On 3/3/21 6:20 PM, Martin Sebor wrote:
On 3/2/21 7:11 AM, Jason Merrill wrote:
On 3/1/21 6:11 PM, Martin Sebor wrote:
On 2/24/21 5:35 PM, Jason Merrill wrote:
On 2/23/21 6:07 PM, Martin Sebor wrote:
On 2/23/21 2:52 PM, Jason Merrill wrote:
On 2/23/21 11:02 AM, Martin Sebor wrote:
[CC Jason
Maciej W. Rozycki 于2021年3月4日周四 上午7:50写道：
>
> On Fri, 19 Feb 2021, YunQiang Su wrote:
>
> > > My understanding therefore is that the original assumption that `optimal'
> > > will serve people best is no longer true.
> > >
> >
> > I guess that `optimal' can still produce the best performance,
>
> On 2/23/21 3:14 AM, YunQiang Su wrote:
> > For MIPSr6, we may wish to use compact-branches only.
> > Currently, we have to use `always' option, while it is mark as
> > conflict with pre-R6.
> > cc1: error: unsupported combination: ‘mips32r2’
> > -mcompact-branches=always Just ignore
Yes, OK, however, have you been able to test performance. I am only
curious. There was a test program we used back when this code was first
implemented in bugzilla. I do not remember the PR number off hand.
Jerry
On 2/23/21 1:46 PM, Harald Anlauf via Fortran wrote:
Dear all,
under certain
On Thu, Mar 4, 2021 at 1:19 AM Andrew Pinski wrote:
> On Wed, Mar 3, 2021 at 4:02 PM Christoph Müllner
> wrote:
> >
> > [CCing Andrew Pinski, who had the same question]
> >
> > On 2/15/21 1:12 PM, Richard Earnshaw wrote:
> > > On 09/12/2020 17:21, Christoph Müllner wrote:
> > >> From: Christoph
Yes OK got mainline.
On 3/3/21 3:45 AM, Tobias Burnus wrote:
Rather obvious change – don't apply replacement multiple times.
OK for mainline?
Tobias
-
Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München
Registergericht München HRB 106955, Geschäftsführer:
Jason Merrill wrote:
I notice this patch includes
+ var_nest_node () = default;
which will break GCC 10 bootstrap with a C++98 compiler; we only
switched to C++11 for GCC 11.
Hmm, the patch was already backported…
… I will fix this.
I missed the warning during testing.
Iain
On Wed, Mar 03, 2021 at 11:33:52PM +, Joseph Myers wrote:
> On Wed, 3 Mar 2021, Michael Meissner via Gcc-patches wrote:
>
> > As we have discussed many times, on 32-bit BE, you cannot use hardware
> > _Float128 support on power9/power10 because there is no TImode in 32-bit.
> > Various
In this test we are building a call in a template, but since neither
the function nor any of its arguments are dependent, we go down the
normal path in finish_call_expr. convert_arguments sees that we're
binding a reference to int to double and therein convert_to_integer
creates a FIX_TRUNC_EXPR.
On Wed, Mar 3, 2021 at 4:02 PM Christoph Müllner wrote:
>
> [CCing Andrew Pinski, who had the same question]
>
> On 2/15/21 1:12 PM, Richard Earnshaw wrote:
> > On 09/12/2020 17:21, Christoph Müllner wrote:
> >> From: Christoph Muellner
> >>
> >> It is possible to call
> From: Hans-Peter Nilsson
> Date: Tue, 2 Mar 2021 23:58:08 +0100
> > From: Jeff Law
> > Date: Tue, 2 Mar 2021 23:39:27 +0100
> > On 2/24/21 10:17 PM, Hans-Peter Nilsson via Gcc-patches wrote:
> > > Ok to commit? Or is a renaming patch appending a
> > > number-suffix, like:
> > >
> > > ---
On 3/3/21 3:31 AM, Richard Biener wrote:
On Tue, Mar 2, 2021 at 9:23 PM Martin Sebor wrote:
On 3/2/21 3:39 AM, Richard Biener wrote:
On Fri, Jan 22, 2021 at 12:39 AM Martin Sebor via Gcc-patches
wrote:
The hack I put in compute_objsize() last January for pr93200 isn't
quite correct. It
[CCing Andrew Pinski, who had the same question]
On 2/15/21 1:12 PM, Richard Earnshaw wrote:
> On 09/12/2020 17:21, Christoph Müllner wrote:
>> From: Christoph Muellner
>>
>> It is possible to call aarch64_declare_function_name() and
>> have cfun not set. Let's sanitize the access to this
On Wed, 3 Mar 2021, Jeff Law wrote:
> > gcc/testsuite/ChangeLog:
> > * gcc.target/mips/compact-branches-1.c: add isa_rev>=6.
> > * gcc.target/mips/mips.exp: don't add -mipsXXr6 option for
> > -mcompact-branches=always. It is usable for pre-R6 now.
> > *
On Fri, 19 Feb 2021, YunQiang Su wrote:
> > My understanding therefore is that the original assumption that `optimal'
> > will serve people best is no longer true.
> >
>
> I guess that `optimal' can still produce the best performance, while
> the delay slot
> make MIPS quite differnent with
On Wed, 3 Mar 2021, Michael Meissner via Gcc-patches wrote:
> As we have discussed many times, on 32-bit BE, you cannot use hardware
> _Float128 support on power9/power10 because there is no TImode in 32-bit.
> Various machine independent parts of GCC require an integer type to be the
> same
>
On 3/2/21 7:11 AM, Jason Merrill wrote:
On 3/1/21 6:11 PM, Martin Sebor wrote:
On 2/24/21 5:35 PM, Jason Merrill wrote:
On 2/23/21 6:07 PM, Martin Sebor wrote:
On 2/23/21 2:52 PM, Jason Merrill wrote:
On 2/23/21 11:02 AM, Martin Sebor wrote:
[CC Jason for any further comments/clarification]
On 1/21/21 2:59 AM, Martin Jambor wrote:
> Hi,
>
> in the PR 98078 testcase, speculative call-graph edges which were
> created by IPA-CP are confirmed during inlining but
> cgraph_edge::set_call_stmt does not take it very well.
>
> The function enters the update_speculative branch and updates
On 2/23/21 3:14 AM, YunQiang Su wrote:
> For MIPSr6, we may wish to use compact-branches only.
> Currently, we have to use `always' option, while it is mark as conflict
> with pre-R6.
> cc1: error: unsupported combination: ‘mips32r2’ -mcompact-branches=always
> Just ignore
I notice this patch includes
+ var_nest_node () = default;
which will break GCC 10 bootstrap with a C++98 compiler; we only
switched to C++11 for GCC 11.
On Fri, Jul 17, 2020 at 8:57 AM Nathan Sidwell wrote:
>
> On 7/17/20 3:37 AM, Richard Biener wrote:
> > On Thu, Jul 16, 2020 at 7:39 PM
On 3/3/21 1:42 PM, Ilya Leoshkevich wrote:
> On Wed, 2021-03-03 at 21:26 +0100, Ilya Leoshkevich via Gcc-patches
> wrote:
>> On Wed, 2021-03-03 at 13:02 -0700, Jeff Law wrote:
>>>
>>> On 3/2/21 4:50 PM, Ilya Leoshkevich via Gcc-patches wrote:
Hello,
I would like to ping the
On 3/3/21 12:39 PM, Iain Sandoe wrote:
> Iain Sandoe wrote:
>
>> This is not a GCC problem, but a fault in the static linker where,
>> when a source file is used multiple times, with conditional compilation
>> the source file is only referenced by the linker for the first object.
>> Then, when
On Mar 3, 2021, Segher Boessenkool wrote:
> On Wed, Mar 03, 2021 at 04:45:23PM -0300, Alexandre Oliva wrote:
>> On Mar 2, 2021, Segher Boessenkool wrote:
>>
>> > This is PR99352 now.
>>
>> Thanks. I've filed PR99371 for the add_options_for_sqrt_insn
>> incompleteness,
> As I said before,
It turns out that cloning can cause use to load things. Specifically
when checking paramter shadows (this is avoidable), and also the delete
operator of a deleting dtor (not avoidable). Doing that in the middle
of loading is a bad thing. This defers it to a post-load worklist. If
it
On Wed, 2021-03-03 at 21:26 +0100, Ilya Leoshkevich via Gcc-patches
wrote:
> On Wed, 2021-03-03 at 13:02 -0700, Jeff Law wrote:
> >
> >
> > On 3/2/21 4:50 PM, Ilya Leoshkevich via Gcc-patches wrote:
> > > Hello,
> > >
> > > I would like to ping the following patch:
> > >
> > > Add input_modes
Hi!
On Tue, Dec 08, 2020 at 03:46:31PM -0600, Pat Haugen wrote:
> gcc/
> * config/rs6000/dfp.md (extendddtd2, trunctddd2, *cmp_internal1,
> floatditd2, ftrunc2, fixdi2, dfp_ddedpd_,
> dfp_denbcd_, dfp_dxex_, dfp_diex_,
> *dfp_sgnfcnc_, dfp_dscli_, dfp_dscri_): Update size
On Wed, 2021-03-03 at 13:02 -0700, Jeff Law wrote:
>
>
> On 3/2/21 4:50 PM, Ilya Leoshkevich via Gcc-patches wrote:
> > Hello,
> >
> > I would like to ping the following patch:
> >
> > Add input_modes parameter to TARGET_MD_ASM_ADJUST hook
> >
On Wed, Mar 03, 2021 at 04:45:23PM -0300, Alexandre Oliva wrote:
> On Mar 2, 2021, Segher Boessenkool wrote:
>
> > This is PR99352 now.
>
> Thanks. I've filed PR99371 for the add_options_for_sqrt_insn
> incompleteness,
As I said before, I don't agree with that. We do no longer support
Was happy to find out that my recent dguide fix (r11-7483) fixed
this test too. In particular, the
+ /* Wait until the enclosing scope is non-dependent. */
+ if (DECL_CLASS_SCOPE_P (tmpl)
+ && dependent_type_p (DECL_CONTEXT (tmpl)))
+return ptype;
bit.
Tested x86_64-pc-linux-gnu,
On Wed, 2021-03-03 at 11:34 -0700, Jeff Law wrote:
>
>
> On 3/2/21 3:37 PM, Ilya Leoshkevich via Gcc-patches wrote:
> > Bootstrapped and regtested on x86_64-redhat-linux, ppc64le-redhat-
> > linux
> > and s390x-redhat-linux. Ok for master?
> >
> >
> >
> > Commit efb6bc55a93a ("fwprop: Allow
hi!
On Wed, Mar 03, 2021 at 04:22:29PM -0300, Alexandre Oliva wrote:
> While we could hide the bug/missing feature in add_options_for_sqrt_insn
> by constraining check_effective_target_sqrt_insn, the result would be
> just reduced test coverage for powerpc builds that defaulted to
>
On 3/2/21 4:50 PM, Ilya Leoshkevich via Gcc-patches wrote:
> Hello,
>
> I would like to ping the following patch:
>
> Add input_modes parameter to TARGET_MD_ASM_ADJUST hook
> https://gcc.gnu.org/pipermail/gcc-patches/2021-January/562898.html
>
> It is needed for the following regression fix:
>
On Mar 2, 2021, Segher Boessenkool wrote:
> This is PR99352 now.
Thanks. I've filed PR99371 for the add_options_for_sqrt_insn
incompleteness, and PR99372 for the gimplefe-28.c ICE.
--
Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain
Iain Sandoe wrote:
This is not a GCC problem, but a fault in the static linker where,
when a source file is used multiple times, with conditional compilation
the source file is only referenced by the linker for the first object.
Then, when dsymutil tries to find the source file for next object
This defers inserting specializations into the specialization table,
until we have completed their streaming. When streaming a cluster we
ensure that all imports are populated before any of the cluster, so they
need no visibility of other specializations. Further within the same
import,
Thanks for the review. I attached the updated patch.
Can you commit this for me or point me to what I should do next? This is my
first contribution here.
Best,
Moritz
Am 03.03.21 um 19:02 schrieb Patrick Palka:
On Wed, 3 Mar 2021, Moritz Sichert via Libstdc++ wrote:
On Mar 2, 2021, David Edelsohn wrote:
> The procs are used in more than that one test.
Err, are you looking at the trunk? In my tree, there are only two tests
that mention sqrt_insn, and it's two rather than one just because I
added the flag to another test myself, in a patch yet to be
On Tue, Mar 02, 2021 at 03:53:06PM -0600, Segher Boessenkool wrote:
> If you want to make decimal and/or QP float work only on 64-bit LE Linux
> you should say so. And in that case, that is certainly not acceptable
> if it doesn't "sorry" at configure time already.
Well in general the only
On Linux/x86_64,
f8e7f3f3f33e22721a28772cc3f9b616e48cd1c9 is the first bad commit
commit f8e7f3f3f33e22721a28772cc3f9b616e48cd1c9
Author: Jason Merrill
Date: Thu Feb 11 22:01:19 2021 -0500
cgraph: flatten and same_body aliases [PR96078]
caused
FAIL: gcc.dg/attr-flatten-1.c (test for
On 3/2/21 3:37 PM, Ilya Leoshkevich via Gcc-patches wrote:
> Bootstrapped and regtested on x86_64-redhat-linux, ppc64le-redhat-linux
> and s390x-redhat-linux. Ok for master?
>
>
>
> Commit efb6bc55a93a ("fwprop: Allow (subreg (mem)) simplifications")
> introduced a check that was supposed to
Hi,
This patch merges the D front-end implementation with upstream dmd,
fixing a heap-buffer-overflow in checkModFileAlias. The code wrongly
assumed memcmp did not read past the mismatch.
Bootstrapped and regression tested on x86_64-linux-gnu/-m32/-mx32,
committed to mainline, and backported to
On Wed, Mar 03, 2021 at 12:45:54PM -0500, David Malcolm wrote:
> > I think it's the D.6750 which is printed via
> >
> > else if (TREE_CODE (node) == DEBUG_EXPR_DECL)
> > {
> > if (flags & TDF_NOUID)
> > pp_string (pp, "D#");
> > else
> >
On Wed, 3 Mar 2021, Moritz Sichert via Libstdc++ wrote:
> std::ranges::reverse_view uses make_reverse_iterator in its
> implementation as described in [range.reverse.view]. This accidentally
> allows ADL as an unqualified name is used in the call. According to
> [contents], however, this should
On Wed, 2021-03-03 at 16:23 +0100, Richard Biener wrote:
> On Wed, 3 Mar 2021, David Malcolm wrote:
>
> > On Wed, 2021-03-03 at 08:48 +0100, Richard Biener wrote:
> > > On Tue, 2 Mar 2021, Martin Sebor wrote:
> > >
> > > > On 3/2/21 9:52 AM, Jeff Law via Gcc-patches wrote:
> > > > >
> > > > >
On 03/03/21 19:34 +0200, Ville Voutilainen wrote:
On Wed, 3 Mar 2021 at 19:25, Jonathan Wakely via Libstdc++
wrote:
Oh, except that is_scalar is surprisingly expensive to instantiate
(its defined in a really expensive way) and since we control all uses
I'll be more than happy to write you an
On Wed, 3 Mar 2021 at 19:25, Jonathan Wakely via Libstdc++
wrote:
> Oh, except that is_scalar is surprisingly expensive to instantiate
> (its defined in a really expensive way) and since we control all uses
I'll be more than happy to write you an __is_scalar for GCC 12. :P
On 23/02/21 13:57 -0800, Thomas Rodgers wrote:
From: Thomas Rodgers
* This revises the previous version to fix std::__condvar::wait_until() usage.
This is a substantial rewrite of the atomic wait/notify (and timed wait
counterparts) implementation.
The previous __platform_wait looped on
On Wednesday, 3 March 2021 08:21:51 PST Jonathan Wakely wrote:
> >>- = is_same_v, __platform_wait_t>;
> >>+ = is_scalar_v> && sizeof(_Tp) ==
> >>sizeof(__platform_wait_t)
> Oh, except that is_scalar is surprisingly expensive to instantiate
> (its defined in a really expensive way) and
std::ranges::reverse_view uses make_reverse_iterator in its
implementation as described in [range.reverse.view]. This accidentally
allows ADL as an unqualified name is used in the call. According to
[contents], however, this should be treated as a qualified lookup into
the std namespace.
This
On 03/03/21 09:14 -0800, Thiago Macieira via Libstdc++ wrote:
On Wednesday, 3 March 2021 06:34:26 PST Jonathan Wakely wrote:
On 26/02/21 07:59 -0800, Thiago Macieira via Libstdc++ wrote:
>ints can be used as futex on Linux. ptrdiff_t on 64-bit Linux can't.
Yes, we should do this for GCC 11.
On Tue, Mar 02, 2021 at 01:29:59PM +0100, Richard Biener wrote:
> On Sun, Feb 14, 2021 at 11:27 AM Stefan Schulze Frielinghaus
> wrote:
> >
> > On Tue, Feb 09, 2021 at 09:57:58AM +0100, Richard Biener wrote:
> > > On Mon, Feb 8, 2021 at 3:11 PM Stefan Schulze Frielinghaus via
> > > Gcc-patches
On Wednesday, 3 March 2021 06:34:26 PST Jonathan Wakely wrote:
> On 26/02/21 07:59 -0800, Thiago Macieira via Libstdc++ wrote:
> >ints can be used as futex on Linux. ptrdiff_t on 64-bit Linux can't.
>
> Yes, we should do this for GCC 11.
Want me to re-submit this one alone, with the "alignas(4)"
On Tue, 2 Mar 2021, Jason Merrill wrote:
> On 3/2/21 11:45 AM, Patrick Palka wrote:
> > On Mon, 1 Mar 2021, Jason Merrill wrote:
> >
> > > On 2/28/21 12:59 PM, Patrick Palka wrote:
> > > > This folds the diagnose_requires_expr routines into the corresponding
> > > > tsubst_requires_expr ones.
On 03/03/21 14:34 +, Jonathan Wakely wrote:
On 26/02/21 07:59 -0800, Thiago Macieira via Libstdc++ wrote:
The kernel doesn't care what we store in those 32 bits, only that they are
comparable. This commit adds:
* pointers and long on 32-bit architectures
* unsigned
* untyped enums and typed
On Wed, Mar 03, 2021 at 04:23:59PM +0100, Richard Biener wrote:
> I think it's the D.6750 which is printed via
>
> else if (TREE_CODE (node) == DEBUG_EXPR_DECL)
> {
> if (flags & TDF_NOUID)
> pp_string (pp, "D#");
> else
> pp_printf
> -Original Message-
> From: Jonathan Wright
> Sent: 03 March 2021 12:38
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: [PATCH] testsuite: aarch64: Add tests for vcvt FP intrinsics
>
> Hi,
>
> As subject, this patch adds tests for vcvtx* and vcvt_fXX_fXX
> -Original Message-
> From: Jonathan Wright
> Sent: 03 March 2021 12:33
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: [PATCH] testsuite: aarch64: Add tests for v[q]mov[u]n_high intrinsics
>
> Hi,
>
> As subject, this patch adds tests for v[q]mov[u]n_high Neon
> -Original Message-
> From: Jonathan Wright
> Sent: 03 March 2021 12:29
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: [PATCH] testsuite: aarch64: Add tests for v[r]shrn_high intrinsics
>
> Hi,
>
> As subject, this patch adds tests for v[r]shrn_high Neon intrinsics.
> -Original Message-
> From: Jonathan Wright
> Sent: 03 March 2021 12:24
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: [PATCH] testsuite: aarch64: Add tests for narrowing-arithmetic
> intrinsics
>
> Hi,
>
> As subject, this patch adds tests for v[r]addhn_high and
On Wed, 3 Mar 2021, Jonathan Wakely wrote:
> For int, there shouldn't be any need to force the alignment. I don't
> think any ABI supported by GCC allows int members to be aligned to
> less than __alignof__(int).
(sizeof(int) last)
The CRIS ABI does as in default packed, and ISTR there was some
On Wed, 3 Mar 2021, David Malcolm wrote:
> On Wed, 2021-03-03 at 08:48 +0100, Richard Biener wrote:
> > On Tue, 2 Mar 2021, Martin Sebor wrote:
> >
> > > On 3/2/21 9:52 AM, Jeff Law via Gcc-patches wrote:
> > > >
> > > >
> > > > On 3/1/21 1:39 AM, Richard Biener wrote:
> > > > > The default
On 23/02/21 13:57 -0800, Thomas Rodgers wrote:
diff --git a/libstdc++-v3/include/bits/atomic_wait.h
b/libstdc++-v3/include/bits/atomic_wait.h
index 1a0f0943ebd..fa83ef6c231 100644
--- a/libstdc++-v3/include/bits/atomic_wait.h
+++ b/libstdc++-v3/include/bits/atomic_wait.h
@@ -39,17 +39,16 @@
Hi Eric,
>> sparcv9 bootstrap has been broken for 1 1/2 years now by spurious
>> -Wuninitialized warnings:
>
> IIRC we used to have 3 of them, now we have 2 so there is some progress. ;-)
>
>> Before we ship yet another release with this issue, I suggest to at
>> least include a workaround of
On 03/03/21 14:56 +, Jonathan Wakely wrote:
On 01/03/21 09:56 +0100, Richard Biener via Libstdc++ wrote:
On Sun, Feb 28, 2021 at 10:53 PM Hans-Peter Nilsson wrote:
On Fri, 26 Feb 2021, Thiago Macieira via Gcc-patches wrote:
On Friday, 26 February 2021 11:31:00 PST Andreas Schwab
On 3/2/21 6:10 PM, Jakub Jelinek wrote:
Hi!
P0145R3 added
"However, the operands are sequenced in the order prescribed for the built-in
operator" rule for overloaded operator calls when using the operator syntax.
op_is_ordered follows that, but added just the overloaded operators
added in that
On Mär 03 2021, Jonathan Wakely wrote:
> For int, there shouldn't be any need to force the alignment. I don't
> think any ABI supported by GCC allows int members to be aligned to
> less than __alignof__(int).
There is no requirement that __alignof__(int) is big enough.
Andreas.
--
Andreas
On Wed, 2021-03-03 at 08:48 +0100, Richard Biener wrote:
> On Tue, 2 Mar 2021, Martin Sebor wrote:
>
> > On 3/2/21 9:52 AM, Jeff Law via Gcc-patches wrote:
> > >
> > >
> > > On 3/1/21 1:39 AM, Richard Biener wrote:
> > > > The default diagnostic tree printer relies on dump_generic_node
> > > >
On 01/03/21 09:56 +0100, Richard Biener via Libstdc++ wrote:
On Sun, Feb 28, 2021 at 10:53 PM Hans-Peter Nilsson wrote:
On Fri, 26 Feb 2021, Thiago Macieira via Gcc-patches wrote:
> On Friday, 26 February 2021 11:31:00 PST Andreas Schwab wrote:
> > On Feb 26 2021, Thiago Macieira wrote:
>
On 3/3/21 12:26 PM, Jan Hubicka wrote:
libgcc/ChangeLog:
PR gcov-profile/99105
* libgcov-driver.c (write_top_counters): Rename to ...
(write_topn_counters): ... this.
(write_one_data): Pre-allocate buffer for number of items
in the corresponding linked
> sparcv9 bootstrap has been broken for 1 1/2 years now by spurious
> -Wuninitialized warnings:
IIRC we used to have 3 of them, now we have 2 so there is some progress. ;-)
> Before we ship yet another release with this issue, I suggest to at
> least include a workaround of demoting them to
On 2020/1/21 12:49 AM, Jakub Jelinek wrote:
The OpenMP 4.5 definition of mappable type for C++ is that
- All data members must be non-static.
among other requirements. In OpenMP 5.0 that has been removed.
So, if we follow the 4.5 definition, it shouldn't change, if we follow 5.0
definition,
On 26/02/21 07:59 -0800, Thiago Macieira via Libstdc++ wrote:
Our thread's ID does not change so we don't have to get it every time
and hash it every time.
This looks good for GCC 11.
(This one wouldn't be an ABI break to change later, but we might as
well do it now, as we have the patch
On 26/02/21 07:59 -0800, Thiago Macieira via Libstdc++ wrote:
The kernel doesn't care what we store in those 32 bits, only that they are
comparable. This commit adds:
* pointers and long on 32-bit architectures
* unsigned
* untyped enums and typed enums on int & unsigned int
* float
We're not
On 26/02/21 07:59 -0800, Thiago Macieira via Libstdc++ wrote:
ints can be used as futex on Linux. ptrdiff_t on 64-bit Linux can't.
Yes, we should do this for GCC 11.
libstdc++-v3/include/std/latch | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
On Wed, 3 Mar 2021 at 15:13, Richard Earnshaw (lists)
wrote:
>
> On 03/03/2021 14:11, Christophe Lyon via Gcc-patches wrote:
> > On Wed, 3 Mar 2021 at 14:55, Richard Earnshaw (lists)
> > wrote:
> >>
> >> Hopefully this change will reduce the number of times Christophe is
> >> needing to tweak
On 03/03/2021 14:11, Christophe Lyon via Gcc-patches wrote:
> On Wed, 3 Mar 2021 at 14:55, Richard Earnshaw (lists)
> wrote:
>>
>> Hopefully this change will reduce the number of times Christophe is
>> needing to tweak the testsuite.
>>
>
> Thanks!
>
> I guess this means we can now do some
On Wed, 3 Mar 2021 at 14:55, Richard Earnshaw (lists)
wrote:
>
> Hopefully this change will reduce the number of times Christophe is
> needing to tweak the testsuite.
>
Thanks!
I guess this means we can now do some cleanup in the testsuite?
Did you have a quick look at the amount of tests
sparcv9 bootstrap has been broken for 1 1/2 years now by spurious
-Wuninitialized warnings:
In function ‘wide_int wi::max_value(unsigned int, signop)’,
inlined from ‘wide_int wi::max_value(unsigned int, signop)’ at
/vol/gcc/src/hg/master/local/gcc/wide-int.cc:330:1:
On 02/03/2021 18:35, Christophe Lyon wrote:
> On Tue, 2 Mar 2021 at 19:18, Richard Earnshaw
> wrote:
>>
>> On 02/03/2021 18:14, Richard Earnshaw via Gcc-patches wrote:
>>> On 02/03/2021 18:10, Christophe Lyon wrote:
On Tue, 2 Mar 2021 at 17:25, Richard Earnshaw
wrote:
>
> On
On 3/2/21 4:51 PM, Marek Polacek wrote:
On Mon, Mar 01, 2021 at 09:29:19PM -0500, Jason Merrill via Gcc-patches wrote:
On 3/1/21 7:59 PM, Marek Polacek wrote:
On Mon, Mar 01, 2021 at 03:08:58PM -0500, Jason Merrill wrote:
On 3/1/21 2:54 PM, Marek Polacek wrote:
On Thu, Feb 25, 2021 at
Hopefully this change will reduce the number of times Christophe is
needing to tweak the testsuite.
--
Arm processors can support up to two instruction sets. Some early
cores only support the traditional A32 (Arm) instructions, while some
more recent devices only support T32 (Thumb)
A call that is the immediate operand of decltype has special semantics: no
temporary is produced, so it's OK for the return type to be e.g. incomplete.
But we were treating (e | f) the same way, which confused overload
resolution when we then tried to evaluate ... | g.
Fixed by making build_temp
On Feb 25, 2021, Hans-Peter Nilsson wrote:
> Additional files are created in presence of @file option.
Oh, wow. I hope nobody uses @file in target board files ;-)
> gcc/testsuite:
> * gcc.misc-tests/outputs.exp: Skip @file -save-temps
> tests if target test-framework has -L or -I
On 03/03/21 13:29 +0100, Rainer Orth wrote:
The following patch updates the Solaris baselines for GCC 11.1. There's
only one caveat: comparing the Solaris 11.3 and 11.4 baselines, I find
+FUNC:_ZSt10from_charsPKcS0_RdSt12chars_format@@GLIBCXX_3.4.29
On Feb 25, 2021, Hans-Peter Nilsson wrote:
> Navigating and debugging causes for failing tests here isn't
> helped by the existence of tests with duplicate names.
Aah, I guess I see what happened: some test sets were copied to cover
additional cases I hadn't covered (cool :-), but the test
On 3/3/21 11:50 AM, Ilya Leoshkevich wrote:
> On Wed, 2021-03-03 at 07:50 +0100, Andreas Krebbel wrote:
>> On 3/2/21 11:59 PM, Ilya Leoshkevich wrote:
>>> mul-signed-overflow-*.c execution tests fail on z13, because they
>>> contain z14-specific instructions. Fix by requiring s390_z14_hw
>>>
Hi,
As subject, this patch adds tests for vcvtx* and vcvt_fXX_fXX floating-point
Neon intrinsics. Since these intrinsics are only supported for AArch64, these
tests are restricted to only run on AArch64 targets.
Ok for master?
Thanks,
Jonathan
---
gcc/testsuite/ChangeLog:
2021-02-18
On Wed, Mar 03, 2021 at 01:36:20PM +0100, Rainer Orth wrote:
> The new gcc.target/i386/pr95798-?.c tests FAIL on 64-bit Solaris/x86:
>
> +FAIL: gcc.target/i386/pr95798-1.c scan-assembler 1,
> 8(%rsp,%r[a-z0-9]*,8)
> +FAIL: gcc.target/i386/pr95798-1.c scan-assembler 2,
>
The new gcc.target/i386/pr95798-?.c tests FAIL on 64-bit Solaris/x86:
+FAIL: gcc.target/i386/pr95798-1.c scan-assembler 1,
8(%rsp,%r[a-z0-9]*,8)
+FAIL: gcc.target/i386/pr95798-1.c scan-assembler 2,
16(%rsp,%r[a-z0-9]*,8)
+FAIL: gcc.target/i386/pr95798-1.c scan-assembler 3,
Hi,
As subject, this patch adds tests for v[q]mov[u]n_high Neon intrinsics. Since
these intrinsics are only supported for AArch64, these tests are restricted
to only run on AArch64 targets.
Ok for master?
Thanks,
Jonathan
---
gcc/testsuite/ChangeLog:
2021-03-02 Jonathan Wright
*
The following patch updates the Solaris baselines for GCC 11.1. There's
only one caveat: comparing the Solaris 11.3 and 11.4 baselines, I find
+FUNC:_ZSt10from_charsPKcS0_RdSt12chars_format@@GLIBCXX_3.4.29
+FUNC:_ZSt10from_charsPKcS0_ReSt12chars_format@@GLIBCXX_3.4.29
Hi,
As subject, this patch adds tests for v[r]shrn_high Neon intrinsics. Since
these intrinsics are only supported for AArch64, these tests are restricted
to only run on AArch64 targets.
Ok for master?
Thanks,
Jonathan
---
gcc/testsuite/ChangeLog:
2021-03-02 Jonathan Wright
*
Hi,
As subject, this patch adds tests for v[r]addhn_high and v[r]subhn_high Neon
intrinsics. Since these intrinsics are only supported for AArch64, these tests
are restricted to only run on AArch64 targets.
Ok for master?
Thanks,
Jonathan
---
gcc/testsuite/ChangeLog:
2021-03-02 Jonathan
This reworks namespace serializing to avoid some issues I ran into
when working on 99170. In modules, (non-anonymous) namespaces are
strange beasts, that always have external linkage, but may have
module-specific visibility. I still don't get the latter 100%
correct, but this is in the right
*PING*
I think the patch is an improvement, even though there is a small
regression and many issues are not covered: PR fortran/99266 and as
explained below.
On 25.02.21 12:16, Tobias Burnus wrote:
The issue is that for CLASS – and in particular CLASS(*)
the ts.u.derived->components is not yet
Rather obvious change – don't apply replacement multiple times.
OK for mainline?
Tobias
-
Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank
Thürauf
Fortran: Fix -freal-{4,8}-real*
> LGTM.
Thanks. However, I overlooked an issue with pathologically large frames
(larger than SEH_MAX_FRAME_SIZE, i.e. 2GB and for which we cannot emit CFI
directives) that is visible in the gnat.dg testsuite under the form of an ICE.
Tested on x86_64-w64-mingw32, applied on mainline/10/9
>
> libgcc/ChangeLog:
>
> PR gcov-profile/99105
> * libgcov-driver.c (write_top_counters): Rename to ...
> (write_topn_counters): ... this.
> (write_one_data): Pre-allocate buffer for number of items
> in the corresponding linked lists.
> * libgcov-merge.c
> Hello.
>
> AS mentioned here, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97461#c25, I
> like
> what Richard suggested. So instead of usage of malloc, we should use mmap
> memory
> chunks that serve as a memory pool for struct gcov_kvp.
>
> Malloc is used as a fallback when mmap is not
On Wed, 2021-03-03 at 07:50 +0100, Andreas Krebbel wrote:
> On 3/2/21 11:59 PM, Ilya Leoshkevich wrote:
> > mul-signed-overflow-*.c execution tests fail on z13, because they
> > contain z14-specific instructions. Fix by requiring s390_z14_hw
> > target.
> >
> > gcc/testsuite/ChangeLog:
> >
> >
1 - 100 of 102 matches
Mail list logo
