https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97494
Bug ID: 97494
Summary: [11 regression] several vector test case failures
starting with r11-3966
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
Martin Liška changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #17 from Jan Hubicka ---
> The following happens:
>
> get_order is called by kmalloc_large which is called in kmalloc. And kmalloc
> calls the function for larger allocations. Problem is that we eliminate all
> calls to get_order lat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97494
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=97493
Richard Biener changed:
What|Removed |Added
Status|RESOLVED|WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #18 from Martin Liška ---
(In reply to Jan Hubicka from comment #17)
> > The following happens:
> >
> > get_order is called by kmalloc_large which is called in kmalloc. And kmalloc
> > calls the function for larger allocations. Probl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80928
--- Comment #30 from Richard Biener ---
(In reply to Richard Biener from comment #29)
> So a testcase for missed outer loop induction SLP (and nested cycle SLP) is
> for example
>
> int a[1024];
> void foo (unsigned n)
> {
> for (int i = 0; i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97313
--- Comment #5 from Vladimir Makarov ---
(In reply to Martin Liška from comment #4)
> Thank you Vladimir for the fix.
> Can we close it now?
There are no complaints about the patch for more a week. So I guess the PR can
be closed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97493
--- Comment #3 from Jakub Jelinek ---
I can't reproduce it with -fno-strict-aliasing, only when that option is
missing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93232
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
Resolut
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97495
Bug ID: 97495
Summary: -Wstringop-overflow where -Warray-bounds would be more
appropriate
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97495
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97496
Bug ID: 97496
Summary: ice during during GIMPLE pass: cddce
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #19 from Jan Hubicka ---
get_order unwinds to:
[local count: 1073741824]:
_1 = __builtin_constant_p (size_68(D));
if (_1 != 0)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 536870913]:
if (size_68(D) == 0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97496
--- Comment #2 from Martin Liška ---
for SSA_NAME: vect__16.4_34 in statement:
# .MEM_29 = VDEF <.MEM_7(D)>
MEM [(int *)&b] = vect__16.4_34;
during GIMPLE pass: slp
dump file: pr97496.c.169t.slp1
pr97496.c:3:6: internal compiler error: verify_ss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97496
Martin Liška changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #20 from Jan Hubicka ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
>
> --- Comment #19 from Jan Hubicka ---
> get_order unwinds to:
>
>[local count: 1073741824]:
> _1 = __builtin_constant_p (size_68(D));
> if (_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97497
Bug ID: 97497
Summary: gcse wrong code generation with partial register
clobbers
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97497
--- Comment #1 from Andreas Krebbel ---
Created attachment 49402
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49402&action=edit
Proposed fix
With the patch only regs are considered which aren't "fixed" assuming that for
fixed_regs the ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #21 from Jakub Jelinek ---
(In reply to Jan Hubicka from comment #20)
> > _2 = size_68(D) + 18446744073709551615;
> > _3 = __builtin_constant_p (_2);
> Forgot to note, things would be easier if we folded this to _1 :)
> Among othe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #22 from Jan Hubicka ---
> Maybe better just have a match.pd rule that would fold
> y = z binop cst;
> x = __builtin_constant_p (y);
> to
> x = __builtin_constant_p (z);
> and let SCCVN do the rest (or do it in fwprop or whatever else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97456
--- Comment #8 from CVS Commits ---
The master branch has been updated by Martin Jambor :
https://gcc.gnu.org/g:619f91eaa8c8a50f1f9d3e7b96ee837037f0e806
commit r11-4075-g619f91eaa8c8a50f1f9d3e7b96ee837037f0e806
Author: Martin Jambor
Date: Mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97409
Jim Wilson changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97487
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #24 from Peter Bergner ---
(In reply to Richard Biener from comment #22)
>tree oi_uns_type = make_unsigned_type (256);
> - vector_pair_type_node = build_distinct_type_copy (oi_uns_type);
>SET_TYPE_MODE (vector_pai
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97478
--- Comment #2 from Jakub Jelinek ---
It breaks bootstrap on x86_64-linux and i686-linux too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97438
--- Comment #3 from CVS Commits ---
The master branch has been updated by Iain D Sandoe :
https://gcc.gnu.org/g:b003c4b14b3f889e6707db68d2c6545eda7a203b
commit r11-4076-gb003c4b14b3f889e6707db68d2c6545eda7a203b
Author: Iain Sandoe
Date: Sat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97481
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #2 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97438
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #25 from Andrew Macleod ---
(In reply to Peter Bergner from comment #24)
> (In reply to Richard Biener from comment #22)
> >tree oi_uns_type = make_unsigned_type (256);
> > - vector_pair_type_node = build_distinct_type_co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97491
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
L
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94169
David Malcolm changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #26 from Peter Bergner ---
(In reply to Andrew Macleod from comment #25)
> (In reply to Peter Bergner from comment #24)
> > (In reply to Richard Biener from comment #22)
> > >tree oi_uns_type = make_unsigned_type (256);
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97481
--- Comment #3 from fdlbxtqi ---
(In reply to Jim Wilson from comment #2)
> riscv-unknown-linux-gnu is not a supported target. You must use either
> riscv32-unknown-linux-gnu or riscv64-unknwon-linux-gnu. Both compilers
> support both word size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94799
--- Comment #13 from Marek Polacek ---
The fix may be as easy as this:
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -23812,8 +23812,8 @@ cp_parser_class_name (cp_parser *parser,
/* Any name names a type if we're following the `typename' ke
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97063
--- Comment #8 from CVS Commits ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:53325dec8e01775af3eb9231d10f2afa1b8d5559
commit r10-8912-g53325dec8e01775af3eb9231d10f2afa1b8d5559
Author: Harald Anlauf
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #27 from Peter Bergner ---
(In reply to Peter Bergner from comment #26)
> (In reply to Andrew Macleod from comment #25)
> > Wonder if it was suppose to be something like:
>
> Maybe? :-) I'll report back how the build does with this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97132
--- Comment #6 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:90c9484b12dd8a05b5314f5cb9847df46024a194
commit r10-8913-g90c9484b12dd8a05b5314f5cb9847df46024a194
Author: Jonathan Wakel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97132
--- Comment #7 from CVS Commits ---
The releases/gcc-9 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:77923ad01415f6e72af844cbef5227f5b5a9fb4b
commit r9-9003-g77923ad01415f6e72af844cbef5227f5b5a9fb4b
Author: Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97481
--- Comment #4 from fdlbxtqi ---
(In reply to Jim Wilson from comment #2)
> riscv-unknown-linux-gnu is not a supported target. You must use either
> riscv32-unknown-linux-gnu or riscv64-unknwon-linux-gnu. Both compilers
> support both word size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97474
--- Comment #8 from joseph at codesourcery dot com ---
p and p->p are two different pointer objects, the first restricted, so
it's not valid to use p->p to access an object that's also accessed via p
(and modified).
This is different from the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97132
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97471
Nathan Sidwell changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97497
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
me/john/gcc-head/ --enable-languages=c,c++,lto
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20201019 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
'-dumpdir' &#x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97485
Sergei Trofimovich changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55394
Sergei Trofimovich changed:
What|Removed |Added
CC||slyfox at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93297
--- Comment #8 from John McFarlane ---
And this input can generate an ICE even with the -std=c++2a switch:
template class a;
template a()->a;
template <2> using c a;
static_assert(c{ }
CL: g++ -v -std=c++2a source.cpp
Online
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97481
--- Comment #5 from fdlbxtqi ---
(In reply to Jim Wilson from comment #2)
> riscv-unknown-linux-gnu is not a supported target. You must use either
> riscv32-unknown-linux-gnu or riscv64-unknwon-linux-gnu. Both compilers
> support both word size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94169
--- Comment #4 from Martin Sebor ---
Yes. The recent proposal to change their signature to return const char* was
rejected in WG14 thanks to source compatibility concerns:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2526.htm
http://www.op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #28 from Peter Bergner ---
(In reply to Andrew Macleod from comment #25)
> Wonder if it was suppose to be something like:
>
>
>/* Vector pair and vector quad support. */
>if (TARGET_EXTRA_BUILTINS)
> {
> - tree oi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #29 from CVS Commits ---
The master branch has been updated by Andrew Macleod :
https://gcc.gnu.org/g:6e02de946125c36871bd4d8eff21f7f88f01a8aa
commit r11-4080-g6e02de946125c36871bd4d8eff21f7f88f01a8aa
Author: Andrew MacLeod
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #30 from Andrew Macleod ---
On 10/19/20 6:40 PM, bergner at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
>
> --- Comment #28 from Peter Bergner ---
> (In reply to Andrew Macleod from comment #25)
>> Won
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97498
Bug ID: 97498
Summary: #pragma GCC diagnostic ignored "-Wunused-function"
inconsistent
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97473
Hans-Peter Nilsson changed:
What|Removed |Added
CC||hp at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97499
Bug ID: 97499
Summary: build dos cross compiler ICE
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97499
--- Comment #1 from fdlbxtqi ---
/gcc_dos_build/./gcc/xgcc -B/gcc_dos_build/./gcc/
-B/i586-pc-msdosdjgpp/i586-pc-msdosdjgpp/bin/
-B/i586-pc-msdosdjgpp/i586-pc-msdosdjgpp/lib/ -isystem
/i586-pc-msdosdjgpp/i586-pc-msdosdjgpp/include -isystem
/i586-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94799
--- Comment #14 from Marek Polacek ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556517.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95310
--- Comment #4 from Patrick Palka ---
(In reply to ensadc from comment #3)
> When verifying the fix, I noticed a new bug:
Thanks for the heads up.
>
>
> template requires true
> using iter_reference_t = decltype(*T{});
>
> template
> s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #23 from Christophe Leroy ---
(In reply to Jan Hubicka from comment #19)
>
> It is always possible to always_inline functions that are intended to be
> always inlined.
> Honza
Yes and I sent a patch for that to the Linux kernel, but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #25 from Christophe Leroy ---
Created attachment 49404
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49404&action=edit
pipe.s from build of fs/pipe.o with GCC 9.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #24 from Christophe Leroy ---
Created attachment 49403
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49403&action=edit
pipe.i from build of fs/pipe.o with GCC 9.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97497
--- Comment #3 from Andreas Krebbel ---
Created attachment 49405
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49405&action=edit
testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97438
--- Comment #5 from Avi Kivity ---
No pressing reason to backport (for me gcc coroutines are useless anyway due to
95137)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97496
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97499
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97497
--- Comment #4 from Andreas Krebbel ---
Reading from symbol t uses the GOT pointer in r12. The call then partially
clobbers r12 but does not affect the lower 32 bits where the GOT pointer
resides. So the GOT pointer stays in fact live across the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #26 from Christophe Leroy ---
In reality it is not perfect with GCC 9.2, but that's better, only two
instances are unused.
[root@po17688vm linux-powerpc]# ppc-linux-objdump -d vmlinux | grep get_order
c00c0470 :
c013e238 :
c0225f68
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #31 from Richard Biener ---
(In reply to Andrew Macleod from comment #30)
> On 10/19/20 6:40 PM, bergner at gcc dot gnu.org wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
> >
> > --- Comment #28 from Peter Bergner ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97474
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
>
> --- Comment #23 from Christophe Leroy ---
> (In reply to Jan Hubicka from comment #19)
> >
> > It is always possible to always_inline functions that are intended to be
> > always inlined.
> > Honza
>
> Yes and I sent a patch for that to t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #27 from Jan Hubicka ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
>
> --- Comment #23 from Christophe Leroy ---
> (In reply to Jan Hubicka from comment #19)
> >
> > It is always possible to always_inline functions that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97474
Jakub Jelinek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97474
--- Comment #11 from Jakub Jelinek ---
(In reply to Jakub Jelinek from comment #10)
> I think the place in the C++ FE that adds restrict here is:
> tree
> type_passed_as (tree type)
> {
> /* Pass classes with copy ctors by invisible reference.
101 - 174 of 174 matches
Mail list logo
