[Bug lto/47528] liblto_plugin.so not found should not to be an fatal error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47528 --- Comment #6 from Kai Tietz 2011-02-08 08:03:22 UTC --- Just out of interest. What binutils version you are using? As error message indicates that the ld tool doesn't recognize -plugin command.
[Bug lto/47225] [4.6 regression]: cross-compile fails while configuring libgcc with "xgcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47225 --- Comment #34 from Paolo Bonzini 2011-02-08 08:06:28 UTC --- Iain, the correct fix is to add -module to the LTO plugin LDFLAGS. This changes the extension from .dylib to .so.
[Bug lto/47528] liblto_plugin.so not found should not to be an fatal error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47528 --- Comment #7 from Dongsheng Song 2011-02-08 08:56:26 UTC --- The source of binutils for native compiler same as the cross building compiler, so I think this maybe an autotools bug of binutils: oracle@vc:~/vcs/git/binutils$ git log -1 commit c4773de8739c6155aa847c5ee80f1fa1437a656a Author: Alan Modra Date: Mon Feb 7 23:00:05 2011 + daily update
[Bug lto/47528] liblto_plugin.so not found should not to be an fatal error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47528 --- Comment #8 from Kai Tietz 2011-02-08 09:25:38 UTC --- Is binutils build using option '--enable-plugins'? It is worth a try. AFAICS is there in ld's configure.ac a quirk about the header-check windows.h. It uses here Windows.h, which can lead to troubles, if POSIX-like file-system is activated.
[Bug fortran/47642] New: real(kind=16) - libquadmath - segfault on amd64 FreeBSD
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47642 Summary: real(kind=16) - libquadmath - segfault on amd64 FreeBSD Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: me...@bristol.ac.uk BUZI> uname -a FreeBSD zzz 9.0-CURRENT FreeBSD 9.0-CURRENT #4 r217412: Fri Jan 14 22:09:57 GMT 2011 root@zzz:/usr/obj/usr/src/sys/BUZI amd64 BUZI> cat tmp.f90 program z implicit none real(kind=16) :: q q=1.0e48_16 write(*,*)q write(*,*)nearest(q,1.0) write(*,*)nearest(q,1.0)-q end program z BUZI> gfortran46 -Wl,-rpath=/usr/local/lib/gcc46 tmp.f90 BUZI> ./a.out 1.000E+0048 1.014E+0048 140737488355328. BUZI> This is fine, however, changing the constant to 1e38 gives segfault: BUZI> cat tmp.f90 program z implicit none real(kind=16) :: q q=1.0e38_16 write(*,*)q write(*,*)nearest(q,1.0) write(*,*)nearest(q,1.0)-q end program z BUZI> gfortran46 -Wl,-rpath=/usr/local/lib/gcc46 tmp.f90 BUZI> ./a.out 1.000E+0038 Segmentation fault (core dumped) BUZI> Same with 1e39: BUZI> cat tmp.f90 program z implicit none real(kind=16) :: q q=1.0e39_16 write(*,*)q write(*,*)nearest(q,1.0) write(*,*)nearest(q,1.0)-q end program z BUZI> gfortran46 -Wl,-rpath=/usr/local/lib/gcc46 tmp.f90 BUZI> ./a.out 1.000E+0039 Segmentation fault (core dumped) BUZI> Then 1e29 works correct again BUZI> cat tmp.f90 program z implicit none real(kind=16) :: q q=1.0e29_16 write(*,*)q write(*,*)nearest(q,1.0) write(*,*)nearest(q,1.0)-q end program z BUZI> gfortran46 -Wl,-rpath=/usr/local/lib/gcc46 tmp.f90 BUZI> ./a.out 10.0 10.2 1.52587890625E-0005 BUZI> >From debugger: BUZI> gdb a.out a.out.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols found)... Core was generated by `a.out'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/local/lib/gcc46/libgfortran.so.3...done. Loaded symbols for /usr/local/lib/gcc46/libgfortran.so.3 Reading symbols from /lib/libm.so.5...done. Loaded symbols for /lib/libm.so.5 Reading symbols from /usr/local/lib/gcc46/libgcc_s.so.1...done. Loaded symbols for /usr/local/lib/gcc46/libgcc_s.so.1 Reading symbols from /usr/local/lib/gcc46/libquadmath.so.0...done. Loaded symbols for /usr/local/lib/gcc46/libquadmath.so.0 Reading symbols from /lib/libc.so.7...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x0008010ba0ae in memset () from /lib/libc.so.7 (gdb) (gdb) bt #0 0x0008010ba0ae in memset () from /lib/libc.so.7 #1 0x000800d98a27 in quadmath_flt128tostr (s=0x7fffd250 '0' ..., size=47, n=37, x=Variable "x" is not available. ) at ../.././../gcc-4.6-20110205/libquadmath/quadmath_io.c:95 #2 0x3030303030303030 in ?? () #3 0x3030303030303030 in ?? () #4 0x3030303030303030 in ?? () #5 0x3030303030303030 in ?? () #6 0x3030303030303030 in ?? () #7 0x3030303030303030 in ?? () *skip lots of identical lines* #968 0x3030303030303030 in ?? () #969 0x3030303030303030 in ?? () #970 0x3030303030303030 in ?? () #971 0x3030303030303030 in ?? () #972 0x3030303030303030 in ?? () #973 0x3030303030303030 in ?? () ---Type to continue, or q to quit--- #974 0x3030303030303030 in ?? () Cannot access memory at address 0x7000 (gdb)
[Bug lto/47225] [4.6 regression]: cross-compile fails while configuring libgcc with "xgcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47225
--- Comment #35 from Iain Sandoe 2011-02-08 09:56:08
UTC ---
(In reply to comment #34)
> the correct fix is to add -module to the LTO plugin LDFLAGS. This changes the
> extension from .dylib to .so.
Thanks, I suppose the intention of the other entry is really for hosts that
want to change the base-name of the plugin? (that wasn't 100% clear to me from
the comment in gcc/config.host).
anyway, something like this?
Index: lto-plugin/configure.ac
===
--- lto-plugin/configure.ac(revision 169878)
+++ lto-plugin/configure.ac(working copy)
@@ -9,6 +9,13 @@ AC_SYS_LARGEFILE
AM_PROG_LIBTOOL
ACX_LT_HOST_FLAGS
AC_SUBST(target_noncanonical)
+case "${host}" in
+ *-darwin*)
+# Darwin needs -module to produce a dylib with .so suffix
+extra_ldflags_lto_plugin='-module'
+;;
+esac
+AC_SUBST(extra_ldflags_lto_plugin)
AC_TYPE_INT64_T
AC_TYPE_UINT64_T
AC_HEADER_SYS_WAIT
Index: lto-plugin/Makefile.am
===
--- lto-plugin/Makefile.am(revision 169878)
+++ lto-plugin/Makefile.am(working copy)
@@ -11,6 +11,8 @@ AM_CPPFLAGS = -I$(top_srcdir)/../include $(DEFS)
AM_CFLAGS = -Wall -Werror
AM_LIBTOOLFLAGS = --tag=disable-static
+extra_ldflags_lto_plugin = @extra_ldflags_lto_plugin@
+
libexecsub_LTLIBRARIES = liblto_plugin.la
liblto_plugin_la_SOURCES = lto-plugin.c
@@ -18,6 +20,7 @@ liblto_plugin_la_LIBADD = \
$(if $(wildcard
../libiberty/pic/libiberty.a),../libiberty/pic/libiberty.a,)
# Note that we intentionally override the bindir supplied by ACX_LT_HOST_FLAGS
liblto_plugin_la_LDFLAGS = $(lt_host_flags) -bindir $(libexecsubdir) \
+$(extra_ldflags_lto_plugin) \
$(if $(wildcard
../libiberty/pic/libiberty.a),,-Wc,../libiberty/libiberty.a)
all: copy_lto_plugin
[Bug lto/47225] [4.6 regression]: cross-compile fails while configuring libgcc with "xgcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47225 --- Comment #36 from Paolo Bonzini 2011-02-08 10:00:41 UTC --- No, it should be added for all targets.
[Bug lto/47528] liblto_plugin.so not found should not to be an fatal error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47528 --- Comment #9 from Dongsheng Song 2011-02-08 10:04:25 UTC --- Thanks, with the following patch (Windows.h => windows.h), the building OK now: $ git diff ld/configure.in ld/plugin.c diff --git a/ld/configure.in b/ld/configure.in index 2836545..bd5040e 100644 --- a/ld/configure.in +++ b/ld/configure.in @@ -173,7 +173,7 @@ AC_SEARCH_LIBS([dlopen],[dl],[],[enable_plugins=no],[]) AC_CHECK_FUNCS([dlopen dlsym dlclose],[],[enable_plugins=no]) # We also support plugins on Windows (MinGW). if test x$enable_plugins = xno ; then - AC_CHECK_HEADERS([Windows.h],[enable_plugins=yes],[],[AC_INCLUDES_DEFAULT]) + AC_CHECK_HEADERS([windows.h],[enable_plugins=yes],[],[AC_INCLUDES_DEFAULT]) fi AM_CONDITIONAL([ENABLE_PLUGINS], [test x$enable_plugins = xyes]) diff --git a/ld/plugin.c b/ld/plugin.c index b285787..8631d25 100644 --- a/ld/plugin.c +++ b/ld/plugin.c @@ -33,7 +33,7 @@ #include "plugin-api.h" #include "elf-bfd.h" #if !defined (HAVE_DLFCN_H) && defined (HAVE_WINDOWS_H) -#include +#include #endif /* The suffix to append to the name of the real (claimed) object file
[Bug lto/47225] [4.6 regression]: cross-compile fails while configuring libgcc with "xgcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47225 --- Comment #37 from Iain Sandoe 2011-02-08 10:10:21 UTC --- (In reply to comment #36) > No, it should be added for all targets. so.. Index: lto-plugin/Makefile.am === --- lto-plugin/Makefile.am(revision 169878) +++ lto-plugin/Makefile.am(working copy) @@ -17,7 +17,7 @@ liblto_plugin_la_SOURCES = lto-plugin.c liblto_plugin_la_LIBADD = \ $(if $(wildcard ../libiberty/pic/libiberty.a),../libiberty/pic/libiberty.a,) # Note that we intentionally override the bindir supplied by ACX_LT_HOST_FLAGS -liblto_plugin_la_LDFLAGS = $(lt_host_flags) -bindir $(libexecsubdir) \ +liblto_plugin_la_LDFLAGS = $(lt_host_flags) -module -bindir $(libexecsubdir) \ $(if $(wildcard ../libiberty/pic/libiberty.a),,-Wc,../libiberty/libiberty.a) all: copy_lto_plugin
[Bug tree-optimization/47639] [4.5/4.6 Regression] ICE: verify_stmts failed: statement marked for throw, but doesn't with -fstack-check=generic -fexceptions -fnon-call-exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47639 Richard Guenther changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | --- Comment #2 from Richard Guenther 2011-02-08 10:18:21 UTC --- Well. Mine then.
[Bug lto/47641] gcc.dg/lto/20101009-1 c_lto_20101009-1_0.o-c_lto_20101009-1_0.o link ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47641 Richard Guenther changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | --- Comment #3 from Richard Guenther 2011-02-08 10:20:23 UTC --- Mine.
[Bug lto/47528] liblto_plugin.so not found should not to be an fatal error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47528 Kai Tietz changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED --- Comment #10 from Kai Tietz 2011-02-08 10:25:31 UTC --- Ok, so I close this bug as fixed. Please sent patch to binutils ML. Thanks, Kai
[Bug target/47643] New: x86 -mtune docs still imply i386 is the default for codegen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47643 Summary: x86 -mtune docs still imply i386 is the default for codegen Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: documentation Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org Target: i386-* At http://gcc.gnu.org/onlinedocs/gcc/i386-and-x86_002d64-Options.html the docs for -mtune still say: "the compiler will not generate any code that does not run on the i386 without the -march=cpu-type option being used." Now that the default -march is implied by the target it's likely that generated code will not run on i386 even when there is no -march used on the command line or --with-arch used in the configure command. The manual should be changed to make that clear. Maybe something like: "the compiler will not generate any code that does not run on the default target architecture without the -march=cpu-type option being used (where the default target arch is determined from the target triplet e.g. i686-pc-linux-gnu)."
[Bug fortran/47642] real(kind=16) - libquadmath - segfault on amd64 FreeBSD
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47642 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.02.08 10:40:46 Ever Confirmed|0 |1 --- Comment #1 from Dominique d'Humieres 2011-02-08 10:40:46 UTC --- I also see it on x86_64-unknown-linux-gnu and x86_64-apple-darwin10.6.0. As shown by the following test, there is a bus error for the exponents is the range 127 to 142 (I did not check exponents above 200;-): program z implicit none integer ::i real(kind=16) :: q do i=1,126 q=2.0_16**i write(*,*)i,q end do do i=200,143,-1 q=2.0_16**i write(*,*)i,q end do !write(*,*)'127' !q=2.0_16**127 !write(*,*)i,q write(*,*)'142' q=2.0_16**142 write(*,*)i,q end program z
[Bug tree-optimization/47632] [4.6 Regression] ICE: verify_flow_info failed: BB 4 can not throw but has an EH edge with -fnon-call-exceptions -ftrapv and operator new[]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47632 --- Comment #3 from Richard Guenther 2011-02-08 10:44:12 UTC --- Author: rguenth Date: Tue Feb 8 10:44:06 2011 New Revision: 169917 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169917 Log: 2011-02-08 Richard Guenther PR tree-optimization/47632 * tree-ssa-forwprop.c (remove_prop_source_from_use): Remove unused up_to_stmt parameter, return whether cfg-cleanup is necessary, remove EH info properly. (forward_propagate_into_gimple_cond): Adjust caller. (forward_propagate_into_cond): Likewise. (forward_propagate_comparison): Likewise. (tree_ssa_forward_propagate_single_use_vars): Make forward_propagate_comparison case similar to the two others. * g++.dg/opt/pr47632.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/opt/pr47632.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-forwprop.c
[Bug target/47324] g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47324 --- Comment #13 from Jack Howarth 2011-02-08 10:45:31 UTC --- The audit trail is a little fuzzy here but it seems like this wasn't present at r137753 but was at r138906 for -m32 on i686-apple-darwin9. We also had PR37012 opened for this at one point.
[Bug tree-optimization/47632] [4.6 Regression] ICE: verify_flow_info failed: BB 4 can not throw but has an EH edge with -fnon-call-exceptions -ftrapv and operator new[]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47632 Richard Guenther changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Richard Guenther 2011-02-08 10:47:34 UTC --- Fixed.
[Bug target/47324] g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47324
--- Comment #14 from mrs at gcc dot gnu.org 2011-02-08
10:50:43 UTC ---
157762 seems to have new code that outputs a dwarf register number without
going though DWARF2_FRAME_REG_OUT which I think is wrong.
I fixed that and played around for a bit, the closest I could come up with was
something like the below... but I'm certain it is wrong. :-( We need someone
to puzzle over the dwarf/stabs/unwind/eh_frame debug info and come up with the
right solution. Also, at lower optimizations the test still failed.
I'm wondering if we are even wondering around in the right area yet.
Index: dwarf2out.c
===
--- dwarf2out.c(revision 169905)
+++ dwarf2out.c(working copy)
@@ -474,7 +474,7 @@
static void dwarf2out_frame_debug_expr (rtx, const char *);
/* Support for complex CFA locations. */
-static void output_cfa_loc (dw_cfi_ref);
+static void output_cfa_loc (dw_cfi_ref, bool);
static void output_cfa_loc_raw (dw_cfi_ref);
static void get_cfa_from_loc_descr (dw_cfa_location *,
struct dw_loc_descr_struct *);
@@ -3317,7 +3317,7 @@
case DW_CFA_def_cfa_expression:
case DW_CFA_expression:
- output_cfa_loc (cfi);
+ output_cfa_loc (cfi, for_eh);
break;
case DW_CFA_GNU_negative_offset_extended:
@@ -5451,14 +5451,16 @@
description based on a cfi entry with a complex address. */
static void
-output_cfa_loc (dw_cfi_ref cfi)
+output_cfa_loc (dw_cfi_ref cfi, bool for_eh)
{
+ unsigned long r;
dw_loc_descr_ref loc;
unsigned long size;
if (cfi->dw_cfi_opc == DW_CFA_expression)
{
- dw2_asm_output_data (1, cfi->dw_cfi_oprnd1.dw_cfi_reg_num, NULL);
+ r = DWARF2_FRAME_REG_OUT (cfi->dw_cfi_oprnd1.dw_cfi_reg_num, for_eh);
+ dw2_asm_output_data (1, r, NULL);
loc = cfi->dw_cfi_oprnd2.dw_cfi_loc;
}
else
Index: config/i386/darwin.h
===
--- config/i386/darwin.h(revision 169905)
+++ config/i386/darwin.h(working copy)
@@ -252,17 +252,12 @@
#undef DBX_REGISTER_NUMBER
#define DBX_REGISTER_NUMBER(n) \
(TARGET_64BIT ? dbx64_register_map[n]\
- : write_symbols == DWARF2_DEBUG ? svr4_dbx_register_map[n]\
- : dbx_register_map[n])
+ : darwin_dbx_register_number(n))
/* Unfortunately, the 32-bit EH information also doesn't use the standard
DWARF register numbers. */
#define DWARF2_FRAME_REG_OUT(n, for_eh)\
- (! (for_eh) || write_symbols != DWARF2_DEBUG || TARGET_64BIT ? (n)\
- : (n) == 5 ? 4\
- : (n) == 4 ? 5\
- : (n) >= 11 && (n) <= 18 ? (n) + 1\
- : (n))
+ darwin_dwarf2_frame_reg_out (n, for_eh)
#undef REGISTER_SUBTARGET_PRAGMAS
#define REGISTER_SUBTARGET_PRAGMAS() DARWIN_REGISTER_TARGET_PRAGMAS()
Index: config/darwin.c
===
--- config/darwin.c(revision 169905)
+++ config/darwin.c(working copy)
@@ -3094,4 +3094,47 @@
fputs (":\n", fp);
}
+static bool
+darwin_will_use_eh ()
+{
+ if ()
+return true;
+ return 0;
+}
+
+int
+darwin_dbx_register_number(n)
+{
+#if 1
+ /* Without -O3, eh-alloc-1.c -m32 fails. */
+ /* Works! */
+ if (write_symbols == DWARF2_DEBUG && !dwarf2out_do_frame())
+return svr4_dbx_register_map[n];
+#else
+ /* Works! */
+ if (!(write_symbols == DWARF2_DEBUG
+|| write_symbols == NO_DEBUG))
+return svr4_dbx_register_map[n];
+#endif
+ return dbx_register_map[n];
+}
+
+int
+darwin_dwarf2_frame_reg_out (n, for_eh)
+{
+ if (! (for_eh)
+ /* WTF, if we are doing this for_eh, and the eh uses the pre-svr4
numbers, then
+ we must convert the svr4 numbers back. */
+ || (write_symbols != DWARF2_DEBUG, 0)
+ || TARGET_64BIT)
+return n;
+ if (n == 5)
+return 4;
+ if (n == 4)
+return 5;
+ if (n >= 11 && n <= 18)
+return n + 1;
+ return n;
+}
+
#include "gt-darwin.h"
[Bug target/47324] g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47324 --- Comment #15 from Jack Howarth 2011-02-08 10:57:38 UTC --- These probably were failing since added here... http://gcc.gnu.org/ml/gcc-patches/2008-07/msg00647.html
[Bug lto/47528] liblto_plugin.so not found should not to be an fatal error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47528 --- Comment #11 from Dongsheng Song 2011-02-08 11:04:32 UTC --- I don't known where I report the following issue: C:\>gcc -O2 -pipe Hello.c C:\>a Hello, World! C:\>gcc -O2 -pipe -flto Hello.c c:/gcc-4.6-windows/bin/../lib/gcc/i686-w64-mingw32/4.6.0/../../../../i686-w64-mingw32/bin/ld.exe: could not unlink output file collect2: ld returned 1 exit status
[Bug lto/47528] liblto_plugin.so not found should not to be an fatal error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47528 --- Comment #12 from Kai Tietz 2011-02-08 11:14:09 UTC --- (In reply to comment #11) > I don't known where I report the following issue: > > C:\>gcc -O2 -pipe Hello.c > > C:\>a > Hello, World! > > C:\>gcc -O2 -pipe -flto Hello.c > c:/gcc-4.6-windows/bin/../lib/gcc/i686-w64-mingw32/4.6.0/../../../../i686-w64-mingw32/bin/ld.exe: > could not unlink output file > collect2: ld returned 1 exit status There is already a bug report. See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47241
[Bug target/47617] SSE rounding mode works -g, not -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47617 --- Comment #7 from Richard Guenther 2011-02-08 11:35:32 UTC --- Well, this case is slightly different as we simply have const/pure builtins that do not only depend on their arguments (but the FP state). Thus we'd need to trop the attributes from these functions for -frounding-math. Not that it would help a lot, given PR34678 ...
[Bug libffi/46661] 32-bit cls_pointer.c, cls_pointer_stack.c FAIL on IRIX 6.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46661 Rainer Orth changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2011-02/msg00531.htm ||l Last reconfirmed||2011.02.08 11:36:42 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 2011-02-08 11:36:42 UTC --- Mine, patch posted.
[Bug c/47644] New: [avr] Regression in choosing registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47644
Summary: [avr] Regression in choosing registers
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kip.hi...@gmail.com
Created attachment 23275
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23275
Test case in C
Consider the following snippet compiled with -O3:
int lsl_short(int f) {
return f << 1;
}
gcc 4.3.3 is copying the value from r25:r24 (first parameter) to r19:r18, then
moving back to r25:r24 (return value). Same for longs but with 4 registers.
Expected:
The lsl and rol should happen directly on r25:r24, just as they did in 4.2
[Bug c/47644] [avr] Optimisation regression in choosing registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47644 --- Comment #1 from Ángel 2011-02-08 11:47:46 UTC --- Created attachment 23276 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23276 gcc 4.3.3 assembler
[Bug c/47644] [avr] Optimisation regression in choosing registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47644 --- Comment #2 from Ángel 2011-02-08 11:48:37 UTC --- Created attachment 23277 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23277 gcc 4.2 assembler
[Bug tree-optimization/47639] [4.5/4.6 Regression] ICE: verify_stmts failed: statement marked for throw, but doesn't with -fstack-check=generic -fexceptions -fnon-call-exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47639
--- Comment #3 from Richard Guenther 2011-02-08
12:09:09 UTC ---
Ugh. We lower
[LP 1] D.2691_8 = v1_6(D) / v2_7(D);
to
D.2699_13 = BIT_FIELD_REF ;
D.2700_14 = BIT_FIELD_REF ;
D.2701_15 = D.2699_13 / D.2700_14;
D.2702_16 = BIT_FIELD_REF ;
D.2703_17 = BIT_FIELD_REF ;
D.2704_18 = D.2702_16 / D.2703_17;
[LP 1] D.2691_8 = {D.2701_15, D.2704_18};
now the most ugly part of that is we construct a big tree with
the CONSTRUCTOR and then feed that to force_gimple_operand ...
What I did in the patch that caused this is to make
{D.2701_15, D.2704_18} not throw - which exposes this bug.
We can hide this issue again by properly clearing EH info on
the CONSTRUCTOR statement, leaving the issue alone that we'd
really need to move EH info to the piecewise computations,
split the block, add new EH edges, etc.
Not worthwhile for stage4 and not a regression.
C++ testcase that fails with -fnon-call-exceptions only:
typedef int __attribute__ ((vector_size (8))) vec;
vec foo (vec v1, vec v2)
{
try
{
return v1 / v2;
}
catch (...)
{
throw;
}
}
[Bug middle-end/47645] New: Generic vector lowering does not preserve EH information
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47645
Summary: Generic vector lowering does not preserve EH
information
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org
typedef int __attribute__ ((vector_size (8))) vec;
vec foo (vec v1, vec v2)
{
try
{
return v1 / v2;
}
catch (...)
{
throw;
}
}
will be lowered to piecewise operations that do not throw and have no
EH landing pad associated (and blocks not split, etc.).
Split out from PR47639 where this issue uncovers as an ICE.
The vector lowering code needs some re-org to properly transition
EH info. This bug isn't a regression.
[Bug bootstrap/45381] [4.6 Regression] Bootstrap failure for powerpc-apple-darwin9: error: AltiVec argument passed to unprototyped function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45381 Iain Sandoe changed: What|Removed |Added CC||iains at gcc dot gnu.org --- Comment #8 from Iain Sandoe 2011-02-08 12:17:28 UTC --- what was the reason that the patch at comment #1 was not acceptable? If the builtins were not available prior to 4.0.5, then the caveat seems sensible ... I must be missing something ;) === if not, for all darwin 8 & 9 the system compiler is 4.0.1 (3.3 for darwin 7, and I doubt trunk builds for earlier than that) 4.2.1 is not available on darwin 8 (so I'd imagine that bootstrap is broken there without a ready workaround). I don't have a ppc darwin 8 box available right now - although I will try to crank one up before 4.6 forks. I could not find a permutation of installed headers that gave the right result - perhaps looking in the wrong place. Do we want to pursue this further - or just accept a slower solution for the (legacy) darwin versions?
[Bug libfortran/47567] Wrong output for small absolute values with F editing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47567 --- Comment #14 from Jerry DeLisle 2011-02-08 12:36:19 UTC --- OK, thanks for spotting that. I will have a look.
[Bug fortran/47642] real(kind=16) - libquadmath - segfault on amd64 FreeBSD
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47642 Jerry DeLisle changed: What|Removed |Added Status|NEW |ASSIGNED CC||jvdelisle at gcc dot ||gnu.org AssignedTo|unassigned at gcc dot |jvdelisle at gcc dot |gnu.org |gnu.org --- Comment #2 from Jerry DeLisle 2011-02-08 12:40:48 UTC --- Looks like this is IO related so will have a look.
[Bug fortran/47642] real(kind=16) - libquadmath - segfault on amd64 FreeBSD
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47642
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek 2011-02-08
12:50:44 UTC ---
size_t l = c - p;
memcpy (res + 3, p + 1, l);
size_t l2 = strlen (c + 1);
memcpy (res + 2 + l, c + 1, l2);
memset (res + 2 + l + l2, '0', n - (l + l2) + 1);
p is "174224571863520493293247799005065324265470", thus l is 42, l2 is 0
and n - (l + l2) + 1 is -1.
quadmath_io.c has more issues though, e.g.
void
quadmath_flt128tostr (char *s, size_t size, size_t n, __float128 x)
{
char buffer[1024];
memset (buffer, 0, sizeof(buffer));
format (buffer, x, n);
memcpy (s, buffer, size);
}
will happily copy garbage over for size > 1024, other buffer overflows will
happen for n > 1024 - epsilon, etc. and there is no reason why we need so many
extra buffers. At least the one in quadmath_flt128tostr doesn't make sense,
size should be simply passed through down to format and it should make sure it
never overflows the given size. The other memset in format:
memset (buffer, 0, sizeof(buffer));
should be avoided too, I believe g_Qfmt should return the pointer after the
last character it wrote, or NULL, so for NULL the caller should just clear
buffer[0] and for other value it should clear *g_Qfmt.
[Bug lto/47641] gcc.dg/lto/20101009-1 c_lto_20101009-1_0.o-c_lto_20101009-1_0.o link ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47641 --- Comment #4 from Richard Guenther 2011-02-08 12:53:53 UTC --- Author: rguenth Date: Tue Feb 8 12:53:50 2011 New Revision: 169925 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169925 Log: 2011-02-08 Richard Guenther PR tree-optimization/47641 * tree-ssa.c (execute_update_addresses_taken): For asm outputs require type compatibility. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa.c
[Bug lto/47641] gcc.dg/lto/20101009-1 c_lto_20101009-1_0.o-c_lto_20101009-1_0.o link ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47641 Richard Guenther changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 --- Comment #5 from Richard Guenther 2011-02-08 12:54:30 UTC --- Fixed.
[Bug fortran/47642] real(kind=16) - libquadmath - segfault on amd64 FreeBSD
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47642 --- Comment #4 from Jerry DeLisle 2011-02-08 13:00:49 UTC --- Jakub, if you have time to fix this, please do. It may take me several days to get to this because of time constraints.
[Bug tree-optimization/45978] [4.6 Regression] bogus "array subscript is above array bounds" warning in extremely simple code with no loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45978
Richard Guenther changed:
What|Removed |Added
Priority|P3 |P2
--- Comment #3 from Richard Guenther 2011-02-08
13:37:48 UTC ---
Something like
Index: gimple-fold.c
===
--- gimple-fold.c (revision 169917)
+++ gimple-fold.c (working copy)
@@ -212,6 +212,7 @@ maybe_fold_offset_to_array_ref (location
tree min_idx, idx, idx_type, elt_offset = integer_zero_node;
tree array_type, elt_type, elt_size;
tree domain_type;
+ tree no_warning = false;
/* If BASE is an ARRAY_REF, we can pick up another offset (this time
measured in units of the size of elements type) from that ARRAY_REF).
@@ -308,26 +309,34 @@ maybe_fold_offset_to_array_ref (location
char *(c[4]);
c[3][2];
should not be simplified into (*c)[14] or tree-vrp will
- give false warnings.
- This is only an issue for multi-dimensional arrays. */
- if (TREE_CODE (elt_type) == ARRAY_TYPE
- && domain_type)
+ give false warnings. For multi-dimensional arrays
+ avoid this transformation, for one-dimensional arrays
+ set TREE_NO_WARNING on out-of-bound references. */
+ if (domain_type)
{
+ bool oob = false;
if (TYPE_MAX_VALUE (domain_type)
&& TREE_CODE (TYPE_MAX_VALUE (domain_type)) == INTEGER_CST
&& tree_int_cst_lt (TYPE_MAX_VALUE (domain_type), idx))
- return NULL_TREE;
+ oob = true;
else if (TYPE_MIN_VALUE (domain_type)
&& TREE_CODE (TYPE_MIN_VALUE (domain_type)) == INTEGER_CST
&& tree_int_cst_lt (idx, TYPE_MIN_VALUE (domain_type)))
- return NULL_TREE;
+ oob = true;
else if (compare_tree_int (idx, 0) < 0)
+ oob = true;
+ if (oob)
+ {
+ if (TREE_CODE (elt_type) == ARRAY_TYPE)
return NULL_TREE;
+ no_warning = true;
+ }
}
{
tree t = build4 (ARRAY_REF, elt_type, base, idx, NULL_TREE, NULL_TREE);
SET_EXPR_LOCATION (t, loc);
+TREE_NO_WARNING (t) = no_warning;
return t;
}
}
fixes this but will cause us to omit all warnings for C array accesses
that are out-of-bounds:
FAIL: gcc.dg/Warray-bounds.c (test for warnings, line 59)
FAIL: gcc.dg/Warray-bounds.c (test for warnings, line 60)
FAIL: gcc.dg/Warray-bounds.c (test for warnings, line 65)
FAIL: gcc.dg/Warray-bounds.c (test for warnings, line 66)
FAIL: gcc.dg/Warray-bounds.c (test for warnings, line 72)
FAIL: gcc.dg/Warray-bounds.c (test for warnings, line 73)
In general I'd say we should not warn from VRP after loop opts, and
for address-taking operations we should have a distinct warning,
eventually looking at object sizes, not only type bounds.
This bug is a regression only because we now vectorize the testcase to
xorps %xmm0, %xmm0
movq%rdi, %rax
movlps %xmm0, (%rdi)
movhps %xmm0, 8(%rdi)
movlps %xmm0, 16(%rdi)
movlps %xmm0, 24(%rdi)
compared to
xorl%edx, %edx
movq%rdi, %rax
movl%edx, (%rdi)
movl%edx, 4(%rdi)
movl%edx, 8(%rdi)
movl%edx, 12(%rdi)
movl%edx, 16(%rdi)
movl%edx, 20(%rdi)
movl%edx, 24(%rdi)
movl%edx, 28(%rdi)
which is a good thing.
Eventually we can mitigate the problem from inside the vectorizer by
not using
vect_p.7_13 = &MEM[(struct Y *)&].ar[0];
but instead
vect_p.7_13 = & + off
style initial addresses. Unfortunately that isn't very easy to do.
[Bug c++/46394] [C++0X] [4.6 Regression] no matching function with default template parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46394 Richard Guenther changed: What|Removed |Added Keywords||rejects-valid Priority|P3 |P1
[Bug tree-optimization/46728] GCC does not generate fmadd for pow (x, 0.75)+y on powerpc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46728 Richard Guenther changed: What|Removed |Added Keywords||missed-optimization Target Milestone|4.6.0 |--- Summary|[4.6 Regression] GCC no |GCC does not generate fmadd |longer generates fmadd for |for pow (x, 0.75)+y on |pow (x, 0.75)+y on powerpc |powerpc Severity|normal |enhancement --- Comment #3 from Richard Guenther 2011-02-08 13:44:51 UTC --- I had patches for powi expansion I think 6 years ago but they were rejected (fortunately I can now approve them myself). We should expose most of this lowering to the vectorizer as it can vectorize sqrt and multiplication series while it cannot vectorize pow or powi in general (it tries for some special cases via the sucky pattern recognition). Not a regression, no compiler was released with the fancy pow (x, 0.75) + y handling.
[Bug middle-end/46790] [4.6 regression] EH failures in libstdc++ testsuite with --gc-sections and GNU ld 2.18
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46790 Richard Guenther changed: What|Removed |Added Priority|P3 |P1 --- Comment #4 from Richard Guenther 2011-02-08 13:49:17 UTC --- So it's really a linker bug. Can we detect it at configure time and turn off the fancy renaming? If we do not fix this bug we should document this issue in changes.html and adjust the minimum required binutils version in doc/install.texi (some very ancient versions seem to be mentioned there, and no target-independent minimal version is suggested). Marking P1 to force some kind of solution before the release.
[Bug tree-optimization/46886] [4.5/4.6 Regression] gfortran.dg/array_constructor_9.f90 FAILs with -ftree-parallelize-loops -fstrict-overflow -fno-tree-ch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46886 Richard Guenther changed: What|Removed |Added Priority|P3 |P2
[Bug c++/47049] [C++0x] ICE in write_unnamed_type_name with lambda use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47049 Richard Guenther changed: What|Removed |Added Keywords||ice-on-valid-code Target Milestone|4.5.3 |--- Summary|[4.5/4.6 Regression]|[C++0x] ICE in |[C++0x] ICE in |write_unnamed_type_name |write_unnamed_type_name |with lambda use |with lambda use | Known to fail||4.5.0, 4.5.1, 4.5.2, 4.6.0 --- Comment #11 from Richard Guenther 2011-02-08 13:55:21 UTC --- Hm, this doesn't seem to be a regression. lambda is not supported in GCC 4.4, GCC 4.5.x ICE the same way as trunk. So, what version works for you (some unreleased SVN rev does not count, such a regression is not percieved as such from a users POV)? Unmarking as regression.
[Bug c++/47049] [C++0x] ICE in write_unnamed_type_name with lambda use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47049 --- Comment #12 from Jakub Jelinek 2011-02-08 13:58:17 UTC --- It is a regression in the sense that e.g. the #c10 testcase with 4.4 resulted in a bunch of errors, but not an ICE, while it ICEs in 4.6.
[Bug middle-end/47092] [4.6 Regression] gfortran.fortran-torture/execute/forall_4.f90 is VERY slow with -fgraphite-identity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47092 Richard Guenther changed: What|Removed |Added Priority|P3 |P2 Status|UNCONFIRMED |NEW Last reconfirmed||2011.02.08 14:00:31 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther 2011-02-08 14:00:31 UTC --- Confirmed.
[Bug fortran/47642] real(kind=16) - libquadmath - segfault on amd64 FreeBSD
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47642
--- Comment #5 from Jakub Jelinek 2011-02-08
14:04:23 UTC ---
The question is how accurrate we expect the n argument to be (e.g. for
#include
int
main (void)
{
char buf[1024];
int i;
__float128 f;
for (i = 1, f = 2; i <= 256; i++, f *= 2)
quadmath_flt128tostr (buf, sizeof (buf), 40, f);
return 0;
}
before this ICE g_Qfmt will happily return a string with 42 digits (i.e. 41
digits after decimal point) and the various adjustments format does can e.g.
use just zeros instead of the digits that g_Qfmt could have computed but did
not.
Does anyone have confidence in gdtoa QoI? I'd personally feel much safer by
just copying over and editting glibc stdio-common/printf_fp.c than fixing up
gdtoa.
[Bug bootstrap/47243] [4.6 Regression] Bootstrap fails: Segfault of genmddeps / COLLECT bug?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47243 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011.02.08 14:05:51 Ever Confirmed|0 |1 --- Comment #7 from Richard Guenther 2011-02-08 14:05:51 UTC --- I can't reproduce it (neither with nor without -flto). Please specify your target, your binutils version and how you configured GCC. Or close the bug if it no longer reproduces for you.
[Bug c++/47326] [4.4/4.5/4.6 Regression] ICE in tsubst_copy (triggered by dependency of return type on parameter pack size)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47326 Richard Guenther changed: What|Removed |Added Priority|P3 |P2 --- Comment #6 from Richard Guenther 2011-02-08 14:13:31 UTC --- Calling this a regression is interesting. GCC 4.3 rejects the code: > /space/rguenther/install/gcc-4.3.5/bin/g++ -S t.ii -std=c++0x ../src/simple-tests/bug-gcc-ICE-return_type_depends_on_variadic_size.cpp:7: error: expected initializer before '->' token ../src/simple-tests/bug-gcc-ICE-return_type_depends_on_variadic_size.cpp: In function 'int main()': ../src/simple-tests/bug-gcc-ICE-return_type_depends_on_variadic_size.cpp:12: error: 'f' was not declared in this scope it remains to be stated whether the code is valid or not, ICEing instead of rejecting it is a regression.
[Bug middle-end/45505] [4.6 Regression] gfortran.dg/pr25923.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45505 Martin Jambor changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jamborm at gcc dot gnu.org |gnu.org | --- Comment #19 from Martin Jambor 2011-02-08 14:15:53 UTC --- I have posted a proposed fix to the mailing list: http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00538.html
[Bug tree-optimization/47639] [4.5/4.6 Regression] ICE: verify_stmts failed: statement marked for throw, but doesn't with -fstack-check=generic -fexceptions -fnon-call-exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47639 --- Comment #4 from Richard Guenther 2011-02-08 14:16:53 UTC --- Author: rguenth Date: Tue Feb 8 14:16:50 2011 New Revision: 169926 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169926 Log: 2011-02-08 Richard Guenther PR middle-end/47639 * tree-vect-generic.c (expand_vector_operations_1): Update stmts here ... (expand_vector_operations): ... not here. Cleanup EH info and the CFG if required. * g++.dg/opt/pr47639.c: New testcase. Added: trunk/gcc/testsuite/g++.dg/opt/pr47639.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-generic.c
[Bug middle-end/47092] [4.6 Regression] gfortran.fortran-torture/execute/forall_4.f90 is VERY slow with -fgraphite-identity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47092 --- Comment #2 from Dominique d'Humieres 2011-02-08 14:22:17 UTC --- The slow-down appeared between revisions 167992 and 168504.
[Bug c++/47326] [4.4/4.5/4.6 Regression] ICE in tsubst_copy (triggered by dependency of return type on parameter pack size)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47326
--- Comment #8 from Jonathan Wakely 2011-02-08
14:30:36 UTC ---
The code is valid C++0x (so the summary should include [C++0x])
It doesn't ICE if sizeof...(_ARGS) is used instead of sizeof...(args), or if
the sizeof... expression occurs in the function body rather than the
trailing-return-type
e.g this compiles:
template struct A { };
template
auto f (_ARGS... args) -> A {
return {};
}
int main() {
f(1,2);
}
and so does this:
template struct A { };
template
A<2> f (_ARGS... args) {
return A{};
}
int main() {
f(1,2);
}
but not this:
template struct A { };
template
auto f (_ARGS... args) -> A {
return {};
}
int main() {
f(1,2);
}
[Bug driver/47390] [4.6 Regression] Linking with -export-dynamic broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47390
--- Comment #6 from Richard Guenther 2011-02-08
14:36:34 UTC ---
(In reply to comment #2)
> On Fri, 21 Jan 2011, rguenth at gcc dot gnu.org wrote:
>
> > Joseph - 4.5 handled -export-dynamic by passing it through to the linker
> > (not exactly sure why). Can we restore this behavior to avoid regressions?
> > If not, can we diagnose this invalid option then? It seems to be passed
> > as -e xport-dynamic to the linker now, resulting in an undefined symbol
> > for me with a trivial hello-world.
>
> -export-dynamic was passed down by an accident of %{e*} in
> LINK_COMMAND_SPEC. If you want this to continue to work then add
>
> export-dynamic
> Driver
>
> to common.opt, and probably put a comment on LINK_COMMAND_SPEC saying that
> %{e*} deliberately covers -export-dynamic. (Alternatively, I think using
> %{export-dynamic} %{e}, together with the common.opt change, will make the
> passed options explicit, and successfully pass to the linker (in separate
> argument form) -e options passed to the driver in either joined or
> separate form - but verify this before making that change.)
Hm, I see. The -e LINK_COMMAND_SPEC isn't documented in invoke.texi
"Link Options", do we generally not do this? It seems to be a spec that
is always enabled.
We document -rdynamic as the way to pass down -export-dynamic, so if
the -e handling is on-purpose ...
Can we force -e options to be passed down in their original joined/non-joined
form? At least for GNU ld -e xport-dynamic is not equal to -export-dynamic,
that a %{e*} spec exchanges a working pass-down variant for an unworking
is unfortunate(?) We can't seem to easily exclude export-dynamic from
e* as to reject it either.
The situation seems to be a bit weird. Probably a note in the changes.html
Caveats section regarding the stricter option handling is due.
[Bug tree-optimization/47640] [4.6 Regression] ICE: verify_flow_info failed: BB 3 can not throw but has an EH edge with -fstack-check=generic -fnon-call-exceptions -ftrapv
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47640 --- Comment #2 from Jeffrey A. Law 2011-02-08 14:37:27 UTC --- tree-ssa-forwprop is either not doing the right thing WRT EH edges when it removes statements which potentially throw or shouldn't be removing the potentially throwing statements. There's no doubt in my mind there's a myriad of these kinds of problems throughout the compiler.
[Bug rtl-optimization/47477] [4.6 regression] Sub-optimal mov at end of method
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47477 Richard Guenther changed: What|Removed |Added Priority|P3 |P2
[Bug rtl-optimization/47477] [4.6 regression] Sub-optimal mov at end of method
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47477 --- Comment #8 from Richard Guenther 2011-02-08 14:39:25 UTC --- (In reply to comment #7) > forwprop is a forward walk, for this kind of optimization we want to walk > backwards, from the narrowing integer conversion to the operations and > whenever > we change some operation see if we can change the def_stmts of its operands > too. forwprop does both, walking forward and backward today. It's just misnamed now ;)
[Bug c++/47482] [4.6 Regression] [C++0x] ICE: unexpected expression ‘sizeof ("A")’ of kind sizeof_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47482 Richard Guenther changed: What|Removed |Added Priority|P3 |P1
[Bug tree-optimization/47640] [4.6 Regression] ICE: verify_flow_info failed: BB 3 can not throw but has an EH edge with -fstack-check=generic -fnon-call-exceptions -ftrapv
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47640 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #3 from Jeffrey A. Law 2011-02-08 14:45:16 UTC --- richi pointed out this was a duplicate of a bug he'd already fixed. *** This bug has been marked as a duplicate of bug 47632 ***
[Bug tree-optimization/47632] [4.6 Regression] ICE: verify_flow_info failed: BB 4 can not throw but has an EH edge with -fnon-call-exceptions -ftrapv and operator new[]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47632 --- Comment #5 from Jeffrey A. Law 2011-02-08 14:45:16 UTC --- *** Bug 47640 has been marked as a duplicate of this bug. ***
[Bug libgcj/47484] [4.4/4.5/4.6 regression] share/python/aotcompile.py and share/python/classfile.py pollute common namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47484 Richard Guenther changed: What|Removed |Added Priority|P3 |P2
[Bug lto/47497] [4.6 Regression] SPEC CPU 2006 failed to link with LTO -fuse-linker-plugin -fwhole-program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47497 Richard Guenther changed: What|Removed |Added Priority|P3 |P1 Summary|[4.6 Regression] SPEC CPU |[4.6 Regression] SPEC CPU |2006 failed to link with|2006 failed to link with |LTO |LTO -fuse-linker-plugin ||-fwhole-program
[Bug rtl-optimization/47614] [4.6 Regression] cpu2000 benchmark 301.apsi fails with revision 169782
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47614 --- Comment #8 from Jakub Jelinek 2011-02-08 14:52:25 UTC --- I can't reproduce this with a cross compiler unfortunately, but perhaps using check_for_inc_dec (currently static in dse.c) when deleting insn where needed in postreload.c might fix that.
[Bug c++/47503] [4.6 Regression] [C++0x] ICE: in adjust_temp_type, at cp/semantics.c:5876 with -fno-elide-constructors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47503 Richard Guenther changed: What|Removed |Added Priority|P3 |P1
[Bug middle-end/47646] New: [4.6 Regression] Revision 169918 caused many testsuite failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47646 Summary: [4.6 Regression] Revision 169918 caused many testsuite failures Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com CC: kreb...@gcc.gnu.org On Linux/x86, revision 169918: http://gcc.gnu.org/ml/gcc-cvs/2011-02/msg00462.html caused: FAIL: c-c++-common/pr2.c (test for warnings, line 13) FAIL: c-c++-common/pr2.c -Wc++-compat (test for warnings, line 13) FAIL: c-c++-common/pr2.c -Wc++-compat (test for warnings, line 28) FAIL: c-c++-common/pr2.c -Wc++-compat (test for excess errors) FAIL: c-c++-common/pr2.c (test for excess errors) FAIL: g++.dg/warn/Wuninitialized-5.C (test for warnings, line 8) FAIL: g++.dg/warn/Wuninitialized-5.C (test for excess errors) FAIL: gcc.dg/noreturn-1.c (test for excess errors) FAIL: gcc.dg/noreturn-1.c detect return from noreturn (test for warnings, line 38) FAIL: gcc.dg/pr39666-2.c (test for warnings, line 8) FAIL: gcc.dg/pr39666-2.c (test for excess errors) FAIL: gcc.dg/uninit-pr19430.c (test for warnings, line 21) FAIL: gcc.dg/uninit-pr19430.c (test for excess errors) FAIL: gfortran.dg/pr39666-2.f90 -O (test for warnings, line 5) FAIL: gfortran.dg/pr39666-2.f90 -O (test for excess errors) FAIL: objc.dg/attributes/method-noreturn-1.m -fgnu-runtime (test for warnings, line 21) FAIL: objc.dg/attributes/method-noreturn-1.m -fgnu-runtime (test for warnings, line 25) FAIL: objc.dg/attributes/method-noreturn-1.m -fgnu-runtime (test for excess errors)
[Bug c++/47511] [4.6 Regression] [C++0x] ICE: unexpected ast of kind template_decl in potential_constant_expression_1, at cp/semantics.c:7711
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47511 Richard Guenther changed: What|Removed |Added Keywords||rejects-valid Priority|P3 |P1
[Bug lto/47527] [4.6 regression] -flto -flto-partition=none broken for arm-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47527 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011.02.08 14:57:10 Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther 2011-02-08 14:57:10 UTC --- Does -fno-use-linker-plugin work? Which binutils version do you use?
[Bug middle-end/47581] [4.5/4.6 regression] Unnecessary adjustments to stack pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47581 Richard Guenther changed: What|Removed |Added Priority|P3 |P2
[Bug pch/47584] [4.6 regression] internal compiler error: sigsegv in libcpp/line-map.c:285
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47584 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.02.08 15:02:07 Ever Confirmed|0 |1 --- Comment #8 from Richard Guenther 2011-02-08 15:02:07 UTC --- Probably memory usage for the PCH changed between releases.
[Bug rtl-optimization/47620] [4.6 Regression] Profiledbootstrap failure on powerpc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47620 Richard Guenther changed: What|Removed |Added Target|powerpc64-linux |powerpc64-linux, ||s390x-linux Priority|P3 |P1 Version|unknown |4.6.0
[Bug testsuite/47622] [4.6 Regression] FAIL: gcc.dg/pr42631.c scan-rtl-dump-not web "Web oldreg"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47622 Richard Guenther changed: What|Removed |Added Priority|P3 |P1 Component|debug |testsuite
[Bug tree-optimization/47639] [4.5 Regression] ICE: verify_stmts failed: statement marked for throw, but doesn't with -fstack-check=generic -fexceptions -fnon-call-exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47639 Richard Guenther changed: What|Removed |Added Known to work||4.6.0 Summary|[4.5/4.6 Regression] ICE: |[4.5 Regression] ICE: |verify_stmts failed:|verify_stmts failed: |statement marked for throw, |statement marked for throw, |but doesn't with|but doesn't with |-fstack-check=generic |-fstack-check=generic |-fexceptions|-fexceptions |-fnon-call-exceptions |-fnon-call-exceptions Known to fail|4.6.0 | --- Comment #5 from Richard Guenther 2011-02-08 15:06:25 UTC --- Fixed on trunk sofar.
[Bug middle-end/47646] [4.6 Regression] Revision 169918 caused many testsuite failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47646 Richard Guenther changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |4.6.0
[Bug rtl-optimization/47420] [4.6 regression] ICE: in calc_dfs_tree, at dominance.c:395 with c++ code for mingw
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47420 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.6.0
[Bug c++/47488] [4.4/4.5/4.6 Regression] (sizeof|decltype) + template + string literals: ICE in write_template_arg_literal, at cp/mangle.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47488 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.4.6
[Bug middle-end/44440] [4.6 regression] ira_initialization and buitins construction taking too much of startup time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=0 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.6.0
[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 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.6.0
[Bug lto/47241] lto not work on mingw32, reporting 'ld.exe: could not unlink output file'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47241
Kai Tietz changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed||2011.02.08 15:38:59
CC||ktietz at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #2 from Kai Tietz 2011-02-08 15:38:59
UTC ---
Hmm, this could be related to wrapper and file-removing there.
Does this patch fixes the issue you have?
Index: lto-plugin.c
===
--- lto-plugin.c(revision 169926)
+++ lto-plugin.c(working copy)
@@ -660,12 +660,14 @@
if (arguments_file_name)
{
t = unlink (arguments_file_name);
+ if (t != 0 && errno == ENOENT) t = 0;
check (t == 0, LDPL_FATAL, "could not unlink arguments file");
}
for (i = 0; i < num_output_files; i++)
{
t = unlink (output_files[i]);
+ if (t != 0 && errno == ENOENT) t = 0;
check (t == 0, LDPL_FATAL, "could not unlink output file");
}
[Bug target/47619] ICE in printf() with -fsplit-stack enabled.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47619 --- Comment #7 from Ian Lance Taylor 2011-02-08 15:41:35 UTC --- Works for me with current mainline gold and eglibc 2.11.1 on Ubuntu Lucid. Can you show me the -v line from your link command?
[Bug target/47619] ICE in printf() with -fsplit-stack enabled.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47619 H.J. Lu changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #8 from H.J. Lu 2011-02-08 15:50:06 UTC --- I have glibc 2.13 on Fedora 14: [hjl@gnu-6 pr47619]$ /usr/gcc-4.6/bin/gcc -O -fsplit-stack -B./ -o x x.o -Wl,-v collect2 version 4.6.0 20110202 (experimental) [trunk revision 169766] (x86-64 Linux/ELF) ./ld --demangle --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o x /usr/lib/../lib64/crt1.o /usr/lib/../lib64/crti.o /usr/gcc-4.6/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/crtbegin.o -L. -L/usr/gcc-4.6/lib/gcc/x86_64-unknown-linux-gnu/4.6.0 -L/usr/gcc-4.6/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/gcc-4.6/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../.. x.o -v --wrap=pthread_create -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/gcc-4.6/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/crtend.o /usr/lib/../lib64/crtn.o GNU gold (GNU Binutils 2.21.51.20110207) 1.11
[Bug libmudflap/18885] linker does not link libmudflap automatically with -fmudflap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18885
Ludovic Courtès changed:
What|Removed |Added
CC||ludo at gnu dot org
--- Comment #4 from Ludovic Courtès 2011-02-08 15:58:22
UTC ---
I can confirm the problem with 4.5.1 on x86_64-linux-gnu.
Indeed, the `mflib' spec lacks `-lmudflap':
$ gcc -dumpspecs |grep -A2 -E '(mflib|link_command)'
*mflib:
%{fmudflap|fmudflapth: -export-dynamic}
--
*link_command:
%{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S:%(linker)
%{fuse-linker-plugin: -plugin %(linker_plugin_file)
-plugin-opt=%(lto_wrapper) -plugin-opt=%(lto_gcc)
%{static|static-libgcc:-plugin-opt=-pass-through=%(lto_libgcc)}
%{static:-plugin-opt=-pass-through=-lc} %{O*:-plugin-opt=-O%*}
%{w:-plugin-opt=-w} %{f*:-plugin-opt=-f%*} %{m*:-plugin-opt=-m%*}
%{v:-plugin-opt=-v} } %{flto} %{fwhopr} %l %{pie:-pie} %X %{o*} %{A}
%{d} %{e*} %{m} %{N} %{n} %{r}%{s} %{t} %{u*} %{x} %{z} %{Z}
%{!A:%{!nostdlib:%{!nostartfiles:%S}}}%{static:} %{L*} %(mfwrap)
%(link_libgcc) %o
%{fopenmp|ftree-parallelize-loops=*:%:include(libgomp.spec)%(link_gomp)}
%(mflib)%{fprofile-arcs|fprofile-generate*|coverage:-lgcov}
%{!nostdlib:%{!nodefaultlibs:%(link_ssp) %(link_gcc_c_sequence)}}
%{!A:%{!nostdlib:%{!nostartfiles:%E}}} %{T*} }}
[Bug debug/47647] New: BLOCKs are empty
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47647 Summary: BLOCKs are empty Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: lto Severity: normal Priority: P3 Component: debug AssignedTo: unassig...@gcc.gnu.org ReportedBy: rgue...@gcc.gnu.org r165191 assumes that DECL_CONTEXT of variables is their corresponding BLOCK which isn't the case at least for autos. Thus the BLOCK tree ends up mostly empty for -flto -g.
[Bug bootstrap/45381] [4.6 Regression] Bootstrap failure for powerpc-apple-darwin9: error: AltiVec argument passed to unprototyped function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45381 --- Comment #9 from Richard Henderson 2011-02-08 16:17:10 UTC --- I don't think we really want to pursue this further. I had hoped to find a solution that satisfied the older apple compiler -- it is supposed to support altivec after all -- but it remains a mystery what is broken with that compiler.
[Bug bootstrap/45381] [4.6 Regression] Bootstrap failure for powerpc-apple-darwin9: error: AltiVec argument passed to unprototyped function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45381 --- Comment #10 from Iain Sandoe 2011-02-08 16:44:15 UTC --- (In reply to comment #9) > I don't think we really want to pursue this further. > > I had hoped to find a solution that satisfied the older apple compiler -- it > is supposed to support altivec after all -- but it remains a mystery what is > broken with that compiler. OK, that's fair - so is the solution to apply (an updated) patch like comment #1 ? - or must earlier darwin systems do that locally? (I'm not clear whether the limitation of 4.0.5 applies generally or only to the Apple Local versions)
[Bug middle-end/47646] [4.6 Regression] Revision 169918 caused many testsuite failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47646 --- Comment #1 from Andreas Krebbel 2011-02-08 16:46:25 UTC --- Author: krebbel Date: Tue Feb 8 16:46:20 2011 New Revision: 169927 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169927 Log: 2011-02-08 Andreas Krebbel PR middle-end/47646 * gcc.dg/pr39666-2.c (foo2): If the location of the statement using the variable is known the warning is emitted there. * gcc.dg/uninit-pr19430.c (foo): Likewise. * g++.dg/warn/Wuninitialized-5.C (foo): Likewise. * c-c++-common/pr2.c (g): Both warnings occur at the return statement. (vg): Likewise. * gcc.dg/noreturn-1.c (foo5): Likewise. * objc.dg/attributes/method-noreturn-1.m (method1): Likewise. (method2): Likewise. * gfortran.dg/pr25923.f90 (baz): The warning will now be issued for the return statement using the uninitialized variable. * gfortran.dg/pr39666-2.f90 (f): Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/pr2.c trunk/gcc/testsuite/g++.dg/warn/Wuninitialized-5.C trunk/gcc/testsuite/gcc.dg/noreturn-1.c trunk/gcc/testsuite/gcc.dg/pr39666-2.c trunk/gcc/testsuite/gcc.dg/uninit-pr19430.c trunk/gcc/testsuite/gfortran.dg/pr25923.f90 trunk/gcc/testsuite/gfortran.dg/pr39666-2.f90 trunk/gcc/testsuite/objc.dg/attributes/method-noreturn-1.m
[Bug bootstrap/45381] [4.6 Regression] Bootstrap failure for powerpc-apple-darwin9: error: AltiVec argument passed to unprototyped function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45381 --- Comment #11 from Richard Henderson 2011-02-08 16:52:41 UTC --- Yes, a patch like in #1 would be fine.
[Bug tree-optimization/46994] [4.6 Regression] ICE: in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:422 with -fgraphite-identity -fno-tree-dce -ffast-math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46994 --- Comment #3 from Sebastian Pop 2011-02-08 16:54:03 UTC --- Author: spop Date: Tue Feb 8 16:53:57 2011 New Revision: 169928 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169928 Log: Fix PRs 46834, 46994, and 46995: only rewrite reductions not containing other computations. 2011-02-08 Sebastian Pop PR tree-optimization/46834 PR tree-optimization/46994 PR tree-optimization/46995 * graphite-sese-to-poly.c (used_outside_reduction): New. (detect_commutative_reduction): Call used_outside_reduction. (rewrite_commutative_reductions_out_of_ssa_close_phi): Call translate_scalar_reduction_to_array only when at least one loop-phi/close-phi tuple has been detected. * gcc.dg/graphite/id-pr46834.c: New. * gfortran.dg/graphite/id-pr46994.f90: New. * gfortran.dg/graphite/id-pr46995.f90: New. Added: trunk/gcc/testsuite/gcc.dg/graphite/id-pr46834.c trunk/gcc/testsuite/gfortran.dg/graphite/id-pr46994.f90 trunk/gcc/testsuite/gfortran.dg/graphite/id-pr46995.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/graphite-sese-to-poly.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/46834] [4.6 Regression] ICE: verify_ssa failed: missing definition with -fgraphite-identity -ffast-math -fno-tree-dce
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46834 --- Comment #3 from Sebastian Pop 2011-02-08 16:54:04 UTC --- Author: spop Date: Tue Feb 8 16:53:57 2011 New Revision: 169928 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169928 Log: Fix PRs 46834, 46994, and 46995: only rewrite reductions not containing other computations. 2011-02-08 Sebastian Pop PR tree-optimization/46834 PR tree-optimization/46994 PR tree-optimization/46995 * graphite-sese-to-poly.c (used_outside_reduction): New. (detect_commutative_reduction): Call used_outside_reduction. (rewrite_commutative_reductions_out_of_ssa_close_phi): Call translate_scalar_reduction_to_array only when at least one loop-phi/close-phi tuple has been detected. * gcc.dg/graphite/id-pr46834.c: New. * gfortran.dg/graphite/id-pr46994.f90: New. * gfortran.dg/graphite/id-pr46995.f90: New. Added: trunk/gcc/testsuite/gcc.dg/graphite/id-pr46834.c trunk/gcc/testsuite/gfortran.dg/graphite/id-pr46994.f90 trunk/gcc/testsuite/gfortran.dg/graphite/id-pr46995.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/graphite-sese-to-poly.c trunk/gcc/testsuite/ChangeLog
[Bug driver/47390] [4.6 Regression] Linking with -export-dynamic broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47390
--- Comment #7 from joseph at codesourcery dot com 2011-02-08 16:54:19 UTC ---
On Tue, 8 Feb 2011, rguenth at gcc dot gnu.org wrote:
> Hm, I see. The -e LINK_COMMAND_SPEC isn't documented in invoke.texi
> "Link Options", do we generally not do this? It seems to be a spec that
> is always enabled.
What's documented is pretty random - there are lots of undocumented
options in specs.
> Can we force -e options to be passed down in their original joined/non-joined
> form? At least for GNU ld -e xport-dynamic is not equal to -export-dynamic,
> that a %{e*} spec exchanges a working pass-down variant for an unworking
> is unfortunate(?) We can't seem to easily exclude export-dynamic from
> e* as to reject it either.
You can force joined form by adding code like the OPT_L handling
case OPT_L:
/* Similarly, canonicalize -L for linkers that may not accept
separate arguments. */
save_switch (concat ("-L", arg, NULL), 0, NULL, validated);
return true;
although the explicit export-dynamic entry in common.opt for backwards
compatibility would seem better to me.
[Bug middle-end/46834] [4.6 Regression] ICE: verify_ssa failed: missing definition with -fgraphite-identity -ffast-math -fno-tree-dce
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46834 Sebastian Pop changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Sebastian Pop 2011-02-08 16:55:48 UTC --- Fixed.
[Bug tree-optimization/46995] [4.6 Regression] ICE: verify_ssa failed: definition in block 11 does not dominate use in block 16 with -fgraphite-identity -fno-tree-dce -ffast-math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46995 --- Comment #3 from Sebastian Pop 2011-02-08 16:54:03 UTC --- Author: spop Date: Tue Feb 8 16:53:57 2011 New Revision: 169928 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169928 Log: Fix PRs 46834, 46994, and 46995: only rewrite reductions not containing other computations. 2011-02-08 Sebastian Pop PR tree-optimization/46834 PR tree-optimization/46994 PR tree-optimization/46995 * graphite-sese-to-poly.c (used_outside_reduction): New. (detect_commutative_reduction): Call used_outside_reduction. (rewrite_commutative_reductions_out_of_ssa_close_phi): Call translate_scalar_reduction_to_array only when at least one loop-phi/close-phi tuple has been detected. * gcc.dg/graphite/id-pr46834.c: New. * gfortran.dg/graphite/id-pr46994.f90: New. * gfortran.dg/graphite/id-pr46995.f90: New. Added: trunk/gcc/testsuite/gcc.dg/graphite/id-pr46834.c trunk/gcc/testsuite/gfortran.dg/graphite/id-pr46994.f90 trunk/gcc/testsuite/gfortran.dg/graphite/id-pr46995.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/graphite-sese-to-poly.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/46994] [4.6 Regression] ICE: in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:422 with -fgraphite-identity -fno-tree-dce -ffast-math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46994 Sebastian Pop changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Sebastian Pop 2011-02-08 16:56:20 UTC --- Fixed.
[Bug tree-optimization/46995] [4.6 Regression] ICE: verify_ssa failed: definition in block 11 does not dominate use in block 16 with -fgraphite-identity -fno-tree-dce -ffast-math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46995 Sebastian Pop changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Sebastian Pop 2011-02-08 16:56:31 UTC --- Fixed.
[Bug fortran/47648] New: libgfortran/libgfortran.h:53:29: fatal error: quadmath_weak.h: No such f ile or directory - FreeBSD ia64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47648 Summary: libgfortran/libgfortran.h:53:29: fatal error: quadmath_weak.h: No such f ile or directory - FreeBSD ia64 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: me...@bristol.ac.uk # uname -a FreeBSD mech-cluster241.men.bris.ac.uk 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r216732: Mon Dec 27 13:22:47 GMT 2010 r...@mech-cluster241.men.bris.ac.uk:/usr/obj/usr/src/sys/TZAV ia64 # Building gcc46 gives: libtool: compile: /usr/ports/lang/gcc46/work/build/./gcc/xgcc -B/usr/ports/lang/gcc46/work/build/./ gcc/ -B/usr/local/ia64-portbld-freebsd9.0/bin/ -B/usr/local/ia64-portbld-freebsd9.0/lib/ -isystem /u sr/local/ia64-portbld-freebsd9.0/include -isystem /usr/local/ia64-portbld-freebsd9.0/sys-include -DH AVE_CONFIG_H -I. -I../.././../gcc-4.6-20110205/libgfortran -iquote../.././../gcc-4.6-20110205/libgfo rtran/io -I../.././../gcc-4.6-20110205/libgfortran/../gcc -I../.././../gcc-4.6-20110205/libgfortran/ ../gcc/config -I../.././gcc -D_GNU_SOURCE -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -fcx-fortran-rules -ffunction-sections -fdata-section s -g -O2 -pipe -I/usr/local/include -fno-strict-aliasing -MT backtrace.lo -MD -MP -MF .deps/backtrac e.Tpo -c ../.././../gcc-4.6-20110205/libgfortran/runtime/backtrace.c -fPIC -DPIC -o .libs/backtrace .o In file included from ../.././../gcc-4.6-20110205/libgfortran/runtime/backtrace.c:25:0: ../.././../gcc-4.6-20110205/libgfortran/libgfortran.h:53:29: fatal error: quadmath_weak.h: No such file or directory compilation terminated. In file included from ../.././../gcc-4.6-20110205/libgfortran/fmain.c:4:0: ../.././../gcc-4.6-20110205/libgfortran/libgfortran.h:53:29: fatal error: quadmath_weak.h: No such file or directory compilation terminated. gmake[3]: *** [fmain.lo] Error 1 gmake[3]: *** Waiting for unfinished jobs gmake[3]: *** [backtrace.lo] Error 1 gmake[3]: Leaving directory `/usr/ports/lang/gcc46/work/build/ia64-portbld-freebsd9.0/libgfortran' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/usr/ports/lang/gcc46/work/build/ia64-portbld-freebsd9.0/libgfortran' gmake[1]: *** [all-target-libgfortran] Error 2 gmake[1]: Leaving directory `/usr/ports/lang/gcc46/work/build'
[Bug fortran/47649] New: install-info: No such file or directory for /usr/local/info/gcc46/libquadmath.info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47649 Summary: install-info: No such file or directory for /usr/local/info/gcc46/libquadmath.info Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: me...@bristol.ac.uk # uname -a FreeBSD mech-anton240.men.bris.ac.uk 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r216048: Mon Nov 29 15:19:12 GMT 2010 r...@mech-anton240.men.bris.ac.uk:/usr/obj/usr/src/sys/QOF sparc64 # make was fine. make install gives this: cd /usr/ports/lang/gcc46/work ; /usr/bin/sed -i -e "/PLIST.lib/ r PLIST.lib" /usr/ports/lang/gcc46/work/.PLIST.mktmp install-info --quiet /usr/local/info/gcc46/cpp.info /usr/local/info/dir install-info --quiet /usr/local/info/gcc46/cppinternals.info /usr/local/info/dir install-info --quiet /usr/local/info/gcc46/gcc.info /usr/local/info/dir install-info --quiet /usr/local/info/gcc46/gccinstall.info /usr/local/info/dir install-info --quiet /usr/local/info/gcc46/gccint.info /usr/local/info/dir install-info --quiet /usr/local/info/gcc46/gfortran.info /usr/local/info/dir install-info --quiet /usr/local/info/gcc46/libgomp.info /usr/local/info/dir install-info --quiet /usr/local/info/gcc46/libquadmath.info /usr/local/info/dir install-info: No such file or directory for /usr/local/info/gcc46/libquadmath.info *** Error code 1 Stop in /usr/ports/lang/gcc46. *** Error code 1
[Bug testsuite/47622] [4.6 Regression] FAIL: gcc.dg/pr42631.c scan-rtl-dump-not web "Web oldreg"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47622 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek 2011-02-08 17:37:02 UTC --- Do we really need that scan-rtl test in there (which has been newly added to an old testcase, why?)? If yes, can't it be limited to a few selected targets where it is supposed to not be present?
[Bug target/47481] [4.6 Regression] spill failure with -O2 -msoft-float on Ada RTS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47481 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|NEW AssignedTo|ebotcazou at gcc dot|unassigned at gcc dot |gnu.org |gnu.org --- Comment #3 from Eric Botcazou 2011-02-08 17:44:34 UTC --- There is probably no point in using 80-bit floats with -msoft-float: Index: config/i386/i386.h === --- config/i386/i386.h (revision 169914) +++ config/i386/i386.h (working copy) @@ -658,7 +658,8 @@ enum target_cpu_default #define DOUBLE_TYPE_SIZE 64 #define LONG_DOUBLE_TYPE_SIZE 80 -#define WIDEST_HARDWARE_FP_SIZE LONG_DOUBLE_TYPE_SIZE +#define WIDEST_HARDWARE_FP_SIZE \ + (TARGET_80387 ? LONG_DOUBLE_TYPE_SIZE : DOUBLE_TYPE_SIZE) #if defined (TARGET_BI_ARCH) || TARGET_64BIT_DEFAULT #define MAX_BITS_PER_WORD 64
[Bug bootstrap/47243] [4.6 Regression] Bootstrap fails: Segfault of genmddeps / COLLECT bug?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47243 Tobias Burnus changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED --- Comment #8 from Tobias Burnus 2011-02-08 18:01:31 UTC --- Seems to be fixed. I think it was fixed by the patch for PR 47244 - sorry for forgetting to update this PR.
[Bug fortran/47642] real(kind=16) - libquadmath - segfault on amd64 FreeBSD
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47642 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #6 from Tobias Burnus 2011-02-08 18:23:44 UTC --- (In reply to comment #5) > Does anyone have confidence in gdtoa QoI? I'd personally feel much safer by > just copying over and editting glibc stdio-common/printf_fp.c than fixing up > gdtoa. I think one could do so. Actually, I would not mind if one could get completely rid of gdtoa - the way it does the string-to-__float128 conversion also looks overly complicated.
[Bug fortran/47649] install-info: No such file or directory for /usr/local/info/gcc46/libquadmath.info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47649 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus 2011-02-08 18:27:50 UTC --- Regarding this PR (PR 47649) and also regarding PR 47648: Is libquadmath actually build? In either case: Can you show how the configure output of libquadmath looks like? I assume you did not configure with --disable-libquadmath nor with --disable-libquadmath-support - or did you?
[Bug target/47619] ICE in printf() with -fsplit-stack enabled.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47619 --- Comment #9 from Ian Lance Taylor 2011-02-08 18:41:53 UTC --- I just tried glibc 2.12.2 on Fedora 13 and it worked there too. I don't have a Fedora 14 system. This program eats memory and your numbers show it had allocated over 434M when it crashed for you; do you have a ulimit set? Otherwise I'm not sure what to suggest without the ability to debug the program. I suppose a partial backtrace and some idea of precisely which instruction was executing at the crash might suggest something (note that the full backtrace will be huge, and uninteresting).
[Bug tree-optimization/42893] [4.3/4.4/4.5/4.6 Regression] Missed conditionally dead store elimination
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42893 --- Comment #12 from Jeffrey A. Law 2011-02-08 18:54:21 UTC --- Author: law Date: Tue Feb 8 18:54:12 2011 New Revision: 169933 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169933 Log: PR tree-optimization/42893 * gcc.tree-ssa/pr42893.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr42893.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/42893] [4.3/4.4/4.5/4.6 Regression] Missed conditionally dead store elimination
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42893 Jeffrey A. Law changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #13 from Jeffrey A. Law 2011-02-08 18:55:44 UTC --- Testcase added.
