--- Comment #41 from jbeulich at novell dot com 2006-12-07 08:15 ---
That's not a good idea, I think. The semantics of how to treat undefined
symbols in the symbol table that arten't used in any relocations depend on the
OS ABI, not the ELF file format. Non-gld linkers may interpret
--- Comment #12 from burnus at gcc dot gnu dot org 2006-12-07 09:15 ---
Subject: Bug 29711
Author: burnus
Date: Thu Dec 7 09:15:41 2006
New Revision: 119609
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119609
Log:
2006-12-06 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #2 from midoegal at web dot de 2006-12-07 09:54 ---
Created an attachment (id=12764)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12764action=view)
Source file mentioned in the description
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30086
--- Comment #3 from midoegal at web dot de 2006-12-07 09:55 ---
I attached the file. Its from GDB 6.5.90 release.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30086
--- Comment #3 from mkuvyrkov at gcc dot gnu dot org 2006-12-07 10:02
---
Subject: Bug 29794
Author: mkuvyrkov
Date: Thu Dec 7 10:02:35 2006
New Revision: 119613
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119613
Log:
2006-12-07 Maxim Kuvyrkov [EMAIL PROTECTED]
PR
--- Comment #4 from mkuvyrkov at gcc dot gnu dot org 2006-12-07 10:05
---
Subject: Bug 29794
Author: mkuvyrkov
Date: Thu Dec 7 10:05:29 2006
New Revision: 119614
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119614
Log:
2006-12-07 Maxim Kuvyrkov [EMAIL PROTECTED]
PR
--- Comment #1 from pcarlini at suse dot de 2006-12-07 10:07 ---
*Assuming* we keep delivering the legacy hash_* containers, probably we should
also keep the corresponding debug mode version. Indeed, if we start delivering
the unordered containers in namespace std we should also deliver
--- Comment #5 from mkuvyrkov at gcc dot gnu dot org 2006-12-07 10:08
---
Fixed by the above commit.
--
mkuvyrkov at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from burnus at gcc dot gnu dot org 2006-12-07 10:25 ---
Works today = Close bug
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
The diagnostic of the code below is rather generic. A more verbose message
would be preferable. Without RECURSIVE, gfortran gives Error: Syntax error in
data declaration.
$ cat foo.f90
RECURSIVE LOGICAL SUBROUTINE foo()
END SUBROUTINE
$ gfortran-svn -c -Wall -g foo.f90
foo.f90:1:
RECURSIVE
--- Comment #1 from ubizjak at gmail dot com 2006-12-07 10:54 ---
Fixed by http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00462.html.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #3 from marc dot glisse at normalesup dot org 2006-12-07 11:04
---
Sure, it works with a posix shell. But it would not hurt to use single quotes
around the constant string passed as an argument to sed, as is done in the rest
of the file, if only for consistancy. It seems to
configured with: /vol/gnu/src/gcc-4.1.1/configure --prefix=/vol/gcc/4.1/
--with-cpu=pentium3 --with-arch=pentium3 --with-tune=pentium3
--enable-languages=c,c++,java
preprocessed output doesn't fit into this field. Please contact me for more
information.
Yours, Robert
--
Summary:
--- Comment #1 from rhaschke at techfak dot uni-bielefeld dot de
2006-12-07 11:56 ---
code compiles if the default argument for pIdleTarget
in line BaseRobot.ii:80118 is changed to 0
--
rhaschke at techfak dot uni-bielefeld dot de changed:
What|Removed
--- Comment #2 from rhaschke at techfak dot uni-bielefeld dot de
2006-12-07 11:58 ---
code compiles if the default argument pIdleTarget of method
commonEventProcessing
is changed to zero in line BaseRobot.ii:80118
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30108
--- Comment #30 from irar at il dot ibm dot com 2006-12-07 12:14 ---
I am testing a patch for x86 boostrap failure. It was caused by a bug in
vectorization of strided accesses analysis, and, therefore, has nothing to do
with the bootstrap failures on ppc.
Ira
--
--- Comment #7 from gary at gcc dot gnu dot org 2006-12-07 12:31 ---
Subject: Bug 24938
Author: gary
Date: Thu Dec 7 12:30:56 2006
New Revision: 119617
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119617
Log:
2006-12-06 Tom Tromey [EMAIL PROTECTED]
PR java/24938:
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-12-07 12:34 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21466
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-12-07 12:40 ---
Numbers with mainline r119612 are
FiniteElementMethod.cpp: 346MB, 46.86s
parse.ff.cc: 1GB, 1236.53s
so actually the latter is the biggest offender here ;) The compiler was built
with release checking (but not
--- Comment #18 from patchapp at dberlin dot org 2006-12-07 12:50 ---
Subject: Bug number PR17687
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00476.html
--
--- Comment #16 from j at uriah dot heep dot sax dot de 2006-12-07 13:24
---
The last update of this has been about a year ago, and talked about it not
being done before GCC 4.1... Now that GCC 4.2 has been branched off, is there
any news on integrating that patch?
There's one
--- Comment #31 from irar at il dot ibm dot com 2006-12-07 13:30 ---
(In reply to comment #17)
I applied the patch http://gcc.gnu.org/ml/gcc-patches/2006-07/msg01043.html (a
fix for PR26197). The bootstrap with vectorization passes!
However, the failure in comment #3 still occurs in
InetAddress.getHostName() does not resolve host names, which differs from the
Sun's JDK behaviour. Consider the following test case:
import java.net.InetAddress;
public class Test {
public static void main(String[] argv) throws Exception {
String resolved =
--- Comment #1 from renaud dot saintgratien at orange-ftgroup dot com
2006-12-07 13:34 ---
Created an attachment (id=12765)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12765action=view)
Test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30109
--- Comment #42 from matz at gcc dot gnu dot org 2006-12-07 13:57 ---
I agree with Jan and HJ here. We must not emit symbols to unreferenced
symbols. Even the size increase wouldn't be really acceptable. In a way
ELF _is_ special here, so special handling is completely justified. In
--- Comment #43 from hjl at lucon dot org 2006-12-07 14:05 ---
I posted the updated patch at
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00477.html
I have asked Steve and Janis to test it on AIX and HPUX. We are calling
process_pending_assemble_externals in 2 different places anyway.
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-12-07 14:07 ---
tree alias analysis :1125.41 (91%) usr 1.57 (31%) sys1127.32 (91%) wall
199468 kB (19%) ggc
PRE : 61.16 ( 5%) usr 0.83 (16%) sys 62.01 ( 5%) wall
2073 kB ( 0%) ggc
TOTAL
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-12-07 14:13 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-12-07 14:13 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-12-07 14:14 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-12-07 14:14 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-12-07 14:16 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-12-07 14:17 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-12-07 14:17 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-12-07 14:20 ---
Confirmed (but it's not PRE).
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from burnus at gcc dot gnu dot org 2006-12-07 14:21 ---
While I agree that the message is not that helpful, other compilers don't do
much better. (The problem is: There are zillions of ways to write invalid
code.)
I'd favour a WONTFIX, but maybe someone has a good idea
--- Comment #10 from dfranke at gcc dot gnu dot org 2006-12-07 15:11
---
Here on debian, the last revision that successfully bootstrapped was r118355
(glibc-2.3.2, kernel-2.6.15.7).
Anything else I can do?
--
dfranke at gcc dot gnu dot org changed:
What|Removed
The source from classpath/external is missing from the libgcj src.zip.
--
Summary: classpath external missing from src.zip
Product: gcc
Version: 2.95
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcj
--- Comment #1 from bkonrath at redhat dot com 2006-12-07 15:47 ---
Created an attachment (id=12766)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12766action=view)
patch to add source in classpath/external to src.zip
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30110
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-12-07 16:06 ---
I have a patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-12-07 16:07 ---
Created an attachment (id=12767)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12767action=view)
patch prototype
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30038
--- Comment #4 from pault at gcc dot gnu dot org 2006-12-07 16:29 ---
(In reply to comment #3)
It appears to be some wierdness with size = replace size with kind and the ICE
goes away too.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30084
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-12-07 16:46 ---
isn't this the same as loop unswitching?
PS This was done from a PS3!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30104
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-12-07 16:49 ---
unswitching would duplicate the whole loop here, so not exactly I think. But
if-conversion to
j = COND_EXPR p, 1, 2
or
j = 2 - (int)p;
would make j loop invariant.
--
--- Comment #3 from tromey at gcc dot gnu dot org 2006-12-07 17:19 ---
Fixed on ecj branch.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pault at gcc dot gnu dot org 2006-12-07 17:25 ---
Created an attachment (id=12768)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12768action=view)
Patch and testcases
I believe that this is consistent with the discussion on comp.lang.fortran.
The references to
--- Comment #2 from pault at gcc dot gnu dot org 2006-12-07 17:28 ---
Harald,
I agree that other compilers handle this OK but is it valid? As far as I can
tell, random_number and random_seed are specific intrinsics. What should the
form be here?
Thanks for keeping us on our toes!
--- Comment #18 from lucier at math dot purdue dot edu 2006-12-07 17:32
---
Well, I decided to try it with 4.3.0 on powerpc64-apple-darwin8.8.0 and didn't
get any better results:
[descartes:~/Desktop] lucier% time /pkgs/gcc-4.3.0-64/bin/gcc -mcpu=970 -m64
-no-cpp-precomp -Wall -W
--- Comment #18 from paulthomas2 at wanadoo dot fr 2006-12-07 17:33 ---
Subject: Re: Problem with handling optional and entry
master arguments
elizabeth,
We are talking about the same machine and the same operating system. All the
x86_64 binaries are from
--- Comment #4 from mmitchel at gcc dot gnu dot org 2006-12-07 17:49
---
Subject: Bug 29730
Author: mmitchel
Date: Thu Dec 7 17:49:32 2006
New Revision: 119631
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119631
Log:
PR c++/29730
* parser.c
#include iostream
int main()
{
struct pod {
int i;
};
struct inherit : pod {
inherit() : pod() {}
};
struct compose {
compose() : p() {}
pod p;
};
inherit i;
compose c;
std::cout i.i std::endl;
std::cout c.p.i
--- Comment #19 from dberlin at gcc dot gnu dot org 2006-12-07 17:54
---
Subject: Re: Inordinate compile times on large routines
This is the branch that you installed your changes on, right Dan?
yes
I suppose I should try it on another architecture to see whether the problem
--- Comment #20 from dberlin at gcc dot gnu dot org 2006-12-07 17:54
---
Subject: Re: Inordinate compile times on large routines
We now spend basically no time in PTA, and about 800 seconds in
remove_ssa_form.
Sometime later on, we run out of memory and crash.
(IE it's
--- Comment #1 from gcc-bugzilla at kayari dot org 2006-12-07 18:03 ---
Values printed out confirm it on Linux for 3.3.5 20050117 (prerelease) (SUSE
Linux), and official FSF 3.4.3, 4.0.1, 4.0.2, 4.1.1
N.B. I meant AIX 5.3, not 5/3
--
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-12-07 18:08
---
Subject: Bug 29730
Author: mmitchel
Date: Thu Dec 7 18:08:42 2006
New Revision: 119632
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119632
Log:
PR c++/29730
* parser.c
--- Comment #6 from mmitchel at gcc dot gnu dot org 2006-12-07 18:09
---
Fixed in 4.1.2, 4.2.0.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org
--- Comment #3 from pault at gcc dot gnu dot org 2006-12-07 18:15 ---
(In reply to comment #2)
I think this is a doublicate of one of symbol ambiguity bugs, which confuse
It is related - the latest version incorrectly gives a warning that the
interfaces are ambiguous.
In any case,
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-12-07 18:18 ---
Actually this is a PRE opertunity.
if we look into .102t.final_cleanup, we notice we did the load PRE:
L2:;
prephitmp.32 = *data;
prephitmp.38 = *(data + 12B);
i = 1;
goto bb 5 (L1);
L0:;
*((int *)
--- Comment #4 from dann at godzilla dot ics dot uci dot edu 2006-12-07
18:24 ---
(In reply to comment #3)
unswitching would duplicate the whole loop here, so not exactly I think. But
if-conversion to
j = COND_EXPR p, 1, 2
or
j = 2 - (int)p;
would make j loop
--- Comment #6 from patchapp at dberlin dot org 2006-12-07 18:25 ---
Subject: Bug number PR30028
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00499.html
--
--- Comment #17 from pinskia at gcc dot gnu dot org 2006-12-07 18:32
---
There are two things need for this patch to go forward.
First you need a copyright assignment on file.
Second you need to post the patch to [EMAIL PROTECTED]
--
--- Comment #3 from tromey at gcc dot gnu dot org 2006-12-07 18:37 ---
Nothing to do -- not sure why I didn't close it earlier.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
If I compile the following piece of code with g++ -c, and examine the resulting
object file, it references symbols myfoo and bar, so the second pragma
failed because of the namespace.
extern C {
#pragma redefine_extname foo myfoo
void foo(double);
namespace A {
#pragma redefine_extname
--- Comment #3 from burnus at gcc dot gnu dot org 2006-12-07 18:49 ---
I agree that other compilers handle this OK but is it valid?
I think it is. Think of the form
interface operator(=)
module procedure myassign
end interface
here the generic-spec is not a generic-name but
The following Fortran code, from the gamess CPU2006 benchmark, fails with an
ICE on the 4.1 branch when compiled with -m32 -O3.
SUBROUTINE RD2PDM(INFILE,TPDM,GBUF,LABS,NINTMX,IPIN)
C
IMPLICIT DOUBLE PRECISION(A-H,O-Z)
LOGICAL READMORE
INTEGER LABS(*),IPIN(*)
DOUBLE
--- Comment #3 from lmillward at gcc dot gnu dot org 2006-12-07 19:16
---
Subject: Bug 29980
Author: lmillward
Date: Thu Dec 7 19:16:38 2006
New Revision: 119633
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119633
Log:
PR c++/29980
*
--- Comment #4 from lmillward at gcc dot gnu dot org 2006-12-07 19:17
---
Fixed in 4.3.
--
lmillward at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-07 19:46 ---
This works with 4.3.0 20061205
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30113
--- Comment #10 from burnus at gcc dot gnu dot org 2006-12-07 20:00 ---
Using the three patches:
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00500.html
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00499.html
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00476.html
gfortran is able to
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-12-07 20:08 ---
Reducing, it has to do with default arguments.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-12-07 20:18 ---
Reduced testcase:
class BaseRobot {
typedef void (BaseRobot::*PseudoState)(void);
typedef PseudoState STATE;
STATE initial ();
int ready ();
STATE stpOtherTask ();
STATE commonEventProcessing
--- Comment #11 from dorit at il dot ibm dot com 2006-12-07 20:19 ---
(In reply to comment #10)
Using the three patches:
...
gfortran is able to use sincos - and does so for my example (comment #0; the
example, however, cannot be vectorized).
why? (what does
--- Comment #9 from burnus at gcc dot gnu dot org 2006-12-07 20:22 ---
I believe that this is consistent with the discussion on comp.lang.fortran.
Looks ok, quick tests with some examples looks also ok and it also regression
test on x86_64-unknown-linux-gnu.
The references to the
--- Comment #12 from burnus at gcc dot gnu dot org 2006-12-07 20:32 ---
(In reply to comment #11)
gfortran is able to use sincos - and does so for my example (comment #0; the
example, however, cannot be vectorized).
why? (what does -fdump-tree-vect-details say?)
sinc.f90:8: note:
--- Comment #1 from geoffk at gcc dot gnu dot org 2006-12-07 20:34 ---
This function was added in revision 118240, with
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01646.html.
--
geoffk at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from burnus at gcc dot gnu dot org 2006-12-07 20:36 ---
Created an attachment (id=12769)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12769action=view)
-fdump-tree-vect-details output of the example
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30038
program inquire_formatted_bug
character(len=32) :: buf
open(unit=1000, file=Mag.sav, status=OLD, form =UNFORMATTED)
inquire(unit=1000, formatted = buf)
print *, buf
end program inquire_formatted_bug
gives YES but should give NO
--
Summary: Inquire formatted yields erroneous
--- Comment #14 from rguenth at gcc dot gnu dot org 2006-12-07 20:48
---
sincos is not being used because we don't see that time is not aliased by the
writes to strain_tensor:
# VUSE SMT.774_6041;
time.463_952 = time;
D.3397_953 = time.463_952 *
--- Comment #15 from rguenth at gcc dot gnu dot org 2006-12-07 20:50
---
Note that for _vectorization_ of sincos we need the following:
- a vectorized sincos implementation and vectorization support for it
(that's the easier part). At the moment we only can vectorize calls
to
The fortran allocate() interface which is
void allocate (void **, int)
to the middle-end does not allow aliasing to create a separate alias tag
for the allocated memory. The middle-end only supports malloc style
interfaces for this, it looks like internal_malloc which the fortran
frontend
--- Comment #5 from lmillward at gcc dot gnu dot org 2006-12-07 20:59
---
Subject: Bug 29980
Author: lmillward
Date: Thu Dec 7 20:59:08 2006
New Revision: 119634
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119634
Log:
PR c++/29980
*
--- Comment #6 from lmillward at gcc dot gnu dot org 2006-12-07 21:00
---
Fixed in 4.2
--
lmillward at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from carlos at codesourcery dot com 2006-12-07 21:10
---
Eric,
All of my patches are now on mainline. The compiler and cpp should no longer
search in the configured prefix. Have you tested mainline?
There may be a couple of lurking spec file reads that try the
Compiling this with -pedantic and -Wformat gives the warning message that
follows it.
#includestdio.h
int main() {
int a[1],(*b)[1]=a;
printf(%p,b);
return 0;
}
test.c: In function main:
test.c:5: warning: format %p expects type void *, but argument 2 has type
int (*)[0u]
I
--- Comment #9 from dee at pcds dot biz 2006-12-07 21:25 ---
I'd like to point out that structures containing only pure virtual functions
should not trigger this diagnostic either. Consider the following:
struct IfacFoo
{
virtual int a() = 0;
virtual int b() = 0;
};
There is no
== begin of div.c ==
int main()
{
asm(
fdivp;
);
}
== end of div.c ==
if compiled
===
$ gcc div.c
$ gdb a.out
GNU gdb 6.4
Copyright 2005 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome
=/pkgs/gmp-4.2.1 --enable-checking=no --
enable-languages=c
Thread model: posix
gcc version 4.3.0 20061207 (experimental)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-12-07 21:54 ---
A little playing around and looking at the allocate() implementation in
libgfortran suggests that it is possible to fix this.
Index: trans-array.c
===
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-12-07 22:00 ---
That patch^Whack improves fatigue runtime from 27.3s to 9.5s (with the sincos
patches applied).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30115
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-07 22:40 ---
This is at most a GNU binutils bug. Please file it with them at
http://sourceware.org/bugzilla/ .
Also IIRC fdivp's arguments are swapped in ATT asm mode because of some
historical accident.
See the comment in
--- Comment #10 from paulthomas2 at wanadoo dot fr 2006-12-07 23:34 ---
Subject: Re: Ambigous interfaces not detected
burnus,
I'm quite sure I wouldn't have understood the Although not referenced
correctly without the deep look at the standard.
And if it is indeed referenced and
--- Comment #4 from tromey at gcc dot gnu dot org 2006-12-08 00:15 ---
Also we appear to incorrect create the annotation data
structure for one of the methods.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from ben at decadent dot org dot uk 2006-12-08 00:40
---
Lawrence: Every class has a destructor. You're talking about classes that have
trivial destructors. Whether a non-virtual destructor is trivial or not has no
bearing on the fact that if an instance of a derived
--- Comment #5 from tromey at gcc dot gnu dot org 2006-12-08 01:13 ---
I needed this to see correct output.
There's still some oddity where main sorts before barf in the output,
I haven't looked at that.
--- pp.java.~1~ 2006-12-05 11:49:25.0 -0700
+++ pp.java 2006-12-07
--- Comment #6 from tromey at gcc dot gnu dot org 2006-12-08 01:15 ---
Oh, I see. It is just that we need:
Arrays.sort(methods, myCollator);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30076
--- Comment #7 from tromey at gcc dot gnu dot org 2006-12-08 01:19 ---
Subject: Bug 30076
Author: tromey
Date: Fri Dec 8 01:19:17 2006
New Revision: 119644
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119644
Log:
PR libgcj/30076:
* defineclass.cc (read_fields):
/gcc-4.2.0-test --with-
gmp=/pkgs/gmp-4.2.1 --with-mpfr=/pkgs/gmp-4.2.1 --enable-checking=no
--enable-languages=c
Thread model: posix
gcc version 4.2.0 20061207 (prerelease)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2006-12-08 01:25
---
It's Magic!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30115
1 - 100 of 113 matches
Mail list logo
