Re: 64-bit pei vs dwarf2
On Mon, Sep 27, 2010 at 05:29:19PM -0700, Richard Henderson wrote: > The 64-bit PEI format has a SECREL32 relocation type. It > does not, however, have a SECREL64 relocation type. Which > means that for > > > #define DWARF_REF_SIZE \ > > (dwarf_version == 2 ? DWARF2_ADDR_SIZE : DWARF_OFFSET_SIZE) > > we don't really have something to use for for dwarf2. > > I could fake it with > > .secrel32 ref > .long 0 This is something we already use for TLS on x86_64: .byte 0xa # DW_AT_location .byte 0xe # DW_OP_const8u .long i...@dtpoff, 0 At least for relocations that are always resolved to locations within the same .debug_info section they will be always unsigned and thus using .secrel 32 ref; .long 0 is IMHO just fine, and implicit pointer currently will never reference anything outside of the current executable's or shared library's CU. Other alternative would be e.g. to have some macro to protect uses of DW_FORM_ref_addr/DW_OP_GNU_implicit_pointer/DW_OP_call_ref, which by default would be to enable them e.g. for (dwarf_version >= 3 || !dwarf_strict) and targets like this could restrict them to (dwarf_version >= 3). Jakub
Bugzilla not whining [was Re: Bugzilla outage Thursday, September 23, 18:00GMT-21:00GMT]
On 21/09/2010 18:27, Ian Lance Taylor wrote: >> We're ready for another try. >> >> Thanks to sterling work by Frédéric Buclin, the gcc.gnu.org overseers >> group is preparing to upgrade gcc.gnu.org bugzilla to a current version. >> We will be taking bugzilla offline on Thursday, September 23, for three >> hours starting at 18:00GMT, 11:00PDT to do a final database upgrade and >> conversion to the new system. Please let us know if this is an >> intolerable inconvenience. >> >> A demonstration version of the new system may still be found at >> http://gcc.gnu.org/bugzilla-test/ . Before I start, I'd like to thank Frédéric for having done all this work and got us a nice shiny new bugzilla. Thank you! One minor thing appears to have failed in the transition: although all my saved searches and whine settings have come across cleanly, I'm no longer receiving my nightly emails that the whine is supposed to be sending me. Is it just me, or is something broken? (While looking for where to report this, I noticed that the "Bugzilla" product category wasn't carried over from the test installation; might it be worth adding that back into the live bugzilla? Then again I don't suppose it'd get an awful lot of usage, beyond this initial transition period.) cheers, DaveK
Re: 64-bit pei vs dwarf2
2010/9/28 Jakub Jelinek :
> On Mon, Sep 27, 2010 at 05:29:19PM -0700, Richard Henderson wrote:
>> The 64-bit PEI format has a SECREL32 relocation type. It
>> does not, however, have a SECREL64 relocation type. Which
>> means that for
>>
>> > #define DWARF_REF_SIZE \
>> > (dwarf_version == 2 ? DWARF2_ADDR_SIZE : DWARF_OFFSET_SIZE)
>>
>> we don't really have something to use for for dwarf2.
>>
>> I could fake it with
>>
>> .secrel32 ref
>> .long 0
>
> This is something we already use for TLS on x86_64:
> .byte 0xa # DW_AT_location
> .byte 0xe # DW_OP_const8u
> .long i...@dtpoff, 0
> At least for relocations that are always resolved to locations
> within the same .debug_info section they will be always unsigned
> and thus using .secrel 32 ref; .long 0 is IMHO just fine, and
> implicit pointer currently will never reference anything outside of the
> current executable's or shared library's CU.
So I suggest the following patch. I tested it for x86_64-w64-mingw32
and didn't got regressions. Also the eh/register1.C test produces
correct abbreviations (tested by objdump -Wi).
ChangeLog
2010-09-28 Kai Tietz
* config/i386/cygming.h (ASM_OUTPUT_DWARF_OFFSET): Output
addition zero for padding of secrel32 requested for 8 bytes.
I will apply this today, if there aren't any objections.
Regards,
Kai
--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination
w64_secrel.diff
Description: Binary data
Re: 64-bit pei vs dwarf2
On 09/28/2010 11:09 AM, Kai Tietz wrote: > ChangeLog > > 2010-09-28 Kai Tietz > > * config/i386/cygming.h (ASM_OUTPUT_DWARF_OFFSET): Output > addition zero for padding of secrel32 requested for 8 bytes. > > I will apply this today, if there aren't any objections. Please don't send diffs as Content-Type: application/octet-stream. Thanks, Andrew.
Re: eliminating mpc/mpfr and reducing gmp
On 09/28/2010 01:51 AM, Dave Korn wrote: > > Huh, am I doing something seriously wrong? It takes me four hours to > boostrap GCC at with all languages enabled at -j8 on an AMD2x64 You must be. I just bootstrapped with c, c++, and java, and it was real40m36.704s user164m5.664s sys 21m59.769s Without bootstrapping, that's real21m56.764s user73m37.137s sys 11m8.702s And note, I'm doing a full build including binutils. This is a Xeon W3520, 2.6 GHz. Time to upgrade? Andrew.
Re: eliminating mpc/mpfr and reducing gmp
On 28/09/2010 11:44, Andrew Haley wrote: > On 09/28/2010 01:51 AM, Dave Korn wrote: > >> Huh, am I doing something seriously wrong? It takes me four hours to >> boostrap GCC at with all languages enabled at -j8 on an AMD2x64 > > You must be. I just bootstrapped with c, c++, and java, and it was > > real40m36.704s > user164m5.664s > sys 21m59.769s > > Without bootstrapping, that's > > real21m56.764s > user73m37.137s > sys 11m8.702s > > And note, I'm doing a full build including binutils. This is a Xeon W3520, > 2.6 GHz. > > Time to upgrade? Sorry, have to check: that was under Cygwin? Those look like the kinds of times I expect from a Linux box. cheers, DaveK
Re: eliminating mpc/mpfr and reducing gmp
On 09/28/2010 12:35 PM, Dave Korn wrote: > On 28/09/2010 11:44, Andrew Haley wrote: >> On 09/28/2010 01:51 AM, Dave Korn wrote: >> >>> Huh, am I doing something seriously wrong? It takes me four hours to >>> boostrap GCC at with all languages enabled at -j8 on an AMD2x64 >> >> You must be. I just bootstrapped with c, c++, and java, and it was >> >> real40m36.704s >> user164m5.664s >> sys 21m59.769s >> >> Without bootstrapping, that's >> >> real21m56.764s >> user73m37.137s >> sys 11m8.702s >> >> And note, I'm doing a full build including binutils. This is a Xeon W3520, >> 2.6 GHz. >> >> Time to upgrade? > > Sorry, have to check: that was under Cygwin? Goodness me, no! You never mentioned Cygwin, AFAICR. Andrew.
split stack on darwin
Ian, Does the new split stack feature in gcc trunk absolutely require additional libc support to function or can it be made to work on other targets like darwin with just changes to libgcc? Thanks in advance for any clarifications. Jack
Re: Bugzilla not whining [was Re: Bugzilla outage Thursday, September 23, 18:00GMT-21:00GMT]
Le 28. 09. 10 11:25, Dave Korn a écrit : > Before I start, I'd like to thank Frédéric for having done all this work and > got us a nice shiny new bugzilla. Thank you! Thanks again. :) > One minor thing appears to have failed in the transition: although all my > saved searches and whine settings have come across cleanly, I'm no longer > receiving my nightly emails that the whine is supposed to be sending me. Is > it just me, or is something broken? It's not just you, nor is it broken. Last Friday, Daniel Berlin asked me what to do with the cron job for whine.pl, because this script was running from his own account, and while I did the upgrade, I enforced security on Bugzilla which doesn't let him run this script himself anymore. We have to run whine.pl from another account, which I have access to. I thought Daniel would do it himself, but from what you say, he didn't. :) Unless someone from #overseers wants to set the cron job himself, I can do it. #overseers: please let me know. (note that we should add collectstats.pl as well to the cron job, to collect data for old and new charts.) > (While looking for where to report this, I noticed that the "Bugzilla" > product category wasn't carried over from the test installation; Yeah, the initial plan was to create a "Bugzilla" product, move the already filed bugs to this product, and use it for Bugzilla-specific bugs. But when I looked at the older bugs specific to Bugzilla, I realized that it would be a very low-usage product, so I didn't create it, and we use gcc/web instead. If there is enough interest in a separate product for Bugzilla, it would be easy to set it up. Just let me know (again for #overseers). Frédéric
Re: 64-bit pei vs dwarf2
On 09/28/2010 03:09 AM, Kai Tietz wrote:
> * config/i386/cygming.h (ASM_OUTPUT_DWARF_OFFSET): Output
> addition zero for padding of secrel32 requested for 8 bytes.
>
> I will apply this today, if there aren't any objections.
I've committed the following instead, which I think is a bit tidier.
r~
* config/i386/cygming.h (ASM_OUTPUT_DWARF_OFFSET): Output 8 bytes
when 8 bytes are requested.
diff --git a/gcc/config/i386/cygming.h b/gcc/config/i386/cygming.h
index 3fee731..ed6b459 100644
--- a/gcc/config/i386/cygming.h
+++ b/gcc/config/i386/cygming.h
@@ -96,11 +96,25 @@ along with GCC; see the file COPYING3. If not see
won't allow it. */
#define ASM_OUTPUT_DWARF_OFFSET(FILE, SIZE, LABEL, SECTION)\
do { \
-if (SIZE != 4 && (!TARGET_64BIT || SIZE != 8)) \
- abort ();\
- \
-fputs ("\t.secrel32\t", FILE); \
-assemble_name (FILE, LABEL); \
+switch (SIZE) \
+ {\
+ case 4: \
+ fputs ("\t.secrel32\t", FILE); \
+ assemble_name (FILE, LABEL);\
+ break; \
+ case 8: \
+ /* This is a hack. There is no 64-bit section relative \
+ relocation. However, the COFF format also does not \
+ support 64-bit file offsets; 64-bit applications are \
+ limited to 32-bits of code+data in any one module. \
+ Fake the 64-bit offset by zero-extending it. */ \
+ fputs ("\t.secrel32\t", FILE); \
+ assemble_name (FILE, LABEL);\
+ fputs ("\n\t.long\t0", FILE); \
+ break; \
+ default: \
+ gcc_unreachable (); \
+ }\
} while (0)
#endif
Re: split stack on darwin
Jack Howarth writes: > Does the new split stack feature in gcc trunk absolutely require additional > libc support to function or can it be made to work on other targets like > darwin with just changes to libgcc? Thanks in advance for any > clarifications. The additional support that it needs is a thread local place to store the stack bound which can be accessed efficiently. On GNU/Linux I'm using a word in the thread block--I've actually stolen a word which was reserved for transactional memory but which RTH says he doesn't need. This can be accessed as an offset from %fs or %gs. To make this functionality work on Darwin, you need something similar. I don't know how thread local storage works on Darwin, so I don't know if you can do something similar. I list some other options at http://gcc.gnu.org/wiki/SplitStacks under "Possible strategies." Ian
Re: split stack on darwin
On 28 Sep 2010, at 17:29, Ian Lance Taylor wrote: Jack Howarth writes: Does the new split stack feature in gcc trunk absolutely require additional libc support to function or can it be made to work on other targets like darwin with just changes to libgcc? Thanks in advance for any clarifications. The additional support that it needs is a thread local place to store the stack bound which can be accessed efficiently. On GNU/Linux I'm using a word in the thread block--I've actually stolen a word which was reserved for transactional memory but which RTH says he doesn't need. This can be accessed as an offset from %fs or %gs. To make this functionality work on Darwin, you need something similar. I don't know how thread local storage works on Darwin, so I don't know if you can do something similar. We have emulated TLS (Richard's new code) . I list some other options at http://gcc.gnu.org/wiki/SplitStacks under "Possible strategies. I sincerely doubt something this involved can be accommodated in the remaining time of stage 1 (unless we magic some additional Darwin devs from somewhere ;-)) Iain
Re: 64-bit pei vs dwarf2
2010/9/28 Richard Henderson :
> On 09/28/2010 03:09 AM, Kai Tietz wrote:
>> * config/i386/cygming.h (ASM_OUTPUT_DWARF_OFFSET): Output
>> addition zero for padding of secrel32 requested for 8 bytes.
>>
>> I will apply this today, if there aren't any objections.
>
> I've committed the following instead, which I think is a bit tidier.
>
>
> r~
>
Ok, thanks for tracking this issue. In my opinion it would be good to
back-merge this patch to branches.
Kai
--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination
Re: 64-bit pei vs dwarf2
On 09/28/2010 09:50 AM, Kai Tietz wrote: > 2010/9/28 Richard Henderson : >> On 09/28/2010 03:09 AM, Kai Tietz wrote: >>> * config/i386/cygming.h (ASM_OUTPUT_DWARF_OFFSET): Output >>> addition zero for padding of secrel32 requested for 8 bytes. >>> >>> I will apply this today, if there aren't any objections. >> >> I've committed the following instead, which I think is a bit tidier. >> >> >> r~ >> > > Ok, thanks for tracking this issue. In my opinion it would be good to > back-merge this patch to branches. I've committed it to 4.5 for good measure, but this really only matters for mainline with the DW_OP_GNU_implicit_pointer support. Prior to that we never emitted any opcodes with references. r~
Re: split stack on darwin
IainS writes: > On 28 Sep 2010, at 17:29, Ian Lance Taylor wrote: > >> Jack Howarth writes: >> >>> Does the new split stack feature in gcc trunk absolutely require >>> additional >>> libc support to function or can it be made to work on other targets >>> like >>> darwin with just changes to libgcc? Thanks in advance for any >>> clarifications. >> >> The additional support that it needs is a thread local place to store >> the stack bound which can be accessed efficiently. On GNU/Linux I'm >> using a word in the thread block--I've actually stolen a word which >> was >> reserved for transactional memory but which RTH says he doesn't need. >> This can be accessed as an offset from %fs or %gs. To make this >> functionality work on Darwin, you need something similar. I don't >> know >> how thread local storage works on Darwin, so I don't know if you can >> do >> something similar. > > We have emulated TLS (Richard's new code) . If I understand correctly how that works, that would be a heavy performance penalty for something like -fsplit-stack. >> I list some other options at http://gcc.gnu.org/wiki/SplitStacks under >> "Possible strategies. > > > I sincerely doubt something this involved can be accommodated in the > remaining time of stage 1 > (unless we magic some additional Darwin devs from somewhere ;-)) If a good strategy can be chosen, the actual changes are probably fairly small. But of course it's up to you. Ian
Re: Simple development GCC and G++
On 09/27/10 16:48, Paul Brook wrote: Most of the interesting bits happen in the linker+debugger. "gcc -ffunction- sections -fdata-sections -fPIC" is likely to be pretty good in terms of compiler output. What you then need is a linker that will relink an image, changing it as little as possible relative to a previous run. Your debugger then needs to be able to replace these images in-place (which may require interaction with the dynamic linker). Be warned that this ends up being extremely complex, even for relatively simple changes. I think that you are aiming at the wrong target. Look at the goal: - To be able to debug then edit, recompile and continue debugging. There seems to be no requirement for "preserve the ABI" nor "compile to native code". What I am getting at is that it is possible to use a different ABI that is more robust with respect to local variable addition/removal. Michael
Microblaze port
I am pleased to announce that the GCC Steering Committee has accepted the Microblaze port for inclusion in GCC and appointed Michael Eager as port maintainer. Happy hacking! David
Re: Microblaze port
David Edelsohn wrote: I am pleased to announce that the GCC Steering Committee has accepted the Microblaze port for inclusion in GCC and appointed Michael Eager as port maintainer. Thanks! Adding myself to maintainer list. Index: MAINTAINERS === --- MAINTAINERS (revision 164696) +++ MAINTAINERS (working copy) @@ -72,6 +72,7 @@ m68k-motorola-sysv portPhilippe De Muyter p...@macqel.be mcore port Nick Cliftonni...@redhat.com mep port DJ Delorie d...@redhat.com +microblaze Michael Eager ea...@eagercon.com mips port Eric Christopherechri...@apple.com mips port Richard Sandiford rdsandif...@googlemail.com mmix port Hans-Peter Nilsson h...@bitrange.com -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: eliminating mpc/mpfr and reducing gmp
On 28/09/2010 13:28, Andrew Haley wrote: > On 09/28/2010 12:35 PM, Dave Korn wrote: >> On 28/09/2010 11:44, Andrew Haley wrote: >>> On 09/28/2010 01:51 AM, Dave Korn wrote: >>> Huh, am I doing something seriously wrong? It takes me four hours to boostrap GCC at with all languages enabled at -j8 on an AMD2x64 >>> You must be. I just bootstrapped with c, c++, and java, and it was >>> >>> real40m36.704s >>> user164m5.664s >>> sys 21m59.769s >>> >>> Without bootstrapping, that's >>> >>> real21m56.764s >>> user73m37.137s >>> sys 11m8.702s >>> >>> And note, I'm doing a full build including binutils. This is a Xeon W3520, >>> 2.6 GHz. >>> >>> Time to upgrade? >> Sorry, have to check: that was under Cygwin? > > Goodness me, no! You never mentioned Cygwin, AFAICR. No, Jay mentioned it! So I was comparing notes with him. cheers, DaveK
Re: Microblaze port
On 09/28/2010 01:56 PM, Michael Eager wrote: David Edelsohn wrote: I am pleased to announce that the GCC Steering Committee has accepted the Microblaze port for inclusion in GCC and appointed Michael Eager as port maintainer. Thanks! Congratulations! Does your current source include the microblaze-*-rtems* target configure magic? I don't remember where it got left. --joel Adding myself to maintainer list. Index: MAINTAINERS === --- MAINTAINERS (revision 164696) +++ MAINTAINERS (working copy) @@ -72,6 +72,7 @@ m68k-motorola-sysv portPhilippe De Muyter p...@macqel.be mcore port Nick Cliftonni...@redhat.com mep port DJ Delorie d...@redhat.com +microblaze Michael Eager ea...@eagercon.com mips port Eric Christopherechri...@apple.com mips port Richard Sandiford rdsandif...@googlemail.com mmix port Hans-Peter Nilsson h...@bitrange.com -- Joel Sherrill, Ph.D. Director of Research& Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Re: gcj fails to compile java
On 25 September 2010 14:20, Jack Howarth wrote:
> I've filed PR45773 concerning the new regression in gcj where java classes
> can
> no longer be compiled with ecj.jar. Since r163770 (with r163814 backported to
> fix
> the libjava build), any attempt to compile a java source file with gcj
> produces
> the error...
>
> gcj --main=testme -O testme.java
> Exception in thread "main" java.lang.NoClassDefFoundError:
> org.eclipse.jdt.internal.compiler.batch.GCCMain
> at gnu.java.lang.MainThread.run(libgcj.12.dylib)
> Caused by: java.lang.ClassNotFoundException:
> org.eclipse.jdt.internal.compiler.batch.GCCMain not found in
> gnu.gcj.runtime.SystemClassLoader{urls=[file:/sw/share/java/ecj/ecj.jar,file:./],
> parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
> at java.net.URLClassLoader.findClass(libgcj.12.dylib)
> at java.lang.ClassLoader.loadClass(libgcj.12.dylib)
> at java.lang.ClassLoader.loadClass(libgcj.12.dylib)
> at gnu.java.lang.MainThread.run(libgcj.12.dylib)
>
> This problem does not exist at r163768. I am reposting this problem since the
> new
> bugzilla keeps reporting...
>
> GCC Bugzilla has suffered an internal error. Please save this page and send
> it to dber...@gcc.gnu.org with details of what you were doing at the time
> this message appeared.
>
> URL: file:///Users/howarth/Internal Error.html
>
> There was an error sending mail from '"howarth at nitro dot med.uc.edu"
> ' to 'java-...@gcc.gnu.org':Can't send data
>
> whenever I add new information and nothing appears in the gcc-bugs archives
> from those sessions
> (although the PR itself if updated).
> Jack
>
With a simple HelloWorld class:
$ cat HelloWorld.java
public class HelloWorld
{
public static void main(String[] args) { System.out.println("Hello World!"); }
}
current HEAD works fine for me:
$ /home/andrew/build/gcj/bin/gcj --main=HelloWorld -O HelloWorld.java
$ LD_LIBRARY_PATH=/home/andrew/build/gcj/lib64 ./a.out
Hello World!
$ /home/andrew/build/gcj/bin/gcj --version
gcj (GCC) 4.6.0 20100928 (experimental) [trunk revision 164689]
Can you attach the testme.java file?
--
Andrew :-)
Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)
Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net
PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: Microblaze port
Joel Sherrill wrote: On 09/28/2010 01:56 PM, Michael Eager wrote: David Edelsohn wrote: I am pleased to announce that the GCC Steering Committee has accepted the Microblaze port for inclusion in GCC and appointed Michael Eager as port maintainer. Thanks! Congratulations! Does your current source include the microblaze-*-rtems* target configure magic? I don't remember where it got left. No, it doesn't. After the basic MicroBlaze support is checked in, please post patches for rtems to gcc-patches. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: gcj fails to compile java
On Tue, Sep 28, 2010 at 08:21:45PM +0100, Dr Andrew John Hughes wrote:
> On 25 September 2010 14:20, Jack Howarth wrote:
> > I've filed PR45773 concerning the new regression in gcj where java classes
> > can
> > no longer be compiled with ecj.jar. Since r163770 (with r163814 backported
> > to fix
> > the libjava build), any attempt to compile a java source file with gcj
> > produces
> > the error...
> >
> > gcj --main=testme -O testme.java
> > Exception in thread "main" java.lang.NoClassDefFoundError:
> > org.eclipse.jdt.internal.compiler.batch.GCCMain
> > at gnu.java.lang.MainThread.run(libgcj.12.dylib)
> > Caused by: java.lang.ClassNotFoundException:
> > org.eclipse.jdt.internal.compiler.batch.GCCMain not found in
> > gnu.gcj.runtime.SystemClassLoader{urls=[file:/sw/share/java/ecj/ecj.jar,file:./],
> > parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
> > at java.net.URLClassLoader.findClass(libgcj.12.dylib)
> > at java.lang.ClassLoader.loadClass(libgcj.12.dylib)
> > at java.lang.ClassLoader.loadClass(libgcj.12.dylib)
> > at gnu.java.lang.MainThread.run(libgcj.12.dylib)
> >
> > This problem does not exist at r163768. I am reposting this problem since
> > the new
> > bugzilla keeps reporting...
> >
> > GCC Bugzilla has suffered an internal error. Please save this page and send
> > it to dber...@gcc.gnu.org with details of what you were doing at the time
> > this message appeared.
> >
> > URL: file:///Users/howarth/Internal Error.html
> >
> > There was an error sending mail from '"howarth at nitro dot med.uc.edu"
> > ' to 'java-...@gcc.gnu.org':Can't send data
> >
> > whenever I add new information and nothing appears in the gcc-bugs archives
> > from those sessions
> > (although the PR itself if updated).
> > Jack
> >
>
> With a simple HelloWorld class:
>
> $ cat HelloWorld.java
> public class HelloWorld
> {
> public static void main(String[] args) { System.out.println("Hello
> World!"); }
> }
>
> current HEAD works fine for me:
Of course it does because the bug was just fixed...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45773#c20
>
> $ /home/andrew/build/gcj/bin/gcj --main=HelloWorld -O HelloWorld.java
> $ LD_LIBRARY_PATH=/home/andrew/build/gcj/lib64 ./a.out
> Hello World!
> $ /home/andrew/build/gcj/bin/gcj --version
> gcj (GCC) 4.6.0 20100928 (experimental) [trunk revision 164689]
>
> Can you attach the testme.java file?
> --
> Andrew :-)
>
> Free Java Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
>
> Support Free Java!
> Contribute to GNU Classpath and the OpenJDK
> http://www.gnu.org/software/classpath
> http://openjdk.java.net
>
> PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: Bugzilla not whining [was Re: Bugzilla outage Thursday, September 23, 18:00GMT-21:00GMT]
Le 28. 09. 10 11:25, Dave Korn a écrit : > I'm no longer > receiving my nightly emails that the whine is supposed to be sending me. This should be fixed now. Let me know if you still don't get nightly emails. Frédéric
gcc-4.4-20100928 is now available
Snapshot gcc-4.4-20100928 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20100928/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch revision 164706 You'll find: gcc-4.4-20100928.tar.bz2 Complete GCC (includes all of below) MD5=8746a0debf1e61043a2b4a666376c6ab SHA1=fe67927deecb557a205002ff36c417db6dce7e0e gcc-core-4.4-20100928.tar.bz2C front end and core compiler MD5=cfb78962a2ae44a1caa415ee9a4ad60b SHA1=1d87c9b9edfde1f91fd9d74f4eee84834817fe91 gcc-ada-4.4-20100928.tar.bz2 Ada front end and runtime MD5=3df63cb01d7f29d474db453aea8f3d41 SHA1=9034cb94ccf899a9f2e93338fbd2133d645f832e gcc-fortran-4.4-20100928.tar.bz2 Fortran front end and runtime MD5=2f906407a5fd0f5e6c7c1fca82fa49ab SHA1=72ea01ecc70e1c90b09fb43c88a38b359dde04e6 gcc-g++-4.4-20100928.tar.bz2 C++ front end and runtime MD5=3cc1e8c284f990a5636881c02aeaed95 SHA1=528aae5adb8f5a5eea22b0a7b9d3047537e7e978 gcc-java-4.4-20100928.tar.bz2Java front end and runtime MD5=cb9180d55b2cd29115bcb07432f39c39 SHA1=c084e442eb2980b8fc5beb5cac4b94f50780bbb3 gcc-objc-4.4-20100928.tar.bz2Objective-C front end and runtime MD5=3dc02c08f5fd0be60697fc05293b9a9b SHA1=37d5f08c66dd1e94dcb9c707b683611910e62031 gcc-testsuite-4.4-20100928.tar.bz2 The GCC testsuite MD5=6e336449c602ac7c7896ceb673018d28 SHA1=bbbf5f58019f09a7b300a6fc388cff88ccc26f5d Diffs from 4.4-20100921 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 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.
