-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bisqwit at iki dot fi
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26098
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bisqwit at iki dot fi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31485
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54946
Bug #: 54946
Summary: ICE on template parameter from cast char-pointer in
C++11 constexpr struct
Classification: Unclassified
Product: gcc
Version: 4.7.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54946
--- Comment #1 from Joel Yliluoma bisqwit at iki dot fi 2012-10-17 12:10:21
UTC ---
Please excuse the conts typo in the post; naturally it meant to say const
there. The typo is not relevant to the bug report.
I changed the code a few
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55239
Bug #: 55239
Summary: Spurious unused variable warning on function-local
objects with a destructor and an initializer
Classification: Unclassified
Product: gcc
Version:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55240
Bug #: 55240
Summary: [c++0x] ICE on non-static data member initialization
using 'auto' variable from containing function
Classification: Unclassified
Product: gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55239
--- Comment #5 from Joel Yliluoma bisqwit at iki dot fi 2012-11-08 15:16:48
UTC ---
Nice. I had no idea this was first reported in 2003 and fixed in 2012 in a
version recent enough to be still unreleased :)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55250
Bug #: 55250
Summary: [C++0x][constexpr] enum declarations within constexpr
function are allowed, constexpr declarations are not
Classification: Unclassified
Product: gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56794
Bug #: 56794
Summary: C++11 Error in range-based for with parameter pack
array
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53630
Bug #: 53630
Summary: C+11 regex compiler produces SIGSEGV
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Assignee: unassigned at gcc dot gnu.org
Reporter: bisqwit at iki dot fi
This is just silly. GCC optimizes the first function into single opcode
(bswap), but not the other. For Clang, it's the other way around.
unsigned byteswap_gcc(unsigned result)
{
result = ((result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58195
Joel Yliluoma bisqwit at iki dot fi changed:
What|Removed |Added
CC||bisqwit at iki dot
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bisqwit at iki dot fi
// Works:
char* table1[10];
templateunsigned size, char*(table)[size] void test1() { }
void tester1() { test110,table1(); }
// Doesn't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61323
--- Comment #1 from Joel Yliluoma bisqwit at iki dot fi ---
Interestingly enough, only if you add the term constexpr to the array
declaration, you get an actually meaningful error message:
constexpr const char* table7[10
--- Comment #2 from bisqwit at iki dot fi 2007-07-14 17:34 ---
Also, yay, bug report #32767 :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32767
--- Comment #4 from bisqwit at iki dot fi 2007-07-15 21:17 ---
Also is reported that on some 32-bit platforms, instead of causing an ICE, it
causes a rampant memory eating phenomenon.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32767
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bisqwit at iki dot fi
GCC build triplet: x86_64-pc-linux-gnu
GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu
http
--- Comment #1 from bisqwit at iki dot fi 2008-01-24 13:52 ---
The body of the function B_CLEAR() is not included, and not relevant, since the
error happens without the body as well, and does not progress to linking.
--
bisqwit at iki dot fi changed:
What|Removed
template function
local objects
Product: gcc
Version: 4.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bisqwit at iki dot fi
: Inexplicable error message with constructing SIMD values
Product: gcc
Version: 4.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bisqwit at iki dot
--- Comment #9 from bisqwit at iki dot fi 2010-01-17 22:37 ---
Out of curiosity... What does it mean it's not a regression, and what are its
practical implications?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42697
--- Comment #11 from bisqwit at iki dot fi 2010-01-18 07:59 ---
Ah, I see. So the reason it is not fixed in 4.5 is that it may cause new
regressions?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42697
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50276
--- Comment #5 from Joel Yliluoma bisqwit at iki dot fi 2012-01-03 23:16:07
UTC ---
It also accepts this code without complaints, which is another error:
templateint i
bool test()
{
if (bool value = this_identifier_has_not_been_declared
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50276
Bug #: 50276
Summary: Wrong used uninitialized in this function warning
[C++0x]
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50276
--- Comment #1 from Joel Yliluoma bisqwit at iki dot fi 2011-09-02 13:04:31
UTC ---
Even this produces the warning. Changing any of the 0s into 1 did not
affect the warning.
static inline unsigned testfun(void*)
{
return 0;
}
templateint i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48933
Summary: Infinite recursion in tr1/cmath functions with complex
parameters
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48933
--- Comment #4 from Joel Yliluoma bisqwit at iki dot fi 2011-05-09 10:51:28
UTC ---
There is, however, an asinh, a cbrt, a hypot etc. for complex types. I don't
know about standard, but mathematically they are well defined. (for example,
hypot(x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49043
Summary: Returns from lambda functions incorrectly detected as
exits from OpenMP loops in surrounding code
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49043
--- Comment #2 from Joel Yliluoma bisqwit at iki dot fi 2011-05-19 08:10:06
UTC ---
Even if the lambda function is not called, it happens. Merely defining the
function causes it.
Interestingly though, it does not happen if a method body
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49043
Joel Yliluoma bisqwit at iki dot fi changed:
What|Removed |Added
Summary|[C++0x] Returns from lambda |[OpenMP C++0x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49100
Summary: [OpenMP]: Compiler error when inline method defined
within OpenMP loop
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49100
--- Comment #1 from Joel Yliluoma bisqwit at iki dot fi 2011-05-21 11:31:46
UTC ---
It also does not happen with C's nested functions. This for instance compiles
and works just fine (to my surprise).
#include stdio.h
int main()
{
int
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49100
--- Comment #3 from Joel Yliluoma bisqwit at iki dot fi 2011-07-25 10:01:08
UTC ---
While it's true that one should not reference the original variable within the
loop, question is, why does the inner function reference the original variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49100
--- Comment #5 from Joel Yliluoma bisqwit at iki dot fi 2011-07-25 10:24:20
UTC ---
Obviously :) All right, thanks.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46764
Summary: std=c++0x causes compilation failure on SFINAE test
for methods
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66644
--- Comment #1 from Joel Yliluoma bisqwit at iki dot fi ---
The last code piece should have test2{0,0}; there. Something ate a couple of
characters off the end of that line.
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bisqwit at iki dot fi
Target Milestone: ---
Accepted by GCC:
struct test
{ union
{
struct { char a=0, b; };
char buffer[16
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bisqwit at iki dot fi
Target Milestone: ---
When compiling this program,
struct Polygon {};
template
struct View {};
template
void RenderLight(PixType, Params
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67561
Joel Yliluoma changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bisqwit at iki dot fi
Target Milestone: ---
In GCC 4.9, this code generates an error. In GCC 5.2, it generates no warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67411
Joel Yliluoma changed:
What|Removed |Added
CC||bisqwit at iki dot fi
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67561
--- Comment #1 from Joel Yliluoma ---
Further reduced example:
template
void DrawView(PlotFunc GetPlotFunc)
{
GetPlotFunc(1)(2);
}
void CalculateLightmap()
{
auto LightmapRenderer = [](unsigned round)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67559
--- Comment #2 from Joel Yliluoma ---
But when compiling for earlier standard versions that explicitly label this as
undefined behavior, it should at least give a warning.
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: bisqwit at iki dot fi
Target Milestone: ---
This code is written as if tailored to be SIMD-optimized by GCC...
But GCC somehow blows it.
template
struct vec
{
T d[N];
vec<
Component: regression
Assignee: unassigned at gcc dot gnu.org
Reporter: bisqwit at iki dot fi
Target Milestone: ---
For this program (needs -msse2 to compile).
#include
__m128d reg;
void set_lower(double b)
{
double v[2];
_mm_store_pd(v, reg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67609
--- Comment #1 from Joel Yliluoma ---
For the record, changing _mm_load_pd(v) into _mm_set_pd(v[1],v[0]) will coax
GCC into generating correct code. The bug is related to _mm_load_pd().
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67609
Joel Yliluoma changed:
What|Removed |Added
Component|target |regression
--- Comment #6 from Joel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67577
--- Comment #1 from Joel Yliluoma ---
It may be also worth mentioning that adding an explicit '#pragma omp simd'
before each of those loops, inside the operator functions, will make sure that
GCC at least does the mathematics using packed
ty: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bisqwit at iki dot fi
Target Milestone: ---
Consider this example code.
unsigned x;
template
void plain_if(unsigned y)
{
++
Assignee: unassigned at gcc dot gnu.org
Reporter: bisqwit at iki dot fi
Target Milestone: ---
GCC 5.2 fails to compile the code below, erroneously citing "error: use of
'TestFunc' before deduction of 'auto'".
Compiles fine in Clang 3.5.
#include
template
s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67838
--- Comment #1 from Joel Yliluoma ---
Note that the use of "template" here is to declare a parametric variable. It is
not for the function's parameter list. It works the same way as in this
expression:
template
int v = 3*LMode;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71499
--- Comment #1 from Joel Yliluoma ---
Addendum: While this works, reading LTO data and producing HOST code:
/usr/local/libexec/gcc/x86_64-pc-linux-gnu/6.1.0/lto1 -dumpbase tmpe.o -auxbase
tmpe -version -fopenacc tmpe.o -o /tmp/ccZgHvRO.s
This
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: bisqwit at iki dot fi
Target Milestone: ---
Summary: Error message:
lto1: internal compiler error: in input_overwrite_node, at
lto-cgraph.c:1203
On GCC 6.1.0
Compiling this code
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: bisqwit at iki dot fi
Target Milestone: ---
With this example program:
#pragma omp declare target
void Process()
{
static const int value = 12;
}
#pragma omp end declare target
int
Assignee: unassigned at gcc dot gnu.org
Reporter: bisqwit at iki dot fi
Target Milestone: ---
With this example program:
#include
void Process(unsigned* Target)
{
for(int s=0; s<4; ++s)
Target[s] = 100u * std::min(255, std::max(0, 0))
+ 200u *
++
Assignee: unassigned at gcc dot gnu.org
Reporter: bisqwit at iki dot fi
Target Milestone: ---
When running this code, libstdc++ crashes with a stack overflow (segmentation
fault) in std::regex_match. This regular expression is not the type that should
require exponential
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70411
--- Comment #1 from Joel Yliluoma ---
Minimal regex that causes the same crash: "^0+ .*"
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bisqwit at iki dot fi
Target Milestone: ---
This code generates an AST error when compiled with -std=c++17 -fopenmp.
void foo()
{
auto keymaker = [](void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63259
Joel Yliluoma changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: bisqwit at iki dot fi
Target Milestone: ---
For this code (-xc -std=c99 or -xc++ -std=c++17):
struct guu { int a; int b; float c; char d; };
extern void test(struct guu);
void caller
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91201
--- Comment #6 from Joel Yliluoma ---
Maybe a horizontal checksum is a bit obscure term. A 8-bit checksum is what is
being accomplished, nonetheless. Yes, there are simpler ways to do it…
But I tried a number of different approaches in order to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91526
Joel Yliluoma changed:
What|Removed |Added
CC||bisqwit at iki dot fi
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91201
--- Comment #24 from Joel Yliluoma ---
The simple horizontal 8-bit add seems to work nicely. Very nice work.
However, the original bug report — that the code snippet quoted below no longer
receives love from the SIMD optimization unless you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91201
--- Comment #16 from Joel Yliluoma ---
In reference to my previous comment, this is the code I tested with and the
compiler flags were -Ofast -mno-avx.
unsigned char bytes[128];
unsigned char sum (void)
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91201
--- Comment #15 from Joel Yliluoma ---
Seems to work neatly now.
Any reason why on vector size 128, non-AVX, it does the low byte move through
the red zone? Are pextrb or movd instructions not available? Or does ABI
specify that the upper bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91201
--- Comment #18 from Joel Yliluoma ---
Great, thanks. I can test this in a few days, but I would like to make sure
that the proper thing still happens if the vector is of bytes but the return
value of the function is a larger-than-byte integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91201
--- Comment #19 from Joel Yliluoma ---
If the function return type is changed to "unsigned short", the AVX code with
"vpextrb" will do a spurious "movzx eax, al" at the end — but if the return
type is "unsigned int", it will not. The code with
: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: bisqwit at iki dot fi
Target Milestone: ---
For this code —
typedef unsigned long long E;
const unsigned D = 2;
E bytes[D];
unsigned char sum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91201
--- Comment #3 from Joel Yliluoma ---
For the record, for this particular case (8-bit checksum of an array, 16 bytes
in this case) there exists even more optimal SIMD code, which ICC (version 18
or greater) generates automatically.
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bisqwit at iki dot fi
Target Milestone: ---
template
void foo(T&& begin, T&& end);
void test()
{
unsigned char buffer[16];
const unsigned ch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94128
--- Comment #2 from Joel Yliluoma ---
Yes, it is valid.
— The auto parameter is valid since C++20. It is called a “placeholder type”,
which has existed since C++11. C++20 made it valid also in function parameters.
— The “requires” is a valid
mponent: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bisqwit at iki dot fi
Target Milestone: ---
For this code:
void test(auto param)
requires requires{ { [](auto p){return p;}(param) }; };
void test2() { test(1); }
On this compiler:
g++-10
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bisqwit at iki dot fi
Target Milestone: ---
Rejects valid code.
$ g++-10 --version
g++-10 (Debian 10-20200324-1) 10.0.1 20200324 (experimental) [master
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58195
--- Comment #4 from Joel Yliluoma ---
Still confirmed on GCC 10 (Debian 10-20200324-1) 10.0.1 20200324 (experimental)
[master revision
596c90d3559:023579257f5:906b3eb9df6c577d3f6e9c3ea5c9d7e4d1e90536]
Seems I lack the oomph to update the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94575
--- Comment #2 from Joel Yliluoma ---
Sorry, the error Marek Polacek mentions is due to a copypaste mistake on my
part. The correct code that demonstrates the problem is here. The difference is
the && instead of &.
#include
template
static
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31485
--- Comment #11 from Joel Yliluoma ---
Looks like this issue has taken a step or two *backwards* in the past years.
Where as the second function used to be vectorized properly, today it seems
neither of them are.
Contrast this with Clang,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31485
--- Comment #13 from Joel Yliluoma ---
GCC 4.1.2 is indicated in the bug report headers.
Luckily, Compiler Explorer has a copy of that exact version, and it indeed
vectorizes the second function: https://godbolt.org/z/DC_SSb
On my own system,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31485
--- Comment #23 from Joel Yliluoma ---
(In reply to Jakub Jelinek from comment #21)
> (In reply to Joel Yliluoma from comment #20)
> > Which exceptions would be generated by data in an unused portion of a
> > register?
>
> addps adds 4 float
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31485
--- Comment #25 from Joel Yliluoma ---
(In reply to Jakub Jelinek from comment #24)
> on x86 read e.g. about MXCSR register and in the description of each
> instruction on which Exceptions it can raise.
So the quick answer to #15 is that addps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31485
--- Comment #15 from Joel Yliluoma ---
(In reply to Richard Biener from comment #14)
> I also think llvms code generation is bogus since it appears the ABI
> does not guarantee zeroed upper elements of the xmm0 argument
> which means they could
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31485
--- Comment #20 from Joel Yliluoma ---
(In reply to Jakub Jelinek from comment #16)
> (In reply to Joel Yliluoma from comment #15)
> > (In reply to Richard Biener from comment #14)
> > > I also think llvms code generation is bogus since it
++
Assignee: unassigned at gcc dot gnu.org
Reporter: bisqwit at iki dot fi
Target Milestone: ---
void foo()
{
int test1[2], test2[2];
auto [a,b] = test1, [c,d] = test2;
}
The error message given for this (invalid) C++17 code is a bit confusing.
tmp.cc: In function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94571
--- Comment #1 from Joel Yliluoma ---
| ^
(Missing line from the paste)
The problem exists since GCC 7. (GCC 6 and earlier did not support structured
bindings.)
++
Assignee: unassigned at gcc dot gnu.org
Reporter: bisqwit at iki dot fi
Target Milestone: ---
Incorrect warning (-std=c++14 -Wall )
Tested and occurs on GCC 5.4.1, 6.5.0, 7.5.0, 8.4.0, 9.3.0, and 10.0.1 (master
revision 596c90d3559:023579257f5
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bisqwit at iki dot fi
Target Milestone: ---
Versions tested: GCC 9.3.0, GCC 10.0.1 20200324 (experimental) [master revision
596c90d3559:023579257f5:906b3eb9df6c577d3f6e9c3ea5c9d7e4d1e90536
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bisqwit at iki dot fi
Target Milestone: ---
On GCC 9.3.0:
$ g++-9 test5.cc -std=c++2a -g -fconcepts
test5.cc: In instantiation of ‘auto Mul(const T&, const T2&) [with T =
std::array; T2 = std::array]’:
test5.
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bisqwit at iki dot fi
Target Milestone: ---
GCC produces false error message:
bug1.cc: In instantiation of ‘consteval void VerifyHash() [with unsigned int
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bisqwit at iki dot fi
Target Milestone: ---
GCC produces false error message:
bug1.cc: In function ‘consteval void VerifyHash()’:
bug1.cc:20:70: error: operand of fold
88 matches
Mail list logo
