Re: gcc crosscompile for PPC, Please help!
[EMAIL PROTECTED] wrote on 24/09/2007 09:19:09:
> Hi All,
>
> I wanted to install gcc-3.4 on my ppc-linux m/c. I tried cross
> compiling, but cought up with error which i'm not familiar with as i'm
> new here.
GCC list is about development of GCC so I think you should try the
gcc-help mailing list instead.
Thanks,
Revital
>
> The following is the error log on make:
>
-
> [EMAIL PROTECTED] gcc_build]# make
> make[1]: Entering directory
> `/home/ashok/gcc_build/build-i386-linux/libiberty'
> make[2]: Entering directory
> `/home/ashok/gcc_build/build-i386-linux/libiberty/testsuite'
> make[2]: Nothing to be done for `all'.
> make[2]: Leaving directory
> `/home/ashok/gcc_build/build-i386-linux/libiberty/testsuite'
> make[2]: Entering directory
> `/home/ashok/gcc_build/build-i386-linux/libiberty'
> if [ -z "" ]; then \
> true; \
> else \
> rootpre=`${PWDCMD-pwd}`/; export rootpre; \
> srcrootpre=`cd ../../../gcc-3.4.4/libiberty; ${PWDCMD-pwd}`/; export
> srcrootpre; \
> lib=`echo ${rootpre} | sed -e 's,^.*/\([^/][^/]*\)/$,\1,'`; \
> compiler="gcc"; \
> for i in `${compiler} --print-multi-lib 2>/dev/null`; do \
> dir=`echo $i | sed -e 's/;.*$//'`; \
> if [ "${dir}" = "." ]; then \
> true; \
> else \
> if [ -d ../${dir}/${lib} ]; then \
> flags=`echo $i | sed -e 's/^[^;]*;//' -e 's/@/ -/g'`; \
> if (cd ../${dir}/${lib}; make "AR=ar" "AR_FLAGS=rc" "CC=gcc"
> "CFLAGS=-g -O2" "DESTDIR=" "LIBCFLAGS=-g -O2" "EXTRA_OFILES="
> "HDEFINES=" "INSTALL=/usr/bin/install -c" "INSTALL_DATA=/usr/bin/install
> -c -m 644" "INSTALL_PROGRAM=/usr/bin/install -c" "LDFLAGS=" "LOADLIBES="
> "RANLIB=ranlib" "SHELL=/bin/sh" "prefix=/usr/local"
> "exec_prefix=/usr/local" "libdir=/usr/local/lib" "libsubdir=" "tooldir="
\
> CFLAGS="-g -O2 ${flags}" \
> prefix="/usr/local" \
> exec_prefix="/usr/local" \
> GCJFLAGS=" ${flags}" \
> CXXFLAGS=" ${flags}" \
> LIBCFLAGS="-g -O2 ${flags}" \
> LIBCXXFLAGS=" ${flags}" \
> LDFLAGS=" ${flags}" \
> MULTIFLAGS="${flags}" \
> DESTDIR="" \
> INSTALL="/usr/bin/install -c" \
> INSTALL_DATA="/usr/bin/install -c -m 644" \
> INSTALL_PROGRAM="/usr/bin/install -c" \
> INSTALL_SCRIPT="" \
> all); then \
> true; \
> else \
> exit 1; \
> fi; \
> else true; \
> fi; \
> fi; \
> done; \
> fi
> make[2]: Leaving directory
> `/home/ashok/gcc_build/build-i386-linux/libiberty'
> make[1]: Leaving directory
> `/home/ashok/gcc_build/build-i386-linux/libiberty'
> make[1]: Entering directory `/home/ashok/gcc_build/libiberty'
> make[2]: Entering directory `/home/ashok/gcc_build/libiberty/testsuite'
> make[2]: Nothing to be done for `all'.
> make[2]: Leaving directory `/home/ashok/gcc_build/libiberty/testsuite'
> make[1]: Leaving directory `/home/ashok/gcc_build/libiberty'
> make[1]: Entering directory `/home/ashok/gcc_build/intl'
> make[1]: Nothing to be done for `all'.
> make[1]: Leaving directory `/home/ashok/gcc_build/intl'
> make[1]: Entering directory `/home/ashok/gcc_build/zlib'
> : make ; exec true "AR_FLAGS=rc" "CC_FOR_BUILD=gcc" "CFLAGS=-g -O2"
> "CXXFLAGS=-g -O2" "CFLAGS_FOR_BUILD=" "CFLAGS_FOR_TARGET=-O2 -g -O2"
> "INSTALL=/usr/bin/install -c" "INSTALL_DATA=/usr/bin/install -c -m 644"
> "INSTALL_PROGRAM=/usr/bin/install -c" "INSTALL_SCRIPT=/usr/bin/install
> -c" "LDFLAGS=" "LIBCFLAGS=-g -O2" "LIBCFLAGS_FOR_TARGET=-O2 -g -O2"
> "MAKE=make" "MAKEINFO=makeinfo --split-size=500 " "PICFLAG="
> "PICFLAG_FOR_TARGET=" "SHELL=/bin/sh" "EXPECT=expect" "RUNTEST=runtest"
> "RUNTESTFLAGS=" "exec_prefix=/usr/local" "infodir=/usr/local/info"
> "libdir=/usr/local/lib" "prefix=/usr/local"
> "tooldir=/usr/local/ppc-linux"
> "AR=powerpc-wrs-linux-gnu-ppc7400-glibc_cgl-ar"
> "AS=powerpc-wrs-linux-gnu-ppc7400-glibc_cgl-as"
> "CC=powerpc-wrs-linux-gnu-ppc7400-glibc_cgl-gcc"
> "CXX=powerpc-wrs-linux-gnu-ppc7400-glibc_cgl-g++"
> "LD=powerpc-wrs-linux-gnu-ppc7400-glibc_cgl-ld" "LIBCFLAGS=-g -O2"
> "NM=powerpc-wrs-linux-gnu-ppc7400-glibc_cgl-nm" "PICFLAG=" "RANLIB=:"
> "DESTDIR=" DO=all multi-do
> make[1]: Leaving directory `/home/ashok/gcc_build/zlib'
> make[1]: Entering directory `/home/ashok/gcc_build/gcc'
> powerpc-wrs-linux-gnu-ppc7400-glibc_cgl-gcc -g -O2 -DIN_GCC -W -Wall
> -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic
> -Wno-long-long-DHAVE_CONFIG_H -o cc1 \
> c-parse.o c-lang.o c-pretty-print.o stub-objc.o attribs.o
> c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o c-convert.o
> c-aux-info.o c-common.o c-opts.o c-format.o c-semantics.o c-in
AST-tree in GCC
Hi I want to extract the complete AST-tree from GCC (using 4.1.2). I´ve tried to use -fdump-translation-unit but it seems like its dosent include information in ex. for and if statements. If i use -fdump-tree-orignal-raw i get each function but not the external variables if they are not used in the function. My question is... Anyone knows a way to get all information ? Maybe changing a flag in the source code or something. //Regards John
How to force instruction in slot1 while emit NOP in slot0 if necessary?
We are portinng GCC 4.2.1 to a 2-issue VLIW processor. There are some special instructions which can only be issued on the second slot (slot 1). I tried to specify using following DFA constructs. ;; Define this instruction can only be issued on slot 1 (define_insn_reservation "psr_y" 1 (eq_attr "type" "psr") "slot1" ) ;; Define slot1 can only be issued after slot0 is filled (presence_set "slot1" "slot0") I hope the compiler can automatically insert NOP on slot0 if it is unused so that the second constraint can be fulfilled. However, the compiler falls into a deadlock. Without the second constraint , the compiler can emit code but I cannot tell from RTL on which slot the instruction is issued. What is best way to figure out unused slot and insert NOP insn? Or is there more clever way to specify DFA that allows compiler automatically emit NOPs? Any suggestion is greatly appreciated.
Re: AST-tree in GCC
On 9/24/07, Johan Bohlin <[EMAIL PROTECTED]> wrote: > My question is... Anyone knows a way > to get all information ? Maybe changing a flag in the source code or > something. Debugging dumps are always incomplete. Mostly by design, but in general because we just dump what seems useful for debugging. There is work in progress to stream out the IL in order to do link-time optimizations (search for LTO on the GCC wiki).
Re: how to chase a tree check failure in verify_ssa?
On 9/23/07, Gary Funck <[EMAIL PROTECTED]> wrote: > The operand, op: > > (gdb) p op > $49 = 0x2e1ebc60 > (gdb) pt >
Re: AST-tree in GCC
Perhaps you could also try -fdump-tree-gimple or -fdump-tree-gimple-raw In both cases you dump out the GIMPLE form, AST based. Best, T. > Hi I want to extract the complete AST-tree from GCC (using 4.1.2). > I´ve tried to use -fdump-translation-unit but it seems like its dosent > include information in ex. for and if statements. If i use > -fdump-tree-orignal-raw i get each function but not the external variables > if they are not used in the function. My question is... Anyone knows a way > to get all information ? Maybe changing a flag in the source code or > something. > > > //Regards John > >
Re: Inconsistent error/pedwarn: ISO C++
On 20/09/2007, Doug Gregor <[EMAIL PROTECTED]> wrote:
> We can't seem to decide whether ISO C++ really forbids comparisons
> between pointers and integers or not. The first two are for == and !=,
> the second two are for <, >, <=, >=. Why the inconsistency?
>
> typeck.c: error ("ISO C++ forbids comparison between pointer
> and integer");
> typeck.c: error ("ISO C++ forbids comparison between pointer
> and integer");
> typeck.c: pedwarn ("ISO C++ forbids comparison between
> pointer and integer");
> typeck.c: pedwarn ("ISO C++ forbids comparison between
> pointer and integer");
>
Open a PR and CC Gabriel. I am sure he will give his opinion as soon
as he has free time. Otherwise, this may get forgotten. As I guess, I
think that if ISO C++ forbids the comparison, this should be a
pedwarn. On the other hand, this may be some special case as these
ones:
cd ~/src/trunk/gcc/cp/
grep -n -e "error (.*ISO C\+\+" *.c /dev/null
decl.c:4232: error ("ISO C++ forbids use of initializer list to "
decl.c:6835:error ("ISO C++ forbids in-class initialization of non-const "
decl.c:9753: error ("ISO C++ prohibits overloading operator ?:");
typeck.c:3360:error ("ISO C++ forbids comparison between pointer
and integer");
typeck.c:3365:error ("ISO C++ forbids comparison between pointer
and integer");
typeck.c:5575:error ("ISO C++ forbids casting to an array type %qT", type);
Cheers,
Manuel.
Re: [RFC] failures found while pounding on GCC trunk
On 24/09/2007, Daniel Berlin <[EMAIL PROTECTED]> wrote: > On 9/23/07, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote: > > > > And *before* salias? Does it make a difference? It suits me better for > > my purposes. > > Can't do it before salias. > > I didn't want to add a dummy pass mainly because i didn't want people > to get back to calling something like pass_may_alias. > > If we add a dummy pass, can we verify it is only executed once per function? > I don't understand is why PROPerties are not associated with TODO_ functions in a way that if a pass don't have the properties it requires, it can call the appropriate TODO_ function. That way, if some pass needs PROP_alias but none has triggered TODO_rebuild_alias, then that pass calls TODO_rebuild_alias by itself. That way, if no pass requires alias information, then no pass ever calls TODO_rebuild_alias. Not sure that I am not talking nonsense, but this seems a far better approach that just ICEing because a certain combination of passes cannot work together. Anyway, this surely is far more complex that I am making it out to be... sorry. Cheers, Manuel.
Re: [RFC] failures found while pounding on GCC trunk
On 9/24/07, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote: > I don't understand is why PROPerties are not associated with TODO_ > functions in a way that if a pass don't have the properties it > requires, it can call the appropriate TODO_ function. That way, if > some pass needs PROP_alias but none has triggered TODO_rebuild_alias, > then that pass calls TODO_rebuild_alias by itself. That way, if no > pass requires alias information, then no pass ever calls > TODO_rebuild_alias. That was one of the original design intentions. But it was never actually implemented this way. I think it would be possible to implement it this way but then we would have to distinguish whether a certain property needs to be refreshed or not. For instance, if you ask PROP_alias and aliases have been computed already, you'd have to check that we don't need to compute aliases again. That may add a few wrinkles to the process.
Re: [RFC] failures found while pounding on GCC trunk
On 24/09/2007, Diego Novillo <[EMAIL PROTECTED]> wrote: > On 9/24/07, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote: > > > I don't understand is why PROPerties are not associated with TODO_ > > functions in a way that if a pass don't have the properties it > > requires, it can call the appropriate TODO_ function. That way, if > > some pass needs PROP_alias but none has triggered TODO_rebuild_alias, > > then that pass calls TODO_rebuild_alias by itself. That way, if no > > pass requires alias information, then no pass ever calls > > TODO_rebuild_alias. > > That was one of the original design intentions. But it was never > actually implemented this way. I think it would be possible to > implement it this way but then we would have to distinguish whether a > certain property needs to be refreshed or not. > > For instance, if you ask PROP_alias and aliases have been computed > already, you'd have to check that we don't need to compute aliases > again. That may add a few wrinkles to the process. > I don't get it. If you ask for PROP_alias and aliases have been computed, then PROP_alias is enabled and you don't need to compute them again. Cheers, Manuel.
Re: [RFC] failures found while pounding on GCC trunk
On 9/24/07, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote: > I don't get it. If you ask for PROP_alias and aliases have been > computed, then PROP_alias is enabled and you don't need to compute > them again. You do if alias information has gone stale due to transformations. The SSA form is another example. You can have the program in SSA form, but a transformation has inserted new code that also needs to be placed in SSA form. It could be arranged by clearing PROP_ssa on exit.
Re: [RFC] failures found while pounding on GCC trunk
On 24/09/2007, Diego Novillo <[EMAIL PROTECTED]> wrote: > On 9/24/07, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote: > > > I don't get it. If you ask for PROP_alias and aliases have been > > computed, then PROP_alias is enabled and you don't need to compute > > them again. > > You do if alias information has gone stale due to transformations. > The SSA form is another example. You can have the program in SSA > form, but a transformation has inserted new code that also needs to be > placed in SSA form. > > It could be arranged by clearing PROP_ssa on exit. > That is exactly what I had in mind. If you invalidate a property then the property is destroyed and whoever asks for it must invoke the relevant function to enable it again. Is that a problem? Cheers, Manuel.
Re: [RFC] failures found while pounding on GCC trunk
On 9/24/07, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote: > That is exactly what I had in mind. If you invalidate a property then > the property is destroyed and whoever asks for it must invoke the > relevant function to enable it again. Is that a problem? In principle, I don't think that'd be a problem. There will be surprises lurking, though. Also, I haven't thought whether this would be any simpler or easier to use than the current scheme. I guess I don't mind either way.
Re: [RFC] failures found while pounding on GCC trunk
On 9/24/07, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote: > On 24/09/2007, Daniel Berlin <[EMAIL PROTECTED]> wrote: > > On 9/23/07, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote: > > > > > > And *before* salias? Does it make a difference? It suits me better for > > > my purposes. > > > > Can't do it before salias. > > > > I didn't want to add a dummy pass mainly because i didn't want people > > to get back to calling something like pass_may_alias. > > > > If we add a dummy pass, can we verify it is only executed once per function? > > > > I don't understand is why PROPerties are not associated with TODO_ > functions in a way that if a pass don't have the properties it > requires, it can call the appropriate TODO_ function. That way, if > some pass needs PROP_alias but none has triggered TODO_rebuild_alias, > then that pass calls TODO_rebuild_alias by itself. That way, if no > pass requires alias information, then no pass ever calls > TODO_rebuild_alias. This is what I originally wanted, and i believe the original intention, but at some point somebody turned it into a way to simply verify all the prereqs are missed. This is what LLVM does, BTW.
Re: [RFC] failures found while pounding on GCC trunk
On 9/24/07, Diego Novillo <[EMAIL PROTECTED]> wrote: > On 9/24/07, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote: > > > That is exactly what I had in mind. If you invalidate a property then > > the property is destroyed and whoever asks for it must invoke the > > relevant function to enable it again. Is that a problem? > > In principle, I don't think that'd be a problem. There will be > surprises lurking, though. > > Also, I haven't thought whether this would be any simpler or easier to > use than the current scheme. I guess I don't mind either way. > The main difference is that passes now say whether they've destroyed something or preserved something, instead of it being fixed and trying to have the TODO's check whether anything needs to be done. In practice, it is much easier to try new pass orderings if you make the passes run what they need, instead of statically verifying you've gotten the magic pass properties right :)
Re: how to chase a tree check failure in verify_ssa?
On Mon, Sep 24, 2007 at 09:36:25AM -0400, Diego Novillo wrote:
> On 9/23/07, Gary Funck <[EMAIL PROTECTED]> wrote:
>
> > The operand, op:
> >
> > (gdb) p op
> > $49 = 0x2e1ebc60
> > (gdb) pt
> >
> This symbol was not marked for renaming and the program is already in
> SSA form. When your pass introduces new symbols, you need to add them
> to the symbol table (with add_referenced_var) and also mark it for
> renaming (with mark_sym_for_renaming). For examples see passes like
> tree-sra.c or tree-pre.c that create new variables.
Diego, thanks. That particular symbol is being created in
gimplify_expr, here (at line 541):
536 won't allocate any variable that is used in more than one basic
537 block, which means it will go into memory, causing much extra
538 work in reload and final and poorer code generation, outweighing
539 the extra memory allocation here. */
540 if (!optimize || !is_formal || TREE_SIDE_EFFECTS (val))
541 ret = create_tmp_from_val (val);
542 else
543 {
544 elt_t elt, *elt_p;
545 void **slot;
Above, optimize=3, is_formal=0, and by deduction, side-effects
must be true.
'val' above, is a constructor:
(gdb) p debug_tree (val)
unit size
align 64 symtab 0 alias set 3
fields
unsigned external bit-field nonaddressable decl_4 SI file
line 0
size
unit size
align 1 offset_align 128
offset
bit offset
bit_field_type context chain >
chain >
constant>
We use constructors to build a UPC shared pointer value (it has three
parts [phase, thread, vaddr]).
I would have thought gimplify_expr's internal mechanisms would
mark veriables as referenced, when it needs to?
Re: how to chase a tree check failure in verify_ssa?
Diego, a bit more info. It seems that gimplify_operand is being called in the rewrite_uses pass of tree-ssa-loop-ivopts.c. gimplify_operand() is working on this expr: unit size align 32 symtab 0 alias set -1 precision 32 min max > constant invariant arg 0 constant invariant arg 0 constant static arg 0 constant>>> arg 1 constant invari As you can can see, we coerce a constructor into a UPC shared pointer, which works something like a pointer, but it is not inter-operable directly with integers. Typically, we have to locate the places where these sorts of optimizations are attempted and disable them for UPC shared pointers. Thanks for you help. It got me pointed in the right direction. - Gary
Re: how to chase a tree check failure in verify_ssa?
On 9/24/07, Gary Funck <[EMAIL PROTECTED]> wrote: > I would have thought gimplify_expr's internal mechanisms would > mark veriables as referenced, when it needs to? No, it doesn't. It simply converts to GIMPLE. Once you inserted the new statement, you will need to call mark_symbols_for_renaming() on the new statement. Unfortunately, this is all not well documented. The canonical way is: - create the statement with build() or force_gimple_operand() (if you want to gimplify an expression). - insert it on an edge or block with bsi_insert_... - Call update_stmt() to have it scanned for operands. - Call mark_symbols_for_renaming() to find all the new symbols and mark them for renaming. I keep promising myself that I will spend a few weeks writing up API documentation for all of this. The contents of tree-ssa.texi are too out of date. One dragon at a time...
Re: How to force instruction in slot1 while emit NOP in slot0 if necessary?
"Bingfeng Mei" <[EMAIL PROTECTED]> writes: > We are portinng GCC 4.2.1 to a 2-issue VLIW processor. There are some > special instructions which can only be issued on the second slot (slot > 1). I tried to specify using following DFA constructs. > > ;; Define this instruction can only be issued on slot 1 > (define_insn_reservation "psr_y" 1 > (eq_attr "type" "psr") > "slot1" ) > > ;; Define slot1 can only be issued after slot0 is filled > (presence_set "slot1" "slot0") > > > I hope the compiler can automatically insert NOP on slot0 if it is > unused so that the second constraint can be fulfilled. However, the > compiler falls into a deadlock. Without the second constraint , the > compiler can emit code but I cannot tell from RTL on which slot the > instruction is issued. What is best way to figure out unused slot and > insert NOP insn? Or is there more clever way to specify DFA that allows > compiler automatically emit NOPs? Any suggestion is greatly > appreciated. You can't do this in gcc's scheduler DFA. It's one of its major limitations. There are a couple of ways to handle this. My personal favorite is to do it in the TARGET_ASM_FUNCTION_PROLOGUE routine. For an example of this approach see frv_pack_insns in frv.c. Ian
tgmath.h and newlib
Sorry if this has been discussed before, but the c99-tgmath-* tests are failing on most newlib targets. The problem is that tgmath.h unconditionally includes complex.h, which non-linux newlibs don't provide. What's the best fix? Including complex.h from tgmath.h seems reasonable on the face of it, given that both are C99 headers. So should we simply skip these tests for !c99_runtime? Or, in the absence of tgmath.h, should we try to provide tgmath.h functionality for scalar types only? Or should we not install tgmath.h on targets that don't provide complex.h (which would also imply testsuite skips)? Or something else? Richard
Re: Bug in gcc: assignment to non-lvalue
On 24/09/2007, Jonathan Adamczewski <[EMAIL PROTECTED]> wrote:
>
> What about something like the following?
>
> struct proxy {
> T& t;
> proxy(T& t_) : t(t_) {}
> proxy& operator=(const T& r) { foo(t, r); return *this; }
> };
>
> struct B { proxy get() { return proxy(bar); } };
>
> int main ()
> {
> B b;
> b.get() = 0;
> }
That is legal, 3.10 paragraph 10 says:
An lvalue for an object is necessary in order to modify the object
except that an rvalue of class type can also be used to modify its
referent under certain circumstances. [Example: a member function
called for an object (9.3) can modify the object. ]
The example I posted doesn't use any member functions, but it's not
clear what other circumstances allow it. I'm pretty sure assigning to
rvalues of builtin type shouldn't compile though.
Jon
Re: support single predicate set instructions in GCC-4.1.1
ÎâêØ wrote: (define_insn "*shift_predicate_cmp" [(set (const_int 0) (and:BI (and:BI (match_operand:BI 1 "register_operand" "c") (and:BI (match_operand:DI 2 "gr_reg_or_8bit_adjusted_operand" "rL") (match_operand:DI 3 "gr_register_operand" "r"))) (match_operand:BI 0 "register_operand" "c")))] "" "(%0) cmp.ne %1, p0 = %2, %3" [(set_attr "itanium_class" "icmp")]) it warns "WAW" and there should be stop ";;" between these two instructions. It is the assembler that is giving the warning. The assembler knows that the %1 operand is modified by the instruction, but the compiler does not, because the %1 operand is not a SET_DEST operand. Your SET_DEST is (const_int 0) which is useless info and incorrect. You need to make sure that the RTL is an accurate description of what the instruction does. Besides the problem with the missing SET_DEST, there is also the problem that you are using AND operands for a compare, which won't work. AND and NE are not interchangeable operations. Consider what happens if you compare 0x1 with 0x1. cmp.ne returns false. However, AND returns 0x1, which when truncated from DImode to BImode is still 0x1, i.e. true. So the RTL does not perform the same operation as the instruction you emitted. This could confuse the optimizer. GCC internals assume that predicate registers are always allocated in pairs, and that the second one is always the inverse of the first one. Defining a special pattern that only modifies one predicate register probably isn't gaining you much. If you are doing this before register allocation, then you are still using 2 predicate registers, as the register allocator will always give you 2 even if you only use one. Worst case, if this pattern is exposed to the optimizer, then the optimizer may make changes that break your assumptions. It might simplify a following instruction by using the second predicate reg for instance, which then fails at run-time because you didn't actually set the second predicate reg. If you are only using this in sequences that the optimizer can't rewrite, then you should be OK. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
gcc-4.1-20070924 is now available
Snapshot gcc-4.1-20070924 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20070924/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.1 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch revision 128734 You'll find: gcc-4.1-20070924.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20070924.tar.bz2 C front end and core compiler gcc-ada-4.1-20070924.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20070924.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20070924.tar.bz2 C++ front end and runtime gcc-java-4.1-20070924.tar.bz2 Java front end and runtime gcc-objc-4.1-20070924.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20070924.tar.bz2The GCC testsuite Diffs from 4.1-20070917 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: tgmath.h and newlib
This affects parisc all hpux versions except for possibly 11.31. I've experimented with not including complex.h. With a couple of other testsuite changes (complex -> __complex__), the tgmath tests behave in a semi-reasonable manner if complex arguments are avoided. However, I don't really see any major benefit in having tgmath support as even the support for scalar types is incomplete. Thus, I would be happy to see tgmath.h not installed and the tests skipped for !c99_runtime. Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
Q about assignment expansion
I'm trying to get libfortran (all_l4.c) building for m32c, and it complains (eventually) that it can't add PSI (pointer) and HI (integer) types together. I've backtracked to the statement just before it's lowered to rtl, see below. Note that pointers are PSI mode (24 bits) for this chip. My question is: Who's responsible for converting address types to pointer sizes? sstride[n] = array->dim[n].stride; unit size align 8 symtab -1208871140 alias set 3 canonical type 0xb7eba3cc precision 32 min max pointer_to_this > arg 1 arg 0 arg 1 invariant arg 0 invariant arg 0 >>> arg 5 arg 0 arg 1 > arg 6 addressable used BLK file ../../../../gcc/libgfortran/generated/all_l4.c line 50 size unit size align 16 context (mem/s/c:BLK (plus:PSI (reg/f:PSI 21 virtual-stack-vars) (const_int -84 [0xffac])) [12 sstride+0 S28 A16]) chain >> arg 1 unit size align 8 symtab -1208406160 alias set -1 canonical type 0xb7eba3cc precision 32 min max pointer_to_this > arg 1 used unsigned ignored HI file ../../../../gcc/libgfortran/generated/all_l4.c line 47 size unit size align 8 context (reg:HI 70 [ D.3718 ])> arg 4 arg 5 arg 0 arg 0 arg 0 arg 0 > arg 1 > arg 1 > arg 1 > arg 6 addressable used file ../../../../gcc/libgfortran/generated/all_l4.c line 47 context >> ../../../../gcc/libgfortran/generated/all_l4.c:69> (insn 106 105 107 ../../../../gcc/libgfortran/generated/all_l4.c:69 (set (reg:SI 156) (mem/s:SI (plus:PSI (reg:HI 70 [ D.3718 ]) (const_int 10 [0xa])) [6 .stride+0 S4 A8])) -1 (nil)) /greed/dj/m32c/gcc/m32c-elf/./gcc/xgcc -B/greed/dj/m32c/gcc/m32c-elf/./gcc/ -B/greed/dj/m32c/install/m32c-elf/bin/ -B/greed/dj/m32c/install/m32c-elf/lib/ -isystem /greed/dj/m32c/install/m32c-elf/include -isystem /greed/dj/m32c/install/m32c-elf/sys-include -DHAVE_CONFIG_H -I. -I../../../../gcc/libgfortran -I. -iquote../../../../gcc/libgfortran/io -I../../../../gcc/libgfortran/../gcc -I../../../../gcc/libgfortran/../gcc/config -I../../.././gcc -D_GNU_SOURCE -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -O2 -g -O2 -mcpu=m32cm -c ../../../../gcc/libgfortran/generated/all_l4.c -o all_l4.o
