On 1/18/22 13:17, Jose E. Marchesi wrote:
Hi David.
[Changed from v1: Adjust to account for file renaming so patch applies.]
The CO-RE relocation record size should be written only once in the
.BTF.ext section, not once for each section with relocations.
Tested for bpf-unknown-none. OK to
On 1/18/22 13:18, Jose E. Marchesi wrote:
Hi David.
[Changed from v1: Adjust to account for file renaming so patch applies.]
BPF CO-RE relocations contain offsets to strings buffered in the BTF
string table. These BTF-specific strings are stored in memory in the
CTF auxilliary strtab, whic
On Tue, 2 Nov 2021 at 01:26, Thomas Rodgers wrote:
> This should address Jonathan's feedback and adds support for atomic_ref
>
>This change implements P0528 which requires that padding bits not
>participate in atomic compare exchange operations. All arguments to the
>generic template are 'sanit
On Tue, 18 Jan 2022, Martin Liška wrote:
> @@ -3309,8 +3309,8 @@ riscv_handle_type_attribute (tree *node
> ATTRIBUTE_UNUSED, tree name, tree args,
> && strcmp (string, "machine"))
> {
> warning (OPT_Wattributes,
> -"argument to %qE attribute is
Debug information was getting confused because input_location was different
depending on whether we had looked ahead to see if the next tokens look like
a template argument list.
I tried resetting input_location in cp_lexer_rollback_tokens itself, but
that caused regressions, so let's just do it h
On Mon, 2022-01-17 at 19:30 -0500, Antoni Boucher via Gcc-patches
wrote:
> I was missing the define, so I added it.
> Here's the new patch with it.
Thanks for the patch.
> Le lundi 17 janvier 2022 à 17:18 -0500, Antoni Boucher via Jit a
> écrit :
> > Hi.
> > This patch add support for bitcasts in
On Tue, Jan 18, 2022 at 11:51:31AM -0500, Jason Merrill wrote:
> On 1/18/22 09:26, Jakub Jelinek wrote:
> > On Tue, Jan 18, 2022 at 09:08:03AM -0500, Jason Merrill wrote:
> > > > which makes call a TARGET_EXPR with the dtor in TARGET_EXPR_CLEANUP,
> > > > but then call cxx_constant_value on it. In
On Tue, Jan 18, 2022 at 05:56:47PM -0500, Jason Merrill wrote:
> Debug information was getting confused because input_location was different
> depending on whether we had looked ahead to see if the next tokens look like
> a template argument list.
>
> I tried resetting input_location in cp_lexer_r
On Mon, 2022-01-17 at 21:02 -0500, Antoni Boucher via Gcc-patches
wrote:
> Hi.
> This option will be useful for rustc_codegen_gcc to hide the error
> about unsupported 128-bit integer types.
>
> David, if you know of a better way to check if these types are
> supported than creating such a type an
On 1/18/22 18:07, Jakub Jelinek wrote:
On Tue, Jan 18, 2022 at 11:51:31AM -0500, Jason Merrill wrote:
On 1/18/22 09:26, Jakub Jelinek wrote:
On Tue, Jan 18, 2022 at 09:08:03AM -0500, Jason Merrill wrote:
which makes call a TARGET_EXPR with the dtor in TARGET_EXPR_CLEANUP,
but then call cxx_con
From: Andrew Pinski
It was pointed out to me by Jakub, that the comment in front of
the new code which handles warning/error attribute was not really
understandable. This fixes the comment to be understandable; I
don't know why I wrote the original comment that way even.
Committed as obvious aft
Hi!
This is a non-C++ related part from the PR89074 address_compare changes.
For "foo" == "foo" we already optimize this from the (cmp @0 @0)
simplification, because we use operand_equal_p in that case
and operand_equal_p also compares the STRING_CSTs bytes rather than
just addresses.
Bootstrappe
On Mon, 2022-01-17 at 19:46 -0500, Antoni Boucher via Gcc-patches
wrote:
> I missed the comment about the new define, so here's the updated
> patch.
Thanks for the patch.
>
> Le lundi 17 janvier 2022 à 19:24 -0500, Antoni Boucher via Jit a
> écrit :
> > Hi.
> > This patch add supports for registe
Hi!
As reported in the PR or as I've seen since the weekend, asan_test.C fails
because of many warnings like:
/home/jakub/src/gcc/gcc/testsuite/g++.dg/asan/asan_test.cc:1157:10: error:
using a dangling pointer to an unnamed temporary [-Werror=dangling-pointer=]
/home/jakub/src/gcc/gcc/testsuite/g
On Sun, Jan 16, 2022 at 12:22:18PM +0800, Hongtao Liu via Gcc-patches wrote:
> On Sun, Jan 16, 2022 at 12:44 AM Uros Bizjak via Gcc-patches
> wrote:
> >
> > On Sat, Jan 15, 2022 at 5:39 PM Hongyu Wang wrote:
> > >
> > > Thanks for the suggestion, here is the updated patch that survived
> > > boot
On 1/18/22 16:56, Jakub Jelinek wrote:
Hi!
As reported in the PR or as I've seen since the weekend, asan_test.C fails
because of many warnings like:
/home/jakub/src/gcc/gcc/testsuite/g++.dg/asan/asan_test.cc:1157:10: error:
using a dangling pointer to an unnamed temporary [-Werror=dangling-poin
On Mon, Jan 17, 2022 at 2:29 AM Martin Liška wrote:
>
> Hi.
>
> The patch is about factoring out a function similar to
> check_effective_target_python3.
>
> Cheers,
> Martin
>
> gcc/testsuite/ChangeLog:
>
> * lib/gcov.exp: Use check_effective_target_pytest3.
> * lib/target-support
Sorry for introducing such failure and thanks for the patch, I suppose it could
be treated as obvious fix?
发件人: Jakub Jelinek
发送时间: 星期三, 一月 19, 2022 8:01 上午
收件人: Hongtao Liu; Uros Bizjak
抄送: gcc-patches@gcc.gnu.org; Wang, Hongyu
主题: [PATCH] i386: Fix GLC tuning wi
Tested powerpc64le-linux, powerpc-aix, pushed to trunk.
This fixes a testsuite failure on AIX.
The lock function currently just spins, which should be changed to use
back-off, and maybe then _M_val.wait(__current) when supported.
libstdc++-v3/ChangeLog:
PR libstdc++/104101
* in
Tested powerpc64le-linux. pushed to trunk.
This function is no longer used since r12-6691 and can be removed.
libstdc++-v3/ChangeLog:
* include/bits/stl_pair.h (_PCC::_DeprConsPair): Remove unused
function.
---
libstdc++-v3/include/bits/stl_pair.h | 14 --
1 file ch
Tested powerpc64le-linux, pushed to trunk.
This was deprecated in C++17, not C++14.
libstdc++-v3/ChangeLog:
* include/bits/stl_tempbuf.h (get_temporary_buffer): Change
_GLIBCXX14_DEPRECATED to _GLIBCXX17_DEPRECATED.
---
libstdc++-v3/include/bits/stl_tempbuf.h | 2 +-
1 file cha
Pushed to trunk.
libstdc++-v3/ChangeLog:
* doc/xml/manual/evolution.xml: Document deprecations.
* doc/xml/manual/status_cxx2017.xml: Update status.
* doc/html/*: Regenerate.
---
libstdc++-v3/doc/html/manual/api.html | 10 ++
libstdc++-v3/doc/html/manual/
The new pointer_related_p() utility function added for -Wuse-after-free
is documented to conservatively return false when it cannot determine
relatedness but actually returns true. That has caused the false
positive reported in PR 104069. In r12-6712 I've committed as obvious
a fix for this mist
On Wed, Jan 19, 2022 at 8:00 AM Jakub Jelinek wrote:
>
> On Sun, Jan 16, 2022 at 12:22:18PM +0800, Hongtao Liu via Gcc-patches wrote:
> > On Sun, Jan 16, 2022 at 12:44 AM Uros Bizjak via Gcc-patches
> > wrote:
> > >
> > > On Sat, Jan 15, 2022 at 5:39 PM Hongyu Wang
> > > wrote:
> > > >
> > > >
The regression test gcc.dg/torture/pr57147-2.c triggers a valid
warning by passing a variable with zero size to a function that
expects an array of size 1. The recent change to run the access
pass also earlier in the optimization pipeline has triggered
this warning. In r12-6713 I have committed
A -Wdangling-pointer false positive reported just the other day
on this list has disappeared after an unrelated change to
the gimplifier (r12-6694). In r12-6714 I've committed the regression
test for it, though I'm not sure I see what the warning code could
have done to avoid the false positive.
> From: Jonathan Wakely via Gcc-patches
> Date: Wed, 19 Jan 2022 02:03:58 +0100
> Tested powerpc64le-linux, powerpc-aix, pushed to trunk.
>
>
> This fixes a testsuite failure
I'm guessing the actual number is in the tens.
> on AIX.
...and by the looks of it, some 60 regressions (as counted
b
This patch happens to fix the PR, but I believe it only papers over a
deeper issue that is uncovered in PR104067.
That said, examination of the issue uncovered an oversight in the way
equivalence sets are merged by the equivalence oracle. I have not seen
an instance via the ranger, but I susp
Hi!
On Wed, Jan 19, 2022 at 09:09:41AM +0800, Hongtao Liu wrote:
> > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> Yes, thanks.
Thanks. Committed.
grep '{[^|}]*}"' *.md
found another spot, though dunno if we have sufficient effective targets
etc. to add an -masm=intel t
On Wed, Jan 19, 2022 at 9:40 AM Jakub Jelinek wrote:
>
> Hi!
>
> On Wed, Jan 19, 2022 at 09:09:41AM +0800, Hongtao Liu wrote:
> > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> > Yes, thanks.
>
> Thanks. Committed.
> grep '{[^|}]*}"' *.md
>
> found another spot, though d
PR ada/103538
* Makefile.rtl (LIBGNAT_TARGET_PAIRS): Add
$(TRASYM_DWARF_UNIX_PAIRS),
s-tsmona.adb
Since the x86_64-linux-gnux32 compiler is actually an x32 compiler, set
target_cpu to x32 for x86_64-linux-gnux32.
PR ada/103538
* gcc-interface/Makefile.in (target_cpu): Set to x32 for
x86_64-linux-gnux32.
---
gcc/ada/gcc-interface/Makefile.in | 7 +++
1 file changed,
Gentile ping for this again.
Could someone please give me a quick reply first? :), thanks.
Link: https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586204.html
Shadow Call Stack can be used to protect the return address of a
function at runtime, and clang already supports this feature[1].
LGTM, thanks for adding those comments :)
On Wed, Jan 19, 2022 at 1:21 AM Palmer Dabbelt wrote:
>
> The code generated by -mcmodel=medany is defined to be
> position-independent, but is not guaranteed to function correctly when
> linked into position-independent executables or libraries. See the
On 1/18/22 18:20, Jakub Jelinek wrote:
On Tue, Jan 18, 2022 at 05:56:47PM -0500, Jason Merrill wrote:
Debug information was getting confused because input_location was different
depending on whether we had looked ahead to see if the next tokens look like
a template argument list.
I tried resett
On Linux/x86_64,
2aa184458a11a7ec8c1b451b8eeff458a24632bb is the first bad commit
commit 2aa184458a11a7ec8c1b451b8eeff458a24632bb
Author: Jason Merrill
Date: Mon Jan 17 17:16:38 2022 -0500
c++: input_location and lookahead [PR104025]
caused
FAIL: g++.dg/warn/pr104025.C -std=gnu++14 (tes
On Linux/x86_64,
fdd6d85bd75df9a97659220373b5c1e8b3019e26 is the first bad commit
commit fdd6d85bd75df9a97659220373b5c1e8b3019e26
Author: Jason Merrill
Date: Tue Jan 18 17:43:03 2022 -0500
c++: Use -std=c++20 in testsuite default std list
caused
FAIL: g++.dg/cpp0x/constexpr-compare2.C -
Hello Andrew,
I updated the patch. Please see attached patch files and let me know your
feedback.
Thanks,
Sundeep K.
-Original Message-
From: Andrew Pinski
Sent: Tuesday, January 18, 2022 9:22 AM
To: sundeep.kokko...@gmail.com
Cc: GCC Patches
Subject: Re: [PATCH] Fix for GCC '-MF'
on 2022/1/19 上午5:34, Segher Boessenkool wrote:
> On Tue, Jan 18, 2022 at 11:57:32AM +, Richard Sandiford wrote:
>> "Kewen.Lin" writes:
PR tree-optimization/104015
* gcc.dg/vect/slp-perm-9.c: Adjust.
* gcc.target/powerpc/pr104015-1.c: New test.
* gcc.target/power
> Am 19.01.2022 um 00:50 schrieb Jakub Jelinek via Gcc-patches
> :
>
> Hi!
>
> This is a non-C++ related part from the PR89074 address_compare changes.
> For "foo" == "foo" we already optimize this from the (cmp @0 @0)
> simplification, because we use operand_equal_p in that case
> and opera
> Am 19.01.2022 um 01:04 schrieb Martin Sebor via Gcc-patches
> :
>
> On 1/18/22 16:56, Jakub Jelinek wrote:
>> Hi!
>> As reported in the PR or as I've seen since the weekend, asan_test.C fails
>> because of many warnings like:
>> /home/jakub/src/gcc/gcc/testsuite/g++.dg/asan/asan_test.cc:115
> your description above hints at that the actual modes involved in the
> vec_pack_sbool_trunc are the same so the TYPE_MODE (narrow_vectype)
> and TYPE_MODE (vectype) are not the actual modes participating. I think
> it would be way better to fix that.
>
> I suppose that since we know TYPE_VECTOR
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2022-January/587635.html
BR,
Kewen
on 2022/1/5 下午3:34, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> This patch is to fix the inconsistent behaviors for non-LTO mode
> and LTO mode. As Martin pointed out, currently the function
> rs6000_
PR testsuite/104109
gcc/testsuite/ChangeLog:
* lib/gcov.exp: Fix pytest detection unsupported message.
---
gcc/testsuite/lib/gcov.exp | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/gcc/testsuite/lib/gcov.exp b/gcc/testsuite/lib/gcov.exp
index 6c57515e22
On 18/01/2022 22:42, Segher Boessenkool wrote:
+default:
+ break;
Please don't do that. You can do
default:
break;
break;
/* And just to make sure: */
break;
break;
and it will do exactly the same as not having a default at all. Not
having such useless c
Hi,
This patch adds a combine pattern for "CA minus one". As CA only has two
values (0 or 1), we could convert following pattern
(sign_extend:DI (plus:SI (reg:SI 98 ca)
(const_int -1 [0x]
to
(plus:DI (reg:DI 98 ca)
(const_int -1 [0xfff
The desired transform requires V2SI vector add support, the closest
we have is vect64 so check that which at least fixes the i?86 fail.
Tested on x86_64-unknown-linux-gnu, pushed.
2022-01-19 Richard Biener
PR testsuite/102833
* gcc.dg/vect/bb-slp-17.c: Require vect64.
---
gcc
On Tue, 18 Jan 2022, Martin Sebor wrote:
> On 1/18/22 01:36, Richard Biener wrote:
> > On Mon, 17 Jan 2022, Martin Sebor wrote:
> >
> >> On 1/17/22 07:32, Richard Biener via Gcc-patches wrote:
> >>> The warning control falls into the C++ trap of using a reference
> >>> to old hashtable contents f
Hi!
On 2022-01-18T17:51:31+0100, Martin Liška wrote:
> Can you please test for me the following patch candidate?
Thanks. I additionally fixed up 'num_workers' in test cases, and then
pushed to master branch commit 2aea19bdb12308aac1519ffc5ecc9d1ec24f9cc5
"nvptx: update fix for -Wformat-diag", s
On Tue, Jan 18, 2022 at 11:13 PM HAO CHEN GUI via Gcc-patches
wrote:
>
> Hi,
>This patch adds a combine pattern for "CA minus one". As CA only has two
> values (0 or 1), we could convert following pattern
> (sign_extend:DI (plus:SI (reg:SI 98 ca)
> (const_int -1 [0xff
on 2022/1/18 上午11:06, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> As discussed in PR104015, the test case slp-perm-9.c can be
> fragile when vectorizer tries to use different vectorisation
> strategies.
>
> As Richard suggested, this patch tries to make the check not
> sensitive on the re-trying t
On 1/18/22 08:59, Thomas Schwinge wrote:
Hi!
On 2022-01-10T17:14:00+0100, Martin Liška wrote:
The script is capable of checking if MAINTAINER names are sorted
alphabetically.
Irrespective of the pre-existing issue that a concept of a first and a
last name doesn't exist in all cultures, and t
On Mon, Jan 17, 2022 at 09:08:22PM -0800, Andrew Pinski wrote:
> > Perhaps even
> > /* Check builtins that prevent splitting. */
> > if (gimple_code (stmt) == GIMPLE_CALL)
> > if (tree decl = gimple_call_fndecl (stmt))
> > {
> > if (fndecl_built_in_p (decl
Pushed as obvious.
Martin
gcc/testsuite/ChangeLog:
* gcc.misc-tests/options.exp: Include renamed file.
---
gcc/testsuite/gcc.misc-tests/options.exp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.misc-tests/options.exp
b/gcc/testsuite/gcc.misc-tes
Martin,
> The renaming patches have been just installed and I've built a few target
> compilers so far. I'll be online in ~10 hours from now so I can address
> potential issues caused by the patch.
Who approved it though? The renaming of the C files in the ada/ directory is
wrong and should be
On Mon, 17 Jan 2022, Martin Sebor wrote:
> On 1/17/22 07:32, Richard Biener via Gcc-patches wrote:
> > The warning control falls into the C++ trap of using a reference
> > to old hashtable contents for a put operation which can end up
> > re-allocating that before reading from the old freed refere
On 1/18/22 09:36, Eric Botcazou wrote:
Martin,
The renaming patches have been just installed and I've built a few target
compilers so far. I'll be online in ~10 hours from now so I can address
potential issues caused by the patch.
Who approved it though?
Release managers.
The renaming of
On Mon, Jan 17, 2022 at 7:20 PM Sandra Loosemore
wrote:
>
> On 1/17/22 1:29 AM, Richard Biener wrote:
> > On Mon, Jan 17, 2022 at 4:15 AM Sandra Loosemore
> > wrote:
> >>
> >> On 1/8/22 9:24 PM, Sandra Loosemore wrote:
> >>> This patch fixes the ICE I reported in PR103163. We were initializing
>
> Release managers.
They certainly have authority on the timing, but not on the contents.
> Working on that right now, sorry..
OK, thanks in advance.
--
Eric Botcazou
On Mon, Jan 17, 2022 at 8:56 PM Andrew MacLeod via Gcc-patches
wrote:
>
> As mentioned in the PR, this demonstrates the potentially quadratic
> performance behaviour of adding transitive relations over a series of
> cascading calculations.
>
> As the lookup in a basic block is also linear in natur
On Tue, Jan 18, 2022 at 9:46 AM Eric Botcazou via Gcc-patches
wrote:
>
> > Release managers.
>
> They certainly have authority on the timing, but not on the contents.
Technically all release managers are also global reviewers, but I
agree the speciality
of the Ada setup (esp. the runtime being in
From: LiaoShihua
When I built riscv-gcc with newlib, it will be terminated with message "fatal
error: endian.h: No such file or directory".
So, fixed it in fast_float.h.
libstdc++-v3\ChangeLog:
* src/c++17/fast_float/fast_float.h (defined):fast_float.h will include
with using newlib
On 1/18/22 09:53, Richard Biener wrote:
Technically all release managers are also global reviewers, but I
agree the speciality
of the Ada setup (esp. the runtime being in gcc/) could have been anticipated.
Yeah, I thought that building Ada FE is enough for testing effort, sorry.
I would like t
On Tue, Jan 18, 2022 at 10:08:20AM +0100, Martin Liška wrote:
> On 1/18/22 09:53, Richard Biener wrote:
> > Technically all release managers are also global reviewers, but I
> > agree the speciality
> > of the Ada setup (esp. the runtime being in gcc/) could have been
> > anticipated.
>
> Yeah, I
On Tue, Jan 18, 2022 at 7:26 AM liuhongt wrote:
>
> For testcase in PR, the patch supports QI:4 -> HI:16 pack with
> multi steps(first pack QI:4 -> QI:8 through vec_pack_sbool_trunc_qi,
> then pack QI:8 -> HI:16 through vec_pack_trunc_hi).
> Similar for QI:2 -> HI:16 which is test4 in mask-pack-pr
Since we order DRs after DR_INIT we know the difference will be
positive and thus can avoid signed overflow issues by using
unsigned arithmetic to produce the known unsigned result.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2022-01-18 Richard Biener
PR tree-optimiza
101 - 166 of 166 matches
Mail list logo
