RFC: Make dllimport/dllexport imply default visibility

Consider: struct __attribute__((vsibility ("hidden"))) S { void __declspec(dllimport) f(); }; At present, we give "f" hidden visibility. That seems odd since the user has explicitly told us that the symbol is coming from another shared library. I'm planning to make any dllimport or dlle

Re: Some regressions from the dataflow merge

Seongbae Park (???, ???) wrote: ... I'm looking at it. It is either a scheduler problem, or some other problem downstream triggered by the scheduler. However, I'm having hard time adding fine-grained dbg_cnt to our scheduler - do you know who might be interested in adding insn level dbg_cnt in

Libmudflap for sh-elf toolchain cannot access environment variable MUDFLAP_OPTIONS

Hi, I successfully built the sh-elf cross compiler on the x86/linux host enabled with libmudflap by specifying the correct entry point in libmudflap's configure file. (newlib-1.15.0 was used) I compiled a simple c code with following options on linux shell: sh-elf-gcc -fmudflap test.c -stat

Re: Libmudflap for sh-elf toolchain cannot access environment variable MUDFLAP_OPTIONS

Deepen Mantri wrote: How to make x86/linux shell's environment variable (MUDFLAP_OPTIONS) accessible to test.out while executing it through the sh-elf simulator? I don't know about other targets, but the SH newlib/crt/simulator doesn't do anything with the environment. You could spend ages

Some thoughts about steerring commitee work

Sorry, my first reaction to latest SC announcements was to write immediately. But I took time to think more about the situation (now seing a discussion about "Non-Autopoiesis Maintainers" I am more convinced in my decision). Here is my thoughts. I apologize in advance if somebody feel offended

Re: Some thoughts about steerring commitee work

> Looking at the last SC announcement, it is probably easy to get the > impression that SC is shrunk to David Edelsohn, may be Mark Mitchell > and Gerald Pfeifer. Those three people are indeed the ones that usually *speak for* the SC, but you have absolutely no way of knowing how many of the mem

Resuming SPEC performance tracking at RedHat

People from gcc community found that GCC performance tracking at RedHat stopped after Diego left RedHat. As I understand this was helpful for some of them. Therefore we decided to resume GCC Performance Tracking on GCC. This work is based on Diego Novillo's scripts (Diego, thanks for the good

Re: Resuming SPEC performance tracking at RedHat

On 6/15/07 9:21 AM, Vladimir N. Makarov wrote: > https://vmakarov.108.redhat.com/nonav/spec/index.html Awesome! Could you send me the scripts? You had mentioned a few modifications that sounded very useful. Thanks.

Re: Resuming SPEC performance tracking at RedHat

Richard Guenther wrote: On 6/15/07, Vladimir N. Makarov <[EMAIL PROTECTED]> wrote: Just to summarize what we test at SUSE currently: Richard, thanks for the information. - SPEC2000 is tested in various variants on AMD x86_64, including 32bit results and FDO runs. - SPEC2000 is tested on

Libmudflap for sh-elf toolchain cannot access environment variable MUDFLAP_OPTIONS

Hi, I successfully built the sh-elf cross compiler on the x86/linux host enabled with libmudflap by specifying the correct entry point in libmudflap's configure file. (newlib-1.15.0 was used) I compiled a simple c code with following options on linux shell: sh-elf-gcc -fmudflap test.c -s

Re: Resuming SPEC performance tracking at RedHat

On 6/15/07, Vladimir N. Makarov <[EMAIL PROTECTED]> wrote: People from gcc community found that GCC performance tracking at RedHat stopped after Diego left RedHat. As I understand this was helpful for some of them. Therefore we decided to resume GCC Performance Tracking on GCC. This work is

Re: Some thoughts about steerring commitee work

Richard Kenner wrote: Looking at the last SC announcement, it is probably easy to get the impression that SC is shrunk to David Edelsohn, may be Mark Mitchell and Gerald Pfeifer. Those three people are indeed the ones that usually *speak for* the SC, but you have absolutely no way of kn

RE: Libmudflap for sh-elf toolchain cannot access environment variable MUDFLAP_OPTIONS

Andrew STUBBS wrote: >It's probably easier to place a putenv("MUDFLAP_OPTIONS=blah") >in your code, or inject it from the debugger. Thanks for the reply. MUDFLAP_OPTIONS environment variable is used to control the run time behaviour of instrumented code generated with the help of libmudflap li

Re: Libmudflap for sh-elf toolchain cannot access environment variable MUDFLAP_OPTIONS

Hi - > >It's probably easier to place a putenv("MUDFLAP_OPTIONS=blah") > >in your code, or inject it from the debugger. > > [...] > We cannot place putenv("MUDFLAP_OPTIONS=<..>") in > libmudflap's __mf_init() function existing in mf-runtime.c. > Placing putenv(..) will limit the instrumented code

Re: Libmudflap for sh-elf toolchain cannot access environment variable MUDFLAP_OPTIONS

Deepen Mantri wrote: We cannot place putenv("MUDFLAP_OPTIONS=<..>") in libmudflap's __mf_init() function existing in mf-runtime.c. Placing putenv(..) will limit the instrumented code's runtime behaviour only to option being set in the code by me. Well no, that would be silly - you might as wel

RE: Libmudflap for sh-elf toolchain cannot access environment variable MUDFLAP_OPTIONS

Frank Eigler wrote: >You need to teach your simulator to pass environment variables on ... Thanks for the reply. To pass on the environment variables from simulator to a.out which is targeted for machine different than host would require simulator to pass the data to a.out (other than command

RE: Some thoughts about steering committee work

> Sorry, my first reaction to latest SC announcements was to write > immediately. But I took time to think more about the situation (now > seing a discussion about "Non-Autopoiesis Maintainers" I am more > convinced in my decision). Here is my thoughts. I apologize in advance > if somebody feel

Incorrect bitfield aliasing with Tree SSA

get_alias_set and internally record_component_aliases makes assumptions about the IR that are only valid in RTL. As a consequence the constant 1 is propagated into the function call in the example below (I found this issue with 4.1 but it is also present on trunk): struct s { long long a:

Re: machine learning for loop unrolling

Thank you everybody with the helpful input. I ran into a small problem. I have some features ready (well, not everything I wanted, but still good enough). I'm now trying to instrument the resulting code to time each loop independently. Essentially, what I want is to programatically modify loops f

Re: Some thoughts about steerring commitee work

On Fri, Jun 15, 2007 at 08:50:49AM -0400, Vladimir N. Makarov wrote: > Looking at the last SC announcement, it is probably easy to get the > impression that SC is shrunk to David Edelsohn, may be Mark Mitchell > and Gerald Pfeifer. That would be a mistake. Different SC members play different role

Re: Some thoughts about steerring commitee work

Joe Buck wrote: On Fri, Jun 15, 2007 at 08:50:49AM -0400, Vladimir N. Makarov wrote: Looking at the last SC announcement, it is probably easy to get the impression that SC is shrunk to David Edelsohn, may be Mark Mitchell and Gerald Pfeifer. That would be a mistake. Different SC memb

Re: [fixed-point] Fixed-point branch merge plan

Fu, Chao-Ying wrote: > As Mark requested, we propose a merge plan for the fixed-point branch > as follows. I think this is a good plan. Since there have been no negative comments, let's go with this approach. I've looked at the big patch you posted, and I think it looks very good overall. Yo

Re: Some thoughts about steerring commitee work

On Fri, Jun 15, 2007 at 01:49:13PM -0400, Vladimir N. Makarov wrote: > Thanks, for the clarification, Joe. I always like to put users first. > But I've just been thinking how some SC members which are not involed > development make right decision during a vote about the appointments. Generally

Re: [patch,committed] Make Fortran maintainers "Non-Autopoiesis Maintainers"

> On Thu, Jun 14, 2007 at 10:28:58PM -0700, Brooks Moses wrote: > > At 09:40 PM 6/14/2007, Steve Kargl wrote: > > >On Thu, Jun 14, 2007 at 08:48:22PM -0700, Brooks Moses wrote: > > >> I have no objection to this as a custom for GFortran, certainly -- I > > >> think it's a very good idea, and as a c

Re: Some thoughts about steerring commitee work

"Vladimir N. Makarov" <[EMAIL PROTECTED]> writes: > For example, about latest appointments of Diego and Ian as GWP. They > are good guys but I don't see Diego actively working on RTL or Ian > actively working on tree-SSA. Just for the record, I was already a full middle-end maintainer before the

Access to raw repositories

Hello, I'd like to clone the gcc and src repositories to experiment importing them into git and other SCMs. I could also do this remotely, although it's very time consuming, expecially for cvs. I'm a GCC maintainer, but I don't have a full shell account on sources.redhat.com. Anything that wou

Re: [patch,committed] Make Fortran maintainers "Non-Autopoiesis Maintainers"

Kenneth Zadeck wrote: I wish to applogize to the Fortran maintainers if I have sturred up a hornet's nest. I had been told that the Fortran maintainers followed the rule, as a convention among themselves, that individuals did not approve their own non trivial patches. When the three of us becam

Re: Access to raw repositories

Bernardo Innocenti <[EMAIL PROTECTED]> writes: > I'm a GCC maintainer, but I don't have a full shell account on > sources.redhat.com. Anything that would provide rsync access > would suffice. See . Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Li

Re: Some thoughts about steerring commitee work

Ian Lance Taylor wrote: I've been lobbying for some time, on IRC, for more people to be able to fill in the holes in the maintainership patterns. Most of the existing global maintainers are inactive. There are areas of the code which are not covered by the other maintainership groupings. Thus

Re: machine learning for loop unrolling

Hello, > Of course, instead of clock(), I'd like to use a non-intrusive > mechanism. However, my research on this topic didn't lead to anything > but perfsuite, which doesn't work very well for me (should it?). > > So here are the questions > > - how can I actually insert the code (I need to do

Re: [patch,committed] Make Fortran maintainers "Non-Autopoiesis Maintainers"

Brooks Moses wrote: I'm not entirely sure that I agree with formalizing this for the Fortran maintainers in bulk, at least without discussion. My understanding (and it's entirely possible that I've missed something) was that this wasn't so much a formal rule as a general custom -- and, being a

Re: Some thoughts about steerring commitee work

"Vladimir N. Makarov" <[EMAIL PROTECTED]> writes: > Ian Lance Taylor wrote: > > >I've been lobbying for some time, on IRC, for more people to be able > >to fill in the holes in the maintainership patterns. Most of the > >existing global maintainers are inactive. There are areas of the code > >w

Re: [patch,committed] Make Fortran maintainers "Non-Autopoiesis Maintainers"

On 6/15/07 3:31 PM, Tobias Schlüter wrote: > follow-up, and I'm fine with that. OTOH I do object (with a smiley) to > being labeled something that -- even though I can understand its meaning > from the ancient greek I studied -- I haven't the slightest idea how to > pronounce (sorry, "autopoiesis

Re: Some thoughts about steerring commitee work

Ian Lance Taylor wrote: "Vladimir N. Makarov" <[EMAIL PROTECTED]> writes: Ian Lance Taylor wrote: I've been lobbying for some time, on IRC, for more people to be able to fill in the holes in the maintainership patterns. Most of the existing global maintainers are inactive. There ar

Re: Some thoughts about steerring commitee work

> Please, just look at those charts > > https://vmakarov.108.redhat.com/nonav/spec/comparison.html > > The compilation speed decrease without a performance improving (at least > for the default case) is really scary. Right, I also found those charts a bit depressing, given the time and energy tha

Re: Some thoughts about steerring commitee work

On 6/15/07, Eric Botcazou <[EMAIL PROTECTED]> wrote: > Please, just look at those charts > > https://vmakarov.108.redhat.com/nonav/spec/comparison.html > > The compilation speed decrease without a performance improving (at least > for the default case) is really scary. Right, I also found those

Re: Incorrect bitfield aliasing with Tree SSA

On 6/15/07, Adam Nemet <[EMAIL PROTECTED]> wrote: get_alias_set and internally record_component_aliases makes assumptions about the IR that are only valid in RTL. What is this assumption, exactly?

Re: Some thoughts about steerring commitee work

Eric Botcazou wrote: Please, just look at those charts https://vmakarov.108.redhat.com/nonav/spec/comparison.html The compilation speed decrease without a performance improving (at least for the default case) is really scary. Right, I also found those charts a bit depressing, given the

Re: Some thoughts about steerring commitee work

> No, GCC hit a fundamental wall because its backend was not modern. > The code we generate out of tree-ssa is in general, as good or better > than other compilers generate out of their middle ends. > > The problem remaining is that they have much better backends then us. > > Until dataflow, *nobod

Re: Some thoughts about steerring commitee work

Eric Botcazou wrote: No, GCC hit a fundamental wall because its backend was not modern. The code we generate out of tree-ssa is in general, as good or better than other compilers generate out of their middle ends. The problem remaining is that they have much better backends then us. Until data

Re: Incorrect bitfield aliasing with Tree SSA

Daniel Berlin writes: > On 6/15/07, Adam Nemet <[EMAIL PROTECTED]> wrote: > > get_alias_set and internally record_component_aliases makes > > assumptions about the IR that are only valid in RTL. > > What is this assumption, exactly? That non-addressable fields are always accessed through alias se

Re: RFC: Make dllimport/dllexport imply default visibility

On Jun 15, 2007, at 12:48 AM, Mark Mitchell wrote: Consider: struct __attribute__((vsibility ("hidden"))) S { void __declspec(dllimport) f(); }; At present, we give "f" hidden visibility. That seems odd since the user has explicitly told us that the symbol is coming from another shared l

GCC Status Report (2007-06-15)

GCC 4.3 Stage 1 is now closed. After this point, major new functionality (i.e., the sort of thing deserving its own branch) that has not already been submitted will be held for GCC 4.4. Hopefully, the PTR_PLUS branch and the fixed-point branch will be merged in the relatively near future. I am a

gcc-4.3-20070615 is now available

Snapshot gcc-4.3-20070615 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20070615/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk

Re: RFC: Make dllimport/dllexport imply default visibility

Bill Wendling wrote: > On Jun 15, 2007, at 12:48 AM, Mark Mitchell wrote: > >> Consider: >> >> struct __attribute__((vsibility ("hidden"))) S { >>void __declspec(dllimport) f(); >> }; >> >> At present, we give "f" hidden visibility. That seems odd since the >> user has explicitly told us th

Re: Some thoughts about steerring commitee work

Our backends have done roughly the same good/bad job of generating code since, well, forever. Until that changes, you will see that the only performance improvements you get in the general case are things that the backend was too dumb to get in the first place (IE loads, stores

Re: RFC: Make dllimport/dllexport imply default visibility

On Jun 15, 2007, at 3:45 PM, Mark Mitchell wrote: Bill Wendling wrote: On Jun 15, 2007, at 12:48 AM, Mark Mitchell wrote: Consider: struct __attribute__((vsibility ("hidden"))) S { void __declspec(dllimport) f(); }; At present, we give "f" hidden visibility. That seems odd since the

Re: Incorrect bitfield aliasing with Tree SSA

On 6/15/07, Adam Nemet <[EMAIL PROTECTED]> wrote: Daniel Berlin writes: > On 6/15/07, Adam Nemet <[EMAIL PROTECTED]> wrote: > > get_alias_set and internally record_component_aliases makes > > assumptions about the IR that are only valid in RTL. > > What is this assumption, exactly? That non-addr

I'm sorry, but this is unacceptable (union members and ctors)

Salutations everyone, I'm afraid I have a fairly major project which requires a Linux port. The problem is, development has been put off for a while because GCC lacks any means or work around which permits nesting ctors inside a union. The effort is mature enough that it needs a public release,

Re: RFC: Make dllimport/dllexport imply default visibility

Chris Lattner wrote: > This construct seems like it should be rejected by the C++ front-end. > The source is making two contradictory claims: the struct is not visible > outside this library, but part of it is implemented outside of it. I don't think there's a contradiction. The declaration on

Re: RFC: Make dllimport/dllexport imply default visibility

On Jun 15, 2007, at 3:45 PM, Mark Mitchell wrote: Bill Wendling wrote: Perhaps I'm mistaken, but the above seems to indicate to me that the structure (and, therefore, all of its fields) are hidden, one of its functions is from an external and visible source. Yes. And, therefore, emitting a u

Re: I'm sorry, but this is unacceptable (union members and ctors)

On Fri, Jun 15, 2007 at 04:25:52PM -0700, michael.a wrote: > I'm afraid I have a fairly major project which requires a Linux port. The > problem is, development has been put off for a while because GCC lacks any > means or work around which permits nesting ctors inside a union. Rather, you're rel

Re: RFC: Make dllimport/dllexport imply default visibility

On 6/15/07, Mark Mitchell <[EMAIL PROTECTED]> wrote: I don't think there's a contradiction. The declaration on the structure is the default for the members and applies to the vtable and other class data. There's no reason the members shouldn't be implemented elsewhere, and there's certainly ex

Re: RFC: Make dllimport/dllexport imply default visibility

Andrew Pinski wrote: > Well this allows for easier violating of ODR. I guess I am just a bit > off of what is going on here but I agree with Chris in that this > really should be rejected as you have stuff which is hidden and then > you call a non hidden member function. How can the vtable be hi

Re: RFC: Make dllimport/dllexport imply default visibility

On 6/15/07, Mark Mitchell <[EMAIL PROTECTED]> wrote: So, why not: struct S __attribute__((visibility("hidden")) { void f(); void g() __attribute__((dllimport)); }; void S::f() { S::g(); }; In any case, in practice, ARM's RealView compiler accepts: struct __declspec(notshared) S

Re: Some thoughts about steerring commitee work

Vladimir N. Makarov wrote: > Eric Botcazou wrote: >>> Please, just look at those charts >>> >>> https://vmakarov.108.redhat.com/nonav/spec/comparison.html >>> >>> The compilation speed decrease without a performance improving (at least >>> for the default case) is really scary. >>> >> >> Right,

Re: RFC: Make dllimport/dllexport imply default visibility

Andrew Pinski wrote: >> In any case, in practice, ARM's RealView compiler accepts: >> >> struct __declspec(notshared) S { >> __declspec(dllimport) void f(); >> void g(); >> }; >> >> void S::g() { >> f(); >> } >> >> And, there's a large body of code that uses this. > > Because

Re: Some thoughts about steerring commitee work

Eric Botcazou <[EMAIL PROTECTED]> writes: > > Please, just look at those charts > > > > https://vmakarov.108.redhat.com/nonav/spec/comparison.html > > > > The compilation speed decrease without a performance improving (at least > > for the default case) is really scary. > > Right, I also found th

Re: Some thoughts about steerring commitee work

"Vladimir N. Makarov" <[EMAIL PROTECTED]> writes: > >>>I've been lobbying for some time, on IRC, for more people to be able > >>>to fill in the holes in the maintainership patterns. Most of the > >>>existing global maintainers are inactive. There are areas of the code > >>>which are not covered

Re: Some thoughts about steerring commitee work

On Fri, Jun 15, 2007 at 06:21:53PM -0700, Ian Lance Taylor wrote: > > This is hardly a new thought, but I believe that for the i386 gcc is > handicapped by reload. No matter how smart we are before reload, it > just take one poor decision by reload in an inner loop and we've lost > all the gains.

Re: Some thoughts about steerring commitee work

Please, to see 1. "The LLVM Compiler System" by Chris Lattner http://llvm.org/pubs/2007-03-12-BossaLLVMIntro.html http://llvm.org/pubs/2007-03-12-BossaLLVMIntro.pdf 2. "Vector LLVA: A Virtual Vector Instruction Set for Media Processing" by Bocchino and Vikram http://llvm.org/pubs/2006-06-15-VEE-

Re: RFC: Make dllimport/dllexport imply default visibility

On Fri, Jun 15, 2007 at 04:47:04PM -0700, Mark Mitchell wrote: > data. There's no reason the members shouldn't be implemented elsewhere, > and there's certainly existing code (in Windows, SymbianOS, and other > DLL-based operating systems, whether or not there is on GNU/Linux) that > implements di

Re: Some thoughts about steerring commitee work

On 6/15/07, H. J. Lu <[EMAIL PROTECTED]> wrote: Why don't we turn on vectorizer at -O3 or even -O2, depending on ISA? I added -ftree-vectorize to BOOT_CFLAGS on x86-64. According to -ftree-vectorizer-verbose=1, there are 82 loops vectorized in gcc source. There are no regressions. There are not

When EOL? Replacing GCJ by IcedTea, GCC by LLVM.

1. Stop developing new features to GCJ and start to develop the more advanced IcedTea (a.k.a. OpenJDK). http://icedtea.classpath.org/wiki//Main_Page 2. Stop developing new features to GCC's backend and start to develop the more advanced LLVM-GCC. http://llvm.org/ (Low Level Virtual Machine)

Re: Some thoughts about steerring commitee work

"J.C. Pizarro" <[EMAIL PROTECTED]> writes: > The optimizing stages of GCC's backend are big, fragmented and complex. > > I think that the GCC's commitee goes to the wrong direction. It's an error to blame the steering committee for the ugliness of gcc's optimization passes. The steering committ

Re: When EOL? Replacing GCJ by IcedTea, GCC by LLVM.

"J.C. Pizarro" <[EMAIL PROTECTED]> writes: > 1. Stop developing new features to GCJ > and start to develop the more advanced IcedTea (a.k.a. OpenJDK). > > http://icedtea.classpath.org/wiki//Main_Page > > > 2. Stop developing new features to GCC's backend > and start to develop the more advanced

Re: I'm sorry, but this is unacceptable (union members and ctors)

Portability is not a huge issue for these builds actually as the plan is to distribute binaries for the time being, with open source modules, or module plugins rather, as the system itself is a suite of modules. Also only operating system with nestable and mutually dependent shared library suppor

Re: Some thoughts about steerring commitee work

Ian Lance Taylor wrote: These charts are certainly discouraging. On the other hand, for some real code we're seeing each new version of gcc produce an incremental runtime improvement. So I'm not sure what to make of it. This is hardly a new thought, but I believe that for the i386 gcc is han

When EOL? Replacing GCJ by IcedTea, GCC by LLVM.

For performance and simplicity, i show this summary 1. "The LLVM Compiler System" by Chris Lattner http://llvm.org/pubs/2007-03-12-BossaLLVMIntro.html http://llvm.org/pubs/2007-03-12-BossaLLVMIntro.pdf 2. "LLVM in OpenGL and for Dynamic Languages" by Chris Lattner http://llvm.org/devmtg/2007-05/

Re: I'm sorry, but this is unacceptable (union members and ctors)

On 6/15/07, michael.a <[EMAIL PROTECTED]> wrote: I do believe GCC supports the standard "for loop scope" extension Actually that was not really really an extension before the standard come out. The rules changed with the standardization. Really most of GCC extensions to the C++ langauge that

Re: Some thoughts about steerring commitee work

Ian Lance Taylor wrote: Ian, may be I am wrong but I see a problem that some important for all GCC community things are discussed only on IRC. Not all people are on IRC. Moreover some people avoiding the IRC for some reasons. There will always be private conversations about GCC.

Re: Some thoughts about steerring commitee work

> The optimizing stages of GCC's backend are big, fragmented and complex. > > I think that the GCC's commitee goes to the wrong direction. The steering committee doesn't make those sorts of technical directions. Moreover, nearly all of the backend of GCC existed before the steering committee was

Re: Some thoughts about steerring commitee work

H. J. Lu wrote: On Fri, Jun 15, 2007 at 06:21:53PM -0700, Ian Lance Taylor wrote: This is hardly a new thought, but I believe that for the i386 gcc is handicapped by reload. No matter how smart we are before reload, it just take one poor decision by reload in an inner loop and we've lost al

Re: Some thoughts about steerring commitee work

> Reload is a mess but in local context it is doing a good job. That's exactly the point: it makes sense and does the right thing when viewed locally, but there's little feedback and/or linkage between reload and the other optimizers regarding global decisions. So those global decisions are oft

Re: Some thoughts about steerring commitee work

> The second, it was a bit suspicious to me that in one day two Google > guys got global maintainership although as I wrote Diego did not work on > rtl for a long time. One the other hand, I see Google has a good > developers and may be I was a bit paranoid. Right. A few years ago, if two d

Re: GCC Status Report (2007-06-15)

On Fri, 15 Jun 2007, Mark Mitchell wrote: > GCC 4.3 Stage 1 is now closed. > [...] > As previously discussed, the mainline will be in "lockdown" for 1-2 > weeks, starting midnight tonight. Other then the merges mentioned > above, and documentation improvements, the only patches that should be > c

Re: GCC Status Report (2007-06-15)

On 6/15/07, Kaveh R. GHAZI <[EMAIL PROTECTED]> wrote: Timezone please? PDT? I say JST because that past almost 13 hours ago :). Going to Japan gets me into that mood. -- Pinski

Re: I'm sorry, but this is unacceptable (union members and ctors)

Andrew Pinski-2 wrote: > > Actually that was not really really an extension before the standard > come out. The rules changed with the standardization. Really most of > GCC extensions to the C++ langauge that exist now (except for a few > new ones dealing with the C++0x standard) are all lega

Re: I'm sorry, but this is unacceptable (union members and ctors)

michael.a wrote: It would be interesting for someone to try to make a practical argument that is anything but a nest of technicalities, as to why ctors and unions shouldn't be mixable. The Fortran language specification allows essentially this, although the terms are initializers and equivalen

Re: I'm sorry, but this is unacceptable (union members and ctors)

> My general opinion is it serves no one to be regressive about extensions. > You can always advise against using them, and somewhere down the road, the > specs can always decide an extension is worth supporting more conservatively > or adding to a future spec altogether. > > It would be interestin

Re: GCC Status Report (2007-06-15)

On 6/15/07, Mark Mitchell <[EMAIL PROTECTED]> wrote: Hopefully, the PTR_PLUS branch and the fixed-point branch will be merged in the relatively near future. I checked in pointer_plus as revision 125755. Thanks, Andrew Pinski

Re: r125698 breaks bootstrap on trunk for i686-pc-linux-gnu

On 6/14/07, Thomas Veith <[EMAIL PROTECTED]> wrote: Hi *, binary search revealed that r125698 breaks bootstrap on trunk for i686-pc-linux-gnu. What error are you getting? I don't see this on my machine. Thanks, Andrew Pinski

Re: When EOL? Replacing GCJ by IcedTea, GCC by LLVM.

On Jun 15, 2007, at 8:08 PM, J.C. Pizarro wrote: For performance and simplicity, i show this summary JC, I appreciate your enthusiasm, but I don't think that this is the right forum for discussions about LLVM vs GCC. If you'd like to discuss LLVM, please take it to an LLVM-related mailin