[Bug testsuite/21630] [4.1 Regression] gcc.dg/vect/vect-none.c scan-tree-dump-times vectorized 1 loops 1 fails
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-05-23 06:38 --- (In reply to comment #5) My patch removes vect-none.c, so it's impossible to get failures on this testcase. I guess, there is a problem either in how I created the patch (I did 'cvs remove' and 'cvs add', and 'cvs diff -N' afterwards) or in how you applied it. I simply applied a copy of the patch from http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02124.html using patch command, it applied onto the tree well except the changelog was REJECT Hunk, which is minor IMHO (this was caused by my working copy of the tree being more up to date). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21630
[Bug java/19870] gcj -C doesn't generate accessors for private members across nested class boundaries
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-05-23 07:45 --- outer_field_access_p(), build_outer_field_access(), etc. are only for non-static fields (instance variables). Even for some simple testcases, I could not get GCJ to emit correct bytecode for non-static instance variables. Lastly these methods are for access from inside a nested class to a private member in a containing class, not the other way round as given in the testcase for this PR. So a significant surgery is indeed needed to make these cases work with GCJ. If anyone is working on a patch to fix this, I would certainly like to hear from them - I have a partially working patch, but I don't know if I'd be able to finish it given the lack of skills as well as time on my part. -- What|Removed |Added CC||rmathew at gcc dot gnu dot ||org Last reconfirmed|2005-05-12 16:53:53 |2005-05-23 07:45:49 date|| Summary|gcj -C doesn't generate |gcj -C doesn't generate |accessors for private |accessors for private |members in inner class |members across nested class ||boundaries http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19870
[Bug target/21715] New: code-generation regression
During recent performance testing I have identified a number of small code
fragments where gcc 4.x produces worse code than gcc 3.4.3. Some of these may be
target specific, and I plan to gradually enter such small performance
regressions into the bug database unless there is a better way to report these.
$ cat test.c
long foo(long v) { return v -v; }
$ gcc-3.4.3 -O3 -c test.c objdump -d test.o
test.o: file format elf64-x86-64
Disassembly of section .text:
foo:
0: 48 89 f8mov%rdi,%rax
3: 48 f7 d8neg%rax
6: 48 21 f8and%rdi,%rax
9: c3 retq
$ gcc-4.1-20050516 -O3 -c test.c objdump -d test.o
test.o: file format elf64-x86-64
Disassembly of section .text:
foo:
0: 48 89 f8mov%rdi,%rax
3: 48 f7 d8neg%rax
6: 48 21 c7and%rax,%rdi
9: 48 89 f8mov%rdi,%rax
c: c3 retq
--
Summary: code-generation regression
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: markus at oberhumer dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: x86_64-pc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21715
[Bug target/21715] code-generation performance regression
-- What|Removed |Added Keywords||missed-optimization Known to fail||4.0.0 4.1.0 Known to work||3.4.3 Summary|code-generation regression |code-generation performance ||regression http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21715
[Bug testsuite/21707] [4.1 Regression] g++.old-deja/g++.jason/thunk3.C: syntax error target selector
--- Additional Comments From nickc at redhat dot com 2005-05-23 08:46 --- Hi Guys, I have checked in a patch which restores Kazuhiro's original patch and which should stop the testsuite from complaining. Cheers Nick -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21707
[Bug target/21716] New: ICE in reg-stack.c's swap_rtx_condition
Attached testcase ICEs at -m32 -march=i386 -O2 -ffast-math in
swap_rtx_condition.
Cross jumping there merges testqi_ext_0/jcc_1 from 2 different BB's, but keeps
the %ax setters (cmpfp_2_df_1) in the original blocks.
(insn:HI 2037 4155 2038 55 (set (reg:HI 0 ax [783])
(unspec:HI [
(compare:CCFP (reg/v:DF 10 st(2) [orig:354 cf0d2 ] [354])
(reg:DF 12 st(4)))
] 24)) 22 {*cmpfp_2_df_1} (insn_list 4399 (insn_list 4400 (nil)))
(expr_list:REG_DEAD (reg:DF 12 st(4))
(nil)))
(note:HI 2038 2037 4525 55 NOTE_INSN_DELETED)
;; End of basic block 55, registers live:
0 [ax] 3 [bx] 4 [si] 5 [di] 6 [bp] 7 [sp] 10 [st(2)] 11 [st(3)] 13 [st(5)] 14
[st(6)] 15 [st(7)] 16 [argp] 20 [frame]
;; Start of basic block 56, registers live: 0 [ax] 3 [bx] 4 [si] 5 [di] 6 [bp] 7
[sp] 10 [st(2)] 11 [st(3)] 13 [st(5)] 14 [st(6)] 15 [st(7)] 16 [argp] 20 [frame]
(code_label 4525 2038 4523 56 173 [1 uses])
(note 4523 4525 2448 56 [bb 56] NOTE_INSN_BASIC_BLOCK)
(note:HI 2448 4523 2449 56 NOTE_INSN_DELETED)
(note:HI 2449 2448 2450 56 NOTE_INSN_DELETED)
(note:HI 2450 2449 4359 56 NOTE_INSN_DELETED)
(insn 4359 2450 2453 56 (set (reg:CCZ 17 flags)
(compare:CCZ (and:SI (zero_extract:SI (reg:SI 0 ax [834])
(const_int 8 [0x8])
(const_int 8 [0x8]))
(const_int 1 [0x1]))
(const_int 0 [0x0]))) 278 {*testqi_ext_0} (nil)
(expr_list:REG_DEAD (reg:SI 0 ax [834])
(nil)))
(jump_insn:HI 2453 4359 4454 56 (set (pc)
(if_then_else (eq (reg:CCZ 17 flags)
(const_int 0 [0x0]))
(label_ref 1835)
(pc))) 494 {*jcc_1} (insn_list 4359 (nil))
(expr_list:REG_DEAD (reg:CCZ 17 flags)
(expr_list:REG_BR_PROB (const_int 8448 [0x2100])
(nil
When swap_rtx_condition is called on insn 2037, it doesn't find the %ax user
in the same BB, but as the last instruction in the BB is not INSN_P(), it
crashes
when trying to dereference it's PATTERN.
--
Summary: ICE in reg-stack.c's swap_rtx_condition
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: i386-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21716
[Bug target/21716] ICE in reg-stack.c's swap_rtx_condition
--- Additional Comments From jakub at gcc dot gnu dot org 2005-05-23 09:02 --- Created an attachment (id=8950) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8950action=view) pr21716.c Testcase (too large though). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21716
[Bug libfortran/21621] Inconsistency with binary sequential output
--- Additional Comments From P dot Schaffnit at access dot rwth-aachen dot de 2005-05-23 09:05 --- Hi! I was trying to read some binary data written by a GFortran binary with binaries written with other compilers (LF, SGI), and I couldn't get anywhere, so I just started to poke around to see where it came from... I tried to have a look at the Fortran standard, but I didn't get anywhere, but my experience with several compilers is that they do use this REC-LENGTH thing, so (and g77 did also!), so I would say it would be a pity to have trouble reading old binary data from g77 with gfortran... It's actually a rather self-centered comment, but maybe I'm not the only one... Cheers! Philippe -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21621
[Bug pch/21654] [4.1 Regression] gcc.dg/pch/inline-4.c fails
--- Additional Comments From hubicka at gcc dot gnu dot org 2005-05-23 09:09 --- I am having problems to reproduce it on my machines (i686,x86-64,powerpc64) so I need some help debugging the problem (at least backtrace to start with) Honza -- What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21654
[Bug testsuite/21707] [4.1 Regression] g++.old-deja/g++.jason/thunk3.C: syntax error target selector
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-05-23 09:13 --- I will regression test it, later on to confirm it is really fixed. If all goes well, I'll change the resolution to FIXED and status to RESOLVED. -- What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21707
[Bug ada/21717] New: [4.1 regression] Endless stream of exceptions
The ACATS tests c95085a, c95085b and c95086a fail with an endless stream of exceptions. $ tail ./c9/c95086a/c95086a.log * NO_NAME EXCEPTION RAISED IN ACCEPT E1. * NO_NAME EXCEPTION RAISED IN ACCEPT E1. * NO_NAME EXCEPTION RAISED IN ACCEPT E1. * NO_NAME EXCEPTION RAISED IN ACCEPT E1. * NO_NAME EXCEPTION RAISED IN ACCEPT E1. * NO_NAME EXCEPTION RAISED IN ACCEPT E1. * NO_NAME EXCEPTION RAISED IN ACCEPT E1. * NO_NAME EXCEPTION RAISED IN ACCEPT E1. * NO_NAME EXCEPTION RAISED IN ACCEPT E1. * NO_NAME EXCEPTION RAISED IN ACCEPT E1. -- Summary: [4.1 regression] Endless stream of exceptions Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: schwab at suse dot de CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: ia64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21717
[Bug libfortran/21547] Enable to build libfortran library
--- Additional Comments From antonvys at mail dot ru 2005-05-23 09:40 --- I think if I use ./configure with flags --with-mpfr=[PATH] --with-gmp=[PATH] libgmp should be automatically added to LD_LIBRARY_PATH for building. Otherwise it should be mentioned in docs that setting flags --with-[something] is not enough for building process. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21547
[Bug pch/21654] [4.1 Regression] gcc.dg/pch/inline-4.c fails
--- Additional Comments From hubicka at ucw dot cz 2005-05-23 09:44 --- Subject: Re: [4.1 Regression] gcc.dg/pch/inline-4.c fails Hi, I finally reproduced it on IA-64 machine. I am testing the attached fix. Can you please try if it fixes your problem too? 2005-05-23 Jan Hubicka [EMAIL PROTECTED] * tree-flow.h (stmt_ann_d): Kill GTY ((skip)) mark on BB. Index: tree-flow.h === RCS file: /cvs/gcc/gcc/gcc/tree-flow.h,v retrieving revision 2.109 diff -c -3 -p -r2.109 tree-flow.h *** tree-flow.h 17 May 2005 20:28:22 - 2.109 --- tree-flow.h 23 May 2005 09:40:11 - *** struct stmt_ann_d GTY(()) *** 308,314 unsigned makes_clobbering_call : 1; /* Basic block that contains this statement. */ ! basic_block GTY ((skip ())) bb; /* Operand cache for stmt. */ struct stmt_operands_d GTY ((skip ())) operands; --- 308,314 unsigned makes_clobbering_call : 1; /* Basic block that contains this statement. */ ! basic_block bb; /* Operand cache for stmt. */ struct stmt_operands_d GTY ((skip ())) operands; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21654
[Bug middle-end/20297] #pragma GCC visibility isn't properly handled for builtin functions
-- What|Removed |Added CC||matz at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20297
[Bug middle-end/20297] #pragma GCC visibility isn't properly handled for builtin functions
-- What|Removed |Added CC||pluto at agmk dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20297
[Bug c++/21685] [3.4/4.0/4.1 Regression] Internal compiler error on invalid code
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-05-23
10:11 ---
More compact testcase:
===
templateint struct A
{
void foo();
};
templateint N void bar()
{
AN a;
struct B { B() { a.foo(); } } b;
}
template void bar0();
===
--
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
Keywords||monitored
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21685
[Bug middle-end/21124] [4.1 regression] bogus may be used uninitialized warning
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-05-23 10:46 --- This got fixed by Diego's reorganization of the initial optimization passes: http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00955.html http://gcc.gnu.org/ml/gcc-cvs/2005-05/msg00529.html -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21124
[Bug testsuite/21630] [4.1 Regression] gcc.dg/vect/vect-none.c scan-tree-dump-times vectorized 1 loops 1 fails
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-05-23 11:29 --- I'll re-run the regression test later on. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21630
[Bug target/21715] code-generation performance regression
--- Additional Comments From giovannibajo at libero dot it 2005-05-23 12:23 --- The best way is to use Bugzilla, yes. Please use different bug reports for each code fragment, thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21715
[Bug testsuite/21707] [4.1 Regression] g++.old-deja/g++.jason/thunk3.C: syntax error target selector
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-23 12:44 --- Fixed. -- What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21707
[Bug target/21715] code-generation performance regression
-- What|Removed |Added Keywords||ra http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21715
[Bug pch/21654] [4.1 Regression] gcc.dg/pch/inline-4.c fails
-- What|Removed |Added Status|WAITING |NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21654
[Bug pch/21654] [4.1 Regression] gcc.dg/pch/inline-4.c fails
-- What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21654
[Bug c/21718] New: real.c rounding not perfect
When compiled with -Wall,
int foo (void) { if (9007199254740991.45 ==
9007199254740991.5) return 1;}
does not complain about a missing return statement, showing that GCC is folding
the comparison to true. However, the LHS should round down.
With one less 9 GCC gets it correct.
I'm not convinced it's worthwhile to get perfect rounding, but Joseph wanted me
to file a report.
--
Summary: real.c rounding not perfect
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: neil at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21718
[Bug middle-end/21718] real.c rounding not perfect
-- What|Removed |Added Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21718
[Bug target/21716] ICE in reg-stack.c's swap_rtx_condition
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-23 13:52 --- Confirmed. -- What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||05/msg02166.html Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||ice-on-valid-code, patch Last reconfirmed|-00-00 00:00:00 |2005-05-23 13:52:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21716
[Bug c/21719] New: program using initgroups() fails with stack corruption
Tracing down a problem with sudo receiving a stack corruption on one machine,
I've found out that a minimal program gets a stack corruption when compiled with
gcc-3.4.3, but not when being compiled with HP's bundled cc. See details here:
http://www.sudo.ws/bugs/show_bug.cgi?id=170#c26
The minimal program is this:
main()
{
initgroups(root, 3);
}
Possible required further conditions are: /etc/group must have +: in the last
line, /etc/nsswitch.conf should have compat for selector groups, and the
machine should be NIS master server. (When removing the +: from /etc/group,
the gcc-compiled binary also doesn't get a memory fault).
I'd like to file a bug report for the HP C library once I know it's not a gcc
bug. Upon request I can attach or include disassemblies of both, HP-CC code, and
GCC code.
--
Summary: program using initgroups() fails with stack corruption
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Ulrich dot Windl at rz dot uni-regensburg dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: hppa2.0w-hp-hpux11.11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21719
[Bug c/21719] program using initgroups() fails with stack corruption
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-23 14:02 --- This really sounds like a HP C library bug or bug in the code but I don't know for sure. You are using old style KR C, can you use -Wall -W and fix all the warnings? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21719
[Bug target/21719] program using initgroups() fails with stack corruption
-- What|Removed |Added Component|c |target Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21719
[Bug c++/21670] segv after error
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-05-23 14:32 --- Ivan, this looks like a duplicate of your PR 20789 to me. Or is there any major difference? -- What|Removed |Added CC||reichelt at gcc dot gnu dot ||org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21670
[Bug middle-end/21718] real.c rounding not perfect
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-05-23 14:50 --- We probably don't even get it right for all cases with DECIMAL_DIG digits for all long double formats (required by Annex F). -- What|Removed |Added OtherBugsDependingO||16989 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21718
[Bug c/21720] New: GCC incorrectly rounds hex floats
Unlike decimal floats, correctly rounding hex floats is easy and cheap, so we
should do it. Moreover the standard requires it.
With -Wall GCC complains that the following function is missing a return
statement because it has incorrectly folded the comparison to false.
int foo(void) { if (0x1.0101p0f != 1) return
1; }
Remove one of the long line of zeroes and the precision falls within GCC's
limits and it works.
--
Summary: GCC incorrectly rounds hex floats
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: neil at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21720
[Bug libgcj/21714] libjava bootstrap failure in java/lang/natConcreteProcess.cc
--- Additional Comments From kristerw at netbsd dot org 2005-05-23 15:31 --- Subject: Re: libjava bootstrap failure in java/lang/natConcreteProcess.cc On Sun, 22 May 2005, pinskia at gcc dot gnu dot org wrote: --- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-22 22:08 --- Huh, are you sure it does not have pthreads. Yes, I am sure. pthreads were added in the NetBSD 2.0 release. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21714
[Bug libgcj/21714] [4.0/4.1 Regression] libjava bootstrap failure in java/lang/natConcreteProcess.cc
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-23 15:39 --- Yes I was told late last night the same thing. This was caused by: 2004-08-12 David Daney [EMAIL PROTECTED] PR libgcj/11801 * java/lang/PosixProcess.java: Rewrote. * java/lang/natPosixProcess.cc: Rewrote. * java/lang/Runtime.java (execInternal): Declare throws IOException. * gcj/javaprims.h (ConcreteProcess$ProcessManager): Declare. * posix-threads.cc (block_sigchld) New function. (_Jv_ThreadRegister) Use it. (_Jv_ThreadStart) Use it. * configure.in (PLATFORM_INNER_NAT_HDRS): New AC_SUBST() used in... * Makefile.am: ... to specify extra native headers. * configure: Regenerated. * include/config.h: Regenerated. * Makefile.in: Regenerated. * gcj/Makefile.in: Regenerated. * include/Makefile.in: Regenerated. * testsuite/Makefile.in: Regenerated. -- What|Removed |Added CC||ddaney at avtrex dot com Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-05-23 15:39:10 date|| Summary|libjava bootstrap failure in|[4.0/4.1 Regression] libjava |java/lang/natConcreteProcess|bootstrap failure in |.cc |java/lang/natConcreteProcess ||.cc Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21714
[Bug bootstrap/17814] install.texi mentions wrong --enable-language names
--- Additional Comments From bh at techhouse dot brown dot edu 2005-05-23 15:41 --- (In reply to comment #2) *** Bug 21156 has been marked as a duplicate of this bug. *** I have a pair of attachments on #21156 that may be relevant; I don't know the appropriate way to link them in to this bug report. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17814
[Bug bootstrap/17814] install.texi mentions wrong --enable-language names
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-23 15:44 --- This has now been fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17814
[Bug c/21720] GCC incorrectly rounds hex floats
-- What|Removed |Added OtherBugsDependingO||16989 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21720
[Bug pch/21654] [4.1 Regression] gcc.dg/pch/inline-4.c fails
--- Additional Comments From joseph at codesourcery dot com 2005-05-23 15:46 --- Subject: Re: [4.1 Regression] gcc.dg/pch/inline-4.c fails On Mon, 23 May 2005, hubicka at ucw dot cz wrote: I finally reproduced it on IA-64 machine. I am testing the attached fix. Can you please try if it fixes your problem too? It appears to fix the problem on hppa2.0w-hp-hpux11.23 for me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21654
[Bug libgcj/21714] [4.0/4.1 Regression] libjava bootstrap failure in java/lang/natConcreteProcess.cc
--- Additional Comments From daney at gcc dot gnu dot org 2005-05-23 15:47 --- I don't think we should revert it as Process et al. were broken on many pthread targets before the patch. Since NetBSD is not posix, perhaps it should not be using PosixProcess. I am not a BSD hacker so I cannot fix it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21714
[Bug fortran/17283] UNPACK issues
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-05-23 16:00 --- Looks like there is another memory allocation issue: $ cat unpack.f90 program main real, dimension(5) :: a a = (/(real(i),i=1,5)/) print *, unpack(a(:), a(:)0, 0.) end $ gfortran unpack.f90 $ ./a.out Segmentation fault $ gfortran -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.0/configure --prefix=/home/ig25 --enable-languages=c,f95 : (reconfigured) ../gcc-4.0/configure --prefix=/home/ig25 --with-gcc-version-trigger=/home/ig25/gcc-4.0/gcc/version.c --enable-languages=c,f95 --no-create --no-recursion Thread model: posix gcc version 4.0.1 20050518 (prerelease) -- What|Removed |Added CC||tkoenig at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17283
[Bug target/21716] [3.4/4.0/4.1 Regression] ICE in reg-stack.c's swap_rtx_condition
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-05-23
16:39 ---
Here's a reduced testcase that might be appropriate for the testsuite:
==
/* PR target/21716 */
/* { dg-do compile } */
/* { dg-options -march=i386 -m32 -O2 -ffast-math { i?86-*-* } } */
double atan (double);
void foo()
{
double x, y;
do
{
goto L2;
L1:
if (x) goto L1;
L2:
x += atan (y);
goto L1;
}
while (1);
}
==
For me the original testcase and the reduced one only crash with the
3.4 branch on a native i686-pc-linux-gnu box.
--
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21716
[Bug target/21721] New: [4.0 regression] fails to assemble, Use of p0 is not valid in this context
4.0 CVS 20050522 on ia64-linux, binutils-2.15, glibc-2.3.5, works with 3.3.6 and 3.4.4 releases $ gcc -O2 -g -c writet1.i writet1.c: In function 'load_enc': writet1.c:348: warning: pointer targets in assignment differ in signedness writet1.c: In function 't1_open_fontfile': writet1.c:1000: warning: pointer targets in assignment differ in signedness writet1.c:1012: warning: pointer targets in assignment differ in signedness writet1.c: In function 't1_read_enc': writet1.c:1033: warning: pointer targets in assignment differ in signedness /tmp/cctsWODh.s: Assembler messages: /tmp/cctsWODh.s:15316: Error: Use of p0 is not valid in this context -- Summary: [4.0 regression] fails to assemble, Use of p0 is not valid in this context Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: doko at debian dot org CC: debian-gcc at lists dot debian dot org,gcc-bugs at gcc dot gnu dot org GCC build triplet: ia64-linux GCC host triplet: ia64-linux GCC target triplet: ia64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21721
[Bug target/21721] [4.0 regression] fails to assemble, Use of p0 is not valid in this context
--- Additional Comments From doko at debian dot org 2005-05-23 16:48 --- Created an attachment (id=8951) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8951action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21721
[Bug target/21721] [4.0 regression] fails to assemble, Use of p0 is not valid in this context
--- Additional Comments From doko at debian dot org 2005-05-23 16:49 --- Created an attachment (id=8952) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8952action=view) assembler file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21721
[Bug target/21721] [4.0 regression] fails to assemble, Use of p0 is not valid in this context
-- What|Removed |Added Known to fail||3.3.6 3.4.4 Known to work||4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21721
[Bug java/21722] New: gcj miscompiles accesses to static final vars with indirect dispatch
Below I attached a tarball which contains two packages with one class each. B.java defines a static final String initilized to foo, and A.java tries to call the 'equals' method on that object (and another string). This actually is reduced from trang. The problem happens when this is compiled like the doit.sh script does. I.e. first creating the .class files and then compiling both .class files at once into one object file with -findirect-dispatch. The generated program will segfault. The segfault happens because the generated code for A.main() accesses the -vtable member of the global object '_ZN1b1B3FOOE' (== b::B::FOO) directly (if I read the .t03.generic dump correctly). But it is defined like so in the assembler: _ZN1b1B3FOOE: .long _Utf1 .section.rodata.jutf8.10 I.e. the first (and only) member of that symbol actually is the UTF-8 string itself, not a pointer to the vtable. But the code trying to resolve the address of the 'equals' method assumes so, and hence calls some random address. Note that this is not the same as the usual -findirect-dispatch only supports compiling from .class problem. This is the case here. -- Summary: gcj miscompiles accesses to static final vars with indirect dispatch Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: matz at suse dot de CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org GCC target triplet: i686-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21722
[Bug java/21722] gcj miscompiles accesses to static final vars with indirect dispatch
--- Additional Comments From matz at suse dot de 2005-05-23 16:52 --- Created an attachment (id=8953) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8953action=view) tarball showing the problem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21722
[Bug java/21722] gcj miscompiles accesses to static final vars with indirect dispatch
-- What|Removed |Added CC||skh at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21722
[Bug target/21721] [4.0 regression] fails to assemble, Use of p0 is not valid in this context
-- What|Removed |Added CC||schwab at suse dot de Known to fail|3.3.6 3.4.4 |4.0.1 Known to work|4.0.1 |3.3.6 3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21721
[Bug java/21722] gcj miscompiles accesses to static final vars with indirect dispatch
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-23 16:59 --- Related to PR 1259. -- What|Removed |Added BugsThisDependsOn||1259 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21722
[Bug fortran/21723] New: ICE while building gfortran
This is based on a cvs snapshot of gcc 4.0 from 2005/05/20 from the src rpm in fedora development. Reference: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=158453 /home/mgalgoci/rpm/BUILD/gcc-4.0.0-20050520/obj-hppa-redhat-linux/gcc/xgcc -B/home/mgalgoci/rpm/BUILD/gcc-4.0.0-20050520/obj-hppa-redhat-linux/gcc/ -B/usr/hppa-redhat-linux/bin/ -B/usr/hppa-redhat-linux/lib/ -isystem /usr/hppa-redhat-linux/include -isystem /usr/hppa-redhat-linux/sys-include -DHAVE_CONFIG_H -I. -I../../../libgfortran -I. -iquote../../../libgfortran/io -std=gnu99 -Wall -O2 -O2 -g -mpa-risc-1-0 -fPIC -c ../../../libgfortran/generated/pow_c4_i4.c -fPIC -DPIC -o .libs/pow_c4_i4.o ../../../libgfortran/generated/pow_c4_i4.c: In function 'pow_c4_i4': ../../../libgfortran/generated/pow_c4_i4.c:44: internal compiler error: in read_complex_part, at expr.c:2710 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://bugzilla.redhat.com/bugzilla for instructions. Preprocessed source stored into /tmp/ccKQZCLy.out file, please attach this to your bugreport. -- Summary: ICE while building gfortran Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mgalgoci at redhat dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21723
[Bug libfortran/20179] cannot mix C and Fortran I/O
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-05-23 17:12 --- Good news for this PR. I located the root of the problem, which is that when the library ends, we close() the stdout file descriptor, while the last line of output (without newline trailing character) is not written yet. So, the right thing to do might be not have a special test for stdout and stderr, so that we don't close() those. Patch submitted for review. -- What|Removed |Added URL||http://gcc.gnu.org/ml/fortra ||n/2005-05/msg00267.html Last reconfirmed|2005-05-22 22:09:34 |2005-05-23 17:12:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20179
[Bug fortran/21723] ICE while building gfortran
-- What|Removed |Added GCC build triplet||hppa-redhat-linux GCC host triplet||hppa-redhat-linux GCC target triplet||hppa-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21723
[Bug fortran/21723] ICE while building gfortran
--- Additional Comments From mgalgoci at redhat dot com 2005-05-23 17:14 --- Created an attachment (id=8954) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8954action=view) Preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21723
[Bug target/21723] ICE while building libgfortran
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-23 17:14 --- The code is C. -- What|Removed |Added Component|fortran |target Keywords||build, ice-on-valid-code Summary|ICE while building gfortran |ICE while building ||libgfortran http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21723
[Bug libmudflap/21724] New: [gcc]/libmudflap/Makefile.am, refusing to install mf-runtime.h in includedir
When doing something like: make install includedir=/foo/bar/baz in gcc 4.0.0 you get the following error: test -z /include || mkdir -p -- /include /usr/bin/install -c -m 644 '/home/ams/gsc/devel/gcc/src/libmudflap/mf-runtime.h' '/include/mf-runtime.h' /usr/bin/install: cannot create regular file `/include/mf-runtime.h': Permission denied make[5]: *** [install-includeHEADERS] Error 1 This applys to any platform, not just GNU. Happy hacking. -- Summary: [gcc]/libmudflap/Makefile.am, refusing to install mf- runtime.h in includedir Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libmudflap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ams at gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-pc-gnu0.3 GCC host triplet: i686-pc-gnu0.3 GCC target triplet: i686-pc-gnu0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21724
[Bug target/21721] [4.0 regression] fails to assemble, Use of p0 is not valid in this context
--- Additional Comments From schwab at suse dot de 2005-05-23 17:21 --- Seems to be fixed in 4.1. -- What|Removed |Added Known to work|3.3.6 3.4.4 |3.3.6 3.4.4 4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21721
[Bug c/21723] ICE while building libgfortran
-- What|Removed |Added Component|target |c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21723
[Bug target/21723] ICE while building libgfortran
-- What|Removed |Added Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21723
[Bug libmudflap/21724] [gcc]/libmudflap/Makefile.am, refusing to install mf-runtime.h in includedir
--- Additional Comments From ams at gnu dot org 2005-05-23 17:28 --- Created an attachment (id=8955) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8955action=view) Fix for bug 21724 The following patch fixes the bug. libmudflap/ChangeLog 2005-05-23 Alfred M. Szmidt [EMAIL PROTECTED] * Makefile.am (AM_MAKEFLAGS): Pass includedir. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21724
[Bug target/21723] ICE while building libgfortran
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-23
17:49 ---
Confirmed, reduced testcase:
void pow_c4_i4 (_Complex float a) {}
Only -mpa-risc-1-0 is needed to reproduce this.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |2005-05-23 17:50:00
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21723
[Bug libgcj/21725] New: use new sync built-ins
we should look into replacing or augmenting libjava/sysdep/*/locks.h with a generic version based on the new sync built-ins. This would remove one more step when doing a new port of libgcj. -- Summary: use new sync built-ins Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: minor Priority: P2 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tromey at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21725
[Bug libgcj/21725] use new sync built-ins
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-23 17:51 --- Confirmed, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21725
[Bug target/21723] [4.0/4.1 Regression] ICE while building libgfortran
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-23 17:59 --- This testcase works in 3.4.4 so it is a regression. -- What|Removed |Added Known to fail|4.0.1 |4.0.1 3.4.4 Summary|ICE while building |[4.0/4.1 Regression] ICE |libgfortran |while building libgfortran Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21723
[Bug libgcj/21725] use new sync built-ins
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-05-23 17:52:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21725
[Bug java/21722] gcj miscompiles accesses to static final vars with indirect dispatch
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-23 18:03 --- Confirmed, I don't get a seg fault but a NPE (NullPointerException) instead. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-05-23 18:03:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21722
[Bug ada/21717] [4.1 regression] Endless stream of exceptions ( c95085a, c95085b and c95086a)
-- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Keywords||wrong-code Summary|[4.1 regression] Endless|[4.1 regression] Endless |stream of exceptions|stream of exceptions ( ||c95085a, c95085b and ||c95086a) Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21717
[Bug libgcj/21714] [4.0/4.1 Regression] libjava bootstrap failure in java/lang/natConcreteProcess.cc
--- Additional Comments From tromey at gcc dot gnu dot org 2005-05-23 18:06 --- I agree, we should definitely not revert this. Instead someone should make this file compile and try to work ok when no threads are available. Or, if that can't be done, make a new natBSDProcess.cc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21714
[Bug c++/21670] segv after error
--- Additional Comments From igodard at pacbell dot net 2005-05-23 18:10 --- Looks like it to me too, and I easily could have fallen into the same hole twice because it comes from a use of a shared library. Does a single fix make both go away? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21670
[Bug target/21715] [4.0/4.1 regression] code-generation performance regression
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-23 18:17 --- Confirmed. This is just a RA issue, I don't know how much we can fix for 4.0.x. -- What|Removed |Added BugsThisDependsOn||18427 Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-05-23 18:17:00 date|| Summary|code-generation performance |[4.0/4.1 regression] code- |regression |generation performance ||regression Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21715
[Bug fortran/20786] Can't use AINT intrinsic with KIND parameter
--- Additional Comments From jblomqvi at cc dot hut dot fi 2005-05-23 18:22 --- The ICE seems to have disappeared, but it still doesn't work correctly. E.g. implicit none real(4) :: r = 42.0 r = aint (r,kind=8) print *, r end Prints out 0.00 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20786
[Bug tree-optimization/21582] (optimisation) VRP pass could/should use non-null function attribute
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-23 18:25 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-05-23 18:25:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21582
[Bug testsuite/21630] [4.1 Regression] gcc.dg/vect/vect-none.c scan-tree-dump-times vectorized 1 loops 1 fails
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-05-23 18:58 --- After analysing my build log carefully, there is problem with the patch: patching file ChangeLog Hunk #1 FAILED at 1. 1 out of 1 hunk FAILED -- saving rejects to file ChangeLog.rej patching file gcc.dg/vect/vect-106.c patching file gcc.dg/vect/vect-107.c patching file gcc.dg/vect/vect-108.c patching file gcc.dg/vect/vect-109.c patching file gcc.dg/vect/vect-110.c patching file gcc.dg/vect/vect-111.c patching file gcc.dg/vect/vect-112.c patching file gcc.dg/vect/vect-113.c patching file gcc.dg/vect/vect-114.c patch: unexpected end of file in patch This will explain vect-none.c existed -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21630
[Bug testsuite/21630] [4.1 Regression] gcc.dg/vect/vect-none.c scan-tree-dump-times vectorized 1 loops 1 fails
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-05-23 19:01 --- I have regression tested it, the test summary is available at http://gcc.gnu.org/ml/gcc-testresults/2005-05/msg01512.html Now the testsuite failure, I get is : FAIL: gcc.dg/vect/vect-106.c (test for excess errors) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21630
[Bug libstdc++/21726] New: baseline_symbols.txt for powerpc64 missing
A reminder for a simple issue: we are missing a 3.4.0 abi baseline for powerpc64, instead that for powerpc is used for powerpc64 too and abi_check fails (very misleading) -- Summary: baseline_symbols.txt for powerpc64 missing Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pcarlini at suse dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21726
[Bug libstdc++/21726] baseline_symbols.txt for powerpc64 missing
-- What|Removed |Added GCC target triplet||powerpc64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21726
[Bug libstdc++/21726] baseline_symbols.txt for powerpc64 missing
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-23 19:29 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-05-23 19:29:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21726
[Bug libgcj/21692] unexpected java.lang.NoClassDefFoundError
-- What|Removed |Added CC||rth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21692
[Bug libgcj/21692] unexpected java.lang.NoClassDefFoundError
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-05-23 19:46 --- They fail for me on x86_64, too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21692
[Bug libfortran/21075] [4.0 only] Segfault in reshape with rank 7
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-23 20:04 --- Subject: Bug 21075 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-05-23 20:03:53 Modified files: libgfortran: ChangeLog gcc/testsuite : ChangeLog libgfortran/m4 : cshift1.m4 eoshift1.m4 eoshift3.m4 ifunction.m4 in_pack.m4 in_unpack.m4 reshape.m4 libgfortran/intrinsics: cshift0.c eoshift0.c eoshift2.c random.c reshape_generic.c spread_generic.c stat.c libgfortran/generated: all_l4.c all_l8.c any_l4.c any_l8.c count_4_l4.c count_4_l8.c count_8_l4.c count_8_l8.c cshift1_4.c cshift1_8.c eoshift1_4.c eoshift1_8.c eoshift3_4.c eoshift3_8.c in_pack_i4.c in_pack_i8.c in_unpack_i4.c in_unpack_i8.c maxloc1_4_i4.c maxloc1_4_i8.c maxloc1_4_r4.c maxloc1_4_r8.c maxloc1_8_i4.c maxloc1_8_i8.c maxloc1_8_r4.c maxloc1_8_r8.c maxval_i4.c maxval_i8.c maxval_r4.c maxval_r8.c minloc1_4_i4.c minloc1_4_i8.c minloc1_4_r4.c minloc1_4_r8.c minloc1_8_i4.c minloc1_8_i8.c minloc1_8_r4.c minloc1_8_r8.c minval_i4.c minval_i8.c minval_r4.c minval_r8.c product_c4.c product_c8.c product_i4.c product_i8.c product_r4.c product_r8.c reshape_c4.c reshape_c8.c reshape_i4.c reshape_i8.c sum_c4.c sum_c8.c sum_i4.c sum_i8.c sum_r4.c sum_r8.c Added files: gcc/testsuite/gfortran.dg: reshape_rank7.f90 Log message: 2005-05-23 Thomas Koenig [EMAIL PROTECTED] Backport from mainline: PR libfortran/21354 PR libfortran/21075 * m4/cshift1.m4: Change dimension of auxiliary arrays from GFC_MAX_DIMENSION - 1 to GFC_MAX_DIMENSION. * m4/eoshift1.m4: Likewise. * m4/eoshift3.m4: Likewise. * m4/ifunction.m4: Likewise. * m4/in_pack.m4: Likewise. * m4/in_unpack.m4: Likewise. * m4/reshape.m4: Likewise. * intrinsics/cshift0.c: Likewise. * intrinsics/eoshift0.c: Likewise. * intrinsics/eoshift2.c: Likewise. * intrinsics/random.c: Likewise. * intrinsics/reshape_generic.c: Likewise. * intrinsics/spread_generic.c: Likewise. * intrinsics/stat.c: Likewise. * generated/all_l4.c: Regenerated. * generated/all_l8.c: Regenerated. * generated/any_l4.c: Regenerated. * generated/any_l8.c: Regenerated. * generated/count_4_l4.c: Regenerated. * generated/count_4_l8.c: Regenerated. * generated/count_8_l4.c: Regenerated. * generated/count_8_l8.c: Regenerated. * generated/cshift1_4.c: Regenerated. * generated/cshift1_8.c: Regenerated. * generated/eoshift1_4.c: Regenerated. * generated/eoshift1_8.c: Regenerated. * generated/eoshift3_4.c: Regenerated. * generated/eoshift3_8.c: Regenerated. * generated/in_pack_i4.c: Regenerated. * generated/in_pack_i8.c: Regenerated. * generated/in_unpack_i4.c: Regenerated. * generated/in_unpack_i8.c: Regenerated. * generated/maxloc1_4_i4.c: Regenerated. * generated/maxloc1_4_i8.c: Regenerated. * generated/maxloc1_4_r4.c: Regenerated. * generated/maxloc1_4_r8.c: Regenerated. * generated/maxloc1_8_i4.c: Regenerated. * generated/maxloc1_8_i8.c: Regenerated. * generated/maxloc1_8_r4.c: Regenerated. * generated/maxloc1_8_r8.c: Regenerated. * generated/maxval_i4.c: Regenerated. * generated/maxval_i8.c: Regenerated. * generated/maxval_r4.c: Regenerated. * generated/maxval_r8.c: Regenerated. * generated/minloc1_4_i4.c: Regenerated. * generated/minloc1_4_i8.c: Regenerated. * generated/minloc1_4_r4.c: Regenerated. * generated/minloc1_4_r8.c: Regenerated. * generated/minloc1_8_i4.c: Regenerated. * generated/minloc1_8_i8.c: Regenerated. * generated/minloc1_8_r4.c: Regenerated. * generated/minloc1_8_r8.c: Regenerated. * generated/minval_i4.c: Regenerated. * generated/minval_i8.c: Regenerated. * generated/minval_r4.c: Regenerated. * generated/minval_r8.c: Regenerated. * generated/product_c4.c: Regenerated. *
[Bug libfortran/21075] [4.0 only] Segfault in reshape with rank 7
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-23 20:04 --- Subject: Bug 21075 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-05-23 20:03:53 Modified files: libgfortran: ChangeLog gcc/testsuite : ChangeLog libgfortran/m4 : cshift1.m4 eoshift1.m4 eoshift3.m4 ifunction.m4 in_pack.m4 in_unpack.m4 reshape.m4 libgfortran/intrinsics: cshift0.c eoshift0.c eoshift2.c random.c reshape_generic.c spread_generic.c stat.c libgfortran/generated: all_l4.c all_l8.c any_l4.c any_l8.c count_4_l4.c count_4_l8.c count_8_l4.c count_8_l8.c cshift1_4.c cshift1_8.c eoshift1_4.c eoshift1_8.c eoshift3_4.c eoshift3_8.c in_pack_i4.c in_pack_i8.c in_unpack_i4.c in_unpack_i8.c maxloc1_4_i4.c maxloc1_4_i8.c maxloc1_4_r4.c maxloc1_4_r8.c maxloc1_8_i4.c maxloc1_8_i8.c maxloc1_8_r4.c maxloc1_8_r8.c maxval_i4.c maxval_i8.c maxval_r4.c maxval_r8.c minloc1_4_i4.c minloc1_4_i8.c minloc1_4_r4.c minloc1_4_r8.c minloc1_8_i4.c minloc1_8_i8.c minloc1_8_r4.c minloc1_8_r8.c minval_i4.c minval_i8.c minval_r4.c minval_r8.c product_c4.c product_c8.c product_i4.c product_i8.c product_r4.c product_r8.c reshape_c4.c reshape_c8.c reshape_i4.c reshape_i8.c sum_c4.c sum_c8.c sum_i4.c sum_i8.c sum_r4.c sum_r8.c Added files: gcc/testsuite/gfortran.dg: reshape_rank7.f90 Log message: 2005-05-23 Thomas Koenig [EMAIL PROTECTED] Backport from mainline: PR libfortran/21354 PR libfortran/21075 * m4/cshift1.m4: Change dimension of auxiliary arrays from GFC_MAX_DIMENSION - 1 to GFC_MAX_DIMENSION. * m4/eoshift1.m4: Likewise. * m4/eoshift3.m4: Likewise. * m4/ifunction.m4: Likewise. * m4/in_pack.m4: Likewise. * m4/in_unpack.m4: Likewise. * m4/reshape.m4: Likewise. * intrinsics/cshift0.c: Likewise. * intrinsics/eoshift0.c: Likewise. * intrinsics/eoshift2.c: Likewise. * intrinsics/random.c: Likewise. * intrinsics/reshape_generic.c: Likewise. * intrinsics/spread_generic.c: Likewise. * intrinsics/stat.c: Likewise. * generated/all_l4.c: Regenerated. * generated/all_l8.c: Regenerated. * generated/any_l4.c: Regenerated. * generated/any_l8.c: Regenerated. * generated/count_4_l4.c: Regenerated. * generated/count_4_l8.c: Regenerated. * generated/count_8_l4.c: Regenerated. * generated/count_8_l8.c: Regenerated. * generated/cshift1_4.c: Regenerated. * generated/cshift1_8.c: Regenerated. * generated/eoshift1_4.c: Regenerated. * generated/eoshift1_8.c: Regenerated. * generated/eoshift3_4.c: Regenerated. * generated/eoshift3_8.c: Regenerated. * generated/in_pack_i4.c: Regenerated. * generated/in_pack_i8.c: Regenerated. * generated/in_unpack_i4.c: Regenerated. * generated/in_unpack_i8.c: Regenerated. * generated/maxloc1_4_i4.c: Regenerated. * generated/maxloc1_4_i8.c: Regenerated. * generated/maxloc1_4_r4.c: Regenerated. * generated/maxloc1_4_r8.c: Regenerated. * generated/maxloc1_8_i4.c: Regenerated. * generated/maxloc1_8_i8.c: Regenerated. * generated/maxloc1_8_r4.c: Regenerated. * generated/maxloc1_8_r8.c: Regenerated. * generated/maxval_i4.c: Regenerated. * generated/maxval_i8.c: Regenerated. * generated/maxval_r4.c: Regenerated. * generated/maxval_r8.c: Regenerated. * generated/minloc1_4_i4.c: Regenerated. * generated/minloc1_4_i8.c: Regenerated. * generated/minloc1_4_r4.c: Regenerated. * generated/minloc1_4_r8.c: Regenerated. * generated/minloc1_8_i4.c: Regenerated. * generated/minloc1_8_i8.c: Regenerated. * generated/minloc1_8_r4.c: Regenerated. * generated/minloc1_8_r8.c: Regenerated. * generated/minval_i4.c: Regenerated. * generated/minval_i8.c: Regenerated. * generated/minval_r4.c: Regenerated. * generated/minval_r8.c: Regenerated. * generated/product_c4.c: Regenerated. *
[Bug libfortran/21354] [4.0 only] Rank 7 not handled correctly
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-23 20:04 --- Subject: Bug 21354 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-05-23 20:03:53 Modified files: libgfortran: ChangeLog gcc/testsuite : ChangeLog libgfortran/m4 : cshift1.m4 eoshift1.m4 eoshift3.m4 ifunction.m4 in_pack.m4 in_unpack.m4 reshape.m4 libgfortran/intrinsics: cshift0.c eoshift0.c eoshift2.c random.c reshape_generic.c spread_generic.c stat.c libgfortran/generated: all_l4.c all_l8.c any_l4.c any_l8.c count_4_l4.c count_4_l8.c count_8_l4.c count_8_l8.c cshift1_4.c cshift1_8.c eoshift1_4.c eoshift1_8.c eoshift3_4.c eoshift3_8.c in_pack_i4.c in_pack_i8.c in_unpack_i4.c in_unpack_i8.c maxloc1_4_i4.c maxloc1_4_i8.c maxloc1_4_r4.c maxloc1_4_r8.c maxloc1_8_i4.c maxloc1_8_i8.c maxloc1_8_r4.c maxloc1_8_r8.c maxval_i4.c maxval_i8.c maxval_r4.c maxval_r8.c minloc1_4_i4.c minloc1_4_i8.c minloc1_4_r4.c minloc1_4_r8.c minloc1_8_i4.c minloc1_8_i8.c minloc1_8_r4.c minloc1_8_r8.c minval_i4.c minval_i8.c minval_r4.c minval_r8.c product_c4.c product_c8.c product_i4.c product_i8.c product_r4.c product_r8.c reshape_c4.c reshape_c8.c reshape_i4.c reshape_i8.c sum_c4.c sum_c8.c sum_i4.c sum_i8.c sum_r4.c sum_r8.c Added files: gcc/testsuite/gfortran.dg: reshape_rank7.f90 Log message: 2005-05-23 Thomas Koenig [EMAIL PROTECTED] Backport from mainline: PR libfortran/21354 PR libfortran/21075 * m4/cshift1.m4: Change dimension of auxiliary arrays from GFC_MAX_DIMENSION - 1 to GFC_MAX_DIMENSION. * m4/eoshift1.m4: Likewise. * m4/eoshift3.m4: Likewise. * m4/ifunction.m4: Likewise. * m4/in_pack.m4: Likewise. * m4/in_unpack.m4: Likewise. * m4/reshape.m4: Likewise. * intrinsics/cshift0.c: Likewise. * intrinsics/eoshift0.c: Likewise. * intrinsics/eoshift2.c: Likewise. * intrinsics/random.c: Likewise. * intrinsics/reshape_generic.c: Likewise. * intrinsics/spread_generic.c: Likewise. * intrinsics/stat.c: Likewise. * generated/all_l4.c: Regenerated. * generated/all_l8.c: Regenerated. * generated/any_l4.c: Regenerated. * generated/any_l8.c: Regenerated. * generated/count_4_l4.c: Regenerated. * generated/count_4_l8.c: Regenerated. * generated/count_8_l4.c: Regenerated. * generated/count_8_l8.c: Regenerated. * generated/cshift1_4.c: Regenerated. * generated/cshift1_8.c: Regenerated. * generated/eoshift1_4.c: Regenerated. * generated/eoshift1_8.c: Regenerated. * generated/eoshift3_4.c: Regenerated. * generated/eoshift3_8.c: Regenerated. * generated/in_pack_i4.c: Regenerated. * generated/in_pack_i8.c: Regenerated. * generated/in_unpack_i4.c: Regenerated. * generated/in_unpack_i8.c: Regenerated. * generated/maxloc1_4_i4.c: Regenerated. * generated/maxloc1_4_i8.c: Regenerated. * generated/maxloc1_4_r4.c: Regenerated. * generated/maxloc1_4_r8.c: Regenerated. * generated/maxloc1_8_i4.c: Regenerated. * generated/maxloc1_8_i8.c: Regenerated. * generated/maxloc1_8_r4.c: Regenerated. * generated/maxloc1_8_r8.c: Regenerated. * generated/maxval_i4.c: Regenerated. * generated/maxval_i8.c: Regenerated. * generated/maxval_r4.c: Regenerated. * generated/maxval_r8.c: Regenerated. * generated/minloc1_4_i4.c: Regenerated. * generated/minloc1_4_i8.c: Regenerated. * generated/minloc1_4_r4.c: Regenerated. * generated/minloc1_4_r8.c: Regenerated. * generated/minloc1_8_i4.c: Regenerated. * generated/minloc1_8_i8.c: Regenerated. * generated/minloc1_8_r4.c: Regenerated. * generated/minloc1_8_r8.c: Regenerated. * generated/minval_i4.c: Regenerated. * generated/minval_i8.c: Regenerated. * generated/minval_r4.c: Regenerated. * generated/minval_r8.c: Regenerated. * generated/product_c4.c: Regenerated. *
[Bug libfortran/21354] [4.0 only] Rank 7 not handled correctly
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-05-23 20:05 --- Fixed in 4.0. Closing. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21354
[Bug libgcj/21692] [4.1 Regression] unexpected java.lang.NoClassDefFoundError
-- What|Removed |Added Summary|unexpected |[4.1 Regression] unexpected |java.lang.NoClassDefFoundErr|java.lang.NoClassDefFoundErr |or |or Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21692
[Bug fortran/17031] Cray pointers not supported
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-05-23 20:10 --- According to a discussion on the fortran mailing list, some initial work seems to have been done: http://gcc.gnu.org/ml/fortran/2005-04/msg00071.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17031
[Bug libgcj/21714] [4.0/4.1 Regression] libjava bootstrap failure in java/lang/natConcreteProcess.cc
--- Additional Comments From cato at df dot lth dot se 2005-05-23 20:55 --- Subject: Re: [4.0/4.1 Regression] libjava bootstrap failure in java/lang/natConcreteProcess.cc This is not a BSD problem -- it is just that NetBSD 1.6 is old enough that threads were not as pervasive as they are now (and NetBSD takes long term maintenance seriously, so 1.6 is still a maintained release branch). What are the problems with the old implementation? Would it make sense to resurrect it as natProcessNoThread.c or something? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21714
[Bug c++/21727] New: accepts specialization without template
The code:
templatetypename T
struct foo { void check(); };
voidfoobool::check() {}
compiles without error even though it needs a template before the
specialization.
--
Summary: accepts specialization without template
Product: gcc
Version: 3.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21727
[Bug c++/21727] accepts specialization without template
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-23 21:57 --- Fixed in 4.0.0. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Keywords||accepts-invalid, diagnostic Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21727
[Bug middle-end/21728] New: Nonlocal gotos between nested functions cause undefined labels in assembler output
The following program:
void f(void)
{
void p(void)
{
__label__ l1;
void q(void)
{
goto l1;
}
l1:;
}
p();
}
int
main (void)
{
f();
return 0;
}
compiled using the following command line:
../gcc-lin/gcc/xgcc -B../gcc-lin/gcc/ c_jump2.c
gives me:
/tmp/ccSrSccf.o: In function `q.1137':
/tmp/ccSrSccf.o(.text+0x2d): undefined reference to `.L7'
collect2: ld returned 1 exit status
Output of ../gcc-lin/gcc/xgcc -B../gcc-lin/gcc/ -v:
Reading specs from ../gcc-lin/gcc/specs
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.0.0/configure --enable-languages=c
Thread model: posix
gcc version 4.0.0
The program works when I use `-O2' or `-O3' option (apparently
it works in unit at a time mode and does not work in function at
a time mode).
The problem affects GNU Pascal, I found the above C program trying
to find out why I get the above error from Pascal programs.
--
Summary: Nonlocal gotos between nested functions cause undefined
labels in assembler output
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hebisch at math dot uni dot wroc dot pl
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21728
[Bug fortran/21729] New: ICE in gfc_typenode_for_spec
module modice interface real function foo () end function end interface end module modice function foo () use modice implicit none ! foo = 6 end function foo ICEs in: internal compiler error: in gfc_typenode_for_spec, at fortran/trans-types.c:631 -- Summary: ICE in gfc_typenode_for_spec Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jakub at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21729
[Bug middle-end/21728] [4.0/4.1 Regression] Nonlocal gotos between nested functions cause undefined labels in assembler output
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-23 22:52 --- tree-cfg is removing the BB for some reason. I have no looked into why yet. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2005-05-23 22:53:00 date|| Summary|Nonlocal gotos between |[4.0/4.1 Regression] |nested functions cause |Nonlocal gotos between |undefined labels in |nested functions cause |assembler output|undefined labels in ||assembler output Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21728
[Bug fortran/19575] cdabs intrinsic incorrectly handled with -std=f95
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-23 22:57 --- Fixed since 4.0.0, someone forgot to close the bug. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19575
[Bug fortran/21729] ICE in gfc_typenode_for_spec
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-23 23:00 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-05-23 23:00:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21729
[Bug middle-end/21718] real.c rounding not perfect
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-05-23 23:55
---
Here is the example requested on IRC showing that we don't get it right with
DECIMAL_DIG digits and IEEE quad long double. Tested with current mainline on
sparc-sun-solaris2.10 as an example target where long double is IEEE quad.
Different examples may be needed for 64-bit hosts where we use more than 160
bits (but still not enough). DECIMAL_DIG is 36 for IEEE quad.
int
f (void)
{
if (0.0691986517009071585211899336165210746L
== 0x0.000397cecf54a352d2cf251cf4c2d40ap+0L)
return 1;
}
/* Above decimal is
0x3.97cecf54a352d2cf251cf4c2d4090006cfd...p-112,
which to within 0.5ulp (113-bit mantissa) should round up to above
hex value. Thus, there should be no warning with -O2 -Wall. */
My reading of F.5#2 is that conversions of all numbers with DECIMAL_DIG
significant figures are meant to be correct, not just of those which arise from
converting a representable binary number to decimal (which we probably do get
right). I don't think you'll get all conversions with DECIMAL_DIG digits right
without at least 226 bits internal precision, and proving that any specific
figure is enough would be hard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21718
[Bug fortran/21730] New: Character length incorrect.
character*2 a character*4 b parameter(a=12) parameter (b = a) write (*, *) b end gfortran output: 12 correct output: 12 -- Summary: Character length incorrect. Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fengwang at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org OtherBugsDependingO 19276 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21730
[Bug fortran/19276] [meta-bug] CHARACTER related bugs in gfortran
-- What|Removed |Added BugsThisDependsOn||21730 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19276
[Bug c++/21731] New: Loses two declartions for the price of one
The code:
class A {};
extern A* a;
namespace {
A* a;
}
int main() {
a = 0;
}
gets you:
~/ootbc/members/src$ g++ foo.cc
foo.cc: In function `int main()':
foo.cc:9: error: `a' undeclared (first use this function)
foo.cc:9: error: (Each undeclared identifier is reported only once for each
function it appears in.)
--
Summary: Loses two declartions for the price of one
Product: gcc
Version: 3.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21731
[Bug libstdc++/21674] basic_string vs debug_mode
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-05-24 04:22 --- Dudes, just a quick pass at this. a.out: /usr/lib/gcc/i386-redhat-linux/3.4.3/../../../../include/c++/3.4.3/bits/basic_string.h:643: typename _Alloc::reference std::basic_string_CharT, _Traits, _Alloc::operator[](typename _Alloc::size_type) [with _CharT = char, _Traits = std::char_traitschar, _Alloc = std::allocatorchar]: Assertion `__pos size()' failed. Abort (core dumped) I get this with 3.4 to mainline with -O1 or -O2. -benjamin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21674
[Bug libstdc++/21677] simply including ext/bitmap_allocator.h causes link-time errors
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-05-24 04:34 --- for 4.x and mainline, this is ok: %g++ -c -g -O2 t2.cc %g++ -c -g -O2 t1.cc %g++ t1.o t2.o For 3.4, I get: t2.o(.bss+0x0): In function `main': /home/bkoz/t2.cc:4: multiple definition of `__gnu_cxx::_BA_free_list_store::_S_free_list' t1.o(.bss+0x0):/usr/lib/gcc/i386-redhat-linux/3.4.3/../../../../include/c++/3.4.3/ext/bitmap_allocator.h:477: first defined here t2.o(.bss+0xc): In function `main': /home/bkoz/t2.cc:5: multiple definition of `__gnu_cxx::_BA_free_list_store::_S_bfl_mutex' t1.o(.bss+0xc):/usr/lib/gcc/i386-redhat-linux/3.4.3/../../../../include/c++/3.4.3/ext/bitmap_allocator.h:479: first defined here t2.o(.bss+0x24): In function `__tcf_1': /usr/lib/gcc/i386-redhat-linux/3.4.3/../../../../include/c++/3.4.3/bits/stl_vector.h:117: multiple definition of `__gnu_cxx::_OOM_handler::_S_oom_fcp' t1.o(.bss+0x24):/usr/lib/gcc/i386-redhat-linux/3.4.3/../../../../include/c++/3.4.3/ext/new_allocator.h:69: first defined here t2.o(.bss+0x28): In function `__tcf_1': /usr/lib/gcc/i386-redhat-linux/3.4.3/../../../../include/c++/3.4.3/ext/new_allocator.h:86: multiple definition of `__gnu_cxx::_OOM_handler::_S_handled_oom' t1.o(.bss+0x28):/home/bkoz/t1.cc:3: first defined here t2.o(.bss+0x2c): In function `__tcf_1': /usr/lib/gcc/i386-redhat-linux/3.4.3/../../../../include/c++/3.4.3/ext/new_allocator.h:86: multiple definition of `__gnu_cxx::_OOM_handler::_S_old_handler' t1.o(.bss+0x2c):/usr/lib/gcc/i386-redhat-linux/3.4.3/../../../../include/c++/3.4.3/i386-redhat-linux/bits/gthr-default.h:107: first defined here collect2: ld returned 1 exit status So, reproducible. __gnu_cxx::_BA_free_list_store::_S_bfl_mutex __gnu_cxx::_OOM_handler::_S_handled_oom __gnu_cxx::_OOM_handler::_S_old_handler The first symbol (the mutex) is solved for 4.x/mainline by the patch mentioned by Paolo. The other two, with a quick look at the code, will obviously cause multiple def errors. S dunno. I'm tempted to just say this allocator doesn't work in 3.4.x, and be done with it. There's been a lot of work done on it, and porting the 4.x code to 3.4.x is a non-starter. Sorry. -benjamin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21677
[Bug libstdc++/21677] simply including ext/bitmap_allocator.h causes link-time errors
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-05-24 04:36 --- Downgrade from critical, which extension allocators certainly are not. -benjamin -- What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21677
