Re: Build fail
To build a GCC corss compiler it would be good to use a specail tool that is called "crosstool". You may look at the following links: 1. http://kegel.com/crosstool/ 2. http://kegel.com/crosstool/current/doc/crosstool-howto.html On 2/9/07, Bhaskar Reddy <[EMAIL PROTECTED]> wrote: > Build binutils for i386-linux-gnu. It'll created a targeted version of as. > Hi, even it is building binutils is giving error configure line: configure --target=i386-linux-gnu make line: make ./config/tc-i386.h:530: error: array type has incomplete element type make[3]: *** [app.o] Error 1 make[3]: Leaving directory `/home/sudheer/bhaskar/mtp/binutils-2.13.1/gas' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/sudheer/bhaskar/mtp/binutils-2.13.1/gas' make[1]: *** [all-recursive-am] Error 2 make[1]: Leaving directory `/home/sudheer/bhaskar/mtp/binutils-2.13.1/gas' make: *** [all-gas] Error 2 what could be the problem? > Bhaskar Reddy bhaskar-at-cse.iitb.ac.in |gcc-help| wrote: >> Hi, >> I'm trying to build a cross compiler on i686 for i386. >> Configure Line: configure --target=i386-linux-gnu >> Make Line: make ENABLE-LANGUAGES=C >> >> My host/build system type is: i686-pc-linux-gnu >> >> But, i'm getting the following error messages: >> >> make[2]: *** No rule to make target `/usr/local/bin/i386-linux-gnu-as', >> needed by `stamp-as'. Stop. >> make[2]: Leaving directory `/home/sudheer/bhaskar/mtp/build386/gcc' >> make[1]: *** [all-gcc] Error 2 >> make[1]: Leaving directory `/home/sudheer/bhaskar/mtp/build386' >> make: *** [all] Error 2 >> >> >> How to fix it? >> >> thanks in advance. >> >> > > -- Bhaskar G. Reddy, Graduate Student, Department of CSE, IIT Bombay -- Ferad Zyulkyarov Barcelona Supercomputing Center
Re: Build fail
Ferad Zyulkyarov wrote : To build a GCC corss compiler it would be good to use a specail tool that is called "crosstool". You may look at the following links: 1. http://kegel.com/crosstool/ 2. http://kegel.com/crosstool/current/doc/crosstool-howto.html Everyone always building the target Linux system oneself from absolute scratch? Or that everyone should always do this thing, never use any existing Linux distros for anything? Oh you great guru tell your bright idea to us who have used only existing Linux distros and have made crosstoolchains only for existing Linuces using their existing original thoroughly tested components, what is the wisdom behind all this "from absolute scratch always" suggestion! The late 1800 and early 1900 thinkers like Marx & Engels, V.I.Lenin etc. seemingly had similar ideas about the necessity to start everything from absolute scratch as Mr. Kegel nowadays... Ok, the traditional "evolutionary" method is to not reinvent the wheel with the already tested target components but let then be as they are and produce only the stuff required for the new $host, the GNU binutils and the GCC sources. NOT the target C libraries because they already are there for the existing targets! The Kegel's idealism says that also all these MUST be built with the new GCC. The glibc, the X11 libraries, the Gnome libraries, the KDE libraries, the termcap, the ncurses, Horrible "bolshevism/bullshitism" I would say
Re: Build fail
Hi Kai, I agree that the things I wrote does not have much sense for people that spent years in developing GCC, like you and most of the people here are. I am very very very new in both using gcc and in its internals. The first time when I was building cross platform gcc I really did it from the scratch, not because of any philosophical and idealistic views, but the reason was quite simple and really stupid - I just didn't know about the "crosstool" animal. The gcc mailing list was quite helpful for me, and my intention posting this message was to help, as you did to me. Ferad On 2/9/07, Kai Ruottu <[EMAIL PROTECTED]> wrote: Ferad Zyulkyarov wrote : > To build a GCC corss compiler it would be good to use a specail tool > that is called "crosstool". You may look at the following links: > > 1. http://kegel.com/crosstool/ > 2. http://kegel.com/crosstool/current/doc/crosstool-howto.html Everyone always building the target Linux system oneself from absolute scratch? Or that everyone should always do this thing, never use any existing Linux distros for anything? Oh you great guru tell your bright idea to us who have used only existing Linux distros and have made crosstoolchains only for existing Linuces using their existing original thoroughly tested components, what is the wisdom behind all this "from absolute scratch always" suggestion! The late 1800 and early 1900 thinkers like Marx & Engels, V.I.Lenin etc. seemingly had similar ideas about the necessity to start everything from absolute scratch as Mr. Kegel nowadays... Ok, the traditional "evolutionary" method is to not reinvent the wheel with the already tested target components but let then be as they are and produce only the stuff required for the new $host, the GNU binutils and the GCC sources. NOT the target C libraries because they already are there for the existing targets! The Kegel's idealism says that also all these MUST be built with the new GCC. The glibc, the X11 libraries, the Gnome libraries, the KDE libraries, the termcap, the ncurses, Horrible "bolshevism/bullshitism" I would say
Any hints on this problem? Thanks!
Hi, I am working on gcc-4.1.1 and Itanium architecure. Today I try to add a function call before each ld instruction. The method I use to achieve this goal is to modify final_scan_insn() in final.c: before calling get_insn_template, I add codes to check whether the insn matches a template that will emit ld instruction, then I use emit_library_call to emit new insns and output them by calling final_scan_insn() again. Now,the modified gcc is successfully builded and when I use it to compile a program, I observe that it successfully intercept each ld instruction and add the desired function call before them. But the problem comes, when I run the modified program compiled by the hacked gcc, it crashes due to segment fault. I use gdb to debug the program, and observe that the fault is due to this: originally, what I want to do is ld r14=[r14], and r14 contains the correct address, but in my inserted function call, say FOO, it modifies r14 to 0, and when the program returns from FOO and load from r14 again, it crashes, undoubtedly. Here is a concrete example, just a very simple one to illstrate the situation: ~~~ old code: : ... ld r14=[r14] ... ~~~ ~~~ new code: : ... mov r14=0 ... : ... br.call FOO ld r14=[r14]/* CRASH! */ ... ~~~ Now, my question becomes clear. How to make my inserted function call not affect the orginal state of program? Further more, if I add more instructions (not only a function call), how can I keep the that state? Is there a general way to do this? Any hints on this problem will be *truely* appreciated. Thanks! Best Regards Andy.Wu
Re: Any hints on this problem? Thanks!
"吴曦" <[EMAIL PROTECTED]> writes: > Now, my question becomes clear. How to make my inserted function call > not affect the orginal state of program? Make sure that the called function restores the original state of the program before it returns. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Any hints on this problem? Thanks!
Make sure that the called function restores the original state of the program before it returns. Andreas. Thanks~. I know the goal is to restore the original state before the inserted function returns. BUT, how to? Is there any way to tell gcc: "Hey, you should restore the original state before that function returns". I want hints on how to and the existing interfaces in gcc to do this :-).
gcc 3.4.4 miscompiles eCos
Hello all
(I am not subscribed to the list, please cc all replies)
I am cross-building the RedBoot bootloader (a part of the eCos project)
for a PXA270 target. I can successfully build it with gcc 3.3.2, but if
the same sources are compiled with 3.4.4, it crashes. The project is
mostly in C with some asm parts and C++... I traced the crash down to a
loop in a C file where they call various initialisation functions... which
actually are C++ constructors... Using some linker magic
__CTOR_LIST__ = ABSOLUTE (.); KEEP (*(SORT (.ctors*))) __CTOR_END__ = ABSOLUTE
(.); \
they build a list of C++ constructors and then call then one after the
other (see (*) code excerpt below).
Now, up to some gcc version there has been a -finit-priority option, which
was also used in eCos. As this option disappeared, having become silent
default, it worked also without it... with 3.4.4 no longer. Binutils
version used with 3.4.4 is 2.15.96.
Is there a way to get it to work with 3.4.4? Preferrably without patching
compiler sources / rebuilding it. And whose bug is this - gcc or eCos?
Thanks
Guennadi
-
Guennadi Liakhovetski, Ph.D.
DSA Daten- und Systemtechnik GmbH
Pascalstr. 28
D-52076 Aachen
Germany
* calling C++ constructors:
typedef void (*pfunc) (void);
extern pfunc __CTOR_LIST__[];
extern pfunc __CTOR_END__[];
void
cyg_hal_invoke_constructors (void)
{
#ifdef CYGSEM_HAL_STOP_CONSTRUCTORS_ON_FLAG
static pfunc *p = &__CTOR_END__[-1];
cyg_hal_stop_constructors = 0;
for (; p >= __CTOR_LIST__; p--) {
diag_printf("Invoking constructor @ 0x%08x\n", *p);
(*p) ();
if (cyg_hal_stop_constructors) {
p--;
break;
}
}
#else
pfunc *p;
for (p = &__CTOR_END__[-1]; p >= __CTOR_LIST__; p--) {
diag_printf("Invoking constructor @ 0x%08x\n", *p);
(*p) ();
}
#endif
}
Re: Any hints on this problem? Thanks!
Re: Any hints on this problem? Thanks!
Andy, you must handle the calling convertion when inserting a function call. It includes the saving and restoring of caller registers and the proper passing of params. On 2/9/07, Andrew Haley <[EMAIL PROTECTED]> wrote: �NbjX writes: > > > > Make sure that the called function restores the original state of the > > program before it returns. > > > > Andreas. > Thanks~. I know the goal is to restore the original state before the > inserted function returns. BUT, how to? Is there any way to tell gcc: > "Hey, you should restore the original state before that function > returns". I want hints on how to and the existing interfaces in gcc > to do this :-). He's telling you that you have to do it yourself, in the code that you just inserted. Andrew. -- Paul Yuan www.yingbo.com
Re: Build fail
Kai Ruottu <[EMAIL PROTECTED]> writes: > Ok, the traditional "evolutionary" method is to not reinvent the wheel > with the already tested target components but let then be as they are > and produce only the stuff required for the new $host, the GNU > binutils and the GCC sources. NOT the target C libraries because > they already are there for the existing targets! The Kegel's idealism > says that also all these MUST be built with the new GCC. The glibc, > the X11 libraries, the Gnome libraries, the KDE libraries, the termcap, > the ncurses, Horrible "bolshevism/bullshitism" I would say What in the world are you talking about? crosstool is a one stop shop for people who don't want to figure out how everything fits together. Given that, it clearly must build the target libraries. It can't assume that they already exist. I'm sorry crosstool doesn't fit your philosophical notions (which are, moreover, incorrect as stated). If you have something substantive to say about crosstool--like, say, it doesn't work, or doesn't do what people want--then say that. Ian
Re: gcc 3.4.4 miscompiles eCos
On Fri, 9 Feb 2007, Guennadi Liakhovetski wrote: Now, up to some gcc version there has been a -finit-priority option, which was also used in eCos. As this option disappeared, having become silent default, it worked also without it... with 3.4.4 no longer. Binutils version used with 3.4.4 is 2.15.96. Sorry, it seems to be another problem. I'll post more next week. Thanks Guennadi - Guennadi Liakhovetski, Ph.D. DSA Daten- und Systemtechnik GmbH Pascalstr. 28 D-52076 Aachen Germany
Re: Fw: Scheduling an early complete loop unrolling pass?
Ayal Zaks/Haifa/IBM wrote on 07/02/2007 23:17:54: > ... > > >Ah, right... I wonder if we can keep the loop structure in place, even > >after completely unrolling the loop - I mean the 'struct loop' in > >'current_loops' (not the actual CFG), so that the "SLP in loops" would have > >a chance to at least consider vectorizing this "loop". > Having a "loop" structure for a piece of CFG that is not a loop, was > used in some other compiler we worked with - the notion of 'region' > was such that it corresponded to loops, and in addition the entire > function belonged to a "universal" region (Peter - please correct if > I'm wrong). But I think you were looking for some marking of a basic > block saying "this used to be a loop but got completely unrolled". I > wonder how much such a "dummy" loop structure can really help the > vectorizer, except for (convenience of) keeping intact the driver > that traverses all such structures or the hanging of additional data > off of them. > yes, the idea was just to save time in looking for such occurrences, and leverage our loop-based-slp. Indeed, there may be user-unrolled code and other occurrences for which this trick won't help, and as stated earlier, we probably shouldn't care too much about these cases anyhow. We can play with this idea at some later point when loop-based-slp is in place. thanks, dorit > Ayal.
meaning of --enable-checking flags
The doc on --enable-checking at: http://gcc.gnu.org/install/configure.html contains: --enable-checking=list and implies that list may either be a category (yes,all,release,no) or a sequence of flags (e.g. fold,gcac,gc,valgrind); however, it doesn't describe what the flags mean. Could someone do that or provide a link to the descriptions. Based on: http://gcc.gnu.org/ml/gcc/2007-01/msg01234.html I guess fold doesn't work. I did try: --enable-checking=assert,misc,tree,gc,gcac,rtlflag,runtime,valgrind but the compile of the compiler was taking way too long. I need a way to track down what's causing an ICE in Gregor's variadic template compiler. When just using --enable-checking=yes, I was able to use gdb to find that the value of __FILE__ was corrupted: (gdb) up #1 0x0809e6eb in tsubst (t=0x4034f8a0, args=0x40351ca8, complain=3, in_decl=0x4032eea0) at ../../gcc-4.1.1/gcc/cp/pt.c:8095 (gdb) down #0 fancy_abort (file=0xdc , line=8218, function=0xdc ) at ../../gcc-4.1.1/gcc/diagnostic.c:602 (gdb) p *file Cannot access memory at address 0xdc (gdb) Could someone provide a suggestion about what value of --enable-checking to use to help find the problem? TIA. -regards, Larry
Re: ICE in gcc/libgcc2.c:566 (gcc trunk)
On 07 Feb 2007 15:36:14 -0800
Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> Hanno Meyer-Thurow <[EMAIL PROTECTED]> writes:
>
> > sorry to bother again. I reduced the code (attached) that segfaults here
> > on Core 2 Duo [1]. If I add -fno-split-wide-types the code does not
> > segfault.
> > That flag comes from your patchset [2].
>
> I don't know what is causing this. I just checked again, and it does
> not happen for me.
Now I tried gcc trunk rev. 121750 with 'make bootstrap'. It still fails.
Though, I have a smaller piece of code (attached) that segfaults.
Any idea where to look for TItype / TI mode for nocona arch?
ana gcc # ./cc1 -fsplit-wide-types test.c -o test.o
__negti2
test.c: In function ‘__negti2’:
test.c:7: internal compiler error: Speicherzugriffsfehler
Please submit a full bug report,
with preprocessed source if appropriate.
See http://bugs.gentoo.org/> for instructions.
ana gcc # ./cc1 -fno-split-wide-types test.c -o test.o
__negti2
Execution times (seconds)
life info update : 0.01 (100%) usr 0.00 ( 0%) sys 0.01 (50%) wall
0 kB ( 0%) ggc
TOTAL : 0.01 0.00 0.02
2256 kB
Regards,
Hanno
typedef int TItype __attribute__ ((mode (TI)));
TItype
__negti2 (TItype u)
{
return u;
}
Re: Inserting profiling function calls
Hi, Patrice,
I don't know about inserting call at the basic block level, but I am
quite sure inserting calls at the function level could be done by
aspect-oriented-programming (AOP).
For example, we used our project, AspectC compiler (www.aspectc.net), to
weave in following aspect into gcc,
#include
before():call($ $(...)){
fprintf(stderr, "%s\n", this->funcName);
}
What it does is just to print out name of every functions called inside
gcc during execution time.
Our experiment shows that gcc makes 637929 function calls in order to
compile following program into machine code:
#include
void main(){
char *cool = "cool";
printf("%s\n",cool);
}
And the function names, ordered by calling sequence, are :
---
main
xmalloc_set_program_name
unlock_std_streams
unlock_1
unlock_1
unlock_1
gcc_init_libintl
alloc_args
xmalloc
xmalloc
xmalloc
xmalloc
process_command
xstrdup
xmalloc
make_relative_prefix
lbasename
lrealpath
split_directories
save_string
save_string
save_string
save_string
save_string
save_string
split_directories
..
maybe_unlink
unlink_if_ordinary
lstat
pex_free
pex_unix_cleanup
delete_temp_files
delete_if_ordinary
stat
delete_if_ordinary
stat
--
This is just a simple aspect. More advanced aspect, like memory
profiling, can be easily done by AOP. The cool thing is that those extra
code is totally modularized in aspect, ie. not a single piece of code
will go into gcc code base.
Just an alternative.
Thanks.
Mike
- Original Message -
From: "GERIN Patrice" <[EMAIL PROTECTED]>
To: "Jan Hubicka" <[EMAIL PROTECTED]>
Cc:
Sent: Thursday, February 08, 2007 5:56 PM
Subject: Re: Inserting profiling function calls
Would you for a start please
explain what do you need to do that can't be done using existing arc
and
value profiling?
Sorry, my first mail was not clear about the goal.
Objectives are to follow the execution of function and basic block at
execution time.
To do this, we plan to insert function call, like mcount is inserted
at the function level for gprof but at the basic block level.
A user library linked with the application can then implement this
functions.
Thank you,
Patrice
___
Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et
son interface révolutionnaire.
http://fr.mail.yahoo.com
Re: Any hints on this problem? Thanks!
?? wrote: Now, my question becomes clear. How to make my inserted function call not affect the orginal state of program? Try looking at a similar feature. One such similar feature is the mcount calls emitted for profiling. The various solutions for mcount include 1) saving lots of registers before the call, and restoring lots of registers after the call. This has a high cost which may not work in your case. 2) Writing mcount in assembly language, so that you can avoid clobbering any registers. Another possible solution is to use special compiler options when compiling the function. For instance -fcall-saved-r14 will tell gcc that r14 must be saved/restored in the prologue/epilogue when used. If you split your instrumentation function into a separate file, and compile with special options, this might work. You will need to use such an option for every normal call clobbered register. There are quite a few of them. Another solution is to add the instrumentation earlier, and use expand_call. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: Inserting profiling function calls
> > >Would you for a start please > >explain what do you need to do that can't be done using existing arc and > >value profiling? > > > Sorry, my first mail was not clear about the goal. > Objectives are to follow the execution of function and basic block at > execution time. > To do this, we plan to insert function call, like mcount is inserted > at the function level for gprof but at the basic block level. > A user library linked with the application can then implement this > functions. Hi, interesting, I guess you want to generate some sort of traces through programs or path profiles. This is definitly doable and I think best place to do so would be same time as value range profiling is done (that is also inserting calls but for different reasons, so you probably might want to look into it). Ironically, we used to have such basic block profiling but the implementation was removed in favour of edge profiling years ago be me (the implementation however was broken and would need to be reimplemented anyway). It would be interesting to get infrastructure for path profiling as described in Ball&Larus paper http://citeseer.ist.psu.edu/ball96efficient.html that is what some compilers implement. I din't get across implementing it since I don't see much of use for in in optimization (however if you look at the followup papers, there are some code duplication based ideas that might prove to be effective) Honza > > Thank you, > Patrice > > > > > > ___ > Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son > interface révolutionnaire. > http://fr.mail.yahoo.com
US Daylight Savings Time Changes
Greetings, Are there any gcc-related issues with the upcoming changes to the Daylight Savings Time switch in the US starting this year? That is, will programs compiled with the gcc (excluding any third-party libraries) have any time-related issues this year? If so, are certain versions of gcc 2007-US-DST-change compliant and other versions not? I assume that gcc-compiled apps just get their time from the OS, so provided the OS is 2007-US-DST-change compliant then it will be OK, but need to verify. much appreciated, David Karnowski
Re: US Daylight Savings Time Changes
On Fri, Feb 09, 2007 at 03:52:54PM -0500, Karnowski, David wrote: > Are there any gcc-related issues with the upcoming changes to the > Daylight Savings Time switch in the US starting this year? That is, will > programs compiled with the gcc (excluding any third-party libraries) > have any time-related issues this year? If so, are certain versions of > gcc 2007-US-DST-change compliant and other versions not? It's a library issue, not a compiler issu. > I assume that gcc-compiled apps just get their time from the OS, so > provided the OS is 2007-US-DST-change compliant then it will be OK, but > need to verify. The details are OS-dependent.
Re: US Daylight Savings Time Changes
Joe Buck wrote: On Fri, Feb 09, 2007 at 03:52:54PM -0500, Karnowski, David wrote: Are there any gcc-related issues with the upcoming changes to the Daylight Savings Time switch in the US starting this year? That is, will programs compiled with the gcc (excluding any third-party libraries) have any time-related issues this year? If so, are certain versions of gcc 2007-US-DST-change compliant and other versions not? It's a library issue, not a compiler issu. GCC does however ship with libgcj the java runtime library. Some versions of libgcj may not be aware of this change. David Daney
Re: Any hints on this problem? Thanks!
> ?? wrote: > >Now, my question becomes clear. How to make my inserted function call > >not affect the orginal state of program? > > Try looking at a similar feature. One such similar feature is the > mcount calls emitted for profiling. The various solutions for mcount > include > 1) saving lots of registers before the call, and restoring lots of > registers after the call. This has a high cost which may not work in > your case. > 2) Writing mcount in assembly language, so that you can avoid clobbering > any registers. Actually I would say that copying mcount code would be dificult (because we need to emit the calls at arbitrary basic blocks rather than in prologue) and not very maintanale. I belive that it would be better to simply insert the calls at gimple level like edge/value profiling is done. Using custom calling conventions to speed process up might be interesting, I guess it can be done via target hook+attribute but I would leave it for later time. Honza
GCC 4.1.2 RC2
GCC 4.1.2 RC2 is now available from: ftp://gcc.gnu.org/pub/gcc/prerelease-4.1.2-20070208 and its mirrors. The changes relative to RC1 are fixes for: 1. PR 29683: a wrong-code issue on Darwin 2. PR 30370: a build problem for certain PowerPC configurations 3. PR 29487: a build problem for HP-UX 10.10 a code-quality problem for C++ on all platforms If you find problems in RC2, please file them in Bugzilla. For any issues which are regressions relative to 4.1.1 or 4.1.0, please alert me by email, referencing the Bugzilla PR number. Please do not send me email before filing a PR in Bugzilla. Based on the absence of issues reported for GCC 4.1.2 RC1, I expect GCC 4.1.2 to be identical to these sources, other than version numbers, and so forth. I intend to spin the final release early next week. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
gcc-4.3-20070209 is now available
Snapshot gcc-4.3-20070209 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20070209/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 121777 You'll find: gcc-4.3-20070209.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20070209.tar.bz2 C front end and core compiler gcc-ada-4.3-20070209.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20070209.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20070209.tar.bz2 C++ front end and runtime gcc-java-4.3-20070209.tar.bz2 Java front end and runtime gcc-objc-4.3-20070209.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20070209.tar.bz2The GCC testsuite Diffs from 4.3-20070202 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 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.
GCC mirror set up in Germany
Hi there, first of all let me thank you for the service you provide with GCC.GNU.org! To support your efforts we put up a mirror on our website Cybermirror.org under http://gcc.cybermirror.org. The server is based in Karlsruhe, Germany and daily updated (cron). Please let me know if it is appreciated. Cheers, Sascha
Re: US Daylight Savings Time Changes
> "David" == David Daney <[EMAIL PROTECTED]> writes: >>> Are there any gcc-related issues with the upcoming changes to the >>> Daylight Savings Time switch in the US starting this year? David> GCC does however ship with libgcj the java runtime library. Some David> versions of libgcj may not be aware of this change. David probably knows this, but for others, Jakub and Andrew put in a patch for this today. I think it is only on trunk, not any other branches. Tom
Re: Any hints on this problem? Thanks!
Another solution is to add the instrumentation earlier, and use expand_call.
Thanks for your hints. Is that means doing intrumentation at the "RTL
expand" level? However, I have tried the following method, add a
defined_expand in ia64.md, the template used in define_expand is the
same as the one which will emit a ld instruction, just like this one:
~~
;; expand the ld operation with check code if user turns on
;; fld-checking
(define_expand "gift_load_symptr_low"
[(set (match_operand:DI 0 "register_operand" "=r")
(lo_sum:DI (match_operand:DI 1 "register_operand" "r")
(match_operand 2 "got_symbolic_operand" "s")))]
""
{
if(flag_ld_checking)
{
printf("gift_load_symptr_low emits checking function call\n");
emit_library_call(gen_rtx_SYMBOL_REF(Pmode,
\"gift_check_bitmap\"), 0, VOIDmode, 0);
emit_insn (gen_rtx_SET (VOIDmode,
operands[0],
gen_rtx_LO_SUM (DImode,
operands[1],
operands[2])));
}
DONE;
})
~~
BUT, when I use the newly builded compiler to compile my program,
nothing matched to expand such ld instruction ...
problem building gcc4-4.3.0-20070209
While building the gcc4-4.3.0-20070209 snapshot, I got the error ... checking for correct version of gmp.h... no configure: error: Building GCC requires GMP 4.1+ and MPFR 2.2.1+. ... I am using the same script that worked last week and I have gmp 4.2.1 and mpfr 2.2.1 since several builds. I am using a Mac OSX 10.3.9. Can someone give me a pointer the change(s) that might explain the breakage. TIA Dominique
Re: Any hints on this problem? Thanks!
On Sat, 2007-02-10 at 07:45 +0800, 吴曦 wrote: > Thanks for your hints. Is that means doing intrumentation at the "RTL > expand" level? expand_call is a function in the calls.c file. It knows how to do function calls correctly. If you use this, then registers will be saved and restored correctly. > However, I have tried the following method, add a > defined_expand in ia64.md, the template used in define_expand is the > same as the one which will emit a ld instruction, just like this one: A define_expand is used only for creating RTL. This define_expand will be used only if someplace else has "gen_gift_load_symptr_low (...);". A define_expand is not used for matching instructions. So if you have a define_expand emitting some RTL, then someplace else there must be a define_insn that matches it. You will need to learn a lot more about gcc internals to get this working. It is probably simpler to just write your instrumentation function in assembly code. Or maybe compile it to assembly, and then fix it by hand. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: problem building gcc4-4.3.0-20070209
On Sat, Feb 10, 2007 at 12:56:13AM +0100, Dominique Dhumieres wrote:
> While building the gcc4-4.3.0-20070209 snapshot, I got the error
>
> ...
> checking for correct version of gmp.h... no
> configure: error: Building GCC requires GMP 4.1+ and MPFR 2.2.1+.
> ...
>
> I am using the same script that worked last week and I have
> gmp 4.2.1 and mpfr 2.2.1 since several builds. I am using
> a Mac OSX 10.3.9. Can someone give me a pointer the change(s)
> that might explain the breakage.
You need to show us your configure arguments to be sure. I bet
you're specifying just --host.
I don't know exactly what to do about this. It's caused by:
if test ${build} != ${host}; then
some defaults
else
AC_PROG_CC
fi
AC_TRY_COMPILE
ac_objext is set at the expansion of AC_PROG_CC and if you take the if
branch, it never gets set.
Does anyone reading this know what the right thing to do is? Is there
anything in the autoconf documentation about not using some macros
inside conditional statements?
--
Daniel Jacobowitz
CodeSourcery
Division by zero
Hi,
Division by zero is undefined. We chose to keep it:
http://gcc.gnu.org/ml/gcc-patches/2001-06/msg01068.html
But now gcc seems to optimize it away. For the following function:
$ cat t.c
#include
void foo (int rc)
{
int x = rc / INT_MAX;
x = 4 / x;
}
$ gcc -O2 -S t.c
$ cat t.s
.file "t.c"
.text
.p2align 4,,15
.globl foo
.type foo, @function
foo:
pushl %ebp
movl%esp, %ebp
popl%ebp
ret
.size foo, .-foo
.ident "GCC: (GNU) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)"
.section.note.GNU-stack,"",@progbits
Does we now choose to optimize it away now?
Jie
Re: US Daylight Savings Time Changes
> Tom Tromey writes: Tom> David probably knows this, but for others, Jakub and Andrew put in a Tom> patch for this today. I think it is only on trunk, not any other Tom> branches. Should this be included in GCC 4.1.2? David
Re: Division by zero
"Jie Zhang" <[EMAIL PROTECTED]> writes:
> But now gcc seems to optimize it away. For the following function:
>
> $ cat t.c
> #include
> void foo (int rc)
> {
> int x = rc / INT_MAX;
> x = 4 / x;
> }
I believe we still keep division by zero in general. In your example
it gets optimized away because it is dead code. Nothing uses x.
Ian
Re: GCC 4.1.2 RC2
On Fri, Feb 09, 2007 at 01:36:00PM -0800, Mark Mitchell wrote: > GCC 4.1.2 RC2 is now available from: > > ftp://gcc.gnu.org/pub/gcc/prerelease-4.1.2-20070208 OK, I untarred it, built, and tested. I have test results for all languages except Ada, for RHEL 3 (ancient, but with binutils-2.17), on a 32-bit and 64-bit x86. i686-pc-linux-gnu results are at http://gcc.gnu.org/ml/gcc-testresults/2007-02/msg00367.html (no failures). x86_64-unknown-linux-gnu results are at http://gcc.gnu.org/ml/gcc-testresults/2007-02/msg00350.html and there is only one failure, a Java test: FAIL: FileHandleGcTest -O3 execution - bytecode->native test
Re: US Daylight Savings Time Changes
On Sat, Feb 10, 2007 at 12:49:56AM -0500, David Edelsohn wrote: > > Tom Tromey writes: > > Tom> David probably knows this, but for others, Jakub and Andrew put in a > Tom> patch for this today. I think it is only on trunk, not any other > Tom> branches. > > Should this be included in GCC 4.1.2? I think so. I'm glad someone raised the issue. For GNU/Linux and BSD-based systems, languages other than Java use data files for time zone changes, so you'd need to check if your tzdata package is new enough (use Google to find out how). I'm surprised to learn that Java does it a different way. Are we really shipping time zone information in gcc? Doesn't it change every month or so (when considering the 180 or so countries in the world)?
