https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116014
--- Comment #2 from Joel Yliluoma ---
(In reply to Andi Kleen from comment #1)
> is that from some real code? why would a programmer write shifts like that?
Yes, it is from actual code:
uint64_t readvlq()
{
uint64_t x, f = ~(ui
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116013
--- Comment #1 from Joel Yliluoma ---
Should be noted that this is not x86_64 specific; andn exists for other
platforms too, and even for platforms that don’t have it, changing
`~(expr|const)` into `~expr & ~const` is unlikely to be a pessimiz
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: bisqwit at iki dot fi
Target Milestone: ---
Below are six short functions which perform bit-shifts by a non-constant
inverted amount. GCC fails to generate most optimal code. Further explanation
is
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: bisqwit at iki dot fi
Target Milestone: ---
Below are two short functions which work identically. While GCC utilizes the
ANDN instruction (of Intel BMI1) for test2, it fails to
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
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 i
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 ele
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 appear
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 c
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, th
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, which
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 void
++
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
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: ---
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=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 "confi
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
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.
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 ke
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
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=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 expl
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 "(
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 ty
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)
{
unsign
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 of
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=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.
vmovu
: 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
-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=63259
Joel Yliluoma changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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
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 *
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70411
--- Comment #1 from Joel Yliluoma ---
Minimal regex that causes the same crash: "^0+ .*"
++
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=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;
++
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.
#
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67609
Joel Yliluoma changed:
What|Removed |Added
Component|target |regression
--- Comment #6 from Joel Ylil
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().
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=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 registe
-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 operator
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67561
Joel Yliluoma changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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)
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
Version: 5.2.1
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 generate
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)
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66644
--- Comment #1 from Joel Yliluoma ---
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];
}; };
NOT
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 = ((r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61323
--- Comment #1 from Joel Yliluoma ---
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] = {};
template void test7() { }
v
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bisqwit at iki dot fi
// Works:
char* table1[10];
template void test1() { }
void tester1() { test1<10,table1>(); }
// Doesn't work:
st
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58195
Joel Yliluoma changed:
What|Removed |Added
CC||bisqwit at iki dot fi
--- Comment #1
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=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=55239
--- Comment #5 from Joel Yliluoma 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=55240
Bug #: 55240
Summary: [c++0x] ICE on non-static data member initialization
using 'auto' variable from containing function
Classification: Unclassified
Product: gcc
Versi
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=54946
--- Comment #1 from Joel Yliluoma 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 times trying to figur
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
St
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50276
--- Comment #5 from Joel Yliluoma 2012-01-03 23:16:07
UTC ---
It also accepts this code without complaints, which is another error:
template
bool test()
{
if (bool value = this_identifier_has_not_been_declared( []() {} ))
return value;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50276
--- Comment #1 from Joel Yliluoma 2011-09-02 13:04:31
UTC ---
Even this produces the warning. Changing any of the "0"s into "1" did not
affect the warning.
static inline unsigned testfun(void*)
{
return 0;
}
template
static inline unsigned
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=49100
--- Comment #5 from Joel Yliluoma 2011-07-25 10:24:20
UTC ---
Obviously :) All right, thanks.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49100
--- Comment #3 from Joel Yliluoma 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
rather than the inloop var
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49100
--- Comment #1 from Joel Yliluoma 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
int main()
{
int a;
#pragma omp parallel for
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=49043
Joel Yliluoma changed:
What|Removed |Added
Summary|[C++0x] Returns from lambda |[OpenMP & C++0x]: Compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49043
--- Comment #2 from Joel Yliluoma 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 is defined within the
loop. The
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=48933
--- Comment #4 from Joel Yliluoma 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,y) = sqrt(x*x + y*y),
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
C
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
Com
--- 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
--- 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
le 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
Summary: ice-on-legal-code: template class template function
local objects
Product: gcc
Version: 4.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu do
--- 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
ity: 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://gcc.gnu.org/bugzilla/show_bug.cgi?id=34953
--- 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
--- 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
timization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bisqwit at iki dot fi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31485
Priority: P3
Component: rtl-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
92 matches
Mail list logo
