Re: copyright assignment
On 11/22/2009 10:48 AM, John Nowak wrote: Hello. I would like to get the necessary forms for copyright assignment to GCC for future work on GNAT. I was told this is the way to kick off the process. I sent them offlist. Paolo
[cygwin-1.7] bootstrap failure: ../../gcc/gcc/config/i386/i386.c:24542:24: error: comparison between signed and unsigned integer expressions
Seems to me that http://gcc.gnu.org/ml/gcc-cvs/2009-11/msg00648.html might cause this: /usr/local/src/trunk/objdir/./prev-gcc/xgcc -B/usr/local/src/trunk/objdir/./prev-gcc/ -B/usr/local/gnu/i686-pc-cygwin/bin/ -B/usr/local/gnu/i686-pc-cygwin/bin/ -B/usr/local/gnu/i686-pc-cygwin/lib/ -isystem /usr/local/gnu/i686-pc-cygwin/include -isystem /usr/local/gnu/i686-pc-cygwin/sys-include-c -g -O2 -gtoggle -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -Iyes/include -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -DCLOOG_PPL_BACKEND\ ../../gcc/gcc/config/i386/i386.c -o i386.o cc1: warnings being treated as errors ../../gcc/gcc/config/i386/i386.c: In function 'avx_vpermilp_parallel': ../../gcc/gcc/config/i386/i386.c:24542:24: error: comparison between signed and unsigned integer expressions make[3]: *** [i386.o] Error 1 make[3]: Leaving directory `/usr/local/src/trunk/objdir/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/usr/local/src/trunk/objdir' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/usr/local/src/trunk/objdir' Windows XP Pro/SP3 cygwin Intel Core2 Duo t9...@2.80ghz system with packages: binutils 2.19.51-1 2.19.51.20090704 bison2.3-1 2.3 cloog-ppl0.15.3-1 cygwin 1.7.0-65 dejagnu 20021217-2 1.4.2.x expect 20030128-1 5.26 gcc4-ada 4.3.4-1 gcc4-core4.3.4-1 gcc4-g++ 4.3.4-1 gmp 4.3.1-3 libcloog-devel 0.15.3-1 libgmp-devel 4.3.1-3 libmpc-devel 0.8-1 libmpfr-devel2.4.1-4 libppl 0.10.2-1 make 3.81-2 mpclib 0.8-1 mpfr 2.4.1-4 ppl 0.10.2-1 ppl-devel0.10.2-1 tcltk20080420-1 8.4 w32api 3.14-1 LAST_UPDATED: Mon Nov 23 06:25:08 UTC 2009 (revision 154431) This is on -- Cheers, /ChJ
Re: BUG: GCC-4.4.x changes the function frame on some functions
On Thu, Nov 19, 2009 at 08:01:57PM +0100, Thomas Gleixner wrote: Just compiled with -mincoming-stack-boundary=4 and the problem goes away as gcc now thinks that the incoming stack is already 16 byte aligned. But that might break code which actually uses SSE Please don't do this, lying to the compiler is just going to result in wrong-code sooner or later, with the above switch gcc will assume the incoming stack is 16-byte aligned (which is not true in the ix86 kernel) and could very well e.g. optimize away code that looks at alignment of stack variables etc. Jakub
Re: BUG: GCC-4.4.x changes the function frame on some functions
On Mon, 23 Nov 2009, Jakub Jelinek wrote: On Thu, Nov 19, 2009 at 08:01:57PM +0100, Thomas Gleixner wrote: Just compiled with -mincoming-stack-boundary=4 and the problem goes away as gcc now thinks that the incoming stack is already 16 byte aligned. But that might break code which actually uses SSE Please don't do this, lying to the compiler is just going to result in wrong-code sooner or later, with the above switch gcc will assume the incoming stack is 16-byte aligned (which is not true in the ix86 kernel) and could very well e.g. optimize away code that looks at alignment of stack variables etc. Right. I gave up the idea pretty fast. But in the current situation we are forced to lie to the compiler in some way. Forcing -mtune=generic when the function graph tracer is enabled seems to be a halfways sane work around. Thanks, tglx
Re: i370 port - 3.4.6 to 4.4 upgrade attempt
Ok, now that 3.4.6 is fully working, I made a start on the 4.4 port. 4.4 appears to have invalidated a lot of 3.4.6 things. Below are all the changes I needed to make just to get an xgcc executable built. I didn't really know what most of it was about, but the purpose was just to scope the changes. Any changes that need to be done to 4.4 I can now refer to how it was accomplished in 3.4.6. So, given the scope below, can someone please explain what 4.4 changes are affecting me and what I need to do to overcome them? Note that I have never had to do the machine changes myself - in the past I simply waiting for Dave Pitts to do the upgrade to the new version, and then with a working 370 code generator I would make all the changes necessary for MVS. This time I don't have a working code generator. With these changes to force an executable, I can go: xgcc --version and it works, but when I attempt a compile (with -S), I get an internal error in builtin line 0, which is presumably completely meaningless because I haven't actually done the work yet. Thanks. Paul. Index: gcc4/config.sub diff -c gcc4/config.sub:1.3 gcc4/config.sub:1.4 *** gcc4/config.sub:1.3 Mon Nov 23 12:58:07 2009 --- gcc4/config.sub Mon Nov 23 22:47:08 2009 *** *** 940,945 --- 940,948 rtpc | rtpc-*) basic_machine=romp-ibm ;; + i370 | i370-*) + basic_machine=i370-ibm + ;; s390 | s390-*) basic_machine=s390-ibm ;; Index: gcc4/gcc/config.gcc diff -c gcc4/gcc/config.gcc:1.3 gcc4/gcc/config.gcc:1.4 *** gcc4/gcc/config.gcc:1.3 Mon Nov 23 12:58:07 2009 --- gcc4/gcc/config.gcc Mon Nov 23 22:46:56 2009 *** *** 358,363 --- 358,366 cpu_type=spu need_64bit_hwint=yes ;; + i370*-*-*) + cpu_type=i370 + ;; s390*-*-*) cpu_type=s390 need_64bit_hwint=yes *** *** 1964,1969 --- 1967,1984 thread_file='aix' extra_headers=altivec.h ;; + i370-*-mvspdp) + xm_defines='POSIX' # 'FATAL_EXIT_CODE=12' + xm_file=i370/xm-mvs.h + tm_file=i370/mvspdp.h i370/i370.h + tmake_file=i370/t-mvs i370/t-i370 + c_target_objs=i370-c.o + cxx_target_objs=i370-c.o + ;; + s390-*-linux*) + tm_file=s390/s390.h dbxelf.h elfos.h svr4.h linux.h s390/linux.h + tmake_file=${tmake_file} t-dfprules s390/t-crtstuff s390/t-linux + ;; s390-*-linux*) tm_file=s390/s390.h dbxelf.h elfos.h svr4.h linux.h s390/linux.h tmake_file=${tmake_file} t-dfprules s390/t-crtstuff s390/t-linux Index: gcc4/gcc/config/i370/i370-c.c diff -c gcc4/gcc/config/i370/i370-c.c:1.5 gcc4/gcc/config/i370/i370-c.c:1.6 *** gcc4/gcc/config/i370/i370-c.c:1.5 Mon Nov 23 22:17:42 2009 --- gcc4/gcc/config/i370/i370-c.c Mon Nov 23 22:46:22 2009 *** *** 34,40 #ifdef TARGET_HLASM ! #define BAD(msgid) do { warning (msgid); return; } while (0) /* #pragma map (name, alias) - In this implementation both name and alias are required to be --- 34,43 #ifdef TARGET_HLASM ! #define BAD(msgid) do { warning (0, msgid); return; } while (0) ! ! /* +++ c_lex has gone. however, we don't use it for anything important anyway */ ! #define c_lex(a) /* #pragma map (name, alias) - In this implementation both name and alias are required to be *** *** 42,52 anyone clarify? */ void ! i370_pr_map (pfile) ! cpp_reader *pfile ATTRIBUTE_UNUSED; { tree name, alias, x; if (c_lex (x) != CPP_OPEN_PAREN) BAD (missing '(' after '#pragma map' - ignored); --- 45,55 anyone clarify? */ void ! i370_pr_map (cpp_reader *pfile ATTRIBUTE_UNUSED) { tree name, alias, x; + #if 0 if (c_lex (x) != CPP_OPEN_PAREN) BAD (missing '(' after '#pragma map' - ignored); *** *** 63,70 BAD (missing ')' for '#pragma map' - ignored); if (c_lex (x) != CPP_EOF) ! warning (junk at end of '#pragma map'); ! mvs_add_alias (IDENTIFIER_POINTER (name), TREE_STRING_POINTER (alias), 1); } --- 66,73 BAD (missing ')' for '#pragma map' - ignored); if (c_lex (x) != CPP_EOF) ! warning (0, junk at end of '#pragma map'); ! #endif mvs_add_alias (IDENTIFIER_POINTER (name), TREE_STRING_POINTER (alias), 1); } *** *** 74,84 anyone clarify? */ void ! i370_pr_linkage (pfile) ! cpp_reader *pfile ATTRIBUTE_UNUSED; { tree name, mode, x; if (c_lex (x) != CPP_OPEN_PAREN) BAD (missing '(' after '#pragma linkage' - ignored); --- 77,87 anyone clarify? */ void ! i370_pr_linkage (cpp_reader *pfile ATTRIBUTE_UNUSED) { tree name, mode, x; + #if 0 if (c_lex (x) != CPP_OPEN_PAREN) BAD (missing '(' after '#pragma linkage' - ignored); *** *** 95,102 BAD (missing ')' for '#pragma linkage' - ignored); if (c_lex (x) != CPP_EOF) ! warning (junk at end of '#pragma linkage'); ! } /* #pragma checkout (mode) - --- 98,105 BAD (missing ')' for '#pragma linkage' - ignored); if (c_lex (x) != CPP_EOF) ! warning (0,
Re: GCC 4.5 is uncompilable
Dave Korn wrote: If that doesn't fix it please let me know. The solution was correct, with binutils 2.20 the problem disappeared. There is another one, however on the snapshot 20091119: ../../gcc/lto-streamer-out.c: In function 'write_global_references': ../../gcc/lto-streamer-out.c:2201:7: error: passing argument 3 of 'lto_streamer_ cache_lookup' from incompatible pointer type ../../gcc/lto-streamer.h:790:13: note: expected 'int *' but argument is of type 'int32_t *' which is a source code bug: a local variable ref of type int32_t is passed by pointer to a function which takes int*. Don't know about trunk, as I just started building it. Best regards Piotr Wyderski
Re: i370 port - 3.4.6 to 4.4 upgrade attempt
Paul Edwards mutazi...@gmail.com writes: Index: gcc4/config.sub diff -c gcc4/config.sub:1.3 gcc4/config.sub:1.4 *** gcc4/config.sub:1.3 Mon Nov 23 12:58:07 2009 --- gcc4/config.sub Mon Nov 23 22:47:08 2009 You should send patches for config.{guess,sub} to config-patc...@gnu.org. Andreas. -- Andreas Schwab, sch...@redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E And now for something completely different.
Re: [cygwin-1.7] bootstrap failure: ../../gcc/gcc/config/i386/i386.c:24542:24: error: comparison between signed and unsigned integer expressions
2009/11/23 Christian Joensson: Seems to me that http://gcc.gnu.org/ml/gcc-cvs/2009-11/msg00648.html might cause this: /usr/local/src/trunk/objdir/./prev-gcc/xgcc -B/usr/local/src/trunk/objdir/./prev-gcc/ -B/usr/local/gnu/i686-pc-cygwin/bin/ -B/usr/local/gnu/i686-pc-cygwin/bin/ -B/usr/local/gnu/i686-pc-cygwin/lib/ -isystem /usr/local/gnu/i686-pc-cygwin/include -isystem /usr/local/gnu/i686-pc-cygwin/sys-include -c -g -O2 -gtoggle -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -Iyes/include -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -DCLOOG_PPL_BACKEND \ ../../gcc/gcc/config/i386/i386.c -o i386.o cc1: warnings being treated as errors ../../gcc/gcc/config/i386/i386.c: In function 'avx_vpermilp_parallel': ../../gcc/gcc/config/i386/i386.c:24542:24: error: comparison between signed and unsigned integer expressions make[3]: *** [i386.o] Error 1 make[3]: Leaving directory `/usr/local/src/trunk/objdir/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/usr/local/src/trunk/objdir' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/usr/local/src/trunk/objdir' Windows XP Pro/SP3 cygwin Intel Core2 Duo t9...@2.80ghz system with packages: binutils 2.19.51-1 2.19.51.20090704 bison 2.3-1 2.3 cloog-ppl 0.15.3-1 cygwin 1.7.0-65 dejagnu 20021217-2 1.4.2.x expect 20030128-1 5.26 gcc4-ada 4.3.4-1 gcc4-core 4.3.4-1 gcc4-g++ 4.3.4-1 gmp 4.3.1-3 libcloog-devel 0.15.3-1 libgmp-devel 4.3.1-3 libmpc-devel 0.8-1 libmpfr-devel 2.4.1-4 libppl 0.10.2-1 make 3.81-2 mpclib 0.8-1 mpfr 2.4.1-4 ppl 0.10.2-1 ppl-devel 0.10.2-1 tcltk 20080420-1 8.4 w32api 3.14-1 LAST_UPDATED: Mon Nov 23 06:25:08 UTC 2009 (revision 154431) This is on sorry, this was alreadey reported by H.J. Lu over on gcc-patches: http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01215.html -- Cheers, /ChJ
Re: GCC 4.5 is uncompilable
Piotr Wyderski wrote: Dave Korn wrote: If that doesn't fix it please let me know. The solution was correct, with binutils 2.20 the problem disappeared. There is another one, however on the snapshot 20091119: ../../gcc/lto-streamer-out.c: In function 'write_global_references': ../../gcc/lto-streamer-out.c:2201:7: error: passing argument 3 of 'lto_streamer_ cache_lookup' from incompatible pointer type ../../gcc/lto-streamer.h:790:13: note: expected 'int *' but argument is of type 'int32_t *' which is a source code bug: a local variable ref of type int32_t is passed by pointer to a function which takes int*. Don't know about trunk, as I just started building it. One of the problems with snapshots; sometimes they capture the state of trunk while it has a bug extant. I have successfully compiled HEAD at r.154370 and r.154010 recently. cheers, DaveK
RE: Worth balancing the tree before scheduling?
David Edelsohn wrote: On Fri, Nov 20, 2009 at 10:05 AM, Ian Bolton bol...@icerasemi.com wrote: From some simple experiments (see below), it appears as though GCC aims to create a lop-sided tree when there are constants involved (func1 below), but a balanced tree when there aren't (func2 below). Our assumption is that GCC likes having constants all near to each other to aid with tree-based optimisations, but I'm fairly sure that, when it comes to scheduling, it would be better to have a balanced tree, so sched has more choices about what to schedule next? I think this would depend on the target architecture and instruction set: CISC vs RISC, many registers vs few registers, etc. I do not believe that GCC intentionally is trying to optimize for either, but I do not think there is a single, right answer. Regardless of the architecture, I can't see how an unbalanced tree would ever be a good thing. With a balanced tree, you can still choose to process it in either direction (broad versus deep) - whichever is better for your architecture - but, as far as I can see (bearing in mind that I'm very new to GCC development!), a tall lop-sided tree gives few scheduling options due to all the extra dependencies. I guess I must be missing something? Regards, Ian
Re: i370 port - 3.4.6 to 4.4 upgrade attempt
On 11/23/2009 11:32 AM, Paul Edwards wrote: So, given the scope below, can someone please explain what 4.4 changes are affecting me and what I need to do to overcome them? I think your best bet is to grep the changelogs for what has changes, and see what was done for other ports. Many target macros have become target hooks. Or, PREDICATE_CODES for example will require you to rewrite the r_or_s_operand and s_operand as define_predicate RTL; grep the ChangeLog for predicates.md. And so on. Paolo
Re: Worth balancing the tree before scheduling?
On Nov 23, 2009, at 10:17, Ian Bolton wrote: Regardless of the architecture, I can't see how an unbalanced tree would ever be a good thing. With a balanced tree, you can still choose to process it in either direction (broad versus deep) - whichever is better for your architecture - but, as far as I can see (bearing in mind that I'm very new to GCC development!), a tall lop-sided tree gives few scheduling options due to all the extra dependencies. I guess I must be missing something? Yes, a lop-sided tree often needs less registers. For example, (((a+b)+c)+d)+e would only need 2 registers. Any more balanced tree would need at least one more. -Geert
internal compiler error: in simplify_subreg, at simplify-rtx.c:5138
Hi, I'm using the latest gcc 4.5 to compile the latest linux kernel(rc8). $ mips64el-unknown-linux-gnu-gcc --version mips64el-unknown-linux-gnu-gcc (GCC) 4.5.0 20091123 (experimental) and encountered this error: $ make ARCH=mips CROSS_COMPILE=mips64el-unknown-linux-gnu- mm/rmap.o CHK include/linux/version.h CHK include/linux/utsrelease.h SYMLINK include/asm - include/asm-mips Checking missing-syscalls for N32 CALLscripts/checksyscalls.sh Checking missing-syscalls for O32 CALLscripts/checksyscalls.sh CALLscripts/checksyscalls.sh CC mm/rmap.o mm/rmap.c: In function 'try_to_unmap_one': mm/rmap.c:860:1: internal compiler error: in simplify_subreg, at simplify-rtx.c:5138 Please submit a full bug report, I have tried to find the exact place which introduced this error and at last found out this line of that file: 818 swp_entry_t entry = { .val = page_private(page) }; If I change that line to: swp_entry_t entry = { .val = 1 }; the error will go away. and I found that page_privete(page) is something like this: include/linux/mm.h: 228 #define page_private(page) ((page)-private) So, I moved that (page)-private to the above directly, and try it with: swp_entry_t entry = { .val = ((page)-private) }; and swp_entry_t entry = { .val = (page)-private }; and swp_entry_t entry = { .val = page-private }; and even tried with: swp_entry_t entry; entry.val = page-private; All of them failed, at last, I found the line of gcc: 5130 /* Simplify SUBREG:OUTERMODE(OP:INNERMODE, BYTE) 5131Return 0 if no simplifications are possible. */ 5132 rtx 5133 simplify_subreg (enum machine_mode outermode, rtx op, 5134 enum machine_mode innermode, unsigned int byte) 5135 { 5136 /* Little bit of sanity checking. */ 5137 gcc_assert (innermode != VOIDmode); 5138 gcc_assert (outermode != VOIDmode); -- This line. 5139 gcc_assert (innermode != BLKmode); 5140 gcc_assert (outermode != BLKmode); any more information needed for the above problem? Best Regards, Wu Zhangjin
Re: Possible endless loop in lto-wrapper
2009/11/22 Leandro Nini drfiem...@email.it: Hi, in gcc-4.5 lto-wrapper may end up in an endless loop in case of error: if for example a 'maybe_unlink_file' call from 'lto_wrapper_exit' fails it calls 'fatal_perror' which in turn calls 'lto_wrapper_exit' again causing an infinity of lto-wrapper: deleting LTRANS file /tmp/ccWjXUv8.lto.o: No such file or directory error messages on the console. I've solved this by substituting 'maybe_unlink_file' with 'unlink_if_ordinary' whithin the 'lto_wrapper_exit' function. Not sure if this is the best fix but hope it helps. Thanks for finding the bug! I think that we need something similar to what was done in the linker: Avoid trying to start a new cleanup if we are already in one. Leandro, can you try the attached patch? Diego, OK if it works? 2009-11-23 Rafael Avila de Espindola espind...@google.com * lto-wrapper.c (lto_wrapper_exit): Don't try to delete files if being called recursively. Best Regards, Leandro -- Cheers, -- Rafael Ávila de Espíndola Index: gcc/lto-wrapper.c === --- gcc/lto-wrapper.c (revision 154452) +++ gcc/lto-wrapper.c (working copy) @@ -66,12 +66,20 @@ static void lto_wrapper_exit (int status) { - if (ltrans_output_file) -maybe_unlink_file (ltrans_output_file); - if (flto_out) -maybe_unlink_file (flto_out); - if (args_name) -maybe_unlink_file (args_name); + static bool cleanup_done = false; + if (!cleanup_done) +{ + /* Setting cleanup_done prevents an infinite loop if one of the + calls to maybe_unlink_file fails. */ + cleanup_done = true; + + if (ltrans_output_file) +maybe_unlink_file (ltrans_output_file); + if (flto_out) +maybe_unlink_file (flto_out); + if (args_name) +maybe_unlink_file (args_name); +} exit (status); }
Re: Possible endless loop in lto-wrapper
On Mon, Nov 23, 2009 at 13:59, Rafael Espindola espind...@google.com wrote: 2009-11-23 Rafael Avila de Espindola espind...@google.com * lto-wrapper.c (lto_wrapper_exit): Don't try to delete files if being called recursively. OK. Diego.
No .got section in ELF
The idea I got is about removing .got section in ELF format totally. Before we go, let's see the limitation on the idea 1) It must be deployed on aligned segment model, such as Linux, which cs.start = ds.start. 2) Currently, I only know how to do on x86 ELF. Here is a typical sample in PIC model (shared library) when library want to access its global data ... // Later code snippet template is used by gcc in almost all shared function // to imitate `mov %ip, %ebx'. call next: next: pop %ebx // A. ... movl new_offset(%ebx), %eax // B. load global variable foo to eax. ... .global foo // C. OK!, to ld, offsetof(C - A) is const, and to gcc offsetof(B - A) is also const, so to aligned segment model, new_offset = offset(C - A) - offset(B - A), right? Here is the new workflow 1) Using new option, such as, new option `--segment-model=aligned' to trigger the feature. 2) Gcc creates a section (nogot) which stores data pair offsetof(B - A) and new_offset address for every function. 3) Ld reads nogot section and update new_offset according to above formular. 4) nogot section is discarded later. Constrast to traditional PIC code, we save an indirect memory load instruction and shrink memory fee by avoiding to load .got section into memory. And it seems it's fit with gcc4.5 link-time optimizer feature.
On strategies for function call instrumentation
Hi, I'm Derrick Coetzee and I'm a grad student working with Daniel Wilkerson et al on the Hard Object project at UC Berkeley (see http://www.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-97.html). To minimize implementation effort, we'd like to use gcc as the compiler for our platform. The main trick is, to implement our custom stack management, we need to inject a custom instruction before each function call begins pushing its arguments, and insert a different instruction right after each function call. We considered a couple different ways to do this: 1. We have a C/C++ source-to-source translation framework. We could translate each function call f(a,b,c) to something like ({ _asm { ... }; typeof(f(a,b,c)) result = f(a,b,c); _asm { ... }; result; }) 2. We could modify the code generation of gcc in a private fork. Our main concern is that we need to be sure the instructions will be executed at the right time, right before it starts pushing arguments for the function and right after it returns, even in complex contexts like nested function calls (f(g(a,b),c)). We're not sure how much gcc will reorder these type of sequences, or what optimizations we might be neglecting to consider. We're also not sure if we might be overlooking superior approaches to the problem. Any advice is appreciated. -- Derrick Coetzee University of California, Berkeley
[Bug ada/42150] GNAT (really) appears to misbehave with limited types/finalization/extended return
--- Comment #3 from gcc at coreland dot ath dot cx 2009-11-23 08:15 --- Using built-in specs. Target: x86_64-portbld-freebsd7.2 Configured with: ./..//gcc-4.4.0/configure --enable-languages=c,ada --disable-nls --with-system-zlib --with-libiconv-prefix=/usr/local --program-suffix=44 --bindir=/usr/local/bin/gcc44 --libdir=/usr/local/lib/gcc-4.4.0 --prefix=/usr/local --mandir=/usr/local/man --infodir=/usr/local/info/gcc44 --build=x86_64-portbld-freebsd7.2 Thread model: posix gcc version 4.4.0 (GCC) FreeBSD viper.internal.network 7.2-RELEASE-p4 FreeBSD 7.2-RELEASE-p4 #0: Fri Oct 2 08:22:32 UTC 2009 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42150
[Bug ada/42150] GNAT (really) appears to misbehave with limited types/finalization/extended return
--- Comment #4 from gcc at coreland dot ath dot cx 2009-11-23 08:16 --- Using built-in specs. COLLECT_GCC=/gnat/svn/builds/r154285/bin/gcc-r154285 COLLECT_LTO_WRAPPER=/gnat/svn/builds/r154285/libexec/gcc/x86_64-unknown-freebsd7.2/4.5.0/lto-wrapper Target: x86_64-unknown-freebsd7.2 Configured with: /gnat/svn/src/configure --enable-languages=c,c++,ada,fortran --prefix=/gnat/svn/builds/r154285 --with-system-zlib --disable-nls --program-suffix=-r154285 --enable-libstdcxx-debug Thread model: posix gcc version 4.5.0 20091118 (experimental) (GCC) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42150
[Bug ada/42150] GNAT (really) appears to misbehave with limited types/finalization/extended return
--- Comment #5 from charlet at gcc dot gnu dot org 2009-11-23 08:21 --- Sorry, but we still need a self contained set of sources attached in bugzilla (with only the needed sources to reproduce the bug), and a single, stand alone gcc command line with no extra shell scripts. See http://gcc.gnu.org/bugs/ for more details. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42150
[Bug fortran/42053] [OOP] SELECT TYPE: reject duplicate CLASS IS blocks
--- Comment #2 from janus at gcc dot gnu dot org 2009-11-23 08:47 --- Subject: Bug 42053 Author: janus Date: Mon Nov 23 08:47:14 2009 New Revision: 154432 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154432 Log: 2009-11-23 Janus Weil ja...@gcc.gnu.org PR fortran/42053 * resolve.c (resolve_select_type): Check for duplicate CLASS IS blocks. 2009-11-23 Janus Weil ja...@gcc.gnu.org PR fortran/42053 * gfortran.dg/select_type_9.f03: New. Added: branches/fortran-dev/gcc/testsuite/gfortran.dg/select_type_9.f03 Modified: branches/fortran-dev/gcc/fortran/ChangeLog.fortran-dev branches/fortran-dev/gcc/fortran/resolve.c branches/fortran-dev/gcc/testsuite/ChangeLog.fortran-dev -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42053
[Bug fortran/42053] [OOP] SELECT TYPE: reject duplicate CLASS IS blocks
--- Comment #3 from janus at gcc dot gnu dot org 2009-11-23 08:49 --- Fixed with r154432. Closing. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42053
[Bug target/40835] redundant comparison instruction
--- Comment #9 from carrot at google dot com 2009-11-23 08:51 --- Fixed by Richard. Close it. -- carrot at google dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40835
[Bug tree-optimization/42108] [4.4/4.5 Regression] Vectorizer cannot deal with PAREN_EXPR gracefully, 50% performance regression
--- Comment #18 from irar at il dot ibm dot com 2009-11-23 09:02 --- I tried to vectorize eval.f90 with 4.3 and mainline on x86_64-suse-linux. In both cases no loop gets vectorized in subroutine eval. The k loop is not vectorizable because the step of x is unknown (function argument), and scalar evolution analysis fails to analyze it. The j loop is not vectorized first of all because of the k loop unknown loop bound (this is on our todo list). Ira -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
[Bug ada/42153] s-osinte.adb:46:21: missing body for To_Duration declared at s-osinte.ads:216
--- Comment #2 from laurent at guerby dot net 2009-11-23 09:06 --- hpux11 mixes its own s-osinte spec with the posix body hence the issue: ifeq ($(strip $(filter-out hppa% hp hpux11%,$(targ))),) s-osinte.adbs-osinte-posix.adb \ s-osinte.adss-osinte-hpux.ads \ I missed this one sorry about that, patch coming. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42153
[Bug ada/42153] s-osinte.adb:46:21: missing body for To_Duration declared at s-osinte.ads:216
--- Comment #3 from laurent at guerby dot net 2009-11-23 09:06 --- Created an attachment (id=19089) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19089action=view) Patch for hpux11 Dave, could try this patch? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42153
[Bug ada/42150] GNAT (really) appears to misbehave with limited types/finalization/extended return
--- Comment #6 from gcc at coreland dot ath dot cx 2009-11-23 10:16 --- Created an attachment (id=19090) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19090action=view) source file that generates the error -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42150
[Bug ada/42150] GNAT (really) appears to misbehave with limited types/finalization/extended return
--- Comment #7 from gcc at coreland dot ath dot cx 2009-11-23 10:17 --- Created an attachment (id=19091) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19091action=view) dependency for arc_dir_003.adb -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42150
[Bug ada/42150] GNAT (really) appears to misbehave with limited types/finalization/extended return
--- Comment #8 from gcc at coreland dot ath dot cx 2009-11-23 10:17 --- Created an attachment (id=19092) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19092action=view) dependency for arc_dir_003.adb -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42150
[Bug ada/42150] GNAT (really) appears to misbehave with limited types/finalization/extended return
--- Comment #9 from gcc at coreland dot ath dot cx 2009-11-23 10:17 --- Created an attachment (id=19093) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19093action=view) dependency for arc_dir_003.adb -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42150
[Bug ada/42150] GNAT (really) appears to misbehave with limited types/finalization/extended return
--- Comment #10 from gcc at coreland dot ath dot cx 2009-11-23 10:17 --- Created an attachment (id=19094) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19094action=view) dependency for arc_dir_003.adb -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42150
[Bug ada/42150] GNAT (really) appears to misbehave with limited types/finalization/extended return
--- Comment #11 from gcc at coreland dot ath dot cx 2009-11-23 10:18 --- Created an attachment (id=19095) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19095action=view) dependency for arc_dir_003.adb -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42150
[Bug ada/42150] GNAT (really) appears to misbehave with limited types/finalization/extended return
--- Comment #12 from gcc at coreland dot ath dot cx 2009-11-23 10:18 --- Created an attachment (id=19096) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19096action=view) dependency for arc_dir_003.adb -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42150
[Bug ada/42150] GNAT (really) appears to misbehave with limited types/finalization/extended return
--- Comment #13 from gcc at coreland dot ath dot cx 2009-11-23 10:18 --- Created an attachment (id=19097) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19097action=view) dependency for arc_dir_003.adb -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42150
[Bug ada/42150] GNAT (really) appears to misbehave with limited types/finalization/extended return
--- Comment #14 from gcc at coreland dot ath dot cx 2009-11-23 10:19 --- Created an attachment (id=19098) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19098action=view) dependency for arc_dir_003.adb -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42150
[Bug ada/42150] GNAT (really) appears to misbehave with limited types/finalization/extended return
--- Comment #15 from gcc at coreland dot ath dot cx 2009-11-23 10:19 --- Created an attachment (id=19099) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19099action=view) dependency for arc_dir_003.adb -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42150
[Bug ada/42150] GNAT (really) appears to misbehave with limited types/finalization/extended return
--- Comment #16 from gcc at coreland dot ath dot cx 2009-11-23 10:19 --- Created an attachment (id=19100) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19100action=view) dependency for arc_dir_003.adb -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42150
[Bug ada/42150] GNAT (really) appears to misbehave with limited types/finalization/extended return
--- Comment #17 from gcc at coreland dot ath dot cx 2009-11-23 10:19 --- Created an attachment (id=19101) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19101action=view) dependency for arc_dir_003.adb -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42150
[Bug ada/42150] GNAT (really) appears to misbehave with limited types/finalization/extended return
--- Comment #18 from gcc at coreland dot ath dot cx 2009-11-23 10:20 --- Created an attachment (id=19102) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19102action=view) dependency for arc_dir_003.adb -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42150
[Bug ada/42150] GNAT (really) appears to misbehave with limited types/finalization/extended return
--- Comment #19 from gcc at coreland dot ath dot cx 2009-11-23 10:22 --- Really fail to see how this is more convenient or useful for anyone involved but oh well, what do I know? gcc-4.4.0: gcc -c pfseudo.ads pfseudo-path.adb pfseudo-archiver.ads pfseudo-archiver-directory.adb test.adb arc_dir_003.adb pfseudo-archiver-directory.adb:24:41: wrong type for return_subtype_indication pfseudo-archiver-directory.adb:46:35: wrong type for return_subtype_indication arc_dir_003.adb:25:32: _master conflicts with declaration at line 21 gcc-r154285: gcc-r154285 -c pfseudo.ads pfseudo-path.adb pfseudo-archiver.ads pfseudo-archiver-directory.adb test.adb arc_dir_003.adb arc_dir_003.adb:25:32: _master conflicts with declaration at line 21 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42150
[Bug tree-optimization/42154] New: [4.5 Regression] Wrong code from (early) SRA
struct A { char x[1]; }; extern void abort (void); void __attribute__((noinline,noclone)) foo (struct A a) { if (a.x[0] != 'a') abort (); } int main () { struct A a; int i; for (i = 0; i 1; ++i) a.x[i] = 'a'; foo (a); return 0; } fails at -O1 because (early) SRA converts bb 2: i_2 = 0; goto bb 4; bb 3: a.x[i_1] = 97; i_3 = i_1 + 1; bb 4: # i_1 = PHI 0(2), i_3(3) if (i_1 = 0) goto bb 3; else goto bb 5; bb 5: foo (a); to bb 2: i_2 = 0; goto bb 4; bb 3: a$x$_9 = 97; i_3 = i_1 + 1; bb 4: # i_1 = PHI 0(2), i_3(3) # a$x$_7 = PHI a$x$_4(D)(2), a$x$_9(3) if (i_1 = 0) goto bb 3; else goto bb 5; bb 5: a.x[i_1] = a$x$_7; foo (a); see how the store to a.x[i_1] is wrong as i_1 does no longer have the same value as before (SRA invalidly moved it out of the loop). SRA should have replaced i_1 with zero as it reasoned there is only one element and only because of that it SRAd this. -- Summary: [4.5 Regression] Wrong code from (early) SRA Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42154
[Bug tree-optimization/42154] [4.5 Regression] Wrong code from (early) SRA
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42154
[Bug ada/42150] GNAT (really) appears to misbehave with limited types/finalization/extended return
--- Comment #20 from ebotcazou at gcc dot gnu dot org 2009-11-23 11:02 --- Really fail to see how this is more convenient or useful for anyone involved but oh well, what do I know? Attaching a lot of files is indeed inconvenient, that's why http://gcc.gnu.org/bugs section Detailed bug reporting instructions for GNAT instructs you to submit a single file for gnatchop. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42150
[Bug ada/42150] GNAT (really) appears to misbehave with limited types/finalization/extended return
--- Comment #21 from gcc at coreland dot ath dot cx 2009-11-23 11:12 --- Created an attachment (id=19103) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19103action=view) version suitable for gnatchop -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42150
[Bug ada/42150] GNAT (really) appears to misbehave with limited types/finalization/extended return
--- Comment #22 from gcc at coreland dot ath dot cx 2009-11-23 11:13 --- Any way I can remove the above attachments? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42150
[Bug fortran/42144] [OOP] deferred TBPs do not work
--- Comment #1 from janus at gcc dot gnu dot org 2009-11-23 11:41 --- Another example (with generics): module foo_module implicit none private public :: foo,rescale type ,abstract :: foo contains procedure(times_interface) ,deferred :: times procedure(assign_interface) ,deferred :: assign generic :: operator(*) = times generic :: assignment(=) = assign end type abstract interface function times_interface(this,factor) result(product) import :: foo class(foo) ,intent(in) :: this class(foo) ,allocatable :: product real, intent(in) :: factor end function subroutine assign_interface(lhs,rhs) import :: foo class(foo) ,intent(inout) :: lhs class(foo) ,intent(in) :: rhs end subroutine end interface contains subroutine rescale(this,scale) class(foo) ,intent(inout) :: this real, intent(in) :: scale this = this*scale end subroutine end module module bar_module use foo_module ,only : foo implicit none private public :: bar type ,extends(foo) :: bar private real :: x=1. contains procedure :: times = times_bar procedure :: assign = assign_bar end type contains subroutine assign_bar(lhs,rhs) class(bar) ,intent(inout) :: lhs class(foo) ,intent(in) :: rhs select type(rhs) type is (bar) lhs%x = rhs%x end select end subroutine function times_bar(this,factor) result(product) class(bar) ,intent(in) :: this real, intent(in) :: factor class(foo), allocatable :: product select type(this) type is (bar) allocate(product,source=this) select type(product) type is(bar) product%x = this%x*factor end select end select end function end module program main use foo_module ,only : foo,rescale use bar_module ,only : bar implicit none type(bar) :: unit call rescale(unit,3.141592654) end program -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42144
[Bug fortran/42008] Wrongly rejected derived types with default initializers in PURE procedures
--- Comment #4 from burnus at gcc dot gnu dot org 2009-11-23 12:38 --- Does your patch still reject pure function test() integer, pointer :: p = null() ! INVALID per C1272 integer :: test test = p end function test That is currently rejected as Error: Initialization of pointer at (1) is not allowed in a PURE procedure. NAG f95 rejects it with: ERROR: Local variable P of PURE procedure TEST has the SAVE attribute as p gets implicitly declared as SAVE. There might well be a check for it in gfortran already, but seemingly no test case. If there is no such test case, could you also add it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42008
[Bug tree-optimization/42142] GCC 4.5 doesn't compile a certain quicksort implementation correctly when optimizing with -O1 or higher
--- Comment #5 from paolo dot carlini at oracle dot com 2009-11-23 12:40 --- Richard, can you have a look to this one? First blush, I don't see anything wrong with the code... -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42142
[Bug middle-end/42130] [graphite-branch] dealII fails
--- Comment #3 from grosser at gcc dot gnu dot org 2009-11-23 13:02 --- Subject: Bug 42130 Author: grosser Date: Mon Nov 23 13:02:08 2009 New Revision: 154440 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154440 Log: Protect loops that might be executed zero times. 2009-11-23 Tobias Grosser gros...@fim.uni-passau.de PR middle-end/42130 * graphite-clast-to-gimple.c (graphite_create_new_loop_guard, translate_clast_for_loop): New. (translate_clast_for): Add a condition around the loop, to do not execute loops with zero iterations. * testsuite/g++.dg/graphite/pr42130.C: New. * testsuite/gcc.dg/graphite/pr35356-2.c: Adapt. Added: branches/graphite/gcc/testsuite/g++.dg/graphite/pr42130.C Modified: branches/graphite/gcc/ChangeLog.graphite branches/graphite/gcc/graphite-clast-to-gimple.c branches/graphite/gcc/testsuite/gcc.dg/graphite/pr35356-2.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42130
[Bug tree-optimization/42142] GCC 4.5 doesn't compile a certain quicksort implementation correctly when optimizing with -O1 or higher
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-11-23 13:10 --- ==29953== Conditional jump or move depends on uninitialised value(s) ==29953==at 0x400671: sort (qsort.c:16) ==29953==by 0x40079F: main (qsort.c:45) qsort.c.034t.cddce1 deletes the store to end[i+1]. I will investigate further. Partially reduced testcase: extern void abort (void); void __attribute__((noinline,noclone)) sort(int *arr, int elements) { int piv, beg[10] = {}, end[10] = {}, i=0, L, R ; beg[0]=0; end[0]=elements; while (i=0) { L=beg[i]; R=end[i]-1; if (LR) { piv=arr[L]; if (i==9) abort (); while (LR) { while (arr[R]=piv LR) R--; if (LR) arr[L++]=arr[R]; while (arr[L]=piv LR) L++; if (LR) arr[R--]=arr[L]; } arr[L]=piv; beg[i+1]=L+1; end[i+1]=end[i]; end[i++]=L; } { i--; } } } int main(int argc, char *argv[]) { int table[10]; int count; for (count = 0; count 10; count++) table[count] = 10 - count; sort(table, 10); for ( count = 0; count 9; count++ ) if ( table[count] table[count+1] ) abort (); return 0; } -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-11-23 13:10:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42142
[Bug tree-optimization/42142] [4.5 Regression] DCE miscompiles a certain quicksort implementation correctly when optimizing with -O1 or higher
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||wrong-code Summary|GCC 4.5 doesn't compile a |[4.5 Regression] DCE |certain quicksort |miscompiles a certain |implementation correctly|quicksort implementation |when optimizing with -O1 or |correctly when optimizing |higher |with -O1 or higher Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42142
[Bug tree-optimization/42142] [4.5 Regression] DCE miscompiles a certain quicksort implementation when optimizing with -O1 or higher
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-11-23 13:29 --- int __attribute__((noinline,noclone)) sort(int L) { int end[2] = { 10, 10, }, i=0, R; while (i2) { R = end[i]; if (LR) { end[i+1] = 1; end[i] = 10; ++i; } else break; } return i; } extern void abort (void); int main() { if (sort (5) != 1) abort (); return 0; } -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42142
[Bug c++/14777] [4.3/4.4/4.5 Regression] typedef doesn't fully expose base class type
--- Comment #18 from dodji at gcc dot gnu dot org 2009-11-23 13:30 --- Subject: Bug 14777 Author: dodji Date: Mon Nov 23 13:29:50 2009 New Revision: 154443 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154443 Log: Fix PR c++/14777 gcc/cp/ChangeLog: PR c++/14777 * cp-tree.def TEMPLATE_INFO: Declare new kind of tree node. * cp-tree.h (struct tree_template_info, struct qualified_typedef_usage_s): New. (cp_tree_node_structure_enum): add TS_CP_TEMPLATE_INFO. (union lang_tree_node): Add template_info. (TI_TEMPLATE, TI_ARGS, TI_TYPEDEFS_NEEDING_ACCESS_CHECKING): Adjust. (build_template_info): Declare. (get_types_needing_access_check): Adjust return type. (add_typedef_to_current_template_for_access_check): Declare. * cp-objcp-common.c (cp_tree_size): Handle TEMPLATE_INFO. * semantics.c (add_typedef_to_current_template_for_access_check): Split from ... (check_accessibility_of_qualified_id): ... here. * decl.c (make_typename_type): Use it. * pt.c (build_template_info): Define. (check_explicit_specialization, find_parameter_packs_r, push_template_decl_real, lookup_template_class, for_each_template_parm_r, tsubst_decl, tsubst): Use build_template_info. (get_types_needing_access_check): Adjust return type. (append_type_to_template_for_access_check_1): Record the location of the usage point of the typedef. Adjust to TEMPLATE_INFO. (append_type_to_template_for_access_check): Add new location parameter. Pass it to append_type_to_template_for_access_check_1. Adjust to TEMPLATE_INFO. (perform_typedefs_access_check): Temporarily set input_location to the usage point of the typedef we are checking access for. Adjust to new TEMPLATE_INFO tree node. * tree.c (bind_template_template_parm): Use build_template_info. * call.c (add_template_candidate_real): Likewise. * decl.c (grokfndecl): Likewise. (cp_tree_node_structure): Handle TEMPLATE_INFO. gcc/testsuite/ChangeLog: PR c++/14777 * g++.dg/template/typedef13.C: Adjust. * g++.dg/template/typedef19.C: Adjust. * g++.dg/template/typedef20.C: Adjust. * g++.dg/template/typedef22.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/typedef22.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/cp-objcp-common.c trunk/gcc/cp/cp-tree.def trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl.c trunk/gcc/cp/pt.c trunk/gcc/cp/semantics.c trunk/gcc/cp/tree.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/template/typedef13.C trunk/gcc/testsuite/g++.dg/template/typedef19.C trunk/gcc/testsuite/g++.dg/template/typedef20.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14777
[Bug fortran/42008] Wrongly rejected derived types with default initializers in PURE procedures
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2009-11-23 13:44 --- Without the patch it is rejected, with the patch it is not. I will look into this further. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42008
[Bug c++/14777] [4.3/4.4/ Regression] typedef doesn't fully expose base class type
--- Comment #19 from dodji at gcc dot gnu dot org 2009-11-23 13:44 --- This should be fixed in 4.5. Adjusting the Regression tag. Not planning to fix in 4.3/44. -- dodji at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.3/4.4/4.5 Regression]|[4.3/4.4/ Regression] |typedef doesn't fully expose|typedef doesn't fully expose |base class type |base class type http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14777
[Bug c++/14777] [4.3/4.4/ Regression] typedef doesn't fully expose base class type
-- dodji at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|dodji at gcc dot gnu dot org|unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14777
[Bug tree-optimization/42154] [4.5 Regression] Wrong code from (early) SRA
--- Comment #1 from jamborm at gcc dot gnu dot org 2009-11-23 14:01 --- I'm looking into this. This example shows why using access-expr to create new expressions is a dangerous thing to do, at least in some contexts (which I did not really realize until now). I'd better look at them all. -- jamborm at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jamborm at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-11-23 14:01:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42154
[Bug c++/42121] g++ should warn or error on internal 0 size array in struct
--- Comment #6 from david dot resnick at comverse dot com 2009-11-23 14:15 --- (In reply to comment #5) Subject: Re: g++ should warn or error on internal 0 size array in struct On Fri, 20 Nov 2009, david dot resnick at comverse dot com wrote: (In reply to comment #3) (In reply to comment #2) In standard C, a size 0 array is forbidden, at least in C99 doc I have handy, Yes, but it's a long-standing GNU extension: http://gcc.gnu.org/onlinedocs/gcc-4.4.2/gcc/Zero-Length.html#Zero-Length The C++ front end says: /* As an extension we allow zero-sized arrays. We always allow them in system headers because glibc uses them. */ Maybe the C++ front-end could be made stricter, so that it accepts char b[0] (like the C front end) but not char b[] (which is a C99 flexible array member, and must be the last member) OK, but if you read that link the whole rationale is to do with it being the last field in a struct, not an internal member, right? Seems like there is no possible use in an internal member, and not diagnosing this as warnable means you don't notice if, say, someone accidentally adds something after the flexible array member. Which happened to us, which is why I noticed this issue. If this will break existing usage, I see the reason not to change. But I'm curious what possible use a non-terminal zero sized array in a struct might have. Several cases of C99 flexible array members that C99 does not permit are only diagnosed as pedwarns-if-pedantic for C because of glibc using them. (I gave an example in http://gcc.gnu.org/ml/gcc-patches/2002-08/msg01149.html.) I haven't looked into why it does this. (In reply to comment #5) Subject: Re: g++ should warn or error on internal 0 size array in struct On Fri, 20 Nov 2009, david dot resnick at comverse dot com wrote: (In reply to comment #3) (In reply to comment #2) In standard C, a size 0 array is forbidden, at least in C99 doc I have handy, Yes, but it's a long-standing GNU extension: http://gcc.gnu.org/onlinedocs/gcc-4.4.2/gcc/Zero-Length.html#Zero-Length The C++ front end says: /* As an extension we allow zero-sized arrays. We always allow them in system headers because glibc uses them. */ Maybe the C++ front-end could be made stricter, so that it accepts char b[0] (like the C front end) but not char b[] (which is a C99 flexible array member, and must be the last member) OK, but if you read that link the whole rationale is to do with it being the last field in a struct, not an internal member, right? Seems like there is no possible use in an internal member, and not diagnosing this as warnable means you don't notice if, say, someone accidentally adds something after the flexible array member. Which happened to us, which is why I noticed this issue. If this will break existing usage, I see the reason not to change. But I'm curious what possible use a non-terminal zero sized array in a struct might have. Several cases of C99 flexible array members that C99 does not permit are only diagnosed as pedwarns-if-pedantic for C because of glibc using them. (I gave an example in http://gcc.gnu.org/ml/gcc-patches/2002-08/msg01149.html.) I haven't looked into why it does this. OK, can't argue with not breaking existing headers I suppose. But this is to me clearly a bogus usage. What are the semantics of using internal zero sized arrays in a struct? They have the same offset as the following field and impose alignment restrictions on it. Do they have the same nominal requirements as unions for usage (can't write one, read the other?)? Or is the idea that if they are 0 sized and internal they are not to be used for any purpose whatsoever, and they are only not warnable because of existing usage in glibc headers? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42121
[Bug target/41473] [4.5 Regression] dsymutil Assertion failed ...
--- Comment #30 from howarth at nitro dot med dot uc dot edu 2009-11-23 14:22 --- Perhaps something like... Index: dwarf2out.c === --- dwarf2out.c (revision 154443) +++ dwarf2out.c (working copy) @@ -10447,8 +10447,11 @@ /* Output the block length for this list of location operations. */ dw2_asm_output_data (constant_size (size), size, %s, name); - - output_loc_sequence (AT_loc (a)); + + if (dwarf_strict (size == 0)) +break; + else + output_loc_sequence (AT_loc (a)); break; case dw_val_class_const: could fix this on darwin (untested) since we are the only target defaulting to dwarf_strict. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
[Bug target/41473] [4.5 Regression] dsymutil Assertion failed ...
--- Comment #31 from rguenther at suse dot de 2009-11-23 14:26 --- Subject: Re: [4.5 Regression] dsymutil Assertion failed ... On Mon, 23 Nov 2009, howarth at nitro dot med dot uc dot edu wrote: --- Comment #30 from howarth at nitro dot med dot uc dot edu 2009-11-23 14:22 --- Perhaps something like... Index: dwarf2out.c === --- dwarf2out.c (revision 154443) +++ dwarf2out.c (working copy) @@ -10447,8 +10447,11 @@ /* Output the block length for this list of location operations. */ dw2_asm_output_data (constant_size (size), size, %s, name); - - output_loc_sequence (AT_loc (a)); + + if (dwarf_strict (size == 0)) +break; + else + output_loc_sequence (AT_loc (a)); break; case dw_val_class_const: could fix this on darwin (untested) since we are the only target defaulting to dwarf_strict. Well, I don't think outputting zero-length location sequences makes sense at all. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
[Bug target/41151] Gas fails to consume the assembly Error: offset too big
--- Comment #4 from thiago at kde dot org 2009-11-23 14:32 --- My experience: gcc 4.4 + binutils 2.18.50.20070820 + no -march: ok gcc 4.4 + binutils 2.18.50.20070820 + -march=armv7-a: error gcc 4.4 + binutils 2.19.51.0.2.20090204: ok in both cases The instruction I had problems with was: movwr1, #:lower16:_ZL18qt_resource_struct My guess is that gcc started generating these instructions for newer ARM models, but binutils 2.18 couldn't consume them properly. But since it works with a newer binutils, my guess is that the problem is fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41151
[Bug target/41473] [4.5 Regression] dsymutil Assertion failed ...
--- Comment #32 from howarth at nitro dot med dot uc dot edu 2009-11-23 14:38 --- I got this response over on the gdb mailing list regarding the validity of emitting dwarf debug info containing an AT_location with any block form having a zero length... http://sourceware.org/ml/gdb/2009-11/msg00168.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
[Bug target/41473] [4.5 Regression] dsymutil Assertion failed ...
--- Comment #33 from howarth at nitro dot med dot uc dot edu 2009-11-23 14:41 --- I should reiterate the dsymutil's maintainers comments on this issue... The variable should be checked to make sure it really doesn't have a location, and if it doesn't just don't emit the DW_AT_location attribute. If it does have a valid location, then a lenght of zero is probably a bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
[Bug c++/42121] g++ should warn or error on internal 0 size array in struct
--- Comment #7 from redi at gcc dot gnu dot org 2009-11-23 14:53 --- (In reply to comment #6) OK, can't argue with not breaking existing headers I suppose. But this is to me clearly a bogus usage. What are the semantics of using internal zero sized arrays in a struct? They have the same offset as the following field and impose alignment restrictions on it. Do they have the same nominal requirements as unions for usage (can't write one, read the other?)? Or is the idea that if they are 0 sized and internal they are not to be used for any purpose whatsoever, and they are only not warnable because of existing usage in glibc headers? All good questions! It should be possible to make the C++ front end stricter about these so that outside of system headers they are an error, downgradeable to a warning with -fpermissive. I might try that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42121
[Bug target/41473] [4.5 Regression] dsymutil Assertion failed ...
--- Comment #34 from rguenth at gcc dot gnu dot org 2009-11-23 14:53 --- I suppose empty DW_AT_location lists may now denote places where the value dies and is no longer available. We now properly track this with VTA. Alex? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
[Bug ada/42153] s-osinte.adb:46:21: missing body for To_Duration declared at s-osinte.ads:216
--- Comment #4 from guerby at gcc dot gnu dot org 2009-11-23 14:57 --- Subject: Bug 42153 Author: guerby Date: Mon Nov 23 14:56:58 2009 New Revision: 154446 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154446 Log: 2009-11-23 Eric Botcazou ebotca...@adacore.com Laurent GUERBY laur...@guerby.net PR ada/42153 * s-osinte-linux.ads (struct_timeval): Delete. * s-osinte-hpux.ads (struct_timeval, To_Duration, To_Timeval): Delete. * s-osinte-kfreebsd-gnu.ads: Likewise. * s-osinte-rtems.ads: Likewise. * s-osinte-aix.ads: Likewise. * s-osinte-hpux-dce.ads: Likewise. * s-osinte-darwin.ads: Likewise. * s-osinte-solaris-posix.ads: Likewise. * s-osinte-irix.ads: Likewise. * s-osinte-solaris.ads: Likewise. * s-osinte-hpux-dce.adb (To_Duration, To_Timeval): Delete. * s-osinte-irix.adb: Likewise. * s-osinte-solaris.adb: Likewise. * s-osinte-rtems.adb: Likewise. Minor reformatting. * s-osinte-aix.adb (To_Duration, To_Timeval): Delete. (clock_gettime): Use cal.c timeval_to_duration. * s-osinte-darwin.adb: Likewise. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/s-osinte-aix.adb trunk/gcc/ada/s-osinte-aix.ads trunk/gcc/ada/s-osinte-darwin.adb trunk/gcc/ada/s-osinte-darwin.ads trunk/gcc/ada/s-osinte-hpux-dce.adb trunk/gcc/ada/s-osinte-hpux-dce.ads trunk/gcc/ada/s-osinte-hpux.ads trunk/gcc/ada/s-osinte-irix.adb trunk/gcc/ada/s-osinte-irix.ads trunk/gcc/ada/s-osinte-kfreebsd-gnu.ads trunk/gcc/ada/s-osinte-linux.ads trunk/gcc/ada/s-osinte-rtems.adb trunk/gcc/ada/s-osinte-rtems.ads trunk/gcc/ada/s-osinte-solaris-posix.ads trunk/gcc/ada/s-osinte-solaris.adb trunk/gcc/ada/s-osinte-solaris.ads -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42153
[Bug target/41473] [4.5 Regression] dsymutil Assertion failed ...
--- Comment #35 from howarth at nitro dot med dot uc dot edu 2009-11-23 15:03 --- If it is in fact valid dwarf, the question remains of what to do about the breakage that this causes with dsymutil on darwin. Inhibiting the emission of this in dwarf-strict might be a reasonable compromise since only darwin is defaulting that on. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
[Bug target/41473] [4.5 Regression] dsymutil Assertion failed ...
--- Comment #36 from rguenther at suse dot de 2009-11-23 15:07 --- Subject: Re: [4.5 Regression] dsymutil Assertion failed ... On Mon, 23 Nov 2009, howarth at nitro dot med dot uc dot edu wrote: --- Comment #35 from howarth at nitro dot med dot uc dot edu 2009-11-23 15:03 --- If it is in fact valid dwarf, the question remains of what to do about the breakage that this causes with dsymutil on darwin. Inhibiting the emission of this in dwarf-strict might be a reasonable compromise since only darwin is defaulting that on. If it's valid dwarf then it is also dwarf-strict. Please get apple fix its tools and issue a maintainance update. (I'm inclined to close this bug as invalid) Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
[Bug rtl-optimization/42155] New: Optimizer generates bad code for ARM7 THUMB mode (local variable lost)
Hello. I've found bug in GCC 4.4.1 for ARM7TDMI in THUMB mode. Test code: void foo(char *bar); char test() { char tmp; foo(tmp); return tmp; } Compiled with: arm-elf-gcc -S -mcpu=arm7tdmi -O2 -mthumb test.c Then using -O2 or -O3 optimization, assembler code looks like: 1:test: 2:push{r4, lr} 3:sub sp, sp, #4 4:mov r4, sp 5:add r4, r4, #3 6:mov r0, r4 7:bl foo 8:add sp, sp, #4 9:ldrbr0, [r4] 10: @ sp needed for prologue 11: pop {r4, pc} So, if interrupt or task switching occurs between line 8 and line 9, local variable in stack (referenced by r4) will be garbaged by service routine, because stack rewinds before usage of local variable. This code works fine with -O1: 1:test: 2:push{r4, lr} 3:sub sp, sp, #4 4:mov r4, sp 5:add r4, r4, #3 6:mov r0, r4 7:bl foo 8:ldrbr0, [r4] 9:add sp, sp, #4 10: @ sp needed for prologue 11: pop {r4, pc} -- Summary: Optimizer generates bad code for ARM7 THUMB mode (local variable lost) Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: critical Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: heavy at smtp dot ru GCC build triplet: arm-elf GCC host triplet: i486-linux-gnu GCC target triplet: arm-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42155
[Bug target/41473] [4.5 Regression] dsymutil Assertion failed ...
--- Comment #37 from howarth at nitro dot med dot uc dot edu 2009-11-23 15:26 --- (In reply to comment #36) If it's valid dwarf then it is also dwarf-strict. Please get apple fix its tools and issue a maintainance update. (I'm inclined to close this bug as invalid) Richard. Apple will be fixing this for Xcode 3.2.x, but realistically it extremely unlikely that the fix will be backported to Xcode 3.1.x or early so you are basically cutting off all releases earlier than Snow Leopard from generating complete debug code in gcc trunk. Currently we can't generate dSYM's for... libgcj.dylib libgcjgc.1.dylib libgfortran.3.dylib libgomp.1.dylib libobjc-gnu.2.dylib libssp.0.dylib libstdc++.6.dylib because of this issue. Our only other choice left will be to carry around non-standard patches to avoid this problem in distributed FSF gcc binaries for darwin. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
[Bug target/41473] [4.5 Regression] dsymutil Assertion failed ...
--- Comment #38 from rguenther at suse dot de 2009-11-23 15:28 --- Subject: Re: [4.5 Regression] dsymutil Assertion failed ... On Mon, 23 Nov 2009, howarth at nitro dot med dot uc dot edu wrote: --- Comment #37 from howarth at nitro dot med dot uc dot edu 2009-11-23 15:26 --- (In reply to comment #36) If it's valid dwarf then it is also dwarf-strict. Please get apple fix its tools and issue a maintainance update. (I'm inclined to close this bug as invalid) Richard. Apple will be fixing this for Xcode 3.2.x, but realistically it extremely unlikely that the fix will be backported to Xcode 3.1.x or early so you are basically cutting off all releases earlier than Snow Leopard from generating complete debug code in gcc trunk. Currently we can't generate dSYM's for... libgcj.dylib libgcjgc.1.dylib libgfortran.3.dylib libgomp.1.dylib libobjc-gnu.2.dylib libssp.0.dylib libstdc++.6.dylib because of this issue. Our only other choice left will be to carry around non-standard patches to avoid this problem in distributed FSF gcc binaries for darwin. As this only affects GCC 4.5 it is not unreasonable to require an up-to-date Xcode. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
[Bug c++/14777] [4.3/4.4/ Regression] typedef doesn't fully expose base class type
--- Comment #20 from jason at gcc dot gnu dot org 2009-11-23 15:40 --- If you don't think it's worth fixing on the older branches, the right thing to do is set the Target Milestone to the release where it will be fixed, and then close the bug as fixed. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.3.5 |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14777
[Bug target/41473] [4.5 Regression] dsymutil Assertion failed ...
--- Comment #39 from howarth at nitro dot med dot uc dot edu 2009-11-23 15:43 --- Normally this wouldn't be a big deal, but powerpc support stops at Leopard so we are effectively cutting off powerpc-apple-darwin* from every properly generating dSYMs in gcc 4.5. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
[Bug target/40959] build fails - No rule to make target `/usr/ports/lang/gcc43/work/build/ia64-portbld-freebsd8.0/libgcc/crtfastmath.o', needed by `T_TARGET'. Stop.
--- Comment #13 from sje at cup dot hp dot com 2009-11-23 15:43 --- I think you will need to create a fde-freebsd.c file in gcc/config/ia64 to define Unwind_FindTableEntry. See fde-glibc.c and fde-vms.c for examples. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40959
[Bug target/41473] [4.5 Regression] dsymutil Assertion failed ...
--- Comment #40 from jakub at gcc dot gnu dot org 2009-11-23 15:49 --- Given: 2.6.1.1.4 Empty Location Descriptions An empty location description consists of a DWARF expression containing no operations. It represents a piece or all of an object that is present in the source but not in the object code (perhaps due to optimization). I believe this is valid DWARF, and IMNSHO it is Apple's responsibility to issue a bug fix update, GCC shouldn't be working around Apple's bugs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
[Bug middle-end/42095] [4.5 Regression] g++.dg/lto/20081118-1 cp_lto_20081118-1_0.o-cp_lto_20081118-1_1.o link
--- Comment #3 from jakub at gcc dot gnu dot org 2009-11-23 16:10 --- Subject: Bug 42095 Author: jakub Date: Mon Nov 23 16:10:19 2009 New Revision: 154449 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154449 Log: PR middle-end/42095 * tree.c: Include cgraph.h. (cp_fix_function_decl_p): Don't return true for same_body aliases. * Make-lang.in (cp/tree.o): Depend on $(CGRAPH_H). Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/Make-lang.in trunk/gcc/cp/tree.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42095
[Bug target/40959] build fails - No rule to make target `/usr/ports/lang/gcc43/work/build/ia64-portbld-freebsd8.0/libgcc/crtfastmath.o', needed by `T_TARGET'. Stop.
--- Comment #14 from mexas at bristol dot ac dot uk 2009-11-23 16:12 --- can I add a FBSD ia64 developer email to the CC list (xcl...@mac.com)? I tried to do this before, but was refused. I'm just reporting the bug. I've neigher skill not time to deal with this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40959
[Bug target/41473] [4.5 Regression] dsymutil Assertion failed ...
--- Comment #41 from rguenther at suse dot de 2009-11-23 16:29 --- Subject: Re: [4.5 Regression] dsymutil Assertion failed ... On Mon, 23 Nov 2009, howarth at nitro dot med dot uc dot edu wrote: --- Comment #39 from howarth at nitro dot med dot uc dot edu 2009-11-23 15:43 --- Normally this wouldn't be a big deal, but powerpc support stops at Leopard so we are effectively cutting off powerpc-apple-darwin* from every properly generating dSYMs in gcc 4.5. So it's the responsibility of the darwin community to come up with either a fixed dsymutil or a proper re-implementation of it. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
[Bug target/41473] [4.5 Regression] dsymutil Assertion failed ...
--- Comment #42 from howarth at nitro dot med dot uc dot edu 2009-11-23 16:35 --- (In reply to comment #41) So it's the responsibility of the darwin community to come up with either a fixed dsymutil or a proper re-implementation of it. Richard. Unfortunately, dsymutil isn't part of Apple's open source releases so realistically we will just have to add a hack like comment 30 for distributed binary builds of FSF gcc in MacPorts and fink (if we want to be able to be able to debug code that triggers this issue on darwin9 and earlier). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
[Bug target/38644] Optimization flag -O1 -fschedule-insns2 causes wrong code
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-11-23 16:42 --- *** Bug 42155 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||heavy at smtp dot ru http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
[Bug rtl-optimization/42155] Optimizer generates bad code for ARM7 THUMB mode (local variable lost)
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-11-23 16:42 --- *** This bug has been marked as a duplicate of 38644 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42155
[Bug ada/42153] s-osinte.adb:46:21: missing body for To_Duration declared at s-osinte.ads:216
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2009-11-23 17:09 --- Presumably, thanks Laurent. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42153
[Bug objc++/42156] New: Hundreds of objc++ testsuite regressions
Sometime between mainline revision 154353: http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg01929.html and 154391: http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg01929.html I'm getting massive numbers of objc++ testsuite regressions. -- Summary: Hundreds of objc++ testsuite regressions Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: objc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ghazi at gcc dot gnu dot org GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42156
[Bug objc++/42156] Hundreds of objc++ testsuite regressions
--- Comment #1 from ghazi at gcc dot gnu dot org 2009-11-23 18:15 --- Sorry the second results for 154391 link is: http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg02040.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42156
[Bug fortran/42008] Wrongly rejected derived types with default initializers in PURE procedures
--- Comment #6 from burnus at gcc dot gnu dot org 2009-11-23 19:35 --- (In reply to comment #5) Without the patch it is rejected, with the patch it is not. I will look into this further. Would something like if (...-attr.saved) { gfc_error } work, combined with the patch from comment 3? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42008
[Bug middle-end/42095] [4.5 Regression] g++.dg/lto/20081118-1 cp_lto_20081118-1_0.o-cp_lto_20081118-1_1.o link
--- Comment #4 from jakub at gcc dot gnu dot org 2009-11-23 20:52 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42095
[Bug target/41473] [4.5 Regression] dsymutil Assertion failed ...
--- Comment #43 from andreast at gcc dot gnu dot org 2009-11-23 20:55 --- I understood Jack this way that he asked/is looking for a temporary solution to prove that this is the only issue we face with dsymutil. It is not the idea, from my understanding, that we, gcc, 'fix'/tweak gcc to workaround OS issues. Right now, my expectation is this, Apple has to fix this issue on both, Xcode-3.1x (Leopard) and Xcode-3.2x(Snow Leopard). There are a lot of users which are still on Xcode-3.1x, and a few will stay on this release since they can not upgrade due to the fact that Snow Leopard does not run on ppc machines. From the technical POV we should try to help isolating the issue. My 2 cents. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
[Bug rtl-optimization/42116] ice on valid code (unrecognizable insn)
--- Comment #10 from ltuikov at yahoo dot com 2009-11-23 20:56 --- Can anyone comment on this? I'd really like to use gcc 4.4.2 to cross compile ARC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42116
[Bug target/42113] [4.3/4.4/4.5 Regression] Internal Compiler error with -O3, breaking commit known
--- Comment #11 from uros at gcc dot gnu dot org 2009-11-23 21:14 --- Subject: Bug 42113 Author: uros Date: Mon Nov 23 21:14:32 2009 New Revision: 154464 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154464 Log: PR target/42113 * config/alpha/alpha.md (*cmp_sadd_si): Change mode of scratch register to SImode. (*cmp_sadd_sidi): Ditto. (*cmp_ssub_si): Ditto. (*cmp_ssub_sidi): Ditto. testsuite/ChangeLog: PR target/42113 * gcc.target/alpha/pr42113.c: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/gcc.target/alpha/pr42113.c Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/config/alpha/alpha.md branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42113
[Bug target/42113] [4.3/4.4/4.5 Regression] Internal Compiler error with -O3, breaking commit known
--- Comment #12 from uros at gcc dot gnu dot org 2009-11-23 21:27 --- Subject: Bug 42113 Author: uros Date: Mon Nov 23 21:27:30 2009 New Revision: 154465 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154465 Log: PR target/42113 * config/alpha/alpha.md (*cmp_sadd_si): Change mode of scratch register to SImode. (*cmp_sadd_sidi): Ditto. (*cmp_ssub_si): Ditto. (*cmp_ssub_sidi): Ditto. testsuite/ChangeLog: PR target/42113 * gcc.target/alpha/pr42113.c: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.target/alpha/pr42113.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/config/alpha/alpha.md branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42113
[Bug target/42113] [4.3/4.4/4.5 Regression] Internal Compiler error with -O3, breaking commit known
--- Comment #13 from ubizjak at gmail dot com 2009-11-23 21:30 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42113
[Bug target/41473] [4.5 Regression] dsymutil Assertion failed ...
--- Comment #44 from howarth at nitro dot med dot uc dot edu 2009-11-23 21:41 --- (In reply to comment #43) From the technical POV we should try to help isolating the issue. My 2 cents. Actually, if the Alexandre's patch... http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01292.html is approved, the issue will disappear. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
[Bug target/40959] build fails - No rule to make target `/usr/ports/lang/gcc43/work/build/ia64-portbld-freebsd8.0/libgcc/crtfastmath.o', needed by `T_TARGET'. Stop.
--- Comment #15 from mexas at bristol dot ac dot uk 2009-11-23 21:47 --- Hi Marcel, sorry to bother you with this again. Are you happy to be on my Cc list for this bug? Sure. sje@ doesn't quite know what he's talking about because he doesn't know FreeBSD. See also below. --- Comment #13 from sje at cup dot hp dot com 2009-11-23 15:43 --- I think you will need to create a fde-freebsd.c file in gcc/config/ia64 to define Unwind_FindTableEntry. See fde-glibc.c and fde-vms.c for examples. _Unwind_FindTableEntry is defined in libc. FYI, -- Marcel Moolenaar xcl...@mac.com -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40959
[Bug fortran/42131] Weird translation of DO loops
--- Comment #11 from tkoenig at gcc dot gnu dot org 2009-11-23 21:48 --- Created an attachment (id=19104) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19104action=view) another proposed patch Here's another proposed patch, but there is a problem with it. If we calculate (m2 - m1 + m3)/m3 with signed types, then this will overflow, for example, for do i=-huge(i),huge(i),2 The current implementation gets around that by doing the addition and division unsigned, then dividing unsigned as well. For this, there have to be two cases, one for m30 and one for m30, which is what we generate at the moment. Possible solutions: - get rid of the loop counter altogether - perform the intermediate calculation with increased precision, if available - Multiply everything by the sign of m3 before doing the unsigned math (which is what we do now, except that we hide this behind an if) - Trust two's complement arithmetic and hope that overflows don't trap (not, in general, a good idea) Any tricks I have missed? -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Attachment #19076|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42131
[Bug target/29720] Latest CVS: undefined reference to __tls_get_addr
--- Comment #3 from ubizjak at gmail dot com 2009-11-23 21:58 --- (In reply to comment #2) OK, that fixed the problem. But shouldn't configuration have caught it? So, fixed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29720
[Bug fortran/41860] -finit-local-XXX clobbers -fno-automatic
--- Comment #2 from jb at gcc dot gnu dot org 2009-11-23 22:01 --- Closing as fixed, as no complaints about the committed patch have surfaced. -- jb at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41860
[Bug middle-end/42127] Verify_flow_info: Wrong frequency of block. Profiled bootstrap failed.
--- Comment #4 from hubicka at gcc dot gnu dot org 2009-11-23 22:04 --- Fixed. -- hubicka at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42127
[Bug bootstrap/42157] New: [4.5 regression] ICE building stage 1 libgcc on IRIX 5.3: SEGV in compare_access_positions
While building current mainline (rev 154216) again after half a year, the bootstrap aborted while building the stage 1 libgcc: /vol/gcc/src/gcc-dist/libgcc/../gcc/libgcc2.c: In function '__muldi3': /vol/gcc/src/gcc-dist/libgcc/../gcc/libgcc2.c:562:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[3]: *** [_muldi3.o] Error 1 Running cc1 under gdb reveals (gdb) run -fpreprocessed libgcc2.i -quiet -dumpbase libgcc2.c -mno-synci -auxbase-strip _muldi3.o -g -g -g -O2 -O2 -O2 -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -version -o libgcc2.s Starting program: /tmp_mnt/vol/gcc/obj/gcc-4.5.0-20091116/5.3-gcc/mips-sgi-irix5.3/libgcc/cc1 -fpreprocessed libgcc2.i -quiet -dumpbase libgcc2.c -mno-synci -auxbase-strip _muldi3.o -g -g -g -O2 -O2 -O2 -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -version -o libgcc2.s GNU C (GCC) version 4.5.0 20091116 (experimental) [trunk revision 154216] (mips-sgi-irix5.3) compiled by GNU C version 4.1.1, GMP version 4.2.1, MPFR version 2.3.2, MPC version 0.8 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU C (GCC) version 4.5.0 20091116 (experimental) [trunk revision 154216] (mips-sgi-irix5.3) compiled by GNU C version 4.1.1, GMP version 4.2.1, MPFR version 2.3.2, MPC version 0.8 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 23aff50e67c559603acf00c443e2c073 Program received signal SIGSEGV, Segmentation fault. 0x014a2e48 in compare_access_positions (a=0x10292084, b=0x1029208c) at /vol/gcc/src/gcc-dist/gcc/tree-sra.c:1106 (gdb) p f1 $1 = (const access_p) 0x20 (gdb) p f2 $2 = (const access_p) 0x10291d80 (gdb) where #0 0x014a2e48 in compare_access_positions (a=0x10292084, b=0x1029208c) at /vol/gcc/src/gcc-dist/gcc/tree-sra.c:1106 #1 0x0fac4254 in qsort () at qsort.c:94 #2 0x014a610c in sort_and_splice_var_accesses (var=0x1a98b40) at /vol/gcc/src/gcc-dist/gcc/tree-sra.c:1407 #3 0x014a9050 in analyze_all_variable_accesses () at /vol/gcc/src/gcc-dist/gcc/tree-sra.c:1875 #4 0x014ad7dc in perform_intra_sra () at /vol/gcc/src/gcc-dist/gcc/tree-sra.c:2568 #5 0x014ada50 in early_intra_sra () at /vol/gcc/src/gcc-dist/gcc/tree-sra.c:2597 #6 0x00d17cec in execute_one_pass (pass=0x10180324) at /vol/gcc/src/gcc-dist/gcc/passes.c:1522 #7 0x00d1853c in execute_pass_list (pass=0x10180324) at /vol/gcc/src/gcc-dist/gcc/passes.c:1577 #8 0x00d18584 in execute_pass_list (pass=0x1017fe38) at /vol/gcc/src/gcc-dist/gcc/passes.c:1578 #9 0x00d16064 in do_per_function_toporder ( callback=0xd184a4 execute_pass_list, data=0x1018cb48) at /vol/gcc/src/gcc-dist/gcc/passes.c:1120 #10 0x00d19254 in execute_ipa_pass_list (pass=0x1017fe04) at /vol/gcc/src/gcc-dist/gcc/passes.c:1743 #11 0x011d6504 in ipa_passes () at /vol/gcc/src/gcc-dist/gcc/cgraphunit.c:1363 #12 0x011d6884 in cgraph_optimize () at /vol/gcc/src/gcc-dist/gcc/cgraphunit.c:1422 #13 0x011d5330 in cgraph_finalize_compilation_unit () at /vol/gcc/src/gcc-dist/gcc/cgraphunit.c:1090 #14 0x004c60a4 in c_write_global_declarations () at /vol/gcc/src/gcc-dist/gcc/c-decl.c:9489 #15 0x00626034 in compile_file () at /vol/gcc/src/gcc-dist/gcc/toplev.c:1061 #16 0x0062ac60 in do_compile () at /vol/gcc/src/gcc-dist/gcc/toplev.c:2408 #17 0x0062ae8c in toplev_main (argc=25, argv=0x7ffbfeb4) at /vol/gcc/src/gcc-dist/gcc/toplev.c:2450 #18 0x00601160 in main (argc=25, argv=0x7ffbfeb4) at /vol/gcc/src/gcc-dist/gcc/main.c:35 So far, I couldn't reproduce this in an i386-pc-solaris2.10 - mips-sgi-irix5.3 cross compiler. -- Summary: [4.5 regression] ICE building stage 1 libgcc on IRIX 5.3: SEGV in compare_access_positions Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ro at gcc dot gnu dot org GCC build triplet: mips-sgi-irix5.3 GCC host triplet: mips-sgi-irix5.3 GCC target triplet: mips-sgi-irix5.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42157
[Bug c/36470] sizeof UTF-32 is 2 on AVR
--- Comment #5 from hutchinsonandy at gcc dot gnu dot org 2009-11-23 22:10 --- Subject: Bug 36470 Author: hutchinsonandy Date: Mon Nov 23 22:10:18 2009 New Revision: 154471 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154471 Log: PR testsuite/36470 * gcc.dg/utf-cvt.c: Skip int test for 16bit int targets. Enable short test for avr target. * gcc.dg/utf32-1.c: Enable test for avr and m32 targets. * gcc.dg/utf32-2.c: Ditto. * gcc.dg/utf32-3.c: Ditto. * gcc.dg/utf32-4.c: Enable test for non-32bit targets. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/utf-cvt.c trunk/gcc/testsuite/gcc.dg/utf32-1.c trunk/gcc/testsuite/gcc.dg/utf32-2.c trunk/gcc/testsuite/gcc.dg/utf32-3.c trunk/gcc/testsuite/gcc.dg/utf32-4.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36470
[Bug tree-optimization/42154] [4.5 Regression] Wrong code from (early) SRA
--- Comment #2 from jamborm at gcc dot gnu dot org 2009-11-23 22:19 --- Proposed patch: http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01311.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42154