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 reg
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 Softwar
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 loo
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, a
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 th
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, para
> # 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) (
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.
>
> Di
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
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 u
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 MAIN
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?
> O
12 matches
Mail list logo