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.
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=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=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=97474
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
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=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=97499
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
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=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=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=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=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 #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=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=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=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=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=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=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=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=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 #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=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=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=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=55394
Sergei Trofimovich changed:
What|Removed |Added
CC||slyfox at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97485
Sergei Trofimovich changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONF
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=97497
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
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=97132
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
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=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=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=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=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=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=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=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=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=94169
David Malcolm changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org
--- Comment
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=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=97438
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Last reconfirmed|
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
--- 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=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=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=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=97409
Jim Wilson changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
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=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=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=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=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=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=97496
Martin Liška changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
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=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
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=97495
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
Ever confirmed|0
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=93232
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
Resolut
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=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=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=97493
Richard Biener changed:
What|Removed |Added
Status|RESOLVED|WAITING
Last reconfirmed|
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=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=97445
Martin Liška changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org,
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
--- Comment #15 from Martin Liška ---
Created attachment 49401
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49401&action=edit
x86_64 pre-processed source file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
Martin Liška changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97471
Nathan Sidwell changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97461
--- Comment #10 from Martin Liška ---
> Hmm, it seems to me that having some entries prealocated by default
> would be way to avoid this problem in majority cases w/o having to
> modify the upstream packages.
I tend to the same. I'm going to pre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97461
--- Comment #9 from Jan Hubicka ---
>
> They have the very same problem when I disable a statically pre-allocated
> buffers with -mllvm -vp-static-alloc=0:
>
> Program received signal SIGILL, Illegal instruction.
> 0x004014e6 in calloc
>
> They have the very same problem when I disable a statically pre-allocated
> buffers with -mllvm -vp-static-alloc=0:
>
> Program received signal SIGILL, Illegal instruction.
> 0x004014e6 in calloc (nmemb=1, size=8) at pr97461.c:103
> 103 if (malloc_depth != 0) __builtin_trap();
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97461
--- Comment #8 from Martin Liška ---
(In reply to Jan Hubicka from comment #7)
> > No. The only thing we support is a recursive malloc as seen in:
> > ./gcc/testsuite/gcc.dg/tree-prof/indir-call-prof-malloc.c
> >
> > It was added in g:bc2b1a232b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97388
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97489
David Malcolm changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #2 from David Malco
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97493
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97493
Bug ID: 97493
Summary: generate wrong code with "-Os -fno-toplevel-reorder
-frename-registers"
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
> No. The only thing we support is a recursive malloc as seen in:
> ./gcc/testsuite/gcc.dg/tree-prof/indir-call-prof-malloc.c
>
> It was added in g:bc2b1a232b1825b421a1aaa21a0865b2d1e4e08c as we use a
> statically allocated buffer when we recursively entry allocate_gcov_kvp.
>
> However this is d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97461
--- Comment #7 from Jan Hubicka ---
> No. The only thing we support is a recursive malloc as seen in:
> ./gcc/testsuite/gcc.dg/tree-prof/indir-call-prof-malloc.c
>
> It was added in g:bc2b1a232b1825b421a1aaa21a0865b2d1e4e08c as we use a
> static
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97461
--- Comment #6 from Martin Liška ---
(In reply to Richard Biener from comment #5)
> Hmm, is the TOPN allocation strathegy configurable? I wonder whether we have
> to resort to an alternate allocation scheme (mmap/sbrk), avoiding libc?
No. The o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #23 from Peter Bergner ---
(In reply to Richard Biener from comment #22)
> OK, so the fix here is quite obviously to simply drop the
> build_distinct_type_copy calls:
Thanks richi, I'll put the patch through a bootstrap/regtest cycle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97477
--- Comment #2 from Dalon Work ---
(In reply to Richard Biener from comment #1)
> IIRC restrict is not official C++ but I agree it should be accepted.
You are correct, it is not official c++. g++ accepts and uses the '__restrict'
keyword in c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97492
Bug ID: 97492
Summary: arm cortex-m0+ or constant value can use adds
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #13 from Christophe Leroy ---
(In reply to Christophe Leroy from comment #10)
> (In reply to Jakub Jelinek from comment #9)
> > What I was suggesting is build with make V=1 and copy/paste the command line
> > used to compile a particu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #12 from Christophe Leroy ---
Created attachment 49399
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49399&action=edit
pipe.s from build of fs/pipe.o
fs/pipe.o includes an instance of get_order() allthouth get_order() is decla
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #11 from Christophe Leroy ---
Created attachment 49398
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49398&action=edit
Build of fs/pipe.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97485
--- Comment #3 from Jonathan Wakely ---
Looks like a dup of PR 55394
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97491
Bug ID: 97491
Summary: Wrong restriction for VALUE arguments of pure
procedures
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #10 from Christophe Leroy ---
(In reply to Jakub Jelinek from comment #9)
> What I was suggesting is build with make V=1 and copy/paste the command line
> used to compile a particular source file and append -save-temps to those
> opti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80928
--- Comment #29 from Richard Biener ---
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 < 1020; i += 4)
{
int suma = a[i];
int sumb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97488
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97488
--- Comment #2 from CVS Commits ---
The master branch has been updated by Aldy Hernandez :
https://gcc.gnu.org/g:2d2f4ffc97a8510e72a99ee106159aeae2627a42
commit r11-4070-g2d2f4ffc97a8510e72a99ee106159aeae2627a42
Author: Aldy Hernandez
Date:
1 - 100 of 174 matches
Mail list logo
