* altivec amusement
@ 2002-02-21 21:28 Brad Lucier
2002-02-22 1:33 ` Richard Henderson
2002-02-22 15:53 ` Aldy Hernandez
0 siblings, 2 replies; 7+ messages in thread
From: Brad Lucier @ 2002-02-21 21:28 UTC (permalink / raw)
To: gcc; +Cc: Brad Lucier
I tried to port a code that uses AltiVec heavily, originally compiled with
CodeWarrior, to MacOS X using gcc-3.1 CVS. I got an ICE (in emit_move_insn,
at expr.c:2748, if anyone's interested), but unfortunately I'll have to work
hard to see if I can come up with another test case, I can't just post the code.
What was amusing to me was to see the size of the .i file compared to the
.c file: 20687949 bytes versus 12914 bytes. It's going to be interesting
reading through the .i files that come with AltiVec test cases!
Brad
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: altivec amusement
2002-02-21 21:28 altivec amusement Brad Lucier
@ 2002-02-22 1:33 ` Richard Henderson
2002-02-22 15:53 ` Aldy Hernandez
1 sibling, 0 replies; 7+ messages in thread
From: Richard Henderson @ 2002-02-22 1:33 UTC (permalink / raw)
To: Brad Lucier; +Cc: gcc
On Fri, Feb 22, 2002 at 12:23:59AM -0500, Brad Lucier wrote:
> What was amusing to me was to see the size of the .i file compared to the
> .c file: 20687949 bytes versus 12914 bytes.
Yep. The altivec spec is much more suited to c++ than c.
r~
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: altivec amusement
2002-02-21 21:28 altivec amusement Brad Lucier
2002-02-22 1:33 ` Richard Henderson
@ 2002-02-22 15:53 ` Aldy Hernandez
1 sibling, 0 replies; 7+ messages in thread
From: Aldy Hernandez @ 2002-02-22 15:53 UTC (permalink / raw)
To: Brad Lucier; +Cc: gcc
>>>>> "Brad" == Brad Lucier <lucier@math.purdue.edu> writes:
> I tried to port a code that uses AltiVec heavily, originally compiled with
> CodeWarrior, to MacOS X using gcc-3.1 CVS. I got an ICE (in emit_move_insn,
> at expr.c:2748, if anyone's interested), but unfortunately I'll have to work
> hard to see if I can come up with another test case, I can't just
> post the code.
Reduce the testcase to the absolute bare reproducible minimum and
send me the .i.
> What was amusing to me was to see the size of the .i file compared to the
> c file: 20687949 bytes versus 12914 bytes. It's going to be interesting
> reading through the .i files that come with AltiVec test cases!
.i's are not meant for humans in altivec.
Aldy
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: altivec amusement
2002-02-25 17:56 ` Aldy Hernandez
@ 2002-02-26 1:32 ` Joseph S. Myers
0 siblings, 0 replies; 7+ messages in thread
From: Joseph S. Myers @ 2002-02-26 1:32 UTC (permalink / raw)
To: Aldy Hernandez; +Cc: Brad Lucier, GCC Mailinglist
On Tue, 26 Feb 2002, Aldy Hernandez wrote:
> int x[5];
> int *y;
> int foo[__builtin_types_compatible_p (__typeof(x), __typeof(y)) == 1 ?
> 1 : -1];
>
> brad wants the above to compile.
>
> otherwise you can never pass an "int []" when we expect an
> "int *" to an altivec macro/"overloaded function".
Perhaps then you should be using __typeof(*x) and __typeof(*y)? (Or
explicitly checking for array types.)
--
Joseph S. Myers
jsm28@cam.ac.uk
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: altivec amusement
2002-02-25 1:22 ` Joseph S. Myers
@ 2002-02-25 17:56 ` Aldy Hernandez
2002-02-26 1:32 ` Joseph S. Myers
0 siblings, 1 reply; 7+ messages in thread
From: Aldy Hernandez @ 2002-02-25 17:56 UTC (permalink / raw)
To: Joseph S. Myers; +Cc: Brad Lucier, GCC Mailinglist
> __builtin_types_compatible_p correctly distinguishes. __typeof
> correctly
> acts like sizeof in that the array-to-pointer and function-to-pointer
> conversions do not apply to its argument. (Of course the value that
> ends
what i'm talking about is this:
int x[5];
int *y;
int foo[__builtin_types_compatible_p (__typeof(x), __typeof(y)) == 1 ?
1 : -1];
brad wants the above to compile.
otherwise you can never pass an "int []" when we expect an
"int *" to an altivec macro/"overloaded function".
perhaps __builtin_types_compatible_p should return true for pointers
and array of the same underlying type (?)
> up getting passed to the function does have those conversions applied.)
>
> --
> Joseph S. Myers
> jsm28@cam.ac.uk
>
>
--
Aldy Hernandez E-mail: aldyh@redhat.com
Professional Gypsy Lost in Australia
Red Hat, Inc.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: altivec amusement
2002-02-25 1:00 ` Aldy Hernandez
@ 2002-02-25 1:22 ` Joseph S. Myers
2002-02-25 17:56 ` Aldy Hernandez
0 siblings, 1 reply; 7+ messages in thread
From: Joseph S. Myers @ 2002-02-25 1:22 UTC (permalink / raw)
To: Aldy Hernandez; +Cc: Brad Lucier, GCC Mailinglist
On Mon, 25 Feb 2002, Aldy Hernandez wrote:
> joseph, it seems __builtin_types_equal differentiates between
> int foo[]
> and
> int *foo
>
> so what brad is trying to do won't work.
>
> is __builtin_types_equal doing the right thing?
__builtin_types_compatible_p correctly distinguishes. __typeof correctly
acts like sizeof in that the array-to-pointer and function-to-pointer
conversions do not apply to its argument. (Of course the value that ends
up getting passed to the function does have those conversions applied.)
--
Joseph S. Myers
jsm28@cam.ac.uk
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: altivec amusement
[not found] <200202250807.g1P87Hw24573@banach.math.purdue.edu>
@ 2002-02-25 1:00 ` Aldy Hernandez
2002-02-25 1:22 ` Joseph S. Myers
0 siblings, 1 reply; 7+ messages in thread
From: Aldy Hernandez @ 2002-02-25 1:00 UTC (permalink / raw)
To: Brad Lucier; +Cc: Joseph Myers, GCC Mailinglist
[let's ask joseph about this one]
found the problem.
the moto specs are so vague... they're not helpful. this
is a case of "eeech, you may be right, i may be right".
[snip]
vector unsigned char high_products[256];
[snip]
low = vec_ldl((int) *(inp++),high_products);
replace the high_products in the call to vec_ldl with:
(vector unsigned char *)high_products
vec_ldl is expecting a "vector unsigned char *" in the second
argument, not a "vector unsigned char []".
joseph, it seems __builtin_types_equal differentiates between
int foo[]
and
int *foo
so what brad is trying to do won't work.
is __builtin_types_equal doing the right thing?
--
Aldy Hernandez E-mail: aldyh@redhat.com
Professional Gypsy Lost in Australia
Red Hat, Inc.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2002-02-26 9:19 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-02-21 21:28 altivec amusement Brad Lucier
2002-02-22 1:33 ` Richard Henderson
2002-02-22 15:53 ` Aldy Hernandez
[not found] <200202250807.g1P87Hw24573@banach.math.purdue.edu>
2002-02-25 1:00 ` Aldy Hernandez
2002-02-25 1:22 ` Joseph S. Myers
2002-02-25 17:56 ` Aldy Hernandez
2002-02-26 1:32 ` Joseph S. Myers
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).