[Bug bootstrap/45206] New: [4.6 regression] ICE in ix86_expand_epilogue compiling libgcc
The error is: /home/eric/gnat/gnat-head/native32/./gcc/xgcc -B/home/eric/gnat/gnat-head/native32/./gcc/ -B/home/eric/install/gnat-head/i586-suse-linux/bin/ -B/home/eric/install/gnat-head/i586-suse-linux/lib/ -isystem /home/eric/install/gnat-head/i586-suse-linux/include -isystem /home/eric/install/gnat-head/i586-suse-linux/sys-include-g -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../.././gcc -I/home/eric/gnat/gnat-head/src/libgcc -I/home/eric/gnat/gnat-head/src/libgcc/. -I/home/eric/gnat/gnat-head/src/libgcc/../gcc -I/home/eric/gnat/gnat-head/src/libgcc/../include -I/home/eric/gnat/gnat-head/src/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_TLS -o unwind-dw2.o -MT unwind-dw2.o -MD -MP -MF unwind-dw2.dep -fexceptions -c /home/eric/gnat/gnat-head/src/libgcc/../gcc/unwind-dw2.c -fvisibility=hidden -DHIDE_EXPORTS In file included from /home/eric/gnat/gnat-head/src/libgcc/../gcc/unwind-dw2.c:1582:0: /home/eric/gnat/gnat-head/src/libgcc/../gcc/unwind.inc: In function '_Unwind_RaiseException': /home/eric/gnat/gnat-head/src/libgcc/../gcc/unwind.inc:136:1: internal compiler error: in ix86_expand_epilogue, at config/i386/i386.c:10178 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[3]: *** [unwind-dw2.o] Error 1 Preprocessed file to be attached, compile with -mtune=i586. -- Summary: [4.6 regression] ICE in ix86_expand_epilogue compiling libgcc Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ebotcazou at gcc dot gnu dot org GCC build triplet: i586-*-* GCC host triplet: i586-*-* GCC target triplet: i586-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45206
[Bug bootstrap/45206] [4.6 regression] ICE in ix86_expand_epilogue compiling libgcc
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2010-08-06 06:21 --- Created an attachment (id=21420) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21420action=view) Preprocessed file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45206
[Bug libstdc++/45202] Strict aliasing warning in stl_tree (returning a copy of a set from a member function in a loop)
--- Comment #5 from paolo dot carlini at oracle dot com 2010-08-06 06:53 --- *** This bug has been marked as a duplicate of 42032 *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45202
[Bug c++/42032] Aliasing errors in stl_tree.h
--- Comment #9 from paolo dot carlini at oracle dot com 2010-08-06 06:53 --- *** Bug 45202 has been marked as a duplicate of this bug. *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||eric_moyer at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42032
[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap
--- Comment #68 from bonzini at gnu dot org 2010-08-06 07:07 --- fwprop.c doesn't handle it directly, but local_ref_killed_between_p should see defs created by df-scan.c for each hard register in regs_invalidated_by_call (see df_get_call_refs). Also, since fwprop can lengthen lifetimes arbitrarily (though this wouldn't happen often) propagate_rtx actually forbids copy propagation of hard registers: if (REG_P (new_rtx) REGNO (new_rtx) FIRST_PSEUDO_REGISTER) return NULL_RTX; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
[Bug c/44803] LIBRARY_PATH should work on cross-compilers
--- Comment #2 from felipe dot contreras at gmail dot com 2010-08-06 07:08 --- (In reply to comment #1) ? (you have to give some more details) What exactly do you need? From the manpage LIBRARY_PATH The value of LIBRARY_PATH is a colon-separated list of directories, much like PATH. When configured as a native compiler, GCC tries the directories thus specified when searching for special linker files, if it cant find them using GCC_EXEC_PREFIX. Linking using GCC also uses these directories when searching for ordinary libraries for the -l option (but directories specified with -L come first). I confirm that LIBRARY_PATH is ignored by CodeSourcery cross-compiler, and I don't see why. Wouldn't LIBRARY_PATH be specially useful for cross-comilation? -- felipe dot contreras at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |felipe dot contreras at |dot org |gmail dot com Status|WAITING |UNCONFIRMED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44803
[Bug c/45207] New: The -Os flag generates wrong code for ARM966e-s
We have problems with GCC-4.5.0 and GCC-4.5.1 for ARM when using the -Os optimizer flag. The code crashes due to what seems to be undefined instruction exception. If we instead use -O1 or -O2 it works fine. Also GCC-4.3.x and GCC-4.4.x works well. I also tried to add all excluded -O2 flags when compiling with -Os but this gave still wrong code. Our CFLAGS: -g3 -ggdb3 -gdwarf-2 -mthumb -c -Wall -W -Wextra -Wno-unused-parameter -mcpu=arm966e-s -Os -mhard-float -mfpu=fpa -ffunction-sections -fdata-sections I attach build-script for our arm-elf-toolchain built on an intel machine. Also arm-elf-gdb 7.1 complaints about the elf file when trying to debug: warning: (Internal error: pc 0x4a42c in read in psymtab, but not in symtab.) Thanks and Best Regards, Fredrik Hederstierna -- Summary: The -Os flag generates wrong code for ARM966e-s Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fredrik dot hederstierna at securitas-direct dot com GCC target triplet: arm-elf-gcc http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45207
[Bug c/45207] The -Os flag generates wrong code for ARM966e-s
--- Comment #1 from fredrik dot hederstierna at securitas-direct dot com 2010-08-06 07:20 --- Created an attachment (id=21421) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21421action=view) Script to build arm-elf toolchain -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45207
[Bug middle-end/41082] [4.5/4.6 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3
--- Comment #52 from dominiq at lps dot ens dot fr 2010-08-06 07:33 --- The miscompilation with -m64 is back at revision 162879. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082
[Bug target/45205] printf does not print some long doubles correctly
--- Comment #8 from dominiq at lps dot ens dot fr 2010-08-06 07:46 --- The test works here with: Using built-in specs. Target: powerpc-apple-darwin9 Configured with: /var/tmp/gcc/gcc-5493~1/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib --build=i686-apple-darwin9 --program-prefix= --host=powerpc-apple-darwin9 --target=powerpc-apple-darwin9 Thread model: posix gcc version 4.0.1 (Apple Inc. build 5493) and also with all the FSF gcc versions I have tried. It looks like a bug in 10.4 which will probably never be fixed. Any reason not to upgrade your system to 10.5 or 10.6? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45205
[Bug target/45205] printf does not print some long doubles correctly
--- Comment #9 from dominiq at lps dot ens dot fr 2010-08-06 07:49 --- to upgrade your system to 10.5 or 10.6? I just realized that 10.6 requires an Intel proc!-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45205
[Bug target/45207] The -Os flag generates wrong code for ARM966e-s
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-08-06 07:52 --- Have you tried compiling with -fno-strict-aliasing ? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |target Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45207
[Bug target/45208] New: powerpc-gcc -msdata breakdown on incomplete initializers
When compiling the code-snippet below with powerpc-*-gcc -msdata,
this error happens:
# powerpc-rtems4.11-gcc -c test.c -o test.o -msdata
test.c:10: error: rtems_filesystem_mount_table_size causes a section type
conflict
--- snip ---
int pipe (int __fildes[2] );
void Init( void )
{
int fd[2] = {0};
pipe( fd );
}
const int rtems_filesystem_mount_table_size = 1;
--- snip ---
This error does not happen, when
- compiling this snippet without -msdata
- expanding int fd[2] = {0}; into int fd[2] = {0,0};
I am able to reproduce this bug with GCC 4.2.4, 4.3.2, 4.4.4, 4.5.1,
all targetting powerpc-rtems.
--
Summary: powerpc-gcc -msdata breakdown on incomplete initializers
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: corsepiu at gcc dot gnu dot org
GCC target triplet: powerpc-rtems*, powerpc-elf*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45208
[Bug tree-optimization/45195] incorrect array subscript above bounds warning
--- Comment #2 from rahul at icerasemi dot com 2010-08-06 08:01 --- Confirmed, fix for PR41317 avoids forwarding ARRAY_REFs to their use and fixes this issue. Does this fix hinder any optimizations? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45195
[Bug c/45207] The -Os flag generates wrong code for ARM966e-s
--- Comment #3 from fredrik dot hederstierna at securitas-direct dot com 2010-08-06 08:36 --- (In reply to comment #2) Have you tried compiling with -fno-strict-aliasing ? I've tried it now, and it made no difference I'm afraid. The code got slightly bigger, but behavior is the same as previously. /Fredrik -- fredrik dot hederstierna at securitas-direct dot com changed: What|Removed |Added CC||fredrik dot hederstierna at ||securitas-direct dot com Component|target |c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45207
[Bug fortran/44232] function result with pointer to strided component of argument
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2010-08-06 09:05 --- (In reply to comment #8) Hmm. I've now built gfortran 4.5.1 20100521 (from the branch) and still have the same internal compiler error. I have gcc 4.5.1 20100506 on x86_64-apple-darwin10.3.0, and it compiles fine. The Fortran patches between my version and yours are: -- Revision 159556 2010-05-19 Tobias Burnus bur...@net-b.de PR fortran/43591 * expr.c (gfc_is_constant_expr, gfc_traverse_expr): Handle proc-pointers and type-bound procedures. (gfc_specification_expr): Check proc-pointers for pureness. Revision 159417 2010-05-14 Steven G. Kargl ka...@gcc.gnu.org PR fortran/44135 * fortran/interface.c (get_sym_storage_size): Use signed instead of unsigned mpz_get_?i routines. Revision 159363 PR fortran/44036 * openmp.c (resolve_omp_clauses): Allow procedure pointers in clause variable lists. * trans-openmp.c (gfc_omp_privatize_by_reference): Don't privatize by reference dummy procedures or non-dummy procedure pointers. (gfc_omp_predetermined_sharing): Return OMP_CLAUSE_DEFAULT_FIRSTPRIVATE for dummy procedures. Revision 159306 2010-05-12 Daniel Franke franke.dan...@gmail.com PR fortran/40728 * intrinc.c (gfc_is_intrinsic): Do not prematurely mark symbol as external. Revision 159101 2010-05-06 Tobias Burnus bur...@net-b.de PR fortran/43985 * trans-types.c (gfc_sym_type): Mark Cray pointees as GFC_POINTER_TYPE_P. -- None of these look like they could be it. It could be something outside the Fortran front-end, or a 32/64-bit issue (but then, we'd probably see it on 32-bit linux too). If you have time, can you: 1. Using gfortran -v, isolate the invocation of the compiler itself, f951 2. Copy-paste this command-line and run it under gdb: gdb -args [command line here] 3. When it aborts, backtrace (command bt) and copy-paste the output of gdb. This will give information on where to look. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44232
[Bug c/45207] The -Os flag generates wrong code for ARM966e-s
--- Comment #4 from fredrik dot hederstierna at securitas-direct dot com 2010-08-06 09:09 --- Hm, I now tried to disable all possible optimization flags, but still -Os does not work, but -O2 still works! Does the -Os option do anything more that is not controllable from command line options/flags? # Disable O1 flags CFLAGS += -fno-auto-inc-dec CFLAGS += -fno-cprop-registers CFLAGS += -fno-dce CFLAGS += -fno-defer-pop CFLAGS += -fno-delayed-branch CFLAGS += -fno-dse CFLAGS += -fno-guess-branch-probability CFLAGS += -fno-if-conversion2 CFLAGS += -fno-if-conversion CFLAGS += -fno-ipa-pure-const CFLAGS += -fno-ipa-reference CFLAGS += -fno-merge-constants CFLAGS += -fno-split-wide-types CFLAGS += -fno-tree-builtin-call-dce CFLAGS += -fno-tree-ccp CFLAGS += -fno-tree-ch CFLAGS += -fno-tree-copyrename CFLAGS += -fno-tree-dce CFLAGS += -fno-tree-dominator-opts CFLAGS += -fno-tree-dse CFLAGS += -fno-tree-forwprop CFLAGS += -fno-tree-fre CFLAGS += -fno-tree-phiprop CFLAGS += -fno-tree-sra CFLAGS += -fno-tree-pta CFLAGS += -fno-tree-ter CFLAGS += -fno-unit-at-a-time # Disable O2 flags CFLAGS += -fno-thread-jumps CFLAGS += -fno-align-functions -fno-align-jumps CFLAGS += -fno-align-loops -fno-align-labels CFLAGS += -fno-caller-saves CFLAGS += -fno-crossjumping CFLAGS += -fno-cse-follow-jumps -fno-cse-skip-blocks CFLAGS += -fno-delete-null-pointer-checks CFLAGS += -fno-expensive-optimizations CFLAGS += -fno-gcse -fno-gcse-lm CFLAGS += -fno-inline-small-functions CFLAGS += -fno-indirect-inlining CFLAGS += -fno-ipa-sra CFLAGS += -fno-optimize-sibling-calls CFLAGS += -fno-peephole2 CFLAGS += -fno-regmove CFLAGS += -fno-reorder-blocks -fno-reorder-functions CFLAGS += -fno-rerun-cse-after-loop CFLAGS += -fno-sched-interblock -fno-sched-spec CFLAGS += -fno-schedule-insns -fno-schedule-insns2 CFLAGS += -fno-strict-aliasing -fno-strict-overflow CFLAGS += -fno-tree-switch-conversion CFLAGS += -fno-tree-pre CFLAGS += -fno-tree-vrp # Disable flags for debugging purposes CFLAGS += -fno-omit-frame-pointer -fno-web The code size increased alot when disabling all this options. /Fredrik -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45207
[Bug c/45207] The -Os flag generates wrong code for ARM966e-s
--- Comment #5 from ramana at gcc dot gnu dot org 2010-08-06 09:13 --- If you don't give us a testcase we can't verify / see what's going wrong here. Please report bugs as described here. http://gcc.gnu.org/bugs/ . Thanks, Ramana -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45207
[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap
--- Comment #69 from bernds at gcc dot gnu dot org 2010-08-06 09:29 --- (In reply to comment #68) Also, since fwprop can lengthen lifetimes arbitrarily (though this wouldn't happen often) propagate_rtx actually forbids copy propagation of hard registers: if (REG_P (new_rtx) REGNO (new_rtx) FIRST_PSEUDO_REGISTER) return NULL_RTX; Clearly that isn't working. Maybe it's because we have (zero_extend (hardreg))? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap
--- Comment #70 from bonzini at gnu dot org 2010-08-06 09:54 --- The real reason is the first: why is there no def for r25? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap
--- Comment #71 from bernds at codesourcery dot com 2010-08-06 09:57 --- Subject: Re: [4.6 regression] Revision 162270 failed to bootstrap On 08/06/2010 11:54 AM, bonzini at gnu dot org wrote: --- Comment #70 from bonzini at gnu dot org 2010-08-06 09:54 --- The real reason is the first: why is there no def for r25? Because it's an incoming argument. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap
--- Comment #72 from bonzini at gnu dot org 2010-08-06 10:00 --- No, why is there no def for r25 _where it is clobbered_? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap
--- Comment #73 from bernds at codesourcery dot com 2010-08-06 10:27
---
Subject: Re: [4.6 regression] Revision 162270 failed
to bootstrap
On 08/06/2010 12:00 PM, bonzini at gnu dot org wrote:
--- Comment #72 from bonzini at gnu dot org 2010-08-06 10:00 ---
No, why is there no def for r25 _where it is clobbered_?
There is. The problem seems to be that we first propagate into insn 15,
which then looks like
(insn 15 14 16 3 (set (reg:DI 67 [ obj.8+-4 ])
(sign_extend:DI (reg:SI 25 %r25 [ obj ])))
../../gcc/gcc/cfg.c:1211 139 {extendsidi2}
(expr_list:REG_DEAD (reg/v:DI 74 [ obj+-4 ])
(nil)))
and from there, we propagate into another insn. However, at this point,
insn 15 has no uses associated with it, so all_uses_available_at returns
true without doing anything.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
[Bug c/45204] gcc generates incorrect code
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-08-06 10:28 --- We need a testcase. Also please try -fno-strict-aliasing if you know the code is bogus. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45204
[Bug c++/45201] ICE: stack overflow during debug information generation
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-08-06 10:37 --- Works for me on x86_64-linux with -m32. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45201
[Bug bootstrap/45206] [4.6 regression] ICE in ix86_expand_epilogue compiling libgcc
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-08-06 11:06 ---
Confirmed.
struct _Unwind_Context { void *ra; };
void _Unwind_RaiseException(void)
{
struct _Unwind_Context this_context, cur_context;
long offset = uw_install_context_1 ((this_context), (cur_context));
void *handler = __builtin_frob_return_addr ((cur_context)-ra);
__builtin_eh_return (offset, handler);
}
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rth at gcc dot gnu dot org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2010-08-06 11:06:16
date||
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45206
[Bug middle-end/44121] [4.6 Regression] multiple char-related fails.
--- Comment #18 from dominiq at lps dot ens dot fr 2010-08-06 11:08 --- AFAICT this pr seems to have been fixed between revisions 162881 (fail) and 162920 (OK) at least on x86_64-apple-darwin10.4.0 (-m32 and -m64) and powerpc-apple-darwin9 (-m32, see http://gcc.gnu.org/ml/gcc-testresults/2010-08/msg00530.html ). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44121
[Bug tree-optimization/45199] [4.6 Regression] ICE in loop distribution at -O3
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-08-06 11:11 --- Confirmed. Program received signal SIGSEGV, Segmentation fault. 0x00b6a1e4 in gimple_bb (g=0x0) at /space/rguenther/src/svn/trunk/gcc/gimple.h:1148 1148 return g-gsbase.bb; (gdb) up #1 0x00b6af64 in find_uses_to_rename_use (bb=0x75b010d0, use=0x75aeb058, use_blocks=0x1868620, need_phis=0x186ada8) at /space/rguenther/src/svn/trunk/gcc/tree-ssa-loop-manip.c:247 247 def_bb = gimple_bb (SSA_NAME_DEF_STMT (use)); (gdb) p use $1 = (tree) 0x75aeb058 (gdb) call debug_tree ($1) ssa_name 0x75aeb058 nothrow var var_decl 0x75ad9dc0 D.1597def_stmt version 7 in-free-list -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-08-06 11:11:19 date|| Summary|ICE in loop distribution|[4.6 Regression] ICE in loop ||distribution at -O3 Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45199
[Bug c/45207] The -Os flag generates wrong code for ARM966e-s
--- Comment #6 from fredrik dot hederstierna at securitas-direct dot com 2010-08-06 12:06 --- Yes you are right, unfortunately I just had problems to break out any small test case from our sources. I think I found out what is the source of the problems. The -Os disable alignment of functions. In some case I try to force alignment void __attribute__((aligned(4))) _irq_off(void); since we have some thumb-arm trampoline functions to modify cpu-flags. I guess somehow some functions got thumb-aligned, but I try to investigate this further. /Fredrik -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45207
[Bug middle-end/44121] [4.6 Regression] multiple char-related fails.
--- Comment #19 from dominiq at lps dot ens dot fr 2010-08-06 12:48 --- From IRC: martinj dominiq: r162911 and r162912 ...and no other recent change seems relevant martinj dominiq: whether the bug is fixed or just hidden, I can't really tell at the moment -- dominiq at lps dot ens dot fr changed: What|Removed |Added CC||mjambor at suse dot cz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44121
[Bug c++/45209] New: coredump in exception handling (gcc44, FreeBSD 7.2)
Hello,
I have coredump for exception handling in a c++ program using dynamic library.
I wrote the minimal application using dlopen to load a libtest_so.so and
execute functions in so with dlsym. In the libtest_so.so I throw an exception
and try to catch it.
Source code:
1) main application test_exception (test.cpp)
#include cstdio
#include dlfcn.h
typedef void (*TFuncVoid)();
int main() {
void* testlib = dlopen(./libtest_so.so, RTLD_NOW | RTLD_GLOBAL);
TFuncVoid FFunc = 0;
FFunc = TFuncVoid(dlsym(testlib, ThrowCatchException));
if (FFunc) {
try {
FFunc();
} catch (...) {
printf(Catched in test.cpp. \n);
}
}
return 0;
}
2) library libtest_so.so (test_so.cpp)
#include cstdio
extern C void ThrowCatchException() {
try {
throw 5;
} catch (int) {
printf(catch (int): la-la-la \n);
} catch (...) {
printf(catch (...): la-la-la \n);
}
}
3) Commands for compiling the application:
g++44 -g -Wall -fPIC -fexceptions
-DNATIVE_INCLUDE_PATH=/usr/local/lib/gcc44/include/c++/ -Iinclude_path_1
-Iinclude_path_2 -o CMakeFiles/test_exception.dir/test.cpp.o -c
path_to_src/test/test.cpp
g++44 -nostdlib /usr/lib/crt1.o /usr/lib/crti.o
/usr/local/lib/gcc44/gcc/x86_64-portbld-freebsd7.2/4.4.1/crtbegin.o -g -Wall
-fPIC -fexceptions -DNATIVE_INCLUDE_PATH=/usr/local/lib/gcc44/include/c++/
-Wl,-E CMakeFiles/test_exception.dir/test.cpp.o -o test_exception
/usr/local/lib/gcc44/gcc/x86_64-portbld-freebsd7.2/4.4.1/../../../libsupc++.a
/usr/local/lib/gcc44/gcc/x86_64-portbld-freebsd7.2/4.4.1/libgcc.a
/usr/local/lib/gcc44/gcc/x86_64-portbld-freebsd7.2/4.4.1/libgcc_eh.a -lc -lm
/usr/local/lib/gcc44/gcc/x86_64-portbld-freebsd7.2/4.4.1/crtend.o
/usr/lib/crtn.o
4) Commands for compiling the library:
g++44 -g -Wall -fPIC -fexceptions
-DNATIVE_INCLUDE_PATH=/usr/local/lib/gcc44/include/c++/ -Iinclude_path_1
-Iinclude_path_2 -o CMakeFiles/test_so.dir/test_so.cpp.o -c
path_to_src/test_so.cpp
g++44 -fPIC -g -Wall -fexceptions
-DNATIVE_INCLUDE_PATH=/usr/local/lib/gcc44/include/c++/ -shared
-Wl,-soname,libtest_so.so -o libtest_so.so CMakeFiles/test_so.dir/test_so.cpp.o
4) correct output (command ./test_exception):
catch (int): la-la-la
5) wrong result (command ./test_exception):
terminate called after throwing an instance of 'int'
Abort trap (core dumped)
6) my gcc configuration info (g++44 -v)
Using built-in specs.
Target: x86_64-portbld-freebsd7.2
Configured with: ./../gcc-4.4-20090616/configure --disable-nls
--with-system-zlib --with-libiconv-prefix=/usr/local --with-gmp=/usr/local
--program-suffix=44 --libdir=/usr/local/lib/gcc44
--libexecdir=/usr/local/libexec/gcc44
--with-gxx-include-dir=/usr/local/lib/gcc44/include/c++/ --disable-libgcj
--prefix=/usr/local --mandir=/usr/local/man --infodir=/usr/local/info/gcc44
--build=x86_64-portbld-freebsd7.2
Thread model: posix
gcc version 4.4.1 20090616 (prerelease) (GCC)
--
Summary: coredump in exception handling (gcc44, FreeBSD 7.2)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: skylanderr at gmail dot com
GCC host triplet: x86_64-unknown-freebsd7.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45209
[Bug c++/45209] coredump in exception handling (gcc44, FreeBSD 7.2)
--- Comment #1 from skylanderr at gmail dot com 2010-08-06 13:14 --- Created an attachment (id=21422) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21422action=view) the preprocessed file for tha application -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45209
[Bug c++/45209] coredump in exception handling (gcc44, FreeBSD 7.2)
--- Comment #2 from skylanderr at gmail dot com 2010-08-06 13:15 --- Created an attachment (id=21423) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21423action=view) the preprocessed file for the library -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45209
[Bug c/45204] gcc generates incorrect code
--- Comment #2 from contact at philipashmore dot com 2010-08-06 13:37 --- It's exactly what I tried first - I know there are obvious cases as per your frequently reported bugs section. I wanted the compiler to tell me where the aliasing was occurring in these and in any less obvious places so I could disable aliasing optimizations in these cases. Currently it's missing even the ones the docs claims it should spot - pointer- uintptr_t - pointer. Previous release of treedb didn't need -fno-strict-aliasing, or did they? If the compiler can't spot aliasing should -fno-strict-aliasing be the default? -- contact at philipashmore dot com changed: What|Removed |Added CC||contact at philipashmore dot ||com Status|WAITING |UNCONFIRMED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45204
[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap
--- Comment #74 from bonzini at gnu dot org 2010-08-06 13:38 --- Thanks for the help. I'll look at it tomorrow/next week. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
[Bug c/45204] gcc generates incorrect code
--- Comment #3 from contact at philipashmore dot com 2010-08-06 13:52 --- Maybe I should add that the 0.6.0-beta1 release in GIT passed uintptr_t - sized structures by value and the compiler spotted the aliasing, which is why I introduced the pointer - uintptr_t - pointer hacks to begin with. Without passing structs by value the compiler doesn't report the aliasing problems. I'm being sincere when I say that if the compiler really can't spot aliasing problems then -fno-strict-aliasing should be on by default. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45204
[Bug c/45204] gcc generates incorrect code
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-08-06 13:55 --- (In reply to comment #3) Maybe I should add that the 0.6.0-beta1 release in GIT passed uintptr_t - sized structures by value and the compiler spotted the aliasing, which is why I introduced the pointer - uintptr_t - pointer hacks to begin with. Without passing structs by value the compiler doesn't report the aliasing problems. I'm being sincere when I say that if the compiler really can't spot aliasing problems then -fno-strict-aliasing should be on by default. The compiler can spot all aliasing that is permitted by the language standard. If you are writing non-C code then you need to tell that to the compiler via -fno-strict-aliasing. Merely adding hacks to avoid the diagnostic (which can't be perfect, if we could detect the aliasing we wouldn't optimize based on the fact that it isn't there). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45204
[Bug target/45209] coredump in exception handling (gcc44, FreeBSD 7.2)
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-08-06 14:08 --- Works on x86_64-linux. I suspect that linking libgcc and libgcc_eh statically causes the problem for you as I can reproduce the segfault when linking the whole test application statically. Thus, this sounds like an installation problem on your side. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|c++ |target GCC target triplet||x86_64-unknown-freebsd7.2 Version|unknown |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45209
[Bug bootstrap/45174] Make fails in zlib
--- Comment #14 from dschlic1 at gmail dot com 2010-08-06 14:35 --- Subject: Make fails in zlib Hello; Can you put that in layman's terms? I am using the standard GNU linker and assembler. I run Ubuntu 10.04 LTS with all of the latest patches. Thank You, Donald Schlicht On Thu, Aug 5, 2010 at 1:01 PM, rwild at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: --- Comment #13 from rwild at gcc dot gnu dot org 2010-08-05 17:01 --- config.log excerpt from zlib: configure:7903: result: yes configure:7936: checking whether the gcc -m64 linker (ld) supports shared libraries configure:9020: result: yes configure:9265: checking dynamic linker characteristics configure:9710: error: Link tests are not allowed after GCC_NO_EXECUTABLES. which corresponds to this code in zlib/configure, from AC_PROG_LIBTOOL: lt_cv_shlibpath_overrides_runpath=no save_LDFLAGS=$LDFLAGS save_libdir=$libdir eval libdir=/foo; wl=\$lt_prog_compiler_wl\; \ LDFLAGS=\\$LDFLAGS $hardcode_libdir_flag_spec\ if test x$gcc_no_link = xyes; then as_fn_error Link tests are not allowed after GCC_NO_EXECUTABLES. $LINENO 5 Either GCC or the user needs to prime cache variables in the way this test shows: http://git.savannah.gnu.org/cgit/libtool.git/tree/tests/no-executables.at (There is currently one item missing there for AIX, which is relevant for GCC but irrelevant to this particular PR). This same issue supposedly holds for other GCC directories in which GCC_NO_EXECUTABLES is used; it might just be latent. Question is, what values the variables should be primed with. In general, tough one. In this specific case: find out whether your linker sets DT_RUNPATH upon -Wl,-rpath (yes) or only DT_RPATH (no). Pass lt_cv_shlibpath_overrides_runpath=no or =yes to configure accordingly. Hmm. How can I ensure this primes the cache for host directories only? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45174
[Bug libstdc++/45133] [c++0x] std::future will crash with NULL deref if get() is called twice
--- Comment #4 from redi at gcc dot gnu dot org 2010-08-06 15:36 --- The committee is currently in the middle of re-designing future::get so I'll wait and see what happens. It looks as though it's going to be renamed and throw if called twice. -- redi at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|SUSPENDED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45133
[Bug fortran/45210] New: compilation error
A subroutine fails to compile with an apparently incorrect error message. It is a piece of the scientific software called nextnano3. I will attach it to this bug. -- Summary: compilation error Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sliwa at blue dot cft dot edu dot pl GCC build triplet: x86_64-redhat-linux GCC host triplet: x86_64-redhat-linux GCC target triplet: x86_64-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45210
[Bug fortran/45210] compilation error
--- Comment #1 from sliwa at blue dot cft dot edu dot pl 2010-08-06 16:43 --- Created an attachment (id=21424) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21424action=view) p1.f90 first part of the test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45210
[Bug fortran/45210] compilation error
--- Comment #2 from sliwa at blue dot cft dot edu dot pl 2010-08-06 16:45 --- Created an attachment (id=21425) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21425action=view) second part of the test case This file contains to routines. The error is reported in the first one, but after removing the second one no error is reported. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45210
[Bug fortran/45210] compilation error
--- Comment #3 from sliwa at blue dot cft dot edu dot pl 2010-08-06 16:49 --- To reproduce: 1. gfortran -c p1.f90 (no message) 2. gfortran -c p2.f90 p2.f90:66.25: CALL ijk_to_i_j_k(i_j_k,i_j_k_fid,grid_size) 1 Error: Rank mismatch in argument 'j' at (1) (0 and 1) 3. Now copy the first routine from p2.f90 to p2a.f90 gfortran -c p2a.f90 (no message) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45210
[Bug fortran/45211] New: C interoperable error when compiling BIND(C) function in a module.
gfortran (all versions 4.2-4.5) reports the error when trying to compile code below: Error: Type 'link_info' at (1) is a parameter to the BIND(C) procedure 'liter_cb' but is not C interoperable because derived type 'info_t' is not C interoperable when I remove the module and compile just the function it compiles fine. info_t is interoperable with C MODULE liter_cb_mod USE ISO_C_BINDING CONTAINS FUNCTION liter_cb(link_info) bind(C) USE ISO_C_BINDING IMPLICIT NONE INTEGER(c_int) liter_cb TYPE, bind(C) :: info_t INTEGER(c_int) :: type END TYPE info_t TYPE(info_t) :: link_info liter_cb = 0 END FUNCTION liter_cb END MODULE liter_cb_mod -- Summary: C interoperable error when compiling BIND(C) function in a module. Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: brtnfld at hdfgroup dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45211
[Bug fortran/44660] [4.4 Regression] ICE in resolve_equivalence()
--- Comment #23 from mikael at gcc dot gnu dot org 2010-08-06 17:17 --- Subject: Bug 44660 Author: mikael Date: Fri Aug 6 17:17:37 2010 New Revision: 162949 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162949 Log: 2010-08-06 Mikael Morin mik...@gcc.gnu.org PR fortran/44660 * gfortran.h (gfc_namespace): New field old_equiv. (gfc_free_equiv_until): New prototype. * match.c (gfc_free_equiv_until): New, renamed from gfc_free_equiv with a parameterized stop condition. (gfc_free_equiv): Use gfc_free_equiv_until. * parse.c (next_statement): Save equivalence list. (reject_statement): Restore equivalence list. Modified: branches/gcc-4_4-branch/gcc/fortran/ChangeLog branches/gcc-4_4-branch/gcc/fortran/gfortran.h branches/gcc-4_4-branch/gcc/fortran/match.c branches/gcc-4_4-branch/gcc/fortran/parse.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44660
[Bug fortran/44660] ICE in resolve_equivalence()
--- Comment #24 from mikael at gcc dot gnu dot org 2010-08-06 17:19 --- One more down -- mikael at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail|4.4.5 | Known to work|4.3.6 4.6.0 4.5.1 |4.3.6 4.4.5 4.5.1 4.6.0 Resolution||FIXED Summary|[4.4 Regression] ICE in |ICE in resolve_equivalence() |resolve_equivalence() | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44660
[Bug bootstrap/45174] Make fails in zlib
--- Comment #15 from rwild at gcc dot gnu dot org 2010-08-06 17:22 --- (In reply to comment #14) Can you put that in layman's terms? Yes; sorry for the complicated and technical response. As far as I can see, there is at the moment no simple way to avoid this issue with a configure command-line switch, so I'll describe an approach that hopefully works around the issue for now: In the build tree where the error occurred, there should be an empty file named something like: arm-unknown-elf/zlib/config.cache Please open that file with a text editor and add the line lt_cv_shlibpath_overrides_runpath=no Then rerun make. Please report back if that works or not; if it doesn't, then find the first error message in the output and cut and paste 50 lines of output from a few lines above that error message. Thanks. I'll write to the gcc list about how to improve configury so that this hopefully becomes easier or unnecessary in the future. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45174
[Bug fortran/45210] compilation error
--- Comment #4 from dominiq at lps dot ens dot fr 2010-08-06 17:22 --- Confirmed on 4.4.4 and 4.5.0, but the test compiles with trunk (with/without -fno-whole-file). Now I see: ... CALL ijk_to_i_j_k(i_j_k,i_j_k_fid,grid_size) ... SUBROUTINE ijk_to_i_j_k(i,j,k,size,i_j_k) The call has 3 arguments and the subroutine 5. In addition i_j_k_fid is a rank one array and j a scalar, so the error makes sense for me. What I don't understand is why this is not detected with 4.6. Should not the summary be [4.6 Regression] missing error? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45210
[Bug fortran/45211] C interoperable error when compiling BIND(C) function in a module.
--- Comment #1 from dominiq at lps dot ens dot fr 2010-08-06 17:26 --- Confirmed also with trunk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45211
[Bug fortran/45210] compilation error
--- Comment #5 from sliwa at blue dot cft dot edu dot pl 2010-08-06 18:07 --- Your right, I assumed blindly that this code makes at least some sense (I modified it to remove the dependencies, but the main issue remains the same). However, it compiles with Pathscale 3.1 and SunStudio 12.1 (probably also others, as a Windows binary of this beautiful artwork is available). Is it normal that a routine can prevent compilation of a preceding one? PS. A colleague of mine is going to use this program compiled with one of the above compilers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45210
[Bug fortran/45210] compilation error
--- Comment #6 from dominiq at lps dot ens dot fr 2010-08-06 18:42 --- Your right, I assumed blindly that this code makes at least some sense (I modified it to remove the dependencies, but the main issue remains the same). However, it compiles with Pathscale 3.1 and SunStudio 12.1 (probably also others, as a Windows binary of this beautiful artwork is available). Is it normal that a routine can prevent compilation of a preceding one? Well, I cannot see how the code you POSTED (you may have introduced a problem when reducing the code, it is quite common) could be valid according the Fortran standard. However I think the constraints that the actual and dummy must match are put under a shall, i.e. the burden is on the user and the compiler may or may not detect the problem (put the call and the subroutine in two different files instead of in a CONTAINS unit and the compiler has no way to check that the actual and dummy argument match: a very common mistake when using libraries). CCed Steven G. Kargl for additional opinion. -- dominiq at lps dot ens dot fr changed: What|Removed |Added CC||sgk at troutmask dot apl dot ||washington dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45210
[Bug target/24178] [4.0/4.1 regression] generates code that produces unaligned access exceptions
--- Comment #15 from ubizjak at gmail dot com 2010-08-06 19:33 --- This one started to fail on mainline recently. f: .frame $30,0,$26,0 .prologue 0 lda $1,18($16) ldq_u $0,18($16) extbl $0,$1,$0 ret $31,($26),1 .end f The testcase passed with r161055 [1] and failed with r161806 [2]. In between is Richi's mem-ref2 merge... [1] http://gcc.gnu.org/ml/gcc-testresults/2010-06/msg02114.html [2] http://gcc.gnu.org/ml/gcc-testresults/2010-07/msg00417.html -- ubizjak at gmail dot com changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24178
[Bug c/45207] The -Os flag generates wrong code for ARM966e-s
--- Comment #7 from siarhei dot siamashka at gmail dot com 2010-08-06 19:36 --- Do you have any packed structs? I wonder if the problem could be somehow related to PR45070. But it's hard to say anything until you narrow down the problem to a smaller testcase. -- siarhei dot siamashka at gmail dot com changed: What|Removed |Added CC||siarhei dot siamashka at ||gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45207
[Bug target/24178] [4.6 Regression] generates code that produces unaligned access exceptions
-- ubizjak at gmail dot com changed: What|Removed |Added Summary|[4.0/4.1 regression]|[4.6 Regression] generates |generates code that produces|code that produces unaligned |unaligned access exceptions |access exceptions Target Milestone|4.0.3 |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24178
[Bug target/24178] [4.0/4.1 regression] generates code that produces unaligned access exceptions
--- Comment #16 from rguenth at gcc dot gnu dot org 2010-08-06 19:45 --- Can you instead open a new bug please? Thx. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED Summary|[4.6 Regression] generates |[4.0/4.1 regression] |code that produces unaligned|generates code that produces |access exceptions |unaligned access exceptions Target Milestone|4.6.0 |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24178
[Bug target/45212] New: FAIL: gcc.target/alpha/pr24178.c scan-assembler ldl.*,18\\\\(
gcc.target/alpha/PR24178.c started to fail on mainline recently: FAIL: gcc.target/alpha/pr24178.c scan-assembler ldl.*,18( The problem is, that we don't generate expected ldl insn, but: f: .frame $30,0,$26,0 .prologue 0 lda $1,18($16) ldq_u $0,18($16) extbl $0,$1,$0 ret $31,($26),1 .end f The generated code is similar to what PR24178 fixed, see PR24178, comment #9. The testcase passed with r161055 [1] and failed with r161806 [2]. In between is Richi's mem-ref2 merge... [1] http://gcc.gnu.org/ml/gcc-testresults/2010-06/msg02114.html [2] http://gcc.gnu.org/ml/gcc-testresults/2010-07/msg00417.html -- Summary: FAIL: gcc.target/alpha/pr24178.c scan-assembler ldl.*,18( Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ubizjak at gmail dot com GCC target triplet: alphaev68-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45212
[Bug target/24178] [4.0/4.1 regression] generates code that produces unaligned access exceptions
--- Comment #17 from ubizjak at gmail dot com 2010-08-06 20:00 --- (In reply to comment #16) Can you instead open a new bug please? Thx. Sure. PR45212. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24178
[Bug target/45212] [4.6 Regression] FAIL: gcc.target/alpha/pr24178.c scan-assembler ldl.*,18\\\\(
--- Comment #1 from ubizjak at gmail dot com 2010-08-06 20:14 --- The problem is, that we enter alpha_expand_mov_nobwx with operand[1]: (mem/s:QI (plus:DI (reg/v/f:DI 72 [ p10 ]) (const_int 18 [0x12])) [0+8 S1 A16]) This fails aligned_memory_operand (operands[1], mode) check. OTOH, for gcc-4_5 branch, alpha_expand_mov_nobwx is called with: (mem/s:QI (plus:DI (reg/v/f:DI 74 [ p10 ]) (const_int 18 [0x12])) [0 S1 A64]) -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-08-06 20:14:13 date|| Summary|FAIL: |[4.6 Regression] FAIL: |gcc.target/alpha/pr24178.c |gcc.target/alpha/pr24178.c |scan-assembler ldl.*,18(|scan-assembler ldl.*,18( Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45212
[Bug target/45212] [4.6 Regression] FAIL: gcc.target/alpha/pr24178.c scan-assembler ldl.*,18\\\\(
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-08-06 20:29 --- Mine. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-08-06 20:14:13 |2010-08-06 20:29:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45212
[Bug target/45213] New: suffix or operands invalid for `push' triggered by optimisations on x86_64
The attached source file gives: $ gcc -c t.c -Os -fno-omit-frame-pointer /tmp/ccAuCzVe.s: Assembler messages: /tmp/ccAuCzVe.s:16: Error: suffix or operands invalid for `push' It complains on the line: pushq $0x3f80 Reproduced on: Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.5.0/work/gcc-4.5.0/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.5.0 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.0/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.5.0 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.5.0/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.5.0/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.0/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --without-ppl --without-cloog --disable-lto --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --enable-multilib --enable-libmudflap --disable-libssp --enable-libgomp --enable-cld --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.5.0/python --disable-libgcj --enable-languages=c,c++ --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.5.0 p1.2, pie-0.4.5' Thread model: posix gcc version 4.5.0 (Gentoo 4.5.0 p1.2, pie-0.4.5) Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --with-cpu=generic --host=x86_64-redhat-linux Thread model: posix gcc version 4.1.2 20070925 (Red Hat 4.1.2-27) -- Summary: suffix or operands invalid for `push' triggered by optimisations on x86_64 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: philip dot taylor at cl dot cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45213
[Bug target/45213] suffix or operands invalid for `push' triggered by optimisations on x86_64
--- Comment #1 from philip dot taylor at cl dot cam dot ac dot uk 2010-08-06 20:37 --- Created an attachment (id=21426) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21426action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45213
[Bug target/45213] suffix or operands invalid for `push' triggered by optimisations on x86_64
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-08-06 20:44 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC target triplet||x86_64-*-* Keywords||assemble-failure Known to fail||4.1.2 4.3.2 4.2.2 4.6.0 Last reconfirmed|-00-00 00:00:00 |2010-08-06 20:44:01 date|| Version|unknown |4.5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45213
[Bug libgomp/45192] OpenMP fails in DLLs
--- Comment #3 from john at quivinco dot com 2010-08-06 20:48 --- I just read this... TDM-GCC has been built to allow the use of GCC's -fopenmp option for generating parallel code as specified by the OpenMP API. (See http://gcc.gnu.org/onlinedocs/libgomp/ for details.) If you want to use OpenMP in your programs, be sure to install the openmp optional package. The OpenMP support in the TDM-GCC builds has received very little testing; if you find build or packaging problems, please send a bug report (see BUGS above). LibGOMP, GCC's implementation of OpenMP, currently only supports the use of the POSIX Threads (pthreads) api for implementing its threading model. Because the MinGW project itself doesn't distribute a pthreads implementation, the pthreads-win32 library, available from http://sourceware.org/pthreads-win32/, is included in this distribution. If you aren't familiar with pthreads-win32, please read the file pthreads-win32-README for more information, or the documentation available at the website referenced above. pthreads-win32 is distributed under the terms of the LGPL; see COPYING.lib-gcc-tdm.txt for details. In order to correctly compile code that utilizes OpenMP/libGOMP, you need to add the -fopenmp option at compile time AND link time. By default, this will link the standard C-cleanup DLL version of pthreads-win32 to your program, which means that you will need to ensure that the file pthreadGC2.dll (included in the bin subdirectory in the openmp package) can be found by your program. If you plan to distribute a program that relies on pthreads-win32, be sure to understand and comply with the terms of the LGPL (see COPYING.lib-gcc-tdm.txt). libpthread.a is included in the lib subdirectory of the openmp package along with two other pthreads library files: - libpthreadGC2-static.a provides a static version of the pthreads-win32 library, but it requires some additional non-POSIX-compliant startup code to be included in your program. See pthreads-win32-README for details. - libpthreadGCE2.a provides a version of the pthreads-win32 library with a somewhat safer response in the face of unexpected C++ exceptions. The creators of the pthreads-win32 library recommend, however, that this version not be used, because code written to rely on this is less portable. Anyone tried this or know where to get pthreadGC2.dll? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45192
[Bug target/45213] suffix or operands invalid for `push' triggered by optimisations on x86_64
--- Comment #3 from ubizjak at gmail dot com 2010-08-06 20:53 --- (In reply to comment #0) It complains on the line: pushq $0x3f80 No, it doesn't. Assembler complains on: pushq $0xbf80 Which makes this a binutils bug. Let's ask H.J. -- ubizjak at gmail dot com changed: What|Removed |Added CC||hjl dot tools at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45213
[Bug target/45213] suffix or operands invalid for `push' triggered by optimisations on x86_64
--- Comment #4 from hjl dot tools at gmail dot com 2010-08-06 21:02 --- I opened: http://www.sourceware.org/bugzilla/show_bug.cgi?id=11893 -- hjl dot tools at gmail dot com changed: What|Removed |Added URL||http://www.sourceware.org/bu ||gzilla/show_bug.cgi?id=11893 Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45213
[Bug fortran/45210] compilation error
--- Comment #7 from dominiq at lps dot ens dot fr 2010-08-06 21:09 --- Thanks to Thomas König, the mystery is sorted out: both p1.f90 and p2.f90 contain a subroutine ijk_to_i_j_k. In p1 the subroutine has the right dummy arguments for the call, while the one in p2 has wrong ones. Due to USE module_ijk_to_i_j_k ,ONLY:ijk_to_i_j_k in SUBROUTINE i_j_k_to_ijk(i_j_k,size,i,j,k), the call to ijk_to_i_j_k should use the one in p1 (as with 4.6) and not the one in p2 (as with 4.4 or 4.5). So if the above is right, the bug has been fixed in 4.6, but not backported to 4.5. Can you check where and with actual arguments the subroutine i_j_k_to_ijk is called in the full code? If all the calls are to the subroutine in p1, you can probably remove the one in p2. If both subroutines are called, some with the argument list corresponding to p1 and some with the argument list corresponding to p2, you can try to rename one of the subroutines. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45210
[Bug fortran/45057] Unneeded temporary / missed bounds violation for PACK
-- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-08-06 21:21:08 date|| Summary|Unneded temporary / missed |Unneeded temporary / missed |bounds violation for PACK |bounds violation for PACK http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45057
[Bug tree-optimization/45214] New: Poor initial RTL for bitfield operations
The attached testcase, from gcc's own gimplify.c, is optimized poorly at the tree stage. Initial RTL has ;; t_1-gsbase.plf = D.2014_8; (insn 8 6 9 (set (reg:QI 65) (mem/s:QI (plus:SI (reg/v/f:SI 58 [ t ]) (const_int 1 [0x1])) [0+1 S1 A8])) gimplify.i:48 -1 (nil)) (insn 9 8 10 (parallel [ (set (reg:QI 64) (lshiftrt:QI (reg:QI 65) (const_int 3 [0x3]))) (clobber (reg:CC 17 flags)) ]) gimplify.i:48 -1 (expr_list:REG_EQUAL (lshiftrt:QI (mem/s:QI (plus:SI (reg/v/f:SI 58 [ t ]) (const_int 1 [0x1])) [0+1 S1 A8]) (const_int 3 [0x3])) (nil))) (insn 10 9 11 (parallel [ (set (reg:QI 66) (and:QI (reg:QI 64) (const_int 3 [0x3]))) (clobber (reg:CC 17 flags)) ]) gimplify.i:48 -1 (nil)) (insn 11 10 13 (parallel [ (set (reg:QI 67) (ior:QI (reg:QI 66) (const_int 1 [0x1]))) (clobber (reg:CC 17 flags)) ]) gimplify.i:48 -1 (nil)) (insn 13 11 14 (parallel [ (set (reg:QI 69) (and:QI (reg:QI 67) (const_int 3 [0x3]))) (clobber (reg:CC 17 flags)) ]) gimplify.i:48 -1 (nil)) (insn 14 13 15 (parallel [ (set (reg:QI 70) (ashift:QI (reg:QI 69) (const_int 3 [0x3]))) (clobber (reg:CC 17 flags)) ]) gimplify.i:48 -1 (nil)) (insn 15 14 16 (set (reg:QI 71) (mem/s/j:QI (plus:SI (reg/v/f:SI 58 [ t ]) (const_int 1 [0x1])) [0+1 S1 A8])) gimplify.i:48 -1 (nil)) (insn 16 15 17 (parallel [ (set (reg:QI 72) (and:QI (reg:QI 71) (const_int -25 [0xffe7]))) (clobber (reg:CC 17 flags)) ]) gimplify.i:48 -1 (nil)) (insn 17 16 18 (parallel [ (set (reg:QI 73) (ior:QI (reg:QI 72) (reg:QI 70))) (clobber (reg:CC 17 flags)) ]) gimplify.i:48 -1 (nil)) (insn 18 17 0 (set (mem/s/j:QI (plus:SI (reg/v/f:SI 58 [ t ]) (const_int 1 [0x1])) [0+1 S1 A8]) (reg:QI 73)) gimplify.i:48 -1 (nil)) This is not optimized by anything unless the combiner is extended to handle four insns. This PR should stay open even if the combiner is improved, until the tree optimizers handle this better. -- Summary: Poor initial RTL for bitfield operations Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bernds at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45214
[Bug tree-optimization/45214] Poor initial RTL for bitfield operations
--- Comment #1 from bernds at gcc dot gnu dot org 2010-08-06 21:21 --- Created an attachment (id=21427) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21427action=view) A testcase which shows the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45214
[Bug fortran/44235] array temporary with high upper bound
--- Comment #3 from steven at gcc dot gnu dot org 2010-08-06 21:24 --- What's the plan with the patch of comment #2? NB, the result of gfc_dep_compare_expr (l_start, r_start) could be cached instead of computed twice: + ((res = gfc_dep_compare_expr (l_start, r_start)) == 0 + || res == -1) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44235
[Bug tree-optimization/45215] New: Tree-optimization misses a trick with bit tests
The following testcase
int x (int t)
{
if (t 256)
return -26;
return 0;
}
can be implemented as a sequence of two shifts and one and operation:
movl4(%esp), %eax
sall$23, %eax
sarl$31, %eax
andl$-26, %eax
ret
Initial RTL generation produces a more complicated sequence which is not
optimized unless the combiner is extended to handle four insns. The tree
optimizers could be enhanced to handle this pattern and related ones, although
it would have to take costs into account, as on some targets other sequences
may be better.
--
Summary: Tree-optimization misses a trick with bit tests
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bernds at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45215
[Bug fortran/44235] array temporary with high upper bound
--- Comment #4 from dominiq at lps dot ens dot fr 2010-08-06 21:34 --- I am not to sure about the patch in comment #2 because the case should probably be handled by gfc_is_same_range and the patch does it in gfc_check_section_vs_section. Note that gfc_is_same_range has a line /* TODO: More sophisticated range comparison. */ In my opinion the right way to fix this pr would be to compare the starts and the extends, but so far I did not find how to do it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44235
[Bug tree-optimization/45214] Poor initial RTL for bitfield operations
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-08-06 21:48 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC|richard dot guenther at |rguenth at gcc dot gnu dot |gmail dot com |org Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2010-08-06 21:48:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45214
[Bug tree-optimization/45215] Tree-optimization misses a trick with bit tests
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-08-06 21:49 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC|richard dot guenther at |rguenth at gcc dot gnu dot |gmail dot com |org Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2010-08-06 21:49:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45215
[Bug target/45213] suffix or operands invalid for `push' triggered by optimisations on x86_64
--- Comment #5 from hjl dot tools at gmail dot com 2010-08-06 21:51 --- The bug is in gcc. pushq $imm32S only takes 32bit signed extended immediate. You can't push 0xbf80. Instead, you push -1082130432 or 0xbf80. -- hjl dot tools at gmail dot com changed: What|Removed |Added URL|http://www.sourceware.org/bu| |gzilla/show_bug.cgi?id=11893| Status|RESOLVED|REOPENED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45213
[Bug target/45213] suffix or operands invalid for `push' triggered by optimisations on x86_64
--- Comment #6 from hjl dot tools at gmail dot com 2010-08-06 22:10 ---
This patch:
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 204211a..3dfbede 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -12921,7 +12921,7 @@ ix86_print_operand (FILE *file, rtx x, int code)
if (ASSEMBLER_DIALECT == ASM_ATT)
putc ('$', file);
- fprintf (file, 0x%08lx, (long unsigned int) l);
+ fprintf (file, 0x%08lx, (long) (int) l);
}
/* These float cases don't actually occur as immediate operands. */
works for me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45213
[Bug tree-optimization/45216] New: Rotate expressions not recognized at tree level
We have RROTATE_EXPR and LROTATE_EXPR, but the patterns are not reliably
detected at the tree level. I'm attaching a testcase reduced from the Linux
kernel, which has at least one sequence that can be rewritten using a rolw
instruction:
movzwl %cx, %edx
movzwl %ax, %eax
shrw$8, %cx
movl%edx, -44(%ebp)
sall$8, %edx
movw%cx, -50(%ebp)
orw %dx, -50(%ebp)
Other opportunities exist. At the most basic level, a function like
unsigned short rol8 (unsigned short word, unsigned int shift)
{
return (word 8) | (word 8);
}
should be transformed at the tree level by recognizing the rotate.
--
Summary: Rotate expressions not recognized at tree level
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bernds at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45216
[Bug tree-optimization/45216] Rotate expressions not recognized at tree level
--- Comment #1 from bernds at gcc dot gnu dot org 2010-08-06 22:19 --- Created an attachment (id=21428) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21428action=view) A testcase which shows the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45216
[Bug tree-optimization/45217] New: Tree optimizations do not recognize partial stores
unsigned int bplpt;
void BPLPTH (unsigned short x)
{
bplpt = (bplpt 0x) | (x 16);
}
void BPLPTL (unsigned short x)
{
bplpt = (bplpt 0x) | x;
}
Here, nothing at the tree level recognizes that these functions implement
16-bit stores into a larger object. This is handled by the combiner, but in
its current state it fails to optimize BPLPTL as there are too many insns to
look at.
This bug should stay open until there is a tree-level solution that does not
rely on the RTL combiner.
--
Summary: Tree optimizations do not recognize partial stores
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bernds at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45217
[Bug fortran/45159] Unnecessary temporaries
--- Comment #14 from tkoenig at gcc dot gnu dot org 2010-08-06 22:33 --- Subject: Bug 45159 Author: tkoenig Date: Fri Aug 6 22:33:37 2010 New Revision: 162966 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162966 Log: 2010-08-06 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/45159 * dependency.c (check_section_vs_section): Handle cases where the start expression coincides with the lower or upper bound of the array. 2010-08-06 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/45159 * gfortran.dg/dependency_31.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/dependency_31.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dependency.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45159
[Bug c++/45200] ICE in template instantiation
--- Comment #6 from pinskia at gcc dot gnu dot org 2010-08-06 22:35 ---
Nice reduced testcase:
templatetypename T
struct remove_reference
{
typedef T type;
};
templatetypename TestType struct forward_as_lref{};
templatetypename Seq, typename N
struct apply1
{
typedef typename remove_referenceSeq::type seq;
typedef forward_as_lref typename seq::seq_type type;
};
templatetypename Seq
struct apply
{
typedef forward_as_lref typename remove_referenceSeq::type::seq_type
type;
};
struct reverse_view
{
typedef int seq_type;
};
int main()
{
applyreverse_view ::type a2;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45200
[Bug c++/45200] [4.5/4.6 Regression] ICE in template instantiation
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet|i686-pc-mingw32 | Keywords||ice-on-valid-code Known to fail||4.5.0 4.6.0 Known to work||4.4.3 Summary|ICE in template |[4.5/4.6 Regression] ICE in |instantiation |template instantiation Target Milestone|--- |4.5.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45200
[Bug target/45213] suffix or operands invalid for `push' triggered by optimisations on x86_64
--- Comment #7 from hjl dot tools at gmail dot com 2010-08-06 22:39 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00528.html -- hjl dot tools at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2010- ||08/msg00528.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45213
[Bug tree-optimization/45218] New: Mathematical simplification missed at tree-level
Consider
a = (x / 39) * 32 + (x % 39)
If we have no instruction to produce both the quotient and the remaineder, this
can be computed as
y = x / 39
z = x - y * 39
a = y * 32 + z
The last line can be simplified by substituting:
a = y * 32 + x - y * 39
a = y * (32 - 39) + x
a = x - y * 7
Testcase:
int i_size;
extern void foo (void);
int udf_check_anchor_block(int block)
{
i_size = ( ( ( (block) / 39 ) 5 ) + ( block % 39 ));
return 1;
}
The tree optimization phase misses this, and this PR should stay open until
that is resolved. The combiner can handle it if it is able to look at 4
instructions.
--
Summary: Mathematical simplification missed at tree-level
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bernds at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45218
[Bug fortran/44235] array temporary with high upper bound
--- Comment #5 from dominiq at lps dot ens dot fr 2010-08-06 22:49 ---
Note that the following patch I have in my tree for some time now also fix the
pr
--- gcc/fortran/dependency.c2010-08-07 00:37:34.0 +0200
+++ ../work/gcc/fortran/dependency.c2010-08-05 19:11:58.0 +0200
@@ -1172,8 +1172,8 @@ check_section_vs_section (gfc_array_ref
/* Check for forward dependencies x:y vs. x+1:z. */
if (l_dir == 1 r_dir == 1
- l_start r_start gfc_dep_compare_expr (l_start, r_start) == -1
- l_end r_end gfc_dep_compare_expr (l_end, r_end) == -1)
+ ((l_start r_start gfc_dep_compare_expr (l_start, r_start) ==
-1)
+ || (l_end r_end gfc_dep_compare_expr (l_end, r_end) == -1)))
{
/* Check that the strides are the same. */
if (!l_stride !r_stride)
@@ -1185,8 +1185,8 @@ check_section_vs_section (gfc_array_ref
/* Check for forward dependencies x:y:-1 vs. x-1:z:-1. */
if (l_dir == -1 r_dir == -1
- l_start r_start gfc_dep_compare_expr (l_start, r_start) == 1
- l_end r_end gfc_dep_compare_expr (l_end, r_end) == 1)
+ ((l_start r_start gfc_dep_compare_expr (l_start, r_start) == 1)
+ || (l_end r_end gfc_dep_compare_expr (l_end, r_end) == 1)))
{
/* Check that the strides are the same. */
if (!l_stride !r_stride)
This followed a discussion with Tobias Burnus on IRC. It assumes that the code
is valid, i.e., lhs and rhs has the same extent, otherwise creating a temporary
does make the code valid, even if the result is not the same with or without
temporary.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44235
[Bug tree-optimization/45218] Mathematical simplification missed at tree-level
-- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-08-06 22:51:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45218
[Bug tree-optimization/45219] New: [4.6 Regression] ICE: SIGSEGV in dominated_by_p (dominance.c:973) with -O2 -fprofile-generate
Command line: $ gcc -O2 -fprofile-generate testcase.c Valgrind output: ==8227== Invalid read of size 8 ==8227==at 0x60BB4B: dominated_by_p (dominance.c:973) ==8227==by 0x950317: dse_enter_block (tree-ssa-dse.c:198) ==8227==by 0xF18CC6: walk_dominator_tree (domwalk.c:188) ==8227==by 0x94F9F2: tree_ssa_dse (tree-ssa-dse.c:429) ==8227==by 0x7BD50B: execute_one_pass (passes.c:1564) ==8227==by 0x7BD7A4: execute_pass_list (passes.c:1619) ==8227==by 0x7BD7B6: execute_pass_list (passes.c:1620) ==8227==by 0x8FF355: tree_rest_of_compilation (tree-optimize.c:452) ==8227==by 0xAB6505: cgraph_expand_function (cgraphunit.c:1643) ==8227==by 0xAB9389: cgraph_optimize (cgraphunit.c:1722) ==8227==by 0xAB997A: cgraph_finalize_compilation_unit (cgraphunit.c:1185) ==8227==by 0x4DF88E: c_write_global_declarations (c-decl.c:9698) ==8227== Address 0x20 is not stack'd, malloc'd or (recently) free'd ==8227== testcase.c: In function 'foo': testcase.c:12:5: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Tested revisions: r162940 - crash r162456 - OK -- Summary: [4.6 Regression] ICE: SIGSEGV in dominated_by_p (dominance.c:973) with -O2 -fprofile-generate Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zsojka at seznam dot cz GCC host triplet: x86_64-pc-linux-gnu GCC target triplet: x86_64-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45219
[Bug tree-optimization/45219] [4.6 Regression] ICE: SIGSEGV in dominated_by_p (dominance.c:973) with -O2 -fprofile-generate
--- Comment #1 from zsojka at seznam dot cz 2010-08-06 23:00 --- Created an attachment (id=21429) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21429action=view) reduced testcase (from gcc.dg/tree-ssa/20041008-1.c) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45219
[Bug tree-optimization/45216] Rotate expressions not recognized at tree level
--- Comment #2 from steven at gcc dot gnu dot org 2010-08-06 23:02 --- pathetic... :) -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2010-08-06 23:02:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45216
[Bug tree-optimization/15596] [4.3/4.4/4.5/4.6 Regression] Missed optimization with bitfields with return value
--- Comment #18 from steven at gcc dot gnu dot org 2010-08-06 23:12 --- Martin, perhaps a test case you want to watch if you or someone else is going to play with SRA vs. bitfields. -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||jamborm at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15596
[Bug tree-optimization/45216] Rotate expressions not recognized at tree level
--- Comment #3 from steven at gcc dot gnu dot org 2010-08-06 23:17 --- Related to PR17886, where it says that: gcc can detect the (x y)|(x (bitwidth-y)) idiom for rotate and convert it into the machine rotate instruction. But it only works when y is a constant and is not long long. But apparently even this case is not detected anymore. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45216
[Bug target/44942] Bug in argument passing of long double
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2010-08-06 23:23 --- Subject: Bug 44942 Author: ebotcazou Date: Fri Aug 6 23:22:52 2010 New Revision: 162967 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162967 Log: PR target/44942 * config/sparc/sparc.c (function_arg_advance): Always take into account the padding, if any. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sparc/sparc.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44942
[Bug target/44942] Bug in argument passing of long double
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2010-08-06 23:23 --- Subject: Bug 44942 Author: ebotcazou Date: Fri Aug 6 23:23:12 2010 New Revision: 162968 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162968 Log: PR target/44942 * config/sparc/sparc.c (function_arg_advance): Always take into account the padding, if any. Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/config/sparc/sparc.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44942
[Bug target/44942] Bug in argument passing of long double
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2010-08-06 23:23 --- Subject: Bug 44942 Author: ebotcazou Date: Fri Aug 6 23:23:29 2010 New Revision: 162969 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162969 Log: PR target/44942 * config/sparc/sparc.c (function_arg_advance): Always take into account the padding, if any. Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/config/sparc/sparc.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44942
[Bug tree-optimization/45216] Rotate expressions not recognized at tree level
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-08-06 23:41 --- Fold used to detect these. Maybe we're now having different conversions inbetween. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC|richard dot guenther at |rguenth at gcc dot gnu dot |gmail dot com |org Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45216
[Bug tree-optimization/45217] Tree optimizations do not recognize partial stores
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-08-06 23:44 --- Confirmed. BIT_FIELD_EXPR would be a good match for this. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC|richard dot guenther at |rguenth at gcc dot gnu dot |gmail dot com |org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2010-08-06 23:44:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45217
[Bug bootstrap/45174] Make fails in zlib
--- Comment #16 from dschlic1 at gmail dot com 2010-08-07 00:18 ---
Subject: Re: Make fails in zlib
Hello;
I changed the value of lt_cv_shlibpath_overrides_runpath (it was set to
the result of an equality statement). No joy. The log is attached.
Results from the terminal are:
don...@donald-desktop:~$ sh Try15.sh /home/donald arm-elf 5
Found Linux OS.
**
* Building gcc-4.5.1-boot
**
make[3]: *** No rule to make target `all'. Stop.
make[2]: *** [multi-do] Error 1
make[1]: *** [all-multi] Error 2
make: *** [all-zlib] Error 2
make: *** Waiting for unfinished jobs
don...@donald-desktop:~$
Previously to placing this bug report, I tried to find the source of
the error. The error occurs in this piece of code from configure in the
zlib source directory:
if test ${lt_cv_ld_exported_symbols_list+set} = set; then :
$as_echo_n (cached) 6
else
lt_cv_ld_exported_symbols_list=no
save_LDFLAGS=$LDFLAGS
echo _main conftest.sym
LDFLAGS=$LDFLAGS -Wl,-exported_symbols_list,conftest.sym
if test x$gcc_no_link = xyes; then
as_fn_error Link tests are not allowed after GCC_NO_EXECUTABLES.
$LINENO 5
fi
This piece of code is executed twice, first with
lt_cv_ld_exported_symbols_list set to blank, and gcc_no_link set to
blank. lt_cv_ld_exported_symbols_list is set to no because the else part
of the if statement is executed. Because gcc_no_link is not set, no
error is triggered.
However on the second pass, lt_cv_ld_exported_symbols_list has lost its
value (is blank), however gcc_no_link is set to yes. Result error. I
have not found out why lt_cv_ld_exported_symbols_list loses its value on
the second pass. LDFLAGS also loses its value on the second pass.
Thank You,
Donald Schlicht
--- Comment #17 from dschlic1 at gmail dot com 2010-08-07 00:18 ---
Created an attachment (id=21430)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21430action=view)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45174
[Bug tree-optimization/45220] New: [4.6 Regression] libjava/libltdl/ltdl.c:1272:1: internal compiler error: Segmenta
/test/gnu/gcc/objdir/./gcc/xgcc -B/test/gnu/gcc/objdir/./gcc/ -B/opt/gnu/gcc/gc c-4.6.0/hppa2.0w-hp-hpux11.11/bin/ -B/opt/gnu/gcc/gcc-4.6.0/hppa2.0w-hp-hpux11.1 1/lib/ -isystem /opt/gnu/gcc/gcc-4.6.0/hppa2.0w-hp-hpux11.11/include -isystem /o pt/gnu/gcc/gcc-4.6.0/hppa2.0w-hp-hpux11.11/sys-include -DHAVE_CONFIG_H -I. -I../ ../../../gcc/libjava/libltdl -g -O2 -c ../../../../gcc/libjava/libltdl/ltdl.c - fPIC -DPIC -o .libs/ltdl.o /test/gnu/gcc/objdir/./gcc/xgcc -B/test/gnu/gcc/objdir/./gcc/ -B/opt/gnu/gcc/gcc -4.6.0/hppa2.0w-hp-hpux11.11/bin/ -B/opt/gnu/gcc/gcc-4.6.0/hppa2.0w-hp-hpux11.11 /lib/ -isystem /opt/gnu/gcc/gcc-4.6.0/hppa2.0w-hp-hpux11.11/include -isystem /op t/gnu/gcc/gcc-4.6.0/hppa2.0w-hp-hpux11.11/sys-include-c -g -O2 -W -Wall -g natpg s-fileio.adb -o s-fileio.o s-fileio.adb: In function 'System.File_Io.Close': s-fileio.adb:308:10: warning: 'Errno' may be used uninitialized in this function [-Wuninitialized] ../../../../gcc/libjava/libltdl/ltdl.c: In function 'sys_shl_sym': ../../../../gcc/libjava/libltdl/ltdl.c:1272:1: internal compiler error: Segmenta tion fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[4]: *** [ltdl.lo] Error 1 make[4]: Leaving directory `/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libjava/l ibltdl' make[3]: *** [all] Error 2 make[3]: Leaving directory `/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libjava/l ibltdl' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libjava' make[1]: *** [all-target-libjava] Error 2 make[1]: *** Waiting for unfinished jobs -bash-3.2$ ./xgcc -B./ -v Reading specs from ./specs COLLECT_GCC=./xgcc COLLECT_LTO_WRAPPER=./lto-wrapper Target: hppa2.0w-hp-hpux11.11 Configured with: ../gcc/configure --with-gnu-as --with-as=/opt/gnu/bin/as --enable-shared --with-local-prefix=/opt/gnu --prefix=/opt/gnu/gcc/gcc-4.6.0 --with-gmp=/opt/gnu/gcc/gcc-4.6.0 --enable-threads=posix --enable-debug=no --disable-nls --without-cloog --without-ppl --enable-languages=c,c++,objc,fortran,java,ada,obj-c++ Thread model: posix gcc version 4.6.0 20100806 (experimental) [trunk revision 162948] (GCC) Program received signal SIGSEGV, Segmentation fault. 0x0062ab88 in dominated_by_p (dir=CDI_DOMINATORS, bb1=0x7ae08e10, bb2=0x0) at ../../gcc/gcc/dominance.c:973 973 struct et_node *n1 = bb1-dom[dir_index], *n2 = bb2-dom[dir_index]; (gdb) bt #0 0x0062ab88 in dominated_by_p (dir=CDI_DOMINATORS, bb1=0x7ae08e10, bb2=0x0) at ../../gcc/gcc/dominance.c:973 #1 0x02781b14 in dse_possible_dead_store_p (stmt=0x7ae0ac90, use_stmt=0x7eff0e98) at ../../gcc/gcc/tree-ssa-dse.c:202 #2 0x02781de4 in dse_optimize_stmt (dse_gd=0x7eff0d28, bd=0x400c2620, gsi=Cannot access memory at address 0x10 ) at ../../gcc/gcc/tree-ssa-dse.c:296 #3 0x0278219c in dse_enter_block (walk_data=0x7eff0d08, bb=0x7ae08e10) at ../../gcc/gcc/tree-ssa-dse.c:369 #4 0x031b2c8c in walk_dominator_tree (walk_data=0x7eff0d08, bb=0x7ae08e10) at ../../gcc/gcc/domwalk.c:188 #5 0x0278249c in tree_ssa_dse () at ../../gcc/gcc/tree-ssa-dse.c:429 #6 0x00c8a508 in execute_one_pass (pass=0x400c8460) at ../../gcc/gcc/passes.c:1564 #7 0x00c8a800 in execute_pass_list (pass=0x400c8460) at ../../gcc/gcc/passes.c:1619 #8 0x00c8a824 in execute_pass_list (pass=0x4001cfe8) at ../../gcc/gcc/passes.c:1620 #9 0x02500b84 in tree_rest_of_compilation (fndecl=0x7ae9b500) at ../../gcc/gcc/tree-optimize.c:452 #10 0x013f2638 in cgraph_expand_function (node=0x7ae8ded8) at ../../gcc/gcc/cgraphunit.c:1643 #11 0x013f29ac in cgraph_expand_all_functions () at ../../gcc/gcc/cgraphunit.c:1722 #12 0x013f33e4 in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1978 #13 0x013f066c in cgraph_finalize_compilation_unit () at ../../gcc/gcc/cgraphunit.c:1185 #14 0x000bd144 in c_write_global_declarations () at ../../gcc/gcc/c-decl.c:9698 #15 0x00e377e4 in compile_file () at ../../gcc/gcc/toplev.c:983 #16 0x00e3b3d0 in do_compile () at ../../gcc/gcc/toplev.c:2321 #17 0x00e3b55c in toplev_main (argc=27, argv=0x7eff06a4) at ../../gcc/gcc/toplev.c:2362 #18 0x00363164 in main (argc=27, argv=0x7eff06a4) at ../../gcc/gcc/main.c:36 -- Summary: [4.6 Regression] libjava/libltdl/ltdl.c:1272:1: internal compiler error: Segmenta Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa2.0w-hp-hpux11.11 GCC host triplet: hppa2.0w-hp-hpux11.11, hppa64-hp-hpux11.11 GCC target triplet: hppa2.0w-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45220
[Bug tree-optimization/45220] [4.6 Regression] libjava/libltdl/ltdl.c:1272:1: internal compiler error: Segmenta
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-08-07 00:32 --- Looks related to PR 45219. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||45219 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45220
