This avoids bigger than V2DF vectorization which disturbs the ability
to consistently check for the vectorization result after us now
also vectorizing the V2DF tail of a V4DF vectorization variant.
tested on x86_64-unknown-linux-gnu, pushed.
2021-09-28 Richard Biener
* gcc.dg/vect/bb-
On Mon, 27 Sep 2021, sunil.k.pandey wrote:
> On Linux/x86_64,
>
> d06dc8a2c73735e9496f434787ba4c93ceee5eea is the first bad commit
> commit d06dc8a2c73735e9496f434787ba4c93ceee5eea
> Author: Richard Biener
> Date: Mon Sep 27 13:36:12 2021 +0200
>
> middle-end/102450 - avoid type_for_size
> I'd put this new pattern in mmx.md to keep 64bit/32bit modes in
> mmx.md, similar to e.g. FMA patterns among others.
Yes, I put it after single-float patterns. Attached the patch I'm
going to check-in.
Thanks for your review.
Uros Bizjak 于2021年9月28日周二 下午2:27写道：
>
> On Tue, Sep 28, 2021 at 6:48
On Tue, Sep 28, 2021 at 2:59 PM Richard Biener via Gcc-patches
wrote:
>
> On Mon, 27 Sep 2021, sunil.k.pandey wrote:
>
> > On Linux/x86_64,
> >
> > 6390c5047adb75960f86d56582e6322aaa4d9281 is the first bad commit
> > commit 6390c5047adb75960f86d56582e6322aaa4d9281
> > Author: Richard Biener
> > D
On Tue, Sep 28, 2021 at 8:29 AM Jeff Law via Gcc-patches
wrote:
>
>
>
> On 9/28/2021 12:17 AM, Aldy Hernandez wrote:
> > On Tue, Sep 28, 2021 at 3:46 AM Jeff Law wrote:
> >>
> >>
> >> On 9/27/2021 9:00 AM, Aldy Hernandez wrote:
> >>> Last year I mentioned that -fthread-jumps was being ignored by
On Tue, Sep 28, 2021 at 4:01 AM Hongtao Liu wrote:
>
> On Mon, Sep 27, 2021 at 8:53 PM Richard Biener
> wrote:
> >
> > On Fri, Sep 24, 2021 at 1:26 PM liuhongt wrote:
> > >
> > > Hi:
> > > Related discussion in [1] and PR.
> > >
> > > Bootstrapped and regtest on x86_64-linux-gnu{-m32,}.
> >
It turned out that one warning output depended on details how
the testsuite it run. Thus, just ignore that bit that did not
always appear or not by using dg-prune-output.
Those subtle differences in test runs which make a test fail
or not fail, depending on how GCC's testsuite is run, make
life l
On Tue, Sep 28, 2021 at 8:42 AM liuhongt wrote:
>
> Hi:
> Bootstrapped and regtested on x86_64-pc-lunux-gnu{-m32,}.
> Ok for trunk?
>
> gcc/ChangeLog:
>
> PR target/102494
> * config/i386/i386-expand.c (emit_reduc_half): Hanlde V4HImode.
> * config/i386/mmx.md (reduc_pl
On Tue, 28 Sep 2021, Hongtao Liu wrote:
> On Tue, Sep 28, 2021 at 2:59 PM Richard Biener via Gcc-patches
> wrote:
> >
> > On Mon, 27 Sep 2021, sunil.k.pandey wrote:
> >
> > > On Linux/x86_64,
> > >
> > > 6390c5047adb75960f86d56582e6322aaa4d9281 is the first bad commit
> > > commit 6390c5047adb759
The easiest is to disable AVX2 and AVX512F explicitely.
Tested on x86_64-unknown-linux-gnu, pushed.
2021-09-28 Richard Biener
* gcc.target/i386/vect-pr97352.c: Pass -mno-avx2 -mno-avx512f.
---
gcc/testsuite/gcc.target/i386/vect-pr97352.c | 2 +-
1 file changed, 1 insertion(+), 1 dele
Hi,
As the discussion in PR102347, currently builtin_decl is invoked so
early, it's when making up the function_decl for builtin functions,
at that time the rs6000_builtin_mask could be wrong for those
builtins sitting in #pragma/attribute target functions, though it
will be updated properly later
Hi,
This patch follows the discussions here[1][2], where Segher
pointed out the existing way to guard the extra penalized
cost for strided/elementwise loads with a magic bound does
not scale.
The way with nunits * stmt_cost can get one much
exaggerated penalized cost, such as: for V16QI on P8, it
On Tue, 28 Sep 2021, Richard Biener wrote:
> On Tue, 28 Sep 2021, Hongtao Liu wrote:
>
> > On Tue, Sep 28, 2021 at 2:59 PM Richard Biener via Gcc-patches
> > wrote:
> > >
> > > On Mon, 27 Sep 2021, sunil.k.pandey wrote:
> > >
> > > > On Linux/x86_64,
> > > >
> > > > 6390c5047adb75960f86d56582e63
Hi Segher,
on 2021/9/23 上午6:36, Segher Boessenkool wrote:
> Hi!
>
> On Tue, Sep 21, 2021 at 11:24:08AM +0800, Kewen.Lin wrote:
>> on 2021/9/18 上午6:01, Segher Boessenkool wrote:
>>> On Thu, Sep 16, 2021 at 09:14:15AM +0800, Kewen.Lin wrote:
The way with nunits * stmt_cost can get one much exa
* Richard Biener [2021-09-27 10:23:50 +0200]:
> On Fri, Sep 24, 2021 at 12:34 PM Andrew Burgess
> wrote:
> >
> > * Thomas Schwinge [2021-09-23 11:29:05 +0200]:
> >
> > > Hi!
> > >
> > > I only had a curious look here; hope that's still useful.
> > >
> > > On 2021-09-22T16:30:42+0100, Andrew Bur
Hi,
Gentle ping this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/578552.html
One related patch [1] is ready to commit, whose test cases rely on
this patch if no changes are applied to them.
[1] https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579658.html
BR,
Kewen
The problem here is that the solver's code solving unknown SSAs on entry
to a path was returning UNDEFINED if there were no incoming edges to the
start of the path that were not the function entry block. This caused a
cascade of pain down stream.
Tested on x86-64 Linux.
PR tree-optimizat
Hi!
The testcases in the patch are either miscompiled or ICE with checking,
because the defaulted operator== is synthetized too early (but only if
constexpr), when the corresponding class type is still incomplete type.
The problem is that at that point the bitfield FIELD_DECLs still have as
TREE_T
Dragan Mladjenovic via Gcc-patches
于2021年9月26日周日 下午9:26写道：
>
> This allows us to choose the different names if needed in the future.
>
I try to apply this patch to current gcc, I get this error:
/build/mips-mti-elf/srcs-gcc/gcc/testsuite/gcc.c-torture/compile/20010226-1.c:
In function 'foo':^M
/b
Hi!
i387 has instructions to store some transcedental numbers into the top of
stack. The problem is that what exact bit in the last place one gets for
those depends on the current rounding mode, the CPU knows the number with
slightly higher precision. The compiler assumes rounding to nearest whe
On 9/28/21 9:41 AM, Richard Biener wrote:
On Tue, Sep 28, 2021 at 8:29 AM Jeff Law via Gcc-patches
wrote:
On 9/28/2021 12:17 AM, Aldy Hernandez wrote:
On Tue, Sep 28, 2021 at 3:46 AM Jeff Law wrote:
On 9/27/2021 9:00 AM, Aldy Hernandez wrote:
Last year I mentioned that -fthread-jumps
Hi!
The gimplifier adds implicit private clauses on SIMD constructs for local
variables in the SIMD body if they are addressable to make sure they use
the magic arrays with "omp simd array" attribute (such that each SIMD lane
has its own copy), but we actually don't need to default privatize etc.
In analyzing PR102511, it has become abundantly clear that we need
better debugging aids for the jump threader solver. Currently
debugging these issues is a nightmare if you're not intimately
familiar with the code. This patch attempts to improve this.
First, I'm enabling path solver dumps with
On Tue, Sep 28, 2021 at 11:33 AM Jakub Jelinek wrote:
>
> Hi!
>
> i387 has instructions to store some transcedental numbers into the top of
> stack. The problem is that what exact bit in the last place one gets for
> those depends on the current rounding mode, the CPU knows the number with
> slig
This adds a testcase for the PR which was fixed with the fix for
PR100112.
Tested on x86_64-unknown-linux-gnu, pushed.
2021-09-28 Richard Biener
PR tree-optimization/99793
* gcc.dg/tree-ssa/pr99793.c: New testcase.
---
gcc/testsuite/gcc.dg/tree-ssa/pr99793.c | 14
On Tue, Sep 28, 2021 at 11:42 AM Aldy Hernandez wrote:
>
>
>
> On 9/28/21 9:41 AM, Richard Biener wrote:
> > On Tue, Sep 28, 2021 at 8:29 AM Jeff Law via Gcc-patches
> > wrote:
> >>
> >>
> >>
> >> On 9/28/2021 12:17 AM, Aldy Hernandez wrote:
> >>> On Tue, Sep 28, 2021 at 3:46 AM Jeff Law wrote:
Hi Christophe,
Sorry for the delay.
> -Original Message-
> From: Gcc-patches bounces+kyrylo.tkachov=arm@gcc.gnu.org> On Behalf Of Christophe
> Lyon via Gcc-patches
> Sent: 07 September 2021 10:15
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH 01/13] arm: Add new tests for comparison
> -Original Message-
> From: Gcc-patches bounces+kyrylo.tkachov=arm@gcc.gnu.org> On Behalf Of Christophe
> Lyon via Gcc-patches
> Sent: 07 September 2021 10:15
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH 02/13] arm: Add tests for PR target/100757
>
> These tests currently trigg
> -Original Message-
> From: Gcc-patches bounces+kyrylo.tkachov=arm@gcc.gnu.org> On Behalf Of Christophe
> Lyon via Gcc-patches
> Sent: 07 September 2021 10:15
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH 03/13] arm: Add test for PR target/101325
>
> This test is derived from th
On Sun, 26 Sep 2021, liuhongt wrote:
> Hi:
> > Please don't add the -fno- option to the warning tests. As I said,
> > I would prefer to either suppress the vectorization for the failing
> > cases by tweaking the test code or xfail them. That way future
> > regressions won't be masked by the opti
Hi Christophe,
> -Original Message-
> From: Gcc-patches bounces+kyrylo.tkachov=arm@gcc.gnu.org> On Behalf Of Christophe
> LYON via Gcc-patches
> Sent: 08 September 2021 08:49
> To: Richard Earnshaw ; gcc-
> patc...@gcc.gnu.org
> Subject: Re: [PATCH 04/13] arm: Add GENERAL_AND_VPR_REGS
On Sun, 26 Sep 2021, Ilya Leoshkevich wrote:
> Biasing loop-carried PHIs during the 1st reassociation pass interferes
> with reduction chains and does not bring measurable benefits, so do it
> only during the 2nd reassociation pass.
OK.
Thanks,
Richard.
> gcc/ChangeLog:
>
> * passe
> -Original Message-
> From: Gcc-patches bounces+kyrylo.tkachov=arm@gcc.gnu.org> On Behalf Of Christophe
> Lyon via Gcc-patches
> Sent: 07 September 2021 10:17
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH 05/13] arm: Add support for VPR_REG in
> arm_class_likely_spilled_p
>
> VP
> -Original Message-
> From: Gcc-patches bounces+kyrylo.tkachov=arm@gcc.gnu.org> On Behalf Of Christophe
> Lyon via Gcc-patches
> Sent: 07 September 2021 10:17
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH 06/13] arm: Fix mve_vmvnq_n_ argument
> mode
>
> The vmvnq_n* intrinsics a
On Sun, 26 Sep 2021, Ilya Leoshkevich wrote:
> PR tree-optimization/49749 introduced code that shortens dependency
> chains containing loop accumulators by placing them last on operand
> lists of associative operations.
>
> 456.hmmer benchmark on s390 could benefit from this, however, the code
>
On Sun, 26 Sep 2021, Ilya Leoshkevich wrote:
> Add both positive and negative tests.
The tests will likely be quite fragile with respect to what is
actually vectorized on which target. If you move the tests
to gcc.dg/vect/ you could at least do
/* { dg-require-effective-target vect_int } */
do
Hi Joseph,
Firstly very many thanks for taking the time to respond, and especially for
mentioning
the discussion in PR 54192 (and Marc Glisse's -ffenv-access patches, but
they are a
little less relevant). Indeed the starting point for this patch is Richard
Beiner's proposal
in comment #9 for tha
On Tue, 2021-09-28 at 13:28 +0200, Richard Biener wrote:
> On Sun, 26 Sep 2021, Ilya Leoshkevich wrote:
>
> > Add both positive and negative tests.
>
> The tests will likely be quite fragile with respect to what is
> actually vectorized on which target. If you move the tests
> to gcc.dg/vect/ yo
On Wed, Sep 15, 2021 at 10:46 AM Martin Liška wrote:
>
> Hello.
>
> The patch extends the loop unswitching pass so that gswitch
> statements are supported. The pass now uses ranger which marks
> switch edges that are known to be unreachable in a versioned loop.
>
> Patch can bootstrap on x86_64-li
On Fri, Sep 24, 2021 at 8:29 AM Xionghu Luo wrote:
>
> Update the patch to v3, not sure whether you prefer the paste style
> and continue to link the previous thread as Segher dislikes this...
>
>
> [PATCH v3] Don't move cold code out of loop by checking bb count
>
>
> Changes:
> 1. Handle max_loo
On Tue, Sep 28, 2021 at 1:34 PM Roger Sayle wrote:
>
>
> Hi Joseph,
> Firstly very many thanks for taking the time to respond, and especially for
> mentioning
> the discussion in PR 54192 (and Marc Glisse's -ffenv-access patches, but
> they are a
> little less relevant). Indeed the starting point
Hi!
On 2021-09-27T14:38:56+0200, Tobias Burnus wrote:
> On 27.09.21 14:07, Tobias Burnus wrote:
>> now committed r12-3897-g00f6de9c69119594f7dad3bd525937c94c8200d0
>
> I accidentally changed dg-note to dg-message when updating the expected
> output, as the dump has changed. (Copying seemingly the
Hi!
On 2021-09-27T14:07:53+0200, Tobias Burnus wrote:
> now committed r12-3897-g00f6de9c69119594f7dad3bd525937c94c8200d0
> Conclusion: Reviews are very helpful :-)
Ha! :-) (... and I wasn't even involed here!) ;-P
As testing showed here:
> --- /dev/null
> +++ b/gcc/testsuite/gfortran.dg/a
On Tue, 28 Sep 2021, Ilya Leoshkevich wrote:
> On Tue, 2021-09-28 at 13:28 +0200, Richard Biener wrote:
> > On Sun, 26 Sep 2021, Ilya Leoshkevich wrote:
> >
> > > Add both positive and negative tests.
> >
> > The tests will likely be quite fragile with respect to what is
> > actually vectorized
Found this one lurking around in one of my trees.
It does not solve the actual issue of John that hppa64-hp-hpux11.11 does
not have an __int128 alias integer(kind=16) type. The latter is required for
OpenMP's omp_depend_kind as per implementation choice is has to be large
enough to store two poin
On Tue, Sep 28, 2021 at 03:00:56PM +0200, Tobias Burnus wrote:
> The depend type is a struct with two pointer members for C/C++ - but for
> Fortran OpenMP requires an integer type with kind = omp_depend_kind. Thus,
> libgomp's configure checks that an integer type/kind with size 2*sizeof(void*)
> i
Hi,
this patch implements the latest of my attempts to avoid some of the
unnecessary temporaries noce_convert_multiple currently emits. I named
it 8/7 because it actually applies on top of the last series that is not
yet approved while being a rather minor change.
The idea is to go over the
> On Sep 28, 2021, at 2:14 AM, Richard Biener via Gcc-patches
> wrote:
>
> On Tue, Sep 21, 2021 at 4:26 PM Richard Biener via Gcc-patches
> wrote:
>>
>> This makes defaults.h choose DWARF2_DEBUG if PREFERRED_DEBUGGING_TYPE
>> is not specified by the target and errors out if DWARF DWARF is n
On 28/09/2021 13:12, Kyrylo Tkachov wrote:
-Original Message-
From: Gcc-patches On Behalf Of Christophe
Lyon via Gcc-patches
Sent: 07 September 2021 10:15
To: gcc-patches@gcc.gnu.org
Subject: [PATCH 02/13] arm: Add tests for PR target/100757
These tests currently trigger an ICE whic
On 28/09/2021 13:14, Kyrylo Tkachov wrote:
-Original Message-
From: Gcc-patches On Behalf Of Christophe
Lyon via Gcc-patches
Sent: 07 September 2021 10:15
To: gcc-patches@gcc.gnu.org
Subject: [PATCH 03/13] arm: Add test for PR target/101325
This test is derived from the one provided
On 28/09/2021 13:18, Kyrylo Tkachov wrote:
Hi Christophe,
-Original Message-
From: Gcc-patches On Behalf Of Christophe
LYON via Gcc-patches
Sent: 08 September 2021 08:49
To: Richard Earnshaw ; gcc-
patc...@gcc.gnu.org
Subject: Re: [PATCH 04/13] arm: Add GENERAL_AND_VPR_REGS regclass
On 9/28/2021 3:45 AM, Aldy Hernandez wrote:
In analyzing PR102511, it has become abundantly clear that we need
better debugging aids for the jump threader solver. Currently
debugging these issues is a nightmare if you're not intimately
familiar with the code. This patch attempts to improve t
On Tue, 28 Sep 2021, Jakub Jelinek via Gcc-patches wrote:
> Hi!
>
> The testcases in the patch are either miscompiled or ICE with checking,
> because the defaulted operator== is synthetized too early (but only if
> constexpr), when the corresponding class type is still incomplete type.
> The prob
On Tue, 28 Sep 2021, Patrick Palka wrote:
> On Tue, 28 Sep 2021, Jakub Jelinek via Gcc-patches wrote:
>
> > Hi!
> >
> > The testcases in the patch are either miscompiled or ICE with checking,
> > because the defaulted operator== is synthetized too early (but only if
> > constexpr), when the corr
On 9/28/21 3:47 PM, Jeff Law wrote:
On 9/28/2021 3:45 AM, Aldy Hernandez wrote:
In analyzing PR102511, it has become abundantly clear that we need
better debugging aids for the jump threader solver. Currently
debugging these issues is a nightmare if you're not intimately
familiar with the
On 9/28/2021 7:53 AM, Aldy Hernandez wrote:
On 9/28/21 3:47 PM, Jeff Law wrote:
On 9/28/2021 3:45 AM, Aldy Hernandez wrote:
In analyzing PR102511, it has become abundantly clear that we need
better debugging aids for the jump threader solver. Currently
debugging these issues is a nightm
On 9/25/21 15:15, nick huang wrote:
Why doesn't the PR92010 fix address these testcases as well?
3. PR92010 creates new functions of "rebuild_function_or_method_type" and by
using gdb to trace PR101402 code as following:
template struct A {
typedef T arr[3];
};
template void f(const typ
On Tue, Sep 28, 2021 at 09:49:11AM -0400, Patrick Palka via Gcc-patches wrote:
> > --- gcc/cp/method.c.jj 2021-09-15 08:55:37.563497558 +0200
> > +++ gcc/cp/method.c 2021-09-27 13:48:12.139271830 +0200
> > @@ -3160,8 +3160,11 @@ defaulted_late_check (tree fn)
> >if (kind == sfk_comparison)
Ping…
Qing
Begin forwarded message:
From: Qing Zhao via Gcc-patches
mailto:gcc-patches@gcc.gnu.org>>
Subject: [PATCH][testsuite][aarch64]: Fix gcc.target/aarch64/auto-init-* tests.
Date: September 21, 2021 at 2:20:58 PM CDT
To: gcc-patches Nick Alcock via
mailto:gcc-patches@gcc.gnu.org>>
Reply
Hi all,
This patch adds support for -march=armv8.7-a in GCC.
It adds the +ls64 extension that's included in this architecture revision.
Currently this is just the command-line option and +ls64 allows the relevant
instructions
to be used in inline assembly. The ACLE defines some intrinsics for the
On 9/28/21 1:20 AM, Richard Biener wrote:
On Mon, 27 Sep 2021, sunil.k.pandey wrote:
On Linux/x86_64,
d06dc8a2c73735e9496f434787ba4c93ceee5eea is the first bad commit
commit d06dc8a2c73735e9496f434787ba4c93ceee5eea
Author: Richard Biener
Date: Mon Sep 27 13:36:12 2021 +0200
middle-end
On 9/28/2021 7:53 AM, Aldy Hernandez wrote:
On 9/28/21 3:47 PM, Jeff Law wrote:
On 9/28/2021 3:45 AM, Aldy Hernandez wrote:
In analyzing PR102511, it has become abundantly clear that we need
better debugging aids for the jump threader solver. Currently
debugging these issues is a nightm
On September 28, 2021 5:45:52 PM GMT+02:00, Jeff Law via Gcc-patches
wrote:
>
>
>On 9/28/2021 7:53 AM, Aldy Hernandez wrote:
>>
>>
>> On 9/28/21 3:47 PM, Jeff Law wrote:
>>>
>>>
>>> On 9/28/2021 3:45 AM, Aldy Hernandez wrote:
In analyzing PR102511, it has become abundantly clear that we need
On September 28, 2021 5:45:52 PM GMT+02:00, Jeff Law via Gcc-patches
wrote:
>
>
>On 9/28/2021 7:53 AM, Aldy Hernandez wrote:
>>
>>
>> On 9/28/21 3:47 PM, Jeff Law wrote:
>>>
>>>
>>> On 9/28/2021 3:45 AM, Aldy Hernandez wrote:
In analyzing PR102511, it has become abundantly clear that we need
I really don't know what to do here. This is a bit of whack-o-mole.
The IL is sufficiently different for various architectures that any
tweak can cause the number of jump threads to vary.
For the pr7745-2.c testcase, we have less threading candidates because 2
of them now cross loop boundaries.
On 9/28/21 6:05 PM, Richard Biener wrote:
On September 28, 2021 5:45:52 PM GMT+02:00, Jeff Law via Gcc-patches
wrote:
On 9/28/2021 7:53 AM, Aldy Hernandez wrote:
On 9/28/21 3:47 PM, Jeff Law wrote:
On 9/28/2021 3:45 AM, Aldy Hernandez wrote:
In analyzing PR102511, it has become abu
Found when looking at Sandra's c535b-1.f90 and playing around.
When fixing same_type_as, I spotted by code reading another issue,
related to not catering for derived types. (Untested whether it
failed indeed.)
I added now a bunch of testcases.
OK for mainline?
Tobias
-
Siemens
On 9/28/2021 10:09 AM, Aldy Hernandez wrote:
I really don't know what to do here. This is a bit of whack-o-mole.
The IL is sufficiently different for various architectures that any
tweak can cause the number of jump threads to vary.
For the pr7745-2.c testcase, we have less threading candida
On Tue, 28 Sep 2021, Jakub Jelinek wrote:
> On Tue, Sep 28, 2021 at 09:49:11AM -0400, Patrick Palka via Gcc-patches wrote:
> > > --- gcc/cp/method.c.jj2021-09-15 08:55:37.563497558 +0200
> > > +++ gcc/cp/method.c 2021-09-27 13:48:12.139271830 +0200
> > > @@ -3160,8 +3160,11 @@ defaulted_
On Tue, Sep 28, 2021 at 12:44:58PM -0400, Patrick Palka wrote:
> Ah yeah, sorry for the noise, I misunderstood the function comment.
>
> On a related note I think 'ctx' can also be a NAMESPACE_DECL here in
> the case of a defaulted non-member operator<=> (as in the below), for
> which I'd expect t
On Tue, Sep 28, 2021 at 06:49:38PM +0200, Jakub Jelinek via Gcc-patches wrote:
> On Tue, Sep 28, 2021 at 12:44:58PM -0400, Patrick Palka wrote:
> > Ah yeah, sorry for the noise, I misunderstood the function comment.
> >
> > On a related note I think 'ctx' can also be a NAMESPACE_DECL here in
> > t
Signed-off-by: Jonathan Wakely
libstdc++-v3/ChangeLog:
PR libstdc++/102499
* include/bits/fs_path.h (path::begin, path::end): Add noexcept
to declarations, to match definitions.
Tested x86_64-linux. Committed to trunk.
commit f2b7f56a15d9cbbd2f0db22e0e39c4dd161bab69
Aut
The previous message told you something was wrong, but not why it
happened or why it's bad. This changes it to explain that the function
is being misused.
Signed-off-by: Jonathan Wakely
libstdc++-v3/ChangeLog:
* include/bits/move.h (forward(remove_reference_t&&)):
Improve text o
On Tue, 28 Sep 2021, Jakub Jelinek wrote:
> On Tue, Sep 28, 2021 at 06:49:38PM +0200, Jakub Jelinek via Gcc-patches wrote:
> > On Tue, Sep 28, 2021 at 12:44:58PM -0400, Patrick Palka wrote:
> > > Ah yeah, sorry for the noise, I misunderstood the function comment.
> > >
> > > On a related note I t
On 9/27/21 15:38, Iain Sandoe wrote:
For coroutines, we make copies of the original function arguments into
the coroutine frame. Normally, these are destroyed on the proper exit
from the coroutine when the frame is destroyed.
However, if an exception is thrown before the first suspend point is
The BPF CO-RE support (commit 8bdabb37549f12ce727800a1c8aa182c0b1dd42a)
mistakenly overwrote bpf-*-* extra_headers in config.gcc, causing
bpf-helpers.h to not be installed. The redefinition with coreout.h is
unneeded, so delete it.
gcc/ChangeLog:
* config.gcc (bpf-*-*): Do not overwrite e
On Tue, Sep 28, 2021 at 01:25:13PM -0400, Patrick Palka via Gcc-patches wrote:
> On Tue, 28 Sep 2021, Jakub Jelinek wrote:
>
> > On Tue, Sep 28, 2021 at 06:49:38PM +0200, Jakub Jelinek via Gcc-patches
> > wrote:
> > > On Tue, Sep 28, 2021 at 12:44:58PM -0400, Patrick Palka wrote:
> > > > Ah yeah,
Fix the free'up of btf_var_ids hash_map in btf_finalize ().
Testing notes:
- Bootstrapped GCC with -gbtf as an experiment.
- Usual bootstrap and regression testing on x86_64.
- BPF backend testing - make all-gcc, reg tested bpf.exp, btf.exp and ctf.exp.
(tested using David Faust's config.gcc pa
CTF is supported for C only. Currently, a warning is emitted if the -gctf
command line option is specified for a non-C frontend. This warning is also
used by the GCC testsuite framework - it skips adding -gctf to the list of
debug flags for automated testing, if CTF is not supported for the front
Hi,
These two symbols have been emitted since 4.8, but were not added
to the Darwin exports, so we have been using the ones from libgcc.a.
Added to libgcc_s now.
tested on i686 and x86_64-darwin, pushed to master,
thanks
Iain
Signed-off-by: Iain Sandoe
libgcc/ChangeLog:
* config/i386
Hi Tobias,
let me first reach for my brown bag...
> Otherwise, the quote from F2018 of my previous email applies:
>
> F2018:16.9.109 LBOUND has for "case(i)", i.e. with a 'dim'
> argument the following. The case without 'dim' just iterates
> through case (i) for each dim. Thus:
>
> "If DIM is pre
Here, when unifying TT with S, processing_template_decl is unset, and
this foils the dependence checks in do_auto_deduction for avoiding
checking constraints on an auto when the initializer is dependent.
This patch fixes this issue by making sure processing_template_decl is
set during the call to
Hi,
We have a somewhat unusual situation in that for PPC64, R13 is
both reserved for future use by the ABI document and callee-saved.
In fact, it is already used internally by the pthreads
implementation to contain pthread_self.
So add R13 to the fixed regs, but also keep it in the callee-
saved
Hi Kewen,
Although I agree that what we do now is tragically bad (and will be fixed in
the builtin rewrite), this seems a little too cavalier to remove all checking
during initialization without adding any checking somewhere else. :-) We still
need to check for invalid usage when the builtin i
This allows std::__to_address to be used with __normal_iterator in
C++11/14/17 modes. Without the partial specialization the deduced
pointer_traits::element_type is incorrect, and so the return type of
__to_address is wrong.
A similar partial specialization is probably needed for
__gnu_debug::_Saf
The _OutputIteratorConcept should be checked using the correct value
category. The std::move_backward and std::copy_backward algorithms
should use _OutputIteratorConcept instead of _ConvertibleConcept.
In order to use the correct value category, the concept should use a
function that returns _Valu
Types used in ordered containers need to be comparable, or the container
needs to use a custom comparison function. These tests fail when
_GLIBCXX_CONCEPT_CHECKS is defined, because the element types aren't
comparable.
Signed-off-by: Jonathan Wakely
libstdc++-v3/ChangeLog:
* testsuite/2
Signed-off-by: Jonathan Wakely
libstdc++-v3/ChangeLog:
* testsuite/25_algorithms/copy/34595.cc: Add missing operation
for type used as an iterator.
* testsuite/25_algorithms/unique_copy/check_type.cc: Likewise.
Tested x86_64-linux. Committed to trunk.
commit 5f1db7627f6
This adds some additional checks the the C++98-style concept checks for
iterators, and removes some bogus checks for mutable iterators. Instead
of requiring that the result of dereferencing a mutable iterator is
assignable (which is a property of the value type, not required for the
iterator) check
The extension that allows implicitly rebinding a container's allocator
is not allowed when _GLIBCXX_CONCEPT_CHECKS is defined, so skip the
tests for that extension.
Signed-off-by: Jonathan Wakely
libstdc++-v3/ChangeLog:
*
testsuite/23_containers/deque/requirements/explicit_instantiatio
As an extension, our container adaptors SFINAE away the default
constructor if the adapted sequence container is not default
constructible. When _GLIBCXX_CONCEPT_CHECKS is defined we enforce that
the sequence is default constructible, so the tests for the extension
fail. This disables the relevant
Hi,
Recognise .d for D source files on the command line. This will
trigger an invocation of dsymutil when a D source is present.
tested along with D patches on i686, powerpc and x86_64 darwin,
pushed to master, thanks,
Iain
gcc/ChangeLog:
* config/darwin.h (DSYMUTIL_SPEC): Recognize D
On Thu, 2 Sept 2021 at 22:25, Jonathan Wakely wrote:
>
> On Thu, 2 Sept 2021 at 19:00, Jonathan Wakely wrote:
> >
> > * include/bits/atomic_wait.h (_GLIBCXX_HAVE_PLATFORM_WAIT):
> > Define before first attempt to check it.
> >
> > Tested x86_64-linux and powerpc64-linux, not committ
On 9/28/21 09:53, Patrick Palka wrote:
On Tue, 28 Sep 2021, Patrick Palka wrote:
On Tue, 28 Sep 2021, Jakub Jelinek via Gcc-patches wrote:
Hi!
The testcases in the patch are either miscompiled or ICE with checking,
because the defaulted operator== is synthetized too early (but only if
conste
This fixes a logic error in the futex-based timed wait.
Signed-off-by: Jonathan Wakely
libstdc++-v3/ChangeLog:
* include/bits/atomic_timed_wait.h (__platform_wait_until_impl):
Return false for ETIMEDOUT and true otherwise.
Tested x86_64-linux.
I'm not seeing any tests fail as
Signed-off-by: Jonathan Wakely
libstdc++-v3/ChangeLog:
* include/bits/regex.h (basic_regex, swap): Add noexcept to
non-throwing functions.
* include/bits/regex_automaton.h (_State_base, _State)
(_NFA_base): Likewise.
* include/bits/regex_compiler.h (_Compi
Signed-off-by: Jonathan Wakely
libstdc++-v3/ChangeLog:
* include/bits/regex_compiler.tcc: Add line break in empty while
statement.
* include/bits/regex_executor.tcc: Avoid unused parameter
warning.
Tested x86_64-linux. Committed to trunk.
commit b5f276b8c76d892f
There is no benefit to using _SizeT instead of size_t, and IterT tells
you less about the type than const _CharT*. This removes some unhelpful
typedefs.
Signed-off-by: Jonathan Wakely
libstdc++-v3/ChangeLog:
* include/bits/regex_automaton.h (_NFA_base::_SizeT): Remove.
* include
On 9/28/21 15:15, Patrick Palka wrote:
Here, when unifying TT with S, processing_template_decl is unset, and
this foils the dependence checks in do_auto_deduction for avoiding
checking constraints on an auto when the initializer is dependent.
This patch fixes this issue by making sure processing
Hi!
On Thu, Aug 26, 2021 at 11:53:24AM -0300, Raphael Moreira Zinsly wrote:
> Without dwarf2 unwind tables available _Unwind_Backtrace() is not
> able to return the full backtrace.
> This patch adds a fallback function on powerpc to get the backtrace
> by doing a backchain, this code was originall
1 - 100 of 123 matches
Mail list logo
