>> STL is good, but may surplus what GCC really needs, and will introduce
>> many complex, "uncontrollable" C++ features.
>>
>>
>> Personally, I think what GCC need most is an simple, generic, one
>> layer containers of pointers to objects, with their iterators.
>> Instead of containers of arbitr
yazdanbakhsh writes:
> I want to exclude XORI from the instruction set of a cpu. I deleted all the
> XORI in md file. But when I compiled my program some XORI operation still
> exist. how this would be possible?
It could be printed directly from a .c file in your config/CPU
directory.
Ian
2010/6/2 Richard Guenther :
> On Wed, Jun 2, 2010 at 1:51 PM, David Edelsohn wrote:
>> On Wed, Jun 2, 2010 at 2:07 AM, Laurynas Biveinis
>>> All the patches from gc-improv merge have been approved. Due to the
>>> scope of the changes, the merge will need trunk freeze. Thus I am
>>> planning to do
Hi,
I want to exclude XORI from the instruction set of a cpu. I deleted all the
XORI in md file. But when I compiled my program some XORI operation still
exist. how this would be possible?
--
View this message in context:
http://old.nabble.com/Question-about-Machine-Description-tp1026428p287633
As I was about to check in the -mrecip changes for powerpc on GCC 4.6, I
figured to get a start on documentation, and I was going to edit the
gcc-4.6/changes.html file. I realize this is early in the cycle, but did we
want to create the gcc-4.6 directory?
--
Michael Meissner, IBM
Until June 30:
> You've already convinced me, but you originally described a problem
> where emacs' paragraph formatting would incorrectly rearrange
> multi-line C++ comments. Out of personal curiosity, does emacs
> actually have a bug in this regard or not?
It happens to work correctly in a well-formed C++ tes
On 2 June 2010 22:42, manal habib wrote:
> Hi,
>
> I am new into the field of coding, and I am wandering if I can get
> some help on how to use the GCC? I have a mac version 10.5.8. Should
> I just copy one of the image folders to make computer? how can use
> it?
This is not the right mailing l
> >> I'm not sure i agree with this, because I don't see anything wrong
> >> with multi-line C++-style comments.
> >
> > I'm with Ian on this one. Is there a reason for this, other than
> one's
> > personal tool preference for editing code may make C-style multi-line
> > comments easier to add/remo
Hi,
I am new into the field of coding, and I am wandering if I can get
some help on how to use the GCC? I have a mac version 10.5.8. Should
I just copy one of the image folders to make computer? how can use
it?
Thank you very much
Manal Habib
On 06/01/2010 05:52 AM, Richard Guenther wrote:
> On Thu, Feb 18, 2010 at 1:26 AM, Paolo Bonzini wrote:
Maybe we can use this in AC_CHECK_DECLS instead of having a new
separate macro. If there is a parenthesis in the name call the new
version, if there is none, call the old one.
>>
Robert Dewar writes:
> I would create a specific committee to reccommend a C++ coding
> standard (preferably based on one of the standard ones available, such
> as Google).
Doing things in secret like that is not the Open Source Way.
On Wed, Jun 2, 2010 at 14:09, NightStrike wrote:
> threads that haven't been addressed. I offered to Ian to do the same
> thing for the whole mailing list if we can make it a policy that
> people who commit changes do what Kai is doing so that it's clear that
> the thread is done with. I don't
Quoting Richard Earnshaw :
A missing virtual hook would be a build failure, rather than a runtime
error. So the advantage is easier maintenance.
If we really wanted to have a target hook without a valid default, we could
have it right now by using a default that causes a link or even a compil
On Wed, Jun 02, 2010 at 06:52:11PM +0100, Richard Earnshaw wrote:
> > Currently targetm is a struct with function pointers, so calling
> > targetm.hook_xyz ();
> > means reading a pointer from &targetm + off, then calling it.
> > If you make it a class with virtual functions and targetm
> > would b
Recently on #gcc, I have been conversing with several others on the
topic of patches lost in the tides of the gcc-patches mailing list. I
flagged Jeff Downs' recent message as an example of a patch that has
been waiting since November
(http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00177.html). I t
On Wed, 2010-06-02 at 19:50 +0200, Jakub Jelinek wrote:
> On Wed, Jun 02, 2010 at 06:17:25PM +0100, Richard Earnshaw wrote:
> >
> > On Mon, 2010-05-31 at 10:02 -0700, Mark Mitchell wrote:
> > > I think virtual functions are on the edge; quite useful, but do result
> > > in the compiler adding a p
> Provided that the object format for binaries is published and that we
> can therefore create some binutils tools as well.
No. You build a cross-COMPILER, not a cross-assembler. You use the
assembler on the target.
On Wed, Jun 02, 2010 at 06:17:25PM +0100, Richard Earnshaw wrote:
>
> On Mon, 2010-05-31 at 10:02 -0700, Mark Mitchell wrote:
> > I think virtual functions are on the edge; quite useful, but do result
> > in the compiler adding a pointer to data objects and in uninlinable
> > indirect calls at run
Richard Earnshaw wrote:
>> I think virtual functions are on the edge; quite useful, but do result
>> in the compiler adding a pointer to data objects and in uninlinable
>> indirect calls at run-time. Therefore, I would avoid them in the
>> initial subset of C++ used in GCC.
>
> We do, of course,
Dave Korn wrote:
>>> Just to be clear, I don't believe that regenerating the docs itself would
>>> be a breach since NOTHING you do internally can be a GPL or GFDL breach).
>>> What would be a breach would be *distributing* those regenerated docs.
>> Indeed; I was too casual in my description. D
On Mon, 2010-05-31 at 08:22 -0400, Robert Dewar wrote:
> Gcc is very widespread at this point. Yes, there is the issue
> of completely new targets, but these can be easily handled by
> building cross-compilers.
Provided that the object format for binaries is published and that we
can therefore cre
On Mon, 2010-05-31 at 10:02 -0700, Mark Mitchell wrote:
> I think virtual functions are on the edge; quite useful, but do result
> in the compiler adding a pointer to data objects and in uninlinable
> indirect calls at run-time. Therefore, I would avoid them in the
> initial subset of C++ used in
On 02/06/2010 17:22, Richard Guenther wrote:
> template
> void mark(const T&) { gcc_unreachable (); }
>
> we might be safe to not miss implementations for something gengtype
> does not handle itself.
Wouldn't
template
void mark(const T&) { gcc_does_not_exist_causes_link_failure (); }
do an e
On Wed, Jun 2, 2010 at 6:03 PM, Tom Tromey wrote:
>> "Basile" == Basile Starynkevitch writes:
>
> Basile> Still, my concerns on C++ is mostly gengtype related. I believe we
> need
> Basile> to keep a garbage collector even with C++, and I believe that changing
> Basile> gengtype to follow C+
On 02/06/2010 15:07, Mark Mitchell wrote:
> Richard Kenner wrote:
>
>>> However, if I changed the code, but did not regenerate the docs, and you
>>> then picked up my changes, possibly made more of your own, and then
>>> regenerated the docs, *you* would be in breach. (Because my changes are
>>>
> "Basile" == Basile Starynkevitch writes:
Basile> Still, my concerns on C++ is mostly gengtype related. I believe we need
Basile> to keep a garbage collector even with C++, and I believe that changing
Basile> gengtype to follow C++ could be quite painful if we follow the usual
Basile> route
On Wed, May 26, 2010 at 7:16 PM, Mark Mitchell wrote:
> Ulrich Weigand wrote:
>
>>> So the question is: The goal is to have hooks, not macros, right? If
>>> so, can reviewers please take care to reject patches that introduce
>>> new macros?
>>
>> I don't know to which extent this is a formal goal
Robert Dewar writes:
> A rather global comment. I think trying to do language
> design by the flood-of-email method is dubious. I would
> create a specific committee to reccommend a C++ coding
> standard (preferably based on one of the standard ones
> available, such as Google). And then when the
A rather global comment. I think trying to do language
design by the flood-of-email method is dubious. I would
create a specific committee to reccommend a C++ coding
standard (preferably based on one of the standard ones
available, such as Google). And then when there is a
completed document, ask
Ian Lance Taylor wrote:
Richard Guenther writes:
I agree that that is the usual problem with overloaded operators. I
don't really agree that that is a problem in this specific case. We
have to do those operations anyhow. I don't think the ease of writing
the code is going to cause us to do
On Wed, Jun 2, 2010 at 9:33 AM, Emílio Wuerges wrote:
> Now that we are talking about STL & templates: What about boost?
My personal inclination it to keep the dependencies strictly to a
C++98 implementation.
When times come that we need more dependencies and the benefits clearly
demonstrated, t
On 2 June 2010 15:05, Paolo Bonzini wrote:
> On 06/02/2010 03:01 PM, Gabriel Dos Reis wrote:
>>
>> In the guidelines, I would like to include:
>> (2) if you define a class template used mostly with pointer type
>> arguments,
>> consider specializing for void* (or const void*) and define
On 2 June 2010 15:33, Emílio Wuerges wrote:
> Now that we are talking about STL & templates: What about boost?
The requirement for a C++98 compiler is a much weaker requirement than
C++98 compiler + working Boost. Boost is not tested on most of the
platforms that GCC targets. Also, Boost APIs are
Now that we are talking about STL & templates: What about boost?
On Wed, Jun 2, 2010 at 11:22 AM, Gabriel Dos Reis
wrote:
> On Wed, Jun 2, 2010 at 9:05 AM, Paolo Bonzini wrote:
>> On 06/02/2010 03:01 PM, Gabriel Dos Reis wrote:
>>>
>>> In the guidelines, I would like to include:
>>> (2) if yo
On Wed, Jun 2, 2010 at 9:05 AM, Paolo Bonzini wrote:
> On 06/02/2010 03:01 PM, Gabriel Dos Reis wrote:
>>
>> In the guidelines, I would like to include:
>> (2) if you define a class template used mostly with pointer type
>> arguments,
>> consider specializing for void* (or const void*)
Matthias Klose wrote:
>> I will state explicitly up front a few topics I am not raising, because
>> I do not think they are either necessary, or likely to be productive:
>>
>> * Whether or not the GFDL is a "free" license, or whether it's a good
>> license, or anything else about its merits or lac
On 06/02/2010 03:54 PM, Ian Lance Taylor wrote:
Richard Guenther writes:
On Tue, Jun 1, 2010 at 6:58 PM, Ian Lance Taylor wrote:
Richard Guenther writes:
Overall the wiki document looks good. I'd like to disallow
* Operators may only be overloaded for types which implement numeric
value
Richard Kenner wrote:
>> However, if I changed the code, but did not regenerate the docs, and you
>> then picked up my changes, possibly made more of your own, and then
>> regenerated the docs, *you* would be in breach. (Because my changes are
>> only available to you under the GPL; you do not ha
On 06/02/2010 03:01 PM, Gabriel Dos Reis wrote:
In the guidelines, I would like to include:
(2) if you define a class template used mostly with pointer type arguments,
consider specializing for void* (or const void*) and define all other
pointer specialization in terms of th
> However, if I changed the code, but did not regenerate the docs, and you
> then picked up my changes, possibly made more of your own, and then
> regenerated the docs, *you* would be in breach. (Because my changes are
> only available to you under the GPL; you do not have the right to
> relicense
Dave Korn wrote:
>> "If Texinfo text is included the .h files specifically to be copied into
>> a manual, it is ok to for you copy that text into a manual and release
>> the manual under the GFDL."
>>
>> In context, "you" means "the GCC maintainers" and the permission would
>> be limited only to c
Richard Guenther writes:
> On Tue, Jun 1, 2010 at 6:58 PM, Ian Lance Taylor wrote:
>> Richard Guenther writes:
>>
>>> Overall the wiki document looks good. I'd like to disallow
>>>
>>> * Operators may only be overloaded for types which implement numeric
>>> values, where the overloaded operato
Laurynas Biveinis writes:
> 2010/6/2 Ian Lance Taylor :
>>> Ian, do you have an idea on how to avoid _M_impl dependency in
>>> gengtype or what else to do about it?
>>>
>>> Because we can trivially make gengtype mark the vector itself and mark
>>> whatever was put into vector, but not _M_impl.
>>
Jakub Jelinek writes:
> But do we really want to use std::vector? The vec.h, appart from
> having ugly syntactic sugar, seems to be more space efficient, has better
> aliasing properties (given that it is just one pointer, you can e.g. use
> restrict on it easily) and seems to have more operatio
On Wed, Jun 2, 2010 at 4:35 AM, Richard Guenther
wrote:
> On Wed, Jun 2, 2010 at 2:49 AM, Gabriel Dos Reis
> wrote:
>> On Tue, Jun 1, 2010 at 7:38 PM, DJ Delorie wrote:
>>>
>>> "Hargett, Matt" writes:
> As noted earlier I think we do want to use some STL classes.
I agree with Mark
On Wed, Jun 2, 2010 at 3:04 PM, Gabriel Dos Reis
wrote:
> On Wed, Jun 2, 2010 at 4:19 AM, Richard Guenther
> wrote:
>
>> I'd like us to stick with C comments only. I defintely do not like
>> a mix of both styles and I can't see an advantage of C++ comments.
>
> It does not have a 'gotcha' for co
On Wed, Jun 2, 2010 at 4:19 AM, Richard Guenther
wrote:
> I'd like us to stick with C comments only. I defintely do not like
> a mix of both styles and I can't see an advantage of C++ comments.
It does not have a 'gotcha' for commenting out codes.
On Wed, Jun 2, 2010 at 2:44 AM, Paolo Bonzini wrote:
> In particular, I wonder if the best use of C++ wouldn't be a set of
> functions (including templates, etc.) implementing a kind of RTTI with a
> less verbose syntax than what we have now.
Agreed. I don't agree with the rejection of simple f
On Mon, 2010-05-31 at 08:40 -0700, Mark Mitchell wrote:
> Eric Botcazou wrote:
>
> >> We do require long long for 32->64 cross compilers.
> >
> > Right, only in this case, and I don't see why this should be changed with
> > the
> > transition to C++, that's orthogonal.
>
> I agree.
We need i
On Wed, Jun 2, 2010 at 1:22 AM, Ian Lance Taylor wrote:
> Basile Starynkevitch writes:
>
>> On Tue, 2010-06-01 at 19:49 -0500, Gabriel Dos Reis wrote:
>>> (2) we should prefer standard solution over home-grown hacks, unless
>>> there is a clear demonstration of value. For example, i
On Tue, Jun 1, 2010 at 11:43 PM, Basile Starynkevitch
wrote:
> On Tue, 2010-06-01 at 19:49 -0500, Gabriel Dos Reis wrote:
>> (2) we should prefer standard solution over home-grown hacks, unless
>> there is a clear demonstration of value. For example, it would be
>> unwise to
Hi,
On Wed, 2 Jun 2010, Richard Guenther wrote:
> Well, on the one hand I agree - but on the other hand I see people
> eagerly waiting to be the first to post patches to convert all VEC uses
> that allocate from the heap(!) (yes - we can't use STL for GC allocated
> stuff!), leaving us with fi
On Wed, Jun 2, 2010 at 5:00 AM, Bingfeng Mei wrote:
> Hi,
>
> For the following simple example,
>
> int main(void)
> {
> int a=0;
> switch (a)
> {
> case 0:
> int b=2;
> break;
> }
> }
>
> GCC will complain:
> tst.c: In function 'main':
> tst.c:7:6: error: a label can only be p
Hi,
On Tue, 1 Jun 2010, Ian Lance Taylor wrote:
> >> > * Use C-style comments for multi-line comments, and C++-style comments
> >> > for single-line comments.
> >>
> >> I'm not sure i agree with this, because I don't see anything wrong
> >> with multi-line C++-style comments.
> >
> > It assume
On Wed, Jun 2, 2010 at 1:51 PM, David Edelsohn wrote:
> On Wed, Jun 2, 2010 at 2:07 AM, Laurynas Biveinis
> wrote:
>> Hello all -
>>
>> All the patches from gc-improv merge have been approved. Due to the
>> scope of the changes, the merge will need trunk freeze. Thus I am
>> planning to do it nex
Well, on the one hand I agree - but on the other hand I see people
eagerly waiting to be the first to post patches to convert all
VEC uses that allocate from the heap(!) (yes - we can't use STL
for GC allocated stuff!), leaving us with files that use a mix of
stl::vector and VEC. VEC is clearly s
On Wed, Jun 2, 2010 at 2:07 AM, Laurynas Biveinis
wrote:
> Hello all -
>
> All the patches from gc-improv merge have been approved. Due to the
> scope of the changes, the merge will need trunk freeze. Thus I am
> planning to do it next Tuesday, at 7am CEST. The freeze should last
> about 2-3 hours
On 02.06.2010 01:31, Mark Mitchell wrote:
I will state explicitly up front a few topics I am not raising, because
I do not think they are either necessary, or likely to be productive:
* Whether or not the GFDL is a "free" license, or whether it's a good
license, or anything else about its merits
On 02/06/2010 00:38, Ian Lance Taylor wrote:
> DJ Delorie writes:
* Use C-style comments for multi-line comments, and C++-style comments
for single-line comments.
>>> I'm not sure i agree with this, because I don't see anything wrong
>>> with multi-line C++-style comments.
>> It assum
On 02/06/2010 00:31, Mark Mitchell wrote:
> At this point, RMS has said, answered this question from me:
>
> "Can we take comments (not code) from FSF-owned GPL'd code and process
> them in some way that results in them being included in a GFDL'd manual?"
>
> by saying, in part:
>
> "If Texinfo
On Wed, Jun 2, 2010 at 12:00 PM, Bingfeng Mei wrote:
> Hi,
>
> For the following simple example,
>
> int main(void)
> {
> int a=0;
> switch (a)
> {
> case 0:
> int b=2;
> break;
> }
> }
>
> GCC will complain:
> tst.c: In function 'main':
> tst.c:7:6: error: a label can only be
Hi,
For the following simple example,
int main(void)
{
int a=0;
switch (a)
{
case 0:
int b=2;
break;
}
}
GCC will complain:
tst.c: In function 'main':
tst.c:7:6: error: a label can only be part of a statement and a declaration is
not a statement
G++ will compil
Converting to C++ is a major change. Does that justify to have a major release
(5.0.0)?
Bingfeng
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> Richard Guenther
> Sent: 02 June 2010 10:36
> To: Gabriel Dos Reis
> Cc: DJ Delorie; Hargett,
On Wed, Jun 2, 2010 at 2:49 AM, Gabriel Dos Reis
wrote:
> On Tue, Jun 1, 2010 at 7:38 PM, DJ Delorie wrote:
>>
>> "Hargett, Matt" writes:
As noted earlier I think we do want to use some STL classes.
>>>
>>> I agree with Mark's earlier declaration that it is relatively
>>> straight-forward,
> I'd like us to stick with C comments only. I defintely do not like
> a mix of both styles and I can't see an advantage of C++ comments.
It indeed seems to fall into the buy-us-nothing category.
--
Eric Botcazou
On Wed, Jun 2, 2010 at 1:38 AM, Ian Lance Taylor wrote:
> DJ Delorie writes:
>
>>> I did mean that all virtual functions should be protected.
>>
>> This forbids the most useful thing about virtual functions - letting
>> child classes implement a public ABI defined by the base class.
>
> There are
On Tue, Jun 1, 2010 at 6:37 PM, Robert Dewar wrote:
> Richard Guenther wrote:
>>
>> On Tue, Jun 1, 2010 at 4:48 PM, Mark Mitchell
>> wrote:
>>>
>>> Ian Lance Taylor wrote:
>>>
I have written a proposed set of C++ coding conventions on the wiki at
http://gcc.gnu.org/wiki/CppConvention
On Tue, Jun 1, 2010 at 6:58 PM, Ian Lance Taylor wrote:
> Richard Guenther writes:
>
>> Overall the wiki document looks good. I'd like to disallow
>>
>> * Operators may only be overloaded for types which implement numeric
>> values, where the overloaded operators implement the usual numeric
>> s
On Tue, Jun 1, 2010 at 6:32 PM, Vladimir Makarov wrote:
> Richard Guenther wrote:
>>
>> On Tue, Jun 1, 2010 at 12:00 PM, Richard Guenther
>> wrote:
>>
>>>
>>> On Mon, May 31, 2010 at 6:22 PM, Diego Novillo
>>> wrote:
>>>
Now that the SC and the FSF have agreed to this, we should decide
On Wed, Jun 02, 2010 at 08:28:53AM +0200, Laurynas Biveinis wrote:
> See http://gcc.gnu.org/wiki/gcc-in-cxx , section "Major TODO":
> work out the details of using STL containers with GC allocated
> objects. This means teaching gengtype how to generate code to traverse
> STL containers, which would
On 06/01/2010 04:11 PM, Ian Lance Taylor wrote:
In the gccgo IR I don't represent everything with a single type.
Instead, I use a separate base class for types, expressions and
statements (in Go there is more of a distinction between expressions
and statements than there is in C/C++). I represe
71 matches
Mail list logo
