Re: GNU/Linux ABI documentation ? GCC supports SSSE3 in general purpose code generation ?
"Darryl L. Miles" writes: > So my next question is what support is there in the various formats, > technologies and runtime libraries to provide a backwards compatible > solution, such that a binary from one system when put on another can > have any hardware incompatibilities detected at the soonest > opportunity, for example upon execution, soon after execution, during > DSO loading: Different architectures have adopted different approaches here. I believe the most common one is to record the required architecture in the e_flags field of the ELF header. ARM has adoped a more baroque solution involving a special attributes section. Either way, the linker combines this information such that the resulting executable is marked for the required architecture. The kernel or dynamic linker may then check the architecture, and give an error if the system does not support it. Unfortunately, as far as I know, no such solution was ever adopted for the x86 family. So this does not help your immediate problem, and will not help it until somebody implements such an approach for x86. > The next matter is has anyone done any studies on the performance > difference when enablement of newer instructions is possible for > "general purpose code generation". I'm not so interested in > specialized use cases such as codecs, compression, encryption, > graphics, etc... I consider these specialized use cases for which many > applications and libraries already have a workable solution by > "guarding" the execution of instructions that optimize such algorithms > by checking the CPU runtime support. I'm interested in the facts on > how much benefit regular code gets from this choice. I don't know of any studies, but it's clear that automatic vectorization using the SSE instructions can help a range of different programs. Ian
Re: struct tree_type
BLUE 3TOO writes: > Can somebody quickly explain what the bit fields are for? thanks > > unsigned int precision : 10; > unsigned no_force_blk_flag : 1; > unsigned needs_constructing_flag : 1; > unsigned transparent_aggr_flag : 1; > unsigned restrict_flag : 1; > unsigned contains_placeholder_bits : 2; > ENUM_BITFIELD(machine_mode) mode : 8; > unsigned string_flag : 1; > unsigned lang_flag_0 : 1; > unsigned lang_flag_1 : 1; > unsigned lang_flag_2 : 1; > unsigned lang_flag_3 : 1; > unsigned lang_flag_4 : 1; > unsigned lang_flag_5 : 1; > unsigned lang_flag_6 : 1; Look for the uses of the bitfields in the macros in tree.h, and look at the comments on those macros. Never refer to the fields directly; always use the macros. E.g., no_force_blk_flag is used in two macros, TYPE_NO_FORCE_BLK and TYPE_IS_SIZETYPE, and the comments explain when those macros are valid and what they mean. The lang_flag_N fields are used for frontend specific purposes, so for them you have to look at the individual frontends. Ian
Re: GCC Bugzilla is broken now
On 07/13/2010 11:13 AM, Jie Zhang wrote: I got this when trying to access http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44921 Software error: Can't rename data/versioncache.Xg5KN to versioncache at globals.pl line 306. For help, please send mail to the webmaster (sourcemas...@sourceware.org), giving this error message and the time and date of the error. It has recovered now. Thanks! -- Jie Zhang CodeSourcery
Re: GNU/Linux ABI documentation ? GCC supports SSSE3 in general purpose code generation ?
Ian Lance Taylor writes: > Unfortunately, as far as I know, no such solution was ever adopted for > the x86 family. So this does not help your immediate problem, and will > not help it until somebody implements such an approach for x86. The Sun assembler, linker, and runtime linker implement this, cf. http://docs.sun.com/app/docs/doc/819-0690/chapter7-28?l=en&a=view Hope this helps. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: Deprecating ARM FPA support (was: ARM Neon Tests Failing on non-Neon Target)
> However, although no one currently sells FPA hardware, it is widely > supported as the only floating point model emulated by the Linux > kernel, and people have to use it when compiling stuff to run on OABI > systems, which include boards currently on the market based on ARMv4 > (no t) such as the Balloon Board 2.0 as well as boards with more > recent CPUs where the manufacturer only supplies a LInux port for a > kernel version that predates EABI support such as the Armadillo range. Armv4 (not t) targets are supported by EABI targets via the --fix-v4bx option. You have to decide which you're targeting at static link time (v4t interworking for EABI compliance or armv4), but once you make that decision it should support everything the OABI port did. In theory you can use --fix-v4bx-interworking to generate armv4 binaries that are fully EABI compliant, however this comes at significant cost, and you eed to tweak a couple of the libgcc assembly routines. Paul
Re: GNU/Linux ABI documentation ? GCC supports SSSE3 in general purpose code generation ?
Rainer Orth writes: > Ian Lance Taylor writes: > >> Unfortunately, as far as I know, no such solution was ever adopted for >> the x86 family. So this does not help your immediate problem, and will >> not help it until somebody implements such an approach for x86. > > The Sun assembler, linker, and runtime linker implement this, cf. > > http://docs.sun.com/app/docs/doc/819-0690/chapter7-28?l=en&a=view > > Hope this helps. Sounds good to me. Anybody want to add this to the GNU tools? Ian
Re: How to pass a pathlist in RUNTESTFLAGS?
On 9 Jul 2010, at 17:28, Manuel López-Ibáñez wrote: RUNTESTFLAGS="CFLAGS_FOR_TARGET=--sysroot=/path/to/somewhere --target_board=unix/-foo/-bar" Please, once you find out, add this info to http://gcc.gnu.org/wiki/Testing_GCC done (and amended the sim. section to refer to the second simulator page), would you like to give it a "once over" in case I've missed a stylistic requirement? thanks Iain
GNU's inventation to PAGE
Good morning GNU, I'm launching a new network of indie game development called PAGE (the full name is not to be released until opening date), which will assist independent game developers gain clients and earn real profits (you will benefit even as a non profit organization), along with having access to any of the latest gamedev technology for PC, Mac, mobile platforms and game consoles (such as SDKs for the new Playstation Move and etc.). The release of this network should be around October or November of this year. If you have any interest in joining and/or contributing to this network, feel free to contact me. My regards, Tajiya Baba, Head Director of EYI Publications Company 2009-2010
Re: GNU/Linux ABI documentation ? GCC supports SSSE3 in general purpose code generation ?
On Tue, Jul 13, 2010 at 4:26 AM, Ian Lance Taylor wrote: > Rainer Orth writes: > >> Ian Lance Taylor writes: >> >>> Unfortunately, as far as I know, no such solution was ever adopted for >>> the x86 family. So this does not help your immediate problem, and will >>> not help it until somebody implements such an approach for x86. >> >> The Sun assembler, linker, and runtime linker implement this, cf. >> >> http://docs.sun.com/app/docs/doc/819-0690/chapter7-28?l=en&a=view >> >> Hope this helps. > > Sounds good to me. Anybody want to add this to the GNU tools? > Not very interesting to Linux. We don't use hardware capability filters. However, it is nice to mark a binary which ISAs it uses. But it should be specified in the psABI. -- H.J.
Re: GNU/Linux ABI documentation ? GCC supports SSSE3 in general purpose code generation ?
On Tue, Jul 13, 2010 at 6:39 AM, H.J. Lu wrote: > On Tue, Jul 13, 2010 at 4:26 AM, Ian Lance Taylor wrote: >> Rainer Orth writes: >> >>> Ian Lance Taylor writes: >>> Unfortunately, as far as I know, no such solution was ever adopted for the x86 family. So this does not help your immediate problem, and will not help it until somebody implements such an approach for x86. >>> >>> The Sun assembler, linker, and runtime linker implement this, cf. >>> >>> http://docs.sun.com/app/docs/doc/819-0690/chapter7-28?l=en&a=view >>> >>> Hope this helps. >> >> Sounds good to me. Anybody want to add this to the GNU tools? >> > > Not very interesting to Linux. We don't use hardware capability filters. > However, it is nice to mark a binary which ISAs it uses. But it should > be specified in the psABI. > On x86, it is OK for binary to have ISAs beyond the base ISA as long as proper ISA check is used before the new ISA code is entered. However, we should have a way to mark the base ISA. -- H.J.
Re: GNU/Linux ABI documentation ? GCC supports SSSE3 in general purpose code generation ?
"H.J. Lu" writes: > On x86, it is OK for binary to have ISAs beyond the base ISA > as long as proper ISA check is used before the new ISA code is > entered. However, we should have a way to mark the base ISA. That's what the Sun assembler does by default. If you need to override its findings if e.g. runtime checks are in place, you can do so with linker maps, see gcc.target/i386/clearcap.map for an example. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: Compilation time in gcc-4.4.0
On 07/08/2010 10:58 PM, Maxiwell Garcia wrote: Hi, I am writing a paper about instruction-set architecture simulators. In first time, I used gcc-4.4.0 and the compilation time reached 33 minutes (with -O3) for my simulator and the performance reached 270 MIPS (Million instruction per second). When I used the gcc-4.4.4, in the same code, the compilation time reached 39 seconds and the performance reached 600 MIPS. My code have many "switchs" with 512 "cases" and the library is in use. How to explain this behavior in the compilation and performance in my paper? Try -ftime-report, it should explain the compilation time change. Such a dramatic performance change is usually due to better register allocation, but this is just a guess. Paolo
Re: Compilation time in gcc-4.4.0
On Tue, Jul 13, 2010 at 4:50 PM, Paolo Bonzini wrote: > On 07/08/2010 10:58 PM, Maxiwell Garcia wrote: >> >> Hi, >> >> I am writing a paper about instruction-set architecture simulators. In >> first time, I used gcc-4.4.0 and the compilation time reached 33 >> minutes (with -O3) for my simulator and the performance reached 270 >> MIPS (Million instruction per second). When I used the gcc-4.4.4, in >> the same code, the compilation time reached 39 seconds and the >> performance reached 600 MIPS. My code have many "switchs" with 512 >> "cases" and the library is in use. >> How to explain this behavior in the compilation and performance in my >> paper? > > Try -ftime-report, it should explain the compilation time change. Such a > dramatic performance change is usually due to better register allocation, > but this is just a guess. I would guess it was the various backports of tree PRE fixes actually. Richard. > Paolo >
GTY variable_size & documentation
Hello, in the trunk's documentation
http://gcc.gnu.org/onlinedocs/gccint/GTY-Options.html I am reading:
> variable_size
> The type machinery expects the types to be of constant size.
> When this is not true, for example, with structs that have
> array fields or unions, the type machinery cannot tell how
> many bytes need to be allocated at each allocation. The
> variable_size is used to mark such types. The type machinery
> then provides allocators that take a parameter indicating an
> exact size of object being allocated.
>
> For example,
>
> struct GTY((variable_size)) sorted_fields_type {
> int len;
> tree GTY((length ("%h.len"))) elts[1];
> };
>
>
> Then the objects of struct sorted_fields_type are allocated in
> GC memory as follows:
>
> field_vec = ggc_alloc_sorted_fields_type (size);
I find the last paragraph and example very misleading, but perhaps I am not a
native english speaker and am understanding wrongly.
I would much prefer a sentence like
The type machinery then provides allocators that take a parameter indicating
an exact size of object being allocated (like malloc does)
and the exemple should better be
Then the objects of struct sorted_fields_type are allocated in GC memory as
follows, assuming n is the number of elements:
field_vec = ggc_alloc_sorted_fields_type (sizeof(sorted_fields_type) +
(n-1) * sizeof(tree));
The factor is n-1 (not n) since the struct sorted_fields_type is declared with
an array elts[1]
By the way, I would very much like that GCC code would assume that
variable-sized struct-ures are permitted, and declare instead
struct GTY((variable_size)) sorted_fields_type {
int len;
tree GTY((length ("%h.len"))) elts[];
};
Perhaps such a transition is needed, or at least very useful, even before any
transition to C++ ?
Cheers.
P.S. I am not yet proposing a gty.texi patch, because I have still a one-line
patch to it awaiting approval
http://gcc.gnu.org//ml/gcc-patches/2010-07/msg00744.html and I usually don't
work on patching files for which I have patches awaiting review.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: How to pass a pathlist in RUNTESTFLAGS?
On 13 July 2010 14:47, IainS wrote: > > On 9 Jul 2010, at 17:28, Manuel López-Ibáñez wrote: > >>> RUNTESTFLAGS="CFLAGS_FOR_TARGET=--sysroot=/path/to/somewhere >>> --target_board=unix/-foo/-bar" >>> >> >> Please, once you find out, add this info to >> http://gcc.gnu.org/wiki/Testing_GCC > > done (and amended the sim. section to refer to the second simulator page), > would you like to give it a "once over" in case I've missed a stylistic > requirement? Many thanks! There are no stylistic requirements, apart from make it pretty and understandable. You do not need the full URL for wiki links, just use [[WikiPage]]. Fixed thusly. Cheers, Manuel.
Re: GNU/Linux ABI documentation ? GCC supports SSSE3 in general purpose code generation ?
> Ian Lance Taylor writes: > > Unfortunately, as far as I know, no such solution was ever adopted for > > the x86 family. So this does not help your immediate problem, and will > > not help it until somebody implements such an approach for x86. > > The Sun assembler, linker, and runtime linker implement this, cf. > > http://docs.sun.com/app/docs/doc/819-0690/chapter7-28?l=en&a=view > > Hope this helps. Better IMO would be to implement GNU object attributes. The assembler and linker already have all the framework for these, you just need to define an appropriate set of attributes. Their design is based on the ARM EABI object attributes, which provide a more complete example of how they can be used. While a simple bitmask may be sufficient for the runtime linker, it's often useful to have a more flexible system for relocatable objects. Paul
Re: struct tree_type
On 13 July 2010 11:09, Ian Lance Taylor wrote: > BLUE 3TOO writes: > >> Can somebody quickly explain what the bit fields are for? thanks >> >> unsigned int precision : 10; >> unsigned no_force_blk_flag : 1; >> unsigned needs_constructing_flag : 1; >> unsigned transparent_aggr_flag : 1; >> unsigned restrict_flag : 1; >> unsigned contains_placeholder_bits : 2; >> ENUM_BITFIELD(machine_mode) mode : 8; >> unsigned string_flag : 1; >> unsigned lang_flag_0 : 1; >> unsigned lang_flag_1 : 1; >> unsigned lang_flag_2 : 1; >> unsigned lang_flag_3 : 1; >> unsigned lang_flag_4 : 1; >> unsigned lang_flag_5 : 1; >> unsigned lang_flag_6 : 1; > > Look for the uses of the bitfields in the macros in tree.h, and look at > the comments on those macros. Never refer to the fields directly; > always use the macros. > > E.g., no_force_blk_flag is used in two macros, TYPE_NO_FORCE_BLK and > TYPE_IS_SIZETYPE, and the comments explain when those macros are valid > and what they mean. > > The lang_flag_N fields are used for frontend specific purposes, so for > them you have to look at the individual frontends. Blue_3too, an improvement would be to submit a patch adding the above explanation as comments before the bitfields (where you would have expected to find such explanation). Such a small patch does not require copyright assignment, just send it to gcc-patches with a changelog. Cheers, Manuel.
Re: Compilation time in gcc-4.4.0
On 07/13/2010 04:53 PM, Richard Guenther wrote: On Tue, Jul 13, 2010 at 4:50 PM, Paolo Bonzini wrote: On 07/08/2010 10:58 PM, Maxiwell Garcia wrote: Hi, I am writing a paper about instruction-set architecture simulators. In first time, I used gcc-4.4.0 and the compilation time reached 33 minutes (with -O3) for my simulator and the performance reached 270 MIPS (Million instruction per second). When I used the gcc-4.4.4, in the same code, the compilation time reached 39 seconds and the performance reached 600 MIPS. My code have many "switchs" with 512 "cases" and the libraryis in use. How to explain this behavior in the compilation and performance in my paper? Try -ftime-report, it should explain the compilation time change. Such a dramatic performance change is usually due to better register allocation, but this is just a guess. I would guess it was the various backports of tree PRE fixes actually. Sorry, I was referring to the change in performance which I justified by better register allocation. PRE is indeed a good candidate for the compilation time fixes. Paolo
Re: Compilation time in gcc-4.4.0
On 07/13/2010 04:53 PM, Richard Guenther wrote: On Tue, Jul 13, 2010 at 4:50 PM, Paolo Bonzini wrote: On 07/08/2010 10:58 PM, Maxiwell Garcia wrote: Hi, I am writing a paper about instruction-set architecture simulators. In first time, I used gcc-4.4.0 and the compilation time reached 33 minutes (with -O3) for my simulator and the performance reached 270 MIPS (Million instruction per second). When I used the gcc-4.4.4, in the same code, the compilation time reached 39 seconds and the performance reached 600 MIPS. My code have many "switchs" with 512 "cases" and the libraryis in use. How to explain this behavior in the compilation and performance in my paper? Try -ftime-report, it should explain the compilation time change. Such a dramatic performance change is usually due to better register allocation, but this is just a guess. I would guess it was the various backports of tree PRE fixes actually. Sorry, I was referring to the change in performance which I justified by better register allocation. PRE is indeed a good candidate for the compilation time fixes. Could the changes to PRE cause different code to be generated? Paolo
Re: Compilation time in gcc-4.4.0
On Tue, Jul 13, 2010 at 5:26 PM, Paolo Bonzini wrote: > On 07/13/2010 04:53 PM, Richard Guenther wrote: >> >> On Tue, Jul 13, 2010 at 4:50 PM, Paolo Bonzini wrote: >>> >>> On 07/08/2010 10:58 PM, Maxiwell Garcia wrote: Hi, I am writing a paper about instruction-set architecture simulators. In first time, I used gcc-4.4.0 and the compilation time reached 33 minutes (with -O3) for my simulator and the performance reached 270 MIPS (Million instruction per second). When I used the gcc-4.4.4, in the same code, the compilation time reached 39 seconds and the performance reached 600 MIPS. My code have many "switchs" with 512 "cases" and the library is in use. How to explain this behavior in the compilation and performance in my paper? >>> >>> Try -ftime-report, it should explain the compilation time change. Such a >>> dramatic performance change is usually due to better register allocation, >>> but this is just a guess. >> >> I would guess it was the various backports of tree PRE fixes actually. > > Sorry, I was referring to the change in performance which I justified by > better register allocation. PRE is indeed a good candidate for the > compilation time fixes. Could the changes to PRE cause different code to be > generated? Yes, they will generally cause more PRE to be performed. What ends up generating the noticeable performance difference depends on the specific testcase though - and it might very well be RA (and 4.4.0 to 4.4.4 is a significant amount of changes). Richard. > Paolo >
gcc-4.4-20100713 is now available
Snapshot gcc-4.4-20100713 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20100713/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch revision 162159 You'll find: gcc-4.4-20100713.tar.bz2 Complete GCC (includes all of below) gcc-core-4.4-20100713.tar.bz2 C front end and core compiler gcc-ada-4.4-20100713.tar.bz2 Ada front end and runtime gcc-fortran-4.4-20100713.tar.bz2 Fortran front end and runtime gcc-g++-4.4-20100713.tar.bz2 C++ front end and runtime gcc-java-4.4-20100713.tar.bz2 Java front end and runtime gcc-objc-4.4-20100713.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.4-20100713.tar.bz2The GCC testsuite Diffs from 4.4-20100706 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 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: m4 requirement (was: prerequisites page)
On Jul 10, 2010, at 7:07 PM, Gerald Pfeifer wrote: > Todd, > > On Wed, 19 May 2010, Todd Rinaldo wrote: >> I'm writing to report a discrepancy in >> http://gcc.gnu.org/install/prerequisites.html >> >> I just discovered that if gmp is boot strapped during gcc build and an >> older m4 exists, when gmp calls flex, it will fail during configure >> with: >> >> checking for flex... flex >> checking lex output file root... configure: error: cannot find output from >> flex; giving up >> >> I mention this because the prerequisites page specifies m4 as optional >> if you're just building gcc. m4 appears to have a minimal requirement if >> gmp is being boot strapped. > > thanks for the report, Todd. You mention m4, yet the output you show > is around flex? > > I can update our documentation, but need more details and confirmation > by the respective GCC maintainers on what exactly to adjust. > Gerald, thanks for the reply. When it fell over, I dug into the config.log file and was able to determine that it was a bad m4 macro. I can try to re-produce it to get you more details, but it may take me a while to get to it. Do you want me to do this? Thanks, Todd
Re: m4 requirement
I think I've seen this one, it's something like this: GNU flex calls M4 when you run flex. GMP disables M4 and runs flex; flex then tries to run m4-not-used (or whatever it's called) instead of m4.
Ask for copyright assignment forms for gcc
Hello, It will be appreciated if anyone could help send me the copyright assignment forms. I need them to submit patches to gcc. I think it should be an assignment for all future changes. Thanks Eric
Re: GTY variable_size & documentation
Hi,
2010/7/13 Basile Starynkevitch :
> The type machinery then provides allocators that take a parameter indicating
> an exact size of object being allocated (like malloc does)
>
> and the exemple should better be
>
>
> Then the objects of struct sorted_fields_type are allocated in GC memory as
> follows, assuming n is the number of elements:
>
> field_vec = ggc_alloc_sorted_fields_type (sizeof(sorted_fields_type)
> + (n-1) * sizeof(tree));
I agree that these two changes would be an improvement.
> By the way, I would very much like that GCC code would assume that
> variable-sized struct-ures are permitted, and declare instead
> struct GTY((variable_size)) sorted_fields_type {
> int len;
> tree GTY((length ("%h.len"))) elts[];
> };
>
> Perhaps such a transition is needed, or at least very useful, even before any
> transition to C++ ?
Flexible array member is a C99 feature, IIRC GCC sources require C90.
Cheers,
--
Laurynas
