GCC development plan
Hello, is there something like an unofficial documentation of trunk features or a more or less detailed development plan of the compiler? What I'm trying to say... how do you know what to work on and what are schedules? I'm particularly interested in C++0x, SIMDs and optimization plans. Best regards Piotr Wyderski
Re: GCC development plan
On 01/20/2010 12:17 PM, Piotr Wyderski wrote: > Hello, > > is there something like an unofficial documentation > of trunk features or a more or less detailed development > plan of the compiler? http://catb.org/~esr/writings/homesteading/ with the usual caveats about Open Source vs Free Software. Paolo.
Re: GCC development plan
On 01/20/2010 12:17 PM, Piotr Wyderski wrote: > is there something like an unofficial documentation > of trunk features Well, for the new features in the trunk: Have a look at the release notes for the upcoming version 4.5 at http://gcc.gnu.org/gcc-4.5/changes.html For C++ 0x (1x?) have also a look at http://gcc.gnu.org/gcc-4.5/cxx0x_status.html > or a more or less detailed development > plan of the compiler? No - there might be some (tentative) plan for some parts of the compiler and ideas what should implemented first but there is no overall development plan. > What I'm trying to say... how do you know what to work on That depends on who is paying (if any), personal interest, and perceived importance of a given feature/bug. > and what are schedules? See Stage 1/2/3 at http://gcc.gnu.org/develop.html and the time line on that page that gives you an idea of a schedule of GCC (though not for a given feature). Tobias
Re: GCC development plan
Tobias Burnus wrote: > Well, for the new features in the trunk: Have a look at the release > notes for the upcoming version 4.5 at > http://gcc.gnu.org/gcc-4.5/changes.html > For C++ 0x (1x?) have also a look at > http://gcc.gnu.org/gcc-4.5/cxx0x_status.html Yes, I know those pages pretty well, as I check the C++0x implementation progress every other week. But, from the perspective of trunk, they describe what has already been done and I'm using that features happily. Of course I realize that there is no strict plan, as it is an Open Source project run by volunteers. I would like to know what is in progress or planned /speculated to be, but failed to find that information. The person who maintains the mentioned sites somehow knows what is going on under the hood, so I wonder whether that information is available to mere mortals, and -- if yes -- then how. > No - there might be some (tentative) plan for some parts of the compiler > and ideas what should implemented first That would be more than enough, but where can I find that? I read this list rather carefully, however not much information of that kind is disclosed here. Best regards Piotr Wyderski
Re: GCC development plan
Piotr Wyderski wrote: Tobias Burnus wrote: Well, for the new features in the trunk: Have a look at the release notes for the upcoming version 4.5 at http://gcc.gnu.org/gcc-4.5/changes.html For C++ 0x (1x?) have also a look at http://gcc.gnu.org/gcc-4.5/cxx0x_status.html Yes, I know those pages pretty well, as I check the C++0x implementation progress every other week. But, from the perspective of trunk, they describe what has already been done and I'm using that features happily. Of course I realize that there is no strict plan, as it is an Open Source project run by volunteers. I would like to know what is in progress or planned /speculated to be, but failed to find that information. The person who maintains the mentioned sites somehow knows what is going on under the hood, so I wonder whether that information is available to mere mortals, and -- if yes -- then how. No - there might be some (tentative) plan for some parts of the compiler and ideas what should implemented first That would be more than enough, but where can I find that? I read this list rather carefully, however not much information of that kind is disclosed here. Best regards Piotr Wyderski I think there are three broad parts to this question: infrastructure, core language and library runtimes. I tend to work on the latter and in that case I think all the languages are trying to fill any holes in the published standards for those languages. I know at least C, C++, and Fortran have status pages in the manual and in Wikis describing the coverage with respect to the various standards and Technical Reports and Defect Reports in each language. Pick a hole and start filling. As for infrastructure I know much less. It seems that a lot of thought is presented at GCC workshops. Ideas are presented for new optimization passes and so on. Also, watching the list will reveal annoyances like reload and other stuff. Obviously I don't know these parts ;-) well enough to talk. As a core language evolves in subsequent standards (in particular, right now, C++-0x is coming up) new language features must be supported possibly in conjunction with the corresponding runtime. As for timing at least C++ and possibly Fortran track the standards as the progress and add features as they solidify either in an experimental mode or on a separate branch. Gcc is an important part of the feedback loop into the wider standards world about implementation experience for new language and library proposals. So basically, it's this: 1. look at the standards documents, 2. look at the current coverage in gcc, 3. Fill holes, 4. Don't add too much new stuff. Rinse. Repeat. Ed
Re: Changing the ABI
That is also the conclusions I made.
- Move the zone (4) to the callee if need be. You know that if your
caller had more than 8 output parameters, the last parameters are set
on the stack in zone (3).
- However, it seems to me that in the case of :
void foo (void)
{
...
bar (param1, param2, ..., param9);
...
ptr = alloca (size);
...
bar (param1, param2, ..., param9);
}
In this case, foo would need to add space for param9 on the stack for
the call to bar.
However, later in the function, it would need to perform an alloca.
Since there is another call to bar, it would need to add again some
space for param9 on the stack.
Therefore the stack would look like this :
(5) Space for param9
(6) Alloca space for ptr
(7) Space for param9
Except if there is a way to tell the compiler to retrieve space (5)
before performing the alloca in order to get this:
(6) Alloca space for ptr (retrieved space (5))
(7) Space for param9
Can this be done when expanding the alloca in order to first pop the
stack, then alloca a bit more for the parameters ? However, this needs
also to take precautions when popping the alloca's from the stack.
Thanks for your input and help,
Jean Christophe Beyler
On Tue, Jan 19, 2010 at 9:04 AM, Mikael Pettersson wrote:
> On Mon, 18 Jan 2010 13:55:16 -0500, Jean Christophe Beyler wrote:
>>I have a current issue on my port. Basically the stack is defined as follows :
>>
>>1) CALL_USED save area
>>2) Local variables
>>3) Caller arguments passed on the stack
>>4) 8 words to save arguments passed in registers, even if not passed
>>
>>Now, this was done because we have defined 8 output registers,
>>therefore zone (3) is not used except if we call a function with more
>>than 8 parameters.
>>
>>(4) is only used if we have va_arg functions that will then spill the
>>8 input registers on the stack and call the va_arg function.
>>
>>This is done, to my understanding for our ABI, because, in the case of
>>a va_arg function, we want the parameters consecutively store in
>>memory.
>
> That's indeed a desirable property.
>
>>However, this brings me to 2 problems :
>>
>>1) If there are no va_arg function calls, there still is 8 words
>>wasted on the stack per function call still active on the stack.
>>
>>2) If there is an alloca, then GCC moves the stack pointer but without
>>trying to get back those 8 words or even the space for (3).
>>
>>
>>I am currently working on not having that wasted space. I see two options:
>>
>>1) Change the ABI to go closer to what I have seen in the MIPS port :
>> - The zone (4) is handled by the callee
>> - However, I'll still have the wasted space (4) when an alloca is used no
>> ?
>
> Actually, zone (4) should just be deleted entirely from the ABI.
> That is, all the ABI should specify is that non-register arguments
> are in the caller's frame starting exactly at the stack pointer.
>
> For non-varargs calls, there's no waste.
>
> For varargs calls, the callee can allocate its frame and save the
> incoming register arguments at the top of its own frame, establishing
> the all-arguments-are-stored-consecutively property without burdening
> the caller or the ABI.
>
> An alloca() in the callee should just adjust the stack pointer and
> ignore the register arguments save area at the top of the frame.
>
> /Mikael
>
Extra regressions for --enable-build-with-cxx
I've tested mainline r156055 with the patch for PR42798 both with and without --enable-build-with-cxx; a number of testsuites show additional failures for --enable-build-with-cxx. I've attached simple diffs from the gcc to g++ bootstrap regtest summaries. Did this ever work properly? i686-pc-linux-gnu/libstdc++-v3/testsuite/libstdc++.sum 1c1 < Test Run By amylaar on Wed Jan 20 12:06:41 2010 --- > Test Run By amylaar on Wed Jan 20 12:26:07 2010 11c11 < PASS: abi_check --- > FAIL: abi_check 7578c7578,7579 < # of expected passes 7387 --- > # of expected passes 7386 > # of unexpected failures 1 gcc/testsuite/gfortran/gfortran.sum 1c1 < Test Run By amylaar on Wed Jan 20 12:06:43 2010 --- > Test Run By amylaar on Wed Jan 20 13:02:39 2010 16372c16372 < PASS: gfortran.dg/ldist-1.f90 -O scan-tree-dump-times ldist "distributed: split to 4 loops" 1 --- > FAIL: gfortran.dg/ldist-1.f90 -O scan-tree-dump-times ldist "distributed: > split to 4 loops" 1 35807,35808c35807,35808 < # of expected passes 33486 < # of unexpected failures 3 --- > # of expected passes 33485 > # of unexpected failures 4 35811c35811 < /user/inria/fsf/bld-gcc-20/gcc/testsuite/gfortran/../../gfortran version 4.5.0 20100120 (experimental) (GCC) --- > /user/inria/fsf/bld-gcc-cxx12/gcc/testsuite/gfortran/../../gfortran version > 4.5.0 20100120 (experimental) (GCC) gcc/testsuite/g++/g++.sum 1c1 < Test Run By amylaar on Wed Jan 20 12:06:43 2010 --- > Test Run By amylaar on Wed Jan 20 13:02:39 2010 14052,14084c14052,14084 < PASS: g++.dg/plugin/attribute_plugin-test-1.C -fplugin=./attribute_plugin.so (test for warnings, line ) < PASS: g++.dg/plugin/attribute_plugin-test-1.C -fplugin=./attribute_plugin.so (test for warnings, line 7) < PASS: g++.dg/plugin/attribute_plugin-test-1.C -fplugin=./attribute_plugin.so (test for warnings, line 7) < PASS: g++.dg/plugin/attribute_plugin-test-1.C -fplugin=./attribute_plugin.so (test for warnings, line 16) < PASS: g++.dg/plugin/attribute_plugin-test-1.C -fplugin=./attribute_plugin.so (test for excess errors) < PASS: g++.dg/plugin/pragma_plugin-test-1.C -fplugin=./pragma_plugin.so (test for warnings, line ) < PASS: g++.dg/plugin/pragma_plugin-test-1.C -fplugin=./pragma_plugin.so (test for warnings, line 5) < PASS: g++.dg/plugin/pragma_plugin-test-1.C -fplugin=./pragma_plugin.so (test for warnings, line 9) < PASS: g++.dg/plugin/pragma_plugin-test-1.C -fplugin=./pragma_plugin.so (test for warnings, line 14) < PASS: g++.dg/plugin/pragma_plugin-test-1.C -fplugin=./pragma_plugin.so (test for excess errors) < PASS: g++.dg/plugin/self-assign-test-1.C -fplugin=./selfassign.so (test for warnings, line 10) < PASS: g++.dg/plugin/self-assign-test-1.C -fplugin=./selfassign.so (test for warnings, line 13) < PASS: g++.dg/plugin/self-assign-test-1.C -fplugin=./selfassign.so (test for warnings, line 26) < PASS: g++.dg/plugin/self-assign-test-1.C -fplugin=./selfassign.so (test for warnings, line 27) < PASS: g++.dg/plugin/self-assign-test-1.C -fplugin=./selfassign.so (test for warnings, line 33) < PASS: g++.dg/plugin/self-assign-test-1.C -fplugin=./selfassign.so (test for warnings, line 34) < PASS: g++.dg/plugin/self-assign-test-1.C -fplugin=./selfassign.so (test for warnings, line 40) < PASS: g++.dg/plugin/self-assign-test-1.C -fplugin=./selfassign.so (test for warnings, line 41) < PASS: g++.dg/plugin/self-assign-test-1.C -fplugin=./selfassign.so (test for warnings, line 42) < PASS: g++.dg/plugin/self-assign-test-1.C -fplugin=./selfassign.so (test for warnings, line 43) < PASS: g++.dg/plugin/self-assign-test-1.C -fplugin=./selfassign.so (test for warnings, line 44) < PASS: g++.dg/plugin/self-assign-test-1.C -fplugin=./selfassign.so (test for warnings, line 46) < PASS: g++.dg/plugin/self-assign-test-1.C -fplugin=./selfassign.so (test for warnings, line 47) < PASS: g++.dg/plugin/self-assign-test-1.C -fplugin=./selfassign.so (test for excess errors) < PASS: g++.dg/plugin/self-assign-test-2.C -fplugin=./selfassign.so (test for warnings, line 10) < PASS: g++.dg/plugin/self-assign-test-2.C -fplugin=./selfassign.so (test for warnings, line 13) < PASS: g++.dg/plugin/self-assign-test-2.C -fplugin=./selfassign.so (test for warnings, line 26) < PASS: g++.dg/plugin/self-assign-test-2.C -fplugin=./selfassign.so (test for warnings, line 27) < PASS: g++.dg/plugin/self-assign-test-2.C -fplugin=./selfassign.so (test for warnings, line 33) < PASS: g++.dg/plugin/self-assign-test-2.C -fplugin=./selfassign.so (test for warnings, line 34) < PASS: g++.dg/plugin/self-assign-test-2.C -fplugin=./selfassign.so (test for warnings, line 40) < PASS: g++.dg/plugin/self-assign-test-2.C -fplugin=./selfassign.so (test for warnings, line 41) < PASS: g++.
Re: Extra regressions for --enable-build-with-cxx
Joern Rennecke writes: > I've tested mainline r156055 with the patch for PR42798 both > with and without --enable-build-with-cxx; a number of testsuites > show additional failures for --enable-build-with-cxx. > > I've attached simple diffs from the gcc to g++ bootstrap regtest > summaries. > > Did this ever work properly? Yes, it did once work properly. I'm not surprised that plugins don't work, but I don't know why the other tests change state. Ian
updated code size comparison
Hi folks, I've posted an updated code size comparison between LLVM, GCC, and others here: http://embed.cs.utah.edu/embarrassing/ New in this version: - much larger collection of harvested functions: more than 360,000 - bug fixes and UI improvements - added the x86 Open64 compiler John
--enable-build-with-cxx vs plugins (Was: Re: Extra regressions for --enable-build-with-cxx)
Quoting Ian Lance Taylor : I'm not surprised that plugins don't work For Milepost we need both the --enable-build-with-cxx configure option and plugins. How is this supposed to work? Should the person compiling the plugins use C++ to compile the plugin? Or should the cc1 / cc1plus dso export unambiguous symbols with C linkage names in addition to the C++ linkage names? Or should we have a language extension to specify C++ linkage in C headers, and arrange for the gcc headers that are installed for teh benefit of plugins to reflect the used build/bootstrap language so that either gcc or g++ will just work, using references with the appropriate names?
Dave Korn appointed Cygwin maintainer
It is my pleasure to announce that with strong support by the three existing maintainers in this area, the steering committee has appointed Dave Korn Cygwin (actually "windows, cygwin, mingw") maintainer. Thanks for your contributions so far, keep up the good work, Dave, and please adjust the MAINTAINERS file accordingly. Happy hacking! Gerald
Re: --enable-build-with-cxx vs plugins (Was: Re: Extra regressions for --enable-build-with-cxx)
Joern Rennecke writes: > Quoting Ian Lance Taylor : > >> I'm not surprised that plugins don't work > > For Milepost we need both the --enable-build-with-cxx configure option > and plugins. > How is this supposed to work? > Should the person compiling the plugins use C++ to compile the plugin? > Or should the cc1 / cc1plus dso export unambiguous symbols with C linkage > names in addition to the C++ linkage names? > Or should we have a language extension to specify C++ linkage in C headers, > and arrange for the gcc headers that are installed for teh benefit of plugins > to reflect the used build/bootstrap language so that either gcc or g++ will > just work, using references with the appropriate names? I was imagining that if gcc is built with C++, then plugins would be built with C++. Ian
