URGENT ATTENTION
Dear Sir On behalf of the board and management of Overseas Credit Commission(OCC). London UK, I Mr Ayo West, the Operations Manager wishes to inform you that your consignment/fund tagged diplomatic lugagge 122 with Ref:No1226/X42/206 which was deposited in our vault for safe keeping by a Diplomatic courier company(BaxGlobal)is due for Immediate collection.Be informed that we have concluded all arrangments to deliver your consignment at yout doorstep through diplomatic means.In line with the binding diplomatic consignment delivery policies, kindly furnish us with the following as set forth. . A copy of your international passport or any other means of identification as the true consignee. .The address where the above cargo/funds should be delivered to and your phone number. . List the nearest international airport to your address location. Meanwhile, we urge you to treat the above requirement with utmost urgency to enable us dispense our duties and obligation accordingly thereby allowing us to serve you in a timely fashion. Upon satisfactory receipt of all the above mentioned, you Will be further acquainted with the detailed delivery itinerary including information of the diplomat who will accompany your consignment. As always, feel very free to contact us should you have any further question as our customers rights are continuously protected. We pledge our best service at all times. Yours Sincerely Ayo West Foreign Operations Manager
Re: tuples: call for help
On 5/7/07, Aldy Hernandez <[EMAIL PROTECTED]> wrote: Hi Dan. Hi folks. People (ok, so it was Dan) had asked if there was anything they could do to help the tuples effort. The pretty print routines could definitely use a lot of cases (dump_gimple_stmt), and the work is very self contained. So I took a look at this the other day, and you seem to have at least every case that has accessors. Did you want me to write accessors for the other types and then add them to pretty-print?
Re: backport of Revision 120684 for Macintel into gcc 4.2.1?
Andreas, I have posted my results for backporting r120684, 120801, 120853, 120874 and 120977 to gcc 4.2.0 onto gcc-testresults for i686-apple-darwin8 and powerpc-apple-darwin8... http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg00822.html http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg00849.html I only saw 25 libjava failures on i686-apple-darwin8 with the backports (all of which already exist in gcc 4.2.0 so no regressions occur). Interestingly, in both tests I have done with the r120684 backport, this also seems to eliminate the Thread_Sleep_2 libjava testsuite failures that we see on powerpc-apple-darwin8 with stock gcc 4.2.0... http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg00756.html Can you backport r120684, 120801, 120853, 120874, 120977 to gcc 4.2.1 branch please? Mike and Eric both think this is a good idea. Thanks in advance. Jack On Thu, May 17, 2007 at 09:23:22PM +0200, Andreas Tobler wrote: > > I have backported r120684, 120801, 120853, 120874, 120977 and I do not > see any failure on Process_#. > > I have the same failures as you have (except Process_#). The Throw_2 is > due to missing signal handling stuff in gcc and libjava. The others I > did not investigate. I gave up testing libjava on i?86-darwin since I > lack a working ld64 > > These are the results: > > === libjava Summary === > > # of expected passes6962 > # of unexpected failures26 > # of expected failures 12 > # of untested testcases 26 > > Andreas >
mudflap - does anyone else get many exceptions?
This is probably an issue only with multithreaded programs. For a long time now I found a need to apply a private patch to mf-runtime.c so that it does not report access to envp[] as a violation. I now built gcc-4.2.0 and gcc-current and found that I still need this patch for both. The small patch simply moves the registration of standard items (environ, stdin, etc.) from wrap_main() to __mf_init(). I also needed to add a wrapper for strerror_r(). Do other people encounter this problem? How do you solve this? patch is here: http://members.iinet.net.au/~eyaleb/gcc-current-libmudflap-20070518.patch.bz2 -- Eyal Lebedinsky ([EMAIL PROTECTED]) <http://samba.org/eyal/> attach .zip as .dat
Re: How do you get the benefit of -fstrict-aliasing?
On Apr 21, 2007, at 6:01 PM, Bradley Lucier wrote: So I'm wondering whether certain options have to be included on the command line to get the benefits of -fstrict-aliasing. I've thought about this question a bit more, so maybe I can make it less content-free. The C code generated by Gambit-C, the Scheme->C compiler, has certain somewhat strange characteristics, mainly because it's targeted to a simulated virtual machine implemented using C macros. Experimental results show that simply using gcc -O2 or -O3 results in significantly suboptimal code; gcse generally makes the code noticeably worse, for example. So we pick and choose our gcc optimization options. The generated code also has significant opportunities to exploit alias information---words on the stack cannot alias the car or cdr of a pair, the contents of a vector, etc. The macros implementing the virtual machine can be tweaked to make more of that information explicit, and I'd like gcc to exploit that information, so I'm wondering which optimizations make particular use of aliasing information. Perhaps I've left those off the gcc command line. Until now, I have used -fno-strict-aliasing in the code for correctness reasons (some of the virtual machine macros, related to the bignum library and written in a style similar to assembly, have aliasing violations). When I add -fstrict-aliasing when compiling user code (which doesn't use the bignum macros), I sometimes get significantly slower code. Perhaps there is a lot more register pressure as Andrew suggested, but looking at the assembly output doesn't seem to justify this assumption (basic blocks are small and somewhat independent, it's running on a register-rich machine [64-bit PowerPC], etc.). Brad
4.3 release plan
Hello, I know it's way early to ask, but has a release plan already been set for the 4.3 release? A gross estimation of the expected release date would be sufficient. I'm asking because I need to decide whether I need to do the effort to backport a few things to 4.2 or I can rely on the compiler being at least close to release when I'll need it to be stable. -- // Bernardo Innocenti \X/ http://www.codewiz.org/
bootstrap GCC 3.4.6 on SuSE Linux 8.1
Hi all,
my system is based on SuSE Linux 8.1. Hardware is dual PIII
(2x933MHz, 1GB RAM, MSI 694D Pro (6321)).
config.guess gives
i686-pc-linux-gnu
gcc -v
Reading specs from /usr/lib/gcc/i486-suse-linux/3.4.6/specs
Configured with: ../configure --enable-threads=posix
--prefix=/usr --with-local-prefix={_prefix}/local
--infodir=/usr/share/info --mandir=/usr/share/man
--libdir=/usr/lib --enable-languages=c,c++,f77,objc
--disable-libgcj --with-gxx-include-dir=/usr/include/g++
--with-slibdir=/lib --with-system-zlib --enable-shared
--enable-__cxa_atexit i486-suse-linux
Thread model: posix
gcc version 3.4.6
uname -a
Linux Schnecke 2.4.21-273-smp #1 SMP Mon Jan 17 13:15:15 UTC 2005 i686 unknown
glibc 2.2.5
Greetings from Germany
Martin Jacobs
Re: 4.3 release plan
On May 18, 2007, at 12:51 PM, Bernardo Innocenti wrote: has a release plan already been set for the 4.3 release? Just take the dates between 4.1 and 4.2, and add to the 4.2, and presto, you have the 4.3 times... Or, put another way, about 15 months from now.[1] 1 - YMMV, YGWYPF, PPINGOFR
Re: 4.3 release plan
Mike Stump wrote: > On May 18, 2007, at 12:51 PM, Bernardo Innocenti wrote: >> has a release plan already been set for the 4.3 release? > > Just take the dates between 4.1 and 4.2, and add to the 4.2, and > presto, you have the 4.3 times... Or, put another way, about 15 > months from now.[1] Come on, 4.3 doesn't look in such a bad shape! And not long ago there were people proposing to skip 4.2 and release 4.3 directly. > 1 - YMMV, YGWYPF, PPINGOFR I got the first two, but what does the last one mean? BTW, the tentative timeline says that 4.3 stage 1 will end 4 months *ago*: http://gcc.gnu.org/develop.html#timeline -- // Bernardo Innocenti \X/ http://www.codewiz.org/
Re: 4.3 release plan
On 5/18/07, Bernardo Innocenti <[EMAIL PROTECTED]> wrote: Come on, 4.3 doesn't look in such a bad shape! It will soon, when the stage1 projects are finally merged into the trunk. BTW, the tentative timeline says that 4.3 stage 1 will end 4 months *ago*: http://gcc.gnu.org/develop.html#timeline Being tentative, the timeline tends to be wrong ;-) Gr. Steven
Re: 4.3 release plan
On May 18, 2007, at 2:45 PM, Bernardo Innocenti wrote: Come on, 4.3 doesn't look in such a bad shape! I'll let history decide... 1 - YMMV, YGWYPF, PPINGOFR I got the first two, but what does the last one mean? Wow, you're impressive... The second one I thought would be too cryptic for all. You didn't try google did you? :-) Past performance is no guarantee of future returns. BTW, the tentative timeline says that 4.3 stage 1 will end 4 months *ago*: http://gcc.gnu.org/develop.html#timeline Wait, this seems to contradict your point #1 above.
gcc-4.3-20070518 is now available
Snapshot gcc-4.3-20070518 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20070518/ 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 124836 You'll find: gcc-4.3-20070518.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20070518.tar.bz2 C front end and core compiler gcc-ada-4.3-20070518.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20070518.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20070518.tar.bz2 C++ front end and runtime gcc-java-4.3-20070518.tar.bz2 Java front end and runtime gcc-objc-4.3-20070518.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20070518.tar.bz2The GCC testsuite Diffs from 4.3-20070511 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.
Re: mudflap - does anyone else get many exceptions?
Eyal Lebedinsky wrote: > This is probably an issue only with multithreaded programs. > > For a long time now I found a need to apply a private patch to mf-runtime.c > so that it does not report access to envp[] as a violation. I now built > gcc-4.2.0 and gcc-current and found that I still need this patch for both. > > The small patch simply moves the registration of standard items (environ, > stdin, etc.) from wrap_main() to __mf_init(). I also needed to add a > wrapper for strerror_r(). > > Do other people encounter this problem? How do you solve this? > > patch is here: > http://members.iinet.net.au/~eyaleb/gcc-current-libmudflap-20070518.patch.bz2 An important bit: the problem only shows up when code is executed from a shared-object constructor. The attached script demonstrates the problem, note the violation for stderr when used inside dll_init(). -- Eyal Lebedinsky ([EMAIL PROTECTED]) <http://samba.org/eyal/> attach .zip as .dat zz40.sh Description: application/shellscript
