Re: Unwinding through exception handlers when PC is NULL.
On 06/05/11 02:24, David Daney wrote: > This happens because the libgcc unwinder cannot find unwinding > information for the PC at the point of the SIGSEGV. > > However, we know that usually when we end up with a PC of zero, it is > because we called through a NULL function pointer. In this case, we > could use the return address (perhaps with a slight adjustment to > compensate for the call instruction) to do the unwinding. > > Would it make any sense to build something like this into libgcc? > > Or if we want to do this do we need to patch up the register state > before executing the throw? This isn't really an either/or. It makes sense to robustify all that code so it does not segv. Andrew.
Re: gcc detect multiple -o passed on one command line
On 06/05/2011 09:00, Andreas Schwab wrote: > Ian Lance Taylor writes: > >> The difference is that with -E the -o option is passed to cc1, whereas >> without it the -o option is passed to the assembler or the linker. The >> GNU assembler and linker both have the usual Unix behaviour of only >> using the last -o option. > > Nevertheless it might be a good idea to file a bug for binutils. > Consistency is probably more important, and it helps in case of typos. In this case, I don't think consistency should win over maintaining long-established behaviour. I'm more inclined to say that cc1 should change to follow long-established *nix tradition. (I have absolutely found it useful on at least one occasion to be able to add a -o option into CFLAGS and know it would come last on the command-line and win.) cheers, DaveK
Re: [gimplefe] Merge from trunk rev 173770
On Fri, May 6, 2011 at 2:16 AM, Diego Novillo wrote: > This merge brings the gimple-front-end branch up to 4.7. It needed > some minimal adjustments, but things seem to be working. Sandeep, > please make sure it does. You may need to rebase your patch before > committing it. > I got the build working on my machine. So preliminarily things seem to be working. In case this merge brings our branch up to 4.7 should "gcc -v" be showing it? It is not currently. > We need some tests in testsuite/gimple. Sandeep, do you think you > could add some? If you need a hand with dejagnu, let me know. We > still cannot generate code, but we should start adding some minimal > parsing tests. > Sure. I will see how dejagnu works since I have no prior experience using it. I will try adding some testcases to the testsuite. -- Cheers Sandy
Re: [gimplefe] Merge from trunk rev 173770
On Sat, May 7, 2011 at 16:50, Sandeep Soni wrote: > I got the build working on my machine. So preliminarily things seem to > be working. In case this merge brings our branch up to 4.7 should "gcc > -v" be showing it? It is not currently. Yes, gcc -v should show: Using built-in specs. COLLECT_GCC=bin/gcc COLLECT_LTO_WRAPPER=/usr/local/google/home/dnovillo/gimplefe/svn/native/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.7.0-gimplefe/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /home/dnovillo/gimplefe/svn/src/configure --prefix=/home/dnovillo/gimplefe/svn/native --enable-languages=gimple Thread model: posix gcc version 4.7.0-gimplefe 20110502 (trunk r173270) (experimental) (GCC) Note that to get version output, you should use --version. > Sure. I will see how dejagnu works since I have no prior experience > using it. I will try adding some testcases to the testsuite. Great. Let me know if you get stuck. In principle, you'd have to copy from gcc/testsuite/gcc.dg. Create a directory gcc/testsuite/gimple.dg and adapt gcc/testsuite/gcc.dg/dg.exp. There will be wrinkles, I'm sure. Diego.
gcc-4.7-20110507 is now available
Snapshot gcc-4.7-20110507 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.7-20110507/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 173537 You'll find: gcc-4.7-20110507.tar.bz2 Complete GCC (includes all of below) MD5=e073ba989e3c51a4202a9aba76f8af7a SHA1=7b6cf8c90add1ece7cf8d1226a321febb9da64bc gcc-core-4.7-20110507.tar.bz2C front end and core compiler MD5=5c90ef9e0e612eada5c08948234b0531 SHA1=4709d9b27e81d56382dc5a1d5ac985bc730f3671 gcc-ada-4.7-20110507.tar.bz2 Ada front end and runtime MD5=5d60b93b2113216bebc70f98720545cd SHA1=f19ef9a59fc10fbe3baf13f9aa9a160d68b35a9e gcc-fortran-4.7-20110507.tar.bz2 Fortran front end and runtime MD5=79aa780a6899c79aefd07176c0d5e92c SHA1=fdbc51586fd16411eaae490bf4a2026e3d17e92a gcc-g++-4.7-20110507.tar.bz2 C++ front end and runtime MD5=634e92d31ce032fd42f43e3321522012 SHA1=7ef5be0cbe5e33deb383be55a5312d6fbe003d95 gcc-go-4.7-20110507.tar.bz2 Go front end and runtime MD5=bf3e98754582a0f7779f4ee9cdf8 SHA1=9962846d098a5e2882492172e909b4230494491b gcc-java-4.7-20110507.tar.bz2Java front end and runtime MD5=29f7c518aa27b4eab9f2f12488e9af8e SHA1=67ff7d1f24fd594359ed5a9fb2c8e2a9e991101c gcc-objc-4.7-20110507.tar.bz2Objective-C front end and runtime MD5=123a87c4c1e16a683b237410967bc1cc SHA1=ad0ed78088b12311c6a22f6bfad287706df2259e gcc-testsuite-4.7-20110507.tar.bz2 The GCC testsuite MD5=26d418d0ff03283224136c55e8cdcf07 SHA1=4a4bdc9fa5a02020ee4f338a0b2f7fe30bbb98b6 Diffs from 4.7-20110430 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.7 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.
question on arm soft-fp function __aeabi_d2uiz
Hi,
I found in gcc/config/arm/ieee754-df.S, the function __aeabi_d2uiz
converts double into unsigned integer and the function always return 0
if the double value is negative. for example the following codes:
---sample codes--
unsigned long ul;
double d = -1.1;
int main(void)
{
ul = (unsigned long)d;
fprintf (stdout, "ul = 0x%X\n", ul);
return 0;
}
the output of __aeabi_d2uiz on arm soft-fpu is 0x0, resulting in
different behaviors between "(unsigned int)(int)d" and "(unsigned
int)d".
I also tried the code on x86-cygwin, which prints 0x.
I am wondering why __aeabi_d2uiz returns 0 for negative double values.
Is this behavior defined by arm fpu and it's different with x86 in fpu
implementation?
I have no arm fpu platform to verify this question and have know
little about float porints, So any clarification?
Thanks very much.
--
Best Regards.
