These patterns result in non-atomic sequence.
2021-07-21 Uroš Bizjak
gcc/
PR target/100182
* config/i386/sync.md (define_peephole2 atomic_storedi_fpu):
Remove.
(define_peephole2 atomic_loaddi_fpu): Ditto.
gcc/testsuite/
PR target/100182
* gcc.target/i386/pr71245-1.c:
On Fri, Jul 16, 2021 at 5:11 PM Richard Biener wrote:
>
> On Thu, 15 Jul 2021, Richard Biener wrote:
>
> > On Thu, 15 Jul 2021, Richard Biener wrote:
> >
> > > OK, guess I was more looking at
> > >
> > > #define N 32
> > > int foo (unsigned long *a, unsigned long * __restrict b,
> > >
gcc/
* config.gcc (riscv*-*-*): Detect which python is available.
---
gcc/config.gcc | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/gcc/config.gcc b/gcc/config.gcc
index 93e2b3219b9..3df9b52cf25 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -4730,9 +4730,10
1. Replace scalar_int_mode with fixed_size_mode in the by-pieces
infrastructure to allow non-integer mode.
2. Rename widest_int_mode_for_size to widest_fixed_size_mode_for_size
to return QI vector mode for memset.
3. Add op_by_pieces_d::smallest_fixed_size_mode_for_size to return the
smallest
On Mon, Jul 19, 2021 at 7:41 AM Richard Sandiford
wrote:
>
> "H.J. Lu via Gcc-patches" writes:
> > On Fri, Jul 16, 2021 at 7:15 AM H.J. Lu wrote:
> >>
> >> On Fri, Jul 16, 2021 at 6:24 AM Richard Sandiford
> >> wrote:
> >> >
> >> > "H.J. Lu via Gcc-patches" writes:
> >> > > On Fri, Jul 16,
on 2021/7/20 上午4:45, Martin Sebor wrote:
> On 7/19/21 12:28 AM, Kewen.Lin wrote:
>> Hi Martin & Richard,
>>
A further improvement worth considering (if you're so inclined :)
is replacing the pcom_worker vec members with auto_vec (obviating
having to explicitly release them) and for
Hi!
On Thu, Jun 17, 2021 at 10:18:59AM -0500, Bill Schmidt wrote:
> * config/rs6000/rs6000-gen-builtins.c (complete_vector_type): New
> function.
> (complete_base_type): Likewise.
> (construct_fntype_id): Likewise.
> (parse_bif_entry): Call contruct_fntype_id.
>
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574385.html
On 7/12/21 12:06 PM, Martin Sebor wrote:
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574385.html
On 7/2/21 1:21 PM, Martin Sebor wrote:
To avoid a class of false negatives for sanitized code
-Wuninitialized
This patch changes the Go frontend to avoid aliases in receiver types.
If a package declares a method on an alias type, the alias would be
used in the export data. This would then trigger a compiler assertion
on import: we should not be adding methods to aliases.
Fix the problem by ensuring that
On Thu, Jun 17, 2021 at 10:18:58AM -0500, Bill Schmidt wrote:
> * config/rs6000/rs6000-gen-builtins.c (ovld_stanza): New struct.
> (MAXOVLDSTANZAS): New macro.
> (ovld_stanzas): New variable.
> (curr_ovld_stanza): Likewise.
> (MAXOVLDS): New macro.
> (ovlddata):
The gcc.target/powerpc/pr93658.c test uses a loop to write into
consecutive bytes of a char variable. The loop vectorizer turns
it into a series of assignments of vector(16) char each, which
the warning then points out. I have committed r12-2401 to
a suppress the warning:
On Thu, Jun 17, 2021 at 10:18:57AM -0500, Bill Schmidt wrote:
> * config/rs6000/rs6000-gen-builtins.c (parse_bif_attrs):
> Implement.
> +#ifdef DEBUG
> + (*diag) ("attribute set: init = %d, set = %d, extract = %d, \
> +nosoft = %d, ldvec = %d, stvec = %d, reve = %d, pred = %d, htm =
On Mon, 19 Jul 2021, Patrick Palka wrote:
> Constraint subsumption is implemented in two steps. The first step
> computes the disjunctive (or conjunctive) normal form of one of the
> constraints, and the second step verifies that each clause in the
> decomposed form implies the other constraint.
On Thu, Jun 17, 2021 at 10:18:56AM -0500, Bill Schmidt wrote:
> * config/rs6000/rs6000-gen-builtins.c (parse_args): New function.
> (parse_prototype): Implement.
> + restr_opnd[restr_cnt] = *nargs + 1;
> + restr[restr_cnt] = argtype->restr;
> + val1[restr_cnt]
Constraint subsumption is implemented in two steps. The first step
computes the disjunctive (or conjunctive) normal form of one of the
constraints, and the second step verifies that each clause in the
decomposed form implies the other constraint. Performing these two
steps separately is
Gentle ping.
From: Gcc-patches on
behalf of Victor Tong via Gcc-patches
Sent: Monday, June 28, 2021 4:10 PM
To: Richard Biener ; Marc Glisse
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [EXTERNAL] Re: [PATCH] tree-optimization: Optimize division
followed by
On 7/19/21 12:28 AM, Kewen.Lin wrote:
Hi Martin & Richard,
A further improvement worth considering (if you're so inclined :)
is replacing the pcom_worker vec members with auto_vec (obviating
having to explicitly release them) and for the same reason also
replacing the comp_ptrs bare pointer
> On Jul 5, 2021, at 7:09 PM, Matt Jacobson wrote:
>
>> On Jun 7, 2021, at 3:30 AM, Matt Jacobson wrote:
>>
>> The AVR target builds a lot of multilib variants of target libraries by
>> default,
>> and I found myself wanting to use the --with-multilib-list argument to limit
>> what I was
Hi!
On Thu, Jun 17, 2021 at 10:18:55AM -0500, Bill Schmidt wrote:
> +enum bif_stanza
> +{
...
> + NUMBIFSTANZAS
> +};
Doing "NUM" things like this makes it valid to assign the NUM value to
a variable of this enum type, and importantly, the compiler cannot
warn for it then. So this is a bit of
PR analyzer/101503 reports an assertion failure due to an unexpected
"UNKNOWN" value (due to using --param analyzer-max-svalue-depth=0).
This patch fixes this by rejecting attempts to purge state involving
unknown/poisoned svalues (in region_model::purge_state_involving),
as these svalues should
On Mon, 19 Jul 2021 at 19:46, Marek Polacek wrote:
>
> On Sat, Jul 17, 2021 at 02:50:28PM -0700, Jason Merrill wrote:
> > On 7/16/21 6:34 PM, Jakub Jelinek wrote:
> > > On Fri, Jul 16, 2021 at 05:36:13PM -0400, Marek Polacek via Gcc-patches
> > > wrote:
> > > > When implementing DR 1512 in
> On Jul 19, 2021, at 5:33 AM, Richard Biener wrote:
>
> On Fri, 16 Jul 2021, Qing Zhao wrote:
>
>> Hi,
>>
>> After some more study on __builtin_clear_padding and the corresponding
>> testing cases.
>> And also considered both Richard Biener and Richard Sandiford’s previous
>> suggestion
On 7/5/21 12:38 AM, Tuan Le Quang wrote:
Hi Martin,
Thank you for your quick response.
> The main benefit of variadic functions templates over C vararg
> functions is that they make use of the type system for type safety.
> I'm not sure I see applying attribute format to them as a very
Hi!
On Thu, Jun 17, 2021 at 10:18:54AM -0500, Bill Schmidt wrote:
> * config/rs6000/rs6000-gen-builtins.c (rbtree.h): New #include.
> (num_bifs): New variable.
> (num_ovld_stanzas): Likewise.
> (num_ovlds): Likewise.
> (parse_codes): New enum.
> (bif_rbt): New
On Sat, Jul 17, 2021 at 02:50:28PM -0700, Jason Merrill wrote:
> On 7/16/21 6:34 PM, Jakub Jelinek wrote:
> > On Fri, Jul 16, 2021 at 05:36:13PM -0400, Marek Polacek via Gcc-patches
> > wrote:
> > > When implementing DR 1512 in r11-467 I neglected to reject ordered
> > > comparison of two null
This patch adds two new GCN-specific options: -mxnack and
-msram-ecc={on,off,any}.
The primary purpose is to ensure that we have an explicit default
setting for these features and that this is passed to the assembler.
This will ensure that if LLVM defaults change, again, GCC won't get
caught
Hi,
As subject, this patch renames the two-source-register TBL/TBX RTL
patterns so that their names better reflect what they do, rather than
confusing them with tbl3 or tbx4 patterns. Also use the correct
"neon_tbl2" type attribute for both patterns.
Rename single-source-register TBL/TBX
On July 19, 2021 6:13:40 PM GMT+02:00, Hafiz Abid Qadeer
wrote:
>On 19/07/2021 11:45, Richard Biener wrote:
>> On Fri, Jul 16, 2021 at 10:23 PM Hafiz Abid Qadeer
>> wrote:
>>>
>>> On 15/07/2021 13:09, Richard Biener wrote:
On Thu, Jul 15, 2021 at 12:35 PM Hafiz Abid Qadeer
wrote:
Hi,
On Tue, Jul 13 2021, Alexandre Oliva wrote:
> The logic in fill_vector_of_new_param_types may skip some parameters
> when pushing into m_new_types, but common_initialization doesn't take
> that into account, and may end up attempting to access the vector past
> its end when
On 19/07/2021 11:45, Richard Biener wrote:
> On Fri, Jul 16, 2021 at 10:23 PM Hafiz Abid Qadeer
> wrote:
>>
>> On 15/07/2021 13:09, Richard Biener wrote:
>>> On Thu, Jul 15, 2021 at 12:35 PM Hafiz Abid Qadeer
>>> wrote:
On 15/07/2021 11:33, Thomas Schwinge wrote:
>
>> Note that
I'm sending the patch once again for review/approval.
I fixed the doc to use the new function names.
Le vendredi 18 juin 2021 à 16:37 -0400, David Malcolm a écrit :
> On Fri, 2021-06-18 at 15:41 -0400, Antoni Boucher wrote:
> > I have write access now.
>
> Great.
>
> > I'm not sure how I'm
On 7/19/21 12:20 AM, Kewen.Lin wrote:
Hi,
This patch follows Martin's suggestion here[1], to support
range-based for loops for traversing loops, analogously to
the patch for vec[2].
Bootstrapped and regtested on powerpc64le-linux-gnu P9,
x86_64-redhat-linux and aarch64-linux-gnu, also
On 19/07/2021 14:52, Richard Sandiford via Gcc-patches wrote:
Richard Earnshaw via Gcc-patches writes:
On 14/12/2020 11:29, Andrea Corallo via Gcc-patches wrote:
Hi all,
I've committed the attached patch as obvious.
This is to set `fill-column' to 80 in c-mode (Emacs default it to 70) so
Hi,
On Tue, Jul 13 2021, Alexandre Oliva wrote:
> I'm working on a feature that involves creating wrappers for some
> functions, using alternate means to pass variable argument lists to
> the wrapped versions. The split-out (wrapped) function shouldn't be
> stdarg, and though comments in
On Mon, Jul 19, 2021 at 05:17:10PM +0200, Tobias Burnus wrote:
> Update the OpenMP feature list.
>
> Comments? Remarks?
I'd defer mentioning it until I actually finish it (hopefully later this
week or next week worst case).
> gcc-12/changes.html: OpenMP - mention C++11 attributes support
>
>
Update the OpenMP feature list.
Comments? Remarks?
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München;
On 7/17/21 2:36 PM, Jan-Benedict Glaw wrote:
Hi Martin!
On Fri, 2021-06-04 15:27:04 -0600, Martin Sebor wrote:
This is a revised patch series to add warning control by group and
location, updated based on feedback on the initial series.
[...]
My automated checking (in this case: Using
"H.J. Lu via Gcc-patches" writes:
> On Fri, Jul 16, 2021 at 7:15 AM H.J. Lu wrote:
>>
>> On Fri, Jul 16, 2021 at 6:24 AM Richard Sandiford
>> wrote:
>> >
>> > "H.J. Lu via Gcc-patches" writes:
>> > > On Fri, Jul 16, 2021 at 4:38 AM Richard Sandiford
>> > > wrote:
>> > >>
>> > >> "H.J. Lu via
On Mon, Jul 19, 2021 at 8:20 AM Kewen.Lin wrote:
>
> Hi,
>
> This patch follows Martin's suggestion here[1], to support
> range-based for loops for traversing loops, analogously to
> the patch for vec[2].
>
> Bootstrapped and regtested on powerpc64le-linux-gnu P9,
> x86_64-redhat-linux and
Tested x86_64-pc-linux-gnu, applying to trunk.
DR 2126
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/constexpr-temp2.C: New test.
---
gcc/testsuite/g++.dg/cpp0x/constexpr-temp2.C | 6 ++
1 file changed, 6 insertions(+)
create mode 100644
> On Jul 19, 2021, at 5:33 AM, Richard Biener wrote:
>
> On Fri, 16 Jul 2021, Qing Zhao wrote:
>
>> Hi,
>>
>> After some more study on __builtin_clear_padding and the corresponding
>> testing cases.
>> And also considered both Richard Biener and Richard Sandiford’s previous
>> suggestion
On Mon, Jul 19, 2021 at 02:53:13PM +0100, Richard Earnshaw wrote:
> > Yeah, that will mean consistency no matter whether one has the
> > customizations installed or not.
> > And, you don't want the effect of $GCC_GIT gcc-descr but $GCC_GIT gcc-descr
> > HEAD
> > (the default is $GCC_GIT gcc-descr
On Mon, 19 Jul 2021 at 07:20, Kewen.Lin wrote:
>
> Hi,
>
> This patch follows Martin's suggestion here[1], to support
> range-based for loops for traversing loops, analogously to
> the patch for vec[2].
>
> Bootstrapped and regtested on powerpc64le-linux-gnu P9,
> x86_64-redhat-linux and
On 16/07/2021 08:29, Jakub Jelinek via Gcc-patches wrote:
> On Fri, Jul 16, 2021 at 09:06:01AM +0200, Richard Biener via Gcc-patches
> wrote:
>> On Thu, Jul 15, 2021 at 9:12 PM Serge Belyshev
>> wrote:
>>>
>>> This is to make development version string more readable, and
>>> to simplify
Richard Earnshaw via Gcc-patches writes:
> On 14/12/2020 11:29, Andrea Corallo via Gcc-patches wrote:
>> Hi all,
>>
>> I've committed the attached patch as obvious.
>>
>> This is to set `fill-column' to 80 in c-mode (Emacs default it to 70) so
>> now M-q does the right thing. I think is very
On Thu, 15 Jul 2021 at 16:46, Prathamesh Kulkarni
wrote:
>
> On Thu, 15 Jul 2021 at 14:47, Christophe Lyon
> wrote:
> >
> > Hi Prathamesh,
> >
> > On Mon, Jul 5, 2021 at 11:25 AM Kyrylo Tkachov via Gcc-patches
> > wrote:
> >>
> >>
> >>
> >> > -Original Message-
> >> > From: Prathamesh
On Mon, 19 Jul 2021, Matthias Kretz wrote:
> tested on x86_64-pc-linux-gnu with no new failures. OK for master?
I think now that PAREN_EXPR can appear in C++ code you need to
adjust some machiner to expect it (constexpr folding? template stuff?).
I suggest to add some testcases covering
Loop vectorization pattern recog fails to walk PHIs when determining
stmt precisions. This fails to recognize non-mask uses for bools
in PHIs and outer loop vectorization.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2021-07-19 Richard Biener
PR
>> > On 19 Jul 2021, at 11:39, Richard Biener via Gcc-patches
>> > wrote:
>> >
>> > On Fri, Jul 16, 2021 at 12:37 PM Serge Belyshev
>> > wrote:
>> >>
>> >> Based on discussion I've chosen open-coded version without commit hash.
>> >
>> > As said I'd prefer one with (shortened) hash,
Oh, I
On 14/12/2020 11:29, Andrea Corallo via Gcc-patches wrote:
Hi all,
I've committed the attached patch as obvious.
This is to set `fill-column' to 80 in c-mode (Emacs default it to 70) so
now M-q does the right thing. I think is very handy especially in
comments.
Question: should we update
On 19/07/2021 09:46, Thomas Schwinge wrote:
GCN already uses address 4 for this value because address 0 caused
problems with null-pointer checks.
Ugh. How much wasted bytes per what is that? (I haven't looked yet;
hopefully not per GPU thread?) Because:
It's 4 bytes per gang. And that
On Mon, Jul 19, 2021 at 11:47:01AM +0100, Iain Sandoe wrote:
>
>
> > On 19 Jul 2021, at 11:39, Richard Biener via Gcc-patches
> > wrote:
> >
> > On Fri, Jul 16, 2021 at 12:37 PM Serge Belyshev
> > wrote:
> >>
> >> Based on discussion I've chosen open-coded version without commit hash.
> >
On Fri, Jul 16, 2021 at 10:23 PM Hafiz Abid Qadeer
wrote:
>
> On 15/07/2021 13:09, Richard Biener wrote:
> > On Thu, Jul 15, 2021 at 12:35 PM Hafiz Abid Qadeer
> > wrote:
> >>
> >> On 15/07/2021 11:33, Thomas Schwinge wrote:
> >>>
> Note that the "parent" should be abstract but I don't
> On 19 Jul 2021, at 11:39, Richard Biener via Gcc-patches
> wrote:
>
> On Fri, Jul 16, 2021 at 12:37 PM Serge Belyshev
> wrote:
>>
>> Based on discussion I've chosen open-coded version without commit hash.
>
> As said I'd prefer one with (shortened) hash,
Likewise, I’ve been using a
On Sat, Jul 17, 2021 at 4:45 PM Indu Bhagat via Gcc-patches
wrote:
>
> Hello,
>
> Thanks for your feedback on the previous RFC version of this proposal. This
> patch set is a refined and tested version of the same.
> - Added changes to tm.texi.in and regenerated tm.texi.
> - Updated the
On Fri, Jul 16, 2021 at 12:37 PM Serge Belyshev
wrote:
>
> Based on discussion I've chosen open-coded version without commit hash.
As said I'd prefer one with (shortened) hash, but then I'm not angry
if people agree on sth else.
> >> > > ... Perhaps rename the r, o, rr and m temporaries.
>
> I
On Fri, Jul 16, 2021 at 7:33 AM Kewen.Lin wrote:
>
> on 2021/7/15 下午7:58, Richard Biener wrote:
> > On Thu, Jul 15, 2021 at 10:41 AM Kewen.Lin wrote:
> >>
> >> on 2021/7/15 下午4:04, Kewen.Lin via Gcc-patches wrote:
> >>> Hi Uros,
> >>>
> >>> on 2021/7/15 下午3:17, Uros Bizjak wrote:
> On Thu,
On Fri, 16 Jul 2021, Qing Zhao wrote:
> Hi,
>
> After some more study on __builtin_clear_padding and the corresponding
> testing cases.
> And also considered both Richard Biener and Richard Sandiford’s previous
> suggestion to use
> __builtin_clear_padding. I have the following thought on
On 17/07/2021 22:37, Jason Merrill via Gcc-patches wrote:
On Sat, Jul 17, 2021 at 6:55 AM Matthias Kretz wrote:
On Saturday, 17 July 2021 15:32:42 CEST Jonathan Wakely wrote:
On Sat, 17 Jul 2021, 09:15 Matthias Kretz, wrote:
If somebody writes a library with `keep_apart` in the public
apinski--- via Gcc-patches writes:
> From: Andrew Pinski
>
> So the problem is even though there was a csneg with
> a zero_extend in the front, there was not one for csinv.
> This fixes it by extending that pattern.
>
> OK? Bootstrapped and tested on aarch64-linux-gnu with no regressions.
>
>
On Mon, Jul 19, 2021 at 10:46:35AM +0200, Thomas Schwinge wrote:
> |> (So I'll consider some GCN-specific '-Wno-array-bounds' if we don't
> |> get to resolve this otherwise, soon.)
>
> Now: "Awaiting a different solution, of course." ;-)
The current state of the warning is unacceptable. IMNSHO
Hi!
On 2021-07-16T15:11:24-0600, Martin Sebor via Gcc-patches
wrote:
> On 7/16/21 11:42 AM, Thomas Schwinge wrote:
>> On 2021-07-09T17:11:25-0600, Martin Sebor via Gcc-patches
>> wrote:
>>> The attached tweak avoids the new -Warray-bounds instances when
>>> building libatomic for arm.
Hi!
| On 7/16/21 11:42 AM, Thomas Schwinge wrote:
|> On 2021-07-09T17:11:25-0600, Martin Sebor via Gcc-patches
wrote:
|>> The attached tweak avoids the new -Warray-bounds instances when
|>> building libatomic for arm. Christophe confirms it resolves
|>> the problem (thank you!)
|>
|> As Abid
On Fri, Jul 16, 2021 at 3:04 PM Richard Biener wrote:
>
> This removes the last uses of gimple_expr_type.
>
> Bootstrap & regtest running on x86_64-unknown-linux-gnu.
The following variant is what I eventually pushed.
Richard.
p
Description: Binary data
tested on x86_64-pc-linux-gnu with no new failures. OK for master?
New builtin to enable explicit use of PAREN_EXPR in C & C++ code.
Signed-off-by: Matthias Kretz
gcc/testsuite/ChangeLog:
* c-c++-common/builtin-assoc-barrier-1.c: New test.
gcc/cp/ChangeLog:
*
On Fri, Jul 16, 2021 at 2:00 PM Matthias Kretz wrote:
>
> On Friday, 16 July 2021 11:31:29 CEST Richard Biener wrote:
> > On Fri, Jul 16, 2021 at 10:57 AM Matthias Kretz wrote:
> > > On Wednesday, 14 July 2021 10:14:55 CEST Richard Biener wrote:
> > > > I think implementing it similar to how we
Hi Martin & Richard,
>> A further improvement worth considering (if you're so inclined :)
>> is replacing the pcom_worker vec members with auto_vec (obviating
>> having to explicitly release them) and for the same reason also
>> replacing the comp_ptrs bare pointer members with auto_vecs.
>>
On Sun, Jul 18, 2021 at 11:21 PM Kewen.Lin via Gcc-patches
wrote:
>
> Hi,
>
> This patch follows Martin's suggestion here[1], to support
> range-based for loops for traversing loops, analogously to
> the patch for vec[2].
>
> Bootstrapped and regtested on powerpc64le-linux-gnu P9,
>
Hi,
This patch follows Martin's suggestion here[1], to support
range-based for loops for traversing loops, analogously to
the patch for vec[2].
Bootstrapped and regtested on powerpc64le-linux-gnu P9,
x86_64-redhat-linux and aarch64-linux-gnu, also
bootstrapped on ppc64le P9 with bootstrap-O3
69 matches
Mail list logo
