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'
Conf
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 becaus
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 lo
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 el
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
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?
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 b
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 'op
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()
{
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 'flo
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 :
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;
>
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
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 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
>
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 wou
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
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
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-bi
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 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
> + ;;
> + m
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.
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 b
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 i
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
> 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* ?
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'
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 s
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 ins
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
+
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 instructio
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 "vec
32 matches
Mail list logo
