https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104084
--- Comment #4 from Allan Jensen ---
Created attachment 52217
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52217=edit
-E output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104084
--- Comment #3 from Allan Jensen ---
-v output:
Using built-in specs.
COLLECT_GCC=/opt/gcc/bin/g++-12
Target: x86_64-pc-linux-gnu
Configured with: ../configure --enable-languages=c,c++ --prefix=/opt/gcc
--program-suffix=-12
Thread model: posix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104084
--- Comment #2 from Allan Jensen ---
Removing the (std::nothrow), and declaring the untagged new operator (instead
of declaring them deleted), seems to work around the issue.
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: linux at carewolf dot com
Target Milestone: ---
Another error encounted while compiling Qt with gcc 12. This time
++
Assignee: unassigned at gcc dot gnu.org
Reporter: linux at carewolf dot com
Target Milestone: ---
In an attempt to compile Qt and specifically Qt WebEngine with latest gcc 12
from git today, I git the follow weird error, from Skia inside Chromium inside
QtWebengine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31667
--- Comment #6 from Allan Jensen ---
(In reply to Andrew Pinski from comment #5)
> We produce this now:
>
> movdqa x(%rip), %xmm1
> pxor%xmm0, %xmm0
> movdqa %xmm1, %xmm2
> punpckhbw %xmm0, %xmm1
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78394
--- Comment #17 from Allan Jensen ---
Yes, if you can figure out exactly what optimization passes it needs, then we
could disable the warning when those passes are disabled.
: 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
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
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=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=68836
Allan Jensen changed:
What|Removed |Added
CC||linux at carewolf dot com
--- Comment #8
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=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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89058
--- Comment #2 from Allan Jensen ---
Oops, sorry.
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
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
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
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=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
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=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=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 #2 from Allan Jensen ---
Created attachment 44196
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44196=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 #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
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=85692
--- Comment #5 from Allan Jensen ---
Created attachment 44088
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44088=edit
suggested patch
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 #1 from Allan Jensen ---
Created attachment 44084
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44084=edit
construct.cc
Motivating examples. Compile with -msse4.1 for the second case.
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
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;
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
: 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=edit
strmod.cpp
Many simple loops using modulo naively can be optimized
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
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=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 #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 #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
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=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
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)
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.
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=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|---
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=84718
--- Comment #2 from Allan Jensen ---
Created attachment 43568
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43568=edit
spdy_alt_svc_wire_format.ii.gz
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=edit
spdy_alt_svc_wire_format.s
: 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=edit
gcc log
Using latest gcc 8 updated today I hit an internal compiler er
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84019
Allan Jensen changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
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=63688
Allan Jensen changed:
What|Removed |Added
CC||linux at carewolf dot com
--- Comment #2
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=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))
-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=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)’:
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=82426
--- Comment #3 from Allan Jensen ---
Note it appears the fact it can do it at all in -Os is new in gcc 7
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=edit
Assembler output with -Os -ftree-slp-vectorize
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=edit
Assembler output with -O3
: 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=edit
vectslp.cpp
The attached example is a simple matrix multiplicat
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
-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=edit
bswap-issue.cc
In writting a big-endian bitfield accessor I noticed that bs
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=edit
icf.cc
Several functions that produce identical assembler are not merged by ipa-icf. I
h
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=edit
Example
The intrinsics _mm_testz_si128 and _mm_testc_si128 both map to the exact same
instruct
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=edit
Assembler output from gcc 6
Easier to compare
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=edit
Assembler output
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=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
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 #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=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=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
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
Allan Jensen changed:
What|Removed |Added
CC||linux at carewolf dot com
--- Comment #5
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=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=78762
--- Comment #3 from Allan Jensen ---
Created attachment 40298
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40298=edit
Test compiled with gcc 6
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=edit
Test compiled with -march=haswell
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=edit
Test compiled with -mavx2
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=edit
Test
In gcc 7 when not optimizing for sp
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,
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
Allan Jensen changed:
What|Removed |Added
CC||linux at carewolf dot com
--- Comment #7
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=edit
Test
: 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=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
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=70118
Allan Jensen changed:
What|Removed |Added
Attachment #40130|0 |1
is obsolete|
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=edit
Proposed patch
On closer inspection, we are only almost there, two minor changes are still
needed. (testing patch).
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 #2 from Allan Jensen ---
I believe this to be fixed by r239889
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78394
Allan Jensen changed:
What|Removed |Added
Attachment #40064|0 |1
is obsolete|
: 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=edit
maybe_uninitialized.cpp
Compiling with -Og produces a number of uni
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63319
Allan Jensen changed:
What|Removed |Added
CC||linux at carewolf dot com
--- Comment
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=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
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)
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=edit
Example that trigger the pointl
: 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65274
--- Comment #4 from Allan Jensen ---
It works now.
1 - 100 of 153 matches
Mail list logo
