[Bug fortran/43217] Output of Hollerith constants which are not a multiple of 4 bytes
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2010-08-27 06:50 --- Subject: Bug 43217 Author: jvdelisle Date: Fri Aug 27 06:50:03 2010 New Revision: 163581 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163581 Log: 2010-08-27 Jerry DeLisle jvdeli...@gcc.gnu.org PR fortran/43217 * primary.c (match_hollerith_constant): Calculate padding needed to fill default integer and allocate string for that size. Set pad bytes to ' '. * gfortran.h: Add hollerith pad value to type spec union. * data.c (create_character_initializer): Fix spelling of function name. Use hollerith pad value to calculate length. * arith.c (hollerith2representation); Use hollerith pad value to calculate length. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/arith.c trunk/gcc/fortran/data.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/primary.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43217
[Bug fortran/43217] Output of Hollerith constants which are not a multiple of 4 bytes
--- Comment #9 from burnus at gcc dot gnu dot org 2010-08-27 07:26 --- Close as FIXED (on the 4.6 trunk). Thanks for fixing it, Jerry! -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43217
[Bug fortran/44044] [OOP] SELECT TYPE with class-valued function
--- Comment #8 from burnus at gcc dot gnu dot org 2010-08-27 07:30 --- (In reply to comment #7) So the only ToDo item left here is comment #3. Which is C836, i.e. checking invalid use of the selector in a variable definition context. This will probably be fixes as part of PR 38936 (ASSOCIATE construct; SELECT TYPE uses it internally) - thus mark this PR as depending on PR 38936. -- burnus at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||38936 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44044
[Bug fortran/45420] [OOP] polymorphic TBP call in a CLASS DEFAULT clause
--- Comment #3 from sfilippone at uniroma2 dot it 2010-08-27 07:37 --- (In reply to comment #2) It turns out this bug is rather easy to fix. The problem was the we used the temporary needed for the TYPE IS clause also in the CLASS DEFAULT clause (where we need none). The following patch fixes it (haven't checked for regressions yet): Hi, First, the patch did not apply cleanly, the first hunk was rejected. I applied it by hand, and I got a problem down the road in my library: === gfortran -ggdb -I.. -I../modules -I. -c psb_srwextd.f90 psb_srwextd.f90:76.13: call aa%mv_to_coo(actmp,info) 1 Error: Actual argument at (1) must be definable as the dummy argument 'a' is INTENT = OUT/INOUT psb_srwextd.f90:84.39: if (info == psb_success_) call aa%mv_from_coo(actmp,info) 1 Error: Actual argument at (1) must be definable as the dummy argument 'a' is INTENT = OUT/INOUT The relevant piece of code is as follows: subroutine psb_srwextd(nr,a,info,b,rowscale) use psb_sparse_mod, psb_protect_name = psb_srwextd implicit none ! Extend matrix A up to NR rows with empty ones (i.e.: all zeroes) integer, intent(in) :: nr type(psb_s_sparse_mat), intent(inout):: a integer,intent(out) :: info type(psb_s_sparse_mat), intent(in), optional :: b logical,intent(in), optional :: rowscale integer :: i,j,ja,jb,err_act,nza,nzb character(len=20) :: name, ch_err type(psb_s_coo_sparse_mat):: actmp logical rowscale_ name='psb_srwextd' info = psb_success_ call psb_erractionsave(err_act) if (nr a%get_nrows()) then select type(aa= a%a) type is (psb_s_csr_sparse_mat) if (present(b)) then call psb_rwextd(nr,aa,info,b%a,rowscale) else call psb_rwextd(nr,aa,info,rowscale=rowscale) end if type is (psb_s_coo_sparse_mat) if (present(b)) then call psb_rwextd(nr,aa,info,b%a,rowscale=rowscale) else call psb_rwextd(nr,aa,info,rowscale=rowscale) end if class default call aa%mv_to_coo(actmp,info) if (info == psb_success_) then if (present(b)) then call psb_rwextd(nr,actmp,info,b%a,rowscale=rowscale) else call psb_rwextd(nr,actmp,info,rowscale=rowscale) end if end if if (info == psb_success_) call aa%mv_from_coo(actmp,info) end select end if if (info /= psb_success_) goto call psb_erractionrestore(err_act) return continue call psb_erractionrestore(err_act) if (err_act == psb_act_abort_) then call psb_error() return end if return end subroutine psb_srwextd == The calls to AA%MV_TO ad AA%MV_FROM should be able to modify AA, since 1. AA = A%A 2. A is an INOUT dummy argument. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45420
[Bug rtl-optimization/45416] Code size regression between 4.6(4.5) and 4.4 for ARM
-- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||missed-optimization Known to fail||4.5.0 4.5.1 Known to work||4.4.5 Last reconfirmed|-00-00 00:00:00 |2010-08-27 07:41:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45416
[Bug fortran/45424] New: F2008: Add is_contiguous intrinsic
For compile-time checking that can simply use the the gfc_is_simply_contiguous check. For run time, it should use the flag in the descriptor (if existing) or some library check, cf. pack checks. Because of the potential descriptor element, mark dependent on PR 36825. From Fortran 2008: 13.7.86 IS_CONTIGUOUS (ARRAY) Description. Test contiguity of an array (5.3.7). Class. Inquiry function. Argument. ARRAY may be of any type. It shall be an array. If it is a pointer it shall be associated. Result Characteristics. Default logical scalar. Result Value. The result has the value true if ARRAY is contiguous, and false otherwise. Example. After the pointer assignment AP = TARGET (1:10:2), IS_CONTIGUOUS (AP) has the value false. -- Summary: F2008: Add is_contiguous intrinsic Product: gcc Version: 4.6.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 BugsThisDependsOn: 36825 OtherBugsDependingO 39627 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45424
[Bug fortran/45277] make bootstrap fails at:checking whether the GNU Fortran compiler is working... no
--- Comment #5 from philippe_scelers at mentor dot com 2010-08-27 08:29 --- make check: OK for GMP but fails for MPFR Solution: build GMP, MPFR and MPC separately and add --with-... to configure gcc. Note: GMP must be build for 32 bits, i.e. set env var ABI=32 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45277
[Bug fortran/45308] [F2003] DATE_AND_TIME does _not_ blank-pad strings
--- Comment #6 from burnus at gcc dot gnu dot org 2010-08-27 09:03 --- Close as FIXED (on the 4.6 trunk). Thanks, Jakub, for the patch! -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Summary|[F2003] DATE_AND_TIME does |[F2003] DATE_AND_TIME does |_not_ black-pad strings |_not_ blank-pad strings http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45308
[Bug fortran/45420] [OOP] polymorphic TBP call in a CLASS DEFAULT clause
--- Comment #4 from janus at gcc dot gnu dot org 2010-08-27 09:06 --- (In reply to comment #3) First, the patch did not apply cleanly, the first hunk was rejected. I applied it by hand, and I got a problem down the road in my library: === gfortran -ggdb -I.. -I../modules -I. -c psb_srwextd.f90 psb_srwextd.f90:76.13: call aa%mv_to_coo(actmp,info) 1 Error: Actual argument at (1) must be definable as the dummy argument 'a' is INTENT = OUT/INOUT psb_srwextd.f90:84.39: if (info == psb_success_) call aa%mv_from_coo(actmp,info) 1 Error: Actual argument at (1) must be definable as the dummy argument 'a' is INTENT = OUT/INOUT I tried to reproduce this by modifying your original test case, but did not succeed so far. Can you provide a standalone test case for this problem? My feeling is that this is another bug uncovered by the fix for the previous one. The patch in comment #2 is free of testsuite regressions and certainly does the right thing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45420
[Bug target/41484] Please add memory forms of pmovzx* (SSE4.1)
--- Comment #3 from ubizjak at gmail dot com 2010-08-27 09:20 --- Confirmed. -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-08-27 09:20:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41484
[Bug target/41484] Please add memory forms of pmovzx* (SSE4.1)
--- Comment #4 from ubizjak at gmail dot com 2010-08-27 09:26 --- Created an attachment (id=21576) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21576action=view) Patch to remove special (vec_duplicate ...) insn RTXes This patch removes special (vec_duplicate ...) forms of zero/sign extension instructions. This is similar to existing sse2_cvtps2pd pattern that access full 128bit memory even if only low 64bits are used. Also, current gcc generates: movdqa (%rdi), %xmm0 # 6 *movv16qi_internal/2[length = 4] pmovzxbd%xmm0, %xmm0# 7 sse4_1_zero_extendv4qiv4si2 which also access full 128bit 16byte aligned value. This is no better than: pmovzxbd(%rdi), %xmm0 # 7 sse4_1_zero_extendv4qiv4si2 Patch is untested, since I don't have required HW. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41484
[Bug java/45322] libjava error: libtool: compile: libobj name `ltdl.lo' may not contain shell special
--- Comment #2 from jay dot krell at cornell dot edu 2010-08-27 09:53 --- Wow, could this be checked for earlier? It goes a long way before erroring. Thanks. I'll try again with bash. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45322
[Bug fortran/45425] New: where mask not applied before where clause evaluated
This is the system uname -a Linux argux9.fuqua.duke.edu 2.6.18-194.3.1.el5 #1 SMP Thu May 13 13:08:30 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux This is the compiler gfortran44 --version GNU Fortran (GCC) 4.4.0 20090514 (Red Hat 4.4.0-6) Copyright (C) 2009 Free Software Foundation, Inc. This is the problem The bug is that the mask is supposed to be applied before the statements within the where clause are evaluated. As can be seen from the output the statements within the mask are evaluated before the mask is applied. This is the relevant code do k = 1, rows + 1 if ( (k .gt. rows) .or. (k .gt. cols) ) then mask = .false. else mask = .true. end if where (mask) A = b(k) end where end do These are the compiler flags -save-temps -fbounds-check This is stderr At line 39 of file wherebug.F90 Fortran runtime error: Array reference out of bounds for array 'b', upper bound of dimension 1 exceeded (6 5) This is the -save-temps file a...@argux9$ cat wherebug.f90 # 1 wherebug.F90 # 1 built-in # 1 command-line # 1 wherebug.F90 program wherebug implicit none integer, parameter :: stdin = 5, ! reserved unit for standard input stdout= 6, ! reserved unit for standard output stderr= 0 ! reserved unit for standard error integer, parameter :: i1 = selected_int_kind(2), i2 = selected_int_kind(4), i4 = selected_int_kind(9), i8 = selected_int_kind(18), r4 = kind(1.0), r8 = selected_real_kind(2*precision(1.0_r4)), r16 = selected_real_kind(2*precision(1.0_r8)) integer, parameter :: rows = 5, cols = 5 integer :: i, j, k real(r8), dimension(rows,cols) :: A real(r8), dimension(rows) :: b logical, dimension(rows,cols) :: mask A = 1.0_r8 b = 1.0_r8 mask = .true. do k = 1, rows + 1 if ( (k .gt. rows) .or. (k .gt. cols) ) then mask = .false. else mask = .true. end if where (mask) A = b(k) end where end do end program wherebug -- Summary: where mask not applied before where clause evaluated Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aronaldg at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45425
[Bug fortran/45426] New: Fixed-form: END may not be continued
Fortran 2008 (and earlier) have: 3.3.3.5 Fixed form statements The program unit END statement shall not be continued. A statement whose initial line appears to be a program unit END statement shall not be continued. (That applies to all END: A program unit is a main program, an external subprogram, a module, a submodule, or a block data program unit.) gfortran currently does not diagnose this: a) EXAMPLE 1: initial line appears to be a program unit END statement integer :: ender end +er = 5 print *, ender end b) EXAMPLE 2: END statement which is continued subroutine test end * subroutine test Expected: With -std=f2008 / -pedantic, the continuation line is rejected / being warned for - with -std=gnu/legacy it is accepted. Intel's ifort prints with -stand f03: test.f(2): error #5269: Operator END of program unit cannot be continued. end --^ Though I do not like Intel's wording. -- Summary: Fixed-form: END may not be continued Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: accepts-invalid 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=45426
[Bug fortran/45426] Fixed-form: END may not be continued
--- Comment #1 from burnus at gcc dot gnu dot org 2010-08-27 10:11 --- I learned about this restriction at http://groups.google.com/group/comp.lang.fortran/msg/94c45e3d727f49fc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45426
[Bug fortran/43217] Output of Hollerith constants which are not a multiple of 4 bytes
--- Comment #10 from dominiq at lps dot ens dot fr 2010-08-27 10:23 --- I think the test case has not been committed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43217
[Bug middle-end/45422] [4.6 Regression] compile time increases 8x.
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-08-27 10:23 --- Can also be seen here: http://gcc.opensuse.org/SPEC/CFP/sb-barbella.suse.de-head-64-2006/times.html and here: http://gcc.opensuse.org/c++bench-frescobaldi/polyhedron/polyhedron-summary.txt-1-0.html I'm looking at a profile. -- rguenth 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-08-27 10:23:21 date|| Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45422
[Bug lto/44812] m32 lto produces non-relocatable subtraction expression errors
--- Comment #23 from dominiq at lps dot ens dot fr 2010-08-27 10:30 --- With the patch in comment #21 I get for powerpc-apple-darwin9 Running target unix/-m32 Using /sw/share/dejagnu/baseboards/unix.exp as board description file for target. Using /sw/share/dejagnu/config/unix.exp as generic interface file for target. Using /opt/gcc/gcc-4.6-work/gcc/testsuite/config/default.exp as tool-and-target-specific interface file. Running /opt/gcc/gcc-4.6-work/gcc/testsuite/gcc.dg/lto/lto.exp ... === gcc Summary for unix/-m32 === # of expected passes618 # of unsupported tests 8 Running target unix/-m64 Using /sw/share/dejagnu/baseboards/unix.exp as board description file for target. Using /sw/share/dejagnu/config/unix.exp as generic interface file for target. Using /opt/gcc/gcc-4.6-work/gcc/testsuite/config/default.exp as tool-and-target-specific interface file. Running /opt/gcc/gcc-4.6-work/gcc/testsuite/gcc.dg/lto/lto.exp ... FAIL: gcc.dg/lto/20090116 c_lto_20090116_0.o-c_lto_20090116_0.o link, -O1 -fwhopr -fPIC (internal compiler error) === gcc Summary for unix/-m64 === # of expected passes617 # of unexpected failures1 # of unresolved testcases 1 # of unsupported tests 8 === gcc Summary === # of expected passes1235 # of unexpected failures1 # of unresolved testcases 1 # of unsupported tests 16 /opt/gcc/darwin_buildw/gcc/xgcc version 4.6.0 20100825 (experimental) [trunk revision 163553p1b] (GCC) and Running target unix/-m32 Using /sw/share/dejagnu/baseboards/unix.exp as board description file for target. Using /sw/share/dejagnu/config/unix.exp as generic interface file for target. Using /opt/gcc/gcc-4.6-work/gcc/testsuite/config/default.exp as tool-and-target-specific interface file. Running /opt/gcc/gcc-4.6-work/gcc/testsuite/g++.dg/lto/lto.exp ... FAIL: g++.dg/lto/20081109 cp_lto_20081109_0.o-cp_lto_20081109_1.o execute -O2 -fwhopr FAIL: g++.dg/lto/20100723-1 cp_lto_20100723-1_0.o-cp_lto_20100723-1_0.o link, -fcompare-debug -flto (internal compiler error) FAIL: g++.dg/lto/20100723-1 cp_lto_20100723-1_0.o-cp_lto_20100723-1_0.o link, -fcompare-debug -fwhopr (internal compiler error) === g++ Summary for unix/-m32 === # of expected passes459 # of unexpected failures3 # of unresolved testcases 2 # of unsupported tests 1 Running target unix/-m64 Using /sw/share/dejagnu/baseboards/unix.exp as board description file for target. Using /sw/share/dejagnu/config/unix.exp as generic interface file for target. Using /opt/gcc/gcc-4.6-work/gcc/testsuite/config/default.exp as tool-and-target-specific interface file. Running /opt/gcc/gcc-4.6-work/gcc/testsuite/g++.dg/lto/lto.exp ... FAIL: g++.dg/lto/20081109 cp_lto_20081109_0.o-cp_lto_20081109_1.o execute -O2 -fwhopr FAIL: g++.dg/lto/20100723-1 cp_lto_20100723-1_0.o-cp_lto_20100723-1_0.o link, -fcompare-debug -flto (internal compiler error) FAIL: g++.dg/lto/20100723-1 cp_lto_20100723-1_0.o-cp_lto_20100723-1_0.o link, -fcompare-debug -fwhopr (internal compiler error) === g++ Summary for unix/-m64 === # of expected passes459 # of unexpected failures3 # of unresolved testcases 2 # of unsupported tests 1 === g++ Summary === # of expected passes918 # of unexpected failures6 # of unresolved testcases 4 # of unsupported tests 2 /opt/gcc/darwin_buildw/gcc/testsuite/g++/../../g++ version 4.6.0 20100825 (experimental) [trunk revision 163553p1b] (GCC) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44812
[Bug fortran/45420] [OOP] polymorphic TBP call in a CLASS DEFAULT clause
--- Comment #5 from sfilippone at uniroma2 dot it 2010-08-27 11:38 --- (In reply to comment #4) (In reply to comment #3) I tried to reproduce this by modifying your original test case, but did not succeed so far. Can you provide a standalone test case for this problem? My feeling is that this is another bug uncovered by the fix for the previous one. The patch in comment #2 is free of testsuite regressions and certainly does the right thing. Ok, go ahead with this fix, and I will open a new PR as appropriate. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45420
[Bug middle-end/45422] [4.6 Regression] compile time increases 8x.
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-08-27 11:41 --- Reproducable with -O3 alone, -fbounds-check makes it more visible. With plain -O3: tree iv optimization : 22.64 (33%) usr 0.18 (11%) sys 22.97 (32%) wall 113858 kB (16%) ggc and with added -fbounds-check: tree iv optimization : 184.70 (78%) usr 0.67 (31%) sys 186.67 (78%) wall 166066 kB (18%) ggc this connection with bounds-checking makes it sound familiar. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45422
[Bug middle-end/45422] [4.6 Regression] compile time increases 8x.
--- Comment #4 from jv244 at cam dot ac dot uk 2010-08-27 11:45 --- (In reply to comment #3) this connection with bounds-checking makes it sound familiar. I had a similar bug open (and fixed) as PR43627 with a comment from you http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43627#c11 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45422
[Bug fortran/45425] Bounds check applied before MASK of WHERE construct
--- Comment #1 from burnus at gcc dot gnu dot org 2010-08-27 11:58 ---
Confirm, the bounds checks are misplaces. Simplified test case:
implicit none
integer :: A(1), i,b(1)
logical :: mask(1)
mask = .false.
b = 5
do i = 2, 2
where (mask)
A = b(i)
end where
end do
end
If one looks at the dump of the internal representation (-fdump-tree-original)
one sees that WHERE itself is properly handled - only the bounds check is
outside of the WHERE loop and thus outside of the MASK:
if (__builtin_expect (i = 0, 0))
_gfortran_runtime_error_at (...);
[...]
S.1 = 1;
while (1)
{
if (S.1 1) goto L.4;
if (mask[S.1 + -1])
{
a[S.1 + -1] = b[i + -1];
}
S.1 = S.1 + 1;
}
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO||27766
nThis||
Keywords||wrong-code
Known to fail||4.1.2 4.6.0
Summary|where mask not applied |Bounds check applied before
|before where clause |MASK of WHERE construct
|evaluated |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45425
[Bug middle-end/45422] [4.6 Regression] compile time increases 8x.
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-08-27 12:06 --- MODULE hfx_contract_block INTEGER, PARAMETER :: dp=KIND(0.0D0) CONTAINS SUBROUTINE block_9_2(mc_max,md_max,kbd,kbc,kad,kac,pbd,pbc,pad,pac,prim,scale) INTEGER :: mc_max, md_max REAL(KIND=dp) :: kbd(2*md_max), kbc(2*mc_max), kad(9*md_max), kac(9*mc_max), pbd(2*md_max), pbc(2*mc_max), pad(9*md_max), pac(9*mc_max), prim(9*2*mc_max*md_max), scale INTEGER :: ma, mb, mc, md, p_index REAL(KIND=dp):: ks_bc, ks_bd, p_bc, p_bd, tmp kbd(1:2*md_max) = 0.0_dp kbc(1:2*mc_max) = 0.0_dp kad(1:9*md_max) = 0.0_dp kac(1:9*mc_max) = 0.0_dp p_index = 0 DO md = 1,md_max DO mc = 1,mc_max DO mb = 1,2 ks_bd = 0.0_dp ks_bc = 0.0_dp p_bd = pbd((md-1)*2+mb) p_bc = pbc((mc-1)*2+mb) DO ma = 1,9 p_index=p_index+1 tmp = scale*prim(p_index) ks_bc = ks_bc + tmp* pad((md-1)*9+ma) ks_bd = ks_bd + tmp* pac((mc-1)*9+ma) kad((md-1)*9+ma) = kad((md-1)*9+ma)-tmp*p_bc kac((mc-1)*9+ma) = kac((mc-1)*9+ma)-tmp*p_bd END DO kbd((md-1)*2+mb) = kbd((md-1)*2+mb) - ks_bd kbc((mc-1)*2+mb) = kbc((mc-1)*2+mb) - ks_bc END DO END DO END DO END SUBROUTINE block_9_2 END MODULE gfortran -S -O3 -ffree-form -fbounds-check t.f90 -ftime-report tree iv optimization : 3.49 (94%) usr 0.00 ( 0%) sys 3.52 (94%) wall 2272 kB (36%) ggc can someone try to track down revisions that slowed that testcase down? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45422
[Bug fortran/45159] Unnecessary temporaries
--- Comment #20 from tkoenig at gcc dot gnu dot org 2010-08-27 12:09 --- Subject: Bug 45159 Author: tkoenig Date: Fri Aug 27 12:08:47 2010 New Revision: 163584 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163584 Log: 2010-08-27 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/45159 * dependency.c (check_section_vs_section): Single test for identical strides which takes into account that only one of the strides may be NULL. 2010-08-27 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/45159 * gfortran.dg/dependency_33.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/dependency_33.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dependency.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45159
[Bug lto/44812] m32 lto produces non-relocatable subtraction expression errors
--- Comment #24 from howarth at nitro dot med dot uc dot edu 2010-08-27 12:10 --- Testsuite results for m32_to_fix2.diff at http://gcc.gnu.org/ml/gcc-testresults/2010-08/msg02690.html. This approach completely fixes the darwin-specific lto failures on x86_64-apple-darwin10. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44812
[Bug fortran/44235] array temporary with high upper bound
--- Comment #13 from tkoenig at gcc dot gnu dot org 2010-08-27 12:12 --- Fixed on trunk. Closing. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44235
[Bug target/45094] [arm] wrong instructions for dword move in some cases
--- Comment #7 from ramana at gcc dot gnu dot org 2010-08-27 12:14 --- can this be backported to the 4.5 branch please ? -- ramana at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45094
[Bug middle-end/45422] [4.6 Regression] compile time increases 8x.
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-08-27 12:16 --- Without -fbounds-check we have around 650 million calls to iv_ca_get_num_inv_exprs ... called from iv_ca_recount_cost. With -fbounds-check this balloons to nearly 5 billion calls to that function. David - this sounds like your changes, can you have a look to possibly reduce this number of calls? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||xinliangli at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45422
[Bug target/45250] [4.6 Regression] FAIL: tr1/5_numerical_facilities/special_functions/01_assoc_laguerre/check_nan.cc
--- Comment #3 from danglin at gcc dot gnu dot org 2010-08-27 12:50 --- Introduced in revision 162337: 2010-07-20 Jakub Jelinek ja...@redhat.com * var-tracking.c (vt_expand_loc, vt_expand_loc_dummy): Bump maximum depth to 8 from 5. -- danglin at gcc dot gnu dot org changed: What|Removed |Added CC||jakub at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45250
[Bug middle-end/45422] [4.6 Regression] compile time increases 8x.
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-08-27 13:01 --- The few remaining bound checks do not look simple to remove (if at all). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45422
[Bug libfortran/45323] warnings compiling libgfortran/io/write.c: array subscript has type 'char'
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2010-08-27 13:25 --- Closing as fixed. Please reopen if the problem has not gone away. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45323
[Bug fortran/39654] ABI bug: FTELL intrinsic function not capable of large files
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-08-27 13:27:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39654
[Bug lto/44812] m32 lto produces non-relocatable subtraction expression errors
--- Comment #25 from howarth at nitro dot med dot uc dot edu 2010-08-27 13:54 --- Created an attachment (id=21577) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21577action=view) m32 darwin lto fix using external -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44812
[Bug lto/44812] m32 lto produces non-relocatable subtraction expression errors
--- Comment #26 from howarth at nitro dot med dot uc dot edu 2010-08-27 13:59 --- (In reply to comment #25) Created an attachment (id=21577) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21577action=view) [edit] m32 darwin lto fix using external This version almost works. However I get the following c++ lto failures... FAIL: g++.dg/lto/20081022 cp_lto_20081022_0.o-cp_lto_20081022_1.o link, -O0 -fwhopr UNRESOLVED: g++.dg/lto/20081022 cp_lto_20081022_0.o-cp_lto_20081022_1.o execute -O0 -fwhopr FAIL: g++.dg/lto/20081125 cp_lto_20081125_0.o-cp_lto_20081125_1.o link, -fwhopr UNRESOLVED: g++.dg/lto/20081125 cp_lto_20081125_0.o-cp_lto_20081125_1.o execute -fwhopr FAIL: g++.dg/lto/20081203 cp_lto_20081203_0.o-cp_lto_20081203_1.o link, -O0 -fwhopr UNRESOLVED: g++.dg/lto/20081203 cp_lto_20081203_0.o-cp_lto_20081203_1.o execute -O0 -fwhopr FAIL: g++.dg/lto/20090311 cp_lto_20090311_0.o-cp_lto_20090311_1.o link, -O0 -fwhopr UNRESOLVED: g++.dg/lto/20090311 cp_lto_20090311_0.o-cp_lto_20090311_1.o execute -O0 -fwhopr FAIL: g++.dg/lto/20090311 cp_lto_20090311_0.o-cp_lto_20090311_1.o link, -O2 -fwhopr UNRESOLVED: g++.dg/lto/20090311 cp_lto_20090311_0.o-cp_lto_20090311_1.o execute -O2 -fwhopr FAIL: g++.dg/lto/20091210-1 cp_lto_20091210-1_0.o-cp_lto_20091210-1_1.o link, -O0 -fwhopr UNRESOLVED: g++.dg/lto/20091210-1 cp_lto_20091210-1_0.o-cp_lto_20091210-1_1.o execute -O0 -fwhopr FAIL: g++.dg/lto/20091210-1 cp_lto_20091210-1_0.o-cp_lto_20091210-1_1.o link, -O2 -fwhopr UNRESOLVED: g++.dg/lto/20091210-1 cp_lto_20091210-1_0.o-cp_lto_20091210-1_1.o execute -O2 -fwhopr FAIL: g++.dg/lto/20100723-1 cp_lto_20100723-1_0.o-cp_lto_20100723-1_0.o link, -fcompare-debug -flto (internal compiler error) UNRESOLVED: g++.dg/lto/20100723-1 cp_lto_20100723-1_0.o-cp_lto_20100723-1_0.o execute -fcompare-debug -flto FAIL: g++.dg/lto/20100723-1 cp_lto_20100723-1_0.o-cp_lto_20100723-1_0.o link, -fcompare-debug -fwhopr (internal compiler error) UNRESOLVED: g++.dg/lto/20100723-1 cp_lto_20100723-1_0.o-cp_lto_20100723-1_0.o execute -fcompare-debug -fwhopr Executing on host: /sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/testsuite/g++/../../g++ -B/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/testsuite/g++/../../ cp_lto_20081022_0.o cp_lto_20081022_1.o -nostdinc++ -I/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/x86_64-apple-darwin10.5.0/i386/libstdc++-v3/include/x86_64-apple-darwin10.5.0 -I/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/x86_64-apple-darwin10.5.0/i386/libstdc++-v3/include -I/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20100826/libstdc++-v3/libsupc++ -I/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20100826/libstdc++-v3/include/backward -I/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20100826/libstdc++-v3/testsuite/util -fmessage-length=0 -O0 -fwhopr -L/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/x86_64-apple-darwin10.5.0/i386/libstdc++-v3/src/.libs -B/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/x86_64-apple-darwin10.5.0/i386/libstdc++-v3/src/.libs -L/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/x86_64-apple-darwin10.5.0/i386/libstdc++-v3/src/.libs -L/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/x86_64-apple-darwin10.5.0/i386/libiberty -multiply_defined suppress -m32 -o g++-dg-lto-20081022-01(timeout = 300) Undefined symbols:^M __ZN3foo3barEv, referenced from:^M __Z1gP3foo in ccxsAxgO.ltrans0.ltrans.o^M __Z1fP3foo in ccxsAxgO.ltrans1.ltrans.o^M ld: symbol(s) not found^M On the positive side, all of the original non-relocatable subtraction expression errors are gone. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44812
[Bug fortran/43217] Output of Hollerith constants which are not a multiple of 4 bytes
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2010-08-27 14:02 --- Dominiq, can you test the output of the test case for me on PPC? hollerith8.f90 in the gfortran post. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43217
[Bug fortran/45277] make bootstrap fails at:checking whether the GNU Fortran compiler is working... no
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2010-08-27 14:02 --- make check: OK for GMP but fails for MPFR Solution: build GMP, MPFR and MPC separately and add --with-... to configure gcc. Note: GMP must be build for 32 bits, i.e. set env var ABI=32 Yes, or else configure with --build=... as documented in http://gcc.gnu.org/install/specific.html#sparc-sun-solaris2 Could you quickly sum up what you've found, i.e. which versions of GMP/MPFR are miscompiled by which versions of GCC and which versions are correctly compiled by which versions of the compiler? Thanks in advance. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45277
[Bug lto/44812] m32 lto produces non-relocatable subtraction expression errors
--- Comment #27 from howarth at nitro dot med dot uc dot edu 2010-08-27 14:13 --- Created an attachment (id=21578) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21578action=view) corrected m32 darwin lto fix using external -- howarth at nitro dot med dot uc dot edu changed: What|Removed |Added Attachment #21577|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44812
[Bug lto/44812] m32 lto produces non-relocatable subtraction expression errors
--- Comment #28 from howarth at nitro dot med dot uc dot edu 2010-08-27 14:15 --- (In reply to comment #27) Created an attachment (id=21578) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21578action=view) [edit] corrected m32 darwin lto fix using external My mistake. The additional assemble_external() calls weren't needed in lto-cgraph.c and this reduced patch produces the same errors. Any idea of what is happening to ltrans such that the symbols become undefined now? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44812
[Bug c/45407] internal compiler error gcc 4.5.1
--- Comment #8 from bbiswas at email dot unc dot edu 2010-08-27 14:19 --- Subject: Re: internal compiler error gcc 4.5.1 I successfully built gcc on Solaris 10 using these versions of gmp/mpfr/mpc: gmp 4.3.2 mpfr 2.4.2 mpc 0.8.1 The instructions on the prerequisites.html page you reference below say to use those versions (or later). I'd recommend listing what versions you have tested gcc with and say simply that other versions haven't been tested. I originally used the latest version of those three libraries: gmp 5.0.1 mpfr 3.0.0 mpc 0.8.2 Those three libraries _will_ work when building gcc on Linux or AIX--but not Solaris (you get the internal compiler error message in the bug report I originally submitted). I tried various combinations as well on Solaris (e.g. gmp 4.3.2, mpfr 2.4.2, and mpc 0.8.2), but only using the three earlier versions (gmp 4.3.2, mpfr 2.4.2, mpc 0.8.1) worked. Anyway, we have gcc working on all platforms now. Thanks for all your help! --Brian On Aug 25, 2010, at 4:07 PM, ebotcazou at gcc dot gnu dot org wrote: --- Comment #7 from ebotcazou at gcc dot gnu dot org 2010-08-25 20:07 --- I did notice that the SUNWspro compilers were used to compile the latest versions of mpfr mpc we use. Should I try re-compiling mpfr and mpc with gcc and then rebuilding gcc 4.5.1? The problematic ones are GMP and MPFR. You should run 'make check' in the build dir once you have compiled them. I am using the latest versions of mpfr (3.0.0) and mpc (0.8.2). I didn't see anything in: http://gcc.gnu.org/install/prerequisites.html about certain gcc versions miscompiling either of those packages. Yes, but we cannot test all combinations of libraries so sticking with the recommended versions is the safest approach. These are regularly tested in conjunction with the compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45407 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45407
[Bug fortran/43217] Output of Hollerith constants which are not a multiple of 4 bytes
--- Comment #12 from dominiq at lps dot ens dot fr 2010-08-27 14:20 --- On ppc, the original test gives before patch 48454C4C 4F20594F 5500 So it seems that the test is likely to fail on ppc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43217
[Bug c/45407] internal compiler error gcc 4.5.1
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2010-08-27 14:36 --- I successfully built gcc on Solaris 10 using these versions of gmp/mpfr/mpc: gmp 4.3.2 mpfr 2.4.2 mpc 0.8.1 The instructions on the prerequisites.html page you reference below say to use those versions (or later). I'd recommend listing what versions you have tested gcc with and say simply that other versions haven't been tested. Thanks for your feedback. I'm going to add a blurb to the platform-specific instructions. I originally used the latest version of those three libraries: gmp 5.0.1 mpfr 3.0.0 mpc 0.8.2 Those three libraries _will_ work when building gcc on Linux or AIX--but not Solaris (you get the internal compiler error message in the bug report I originally submitted). I tried various combinations as well on Solaris (e.g. gmp 4.3.2, mpfr 2.4.2, and mpc 0.8.2), but only using the three earlier versions (gmp 4.3.2, mpfr 2.4.2, mpc 0.8.1) worked. Do you confirm that going from MPC 0.8.1 to 0.8.2 alone is problematic with GCC 4.1.2 as the base compiler? -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet||sparc-sun-solaris2.* GCC host triplet||sparc-sun-solaris2.* GCC target triplet||sparc-sun-solaris2.* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45407
[Bug fortran/45420] [OOP] polymorphic TBP call in a CLASS DEFAULT clause
--- Comment #6 from sfilippone at uniroma2 dot it 2010-08-27 14:40 --- (In reply to comment #3) end if class default call aa%mv_to_coo(actmp,info) if (info == psb_success_) then if (present(b)) then call psb_rwextd(nr,actmp,info,b%a,rowscale=rowscale) else call psb_rwextd(nr,actmp,info,rowscale=rowscale) end if end if if (info == psb_success_) call aa%mv_from_coo(actmp,info) end select If however I change the code as follows: select type(aa = a%a) class default call a%a%mv_to_coo(actmp,info) ... it compiles. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45420
[Bug tree-optimization/45427] New: Number of iteration analysis bogus
The analysis for nb_iterations_upper_bound is bogus when we derive bounds for
an exit check ptr == 0 (leading to an assert). The testcase looks like
(subroutine cxb3014__test_block__char_pointers__value from acats CXB3014):
bb 5:
# p_1 = PHI ref_58(3), p_52(8)
# h_2 = PHI 0(3), h_10(8)
D.3266_7 = *p_1;
if (D.3266_7 == terminator_9(D))
goto bb 9;
else
goto bb 6;
bb 6:
h_10 = h_2 + 1;
if (p_1 == 0B)
goto bb 7;
else
goto bb 8;
bb 7:
D.3760.P_ARRAY = i-cpoint.adb:59 instantiated at cxb3014.adb:114;
D.3760.P_BOUNDS = *.LC15;
ada.exceptions.raise_exception_always (char_pointers__pointer_error,
D.3760);
bb 8:
left.84_50 = (cxb3014__test_block__char_pointers__addr) p_13;
D.3762_51 = left.84_50 + 1;
p_52 = (cxb3014__test_block__char_pointers__element * {ref-all}) D.3762_51;
# DEBUG ref = p_52
# DEBUG p = p_52
goto bb 5;
bb 9:
...
when looking at the exit 6-7 number_of_iterations_ne is present with
iv-base (cxb3014__test_block__char_pointers__element * {ref-all}) ref_4(D)
and final 0B, the step is 1. We then do
else
{
s = fold_convert (niter_type, iv-step);
c = fold_build2 (MINUS_EXPR, niter_type,
fold_convert (niter_type, final),
fold_convert (niter_type, iv-base));
}
which creates -(UNSIGNED_64) ref_4(D) for c, with no_overflow set as we
do for pointers (but note we now have unsigned_type_for, a non-pointer!)
we obviously can't reach zero with a step of 1 without overflowing
without the initial value being zero.
I have a patch in the works that uses number of iteration analysis for
value-range propagation and that miscompiles CXB3014 because of the
above bug.
Zdenek - any idea?
--
Summary: Number of iteration analysis bogus
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45427
[Bug fortran/43217] Output of Hollerith constants which are not a multiple of 4 bytes
--- Comment #13 from dominiq at lps dot ens dot fr 2010-08-27 14:48 ---
The following test
! { dg-do run )
program hello2
call wrtout (9hHELLO YOU, 9)
stop
end
subroutine wrtout (iarray, nchrs)
integer(1), parameter :: zero = 0
LOGICAL, PARAMETER :: bigend = IACHAR(TRANSFER(1,a)) == zero
integer iarray(1)
integer nchrs
integer icpw
data icpw/4/
integer i, nwrds
character(len=33) outstr
nwrds = (nchrs + icpw - 1) /icpw
write(outstr,'(4(z8, ))') (iarray(i), i=1,nwrds)
if (.not.bigend.and.outstr.ne.4C4C4548 4F59204F 20202055) call abort
if (bigend.and.outstr.ne.48454C4C 4F20594F 55202020) call abort
return
end
! { dg-warning Hollerith constant { target *-*-* } 3 }
! { dg-warning Rank mismatch { target *-*-* } 3 }
seems to work on ppc and *86* platforms (please adjust the test according your
taste!-).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43217
[Bug tree-optimization/45427] Number of iteration analysis bogus
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-08-27 14:50 ---
C testcase:
extern void abort (void);
int __attribute__((noinline,noclone))
foo (char *p)
{
int h = 0;
do
{
if (*p == '\0')
break;
++h;
if (p == 0)
abort ();
++p;
}
while (1);
return h;
}
int main()
{
if (foo(a) != 1)
abort ();
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45427
[Bug tree-optimization/45427] Number of iteration analysis bogus
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-08-27 14:59 --- And here's the patch I'm talking about: http://gcc.gnu.org/ml/gcc-patches/2010-08/msg01981.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45427
[Bug fortran/43217] Output of Hollerith constants which are not a multiple of 4 bytes
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2010-08-27 15:00 --- Subject: Bug 43217 Author: jvdelisle Date: Fri Aug 27 15:00:11 2010 New Revision: 163588 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163588 Log: 2010-08-27 Jerry DeLisle jvdeli...@gcc.gnu.org PR libfortran/43217 * gfortran.dg/hollerith8.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/hollerith8.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43217
[Bug fortran/43217] Output of Hollerith constants which are not a multiple of 4 bytes
--- Comment #15 from jvdelisle at gcc dot gnu dot org 2010-08-27 15:01 --- Dominique, thanks for testing that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43217
[Bug c/45407] internal compiler error gcc 4.5.1
--- Comment #10 from bbiswas at email dot unc dot edu 2010-08-27 15:05 --- Subject: Re: internal compiler error gcc 4.5.1 Yes. mpc 0.8.2 includes symbols found in gmp 3.0.0. But you can't use gmp 3.0.0 because then gcc fails to build (internal compiler error). mpc 0.8.1 doesn't include those symbols, you can use gmp 4.3.2, and all is well. --Brian On Aug 27, 2010, at 10:36 AM, ebotcazou at gcc dot gnu dot org wrote: --- Comment #9 from ebotcazou at gcc dot gnu dot org 2010-08-27 14:36 --- I successfully built gcc on Solaris 10 using these versions of gmp/mpfr/mpc: gmp 4.3.2 mpfr 2.4.2 mpc 0.8.1 The instructions on the prerequisites.html page you reference below say to use those versions (or later). I'd recommend listing what versions you have tested gcc with and say simply that other versions haven't been tested. Thanks for your feedback. I'm going to add a blurb to the platform- specific instructions. I originally used the latest version of those three libraries: gmp 5.0.1 mpfr 3.0.0 mpc 0.8.2 Those three libraries _will_ work when building gcc on Linux or AIX--but not Solaris (you get the internal compiler error message in the bug report I originally submitted). I tried various combinations as well on Solaris (e.g. gmp 4.3.2, mpfr 2.4.2, and mpc 0.8.2), but only using the three earlier versions (gmp 4.3.2, mpfr 2.4.2, mpc 0.8.1) worked. Do you confirm that going from MPC 0.8.1 to 0.8.2 alone is problematic with GCC 4.1.2 as the base compiler? -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet||sparc-sun-solaris2.* GCC host triplet||sparc-sun-solaris2.* GCC target triplet||sparc-sun-solaris2.* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45407 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45407
[Bug c++/45428] New: Address of templete function even if named as a template-id is not properly determined
I do not know if this is a duplicate report as there are other similar tickets
about problems with addresses of overloads, but as far as I've seen none seems
to be reported against template-ids.
Consider this snippet.
---
struct function
{
void (*outline)(void *);
};
templatetypename _T
struct info
{
_T *t_0;
};
templatetypename _T
static void my_fun(info_T *_args)
{
}
templatetypename _T
void f(_T t)
{
function fun = {
(void(*)(void)) my_fun_T // This is test.cpp:22
};
}
int main(int argc, char *argv[])
{
int a = 3;
f(a);
float b = 1.0f;
f(b);
return 0;
}
---
g++ yields the following errors
test.cpp: In function ‘void f(_T) [with _T = int]’:
test.cpp:28: instantiated from here
test.cpp:22: error: insufficient contextual information to determine type
test.cpp: In function ‘void f(_T) [with _T = float]’:
test.cpp:30: instantiated from here
test.cpp:22: error: insufficient contextual information to determine type
A workaround that seems to work is using a double casting, a first one that
selects the right overload (even if this would not be needed as we passed all
the template-arguments of the template-id of the function and no
template-parameter is left to deduce) before the original casting.
templatetypename _T
void f(_T t)
{
function fun = {
(void(*)(void))(void (*)(info_T *_args)) my_fun_T
};
}
Neither __typeof__(my_fun_T) or decltype (C++0x) seem able to figure the
precise 'my_fun_T'.
Usign __typeof__ like in
(void(*)(void))(__typeof__(my_fun_T)) my_fun_T
yields a
test.cpp:22: error: type of ‘my_funint’ is unknown
while decltype (g++ -std=c++0x) used like in
(void(*)(void)) (decltype(my_fun_T)) my_fun_T
ends with an ICE
test.cpp:22: internal compiler error: in finish_decltype_type, at
cp/semantics.c:4694
I'm not entirely sure whether this scenario should be regarded as valid but
icc, comeau and xlc++ accept this code, so I'm inclined to think g++ should
accept it too.
--
Summary: Address of templete function even if named as a
template-id is not properly determined
Product: gcc
Version: 4.4.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: roger dot ferrer at bsc dot es
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45428
[Bug c++/45428] Address of template function even if fully named as a template-id is not properly determined
--- Comment #1 from redi at gcc dot gnu dot org 2010-08-27 15:15 --- (In reply to comment #0) (void(*)(void)) my_fun_T // This is test.cpp:22 Can I assume you meant to case to (void(*)(void*)) here? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45428
[Bug c++/45428] Address of template function even if fully named as a template-id is not properly determined
--- Comment #2 from redi at gcc dot gnu dot org 2010-08-27 15:21 --- (In reply to comment #1) (In reply to comment #0) (void(*)(void)) my_fun_T // This is test.cpp:22 Can I assume you meant to case to (void(*)(void*)) here? With that change 4.5 and 4.6 compile the code, but don't link -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45428
[Bug c++/45428] Address of template function even if fully named as a template-id is not properly determined
--- Comment #3 from roger dot ferrer at bsc dot es 2010-08-27 15:46 --- (In reply to comment #2) (In reply to comment #1) (In reply to comment #0) (void(*)(void)) my_fun_T // This is test.cpp:22 Can I assume you meant to case to (void(*)(void*)) here? Yes it was a typo, sorry. Even if fixed, though, g++ 4.4 does not compile it. Anyway if 4.5 and 4.6 accept such code I guess this is already fixed in forthcoming releases, right? Maybe the PR should be closed as fixed. Anyway, using the double-cast workaround g++ 4.4 does link. Thanks -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45428
[Bug ada/45421] [4.6 regression] Ada bootstrap failure on IRIX 6.5: SIGBUS in sem_aggr.sort_case_table
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2010-08-27 16:00 --- I can confirm something similar (an unaligned access) on IA64/Linux: (botca...@tinto) /nile.build/botcazou/gcc-head/ia64-unknown-linux-gnu $ gcc/gnat1 -quiet assert1.adb -I gcc/ada/rts gnat1(32495): unaligned access to 0x6fffa55c, ip=0x405e8cc1 gnat1(32495): unaligned access to 0x6fffa574, ip=0x405e8cc1 gnat1(32495): unaligned access to 0x6fffa58c, ip=0x405e8cc1 gnat1(32495): unaligned access to 0x6fffa55c, ip=0x405e8cc1 The address points to: Breakpoint 1, sem_aggr.sort_case_table (component_typ=72) at /nile.build/botcazou/gcc-head/src/gcc/ada/sem_aggr.adb:3974 3974 T := Case_Table (K + 1); It started to fail on 08/12 according to: http://gcc.gnu.org/ml/gcc-testresults/2010-08/msg01253.html http://gcc.gnu.org/ml/gcc-testresults/2010-08/msg01253.html Likely triggered/exposed by: 2010-08-12 Richard Guenther rguent...@suse.de * tree-flow.h (struct ptr_info_def): Add align and misalign fields. * tree-ssa-alias.c (get_ptr_info): Move ... * tree-ssanames.c (get_ptr_info): ... here. Initialize align and misalign fields conservatively. * tree-ssa-ccp.c (ccp_finalize): From partially constant pointers derive alignment information. (evaluate_stmt): Derive alignment information from memory allocation functions. * tree.h (get_pointer_alignment): Make unsigned. * builtins.c (get_object_alignment): Use alignment information we have computed for pointers. (get_pointer_alignment): Likewise. Make conservative, return and unsigned value. (expand_builtin_strlen): Adjust. (expand_builtin_memcmp): Likewise. (expand_builtin_strcmp): Likewise. (expand_builtin_strncmp): Likewise. (get_builtin_sync_mem): Use at least mode alignment. (fold_builtin_memset): Adjust. (fold_builtin_memory_op): Likewise. * gimple-pretty-print.c (dump_gimple_phi): Alongside alias information also dump pointer alignment knowledge. (dump_gimple_stmt): Likewise. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-08-27 16:00:30 date|| Summary|[4.6 regression] Ada|[4.6 regression] Ada |bootstrap failure on IRIX |bootstrap failure on IRIX |6.5: SEGV in|6.5: SIGBUS in |sem_aggr.sort_case_table|sem_aggr.sort_case_table http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45421
[Bug target/45363] [4.5 Regression] libgcc fails to configure: cc1: internal compiler error: Illegal instruction: 4
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2010-08-27 16:31 --- Gerald, we have problems with the third-party libraries (GMP,MPFR,MPC) on the SPARC, newer versions are miscompiled by earlier versions of GCC. So I'd suggest to stick to the minimal versions listed in: http://gcc.gnu.org/install/prerequisites.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45363
[Bug middle-end/45422] [4.6 Regression] compile time increases 8x.
--- Comment #8 from hjl dot tools at gmail dot com 2010-08-27 15:52 --- It is caused by revision 162653: http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg01007.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45422
[Bug testsuite/45429] [4.6 Regression] gcc.dg/vect/no-section-anchors-vect-64.c
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 Version|4.5.3 |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45429
[Bug tree-optimization/45427] Number of iteration analysis bogus
--- Comment #4 from rakdver at kam dot mff dot cuni dot cz 2010-08-27
16:33 ---
Subject: Re: New: Number of iteration
analysis bogus
when looking at the exit 6-7 number_of_iterations_ne is present with
iv-base (cxb3014__test_block__char_pointers__element * {ref-all}) ref_4(D)
and final 0B, the step is 1. We then do
else
{
s = fold_convert (niter_type, iv-step);
c = fold_build2 (MINUS_EXPR, niter_type,
fold_convert (niter_type, final),
fold_convert (niter_type, iv-base));
}
which creates -(UNSIGNED_64) ref_4(D) for c, with no_overflow set as we
do for pointers (but note we now have unsigned_type_for, a non-pointer!)
This looks correct to me, as far as I can tell. The original induction
variable
has pointer type, and thus it cannot overflow without causing undefined
behavior.
I do not understand the problem; what would you expect the result of the
analysis to be?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45427
[Bug middle-end/45429] New: [4.6 Regression] gcc.dg/vect/no-section-anchors-vect-64.c
On Linux/ia64, revision 163565 gave FAIL: gcc.dg/vect/no-section-anchors-vect-64.c scan-tree-dump-times vect Alignment of access forced using peeling 2 Revision 163561 is OK. -- Summary: [4.6 Regression] gcc.dg/vect/no-section-anchors-vect- 64.c Product: gcc Version: 4.5.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45429
[Bug tree-optimization/45427] Number of iteration analysis bogus
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-08-27 16:12 --- I think the bug is that we assume the exit is taken at some point, which is not true if we assume the induction variable does not wrap (so we only can assume one of both those assumptions at the same time). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45427
[Bug target/41484] Please add memory forms of pmovzx* (SSE4.1)
--- Comment #5 from hjl dot tools at gmail dot com 2010-08-27 16:16 --- (In reply to comment #4) Created an attachment (id=21576) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21576action=view) [edit] Patch to remove special (vec_duplicate ...) insn RTXes This patch removes special (vec_duplicate ...) forms of zero/sign extension instructions. This is similar to existing sse2_cvtps2pd pattern that access full 128bit memory even if only low 64bits are used. Also, current gcc generates: movdqa (%rdi), %xmm0 # 6 *movv16qi_internal/2[length = 4] pmovzxbd%xmm0, %xmm0# 7 sse4_1_zero_extendv4qiv4si2 which also access full 128bit 16byte aligned value. This is no better than: pmovzxbd(%rdi), %xmm0 # 7 sse4_1_zero_extendv4qiv4si2 Patch is untested, since I don't have required HW. I tested it on Linux/ia32 and Linux/Intel64 with SSE4.1. There are no regressions. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41484
[Bug target/41484] Please add memory forms of pmovzx* (SSE4.1)
--- Comment #6 from uros at gcc dot gnu dot org 2010-08-27 16:54 --- Subject: Bug 41484 Author: uros Date: Fri Aug 27 16:53:51 2010 New Revision: 163591 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163591 Log: PR target/41484 * config/i386/sse.md (sse4_1_extendv8qiv8hi2): Also accept memory operands for operand 1. (sse4_1_extendv4qiv4si2): Ditto. (sse4_1_extendv2qiv2di2): Ditto. (sse4_1_extendv4hiv4si2): Ditto. (sse4_1_extendv2hiv2di2): Ditto. (sse4_1_extendv2siv2di2): Ditto. (sse4_1_zero_extendv8qiv8hi2): Ditto. (sse4_1_zero_extendv4qiv4si2): Ditto. (sse4_1_zero_extendv2qiv2di2): Ditto. (sse4_1_zero_extendv4hiv4si2): Ditto. (sse4_1_zero_extendv2hiv2di2): Ditto. (sse4_1_zero_extendv2siv2di2): Ditto. (*sse4_1_extendv8qiv8hi2): Remove insn pattern. (*sse4_1_extendv4qiv4si2): Ditto. (*sse4_1_extendv2qiv2di2): Ditto. (*sse4_1_extendv4hiv4si2): Ditto. (*sse4_1_extendv2hiv2di2): Ditto. (*sse4_1_extendv2siv2di2): Ditto. (*sse4_1_zero_extendv8qiv8hi2): Ditto. (*sse4_1_zero_extendv4qiv4si2): Ditto. (*sse4_1_zero_extendv2qiv2di2): Ditto. (*sse4_1_zero_extendv4hiv4si2): Ditto. (*sse4_1_zero_extendv2hiv2di2): Ditto. (*sse4_1_zero_extendv2siv2di2): Ditto. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/sse.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41484
[Bug ada/45421] [4.6 regression] Ada bootstrap failure on IRIX 6.5: SIGBUS in sem_aggr.sort_case_table
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2010-08-27 16:01 --- Investigating on IA-64. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC|ebotcazou at gcc dot gnu dot| |org | AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-08-27 16:00:30 |2010-08-27 16:01:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45421
[Bug middle-end/45422] [4.6 Regression] compile time increases 8x.
--- Comment #9 from davidxl at gcc dot gnu dot org 2010-08-27 17:01 --- Will take a look -- davidxl at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |davidxl at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-08-27 10:23:21 |2010-08-27 17:01:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45422
[Bug tree-optimization/45427] Number of iteration analysis bogus
--- Comment #5 from rguenther at suse dot de 2010-08-27 17:23 ---
Subject: Re: Number of iteration analysis
bogus
On Fri, 27 Aug 2010, rakdver at kam dot mff dot cuni dot cz wrote:
--- Comment #4 from rakdver at kam dot mff dot cuni dot cz 2010-08-27
16:33 ---
Subject: Re: New: Number of iteration
analysis bogus
when looking at the exit 6-7 number_of_iterations_ne is present with
iv-base (cxb3014__test_block__char_pointers__element * {ref-all}) ref_4(D)
and final 0B, the step is 1. We then do
else
{
s = fold_convert (niter_type, iv-step);
c = fold_build2 (MINUS_EXPR, niter_type,
fold_convert (niter_type, final),
fold_convert (niter_type, iv-base));
}
which creates -(UNSIGNED_64) ref_4(D) for c, with no_overflow set as we
do for pointers (but note we now have unsigned_type_for, a non-pointer!)
This looks correct to me, as far as I can tell. The original induction
variable
has pointer type, and thus it cannot overflow without causing undefined
behavior.
I do not understand the problem; what would you expect the result of the
analysis to be?
At the moment we get (for the C testcase):
Analyzing # of iterations of loop 1
exit condition [p_4(D), + , 1](no_overflow) != 0B
bounds on difference of bases: -18446744073709551615 ... 0
result:
# of iterations -(long unsigned int) p_4(D), bounded by 0
Statement (exit)if (p_1 == 0B)
is executed at most -(long unsigned int) p_4(D) (bounded by 0) + 1 times
in loop 1.
thus, nb-iterations is bound by zero. But that's wrong, we're using
the estimate for an exit that isn't taken (or that estimate is wrong).
0 - (UNSIGNED_64) ref_4(D) is overflowing, so we shouldn't assess
that there's no overflow involved.
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45427
[Bug tree-optimization/45427] Number of iteration analysis bogus
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-08-27 17:26 --- You can see that analysis happening with the C testcase on unpatched trunk when looking at the cunrolli dump at -O2 for example. Analyzing # of iterations of loop 1 exit condition [p_4(D), + , 1](no_overflow) != 0B bounds on difference of bases: -18446744073709551615 ... 0 result: # of iterations -(long unsigned int) p_4(D), bounded by 0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45427
[Bug tree-optimization/45427] Number of iteration analysis bogus
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-08-27 17:27 --- Or in the cddce1 dump: Analyzing # of iterations of loop 1 exit condition [p_4(D), + , 1](no_overflow) != 0B bounds on difference of bases: -18446744073709551615 ... 0 result: # of iterations -(long unsigned int) p_4(D), bounded by 0 Found loop 1 to be finite: iterating -(long unsigned int) p_4(D) times where we might be able to construct a testcase with an infinite loop and no side-effects that CDCE will then remove. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45427
[Bug lto/44812] m32 lto produces non-relocatable subtraction expression errors
--- Comment #29 from iains at gcc dot gnu dot org 2010-08-27 17:38 --- (In reply to comment #12) Subject: Re: m32 lto produces non-relocatable subtraction expression errors Hmm, actually the symbol is not changed, since it is externally visible symbol. I guess the problem would be that the symbol is used by 2 units, so both of them gets the declaration, but both of them gets the declaration with initializer (not extern). To avoid duplicate definitions, varpool.c is testing in_other_partition and prevents calling assemble_variable on them. so one gets emitted and the other doesn't? This works just fine on ELF since extern vars don't need to be announced. we don't need to announce them either ... (assemble_external() is a no-op). Here we apparently need to get it assembled, but it is not getting via assemble_external. we need to get the right entry into the machopic tables - if the var is local to the TU ... Rebuilding the decl to DECL_EXTERN is probably possible, but somewhat hackish. I guess this is just allowing it to be assembled... === It is possible that the following is the root of the problem; when deciding how to output a var darwin/macho-pic takes the presence of an initializer as evidence that the var is defined in the current TU and that, therefore, it can reference it locally and doesn't need to output the other stuff. unless the var passes through assemble_var () this will not get done. assemble_external () seems a bit hackish too... I'm not clear why the two instances are not coalesced by the whopr process? Is that to cater for file-scope vars? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44812
[Bug middle-end/45410] constant not optimized / propagated
--- Comment #5 from reza at parvan dot net 2010-08-27 17:59 --- (In reply to comment #2) That's not the main problem here. The problem is that this is an aggregate and we SRA only automatic vars, not global vars. And it isn't constant either Jakub, Thanks for that insight. Of course, gcc does a pretty good job (and flow analysis) if we move 'struct s ss' into function scope. That seems like a reasonable workaround for many situations. Reza. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45410
[Bug c++/43453] Initialization of char array with string literal fails in mem-initializer
--- Comment #1 from giecrilj at stegny dot 2a dot pl 2010-08-27 18:06
---
(In reply to comment #0)
Fails to compile, but should work:
struct A {
char x[4];
A():x(bug) { }
};
Error i get is:
main.cpp:3: error: array used as initializer
Why do you think it should work?
For example, the following equivalent code is invalid as well:
char x [4] (bug);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43453
[Bug java/45322] libjava error: libtool: compile: libobj name `ltdl.lo' may not contain shell special
--- Comment #3 from rwild at gcc dot gnu dot org 2010-08-27 18:15 --- Maybe. Not all requirements from the installation manual can be checked easily. This one we can maybe fix, but for that please provide all information asked for. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45322
[Bug fortran/45430] New: segfault in OMP code with threadprivate and copyin
For this version: gfortran -v Using built-in specs. COLLECT_GCC=/opt/gcc/4.5.0/bin/../snos/bin/gfortran COLLECT_LTO_WRAPPER=/opt/gcc/4.5.0/snos/libexec/gcc/x86_64-suse-linux/4.5.0/lto-wrapper Target: x86_64-suse-linux Configured with: ../xt-gcc-4.5.0/configure --prefix=/opt/gcc/4.5.0/snos --disable-nls --libdir=/opt/gcc/4.5.0/snos/lib --enable-languages=c,c++,fortran --with-gxx-include-dir=/opt/gcc/4.5.0/snos/include/g++ --with-slibdir=/opt/gcc/4.5.0/snos/lib --with-system-zlib --enable-shared --enable-__cxa_atexit x86_64-suse-linux --with-mpc=/opt/gcc/mpc/0.8.1 --with-mpfr=/opt/gcc/mpfr/2.4.2 --with-gmp=/opt/gcc/gmp/4.3.2 --with-sysroot= Thread model: posix gcc version 4.5.0 20100414 (Cray Inc.) (GCC) And this compile script: cat compile.gnu ftn -fopenmp -c mod_init_openmp.f90 ftn -fopenmp -c mod_globals.f90 ftn -fopenmp -c mod_mysubs.f90 ftn -fopenmp -c mod_display_arrays.f90 ftn -fopenmp mod_init_openmp.o mod_globals.o mod_mysubs.o mod_display_arrays.o test_loop1.f90 ./a.out.gnu Running on2 threads Iteration =0 After sub1: Array = pb 2.0002.0002.0002.000 2.000 2.0002.0002.0002.000 2.000 2.0002.0002.0002.000 2.000 2.0002.0002.0002.000 2.000 .. After sub2: Array = out2 68.000 68.000 68.000 68.000 68.000 68.000 68.000 68.000 68.000 68.000 68.000 68.000 68.000 68.000 68.000 68.000 68.000 68.000 68.000 68.000 Iteration =6 Segmentation fault -- Summary: segfault in OMP code with threadprivate and copyin Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: longb at cray dot com GCC build triplet: x86_64-suse-linux GCC host triplet: x86_64-suse-linux GCC target triplet: x86_64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45430
[Bug fortran/45430] segfault in OMP code with threadprivate and copyin
--- Comment #1 from longb at cray dot com 2010-08-27 18:31 --- Comments from original submitter: A [deleted] user has given me the following code which fails with gcc/4.5.0. The code is OK with PGI and CCE. The problem seems to come about from the use of threadprivate in mod_globals.f90 and using the loop with the copyin clause in test_loop1.f90. If the threadprivate is commented out, and the copyin replaced with a private clause, all is well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45430
[Bug c++/45428] Address of template function even if fully named as a template-id is not properly determined
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-08-27 18:33 --- *** This bug has been marked as a duplicate of 11407 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45428
[Bug c++/11407] [DR 115] Function cannot be resolved
--- Comment #17 from pinskia at gcc dot gnu dot org 2010-08-27 18:33 --- *** Bug 45428 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||roger dot ferrer at bsc dot ||es http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11407
[Bug c++/45431] New: initializer-string for array of chars is too long: which one?
== Steps to reproduce ==
#!/bin/sh
# 1. Create the source file
cat 'bugpp.cpp' '/* EOF */'
struct personal_data
{ char name [01]; char surname [01]; }
const sc_me = {
Christopher,
Yeleighton };
/* EOF */
# 2. Compile as C++
make 'bugpp'
# 3. Compile as C
mv 'bugpp.cpp' 'bug.c'
make 'bug'
== Expected results (from gcc) ==
cc bug.c -o bug
bug.c:4: warning: initializer-string for array of chars is too long
bug.c:4: warning: (near initialization for #8216;sc_me.name#8217;)
bug.c:5: warning: initializer-string for array of chars is too long
bug.c:5: warning: (near initialization for #8216;sc_me.surname#8217;)
== Actual results (from g++) ==
g++ bugpp.cpp -o bugpp
bugpp.cpp:5: error: initializer-string for array of chars is too long
bugpp.cpp:5: error: initializer-string for array of chars is too long
== Essential differences ==
* The first line number should be 4
* g++ fails to indicate the failing data field
== Why this is important ==
Ordinary bugs in error messages should be marked as enhancement; however,
this one is particularly nasty. It is very difficult to identify the cause of
error when compiling long data initialisation statements using g++ because the
error message does not contain the line number or the position in the
structure.
== See also ==
* Bug 31158
== Version information ==
Using built-in specs.
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.4
--enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/
--with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap
--with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --program-suffix=-4.4
--enable-linux-futex --without-system-libunwind --with-arch-32=i586
--with-tune=generic --build=x86_64-suse-linux
Thread model: posix
gcc version 4.4.1 [gcc-4_4-branch revision 150839] (SUSE Linux)
--
Summary: initializer-string for array of chars is too long: which
one?
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: giecrilj at stegny dot 2a dot pl
GCC build triplet: x86_64-suse-linux
GCC host triplet: x86_64-suse-linux
GCC target triplet: x86_64-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45431
[Bug fortran/45430] segfault in OMP code with threadprivate and copyin
--- Comment #2 from longb at cray dot com 2010-08-27 18:36 --- Created an attachment (id=21579) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21579action=view) Test case, including source files and compile script Attached tar.gz file contains the source files and the compile.gnu script. Compilation completes, but execution of the a.out results in segfault. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45430
[Bug middle-end/45416] [4.5/4.6 Regression] Code size regression between 4.6(4.5) and 4.4 for ARM
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|rtl-optimization|middle-end Summary|Code size regression between|[4.5/4.6 Regression] Code |4.6(4.5) and 4.4 for ARM|size regression between ||4.6(4.5) and 4.4 for ARM Target Milestone|--- |4.5.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45416
[Bug tree-optimization/45427] Number of iteration analysis bogus
--- Comment #8 from rakdver at kam dot mff dot cuni dot cz 2010-08-27
18:47 ---
Subject: Re: Number of iteration analysis
bogus
when looking at the exit 6-7 number_of_iterations_ne is present with
iv-base (cxb3014__test_block__char_pointers__element * {ref-all})
ref_4(D)
and final 0B, the step is 1. We then do
else
{
s = fold_convert (niter_type, iv-step);
c = fold_build2 (MINUS_EXPR, niter_type,
fold_convert (niter_type, final),
fold_convert (niter_type, iv-base));
}
which creates -(UNSIGNED_64) ref_4(D) for c, with no_overflow set as we
do for pointers (but note we now have unsigned_type_for, a non-pointer!)
This looks correct to me, as far as I can tell. The original induction
variable
has pointer type, and thus it cannot overflow without causing undefined
behavior.
I do not understand the problem; what would you expect the result of the
analysis to be?
At the moment we get (for the C testcase):
Analyzing # of iterations of loop 1
exit condition [p_4(D), + , 1](no_overflow) != 0B
bounds on difference of bases: -18446744073709551615 ... 0
result:
# of iterations -(long unsigned int) p_4(D), bounded by 0
Statement (exit)if (p_1 == 0B)
is executed at most -(long unsigned int) p_4(D) (bounded by 0) + 1 times
in loop 1.
thus, nb-iterations is bound by zero. But that's wrong, we're using
the estimate for an exit that isn't taken (or that estimate is wrong).
This is something I forgot to document in the comments for tree_niter_desc
(although it is mentioned in the comments of number_of_iterations_ne_max) --
niter-max is valid only under the assumption that the exit is taken.
Unfortunately, I must have forgotten about this assumption as well, since
even the (only current) use in estimate_numbers_of_iterations_loop
gets this wrong.
The solution is to use the current method for computing niter-max only if
exit_must_be_taken is true, and something more conservative otherwise. I will
fix that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45427
[Bug tree-optimization/45427] Number of iteration analysis bogus
--- Comment #9 from rguenther at suse dot de 2010-08-27 18:52 ---
Subject: Re: Number of iteration analysis
bogus
On Fri, 27 Aug 2010, rakdver at kam dot mff dot cuni dot cz wrote:
--- Comment #8 from rakdver at kam dot mff dot cuni dot cz 2010-08-27
18:47 ---
Subject: Re: Number of iteration analysis
bogus
when looking at the exit 6-7 number_of_iterations_ne is present with
iv-base (cxb3014__test_block__char_pointers__element * {ref-all})
ref_4(D)
and final 0B, the step is 1. We then do
else
{
s = fold_convert (niter_type, iv-step);
c = fold_build2 (MINUS_EXPR, niter_type,
fold_convert (niter_type, final),
fold_convert (niter_type, iv-base));
}
which creates -(UNSIGNED_64) ref_4(D) for c, with no_overflow set as we
do for pointers (but note we now have unsigned_type_for, a non-pointer!)
This looks correct to me, as far as I can tell. The original induction
variable
has pointer type, and thus it cannot overflow without causing undefined
behavior.
I do not understand the problem; what would you expect the result of the
analysis to be?
At the moment we get (for the C testcase):
Analyzing # of iterations of loop 1
exit condition [p_4(D), + , 1](no_overflow) != 0B
bounds on difference of bases: -18446744073709551615 ... 0
result:
# of iterations -(long unsigned int) p_4(D), bounded by 0
Statement (exit)if (p_1 == 0B)
is executed at most -(long unsigned int) p_4(D) (bounded by 0) + 1 times
in loop 1.
thus, nb-iterations is bound by zero. But that's wrong, we're using
the estimate for an exit that isn't taken (or that estimate is wrong).
This is something I forgot to document in the comments for tree_niter_desc
(although it is mentioned in the comments of number_of_iterations_ne_max) --
niter-max is valid only under the assumption that the exit is taken.
Unfortunately, I must have forgotten about this assumption as well, since
even the (only current) use in estimate_numbers_of_iterations_loop
gets this wrong.
The solution is to use the current method for computing niter-max only if
exit_must_be_taken is true, and something more conservative otherwise. I will
fix that.
Thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45427
[Bug fortran/45420] [OOP] polymorphic TBP call in a CLASS DEFAULT clause
--- Comment #7 from janus at gcc dot gnu dot org 2010-08-27 19:02 --- Subject: Bug 45420 Author: janus Date: Fri Aug 27 19:02:15 2010 New Revision: 163594 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163594 Log: 2010-08-27 Janus Weil ja...@gcc.gnu.org PR fortran/45420 * match.c (select_type_set_tmp): Add the possibility to reset the temporary to NULL. (gfc_match_class_is): Reset the temporary in CLASS DEFAULT clauses. 2010-08-27 Janus Weil ja...@gcc.gnu.org PR fortran/45420 * gfortran.dg/select_type_15.f03: New. Added: trunk/gcc/testsuite/gfortran.dg/select_type_15.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/match.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45420
[Bug c++/45431] initializer-string for array of chars is too long: which one?
--- Comment #1 from redi at gcc dot gnu dot org 2010-08-27 19:10 --- 4.5 and 4.6 give the column number, but of the closing brace, which is no better -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45431
[Bug fortran/45420] [OOP] polymorphic TBP call in a CLASS DEFAULT clause
--- Comment #8 from janus at gcc dot gnu dot org 2010-08-27 19:14 --- Fixed with r163594. Closing. (Salvatore, please open a new PR for your problem in comment #3 if you have reduced it.) -- janus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|janus at gcc dot gnu dot org|unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45420
[Bug fortran/45420] [OOP] polymorphic TBP call in a CLASS DEFAULT clause
--- Comment #9 from janus at gcc dot gnu dot org 2010-08-27 19:15 --- Closing. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45420
[Bug fortran/33197] Fortran 2008: math functions
--- Comment #40 from burnus at gcc dot gnu dot org 2010-08-27 19:18 ---
Subject: Bug 33197
Author: burnus
Date: Fri Aug 27 19:17:45 2010
New Revision: 163595
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163595
Log:
gcc/fortran/
2010-08-27 Tobias Burnus bur...@net-b.de
PR fortran/33197
* gcc/fortran/intrinsic.c (add_functions): Add norm2 and parity.
* gcc/fortran/intrinsic.h (gfc_check_norm2, gfc_check_parity):
gfc_simplify_norm2, gfc_simplify_parity, gfc_resolve_norm2,
gfc_resolve_parity): New prototypes.
* gcc/fortran/gfortran.h (gfc_isym_id): New enum items
GFC_ISYM_NORM2 and GFC_ISYM_PARITY.
* gcc/fortran/iresolve.c (gfc_resolve_norm2,
gfc_resolve_parity): New functions.
* gcc/fortran/check.c (gfc_check_norm2, gfc_check_parity):
New functions.
* gcc/fortran/trans-intrinsic.c (gfc_conv_intrinsic_arith,
gfc_conv_intrinsic_function): Handle NORM2 and PARITY.
* gcc/fortran/intrinsic.texi (NORM2, PARITY): Add.
* gcc/fortran/simplify.c (simplify_transformation_to_array):
Add post-processing opterator.
(gfc_simplify_all, gfc_simplify_any, gfc_simplify_count,
gfc_simplify_product, gfc_simplify_sum): Update call.
(add_squared, do_sqrt, gfc_simplify_norm2, do_xor,
gfc_simplify_parity): New functions.
gcc/testsuite/
2010-08-27 Tobias Burnus bur...@net-b.de
PR fortran/33197
* gcc/testsuite/gfortran.dg/norm2_1.f90: New.
* gcc/testsuite/gfortran.dg/norm2_2.f90: New.
* gcc/testsuite/gfortran.dg/norm2_3.f90: New.
* gcc/testsuite/gfortran.dg/norm2_4.f90: New.
* gcc/testsuite/gfortran.dg/parity_1.f90: New.
* gcc/testsuite/gfortran.dg/parity_2.f90: New.
* gcc/testsuite/gfortran.dg/parity_3.f90: New.
libgfortran/
2010-08-27 Tobias Burnus bur...@net-b.de
PR fortran/33197
* libgfortran/m4/ifunction.m4 (FINISH_ARRAY_FUNCTION,
ARRAY_FUNCTION): Allow expression after loop.
* libgfortran/m4/norm2.m4: New for _gfortran_norm2_r{4,8,10,16}.
* libgfortran/m4/parity.m4: New for
* _gfortran_parity_l{1,2,4,8,16}.
* libgfortran/gfortran.map: Add new functions.
* libgfortran/Makefile.am: Ditto.
* libgfortran/m4/minloc1.m4: Add empty argument for
* ARRAY_FUNCTION.
* libgfortran/m4/maxloc1.m4: Ditto.
* libgfortran/m4/all.m4: Ditto.
* libgfortran/m4/minval.m4: Ditto.
* libgfortran/m4/maxval.m4: Ditto.
* libgfortran/m4/count.m4: Ditto.
* libgfortran/m4/product.m4: Ditto.
* libgfortran/m4/any.m4: Ditto.
* Makefile.in: Regenerated.
* generated/minval_r8.c: Regenerated.
* generated/maxloc1_4_r8.c: Regenerated.
* generated/minloc1_16_r16.c: Regenerated.
* generated/norm2_r4.c: Regenerated.
* generated/sum_i8.c: Regenerated.
* generated/parity_l2.c: Regenerated.
* generated/any_l16.c: Regenerated.
* generated/maxval_i2.c: Regenerated.
* generated/any_l2.c: Regenerated.
* generated/product_r4.c: Regenerated.
* generated/maxloc1_8_i4.c: Regenerated.
* generated/parity_l16.c: Regenerated.
* generated/all_l1.c: Regenerated.
* generated/product_i2.c: Regenerated.
* generated/minloc1_8_r16.c: Regenerated.
* generated/maxloc1_8_r16.c: Regenerated.
* generated/sum_r16.c: Regenerated.
* generated/sum_i1.c: Regenerated.
* generated/minloc1_4_r8.c: Regenerated.
* generated/maxloc1_16_r16.c: Regenerated.
* generated/minloc1_16_i4.c: Regenerated.
* generated/maxloc1_16_i4.c: Regenerated.
* generated/maxval_r16.c: Regenerated.
* generated/product_c10.c: Regenerated.
* generated/minloc1_8_i4.c: Regenerated.
* generated/all_l2.c: Regenerated.
* generated/product_c4.c: Regenerated.
* generated/sum_r4.c: Regenerated.
* generated/all_l16.c: Regenerated.
* generated/minloc1_16_r10.c: Regenerated.
* generated/sum_i2.c: Regenerated.
* generated/maxloc1_8_r8.c: Regenerated.
* generated/minval_i16.c: Regenerated.
* generated/parity_l4.c: Regenerated.
* generated/maxval_i4.c: Regenerated.
* generated/any_l4.c: Regenerated.
* generated/minval_i8.c: Regenerated.
* generated/maxloc1_4_i8.c: Regenerated.
* generated/minloc1_4_i16.c: Regenerated.
* generated/maxloc1_4_i16.c: Regenerated.
* generated/minloc1_8_r10.c: Regenerated.
* generated/product_i4.c: Regenerated.
* generated/maxloc1_8_r10.c: Regenerated.
* generated/sum_c16.c: Regenerated.
* generated/minloc1_16_r8.c: Regenerated.
* generated/maxloc1_16_r8.c: Regenerated.
* generated/count_4_l.c: Regenerated.
* generated/sum_r10.c: Regenerated.
[Bug fortran/33197] Fortran 2008: math functions
--- Comment #41 from burnus at gcc dot gnu dot org 2010-08-27 19:20 --- FIXED on the 4.6 trunk. Thanks to all involved in implementing the math intrinsics. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33197
[Bug c/45289] gcc lacks a posix option for -std since POSIX 2008 defines special behavior
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-08-27 19:25 --- Not working on the C frontend change. But the warning should be gone on trunk. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|rguenth at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45289
[Bug fortran/45432] New: gfortran.dg/allocate_alloc_opt_9.f90: Segfault due to invalid FREE
When running gfortran gfortran.dg/allocate_alloc_opt_9.f90 I get an ICE with free_expr0(): Bad expr type That happens for the second call to gfc_match_allocate and the ICE happens via gfc_match_allocate (match.c:309) - gfc_free_expr valgrind writes: ==2974== Invalid read of size 4 ==2974== at 0x508BC9: gfc_match_allocate (match.c:3098) ==2974== by 0x518FA9: match_word (parse.c:65) ==2974== by 0x519EFC: decode_statement (parse.c:332) If one prints the value of tmp and tmp-expr_type, one gets tmp != NULL and expr_type == 1549556828 ... Daniel checked 4.5.0 and found the same valgrind error. -- Summary: gfortran.dg/allocate_alloc_opt_9.f90: Segfault due to invalid FREE Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code, error-recovery 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=45432
[Bug fortran/45432] gfortran.dg/allocate_alloc_opt_9.f90: Segfault due to invalid FREE
--- Comment #1 from janus at gcc dot gnu dot org 2010-08-27 19:40 ---
This should fix it (it was some kind of double-free problem):
Index: gcc/fortran/match.c
===
--- gcc/fortran/match.c (revision 163594)
+++ gcc/fortran/match.c (working copy)
@@ -2955,6 +2955,7 @@ alloc_opt_list:
}
stat = tmp;
+ tmp = NULL;
saw_stat = true;
if (gfc_check_do_variable (stat-symtree))
@@ -2981,6 +2982,7 @@ alloc_opt_list:
}
errmsg = tmp;
+ tmp = NULL;
saw_errmsg = true;
if (gfc_match_char (',') == MATCH_YES)
@@ -3019,6 +3021,7 @@ alloc_opt_list:
}
source = tmp;
+ tmp = NULL;
saw_source = true;
if (gfc_match_char (',') == MATCH_YES)
@@ -3050,6 +3053,7 @@ alloc_opt_list:
}
mold = tmp;
+ tmp = NULL;
saw_mold = true;
mold-mold = 1;
--
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|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2010-08-27 19:40:17
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45432
[Bug c++/45431] initializer-string for array of chars is too long: which one?
--- Comment #2 from giecrilj at stegny dot 2a dot pl 2010-08-27 20:58 --- #9 0x00442a5e in digest_init_r (type=0x7618ac00, init=0x7617c4c0, nested=1 '\001') at ../../gcc/cp/typeck2.c:785 785 permerror (input_location, initializer-string for array of chars is too long); (gdb) l 780 /* In C it is ok to subtract 1 from the length of the string 781 because it's ok to ignore the terminating null char that is 782 counted in the length of the constant, but in C++ this would 783 be invalid. */ 784 if (size TREE_STRING_LENGTH (init)) 785 permerror (input_location, initializer-string for array of chars is too long); 786 } 787 return init; 788 } 789 } Symbol input_location is static storage. The function digest_init_r does not modify it in any way. It is an oblique index (601), to be resolved by linemap_lookup in line_table. If my investigation is correct, in this particular case it would be 1 + 601 7 == line 5 This particular value is assigned by the function cp_lexer_set_source_position_from_token, specifically from token-location. The stack: #0 cp_lexer_consume_token (lexer=0x7617c340) at ../../gcc/cp/parser.c:662 #1 0x004647f7 in cp_parser_braced_list (parser=0x77e84730, non_constant_p=0x7fffdb9e ) at ../../gcc/cp/parser.c:14692 #2 0x0046b07c in cp_parser_init_declarator (parser=0x77e84730, decl_specifiers=0x7fffdbf0, checks=value optimized out, function_definition_allowed_p=value optimized out, member_p=0 '\000', declares_class_or_enum=value optimized out, function_definition_p=0x7fffdc5f ) at ../../gcc/cp/parser.c:12893 The function cp_parser_init_declarator later calls cp_finish_decl (./../gcc/cp/parser.c:12929), which is where the error is reported. The error reporting code incorrectly assumes that the offending line is stored in the global input_location, which at the moment corresponds to the location of the closing brace. However, it seems that after the init tree has been constructed, the tokens are gone, and so is line number information. In conclusion, I think the easiest way to fix this problem (and perhaps other similar ones) would be to add line number information from the original tokens to the init tree. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45431
[Bug java/45433] New: Can't find GCCMain in org.eclipse.jdt.internal.compiler.batch.GCCMain
I just compiled gcc for fedora, and I'm getting this error:
[...@chessman ~]$ cat HelloWorld.java
public class HelloWorld {
public static void main(String[] args){
System.out.println(Hello world!);
}
}
[...@chessman ~]$ gcj -v -save-temps -o HelloWorld HelloWorld.java
Using built-in specs.
Reading specs from
/usr/local/lib/gcc/x86_64-fedora-linux-gnu/4.6.0/../../../libgcj.spec
rename spec startfile to startfileorig
rename spec lib to liborig
COLLECT_GCC=gcj
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-fedora-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-fedora-linux-gnu
Configured with: ./configure --build=x86_64-fedora-linux-gnu --with-ecj-jar
Thread model: posix
gcc version 4.6.0 20100827 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-fsaw-java-file' '-v' '-save-temps' '-o' 'HelloWorld'
'-fbootclasspath=./:/usr/local/share/java/libgcj-4.6.0.jar' '-g1'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
/usr/local/libexec/gcc/x86_64-fedora-linux-gnu/4.6.0/ecj1 HelloWorld.java -g1
-fbootclasspath=./:/usr/local/share/java/libgcj-4.6.0.jar -g1 -fsource=1.5
-ftarget=1.5 -fzip-dependency HelloWorld.zip -fzip-target HelloWorld.jar
Exception in thread main java.lang.NoClassDefFoundError:
org.eclipse.jdt.internal.compiler.batch.GCCMain
at gnu.java.lang.MainThread.run(libgcj.so.10)
Caused by: java.lang.ClassNotFoundException:
org.eclipse.jdt.internal.compiler.batch.GCCMain not found in
gnu.gcj.runtime.SystemClassLoader{urls=[],
parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
at java.net.URLClassLoader.findClass(libgcj.so.10)
at java.lang.ClassLoader.loadClass(libgcj.so.10)
at java.lang.ClassLoader.loadClass(libgcj.so.10)
at gnu.java.lang.MainThread.run(libgcj.so.10)
[...@chessman ~]$
I built this GCC today with the GCC I built yesterday (also 4.6.0). That also
had this java error.
--
Summary: Can't find GCCMain in
org.eclipse.jdt.internal.compiler.batch.GCCMain
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: leo dot izen at gmail dot com
GCC build triplet: x86_64-fedora-linux-gnu
GCC host triplet: x86_64-fedora-linux-gnu
GCC target triplet: x86_64-fedora-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45433
[Bug java/45433] Can't find GCCMain in org.eclipse.jdt.internal.compiler.batch.GCCMain
--- Comment #1 from leo dot izen at gmail dot com 2010-08-27 21:08 --- Created an attachment (id=21580) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21580action=view) file I tried to compile -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45433
[Bug fortran/32049] Support on x86_64 also kind=16
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2010-08-27 21:24 --- Subject: Bug 32049 Author: fxcoudert Date: Fri Aug 27 21:24:13 2010 New Revision: 163597 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163597 Log: PR fortran/32049 * gfortran.h (gfc_real_info): Add c_float128 field. * mathbuiltins.def: Indicate which builtins are const. * trans-types.h (float128_type_node, complex_float128_type_node, gfc_real16_is_float128): New variables. * trans-types.c (float128_type_node, complex_float128_type_node, gfc_real16_is_float128): New variables. (gfc_init_kinds): Allow TFmode. (gfc_build_real_type): Mark __float128 types as such. (gfc_init_types): Initialize float128_type_node and complex_float128_type_node * f95-lang.c (gfc_init_builtin_functions): Adjust for new argument of OTHER_BUILTIN macro. * trans-intrinsic.c (gfc_intrinsic_map_t): Likewise. (builtin_decl_for_precision): Special case for __float128. (builtin_decl_for_float_kind): Likewise. (define_quad_builtin): New function. (gfc_build_intrinsic_lib_fndecls): Create all __float128 library decls if necessary. Store them in the real16_decl and complex16_decl builtin map fields. (gfc_get_intrinsic_lib_fndecl): Handle q-suffixed __float128 library function names. * gfortran.dg/random_seed_1.f90: Adjust test. * gfortran.dg/float128_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/float128_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/f95-lang.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/mathbuiltins.def trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/fortran/trans-types.c trunk/gcc/fortran/trans-types.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/random_seed_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32049
[Bug java/45433] Can't find GCCMain in org.eclipse.jdt.internal.compiler.batch.GCCMain
--- Comment #2 from jakub at gcc dot gnu dot org 2010-08-27 21:35 --- You need to read the documentation, which would tell you you need to use -fmain=HelloWorld option. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45433
[Bug fortran/45432] gfortran.dg/allocate_alloc_opt_9.f90: Segfault due to invalid FREE
--- Comment #2 from janus at gcc dot gnu dot org 2010-08-27 21:51 --- Subject: Bug 45432 Author: janus Date: Fri Aug 27 21:50:47 2010 New Revision: 163599 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163599 Log: 2010-08-27 Janus Weil ja...@gcc.gnu.org PR fortran/45432 * match.c (gfc_match_allocate): Avoid double free on error. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/match.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45432
[Bug fortran/45432] gfortran.dg/allocate_alloc_opt_9.f90: Segfault due to invalid FREE
--- Comment #3 from janus at gcc dot gnu dot org 2010-08-27 21:51 --- Fixed with r163599. Closing. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45432
[Bug c++/986] g++ misses warning for on temporary
--- Comment #26 from driscoll at cs dot wisc dot edu 2010-08-27 22:02
---
I was surprised to see this is not caught by a warning as well. (The discussion
of whether it should be an error is silly; it pretty clearly shouldn't be.
There's -Werror if you disagree.)
Motivation: This surfaced in the code I'm working on as it has several similar
functions that return std::sets of objects. I changed several of them to return
by const-reference for efficiency purposes, but not all of them could be
modified such. I then changed call sites so that the return was stored in a
const-reference instead of copied. I expected the compiler to be able to catch
any mismatches (storing the by-value return in a reference), but when I ran a
test to see if it would, there was no warning.
Examples:
This first one is inspired by the code I was working on:
int retByVal() {
return 5;
}
int foo() {
int const v = retByVal(); // no warning
return v;// no warning
}
but you don't even need to get that complicated. The following illustrates as
well:
int foo() {
int const x = 4; // no warning
return x; // no warning
}
Comparison of compilers:
- GCC fails to warn for either examples:
- 3.3.3, 3.4.6 (-Wall -W)
- 4.1.2, 4.5.1 (-Wall -Wextra)
- MSVC fails to warn for either of these examples
- 2005, 2008 (level 4)
- 2010 (all warnings, /Wall)
- The EDG front end warns if remarks are on:
- Intel CC (10.1 -Wall), *does* warn about these examples. E.g.:
remark #383: value copied to temporary, reference to temporary used
int const v = retByVal();
- Comeau (with -r) warns
I haven't lost debugging time to this or anything like that, but I am a bit
disappointed and surprised to see that neither MSVC nor GCC warns for this
almost-certain error and thought I'd contribute in the hopes that another
person running across it might inspire someone to fix it.
--
driscoll at cs dot wisc dot edu changed:
What|Removed |Added
CC||driscoll at cs dot wisc dot
||edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=986
[Bug c++/986] g++ misses warning for on temporary
--- Comment #27 from pinskia at gcc dot gnu dot org 2010-08-27 22:21 --- This first one is inspired by the code I was working on: Your two functions are well defined as the scope of the temp is only lost after going out of scope. So there is no references to a temp escaping unlike the original example. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=986
[Bug c++/986] g++ misses warning for on temporary
--- Comment #28 from driscoll at cs dot wisc dot edu 2010-08-27 22:53 --- Your two functions are well defined as the scope of the temp is only lost after going out of scope. I see A reference is bound to a temporary object: the temporary object is destroyed at the end of the reference's lifetime at http://publib.boulder.ibm.com/infocenter/comphelp/v8v101/index.jsp?topic=/com.ibm.xlcpp8a.doc/language/ref/cplr382.htm (as well as 12.2 para 5 in the standard) now... that's something I totally did not know. Thanks, and sorry for the spam. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=986
[Bug rtl-optimization/45434] New: x86 missed optimization: use high register (ah, bh, ch, dh) when available to make comparisons
It is unnecessary to shift a value in a high register position (ah, bh, ch, dh)
down to a low register position (al, bl, cl, dl) to perform a machine
comparison. X86-64 Linux ABI exhaustive example:
#include assert.h
#include stdbool.h
#include stdint.h
__attribute__ ((noinline)) bool check_via_c(uint64_t i) {
if ((i 0xFF) == ((i 0xFF00) 8)) return true;
return false;
}
__attribute__ ((noinline)) bool check_via_asm(uint64_t i) {
bool result;
__asm__ (mov %%rdi, %%rax\n
cmp %%al, %%ah\n
sete %0\n : =r (result));
return result;
}
int main() {
for (uint64_t i=0; i = 0x; ++i) {
assert(check_via_c(i) == (check_via_asm(i)));
}
}
gcc-4.5 -O3 -std=gnu99 ah_bh_ch_dh_missed_optimization.c objdump -d -m
i386:x86-64 a.out |less
GCC generates:
00400530 check_via_c:
400530: 48 89 f8mov%rdi,%rax
400533: 48 c1 e8 08 shr$0x8,%rax
400537: 40 38 f8cmp%dil,%al
40053a: 0f 94 c0sete %al
40053d: c3 retq
A superior solution:
00400540 check_via_asm:
400540: 48 89 f8mov%rdi,%rax
400543: 38 c4 cmp%al,%ah
400545: 0f 94 c0sete %al
400548: c3 retq
--
Summary: x86 missed optimization: use high register (ah, bh, ch,
dh) when available to make comparisons
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: adam at consulting dot net dot nz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45434
