https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53298
--- Comment #14 from markeggleston at gcc dot gnu.org ---
The test case in comment 7 proved trickier to track down.
The ICE occurs in this code:
/* Components can correspond to fields of different containing
types, as components are creat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96989
Richard Biener changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
Key
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96988
Richard Biener changed:
What|Removed |Added
Component|middle-end |c++
Blocks|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96987
Richard Biener changed:
What|Removed |Added
Keywords||diagnostic
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96986
Richard Biener changed:
What|Removed |Added
Priority|P3 |P4
Summary|[8 Regression] Ex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96984
--- Comment #2 from Richard Biener ---
FRE does nothing wrong - it eliminates an add.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53298
--- Comment #13 from markeggleston at gcc dot gnu.org ---
The test case in comment 0 is fixed by:
trans-array.c
@ -3638,8 +3638,11 @@ gfc_conv_array_ref (gfc_se * se, gfc_array_ref * ar,
gfc_expr *expr,
/* Handle scalarized references separat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96990
--- Comment #1 from Andrew Pinski ---
I think it was only broken for GCC 10.2.0 and has already been fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96933
--- Comment #10 from Kewen Lin ---
(In reply to Segher Boessenkool from comment #9)
> I'm not sure what you mean.
>
> vmrglb merges the vectors
> abcdefghijklmnop
> and
> ABCDEFGHIJKLMNOP
> to
> iIjJkKlLmMnNoOpP
>
> ... ah, I see what you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96948
--- Comment #5 from Kirill Müller ---
Solved by https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553418.html.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96990
Bug ID: 96990
Summary: Regression in aarch64 struct vector member
initialization
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96973
--- Comment #12 from Ian Lance Taylor ---
Thanks, that part should now be fixed also.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96973
--- Comment #11 from CVS Commits ---
The master branch has been updated by Ian Lance Taylor :
https://gcc.gnu.org/g:181f877b6c0e365c940b117c306e7309e19ffd89
commit r11-3064-g181f877b6c0e365c940b117c306e7309e19ffd89
Author: Ian Lance Taylor
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96942
--- Comment #33 from Dmitriy Ovdienko ---
@Jonathan Wakely
I have one idea to improve code of p_m_r
I expect that allocation are very rare operation. If true, it makes sense to
add __unlikelly to `if (!__p)` inside the `do_allocate` member func
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96989
Bug ID: 96989
Summary: SSA_NAMEs in Wuninitialized warning messages after
r11-959
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96973
--- Comment #10 from Francois-Xavier Coudert ---
Hi Ian,
There is still the issue in comment #1: none of the mechanisms for finding the
executable path are currently working on darwin (at least in the circumstances
I am testing in).
- state->fi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96942
--- Comment #32 from Dmitriy Ovdienko ---
What bothers me is does why Rust generate less cpucache-references.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96942
--- Comment #31 from Dmitriy Ovdienko ---
Created attachment 49202
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49202&action=edit
Modified solution with 2-level memory pools
I believe I'm done with this task. Attached is a solution based
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96988
Bug ID: 96988
Summary: Bad/missing warnings when returning a temporary from
an inlined function
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96973
Ian Lance Taylor changed:
What|Removed |Added
Resolution|--- |FIXED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96942
--- Comment #30 from Dmitriy Ovdienko ---
> Dividing estimated size by 2 to counter the over-allocation effect:
Good idea... but it smells bad :)
What if someone change allocation algorithm...?
> Since the poolSize function actually returns siz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983
--- Comment #5 from Peter Bergner ---
(In reply to seurer from comment #3)
> That said, should the dg-require-effective-target fortran_real_16 "work" on
> powerpc64?
REAL*16 is a 16 byte double, correct? Ie, our long double? Therefore, it
shou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96942
--- Comment #29 from Dmitriy Ovdienko ---
Table above isn't readable. Value for `cache-references` .. faults
are divided by 1000
Sorry for flood.
| CPU counter | Rust | C++ before |C++ now | C++ malloc |
|--|-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96987
Bug ID: 96987
Summary: [11 regression] warning 'ptr' may be used
uninitialized const pointer parameter
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96942
--- Comment #28 from Dmitriy Ovdienko ---
Added CPU counters for malloc-based allocator as a base point
| CPU counter | Rust | C++ before |C++ now | C++
malloc |
|--|---:|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96942
--- Comment #27 from Dmitriy Ovdienko ---
Following are CPU counters I've got for improved C++ test vs Rust and original
C++ test by Danial Klimkin
| CPU counter | Rust | C++ before |C++ now |
|--|-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96973
--- Comment #8 from CVS Commits ---
The master branch has been updated by Ian Lance Taylor :
https://gcc.gnu.org/g:488e9e6dea3262a11307592e9aad87a97c8d
commit r11-3055-g488e9e6dea3262a11307592e9aad87a97c8d
Author: Ian Lance Taylor
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96942
--- Comment #26 from Dmitriy Ovdienko ---
Created attachment 49201
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49201&action=edit
Modified solution (thread per iteration)
Attached is a code similar to what Rust sample is doing (parallel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96890
--- Comment #8 from CVS Commits ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:19c2bd56876302aebb2bdc20b376395931cd5041
commit r10-8718-g19c2bd56876302aebb2bdc20b376395931cd5041
Author: Harald Anlauf
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96971
Ian Lance Taylor changed:
What|Removed |Added
CC||ian at airs dot com
Resolutio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983
--- Comment #4 from seurer at gcc dot gnu.org ---
I see 6 other tests that use that:
gcc/testsuite/gfortran.dg/io_real_boz_3.f90:3:! { dg-require-effective-target
fortran_real_16 }
gcc/testsuite/gfortran.dg/io_real_boz_4.f90:3:! { dg-require-effe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96971
--- Comment #1 from CVS Commits ---
The master branch has been updated by Ian Lance Taylor :
https://gcc.gnu.org/g:651c61c3cef123d70ec3582d53b58526a8cadcf7
commit r11-3054-g651c61c3cef123d70ec3582d53b58526a8cadcf7
Author: Ian Lance Taylor
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96986
Bug ID: 96986
Summary: [8 Regression] Explicit interface required: volatile
argument for ENTRY subroutine
Product: gcc
Version: 8.3.1
Status: UNCONFIRMED
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96941
David Edelsohn changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983
--- Comment #3 from seurer at gcc dot gnu.org ---
That changes it to unsupported which gets past the FAILs.
That said, should the dg-require-effective-target fortran_real_16 "work" on
powerpc64?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96965
Segher Boessenkool changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96933
--- Comment #9 from Segher Boessenkool ---
I'm not sure what you mean.
vmrglb merges the vectors
abcdefghijklmnop
and
ABCDEFGHIJKLMNOP
to
iIjJkKlLmMnNoOpP
... ah, I see what you mean I guess.
So, use something else instead? How about vp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96985
Bug ID: 96985
Summary: c++ `noexcept` is ignored for *known* functions
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96942
--- Comment #25 from Jonathan Wakely ---
Depth = 21, Pool size = 134,217,728 Bytes
| |PMR | PMR (round64) |Malloc |
|---|||---|
| cache-references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96942
--- Comment #24 from Jonathan Wakely ---
Yes, I'm using that one, but I was testing depth=20.
The new code is a lot better for depth=18, but worse (or not much different)
for greater depths.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96942
--- Comment #23 from Alexander Monakov ---
Are you benchmarking with bt_pmr_0thrd (attached in comment #3) with depth=18?
On earlier tests there are other effects in play too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96942
--- Comment #22 from Jonathan Wakely ---
Created attachment 49199
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49199&action=edit
Patch to reduce monotonic_buffer_resource chunk sizes
(In reply to Alexander Monakov from comment #20)
> Rou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983
--- Comment #2 from anlauf at gcc dot gnu.org ---
Could you please check if adding
! { dg-skip-if "" { "powerpc*-*-*" } }
solves the issue? (That would be similar to testcase nan_7.f90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91483
--- Comment #2 from Marek Polacek ---
Related test:
void
foo ()
{
constexpr int a = 0;
constexpr const int *p = &a;
}
We just say
error: ‘& a’ is not a constant expression
but that's inadequate. clang++ now says
note: address of non-stati
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96973
--- Comment #7 from Francois-Xavier Coudert ---
Actually we're not using the other members. So how about simply:
diff --git a/libbacktrace/macho.c b/libbacktrace/macho.c
index bd737226ca6..7f093f309fb 100644
--- a/libbacktrace/macho.c
+++ b/libb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96973
--- Comment #6 from Iain Sandoe ---
(In reply to Francois-Xavier Coudert from comment #4)
from fat.h
FAT headers are always written bigendian
* at least there's no statement revoking that in the section on FAT64
* it doesn't seem that the FA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96962
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96984
Martin Sebor changed:
What|Removed |Added
Last reconfirmed||2020-09-08
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96949
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96815
Jason Cobb changed:
What|Removed |Added
CC||jason.e.cobb at gmail dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96950
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96984
Bug ID: 96984
Summary: bogus -Warray-bounds with -fsanitize due to FRE
substituting subobjects at the same address
Product: gcc
Version: 11.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96949
--- Comment #2 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:34d926dba097c4965917d09a3eedec11242c5457
commit r11-3052-g34d926dba097c4965917d09a3eedec11242c5457
Author: David Malcolm
Date: Mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96950
--- Comment #2 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:af656c401e97f9de2a8478f18278e8efb2a6cf23
commit r11-3051-gaf656c401e97f9de2a8478f18278e8efb2a6cf23
Author: David Malcolm
Date: Mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96962
--- Comment #2 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:47997a32e63b77ec88a7131a5d540f108c698661
commit r11-3050-g47997a32e63b77ec88a7131a5d540f108c698661
Author: David Malcolm
Date: Mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96980
--- Comment #1 from Jonathan Wakely ---
This is not valid C++, that's why GCC doesn't accept it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96982
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96892
--- Comment #2 from Thomas Preud'homme ---
Wouldn't it be enough to add:
"emit_move_insn (operands[3], gen_rtx_MEM(SImode, operands[3]));"
just before the line "if (TARGET_32BIT)" in stack_protect_combined_test_insn
insn pattern?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96982
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96981
--- Comment #3 from Richard Biener ---
*** Bug 96982 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |11.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983
--- Comment #1 from anlauf at gcc dot gnu.org ---
The testcase has:
! { dg-require-effective-target fortran_real_16 }
I assume that powerpc advertises supporting fortran_real_16
while it actually does not.
Suggestions?
Should the testcase be r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96043
--- Comment #3 from Richard Biener ---
Turns out gcc.dg/vect/costmodel/x86_64/costmodel-pr69297.c can be massaged to
such case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96892
--- Comment #1 from Thomas Preud'homme ---
Confirmed on GCC 11.0.0 20200908
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96981
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96979
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96937
--- Comment #5 from Simon Marchi ---
(In reply to Richard Biener from comment #3)
> Hmm, can you point out the issue in the reduced testcase? I can't see it.
> The only cloning done I see is partial inlining so does
> -fno-partial-inlining fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983
Bug ID: 96983
Summary: [11 regression] ICE compiling gfortran.dg/pr96711.f90
starting with r11-3042
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: nor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96937
--- Comment #4 from Simon Marchi ---
Created attachment 49198
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49198&action=edit
Output from creduce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96982
Bug ID: 96982
Summary: no assembler error with -O1/O2/O3, but with -O0
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96979
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |8.5
Summary|Switch with case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96979
Richard Biener changed:
What|Removed |Added
Keywords||compile-time-hog
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96981
--- Comment #1 from Richard Biener ---
on the border of being invalid I guess
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96975
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96981
Bug ID: 96981
Summary: Assembler messages: Error: missing name
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96974
Richard Biener changed:
What|Removed |Added
Target Milestone|10.4|10.3
Version|unknown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96978
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |11.0
Version|10.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96973
Iain Sandoe changed:
What|Removed |Added
CC||iains at gcc dot gnu.org
--- Comment #5 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96942
--- Comment #21 from Dmitriy Ovdienko ---
> This is only the second time
> I've ever received any indication anybody is even using the
> header, so I've not wasted my time tuning it.
I used it to create an order book :). It helped me to impro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94595
Christophe Lyon changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96767
Christophe Lyon changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96770
Christophe Lyon changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96980
Bug ID: 96980
Summary: unimplemented of variably-modified type
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96043
--- Comment #2 from Richard Biener ---
I have a patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96979
Bug ID: 96979
Summary: Switch with case values derived from constexpr
function takes unreasonable time to compile
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96951
--- Comment #5 from kab at acm dot org ---
(In reply to Martin Sebor from comment #3)
> If in the code the test case was derived from the string
> member is not necessarily meant to be a string then declaring it with
> attribute nonstring avoids t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96951
--- Comment #4 from Florian Weimer ---
Thanks.
Checking for the null byte at the end (as in comment 0) currently seems the
most convenient way. Writing those additional null bytes is not entirely free.
As an industry standard, the strlcpy functi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96973
--- Comment #4 from Francois-Xavier Coudert ---
I've identified the issue and found a fix. The problem is in the calculation of
the offset when !is_64. The current code is take the uint32_t offset value,
casting it into a uint64_t, then calling b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96978
Bug ID: 96978
Summary: [11 regression] gcc.dg/vect/bb-slp-pr92596.c causes an
ICE since r11-3025
(g095d42feed09f880f835ed74d0aa7b1ad7abd03c)
Product: gcc
Version:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96976
--- Comment #2 from Igor Chorazewicz ---
(In reply to Jonathan Wakely from comment #1)
> Fixed on trunk by r11-1571
>
> It's also fixed on the gcc-10 branch by r10-8343
Do you plan to backport it to older gcc versions?
Also, do you by any chan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96942
--- Comment #20 from Alexander Monakov ---
Round up to 64 bytes (typical cache line size).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96977
Bug ID: 96977
Summary: mangling ‘typeof’ or use ‘decltype’
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82091
Francois-Xavier Coudert changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25119
Francois-Xavier Coudert changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59068
Francois-Xavier Coudert changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63826
Francois-Xavier Coudert changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96942
--- Comment #19 from Jonathan Wakely ---
The upstream isn't necessarily malloc (although we could add a check to find
out whether it is the std::new_delete_resource() if we wanted to).
Suggestions for improvement are welcome. This is only the se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96942
--- Comment #18 from Alexander Monakov ---
Huh? malloc is capable of splitting the tail of the last page for reuse in
subsequent small allocations, why not let it do it? It will not be "wasted".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96976
--- Comment #1 from Jonathan Wakely ---
Fixed on trunk by r11-1571
It's also fixed on the gcc-10 branch by r10-8343
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96942
--- Comment #17 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #16)
> To request a power of two size from the upstream resource, so that we don't
> e.g. ask for 4090 bytes and waste the end of a page.
Or even worse, allocate
1 - 100 of 135 matches
Mail list logo
