Re: (new) Failure building GFortran (Cygwin)
Dave Korn ha scritto:
Angelo Graziosi wrote on 05 July 2008 12:16:
For the sake of completeness I want to flag that the current snapshot
4.4-20080704 has new failures:
/work/gcc/gcc/ggc-page.c -o ggc-page.o
cc1: warnings being treated as errors
/work/gcc/gcc/ggc-page.c: In function 'alloc_page':
/work/gcc/gcc/ggc-page.c:802: error: request for implicit conversion
from 'void *' to 'char *' not permitted in C++
/work/gcc/gcc/ggc-page.c:845: error: request for implicit conversion
from 'void *' to 'struct page_entry *' not permitted in C++
make[3]: *** [ggc-page.o] Error 1
But I am confused in any case: Why 'not permitted in C++'?
Isn't xgcc a C compiler?
I am enabling only C,Fortran!
This is probably fallout from Kaveh's current work on making sure gcc
stays c++ compatible. Your patch looked good to me, you should send it with
a ChangeLog to gcc-patches.
cheers,
DaveK
Could this be valid?
gcc/ChangeLog:
2008-07-05 Angelo Graziosi <[EMAIL PROTECTED]>
* ggc-page.c (alloc_page):
Adding explicit cast to xmalloc, xcalloc.
--- gcc-4.4-20080704.orig/gcc/ggc-page.c 2008-06-29
06:39:16.0 +0200
+++ gcc-4.4-20080704/gcc/ggc-page.c 2008-07-05 12:00:20.90625 +0200
@@ -799,7 +799,7 @@
alloc_size = GGC_QUIRE_SIZE * G.pagesize;
else
alloc_size = entry_size + G.pagesize - 1;
- allocation = xmalloc (alloc_size);
+ allocation = (char *)xmalloc (alloc_size);
page = (char *) (((size_t) allocation + G.pagesize - 1) &
-G.pagesize);
head_slop = page - allocation;
@@ -842,7 +842,7 @@
struct page_entry *e, *f = G.free_pages;
for (a = enda - G.pagesize; a != page; a -= G.pagesize)
{
- e = xcalloc (1, page_entry_size);
+ e = (struct page_entry *)xcalloc (1, page_entry_size);
e->order = order;
e->bytes = G.pagesize;
e->page = a;
Thanks,
Angelo.
If you look stupid in bed
Your new source of great health. http://oj.doctorfeelgoodphd.eu
RE: Bootstrap failures due to C++ warnings with --enable-gather-detailed-memory-stats
Kaveh R. GHAZI wrote on 06 July 2008 23:36: > * gcc.c (execute): Fix -Wc++-compat warning. Kaveh, am I right in inferring from recent list traffic that you've taken on a whole load of c-vs-c++ compatibility work? If so, have you seen / can you take a look at http://gcc.gnu.org/ml/gcc/2008-07/msg00109.html (and the follow-up http://gcc.gnu.org/ml/gcc/2008-07/msg00130.html) ? cheers, DaveK -- Can't think of a witty .sigline today
Re: Bootstrap failures due to C++ warnings with --enable-gather-detailed-memory-stats
On Mon, Jul 7, 2008 at 4:48 AM, Dave Korn <[EMAIL PROTECTED]> wrote: > Kaveh R. GHAZI wrote on 06 July 2008 23:36: > >> * gcc.c (execute): Fix -Wc++-compat warning. > > > Kaveh, am I right in inferring from recent list traffic that you've taken > on a whole load of c-vs-c++ compatibility work? If so, have you seen / can > you take a look at http://gcc.gnu.org/ml/gcc/2008-07/msg00109.html (and the > follow-up http://gcc.gnu.org/ml/gcc/2008-07/msg00130.html) ? The idiom is to use XCNEWVAR(T) for xcalloc(1, sizeof(T)), XNEWVAR(T) for xmalloc(sizeof(T)), XNEWVEC(T,n) for xmalloc(n * sizeof(T)), and XCNEWVEC(T,n) for xcalloc(n,sizeof(T)). You don't need to add explicit casts -- those are taken care of by the allocation macros. > > > >cheers, > DaveK > -- > Can't think of a witty .sigline today > >
GNU LD fails to generate correct ARM Thumb veneer
good day people:
i have been using GNUARM/Cygwin for some time now and i have not
encountered a problem like this before.
BACKGROUND
- target MCU is STR71x
- CPU core is ARM7TDMI
- toolchain is GNUARM 4.1.1 on Cygwin
- source code
- the first file to be linked is an ARM assembly .s file
that contains the ARM vector table and handler addresses.
the vector table is in a separate section called .VhaInit.
when linked, it is located to 0x2000 (SRAM) or
0x4000 (Flash)
- the second file is another ARM assembly .s file that contains
C startup code. when linked, the .text is located to 0x2080
(SRAM) or 0x4080 (Flash), just after .VhaInit.
- assembly files are assembled with -mthumb-interworking but are
written in pure ARM code.
- there is a C file that is compiled with -mthumb
-mthumb-interworking.
- i also link with -gc-sections, and C code is compiled with
-ffunction-sections and -fdata-sections so that unused C code is
eliminated by the linker.
- ResetHandler entry is set to 0x400C using --defsym option of
LD: --defsym ResetHandler=0x400C
PROBLEM
- when i add code to access .VhaInit entries from .text to prevent the
garbage collection of .VhaInit, Thumb Interworking code is ZERO. the
entries are present, but no interworking code is present.
- when i remove code that accesses .VhaInit, Interworking code is
correct.
- when i disable -ffunction-sections, -fdata-sections, and
-gc-sections, and when i still access data in .VhaInit from .text,
Interworking is correct.
so, what's going on? 8-)
i think its a bug in GNU LD.
any help will be gratefully accepted.
have a nice day,
Aaron
--
{tel: +91-20-6526-7076; cell: +91-9970-591-079; fax: +1-800-450-5419}
Re: Trouble with gdb 6.8 on Irix
[moved to the GCC list] > > I think that GDB on mips-irix has been in dire need of attention. > > It's something I have on my list and I hope to get to it by the end > > of the year, but my hopes often get overridden by more urgent issues... > > The release that AdaCore uses in its product is GDB 5.3 (very old now, > > I know). > > If you care about GDB on mips-irix, I strongly advise caring about GCC as > well, or finding someone to care about it. Right now, it is on the list > of targets to be deprecated in GCC 4.4 because we wish to remove fixproto > and it is one of the few targets still using fixproto (so someone would > need to stop it from using fixproto, and make fixincludes do any necessary > fixes fixproto does at present for this target). I can as Olivier or Eric if they have some time to have a look. Do we have an idea of deadlines? Does it have to be fixed by 4.4? -- Joel
Re: GNU LD fails to generate correct ARM Thumb veneer
Hi Aaron, - the first file to be linked is an ARM assembly .s file that contains the ARM vector table and handler addresses. the vector table is in a separate section called .VhaInit. Did you know that you can use the KEEP directive in a linker script (or a linker script fragment) in order to make sure that the .VhaInit section is not garbage collected ? - when i add code to access .VhaInit entries from .text to prevent the garbage collection of .VhaInit, Thumb Interworking code is ZERO. the entries are present, but no interworking code is present. What sort of code are you adding and how are you adding it ? - when i remove code that accesses .VhaInit, Interworking code is correct. - when i disable -ffunction-sections, -fdata-sections, and -gc-sections, and when i still access data in .VhaInit from .text, Interworking is correct. so, what's going on? 8-) i think its a bug in GNU LD. any help will be gratefully accepted. You try to isolate whether this really is a linker bug. (It certainly sounds like it is). If you can reproduce the problem just using assembler source files then please file a bug report with the binutils project (at http://sourceware.org/bugzilla). Including a *small* test case will really help. Cheers Nick
Re: (new) Failure building GFortran (Cygwin)
Angelo Graziosi <[EMAIL PROTECTED]> writes: > Could this be valid? It's valid, but it's not the right patch. The right patch is to use XNEW and XCNEW from include/libiberty.h. Ian
Re: Trouble with gdb 6.8 on Irix
On Mon, 7 Jul 2008, Joel Brobecker wrote: > > If you care about GDB on mips-irix, I strongly advise caring about GCC as > > well, or finding someone to care about it. Right now, it is on the list > > of targets to be deprecated in GCC 4.4 because we wish to remove fixproto > > and it is one of the few targets still using fixproto (so someone would > > need to stop it from using fixproto, and make fixincludes do any necessary > > fixes fixproto does at present for this target). > > I can as Olivier or Eric if they have some time to have a look. > Do we have an idea of deadlines? Does it have to be fixed by 4.4? I would hope to remove fixproto and all deprecated targets on trunk around the time 4.4.0 is released. If the deprecation patch is approved, the deprecated targets will require --enable-obsolete to build them, on trunk and 4.4 branch once created, until removed. -- Joseph S. Myers [EMAIL PROTECTED]
Re: GNU LD fails to generate correct ARM Thumb veneer
hello Nick:
thank you for your prompt response. i have seen your crt0.S.
- the first file to be linked is an ARM assembly .s file
that contains the ARM vector table and handler addresses.
the vector table is in a separate section called .VhaInit.
Did you know that you can use the KEEP directive in a linker script (or
a linker script fragment) in order to make sure that the .VhaInit
section is not garbage collected ?
yes. i avoided using a linker script. i use objcopy and move the
LMA as needed for ROM programs.
- when i add code to access .VhaInit entries from .text to prevent the
garbage collection of .VhaInit, Thumb Interworking code is ZERO. the
entries are present, but no interworking code is present.
What sort of code are you adding and how are you adding it ?
.section .VhaInit, "a"
.align 0
AppTextVha:
@ V: ARM Vectors
ResetVec: LDRPC, ResetAddr@ Reset
[...]
@ HA: our Handler Addresses
ResetAddr: .word ResetHandler @ Reset
[...]
AppTextVStart:
@ UH: our Unused Handlers
ResetHolder:B .@ Reset
LDR R1, =AppTextVha
LDR R1, =AppTextVStart
- when i remove code that accesses .VhaInit, Interworking code is
correct.
You try to isolate whether this really is a linker bug. (It
certainly sounds like it is). If you can reproduce the problem
just using assembler source files then please file a bug report
with the binutils project (at http://sourceware.org/bugzilla).
Including a *small* test case will really help.
okay. i will send you one.
thank you once again,
Aaron
--
{tel: +91-20-6526-7076; cell: +91-9970-591-079; fax: +1-800-450-5419}
Re: (new) Failure building GFortran (Cygwin)
Ian Lance Taylor wrote:
It's valid, but it's not the right patch. The right patch is to use
XNEW and XCNEW from include/libiberty.h.
Gabriel Dos Reis in [1] wrote:
> The idiom is to use XCNEWVAR(T) for xcalloc(1, sizeof(T)),
> XNEWVAR(T) for xmalloc(sizeof(T)),...
Gulp! I am a little confused... XNEW or XNEWVAR, etc.?
In any case, my opinion is that this should solve:
--- gcc-4.4-20080704.orig/gcc/ggc-page.c 2008-06-29 06:39:16.0 +0200
+++ gcc-4.4-20080704/gcc/ggc-page.c 2008-07-05 12:00:20.90625 +0200
@@ -799,7 +799,7 @@
alloc_size = GGC_QUIRE_SIZE * G.pagesize;
else
alloc_size = entry_size + G.pagesize - 1;
- allocation = xmalloc (alloc_size);
+ allocation = XNEWVAR(char, alloc_size);
page = (char *) (((size_t) allocation + G.pagesize - 1) &
-G.pagesize);
head_slop = page - allocation;
@@ -842,7 +842,7 @@
struct page_entry *e, *f = G.free_pages;
for (a = enda - G.pagesize; a != page; a -= G.pagesize)
{
- e = xcalloc (1, page_entry_size);
+ e = XCNEWVAR(struct page_entry, page_entry_size);
e->order = order;
e->bytes = G.pagesize;
e->page = a;
What do you think?
Cheers,
Angelo.
---
[1] http://gcc.gnu.org/ml/gcc/2008-07/msg00133.html
Re: (new) Failure building GFortran (Cygwin)
Angelo Graziosi <[EMAIL PROTECTED]> writes:
> Ian Lance Taylor wrote:
>> It's valid, but it's not the right patch. The right patch is to use
>> XNEW and XCNEW from include/libiberty.h.
>>
>
> Gabriel Dos Reis in [1] wrote:
>> The idiom is to use XCNEWVAR(T) for xcalloc(1, sizeof(T)),
>> XNEWVAR(T) for xmalloc(sizeof(T)),...
>
>
> Gulp! I am a little confused... XNEW or XNEWVAR, etc.?
It is confusing.
> --- gcc-4.4-20080704.orig/gcc/ggc-page.c 2008-06-29 06:39:16.0 +0200
> +++ gcc-4.4-20080704/gcc/ggc-page.c 2008-07-05 12:00:20.90625 +0200
> @@ -799,7 +799,7 @@
> alloc_size = GGC_QUIRE_SIZE * G.pagesize;
>else
> alloc_size = entry_size + G.pagesize - 1;
> - allocation = xmalloc (alloc_size);
> + allocation = XNEWVAR(char, alloc_size);
Actually, I think this should be XNEWVEC (char, alloc_size), though
the effect is similar when the type is char.
> @@ -842,7 +842,7 @@
> struct page_entry *e, *f = G.free_pages;
> for (a = enda - G.pagesize; a != page; a -= G.pagesize)
> {
> - e = xcalloc (1, page_entry_size);
> + e = XCNEWVAR(struct page_entry, page_entry_size);
Here XCNEWVAR is correct. There should be a space before the left
parenthesis.
Ian
Re: (new) Failure building GFortran (Cygwin)
Ian Lance Taylor ha scritto:
Angelo Graziosi <[EMAIL PROTECTED]> writes:
Ian Lance Taylor wrote:
It's valid, but it's not the right patch. The right patch is to use
XNEW and XCNEW from include/libiberty.h.
Gabriel Dos Reis in [1] wrote:
The idiom is to use XCNEWVAR(T) for xcalloc(1, sizeof(T)),
XNEWVAR(T) for xmalloc(sizeof(T)),...
Gulp! I am a little confused... XNEW or XNEWVAR, etc.?
It is confusing.
--- gcc-4.4-20080704.orig/gcc/ggc-page.c 2008-06-29 06:39:16.0 +0200
+++ gcc-4.4-20080704/gcc/ggc-page.c 2008-07-05 12:00:20.90625 +0200
@@ -799,7 +799,7 @@
alloc_size = GGC_QUIRE_SIZE * G.pagesize;
else
alloc_size = entry_size + G.pagesize - 1;
- allocation = xmalloc (alloc_size);
+ allocation = XNEWVAR(char, alloc_size);
Actually, I think this should be XNEWVEC (char, alloc_size), though
the effect is similar when the type is char.
@@ -842,7 +842,7 @@
struct page_entry *e, *f = G.free_pages;
for (a = enda - G.pagesize; a != page; a -= G.pagesize)
{
- e = xcalloc (1, page_entry_size);
+ e = XCNEWVAR(struct page_entry, page_entry_size);
Here XCNEWVAR is correct. There should be a space before the left
parenthesis.
Ian
--- gcc-4.4-20080704.orig/gcc/ggc-page.c 2008-06-29 06:39:16.0 +0200
+++ gcc-4.4-20080704/gcc/ggc-page.c 2008-07-05 12:00:20.90625 +0200
@@ -799,7 +799,7 @@
alloc_size = GGC_QUIRE_SIZE * G.pagesize;
else
alloc_size = entry_size + G.pagesize - 1;
- allocation = xmalloc (alloc_size);
+ allocation = XNEWVEC (char, alloc_size);
page = (char *) (((size_t) allocation + G.pagesize - 1) &
-G.pagesize);
head_slop = page - allocation;
@@ -842,7 +842,7 @@
struct page_entry *e, *f = G.free_pages;
for (a = enda - G.pagesize; a != page; a -= G.pagesize)
{
- e = xcalloc (1, page_entry_size);
+ e = XCNEWVAR (struct page_entry, page_entry_size);
e->order = order;
e->bytes = G.pagesize;
e->page = a;
Angelo
Re: (new) Failure building GFortran (Cygwin)
On Tue, 8 Jul 2008, Angelo Graziosi wrote:
> --- gcc-4.4-20080704.orig/gcc/ggc-page.c 2008-06-29 06:39:16.0 +0200
> +++ gcc-4.4-20080704/gcc/ggc-page.c 2008-07-05 12:00:20.90625 +0200
> @@ -799,7 +799,7 @@
> alloc_size = GGC_QUIRE_SIZE * G.pagesize;
> else
> alloc_size = entry_size + G.pagesize - 1;
> - allocation = xmalloc (alloc_size);
> + allocation = XNEWVEC (char, alloc_size);
>
> page = (char *) (((size_t) allocation + G.pagesize - 1) &
> -G.pagesize);
> head_slop = page - allocation;
> @@ -842,7 +842,7 @@
> struct page_entry *e, *f = G.free_pages;
> for (a = enda - G.pagesize; a != page; a -= G.pagesize)
> {
> - e = xcalloc (1, page_entry_size);
> + e = XCNEWVAR (struct page_entry, page_entry_size);
> e->order = order;
> e->bytes = G.pagesize;
> e->page = a;
FWIW, this looks correct to me. (However I can't approve it).
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
Re: (new) Failure building GFortran (Cygwin)
Angelo Graziosi <[EMAIL PROTECTED]> writes:
> --- gcc-4.4-20080704.orig/gcc/ggc-page.c 2008-06-29 06:39:16.0 +0200
> +++ gcc-4.4-20080704/gcc/ggc-page.c 2008-07-05 12:00:20.90625 +0200
> @@ -799,7 +799,7 @@
> alloc_size = GGC_QUIRE_SIZE * G.pagesize;
>else
> alloc_size = entry_size + G.pagesize - 1;
> - allocation = xmalloc (alloc_size);
> + allocation = XNEWVEC (char, alloc_size);
>
>page = (char *) (((size_t) allocation + G.pagesize - 1) &
> -G.pagesize);
>head_slop = page - allocation;
> @@ -842,7 +842,7 @@
> struct page_entry *e, *f = G.free_pages;
> for (a = enda - G.pagesize; a != page; a -= G.pagesize)
> {
> - e = xcalloc (1, page_entry_size);
> + e = XCNEWVAR (struct page_entry, page_entry_size);
> e->order = order;
> e->bytes = G.pagesize;
> e->page = a;
>
This is OK, with a ChangeLog entry, if it passes bootstrap with the
appropriate configure option.
Thanks.
Ian
