[Bug fortran/41586] Allocatable _scalars_ are never auto-deallocated
--- Comment #3 from janus at gcc dot gnu dot org 2009-10-16 21:04 ---
AND ALSO FOR:
type t0
end type t0
type(t0), allocatable :: m(:)
allocate(t0 :: m(3))
end
No, this one actually works (since 'm' is not a scalar):
if (m.data != 0B)
{
__builtin_free ((void *) m.data);
}
m.data = 0B;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41586
[Bug fortran/41719] [OOP] invalid: Intrinsic assignment involving polymorphic variables
--- Comment #7 from janus at gcc dot gnu dot org 2009-10-16 21:10 --- Subject: Bug 41719 Author: janus Date: Fri Oct 16 21:10:43 2009 New Revision: 152919 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152919 Log: 2009-10-16 Janus Weil ja...@gcc.gnu.org PR fortran/41719 * resolve.c (resolve_ordinary_assign): Reject intrinsic assignments to polymorphic variables. 2009-10-16 Janus Weil ja...@gcc.gnu.org PR fortran/41719 * gfortran.dg/class_5.f03: New test case. * gfortran.dg/typebound_operator_2.f03: Fixing invalid test case. * gfortran.dg/typebound_operator_4.f03: Ditto. Added: trunk/gcc/testsuite/gfortran.dg/class_5.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/typebound_operator_2.f03 trunk/gcc/testsuite/gfortran.dg/typebound_operator_4.f03 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41719
[Bug fortran/41719] [OOP] invalid: Intrinsic assignment involving polymorphic variables
-- 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 |2009-10-16 21:11:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41719
[Bug fortran/41719] [OOP] invalid: Intrinsic assignment involving polymorphic variables
--- Comment #8 from janus at gcc dot gnu dot org 2009-10-16 21:12 --- Fixed with r152919. 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=41719
[Bug fortran/41714] [OOP] ALLOCATE SOURCE= does not properly copy the value from SOURCE
--- Comment #4 from janus at gcc dot gnu dot org 2009-10-16 21:25 --- (In reply to comment #3) In addition to this there are two more test cases failing: Sorry, these were fake (my local source tree was messed up). The only real failure is class_allocate_1.f03, from which one can extract a reduced test case: implicit none type t1 integer :: a end type type, extends(t1) :: t2 integer :: b end type class(t1),pointer :: cp type(t2) :: x allocate(cp, source = x) end which gives the same error at -O1 and above: internal compiler error: in tree_annotate_all_with_location, at gimplify.c:892 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41714
[Bug c/40033] [4.5 regression] ICE with invalid statement expression
--- Comment #1 from d dot g dot gorbachev at gmail dot com 2009-10-16 21:57 --- Created an attachment (id=18814) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18814action=view) testcase A similar problem: bug.cc: In function 'void f()': bug.cc:5:20: error: '__cxa_begin_catch' cannot be used as a function bug.cc:5:20: internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at tree-ssa.c:1221 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40033
[Bug middle-end/41734] New: ICE in cgraph_mark_functions_to_output, at cgraphunit.c:1137 with -fwhopr
This is number #1 ICE when building SPEC with -fwhopr. I'll attach a sample testcase once I reduced it. -- Summary: ICE in cgraph_mark_functions_to_output, at cgraphunit.c:1137 with -fwhopr Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: lto Severity: normal Priority: P3 Component: middle-end 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=41734
[Bug middle-end/41734] ICE in cgraph_mark_functions_to_output, at cgraphunit.c:1137 with -fwhopr
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-10-16 22:04 --- I'm reducing it from 164.gzip with -O3 -ffast-math -fwhopr -fwhole-program. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41734
[Bug middle-end/41734] ICE in cgraph_mark_functions_to_output, at cgraphunit.c:1137 with -fwhopr
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-10-16 23:02 ---
util.3.i
typedef unsigned int size_t;
extern struct _IO_FILE *stderr;
typedef unsigned char uch;
extern uch inbuf[];
unsigned insize;
char *progname;
extern void read_error (void);
int fill_inbuf(int eof_ok)
{
if (insize == 0)
{
if (eof_ok)
return -1;
read_error();
}
return inbuf[0];
}
void read_error(void)
{
__builtin_fprintf(stderr, \n%s: , progname);
}
gzip.3.i
typedef unsigned char uch;
uch inbuf[8];
extern unsigned insize;
unsigned inptr;
int to_stdout = 0;
int force = 0;
extern int fill_inbuf (int);
int get_method(int in)
{
char magic[2];
if (force to_stdout)
magic[0] = (char)(inptr insize ? inbuf[inptr++] : fill_inbuf(1));
else
magic[1] = (char)(inptr insize ? inbuf[inptr++] : fill_inbuf(0));
}
int main()
{
return 0;
}
$ ./xgcc -B. util.3.i gzip.3.i -O3 -fwhopr read_error/5(-1) @0xb7d33200 (clone
of read_error/4) availability:not_available (15 after inlining) (6 after
inlining) needed reachable body externally_visible finalized
called by: fill_inbuf/2 (0.00 per call)
calls:
lto1: internal compiler error: failed to reclaim unneeded function
Please submit a full bug report,
with preprocessed source if appropriate.
or w/o checking
/space/rguenther/install/lto/bin/gcc -o gzip ~/util.3.i ~/gzip.3.i -O3
-fwhopr
lto1: internal compiler error: in cgraph_mark_functions_to_output, at
cgraphunit.c:1137
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
--
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 |2009-10-16 23:02:04
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41734
[Bug tree-optimization/41735] New: [4.5 Regression] inlined comdat function sometimes is emitted
Take:
struct g
{
inline g(void);
int t;
};
inline g::g(void)
{
t = 0;
}
int h(void)
{
g a;
return a.t;
}
--- CUT ---
g::g() is being emitted even at -O2 -fno-early-inlining even though it has been
inlined.
Note we either update the cgraph after early inlining or it updates it
correctly.
--
Summary: [4.5 Regression] inlined comdat function sometimes is
emitted
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41735
[Bug tree-optimization/41735] [4.5 Regression] inlined comdat function sometimes is emitted
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.5.0 Known to work||4.4.1 Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41735
[Bug tree-optimization/41735] [4.5 Regression] inlined comdat function sometimes is emitted
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-10-17 00:21 --- Oh if I did not have t = 0; there, the function would have been eliminated too as const/pure is able to figure out that function is constant and able to remove it and something comes along and updates the cgraph. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41735
[Bug testsuite/41700] g++.dg/debug/dwarf2/icf.C
--- Comment #3 from ccoutant at gcc dot gnu dot org 2009-10-17 00:30 --- The insn UID is changed when the call_insn is split, so the vtable slot index can't be found when it's time to build the vcall table. -- ccoutant at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ccoutant at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2009-10-14 21:03:06 |2009-10-17 00:30:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41700
[Bug fortran/41656] [OOP] Unresolved GENERIC
--- Comment #6 from pault at gcc dot gnu dot org 2009-10-16 06:07 --- Subject: Bug 41656 Author: pault Date: Fri Oct 16 06:07:09 2009 New Revision: 152890 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152890 Log: 2009-10-16 Paul Thomas pa...@gcc.gnu.org PR fortran/41648 PR fortran/41656 * trans-expr.c (select_class_proc): Convert the expression for the vindex, carried on the first member of the esym list. * gfortran.h : Add the vindex field to the esym_list structure. and eliminate the class_object field. * resolve.c (check_class_members): Remove the setting of the class_object field. (vindex_expr): New function. (get_class_from_expr): New function. (resolve_class_compcall): Call the above to find the ultimate class or derived component. If derived, do not generate the esym list. Add and expression for the vindex to the esym list by calling the above. (resolve_class_typebound_call): The same. 2009-10-16 Paul Thomas pa...@gcc.gnu.org PR fortran/41648 * gfortran.dg/dynamic_dispatch_4.f03 : New test. PR fortran/41656 * gfortran.dg/dynamic_dispatch_5.f03 : New test. Added: trunk/gcc/testsuite/gfortran.dg/dynamic_dispatch_4.f03 trunk/gcc/testsuite/gfortran.dg/dynamic_dispatch_5.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41656
[Bug fortran/41648] [OOP] Type-bound procedures refused
--- Comment #3 from pault at gcc dot gnu dot org 2009-10-16 06:07 --- Subject: Bug 41648 Author: pault Date: Fri Oct 16 06:07:09 2009 New Revision: 152890 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152890 Log: 2009-10-16 Paul Thomas pa...@gcc.gnu.org PR fortran/41648 PR fortran/41656 * trans-expr.c (select_class_proc): Convert the expression for the vindex, carried on the first member of the esym list. * gfortran.h : Add the vindex field to the esym_list structure. and eliminate the class_object field. * resolve.c (check_class_members): Remove the setting of the class_object field. (vindex_expr): New function. (get_class_from_expr): New function. (resolve_class_compcall): Call the above to find the ultimate class or derived component. If derived, do not generate the esym list. Add and expression for the vindex to the esym list by calling the above. (resolve_class_typebound_call): The same. 2009-10-16 Paul Thomas pa...@gcc.gnu.org PR fortran/41648 * gfortran.dg/dynamic_dispatch_4.f03 : New test. PR fortran/41656 * gfortran.dg/dynamic_dispatch_5.f03 : New test. Added: trunk/gcc/testsuite/gfortran.dg/dynamic_dispatch_4.f03 trunk/gcc/testsuite/gfortran.dg/dynamic_dispatch_5.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41648
[Bug fortran/41648] [OOP] Type-bound procedures refused
--- Comment #4 from pault at gcc dot gnu dot org 2009-10-16 06:09 --- Fixed on trunk. Thanks for the patch. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41648
[Bug fortran/41656] [OOP] Unresolved GENERIC
--- Comment #7 from pault at gcc dot gnu dot org 2009-10-16 06:09 --- Fixed on trunk. Thanks for the patch. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41656
[Bug libstdc++/40826] [C++0x] atomic_flag_{test_and_set,clear}_explicit() are apparently broken
--- Comment #2 from bkoz at gcc dot gnu dot org 2009-10-16 07:47 --- Subject: Bug 40826 Author: bkoz Date: Fri Oct 16 07:47:33 2009 New Revision: 152895 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152895 Log: 2009-10-15 Benjamin Kosnik b...@redhat.com PR libstdc++/40654 PR libstdc++/40826 * src/atomic.cc (atomic_flag_test_and_set_explicit): Add static_cast from base to derived. (atomic_flag_clear_explicit): Same. * include/bits/atomic_2.h (__atomic2::atomic_flag): Public derivation. Remove value type constructor. * include/bits/atomic_0.h (__atomic0::atomic_flag): Same. * include/std/future (_Future_state): Use ATOMIC_FLAG_INIT to initialized the atomic_flag member. Added: trunk/libstdc++-v3/testsuite/29_atomics/atomic_flag/clear/ trunk/libstdc++-v3/testsuite/29_atomics/atomic_flag/clear/1.c trunk/libstdc++-v3/testsuite/29_atomics/atomic_flag/clear/1.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/atomic_0.h trunk/libstdc++-v3/include/bits/atomic_2.h trunk/libstdc++-v3/include/std/future trunk/libstdc++-v3/src/atomic.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40826
[Bug libstdc++/40654] [C++0x] atomic.cc: 'd' is used uninitialized warning
--- Comment #4 from bkoz at gcc dot gnu dot org 2009-10-16 07:47 --- Subject: Bug 40654 Author: bkoz Date: Fri Oct 16 07:47:33 2009 New Revision: 152895 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152895 Log: 2009-10-15 Benjamin Kosnik b...@redhat.com PR libstdc++/40654 PR libstdc++/40826 * src/atomic.cc (atomic_flag_test_and_set_explicit): Add static_cast from base to derived. (atomic_flag_clear_explicit): Same. * include/bits/atomic_2.h (__atomic2::atomic_flag): Public derivation. Remove value type constructor. * include/bits/atomic_0.h (__atomic0::atomic_flag): Same. * include/std/future (_Future_state): Use ATOMIC_FLAG_INIT to initialized the atomic_flag member. Added: trunk/libstdc++-v3/testsuite/29_atomics/atomic_flag/clear/ trunk/libstdc++-v3/testsuite/29_atomics/atomic_flag/clear/1.c trunk/libstdc++-v3/testsuite/29_atomics/atomic_flag/clear/1.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/atomic_0.h trunk/libstdc++-v3/include/bits/atomic_2.h trunk/libstdc++-v3/include/std/future trunk/libstdc++-v3/src/atomic.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40654
[Bug libfortran/41711] Z format does not support writing KIND=10 reals
--- Comment #9 from dominiq at lps dot ens dot fr 2009-10-16 08:13 --- (In reply to comment #8) This seems to work. (Although I thought I saw once for the z4 value.) With the following changes program z implicit none integer,parameter :: k8 = selected_real_kind (precision (0.0d0)) integer,parameter :: k = max(k8,selected_real_kind (precision (0.0d0) + 1)) LOGICAL, PARAMETER :: bigend = IACHAR(TRANSFER(1,a)) == 0 character(16) :: str real(k) e integer i integer(8), dimension(2) :: it print *, k call random_seed() do i=1,100 call random_number(e) it = transfer(e, it) if (k==k8) then write(*,'(E24.17,3X,Z16.16)') e, it(1) else if (bigend) then write(str,'(z16.16)') it(1) write(*,'(E24.17,3X,A,1X,Z16.16)') e, str(33-2*k:16), it(2) else write(str,'(z16.16)') it(2) write(*,'(E24.17,3X,A,Z16.16)') e, str(33-2*k:16), it(1) end if end do end program z The code works for platforms having REAl(10/16) and with little/big endian-ness (the Z16.16 format force the printing of the leading zeroes). Note that ifort detects the spurious ')' in write(*,'(E24.17,3X,Z4,Z16))') (although I think it is not a violation of the standard). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41711
[Bug fortran/41724] New: PUREness/ELEMENTAL check missing for ACTUAL/DUMMY conformance
One again a bug report based on the famous compiler stress tests of James Van Buskirk http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/da1feef5e8c9ed9a Pre-remark: After writing this PR, I realized the following parenthesis: with a dummy procedure (which is prohibited from being elemental) I failed to quickly find the restriction elsewhere - but the text is normative. Thus also PROGRAM C should be invalid. One should re-check and consider to add a check whether a DUMMY argument is also ELEMENTAL and reject it then. Program A (Validly rejected by gfortran; but should accept as extension?) gfortran rejects the program with Error: ELEMENTAL non-INTRINSIC procedure 'my_dcos' is not allowed as an actual argument at (1) That's in line with Fortran 95, 12.4 Procedure reference: Constraint: A non-intrinsic elemental procedure shall not be used as an actual argument. and Fortran 2003 has: C1228 (R1221) A nonintrinsic elemental procedure shall not be used as an actual argument. and Fortran 2008: C1233 (R1223) A nonintrinsic elemental procedure shall not be used as an actual argument. Interestingly, the program is accepted by (!) NAG f95 (with extension warning) and ifort (with warning using -stand f03). (sunf95, openf95, g95 and gfortran unconditionally reject it.) PROGRAM B - gfortran accepts invalid The program is accepted by gfortran, sunf95, and (!) NAG f95, but rejected by ifort and g95 with the error: Error: Dummy procedure 'my_dcos' at (1) must be PURE error #7892: Procedure argument must be PURE [MY_DCOS] error #7050: The PURE attribute of the associated actual procedure differs from the PURE attribute of the dummy procedure. [MY_DCOS] error #7849: The ELEMENTAL attribute of the associated actual procedure differs from the ELEMENTAL attribute of the dummy procedure. [MY_DCOS] We recall (see below): The dummy argument is ELEMENTAL, but the actual argument is a simple function - neither PURE nor ELEMENTAL. gfortran actually misses a check as Fortran 2003 states (12.4.1.3 Actual arguments associated with dummy procedure entities): If the interface of the dummy argument is explicit, the characteristics listed in 12.2 shall be the same for the associated actual argument and the corresponding dummy argument, except that a pure actual argument may be associated with a dummy argument that is not pure and an elemental intrinsic actual procedure may be associated with a dummy procedure (which is prohibited from being elemental). (Side remark: In Fortran 2008 IMPURE ELEMENTAL procedures are allowed; without IMPURE - and thus always in F95/F2003 - ELEMENTAL implies PURE. - But that does not help here) PROGRAM C - looks to be valid [or not?] and is accepted Calling DCOS as actual argument is standard conform (listed as specific function and does not have a * before the entry). (gfortran accepts it, ifort rejects it.) [But see note above regarding ELEMENTAL dummies] = PROGRAM A == module funcs implicit none integer, parameter :: dp = kind(1.0d0) contains ELEMENTAL function my_dcos(x) integer, parameter :: dp = kind(1.0d0) real(dp), intent(in) :: x real(dp) :: my_dcos my_dcos = cos(x) end function subroutine test(fun) interface ELEMENTAL function fun(x) import implicit none real(dp), intent(in) :: x real(dp) fun end function fun end interface real(dp) x(3) x = [1,2,3] write(*,*) fun(x) end subroutine test end module funcs program start use funcs implicit none call test(my_dcos) end program start = PROGRAM B == module funcs implicit none integer, parameter :: dp = kind(1.0d0) contains function my_dcos(x) ! Not elemental integer, parameter :: dp = kind(1.0d0) real(dp), intent(in) :: x real(dp) :: my_dcos my_dcos = cos(x) end function subroutine test(fun) interface ELEMENTAL function fun(x) import implicit none real(dp), intent(in) :: x real(dp) fun end function fun end interface real(dp) x(3) x = [1,2,3] write(*,*) fun(x) end subroutine test end module funcs program start use funcs implicit none call test(my_dcos) end program start = PROGRAM C == module funcs implicit none integer, parameter :: dp = kind(1.0d0) contains subroutine test(fun) interface ELEMENTAL function fun(x) import implicit none real(dp), intent(in) :: x real(dp) fun end function fun end interface real(dp) x(3) x = [1,2,3] write(*,*) fun(x) end subroutine test end module funcs program start use funcs implicit none intrinsic dcos call test(dcos) end
[Bug c++/41725] New: g++ accepts compounded unnamed type in template (violates 14.3.1-2)
g++ accepts a type as a template argument, that is defined inside of an unnamed type. In the attached example t_inner is defined in an unnamed structure. That would make t_inner a type compounded from an unnamed type as I read section 14.3.1-2 of the ISO/IEC 14882/1998 standard (p. 241). So this should cause an error (and does with other Compilers / tools), but g++ accepts it. The problem was found with: gcc -v Using built-in specs. Target: sparc-sun-solaris2.10 Configured with: ../gcc-4.2.4/configure --prefix=/usr/local/gcc424 Thread model: posix gcc version 4.2.4 It has also been verified with: gcc -v Reading specs from /usr/local/gcc344/lib/gcc/sparc-sun-solaris2.10/3.4.4/specs Configured with: ./configure --prefix=/usr/local/gcc344 Thread model: posix gcc version 3.4.4 It has also been seen with version 4.3.3 on Linux (Ubuntu 9.04 on 64bit Intel). The Comeau online compiler gives an a template argument may not reference an unnamed type error message for that code. -- Summary: g++ accepts compounded unnamed type in template (violates 14.3.1-2) Product: gcc Version: 4.2.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: td-gnubugs at th-dorner dot de GCC build triplet: sparc-sun-solaris2.10 GCC host triplet: sparc-sun-solaris2.10 GCC target triplet: sparc-sun-solaris2.10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41725
[Bug tree-optimization/41718] internal compiler error: in add_stack_var_conflict, at cfgexpand.c:359
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-10-16 08:53 --- I suggest to change size_t to HOST_WIDEST_INT. But I guess on a 32bit host you don't have any luck compiling this big testcase anyway... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41718
[Bug lto/41669] Infinite recursion trying to build gcc
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-10-16 08:54 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41669
[Bug lto/41726] New: Recursion prevention in gimple_get_alias_set should be revisited
$summary Mine. Probably not for 4.5 though. -- Summary: Recursion prevention in gimple_get_alias_set should be revisited Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: FIXME Severity: normal Priority: P3 Component: lto AssignedTo: rguenth at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41726
[Bug lto/41668] ICE in get_alias_set, at alias.c:698
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-10-16 08:55 --- Fixed again. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41668
[Bug c++/41725] g++ accepts compounded unnamed type in template (violates 14.3.1-2)
--- Comment #1 from td-gnubugs at th-dorner dot de 2009-10-16 08:59 --- Created an attachment (id=18806) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18806action=view) (almost) minimal example A g++ -pedantic -ansi -Wall -Wextra -o ArrayWithInnerStructure3 ArrayWithInnerStructure3.cpp ; ./ArrayWithInnerStructure3 ; echo $? just prints 8 and no compilation error or warning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41725
[Bug middle-end/41713] -O -flto -g: ICE in lto_output_tree_ref, at lto-streamer-out.c:732
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-10-16 09:04 --- Confirmed. Alex didn't update LTO with the introduction of DEBUG_EXPR_DECLs. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||aoliva at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-10-16 09:04:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41713
[Bug c++/41727] New: inner template specialization on non-type arg template causes ICE
when:
template
class Tag
struct
outer
{
template
typename Arg0
, typename Arg1
struct
inner
;
};
is specialized on Tag and Arg1 where Arg1 is value_wrapArg1Int,
ICE is generated at cp/pt.c:9668 from recent (yesterday?)
svn update.
--
Summary: inner template specialization on non-type arg template
causes ICE
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: cppljevans at suddenlink dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41727
[Bug c++/41727] inner template specialization on non-type arg template causes ICE
--- Comment #1 from cppljevans at suddenlink dot net 2009-10-16 10:01 --- Created an attachment (id=18807) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18807action=view) testcase with compiler output shown in comments Compiler output showing ICE is shown in comments after: //CompilerOutput: at bottom of source code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41727
[Bug c++/41728] New: error: SSA name in freelist but still referenced
I just tried to compile some C++ code with the gcc 4.5 mainline snapshot 20091015 and the compiler said In function 'int s244(defs*)': cq.cc:562:1: error: SSA name in freelist but still referenced D.9231_46 cc1plus: note: in statement lrc_55 = D.9231_46 != D.8194_53; cq.cc:562:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Preprocessed C++ source attached. Flags -O3 -ffast-math required. -- Summary: error: SSA name in freelist but still referenced Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dcb314 at hotmail dot com GCC host triplet: x86_64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41728
[Bug c++/41728] error: SSA name in freelist but still referenced
--- Comment #1 from dcb314 at hotmail dot com 2009-10-16 10:08 --- Created an attachment (id=18808) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18808action=view) C++ source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41728
[Bug debug/41717] [4.5 Regression] internal compiler error: in expand_debug_expr
--- Comment #10 from jakub at gcc dot gnu dot org 2009-10-16 10:43 --- Subject: Bug 41717 Author: jakub Date: Fri Oct 16 10:43:18 2009 New Revision: 152897 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152897 Log: PR debug/41717 * cfgexpand.c (expand_debug_expr): Handle CONJ_EXPR. * dwarf2out.c (mem_loc_descriptor): Don't handle POST_INT/POST_DEC/POST_MODIFY like SUBREG. For SUBREG punt if it is not lowpart subreg or if inner mode isn't MODE_INT. * gcc.dg/debug/pr41717.c: New test. Added: trunk/gcc/testsuite/gcc.dg/debug/pr41717.c Modified: trunk/gcc/ChangeLog trunk/gcc/cfgexpand.c trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41717
[Bug tree-optimization/38816] graphite undocumented
--- Comment #2 from rob1weld at aol dot com 2009-10-16 10:46 --- Thanks, Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38816
[Bug debug/41717] [4.5 Regression] internal compiler error: in expand_debug_expr
--- Comment #11 from jakub at gcc dot gnu dot org 2009-10-16 10:51 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41717
[Bug c++/40146] Unexplained 'anonymous' is used uninitialized in this function warning
--- Comment #9 from gcc at abeckmann dot de 2009-10-16 11:05 --- Created an attachment (id=18809) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18809action=view) different test case I've seen this spurious warning, too, and could reduce it to a different, much smaller test case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40146
[Bug c++/41728] error: SSA name in freelist but still referenced
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-10-16 11:32 --- Confirmed. Reducing. -- 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 |2009-10-16 11:32:16 date|| Summary|error: SSA name in freelist |error: SSA name in freelist |but still referenced|but still referenced http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41728
[Bug tree-optimization/41728] [4.5 Regression] error: SSA name in freelist but still referenced
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-10-16 11:39 ---
int a[8];
int s244(void)
{
int lrc, j;
lrc = 0;
for (j=0; j7; j++)
if(a[j] != a[j+1])
lrc = 1;
if (lrc != 0)
return 0;
return 1;
}
-O3 required. After 126t.cddce2.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Component|c++ |tree-optimization
Summary|error: SSA name in freelist |[4.5 Regression] error: SSA
|but still referenced|name in freelist but still
||referenced
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41728
[Bug middle-end/41713] -O -flto -g: ICE in lto_output_tree_ref, at lto-streamer-out.c:732
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-10-16 11:41 --- I'll fix it anyway. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2009-10-16 09:04:45 |2009-10-16 11:41:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41713
[Bug c++/41723] Error when using a qualified name to declare a nested template instantiation as a friend of the containing template
--- Comment #2 from redi at gcc dot gnu dot org 2009-10-16 11:42 --- This looks very similar to bug 41038, but still fails with 4.4.2 N.B. you don't need the friend declaration at all, nested types can access all members of their enclosing class (this was changed by DR45) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41723
[Bug target/41722] internal compiler error / unable to generate reloads
--- Comment #3 from mikpe at it dot uu dot se 2009-10-16 11:48 --- I can reproduce this ICE with gcc 4.3.4, 4.4.2, and 4.5-20091008 when compiling for armv7-a and hardfloat and FPA. Dropping the -march=armv7-a or switching to softfloat masks the ICE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41722
[Bug tree-optimization/41728] [4.5 Regression] error: SSA name in freelist but still referenced
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-10-16 12:09 --- After DOM2 we have bb 2: D.2725_21 = a[0]; D.2706_26 = D.2725_21; D.2708_28 = a[1]; a_I_lsm0.4_29 = D.2708_28; lrc_30 = D.2725_21 != D.2708_28; ... but D.2725_21 : -- single use. D.2706_26 = D.2725_21; DOM changes lrc_30 = [cond_expr] D.2706_26 == D.2708_28 ? 0 : 1; to lrc_30 = D.2725_21 != D.2708_28; and likely misses an update_stmt() (again). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41728
[Bug tree-optimization/41728] [4.5 Regression] error: SSA name in freelist but still referenced
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-10-16 12:18 --- I have a patch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2009-10-16 11:32:16 |2009-10-16 12:18:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41728
[Bug middle-end/41729] New: Undefined reference with -fPIC -fwhole-program -flto
extern C {
extern int printf (__const char *__restrict __format, ...);
}
class cException { };
class TCmdenvApp {
public:
virtual int run();
};
int TCmdenvApp::run()
{
try {
printf(\nPreparing for Run #%d...\n, 1);
}
catch (cException *e) {
}
}
int main()
{
TCmdenvApp app;
app.run();
}
./g++ -B. -B ../x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs cmdenv.3.ii
-flto -fwhole-program -fPIC
/tmp/ccc2e3Uh.lto.o:(.gcc_except_table+0x10): undefined reference to `.LDFCM0'
collect2: ld returned 1 exit status
works without either of -flto, -fwhole-program or -fPIC.
It looks like .LDFCM0 is privatized on read-in to .LDFCM0.1932 in
lto_set_decl_assembler_name but dwarf2out does not compensate for that?
--
Summary: Undefined reference with -fPIC -fwhole-program -flto
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: lto
Severity: normal
Priority: P3
Component: middle-end
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=41729
[Bug c++/40146] Unexplained 'anonymous' is used uninitialized in this function warning
--- Comment #10 from gcc at abeckmann dot de 2009-10-16 13:11 --- === compile command (shows the spurious warning) === x86_64-linux-gnu-g++-4.4.x -O2 -W -Wall -DSPURIOUS_WARNING -c anonymous-iuuitf.cpp === === === compile command (no spurious warning) === x86_64-linux-gnu-g++-4.4.x -O2 -W -Wall -c anonymous-iuuitf.cpp === === === spurious warning reported: === anonymous-iuuitf.cpp: In function (static initializers for anonymous-iuuitf.cpp): anonymous-iuuitf.cpp:45: warning: anonymous is used uninitialized in this function === === The spurious warning also occurs with a i686 4.4.x compiler. It does not happen with 4.3.x or trunk/4.5.x (both x86_64 and i686). The warning also disappears if optimization is reduced from -O2 to -O1. === verbose output === $ x86_64-linux-gnu-g++-4.4.x -v -O2 -W -Wall -DSPURIOUS_WARNING -c anonymous-iuuitf.cpp Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4_4-branch/configure --prefix=/opt/software/x86_64/gcc-4.4.x --program-suffix=-4.4.x --enable-languages=c,c++ --enable-checking Thread model: posix gcc version 4.4.3 20091016 (prerelease) (GCC) COLLECT_GCC_OPTIONS='-v' '-O2' '-W' '-Wall' '-DSPURIOUS_WARNING' '-c' '-shared-libgcc' '-mtune=generic' /opt/software/x86_64/gcc-4.4.x/libexec/gcc/x86_64-unknown-linux-gnu/4.4.3/cc1plus -quiet -v -D_GNU_SOURCE -DSPURIOUS_WARNING anonymous-iuuitf.cpp -quiet -dumpbase anonymous-iuuitf.cpp -mtune=generic -auxbase anonymous-iuuitf -O2 -W -Wall -version -o /tmp/ccrjG8Y8.s ignoring nonexistent directory /opt/software/x86_64/gcc-4.4.x/lib/gcc/x86_64-unknown-linux-gnu/4.4.3/../../../../x86_64-unknown-linux-gnu/include #include ... search starts here: #include ... search starts here: /opt/software/x86_64/gcc-4.4.x/lib/gcc/x86_64-unknown-linux-gnu/4.4.3/../../../../include/c++/4.4.3 /opt/software/x86_64/gcc-4.4.x/lib/gcc/x86_64-unknown-linux-gnu/4.4.3/../../../../include/c++/4.4.3/x86_64-unknown-linux-gnu /opt/software/x86_64/gcc-4.4.x/lib/gcc/x86_64-unknown-linux-gnu/4.4.3/../../../../include/c++/4.4.3/backward /usr/local/include /opt/software/x86_64/gcc-4.4.x/include /opt/software/x86_64/gcc-4.4.x/lib/gcc/x86_64-unknown-linux-gnu/4.4.3/include /opt/software/x86_64/gcc-4.4.x/lib/gcc/x86_64-unknown-linux-gnu/4.4.3/include-fixed /usr/include End of search list. GNU C++ (GCC) version 4.4.3 20091016 (prerelease) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.4.3 20091016 (prerelease), GMP version 4.3.1, MPFR version 2.4.1-p2. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 2f5c889faec03641af0e9a45c39b0565 anonymous-iuuitf.cpp: In function (static initializers for anonymous-iuuitf.cpp): anonymous-iuuitf.cpp:45: warning: anonymous is used uninitialized in this function COLLECT_GCC_OPTIONS='-v' '-O2' '-W' '-Wall' '-DSPURIOUS_WARNING' '-c' '-shared-libgcc' '-mtune=generic' as -V -Qy -o anonymous-iuuitf.o /tmp/ccrjG8Y8.s GNU assembler version 2.19.91 (x86_64-linux-gnu) using BFD version (GNU Binutils for Debian) 2.19.91.20091006 COMPILER_PATH=/opt/software/x86_64/gcc-4.4.x/libexec/gcc/x86_64-unknown-linux-gnu/4.4.3/:/opt/software/x86_64/gcc-4.4.x/libexec/gcc/x86_64-unknown-linux-gnu/4.4.3/:/opt/software/x86_64/gcc-4.4.x/libexec/gcc/x86_64-unknown-linux-gnu/:/opt/software/x86_64/gcc-4.4.x/lib/gcc/x86_64-unknown-linux-gnu/4.4.3/:/opt/software/x86_64/gcc-4.4.x/lib/gcc/x86_64-unknown-linux-gnu/ LIBRARY_PATH=/opt/software/x86_64/gcc-4.4.x/lib/gcc/x86_64-unknown-linux-gnu/4.4.3/:/opt/software/x86_64/gcc-4.4.x/lib/gcc/x86_64-unknown-linux-gnu/4.4.3/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/opt/software/x86_64/gcc-4.4.x/lib/gcc/x86_64-unknown-linux-gnu/4.4.3/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-O2' '-W' '-Wall' '-DSPURIOUS_WARNING' '-c' '-shared-libgcc' '-mtune=generic' === === -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40146
[Bug c++/38908] [4.4 regression] Unexplained 'anonymous' is used uninitialized in this function warning in cc1plus -m64
--- Comment #19 from gcc at abeckmann dot de 2009-10-16 13:13 --- some cases where this warning still occurs in 4.4 are documented in #40146 -- gcc at abeckmann dot de changed: What|Removed |Added CC||gcc at abeckmann dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38908
[Bug middle-end/41730] New: ICE with -flto -fwhole-program
./g++ -B. -B ../x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -O -flto
-fwhole-program auto_derivative_function.3.ii
lto1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
for
template int dim
struct AutoDerivativeFunction {
virtual void gradient_list (void);
};
template int dim
void AutoDerivativeFunctiondim::gradient_list (void)
{
}
template class AutoDerivativeFunction1;
int main() {}
The ICE happens in IPA pure-const:
Program received signal SIGSEGV, Segmentation fault.
0x00b91ebb in propagate ()
at /space/rguenther/src/svn/trunk/gcc/ipa-pure-const.c:876
876 if (pure_const_state w_l-pure_const_state)
(gdb) p w_l
$1 = (funct_state) 0x0
(gdb) bt
#0 0x00b91ebb in propagate ()
at /space/rguenther/src/svn/trunk/gcc/ipa-pure-const.c:876
#1 0x007d5dbd in execute_one_pass (pass=0x14b08c0)
at /space/rguenther/src/svn/trunk/gcc/passes.c:1519
The ICE goes away when dropping either -flto or -fwhole-program.
--
Summary: ICE with -flto -fwhole-program
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: lto
Severity: normal
Priority: P3
Component: middle-end
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=41730
[Bug middle-end/41730] ICE with -flto -fwhole-program
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-10-16 13:54 --- This breaks 447.dealII build currently. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41730
[Bug middle-end/41713] -O -flto -g: ICE in lto_output_tree_ref, at lto-streamer-out.c:732
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-10-16 14:21 --- Subject: Bug 41713 Author: rguenth Date: Fri Oct 16 14:21:05 2009 New Revision: 152902 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152902 Log: 2009-10-16 Richard Guenther rguent...@suse.de PR lto/41713 * lto-streamer-out.c (lto_output_tree_ref): Handle DEBUG_EXPR_DECL the same as VAR_DECL. * gfortran.dg/lto/20091016-1_0.f90: New testcase. Added: trunk/gcc/testsuite/gfortran.dg/lto/20091016-1_0.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/lto-streamer-out.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41713
[Bug middle-end/41713] -O -flto -g: ICE in lto_output_tree_ref, at lto-streamer-out.c:732
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-10-16 14:23 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41713
[Bug lto/41715] VIEW_CONVERT_EXPR use for mismatched prevailing decl replacement doesn't work
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-10-16 14:23 --- Subject: Bug 41715 Author: rguenth Date: Fri Oct 16 14:23:22 2009 New Revision: 152903 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152903 Log: 2009-10-16 Richard Guenther rguent...@suse.de PR lto/41715 * lto-streamer-in.c (lto_input_tree_ref): Revert last change. (maybe_fixup_handled_component): New function. (input_gimple_stmt): Fixup mismatched decl replacements. lto/ * lto.c (lto_fixup_tree): Revert last change. * gfortran.dg/lto/20091015-1_0.f: New testcase. * gfortran.dg/lto/20091015-1_1.f: Likewise. * gfortran.dg/lto/20091015-1_2.f: Likewise. Added: trunk/gcc/testsuite/gfortran.dg/lto/20091015-1_0.f trunk/gcc/testsuite/gfortran.dg/lto/20091015-1_1.f trunk/gcc/testsuite/gfortran.dg/lto/20091015-1_2.f Modified: trunk/gcc/ChangeLog trunk/gcc/lto-streamer-in.c trunk/gcc/lto/ChangeLog trunk/gcc/lto/lto.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41715
[Bug lto/41715] VIEW_CONVERT_EXPR use for mismatched prevailing decl replacement doesn't work
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-10-16 14:23 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41715
[Bug lto/41598] bootstrap *using* lto fails
--- Comment #14 from rguenth at gcc dot gnu dot org 2009-10-16 14:30 --- This particular problem seems to be fixed. I'll add a testcase. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41598
[Bug lto/41598] bootstrap *using* lto fails
--- Comment #15 from rguenth at gcc dot gnu dot org 2009-10-16 14:43 --- Subject: Bug 41598 Author: rguenth Date: Fri Oct 16 14:42:47 2009 New Revision: 152904 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152904 Log: 2009-10-16 Richard Guenther rguent...@suse.de PR lto/41598 * gcc.dg/lto/20091016-1_0.c: New testcase. * gcc.dg/lto/20091016-1_1.c: Likewise. * gcc.dg/lto/20091016-1_a.h: Likewise. Added: trunk/gcc/testsuite/gcc.dg/lto/20091016-1_0.c trunk/gcc/testsuite/gcc.dg/lto/20091016-1_1.c trunk/gcc/testsuite/gcc.dg/lto/20091016-1_a.h Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41598
[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame
--- Comment #18 from jakub at gcc dot gnu dot org 2009-10-16 14:55 --- When testing this, I've noticed a major problem with Ada, supposedly on the trunk as well when using latest binutils. The problem is that gnat_init_gcc_eh which can change flag_exceptions is called way too late, not from lang_hooks.init, but far after it. This means by the time dwarf2out_init is called flag_exceptions might be still 0 and thus .cfi_sections .dwarf_frame is emitted. But then gnat_init_gcc_eh changes flag_exception to 1 and excepts .eh_frame to be generated. The reason I've put .cfi_sections directive addition to dwarf2out.c is to allow the user to override it within inline assembly, so I don't want to emit it at the end of the file. -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40521
[Bug target/41684] [4.4/4.5 regression] binutils testsuite failures when built with 4.4/4.5
--- Comment #10 from mikpe at it dot uu dot se 2009-10-16 15:16 --- (In reply to comment #7) I'm currently bootstrapping and testing a patch which disable section anchors on arm. It will be interesting to see if it fixes any testsuite failures. Done. It caused no new failures but fixed several objc ones: @@ -339,34 +339,14 @@ Running /home/mikpe/gcc-4.4/gcc/testsuite/objc/compile/compile.exp ... Running /home/mikpe/gcc-4.4/gcc/testsuite/objc/execute/exceptions/exceptions.exp ... Running /home/mikpe/gcc-4.4/gcc/testsuite/objc/execute/execute.exp ... -FAIL: objc/execute/class-13.m compilation, -O1 -fgnu-runtime -FAIL: objc/execute/class-13.m compilation, -O2 -fgnu-runtime -FAIL: objc/execute/class-13.m compilation, -O3 -fomit-frame-pointer -fgnu-runtime -FAIL: objc/execute/class-13.m compilation, -O3 -g -fgnu-runtime -FAIL: objc/execute/class-13.m compilation, -Os -fgnu-runtime -FAIL: objc/execute/class-6.m compilation, -O1 -fgnu-runtime -FAIL: objc/execute/class-6.m compilation, -O2 -fgnu-runtime -FAIL: objc/execute/class-6.m compilation, -O3 -fomit-frame-pointer -fgnu-runtime -FAIL: objc/execute/class-6.m compilation, -O3 -g -fgnu-runtime -FAIL: objc/execute/class-6.m compilation, -Os -fgnu-runtime FAIL: objc/execute/forward-1.m execution, -O0 -fgnu-runtime -FAIL: objc/execute/forward-1.m compilation, -O1 -fgnu-runtime -FAIL: objc/execute/forward-1.m compilation, -O2 -fgnu-runtime -FAIL: objc/execute/forward-1.m compilation, -O3 -fomit-frame-pointer -fgnu-runtime -FAIL: objc/execute/forward-1.m compilation, -O3 -fomit-frame-pointer -funroll-loops -fgnu-runtime -FAIL: objc/execute/forward-1.m compilation, -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions -fgnu-runtime -FAIL: objc/execute/forward-1.m compilation, -O3 -g -fgnu-runtime -FAIL: objc/execute/forward-1.m compilation, -Os -fgnu-runtime -FAIL: objc/execute/object_is_class.m compilation, -O1 -fgnu-runtime -FAIL: objc/execute/object_is_class.m compilation, -O2 -fgnu-runtime -FAIL: objc/execute/object_is_class.m compilation, -O3 -fomit-frame-pointer -fgnu-runtime -FAIL: objc/execute/object_is_class.m compilation, -O3 -g -fgnu-runtime -FAIL: objc/execute/object_is_class.m compilation, -Os -fgnu-runtime -FAIL: objc/execute/object_is_meta_class.m compilation, -O1 -fgnu-runtime -FAIL: objc/execute/object_is_meta_class.m compilation, -O2 -fgnu-runtime -FAIL: objc/execute/object_is_meta_class.m compilation, -O3 -fomit-frame-pointer -fgnu-runtime -FAIL: objc/execute/object_is_meta_class.m compilation, -O3 -g -fgnu-runtime -FAIL: objc/execute/object_is_meta_class.m compilation, -Os -fgnu-runtime +FAIL: objc/execute/forward-1.m execution, -O1 -fgnu-runtime +FAIL: objc/execute/forward-1.m execution, -O2 -fgnu-runtime +FAIL: objc/execute/forward-1.m execution, -O3 -fomit-frame-pointer -fgnu-runtime +FAIL: objc/execute/forward-1.m execution, -O3 -fomit-frame-pointer -funroll-loops -fgnu-runtime +FAIL: objc/execute/forward-1.m execution, -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions -fgnu-runtime +FAIL: objc/execute/forward-1.m execution, -O3 -g -fgnu-runtime +FAIL: objc/execute/forward-1.m execution, -Os -fgnu-runtime Running /home/mikpe/gcc-4.4/gcc/testsuite/objc.dg/dg.exp ... Running /home/mikpe/gcc-4.4/gcc/testsuite/objc.dg/gnu-encoding/gnu-encoding.exp ... Running /home/mikpe/gcc-4.4/gcc/testsuite/objc.dg/pch/pch.exp ... @@ -374,10 +354,9 @@ === objc Summary === -# of expected passes 1819 -# of unexpected failures 28 +# of expected passes 1866 +# of unexpected failures 8 # of expected failures 7 -# of unresolved testcases 27 # of unsupported tests 24 I had hoped that it might fix some small C or C++ test case which could then be used for debugging section anchors, but no such luck. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41684
[Bug lto/41731] New: The linker plugin should support translations
Joseph S. Myers says: Is this callback interface defined to take translated or untranslated text? If untranslated, there would be a problem with the callback knowing which textual domain to use for translation, so I'd guess it should be defined to take translated messages. This means you should be translating the messages first, using dgettext to use the right domain (which I think should be gcc rather than inventing yet another domain for a few messages). You also need to call bindtextdomain - see how cpplib does things for an example of one domain being used in a library in a program that mainly uses another domain (cpplib and gcc there, gcc and whatever domain the linker uses - it appears to be gold - here). Then gcc/po/exgettext needs to get the messages extracted for translation into gcc/po/gcc.pot. -- Summary: The linker plugin should support translations Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: espindola at google dot com GCC build triplet: x86_64-linux-gnu GCC host triplet: x86_64-linux-gnu GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41731
[Bug fortran/41714] [OOP] ALLOCATE SOURCE= does not properly copy the value from SOURCE
--- Comment #3 from janus at gcc dot gnu dot org 2009-10-16 16:22 --- (In reply to comment #2) Problem: The patch in comment #1 regresses on class_allocate_1.f03: In addition to this there are two more test cases failing: Native configuration is x86_64-unknown-linux-gnu === gfortran tests === Schedule of variations: unix Running target unix Using /usr/share/dejagnu/baseboards/unix.exp as board description file for target. Using /usr/share/dejagnu/config/unix.exp as generic interface file for target. Using /home/jweil/gcc45/trunk/gcc/testsuite/config/default.exp as tool-and-target-specific interface file. Running /home/jweil/gcc45/trunk/gcc/testsuite/gfortran.dg/debug/debug.exp ... Running /home/jweil/gcc45/trunk/gcc/testsuite/gfortran.dg/dg.exp ... FAIL: gfortran.dg/class_allocate_1.f03 -O1 (internal compiler error) FAIL: gfortran.dg/class_allocate_1.f03 -O1 (test for excess errors) FAIL: gfortran.dg/class_allocate_1.f03 -O2 (internal compiler error) FAIL: gfortran.dg/class_allocate_1.f03 -O2 (test for excess errors) FAIL: gfortran.dg/class_allocate_1.f03 -O3 -fomit-frame-pointer (internal compiler error) FAIL: gfortran.dg/class_allocate_1.f03 -O3 -fomit-frame-pointer (test for excess errors) FAIL: gfortran.dg/class_allocate_1.f03 -O3 -fomit-frame-pointer -funroll-loops (internal compiler error) FAIL: gfortran.dg/class_allocate_1.f03 -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: gfortran.dg/class_allocate_1.f03 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (internal compiler error) FAIL: gfortran.dg/class_allocate_1.f03 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: gfortran.dg/class_allocate_1.f03 -O3 -g (internal compiler error) FAIL: gfortran.dg/class_allocate_1.f03 -O3 -g (test for excess errors) FAIL: gfortran.dg/class_allocate_1.f03 -Os (internal compiler error) FAIL: gfortran.dg/class_allocate_1.f03 -Os (test for excess errors) FAIL: gfortran.dg/dynamic_dispatch_4.f03 -O0 (test for excess errors) FAIL: gfortran.dg/dynamic_dispatch_4.f03 -O1 (test for excess errors) FAIL: gfortran.dg/dynamic_dispatch_4.f03 -O2 (test for excess errors) FAIL: gfortran.dg/dynamic_dispatch_4.f03 -O3 -fomit-frame-pointer (test for excess errors) FAIL: gfortran.dg/dynamic_dispatch_4.f03 -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: gfortran.dg/dynamic_dispatch_4.f03 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: gfortran.dg/dynamic_dispatch_4.f03 -O3 -g (test for excess errors) FAIL: gfortran.dg/dynamic_dispatch_4.f03 -Os (test for excess errors) FAIL: gfortran.dg/dynamic_dispatch_5.f03 -O (test for excess errors) Running /home/jweil/gcc45/trunk/gcc/testsuite/gfortran.dg/gomp/gomp.exp ... Running /home/jweil/gcc45/trunk/gcc/testsuite/gfortran.dg/graphite/graphite.exp ... Running /home/jweil/gcc45/trunk/gcc/testsuite/gfortran.dg/guality/guality.exp ... Running /home/jweil/gcc45/trunk/gcc/testsuite/gfortran.dg/lto/lto.exp ... Running /home/jweil/gcc45/trunk/gcc/testsuite/gfortran.dg/vect/vect.exp ... Running /home/jweil/gcc45/trunk/gcc/testsuite/gfortran.fortran-torture/compile/compile.exp ... Running /home/jweil/gcc45/trunk/gcc/testsuite/gfortran.fortran-torture/execute/execute.exp ... === gfortran Summary === # of expected passes32786 # of unexpected failures23 # of expected failures 30 # of unresolved testcases 15 # of unsupported tests 60 /home/jweil/gcc45/build/gcc/testsuite/gfortran/../../gfortran version 4.5.0 20091015 (experimental) [trunk revision 152844] (GCC) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41714
[Bug middle-end/35903] false warning when passing quoted string to function strcmp(arg,no);
--- Comment #3 from cepeda at gmail dot com 2009-10-16 16:51 ---
This bug has no changed for months, I think it is still active.
It seems not to work only when size of char[] is 3 (2+'\0'). A test case is
this:
// Begin of code
#include stdio.h
#include string.h
int main(int argc, char **argv)
{
printf(%d,strcmp(argv[0],A)); // NO warning
printf(%d,strcmp(argv[0],AA)); // warning: array subscript
printf(%d,strcmp(argv[0],AAA)); // NO warning
return 0;
}
// End of code
The compilation says:
$ gcc -v -save-temps -O3 -fno-builtin -funsigned-char -Wall test.c
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.1-4ubuntu8'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--enable-multiarch --enable-linker-build-id --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
--enable-targets=all --disable-werror --with-arch-32=i486 --with-tune=generic
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu
Thread model: posix
gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu8)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-fno-builtin' '-funsigned-char'
'-Wall' '-mtune=generic' '-march=i486'
/usr/lib/gcc/i486-linux-gnu/4.4.1/cc1 -E -quiet -v test.c -D_FORTIFY_SOURCE=2
-mtune=generic -march=i486 -Wall -fno-builtin -funsigned-char -O3
-fpch-preprocess -fstack-protector -o test.i
ignoring nonexistent directory /usr/local/include/i486-linux-gnu
ignoring nonexistent directory
/usr/lib/gcc/i486-linux-gnu/4.4.1/../../../../i486-linux-gnu/include
ignoring nonexistent directory /usr/include/i486-linux-gnu
#include ... search starts here:
#include ... search starts here:
/usr/local/include
/usr/lib/gcc/i486-linux-gnu/4.4.1/include
/usr/lib/gcc/i486-linux-gnu/4.4.1/include-fixed
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-fno-builtin' '-funsigned-char'
'-Wall' '-mtune=generic' '-march=i486'
/usr/lib/gcc/i486-linux-gnu/4.4.1/cc1 -fpreprocessed test.i -quiet -dumpbase
test.c -mtune=generic -march=i486 -auxbase test -O3 -Wall -version -fno-builtin
-funsigned-char -fstack-protector -o test.s
GNU C (Ubuntu 4.4.1-4ubuntu8) version 4.4.1 (i486-linux-gnu)
compiled by GNU C version 4.4.1, GMP version 4.3.1, MPFR version
2.4.1-p2.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 293503c4ddf766b61fc5ff6a5ff38cdc
test.c: In function main:
test.c:7: warning: array subscript is above array bounds
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-fno-builtin' '-funsigned-char'
'-Wall' '-mtune=generic' '-march=i486'
as -V -Qy -o test.o test.s
GNU assembler version 2.19.92 (i486-linux-gnu) using BFD version (GNU Binutils
for Ubuntu) 2.19.92.20091014
COMPILER_PATH=/usr/lib/gcc/i486-linux-gnu/4.4.1/:/usr/lib/gcc/i486-linux-gnu/4.4.1/:/usr/lib/gcc/i486-linux-gnu/:/usr/lib/gcc/i486-linux-gnu/4.4.1/:/usr/lib/gcc/i486-linux-gnu/:/usr/lib/gcc/i486-linux-gnu/4.4.1/:/usr/lib/gcc/i486-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/i486-linux-gnu/4.4.1/:/usr/lib/gcc/i486-linux-gnu/4.4.1/:/usr/lib/gcc/i486-linux-gnu/4.4.1/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc/i486-linux-gnu/4.4.1/../../../:/lib/:/usr/lib/:/usr/lib/i486-linux-gnu/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-fno-builtin' '-funsigned-char'
'-Wall' '-mtune=generic' '-march=i486'
/usr/lib/gcc/i486-linux-gnu/4.4.1/collect2 --build-id --eh-frame-hdr -m
elf_i386 --hash-style=both -dynamic-linker /lib/ld-linux.so.2 -z relro
/usr/lib/gcc/i486-linux-gnu/4.4.1/../../../../lib/crt1.o
/usr/lib/gcc/i486-linux-gnu/4.4.1/../../../../lib/crti.o
/usr/lib/gcc/i486-linux-gnu/4.4.1/crtbegin.o
-L/usr/lib/gcc/i486-linux-gnu/4.4.1 -L/usr/lib/gcc/i486-linux-gnu/4.4.1
-L/usr/lib/gcc/i486-linux-gnu/4.4.1/../../../../lib -L/lib/../lib
-L/usr/lib/../lib -L/usr/lib/gcc/i486-linux-gnu/4.4.1/../../..
-L/usr/lib/i486-linux-gnu test.o -lgcc --as-needed -lgcc_s --no-as-needed -lc
-lgcc --as-needed -lgcc_s --no-as-needed
/usr/lib/gcc/i486-linux-gnu/4.4.1/crtend.o
/usr/lib/gcc/i486-linux-gnu/4.4.1/../../../../lib/crtn.o
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35903
[Bug tree-optimization/41718] internal compiler error: in add_stack_var_conflict, at cfgexpand.c:359
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-10-16 16:56 --- There are a lot of variables here. I don't even know if the resulting binary will have enough stack space for those variables ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41718
[Bug tree-optimization/41728] [4.5 Regression] error: SSA name in freelist but still referenced
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-10-16 16:57 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41728
[Bug tree-optimization/41728] [4.5 Regression] error: SSA name in freelist but still referenced
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-10-16 16:57 --- Subject: Bug 41728 Author: rguenth Date: Fri Oct 16 16:57:31 2009 New Revision: 152910 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152910 Log: 2009-10-16 Richard Guenther rguent...@suse.de PR tree-optimization/41728 * tree-ssa-dom.c (optimize_stmt): Mark the stmt modified if fold_stmt did anything. * gcc.c-torture/compile/pr41728.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr41728.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-dom.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41728
[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame
--- Comment #19 from ebotcazou at gcc dot gnu dot org 2009-10-16 17:35 --- When testing this, I've noticed a major problem with Ada, supposedly on the trunk as well when using latest binutils. Thanks for the heads up. The problem is that gnat_init_gcc_eh which can change flag_exceptions is called way too late, not from lang_hooks.init, but far after it. This means by the time dwarf2out_init is called flag_exceptions might be still 0 and thus .cfi_sections .dwarf_frame is emitted. But then gnat_init_gcc_eh changes flag_exception to 1 and excepts .eh_frame to be generated. Can we arrange for making it safe to set flag_exceptions from lang_hooks.init and then clear it in gnat_init_gcc_eh? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40521
[Bug lto/41593] slightly confusing configure message about lto
--- Comment #2 from rwild at gcc dot gnu dot org 2009-10-16 17:56 --- The duplicate lto in the language list has been fixed in r152697, http://gcc.gnu.org/ml/gcc-patches/2009-10/msg00682.html. However, the way to enable lto still is not to add it to --enable-languages, but to use --enable-lto. If that's ok, then this bug can be closed. If OTOH we want --enable-languages=c,lto to cause a failure if lto cannot be built, then that can be fixed, too. -- rwild at gcc dot gnu dot org changed: What|Removed |Added CC||rwild at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41593
[Bug fortran/41719] [OOP] invalid: Intrinsic assignment involving polymorphic variables
--- Comment #2 from janus at gcc dot gnu dot org 2009-10-16 18:44 ---
Preliminary patch:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (Revision 152915)
+++ gcc/fortran/resolve.c (Arbeitskopie)
@@ -7629,6 +7629,14 @@ resolve_ordinary_assign (gfc_code *code, gfc_names
}
}
+ /* F03:7.4.1.2. */
+ if (lhs-ts.type == BT_CLASS)
+{
+ gfc_error (Variable must not be polymorphic in assignment at %L,
+lhs-where);
+ return false;
+}
+
gfc_check_assign (lhs, rhs, 1);
return false;
}
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
Summary|invalid: Intrinsic |[OOP] invalid: Intrinsic
|assignment involving|assignment involving
|polymorphic variables |polymorphic variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41719
[Bug fortran/41719] [OOP] invalid: Intrinsic assignment involving polymorphic variables
--- Comment #3 from janus at gcc dot gnu dot org 2009-10-16 18:55 --- Actually the following two test cases are invalid according to this PR: typebound_operator_2.f03 typebound_operator_4.f03 Both include an intrinsic assignment with a polymorphic (dummy) variable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41719
[Bug fortran/41719] [OOP] invalid: Intrinsic assignment involving polymorphic variables
--- Comment #4 from janus at gcc dot gnu dot org 2009-10-16 19:10 --- Note: It seems this will be legal again in F08. 7.2.1.2 Intrinsic assignment statement An intrinsic assignment statement is an assignment statement that is not a de#64257;ned assignment statement (7.2.1.4). In an intrinsic assignment statement, (1) if the variable is polymorphic it shall be allocatable and not a coarray, ... (4) if the variable is polymorphic it shall be type compatible with expr ; otherwise the declared types of the variable and expr shall conform as speci#64257;ed in Table 7.10, ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41719
[Bug fortran/41732] New: build of gcc v4.4.1 dies in gfortran on Solaris 10 (sparc)
I am attempting to build the gcc v 4.4.1 suite of compilers on a Solaris 10 (sparc) platform using gcc v3.4.6. The build runs great for about 3 hours and then dies complaining that GNU Fortran is not working;. I will attempt to attach the config.log file to this bug report from /local/gcc441/sparc-sun-solaris2.10/libgfortran/ (config.log) I'll also attach a script output file (configure.scr) that shows what options were used with the configure command. I'll also attach the last ~200 lines of the make output to the terminal. -- Summary: build of gcc v4.4.1 dies in gfortran on Solaris 10 (sparc) Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: major Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: thomas dot preston at baesystems dot com GCC build triplet: gcc 3.4.6 GCC host triplet: gcc 3.4.6 GCC target triplet: gcc 4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41732
[Bug fortran/41732] build of gcc v4.4.1 dies in gfortran on Solaris 10 (sparc)
--- Comment #1 from thomas dot preston at baesystems dot com 2009-10-16 19:13 --- Created an attachment (id=18810) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18810action=view) the config.log from /local/gcc441/sparc-sun-solaris2.10/libgfortran -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41732
[Bug fortran/41732] build of gcc v4.4.1 dies in gfortran on Solaris 10 (sparc)
--- Comment #2 from thomas dot preston at baesystems dot com 2009-10-16 19:14 --- Created an attachment (id=18811) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18811action=view) scripted output of running the configure command showing options -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41732
[Bug fortran/41732] build of gcc v4.4.1 dies in gfortran on Solaris 10 (sparc)
--- Comment #3 from thomas dot preston at baesystems dot com 2009-10-16 19:15 --- Created an attachment (id=18812) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18812action=view) last 200 lines of make output displayed on the terminal -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41732
[Bug fortran/41732] build of gcc v4.4.1 dies in gfortran on Solaris 10 (sparc)
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-10-16 19:16 --- init2.c:37: assertion failed: ((64 - 0)+0) == (((64 - 0)+0)/8) * 8 sizeof(mp_limb_t) == (((64 - 0)+0)/8) That means your GMP and/or MPFR is broken and you should rebuild them. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41732
[Bug fortran/41719] [OOP] invalid: Intrinsic assignment involving polymorphic variables
--- Comment #5 from janus at gcc dot gnu dot org 2009-10-16 19:19 --- (In reply to comment #4) Note: It seems this will be legal again in F08. That is: for certain cases (ALLOCATABLE). The example in comment #0 is still illegal. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41719
[Bug target/40983] The scheduler incorrectly swaps MMX and floating point instructions
--- Comment #5 from sezeroz at gmail dot com 2009-10-16 19:45 --- Any progress on this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40983
[Bug fortran/41733] New: Proc-pointer conformance checks
Pointed out by James Van Buskirk in http://groups.google.com/group/comp.lang.fortran/msg/c96779deea345264 in the thread http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/da1feef5e8c9ed9a Gfortran misses several proc-pointer checks. Cf. also PR 41724. -- Summary: Proc-pointer conformance checks Product: gcc Version: 4.5.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=41733
[Bug libstdc++/40654] [C++0x] atomic.cc: 'd' is used uninitialized warning
--- Comment #5 from sezeroz at gmail dot com 2009-10-16 19:49 --- Any chance for a backport to 4.4 ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40654
[Bug debug/41340] [4.5 Regression] G++ produces different code with and without -g option
--- Comment #5 from d dot g dot gorbachev at gmail dot com 2009-10-16 20:09 --- There is a real difference, i.e. - 179: mov0x8(%ebp),%edx - 17c: movzwl (%edx),%eax + 179: mov0x8(%ebp),%esi + 17c: movzwl (%esi),%eax [...] - 1a0: mov%edx,(%esp) - 1a3: mov%edx,-0x24(%ebp) - 1a6: call 1a7 _Z8copy_rtxP7rtx_def+0x37 - 1ab: mov%eax,%ecx - 1ad: movzbl 0x3(%eax),%eax - 1b1: mov%eax,%esi - 1b3: and$0xffdf,%eax [...] + 1a0: mov%esi,(%esp) + 1a3: call 1a4 _Z8copy_rtxP7rtx_def+0x34 + 1a8: mov%eax,%edi + 1aa: movzbl 0x3(%eax),%eax + 1ae: mov%eax,%ecx + 1b0: and$0xffdf,%eax + 1b3: mov%al,0x3(%edi) etc. -fcompare-debug produces -fcompare-debug failure (length) -- d dot g dot gorbachev at gmail dot com changed: What|Removed |Added Status|WAITING |UNCONFIRMED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41340
[Bug debug/41340] [4.5 Regression] G++ produces different code with and without -g option
--- Comment #6 from d dot g dot gorbachev at gmail dot com 2009-10-16 20:12 --- Created an attachment (id=18813) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18813action=view) gzipped preprocessed source file Another case. Compile with: cc1 -O3 -march=i686 -g tree-eh.i -2fb6: sub$0xdc,%esp +2fb6: sub$0xcc,%esp [...] -38f2: mov$0x1,%edi -38f7: movb $0x0,-0x98(%ebp) -38fe: mov%edx,-0x9c(%ebp) -3904: cmp%eax,(%ecx) -3906: jne3ad9 execute_cleanup_eh+0xb29 [...] +38f2: xor%edi,%edi +38f4: cmp%eax,(%ecx) +38f6: jne3ac3 execute_cleanup_eh+0xb13 +38fc: mov0x0,%eax +3901: xor%esi,%esi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41340
[Bug fortran/35810] [TR 15581 / F2003] Automatic reallocation on assignment to allocatable variables
--- Comment #6 from burnus at gcc dot gnu dot org 2009-10-16 20:23 --- Note in Fortran 2008 (cf. PR 41719), polymorphic-variable = expr is allowed iff the variable is allocatable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35810
[Bug fortran/41719] [OOP] invalid: Intrinsic assignment involving polymorphic variables
--- Comment #6 from burnus at gcc dot gnu dot org 2009-10-16 20:25 --- (In reply to comment #5) (In reply to comment #4) Note: It seems this will be legal again in F08. That is: for certain cases (ALLOCATABLE). The example in comment #0 is still illegal. if the variable is polymorphic it shall be type compatible with expr That's obvious. If I have CLASS(t) :: c, I cannot do an intrinsic assignment such as c = .true. - or c = t2 (assuming that t2 does not extend t). Regarding: if the variable is polymorphic it shall be allocatable and not a coarray, Allocatables are special as for A = B, A is (re)allocated on the fly iff A is unallocated or the shape/length type parameters does not match the RHS. (If they do match, no reallocation is happening - which matters if A has the TARGET attribute and is associated with a pointer.) Cf. 7.2.1.3 Interpretation of intrinsic assignments. I suggest to ignore F2008 and defer it until we have the realloc on assignment implemented. Cf. PR 35810. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41719
[Bug fortran/41733] Proc-pointer conformance checks: Elemental-proc-ptr = non-elemental-proc
--- Comment #1 from burnus at gcc dot gnu dot org 2009-10-16 20:35 --- The first example, procedure(fun), pointer :: f f = my_dcos write(*,*) f(x) looks fine to me. fun is elemental - and my_dcos is also elemental. The second example is wrong: fun is elemental, but my_dcos is not thus f = my_dcos is invalid per F2003, 7.4.2.2 Procedure pointer assignment: If proc-pointer-object has an explicit interface, its characteristics shall be the same as proc-target except that proc-target may be pure even if proc-pointer-object is not pure and proc-target may be an elemental intrinsic procedure even if proc-pointer-object is not elemental. The third example looks OK again - actually, it is the same as the first, except that one uses an intrinsic elemental procedure (dcos). Test case for the second example: module funcs implicit none integer, parameter :: dp = kind(1.0d0) abstract interface elemental function fun(x) import implicit none real(dp), intent(in) :: x real(dp) fun end function fun end interface contains function my_dcos(x) integer, parameter :: dp = kind(1.0d0) real(dp), intent(in) :: x real(dp) :: my_dcos my_dcos = cos(x) end function end module funcs program start use funcs implicit none procedure(fun), pointer :: f real(dp) x(3) x = [1,2,3] f = my_dcos write(*,*) f(x) end program start -- burnus at gcc dot gnu dot org changed: What|Removed |Added Summary|Proc-pointer conformance|Proc-pointer conformance |checks |checks: Elemental-proc-ptr ||= non-elemental-proc http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41733
