[Bug fortran/27035] present doesn't work on array
--- Comment #10 from paul dot richard dot thomas at cea dot fr 2006-04-05 07:02 --- > program main > call foo (5) > end program main > subroutine foo(n, a) > integer :: n > integer, dimension(5), optional :: a > print *, n > if (present (a)) call abort () > end subroutine foo Andrew is right about this; gfortran does not communicate the "interface" (that's the word that you were looking for, Andrew) between same file but separate procedures. Thus, MAIN does not "know" that the second argument is optional. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27035
[Bug classpath/27028] Iterator.hasNext() throws ConcurrentModificationException
--- Comment #4 from rmathew at gcc dot gnu dot org 2006-04-05 07:05 --- (In reply to comment #2) > The difference between Sun's and Classpath's implementation appears to be that > Classpath will check for Concurrent Modification on both hasNext() and next() > calls, while Sun's implementation only checks next() calls. I would argue that Sun's implementation is correct in this case in the sense that hasNext() doesn't actually modify anything, only next() does. I agree that the user code is buggy, gets a potentially bogus answer with hasNext() and is simply asking for trouble, but the said trouble doesn't happen unless it actually calls next(). You cannot throw an exception on me if I merely intend to screw up - do that only if I actually screw up. My 2p. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27028
[Bug c++/12226] [3.3 Regression] g++ fails to enforce accessibility requirement for copy constructor
--- Comment #19 from jason at gcc dot gnu dot org 2006-04-05 07:05 --- Giving an error for this testcase is no longer correct under DR 391: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#391 -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12226
[Bug c++/12226] [3.3 Regression] g++ fails to enforce accessibility requirement for copy constructor
--- Comment #20 from pinskia at gcc dot gnu dot org 2006-04-05 07:10 --- (In reply to comment #19) > Giving an error for this testcase is no longer correct under DR 391: > > http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#391 That would be recorded as PR 25950. *** This bug has been marked as a duplicate of 25950 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12226
[Bug c++/25950] [3.4/4.0/4.1] [DR 391] Reference binding and explicit copy constructors
--- Comment #20 from pinskia at gcc dot gnu dot org 2006-04-05 07:10 --- *** Bug 12226 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||austern at apple dot com Bug 25950 depends on bug 12226, which changed state. Bug 12226 Summary: [3.3 Regression] g++ fails to enforce accessibility requirement for copy constructor http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12226 What|Old Value |New Value Status|REOPENED|RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25950
[Bug fortran/27035] present doesn't work on array
--- Comment #11 from paul dot richard dot thomas at cea dot fr 2006-04-05 07:17 --- (In reply to comment #7) > I don't think this is defined code: > if (present (a)) call abort () > call foo_ (a) > If a is not present, you should not be able to use a in any way. Not quite; as I recorded in PR26891 (fixed in trunk and to be fixed in 4.1 tomorrow) 12.4.1.5 Restriction on dummy arguments not present. . snip . Except as noted in the list above, it may be supplied as an actual argument corresponding to an optional dummy argument, which is also considered not to be associated with an actual argument. The code below works correctly (and in the same way as DF6.0 and ifort). I cannot see a bug in this PR. Paul module mod implicit none private public bar_ interface bar_ module procedure bar end interface public foo_ interface foo_ module procedure foo end interface contains subroutine bar (a) real(kind=kind(1.0d0)), dimension(:,:), optional :: a if (present(a)) then print *, "present in BAR" else print *, "not present in BAR" ENDIF call foo_ (a) ! Optional dummy and optional actual => Acceptable end subroutine bar subroutine foo(a) real(kind=kind(1.0d0)), dimension(:,:), optional :: a if (present(a)) then print *, "present in FOO" else print *, "not present in FOO" ENDIF end subroutine foo end program main use mod real(kind=kind(1.0d0)), dimension(1,1) :: a call bar_ () call bar_ (a) end program main -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27035
[Bug tree-optimization/27022] ICE in build_polynomial_chrec, at tree-chrec.h / mpfr-2.2.0
--- Comment #3 from c dot lemmen at fz-juelich dot de 2006-04-05 07:25 --- Created an attachment (id=11210) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11210&action=view) Preprocessed source that triggers the ICE Sorry, I forgot -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27022
[Bug fortran/27035] present doesn't work on array
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-04-05 07:25 --- (In reply to comment #11) > (In reply to comment #7) > > I don't think this is defined code: > > if (present (a)) call abort () > > call foo_ (a) > > If a is not present, you should not be able to use a in any way. > > Not quite; as I recorded in PR26891 (fixed in trunk and to be fixed in 4.1 > tomorrow) I had missed that :). *** This bug has been marked as a duplicate of 26891 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27035
[Bug fortran/26891] Automatic conversion for optional parameters of missing dummies
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-04-05 07:25 --- *** Bug 27035 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26891
[Bug tree-optimization/26763] [4.1/4.2 Regression] wrong final value of induction variable calculated
--- Comment #12 from rguenth at gcc dot gnu dot org 2006-04-05 08:16 --- Subject: Bug 26763 Author: rguenth Date: Wed Apr 5 08:16:38 2006 New Revision: 112697 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112697 Log: 2006-04-05 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/26763 * fold-const.c (fold_comparison): Move folding of PTR + CST CMP PTR + CST ... (fold_binary): ... here. Fold only for EQ_EXPR and NE_EXPR. * gcc.dg/torture/pr26763-1.c: New testcase. * gcc.dg/torture/pr26763-2.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/torture/pr26763-1.c trunk/gcc/testsuite/gcc.dg/torture/pr26763-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26763
[Bug tree-optimization/26763] [4.1/4.2 Regression] wrong final value of induction variable calculated
--- Comment #13 from rguenth at gcc dot gnu dot org 2006-04-05 08:20 --- Subject: Bug 26763 Author: rguenth Date: Wed Apr 5 08:20:21 2006 New Revision: 112698 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112698 Log: 2006-04-05 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/26763 * fold-const.c (fold_binary): Fold PTR + CST CMP PTR + CST only for EQ_EXPR and NE_EXPR. * gcc.dg/torture/pr26763-1.c: New testcase. * gcc.dg/torture/pr26763-2.c: Likewise. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/torture/pr26763-1.c branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/torture/pr26763-2.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/fold-const.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26763
[Bug tree-optimization/26763] [4.1/4.2 Regression] wrong final value of induction variable calculated
--- Comment #14 from rguenth at gcc dot gnu dot org 2006-04-05 08:22 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26763
[Bug tree-optimization/27022] ICE in build_polynomial_chrec, at tree-chrec.h / mpfr-2.2.0
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-04-05 08:29 --- works for me with 20060330 and 20060404 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27022
[Bug target/26778] GCC4 moves the result of a conditional block through inadequate registers
--- Comment #3 from guillaume dot melquiond at ens-lyon dot fr 2006-04-05 08:59 --- Since the runtime slowdown between the binaries produced by GCC3 and GCC4 was not negligible, I did search a bit more for workarounds. It was quite simple in fact: passing -mno-sse produced assembly code roughly as efficient. With -mno-sse, the testcase obviously does not use any xmm register anymore. But in addition it does not use any callee-save register anymore, and hence it uses less stack space and prologue and epilogue are shorter. As a consequence, the generated code is both faster and shorter with -mno-sse. In fact, the testcase binary is even 30% shorter than if it had been produced with -Os. (The same binary is generated for both -O3 and -Os.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26778
[Bug libstdc++/26875] Array allocator use count is shared between array_allocator instances
--- Comment #9 from pcarlini at suse dot de 2006-04-05 09:41 --- (In reply to comment #8) > Here's a fix that seems to work. Agree with Paolo, this should go into > mainline > and gcc-4.1 Juyt assign the PR to yourself... ;) Maybe the copy constructor should copy _M_used? Or, you could as well remove it, AFAICS. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26875
[Bug tree-optimization/27039] New: Unable to determine # of iterations for a simple loop
With the fix for PR 26763, we are unable to determine # of iterations of the
following loop, more precisely, we are unable to determine that it rolls -- for
that, we would need to fold p_4 + 4B > p_4 + 8B.
int foo (int *p)
{
int i = 0, *x;
for (x = p; x < p + 2; x++)
i++;
return i;
}
--
Summary: Unable to determine # of iterations for a simple loop
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rakdver at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27039
[Bug libgcj/25414] should update rmic
--- Comment #4 from aph at gcc dot gnu dot org 2006-04-05 09:53 --- Subject: Bug 25414 Author: aph Date: Wed Apr 5 09:53:08 2006 New Revision: 112699 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112699 Log: 2006-04-05 Archit Shah <[EMAIL PROTECTED]> PR java/25414 * gnu/java/rmi/rmic/CompilerProcess.java (computeTypicalArguments): Add classpath argument. * gnu/java/rmi/rmic/Compile_gcj.java (computeArguments): Adjust caller. * gnu/java/rmi/rmic/Compile_jikes.java (computeArguments): Likewise. * gnu/java/rmi/rmic/Compile_kjc.java (computeArguments): Likewise. * gnu/java/rmi/rmic/Compiler.java (getClasspath, setClasspath): New. * gnu/java/rmi/rmic/RMIC.java: Set classpath for compiler, call mkdirs for destination directory, correct handling of superclasses and interfaces of the remote class, correct handling of exceptions declared by remote methods. Modified: trunk/libjava/ChangeLog trunk/libjava/gnu/java/rmi/rmic/Compile_gcj.java trunk/libjava/gnu/java/rmi/rmic/Compile_jikes.java trunk/libjava/gnu/java/rmi/rmic/Compile_kjc.java trunk/libjava/gnu/java/rmi/rmic/Compiler.java trunk/libjava/gnu/java/rmi/rmic/CompilerProcess.java trunk/libjava/gnu/java/rmi/rmic/RMIC.java -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25414
[Bug tree-optimization/27039] Unable to determine # of iterations for a simple loop
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-05 09:57 --- Confirmed. That gives us a testcase at least. Now, back to the folding problem of PTR +- CST CMP PTR +- CST where all of PTR / CST are of pointer type naturally and unsigned usually. The problem was that the frontends/middle-end introduce pointer overflow via presenting us with PTR + (unsigned)-CST. Now, we may argue that if (signed)CST is positive, that this didn't happen, and we can do the comparison in either signed or unsigned mode. Of course this won't help for p - 4 < p + 4, because this is exactly where the above condition would trigger. Does this sound reasonable? Can anyone punch a hole in this argument? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-05 09:57:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27039
[Bug tree-optimization/27039] [4.1/4.2 Regression] Unable to determine # of iterations for a simple loop
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-04-05 09:57:15 |2006-04-05 09:58:10 date|| Summary|Unable to determine # of|[4.1/4.2 Regression] Unable |iterations for a simple loop|to determine # of iterations ||for a simple loop Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27039
[Bug tree-optimization/27039] [4.1/4.2 Regression] Unable to determine # of iterations for a simple loop
--- Comment #2 from rakdver at atrey dot karlin dot mff dot cuni dot cz 2006-04-05 10:05 --- Subject: Re: Unable to determine # of iterations for a simple loop > Confirmed. That gives us a testcase at least. > > Now, back to the folding problem of > > PTR +- CST CMP PTR +- CST > > where all of PTR / CST are of pointer type naturally and unsigned usually. > The problem was that the frontends/middle-end introduce pointer overflow via > presenting us with PTR + (unsigned)-CST. Now, we may argue that if > (signed)CST > is positive, that this didn't happen, and we can do the comparison in either > signed or unsigned mode. If p points to the end of the array whose size is more than range of signed, then this would make you mistakenly consider p - size > p. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27039
[Bug tree-optimization/27039] [4.1/4.2 Regression] Unable to determine # of iterations for a simple loop
--- Comment #3 from rguenther at suse dot de 2006-04-05 10:13 --- Subject: Re: [4.1/4.2 Regression] Unable to determine # of iterations for a simple loop On Wed, 5 Apr 2006, rakdver at atrey dot karlin dot mff dot cuni dot cz wrote: > Subject: Re: Unable to determine # of iterations for a simple loop > > > Confirmed. That gives us a testcase at least. > > > > Now, back to the folding problem of > > > > PTR +- CST CMP PTR +- CST > > > > where all of PTR / CST are of pointer type naturally and unsigned usually. > > The problem was that the frontends/middle-end introduce pointer overflow via > > presenting us with PTR + (unsigned)-CST. Now, we may argue that if > > (signed)CST > > is positive, that this didn't happen, and we can do the comparison in either > > signed or unsigned mode. > > If p points to the end of the array whose size is more than range of > signed, then this would make you mistakenly consider p - size > p. Umm. Correct :/ I guess the only way to "fix" the mess is to make the frontends _not_ generate these spurious pointer overflows in the first place. Like I asked for in http://gcc.gnu.org/ml/gcc/2006-03/msg00866.html where nobody commented. :/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27039
[Bug tree-optimization/27039] [4.1/4.2 Regression] Unable to determine # of iterations for a simple loop
--- Comment #4 from rakdver at atrey dot karlin dot mff dot cuni dot cz 2006-04-05 10:20 --- Subject: Re: [4.1/4.2 Regression] Unable to determine # of iterations for a simple loop > > > Confirmed. That gives us a testcase at least. > > > > > > Now, back to the folding problem of > > > > > > PTR +- CST CMP PTR +- CST > > > > > > where all of PTR / CST are of pointer type naturally and unsigned usually. > > > The problem was that the frontends/middle-end introduce pointer overflow > > > via > > > presenting us with PTR + (unsigned)-CST. Now, we may argue that if > > > (signed)CST > > > is positive, that this didn't happen, and we can do the comparison in > > > either > > > signed or unsigned mode. > > > > If p points to the end of the array whose size is more than range of > > signed, then this would make you mistakenly consider p - size > p. > > Umm. Correct :/ I guess the only way to "fix" the mess is to make the > frontends _not_ generate these spurious pointer overflows in the first > place. Like I asked for in > > http://gcc.gnu.org/ml/gcc/2006-03/msg00866.html > > where nobody commented. :/ the problem is that it is a bit hard to avoid this. What code should we produce for signed i; char *x; x + i? In order to avoid overflows when the addition is casted to an unsigned type, we would have to translate it to (i < 0) ? x - (char *) (-i) : x + (char *) i, which would be really bad. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27039
[Bug tree-optimization/27039] [4.1/4.2 Regression] Unable to determine # of iterations for a simple loop
--- Comment #5 from rguenther at suse dot de 2006-04-05 10:28 --- Subject: Re: [4.1/4.2 Regression] Unable to determine # of iterations for a simple loop On Wed, 5 Apr 2006, rakdver at atrey dot karlin dot mff dot cuni dot cz wrote: > > Umm. Correct :/ I guess the only way to "fix" the mess is to make the > > frontends _not_ generate these spurious pointer overflows in the first > > place. Like I asked for in > > > > http://gcc.gnu.org/ml/gcc/2006-03/msg00866.html > > > > where nobody commented. :/ > > the problem is that it is a bit hard to avoid this. What code should we > produce for > > signed i; > char *x; > > x + i? > > In order to avoid overflows when the addition is casted to an > unsigned type, we would have to translate it to > (i < 0) ? x - (char *) (-i) : x + (char *) i, > which would be really bad. At the moment the C frontend does in the x + i case x + (char *)(size_t)i so, now this would be problematic for x + i < x which would then become (effectively) (size_t)i < 0 which is false even for negative i. Now, the frontend makes it worse, because for constant offsets I believe we _can_ fold if we know the constant didn't overflow. I.e. at the moment for x - 1 we get x + (char *)(size_t)-1 which is bad, instead x - (char *)(size_t)1 would be much better here. The question is of course, if the programmer is allowed to write x + (size_t)-1 and expect the result to be defined. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27039
[Bug tree-optimization/27039] [4.1/4.2 Regression] Unable to determine # of iterations for a simple loop
--- Comment #6 from rakdver at atrey dot karlin dot mff dot cuni dot cz 2006-04-05 10:39 --- Subject: Re: [4.1/4.2 Regression] Unable to determine # of iterations for a simple loop > would be much better here. The question is of course, if the programmer > is allowed to write > > x + (size_t)-1 > > and expect the result to be defined. if I understand the C standard correctly, no, this has undefined behavior. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27039
[Bug tree-optimization/27039] [4.1/4.2 Regression] Unable to determine # of iterations for a simple loop
--- Comment #7 from rguenther at suse dot de 2006-04-05 10:47 --- Subject: Re: [4.1/4.2 Regression] Unable to determine # of iterations for a simple loop > > would be much better here. The question is of course, if the programmer > > is allowed to write > > > > x + (size_t)-1 > > > > and expect the result to be defined. > > if I understand the C standard correctly, no, this has undefined behavior. This is also my understanding, so we should try to avoid creating the above in the frontends. But of course, as discussed, this doesn't solve the problem (does it, for constant offsets?). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27039
[Bug middle-end/26996] interpret_rhs_modify_expr calls fold_convert (vector_type, -1)
--- Comment #2 from spop at gcc dot gnu dot org 2006-04-05 12:33 --- Subject: Bug 26996 Author: spop Date: Wed Apr 5 12:33:06 2006 New Revision: 112700 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112700 Log: PR tree-optimization/26996 * tree-scalar-evolution.c (analyze_scalar_evolution_1): Don't analyze VECTOR_TYPE variables. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-scalar-evolution.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26996
[Bug tree-optimization/26919] [4.1/4.2 regression] ICE in cgraph_estimate_size_after_inlining with a large number of arguments
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-04-05 13:01
---
Reduced testcase, compile with --param inline-call-cost=0
struct A
{
A() {}
};
struct B
{
A a;
B(A, int) {}
};
void foo()
{
B b(A(), 0);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26919
[Bug libstdc++/27042] New: Assembler Error: symbol `_ZT' is already defined
$ ../gcc-4.1.0/configure --prefix=$HOME/opt/gcc-4.1.0.tmp --enable-languages=ada,c,c++ --with-as=$HOME/opt/binutils-2.16.1/bin/as --with-gnu-as --with-ld=$HOME/opt/binutils-2.16.1/bin/ld --with-gnu-ld --enable-bootstrap=no ... $ make ... /export/home/lbre/src/gcc-4.1.0.o/./gcc/xgcc -shared-libgcc -B/export/home/lbre/src/gcc-4.1.0.o/./gcc -nostdinc++ -L/export/home/lbre/src/gcc-4.1.0.o/sparc-sun-solaris2.8/libstdc++-v3/src -L/export/home/lbre/src/gcc-4.1.0.o/sparc-sun-solaris2.8/libstdc++-v3/src/.libs -B/export/home/lbre/opt/gcc-4.1.0.tmp/sparc-sun-solaris2.8/bin/ -B/export/home/lbre/opt/gcc-4.1.0.tmp/sparc-sun-solaris2.8/lib/ -isystem /export/home/lbre/opt/gcc-4.1.0.tmp/sparc-sun-solaris2.8/include -isystem /export/home/lbre/opt/gcc-4.1.0.tmp/sparc-sun-solaris2.8/sys-include -I/export/home/lbre/src/gcc-4.1.0.o/sparc-sun-solaris2.8/libstdc++-v3/include/sparc-sun-solaris2.8 -I/export/home/lbre/src/gcc-4.1.0.o/sparc-sun-solaris2.8/libstdc++-v3/include -I/export/home/lbre/src/gcc-4.1.0/libstdc++-v3/libsupc++ -g -O2 -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -I/export/home/lbre/src/gcc-4.1.0.o/sparc-sun-solaris2.8/libstdc++-v3/include/backward -Wno-deprecated -c ../../../../gcc-4.1.0/libstdc++-v3/src/strstream.cc -fPIC -DPIC -o .libs/strstream.o /var/tmp//cc4Gnxrh.s: Assembler messages: /var/tmp//cc4Gnxrh.s:3520: Error: symbol `_ZT' is already defined /var/tmp//cc4Gnxrh.s:5411: Error: symbol `_ZT' is already defined /var/tmp//cc4Gnxrh.s:5675: Error: symbol `_ZT' is already defined /var/tmp//cc4Gnxrh.s:7026: Error: symbol `_ZT' is already defined /var/tmp//cc4Gnxrh.s:7042: Error: symbol `_ZT' is already defined /var/tmp//cc4Gnxrh.s:7284: Error: symbol `_ZT' is already defined /var/tmp//cc4Gnxrh.s:7300: Error: symbol `_ZT' is already defined make[4]: *** [strstream.lo] Error 1 make[4]: Leaving directory `/export/home/lbre/src/gcc-4.1.0.o/sparc-sun-solaris2.8/libstdc++-v3/src' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/export/home/lbre/src/gcc-4.1.0.o/sparc-sun-solaris2.8/libstdc++-v3' make[2]: *** [all] Error 2 make[2]: Leaving directory `/export/home/lbre/src/gcc-4.1.0.o/sparc-sun-solaris2.8/libstdc++-v3' make[1]: *** [all-target-libstdc++-v3] Error 2 make[1]: Leaving directory `/export/home/lbre/src/gcc-4.1.0.o' make: *** [all] Error 2 As can be seen from the configure options, this is with GNU binutils 2.16.1. I also tried the Sun assembler and linker, and get similar errors but thousands of times instead of just 7. Complete logs available on request (1.2 Mb for GNU as/ld, 91 Mb for Sun as/ld; respectively 54k and 2553k compressed with bzip2). Am I doing something wrong? (--enable-bootstrap=yes gives the same errors). Incidentally, the options mention /export/home/lbre/opt/gcc-4.1.0.tmp/sparc-sun-solaris2.8/ in four places (-B and -isystem options) but this is incorrect because that directory does not exist yet. I don't think the bootstrap procedure should ever refer to the install directory, except when installing. Is this worth another PR? -- Ludovic Brenta. -- Summary: Assembler Error: symbol `_ZT' is already defined Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ludovic at ludovic-brenta dot org GCC build triplet: sparc-sun-solaris2.8 GCC host triplet: sparc-sun-solaris2.8 GCC target triplet: sparc-sun-solaris2.8 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27042
[Bug java/27025] ICE on simple initializer
--- Comment #5 from aph at gcc dot gnu dot org 2006-04-05 13:19 --- I don't think this is a regression. [EMAIL PROTECTED] ~]$ ~/gcc/install-4.0/bin/gcj -C z.java z.java: In class 'z': z.java: In method 'z.main(java.lang.String[])': z.java:9: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. zapata:~ $ /usr/bin/gcj -v gcc version 3.4.5 20051201 (Red Hat 3.4.5-2) zapata:~ $ /usr/bin/gcj -C z.java z.java: In class `z': z.java: In method `z.main(java.lang.String[])': z.java:9: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://bugzilla.redhat.com/bugzilla> for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27025
[Bug fortran/26891] Automatic conversion for optional parameters of missing dummies
--- Comment #6 from hjl at gcc dot gnu dot org 2006-04-05 13:23 --- Subject: Bug 26891 Author: hjl Date: Wed Apr 5 13:23:35 2006 New Revision: 112701 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112701 Log: Correct PR number in ChangeLogs. gcc/fortran/ 2006-04-03 Paul Thomas <[EMAIL PROTECTED]> PR fortran/26891 * trans.h : Prototype for gfc_conv_missing_dummy. * trans-expr (gfc_conv_missing_dummy): New function (gfc_conv_function_call): Call it and tidy up some of the code. * trans-intrinsic (gfc_conv_intrinsic_function_args): The same. gcc/testsuite/ 2006-04-03 Paul Thomas <[EMAIL PROTECTED]> PR fortran/26891 * gfortran.dg/missing_optional_dummy_1.f90: New test. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26891
[Bug tree-optimization/26919] [4.1/4.2 regression] ICE in cgraph_estimate_size_after_inlining with a large number of arguments
--- Comment #11 from rguenth at gcc dot gnu dot org 2006-04-05 13:29 --- I have a fix. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-03-29 19:37:36 |2006-04-05 13:29:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26919
[Bug libstdc++/27042] Assembler Error: symbol `_ZT' is already defined
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2006-04-05 13:35 --- > As can be seen from the configure options, this is with GNU > binutils 2.16.1. What's the configure shell? What's the version of GNU make? What's the bootstrap compiler? > I also tried the Sun assembler and linker, and get similar errors > but thousands of times instead of just 7. Complete logs available > on request (1.2 Mb for GNU as/ld, 91 Mb for Sun as/ld; respectively > 54k and 2553k compressed with bzip2). Both sets of tools are known to work with GCC 4.1.0 on SPARC/Solaris 8. > Am I doing something wrong? What happens if you bootstrap the compiler (make bootstrap instead of make)? -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27042
[Bug middle-end/26996] interpret_rhs_modify_expr calls fold_convert (vector_type, -1)
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-04-05 13:42 --- Fixed on the mainline - this problem is latent in 4.1, can you commit this obviously safe patch there, too (though techically it might not be a regression)? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to work||4.2.0 Last reconfirmed|-00-00 00:00:00 |2006-04-05 13:42:38 date|| Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26996
[Bug middle-end/26898] Fold does not fold signed + CST1 CMP signed + CST2
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-04-05 13:47 --- This is mine. And I have a patch posted. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-03-30 21:49:44 |2006-04-05 13:47:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26898
[Bug bootstrap/27042] Assembler Error: symbol `_ZT' is already defined
--- Comment #2 from ludovic at ludovic-brenta dot org 2006-04-05 13:47 --- $ make --version GNU Make 3.80 Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ $SHELL --version GNU bash, version 2.03.0(1)-release (sparc-sun-solaris) Copyright 1998 Free Software Foundation, Inc. $ gcc --version 2.8.1 (that's from GNAT 3.15p, binary distribution from AdaCore; but the compiler used to build strstream.cc is ./xgcc, i.e. GCC 4.1.0 built in stage1. And, as I said, the same errors occur with --enable-bootstrap=yes, so I can confidently say that the bootstrap compiler is irrelevant). I've started the "make bootstrap" and will report later. To speed it up I've only passed --enable-languages=c,c++. -- Ludovic Brenta. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27042
[Bug middle-end/24556] gcc can't inline functions using setjmp
--- Comment #11 from rguenth at gcc dot gnu dot org 2006-04-05 13:48 --- I'm not working on this. Re-closing as WONTFIX. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24556
[Bug middle-end/25186] (short)(((int)short_var) <<1) should be folded so that the shift is done in the short type
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-04-05 13:49 --- I'm no longer working on this. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|rguenth at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25186
[Bug middle-end/26898] Fold does not fold signed + CST1 CMP signed + CST2
--- Comment #5 from patchapp at dberlin dot org 2006-04-05 13:50 --- Subject: Bug number PR26898 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-04/msg00190.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26898
/usr/src/sys/net80211/ieee80211_node.c:175: internal compiler error: Segmentation fault: 11
root: gcc -v Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.4.4 [FreeBSD] 20050518 root: uname -a FreeBSD ws3-plovdiv.digsys.bg 6.1-PRERELEASE FreeBSD 6.1-PRERELEASE #0: Wed Mar 22 20:44:32 EET 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/IBsec i386 root: cc -c -O2 -pipe -funroll-loops -ffast-math -fno-strict-aliasing -march=pentium3 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/pf -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -I/usr/src/sys/contrib/ngatm -I/usr/src/sys/dev/twa -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror /usr/src/sys/net80211/ieee80211_node.c /usr/src/sys/net80211/ieee80211_node.c: In function `ieee80211_node_lateattach': /usr/src/sys/net80211/ieee80211_node.c:175: internal compiler error: Segmentation fault: 11 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. *** Error code 1 Stop in /usr/obj/usr/src/sys/IBsec. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Best regards, Valentin ChernoZemsky __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
[Bug bootstrap/27042] Assembler Error: symbol `_ZT' is already defined
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2006-04-05 13:57 --- > (that's from GNAT 3.15p, binary distribution from AdaCore; but the > compiler used to build strstream.cc is ./xgcc, i.e. GCC 4.1.0 > built in stage1. And, as I said, the same errors occur with > --enable-bootstrap=yes, so I can confidently say that the > bootstrap compiler is irrelevant). --enable-bootstrap=yes has not been tested with GCC 4.1.x so I'd avoid it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27042
[Bug middle-end/26565] [4.0/4.1 Regression] Unaligned accesses with __attribute__(packed) and memcpy
--- Comment #12 from patchapp at dberlin dot org 2006-04-05 14:00 --- Subject: Bug number PR26565 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-04/msg00192.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26565
[Bug other/27043] New: building Ada rts does not find 'as'
Building on Windows XPSP2, NTFS file system using MSYS 1.0.10. If I don't specify --with-as to configure, the compilers (all) build well until stage3. Only when the stage3 compiler starts building the Ada run time system, it cannot find 'as' anymore: rm -f ../stamp-gnatlib touch ../stamp-gnatlib1 make -C rts \ CC="`echo \"./xgcc -B./ \" \ | sed -e 's,^\./xgcc,../../xgcc,' -e 's,-B\./,-B../../,'`" \ INCLUDES="-I. -I.. -I../.. -I/d/Data/Development/gcc-cvs/gcc-4.1.0/gcc/ada -I/d/Data/Development/gcc-cvs/gcc-4.1.0/gcc/ada/../config -I/d/Data/Development/gcc-cvs/gcc-4.1.0/gcc/ada/../../include -I/d/Data/Development/gcc-cvs/gcc-4.1.0/gcc/ada/.. -I./../.." \ CFLAGS="-g -O2 -fexceptions -DIN_RTS" \ srcdir=/d/Data/Development/gcc-cvs/gcc-4.1.0/gcc/ada \ -f ../Makefile adaint.o argv.o cio.o cstreams.o ctrl_c.o errno.o exit.o raise.o sysdep.o aux-io.o init.o initialize.o seh_init.o cal.o final.o tracebak.o expect.o mkdir.o socket.o raise-gcc.o make[7]: Entering directory `/d/Data/Development/gcc-cvs/build_4.1.0/gcc/ada/rts' ../../xgcc -B../../ -c -DIN_GCC `echo -g -O2 -fexceptions -DIN_RTS |sed -e 's/-pedantic//g' -e 's/-Wtraditional//g'` -I. -I.. -I../.. -I/d/Data/Development/gcc-cvs/gcc-4.1.0/gcc/ada -I/d/Data/Development/gcc-cvs/gcc-4.1.0/gcc/ada/../config -I/d/Data/Development/gcc-cvs/gcc-4.1.0/gcc/ada/../../include -I/d/Data/Development/gcc-cvs/gcc-4.1.0/gcc/ada/.. -I./../.. adaint.c \ -o adaint.o ..\..\as: ..\..\as: No such file or directory make[7]: *** [adaint.o] Error 1 make[7]: Leaving directory `/d/Data/Development/gcc-cvs/build_4.1.0/gcc/ada/rts' make[6]: *** [gnatlib] Error 2 make[6]: Leaving directory `/d/Data/Development/gcc-cvs/build_4.1.0/gcc/ada' make[5]: *** [gnatlib-shared-win32] Error 2 make[5]: Leaving directory `/d/Data/Development/gcc-cvs/build_4.1.0/gcc/ada' make[4]: *** [gnatlib-shared] Error 2 make[4]: Leaving directory `/d/Data/Development/gcc-cvs/build_4.1.0/gcc/ada' make[3]: *** [gnatlib-shared] Error 2 make[3]: Leaving directory `/d/Data/Development/gcc-cvs/build_4.1.0/mingw32/libada' make[2]: *** [all-target-libada] Error 2 make[2]: Leaving directory `/d/Data/Development/gcc-cvs/build_4.1.0' make[1]: *** [all] Error 2 make[1]: Leaving directory `/d/Data/Development/gcc-cvs/build_4.1.0' make: *** [bootstrap] Error 2 The MinGW/MSYS maintainers suggested a bug report here rather than in MinGW bug-db. Rolf -- Summary: building Ada rts does not find 'as' Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rolf dot ebert dot gcc at gmx dot de GCC build triplet: mingw32 GCC host triplet: mingw32 GCC target triplet: mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27043
[Bug java/27025] ICE on simple initializer
--- Comment #6 from aph at gcc dot gnu dot org 2006-04-05 14:12 ---
As far as I can see this bug is in every version of gcj that has ever existed.
There is special code (in merge_string_cste()) to convert an integer constant
to a constant string for concatenation. However, there isn't any code to
convert a floating-point constant to a constant string.
It would be fairly simple to call real_to_decimal() on the floating-point
number, but that function doesn't do Java-style floating-point formatting. We
could add full Java-style floating-point output conversion to gcj, but I don't
think it would be worth the effort.
My proposed fix, although technically imperfect, cures 99% of the cases we are
ever likely to encounter. It fails to fix weird cases like:
switch(x) { case 0: break;
case ("foo" + 2) == "foo2": break;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27025
[Bug rtl-optimization/27044] New: Loop variables incorrectly initialized with optimization on
In the following code, in the loop at line 381 of jtagmkII.c (line 2586 of the attached jtagmkII.i), msglen (and l, as I recall) contain incorrect values. This only happens when optimization is turned on (-O2); it does not happen with -O1. The code runs correctly when compiled with gcc-3.3 using optimization. -- Summary: Loop variables incorrectly initialized with optimization on Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ned at bike-nomad dot com GCC build triplet: powerpc-apple-darwin8 GCC host triplet: powerpc-apple-darwin8 GCC target triplet: powerpc-apple-darwin8 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27044
[Bug rtl-optimization/27044] Loop variables incorrectly initialized with optimization on
--- Comment #1 from ned at bike-nomad dot com 2006-04-05 14:17 --- Created an attachment (id=11211) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11211&action=view) Preprocessed source demonstrating bug Bug is at line 2585/2586 of attached file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27044
[Bug rtl-optimization/27044] Loop variables incorrectly initialized with optimization on
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-04-05 14:26 --- It's hard to verify with this big (non-executable) testcase. Is there a chance you can strengthen your claim? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27044
[Bug c++/27045] New: c++ is generating incorrect optimized code for xor operations on long long
c++ is generating incorrect optimized code for xor operations on long long.
Version which is affected is:
g++ (GCC) 4.0.2 20051125 (Red Hat 4.0.2-8)
Following (proper) code is inlined into bad assembly when optimization is
turned on:
namespace __gnu_cxx
{
/**
hash specialization for uint64
*/
template <>
class hash
{
public:
size_t operator()(uint64 const & number) const
{
hash uint32Hasher;
uint32 const *p = (uint32 *)&number;
return uint32Hasher(p[0]) ^ uint32Hasher(p[1]);
}
};
/**
hash specialization for RequestId
*/
template<>
class hash
{
public:
size_t operator()(RequestId const & requestId) const
{
hash uint64Hasher;
return uint64Hasher(requestId.getV1()) ^
uint64Hasher(requestId.getV2());
}
};
}
Part of bad assembly:
call_ZNK9RequestId5getV1Ev
movl-20(%ebp), %ebx
movl%esi, (%esp)
movl%eax, -24(%ebp)
movl-24(%ebp), %eax
movl%edx, -20(%ebp)
xorl%eax, %ebx
call_ZNK9RequestId5getV2Ev
movl-16(%ebp), %ecx
movl%eax, -16(%ebp)
movl-12(%ebp), %eax
movl%edx, -12(%ebp)
xorl%ecx, %eax
and it probably should be something like:
call_ZNK9RequestId5getV1Ev
movl%eax, -24(%ebp)
movl%edx, -20(%ebp)
movl-20(%ebp), %ebx
movl%esi, (%esp)
movl-24(%ebp), %eax
xorl%eax, %ebx
call_ZNK9RequestId5getV2Ev
movl%eax, -16(%ebp)
movl%edx, -12(%ebp)
movl-16(%ebp), %ecx
movl-12(%ebp), %eax
xorl%ecx, %eax
It seems that compiler reads values from stack before setting them after call
to getV1() or getV2().
Bug shows up only when optimization is turned on.
I am attaching simple demo program which should run when optimization is set to
0 and crash when it is set to 2 or 3.
--
Summary: c++ is generating incorrect optimized code for xor
operations on long long
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: l_heldt at poczta dot onet dot pl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27045
[Bug c++/27045] c++ is generating incorrect optimized code for xor operations on long long
--- Comment #1 from l_heldt at poczta dot onet dot pl 2006-04-05 15:17 --- Created an attachment (id=11212) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11212&action=view) File containing hash specifications -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27045
[Bug c++/27045] c++ is generating incorrect optimized code for xor operations on long long
--- Comment #2 from l_heldt at poczta dot onet dot pl 2006-04-05 15:17 --- Created an attachment (id=11213) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11213&action=view) Implementation of RequestId -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27045
[Bug c++/27045] c++ is generating incorrect optimized code for xor operations on long long
--- Comment #3 from l_heldt at poczta dot onet dot pl 2006-04-05 15:18 --- After compilation: g++ test.cpp req.cpp -O0 program works fine. After compilation with: g++ test.cpp req.cpp -O2 it breaks with SIGABRT. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27045
[Bug classpath/27028] Iterator.hasNext() throws ConcurrentModificationException
--- Comment #5 from mckinlay at redhat dot com 2006-04-05 15:19 --- (In reply to comment #4) > I would argue that Sun's implementation is correct in this case in the > sense that hasNext() doesn't actually modify anything, only next() does. Yeah, I agree - although you might get a bogus answer for hasNext(), 99% of the time, the application is about to call next(), so they'll get the exception there anyway. Changing this also gives a slight performance improvement for iterators. This bug seems to be coming up pretty regularly. I'm working on a patch and test case for it. -- mckinlay at redhat dot com changed: What|Removed |Added AssignedTo|mckinlay at redhat dot com |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27028
[Bug classpath/27028] Iterator.hasNext() throws ConcurrentModificationException
-- mckinlay at redhat dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mckinlay at redhat dot com |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-04-04 20:34:07 |2006-04-05 15:20:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27028
[Bug bootstrap/27042] Assembler Error: symbol `_ZT' is already defined
--- Comment #4 from ludovic at ludovic-brenta dot org 2006-04-05 15:21 --- --enable-bootstrap=no + "make bootstrap" cause a successful build: ... /export/home/lbre/src/gcc-4.1.0.bootstrap/./gcc/xgcc -shared-libgcc -B/export/home/lbre/src/gcc-4.1.0.bootstrap/./gcc -nostdinc++ -L/export/home/lbre/src/gcc-4.1.0.bootstrap/sparc-sun-solaris2.8/libstdc++-v3/src -L/export/home/lbre/src/gcc-4.1.0.bootstrap/sparc-sun-solaris2.8/libstdc++-v3/src/.libs -B/export/home/lbre/opt/gcc-4.1.0-bootstrap/sparc-sun-solaris2.8/bin/ -B/export/home/lbre/opt/gcc-4.1.0-bootstrap/sparc-sun-solaris2.8/lib/ -isystem /export/home/lbre/opt/gcc-4.1.0-bootstrap/sparc-sun-solaris2.8/include -isystem /export/home/lbre/opt/gcc-4.1.0-bootstrap/sparc-sun-solaris2.8/sys-include -I/export/home/lbre/src/gcc-4.1.0.bootstrap/sparc-sun-solaris2.8/libstdc++-v3/include/sparc-sun-solaris2.8 -I/export/home/lbre/src/gcc-4.1.0.bootstrap/sparc-sun-solaris2.8/libstdc++-v3/include -I/export/home/lbre/src/gcc-4.1.0/libstdc++-v3/libsupc++ -g -O2 -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -I/export/home/lbre/src/gcc-4.1.0.bootstrap/sparc-sun-solaris2.8/libstdc++-v3/include/backward -Wno-deprecated -c ../../../../gcc-4.1.0/libstdc++-v3/src/strstream.cc -fPIC -DPIC -o .libs/strstream.o /export/home/lbre/src/gcc-4.1.0.bootstrap/./gcc/xgcc -shared-libgcc -B/export/home/lbre/src/gcc-4.1.0.bootstrap/./gcc -nostdinc++ -L/export/home/lbre/src/gcc-4.1.0.bootstrap/sparc-sun-solaris2.8/libstdc++-v3/src -L/export/home/lbre/src/gcc-4.1.0.bootstrap/sparc-sun-solaris2.8/libstdc++-v3/src/.libs -B/export/home/lbre/opt/gcc-4.1.0-bootstrap/sparc-sun-solaris2.8/bin/ -B/export/home/lbre/opt/gcc-4.1.0-bootstrap/sparc-sun-solaris2.8/lib/ -isystem /export/home/lbre/opt/gcc-4.1.0-bootstrap/sparc-sun-solaris2.8/include -isystem /export/home/lbre/opt/gcc-4.1.0-bootstrap/sparc-sun-solaris2.8/sys-include -I/export/home/lbre/src/gcc-4.1.0.bootstrap/sparc-sun-solaris2.8/libstdc++-v3/include/sparc-sun-solaris2.8 -I/export/home/lbre/src/gcc-4.1.0.bootstrap/sparc-sun-solaris2.8/libstdc++-v3/include -I/export/home/lbre/src/gcc-4.1.0/libstdc++-v3/libsupc++ -g -O2 -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -I/export/home/lbre/src/gcc-4.1.0.bootstrap/sparc-sun-solaris2.8/libstdc++-v3/include/backward -Wno-deprecated -c ../../../../gcc-4.1.0/libstdc++-v3/src/strstream.cc -o strstream.o >/dev/null 2>&1 (no output) The bootstrap then completes successfully. So: "make" fails, "make bootstrap" works, but the commands invoked are identical. Could it be that gcc 2.8.1 silently miscompiled cc1plus in the case of "make", and introduced an obscure bug which only strstream.cc triggers? -- Ludovic Brenta. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27042
[Bug classpath/24632] java.util.HashMap$HashIterator.hasNext throws ConcurrentModificationException
--- Comment #6 from mckinlay at redhat dot com 2006-04-05 15:22 --- *** This bug has been marked as a duplicate of 27028 *** -- mckinlay at redhat dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24632
[Bug classpath/27028] Iterator.hasNext() throws ConcurrentModificationException
--- Comment #6 from mckinlay at redhat dot com 2006-04-05 15:22 --- *** Bug 24632 has been marked as a duplicate of this bug. *** -- mckinlay at redhat dot com changed: What|Removed |Added CC||gnuclasspath dot 10 dot ||bertnase at spamgourmet dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27028
[Bug fortran/27046] New: gfortran print flush in dll
PRINT* in gfortran 4.2.0 compiled dll's needs CALL FLUSH to perform correctly
when called from gcc (3.4.2, 3.4.5, 4.1) compiled main. Reproducible sample:
$ gfortran -shared -o ftesti.dll ftesti.f90
ftesti.f90:
---
subroutine print_from_gfortran(txt)
implicit none
character :: txt
print *,txt
end subroutine print_from_gfortran
$ gcc -o ctesti.exe ctesti.c
ctesti.c:
-
#include
#include
void print_from_gcc(char* txt) {
printf("%s\n",txt);
}
int main(int argc, char** argv) {
HINSTANCE handle=LoadLibrary("ftesti.dll");
FARPROC print_from_gfortran=GetProcAddress(handle,"print_from_gfortran_");
print_from_gcc ("c");
print_from_gfortran("f");
print_from_gcc ("c");
print_from_gfortran("f");
return 0;
}
Now, running ctesti.exe produces
c
c
f
f
Correct output should be
c
f
c
f
Adding CALL FLUSH in ftesti.f90 fixes the case:
ftesti.f90:
---
subroutine print_from_gfortran(txt)
implicit none
character :: txt
print *,txt
call flush
end subroutine print_from_gfortran
--
Summary: gfortran print flush in dll
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikko dot lyly at csc dot fi
GCC host triplet: i686-pc-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27046
[Bug tree-optimization/26919] [4.1/4.2 regression] ICE in cgraph_estimate_size_after_inlining with a large number of arguments
--- Comment #12 from rguenth at gcc dot gnu dot org 2006-04-05 15:41 --- Subject: Bug 26919 Author: rguenth Date: Wed Apr 5 15:41:18 2006 New Revision: 112709 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112709 Log: 2006-04-05 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/26919 * ipa-inline.c (cgraph_decide_inlining_incrementally): Fix argument to cgraph_estimate_size_after_inlining. * gcc.dg/ipa/ipa-1.c: Use -fno-early-inlining. * gcc.dg/ipa/ipa-2.c: Likewise. * gcc.dg/ipa/ipa-3.c: Likewise. * gcc.dg/ipa/ipa-5.c: Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-inline.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/ipa/ipa-1.c trunk/gcc/testsuite/gcc.dg/ipa/ipa-2.c trunk/gcc/testsuite/gcc.dg/ipa/ipa-3.c trunk/gcc/testsuite/gcc.dg/ipa/ipa-5.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26919
[Bug tree-optimization/26919] [4.1 regression] ICE in cgraph_estimate_size_after_inlining with a large number of arguments
--- Comment #13 from rguenth at gcc dot gnu dot org 2006-04-05 15:44 --- Fixed on the mainline. Let's wait if the changed inlining causes regressions before backporting. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to work||4.2.0 Summary|[4.1/4.2 regression] ICE in |[4.1 regression] ICE in |cgraph_estimate_size_after_i|cgraph_estimate_size_after_i |nlining with a large number |nlining with a large number |of arguments|of arguments http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26919
[Bug bootstrap/27042] Assembler Error: symbol `_ZT' is already defined
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2006-04-05 15:47 --- > The bootstrap then completes successfully. Wunderbar. :-) > So: "make" fails, "make bootstrap" works, but the commands > invoked are identical. Could it be that gcc 2.8.1 silently > miscompiled cc1plus in the case of "make", and introduced an > obscure bug which only strstream.cc triggers? Most likely, yes; --enable-bootstrap=yes should have worked around the problem, but it may have its own problems in 4.1.x. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27042
[Bug fortran/27047] New: gfortran print flush in dll
PRINT* in gfortran 4.2.0 compiled dll's needs CALL FLUSH to perform correctly
when called from gcc (3.4.2, 3.4.5, 4.1) compiled main. Reproducible sample:
$ gfortran -shared -o ftesti.dll ftesti.f90
ftesti.f90:
---
subroutine print_from_gfortran(txt)
implicit none
character :: txt
print *,txt
end subroutine print_from_gfortran
$ gcc -o ctesti.exe ctesti.c
ctesti.c:
-
#include
#include
void print_from_gcc(char* txt) {
printf("%s\n",txt);
}
int main(int argc, char** argv) {
HINSTANCE handle=LoadLibrary("ftesti.dll");
FARPROC print_from_gfortran=GetProcAddress(handle,"print_from_gfortran_");
print_from_gcc ("c");
print_from_gfortran("f");
print_from_gcc ("c");
print_from_gfortran("f");
return 0;
}
Now, running ctesti.exe produces
c
c
f
f
Correct output should be
c
f
c
f
Adding CALL FLUSH in ftesti.f90 fixes the case:
ftesti.f90:
---
subroutine print_from_gfortran(txt)
implicit none
character :: txt
print *,txt
call flush
end subroutine print_from_gfortran
--
Summary: gfortran print flush in dll
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikko dot lyly at csc dot fi
GCC host triplet: i686-pc-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27047
Re: [Bug c++/27045] c++ is generating incorrect optimized code for xor operations on long long
All, Not a bug, this is yet another case of type pruning. Use -fno-strict-aliasing or fix your code. Graham
[Bug c++/27045] c++ is generating incorrect optimized code for xor operations on long long
--- Comment #4 from graham dot stott at btinternet dot com 2006-04-05 16:00 --- Subject: Re: c++ is generating incorrect optimized code for xor operations on long long All, Not a bug, this is yet another case of type pruning. Use -fno-strict-aliasing or fix your code. Graham -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27045
Re: [Bug c++/27045] c++ is generating incorrect optimized code for xor operations on long long
All, Not a bug, this is yet another case of type pruning. Use -fno-strict-aliasing or fix your code. Graham
[Bug c++/27045] c++ is generating incorrect optimized code for xor operations on long long
--- Comment #5 from graham dot stott at btinternet dot com 2006-04-05 16:00 --- Subject: Re: c++ is generating incorrect optimized code for xor operations on long long All, Not a bug, this is yet another case of type pruning. Use -fno-strict-aliasing or fix your code. Graham -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27045
[Bug fortran/27047] gfortran print flush in dll
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-05 16:02 --- *** This bug has been marked as a duplicate of 27046 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27047
[Bug fortran/27046] gfortran print flush in dll
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-05 16:02 --- *** Bug 27047 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27046
[Bug tree-optimization/8781] Pessimization of C++ (functional) code
--- Comment #20 from rguenth at gcc dot gnu dot org 2006-04-05 16:05 --- Because they are not the same: (gdb) call debug_generic_expr(0xb7e31c94) struct noop_tD.2008 (gdb) call debug_generic_expr(0xb7e3505c) struct noop_tD.2008 generated by #0 build1_stat (code=NOP_EXPR, type=0xb7e3505c, node=0xb7d843c8) at /space/rguenther/src/svn/gcc/gcc/tree.c:2779 #1 0x085440ad in fold_build1_stat (code=NOP_EXPR, type=0xb7e3505c, op0=0xb7d843c8) at /space/rguenther/src/svn/gcc/gcc/fold-const.c:11099 #2 0x084eaf25 in fold_convert (type=0xb7e3505c, arg=0xb7d843c8) at /space/rguenther/src/svn/gcc/gcc/fold-const.c:1996 #3 0x0828659b in setup_one_parameter (id=0xbfffeb54, p=0xb7e38000, value=0xb7d843c8, fn=0xb7e37100, bb=0xb7e400a0, vars=0xbfffe924) at /space/rguenther/src/svn/gcc/gcc/tree-inline.c:1069 #4 0x0828692e in initialize_inlined_parameters (id=0xbfffeb54, args=0xb7e36468, static_chain=0x0, fn=0xb7e37100, bb=0xb7e400a0) at /space/rguenther/src/svn/gcc/gcc/tree-inline.c:1125 #5 0x08289168 in expand_call_inline (bb=0xb7e400a0, stmt=0xb7d7f1b0, tp=0xb7d7f1d0, data=0xbfffeb54) (gdb) call cxx_types_compatible_p (0xb7e31c94, 0xb7e3505c) $1 = 1 (gdb) call debug_tree(0xb7e31c94) needs-constructing type_1 type_5 type_6 SI size constant invariant 32> unit size constant invariant 4> align 32 symtab 0 alias set -1 fields unsigned SI size unit size align 32 symtab 0 alias set -1> readonly used private unsigned nonlocal decl_3 SI file t.C line 5 size unit size align 32 offset_align 128 offset bit offset context > chain > external nonlocal suppress-debug decl_4 VOID file t.C line 4 align 8 context > >> needs-constructor X(constX&) this=(X&) n_parents=0 use_template=1 interface-unknown pointer_to_this chain >> (gdb) call debug_tree(0xb7e3505c) readonly needs-constructing type_1 type_5 SI size constant invariant 32> unit size constant invariant 4> align 32 symtab 0 alias set -1 fields unsigned SI size unit size align 32 symtab 0 alias set -1> readonly used private unsigned nonlocal decl_3 SI file t.C line 5 size unit size align 32 offset_align 128 offset bit offset context > chain > external nonlocal suppress-debug decl_4 VOID file t.C line 4 align 8 context > >> needs-constructor X(constX&) this=(X&) n_parents=0 use_template=1 interface-unknown pointer_to_this reference_to_this > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8781
[Bug libfortran/27046] gfortran print flush in dll
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-05 16:08 --- This was fixed for the non windows case for sure. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|fortran |libfortran GCC host triplet|i686-pc-mingw32 | GCC target triplet||i686-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27046
[Bug c++/8781] Pessimization of C++ (functional) code
--- Comment #21 from rguenth at gcc dot gnu dot org 2006-04-05 16:11 --- The main difference is the TYPE_DEPENDENT_P_VALID valid lang-type flag. So this looks like a frontend problem. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|tree-optimization |c++ Last reconfirmed|2005-10-09 16:47:55 |2006-04-05 16:11:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8781
[Bug c++/27045] c++ is generating incorrect optimized code for xor operations on long long
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-04-05 16:13 --- *** This bug has been marked as a duplicate of 21920 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27045
[Bug c/21920] alias violating
--- Comment #90 from pinskia at gcc dot gnu dot org 2006-04-05 16:13 --- *** Bug 27045 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||l_heldt at poczta dot onet ||dot pl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21920
[Bug middle-end/26996] interpret_rhs_modify_expr calls fold_convert (vector_type, -1)
--- Comment #4 from spop at gcc dot gnu dot org 2006-04-05 17:25 --- Subject: Bug 26996 Author: spop Date: Wed Apr 5 17:25:26 2006 New Revision: 112711 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112711 Log: PR tree-optimization/26996 * tree-scalar-evolution.c (analyze_scalar_evolution_1): Don't analyze VECTOR_TYPE variables. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/tree-scalar-evolution.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26996
[Bug middle-end/26996] interpret_rhs_modify_expr calls fold_convert (vector_type, -1)
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-04-05 17:29 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26996
[Bug tree-optimization/27022] ICE in build_polynomial_chrec, at tree-chrec.h / mpfr-2.2.0
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-04-05 18:25 --- This was fixed by the patch which fixed PR 26992 so closing as a dup of that bug. *** This bug has been marked as a duplicate of 26992 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27022
[Bug tree-optimization/26992] [4.2 Regression] Internal Compiler Error in dwarf2out.c:7607 build_polynomial_chrec
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-04-05 18:25 --- *** Bug 27022 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||c dot lemmen at fz-juelich ||dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26992
[Bug rtl-optimization/27044] Loop variables incorrectly initialized with optimization on
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-05 18:27 --- Can you try 4.0.3? Otherwise just report this to Apple instead as you are using Apple's hacked up Compiler. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27044
[Bug tree-optimization/27004] [4.1/4.2 Regression] Insane amount of memory needed at -O1 and above because of salias and large switch
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.1/4.2 Regression] Insane |[4.1/4.2 Regression] Insane |amount of memory needed at -|amount of memory needed at - |O1 and above because of |O1 and above because of |salias |salias and large switch Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27004
[Bug tree-optimization/26948] ICE: tree check: expected ssa_name, with -ftree-vectorize
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-05 18:38 --- Yes this is a dup of bug 26197. *** This bug has been marked as a duplicate of 26197 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26948
[Bug tree-optimization/26197] [4.2 regression] ICE in is_old_name with vectorizer
--- Comment #16 from pinskia at gcc dot gnu dot org 2006-04-05 18:38 --- *** Bug 26948 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||micis at gmx dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26197
[Bug classpath/27028] Iterator.hasNext() throws ConcurrentModificationException
--- Comment #7 from bryce at gcc dot gnu dot org 2006-04-05 18:41 --- Subject: Bug 27028 Author: bryce Date: Wed Apr 5 18:41:17 2006 New Revision: 112714 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112714 Log: 2006-04-05 Bryce McKinlay <[EMAIL PROTECTED]> PR classpath/27028 PR classpath/24752 * java/util/AbstractList.java (hasNext): Don't throw ConcurrentModificationException. Update Javadoc. (hasPrevious): Likewise. (nextIndex): Likewise. (previousIndex): Likewise. * java/util/HashMap.java (hasNext): Likewise. * java/util/Hashtable.java (hasNext): Likewise. * java/util/IdentityHashMap.java (hasNext): Likewise. * java/util/LinkedHashMap.java (hasNext): Likewise. * java/util/LinkedList.java (nextIndex): Likewise. (previousIndex): Likewise. (hasNext): Likewise. (hasPrevious): Likewise. * java/util/TreeMap.java (hasNext): Likewise. * java/util/WeakHashMap.java (hasNext): Likewise. Modified: branches/gcc-4_1-branch/libjava/classpath/ChangeLog.gcj branches/gcc-4_1-branch/libjava/classpath/java/util/AbstractList.java branches/gcc-4_1-branch/libjava/classpath/java/util/HashMap.java branches/gcc-4_1-branch/libjava/classpath/java/util/Hashtable.java branches/gcc-4_1-branch/libjava/classpath/java/util/IdentityHashMap.java branches/gcc-4_1-branch/libjava/classpath/java/util/LinkedHashMap.java branches/gcc-4_1-branch/libjava/classpath/java/util/LinkedList.java branches/gcc-4_1-branch/libjava/classpath/java/util/TreeMap.java branches/gcc-4_1-branch/libjava/classpath/java/util/WeakHashMap.java -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27028
[Bug libgcj/27024] Implement URLConnection.getFileNameMap
--- Comment #1 from tromey at gcc dot gnu dot org 2006-04-05 18:43 --- Subject: Bug 27024 Author: tromey Date: Wed Apr 5 18:43:15 2006 New Revision: 112715 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112715 Log: libjava/classpath: PR libgcj/27024: * java/net/MimeTypeMapper.java (getContentTypeFor): Fall back to MimeTypes. libjava: PR libgcj/27024: * java/net/URLConnection.java (guessContentTypeFromName): Rewrote, using Classpath implementation. (getFileNameMap): Likewise. (guessContentTypeFromStream): Return application/octet-stream. Modified: branches/gcc-4_1-branch/libjava/ChangeLog branches/gcc-4_1-branch/libjava/classpath/ChangeLog.gcj branches/gcc-4_1-branch/libjava/classpath/java/net/MimeTypeMapper.java branches/gcc-4_1-branch/libjava/java/net/URLConnection.java -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27024
[Bug classpath/27028] Iterator.hasNext() throws ConcurrentModificationException
--- Comment #8 from mckinlay at redhat dot com 2006-04-05 18:43 --- Fix checked in to Classpath HEAD and gcc-4_1_branch -- mckinlay at redhat dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27028
Mp3 e Bluetooth!
Novita' assoluta!Nuovissimi occhiali da sole con lettore/registratore MP3 incorporato ed i fantastici occhiali con BLUETOOTH incorporato! Per ascoltare la Vs. musica preferita e per telefonare a mani libere completamente SENZA CAVI!!!Per vedere questi gioielli tecnologici clicchi su; http://1go.it/5va o su http://occhiali.tux.nu/ Cordiali saluti e una bellissima estate senza fili! Lo staff di Emmedue s.r.l.
[Bug libgcj/27024] Implement URLConnection.getFileNameMap
--- Comment #2 from tromey at gcc dot gnu dot org 2006-04-05 18:55 --- I checked in a fix to the 4.1 branch. For svn trunk I am looking at a more complete merge with Classpath. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27024
[Bug java/25847] libjava build doesn't stop when there is a fatal error
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-05 19:14 --- Always do a make check, this is the correct thing to do when checking the compiler anyways. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25847
[Bug c/27050] New: error during kernel FreeBSD 5.4 compilation
cc -O -pipe -D_KERNEL -DKLD_MODULE -nostdinc -I- -include
/usr/src/sys/i386/compile/SPIKE/opt_global.h -I. -I@ -I@/contrib/altq
-I/usr/include -finline-limit=8000 -fno-common
-I/usr/src/sys/i386/compile/SPIKE -mno-align-long-strings
-mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2
-ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions
-std=c99 -c /usr/src/sys/modules/ispfw/../../dev/ispfw/ispfw.c
cc: Internal error: Killed (program cc1)
Please submit a full bug report.
See http://gcc.gnu.org/bugs.html> for instructions.
{standard input}: Assembler messages:
{standard input}:173815: Warning: end of file not at end of a line; newline
inserted
{standard input}:175083: Error: unknown pseudo-op: `.valu'
*** Error code 1
Stop in /usr/src/sys/modules/ispfw.
*** Error code 1
Stop in /usr/src/sys/modules.
*** Error code 1
Stop in /usr/src/sys/i386/compile/SPIKE.
--
Summary: error during kernel FreeBSD 5.4 compilation
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dol at reedcat dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27050
R__E_M_0_V_E
U,N,S,U,B,S,C,R,I,,B,E
[Bug target/26504] compute_frame_pointer_to_cfa_displacement error for avr target with --with-dwarf2
--- Comment #8 from bjkeen at super dot org 2006-04-05 20:11 --- (In reply to comment #6) > Can either one of you try the patch in PR 26015? > Putting #define FRAME_POINTER_CFA_OFFSET(FNDECL) 0 as indicated in that patch, into config/avr.h seems to work, but it is also necessary to specify --disable-libssp to configure. Perhaps libssp should by default be disabled for avr targets? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26504
[Bug c/27051] New: Compiler generates .sdata when -mno-sdata specified
Given the following code:
float
abc(float a, float b)
{
return ((a - b) * 0.1);
}
Compiled with the -mno-sdata flag, the compiler still defines an .sdata item
for the floating constant 0.1, which causes problems for embedded systems
that rely on -mno-sdata meaning NO .sdata
This bug can be circumvented as follows:
float
abc(float a, float b)
{
static float r = 0.1;
return ((a - b) * r);
}
--
Summary: Compiler generates .sdata when -mno-sdata specified
Product: gcc
Version: 3.4.5
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jsworley at qwest dot net
GCC build triplet: ia64-unknown-linux-gnu
GCC host triplet: ia64-redhat-linux
GCC target triplet: ia64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27051
[Bug fortran/27021] Problem with nearest(tiny(o),-1.0)/2.0
--- Comment #2 from kargl at gcc dot gnu dot org 2006-04-05 20:50 --- I sent a preliminary patch for this problem to fortran@ http://gcc.gnu.org/ml/fortran/2006-04/msg00084.html -- kargl at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |kargl at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-05 20:50:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27021
[Bug middle-end/27050] error during kernel FreeBSD 5.4 compilation
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-05 21:06 --- Can you attach the preprocessed source? reading http://gcc.gnu.org/bugs.html tells you how to get the preprocessed source. The other thing you should be doing is also trying to update the GCC version you have because 3.4.2 is over a year old now. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27050
[Bug middle-end/27050] error during kernel FreeBSD 5.4 compilation
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-04-05 21:11 --- This: cc: Internal error: Killed (program cc1) hints at a out-of-memory condition or someone killing cc1. So I guess this is invalid. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27050
[Bug c++/27052] New: When using excessive -ftemplate-depth g++ segfaults
When compiling foo.C using the command line g++ -ftemplate-depth-2 foo.C the result is g++: Internal error: Segmentation fault (program cc1plus) Please submit a full bug report. See http://gcc.gnu.org/bugs.html> for instructions. instead of the expected foo.C:3: error: template instantiation depth exceeds maximum of 2 (use -ftemplate-depth-NN to increase the maximum) instantiating 'struct foo<2u>' foo.C:3: instantiated from 'foo<1u>' ... foo.C:3: instantiated from 'foo<0u>' foo.C:8: instantiated from here foo.C:3: error: incomplete type 'foo<2u>' used in nested name specifier -- Summary: When using excessive -ftemplate-depth g++ segfaults Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gcc at magfr dot user dot lysator dot liu dot se GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27052
[Bug c++/27052] When using excessive -ftemplate-depth g++ segfaults
--- Comment #1 from gcc at magfr dot user dot lysator dot liu dot se 2006-04-05 21:14 --- Created an attachment (id=11214) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11214&action=view) Recursive template for error triggering -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27052
[Bug c++/27052] When using excessive -ftemplate-depth g++ segfaults
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-05 21:16 --- Actually what is happening here is that the stack is overflowing before hitting the limit you set :). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27052
[Bug middle-end/27050] error during kernel FreeBSD 5.4 compilation
--- Comment #3 from kargl at gcc dot gnu dot org 2006-04-05 21:25 --- (In reply to comment #1) > > The other thing you should be doing is also trying to update the GCC version > you have because 3.4.2 is over a year old now. > Andrew, he's using the version of gcc bundled with FreeBSD 5.4, which has probably been used to successfully build the FreeBSD 5.4 kernel millions of times. This smells like a hardware problem (i.e., bad memory, a full filesystem, overheating, etc). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27050
[Bug libgcj/23682] gnu.java.nio.SelectorImpl.select(long) throws ArrayIndexOutOfBoundsException
--- Comment #4 from tromey at gcc dot gnu dot org 2006-04-05 21:38 --- One possible problem I see here is that the 'interestOps' of a SelectionKeyImpl can change while getFDsAsArray is running. There are a few possible fixes here, the simplest would be to avoid having two loops in getFDsAsArray. If I send a patch can you easily test it? -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-05 21:38:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23682
[Bug libgcj/26625] libgcj-4.2.0.jar not rebuilt after a source file change
--- Comment #1 from tromey at gcc dot gnu dot org 2006-04-05 21:42 --- Testing a patch. -- tromey at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-05 21:42:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26625
[Bug middle-end/27050] error during kernel FreeBSD 5.4 compilation
--- Comment #4 from dol at reedcat dot net 2006-04-05 21:48 --- Subject: RE: error during kernel FreeBSD 5.4 compilation Maybe you are right. This particular computer has only 32M of RAM. Maybe this could be the reason of this issue? dol@ > -Original Message- > From: rguenth at gcc dot gnu dot org > [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 06, 2006 1:11 AM > To: [EMAIL PROTECTED] > Subject: [Bug middle-end/27050] error during kernel FreeBSD > 5.4 compilation > > > > --- Comment #2 from rguenth at gcc dot gnu dot org > 2006-04-05 21:11 --- > This: > > cc: Internal error: Killed (program cc1) > > hints at a out-of-memory condition or someone killing cc1. > So I guess this is invalid. > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27050 > > --- You are receiving this mail because: --- You > reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27050
[Bug libgcj/26625] libgcj-4.2.0.jar not rebuilt after a source file change
--- Comment #2 from cvs-commit at developer dot classpath dot org 2006-04-05 22:12 --- Subject: Bug 26625 CVSROOT:/cvsroot/classpath Module name:classpath Branch: Changes by: Tom Tromey <[EMAIL PROTECTED]>06/04/05 22:12:01 Modified files: . : ChangeLog lib: Makefile.am Log message: PR libgcj/26625: * lib/Makefile.am (compile-classes): Touch the output file. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/ChangeLog.diff?tr1=1.7025&tr2=1.7026&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/lib/Makefile.am.diff?tr1=1.116&tr2=1.117&r1=text&r2=text -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26625
