[Bug tree-optimization/47005] [4.6 Regression] ACATS c62002a is miscompiled at -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47005 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug rtl-optimization/47166] [4.5 4.6 Regression] SpecCpu2000 Ammp segfaults for ARM with -O3 -mthumb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47166
--- Comment #5 from Hans-Peter Nilsson hp at gcc dot gnu.org 2011-01-05
08:21:11 UTC ---
(In reply to comment #4)
(In reply to comment #0)
(insn 3163 3161 3164 107 rectmm.c:1041 (set (reg:SI 1 r1)
(plus:SI (reg:SI 1 r1)
(const_int 280 [0x118]))) 4 {*arm_addsi3} (nil))
Please consider my request in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45051#c8.
I mean, the But r1 is an input as well as an output , i.e. referred to, so
insn 3163 should have matched without your patch. I'm missing analysis on why
that didn't happen part.
[Bug fortran/47174] New: libquadmath: Build now depends on makeinfo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47174 Summary: libquadmath: Build now depends on makeinfo Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org http://gcc.gnu.org/ml/fortran/2011-01/msg00012.html libquadmath now fails to build if makeinfo isn't installed on the system: [...] WARNING: `makeinfo' is missing on your system. You should only need it if you modified a `.texi' or `.texinfo' file, or any other file indirectly affecting the aspect of the manual. The spurious call might also be the consequence of using a buggy `make' (AIX, DU, IRIX). You might want to install the `Texinfo' package or the `GNU make' package. Grab either from any GNU archive site. make[3]: *** [libquadmath.info] Error 1 There is apparently a dependency on libquadmath.info via INFO_DEPS: INFO_DEPS = libquadmath.info In what way is that different from, say, libgomp? IIUC makeinfo is required for the development tree. libgomp doesn't fail to build in this configuration. In fact, all components used to build in this configuration (except maybe libjava) up to the patch.
[Bug fortran/46520] [4.6 Regression] libquadmath: fails at link test on bare irons
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46520 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED --- Comment #9 from Tobias Burnus burnus at gcc dot gnu.org 2011-01-05 08:57:59 UTC --- (In reply to comment #8) Tobias, anything left here or can this report be closed? I was just told for picochip-unknown-none: I just tried a build and libquadmath works fine. I had to disable libiberty, though. Thus, I close this PR as FIXED. If someone still has problems, please report them and either re-open this PR or fill a new PR (and CC me).
[Bug fortran/47024] [OOP] STORAGE_SIZE (for polymorphic types): Segfault at run time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47024 --- Comment #7 from janus at gcc dot gnu.org 2011-01-05 09:05:48 UTC --- Author: janus Date: Wed Jan 5 09:05:44 2011 New Revision: 168505 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168505 Log: 2011-01-05 Janus Weil ja...@gcc.gnu.org PR fortran/47024 * trans-decl.c (gfc_trans_deferred_vars): Initialize the _vpr component of polymorphic allocatables according to their declared type. 2011-01-05 Janus Weil ja...@gcc.gnu.org PR fortran/47024 * gfortran.dg/storage_size_3.f08: New. Added: trunk/gcc/testsuite/gfortran.dg/storage_size_3.f08 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/47024] [OOP] STORAGE_SIZE (for polymorphic types): Segfault at run time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47024 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #8 from janus at gcc dot gnu.org 2011-01-05 09:17:25 UTC --- Fixed with r168505. Closing.
[Bug fortran/46262] [OOP] tree check: expected function_type or method_type, have pointer_type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46262 janus at gcc dot gnu.org changed: What|Removed |Added Summary|[4.6 Regression] [OOP] tree |[OOP] tree check: expected |check: expected |function_type or |function_type or|method_type, have |method_type, have |pointer_type |pointer_type| --- Comment #9 from janus at gcc dot gnu.org 2011-01-05 09:33:56 UTC --- (In reply to comment #1) -fdump-tree-original shows wrong code being generated: struct class$integrable_model_a T3f8 (struct class$integrable_model restrict) D.1529; static real(kind=4) C.1528 = 2.0e+0; struct class$integrable_model_a D.1527; D.1527 = d_dt ((struct class$integrable_model *) model); D.1529 = d_dt (D.1527, C.1528); _gfortran_transfer_real_write (dt_parm.0, D.1529, 4); The second call to d_dt should actually be a call to D.1527-$vptr-multiply. Note that 4.5 also produces wrong code here: real(kind=4) D.1560; static real(kind=4) C.1559 = 2.0e+0; struct .class.integrable_model.a D.1558; D.1558 = d_dt ((struct .class.integrable_model *) model); D.1560 = multiply (D.1558, C.1559); _gfortran_transfer_real (dt_parm.0, D.1560, 4); It has a static call to 'multiply', instead of a polymorphic call via the vptr. So, since 4.5 also does not handle the test case correctly, I think it's fair to remove the regression tag. In a way one could even argue that the ICE in 4.6 is an improvement over 4.5 silently giving wrong results for such cases, since the user does at least get *some* error message (even though a crude and uninformative one), instead of assuming the feature was supported and getting wrong results in the end!
[Bug fortran/46017] Reject ALLOCATE(a, a%b) as a%b depends on the allocation status of a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46017 --- Comment #3 from Thomas Koenig tkoenig at gcc dot gnu.org 2011-01-05 10:03:18 UTC --- Author: tkoenig Date: Wed Jan 5 10:03:15 2011 New Revision: 168506 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168506 Log: 2011-01-05 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/46017 * resolve.c (resolve_allocate_deallocate): Follow references to check for duplicate occurence of allocation/deallocation objects. 2011-01-05 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/46017 * gfortran.dg/allocate_error_2.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/allocate_error_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/47145] [4.6 Regression] cross-compilation fails with cannot check for file existence when cross compiling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47145 --- Comment #19 from Jonathan Wakely redi at gcc dot gnu.org 2011-01-05 10:07:40 UTC --- (In reply to comment #18) This xml catalog testing passed on Debian and RHEL: echo 'article/' | xsltproc --noout --nonet \ http://docbook.sourceforge.net/release/xsl/current/xhtml/docbook.xsl - We use the xsl-ns stylesheets for Docbook 5 support and I think xsl-ns is less widely-installed than the older stylesheets. We also generate xhtml 1.1 so a better test would be http://docbook.sourceforge.net/release/xsl-ns/current/xhtml-1_1/docbook.xsl
[Bug fortran/47175] New: no predefined macros __amd64, __amd64__, __x86_64 __x86_64__ in prepocessor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47175 Summary: no predefined macros __amd64, __amd64__, __x86_64 __x86_64__ in prepocessor Product: gcc Version: 4.4.5 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: jan.raub...@gmx.de Matlab and probably other software uses the predefined macros to check for the current platform to enable long pointer or not. I have found that the macros above are no more in gfortran 4.4 and higher. The only way to check for the right platform is the __LP64__ macro which seems not to be used on other compiles like sunf90. It takes me some hours to find why a Matlab mex file crashes immediately after calling. Whith gcc these macros are available, why not whith gfortran? Jan
[Bug tree-optimization/47005] [4.6 Regression] ACATS c62002a is miscompiled at -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47005 --- Comment #9 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-01-05 11:23:43 UTC --- Author: ebotcazou Date: Wed Jan 5 11:23:40 2011 New Revision: 168508 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168508 Log: PR tree-optimization/47005 * tree-sra.c (struct access): Add 'non_addressable' bit. (create_access): Set it for a DECL_NONADDRESSABLE_P field. (decide_one_param_reduction): Return 0 if the parameter is passed by reference and one of the accesses in the group is non_addressable. Added: trunk/gcc/testsuite/gnat.dg/opt14.adb Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-sra.c
[Bug tree-optimization/47005] [4.6 Regression] ACATS c62002a is miscompiled at -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47005 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #10 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-01-05 11:26:29 UTC --- Done.
[Bug libstdc++/47145] [4.6 Regression] cross-compilation fails with cannot check for file existence when cross compiling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47145 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.01.05 11:46:14 CC||ramana at gcc dot gnu.org Ever Confirmed|0 |1
[Bug libstdc++/47145] [4.6 Regression] cross-compilation fails with cannot check for file existence when cross compiling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47145 --- Comment #20 from Paolo Carlini paolo.carlini at oracle dot com 2011-01-05 11:50:08 UTC --- Note: somebody should now change the subject to something more meaningful, about hard coded paths and such, because the original P1 issue is resolved.
[Bug go/47176] New: libgo doesn't compile if libunicode is installed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47176 Summary: libgo doesn't compile if libunicode is installed Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go AssignedTo: i...@airs.com ReportedBy: b...@arklinux.org Trying to build gcc with go support on a system that has libunicode (http://libunicode.sf.net/) installed results in libtool: compile: /usr/src/ark/BUILD/gcc-4.6.0/build/./gcc/gccgo -B/usr/src/ark/BUILD/gcc-4.6.0/build/./gcc/ -B/usr/x86_64-unknown-linux-gnu/bin/ -B/usr/x86_64-unknown-linux-gnu/lib/ -isystem /usr/x86_64-unknown-linux-gnu/include -isystem /usr/x86_64-unknown-linux-gnu/sys-include -minline-all-stringops -O2 -g -c -fgo-prefix=libgo_bytes ../../../libgo/go/bytes/buffer.go ../../../libgo/go/bytes/bytes.go ../../../libgo/go/bytes/bytes_decl.go -fPIC -o bytes/.libs/bytes.o ../../../libgo/go/bytes/bytes.go:10:9: error: /usr/lib/../lib64/libunicode.so exists but does not contain any Go export data make[4]: *** [bytes/libbytes.a] Error 1 The problem is that the libgo build process sees the system libunicode.so which has nothing to do with go before seeing the go libunicode it built before.
[Bug fortran/41580] [OOP] SAME_TYPE_AS and EXTENDS_TYPE_OF - add compile-time simplifcation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41580 --- Comment #4 from janus at gcc dot gnu.org 2011-01-05 12:16:33 UTC --- (In reply to comment #2) For SAME_TYPE_AS and EXTENDS_TYPE_OF one should add a compile-time simplification to simplify.c. Currently, only the run-time version is implemented. Well, currently the translation of SAME_TYPE_AS is done by gfc_conv_same_type_as (trans-intrinsic.c), for both TYPE- and CLASS-valued arguments. Note: If both arguments are TYPE-valued, the result will be a compile-time constant, otherwise it has to be evaluated at runtime, according to the _hash values in the vtabs. In which situations would we actually gain something by treating the TYPE-TYPE case in simplify.c?
[Bug fortran/47177] New: bad example of using -dM in manual
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47177 Summary: bad example of using -dM in manual Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: documentation Severity: minor Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org http://gcc.gnu.org/onlinedocs/gfortran/Preprocessing-Options.html gives an example of using -dM: touch foo.f90; gfortran -cpp -dM foo.f90 But the CPP documentation for -dM at http://gcc.gnu.org/onlinedocs/cpp/Invocation.html#index-dM-183 points out that without -E it will be interpreted as a synonym for -fdump-rtl-mach To print the predefined macros the example should be changed to touch foo.f90; gfortran -cpp -E -dM foo.f90
[Bug libstdc++/47145] configure test for docbook-xsl-ns stylesheets uses hardcoded path
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47145 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Summary|[4.6 Regression]|configure test for |cross-compilation fails |docbook-xsl-ns stylesheets |with cannot check for file |uses hardcoded path |existence when cross| |compiling | --- Comment #21 from Jonathan Wakely redi at gcc dot gnu.org 2011-01-05 12:22:09 UTC --- summary changed
[Bug target/47178] New: QtWebKit miscompiled for x86_64-*-mingw*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47178 Summary: QtWebKit miscompiled for x86_64-*-mingw* Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: vanboxem.ru...@gmail.com The 64-bit runtime provided by the mingw-w64 project together with the GCC toolchain can compile Qt completely (with no known issues as far as I know) with GCC 4.4 (earlier versions don't have the necessary support for x64 Windows). Only with GCC 4.5 and 4.6, issues arise in the form of runtime errors when QtWebKit is compiled for x86_64-w64-mingw32. I have created a WebKit bug report here: https://bugs.webkit.org/show_bug.cgi?id=44052 The report has a stack backtrace of a Qt application (Assistant) showing the crash. All binaries are compiled with -g3 (highest debug level). Optimization level (none or -O2) does not change the fact that the app crashes. Looking at the backtrace, the problem is in WebKit somewhere, but as no other platforms show this problem, the issue must be toolchain-side somewhere. A correct binary is produced using patched (for Win64) 4.4 GCC toolchains.
[Bug tree-optimization/47179] New: [4.5/4.6 Regression] SPU: errno misoptimization around malloc call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47179 Summary: [4.5/4.6 Regression] SPU: errno misoptimization around malloc call Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: uweig...@gcc.gnu.org CC: rguent...@suse.de Target: spu-elf The problem described in PR 42944 is still present on SPU. This is because the SPU system library (newlib) uses: extern struct _reent _impure_data; #define errno (_impure_data._errno) in its version of errno.h, but GCC's call_may_clobber_ref_p_1 routine assumes errno is always either a global or else accessed via a pointer. It does not handle component references. (Note that the problem seems to be specific to the SPU, because of an optimization that makes use of the fact that SPU code is always single-threaded. On other platforms, newlib accesses errno via a pointer as well.)
[Bug c/47150] [4.5/4.6 Regression] ICE in gimplify_expr at gimplify.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47150 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-05 13:31:07 UTC --- Created attachment 22903 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22903 gcc46-pr47150.patch Untested fix.
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added CC||jason at redhat dot com, ||mark at codesourcery dot ||com --- Comment #21 from Jan Hubicka hubicka at gcc dot gnu.org 2011-01-05 13:36:37 UTC --- I am re-building now. Martin's edge cgraph_opt streaming fix is needed and flag_shlib needs to be set in lto-options.c With this fixed oprofile shows that cc1plus spends a lot of time in lookup_filed_1. 40259 5.6000 cc1plus cc1plus lookup_field_1 20275 2.8203 cc1plus cc1plus longest_match 15843 2.2038 libc-2.11.1.so libc-2.11.1.so _int_malloc 12409 1.7261 libc-2.11.1.so libc-2.11.1.so memset 10680 1.4856 cc1plus cc1plus htab_find_slot_with_hash 10471 1.4565 libc-2.11.1.so libc-2.11.1.so vfprintf 9004 1.2525 cc1plus cc1plus deflate_slow 8580 1.1935 cc1plus cc1plus ggc_internal_alloc_stat 8300 1.1545 libc-2.11.1.so libc-2.11.1.so memcpy 8100 1.1267 cc1plus cc1plus ht_lookup_with_hash 8044 1.1189 libpython2.6.so.1.0 libpython2.6.so.1.0 /usr/lib64/libpython2.6.so.1.0 7840 1.0905 cc1plus cc1plus _cpp_lex_direct 6340 0.8819 cc1plus cc1plus pointer_set_insert I am adding c++ maintainers to CC as this seems like relatively low hanging fruit for noticeable compilation speedup? It tends to show in oprofile as 5-7% of compile time.
[Bug fortran/47175] no predefined macros __amd64, __amd64__, __x86_64 __x86_64__ in prepocessor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47175 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2011-01-05 13:41:57 UTC --- Checking __amd64, __amd64__, __x86_64 __x86_64__ for pointer size is wrong since pointer size may be 32bit on x86-64. Checking __LP64__ is correct.
[Bug tree-optimization/47005] [4.6 Regression] ACATS c62002a is miscompiled at -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47005 --- Comment #11 from John Marino gnugcc at marino dot st 2011-01-05 13:49:47 UTC --- I rebuilt OpenBSD i386 using then Jan 5 daily bump (SVN 168495) and patched it with tree-src.c file. ACATS 62002a now passes, thanks.
[Bug tree-optimization/47005] [4.6 Regression] ACATS c62002a is miscompiled at -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47005 --- Comment #12 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-01-05 13:54:30 UTC --- ACATS 62002a now passes, thanks. Thanks for confirming. ACATS is clean on both i386 and i586 Linux SJLJ now, are there any remaining failures on BSD platforms?
[Bug fortran/47175] no predefined macros __amd64, __amd64__, __x86_64 __x86_64__ in prepocessor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47175 --- Comment #2 from Jan jan.rauberg at gmx dot de 2011-01-05 14:00:43 UTC --- (In reply to comment #1) Checking __amd64, __amd64__, __x86_64 __x86_64__ for pointer size is wrong since pointer size may be 32bit on x86-64. No, it can't be. The macros are set in dependence of the target platform (m32 or m64). That means, if m32 is given the macro __i686 is set instead of __amd64. On the other hand, if m64 is given the macro __amd64 is set. I don't want to know the really underlying platform. I (or Matlab) want to know the target platform. So it is right to check the __amd64 macro. You can try it with the gcc-4.4. Only with gfortran-4.4 the macro is missed. Checking __LP64__ is correct. Yes maybe, but this is not the default way (by Matlab and other tools) Jan
[Bug objc/45989] Some objc.dg-struct-layout-encoding-1 tests XPASS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45989 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-01-05 14:02:15 UTC --- Did somebody test the patch in comment #3?
[Bug go/47176] libgo doesn't compile if libunicode is installed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47176 --- Comment #1 from ian at gcc dot gnu.org ian at gcc dot gnu.org 2011-01-05 14:12:41 UTC --- Author: ian Date: Wed Jan 5 14:12:37 2011 New Revision: 168512 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168512 Log: PR go/47176 byte/libbytes.a depends on unicode.gox. Modified: trunk/libgo/Makefile.am trunk/libgo/Makefile.in
[Bug go/47176] libgo doesn't compile if libunicode is installed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47176 Ian Lance Taylor ian at airs dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from Ian Lance Taylor ian at airs dot com 2011-01-05 14:13:20 UTC --- There was a missing dependency in libgo/Makefile.am. This should be fixed now. Let me know if not. Thanks for reporting it.
[Bug fortran/47180] New: [OOP] EXTENDS_TYPE_OF returns the wrong result if the polymorphic variable is unallocated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47180 Summary: [OOP] EXTENDS_TYPE_OF returns the wrong result if the polymorphic variable is unallocated 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 Found when looking at PR 41580. The following program should print 6 times T but it prints trice F followed by trice T. From Fortran 2008: 13.7.60 EXTENDS_TYPE_OF (A, MOLD) Result Value. [unlimited polymorphic] ; otherwise if the dynamic type of A or MOLD is extensible, the result is true if and only if the dynamic type of A is an extension type of the dynamic type of MOLD; otherwise the result is processor dependent. NOTE 13.12 The dynamic type of a disassociated pointer or unallocated allocatable variable is its declared type. (NAG 5.1 ICEs and ifort prints the same result as gfortran; nevertheless, I expect that the code is correct, which is in line with NOTE 13.12.) implicit none type t1 integer :: a end type t1 type, extends(t1):: t11 integer :: b end type t11 type(t1) a1 type(t11) a11 class(t1), allocatable :: b1 class(t11), allocatable :: b11 print *, extends_type_of(b1,a1) ! T - currently, gfortran prints F print *, extends_type_of(b11,a1) ! T - currently, gfortran prints F print *, extends_type_of(b11,a11) ! T - currently, gfortran prints F allocate(t1 :: b1) allocate(t11 :: b11) print *, extends_type_of(b1,a1) ! T print *, extends_type_of(b11,a1) ! T print *, extends_type_of(b11,a11) ! T end
[Bug fortran/47175] no predefined macros __amd64, __amd64__, __x86_64 __x86_64__ in prepocessor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47175 --- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2011-01-05 14:28:51 UTC --- (In reply to comment #2) (In reply to comment #1) Checking __amd64, __amd64__, __x86_64 __x86_64__ for pointer size is wrong since pointer size may be 32bit on x86-64. No, it can't be. The macros are set in dependence of the target platform (m32 or m64). That means, if m32 is given the macro __i686 is set instead of __amd64. On the other hand, if m64 is given the macro __amd64 is set. I don't want to know the really underlying platform. I (or Matlab) want to know the target platform. So it is right to check the __amd64 macro. You can try it with the gcc-4.4. Only with gfortran-4.4 the macro is missed. See http://www.kernel.org/pub/linux/devel/binutils/ilp32/abi.pdf where pointer size is 32bit.
[Bug fortran/46402] libquadmath: Add fmalq
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46402 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2011.01.05 14:37:05 Resolution|DUPLICATE | Ever Confirmed|0 |1 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2011-01-05 14:37:05 UTC --- Reopen as this is only about porting existing code and not starting from scratch.
[Bug fortran/47180] [OOP] EXTENDS_TYPE_OF returns the wrong result if the polymorphic variable is unallocated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47180 --- Comment #1 from janus at gcc dot gnu.org 2011-01-05 14:37:26 UTC --- (In reply to comment #0) Found when looking at PR 41580. The following program should print 6 times T but it prints trice F followed by trice T. Actually it does print six time T for me! Are you sure your trunk is up to date? Note that r168505 is crucial here, which is the fix for PR47024 that I just committed a few hours ago, and which fixes this very issue ...
[Bug rtl-optimization/47166] [4.5 4.6 Regression] SpecCpu2000 Ammp segfaults for ARM with -O3 -mthumb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47166 --- Comment #6 from Ian Bolton ibolton at gcc dot gnu.org 2011-01-05 14:38:42 UTC --- I mean, the But r1 is an input as well as an output , i.e. referred to, so insn 3163 should have matched without your patch. I'm missing analysis on why that didn't happen part. OK, I will do more analysis to try to determine what's going on.
[Bug other/47167] Performance regression in numerical code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47167 --- Comment #1 from Martin Reinecke mar...@mpa-garching.mpg.de 2011-01-05 14:42:20 UTC --- Created attachment 22904 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22904 shorter test case More compact test case; the hot spot is marked with CRITICAL LOOP. Compile with gcc -O2 -fomit-frame-pointer testcase2.c -lm and test using time ./a.out.
[Bug fortran/47180] [OOP] EXTENDS_TYPE_OF returns the wrong result if the polymorphic variable is unallocated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47180 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2011-01-05 14:46:29 UTC --- (In reply to comment #1) Actually it does print six time T for me! Are you sure your trunk is up to date? Note that r168505 is crucial here, which is the fix for PR47024 that I just committed a few hours ago, and which fixes this very issue ... I think that my vanilla trunk is then not sufficiently up to date; I have another build which contains your patch - but also a draft patch for PR 41580 and is thus not reliably. Thus, I believe your result: Close as FIXED.
[Bug fortran/47180] [OOP] EXTENDS_TYPE_OF returns the wrong result for disassociated polymorphic pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47180 janus at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|NEW Last reconfirmed||2011.01.05 14:48:38 Resolution|FIXED | Summary|[OOP] EXTENDS_TYPE_OF |[OOP] EXTENDS_TYPE_OF |returns the wrong result if |returns the wrong result |the polymorphic variable is |for disassociated |unallocated |polymorphic pointers Ever Confirmed|0 |1 --- Comment #3 from janus at gcc dot gnu.org 2011-01-05 14:48:38 UTC --- (In reply to comment #1) Note that r168505 is crucial here, which is the fix for PR47024 that I just committed a few hours ago, and which fixes this very issue ... Anyway r168505 only fixed the issue for allocatables, not pointers! Therefore the following variant indeed still gives the wrong output: implicit none type t1 integer :: a end type t1 type, extends(t1):: t11 integer :: b end type t11 type(t1), target :: a1 type(t11), target :: a11 class(t1), pointer :: b1 class(t11), pointer :: b11 b1 = NULL() b11 = NULL() print *, extends_type_of(b1,a1) ! T - currently, gfortran prints F print *, extends_type_of(b11,a1) ! T - currently, gfortran prints F print *, extends_type_of(b11,a11) ! T - currently, gfortran prints F b1 = a1 b11 = a11 print *, extends_type_of(b1,a1) ! T print *, extends_type_of(b11,a1) ! T print *, extends_type_of(b11,a11) ! T end
[Bug lto/47162] [4.6 Regression] LTO is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47162 --- Comment #6 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2011-01-05 14:55:32 UTC --- Author: hjl Date: Wed Jan 5 14:55:27 2011 New Revision: 168515 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168515 Log: Fix PR lto/47162. 2011-01-05 Martin Jambor mjam...@suse.cz PR lto/47162 * lto-cgraph.c (output_cgraph_opt_summary_p): Also check for thunk deltas on streamed outgoing edges. (output_node_opt_summary): Output info for outgoing edges only when the node is in new parameter set. (output_cgraph_opt_summary): New parameter set, passed to the two aforementioned functions. Update its forward declaration and its callee too. Modified: trunk/gcc/ChangeLog trunk/gcc/lto-cgraph.c
[Bug lto/47181] New: memops-asm testcase fails with -flto -fuse-linker-plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47181 Summary: memops-asm testcase fails with -flto -fuse-linker-plugin Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: hubi...@gcc.gnu.org memops-asm testcase fails with -flto -fuse-linker-plugin. We produce undefined call to my_memcpy: evans:/abuild/jh/trunk-3/build-inst2/gcc/:[0]# ./xgcc -B ./ -O2 memops-asm*.c /abuild/jh/trunk-3/gcc/testsuite/gcc.c-torture/execute/builtins/lib/main.c -g -O0 -flto --save-temps -fdump-ipa-all-details-save-temps memops-asm.c: In function ?main_test?: memops-asm.c:37:3: warning: incompatible implicit declaration of built-in function ?printf? [enabled by default] [Leaving LTRANS /tmp/ccrBB4II.args] [Leaving LTRANS /tmp/ccc7Rjx0.ltrans.out] [Leaving LTRANS /tmp/ccOzcZ98.args] [Leaving LTRANS /tmp/ccc7Rjx0.ltrans0.o] evans:/abuild/jh/trunk-3/build-inst2/gcc/:[0]# grep memcpy *.s ccc7Rjx0.ltrans0.s: .globl memcpy ccc7Rjx0.ltrans0.s: .type memcpy, @function ccc7Rjx0.ltrans0.s:memcpy: ccc7Rjx0.ltrans0.s: callmy_memcpy.2055 ccc7Rjx0.ltrans0.s: .size memcpy, .-memcpy ccc7Rjx0.ltrans0.s: .type my_memcpy.2055, @function ccc7Rjx0.ltrans0.s:my_memcpy.2055: ccc7Rjx0.ltrans0.s: .size my_memcpy.2055, .-my_memcpy.2055 ccc7Rjx0.ltrans0.s: callmy_memcpy ccc7Rjx0.ltrans0.s: callmy_memcpy ccc7Rjx0.ltrans0.s: .string memcpy ccc7Rjx0.ltrans0.s: .string my_memcpy the issue is that my_memcpy is declared once as: extern void *memcpy (void *, const void *, size_t) __asm (ASMNAME (my_memcpy)); and in the other unit as void * my_memcpy (void *d, const void *s, size_t n) we fail to merge the declarations in lto-symtab since builtins are streamed in special way. This leads to linker bug and wrong code: http://sourceware.org/bugzilla/show_bug.cgi?id=12365
[Bug fortran/47180] [OOP] EXTENDS_TYPE_OF returns the wrong result for disassociated polymorphic pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47180
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 #4 from janus at gcc dot gnu.org 2011-01-05 15:08:09 UTC ---
Draft patch:
Index: gcc/fortran/trans-expr.c
===
--- gcc/fortran/trans-expr.c(revision 168504)
+++ gcc/fortran/trans-expr.c(working copy)
@@ -6121,25 +6121,24 @@ gfc_trans_class_assign (gfc_expr *expr1, gfc_expr
if (expr2-ts.type != BT_CLASS)
{
/* Insert an additional assignment which sets the '_vptr' field. */
+ gfc_symbol *vtab;
+ gfc_symtree *st;
+
lhs = gfc_copy_expr (expr1);
gfc_add_vptr_component (lhs);
+
if (expr2-ts.type == BT_DERIVED)
-{
- gfc_symbol *vtab;
- gfc_symtree *st;
- vtab = gfc_find_derived_vtab (expr2-ts.u.derived);
- gcc_assert (vtab);
- rhs = gfc_get_expr ();
- rhs-expr_type = EXPR_VARIABLE;
- gfc_find_sym_tree (vtab-name, vtab-ns, 1, st);
- rhs-symtree = st;
- rhs-ts = vtab-ts;
-}
+vtab = gfc_find_derived_vtab (expr2-ts.u.derived);
else if (expr2-expr_type == EXPR_NULL)
-rhs = gfc_get_int_expr (gfc_default_integer_kind, NULL, 0);
- else
-gcc_unreachable ();
+vtab = gfc_find_derived_vtab (expr1-ts.u.derived);
+ gcc_assert (vtab);
+ rhs = gfc_get_expr ();
+ rhs-expr_type = EXPR_VARIABLE;
+ gfc_find_sym_tree (vtab-name, vtab-ns, 1, st);
+ rhs-symtree = st;
+ rhs-ts = vtab-ts;
+
tmp = gfc_trans_pointer_assignment (lhs, rhs);
gfc_add_expr_to_block (block, tmp);
Will commit as obvious after regtesting.
[Bug fortran/47182] New: libquadmath.texi: undefined flag: BUGURL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47182
Summary: libquadmath.texi: undefined flag: BUGURL
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
./libquadmath/libquadmath.texi uses:
Bugs in the GCC Quad-Precision Math Library implementation should be
reported via @value{BUGURL}.
But BUGURL is never set. For ./gcc/ one passes the value via configure:
ACX_BUGURL([http://gcc.gnu.org/bugs.html])
However, such an entry is missing from libquadmath/configure.ac.
(The macro is defined at ./config/acx.m4)
[Bug fortran/47175] no predefined macros __amd64, __amd64__, __x86_64 __x86_64__ in prepocessor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47175 --- Comment #4 from Jan jan.rauberg at gmx dot de 2011-01-05 15:13:23 UTC --- (In reply to comment #3) (In reply to comment #2) (In reply to comment #1) Checking __amd64, __amd64__, __x86_64 __x86_64__ for pointer size is wrong since pointer size may be 32bit on x86-64. No, it can't be. The macros are set in dependence of the target platform (m32 or m64). That means, if m32 is given the macro __i686 is set instead of __amd64. On the other hand, if m64 is given the macro __amd64 is set. I don't want to know the really underlying platform. I (or Matlab) want to know the target platform. So it is right to check the __amd64 macro. You can try it with the gcc-4.4. Only with gfortran-4.4 the macro is missed. See http://www.kernel.org/pub/linux/devel/binutils/ilp32/abi.pdf where pointer size is 32bit. As far as I understood means ILP32 a 32bit application in a 64bit environment and LP64 a 64bit application in 64bit environment. Am I Right? The predefined preprocessor macro __amd64 is true if I compile with -m64 (default on Linux) and it is not true if I compile with -m32. So why I can't check against this macro, as far it is supported (as in gcc)? Please correct me if I'm totally wrong. Or do you want to tell me that a 64bit application could use 32bit pointers, or the other way round? If so, how is it possible? Jan
[Bug tree-optimization/47005] [4.6 Regression] ACATS c62002a is miscompiled at -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47005 --- Comment #13 from John Marino gnugcc at marino dot st 2011-01-05 15:14:36 UTC --- (In reply to comment #12) Thanks for confirming. ACATS is clean on both i386 and i586 Linux SJLJ now, are there any remaining failures on BSD platforms? There are no ACATS or gnat.dg failures on the ZCX platforms (FreeBSD, DragonFlyBSD, NetBSD: i386 and x86_64) The regression tests just completed for OpenBSD i386. There is one failure on ACATS (cb1010a timeout)* Between yesterday and today, the test sse_nolib result went from passing to UNSUPPORTED Comments: 1) Between yesterday and today, test c390001 wouldn't even compile, but now it passes. 2)* I haven't investigated cb1010a timeout yet, but I think the problem is with OpenBSD, not gnat 3) the STACK_CHECK_STATIC_BUILTIN macro value has no effect on OpenBSD. I was expecting failures on c5210[3x,4x,4y] and cb1010[a,b,c] but they don't fail. 4) Despite DWARF2_UNWIND_INFO being set to 0 (meaning MD_UNWIND_SUPPORT macro is ignored), the null_deref and stack_check gnat.dg tests pass. in gdb, the segfault comes and then the program just exits normally. 5) I don't know if the behavior of 3) and 4) is normal for an SJLJ target, or if it's because apparently there's some missing support on OpenBSD for DWARF2 (if I try to set OpenBSD32 to ZCX handling the compile breaks with the unwind_context structure considered illegal), and commit commits also indicate something is missing for OpenBSD. The summary is that the OpenBSD port is currently better then it has ever been, and one remaining ACATS failure is probably related to how OpenBSD handles their stack. As of today, I don't have any errors to report, but that may change as I discover more about the issues I just outlined above.
[Bug fortran/47175] no predefined macros __amd64, __amd64__, __x86_64 __x86_64__ in prepocessor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47175 --- Comment #5 from H.J. Lu hjl.tools at gmail dot com 2011-01-05 15:17:50 UTC --- (In reply to comment #4) (In reply to comment #3) (In reply to comment #2) (In reply to comment #1) Checking __amd64, __amd64__, __x86_64 __x86_64__ for pointer size is wrong since pointer size may be 32bit on x86-64. No, it can't be. The macros are set in dependence of the target platform (m32 or m64). That means, if m32 is given the macro __i686 is set instead of __amd64. On the other hand, if m64 is given the macro __amd64 is set. I don't want to know the really underlying platform. I (or Matlab) want to know the target platform. So it is right to check the __amd64 macro. You can try it with the gcc-4.4. Only with gfortran-4.4 the macro is missed. See http://www.kernel.org/pub/linux/devel/binutils/ilp32/abi.pdf where pointer size is 32bit. As far as I understood means ILP32 a 32bit application in a 64bit environment No. ILP32 is a 32bit environment with 64bit instruction sets. and LP64 a 64bit application in 64bit environment. Am I Right? The predefined preprocessor macro __amd64 is true if I compile with -m64 (default on Linux) and it is not true if I compile with -m32. So why I can't check against this macro, as far it is supported (as in gcc)? Please correct me if I'm totally wrong. Or do you want to tell me that a 64bit application could use 32bit pointers, or the other way round? If so, how is it possible? ILP32 will define both __amd64 and __ILP32__. __amd64 is ISA, which can have 32bit or 64bit pointer sizes.
[Bug tree-optimization/47005] [4.6 Regression] ACATS c62002a is miscompiled at -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47005 --- Comment #14 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-01-05 15:33:24 UTC --- The regression tests just completed for OpenBSD i386. There is one failure on ACATS (cb1010a timeout)* This is a stack checking test. 3) the STACK_CHECK_STATIC_BUILTIN macro value has no effect on OpenBSD. I was expecting failures on c5210[3x,4x,4y] and cb1010[a,b,c] but they don't fail. The tests should pass w and w/o it on x86, but it's better to define it. 4) Despite DWARF2_UNWIND_INFO being set to 0 (meaning MD_UNWIND_SUPPORT macro is ignored), the null_deref and stack_check gnat.dg tests pass. in gdb, the segfault comes and then the program just exits normally. This is expected with SJLJ exceptions, you don't need MD_UNWIND_SUPPORT. The summary is that the OpenBSD port is currently better then it has ever been, and one remaining ACATS failure is probably related to how OpenBSD handles their stack. As of today, I don't have any errors to report, but that may change as I discover more about the issues I just outlined above. Great, thanks for the detailed report.
[Bug lto/47162] [4.6 Regression] LTO is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47162 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #7 from Martin Jambor jamborm at gcc dot gnu.org 2011-01-05 15:39:41 UTC --- Fixed.
[Bug fortran/46402] libquadmath: Add fmalq
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46402 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-05 16:09:10 UTC --- Created attachment 22905 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22905 gcc46-pr46402.patch So far only very lightly tested patch, will do full bootstrap/regtest now.
[Bug fortran/46402] libquadmath: Add fmalq
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46402 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-05 16:10:17 UTC --- Created attachment 22906 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22906 fmaq-test.c Testcase I was using.
[Bug tree-optimization/47005] [4.6 Regression] ACATS c62002a is miscompiled at -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47005 --- Comment #15 from John Marino gnugcc at marino dot st 2011-01-05 16:25:56 UTC --- [off PR] Hi Eric, Can you clarify one statement? Regarding the ten stack-check tests as I can them (c5210[3x,4x,4y], cb1010[a,c,d], null_deref[1,2], stack-check[1,2]), I now understand that it is expected that these tests pass on SJLJ targets. Are these true passes meaning SJLJ targets are fully capable of handling stack overflow and segfaults? Or are these results just false positives? Thanks, John ebotcazou at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47005 --- Comment #14 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-01-05 15:33:24 UTC --- The regression tests just completed for OpenBSD i386. There is one failure on ACATS (cb1010a timeout)* This is a stack checking test. 3) the STACK_CHECK_STATIC_BUILTIN macro value has no effect on OpenBSD. I was expecting failures on c5210[3x,4x,4y] and cb1010[a,b,c] but they don't fail. The tests should pass w and w/o it on x86, but it's better to define it. 4) Despite DWARF2_UNWIND_INFO being set to 0 (meaning MD_UNWIND_SUPPORT macro is ignored), the null_deref and stack_check gnat.dg tests pass. in gdb, the segfault comes and then the program just exits normally. This is expected with SJLJ exceptions, you don't need MD_UNWIND_SUPPORT. The summary is that the OpenBSD port is currently better then it has ever been, and one remaining ACATS failure is probably related to how OpenBSD handles their stack. As of today, I don't have any errors to report, but that may change as I discover more about the issues I just outlined above. Great, thanks for the detailed report.
[Bug preprocessor/39213] [4.4/4.5/4.6 regression] Preprocessor ICE with -m64 and --traditional-cpp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39213 --- Comment #22 from Rob rob1weld at aol dot com 2011-01-05 16:26:43 UTC --- (In reply to comment #21) At long last. It was only 2 years... I have some older than that. Thank you for your work on my Bug Report, Rob
[Bug other/45915] Check for gnu_unique_object in ld.so in gcc/configure.ac is broken for non-glibc ldd
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45915 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2011-01/msg00233.htm ||l Last reconfirmed||2011.01.05 16:44:40 CC||ro at gcc dot gnu.org AssignedTo|unassigned at gcc dot |ro at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.6.0 Ever Confirmed|0 |1 --- Comment #1 from Rainer Orth ro at gcc dot gnu.org 2011-01-05 16:44:40 UTC --- Mine, patch posted.
[Bug rtl-optimization/47166] [4.5 4.6 Regression] SpecCpu2000 Ammp segfaults for ARM with -O3 -mthumb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47166 Ian Bolton ibolton at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.01.05 16:45:57 Ever Confirmed|0 |1 --- Comment #7 from Ian Bolton ibolton at gcc dot gnu.org 2011-01-05 16:45:57 UTC --- I have altered the source, so that I call both refers_to_regno_p and reg_mentioned_p and print out when the two disagree. For the attached rectmm.i input file, there are only 5 disagreements: mismatch for regno=2343: refersto=F,mentions=T reg = (reg/f:SI 2343) i1 = (insn 3162 1730 3165 99 rectmm.c:1041 (set (reg/f:SI 2343) (reg:SI 1 r1)) -1 (nil)) mismatch for regno=2355: refersto=F,mentions=T reg = (reg/f:SI 2355) i1 = (insn 3166 1745 3169 99 rectmm.c:1043 (set (reg/f:SI 2355) (reg:SI 9 r9)) -1 (nil)) mismatch for regno=2377: refersto=F,mentions=T reg = (reg/f:SI 2377) i1 = (insn 3170 1770 1731 99 rectmm.c:1045 (set (reg/f:SI 2377) (reg:SI 12 ip)) -1 (nil)) mismatch for regno=2349: refersto=F,mentions=T reg = (reg/f:SI 2349) i1 = (insn 3174 1737 3177 99 rectmm.c:1042 (set (reg/f:SI 2349) (reg:SI 0 r0)) -1 (nil)) mismatch for regno=2361: refersto=F,mentions=T - reg and i1 follow ... reg = (reg/f:SI 2361) il = (insn 3178 1752 1772 99 rectmm.c:1044 (set (reg/f:SI 2361) (reg:SI 3 r3)) -1 (nil)) This occurs because reg_mentioned_p looks at output regs, but refers_to_regno_p does not. The knock-on effect of this difference must lead to those increments being lost, but I don't know why yet.
[Bug fortran/42954] [4.5/4.6 regression] TARGET_*_CPP_BUILDINS issues with gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42954 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added CC||jan.rauberg at gmx dot de --- Comment #13 from Andrew Pinski pinskia at gcc dot gnu.org 2011-01-05 16:49:54 UTC --- *** Bug 47175 has been marked as a duplicate of this bug. ***
[Bug fortran/47175] no predefined macros __amd64, __amd64__, __x86_64 __x86_64__ in prepocessor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47175 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #6 from Andrew Pinski pinskia at gcc dot gnu.org 2011-01-05 16:49:54 UTC --- This is a dup of bug 42954 anyways. But really it should be using __LP64__ for checking what size of a pointer is. *** This bug has been marked as a duplicate of bug 42954 ***
[Bug tree-optimization/46021] 3 tree-ssa tests XPASS almost everywhere
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46021 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc-p ||atches/2011-01/msg00238.htm ||l Target Milestone|--- |4.6.0 --- Comment #3 from Rainer Orth ro at gcc dot gnu.org 2011-01-05 16:51:09 UTC --- Patch for gcc.dg/tree-ssa/20040204-1.c on alpha, i386, x86_64 posted.
[Bug tree-optimization/47005] [4.6 Regression] ACATS c62002a is miscompiled at -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47005 --- Comment #16 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-01-05 16:55:57 UTC --- Regarding the ten stack-check tests as I can them (c5210[3x,4x,4y], cb1010[a,c,d], null_deref[1,2], stack-check[1,2]), I now understand that it is expected that these tests pass on SJLJ targets. null_deref[1,2] are not really about stack checking, but I get the point. Are these true passes meaning SJLJ targets are fully capable of handling stack overflow and segfaults? Or are these results just false positives? Stack checking per se is orthogonal to ZCX vs SJLJ. What isn't orthogonal is the handling of segfaults (hence the connection to stack checking done with probes): SJLJ handles segfaults out of the box whereas ZCX needs MD_UNWIND_SUPPORT. So, yes, the aforementioned 10 special tests are expected to pass on SJLJ targets out of the box, i.e. without additional target-specific support.
[Bug fortran/41580] [OOP] SAME_TYPE_AS and EXTENDS_TYPE_OF - add compile-time simplifcation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41580 --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2011-01-05 17:19:45 UTC --- Created attachment 22907 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22907 Draft patch - not fully working (In reply to comment #4) Note: If both arguments are TYPE-valued, the result will be a compile-time constant, otherwise it has to be evaluated at runtime, according to the _hash values in the vtabs. Well, extends_type_of can also be (sometimes) be evaluated at compile time for CLASS. In which situations would we actually gain something I assume that in practice it only matters for automatically generated code - but there it might reduce the code size and improve the performance. By the way: I think that's a 4.7 item. * * * I attached a draft patch. Note, however, that it does not work (cf. bottom of patch/test case). For if (extends_type_of(a11,b11) .neqv. .true.) call abort() one enters gfc_simplify_extends_type_of twice: Once the second argument (mold) is BT_CLASS (which give the correct result: NULL, i.e. not compile-time simplifiable). But then again with mold being BT_DERIVED - which is then compile-time simplified to .TRUE. as a11 and b11 are the same type. I have not dug into this, but it seems to occur in two steps - first a normal simplification happens, then a specific interface is used via gfc_intrinsic_func_interface, which is then again simplified - but with BT_DERIVED argument (base type). I think all gfc_simplify_* functions could be affected. TODO: - Fix the double-simplification problem - Add more test cases - I think the double-simplification also affects same_type, but it is currently not tested for.
[Bug other/47167] Performance regression in numerical code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47167 --- Comment #2 from Uros Bizjak ubizjak at gmail dot com 2011-01-05 17:31:20 UTC --- The only difference in the hot loop is the usage of two regs in the address: 4.5.1: .L142: movapd%xmm0, (%rcx) mulpd%xmm6, %xmm2 addq$32, %rbx movapd%xmm1, %xmm6 mulpd%xmm0, %xmm6 movsd(%rax), %xmm1 movsd8(%rax), %xmm3 unpcklpd%xmm1, %xmm1 subpd%xmm2, %xmm6 unpcklpd%xmm3, %xmm3 mulpd%xmm9, %xmm1 mulpd%xmm0, %xmm3 movapd%xmm6, 16(%rcx) addq$32, %rcx movapd%xmm1, %xmm0 movsd16(%rax), %xmm1 mulpd%xmm6, %xmm0 unpcklpd%xmm1, %xmm1 movsd24(%rax), %xmm2 addq$32, %rax cmpq%rsi, %rbx unpcklpd%xmm2, %xmm2 subpd%xmm3, %xmm0 mulpd%xmm9, %xmm1 jne.L142 4.6: .L167: movapd%xmm0, %xmm10 .L143: mulpd%xmm2, %xmm6 movapd%xmm3, %xmm2 movapd%xmm10, (%rsi,%rcx) mulpd%xmm10, %xmm2 movsd(%rdx), %xmm0 movsd8(%rdx), %xmm1 subpd%xmm6, %xmm2 unpcklpd%xmm0, %xmm0 unpcklpd%xmm1, %xmm1 mulpd%xmm11, %xmm0 movapd%xmm2, 16(%rsi,%rcx) mulpd%xmm10, %xmm1 addq$32, %rcx mulpd%xmm2, %xmm0 movsd16(%rdx), %xmm3 movsd24(%rdx), %xmm6 addq$32, %rdx cmpq%rdi, %rcx unpcklpd%xmm3, %xmm3 unpcklpd%xmm6, %xmm6 subpd%xmm1, %xmm0 mulpd%xmm11, %xmm3 jne.L167 Given the comment above ix86_address_cost: /* Return cost of the memory address x. For i386, it is better to use a complex address than let gcc copy the address into a reg and make a new pseudo. But not if the address requires to two regs - that would mean more pseudos with longer lifetimes. */ this could be the reason for slowdown.
[Bug lto/47183] New: Please discard unused functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47183 Summary: Please discard unused functions Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: d.g.gorbac...@gmail.com Created attachment 22908 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22908 Testcase Compile it with `g++ -O2 -flto -fuse-linker-plugin 47183.C'.
[Bug fortran/22210] gfc_conv_array_initializer weirdness
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22210 John T jrt at worldlinc dot net changed: What|Removed |Added CC||jrt at worldlinc dot net --- Comment #15 from John T jrt at worldlinc dot net 2011-01-05 17:47:45 UTC --- Using gfortran for gcc-4.4.5 on i686 Linux, compiled here with glib-2.7-something on Mandriva 2008.1, I got the following error while compiling files for an old program. I looked at the gfortran source around line 4781 of varasm.c, but don't know enough to make any suggestions about the problem. The only observation I have is that the preceding if statement assures that pos doesn't equal totalbytes, so the = operator shouldn't need the = in the assert argument. I don't know what statement sets the size of the data block (and its size). gfortran -c -o mind.o mind.f mind.f:457: internal compiler error: in output_constructor, at varasm.c:4781 line 454+ of mind.f contains the statements return end c- block data general c- c common /grid/grid_on
[Bug fortran/46402] libquadmath: Add fmalq
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46402 --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org 2011-01-05 17:56:50 UTC --- (In reply to comment #4) Created attachment 22905 [details] gcc46-pr46402.patch Please also add an item to libquadmath.texi
[Bug fortran/46416] libquadmath: missing functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46416 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2011-01-05 18:00:00 UTC --- I now compared the list of libquadmath functions at http://gcc.gnu.org/onlinedocs/libquadmath/Math-Library-Routines.html with the C99 functions in math.h and complex.h (cf. http://en.wikipedia.org/wiki/Math.h and http://en.wikipedia.org/wiki/Complex.h). Missing (no guarantee for completeness or correctness) a) fmaq, cf. Jakub's patch at PR 46402 b) math.h functions: fdimq, fmaq [cf. above], fmaxq, fminq, ilogbq, llrintq, lrintq, log2q, nearbyintq, nexttowardq, remquoq c) complex.h functions - casinq, cacosq, catanq, casinhq, cacoshq, catanhq - cimagq, conjq, cprojq, crealq
[Bug lto/47183] Please discard unused functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47183 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2011-01-05 18:00:15 UTC --- I don't see any unused functions here.
[Bug fortran/47180] [OOP] EXTENDS_TYPE_OF returns the wrong result for disassociated polymorphic pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47180 --- Comment #5 from janus at gcc dot gnu.org 2011-01-05 18:06:25 UTC --- Author: janus Date: Wed Jan 5 18:06:21 2011 New Revision: 168524 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168524 Log: 2011-01-05 Janus Weil ja...@gcc.gnu.org PR fortran/47180 * trans-expr.c (gfc_trans_class_assign): For a polymorphic NULL pointer assignment, set the _vptr component to the declared type. 2011-01-05 Janus Weil ja...@gcc.gnu.org PR fortran/47180 * gfortran.dg/extends_type_of_2.f03: New. Added: trunk/gcc/testsuite/gfortran.dg/extends_type_of_2.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog
[Bug boehm-gc/11412] boehm-gc testing problems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11412 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2011-01/msg00244.htm ||l CC||ro at gcc dot gnu.org AssignedTo|unassigned at gcc dot |ro at gcc dot gnu.org |gnu.org | --- Comment #3 from Rainer Orth ro at gcc dot gnu.org 2011-01-05 18:08:38 UTC --- Mine, initial patch posted.
[Bug fortran/47180] [OOP] EXTENDS_TYPE_OF returns the wrong result for disassociated polymorphic pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47180 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from janus at gcc dot gnu.org 2011-01-05 18:12:48 UTC --- Fixed with r168524. Closing.
[Bug fortran/47180] [OOP] EXTENDS_TYPE_OF returns the wrong result for disassociated polymorphic pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47180 --- Comment #7 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-01-05 18:18:34 UTC --- Compiling revision 168524 gives: ../../work/gcc/fortran/trans-expr.c: In function 'gfc_trans_class_assign': ../../work/gcc/fortran/trans-expr.c:6172:42: error: 'vtab' may be used uninitialized in this function [-Werror=uninitialized] cc1: all warnings being treated as errors
[Bug libgomp/42616] OMP'ed loop inside pthread leads to crash.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42616 Victor K. vityan at vityan dot sytes.net changed: What|Removed |Added CC||vityan at vityan dot ||sytes.net --- Comment #8 from Victor K. vityan at vityan dot sytes.net 2011-01-05 18:20:35 UTC --- Testsuite works just fine with MingW-W64(GCC 4.6.0) + WinPthreads: /mw64src $ g++ -m32 omp_test.c -o ./omptst.exe -D_OPENMP -lgomp -lpthread /mw64src $ ./omptst OMP : All looks good /mw64src $ g++ -m64 -static omp_test.c -o ./omptst64.exe -D_OPENMP -lgomp -lpthread /mw64src $ ./omptst64 OMP : All looks good
[Bug libgomp/42616] OMP'ed loop inside pthread leads to crash.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42616 --- Comment #9 from Dmitri Zolotukhin zlogic at gmail dot com 2011-01-05 18:30:46 UTC --- @Victor K. Are you using the MinGW or TDM version of GCC? TDM 4.5.0 passes the test cases on my machine. Seems the problem existed only in the 4.4.* branch of gcc.
[Bug fortran/47180] [OOP] EXTENDS_TYPE_OF returns the wrong result for disassociated polymorphic pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47180 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #8 from Tobias Burnus burnus at gcc dot gnu.org 2011-01-05 18:34:10 UTC --- REOPEN: Causes build issues (cf. comment 7). gfc_symbol *vtab; if (expr2-ts.type == BT_DERIVED) vtab = gfc_find_derived_vtab (expr2-ts.u.derived); else if (expr2-expr_type == EXPR_NULL) vtab = gfc_find_derived_vtab (expr1-ts.u.derived); gcc_assert (vtab); Which means that vtab is not initialized if the if/if else branch is not entered. Simple solution: - gfc_symbol *vtab; + gfc_symbol *vtab = NULL;
[Bug c++/47184] New: gcc interprets C++0x initialization construct as function declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47184
Summary: gcc interprets C++0x initialization construct as
function declaration
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zeratul...@hotmail.com
For the following code:
struct S
{
int a;
float b;
};
struct T
{
T(S s) {}
};
int main()
{
T t(S{1, 0.1}); // ERROR HERE
}
gcc 4.6 trunk gives the following errors (with the --std=c++0x option):
decl.cpp: In function 'int main()':
decl.cpp:14:10: error: expected ')' before '{' token
decl.cpp:14:10: error: a function-definition is not allowed here before '{'
token
decl.cpp:14:18: error: expected primary-expression before ')' token
decl.cpp:14:18: error: expected ';' before ')' token
It seems gcc is interpreting the statement as a function declaration.
I think this is valid C++0x.
[Bug fortran/47180] [OOP] EXTENDS_TYPE_OF returns the wrong result for disassociated polymorphic pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47180 --- Comment #9 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-01-05 18:41:36 UTC --- Simple solution: - gfc_symbol *vtab; + gfc_symbol *vtab = NULL; This is the fix I have also reached and it allows gcc/fortran/trans-expr.c to be compiled.
[Bug fortran/47180] [OOP] EXTENDS_TYPE_OF returns the wrong result for disassociated polymorphic pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47180 --- Comment #10 from janus at gcc dot gnu.org 2011-01-05 18:55:59 UTC --- (In reply to comment #8) REOPEN: Causes build issues (cf. comment 7). Thanks for noticing, and sorry for the breakage. Simple solution: - gfc_symbol *vtab; + gfc_symbol *vtab = NULL; Yes, I'll commit shortly.
[Bug libstdc++/47185] New: UB in TR1 and C++0x placeholders and non conforming implementation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47185
Summary: UB in TR1 and C++0x placeholders and non conforming
implementation
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: thom.hel...@gmail.com
According to C++ TR1 3.6.4 [tr.func.bind.place] and C++0x (n3092) 20.8.10.1.3
[func.bind.place] placeholders are declared as:
namespace placeholders {
// M is the implementation-defined number of placeholders
extern unspecified _1;
extern unspecified _2;
.
.
.
extern unspecified _M;
}
However, in libstdc++ they are defined as:
namespace placeholders
{
namespace
{
_Placeholder1 _1;
_Placeholder2 _2;
.
.
.
_Placeholder29 _29;
}
}
The implementation is the same for tr1 and c++0x.
This implementation can lead to UB as discussed here:
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/c08e83496d251ba9?pli=1
[Bug objc/45989] Some objc.dg-struct-layout-encoding-1 tests XPASS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45989 --- Comment #5 from Rainer Orth ro at gcc dot gnu.org 2011-01-05 19:10:41 UTC --- I successfully did on i386-pc-solaris2.11. I'd suggest a slightly updated version (attached), with two changes * We should use i?86*-*-* (or perhaps just i?86-*-*, I see no reason for the first *). * The comment should be updated (perhaps with PR #s) to provide documentation for the XFAILed changes.
[Bug fortran/47180] [OOP] EXTENDS_TYPE_OF returns the wrong result for disassociated polymorphic pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47180 --- Comment #11 from janus at gcc dot gnu.org 2011-01-05 19:15:19 UTC --- Author: janus Date: Wed Jan 5 19:14:56 2011 New Revision: 168526 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168526 Log: 2011-01-05 Janus Weil ja...@gcc.gnu.org PR fortran/47180 * trans-expr.c (gfc_trans_class_assign): Bugfix for r168524 (make sure 'vtab' is initialized). Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c
[Bug libstdc++/47185] UB in TR1 and C++0x placeholders and non conforming implementation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47185 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.01.05 19:16:45 Ever Confirmed|0 |1 Severity|major |normal --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-01-05 19:16:45 UTC --- Easy enough to fix, but it won't happen in time for 4.6.0 I agree with the analysis, and I know you could contrive a test that relies on the address of a placeholder, but this is not major severity unless you can show an *actual* problem caused by this, rather than a theoretical one.
[Bug objc/45989] Some objc.dg-struct-layout-encoding-1 tests XPASS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45989 --- Comment #6 from Rainer Orth ro at gcc dot gnu.org 2011-01-05 19:17:42 UTC --- Created attachment 22909 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22909 slightly revised patch
[Bug fortran/47180] [OOP] EXTENDS_TYPE_OF returns the wrong result for disassociated polymorphic pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47180 janus at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #12 from janus at gcc dot gnu.org 2011-01-05 19:21:18 UTC --- Ok. Build problem fixed. Closing, finally.
[Bug other/47167] Performance regression in numerical code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47167 --- Comment #3 from Uros Bizjak ubizjak at gmail dot com 2011-01-05 19:30:49 UTC --- this could be the reason for slowdown. Hm, not really. But, by changing the generated assembly around loop entry: $ diff -u testcase2.s testcase2_.s --- testcase2.s2011-01-05 20:21:01.492919294 +0100 +++ testcase2_.s2011-01-05 20:22:23.616577277 +0100 @@ -1678,6 +1678,7 @@ addq%r15, %rdx addq$1, %rdi salq$5, %rdi +movapd%xmm10, %xmm0 jmp.L143 .p2align 4,,10 .p2align 3 @@ -1687,7 +1688,7 @@ mulpd%xmm2, %xmm6 movapd%xmm3, %xmm2 movapd%xmm10, (%rsi,%rcx) -mulpd%xmm10, %xmm2 +mulpd%xmm0, %xmm2 movsd(%rdx), %xmm0 movsd8(%rdx), %xmm1 subpd%xmm6, %xmm2 The slowdown is magically fixed: $ gcc -lm testcase2_.s $ time ./a.out real0m4.041s user0m4.034s sys0m0.003s versus: $ gcc -lm testcase2.s $ time ./a.out real0m4.239s user0m4.234s sys0m0.001s The important change is the change of %xmm10 - %xmm0 in the mulpd instruction. The functionality of the test didn't change due to existing movapd%xmm0, %xmm10 at the top of the loop and added extra movapd%xmm10, %xmm0 before the loop. This all happens on SnB, the code is generated with -O2 only. H.J., any ideas?
[Bug other/47167] Performance regression in numerical code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47167 --- Comment #4 from Uros Bizjak ubizjak at gmail dot com 2011-01-05 19:48:58 UTC --- Applying the same medicine to original test gets us from: wall time for map2alm: 6.908527s to wall time for map2alm: 6.703142s where 4.5.1 wins with: wall time for map2alm: 6.651740s
[Bug target/40411] -std=c99 does not enable c99 mode in Solaris C library
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40411 --- Comment #22 from Sean McGovern gseanmcg at gmail dot com 2011-01-05 19:50:09 UTC --- Sorry, still learning -- collect2 is definitely not the place for this. Target-specific plugin maybe?
[Bug other/47167] Performance regression in numerical code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47167 --- Comment #5 from H.J. Lu hjl.tools at gmail dot com 2011-01-05 20:09:11 UTC --- (In reply to comment #3) this could be the reason for slowdown. $ gcc -lm testcase2.s $ time ./a.out real0m4.239s user0m4.234s sys0m0.001s The important change is the change of %xmm10 - %xmm0 in the mulpd instruction. The functionality of the test didn't change due to existing movapd%xmm0, %xmm10 at the top of the loop and added extra movapd%xmm10, %xmm0 before the loop. This all happens on SnB, the code is generated with -O2 only. H.J., any ideas? Some loop performance is very sensitive to code sizes. This change -mulpd%xmm10, %xmm2 +mulpd%xmm0, %xmm2 will impact loop size due to exta REX prefix.
[Bug fortran/46416] libquadmath: missing functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46416
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2011.01.05 21:14:44
AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-05
21:14:44 UTC ---
Created attachment 22910
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22910
gcc46-pr46416.patch
Very lightly tested patch to add ca{sin,cos,tan}{,h}q and fix broken atan2q.
[Bug lto/47183] Please discard unused functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47183 --- Comment #2 from Dmitry Gorbachev d.g.gorbachev at gmail dot com 2011-01-05 22:13:55 UTC --- It's operator delete(void*). Also, typeinfo for S, typeinfo name for S, vtable for __cxxabiv1::__class_type_info are unused, too.
[Bug libstdc++/47185] UB in TR1 and C++0x placeholders and non conforming implementation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47185 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com Target Milestone|--- |4.6.0 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2011-01-05 22:31:03 UTC --- A fix seems to me safe enough even at this Stage, I'll post it momentarily. Note, we are not going to fiddle with TR1, very serious regressions only.
[Bug objc/45989] Some objc.dg-struct-layout-encoding-1 tests XPASS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45989 --- Comment #7 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-01-05 22:31:14 UTC --- * We should use i?86*-*-* (or perhaps just i?86-*-*, I see no reason for the first *). I don't think this cover x86_64-*-*, this is why I have tested *86*-*-* * The comment should be updated (perhaps with PR #s) to provide documentation for the XFAILed changes. See the end of comment #2. This should probably addressed by the objc maintainers.
[Bug lto/47183] Please discard unused functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47183 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||hubicka at gcc dot gnu.org Resolution||FIXED --- Comment #3 from Jan Hubicka hubicka at gcc dot gnu.org 2011-01-05 22:44:57 UTC --- j...@evans:/abuild/jh/trunk-3/build-inst2/gcc ./g++ -B ./ -O2 t.C -save-temps -flto -fuse-linker-plugin [Leaving LTRANS /abuild/jh/tmp//ccoul7Xo.args] [Leaving LTRANS /abuild/jh/tmp//ccT1KSUO.ltrans.out] [Leaving LTRANS /abuild/jh/tmp//ccOM6q7y.args] [Leaving LTRANS /abuild/jh/tmp//ccT1KSUO.ltrans0.o] j...@evans:/abuild/jh/trunk-3/build-inst2/gcc cat *.s .file ccT1KSUO.ltrans0.o .section.text.startup,ax,@progbits .p2align 4,,15 .globl main .type main, @function main: .LFB0: .cfi_startproc xorl%eax, %eax ret .cfi_endproc .LFE0: .size main, .-main .ident GCC: (GNU) 4.6.0 20110105 (experimental) .section.note.GNU-stack,,@progbits it is optimized out. With GNU LD I however get j...@evans:/abuild/jh/trunk-3/build-inst2/gcc nm a.out 00600748 d _DYNAMIC 00600910 d _GLOBAL_OFFSET_TABLE_ 0040067c R _IO_stdin_used w _Jv_RegisterClasses 00400582 W _ZTI1S 00400582 W _ZTS1S U _ZTVN10__cxxabiv117__class_type_infoE@@CXXABI_1.3 U _ZdlPv@@GLIBCXX_3.4 00600728 d __CTOR_END__ 00600720 d __CTOR_LIST__ 00600738 D __DTOR_END__ 00600730 d __DTOR_LIST__ 00400700 r __FRAME_END__ 00600740 d __JCR_END__ 00600740 d __JCR_LIST__ 00600940 A __bss_start 00600930 D __data_start 00400630 t __do_global_ctors_aux 004004f0 t __do_global_dtors_aux 00600938 D __dso_handle w __gmon_start__ 00600720 d __init_array_end 00600720 d __init_array_start 00400590 T __libc_csu_fini 004005a0 T __libc_csu_init U __libc_start_main@@GLIBC_2.2.5 00600940 A _edata 00600950 A _end 0040066c T _fini 00400460 T _init 004004a4 T _start 004004d0 t call_gmon_start 00600940 b completed.5822 00600930 W data_start 00600948 b dtor_idx.5824 00400560 t frame_dummy 004004a0 T main With gold I get: 00401720 d _DYNAMIC 004018f8 d _GLOBAL_OFFSET_TABLE_ 0040063c R _IO_stdin_used w _Jv_RegisterClasses w _ZTI1S w _ZTS1S v _ZTVN10__cxxabiv117__class_type_infoE U _ZdlPv 00401930 d __CTOR_END__ 00401928 d __CTOR_LIST__ 00401940 d __DTOR_END__ 00401938 d __DTOR_LIST__ 004006d8 r __FRAME_END__ 00401948 d __JCR_END__ 00401948 d __JCR_LIST__ 00401950 A __bss_start 00401918 D __data_start 00400600 t __do_global_ctors_aux 004004b0 t __do_global_dtors_aux 00401920 d __dso_handle w __gmon_start__ a __init_array_end a __init_array_start 00400560 T __libc_csu_fini 00400570 T __libc_csu_init U __libc_start_main 00401950 A _edata 00401960 A _end 00400658 T _fini 00400640 T _init 00400460 T _start 0040048c t call_gmon_start 00401950 b completed.5822 00401918 W data_start 00401958 b dtor_idx.5824 00400520 t frame_dummy 00400550 T main I think both linker are buggy to insert those entries into final symbol table when they are not appearing in the output from the linker plugin. Closing this as GCC bug and will fill it in as linker PR.
[Bug lto/47183] Please discard unused functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47183 --- Comment #4 from Jan Hubicka hubicka at gcc dot gnu.org 2011-01-05 22:51:36 UTC --- http://sourceware.org/bugzilla/show_bug.cgi?id=12370 now tracks the gold problem http://sourceware.org/bugzilla/show_bug.cgi?id=12369 now tracks the GNU LD problem.
[Bug tree-optimization/46021] 3 tree-ssa tests XPASS almost everywhere
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46021 Ulrich Weigand uweigand at gcc dot gnu.org changed: What|Removed |Added Target|i386-pc-solaris2.*, |i386-pc-solaris2.*, |sparc-sun-solaris2.*, |sparc-sun-solaris2.*, |alpha-dec-osf5.1b, |alpha-dec-osf5.1b, |mips-sgi-irix6.5|mips-sgi-irix6.5, spu-elf CC||uweigand at gcc dot gnu.org --- Comment #4 from Ulrich Weigand uweigand at gcc dot gnu.org 2011-01-05 23:38:40 UTC --- gcc.dg/tree-ssa/20040204-1.c XPASSes on spu-elf as well ...
[Bug c/47146] Floating point to integer conversions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47146
--- Comment #6 from Pierre Innocent babelart at yahoo dot com 2011-01-06
03:17:01 UTC ---
Daer Kargl,
Thanks, my mistake !
The C99 tests failures may be due to non-athlon specific code.
Still checking !
Regards,
Pierre Innocent
--- On Mon, 1/3/11, sgk at troutmask dot apl.washington.edu
gcc-bugzi...@gcc.gnu.org wrote:
From: sgk at troutmask dot apl.washington.edu gcc-bugzi...@gcc.gnu.org
Subject: [Bug c/47146] Floating point to integer conversions
To: babel...@yahoo.com
Received: Monday, January 3, 2011, 1:01 PM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47146
--- Comment #5 from Steve Kargl sgk at troutmask dot
apl.washington.edu 2011-01-03 18:01:11 UTC ---
On Mon, Jan 03, 2011 at 05:12:10PM +, babelart at yahoo
dot com wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47146
Sorry, I was not specific enough. It is the integer
conversion that seem
to be wrong,for example the following two lines:
fprintf( stdout, Float 100.0 * 0.3894949=%d\n, 100.0
* elapsed );
fprintf( stdout, Float 100 * 0.3894949=%d\n, 100 *
elapsed );
both produce the value '-536870912'.
I also downloaded the C99 integer to float conversion
test code; and they
generated two many failures. I also believe the
compiler should round resulting
integer values when stripping decimals off.
Regards,
Pierre Innocent
Compile the code with -Wall and fix all the warnings.
#include stdio.h
int
main (void)
{
float elapsed;
elapsed = 0.3894949; /* Note, the
rhs is a double! */
printf(Float 100.0 * 0.3894949=%d\n,
100.0 * elapsed );
printf(Float 100 * 0.3894949=%d\n, 100
* elapsed );
return 0;
}
troutmask:kargl[208] cc -o z -Wall a.c
a.c: In function 'main':
a.c:7: warning: format '%d' expects type 'int', but
argument 2 has type
'double'
a.c:8: warning: format '%d' expects type 'int', but
argument 2 has type
'double'
Your printf statements are using the first 4 bytes of
the 8 byte double argument.
--
Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You reported the bug.
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #22 from Mark Mitchell mark at codesourcery dot com 2011-01-06 03:55:40 UTC --- On 1/5/2011 5:36 AM, hubicka at gcc dot gnu.org wrote: 40259 5.6000 cc1plus cc1plus lookup_field_1 I've looked at this, in the distant past. I don't think the routine itself is *very* low-hanging fruit; it's already using an inline log n algorithm to find a field in most cases, and I bet that's as good as a hash table since n is generally relatively small. But, maybe in most cases is wrong; there is a slow-path, and we should confirm that most of the time is in the fast-path code. We could also try a bit of memoization; I wouldn't be surprised if we often lookup x.y several times in a row. More often, when I've looked at this kind of thing, though, I've concluded that the problem was that we were calling the routine too often, rather than the routine itself was too slow. Quite possibly we could improve algorithms that are using lookup_field_1 so that they didn't do so as often, by building caches or otherwise. For that, we'd need to look at the callers of lookup_field_1. So, in summary, I'd recommend three things: * Split lookup_field_1 into its fast-path and slow-path code so that we can profile it and figure out which code is taking up most of the time. * Assuming it's fast-path code, look at the frequent callers and think about how to optimize them.
[Bug tree-optimization/47139] [4.6 Regression] ice in process_use, at tree-vect-stmts.c:290
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47139 --- Comment #4 from irar at gcc dot gnu.org 2011-01-06 07:34:28 UTC --- Author: irar Date: Thu Jan 6 07:34:24 2011 New Revision: 168535 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168535 Log: PR tree-optimization/47139 * tree-vect-loop.c (vect_is_simple_reduction_1): Check that only the last reduction value is used outside the loop. Update documentation. Added: trunk/gcc/testsuite/gcc.dg/vect/pr47139.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-loop.c
[Bug tree-optimization/47139] [4.6 Regression] ice in process_use, at tree-vect-stmts.c:290
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47139 Ira Rosen irar at il dot ibm.com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Ira Rosen irar at il dot ibm.com 2011-01-06 07:35:45 UTC --- Fixed.
[Bug other/47167] Performance regression in numerical code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47167 --- Comment #6 from Uros Bizjak ubizjak at gmail dot com 2011-01-06 07:38:11 UTC --- (In reply to comment #5) Some loop performance is very sensitive to code sizes. This change -mulpd%xmm10, %xmm2 +mulpd%xmm0, %xmm2 will impact loop size due to exta REX prefix. Adding nop (or several of them, FWIW) around changed mulpd insn does not affect the performance, so IMO it is not the loop layout that matters in this case.
