GCC 4.3.0 Status Report (2008-02-14)

Status == We are in Stage 3 and the trunk is open for regression and documentation fixes only. We have reached our goal of zero open P1 regressions (in fact several times, but each time different P1s appeared), so 4.3.0 release candidate will be created early next week. There is still time t

gcc 4.2.3 bootstrap *seems* to be broken on AIX 5.3

Hi *, when trying to installl gcc 4.2.3 on AIX 5.3 bootstraps fails in stage3 in configure-target-libmudflap when trying to detect used thread-model: checking for thread model used by GCC... aix aix is an unsupported thread package make[1]: *** [configure-target-libmudflap] Error 1 make[1]: Leav

GIMPLE: obtaining informations about variables

Hi all, I'm adding a new functionality to gcc for a university project. I know that, for each function, gcc creates a GIMPLE code that can be viewed as a control flow graph. I'm able to visit nodes (basic blocks), edges and statements of those graphs using some gcc macros. But how can I obtain the

Re: GCC 4.3.0 Status Report (2008-02-14)

g++ 4.3 broken on OpenBSD, see: http://gcc.gnu.org/ml/libstdc++/2008-02/msg00034.html Dongsheng 2008/2/14, Jakub Jelinek <[EMAIL PROTECTED]>: > Status > == > > We are in Stage 3 and the trunk is open for regression and documentation > fixes only. We have reached our goal of zero open P1 r

Re: gcc 4.2.3 bootstrap *seems* to be broken on AIX 5.3

> t veith writes: Thomas> when trying to installl gcc 4.2.3 on AIX 5.3 bootstraps fails in stage3 in configure-target-libmudflap when trying to detect used thread-model: Thomas> checking for thread model used by GCC... aix Thomas> aix is an unsupported thread package Thomas> make[1]: *** [co

Re: GIMPLE: obtaining informations about variables

On Thu, Feb 14, 2008 at 9:39 AM, Andrea Callia D'Iddio <[EMAIL PROTECTED]> wrote: > But how can I obtain the list of variables used by a function? (global > variables and also function local variables) Once you are in SSA form, the table REFERENCED_VARS contains all the symbols that are referen

Re: Optimizations documentation

Dorit Nuzman/Haifa/IBM wrote on 03/01/2008 18:53:25: > > g++-4.3 seems well ahead of other compilers in ability to vectorize STL > > iterators: > > http://softwarecommunity.intel.com/Wiki/HighPerformanceComputing/688.htm > > > good to know. > I browsed over the posting above; do you have a summa

Re: GCC 4.3.0 Status Report (2008-02-14)

Hi, Any chance of someone with ARM knowledge dealing with this issue before the branch is cut. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35071 Uros Bizjak thinks it is just a typo in an assembly file but no one who has commented on this PR is comfortable saying that. Just a wild guess, coul

[offtopic, nontechnical] GCC in Europe thru ITEA2

Hello All, A slightly offtopic post, non technical, concerning only "European" (including Switzerland and perhaps Israel) GCC developers. My apologies to others. There is an ITEA2 call http://www.itea2.org/ soon which might perhaps provide limited partial (30%) funding on GCC related work li

Re: [discuss] When is RBX used for base pointer?

> > Hi, > > > > On Wed, 13 Feb 2008, H.J. Lu wrote: > > > > > We need a callee-saved register for stack alignment. > > > > Can you expand on why? > > > > > In 64bit, our choices are rbx, and r12-r15. r12-r15 need the REX byte > > > and r12 also needs the SIB byte. So I'd like to use rbx. x

lto

diego and honza diego asked on irc were we planning to be able to serialize out all of the combined declarations. My response we could certainly use the machinery that we currently have to do this. However, I believe that Deigo's motivation is somewhat flawed, and for that matter the plans in the

Re: gcc 4.2.3 bootstrap *seems* to be broken on AIX 5.3

Thomas> when trying to installl gcc 4.2.3 on AIX 5.3 bootstraps fails in stage3 in configure-target-libmudflap when trying to detect used thread-model: Thomas> Anyone an idea? On Thu, Feb 14, 2008 at 09:54:17AM -0500, David Edelsohn wrote: > Do not enable Mudflap on AIX. Mudflap only is

Re: GCC 4.3.0 Status Report (2008-02-14)

Also regarding ARM, PR31849 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31849 ) is a show stopper, at least for some embedded bare metal targets, i.e. arm-elf and arm-none-eabi. Until size optimization at least matches gcc 4.2, gcc 4.3 will

Re: lto

Hi, > diego and honza > > diego asked on irc were we planning to be able to serialize out all of > the combined declarations. > My response we could certainly use the machinery that we currently have > to do this. > > However, I believe that Deigo's motivation is somewhat flawed, and for > that m

Re: GCC 4.3.0 Status Report (2008-02-14)

Alexandre Pereira Nunes wrote: Also regarding ARM, PR31849 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31849 ) is a show stopper, at least for some embedded bare metal targets, i.e. arm-elf and arm-none-eabi. Until size optimization at least ma

Re: GCC 4.3.0 Status Report (2008-02-14)

Hi, I opened one: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35200 Gcc 4.3 can't compile the current FSF binutils on Linux/ia32. H.J. --- On Thu, Feb 14, 2008 at 3:47 AM, Jakub Jelinek <[EMAIL PROTECTED]> wrote: > Status > == > > We are in Stage 3 and the trunk is open for regression an

Re: GCC 4.3.0 Status Report (2008-02-14)

On Thu, Feb 14, 2008 at 11:55 AM, H.J. Lu <[EMAIL PROTECTED]> wrote: > Gcc 4.3 can't compile the current FSF binutils on Linux/ia32. And this is not a bug in GCC. The binutils sources actually do violate C/C++ aliasing rules. It comes down to taking the address of the field of the union and then

future MELT (formerly Basilys) branch

Hello All, I am working on making all my code -see my home page where you can download it already- available as a GCC branch. Essentially it is a lisp dialect for coding middle end transformations & analysers I start writing the wiki page http://gcc.gnu.org/wiki/MiddleEndLispTranslator All

Re: lto

Jan Hubicka wrote: > Hi, > >> diego and honza >> >> diego asked on irc were we planning to be able to serialize out all of >> the combined declarations. >> My response we could certainly use the machinery that we currently have >> to do this. >> >> However, I believe that Deigo's motivation is s

Re: future MELT (formerly Basilys) branch

On Thu, 14 Feb 2008, Basile STARYNKEVITCH wrote: > All the legal stuff has been done. I have write access (after approval) > > > unfortunately my code is still very buggy and not entirely complete. Sounds like perfect material for a branch. :-) > Diego Novillo told me that I could make a branch

Possible ABI issue: PR33823

Could someone please take a look at PR33823? It may or may not involve an ABI change issue.

Re: Possible ABI issue: PR33823

On Thu, Feb 14, 2008 at 10:26 PM, Alexandre Pereira Nunes <[EMAIL PROTECTED]> wrote: > Could someone please take a look at PR33823? > > > It may or may not involve an ABI change issue. The bug doesn't mention an ABI change - the bug just mentions that the ABI used by GCC for packed bitfields is n

Re: GCC 4.3.0 Status Report (2008-02-14)

On Thu, Feb 14, 2008 at 7:28 PM, Alexandre Pereira Nunes <[EMAIL PROTECTED]> wrote: > Also regarding ARM, PR31849 > (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31849 > ) is a show stopper, > at least for some embedded bare metal targets, i.e. a

Re: GCC 4.3.0 Status Report (2008-02-14)

Richard Guenther escreveu: On Thu, Feb 14, 2008 at 7:28 PM, Alexandre Pereira Nunes <[EMAIL PROTECTED]> wrote: Also regarding ARM, PR31849 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31849 ) is a show stopper, at least for some embedded b

Re: GCC 4.3.0 Status Report (2008-02-14)

On Thu, Feb 14, 2008 at 7:42 PM, Joel Sherrill <[EMAIL PROTECTED]> wrote: > > Alexandre Pereira Nunes wrote: > > Also regarding ARM, PR31849 > > (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31849 > > ) is a show stopper, > > at least for some e

Re: GCC 4.3.0 Status Report (2008-02-14)

On Thu, Feb 14, 2008 at 10:42 PM, Joel Sherrill <[EMAIL PROTECTED]> wrote: > > Richard Guenther wrote: > > On Thu, Feb 14, 2008 at 7:42 PM, Joel Sherrill > > <[EMAIL PROTECTED]> wrote: > > > >> Alexandre Pereira Nunes wrote: > >> > Also regarding ARM, PR31849 > >> > (http://gcc.gnu.org/bugz

Re: GCC 4.3.0 Status Report (2008-02-14)

Richard Guenther wrote: On Thu, Feb 14, 2008 at 7:42 PM, Joel Sherrill <[EMAIL PROTECTED]> wrote: Alexandre Pereira Nunes wrote: > Also regarding ARM, PR31849 > (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31849 > ) is a show stopper, > a

Re: GCC 4.3.0 Status Report (2008-02-14)

On Thu, 14 Feb 2008, Joel Sherrill wrote: > Alexandre Pereira Nunes wrote: > > Also regarding ARM, PR31849 > > (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31849 > > ) is a show stopper, > > at least for some embedded bare metal targets, i.e. arm-

Can't reproduce PR34800/PR28706 with gcc 4.3 (arm-elf, i486-linux-gnu), close it?

Hi, I no longer can reproduce PR34800, can someone else verify and close it? Also, PR28706 seems fixed for both 4.3 and 4.2.2/4.2.3.

Re: [discuss] When is RBX used for base pointer?

> > > Hi, > > > > > > On Wed, 13 Feb 2008, H.J. Lu wrote: > > > > > > > We need a callee-saved register for stack alignment. > > > > > > Can you expand on why? > > > > > > > In 64bit, our choices are rbx, and r12-r15. r12-r15 need the REX byte > > > > and r12 also needs the SIB byte. So I'

Re: lto

> I have to admit that i had not considered the issue of having the later > stages of compilation of one function feed into the early stages of > another. The problem with this is that it implies a serial ordering of > the compilation and that is not going to yield a usable system for > compiling

Re: Some 4.4 project musings

> Diego Novillo wrote: > >On Fri, Feb 1, 2008 at 3:55 PM, Andrew MacLeod <[EMAIL PROTECTED]> wrote: > > > > > >> 1 - Pass cleanup. There have been rumblings about this, but I haven't > >> > > > >Yes, this is an area that is in desperate need of TLC. Your plan > >looks good to me. We need t

Re: GCC 4.3.0 Status Report (2008-02-14)

On Thu, 2008-02-14 at 22:17 +, Joseph S. Myers wrote: > On Thu, 14 Feb 2008, Joel Sherrill wrote: > > The m68k/coldfire is suffering from this regression the > > RTEMS community really would like to see resolved. > > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35088 > > Please try this