Folks,
you all are great brave men hacking on one of the most mission-critical
free software piece ever. I'm seeing some of you are more and more
frustrated, since this thread is turning into the flame-war.
As a long time GCC user, I would like to ask you to calm down a bit if
this is
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_r.c
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-patches@
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
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
Brav ! Kiutaltunk Neked egy kt f rszre, 14 ingyenes jszakra
szl Eurorest hotelcsekket.
Ha korbban nem vettl rszt az akciinkban, akkor biztosan nem
hitted eddig, hogy 1 zenetrt, amit az ismerseidnek kldtl, egy olyan
hotelcsekk tulajdonosa lehetsz, amely 2 szemly rszre 14 ingyenes
jszakt garantl
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, which is
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 anyway.
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 is
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 build gfortran as a
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-17 at 01:59,
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
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 any
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-1.exp accordingly.
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:
Ian Lance Taylor ian@airs.com 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
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 ian@airs.com 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 ian@airs.com 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
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
On 17 May 2005 10:05:58 -0400, Ian Lance Taylor ian@airs.com 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
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
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:
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
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 other list but
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 problem
because
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 function
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 wrote:
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,
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
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
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.
--
Alexandre
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_blah macros for FIELD_DECL's, TYPE_DECL_blah macros for
TYPE_DECL's, etc, instead of using DECL_blah on both for some fields.
Can you be more specific on
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 can't
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_blah macros for FIELD_DECL's, TYPE_DECL_blah macros for
TYPE_DECL's, etc, instead of using
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 help
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
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
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 again
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
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
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
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.
Thanks, that's
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 dependence on
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 them,
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
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 translations
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 the
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 testing on
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
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
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 from
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 faster than
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
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
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
Mark Kettenis [EMAIL PROTECTED] writes:
From: Ian Lance Taylor ian@airs.com
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
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
[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
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
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 my
Opinions on how to handle this bug?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21250
This came up because we give built-in 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.
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 from
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 have (a
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'.
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 built-in 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
Per Bothner [EMAIL PROTECTED] writes:
...
However, we end up with preprocessor output like this:
# 1 any-file
# 0 built-in
# 1 command line
# 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
Neil Booth [EMAIL PROTECTED] writes:
But that would break too much
code. Simplest and cleanest solution: Just get rid of the built-in
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
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
Zack Weinberg wrote:
Stuff does appear between built-in and command line 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 command line
too) when none of those options is in use.
In that case it's probably
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.
Whatever.
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 machine
gcc 4.0.0 generates code that has line (**) ignored (nothing is invoked in it's
place).
I am not sure in what kind of relationship does this code stand with C++
standard.
But although structure X::Z is undefined, technically method Y::r can be invoked
safely since X::Z definition isn't required
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-17
06:31 ---
Subject: Bug 15080
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-17 06:31:51
Modified files:
gcc/fortran: ChangeLog
gcc/testsuite :
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-17
06:45 ---
Subject: Bug 21610
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-17 06:45:49
Modified files:
gcc: ChangeLog c-typeck.c
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-17
06:48 ---
Subject: Bug 21492
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-17 06:48:19
Modified files:
gcc: ChangeLog cfgcleanup.c
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-17
06:51 ---
Subject: Bug 21454
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-17 06:51:48
Modified files:
gcc/testsuite : ChangeLog
gcc/cp :
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-17
07:02 ---
Subject: Bug 15080
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-05-17 07:02:18
Modified files:
gcc/testsuite :
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-17
07:08 ---
Subject: Bug 21610
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-05-17 07:07:59
Modified files:
gcc:
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-17
07:10 ---
Subject: Bug 21454
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-05-17 07:10:40
Modified files:
gcc/testsuite :
In the following code snippet:
namespace odd {
templateclass T
void f(T);
}
namespace N {
struct A {};
int f(A);
void g()
{
A a;
using odd::f;
int assert = sizeof(f(a)); // --- here
}
}
according to the standard 3.4.2/2 int N::f(A) should be found. But gcc finds
void
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-05-17
08:04 ---
Fails on i386-freebsd, too. Problems with non-linux /dev/null semantic, looks
like.
--
What|Removed |Added
--- Additional Comments From steven at gcc dot gnu dot org 2005-05-17
08:14 ---
SSA form after inserting ASSERT_EXPRs
main ()
{
int i;
int c;
int b;
int D.1576;
bb 0:
c_4 = f ();
if (c_4 = 0) goto L0; else goto L8;
L0:;
c_8 = ASSERT_EXPR c_4, c_4 = 0;
c_7
--
What|Removed |Added
Priority|P2 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21332
--- Additional Comments From pluto at agmk dot net 2005-05-17 08:27 ---
(In reply to comment #3)
Known gcc bug. Check out my patch in bug 19664:
http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00180.html
You may need to fix libstdc++ header files also.
in PR19664 i see
GCC produced this ICE when the attached program was compiled. I tried the fix
from http://gcc.gnu.org/PR18641 but it did not fix the problem.
commandline options
-O2 -msoft-float -m64 -c
gcc output
=
a.c: In function `do_select':
a.c:12770: error: unable to find
--- Additional Comments From raj dot khem at gmail dot com 2005-05-17
08:43 ---
Created an attachment (id=8907)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8907action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21616
--- Additional Comments From pcarlini at suse dot de 2005-05-17 08:57
---
Assuming that the intertwined compiler issues get fixed, the libstdc++ patch
should be trivial, I'm attaching to 19664 an old draft that maybe has now some
hunks wrong about copyright dates (if you can rework
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-17
09:00 ---
Subject: Bug 21595
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-17 09:00:03
Modified files:
gcc: ChangeLog builtins.c
1 - 100 of 224 matches
Mail list logo
