One more backport I've just tested.
Martin
>From 1740f6453356fec7926e360b3a379ca0fa80a1da Mon Sep 17 00:00:00 2001
From: Tom de Vries
Date: Fri, 5 Feb 2021 10:36:38 +0100
Subject: [PATCH] debug: fix switch lowering debug info
gcc/ChangeLog:
PR debug/98656
* tree-switch-conversion.c (jump_tab
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 happened to suppress th
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:
> >
> >
> 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
>
> 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
> 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
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
*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
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
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
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.
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[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 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\\\
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-
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 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
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 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:
> 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
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
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)
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
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/
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 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
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 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 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 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:
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 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
> 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 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
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 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 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 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 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
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 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
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 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
> -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]
> -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: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: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
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
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 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 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, 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 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
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 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
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 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 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, 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 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, 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
> >
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 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
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 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 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
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
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
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
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
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:
>
>
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 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 (
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, 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
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
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 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
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 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
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 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
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 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
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 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 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 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, 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
[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 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
> 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 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
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 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
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
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
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, 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 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
1 - 100 of 102 matches
Mail list logo
