On Mon, May 16, 2005 at 05:26:36PM -0700, Mark Mitchell wrote:
> 2005-05-16 Mark Mitchell <[EMAIL PROTECTED]>
>
> * gcc.dg/compat/generate-random.c (config.h): Do not include.
> (limits.h): Include unconditionally.
> (stdlib.h): Likewise.
> * gcc.dg/compat/generate-random
On Tue, 2005-05-17 at 03:31 +0200, Steven Bosscher wrote:
> On Tuesday 17 May 2005 03:16, Joe Buck wrote:
> > On Tue, May 17, 2005 at 03:11:03AM +0200, Steven Bosscher wrote:
> > > On Tuesday 17 May 2005 02:59, Steven Bosscher wrote:
> > > > Oh, and how helpful of you to post that patch to gcc-patc
On Tue, 2005-05-17 at 01:59, Steven Bosscher wrote:
> No, I just don't build gfortran as a cross. There are many reasons
> why this is a bad idea anyway.
Such as?
On Tue, May 17, 2005 at 11:14:22AM +0200, Ralf Corsepius wrote:
> * I wasn't aware about this fortran specific patch posting policy. I
> never have sent any gcc patch to any other list but gcc-patches for
> approval before, so I also had not done so this time.
>
> * How could I know that the resp
On Tue, 17 May 2005, Ralf Corsepius wrote:
This kind of tone will only discourage contributors.
My tone was no different than Ralf's toward me.
Well, I admit I had been sarcastic/fatalistic in replying to Steven,
primarily, because I am pretty much frustrated about GCC's mainstream
developer's posi
Bravó ! Kiutaltunk Neked egy két fő részére, 14 ingyenes éjszakára
szóló Eurorest hotelcsekket.
Ha korábban nem vettél részt az akcióinkban, akkor biztosan nem
hitted eddig, hogy 1 üzenetért, amit az ismerőseidnek küldtél, egy olyan
hotelcsekk tulajdonosa lehetsz, amely 2 személy részére 14 ingy
On May 17, 2005 11:29 AM, Richard Earnshaw <[EMAIL PROTECTED]> wrote:
> On Tue, 2005-05-17 at 01:59, Steven Bosscher wrote:
>
> > No, I just don't build gfortran as a cross. There are many reasons
> > why this is a bad idea anyway.
>
> Such as?
For one thing, libgfortran requires c99 support,
On Tue, 2005-05-17 at 11:16, Steven Bosscher wrote:
> On May 17, 2005 11:29 AM, Richard Earnshaw <[EMAIL PROTECTED]> wrote:
>
> > On Tue, 2005-05-17 at 01:59, Steven Bosscher wrote:
> >
> > > No, I just don't build gfortran as a cross. There are many reasons
> > > why this is a bad idea anyway.
On Tue, 2005-05-17 at 12:16 +0200, Steven Bosscher wrote:
> On May 17, 2005 11:29 AM, Richard Earnshaw <[EMAIL PROTECTED]> wrote:
>
> > On Tue, 2005-05-17 at 01:59, Steven Bosscher wrote:
> >
> > > No, I just don't build gfortran as a cross. There are many reasons
> > > why this is a bad idea an
> For one thing, libgfortran requires c99 support, which is not in
> newlib iiuc.
In practice, no, it doesn't. F95 works fine on Solaris 2.5.1, which is the
typical non-C99 native platform.
--
Eric Botcazou
Alexandre Oliva wrote:
On May 16, 2005, Georg Bauhaus <[EMAIL PROTECTED]> wrote:
- cd ada/doctools && gnatmake -q xgnatugn
+ cd ada/doctools && gnatmake -q --GCC=$(CC) xgnatugn -largs --GCC=$(CC)
Don't you need quotes around $(CC),
Yes, there should be quotes.
(Without them the change
On May 17, 2005 12:21 PM, Ralf Corsepius <[EMAIL PROTECTED]> wrote:
> On Tue, 2005-05-17 at 12:16 +0200, Steven Bosscher wrote:
> > On May 17, 2005 11:29 AM, Richard Earnshaw <[EMAIL PROTECTED]> wrote:
> >
> > > On Tue, 2005-05-17 at 01:59, Steven Bosscher wrote:
> > >
> > > > No, I just don't b
On Tue, 2005-05-17 at 12:52 +0200, Steven Bosscher wrote:
> On May 17, 2005 12:21 PM, Ralf Corsepius <[EMAIL PROTECTED]> wrote:
>
> > On Tue, 2005-05-17 at 12:16 +0200, Steven Bosscher wrote:
> > > On May 17, 2005 11:29 AM, Richard Earnshaw <[EMAIL PROTECTED]> wrote:
> > >
> > > > On Tue, 2005-05
Hi!
Bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21364
shows that it is very dangerous to not check format strings
in translations. No translation of a particular message is always
better than a bad translation that causes compiler crash.
Now, looking at gettext, it seems to support GCC inter
Mark Mitchell wrote:
struct A {...};
struct B { ...; struct A a; ...; };
void f() {
B b;
g(&b.a);
}
does the compiler have to assume that "g" may access the parts of "b"
outside of "a". If the compiler can see the body of "g" than it may be
able to figure out that it can't access
On 5/17/05, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Ian Lance Taylor wrote:
>
> >>1. Remove the use of config.h and HAVE_*_H.
> >>
> >>2. Modify the generator not to depend on libiberty headers, including
> >>hashtab.h, by substituting a simple dictonary object.
> >>
> >>3. Adjust struct-layout
Richard Guenther <[EMAIL PROTECTED]> writes:
> /net/alwazn/home/rguenth/src/gcc/cvs/gcc-4.1/gcc/testsuite/gcc.dg/compat/generate-random.c:55:23:
> libiberty.h: No such file or directory^M
> /net/alwazn/home/rguenth/src/gcc/cvs/gcc-4.1/gcc/testsuite/gcc.dg/compat/generate-random_r.c:56:23:
> libibe
Ian Lance Taylor writes:
> Richard Guenther <[EMAIL PROTECTED]> writes:
>
>> Note how
>> 1. it uses $(CC) for building, not the built compiler
>
> That is correct, as this program is run on the build system to
> generate test cases.
Shouldn't it use CC_FOR_BUILD then?
Andreas.
--
Andreas Sc
On Tue, 17 May 2005, Jakub Jelinek wrote:
> Bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21364
> shows that it is very dangerous to not check format strings
> in translations. No translation of a particular message is always
> better than a bad translation that causes compiler crash.
>
> Now,
Andreas Schwab <[EMAIL PROTECTED]> writes:
> Ian Lance Taylor writes:
>
> > Richard Guenther <[EMAIL PROTECTED]> writes:
> >
> >> Note how
> >> 1. it uses $(CC) for building, not the built compiler
> >
> > That is correct, as this program is run on the build system to
> > generate test cases.
On 17 May 2005 08:59:07 -0400, Ian Lance Taylor wrote:
> Richard Guenther <[EMAIL PROTECTED]> writes:
>
> > /net/alwazn/home/rguenth/src/gcc/cvs/gcc-4.1/gcc/testsuite/gcc.dg/compat/generate-random.c:55:23:
> > libiberty.h: No such file or directory^M
> > /net/alwazn/home/rguenth/src/gcc/cvs/gcc-4
Richard Guenther <[EMAIL PROTECTED]> writes:
> It works after removing the libiberty includes from generate-random.c
> and generate-random_r.c
Personally I think this change comes under the "obvious" rule, given
Mark's change yesterday to not link against libiberty.
Ian
This is really getting pretty far from the original topic but
I am diving in anyway.
Steven Bosscher wrote:
On Tuesday 17 May 2005 02:53, Ralf Corsepius wrote:
On Tue, 2005-05-17 at 00:10 +0200, Steven Bosscher wrote:
On Monday 16 May 2005 23:43, Ralf Corsepius wrote:
On Mon, 2005-05-16 at 10:42 -0
On 17 May 2005 10:05:58 -0400, Ian Lance Taylor wrote:
> Richard Guenther <[EMAIL PROTECTED]> writes:
>
> > It works after removing the libiberty includes from generate-random.c
> > and generate-random_r.c
>
> Personally I think this change comes under the "obvious" rule, given
> Mark's change y
On Mon, May 16, 2005 at 05:41:03PM -0700, Mark Mitchell wrote:
> I've very nearly ready to release GCC 3.4.4. If you have objections or
> high-priority fixes that you think will be required for this release,
> please speak up within the next 24 hours.
Sorry for the last minute mail ...
It occ
Richard Guenther wrote:
Personally I think this change comes under the "obvious" rule, given
Mark's change yesterday to not link against libiberty.
Done.
Yes, this is an obvious patch; thank you. I did not notice this problem
because my machine does have a libiberty.h installed. Would you plea
I'm upgrading to V4.0.0 and struggling with some code that's seriously
into templates. One puzzling error is this one:
keyed_obj.hh:159: error: no matching function for call to
'CxnIndex::CxnIndex(CxnIndex)'
Indeces.hh:150: note: candidates are: CxnIndex::CxnIndex(CxnIndex&)
Indeces.hh:145: note
Jonathan Wakely wrote:
On Tue, May 17, 2005 at 11:14:22AM +0200, Ralf Corsepius wrote:
* I wasn't aware about this fortran specific patch posting policy. I
never have sent any gcc patch to any other list but gcc-patches for
approval before, so I also had not done so this time.
* How could I know t
On Tue, May 17, 2005 at 12:00:59PM -0400, Paul Koning wrote:
> I'm upgrading to V4.0.0 and struggling with some code that's seriously
> into templates. One puzzling error is this one:
>
> keyed_obj.hh:159: error: no matching function for call to
> 'CxnIndex::CxnIndex(CxnIndex)'
> Indeces.hh:150:
On Tue, May 17, 2005 at 11:05:07AM -0500, Joel Sherrill <[EMAIL PROTECTED]>
wrote:
> Jonathan Wakely wrote:
> >On Tue, May 17, 2005 at 11:14:22AM +0200, Ralf Corsepius wrote:
> >
> >
> >>* I wasn't aware about this fortran specific patch posting policy. I
> >>never have sent any gcc patch to any
On 5/17/05, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Richard Guenther wrote:
>
> >>Personally I think this change comes under the "obvious" rule, given
> >>Mark's change yesterday to not link against libiberty.
> >
> > Done.
>
> Yes, this is an obvious patch; thank you. I did not notice this p
On Tue, May 17, 2005 at 09:12:38AM -0700, Joe Buck wrote:
> On Tue, May 17, 2005 at 12:00:59PM -0400, Paul Koning wrote:
> > I'm upgrading to V4.0.0 and struggling with some code that's seriously
> > into templates. One puzzling error is this one:
> >
> > keyed_obj.hh:159: error: no matching fun
On Tue, May 17, 2005 at 11:14:22AM +0200, Ralf Corsepius wrote:
> On Tue, 2005-05-17 at 03:31 +0200, Steven Bosscher wrote:
> > On Tuesday 17 May 2005 03:16, Joe Buck wrote:
> > > On Tue, May 17, 2005 at 03:11:03AM +0200, Steven Bosscher wrote:
> > > > On Tuesday 17 May 2005 02:59, Steven Bosscher
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 really distinct _DECL
nodes into distinct DECL trees, sh
Joe Buck wrote:
I used to be an embedded programmer myself, and while I cared very much
about the size and speed of the embedded code I wound up with, I didn't
care at all about being able to run the compiler itself on a machine that
wasn't reasonably up to date, much less trying to bootstrap the c
On Tue, 17 May 2005, Joel Sherrill <[EMAIL PROTECTED]> wrote:
> > For future reference, where patches should be sent is explained here:
> > http://gcc.gnu.org/lists.html
>
> OK .. and Bugzilla or http://gcc.gnu.org/bugs.html references that link how?
>
> A search for "patch" in the bug reporting
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
On May 17, 2005, Karel Gardas <[EMAIL PROTECTED]> wrote:
> you see that 4.0 added "embedded" platforms like arm-none-elf and
> mips-none-elf to the primary platforms list.
These are only embedded targets. You can't run GCC natively on them,
so they don't help embedded hosts in any way.
--
Alex
On Tue, May 17, 2005 at 01:08:29PM -0400, Daniel Berlin wrote:
> This is probably going to hurt, and will require things like using
> FIELD_DECL_ macros for FIELD_DECL's, TYPE_DECL_ macros for
> TYPE_DECL's, etc, instead of using DECL_ on both for some fields.
Can you be more specific on which fie
On Tue, 17 May 2005, Joel Sherrill <[EMAIL PROTECTED]> wrote:
> One thing that has been on my personal wish list a LONG time is
> to get RTEMS configurations to properly run the GCC test suite. [I normally
> test and report against *-elf since they are similar and easier.] Many tests
> fail or c
On Tue, 2005-05-17 at 10:46 -0700, Richard Henderson wrote:
> On Tue, May 17, 2005 at 01:08:29PM -0400, Daniel Berlin wrote:
> > This is probably going to hurt, and will require things like using
> > FIELD_DECL_ macros for FIELD_DECL's, TYPE_DECL_ macros for
> > TYPE_DECL's, etc, instead of using D
On Tue, 17 May 2005, Alexandre Oliva wrote:
On May 17, 2005, Karel Gardas <[EMAIL PROTECTED]> wrote:
you see that 4.0 added "embedded" platforms like arm-none-elf and
mips-none-elf to the primary platforms list.
These are only embedded targets. You can't run GCC natively on them,
so they don't hel
Jakub Jelinek wrote:
+ #ifndef WORDS_BIGENDIAN
+ /* On a little-endian machine, if the data is 4-byte aligned we can hash
+ by word for better speed. This gives nondeterministic results on
+ big-endian machines. */
WORDS_BIGENDIAN is not being defined in the headers that are included
John David Anglin wrote:
Please download, build, and test.
I've now completed testing on the PA and don't see any major issues.
The only easily fixable issue that showed up in testing was the failure
of 26_numerics/complex/pow.cc under hpux 10.20. This fails because of
a corner case in the 10.20
The main case i've hit so far is DECL_CONTEXT, which is also
DECL_FIELD_CONTEXT
Are there any other cases? Offhand, I can't think of another DECL field
that's shared by only a subset of DECLs.
On Tue, May 17, 2005 at 02:10:48PM -0400, Daniel Berlin wrote:
> The main case i've hit so far is DECL_CONTEXT, which is also
> DECL_FIELD_CONTEXT, and my current thinking is that in a FIELD_DECL will
> be only accessible through DECL_FIELD_CONTEXT (unless we want to
> "re-merge" these two fields a
Ralf Corsepius <[EMAIL PROTECTED]> writes:
[...]
| Well, I admit I had been sarcastic/fatalistic in replying to Steven,
| primarily, because I am pretty much frustrated about GCC's mainstream
| developer's position/attitude on embedded targets.
| Steven's answers perfectly queue-in into a long hi
On Tue, 2005-05-17 at 14:59 -0400, Richard Kenner wrote:
> The main case i've hit so far is DECL_CONTEXT, which is also
> DECL_FIELD_CONTEXT
>
> Are there any other cases? Offhand, I can't think of another DECL field
> that's shared by only a subset of DECLs.
An example is DECL_INITIAL vs
Joe Buck <[EMAIL PROTECTED]> writes:
| On Tue, May 17, 2005 at 12:00:59PM -0400, Paul Koning wrote:
| > I'm upgrading to V4.0.0 and struggling with some code that's seriously
| > into templates. One puzzling error is this one:
| >
| > keyed_obj.hh:159: error: no matching function for call to
'C
On 2005-05-17, at 11:14, Ralf Corsepius wrote:
On Tue, 2005-05-17 at 03:31 +0200, Steven Bosscher wrote:
On Tuesday 17 May 2005 03:16, Joe Buck wrote:
How is it helpful to not follow the rules when posting patches
Quite simple:
* I wasn't aware about this fortran specific patch posting policy. I
ne
On 2005-05-17, at 11:29, Richard Earnshaw wrote:
On Tue, 2005-05-17 at 01:59, Steven Bosscher wrote:
No, I just don't build gfortran as a cross. There are many reasons
why this is a bad idea anyway.
Such as?
The dependence on external packages which don't cross compile well
for example.
> "Gabriel" == Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
Gabriel> Joe is right. But I think the diagnostic is very very
Gabriel> confusing and it is not obvious what was going from the type
Gabriel> signature. Please fill a bugzilla PR and ask for diagnostic
Gabriel> enhancement.
Tha
On Tuesday 17 May 2005 20:27, Marcin Dalecki wrote:
> On 2005-05-17, at 11:29, Richard Earnshaw wrote:
> > On Tue, 2005-05-17 at 01:59, Steven Bosscher wrote:
> >> No, I just don't build gfortran as a cross. There are many reasons
> >> why this is a bad idea anyway.
> >
> > Such as?
>
> The depend
On Tue, 17 May 2005, Joseph S. Myers wrote:
> the page for entering new bugs has a big notice "Before reporting a bug,
> please read the bug writing guidelines, please look at the list of most
> frequently reported bugs, and please search for the bug." so those for
> individual bugs could have a
Karel Gardas wrote:
On Tue, 17 May 2005, Alexandre Oliva wrote:
On May 17, 2005, Karel Gardas <[EMAIL PROTECTED]> wrote:
you see that 4.0 added "embedded" platforms like arm-none-elf and
mips-none-elf to the primary platforms list.
These are only embedded targets. You can't run GCC natively on th
Hello,
I've tried to meassure some cache misses of 4.0.1 and 4.1.0 C++
compilers by using oprofile on amd64 box while compiling MICO sources
and found that:
0) compiler options used were:
-I../include -Wall -D_REENTRANT -D_GNU_SOURCE -DPIC -fPIC -c
1) the most expensive seems to be comptyp
Karel Gardas <[EMAIL PROTECTED]> writes:
> I've thought that L1 and L2 DTLB misses are the most important for the
> overall performance or performance degradation, if not please correct
> me since this is my first attempt to measure and interpret such data.
TLB is just for caching the translation
Richard Henderson wrote:
On Tue, May 17, 2005 at 01:08:29PM -0400, Daniel Berlin wrote:
Depending on what field, yes, I'll object. There should be a "minimal
decl" for which the "normal" decl stuff should belong to. DECL_ALIGN,
for instance.
But you probably shouldn't have been doing that in th
>> Yes, but Ralf was complaining about embedded cross-compiling development
>> for RTEMS. I have not tried to reply to Peter Barada who complains about
>> GCC inablity to be run on embedded targets directly.
>
>Logically Peter's situation is the same as the NetBSD issue with
>building and testi
Nathan Sidwell wrote:
I attended a UK C++ panel meeting yesterday, and took the opportunity
to solicit opinions on this. The question I posed was
struct A {
...
T1 a;
T2 b;
};
void g(T1 &a);
void Foo () {
A v;
v.b = 2;
g (v.a);
Jonathan Wakely wrote:
On Mon, May 16, 2005 at 05:41:03PM -0700, Mark Mitchell wrote:
I've very nearly ready to release GCC 3.4.4. If you have objections or
high-priority fixes that you think will be required for this release,
please speak up within the next 24 hours.
Sorry for the last minute
Peter Barada wrote:
Yes, but Ralf was complaining about embedded cross-compiling development
for RTEMS. I have not tried to reply to Peter Barada who complains about
GCC inablity to be run on embedded targets directly.
Logically Peter's situation is the same as the NetBSD issue with
building and
Mark Mitchell wrote:
> Will the UK committee open a DR for this? Or, would you care to send
> mail to Steve Adamczyk about it?
this can be done. I shall wait until the minutes have been written up.
>
>> The observation was made that if A is non-POD, one cannot play offsetof
>> tricks to get fr
>> Its a 266Mhz ColdFire v4e machine, about 263 BogoMips, 1/20 the
>> BogoMips of my workstation, and with an NFS rootfs, it gets network
>> bound pretty rapidly and runs even slower compared to a NetBSD machine
>> with a local disk :)
>
>I would have thought the CPU itself was comparable to or fa
Nathan Sidwell wrote:
Mark Mitchell wrote:
Will the UK committee open a DR for this? Or, would you care to send
mail to Steve Adamczyk about it?
this can be done. I shall wait until the minutes have been written up.
Excellent.
The observation was made that if A is non-POD, one cannot play offset
On Tue, 17 May 2005, Andi Kleen wrote:
Karel Gardas <[EMAIL PROTECTED]> writes:
I've thought that L1 and L2 DTLB misses are the most important for the
overall performance or performance degradation, if not please correct
me since this is my first attempt to measure and interpret such data.
TLB is j
From: Ian Lance Taylor
Date: 15 May 2005 23:20:14 -0400
Well, we require an ISO C90 compiler; do we require ISO C90 libraries?
If we require the libraries, then we can remove a number of files from
libiberty, at least atexit.c, memchr.c, memcmp.c, memcpy.c, memmove.c,
memset.c,
On Tue, 17 May 2005, Joseph S. Myers wrote:
[...]
shortly. All those posted (at least this month) seem to get posted with
subject lines which do not match the normal form produced by test_summary
and so don't get so readily found by my script which counts how many test
results postings the
Mark Kettenis <[EMAIL PROTECTED]> writes:
>From: Ian Lance Taylor
>Date: 15 May 2005 23:20:14 -0400
>
>
>Well, we require an ISO C90 compiler; do we require ISO C90 libraries?
>If we require the libraries, then we can remove a number of files from
>libiberty, at least atexit
On May 17, 2005, at 2:21 PM, Mark Mitchell wrote:
It wouldn't look like escape to (at least some compilers')
optimizers if, say, the front end folded it to a constant. So, I'm
not sure how to express what constitutes escape.
Well, we're going to need to ensure the optimizer can see various
t
[rewritten/remeasured as per suggestion by Andy Kleen]
Hello,
I've tried to measure some cache misses of 4.0.1 and 4.1.0 C++
compilers by using oprofile on amd64 box while compiling MICO sources
and found that:
0) compiler options used were:
-I../include -Wall -D_REENTRANT -D_GNU_SOURCE -DP
Peter Barada wrote:
Its a 266Mhz ColdFire v4e machine, about 263 BogoMips, 1/20 the
BogoMips of my workstation, and with an NFS rootfs, it gets network
bound pretty rapidly and runs even slower compared to a NetBSD machine
with a local disk :)
Hmmm, Ghz wise and BogoMips wise, this is about half wh
On Tue, 17 May 2005, Hugh Sasse wrote:
> On Tue, 17 May 2005, Joseph S. Myers wrote:
> [...]
> > shortly. All those posted (at least this month) seem to get posted with
> > subject lines which do not match the normal form produced by test_summary
> > and so don't get so readily found by m
Opinions on how to handle this bug?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21250
This came up because we give declarations
line 0, but used line 1 in a different date structure.
I fixed the code to consistently use line 0, which is
needed for the --enable-mapped-location unification.
However,
On Tue, 17 May 2005, Joel Sherrill <[EMAIL PROTECTED]> wrote:
>> For future reference, where patches should be sent is explained here:
>> http://gcc.gnu.org/lists.html
> OK .. and Bugzilla or http://gcc.gnu.org/bugs.html references that link how?
I'm not sure we should add a link to lists.html fro
>> Its a 266Mhz ColdFire v4e machine, about 263 BogoMips, 1/20 the
>> BogoMips of my workstation, and with an NFS rootfs, it gets network
>> bound pretty rapidly and runs even slower compared to a NetBSD machine
>> with a local disk :)
>
>Hmmm, Ghz wise and BogoMips wise, this is about half what I
Mike Stump wrote:
We need to teach it about the meaning of constants.
One can:
#include "foo.h"
main() {
printf ("%d\n", offsetof (s, m));
}
and then in another file, read and use that on an address. One can
also transform it into a #define S_M_OFFSET 8, and #include it. So,
I'd claim the
I'm trying to build top of tree...
make[2]: Leaving directory `/Volumes/mrs3/net/gcc-darwinO2/powerpc-
apple-darwin8.0.0/libjava'
make[2]: Entering directory `/Volumes/mrs3/net/gcc-darwinO2/powerpc-
apple-darwin8.0.0/libjava'
make[2]: *** No rule to make target `0', needed by `gnu/awt.list'.
S
On May 17, 2005, at 4:00 PM, Mark Mitchell wrote:
it is that whether or not you spell "8" as "8", "&s.x - &s.y", or
"offsetof (S, x) - offsetof (S, y)" should not matter, in which
case I certainly agree.
Yes, that is it, we agree.
Huh? I can cross-compile GCC, its all the packages that require
native configuration/building
Is it fesable for people in this sort of situation to build GCC on a fast
machine but with the final host and target both set to whatever the slower
machine is (in this case coldfire)
Does GCC even
Per Bothner wrote:-
> Opinions on how to handle this bug?
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21250
>
> This came up because we give declarations
> line 0, but used line 1 in a different date structure.
> I fixed the code to consistently use line 0, which is
> needed for the --enable-m
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
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 up by canonicalizing type
Zack Weinberg wrote:
Stuff does appear between and with -g3, -dD,
and possibly some of the other -d switches. That is why they're
there. I would have no objection to suppressing it (and
too) when none of those options is in use.
In that case it's probably easiest to just hack c-ppoutput.c so
> > The documentation for -fvisibility=hidden suggets that this switch is
> > useful for shared libraries, to make things smaller and faster. It
> > doesn't seem to be appropriate for object libraries.
> It's done *exactly* so that we catch this bug in your configury.
I don't know about you, but
On Wed, May 18, 2005 at 05:12:09AM +0100, Sam Lauber wrote:
> I don't know about you, but forcing a link failure in good
> code just because someone screwed up GCC configuration is
> probably the of the most worst compiler hacker's sins.
But it IS NOT GOOD CODE! That's the whole point.
Whateve
On Tue, 2005-05-17 at 12:11 -0500, Joel Sherrill wrote:
> Joe Buck wrote:
> >
> > I used to be an embedded programmer myself, and while I cared very much
> > about the size and speed of the embedded code I wound up with, I didn't
> > care at all about being able to run the compiler itself on a ma
Jonathan Wilson wrote:
>>Huh? I can cross-compile GCC, its all the packages that require
>>native configuration/building
>
> Is it fesable for people in this sort of situation to build GCC on a fast
> machine but with the final host and target both set to whatever the slower
> machine is (i
On x86_64-linux-gnu I get with current CVS the following bootstrap error:
/cvs/gcc/libobjc/Object.m: In function '-[Object name]':
/cvs/gcc/libobjc/Object.m:101: internal compiler error: in tree_node_structure,
at tree.c:1815
Please submit a full bug report,
with preprocessed source if appropriat
90 matches
Mail list logo
