question in porting gcc front end
i write a front-end , and compile it with gcc-3.4.1 source code,
and it errors in function rest_of_compilation()
void
rest_of_compilation (tree decl)
{
rtx insns;
timevar_push (TV_REST_OF_COMPILATION);
rtl_register_cfg_hooks ();
generating_concat_p = 0;
cse_not_expected = ! optimize;
/*
First,
make
sure
that
NOTE_BLOCK
is
set
correctly
for
each
NOTE_INSN_BLOCK_BEG/NOTE_INSN_BLOCK_END note. */
if (!cfun->x_whole_function_mode_p)
identify_blocks ();
}
:internal compiler error: in identify_blocks_1, at function.c:6090
idendify_blocks()
{
last_block_vector = identify_blocks_1 (get_insns (),
block_vector + 1,
block_vector + n_blocks,
block_stack);
.
}
it seems that i haven`t give the block information for current_function_decl.
because when i gdb it, the n_blocks=1;
when should i build the block structure?
Re: [rfc] mainline slush
> On Sunday 22 May 2005 00:16, Jan Hubicka wrote: > > (not sure of -fdump-rtl-expand ever worked, but I > > might try to restore it if it did). > > It very definitely did work, and quite nicely too. > Try -fdump-rtl-expand-details. Yeah, but on tree-profiling it always was -fdump-tree-expand-details. Now I see what went wrong. I am still testing the patch but it should rename it back to -fdump-rtl-expand 2005-05-22 Jan Hubicka <[EMAIL PROTECTED]> * tree-optimize.c (init_tree_optimization_passes): Fix flags of all_passes and all_ipa_passes. Index: tree-optimize.c === RCS file: /cvs/gcc/gcc/gcc/tree-optimize.c,v retrieving revision 2.101 diff -c -3 -p -r2.101 tree-optimize.c *** tree-optimize.c 19 May 2005 10:38:42 - 2.101 --- tree-optimize.c 22 May 2005 08:50:25 - *** init_tree_optimization_passes (void) *** 487,499 #undef NEXT_PASS register_dump_files (all_lowering_passes, false, PROP_gimple_any); ! register_dump_files (all_passes, false, PROP_gimple_any ! | PROP_gimple_lcf ! | PROP_gimple_leh | PROP_cfg); ! register_dump_files (all_ipa_passes, true, PROP_gimple_any !| PROP_gimple_lcf !| PROP_gimple_leh | PROP_cfg); } --- 488,496 #undef NEXT_PASS register_dump_files (all_lowering_passes, false, PROP_gimple_any); ! register_dump_files (all_passes, false, PROP_gimple_leh | PROP_cfg); ! register_dump_files (all_ipa_passes, true, PROP_gimple_leh | PROP_cfg); }
Re: Problem in assembly and linking(gcc-4.0)
gcc -S file.c as -o file.o file.s ld -o exefile file.o /usr/lib/crt1.o /usr/lib/crti.o -lc /usr/lib/crtn.o -dynamic /lib/ld-linux.so.2 * You might also do gcc file.c .But well, see below : The executable produced above works fine. This would mean that there is some problem occuring while assembling or linking in regualr commands used by gcc. is there a solution for this ? * Fireup gdb. ( http://sources.redhat.com/gdb ) * run your program * Look at reason for segfault. Also this list is for devel of gcc and not devel using gcc. Please use gcc-help instead if you have a problem with using gcc. cheers Ramana -- Ramana Radhakrishnan GNU Tools codito ergo sum (www.codito.com)
Re: [rfc] mainline slush
> Eric Botcazou <[EMAIL PROTECTED]> writes: > > >> On Sat, May 21, 2005 at 12:16:27AM +0200, Eric Botcazou wrote: > >> > http://gcc.gnu.org/ml/gcc-testresults/2005-05/msg01339.html > >> > >> The vectorization failures still need to be fixed. > > > > Are these specific to SPARC? If so, I don't think development > should be held > > off for them at this point. If not, platforms with real SIMD units are > > probably better testbeds. > > Happen also on x86_64-linux-gnu, e.g.: > ... > FAIL: gcc.dg/vect/pr18400.c (test for excess errors) > WARNING: gcc.dg/vect/pr18400.c compilation failed to produce executable > FAIL: gcc.dg/vect/vect-11a.c (test for excess errors) > WARNING: gcc.dg/vect/vect-11a.c compilation failed to produce executable > FAIL: gcc.dg/vect/vect-11a.c scan-tree-dump-times vectorized 1 loops 2 > FAIL: gcc.dg/vect/vect-2.c (test for excess errors) > WARNING: gcc.dg/vect/vect-2.c compilation failed to produce executable > XPASS: gcc.dg/vect/vect-22.c scan-tree-dump-times vectorized 3 loops 1 > FAIL: gcc.dg/vect/vect-34.c (test for excess errors) > WARNING: gcc.dg/vect/vect-34.c compilation failed to produce executable > FAIL: gcc.dg/vect/vect-66.c (test for excess errors) > WARNING: gcc.dg/vect/vect-66.c compilation failed to produce executable > XPASS: gcc.dg/vect/vect-67.c scan-tree-dump-times vectorized 1 loops 1 > FAIL: gcc.dg/vect/vect-93.c (test for excess errors) > WARNING: gcc.dg/vect/vect-93.c compilation failed to produce executable > FAIL: gcc.dg/vect/vect-all.c (test for excess errors) > WARNING: gcc.dg/vect/vect-all.c compilation failed to produce executable > FAIL: gcc.dg/vect/vect-none.c scan-tree-dump-times vectorized 1 loops 1 > ... > FAIL: gcc.dg/vect/pr18400.c (test for excess errors) > FAIL: gcc.dg/vect/vect-11a.c (test for excess errors) > FAIL: gcc.dg/vect/vect-11a.c scan-tree-dump-times vectorized 1 loops 2 > FAIL: gcc.dg/vect/vect-2.c (test for excess errors) > FAIL: gcc.dg/vect/vect-34.c (test for excess errors) > FAIL: gcc.dg/vect/vect-66.c (test for excess errors) > XPASS: gcc.dg/vect/vect-67.c scan-tree-dump-times vectorized 1 loops 1 > FAIL: gcc.dg/vect/vect-93.c (test for excess errors) > FAIL: gcc.dg/vect/vect-all.c (test for excess errors) > FAIL: gcc.dg/vect/vect-shift-1.c (test for excess errors) > I also see these failures on powerpc-apple-darwin, but they are all solved when I apply Keith's patch: http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00803.html dorit > > The errors I'm seeing are: > FAIL: gcc.dg/vect/pr18400.c (test for excess errors) > Excess errors: > /cvs/gcc/gcc/testsuite/gcc.dg/vect/pr18400.c:9: internal compiler > error: tree ch > eck: expected ssa_name, have var_decl in verify_ssa, at tree-ssa.c:750 > > WARNING: gcc.dg/vect/pr18400.c compilation failed to produce executable > > Andreas > -- > Andreas Jaeger, [EMAIL PROTECTED], http://www.suse.de/~aj > SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany >GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 > [attachment "attdhcxd.dat" deleted by Dorit Naishlos/Haifa/IBM]
Re: Some questions about FIELD_DECL
On Sat, 2005-05-21 at 21:32 -0700, Zack Weinberg wrote: > Daniel Berlin <[EMAIL PROTECTED]> writes: > > > I've actually discovered that we set the assembler name on a field that > > is the vtable, but never actually use it again, at least for DWARF2 and > > STABS (it's set to a constant called VFIELD_NAME). > > I grepped .s file from all of libjava and the stl testcases compared > > with -gstabs and -gdwarf-2, and none of them contain VFIELD_NAME with or > > without my change. > > This appears to be mostly vestigial old ABI stuff. VFIELD_NAME_P is > used to special-case the vtable pointer in the default copy > constructor and assignment operator (see cp/method.c: > do_build_copy_constructor, do_build_assign_ref respectively) but that > can and probably should be changed. Even if it's kept, it would > suffice to use the DECL_NAME, not the DECL_ASSEMBLER_NAME, for that. > Thanks. In fact, it's already, checking DECL_NAME, which is still set by the build_decl call above the one setting the assembler name (IE nothing has changed). IE: field = build_decl (FIELD_DECL, get_vfield_name (t), vtbl_ptr_type_node); SET_DECL_ASSEMBLER_NAME (field, get_identifier (VFIELD_NAME)); and then [EMAIL PROTECTED]:/mnt/gccstuff/gcc-cleaning-decls/gcc/cp> grep VFIELD_NAME_P *.c method.c: if (VFIELD_NAME_P (DECL_NAME (field))) method.c: if (VFIELD_NAME_P (DECL_NAME (field))) So the check will still succeed when it should without the assembler name :). Overnight i compiled libjava with and without the line setting the assembler name, and the .s files are identical > zw
Re: [rfc] mainline slush
On Sun, May 22, 2005 at 05:25:13PM +0300, Dorit Naishlos wrote: > I also see these failures on powerpc-apple-darwin, but they are all solved > when I apply Keith's patch: > http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00803.html His patch was approved under the condition that a few things get modified: http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00900.html Unfortunately he did not seem to have sent a followup. Could you polish up his patch and get it committed? Or who will? Andreas -- Andreas Jaeger, [EMAIL PROTECTED], http://www.suse.de/~aj SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Re: [rfc] mainline slush
Andreas Jaeger <[EMAIL PROTECTED]> wrote on 22/05/2005 17:29:24: > On Sun, May 22, 2005 at 05:25:13PM +0300, Dorit Naishlos wrote: > > I also see these failures on powerpc-apple-darwin, but they are all solved > > when I apply Keith's patch: > > http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00803.html > > His patch was approved under the condition that a few > things get modified: > http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00900.html > > > Unfortunately he did not seem to have sent a followup. Could you > polish up his patch and get it committed? Or who will? > let's give Keith another day to respond, he's the most qualified person to do this dorit > Andreas > -- > Andreas Jaeger, [EMAIL PROTECTED], http://www.suse.de/~aj > SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany >GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
gcc-4.1-20050522 is now available
Snapshot gcc-4.1-20050522 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20050522/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.1 CVS branch with the following options: -D2005-05-22 17:43 UTC You'll find: gcc-4.1-20050522.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20050522.tar.bz2 C front end and core compiler gcc-ada-4.1-20050522.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20050522.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20050522.tar.bz2 C++ front end and runtime gcc-java-4.1-20050522.tar.bz2 Java front end and runtime gcc-objc-4.1-20050522.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20050522.tar.bz2The GCC testsuite Diffs from 4.1-20050515 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.1 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: expand_main_function/PREFERRED_STACK_BOUNDARY on ppc
Richard Henderson wrote: > > A possible way to address that is to have expand_main_function compute the > > distance between the current and aligned values of the stack pointer and > > resort to allocate_dynamic_stack_space to allocate exactly that amount. > Sure, if it works. OK, I'll test my current patch more extensively and followup on GCC patches. Thanks for your reply. Olivier
Compiling GCC with g++: a report
Hi, I spent the week-end trying to get GCC -- mainline -- compilable (i.e. those compoenents written in C) with a C++ compiler (e.g. g++). My summary is: It is largely doable and it is within our reach at this point of development. More specifically, I successfully got all files necessary to build a native GNU C compiler on an i686-pc-linux-gnu. Attempt to get the GNU C++ compiler through the same massage is underway (but I'm going to bed shortly ;-)). I think this project is beneficial to GCC for several reasons: (1) for testing purposes, we can use a compiler with stricter type checking. (2) there have been lots of discussions about more static typing in the data structures, but so far we haven't made anything concrete. Partly because, we need this sort of preliminary preparation of thee source tree. We can have infinite debates about the merits of such approaches, but I think a way to know is to do actual experiments and we better start making that possible now. (3) It might open the door for more contributions and foster more free software based on GCC. (4) . What I have learnt from this little experience. Well, the source code seems to have been carefully written to make sure that no lunatic (e.g. the author of this writing) will succeed in feeding a C++ compiler with GCC :-) The first resistance seems to come from the pervasive use of the implicit conversion void* -> T*, mostly with storage allocating functions. We've recently introduced C++ friendly macros in libiberty, but we have yet to take advantage of them. We should start now. (I also noted a happy confusion about the calling convention of the function [x]calloc(), but it is mostly harmless as everything "multiply nicely" in the end and we don't get burned by strict alignment issues). We should generalize the notation for GGC allocators and alloca(). The second resistance is the pervasive use of C++ keywords (e.g. new, class, template, try, catch, ...). The first three are quite frequent in the middle-end. Third, there is some "type-punning" with enums, int and unsigned int, where the middle-end (mostly) relies on implicit conversion from int to enums. That is a bit annoying but could be avoided as most of the time, we do have names for those integer constants. For example, we should be using EXPAND_NORMAL instead of 0, or VOIDmode, instead of 0, TV_TOTAL instead of 0, etc. At this point, I should also note that not implicit conversions between enums (c_tree_code <-> tree_code, or rtx_code <-> reg_note, etc.) is not supported in C++. So, we should probably arrange to make the relationship (mostly subsetting) between more explicit, as opposed to throwing in casts. Also, there are few cases where we want to iterate over all the values of enumerations. I've shamelessly used the following macros: #define NEXT(E) ((__typeof__(E)) (E + 1)) #define PREV(E) ((__typeof__(E)) (E - 1)) #define DECR(E) (E = (__typeof__(E)) (E - 1)) #define INCR(E) (E = (__typeof__(E)) (E + 1)) #define IOR(A,B) ((__typeof__(A)) (A | B)) #define AND(A,B) ((__typeof__(A)) (A & B)) #define XOR(A,B) ((__typeof__(A)) (A ^ B)) but I'm not suggesting that as real replacement; just reporting the dirty tricks I did and I'm looking for better suggestions. Fourth, it appears that we're implicilty using C99's semantics of "extern inline" in our source -- when we have a pure C90 compiler that does not understand "inline", we just #define inline to nothing so we don't get into trouble. With a C++ compiler, we're in trouble because an inline function needs to be defined in every translation where it is used. So, I either move the affected functions to "static inline" or just make then non-inline (cases are in hashtable.c and toplev.c). Fifth, there is a slight difference between "const" in C and in C++. In C++, a const variable implicitly has an internal linkage; so a C++ compiler tends to optimize it out when its address is not taken (so no storage is wasted). This is an issue for the objects automatically generated by the gengtype support machinery. The are supposed to have external linkage, so we need to explicitly say "extern" in their definitions. Sixth, there is a real "mess" about name spaces. It is true that every C programmers knows the rule saying tags inhabit different name space than variable of functions. However, all the C coding standards I've read so far usually suggest typedef struct foo foo; but *not* typedef struct foo *foo; i.e. "bringing" the tag-name into normal name space to name the type structure or enumeration is OK, but not naming a different type! the latter practice will be flagged by a C++ compiler. I guess we may need some discussion about the naming of structure (POSIX reserves anything ending with "_t", so we might want to choose something so that we don't run into problem. However, I do not expect this issue to d
Re: Compiling GCC with g++: a report
Gabriel Dos Reis wrote: > Hi, > > I spent the week-end trying to get GCC -- mainline -- compilable > (i.e. those compoenents written in C) with a C++ compiler (e.g. g++). [...] > > I think this project is beneficial to GCC for several reasons: [...] > > (4) . Tom Tromey's GCJX (gcjx_branch in CVS), the completely rewritten Java front-end that is written in C++. Ranjit. -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/
