[Bug tree-optimization/24851] [4.1 Regression] f2c miscompilation
--- Comment #1 from rguenth at gcc dot gnu dot org 2005-11-14 15:27 --- Created an attachment (id=10233) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10233action=view) testcase self-contained (but complete) yyparse function. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24851
[Bug tree-optimization/24851] [4.1 Regression] f2c miscompilation
--- Comment #2 from rguenth at gcc dot gnu dot org 2005-11-14 15:29 --- The problem is that with 31.ccp we introduce: bb 0: save1 = yylval; save2 = yyval; save3_92 = yynerrs; save4_94 = yyerrflag; yystate_95 = 0; yychar_96 = -1; yynerrs = 0; yyerrflag = 0; yyp_99 = yys[536870911]; goto bb 4 (yystack); ... # yychar_56 = PHI -1(0), -1(13), yychar_61(31), ... # yystate_52 = PHI 0(0), yystate_2511(13), yystate_2467(31), ... # yyp_48 = PHI yys[536870911](0), yyp_129(13), yyp_49(31), ... yystack:; yyp_129 = yyp_48 + 8B; D.1934_130 = yys[150]; if (yyp_129 = yys[150]) goto L4; else goto L5; L4:; yyerror (yacc stack overflow[0]); goto bb 2 (ret1); ... and later we will say that (yyp_129 = yys[150]) is always true because of this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24851
[Bug tree-optimization/24851] [4.1 Regression] f2c miscompilation
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||bonzini at gcc dot gnu dot ||org Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24851
[Bug c++/24848] g++ issues parse error on constructor template specialization.
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-14 15:38 --- *** This bug has been marked as a duplicate of 6259 *** -- 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=24848
[Bug c++/6259] Explicit instantiation of template constructor not allowed
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-14 15:38 --- *** Bug 24848 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||seefeld at sympatico dot ca http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6259
[Bug middle-end/24851] [4.1 Regression] f2c miscompilation
--- Comment #3 from rguenth at gcc dot gnu dot org 2005-11-14 15:40 ---
Reduced testcase:
void abort(void);
int main()
{
int a[10], *p;
p = a[-1];
if (p = a[9])
abort ();
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24851
[Bug target/24842] testsuite failure: gcc.dg/attr-weakref-1.c execution test
--- Comment #1 from aoliva at gcc dot gnu dot org 2005-11-14 15:41 --- Yeah, weakref support in the compiler is independent of .weakref support in the assembler. If .weakref is not available, the compiler will emulate that by always using the target symbol name, and deciding at the last minute whether to issue a .weak directive for the target or not. Will you please let me know what the excess errors are that you get, so that I can decide whether to delve into the issue myself or not? Thanks, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24842
[Bug middle-end/24851] [4.1 Regression] f2c miscompilation
--- Comment #4 from rguenth at gcc dot gnu dot org 2005-11-14 15:42 --- C++ frontend is fine. With C out of (.03.gimple) p = a + -4B; D.1282 = a + 36B; we (fold?) get (.10.cleanup_cfg) p = a[1073741823]; D.1282 = a[9]; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24851
[Bug middle-end/24851] [4.1 Regression] f2c miscompilation
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-14 15:42 ---
Confirmed, short testcase:
int f(void)
{
int i = -1;
int a[10];
int *b = a[2];
return a[i]=b;
}
int main(void)
{
if (f())
abort();
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2005-11-14 15:42:29
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24851
[Bug target/24718] Shared libgcc not used for linking by default
--- Comment #17 from sje at cup dot hp dot com 2005-11-14 15:44 --- Eric, can you be more specific about what won't work? The regression testing with Zack's patch seemed to go fine and hand testing some cases looks OK too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24718
[Bug target/24718] Shared libgcc not used for linking by default
--- Comment #18 from ebotcazou at gcc dot gnu dot org 2005-11-14 15:52 --- Eric, can you be more specific about what won't work? The regression testing with Zack's patch seemed to go fine and hand testing some cases looks OK too. Do you have a eh_dummy.o file for both -milp32 and -mlp64? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24718
[Bug middle-end/24851] [4.1 Regression] f2c miscompilation
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-14 15:56 --- The problem here is that we are comparing in unsigned when we shoud be comparing in a signed type. This was introduced by: 2005-01-29 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/15791 * fold-const.c (extract_array_ref): New function. (fold): Fold comparisons between a[i] and a[j] or semantically equivalent trees. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24851
[Bug target/24718] Shared libgcc not used for linking by default
--- Comment #19 from sje at cup dot hp dot com 2005-11-14 16:01 --- Yes, I checked the installed libgcc_eh.a (lib/gcc/ia64-hp-hpux11.23/3.4.5/libgcc_eh.a and lib/gcc/ia64-hp-hpux11.23/3.4.5/hpux64/libgcc_eh.a) and both contain eh_dummy.o. I do not getting any warnings messages from ld when compiling and linking C or C++, with or without -mlp64 and with or without -shared. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24718
[Bug tree-optimization/24709] [4.1 Regression] 4.1.0 HEAD crashes with enable-checking on huge switch statement
--- Comment #7 from amacleod at redhat dot com 2005-11-14 16:01 --- Subject: Bug 24709 Author: amacleod Date: Sun Nov 13 16:09:14 2005 New Revision: 106865 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106865 Log: PR tree-optimization/24709 * tree-ssa-operands.c (verify_imm_links): Increase limit for infinite loop check. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-operands.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24709
[Bug c++/24852] New: [4.0 regression] Segmentation fault (infinite recursion in cgraph_clone_inlined_nodes)
// compile this with -O3 to get segfault on 4.0.3,
// note the warning: inline function 'A::~A()' used but never defined.
// 3.3 and 4.1 accept this code without warning.
// This bug was originally reported by Alexey Maximov [EMAIL PROTECTED]
struct A;
templateclass T
struct P
{
P() : p(0) { }
~P();
T *p;
};
templateclass T
PT::~P()
{
delete p;
}
struct Q : private PA
{
};
struct V
{
virtual ~V();
};
#pragma interface
struct A
{
V d;
Q p;
};
struct T
{
T ();
Q q;
};
T::T ()
{
}
--
Summary: [4.0 regression] Segmentation fault (infinite recursion
in cgraph_clone_inlined_nodes)
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: belyshev at depni dot sinp dot msu dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24852
[Bug c++/24852] [4.0 regression] Segmentation fault (infinite recursion in cgraph_clone_inlined_nodes)
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-14 16:04 --- This is a dup of bug 24248 which in turn is a dup of bug 22252. *** This bug has been marked as a duplicate of 22252 *** -- 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=24852
[Bug c++/22252] [4.0 Regression] pragma interface/implementation still break synthesized methods
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-11-14 16:04 --- *** Bug 24852 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||belyshev at depni dot sinp ||dot msu dot ru http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22252
[Bug target/24718] Shared libgcc not used for linking by default
--- Comment #20 from bugzilla-gcc at thewrittenword dot com 2005-11-14 16:07 --- (In reply to comment #19) Yes, I checked the installed libgcc_eh.a (lib/gcc/ia64-hp-hpux11.23/3.4.5/libgcc_eh.a and lib/gcc/ia64-hp-hpux11.23/3.4.5/hpux64/libgcc_eh.a) and both contain eh_dummy.o. I do not getting any warnings messages from ld when compiling and linking C or C++, with or without -mlp64 and with or without -shared. Odd. We have the latest linker patch installed on our system (PHSS_33349) and applying Eric's patch added eh_dummy.o to libgcc_eh.a but the linker still gave a warning. I guess 'struct eh_dummy;' didn't add enough symbolic information to the archive library. Change it to 'int __libgcc_eh_dummy;' worked for us. Looking at Zack's patch, I don't see how eh_dummy.o would get added to libgcc_eh.a on gcc-3.4 without adding it to $libgcc2_eh_static_objs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24718
[Bug target/24718] Shared libgcc not used for linking by default
--- Comment #21 from ebotcazou at gcc dot gnu dot org 2005-11-14 16:09 --- Yes, I checked the installed libgcc_eh.a (lib/gcc/ia64-hp-hpux11.23/3.4.5/libgcc_eh.a and lib/gcc/ia64-hp-hpux11.23/3.4.5/hpux64/libgcc_eh.a) and both contain eh_dummy.o. I do not getting any warnings messages from ld when compiling and linking C or C++, with or without -mlp64 and with or without -shared. I must have dreamt... could you send to [EMAIL PROTECTED] the patched 3.4.x mklibgcc.in as well as the generated $objdir/gcc/libgcc.mk? Thanks in advance. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24718
[Bug target/24850] [4.1 regression] bootstrap failure on m68k-linux
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||build, ice-on-valid-code Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24850
[Bug middle-end/24853] New: scheduling takes 40% or more time
For current mainline and Apple 3.3/4.0, the top pass in the profile is scheduling: 14.99 (42%) usr 4.32 (75%) sys 19.32 (46%) wall Note that at -O0, instead, it is global alloc : 1.06 (30%) usr 0.03 ( 5%) sys 1.09 (26%) wall but I doubt we can do much about it. -- Summary: scheduling takes 40% or more time Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: compile-time-hog Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bonzini at gcc dot gnu dot org GCC host triplet: powerpc-apple-darwin8.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24853
[Bug middle-end/24853] scheduling takes 40% or more time
--- Comment #1 from bonzini at gcc dot gnu dot org 2005-11-14 16:22 --- Created an attachment (id=10234) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10234action=view) file used for benchmarking -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24853
[Bug middle-end/24851] [4.1 Regression] f2c miscompilation
--- Comment #7 from rguenth at gcc dot gnu dot org 2005-11-14 16:27 ---
Valid testcase (?):
void abort(void);
int main()
{
int a[10], *p, *q;
q = a[1];
p = q[-1];
if (p = a[9])
abort ();
return 0;
}
fold_stmt is doing the a[0] + -4B to a[1073741823] transformation. But it
somehow looks the C representation of a[X] with pointer addition is not a
good idea. The C++ frontend makes out of the above
int main() ()
{
int a[10];
bb 0:
if (a[9] = a[1073741824]) goto L0; else goto L1;
L0:;
abort ();
L1:;
return 0;
}
I'm unsure how to fix this without completely disabling the comparison
folding for anything but == and !=.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24851
[Bug target/24718] Shared libgcc not used for linking by default
--- Comment #22 from ebotcazou at gcc dot gnu dot org 2005-11-14 16:28 --- Odd. We have the latest linker patch installed on our system (PHSS_33349) and applying Eric's patch added eh_dummy.o to libgcc_eh.a but the linker still gave a warning. I guess 'struct eh_dummy;' didn't add enough symbolic information to the archive library. Change it to 'int __libgcc_eh_dummy;' worked for us. It could be nice to compare the versions of 'ar' and 'ranlib' you have. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24718
[Bug target/24718] Shared libgcc not used for linking by default
--- Comment #23 from sje at cup dot hp dot com 2005-11-14 16:33 --- I build binutils 2.16 as part of my GCC build/test so I used that ar and ranlib when building GCC: ar --version GNU ar 2.16.91 20051103 Copyright 2005 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. ranlib --version GNU ranlib 2.16.91 20051103 Copyright 2005 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24718
[Bug target/24718] Shared libgcc not used for linking by default
--- Comment #24 from bugzilla-gcc at thewrittenword dot com 2005-11-14 16:59 --- (In reply to comment #23) I build binutils 2.16 as part of my GCC build/test so I used that ar and ranlib when building GCC: We're using the system ar/ranlib. I built binutils-2.16 with _no_ patches but ar doesn't work: $ ./ar /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yylsp' in load module '/usr/lib/hpux32/libl.so.1'. /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yyolsp' in load module '/usr/lib/hpux32/libl.so.1'. /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yyfnd' in load module '/usr/lib/hpux32/libl.so.1'. /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yytextuc' in load module '/usr/lib/hpux32/libl.so.1'. /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yylenguc' in load module '/usr/lib/hpux32/libl.so.1'. /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yylstate' in load module '/usr/lib/hpux32/libl.so.1'. /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yyprevious' in load module '/usr/lib/hpux32/libl.so.1'. /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yytextarr' in load module '/usr/lib/hpux32/libl.so.1'. /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yyextra' in load module '/usr/lib/hpux32/libl.so.1'. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24718
[Bug middle-end/24851] [4.1 Regression] f2c miscompilation
--- Comment #8 from rguenth at gcc dot gnu dot org 2005-11-14 17:03 --- Patch to avoid the situation posted. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||11/msg00996.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24851
[Bug middle-end/24851] [4.1 Regression] f2c miscompilation
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-11-14 17:04 --- (In reply to comment #8) Patch to avoid the situation posted. So this patch makes the real bug latent. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added URL|http://gcc.gnu.org/ml/gcc- | |patches/2005- | |11/msg00996.html| Keywords|patch | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24851
[Bug target/24718] Shared libgcc not used for linking by default
--- Comment #25 from sje at cup dot hp dot com 2005-11-14 17:05 --- I build binutils with --disable-shared and using flex/bison instead of lex/yacc, that is probably why my ar works. I experimented with the use of the system ar/ranlib by just building eh_dummy.o and .a by hand and they look OK to me, I.e. they have a symbol table in them and thus should not get the warning message. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24718
[Bug target/24718] Shared libgcc not used for linking by default
--- Comment #26 from bugzilla-gcc at thewrittenword dot com 2005-11-14 17:18 --- (In reply to comment #25) I build binutils with --disable-shared and using flex/bison instead of lex/yacc, that is probably why my ar works. I experimented with the use of the system ar/ranlib by just building eh_dummy.o and .a by hand and they look OK to me, I.e. they have a symbol table in them and thus should not get the warning message. Ok, I have a working binutils-2.16 ar. And, binutils-2.16 ar creates a libgcc_eh.a that does not cause linker errors whereas HP as does _not_, with the _same_ eh_dummy.o file. Replace your libgcc_eh.a in your GCC tree with the version created by the system ar and I expect you'll see the same as me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24718
[Bug fortran/24828] Z and negative integers
--- Comment #2 from kargl at gcc dot gnu dot org 2005-11-14 17:25 --- Gfortran is doing the right thing with respect to a BOZ-literal-constant (other than a BOZ can only be used in a DATA statement per the F95 standard, so the code is invalid). If you look at the definition of BOZ in the standard, you'll find that a BOZ is converted to an integer of the largest available kind. In this case, it appears that integer(8) is the largest kind, so it's converted to that type and kind. The program assigns this integer(8) value to an integer(4), which explains the (int8) cast in the if statement. -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||kargl at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24828
[Bug target/24718] Shared libgcc not used for linking by default
--- Comment #27 from sje at cup dot hp dot com 2005-11-14 17:26 --- In your last comment you mention the binutils ar, but later the binutils as. I cannot reproduce the problem by just using the binutils ar command but I can reproduce it using the binutils as (assembler) command. Which assembler are you using when you get the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24718
[Bug fortran/24828] Z and negative integers
--- Comment #3 from kargl at gcc dot gnu dot org 2005-11-14 17:29 --- Remove wrong-code keyword because gfortran is doing the correct thing with a BOZ-literal-constant with the exception of permitting BOZ-literal-constant in non-DATA statements. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Keywords|wrong-code | Last reconfirmed|2005-11-12 23:53:06 |2005-11-14 17:29:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24828
[Bug middle-end/24851] [4.1 Regression] f2c miscompilation
--- Comment #10 from pinskia at gcc dot gnu dot org 2005-11-14 17:29 --- Actually I was wrong on which patch caused/exposed this, This was caused by: 2005-05-14 Richard Guenther [EMAIL PROTECTED] * fold-const.c (div_if_zero_remainder): New function. (try_move_mult_to_index): Use it. div_if_zero_remainder uses the unsigned ness of the domain, which is wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24851
[Bug target/24718] Shared libgcc not used for linking by default
--- Comment #28 from bugzilla-gcc at thewrittenword dot com 2005-11-14 17:29 --- (In reply to comment #27) In your last comment you mention the binutils ar, but later the binutils as. I cannot reproduce the problem by just using the binutils ar command but I can reproduce it using the binutils as (assembler) command. Which assembler are you using when you get the problem. Oops. HP as - HP ar. So, with a eh_dummy.o created from an eh_dummy.c with 'struct eh_dummy;', libgcc_eh.a created by HP ar gives me a linker warning and a libgcc_eh.a created by binutils-2.16 ar does not give me a linker warning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24718
[Bug target/24718] Shared libgcc not used for linking by default
--- Comment #29 from sje at cup dot hp dot com 2005-11-14 17:31 --- In my comment I meant to say I could reproduce the problem with the HP assembler, but not with the GNU assembler (even if I use the GNU ar). I will test some more combinations. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24718
[Bug middle-end/24851] [4.1 Regression] f2c miscompilation
--- Comment #11 from pinskia at gcc dot gnu dot org 2005-11-14 17:31 --- div_if_zero_remainder assumes that the type of the agruments comming in are the same. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24851
[Bug target/24718] Shared libgcc not used for linking by default
--- Comment #30 from sje at cup dot hp dot com 2005-11-14 17:35 --- OK, I have reproduced it with GNU as (assembler) and HP ar. Should we bypass the whole issue by putting 'int __libgcc_eh_dummy;' in eh_dummy.o and use that as the 3.4 patch? I am willing to test and submit such a patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24718
[Bug tree-optimization/24309] [4.1 Regression] ICE with -O3 -ftree-loop-linear
--- Comment #9 from janis at gcc dot gnu dot org 2005-11-14 17:39 --- A regression hunt on powerpc-linux shows that the testcase from comment #8 starts failing with this large merge from the autovect branch, within the date range that the submitter identified: http://gcc.gnu.org/viewcvs?view=revrev=102356 r102356 | irar | 2005-07-25 12:05:07 + (Mon, 25 Jul 2005) | 83 lines A regression hunt on powerpc-linux using the testcase from comment #2 identified this patch; the original larger testcase fails at the same place: http://gcc.gnu.org/viewcvs?view=revrev=88404 r88404 | rakdver | 2004-10-01 18:26:37 + (Fri, 01 Oct 2004) | 9 lines * common.opt (ftree-loop-ivcanon): Enable by default. * tree-ssa-loop-ivcanon.c (try_unroll_loop_completely): Enable complete loop unrolling. (canonicalize_induction_variables, tree_unroll_loops_completely): Reset scev info. * gcc.dg/tree-ssa/loop-1.c: Check that unrolling occurs already on tree level. The reghunts used -O2 -ftree-loop-linear. Let me know if there are other options that could be used to find earlier failures. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24309
[Bug target/24718] Shared libgcc not used for linking by default
--- Comment #31 from bugzilla-gcc at thewrittenword dot com 2005-11-14 17:41 --- Sure. I don't understand how Zack's patch works but as long as we have a solution that works, fine by me. Eric might be interested in reviewing the patch too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24718
[Bug target/24718] Shared libgcc not used for linking by default
--- Comment #32 from sje at cup dot hp dot com 2005-11-14 17:46 --- Do you see this problem on the Top-of-tree and/or 4.0 sources? That seems to use the same eh_dummy.c file (struct eh_dummy;) as 3.4. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24718
[Bug target/24718] Shared libgcc not used for linking by default
--- Comment #33 from bugzilla-gcc at thewrittenword dot com 2005-11-14 17:51 --- (In reply to comment #32) Do you see this problem on the Top-of-tree and/or 4.0 sources? That seems to use the same eh_dummy.c file (struct eh_dummy;) as 3.4. 4.0.2 had the same problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24718
[Bug target/24718] Shared libgcc not used for linking by default
--- Comment #34 from ebotcazou at gcc dot gnu dot org 2005-11-14 17:51 --- Sure. I don't understand how Zack's patch works but as long as we have a solution that works, fine by me. Eric might be interested in reviewing the patch too. The misunderstanding has been cleared with Steve. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24718
[Bug c++/23171] [4.1 Regression] ICE on pointer initialization with C99 initializer
--- Comment #10 from mark at codesourcery dot com 2005-11-14 17:59 --- Subject: Re: [4.1 Regression] ICE on pointer initialization with C99 initializer giovannibajo at libero dot it wrote: --- Comment #9 from giovannibajo at libero dot it 2005-11-14 00:30 --- Mark, do you believe that the introduction of COMPOUND_LITERAL_EXPR in the C++ frontend could be feasable for 4.1? It's possible, but I somewhat doubt it. I'm afraid we won't know all the places that need to change. I'd actually like to understand better why the middle-end is no longer able to handle CONSTRUCTORs as it used to; this was a change in the middle-end interface at some point. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23171
[Bug middle-end/24853] scheduling takes 40% or more time
--- Comment #2 from bonzini at gcc dot gnu dot org 2005-11-14 18:12 --- Top of the profile: 1051747.2325 cc1 cc1sched_analyze_insn 98121 6.7475 cc1 cc1free_deps 89078 6.1256 cc1 cc1bitmap_set_bit 63000 4.3323 cc1 cc1free_list 48690 3.3482 cc1 cc1alloc_INSN_LIST 39632 2.7254 cc1 cc1compute_global_livein 26382 1.8142 cc1 cc1free_INSN_LIST_list 25567 1.7582 cc1 cc1bitmap_bit_p -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24853
[Bug c++/23171] [4.1 Regression] ICE on pointer initialization with C99 initializer
--- Comment #11 from dberlin at gcc dot gnu dot org 2005-11-14 18:14 --- Mark, the frontend is producing the address of a constructor, and nothing in the middle end used to be really analyzing static iniatlizers which is why it didn't break before (those that do try to look at them would give up in this case, but static vars analysis can't give up without destroying the results of the entire analysis) IMHO, this easier to fix in the frontend than in the middle end, by simply not producing CONSTRUCTOR. What exactly is ADDRESSOF(CONSTRUCTOR) anyway? ISTM it should require a temporary variable to evaluate. However, we can't GIMPLIFY it and do that for you because it's a static initializer (and we don't gimplify those), so it's either teach *every single thing that wants to look at DECL_INITIAL for a static initializer* what ADDRESSOF(CONSTUCTOR) is supposed to mean, or make the frontend do something like split it into two variables. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23171
[Bug middle-end/24853] scheduling takes 40% or more time
-- bonzini at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-14 18:15:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24853
[Bug tree-optimization/24309] [4.1 Regression] ICE with -O3 -ftree-loop-linear
--- Comment #10 from dberlin at gcc dot gnu dot org 2005-11-14 18:18 --- It probably did *nothing at all* before the merge. The ICE is not too hard to fix, i just haven't gotten to it yet I will hopefully soon. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24309
[Bug middle-end/24853] scheduling takes 40% or more time
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2005-11-14 18:21 --- For current mainline and Apple 3.3/4.0, the top pass in the profile is scheduling: 14.99 (42%) usr 4.32 (75%) sys 19.32 (46%) wall Is it the first scheduling pass? If so, we have a patch at AdaCore to limit its explosion. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24853
[Bug middle-end/24853] scheduling takes 40% or more time
--- Comment #4 from paolo dot bonzini at lu dot unisi dot ch 2005-11-14 18:26 --- Subject: Re: scheduling takes 40% or more time Is it the first scheduling pass? If so, we have a patch at AdaCore to limit its explosion. Yes, it is. schedule_insns2 takes nothing. Paolo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24853
[Bug c++/23171] [4.1 Regression] ICE on pointer initialization with C99 initializer
--- Comment #12 from mark at codesourcery dot com 2005-11-14 18:27 --- Subject: Re: [4.1 Regression] ICE on pointer initialization with C99 initializer dberlin at gcc dot gnu dot org wrote: --- Comment #11 from dberlin at gcc dot gnu dot org 2005-11-14 18:14 --- Mark, the frontend is producing the address of a constructor, and nothing in the middle end used to be really analyzing static iniatlizers which is why it didn't break before (those that do try to look at them would give up in this case, but static vars analysis can't give up without destroying the results of the entire analysis) OK, that's a good summary of the key change. My point was simply that this is not something new the front-end started doing; it's been using this construct to mean address of a temporary for a long time. IMHO, this easier to fix in the frontend than in the middle end, by simply not producing CONSTRUCTOR. I agree that, at least, the best fix is in the front-end. However, it probably won't be trivial to do. If the problem only affects static initializers, then we should probably try to localize the change to that code, rather than trying to introduce COMPOUND_LITERAL_EXPR throughout the front end at this point. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23171
[Bug target/24842] testsuite failure: gcc.dg/attr-weakref-1.c execution test
--- Comment #2 from hp at gcc dot gnu dot org 2005-11-14 18:35 --- In response to comment #1 regarding excess errors, see the original description: I don't get any, I just get a call to abort when the test-program is executed (as you know, the *** EXIT code 4242 is the status-wrapper's way of telling this). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24842
[Bug libgcj/24834] PersistentByteMap close() method is not catching Exception
--- Comment #2 from m4341 at abc dot se 2005-11-14 18:42 --- This was detected by opening the whole set of Java files in Eclipse (and not having any standard Java library at all selected). The close method stood out as an error. since it was declared to throw an exception in the classes AbstractInterruptibleChannel and FileChannel, but when used in PersistentByteMap it was not caught. I did this as an effort to try to strip out the parts I didn't need like AWT and then I encountered this. I hope that this is sufficient as an explanation to the bug. It doesn't seem to be critical. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24834
[Bug middle-end/24851] [4.1 Regression] f2c miscompilation
--- Comment #12 from pinskia at gcc dot gnu dot org 2005-11-14 18:47 --- Note we haveyyp = yys[-1]; (where yys is an array) in the orginal testcase so that is undefined. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24851
[Bug middle-end/24853] scheduling takes 40% or more time
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2005-11-14 18:50 --- Created an attachment (id=10236) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10236action=view) Patch (against 3.4.x) for controlling the explosion of the 1st scheduling pass. * params.def (PARAM_MAX_SCHED_READY_INSNS): New parameter, defaulting to 100. * params.h (MAX_SCHED_READY_INSNS): New macro. * haifa-sched.c: Include param.h. (queue_to_ready): Re-queue insns past MAX_SCHED_READY_INSNS for the next cycle during the first scheduling pass. (schedule_block): Delay insns past MAX_SCHED_READY_INSNS in the ready list for 1 cycle during the first scheduling pass. * doc/invoke.texi (--param): New parameter max-sched-ready-insns. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24853
[Bug middle-end/24851] [4.1 Regression] f2c miscompilation
--- Comment #13 from pinskia at gcc dot gnu dot org 2005-11-14 19:08 --- I have a fix for the only valid testcase (comment #7) here. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24851
[Bug middle-end/24851] [4.1 Regression] f2c miscompilation
--- Comment #14 from pinskia at gcc dot gnu dot org 2005-11-14 19:09 --- (In reply to comment #13) I have a fix for the only valid testcase (comment #7) here. s/valid/defined/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24851
[Bug target/24831] [4.1 regression] gthr-dce.h:77: error: expected expression before '{' token
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2005-11-14
19:15 ---
Subject: Re: [4.1 regression] gthr-dce.h:77: error: expected expression before
'{' token
So is pthread_key_delete not declared in HP-UX's DCE headers? Is it actually
the correct spelling, or have we always had a harmless typo in gthr-dce.h? It
looks suspicious because pthread_keycreate doesn't have the second underscore.
It's not declared, and as far as I can tell, not available in HP-UX 10.20.
pthread_keycreate is available. I don't have DCE threads installed under
HP-UX 11 but the functions are pthread_key_create and pthread_key_delete
for the posix threads library.
Anyhow, it seems to me like we could simply remove or comment out the
pthread_key_delete line, since this function is not used anywhere.
Could you please test such a change? Thanks,
I'll test it when my current build completes.
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24831
[Bug libgcj/24832] Modularization of Java libraries
--- Comment #2 from m4341 at abc dot se 2005-11-14 19:18 --- Created an attachment (id=10237) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10237action=view) Proposal for the initial split. This is the initial split I did, and I must admit that it isn't thoroughly tested. There are one text file for each module I created. The text file contains an initial dependency description and a list of files incorporated in that module. In addition to this there is one Java-file with code modified to dynamically load the DefaultContentHandlerFactory that now resides in the AWT package from the URLConnection class. This wasn't necessary earlier. Beware that this is completely untested and I see it as a proposed modification. I REALLY wanted to break out the security classes too, since they have a significant size and aren't really needed on an embedded system. This is my minimal effort breakup - it could have been even better. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24832
[Bug c++/24847] Instantiates un-called copy constructor
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-14 19:32 --- Comeau also rejects this. I don't understand why we are trying to instantiate fooint, 5, b::foo(fooint, 0, b) except to try to match the constructor, so maybe this is invalid after all. Some one else really needs to look at this. A weird testcase at best. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24847
[Bug ada/24855] New: Missing stdarg.h in ada/raise.c for arm-rtems
From Joel Sherril arm-rtems4.7 - C, C++ OK. Ada fails with this: ../../xgcc -B../../ -c -DCROSS_COMPILE -DIN_GCC `echo -g -O2 -Dinhibit_libc -fno-inline -fexceptions -DIN_RTS |sed -e 's/-pedantic//g' -e 's/-Wtraditional//g'` \ -I. -I.. -I../.. -I/home/joel/gcc-work/head/gcc-head-test/gcc/ada -I/home/joel/gcc-work/head/gcc-head-test/gcc/ada/../config -I/home/joel/gcc-work/head/gcc-head-test/gcc/ada/../../include -I/home/joel/gcc-work/head/gcc-head-test/gcc/ada/.. -I./../.. raise.c -o raise.o raise.c: In function 'db': raise.c:233: error: 'va_list' undeclared (first use in this function) raise.c:233: error: (Each undeclared identifier is reported only once raise.c:233: error: for each function it appears in.) raise.c:233: error: expected ';' before 'msg_args' raise.c:237: error: 'msg_args' undeclared (first use in this function) raise.c: In function 'get_region_description_for': raise.c:595: warning: pointer targets in assignment differ in signedness -- Summary: Missing stdarg.h in ada/raise.c for arm-rtems Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: laurent at guerby dot net GCC target triplet: arm-rtems http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24855
[Bug tree-optimization/24840] [4.1 Regression] ICE process_assert_insertions_for, at tree-vrp.c:2807
--- Comment #8 from janis at gcc dot gnu dot org 2005-11-14 19:40 --- A regression hunt on powerpc-linux using -O2 with the testcase in comment #7 identified the following large patch: http://gcc.gnu.org/viewcvs?view=revrev=100478 r100478 | dnovillo | 2005-06-02 02:57:15 + (Thu, 02 Jun 2005) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24840
[Bug middle-end/24827] FAIL: gcc.dg/attr-weakref-1.c
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2005-11-14 19:40 --- Subject: Re: FAIL: gcc.dg/attr-weakref-1.c Does this target actually support weak declarations? It appears to me that it only does when the assembler supports .weak, but even then, the linker will object to undefined weak symbols, which is something this test relies on. I suppose we'd have to mark it as an XFAIL on hpux, or use some alternate dg-require to indicate we need the ability to refer to undefined weak symbols. See PR 23387. The HP linkers and dynamic loaders don't like undefined weak symbols. GAS provides support for .weak using SOM secondary definition symbols on the 32-bit port. We use this under HP-UX 11 and it is good enough for most purposes. However, the semantics differ from that defined in the sysv ABI. The 64-bit support is a little better supported by the linker, but the dynamic linker still doesn't like undefined weak symbols. We don't support .weak' under HP-UX 10 due to linker bugs. Either XFAIL or dg-require would be ok. If more tests are likely to be added, maybe dg-require would be better. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24827
[Bug c/24856] New: call to setlocale doesn't return expected value
-- Summary: call to setlocale doesn't return expected value Product: gcc Version: 3.4.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tedoc2000 at gmail dot com GCC build triplet: powerpc-ibm-aix4.3.2.0 GCC host triplet: powerpc-ibm-aix4.3.2.0 GCC target triplet: powerpc-ibm-aix4.3.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24856
[Bug ada/24857] New: ada/s-auxdec.ads alignment issue for arm-rtems
From Joel Sherrill:
Gcc on the head fails to compile arm-rtems4.7 at the following point
when Ada is enabled.
../../xgcc -B../../ -c -g -O2 -W -Wall -gnatpg s-auxdec.adb -o
s-auxdec.o
s-auxdec.ads:286:13: alignment for Aligned_Word must be at least 4
The code is:
type Aligned_Word is record
Value : Short_Integer;
end record;
for Aligned_Word'Alignment use
Integer'Min (2, Standard'Maximum_Alignment);
I (Laurent) think Standard'Maximum_Alignment comes from ada/targtyps.c
get_target_maximum_alignment (void)
{
return BIGGEST_ALIGNMENT / BITS_PER_UNIT;
}
Joel confirmed that changing Min (2 to Min (4 enable this file to be
compiled, however my reading of the source would imply that BIGGEST_ALIGNMENT
is at least 32 on arm, so something else must be at play here, any idea?
--
Summary: ada/s-auxdec.ads alignment issue for arm-rtems
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: build
Severity: normal
Priority: P3
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: laurent at guerby dot net
GCC target triplet: arm-rtems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24857
[Bug c/24856] call to setlocale doesn't return expected value
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-14 19:48 --- Why do you think this is a GCC bug? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24856
[Bug ada/24855] Missing stdarg.h in ada/raise.c for arm-rtems
--- Comment #1 from joel at gcc dot gnu dot org 2005-11-14 19:48 --- Created an attachment (id=10238) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10238action=view) Simple fix This is the simplest way to fix this bug. I just added an include of stdarg.h but I don't know if this is the right place or if it should be protected by some conditional compilation flags. It fixes the problem and arm-rtems4.7 compiles. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24855
[Bug libfortran/21468] vectorizing libfortran
--- Comment #7 from jb at gcc dot gnu dot org 2005-11-14 19:48 --- Subject: Bug 21468 Author: jb Date: Mon Nov 14 19:48:31 2005 New Revision: 106898 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106898 Log: 2005-11-14 Janne Blomqvist [EMAIL PROTECTED] PR fortran/21468 * Makefile.am: Add -ftree-vectorize for compiling matmul. * m4/matmul.m4: Add const and restrict to type declarations as appropriate. * m4/matmull.m4: Likewise. * Makefile.in: Regenerated. * generated/matmul_*.c: Likewise. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/Makefile.am trunk/libgfortran/Makefile.in trunk/libgfortran/generated/matmul_c10.c trunk/libgfortran/generated/matmul_c16.c trunk/libgfortran/generated/matmul_c4.c trunk/libgfortran/generated/matmul_c8.c trunk/libgfortran/generated/matmul_i16.c trunk/libgfortran/generated/matmul_i4.c trunk/libgfortran/generated/matmul_i8.c trunk/libgfortran/generated/matmul_l16.c trunk/libgfortran/generated/matmul_l4.c trunk/libgfortran/generated/matmul_l8.c trunk/libgfortran/generated/matmul_r10.c trunk/libgfortran/generated/matmul_r16.c trunk/libgfortran/generated/matmul_r4.c trunk/libgfortran/generated/matmul_r8.c trunk/libgfortran/m4/matmul.m4 trunk/libgfortran/m4/matmull.m4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21468
[Bug tree-optimization/24840] [4.1 Regression] ICE process_assert_insertions_for, at tree-vrp.c:2807
--- Comment #9 from dnovillo at gcc dot gnu dot org 2005-11-14 19:50 --- Working on it. -- dnovillo at gcc dot gnu dot org changed: What|Removed |Added CC|dnovillo at gcc dot gnu dot | |org | AssignedTo|unassigned at gcc dot gnu |dnovillo at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24840
[Bug other/24829] [4.1 Regression] libobjc testsuite failures
--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2005-11-14 19:51 --- Subject: Re: [4.1 Regression] libobjc testsuite failures worked with the #pragma weaks. Or would it? Anyhow, please confirm how you configured the compiler. I'm particularly interested in what assembler you're using, and what `grep HAVE_GAS_WEAK gcc/auto-host.h' prints. /* Define if your assembler supports .weak. */ #ifndef USED_FOR_TARGET #define HAVE_GAS_WEAK 1 #endif /* Define if your assembler supports .weakref. */ #ifndef USED_FOR_TARGET #define HAVE_GAS_WEAKREF 1 #endif I think that GAS shouldn't advertise .weakref support under hppa-hpux. Support for the HP assembler which doesn't have weak support is nearly dead. All recent versions of GAS have .weak support. I'm using the following gas versions at the moment: -bash-2.05b$ /opt/gnu/bin/as --version GNU assembler 2.16.91 20051106 Copyright 2005 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. This assembler was configured for a target of `hppa2.0w-hp-hpux11.11'. -bash-2.05b$ /opt/gnu64/bin/as --version GNU assembler 2.16.91 20051106 Copyright 2005 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. This assembler was configured for a target of `hppa64-hp-hpux11.11'. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24829
[Bug bootstrap/24859] New: Unrecognized opcode bootstrapping gcc on AIX 5/POWER
Hello, I am trying to bootstrap GCC 4.0.2 on AIX 5.1L (POWER architecture). make bootstrap runs for awhile, then dies with this error: ./xgcc -B./ -B/usr/local/powerpc-ibm-aix5.1.0.0/bin/ -isystem /usr/local/powerpc-ibm-aix5.1.0.0/include -isystem /usr/local/powerpc-ibm-aix5.1.0.0/sys-include -L/home/jgoerzen/programs/gccbuild/objdir/gcc/../ld -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I -I../../gcc-4.0.2/gcc -I../../gcc-4.0.2/gcc/ -I../../gcc-4.0.2/gcc/../include -I../../gcc-4.0.2/gcc/../libcpp/include -mcpu=power -c ../../gcc-4.0.2/gcc/config/rs6000/darwin-ldouble.c -o libgcc/power/darwin-ldouble.o /tmp//cc5orZlk.s: Assembler messages: /tmp//cc5orZlk.s:207: Error: Unrecognized opcode: `fmsub' /tmp//cc5orZlk.s:293: Error: Unrecognized opcode: `fmsub' make[3]: *** [libgcc/power/darwin-ldouble.o] Error 1 make[3]: Leaving directory `/home/jgoerzen/programs/gccbuild/objdir/gcc' make[2]: *** [stmp-multilib] Error 2 make[2]: Leaving directory `/home/jgoerzen/programs/gccbuild/objdir/gcc' make[1]: *** [stage1_build] Error 2 make[1]: Leaving directory `/home/jgoerzen/programs/gccbuild/objdir/gcc' make: *** [bootstrap] Error 2 I'm a little surprised to see RS6000 showing up there, since this is a 64-bit POWER platform. I'm using the GCC 4.0.2 directly from the gcc.gnu.org site. I'm bootstrapping with gcc 3.3.2, which I had also compiled myself. Using GNU binutils 2.14 20030612, also compiled myself. GCC 3.3.2 seems to be working fine otherwise. I'm happy to provide whatever additional information may be helpful. -- Summary: Unrecognized opcode bootstrapping gcc on AIX 5/POWER Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jgoerzen at complete dot org GCC build triplet: powerpc-ibm-aix5.1.0.0 GCC host triplet: powerpc-ibm-aix5.1.0.0 GCC target triplet: powerpc-ibm-aix5.1.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24859
[Bug c/24856] call to setlocale doesn't return expected value
--- Comment #2 from tedoc2000 at gmail dot com 2005-11-14 19:55 --- I have a very simple program that is trying to call setlocale(LC_ALL,) to set the LC_ALL from the enviroment. When I run with a gcc3.3.2 compiled binary: gcc33 ./locale en_US en_US en_US en_US en_US en_US en_US en_US en_US en_US en_US en_US But when I run with gcc 3.4.4 compiled binary I get: gcc34 ./locale null C C C C C C In both cases I have: echo $LANG en_US echo $LC_ALL The .i files look the same to me except for white space differences Here is the -v output from the gcc 3.3.2 version: /opt/OPSWgcc32/bin/gcc -v Reading specs from /opt/OPSWgcc32/lib/gcc-lib/powerpc-ibm-aix4.3.2.0/3.3.2/specs Configured with: ../configure --with-ar=/usr/bin/ar --with-as=/usr/bin/as --with-ld=/usr/bin/ld --disable-nls --enable-languages=c,c++ --prefix=/opt/OPSWgcc32 --enable-threads --enable-version-specific-runtime-libs --host=powerpc-ibm-aix4.3.2.0 Thread model: aix gcc version 3.3.2 And here is the 3.4.4 version: Reading specs from /opt/OPSWbuildtools/1.0.1/lib/gcc/powerpc-ibm-aix4.3.2.0/3.4.4/specs Configured with: ../gcc-3.4.4/configure --disable-shared --with-as=/bin/as --with-ld=/bin/ld --disable-nls --enable-threads=posix --with-libiconv-prefix=/opt/OPSWbuildtools/1.0.1 --prefix=/opt/OPSWbuildtools/1.0.1 --with-local-prefix=/opt/OPSWbuildtools/1.0.1 --enable-version-specific-runtime-libs --enable-languages=c,c++ Thread model: aix gcc version 3.4.4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24856
[Bug bootstrap/24859] Unrecognized opcode bootstrapping gcc on AIX 5/POWER
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-14 19:55 --- Using GNU binutils 2.14 20030612, also compiled myself. That is your bug. binutils is not complete for AIX 5 support at all. rs6000 is there because that is the name of the target directory which supports rs6000 and PowerPC 32/64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24859
[Bug c/24856] call to setlocale doesn't return expected value
--- Comment #3 from tedo at opsware dot com 2005-11-14 19:56 --- Subject: Re: call to setlocale doesn't return expected value Sorry.. Hit return too early. Filling out info now :/ tedo pinskia at gcc dot gnu dot org wrote: --- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-14 19:48 --- Why do you think this is a GCC bug? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24856
[Bug c/24856] call to setlocale doesn't return expected value
--- Comment #4 from tedoc2000 at gmail dot com 2005-11-14 19:57 --- Created an attachment (id=10239) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10239action=view) .i file for gcc332 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24856
[Bug c/24856] call to setlocale doesn't return expected value
--- Comment #5 from tedoc2000 at gmail dot com 2005-11-14 19:58 --- Created an attachment (id=10240) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10240action=view) .i file for gcc344 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24856
[Bug c/24856] call to setlocale doesn't return expected value
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-14 20:02 --- Again why do you think this is a GCC bug? The preprocessed sources are the same between 3.3.2 and 3.4.4. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24856
[Bug libgcj/24860] New: java.util.Calendar needs updating
Bugfixes have made it into the classpath version of java.util.Calendar, but are not in the version of Calendar used in libgcj. Bug 22957 is an example. See http://gcc.gnu.org/ml/java-patches/2005-q4/msg00181.html for a patch that was applied to the 4.0.x branch. Tom Tromey mentioned that he is working on changes to allow use of the Calendar class from the classpath import http://gcc.gnu.org/ml/java-patches/2005-q4/msg00186.html. -- Summary: java.util.Calendar needs updating Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: archit dot shah at alum dot mit dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24860
[Bug c/24861] New: internal compiler error when building gcc with --with-cpu=ep9312 --with-fpu=maverick
When compiling gcc with the --with-cpu=ep9312 and --with-fpu=maverick options
Gcc was configured with:
--prefix=/usr --bindir=/usr/armv4l-unknown-linux-gnu/gcc-bin/4.0.2
--includedir=/usr/lib/gcc/armv4l-unknown-linux-gnu/4.0.2/include
--datadir=/usr/share/gcc-data/armv4l-unknown-linux-gnu/4.0.2
--mandir=/usr/share/gcc-data/armv4l-unknown-linux-gnu/4.0.2/man
--infodir=/usr/share/gcc-data/armv4l-unknown-linux-gnu/4.0.2/info
--with-gxx-include-dir=/usr/lib/gcc/armv4l-unknown-linux-gnu/4.0.2/include/g++-v4
--host=x86_64-pc-linux-gnu --target=armv4l-unknown-linux-gnu --with-cpu=ep9312
--with-fpu=maverick --build=x86_64-pc-linux-gnu --disable-altivec --disable-nls
--with-system-zlib --disable-checking --disable-werror
--disable-libunwind-exceptions --disable-multilib --disable-libgcj
--enable-languages=c,c++ --with-sysroot=/usr/armv4l-unknown-linux-gnu
--enable-__cxa_atexit --enable-clocale=gnu
This is the error:
/tmp/build/gcc/xgcc -B/tmp/build/gcc/ -B/usr/armv4l-unknown-linux-gnu/bin/
-B/usr/armv4l-unknown-linux-gnu/lib/ -isystem
/usr/armv4l-unknown-linux-gnu/include -isystem
/usr/armv4l-unknown-linux-gnu/sys-include -O2 -DIN_GCC -DCROSS_COMPILE -W
-Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -isystem ./include -fomit-frame-pointer -fPIC
-mcpu=ep9312 -mfpu=maverick -g0 -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2
-D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../gcc-4.0.2/gcc -I../../gcc-4.0.2/gcc/.
-I../../gcc-4.0.2/gcc/../include -I../../gcc-4.0.2/gcc/../libcpp/include
-DL_fixunssfsi -fvisibility=hidden -DHIDE_EXPORTS -c
../../gcc-4.0.2/gcc/libgcc2.c -o libgcc/./_fixunssfsi.o
../../gcc-4.0.2/gcc/libgcc2.c: In function '__fixunssfsi':
../../gcc-4.0.2/gcc/libgcc2.c:1517: error: insn does not satisfy its
constraints:
(insn 75 7 6 0 (set (reg:SI 28 mv1)
(const_int 1325400064 [0x4f00])) 143 {*arm_movsi_insn} (nil)
(nil))
../../gcc-4.0.2/gcc/libgcc2.c:1517: internal compiler error: in
copyprop_hardreg_forward_1, at regrename.c:1570
Executing with -v:
/tmp/build/gcc/xgcc -B/tmp/build/gcc/ -B/usr/armv4l-unknown-linux-gnu/bin/
-B/usr/armv4l-unknown-linux-gnu/lib/ -isystem
/usr/armv4l-unknown-linux-gnu/include -isystem
/usr/armv4l-unknown-linux-gnu/sys-include -O2 -DIN_GCC -DCROSS_COMPILE -W
-Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -isystem ./include -fomit-frame-pointer -fPIC
-mcpu=ep9312 -mfpu=maverick -g0 -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2
-D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../gcc-4.0.2/gcc -I../../gcc-4.0.2/gcc/.
-I../../gcc-4.0.2/gcc/../include -I../../gcc-4.0.2/gcc/../libcpp/include
-DL_fixunssfsi -fvisibility=hidden -DHIDE_EXPORTS -c
../../gcc-4.0.2/gcc/libgcc2.c -o libgcc/./_fixunssfsi.o -v -save-temps -v
Reading specs from /tmp/build/gcc/specs
Target: armv4l-unknown-linux-gnu
Configured with: ../gcc-4.0.2/configure --prefix=/usr
--bindir=/usr/armv4l-unknown-linux-gnu/gcc-bin/4.0.2
--includedir=/usr/lib/gcc/armv4l-unknown-linux-gnu/4.0.2/include
--datadir=/usr/share/gcc-data/armv4l-unknown-linux-gnu/4.0.2
--mandir=/usr/share/gcc-data/armv4l-unknown-linux-gnu/4.0.2/man
--infodir=/usr/share/gcc-data/armv4l-unknown-linux-gnu/4.0.2/info
--with-gxx-include-dir=/usr/lib/gcc/armv4l-unknown-linux-gnu/4.0.2/include/g++-v4
--host=x86_64-pc-linux-gnu --target=armv4l-unknown-linux-gnu --with-cpu=ep9312
--with-fpu=maverick --build=x86_64-pc-linux-gnu --disable-altivec --disable-nls
--with-system-zlib --disable-checking --disable-werror
--disable-libunwind-exceptions --disable-multilib --disable-libgcj
--enable-languages=c,c++ --with-sysroot=/usr/armv4l-unknown-linux-gnu
--enable-__cxa_atexit --enable-clocale=gnu
Thread model: posix
gcc version 4.0.2
/tmp/build/gcc/cc1 -E -quiet -v -v -I. -I. -I../../gcc-4.0.2/gcc
-I../../gcc-4.0.2/gcc/. -I../../gcc-4.0.2/gcc/../include
-I../../gcc-4.0.2/gcc/../libcpp/include -iprefix
/tmp/build/gcc/../../../lib/gcc/armv4l-unknown-linux-gnu/4.0.2/ -isystem
/tmp/build/gcc/include -DIN_GCC -DCROSS_COMPILE -DHAVE_GTHR_DEFAULT
-DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -DL_fixunssfsi -DHIDE_EXPORTS -isystem
/usr/armv4l-unknown-linux-gnu/include -isystem
/usr/armv4l-unknown-linux-gnu/sys-include -isystem ./include
../../gcc-4.0.2/gcc/libgcc2.c -mcpu=ep9312 -mfpu=maverick -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-fomit-frame-pointer -fPIC -fvisibility=hidden -O2 -fpch-preprocess -o
libgcc2.i
ignoring duplicate directory /usr/armv4l-unknown-linux-gnu/sys-include
ignoring duplicate directory ./include
ignoring nonexistent directory
/tmp/build/gcc/../../../lib/gcc/armv4l-unknown-linux-gnu/4.0.2/include
ignoring nonexistent directory
/tmp/build/gcc/../../../lib/gcc/armv4l-unknown-linux-gnu/4.0.2/../../../../armv4l-unknown-linux-gnu/include
ignoring nonexistent directory
/usr/armv4l-unknown-linux-gnu/usr/local/include
ignoring duplicate directory
/usr/lib/gcc/armv4l-unknown-linux-gnu/4.0.2/../../../../armv4l-unknown-linux-gnu/include
ignoring duplicate
[Bug c++/24580] [3.4/4.0/4.1 Regression] virtual base class cause exception not to be caught
--- Comment #3 from jason at gcc dot gnu dot org 2005-11-14 20:07 --- Subject: Bug 24580 Author: jason Date: Mon Nov 14 20:07:45 2005 New Revision: 106901 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106901 Log: PR c++/24580 * method.c (locate_ctor): Skip all artificial parms, not just 'this'. Added: trunk/gcc/testsuite/g++.dg/eh/synth2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/method.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24580
[Bug target/24861] internal compiler error when building gcc with --with-cpu=ep9312 --with-fpu=maverick
--- Comment #1 from nekkar at libero dot it 2005-11-14 20:10 --- Created an attachment (id=10241) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10241action=view) preprocessed source, as required -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24861
[Bug c/24856] call to setlocale doesn't return expected value
--- Comment #7 from tedoc2000 at gmail dot com 2005-11-14 20:13 --- Actually I think it may have to do with libgcc. But I wasn't sure how to file a bug like that: Anyway I filed it against gcc because: a) Both files were compiled on the same server (So no patch level differences) b) The versions of all the other things I can think of are the same (ar, as, ln) c) Both versions of gcc create the same .i file. d) When I take the .o file and collect2 against the gcc3.3.2 versions of libgcc it works as I expect. Here is the collect2 I used: opt/OPSWbuildtools/1.0.1/libexec/gcc/powerpc-ibm-aix4.3.2.0/3.4.4/collect2 -bpT:0x1000 -bpD:0x2000 -btextro -bnodelcsect -bexport:/usr/lib/libg.exp -o locale /lib/crt0.o -L/opt/OPSWgcc32/lib/gcc-lib/powerpc-ibm-aix4.3.2.0/3.3.2 -L/opt/OPSWgcc32/lib/gcc-lib/powerpc-ibm-aix4.3.2.0/3.3.2/../../.. locale.o /opt/OPSWgcc32/lib/gcc-lib/powerpc-ibm-aix4.3.2.0/3.3.2/libgcc.a /opt/OPSWgcc32/lib/gcc-lib/powerpc-ibm-aix4.3.2.0/3.3.2/libgcc_eh.a -lg -lc /opt/OPSWgcc32/lib/gcc-lib/powerpc-ibm-aix4.3.2.0/3.3.2/libgcc.a /opt/OPSWgcc32/lib/gcc-lib/powerpc-ibm-aix4.3.2.0/3.3.2/libgcc_eh.a As opposed to the one I get with gcc3.4.4: /opt/OPSWbuildtools/1.0.1/libexec/gcc/powerpc-ibm-aix4.3.2.0/3.4.4/collect2 -bpT:0x1000 -bpD:0x2000 -btextro -bnodelcsect -bexport:/usr/lib/libg.exp -o locale /lib/crt0.o -L/opt/OPSWbuildtools/1.0.1/lib/gcc/powerpc-ibm-aix4.3.2.0/3.4.4 -L/opt/OPSWbuildtools/1.0.1/lib/gcc/powerpc-ibm-aix4.3.2.0/3.4.4/../../.. locale.o /opt/OPSWbuildtools/1.0.1/lib/gcc/powerpc-ibm-aix4.3.2.0/3.4.4/libgcc.a -lg -lc /opt/OPSWbuildtools/1.0.1/lib/gcc/powerpc-ibm-aix4.3.2.0/3.4.4/libgcc.a e) I'm not so smart? :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24856
[Bug target/24856] call to setlocale doesn't return expected value
--- Comment #8 from tedoc2000 at gmail dot com 2005-11-14 20:18 --- oops I meant ld not ln in b) above -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24856
[Bug c++/24580] [3.4/4.0/4.1 Regression] virtual base class cause exception not to be caught
--- Comment #4 from jason at gcc dot gnu dot org 2005-11-14 20:23 --- Subject: Bug 24580 Author: jason Date: Mon Nov 14 20:23:25 2005 New Revision: 106902 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106902 Log: PR c++/24580 * method.c (locate_ctor): Skip all artificial parms, not just 'this'. Added: branches/gcc-4_0-branch/gcc/testsuite/g++.dg/eh/synth2.C - copied unchanged from r106901, trunk/gcc/testsuite/g++.dg/eh/synth2.C Modified: branches/gcc-4_0-branch/gcc/cp/ChangeLog branches/gcc-4_0-branch/gcc/cp/method.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24580
[Bug bootstrap/24859] Unrecognized opcode bootstrapping gcc on AIX 5/POWER
--- Comment #2 from jgoerzen at complete dot org 2005-11-14 20:26 --- I am retrying this build with IBM ld and as. If memoery serves, I had to install GNU binutils because IBM binutils caused trouble with version 3.3.2. I will post a comment here when the build is complete (or fails, whichever comes first). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24859
[Bug target/24856] call to setlocale doesn't return expected value
--- Comment #9 from dje at gcc dot gnu dot org 2005-11-14 20:28 --- I do not have access to an AIX 4.3.2 system, but I compiled the reconstructed C testcase with: gcc-3.3.3 on AIX 5.1 gcc-3.4.4 on AIX 5.1 gcc-4.0.2 on AIX 5.1 gcc-4.1 experimental on AIX 5.2 All four compilers produced en_US en_US en_US en_US en_US en_US en_US en_US en_US en_US en_US en_US -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24856
[Bug c++/24580] [3.4/4.0/4.1 Regression] virtual base class cause exception not to be caught
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-14 20:33 --- Fixed in 4.0.3. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24580
[Bug tree-optimization/24709] [4.1 Regression] 4.1.0 HEAD crashes with enable-checking on huge switch statement
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-11-14 20:34 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24709
[Bug ada/24857] ada/s-auxdec.ads alignment issue for arm-rtems
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2005-11-14 20:37 --- Joel confirmed that changing Min (2 to Min (4 enable this file to be compiled, however my reading of the source would imply that BIGGEST_ALIGNMENT is at least 32 on arm, so something else must be at play here, any idea? Excerpt from config/arm/arm.h: /* Setting STRUCTURE_SIZE_BOUNDARY to 32 produces more efficient code, but the value set in previous versions of this toolchain was 8, which produces more compact structures. The command line option -mstructure_size_boundary=n can be used to change this value. For compatibility with the ARM SDK however the value should be left at 32. ARM SDT Reference Manual (ARM DUI 0020D) page 2-20 says Structures are aligned on word boundaries. The AAPCS specifies a value of 8. */ #define STRUCTURE_SIZE_BOUNDARY arm_structure_size_boundary extern int arm_structure_size_boundary; /* This is the value used to initialize arm_structure_size_boundary. If a particular arm target wants to change the default value it should change the definition of this macro, not STRUCTURE_SIZE_BOUNDARY. See netbsd.h for an example of this. */ #ifndef DEFAULT_STRUCTURE_SIZE_BOUNDARY #define DEFAULT_STRUCTURE_SIZE_BOUNDARY 32 #endif -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24857
[Bug ada/24857] ada/s-auxdec.ads alignment issue for arm-rtems
-- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-14 20:37:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24857
[Bug target/24856] call to setlocale doesn't return expected value
--- Comment #10 from tedoc2000 at gmail dot com 2005-11-14 20:39 --- Hmm.. I'm getting the same exact behaviour on my AIX 5.1 box :/ So maybe it has something to do with the way I configured gcc 3.4.4 (which is a little different than how I did 3.3.2) Let me try re-building 3.4.4 with the same ./configure command line as I did the gcc 3.3.2 Will see if that does anything. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24856
[Bug debug/24824] [4.1 Regression] ICE: in build_abbrev_table, at dwarf2out.c:6427 with -feliminate-dwarf2-dups
--- Comment #5 from janis at gcc dot gnu dot org 2005-11-14 20:43 --- A regression hunt on powerpc-linux using the testcase from comment #4 identified the following patch: http://gcc.gnu.org/viewcvs?view=revrev=100757 r100757 | nathan | 2005-06-08 11:49:23 + (Wed, 08 Jun 2005) -- janis at gcc dot gnu dot org changed: What|Removed |Added CC||nathan at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24824
[Bug target/24861] internal compiler error when building gcc with --with-cpu=ep9312 --with-fpu=maverick
--- Comment #2 from nekkar at libero dot it 2005-11-14 20:43 --- There is the very same problem with gcc 4.0.0 -- nekkar at libero dot it changed: What|Removed |Added CC||nekkar at libero dot it http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24861
[Bug c++/24580] [3.4/4.0/4.1 Regression] virtual base class cause exception not to be caught
--- Comment #6 from jason at gcc dot gnu dot org 2005-11-14 20:48 --- Subject: Bug 24580 Author: jason Date: Mon Nov 14 20:48:50 2005 New Revision: 106903 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106903 Log: PR c++/24580 * method.c (locate_ctor): Skip all artificial parms, not just 'this'. Added: branches/gcc-3_4-branch/gcc/testsuite/g++.dg/eh/synth2.C - copied unchanged from r106901, trunk/gcc/testsuite/g++.dg/eh/synth2.C Modified: branches/gcc-3_4-branch/gcc/cp/ChangeLog branches/gcc-3_4-branch/gcc/cp/method.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24580
[Bug c++/24580] [3.4/4.0/4.1 Regression] virtual base class cause exception not to be caught
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-11-14 20:52 --- Fixed also for 3.4.5. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.0.3 |3.4.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24580
[Bug debug/24490] [4.1 Regression] gcc / gdb backtrace problem
--- Comment #9 from wilson at gcc dot gnu dot org 2005-11-14 21:09 --- Not a gcc bug. This is a gdb bug, and I already have an approved patch for gdb that will be checked in shortly. -- wilson at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24490
[Bug fortran/24862] New: Internal Error: Derived type I/O should have been handled via the frontend.
The code below gives the error in the summary line for both writes of X%i. I'm using the latest svn version (106896). gfortran-CVS gfortran3.F95 ./a.out At line 26 of file gfortran3.F95 Internal Error: Derived type I/O should have been handled via the frontend. --- module gfortran3 type tp integer :: i end type contains subroutine inittp(X) type(tp), intent(inout) :: X(:) X%i = 256 end subroutine inittp subroutine test(x) type(tp), intent(in) :: x(:) write(*,*) x%i write(*,*) x end subroutine test end module program prog use gfortran3 implicit none type(tp) :: Y(5) call inittp(Y) write(*,*) Y%i call test(Y) end program prog -- gfortran-CVS -v gfortran3.F95 ./a.out Driving: gfortran-CVS -v gfortran3.F95 -lgfortranbegin -lgfortran -lm -shared-libgcc Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../configure --prefix=/home/zeekec/local --program-suffix=-CVS --disable-nls : (reconfigured) ../configure --prefix=/home/zeekec/local --program-suffix=-CVS --disable-nls --enable-languages=c,c++,fortran,java,objc --no-create --no-recursion Thread model: posix gcc version 4.1.0 20051114 (experimental) /home/zeekec/local/libexec/gcc/i686-pc-linux-gnu/4.1.0/cc1 -E -lang-fortran -traditional-cpp -D_LANGUAGE_FORTRAN -quiet -v gfortran3.F95 -mtune=pentiumpro -o /tmp/ccdkugj8.f95 ignoring nonexistent directory /home/zeekec/local/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../i686-pc-linux-gnu/include #include ... search starts here: #include ... search starts here: /usr/local/include /home/zeekec/local/include /home/zeekec/local/lib/gcc/i686-pc-linux-gnu/4.1.0/include /usr/include End of search list. /home/zeekec/local/libexec/gcc/i686-pc-linux-gnu/4.1.0/f951 /tmp/ccdkugj8.f95 -quiet -dumpbase gfortran3.F95 -mtune=pentiumpro -auxbase gfortran3 -version -o /tmp/ccg6IRy3.s GNU F95 version 4.1.0 20051114 (experimental) (i686-pc-linux-gnu) compiled by GNU C version 4.1.0 20051108 (experimental). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 as -V -Qy -o /tmp/ccGjbqT8.o /tmp/ccg6IRy3.s GNU assembler version 2.15.92.0.2 (i386-redhat-linux) using BFD version 2.15.92.0.2 20040927 /home/zeekec/local/libexec/gcc/i686-pc-linux-gnu/4.1.0/collect2 --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o /usr/lib/crti.o /home/zeekec/local/lib/gcc/i686-pc-linux-gnu/4.1.0/crtbegin.o -L/home/zeekec/local/lib/gcc/i686-pc-linux-gnu/4.1.0 -L/home/zeekec/local/lib/gcc/i686-pc-linux-gnu/4.1.0/../../.. /tmp/ccGjbqT8.o -lgfortranbegin -lgfortran -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /home/zeekec/local/lib/gcc/i686-pc-linux-gnu/4.1.0/crtend.o /usr/lib/crtn.o At line 26 of file gfortran3.F95 Internal Error: Derived type I/O should have been handled via the frontend. -- Summary: Internal Error: Derived type I/O should have been handled via the frontend. Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zeekec at mad dot scientist dot com 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=24862
[Bug fortran/24862] [4.1 Regression] Internal Error: Derived type I/O should have been handled via the frontend.
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-14 21:15 --- This worked in gcc 4.0.3 20051105 -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Keywords||wrong-code Known to fail||4.1.0 Known to work||4.0.2 Summary|Internal Error: Derived type|[4.1 Regression] Internal |I/O should have been handled|Error: Derived type I/O |via the frontend. |should have been handled via ||the frontend. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24862
[Bug fortran/24862] [4.1 Regression] Internal Error: Derived type I/O should have been handled via the frontend.
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-14 21:28 --- But fails with the mainline from at least 20051026. This was caused by the array transfer patch (I don't know who patched it). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to work|4.0.2 |4.0.2 4.0.3 Priority|P3 |P5 Last reconfirmed|-00-00 00:00:00 |2005-11-14 21:28:37 date|| Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24862
[Bug ada/18434] [4.0/4.1 Regression] Ada: cannot build gnattools on Tru64 UNIX V5.1B
--- Comment #19 from guerby at gcc dot gnu dot org 2005-11-14 21:34 --- Subject: Bug 18434 Author: guerby Date: Mon Nov 14 21:34:34 2005 New Revision: 106906 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106906 Log: 2005-11-14 Robert Dewar [EMAIL PROTECTED] PR ada/18434 * osint-m.adb: Add pragma Elaborate_All for Osint Modified: branches/gcc-4_0-branch/gcc/ada/ChangeLog branches/gcc-4_0-branch/gcc/ada/osint-m.adb -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18434
