https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98232
Richard Biener changed:
What|Removed |Added
Summary|[9 branch] [regression] ICE |[9 Regression] ICE when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98228
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |11.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98227
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |11.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98234
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |11.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98234
Bug ID: 98234
Summary: [11 Regression] OOM at -O2 for PR91257 testcase
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68778
Ev Drikos changed:
What|Removed |Added
CC||drikosev at gmail dot com
--- Comment #6 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98233
Bug ID: 98233
Summary: A small bug in stl
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98232
Bug ID: 98232
Summary: [9 branch] [regression] ICE when compiling libreoffice
Product: gcc
Version: 9.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98231
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98231
Bug ID: 98231
Summary: [11 Regression] bogus error: no match for ‘operator<<’
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98208
--- Comment #10 from Ilya Leoshkevich ---
I've posted the combined fixincludes/tests/base/sys/types.h + genfixes patch
here: https://gcc.gnu.org/pipermail/gcc-patches/2020-December/561601.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98212
Jakub Jelinek changed:
What|Removed |Added
Summary|[10/11 Regression] X86 |[10 Regression] X86
|u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98212
--- Comment #8 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:a5c05005499dd323296008fda4f414d8647adf0c
commit r11-5923-ga5c05005499dd323296008fda4f414d8647adf0c
Author: Jakub Jelinek
Date: Fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98226
--- Comment #5 from Jonathan Wakely ---
I've removed some redundant code from them, but not changed the indirection
that this PR complains about. I don't plan to change that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98226
--- Comment #4 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:2ea62857a3fbdf091ba38cbb62e98dc76b198e2e
commit r11-5922-g2ea62857a3fbdf091ba38cbb62e98dc76b198e2e
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98230
--- Comment #9 from Adam Van Ymeren ---
Awesome thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98174
--- Comment #4 from CVS Commits ---
The master branch has been updated by Andrew Macleod :
https://gcc.gnu.org/g:7f359556a772e26eabf8d31e53aae1de6f2f200d
commit r11-5921-g7f359556a772e26eabf8d31e53aae1de6f2f200d
Author: Andrew MacLeod
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98230
Eric Botcazou changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98230
--- Comment #7 from CVS Commits ---
The releases/gcc-8 branch has been updated by Eric Botcazou
:
https://gcc.gnu.org/g:87c40733898283f0d1e48bcbf8055c2718064e77
commit r8-10673-g87c40733898283f0d1e48bcbf8055c2718064e77
Author: Ed Schonberg
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98230
--- Comment #6 from CVS Commits ---
The releases/gcc-9 branch has been updated by Eric Botcazou
:
https://gcc.gnu.org/g:da6e672dc9bbedb993a5fea498954f0ca861b7ec
commit r9-9107-gda6e672dc9bbedb993a5fea498954f0ca861b7ec
Author: Ed Schonberg
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98230
--- Comment #5 from CVS Commits ---
The releases/gcc-10 branch has been updated by Eric Botcazou
:
https://gcc.gnu.org/g:bc7d2977d108ed00c30c9f21d5701f28ffb50f29
commit r10-9137-gbc7d2977d108ed00c30c9f21d5701f28ffb50f29
Author: Ed Schonberg
Da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98230
--- Comment #4 from CVS Commits ---
The master branch has been updated by Eric Botcazou :
https://gcc.gnu.org/g:779bf1823ced0814803d2be7f7ded0317e70140c
commit r11-5920-g779bf1823ced0814803d2be7f7ded0317e70140c
Author: Ed Schonberg
Date: Thu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91506
Marek Polacek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91506
--- Comment #3 from CVS Commits ---
The master branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:96a5c483afbe0cb3fb037641bf2b5658531d9255
commit r11-5917-g96a5c483afbe0cb3fb037641bf2b5658531d9255
Author: Marek Polacek
Date: Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98230
Eric Botcazou changed:
What|Removed |Added
Target Milestone|--- |8.5
Summary|Incorrect Type'Mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98230
Eric Botcazou changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot
gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98230
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91506
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63707
--- Comment #13 from Jakub Jelinek ---
At least for #c5 the important difference between that testcase and // ~Child
();
which is accepted is I think since
r0-113052-ge2df21bfc6c81b4bc410a42002c8427454ffa628
in the cp/init.c (perform_member_init)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98230
--- Comment #1 from Adam Van Ymeren ---
Forgot some details
=== output of gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Targe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98230
Bug ID: 98230
Summary: Bug in Type'Modulus during a loop whose range is
computed by a variable
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59238
--- Comment #6 from Jakub Jelinek ---
Fixed on the trunk now, not sure if this should be eventually backported or
not.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98169
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |11.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98169
--- Comment #7 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #6)
> Not familiar with the 64-bit vector support myself, CCing Uros on that.
PR98218
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98229
--- Comment #1 from Jakub Jelinek ---
Created attachment 49731
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49731&action=edit
gcc11-pr98229.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98226
--- Comment #3 from Andrew Pinski ---
(In reply to Jonathan Wakely from comment #2)
> Oh, but you didn't enable any optimization at all, so who cares about the
> performance?
I was thinking the same.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98229
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98216
--- Comment #4 from Emmanuel Le Trong ---
Looking at the symbols in your snippet:
$ nm -C toto | grep wrapper
00402030 u wrapper::arr
That looks like a weird NaN to me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98169
Jakub Jelinek changed:
What|Removed |Added
CC||uros at gcc dot gnu.org
--- Comment #6 f
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20201210 (experimental) [master revision
b46dd03fe94:30c63a5c82a:afc14c8d0a9e7af13698a7eec84226a3cc4b0e67] (GCC)
[556] %
[556] % gcctk -m32 -O0 -c small.c
[557] %
[557] % gcctk -m32 -O1 -c small.c
during RTL pass: expand
small.c: In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98226
--- Comment #2 from Jonathan Wakely ---
Oh, but you didn't enable any optimization at all, so who cares about the
performance?
20201210 on s390x-linux-gnu
/<>/build/./gcc/xgcc -B/<>/build/./gcc/ -B/
usr/lib/gcc-snapshot/s390x-linux-gnu/bin/
-B/usr/lib/gcc-snapshot/s390x-linux-gnu/lib/ -isystem
/usr/lib/gcc-snapshot/s390x-
linux-gnu/include -isystem /usr/lib/gcc-snapshot/s390x-linux-gnu/sys-include
-c -g -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98226
--- Comment #1 from Jonathan Wakely ---
This seems like an optimizer bug. There is no way I'm going to repeat the
entire body of countr_zero in countr_one.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96124
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98216
--- Comment #3 from Jonathan Wakely ---
Reduced:
struct an_array
{
constexpr bool operator==(const an_array& a) const { return d == a.d; }
double d;
};
constexpr auto
add_array (an_array a, an_array b)
{
a.d += b.d;
return a;
}
templa
on riscv64-linux-gnu
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
Assignee: unassigned at gcc dot gnu.org
Reporter: doko at debian dot org
Target Milestone: ---
tru
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
{
f
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
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++
Assigne
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|---
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
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 to
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 sto
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 a
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 fr
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97727
akrl at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96710
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
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
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
Targ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68451
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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: Th
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97875
Christophe Lyon changed:
What|Removed |Added
Status|WAITING |ASSIGNED
--- Comment #6 from Christoph
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
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 compare
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 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95285
Wilco changed:
What|Removed |Added
CC||wdijkstr at arm dot com
--- Comment #16 from Wil
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: testsui
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 w
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 usu
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|
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
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 a/gcc/matc
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
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 meanin
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 De
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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98190
--- Comment #16 from rguenther at suse dot de ---
On Thu, 10 Dec 2020, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98190
>
> --- Comment #15 from Jakub Jelinek ---
> Created attachment 49727
> --> https://g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98211
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98211
--- Comment #9 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:76c09f2af9d8ab9c760d860626f069d12d86f0a9
commit r11-5901-g76c09f2af9d8ab9c760d860626f069d12d86f0a9
Author: Richard Biener
Date:
1 - 100 of 128 matches
Mail list logo
