Re: Summer of Code project discussion
[EMAIL PROTECTED] (Mark Mitchell) wrote on 03.05.06 in <[EMAIL PROTECTED]>: > To make this work, we have to be careful not to generate as much garbage > as we presently do, as we'll needlessly waste space in these pools. > Right now, we're using GC partly to compensate for things like using > trees to represent strictly temporary data. You can always include the option for temporary pools, which you throw away after the temporary trees are no longer used - if you can make sure you know that. You probably need to give pool arguments to a number of functions, anyway. MfG Kai
Re: Strange ACATS fails in acats.log
> > I'm experiencing ACATS failures that manifest in > > splitting > /abuild/rguenther/obj4/gcc/testsuite/ada/acats/tests/a/ada101a.ada into: >ada101a.adb > BUILD > FAIL: ada101a > BUILD > FAIL: c760009 > splitting > /abuild/rguenther/obj4/gcc/testsuite/ada/acats/tests/cd/cd2a22i.ada into: >cd2a22i.adb > BUILD > FAIL: cd2a22i > > to appear in the logs, but nothing else. What's this about? Can we make Apparenlty your compiler isn't working properly (just a guess). > the log a little more verbose here please? You could run the test with sh -x to get more info. Arno
Dsp-C / Embedded-C
Hi, i am looking for a way to support fixedpoint operations in gcc in order to produce efficient code for a dsp core. The only obvious solution i am aware of would be to add support for a language extension like DSP-C (www.dsp-c.org) or Embedded-C (www.embedded-c.org) to the compiler. Is anybody doing any work on supporting this in gcc? Michael -- Michael Staudenmaier Freescale Halbleiter GmbH Munich/Germany
Re: Suggestion for GCC (C & C++) enhancement - static variable initialisation ordering
"Manfred von Willich" <[EMAIL PROTECTED]> writes: | | I'd encourage you to work up a solid proposal for ISO/ANSI and | | propose it there. | | Being a newbie, I'd appreciate contact/site details for submissions to the | ISO/ANSI standardisation forum (do I email [EMAIL PROTECTED]). http://www.open-std.org/JTC1/SC22/WG21/ -- Gaby
V/S to GCC/G77 fortran conversion
Dear GCC community We have several fortran programs developed under MS' Visual Studio and would like to convert them to be GCC/G77 compatible. Short of converting the programs manaully, is anyone aware of a conversion package capable of doing the conversion automagically? Thank you in advance Attila _ Mutsuura Associates, Inc. /\ \ Vienna, VA 22181 / \ \ / /\ \ \ / / /\ \ \ E-MAIL: [EMAIL PROTECTED] / /_/ \ \ \ WEB: http://www.mutsuura.com / \ \ / \ \ / /\ \ \/ /\ \ \ MAIN:(703)281-9722 / / /\ \/ / /\ \ \ CELL:(703)863-1933/ / / \ / / \ \ \ FAX :(703)281-9744 / / /\/_/\ \_\ SBA/SDB CERTIFIED\/_/ \/_/
[RFC] IL cleanups
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The topic of our internal data structures comes up every so often and it will become particularly important now that we are planning to add link-time and dynamic optimizations to GCC. I would like to get started on some initial cleanups that should help when time comes to either stream GIMPLE (or some other variant) out to disk or when combining multiple compilation units for interprocedural optimizations. The common thread to these cleanups is going to be memory savings, and to a certain extent compile time improvements. I'm not looking for any new optimization opportunities nor improved analyses. Well, there is one additional feature that I would like to shoot for: the ability to save GIMPLE out and read it back in at an arbitrary point in the compilation phase. 1- Memory SSA The virtual SSA representation is very bloated, particularly in the presence of imprecise alias information. This work attempts to compact that information without risking precision. This is currently underway and expected to be integrated by the next stage 1. More details at http://gcc.gnu.org/ml/gcc/2006-02/msg00620.html 2- GIMPLE tuples New data structures for representing GIMPLE statements. The current IL uses a central data structure called 'tree'. Every IL node has this type, which results in nodes with unused fields. The basic idea is to analyze the tree codes used in GIMPLE and create smaller data structures to represent them. This will require some exploratory work and details are a bit vague, but some early discussion and implementation strategies were discussed in http://gcc.gnu.org/ml/gcc/2006-02/msg00622.html. * Create a basic 1 or 2 word structure that's basically a code and some bitfields. GIMPLE statements and expressions inherit from this structure. * Introduce the notion of GIMPLE statements and GIMPLE expressions. Each has attributes that the other does not need. A statement will have location information and no type, while an expression will have type and no location information. * GIMPLE statements have an array of operands, location info (including basic block) and an ID. Each operand will be a GIMPLE expression. * GIMPLE expressions have 0 or more operands and a type. SSA names are GIMPLE expressions with 0 operands. * Convert compiler temporaries into smaller DECLs and/or emit them directly as SSA names or just indices into a temporary table. (http://gcc.gnu.org/ml/gcc/2005-12/msg00632.html, http://gcc.gnu.org/ml/gcc/2006-01/msg00510.html) * Move annotations to hash tables or make them part of the IL structures. I presume that this activity may take a good 8-12 weeks (assuming 40-45 hour weeks). I will dedicate some of my development time to this, though my main focus for now is going to be mem-ssa. I will create a branch in the next few days to host this work. Or perhaps mem-ssa could be used for this, I'm still not sure. I'd appreciate thoughts/ideas in this area, and code, of course. 3- Remove on-the-side data structures A key property of a streamable IL is to be able to recover full compilation state from an isolated file. This means that the IL must have all the information required to create final code out of it. We currently keep some on-the-side data structures and/or global variables that are created at various points starting at the parser. A litmus test for this would be a pass that can read a program in GIMPLE form from a file and compile it to completion. This will force us to commit to a completely explicit representation: variables, types, exception handling, etc. It's not clear yet whether we will want to make GIMPLE itself streamable for the purposes of optimization. Perhaps we will end up using some other variant like the GVM bytecodes proposed in LTO or convert into the bytecodes used by LLVM. But I think it should be useful if we could read/write GIMPLE for developing test cases and general debugging of the compiler itself. Anything else I may have missed? There are other related activities, like keeping the whole callgraph in SSA form that may also benefit from these cleanups. All these cleanups could be either hosted on the same branch, or done in separate branches. However, I think concentrating the work on a single branch may allow better integration and memory savings testing. Thanks. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEWeulUTa2oAUaiwQRAidEAJ9Zwrku7cHBy/hqiz96rNFiBEH2agCfRajf L2YfHlJBHjCzoix4gWQhV0Q= =9Swx -END PGP SIGNATURE-
Re: Dynamically generated code and DWARF exception handling
Andrew Haley a écrit : Richard Henderson writes: > On Tue, May 02, 2006 at 01:23:56PM +0200, jacob navia wrote: > > Is there an equivalent API for linux? > > __register_frame_info_bases / __deregister_frame_info_bases. Are these an exported API? I metioned the existence of these entry points in a reply to Jacob on March 10. Jacob, did you investigate this? Andrew. Well, I searched for those and found some usage examples in the source of Apple Darwin gcc code for the startup. But then... is that current? I have googled around but I find only small pieces of information that may or may not apply to AMD64. ALL of this is extremely confusing and I am getting scared really. This stuff costed me 2 weeks hard work under windows, but somehow I had there an API that I could call. Under linux the stuff is still as complex as in windows (DWARF info generation is not easy) but what scares me is that there is NO API, no standard way of doing this. I have downloaded gcc 4.1 and will try to figure out where in the source I find those functions or where in the binutils source those functions could be hidden. Then, I will try to figure out from the source what they are doing and what they expect. As far as I know, there is no AMD64 specific docs, just ITANIUM docs that *could* be used for AMD64 but nobody knows for sure if those docs apply or they are just obsolete. What a mess people. I am getting wet pants... jacob
Re: [RFC] IL cleanups
* Introduce the notion of GIMPLE statements and GIMPLE expressions. Each has attributes that the other does not need. A statement will have location information and no type, while an expression will have type and no location information. Expressions need locations too for proper debugging information.
Re: Dynamically generated code and DWARF exception handling
Richard Henderson writes: > On Tue, May 02, 2006 at 01:23:56PM +0200, jacob navia wrote: > > Is there an equivalent API for linux? > > __register_frame_info_bases / __deregister_frame_info_bases. Are these an exported API? I metioned the existence of these entry points in a reply to Jacob on March 10. Jacob, did you investigate this? Andrew.
Re: Dynamically generated code and DWARF exception handling
jacob navia writes: > Andrew Haley a écrit : > > >Richard Henderson writes: > > > On Tue, May 02, 2006 at 01:23:56PM +0200, jacob navia wrote: > > > > Is there an equivalent API for linux? > > > > > > __register_frame_info_bases / __deregister_frame_info_bases. > > > >Are these an exported API? > > > >I metioned the existence of these entry points in a reply to Jacob on > >March 10. Jacob, did you investigate this? > Well, I searched for those and found some usage examples in the > source of Apple Darwin gcc code for the startup. But then... is > that current? I have no idea. Didn't you look at the source code for these functions? > I have googled around but I find only small pieces of information > that may or may not apply to AMD64. ALL of this is extremely > confusing and I am getting scared really. This stuff costed me 2 > weeks hard work under windows, but somehow I had there an API that > I could call. Under linux the stuff is still as complex as in > windows (DWARF info generation is not easy) but what scares me is > that there is NO API, no standard way of doing this. Well, there's not point us trying to help you if you aren't prepared to try yourself. It's up to you. > I have downloaded gcc 4.1 and will try to figure out where in the source > I find those functions or where in the binutils source those functions > could be hidden. gcc/unwind-dw2-fde-glibc.c. Andrew.
Re: [RFC] IL cleanups
Hi, nice that you are going to look into it. I am quite interested to help here as you can probably guess ;) The overall plan looks good to me. (and is pretty compatible with what I believe is needed) There are a lots of details however > > > Anything else I may have missed? There are other related activities, > like keeping the whole callgraph in SSA form that may also benefit from > these cleanups. All these cleanups could be either hosted on the same > branch, or done in separate branches. However, I think concentrating > the work on a single branch may allow better integration and memory > savings testing. If you are interested in some sort of integration of changes in IPA branch (IE whole program in SSA form), I can probably prepare sort of merge patches for review (pretty much as I intend to finally do in next development cycle). It would be nice to have this in mind when designing datastructures so we won't end up with sollution having limitations of SSA to single function body (for example in current implementation the variable annotations are quite an offenders as they are shared across functions for static variables but contain function local datastructures). I did some testing of memory consumption for my gccsummit paper and it looks like (quite suprisingly I would say) current IPA branch is not noticeably worse in memory consumption than mainline (ie the conversion to SSA and early optimizations don't expand IL too much). I don't however build the aliasing info, just do the SSA before first alias pass. I am not sure whether we want to build SSA representation of aliasing for whole program (mem-SSA or not) is good idea. Perhaps just making aliaisng aware early local pass, then removing the virutal operands and rebuilding aliasing in late pass is easier way to go, but with proper design of datastructures I guess it won't be dificult to experiment with it later. Honza > > > Thanks. > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.3 (GNU/Linux) > > iD8DBQFEWeulUTa2oAUaiwQRAidEAJ9Zwrku7cHBy/hqiz96rNFiBEH2agCfRajf > L2YfHlJBHjCzoix4gWQhV0Q= > =9Swx > -END PGP SIGNATURE-
Re: Multiple calls to __gcov_init
> On Tue, Apr 25, 2006 at 03:05:26PM +0200, Richard Guenther wrote:
> > On 4/25/06, Momchil Velikov <[EMAIL PROTECTED]> wrote:
> > > Why does GCC emit multiple calls to __gcov_init, via mulitple (two)
> > > entries in
> > > the ctors table? For example "int foo () { return 0; }" compiled with
> > > "gcc -S
> > > -fprofile-generate" produces the following assembly file, where the
> > > ".ctors"
> > > section conrtains two entries.
> >
> > -funit-at-a-time fixes it. But who uses -fprofile-generate with -O0
> > these days...
>
> gcov is used for coverage testing, and these are best run at -O0.
coverage should be equivalent at -O0 and other levels now when profiling
is done early. I will try to look into how we end up with two inits.
(It would be however good idea to open the bug for it and assign it to
me so it won't get forgotten)
Honza
Re: Status of SEE and Autovectorization patches?
The patches for SEE have been committed today. The minor style corrections requested by you in the final review approval will be in a follow-up patch to be submitted the next week. Mircea
Optimizations for the MIPS target
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there i have a few questions on the optimizations for the MIPS target, mostly regarding load/store instructions. 1. In the code generated for global symbols (e.g. arrays), the alignment is always at 4-byte boundary and not at 1-byte boundary (.align 0). E.g.: .align 2 some_array: .byte some_integer ... My question here is: culdn't "-Os" optimization option force .align 0 alignment? Is there any way to use the minimal data memory requirements for global symbols possible? 2. The MIPS backend prefers to emit the lw,sw instructions for -O3. lb,lbu etc.. are only used by the -Os option. However, i'm not sure that there is a clear code size advantage for using these variants. What I mean is: shouldn't they be used always? thanks in advance Nikolaos Kavvadias -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEWgIjMPiy0tCWlz4RAoH/AKCASVPXXY+wWTXz4DvnGWkSCXv0KACfTB+L fwLA06gCR+lUOb78huUeGPw= =e1rk -END PGP SIGNATURE-
Re: Dsp-C / Embedded-C
Michael Staudenmaier wrote: Hi, i am looking for a way to support fixedpoint operations in gcc in order to produce efficient code for a dsp core. The only obvious solution i am aware of would be to add support for a language extension like DSP-C (www.dsp-c.org) or Embedded-C (www.embedded-c.org) to the compiler. Is anybody doing any work on supporting this in gcc? There is of course a complete implementation in the Ada front end since this is a standard feature of Ada. It would be just fine to move this into the back end, but non-trivial! Michael -- Michael Staudenmaier Freescale Halbleiter GmbH Munich/Germany
Re: [RFC] IL cleanups
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jan Hubicka wrote on 05/04/06 08:36: > If you are interested in some sort of integration of changes in IPA > branch (IE whole program in SSA form), I can probably prepare sort of > merge patches for review (pretty much as I intend to finally do in next > development cycle). > Yeah, that'd be nice. Some of these changes are individually pretty substantial, so I wonder whether it'd be better to have them in separate branches to simplify integration. > It would be nice to have this in mind when designing datastructures so > we won't end up with sollution having limitations of SSA to single > function body (for example in current implementation the variable > annotations are quite an offenders as they are shared across functions > for static variables but contain function local datastructures). > Yes, another thing that I now see that is implicit with the removal of on-the-side data structures is the gradual removal of language hooks, or the inclusion of enough original language information to recover from a stream. > I did some testing of memory consumption for my gccsummit paper and it > looks like (quite suprisingly I would say) current IPA branch is not > noticeably worse in memory consumption than mainline (ie the conversion > to SSA and early optimizations don't expand IL too much). > Nice. Looking forward to this. > I don't however build the aliasing info, just do the SSA before first > alias pass. I am not sure whether we want to build SSA representation > of aliasing for whole program (mem-SSA or not) is good idea. Perhaps > just making aliaisng aware early local pass, then removing the virutal > operands and rebuilding aliasing in late pass is easier way to go, but > with proper design of datastructures I guess it won't be dificult to > experiment with it later. > Is it because of all the virtual operands? Or is the information hard to keep for multiple functions? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEWgNjUTa2oAUaiwQRAt3VAJ40n4uTok2563PvLYTSJbrcqF1tCQCePGRA ZtjZOQrRz8AiUPwR5WtsVBw= =f50m -END PGP SIGNATURE-
'official' f2c - where to find?
All I searched online but can't seem to find an 'official' source for 'f2c' converter. Does anyone know a/the website where I can find it? Thx in advance Attila _ Mutsuura Associates, Inc. /\ \ Vienna, VA 22181 / \ \ / /\ \ \ / / /\ \ \ E-MAIL: [EMAIL PROTECTED] / /_/ \ \ \ WEB: http://www.mutsuura.com / \ \ / \ \ / /\ \ \/ /\ \ \ MAIN:(703)281-9722 / / /\ \/ / /\ \ \ CELL:(703)863-1933/ / / \ / / \ \ \ FAX :(703)281-9744 / / /\/_/\ \_\ SBA/SDB CERTIFIED\/_/ \/_/
RE: V/S to GCC/G77 fortran conversion
->We have several fortran programs developed under MS' Visual Studio and ->would like to convert them to be GCC/G77 compatible. ->Short of converting the programs manaully, is anyone aware of a conversion ->package capable of doing the conversion automagically? if you are willing to move to the 3.X version of gcc, there is an excellent fortran compiler (g77) with many, many compiler options and features to run fortran-77 code from other compilers. with gcc-4.X, gfortran is available. gfortran is not as lenient about non-standard code, but has the advantage of supporting the modern language features. IMHO, f2c is a poor replacement for g77; i would use g77 in almost every situation dealing with old code. As far as hand modifying the code, it is in most cases very small syntactic differences that can be accomplished with a perl script or even spending a few minutes of time in the editor for each file. Although many will disagree, fortran code is very portable between dialects; once the compiler eats the code the results are usually as expected. HTH, bud davis
Re: [RFC] IL cleanups
> -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Jan Hubicka wrote on 05/04/06 08:36: > > > If you are interested in some sort of integration of changes in IPA > > branch (IE whole program in SSA form), I can probably prepare sort of > > merge patches for review (pretty much as I intend to finally do in next > > development cycle). > > > Yeah, that'd be nice. Some of these changes are individually pretty > substantial, so I wonder whether it'd be better to have them in separate > branches to simplify integration. I will definitly maintain the IPA branch till next release cycle so the changes can be integrated possibly earlier before the gimple reorganization converge to something. (honestly I have no idea how long this will take, but I take your promise of 12 weeks ;)) > > > It would be nice to have this in mind when designing datastructures so > > we won't end up with sollution having limitations of SSA to single > > function body (for example in current implementation the variable > > annotations are quite an offenders as they are shared across functions > > for static variables but contain function local datastructures). > > > Yes, another thing that I now see that is implicit with the removal of > on-the-side data structures is the gradual removal of language hooks, or > the inclusion of enough original language information to recover from a > stream. Yep, language hooks are going to be fun. > > > I did some testing of memory consumption for my gccsummit paper and it > > looks like (quite suprisingly I would say) current IPA branch is not > > noticeably worse in memory consumption than mainline (ie the conversion > > to SSA and early optimizations don't expand IL too much). > > > Nice. Looking forward to this. > > > I don't however build the aliasing info, just do the SSA before first > > alias pass. I am not sure whether we want to build SSA representation > > of aliasing for whole program (mem-SSA or not) is good idea. Perhaps > > just making aliaisng aware early local pass, then removing the virutal > > operands and rebuilding aliasing in late pass is easier way to go, but > > with proper design of datastructures I guess it won't be dificult to > > experiment with it later. > > > Is it because of all the virtual operands? Or is the information hard > to keep for multiple functions? Well, I would expect vops to be important portion of our memory footprint, but I don't have numbers for that (and I would expect that for example SSA_NAME shows on the list more than it actually did, so the guesses are not really good here). Anyway the main dificulty here is that for built aliasing info you need variable annotations and those are shared. Perhaps also keeping the info up to date during inlining might be bit tricky (for local variables inlining is really nice not inventing PHIs and such, but for statics this is more fun so I guess we would end up marking them all for renaming anyway). I am also not quite convinced how much the SSA form aliasing helps the IPA passes that are usually interested in rather straighforward analysis of function body, so aliasing don't seems to be top priority here. So I simply chosed to not mess with this for initial implementation. Honza > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.3 (GNU/Linux) > > iD8DBQFEWgNjUTa2oAUaiwQRAt3VAJ40n4uTok2563PvLYTSJbrcqF1tCQCePGRA > ZtjZOQrRz8AiUPwR5WtsVBw= > =f50m > -END PGP SIGNATURE-
Re: Status of SEE and Autovectorization patches?
On Thu, May 04, 2006 at 03:25:22PM +0200, Mircea Namolaru wrote:
> The patches for SEE have been committed today.
>
> The minor style corrections requested by you in the
> final review approval will be in a follow-up patch
> to be submitted the next week.
>
I didn't see you have addressed the issuses I raised in my previous
emails. When I used
export BOOT_CFLAGS="-g -O2 -fsee" CXXFLAGS="-g -O2 -fsee" FCFLAGS="-g -O2
-fsee" GCJFLAGS="-g -O2 -fsee" SYSROOT_CFLAGS_FOR_TARGET="-g -O2 -fsee"
# /configure
# make BOOT_CFLAGS="-g -O2 -fsee" CXXFLAGS="-g -O2 -fsee" FCFLAGS="-g -O2
-fsee" GCJFLAGS="-g -O2 -fsee" SYSROOT_CFLAGS_FOR_TARGET="-g -O2 -fsee"
to configure and build gcc on Linux/x86 and Linux/x86-64. They both
failed to bootstrap. There are at least 2 problems:
1. SEE uses NEXT_INSN/PREV_INSN to find adjacent insns. But with
-g, NEXT_INSN/PREV_INSN may point to a NOTE. So adjacent insns checks
with NEXT_INSN/PREV_INSN aren't sufficient.
2. Not all zero_extend patterns are available for x86/x86-64. For
example:
(insn 137 0 0 (set (reg:SI 60 [ prephitmp.115 ])
(zero_extend:SI (subreg:QI (reg:SI 60 [ prephitmp.115 ]) 0)))
-1 (nil)
(nil))
may not be used on x86/x86-64. i386.md has
(define_expand "zero_extendqisi2"
[(parallel
[(set (match_operand:SI 0 "register_operand" "")
(zero_extend:SI (match_operand:QI 1 "nonimmediate_operand" "")))
(clobber (reg:CC FLAGS_REG))])]
""
"")
This is case for all extensions for i386. For x86-64, only
zero_extendsidi2 won't clobber CC.
3. When the original insns were
set (dest_extension_reg1) (sign_extend (source_extension_reg1))
set (dest_extension_reg2) (sign_extend (dest_extension_reg1))
We created
ref: set (dest_extension_reg1) (sign_extend (source_extension_reg1))
def_se: set (dest_extension_reg2) (sign_extend (dest_extension_reg1))
and
use_se: set (dest_extension_reg1) (sign_extend (dest_extension_reg1))
ref: set (dest_extension_reg2) (sign_extend (dest_extension_reg1))
When def merge failed, def_se was deleted. Now use_se had a deleted
ref.
Basically, SEE doesn't handle
(set (reg/v:SI 70 [ j ])
(sign_extend:SI (subreg:HI (reg:SI 72 [ start ]) 0)))
(set (reg:DI 73 [ j ])
(sign_extend:DI (reg/v:SI 70 [ j ])))
correctly.
4. SEE also failed to handle
set (dest_extension_reg1) (zero_extend (source_extension_reg1))
set (reg) (..dest_extension_reg1..)
set (dest_extension_reg2) (sign_extend (source_extension_reg1))
(insn:HI 28 26 30 2 x.c:1201 (set (reg:DI 534 [ mode ])
(zero_extend:DI (reg/v:SI 264 [ mode ]))) 111
{zero_extendsidi2_rex64}
(insn_list:REG_DEP_TRUE 11 (nil))
(nil))
(insn:HI 30 28 269 2 x.c:1201 (set (reg:QI 261 [ D.24257 ])
(mem/s/u:QI (plus:DI (reg:DI 534 [ mode ])
(symbol_ref:DI ("mode_class") [flags 0x40] )) [0 mode_class S1 A8])) 55 {*movqi_1}
(insn_list:REG_DEP_TRUE 28 (nil))
(nil))
(insn:HI 269 30 270 2 x.c:1273 (set (reg:DI 546)
(sign_extend:DI (reg/v:SI 264 [ mode ]))) 115
{extendsidi2_rex64} (nil)
(nil))
If I don't use -fsee for bootstrap, I will get some extra "make check"
failures on Linux/x86-64 for -O3, which turns on SEE.
H.J.
Re: Dynamically generated code and DWARF exception handling
> "jacob" == jacob navia <[EMAIL PROTECTED]> writes: >> Unfortunately things are also worse for libgcj, in that we need to be >> able to generate stack traces as well, and the trampoline function >> approach won't work there. >> jacob> ? Sorry I do not follow here The java runtime needs to be able to examine the current stack and find out what methods (and map back to classes and then class loaders) are executing. So a little shim like I mentioned won't work, as the whole stack trace has to be created. >> Longer term, yeah, gcc's unwinder needs a JIT API, and then the >> various JITs need to be updated to use it. At least LLVM appears to >> be headed this direction. >> jacob> Very interesting but maybe you could be more specific? jacob> I browsed that "llvm" and seems a huge project, as libgcj is. To go jacob> through all that code to find how they implement this, will be jacob> extremely difficult. If you could give me some hints as to where is jacob> the needle in those haystacks I would be really thankful. Unfortunately this work hasn't started, at least not that I'm aware. So, it isn't in there yet, just planned. Tom
Re: Status of SEE and Autovectorization patches?
I thought that you or others at Intel were going to extend the SEE infrastructure to better support x86. The x86 port can turn off SEE in override_options or XFAIL the tests for x86 until that work is committed. David
Re: Status of SEE and Autovectorization patches?
On Thu, May 04, 2006 at 11:15:27AM -0400, David Edelsohn wrote: > I thought that you or others at Intel were going to extend the SEE > infrastructure to better support x86. The x86 port can turn off SEE in > override_options or XFAIL the tests for x86 until that work is committed. Some of the issues aren't specific to x86. Has anyone tried export BOOT_CFLAGS="-g -O2 -fsee" CXXFLAGS="-g -O2 -fsee" FCFLAGS="-g -O2 -fsee" GCJFLAGS="-g -O2 -fsee" SYSROOT_CFLAGS_FOR_TARGET="-g -O2 -fsee" # /configure # make BOOT_CFLAGS="-g -O2 -fsee" CXXFLAGS="-g -O2 -fsee" FCFLAGS="-g -O2 -fsee" GCJFLAGS="-g -O2 -fsee" SYSROOT_CFLAGS_FOR_TARGET="-g -O2 -fsee" on PPC/PPC64? H.J.
Re: [RFC] IL cleanups
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Richard Kenner wrote on 05/04/06 08:19: > * Introduce the notion of GIMPLE statements and GIMPLE > expressions. Each has attributes that the other does not need. A > statement will have location information and no type, while an > expression will have type and no location information. > > Expressions need locations too for proper debugging information. Yes, but when we map into GIMPLE, a multi-line, multi-expression statement will be converted into many GIMPLE statements, each one will carry the location info from the original statement adjusted with the line number of each expression (I'm hoping this can be carried from the FE into GIMPLE somewhat easily?). My thinking with this was that GIMPLE expressions don't need the location info because it will always be associated with the containing statement. Expressions in GIMPLE are always the RHS of an assignment, so we store the location to the assignment, not the expression. Or is this not feasible? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEWiA9UTa2oAUaiwQRAk0cAJ4uXc9sYs59BzA8f6rjER3N3fDK+ACfa1tT cpnS0js1hj1nlvb+3thxV90= =2n9c -END PGP SIGNATURE-
Re: Status of SEE and Autovectorization patches?
On May 4, 2006, at 8:37 AM, H. J. Lu wrote: On Thu, May 04, 2006 at 11:15:27AM -0400, David Edelsohn wrote: I thought that you or others at Intel were going to extend the SEE infrastructure to better support x86. The x86 port can turn off SEE in override_options or XFAIL the tests for x86 until that work is committed. Some of the issues aren't specific to x86. Has anyone tried Then again this is the first time I and others (reviewers) just heard about the bootstrap problem with turning on SEE. -- Pinski
Re: Status of SEE and Autovectorization patches?
On Thu, May 04, 2006 at 08:39:58AM -0700, Andrew Pinski wrote: > > On May 4, 2006, at 8:37 AM, H. J. Lu wrote: > > >On Thu, May 04, 2006 at 11:15:27AM -0400, David Edelsohn wrote: > >>I thought that you or others at Intel were going to extend the SEE > >>infrastructure to better support x86. The x86 port can turn off > >>SEE in > >>override_options or XFAIL the tests for x86 until that work is > >>committed. > > > >Some of the issues aren't specific to x86. Has anyone tried > > Then again this is the first time I and others (reviewers) just heard > about the > bootstrap problem with turning on SEE. I raised those issues to [EMAIL PROTECTED] and [EMAIL PROTECTED], CCed [EMAIL PROTECTED] H.J.
Re: 'official' f2c - where to find?
On Thu, May 04, 2006 at 09:45:31AM -0400, Attila Horvath wrote: > I searched online but can't seem to find an 'official' > source for 'f2c' converter. That program has nothing to do with gcc, so you are on the wrong list. But how hard did you search? Type "f2c" into Google and follow the top link.
Re: Optimizations for the MIPS target
On Thu, May 04, 2006 at 04:31:15PM +0300, Nikolaos Kavvadias wrote: > My question here is: culdn't "-Os" optimization option force .align 0 > alignment? Is there any way to use the minimal data memory > requirements for global symbols possible? While it could, I hope that it does not go so far as to make the reads unaligned (on processors that allow this). -Os currently optimizes well for speed as well as for space, and there's a substantial performance penalty for unaligned reads and writes in many cases.
Re: Optimizations for the MIPS target
Joe Buck wrote: On Thu, May 04, 2006 at 04:31:15PM +0300, Nikolaos Kavvadias wrote: My question here is: culdn't "-Os" optimization option force .align 0 alignment? Is there any way to use the minimal data memory requirements for global symbols possible? While it could, I hope that it does not go so far as to make the reads unaligned (on processors that allow this). -Os currently optimizes well for speed as well as for space, and there's a substantial performance penalty for unaligned reads and writes in many cases. IIRC, On mips they are trapped and emulated in the Linux/(your OS here) kernel. That means that literally hundreds of instructions are executed for each unaligned access. On systems where they are not emulated, you would get a hard failure. David Daney.
Re: Summer of Code project discussion
On Wed, 2006-05-03 at 20:35 -0700, Mark Mitchell wrote:
> Laurynas Biveinis wrote:
> > 2006/5/3, Daniel Berlin <[EMAIL PROTECTED]>:
> >
> >> The number of *host* systems we support that don't have mmap is
> >> approaching 0, if it is not there already :)
> >
> > Uhm, at least DJGPP as a GCC host system is alive and does not support
> > mmap. But according to the following discussion, that's non-issue.
>
> In the long run, I don't think we really want to be using garbage
> collection at all.
+1
> My opinion is, in the long run, memory pools really are what we want --
> just not as many as we used to have. In particular, we want one memory
> pool for global trees (global types, variables with static storage
> duration, functions), and one memory pool for the body of each function.
> References would be allowed from the body of each function to the
> global pool, but the other direction should be strictly limited to one
> pointer from each function to its body. (This allows you to read
> in/write out function bodies more easily.)
I've always been in favor of memory pools of this sort, with the
addition of subpools for memory intensive per-iteration sort of things.
IE we have something like
do_foo (apr_pool_t *pool)
{
apr_pool_t *subpool = apr_pool_create (pool);
for (i = 0; i < 1; i++)
{
apr_pool_clear (subpool);
garbage_intensive_thing (subpool);
}
}
The subpool are automatically destroyed when the parent pool dies, so we
rarely free them explicitly.
This is exactly what we do in subversion, and the only memory leaks we
ever have are where we needed a subpool but didn't have one.
usually owing to the fact that nobody realized something could need that
many iterations of a loop, call a function that many times, etc.
The thing that obstacks miss are this subpool notion.
BTW, for people looking for a good featureful implementation of pools,
take a look at the pools in APR (apache portable runtime). It supports
things like subpools, cleanup functions that can be called on pool
death, etc,
--Dan
Re: 'official' f2c - where to find?
Attila Horvath <[EMAIL PROTECTED]> asks on Thu, 04 May 2006 06:18:42 -0800 about the official site for the f2c Fortran-to-C converter. Try ftp://netlib.bell-labs.com/netlib/f2c/ I just reached it without problems. --- - Nelson H. F. BeebeTel: +1 801 581 5254 - - University of UtahFAX: +1 801 581 4148 - - Department of Mathematics, 110 LCBInternet e-mail: [EMAIL PROTECTED] - - 155 S 1400 E RM 233 [EMAIL PROTECTED] [EMAIL PROTECTED] - - Salt Lake City, UT 84112-0090, USAURL: http://www.math.utah.edu/~beebe/ - ---
Re: Optimizations for the MIPS target
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Daney wrote: > Joe Buck wrote: > >> On Thu, May 04, 2006 at 04:31:15PM +0300, Nikolaos Kavvadias >> wrote: >> >>> My question here is: culdn't "-Os" optimization option force >>> .align 0 alignment? Is there any way to use the minimal data >>> memory requirements for global symbols possible? >> >> >> >> While it could, I hope that it does not go so far as to make the >> reads unaligned (on processors that allow this). -Os currently >> optimizes well for speed as well as for space, and there's a >> substantial performance penalty for unaligned reads and writes in >> many cases. >> > > IIRC, On mips they are trapped and emulated in the Linux/(your OS > here) kernel. That means that literally hundreds of instructions > are executed for each unaligned access. > > On systems where they are not emulated, you would get a hard > failure. > > David Daney. That's reasonable. And the trap handling routines, being called really often in such case, incur a very high performance cost. In a hypothetical case of a processor, there could be provision for adjusting the unaligned (byte-wise) addresses to the intended alignment in hardware But that's probably unecessary complexity. Nikolaos Kavvadias -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEWixQMPiy0tCWlz4RApLtAKCQQzW9Sr/b8DuddBuBaNatK4jAfgCgiTl7 LNInrCdFNfMw1cODsgQvuUg= =7O4q -END PGP SIGNATURE-
Re: [RFC] IL cleanups
> "Diego" == Diego Novillo <[EMAIL PROTECTED]> writes: Diego> Yes, another thing that I now see that is implicit with the removal of Diego> on-the-side data structures is the gradual removal of language hooks, or Diego> the inclusion of enough original language information to recover from a Diego> stream. I've got a java-specific case or two that stress this idea a bit. Where should I file these? If you want to do jit stuff then there are a few other things to add to the to-do list: remove global variables, general namespace cleanliness improvements, back ends that go direct to memory... lots of work. Also some of the current global flags will have to be turned into bits on operations. I'm thinking of things like -fwrapv here. Tom
Re: Strange ACATS fails in acats.log
BUILD alone means that the sequence gnatchop x ls * > tmp main=`tail -1 tmp` echo "BUILD $main" got an empty tmp file. I see that from time to time, more on SMP/dual core machines, if you add sync or sleep it goes away but the run is slower. I've always assumed it's some kind of process/kernel/fs race condition (I don't see anything wrong in gnatchop code). Laurent On Thu, 2006-05-04 at 10:11 +0200, Arnaud Charlet wrote: > > > > I'm experiencing ACATS failures that manifest in > > > > splitting > > /abuild/rguenther/obj4/gcc/testsuite/ada/acats/tests/a/ada101a.ada into: > >ada101a.adb > > BUILD > > FAIL: ada101a > > BUILD > > FAIL: c760009 > > splitting > > /abuild/rguenther/obj4/gcc/testsuite/ada/acats/tests/cd/cd2a22i.ada into: > >cd2a22i.adb > > BUILD > > FAIL: cd2a22i > > > > to appear in the logs, but nothing else. What's this about? Can we make > > Apparenlty your compiler isn't working properly (just a guess). > > > the log a little more verbose here please? > > You could run the test with sh -x to get more info. > > Arno >
Re: Strange ACATS fails in acats.log
On Thu, 4 May 2006, Laurent GUERBY wrote: > BUILD alone means that the sequence > > gnatchop x > ls * > tmp > main=`tail -1 tmp` > echo "BUILD $main" > > got an empty tmp file. > > I see that from time to time, more on SMP/dual core machines, if you add > sync or sleep it goes away but the run is slower. I've always assumed > it's some kind of process/kernel/fs race condition (I don't see > anything wrong in gnatchop code). Yes, this happens repeatedly on a 4-way HT-Xeon machine. Maybe just skipping the test completely if $main is empty would at least avoid the spurious FAILs... Richard. -- Richard Guenther <[EMAIL PROTECTED]> Novell / SUSE Labs
Re: Dynamically generated code and DWARF exception handling
On Thu, May 04, 2006 at 12:49:03PM +0100, Andrew Haley wrote: > Are these an exported API? Inasmuch as we've got to support them forever for binary compatibility, I don't see why not. r~
Is this a gcc bug or invalid code?
Before I open a bug report, I will ask it here:
[EMAIL PROTECTED] tmp]$ cat foo.c
typedef struct A A;
A *a;
typedef struct A
{
int x;
} A;
[EMAIL PROTECTED] tmp]$ gcc -c foo.c
foo.c:7: error: redefinition of typedef 'A'
foo.c:1: error: previous declaration of 'A' was here
[EMAIL PROTECTED] tmp]$ g++ -c foo.c
[EMAIL PROTECTED] tmp]$ /opt/intel/cce/9.0/bin/icc -c foo.c
Is this a gcc bug or an icc extension?
H.J.
Re: Is this a gcc bug or invalid code?
>
> Before I open a bug report, I will ask it here:
>
> [EMAIL PROTECTED] tmp]$ cat foo.c
> typedef struct A A;
> A *a;
>
> typedef struct A
> {
> int x;
> } A;
> [EMAIL PROTECTED] tmp]$ gcc -c foo.c
> foo.c:7: error: redefinition of typedef 'A'
> foo.c:1: error: previous declaration of 'A' was here
> [EMAIL PROTECTED] tmp]$ g++ -c foo.c
> [EMAIL PROTECTED] tmp]$ /opt/intel/cce/9.0/bin/icc -c foo.c
>
> Is this a gcc bug or an icc extension?
Try in strict mode for ICC. With Comeau C compiler,
it rejects it with the similar error message.
-- Pinski
Re: Status of SEE and Autovectorization patches?
On Thu, May 04, 2006 at 08:26:52PM +0300, Leehod Baruch wrote:
> Please, lets be more precise.
> All the problem you have listed here are problems that relates x86.
> There is no problem on PPC and as far as I know there is no problem
> on other platforms (at least no one complained about it).
> *ALL* the problems you have mentioned appears only on x86 and most of
> them are a result of changes that we tried to do in order to make this
> optimization work better for Intel.
> Just a reminder, we concluded that this optimization in it's current state
> is not relevant for Intel and therefore all these changes/bugs are
> irrelevant now.
> As far as the committed patch there is no problem except one
> _minor_ correction that will be submitted in the follow-up patch.
>
> > On Thu, May 04, 2006 at 03:25:22PM +0200, Mircea Namolaru wrote:
> >> The patches for SEE have been committed today.
> >>
> >> The minor style corrections requested by you in the
> >> final review approval will be in a follow-up patch
> >> to be submitted the next week.
> >>
> >
> > I didn't see you have addressed the issuses I raised in my previous
> > emails. When I used
> >
> > export BOOT_CFLAGS="-g -O2 -fsee" CXXFLAGS="-g -O2 -fsee" FCFLAGS="-g -O2
> > -fsee" GCJFLAGS="-g -O2 -fsee" SYSROOT_CFLAGS_FOR_TARGET="-g -O2 -fsee"
> > # /configure
> > # make BOOT_CFLAGS="-g -O2 -fsee" CXXFLAGS="-g -O2 -fsee" FCFLAGS="-g -O2
> > -fsee" GCJFLAGS="-g -O2 -fsee" SYSROOT_CFLAGS_FOR_TARGET="-g -O2 -fsee"
> >
> > to configure and build gcc on Linux/x86 and Linux/x86-64. They both
> This is relevant for x86.
# export BOOT_CFLAGS="-g -O2 -fsee" CXXFLAGS="-g -O2 -fsee" FCFLAGS="-g -O2
-fsee" GCJFLAGS="-g -O2 -fsee" SYSROOT_CFLAGS_FOR_TARGET="-g -O2 -fsee"
# ./configure
# make BOOT_CFLAGS="-g -O2 -fsee" CXXFLAGS="-g -O2 -fsee" FCFLAGS="-g -O2
-fsee" GCJFLAGS="-g -O2 -fsee" SYSROOT_CFLAGS_FOR_TARGET="-g -O2 -fsee"
is applying SEE on gcc sources. Why is this only relevant for x86?
> > failed to bootstrap. There are at least 2 problems:
> >
> > 1. SEE uses NEXT_INSN/PREV_INSN to find adjacent insns. But with
> > -g, NEXT_INSN/PREV_INSN may point to a NOTE. So adjacent insns checks
> > with NEXT_INSN/PREV_INSN aren't sufficient.
> Only if we change the code to catch x86 patterns.
With -g, I may get
(note:HI 17 14 18 2
("/net/gnu-13/export/gnu/src/gcc-see/gcc/gcc/testsuite/gcc.c-torture/execute/20010224-1.c")
18)
(insn:HI 18 17 19 2
/net/gnu-13/export/gnu/src/gcc-see/gcc/gcc/testsuite/gcc.c-torture/execute/20010224-1.c:18
(set (reg/v:SI 70 [ j ])
(sign_extend:SI (subreg:HI (reg:SI 72 [ start ]) 0))) 118 {extendhisi2}
(insn_list:REG_DEP_TRUE 12 (nil))
(expr_list:REG_DEAD (reg:SI 72 [ start ])
(nil)))
(note:HI 19 18 20 2
("/net/gnu-13/export/gnu/src/gcc-see/gcc/gcc/testsuite/gcc.c-torture/execute/20010224-1.c")
19)
(insn:HI 20 19 22 2
/net/gnu-13/export/gnu/src/gcc-see/gcc/gcc/testsuite/gcc.c-torture/execute/20010224-1.c:19
(set (reg:DI 73 [ j ])
(sign_extend:DI (reg/v:SI 70 [ j ]))) 115 {extendsidi2_rex64}
(insn_list:REG_DEP_TRUE 18 (nil))
(nil))
Those notes may be added between insns because -g. NEXT_INSN/PREV_INSN
won't get you the adjacent insn in this case.
> > 2. Not all zero_extend patterns are available for x86/x86-64. For
> > example:
> >
> > (insn 137 0 0 (set (reg:SI 60 [ prephitmp.115 ])
> > (zero_extend:SI (subreg:QI (reg:SI 60 [ prephitmp.115 ]) 0)))
> > -1 (nil)
> > (nil))
> >
> > may not be used on x86/x86-64. i386.md has
> >
> > (define_expand "zero_extendqisi2"
> > [(parallel
> > [(set (match_operand:SI 0 "register_operand" "")
> >(zero_extend:SI (match_operand:QI 1 "nonimmediate_operand" "")))
> > (clobber (reg:CC FLAGS_REG))])]
> > ""
> > "")
> >
> > This is case for all extensions for i386. For x86-64, only
> > zero_extendsidi2 won't clobber CC.
> Again, for x86.
But SEE doesn't provide a way to deal with it.
> > 3. When the original insns were
> >
> > set (dest_extension_reg1) (sign_extend (source_extension_reg1))
> > set (dest_extension_reg2) (sign_extend (dest_extension_reg1))
> >
> > We created
> >
> > ref: set (dest_extension_reg1) (sign_extend (source_extension_reg1))
> > def_se: set (dest_extension_reg2) (sign_extend (dest_extension_reg1))
> >
> > and
> >
> > use_se: set (dest_extension_reg1) (sign_extend (dest_extension_reg1))
> > ref: set (dest_extension_reg2) (sign_extend (dest_extension_reg1))
> >
> > When def merge failed, def_se was deleted. Now use_se had a deleted
> > ref.
> >
> > Basically, SEE doesn't handle
> >
> > (set (reg/v:SI 70 [ j ])
> > (sign_extend:SI (subreg:HI (reg:SI 72 [ start ]) 0)))
> > (set (reg:DI 73 [ j ])
> > (sign_extend:DI (reg/v:SI 70 [ j ])))
> >
> > correctly.
> This is not true. SEE handles this. The problem that you saw are a result
> of Denis' change.
> >
> > 4. SEE also failed to handle
> >
> > set (dest_extension_reg1) (zero_extend (source_extension_reg1))
> > set (reg) (..dest_extension_reg1.
Re: Status of SEE and Autovectorization patches?
> H J Lu writes: >> > This is case for all extensions for i386. For x86-64, only >> > zero_extendsidi2 won't clobber CC. >> Again, for x86. HJ> But SEE doesn't provide a way to deal with it. Um, so extend SEE to better support your needs? David
Re: Status of SEE and Autovectorization patches?
On Thu, May 04, 2006 at 02:53:38PM -0400, David Edelsohn wrote: > > H J Lu writes: > > >> > This is case for all extensions for i386. For x86-64, only > >> > zero_extendsidi2 won't clobber CC. > >> Again, for x86. > > HJ> But SEE doesn't provide a way to deal with it. > > Um, so extend SEE to better support your needs? > > David We are working on it. In the meantime, we don't think SEE should be turned on by any -Ox on x86 and x86-64. We are also checking ia64 now. H.J.
Re: Dynamically generated code and DWARF exception handling
On May 4, 2006, at 5:05 AM, jacob navia wrote:
Well, I searched for those and found some usage examples in the
source of Apple Darwin gcc code for the startup. But then... is
that current?
This question lacks any detail that would allow me to answer it.
With enough detail, I could.
ALL of this is extremely confusing and I am getting scared really.
This list is isn't for people that get really scared.
Then, I will try to figure out from the source what they are doing
and what they expect. As far as I know, there is no AMD64 specific
docs, just ITANIUM docs that *could* be used for AMD64 but nobody
knows for sure
We know for sure. The answer is yes.
if those docs apply or they are just obsolete.
No, they are not obsolete.
One approach to solving this might be to do up your code following
the windows api, and then ask of specific questions on how to
implement that api. In the end, you can contribute that api to gcc,
and the next soul to want to do this would have an easier time. I
think that might make a reasonable addition (I'm assuming sanity in
the windows api) to gcc. If not, a simplified form of it hopefully
would.
The problem I see is related to libffi and the fact that the one abi
has to support every target, both now, and all future ones. Not
sure, but maybe expanding libffi to handle this case is the right
direction.
Another idea, is to, for each function foo you want to call on the
system, generate:
foo_prime() { try{ foo(); } catch (...) { longjmp() } }
with the system compiler and have the JIT dispatcher do the
corresponding setjmp, and when it comes back into it, rethrow from
there. This trades a host of problems for a different set of
problems. In doing the library, you're need to understand the dwarf
EH stuff, in the later scheme, no dwarf EH bits.
Re: [RFC] IL cleanups
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tom Tromey wrote on 05/04/06 12:58: > I've got a java-specific case or two that stress this idea a bit. > Where should I file these? > The GCC wiki should be a good place for now. Some of the ideas discussed in this thread are sprinkled throughout, particularly in http://gcc.gnu.org/wiki/Speedup%20areas. I will try to get them together into a separate sub-page and move items from 'Speedup areas' into the new one. > If you want to do jit stuff then there are a few other things to add > to the to-do list: remove global variables, general namespace > cleanliness improvements, back ends that go direct to memory... lots > of work. > Yes. If LLVM were to become available for us to use, we could initially start with a pass that emits LLVM bytecodes that are then sent to LLVM's jit. If not, we'll need to implement our own jit from scratch (perhaps using LLVM bytecodes, or define our own, I'm not sure). > Also some of the current global flags will have to be turned into > bits on operations. I'm thinking of things like -fwrapv here. > Good point. I had forgotten about that. I'll add it to the list. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEWlslUTa2oAUaiwQRAtA/AJ95qFQilMICrNvWOeAG0UDbGgV/XACePpNQ TQL+ARwA7F16xTf2kD/WOyE= =CL4Q -END PGP SIGNATURE-
Re: Status of SEE and Autovectorization patches?
H. J. Lu wrote: > export BOOT_CFLAGS="-g -O2 -fsee" CXXFLAGS="-g -O2 -fsee" FCFLAGS="-g -O2 > -fsee" GCJFLAGS="-g -O2 -fsee" SYSROOT_CFLAGS_FOR_TARGET="-g -O2 -fsee" > # /configure > # make BOOT_CFLAGS="-g -O2 -fsee" CXXFLAGS="-g -O2 -fsee" FCFLAGS="-g -O2 > -fsee" GCJFLAGS="-g -O2 -fsee" SYSROOT_CFLAGS_FOR_TARGET="-g -O2 -fsee" > > to configure and build gcc on Linux/x86 and Linux/x86-64. That certainly does suggest a bug in the SEE patches. They needn't do anything useful on IA32/AMD64, but they should presumably either (a) not cause a bootstrap failure on these architectures, or (b) be disabled on these architectures. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: [RFC] IL cleanups
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jan Hubicka wrote on 05/04/06 10:37: > (honestly I have no idea how long this will take, but I take your > promise of 12 weeks ;)) > Notice that I never said *calendar* weeks. Given the exploratory nature of some of these items, it may well take longer. However, I think it should be possible to get something substantial in that time frame (depending on resources). > I am also not quite convinced how much the SSA form aliasing helps > the IPA passes that are usually interested in rather straighforward > analysis of function body, so aliasing don't seems to be top priority > here. So I simply chosed to not mess with this for initial > implementation. > Sounds reasonable. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEWmRBUTa2oAUaiwQRAo4LAKCaYOMNUb88dIkpI4QuMWqYG8Vr6QCfS0LL 11tGH3pIepz1XS5pY3+RFXg= =Fs6d -END PGP SIGNATURE-
gcc compile time
I used gcc-2.96 to compile gcc-3.4.6 core with the c++ libraries added. It took almost if not two hours to compile and that was with these options: make CFLAGS='-O' LIBCFLAGS='-g -O2' LIBCXXFLAGS='-g -O2 -fno-implicit-templates' bootstrap This is supposed to save space. I want to cut down on compile time. Are there any options that can do that? Bill
codegen differences for increment of a volatile int
I've been looking at how GCC 4.0 handles "volatile" internally,
and may have a question/two on that later, but in the meantime,
I noticed some interesting differences in generated code that I
thought were a bit unusual, and was wondering if someone here
might explain why GCC behaves as it does, and what might be the
recommended behavior?
Beginning with this simple example,
1 int j;
2 volatile int jv;
3 void p()
4 {
5++j;
6++jv;
7 }
when compiled with "gcc (GCC) 3.4.4 20050721 (Red Hat 3.4.4-2)"
the following code results:
inclj
movljv, %eax
incl%eax
movl%eax, jv
Note that in the case where 'j' is _not_ volatile that a
single 'incl' was generated, but in the case where 'jv'
is volatile, the value was first loaded into a register,
then incremented and stored back into memory.
(asserting -O2 didn't substantially change the
generated code)
Compiling under "gcc (GCC) 4.0.2 20051125 (Red Hat 4.0.2-8)",
the compiler always uses the form where the value is first
loaded from memory into a register:
movlj, %eax
incl%eax
movl%eax, j
movljv, %eax
incl%eax
movl%eax, jv
However, if -O2 is asserted, then the behavior reverts
back the same behavior as demonstrated in gcc 3.4:
inclj
movljv, %eax
incl%eax
movl%eax, jv
[both systems are i386-redhat-linux (FC3 and FC4)]
Is there a technical reason that the use of "volatile" would
dictate the second form of increment that first loads the
value from memory into a register? I would think that a
systems programmer might expect the opposite behavior, where
"volatile" would imply the single instruction form of increment
(which is non-interruptible on single processor systems).
Re: gcc compile time
On May 4, 2006, at 2:17 PM, Bill Cunningham wrote: I used gcc-2.96 to compile gcc-3.4.6 core with the c++ libraries added. It took almost if not two hours to compile and that was with these options: make CFLAGS='-O' LIBCFLAGS='-g -O2' LIBCXXFLAGS='-g -O2 -fno-implicit-templates' bootstrap I want to cut down on compile time. Are there any options that can do that? You can use ccache to speed it up if you want to compile it over and over again. You can use -O0, that's faster than -O2. Also, you can install the new compiler, and then just use make instead of make bootstrap, that's also faster. Plus, you could just use make all instead, that's faster than bootstrap. And lastly, leaving out the - g is also faster.
Re: gcc compile time
2006/5/4, Mike Stump <[EMAIL PROTECTED]>: On May 4, 2006, at 2:17 PM, Bill Cunningham wrote: > I used gcc-2.96 to compile gcc-3.4.6 core with the c++ > libraries added. > It took almost if not two hours to compile and that was with these > options: > > make CFLAGS='-O' LIBCFLAGS='-g -O2' > LIBCXXFLAGS='-g -O2 -fno-implicit-templates' bootstrap > I want to cut down on compile time. Are there any options that can > do that? You can use ccache to speed it up if you want to compile it over and over again. You can use -O0, that's faster than -O2. Also, you can install the new compiler, and then just use make instead of make bootstrap, that's also faster. Plus, you could just use make all instead, that's faster than bootstrap. And lastly, leaving out the - g is also faster. If you have dual/multiple CPU's or HT using -j flag for make can speed things up considerably. Probably it would help a bit even on a single CPU machine. If you have several machines with the same compiler versions in LAN you can also use distcc together with the -j flag to distribute the job. -- Kalle Last
Re: codegen differences for increment of a volatile int
On May 4, 2006, at 2:45 PM, Gary Funck wrote: I've been looking at how GCC 4.0 handles "volatile" internally, and may have a question/two on that later, but in the meantime, I noticed some interesting differences in generated code that I thought were a bit unusual, and was wondering if someone here might explain why GCC behaves as it does Yeah, someone brings this issue up one every 2 or 3 years. This is like the 5th round now. Check the archive (and source code) for volatile_ok and my name. Because we're lazy is the answer you seek. :-( If you want to step forward and fix it, I'd be happy to go into more depth. It something like 20 lines to get started, and then audit the entire port to ensure nothing `funny' is done. Is there a technical reason that the use of "volatile" would dictate the second form of increment that first loads the value from memory into a register? No. I would think that a systems programmer might expect the opposite behavior, where "volatile" would imply the single instruction form of increment (which is non-interruptible on single processor systems). Yes.
gcc-4.0-20060504 is now available
Snapshot gcc-4.0-20060504 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20060504/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.0 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_0-branch revision 113541 You'll find: gcc-4.0-20060504.tar.bz2 Complete GCC (includes all of below) gcc-core-4.0-20060504.tar.bz2 C front end and core compiler gcc-ada-4.0-20060504.tar.bz2 Ada front end and runtime gcc-fortran-4.0-20060504.tar.bz2 Fortran front end and runtime gcc-g++-4.0-20060504.tar.bz2 C++ front end and runtime gcc-java-4.0-20060504.tar.bz2 Java front end and runtime gcc-objc-4.0-20060504.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.0-20060504.tar.bz2The GCC testsuite Diffs from 4.0-20060427 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.0 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: Google SoC Project proposal: Wcoercion option
Hi Ian, I have submitted the project proposal to Google so it should be available to GCC for review. Although I cannot edit it anymore, any comment, criticism (even in the language, I am not native English-speaker) would be welcome. Cheers, Manu. On 26 Apr 2006 10:05:34 -0700, Ian Lance Taylor wrote: [EMAIL PROTECTED] writes: > I would like to participate in the Google Summer of Code with GCC as > the mentoring organisation working in the project described below. > This is a draft of the project proposal I am preparing to submit to > Google. Any comments and suggestions (and criticism) are welcome. > Also, if someone wants to participate as a mentor for this project > [*], please get in contact with Ian Lance Taylor > and me. This looks like a good plan to me, well described, well thought out, and doable. Please submit it to Summer of Code when they start taking student applications on May 1. I'm willing to act as the mentor on this project, although it's fine with me if somebody else wants to take it on. Thanks! Ian
Re: Google SoC Project proposal: Wcoercion option
Hi Grabiel,
On 26 Apr 2006 20:36:27 +0200, Gabriel Dos Reis
<[EMAIL PROTECTED]> wrote:
I hope that does not fire up warnings for the following case and variants
struct A { /* ... */ };
struct B { /* ... */ };
struct C : A, B { /* ... */ };
void f(B*);
C c;
f(&c);
as the call to f(), implies an implicit conversion from C to B, that
alters the value of "&c".
I am sorry to say that I don't understand the definition of struct C.
Would you please write an example that compiles?
Anyway, I plan to divide the different cases into several patches, so
each case can be reviewed and tested independently. Also, I will send
each patch and testcases the list, so I am looking forward to reading
your review. It would be quite an achievement for me to see the option
merged into GCC mainline, so it is my intention to follow developers'
comments, and not to push or force any personal agenda.
Cheers,
Manu.
[PATCH] Strange ACATS fails in acats.log
On Thu, 2006-05-04 at 19:40 +0200, Richard Guenther wrote:
> On Thu, 4 May 2006, Laurent GUERBY wrote:
> > I see that from time to time, more on SMP/dual core machines, if you add
> > sync or sleep it goes away but the run is slower. I've always assumed
> > it's some kind of process/kernel/fs race condition (I don't see
> > anything wrong in gnatchop code).
>
> Yes, this happens repeatedly on a 4-way HT-Xeon machine. Maybe just
> skipping the test completely if $main is empty would at least avoid
> the spurious FAILs...
In the same vein as my 20050418 patch, may be the following will help.
Tested on x86_64-linux.
Laurent
2005-05-15 Laurent GUERBY <[EMAIL PROTECTED]>
* ada/acats/run_all.sh: Use sync when main not found.
Index: run_all.sh
===
--- run_all.sh (revision 113519)
+++ run_all.sh (working copy)
@@ -64,6 +64,13 @@
rm -f "$binmain" *.o *.ali > /dev/null 2>&1
}
+find_main () {
+ ls ${i}?.adb > ${i}.lst 2> /dev/null
+ ls ${i}*m.adb >> ${i}.lst 2> /dev/null
+ ls ${i}.adb >> ${i}.lst 2> /dev/null
+ main=`tail -1 ${i}.lst`
+}
+
EXTERNAL_OBJECTS=""
# Global variable to communicate external objects to link with.
@@ -230,10 +237,12 @@
fi
target_gnatchop -c -w `ls ${test}*.a ${test}*.ada ${test}*.adt
${test}*.am ${test}*.dep 2> /dev/null` >> $dir/acats.log 2>&1
- ls ${i}?.adb > ${i}.lst 2> /dev/null
- ls ${i}*m.adb >> ${i}.lst 2> /dev/null
- ls ${i}.adb >> ${i}.lst 2> /dev/null
- main=`tail -1 ${i}.lst`
+ main=""
+ find_main
+ if [ "$main" == "" ]; then
+ sync
+ find_main
+ fi
binmain=`echo $main | sed -e 's/\(.*\)\..*/\1/g'`
echo "BUILD $main" >> $dir/acats.log
EXTERNAL_OBJECTS=""
