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
| #pragma
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
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-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
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
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
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 not be
* 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
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 harping on
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 description
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
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_ENUMS
TVQ_FOO1,
- 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 mode
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 know is that
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) or
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 being
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 bare
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 single
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
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
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 me
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
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 [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
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
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
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
* 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_result;
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 myself]
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 a
[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 type in most
places,
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
[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
before
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 reserved
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. Identifiers such as new
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. Identifiers
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, everybody
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 (assuming
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 is still
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 a
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
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).
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, you
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, 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, 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, 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.
Ah,
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, it's
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 saying
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
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
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 compatibility
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 that I'm
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 again -
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 code)
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
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 pass
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
| | |
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 the
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.
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
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 constants
(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_mode_desc
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 stop
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
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,
...
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 you can't
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
|
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 among the
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 what Mark
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.c
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 accept
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 a 42.
Gabriel Dos Reis gdr at integrable-solutions dot net
| J Delorie dj at redhat dot com 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
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,
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 context
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 library
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
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) insert your favorite reasons why you
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.
Ranjit == Ranjit Mathew [EMAIL PROTECTED] writes:
(4) insert your favorite reasons why you would like to see this happen.
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
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
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 have
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 think
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,
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 interesting.
|
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 write
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
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
89 matches
Mail list logo
