Re: [Bug target/78804] [RX] -m64bit-doubles does not work

"olegendo at gcc dot gnu.org" writes: > I don't know why it was decided to use this ABI. Maybe some legacy > stuff. Compatibility with Renesas's compiler.

Re: [Bug c++/41916] New: psignal() declaration needs const char*

Libiberty should not even try to compile psignal() on djgpp as djgpp already has one. This is noted in libiberty/configure.ac.

Re: Warning while building for win64

This is a special case because all the logic has to be done in md5.c as preprocessor macros. You'd need someone familiar with the platform (Chris, Danny, Kai) to specify a reliable way to detect that platform and/or define the types accordingly. If it can typedef md5_uintptr directly, or use

Re: [Bug testsuite/38946] [trunk regression]?gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

I think adding a printf() clone to libiberty is WAY overkill just to silence one failing test.

Re: problem with one tree style builds

I am on Fedora 7 with autoconf 2.61 with a checkout from yesterday off the trunk. So I shouldn't have see it based upon that requirement. What else could it be? Did you re-generate all the configure's from all the configure.ac's? The ones in CVS are all built with 2.59.

Re: problem with one tree style builds

http://sourceware.org/ml/newlib/2006/msg00472.html Shouldn't this patch already be in the top level gcc/Makefile.in? The right fix is to use autoconf 2.60 or later. The patch you link to requires GNU make, and thus was rejected.

Re: problem with one tree style builds

What is the recommended procedure to regenerate them? Not sure there is one. Shouldn't they be regenerated and committed in CVS? No, because that changes the base requirements for all those packages.

Re: Found Error in link-script for R8C

Hello to everyone, Wrong list. The R8C link scripts are part of newlib (libgloss), not gcc. RESETVEC (r) : ORIGIN = 0xfffc, LENGTH = 4 But this is wrong. The Resetvektor for R8C is only 16Bit and not 32bit. The REJ09B0169-0100 page 61 shows the reset vector as being 0FFFCh to 0h.

Re: [Bug c++/26825] New: bad allocation while adding new elements to vector

When reporting DJGPP bugs, please run your app under gdb and use where to get a traceback, or use djgpp's symify (or bfdsymify) to replace these hex numbers with file/line information. You may need to compile your application with -g to get symbolic debugging information. Call frame traceback

Re: libgloss psignal declaration [PATCH]

I found the following patch necessary to build libiberty with newlib headers. Although, glibc seems to use the same signature now. While I'm generally OK with this... 1. The patch is incomplete, as you don't update the documentation to match the new prototype. 2. GCC patches go to [EMAIL