https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109283
--- Comment #3 from ncm at cantrip dot org ---
Appears fixed in 13.1
Still ICEs in trunk,
Compiler-Explorer-Build-gcc-70d038235cc91ef1ea4fce519e628cfb2d297bff-binutils-2.40)
14.0.0 20230508 (experimental):
: In function 'std::generator >
sou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59498
--- Comment #22 from ncm at cantrip dot org ---
CWG 1430 seems to be about disallowing a construct that requires capturing an
alias declaration into a name mangling. This bug and at least some of those
referred to it do not ask for any
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109283
--- Comment #2 from ncm at cantrip dot org ---
Betting this one is fixed by deleting code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109291
--- Comment #2 from ncm at cantrip dot org ---
CWG 1430 is still marked Open, and is anyway only superficially
analogous. Here, there is no need for an alias to be encoded
into a type signature.
++
Assignee: unassigned at gcc dot gnu.org
Reporter: ncm at cantrip dot org
Target Milestone: ---
template
struct type_identity { using type = T; };
template
using type_identity_t = typename type_identity::type;
template
struct S1 { using alias1 = typename type_identity::type
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ncm at cantrip dot org
Target Milestone: ---
Created attachment 54754
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54754=edit
Reproducer
Basically:
co_yield a ? s : t;
segfau
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68703
--- Comment #10 from ncm at cantrip dot org ---
(In reply to ncm from comment #9)
> This bug appears not to manifest in g++-8, 9, and 10.
Of the three code samples in comment 4, the first and
third fail to compile because N is undefined. W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87085
ncm at cantrip dot org changed:
What|Removed |Added
CC||ncm at cantrip dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97736
--- Comment #12 from ncm at cantrip dot org ---
As it is, your probability of failure in 9 and 10 is exactly 1.0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97736
--- Comment #10 from ncm at cantrip dot org ---
Don't understand, the compiler we are using (9) has the
regression. It looks like a trivial backport.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42857
--- Comment #9 from ncm at cantrip dot org ---
(In reply to Jonathan Wakely from comment #8)
> Probably changed by one of the patches for PR 94749 or PR 96161, although I
> still see two reads for the first example.
Thank you, I was mi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68703
--- Comment #9 from ncm at cantrip dot org ---
This bug appears not to manifest in g++-8, 9, and 10.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66028
--- Comment #2 from ncm at cantrip dot org ---
This bug appears not to manifest in g++-10.2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42857
--- Comment #7 from ncm at cantrip dot org ---
This bug appears not to manifest in g++-10.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58855
--- Comment #2 from ncm at cantrip dot org ---
This bug is still present in g++-10.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97736
--- Comment #6 from ncm at cantrip dot org ---
The referenced patch seems to have also deleted a fair bit of explanatory
comment text, including a list of possible refinements for selected targets.
Assignee: unassigned at gcc dot gnu.org
Reporter: ncm at cantrip dot org
Target Milestone: ---
In Gcc 8 and previous, the following code
bool is_vowel(char c) {
switch (c)
case'a':case'e':case'i':case'o':case'u':
return true;
return false;
}
compiled with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94037
--- Comment #10 from ncm at cantrip dot org ---
(In reply to Uroš Bizjak from comment #9)
> (In reply to ncm from comment #8)
> > It seems worth mentioning that the round trip through
> > L1 cache is just a workaround for the opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94037
--- Comment #8 from ncm at cantrip dot org ---
It seems worth mentioning that the round trip through
L1 cache is just a workaround for the optimizer refusing
to ever emit two CMOV instructions in a basic block.
Recognizing and replacing
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ncm at cantrip dot org
Target Milestone: ---
(This report re-uses some code from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93165 but identifies an entirely
different problem.)
Given:
```
bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67153
--- Comment #29 from ncm at cantrip dot org ---
> My reason for thinking this is not a bug is that the fastest choice will
> depend on the contents of the word list. Regardless of layout, there will
> be one option that is slightly fa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93165
--- Comment #7 from ncm at cantrip dot org ---
(In reply to Richard Biener from comment #6)
> (In reply to Andrew Pinski from comment #4)
> > (In reply to Alexander Monakov from comment #3)
> > > So perhaps an unpopular op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93165
--- Comment #5 from ncm at cantrip dot org ---
(In reply to Alexander Monakov from comment #3)
> The compiler has no way of knowing ahead of time that you will be evaluating
> the result on random data; for mostly-sorted arrays bra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93165
--- Comment #2 from ncm at cantrip dot org ---
Created attachment 47593
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47593=edit
a makefile
This duplicates code found on the linked archive.
E.g.:
make all
make CC=g++-9 INDEXED
make
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93165
--- Comment #1 from ncm at cantrip dot org ---
Created attachment 47592
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47592=edit
code demonstrating the failure
: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ncm at cantrip dot org
Target Milestone: ---
=== Abstract:
In important cases where using a "conditional move" instruction would provide a
2x performance improvement, Gcc fails to generate the i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89501
--- Comment #13 from ncm at cantrip dot org ---
What I am getting is that the compiler is leaving that permitted optimization
-- eliminating the inode check -- on the table. It is doing that not so much
because it would make Linus angry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89501
ncm at cantrip dot org changed:
What|Removed |Added
CC||ncm at cantrip dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67153
--- Comment #26 from ncm at cantrip dot org ---
Still fails on Skylake (i7-6700HQ) and gcc 8.1.0.
The good news is that clang++-7.0.0 code is slow on all four versions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67153
--- Comment #22 from ncm at cantrip dot org ---
(In reply to Nathan Kurz from comment #21)
> My current belief is
> that everything here is expected behavior, and there is no bug with either
> the compiler or processor.
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58855
ncm at cantrip dot org changed:
What|Removed |Added
CC||ncm at cantrip dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67153
--- Comment #18 from ncm at cantrip dot org ---
It is far from clear to me that gcc-5's choice to put the increment value in a
register, and use just one loop body, is wrong. Rather, it appears that an
incidental choice in the placement order
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ncm at cantrip dot org
Target Milestone: ---
$ cat vs2.cc
template
struct D {
int v//[N]
__attribute__((vector_size(N * sizeof(int;
int f1() { return this->v[
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67153
--- Comment #14 from ncm at cantrip dot org ---
A notable difference between g++-4.9 output and g++-5 output is that,
while both hoist the (word == seven) comparison out of the innermost
loop, gcc-4.9 splits inner loop into two versions, one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67153
--- Comment #13 from ncm at cantrip dot org ---
This is essentially the entire difference between the versions of
puzzlegen-int.cc without, and with, the added ++count; line
referenced above (modulo register assignments and branch labels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67153
--- Comment #12 from ncm at cantrip dot org ---
As regards hot spots, the program has two:
int score[7] = { 0, };
for (Letters word : words)
/**/if (!(word ~seven))
for_each_in_seven([](Letters letter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67153
--- Comment #9 from ncm at cantrip dot org ---
I did experiment with -m[no-]bmi[2] a fair bit. It all made a significant
difference in the instructions emitted, but exactly zero difference in
runtime. That's actually not surprising at all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67153
--- Comment #11 from ncm at cantrip dot org ---
Aha, Uroš, I see your name in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62011
Please forgive me for teaching you about micro-ops.
The code being generated for all versions does use (e.g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67153
--- Comment #10 from ncm at cantrip dot org ---
I found this, which at first blush seems like it might be relevant.
The hardware complained about here is the same Haswell i7-4770.
http://stackoverflow.com/questions/25078285/replacing-a-32-bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67153
--- Comment #6 from ncm at cantrip dot org ---
It seems worth adding that the same failure occurs without -march=native.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67153
--- Comment #4 from ncm at cantrip dot org ---
Also fails 5.2.1 (Debian 5.2.1--15) 5.2.1 20150808
As noted, the third version of the program, using bitset but not using
lambdas, is as slow as the version using unsigned int -- even when built
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67153
--- Comment #5 from ncm at cantrip dot org ---
My preliminary conclusion is that a hardware optimization provided in Haswell
but not in Westmere is not recognizing the opportunity in the unsigned int
test case, that it finds in the original
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67153
--- Comment #3 from ncm at cantrip dot org ---
Created attachment 36159
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36159action=edit
bitset, but using an inlined container adapter, not lambdas, and slow
This version compiles just
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ncm at cantrip dot org
Target Milestone: ---
Created attachment 36146
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36146action=edit
The std::bitset version
I have attached two small, semantically equivalent C++14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67153
--- Comment #1 from ncm at cantrip dot org ---
Created attachment 36147
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36147action=edit
The unsigned int version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67153
ncm at cantrip dot org changed:
What|Removed |Added
Target||Linux amd64
Known to work
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: ncm at cantrip dot org
Target Milestone: ---
Created attachment 35487
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35487action=edit
missing hash container constructors, provided
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66055
ncm at cantrip dot org changed:
What|Removed |Added
Attachment #35487|0 |1
is obsolete
++
Assignee: unassigned at gcc dot gnu.org
Reporter: ncm at cantrip dot org
Target Milestone: ---
struct range {
int start; int stop;
struct iter {
int i;
bool operator!=(iter other) { return other.i != i; };
iter operator++() { ++i; return
--- Additional Comments From ncm at cantrip dot org 2005-04-01 13:24
---
Subject: Re: basic_string::_M_rep() can produce an unnaturally aligned pointer
to _Rep
On Fri, Apr 01, 2005 at 11:42:27AM -, pcarlini at suse dot de wrote:
What|Removed
50 matches
Mail list logo
