https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98216
--- Comment #2 from Jonathan Wakely ---
Reduced:
template
struct array
{
constexpr T& operator[](int n) { return d[n]; }
constexpr const T& operator[](int n) const { return d[n]; }
constexpr bool operator==(const array& a) const
{
Hi All,
This adds implementation for the optabs for complex additions. With this the
following C code:
void f90 (float complex a[restrict N], float complex b[restrict N],
float complex c[restrict N])
{
for (int i=0; i < N; i++)
c[i] = a[i] + (b[i] * I);
}
generates
Hi All,
This adds implementation for the optabs for complex operations. With this the
following C code:
void f90 (float complex a[restrict N], float complex b[restrict N],
float complex c[restrict N])
{
for (int i=0; i < N; i++)
c[i] = a[i] + (b[i] * I);
}
generates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97104
akrl at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
On 12/9/20 4:09 PM, Eric Gallager via Gcc-patches wrote:
On Fri, Dec 4, 2020 at 4:58 AM Erick Ochoa <
erick.oc...@theobroma-systems.com> wrote:
This commit includes the following components:
Type-based escape analysis to determine structs that can be modified at
link-time.
Field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98226
Bug ID: 98226
Summary: Slow std::countr_one
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91415
--- Comment #13 from Nicolai Josuttis ---
Oh, sorry, your are right, the example indeed works.
BUT: I used in fact a slightly different example
(sorry, didn't expect that there is a difference):
int main() {
int i = 0;
int j = i++ << i++;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71899
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
This augments the spelling suggestion code to understand about visible
imported modules. Simply consider each visible binding in the
binding_vector, until we find one that has something of interest.
gcc/cp/
* name-lookup.c: Include bitmap.h.
(enum binding_slots): New.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97723
--- Comment #3 from Paul Thomas ---
(In reply to Paul Thomas from comment #2)
>
> The fix regtests OK. I will commit as 'obvious' with a test case in the next
> day or two.
Cancel that, there is one regression.
Paul
Thank you for your rapid feedback.
I'll fix the various formatting issues (spaces in the wrong places
and such as well as revise the Changelog magic) in the next submission.
It will wait for Joseph's review to also make any changes he suggests.
I'll also try to train myself to be more sensitive
This implements lightweight heuristical detection and diagnosing of
satisfaction results that change at different points in the program,
which renders the program as ill-formed NDR as of P2014. We've recently
started to more aggressively cache satisfaction results, and so the goal
here is to make
On Wed, 9 Dec 2020 at 17:47, Richard Sandiford
wrote:
>
> Christophe Lyon via Gcc-patches writes:
> > Hi,
> >
> > I've been working for a while on enabling auto-vectorization for ARM
> > MVE, and I find it a bit awkward to keep things common with Neon as
> > much as possible.
> >
> > I've just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71899
--- Comment #6 from Daniel Krügler ---
(In reply to Jonathan Wakely from comment #5)
> LWG 2743 seems to be the wrong issue, I think https://wg21.link/lwg2114 is
> the right one.
Ah yes, this was an unintended mislinking on my side. Feel free
On 04/12/20 00:35 +, Jonathan Wakely wrote:
On 03/12/20 20:07 -0300, Tulio Magno Quites Machado Filho via Libstdc++ wrote:
Jonathan Wakely via Libstdc++ writes:
diff --git a/libstdc++-v3/configure.ac b/libstdc++-v3/configure.ac
index cbfdf4c6bad..d25842fef35 100644
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98220
--- Comment #12 from Jonathan Wakely ---
(In reply to wuz73 from comment #11)
> (In reply to Jonathan Wakely from comment #10)
> > No it's, not a bug, because the C++ standard says the order is unspecified.
> > The compiler is allowed to reorder
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44952
--- Comment #16 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #5)
> 27.4 [iostream.objects] paragraph 2
> The results of including in a translation unit shall be as if
> defined an instance of ios_base::Init with static
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35718
Paul Thomas changed:
What|Removed |Added
Assignee|pault at gcc dot gnu.org |unassigned at gcc dot
gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97723
Paul Thomas changed:
What|Removed |Added
Last reconfirmed||2020-12-10
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97723
Paul Thomas changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98220
--- Comment #11 from wuz73 at hotmail dot com ---
(In reply to Jonathan Wakely from comment #10)
> No it's, not a bug, because the C++ standard says the order is unspecified.
> The compiler is allowed to reorder them, and that's what happens with
On 12/9/20 2:24 AM, Martin Liška wrote:
Hello.
The newly added warning is about warning a user
that std::atomic_thread_fence is not supported by TSAN.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
PR
Hi Christophe,
> From: Christophe Lyon
> Sent: Monday, November 9, 2020 1:38 PM
> To: Dennis Zhang
> Cc: Kyrylo Tkachov; gcc-patches@gcc.gnu.org; Richard Earnshaw; nd; Ramana
> Radhakrishnan
> Subject: Re: [PATCH][Arm] Auto-vectorization for MVE: vsub
>
> Hi,
>
> I have just noticed that the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97727
akrl at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
This needs the first patch in the series to be applied first. This patch is
not critical for enabling IEEE 128-bit long double, but it does improve
float128 code generation on power10.
I haven't received a reply for this patch:
| Date: Sun, 15 Nov 2020 23:53:20 -0500
| Subject: [PATCH 2/2]
This patch has been around for quite some time. It isn't critical for enabling
IEEE 128-bit long double, but it improves code generation for float128 on
power10.
I haven't received a reply for this patch:
| Date: Sun, 15 Nov 2020 23:50:51 -0500
| Subject: [PATCH 1/2] Power10: Add IEEE 128-bit
This patch fixes a typo reported at
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/558478.html
gcc/testsuite/
* gcc.target/arm/simd/mve-vsub_1.c: Fix typo.
Remove needless dg-additional-options.
Cheers,
Dennisdiff --git a/gcc/testsuite/gcc.target/arm/simd/mve-vsub_1.c
On Thu, Dec 10, 2020 at 03:38:40PM +0100, Jakub Jelinek via Gcc-patches wrote:
> I don't understand this. My reading of:
> "The event-handle will be considered as if it was specified on a
> firstprivate clause. The use of a variable in a detach clause expression of a
> task
> construct causes an
This patch isn't critical for IEEE 128-bit long double, but it is a feature
Jonathan Wakely asked for, to have a single switch to enable IEEE/IBM 128-bit
long double, without having to set the long double size.
I haven't received a replay for this patch:
| Date: Thu, 19 Nov 2020 19:00:11 -0500
|
This is one of the critical patches for enabling IEEE 128-bit long double.
I haven't received a reply for this patch:
| Date: Thu, 19 Nov 2020 19:05:24 -0500
| Subject: [PATCH] PowerPC: Add float128/Decimal conversions
| Message-ID: <2020112524.ga...@ibm-toto.the-meissners.org>
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96710
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
This patch is one of the critical patches to enable building GCC with the long
double type set to IEEE 128-bit.
I haven't received a response for this patch:
| Date: Thu, 19 Nov 2020 18:58:14 -0500
| Subject: [PATCH] PowerPC: Map IEEE 128-bit long double built-in functions
| Message-ID:
On 10/12/2020 16:10, webmaster wrote:
(As a general rule, you'll get more useful responses if you use your
name in your posts. It's common courtesy.)
> Is it possible to request such feature?
>
Of course you can file a request for it. Go to the gcc bugzilla site:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98174
--- Comment #3 from Richard Biener ---
(In reply to Richard Biener from comment #2)
> Maybe related (didn't check yet), the testcases for PR91257 and PR93199 now
> OOM at -O2
https://gcc.opensuse.org/gcc-old/c++bench-czerny/random/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98174
--- Comment #2 from Richard Biener ---
Maybe related (didn't check yet), the testcases for PR91257 and PR93199 now OOM
at -O2
Hi all,
following discussion on PR97092 I'd like to submit the following patch
with a fix plus associated testcase.
With this patch applied mode is recomputed at each iteration while
looping across different copies in 'update_costs_from_allocno', this
instead of carrying mode over subsequent
On Thu, Dec 10, 2020 at 12:00:17PM +0100, Jakub Jelinek wrote:
> So, would it be better to check for one of FRAME_POINTER_REGNUM,
> ARG_POINTER_REGNUM or RETURN_ADDRESS_POINTER_REGNUM if they
> are mentioned in (from part of pairs in) ELIMINABLE_REGS?
In patch form now:
2020-12-10 Jakub Jelinek
Is it possible to request such feature?
Am 09.12.2020 um 16:45 schrieb webmaster:
> I have the following Code C\C++:
>
> static int foo = 0;
>
> static void bar(void)
> {
> foo = 1;
> }
>
> Here it is clear for the compiler that the variable foo can only be
> accessed from the same modul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78173
Patrick Palka changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68451
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
I was about to add this test with dg-ice but it turned out it had
already been fixed by the recent r11-3361!
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/testsuite/ChangeLog:
PR c++/68451
* g++.dg/cpp0x/friend6.C: New test.
---
gcc/testsuite/g++.dg/cpp0x/friend6.C | 23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68451
--- Comment #4 from CVS Commits ---
The master branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:e271cd0234d5db2f95c35454b8b29b6e8386caa8
commit r11-5912-ge271cd0234d5db2f95c35454b8b29b6e8386caa8
Author: Marek Polacek
Date:
Here are some refactorings to the name-lookup machinery. Primarily
breakout out worker functions that the modules patch will also use.
Fixing a couple of comments on the way.
gcc/cp/
* name-lookup.c (pop_local_binding): Check for IDENTIFIER_ANON_P.
(update_binding):
> 2020-12-10 Jakub Jelinek
>
> PR rtl-optimization/98212
> * dojump.c (do_compare_rtx_and_jump): Change computation of
> first_prob for and_them. Add comment explaining and_them case.
>
> * gcc.dg/predict-8.c: Adjust expected probability.
OK, thanks.
--
Eric
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68451
Marek Polacek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
This case handles the discriminated record types of Ada: the PLACEHOLDER_EXPR
is the "template" expression for the discriminant in the type definition. Now
for some components, typically arrays whose upper bound is the discriminant,
the compiler creates a local subtype for the component, so the
On Thu, Dec 10, 2020 at 03:18:54PM +0100, Eric Botcazou wrote:
> OK, thanks, but aren't there missing TABs in the new version? Only one line
> is changed in the end AFAICS.
No, sorry, just me hand editing of the patch (and the source) instead of
regenerating the patch (I had there prob.invert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97875
Christophe Lyon changed:
What|Removed |Added
Status|WAITING |ASSIGNED
--- Comment #6 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729
--- Comment #42 from abebeos at lazaridis dot com ---
from Dimitar Dimitrov dimi...@dinux.eu within
https://gcc.gnu.org/pipermail/gcc-patches/2020-December/561489.html
> I tested the trees you have given with my own AVR test setup [1]. I confirm
On Wed, Dec 09, 2020 at 05:37:24PM +, Kwok Cheung Yeung wrote:
> --- a/gcc/c/c-typeck.c
> +++ b/gcc/c/c-typeck.c
> @@ -14942,6 +14942,11 @@ c_finish_omp_clauses (tree clauses, enum
> c_omp_region_type ort)
> pc = _CLAUSE_CHAIN (c);
> continue;
>
> + case
Hi all,
This patch backports the commit 3553c658533e430b232997bdfd97faf6606fb102.
The original is approved at
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/557871.html
There is a change to remove FPCR-reading flag for builtin declaration since
it's not supported in gcc-10.
Another
Hi all,
This patch backports the commit f7d6961126a7f06c8089d8a58bd21be43bc16806.
The original is approved at
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/557859.html
The only change is to remove FPCR-reading flags for builtin definition since
it's not supported in gcc-10.
Regtested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64194
--- Comment #17 from CVS Commits ---
The releases/gcc-10 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:4fb1ee669ccaad16795baf25d2cab48d8cf8c1eb
commit r10-9136-g4fb1ee669ccaad16795baf25d2cab48d8cf8c1eb
Author: Patrick Palka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98220
--- Comment #10 from Jonathan Wakely ---
No it's, not a bug, because the C++ standard says the order is unspecified. The
compiler is allowed to reorder them, and that's what happens with -flto.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95582
--- Comment #20 from Eric Botcazou ---
> So I'm going to look at this again. Some random thoughts on the Ada bools
> though. It would be nice if the Ada FE could leave boolean_type_node
> untouched so that when the middle-end produces a
> 2020-12-10 Jakub Jelinek
>
> PR rtl-optimization/98212
> * dojump.c (do_compare_rtx_and_jump): Change computation of
> first_prob for and_them. Add comment explaining and_them case.
>
> * gcc.dg/predict-8.c: Adjust expected probability.
>
> --- gcc/dojump.c.jj
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98220
--- Comment #9 from wuz73 at hotmail dot com ---
Without -flto I can specify link order. So -flto will ignore the order? It is
still a bug as in many cases orders do matter.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95582
--- Comment #19 from Richard Biener ---
So I'm going to look at this again. Some random thoughts on the Ada bools
though. It would be nice if the Ada FE could leave boolean_type_node
untouched so that when the middle-end produces a compare to
Στις Πέμ, 10 Δεκ 2020 στις 7:42 π.μ., ο/η Dimitar Dimitrov
έγραψε:
> On сряда, 9 декември 2020 г. 15:12:49 EET abebeos via Gcc-patches wrote:
> > Essence:
> >
> > I need a confirmation that the testsuite setup as presented in:
> >
> > https://github.com/abebeos/avr-gnu
> >
> > works fine.
> >
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95285
Wilco changed:
What|Removed |Added
CC||wdijkstr at arm dot com
--- Comment #16 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97090
Rainer Orth changed:
What|Removed |Added
Target Milestone|--- |11.0
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98225
Rainer Orth changed:
What|Removed |Added
Target Milestone|--- |11.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98225
Bug ID: 98225
Summary: gcc.misc-tests/outputs.exp ltrans_args tests FAIL
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98224
Rainer Orth changed:
What|Removed |Added
Target Milestone|--- |11.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98224
Bug ID: 98224
Summary: [11 regression] gcc.dg/Walloca-2.c XPASSes
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91384
--- Comment #10 from Richard Biener ---
But then
void foo (void);
void bar (void);
int
test (int a)
{
if (a)
foo ();
else
bar ();
return -a;
}
is not optimized either (the usual argument - the user could have written it
in the
On Thu, Dec 10, 2020 at 12:50:02PM +0100, Eric Botcazou wrote:
> prob.split adjusts prob so this needs to be reflected in the comment (maybe
> "adjusted prob" or the formula if it is simple). Otherwise looks good to me.
Actually I went back to drawing board and the patch wasn't correct.
Let's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91384
--- Comment #9 from Richard Biener ---
The local gimple transform is not right or wrong, it depends on the
surroundings
and unless we have a way to assess those in a good way doing it in one or the
other way is going to hurt either case.
The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98219
H.J. Lu changed:
What|Removed |Added
Target Milestone|--- |11.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98219
H.J. Lu changed:
What|Removed |Added
Attachment #49724|0 |1
is obsolete|
On Thu, 10 Dec 2020 at 17:11, Richard Biener wrote:
>
> On Wed, 9 Dec 2020, Prathamesh Kulkarni wrote:
>
> > On Tue, 8 Dec 2020 at 14:36, Prathamesh Kulkarni
> > wrote:
> > >
> > > On Mon, 7 Dec 2020 at 17:37, Hongtao Liu wrote:
> > > >
> > > > On Mon, Dec 7, 2020 at 7:11 PM Prathamesh Kulkarni
On Thu, 10 Dec 2020 at 17:11, Richard Biener wrote:
>
> On Wed, 9 Dec 2020, Prathamesh Kulkarni wrote:
>
> > On Tue, 8 Dec 2020 at 14:36, Prathamesh Kulkarni
> > wrote:
> > >
> > > On Mon, 7 Dec 2020 at 17:37, Hongtao Liu wrote:
> > > >
> > > > On Mon, Dec 7, 2020 at 7:11 PM Prathamesh Kulkarni
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98223
Rainer Orth changed:
What|Removed |Added
Target Milestone|--- |11.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98223
Bug ID: 98223
Summary: gcc.dg/analyzer/pr94851-1.c XPASSes
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
On Wed, 9 Dec 2020 at 15:52, Hongtao Liu wrote:
>
> On Wed, Dec 9, 2020 at 5:22 PM Prathamesh Kulkarni via Gcc-patches
> wrote:
> >
> > On Wed, 9 Dec 2020 at 00:29, sunil.k.pandey wrote:
> > >
> > > On Linux/x86_64,
> > >
> > > 3a6e3ad38a17a03ee0139b49a0946e7b9ded1eb1 is the first bad commit
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91384
--- Comment #8 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #1)
> Started with r223689. Though, generally that change looks like a useful
> GIMPLE canonicalization.
How about we amend the above change to:
diff --git
This removes an odd special-case of VECTOR_BOOLEAN_TYPE_P typed
conversions from vectorizable_assignment that was obsoleted by
making all integer mode VECTOR_BOOLEAN_TYPE_P types have 1-bit
precision bool components with 605c2a393d3a2db8
Bootstrapped and tested on x86_64-unknown-linux-gnu,
On Thu, 10 Dec 2020, Richard Sandiford wrote:
> Richard Biener writes:
> >> @@ -812,33 +997,80 @@ split_constant_offset_1 (tree type, tree op0, enum
> >> tree_code code, tree op1,
> >> }
> >> }
> >>
> >> -/* Expresses EXP as VAR + OFF, where off is a constant. The type of OFF
> >> -
On Tue, 8 Dec 2020 at 15:00, Kyrylo Tkachov wrote:
>
>
> > -Original Message-
> > From: Christophe Lyon
> > Sent: 08 December 2020 13:59
> > To: Kyrylo Tkachov
> > Cc: gcc-patches@gcc.gnu.org
> > Subject: Re: [PATCH 1/5] arm: Auto-vectorization for MVE: vand
> >
> > On Tue, 8 Dec 2020
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71899
--- Comment #5 from Jonathan Wakely ---
LWG 2743 seems to be the wrong issue, I think https://wg21.link/lwg2114 is the
right one.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98222
Martin Liška changed:
What|Removed |Added
Known to work||10.2.0
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95396
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Summary|[8/9/10/11 Regression] GCC |[8/9/10 Regression] GCC
Richard Biener writes:
>> @@ -812,33 +997,80 @@ split_constant_offset_1 (tree type, tree op0, enum
>> tree_code code, tree op1,
>> }
>> }
>>
>> -/* Expresses EXP as VAR + OFF, where off is a constant. The type of OFF
>> - will be ssizetype. */
>> +/* If EXP has pointer type, try to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67214
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97929
Joel Hutton changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98221
--- Comment #4 from Richard Biener ---
(In reply to Andreas Krebbel from comment #3)
> tree-vect-loop-manip.c: vect_maybe_permute_loop_masks also emits
> VEC_UNPACKS_HI/LO dependent on BYTES_BIG_ENDIAN.
>
> What is the expectation wrt the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97929
--- Comment #3 from CVS Commits ---
The master branch has been updated by Joel Hutton :
https://gcc.gnu.org/g:f5b902a9af9d1cce6c540c7f71e02e22e45c23ef
commit r11-5903-gf5b902a9af9d1cce6c540c7f71e02e22e45c23ef
Author: Joel Hutton
Date: Thu
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20201210 (experimental) [master revision
66dea8899df:e246cb295db:680e4202f23ce74f3b26c7f090b9d22a56765554] (GCC)
[518] %
[518] % gcctk -O2 small.c; ./a.out
[519] %
[519] % gcctk -O3 small.c
small.c: In function ‘f
On Wed, 9 Dec 2020, Richard Sandiford wrote:
> PR98069 is about a case in which split_constant_offset miscategorises
> an expression of the form:
>
> int foo;
> …
> POINTER_PLUS_EXPR
>
> as:
>
> base: base
> offset: (sizetype) (-foo) * size
> init: INT_MIN * size
>
> “-foo”
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98221
--- Comment #3 from Andreas Krebbel ---
tree-vect-loop-manip.c: vect_maybe_permute_loop_masks also emits
VEC_UNPACKS_HI/LO dependent on BYTES_BIG_ENDIAN.
What is the expectation wrt the meaning of hi/lo in RTL standard names? I
couldn't find it
> 2020-12-10 Jakub Jelinek
>
> PR rtl-optimization/98212
> * dojump.c (do_compare_rtx_and_jump): Change computation of
> first_prob for and_them and don't invert prob around it.
>
> * gcc.dg/predict-8.c: Adjust expected probability.
>
> --- gcc/dojump.c.jj
On Thu, 10 Dec 2020, Joel Hutton wrote:
> Hi all,
>
> This patch addresses PR97929 by adding a missing case for WIDEN_PLUS/MINUS in
> vect_get_smallest_scalar_type. It also introduces a test to check for
> regression.
>
> One thing to note is that I saw a failure on c-c++-common/builtins.c
On Thu, 10 Dec 2020, Joel Hutton wrote:
> Hi all,
>
> This adds missing pretty print for WIDEN_PLUS/MINUS and
> VEC_WIDEN_PLUS/MINUS_HI/LO
>
> Bootstrapped and regression tested all together on aarch64.
>
> Ok for trunk?
OK.
> Add WIDEN_PLUS, WIDEN_MINUS pretty print
>
> Add 'w+'/'w-' as
On Wed, 9 Dec 2020, Bernd Edlinger wrote:
> On 12/8/20 7:57 PM, Bernd Edlinger wrote:
> > On 12/8/20 11:35 AM, Richard Biener wrote:
> >>
> >> + {
> >> + /* Remove a nonbind marker when the outer scope of the
> >> + inline function is completely removed. */
> >> +
This adjusts the SLP build to allow a pattern root stmt to be
built from scalars. I've noticed this in PR98211 where we fail
to promote a SLP subtree to a simple splat operation and instead
emit a series of uniform vector operations. The bb-slp-div-1.c
testcase is now vectorized on x86_64 but
Pattern recog incompletely handles some bool cases but we shouldn't
miscompile as a result but not vectorize. Unfortunately
vectorizable_assignment lets invalid conversions (that
vectorizable_conversion rejects) slip through. The following
rectifies that.
Bootstrapped and tested on
Hello.
In C FE we have troubles to instrument top-level pointer comparison
(and subtraction):
/home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/asan/pr98204.c:5:1:
internal compiler error: in pointer_diff, at c/c-typeck.c:3954
5 | static long i=((char*)&(v.c)-(char*));
| ^~
On Wed, 9 Dec 2020, Prathamesh Kulkarni wrote:
> On Tue, 8 Dec 2020 at 14:36, Prathamesh Kulkarni
> wrote:
> >
> > On Mon, 7 Dec 2020 at 17:37, Hongtao Liu wrote:
> > >
> > > On Mon, Dec 7, 2020 at 7:11 PM Prathamesh Kulkarni
> > > wrote:
> > > >
> > > > On Mon, 7 Dec 2020 at 16:15, Hongtao
On Wed, 9 Dec 2020, Prathamesh Kulkarni wrote:
> On Tue, 8 Dec 2020 at 14:36, Prathamesh Kulkarni
> wrote:
> >
> > On Mon, 7 Dec 2020 at 17:37, Hongtao Liu wrote:
> > >
> > > On Mon, Dec 7, 2020 at 7:11 PM Prathamesh Kulkarni
> > > wrote:
> > > >
> > > > On Mon, 7 Dec 2020 at 16:15, Hongtao
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98211
--- Comment #11 from Richard Biener ---
(In reply to rsand...@gcc.gnu.org from comment #8)
> (In reply to Richard Biener from comment #7)
> > Hmm, OK, so besides the incomplete bool pattern matching the issue seems to
> > be that while we reject
101 - 200 of 260 matches
Mail list logo
