Fwd: Re: Why is building a cross compiler "out-of-the-box" always broken?
(Stephen typoed the gcc address, forwarding) From: Segher Boessenkool <[EMAIL PROTECTED]> Date: 21 augustus 2007 17:10:30 GMT+02:00 To: "Stephen M. Kenton" <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Subject: Re: Why is building a cross compiler "out-of-the-box" always broken? I got 17 "minimal" compilers to build using your help. Upon closer examination I realized that you are not building glibc, which of course if fine for your application testing kernel builds. Half of my targets do not even support glibc :-) When I tried to use those compilers to configure glibc, it complained about needing unwind support. Presumably because of --enable-sjlj-exceptions. Most likely yes. I modified the gcc configure to allow --with-headers to point to the kernel headers and still set inhibit libc, What sets the inhibit_libc -- do you modify configure itself for that, or does some configure option do it? then I removed the --enable-sjlj-exceptions and it built about the same set of compilers as before. Glibc configure died for another reason after that, but that's a different issue. I really think that lumping kernel and libc headers together in the configure when deciding whether to set inhibit_libc is a mistake. It looks one should be independent of the other. Another problem is that GCC should provide some of those headers itself really; certainly the headers for the parts of C that it does implement itself. That's a long-standing issue though, is there any progress on it (or even a plan for fixing it)? Segher
Constant multidimensional array pointers inside a class
Hi,
The subject is quite a mouthful, so here is the gist of what I'm trying
to do:
class MyClass {
public:
MyClass(float *arr1D, const int width, const int comps)
: _arr3D((float (*)[width][comps])arr1D) {}
protected:
const float (*const _arr3D)[???][???];
};
The idea is to pass in a flattened pointer, pointing to a dynamically
allocated piece of memory, and convert it back to a multidimensionally
indexable array.
Herein lies the dilemma. In order to declare the pointer I need to
supply bounds information. However, in a dynamically allocated situation
this information can only come from outside the class. I can't see any
way to embed this constant pointer inside the class - however, it's
quite easy to assign it later in a non-const declaration.
Is this even possible in the language? The logical syntax would appear
to be:
protected:
const float (*const _arr3D)[][];
And to delay stride binding until the constructor is analysed. Intel
C/C++ goes some way towards this (GCC 4.1 fails on this statement
instantly) by allowing this program to compile. However, an error is
still flagged if any attempts to access the array are made.
--
Jay L. T. Cornwall
http://www.jcornwall.me.uk/
Implementing VMX128 AltiVec Variant
Hi, For those of you who don't know, VMX128 is a slightly modified version of VMX (AltiVec) in the Xenon processor (i.e. XBox 360). I'm trying to implement support for this in GCC. The principal difference that makes -maltivec not work is that some VMX instructions are missing. Namely, the following: vmuloub, vmulouh, vmulosb, vmulosh, vmuleub, vmuleuh, vmulesb, vmulesh, vsum4ubs, vsum4shs, vsum2sws, vsum4sbs, vsumsws, vmhaddshs, vmhraddshs, vmladduhm, vmsumubm, vmsummbm, vmsumuhm, vmsumuhs, vmsumshm, vmsumshs As a firs pass at this, I removed all references to these instructions from: gcc/config/rs6000/rs6000.c gcc/config/rs6000/altivec.h gcc/config/rs6000/altivec.md These are the only place I found references to them, apart from the files in the gcc/ada directory: gcc/ada/g-alveop.adb gcc/ada/g-alveop.ads gcc/ada/g-alleve.adb gcc/ada/g-alleve.ads I ignored these - I am making a rash assumption here that these are not too important for a C/C++ only build, but I'd like some confirmation on that. What are the above ada files for? 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? When I compile a test program with -maltivec and a loop that vectorizes, my .o files don't contain any of the non-existant instructions (listed above). However, once it is linked, the resulting binary does (including if it is a dynamically linked executable). Can anyone hazard a guess as to what is actually going on? Eventually, I would like to implement this as an option independent of -maltivec. Binutils already have a -mvmx128 flag, and I was planning to use the same flag. Other VMX128 changes include an addition of an extra 96 vector registers (for a total of 128), and possibly some extra functions, I'm not sure off the top of my head. But for a first pass, I'm hoping that just removing the non-existent instructions should work. I'm very new to GCC code (been using it for years, just never looked at the source). If somebody would be kind enough to help me out by pointing me in the right direction, it would be very much appreciated. Thanks in advance. Gordan
Re: Implementing VMX128 AltiVec Variant
Gordan Bobic <[EMAIL PROTECTED]> writes: > These are the only place I found references to them, apart from the > files in the gcc/ada directory: > > gcc/ada/g-alveop.adb > gcc/ada/g-alveop.ads > gcc/ada/g-alleve.adb > gcc/ada/g-alleve.ads > > I ignored these - I am making a rash assumption here that these are > not too important for a C/C++ only build, but I'd like some > confirmation on that. What are the above ada files for? I don't know what they are for, but I can confirm that they are irrelevant for a C/C++ build. > 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. Ian
Re: Implementing VMX128 AltiVec Variant
Ian Lance Taylor wrote: Gordan Bobic <[EMAIL PROTECTED]> writes: These are the only place I found references to them, apart from the files in the gcc/ada directory: gcc/ada/g-alveop.adb gcc/ada/g-alveop.ads gcc/ada/g-alleve.adb gcc/ada/g-alleve.ads I ignored these - I am making a rash assumption here that these are not too important for a C/C++ only build, but I'd like some confirmation on that. What are the above ada files for? I don't know what they are for, but I can confirm that they are irrelevant for a C/C++ build. Just out of interest, I only downloaded the core, gcc and g++ tar balls of the source. Why are the above ada files in there if they are irrelevant for a C/C++ only build? 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. Hmm, fair point. I'll have a re-check for this. I thought I weeded all those out, but I might have missed some. Thanks. Gordan
Re: Implementing VMX128 AltiVec Variant
Gordan Bobic <[EMAIL PROTECTED]> writes: > Just out of interest, I only downloaded the core, gcc and g++ tar > balls of the source. Why are the above ada files in there if they are > irrelevant for a C/C++ only build? I think the gcc tar ball actually includes everything. I think you just need the core and the g++ tarball. Ian
Re: Implementing VMX128 AltiVec Variant
On Aug 21, 2007, at 11:49 PM, Gordan Bobic wrote: These are the only place I found references to them, apart from the files in the gcc/ada directory: gcc/ada/g-alveop.adb gcc/ada/g-alveop.ads gcc/ada/g-alleve.adb gcc/ada/g-alleve.ads I ignored these - I am making a rash assumption here that these are not too important for a C/C++ only build, but I'd like some confirmation on that. What are the above ada files for? These are the Ada bindings to the altivec instructions. You can of course ignore this if you are not interested in Ada. Tristan.
recent troubles with float vectors & bitwise ops
Hello,
# cat vecop.cc
template T foo() {
T
a = { 0, 1, 2, 3 }, b = { 4, 5, 6, 7 },
c = a | b,
d = c & b,
e = d ^ b;
return e;
}
int main() {
typedef float v4sf_t __attribute__ ((__vector_size__ (16)));
typedef int v4si_t __attribute__ ((__vector_size__ (16)));
foo();
foo();
return 0;
}
# /usr/local/gcc-4.3-svn.old5/bin/g++ -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/usr/local/gcc-4.3-svn
--enable-languages=c,c++ --enable-threads=posix --disable-checking
--disable-nls --disable-shared --disable-win32-registry
--with-system-zlib --disable-multilib --verbose --with-gcc=gcc-4.2
--with-gnu-ld --with-gnu-as --enable-checking=none --disable-bootstrap
Thread model: posix
gcc version 4.3.0 20070808 (experimental)
# /usr/local/gcc-4.3-svn.old5/bin/g++ vecop.cc
# /usr/local/gcc-4.3-svn.old6/bin/g++ -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/usr/local/gcc-4.3-svn
--enable-languages=c,c++ --enable-threads=posix --disable-checking
--disable-nls --disable-shared --disable-win32-registry
--with-system-zlib --disable-multilib --verbose --with-gcc=gcc-4.2
--with-gnu-ld --with-gnu-as --enable-checking=none --disable-bootstrap
Thread model: posix
gcc version 4.3.0 20070819 (experimental)
# /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.
Re: recent troubles with float vectors & bitwise ops
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; }
Ian
Re: recent troubles with float vectors & bitwise ops
Ian Lance Taylor wrote: What does it mean to do a bitwise-or of a floating point value? Apparently enough for a small vendor like Intel to propose such things as orps, andps, andnps, and xorps. So, that's what i feared... it was intentional. And now i guess the only sanctioned access to those ops is via builtins/intrinsics. Great. If only i could get the same quality of code when using intrinsics to begin with...
Re: pragma-like warning turn off ?
Hi Ian, On 21 Aug 2007 21:19:07 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > "Sunzir Deepur" <[EMAIL PROTECTED]> writes: > > > is there a way to turn off warnings for selective lines ? > > No. can you please explain me the complexity of adding this feature ? if you'd to add it, how would you do that ? (maybe i will do that ?) thank you sunzir > > Sorry. > > Ian >
Re: pragma-like warning turn off ?
"Sunzir Deepur" <[EMAIL PROTECTED]> writes: > On 21 Aug 2007 21:19:07 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > > "Sunzir Deepur" <[EMAIL PROTECTED]> writes: > > > > > is there a way to turn off warnings for selective lines ? > > > > No. > > can you please explain me the complexity of adding this feature ? > if you'd to add it, how would you do that ? 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. There was some recent discussion of this on the gcc-patches mailing list. Look for __nowarn__. Ian
