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
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 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
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 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
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 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
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
-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, 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
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 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: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 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 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, 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
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
> 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
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
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
> 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
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
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
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
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
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
26 matches
Mail list logo
