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.
I'm out of the office tomorrow, and I don't want to leave things up in
the air.
I've looked at test results for a few 4.01 platforms on the testresults
lists:
powerpc64-unknown-linux-gnu : vec failures
x86_64-suse-linux-gnu: ieee failures, vect failures
s390-linux-gnu: OK
mips-sgi-irix6.5:
Zack Weinberg wrote:
(And I'd be less grumpy about coding to the intersection of C and C++
if someone coded up warnings for the C compiler to catch things
outside the intersection.)
My feeling on this is that it's not fair to expect people to know C++,
until and unless we switch to actually u
Mark Mitchell <[EMAIL PROTECTED]> writes:
...
> Like you, I do think these problems are surmountable; but, also like
> you, I think it would take some time to get all the problems solved.
> I don't really think, though, that this is immediately relevant;
> Gaby's trying to fix things that seem to m
Zack Weinberg wrote:
Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
[...]
The cast you're talking about is buried deep in XNEWVEC, XRESIZEVEC
and such. It is not anything you'll find in the code directly. So,
in fact we do not lose readability as you claim.
To be honest, I think XNEW* are l
Zack Weinberg wrote:
Mark Mitchell <[EMAIL PROTECTED]> writes:
[snip stuff addressed elsewhere]
I agree with the goal of more hiding.
You can do this in C by using an incomplete structure type in most
places, and then, in the files where you want the definition visible,
defining the structure
Mark Mitchell <[EMAIL PROTECTED]> writes:
[snip stuff addressed elsewhere]
> I agree with the goal of more hiding.
>
> You can do this in C by using an incomplete structure type in most
> places, and then, in the files where you want the definition visible,
> defining the structure to have a singl
Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
[...]
> The cast you're talking about is buried deep in XNEWVEC, XRESIZEVEC
> and such. It is not anything you'll find in the code directly. So,
> in fact we do not lose readability as you claim.
To be honest, I think XNEW* are less readable than bar
Zack Weinberg wrote:
Um, yeah. I completely botched that explanation. My apologies. I'm
concerned about four different scenarios which may arise when the
preexisting C++ compiler and runtime are ABI-incompatible with the C++
compiler and runtime being built; none are source compatibility
issu
Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
> On Mon, May 23, 2005 at 09:01:20PM -0700, Zack Weinberg wrote:
>> Furthermore, as I've said before, I support migrating
>> to C++ -- but only if the C++ ABI and libstdc++ soname are first
>> permanently frozen. If we do not do that first, we risk be
Zack Weinberg wrote:
On Mon, 2005-05-23 at 01:15 -0500, Gabriel Dos Reis wrote:
Hi,
I spent the week-end trying to get GCC -- mainline -- compilable
(i.e. those compoenents written in C) with a C++ compiler (e.g. g++).
These results are very interesting.
As a general observation: A lot of
Andrew Pinski <[EMAIL PROTECTED]> writes:
| On May 24, 2005, at 12:01 AM, Zack Weinberg wrote:
| > Use of bare 'inline' is just plain wrong in our source code; this has
| > nothing to do with C++, no two C compilers implement bare 'inline'
| > alike. Patches to add 'static' to such functions (AND
Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
| On Mon, May 23, 2005 at 09:01:20PM -0700, Zack Weinberg wrote:
| > As a general observation: A lot of the things you have found to be
| > problematic, are in fact preferred idioms for C code. For instance,
| > no standard-C programmer would ever wri
Zack Weinberg <[EMAIL PROTECTED]> writes:
| On Mon, 2005-05-23 at 01:15 -0500, Gabriel Dos Reis wrote:
| > Hi,
| >
| > I spent the week-end trying to get GCC -- mainline -- compilable
| > (i.e. those compoenents written in C) with a C++ compiler (e.g. g++).
|
| These results are very interesti
On May 24, 2005, at 12:01 AM, Zack Weinberg wrote:
Use of bare 'inline' is just plain wrong in our source code; this has
nothing to do with C++, no two C compilers implement bare 'inline'
alike. Patches to add 'static' to such functions (AND MAKING NO OTHER
CHANGES) are preapproved, post-slush.
On Mon, May 23, 2005 at 09:01:20PM -0700, Zack Weinberg wrote:
> As a general observation: A lot of the things you have found to be
> problematic, are in fact preferred idioms for C code. For instance,
> no standard-C programmer would ever write an explicit cast on malloc's
> return value. I thin
On Mon, 2005-05-23 at 01:15 -0500, Gabriel Dos Reis wrote:
> Hi,
>
> I spent the week-end trying to get GCC -- mainline -- compilable
> (i.e. those compoenents written in C) with a C++ compiler (e.g. g++).
These results are very interesting.
As a general observation: A lot of the things you ha
Ron Hudson wrote:
Hi,
I am teaching myself C by writing programs. I have some questions about
proper practices...
Ask in news:comp.lang.c
On Tue, 24 May 2005, Gabriel Dos Reis wrote:
> I can also report that I got the GNU C++ compiler through -- and apart
> form uses of C++ keywords (template, namespace, class), it worked
> out. A note on type sfety issue though: lookup_name() is declared in
> c-tree.h as
>
> extern tree loo
Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
[...]
| Attempt to get the GNU C++ compiler through the same massage is
| underway (but I'm going to bed shortly ;-)).
I can also report that I got the GNU C++ compiler through -- and apart
form uses of C++ keywords (template, namespace, class), it wo
On May 23, 2005, at 3:58 PM, Ron Hudson wrote:
I am teaching myself C by writing programs.
I'm sorry, this is the wrong list for such questions.
Hi,
I am teaching myself C by writing programs. I have some questions about
proper practices..
1) How do I know when to break my program into separate files. I am
currently working on a Star Trek program. It has 4 or 5 large
functions. They are all in one file. It's only about 900 lines rig
Gerald Pfeifer wrote:
That said, like after the 4.0.0, I managed to find a way to simplify
the list of steps you'll have to perform in the future. I just hope
you don't get too used to these simplifications, they are getting harder
to find. ;-)
I appreciate your help -- in this case and othe
On Mon, 2005-05-23 at 19:35 +0200, Steven Bosscher wrote:
> On Monday 23 May 2005 18:20, Jeffrey A Law wrote:
> > I'd much rather take the time to fix all these problems, install the
> > fixes along with the checking bits to ensure they never come back
> > rather than to iterate on each one separat
Daniel Berlin wrote:
On Mon, 2005-05-23 at 12:26 -0700, Mark Mitchell wrote:
Daniel Berlin wrote:
While moving FIELD_DECL to it's own substruct, the following questions
have come up. I figured one of you might know:
1. Do we need DECL_ASSEMBLER_NAME on FIELD_DECL? I can't think of a
place
On Mon, 23 May 2005, Mike Stump wrote:
On May 23, 2005, at 12:01 PM, Mark Mitchell wrote:
We've researched this in detail.
As have I, I also have the timings for template heavy code with the more
egregious of the bugs fixed in the compiler-server branch, at that time, they
were worth a 10x
On Mon, 2005-05-23 at 12:26 -0700, Mark Mitchell wrote:
> Daniel Berlin wrote:
> > While moving FIELD_DECL to it's own substruct, the following questions
> > have come up. I figured one of you might know:
> >
> > 1. Do we need DECL_ASSEMBLER_NAME on FIELD_DECL? I can't think of a
> > place where
On May 23, 2005, at 12:01 PM, Mark Mitchell wrote:
We've researched this in detail.
As have I, I also have the timings for template heavy code with the
more egregious of the bugs fixed in the compiler-server branch, at
that time, they were worth a 10x compile time improvement. If
someone
> | > dfs = (bitmap *) xmalloc (last_basic_block * sizeof (bitmap *));
> | >
It would be nice if gcc gave a warning for suspicious cases like this.
I did a crude warning for this, and ironically it found a bug in valgrind:
http://w
Daniel Berlin wrote:
While moving FIELD_DECL to it's own substruct, the following questions
have come up. I figured one of you might know:
1. Do we need DECL_ASSEMBLER_NAME on FIELD_DECL? I can't think of a
place where we would actually try to *output* a FIELD_DECL directly, but
maybe i've mis
Mark Mitchell wrote:
> It's certainly well-known here -- but that's not to say it shouldn't
> go in some nice FSF-ish place as well in case somebody else wants to
> work on it.
Probably it's obvious but indeed, we already noticed that this is also
*the* bottleneck for the compile-time performance
Karel Gardas wrote:
On Mon, 23 May 2005, Mark Mitchell wrote:
Mike Stump wrote:
On May 17, 2005, at 3:16 PM, Karel Gardas wrote:
1) the most expensive seems to be comptypes -- at least from data L2
refill point of view (~17%)
2) comptypes is also the most CPU intensive operation since t
On Mon, 23 May 2005, Mark Mitchell wrote:
Mike Stump wrote:
On May 17, 2005, at 3:16 PM, Karel Gardas wrote:
1) the most expensive seems to be comptypes -- at least from data L2
refill point of view (~17%)
2) comptypes is also the most CPU intensive operation since the most
of time is
Mike Stump wrote:
On May 17, 2005, at 3:16 PM, Karel Gardas wrote:
1) the most expensive seems to be comptypes -- at least from data L2
refill point of view (~17%)
2) comptypes is also the most CPU intensive operation since the most
of time is spent there
I think comptypes can be sped
Jeffrey A Law wrote:
On Mon, 2005-05-23 at 11:04 -0700, Mark Mitchell wrote:
Jeffrey A Law wrote:
much rather bite the bullet and get them fixed now. The fact that it's
affecting a lot of people keep the coals hot on my feet :-)
Jeff --
I know you're doing everything you can to fix the pr
On Mon, 2005-05-23 at 11:04 -0700, Mark Mitchell wrote:
> Jeffrey A Law wrote:
> > much rather bite the bullet and get them fixed now. The fact that it's
> > affecting a lot of people keep the coals hot on my feet :-)
>
> Jeff --
>
> I know you're doing everything you can to fix the problems. D
Jeffrey A Law wrote:
much rather bite the bullet and get them fixed now. The fact that it's
affecting a lot of people keep the coals hot on my feet :-)
Jeff --
I know you're doing everything you can to fix the problems. Do you have
an ETA for a solution? Probably if it's on the order of a
On Monday 23 May 2005 18:20, Jeffrey A Law wrote:
> I'd much rather take the time to fix all these problems, install the
> fixes along with the checking bits to ensure they never come back
> rather than to iterate on each one separately.
And int the mean time, things stay broken?
Gr.
Steven
> "Ranjit" == Ranjit Mathew <[EMAIL PROTECTED]> writes:
>> (4) .
Ranjit> Tom Tromey's GCJX (gcjx_branch in CVS), the completely
Ranjit> rewritten Java front-end that is written in C++.
Plugging this into gcc has largely been fine, thanks to an earlier
round of patches in this area.
The bigg
Kai Rottu wrote:
On windows, it is possible to build a binary using a compiler on Windows XP
that can then run on older versions of windows simply by not using any features
specific to the newest versions of windows XP (or by using LoadLibrary and
GetProcAddress to see if those features are avai
On Mon, 2005-05-23 at 17:25 +0100, Richard Earnshaw wrote:
> On Mon, 2005-05-23 at 17:20, Jeffrey A Law wrote:
> > On Mon, 2005-05-23 at 16:34 +0100, Richard Earnshaw wrote:
> > > On Mon, 2005-05-23 at 16:19, Eric Christopher wrote:
> > > > > > http://gcc.gnu.org/wiki/GCC%204.1%20Slush
> > > > >
On Mon, 2005-05-23 at 12:19 -0400, Daniel Berlin wrote:
> >
>
> Originally, this is one of the reasons the patch was not committed:
> There were places in fortran that weren't clean, etc, and i just didn't
> have time to go hunting (which is why i posted it to gcc patches, and
> left it out there
Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
| Hi,
|
| I spent the week-end trying to get GCC -- mainline -- compilable
| (i.e. those compoenents written in C) with a C++ compiler (e.g. g++).
|
| My summary is: It is largely doable and it is within our reach at this
| point of development. M
On Mon, 2005-05-23 at 17:20, Jeffrey A Law wrote:
> On Mon, 2005-05-23 at 16:34 +0100, Richard Earnshaw wrote:
> > On Mon, 2005-05-23 at 16:19, Eric Christopher wrote:
> > > > > http://gcc.gnu.org/wiki/GCC%204.1%20Slush
> > > >
> > > > Just to let folks know that mips-elf fails to build newlib.
On Mon, 2005-05-23 at 16:34 +0100, Richard Earnshaw wrote:
> On Mon, 2005-05-23 at 16:19, Eric Christopher wrote:
> > > > http://gcc.gnu.org/wiki/GCC%204.1%20Slush
> > >
> > > Just to let folks know that mips-elf fails to build newlib.
> > > There's a segfault in is_gimple_reg_type(), which is b
On Mon, 2005-05-23 at 10:00 -0600, Jeffrey A Law wrote:
> On Mon, 2005-05-23 at 11:42 -0400, Eric Christopher wrote:
> > > Eric (and anyone else who wasn't aware): there's been a lot of
> > > discussion about this on gcc-patches since I posted that message:
> > >
> > > http://gcc.gnu.org/ml/gc
On Mon, 2005-05-23 at 11:42 -0400, Eric Christopher wrote:
> > Eric (and anyone else who wasn't aware): there's been a lot of
> > discussion about this on gcc-patches since I posted that message:
> >
> > http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02029.html
> >
> > It's also PR21638:
> >
>
> Eric (and anyone else who wasn't aware): there's been a lot of
> discussion about this on gcc-patches since I posted that message:
>
> http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02029.html
>
> It's also PR21638:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21638
>
> It looks lik
Eric Christopher <[EMAIL PROTECTED]> writes:
>> > http://gcc.gnu.org/wiki/GCC%204.1%20Slush
>>
>> Just to let folks know that mips-elf fails to build newlib.
>> There's a segfault in is_gimple_reg_type(), which is being
>> passed a null type. I'm not sure if I'll have time to look
>> at it toni
On Mon, 2005-05-23 at 16:19, Eric Christopher wrote:
> > > http://gcc.gnu.org/wiki/GCC%204.1%20Slush
> >
> > Just to let folks know that mips-elf fails to build newlib.
> > There's a segfault in is_gimple_reg_type(), which is being
> > passed a null type. I'm not sure if I'll have time to look
> > http://gcc.gnu.org/wiki/GCC%204.1%20Slush
>
> Just to let folks know that mips-elf fails to build newlib.
> There's a segfault in is_gimple_reg_type(), which is being
> passed a null type. I'm not sure if I'll have time to look
> at it tonight.
I took a look and it seemed to work for me,
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.
Among the subjects covered
On Mon, May 23, 2005 at 10:28:05AM +0200, Uros Bizjak wrote:
> This change is needed to get i387 status word switching instructions in
> (int)->(float) conversions out of the loops, i.e.:
>
> int i;
> double d;
>
> for (x = 0... {
>i[x] = d[x];
> }
I think it would also be very useful to hav
Erik Poupaert wrote:
> If someone knows of an interesting discussion place where people can
> verify each other's results, please let me know.
Try the following:
http://groups-beta.google.com/group/algogeeks
--
Marcel Cox
Hi
In order to avoid being off-topic, does anybody know any mailing list
where people discuss just algorithms specifically? It doesn't need to
be compiler construction-specific -- even though they're amongst the
most interesting algorithms around.
I've recently devised an algorithm to produce use
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,bx,si,di,bp,sp,st,st1,st2,st3,st4,st5,st6,st7*/ \
{ 0, 0, 0, 0, 0, 0, 0, 1
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,bx,si,di,bp,sp,st,st1,st2,st3,st4,st5,st6,st7*/ \
{ 0, 0, 0, 0, 0, 0, 0, 1
Jeffrey A Law <[EMAIL PROTECTED]> wrote on 09/05/2005 18:17:45:
> Yes, it looks quite reasonable. Please go ahead with the full testing
> cycle and consider the patch pre-approved once complete.
>
I have changed the patch according to some feedbacks that I have got -- the
main idea didn't ch
Jonathan Wilson kirjoitti:
> Neither does Linux - by linking against a recent library you are
> *asking* for a binary that requires that library. If you understand
> that you might understand why everyone is saying you should build on
the
> lowest common denominator of the systems you're targ
59 matches
Mail list logo
