Some time ago, someone posted a patch which provided beginnings of a
general-purpose Ada test suite infrastructure (in addition to the
current ACATS tests, which cannot be used for regression tests). The
patch was not integrated, and I can't find it at the moment. 8-(
Does anybody know which
On Wed, 27 Apr 2005, Daniel Berlin wrote:
If you want a faster compiler, it's hard work. It means not adding
features because the design isn't a good one, *even if the user would
still find it useful*. People aren't willing to do this. It means lots
and lots of profiling, and taking care of
Some time ago, someone posted a patch which provided beginnings of a
general-purpose Ada test suite infrastructure (in addition to the
current ACATS tests, which cannot be used for regression tests). The
Note that this is technically incorrect: the ACATS infrastructure can
be used for
Paul Koning writes:
Andrew == Andrew Pinski [EMAIL PROTECTED] writes:
However, I can always tell when a GCC build has hit the libjava
build -- that's when the *whole system* suddenly slows to a crawl.
Maybe it comes from doing some processing on 5000 foo.o files all
at
Original Message
From: Marcin Dalecki
Sent: 28 April 2005 02:58
On 2005-04-27, at 22:54, Karel Gardas wrote:
Total Physical Source Lines of Code (SLOC)= 2,456,727
Development Effort Estimate, Person-Years (Person-Months) = 725.95
(8,711.36) (Basic COCOMO model,
* Arnaud Charlet:
Some time ago, someone posted a patch which provided beginnings of a
general-purpose Ada test suite infrastructure (in addition to the
current ACATS tests, which cannot be used for regression tests). The
Note that this is technically incorrect: the ACATS infrastructure can
I thought that there were some reservations about changing the ACATS
test suite.
I do not remember anything like that. Also, we're not talking about changing
the ACATS test suite, but rather expanding it.
So how we can make sure that this work is not lost? Who would be in a
position to
On Thu, 2005-04-28 at 09:45 +0200, Florian Weimer wrote:
Some time ago, someone posted a patch which provided beginnings of a
general-purpose Ada test suite infrastructure (in addition to the
current ACATS tests, which cannot be used for regression tests). The
patch was not integrated, and I
Hi all,
I have some preleminary benchmark results comparing 3.4(.3) with 4.0.0,
including some optimization option permuations.
http://exactcode.de/rene/hidden/gcc-article/2005-gcc-4.0/stat2-rt.png
http://exactcode.de/rene/hidden/gcc-article/2005-gcc-4.0/stat2-bt.png
rt = runtime
bt =
On Wed, 2005-04-27 at 20:57, Steven Bosscher wrote:
On Wednesday 27 April 2005 17:45, Matt Thomas wrote:
The features under discussion are new, they didn't exist before.
And because they never existed before, their cost for older platforms
may not have been correctly assessed.
If
On Wed, 2005-04-27 at 21:55, Andrew Pinski wrote:
However, I can always tell when a GCC build has hit the libjava build
-- that's when the *whole system* suddenly slows to a crawl. Maybe
it comes from doing some processing on 5000 foo.o files all at
once... :-(
But that is not GCC
On Thu, Apr 28, 2005 at 07:31:06AM +, Thorsten Glaser wrote:
Zack Weinberg dixit:
This could be made substantially easier if libgcc moved to the top
level. You wanna help out with that?
What about crtstuff?
Yes, they should be moved at the same time; I consider them closer to
part of
Richard Earnshaw writes:
On Wed, 2005-04-27 at 21:55, Andrew Pinski wrote:
However, I can always tell when a GCC build has hit the libjava build
-- that's when the *whole system* suddenly slows to a crawl. Maybe
it comes from doing some processing on 5000 foo.o files all at
On Thu, 2005-04-28 at 14:35, Andrew Haley wrote:
Richard Earnshaw writes:
On Wed, 2005-04-27 at 21:55, Andrew Pinski wrote:
However, I can always tell when a GCC build has hit the libjava build
-- that's when the *whole system* suddenly slows to a crawl. Maybe
it comes from
James E Wilson wrote:
Amir Fuhrmann wrote:
../gcc-3.4.3/configure --exec-prefix=/usr/local --program-prefix=ppc-
--with-stabs -with-cpu=603 --target=powerpc-eabi --with-gnu-as=ppc-as
--with-gnu-ld=ppc-ld --enable-languages=c,c++
The suggestion to look at Dan Kegel's crosstool is a good one, but
A testcase to trigger the assert was:
typedef _Bool Tal16bool __attribute__ ((aligned (16)));
struct S49
{
Tal16bool a:1;
};
and it turns out that the underlying problem is actually in the
general-purpose
field layout code. Both known_align and actual_align are calculated as
BIGGEST_ALIGNMENT
I have to agree with Richard's assessment, gcc is currently on the verge of
being
unusable in many instances.
If you have a lot of software to build and have to do complete rebuilds it's
painful,
the binutils guys have a 3x speedup patch coming up, but every time there is a
speedup
it
This is sort of the final state I ended up trying to teach
the C frontend not to emit array-to-pointer decay as
ADDR_EXPR (element-type*, array)
but as
ADDR_EXPR (element-type*, ARRAY_REF (element-type, array, 0))
for both type correctness and for possible simplifications of
fold and the tree
On Wed, Apr 27, 2005 at 08:05:39AM -0700, Matt Thomas wrote:
Am I the only person who has attempted to do a native bootstrap on a
system as slow as a M68k?
I am using an Amiga with [EMAIL PROTECTED] myself. My last GCC bootstrap on
that machine was done in 1999 for GCC 2.95.2 and it took
Peter Barada wrote:
Well, yes. 1 second/file is still slow! I want make to complete
instantaneously! Don't you?
Actually I want it to complete before I even start, but I don't want
to get too greedy. :)
What's really sad is that for cross-compilation of the toolchain, we
have to repeat a few
On Wed, Apr 27, 2005 at 04:40:29PM -0700, Zack Weinberg wrote:
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
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 needing -lgcc-eh), so
even really fast
On Thu, 2005-04-28 at 11:58 -0400, Peter Barada wrote:
This is for a m68k-linux build (with coldfire-linux config for glibc),
and its only the C compiler, so adding C++ will obvioulsy make it take
longer.
A 2.4 Ghz P4 isn't what I would consider an obsolete machine and it took
90 minutes
On 2005-04-27 14:30:01 -0700, Mike Stump wrote:
On Apr 27, 2005, at 5:15 AM, Neil Booth wrote:
Even better, you can turn of the warning with a cast, making your
intent explicit to the compiler, so there's every reason to have
it on by default.
And, if you don't like casts, you can (...)255
Output from running srcdir/config.guess:
powerpc-ibm-aix5.2.0.0
I have not installed this version of gcc yet so here is the output from xgcc in
objdir/gcc/xgcc -v:
Using built-in specs.
Target: powerpc-ibm-aix5.2.0.0
Configured with: ../gcc-4.0.0/configure --prefix=/usr/local
On Wed, 2005-04-27 at 16:40 -0700, Zack Weinberg wrote:
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,
On Thu, 28 Apr 2005, Richard Guenther wrote:
The patch was bootstrapped and tested on i686-pc-linux-gnu for
the C language with the only remaining regression being c99-init-4.c
(I didn't manage to find the place to fix).
You don't say how it regresses. What diagnostic is it generating, what
Andrew Haley [EMAIL PROTECTED] writes:
If ld can't accept a list of files from a stream but is instead
limited by command line length, then that *is* the fault of ld.
GNU ld won't currently read a list of files from stdin, but it will
read a list of files from a file.
For example, look at
Ian Lance Taylor writes:
Andrew Haley [EMAIL PROTECTED] writes:
If ld can't accept a list of files from a stream but is instead
limited by command line length, then that *is* the fault of ld.
GNU ld won't currently read a list of files from stdin, but it will
read a list of files
Martin Koegler wrote:
I have redone the implementation of the eeprom attribute in my prototype.
It is now a cleaner solution, but requires larger changes in the core,
but the changes in the core should not affect any backend/frontend, if
it does not uses them (except a missing case in
Hi,
PR21173 and its duplicates are a class of wrong-code and ICE bugs
in GCC 4.0.0.
In Bugzilla, PR21173 now has 3 duplicates, and there was another
example on this mailing list. That makes 5 users who have already
run into this rather serious bug. That is a lot, for a compiler
that has only
On Wed, Apr 27, 2005 at 07:40:37PM -0600, Tom Tromey wrote:
Paul == Paul Koning [EMAIL PROTECTED] writes:
Paul Maybe. Then again, maybe there are real problems here. The ranlib
Paul one was already mentioned. And I wonder if libjava really needs to
Paul bring the host to its knees, as it
On Thu, Apr 28, 2005 at 12:09:35PM -0400, David Edelsohn wrote:
Andrew Haley writes:
Andrew Yeah, good point. libtool seems to go to extraordinary lengths to
Andrew avoid doing so, I presume because it isn't portable.
Current libtool does allow a list of files, but the version used
Andrew Haley writes:
Andrew Yes thanks, I've had that pointed out to me. Apparently the real
Andrew issue here is that we have an older version of libtool in the gcc
Andrew tree.
Any feature in libtool CVS is fair game to be backported to
libtool in GCC. I am planning to backport a
Joe Buck writes:
Joe Is there a reason why we aren't using a recent libtool?
Porting and testing effort to upgrade.
David
On Thu, Apr 28, 2005 at 06:45:10PM +0200, Steven Bosscher wrote:
Hi,
PR21173 and its duplicates are a class of wrong-code and ICE bugs
in GCC 4.0.0.
In Bugzilla, PR21173 now has 3 duplicates, and there was another
example on this mailing list. That makes 5 users who have already
run into
Joe Buck writes:
On Wed, Apr 27, 2005 at 07:40:37PM -0600, Tom Tromey wrote:
Paul == Paul Koning [EMAIL PROTECTED] writes:
Paul Maybe. Then again, maybe there are real problems here. The ranlib
Paul one was already mentioned. And I wonder if libjava really needs to
Paul bring
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I only build with --enable-languages=c,c++ - I can try a full build if
you want. Also I couldn't run the testsuite because of missing testtools.
Christian
- -
make bootstrap successful build info:
$
On Thu, Apr 28, 2005 at 12:37:48PM -0400, Paul Schlie wrote:
Martin Koegler wrote:
I have redone the implementation of the eeprom attribute in my prototype.
It is now a cleaner solution, but requires larger changes in the core,
but the changes in the core should not affect any
On Apr 28, 2005, at 9:10 AM, Daniel Berlin wrote:
1. make bootstrap on a 2.4ghz p4 takes 90 minutes for me as of
yesterday.
2. Building XLC with (C,C++,Fortran) and a single backend takes
roughly
the same time as building GCC. And they aren't three staging, AFAIK.
..ain't the same ballpark, it
t002.x has this code:
typedef unsigned short int Tal16ushort __attribute__ ((aligned (16)));
struct S460
{
unsigned long int __attribute__ ((packed)) a;
Tal16ushort __attribute__ ((aligned)) b:13) - 1) 15) + 1);
unsigned short int c;
};
BIGGEST_ALIGNMENT is 64 for sh64-elf.
Does the
On Apr 28, 2005 06:55 PM, Joe Buck [EMAIL PROTECTED] wrote:
On Thu, Apr 28, 2005 at 06:45:10PM +0200, Steven Bosscher wrote:
Hi,
PR21173 and its duplicates are a class of wrong-code and ICE bugs
in GCC 4.0.0.
In Bugzilla, PR21173 now has 3 duplicates, and there was another
On Thu, Apr 28, 2005 at 01:05:29PM +0200, Laurent GUERBY wrote:
On Thu, 2005-04-28 at 09:45 +0200, Florian Weimer wrote:
Some time ago, someone posted a patch which provided beginnings of a
general-purpose Ada test suite infrastructure (in addition to the
current ACATS tests, which cannot
On Wed, 27 Apr 2005 16:52:25 -0400, Paul Koning [EMAIL PROTECTED] said:
However, I can always tell when a GCC build has hit the libjava build
-- that's when the *whole system* suddenly slows to a crawl. Maybe
it comes from doing some processing on 5000 foo.o files all at
once... :-(
It's
On Thu, Apr 28, 2005 at 07:31:32PM +0200, Steven Bosscher wrote:
Yeah, but in this case the patch that introduced the bug was one of
the last to go in before the release (it was the fix for PRs 20490
and 20929, the patch for that went in on April 17). So it was more
an unfortunate fix than a
On Thu, 2005-04-28 at 10:23 -0700, Devang Patel wrote:
On Apr 28, 2005, at 9:10 AM, Daniel Berlin wrote:
1. make bootstrap on a 2.4ghz p4 takes 90 minutes for me as of
yesterday.
2. Building XLC with (C,C++,Fortran) and a single backend takes
roughly
the same time as building GCC.
Not that I'm really complaining: you can get quite a lot of mileage
out of multiple CPUs as it is, more than enough (in my opinion) to
justify purchasing some nice build servers by software shops that do a
lot of GCC work. (I won't post the actual bootstrap times out of fear
of being lynched.)
Someone complained I was unfair in my gcc bootstrap times since
some builds included libjava/gfortran and some did not.
So in the past day, I've done bootstrap with just c,c++,objc on
both 3.4 and gcc4.1. I've put the results in a web page at
http://3am-software.com/gcc-speed.html. The initial
On Apr 28, 2005, at 10:54 AM, Daniel Berlin wrote:
On Thu, 2005-04-28 at 10:23 -0700, Devang Patel wrote:
On Apr 28, 2005, at 9:10 AM, Daniel Berlin wrote:
1. make bootstrap on a 2.4ghz p4 takes 90 minutes for me as of
yesterday.
2. Building XLC with (C,C++,Fortran) and a single backend takes
On Thu, Apr 28, 2005 at 11:03:51AM -0700, Matt Thomas wrote:
Someone complained I was unfair in my gcc bootstrap times since
some builds included libjava/gfortran and some did not.
So in the past day, I've done bootstrap with just c,c++,objc on
both 3.4 and gcc4.1. I've put the results in
Matt Thomas [EMAIL PROTECTED] writes:
When I see the native stage2 m68k compiler spend 30+ minutes compute bound
with no paging activity compiling a single source file, I believe
that is an accurate term. Compiling stage3 on a 50MHz 68060 took 18 hours.
(That 30 minutes was for fold-const.c
On Thu, 2005-04-28 at 11:08 -0700, Devang Patel wrote:
On Apr 28, 2005, at 10:54 AM, Daniel Berlin wrote:
On Thu, 2005-04-28 at 10:23 -0700, Devang Patel wrote:
On Apr 28, 2005, at 9:10 AM, Daniel Berlin wrote:
1. make bootstrap on a 2.4ghz p4 takes 90 minutes for me as of
yesterday.
Note:
- I builded GMP 4.1.4 with MPFR 4.1 myself.
- I switched to GNU make and actualized some other tools as avalable
(http://gcc.gnu.org/install/prerequisites.html).
- Building fails if standard tools from Mac OS 10.3.9 are used! The
prerequisits changed!
- Other languages will come later.
On Thu, 28 Apr 2005, Ian Lance Taylor wrote:
If you can include the preprocessed file and profiler output from cc1
running on your system, there is a chance that this can be addressed.
GCC comes with a test suite and a means for submitting results. May
I suggest that it might be useful to have a
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 ?
Thanks a lot.
Regards,
Laurielle LEA
--
Laurielle LEA
Savoir-faire Linux inc.
http://www.savoirfairelinux.com
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 supports just 8bit
On Thu, Apr 28, 2005 at 03:43:22PM -0400, Paul Schlie wrote:
For the MEM_AREA for the tree, I have eliminated many explicit set operation
of this attribute (build3_COMPONENT_REF and build4_ARRAY_REF completly).
For certain tree codes, the build{1,2,3,4} automatically generate the
On Thu, 2005-04-28 at 11:03 -0700, Matt Thomas wrote:
Someone complained I was unfair in my gcc bootstrap times since
some builds included libjava/gfortran and some did not.
So in the past day, I've done bootstrap with just c,c++,objc on
both 3.4 and gcc4.1. I've put the results in a web
On Thu, 28 Apr 2005, Daniel Berlin wrote:
On Thu, 2005-04-28 at 11:03 -0700, Matt Thomas wrote:
Someone complained I was unfair in my gcc bootstrap times since
some builds included libjava/gfortran and some did not.
So in the past day, I've done bootstrap with just c,c++,objc on
both 3.4 and
Peter Barada wrote:
The alternative of course is to do only crossbuilds. Is it reasonable
to say that, for platforms where a bootstrap is no longer feasible, a
successful crossbuild is an acceptable test procedure to use instead?
A successful crossbuild is certainly the minimum concievable
From: Martin Koegler [EMAIL PROTECTED]
On Thu, Apr 28, 2005 at 03:43:22PM -0400, Paul Schlie wrote:
For the MEM_AREA for the tree, I have eliminated many explicit set operation
of this attribute (build3_COMPONENT_REF and build4_ARRAY_REF completly).
For certain tree codes, the
Unfortunately for some of the embedded targets(like the ColdFire V4e
work I'm doing), a bootstrap is impossible due to limited memory and
no usable mass-storage device on the hardware I have available, so
hopefully a successful crossbuild will suffice.
How about a successful crossbuild plus
On Apr 27, 2005, at 7:41 AM, David Edelsohn wrote:
GCC now supports C++, Fortran 90 and Java. Those languages have
extensive, complicated runtimes. The GCC Java environment is becoming
much more complete and standards compliant, which means adding more
and
more features.
Except it's not
Hi to all,
While trying to build gcc 4.0 on an iSeries V5R3 using PASE (aix 5.1 emulation),
with a gcc 3.3.4 () got the following :
gcc 3.3.4 specs :
Reading specs from
/QOpenSys/usr/local/bin/../lib/gcc-lib/powerpc-ibm-aix5.1.0.0/3.3.4/specs
Configured with: ../gcc-3.3.4/configure
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-28
07:49 ---
Using gcc version 4.1.0 20050418, I get an ICE/segfault. Beginning of the
backtrace:
(gdb) where
#0 0xb7ee4ec5 in vfprintf () from /lib/tls/libc.so.6
#1 0xb7f032db in vsprintf () from
--- Additional Comments From pcarlini at suse dot de 2005-04-27 16:03
---
Fixed for 4.0.1.
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-28
07:51 ---
Subject: Bug 21244
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-28
07:58 ---
Possible patch:
diff -p -u -r1.39 resolve.c
--- gcc/fortran/resolve.c 19 Mar 2005 19:45:33 - 1.39
+++ gcc/fortran/resolve.c 28 Apr 2005 07:56:12 -
@@ -616,6 +616,13 @@
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-28
08:00 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00
--- Additional Comments From nathan at gcc dot gnu dot org 2005-04-28
08:02 ---
the example test case is invalid even with the gnu extension. As with
static const int members, you must have a single out-of-class definition of
the member EVEN IF the member is initialized in class.
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-28
08:02 ---
Subject: Bug 21244
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-04-28 08:01:36
Modified files:
libstdc++-v3 :
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-04-28
08:07 ---
In 4.1, this is now a runtime error:
$ cat maxloc-2.f90
integer, dimension(0:1,0:1) :: n
integer, dimension(1) :: i
n = reshape((/1, 2, 3, 4/), shape(n))
i = maxloc(n)
print *,i
end program
$
--- Additional Comments From gdr at gcc dot gnu dot org 2005-04-28 08:23
---
(In reply to comment #6)
Um... first of all, this works on 3.4 branch only by accident, i.e. I think
the
underlying problem is still present there. What happens is that a call has an
argument containing a
--- Additional Comments From gdr at gcc dot gnu dot org 2005-04-28 08:34
---
(In reply to comment #15)
Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01713.html.
Roger --
Are you still confident in this patch (as you said last Jan) for 3.3.6?
-- Gaby
--
--- Additional Comments From gdr at gcc dot gnu dot org 2005-04-28 08:36
---
(In reply to comment #4)
I don't know if there is anything we can do about 3.3.x but who knows.
No PowerPC maintainer seems to be interested in this. Will most likely
close as wontfix.
-- Gaby
--
--- Additional Comments From gdr at gcc dot gnu dot org 2005-04-28 08:38
---
(In reply to comment #2)
Confirmed, only a regression for 3.3.x.
This is infinite loop in the g++ parser. Since, it is ICE on
invalid code, it is not critical at this time.
-- Gaby
--
What
gcc -v
Reading specs from /usr/lib/gcc/i586-mandrake-linux-gnu/3.4.1/specs
Configured with: ../configure --prefix=/usr --libdir=/usr/lib --with-
slibdir=/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared -
-enable-threads=posix --disable-checking --enable-long-long --enable-
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-28
09:19 ---
It does not fix the error. Will look further into it.
--
What|Removed |Added
--- Additional Comments From matz at suse dot de 2005-04-28 09:24 ---
Yes, I determined that already in the initial report; to cite myself:
It's invalid for two reasons I think, first the missing definition, instead
of the declaration.
[the second reason being the use of the
--- Additional Comments From pcarlini at suse dot de 2005-04-28 09:25
---
There is nothing wrong with a null char per se. The problem is that you second
constructor call is wrong: according to the standard, there is *no* constructor
taking a const char*, and two size_type. Instead,
--- Additional Comments From aph at gcc dot gnu dot org 2005-04-28 10:59
---
Added to Tom Tromey's queue for 4.0 branch.
--
What|Removed |Added
--- Additional Comments From aph at gcc dot gnu dot org 2005-04-28 11:00
---
Added to Tom Tromey's queue for 4.0 branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21140
I don't if this is a gcc or autoconf issue, but here it is:
My system: SunOS 5.9 Generic_118558-05 sun4u sparc SUNW,Sun-Fire-280R Solaris
My configure:env CC=cc ../configure --prefix=/scratch/src/gcc-4-test \
--enable-threads --with-cpu=ultrasparc --enable-shared \
--enable-languages=c,c++
When
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-28
11:34 ---
New patch proposed: http://gcc.gnu.org/ml/fortran/2005-04/msg00667.html
--
What|Removed |Added
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-28
11:56 ---
Subject: Bug 20865
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-04-28 11:56:03
Modified files:
gcc/fortran:
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-28
11:56 ---
Subject: Bug 20865
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-04-28 11:56:03
Modified files:
gcc/fortran:
/// template.cc /
struct VirtualBase
{
virtual ~VirtualBase();
};
struct Foo
{};
struct Bar
{
virtual ~Bar();
};
templateclass OtherBase
class Test : public VirtualBase, public OtherBase
{
};
void func()
{
TestFoo foo;
TestBar bar;
}
--- Additional Comments From pcarlini at suse dot de 2005-04-28 12:12
---
By the way, the proposed patch does *not* implement FNV right: among other
things, replaces a bit-a-bit xor with a sum.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21193
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-28
12:59 ---
*** Bug 21261 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-28
12:59 ---
*** This bug has been marked as a duplicate of 9382 ***
--
What|Removed |Added
Given the code below, GCC fails to optimize the tail call to memset into a jmp
on x86_64-unknown-linux-gnu as of 4.0 or 4.1 mainline. Versions 3.4 and 3.3
perform the transformation so it is a regression. All GCC versions on x86_64
manage to optimize the call to my_memset so it may be related
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-28
13:07 ---
*** Bug 21263 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-28
13:07 ---
*** This bug has been marked as a duplicate of 21230 ***
--
What|Removed |Added
--- Additional Comments From ghazi at gcc dot gnu dot org 2005-04-28 13:11
---
Roger Sayle provided this feedback to me in private email and agreed to have it
copied here:
--
I've glanced through the code and I suspect I
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-28
13:13 ---
Confirmed, it also happens on PPC-darwin too.
Note here is a testcase for x86 (32bit):
#include stddef.h
extern void *memset (void *, int, size_t);
extern void *my_memset (void *, int, size_t);
void
foo
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-28
13:24 ---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-04-28
13:36 ---
(In reply to comment #9)
Mac OS X and darwin works on the G3, just fine.
The Mac OS X tiger system requirements say that it needs built-in firewire.
This Mac doesn't have firewire. It also came with 32
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-28
13:42 ---
(In reply to comment #10)
(In reply to comment #9)
Mac OS X and darwin works on the G3, just fine.
The Mac OS X tiger system requirements say that it needs built-in firewire.
This Mac doesn't have
$ cat minlc.c
void minlc(float *a, int n)
{
int i;
float mv = a[0];
for (i=1; in; i++)
{
if(a[i] mv)
mv = a[i];
}
}
$ gcc -O2 -ftree-vectorize -ftree-vectorizer-verbose=3 -S minlc.c
minlc.c: In function 'minlc':
minlc.c:2: error: Definition in block 2
1 - 100 of 162 matches
Mail list logo
