: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: linux at carewolf dot com
Target Milestone: ---
On aarch64 calling __builtin_round and casting the result to int or long long
uses a single fcvtas instruction, but using
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51033
Allan Jensen changed:
What|Removed |Added
CC||linux at carewolf dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51033
--- Comment #32 from Allan Jensen 2013-02-17
15:23:49 UTC ---
(In reply to comment #31)
> (In reply to comment #30)
> > Another example is binary operators between scalar and vectors. In C the
> > scalar
> > is automatically treated as a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53460
Bug #: 53460
Summary: Internal compiler error: in calc_dfs_tree, at
dominance.c:395
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53460
--- Comment #1 from Allan Jensen 2012-05-23
15:34:35 UTC ---
Created attachment 27481
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27481
FontFastPath.ii.gz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53460
--- Comment #2 from Allan Jensen 2012-05-23
15:37:32 UTC ---
It appears I am not allowed to make more than one attachment so you will have
to do with one example. Here is the console output:
Using built-in specs.
COLLECT_GCC=/usr/bin/g++
Target:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48026
Allan Jensen changed:
What|Removed |Added
CC||linux at carewolf dot com
--- Comment #2
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: linux at carewolf dot com
Created attachment 31399
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31399&action=edit
Patch
Trying to compile a function with an "xop" multiversion fails with a &qu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78394
--- Comment #9 from Allan Jensen ---
I see two other level effort ways to possibly fix the issue. Disable the
warning like for -O0 as it is buggy, or if we believe it still has some value
in -Og even with the false positivies, just removing it fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88475
Allan Jensen changed:
What|Removed |Added
CC||linux at carewolf dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88475
--- Comment #3 from Allan Jensen ---
No, it has to be a raw-string to be valid.
https://wandbox.org/permlink/I0yF3U3OXoH6LbIM
P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: linux at carewolf dot com
Target Milestone: ---
When using the vld3_u8 and vst4_u8 instrinsics, the code generated with gcc8 is
less efficient than the code generated with gcc7. One has 3 moves, and the
othe
P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: linux at carewolf dot com
Target Milestone: ---
When using the vld3_u8 and vst4_u8 instrinsics, the code generated with gcc8 is
less efficient than the code generated with gcc7. One has 3 moves, and the
other 9 mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89058
--- Comment #2 from Allan Jensen ---
Oops, sorry.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89057
--- Comment #4 from Allan Jensen ---
While that change might have made things worse. The real problem is probably
that the registers for those instructions are loaded and stored using
intrinsics, so proper register allocation and combining cant b
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: linux at carewolf dot com
Target Milestone: ---
If you have something like this:
inline unsigned qPremultiply(unsigned x)
{
const unsigned a = x >> 24;
if (a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85406
--- Comment #1 from Allan Jensen ---
Note it might be hard to figure out for the compiler that the result for a==255
will leave the input unchanged, but you can observe the same if you instead
test for a == 0 (and return 0). In that case the comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85406
--- Comment #3 from Allan Jensen ---
You need to add the loop around it
void test(unsigned *buffer, int count)
{
for (int i = 0; i < count; ++i)
buffer[i] = qPremultiply(buffer[i]);
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85406
--- Comment #4 from Allan Jensen ---
Created attachment 43995
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43995&action=edit
gccbug85406.cpp
This version compiles with a pcmpeqd and pandn instead of a blend, but the
principle is the same
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85406
--- Comment #6 from Allan Jensen ---
Yeah, the a==255 was actually not a case I would expect the compiler to solve,
which is why I changed the example to the a==0 case, which should be solveable
using existing constant propagation.
Note you can
: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: linux at carewolf dot com
Target Milestone: ---
Created attachment 44030
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44030&action=edit
strmod.cpp
Many simple loops using modulo naively
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85551
--- Comment #1 from Allan Jensen ---
I also stumbled on this old motivating article when I tried googling the
concept: http://publications.csail.mit.edu/lcs/pubs/pdf/MIT-LCS-TM-600.pdf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85551
--- Comment #2 from Allan Jensen ---
Hmm.. I appear to have made unsafe assumptions in the mod_opt cases.
The first safe optimization version would then be:
void mod_opt(int *a, int count, int stride, unsigned width)
{
int pos_opt = 0;
f
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: linux at carewolf dot com
Target Milestone: ---
If a vector initialization is using elements from only a single vector source,
it will be optimized as a shuffle, but if it is using elements from two, it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85692
--- Comment #1 from Allan Jensen ---
Created attachment 44084
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44084&action=edit
construct.cc
Motivating examples. Compile with -msse4.1 for the second case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85692
--- Comment #4 from Allan Jensen ---
Note I already posted a patch on gcc-patches myself. It is very similar to
yours
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85692
--- Comment #5 from Allan Jensen ---
Created attachment 44088
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44088&action=edit
suggested patch
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: linux at carewolf dot com
Target Milestone: ---
When SSE4.1 is available, std::floor, std::ceil and their C counterparts are
inlined to being a single roundss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85950
--- Comment #1 from Allan Jensen ---
Sorry forget the example above. I will attached the real code that triggers it.
Note it does not trigger with -fno-signed-zeros, -fno-trapping-math,
-fassociative-math and -freciprocal-math, so it is somethin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85950
--- Comment #2 from Allan Jensen ---
Created attachment 44196
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44196&action=edit
Example
To trigger need both a rounding conversion and a conversion to integer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85950
--- Comment #4 from Allan Jensen ---
Btw, I found this while trying to figure out why std::round() wasn't also
optimized to a single roundss instruction, is that just a missing optimization
or is there a quirk about that that makes them not fit?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85950
--- Comment #6 from Allan Jensen ---
Btw, I have tested and the patch works for my cases.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83847
Allan Jensen changed:
What|Removed |Added
CC||linux at carewolf dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83847
--- Comment #4 from Allan Jensen ---
Full output from the ICE:
during GIMPLE pass: vect
/src/qt5/qtbase/src/corelib/kernel/qmetaobjectbuilder.cpp: In function ‘int
buildMetaObject(QMetaObjectBuilderPrivate*, char*, int, bool)’:
/src/qt5/qtbase/s
-end
Assignee: unassigned at gcc dot gnu.org
Reporter: linux at carewolf dot com
Target Milestone: ---
ICE when compiling Chromium in QtWebEngine under certain conditions.
With gcc 8:
during GIMPLE pass: fre
../../../../../qtwebengine/src/3rdparty/chromium/third_party/WebKit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84019
--- Comment #1 from Allan Jensen ---
First line of the ICE (the only line reported by system gcc)
../../src/init2.c:52: MPFR assertion failed: p >= 2 && p <=
((mpfr_prec_t)((mpfr_uprec_t)(~(mpfr_uprec_t)0)>>1))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84019
--- Comment #2 from Allan Jensen ---
I can provide the intermediate code, but I haven't created a reduced test-case,
so it would be big.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63688
Allan Jensen changed:
What|Removed |Added
CC||linux at carewolf dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86582
Allan Jensen changed:
What|Removed |Added
CC||linux at carewolf dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68836
Allan Jensen changed:
What|Removed |Added
CC||linux at carewolf dot com
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88475
--- Comment #5 from Allan Jensen ---
Note, you can fix the conflict with icecc by setting ICEC_REMOTE_CPP=0
Icecc will only do this to enable the remote cpp feature.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43147
Allan Jensen changed:
What|Removed |Added
CC||linux at carewolf dot com
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66970
--- Comment #19 from Allan Jensen ---
(In reply to felix from comment #18)
> So even if this feature is adopted as-is, it will necessitate some changes
> in the documentation. And while I can sympathise with claims that this
> behaviour is surpri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58407
Allan Jensen changed:
What|Removed |Added
CC||linux at carewolf dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84019
--- Comment #8 from Allan Jensen ---
Yes, I will take a look again and produce the intermediate results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84019
Allan Jensen changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: linux at carewolf dot com
Target Milestone: ---
Created attachment 43566
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43566&action=edit
gcc log
Using latest gcc 8 updated today I hit an internal compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84718
--- Comment #1 from Allan Jensen ---
Created attachment 43567
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43567&action=edit
spdy_alt_svc_wire_format.s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84718
--- Comment #2 from Allan Jensen ---
Created attachment 43568
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43568&action=edit
spdy_alt_svc_wire_format.ii.gz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84718
--- Comment #4 from Allan Jensen ---
I will update my gcc build and check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84670
Allan Jensen changed:
What|Removed |Added
CC||linux at carewolf dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84718
Allan Jensen changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Assignee: unassigned at gcc dot gnu.org
Reporter: linux at carewolf dot com
Target Milestone: ---
Neither the command-line flag -ftree-loop-vectorize nor -fopenmp combined with
"#pragma omp simd" works when -Os is active.
It seems that it when specified manually vec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84777
--- Comment #4 from Allan Jensen ---
I will try the patch. I just tried -fopt-info-vec-missed and the message
reported for every loop was:
note: not vectorized: latch block not empty.
note: bad loop form.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84777
--- Comment #6 from Allan Jensen ---
Great. Your patch worked with 90% of the marked loops!
The remaining report things like this with -fopt-info-vec-missed:
note: not vectorized: relevant stmt not supported: idisty.872_437 = (unsigned
int) idi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84777
--- Comment #8 from Allan Jensen ---
Yes, those I say are missing are compared to -O2. I was investigating this in
relation to Qt. We either build these files with -O3, or with -Os for customer
that are binary size sensitive. Since some of the im
: other
Assignee: unassigned at gcc dot gnu.org
Reporter: linux at carewolf dot com
Target Milestone: ---
The intrinsics _mm_loadl_epi64 and _mm_storel_epi64 triggers UBSan warnings on
unaligned access because the instrinsics definitions in emmintrin.h are using
__m64 and
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: linux at carewolf dot com
Target Milestone: ---
Created attachment 41610
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41610&action=edit
bswap-issue.cc
In writting a big-endian bitfield accessor I notic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81174
Allan Jensen changed:
What|Removed |Added
Version|6.1.1 |7.1.0
--- Comment #1 from Allan Jensen -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70118
--- Comment #2 from Allan Jensen ---
I believe this to be fixed by r239889
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70118
--- Comment #3 from Allan Jensen ---
Or r217608
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70118
--- Comment #4 from Allan Jensen ---
Created attachment 40130
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40130&action=edit
Proposed patch
On closer inspection, we are only almost there, two minor changes are still
needed. (testing patc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70118
Allan Jensen changed:
What|Removed |Added
Attachment #40130|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31667
Allan Jensen changed:
What|Removed |Added
CC||linux at carewolf dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31667
--- Comment #4 from Allan Jensen ---
(In reply to Allan Jensen from comment #3)
> Gcc 5 and 6 produces code with pmovzx when compiling the example with -O3
> -msse4.1
>
> I assume this can be closed.
Note like comment 1 saids, it will not use a
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: linux at carewolf dot com
Target Milestone: ---
An unpack pattern with 0 constant are neither folded nor recognized as a pmovzx
instruction.
SSE2 code:
_mm_unpacklo_epi32(X, _mm_setzero_si128())
GCC code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78563
--- Comment #1 from Allan Jensen ---
Created attachment 40177
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40177&action=edit
Test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47754
Allan Jensen changed:
What|Removed |Added
CC||linux at carewolf dot com
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47754
--- Comment #8 from Allan Jensen ---
Note this happens with -mavx2, but not with -march=haswell. It appears the
tuning is a bit too pessimistic when avx2 is enabled on generic x64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47754
--- Comment #10 from Allan Jensen ---
No I mean it triggers when you compile with -mavx2, it is solved with
-march=haswell. It appears the issue is the tune flag
X86_TUNE_AVX256_UNALIGNED_LOAD_OPTIMAL is set for all processors that support
avx2,
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: linux at carewolf dot com
Target Milestone: ---
Created attachment 40295
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40295&action=edit
Test
In gcc 7 when not optimiz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78762
--- Comment #1 from Allan Jensen ---
Created attachment 40296
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40296&action=edit
Test compiled with -mavx2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78762
--- Comment #2 from Allan Jensen ---
Created attachment 40297
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40297&action=edit
Test compiled with -march=haswell
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78762
--- Comment #3 from Allan Jensen ---
Created attachment 40298
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40298&action=edit
Test compiled with gcc 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47754
--- Comment #11 from Allan Jensen ---
The think the issue I noted is completely separate from this one, so I opened
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78762 to deal with it.
I think this one could probably be closed though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70118
Allan Jensen changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59874
Allan Jensen changed:
What|Removed |Added
CC||linux at carewolf dot com
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66970
Allan Jensen changed:
What|Removed |Added
CC||linux at carewolf dot com
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59874
--- Comment #8 from Allan Jensen ---
Thanks that looks good. I will test it when I have a chance. I am changing the
Qt sources to not assume the presence of __builtin_clzs when __BMI__ is
defined. It can use __builtin_clz() and __builtin_ctz()-16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59874
--- Comment #15 from Allan Jensen ---
Yes, the patch works and it also evaluates at compile time.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78762
--- Comment #10 from Allan Jensen ---
That would solve the problem, but also leave the behavior as Sandybridge only
(nehalem didn't have AVX).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78762
--- Comment #11 from Allan Jensen ---
Btw, did you benchmark store splitting on AMD? It is also enabled for BDVER and
ZNVER1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78762
--- Comment #13 from Allan Jensen ---
The question is if the unaligned store is still slow on Excavator and Ryzen
which support AVX2. As far as I understand the bulldozer architectures just
prefer split AVX because it was basically emulating them
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: linux at carewolf dot com
Target Milestone: ---
The intrinsics for x86 SIMD shuffle instructions could be redeclared using
__builtin_shuffle. This would help folding and better
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80040
--- Comment #1 from Allan Jensen ---
Created attachment 40972
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40972&action=edit
Assembler output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80040
--- Comment #2 from Allan Jensen ---
Created attachment 40973
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40973&action=edit
Assembler output from gcc 6
Easier to compare
Assignee: unassigned at gcc dot gnu.org
Reporter: linux at carewolf dot com
Target Milestone: ---
Created attachment 40971
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40971&action=edit
Example
The intrinsics _mm_testz_si128 and _mm_testc_si128 both map to the exa
Assignee: unassigned at gcc dot gnu.org
Reporter: linux at carewolf dot com
Target Milestone: ---
Created attachment 41100
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41100&action=edit
icf.cc
Several functions that produce identical assembler are not merged by ipa
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: linux at carewolf dot com
Target Milestone: ---
Created attachment 42299
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42299&action=edit
vectslp.cpp
The attached example is a simple matrix multipl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82426
--- Comment #1 from Allan Jensen ---
Created attachment 42300
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42300&action=edit
Assembler output with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82426
--- Comment #2 from Allan Jensen ---
Created attachment 42301
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42301&action=edit
Assembler output with -Os -ftree-slp-vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82426
--- Comment #3 from Allan Jensen ---
Note it appears the fact it can do it at all in -Os is new in gcc 7
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: linux at carewolf dot com
Target Milestone: ---
We have been running into several issues with the tautological compare warning
in qtdeclarative, first there was https
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: linux at carewolf dot com
Target Milestone: ---
Created attachment 39774
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39774&action=edit
Example that trig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77902
--- Comment #1 from Allan Jensen ---
Further experimentation shows that GCC can sometimes reason about the remaining
range but does so inconsistenly.
For instance this examplse also fails:
int result = 0;
for (; count >= 4; count -= 4) {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77902
--- Comment #2 from Allan Jensen ---
While this have been the case in both GCC 5 and GCC 6, it appears to both
failing cases previously meantioned already produced the best case result in
using a half recent GCC 7.
gcc version 7.0.0 20160923 (exp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77902
Allan Jensen changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63319
Allan Jensen changed:
What|Removed |Added
CC||linux at carewolf dot com
--- Comment
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: linux at carewolf dot com
Target Milestone: ---
Created attachment 40064
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40064&action=edit
maybe_uninitialized.cpp
Compiling with -Og produces a nu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78394
Allan Jensen changed:
What|Removed |Added
Attachment #40064|0 |1
is obsolete|
1 - 100 of 153 matches
Mail list logo
