https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109509
--- Comment #1 from Chip Kerchner ---
Just for note: The same code that has heavy use always_inline compiles about
3X faster in LLVM and uses about 2X less memory to compile.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109491
--- Comment #14 from Chip Kerchner ---
Just one more question and then I'll switch to the new bug.
Would it help any if the functions that are "always_inline" be changed from
non-static to static?
Eigen's approach (where this code originally c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109491
--- Comment #12 from Chip Kerchner ---
> having always_inline across a deep call stack can exponentially increase
> compile-time
Do you think it would be worth requesting a feature to reduce the compilation
times in situations like this? Idea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109501
--- Comment #8 from Chip Kerchner ---
Well, then I'm asking GCC to add these to make it easier to use
`vec_test_data_class`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109501
--- Comment #5 from Chip Kerchner ---
Here's a testcase
```
#include
#include
int main()
{
__vector float p4f = { float(0), float(1), float(2), float(3) };
__vector __bool int nan_selector = vec_test_data_class(p4f,
__VEC_CLASS_FP_NAN);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109501
--- Comment #4 from Chip Kerchner ---
PowerPC LE - P9.
Yes, other PVIPR APIs are available and compile in more source code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109501
--- Comment #2 from Chip Kerchner ---
'__VEC_CLASS_FP_NAN' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109501
Chip Kerchner changed:
What|Removed |Added
CC||chip.kerchner at ibm dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109501
Bug ID: 109501
Summary: vec_test_data_class defines missing
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70243
--- Comment #4 from Chip Kerchner ---
It shows up as a rounding difference on BE machines.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70243
Chip Kerchner changed:
What|Removed |Added
CC||chip.kerchner at ibm dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109116
--- Comment #2 from Chip Kerchner ---
This could be a bigger issue with register allocation after the disassemble of
an opaque object like vector_pair or MMA.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109116
--- Comment #1 from Chip Kerchner ---
This has been in GCC since the initial version that supported __vector_pair
(10.x)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109116
Bug ID: 109116
Summary: vector_pair register allocation bug
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimiza
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108757
--- Comment #16 from Chip Kerchner ---
Dang copy and paste issue... This is what I meant.
unsigned long int
foo (unsigned long int a)
{
return (a + (N*M)) / N - M;
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108757
--- Comment #15 from Chip Kerchner ---
How about this (from Peter's testcase)? Does it still have issues? It
produces the same assembly.
#define N 32
#define M 2
unsigned long int
foo (unsigned long int a)
{
return (a - (N*M)) / N + M;
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108757
--- Comment #12 from Chip Kerchner ---
Here is an example of the original problem
#define EIGEN_ALWAYS_INLINE __attribute__((always_inline)) inline
typedef __vector float Packet4f;
typedef size_t Index;
EIGEN_ALWAYS_INLINE Packet4f ploadu(con
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108757
--- Comment #11 from Chip Kerchner ---
Nevermind, using a similar example that Segher gave, it would failed too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108757
--- Comment #10 from Chip Kerchner ---
Oops that should be 31 * -2, not 33.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108757
--- Comment #9 from Chip Kerchner ---
Doesn't this work for powers of two (N) and signed values (for A, N and M)?
(59 - (33 * -2)) / -2 + 31 = -62 + 31 = -29
and
59 / -2 = -29
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102059
--- Comment #24 from Chip Kerchner ---
(In reply to Kewen Lin from comment #23)
> Hi Chip, I can reproduce this error with trunk. With some investigation, I
> think it's not duplicated of this PR, some information restoring seems wrong
> when lt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102347
Bug ID: 102347
Summary: "fatal error: target specific builtin not available"
with MMA and LTO
Product: gcc
Version: 10.3.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102059
--- Comment #22 from Chip Kerchner ---
(In reply to Chip Kerchner from comment #21) - Forgot one line of code
> --
> #pragma GCC target "cpu=power10"
> int main() {
> float *b;
> __vector_quad c;
> __builtin_mma_disasse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102059
--- Comment #21 from Chip Kerchner ---
I'm also seeing MMA problems with LTO. With this simple program (main.ii)
--
int main() {
float *b;
__vector_quad c;
__builtin_mma_disassemble_acc(b, &c);
return 0;
}
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102059
Chip Kerchner changed:
What|Removed |Added
CC||chip.kerchner at ibm dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92031
Chip Kerchner changed:
What|Removed |Added
CC||chip.kerchner at ibm dot com
--- Comment
26 matches
Mail list logo
