> However, there is still a question which puzzles me a lot? Why gengtype is
> not a sort of filter or generator (like yacc is) taking a (list of) files on
> input and producing a file on output?
It used to take a list of files on its command line, but the list
was so long we were running into len
I want to have a GTY() garbage collected structure such that, when it
is destoyed, some specific routine is called (this should indeed be
possible, since GGC is a mark& sweep garbage collector, which delet
individually each dead data).
if_marked and deletable are not what you want; they are two
Back in 2000 I wrote a really simple patch that caused gcc to treat an
ASM_OPERANDS that clobbered "pc" as a control flow barrier, exactly
for this problem.
http://gcc.gnu.org/ml/gcc-patches/2000-01/msg00190.html
I still think it was a good idea, but at the time it was received
unenthusiasticall
Ian Lance Taylor writes:
Kazu Hirata <[EMAIL PROTECTED]> writes:
>
> I am aware of the define_constraints patch. I am thinking about
> working on the H8 and M68K ports at least. How urgent is this? FWIW,
> I've reproduced the ICE that Zack mentioned, but I haven't
> investigated it.
It's not
So I've just checked in a patch series which accomplishes about half
of what I was originally aiming to achieve with gengtype, and I'd like
to review what I think should still be done. My ultimate goal - not
just with gengtype - is to remove all hardwired kludges and
dependencies on target header
Gabriel Dos Reis wrote:
I don't understand your statement. The C++ (and the C) standard says
# If a source file that is not empty does not end in a new-line
# character, or ends in a new-line character immediately preceded by a
# backslash character, the behavior is undefined.
The GNU prepr
On 3/29/07, François-Xavier Coudert <[EMAIL PROTECTED]> wrote:
Works OK on the cross. So, it's probably a host problem in gengtype.
It appears to exist on HPUX as well, as Steve noted.
Yeah, it appears I was overly optimistic in hoping vsnprintf() would
do what C99 says it does. I do not have
[resend]
On 3/29/07, François-Xavier Coudert <[EMAIL PROTECTED]> wrote:
> I've attached a patch that should fix it (it
> just reverts the oprintf() changes, which were not really necessary, I
> was just trying to be more efficient).
Thanks, that fixes it for me on i386-pc-mingw32.
committed.
Martin Michlmayr wrote:
...
- The "no newline" and "xxx redfined" pedwarnings should be converted
into normal warnings. Rationale: no newline doesn't harm anyone and
there are quite a few programs that would fail because of an error
that many agree is too strict. Redefining something with
On 4/1/07, Martin Michlmayr <[EMAIL PROTECTED]> wrote:
* Zack Weinberg <[EMAIL PROTECTED]> [2007-04-01 08:30]:
> This therefore needs to stay a pedwarn at least for the case where the
> redefinition comes from a #define in the source. It's not clear to me
> whet
Ugh. That puts us in the position of having to decide whether command
line definitions "count" as previous definitions for 6.10.3p3.
6.10.3p*2*.
zw
On 4/1/07, Robert Dewar <[EMAIL PROTECTED]> wrote:
Zack Weinberg wrote:
It's not bending the language, the standard has nothing whatever to say
about -D. I see no reason not to be completely permissive wrt -D if it
is going to make transition smoother.
The thing is, the standard do
The target macros described in the "Addressing Modes" section of the
internals manual are rather badly in need of cleaning up. I see three
primary reasons why this is so:
1) These are the macros subject to REG_OK_STRICT. For those of you
who have managed so far to avoid finding out about thi
Bernd Schmidt <[EMAIL PROTECTED]> writes:
> Zack Weinberg wrote:
>> I have worked out a tentative plan for replacing most of these
>> macros with ordinary target hooks, and eliminating REG_OK_STRICT.
>
> Are you planning to keep the observed behaviour, or do you want
Kazu Hirata <[EMAIL PROTECTED]> writes:
> Hi Zack,
>
>> So, the plan: Step 1 introduces - one at a time - target hooks
>> corresponding to each of the above macros. All callers are changed to
>> use the hooks.
...
>> Step 2 is to convert each architecture, one at a time, to make
>> target-hook d
"Dave Korn" <[EMAIL PROTECTED]> writes:
> I'm basically in agreement with you here, and just want to suggest you can
> avoid an awful lot of code duplication by doing something like
>
> #ifdef REG_OK_STRICT
> #define ${CPU}_IS_STRICT 1
> #else
> #define ${CPU}_IS_STRICT 0
> #endif
This idiom i
Richard Sandiford <[EMAIL PROTECTED]> writes:
> Zack Weinberg <[EMAIL PROTECTED]> writes:
>> I have worked out a tentative plan for replacing most of these macros
>> with ordinary target hooks, and eliminating REG_OK_STRICT. I propose
>> t
I think I've addressed all the points you bring up in responses to
other people. If I missed something, please let me know?
zw
Kazu Hirata <[EMAIL PROTECTED]> writes:
> It turns out that the CALL_EXPR case of fold_ternary needs the
> original tree like so. (Notice a reference to t.)
...
> If we want to change fold_builtin to take operands like op0, op1, and
> op2, I would have to change so many things that depend on
> fo
There is no option that does what you want. This is a deliberate,
albeit controversial, design decision which we are not presently
interested in debating.
If you are writing a back end, consider using the existing, well-
understood machinery for porting GCC to a new architecture. If you go
that
I'd appreciate it if y'all would do the following sequence of commands
on your favorite machine:
srcdir=/path/to/gcc/source/tree/
$srcdir/configure
make all-libcpp configure-gcc
cd gcc
make config.h tm.h
time ../libcpp/makedepend -I. -I$srcdir/gcc -I$srcdir/libcpp/include \
-I$srcdir/include
DJ Delorie <[EMAIL PROTECTED]> writes:
>> and (c) whether or not you would be willing to trade that much
>> additional delay in an edit-compile-debug cycle for not having to
>> write dependencies manually anymore.
>
> Are there any compromise solutions?
Lots.
The program as it currently exists i
DJ Delorie <[EMAIL PROTECTED]> writes:
>> probably the sanest thing is to go with the automake-like approach of
>> one .d file per .c file, which then can be annotated without having to
>> write logic to parse a big dependency file and update it in place.
>
> The problem with .d files is that ther
DJ Delorie <[EMAIL PROTECTED]> writes:
>> That script doesn't really parse the file at all, it just scans for
>> #include lines, and it processes each header only once no matter how
>> many files reference it. Which has got to be faster than what
>> cpplib is doing.
>
> Right, I figured you could
Zack Weinberg <[EMAIL PROTECTED]> writes:
> It is from 2x to 7x faster, depending on whether the filesystem cache
> is primed. There doesn't seem to be any way to get it to read
> multiple include directories, so the results are not entirely
> accurate, but that's a
Tom Tromey <[EMAIL PROTECTED]> writes:
> Automake also doesn't do a separate "make depend" step. Dependencies
> are computed as a side effect of compilation.
I would take this approach if there were a sensible way to deal with
the generated sources.
> Computed headers are dealt with somewhat cl
Mark Mitchell <[EMAIL PROTECTED]> writes:
> Maybe cpplib could even be hacked to have a mode where (when
> generating dependencies) it silently permits #include of an
> non-existing file, considers it a dependency in the current
> directory, and just keeps going? I have insufficient cpplib taste
Alexandre Oliva <[EMAIL PROTECTED]> writes:
> On Mar 7, 2005, Zack Weinberg <[EMAIL PROTECTED]> wrote:
>
>> (c) whether or not you would be willing to trade that much
>> additional delay in an edit-compile-debug cycle for not having to
>> write dependenc
Nathan Sidwell <[EMAIL PROTECTED]> writes:
> Dave Korn wrote:
>
>> There was under varargs, which didn't require to pass a named
>> argument to va_start; it's only with stdargs that it would be
>> impossible. I suspect that this is the underlying reason for the
>> code having developed this way:
Mark Mitchell <[EMAIL PROTECTED]> writes:
> Zack Weinberg wrote:
>
>> It would certainly be nice to get rid of this mess, but Jim Wilson
>> expressed concerns last time it came up:
>> <http://gcc.gnu.org/ml/gcc-patches/2004-01/msg03213.html>
>
> Well, s
Ian Lance Taylor writes:
> I think this change is a great idea. I want to point out something
> you probably already noticed: some definitions of
> LEGITIMIZE_RELOAD_ADDRESS rely on the fact that they appear in
> reload.c in the only caller, find_reloads_address. For example, the
> definition i
The interface looks sound to me with one exception: it's not safe to
conflate !-pipe with -save-temps, because that opens up the
possibility of a tempfile race -- if an attacker sees that the
compiler is producing /tmp/ccQWERTY.s, then they should not be able to
predict that the assembler will pro
Ian Lance Taylor writes:
> If you do use PEX_SAVE_TEMPS, then the caller provides the base name
> and the suffix, and the caller is responsible for making good
> choices.
It doesn't look like the caller can specify a different base name for
each stage in the pipeline, is the thing.
zw
"Joseph S. Myers" <[EMAIL PROTECTED]> writes:
> Per Bothner <[EMAIL PROTECTED]> writes:
>> The general frustration is: where is dg-error documented?
>
> It ought to be in the dejagnu manual (i.e., that's where documentation
> should best be contributed) since dg-error is part of base dejagnu.
The
Ãyvind Harboe <[EMAIL PROTECTED]> writes:
> - Many backends do not support trampolines. Are trampolines
> something that is ultimately being added to the backends?
As and if the port maintainers care, I think.
> - Do (theoretical?) alternatives to trampolines exist?
> I.e. something that do
Dale Johannesen <[EMAIL PROTECTED]> writes:
> Consider the following:
>
> static inline int a() __attribute((always_inline));
> static inline int b() __attribute((always_inline));
>
> static inline int b() { a(); }
> static inline int a() { }
> int c() { b(); }
>
> This compiles fine at -O2. At -
Dale Johannesen <[EMAIL PROTECTED]> writes:
>>> It seems undesirable for -O options to affect which programs will
>>> compile.
>>
>> Agreed. Perhaps we should run the inliner at -O0 if we see
>> always_inline attributes, just for those functions?
>
> We do; the problem is that it makes only 1 pas
[EMAIL PROTECTED] writes:
> | > Do you demonstrate that "C++ is not LALR(1)"?
> |
> | I'll leave that to you as a homework assignment. Actually, C++ is not
> | LALR(N) for any N.
Nor is it LR(N) nor LL(N).
> | Get out the C++ grammar and figure it out, it's an easy proof.
> | Come back when y
I have checked in the patch to clean up after GCC's change to version
number handling. This should address all reported issues with build,
installation, etc. Per Ian's suggestion, I am doing a multilib-ful
build with a relative $(srcdir), which may expose more problems, which
will be addressed i
John Marshall <[EMAIL PROTECTED]> writes:
> Mike Stump wrote:
>> The canonical form can be found in gcc/libgcc2.c:
>>
>> [...] (The General Public License restrictions
>> do apply in other respects; for example, they cover modification of
>> the file, and distribution when not linked into a combin
I've merged the gcc_update --silent changes, and Andreas' quoting fix,
from mainline to the 3.4 and 4.0 branches.
zw
Ian Lance Taylor writes:
> 3) Write a new CC0 collapse pass. This pass is run immediately
> after RTL expansion. It walks the instruction stream looking for
> instructions which set and use CC_REG. At this point these
> instructions will always be adjacent. The pass combines them into
> the c
Ian Lance Taylor writes:
> Zack Weinberg <[EMAIL PROTECTED]> writes:
>> I'm not understanding why this is a separate pass, instead of
>> generating the combined instructions directly in the expander. I
>> think generic expander support for compare-and-branc
DJ Delorie <[EMAIL PROTECTED]> writes:
> I only want to avoid a situation where libiberty is left half
> converted (except short term, of course). The mechanics of the
> process are irrelevent to me.
I take it that all libiberty-using projects have taken the plunge,
then? You vetoed this conver
DJ Delorie <[EMAIL PROTECTED]> writes:
>> I take it that all libiberty-using projects have taken the plunge,
>> then? You vetoed this conversion awhile back because libiberty had
>> to be done last.
>
> At this point, I think libiberty *is* the last.
I'm glad to hear it. It'll be nice to be com
DJ Delorie <[EMAIL PROTECTED]> writes:
>> Less to maintain is all I was hoping for. I think the configure
>> scripts (both libiberty's and gcc's) could be simplified quite a bit
>> if we assumed a C89 compliant runtime library, as could libiberty.h
>> and system.h.
>
> Well, gcc can make assumpti
Andrew Pinski <[EMAIL PROTECTED]> writes:
>
> The code for these testcases submitted so far are about 12 lines a piece
> and have almost nothing which can tell where they came from (Other than
> comments in the code).
That's probably fine then. IIRC, previous discussion of this has
generally come
Tom Tromey <[EMAIL PROTECTED]> writes:
> David> Currently I have placed the factor out functions in a files named
> David> parse_factor.c (and .h). I feel this is a somewhat bad name,
> David> is there any rule for file naming in use at gcc.
>
> There is no rule I know of other than "whatever the
Aldy Hernandez <[EMAIL PROTECTED]> writes:
> I need options only for certain subtargets. For example, aix.h has
> some options that should not be available by other targets.
Take a look at how this is done for the ia64-hpux port.
zw
Dale Johannesen <[EMAIL PROTECTED]> writes:
> For mainline I assume we'll need "GCC" to the syntax; that local
> change is small compared to making it work though.)
If you're implementing a #pragma for compatibility with another
compiler, we don't require the "GCC" prefix.
zw
Robert Dewar <[EMAIL PROTECTED]> writes:
> But I doubt that projects to buy small linear gains in memory usage
> are mainstream very worthwhile in the long run (non-linear gains are
> *always* worth going after by contrast).
Last year CodeSourcery had a contract to speed up the C++ front end at
-
Robert Dewar <[EMAIL PROTECTED]> writes:
> Zack Weinberg wrote:
>> Last year CodeSourcery had a contract to speed up the C++ front end at
>> -O0, and we found that small linear reductions in memory usage
>> corresponded directly to small linear reductions in time usage,
> I as sorry I repeat my appeal, but if really nobody works on Sparc
> or PowerPC processors and nobody wants to send me 'specs' file from
> directory > " /usr/lib/gcc-lib/name_of_compiler/lib/version/specs "
> or similar ???
You probably don't need this file. If you do, you can get it for
yours
Eric Christopher <[EMAIL PROTECTED]> writes:
>> "This compiler at present doesn't cover all of Fortran 77. We assume
>> distributors to provide access to g77 as long as that's useful."
>
> Slightly corrected for grammar:
>
> "We assume that distributors will provide access to g77 as long until
>
Bernd Schmidt <[EMAIL PROTECTED]> writes:
> Zack Weinberg wrote:
>> The target macros described in the "Addressing Modes" section of the
>> internals manual are rather badly in need of cleaning up.
>
> What's your status on this - would you mind very mu
Dimitry Golubovsky <[EMAIL PROTECTED]> writes:
> Devang,
>
> Thanks for your relpy.
>
> This addresses only compiler's action problem (no output produced),
> but does not address the stdin problem.
>
> When I try
>
> % cat a.c | gcc -fsyntax-only -
>
> I get
>
> gcc: -E required when input is fro
"Dave Korn" <[EMAIL PROTECTED]> writes:
> Then the error message *really* ought to say
>
> gcc: -E or -x required when input is from standard input
>
> since it is thoroughly obtuse and non-explanatory as it stands. The
> attached is against 4.0 RC1, but I imagine it'll apply cleanly to HEAD wi
"Dave Korn" <[EMAIL PROTECTED]> writes:
> No write perms mate! However I'll check out HEAD and do a
> before-and-after testsuite run overnight, and get back to you in the morning
> with the results (UK time). Will "--enable-languages=c,c++" be enough, or
> do you want me to test against all de
Ian Lance Taylor writes:
> Peter Barada <[EMAIL PROTECTED]> writes:
>> I've got a "Using and Porting GNU CC" manual for rev 2.95, and am
>> looking around for a newer one and can't find it anywhere. Does
>> anyone know if a newer printed manual is available(and if so, where I
>> can find it)?
>
>
Branko Äibej <[EMAIL PROTECTED]> writes:
> Zack Weinberg wrote:
>
>> "This compiler does not support all of Fortran 77 yet. We recommend
>> distributors continue to provide packages of g77 from GCC 3.4 for
>> the time being. When gfortran is considered a
Richard Sandiford <[EMAIL PROTECTED]> writes:
> The only reliable way to get what you want is to either (a) add -G0
> multilibs or (b) change the default -G setting. Perhaps a configure
> option would be useful here. Maybe something like --with-sdata-limit,
> to go alongside options like --with-
Joe Buck <[EMAIL PROTECTED]> writes:
> GCC has the "suggest parentheses" warning elsewhere (to catch people
> writing "if (foo = 0)" and the like; maybe there should be a warning
> for this one as well.
I'd be happy to take a patch to add -Wparentheses support to
libcpp/expr.c.
zw
James E Wilson <[EMAIL PROTECTED]> writes:
>> unnecessary, and error prone (as evidenced by string literal memory
>> references not being properly identified as READONLY, although their
>> equivalent array representations are treated properly for example?)
>
> If true, that sounds like a bug
Mike Stump <[EMAIL PROTECTED]> writes:
> Not being able to build in the source directory is a bug.
> Having to set CONFIG_SHELL is a bug.
> Having to install a newer cctools is a bug.
Patches are welcome.
zw
Bruce Lilly <[EMAIL PROTECTED]> writes:
> Earlier versions of gcc retain static character strings in object
> files which can be used for identification via ident (RCS) or what
> (SCCS). Gcc 4.0.0 removes them above optimization level 1.
The first observation I'd like to make is that we (the GCC
Bruce Lilly <[EMAIL PROTECTED]> writes:
>> I don't see why you think the warnings are spurious. ~(AAA), for example,
>> is 4294967294,
>
> No, in this context it is 254 (an 8-bit unsigned field with the LSB clear).
C does not work the way you think. AAA has type unsigned int. The
expression ~
Matt Thomas <[EMAIL PROTECTED]> writes:
> libjava is built on everything but vax and mips. Bootstrapping core
> might be better but do the configure on the fly it's not as easy as
> it used to be.
--enable-languages=c,c++ (or even perhaps --enable-languages=c)
doesn't work for you?
Also, I beli
Wasn't TER a temporary kludge that should be going away?
zw
Vincent Lefevre <[EMAIL PROTECTED]> writes:
> On 2005-04-26 13:15:43 -0700, Zack Weinberg wrote:
>> The initializer thus tries to give a variable with type unsigned:8
>> a value that it cannot hold. The diagnostic is correct.
>
> However it is correct to store any inte
Daniel Berlin <[EMAIL PROTECTED]> writes:
> On Wed, 2005-04-27 at 15:13 -0700, Stan Shebs wrote:
>> Steven Bosscher wrote:
>> >If someone had cared about them, it would have been noticed
>> >earlier. But since _nobody_ has complained before you, I guess we
>> >can conclude that by far the majorit
Having seen Joe's comment, I should say that I agree with him that a
lot of other projects' mailing lists are worse. However, that isn't
an excuse in my book.
zw
Daniel Berlin <[EMAIL PROTECTED]> writes:
> On Wed, 2005-04-27 at 16:40 -0700, Zack Weinberg wrote:
>> I have seen such complaints. Not about bootstrap times, no, that only
>> affects people who compile the compiler; but the more general case of
>> 'gcc takes forev
Daniel Berlin <[EMAIL PROTECTED]> writes:
>> What you say is true. Does that mean we shouldn't try?
>
> Let me point out the important part again: All I ever see people
> suggest is magic bullets.
>
> We should try, but by doing the hard work. Not by expecting magic.
Sure. CodeSourcery did hav
Peter Barada <[EMAIL PROTECTED]> writes:
> What's really sad is that for cross-compilation of the toolchain, we
> have to repeat a few steps (build gcc twice, build glibc twice)
> because glibc and gcc assume that a near-complete environment is
> available(such as gcc needing headers, and glibc ne
Peter Barada <[EMAIL PROTECTED]> writes:
>>> What's really sad is that for cross-compilation of the toolchain, we
>>> have to repeat a few steps (build gcc twice, build glibc twice)
>>> because glibc and gcc assume that a near-complete environment is
>>> available(such as gcc needing headers, and
Andrew Pinski <[EMAIL PROTECTED]> writes:
> On Apr 28, 2005, at 3:08 PM, Laurielle Lea wrote:
>
>> Hello,
>>
>> I would like just to know if string class of libstdc++ support UTF8
>> and if not, is it possible to convert string to utf8 ?
>
> wstring supports wide strings via wchar_t. string suppo
Bernard Leak <[EMAIL PROTECTED]> writes:
> To submit the output of a gcc test run to the relevant mailing list,
> I'm enjoined to run an obfuscated script and pipe the output to sh.
> Fine - but then it tells me (actually, the docs said this already)
> that I need "the Mail program" in my path. N
[EMAIL PROTECTED] (Bob Proulx) writes:
> However if you are working in some port environment you may be
> trying to bootstrap these things along and may want/need gcc to get
> other components bootstrapped. You may not have a working system to
> begin with.
This is true, and we could improve the
Ralf Corsepius <[EMAIL PROTECTED]> writes:
> FWIW: IMO, NO_IMPLICIT_EXTERN_C actually is an OS/libc feature ("Your
> system headers are c++ aware"), therefore it is hardly possible or
> useful to ever use "#define NO_IMPLICIT_EXTERN_C" on "generic" targets
> (*-elf, *-coff etc.).
I'm going to ask
Ralf Corsepius <[EMAIL PROTECTED]> writes:
> On Sun, 2005-05-08 at 21:34 -0700, Zack Weinberg wrote:
>> Ralf Corsepius <[EMAIL PROTECTED]> writes:
>>
>> > FWIW: IMO, NO_IMPLICIT_EXTERN_C actually is an OS/libc feature ("Your
>> > system headers a
Georg Bauhaus <[EMAIL PROTECTED]> writes:
> Installing an MTA, whatever its size may be, has the potential
> of introducing more work, more open ports, more firewall building,
> more following the associated securitiy advisories absent a firewall
> or not absent a firewall, more ...
Not at all.
Bernard Leak <[EMAIL PROTECTED]> writes:
> My system has developed, for hysterical reasons, as a minimal
> installation of GNU/Linux on a P4. Minimal really was minimal - no
> networking, no X... Everything else has been added on demand. I
> managed to get my networking running with no problems w
Matthew Woodcraft <[EMAIL PROTECTED]> writes:
> There is at least one serious distribution which has considered having no
> /usr/sbin/sendmail (or mailx) in a default installation:
>
> http://lists.ubuntu.com/archives/ubuntu-devel/2005-February/004207.html
What a horrible idea. It's not just abo
Paul Schlie <[EMAIL PROTECTED]> writes:
>> From: Mark Mitchell <[EMAIL PROTECTED]>
>> static const int i = f();
>
> Admittedly didn't think that was legal, as I though all "static const"
> initializer values needed to be resolvable at compile time, directly or
> indirectly from literal values by th
Nicholas K Rivers <[EMAIL PROTECTED]> writes:
> Mike Stump wrote:
>>
>> In general, I am against bug migration. We want the testcase names
>> to be stable, for ever, to quote my favorite.., uhm, to quote sponge
>> bob.
>
> I see. Well maybe there's a better task I could do.
No, the instability
Daniel Berlin <[EMAIL PROTECTED]> writes:
> While my weekdays are booked with real stuff (structure aliasing,
> array_ref/mem_ref, dependence, blah blah blah), the next couple weekends
> i have plans to try to do some serious tree seperation.
>
> My current evil plan is to try to seperate the real
Per Bothner <[EMAIL PROTECTED]> writes:
...
> However, we end up with preprocessor output like this:
>
> # 1 "any-file"
> # 0 ""
> # 1 ""
> # 1 "any-file"
>
> Some assemblers complain about line number 0. This is especially
> an issue for people who use cpp to preprocessor assembler, which
> of c
Neil Booth <[EMAIL PROTECTED]> writes:
>> But that would break too much
>> code. Simplest and cleanest solution: Just get rid of the
>> line in pre-processor output. This might break some tools that look
>> at cpp output, but it seems unlikely.
>
> Agreed - we never guarantee the form of -E any
Bill Northcott <[EMAIL PROTECTED]> writes:
> On 21/05/2005, at 4:02 AM, Mike Stump wrote:
>>> I have now realised that it is not generated as part of the
>>> compiler build process.
>> It used to be.
>>> Presumably these files serve some purpose. How do they affect the
>>> operation of the compil
Daniel Berlin <[EMAIL PROTECTED]> writes:
> I've actually discovered that we set the assembler name on a field that
> is the vtable, but never actually use it again, at least for DWARF2 and
> STABS (it's set to a constant called VFIELD_NAME).
> I grepped .s file from all of libjava and the stl tes
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
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
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
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
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
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
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, 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
> &
1 - 100 of 179 matches
Mail list logo
