https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91276
Lauri Kasanen changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91274
--- Comment #3 from Lauri Kasanen ---
Then why is every other type supported, but not 64? It makes no sense.
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: cand at gmx dot com
Target Milestone: ---
Target: ppc64le
Seems gcc is currently missing the VSX built-in that multiplies int vectors.
The vmuluwm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88696
--- Comment #1 from Lauri Kasanen ---
Actually, seems this is only a documentation bug. vec_mul for the int vectors
is not listed on any of the "PowerPC AltiVec/VSX Built-in Functions" pages,
even though it works. It emulates the multiplication o
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: cand at gmx dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
The current error message is not very helpful when linking against a static lib
instead of object
Assignee: unassigned at gcc dot gnu.org
Reporter: cand at gmx dot com
Target Milestone: ---
Host: ppc64le
Target: ppc64le
The 64-bit vector splats for ppc are missing. They are there for s390, and
supported in the IBM compiler.
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: cand at gmx dot com
Target Milestone: ---
Host: ppc64le
Target: ppc64le
C:
#include
#include
int main() {
const unsigned long long r0l
Assignee: unassigned at gcc dot gnu.org
Reporter: cand at gmx dot com
Target Milestone: ---
Host: ppc64le
Target: ppc64le
On the "PowerPC AltiVec Built-in Functions Available on ISA 3.0" page, there
are typos in the crypto vpmsum functions. All o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91275
--- Comment #1 from Lauri Kasanen ---
clang 7.0.0 outputs the expected values, aka the gcc -O0 ones, at all
optimization levels. (it calls the builtin __builtin_altivec_crypto_vpmsumd,
but no other changes)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91275
--- Comment #7 from Lauri Kasanen ---
Thanks for working on this. Per my experience, this is fast for gcc ;)
Are you sure about the smaller ones? To me they should not care about 64-bit
swaps, but clang lists them all as lane-sensitive:
https://
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91275
--- Comment #9 from Lauri Kasanen ---
Can -mno-optimize-swaps be used per-function, in the code via some pragma?
Alternatively, does calling the instruction via inline asm prevent the
swapping?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91275
--- Comment #14 from Lauri Kasanen ---
Inline asm works on the buggy versions. Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82182
--- Comment #2 from Lauri Kasanen ---
It may be a few weeks before I can test newer gcc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82182
Lauri Kasanen changed:
What|Removed |Added
Version|7.2.0 |8.3.0
Known to fail|
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: cand at gmx dot com
Target Milestone: ---
C:
#include
uint16_t mydiv(const uint16_t a, const uint8_t b) {
return a / b;
}
uint16_t mydiv2(const uint16_t a, const uint16_t b) {
return a / b;
}
Assembly
y: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: cand at gmx dot com
Target Milestone: ---
Mednafen's TestGCC81740 test fails with gcc 7.2 using -O3, but it works with
-O2 and -O3 -fno-tree-loop-vectorize. It also fails with gcc 5.2, but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82750
--- Comment #2 from Lauri Kasanen ---
Thanks, passing to mednafen devs.
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: cand at gmx dot com
Target Milestone: ---
Created attachment 36766
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36766&acti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68419
--- Comment #1 from Lauri Kasanen ---
This is very similar to 64551, but not a dup. Another part of IPA failing.
++
Assignee: unassigned at gcc dot gnu.org
Reporter: cand at gmx dot com
GCC 4.8.3 and 4.10 trunk@212302 tested, both broken. According to
https://bugreports.qt-project.org/browse/QTBUG-31988 this is a regression and
worked in 4.7, but I cannot confirm that as 4.7 can't build cu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61721
--- Comment #1 from Lauri Kasanen ---
Created attachment 33073
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33073&action=edit
Failing preprocessed source from 4.10-git
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61721
--- Comment #2 from Lauri Kasanen ---
Created attachment 33074
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33074&action=edit
Working case from 4.10-git (-fno-inline)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61721
--- Comment #3 from Lauri Kasanen ---
$ g++ -v
Using built-in specs.
COLLECT_GCC=/tmp/install/bin/g++
COLLECT_LTO_WRAPPER=/tmp/install/libexec/gcc/x86_64-unknown-linux-gnu/4.10.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./con
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61721
--- Comment #5 from Lauri Kasanen ---
A -fsanitize=undefined built binary does not print anything. I understand it
can't catch all undefined behavior?
What is more interesting that adding -fsanitize=undefined to a failing case
makes it work, cha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61721
Lauri Kasanen changed:
What|Removed |Added
Known to fail|4.10.0 |5.0
--- Comment #7 from Lauri Kasanen -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61721
Lauri Kasanen changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60546
Lauri Kasanen changed:
What|Removed |Added
CC||cand at gmx dot com
--- Comment #23
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: cand at gmx dot com
The following code fails to compile with all GCC versions I have, up to g++
(GCC) 5.0.0 20140817 (experimental). It also fails with clang, but it would be
nice for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68419
--- Comment #3 from Lauri Kasanen ---
The exact arguments are included in my post? Both the gcc configure like that
created them, and the direct args used.
Do you mean 5.3 or git?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68419
Lauri Kasanen changed:
What|Removed |Added
Version|5.2.0 |5.3.0
--- Comment #4 from Lauri Kasanen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68419
--- Comment #6 from Lauri Kasanen ---
Here's more details on my system.
Host gcc: 4.2.2
Host binutils: 2.25.1
m68k binutils: 2.24
I used make -j13, but a parallel build shouldn't affect things. I doubt the
host gcc version is at fault either, g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68419
--- Comment #8 from Lauri Kasanen ---
Today's gcc 5 branch, git 4e07f8a1b79f5e or svn r232358, still fails.
/tmp/gccbuild/./gcc/xgcc -B/tmp/gccbuild/./gcc/ -B/tmp/tmpgcc/m68k-elf/bin/
-B/tmp/tmpgcc/m68k-elf/lib/ -isystem /tmp/tmpgcc/m68k-elf/inc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68419
--- Comment #9 from Lauri Kasanen ---
Your command line from comment #5 fails similarly, on my original attachment.
./gcc/cc1 -O2 unwind-dw2.i -g -auxbase-strip unwind-dw2.o -g -O2
-fbuilding-libgcc -fno-stack-protector -fexceptions -fvisibility
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68419
--- Comment #10 from Lauri Kasanen ---
When using gcc 5.2 as the host compiler, there is no crash.
The gcc docs state that any version of gcc above 3.4 is supported, so this is
still a bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68419
--- Comment #12 from Lauri Kasanen ---
https://gcc.gnu.org/install/prerequisites.html
"To build all languages in a cross-compiler or other configuration where
3-stage bootstrap is not performed, you need to start with an existing GCC
binary (ver
35 matches
Mail list logo