: target
Assignee: unassigned at gcc dot gnu.org
Reporter: linux at carewolf dot com
Created attachment 32567
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32567&action=edit
Test case
If you compile the attached program with -O0 and -mlzcnt on x86, it will
produce wrong
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60788
--- Comment #1 from Allan Jensen ---
Sorry. The optimization has nothing to do with it, it just causes the constant
expressions used for testing to be evaluated at compile time.
The real issue is that the lzcnt instruction does not return the num
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60788
--- Comment #3 from Allan Jensen ---
Sorry for the confusion. I thought Intel had added it from Ivy Bridge, but it
was Haswell.
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: linux at carewolf dot com
After investigating a loop using SSE intrinsics that was significantly faster
in clang than in gcc, I discovered gcc had the same performance as clang in
-O2, and only performed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65492
--- Comment #1 from Allan Jensen ---
Created attachment 35070
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35070&action=edit
main
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65492
--- Comment #2 from Allan Jensen ---
Created attachment 35071
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35071&action=edit
vector union test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65492
--- Comment #3 from Allan Jensen ---
The -O3 regression seems to go back a long way, but has become lesser over
time.
With gcc 4.6 and older it runs at 3.1s with -O3, and still at 1.8s with -O2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65492
--- Comment #8 from Allan Jensen ---
You can remove the branches in the inner loop and still reproduce the issue.
There were no branches in the original code, I only added them to the reduced
case because I was using a smaller lookup table.
I ap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65492
--- Comment #9 from Allan Jensen ---
Looking at the assembler, it does indeed appear that the only difference just
loop unrolling and if conversion.
After testing on another machine (and old PhenomII as opposed to the
Sandybridge), and report t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65492
--- Comment #10 from Allan Jensen ---
Just make things more complicated, I just tried the test on a Haswell, and
surprisingly disabling if-convert or tree-vectorize on -O3 has no effect on
performance, but activating tree-vectorize on -O2 does.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65492
--- Comment #11 from Allan Jensen ---
Issues with slow cmov has been seen in several bug reports:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53346
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54073
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65492
--- Comment #12 from Allan Jensen ---
I have a very crude fix for this.
First though, according to comments in tree-if-conv.c and earlier bugs on the
issues. If-conversion is suppposed to be conditional. It performed in a piece
of conditionally
: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: linux at carewolf dot com
After recently trying to build Qt with -O3, I found one of our tests failing.
After investigating I narrowed it down to qregion.cpp and the flag
-finline-functions (using -O2 -finline-functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60429
--- Comment #1 from Allan Jensen ---
Created attachment 32268
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32268&action=edit
qregion.cpp intermediate compiled with G++ 4.4 (working)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60429
--- Comment #2 from Allan Jensen ---
Created attachment 32269
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32269&action=edit
qregion.cpp intermediate compiled with gcc 4.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60429
--- Comment #3 from Allan Jensen ---
Created attachment 32270
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32270&action=edit
qregion.cpp assembler compiled with gcc 4.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60429
--- Comment #4 from Allan Jensen ---
Created attachment 32271
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32271&action=edit
qregion.cpp assembler compiled with gcc 4.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60429
--- Comment #6 from Allan Jensen ---
(In reply to Richard Biener from comment #5)
> Can you identify the inlined call? Is it
>
> if (pSLL && y == pSLL->scanline) {
> loadAET(&AET, pSLL->edgelist);
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60429
--- Comment #8 from Allan Jensen ---
Created attachment 32303
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32303&action=edit
Reduced test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60429
--- Comment #9 from Allan Jensen ---
Created attachment 32304
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32304&action=edit
Reduced test assembler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60429
--- Comment #10 from Allan Jensen ---
I have uploaded a reduced test. Compiled with -O0 or -O1 it outputs 180,
compiled with -O2 or higher it outputs 179.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60429
--- Comment #11 from Allan Jensen ---
Note that to run it, it links against Qt5Core.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60429
--- Comment #13 from Allan Jensen ---
(In reply to Andrew Pinski from comment #12)
> tmpPtBlock->pts = reinterpret_cast *>(tmpPtBlock->data);
>
> Does this not violate C/C++ aliasing rules later on?
>
> I think data should be cha
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60429
--- Comment #24 from Allan Jensen ---
I just tested the latest subversion head of gcc 4.9 and can confirm it fixes
the original problem (tst_qregion in Qt 5.2.1 compiled with -O3).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60429
--- Comment #25 from Allan Jensen ---
Will it be backported to 4.8?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67351
Allan Jensen changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51509
Allan Jensen changed:
What|Removed |Added
CC||linux at carewolf dot com
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64806
Allan Jensen changed:
What|Removed |Added
CC||linux at carewolf dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64806
--- Comment #3 from Allan Jensen ---
I refer to this:
/* Handle arch= if specified. For priority, set it to be 1 more than
the best instruction set the processor can handle. For instance, if
there is a version for atom and a versio
++
Assignee: unassigned at gcc dot gnu.org
Reporter: linux at carewolf dot com
Created attachment 34871
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34871&action=edit
C++ source
A specific combination of local typedef inside a templated function causes gcc
to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65211
--- Comment #1 from Allan Jensen ---
Created attachment 34872
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34872&action=edit
Assembler intermediate
It is the "movdqa(%rdx), %xmm1" instruction on line 19 that is wrong.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65211
--- Comment #2 from Allan Jensen ---
Created attachment 34873
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34873&action=edit
Intermediate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65211
Allan Jensen changed:
What|Removed |Added
Attachment #34873|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65211
--- Comment #4 from Allan Jensen ---
Note either removing the template argument or moving the typedef out of the
function both solve the issue, and makes gcc use an unaligned load.
: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: linux at carewolf dot com
When trying to build QtWebkit with LTO I get the internal error:
lto1: internal compiler error: in should_move_die_to_comdat, at
dwarf2out.c:6846
Note. I do not actually expect an LTO debug build of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65274
--- Comment #2 from Allan Jensen ---
Yes, it appears to complete the linktime compilation when using GCC trunk.
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: linux at carewolf dot com
Target Milestone: ---
Enabling the optimization 'split-wide-types' causes worse code for NEON
intrinsics than disabling it, and it is enabled by default by -O1.
It is triggered by mult
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68793
--- Comment #1 from Allan Jensen ---
Created attachment 36957
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36957&action=edit
neon-test.cpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68793
--- Comment #2 from Allan Jensen ---
Created attachment 36958
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36958&action=edit
neon-test-split-wide-types.s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68793
--- Comment #3 from Allan Jensen ---
Created attachment 36959
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36959&action=edit
neon-test-no-split-wide-types.s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68793
--- Comment #5 from Allan Jensen ---
The test-case uses C++11 initialization. I haven't tested gcc 6, so if you say
it is solved, I would trust you.
Note the 32-bit case is also suboptimal in both cases (not affected by
split-wide-types). Is tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68793
--- Comment #6 from Allan Jensen ---
I mean the neon64 case, not 32-bit.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68793
Allan Jensen changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67351
--- Comment #1 from Allan Jensen ---
Created attachment 36254
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36254&action=edit
Compiled test assembler
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: linux at carewolf dot com
Target Milestone: ---
Created attachment 36253
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36253&action=edit
Test
Gcc will expand and detect field setting on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65274
--- Comment #4 from Allan Jensen ---
It works now.
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.
++
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
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 in
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.
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 #4 from Allan Jensen ---
Created attachment 52217
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52217&action=edit
-E output
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=121244
--- Comment #2 from Allan Jensen ---
Sure, I skipped the preprocessed sources because I thought the real problem was
not listing the failed instantiations when encountering a situation causing the
warning at default level. I can add them, though
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: linux at carewolf dot com
Target Milestone: ---
Doing a trial build of Qt with git gcc from 24/7 2025. I hit multiple errors
under -Werror with the new default on Wsfinae-incomplete
101 - 155 of 155 matches
Mail list logo
