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, while
>
> 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 -mcompac
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 ci
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: Tho
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 machine
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 aarch64_declare_function_na
> 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:
> > >
> > > --- ou
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 ha
[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 variabl
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.
> > * gcc.target/mips/compact-bran
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 othe
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
> si
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 th
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 -mcompact-branches=a
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 Nat
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 follow
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, I
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 causes
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 p
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
> > https://gcc.gnu.org/pipermail/gcc-patches/2021-Janu
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
enabli
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, ap
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
> -mno-powerpc-g
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, we've
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:
std::ranges::reverse_vie
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 contrib
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 suppor
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 war
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 lo
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 be
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 EINTR
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 s
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 lea
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.
W
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 wr
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 (pp
> -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 floating-point
> -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 intrins
> -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. S
> -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 v[r]
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
o
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 dia
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 @@
#inc
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 demo
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 wrote
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 p
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 Schw
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
> > > > w
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 li
> 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 warni
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, t
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 now).
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 us
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 a/libstdc++-v3/include/std
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 the
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 clean
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 involv
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:
/vol/gcc/src/hg/master/loc
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 02/
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 10:45:2
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 d
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 o
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
+FUNC:_ZSt10from_charsPKcS0_ReSt12chars_forma
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 names
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
>>> targe
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 Jonathan
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,
> 16(%rsp,%r[a-
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,
24\\\
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
* g
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
+FUNC:_ZSt10from_charsPKcS0_
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
* gcc.
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 Wrig
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 dir
*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* han
> 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 branc
>
> 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 (__g
> 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 avail
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
