[Bug target/38306] [4.4/4.5 Regression] 15% slowdown w.r.t. 4.3 of computational kernel on some architectures
--- Comment #14 from jv244 at cam dot ac dot uk 2009-09-01 06:56 --- I wanted to try Vladimir Makarov's new patch for this testcase, but on an unpatched trunk I notice a serious runtime regression with '-fschedule-insns' with respect to 4.3.3 Using as base options (for the attached testcase) gfortran -O3 -march=native -funroll-loops -ffast-math test.f90 4.3.3 w -fschedule-insns : 3.372s 4.3.3 w/o -fschedule-insns : 4.384s 4.4.2 w -fschedule-insns : 4.748s 4.4.2 w/o -fschedule-insns : 4.408s 4.5.0 w -fschedule-insns : 4.712s 4.5.0 w/o -fschedule-insns : 4.408s so 4.3 against 4.5 'w -fschedule-insns' is about 40% faster. I guess this is pretty target specific, I'm running this on an Opteron, this is what -v reports: Target: x86_64-unknown-linux-gnu Configured with: /data03/vondele/gcc_trunk/gcc/configure --disable-bootstrap --prefix=/data03/vondele/gcc_trunk/build --enable-languages=c,c++,fortran --disable-multilib --with-ppl=/data03/vondele/gcc_trunk/build/ --with-cloog=/data03/vondele/gcc_trunk/build/ Thread model: posix gcc version 4.5.0 20090830 (experimental) [trunk revision 151229] (GCC) COLLECT_GCC_OPTIONS='-O3' '-funroll-loops' '-ffast-math' '-fschedule-insns' '-v' '-shared-libgcc' /data03/vondele/gcc_trunk/build/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/f951 test.f90 -march=k8-sse3 -mcx16 -msahf --param l1-cache-size=64 --param l1-cache-line-size=64 --param l2-cache-size=1024 -mtune=k8 -quiet -dumpbase test.f90 -auxbase test -O3 -version -funroll-loops -ffast-math -fschedule-insns -fintrinsic-modules-path /data03/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/finclude -o /tmp/ccvGq2CO.s -- jv244 at cam dot ac dot uk changed: What|Removed |Added CC||vmakarov at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38306
[Bug bootstrap/41205] [4.5 Regression] Bootstrap broken on i686-apple-darwin9 by revision 151249
-- dodji at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-09-01 07:00:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41205
[Bug bootstrap/41205] [4.5 Regression] Bootstrap broken on i686-apple-darwin9 by revision 151249
--- Comment #2 from dodji at gcc dot gnu dot org 2009-09-01 07:01 --- Created an attachment (id=18459) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18459action=view) Obvious fix candidate Could you please test this patch on darwin and see if it fixes bootstrap for you ? I am sorry I don't have any darwin system at hand to test. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41205
[Bug c/41203] -mtune=pentium2 structure related tree-outof-ssa internal compiler error
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-09-01 08:16 --- Works for me on a i686 host with current trunk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41203
[Bug bootstrap/41205] [4.5 Regression] Bootstrap broken on i686-apple-darwin9 by revision 151249
--- Comment #3 from dodji at gcc dot gnu dot org 2009-09-01 08:46 --- Subject: Bug 41205 Author: dodji Date: Tue Sep 1 08:45:38 2009 New Revision: 151262 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151262 Log: Fix bootstrap after patch PR debug/30161 gcc/ChangeLog: PR bootstrap/41205 Fix AIX bootstrap after PR debug/30161 * dwarf2out.c (make_ith_pack_parameter_name): Don't used strnlen that is a GNU extension. (tmpl_value_parm_die_table): Move the definition of this global outside #ifdef DWARF2_DEBUGGING_INFO region. gcc/cp/ChangeLog: PR bootstrap/41205 * pt.c (make_ith_pack_parameter_name): Don't use strnlen that is a GNU extension. Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/dwarf2out.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41205
[Bug debug/30161] GCC should generate dwarf info about template parameters
--- Comment #10 from dodji at gcc dot gnu dot org 2009-09-01 08:46 --- Subject: Bug 30161 Author: dodji Date: Tue Sep 1 08:45:38 2009 New Revision: 151262 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151262 Log: Fix bootstrap after patch PR debug/30161 gcc/ChangeLog: PR bootstrap/41205 Fix AIX bootstrap after PR debug/30161 * dwarf2out.c (make_ith_pack_parameter_name): Don't used strnlen that is a GNU extension. (tmpl_value_parm_die_table): Move the definition of this global outside #ifdef DWARF2_DEBUGGING_INFO region. gcc/cp/ChangeLog: PR bootstrap/41205 * pt.c (make_ith_pack_parameter_name): Don't use strnlen that is a GNU extension. Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/dwarf2out.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30161
[Bug target/38306] [4.4/4.5 Regression] 15% slowdown w.r.t. 4.3 of computational kernel on some architectures
--- Comment #15 from bonzini at gnu dot org 2009-09-01 08:54 --- Please try -O2 and -O2 -funroll-loops too, since -O3 is not always good for speed. (It would be even better if -O2 is not slower and you can find out what the culprit is at -O3; this is not necessarily possible though). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38306
[Bug bootstrap/41205] [4.5 Regression] Bootstrap broken on i686-apple-darwin9 by revision 151249
--- Comment #4 from dodji at gcc dot gnu dot org 2009-09-01 08:55 --- Fixed in trunk. -- dodji at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41205
[Bug c++/41207] New: The resulting 64-bit binary doesn't get recognized as proper binary by windows vista x64
x86_64-w64-mingw32-g++ produce binary will not run. Runtime : libqt4_plugin.dll' (%1 is not a valid Win32 application. (error 193)) plugins/libqt4_plugin.dll: file format pei-x86-64 Disassembly of section .text: 68e81000 _pre_c_init: 68e81000: 53 push %rbx 68e81001: b9 00 01 00 00 mov$0x100,%ecx 68e81006: 48 83 ec 20 sub$0x20,%rsp 68e8100a: e8 01 16 71 00 callq 69592610 _malloc 68e8100f: 48 89 c3mov%rax,%rbx 68e81012: 48 89 c1mov%rax,%rcx 68e81015: e8 f6 7f 6f 00 callq 69579010 __encode_pointer 68e8101a: 48 85 dbtest %rbx,%rbx 68e8101d: 48 89 05 bc a4 cb 00mov%rax,0xcba4bc(%rip)# 69b3b4e0 ___onexitbegin 68e81024: 48 89 05 c5 a4 cb 00mov%rax,0xcba4c5(%rip)# 69b3b4f0 ___onexitend 68e8102b: b8 01 00 00 00 mov$0x1,%eax 68e81030: 74 09 je 68e8103b _pre_c_init+0x3b 68e81032: 48 c7 03 00 00 00 00movq $0x0,(%rbx) 68e81039: 30 c0 xor%al,%al 68e8103b: 48 83 c4 20 add$0x20,%rsp 68e8103f: 5b pop%rbx 68e81040: c3 retq 68e81041: 66 66 66 66 66 66 2enopw %cs:0x0(%rax,%rax,1) 68e81048: 0f 1f 84 00 00 00 00 68e8104f: 00 68e81050 __CRT_INIT: 68e81050: 41 54 push %r12 68e81052: 55 push %rbp 68e81053: 57 push %rdi 68e81054: 4c 89 c7mov%r8,%rdi 68e81057: 56 push %rsi 68e81058: 53 push %rbx 68e81059: 48 89 cbmov%rcx,%rbx 68e8105c: 48 83 ec 20 sub$0x20,%rsp 68e81060: 85 d2 test %edx,%edx 68e81062: 75 7d jne68e810e1 __CRT_INIT+0x91 68e81064: 8b 15 96 ef ca 00 mov0xcaef96(%rip),%edx# 69b3 __bss_start__ 68e8106a: 31 c0 xor%eax,%eax 68e8106c: 85 d2 test %edx,%edx 68e8106e: 7e 66 jle68e810d6 __CRT_INIT+0x86 68e81070: 83 ea 01sub$0x1,%edx 68e81073: 31 c0 xor%eax,%eax 68e81075: 89 15 85 ef ca 00 mov%edx,0xcaef85(%rip)# 69b3 __bss_start__ 68e8107b: ba 01 00 00 00 mov$0x1,%edx 68e81080: f0 48 0f b1 15 87 a4lock cmpxchg %rdx,0xcba487(%rip) # 69b3b510 ___native_startup_lock 68e81087: cb 00 68e81089: 48 85 c0test %rax,%rax 68e8108c: 74 2a je 68e810b8 __CRT_INIT+0x68 68e8108e: 48 8b 35 6b ec cb 00mov0xcbec6b(%rip),%rsi# 69b3fd00 __imp__Sleep 68e81095: bf 01 00 00 00 mov$0x1,%edi 68e8109a: 31 db xor%ebx,%ebx 68e8109c: 0f 1f 40 00 nopl 0x0(%rax) 68e810a0: b9 e8 03 00 00 mov$0x3e8,%ecx 68e810a5: ff d6 callq *%rsi 68e810a7: 48 89 d8mov%rbx,%rax 68e810aa: f0 48 0f b1 3d 5d a4lock cmpxchg %rdi,0xcba45d(%rip) # 69b3b510 ___native_startup_lock 68e810b1: cb 00 68e810b3: 48 85 c0test %rax,%rax 68e810b6: 75 e8 jne68e810a0 __CRT_INIT+0x50 68e810b8: 8b 05 42 a4 cb 00 mov0xcba442(%rip),%eax# 69b3b500 ___native_startup_state 68e810be: 83 f8 02cmp$0x2,%eax 68e810c1: 0f 84 e9 00 00 00 je 68e811b0 __CRT_INIT+0x160 68e810c7: b9 1f 00 00 00 mov$0x1f,%ecx 68e810cc: e8 47 15 71 00 callq 69592618 __amsg_exit -- Summary: The resulting 64-bit binary doesn't get recognized as proper binary by windows vista x64 Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: t7 at gmail dot com GCC build triplet: x86_64-w64-mingw32 GCC host triplet: x86_64-w64-mingw32 GCC target triplet: x86_64-w64-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41207
[Bug boehm-gc/41208] New: illegal instruction lwsync reported on e500
In running applications on e500, we got illegal instruction error, finally, we found it's caused by asm code below: gcc-4.3.2/boehm-gc/include/private/gc_locks.h __asm__ __volatile__(lwsync: : : memory); lwsync is not supported by e500, even though powerpc claims that. There are similar issues before since __NO_LWSYNC__ has been introduced. it should be modified to use msync or sync in this case. + #ifdef __NO_LWSYNC__ + __asm__ __volatile__(msync: : : memory); + #else __asm__ __volatile__(lwsync: : : memory); + #endif -- Summary: illegal instruction lwsync reported on e500 Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: boehm-gc AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: harry dot he at freescale dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: powerpc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41208
[Bug target/38306] [4.4/4.5 Regression] 15% slowdown w.r.t. 4.3 of computational kernel on some architectures
--- Comment #16 from jv244 at cam dot ac dot uk 2009-09-01 09:13 --- (In reply to comment #15) Please try -O2 and -O2 -funroll-loops too, since -O3 is not always good for speed. (It would be even better if -O2 is not slower and you can find out what the culprit is at -O3; this is not necessarily possible though). you're right that, without -fschedule-insns -O2 is faster than -O3 on this case, but nothing comes close to 4.3 performance. adding '-fschedule-insns' to the fastest -O2 choice makes it 20% slower. All numbers with trunk: -O2 -march=native -funroll-loops -ffast-math: 4.032 -O2 -march=native -funroll-loops -ffast-math -fschedule-insns: 4.712 -O3 -march=native -funroll-loops -ffast-math: 4.408 -O2 -march=native -ffast-math: 11.373 -O2 -march=native -ffast-math -fschedule-insns: 11.409 -O3 -march=native -ffast-math: 4.296 -O3 -march=native -ffast-math -fschedule-insns: 4.656 I can test other flags if you've a hint -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38306
[Bug target/38306] [4.4/4.5 Regression] 15% slowdown w.r.t. 4.3 of computational kernel on some architectures
--- Comment #17 from jv244 at cam dot ac dot uk 2009-09-01 09:17 --- (In reply to comment #16) All numbers with trunk: with 4.3 there is no difference between -O2 and -O3 -O2 -march=native -funroll-loops -ffast-math: 4.388 -O2 -march=native -funroll-loops -ffast-math -fschedule-insns: 3.352 -O3 -march=native -funroll-loops -ffast-math: 4.380 -O3 -march=native -funroll-loops -ffast-math -fschedule-insns: 3.372 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38306
[Bug target/41156] [4.4/4.5 Regression] zlib segfault in inflate_table() compiled w/ -O -msse2 ftree-vectorize
--- Comment #6 from jakub at gcc dot gnu dot org 2009-09-01 09:28 --- IMHO either standard options compiled code shouldn't be called from -mpreferred-stack-boundary=2 code, or it needs to be compiled with -mincoming-stack-boundary=2. But it should be user's responsibility. Ensuring by default outgoing calls are 16 byte aligned, but not assuming it is just a very stupid thing to do and unnecessarily penalizes normal users. It is certainly not true that most code is compiled with -mpreferred-stack-boundary=2, only kernel and a handful of packages is by default, and kernel has its own ABI (and doesn't use FPU nor SSE*). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41156
[Bug c++/41153] [4.4 Regression] ICE in building Qt4 src/core
--- Comment #11 from jakub at gcc dot gnu dot org 2009-09-01 09:32 --- Mark, I don't think this should be P1, __optimize__ attribute is new in 4.4 (so considering it regression is already quite weird, though the attribute is ignored in older releases, so technically it is a regression, albeit one wouldn't use it with pre-4.4), but more importantly is known to be broken in many ways. -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||mmitchel at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41153
[Bug fortran/41209] New: Add full ATTRIBUTE support to gfortran (ALIGN, (WEAK)ALIAS, ...)
gfortran currently supports only STDCALL, FASTCALL and CDECL as attributes using !GCC$ ATTRIBUTE list :: symbol The attributes are saved as bit in the attr struct. For full attribute support, one presumably should save the string and convert it later in trans*.c into a TREE. The string should then be saved in the .mod file. (That is also the reason that one cannot directly save the attributes into a TREE.) Issue: For STDCALL etc. we do some conformance checking for proc-pointer assignments. That should continue to work. Maybe one needs to do further checks. See: http://gcc.gnu.org/onlinedocs/gfortran/GNU-Fortran-Compiler-Directives.html http://gcc.gnu.org/onlinedocs/gcc/Variable-Attributes.html http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html PR 34112 and PR 40955 -- Summary: Add full ATTRIBUTE support to gfortran (ALIGN, (WEAK)ALIAS, ...) Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41209
[Bug middle-end/40106] Time increase for the Polyhedron test air.f90 due to bad optimization
--- Comment #29 from dominiq at lps dot ens dot fr 2009-09-01 09:37 --- Does anyone understand why commenting a write can change crtl-maybe_hot_insn_p from 1 to 0? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40106
[Bug target/41210] New: ICE with vsx_movv2df
gcc.target/powerpc/vsx-builtin-7.c
testcase ICEs with -m32 -fstack-protector or -m64:
./cc1 -I include/ -O2 -m32 -fstack-protector -mcpu=power7 vsx-builtin-7.c
(insn 19 31 22 2 vsx-builtin-7.c:21 (set (reg/i:V2DF 3 3)
(mem/c/i:V2DF (plus:SI (reg:SI 9 9)
(reg:SI 0 0 [135])) [6 D.1882+0 S16 A128])) 651 {*vsx_movv2df}
(nil))
vsx-builtin-7.c:21:1: internal compiler error: in reload_cse_simplify_operands,
at postreload.c:396
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
./cc1 -I include/ -O2 -m64 -mcpu=power7 vsx-builtin-7.c
vsx-builtin-7.c: In function âinsert_df_nâ:
vsx-builtin-7.c:21:1: error: insn does not satisfy its constraints:
(insn 19 32 22 2 vsx-builtin-7.c:21 (set (reg/i:V2DF 3 3)
(mem/c/i:V2DF (plus:DI (reg:DI 9 9)
(reg:DI 0 0 [136])) [6 D.1879+0 S16 A128])) 651 {*vsx_movv2df}
(nil))
vsx-builtin-7.c:21:1: internal compiler error: in reload_cse_simplify_operands,
at postreload.c:396
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
similarly, vsx-vector-5.c ICEs with -m64 -fstack-protector the same way.
--
Summary: ICE with vsx_movv2df
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
GCC target triplet: powerpc*-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41210
[Bug testsuite/41199] gcc.dg/20081223-1.c should be in gcc.dg/lto/
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-09-01 10:34 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41199
[Bug testsuite/41199] gcc.dg/20081223-1.c should be in gcc.dg/lto/
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-09-01 10:34 --- Subject: Bug 41199 Author: rguenth Date: Tue Sep 1 10:34:17 2009 New Revision: 151265 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151265 Log: 2009-09-01 Richard Guenther rguent...@suse.de PR lto/41199 * gcc.dg/20081223-1.c: Conditionalize -fwhopr on target lto. Modified: branches/lto/gcc/testsuite/ChangeLog.lto branches/lto/gcc/testsuite/gcc.dg/20081223-1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41199
[Bug c/41196] The use of ARM NEON vshll_n_u8 intrinsic results in compile error on valid code
--- Comment #1 from ramana at gcc dot gnu dot org 2009-09-01 11:13 --- Also occurs with trunk. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-09-01 11:13:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41196
[Bug c/41211] New: internal compiler error when using x86_64-w64-mingw32-gcc to build sqlite3 alter.c
I built an x86_64-w64-mingw32 cross compiler under x86_64 linux using latest gcc SVN code, then use this cross compiler to build sqlite3 The compile failed with the following message : E:\code\sqlite3_sepmake gcc -pipe -Wall -g -O2 -save-temps -c -o alter.o alter.c gcc: warning: -pipe ignored because -save-temps specified alter.c: In function 'sqlite3AlterFinishAddColumn': alter.c:465:6: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make: *** [alter.o] Error 1 -- Summary: internal compiler error when using x86_64-w64-mingw32- gcc to build sqlite3 alter.c Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: drangon dot mail at gmail dot com GCC build triplet: x86_64-gnu-linux GCC host triplet: x86_64-gnu-linux GCC target triplet: x86_64-w64-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41211
[Bug c/41211] internal compiler error when using x86_64-w64-mingw32-gcc to build sqlite3 alter.c
--- Comment #1 from drangon dot mail at gmail dot com 2009-09-01 11:22 --- Created an attachment (id=18460) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18460action=view) gzip of alter.i, -save-temps output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41211
[Bug c/41211] internal compiler error when using x86_64-w64-mingw32-gcc to build sqlite3 alter.c
--- Comment #2 from drangon dot mail at gmail dot com 2009-09-01 11:25 --- Created an attachment (id=18461) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18461action=view) alter.s, -save-temps output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41211
[Bug tree-optimization/41212] New: miscompilation at -O2
The program below is miscompiled using gfortran -O2 -o m m.f90; ./m gives: y= 0.60653065945526063 2*y= 2. (the second of the printed numbers should equal twice the first). Using gfortran -fno-inline -O2 -o m m.f90 works OK. The compiler is: Using built-in specs. Target: i686-pc-linux-gnu Configured with: /home/jerry/gcc/trunk/configure --prefix=/usr/local/gfortran --enable-languages=c,fortran --disable-libmudflap --enable-libgomp --disable-shared Thread model: posix gcc version 4.5.0 20090831 (experimental) [trunk revision 151238] (GCC) program m double precision :: y,z call b(1.0d0,y,z) print*,'y= ', y, ' 2*y=', z contains subroutine b( x, y, z) implicit none double precision :: x,y,z integer :: i, k double precision :: h, r y = 1.0d0 z = 0.0d0 h = 0 DO k = 1,10 h = h + 1.0d0/k r = 1 DO i = 1,k r = (x/(2*i) ) * r END DO y = y + (-1)**k * r z = z + (-1)**(k+1) * h * r IF ( ABS(2*k/x*r) 1d-6 ) EXIT END DO z = 2*y end subroutine b end program m -- Summary: miscompilation at -O2 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jpr at csc dot fi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41212
[Bug fortran/41165] -std=f95: Reject PRODUCT in initialization expressions.
--- Comment #3 from dfranke at gcc dot gnu dot org 2009-09-01 11:49 --- It turns out, that the PRODUCT is already simplified to EXPR_CONST before is is checked in expr.c (check_init_expr). To be more specific, in resolve.c (resolve_unknown_f) the simplification is implied via intrinsic.c (gfc_intrinsic_func_interface). The latter returns MATCH_YESif the call corresponds to an intrinsic, simplification is done if possible. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-09-01 11:49:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41165
[Bug libstdc++/41058] FAIL: ext/pb_ds/regression/hash_data_map_rand.cc
--- Comment #29 from ubizjak at gmail dot com 2009-09-01 12:00 --- (In reply to comment #28) This may be related to PR 37144. No, it was assembler bug with 2.19.1 in my case. -- ubizjak at gmail dot com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41058
[Bug libgcj/40868] ecjx.cc should be compiled by host gcc
--- Comment #1 from ramana at gcc dot gnu dot org 2009-09-01 12:03 --- This sounds correct to me . Adding one of the libjava maintainers to comment on this. Patches should be submitted to the correct mailing list. -- ramana at gcc dot gnu dot org changed: What|Removed |Added CC||aph at redhat dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-09-01 12:03:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40868
[Bug rtl-optimization/24319] [4.3/4.4/4.5 regression] amd64 register spill error with -fschedule-insns
--- Comment #17 from ubizjak at gmail dot com 2009-09-01 12:08 --- Patch at http://gcc.gnu.org/ml/gcc-patches/2009-09/msg3.html -- ubizjak at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2009- ||09/msg3.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24319
[Bug tree-optimization/41213] New: miscompilation at -O2
The program below is miscompiled using gfortran -O2 -o m m.f90; ./m gives: y= 0.60653065945526063 2*y= 2. (the second of the printed numbers should equal twice the first). Using gfortran -fno-inline -O2 -o m m.f90 works OK. The compiler is: Using built-in specs. Target: i686-pc-linux-gnu Configured with: /home/jerry/gcc/trunk/configure --prefix=/usr/local/gfortran --enable-languages=c,fortran --disable-libmudflap --enable-libgomp --disable-shared Thread model: posix gcc version 4.5.0 20090831 (experimental) [trunk revision 151238] (GCC) program m double precision :: y,z call b(1.0d0,y,z) print*,'y= ', y, ' 2*y=', z contains subroutine b( x, y, z) implicit none double precision :: x,y,z integer :: i, k double precision :: h, r y = 1.0d0 z = 0.0d0 h = 0 DO k = 1,10 h = h + 1.0d0/k r = 1 DO i = 1,k r = (x/(2*i) ) * r END DO y = y + (-1)**k * r z = z + (-1)**(k+1) * h * r IF ( ABS(2*k/x*r) 1d-6 ) EXIT END DO z = 2*y end subroutine b end program m -- Summary: miscompilation at -O2 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jpr at csc dot fi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41213
[Bug c++/41058] FAIL: ext/pb_ds/regression/hash_data_map_rand.cc
--- Comment #30 from paolo dot carlini at oracle dot com 2009-09-01 12:12 --- Even if the bug is fixed, I think it would be nice to have it properly categorization: I can see only a C++ front-end patch in the trail, thus I'm changing the category to C++. If I'm wrong, please improve it... -- paolo dot carlini at oracle dot com changed: What|Removed |Added Component|libstdc++ |c++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41058
[Bug libstdc++/41214] New: [4.5 regression] Null pointer dereferenced in _Unwind_SetGR()
GCC 4.5.0 20090827 When I run any program which throws an exception, I get a segfault: __cxa_throw . libstdc++-v3/libsupc++/eh_throw.cc:78 _Unwind_RaiseException .. gcc/unwind.inc:62 __gxx_personality_v0 libsupc++/eh_personality.cc:706 _Unwind_SetGR ... gcc/unwind-dw2.c:215 GCC is compiled with -O3, maybe it makes a difference. -- Summary: [4.5 regression] Null pointer dereferenced in _Unwind_SetGR() Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: d dot g dot gorbachev at gmail dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41214
[Bug tree-optimization/41212] miscompilation at -O2
--- Comment #1 from jpr at csc dot fi 2009-09-01 12:15 --- *** Bug 41213 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41212
[Bug tree-optimization/41213] miscompilation at -O2
--- Comment #1 from jpr at csc dot fi 2009-09-01 12:15 --- Sorry about the duplicate... *** This bug has been marked as a duplicate of 41212 *** -- jpr at csc dot fi changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41213
[Bug c++/41214] [4.5 regression] Null pointer dereferenced in _Unwind_SetGR()
--- Comment #1 from paolo dot carlini at oracle dot com 2009-09-01 12:21 --- For sure, this isn't a library issue. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Component|libstdc++ |c++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41214
[Bug lto/41058] FAIL: ext/pb_ds/regression/hash_data_map_rand.cc
--- Comment #31 from rguenth at gcc dot gnu dot org 2009-09-01 12:21 --- Let's reopen it as LTO specific. The test still fails on i?86 with the original multi-file testcase and -flto. There are also other similar pb_ds fails. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Component|c++ |lto Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41058
[Bug fortran/41209] Add full ATTRIBUTE support to gfortran (ALIGN, (WEAK)ALIAS, ...)
--- Comment #1 from burnus at gcc dot gnu dot org 2009-09-01 13:29 ---
As fun one can think of supporting also alignment within a TYPE, similarly to
C's:
struct foo { int x[2] __attribute__ ((aligned (8))); };
See http://gcc.gnu.org/onlinedocs/gcc/Type-Attributes.html for details.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41209
[Bug target/41156] [4.4/4.5 Regression] zlib segfault in inflate_table() compiled w/ -O -msse2 ftree-vectorize
--- Comment #7 from hjl dot tools at gmail dot com 2009-09-01 13:20 --- Realign the incoming stack for vectorizer has very limited impact on performance. Here are the differences of -m32 -O3 -msse2 -mfpmath=sse -ffast-math -funroll-loops before and after my patch: 400.perlbench-0.384615% 401.bzip20% 403.gcc -0.362319% 429.mcf -0.813008% 445.gobmk0.921659% 456.hmmer0.549451% 458.sjeng-0.438596% 462.libquantum 0% 464.h264ref 0% 471.omnetpp -0.478469% 473.astar-0.645161% 483.xalancbmk-0.727273% SPECint(R)_base2006 -0.411523% 410.bwaves -0.406504% 416.gamess 0% 433.milc -1.36986% 434.zeusmp -0.44843% 435.gromacs 0% 436.cactusADM0% 437.leslie3d -0.89% 444.namd 1.20482% 447.dealII -0.350877% 450.soplex -0.31746% 453.povray 0.458716% 454.calculix 0% 459.GemsFDTD 0% 465.tonto0% 470.lbm 0% 481.wrf 0.480769% 482.sphinx3 0.940439% SPECfp(R)_base2006 0% It won't change generated code if vectorizer isn't enabled. Its benifits outweigh its drawbacks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41156
[Bug tree-optimization/41212] miscompilation at -O2
--- Comment #2 from dominiq at lps dot ens dot fr 2009-09-01 13:37 --- Confirmed on (powerpc|i686)-apple-darwin9 in 32 bit mode and -O2 or above. This is a regression: I get 1.21306131891052 with gcc 4.2.4, 4.3.4, and 4.4.1. I also get 1.21306131891052 with recent revisions of trunk with -m64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41212
[Bug c++/41153] [4.4 Regression] ICE in building Qt4 src/core
--- Comment #12 from mmitchel at gcc dot gnu dot org 2009-09-01 13:54 --- I think the question is whether the use of __optimize__ is in a standard Qt release. If it is, then I'm quite concerned; it's bad if GCC 4.4.2 can't build Qt/KDE. (TBH, I'm concerned anyhow; if __optimize__ is unreliable, then perhaps we should be ignoring/warning about it in 4.4.x until we get it solid...) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41153
[Bug target/41021] [ARM] Suboptimal code generated to store a struct
--- Comment #4 from jamborm at gcc dot gnu dot org 2009-09-01 14:01 --- Indeed. SRA should not trigger here, that would make it too eager in other cases (thus I'm removing myself from the CC, feel free to add me again if there's any discussion that might concern me or SRA again). -- jamborm at gcc dot gnu dot org changed: What|Removed |Added CC|jamborm at gcc dot gnu dot | |org | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41021
[Bug libgcj/40868] ecjx.cc should be compiled by host gcc
--- Comment #2 from aph at gcc dot gnu dot org 2009-09-01 14:06 --- Assigning to Tom tromey: this is his area. -- aph at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40868
[Bug c/41215] New: request: option to suppress discarded qualifiers warnings
There is currently no GCC option that will turn off discarded qualifiers warnings, which typically arise from const/non-const mismatches. These warnings look like this: warning: assignment discards qualifiers from pointer target type warning: passing argument 1 of foo discards qualifiers from pointer target type This is a request for an option to suppress these warnings. A typical C programmer should see these warnings so that they can fix them. But in tools that automatically generate C code it may sometimes be difficult to avoid large numbers of warnings like this, and so as a practical matter it may be helpful to be able to suppress them. (One such tool is the Vala compiler; see http://live.gnome.org/Vala). -- Summary: request: option to suppress discarded qualifiers warnings Product: gcc Version: 4.3.3 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: adam at yorba dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41215
[Bug target/41074] Invalid code generation on ARM when using '-fno-omit-frame-pointer' option
--- Comment #2 from ramana at gcc dot gnu dot org 2009-09-01 14:51 --- I'm afraid nothing much can be done without a smaller testcase than this. What happens if you don't use -fno-omit-frame-pointer ? -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41074
[Bug bootstrap/40651] bootstrap error on arm-linux-gnueabi: segfault in next_const_call_expr_arg
--- Comment #3 from ramana at gcc dot gnu dot org 2009-09-01 14:56 --- Does this still occur with trunk ? -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40651
[Bug target/41074] Invalid code generation on ARM when using '-fno-omit-frame-pointer' option
--- Comment #3 from siarhei dot siamashka at gmail dot com 2009-09-01 15:08 --- It works fine if '-fno-omit-frame-pointer' is removed. I agree that this is quite a large and convoluted function. Unfortunately I did not manage to reduce it to something smaller that would still result in broken behaviour. My only guess is that the stack frame which is bigger than 4K may make some difference. I have a full linux system compiled with -fno-omit-frame-pointer (to get stack backtraces and generate callgraphs in oprofile). If anything simpler happens to to be broken too, I'll try to investigate it and provide additional details. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41074
[Bug c++/41195] floating point optimization
--- Comment #3 from Vikas dot Mehta at roguewave dot com 2009-09-01 15:22 --- Subject: RE: floating point optimization Thanks for looking into this issue. Target: x86_64-redhat-linux -Original Message- From: pinskia at gcc dot gnu dot org [mailto:gcc-bugzi...@gcc.gnu.org] Sent: Monday, August 31, 2009 12:21 AM To: Vikas Mehta Subject: [Bug c++/41195] floating point optimization --- Comment #2 from pinskia at gcc dot gnu dot org 2009-08-31 06:21 --- I think this is a duplicate of bug 323. What target are you using? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41195
[Bug c++/41216] New: G++ failed to correctly resolve the template parameters.
Platform£º
WinXP SP3 + Eclipse CDT 6.0 + MinGW 5.1.4 + GCC 4.4.1 (TDM's Build)
Bug description:
GCC failed to correctly resolve the template parameters when nestedly calling
friend function templates of class templates.
Sample codes£º
/* TestMinGW.cpp*/
#include iostream
#include vector
/* Class Inner */
struct Inner {
template class IStream friend IStream operator ( IStream in, Inner
inner );
Inner() : data(0) {}
template class IStream explicit Inner( IStream in ) { operator
(in,*this); }
int data;
};
template class IStream
IStream operator ( IStream in, Inner inner )
{
in inner.data;
return in;
}
/* Class Outter */
struct Outter {
template class IStream friend IStream operator ( IStream in, Outter
outter );
template class IStream explicit Outter( IStream in ) { Inner inner(in);
inners.push_back(inner); }
std::vector Inner inners;
};
template class IStream
IStream operator ( IStream in, Outter inner )
{
in inner;
return in;
}
/* Main */
int main ( int argc, char* argv[] )
{
Inner inner(std::cin);// OK.
Outter outter(std::cin); // Compilation error.
return 0;
}
Compiler log:
g++ -v -save-temps -O3 -Wall -c -fmessage-length=0 -oSrc\TestMinGW.o
..\Src\TestMinGW.cpp
Using built-in specs.
Target: mingw32
Configured with: ../../gcc-4.4.1/configure --prefix=/mingw --build=mingw32
--enable-languages=c,ada,c++,fortran,objc,obj-c++ --disable-nls
--disable-win32-registry --enable-libgomp
--enable-cxx-flags='-fno-function-sections -fno-data-sections' --disable-werror
--enable-threads --disable-symvers --enable-version-specific-runtime-libs
--enable-fully-dynamic-string --with-pkgversion='TDM-1 mingw32'
--enable-sjlj-exceptions
--with-bugurl=http://www.tdragon.net/recentgcc/bugs.php
Thread model: win32
gcc version 4.4.1 (TDM-1 mingw32)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-Wall' '-c' '-fmessage-length=0'
'-oSrc\TestMinGW.o' '-mtune=i386'
d:/mingw-5.1.4/bin/../libexec/gcc/mingw32/4.4.1/cc1plus.exe -E -quiet -v
-iprefix d:\mingw-5.1.4\bin\../lib/gcc/mingw32/4.4.1/ ..\Src\TestMinGW.cpp
-mtune=i386 -Wall -fmessage-length=0 -O3 -fpch-preprocess -o TestMinGW.ii
ignoring nonexistent directory
d:\mingw-5.1.4\bin\../lib/gcc/mingw32/4.4.1/../../../../mingw32/include
ignoring duplicate directory
d:/mingw-5.1.4/lib/gcc/../../lib/gcc/mingw32/4.4.1/include/c++
ignoring duplicate directory
d:/mingw-5.1.4/lib/gcc/../../lib/gcc/mingw32/4.4.1/include/c++/mingw32
ignoring duplicate directory
d:/mingw-5.1.4/lib/gcc/../../lib/gcc/mingw32/4.4.1/include/c++/backward
ignoring nonexistent directory /mingw/include
ignoring duplicate directory d:/mingw-5.1.4/lib/gcc/../../include
ignoring duplicate directory
d:/mingw-5.1.4/lib/gcc/../../lib/gcc/mingw32/4.4.1/include
ignoring duplicate directory
d:/mingw-5.1.4/lib/gcc/../../lib/gcc/mingw32/4.4.1/include-fixed
ignoring nonexistent directory
d:/mingw-5.1.4/lib/gcc/../../lib/gcc/mingw32/4.4.1/../../../../mingw32/include
ignoring nonexistent directory /mingw/include
#include ... search starts here:
#include ... search starts here:
D:/boost-1.40.0/include
D:/dlib-17.21
d:\mingw-5.1.4\bin\../lib/gcc/mingw32/4.4.1/include/c++
d:\mingw-5.1.4\bin\../lib/gcc/mingw32/4.4.1/include/c++/mingw32
d:\mingw-5.1.4\bin\../lib/gcc/mingw32/4.4.1/include/c++/backward
d:\mingw-5.1.4\bin\../lib/gcc/mingw32/4.4.1/../../../../include
d:\mingw-5.1.4\bin\../lib/gcc/mingw32/4.4.1/include
d:\mingw-5.1.4\bin\../lib/gcc/mingw32/4.4.1/include-fixed
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-Wall' '-c' '-fmessage-length=0'
'-oSrc\TestMinGW.o' '-mtune=i386'
d:/mingw-5.1.4/bin/../libexec/gcc/mingw32/4.4.1/cc1plus.exe -fpreprocessed
TestMinGW.ii -quiet -dumpbase TestMinGW.cpp -mtune=i386 -auxbase-strip
Src\TestMinGW.o -O3 -Wall -version -fmessage-length=0 -o TestMinGW.s
GNU C++ (TDM-1 mingw32) version 4.4.1 (mingw32)
compiled by GNU C version 4.4.1, GMP version 4.3.0, MPFR version 2.4.1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 8d2e404a57d82e42e16008cfa0818446
..\Src\TestMinGW.cpp: In function 'IStream operator(IStream, Inner) [with
IStream = Inner]':
..\Src\TestMinGW.cpp:8: instantiated from 'Inner::Inner(IStream) [with
IStream = Inner]'
d:\mingw-5.1.4\bin\../lib/gcc/mingw32/4.4.1/include/c++/bits/stl_uninitialized.h:74:
instantiated from 'static _ForwardIterator
std::__uninitialized_copyanonymous ::uninitialized_copy(_InputIterator,
_InputIterator, _ForwardIterator) [with _InputIterator = Inner*,
_ForwardIterator = Inner*, bool anonymous = false]'
d:\mingw-5.1.4\bin\../lib/gcc/mingw32/4.4.1/include/c++/bits/stl_uninitialized.h:117:
instantiated from '_ForwardIterator std::uninitialized_copy(_InputIterator,
_InputIterator, _ForwardIterator) [with _InputIterator = Inner*,
_ForwardIterator = Inner*]'
d:\mingw-5.1.4\bin\../lib/gcc/mingw32/4.4.1/include/c++/bits/stl_uninitialized.h:257:
instantiated from '_ForwardIterator
[Bug c++/41216] G++ failed to correctly resolve the template parameters.
--- Comment #1 from yimingli0126 at 163 dot com 2009-09-01 16:16 --- Created an attachment (id=18462) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18462action=view) The source file rising the compilation failure. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41216
[Bug driver/39356] assembler isn't called
--- Comment #19 from ktietz at gcc dot gnu dot org 2009-09-01 16:16 --- I verified it by myself and it is a duplicate of 41184 *** This bug has been marked as a duplicate of 41184 *** -- ktietz at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39356
[Bug c/41184] wrong optimise code, epilogue code adjust wrong rsp before pop
--- Comment #8 from ktietz at gcc dot gnu dot org 2009-09-01 16:16 --- *** Bug 39356 has been marked as a duplicate of this bug. *** -- ktietz at gcc dot gnu dot org changed: What|Removed |Added CC||rainer at emrich-ebersheim ||dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41184
[Bug target/35124] Method _alloca is defined different by MSVCRT as by gcc.
--- Comment #9 from ktietz at gcc dot gnu dot org 2009-09-01 16:20 --- As the initial reason of this bug is solved, I close it. In fact is the __chkstk function here incompatible to VC version, but this should be part of a feature request. -- ktietz at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35124
[Bug libgcj/40868] ecjx.cc should be compiled by host gcc
--- Comment #3 from tromey at gcc dot gnu dot org 2009-09-01 16:58 --- I think it isn't correct to use gcc directly. You probably have to introduce a new variable. But, I don't see why we need ecjx.cc at all. I think it must be to work around some other problem. Maybe instead we could just fix that problem directly. Apparently it came in here, though I don't see why: http://gcc.gnu.org/ml/java-patches/2008-q4/msg00067.html See also PR 38396 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40868
[Bug libstdc++/41216] G++ failed to correctly resolve the template parameters.
--- Comment #2 from paolo dot carlini at oracle dot com 2009-09-01 17:07 --- Seems a problem with the stricter uninitialized_copy we have got since 4.3... Investigating. -- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle |dot org |dot com Component|c++ |libstdc++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41216
[Bug libgcj/40868] ecjx.cc should be compiled by host gcc
--- Comment #4 from aph at gcc dot gnu dot org 2009-09-01 17:09 --- Hmm, I seem to have approved that patch. I agree with you: I can't see why the specfile change requires ecjx.cc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40868
[Bug c++/41214] [4.5 regression] Null pointer dereferenced in _Unwind_SetGR()
--- Comment #2 from ubizjak at gmail dot com 2009-09-01 17:26 --- No testcase - no analysis - no solution. -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41214
[Bug tree-optimization/41212] [4.5 Regression] miscompilation at -O2
--- Comment #3 from ubizjak at gmail dot com 2009-09-01 17:31 --- Per comment #2. -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-09-01 17:31:02 date|| Summary|miscompilation at -O2 |[4.5 Regression] ||miscompilation at -O2 Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41212
[Bug fortran/41209] Add full ATTRIBUTE support to gfortran (ALIGN, (WEAK)ALIAS, ...)
--- Comment #2 from burnus at gcc dot gnu dot org 2009-09-01 17:39 --- Created an attachment (id=18463) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18463action=view) Draft patch - first steps but incomplete will not work Draft patch (not really work yet). TODO: a) Copy attributes properly and free them at the end b) Write/read them from the .mod file c) Use an ENUM for stdcall etc.? Requires a check whether they are already set but those options are orthogonal thus that makes sense. TODO 2: Check whether derived types are properly handled: bind(C) vs. sequence vs. extensible types. And attributes to components vs. attributes to the type as a whole. Plus checking whether we set some attributes by default which clash with user settings. Plus: Are additional front-end checks needed besides stdcall etc. conformance for proc-pointers? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41209
[Bug target/39112] incorrect value of a static const double class member
--- Comment #4 from ktietz at gcc dot gnu dot org 2009-09-01 17:40 --- *** This bug has been marked as a duplicate of 41184 *** -- ktietz at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39112
[Bug c/41184] wrong optimise code, epilogue code adjust wrong rsp before pop
--- Comment #9 from ktietz at gcc dot gnu dot org 2009-09-01 17:40 --- *** Bug 39112 has been marked as a duplicate of this bug. *** -- ktietz at gcc dot gnu dot org changed: What|Removed |Added CC||alexey dot pushkin at ||mererand dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41184
[Bug target/41211] internal compiler error when using x86_64-w64-mingw32-gcc to build sqlite3 alter.c
--- Comment #4 from ubizjak at gmail dot com 2009-09-01 17:53 --- Works for me with a crosscompiler from linux to mingw: Target: x86_64-pc-mingw32 Configured with: ../gcc-svn/trunk/configure --target=x86_64-pc-mingw32 Thread model: win32 gcc version 4.5.0 20090901 (experimental) [trunk revision 151274] (GCC) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41211
[Bug bootstrap/39686] ./gcc/xgcc crashes on mingw
--- Comment #1 from ktietz at gcc dot gnu dot org 2009-09-01 18:26 --- I can't reproduce this failure. Neither for msys, linux, and linux64, nor for cygwin. Does it still exists for you? Which host and build environment you are using? -- ktietz at gcc dot gnu dot org changed: What|Removed |Added CC||ktietz at gcc dot gnu dot ||org Summary|./gcc/xgcc crashes on mingw |./gcc/xgcc crashes on mingw http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39686
[Bug target/40802] Libstdc++ is broken for win64 host
--- Comment #16 from ktietz at gcc dot gnu dot org 2009-09-01 18:38 --- (In reply to comment #15) GCC 4.5 [Trunk], SVN Revision 149872. Because Win64 testing is so hard to come by, I took the initiative of deleting the entire tree, re-checking it out, and building from scratch. I am sorry, I am still encountering the following: make[3]: Entering directory `/home/peter/mount/GCC/gcc-trunk/build-win-149872-20090721/x86_64-w64-mingw32/libstdc++-v3' Making all in include make[4]: Entering directory `/home/peter/mount/GCC/gcc-trunk/build-win-149872-20090721/x86_64-w64-mingw32/libstdc++-v3/include' mkdir -p ./x86_64-w64-mingw32/bits/stdc++.h.gch x86_64-w64-mingw32-c++ -L/home/peter/build/GCC/gcc-trunk/build-win-149872-20090721/x86_64-w64-mingw32/winsup/mingw -L/home/peter/build/GCC/gcc-trunk/build-win-149872-20090721/x86_64-w64-mingw32/winsup/w32api/lib -isystem /home/peter/build/GCC/gcc-trunk/winsup/mingw/include -isystem /home/peter/build/GCC/gcc-trunk/winsup/w32api/include-x c++-header -g -O2 -I/home/peter/build/GCC/gcc-trunk/build-win-149872-20090721/x86_64-w64-mingw32/libstdc++-v3/include/x86_64-w64-mingw32 -I/home/peter/build/GCC/gcc-trunk/build-win-149872-20090721/x86_64-w64-mingw32/libstdc++-v3/include -I/home/peter/build/GCC/gcc-trunk/libstdc++-v3/libsupc++ -O2 -g -std=gnu++0x /home/peter/build/GCC/gcc-trunk/libstdc++-v3/include/precompiled/stdc++.h \ -o x86_64-w64-mingw32/bits/stdc++.h.gch/O2ggnu++0x.gch In file included from /home/peter/build/GCC/gcc-trunk/build-win-149872-20090721/x86_64-w64-mingw32/libstdc++-v3/include/bits/move.h:38:0, from /home/peter/build/GCC/gcc-trunk/build-win-149872-20090721/x86_64-w64-mingw32/libstdc++-v3/include/bits/stl_pair.h:60, from /home/peter/build/GCC/gcc-trunk/build-win-149872-20090721/x86_64-w64-mingw32/libstdc++-v3/include/bits/stl_algobase.h:66, from /home/peter/build/GCC/gcc-trunk/build-win-149872-20090721/x86_64-w64-mingw32/libstdc++-v3/include/bits/char_traits.h:41, from /home/peter/build/GCC/gcc-trunk/build-win-149872-20090721/x86_64-w64-mingw32/libstdc++-v3/include/ios:41, from /home/peter/build/GCC/gcc-trunk/build-win-149872-20090721/x86_64-w64-mingw32/libstdc++-v3/include/istream:40, from /home/peter/build/GCC/gcc-trunk/build-win-149872-20090721/x86_64-w64-mingw32/libstdc++-v3/include/sstream:39, from /home/peter/build/GCC/gcc-trunk/build-win-149872-20090721/x86_64-w64-mingw32/libstdc++-v3/include/complex:47, from /home/peter/build/GCC/gcc-trunk/build-win-149872-20090721/x86_64-w64-mingw32/libstdc++-v3/include/ccomplex:42, from /home/peter/build/GCC/gcc-trunk/libstdc++-v3/include/precompiled/stdc++.h:51: /home/peter/build/GCC/gcc-trunk/build-win-149872-20090721/x86_64-w64-mingw32/libstdc++-v3/include/type_traits:185:62: error: a function call cannot appear in a constant-expression /home/peter/build/GCC/gcc-trunk/build-win-149872-20090721/x86_64-w64-mingw32/libstdc++-v3/include/type_traits:185:63: error: template argument 2 is invalid /home/peter/build/GCC/gcc-trunk/build-win-149872-20090721/x86_64-w64-mingw32/libstdc++-v3/include/type_traits:215:54: error: a function call cannot appear in a constant-expression /home/peter/build/GCC/gcc-trunk/build-win-149872-20090721/x86_64-w64-mingw32/libstdc++-v3/include/type_traits:215:55: error: template argument 2 is invalid In file included from /home/peter/build/GCC/gcc-trunk/build-win-149872-20090721/x86_64-w64-mingw32/libstdc++-v3/include/fenv.h:50:0, from /home/peter/build/GCC/gcc-trunk/build-win-149872-20090721/x86_64-w64-mingw32/libstdc++-v3/include/cfenv:44, from /home/peter/build/GCC/gcc-trunk/libstdc++-v3/include/precompiled/stdc++.h:52: /home/peter/build/GCC/gcc-trunk/build-win-149872-20090721/x86_64-w64-mingw32/libstdc++-v3/include/tr1_impl/cfenv:49:11: error: ::fenv_t has not been declared /home/peter/build/GCC/gcc-trunk/build-win-149872-20090721/x86_64-w64-mingw32/libstdc++-v3/include/tr1_impl/cfenv:50:11: error: ::fexcept_t has not been declared /home/peter/build/GCC/gcc-trunk/build-win-149872-20090721/x86_64-w64-mingw32/libstdc++-v3/include/tr1_impl/cfenv:53:11: error: ::feclearexcept has not been declared /home/peter/build/GCC/gcc-trunk/build-win-149872-20090721/x86_64-w64-mingw32/libstdc++-v3/include/tr1_impl/cfenv:54:11: error: ::fegetexceptflag has not been declared /home/peter/build/GCC/gcc-trunk/build-win-149872-20090721/x86_64-w64-mingw32/libstdc++-v3/include/tr1_impl/cfenv:55:11: error: ::feraiseexcept has not been declared /home/peter/build/GCC/gcc-trunk/build-win-149872-20090721/x86_64-w64-mingw32/libstdc++-v3/include/tr1_impl/cfenv:56:11: error: ::fesetexceptflag has not been declared /home/peter/build/GCC/gcc-trunk/build-win-149872-20090721/x86_64-w64-mingw32/libstdc++-v3/include/tr1_impl/cfenv:57:11:
[Bug target/41211] internal compiler error when using x86_64-w64-mingw32-gcc to build sqlite3 alter.c
--- Comment #5 from ktietz at gcc dot gnu dot org 2009-09-01 18:59 --- (In reply to comment #4) Works for me with a crosscompiler from linux to mingw: Target: x86_64-pc-mingw32 Configured with: ../gcc-svn/trunk/configure --target=x86_64-pc-mingw32 Thread model: win32 gcc version 4.5.0 20090901 (experimental) [trunk revision 151274] (GCC) Works for me too. Maybe a duplicate of PR/41184 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41211
[Bug driver/41217] New: Driver crashes if -o specified without filename
$ ./xgcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../configure --enable-languages=c Thread model: posix gcc version 4.5.0 20090901 (experimental) [trunk revision 151276] (GCC) $ ./xgcc -B. -o Segmentation fault (gdb) bt #0 0xb7f43613 in strlen () from /lib/tls/i686/cmov/libc.so.6 #1 0x08065b27 in xstrdup (s=0x0) at ../../libiberty/xstrdup.c:33 #2 0x0804f55e in process_command (argc=3, argv=0x9ff62b8) at ../../gcc/gcc.c:4164 #3 0x0805720f in main (argc=3, argv=0xbfe5d574) at ../../gcc/gcc.c:6823 Introduced by http://gcc.gnu.org/viewcvs?view=revisionrevision=145470 Only happens in gcc 4.5.0. Index: gcc.c === --- gcc.c (revision 151276) +++ gcc.c (working copy) @@ -4161,7 +4161,10 @@ argv[i] = convert_filename (argv[i], ! have_c, 0); #endif /* Save the output name in case -save-temps=obj was used. */ - save_temps_prefix = xstrdup ((p[1] == 0) ? argv[i + 1] : argv[i] + 1); + if ((p[1] == 0) argv[i + 1]) + save_temps_prefix = xstrdup(argv[i + 1]); + else + save_temps_prefix = xstrdup(argv[i] + 1); goto normal_switch; default: -- Summary: Driver crashes if -o specified without filename Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rmansfield at qnx dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41217
[Bug c++/41216] G++ failed to correctly resolve the template parameters.
--- Comment #3 from paolo dot carlini at oracle dot com 2009-09-01 20:06
---
As a matter of fact, this snippet doesn't link:
struct Inner
{
Inner()
: data(0) {}
templateclass IStream
explicit Inner(IStream);
int data;
};
int f()
{
Inner inner1;
Inner inner2(inner1);
}
Now, as a matter of fact, the fact that the above code doesn't link means that
Inner isn't CopyConstructible (First line of Table 30 in C++03), thus, it is
invalid to instantiate std::vector with it, as you are doing in Outter. I'm
adding Jason in CC just in case he has something to say about the C++ proper
issue.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
CC||jason at gcc dot gnu dot org
Status|UNCONFIRMED |RESOLVED
Component|libstdc++ |c++
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41216
[Bug libstdc++/41216] G++ failed to correctly resolve the template parameters.
--- Comment #4 from paolo dot carlini at oracle dot com 2009-09-01 20:07 --- Actually, a library issue, invalid, still library. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Component|c++ |libstdc++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41216
[Bug target/40546] -fwhole-program -shared with externally_visible gives R_X86_64_PC32 errors
--- Comment #1 from kpfleming at digium dot com 2009-09-01 20:53 --- I have just run into this as well; supplying -fPIC (implied in -shared) without -fwhole-program works fine, but adding -fwhole-program causes functions that are called internally to the program being compiled to end up with the wrong relocation type. Making that function static and providing an externally_visible wrapper for it is a workaround. -- kpfleming at digium dot com changed: What|Removed |Added CC||kpfleming at digium dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40546
[Bug fortran/41219] New: libgfortran build warnings
Reported by NightStrike in #gfortran - I see the same in my build logs. Some
annotations, see below.
../../../gcc/libgfortran/io/list_read.c: In function nml_read_obj:
../../../gcc/libgfortran/io/list_read.c:2470:31: warning: comparison between
bt and enum anonymous
../../../gcc/libgfortran/io/write.c: In function write_a_char4:
../../../gcc/libgfortran/io/write.c:328:8: warning: passing argument 2 of
write_default_char4 from incompatible pointer type
../../../gcc/libgfortran/io/write.c:44:1: note: expected gfc_char4_t * but
argument is of type const char *
../../../gcc/libgfortran/io/unix.c: In function fd_to_stream:
../../../gcc/libgfortran/io/unix.c:750:15: warning: statbuf.st_mode may be
used uninitialized in this function
../../../gcc/libgfortran/io/unix.c:750:15: warning: statbuf.st_size may be
used uninitialized in this function
../../../gcc/libgfortran/intrinsics/getlog.c: In function _gfortran_getlog:
../../../gcc/libgfortran/intrinsics/getlog.c:85:3: warning: implicit
declaration of function getlogin
../../../gcc/libgfortran/intrinsics/getlog.c:85:5: warning: assignment makes
pointer from integer without a cast
../../../gcc/libgfortran/intrinsics/iso_c_binding.c: In function
__iso_c_binding_c_f_pointer_u0:
../../../gcc/libgfortran/intrinsics/iso_c_binding.c:112:15: warning: str may
be used uninitialized in this function
ISO_C_BINDING_PREFIX (c_f_pointer_u0) (void *c_ptr_in,
for (i = 0; i shapeSize; i++)
{
index_type str, ub;
if (i == 0)
str = 1;
}
else
{
str = str * GFC_DESCRIPTOR_EXTENT(f_ptr_out,i-1);
That looks like a real bug! The str declaration should be moved outside the
loop.
../../../gcc/libgfortran/intrinsics/unpack_generic.c: In function
unpack_internal:
../../../gcc/libgfortran/intrinsics/unpack_generic.c:60:32: warning: unused
parameter fsize
That's
unpack_internal (gfc_array_char *ret, const gfc_array_char *vector,
const gfc_array_l1 *mask, const gfc_array_char *field,
index_type size, index_type fsize)
And probably a side effect of Thomas' bound check work.
--
Summary: libgfortran build warnings
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41219
[Bug target/40546] -fwhole-program -shared with externally_visible gives R_X86_64_PC32 errors
--- Comment #3 from kpfleming at digium dot com 2009-09-01 21:11 --- That talks about using -fpie/-fPIE as a workaround, but according to the gcc manpage those options are not suitable when the result is going to be used in a shared library, only as a linked executable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40546
[Bug fortran/41218] New: Vendor extension: character assignment in DATA to non-character variables
http://gcc.gnu.org/ml/fortran/2009-09/msg3.html
g77 - but also openf95, sunf95 or ifort - support the following Fortran 66
vendor extension, which was effectively obsoleted by Fortran 77.
LOGICAL :: L
INTEGER :: I
REAL:: R
DATA L/'abcd'/, I/'Text'/, R/'ZYXW'/ ! Missing legacy extension
print *, L, transfer(L,1234)
print *, I, transfer(I,1234)
print *, R, transfer(R,1234)
END
Tim wrote: Hollerith constant expressed with apostrophes was a vendor
extension to f66, typically supported by IBM and HP but few others. Its use was
often a sign of intentional non-portability. In order to support the extension
in f77, it involved the new extension of supporting character strings to assign
and initialize Hollerith.
* * *
One needs to add a conversion similar as done in gfc_simplify_transfer -
with the proper warning if the string is too long (ignored characters)
or too short (undefined value) - somewhere in gfc_check_assign. The
first steps will be:
Index: expr.c
===
--- expr.c (revision 151272)
+++ expr.c (working copy)
@@ -3021,6 +3021,18 @@ gfc_check_assign (gfc_expr *lvalue, gfc_
if (lvalue-ts.type == BT_LOGICAL rvalue-ts.type == BT_LOGICAL)
return SUCCESS;
+ if ((gfc_numeric_ts (lvalue-ts) || lvalue-ts.type == BT_LOGICAL)
+ rvalue-ts.type == BT_CHARACTER)
+{
+ if (gfc_notify_std (GFC_STD_LEGACY, Legacy: Assigning character
+literal in DATA statement at %L to a
noncharacter
+variable, rvalue-where) == FAILURE)
+ return FAILURE;
+
+FIXME: Do actual conversion similar to gfc_simplify_transfer
+ (incl. too long/too shortwarnings)
+
+}
+
gfc_error (Incompatible types in DATA statement at %L; attempted
conversion of %s to %s, lvalue-where,
gfc_typename (rvalue-ts), gfc_typename (lvalue-ts));
--
Summary: Vendor extension: character assignment in DATA to non-
character variables
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41218
[Bug target/40546] -fwhole-program -shared with externally_visible gives R_X86_64_PC32 errors
--- Comment #2 from kargl at gcc dot gnu dot org 2009-09-01 20:58 --- (In reply to comment #1) I have just run into this as well; supplying -fPIC (implied in -shared) without -fwhole-program works fine, but adding -fwhole-program causes functions that are called internally to the program being compiled to end up with the wrong relocation type. Making that function static and providing an externally_visible wrapper for it is a workaround. See http://gcc.gnu.org/ml/fortran/2009-08/msg00466.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40546
[Bug libgcj/40868] ecjx.cc should be compiled by host gcc
--- Comment #5 from jakub at gcc dot gnu dot org 2009-09-01 21:38 --- I believe libtool wasn't doing the right thing without any sources, but it has been a while, so I don't remember the details. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40868
[Bug libstdc++/41220] New: [4.5 Regression] Make clean; make; make check doesn't work fine anymore
The summary says it all. For sure it used to work fine and still does in the 4_4-branch. Many spurious failures: FAIL: 17_intro/headers/c++1998/all.cc (test for excess errors) FAIL: 17_intro/headers/c++1998/all_no_exceptions.cc (test for excess errors) FAIL: 17_intro/headers/c++1998/stdc++.cc (test for excess errors) FAIL: 17_intro/headers/c++1998/stdc++_assert_neg.cc (test for errors, line 34) FAIL: 17_intro/headers/c++1998/stdc++_assert_neg.cc (test for excess errors) FAIL: 17_intro/headers/c++1998/stdc++_multiple_inclusion.cc (test for excess errors) FAIL: 17_intro/headers/c++200x/all_no_exceptions.cc (test for excess errors) FAIL: 17_intro/headers/c++200x/all_pedantic_errors.cc (test for excess errors) FAIL: 17_intro/headers/c++200x/stdc++_multiple_inclusion.cc (test for excess errors) ... of the form: .../libstdc++-v3/testsuite/17_intro/headers/c++1998/all.cc:20:25: fatal error: bits/extc++.h: No such file or directory -- Summary: [4.5 Regression] Make clean; make; make check doesn't work fine anymore Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: paolo dot carlini at oracle dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41220
[Bug c++/57] [DR 325] GCC can't parse a non-parenthesized comma in a template-id within a default argument
--- Comment #44 from keith dot g dot erickson at lmco dot com 2009-09-01 22:11 --- (In reply to comment #41) (In reply to comment #40) I read all comments and saw a patch. But I don't know how I can fix my gcc with this patch. The easiest way is to wait for gcc 4.4. W. GCC 4.4 came and went. Now what? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57
[Bug c++/57] [DR 325] GCC can't parse a non-parenthesized comma in a template-id within a default argument
--- Comment #45 from paolo dot carlini at oracle dot com 2009-09-01 22:26 --- (In reply to comment #44) GCC 4.4 came and went. Now what? Now what what? The issue is fixed for 4.4, and I just double checked myself the original testcase and the one in Comment #40, both compile fine. Comments #38 and #39 explain why technically the PR must remain suspended for now. So? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57
[Bug java/41221] New: segfault/internal compiler error in gcj when using AOT compilation
Hi, I maintain the eclipse-emf package in Fedora. If I enable gcj-aot compiling on it, I get an internal compiler error. The error can be reproduced by building the following source rpm on Fedora 10, 11 or 12 (Rawhide): http://mbooth.fedorapeople.org/aot_bug/eclipse-emf.spec http://mbooth.fedorapeople.org/aot_bug/eclipse-emf-2.4.1-1.fc10.src.rpm This bug was originally reported at the Red Hat bugzilla (https://bugzilla.redhat.com/show_bug.cgi?id=477707) -- Summary: segfault/internal compiler error in gcj when using AOT compilation Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: major Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fedora at matbooth dot co dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41221
[Bug java/41221] segfault/internal compiler error in gcj when using AOT compilation
--- Comment #1 from fedora at matbooth dot co dot uk 2009-09-01 22:59 --- Created an attachment (id=18464) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18464action=view) build error This is the error that is spit into the console during the build of the above rpm. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41221
[Bug fortran/41222] New: -std=f95 forbids USEd functions named like f03/f08 intrisics
This applies to gfortran 4.4.1 as distributed with Ubuntu 9.10 alpha-4. The use of the -std=f95 flag causes a spurious error to be raised when the module or program being compiled USEs a function from another module whose name matches that of a Fortran 200x intrinsic. I'll illustrate the bug with an example (the intrinsic function name being 'erfc' in this case): $ cat numerical.f90 MODULE numerical IMPLICIT NONE PRIVATE PUBLIC dp,erfc INTEGER,PARAMETER :: dp=kind(1.d0) CONTAINS REAL(dp) FUNCTION erfc(x) IMPLICIT NONE REAL(dp),INTENT(in) :: x erfc=x END FUNCTION erfc END MODULE numerical $ cat bug.f90 PROGRAM bug USE numerical, ONLY : dp,erfc IMPLICIT NONE REAL(dp) f f=erfc(1.d0) print *,f END PROGRAM bug $ gfortran -c numerical.f90 $ gfortran -o bug bug.f90 numerical.o $ ./bug 1. $ gfortran -std=f95 -o bug bug.f90 numerical.o /tmp/pablo/cci42qz2.o: In function `MAIN__': bug.f90:(.text+0x20): undefined reference to `erfc_' collect2: ld returned 1 exit status This can be reproduced with other function names, e.g. 'bessel_j0', etc. The problem goes away if one renames the function, of course. -- Summary: -std=f95 forbids USEd functions named like f03/f08 intrisics Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pablomme at googlemail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41222
[Bug fortran/41222] -std=f95 forbids USEd functions named like f03/f08 intrisics
--- Comment #1 from dominiq at lps dot ens dot fr 2009-09-01 23:52 --- The test works on trunk. I think it is a variant (duplicate?) of pr39876 that has been fixed on trunk. The fix could probably be backported to 4.4.2 without too much trouble. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41222
[Bug fortran/41222] -std=f95 forbids USEd functions named like f03/f08 intrisics
--- Comment #2 from kargl at gcc dot gnu dot org 2009-09-01 23:53 --- The problem appears to be fixed in trunk. troutmask:sgk[205] gfc4x -o z t.f90 troutmask:sgk[206] ./z 1. troutmask:sgk[207] gfc4x -o z -std=f95 t.f90 troutmask:sgk[208] ./z 1. troutmask:sgk[209] gfc4x --version GNU Fortran (GCC) 4.5.0 20090901 (experimental) Copyright (C) 2009 Free Software Foundation, Inc. Note, I haven't given any thought to the program and the options used as what the correct behavior ought to be. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.4.2 Known to work||4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41222
[Bug fortran/41222] -std=f95 forbids USEd functions named like f03/f08 intrisics
--- Comment #3 from pablomme at googlemail dot com 2009-09-02 00:10 --- Indeed this is a duplicate of bug 39876, sorry for not finding that earlier. Thanks! *** This bug has been marked as a duplicate of 39876 *** -- pablomme at googlemail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41222
[Bug fortran/39876] module procedure name that collides with the GNU intrinsic
--- Comment #7 from pablomme at googlemail dot com 2009-09-02 00:10 --- *** Bug 41222 has been marked as a duplicate of this bug. *** -- pablomme at googlemail dot com changed: What|Removed |Added CC||pablomme at googlemail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39876
[Bug fortran/39229] No warning of truncated lines if a continuation line follows
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2009-09-02 01:03 --- Subject: Bug 39229 Author: jvdelisle Date: Wed Sep 2 01:03:34 2009 New Revision: 151309 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151309 Log: 2009-09-01 Jerry DeLisle jvdeli...@gcc.gnu.org PR fortran/39229 * gfortran.dg/line_length_3.f: New test. * gfortran.dg/line_length_4.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/line_length_3.f trunk/gcc/testsuite/gfortran.dg/line_length_4.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39229
[Bug fortran/39229] No warning of truncated lines if a continuation line follows
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2009-09-02 01:19 --- Closing. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39229
[Bug rtl-optimization/24319] [4.3/4.4/4.5 regression] amd64 register spill error with -fschedule-insns
--- Comment #18 from lucier at math dot purdue dot edu 2009-09-02 02:54 --- Vlad: The patch works great in my tests so far, thanks. After installing your patch on today's trunk so that -fschedule-insns actually works, I find it is quite expensive on large files. For example, with today's trunk with your patches applied, for the file http://www.math.purdue.edu/~lucier/bugzilla/8/_num.i.gz and the options /pkgs/gcc-mainline-schedule/bin/gcc -Wno-unused -O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fwrapv -fomit-frame-pointer -fPIC -fno-common -mieee-fp -ftime-report -c _num.i total CPU time on my x86-64 box is TOTAL : 29.60 0.9230.54 176587 kB while with -fschedule-insns it is scheduling: 23.03 (42%) usr 0.02 ( 2%) sys 23.07 (41%) wall 2125 kB ( 1%) ggc TOTAL : 55.47 1.0356.57 180793 kB I don't know whether you can make it go faster now, or whether that's unreasonable and I should just wait and file another PR. Brad -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24319
[Bug c++/41223] New: [4.4.1] template template member function - error: no matching function for call ...
With the code:
// begin redux.cc
#include string
#include vector
struct C
{
templatetypename Element, templatetypename T class Container
void member_template(ContainerElement container)
{}
};
int main(int,char**)
{
std::vectorstd::string entries;
C().member_template(entries);
}
//end redux.cc
while compiling with 4.4.1 (host:=x86_64, target:=x86_64), I get the following
error:
redux.cc: In function int main(int, char**):
redux.cc:14: error: no matching function for call to
C::member_template(std::vectorstd::basic_stringchar, std::char_traitschar,
std::allocatorchar , std::allocatorstd::basic_stringchar,
std::char_traitschar, std::allocatorchar )
With 3.4.6 (host:=x86_64, target=mips) and 4.1.2 (host:=i386, target=i386), the
code compiles and links without any errors (and works as expected).
--
Summary: [4.4.1] template template member function - error: no
matching function for call ...
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at portuosus dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41223
[Bug c++/41223] [4.4.1] template template member function - error: no matching function for call ...
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-09-02 05:12 --- This code is invalid. The reason is std::vector is a template that takes two template arguments (with a default one). So templatetypename T class Container does not match std::vector in 4.4. This was a removed undocumented extension. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41223
[Bug fortran/41222] -std=f95 forbids USEd functions named like f03/f08 intrisics
--- Comment #4 from kargl at gcc dot gnu dot org 2009-09-02 05:19 --- (In reply to comment #3) Indeed this is a duplicate of bug 39876, sorry for not finding that earlier. Thanks! *** This bug has been marked as a duplicate of 39876 *** Speaking as one of the gfortran hackers, we would rather get a duplicate bug report than no report at all. In particular, with a small self-contained test case, it is sgtraight forward to test multiple versions of gfortran. In fact, I've found that this is a regression from 4.3.x and the patch in 4.5.0 is fairly simple. I'll see if I can backport it this weekend. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Known to work|4.5.0 |4.5.0 4.3.3 Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41222
