Hi,
We're pleased to announce that gcc110.fsffrance.org a new powerful
POWER7 server made available by IBM (1) and hosted by OSUOSL (2) is now
online in the GCC Compile Farm (3), a not-for-profit project maintained by
the Free Software Fundation France (4).
The server is an IBM Power 730 Express
Hello All
(I am playing with C++11, but I am not a C++ expert, and I don't know the C++
front-end
part of GCC, so this is a feature wish only).
Perhaps it could be useful for some later (4.8?) release of GCC to produce an
inferred
type annotation file.
For those knowing Ocaml, I was thinking o
On 10/11/2011 11:58, Basile Starynkevitch wrote:
Hello All
(I am playing with C++11, but I am not a C++ expert, and I don't know the C++
front-end
part of GCC, so this is a feature wish only).
Perhaps it could be useful for some later (4.8?) release of GCC to produce an
inferred
type annotati
On 10 November 2011 10:58, Basile Starynkevitch wrote:
> With the type inference abilities given by
> the auto keyword, it is sometimes hard for a beginner to understand what type
> is some
> particular expression in his code (or what exactly function is called in an
> overloaded
> context).
If
I've recently noticed that several of our target libraries are not
properly (if at all) represented as bugzilla components. The following
table shows the current situation:
directory component
libada(ada)
libcpp(preprocessor)
libdecnumber
> The entries in parens are only covered indirectly and may or may not
> warrant their own components. I'd argue that it would be helpful to
> have libada and libgo components of their own (while libcpp would
> probably be overkill), but of course that's ultimately up to the
> respective maintaine
On Thu, Nov 10, 2011 at 2:35 PM, Arnaud Charlet wrote:
>> The entries in parens are only covered indirectly and may or may not
>> warrant their own components. I'd argue that it would be helpful to
>> have libada and libgo components of their own (while libcpp would
>> probably be overkill), but
Quoting Jonathan Wakely :
Of course, such a thing could be done by some GCC plugin, but I
believe providing the
feature inside GCC itself, and documenting the format of the
textual type annotation
file, would give this feature more visibility, and it would help
people a lot. And I am
pre
> I think we should have different components only if we have different
> maintainers for them (or, if they do not naturally belong to another
> component).
Right, precisely for Ada that would be the same set of people.
> Note that most bug submitters confuse the bug component with the
> language
Joern Rennecke a écrit:
> I think the right balance if good visibility is considered important would be
> to have this as a plugin that is shipped with the gcc distribution and
> installed by default.
That, or that a group of motivated plugins authors gets together to
create a "blessed" plugin r
On Thu, 2011-11-10 at 14:22 +0100, Rainer Orth wrote:
> I think that at least some of the gaps need to be filled, notably libgcc
> (recently bugs have been filed under other), libitm (new with the
> trans-mem merge, but fits nowhere else)
Something for libitm would probably make sense (or "trans-m
On Thu, 10 Nov 2011 13:11:49 +0100
David Brown wrote:
>
> I don't know why you say such a feature would only help C++ newbies - my
> guess is that it would be at least as helpful to experts. But maybe
> /real/ C++ experts have a different opinion there!
Yes, perhaps you're right. But certainl
On Thu, 10 Nov 2011 12:54:52 +
Jonathan Wakely wrote:
> Doesn't DWARF debug info already contain all that info anyway?
It is not a textual file, and it is not easily parsable. Nobody would write a
DWARF
parser in a few hundreds lines of Emacs Lisp.
>
> > Of course, such a thing could be d
On 10 November 2011 16:08, Basile Starynkevitch wrote:
> On Thu, 10 Nov 2011 12:54:52 +
> Jonathan Wakely wrote:
>
>> Doesn't DWARF debug info already contain all that info anyway?
>
> It is not a textual file, and it is not easily parsable. Nobody would write a
> DWARF
> parser in a few hund
On 10 November 2011 16:12, Jonathan Wakely wrote:
> On 10 November 2011 16:08, Basile Starynkevitch wrote:
>> It is not a textual file, and it is not easily parsable. Nobody would write
>> a DWARF
>> parser in a few hundreds lines of Emacs Lisp.
>
> But it contains all the information you want, an
On 10 November 2011 16:17, Jonathan Wakely wrote:
> On 10 November 2011 16:12, Jonathan Wakely wrote:
>> On 10 November 2011 16:08, Basile Starynkevitch wrote:
>>> It is not a textual file, and it is not easily parsable. Nobody would write
>>> a DWARF
>>> parser in a few hundreds lines of Emacs Li
On Thu, 10 Nov 2011, Rainer Orth wrote:
> I've recently noticed that several of our target libraries are not
> properly (if at all) represented as bugzilla components. The following
> table shows the current situation:
>
> directory component
You omitted boehm-gc and zlib, both used
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[ This should have gone out some time ago... Sorry for the long delay ]
I'm pleased to announce that the GCC steering committee has approved
the nomination of Andrey Belevantsev, Alexander Monakov, and Dmitry
Melnik as selective scheduling reviewers
On Thu, 10 Nov 2011 12:54:52 +
Jonathan Wakely wrote:
> > That type annotation produced by g++ would be usable by external editors,
> > etc.
>
> That's a pretty big assumption, and the file would be useless without
> editor support (I realise there's a chicken and egg situation here.)
>
> D
On 10 November 2011 17:36, Basile Starynkevitch wrote:
> On Thu, 10 Nov 2011 12:54:52 +
> Jonathan Wakely wrote:
>> > That type annotation produced by g++ would be usable by external editors,
>> > etc.
>>
>> That's a pretty big assumption, and the file would be useless without
>> editor suppo
Rainer Orth writes:
> The entries in parens are only covered indirectly and may or may not
> warrant their own components. I'd argue that it would be helpful to
> have libada and libgo components of their own (while libcpp would
> probably be overkill), but of course that's ultimately up to the
On Thu, 18 Aug 2011, Jonathan Wakely wrote:
> Personally I *like* it when a new release identifies portability
> problems such as missing includes. I consider it an advantage,
> and an improvement in the compiler.
That's a valid approach from a technology perspective. From a
customer/user pers
Snapshot gcc-4.5-2010 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-2010/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On 11/06/2011 09:14 PM, Miles Bader wrote:
Hmm, has he been contacted recently? The original patch was from ages
ago...
Yes, I've been in communication with him and the FSF. I expect this to
be sorted out soon so we can put in the patch.
Jason
On Thu, Nov 10, 2011 at 10:12 AM, Jonathan Wakely wrote:
> Adding this to GCC seems like a total waste of time, write a dwarf
> processor that dumps the info you want.
>
Agreed.
I suspect there is a misunderstanding of what 'auto' means in C++.
Furthermore, I think the step is completely backwa
On Thu, Nov 10, 2011 at 10:04:34PM -0800, Gabriel Dos Reis wrote:
> On Thu, Nov 10, 2011 at 10:12 AM, Jonathan Wakely
> wrote:
>
> > Adding this to GCC seems like a total waste of time, write a dwarf
> > processor that dumps the info you want.
> >
>
> Agreed.
>
> I suspect there is a misunders
26 matches
Mail list logo
