On 2005-05-25, at 08:06, Christoph Hellwig wrote:
On Tue, May 24, 2005 at 05:14:42PM -0700, Zack Weinberg wrote:
I'm not sure what the above may imply for your ongoing
discussion, tough...
Well, if I were running the show, the 'clock' would only start
running
when it was consensus amo
On 2005-05-24, at 18:06, Diego Novillo wrote:
On Mon, May 23, 2005 at 01:15:17AM -0500, Gabriel Dos Reis wrote:
So, if various components maintainers (e.g. C and C++, middle-end,
ports, etc.) are willing to help quickly reviewing patches we can
have this done for this week (assuming mainlin
On 2005-05-24, at 06:00, Andrew Pinski wrote:
On May 24, 2005, at 12:01 AM, Zack Weinberg wrote:
Use of bare 'inline' is just plain wrong in our source code; this has
nothing to do with C++, no two C compilers implement bare 'inline'
alike. Patches to add 'static' to such functions (AND MAK
On 2005-05-24, at 09:09, Zack Weinberg wrote:
Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
[dropping most of the message - if I haven't responded, assume I don't
agree but I also don't care enough to continue the argument. Also,
rearranging paragraphs a bit so as not to have to repeat myself]
On 2005-05-23, at 08:15, Gabriel Dos Reis wrote:
Sixth, there is a real "mess" about name spaces. It is true that
every C programmers knows the rule saying tags inhabit different name
space than variable of functions. However, all the C coding standards
I've read so far usually suggest
t
"Kaveh R. Ghazi" <[EMAIL PROTECTED]> writes:
| > > Now we have e.g. XNEW* and all we need is a new -W* flag to catch
| > > things like using C++ keywords and it should be fairly automatic to
| > > keep incompatibilities out of the sources.
| >
| > Why not this?
| >
| > #ifndef __cplusplus
> which is defined to correspond to some physical mode
Close. Defined to correspond to one or more physical modes.
> - Huh?, can you provide a single example of where a char type would
> be mapped by the target to two different target specified modes?
i386 can hold a char in %al (QImode) o
> From: DJ Delorie <[EMAIL PROTECTED]>
>> - ok, and how does it know that it needs a 32-bit unsigned scalar?
>
> tm.h: #define INT_TYPE_SIZE 32
>
> Combined with "unsigned int foo;" in the user's source file.
>
> The MI doesn't need to know that this fits in a QImode.
- agreed, all it needs to
> - ok, and how does it know that it needs a 32-bit unsigned scalar?
tm.h: #define INT_TYPE_SIZE 32
Combined with "unsigned int foo;" in the user's source file.
The MI doesn't need to know that this fits in a QImode.
> the world is it desirable to go go in a big circle to identify
> which
> From: DJ Delorie <[EMAIL PROTECTED]>
>
>> where then the target may declare class machine_mode
>> target_int_mode ("HI", 16),
>
> This is where we disagree. The *target* shouldn't map types to modes.
> The *MI* should map types to modes. The target just creates the modes
> it supports and
Zack Weinberg <[EMAIL PROTECTED]> wrote:
>>> This doesn't do what I want at all. The goal is to make the *symbolic
>>> enumeration constants* inaccessible to most code.
>>
> ...
>> If it's OK to have the enums in a header, provided you can't *use*
them...
>>
>> enum {
>> #ifdef TVQ_AUTHORITATIVE_
And YES I have a port with multiple pointer sizes, and YES the
customer wanted both sizes supported in a single compilation unit
This is actually not that uncommon.
Oh, and sometimes gcc randomly uses pointer_mode instead of Pmode. I
haven't a clue why there's a difference, or h
> where then the target may declare class machine_mode
> target_int_mode ("HI", 16),
This is where we disagree. The *target* shouldn't map types to modes.
The *MI* should map types to modes. The target just creates the modes
it supports and describes them. The MI looks them up by descripti
On Tue, 24 May 2005 17:32:27 -0700, Zack Weinberg <[EMAIL PROTECTED]> wrote:
> On Tue, 2005-05-24 at 20:11 -0400, Daniel Jacobowitz wrote:
>> If that's why you were confused by my response, I was not suggesting
>> freezing the ABI. I think it's an awful idea.
>
> Why? To be honest, I keep har
> > Now we have e.g. XNEW* and all we need is a new -W* flag to catch
> > things like using C++ keywords and it should be fairly automatic to
> > keep incompatibilities out of the sources.
>
> Why not this?
>
> #ifndef __cplusplus
> #pragma GCC poison class template new . . .
> #endif
T
* Christoph Hellwig:
> Why can't libstdc++ use symbol versioning?
Via stack allocation, templates and inline functions, the internal
representation of libstdc++ data structures is exported. All of its
users would have to be versioned, too, and you'd need bridging code
between the ABIs (e.g. to p
On Tue, May 24, 2005 at 05:14:42PM -0700, Zack Weinberg wrote:
> > I'm not sure what the above may imply for your ongoing discussion, tough...
>
> Well, if I were running the show, the 'clock' would only start running
> when it was consensus among the libstdc++ developers that the soname
> would n
Kevin Handy wrote:
>> That was caught at link time (and dealt with).
>>
>>
> Would it be possible to add a diagnostic to GCC to warn when C++
> keywords are being used as identifiers? Maybe also add any
> objective C keywords too.
>
> This seems like it would be useful to someone writing librar
> From: DJ Delorie <[EMAIL PROTECTED]>
>> Might it be more desirable for the compiler's code to only refer to
>> target "type" modes as opposed to "size" modes?
>
> Not always, see my mail about Pmode. The problem isn't just how gcc
> refers to machine words, but that gcc assumes their usage is c
On Mon, 23 May 2005 23:25:13 -0700, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Good point; yes, you would have to pass a pointer. I guess you could
> create a singleton representative of each value in the enum, and pass
> them around, but I agree that's getting pretty ugly. Of course, the
> prob
DJ Delorie <[EMAIL PROTECTED]> writes:
| > Now we have e.g. XNEW* and all we need is a new -W* flag to catch
| > things like using C++ keywords and it should be fairly automatic to
| > keep incompatibilities out of the sources.
|
| Why not this?
|
| #ifndef __cplusplus
| #pragma GCC poison class
> Now we have e.g. XNEW* and all we need is a new -W* flag to catch
> things like using C++ keywords and it should be fairly automatic to
> keep incompatibilities out of the sources.
Why not this?
#ifndef __cplusplus
#pragma GCC poison class template new . . .
#endif
> Might it be more desirable for the compiler's code to only refer to
> target "type" modes as opposed to "size" modes?
Not always, see my mail about Pmode. The problem isn't just how gcc
refers to machine words, but that gcc assumes their usage is context
independent or inflexible. For example
> Gabriel Dos Reis
>| J Delorie writes:
>| And the target can do this in tm.c:
>|
>| class machine_mode SImode ("SI", 32);
>| class machine_mode V4QImode ("V4QI", 8, 0, 8, 4);
>|
>| Then, the MI parts can obtain a mode with certain characteristics,
>| enumerate available modes, and
DJ Delorie <[EMAIL PROTECTED]> writes:
| > The cases I've found in my conversion was when codes use plain
| > "0" instead of VOIDmode or whatever machine_mode is appropriate.
| > That use of plain 0 breaks compilation with a C++ compiler.
|
| If the #include isn't portable enough, just hard code
> > unrestricted use of C++ keywords; declaring structure fields with
> > the same name as a structure tag in scope.
>
> I don't think we should be reverting patches that fall afoul of these
> last two, even if they break Gaby's build-with-a-C++-compiler
> builds. But, I would tend to acce
> The cases I've found in my conversion was when codes use plain
> "0" instead of VOIDmode or whatever machine_mode is appropriate.
> That use of plain 0 breaks compilation with a C++ compiler.
If the #include isn't portable enough, just hard code a 42. We'd need
suitable changes for insn-modes
DJ Delorie <[EMAIL PROTECTED]> writes:
| >(2) When and if you switch to this:
| >
| > class machine_mode
| > {
| > enum value_t {
| >VOIDmode, SImode, // ...
| > } value;
| >
| > // accessors, whatever ...
| > };
|
| I think w
On Tue, May 24, 2005 at 05:32:27PM -0700, Zack Weinberg wrote:
> On Tue, 2005-05-24 at 20:11 -0400, Daniel Jacobowitz wrote:
> > On Tue, May 24, 2005 at 05:14:42PM -0700, Zack Weinberg wrote:
> > > Well, if I were running the show, the 'clock' would only start running
> > > when it was consensus am
DJ Delorie <[EMAIL PROTECTED]> writes:
| > No, the goal is to make the *values* inaccessible, not the names.
|
| No, *I* want gcc to stop doing *&$@ like this:
|
| stack_parm = gen_rtx_PLUS (Pmode, stack_parm, offset_rtx);
|
| It should use GET_MODE(stack_parm) in case the target has multiple
Zack Weinberg <[EMAIL PROTECTED]> writes:
| On Tue, 2005-05-24 at 20:54 -0400, DJ Delorie wrote:
| > > This doesn't do what I want at all. The goal is to make the *symbolic
| > > enumeration constants* inaccessible to most code.
| >
| ...
| > If it's OK to have the enums in a header, provided yo
> Furthermore, that does not stop an enthusiastic programmer from
> feeding the interface functions with the wrong values
If you seed the first enum from DATESTAMP, and properly range check,
you can find these cases pretty quickly and abort.
TVQ_SEED = (DATESTAMP%10) * 1000,
TVQ_FOO1,
...
> No, the goal is to make the *values* inaccessible, not the names.
No, *I* want gcc to stop doing *&$@ like this:
stack_parm = gen_rtx_PLUS (Pmode, stack_parm, offset_rtx);
It should use GET_MODE(stack_parm) in case the target has multiple
pointer sizes.
And YES I have a port with multiple
DJ Delorie <[EMAIL PROTECTED]> writes:
[...]
| If it's OK to have the enums in a header, provided you can't *use* them...
|
| enum {
| #ifdef TVQ_AUTHORITATIVE_ENUMS
| TVQ_FOO1,
| TVQ_FOO2,
| TVQ_FOO3,
| TVQ_NUM_ENTRIES,
| #endif
| TVQ_INT_SIZER = 32767;
| } TheValQuux;
|
| This won't sto
>(2) When and if you switch to this:
>
> class machine_mode
> {
> enum value_t {
>VOIDmode, SImode, // ...
> } value;
>
> // accessors, whatever ...
> };
I think what Mark wants is to migrate to this:
class machine_mo
Zack Weinberg <[EMAIL PROTECTED]> writes:
| On Tue, 2005-05-24 at 20:27 -0400, DJ Delorie wrote:
| > > This is still not an answer to the question I originally asked - do you
| > > see any way IN C to write code which has the relevant property of the
| > > class above (that is, that the FOOmode co
On Tue, 2005-05-24 at 20:54 -0400, DJ Delorie wrote:
> > This doesn't do what I want at all. The goal is to make the *symbolic
> > enumeration constants* inaccessible to most code.
>
...
> If it's OK to have the enums in a header, provided you can't *use* them...
>
> enum {
> #ifdef TVQ_AUTHORIT
> This doesn't do what I want at all. The goal is to make the *symbolic
> enumeration constants* inaccessible to most code.
Oh.
enum {
THE_VAL_QUUX_ENUMS
} TheValQuux;
If not defined, you get one enum, THE_VAL_QUUX_ENUMS. The "authority"
can define it to a list of enums, so it gets expanded.
Russ Allbery <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
| > Zack Weinberg <[EMAIL PROTECTED]> writes:
|
| > | (And I'd be less grumpy about coding to the intersection of C and C++
| > | if someone coded up warnings for the C compiler to catch things
| > | outside t
Zack Weinberg <[EMAIL PROTECTED]> writes:
| On Wed, 2005-05-25 at 03:03 +0200, Gabriel Dos Reis wrote:
| > Zack Weinberg <[EMAIL PROTECTED]> writes:
| >
| > | On Tue, 2005-05-24 at 10:49 +0200, Gabriel Dos Reis wrote:
| > | > | So you don't see any value whatsoever to having (for instance) the
|
Zack Weinberg <[EMAIL PROTECTED]> writes:
> Think about how machine_mode values are used. Almost the entire
> compiler is supposed to treat them as opaque things. You get them from
> e.g. int_mode_for_size; you may iterate over a class with
> GET_MODE_WIDER_MODE; you stash them in RTL and you pa
Zack Weinberg wrote:
>Why? To be honest, I keep harping on this mostly because I think it
>should happen. All the C++-in-GCC noise is a digression.
>
>
I was wondering: is it too late to organize a Panel at GCCSummit?
Otherwise we can meet anyway more informally and discuss all those
issues
On Tue, 2005-05-24 at 20:27 -0400, DJ Delorie wrote:
> > This is still not an answer to the question I originally asked - do you
> > see any way IN C to write code which has the relevant property of the
> > class above (that is, that the FOOmode constants are not accessible
> > except to authorized
> This is still not an answer to the question I originally asked - do you
> see any way IN C to write code which has the relevant property of the
> class above (that is, that the FOOmode constants are not accessible
> except to authorized code) and which does not rely on free conversion
> between
On Tue, 2005-05-24 at 20:11 -0400, Daniel Jacobowitz wrote:
> On Tue, May 24, 2005 at 05:14:42PM -0700, Zack Weinberg wrote:
> > Well, if I were running the show, the 'clock' would only start running
> > when it was consensus among the libstdc++ developers that the soname
> > would not be bumped ag
Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
> Zack Weinberg <[EMAIL PROTECTED]> writes:
> | (And I'd be less grumpy about coding to the intersection of C and C++
> | if someone coded up warnings for the C compiler to catch things
> | outside the intersection.)
> Consider that to be a follow-up t
On Tue, May 24, 2005 at 05:14:42PM -0700, Zack Weinberg wrote:
> Well, if I were running the show, the 'clock' would only start running
> when it was consensus among the libstdc++ developers that the soname
> would not be bumped again - that henceforth libstdc++ was committed to
> binary compatibil
On Wed, 2005-05-25 at 01:45 +0200, Paolo Carlini wrote:
> >.. However, the active development on the
> >libstdc++.so.7 branch means that we haven't even started the clock
> >running on this criterion yet.
>
> Maybe a clarification is in order: actually, the name
> libstdcxx
On Wed, 2005-05-25 at 03:03 +0200, Gabriel Dos Reis wrote:
> Zack Weinberg <[EMAIL PROTECTED]> writes:
>
> | On Tue, 2005-05-24 at 10:49 +0200, Gabriel Dos Reis wrote:
> | > | So you don't see any value whatsoever to having (for instance) the
> | > | individual constants of 'enum machine_mode' be
Zack Weinberg <[EMAIL PROTECTED]> writes:
| On Tue, 2005-05-24 at 10:49 +0200, Gabriel Dos Reis wrote:
| > | So you don't see any value whatsoever to having (for instance) the
| > | individual constants of 'enum machine_mode' be inaccessible in most of
| > | GCC? 'cos I sure do.
| >
| > What I'm
Hi,
>.. However, the active development on the
>libstdc++.so.7 branch means that we haven't even started the clock
>running on this criterion yet.
>
>
Maybe a clarification is in order: actually, the name
libstdcxx_so_7-branch is somewhat misleading, right now. Indeed, i
On Tue, 2005-05-24 at 19:17 -0400, Daniel Jacobowitz wrote:
> On Tue, May 24, 2005 at 04:20:27PM -0700, Zack Weinberg wrote:
> > Um, there have been plenty of cases in the past where the top level set
> > something correctly and the subdirectory makefiles overrode it with an
> > incorrect setting.
On Tue, May 24, 2005 at 07:17:22PM -0400, Daniel Jacobowitz wrote:
> $ORIGIN is nifty; but do you know how portable it is? I've got no
> clue.
Solaris and Linux only, afaik.
r~
On Tue, May 24, 2005 at 04:20:27PM -0700, Zack Weinberg wrote:
> Um, there have been plenty of cases in the past where the top level set
> something correctly and the subdirectory makefiles overrode it with an
> incorrect setting.
Ah, but once we have a globally correct setting in the top level we
On Tue, 2005-05-24 at 09:41 -0400, Daniel Jacobowitz wrote:
> We've fixed a lot of these problems already; I will be brave and say
> that we have fixed most of them.
I'm glad you're optimistic about it. It's good to have someone
balancing out pessimistic people like me. :)
> > This scenario, at
On Tue, 2005-05-24 at 10:49 +0200, Gabriel Dos Reis wrote:
> | So you don't see any value whatsoever to having (for instance) the
> | individual constants of 'enum machine_mode' be inaccessible in most of
> | GCC? 'cos I sure do.
>
> What I'm saying is that when you have a name like EXPAND_NORMAL,
Diego Novillo wrote:
On Mon, May 23, 2005 at 01:15:17AM -0500, Gabriel Dos Reis wrote:
So, if various components maintainers (e.g. C and C++, middle-end,
ports, etc.) are willing to help quickly reviewing patches we can
have this done for this week (assuming mainline is unslushed soon).
An
Gabriel Dos Reis wrote:
Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
[...]
| Attempt to get the GNU C++ compiler through the same massage is
| underway (but I'm going to bed shortly ;-)).
I can also report that I got the GNU C++ compiler through -- and apart
form uses of C++ keywords (templat
On May 24, 2005, at 9:43 AM, Joe Buck wrote:
On Tue, May 24, 2005 at 05:03:27PM +0200, Andreas Schwab wrote:
Paul Koning <[EMAIL PROTECTED]> writes:
I hope that doesn't require (void *) casts for pointer arguments
passed to the likes of memcpy...
Only the (void*) -> (any*) direction requires
On Tue, May 24, 2005 at 05:03:27PM +0200, Andreas Schwab wrote:
> Paul Koning <[EMAIL PROTECTED]> writes:
> > I hope that doesn't require (void *) casts for pointer arguments
> > passed to the likes of memcpy...
>
> Only the (void*) -> (any*) direction requires a cast in C++, the other
> direction
On 5/24/05, Diego Novillo <[EMAIL PROTECTED]> wrote:
> On Mon, May 23, 2005 at 01:15:17AM -0500, Gabriel Dos Reis wrote:
>
> > So, if various components maintainers (e.g. C and C++, middle-end,
> > ports, etc.) are willing to help quickly reviewing patches we can
> > have this done for this week
On Mon, May 23, 2005 at 01:15:17AM -0500, Gabriel Dos Reis wrote:
> So, if various components maintainers (e.g. C and C++, middle-end,
> ports, etc.) are willing to help quickly reviewing patches we can
> have this done for this week (assuming mainline is unslushed soon).
> And, of course, everyb
Paul Koning <[EMAIL PROTECTED]> writes:
| > "Gabriel" == Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
|
| Gabriel> http://www.gnu.org/software/gcc/codingconventions.html
|
| Gabriel> Avoid the use of identifiers or idioms that would prevent
| Gabriel> code compiling with a C++ compiler. I
Paul Koning <[EMAIL PROTECTED]> writes:
>> "Gabriel" == Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
>
> Gabriel> http://www.gnu.org/software/gcc/codingconventions.html
>
> Gabriel> Avoid the use of identifiers or idioms that would prevent
> Gabriel> code compiling with a C++ compiler. Iden
> "Gabriel" == Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
Gabriel> http://www.gnu.org/software/gcc/codingconventions.html
Gabriel> Avoid the use of identifiers or idioms that would prevent
Gabriel> code compiling with a C++ compiler. Identifiers such as new
Gabriel> or class, that are r
[Rearranging]
> I want to emphasize that I don't think any of these are unsolvable
> problems. I do think they are all real problems, and I think there
> are going to be other problems I haven't listed above, and I want to
> be sure we have considered the problems and have solutions in hand
> bef
> This scenario, at least theoretically, becomes a non-issue if we make
top-level bootstrap the only option before we start using C++ features
in GCC, but that hasn't happened yet.
It will happen soon after the end of the slush. The last preliminary
patch has already been posted, then all one
[EMAIL PROTECTED] (Mark Mitchell) wrote on 23.05.05 in <[EMAIL PROTECTED]>:
> Zack Weinberg wrote:
> > Mark Mitchell <[EMAIL PROTECTED]> writes:
> >
> > [snip stuff addressed elsewhere]
> >
> >>I agree with the goal of more hiding.
> >>
> >>You can do this in C by using an incomplete structure ty
Florian Weimer <[EMAIL PROTECTED]> writes:
| * Gabriel Dos Reis:
|
| > The first resistance seems to come from the pervasive use of the implicit
| > conversion void* -> T*, mostly with storage allocating functions.
|
| This can be worked around on the C++ side, see the example code below.
| It's
Zack Weinberg <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
|
| > But we do not get any expressive power by using C++ keywords.
|
| Readability, readability, readability.
|
| (for instance, 'class' vs. 'klass'
When replacing "class" with a new identifier, "klass"
Zack Weinberg <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
|
| [dropping most of the message - if I haven't responded, assume I don't
| agree but I also don't care enough to continue the argument. Also,
| rearranging paragraphs a bit so as not to have to repeat myse
* Gabriel Dos Reis:
> The first resistance seems to come from the pervasive use of the implicit
> conversion void* -> T*, mostly with storage allocating functions.
This can be worked around on the C++ side, see the example code below.
It's a kludge, but it's not too bad IMHO.
class xmalloc_resul
Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
> But we do not get any expressive power by using C++ keywords.
Readability, readability, readability.
(for instance, 'class' vs. 'klass' - I can read decimal orders of
magnitude faster if all the English words in what I'm reading are
correctly spel
Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
[dropping most of the message - if I haven't responded, assume I don't
agree but I also don't care enough to continue the argument. Also,
rearranging paragraphs a bit so as not to have to repeat myself]
> with the explicit call to malloc + explicit sp
Mark Mitchell <[EMAIL PROTECTED]> writes:
[...]
| > unrestricted use of C++ keywords;
| >
| > declaring structure fields with the same name as a structure tag in
| > scope.
|
| I don't think we should be reverting patches that fall afoul of these
| last two, even if they break Gaby's build-with
Zack Weinberg <[EMAIL PROTECTED]> writes:
| Mark Mitchell <[EMAIL PROTECTED]> writes:
| ...
| > Like you, I do think these problems are surmountable; but, also like
| > you, I think it would take some time to get all the problems solved.
| > I don't really think, though, that this is immediately r
Zack Weinberg <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
|
| [...]
| > The cast you're talking about is buried deep in XNEWVEC, XRESIZEVEC
| > and such. It is not anything you'll find in the code directly. So,
| > in fact we do not lose readability as you claim.
Zack Weinberg wrote:
(And I'd be less grumpy about coding to the intersection of C and C++
if someone coded up warnings for the C compiler to catch things
outside the intersection.)
My feeling on this is that it's not fair to expect people to know C++,
until and unless we switch to actually u
Mark Mitchell <[EMAIL PROTECTED]> writes:
...
> Like you, I do think these problems are surmountable; but, also like
> you, I think it would take some time to get all the problems solved.
> I don't really think, though, that this is immediately relevant;
> Gaby's trying to fix things that seem to m
Zack Weinberg wrote:
Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
[...]
The cast you're talking about is buried deep in XNEWVEC, XRESIZEVEC
and such. It is not anything you'll find in the code directly. So,
in fact we do not lose readability as you claim.
To be honest, I think XNEW* are l
Zack Weinberg wrote:
Mark Mitchell <[EMAIL PROTECTED]> writes:
[snip stuff addressed elsewhere]
I agree with the goal of more hiding.
You can do this in C by using an incomplete structure type in most
places, and then, in the files where you want the definition visible,
defining the structure
Mark Mitchell <[EMAIL PROTECTED]> writes:
[snip stuff addressed elsewhere]
> I agree with the goal of more hiding.
>
> You can do this in C by using an incomplete structure type in most
> places, and then, in the files where you want the definition visible,
> defining the structure to have a singl
Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
[...]
> The cast you're talking about is buried deep in XNEWVEC, XRESIZEVEC
> and such. It is not anything you'll find in the code directly. So,
> in fact we do not lose readability as you claim.
To be honest, I think XNEW* are less readable than bar
Zack Weinberg wrote:
Um, yeah. I completely botched that explanation. My apologies. I'm
concerned about four different scenarios which may arise when the
preexisting C++ compiler and runtime are ABI-incompatible with the C++
compiler and runtime being built; none are source compatibility
issu
Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
> On Mon, May 23, 2005 at 09:01:20PM -0700, Zack Weinberg wrote:
>> Furthermore, as I've said before, I support migrating
>> to C++ -- but only if the C++ ABI and libstdc++ soname are first
>> permanently frozen. If we do not do that first, we risk be
Zack Weinberg wrote:
On Mon, 2005-05-23 at 01:15 -0500, Gabriel Dos Reis wrote:
Hi,
I spent the week-end trying to get GCC -- mainline -- compilable
(i.e. those compoenents written in C) with a C++ compiler (e.g. g++).
These results are very interesting.
As a general observation: A lot of
Andrew Pinski <[EMAIL PROTECTED]> writes:
| On May 24, 2005, at 12:01 AM, Zack Weinberg wrote:
| > Use of bare 'inline' is just plain wrong in our source code; this has
| > nothing to do with C++, no two C compilers implement bare 'inline'
| > alike. Patches to add 'static' to such functions (AND
Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
| On Mon, May 23, 2005 at 09:01:20PM -0700, Zack Weinberg wrote:
| > As a general observation: A lot of the things you have found to be
| > problematic, are in fact preferred idioms for C code. For instance,
| > no standard-C programmer would ever wri
Zack Weinberg <[EMAIL PROTECTED]> writes:
| On Mon, 2005-05-23 at 01:15 -0500, Gabriel Dos Reis wrote:
| > Hi,
| >
| > I spent the week-end trying to get GCC -- mainline -- compilable
| > (i.e. those compoenents written in C) with a C++ compiler (e.g. g++).
|
| These results are very interesti
On May 24, 2005, at 12:01 AM, Zack Weinberg wrote:
Use of bare 'inline' is just plain wrong in our source code; this has
nothing to do with C++, no two C compilers implement bare 'inline'
alike. Patches to add 'static' to such functions (AND MAKING NO OTHER
CHANGES) are preapproved, post-slush.
On Mon, May 23, 2005 at 09:01:20PM -0700, Zack Weinberg wrote:
> As a general observation: A lot of the things you have found to be
> problematic, are in fact preferred idioms for C code. For instance,
> no standard-C programmer would ever write an explicit cast on malloc's
> return value. I thin
On Mon, 2005-05-23 at 01:15 -0500, Gabriel Dos Reis wrote:
> Hi,
>
> I spent the week-end trying to get GCC -- mainline -- compilable
> (i.e. those compoenents written in C) with a C++ compiler (e.g. g++).
These results are very interesting.
As a general observation: A lot of the things you ha
On Tue, 24 May 2005, Gabriel Dos Reis wrote:
> I can also report that I got the GNU C++ compiler through -- and apart
> form uses of C++ keywords (template, namespace, class), it worked
> out. A note on type sfety issue though: lookup_name() is declared in
> c-tree.h as
>
> extern tree loo
Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
[...]
| Attempt to get the GNU C++ compiler through the same massage is
| underway (but I'm going to bed shortly ;-)).
I can also report that I got the GNU C++ compiler through -- and apart
form uses of C++ keywords (template, namespace, class), it wo
> "Ranjit" == Ranjit Mathew <[EMAIL PROTECTED]> writes:
>> (4) .
Ranjit> Tom Tromey's GCJX (gcjx_branch in CVS), the completely
Ranjit> rewritten Java front-end that is written in C++.
Plugging this into gcc has largely been fine, thanks to an earlier
round of patches in this area.
The bigg
Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
| Hi,
|
| I spent the week-end trying to get GCC -- mainline -- compilable
| (i.e. those compoenents written in C) with a C++ compiler (e.g. g++).
|
| My summary is: It is largely doable and it is within our reach at this
| point of development. M
Gabriel Dos Reis wrote:
> Hi,
>
> I spent the week-end trying to get GCC -- mainline -- compilable
> (i.e. those compoenents written in C) with a C++ compiler (e.g. g++).
[...]
>
> I think this project is beneficial to GCC for several reasons:
[...]
>
> (4) .
Tom Tromey's GCJX (gcjx_bran
Hi,
I spent the week-end trying to get GCC -- mainline -- compilable
(i.e. those compoenents written in C) with a C++ compiler (e.g. g++).
My summary is: It is largely doable and it is within our reach at this
point of development. More specifically, I successfully got all
files necessary to
98 matches
Mail list logo
