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
Snapshot gcc-3.4-20050524 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/3.4-20050524/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 3.4 CVS branch
with the following options: -rgcc-ss-3_4-20050524
You'll
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~
"Joseph S. Myers" <[EMAIL PROTECTED]> writes:
> On Sun, 6 Mar 2005, Ian Lance Taylor wrote:
>
> > look at the ChangeLog for the appropriate year. This is also how some
> > other GNU programs organize their ChangeLog files, including libhava
> > and libstdc++-v3.
>
> Not consistently, however.
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,
Richard Earnshaw wrote:
It's probably too late to do anything about this one this time around,
but isn't this why we have branches? The whole point of having branch
developments is so that potentially destabilizing chanes (such as
adding/changing major interfaces) can be done without causing th
Greetings! GCL is a lisp system that compiles to native object code
via the intermediary of gcc. It uses a conservative garbage
collection algorithm, which means that it walks the C stack to find
likely objects in use by automatic variables, and holds on to these.
This works quite well in practic
Daniel Kegel wrote:
> Any news on when profile-based inlining will be merged?
Very soon, I would guess:
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02304.html
Paolo.
Any news on when profile-based inlining will be merged?
http://gcc.gnu.org/ml/gcc/2005-05/msg00224.html and
http://gcc.gnu.org/wiki/CFG%20Transparent%20Inlining,%20Profile-Guided%20Inlining
have all the official news, but they just say it's not in yet.
I have an app that might benefit from this
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
On Mon, 2005-05-23 at 11:43 -0700, Mark Mitchell wrote:
> Fair enough. Would you mind reporting back later today, then? One
> possibility is to do the changes that fix our primary languages (C, C++,
> and Java, since it's easy) and deal with Fortran later. If we can get
> the mainline bootst
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
On Mon, May 23, 2005 at 10:25:26AM +0200, Uros Bizjak wrote:
> Hello!
>
> It looks that i387 control word register definition is missing from register
> definitions for i386 processor. Inside i386.h, we have:
>
> #define FIXED_REGISTERS \
> /*ax,dx,cx
> 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
On Mon, 2005-05-23 at 17:36, Jeffrey A Law wrote:
> On Mon, 2005-05-23 at 17:25 +0100, Richard Earnshaw wrote:
> > However, in the mean-time I'm stuck. I can't build my world anymore, so
> > I can't test the compiler
> I understand. But realize that I'm trying to ultimately save you time
> i
[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
Hello!
> I'm writing an extensive article about floating-point programming on
> Linux, including a focus on GCC's compilers. This is an outgrowth of
> many debates about topics like -ffast-math and -mfpmath=sse|387, and I
> hope it will prove enlightening for myself and others.
I would like to
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
70 matches
Mail list logo
