https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96966
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2020-09-08
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96967
Richard Biener changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
Target Miles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96968
--- Comment #2 from Iain Sandoe ---
for __builtin_aarch64_get_fpcr64 () O1 the fail is:
$ ./gcc/xgcc -Bgcc ~/fpcr-test-a.c -S -O
during RTL pass: expand
.../fpcr-test-a.c: In function ‘main’:
.../fpcr-test-a.c:7:1: internal compiler error: Segm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96942
--- Comment #9 from Alexander Monakov ---
The most pronounced difference for depth=18 seems to be caused by m_b_r
over-allocating by 2x: internally it mallocs 2x of the size given to the
constructor, and then Linux pre-faults those extra pages, p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96967
Aldy Hernandez changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96932
--- Comment #1 from Tom de Vries ---
FWIW, I've tried this test-case to trigger the problem, but it runs fine:
...
$ cat libgomp/testsuite/libgomp.oacc-c-c++-common/test.c
/* { dg-do run } */
#include
#include
#define assert(COND) \
do {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96955
--- Comment #3 from Hongtao.liu ---
(In reply to Jakub Jelinek from comment #1)
> And if possible, optimize, so that if one does say
> int *p = (int *)__builtin_thread_pointer ();
> return p[4];
> or
> return p[i];
> it will not read %fs:0 into a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96963
--- Comment #3 from Gavin ---
Correct. Due to store-merging, -O2 and -O3 generate the same machine code on
both x86_64 and armv7m.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96969
Bug ID: 96969
Summary: ODR violations do not list the translation unit
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96043
Richard Biener changed:
What|Removed |Added
Assignee|marxin at gcc dot gnu.org |rguenth at gcc dot
gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96970
Bug ID: 96970
Summary: -fprofile-arcs compiled binaries are not reproducible
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96970
--- Comment #1 from Andrew Pinski ---
I thought you have to set the seed if you want a reproductable binary in this
case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96942
--- Comment #10 from Dmitriy Ovdienko ---
Looks like I know why C++ sample does not use all the CPU resources.
C++ does not load threads equally. Last thread gets the most heavy task
(MAX_DEPTH) and performs N iterations alone.
Rust code instea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95680
--- Comment #3 from CVS Commits ---
The master branch has been updated by Iain Buclaw :
https://gcc.gnu.org/g:285d81be9725acc36dc8eca48d4df506cd5e6f6f
commit r11-3047-g285d81be9725acc36dc8eca48d4df506cd5e6f6f
Author: Iain Buclaw
Date: Mon Se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96971
Bug ID: 96971
Summary: libbacktrace identifies object format as pecoff
instead of macho
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96972
Bug ID: 96972
Summary: Missed constant propagation for forward declared
constexpr in composite class
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96973
Bug ID: 96973
Summary: No backtrace for cc1 on x86_64-apple-darwin
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libbac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96973
--- Comment #1 from Francois-Xavier Coudert ---
Continuing to debug, I've added a darwin-specific implementation of
getexecname() with this patch:
diff --git a/libbacktrace/fileline.c b/libbacktrace/fileline.c
index cc1011e8b5d..3e4161e47c6 1006
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96958
--- Comment #3 from Jonathan Wakely ---
Yes, the public API for the load factor is defined in terms of float. We use a
higher precision type internally though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96973
--- Comment #2 from Francois-Xavier Coudert ---
I've gone a bit further with this, using the patch in comment #1 to fix the
executable path issue. I am now trying to make the backtrace work within
libgfortran, on a case with a known runtime error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96942
--- Comment #11 from Jonathan Wakely ---
(In reply to Alexander Monakov from comment #9)
> The most pronounced difference for depth=18 seems to be caused by m_b_r
> over-allocating by 2x: internally it mallocs 2x of the size given to the
> constr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96974
Bug ID: 96974
Summary: [10/11 Regression] ICE in
vect_get_vector_types_for_stmt compiling for SVE
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: ic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96974
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Known to fail||10.1.1, 11.0
Known to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96942
--- Comment #12 from Jonathan Wakely ---
(In reply to Alexander Monakov from comment #5)
> The main gotcha here is m_b_r does not allocate on construction, but rather
> allocates 2x of the preallocation size on first call to 'allocate', and then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96975
Bug ID: 96975
Summary: gcc cannot compile at -O0 but compiles at -O1/-O2/-O3
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96970
Bernhard M. Wiedemann changed:
What|Removed |Added
CC||gccbmw at lsmod dot de
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96942
--- Comment #13 from Jonathan Wakely ---
(In reply to Alexander Monakov from comment #9)
> I think the rest of the slowdown can be attributed to m_b_r simply doing
> more work internally compared to your bare-bones malloc allocator
The malloc-ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96942
--- Comment #14 from Alexander Monakov ---
> It adds 11 bytes to the size given to the constructor (for its internal
> bookkeeping) and then rounds up to a power of two.
What is the purpose of this rounding up?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96968
--- Comment #3 from akrl at gcc dot gnu.org ---
Confirm this was introduced by:
0d7e5fa655e59c99035bf94a46c912e369bb9fa0
"aarch64: Add 64 bit setter getter fpsr fpcr"
I'll have a look as soon as I have a slot of time.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96973
--- Comment #3 from Francois-Xavier Coudert ---
In macho_add_fat(), the code correctly identifies 2 archs, with the right types
(first i386, then x86_64). It's then calling macho_add() for the x86_64 arch,
with an foffset of 0xb000, w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96976
Bug ID: 96976
Summary: g++ reports "call of overloaded '...' is ambiguous"
when universal reference is used
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Seve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96967
--- Comment #2 from CVS Commits ---
The master branch has been updated by Aldy Hernandez :
https://gcc.gnu.org/g:19b0fed7c2d3663f0f144ca8557b6af29bafa4e3
commit r11-3049-g19b0fed7c2d3663f0f144ca8557b6af29bafa4e3
Author: Aldy Hernandez
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96967
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96942
--- Comment #15 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #12)
> m_b_r really needs a "rewind()" member to mark all allocated memory as
> unused again, without actually deallocating it and returning it to the
> upstream r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96942
--- Comment #16 from Jonathan Wakely ---
(In reply to Alexander Monakov from comment #14)
> > It adds 11 bytes to the size given to the constructor (for its internal
> > bookkeeping) and then rounds up to a power of two.
>
> What is the purpose
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
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 #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=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=63826
Francois-Xavier Coudert changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--
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=25119
Francois-Xavier Coudert changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|NEW
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=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=96942
--- Comment #20 from Alexander Monakov ---
Round up to 64 bytes (typical cache line size).
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=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=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=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=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=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=96043
--- Comment #2 from Richard Biener ---
I have a patch.
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=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=96770
Christophe Lyon changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
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=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=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=96978
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |11.0
Version|10.0
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=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=96975
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
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=96979
Richard Biener changed:
What|Removed |Added
Keywords||compile-time-hog
CC|
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=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=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=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 #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=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=96981
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
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=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=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=96983
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |11.0
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=96982
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
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=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=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=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=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=96950
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
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=96984
Martin Sebor changed:
What|Removed |Added
Last reconfirmed||2020-09-08
Status|UNCONFIRMED
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=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=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=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=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=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=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 #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 #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=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=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=96965
Segher Boessenkool changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
1 - 100 of 135 matches
Mail list logo
