[Bug tree-optimization/46723] [4.5/4.6 Regression] internal compiler error: in get_initial_def_for_induction, at tree-vect-loop.c:2431
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46723 Ira Rosen irar at il dot ibm.com changed: What|Removed |Added CC||irar at il dot ibm.com --- Comment #8 from Ira Rosen irar at il dot ibm.com 2010-12-02 08:15:16 UTC --- *** get_initial_def_for_induction (gimple iv *** 2656,2667 --- 2639,2664 loop_arg = PHI_ARG_DEF_FROM_EDGE (iv_phi, latch_e); access_fn = analyze_scalar_evolution (iv_loop, PHI_RESULT (iv_phi)); + STRIP_NOPS (access_fn); gcc_assert (access_fn); this makes gcc_assert meaningless: STRIP_NOPS will segfault for NULL access_fn before the assert. Thanks, Ira
[Bug bootstrap/46757] bootstrap failure under Fedora 13 and 14
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46757
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2010-12-02
08:23:06 UTC ---
On Fedora mpc is packaged as libmpc (because mpc is already a different
package). So yum install {gmp,mpfr,libmpc}{,-devel} is all you need (probably
just yum install libmpc-devel would bring in all the dependencies).
Or you can do yum install /usr/lib64/libmpc.so
[Bug middle-end/46685] [4.6 Regression] New stack alignment failures with -fpic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46685 --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org 2010-12-02 08:40:08 UTC --- I'd actually prefer to go with the sparc.c change (probably including flag_reorder_blocks_and_partition), then hppa could just write its own function_section hook as a wrapper around default_function_section. Eric, what do you think? I don't have a working SPARC box around right now, so can't test it.
Re: [Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
Yeh, precisely. The ironly file is a placeholder into which we put the symbols found in the lto symtab so that they can take part in the link and their resolutions be determined. We have no way of conveying any symbol type The error comes out after the lto1 invocation, so why the ironly section is still around? I would expect it to be discarded at that time and replaced by whatever compiler returns to you. On the other hand, discarding won't help if there was non-LTO module referencing TLS var also used by LTO module I guess.
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #13 from Jan Hubicka hubicka at ucw dot cz 2010-12-02 08:47:28 UTC --- Yeh, precisely. The ironly file is a placeholder into which we put the symbols found in the lto symtab so that they can take part in the link and their resolutions be determined. We have no way of conveying any symbol type The error comes out after the lto1 invocation, so why the ironly section is still around? I would expect it to be discarded at that time and replaced by whatever compiler returns to you. On the other hand, discarding won't help if there was non-LTO module referencing TLS var also used by LTO module I guess.
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #14 from Dave Korn davek at gcc dot gnu.org 2010-12-02 08:52:20 UTC --- (In reply to comment #13) Yeh, precisely. The ironly file is a placeholder into which we put the symbols found in the lto symtab so that they can take part in the link and their resolutions be determined. We have no way of conveying any symbol type The error comes out after the lto1 invocation, so why the ironly section is still around? I would expect it to be discarded at that time and replaced by whatever compiler returns to you. It's the symbol from the ironly section that remains, and it gets discarded and replaced by the the symbol from the real object file by the linker multiple_definition callback hook when _bfd_generic_link_add_one_symbol is called to add the symbol from the real object file into the link hash table. Unfortunately, the elf linker has some additional checking that it does before calling that routine which preemptively complains about the multiple definition before the linker hook has a chance to replace the original ironly symbol by the new one.
[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749 --- Comment #19 from rguenther at suse dot de rguenther at suse dot de 2010-12-02 08:52:14 UTC --- On Wed, 1 Dec 2010, iains at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749 --- Comment #18 from Iain Sandoe iains at gcc dot gnu.org 2010-12-01 22:06:23 UTC --- (In reply to comment #16) On Wed, 1 Dec 2010, iains at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749 --- Comment #15 from Iain Sandoe iains at gcc dot gnu.org 2010-12-01 21:34:19 UTC --- splitting the command into compile and link steps will intentionally remove the dsymutil step - thus making the problem 'go away' ... dsymutil should _only_ be called if there is a source file on the c/l (which would have its object deleted and thus be unavailable for debug). Huh, ok. But the spec seems to call it unconditionally in the link-command-spec when -g is visible. At least I can't see how a source file is matched (and we now definitely do find object files as source for the link step). it is matched (with the noted hacky buggy behavior) by the list of suffixes. And the issue is probably that we match on the intermediate link command but execute only after that is finished. OK Well, that dsymutil hack looks like a hack. yeah - it's on my TODO (pr43751). FWIW, some time ago, I did enquire about the difficulty of adding an intentional additional post-link phase, with the feedback that it was prob. not easy. I thought about adding it to the collect-ld script instead. Why do we want it only if there is a .c source available? That doesn't make sense to me ... but i have no idea what dsymutil is supoosed to do, so ...
Re: [Bug driver/46760] LTO doesn't work with FDO
Hi, at one point I tried profiledbootstrap and problem is that we can not merge multiple LTO files that has been profiled different amount of times. This happens during our build because lto1 and cc1 share libbackend. We probably need to add code rescaling corresponding events... Honza
[Bug driver/46760] LTO doesn't work with FDO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46760 --- Comment #6 from Jan Hubicka hubicka at ucw dot cz 2010-12-02 09:00:51 UTC --- Hi, at one point I tried profiledbootstrap and problem is that we can not merge multiple LTO files that has been profiled different amount of times. This happens during our build because lto1 and cc1 share libbackend. We probably need to add code rescaling corresponding events... Honza
[Bug tree-optimization/46723] [4.5/4.6 Regression] internal compiler error: in get_initial_def_for_induction, at tree-vect-loop.c:2431
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46723 --- Comment #9 from rguenther at suse dot de rguenther at suse dot de 2010-12-02 09:03:35 UTC --- On Thu, 2 Dec 2010, irar at il dot ibm.com wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46723 Ira Rosen irar at il dot ibm.com changed: What|Removed |Added CC||irar at il dot ibm.com --- Comment #8 from Ira Rosen irar at il dot ibm.com 2010-12-02 08:15:16 UTC --- *** get_initial_def_for_induction (gimple iv *** 2656,2667 --- 2639,2664 loop_arg = PHI_ARG_DEF_FROM_EDGE (iv_phi, latch_e); access_fn = analyze_scalar_evolution (iv_loop, PHI_RESULT (iv_phi)); + STRIP_NOPS (access_fn); gcc_assert (access_fn); this makes gcc_assert meaningless: STRIP_NOPS will segfault for NULL access_fn before the assert. Ah, indeed. Of course we should never assert here (if we do the analysis has wrongly determined we can handle the induction), but of course we can't fail to vectorize at this point either ... Thanks, Richard.
[Bug middle-end/46679] fold_binary changes types in divisionm breaking configure -enable-checking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46679 Jay jay.krell at cornell dot edu changed: What|Removed |Added Version|4.5.1 |4.6.0 --- Comment #1 from Jay jay.krell at cornell dot edu 2010-12-02 09:08:49 UTC --- You can prove, almost, the existance of the bug by making this change to slightly increase it: jbook2:gcc jay$ svn diff fold-const.c Index: fold-const.c === --- fold-const.c(revision 167194) +++ fold-const.c(working copy) @@ -11648,7 +11648,7 @@ Note that only CEIL_DIV_EXPR and FLOOR_DIV_EXPR are rewritten now. At one time others generated faster code, it's not clear if they do after the last round to changes to the DIV code in expmed.c. */ - if ((code == CEIL_DIV_EXPR || code == FLOOR_DIV_EXPR) + if ((code == CEIL_DIV_EXPR || code == TRUNC_DIV_EXPR || code == FLOOR_DIV_EXPR) multiple_of_p (type, arg0, arg1)) return fold_build2_loc (loc, EXACT_DIV_EXPR, type, arg0, arg1); it: I don't think C ever produces ceil_div/floor_div, so it's hard to demonstrate. With this, bootstrap fails: /src/gcc-trunk/configure -prefix=/usr/local/gcc-trunk -enable-checking=assert,df,fold,misc,rtl,rtlflag,runtime,tree,types make -j4 /src/gcc-trunk/gcc/tree-ssa-loop-prefetch.c:1503:1: error: type mismatch in binary expression unsigned int int unsigned int D.55547 = D.55546 /[ex] 16; other than just removing this chunk of code completely, I might suggest checking that arg0 == op0 arg1 == op1. Though that is probably a bit more conservative than necessary.
[Bug driver/46760] LTO doesn't work with FDO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46760 Dave Korn davek at gcc dot gnu.org changed: What|Removed |Added Depends on||42690 AssignedTo|davek at gcc dot gnu.org|unassigned at gcc dot ||gnu.org --- Comment #7 from Dave Korn davek at gcc dot gnu.org 2010-12-02 09:08:42 UTC --- (In reply to comment #6) Hi, at one point I tried profiledbootstrap and problem is that we can not merge multiple LTO files that has been profiled different amount of times. This happens during our build because lto1 and cc1 share libbackend. We probably need to add code rescaling corresponding events... Honza Rather than open a second bug for this part of the problem, let's leave this PR to handle it; the first part of the problem that HJ originally reported can be considered a part of bug 42690, which I'm in the course of testing the attached patch as part of. So, de-assigning myself from this PR. Possibly we should consider this a build system bug and the makefile should be responsible for swapping sets of gcda files in and out? Otherwise the component should be changed to lto.
[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749 --- Comment #20 from Iain Sandoe iains at gcc dot gnu.org 2010-12-02 09:09:49 UTC --- (In reply to comment #19) On Wed, 1 Dec 2010, iains at gcc dot gnu.org wrote: yeah - it's on my TODO (pr43751). FWIW, some time ago, I did enquire about the difficulty of adding an intentional additional post-link phase, with the feedback that it was prob. not easy. I thought about adding it to the collect-ld script instead. Why do we want it only if there is a .c source available? That doesn't make sense to me ... but i have no idea what dsymutil is supoosed to do, so ... _any_ source, in fact -- hence PR43751 (because we don't even try to notice Fortran at present). OK. Without wishing to start any debate on whether the approach is good or bad. The idea is that one saves time in the compile/debug loop by _not_ linking the debug - and leaving it in the object files. This is fine until the c/l is of the form gcc some-source.ext-o exe because then the object is temporary and deleted, thus not available for debugging. So, dsymtuil (which is a stand-alone debug-linker - used, in general, for the packaging phase of a project) is invoked for such command lines. It grabs the debug from the files that will be deleted during the build. this is quite helpful: http://wiki.dwarfstd.org/index.php?title=Apple's_%22Lazy%22_DWARF_Scheme
Re: [Bug driver/46760] LTO doesn't work with FDO
Hi, you can still test bootstrap with simply commenting out that sorry. It should give, sort-of, sane results. I will implement counter rescaling once I get some time for it - it is not too hard. Also not too many setups actually train library built into multiple binaries, so it is not that critical outside GCC itself.
[Bug driver/46760] LTO doesn't work with FDO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46760 --- Comment #8 from Jan Hubicka hubicka at ucw dot cz 2010-12-02 09:22:38 UTC --- Hi, you can still test bootstrap with simply commenting out that sorry. It should give, sort-of, sane results. I will implement counter rescaling once I get some time for it - it is not too hard. Also not too many setups actually train library built into multiple binaries, so it is not that critical outside GCC itself.
[Bug c/46762] New: gcc crosscompiled for arm optimises away volatile struct member access when -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46762
Summary: gcc crosscompiled for arm optimises away volatile
struct member access when -Os
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: do...@cba.si
$ cat bug.c
struct GPIO
{
volatile unsigned int IDR;
} *GPIO = (struct GPIO *)(0x40010808);
volatile unsigned int *GPIO_PTR = (volatile unsigned int *)(0x40010808);
static inline int gpio_get_value_ok()
{
if (*GPIO_PTR 1)
return 1;
return 0;
}
void function_with_no_bug(void)
{
int timeout = 0x100;
while (gpio_get_value_ok() == 0) {
if (timeout-- == 0) {
return;
}
}
}
static inline int gpio_get_value_wrong()
{
if (GPIO-IDR 1)
return 1;
return 0;
}
void function_with_bug(void)
{
int timeout = 0x100;
while (gpio_get_value_wrong() == 0) {
if (timeout-- == 0) {
return;
}
}
}
$ arm-none-eabi-gcc -Wall -Os -c bug.c -o bug.o arm-none-eabi-objdump -xd
bug.o
bug.o: file format elf32-littlearm
bug.o
architecture: arm, flags 0x0011:
HAS_RELOC, HAS_SYMS
start address 0x
private flags = 500: [Version5 EABI]
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 0030 0034 2**2
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
1 .data 0008 0064 2**2
CONTENTS, ALLOC, LOAD, DATA
2 .bss 006c 2**0
ALLOC
3 .comment 002b 006c 2**0
CONTENTS, READONLY
4 .ARM.attributes 0034 0097 2**0
CONTENTS, READONLY
SYMBOL TABLE:
ldf *ABS* bug.c
ld .text .text
ld .data .data
ld .bss .bss
ld .comment .comment
ld .ARM.attributes .ARM.attributes
g F .text 002c function_with_no_bug
002c g F .text 0004 function_with_bug
0004 g O .data 0004 GPIO
g O .data 0004 GPIO_PTR
Disassembly of section .text:
function_with_no_bug:
0: e59f3020ldr r3, [pc, #32] ; 28
function_with_no_bug+0x28
4: e5932000ldr r2, [r3]
8: e3a03401mov r3, #16777216 ; 0x100
c: e5921000ldr r1, [r2]
10: e3110001tst r1, #1
14: 112fff1ebxnelr
14: R_ARM_V4BX *ABS*
18: e353cmp r3, #0
1c: 012fff1ebxeqlr
1c: R_ARM_V4BX *ABS*
20: e2433001sub r3, r3, #1
24: eaf8b c function_with_no_bug+0xc
28: .word 0x
28: R_ARM_ABS32 .data
002c function_with_bug:
2c: e12fff1ebx lr
2c: R_ARM_V4BX *ABS*
$ arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/home/domen/toolchains/arm-2010.09/bin/../libexec/gcc/arm-none-eabi/4.5.1/lto-wrapper
Target: arm-none-eabi
Configured with:
/scratch/julian/2010q3-release-eabi-lite/src/gcc-4.5-2010.09/configure
--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=arm-none-eabi
--enable-threads --disable-libmudflap --disable-libssp --disable-libstdcxx-pch
--enable-extra-sgxxlite-multilibs --with-gnu-as --with-gnu-ld
--with-specs='%{save-temps: -fverbose-asm} -D__CS_SOURCERYGXX_MAJ__=2010
-D__CS_SOURCERYGXX_MIN__=9 -D__CS_SOURCERYGXX_REV__=51
%{O2:%{!fno-remove-local-statics: -fremove-local-statics}}
%{O*:%{O|O0|O1|O2|Os:;:%{!fno-remove-local-statics: -fremove-local-statics}}}'
--enable-languages=c,c++ --disable-shared --enable-lto --with-newlib
--with-pkgversion='Sourcery G++ Lite 2010.09-51'
--with-bugurl=https://support.codesourcery.com/GNUToolchain/ --disable-nls
--prefix=/opt/codesourcery --with-headers=yes
--with-sysroot=/opt/codesourcery/arm-none-eabi
--with-build-sysroot=/scratch/julian/2010q3-release-eabi-lite/install/arm-none-eabi
--with-gmp=/scratch/julian/2010q3-release-eabi-lite/obj/host-libs-2010.09-51-arm-none-eabi-i686-pc-linux-gnu/usr
--with-mpfr=/scratch/julian/2010q3-release-eabi-lite/obj/host-libs-2010.09-51-arm-none-eabi-i686-pc-linux-gnu/usr
--with-mpc=/scratch/julian/2010q3-release-eabi-lite/obj/host-libs-2010.09-51-arm-none-eabi-i686-pc-linux-gnu/usr
--with-ppl=/scratch/julian/2010q3-release-eabi-lite/obj/host-libs-2010.09-51-arm-none-eabi-i686-pc-linux-gnu/usr
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #15 from Richard Guenther rguenth at gcc dot gnu.org 2010-12-02 09:41:58 UTC --- (In reply to comment #10) I am just trying to get Mozilla building with GNU ld instead of gold. First problem is that Mozilla links some of libraries as: /abuild/jh/trunk-install/bin/gcc -O3 -flto -flto-partition=none -fuse-linker-plugin -shared -Wl,-soname -Wl,libplds4.so -o libplds4.so ./plarena.o ./plhash.o ./plvrsion.o -L/abuild/jh/build-mozilla-new7/dist/lib -lnspr4 i.e. there is missing -fPIC that means that we compile into non-PIC code and GNU LD eventually complains about PC32 relocations into symbols that can be overwritten. Is this valid? If so, we need to work out -fPIC ourselves at LTO time It's valid I think and we try to work out fPIC ourselves in the funny LTO option handling code (but the options are not re-applied at ltrans stage I think, so it doesn't work at all with WHOPR). Richard. Honza
[Bug target/35258] two memcpy calls merged incorrectly with -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35258 Andreas Krebbel krebbel at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from Andreas Krebbel krebbel at gcc dot gnu.org 2010-12-02 09:41:57 UTC --- Fixed.
[Bug middle-end/46758] [4.5/4.6 Regression] -fgraphite-identity produces wrong code when using 64bit constants
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46758 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.5.2
[Bug fortran/46752] OpenMP - Seg fault for unallocated allocatable array in firstprivate clause
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46752 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution||INVALID --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2010-12-02 09:44:57 UTC --- That is invalid testcase. The Fortran restrictions on FIRSTPRIVATE clause, OpenMP 3.0, page 93, say: A variable that appears in a firstprivate clause must be definable. and Fortran standard says: An allocatable variable that has not been allocated is an example of a data object that is not definable. Non-definable allocatables are allowed just in PRIVATE or SHARED clauses.
[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749 --- Comment #21 from rguenther at suse dot de rguenther at suse dot de 2010-12-02 09:50:48 UTC --- On Thu, 2 Dec 2010, iains at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749 --- Comment #20 from Iain Sandoe iains at gcc dot gnu.org 2010-12-02 09:09:49 UTC --- (In reply to comment #19) On Wed, 1 Dec 2010, iains at gcc dot gnu.org wrote: yeah - it's on my TODO (pr43751). FWIW, some time ago, I did enquire about the difficulty of adding an intentional additional post-link phase, with the feedback that it was prob. not easy. I thought about adding it to the collect-ld script instead. Why do we want it only if there is a .c source available? That doesn't make sense to me ... but i have no idea what dsymutil is supoosed to do, so ... _any_ source, in fact -- hence PR43751 (because we don't even try to notice Fortran at present). OK. Without wishing to start any debate on whether the approach is good or bad. The idea is that one saves time in the compile/debug loop by _not_ linking the debug - and leaving it in the object files. This is fine until the c/l is of the form gcc some-source.ext-o exe because then the object is temporary and deleted, thus not available for debugging. So, dsymtuil (which is a stand-alone debug-linker - used, in general, for the packaging phase of a project) is invoked for such command lines. It grabs the debug from the files that will be deleted during the build. this is quite helpful: http://wiki.dwarfstd.org/index.php?title=Apple's_%22Lazy%22_DWARF_Scheme Huh, but what do you do at make install time? Copy the object files? Extract the debug info and put it into the binary again? Have a special dsymutil make install hook? Can we just disable this for the testsuite? Richard.
[Bug debug/46724] [4.6 Regression] Wrong debug info: Invalid variable location
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46724 --- Comment #2 from Andreas Krebbel krebbel at gcc dot gnu.org 2010-12-02 09:51:17 UTC --- Marked as 4.6 regression. The behavior of 4.5.2 isn't helpful either but it doesn't return a wrong value as with 4.6.
[Bug tree-optimization/46763] New: gcc 4.5: missed optimization: copy global to local, prefetch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46763 Summary: gcc 4.5: missed optimization: copy global to local, prefetch Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: edwinto...@gmail.com Created attachment 22601 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22601 gy.i.bz2 I made a simple change to OCaml's GC: copy a global to a local var (and restore before calling external function), and add a prefetchnta. The global optimization is worth ~4% speedup, the prefetchnta alone is ~8% speedup, and both ~10% speedup. I would expect GCC to do this optimization by itself (at least the global to register one). Attached is a testcase to show the missed optimization, the relevant function is sweep_slice (and its manually optimized variants sweep_slice2, ...): $ gcc-4.5 gy.i -O2 -lm $ ./a.out default: 1.325195s ( 100.0%) glob2loc: 1.268875s ( 95.8% +- 1.024%) prefetchnta: 1.207342s ( 91.1% +- 0.4986%) prefetch: 1.277638s ( 96.4% +- 0.1179%) glob2loc+prefetchnta: 1.199906s ( 90.5% +- 0.3629%) default is the original function (sweep_slice), glob2loc is my manual optimization of caml_gc_sweep_hp, prefetchnta and prefetch are __builtin_prefetch added by me (non-temporal prefetch is very good here), the last one is both manual optimizations at once, resulting in a 9.5% speedup. The attached testcase is quite large, because I dumped the sizes of all objects from the GC to have a realistic run of the GC, I also included all functions needed for the GC to run. gcc-4.5 and gcc-4.4 both have this missed optimization, didn't try older ones. BTW OCaml uses just -O -fno-defer-pop to compile, instead of -O2, but using -O or -O2 doesn't make much difference on this testcase, so I used -O2. $ gcc-4.5 -v Using built-in specs. COLLECT_GCC=gcc-4.5 COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.5.1/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.5.1-11' --with-bugurl=file:///usr/share/doc/gcc-4.5/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.5 --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.5 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-gold --enable-ld=default --with-plugin-ld=ld.gold --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.5.1 (Debian 4.5.1-11) CPU: AMD Phenom(tm) II X6 1090T Processor uname -a: Linux debian 2.6.36-phenom #107 SMP PREEMPT Sat Oct 23 10:30:01 EEST 2010 x86_64 GNU/Linux
[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749 --- Comment #22 from Iain Sandoe iains at gcc dot gnu.org 2010-12-02 10:10:06 UTC --- (In reply to comment #21) On Thu, 2 Dec 2010, iains at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749 --- Comment #20 from Iain Sandoe iains at gcc dot gnu.org 2010-12-02 09:09:49 UTC --- (In reply to comment #19) On Wed, 1 Dec 2010, iains at gcc dot gnu.org wrote: yeah - it's on my TODO (pr43751). FWIW, some time ago, I did enquire about the difficulty of adding an intentional additional post-link phase, with the feedback that it was prob. not easy. I thought about adding it to the collect-ld script instead. Why do we want it only if there is a .c source available? That doesn't make sense to me ... but i have no idea what dsymutil is supoosed to do, so ... _any_ source, in fact -- hence PR43751 (because we don't even try to notice Fortran at present). OK. Without wishing to start any debate on whether the approach is good or bad. The idea is that one saves time in the compile/debug loop by _not_ linking the debug - and leaving it in the object files. This is fine until the c/l is of the form gcc some-source.ext-o exe because then the object is temporary and deleted, thus not available for debugging. So, dsymtuil (which is a stand-alone debug-linker - used, in general, for the packaging phase of a project) is invoked for such command lines. It grabs the debug from the files that will be deleted during the build. this is quite helpful: http://wiki.dwarfstd.org/index.php?title=Apple's_%22Lazy%22_DWARF_Scheme Huh, but what do you do at make install time? Copy the object files? Extract the debug info and put it into the binary again? Have a special dsymutil make install hook? At install-time dsymutil is run and the relevant xxx.dSYM is installed along with the objects, where required. AFAICS, this is already handled within auto* gcc (the gcc libraries appear to build dSYMs). Can we just disable this for the testsuite? well, one possibility to resolve this, is to disable the 'automatic' running of dsymutil - add a '-syms' flag, and require that the user adds that flag along with the debug ones. In which case, it would be automatically absent from the test-suite. It's a bit of a cop-out and I don't know if it would be acceptable to Darwin maintainers .. but it's a thought. The problem showing in this PR would still arise for a user invoking such a flag along with flto -- so we need to fix it at some stage (but I wouldn't say it was in any way critical).
[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749 --- Comment #23 from Iain Sandoe iains at gcc dot gnu.org 2010-12-02 10:14:22 UTC --- (In reply to comment #22) At install-time dsymutil is run and the relevant xxx.dSYM is installed along with the objects, where required. s/objects/exes/
[Bug fortran/46753] [4.4/4.5/4.6 Regression] ICE: OpenMP - in extract_omp_for_data, at omp-low.c:335
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46753 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2010.12.02 10:16:31 CC||jakub at gcc dot gnu.org AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.4.6 Summary|ICE: OpenMP - in|[4.4/4.5/4.6 Regression] |extract_omp_for_data, at|ICE: OpenMP - in |omp-low.c:335 |extract_omp_for_data, at ||omp-low.c:335 Ever Confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2010-12-02 10:16:31 UTC --- Broken by http://gcc.gnu.org/viewcvs?root=gccview=revrev=132592
[Bug libfortran/46720] [4.6 Regression] missing quadmath_weak.h with --enable-maintainer-mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46720 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Severity|normal |enhancement --- Comment #1 from Thomas Koenig tkoenig at gcc dot gnu.org 2010-12-02 10:24:07 UTC --- The issue seems to be fixed after upgrading to automake 1.11.1 from 1.11, so I am ready to resolve this as invalid. However, two points: - The build process complains about the automake 1.11, but this warning scrolls past really fast, and if automake 1.11 really causes issues, this should be addressed. - The timestamps on the generated files should be set so that no unneeded regeneration takes place. How do you do that in svn? Any ideas on either point?
[Bug libfortran/46720] [4.6 Regression] missing quadmath_weak.h with --enable-maintainer-mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46720
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
Severity|enhancement |normal
--- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2010-12-02
10:33:00 UTC ---
(In reply to comment #1)
The issue seems to be fixed after upgrading to automake 1.11.1
from 1.11, so I am ready to resolve this as invalid.
1.11.1 is the correct version according to
http://gcc.gnu.org/install/prerequisites.html (GCC requires the latest release
in the 1.11 series, which is currently 1.11.1.)
However, two points:
- The build process complains about the automake 1.11, but this warning
scrolls past really fast, and if automake 1.11 really causes issues,
this should be addressed.
No idea about that one. Except: When regenerating a directory to a newer
version, please update all the directories using an older 1.11 to the latest
released version.
- The timestamps on the generated files should be set so that no
unneeded regeneration takes place.
No idea. Except using ./contrib/gcc_update, which touches the and the
configure/*.in files if it thinks that it is needed. (Causing that autoreconf
is not run because the touched configure files is newer than the modified
configure.ac file.)
* * *
Some older comments - written before comment 1 was available.
libgfortran/acinclude.m4 contains:
if test -f ../libquadmath/libquadmath.la; then
[...];
LIBQUADINCLUDE='- I$(srcdir)/../libquadmath'
else
[...]
LIBQUADINCLUDE=
Thus, the .h file can only be found if ../libquadmath/libquadmath.la is found
or when the .h file is for other reasons in the include path.
There might be also a race condition in building libgfortran and libquadmath;
however, I think (TM) that the following line of Makefile.def should take care
of it:
dependencies = { module=configure-target-libgfortran;
on=all-target-libquadmath; };
Given that many have bootstrapped successfully with and without
--enable-maintainer-mode, I assume either a race condition or that there is
something peculiar on the specific system, which triggers this bug.
[Bug tree-optimization/46763] gcc 4.5: missed optimization: copy global to local, prefetch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46763
Alexander Monakov amonakov at gcc dot gnu.org changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Comment #1 from Alexander Monakov amonakov at gcc dot gnu.org 2010-12-02
11:03:00 UTC ---
Small testcase for the global load/store issue:
int g;
extern int bar(int);
void foo(int n)
{
int i;
for (i = 0; i n; i++)
{
if (g)
{
g++;
g = bar(i);
}
else
g = i;
}
}
Trunk at -O3 does not optimize stores to g (at -O2, it also loads g on each
iteration):
.L3:
movl%ebx, g(%rip)
movl%ebx, %eax
addl$1, %ebx
cmpl%ebp, %ebx
je .L1
.L5:
testl %eax, %eax
je .L3
addl$1, %eax
movl%ebx, %edi
addl$1, %ebx
movl%eax, g(%rip)
callbar
cmpl%ebp, %ebx
movl%eax, g(%rip)
jne .L5
[Bug middle-end/46685] [4.6 Regression] New stack alignment failures with -fpic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46685
--- Comment #11 from Eric Botcazou ebotcazou at gcc dot gnu.org 2010-12-02
11:30:54 UTC ---
Alternatively, we could do something like:
--- gcc/config/sparc/sparc.c.jj2010-11-26 18:39:04.0 +0100
+++ gcc/config/sparc/sparc.c2010-11-29 15:35:00.727219374 +0100
@@ -1066,8 +1066,13 @@ sparc_expand_move (enum machine_mode mod
are absolutely sure that X is in the same segment as the GOT.
Unfortunately, the flexibility of linker scripts means that we
can't be sure of that in general, so assume that _G_O_T_-relative
- accesses are never valid on VxWorks. */
- if (GET_CODE (operands[1]) == LABEL_REF !TARGET_VXWORKS_RTP)
+ accesses are never valid on VxWorks.
+ If the label is non-local, it might be placed in a different section
+ from . and movMODE_pic_label_ref patterns require the label and .
+ to be in the same section. */
+ if (GET_CODE (operands[1]) == LABEL_REF
+ !TARGET_VXWORKS_RTP
+ !LABEL_REF_NONLOCAL_P (operands[1]))
{
if (mode == SImode)
{
Not sure if even in current function it could happen that sparc_expand_move
is asked for a label that is in the other partition. I mean something like:
__attribute__((noinline, noclone))
void bar (void *x)
{
asm volatile ( : : r (x) : memory);
}
__attribute__((noinline, noclone))
void baz (void)
{
asm volatile ( : : : memory);
}
__attribute__((noinline, noclone))
int foo (int x)
{
__label__ lab;
if (__builtin_expect (x, 0))
{
lab:
baz ();
return 2;
}
bar (lab);
return 1;
}
int
main (void)
{
int x, i;
asm volatile ( : =r (x) : 0 (0));
for (i = 0; i 100; i++)
foo (x);
return 0;
}
first compiled/linked with -O2 -fprofile-generate
-freorder-blocks-and-partition -fpic, then executed, then compiled again with
-O2 -fprofile-use -freorder-blocks-and-partition -fpic. At least on
x86_64-linux the baz () bb is .text.unlikely, while bar (lab) is .text
section. Now, I guess this wouldn't assemble on sparc-linux or Solaris, even
before Honza's patch.
This testcase just crashes the compiler. :-) But, yes, once the patchlet
Index: config/sparc/sparc.c
===
--- config/sparc/sparc.c(revision 167365)
+++ config/sparc/sparc.c(working copy)
@@ -9453,6 +9485,7 @@ sparc_file_end (void)
DECL_VISIBILITY (decl) = VISIBILITY_HIDDEN;
DECL_VISIBILITY_SPECIFIED (decl) = 1;
allocate_struct_function (decl, true);
+ cfun-is_thunk = 1;
current_function_decl = decl;
init_varasm_status ();
assemble_start_function (decl, name);
is applied, your prediction is verified:
ebotca...@grobluk:~/obj$ gcc/xgcc -Bgcc -O2 -fprofile-use
-freorder-blocks-and-partition -fpic pr46685.c
/tmp/ccg98MwA.s: Assembler messages:
/tmp/ccg98MwA.s:71: Error: operation combines symbols in different segments
/tmp/ccg98MwA.s:72: Error: operation combines symbols in different segments
Or simply amend the second patch above and disable this optimization even for
flag_reorder_blocks_and_partition.
This is good enough I'd think. Testing...
[Bug tree-optimization/46663] ICE: SIGSEGV in vect_recog_pow_pattern (gimple.h:2055) with -O -fexceptions -ftree-vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46663 --- Comment #1 from irar at gcc dot gnu.org 2010-12-02 11:47:15 UTC --- Author: irar Date: Thu Dec 2 11:47:12 2010 New Revision: 167366 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=167366 Log: PR tree-optimization/46663 * tree-vect-patterns.c (vect_recog_pow_pattern): Check that FUNCTION_DECL exists and that it's a builtin. Added: trunk/gcc/testsuite/gcc.dg/vect/pr46663.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-patterns.c
[Bug target/43751] dsymutil is not called for fortran and, under some circumstances not for other FEs.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43751 --- Comment #7 from Iain Sandoe iains at gcc dot gnu.org 2010-12-02 11:49:41 UTC --- proposed work-around for 4.6 http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00145.html Note the following web-page describes the intended usage/behavior of dsymutil http://wiki.dwarfstd.org/index.php?title=Apple's_%22Lazy%22_DWARF_Scheme
[Bug debug/46724] [4.6 Regression] Wrong debug info: Invalid variable location
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46724 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.12.02 12:11:48 CC||aoliva at gcc dot gnu.org, ||jakub at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2010-12-02 12:11:48 UTC --- I guess one option would be: 1) allow DECL_DEBUG_EXPR even on RESULT_DECL (i.e. not use VAR_DECL_CHECK there) 2) when creating function_result_decl in assign_parms_augmented_arg_list, either don't mark that artificial PARM_DECL with DECL_IGNORED_P but DECL_NAMELESS and put it into DECL_ARGUMENTS (but then it might confuse debuggers), or create a separate artificial DECL_NAMELESS DECL_BY_REFERENCE variable which will be put into outermost BLOCK. 3) in assign_parms, after assign_parm_setup_reg initializes it, we could emit a DEBUG_INSN for this artificial variable, equating it to the artificial PARM_DECL's DECL_RTL 4) and set DECL_DEBUG_EXPR of the RESULT_DECL to this artificial VAR_DECL The DECL_BY_REFERENCE thingie is there because var-tracking doesn't VALUE track aggregates, so we just want to track its address. Alex, what do you think about this?
[Bug c++/44871] Invalid type mismatches while merging C and C++ sources
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44871 --- Comment #15 from Richard Guenther rguenth at gcc dot gnu.org 2010-12-02 12:24:50 UTC --- Author: rguenth Date: Thu Dec 2 12:24:46 2010 New Revision: 167367 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=167367 Log: 2010-12-02 Richard Guenther rguent...@suse.de PR lto/44871 * gimple.c (canonical_type_hash_cache): New hashtable. (gimple_type_hash): Make a wrapper around ... (gimple_type_hash_1): ... this. Take gtc_mode argument. (gimple_canonical_type_hash): Likewise. (gtc_visit): Take a gtc_mode argument. (gimple_types_compatible_p_1): Likewise. Do not compare struct tag names or field names when computing canonical types. (gimple_types_compatible_p): Adjust. (visit): Take a gtc_mode argument. (iterative_hash_gimple_type): Likewise. Do not hash struct tag names or field names when computing hashes of canonical types. (gimple_register_canonical_type): Use gimple_canonical_type_hash for the hash. (print_gimple_types_stats): Dump stats of canonical_type_hash_cache. (free_gimple_type_tables): Free canonical_type_hash_cache. * g++.dg/lto/20101126-1_0.C: New testcase. * g++.dg/lto/20101126-1_1.c: Likewise. Added: trunk/gcc/testsuite/g++.dg/lto/20101126-1_0.C trunk/gcc/testsuite/g++.dg/lto/20101126-1_1.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimple.c trunk/gcc/testsuite/ChangeLog
[Bug c++/44871] Invalid type mismatches while merging C and C++ sources
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44871 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #16 from Richard Guenther rguenth at gcc dot gnu.org 2010-12-02 12:25:40 UTC --- Fixed.
[Bug fortran/46678] [4.6 Regression] Wrong code with strings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46678 --- Comment #12 from Tobias Burnus burnus at gcc dot gnu.org 2010-12-02 12:44:57 UTC --- I think we can close this PR - can't we?
[Bug other/46268] gengtype warning when GTY(()) markers have no effect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46268 Laurynas Biveinis lauras at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|SUSPENDED --- Comment #2 from Laurynas Biveinis lauras at gcc dot gnu.org 2010-12-02 12:50:11 UTC --- Currently straightforward implementation of this warning gives way too may false positives. To resolve them: 1) C preprocessor needs to be run on the gengtype input in order to resolve conditionally defined types, fields, or types used only by some backends and maybe help with vector issues too. 2) Vector macro machinery needs to be updated to sometimes output GTYs and sometimes not. This would cause a lot of leaking of implementation details to the macro users. The first one is a major roadblock for now.
[Bug c++/46764] New: std=c++0x causes compilation failure on SFINAE test for methods
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46764
Summary: std=c++0x causes compilation failure on SFINAE test
for methods
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bisq...@iki.fi
This code tests whether a class defines a method of a certain name or not.
It fails to compile on GCC when -std=c++0x is used. Without -std=c++0x, it
compiles and works fine.
#include iostream
struct Hello { int helloworld() { return 0; } };
struct Generic {};
// SFINAE test
template typename T
class has_helloworld
{
typedef char yes;
typedef struct { char dummy[2]; } no;
template typename C static yes test( typeof(C::helloworld) ) ;
template typename C static no test(...);
public:
enum { value = sizeof(testT(0)) == sizeof(yes) };
};
int main()
{
std::cout has_helloworldHello::value std::endl;
std::cout has_helloworldGeneric::value std::endl;
return 0;
}
With -std=c++0x, we get the following error message:
tmp5.cc:13:68: error: ISO C++ forbids in-class initialization of non-const
static member 'test'
tmp5.cc:13:68: error: template declaration of 'has_helloworld::yes test'
Without -std=c++0x, the code compiles without warnings.
Indicating that GCC misinterprets test() to be a member/variable initialization
rather than a method/function declaration, despite the parameter expression
yielding a type rather than a value.
[Bug libstdc++/43738] basic_file_stdio.cc uses ioctl on a fd, but not available on mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43738 --- Comment #15 from Kai Tietz ktietz at gcc dot gnu.org 2010-12-02 13:15:18 UTC --- Author: ktietz Date: Thu Dec 2 13:15:10 2010 New Revision: 167369 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=167369 Log: 2010-12-02 Kai Tietz kai.ti...@onevision.com PR libstdc++/43738 * config/io/basic_file_stdio.cc (showmanyc): Check _GLIBCXX_NO_IOCTL before use of ioctl. * config/os/mingw32/os_defines.h (_GLIBCXX_NO_IOCTL): New. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/config/io/basic_file_stdio.cc trunk/libstdc++-v3/config/os/mingw32/os_defines.h
[Bug libstdc++/43738] basic_file_stdio.cc uses ioctl on a fd, but not available on mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43738 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||ktietz at gcc dot gnu.org Resolution||FIXED --- Comment #16 from Kai Tietz ktietz at gcc dot gnu.org 2010-12-02 13:17:14 UTC --- Fixed.
[Bug tree-optimization/46763] gcc 4.5: missed optimization: copy global to local, prefetch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46763
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2010.12.02 13:26:31
CC||rguenth at gcc dot gnu.org
Depends on||41490
Ever Confirmed|0 |1
Severity|normal |enhancement
--- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2010-12-02
13:26:31 UTC ---
GCC has to preserve the stores and loads around the call to bar() as that
might change the value of the variable. So transforming to
int g;
extern int bar(int);
void foo(int n)
{
int i;
int tem = g;
for (i = 0; i n; i++)
{
if (tem)
{
tem++;
tem = bar(i);
}
else
tem = i;
}
g = tem;
}
if that is what you did in your source-to-source transformation isn't valid.
GCC can't do conditional store motion, that is, transform it to
int g;
extern int bar(int);
void foo(int n)
{
int i;
int tem = g;
for (i = 0; i n; i++)
{
if (tem)
{
tem++;
g = tem;
tem = bar(i);
}
else
tem = i;
}
g = tem;
}
which would be valid. An enabling transform is missing as well, sinking
the store to g:
int g;
extern int bar(int);
void foo(int n)
{
int i;
for (i = 0; i n; i++)
{
if (g)
{
g++;
tem = bar(i);
}
else
tem = i;
g = tem;
}
}
which would then allow us to do the load part of the partial store motion
by PRE. That is, you'd get
int g;
extern int bar(int);
void foo(int n)
{
int i,tem;
tem = g;
for (i = 0; i n; i++)
{
if (tem)
{
tem++;
g = tem;
tem = bar(i);
}
else
tem = i;
g = tem;
}
}
but we don't understand that we can sink the store out of the loop
as we don't understand the combined effect of g = tem; tem = bar (i);
to g. You also get the above with -O3 because we see a partial partial
redundancy but then you retain three stores (we still miss both
sinking opportunities). Fixing PR41490 might fix both.
[Bug fortran/46678] [4.6 Regression] Wrong code with strings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46678 --- Comment #13 from paul.richard.thomas at gmail dot com paul.richard.thomas at gmail dot com 2010-12-02 13:33:38 UTC --- Semms to me that Jerry should do the honours :-) Paul On Thu, Dec 2, 2010 at 1:45 PM, burnus at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46678 --- Comment #12 from Tobias Burnus burnus at gcc dot gnu.org 2010-12-02 12:44:57 UTC --- I think we can close this PR - can't we? -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug c/46765] New: Superfluous 'const' declaration does not generate error or warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46765 Summary: Superfluous 'const' declaration does not generate error or warning Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: fredrik.hederstie...@securitas-direct.com Assume we want to declare a pointer to constant data. This can be done by e.g. int const * ptrToConst1; But C/C++ also accepts: //identical to: int const * ptrToConst, const int * ptrToConst2; But GCC also accept a double-const declation: //identical to ??: const int * ptrToConst2; //superfluous const? No warning nor error. const int const * ptrToConst3; The superfluous 'const' declaration does not generate error or warning. It's obvious that the programmer most likely wanted to declare constant pointer to constant data, but he only gets pointer to constant data. He should get a warning or parse error for this. It's no meaning to declare 'constant data' twice. The second const-declaration does not have any effect. I'm compiling with GCC-4.5.1 and having all possible warning flags: -W -Wall -Wextra. I also attach small example file with test of various const-declarations.
[Bug c/46765] Superfluous 'const' declaration does not generate error or warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46765 --- Comment #1 from Fredrik Hederstierna fredrik.hederstie...@securitas-direct.com 2010-12-02 13:34:26 UTC --- Created attachment 22602 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22602 example file for const.
[Bug c++/46764] std=c++0x causes compilation failure on SFINAE test for methods
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46764 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2010-12-02 13:43:27 UTC --- changing typeof to decltype or __typeof__ causes it to work looks as though 'typeof' simply isn't recognised in C++0x mode
[Bug c++/46764] std=c++0x causes compilation failure on SFINAE test for methods
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46764 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||paolo.carlini at oracle dot ||com Resolution||INVALID --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2010-12-02 13:47:28 UTC --- And it's intended: -std=gnu++0x works (note that the default is -std=gnu++98 *not* -std=c++98)
[Bug c/46766] New: Type 'void' is treated differently if used as return value or as parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46766
Summary: Type 'void' is treated differently if used as return
value or as parameter
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: fredrik.hederstie...@securitas-direct.com
It is valid to return a void-function, or cast a variable to void, from a
void-function.
This makes some sense, in particular in C++ since we might have a template, and
we would like to put 'void' as type in this C++ template.
But then maybe it should also be allowed to put 'void' as inparameter to a
void-function, but then compiler warns about too many arguments.
void.c: In function ‘main’:
void.c:16: error: too many arguments to function ‘f1’
void.c:17: error: too many arguments to function ‘f2’
Somehow it would be more 'aligned' to have function-return-values and
function-in-parameters work the same way, so that template-alike-constructions,
or similar pure C macro/preprocessor constructions, could work the same
perhaps?
void f1(void)
{
return (void)0; //OK
}
void f2(void)
{
return f1(); //OK
}
int main(void)
{
f1();//OK
f2();//OK
f1((void)0); //ERROR
f2(f1());//ERROR
return 0;
}
[Bug c/46766] Type 'void' is treated differently if used as return value or as parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46766 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Andreas Schwab sch...@linux-m68k.org 2010-12-02 14:23:59 UTC --- void f1(void) declares a function that takes no parameters.
[Bug libgomp/45240] parallel.c: GOMP_parallel_end locks a mutex but fails to unlock it after atomic operation complete
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45240 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2010-12-02 14:30:41 UTC --- Author: jakub Date: Thu Dec 2 14:30:37 2010 New Revision: 167370 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=167370 Log: PR libgomp/45240 * parallel.c (GOMP_parallel_end): Unlock gomp_remaining_threads_lock at the end if sync builtins aren't supported. Modified: trunk/libgomp/ChangeLog trunk/libgomp/parallel.c
[Bug libgomp/43706] scheduling two threads on one core leads to starvation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43706 --- Comment #27 from Jakub Jelinek jakub at gcc dot gnu.org 2010-12-02 14:31:31 UTC --- Author: jakub Date: Thu Dec 2 14:31:27 2010 New Revision: 167371 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=167371 Log: PR libgomp/43706 * env.c (initialize_env): Default to spin count 30 instead of 2000 if neither OMP_WAIT_POLICY nor GOMP_SPINCOUNT is specified. Modified: trunk/libgomp/ChangeLog trunk/libgomp/env.c
[Bug fortran/46753] [4.4/4.5/4.6 Regression] ICE: OpenMP - in extract_omp_for_data, at omp-low.c:335
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46753 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2010-12-02 14:37:25 UTC --- Author: jakub Date: Thu Dec 2 14:37:20 2010 New Revision: 167372 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=167372 Log: PR fortran/46753 * trans-openmp.c (gfc_trans_omp_do): Use build2_loc instead of fold_build2_loc for OMP_FOR conditions. * libgomp.fortran/pr46753.f90: New test. Added: trunk/libgomp/testsuite/libgomp.fortran/pr46753.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-openmp.c trunk/libgomp/ChangeLog
[Bug c/46766] Type 'void' is treated differently if used as return value or as parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46766 --- Comment #2 from Fredrik Hederstierna fredrik.hederstie...@securitas-direct.com 2010-12-02 14:42:35 UTC --- Ok, but also f1() declares that it does not return any parameters, still it can return (void)0; I'm not saying either is wrong, I just though it should be consistent. If its ok to _return_ (void) from a function, why is it not ok to have (void) as _inparameter_ to a function. Where is the logical difference? /Fredrik
[Bug c/46766] Type 'void' is treated differently if used as return value or as parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46766
--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2010-12-02
15:14:14 UTC ---
(In reply to comment #0)
void f1(void)
{
return (void)0; //OK
This is valid in C++ but allowing it in C is a GCC extension.
void f2(void)
{
return f1(); //OK
This is valid in C++ but allowing it in C is a GCC extension.
f1((void)0); //ERROR
f2(f1());//ERROR
This is repulsive.
I don't see this as more aligned with the examples above, I see it as more
aligned with:
int i = (int) f1(); // EURGH
Or consider the following, how many arguments are given to f3?
void f3(int);
f3((void)0, f1(), f2(), 3); // EURGH
[Bug other/46542] GCC 4.7 pending patches meta-bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46542 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Attachment #22447|0 |1 is obsolete|| --- Comment #2 from Jeffrey A. Law law at redhat dot com 2010-12-02 15:33:33 UTC --- Created attachment 22603 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22603 Improve reload inheritance's code generation and predictability Updated version taking into account comments from various individuals. Compile time cost is down to less than .25% according to my testing.
Re: [Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
It's valid I think and we try to work out fPIC ourselves in the funny LTO option handling code (but the options are not re-applied at ltrans stage I think, so it doesn't work at all with WHOPR). Hmm, the link command above is LTO, not WHOPR. I wonder why we don't work out -fPIC ourselves then... Honza
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #16 from Jan Hubicka hubicka at ucw dot cz 2010-12-02 15:34:48 UTC --- It's valid I think and we try to work out fPIC ourselves in the funny LTO option handling code (but the options are not re-applied at ltrans stage I think, so it doesn't work at all with WHOPR). Hmm, the link command above is LTO, not WHOPR. I wonder why we don't work out -fPIC ourselves then... Honza
[Bug c/46766] Type 'void' is treated differently if used as return value or as parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46766
--- Comment #4 from Fredrik Hederstierna
fredrik.hederstie...@securitas-direct.com 2010-12-02 15:55:05 UTC ---
Yes, I agree its EURGH.
I guess its not preferred to make C++ template-alike code in C.
I think its worth avoid stuff like:
#ifdef BLAH_BLAH_BLAH
#define RETURN_TYPE_C_TEMPLATE void
#define PARAM_TYPE_C_TEMPLATE void
#define PARAM_TYPE_C_TEMPLATE_VARIABLE
#else
#define RETURN_TYPE_C_TEMPLATE int
#define PARAM_TYPE_C_TEMPLATE int
#define PARAM_TYPE_C_TEMPLATE_VARIABLE var
#endif
RETURN_TYPE_C_TEMPLATE func( PARAM_TYPE_C_TEMPLATE
PARAM_TYPE_C_TEMPLATE_VARIABLE )
{
return (RETURN_TYPE_C_TEMPLATE) template_func1(
PARAM_TYPE_C_TEMPLATE_VARIABLE );
}
int main(void)
{
func((PARAM_TYPE_C_TEMPLATE) template_func2());
return ERR_EURGH;
}
[Bug driver/46760] LTO bootstrap doesn't work with FDO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46760 --- Comment #9 from Jan Hubicka hubicka at gcc dot gnu.org 2010-12-02 15:57:00 UTC --- Created attachment 22604 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22604 Patch I am testing to allow profile merging This patch should allow merging of LTO units with different number of executions. I am testing how far I can get with lto bootstrap with this one and the pass-through
[Bug tree-optimization/46723] [4.5/4.6 Regression] internal compiler error: in get_initial_def_for_induction, at tree-vect-loop.c:2431
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46723 --- Comment #10 from Richard Guenther rguenth at gcc dot gnu.org 2010-12-02 16:23:26 UTC --- Author: rguenth Date: Thu Dec 2 16:23:20 2010 New Revision: 167377 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=167377 Log: 2010-12-02 Richard Guenther rguent...@suse.de PR tree-optimization/46723 * tree-vect-loop.c (get_initial_def_for_induction): Strip conversions from the induction evolution and apply it to the result instead. * tree-vect-stmts.c (vect_get_vec_def_for_operand): Handle assigns for induction defs. * gcc.dg/torture/pr46723.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr46723.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-loop.c trunk/gcc/tree-vect-stmts.c
[Bug tree-optimization/46723] [4.5 Regression] internal compiler error: in get_initial_def_for_induction, at tree-vect-loop.c:2431
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46723 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2 Known to work||4.6.0 Summary|[4.5/4.6 Regression]|[4.5 Regression] internal |internal compiler error: in |compiler error: in |get_initial_def_for_inducti |get_initial_def_for_inducti |on, at |on, at |tree-vect-loop.c:2431 |tree-vect-loop.c:2431 Known to fail|4.6.0 | Severity|critical|normal --- Comment #11 from Richard Guenther rguenth at gcc dot gnu.org 2010-12-02 16:27:26 UTC --- Fixed on trunk sofar.
[Bug target/43814] gcc failed to inline memcpy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43814
--- Comment #7 from Maxim Kuvyrkov mkuvyrkov at gcc dot gnu.org 2010-12-02
16:42:40 UTC ---
(In reply to comment #6)
...
, as an example look at the types the C frontend
generates for struct X __attribute__((packed)) { int x; };
void foo (struct X *p, int *q) { memcpy(p-x, q, 4); } - p-x
will have int * type, not int aligned(1) * type.
...
I considered infering initial alignment from function argument pointers
pointed-to types. But I think that's still dangerous. Also alignment
can be infered from dereferences, but that doesn't easily fit into the
CCP framework (there's no def for the pointer) and is also dangerous
as there is a lot of code out there that simply assumes misaligned
accesses are ok.
In short, it's not easy. I'd consider the pointer argument thing
for 4.6,
Do I understand correctly that alignment of p-x from the above example can be
correctly inferred from argument 'p'?
but would it really help in practice (as opposed to
simple artificial testcases)?
The above example was reduced from Dalvik VM, used in Android, and, generally,
expanding __builtin_memcpy and company to 4-byte loads/stores instead of 1-byte
loads/store is a problem worth fixing.
From the front-end point of view, are there any inherit problems that prevent
front-ends setting reliable alignment information on the types that middle-end
could trust? The information is there, right? It's just that middle-end
cannot trust it due to several unfortunate instances when front-end sets it
wrong.
[Bug tree-optimization/45199] [4.6 Regression] ICE in loop distribution at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45199 --- Comment #5 from Sebastian Pop spop at gcc dot gnu.org 2010-12-02 16:53:21 UTC --- Author: spop Date: Thu Dec 2 16:53:16 2010 New Revision: 167380 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=167380 Log: Fix PR45199: do not aggregate memory accesses to the same array for -ftree-loop-distribute-patterns 2010-11-30 Sebastian Pop sebastian@amd.com PR tree-optimization/45199 * tree-data-ref.c (mem_write_stride_of_same_size_as_unit_type_p): New. (stores_zero_from_loop): Call mem_write_stride_of_same_size_as_unit_type_p. * tree-data-ref.h (stride_of_unit_type_p): New. * tree-loop-distribution.c (generate_memset_zero): Simplified. Call stride_of_unit_type_p. (build_rdg_partition_for_component): Do not call rdg_flag_similar_memory_accesses when flag_tree_loop_distribute_patterns is set. * gcc.dg/tree-ssa/ldist-15.c: New. * gcc.dg/tree-ssa/ldist-16.c: New. * gfortran.dg/ldist-pr45199.f: New. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/ldist-15.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ldist-16.c trunk/gcc/testsuite/gfortran.dg/ldist-pr45199.f Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-data-ref.c trunk/gcc/tree-data-ref.h trunk/gcc/tree-loop-distribution.c
[Bug tree-optimization/45199] [4.6 Regression] ICE in loop distribution at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45199 Sebastian Pop spop at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Sebastian Pop spop at gcc dot gnu.org 2010-12-02 16:57:01 UTC --- Fixed
[Bug c/46765] Superfluous 'const' declaration does not generate error or warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46765 Joseph S. Myers jsm28 at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #2 from Joseph S. Myers jsm28 at gcc dot gnu.org 2010-12-02 16:57:02 UTC --- See bug 43651. *** This bug has been marked as a duplicate of bug 43651 ***
[Bug c/43651] add warning for duplicate qualifier
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43651 Joseph S. Myers jsm28 at gcc dot gnu.org changed: What|Removed |Added CC||fredrik.hederstie...@securi ||tas-direct.com --- Comment #5 from Joseph S. Myers jsm28 at gcc dot gnu.org 2010-12-02 16:57:02 UTC --- *** Bug 46765 has been marked as a duplicate of this bug. ***
[Bug target/43814] gcc failed to inline memcpy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43814
--- Comment #8 from rguenther at suse dot de rguenther at suse dot de
2010-12-02 17:01:08 UTC ---
On Thu, 2 Dec 2010, mkuvyrkov at gcc dot gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43814
--- Comment #7 from Maxim Kuvyrkov mkuvyrkov at gcc dot gnu.org 2010-12-02
16:42:40 UTC ---
(In reply to comment #6)
...
, as an example look at the types the C frontend
generates for struct X __attribute__((packed)) { int x; };
void foo (struct X *p, int *q) { memcpy(p-x, q, 4); } - p-x
will have int * type, not int aligned(1) * type.
...
I considered infering initial alignment from function argument pointers
pointed-to types. But I think that's still dangerous. Also alignment
can be infered from dereferences, but that doesn't easily fit into the
CCP framework (there's no def for the pointer) and is also dangerous
as there is a lot of code out there that simply assumes misaligned
accesses are ok.
In short, it's not easy. I'd consider the pointer argument thing
for 4.6,
Do I understand correctly that alignment of p-x from the above example can
be
correctly inferred from argument 'p'?
No, not at the moment.
but would it really help in practice (as opposed to
simple artificial testcases)?
The above example was reduced from Dalvik VM, used in Android, and, generally,
expanding __builtin_memcpy and company to 4-byte loads/stores instead of
1-byte
loads/store is a problem worth fixing.
From the front-end point of view, are there any inherit problems that prevent
front-ends setting reliable alignment information on the types that middle-end
could trust? The information is there, right? It's just that middle-end
cannot trust it due to several unfortunate instances when front-end sets it
wrong.
The frontend does not try to set alignment information on types used as
structure members, and those leak through address-taking. That's the
main exisiting issue (there may be others, but that's the one I know).
We also have the issue that for example Ada uses VIEW_CONVERT_EXPRs
where I am not sure if they have correct alignment information on them.
In the end we _should_ be able to use alignment information of the
types used at the access (that's also more reliable as compared to
use alignment information from pointer argument types).
But we already do that in MEM_REF expansion:
align = MAX (TYPE_ALIGN (TREE_TYPE (exp)),
get_object_alignment (exp, BIGGEST_ALIGNMENT));
Richard.
[Bug c/46766] Type 'void' is treated differently if used as return value or as parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46766 --- Comment #5 from Andreas Schwab sch...@linux-m68k.org 2010-12-02 17:10:15 UTC --- If you want the standard to be changed then this is the wrong place.
[Bug driver/42690] Undefined reference errors with -flto -fuse-linker-plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42690
--- Comment #32 from H.J. Lu hjl.tools at gmail dot com 2010-12-02 17:15:52
UTC ---
Another testcase:
[...@gnu-6 pr12245-6]$ cat y.c
#include stdio.h
#include stdlib.h
#include math.h
int
main (int argc, char **argv)
{
int d = atoi (argv[1]);
printf (%f\n, sin (d));
return 0;
}
[...@gnu-6 pr12245-6]$ make
/usr/gcc-4.6/bin/gcc -O2 -fwhole-program -flto=jobserver -fuse-linker-plugin
-c -o y.o y.c
/usr/gcc-4.6/bin/gcc -static -o foo -O2 -fwhole-program -flto=jobserver
-fuse-linker-plugin y.o -lm
/tmp/ccrHdm25.ltrans0.ltrans.o: In function `main':
ccrHdm25.ltrans0.o:(.text.startup+0x19): undefined reference to `sin'
collect2: ld returned 1 exit status
make: *** [foo] Error 1
[...@gnu-6 pr12245-6]$
[Bug fortran/46752] OpenMP - Seg fault for unallocated allocatable array in firstprivate clause
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46752 --- Comment #3 from Bill Long longb at cray dot com 2010-12-02 17:22:48 UTC --- Conflicting commentary from the OpenMP testers and James Beyer of the OpenMP committee: This test case is derived from OpenMP test omp3f/F03_2_9_3_4_5c.f90 . The case involves an allocatable array that is unallocated in the sequential portion of the test, but whose name appears in a firstprivate clause on a do loop construct. This usage is not specifically prohibited in the API. James Beyer says that 'We did intentionally allow allocatables that are not allocated into the firstprivate clause', so the test case should be acceptable and produce the desired result at runtime. The test case runs successfully on Cray, PGI, Intel, and Sun compilers.
[Bug testsuite/46767] New: r167374 introduce gcc.target/i386 regressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46767 Summary: r167374 introduce gcc.target/i386 regressions Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassig...@gcc.gnu.org ReportedBy: howa...@nitro.med.uc.edu On both x86_64 linux and x86_64 darwin, the commit of r167374 triggered a set of regressions in the gcc.target/i386 testsuite. At both -m32 and -m64, there include... FAIL: gcc.target/i386/pr37434-2.c scan-assembler pinsrw FAIL: gcc.target/i386/pr37434-4.c scan-assembler pinsrb and at -m64 only the additional failures... FAIL: gcc.target/i386/pr34256.c scan-assembler-times mov 2 FAIL: gcc.target/i386/sse2-init-v2di-2.c scan-assembler movq occur. I assume these scan-assembler tests are now invalid.
[Bug middle-end/46667] [4.6 Regression] -freorder-blocks-and-partition -g failed and libstdc++ builds for arm-eabi are broken.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46667 --- Comment #7 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2010-12-02 17:52:38 UTC --- Here's the backtrace I see for arm-eabi. #0 error (gmsgid=0xf323c8 %+D causes a section type conflict) at ../../combined/gcc/diagnostic.c:747 #1 0x00affd0d in get_section (name=0xf324e2 .text.unlikely, flags=2099456, decl=0x2ba5b228f900) at ../../combined/gcc/varasm.c:301 #2 0x00afff64 in get_named_section (decl=0x2ba5b228f900, name=0xf324e2 .text.unlikely, reloc=0) at ../../combined/gcc/varasm.c:392 #3 0x00b007ea in get_named_text_section (decl=0x2ba5b228f900, text_section_name=0xf324e2 .text.unlikely, named_section_suffix=0x0) at ../../combined/gcc/varasm.c:531 #4 0x00b00880 in default_function_section (decl=0x2ba5b228f900, freq=NODE_FREQUENCY_UNLIKELY_EXECUTED, startup=0 '\0', exit=0 '\0') at ../../combined/gcc/varasm.c:554 #5 0x00b00955 in function_section_1 (decl=0x2ba5b228f900, force_cold=1 '\001') at ../../combined/gcc/varasm.c:605 #6 0x00b009b8 in current_function_section () at ../../combined/gcc/varasm.c:635 #7 0x00b39835 in arm_is_long_call_p (decl=0x2ba5b225cd00) at ../../combined/gcc/config/arm/arm.c:5001 #8 0x00b39937 in arm_function_ok_for_sibcall (decl=0x2ba5b225cd00, exp=0x2ba5b2a84370) at ../../combined/gcc/config/arm/arm.c:5033 #9 0x006b1a4b in expand_call (exp=0x2ba5b2a84370, target=0x0, ignore=1) at ../../combined/gcc/calls.c:2306 #10 0x007614e0 in expand_expr_real_1 (exp=0x2ba5b2a84370, target=0x0, tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at ../../combined/gcc/expr.c:9299 #11 0x006c2796 in expand_gimple_stmt (stmt=0x2ba5b22caee0) at ../../combined/gcc/cfgexpand.c:1916 #12 0x006c342b in expand_gimple_basic_block (bb=0x2ba5b253e548) at ../../combined/gcc/cfgexpand.c:2154 #13 0x006c47b8 in gimple_expand_cfg () at ../../combined/gcc/cfgexpand.c:4046 #14 0x00897d6f in execute_one_pass (pass=0x136b600) at ../../combined/gcc/passes.c:1553 #15 0x00898065 in execute_pass_list (pass=0x136b600) at ../../combined/gcc/passes.c:1608 #16 0x0099c576 in tree_rest_of_compilation (fndecl=0x2ba5b228f900) at ../../combined/gcc/tree-optimize.c:422 #17 0x00b4d650 in cgraph_expand_function (node=0x2ba5b2465420) at ../../combined/gcc/cgraphunit.c:1508 #18 0x00b50469 in cgraph_optimize () at ../../combined/gcc/cgraphunit.c:1567 #19 0x00b5089d in cgraph_finalize_compilation_unit () at ../../combined/gcc/cgraphunit.c:1031 #20 0x00548c67 in cp_write_global_declarations () at ../../combined/gcc/cp/decl2.c:3973 #21 0x00940051 in toplev_main (argc=25, argv=0x79418f78) at ../../combined/gcc/toplev.c:591 #22 0x00350401d974 in __libc_start_main () from /lib64/libc.so.6 #23 0x0048a669 in _start () In a compiler configured in a combined tree with : ../combined/configure --with-newlib --target=arm-eabi --with-cpu=cortex-a9 --with-fpu=vfpv3-d16 --with-float=softfp --with-gmp=/projects/pl802_weddell/tools/linux_x86_64 --with-mpfr=/projects/pl802_weddell/tools/linux_x86_64 --with-mpc=/projects/pl802_weddell/tools/linux_x86_64 --enable-languages=c,c++
[Bug middle-end/46667] [4.6 Regression] -freorder-blocks-and-partition -g failed and libstdc++ builds for arm-eabi are broken.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46667 --- Comment #8 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2010-12-02 17:54:22 UTC --- Created attachment 22605 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22605 Testcase for ARM Backtrace shown in previous comment from the following debugging arguments. gdb --args /work/fsfwork/git/build-latest-eabi-clone/./gcc/cc1plus -fpreprocessed string-inst.ii -quiet -dumpbase string-inst.cc -mcpu=cortex-a9 -mfloat-abi=softfp -mfpu=vfpv3-d16 -auxbase-strip string-inst.o -g -O2 -Wall -Wextra -Wwrite-strings -Wcast-qual -std=gnu++0x -version -fno-implicit-templates -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -o string-inst.s
[Bug fortran/46752] OpenMP - Seg fault for unallocated allocatable array in firstprivate clause
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46752 --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2010-12-02 17:55:56 UTC --- (In reply to comment #3) This usage is not specifically prohibited in the API. Sound like a paraphrase for implementation defined/processor dependent to me. James Beyer says that 'We did intentionally allow allocatables that are not allocated into the firstprivate clause' Which seemingly did not work as the combining both standard disallows it, cf. comment 2. As Cray has a representative at the OpenMP ARB and as there is an almost ready OpenMP 3.1 draft (I think the current voting round ends on Tuesday): How about suggesting the OpenMP ARB that one explicitly states in the upcoming OpenMP spec that it is allowed?
[Bug c/45062] [4.6 Regression] Revision 162223 caused ICE at c-decl.c:4064
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45062 --- Comment #7 from Nathan Froyd froydnj at gcc dot gnu.org 2010-12-02 18:00:26 UTC --- Author: froydnj Date: Thu Dec 2 18:00:21 2010 New Revision: 167381 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=167381 Log: PR c/45062 * c-decl.c (grokparms): Set arg_info-parms to NULL_TREE when !funcdef_flag. Modified: trunk/gcc/ChangeLog trunk/gcc/c-decl.c
[Bug c/45062] [4.6 Regression] Revision 162223 caused ICE at c-decl.c:4064
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45062 Nathan Froyd froydnj at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #8 from Nathan Froyd froydnj at gcc dot gnu.org 2010-12-02 18:00:57 UTC --- Fixed.
[Bug target/46768] New: [4.6 Regression] FAIL: gcc.target/i386/pr37434-[24].c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46768 Summary: [4.6 Regression] FAIL: gcc.target/i386/pr37434-[24].c Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com CC: mkuvyr...@gmail.com On Linux/ia32, revision 167375 gave: FAIL: gcc.target/i386/pr37434-2.c scan-assembler pinsrw FAIL: gcc.target/i386/pr37434-4.c scan-assembler pinsrb
[Bug tree-optimization/45948] [4.6 Regression] ICE: SIGSEGV in find_uses_to_rename_use (tree-ssa-loop-manip.c:1242) with -O -fstrict-overflow -ftree-loop-distribution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45948
--- Comment #4 from Sebastian Pop spop at gcc dot gnu.org 2010-12-02 18:39:23
UTC ---
For this case, we end up generating two memset (0) for the first loop,
and we completely remove that loop:
void
foo (int i, int n)
{
int a[30];
int b[30];
for (; i n; i++)
a[i] = b[i] = 0;
while (1)
if (b[0])
bar (a[i - 1]);
}
The problem seems to be that the close phi node for the last value of
i is not removed by the scev constant propagation, and we don't have
the for loop anymore to compute it.
[Bug fortran/46752] OpenMP - Seg fault for unallocated allocatable array in firstprivate clause
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46752 --- Comment #5 from Bill Long longb at cray dot com 2010-12-02 18:42:53 UTC --- Reply from James: Version 3.1 of the OpenMP specification removes the offending bullet: A variable that appears in a firstprivate clause must be definable. When the new spec is released GCC will have to change to allow this test.
[Bug c++/46645] [4.6 Regression] FAIL: 20_util/unique_ptr/requirements/explicit_instantiation/explicit_instantiation.cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46645 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org --- Comment #7 from Jason Merrill jason at gcc dot gnu.org 2010-12-02 19:06:38 UTC --- Mine.
[Bug lto/46769] New: LTO failed to build gold
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46769 Summary: LTO failed to build gold Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com Gcc trunk revision 167368 failed to build gold: /usr/gcc-4.6/bin/g++ -W -Wall-Werror -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -frandom-seed=ld-new -g -O2 -flto=jobserver -fuse-linker-plugin -frandom-seed=1 -o ld-new main.o i386.o x86_64.o sparc.o powerpc.o arm.o arm-reloc-property.o libgold.a ../libiberty/libiberty.a -lpthread -ldl -lz /usr/gcc-4.6/bin/g++ -W -Wall-Werror -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -frandom-seed=incremental-dump -g -O2 -flto=jobserver -fuse-linker-plugin -frandom-seed=1 -o incremental-dump incremental-dump.o i386.o x86_64.o sparc.o powerpc.o arm.o arm-reloc-property.o libgold.a ../libiberty/libiberty.a -lpthread -ldl -lz In file included from /export/gnu/import/git/binutils/gold/options.h:6690:0, from :6068: /export/gnu/import/git/binutils/gold/icf.h: In member function ‘__base_dtor ’: /export/gnu/import/git/binutils/gold/icf.h:62:0: internal compiler error: in force_type_die, at dwarf2out.c:20704 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[5]: *** [/tmp/ccuOmFYl.ltrans1.ltrans.o] Error 1 make[5]: *** Waiting for unfinished jobs lto-wrapper: make returned 2 exit status lto-wrapper failedcollect2: ld returned 1 exit status
[Bug target/46768] [4.6 Regression] FAIL: gcc.target/i386/pr37434-[24].c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46768 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2010-12-02 19:11:26 UTC --- On Intel64, I got FAIL: gcc.target/i386/pr34256.c scan-assembler-times mov 2 FAIL: gcc.target/i386/pr37434-2.c scan-assembler pinsrw FAIL: gcc.target/i386/pr37434-2.c scan-assembler pinsrw FAIL: gcc.target/i386/pr37434-4.c scan-assembler pinsrb FAIL: gcc.target/i386/pr37434-4.c scan-assembler pinsrb FAIL: gcc.target/i386/sse2-init-v2di-2.c scan-assembler movq
[Bug tree-optimization/45948] [4.6 Regression] ICE: SIGSEGV in find_uses_to_rename_use (tree-ssa-loop-manip.c:1242) with -O -fstrict-overflow -ftree-loop-distribution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45948 --- Comment #5 from Sebastian Pop spop at gcc dot gnu.org 2010-12-02 19:19:46 UTC --- First patch here: http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00216.html However, I am not fully happy with this fix that tweaks scev const prop to work around this bug... The other fix that I am thinking about is that we test for scalar dependences outside the loop in the loop distribution pass, but it seems like rdg_defs_used_in_other_loops_p does not handle this correctly... I'm still investigating.
[Bug target/46770] New: Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 Summary: Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: mh+...@glandium.org Considering .init_array/.fini_array has been supported by glibc for 11 years ( http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=fcf70d4114db9ff7923f5dfeb3fea6e2d623e5c2;hp=3f3822198993be18d4d9ccb1593eea274dbd2ba0 ), it would make sense to use these instead of .ctors/.dtors, on systems supporting them.
[Bug target/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 --- Comment #1 from Mike Hommey mh+gcc at glandium dot org 2010-12-02 19:24:44 UTC --- Using .init_array/.fini_array instead of .ctors/.dtors removes the need for the associated (relative) relocations, and avoids the backwards disk seeks on startup (since while .ctors are processed backwards, .init_array is processed forward)
[Bug fortran/46752] OpenMP - Seg fault for unallocated allocatable array in firstprivate clause
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46752 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|WAITING Last reconfirmed||2010.12.02 19:41:57 Resolution|INVALID | Ever Confirmed|0 |1
[Bug c++/46759] incorrect array bounds warning?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46759 --- Comment #3 from rwgk at yahoo dot com 2010-12-02 19:47:29 UTC --- Created attachment 22606 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22606 reproducer with additional tests I changed the original reproducer to return 0 through 4 instead of true or false to verify that each branch is exercised with added tests. The output is as expected and valgrind doesn't report problems. Therefore I still believe the warning misfires. Assuming my code holds up under further scrutinization: It clearly is a minor problem but it creates distracting noise. If it is too much trouble to fix in the 4.5 branch, could the example be added to the test suite in the trunk, so that the same problem doesn't crop up again in the future? % valgrind a.out ==20636== Memcheck, a memory error detector ==20636== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==20636== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==20636== Command: a.out ==20636== 0 0 1 1 2 2 3 3 4 4 4 ==20636== ==20636== HEAP SUMMARY: ==20636== in use at exit: 0 bytes in 0 blocks ==20636== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==20636== ==20636== All heap blocks were freed -- no leaks are possible ==20636== ==20636== For counts of detected and suppressed errors, rerun with: -v ==20636== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 6)
[Bug middle-end/45297] [4.6 Regression] ICE: in create_linear_expr_from_tree, at graphite-sese-to-poly.c:1210 with -Os -fgraphite-identity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45297 --- Comment #13 from Sebastian Pop spop at gcc dot gnu.org 2010-12-02 20:13:16 UTC --- Author: spop Date: Thu Dec 2 20:13:11 2010 New Revision: 167390 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=167390 Log: Fix PR45297: handle ADDR_EXPR in interpret_rhs_expr as in follow_ssa_edge_expr. 2010-12-01 Sebastian Pop sebastian@amd.com PR middle-end/45297 * tree-scalar-evolution.c (interpret_rhs_expr): Handle ADDR_EXPR with MEM_REFs as POINTER_PLUS_EXPR. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-scalar-evolution.c
[Bug middle-end/45297] [4.6 Regression] ICE: in create_linear_expr_from_tree, at graphite-sese-to-poly.c:1210 with -Os -fgraphite-identity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45297 Sebastian Pop spop at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #14 from Sebastian Pop spop at gcc dot gnu.org 2010-12-02 20:14:45 UTC --- Fixed again.
[Bug debug/46771] New: [4.6 Regression] -fcompare-debug failure (length) with -O -ftree-vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46771 Summary: [4.6 Regression] -fcompare-debug failure (length) with -O -ftree-vectorize Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz CC: aol...@gcc.gnu.org Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 22607 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22607 reduced testcase Output: $ gcc -O -ftree-vectorize -fcompare-debug pr46771.c gcc: error: pr46771.c: -fcompare-debug failure (length) $ diff pr46771.*gkd 11c11 ...(long output) There's a difference in generated code with(out) -g. Tested revisions: r167383 - fail r165699 - fail r161659 - OK 4.5 r166509 - OK
[Bug fortran/46772] New: libquadmath: Build failure - strtod: static declaration of 'strtod' follows non-static declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46772 Summary: libquadmath: Build failure - strtod: static declaration of 'strtod' follows non-static declaration Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org Created attachment 22608 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22608 Draft patch On MinGW there is the following compiler error; cf. attachment. /mingw/i586-pc-mingw32/sys-include -DHAVE_CONFIG_H -I. -I../../../gcc-trunk/libquadmath -g -O2 -MT gdtoa/dmisc.lo -MD -MP -MF gdtoa/.deps/dmisc.Tpo -c ../../../gcc-trunk/libquadmath/gdtoa/dmisc.c -o gdtoa/dmisc.o In file included from ../../../gcc-trunk/libquadmath/gdtoa/gdtoaimp.h:186:0, from ../../../gcc-trunk/libquadmath/gdtoa/dmisc.c:32: c:/MinGW/include/stdlib.h:319:1: error: static declaration of 'strtod' follows non-static declaration ../../../gcc-trunk/libquadmath/gdtoa/gdtoa.h:112:15: note: previous declaration of 'strtod' was here
[Bug target/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 --- Comment #2 from Jan Hubicka hubicka at gcc dot gnu.org 2010-12-02 22:22:17 UTC --- Hmm, is it possible to do the change without breaking ABI (i.e. preserving the proper relative order for binary built with init_arra/fini_array linked with ctors/dtors library and vice versa? Honza
[Bug target/43751] dsymutil is not called for fortran and, under some circumstances not for other FEs.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43751 m...@gcc.gnu.org mrs at gcc dot gnu.org changed: What|Removed |Added CC||mrs at gcc dot gnu.org --- Comment #8 from mrs at gcc dot gnu.org mrs at gcc dot gnu.org 2010-12-02 22:27:34 UTC --- Please add a comment with a testcase that fails to work. I tried the obvious one, and when .f is added to darwin9.h, it worked.
[Bug target/46685] [4.6 Regression] New stack alignment failures with -fpic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46685
--- Comment #12 from Eric Botcazou ebotcazou at gcc dot gnu.org 2010-12-02
22:33:24 UTC ---
Author: ebotcazou
Date: Thu Dec 2 22:33:16 2010
New Revision: 167395
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=167395
Log:
PR target/46685
* config/sparc/sparc.c (can_use_mov_pic_label_ref): New predicate.
(sparc_expand_move): Call it to decide whether to emit the special
mov{si,di}_pic_label_ref patterns.
(sparc_legitimize_pic_address): Call it to decide whether to emit
the regular PIC sequence for labels. Fix long line.
(sparc_file_end): Set is_thunk for the PIC helper.
Added:
trunk/gcc/testsuite/gcc.dg/pr46685.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sparc/sparc.c
trunk/gcc/testsuite/ChangeLog
[Bug target/46768] [4.6 Regression] FAIL: gcc.target/i386/pr37434-[24].c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46768 --- Comment #2 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2010-12-02 22:50:49 UTC --- Author: hjl Date: Thu Dec 2 22:50:44 2010 New Revision: 167398 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=167398 Log: Turn on X86_TUNE_INTER_UNIT_MOVES for Core 2 and Core i7. 2010-12-02 H.J. Lu hongjiu...@intel.com PR target/46768 * config/i386/i386.c (initial_ix86_tune_features): Turn on X86_TUNE_INTER_UNIT_MOVES for Core 2 and Core i7. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c
[Bug target/46768] [4.6 Regression] FAIL: gcc.target/i386/pr37434-[24].c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46768 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added CC||howarth at nitro dot ||med.uc.edu --- Comment #3 from Uros Bizjak ubizjak at gmail dot com 2010-12-02 22:54:17 UTC --- *** Bug 46767 has been marked as a duplicate of this bug. ***
[Bug testsuite/46767] r167374 introduce gcc.target/i386 regressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46767 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Uros Bizjak ubizjak at gmail dot com 2010-12-02 22:54:17 UTC --- Dupe of 46768. *** This bug has been marked as a duplicate of bug 46768 ***
[Bug debug/46771] [4.6 Regression] -fcompare-debug failure (length) with -O -ftree-vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46771 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.12.02 22:59:29 CC||jakub at redhat dot com Target Milestone|--- |4.6.0 Ever Confirmed|0 |1 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2010-12-02 22:59:29 UTC --- It is caused by revision 165452: http://gcc.gnu.org/ml/gcc-cvs/2010-10/msg00636.html
[Bug target/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 --- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2010-12-02 23:01:14 UTC --- (In reply to comment #2) Hmm, is it possible to do the change without breaking ABI (i.e. preserving the proper relative order for binary built with init_arra/fini_array linked with ctors/dtors library and vice versa? Yes.
[Bug bootstrap/45888] tm.texi generation is not portable, rule is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45888 --- Comment #19 from Cesar Strauss cestrauss at gmail dot com 2010-12-02 23:38:39 UTC --- (In reply to comment #18) (In reply to comment #17) * anhvofrcaus at gmail dot com wrote on Tue, Nov 30, 2010 at 01:25:49AM CET: It is interesting that this fix worked for Cesar but not for me. In fact, it failed the same way, as reported earlier, on both MinGW and Cygwin. Dear Anh Vo, Please install the file utility. It should be able to identify if a file has CR or CRLF line terminators. Then, run in the source directory: file gcc/doc/tm.texi And in the build directory: file gcc/tm.texi Another way is to open the files using notepad. If the lines run all together, then the file has LF line terminators. If the lines look normal, then it has CRLF line terminators. Thanks, Cesar
[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749 m...@gcc.gnu.org mrs at gcc dot gnu.org changed: What|Removed |Added CC||mrs at gcc dot gnu.org --- Comment #24 from mrs at gcc dot gnu.org mrs at gcc dot gnu.org 2010-12-03 00:26:37 UTC --- The lto people need to engineer a design in which the debug information is left around in .o files, and those files are read at the very last step in a link, to collect the debug information from them and persist that information into the filesystem. They are removing .o files before the end of the final link. To the extent those files have debug information in them, this can't work. I could not find the last invocation of gcc that fails. If someone could point that out, I might be able to suggest a work around that just disappears debug information until such time as the first bug is fixed. Essentially, you can remove -g* from that line and disappear the collection of the debug information. Another solution would be to not have any .c, .cc, .C, .cpp, .cp, .c++, .cxx, .CPP, .m, .mm, .f, or .s files on that line.
