Re: (new) Failure building GFortran (Cygwin)
Ian Lance Taylor ha scritto:
This is OK, with a ChangeLog entry, if it passes bootstrap with the
appropriate configure option.
The following bootstraps rev. 137613, having configured as
${gcc_dir}/configure --prefix="${prefix_dir}" \
--exec-prefix="${eprefix_dir}" \
--sysconfdir="${sysconf_dir}" \
--libdir="${lib_dir}" \
--libexecdir="${libexec_dir}" \
--mandir="${man_dir}" \
--infodir="${info_dir}" \
--enable-languages=c,fortran \
--enable-bootstrap \
--enable-decimal-float=bid \
--enable-libgomp \
--enable-threads \
--enable-sjlj-exceptions \
--enable-version-specific-runtime-libs \
--enable-nls \
--enable-checking=release \
--disable-fixed-point \
--disable-libmudflap \
--disable-shared \
--disable-win32-registry \
--with-system-zlib \
--without-included-gettext \
--without-x
===
gcc/ChangeLog:
2008-07-08 Angelo Graziosi <[EMAIL PROTECTED]>
* ggc-page.c (alloc_page):
Substituting xmalloc, xcalloc with
XNEWVEC and XCNEWVAR macros which add the
needed casts.
--- gcc.orig/gcc/ggc-page.c 2008-06-29 06:39:16.0 +0200
+++ gcc/gcc/ggc-page.c 2008-07-08 09: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;
===
Cheers,
Angelo.
---
Facesti come quei che va di notte,
che porta il lume dietro e se' non giova,
ma dopo se' fa le persone dotte.
.
DANTE, Purgatorio, xxii 67-69
Re: free (static_array)
Thanks everyone! I will file a feature request for this via bugzilla. Regards, Sajish. - Original Message From: Joseph S. Myers <[EMAIL PROTECTED]> To: Michael Meissner <[EMAIL PROTECTED]> Cc: Denys Vlasenko <[EMAIL PROTECTED]>; Sajish V <[EMAIL PROTECTED]>; gcc@gcc.gnu.org Sent: Tuesday, July 1, 2008 5:07:05 PM Subject: Re: free (static_array) On Tue, 1 Jul 2008, Michael Meissner wrote: > On Tue, Jul 01, 2008 at 11:50:58AM +0200, Denys Vlasenko wrote: > > On Tuesday 01 July 2008 09:24, Sajish V wrote: > > > Thanks for the reply, Denys. > > > My question was, why doesn't gcc catch it during compilation? It is clear > > > that we are trying to free a variable from stack. Shouldn't gcc flag an > > > error for this during compilation? > > It could. Nobody has written the code to do so, and as they say patches are > welcome (assuming you have done the paperwork to legally contribute to GCC). > Have you filed a feature request via bugzilla so that it can be tracked? An error is inappropriate; undefined behavior only occurs on execution of the call to free, not on compilation of the program. A warning would be fine (as would converting the call to free into an abort). -- Joseph S. Myers [EMAIL PROTECTED]
Stack Versus Heap
Hello, I've read that allocating objects on the stack is faster than on the heap. What about deletion? Is deleting an object from the heap a lot less efficient? Are the performance differences so negligible that they won't matter? Are there any papers or articles that address the stack and heap implementations? Thanks, Mike
Re: Stack Versus Heap
[EMAIL PROTECTED] writes: > I've read that allocating objects on the stack is faster than on the > heap. What about deletion? Is deleting an object from the heap a lot > less efficient? Are the performance differences so negligible that they > won't matter? > > Are there any papers or articles that address the stack and heap > implementations? This question would be more appropriate for a general C language mailing list. The mailing list gcc@gcc.gnu.org is for people working on developing the gcc compiler. Please direct any followups elsewhere. Thanks. Yes, allocating objects on the stack is faster. Deleting them is also faster. The performance differences are not negligible. I don't know of any papers; it's just obvious if you look at the generated code. Ian
C++ Warnings on trunk
I was under the impression that these would be cleaned up before the -W options were applied to the trunk. The following are for an x86_64-pc-linux to x86_64-pc-mingw32 cross compiler: In file included from ../../../gcc/libgcc/../gcc/unwind-dw2.c:41: ../../../gcc/libgcc/../gcc/unwind-dw2-fde.h: In function 'get_cie': ../../../gcc/libgcc/../gcc/unwind-dw2-fde.h:163: warning: request for implicit conversion from 'const void *' to 'const struct dwarf_cie *' not permitted in C++ In file included from ../../../gcc/libgcc/../gcc/unwind-dw2-fde.c:41: ../../../gcc/libgcc/../gcc/unwind-dw2-fde.h: In function 'get_cie': ../../../gcc/libgcc/../gcc/unwind-dw2-fde.h:163: warning: request for implicit conversion from 'const void *' to 'const struct dwarf_cie *' not permitted in C++ In file included from ../.././gcc/gthr-default.h:1, from ../../../gcc/libgcc/../gcc/gthr.h:134, from ../../../gcc/libgcc/../gcc/unwind-sjlj.c:36: ../../../gcc/libgcc/../gcc/gthr-win32.h: In function '__gthread_setspecific': ../../../gcc/libgcc/../gcc/gthr-win32.h:615: warning: cast discards qualifiers from pointer target type ../../../gcc/libgcc/../gcc/unwind-sjlj.c: In function '_Unwind_SjLj_Register': ../../../gcc/libgcc/../gcc/unwind-sjlj.c:133: warning: request for implicit conversion from 'void *' to 'struct SjLj_Function_Context *' not permitted in C++ ../../../gcc/libgcc/../gcc/config/i386/gthr-win32.c: In function '__gthr_win32_setspecific': ../../../gcc/libgcc/../gcc/config/i386/gthr-win32.c:144: warning: cast discards qualifiers from pointer target type In file included from ../.././gcc/gthr-default.h:1, from ../../../gcc/libgcc/../gcc/gthr.h:134, from ../../../gcc/libgcc/../gcc/unwind-dw2.c:42: ../../../gcc/libgcc/../gcc/gthr-win32.h: In function '__gthread_setspecific': ../../../gcc/libgcc/../gcc/gthr-win32.h:615: warning: cast discards qualifiers from pointer target type In file included from ../.././gcc/gthr-default.h:1, from ../../../gcc/libgcc/../gcc/gthr.h:134, from ../../../gcc/libgcc/../gcc/unwind-dw2-fde.c:42:
Re: C++ Warnings on trunk
NightStrike <[EMAIL PROTECTED]> writes: > I was under the impression that these would be cleaned up before the > -W options were applied to the trunk. It's pretty hard to clean up all the warnings for every possible target. Also these are only warnings--this code is not compiled with -Werror. In this case, I argue that this code is always compiled with a C compiler, and should never be compiled by a C++ compiler. Therefore, I believe it is wrong for this code to be compiled with the -Wc++-compat warning enabled. This should be fixed somewhere in the configure script and/or Makefile. Ian
Re: C++ Warnings on trunk
On 7/8/08, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > NightStrike <[EMAIL PROTECTED]> writes: > > > I was under the impression that these would be cleaned up before the > > -W options were applied to the trunk. > > It's pretty hard to clean up all the warnings for every possible > target. Also these are only warnings--this code is not compiled with > -Werror. > > In this case, I argue that this code is always compiled with a C > compiler, and should never be compiled by a C++ compiler. Therefore, > I believe it is wrong for this code to be compiled with the > -Wc++-compat warning enabled. This should be fixed somewhere in the > configure script and/or Makefile. Is someone currently taking care of that?
Re: C++ Warnings on trunk
On 7/8/08, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > NightStrike <[EMAIL PROTECTED]> writes: > > > I was under the impression that these would be cleaned up before the > > -W options were applied to the trunk. > > It's pretty hard to clean up all the warnings for every possible > target. Also these are only warnings--this code is not compiled with > -Werror. > > In this case, I argue that this code is always compiled with a C > compiler, and should never be compiled by a C++ compiler. Therefore, > I believe it is wrong for this code to be compiled with the > -Wc++-compat warning enabled. This should be fixed somewhere in the > configure script and/or Makefile. Ok. How about these? ../../gcc/gcc/bitmap.c: In function 'bitmap_obstack_alloc_stat': ../../gcc/gcc/bitmap.c:359: warning: request for implicit conversion from 'void *' to 'struct bitmap_head_def *' not permitted in C++ ../../gcc/gcc/bitmap.c: In function 'bitmap_obstack_free': ../../gcc/gcc/bitmap.c:394: warning: request for implicit conversion from 'void *' to 'struct bitmap_element *' not permitted in C++
Re: GNU LD fails to generate correct ARM Thumb veneer
good morning Nick:
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.
did some research this morning and was able to finalize all the
information. reports have been filed with GCC Bugzilla,
Mikrocontroller Forum, and Comp.Arch.Embedded.
basically, i found a new error that masks the original error and
that prevents you from finding the original error of zero Interworking
code.
i created sample, simple assembly code for these online reports.
pls see these links for more information:
- GCC Bugzilla Bug 6726
http://sourceware.org/bugzilla/show_bug.cgi?id=6726
- GCC Bugzilla Bug 6727
http://sourceware.org/bugzilla/show_bug.cgi?id=6727
- Mikrocontroller.net Forum
http://en.mikrocontroller.net/topic/158791#699646
- Comp.Arch.Embedded
http://www.embeddedrelated.com/usenet/embedded/show/96927-1.php
GLOBAL CONDITIONS
if:
- you enable --gc-sections
- you enable Thumb Interworking
PROBLEM 1
- if you do not define program entry point:
you get the ldlang.c 4275 error
SOLUTION 1
- simply define entry point _start or whatever using --entry if
required
PROBLEM
- you position another section using --section-start before .text
using -Ttext: you get ZERO interworking code
SOLUTION
- position .data/other section AFTER .text. place -Ttext before
--section-start
or -Tdata.
i hope that this is helpful to you.
Aaron
--
{tel: +91-20-6526-7076; cell: +91-9970-591-079; fax: +1-800-450-5419}
Re: C++ Warnings on trunk
NightStrike <[EMAIL PROTECTED]> writes: > On 7/8/08, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: >> NightStrike <[EMAIL PROTECTED]> writes: >> >> > I was under the impression that these would be cleaned up before the >> > -W options were applied to the trunk. >> >> It's pretty hard to clean up all the warnings for every possible >> target. Also these are only warnings--this code is not compiled with >> -Werror. >> >> In this case, I argue that this code is always compiled with a C >> compiler, and should never be compiled by a C++ compiler. Therefore, >> I believe it is wrong for this code to be compiled with the >> -Wc++-compat warning enabled. This should be fixed somewhere in the >> configure script and/or Makefile. > > Is someone currently taking care of that? I don't know. It doesn't break the build and as such should be fixed soon but does not need to be fixed immediately. Ian
Re: C++ Warnings on trunk
NightStrike <[EMAIL PROTECTED]> writes: > On 7/8/08, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: >> NightStrike <[EMAIL PROTECTED]> writes: >> >> > I was under the impression that these would be cleaned up before the >> > -W options were applied to the trunk. >> >> It's pretty hard to clean up all the warnings for every possible >> target. Also these are only warnings--this code is not compiled with >> -Werror. >> >> In this case, I argue that this code is always compiled with a C >> compiler, and should never be compiled by a C++ compiler. Therefore, >> I believe it is wrong for this code to be compiled with the >> -Wc++-compat warning enabled. This should be fixed somewhere in the >> configure script and/or Makefile. > > Ok. How about these? > > ../../gcc/gcc/bitmap.c: In function 'bitmap_obstack_alloc_stat': > ../../gcc/gcc/bitmap.c:359: warning: request for implicit conversion >>From 'void *' to 'struct bitmap_head_def *' not permitted in C++ > ../../gcc/gcc/bitmap.c: In function 'bitmap_obstack_free': > ../../gcc/gcc/bitmap.c:394: warning: request for implicit conversion >>From 'void *' to 'struct bitmap_element *' not permitted in C++ Kaveh mentioned these in his original e-mail, explained why he found it difficult to fix, and added this to the Makefile so that it wouldn't break the build. # bitmap.c contains -Wc++compat warnings. bitmap.o-warn = -Wno-error This too should be fixed soon but need not be fixed immediately. Ian
Re: C++ Warnings on trunk
From: "Ian Lance Taylor" <[EMAIL PROTECTED]> Kaveh mentioned these in his original e-mail, explained why he found it difficult to fix, and added this to the Makefile so that it wouldn't break the build. # bitmap.c contains -Wc++compat warnings. bitmap.o-warn = -Wno-error This too should be fixed soon but need not be fixed immediately. Ian Right, here's the original link where I mention it: http://gcc.gnu.org/ml/gcc-patches/2008-06/msg01658.html This involves a cast from one type to another through a void*. I haven't been able to convince myself that this is completely safe. If someone understands why the code is violating type-safety intentionally and can explain why it's always safe, I would be happy to insert the appropriate cast and fix it.
Re: C++ Warnings on trunk
From: "NightStrike" <[EMAIL PROTECTED]> On 7/8/08, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: NightStrike <[EMAIL PROTECTED]> writes: > I was under the impression that these would be cleaned up before the > -W options were applied to the trunk. It's pretty hard to clean up all the warnings for every possible target. Also these are only warnings--this code is not compiled with -Werror. In this case, I argue that this code is always compiled with a C compiler, and should never be compiled by a C++ compiler. Therefore, I believe it is wrong for this code to be compiled with the -Wc++-compat warning enabled. This should be fixed somewhere in the configure script and/or Makefile. Is someone currently taking care of that? Yeah, it's on my list.
Re: (new) Failure building GFortran (Cygwin)
On Tue, Jul 8, 2008 at 3:48 AM, Angelo Graziosi
<[EMAIL PROTECTED]> wrote:
> Ian Lance Taylor ha scritto:
>>
>> This is OK, with a ChangeLog entry, if it passes bootstrap with the
>> appropriate configure option.
>
>
> The following bootstraps rev. 137613, having configured as
>
> ${gcc_dir}/configure --prefix="${prefix_dir}" \
> --exec-prefix="${eprefix_dir}" \
> --sysconfdir="${sysconf_dir}" \
> --libdir="${lib_dir}" \
> --libexecdir="${libexec_dir}" \
> --mandir="${man_dir}" \
> --infodir="${info_dir}" \
> --enable-languages=c,fortran \
> --enable-bootstrap \
> --enable-decimal-float=bid \
> --enable-libgomp \
> --enable-threads \
> --enable-sjlj-exceptions \
> --enable-version-specific-runtime-libs \
> --enable-nls \
> --enable-checking=release \
> --disable-fixed-point \
> --disable-libmudflap \
> --disable-shared \
> --disable-win32-registry \
> --with-system-zlib \
> --without-included-gettext \
> --without-x
>
> ===
> gcc/ChangeLog:
> 2008-07-08 Angelo Graziosi <[EMAIL PROTECTED]>
>
>
>* ggc-page.c (alloc_page):
>Substituting xmalloc, xcalloc with
>XNEWVEC and XCNEWVAR macros which add the
>needed casts.
>
>
>
> --- gcc.orig/gcc/ggc-page.c 2008-06-29 06:39:16.0 +0200
> +++ gcc/gcc/ggc-page.c 2008-07-08 09: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);
OK.
>
> 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);
OK.
> e->order = order;
> e->bytes = G.pagesize;
> e->page = a;
> ===
>
>
> Cheers,
> Angelo.
>
> ---
> Facesti come quei che va di notte,
> che porta il lume dietro e se' non giova,
> ma dopo se' fa le persone dotte.
> .
> DANTE, Purgatorio, xxii 67-69
>
Re: C++ Warnings on trunk
"Kaveh Ghazi" <[EMAIL PROTECTED]> writes: > Right, here's the original link where I mention it: > http://gcc.gnu.org/ml/gcc-patches/2008-06/msg01658.html > > This involves a cast from one type to another through a void*. I haven't > been able to convince myself that this is completely safe. If someone > understands why the code is violating type-safety intentionally and can > explain why it's always safe, I would be happy to insert the appropriate > cast and fix it. The two types bitmap_element and bitmap_head share a common initial sequence, and when following through ->heads only the first pointer is ever used. If you define a union type containing the two structs and make it visible at any point using that cast that would make it completely safe to the letter of the standard (6.5.2.3#5). Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
