[Bug target/44129] Building linux kernel with gcc-4.5.0 and CONFIG_CC_OPTIMIZE_FOR_SIZE segfaults
--- Comment #9 from bdubbs at linuxfromscratch dot org 2010-05-16 06:38 --- I have traced the problem file for this bug to the kernel file arch/x86/kernel/tsc.c I have two source trees for the 2.6.33.4 kernel, one compiled with gcc-4.4.1 which works and gcc version 4.5.1 20100514 (prerelease) which fails. I have attached the config file that generates the error. I traced the problem to the above file, but don't know enough about the kernel and gcc internals to either parse it down much further or fix the problem. When I copy arch/x86/kernel/tsc.o from the 4.4.1 build to the 4.5.1 kernel tree and rebuild, the system (relatively generic Dell x86_64) boots properly. The file build command is: gcc -Wp,-MD,arch/x86/kernel/.tsc.o.d -nostdinc -isystem /usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.1/include -I/sources/linux-2.6.33.4-gcc45/arch/x86/include -Iinclude -include include/generated/autoconf.h -D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -fno-delete-null-pointer-checks -Os -m64 -march=core2 -mno-red-zone -mcmodel=kernel -funit-at-a-time -maccumulate-outgoing-args -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -pipe -Wno-sign-compare -fno-asynchronous-unwind-tables -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -Wframe-larger-than=2048 -fno-stack-protector -fno-omit-frame-pointer -fno-optimize-sibling-calls -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fno-dwarf2-cfi-asm -fconserve-stack -fno-stack-protector -DKBUILD_STR(s)=#s -DKBUILD_BASENAME=KBUILD_STR(tsc) -DKBUILD_MODNAME=KBUILD_STR(tsc) -c -o arch/x86/kernel/tsc.o arch/x86/kernel/tsc.c When I tried removing the -Os option, it did not fix the problem. I'm guessing the problem is around lines 724-761 because of the ifdef CONFIG_X86_64 and the use of rdtsc_barrier() in the panic info above. I'm really at the limits of what I know how to do here. I think I rebuilt/rebooted a hundred times to narrow things down so far. Let me know if I can do anything else. Many Bothans died to bring us this information. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44129
[Bug fortran/44155] gfortran segmentation fault using iso_c_binding
--- Comment #1 from jv244 at cam dot ac dot uk 2010-05-16 06:57 --- reduced testcase: module mod_tetgen use iso_c_binding type tetgenio double precision, pointer :: pointlist(:,:) integer :: numberoffacets = 0 end type tetgenio contains subroutine tetgenf( in, out ) type(tetgenio), target, intent(in):: in type(tetgenio), target, intent(inout) :: out call tetcall(inhandle, outhandle, c_loc(in%pointlist), out%numberoffacets) end subroutine tetgenf end module mod_tetgen #0 0x0056f9eb in gfc_conv_procedure_call (se=0x7fff0f31c1a0, sym=0x13f0400, arg=0x13f3f10, expr=0x13f44b0, append_args=0x0) at /data03/vondele/gcc_trunk/gcc/gcc/fortran/trans-expr.c:2545 #1 0x005702ba in gfc_conv_function_expr (se=0x7fff0f31c1a0, expr=0x13f44b0) at /data03/vondele/gcc_trunk/gcc/gcc/fortran/trans-expr.c:3792 #2 0x0056a798 in gfc_conv_expr_reference (se=0x13f40f0, expr=0x13f0400) at /data03/vondele/gcc_trunk/gcc/gcc/fortran/trans-expr.c:4582 #3 0x0056ed56 in gfc_conv_procedure_call (se=0x7fff0f31c830, sym=0x13f38e0, arg=0x13f3850, expr=0x0, append_args=0x0) at /data03/vondele/gcc_trunk/gcc/gcc/fortran/trans-expr.c:2858 #4 0x0058b9f3 in gfc_trans_call (code=0x13f4990, dependency_check=0 '\0', mask=0x0, count1=0x0, invert=0 '\0') at /data03/vondele/gcc_trunk/gcc/gcc/fortran/trans-stmt.c:378 #5 0x0054864f in trans_code (code=0x13f4990, cond=0x0) at /data03/vondele/gcc_trunk/gcc/gcc/fortran/trans.c:1144 #6 0x005624c7 in gfc_generate_function_code (ns=0x13f2740) at /data03/vondele/gcc_trunk/gcc/gcc/fortran/trans-decl.c:4456 #7 0x00547c3a in gfc_generate_module_code (ns=0x13e5530) at /data03/vondele/gcc_trunk/gcc/gcc/fortran/trans.c:1392 #8 0x0050d45c in gfc_parse_file () at /data03/vondele/gcc_trunk/gcc/gcc/fortran/parse.c:4303 #9 0x00544f7d in gfc_be_parse_file (set_yydebug=value optimized out) at /data03/vondele/gcc_trunk/gcc/gcc/fortran/f95-lang.c:239 -- jv244 at cam dot ac dot uk changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.4.4 4.5.1 4.6.0 Last reconfirmed|-00-00 00:00:00 |2010-05-16 06:58:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44155
[Bug fortran/36928] array temporary for interleaving assignment
--- Comment #8 from tkoenig at gcc dot gnu dot org 2010-05-16 09:00 --- Richard, what do you think of this? Does it make sense to do the dependency analysis in the front end? Does Graphite (about which I know next to nothing, I admit) have the necessary infrastructure to detect the dependencies? -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36928
[Bug c++/43911] [4.4/4.5 Regression] g++ can't compile any even trivial c++ source: undefined reference to `_Unwind_GetIPInfo'
--- Comment #27 from dougmencken at gmail dot com 2010-05-16 09:15 --- This is actually not a regression. It all belongs to my setup: I'm using busybox (without any coreutils and other shells) and uclibc. Here's the diff made from bootstrap directories from my setup and gentoo stage 2 uclibc: http://ftp.osuosl.org/pub/manulix/misc/diff-gcc-4.4.2-bootstraps.out libgcc/libgcc.map in the second doesn't include _Unwind_GetIPInfo and a bunch of others. This might be due to uname -p = unknown and such. But it is not a regression in GCC. Now closing this bug as WORKSFORME. Sorry for your time. -- dougmencken at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43911
[Bug bootstrap/44146] r159371 breaks bootstrap on x86_64-apple-darwin10
--- Comment #15 from iains at gcc dot gnu dot org 2010-05-16 09:32 --- (In reply to comment #13) (In reply to comment #12) 2/ m64 we get this : mini-02-sno:gcc-4-6-trunk-build $ otool -rv x86_64-apple-darwin10//libstdc++-v3/libsupc++/.libs/libsupc++.a |grep emu 002c True long True BRANCH False ___emutls_get_address 0024 True long True SIGNED False ___emutls_v._ZZN12_GLOBAL__N_110get_globalEvE6global 000c True long True BRANCH False ___emutls_get_address 0004 True long True SIGNED False ___emutls_v._ZZN12_GLOBAL__N_110get_globalEvE6global note ^^^ these are long rather than quad. otool -tv : eh-appl-m64.o: (__TEXT,__text) section __ZN12_GLOBAL__N_110get_globalEv: pushq %rbp 0001movq%rsp,%rbp 0004leaq0x(%rip),%rdi 000bcallq 0x0010 0010leave 0011ret ___cxa_get_globals_fast: 0012pushq %rbp 0013movq%rsp,%rbp 0016callq 0x001b 001bleave 001cret ___cxa_get_globals: 001dpushq %rbp 001emovq%rsp,%rbp 0021callq 0x0026 0026leave 0027ret -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44146
[Bug debug/41371] [4.5 Regression] var-tracking is slow and memory hungry
--- Comment #22 from dcb314 at hotmail dot com 2010-05-16 10:21 --- (In reply to comment #21) Assuming this is fixed. If you have a new testcase, please file a new PR. I am not sure that my original bug report is fixed. I tried 4.6 snapshot 20100515 and it couldn't compile it in ten minutes (ulimit -t 600) on a 2.7GHz Athlon. -- dcb314 at hotmail dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
[Bug fortran/36928] array temporary for interleaving assignment
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-05-16 10:30 --- It makes sense to do this in the frontend. The worst thing is when the frontend creates array temporaries - those are really really hard to get rid of in the middle-end. There are basically two (or maybe two and a half) ways to this and similar problems. 1) Do as much dependence analysis in the frontend as possible and create the remaining necessary temporaries there 2) Delay creation of all temporaries until somewhen in the middle-end 2.5) Mark the generated temporaries somehow to make them easier accessible to later middle-end optimizations I once was working on the necessary infrastructure to do 2) (the so-called middle-end array expressions). This work has been pushed back on my TODO list again and again (and recently I discovered some cases that it might not be able to handle) - simply due to lack of time (and lack of knowledge of the Fortran frontend which would be the only (or at least major) consumer). I do not think 2.5) is the proper way out of the issue, though probably it won't hurt (but I didn't think a lot about it nor do I have a proposal on how to do it). So I think 1) indeed makes sense. At the moment the frontend is the only one that can avoid generating temporaries. Note that Jakub had the useful suggestion of emitting versioned code from the frontend. Basically when the frontend knows that an array temporary might not be necessary emit two versions of the loop guarded with a proper runtime condition. One with and one without temporaries. This also has the chance that the middle-end will figure out that one of the cases is not necessary. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36928
[Bug debug/41371] [4.5/4.6 Regression] var-tracking is slow and memory hungry
--- Comment #23 from rguenth at gcc dot gnu dot org 2010-05-16 10:49 --- I see variable tracking : 734.06 (99%) usr 0.33 (35%) sys 735.29 (99%) wall 11548 kB ( 8%) ggc ... 743.18user 1.00system 12:25.12elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+10440outputs (0major+116553minor)pagefaults 0swaps for bug90.cc at -O2 -g with 4.5 branch r158342. Which is a 6800% regression over 4.4.3: 10.88user 0.62system 0:12.64elapsed 90%CPU (0avgtext+0avgdata 0maxresident)k 18664inputs+5096outputs (106major+55648minor)pagefaults 0swaps -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P1 |P2 Last reconfirmed|2009-10-18 18:00:22 |2010-05-16 10:49:29 date|| Summary|[4.5 Regression] var- |[4.5/4.6 Regression] var- |tracking is slow and memory |tracking is slow and memory |hungry |hungry Target Milestone|4.5.0 |4.5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
[Bug fortran/40873] -fwhole-file -fwhole-program: Wrong decls cause too much to be optimized away
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-05-16 10:53 --- (In reply to comment #5) A few comments: (1) adding -flto or -fwhopr solves the linking problem for the polyhedron tests and the reduced one in comment #1. (2) the test in comment #4 is different as it shows up for -fwhole-file and is not solved with -flto or -fwhopr. (3) I have been puzzled by the results in http://users.physik.fu-berlin.de/~tburnus/gcc-trunk/benchmark/ for fatigue.f90. It is due to -fwhole-program: [macbook] lin/test% gfc -O3 -ffast-math -fwhole-file -flto fatigue.f90 [macbook] lin/test% time a.out ... 9.223u 0.004s 0:09.23 99.8% 0+0k 0+0io 0pf+0w [macbook] lin/test% gfc -O3 -ffast-math -fwhole-program fatigue.f90 [macbook] lin/test% time a.out ... 6.482u 0.004s 0:06.49 99.8% 0+0k 0+0io 0pf+0w It would be interesting to understand why and to keep this nice speed up when fixing this pr. -fwhole-program enables -fwhole-file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40873
[Bug middle-end/41734] ICE in cgraph_mark_functions_to_output, at cgraphunit.c:1137 with -fwhopr
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-05-16 10:54 --- *** Bug 44153 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||pluto at agmk dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41734
[Bug lto/44153] ICE in cgraph_mark_functions_to_output, at cgraphunit.c:1194
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-05-16 10:54 --- -fwhopr is known to be broken in 4.5.x. *** This bug has been marked as a duplicate of 41734 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44153
[Bug lto/44150] [4.6 regression] g++.dg/lto/20081109 cp_lto_20081109_0.o-cp_lto_20081109_1.o
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-05-16 10:56 --- (In reply to comment #3) Why is flag_exceptions not just streamed out/in with other options? It is, but the option merging is basically broken by design (and comes too late anyway). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44150
[Bug lto/44150] [4.6 regression] g++.dg/lto/20081109 cp_lto_20081109_0.o-cp_lto_20081109_1.o
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-05-16 10:58 --- (In reply to comment #2) OK, here's what's going wrong: The LTO design is such that EH is only enabled if we encounter a function with an EH personality. With -fwhopr we process one translation unit at a time, so when we look at 20081109_1.C we only see foo(int). Before my patch foo(int) contained an ERT_MUST_NOT_THROW region, so we required the C++ personality function. After my patch, it contains an ERT_CLEANUP region instead, which doesn't require the C++ personality function So cgraph doesn't set DECL_FUNCTION_PERSONALITY, so lto1 doesn't think that foo needs EH, so it never sets flag_exceptions, so we don't get unwind information, so the throw can't unwind through foo. There seem to be two issues here: 1) lto1 incorrectly thinks foo doesn't need EH. 2) -fwhopr means that lto1 can make different decisions about EH for different translation units, so things blow up when linked together. With #2 fixed, #1 isn't as big a problem--but it could still be an issue if we aren't compiling the entire program, i.e. a shared library wants to throw from a callback. If anything we call can throw, we need unwind information and should turn on -fexceptions. 2) should be fixed by deciding on EH info at WPA stage (and not re-deciding at LTRANS stage for every translation unit). The current way of detecting whether to init EH is somewhat of a hack, and there is no convenient place to store such overall properties (no, the current option saving/restoring machiner is not it). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44150
[Bug fortran/40873] -fwhole-file -fwhole-program: Wrong decls cause too much to be optimized away
--- Comment #7 from dominiq at lps dot ens dot fr 2010-05-16 11:00 --- -fwhole-program enables -fwhole-file. Yes, but -fwhole-file does not enable -fwhole-program. All the polyhedron tests pass with -fwhole-file (and say -O3 -ffast-math), but the test in comment #4 fails with -whole-file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40873
[Bug fortran/40873] -fwhole-file -fwhole-program: Wrong decls cause too much to be optimized away
--- Comment #8 from rguenther at suse dot de 2010-05-16 11:04 --- Subject: Re: -fwhole-file -fwhole-program: Wrong decls cause too much to be optimized away On Sun, 16 May 2010, dominiq at lps dot ens dot fr wrote: --- Comment #7 from dominiq at lps dot ens dot fr 2010-05-16 11:00 --- -fwhole-program enables -fwhole-file. Yes, but -fwhole-file does not enable -fwhole-program. All the polyhedron tests pass with -fwhole-file (and say -O3 -ffast-math), but the test in comment #4 fails with -whole-file. -fwhole-file cannot enable -fwhole-program. -fwhole-program says to the optimizers that they do see the whole program - all callers to functions defined in the current TU have to be visible (and have correct callgraph edges, thus -fwhole-file). You cant' compare -fwhole-file numbers to -fwhole-program numbers. -fwhole-file is a correctness option, w/o it the Frontend generates an invalid representation for the middle-end. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40873
[Bug fortran/40873] -fwhole-file -fwhole-program: Wrong decls cause too much to be optimized away
--- Comment #9 from dominiq at lps dot ens dot fr 2010-05-16 11:16 --- You cant' compare -fwhole-file numbers to -fwhole-program numbers. -fwhole-file is a correctness option, w/o it the Frontend generates an invalid representation for the middle-end. Well, from what I saw running the polyhedron tests, -fwhole-file is more than a correctness option. I think it exposes more optimization opportunities to the middle end, giving faster executable for ac, aermod, and doduc. Note that adding -flto gives also some speed up for these tests. Due to this pr one cannot test the effect of -fwhole-program on half the tests. However using it for fatigue gives a quite large speed up I do not see for the seven other tests. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40873
[Bug fortran/40873] -fwhole-file -fwhole-program: Wrong decls cause too much to be optimized away
--- Comment #10 from rguenther at suse dot de 2010-05-16 11:21 --- Subject: Re: -fwhole-file -fwhole-program: Wrong decls cause too much to be optimized away On Sun, 16 May 2010, dominiq at lps dot ens dot fr wrote: --- Comment #9 from dominiq at lps dot ens dot fr 2010-05-16 11:16 --- You cant' compare -fwhole-file numbers to -fwhole-program numbers. -fwhole-file is a correctness option, w/o it the Frontend generates an invalid representation for the middle-end. Well, from what I saw running the polyhedron tests, -fwhole-file is more than a correctness option. I think it exposes more optimization opportunities to the middle end, giving faster executable for ac, aermod, and doduc. Note that adding -flto gives also some speed up for these tests. Due to this pr one cannot test the effect of -fwhole-program on half the tests. However using it for fatigue gives a quite large speed up I do not see for the seven other tests. It enables more optimization opportunities because calls inside the unit are visible as such. Without -fwhole-file nearly all calls look like calls to external functions and local functions appear unused. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40873
[Bug fortran/44156] New: dot_product / matmul and signed zeros
Strictly speaking, we should get -0.0 in all cases. i...@linux-fd1f:~/Fort cat intrinsic_signed_zero.f90 program main implicit none real, dimension(1) :: a, b real, dimension(1,1) :: aa, bb a(1) = -1.0 b(1) = 0.0 print *,a(1)*b(1) print *,dot_product(a,b) aa(1,1) = -1.0 bb(1,1) = 0.0 print *,matmul(aa,bb) end program main i...@linux-fd1f:~/Fort gfortran intrinsic_signed_zero.f90 i...@linux-fd1f:~/Fort ./a.out -0.000 0.000 0.000 -- Summary: dot_product / matmul and signed zeros Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: wrong-code Severity: minor Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44156
[Bug debug/43776] cpu hog with '-O1 -g2' / var-tracking issue?
--- Comment #3 from pluto at agmk dot net 2010-05-16 12:22 --- *** This bug has been marked as a duplicate of 41371 *** -- pluto at agmk dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43776
[Bug debug/41371] [4.5/4.6 Regression] var-tracking is slow and memory hungry
--- Comment #24 from pluto at agmk dot net 2010-05-16 12:22 --- *** Bug 43776 has been marked as a duplicate of this bug. *** -- pluto at agmk dot net changed: What|Removed |Added CC||pluto at agmk dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
[Bug debug/41371] [4.5/4.6 Regression] var-tracking is slow and memory hungry
--- Comment #25 from pluto at agmk dot net 2010-05-16 12:26 --- PR43776 constains another thestcase: results for top of 4.5/4.6: $ time g++45 -Wall -c 1.ii -O1 -g2 1.ii: In member function 'void es::ClockAnalyzer::initPrimitives()': 1.ii:38722:7: note: variable tracking size limit exceeded with -fvar-tracking-assignments, retrying without g++45 -Wall -c 1.ii -O1 -g2 32,72s user 0,35s system 99% cpu 33,096 total $ time g++46 -Wall -c 1.ii -O1 -g2 1.ii: In member function 'void es::ClockAnalyzer::initPrimitives()': 1.ii:38722:7: note: variable tracking size limit exceeded with -fvar-tracking-assignments, retrying without g++46 -Wall -c 1.ii -O1 -g2 23,68s user 0,40s system 99% cpu 24,099 total btw. the '-O1 -fno-inline -g2' has worse results. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
[Bug c++/44157] New: GCC wrongly takes a std::initializer_list argument as non-deduced context
This is well-formed, but GCC does not like it
#include initializer_list
templatetypename T
void f(T) { }
int main() {
std::initializer_listint a = { 0 };
f(a);
}
main1.cpp: In function 'int main()':
main1.cpp:8:6: warning: deducing 'T' as 'std::initializer_listint'
main1.cpp:4:6: warning: in call to 'void f(T) [with T =
std::initializer_listint]'
main1.cpp:8:6: warning: (you can disable this with -fno-deduce-init-list)
The FCD says that if the argument is an initializer list and the parameter is
a T, the parameter is a non-deduced context (14.8.2.1/1). In this code,
however, the argument is not an initializer list (if called as f({0}), it
would be). Consequently, the warning is wrong.
--
Summary: GCC wrongly takes a std::initializer_list argument as
non-deduced context
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schaub-johannes at web dot de
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44157
[Bug bootstrap/44146] r159371 breaks bootstrap on x86_64-apple-darwin10
--- Comment #16 from iains at gcc dot gnu dot org 2010-05-16 12:56 --- leaving off the eh and debug stuff look at .text __ZN12_GLOBAL__N_110get_globalEv: LFB100: pushq %rbp LCFI0: movq%rsp, %rbp LCFI1: reference a variable relative to the instruction pointer is this intended?? seems doomed to fail at some point leaq___emutls_v._ZZN12_GLOBAL__N_110get_globalEvE6global(%rip), %rdi call___emutls_get_address leave LCFI2: ret LFE100: .globl ___cxa_get_globals_fast ___cxa_get_globals_fast: LFB101: pushq %rbp LCFI3: movq%rsp, %rbp LCFI4: call__ZN12_GLOBAL__N_110get_globalEv leave LCFI5: ret LFE101: .globl ___cxa_get_globals ___cxa_get_globals: LFB102: pushq %rbp LCFI6: movq%rsp, %rbp LCFI7: call__ZN12_GLOBAL__N_110get_globalEv leave LCFI8: ret LFE102: .no_dead_strip ___emutls_v._ZZN12_GLOBAL__N_110get_globalEvE6global .data .align 5 ___emutls_v._ZZN12_GLOBAL__N_110get_globalEvE6global: .quad 16 .quad 8 .quad 0 .quad 0 .section __TEXT,__eh_frame,coalesced,no_toc+strip_static_syms+live_support EH_frame1: .set L$set$0,LECIE1-LSCIE1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44146
[Bug bootstrap/44146] r159371 breaks bootstrap on x86_64-apple-darwin10
--- Comment #17 from iains at gcc dot gnu dot org 2010-05-16 13:51 --- (In reply to comment #16) leaving off the eh and debug stuff look at .text __ZN12_GLOBAL__N_110get_globalEv: LFB100: pushq %rbp LCFI0: movq%rsp, %rbp LCFI1: reference a variable relative to the instruction pointer is this intended?? seems doomed to fail at some point leaq___emutls_v._ZZN12_GLOBAL__N_110get_globalEvE6global(%rip), %rdi well, clearly, it's intended - non-emutls code does the same thing (when compiled m64). However, the point remains that a 32bit offset is going to fail to reach variables as soon as the total space occupied 4Gb it seems maybe we have a code-gen problem ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44146
[Bug c++/44158] New: [C++0x]wrong overload resolution for copy-initialization from an rvalue
In the following code, the X's move constructor (the constructor overloaded for
rvalue reference) should be called for the copy-initialization
`X y = static_castX(x);', and two successive assertions should be passed.
However, it seems that the implicitly defined copy constructor is called, and
the second assertion fails.
cryol...@thinblue:~/work/gcc_bug/move_on_tribially_copy_constructible$
g++-4.5.0 -v -save-temps -std=c++0x main.cpp
Using built-in specs.
COLLECT_GCC=g++-4.5.0
COLLECT_LTO_WRAPPER=/home/cryolite/local/libexec/gcc/i486-linux-gnu/4.5.0/lto-wrapper
Target: i486-linux-gnu
Configured with: ../gcc-4.5.0/configure --build=i486-linux-gnu
--prefix=/home/cryolite/local --program-suffix=-4.5.0
--enable-version-specific-runtime-libs --enable-languages=c,c++
Thread model: posix
gcc version 4.5.0 (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++0x' '-shared-libgcc'
'-mtune=i486' '-march=i486'
/home/cryolite/local/libexec/gcc/i486-linux-gnu/4.5.0/cc1plus -E -quiet -v
-D_GNU_SOURCE main.cpp -mtune=i486 -march=i486 -std=c++0x -fpch-preprocess -o
main.ii
ignoring duplicate directory /home/cryolite/local/include
ignoring nonexistent directory
/home/cryolite/local/lib/gcc/i486-linux-gnu/4.5.0/../../../../i486-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/home/cryolite/local/include
/home/cryolite/local/lib/gcc/i486-linux-gnu/4.5.0/include/c++
/home/cryolite/local/lib/gcc/i486-linux-gnu/4.5.0/include/c++/i486-linux-gnu
/home/cryolite/local/lib/gcc/i486-linux-gnu/4.5.0/include/c++/backward
/usr/local/include
/home/cryolite/local/lib/gcc/i486-linux-gnu/4.5.0/include
/home/cryolite/local/lib/gcc/i486-linux-gnu/4.5.0/include-fixed
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++0x' '-shared-libgcc'
'-mtune=i486' '-march=i486'
/home/cryolite/local/libexec/gcc/i486-linux-gnu/4.5.0/cc1plus -fpreprocessed
main.ii -quiet -dumpbase main.cpp -mtune=i486 -march=i486 -auxbase main
-std=c++0x -version -o main.s
GNU C++ (GCC) version 4.5.0 (i486-linux-gnu)
compiled by GNU C version 4.5.0, GMP version 4.3.1, MPFR version
2.4.1-p2, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=81 --param ggc-min-heapsize=95967
GNU C++ (GCC) version 4.5.0 (i486-linux-gnu)
compiled by GNU C version 4.5.0, GMP version 4.3.1, MPFR version
2.4.1-p2, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=81 --param ggc-min-heapsize=95967
Compiler executable checksum: f3cfa96cf9dcd630b91f4110d3b8b2b3
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++0x' '-shared-libgcc'
'-mtune=i486' '-march=i486'
as -V -Qy --32 -o main.o main.s
GNU assembler version 2.20 (i486-linux-gnu) using BFD version (GNU Binutils for
Ubuntu) 2.20
COMPILER_PATH=/home/cryolite/local/libexec/gcc/i486-linux-gnu/4.5.0/:/home/cryolite/local/libexec/gcc/i486-linux-gnu/4.5.0/:/home/cryolite/local/libexec/gcc/i486-linux-gnu/:/home/cryolite/local/lib/gcc/i486-linux-gnu/4.5.0/:/home/cryolite/local/lib/gcc/i486-linux-gnu/
LIBRARY_PATH=/home/cryolite/local/lib/:/home/cryolite/local/lib/gcc/i486-linux-gnu/4.5.0/:/home/cryolite/local/lib/gcc/i486-linux-gnu/4.5.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++0x' '-shared-libgcc'
'-mtune=i486' '-march=i486'
/home/cryolite/local/libexec/gcc/i486-linux-gnu/4.5.0/collect2 --eh-frame-hdr
-m elf_i386 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o /usr/lib/crti.o
/home/cryolite/local/lib/gcc/i486-linux-gnu/4.5.0/crtbegin.o
-L/home/cryolite/local/lib -L/home/cryolite/local/lib/gcc/i486-linux-gnu/4.5.0
-L/home/cryolite/local/lib/gcc/i486-linux-gnu/4.5.0/../../.. main.o -lstdc++
-lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
/home/cryolite/local/lib/gcc/i486-linux-gnu/4.5.0/crtend.o /usr/lib/crtn.o
cryol...@thinblue:~/work/gcc_bug/move_on_tribially_copy_constructible$ cat
main.ii
# 1 main.cpp
# 1 built-in
# 1 command-line
# 1 main.cpp
# 1 /home/cryolite/local/lib/gcc/i486-linux-gnu/4.5.0/include/c++/cassert 1 3
# 43 /home/cryolite/local/lib/gcc/i486-linux-gnu/4.5.0/include/c++/cassert 3
# 44 /home/cryolite/local/lib/gcc/i486-linux-gnu/4.5.0/include/c++/cassert 3
# 1 /usr/include/assert.h 1 3 4
# 37 /usr/include/assert.h 3 4
# 1 /usr/include/features.h 1 3 4
# 313 /usr/include/features.h 3 4
# 1 /usr/include/bits/predefs.h 1 3 4
# 314 /usr/include/features.h 2 3 4
# 346 /usr/include/features.h 3 4
# 1 /usr/include/sys/cdefs.h 1 3 4
# 353 /usr/include/sys/cdefs.h 3 4
# 1 /usr/include/bits/wordsize.h 1 3 4
# 354 /usr/include/sys/cdefs.h 2 3 4
# 347 /usr/include/features.h 2 3 4
# 378 /usr/include/features.h 3 4
# 1 /usr/include/gnu/stubs.h 1 3 4
# 1 /usr/include/bits/wordsize.h 1 3 4
# 5 /usr/include/gnu/stubs.h 2 3 4
# 1 /usr/include/gnu/stubs-32.h 1 3 4
# 8 /usr/include/gnu/stubs.h 2 3 4
# 379 /usr/include/features.h 2 3 4
# 38 /usr/include/assert.h 2 3 4
# 68 /usr/include/assert.h 3 4
extern C {
extern void __assert_fail (__const char *__assertion, __const char *__file,
unsigned int __line,
[Bug testsuite/44159] New: CPU options cause testsuite failures
On x86_64-w64-mingw32 targets, during tests such as avx-vaddpd-1.c, the testsuite fails. This seems to be due to the fact that the test function is inlined into main. Due to this inlining, some of the the xmm registers are saved and restored. However, because the -mavx flag is passed, the register saves are performed using instructions not available on the CPU. In other words, the register save/restore is performed before the __cpuid function is called to determine whether the test is supported on the machine that is running the test. This is hit-and-miss and is problematic on any tests that require unsupported registry saves on this target type. -- Summary: CPU options cause testsuite failures Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dougsemler at gmail dot com GCC target triplet: x86_64-w64-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44159
[Bug testsuite/44159] CPU options cause testsuite failures
--- Comment #1 from dougsemler at gmail dot com 2010-05-16 14:23 --- Created an attachment (id=20672) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20672action=view) Assembly that shows unsupported registry saves This assembly is made from: /opt/build/x86_64-pc-linux/x86_64-w64-mingw32/gcc/gcc/xgcc -B/opt/build/x86_64-pc-linux/x86_64-w64-mingw32/gcc/gcc/ /opt/src/repos/gcc.git/gcc/testsuite/gcc.target/i386/avx-vaddpd-1.c -O2 -mavx -lm -o ./avx-vaddpd-1.exe during a test suite run. As can be seen, the vmovdqa instruction is used to save the registers xmm6,7, and 8 prior to the __cpuid test...which is not available on my core2 duo. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44159
[Bug bootstrap/44146] r159371 breaks bootstrap on x86_64-apple-darwin10
--- Comment #18 from iains at gcc dot gnu dot org 2010-05-16 14:26 --- (In reply to comment #13) (In reply to comment #12) that doesn't really explain why this should be repeatably affected by the reversion of 159371.. Yesterday (on an initially failing bootstrap) I applied the suggestion @ comment #2 and the problem cleared. However, I then removed this change and the problem still cleared. the next time this happens to any of the interested parties: could you try make clean-target-libstdc++-v3 make options you usually use all-target -- and see if the phenomenon is essentially randomly dependent on the layout of the code? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44146
[Bug fortran/42647] Missed initialization/dealloc of allocatable scalar DT with allocatable component
--- Comment #9 from dominiq at lps dot ens dot fr 2010-05-16 14:40 --- (In reply to comment #8) This is fixed by this patchlet (which is part of patch in comment #1): This patch breaks gfortran.dg/allocatable_scalar_9.f90 (Segmentation fault) and some variants I have in my tests. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42647
[Bug c++/44160] New: [C++0x]a mysterious error on __func__ in a lambda expression
The following code causes a mysterious error.
__FUNCTION__ and __PRETTY_FUNCTION__ cause the same problem as __func__, too.
cryol...@thinblue:~/work/gcc_bug/func_in_lambda$ g++-4.5.0 -v -save-temps
-std=c++0x main.cpp
Using built-in specs.
COLLECT_GCC=g++-4.5.0
COLLECT_LTO_WRAPPER=/home/cryolite/local/libexec/gcc/i486-linux-gnu/4.5.0/lto-wrapper
Target: i486-linux-gnu
Configured with: ../gcc-4.5.0/configure --build=i486-linux-gnu
--prefix=/home/cryolite/local --program-suffix=-4.5.0
--enable-version-specific-runtime-libs --enable-languages=c,c++
Thread model: posix
gcc version 4.5.0 (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++0x' '-shared-libgcc'
'-mtune=i486' '-march=i486'
/home/cryolite/local/libexec/gcc/i486-linux-gnu/4.5.0/cc1plus -E -quiet -v
-D_GNU_SOURCE main.cpp -mtune=i486 -march=i486 -std=c++0x -fpch-preprocess -o
main.ii
ignoring duplicate directory /home/cryolite/local/include
ignoring nonexistent directory
/home/cryolite/local/lib/gcc/i486-linux-gnu/4.5.0/../../../../i486-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/home/cryolite/local/include
/home/cryolite/local/lib/gcc/i486-linux-gnu/4.5.0/include/c++
/home/cryolite/local/lib/gcc/i486-linux-gnu/4.5.0/include/c++/i486-linux-gnu
/home/cryolite/local/lib/gcc/i486-linux-gnu/4.5.0/include/c++/backward
/usr/local/include
/home/cryolite/local/lib/gcc/i486-linux-gnu/4.5.0/include
/home/cryolite/local/lib/gcc/i486-linux-gnu/4.5.0/include-fixed
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++0x' '-shared-libgcc'
'-mtune=i486' '-march=i486'
/home/cryolite/local/libexec/gcc/i486-linux-gnu/4.5.0/cc1plus -fpreprocessed
main.ii -quiet -dumpbase main.cpp -mtune=i486 -march=i486 -auxbase main
-std=c++0x -version -o main.s
GNU C++ (GCC) version 4.5.0 (i486-linux-gnu)
compiled by GNU C version 4.5.0, GMP version 4.3.1, MPFR version
2.4.1-p2, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=81 --param ggc-min-heapsize=95967
GNU C++ (GCC) version 4.5.0 (i486-linux-gnu)
compiled by GNU C version 4.5.0, GMP version 4.3.1, MPFR version
2.4.1-p2, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=81 --param ggc-min-heapsize=95967
Compiler executable checksum: f3cfa96cf9dcd630b91f4110d3b8b2b3
cc1plus: error: declaration of 'const char __func__ [5]'
main.cpp:3:17: error: conflicts with previous declaration 'const char __func__
[11]'
cryol...@thinblue:~/work/gcc_bug/func_in_lambda$ cat main.ii
# 1 main.cpp
# 1 built-in
# 1 command-line
# 1 main.cpp
int main()
{
[]() { return __func__; };
__func__;
}
--
Summary: [C++0x]a mysterious error on __func__ in a lambda
expression
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ai dot azuma at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44160
[Bug bootstrap/44146] r159371 breaks bootstrap on x86_64-apple-darwin10
--- Comment #19 from hubicka at ucw dot cz 2010-05-16 15:00 --- Subject: Re: r159371 breaks bootstrap on x86_64-apple-darwin10 --- Comment #17 from iains at gcc dot gnu dot org 2010-05-16 13:51 --- (In reply to comment #16) leaving off the eh and debug stuff look at .text __ZN12_GLOBAL__N_110get_globalEv: LFB100: pushq %rbp LCFI0: movq%rsp, %rbp LCFI1: reference a variable relative to the instruction pointer is this intended?? seems doomed to fail at some point leaq___emutls_v._ZZN12_GLOBAL__N_110get_globalEvE6global(%rip), %rdi well, clearly, it's intended - non-emutls code does the same thing (when compiled m64). However, the point remains that a 32bit offset is going to fail to reach variables as soon as the total space occupied 4Gb it seems maybe we have a code-gen problem ? Well, you know that emults will be bound withtin the same DSO, so you are safe. This is small PIC model. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44146
[Bug bootstrap/44146] r159371 breaks bootstrap on x86_64-apple-darwin10
--- Comment #20 from iains at gcc dot gnu dot org 2010-05-16 15:15 --- (In reply to comment #19) Subject: Re: r159371 breaks bootstrap on x86_64-apple-darwin10 --- Comment #17 from iains at gcc dot gnu dot org 2010-05-16 13:51 --- (In reply to comment #16) leaving off the eh and debug stuff look at .text __ZN12_GLOBAL__N_110get_globalEv: LFB100: pushq %rbp LCFI0: movq%rsp, %rbp LCFI1: reference a variable relative to the instruction pointer is this intended?? seems doomed to fail at some point leaq ___emutls_v._ZZN12_GLOBAL__N_110get_globalEvE6global(%rip), %rdi well, clearly, it's intended - non-emutls code does the same thing (when compiled m64). However, the point remains that a 32bit offset is going to fail to reach variables as soon as the total space occupied 4Gb it seems maybe we have a code-gen problem ? Well, you know that emults will be bound withtin the same DSO, so you are safe. This is small PIC model. hmmm.. I don't quite understand this.. the original ld error was: ld: codegen problem, can't use rel32 to external symbol ___emutls_v._ZZN12_GLOBAL__N_110get_globalEvE6global in ___cxa_get_globals_fast is the loader not entitled to place .data and .text wherever it likes in the 64bit address space? ... in any event, potentially, further apart than can be reached by a +/- 31 bits. .. what happens when the data size passes 2Gb? (having said that - I agree that it doesn't make a lot of sense to see this failure when building libstdc++ ...) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44146
[Bug fortran/44156] dot_product / matmul and signed zeros
--- Comment #1 from kargl at gcc dot gnu dot org 2010-05-16 16:19 ---
The generated code is fine. The F2003 standard states on page 38.
The real type includes a zero value. Processors that distinguish between
positive and negative zeros shall treat them as equivalent
(1) in all relational operations,
(2) as actual arguments to intrinsic procedures other than those
for which it is explicitly specified that negative zero is
distinguished, and
MATMAL and DOT_PRODUCT are not in the list that (2) applies to.
Remove wrong-code keyword.
Change Severity to enhancement, because might try to argue that this
is a Quality of Implementation issue. I'll leave it to Thomas to
decide whether to close as WONTFIX.
PS: DOT_PRODUCT is in-lined. -ftree-dump-original shows
val.2 = 0.0;
{
integer(kind=4) S.3;
S.3 = 1;
while (1)
{
if (S.3 1) goto L.1;
val.2 = a[S.3 + -1] * b[S.3 + -1] + val.2;
S.3 = S.3 + 1;
}
L.1:;
}
D.1505 = val.2;
Even if a[S.3 + -1] * b[S.3 + -1] = -0. The accumulation of the
sum -0 + 0 in the above will result in 0 (without the sign).
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
Severity|minor |enhancement
Keywords|wrong-code |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44156
[Bug c++/44158] [C++0x] wrong overload resolution for copy-initialization from an rvalue
--- Comment #1 from redi at gcc dot gnu dot org 2010-05-16 17:07 --- The rules say that for copy-initialization where the source type (X) is not the same as the destination type (X) a temporary is created. That temporary is copy-constructed from x, then y is move-constructed from the temporary. To avoid the temporary use direct-initialization; Y y( static_castX(x) ); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44158
[Bug c++/44158] [C++0x] wrong overload resolution for copy-initialization from an rvalue
--- Comment #2 from redi at gcc dot gnu dot org 2010-05-16 17:08 --- (In reply to comment #1) Y y( static_castX(x) ); ^ Oops. I meant X not Y -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44158
[Bug bootstrap/44146] r159371 breaks bootstrap on x86_64-apple-darwin10
--- Comment #21 from hubicka at ucw dot cz 2010-05-16 17:22 --- Subject: Re: r159371 breaks bootstrap on x86_64-apple-darwin10 hmmm.. I don't quite understand this.. the original ld error was: ld: codegen problem, can't use rel32 to external symbol ___emutls_v._ZZN12_GLOBAL__N_110get_globalEvE6global in ___cxa_get_globals_fast is the loader not entitled to place .data and .text wherever it likes in the 64bit address space? ... in any event, potentially, further apart than can be reached by a +/- 31 bits. .. what happens when the data size passes 2Gb? There -mcmodel=small/medium/large flag to control this. By default compiler assume that your binary is smaller than 2GB. For PIC we make same assumption and we require loader to keep code and data section together to make RIP relative addressing work. Otherwise it would be of no use ;) Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44146
[Bug libstdc++/40974] cannot build gcc-4.4.1: fenv_t has not been declared
--- Comment #29 from rwild at gcc dot gnu dot org 2010-05-16 17:32 --- (In reply to comment #27) You mean the patch in Comment # 20? Because it seems an hack to me. Maybe Ralf is willing to explain why is the only possible fix. Oh, I don't think it's the only possible fix, it's merely the only patch I came up with. Off-hand, I don't see what else to do though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974
[Bug target/44161] New: __attribute__((__target__)) resets pic flag causing spurious warnings
In some cases, __attribute__((__target__(...))) causes spurious warnings about -fpic not being supported on the target.It seems at some point flag_pic may be reset, even though the option is not passed via the command line. These spurious warnings cause testsuite/gcc.target/i386/funcspec-4.c and funcspec-8.c to fail, while other tests succeed even with the warning. -- Summary: __attribute__((__target__)) resets pic flag causing spurious warnings Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dougsemler at gmail dot com GCC target triplet: x86_64-w64-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44161
[Bug target/44161] __attribute__((__target__)) resets pic flag causing spurious warnings
--- Comment #1 from dougsemler at gmail dot com 2010-05-16 17:40 --- Created an attachment (id=20673) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20673action=view) Test failure example Testsuite i386.exp=func-spec*.c Shows test failures in -4 and -8 due to excess warnings. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44161
[Bug target/44161] __attribute__((__target__)) resets pic flag causing spurious warnings
--- Comment #2 from dougsemler at gmail dot com 2010-05-16 17:42 --- Created an attachment (id=20674) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20674action=view) Test success example Runtest with the warning removed from config/i386/cygming.h Shows that the tests will succeed with the warning (that I believe is spurious) not printed (but with the flag_pic still reset in the config .h file) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44161
[Bug c++/44158] [C++0x] wrong overload resolution for copy-initialization from an rvalue
--- Comment #3 from paolo dot carlini at oracle dot com 2010-05-16 18:29 --- This is invalid then. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44158
[Bug lto/44149] lto1: internal compiler error: in lto_symtab_merge_decls_1, at lto-symtab.c:610
--- Comment #2 from toon at moene dot org 2010-05-16 18:35 --- Created an attachment (id=20675) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20675action=view) reduced test case A reduced test case that failes in the same way. -- toon at moene dot org changed: What|Removed |Added Attachment #20664|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44149
[Bug lto/44149] lto1: internal compiler error: in lto_symtab_merge_decls_1, at lto-symtab.c:610
--- Comment #3 from toon at moene dot org 2010-05-16 18:51 ---
It might be useful to compare the two decls that invoke the mismatch that
triggers the gcc_assert:
prevailing-decl is:
function_decl 0x7fb0f574f900 convect_satmixratio
type function_type 0x7fb0f5786b28
type void_type 0x7fb0f584cd20 VOID
align 8 symtab 0 alias set -1 canonical type 0x7fb0f584cd20
pointer_to_this pointer_type 0x7fb0f584cdc8
QI
size integer_cst 0x7fb0f583d758 constant 8
unit size integer_cst 0x7fb0f583d780 constant 1
align 8 symtab 0 alias set -1 canonical type 0x7fb0f5786b28
public external QI file bkfconv.f90 line 517 col 0 align 8
whereas e-decl is:
function_decl 0x7fb0f574f600 convect_satmixratio
type function_type 0x7fb0f5763b28
type void_type 0x7fb0f584cd20 VOID
align 8 symtab 0 alias set -1 canonical type 0x7fb0f584cd20
pointer_to_this pointer_type 0x7fb0f584cdc8
QI
size integer_cst 0x7fb0f583d758 constant 8
unit size integer_cst 0x7fb0f583d780 constant 1
align 8 symtab 0 alias set -1 canonical type 0x7fb0f5763b28
arg-types tree_list 0x7fb0f5754bb8 value reference_type
0x7fb0f5750738
chain tree_list 0x7fb0f5754be0 value pointer_type 0x7fb0f5763bd0
chain tree_list 0x7fb0f5754c08 value pointer_type
0x7fb0f5764000
chain tree_list 0x7fb0f5754c30 value pointer_type
0x7fb0f57643f0
chain tree_list 0x7fb0f5754c58 value pointer_type
0x7fb0f57647e0 chain tree_list 0x7fb0f5754c80
nothrow public static QI file bkfconv.f90 line 400 col 0 align 8
arguments parm_decl 0x7fb0f5760660 klon
type reference_type 0x7fb0f5750738 type integer_type 0x7fb0f584c498
unsigned restrict DI
size integer_cst 0x7fb0f583da50 constant 64
unit size integer_cst 0x7fb0f583da78 constant 8
align 64 symtab 0 alias set -1 canonical type 0x7fb0f5750738
readonly used unsigned DI passed-by-reference file bkfconv.f90 line 400
col 0 size integer_cst 0x7fb0f583da50 64 unit size integer_cst
0x7fb0f583da78 8
align 64 context function_decl 0x7fb0f574f600 convect_satmixratio
arg-type reference_type 0x7fb0f5750738
chain parm_decl 0x7fb0f57606e8 ppres type pointer_type
0x7fb0f57653f0
readonly used unsigned DI passed-by-reference file bkfconv.f90 line
400 col 0 size integer_cst 0x7fb0f583da50 64 unit size integer_cst
0x7fb0f583da78 8
align 64 context function_decl 0x7fb0f574f600 convect_satmixratio
arg-type pointer_type 0x7fb0f5763bd0 chain parm_decl 0x7fb0f5760770 pt
result result_decl 0x7fb0f5752180 D.2157 type void_type 0x7fb0f584cd20
ignored VOID file bkfconv.f90 line 400 col 0
align 8 context function_decl 0x7fb0f574f600 convect_satmixratio
This is found by adding the following to lto-symtab.c:
$ svn diff
Index: lto-symtab.c
===
--- lto-symtab.c(revision 159454)
+++ lto-symtab.c(working copy)
@@ -603,8 +603,15 @@
/* Assert it's the only one. */
if (prevailing)
for (e = prevailing-next; e; e = e-next)
- gcc_assert (e-resolution != LDPR_PREVAILING_DEF_IRONLY
- e-resolution != LDPR_PREVAILING_DEF);
+ {
+ if (!(e-resolution != LDPR_PREVAILING_DEF_IRONLY
+ e-resolution != LDPR_PREVAILING_DEF))
+{
+ debug_tree(prevailing-decl);
+ debug_tree(e-decl);
+ gcc_assert(0);
+}
+ }
/* If there's not a prevailing symbol yet it's an external reference.
Happens a lot during ltrans. Choose the first symbol with a
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44149
[Bug fortran/44156] dot_product / matmul and signed zeros
--- Comment #2 from tkoenig at netcologne dot de 2010-05-16 19:03 --- Subject: Re: dot_product / matmul and signed zeros kargl at gcc dot gnu dot org wrote: The generated code is fine. The F2003 standard states on page 38. The real type includes a zero value. Processors that distinguish between positive and negative zeros shall treat them as equivalent (1) in all relational operations, (2) as actual arguments to intrinsic procedures other than those for which it is explicitly specified that negative zero is distinguished, and MATMAL and DOT_PRODUCT are not in the list that (2) applies to. In this case, the negative zero is the _result_; it is not passed as an argument (what's being passed are 0.0 and -1.0, respectively). So, this looks like a question for c.l.f. And yes, there are bugs that are more severe than this ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44156
[Bug c++/44158] [C++0x] wrong overload resolution for copy-initialization from an rvalue
--- Comment #4 from redi at gcc dot gnu dot org 2010-05-16 19:34 --- it might be a valid enhancement request, as I think the temporary is eligible for copy-elision (Jason?) but the compiler isn't required to elide it, so it is wrong to assert that a temporary won't be created -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44158
[Bug libgcj/42986] natVMSecureRandom.cc error: expected type-specifier
--- Comment #3 from cestrauss at gmail dot com 2010-05-16 20:00 --- I can confirm this mingw32 libgcj build failure exists on current trunk (4.6.0 revision 159436). The original patch attached to this report does solve the issue for me, after updating it so it applies cleanly. Regards, Cesar -- cestrauss at gmail dot com changed: What|Removed |Added CC||cestrauss at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42986
[Bug fortran/35779] error pointer wrong in PARAMETER
--- Comment #9 from dfranke at gcc dot gnu dot org 2010-05-16 20:01 --- Subject: Bug 35779 Author: dfranke Date: Sun May 16 20:01:06 2010 New Revision: 159465 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159465 Log: gcc/fortran/: 2010-05-16 Daniel Franke franke.dan...@gmail.com PR fortran/35779 * array.c (match_array_list): Revert functional change of 2010-05-13. gcc/fortran/: 2010-05-16 Daniel Franke franke.dan...@gmail.com PR fortran/35779 * gfortran.dg/initialization_25.f90: Commented testcase. * gfortran.dg/initialization_26.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/initialization_26.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/array.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/initialization_25.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35779
[Bug fortran/35779] error pointer wrong in PARAMETER
--- Comment #10 from dfranke at gcc dot gnu dot org 2010-05-16 20:03 --- (In reply to comment #9) 2010-05-16 Daniel Franke franke.dan...@gmail.com PR fortran/35779 * array.c (match_array_list): Revert functional change of 2010-05-13. Back to square one. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35779
[Bug fortran/35779] error pointer wrong in PARAMETER
--- Comment #11 from dfranke at gcc dot gnu dot org 2010-05-16 20:05 --- Relevant ML discussion starts here: http://gcc.gnu.org/ml/fortran/2010-05/msg00165.html Unassigning myself. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|dfranke at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|REOPENED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35779
[Bug fortran/44156] dot_product / matmul and signed zeros
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-05-16 20:17 ---
The simplifiers show the same behaviour:
$ cat pr44156.f90
program main
implicit none
real, dimension(1), parameter :: a = -1.0, b = 0.0
real, dimension(1,1), parameter :: aa = -1.0, bb = 0.0
real, dimension(1), parameter :: c = dot_product(a,b)
real, dimension(1,1), parameter :: d = matmul(aa, bb)
real, parameter :: e = a(1) * b(1)
print *, c, d, e
end program main
$ gfortran-svn -Wall -W pr44156.f90 ./a.out
0.000 0.000 -0.000
The dump has:
MAIN__ ()
{
static real(kind=4) c[1] = {};
static real(kind=4) d[1] = {0.0};
[writes snipped]
{
static real(kind=4) C.1525 = -0.0;
_gfortran_transfer_real (dt_parm.0, C.1525, 4);
}
}
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
CC||dfranke at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44156
[Bug fortran/44155] gfortran segmentation fault using iso_c_binding
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-05-16 20:24 --- *** This bug has been marked as a duplicate of 40963 *** -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44155
[Bug fortran/40963] ICE segfault - c_loc with derived type component as argument
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-05-16 20:24 --- *** Bug 44155 has been marked as a duplicate of this bug. *** -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||whalen at cray dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40963
[Bug fortran/43896] [OOP] ICE in gfc_conv_variable, at fortran/trans-expr.c:551
--- Comment #18 from janus at gcc dot gnu dot org 2010-05-16 20:33 --- (In reply to comment #17) So it seems tht the bug is not gone. I have tried again with version from May 8th and I still get the problem on line 556. Yes, the issue is not fixed yet. The commit in comment #16 was just the merging of the fortran-dev branch to trunk, which did nothing about the ICE. We'll take care of this soon ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43896
[Bug middle-end/44133] [4.5/4.6 Regression] Uninit warning regression with new SRA
--- Comment #2 from jamborm at gcc dot gnu dot org 2010-05-16 21:09 --- Patch posted to the mailing list: http://gcc.gnu.org/ml/gcc-patches/2010-05/msg01209.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44133
[Bug c++/44158] [C++0x] wrong overload resolution for copy-initialization from an rvalue
--- Comment #5 from paolo dot carlini at oracle dot com 2010-05-16 21:25
---
To be safe, let's reopen the bug. For the record, this works:
#include cassert
struct X
{
X(int i) : i_(i) {}
X(X x) : i_(x.i_) { x.i_ = 0; }
int i_;
X(const X) = delete;
};
int main()
{
X x(42);
X y = static_castX(x);
assert( y.i_ == 42 );
assert( x.i_ == 0 );
}
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44158
[Bug c++/44162] New: cannot match function ref argument to dependent std::enable_if::type
Given some function
void ff(); // any signature
This function is callable:
void rcv_f( typename std::enable_if true, decltype(ff) ::type const f ) {}
This function template does not produce a candidate:
template class F
void rcv_f( typename std::enable_if true, F ::type const f ) {}
This function template prints two identical lines:
template class F
void rcv_f( F const f ) {
std::cerr typeid( typename std::enable_if true, F ::type ).name()
std::endl;
std::cerr typeid( F ).name() std::endl;
}
The problem does not occur with functors. The first example still works if
trivially made into a template, so the dependent argument matters rather than
the dependent context.
--
Summary: cannot match function ref argument to dependent
std::enable_if::type
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: potswa at mac dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44162
[Bug fortran/43990] [OOP] ICE in output_constructor_regular_field, at varasm.c:4995
--- Comment #5 from janus at gcc dot gnu dot org 2010-05-16 22:11 ---
The ICE is fixed by removing this unneeded (and buggy) piece of code:
Index: gcc/fortran/trans-expr.c
===
--- gcc/fortran/trans-expr.c(revision 159444)
+++ gcc/fortran/trans-expr.c(working copy)
@@ -4337,21 +4337,8 @@ gfc_conv_structure (gfc_se * se, gfc_expr * expr,
if (!c-expr || cm-attr.allocatable)
continue;
- if (cm-ts.type == BT_CLASS !cm-attr.proc_pointer)
+ if (strcmp (cm-name, $size) == 0)
{
- gfc_component *data;
- data = gfc_find_component (cm-ts.u.derived, $data, true, true);
- if (!data-backend_decl)
- gfc_get_derived_type (cm-ts.u.derived);
- val = gfc_conv_initializer (c-expr, cm-ts,
- TREE_TYPE (data-backend_decl),
- data-attr.dimension,
- data-attr.pointer);
-
- CONSTRUCTOR_APPEND_ELT (v, data-backend_decl, val);
- }
- else if (strcmp (cm-name, $size) == 0)
- {
val = TYPE_SIZE_UNIT (gfc_get_derived_type (cm-ts.u.derived));
CONSTRUCTOR_APPEND_ELT (v, cm-backend_decl, val);
}
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org
|dot org |
Status|NEW |ASSIGNED
Last reconfirmed|2010-05-05 14:12:54 |2010-05-16 22:11:03
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43990
[Bug c++/44162] [C++0x] cannot match function ref argument to dependent std::enable_if::type
--- Comment #1 from paolo dot carlini at oracle dot com 2010-05-16 22:17 --- Please provide a short self-contained testcase, thanks. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING Summary|cannot match function ref |[C++0x] cannot match |argument to dependent |function ref argument to |std::enable_if::type|dependent ||std::enable_if::type http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44162
[Bug c++/44158] [C++0x] wrong overload resolution for copy-initialization from an rvalue
--- Comment #6 from jason at gcc dot gnu dot org 2010-05-16 22:32 --- (In reply to comment #1) The rules say that for copy-initialization where the source type (X) is not the same as the destination type (X) a temporary is created. But the source type is X; there are no expressions of reference type. The problem is not the overload resolution, but that build_over_call looks at TYPE_HAS_COMPLEX_INIT_REF even though we're dealing with the move ctor, not the copy ctor. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-16 22:32:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44158
[Bug c++/44158] [C++0x] wrong overload resolution for copy-initialization from an rvalue
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-05-16 22:32:43 |2010-05-16 23:21:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44158
[Bug bootstrap/39150] Configure scripts have no 64-Bit Solaris defined (only i386-solaris*).
--- Comment #15 from rob1weld at aol dot com 2010-05-17 02:34 --- (In reply to comment #13) Subject: Re: Configure scripts have no 64-Bit Solaris defined (only i386-solaris*). --- Comment #12 from rob1weld at aol dot com 2010-05-04 07:20 --- This is an Enhancement (EG: I wish (someday in the future) that we had this feature) and I would have preferred it remain open ... But what's the *point* of having such a configuration, except as a prove of `we can do that'? Any actual problem that would be solved this way? Rainer (In reply to comment #13) Same as on Linux: the compiler will be faster and able to handle more memory. OpenSolaris is 64 Bit; it's ability to run on older Hardware is a convenience, not a requirement. Similarly gcc could output 80286 / 80387 code ONLY, for Intel Platforms, as that would be easier also ... Support for both modes (and more to come) is not so much proof we can do that as it is the normal thing (compared to other Platforms) to do. The inability of the Build Mechanism to operate in a similar manner (logic) as it does on Linux is support of a third way of building gcc rather than proof that doing it one way is easier. OpenSolaris recently added support for the ARM Processor, so that adds a few more 'multi-lib modes' that need to be supported, along with the expanded line of SPARC Processors now being supported. The OpenSolaris Group also has a 'call for Ports', so in theory our mechanism _must_ be general enough to support any possible Processor (in the future, you don't need to do everything today!). I would be more than happy to request from Oracle a gcc Team be created and dispatched here. The result of a successful request _might_ be a tiny Team of experts (OS Design / Compiler Writers) that would assist with Testing, Patching, Solaris Expertise, and bring with them an assignment to a share of the Server Farm. They have such a Liaison for most larger Programs and supported Hardware. I can foresee one or two getting assigned and a half dozen or so volunteer when they hear of your hardship (... rather the time it takes to analyze and fix problems. This is practically doubled if you have two different configurations to test, and I simply cannot afford that ...). Do one of you wish to ask or shall I ? (Note: It might take 3-6 months to get approved as some may be paid; so lets get started). Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39150
[Bug c++/44157] [C++0x] GCC wrongly takes a std::initializer_list argument as non-deduced context
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-17 04:09:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44157
