[Bug middle-end/28776] [4.2 Regression] dwarf2out.c:2160: ICE: in build_polynomial_chrec, at tree-chrec.h:108
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-08-19 06:02 --- Reducing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28776
[Bug middle-end/28776] [4.2 Regression] dwarf2out.c:2160: ICE: in build_polynomial_chrec, at tree-chrec.h:108
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-08-19 05:59 --- I can reproduce the ICE on i686-linux-gnu with a native compiler with the preprocessed source. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|powerpc-apple-darwin8.7.0 | GCC host triplet|powerpc-apple-darwin8.7.0 | GCC target triplet|powerpc-apple-darwin8.7.0 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28776
[Bug fortran/24866] internal compiler error
--- Comment #6 from pault at gcc dot gnu dot org 2006-08-19 05:49 --- > I know you're on vacation, Paul, but I think what looks troubling to us would > look trivial to you, friendly as you are with the module code in gfortran! > I'll have a look today - I am in the midst of a triage of the fortran PRs and this comes out as one of the "straight to the operating theatre" category. Offhand, I think that it is a primary.c/decl.c problem rather than a module.c but I'll let you know. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24866
[Bug libfortran/28747] Empty write STREAM I/O file positioning problem
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2006-08-19 03:29 --- Here is a comparison of no optimization and with -O1. Does this code look the same on x86-64 that is not FreeBSD? Code with no optimization: This does not work. call_gfortran_st_write_done movq$.LC0, -424(%rbp) movl$8, -416(%rbp) movl$10, -428(%rbp) movq$1, -392(%rbp) movl$512, -432(%rbp) leaq-432(%rbp), %rdi call_gfortran_st_write Code with -O1: This works call_gfortran_st_write_done movq$.LC0, 8(%rsp) movl$8, 16(%rsp) movl$10, 4(%rsp) movq$1, 40(%rsp) movl$512, (%rsp) movq%rsp, %rdi call_gfortran_st_write -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28747
[Bug target/27565] [4.1/4.2 Regression] ICE in assign_stack_temp_for_type for vectors with SPE
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-08-19 03:03 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27565
[Bug middle-end/28071] [4.1/4.2 regression] A file that can not be compiled in reasonable time/space
--- Comment #39 from hubicka at ucw dot cz 2006-08-19 01:51 --- Subject: Re: [4.1/4.2 regression] A file that can not be compiled in reasonable time/space The -O1 time sinks: life analysis : 25.44 (19%) usr 0.00 ( 0%) sys 25.49 (17%) wall 2565 kB ( 2%) ggc inline heuristics : 14.92 (11%) usr 0.00 ( 0%) sys 14.95 (10%) wall 1486 kB ( 1%) ggc integration : 20.73 (15%) usr 0.10 ( 4%) sys 22.72 (15%) wall 33445 kB (20%) ggc tree SSA to normal: 27.97 (20%) usr 0.04 ( 2%) sys 28.13 (19%) wall 17 kB ( 0%) ggc expand: 2.56 ( 2%) usr 0.04 ( 2%) sys 2.67 ( 2%) wall 24100 kB (14%) ggc local alloc : 7.21 ( 5%) usr 0.03 ( 1%) sys 7.18 ( 5%) wall 1855 kB ( 1%) ggc global alloc : 11.76 ( 9%) usr 0.99 (39%) sys 17.71 (12%) wall 11029 kB ( 6%) ggc reload CSE regs : 7.91 ( 6%) usr 0.02 ( 1%) sys 7.97 ( 5%) wall 2393 kB ( 1%) ggc TOTAL : 136.62 2.56 148.01 170448 kB tree SSA to normal spends most of time in find_value_in_list because TER is shuffling around single linked lists in the quadratic way. I got quickly lost in the logic there. Andrew, can you take a look, please? integration runs into qudratic behaviour of cgraph_edge. Implementing hashtable for large cgraphs is easy, I will do so. Also tree_split_block quadratic behaviour hits us here. reload CSE regs has hard time to track all the stack slot memory locations. It is working harder than needed because a lot of memories are believed to be aliasing even if theoretically almost everything SRA and has no address taken so it should have unique alias sets. Life analysis spends most of time in dead store removal code. Again lowering --param might help. I am also testing little patch to cut it to 13 seconds by speeding up reg_overlap_mentioned_p. It would be insteresting to see how dataflow branch score here. inline heuristics spends most time checking inline_function_growth limit, I will need to think about it a bit. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28071
[Bug middle-end/28071] [4.1/4.2 regression] A file that can not be compiled in reasonable time/space
--- Comment #38 from hubicka at ucw dot cz 2006-08-19 00:19 ---
Subject: Re: [4.1/4.2 regression] A file that can not be compiled in
reasonable time/space
At -O0 we get time sinks:
life analysis : 0.75 (10%) usr 0.01 ( 3%) sys 0.78 ( 9%) wall
2714 kB ( 4%) ggc
expand: 1.46 (15%) usr 0.04 (11%) sys 1.66 (15%) wall
37656 kB (58%) ggc
local alloc : 1.40 (14%) usr 0.04 (11%) sys 1.45 (13%) wall
1293 kB ( 2%) ggc
global alloc : 3.55 (36%) usr 0.05 (14%) sys 3.67 (34%) wall
7509 kB (12%) ggc
final : 0.96 (10%) usr 0.04 (11%) sys 1.00 ( 9%) wall
1157 kB ( 2%) ggc
TOTAL : 9.95 0.3510.77
64543 kB
Expand seems resonable given that almost everything is call that has
long representation.
Global alloc is copying important portion of insn stream because of:
/* If we aren't replacing things permanently and we changed something,
make another copy to ensure that all the RTL is new. Otherwise
things can go wrong if find_reload swaps commutative operands
and one is inside RTL that has been copied while the other is not. */
new_body = old_body;
if (! replace)
{
new_body = copy_insn (old_body);
if (REG_NOTES (insn))
REG_NOTES (insn) = copy_insn_1 (REG_NOTES (insn));
}
and few other occurences of copy_insn in reload1.c. They seems to copy
quite a lot of unnecesary RTL "just for sure". Also virtual register
ellimination produce a lot of duplicated RTL, perhaps it can be cached?
global alloc also spend 50% of time by clearing out
reg_has_output_reload. I am testing patch that fix that.
global alloc : 1.51 (19%) usr 0.07 (20%) sys 1.60 (18%) wall
7509 kB (12%) ggc
Final is spending all it's time in shorten branches, that are not needed
at all.
Honza
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28071
[Bug middle-end/28753] [4.2 regression] ICE in extract_insn, at recog.c:2075 on powerpc
--- Comment #9 from janis at gcc dot gnu dot org 2006-08-18 23:31 --- A regression hunt using "-O2 -w -fmove-loop-invariants" on powerpc-linux identfied the following patch: http://gcc.gnu.org/viewcvs?view=rev&rev=99547 r99547 | rakdver | 2005-05-10 22:33:30 + (Tue, 10 May 2005) -- janis at gcc dot gnu dot org changed: What|Removed |Added CC||rakdver at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28753
[Bug middle-end/28071] [4.1/4.2 regression] A file that can not be compiled in reasonable time/space
--- Comment #37 from hubicka at ucw dot cz 2006-08-18 23:10 --- Subject: Re: [4.1/4.2 regression] A file that can not be compiled in reasonable time/space Hi, to summary current process, the memory consumption seems to be in control now: comparing PR rtl-optimization/28071 testcase compilation at -O0 level: Ovarall memory allocated via mmap and sbrk decreased from 146456k to 134136k, overall -9.18% Peak amount of GGC memory allocated before garbage collecting run decreased from 95412k to 81628k, overall -16.89% Amount of produced GGC garbage decreased from 163295k to 143524k, overall -13.77% Overall memory needed: 146456k -> 134136k Peak memory use before GGC: 95412k -> 81628k Peak memory use after GGC: 58507k Maximum of released memory in single GGC run: 45493k Garbage: 163295k -> 143524k Leak: 7142k Overhead: 29023k -> 25103k GGC runs: 87 comparing PR rtl-optimization/28071 testcase compilation at -O1 level: Overall memory needed: 430308k -> 424700k Peak memory use before GGC: 201177k Peak memory use after GGC: 196173k Maximum of released memory in single GGC run: 100203k -> 95156k Garbage: 279198k -> 271636k Leak: 47195k Overhead: 31459k -> 29952k GGC runs: 105 comparing PR rtl-optimization/28071 testcase compilation at -O2 level: Overall memory needed: 350424k -> 344820k Peak memory use before GGC: 208293k Peak memory use after GGC: 196536k Maximum of released memory in single GGC run: 101565k -> 96536k Garbage: 394891k -> 387353k Leak: 47778k Overhead: 49054k -> 47552k GGC runs: 111 comparing PR rtl-optimization/28071 testcase compilation at -O3 -fno-tree-pre -fno-tree-fre level: Overall memory needed: 535696k -> 536260k Peak memory use before GGC: 314602k Peak memory use after GGC: 292946k Maximum of released memory in single GGC run: 163430k Garbage: 494953k -> 486928k Leak: 65110k Overhead: 60330k -> 58798k GGC runs: 100 I will post short summary of remaining bottleneks on each optimization level. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28071
[Bug middle-end/28753] [4.2 regression] ICE in extract_insn, at recog.c:2075 on powerpc
--- Comment #8 from janis at gcc dot gnu dot org 2006-08-18 22:20 --- A regression hunt on powerpc-linux using the testcase from comment #4 identified the following patch: http://gcc.gnu.org/viewcvs?view=rev&rev=110852 r110852 | rakdver | 2006-02-10 21:01:10 + (Fri, 10 Feb 2006) That patch enables -fmove-loop-invariants by default, and earlier versions of mainline fail with same way when that option is used, with the failure starting sometime between 2005-04-15 and 2005-05-13. I'll do another search in that range. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28753
[Bug middle-end/28776] [4.2 Regression] dwarf2out.c:2160: ICE: in build_polynomial_chrec, at tree-chrec.h:108
--- Comment #3 from lucier at math dot purdue dot edu 2006-08-18 21:34 --- Created an attachment (id=12094) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12094&action=view) preprocessed source for dwarf2out.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28776
[Bug c++/23211] [4.0/4.1/4.2 regression] using dec in nested class doesn't import name
--- Comment #10 from janis at gcc dot gnu dot org 2006-08-18 21:30 --- A regression hunt on powerpc-linux using the submitter's testcase identified the following patch: http://gcc.gnu.org/viewcvs?view=rev&rev=69921 r69921 | nathan | 2003-07-29 11:16:50 + (Tue, 29 Jul 2003) -- 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=23211
[Bug middle-end/28776] [4.2 Regression] dwarf2out.c:2160: ICE: in build_polynomial_chrec, at tree-chrec.h:108
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-18 21:27 --- http://gcc.gnu.org/ml/gcc-regression/2006-08/msg6.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28776
[Bug middle-end/28776] [4.2 Regression] dwarf2out.c:2160: ICE: in build_polynomial_chrec, at tree-chrec.h:108
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-18 21:26 --- Can you attach the preprocessed source? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|bootstrap |middle-end Keywords||build, ice-on-valid-code Summary|dwarf2out.c:2160: ICE: in |[4.2 Regression] |build_polynomial_chrec, at |dwarf2out.c:2160: ICE: in |tree-chrec.h:108|build_polynomial_chrec, at ||tree-chrec.h:108 Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28776
[Bug tree-optimization/28778] [4.0/4.1/4.2 Regression] alias bug with cast and call clobbered
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-08-18 21:17 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|normal |blocker Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||alias Known to fail||4.0.0 4.1.0 4.2.0 Known to work||3.4.0 Last reconfirmed|-00-00 00:00:00 |2006-08-18 21:17:52 date|| Summary|strict-aliasing bug |[4.0/4.1/4.2 Regression] ||alias bug with cast and call ||clobbered Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28778
[Bug tree-optimization/28778] strict-aliasing bug
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-18 21:15 ---
Here is a full testcase:
typedef long GLint;
void aglChoosePixelFormat(const GLint *);
void find(const int *alistp) {
const int *blist;
int list[32];
if (alistp)
blist = alistp;
else {
list[3] = 42;
blist = list;
}
aglChoosePixelFormat((GLint*)blist);
}
void aglChoosePixelFormat(const GLint *a)
{
int *b = (int*)a;
if (b[3] != 42)
__builtin_abort ();
}
int main(void)
{
find(0);
return 0;
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||wrong-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28778
[Bug tree-optimization/28778] strict-aliasing bug
--- Comment #2 from mrs at apple dot com 2006-08-18 21:12 --- radr://4658741 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28778
[Bug tree-optimization/28778] strict-aliasing bug
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-18 21:11 --- As long as aglChoosePixelFormat only access the argument as int and not long, this should be ok. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28778
[Bug tree-optimization/28777] Zerodetection (i != 0) compiled with -O2 don't work
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-18 21:08 --- This is most likely a dup of another bug which was fixed in 4.2.0. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Component|c++ |tree-optimization Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28777
[Bug tree-optimization/28778] New: strict-aliasing bug
mrs $ cat /tmp/t2.cc
typedef long GLint;
void aglChoosePixelFormat(const GLint *);
void find(const int *alistp) {
const int *blist;
int list[32];
if (alistp)
blist = alistp;
else {
list[3] = 42; /* this store disappears with -fstrict-aliasing */
blist = list;
}
aglChoosePixelFormat((GLint*)blist);
}
mrs $ ./xgcc -B./ -S -O1 /tmp/t2.cc -fno-strict-aliasing && grep 42 t2.s
li r0,42
mrs $ ./xgcc -B./ -S -O1 /tmp/t2.cc -fstrict-aliasing && grep 42 t2.s
mrs $
The store cannot be removed, as the converted pointer can be used inside the
aglChoosePixelFormat function to access the value. Since the optimizer can't
see that it isn't used, the optimizer must assume it can as the function isn't
marked pure. If it had been, then the optimization would be ok.
t2.cc.035t.dce1 is the first pass that doesn't have the store, t2.cc.034t.fre
has the store.
This worked in 3.3, but not 4.0.1. This doesn't work in gcc version 4.2.0
20060815 (experimental) on powerpc-apple-darwin9.0.0d1, nor on
i686-apple-darwin8.
--
Summary: strict-aliasing bug
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrs at apple dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28778
[Bug libfortran/28747] Empty write STREAM I/O file positioning problem
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2006-08-18 20:54
---
Here is a debug trace showing the steps leading up to the mutation of the dtp
pointer. StevebB on IRC indicated that the assembly output on linux x86-64
natch the freebsd version I posted here and the problem does not occur on that
platform. Notice the before an after values of the dtp pointer!
(gdb) s
*_gfortran_st_write_done (dtp=0x7fffe640)
at ../../../gcc4x/libgfortran/io/transfer.c:2546
2546 if (dtp->u.p.scratch != NULL)
(gdb) s
2548 if (dtp->u.p.current_unit != NULL)
(gdb) s
2549unlock_unit (dtp->u.p.current_unit);
(gdb) s
*_gfortrani_unlock_unit (u=0x2008103b0) at gthr-posix.h:566
566 if (__gthread_active_p ())
(gdb) p dtp
No symbol "dtp" in current context.
(gdb) p u
$5 = (gfc_unit *) 0x2008103b0
(gdb) p *u
$6 = {unit_number = 10, s = 0x200828000, left = 0x0, right = 0x0,
priority = 14047, read_bad = 1, current_record = 1, endfile = NO_ENDFILE,
mode = WRITING, flags = {access = ACCESS_STREAM, action = ACTION_READWRITE,
blank = BLANK_NULL, delim = DELIM_NONE, form = FORM_UNFORMATTED,
is_notpadded = 0, position = POSITION_ASIS, status = STATUS_UNKNOWN,
pad = PAD_YES, convert = CONVERT_NATIVE}, recl = 1, last_record = 25,
maxrec = 9223372036854775807, bytes_left = 0, lock = 0x0, waiting = 0,
closed = 0, ls = 0x0, rank = 0, file_len = 10,
file = 0x20082c140 "teststream"}
(gdb) s
567 return __gthrw_(pthread_mutex_unlock) (mutex);
(gdb) s
Breakpoint 1, *_gfortran_st_write (dtp=0x7fffe7d0)
at ../../../gcc4x/libgfortran/io/transfer.c:2506
2506{
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28747
[Bug c++/28777] New: Zerodetection (i != 0) compiled with -O2 don't work
Compiling the following code with -O2 produces an buggy excecutable:
(Using no optimization or -O1 produces an valid excecutable)
~~~ snip ~~
#include
int main( void )
{
for ( int i = 1; i != 0; i = i + 1 )
{
if ( ! (i % 1) )
{
std::cout << i << std::endl;
if ( i == 0 )
{
std::cout << i << std::endl;
}
}
}
return 0;
}
~~~ snip ~~
Commands to build and execute:
~/c++work/multtest> g++ -O2 -o multtest main.cpp
~/c++work/multtest> ./multtest
1
2
:
-2
-1
0
1
2
: // and continues
== Environment ===
~/c++work/multtest> gcc --version
gcc (GCC) 4.1.1 (Gentoo 4.1.1)
Copyright (C) 2006 Free Software Foundation, Inc.
Dies ist freie Software; die Kopierbedingungen stehen in den Quellen. Es
gibt KEINE Garantie; auch nicht für MARKTGÄNGIGKEIT oder FÜR SPEZIELLE ZWECKE.
~/c++work/multtest> uname --all
Linux atlantis 2.6.17-gentoo-r5 #5 SMP PREEMPT Mon Aug 14 19:48:18 CEST 2006
i686 AMD Athlon(tm) XP 2500+ AuthenticAMD GNU/Linux
~/c++work/multtest> cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 10
model name : AMD Athlon(tm) XP 2500+
stepping: 0
cpu MHz : 1837.783
cache size : 512 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow up ts
bogomips: 3679.34
--
Summary: Zerodetection (i != 0) compiled with -O2 don't work
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hgsawicki at web dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28777
[Bug bootstrap/28776] New: dwarf2out.c:2160: ICE: in build_polynomial_chrec, at tree-chrec.h:108
configure and build:
/bin/rm -rf *; ../configure --prefix=/pkgs/gcc-mainline --with-gmp=/opt/local/
--with-mpfr=/opt/local/ ; make -j 4 bootstrap >& build.log && (make -k -j 8
check RUNTESTFLAGS="--target_board 'unix{-mcpu=970/-m64}'" >& check.log ; make
mail-report-with-warnings.log)
with updated Xcode:
[descartes:gcc/mainline/objdir64] lucier% gcc -v
Using built-in specs.
Target: powerpc-apple-darwin8
Configured with: /private/var/tmp/gcc/gcc-5363.obj~28/src/configure
--disable-checking -enable-werror --prefix=/usr --mandir=/share/man
--enable-languages=c,objc,c++,obj-c++
--program-transform-name=/^[cg][^.-]*$/s/$/-4.0/
--with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib
--build=powerpc-apple-darwin8 --host=powerpc-apple-darwin8
--target=powerpc-apple-darwin8
Thread model: posix
gcc version 4.0.1 (Apple Computer, Inc. build 5363)
fails with the stage2 build with
/Users/lucier/programs/gcc/mainline/objdir64/./prev-gcc/xgcc
-B/Users/lucier/programs/gcc/mainline/objdir64/./prev-gcc/
-B/pkgs/gcc-mainline/powerpc-apple-darwin8.7.0/bin/ -c -g -O2
-mdynamic-no-pic -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute
-Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc -I../../gcc/.
-I../../gcc/../include -I./../intl -I../../gcc/../libcpp/include
-I/opt/local//include -I/opt/local//include -I../../gcc/../libdecnumber
-I../libdecnumber../../gcc/dwarf2out.c -o dwarf2out.o
../../gcc/dwarf2out.c: In function 'output_call_frame_info':
../../gcc/dwarf2out.c:2160: internal compiler error: in build_polynomial_chrec,
at tree-chrec.h:108
--
Summary: dwarf2out.c:2160: ICE: in build_polynomial_chrec, at
tree-chrec.h:108
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lucier at math dot purdue dot edu
GCC build triplet: powerpc-apple-darwin8.7.0
GCC host triplet: powerpc-apple-darwin8.7.0
GCC target triplet: powerpc-apple-darwin8.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28776
[Bug target/27565] [4.1/4.2 Regression] ICE in assign_stack_temp_for_type for vectors with SPE
--- Comment #6 from jsm28 at gcc dot gnu dot org 2006-08-18 19:16 --- Subject: Bug 27565 Author: jsm28 Date: Fri Aug 18 19:16:19 2006 New Revision: 116250 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116250 Log: PR target/27565 * config/rs6000/rs6000.h (LOCAL_ALIGNMENT): For SPE, only adjust alignment of SPE vector types. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config/rs6000/rs6000.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27565
[Bug middle-end/28753] [4.2 regression] ICE in extract_insn, at recog.c:2075 on powerpc
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-08-18 19:16 --- (In reply to comment #6) > The testcase in comment #4 is incomplete; I get all of these errors even with > the current 4.1-branch on powerpc-linux: Janis, this is C code and not C++ code :). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28753
[Bug target/27565] [4.1/4.2 Regression] ICE in assign_stack_temp_for_type for vectors with SPE
--- Comment #5 from jsm28 at gcc dot gnu dot org 2006-08-18 19:15 --- Subject: Bug 27565 Author: jsm28 Date: Fri Aug 18 19:15:31 2006 New Revision: 116249 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116249 Log: PR target/27565 * config/rs6000/rs6000.h (LOCAL_ALIGNMENT): For SPE, only adjust alignment of SPE vector types. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27565
[Bug fortran/28722] Fortran front-end produces mismatch trees
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-18 19:13 --- This happens when the first patch in PR 22368 is added. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet||i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28722
[Bug java/28775] gcj-dbtool fails to work on x86_64: NoSuchAlgorithmException: MD5
--- Comment #1 from bero at arklinux dot org 2006-08-18 19:10 --- The problem is that classpath.security gets installed to /usr/lib/security only, but not /usr/lib64/security. Running cp /usr/lib/security/classpath.secruity /usr/lib64/security after installing gcc fixes it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28775
[Bug java/28775] New: gcj-dbtool fails to work on x86_64: NoSuchAlgorithmException: MD5
When trying to use gcj-dbtool (SVN rev. 116230) on x86_64, this happens: gcj-dbtool -f ecj.db ecj.jar /usr/lib64/libecj.so.3 error: could not update ecj.db: java.security.NoSuchAlgorithmException: MD5 Works as expected with the same gcc/gcj on normal x86. -- Summary: gcj-dbtool fails to work on x86_64: NoSuchAlgorithmException: MD5 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bero at arklinux dot org GCC build triplet: x86_64-pc-linux-gnu GCC host triplet: x86_64-pc-linux-gnu GCC target triplet: x86_64-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28775
[Bug fortran/28771] gfortran accepts invalid variable definition
--- Comment #2 from pault at gcc dot gnu dot org 2006-08-18 18:29 --- As the submitter of the patch, I suppose that I had better take on the PR! Thanks for the report, Martin Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-08-18 18:29:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28771
[Bug fortran/28722] Fortran front-end produces mismatch trees
--- Comment #1 from pault at gcc dot gnu dot org 2006-08-18 18:28 --- Andrew, How, when and where does this happen, please? Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28722
[Bug fortran/28771] gfortran accepts invalid variable definition
--- Comment #1 from patchapp at dberlin dot org 2006-08-18 18:20 --- Subject: Bug number PR28771 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00668.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28771
[Bug middle-end/28753] [4.2 regression] ICE in extract_insn, at recog.c:2075 on powerpc
--- Comment #6 from janis at gcc dot gnu dot org 2006-08-18 18:04 --- The testcase in comment #4 is incomplete; I get all of these errors even with the current 4.1-branch on powerpc-linux: elm3b11% /opt/gcc-nightly/4.1/bin/g++ -c 28753.cc 28753.cc:21: error: ISO C++ forbids declaration of __pyx_f_11 with no type 28753.cc: In function int __pyx_f_11(PyObject*, PyObject*): 28753.cc:34: error: return-statement with no value, in function returning int 28753.cc:37: error: PyObject_GetIter was not declared in this scope 28753.cc:40: error: PyIter_Next was not declared in this scope 28753.cc:51: error: PyObject_CallObject was not declared in this scope 28753.cc:57: error: PyTuple_New was not declared in this scope 28753.cc:75: error: PyErr_ExceptionMatches was not declared in this scope -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28753
[Bug c++/28774] New: Request for warning where const/volatile is ignored in a cast
In the code fragment int i = static_cast(1.234); int j = static_cast(1.234); the const and volatile qualifiers in the cast are silently ignored, even with -Wall -W -pedantic. A warning from g++ for this mild infraction would be useful. -- Summary: Request for warning where const/volatile is ignored in a cast Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: simon_baldwin at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28774
[Bug c++/28659] [4.2 regression] ICE (segfault) while compiling kdelibs 4.0 snapshot
--- Comment #7 from mueller at gcc dot gnu dot org 2006-08-18 17:55 --- struct oD.1993: type_0 type_5 type_6 BLK size constant invariant 0> unit size constant invariant 0> align 8 symtab 0 alias set -1 attributes local bindings <(nil)>> value readonly constant invariant static "default\000">>> no-binfo use_template=1 interface-unknown> the original type is: oD.1985:: type_0 type_5 type_6 BLK size unit size align 8 symtab 0 alias set -1 attributes local bindings <(nil)>> value readonly constant invariant static "default\000">>> no-binfo use_template=1 interface-unknown> QI size constant invariant 8> unit size constant invariant 1> align 8 symtab 0 alias set -1 method basetype > arg-types > unsigned SI size unit size align 32 symtab 0 alias set -1> chain >>> -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28659
[Bug preprocessor/23688] Compiler does not warn on selected unknown character escapes
--- Comment #3 from simon_baldwin at yahoo dot com 2006-08-18 17:51 --- Unfortunately, adding -pedantic brings in a grab-bag of other warnings that aren't currently separable. What would be useful, I think, is to have unknown escape sequences as its own -Wmumble option. That way, it's selectively available without all of the rest of -pedantic. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23688
[Bug libfortran/28747] Empty write STREAM I/O file positioning problem
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2006-08-18 16:29 --- Using -fdump-tree-final_cleanup all looks OK. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28747
[Bug c++/28385] [4.0/4.1 regression] templated function call goes awry
--- Comment #8 from jason at gcc dot gnu dot org 2006-08-18 16:28 --- Subject: Bug 28385 Author: jason Date: Fri Aug 18 16:28:15 2006 New Revision: 116244 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116244 Log: PR c++/28385 * pt.c (tsubst) [TEMPLATE_TYPE_PARM]: Ignore quals from template if arg is a function. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/const1.C - copied unchanged from r116203, trunk/gcc/testsuite/g++.dg/template/const1.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/pt.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28385
[Bug c++/28385] [4.0/4.1 regression] templated function call goes awry
--- Comment #7 from jason at gcc dot gnu dot org 2006-08-18 16:27 --- Subject: Bug 28385 Author: jason Date: Fri Aug 18 16:27:03 2006 New Revision: 116243 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116243 Log: PR c++/28385 * pt.c (tsubst) [TEMPLATE_TYPE_PARM]: Ignore quals from template if arg is a function. Added: branches/gcc-4_0-branch/gcc/testsuite/g++.dg/template/const1.C - copied unchanged from r116203, trunk/gcc/testsuite/g++.dg/template/const1.C Modified: branches/gcc-4_0-branch/gcc/cp/ChangeLog branches/gcc-4_0-branch/gcc/cp/pt.c branches/gcc-4_0-branch/gcc/cp/search.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28385
[Bug bootstrap/28770] [4.1 Regression] one reference to powerpc-ibm-eabi-ar.exe when only xar.exe installed
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28770
[Bug target/25500] [4.0/4.1/4.2 Regression]: SSE2 vectorized code is slower on 4.x.x than previous
--- Comment #22 from bonzini at gnu dot org 2006-08-18 16:16 --- patch withdrawn, I'll wait for pinskia's -- bonzini at gnu dot org changed: What|Removed |Added URL|http://gcc.gnu.org/ml/gcc- | |patches/2006- | |08/msg00171.html| Keywords|patch | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25500
[Bug libfortran/28747] Empty write STREAM I/O file positioning problem
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-18 16:15 --- (In reply to comment #1) > Middle-end or backend problem? Can you look at the dump that is produced by -fdump-tree-final_cleanup and see if it is correct? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28747
[Bug libfortran/28747] Empty write STREAM I/O file positioning problem
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2006-08-18 16:12 --- Simplified test case used in discussion above. program streamtest implicit none real, dimension(2,3) :: anarray open(10, file="teststream", access="stream", form="unformatted") anarray = 3.14159 write(10) anarray !flush(10) write(10, pos=1) ! This is a way to position an unformatted file anarray = 0.0 read(10) anarray close(10,status="keep") end program streamtest Additional info: Using built-in specs. Target: x86_64-unknown-freebsd7.0 Configured with: ../gcc4x/configure --prefix=/home/sgk/work/4x --enable-languages=c,fortran Thread model: posix gcc version 4.2.0 20060816 (experimental) -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added GCC host triplet|FreeBSD |x86_64-unknown-freebsd7.0 GCC target triplet||x86_64-unknown-freebsd7.0 Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28747
[Bug libfortran/28747] Empty write STREAM I/O file positioning problem
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2006-08-18 16:08 --- Created an attachment (id=12093) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12093&action=view) assembly output for reduced case There is wrong code generated setting up the parameters for the second call to write. The pointers are off by 400. You can see this by comparing the instructions just before the first call too _gfortran_st_write vs the instructions leading up to the second _gfortran_st_write. -fdump-tree-original looks OK. Inserting a flush right after the first call to write in the test case and the problem goes away. Middle-end or backend problem? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28747
[Bug libstdc++/28765] __gnu_cxx::__vstring::clear() is slow
--- Comment #7 from ian at airs dot com 2006-08-18 15:58 --- Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28765
[Bug libstdc++/28765] __gnu_cxx::__vstring::clear() is slow
--- Comment #6 from pcarlini at suse dot de 2006-08-18 15:44 --- Fixed for 4.1.2. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28765
[Bug libstdc++/28765] __gnu_cxx::__vstring::clear() is slow
--- Comment #5 from paolo at gcc dot gnu dot org 2006-08-18 15:42 --- Subject: Bug 28765 Author: paolo Date: Fri Aug 18 15:42:27 2006 New Revision: 116241 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116241 Log: 2006-08-18 Paolo Carlini <[EMAIL PROTECTED]> PR libstdc++/28765 * include/ext/rc_string_base.h (_M_clear): New. * include/ext/sso_string_base.h (_M_clear): Likewise. * include/ext/vstring.h (clear): Use it. Modified: branches/gcc-4_1-branch/libstdc++-v3/ChangeLog branches/gcc-4_1-branch/libstdc++-v3/include/ext/rc_string_base.h branches/gcc-4_1-branch/libstdc++-v3/include/ext/sso_string_base.h branches/gcc-4_1-branch/libstdc++-v3/include/ext/vstring.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28765
[Bug libstdc++/28765] __gnu_cxx::__vstring::clear() is slow
--- Comment #4 from paolo at gcc dot gnu dot org 2006-08-18 15:42 --- Subject: Bug 28765 Author: paolo Date: Fri Aug 18 15:42:05 2006 New Revision: 116240 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116240 Log: 2006-08-18 Paolo Carlini <[EMAIL PROTECTED]> PR libstdc++/28765 * include/ext/rc_string_base.h (_M_clear): New. * include/ext/sso_string_base.h (_M_clear): Likewise. * include/ext/vstring.h (clear): Use it. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/ext/rc_string_base.h trunk/libstdc++-v3/include/ext/sso_string_base.h trunk/libstdc++-v3/include/ext/vstring.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28765
[Bug bootstrap/28770] [4.1 Regression] one reference to powerpc-ibm-eabi-ar.exe when only xar.exe installed
--- Comment #9 from bonzini at gnu dot org 2006-08-18 15:36 --- > Will that be in 4.1.2 (or is it in 4.1 prereleases) or only appear in 4.2 ? No. :-( > The problem I have is that I am nearly always using the latest binutils > because I did not get many regressions, but I sometimes regenerate with > previous versions of compiler (GCC-3.4.5 or even try GCC-2.95.3) I see. In fact those versions are even using Cygnus configure, so using them in a combined tree is a mess. There is no real solution. A combined tree is ok for 4.2, with the latest binutils maybe 4.1 too. But it fails with older GCCs. Backporting --with-build-time-tools to 4.1 would be a good idea, and then you can just always configure with --with-build-time-tools=$HOME/local/powerpc-ibm-eabi/bin (which would do no harm for 4.2, which is where --with-build-time-tools works). But it cannot be done, for sure, for 3.x. You can just stop using --program-prefix for the binutils. Then you'll have executables named powerpc-ibm-eabi-foo, which will work for GCC, and then rename them to xfoo at the end of compilation (you can rename because GCC will anyway use the executables in $HOME/local/powerpc-ibm-eabi/bin). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28770
[Bug boehm-gc/28760] GC_PTHREAD_CREATE_NAME segfaults in statically linked binaries
--- Comment #5 from sgilbertson at gcc dot gnu dot org 2006-08-18 15:33 --- The "ugly workaround" (which works great for my static builds!) patches a previous workaround: http://gcc.gnu.org/ml/java-patches/2006-q1/msg00181.html So this issue is related to #13212,which is assigned to Bryce: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13212 Maybe we want to note that 13212 blocks 28760, but in any event the longer term solution for 28760 seems to be making sure that the non-workaround solution to 13212 works for static builds. For a shorter-term solution, I wonder if a configure option could turn off GC_PTHREAD_SYM_VERSION. -- sgilbertson at gcc dot gnu dot org changed: What|Removed |Added CC||sgilbertson at gcc dot gnu ||dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28760
[Bug bootstrap/28770] [4.1 Regression] one reference to powerpc-ibm-eabi-ar.exe when only xar.exe installed
--- Comment #8 from etienne_lorrain at yahoo dot fr 2006-08-18 15:04 --- > For 4.2.0, it will find it and use it: Will that be in 4.1.2 (or is it in 4.1 prereleases) or only appear in 4.2 ? > > I was thinking "combined tree" was not as good, mostly because I had to > > select which common part of the trees to keep - and well, I may have > > choosen the binutils ones. > > > gcc should always win over binutils. That's by design. Changes to the > toplevel are almost always driven by changes in gcc -- the binutils tree > is mostly agnostic and just follows what gcc does. The problem I have is that I am nearly always using the latest binutils because I did not get many regressions, but I sometimes regenerate with previous versions of compiler (GCC-3.4.5 or even try GCC-2.95.3) - maybe only for a quick test - and I better not get libiberty from them for binutils... but that is for the other project, with the other processor... Thanks, Etienne. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28770
[Bug rtl-optimization/28772] Infinite loop in scheduler
--- Comment #3 from schwab at suse dot de 2006-08-18 14:50 --- scheduling:6473.35 (100%) usr 0.60 (88%) sys6473.98 (100%) wall 499608 kB (90%) ggc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28772
[Bug bootstrap/28770] one reference to powerpc-ibm-eabi-ar.exe when only xar.exe installed
--- Comment #7 from paolo dot bonzini at lu dot unisi dot ch 2006-08-18 14:08 --- Subject: Re: one reference to powerpc-ibm-eabi-ar.exe when only xar.exe installed etienne_lorrain at yahoo dot fr wrote: > --- Comment #6 from etienne_lorrain at yahoo dot fr 2006-08-18 13:55 > --- > I do have $(HOME)/local/powerpc-ibm-eabi/bin/ar.exe > and I am using $(HOME)/local/bin/xar.exe for my stuff here, after install. > To bootstrap, GCC may better use $(HOME)/local/powerpc-ibm-eabi/bin/ar.exe > but that will not be in the path, so GCC needs to call it with full path. > For 4.2.0, it will find it and use it: if test x$host = x$build && test -f $srcdir/gcc/BASE-VER; then ... gcc_cv_tool_dirs="$gcc_cv_tool_dirs$gcc_cv_tool_prefix/$target_noncanonical/bin$PATH_SEPARATOR" else gcc_cv_tool_dirs= fi ... if test -z "$ac_cv_path_$1" ; then AC_PATH_PROG([$1], [$2], [], [$gcc_cv_tool_dirs]) fi What 4.2.0 does is to use the same algorithm that the compiler will use to find the assembler/linker, and apply it for other tools such as ar. We decided that a configuration where this breaks is already broken too much. For 4.1.x it was somewhat a mess. What people were really doing "in the wild" was not yet clear, as it was by the time we finished cleaning up this stuff, so there were some unintended changes in the behavior. But the combined tree will surely work. > I was thinking "combined tree" was not as good, mostly because I had to > select which common part of the trees to keep - and well, I may have > choosen the binutils ones. > gcc should always win over binutils. That's by design. Changes to the toplevel are almost always driven by changes in gcc -- the binutils tree is mostly agnostic and just follows what gcc does. Paolo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28770
[Bug bootstrap/28770] one reference to powerpc-ibm-eabi-ar.exe when only xar.exe installed
--- Comment #6 from etienne_lorrain at yahoo dot fr 2006-08-18 13:55 --- I do have $(HOME)/local/powerpc-ibm-eabi/bin/ar.exe and I am using $(HOME)/local/bin/xar.exe for my stuff here, after install. To bootstrap, GCC may better use $(HOME)/local/powerpc-ibm-eabi/bin/ar.exe but that will not be in the path, so GCC needs to call it with full path. I was thinking "combined tree" was not as good, mostly because I had to select which common part of the trees to keep - and well, I may have choosen the binutils ones (difficult to report a bug to binutils when you did not use their source to generate). Thanks for the trick about using cpio with or without the -u option (better than "rm -rf" in Makefile), and to show the order you use too. Etienne. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28770
[Bug bootstrap/28770] one reference to powerpc-ibm-eabi-ar.exe when only xar.exe installed
--- Comment #5 from bonzini at gnu dot org 2006-08-18 13:34 --- Anyway, the simplest solution for you is to build in a combined tree: cd build && rm -rf ppc_combined_src ppc_combined && \ mkdir ppc_combined_src ppc_combined cd build/binutils-$(BINUTILS_VERSION) && find . -print | \ cpio -pdlm ../ppc_combined_src cd build/gcc-$(GCC_VERSION) && find . -print | \ cpio -pdlmu ../ppc_combined_src cd build/ppc_combined && ../ppc_combined_src/configure \ --prefix=$(HOME)/local --program-prefix=x --target=powerpc-ibm-eabi cd build/ppc_combined && make && make install It works for either native or cross, and for native it will test the binutils by using them to compile themselves. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28770
[Bug bootstrap/28770] one reference to powerpc-ibm-eabi-ar.exe when only xar.exe installed
--- Comment #4 from bonzini at gnu dot org 2006-08-18 13:28 --- No, I was misreading the binutils Makefile. Etienne, can you confirm that you have $(HOME)/local/powerpc-ibm-eabi/bin/ar ? It is fixed in 4.2.0 if this is the case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28770
[Bug bootstrap/28770] one reference to powerpc-ibm-eabi-ar.exe when only xar.exe installed
--- Comment #3 from bonzini at gnu dot org 2006-08-18 13:18 --- If I remember/understand correctly, this "happened to work" in older GCC releases (that is, the program prefix was added automatically if no other target tool was found), except that after the installation GCC would forget that the assembler is "xas" and not "powerpc-ibm-eabi-as". The problem is that binutils will install itself into $(HOME)/local/powerpc-ibm-eabi/bin/xar, not $(HOME)/local/powerpc-ibm-eabi/bin/ar. -- bonzini at gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bonzini at gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-08-18 13:18:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28770
[Bug target/23740] attiny13 and attiny2313 are not fully supported
--- Comment #1 from berndtrog at yahoo dot com 2006-08-18 12:59 --- Fixed in r114758. Thanks! -- berndtrog at yahoo dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23740
[Bug rtl-optimization/28772] Infinite loop in scheduler
--- Comment #2 from bonzini at gnu dot org 2006-08-18 12:47 --- Not an infinite loop. 100 lines => 0.47 sec 200 lines => 0.95 sec 1000 lines => 6.16 sec 1500 lines => 11.19 sec 2000 lines => 18.11 sec 2500 lines => 27.26 sec 3000 lines => 37.83 sec 3200 lines => 42.72 sec 3340 lines => 46.00 sec -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28772
[Bug target/25451] [AVR] Add support for new devices
--- Comment #2 from berndtrog at yahoo dot com 2006-08-18 12:47 --- Atmel's new devices where added in r113982. Thanks! -- berndtrog at yahoo dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25451
[Bug bootstrap/28770] one reference to powerpc-ibm-eabi-ar.exe when only xar.exe installed
--- Comment #2 from etienne_lorrain at yahoo dot fr 2006-08-18 12:25 --- I change --target=powerpc-ibm-eabi to --target=powerpc-eabi and --enable-languages=c to --enable-languages=c,c++ but the configure should be the same, I do not know what means "pre-installed"... # rm -rf build/ppc_gcc && mkdir build/ppc_gcc cd build/ppc_gcc && ../gcc-4.1.1/configure --prefix=/cygdrive/c/cygwin-gcc/local --program-prefix=x --target=powerpc-eabi \ --with-cpu=440 --with-newlib --enable-languages=c,c++ creating cache ./config.cache checking host system type... i686-pc-cygwin checking target system type... powerpc-unknown-eabi checking build system type... i686-pc-cygwin checking for a BSD compatible install... /usr/bin/install -c checking whether ln works... yes checking whether ln -s works... yes checking for gcc... gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking for gnatbind... no checking whether compiler driver understands Ada... no checking how to compare bootstrapped objects... cmp --ignore-initial=16 $$f1 $$f 2 checking for correct version of gmp.h... no *** This configuration is not supported in the following subdirectories: target-libmudflap (Any other directories should still work fine.) checking for bison... bison -y checking for bison... bison checking for gm4... no checking for gnum4... no checking for m4... m4 checking for flex... flex checking for flex... flex checking for makeinfo... makeinfo checking for expect... expect checking for runtest... no checking for i686-pc-cygwin-ar... no checking for ar... ar checking for i686-pc-cygwin-as... no checking for as... as checking for i686-pc-cygwin-dlltool... no checking for dlltool... dlltool checking for i686-pc-cygwin-ld... /cygdrive/c/cygwin-gcc/local/lib/gcc/i686-pc-c ygwin/4.1.1/../../../../i686-pc-cygwin/bin/ld.exe checking for i686-pc-cygwin-lipo... no checking for lipo... no checking for i686-pc-cygwin-nm... no checking for nm... nm checking for i686-pc-cygwin-ranlib... no checking for ranlib... ranlib checking for i686-pc-cygwin-strip... no checking for strip... strip checking for i686-pc-cygwin-windres... no checking for windres... windres checking for i686-pc-cygwin-objcopy... no checking for objcopy... objcopy checking for i686-pc-cygwin-objdump... no checking for objdump... objdump checking for powerpc-eabi-ar... no checking for powerpc-eabi-as... no checking for powerpc-eabi-cc... no checking for powerpc-eabi-gcc... no checking for powerpc-eabi-c++... no checking for powerpc-eabi-g++... no checking for powerpc-eabi-cxx... no checking for powerpc-eabi-gxx... no checking for powerpc-eabi-dlltool... no checking for powerpc-eabi-gcc... no checking for powerpc-eabi-gcj... no checking for powerpc-eabi-gfortran... no checking for powerpc-eabi-ld... no checking for powerpc-eabi-lipo... no checking for powerpc-eabi-nm... no checking for powerpc-eabi-objdump... no checking for powerpc-eabi-ranlib... no checking for powerpc-eabi-strip... no checking for powerpc-eabi-windres... no checking where to find the target ar... pre-installed checking where to find the target as... pre-installed checking where to find the target cc... just compiled checking where to find the target c++... just compiled checking where to find the target c++ for libstdc++... just compiled checking where to find the target dlltool... pre-installed checking where to find the target gcc... just compiled checking where to find the target gcj... pre-installed checking where to find the target gfortran... pre-installed checking where to find the target ld... pre-installed checking where to find the target lipo... pre-installed checking where to find the target nm... pre-installed checking where to find the target objdump... pre-installed checking where to find the target ranlib... pre-installed checking where to find the target strip... pre-installed checking where to find the target windres... pre-installed checking whether to enable maintainer-specific portions of Makefiles... no checking if symbolic links between directories work... yes updating cache ./config.cache creating ./config.status creating Makefile -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28770
[Bug fortran/28762] program name 'write' causes compiler crash on if statements containing write commands.
--- Comment #2 from patchapp at dberlin dot org 2006-08-18 12:20 --- Subject: Bug number PR28762 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00641.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28762
[Bug target/26778] [4.0/4.1/4.2 regression] GCC4 moves the result of a conditional block through inadequate registers
--- Comment #9 from bonzini at gnu dot org 2006-08-18 12:07 --- patch bootstrapped & tested on ia64, ppc, x86_64, s390, everywhere including ada but not java, w/ no regressions -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26778
[Bug rtl-optimization/28772] Infinite loop in scheduler
--- Comment #1 from schwab at suse dot de 2006-08-18 11:49 --- Created an attachment (id=12092) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12092&action=view) Testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28772
[Bug rtl-optimization/28772] New: Infinite loop in scheduler
The scheduler apparently infloops on the attached test case when compiling with -O2. #0 internal_state_transition (insn_code=114, chip=0x6019ed70) at ../../gcc/config/ia64/itanium2.md:125927 #1 0x406e81d0 in schedule_block (b=, rgn_n_insns=20657) at ../../gcc/haifa-sched.c:1758 #2 0x407928c0 in schedule_region (rgn=0) at ../../gcc/sched-rgn.c:2394 #3 0x40796f40 in schedule_insns (dump_file=) at ../../gcc/sched-rgn.c:2543 #4 0x4059ca00 in execute_one_pass (pass=0x600410e8) at ../../gcc/passes.c:827 #5 0x4059cd00 in execute_pass_list (pass=0x600410e8) at ../../gcc/passes.c:859 #6 0x4059cd40 in execute_pass_list (pass=0x6003fab8) at ../../gcc/passes.c:860 #7 0x400feb60 in tree_rest_of_compilation (fndecl=0x20457a00) at ../../gcc/tree-optimize.c:419 #8 0x4001ca40 in c_expand_body (fndecl=0x20457a00) at ../../gcc/c-decl.c:6690 #9 0x4060e3d0 in cgraph_expand_function (node=0x2045d1e0) at ../../gcc/cgraphunit.c:1058 #10 0x40610e80 in cgraph_optimize () at ../../gcc/cgraphunit.c:1124 #11 0x4002cb10 in c_write_global_declarations () at ../../gcc/c-decl.c:7698 #12 0x4054b850 in toplev_main (argc=, argv=) at ../../gcc/toplev.c:1004 #13 0x400d6fd0 in main (argc=4, argv=0x607ffeaf2738) at ../../gcc/main.c:35 -- Summary: Infinite loop in scheduler Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: compile-time-hog Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: schwab at suse dot de GCC target triplet: ia64-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28772
[Bug bootstrap/28770] one reference to powerpc-ibm-eabi-ar.exe when only xar.exe installed
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-18 11:47 --- powerpc-ibm-eabi-ar.exe should have been installed by binutils unless you are doing a combined tree but since you are using a program prefix the problem is that GCC does not take that into account for the ar, I think. Can you give the output of the orginal configure for gcc? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |bootstrap http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28770
[Bug target/28621] [4.1/4.2 Regression] SIGSEGV in set_fast_math () at -Os
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-08-18 11:42 --- (In reply to comment #6) > Sorry, but I didn't know that. I reported the bug against GCC 4.1.1 and the > target milestone set for it is GCC 4.1.2. So, I expected that patch to work > with gcc 4.1.x. The 'force_align_arg_pointer' attribute is available at GCC > 4.1.2 or just GCC 4.2.x? Just 4.2.0 which right now the trunk (aka mainline) of the svn. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28621
[Bug fortran/28771] New: gfortran accepts invalid variable definition
As far as I know, the following code snippet is not valid Fortran: program test character(len=*) :: foo = 'test' end To make the code correct, the variable definition either needs the "parameter" attribute or an explicit length. Other compilers (Intel, Fujitsu and NAG) reject this code, but all current versions of gfortran accept it without warning. -- Summary: gfortran accepts invalid variable definition Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: martin at mpa-garching dot mpg dot de 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=28771
[Bug libgcj/28698] [gcj] libgcj-bc only used when building shared libs, not executables
--- Comment #3 from doko at ubuntu dot com 2006-08-18 11:38 --- Created an attachment (id=12091) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12091&action=view) example more simple example from the gettext source, compiled with gcj -C gnu/gettext/GetURL.java gcj -v -fjni -findirect-dispatch gnu/gettext/GetURL.class --main=gnu.gettext.GetURL -o gnu.gettext.GetURL -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28698
[Bug c++/27177] [4.0 Regression] ICE in build_simple_base_path, at cp/class.c:474
--- Comment #8 from zak at transversal dot com 2006-08-18 11:21 ---
However, that patch breaks the following code, which requires *implicit*
derived-to-base conversion:
struct Z {};
struct A : Z {};
Z* implicitToZ (Z*);
struct B : A
{
static const int i = sizeof(implicitToZ((B*)0));
};
Without the patch, the above compiles cleanly (as it does in 4.0.3, 4.1.1 and
Comeau). With the patch, I get:
$ g++ -c dtob.cc
dtob.cc:8: error: invalid conversion from 'B*' to 'Z*'
dtob.cc:8: error: initializing argument 1 of 'Z* implicitToZ(Z*)'
The standard (in 4.10 [conv.ptr], paragraph 3) states that a program requiring
a derived-to-base conversion is ill-formed if the base class is inaccessible or
ambiguous; it does not mention any requirement that the derived class must be
complete.
This breaks code like this using boost::is_base_and_derived (this is cut down
from a real-world example):
#include
#include
struct Base { };
template< typename T >
struct A {
BOOST_STATIC_ASSERT(( boost::is_base_and_derived< Base, T >::value ));
struct Inner { };
};
struct Derived : Base {
typedef A< Derived >::Inner Inner;
};
--
zak at transversal dot com changed:
What|Removed |Added
CC||zak at transversal dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27177
[Bug c/28744] externally_visible attribute not effective with prior declaration of symbol.
--- Comment #10 from dwmw2 at infradead dot org 2006-08-18 11:11 ---
I've hacked around this for now by reverting the patch for PR25795 and doing
this instead:
--- gcc/c-decl.c~ 2006-01-19 23:48:07.0 +
+++ gcc/c-decl.c2006-08-15 21:43:43.0 +0100
@@ -1660,6 +1660,25 @@ merge_decls (tree newdecl, tree olddecl,
if (TREE_DEPRECATED (newdecl))
TREE_DEPRECATED (olddecl) = 1;
+ if (TREE_CODE (newdecl) == FUNCTION_DECL)
+{
+ struct cgraph_node *n = cgraph_node (newdecl);
+ if (n->local.externally_visible)
+ {
+ struct cgraph_node *o = cgraph_node (olddecl);
+ o->local.externally_visible = true;
+ }
+}
+ else if (TREE_CODE (newdecl) == VAR_DECL)
+{
+ struct cgraph_varpool_node *n = cgraph_varpool_node (newdecl);
+ if (n->externally_visible)
+ {
+ struct cgraph_varpool_node *o = cgraph_varpool_node (olddecl);
+ o->externally_visible = true;
+ }
+}
+
/* Keep source location of definition rather than declaration and of
prototype rather than non-prototype unless that prototype is
built-in. */
--- gcc/c-common.c~ 2006-08-18 10:35:10.0 +0100
+++ gcc/c-common.c 2006-08-18 10:52:18.0 +0100
@@ -4243,7 +4243,7 @@ handle_externally_visible_attribute (tre
{
tree node = *pnode;
- if ((!TREE_STATIC (node) && TREE_CODE (node) != FUNCTION_DECL)
+ if (0 && (!TREE_STATIC (node) && TREE_CODE (node) != FUNCTION_DECL)
|| !TREE_PUBLIC (node))
{
warning (OPT_Wattributes,
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28744
[Bug c/28770] New: one reference to powerpc-ibm-eabi-ar.exe when only xar.exe installed
Unlike with GCC-3.*, building GCC-4.1.1 PPC crosscompiler from a bootstrapped native GCC-4.1.1 and binutils-2.17 on cygwin fails because of a small error. Using a new and up to date Cygwin install. xgcc -v (after fix) gives: Using built-in specs. Target: powerpc-ibm-eabi Configured with: ../gcc-4.1.1/configure --prefix=/cygdrive/c/cygwin-gcc/local --program-prefix=x --target=powerpc-ibm-eabi --with-cpu=440 --with-newlib --enable-languages=c Thread model: single gcc version 4.1.1 The error message is: ../../gcc-4.1.1/gcc/unwind-c.c:1: warning: -msoft-float and -mlong-double-128 no t supported rm -f ./libgcc.a powerpc-ibm-eabi-ar rc ./libgcc.a libgcc/./_muldi3.o libgcc/./_negdi2.o libgcc/ ./_lshrdi3.o libgcc/./_ashldi3.o libgcc/./_ashrdi3.o libgcc/./_cmpdi2.o libgcc/. /_ucmpdi2.o libgcc/./_floatdidf.o libgcc/./_floatdisf.o libgcc/./_fixunsdfsi.o l ibgcc/./_fixunssfsi.o libgcc/./_fixunsdfdi.o libgcc/./_fixdfdi.o libgcc/./_fixun ssfdi.o libgcc/./_fixsfdi.o libgcc/./_fixxfdi.o libgcc/./_fixunsxfdi.o libgcc/./ _floatdixf.o libgcc/./_fixunsxfsi.o libgcc/./_fixtfdi.o libgcc/./_fixunstfdi.o l ibgcc/./_floatditf.o libgcc/./_clear_cache.o libgcc/./_enable_execute_stack.o li bgcc/./_trampoline.o libgcc/./__main.o libgcc/./_absvsi2.o libgcc/./_absvdi2.o l ibgcc/./_addvsi3.o libgcc/./_addvdi3.o libgcc/./_subvsi3.o libgcc/./_subvdi3.o l ibgcc/./_mulvsi3.o libgcc/./_mulvdi3.o libgcc/./_negvsi2.o libgcc/./_negvdi2.o l ibgcc/./_ctors.o libgcc/./_ffssi2.o libgcc/./_ffsdi2.o libgcc/./_clz.o libgcc/./ _clzsi2.o libgcc/./_clzdi2.o libgcc/./_ctzsi2.o libgcc/./_ctzdi2.o libgcc/./_pop count_tab.o libgcc/./_popcountsi2.o libgcc/./_popcountdi2.o libgcc/./_paritysi2. o libgcc/./_paritydi2.o libgcc/./_powisf2.o libgcc/./_powidf2.o libgcc/./_powixf 2.o libgcc/./_powitf2.o libgcc/./_mulsc3.o libgcc/./_muldc3.o libgcc/./_mulxc3.o libgcc/./_multc3.o libgcc/./_divsc3.o libgcc/./_divdc3.o libgcc/./_divxc3.o lib gcc/./_divtc3.o libgcc/./_eprintf.o libgcc/./__gcc_bcmp.o libgcc/./_divdi3.o lib gcc/./_moddi3.o libgcc/./_udivdi3.o libgcc/./_umoddi3.o libgcc/./_udiv_w_sdiv.o libgcc/./_udivmoddi4.o libgcc/./_pack_sf.o libgcc/./_unpack_sf.o libgcc/./_addsu b_sf.o libgcc/./_mul_sf.o libgcc/./_div_sf.o libgcc/./_fpcmp_parts_sf.o libgcc/. /_compare_sf.o libgcc/./_eq_sf.o libgcc/./_ne_sf.o libgcc/./_gt_sf.o libgcc/./_g e_sf.o libgcc/./_lt_sf.o libgcc/./_le_sf.o libgcc/./_unord_sf.o libgcc/./_si_to_ sf.o libgcc/./_sf_to_si.o libgcc/./_negate_sf.o libgcc/./_make_sf.o libgcc/./_sf _to_df.o libgcc/./_thenan_sf.o libgcc/./_sf_to_usi.o libgcc/./_usi_to_sf.o libgc c/./_pack_df.o libgcc/./_unpack_df.o libgcc/./_addsub_df.o libgcc/./_mul_df.o li bgcc/./_div_df.o libgcc/./_fpcmp_parts_df.o libgcc/./_compare_df.o libgcc/./_eq_ df.o libgcc/./_ne_df.o libgcc/./_gt_df.o libgcc/./_ge_df.o libgcc/./_lt_df.o lib gcc/./_le_df.o libgcc/./_unord_df.o libgcc/./_si_to_df.o libgcc/./_df_to_si.o li bgcc/./_negate_df.o libgcc/./_make_df.o libgcc/./_df_to_sf.o libgcc/./_thenan_df .o libgcc/./_df_to_usi.o libgcc/./_usi_to_df.o libgcc/./tramp.o libgcc/./darwin- ldouble.o libgcc/./eabi.o libgcc/./unwind-dw2.o libgcc/./unwind-dw2-fde.o libgcc /./unwind-sjlj.o libgcc/./gthr-gnat.o libgcc/./unwind-c.o make[4]: powerpc-ibm-eabi-ar: Command not found make[4]: *** [libgcc.a] Error 127 make[4]: Leaving directory `/cygdrive/c/cygwin-gcc/build/ppc_gcc/gcc' make[3]: *** [stmp-multilib] Error 2 make[3]: Leaving directory `/cygdrive/c/cygwin-gcc/build/ppc_gcc/gcc' make[2]: *** [all-gcc] Error 2 make[2]: Leaving directory `/cygdrive/c/cygwin-gcc/build/ppc_gcc' make[1]: *** [all] Error 2 To fix this problem, just do: $ cd /cygdrive/c/cygwin-gcc/local/bin $ cp xar.exe powerpc-ibm-eabi-ar.exe and rerun "make ; make install" in `/cygdrive/c/cygwin-gcc/build/ppc_gcc/gcc' Extract of Makefile used to rebuild everything: --- FTPMIRROR := http://www.mirrorservice.org/sites/ GCC_VERSION := 4.1.1 BINUTILS_VERSION := 2.17 HOME = /cygdrive/c/cygwin-gcc PATH := $(HOME)/local/bin/:/usr/local/bin:/usr/bin:/bin src: mkdir src build: mkdir build local: mkdir local lib: mkdir lib target: mkdir target src/gcc-core-$(GCC_VERSION).tar.bz2: wget --directory-prefix=src $(FTPMIRROR)/sources.redhat.com/pub/gcc/releases/gcc-$(GCC_VERSION)/gcc-core-$(GCC_VERSION).tar.bz2 src/binutils-$(BINUTILS_VERSION).tar.bz2: wget --directory-prefix=src $(FTPMIRROR)/sources.redhat.com/pub/binutils/releases/binutils-$(BINUTILS_VERSION).tar.bz2 src/gcc-g++-$(GCC_VERSION).tar.bz2: wget --directory-prefix=src $(FTPMIRROR)/sources.redhat.com/pub/gcc/releases/gcc-$(GCC_VERSION)/gcc-g++-$(GCC_VERSION).tar.bz2 toolchain-src: src build src/gcc-core-$(GCC_VERSION).tar.bz2 src/gcc-g++-$(GCC_VERSION).tar.bz2 src/binutils-$(BINUTILS_VERSION).tar.bz2 rm -rf build/* cd build && tar -xjf ../src/binutils-$(BINUTILS_VERSION).tar.bz2 cd build && tar -xjf ../src/gcc-core-$(GCC_VERSION).tar.bz2
[Bug fortran/28762] program name 'write' causes compiler crash on if statements containing write commands.
--- Comment #1 from pault at gcc dot gnu dot org 2006-08-18 10:01 --- Created an attachment (id=12090) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12090&action=view) Fix for the problem This is regtesting right now - I have to go and cut a hedge... a huge hedge (*sigh*)... but I will submit the patch afterwards. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28762
[Bug libstdc++/28765] __gnu_cxx::__vstring::clear() is slow
--- Comment #3 from pcarlini at suse dot de 2006-08-18 08:31 --- Ok, I see... Then I will do the change, a little embarassing ;) By the way, if it's not obvious, the reason we don't simply call _M_set_length is the other base class, where clear cannot be trivial (due to refcounting) and the meaningful thing to do is considering clear a special case of erase and share code. At some point we should add a new _M_clear to both base classes and either forward to _M_erase or just call _M_set_length. -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|ian at airs dot com |pcarlini at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28765
[Bug web/28714] Bugzilla mail sent from invalid address
--- Comment #5 from dwmw2 at infradead dot org 2006-08-18 08:10 --- Yep, I got the mail. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28714
[Bug target/28621] [4.1/4.2 Regression] SIGSEGV in set_fast_math () at -Os
--- Comment #6 from magsilva at gmail dot com 2006-08-18 07:16 --- Sorry, but I didn't know that. I reported the bug against GCC 4.1.1 and the target milestone set for it is GCC 4.1.2. So, I expected that patch to work with gcc 4.1.x. The 'force_align_arg_pointer' attribute is available at GCC 4.1.2 or just GCC 4.2.x? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28621
