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
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
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
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
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:
> 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
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
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"
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
[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
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
> 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, 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
[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
> "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
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
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
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
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 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 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
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 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
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
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
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.
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
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
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,
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
"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 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.
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
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
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
> libstdcxx
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
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, 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
> 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: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
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 pa
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
|
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
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
> 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 TVQ_AUTHORIT
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
>(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
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
> 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 yo
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 am
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
> 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
> > 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
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
> 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
> 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
> 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
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
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
> 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
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
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
70 matches
Mail list logo
