Re: recent troubles with float vectors & bitwise ops

[Paolo Bonzini]

Why did Intel split up these instructions in the first place, is it
because they wanted to have a seperate vector units in some cases?
I don't know and I don't care that much. 


To some extent I agree with Andrew Pinski here.  Saying that you need 
support in a generic vector extension for "vector float | vector float" 
in order to generate ANDPS and not PXOR, is just wrong.  That should be 
done by the back-end.


Paolo

Re: recent troubles with float vectors & bitwise ops

[Paolo Bonzini]

The IA-32 instruction set does distignuish between integer and
floating point bitiwse operations.  In addition to the single-precision
floating-point bitwise instructions that tbp mentioned (ORPS, ANDPS,
ANDNPS and XORPS) there are both distinct double-precision floating-point
bitwise instructions (ORPD, ANDPD, ANDNPD and XORPD) and integer bitwise
instructions (POR, PAND, PANDN and PXOR).  While these operations all do
the same thing, they can differ in performance depending on the context.


Oops, I only remembered PS vs. PD (I remembered POR as MMX instructions 
only).  I believe that optimizing this should be a task for the x86 
machine dependent reorg.


Paolo

Re: Why is building a cross compiler "out-of-the-box" always broken?

[Paolo Bonzini]

Rask Ingemann Lambertsen wrote:

On Sun, Aug 19, 2007 at 10:09:25AM +0200, Paolo Bonzini wrote:

  Thanks for reminding me to ping that patch.

Could you try moving this case statement

+   case "$target" in
+ i[[3456]]86-*-elf* | i[[3456]]86-*-coff*)
+   libgloss_dir=i386
+   ;;
+ m68hc11-*-* | m6811-*-* | m68hc12-*-* | m6812-*-*)
+   libgloss_dir=m68hc11
+   ;;

above in another "case $target in" statement?


   I don't understand what you want it to look like. Your explanation sounds
to me like

case "$target" in
  i[[3456]]86-*-elf* | i[[3456]]86-*-coff*)
libgloss_dir=i386
;;
  m68hc11-*-* | m6811-*-* | m68hc12-*-* | m6812-*-*)
libgloss_dir=m68hc11
;;
esac


Sorry, I meant "all the case statement".  There are many case "$target" 
statements and I would rather avoid trying to avoid one.  Setting 
libgloss_dir=${cpu} as a default can be done above the case "$target" 
you choose.


Paolo

Re: recent troubles with float vectors & bitwise ops

[Ross Ridge]

Ross Ridge <[EMAIL PROTECTED]> wrote:
> GCC makes the problem is even worse if only SSE and not SSE 2 instructions
> are enabled.  Since the integer bitwise instructions are only available
> with SSE 2, using casts instead of intrinsics causes GCC to expand the
> operation into a long series of instructions.

Andrew Pinski writes:
...
>Why did Intel split up these instructions in the first place, is it
>because they wanted to have a seperate vector units in some cases?
>I don't know and I don't care that much. 

Well, if you would rather remain ingorant, I suppose there's little
point in discussing this with you.  However, please don't try to pretend
that the vector extenstions are supposed to be generic when you use
justifications like it's how Altivec works, and it's compatible with
a proprietary "standard" called "C/C++ Language Extensions for Cell
Broadband Engine Architecture".  If you're going to continue to use
justifications like this and ignore the performance implications of
your changes on IA-32, then you should accept the fact that the vector
extensions are not ment for platforms that you don't know and don't care
that much about.

Ross Ridge

Re: recent troubles with float vectors & bitwise ops

[Andrew Pinski]

On 8/22/07, Ross Ridge <[EMAIL PROTECTED]> wrote:
> GCC makes the problem is even worse if only SSE and not SSE 2 instructions
> are enabled.  Since the integer bitwise instructions are only available
> with SSE 2, using casts instead of intrinsics causes GCC to expand the
> operation into a long series of instructions.

And why do a bad decission based on another bad decission?  Why did
Intel split up these instructions in the first place, is it because
they wanted to have a seperate vector units in some cases?  I don't
know and I don't care that much.  This extension is supposed to be
generic and doing weird stuff by allowing bitwise operators on vector
float just confuses people more.  Yes Intel/AMD's specific instruction
set includes that but not everyone elses.

> If I were tbp, I'd just code all his vector operatations using intrinsics.
> The other responses in this thread have made it clear that GCC's vector
> arithemetic operations are really only designed to be used with the Cell
> Broadband Engine and other Power PC processors.

No, they were designed to be generic.  The issue comes down to what is
generic.  I am saying that don't allow it for scalar fp types, why
allow it for vector fp types?  The genericism here is that vector is
just an expansion on top of the scalar types.  Not many new features
are supposed to be added.

-- Pinski

Re: recent troubles with float vectors & bitwise ops

[Ross Ridge]

Ross Ridge writes:
>tbp is correct.  Using casts gets you the integer bitwise instrucitons,
>not the single-precision bitwise instructions that are more optimal for
>flipping bits in single-precision vectors.  If you want GCC to generate
>better code using single-precision bitwise instructions you're now forced
>to use the intrinsics.

GCC makes the problem is even worse if only SSE and not SSE 2 instructions
are enabled.  Since the integer bitwise instructions are only available
with SSE 2, using casts instead of intrinsics causes GCC to expand the
operation into a long series of instructions.

If I were tbp, I'd just code all his vector operatations using intrinsics.
The other responses in this thread have made it clear that GCC's vector
arithemetic operations are really only designed to be used with the Cell
Broadband Engine and other Power PC processors.

Ross Ridge

Re: pragma-like warning turn off ?

[DJ Delorie]

> How do you know that code motion will not move things across the
> pragmas in a backwards direction?

How do the warnings know what line to report *now* ?

gcc-4.2-20070822 is now available

[gccadmin]

Snapshot gcc-4.2-20070822 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20070822/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.2 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_2-branch 
revision 127719

You'll find:

gcc-4.2-20070822.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.2-20070822.tar.bz2 C front end and core compiler

gcc-ada-4.2-20070822.tar.bz2  Ada front end and runtime

gcc-fortran-4.2-20070822.tar.bz2  Fortran front end and runtime

gcc-g++-4.2-20070822.tar.bz2  C++ front end and runtime

gcc-java-4.2-20070822.tar.bz2 Java front end and runtime

gcc-objc-4.2-20070822.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.2-20070822.tar.bz2The GCC testsuite

Diffs from 4.2-20070815 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.2
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: pragma-like warning turn off ?

[Robert Dewar]

DJ Delorie wrote:

Ian Lance Taylor <[EMAIL PROTECTED]> writes:

Let's do that.


We've already talked about keeping track of the source location of
each #pragma, and searching them for the "state" at a given line.  The
diagnostic machinery seems to be able to tell what file/line each
diagnostic is for, we should be able to scan the pragma list to see
what right thing to do is.  I think this would be far easier than
trying to queue up all the diagnostics and *then* scan the list.


How do you know that code motion will not move things across the
pragmas in a backwards direction?


Assuming we've fully converted to the single-integer source location.

Re: recent troubles with float vectors & bitwise ops

[Andrew Pinski]

On 8/22/07, Andrew Pinski <[EMAIL PROTECTED]> wrote:
> Which hardware (remember GCC is a generic compiler)?  VMX/Altivec and
> SPU actually does not have different instructions for bitwise
> and/ior/xor for different vector types (it is all the same
> instruction).  I have ran into ICEs with even bitwise on vector
> float/double on x86 also in the past which is the other reason why I
> disabled them.  Since this is an extension, it would be nice if it was
> nicely defined extension which means disabling them for vector
> float/double.

One more note, the "C/C++ Language extensions for the CBEA"
specifications,  says that the bitwise operators don't work on vector
float/double but do work on the integer vector types.  So the other
reason why this change I did was to make us more conforming with that
standard (yes I worked on that spec but I did not write that part).

-- Pinski

Re: recent troubles with float vectors & bitwise ops

[Andrew Pinski]

On 8/22/07, tbp <[EMAIL PROTECTED]> wrote:
> On 8/22/07, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
> > I think you're running too far with your sarcasm. SSE's instructions do
> > not go so far as to specify integer vs. floating point.  To me, "ps"
> > means "32-bit SIMD", independent of integerness.
> Excuse me if i'm amazed being replied  bitwise ops on floating values
> make no sense as the justification for breaking something that used to
> work and match hardware features. I naively thought that was the
> purpose of that convenient extension.

Which hardware (remember GCC is a generic compiler)?  VMX/Altivec and
SPU actually does not have different instructions for bitwise
and/ior/xor for different vector types (it is all the same
instruction).  I have ran into ICEs with even bitwise on vector
float/double on x86 also in the past which is the other reason why I
disabled them.  Since this is an extension, it would be nice if it was
nicely defined extension which means disabling them for vector
float/double.

Thanks,
Andrew Pinski

Re: Why is building a cross compiler "out-of-the-box" always broken?

[Rask Ingemann Lambertsen]

On Sun, Aug 19, 2007 at 10:09:25AM +0200, Paolo Bonzini wrote:
> 
> >   Thanks for reminding me to ping that patch.
> 
> Could you try moving this case statement
> 
> + case "$target" in
> +   i[[3456]]86-*-elf* | i[[3456]]86-*-coff*)
> + libgloss_dir=i386
> + ;;
> +   m68hc11-*-* | m6811-*-* | m68hc12-*-* | m6812-*-*)
> + libgloss_dir=m68hc11
> + ;;
> 
> above in another "case $target in" statement?

   I don't understand what you want it to look like. Your explanation sounds
to me like

case "$target" in
  i[[3456]]86-*-elf* | i[[3456]]86-*-coff*)
libgloss_dir=i386
;;
  m68hc11-*-* | m6811-*-* | m68hc12-*-* | m6812-*-*)
libgloss_dir=m68hc11
;;
esac

case "$target" in
... rest of cases go here ...

  *)
libgloss_dir=${cpu}
;;
esac

but then the default of the second case construct will override libgloss_dir
from the first one, if I'm not missing something here.

-- 
Rask Ingemann Lambertsen

Re: recent troubles with float vectors & bitwise ops

[tbp]

On 8/22/07, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
> I think you're running too far with your sarcasm. SSE's instructions do
> not go so far as to specify integer vs. floating point.  To me, "ps"
> means "32-bit SIMD", independent of integerness.
Excuse me if i'm amazed being replied  bitwise ops on floating values
make no sense as the justification for breaking something that used to
work and match hardware features. I naively thought that was the
purpose of that convenient extension.

> > So, that's what i feared... it was intentional. And now i guess the only
> > sanctioned access to those ops is via builtins/intrinsics.
> No, you can do so with casts.  Floating-point to integer vector casts
> preserve the bit pattern.  For example, you can do
Again SIMD ops (among them bitwise stuff) comes in 3 mostly symmetric
flavors on x86 namely for int, float and doubles; "casting" isn't
innocuous because there's a penalty for type mismatch (1 cycle of
re-categorization if i remember for both k8 and core2), so it's either
that or some moving around.

Let me cite "Intel(r) 64 and IA-32 Architectures Optimization
Reference Manual",  5-1,
"When writing SIMD code that works for both integer and floating-point
data, use
the subset of SIMD convert instructions or load/store instructions to
ensure that
the input operands in XMM registers contain data types that are
properly defined
to match the instruction.
Code sequences containing cross-typed usage produce the same result across
different implementations but incur a significant performance penalty. Using
SSE/SSE2/SSE3/SSSE3 instructions to operate on type-mismatched SIMD data
in the XMM register is strongly discouraged."

You could find a similar note in AMD's doc for the k8.

Re: recent troubles with float vectors & bitwise ops

[Ross Ridge]

tbp writes:
>Apparently enough for a small vendor like Intel to propose such things
>as orps, andps, andnps, and xorps.

Paolo Bonzini writes:
>I think you're running too far with your sarcasm. SSE's instructions
>do not go so far as to specify integer vs. floating point.  To me, "ps"
>means "32-bit SIMD", independent of integerness

The IA-32 instruction set does distignuish between integer and
floating point bitiwse operations.  In addition to the single-precision
floating-point bitwise instructions that tbp mentioned (ORPS, ANDPS,
ANDNPS and XORPS) there are both distinct double-precision floating-point
bitwise instructions (ORPD, ANDPD, ANDNPD and XORPD) and integer bitwise
instructions (POR, PAND, PANDN and PXOR).  While these operations all do
the same thing, they can differ in performance depending on the context.

Intel's IA-32 Software Developer's Manual gives this warning:

In this example: XORPS or PXOR can be used in place of XORPD
and yield the same correct result. However, because of the type
mismatch between the operand data type and the instruction data
type, a latency penalty will be incurred due to implementations
of the instructions at the microarchitecture level.

>>And now i guess the only sanctioned access to those ops is via
>>builtins/intrinsics.
>
>No, you can do so with casts.

tbp is correct.  Using casts gets you the integer bitwise instrucitons,
not the single-precision bitwise instructions that are more optimal for
flipping bits in single-precision vectors.  If you want GCC to generate
better code using single-precision bitwise instructions you're now forced
to use the intrinsics.

Ross Ridge

Re: pragma-like warning turn off ?

[DJ Delorie]

Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> Let's do that.

We've already talked about keeping track of the source location of
each #pragma, and searching them for the "state" at a given line.  The
diagnostic machinery seems to be able to tell what file/line each
diagnostic is for, we should be able to scan the pragma list to see
what right thing to do is.  I think this would be far easier than
trying to queue up all the diagnostics and *then* scan the list.

Assuming we've fully converted to the single-integer source location.

Re: pragma-like warning turn off ?

[Ian Lance Taylor]

Robert Dewar <[EMAIL PROTECTED]> writes:

> Ian Lance Taylor wrote:
> 
> > It's fairly difficult.  You want a way to turn off specific warnings
> > for specific parts of the IR.  The IR is combined and rearranged
> > during optimization, so you need to figure out how to make the warning
> > control track those changes.
> 
> A simpler approach, used in the GNAT front end, is to keep a list of
> the warning on/off pragmas. Warnings are not output as they are
> generated but rather stored for later output.
> 
> Then after the compilation has completed, the warnings are sorted
> and generated, consulting the pragma list to see if they should
> be suppressed. This approach avoids the problems cited above
> entirely.

Nice.

Let's do that.

Ian

RE: recent troubles with float vectors & bitwise ops

[Dave Korn]

On 22 August 2007 14:06, Rask Ingemann Lambertsen wrote:

> On Wed, Aug 22, 2007 at 11:47:52AM +0100, Dave Korn wrote:
>> 
>>   Well, I like to think that I could cast the address to unsigned char*,
>> memcpy a bunch of them to the address of an int, then dereference the int and
>> the compiler would realise it was a no-op and optimise it away, but I doubt
>> thatt would actually happen...   
> 
>It did a few months ago, at least for scalar variables. 

  I'm proper impressed!

> Have we regressed in this area?

  Not that I know of.  


cheers,
  DaveK
-- 
Can't think of a witty .sigline today

Re: recent troubles with float vectors & bitwise ops

[Rask Ingemann Lambertsen]

On Wed, Aug 22, 2007 at 11:47:52AM +0100, Dave Korn wrote:
> 
>   Well, I like to think that I could cast the address to unsigned char*, 
> memcpy a bunch of them to the address of an int, then dereference the int and 
> the compiler would realise it was a no-op and optimise it away, but I doubt 
> thatt would actually happen...

   It did a few months ago, at least for scalar variables. Have we
regressed in this area?

-- 
Rask Ingemann Lambertsen

Re: PR179 reopened (was it ever fixed?)

[Manuel López-Ibáñez]

On 16/08/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
> On 8/16/07 6:18 AM, Manuel López-Ibáñez wrote:
>
> That's right.  In this case variable 'i' is an addressable local, so it
> is not put in normal SSA form.  It's in virtual SSA form (use the -vops
> option when dumping the IL).  We don't warn on memory symbols, only
> registers.
>
> One way to address this could be to consider 'i.0' uninitialized because
> its initial value is coming from a local memory symbol with no know
> initialization.  Notice that the initial assignment to i.0 has a VUSE
> for i's default definition.  You could probably use that to warn that
> 'i' is being used uninitialized.

This patch fixes gcc.dg/uninit-B.c:

=
--- gcc/tree-ssa.c  (revision 126606)
+++ gcc/tree-ssa.c  (working copy)
@@ -1205,7 +1205,7 @@
 /* Emit a warning for T, an SSA_NAME, being uninitialized.  The exact
   warning text is in MSGID and LOCUS may contain a location or be null.  */

-static void
+void
 warn_uninit (tree t, const char *gmsgid, void *data)
 {
  tree var = SSA_NAME_VAR (t);
@@ -1217,8 +1217,40 @@
  /* Default uses (indicated by an empty definition statement),
 are uninitialized.  */
  if (!IS_EMPTY_STMT (def))
+{
+/* Otherwise, it may be an initial assignment that has a VUSE
+   to a variable's default definition.  */
+if (TREE_CODE (def) == GIMPLE_MODIFY_STMT
+&& has_stmt_ann (def)
+&& ssa_operands_active ()
+&& stmt_references_memory_p (def))
+{
+  struct voptype_d *vuses = VUSE_OPS (def);
+  while (vuses)
+{
+  int i;
+  int n = VUSE_NUM (vuses);
+  for (i = 0; i < n; i++)
+{
+  if (TREE_CODE (VUSE_OP (vuses, i)) == SSA_NAME)
+warn_uninit (VUSE_OP (vuses, i),
+ "%H%qD is used uninitialized in this function",
+ def);
+}
+  vuses = vuses->next;
+}
+}
+  return;
+}
+
+  /* We don't warn for global variables or memory tags. */
+  if (MTAG_P (var) || !is_gimple_variable (var)
+  || !is_gimple_reg_type (TREE_TYPE (var))
+  || TREE_THIS_VOLATILE (var)
+  || is_global_var (var))
return;

+
  /* Except for PARMs of course, which are always initialized.  */
  if (TREE_CODE (var) == PARM_DECL)
return;

However, it gives new false positives. I don't see how can I
differentiate between the two following examples. When i.0D.1284_2 =
iD.1283; is analyzed by warn_uninit, the situation looks exactly the
same to me.

f ()
{
 intD.0 iD.1283;
 intD.0 i.0D.1284;

 # BLOCK 0, starting at line 8
 # PRED: ENTRY (fallthru)
 [doublereference-2.c : 8] g (&iD.1283);
 #   VUSE ;
 [doublereference-2.c : 9] i.0D.1284_2 = iD.1283;
 [doublereference-2.c : 9] h (i.0D.1284_2);
 [doublereference-2.c : 10] return;
 # SUCC: EXIT

}

f ()
{
 intD.0 iD.1283;
 intD.0 i.0D.1284;

 # BLOCK 0, starting at line 7
 # PRED: ENTRY (fallthru)
 #   VUSE ;
 [doublereference-3.c : 7] i.0D.1284_2 = iD.1283;
 [doublereference-3.c : 7] h (i.0D.1284_2);
 [doublereference-3.c : 8] g (&iD.1283);
 [doublereference-3.c : 9] return;
 # SUCC: EXIT
}

Am I missing something?

Cheers,

Manuel.

Re: pragma-like warning turn off ?

[Robert Dewar]

Ian Lance Taylor wrote:


It's fairly difficult.  You want a way to turn off specific warnings
for specific parts of the IR.  The IR is combined and rearranged
during optimization, so you need to figure out how to make the warning
control track those changes.


A simpler approach, used in the GNAT front end, is to keep a list of
the warning on/off pragmas. Warnings are not output as they are 
generated but rather stored for later output.


Then after the compilation has completed, the warnings are sorted
and generated, consulting the pragma list to see if they should
be suppressed. This approach avoids the problems cited above
entirely.


There was some recent discussion of this on the gcc-patches mailing
list.  Look for __nowarn__.

Ian

RE: recent troubles with float vectors & bitwise ops

[Dave Korn]

On 22 August 2007 11:40, Andrew Pinski wrote:

> On 8/22/07, Dave Korn <[EMAIL PROTECTED]> wrote:
>> float InvSqrt (float x){
>> float xhalf = 0.5f*x;
>> int i = *(int*)&x;
> 
> You are violating C/C++ aliasing rules here anyways.
> 
>> i = 0x5f3759df - (i>>1);
>> x = *(float*)&i;
> 
> Likewise.
> 
> So I guess you like to depend on undefined code :).

  Well, I like to think that I could cast the address to unsigned char*, memcpy 
a bunch of them to the address of an int, then dereference the int and the 
compiler would realise it was a no-op and optimise it away, but I doubt thatt 
would actually happen...


cheers,
  DaveK
-- 
Can't think of a witty .sigline today

Re: recent troubles with float vectors & bitwise ops

[Andrew Pinski]

On 8/22/07, Dave Korn <[EMAIL PROTECTED]> wrote:
> float InvSqrt (float x){
> float xhalf = 0.5f*x;
> int i = *(int*)&x;

You are violating C/C++ aliasing rules here anyways.

> i = 0x5f3759df - (i>>1);
> x = *(float*)&i;

Likewise.

So I guess you like to depend on undefined code :).

-- Pinski

RE: recent troubles with float vectors & bitwise ops

[Dave Korn]

On 22 August 2007 11:13, Andrew Pinski wrote:

> On 8/21/07, tbp <[EMAIL PROTECTED]> wrote:
>> # /usr/local/gcc-4.3-svn.old6/bin/g++ vecop.cc
>> vecop.cc: In function 'T foo() [with T = float __vector__]':
>> vecop.cc:13:   instantiated from here
>> vecop.cc:4: error: invalid operands of types 'float __vector__' and
>> 'float __vector__' to binary 'operator|'
>> vecop.cc:5: error: invalid operands of types 'float __vector__' and
>> 'float __vector__' to binary 'operator&'
>> vecop.cc:6: error: invalid operands of types 'float __vector__' and
>> 'float __vector__' to binary 'operator^'
>> 
>> Apparently it's still there as of right now, on x86-64 at least. I think
>> this is not supposed to happen but i'm not sure, hence the mail.
> 
> This is internally, float|float does not make sense so how can vector
> float | vector float make sense (likewise for & and ^).


float InvSqrt (float x){
float xhalf = 0.5f*x;
int i = *(int*)&x;
i = 0x5f3759df - (i>>1);
x = *(float*)&i;
x = x*(1.5f - xhalf*x*x);
return x;
}


  It's not exactly what you're referring to, but it's evidence in favour of the 
argument that we should never presume anything, no matter how unusual, might 
not have a reasonable use.  (However as I said, I'm not arguing against the 
error message, since it's still possible to express this intent using casts.)

cheers,
  DaveK
-- 
Can't think of a witty .sigline today

[c++0x] parameter packs in class templates

[Jan van Dijk]

Good afternoon,

Today I started to play around with g++' c++0x mode. I tried to compile the 
following toy program:

template
struct pack_size
{
enum { value = 1 + pack_size::value };
};

template 
struct pack_size
{
enum { value = 1 };
};

struct A{};

void foo()
{
static_assert(pack_size::value==3,"Pack size error");
}

With today's trunk this does not compile:

$ g++ -c -std=c++0x t.cpp
t.cpp:4: error: cannot expand ‘Pack ...’ into a fixed-length argument list

I was surprised by this message: since the second argument of the primary 
pack_size template is a parameter pack, the argument list is (at least 
conceptually) not of fixed length. After removing the test that generates 
this diagnostic from gcc/cp/pt.c (see patch at the bottom of this message), 
the code compiles fine.

 * assuming the code is valid, my 'fix' is probably not correct (I now nothing 
about C++ internals). The intention of this patch is that, if we pass (only) 
a parameter pack to a context that expects (non-pack) template arguments, 
_followed by_ a parameter pack, the first parameters should be stripped off 
the pack. What remains of the pack is used as the last (pack) parameter. This 
is consistent with my understanding of how variadic _function_ templates 
work.

 * I read n2152.pdf, only to find out that that document refers (almost) 
exclusively to variadic _function_ templates. I did not find anything that 
discusses my use-case.

 * If the standard is not explicit about the validity of this code: If a pack 
expansion is equivalent to the sequence formed by its members, I guess that 
my code should be valid. In that case the problematic 
code 'pack_size' on line 4 is equivalent to the code 
pack_size (line 17) that is fine (?).

Thank you for considering this issue.

With kind regards,

Jan van Dijk.


Index: pt.c
===
--- pt.c(revision 127686)
+++ pt.c(working copy)
@@ -5034,7 +5034,7 @@
   else if (arg_idx < nargs)
 {
   arg = TREE_VEC_ELT (inner_args, arg_idx);
-
+#if 0
   if (arg && PACK_EXPANSION_P (arg))
 {
   /* If ARG is a pack expansion, but PARM is not a
@@ -5048,6 +5048,7 @@
 error ("cannot expand %<%T%> into a fixed-length "
"argument list", arg);
 }
+#endif
 }
   else if (require_all_args)
 /* There must be a default arg in this case.  */

Re: recent troubles with float vectors & bitwise ops

[Andrew Pinski]

On 8/21/07, tbp <[EMAIL PROTECTED]> wrote:
> # /usr/local/gcc-4.3-svn.old6/bin/g++ vecop.cc
> vecop.cc: In function 'T foo() [with T = float __vector__]':
> vecop.cc:13:   instantiated from here
> vecop.cc:4: error: invalid operands of types 'float __vector__' and
> 'float __vector__' to binary 'operator|'
> vecop.cc:5: error: invalid operands of types 'float __vector__' and
> 'float __vector__' to binary 'operator&'
> vecop.cc:6: error: invalid operands of types 'float __vector__' and
> 'float __vector__' to binary 'operator^'
>
> Apparently it's still there as of right now, on x86-64 at least. I think
> this is not supposed to happen but i'm not sure, hence the mail.

This is internally, float|float does not make sense so how can vector
float | vector float make sense (likewise for & and ^).

This was PR 30428.

-- Pinski

RE: recent troubles with float vectors & bitwise ops

[Dave Korn]

On 22 August 2007 06:10, Ian Lance Taylor wrote:

> tbp <[EMAIL PROTECTED]> writes:
> 
>> vecop.cc:4: error: invalid operands of types 'float __vector__' and
>> 'float __vector__' to binary 'operator|'
>> vecop.cc:5: error: invalid operands of types 'float __vector__' and
>> 'float __vector__' to binary 'operator&'
>> vecop.cc:6: error: invalid operands of types 'float __vector__' and
>> 'float __vector__' to binary 'operator^'
>> 
>> Apparently it's still there as of right now, on x86-64 at least. I
>> think this is not supposed to happen but i'm not sure, hence the mail.
> 
> What does it mean to do a bitwise-or of a floating point value?
> 
> This code also gets an error:
> 
> double foo(double a, double b) { return a | b; }


  There are some notable fp hacks and speedups that make use of integer ops on
floating point operands, so it's not entirely an insane notion.

  However, as Paolo points out upthread, that can be done with casts, which is
more correct anyway, so I don't think there's a problem with blocking the
unadorned usage.

cheers,
  DaveK
-- 
Can't think of a witty .sigline today

Re: Implementing VMX128 AltiVec Variant

[Gordan Bobic]

On Wed, 22 Aug 2007, Paolo Bonzini wrote:


> >  With the modifications I made, GCC still compiled fine. However,
> >  libgcc and libstdc++ DO still get build with the missing instructions
> >  (according to objdump -D). Why is that? Is that a consequence of the
> >  ADA files? Or something else? Where should I look? Is the it ada files
> >  that are the cause of the problem I'm seeing?
> 
>  It must be something else.  I'm not sure what, though.  It might be

>  something as simple as an instruction built from substrings.  For
>  example, search for altivec_vmsumum in altivec.md.

 I just re-checked for that and I can't find any. I have attached a diff
 for my modified altivec.h, altivec.md and rs6000.c files. Patch in
 gcc/config/rs6000 subtree with -p1.

 Can anyone think of anywhere else I should be looking? Where else could
 these instructions be coming from?


This is really not relevant to the posted patch; however, I'll still post it 
here.


The proper way to disable Altivec instructions is to leave altivec.h and 
rs6000.c aside, and just change the "TARGET_ALTIVEC" to something like 
"(TARGET_ALTIVEC && 0)".  The remaining code will automagically be disabled.


Later, you can add your option and the corresponding TARGET_VMX128 mask, and 
go back replacing the "TARGET_ALTIVEC && 0" with "TARGET_ALTIVEC && 
!TARGET_VMX128".


Thanks for that. This is the sort of thing I was hoping to eventually 
implement (rather than re-implementing vmx128.h and vmx128.md from scratch 
with 90% overlap with altivec.h and altivec.md). But I'd really like to go 
with a quick and dirty proof of concept first, which is to just cut out 
the offending instructions from altivec support, just to make sure that it 
would work.


Gordan

Re: recent troubles with float vectors & bitwise ops

[Paolo Bonzini]

Apparently enough for a small vendor like Intel to propose such things 
as orps, andps, andnps, and xorps.


I think you're running too far with your sarcasm. SSE's instructions do 
not go so far as to specify integer vs. floating point.  To me, "ps" 
means "32-bit SIMD", independent of integerness.


So, that's what i feared... it was intentional. And now i guess the only 
sanctioned access to those ops is via builtins/intrinsics.


No, you can do so with casts.  Floating-point to integer vector casts 
preserve the bit pattern.  For example, you can do


vector float f = { 5, 5, 5, 5 };
vector int g = { 0x8000, 0, 0x8000, 0 };
vector int f_int = (vector int) f;
f = (vector float) (f_int ^ g);

For Altivec, I get exactly

addis r2,r10,ha16(LC0-"gibberish")
la r2,lo16(LC0-"gibberish")(r2)
lvx v0,0,r2
vxor v2,v2,v0
...
LC0:
.long   -2147483648
.long   0
.long   -2147483648
.long   0

Paolo

Re: Implementing VMX128 AltiVec Variant

[Paolo Bonzini]

Gordan Bobic wrote:

On Tue, 21 Aug 2007, Ian Lance Taylor wrote:


With the modifications I made, GCC still compiled fine. However,
libgcc and libstdc++ DO still get build with the missing instructions
(according to objdump -D). Why is that? Is that a consequence of the
ADA files? Or something else? Where should I look? Is the it ada files
that are the cause of the problem I'm seeing?


It must be something else.  I'm not sure what, though.  It might be
something as simple as an instruction built from substrings.  For
example, search for altivec_vmsumum in altivec.md.


I just re-checked for that and I can't find any. I have attached a diff 
for my modified altivec.h, altivec.md and rs6000.c files. Patch in 
gcc/config/rs6000 subtree with -p1.


Can anyone think of anywhere else I should be looking? Where else could 
these instructions be coming from?


This is really not relevant to the posted patch; however, I'll still 
post it here.


The proper way to disable Altivec instructions is to leave altivec.h and 
rs6000.c aside, and just change the "TARGET_ALTIVEC" to something like 
"(TARGET_ALTIVEC && 0)".  The remaining code will automagically be disabled.


Later, you can add your option and the corresponding TARGET_VMX128 mask, 
and go back replacing the "TARGET_ALTIVEC && 0" with "TARGET_ALTIVEC && 
!TARGET_VMX128".


Paolo

Re: Implementing VMX128 AltiVec Variant

[Gordan Bobic]

On Tue, 21 Aug 2007, Ian Lance Taylor wrote:


With the modifications I made, GCC still compiled fine. However,
libgcc and libstdc++ DO still get build with the missing instructions
(according to objdump -D). Why is that? Is that a consequence of the
ADA files? Or something else? Where should I look? Is the it ada files
that are the cause of the problem I'm seeing?


It must be something else.  I'm not sure what, though.  It might be
something as simple as an instruction built from substrings.  For
example, search for altivec_vmsumum in altivec.md.


I just re-checked for that and I can't find any. I have attached a diff 
for my modified altivec.h, altivec.md and rs6000.c files. Patch in 
gcc/config/rs6000 subtree with -p1.


Can anyone think of anywhere else I should be looking? Where else could 
these instructions be coming from?


Thanks.

Gordandiff -uN altivec/altivec.h vmx128/altivec.h
--- altivec/altivec.h   2007-08-22 09:31:46.0 +0100
+++ vmx128/altivec.h2007-08-22 09:31:21.0 +0100
@@ -71,9 +71,6 @@
 #define vec_lvxl vec_ldl
 #define vec_vlogefp vec_loge
 #define vec_vmaddfp vec_madd
-#define vec_vmhaddshs vec_madds
-#define vec_vmladduhm vec_mladd
-#define vec_vmhraddshs vec_mradds
 #define vec_vnmsubfp vec_nmsub
 #define vec_vnor vec_nor
 #define vec_vor vec_or
@@ -94,8 +91,6 @@
 #define vec_stvx vec_st
 #define vec_stvxl vec_stl
 #define vec_vsubcuw vec_subc
-#define vec_vsum2sws vec_sum2s
-#define vec_vsumsws vec_sums
 #define vec_vrfiz vec_trunc
 #define vec_vxor vec_xor
 
@@ -142,20 +137,6 @@
 #define vec_vminsh __builtin_vec_vminsh
 #define vec_vminsb __builtin_vec_vminsb
 #define vec_mradds __builtin_vec_mradds
-#define vec_vmsumshm __builtin_vec_vmsumshm
-#define vec_vmsumuhm __builtin_vec_vmsumuhm
-#define vec_vmsummbm __builtin_vec_vmsummbm
-#define vec_vmsumubm __builtin_vec_vmsumubm
-#define vec_vmsumshs __builtin_vec_vmsumshs
-#define vec_vmsumuhs __builtin_vec_vmsumuhs
-#define vec_vmulesb __builtin_vec_vmulesb
-#define vec_vmulesh __builtin_vec_vmulesh
-#define vec_vmuleuh __builtin_vec_vmuleuh
-#define vec_vmuleub __builtin_vec_vmuleub
-#define vec_vmulosh __builtin_vec_vmulosh
-#define vec_vmulouh __builtin_vec_vmulouh
-#define vec_vmulosb __builtin_vec_vmulosb
-#define vec_vmuloub __builtin_vec_vmuloub
 #define vec_nmsub __builtin_vec_nmsub
 #define vec_packpx __builtin_vec_packpx
 #define vec_vpkswss __builtin_vec_vpkswss
@@ -173,9 +154,6 @@
 #define vec_vsubshs __builtin_vec_vsubshs
 #define vec_vsubsbs __builtin_vec_vsubsbs
 #define vec_sum4s __builtin_vec_sum4s
-#define vec_vsum4shs __builtin_vec_vsum4shs
-#define vec_vsum4sbs __builtin_vec_vsum4sbs
-#define vec_vsum4ubs __builtin_vec_vsum4ubs
 #define vec_sum2s __builtin_vec_sum2s
 #define vec_sums __builtin_vec_sums
 #define vec_trunc __builtin_vec_trunc
diff -uN altivec/altivec.md vmx128/altivec.md
--- altivec/altivec.md  2007-08-22 09:31:46.0 +0100
+++ vmx128/altivec.md   2007-08-22 09:31:21.0 +0100
@@ -566,53 +566,6 @@
 ;;   [(set (match_operand:V4SI 0 "register_operand" "=v")
 ;; (mult:V4SI (match_operand:V4SI 1 "register_operand" "v")
 ;;(match_operand:V4SI 2 "register_operand" "v")))]
-(define_expand "mulv4si3"
-  [(use (match_operand:V4SI 0 "register_operand" ""))
-   (use (match_operand:V4SI 1 "register_operand" ""))
-   (use (match_operand:V4SI 2 "register_operand" ""))]
-   "TARGET_ALTIVEC"
-   "
- {
-   rtx zero;
-   rtx swap;
-   rtx small_swap;
-   rtx sixteen;
-   rtx one;
-   rtx two;
-   rtx low_product;
-   rtx high_product;
-   
-   zero = gen_reg_rtx (V4SImode);
-   emit_insn (gen_altivec_vspltisw (zero, const0_rtx));
- 
-   sixteen = gen_reg_rtx (V4SImode);   
-   emit_insn (gen_altivec_vspltisw (sixteen,  gen_rtx_CONST_INT (V4SImode, 
-16)));
- 
-   swap = gen_reg_rtx (V4SImode);
-   emit_insn (gen_altivec_vrlw (swap, operands[2], sixteen));
- 
-   one = gen_reg_rtx (V8HImode);
-   convert_move (one, operands[1], 0);
- 
-   two = gen_reg_rtx (V8HImode);
-   convert_move (two, operands[2], 0);
- 
-   small_swap = gen_reg_rtx (V8HImode);
-   convert_move (small_swap, swap, 0);
- 
-   low_product = gen_reg_rtx (V4SImode);
-   emit_insn (gen_altivec_vmulouh (low_product, one, two));
- 
-   high_product = gen_reg_rtx (V4SImode);
-   emit_insn (gen_altivec_vmsumuhm (high_product, one, small_swap, zero));
- 
-   emit_insn (gen_altivec_vslw (high_product, high_product, sixteen));
- 
-   emit_insn (gen_addv4si3 (operands[0], high_product, low_product));
-   
-   DONE;
- }")
- 
 
 ;; Fused multiply subtract 
 (define_insn "altivec_vnmsubfp"
@@ -644,38 +597,6 @@
   "vmsummm %0,%1,%2,%3"
   [(set_attr "type" "veccomplex")])
 
-(define_insn "altivec_vmsumshm"
-  [(set (match_operand:V4SI 0 "register_operand" "=v")
-(unspec:V4SI [(match_operand:V8HI 1 "register_operand" "v")
- (match_operand:V8HI 2 "register_operand" "v")
-  (match_operand:V4SI 3 "register_operand" "v")]
-UNSPEC_VMS

Re: WARNING bootstrapping GFortran on Cygwin

[Brian Dessent]

Angelo Graziosi wrote:

> configure: WARNING: fixed-point is not supported for this target
>^
> checking whether make sets $(MAKE)... yes
> ...
> 
> This warning was absent with the bootstrap I did 20070819 trunk-127626.

That's because this is a new feature that was just merged.  The specific
patch that added it seems to be
.

+AC_ARG_ENABLE(fixed-point,
+[  --enable-fixed-pointenable fixed-point arithmetic extension to
C],
+[
+],
+[
+  case $target in
+mips*-*-*)
+  enable_fixed_point=yes
+  ;;
+*)
+  AC_MSG_WARN(fixed-point is not supported for this target,
ignored)
+  enable_fixed_point=no
+  ;;
+  esac
+])

It does seem a bit spurious to AC_MSG_WARN on all non-supported targets,
even if the user didn't attempt any --enable-fixed-point, but you can at
least silence it with --disable-fixed-point.

> Should I 'tune' the build adding something in 'configure' ?

Pretty sure this requires hardware support, e.g. on a DSP. Not the kind
of thing they make configure switches for... :)

Brian

WARNING bootstrapping GFortran on Cygwin

[Angelo Graziosi]

With GFortran 4.3.0-20070821 trunk-127680 there is this warning:


[ -f stage_final ] || echo stage3 > stage_final
make[1]: Entering directory `/tmp/gcc/build'
make[2]: Entering directory `/tmp/gcc/build'
make[2]: Leaving directory `/tmp/gcc/build'
make[2]: Entering directory `/tmp/gcc/build'
Configuring stage 1 in ./intl
...
checking valgrind.h usability... no
checking valgrind.h presence... no
checking for valgrind.h... no
configure: WARNING: fixed-point is not supported for this target
   ^
checking whether make sets $(MAKE)... yes
...


This warning was absent with the bootstrap I did 20070819 trunk-127626.

Usually I use

${gcc_dir}/configure --prefix=${prefix_dir} \
 --exec-prefix=${prefix_dir} \
 --sysconfdir=${prefix_dir}/etc \
 --libdir=${prefix_dir}/lib \
 --libexecdir=${prefix_dir}/lib \
 --mandir=${prefix_dir}/share/man \
 --infodir=${prefix_dir}/share/info \
 --enable-languages=c,fortran \
 --enable-bootstrap \
 --enable-decimal-float=bid \
 --enable-libgomp \
 --enable-threads \
 --enable-sjlj-exceptions \
 --enable-version-specific-runtime-libs \
 --enable-nls \
 --enable-werror \
 --enable-checking=release \
 --disable-libmudflap \
 --disable-shared \
 --disable-win32-registry \
 --with-system-zlib \
 --without-included-gettext \
 --without-x

Should I 'tune' the build adding something in 'configure' ?



Thanks,

   Angelo.