[Bug target/47564] internal compiler error in memory_address_addr_space, at explow.c:504
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47564 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-01 08:20:20 UTC --- target attribute is a never ending source of problems.
[Bug fortran/47565] New: [4.6 Regression][OOP] Segfault with TBP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47565 Summary: [4.6 Regression][OOP] Segfault with TBP Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org CC: ja...@gcc.gnu.org Follow up to bug 47455 comment 4. The following program works with gfortran 4.5 but with gfortran 4.6 it segfaults at run time at the marked line. Using a normal function call instead of a TBP call works as well. ==20391== Jump to the invalid address stated on the next line ==20391==at 0x0: ??? ==20391==by 0x400C49: MAIN__ (444.f90:27) ==20391==by 0x400C7F: main (444.f90:25) The dump shows the following difference between working and failing: -this-_data-y = *find_y (); +this-_data-y = *this-_vptr-find_y (); If one compares this with a working call and POINTER attribute (cf. attachment 23130 to bug 47455 comment 4), one sees: ! Working: this-_data-x = this-_vptr-find_x (...) ! Failing: this-_data-y = *this-_vptr-find_y (...) Note the extra *. module class_t type :: tx integer, dimension(:), allocatable :: i end type tx type :: t type(tx) :: y contains procedure :: calc procedure, nopass :: find_y end type t contains subroutine calc(this) class(t) :: this ! WORKS: ! this%y = find_y() ! Segfaults: this%y = this%find_y() ! Segfault at run time print *, allocated(this%y%i) end subroutine calc function find_y() result(res) type(tx), allocatable :: res allocate(res) end function find_y end module class_t use class_t type(t) :: x call x%calc() end
[Bug fortran/47455] [4.6 Regression][OOP] internal compiler error: in fold_convert_loc, at fold-const.c:2028
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47455 --- Comment #13 from Tobias Burnus burnus at gcc dot gnu.org 2011-02-01 08:50:39 UTC --- (In reply to comment #12) valgrind ./a.out shows: That seems to be a valgrind bug; even a simple Fortran program consisting of end causes the problem. The crash with comment 4 is now a separate bug: PR 47565 Thus, left to do for this PR is comment 5: A deep copy is missing.
[Bug target/47558] 163267 breaks exception traceback in xplor-nih
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #9 from Iain Sandoe iains at gcc dot gnu.org 2011-02-01 09:08:53
UTC ---
Jack,
The linkage of libs (with trunk darwin.h) is like this:
libgcc_ext.dylib --- exports our additional symbols (ONLY)**
libSystem contains the annotated system symbols.
** this causes the reference to /my/install/path/libgcc_s.1.dylib to be
inserted into the exe.
As below:
===
mini-02-sno:gcc-4-6-trunk-build$ uname -a
Darwin mini-02-sno.local 10.6.0 Darwin Kernel Version 10.6.0: Wed Nov 10
18:13:17 PST 2010; root:xnu-1504.9.26~3/RELEASE_I386 i386 i386
mini-02-sno:gcc-4-6-trunk-build$ cat /Volumes/ScratchCS/tests/linkage.c
/* This is not meant to work or do anything useful !!!
-- sole purpose is to allow examination of linkage. */
int main (void)
{
static __thread i; === make it link our ext lib.
i+i;
_Unwind_Resume ((void *)0); == make it link libSystem (we expect - NOT from
our ext.)
return i;
}
==
mini-02-sno:gcc-4-6-trunk-build$ ./gcc/xgcc -Bgcc
/Volumes/ScratchCS/tests/linkage.c -o tt
mini-02-sno:gcc-4-6-trunk-build$ nm -mv tt
00010f80 (__TEXT,__stub_helper) non-external (was a private external)
stub helpers
00011060 (__DATA,__data) external _NXArgc
00011068 (__DATA,__data) external _NXArgv
(undefined [lazy bound]) external __Unwind_Resume (from
libSystem) === correct
(undefined [lazy bound]) external ___emutls_get_address (from
libgcc) === correct
00011080 (__DATA,__data) non-external ___emutls_v.i.1606
00011078 (__DATA,__data) external ___progname
00010f38 (__TEXT,__text) non-external __dyld_func_lookup
0001 (absolute) [referenced dynamically] external
__mh_execute_header
00011070 (__DATA,__data) external _environ
(undefined [lazy bound]) external _exit (from libSystem)
00010f3e (__TEXT,__text) external _main
(undefined) external dyld_stub_binder (from libSystem)
00010f24 (__TEXT,__text) non-external dyld_stub_binding_helper
00010ee8 (__TEXT,__text) external start
mini-02-sno:gcc-4-6-trunk-build$ DYLD_PRINT_LIBRARIES=1 ./tt
dyld: loaded: /Volumes/GCC/gcc-4-6-trunk-build/./tt
dyld: loaded:
/GCC/gcc-4-6-install/lib/gcc/x86_64-apple-darwin10/4.6.0/libgcc_s.1.dylib
dyld: loaded: /usr/lib/libSystem.B.dylib
dyld: loaded: /usr/lib/system/libmathCommon.A.dylib
Segmentation fault === no surprise, the program is not meant to work
although the program does not work - you can
(a) install your built gcc [without modifying darwin.h]
(b) compile the prog with debug and step through to find that the
_Unwind_Resume that is called __is__ the one from libSystem.
[Bug fortran/46990] [OOP] gfortran rejects passing a CLASS variable to TYPE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46990 --- Comment #7 from Tobias Burnus burnus at gcc dot gnu.org 2011-02-01 09:26:52 UTC --- A variant is http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/dad37643dd8cd0c6 where the defined assignment has: elemental subroutine assign (a, b) class(base_type), intent(out) :: a type(base_type), intent(in) :: b which is not recognized by gfortran and thus the: class(base_type), dimension(:), allocatable, intent(inout) :: a class(base_type), dimension(:), allocatable :: tmp tmp(:size(a)) = a ! polymorphic l.h.s. is rejected.
[Bug middle-end/47566] New: ICE in vn_reference_lookup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47566 Summary: ICE in vn_reference_lookup Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: joost.vandevond...@pci.uzh.ch current trunk fails with ICE compiling with LTO cp2k. /data03/vondele/gnu/gcc_trunk/install/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto1 -march=amdfam10 -mcx16 -msahf -mpopcnt -mabm --param l1-cache-size=64 --param l1-cache-line-size=64 --param l2-cache-size=512 -mtune=amdfam10 -quiet -dumpdir /data03/vondele/cp2k_gcc/cp2k/makefiles/../exe/gfortran-test24/ -dumpbase cp2k.sopt.ltrans1 -auxbase-strip cp2k.sopt.ltrans1.ltrans.o -O3 -version -ffree-form -funroll-loops -ffast-math -fuse-linker-plugin -fltrans cp2k.sopt.ltrans1.o -o cp2k.sopt.ltrans1.s -v GNU GIMPLE (GCC) version 4.6.0 20110201 (experimental) [trunk revision 169466] (x86_64-unknown-linux-gnu) compiled by GNU C version 4.6.0 20110201 (experimental) [trunk revision 169466], GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU GIMPLE (GCC) version 4.6.0 20110201 (experimental) [trunk revision 169466] (x86_64-unknown-linux-gnu) compiled by GNU C version 4.6.0 20110201 (experimental) [trunk revision 169466], GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 In file included from :520:0: /data03/vondele/cp2k_gcc/cp2k/makefiles/../src/fft_tools.F: In function ‘fft3d_pb’: /data03/vondele/cp2k_gcc/cp2k/makefiles/../src/fft_tools.F:994:0: internal compiler error: Segmentation fault in gdb I get Program received signal SIGSEGV, Segmentation fault. 0x0079583b in vn_reference_lookup (op=0x7fffef4a4460, vuse=0x7532eb40, kind=VN_WALK, vnresult=0x0) at ../../gcc/gcc/tree-ssa-sccvn.c:1543 1543 vr1.vuse = vuse ? SSA_VAL (vuse) : NULL_TREE; (gdb) bt #0 0x0079583b in vn_reference_lookup (op=0x7fffef4a4460, vuse=0x7532eb40, kind=VN_WALK, vnresult=0x0) at ../../gcc/gcc/tree-ssa-sccvn.c:1543 #1 0x00787a0c in eliminate () at ../../gcc/gcc/tree-ssa-pre.c:4331 #2 0x0078a2a5 in execute_pre (do_fre=0 '\000') at ../../gcc/gcc/tree-ssa-pre.c:4901 #3 execute_pre (do_fre=0 '\000') at ../../gcc/gcc/tree-ssa-pre.c:4845 #4 0x0064fdb9 in execute_one_pass (pass=0x10968c0) at ../../gcc/gcc/passes.c:1561 #5 0x00650065 in execute_pass_list (pass=0x10968c0) at ../../gcc/gcc/passes.c:1616 #6 0x00650077 in execute_pass_list (pass=0x10957e0) at ../../gcc/gcc/passes.c:1617 #7 0x0071b481 in tree_rest_of_compilation (fndecl=0x75c2ff00) at ../../gcc/gcc/tree-optimize.c:422 #8 0x0085884f in cgraph_expand_function (node=0x754599a0) at ../../gcc/gcc/cgraphunit.c:1563 #9 0x0085a46a in cgraph_expand_all_functions () at ../../gcc/gcc/cgraphunit.c:1622 #10 cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1882 #11 0x004b9fdf in lto_main () at ../../gcc/gcc/lto/lto.c:2457 details of gfortran -v: gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/data03/vondele/gnu/gcc_trunk/install/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/data03/vondele/gnu/gcc_trunk/install --enable-languages=c,c++,fortran --disable-multilib --enable-plugins --enable-cloog-backend=isl --with-ppl=/data03/vondele/gnu/ppl-0.11/install --with-cloog=/data03/vondele/gnu/cloog-0.16.1/install/ --with-libelf=/data03/vondele/gnu/libelf-0.8.13/install --enable-gold --enable-checking=release Thread model: posix gcc version 4.6.0 20110201 (experimental) [trunk revision 169466] (GCC)
[Bug java/47456] internal compiler error: Segmentation fault while using jna
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47456 --- Comment #10 from Mikael Pettersson mikpe at it dot uu.se 2011-02-01 09:40:18 UTC --- Your test case requires using binaries without sources on Win32. You can: 1. Try a newer gcc, preferably 4.5.2. Your pre-4.3.0 development snapshot is ancient and likely to contain bugs which have since been fixed. 2. Supply a test case in source form.
[Bug middle-end/47566] ICE in vn_reference_lookup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47566 --- Comment #1 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-02-01 09:42:12 UTC --- gzipped testcase (2.7Mb) downloadable from http://www.pci.uzh.ch/vandevondele/tmp/cp2k.sopt.ltrans1.o.gz
[Bug libfortran/47567] New: Wrong output for small absolute values with F editing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47567 Summary: Wrong output for small absolute values with F editing Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: thenl...@users.sourceforge.net Fortran 2008, 10.7.2.3.2(9): For an internal value that is neither an IEEE infinity nor a NaN, the output field consists of blanks, if necessary, followed by a minus sign if the internal value is negative, or an optional plus sign otherwise, followed by a string of digits that contains a decimal symbol and represents the magnitude of the internal value, as modified by the established scale factor and rounded (10.7.2.3.7) to d fractional digits. Leading zeros are not permitted except for an optional zero immediately to the left of the decimal symbol if the magnitude of the value in the output field is less than one. The optional zero shall appear if there would otherwise be no digits in the output field. In gfortran, with an (F0.0) edit descriptor, some small values are formatted as ., e.g. print (F0.0), 0.0 ! = 0. print (F0.0), 0.001 ! = . expected 0. print (F0.0), 0.01 ! = . expected 0. print (F0.0), 0.1 ! = 0. Reason: The optional zero shall appear if there would otherwise be no digits in the output field. Any formatting of non-negative values with (F1.n) should always result in asterisks, because a string of digits that contains a decimal symbol, where the optional zero shall appear if there would otherwise be no digits in the output field can never fit in 1. E. g. print (F1.0), 0.0 ! = 0 expected * print (F1.0), 0.001 ! = . expected * print (F1.0), 0.01 ! = . expected * print (F1.0), 0.1 ! = * Similarly, for negative values and (F2.n): print (F2.0), -0.001 ! = -. expected ** print (F2.0), -0.01 ! = -. expected ** print (F2.0), -0.1 ! = ** The exact value 0.0 is formatted with a leading zero with (F0.n) formatting, but this is incorrect, see bug 47434: print (F0.2), 0.0 ! = 0.00 expected .00
[Bug c++/47541] [4.5/4.6 Regression] For integer pointers, the value of ++*p is not written back to memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47541 --- Comment #11 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-01 09:47:26 UTC --- Author: rguenth Date: Tue Feb 1 09:47:21 2011 New Revision: 169468 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=169468 Log: 2011-02-01 Richard Guenther rguent...@suse.de PR tree-optimization/47541 * tree-ssa-structalias.c (push_fields_onto_fieldstack): Make sure to have a field at offset zero. * g++.dg/torture/pr47541.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/torture/pr47541.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-structalias.c
[Bug c++/47568] New: Name lookup: different behavior 4.1.2 / 4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47568 Summary: Name lookup: different behavior 4.1.2 / 4.5.0 Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: matwey.korni...@gmail.com Created attachment 23193 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23193 test There is different behavior with the attached code. when compiled with 4.1.2: assign 1 assign 1 when compiled with 4.5.0: assign 1 assign a Versions: g++-4.1 (GCC) 4.1.2 20070115 (prerelease) (SUSE Linux) gcc (SUSE Linux) 4.5.0 20100604 [gcc-4_5-branch revision 160292] I don't know which behaviors are supported by other versions, but I think that the only one of them is right.
[Bug fortran/47082] [4.6 Regression] [OOP] ICE in gfc_conv_component_ref
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47082 Paul Thomas pault at gcc dot gnu.org changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #5 from Paul Thomas pault at gcc dot gnu.org 2011-02-01 10:00:14 UTC --- (In reply to comment #3) (In reply to comment #2) This does not solve the problem fully, but it reduces it to PR46448: /tmp/cc9UG1CN.s: Assembler messages: /tmp/cc9UG1CN.s:65: Error: symbol `__copy_m0_t0_' is already defined After PR46448 is solved now, the patch fully fixes the test case. Still it feels a bit hackish. Not entirely: If you change the line in module m1 from- class(t0), pointer, private :: idxmap to type(t0), pointer, private :: idxmap then the reduced testcase of comment #1 compiles. Comparing themain programme between the two, you will see a symtree '@2' in the failing case that points to the vtype, '__vtype_m0_T0'. I would guess that this has no backend_decl. Calling gfc_get_derived_type then associates (I think) the backend_decls with that of the symtree '__vtype_m0_T0', which is somehow pointing to a different symbol. I will explore further at lunchtime. Paul
[Bug target/47540] ARM THUMB crash with complex numbers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47540 --- Comment #6 from Mikael Pettersson mikpe at it dot uu.se 2011-02-01 10:11:52 UTC --- The bug started to occur at r140501: Author: pinskia Date: Fri Sep 19 22:24:06 2008 New Revision: 140501 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140501 Log: 2008-09-19 Andrew Pinski andrew_pin...@playstation.sony.com PR tree-opt/30930 * tree-ssa.c (execute_update_addresses_taken): Also update DECL_GIMPLE_REG_P for vector and complex types. But given Ian's observation and proposed patch I suspect r140501 is innocent and merely triggers a bug in the ARM backend.
[Bug target/47540] ARM THUMB crash with complex numbers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47540 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added CC||rearnsha at gcc dot gnu.org --- Comment #7 from Richard Earnshaw rearnsha at gcc dot gnu.org 2011-02-01 10:24:33 UTC --- (In reply to comment #1) Created attachment 23166 [details] Possible patch This is a possible patch for this bug. It fixes what appears to be an obvious bug in the code, and it fixes this test case. However, I am not set up to test the ARM target. Perhaps one of the ARM maintainers could give this patch a try. Looks sensible to me. But please update comment.
[Bug fortran/47569] New: gfortran does not detect that the parameters for passing a partial string to a subroutine are incorrect.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47569 Summary: gfortran does not detect that the parameters for passing a partial string to a subroutine are incorrect. Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: kloe...@knmi.nl gfortran does not detect that the parameters for passing a partial string to a subroutine are incorrect. The example uses s(i) in stead of s(i:j) to pass the string, and this was a common usage pattern in the old fortran77 days, so this may bother more users. Sample code: module teststr implicit none integer, parameter :: GRH_SIZE = 20, NMAX = 41624 type strtype integer :: size character :: mdr(NMAX) end type strtype contains subroutine sub2(string,str_size) integer,intent(in):: str_size character,intent(out) :: string(str_size) string(:) = 'a' end subroutine sub2 subroutine sub1(a) type(strtype),intent(inout) :: a call sub2(a%mdr(GRH_SIZE+1),a%size-GRH_SIZE) end subroutine sub1 end module teststr Command used for compiling: gfortran -c minimal_example.F90 f951: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://bugzilla.redhat.com/bugzilla for instructions. gfortran version used: gfortran --version GNU Fortran (GCC) 4.4.4 20100630 (Red Hat 4.4.4-10) If the line: call sub2(a%mdr(GRH_SIZE+1),a%size-GRH_SIZE) is replaced by: call sub2(a%mdr(GRH_SIZE+1:),a%size-GRH_SIZE) then the compilation runs without problems. Expected output was to get a proper error message with the provided sample code.
[Bug libstdc++/47560] [4.6 Regression] FAIL: abi/header_cxxabi.c (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47560 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||bkoz at redhat dot com --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-02-01 10:57:09 UTC --- Benjamin, can you have a look? Should be a trivial issue related to your recent (nice!) work.
[Bug tree-optimization/45122] [4.6 Regression] -funsafe-loop-optimizations causes FAIL: gcc.c-torture/execute/pr27285.c execution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45122 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #15 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-01 11:02:44 UTC --- Ah, the reason why pr19210-* fail is that those loops have non-const/pure call in it. So, while single_exit (loop) == exit, loop_only_exit_p (loop, exit) still returns false. So, the question is if we really need to give up on -funsafe-loop-optimizations whenever loop_only_exit_p (loop, exit), or if a single_exit (loop) == exit test would be sufficient for that.
[Bug fortran/47569] [4.3/4.4/4.5/4.6 Regression] gfortran does not detect that the parameters for passing a partial string to a subroutine are incorrect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47569 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code CC||burnus at gcc dot gnu.org Summary|gfortran does not detect|[4.3/4.4/4.5/4.6 |that the parameters for |Regression] gfortran does |passing a partial string to |not detect that the |a subroutine are incorrect. |parameters for passing a ||partial string to a ||subroutine are incorrect Known to fail||4.4.4, 4.6.0 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2011-02-01 11:03:57 UTC --- ICE with gfortran 4.3 to 4.6; compiled with gfortran 4.1. Other compilers (NAG, g95, ifort) do not show any compile-time warning/error. ==21718== Invalid read of size 4 ==21718==at 0x4F29A5: compare_actual_formal (interface.c:1689) ==21718==by 0x4F2D5D: gfc_procedure_use (interface.c:2727) ==21718==by 0x53A825: resolve_call (resolve.c:3508) /* Not an array element. */ if (formal-ts.type == BT_CHARACTER (ref == NULL || (actual-expr_type == EXPR_VARIABLE (actual-symtree-n.sym-as-type == AS_ASSUMED_SHAPE || actual-symtree-n.sym-attr.pointer The check does not make sense: For ref-NULL one cannot assume that it is an array ref - it could also be character ref or a component ref.
[Bug c++/47541] [4.5 Regression] For integer pointers, the value of ++*p is not written back to memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47541 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Known to work||4.4.4, 4.6.0 Summary|[4.5/4.6 Regression] For|[4.5 Regression] For |integer pointers, the value |integer pointers, the value |of ++*p is not written |of ++*p is not written |back to memory |back to memory Known to fail||4.5.2 --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-01 11:15:50 UTC --- Fixed on the trunk so far.
[Bug c/47557] Effect of aligned attribute on arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47557 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-01 11:17:53 UTC --- I think the current behavior is correct.
[Bug c++/47570] New: one() = 0 isn't constexpr for unsigned int, yet == and is.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47570
Summary: one() = 0 isn't constexpr for unsigned int, yet ==
and is.
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: yacw...@gmail.com
Target: x86_64-unknown-linux-gnu
Created attachment 23194
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23194
cxp_geq_uint.cpp
I reduced the code down as far as I could. It's fairly self-explanatory.
cxp_geq_uint.cpp
unsigned int constexpr one()
{ return 1; }
int constexpr one_B()
{ return 1; }
int main()
{
// FAIL TO COMPILE:
//static bool constexpr SC_huh = ((unsigned int)one()) = ((unsigned
int)0);
//static bool constexpr SC_huh = one() = ((unsigned int)0);
static bool constexpr SC_huh = one() = 0;
// COMPILE OK:
//static bool constexpr SC_huh = ((one() == 0) || (one() 0));
//static bool constexpr SC_huh = one() == 0;
//static bool constexpr SC_huh = one() 0;
//static bool constexpr SC_huh = one_B() = 0;
//static bool constexpr SC_huh = one() = 1;
return SC_huh;
}
==
g++ cxp_geq_uint.cpp --std=c++0x
==
cxp_geq_uint.cpp: In function ‘int main()’:
cxp_geq_uint.cpp:12:43: error: ‘(1u, true)’ is not a constant expression
==
I can see no reason why = shouldn't be constexpr in this case.
IIRC standard operators and literal casts always have defined behaviour for
standard unsigned integers.
As shown in the code, the problem goes away if:
- The value to the right of = is greater than 0.
- The type is changed to (regular) int.
- The operation is changed to == or (or combining these manually to form =)
SPECS:
gcc: version 4.6.0 2010-12-30 (experimental) (svn = 168358)
- manually patched by
(http://gcc.gnu.org/ml/gcc-patches/2007-04/msg00620.html)
- patch shouldn't have any effect here.
ubuntu: 10.10 (64 bit)
intel: core2 duo
I searched the buglist for constexpr unsigned, didn't see any dupes myself.
I guess this one probably won't be too hard to debug.
I might even have a go if I get some spare time.
HTH.
Simon.
[Bug libfortran/47567] Wrong output for small absolute values with F editing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47567 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org, ||jvdelisle at gcc dot ||gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2011-02-01 11:26:58 UTC --- I concur with the expected results, which match also the NAG compiler. (By the way, other compilers have similar problems.)
[Bug c++/47541] [4.5 Regression] For integer pointers, the value of ++*p is not written back to memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47541 --- Comment #13 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-01 11:27:07 UTC --- Author: rguenth Date: Tue Feb 1 11:27:04 2011 New Revision: 169472 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=169472 Log: 2011-02-01 Richard Guenther rguent...@suse.de PR tree-optimization/47541 * tree-ssa-structalias.c (push_fields_onto_fieldstack): Make sure to have a field at offset zero. * g++.dg/torture/pr47541.C: New testcase. Added: branches/gcc-4_5-branch/gcc/testsuite/g++.dg/torture/pr47541.C Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/testsuite/ChangeLog branches/gcc-4_5-branch/gcc/tree-ssa-structalias.c
[Bug tree-optimization/45122] [4.6 Regression] -funsafe-loop-optimizations causes FAIL: gcc.c-torture/execute/pr27285.c execution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45122
--- Comment #16 from Zdenek Dvorak rakdver at gcc dot gnu.org 2011-02-01
11:27:13 UTC ---
(In reply to comment #15)
Ah, the reason why pr19210-* fail is that those loops have non-const/pure call
in it. So, while single_exit (loop) == exit, loop_only_exit_p (loop, exit)
still returns false.
So, the question is if we really need to give up on
-funsafe-loop-optimizations
whenever loop_only_exit_p (loop, exit), or if a single_exit (loop) == exit
test would be sufficient for that.
I believe single_exit (loop) test would sufficiently match the expectations of
-funsafe-loop-optimizations. This would misscompile code like
while (b)
{
foo(b);
b -= 8;
}
in the case that b is not divisible by 8, on the assumption that there are no
nontrivial infinite loops; which seems reasonable.
[Bug c++/47541] [4.5 Regression] For integer pointers, the value of ++*p is not written back to memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47541 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||4.5.3 Resolution||FIXED --- Comment #14 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-01 11:29:26 UTC --- Fixed.
[Bug tree-optimization/47555] [4.4/4.6 Regression] Huge memory usage when optimizing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47555 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||4.3.4, 4.5.1 Keywords||compile-time-hog, ||memory-hog Last reconfirmed||2011.02.01 11:29:35 CC||rguenth at gcc dot gnu.org, ||spop at gcc dot gnu.org Ever Confirmed|0 |1 Summary|Huge memory usage when |[4.4/4.6 Regression] Huge |optimizing |memory usage when ||optimizing Target Milestone|--- |4.4.6 Known to fail||4.4.5, 4.6.0 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-01 11:29:35 UTC --- GCC 4.5 uses around 800MB, most of the compile-time is spent in SCEV ccp, IVOPTs and VRP - which all hints at SCEV being the culprit. GCC 4.6 tops over 3GB which kills my machine, so does 4.4. 4.3, similar to 4.5 tops at around 1GB.
[Bug fortran/47569] [4.3/4.4/4.5/4.6 Regression] gfortran does not detect that the parameters for passing a partial string to a subroutine are incorrect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47569
--- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2011-02-01
11:33:33 UTC ---
A bit unrelated to the reported problem, but I wonder whether the
coarray/coindexed part is already correctly checked for:
If the actual argument is a coindexed scalar, the corresponding dummy argument
shall be scalar. If the actual argument is a noncoindexed scalar, the
corresponding dummy argument shall be scalar unless the actual argument
is default character, of type character with the C character kind (15.2.2), or
is an element or substring of an element of an array that is not an
assumed-shape, pointer, or polymorphic array. (F2008)
* * *
Draft patch:
diff --git a/gcc/fortran/interface.c b/gcc/fortran/interface.c
index 1e5df61..28daf8a 100644
--- a/gcc/fortran/interface.c
+++ b/gcc/fortran/interface.c
@@ -1672,7 +1672,7 @@ compare_parameter (gfc_symbol *formal, gfc_expr *actual,
return 1;
/* At this point, we are considering a scalar passed to an array. This
- is valid (cf. F95 12.4.1.1; F2003 12.4.1.2),
+ is valid (cf. F95 12.4.1.1 and F2008 12.5.2.4; F2003 12.4.1.2),
- if the actual argument is (a substring of) an element of a
non-assumed-shape/non-pointer array;
- (F2003) if the actual argument is of type character. */
@@ -1686,8 +1686,8 @@ compare_parameter (gfc_symbol *formal, gfc_expr *actual,
if (formal-ts.type == BT_CHARACTER
(ref == NULL
|| (actual-expr_type == EXPR_VARIABLE
- (actual-symtree-n.sym-as-type == AS_ASSUMED_SHAPE
- || actual-symtree-n.sym-attr.pointer
+ (ref-u.ar.as-type == AS_ASSUMED_SHAPE
+ || gfc_expr_attr (actual).pointer
{
if (where (gfc_option.allow_std GFC_STD_F2003) == 0)
{
[Bug middle-end/40979] induct benchmark 60% slower when compiled with -fgraphite-identity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40979 --- Comment #13 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-01 11:35:08 UTC --- It's unfortunate that graphite inserts arrays of size 1 instead of scalar (memory) vars. Otherwise update-address-taken would just re-write those into SSA after going out-of-graphite (if run, of course). It can probably be teached to rewrite single-element arrays into SSA form as well.
[Bug middle-end/40979] induct benchmark 60% slower when compiled with -fgraphite-identity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40979 --- Comment #14 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-01 11:45:44 UTC --- Noting that pass_graphite_transforms lacks any verifier calls, the following would enable the cleanup (in case scalar vars would have been used). Index: gcc/tree-ssa-loop.c === --- gcc/tree-ssa-loop.c (revision 169434) +++ gcc/tree-ssa-loop.c (working copy) @@ -314,7 +314,8 @@ struct gimple_opt_pass pass_graphite_tra 0, /* properties_provided */ 0, /* properties_destroyed */ 0, /* todo_flags_start */ - 0/* todo_flags_finish */ + TODO_update_address_taken + | TODO_dump_func /* todo_flags_finish */ } };
[Bug target/47564] internal compiler error in memory_address_addr_space, at explow.c:504
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47564 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-01 11:50:39 UTC --- Sounds similar to other reports that build on i?86 without -msse and a target attribute that enables some more SSE features. Try with -msse, if that works this is invalid (and a dup of PRxxx).
[Bug target/46692] Missing LM32 multilibs for divider and sign extender
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46692 --- Comment #3 from Sebastien Bourdeauducq lekernel at gcc dot gnu.org 2011-02-01 11:52:15 UTC --- Author: lekernel Date: Tue Feb 1 11:52:12 2011 New Revision: 169473 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=169473 Log: PR gcc/46692 * config/lm32/t-lm32: Add multilib for all CPU options. Modified: trunk/gcc/ChangeLog trunk/gcc/config/lm32/t-lm32
[Bug middle-end/47566] ICE in vn_reference_lookup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47566 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-01 11:53:09 UTC --- I think we need source code (LTO bytecode isn't really portable). It looks like that vuse is somehow bogus - mind posting the output of (gdb) call debug_tree (vuse) at that point?
[Bug target/46692] Missing LM32 multilibs for divider and sign extender
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46692 Sebastien Bourdeauducq sebastien.bourdeauducq at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #4 from Sebastien Bourdeauducq sebastien.bourdeauducq at gmail dot com 2011-02-01 12:01:12 UTC --- see comment #3
[Bug tree-optimization/47559] ICE: verify_stmts failed: statement marked for throw, but doesn't with -fnon-call-exceptions and noexcept
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47559
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
Status|UNCONFIRMED |NEW
Last reconfirmed||2011.02.01 12:03:49
CC||rakdver at gcc dot gnu.org
Component|middle-end |tree-optimization
Ever Confirmed|0 |1
--- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-01
12:03:49 UTC ---
LIM produces
void foo(int*) (int * k)
Eh tree:
1 must_not_throw
{
int k__lsm.1;
bb 2:
k__lsm.1_4 = MEM[(int *)k_1(D)];
bb 3:
[MNT 1] k__lsm.1_5 = 0;
bb 4:
goto bb 3;
}
failing to move the EH info. I think it should just give up here - it
tries to, but only if loop exits via EH edges appear - which is not
the case for must-not-throw. There is also no exit in that endless loop
anyway - which shows the transform isn't valid as if *k points to
readonly memory the testcase now will fail to trap as the store never
happens. Which means this is wrong-code as well (should we simply
not do store-motion for loops without exits?). Thus, the following
would fix the wrong-code issue (but probably not the ICE in a more
generalized test):
Index: gcc/tree-ssa-loop-im.c
===
--- gcc/tree-ssa-loop-im.c (revision 169434)
+++ gcc/tree-ssa-loop-im.c (working copy)
@@ -2368,6 +2368,9 @@ loop_suitable_for_sm (struct loop *loop
unsigned i;
edge ex;
+ if (VEC_empty (edge, exits))
+return false;
+
FOR_EACH_VEC_ELT (edge, exits, i, ex)
if (ex-flags (EDGE_ABNORMAL | EDGE_EH))
return false;
I am testing that change now.
[Bug middle-end/47566] ICE in vn_reference_lookup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47566 --- Comment #3 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-02-01 12:04:46 UTC --- (In reply to comment #2) I think we need source code (LTO bytecode isn't really portable). oops... that's building CP2K. Let me see if I can reproduce this with this night's tarball. (gdb) call debug_tree (vuse) at that point? (gdb) call debug_tree (vuse) var_decl 0x7532eb40 .MEM type void_type 0x77e84d20 void VOID align 8 symtab 0 alias set -1 structural equality pointer_to_this pointer_type 0x77e84dc8 used static external VOID file built-in line 0 col 0 align 8
[Bug middle-end/47566] ICE in vn_reference_lookup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47566 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-01 12:12:13 UTC --- (In reply to comment #3) (In reply to comment #2) I think we need source code (LTO bytecode isn't really portable). oops... that's building CP2K. Let me see if I can reproduce this with this night's tarball. (gdb) call debug_tree (vuse) at that point? (gdb) call debug_tree (vuse) var_decl 0x7532eb40 .MEM type void_type 0x77e84d20 void VOID align 8 symtab 0 alias set -1 structural equality pointer_to_this pointer_type 0x77e84dc8 used static external VOID file built-in line 0 col 0 align 8 That's indeed invalid - it should be an SSA name. This means some earlier pass messed up (or PRE itself). The bug shouldn't depend on LTO (apart from maybe requiring some cross-module inlining to trigger).
[Bug middle-end/47566] ICE in vn_reference_lookup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47566 --- Comment #5 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-02-01 12:23:35 UTC --- (In reply to comment #4) That's indeed invalid - it should be an SSA name. This means some earlier pass messed up (or PRE itself). The bug shouldn't depend on LTO (apart from maybe requiring some cross-module inlining to trigger). The same problem doesn't happen without LTO (but otherwise compiled with the same options). I guess it needs the cross-module inlining. I'll be uploading a tgz with sources.
[Bug middle-end/47566] ICE in vn_reference_lookup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47566 --- Comment #6 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-02-01 12:29:36 UTC --- to reproduce from sources wget http://www.pci.uzh.ch/vandevondele/tmp/cp2k.tgz tar -xzvf cp2k.tgz cd cp2k/makefiles make -j ARCH=gfortran-test24 VERSION=sopt this assumes that you have lapack and blas installed etc. The file cp2k/arch/gfortran-test24.sopt can be changed to modify compile options (or directories for lapack/blas). With make -j ARCH=gfortran-test24 VERSION=sopt distclean a new build can be started from scratch
[Bug target/47564] [4.6 Regression] internal compiler error in memory_address_addr_space, at explow.c:504
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47564 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Summary|internal compiler error in |[4.6 Regression] internal |memory_address_addr_space, |compiler error in |at explow.c:504 |memory_address_addr_space, ||at explow.c:504 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-01 12:32:51 UTC --- I get the ICE on x86_64-linux -m64 -O2 too, so that's not it. Started failing with http://gcc.gnu.org/viewcvs?root=gccview=revrev=167964
[Bug tree-optimization/47555] [4.4/4.6 Regression] Huge memory usage when optimizing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47555 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-01 12:53:41 UTC --- Program received signal SIGINT, Interrupt. tree_code_size (code=POLYNOMIAL_CHREC) at /space/rguenther/src/svn/trunk/gcc/tree.c:737 737 } (gdb) up #1 0x00c3d049 in make_node_stat (code=POLYNOMIAL_CHREC) at /space/rguenther/src/svn/trunk/gcc/tree.c:784 784 size_t length = tree_code_size (code); (gdb) bt #228 0x00ac555c in follow_ssa_edge_in_condition_phi ( loop=0x77edcdd0, condition_phi=0x75bea800, halting_phi=0x75bf3400, evolution_of_loop=0x7fffd708, limit=0) at /space/rguenther/src/svn/trunk/gcc/tree-scalar-evolution.c:1310 #229 0x00ac5a94 in follow_ssa_edge (loop=0x77edcdd0, def=0x75bea800, halting_phi=0x75bf3400, evolution_of_loop=0x7fffd708, limit=0) at /space/rguenther/src/svn/trunk/gcc/tree-scalar-evolution.c:1415 #230 0x00ac5cd1 in analyze_evolution_in_loop ( loop_phi_node=0x75bf3400, init_cond=0x75bf2948) at /space/rguenther/src/svn/trunk/gcc/tree-scalar-evolution.c:1492 #231 0x00ac6108 in interpret_loop_phi (loop=0x77edcdd0, loop_phi_node=0x75bf3400) at /space/rguenther/src/svn/trunk/gcc/tree-scalar-evolution.c:1631 #232 0x00ac7403 in analyze_scalar_evolution_1 (loop=0x77edcdd0, var=0x75a329a0, res=0x0) at /space/rguenther/src/svn/trunk/gcc/tree-scalar-evolution.c:1905 #233 0x00ac754f in analyze_scalar_evolution (loop=0x77edcdd0, var=0x75a329a0) at /space/rguenther/src/svn/trunk/gcc/tree-scalar-evolution.c:1955 ---Type return to continue, or q return to quit--- #234 0x00acbf0f in scev_const_prop () so we again run into exponential expression building in SCEV. The limit we set is 100 which means we allow 2^100 as expression size. That's quite useless (the limit was recently bumped from 20 we have on the 4.5 branch). PHI handling is also odd as we recurse with variable increases instead of with a constant one. I'm going to revert the parm change - its documentation also doesn't match the behavior of the parm, expression growth is at most limited to be O(2^parm), there is no real limit on the expression size.
[Bug fortran/47565] [4.6 Regression][OOP] Segfault with TBP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47565
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2011.02.01 13:00:47
Ever Confirmed|0 |1
--- Comment #1 from janus at gcc dot gnu.org 2011-02-01 13:00:47 UTC ---
Modified test case:
module class_t
contains
function find_y() result(res)
integer, allocatable :: res
print *,find_y
allocate(res)
end function
end module
program p
use class_t
type :: t
procedure(find_y), pointer, nopass :: ppc
contains
procedure, nopass :: find_y
end type
class(t), allocatable :: this
integer :: y
allocate(this)
this%ppc = find_y
! (1) ordinary procedure (works)
y = find_y()
print *, y
! (2) procedure pointer component (works)
y = this%ppc()
print *, y
! (3) type-bound procedure (fails)
y = this%find_y() ! segfault at run time
print *, y
end
This shows that the PPC call also works nicely, while the TBP does not.
The dump for all three calls looks ok:
y = *find_y ();
y = *this._data-ppc ();
y = *this._vptr-find_y ();
The problem seems to be that the initialization for the TBP is missing in the
vtab:
static struct __vtype_p_T __vtab_p_T = {._hash=31520549, ._size=8,
._extends=0B, ._def_init=__def_init_p_T, ._copy=__copy_p_T};
When removing the allocatable attribute of 'find_y', one correctly gets:
static struct __vtype_p_T __vtab_p_T = {._hash=31520549, ._size=8,
._extends=0B, ._def_init=__def_init_p_T, ._copy=__copy_p_T, .find_y=find_y};
[Bug java/47456] internal compiler error: Segmentation fault while using jna
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47456 --- Comment #11 from steve.reinke at iws dot fraunhofer.de 2011-02-01 13:14:23 UTC --- Hi, I din't found a gcj version 4.5 build for windows. That's why I tried to use this version. Do you know where I can get anywhere such a windows build? Regards Steve Reinke -Ursprüngliche Nachricht- Von: mikpe at it dot uu.se [mailto:gcc-bugzi...@gcc.gnu.org] Gesendet: Dienstag, 1. Februar 2011 10:40 An: Reinke, Steve Betreff: [Bug java/47456] internal compiler error: Segmentation fault while using jna http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47456 --- Comment #10 from Mikael Pettersson mikpe at it dot uu.se 2011-02-01 09:40:18 UTC --- Your test case requires using binaries without sources on Win32. You can: 1. Try a newer gcc, preferably 4.5.2. Your pre-4.3.0 development snapshot is ancient and likely to contain bugs which have since been fixed. 2. Supply a test case in source form. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You reported the bug.
[Bug target/47558] 163267 breaks exception traceback in xplor-nih
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558 --- Comment #10 from Iain Sandoe iains at gcc dot gnu.org 2011-02-01 13:25:31 UTC --- two more minor points. 1/ the trunk lib specs do the same as gcc-4.2.1(apple local) 2/ there are no exported symbols for 10.6 in /usr/lib/libgcc_s.10.5.dylib (they are all $add$os10.4 or 10.5) so, you might ask the question why does changing that spec make *any* difference ? (it should only be an improvement in efficiency, no change in symbols). .. debugging that will probably get you to the answer to where the real problem lies.
[Bug fortran/47565] [4.6 Regression][OOP] Segfault with TBP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47565 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org |gnu.org | --- Comment #2 from janus at gcc dot gnu.org 2011-02-01 13:39:31 UTC --- Here is the obvious fix: Index: trans-expr.c === --- trans-expr.c(revision 169470) +++ trans-expr.c(working copy) @@ -4627,7 +4627,7 @@ gfc_conv_structure (gfc_se * se, gfc_expr * expr, components. Although the latter have a default initializer of EXPR_NULL,... by default, the static nullify is not needed since this is done every time we come into scope. */ - if (!c-expr || cm-attr.allocatable) + if (!c-expr || (cm-attr.allocatable cm-attr.flavor != FL_PROCEDURE)) continue; if (strcmp (cm-name, _size) == 0) Will commit after regtesting.
[Bug tree-optimization/47555] [4.4/4.6 Regression] Huge memory usage when optimizing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47555 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-01 13:41:25 UTC --- With --param scev-max-expr-size=20 (the 4.5 default) trunk uses 300MB ram, with 21 it uses 580MB with 22 1.2GB, with 23 2.2GB, ... so it indeed grows exponential (as designed). Bumping from 20 to 100 is thus definitely unreasonable ;)
[Bug target/35926] Pushing / Poping ebx without using it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35926 Tony Poppleton tony.poppleton at gmail dot com changed: What|Removed |Added Last reconfirmed|2008-12-28 06:57:47 |2011-02-01 13:13 Known to fail||4.1.2, 4.3.5, 4.4.5, 4.5.2, ||4.6.0 Severity|normal |enhancement --- Comment #7 from Tony Poppleton tony.poppleton at gmail dot com 2011-02-01 13:44:28 UTC --- Set known to fail field, last reconfirmed field, and modified to enhancement
[Bug libfortran/47567] Wrong output for small absolute values with F editing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47567 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.02.01 13:48:33 AssignedTo|unassigned at gcc dot |jvdelisle at gcc dot |gnu.org |gnu.org Ever Confirmed|0 |1 --- Comment #2 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2011-02-01 13:48:33 UTC --- On it.
[Bug target/47558] 163267 breaks exception traceback in xplor-nih
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558 --- Comment #11 from Jack Howarth howarth at nitro dot med.uc.edu 2011-02-01 13:51:52 UTC --- Created attachment 23195 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23195 build log for xplor-nih 2.2.7 under gcc trunk
[Bug target/47558] 163267 breaks exception traceback in xplor-nih
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558 --- Comment #12 from Jack Howarth howarth at nitro dot med.uc.edu 2011-02-01 13:53:18 UTC --- Created attachment 23196 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23196 otool -L output for xplor-nih binaries
[Bug target/47558] 163267 breaks exception traceback in xplor-nih
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558 --- Comment #13 from Jack Howarth howarth at nitro dot med.uc.edu 2011-02-01 13:56:18 UTC --- It was be true for the simple case that the reduced linkage is fine but somehow the xplor-nih building is exposing a corner case we haven't thought of. I have uploaded a full build log for xplor-nih which was created with... cd xplor-nih-2.27 set path= ( '/Users/howarth/dist/bin' $path ) make and the compilers show up as... [frodo:~/xplor-nih-2.27] howarth% gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/Users/howarth/dist/libexec/gcc/x86_64-apple-darwin10.6.0/4.6.0/lto-wrapper Target: x86_64-apple-darwin10.6.0 Configured with: ../gcc/configure --enable-checking=release --prefix=/Users/howarth/dist --with-gmp=/sw --with-ppl=/sw --with-cloog=/sw --with-mpc=/sw --with-libiconv-prefix=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --enable-languages=c,c++,fortran --enable-cloog-backend=legacy Thread model: posix gcc version 4.6.0 20110201 (experimental) (GCC) [frodo:~/xplor-nih-2.27] howarth% g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/Users/howarth/dist/libexec/gcc/x86_64-apple-darwin10.6.0/4.6.0/lto-wrapper Target: x86_64-apple-darwin10.6.0 Configured with: ../gcc/configure --enable-checking=release --prefix=/Users/howarth/dist --with-gmp=/sw --with-ppl=/sw --with-cloog=/sw --with-mpc=/sw --with-libiconv-prefix=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --enable-languages=c,c++,fortran --enable-cloog-backend=legacy Thread model: posix gcc version 4.6.0 20110201 (experimental) (GCC) [frodo:~/xplor-nih-2.27] howarth% gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/Users/howarth/dist/libexec/gcc/x86_64-apple-darwin10.6.0/4.6.0/lto-wrapper Target: x86_64-apple-darwin10.6.0 Configured with: ../gcc/configure --enable-checking=release --prefix=/Users/howarth/dist --with-gmp=/sw --with-ppl=/sw --with-cloog=/sw --with-mpc=/sw --with-libiconv-prefix=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --enable-languages=c,c++,fortran --enable-cloog-backend=legacy Thread model: posix gcc version 4.6.0 20110201 (experimental) (GCC)
[Bug java/47456] internal compiler error: Segmentation fault while using jna
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47456 --- Comment #12 from Mikael Pettersson mikpe at it dot uu.se 2011-02-01 14:12:12 UTC --- (In reply to comment #11) Hi, I din't found a gcj version 4.5 build for windows. That's why I tried to use this version. Do you know where I can get anywhere such a windows build? (please don't top-post) Looks like mingw supplies prebuilt binaries, including java: http://www.mingw.org/wiki/Getting_Started
[Bug target/47564] [4.6 Regression] internal compiler error in memory_address_addr_space, at explow.c:504
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47564 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.02.01 14:18:55 Target Milestone|--- |4.6.0 Ever Confirmed|0 |1
[Bug fortran/47571] New: undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 Summary: undefined reference to clock_gettime in Linux build of 02/01/2011 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: michael.a.richm...@nasa.gov Host: i686-pc-linux-gnu Target: i686-pc-linux-gnu Build: i686-pc-linux-gnu When I compile the following program: PROGRAM call_date_and_time CHARACTER(LEN=8) date CHARACTER(LEN=10) time CALL DATE_AND_TIME(date, time) END PROGRAM call_date_and_time I get the message: /home/mrichmon/usr/local/gfortran/bin/../lib/gcc/i686-pc-linux-gnu/4.6.0/../../../libgfortran.a(date_and_time.o): In function `gf_gettime': /home/jerry/gcc/trunk/libgfortran/intrinsics/time_1.h:211: undefined reference to `clock_gettime' collect2: ld returned 1 exit status This bug is specific to the following build: http://gfortran.org/download/i686/gfortran-4.6-20110201-linux-i686.tar.gz Is it due to Patch 81226?
[Bug java/47456] internal compiler error: Segmentation fault while using jna
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47456 --- Comment #13 from steve.reinke at iws dot fraunhofer.de 2011-02-01 14:28:43 UTC --- Created attachment 23197 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23197 the src file for the jar
[Bug fortran/47572] New: [OOP] Invalid: Allocatable polymorphic with init expression.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47572 Summary: [OOP] Invalid: Allocatable polymorphic with init expression. Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: accepts-invalid Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org CC: ja...@gcc.gnu.org Found at http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/763785b16883ed68 The program looks very odd and surely is wrong; however, gfortran accepts it. ifort does: error #6562: A data initialization-expr is not valid for this object. [B] I assume that one checks against the CLASS container and not against the actual _data object. C506 (R503) An initialization shall not appear if object-name is a dummy argument, a function result, an object in a named common block unless the type declaration is in a block data program unit, an object in blank common, an allocatable variable, or an automatic object. (F2008) program scalarallocation type test real :: a end type class (test), allocatable :: b = test(3.4) print *,'B', allocated(b) end program
[Bug tree-optimization/47555] [4.4/4.6 Regression] Huge memory usage when optimizing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47555 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-01 14:36:04 UTC --- Author: rguenth Date: Tue Feb 1 14:36:00 2011 New Revision: 169478 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=169478 Log: 2011-02-01 Richard Guenther rguent...@suse.de PR tree-optimization/47555 Revert 2010-07-15 Sebastian Pop sebastian@amd.com * params.def (PARAM_SCEV_MAX_EXPR_SIZE): Bump the value to 100. * gcc.dg/pr47555.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr47555.c Modified: trunk/gcc/ChangeLog trunk/gcc/params.def trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/47555] [4.4 Regression] Huge memory usage when optimizing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47555 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||4.6.0 Summary|[4.4/4.6 Regression] Huge |[4.4 Regression] Huge |memory usage when |memory usage when |optimizing |optimizing Known to fail|4.6.0 | --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-01 14:36:41 UTC --- Re-fixed on trunk. Eventually this is now a dup of an existing bug.
[Bug target/47558] 163267 breaks exception traceback in xplor-nih
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558 --- Comment #14 from Iain Sandoe iains at gcc dot gnu.org 2011-02-01 14:37:39 UTC --- the difference caused by including a reference to /usr/libgcc_s.xxx is to allow a libgcc_s appearing in a DYLD_LIBRARY_PATH (or a fallback path in the compiler's list) to over-ride ... have you (or does the build process) set a DYLD_LIBRARY_PATH ? another possibility is a corrupted, stale or erroneous build of one of those libraries that refers to _Unwind_ in FSF libgcc_s.1.dylib (how it manages that would bear some inspection). I've checked recent trunk for 10.6 and (a) libgcc_ext.dylib does NOT export _Unwind_x (b) /usr/libgcc_s.10.5.dylib is just a stub pointing to libSystem.dylib. so if you've manage to resolve _Unwind_ from FSF libgcc_s then the two top choices are: either there is a dodgy -L in the build process or you've got a DYLD_LIBRARY_PATH somewhere ...
[Bug target/47564] [4.6 Regression] internal compiler error in memory_address_addr_space, at explow.c:504
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47564 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-01 14:40:50 UTC --- Created attachment 23198 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23198 gcc46-pr47564.patch Ugh, this is ugly. The problem is that tree_rest_of_compilation calls init_emit and lots of other init* functions and assumes x_rtl will stay initialized until expansion. But if during any of the following optimization passes set_cfun is called to some other function which has different target options, target_reinit is called, which calls free_after_compilation which will clear x_rtl. Among other things it clears reg_rtx_no, which means when expanding E pseudo allocation starts from 0 instead of first pseudo (i.e. allocates various hard/virtual registers first, which of course can't lead to anything sane). Most of the set_cfun calls actually came from cgraph verification, where it is not really needed - IMHO we can set_cfun there just when we are about to diagnose an issue and when we do that, we will internal_error at the end of function anyway and thus don't have to worry about restoring it at all. The attached patch fixes that. On the testcase there is another set_cfun call after tree_rest_of_compilation has been called though, in particular from cgraph_release_function_body during inlining (called from cgraph_release_node). I guess in such a case we don't actually need target reinit, perhaps we could just change cfun after saving the previous value, instead of using push_cfun/pop_cfun. Or perhaps target_reinit could save x_rtl copy before it and restore it afterwards, so that it doesn't clear it if it wasn't all 0's before.
[Bug c++/47573] New: [trans-mem] ICE in invoke_set_current_function_hook
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47573 Summary: [trans-mem] ICE in invoke_set_current_function_hook Product: gcc Version: trans-mem Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: patrick.marl...@gmail.com CC: r...@gcc.gnu.org, al...@gcc.gnu.org Created attachment 23199 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23199 testcase boom The attached test case makes GCC crashed (with latest revision 169442). $ g++ -fgnu-tm -O0 -S testcase.i testcase.i:22: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. Program received signal SIGSEGV, Segmentation fault. invoke_set_current_function_hook (fndecl=0xa5a5a5a5a5a5a5a5) at ../../transactional-memory/gcc/function.c:4039 4039 ? DECL_FUNCTION_SPECIFIC_OPTIMIZATION (fndecl) (gdb) bt #0 invoke_set_current_function_hook (fndecl=0xa5a5a5a5a5a5a5a5) at ../../transactional-memory/gcc/function.c:4039 #1 0x00aca463 in verify_cgraph_node (node=0x76bbdc30) at ../../transactional-memory/gcc/cgraphunit.c:581 #2 0x00acadd8 in verify_cgraph () at ../../transactional-memory/gcc/cgraphunit.c:812 #3 0x00aee65b in cgraph_remove_unreachable_nodes (before_inlining_p=1 '\001', file=0x0) at ../../transactional-memory/gcc/ipa.c:306 #4 0x008427ee in execute_todo (flags=384) at ../../transactional-memory/gcc/passes.c:1307 #5 0x00844e5a in execute_one_pass (pass=0x132f6c0) at ../../transactional-memory/gcc/passes.c:1602 #6 0x0084525a in execute_ipa_pass_list (pass=0x132f6c0) at ../../transactional-memory/gcc/passes.c:1813 #7 0x00acd5a7 in ipa_passes () at ../../transactional-memory/gcc/cgraphunit.c:1796 #8 cgraph_optimize () at ../../transactional-memory/gcc/cgraphunit.c:1831 #9 0x00acdf35 in cgraph_finalize_compilation_unit () at ../../transactional-memory/gcc/cgraphunit.c:1096 #10 0x005393cb in cp_write_global_declarations () at ../../transactional-memory/gcc/cp/decl2.c:3837 #11 0x008ea23a in compile_file (argc=15, argv=0x7fffe4c8) at ../../transactional-memory/gcc/toplev.c:1065 #12 do_compile (argc=15, argv=0x7fffe4c8) at ../../transactional-memory/gcc/toplev.c:2424 #13 toplev_main (argc=15, argv=0x7fffe4c8) at ../../transactional-memory/gcc/toplev.c:2466 #14 0x76f95d8e in __libc_start_main (main=value optimized out, argc=value optimized out, ubp_av=value optimized out, init=value optimized out, fini=value optimized out, rtld_fini=value optimized out, stack_end=0x7fffe4b8) at libc-start.c:226 #15 0x00489089 in _start ()
[Bug driver/47547] [4.5/4.6 Regression] WHOPR, can't use /dev/null as an output file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47547 --- Comment #5 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2011-02-01 14:42:16 UTC --- Author: hjl Date: Tue Feb 1 14:42:08 2011 New Revision: 169479 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=169479 Log: Check HOST_BIT_BUCKET when settting dump base/dir. 2011-02-01 H.J. Lu hongjiu...@intel.com PR driver/47547 * lto-wrapper.c (run_gcc): Don't add -dumpdir if linker_output is HOST_BIT_BUCKET. * opts.c (finish_options): Don't add x_aux_base_name if it is HOST_BIT_BUCKET. Modified: trunk/gcc/ChangeLog trunk/gcc/lto-wrapper.c trunk/gcc/opts.c
[Bug driver/47547] [4.5 Regression] WHOPR, can't use /dev/null as an output file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47547 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Target Milestone|4.6.0 |4.5.3 Summary|[4.5/4.6 Regression] WHOPR, |[4.5 Regression] WHOPR, |can't use /dev/null as an |can't use /dev/null as an |output file |output file --- Comment #6 from H.J. Lu hjl.tools at gmail dot com 2011-02-01 14:43:48 UTC --- Fixed on trunk.
[Bug tree-optimization/47555] [4.4 Regression] Huge memory usage when optimizing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47555 --- Comment #6 from Tony Poppleton tony.poppleton at gmail dot com 2011-02-01 14:45:28 UTC --- Out of interest, could this parameter of 20 be automatically tuned based on the available RAM? For systems with a lot of RAM, it might make sense to increase the parameter above 20 (assuming this produces better code in the end). Whilst they could override this using the flag mentioned in comment #3, auto-detecting this parameter would make it easier for the end user.
[Bug middle-end/47566] ICE in vn_reference_lookup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47566 --- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-01 14:46:56 UTC --- Hm, you are using -O0 for the compile and -O3 ... for the link step? Should work in theory, but of course isn't tested thoroughly.
[Bug tree-optimization/47555] [4.4 Regression] Huge memory usage when optimizing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47555 --- Comment #7 from rguenther at suse dot de rguenther at suse dot de 2011-02-01 14:48:15 UTC --- On Tue, 1 Feb 2011, tony.poppleton at gmail dot com wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47555 --- Comment #6 from Tony Poppleton tony.poppleton at gmail dot com 2011-02-01 14:45:28 UTC --- Out of interest, could this parameter of 20 be automatically tuned based on the available RAM? For systems with a lot of RAM, it might make sense to increase the parameter above 20 (assuming this produces better code in the end). Whilst they could override this using the flag mentioned in comment #3, auto-detecting this parameter would make it easier for the end user. We try very hard to not have generated code depend on host machine configuration. So, no.
[Bug middle-end/47566] ICE in vn_reference_lookup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47566 --- Comment #8 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-02-01 14:53:44 UTC --- (In reply to comment #7) Hm, you are using -O0 for the compile and -O3 ... for the link step? Should work in theory, but of course isn't tested thoroughly. Right :-) I'm trying to test this thoroughly... seems like a useful trick to speedup parallel builds of Fortran programs (quick -O0 build to satisfy module dependencies, massively parallel and thus hopefully fast lto without the dependencies).
[Bug fortran/47569] [4.3/4.4/4.5/4.6 Regression] gfortran does not detect that the parameters for passing a partial string to a subroutine are incorrect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47569 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2011-02-01 14:54:10 UTC --- (In reply to comment #2) Draft patch: + || gfc_expr_attr (actual).pointer That check won't work as foo(1) is never a pointer while foo might be a pointer; thus, one has to save the last REF_COMPONENT and handle it manually. The following check at a few lines later also needs to be modified (both the AS_ASSUMED and the pointer check). if (actual-expr_type == EXPR_VARIABLE ref (ref-u.ar.as-type == AS_ASSUMED_SHAPE || gfc_expr_attr (actual).pointer)) And the check: for (ref = actual-ref; ref; ref = ref-next) if (ref-type == REF_ARRAY ref-u.ar.type == AR_ELEMENT ref-u.ar.dimen 0) break; seems to mishandle foo(1)%bar(1)%foo by looking only at the first AR_ELEMENT.
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code CC||burnus at gcc dot gnu.org, ||jb at gcc dot gnu.org Summary|undefined reference to |[4.6 Regression] undefined |clock_gettime in Linux |reference to clock_gettime |build of 02/01/2011 |in Linux build of ||02/01/2011 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2011-02-01 14:56:30 UTC --- clock_gettime is part of POSIX. Linux's man page states: Feature Test Macro Requirements for glibc _POSIX_C_SOURCE = 199309L
[Bug fortran/47565] [4.6 Regression][OOP] Segfault with TBP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47565 --- Comment #3 from janus at gcc dot gnu.org 2011-02-01 14:59:45 UTC --- Author: janus Date: Tue Feb 1 14:59:40 2011 New Revision: 169480 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=169480 Log: 2011-02-01 Janus Weil ja...@gcc.gnu.org PR fortran/47565 * trans-expr.c (gfc_conv_structure): Handle constructors for procedure pointer components with allocatable result. 2011-02-01 Janus Weil ja...@gcc.gnu.org PR fortran/47565 * gfortran.dg/typebound_call_20.f03: New. Added: trunk/gcc/testsuite/gfortran.dg/typebound_call_20.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/47565] [4.6 Regression][OOP] Segfault with TBP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47565 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from janus at gcc dot gnu.org 2011-02-01 15:01:22 UTC --- Fixed with r169480. Closing.
[Bug c++/47568] Name lookup: different behavior 4.1.2 / 4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47568 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-02-01 15:07:06 UTC --- it was a bug, it's fixed now 4.1 is no longer maintained
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 --- Comment #2 from Janne Blomqvist jb at gcc dot gnu.org 2011-02-01 15:08:13 UTC --- On Linux/Glibc libgfortran is built with _GNU_SOURCE, which according to the glibc manual is a superset of all kinds of _POSIX_C_SOURCE=[latest_supported_standard] XOPEN_SOURCE=[latest_supported_standard] and so forth. My guess is that the issue is due to mismatch between the build environment and the environment where gfortran is executed. It might be that the OP is running on some old distro that doesn't provide librt.so which is needed by clock_gettime() on Glibc. OP, what does ldd /path/to/libgfortran.so.3 say? FWIW, I have no idea what Patch 81226 refers to.
[Bug target/47558] 163267 breaks exception traceback in xplor-nih
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558 --- Comment #15 from Jack Howarth howarth at nitro dot med.uc.edu 2011-02-01 15:11:51 UTC --- DYLD_LIBRARY_PATH is unset when xplor is started. Also remember that your test case in comment 9 is insufficient to reproduce the behavior of xplor-nih. The code calling the unwinder should be placed in a shared library and then called from a main program. I don't see anything in the following linkages which should cause a problem. gcc -fdefault-integer-8 -dynamiclib -o libfft.dylib dsint.o dsinti.o dcfftf.o dcfftb.o dcffti.o drffti.o drfftf.o drfftb.o zffti.o zfftf.o zfftb.o ctrans.o zfft1d.o zfft2d.o zfft3d.o ftrans.o zmp_fft.o zscal_fft.o zprod_fft.o fft_ftn.o -flat_namespace -undefined suppress -single_module-lcrypto -lblas gcc -fdefault-integer-8 -dynamiclib -o libpppack.dylib cubspl.o ppvalu.o intdy.o xerrwv.o -flat_namespace -undefined suppress -single_module-lcrypto gcc -fdefault-integer-8 -dynamiclib -o libspecfun.dylib gamma.o rjbesl.o ribesl.o -flat_namespace -undefined suppress -single_module-lcrypto g++ -dynamiclib -fdefault-integer-8 -flat_namespace -undefined suppress -single_module dpApi.o vmd.o vmdInter.o tclStream.o dpStream.o ssStream.o publicVMDInter.o thread.o -o libvmd.dylib-lcrypto g++ -dynamiclib -fdefault-integer-8 -flat_namespace -undefined suppress -single_module dinternal.o dint-atom.o dint-node.o dint-loop.o dint-step.o dint-powell.o dint-conmin.o dint-simplex.o dint-pc6.o dint-xplor.o publicIVM.o -o libintVar.dylib-lcrypto -L/Users/howarth/xplor-nih-2.27/bin.Darwin_10_x86_64/ -llapack -lblas g++ -dynamiclib -fdefault-integer-8 -flat_namespace -undefined suppress -single_module maketables.o get.o study.o pcre.o -o libpcre.dylib-lcrypto g++ -dynamiclib -fdefault-integer-8 -flat_namespace -undefined suppress -single_module simulation.o xplorSimulation.o xplorWrap.o atom.o atomSel.o atomSelAction.o derivList.o pdbTool.o ensembleSimulation.o simulationWorld.o xplorPot.o mmapAlloc.o semaphore.o mutex-sem.o randomNum.o potList.o avePot.o modified.o enumNameMap.o dihedral.o ensemblePot.o xplorWrapProc.o coordComparer.o atomSelLang.o atomSelLangYacc.o mmapMalloc.o -o libcommon.dylib -lcrypto -L/Users/howarth/xplor-nih-2.27/bin.Darwin_10_x86_64/ -lpcre -llapack -lblas g++ -dynamiclib -fdefault-integer-8 -flat_namespace -undefined suppress -single_module surf.o io.o compute.o dual.o utils.o lp.o chull.o tessel_cases.o tessel_patches.o tessel_convex.o tessel_concave.o tessel_torus.o surfDiff.o -o libsurfD.dylib-lcrypto -L/Users/howarth/xplor-nih-2.27/bin.Darwin_10_x86_64/ -lspecfun -llapack -lblas g++ -dynamiclib -fdefault-integer-8 -flat_namespace -undefined suppress -single_module noePot.o atomProb.o rdcPot1.o csaPot.o jCoupPot.o shapePot.o atomDensity.o probDistPot.o cosRatioPot.o ncsPot.o prePot.o rdcWavePot.o varTensor.o surfaceArea.o psolPot.o orderPot.o posRMSDPot.o utils.o posSymmPot.o sphereFun.o volume.o planeDistPot.o selNBPot.o gyrPot.o cstMagPot.o diffPot.o relaxRatioPot.o distSymmPot.o sardcPot.o surfTessellation.o torsionDBPot.o nbTargetPot.o solnScatPot.o -o libnmrPot.dylib-lcrypto -L/Users/howarth/xplor-nih-2.27/bin.Darwin_10_x86_64/ -lspecfun -lsurfD -llapack -lblas g++ -dynamiclib -fdefault-integer-8 -flat_namespace -undefined suppress -single_module PeakAssignment.o Peak.o MarvinNOEPotential.o ShiftAssignment.o EquivPeakAssignmentSet.o -o libmarvin.dylib-lcrypto gcc -fdefault-integer-8 -dynamiclib -o libxplor.dylib xfft.o xdofft.o dtorsion.o rotman.o array.o genic.o prot.o tsearch.o xmwrite.o carb.o csa.o geomty.o psfio.o update.o xparse.o hbonds.o usersb.o xpeakpik.o corman.o hbuild.o rotate.o util.o coup.o initia.o rotlsq.o vcorr.o xpred.o cstack.o intcor.o vcorrfft.o xprobab.o cstran.o matrix.o rsearch.o vector.o xprox.o distan.o mmdisg.o rtfio.o xasymm.o xreduce.o drigid.o modes.o rxconv.o xdeclare.o xrefin.o mrigid.o rxprin.o xdo.o xrmani.o dynamc.o nbonds.o rxrefi.o xropti.o dynanl.o ncs.o rxsetu.o xdofried.o xscale.o noe.o sbound.o xdohelp.o xsfsele.o dynlng.o onebond.o segmnt.o xfalgebra.o xshow.o eangle.o packing.o selrpn.o xsigmaa.o ebond.o parmio.o parser.o xmalgebra.o xskel.o enbond.o shake.o xmask.o xstats.o energy.o pick.o sort.o xmaverage.o xsymm.o etor.o plane.o string.o xmphisto.o xtarget.o expression.o powell.o surfac.o xmpsele.o fastnb.o power.o test.o xmread.o collapse_rgyr.o xrama.o trio_faster_newderiv.o susc_anis.o rama_gaussians.o orientations.o xdipolar_coup.o diff_anis.o anisotropy.o angledb.o vectangl.o fantacross.o fantalin.o xangle.o xccr.o xfantaccr.o xfantadipo.o xdipo_pcs.o xdipo_rdc.o xt1dist.o hbdb.o saxs.o pcsa.o ss_orient.o xadc.o hb_dist_angle.o aria.o ariman.o ariass.o aribac.o arical.o arivio.o bonded.o ace.o pmag.o tens_dip_e2.o tenso.o slink.o fxrefin.o fxparse.o fwrite.o pxrefin.o pxtarget.o fxmap.o pxparse.o pxmani.o xmap.o zpacking.o ppacking.o fenergy.o sebond.o seangl.o setor.o darwin64time.o osx_x86_64.o -flat_namespace
[Bug c++/47568] Name lookup: different behavior 4.1.2 / 4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47568 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Known to work||4.4.5 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-02-01 15:12:20 UTC --- in case that wasn't clear, it was a bug in 4.1, it's fixed in 4.4 (maybe earlier, I didn't check)
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-01 15:14:14 UTC --- clock_gettime is defined in librt, so if libgfortran started using librt symbols, it needs to a) link against it dynamically for libgfortran.so b) arrange for gfortran driver to pass in -lrt when linking libgfortran statically.
[Bug fortran/47569] [4.3/4.4/4.5/4.6 Regression] gfortran does not detect that the parameters for passing a partial string to a subroutine are incorrect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47569 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |4.5.3
[Bug c++/47568] Name lookup: different behavior 4.1.2 / 4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47568 --- Comment #3 from Matwey V. Kornilov matwey.kornilov at gmail dot com 2011-02-01 15:24:30 UTC --- Thanks. What is its bugid? I didn't find something similar and then I filled this ticket. Probably I looked through not careful enough.
[Bug target/47558] 163267 breaks exception traceback in xplor-nih
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558 --- Comment #16 from Iain Sandoe iains at gcc dot gnu.org 2011-02-01 15:26:15 UTC --- (In reply to comment #15) Perhaps r163267 is fragile to certain combination of linker flags (like -flat_namespace)? fragile LOL... man ld: -flat_namespace Alters how symbols are resolved at build time and runtime. With -two_levelnamespace (the default), the linker only searches dylibs on the command line for symbols, and records in which dylib they were found. With -flat_namespace, the linker searches all dylibs on the command line and all dylibs those original dylibs depend on. The linker does not record which dylib an external symbol came from, so at runtime dyld again searches all images and uses the first definition it finds. In addition, any undefines in loaded flat_namespace dylibs must be resolvable at build time. -- you are defeating the mechanism that is used to supply the _ext symbols from a different library. If use if this flag is, actually, necessary then we need to alter the whole mechanism for the _ext to build a distinctly named lib.
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 --- Comment #4 from Michael Richmond michael.a.richmond at nasa dot gov 2011-02-01 15:27:19 UTC --- (In reply to comment #2) OP, what does ldd /path/to/libgfortran.so.3 say? linux-gate.so.1 = (0xe000) libm.so.6 = /lib/libm.so.6 (0xb772b000) libc.so.6 = /lib/libc.so.6 (0xb75c) /lib/ld-linux.so.2 (0xb7822000) I am running SuSE Linux 11.3
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2011-02-01 15:29:50 UTC --- For the symbols defined in librt, cf. http://refspecs.freestandards.org/LSB_4.0.0/LSB-Core-generic/LSB-Core-generic/librt.html Regarding http://gcc.gnu.org/ml/fortran/2011-01/msg00326.html 2) Uses clock_gettime() if available and (In reply to comment #3) clock_gettime is defined in librt, so if libgfortran started using librt symbols It probably means that one needs to use libgfortran.spec for that as f951 has no knowledge whether clock_gettime is available. Is is clear that librt exists if clock_gettime is available? librt seems to be a Linux-specific library-name choice. If not, one could consider moving back to a clock_gettime-free libgfortran.
[Bug middle-end/47566] ICE in vn_reference_lookup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47566
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2011.02.01 15:36:11
AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #9 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-01
15:36:11 UTC ---
I can reproduce it. I also run into
In file included from :425:0:
/tmp/cp2k/makefiles/../src/realspace_grid_types.F: In function
'rs_pw_transfer_replicated':
/tmp/cp2k/makefiles/../src/realspace_grid_types.F:816:0: error: non-trivial
conversion at assignment
struct array3_real(kind=8)
struct array3_real(kind=8)
# .MEM_755 = VDEF .MEM_649
grid = D.39399_277-r;
and a couple of similar ICEs in other ltrans units. Probably the known
restrict vs. non-restrict bug.
The bug happens when optimizing fft3d_pb, it also happens with -fno-inline
so indeed the bug might be triggered by the mix of -O0 and -O3 (thus, by
not running early optimizations).
Seems to be -ffast-math vs. non-fast-math. We fold calls during
PRE insertion which turns cabs into components (complex lowering).
That folding,
folded = build_call_array (currop-type,
(TREE_CODE (fn) == FUNCTION_DECL
? build_fold_addr_expr (fn) : fn),
nargs, args);
can create arbitrary number of expressions, including for some reason
non-gimple reg vars. In particular fold_builtin_cabs returns
__builtin_sqrt (__builtin_pow (SAVE_EXPR REALPART_EXPR SAVE_EXPR
val.767_1280, 2.0e+0) + __builtin_pow (SAVE_EXPR IMAGPART_EXPR SAVE_EXPR
val.767_1280, 2.0e+0))
and then save-expr gimplification introduces the non-register temporary
as a result of SSA_NAME save-expr (which is unnecessary anyway).
The following fixes the ICE for me:
Index: builtins.c
===
--- builtins.c (revision 169476)
+++ builtins.c (working copy)
@@ -652,9 +652,10 @@ target_char_cast (tree cst, char *p)
static tree
builtin_save_expr (tree exp)
{
- if (TREE_ADDRESSABLE (exp) == 0
- (TREE_CODE (exp) == PARM_DECL
- || (TREE_CODE (exp) == VAR_DECL !TREE_STATIC (exp
+ if (TREE_CODE (exp) == SSA_NAME
+ || (TREE_ADDRESSABLE (exp) == 0
+ (TREE_CODE (exp) == PARM_DECL
+ || (TREE_CODE (exp) == VAR_DECL !TREE_STATIC (exp)
return exp;
return save_expr (exp);
[Bug middle-end/47566] ICE in vn_reference_lookup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47566
--- Comment #10 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-01
15:40:30 UTC ---
Testcase:
/* { dg-lto-do run } */
/* { dg-extra-ld-options -O2 -ffast-math } */
double cabs(_Complex double);
double __attribute__((used))
foo (_Complex double x, int b)
{
if (b)
x = 0;
return cabs(x);
}
int main() { return 0; }
[Bug target/47564] [4.6 Regression] internal compiler error in memory_address_addr_space, at explow.c:504
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47564 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-01 15:47:07 UTC --- Following works by not doing target_reinit once tree_rest_of_compilation calls init_function_start, until final. --- function.c.jj 2011-01-25 18:40:08.0 +0100 +++ function.c 2011-02-01 16:33:48.0 +0100 @@ -4294,7 +4294,10 @@ invoke_set_current_function_hook (tree f cl_optimization_restore (global_options, TREE_OPTIMIZATION (opts)); } - targetm.set_current_function (fndecl); + /* Don't call targetm.set_current_function in between + prepare_function_start and following free_after_compilation. */ + if (regno_reg_rtx == NULL) +targetm.set_current_function (fndecl); } }
[Bug target/47558] 163267 breaks exception traceback in xplor-nih
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #17 from Iain Sandoe iains at gcc dot gnu.org 2011-02-01 15:50:44
UTC ---
I guess you could make the requirement to link libSystem before (and after)
libgcc_ext explicit like this:
Index: gcc/config/darwin10.h
===
--- gcc/config/darwin10.h(revision 169471)
+++ gcc/config/darwin10.h(working copy)
@@ -23,3 +23,6 @@ unwinder in libSystem is fixed to digest new epilo
#undef LIB_SPEC
#define LIB_SPEC %{!static:-no_compact_unwind -lSystem}
+
+#undef LINK_GCC_C_SEQUENCE_SPEC
+#define LINK_GCC_C_SEQUENCE_SPEC %L %G %L
===
better than having a side-effect of a stub library achieving the same thing.
but it would still be worth knowing how many (if any) programs actually require
flag namespace.
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 --- Comment #6 from Janne Blomqvist jb at gcc dot gnu.org 2011-02-01 15:50:52 UTC --- (In reply to comment #3) clock_gettime is defined in librt, so if libgfortran started using librt symbols, it needs to a) link against it dynamically for libgfortran.so Yes, that's what it does, using a configure.ac snippet lifted from libgomp. On my system, ldd libgfortran.so shows: linux-vdso.so.1 = (0x7fff71ae9000) libquadmath.so.0 = /home/janne/src/gfortran/trunk/install/lib/../lib64/libquadmath.so.0 (0x7f885a485000) libm.so.6 = /lib/libm.so.6 (0x7f885a1df000) librt.so.1 = /lib/librt.so.1 (0x7f8859fd7000) libc.so.6 = /lib/libc.so.6 (0x7f8859c54000) libpthread.so.0 = /lib/libpthread.so.0 (0x7f8859a36000) /lib64/ld-linux-x86-64.so.2 (0x7f885a9cf000) where the librt and libpthread dependencies are due to using clock_gettime() from librt. b) arrange for gfortran driver to pass in -lrt when linking libgfortran statically. Right, I haven't considered this part. Anyone have any idea how that could be done?
[Bug fortran/47572] [OOP] Invalid: Allocatable polymorphic with init expression.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47572
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2011.02.01 15:52:21
AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #1 from janus at gcc dot gnu.org 2011-02-01 15:52:21 UTC ---
The following should be enough to fix it:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 169479)
+++ gcc/fortran/resolve.c (working copy)
@@ -10063,7 +10063,8 @@ resolve_fl_variable (gfc_symbol *sym, int mp_flag)
/* Reject illegal initializers. */
if (!sym-mark sym-value)
{
- if (sym-attr.allocatable)
+ if (sym-attr.allocatable || (sym-ts.type == BT_CLASS
+CLASS_DATA (sym)-attr.allocatable))
gfc_error (Allocatable '%s' at %L cannot have an initializer,
sym-name, sym-declared_at);
else if (sym-attr.external)
[Bug middle-end/47566] ICE in vn_reference_lookup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47566 --- Comment #11 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-02-01 15:52:42 UTC --- (In reply to comment #9) In file included from :425:0: /tmp/cp2k/makefiles/../src/realspace_grid_types.F: In function 'rs_pw_transfer_replicated': /tmp/cp2k/makefiles/../src/realspace_grid_types.F:816:0: error: non-trivial conversion at assignment yes, that is PR45586. Can be worked around with either release checking (which I have enable right now) or changing src/realspace_grid_types.F to use REAL(KIND=dp), DIMENSION ( :, :, : ), POINTER :: r ! the grid instead of REAL(KIND=dp), DIMENSION ( :, :, : ), ALLOCATABLE :: r ! the grid The following fixes the ICE for me: cool.
[Bug target/47558] 163267 breaks exception traceback in xplor-nih
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558 --- Comment #18 from Iain Sandoe iains at gcc dot gnu.org 2011-02-01 15:57:30 UTC --- (In reply to comment #17) I guess you could make the requirement to link libSystem before (and after) libgcc_ext explicit like this: you would also need to ensure that libSystem was before /install/path/to/my/libgcc_s.1.dylib in the search paths at runtime... but it would still be worth knowing how many (if any) programs actually require flag namespace. ... because if this is a large requirement then we really need to change the way the _ext is done (for reasons that should be evident from this and the preceding comment),.
[Bug target/47558] 163267 breaks exception traceback in xplor-nih
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558 --- Comment #19 from Jack Howarth howarth at nitro dot med.uc.edu 2011-02-01 15:59:30 UTC --- (In reply to comment #16) (In reply to comment #15) Perhaps r163267 is fragile to certain combination of linker flags (like -flat_namespace)? fragile LOL... Considering that Apple has always recommended the use of that flag for porting unix software... http://developer.apple.com/library/mac/#documentation/Porting/Conceptual/PortingUnix/compiling/compiling.html%23//apple_ref/doc/uid/TP40002850-TPXREF101 (see the section on Understanding Two-Level Namespaces), it really is not a very funny bug.
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 Janne Blomqvist jb at gcc dot gnu.org changed: What|Removed |Added Target|i686-pc-linux-gnu | Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.02.01 16:02:50 Host|i686-pc-linux-gnu | AssignedTo|unassigned at gcc dot |jb at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 Build|i686-pc-linux-gnu | --- Comment #7 from Janne Blomqvist jb at gcc dot gnu.org 2011-02-01 16:02:50 UTC --- So using -static I was able to reproduce this bug on x86_64-unknown-linux-gnu. As Jakub mentioned, the driver must link in librt when linking statically. I'll look into how this could be done. As a workaround for the reporter, dynamic linking works fine.
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571
--- Comment #8 from Tobias Burnus burnus at gcc dot gnu.org 2011-02-01
16:08:10 UTC ---
(In reply to comment #6)
clock_gettime is defined in librt, so if libgfortran started using librt
symbols, it needs to a) link against it dynamically for libgfortran.so
Yes, that's what it does
But why doesn't it work then, cf. comment 4? openSUSE 11.3 is neither old nor
very special.
b)
arrange for gfortran driver to pass in -lrt when linking libgfortran
statically.
Right, I haven't considered this part. Anyone have any idea how that could be
done?
Via libgfortran/libgfortran.spec.in and some configure script?
Cf. libgomp and libgomp/configure.ac's
# Set up the set of libraries that we need to link against for libgomp.
# Note that the GOMP_SELF_SPEC in gcc.c will force -pthread for -fopenmp,
# which will force linkage against -lpthread (or equivalent for the system).
# That's not 100% ideal, but about the best we can do easily.
if test $enable_shared = yes; then
link_gomp=-lgomp %{static: $LIBS}
else
link_gomp=-lgomp $LIBS
fi
AC_SUBST(link_gomp)
By the way, there is also -lrt added via libgomp/configure.tgt for HPUX.
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-01 16:13:24 UTC --- How many fortran users actually need to more precise DATE_AND_TIME though? Bringing in -lpthread (as dependency of -lrt) certainly has some extra overhead, e.g. everything that uses gthr* will suddenly use real locking. You could e.g. use clock_gettime only through a weakref, thus let the users choose if clock_gettime should be used or not. If they don't link in librt, less precise implementation would be used, if they do link it in, it would become more precise (-lrt would be linked in automatically e.g. for -fopenmp compilations).
[Bug tree-optimization/47559] ICE: verify_stmts failed: statement marked for throw, but doesn't with -fnon-call-exceptions and noexcept
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47559 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-01 16:16:04 UTC --- Author: rguenth Date: Tue Feb 1 16:15:56 2011 New Revision: 169487 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=169487 Log: 2011-02-01 Richard Guenther rguent...@suse.de PR tree-optimization/47559 * tree-ssa-loop-im.c (can_sm_ref_p): Do not perform store-motion on references that can throw. * g++.dg/torture/pr47559.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/torture/pr47559.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-loop-im.c
[Bug fortran/47574] New: internal compiler error: in build2_stat, at tree.c:3795
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47574 Summary: internal compiler error: in build2_stat, at tree.c:3795 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: mlo...@uni-bremen.de Created attachment 23200 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23200 example fortran code to reproduce bug This appears to be a problem with optimization: with -O2 routine compiles without errors. Small changes to the code also seems to fix the problem: e.g. changing exchWidthX to OLx in line 947 The code is part of a ocean model used in oceanography (http://mitgcm.org) and usually compiles on unix-like platforms with a f77 compiler without problems. command-line and output follows, fortran code is attached: gfortran -v -save-temps -Wunused -Wuninitialized -fsecond-underscore -fconvert=big-endian -ffixed-line-length-132 -O3 -funroll-loops -c exch2_uv_agrid_3d_rl.f Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-apple-darwin10.4.0/4.6.0/lto-wrapper Target: x86_64-apple-darwin10.4.0 Configured with: ../gcc-4.6-20101106/configure --enable-languages=c++,fortran Thread model: posix gcc version 4.6.0 20101106 (experimental) (GCC) COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.6' '-v' '-save-temps' '-Wunused' '-Wuninitialized' '-fsecond-underscore' '-fconvert=big-endian' '-ffixed-line-length-132' '-O3' '-funroll-loops' '-c' '-mtune=generic' /usr/local/libexec/gcc/x86_64-apple-darwin10.4.0/4.6.0/f951 exch2_uv_agrid_3d_rl.f -ffixed-form -fPIC -quiet -dumpbase exch2_uv_agrid_3d_rl.f -mmacosx-version-min=10.6.6 -mtune=generic -auxbase exch2_uv_agrid_3d_rl -O3 -Wunused -Wuninitialized -version -fsecond-underscore -fconvert=big-endian -ffixed-line-length-132 -funroll-loops -fintrinsic-modules-path /usr/local/lib/gcc/x86_64-apple-darwin10.4.0/4.6.0/finclude -o exch2_uv_agrid_3d_rl.s GNU Fortran (GCC) version 4.6.0 20101106 (experimental) (x86_64-apple-darwin10.4.0) compiled by GNU C version 4.6.0 20101106 (experimental), GMP version 4.3.1, MPFR version 2.4.1, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU Fortran (GCC) version 4.6.0 20101106 (experimental) (x86_64-apple-darwin10.4.0) compiled by GNU C version 4.6.0 20101106 (experimental), GMP version 4.3.1, MPFR version 2.4.1, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 exch2_uv_agrid_3d_rl.f: In function ‘exch2_uv_agrid_3d_rl’: exch2_uv_agrid_3d_rl.f:293:0: internal compiler error: in build2_stat, at tree.c:3795 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug tree-optimization/47559] ICE: verify_stmts failed: statement marked for throw, but doesn't with -fnon-call-exceptions and noexcept
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47559 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords|wrong-code | Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-01 16:18:08 UTC --- ICE is fixed. I'll open a new bug for the wrong-code issue.
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 --- Comment #10 from Michael Richmond michael.a.richmond at nasa dot gov 2011-02-01 16:18:49 UTC --- (In reply to comment #7) As a workaround for the reporter, dynamic linking works fine. When I use gfortran -Bdynamic call_date_and_time.f90 I get the same error
[Bug fortran/47574] internal compiler error: in build2_stat, at tree.c:3795
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47574 Martin Losch mlo...@uni-bremen.de changed: What|Removed |Added Attachment #23200|0 |1 is obsolete|| --- Comment #1 from Martin Losch mlo...@uni-bremen.de 2011-02-01 16:20:19 UTC --- Created attachment 23201 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23201 correct fortran code to reproduce problem I am sorry for attaching the wrong file
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571
--- Comment #11 from Janne Blomqvist jb at gcc dot gnu.org 2011-02-01
16:20:06 UTC ---
(In reply to comment #8)
(In reply to comment #6)
clock_gettime is defined in librt, so if libgfortran started using librt
symbols, it needs to a) link against it dynamically for libgfortran.so
Yes, that's what it does
But why doesn't it work then, cf. comment 4? openSUSE 11.3 is neither old nor
very special.
Because the original report links statically (as can be deduced from the
presence of libgfortran.a). As I mentioned, static linking is broken but
dynamic works. FWIW, I suspect the output of ldd in comment #4 refers to the
system provided libgfortran, as neither librt nor libquadmath is present.
b)
arrange for gfortran driver to pass in -lrt when linking libgfortran
statically.
Right, I haven't considered this part. Anyone have any idea how that could
be
done?
Via libgfortran/libgfortran.spec.in and some configure script?
Cf. libgomp and libgomp/configure.ac's
# Set up the set of libraries that we need to link against for libgomp.
# Note that the GOMP_SELF_SPEC in gcc.c will force -pthread for -fopenmp,
# which will force linkage against -lpthread (or equivalent for the system).
# That's not 100% ideal, but about the best we can do easily.
if test $enable_shared = yes; then
link_gomp=-lgomp %{static: $LIBS}
else
link_gomp=-lgomp $LIBS
fi
AC_SUBST(link_gomp)
By the way, there is also -lrt added via libgomp/configure.tgt for HPUX.
Thanks, I'll have to take a look at this later tonight.
[Bug tree-optimization/47575] New: store-motion removes global stores from endless loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47575
Summary: store-motion removes global stores from endless loops
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org
void foo (int *k)
{
for (;;)
*k = 0;
}
is optimized to
foo (int * k)
{
int k__lsm.2;
bb 2:
k__lsm.2_4 = MEM[(int *)k_1(D)];
bb 3:
k__lsm.2_6 = 0;
bb 4:
goto bb 3;
}
by LIM, removing the global store. We can use is_hidden_global_store
or friends and require at least one exit if that is true for a sm ref.
[Bug tree-optimization/47575] store-motion removes global stores from endless loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47575 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.02.01 16:25:49 CC||rakdver at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-01 16:25:49 UTC --- Something like Index: tree-ssa-loop-im.c === --- tree-ssa-loop-im.c (revision 169487) +++ tree-ssa-loop-im.c (working copy) @@ -2329,7 +2329,10 @@ can_sm_ref_p (struct loop *loop, mem_ref base = get_base_address (ref-mem); if ((tree_could_trap_p (ref-mem) || (DECL_P (base) TREE_READONLY (base))) - !ref_always_accessed_p (loop, ref, true)) + (!ref_always_accessed_p (loop, ref, true)) + || (TREE_CODE (base) == MEM_REF + ptr_deref_may_alias_global_p (TREE_OPERAND (base, 0)) + !loop-exits-e)) return false; /* And it must be independent on all other memory references minus introducing a new predicate loop_has_no_exit_p ().
