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
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, 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
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
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
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
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
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_
> 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
> 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
> 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
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
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 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 -
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 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
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
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].
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,
PR ada/103538
* Makefile.rtl (LIBGNAT_TARGET_PAIRS): Add
$(TRASYM_DWARF_UNIX_PAIRS),
s-tsmona.adb
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
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
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
> 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
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.
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
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 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
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/
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
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, 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
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
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
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 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
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 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!
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
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
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
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 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 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 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
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 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
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 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 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
Hi!
On Tue, Jan 18, 2022 at 12:51:39PM +0100, Sebastian Huber wrote:
> For some CPUs, the assembler machine directive cannot be determined by ISA
> flags.
That may be the best we can do here, with the current setup, yes.
> PR 104090/target
> * config/rs6000/rs6000.cc (rs6000_machine_
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/powerpc/pr104015-2.c: New test.
> OK for the target-in
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, which at output time is concatenated onto
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 install?
This is OK.
Thanks for the
[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, which at output time is concatenated onto the end
of the standar
[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 install?
Thanks.
gcc/ChangeLog:
* config/bpf/core
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r12-6700-g2aefe248aa4160205c44808166393a42031d2dea.
gcc/analyzer/ChangeLog:
PR analyzer/104089
* region-model-manager.cc
(region_model_manager::get_or_create_constant_svalue): Assert that
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r12-6699-g79e746bb05e432dcd1c18161469272d67c33d79d.
gcc/analyzer/ChangeLog:
PR analyzer/104062
* region-model-manager.cc
(region_model_manager::maybe_fold_sub_svalue): Avoid casting to
On Tue, 18 Jan 2022 at 20:01, Patrick Palka wrote:
> On Tue, 18 Jan 2022, Patrick Palka wrote:
>
> > On Tue, Jan 18, 2022 at 5:12 AM Jonathan Wakely
> wrote:
> > >
> > > Tested x86_64-linux, pushed to trunk.
> > >
> > >
> > > Instead of hardcoded preprocessor conditionals with explicit target
>
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, which at output time is concatenated onto the end
of the standard strtab.
Previously, these string offsets were computed at the time the
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 install?
Thanks
gcc/ChangeLog:
* config/bpf/coreout.c (output_btfext_header): Account for
4-byte record size in cor
Tested powerpc64le-linux, pushed to trunk.
The new deleted constructors added by P2166R1 are a breaking change,
making previously valid code ill-formed in C++23. As a result, they
should only be defined for C++23 and not for C++11 and up.
libstdc++-v3/ChangeLog:
PR libstdc++/104099
On 1/18/22 13:06, Martin Sebor wrote:
On 1/18/22 06:37, Richard Sandiford wrote:
In this PR the waccess pass was fed:
D.10779 ={v} {CLOBBER};
VIEW_CONVERT_EXPR(D.10779) = .MASK_LOAD_LANES
(addr_5(D), 64B, _2);
_7 = D.10779.__val[0];
However, the tracking of m_clobbers only looked at
On Tue, Jan 18, 2022 at 02:44:34PM -0500, Patrick Palka via Gcc-patches wrote:
> On Tue, Jan 18, 2022 at 5:12 AM Jonathan Wakely wrote:
> >
> > Tested x86_64-linux, pushed to trunk.
> >
> >
> > Instead of hardcoded preprocessor conditionals with explicit target
> > checks, just rely on the fact th
On Tue, 18 Jan 2022, Patrick Palka wrote:
> On Tue, Jan 18, 2022 at 5:12 AM Jonathan Wakely wrote:
> >
> > Tested x86_64-linux, pushed to trunk.
> >
> >
> > Instead of hardcoded preprocessor conditionals with explicit target
> > checks, just rely on the fact that __BYTE_ORDER__ is always defined
On Tue, Jan 18, 2022 at 5:12 AM Jonathan Wakely wrote:
>
> Tested x86_64-linux, pushed to trunk.
>
>
> Instead of hardcoded preprocessor conditionals with explicit target
> checks, just rely on the fact that __BYTE_ORDER__ is always defined by
> GCC.
Thanks a lot for fixing these! I apparently m
On Wed, 19 Jan 2022, Kito Cheng wrote:
> LGTM, thanks :)
>
> > Avoid undefined arithmetic involving a pointer to a heap allocation that
> > has been freed and move a problematic calculation ahead of the following
> > call to `free' in `riscv_subset_list::parse_multiletter_ext', removing a
> > com
Am 17.01.22 um 22:26 schrieb Martin Liška:
On 1/12/22 16:54, Martin Liška wrote:
There's a patch that enhances git-backport so that it updates commit
messages for files which name ends now with .cc and is still .c on a branch.
The patch has been installed as I've made the renaming now.
Chee
On 1/18/22 11:08, Patrick Palka wrote:
We're incorrectly rejecting the below testcase during template argument
coercion because invalid_nontype_parm_type_p returns true for
DEPENDENT_OPERATOR_TYPE.
This patch fixes this by partially rewriting invalid_nontype_parm_type_p
in terms of WILDCARD_TYPE
On 14/01/2022 09:57, Richard Biener wrote:
The 'used_vector_modes' is also a heuristic by itself since it registers
every vector type we query, not only those that are used in the end ...
So it's really all heuristics that can eventually go bad.
IMHO remembering the VF that we ended up with (
On 1/18/22 06:37, Richard Sandiford wrote:
In this PR the waccess pass was fed:
D.10779 ={v} {CLOBBER};
VIEW_CONVERT_EXPR(D.10779) = .MASK_LOAD_LANES (addr_5(D),
64B, _2);
_7 = D.10779.__val[0];
However, the tracking of m_clobbers only looked at gassigns,
so it missed that the clobber
This patch introduced new AIX testsuite failures.
PR libstdc++/104101
Thanks, David
For this testcase, the cleanup that is supposed to happen if initialization
throws was wrongly being run on the normal control path as well. This turns
out to be because the EH-only handling in gimple_push_cleanup didn't apply
to conditional cleanups such as we have for nothrow new, since we check
On Tue, Jan 18, 2022 at 05:21:30PM +0100, Martin Liška wrote:
> I'm going to install the following -Wformat-diag that is based on Segher's
> wording.
Thanks!
(But please fix the format=flawed:
> Content-Type: text/plain; charset=UTF-8; format=flowed
)
Segher
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
recent discussion at the psABI specification [1] for more details.
It would be better to reject these in
Aligne __EH_FRAME_BEGIN__ to pointer size since gcc/unwind-dw2-fde.h has
/* The first few fields of a CIE. The CIE_id field is 0 for a CIE,
to distinguish it from a valid FDE. FDEs are aligned to an addressing
unit boundary, but the fields within are unaligned. */
struct dwarf_cie
{
uwo
LGTM, thanks :)
On Wed, Jan 19, 2022 at 12:59 AM Maciej W. Rozycki wrote:
>
> Avoid undefined arithmetic involving a pointer to a heap allocation that
> has been freed and move a problematic calculation ahead of the following
> call to `free' in `riscv_subset_list::parse_multiletter_ext', removin
Avoid undefined arithmetic involving a pointer to a heap allocation that
has been freed and move a problematic calculation ahead of the following
call to `free' in `riscv_subset_list::parse_multiletter_ext', removing a
compilation error:
.../gcc/common/config/riscv/riscv-common.cc: In member fu
On 1/18/22 11:40, Jakub Jelinek wrote:
On Tue, Jan 18, 2022 at 11:25:38AM -0500, Jason Merrill wrote:
Can you please comment on https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86369#c1
then?
Done.
Thanks.
About the rest of the patch, I thought I had seen richi comment on IRC (but
can't find t
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 cxx_eval_outermost_constant_expr
it triggers the:
else if (TREE_CODE (t)
On 1/18/22 17:36, Thomas Schwinge wrote:
Similar here: '%'.
Grüße
Thomas
I see, thank you for the review.
Can you please test for me the following patch candidate?
Thanks,
MartinFrom de5cafe27131c002e6634dd7417577452eb1aac8 Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Tue, 18 Jan 20
On Tue, Jan 18, 2022 at 11:25:38AM -0500, Jason Merrill wrote:
> > Can you please comment on
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86369#c1
> > then?
>
> Done.
Thanks.
> About the rest of the patch, I thought I had seen richi comment on IRC (but
> can't find the comment now) that the
Tested powerpc64le-linux, pushed to trunk.
libstdc++-v3/ChangeLog:
* include/bits/stl_function.h (ptr_fun): Fix suggestion for
non-deprecated alternative.
---
libstdc++-v3/include/bits/stl_function.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libstdc
Tested powerpc64le-linux, pushed to trunk.
This adds the C++23 header, as proposed by P0943R6, for
compatibility with C code.
There are still some ABI differences between atomic_xxx in C and C++
std::atomic_xxx in C++, so this only provides source compatibility, not
binary compatibility.
libst
From: Tom Honermann
Tested powerpc64le-linux, pushed to trunk.
This patch completes implementation of the C++20 proposal P0482R6 [1] by
adding declarations of std::c8rtomb() and std::mbrtoc8() in if
provided by the C library in .
This patch addresses feedback provided in response to a previou
Tested powerpc64le-linux, pushed to trunk.
We should not assume that std::iter_value_t etc. are defined
unconditionally for C++20 mode.
libstdc++-v3/ChangeLog:
PR libstdc++/104098
* include/bits/stl_iterator.h (reverse_iterator): Check
__cpp_lib_concepts instead of __cpl
Tested powerpc64le-linux, pushed to trunk.
The deprecated non-standard std::pair constructors that allow
constructing std::pair from an rvalue and
a literal zero where not sufficiently constrained. They were viable when
constructing std::pair, and that case
should work fine using the standard con
On Tue, 18 Jan 2022 08:31:12 PST (-0800), gcc-patches@gcc.gnu.org wrote:
Thanks Martin!
Yep. Seeing this go by, though, I think there's some English issues
with the original messages. I'd write it more like this, but I'm never
100% sure on these things:
diff --git a/gcc/common/config/r
Hi Martin!
On 2022-01-18T17:22:53+0100, Martin Liška wrote:
> Pushed as pre-approved by Jeff. The patch fixes -Wformat-diag warnings.
> --- a/gcc/config/nvptx/nvptx.cc
> +++ b/gcc/config/nvptx/nvptx.cc
> @@ -5894,7 +5894,7 @@ nvptx_goacc_validate_dims_1 (tree decl, int dims[], int
> fn_level, u
Thanks Martin!
On Wed, Jan 19, 2022 at 12:23 AM Martin Liška wrote:
>
> Pushed as pre-approved by Jeff. The patch fixes -Wformat-diag warnings.
>
> Martin
>
> gcc/ChangeLog:
>
> * common/config/riscv/riscv-common.cc (riscv_subset_list::add):
> Wrap keywords with quotes and remove
On 1/16/22 01:31, Martin Sebor wrote:
Hello.
(I think your message in unrelated to this email thread).
Martin, I've looked into removing the -Wno-error for this warning
for just a subset of targets. It seems doable with some hardcoding
in configure.ac but if you're planning to do the cleanup
On 1/18/22 05:17, Jakub Jelinek wrote:
On Thu, Jan 13, 2022 at 04:18:33PM -0500, Jason Merrill wrote:
Note, address_compare has some special cases, e.g. it assumes that
static vars are never adjacent to automatic vars, which is the case
for the usual layout where automatic vars are on the stack
Pushed as pre-approved by Jeff. The patch fixes -Wformat-diag warnings.
Martin
gcc/ChangeLog:
* config/vms/vms-c.cc (vms_pragma_nostandard): Fix -Wformat-diag
warning.
(vms_pragma_standard): Likewise.
(vms_pragma_extern_prefix): Likewise.
---
gcc/config/vms/vms-
Pushed as pre-approved by Jeff. The patch fixes -Wformat-diag warnings.
Martin
gcc/ChangeLog:
* config/xtensa/xtensa.cc (print_operand): Fix warnings.
(print_operand_address): Likewise.
(xtensa_multibss_section_type_flags): Likewise.
---
gcc/config/xtensa/xtensa.cc | 6
Pushed as pre-approved by Jeff. The patch fixes -Wformat-diag warnings.
Martin
gcc/ChangeLog:
* config/v850/v850-c.cc (pop_data_area): Fix -Wformat-diag
warning.
(ghs_pragma_section): Likewise.
(ghs_pragma_interrupt): Likewise.
(ghs_pragma_starttda): Like
Pushed as pre-approved by Jeff. The patch fixes -Wformat-diag warnings.
Martin
gcc/ChangeLog:
* config/nds32/nds32-intrinsic.cc (nds32_expand_builtin_impl):
Fix warnings.
* config/nds32/nds32-intrinsic.md: Likewise.
* config/nds32/nds32-isr.cc (nds32_check_isr_at
Pushed as pre-approved by Jeff. The patch fixes -Wformat-diag warnings.
Martin
gcc/ChangeLog:
* config/nvptx/nvptx.cc (nvptx_goacc_validate_dims_1): Wrap
keyword.
* config/nvptx/nvptx.md: Remove trailing dot.
libgomp/ChangeLog:
* testsuite/libgomp.oacc-c++/priv
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 for a put operation which can end up
re-allocating that before rea
Pushed as pre-approved by Jeff. The patch fixes -Wformat-diag warnings.
Martin
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc (riscv_subset_list::add):
Wrap keywords with quotes and remove trailing dots.
(riscv_subset_list::parsing_subset_version): Likewise.
Hello.
The patch fixes -Wformat-diag in various targets.
I'm going to install the patch based on Jeff's pre-approval of similar patches.
Martin
gcc/ChangeLog:
* collect2.cc (scan_libraries): Fix -Wformat-diag issues.
* config/aarch64/aarch64-builtins.cc (aarch64_simd_expand_bui
1 - 100 of 166 matches
Mail list logo
