On Thu, 9 Feb 2023, Tamar Christina wrote:
> Hi All,
>
> As discussed in the ticket, this replaces the approach for optimizing the
> div by bitmask operation from a hook into optabs implemented through
> add_highpart.
>
> In order to be able to use this we need to check whether the current
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108752
--- Comment #2 from Richard Biener ---
Created attachment 54447
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54447=edit
prototype
Prototype patch. Would benefit from a vect_finish_stmt_generation with
a gimple_seq overload and using
Updated version attached.
On 31.01.23 12:20, Jakub Jelinek via Gcc-patches wrote:
On Tue, Jan 24, 2023 at 04:24:07PM +0100, Tobias Burnus wrote:
+ if (code->op == EXEC_OMP_LOOP)
+; /* Already rejected in resolve_omp_clauses. */
I don't understand why is this needed. Sure, the vast
A passing build has been detected on builder gccrust-rawhide-x86_64 while
building gccrust.
Full details are available at:
https://builder.sourceware.org/buildbot/#builders/132/builds/438
Build state: build successful
Revision: 7179562ff2854bdd128a2a4ddcd5da5ac59c4512
Worker: bb1-2
Build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108752
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108752
Bug ID: 108752
Summary: word_mode vectorization is pessimized by hard limit on
nunits
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108724
Richard Biener changed:
What|Removed |Added
Known to work||13.0
Summary|[11/12/13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108724
--- Comment #5 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:dc87e1391c55c666c7ff39d4f0dea87666f25468
commit r13-5771-gdc87e1391c55c666c7ff39d4f0dea87666f25468
Author: Richard Biener
Date:
On Fri, 10 Feb 2023, Richard Sandiford wrote:
> Richard Biener via Gcc-patches writes:
> > This fixes an oversight to when removing the hard limits on using
> > generic vectors for the vectorizer to enable both SLP and BB
> > vectorization to use those. The vectorizer relies on vector lowering
Richard Biener via Gcc-patches writes:
> This fixes an oversight to when removing the hard limits on using
> generic vectors for the vectorizer to enable both SLP and BB
> vectorization to use those. The vectorizer relies on vector lowering
> to expand plus, minus and negate to bit operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108749
--- Comment #4 from Jakub Jelinek ---
Perhaps it is implementable also for taskloop, but with a lot of work.
The way how e.g. for/do works with inscan is that the two parts of the loop are
split up, and one essentially gets two worksharing
This fixes an oversight to when removing the hard limits on using
generic vectors for the vectorizer to enable both SLP and BB
vectorization to use those. The vectorizer relies on vector lowering
to expand plus, minus and negate to bit operations but vector
lowering has a hard limit on the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108749
--- Comment #3 from Tobias Burnus ---
(In reply to Jakub Jelinek from comment #2)
> Actually, I don't see how inscan be implemented on taskloop
The proposed extension of the restriction is now tracked in the OpenMP
specification Issue 3489.
Oops, realizes I forgot to fill in the test results, there were no issues
> -Original Message-
> From: Gcc-patches bounces+tamar.christina=arm@gcc.gnu.org> On Behalf Of Tamar
> Christina via Gcc-patches
> Sent: Thursday, February 9, 2023 5:17 PM
> To: gcc-patches@gcc.gnu.org
> Cc:
Oops, realizes I forgot to fill in the test results, there were no issues
> -Original Message-
> From: Gcc-patches bounces+tamar.christina=arm@gcc.gnu.org> On Behalf Of Tamar
> Christina via Gcc-patches
> Sent: Thursday, February 9, 2023 5:22 PM
> To: gcc-patches@gcc.gnu.org
> Cc:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108751
--- Comment #1 from Theodoros Theodoridis ---
I am not sure if this qualifies as a "bug"/missed optimization but I'd be
interested in understanding why these changes cause such a difference. Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108749
--- Comment #2 from Jakub Jelinek ---
Actually, I don't see how inscan be implemented on taskloop, so I'd say both
5.1 and 5.2 are wrong and it should be neither distribute nor taskloop are
constituent.
#pragma omp target parallel for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108751
Bug ID: 108751
Summary: Removing dead code results in worse optimization at
-Os
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108750
Bug ID: 108750
Summary: Loop unswitching fails for poly_int conditions
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
From: Ju-Zhe Zhong
According to RVV ISA, vsmul are not supported for EEW=64 in Zve64*,
so add Full 'V' extension required into predicate of vsmul intrinsics.
gcc/ChangeLog:
* config/riscv/riscv-vector-builtins-functions.def (vsmul): Change
iterators.
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108718
--- Comment #6 from Richard Biener ---
Huh, the change for sure triggered some latent issue, either in the testcase or
in GCC. More analysis is needed (the testcase is large and obfuscated...).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108749
--- Comment #1 from Jakub Jelinek ---
We implement the 5.0 wording which was quite clear that only the selected
combined/composite constructs are allowed for it. The clause handling wording
was added without considering the former (it wasn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106249
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
Hi!
On 2011-04-13T06:49:31-0400, Joern Rennecke wrote:
> [...]
> This Makefile is supposed to give coverage of all the main configure targets
> and notable variants that enable different config files.
> [...]
> --- contrib/config-list.mk(revision 0)
> +++ contrib/config-list.mk(revision
The following fixes a latent issue when we mark control edges but
end up with marking a block with no stmts necessary. In this case
we fail to mark dependent control edges of that block.
Bootstrapped and tested on x86_64-unknown-linux-gnu.
Does this look OK?
Thanks,
Richard.
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108749
Bug ID: 108749
Summary: [OpenMP][C/C++/Fortran] inscan reduction modifier
rejected for combined/composite constructs of
simd/for/do
Product: gcc
Version: 13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108724
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Summary|Poor codegen
Hi!
On 2023-02-02T00:55:01-0500, Flavio Cruz wrote:
> contrib/ChangeLog:
> * config-list.mk: Add x86_64-gnu to list of archs.
>
> Signed-off-by: Flavio Cruz
Thanks, pushed to GCC master branch in
commit e635681dd26abf8243b49f6fd39d3582d57225ba
"Add x86_64-gnu target to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108724
Richard Biener changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108748
Bug ID: 108748
Summary: Enhancement: track ranges of poly_int indeterminates
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100758
Jakub Jelinek changed:
What|Removed |Added
Resolution|WONTFIX |FIXED
--- Comment #23 from Jakub
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108687
--- Comment #10 from Stefan Schulze Frielinghaus ---
Can confirm the attached patch solves this issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108734
--- Comment #7 from Jonathan Wakely ---
(In reply to David Edelsohn from comment #5)
> __has_builtin() does not mean that the builtin is inlined. It only means
> that GCC recognizes the builtin. That is how __has_builtin() is documented.
> In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108737
--- Comment #4 from Richard Biener ---
I think this is another case where control dependences do not work as intended.
Marking useful stmt: foo ();
and we have
[local count: 3508266]:
x_4 = foo ();
if (x_4 != 0)
goto ; [33.00%]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108743
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
On Fri, Jan 06, 2023 at 12:20:33PM +, Andrew Stubbs wrote:
> > > +/* Ensure the the in-branch simd clones are used on targets that support
> > > + them. These counts include all call and definitions. */
> > > +
> > > +/* { dg-skip-if "" { x86_64-*-* } { "-flto" } { "" } } */
> >
> > Drop
On Thu, 9 Feb 2023, Jakub Jelinek wrote:
> Martin Liska mentioned that porting_to.html doesn't mention
> the C++ excess precision changes. Not really sure if porting_to
> should document those, but I think changes.html certainly should.
Do you think this is a widely spread issue for existing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108685
Martin Liška changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108696
--- Comment #4 from Richard Biener ---
(In reply to Andrew Macleod from comment #2)
> Created attachment 54437 [details]
> possible patch
>
> This patch should successfully short circuit unnecessary checks. untested in
> compiler.i
>
> Where
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77760
--- Comment #7 from Jakub Jelinek ---
(In reply to Alexandre Oliva from comment #5)
> As for tm bits, my suggestion was to overwrite tm fields internally, not to
> expose that externally. They'd be used as scratch bits. As in, member
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101099
Martin Liška changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100758
--- Comment #22 from Martin Liška ---
Thank you Jakub, please revert my documentation patch if you are convinced
enough the change works only on old VIA CPUs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108743
--- Comment #5 from Pierre Ossman ---
Could you consider adding -fconstant-cfstrings as an alias? It would make life
easier for making build systems compiler agnostic.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108743
--- Comment #4 from Pierre Ossman ---
I am indeed trying to compile for macOS. Specifically Qt5, which is designed
with just Xcode in mind.
201 - 244 of 244 matches
Mail list logo
