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: 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 the _LIBC clause, that would be best.
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: [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: 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 PROTECTED]
3. If you have a psignal prototype, you should have a psignal
function, and thus should not be compiling this code at all. Thus,
something else is broken. Look for newlib-specific code in
configure.ac.
I suggest leaving the prototype as-is until #3 is resolved, since the
conflict tells you when it's still broken.
> Cheers,
> Shaun
>
> 2005-10-26 Shaun Jackman <[EMAIL PROTECTED]>
>
> * libiberty/strsignal.c (psignal): Change the signo parameter from
> unsigned to int, and message from char * to const char*.
>
> Index: libiberty/strsignal.c
> ===
> RCS file: /cvs/src/src/libiberty/strsignal.c,v
> retrieving revision 1.9
> diff -u -r1.9 strsignal.c
> --- libiberty/strsignal.c 28 Mar 2005 02:09:01 - 1.9
> +++ libiberty/strsignal.c 26 Oct 2005 21:56:29 -
> @@ -549,7 +549,7 @@
> #ifndef HAVE_PSIGNAL
>
> void
> -psignal (unsigned signo, char *message)
> +psignal (int signo, const char *message)
> {
>if (signal_names == NULL)
> {
>
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++/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 EIPs: > 0xe574 > 0xe64e > 0xb3fb > 0x00020e5e > 0x0001c0f4 > 0x0001c12e > 0x0001bce3 > 0x000193dd > 0x000214f7 > 0x16eb > 0xabd8
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". Addresses in R8C are 20 bits, not 16, and are normally stored in a 3 or 4 byte location. The R8C/2D, for example, is available with 96K of flash. > When you write 32Bit value to 0xfffc it writes a 0x00 in Adress > 0x, but this is the Register OFS. After this the watchdog is > switched on and the controller is only working for short time. My flash utility has a command line option for whether the watchdog should be set or disabled. It overrides this byte before programming. Note that all the vectors in the interrupt and reset vector tables are essentially three byte values, with the top byte used for other purposes. Hmmm... I thought there was a .3byte pseudo-op just for this case, but I see now that there isn't. With it, you could do this: .section ".resetvec" .3byte _start .byte 0xff If you know your start address is in the first 64k, you can do this: .section ".resetvec" .short _start .byte 0 .byte 0xff
