Re: [4.6 branch] Issue with C++ references.
On Wed, Oct 19, 2011 at 06:08:15AM +0200, Jason Merrill wrote: > I'll backport that hunk, thanks for catching this. Great ! You're welcome Jason. Yvan
Re: adding destroyable objects into Ggc
Hi Gabriel, I also agree with you that GCC architecture is messy, and that scares newscomer a lot. Yes, but the way we improve it isn't, in my opinion, adding more GC. First we would like to remove complexity, and I do not think we should start by focusing on storage management until we get a clearer idea about lifetime of data structures we manipulate and how they mesh. We might find out (as I suspect) that the builtin GC of C (or C++) is remarkable at the job, provided we have a design that makes the lifetime obvious and take advantage of it. what you say sounds very sensible to me. If you look at LLVM, most memory management is done by using container objects (vectors, maps etc) that automatically free memory when they go out of scope. This takes care of 99% of memory management in a clean and simple way, which is a great situation to be in. Ciao, Duncan.
GCC 4.6.2 Release Candidate available from gcc.gnu.org
GCC 4.6.2 Release Candidate available from gcc.gnu.org The first release candidate for GCC 4.6.2 is available from ftp://gcc.gnu.org/pub/gcc/snapshots/4.6.2-RC-20111019 and shortly its mirrors. It has been generated from SVN revision 180180. I have so far bootstrapped and tested the release candidate on x86_64-linux and i686-linux. Please test it and report any issues to bugzilla. If all goes well, I'd like to release 4.6.2 in the middle of the next week.
Re: GCC 4.6.2 Release Candidate available from gcc.gnu.org
Hello, On 10/19/2011 02:13 PM, Jakub Jelinek wrote: [...] If all goes well, I'd like to release 4.6.2 in the middle of the next week. will there be another release candidate early next week? Is there a chance that these ARM regressions get fixed in this release? (A) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49641 (B) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50106 (C) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644 (A) is discussed here: http://old.nabble.com/-ARM--Fix-PR49641-td32016414.html (B) should be fixed tomorrow according to comment in PR. (C) is still unclear although this PR is open since 2008. In total this makes the GCC for the older ARM7TDMI-S and ARM926EJ-S (they are still in production) cores pretty dangerous. Have a nice day! -- Sebastian Huber, embedded brains GmbH Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany Phone : +49 89 18 90 80 79-6 Fax : +49 89 18 90 80 79-9 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: GCC 4.6.2 Release Candidate available from gcc.gnu.org
On Wed, Oct 19, 2011 at 02:57:26PM +0200, Sebastian Huber wrote: > On 10/19/2011 02:13 PM, Jakub Jelinek wrote: > [...] > >If all goes well, I'd like to release 4.6.2 in the middle of the next week. > > will there be another release candidate early next week? If possible, not. > Is there a chance that these ARM regressions get fixed in this release? > > (A) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49641 > (B) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50106 > (C) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644 > > (A) is discussed here: > > http://old.nabble.com/-ARM--Fix-PR49641-td32016414.html > > (B) should be fixed tomorrow according to comment in PR. > > (C) is still unclear although this PR is open since 2008. None of these is a very recent regression, all have been reported more than 2 months ago and there has been little progress on them (except for (C), where has been some progress, but not on the right solution), so unlikely. 4.6.2 certainly isn't the last 4.6 release, 4.6.3 will follow in 3 months or so. Jakub
Re: adding destroyable objects into Ggc
On Wed, 2011-10-19 at 00:45 -0500, Gabriel Dos Reis wrote: > On Wed, Oct 19, 2011 at 12:22 AM, Chiheng Xu wrote: > > > I recommend people interested in automatic dynamic memory management > > to read this book: > > Garbage Collection: Algorithms For Automatic Dynamic Memory > > Management(Richard Jones,1996) > > There is no reason to assume or to believe that people who argue for > less GC aren't familiar with GC -- a regrettably not so uncommon > jugemental mistake. > > In fact, the book you mention has been part of my essential books since > the year of its publication, and my other daytime job essentially relies GC. Possibly heading offtopic, but as of 2 months ago there's a sequel/new edition (which I'm thoroughly enjoying): The Garbage Collection Handbook: The Art of Automatic Memory Management (Richard Jones, Antony Hosking, Eliot Moss, 2011) ISBN: 978-1420082791 Hope this is helpful Dave
Re: adding destroyable objects into Ggc
Basile - 2011/10/18 Basile Starynkevitch : > Still, I find strange that while some very smart & nice GCC guys want to get > rid of Ggc, > no patch made into the trunk towards that goal (which I Basile dislike and > don't share, > so don't expect me Basile to work on this.). Well, there is my RTL-out-of-GC project to finish Bernd's work which got stalled due to work and studies, and certainly won't be finished for 4.7. In the end I believe that it is the patches that talk. Whatever patches are going to be submitted, reviewed and accepted, that is going to be GCC's future, be it memory management, or something else. -- Laurynas
Re: adding destroyable objects into Ggc
On Wed, Oct 19, 2011 at 04:31:48PM +0300, Laurynas Biveinis wrote:
> In the end I believe that it is the patches that talk. Whatever
> patches are going to be submitted, reviewed and accepted, that is
> going to be GCC's future, be it memory management, or something els
I was beginning to work on a patch to add finalizable (that is destroyable)
objects to Ggc. So I understand you Laurynas suggest that it might be worth
working on it (while I percieved most other emails, e.g. Ian's or Duncan's
messages, as a hint to avoid losing my time).
In http://gcc.gnu.org/ml/gcc/2011-10/msg00274.html I wrote:
# implementation tricks
First, I am looking into gcc/ggc-zone.c and I feel that each page entry should
have some destructor related data (which may be cleared if no destructor is
involved).
For large_page_entry each large object has such a page [one page per large
object], and
the page can easily contain a function pointer to the destructor.
For small_page_entry which contains several chunks for several objects, I have
the
feeling that we would have an array of destructor function pointers (or null).
I am not sure to understand the exact role of alloc_bits in small_page_entry
structure. I
believe that a bit is set there only for start address of each object, not for
the entire
range of the object. Could someone confirm my understanding please?
With gcc/ggc-page.c I believe we should have an array of destructors inside the
page_entry structures.
Laurynas & others, do you understand precisely the role of alloc_bits? Is a
bit set for every machine word (or some elementary allocation unit) which is
used,
or is it set only for the first word?
Do you think I should add some finalization related data to
small_page_entry, or do you suggest I need yet another kind of page_entry,
e.g. a finalizable_page_entry (for rather "small" finalized Ggc objects).?
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: [BUG?] GCC 4.5.2 produces deprecated ARM relocation
On 14/10/11 19:31, Ben Gamari wrote: > On Fri, 14 Oct 2011 18:38:26 +0100, Richard Earnshaw wrote: >> On 14/10/11 17:40, Ben Gamari wrote: >>> I was recently trying to test GCC's behavior in producing various types >>> of ARM relocations. In particular, I was trying to produce an >>> R_ARM_JUMP24 relocation, which requires veneer. It was suggested that >>> the code most likely to produce this relocation would involve some sort >>> of tail recursion. I wrote up a small test[1] involving interworking and >>> tail recursion to see what the produced object might look like. To my >>> surprise, I found that the compiler instead[2] produced the deprecated >>> R_ARM_PLT32 relocation. Considering the deprecated state of this >>> relocation type, should this be considered a bug? Being a linker >>> implementer, I for one would greatly appreciate it if GCC tried to only >>> use non-deprecated relocation types. I apologize if this has already >>> been fixed upstream. >>> >> >> The compiler doesn't produce relocations, but the assembler does. You >> need to make sure your binutils is up-to-date. >> > Fair enough. I suppose that makes more sense. > > $ as -v > GNU assembler version 2.21.0 (arm-linux-gnueabi) using BFD version (GNU > Binutils for Ubuntu) 2.21.0.20110327 > > > Seems that this is the latest stable release. You need to take that up with the binutils folks, they don't generally hang out on this list. R.
RE: GCC 4.7.0 Status Report (2011-09-09)
-Original Message- From: Gary Funck [mailto:g...@intrepid.com] Sent: Thursday, September 22, 2011 5:00 PM To: Jakub Jelinek Cc: gcc@gcc.gnu.org; Joseph S. Myers Subject: Re: GCC 4.7.0 Status Report (2011-09-09) On 09/09/11 09:09:30, Jakub Jelinek wrote: > [...] What is the status of lra, reload-2a, pph, cilkplus, gupc (I I apologize for the late response, my radar didn't catch this message. Cilkplus is not currently feature-complete. We definitely hope to have it completed as soon as we can. > assume at least some of these are 4.8+ material)? For GUPC, we are targeting GCC 4.8. thanks, - Gary
Re: adding destroyable objects into Ggc
On 19 October 2011 08:42, Duncan Sands wrote: > Hi Gabriel, > >>> I also agree with you that GCC architecture is messy, and that scares >>> newscomer a lot. >>> >> >> Yes, but the way we improve it isn't, in my opinion, adding more GC. >> First we would like to remove complexity, and I do not think we should >> start by focusing on storage management until we get a clearer idea >> about lifetime of data structures we manipulate and how they mesh. >> We might find out (as I suspect) that the builtin GC of C (or C++) is >> remarkable at the job, provided we have a design that makes the >> lifetime obvious and take advantage of it. > > what you say sounds very sensible to me. If you look at LLVM, most memory > management is done by using container objects (vectors, maps etc) that > automatically free memory when they go out of scope. This takes care > of 99% of memory management in a clean and simple way, which is a great > situation to be in. And LLVM seems to be very popular with newcomers to the code base. My impression is that noone working with the code is intimidated by properly-managed object lifetimes and the lack of garbage collection.
Nie jesteś zadowolony z obecnych usług księgowych? Obsługujemy W-wę i cały kraj !!
Szanując Państwa prywatność oraz mając na uwadze przepisy Ustawy o świadczeniu usług drogą elektroniczną, zwracam się z zapytaniem o możliwość przesłania oferty handlowej. Jeżeli jesteście Państwo zainteresowani otrzymaniem oferty dotyczącej profesjonalnej obsługi księgowej Państwa Firmy - prowadzonej prze Kancelarię Podatkową z 19 - letnim doświadczeniem na rynku i wysokokwalifikowaną kadrą księgowych, - Obniżeniem kosztów przy zachowaniu najwyższych standardów obsługi - dzięki oprogramowaniu najnowszej generacji możliwa obsługa nawet dużych firm w systemie on-line z calego kraju to proszę odpowiedzieć na tę wiadomość z treścią TAK w temacie lub treści - prześlemy ofertę, Wiadomość wysłana zgodnie z ustawą z dnia 26.08.2002 r. (Dz. U. nr 144, poz. 1204 o świadczeniu usług drogą elektroniczną). Wiadomość nadano na podstawie adresów e-mail ogólnodostępnych w Internecie, zgodnie z art. 25 ust. 2, pkt. 2 ustawy o ochronie danych osobowych. Osoby nie zainteresowane przepraszamy Wysyłka zrealizowana za pomocą programu MailBlaster - www.intralogic.eu/mailblaster
Re: gcc auto-omit-frame-pointer vs msvc longjmp
Kai Tietz wrote:
> 2011/10/18 Bob Breuer :
>> Kai Tietz wrote:
>>> 2011/10/17 Bob Breuer :
Richard Henderson wrote:
> On 10/17/2011 07:09 AM, Bob Breuer wrote:
>> Google finds a mention of longjmp failing with -fomit-frame-pointer:
>> http://lua-users.org/lists/lua-l/2005-02/msg00158.html
>>
>> Looks like gcc 4.6 turns on -fomit-frame-pointer by default.
> Hmm. This is the first I've heard of a longjmp implementation
> failing without a frame pointer. Presumably this is with the
> mingw i.e. msvc libc?
Yeah, mingw from www.mingw.org which I believe uses msvcrt.dll, package
gcc-core-4.6.1-2-mingw32-bin.
> This is something that could be worked around in gcc, I suppose.
> We recognize longjmp for some things, we could force the use of
> a frame pointer for msvc targets too.
>
> For now it might be best to simply force -fno-omit-frame-pointer
> for mingw host in the configure script.
Here's a testcase that crashes on the longjmp:
#include
#include
jmp_buf env;
int test(void)
{
int i;
asm("xor %%ebp,%%ebp" ::: "ebp");
i = setjmp(env);
printf("i = %d\n", i);
if (i == 0)
longjmp(env, 2);
return i;
}
int main(void)
{
return test();
}
Remove the asm statement to make it not crash. Obviously with
omit-frame-pointer, gcc can shove anything into ebp.
Bob
>>> This crash isn'r related to ebp existing, or not. The issue is the
>>> hidden argument of setjmp, which is missing. If you can try the
>>> following at top of file after include section.
>>>
>>> #define setjmp(BUF) _setjmpex((BUF), NULL)
>>> int __cdecl __attribute__ ((__nothrow__,__returns_twice__))
>>> _setjmp3(jmp_buf _Buf, void *_Ctx);
>>> ...
>> Did you mean _setjmp3 instead of _setjmpex? With _setjmp3, it works
>> without the asm, but still crashes if I zero out ebp before the setjmp.
>> Aren't the function arguments on the stack anyway?
>
> Yes, I mean _setjmp3 (pasto from headers and missed the second line
> prototyping _setjmp3).
> I repeat myself here. setjmp() has an hidden arguement, which is
> passed on x86 on stack. By not passing this required argument, setjmp
> will take a random-value from stack. In your case 'i'. btw if you
> would pre-initialize 'i' with zero, I would assume you won't see a
> crash, but anyway this is just by chance.
> For this I suggest to use here _setjmp3 instead, as here
> second-argument is documented as being present.
>
> Btw I tested your code with i686-pc-mingw32 version 4.6.x and 4.7.x
> gcc version. With my suggested pattern, I don't see a crash for your
> provide test-code with, or without zero-ing ebp.
We probably have a difference in build or run environment. I've
double-checked with another machine and can get the same crash in
longjmp when running the test executable on both WinXP and Win2k, but
not on Win7. So it looks like Microsoft may have changed this "feature"
somewhere between WinXP and Win7.
The msvcrt implementation of longjmp (or at least the one I'm looking
at) does a ebp based access using the saved value of ebp. Here's the
relevant disassembly of longjmp:
0x7801e6f3 in longjmpex () from C:\WINNT\system32\msvcrt.dll
(gdb) disas
Dump of assembler code for function longjmpex:
0x7801e6ef <+0>: mov0x4(%esp),%ebx
=> 0x7801e6f3 <+4>: mov(%ebx),%ebp
...
0x7801e73d <+78>:call 0x7800bd5e
...
0x7800bd5e <+56>:push %ebx
0x7800bd5f <+57>:push %ecx
0x7800bd60 <+58>:mov$0x7803dc64,%ebx
=> 0x7800bd65 <+63>:mov0x8(%ebp),%ecx
It crashes on the access of 0x8(%ebp). Those are the only 2 places
where this version of longjmp touches ebp. Is it possible to force a
stackframe by just adding a suitable attribute to either the setjmp
function prototype, or the function which calls setjmp?
Bob
Re: gcc auto-omit-frame-pointer vs msvc longjmp
On 10/19/2011 02:05 PM, Bob Breuer wrote:
> Is it possible to force a
> stackframe by just adding a suitable attribute to either the setjmp
> function prototype, or the function which calls setjmp?
The only thing I can think of that'll be portable to a large number
of versions of GCC is
{
int n; char *p;
asm("" : "=r"(n) : "0"(1));
p = __builtin_alloca(n);
asm("" : : "r"(p));
}
The first asm prevents constant propagation of the 1 to the alloca;
the second asm prevents the alloca from being considered dead code.
r~
[RFC] New git-only branch for Fission project
I'd like to create a new "fission" branch on the GIT mirror at ssh://gcc.gnu.org/git/gcc.git. This branch will host the changes that Sterling and I will be making to support splitting the debug info into separate files -- and, as a byproduct, fixing the pubnames and pubtypes tables so they can be used to create a gdb index. A while ago, I posted a summary of the Fission project on the GCC wiki: http://gcc.gnu.org/wiki/DebugFission I expect we'll be ready to merge our work into trunk when Stage 1 opens for GCC 4.8. Any objections? Is it OK to make a git-only branch? -cary
Getting DWARF codes from RTX
Hello Everyone, Is there a function (or a series of functions) in GCC using which I can convert a register number (either in RTX or int) to DWARF code? Any help is greatly appreciated! Thanks, Balaji V. Iyer.
Re: adding destroyable objects into Ggc
Basile Starynkevitch > I would like to add destroyable objects into Ggc (the GCC garbage > collector, see files gcc/ggc*.[ch]). > > The main motivation is to permit C++ objects to be garbage collected > (I discussed that briefly in the Gcc meeting at Google in London): > adding destroyable object is a prerequisite for that goal. The C++ standard has support for garbage collection, and the general consensus of the committee is that object garbage collected do not execute their destructors. Can you be specific about the use case that is driving you towards this solution? Ian Lance Taylor > I think this type of thing is conventionally called a "finalizer". Basile Starynkevitch writes: > Yes, if you like it. However both Boehm's GC and Java GC attach a > more specific (and perhaps more powerful) meaning to that term. How is what you propose distinct from the finalization mechanism? http://www.hpl.hp.com/personal/Hans_Boehm/gc/finalization.html > But [independently of MELT] I don't believe that GCC will be able to > return to manual memory management. There have been valid reasons > (long time ago) to implement Ggc, and as far as I understand GCC, I > don't see these reasons becoming invalid, on the contrary. I don't > like much the implementation of Ggc [in particular, I badly dislike > the lack of support for local variables in it], but I do believe > that a five-million line compilers (or 8MLOC, depending how you > count them) with a community of hundreds of developers badly need an > automated way to deal with memory. There is a world of difference between using manual memory management in C and using smart pointers in C++. The later can be handled, for the most part, with local coding rules. The former, not so much. More importantly, the C++ standard library provides flexible data structures so that programmers need not worry about either. Basile Starynkevitch > My strong belief is that any *big* compiler needs some automated way > to deal with memory (including circular references, which auto_ptr > is not very happy about). It can be Ggc (I am not very happy of it) > or something else. While not entirely relevant, compiler needs a way to manage circular relationships, but it does not need to manage circular pointers. Programmers have gotten so accustomed to representing relationships with pointers that the alternatives have almost been forgotten. > And in my perception, auto_ptr are a poor man's way of implementing > a garbage collection, it is not a way to avoid it. Auto_ptr has known weaknesses, and has been supplanted by shared_ptr, unique_ptr, and weak_ptr. Even so, none of these are a "poor man's garbage collector" as competent use of them leaves little garbage to be collected. Chiheng Xu > I recommend people interested in automatic dynamic memory management > to read this book: Garbage Collection: Algorithms For Automatic > Dynamic Memory Management(Richard Jones,1996) > > The importance of garbage collection in large software project and > why reference counting based solution is inefficient and can't be > good general "garbage collection" mechanism is clearly explained. I am willing to wager that the implicit assumption here is that relationships are managed with pointers. I am also willing to wager that the author is willing to accept a 5x increase in memory use to get cited benefits. While that tradeoff is good for many applications, it is not good for all applications. -- Lawrence Crowl
Re: gcc auto-omit-frame-pointer vs msvc longjmp
Hi, all
I think this issue causes the gdb crash on XP.
You can see the thread: http://sourceware.org/ml/gdb/2011-10/msg00056.html
My many friends and I can reproduce this crash issue, but no problem on Win7.
On Thu, Oct 20, 2011 at 5:05 AM, Bob Breuer wrote:
> Kai Tietz wrote:
>> 2011/10/18 Bob Breuer :
>>> Kai Tietz wrote:
2011/10/17 Bob Breuer :
> Richard Henderson wrote:
>> On 10/17/2011 07:09 AM, Bob Breuer wrote:
>>> Google finds a mention of longjmp failing with -fomit-frame-pointer:
>>> http://lua-users.org/lists/lua-l/2005-02/msg00158.html
>>>
>>> Looks like gcc 4.6 turns on -fomit-frame-pointer by default.
>> Hmm. This is the first I've heard of a longjmp implementation
>> failing without a frame pointer. Presumably this is with the
>> mingw i.e. msvc libc?
> Yeah, mingw from www.mingw.org which I believe uses msvcrt.dll, package
> gcc-core-4.6.1-2-mingw32-bin.
>
>> This is something that could be worked around in gcc, I suppose.
>> We recognize longjmp for some things, we could force the use of
>> a frame pointer for msvc targets too.
>>
>> For now it might be best to simply force -fno-omit-frame-pointer
>> for mingw host in the configure script.
> Here's a testcase that crashes on the longjmp:
>
> #include
> #include
>
> jmp_buf env;
>
> int test(void)
> {
> int i;
>
> asm("xor %%ebp,%%ebp" ::: "ebp");
>
> i = setjmp(env);
> printf("i = %d\n", i);
>
> if (i == 0)
> longjmp(env, 2);
>
> return i;
> }
>
> int main(void)
> {
> return test();
> }
>
> Remove the asm statement to make it not crash. Obviously with
> omit-frame-pointer, gcc can shove anything into ebp.
>
> Bob
This crash isn'r related to ebp existing, or not. The issue is the
hidden argument of setjmp, which is missing. If you can try the
following at top of file after include section.
#define setjmp(BUF) _setjmpex((BUF), NULL)
int __cdecl __attribute__ ((__nothrow__,__returns_twice__))
_setjmp3(jmp_buf _Buf, void *_Ctx);
...
>>> Did you mean _setjmp3 instead of _setjmpex? With _setjmp3, it works
>>> without the asm, but still crashes if I zero out ebp before the setjmp.
>>> Aren't the function arguments on the stack anyway?
>>
>> Yes, I mean _setjmp3 (pasto from headers and missed the second line
>> prototyping _setjmp3).
>> I repeat myself here. setjmp() has an hidden arguement, which is
>> passed on x86 on stack. By not passing this required argument, setjmp
>> will take a random-value from stack. In your case 'i'. btw if you
>> would pre-initialize 'i' with zero, I would assume you won't see a
>> crash, but anyway this is just by chance.
>> For this I suggest to use here _setjmp3 instead, as here
>> second-argument is documented as being present.
>>
>> Btw I tested your code with i686-pc-mingw32 version 4.6.x and 4.7.x
>> gcc version. With my suggested pattern, I don't see a crash for your
>> provide test-code with, or without zero-ing ebp.
>
>
> We probably have a difference in build or run environment. I've
> double-checked with another machine and can get the same crash in
> longjmp when running the test executable on both WinXP and Win2k, but
> not on Win7. So it looks like Microsoft may have changed this "feature"
> somewhere between WinXP and Win7.
>
> The msvcrt implementation of longjmp (or at least the one I'm looking
> at) does a ebp based access using the saved value of ebp. Here's the
> relevant disassembly of longjmp:
>
> 0x7801e6f3 in longjmpex () from C:\WINNT\system32\msvcrt.dll
> (gdb) disas
> Dump of assembler code for function longjmpex:
> 0x7801e6ef <+0>: mov 0x4(%esp),%ebx
> => 0x7801e6f3 <+4>: mov (%ebx),%ebp
> ...
> 0x7801e73d <+78>: call 0x7800bd5e
> ...
> 0x7800bd5e <+56>: push %ebx
> 0x7800bd5f <+57>: push %ecx
> 0x7800bd60 <+58>: mov $0x7803dc64,%ebx
> => 0x7800bd65 <+63>: mov 0x8(%ebp),%ecx
>
> It crashes on the access of 0x8(%ebp). Those are the only 2 places
> where this version of longjmp touches ebp. Is it possible to force a
> stackframe by just adding a suitable attribute to either the setjmp
> function prototype, or the function which calls setjmp?
>
> Bob
>
--
Best Regards,
xunxun
Re: GCC 4.6.2 Release Candidate available from gcc.gnu.org
I think after the 4.6.2 RC, gfortran' io changed something. The 4.6.2 RC libgfortran section can't be built on mingw/mingw64. It will cause: libtool: compile: i686-w64-mingw32-gcc -L/mingw/i686-w64-mingw32/lib -L/mingw/mingw/lib -isystem /mingw/i686-w64-mingw32/include -isystem /mingw/mingw/include -DHAVE_CONFIG_H -I. -I../.././libgfortran -iquote../.././libgfortran/io -I../.././libgfortran/../gcc -I../.././libgfortran/../gcc/config -I../.././libgfortran/../libquadmath -I../../host-i686-w64-mingw32/gcc -D_GNU_SOURCE -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -fcx-fortran-rules -ffunction-sections -fdata-sections -g -pipe -O2 -I/mingw/include -MT file_pos.lo -MD -MP -MF .deps/file_pos.Tpo -c ../.././libgfortran/io/file_pos.c -o file_pos.o ../.././libgfortran/io/file_pos.c: In function 'st_flush': ../.././libgfortran/io/file_pos.c:457:20: error: 'stream' has no member named 'fd' The latest 4.6 branch libgfortran has no problem. I would hope you can fix the problem next RC or release. On Wed, Oct 19, 2011 at 8:13 PM, Jakub Jelinek wrote: > GCC 4.6.2 Release Candidate available from gcc.gnu.org > > The first release candidate for GCC 4.6.2 is available from > > ftp://gcc.gnu.org/pub/gcc/snapshots/4.6.2-RC-20111019 > > and shortly its mirrors. It has been generated from SVN revision 180180. > > I have so far bootstrapped and tested the release candidate on > x86_64-linux and i686-linux. Please test it and report any issues to > bugzilla. > > If all goes well, I'd like to release 4.6.2 in the middle of the next week. > -- Best Regards, xunxun
Re: Getting DWARF codes from RTX
"Iyer, Balaji V" writes: > Is there a function (or a series of functions) in GCC using which I can > convert a register number (either in RTX or int) to DWARF code? Are you looking for DWARF_FRAME_REGNUM? If not, what do you mean by DWARF code? Do you mean inside gcc, or in code compiled by gcc? Please give an example. Ian
Re: adding destroyable objects into Ggc
On Wed, 19 Oct 2011 21:17:47 -0700
Lawrence Crowl wrote:
> Basile Starynkevitch
> > I would like to add destroyable objects into Ggc (the GCC garbage
> > collector, see files gcc/ggc*.[ch]).
> >
> > The main motivation is to permit C++ objects to be garbage collected
> > (I discussed that briefly in the Gcc meeting at Google in London):
> > adding destroyable object is a prerequisite for that goal.
>
> The C++ standard has support for garbage collection, and the general
> consensus of the committee is that object garbage collected do not
> execute their destructors.
I don't understand well this decision. Do you have URLs describing it
motivations?
>
> Can you be specific about the use case that is driving you towards
> this solution?
>
PPL [Parma Polyhedra Library] data, like e.g. ppl_Constraint_t [from header
that is, using a C API] comes to mind. If you want to share PPL stuff
between
several passes, it can be very handy to add PPL data inside GTY-ed stuff. If
that GTY-ed
stuff is deleted by Ggc, and if the PPL destructor (e.g. ppl_delete_Constraint
in that
case) is not called, you get a memory leak. (In the MELT runtime, I have a
special cases
for things like that, and they are really ad-hoc). And sharing PPL data between
several
passes is useful: a first pass detect some optimization situations using PPL,
and a later
pass actually does the optimizations by modifying the Gimple-s...
Very probably, if Graphite passes will add hooks for plugins [current plugins
have no
good way to find what Graphite consider as induction variables inside
graphite-optimized
loops, except by looking into symbol names like "graphite_IV" inside SSA names;
that
would be much easier if Graphite provides a hook to tell about them, so I do
hope
Graphit will add more plugin hooks!], they will benefit from it; when
discussing about
Graphite people at INRIA, I got the impression that they would be happy of such
features
(and conversely, plugins, in particular MELT, would benefit from more hooks from
Graphite).
Other usages include other finalized data, like FILE* [if a plugin need a FILE*
inside
GTY-ed data to be shared by several passes, it would be handy that when the
GTY-ed object
is deleted, the FILE* is fclosed] or even std::ostringstream or std::ostring-s
shared
between several passes.
Maybe a compilation server might also find finalization useful.
More generally, any resource which is added, e.g. by a plugin, into a GTY-ed
type and
which is used by several passes could benefit of finalizers, because from
inside a plugin
you cannot easily determine when a GTY-ed data is no more used.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
