[Bug debug/42454] [4.5 Regression] debug_ranges table contains empty range for unused .text section with -ffunction-sections
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Keywords||wrong-debug Priority|P3 |P2 Summary|debug_ranges table contains |[4.5 Regression] |empty range for unused .text|debug_ranges table contains |section with -ffunction-|empty range for unused .text |sections|section with -ffunction- ||sections Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42454
[Bug debug/42395] [4.5 Regression] "error: definition in block 12 does not dominate use in block 19" with -O3 -g
--- Comment #4 from jakub at gcc dot gnu dot org 2009-12-23 08:41 --- While that change triggered it because at *.ifcvt it causes a difference: : i_41 = j_4(D); - # DEBUG i => NULL + # DEBUG i => i_9 if (i_41 <= 4095) goto ; it doesn't to appear to be the bug, i_9 definition dominates this use. The problem is that *.vect changes the IL in a way that it no longer dominates it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42395
[Bug bootstrap/42474] New: SIGSEGV in linemap_lookup
While building gcc from tag gcc_4_4_1_release on Haiku, a segfault occurred several times in various files, in the same location in linemap_lookup: mn = set->cache; The set variable is NULL. I changed linemap_lookup to return NULL when the set is NULL and this problem went away. I also experienced this SIGSEGV while using gcc 4.3.3 on Haiku. I will try investigating more recent gcc versions when I get a chance. /c/develop/gcc-4-4-1/host-i586-pc-haiku/gcc/xgcc -v Using built-in specs. Target: i586-pc-haiku Configured with: ./configure --prefix=/c/develop/gcc_4-4-1_java --enable-languages=c,c++,java --disable-nls --disable-shared --target=i586-pc-haiku Thread model: single gcc version 4.4.1 (GCC) Haiku revision 34251 expected behavior: compile without errors actual behavior: recurring SIGSEGV in linemap_lookup /c/develop/gcc-4-4-1/host-i586-pc-haiku/gcc/xgcc -shared-libgcc -B/c/develop/gcc-4-4-1/host-i586-pc-haiku/gcc -nostdinc++ -L/c/develop/gcc-4-4-1/i586-pc-haiku/libstdc++-v3/src -L/c/develop/gcc-4-4-1/i586-pc-haiku/libstdc++-v3/src/.libs -B/c/develop/gcc_4-4-1_java/i586-pc-haiku/bin/ -B/c/develop/gcc_4-4-1_java/i586-pc-haiku/lib/ -isystem /c/develop/gcc_4-4-1_java/i586-pc-haiku/include -isystem /c/develop/gcc_4-4-1_java/i586-pc-haiku/sys-include -x c++-header -O2 -g -I/c/develop/gcc-4-4-1/i586-pc-haiku/libstdc++-v3/include/i586-pc-haiku -I/c/develop/gcc-4-4-1/i586-pc-haiku/libstdc++-v3/include -I/c/develop/gcc-4-4-1/libstdc++-v3/libsupc++ -O2 -g /c/develop/gcc-4-4-1/libstdc++-v3/include/precompiled/stdtr1c++.h -o i586-pc-haiku/bits/stdtr1c++.h.gch/O2g.gch /c/develop/gcc-4-4-1/host-i586-pc-haiku/gcc/xgcc -shared-libgcc -B/c/develop/gcc-4-4-1/host-i586-pc-haiku/gcc -nostdinc++ -L/c/develop/gcc-4-4-1/i586-pc-haiku/libstdc++-v3/src -L/c/develop/gcc-4-4-1/i586-pc-haiku/libstdc++-v3/src/.libs -B/c/develop/gcc_4-4-1_java/i586-pc-haiku/bin/ -B/c/develop/gcc_4-4-1_java/i586-pc-haiku/lib/ -isystem /c/develop/gcc_4-4-1_java/i586-pc-haiku/include -isystem /c/develop/gcc_4-4-1_java/i586-pc-haiku/sys-include -x c++-header -O2 -g -I/c/develop/gcc-4-4-1/i586-pc-haiku/libstdc++-v3/include/i586-pc-haiku -I/c/develop/gcc-4-4-1/i586-pc-haiku/libstdc++-v3/include -I/c/develop/gcc-4-4-1/libstdc++-v3/libsupc++ -O2 -g /c/develop/gcc-4-4-1/libstdc++-v3/include/precompiled/extc++.h -o i586-pc-haiku/bits/extc++.h.gch/O2g.gch Thread 405300 caused an exception: Segment violation Program received signal SIGSEGV, Segmentation fault. linemap_lookup (set=0x2c9d828, line=73) at ../.././libcpp/line-map.c:276 276 mn = set->cache; linemap_lookup (set=0x2c9d828, line=73) at ../.././libcpp/line-map.c:276 276 mn = set->cache; (gdb) bt #0 linemap_lookup (set=0x2c9d828, line=73) at ../.././libcpp/line-map.c:276 #1 0x003fa1e9 in diagnostic_report_current_module (context=0xcd6520) at ../.././gcc/diagnostic.c:236 #2 0x002f64dd in cp_diagnostic_starter (context=0xcd6520, diagnostic=0x7ffec714) at ../.././gcc/cp/error.c:2374 #3 0x003f9989 in diagnostic_report_diagnostic (context=0xcd6520, diagnostic=0x7ffec714) at ../.././gcc/diagnostic.c:403 #4 0x003f9c4d in internal_error (gmsgid=0x95a5e7 "%s") at ../.././gcc/diagnostic.c:658 #5 0x0058aa1f in crash_signal (signo=Variable "signo" is not available. ) at ../.././gcc/toplev.c:601 #6 0x7ffec838 in ?? () #7 0x008c5907 in comp_hashnodes (px=0xb80cc483, py=0x39) at internal.h:672 #8 0x7ffec794 in ?? () #9 0xb80cc483 in ?? () #10 0x0039 in ?? () #11 0x00b9 in ?? () #12 0x24548d00 in ?? () #13 0xc363cd04 in ?? () #14 0x008c123b in linemap_lookup (set=0xdb9dbfdc, line=2147404600) at ../.././libcpp/line-map.c:272 #15 0x02c9d828 in ?? () -- Summary: SIGSEGV in linemap_lookup Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: andrewbachmann at yahoo dot com GCC build triplet: i586-pc-haiku GCC host triplet: i586-pc-haiku GCC target triplet: i586-pc-haiku http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42474
[Bug target/40887] GCC generates suboptimal code for indirect function calls on ARM
--- Comment #8 from ramana at gcc dot gnu dot org 2009-12-23 09:00 --- Patch submitted here. http://gcc.gnu.org/ml/gcc-patches/2009-12/msg01060.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40887
[Bug objc/42475] New: ICE at -O1 and above: internal compiler error: in simplify_subreg, at simplify-rtx.c:4954
This happens only on x86_64-unknown-linux-gnu and x86_64-pc-kfreebsd-gnu. Complete command: gcc CynthiuneHeaderCell.m -c \ -MMD -MP -I/home/y/yavor/include -DGNUSTEP -DGNUSTEP_BASE_LIBRARY=1 -DGNU_GUI_LIBRARY=1 -DGNU_RUNTIME=1 -DGNUSTEP_BASE_LIBRARY=1 -D_REENTRANT -fPIC -g -Wall -DDEBUG -fno-omit-frame-pointer -DGSWARN -DGSDIAGNOSE -Wno-import -O2 -fno-strict-aliasing -fexceptions -fobjc-exceptions -D_NATIVE_OBJC_EXCEPTIONS -fgnu-runtime -v -save-temps -fconstant-string-class=NSConstantString -IFrameworks -IFrameworks/Cynthiune/Cynthiune.framework/Headers -I. -I/home/y/yavor/GNUstep/Library/Headers -I/home/y/yavor/local/include/GNUstep -I/home/y/yavor/include/GNUstep \ -o obj/CynthiuneHeaderCell.m.o Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ./configure --enable-languages=c,c++,objc --with-mpfr=/home/y/yavor CPPFLAGS=-I/home/y/yavor/include Thread model: posix gcc version 4.4.2 (GCC) COLLECT_GCC_OPTIONS='-c' '-MMD' '-MP' '-I/home/y/yavor/include' '-DGNUSTEP' '-DGNUSTEP_BASE_LIBRARY=1' '-DGNU_GUI_LIBRARY=1' '-DGNU_RUNTIME=1' '-DGNUSTEP_BASE_LIBRARY=1' '-D_REENTRANT' '-fPIC' '-g' '-Wall' '-DDEBUG' '-fno-omit-frame-pointer' '-DGSWARN' '-DGSDIAGNOSE' '-Wno-import' '-O2' '-fno-strict-aliasing' '-fexceptions' '-fobjc-exceptions' '-D_NATIVE_OBJC_EXCEPTIONS' '-fgnu-runtime' '-v' '-save-temps' '-fconstant-string-class=NSConstantString' '-IFrameworks' '-IFrameworks/Cynthiune/Cynthiune.framework/Headers' '-I.' '-I/home/y/yavor/GNUstep/Library/Headers' '-I/home/y/yavor/local/include/GNUstep' '-I/home/y/yavor/include/GNUstep' '-o' 'obj/CynthiuneHeaderCell.m.o' '-shared-libgcc' '-mtune=generic' /srv/data/home/y/yavor/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.4.2/cc1obj -E -quiet -v -I/home/y/yavor/include -IFrameworks -IFrameworks/Cynthiune/Cynthiune.framework/Headers -I. -I/home/y/yavor/GNUstep/Library/Headers -I/home/y/yavor/local/include/GNUstep -I/home/y/yavor/include/GNUstep -iprefix /srv/data/home/y/yavor/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.4.2/ -MMD obj/CynthiuneHeaderCell.m.d -MP -MQ obj/CynthiuneHeaderCell.m.o -DGNUSTEP -DGNUSTEP_BASE_LIBRARY=1 -DGNU_GUI_LIBRARY=1 -DGNU_RUNTIME=1 -DGNUSTEP_BASE_LIBRARY=1 -D_REENTRANT -DDEBUG -DGSWARN -DGSDIAGNOSE -D_NATIVE_OBJC_EXCEPTIONS CynthiuneHeaderCell.m -mtune=generic -Wall -Wno-import -fPIC -fno-omit-frame-pointer -fno-strict-aliasing -fexceptions -fobjc-exceptions -fgnu-runtime -fconstant-string-class=NSConstantString -g -fworking-directory -O2 -fpch-preprocess -o CynthiuneHeaderCell.mi ignoring nonexistent directory "/srv/data/home/y/yavor/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.4.2/../../../../x86_64-unknown-linux-gnu/include" ignoring duplicate directory "/srv/data/home/y/yavor/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.4.2/include" ignoring duplicate directory "/srv/data/home/y/yavor/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.4.2/include-fixed" ignoring nonexistent directory "/srv/data/home/y/yavor/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.4.2/../../../../x86_64-unknown-linux-gnu/include" ignoring nonexistent directory "/home/y/yavor/GNUstep/Library/Headers" #include "..." search starts here: #include <...> search starts here: /home/y/yavor/include Frameworks Frameworks/Cynthiune/Cynthiune.framework/Headers . /home/y/yavor/local/include/GNUstep /home/y/yavor/include/GNUstep /srv/data/home/y/yavor/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.4.2/include /srv/data/home/y/yavor/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.4.2/include-fixed /usr/local/include /usr/include End of search list. COLLECT_GCC_OPTIONS='-c' '-MMD' '-MP' '-I/home/y/yavor/include' '-DGNUSTEP' '-DGNUSTEP_BASE_LIBRARY=1' '-DGNU_GUI_LIBRARY=1' '-DGNU_RUNTIME=1' '-DGNUSTEP_BASE_LIBRARY=1' '-D_REENTRANT' '-fPIC' '-g' '-Wall' '-DDEBUG' '-fno-omit-frame-pointer' '-DGSWARN' '-DGSDIAGNOSE' '-Wno-import' '-O2' '-fno-strict-aliasing' '-fexceptions' '-fobjc-exceptions' '-D_NATIVE_OBJC_EXCEPTIONS' '-fgnu-runtime' '-v' '-save-temps' '-fconstant-string-class=NSConstantString' '-IFrameworks' '-IFrameworks/Cynthiune/Cynthiune.framework/Headers' '-I.' '-I/home/y/yavor/GNUstep/Library/Headers' '-I/home/y/yavor/local/include/GNUstep' '-I/home/y/yavor/include/GNUstep' '-o' 'obj/CynthiuneHeaderCell.m.o' '-shared-libgcc' '-mtune=generic' /srv/data/home/y/yavor/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.4.2/cc1obj -fpreprocessed CynthiuneHeaderCell.mi -quiet -dumpbase CynthiuneHeaderCell.m -mtune=generic -auxbase-strip obj/CynthiuneHeaderCell.m.o -g -O2 -Wall -Wno-import -version -fPIC -fno-omit-frame-pointer -fno-strict-aliasing -fexceptions -fobjc-exceptions -fgnu-runtime -fconstant-string-class=NSConstantString -o CynthiuneHeaderCell.s GNU Objective-C (GCC) version 4.4.2 (x86_64-unknown-linux-gnu) compiled by GNU C version 4.4.2, GMP version 4.1.4, MPFR version 2.4.1. warning: GMP header version 4.1.4 differs from library version 4.2.2. GGC heuristics: --param ggc-min-expand=100 --param gg
[Bug objc/42475] ICE at -O1 and above: internal compiler error: in simplify_subreg, at simplify-rtx.c:4954
--- Comment #1 from yavor at gnu dot org 2009-12-23 09:06 --- Created an attachment (id=19379) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19379&action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42475
[Bug objc/42475] ICE at -O1 and above: internal compiler error: in simplify_subreg, at simplify-rtx.c:4954
--- Comment #2 from jakub at gcc dot gnu dot org 2009-12-23 09:39 --- Combiner bug, testing a fix. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-12-23 09:39:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42475
[Bug target/42448] [4.3/4.4/4.5 Regression] Wrong code with _Complex char in structure
--- Comment #3 from ubizjak at gmail dot com 2009-12-23 09:57 --- Patch at http://gcc.gnu.org/ml/gcc-patches/2009-12/msg01067.html -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2009- ||12/msg01067.html Status|NEW |ASSIGNED Last reconfirmed|2009-12-21 13:19:36 |2009-12-23 09:57:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42448
[Bug c++/42470] Conversion Constructor not accepted/recognized
--- Comment #1 from redi at gcc dot gnu dot org 2009-12-23 10:30 --- The code should not compile, Visual Studio is wrong. Base b = 5; is a copy initialization, equivalent to Base b = Base(5); which requires a copy constructor, but your copy constructor takes a non-const Base& and so cannot bind to the temporary. This is covered by 8.5 [dcl.init] paragraph 14 in the standard. -- redi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED GCC build triplet|What is this? | GCC host triplet|Not sure what this means; | |here is the result of uname | |-a: Linux | GCC target triplet|What is this? | Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42470
[Bug c++/42471] No return value from operator =() is accepted by the compiler
--- Comment #1 from redi at gcc dot gnu dot org 2009-12-23 10:41 --- 4.1.0 is no longer supported, but in any case I get a warning for this, just use -Wreturn-type or -Wall -- redi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED GCC build triplet|What is this? | GCC host triplet|Linux lambrusco 2.6.16.13-4-| |smp #1 SMP Wed May 3| |04:53:23 UTC 20 | GCC target triplet|What is this? | Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42471
[Bug c++/38392] Template friend function injection
--- Comment #8 from redi at gcc dot gnu dot org 2009-12-23 11:02 --- See http://www.open-std.org/jtc1/sc22/wg21/prot/14882fdis/cwg_defects.html#329 I believe a "use" of the function must come after the definition for it to be instantiated, indeed if I add this after the explicit instantiation it links OK: void(*pf)() = &Function; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38392
[Bug c++/42472] class members not getting assigned access thru another method
--- Comment #1 from redi at gcc dot gnu dot org 2009-12-23 11:09 ---
C++ is not java, you cannot delegate to another constructor like this:
primes::primes(ulong p):maxp(p) { primes(); }
That creates a temporary object of type primes, it does not call the
constructor.
Therefore primes::i and primes::p are not initialised by the primes(long)
constructor.
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
Version|unknown |4.3.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42472
[Bug rtl-optimization/42429] [4.4 Regression] Miscompilation of 2fish on s390
--- Comment #9 from jakub at gcc dot gnu dot org 2009-12-23 11:14 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42429
[Bug c/42476] New: "warning: will never be executed" about code which is executed with "-Wunreachable-code"
Compiling the following code snippet:
int main(int argc, char **argv)
{
int i;
int asize = 3;
int array[3];
for (i = asize - 1; i < asize; i++)
array[i] = 42;
for (i = 0; i < asize; i++)
printf("%i\n", array[i]);
}
with "gcc -O -Wunreachable-code gccbug.c" shows the following warning message:
gccbug.c: In function 'main':
gccbug.c:8: warning: will never be executed
(Where line 8 is the body of the first for-loop, array[i] = 42;)
Though, array[2] is set to 42, as the later printf shows when executing.
When replacing the "- 1" of line 7 with an higher value, e.g. "- 2", the
warning disappears. Not passing "-O" to the compiler lets the warning
disappear, too.
I tested it with two versions of gcc. The first:
Using built-in specs.
Target: x86_64-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-4.3.4/work/gcc-4.3.4/configure
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.4
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.4
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.4/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.4/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/include/g++-v4
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec
--disable-fixed-point --enable-nls --without-included-gettext
--with-system-zlib --disable-checking --disable-werror --enable-secureplt
--enable-multilib --enable-libmudflap --disable-libssp --enable-libgomp
--disable-libgcj --enable-languages=c,c++,treelang,fortran --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.3.4 p1.0,
pie-10.1.5'
Thread model: posix
gcc version 4.3.4 (Gentoo 4.3.4 p1.0, pie-10.1.5)
The second:
Using built-in specs.
Target: arm-elf
Configured with: /tmp/gcc.ndS8/gcc-4.4.1/configure --enable-languages=c
--with-mpfr=/usr --without-headers --target=arm-elf --prefix=/usr/local/arm-elf
--with-local-prefix=/usr/local/arm-elf --disable-werror --disable-multilib
--disable-shared --disable-nls --disable-libssp --with-arch=armv4t
--with-cpu=arm7tdmi-s
Thread model: single
gcc version 4.4.1 (GCC)
The warning appears with both gcc versions.
--
Summary: "warning: will never be executed" about code which is
executed with "-Wunreachable-code"
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: agraf at znc dot in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42476
[Bug translation/42467] exgettext should not remove TABs from option help strings
--- Comment #3 from jsm28 at gcc dot gnu dot org 2009-12-23 11:58 --- The option help string is passed for translation as a whole before the special interpretation for TAB as described in options.texi: The help text is automatically line-wrapped before being displayed. Normally the name of the option is printed on the left-hand side of the output and the help text is printed on the right. However, if the help text contains a tab character, the text to the left of the tab is used instead of the option's name and the text to the right of the tab forms the help text. This allows you to elaborate on what type of argument the option takes. Thus, exgettext is wrong to remove the text before the tab (which generally does need translation of things such as ). -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||40883 nThis|| Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-12-23 11:58:25 date|| Summary|Localization fails with - |exgettext should not remove |gnat line in gcc --|TABs from option help |help=Ada|strings http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42467
[Bug translation/42467] exgettext should not remove TABs from option help strings
--- Comment #4 from jsm28 at gcc dot gnu dot org 2009-12-23 12:00 --- *** Bug 42468 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42467
[Bug translation/42468] Localization fails with --CLASSPATH line in gcc --help=Java
--- Comment #1 from jsm28 at gcc dot gnu dot org 2009-12-23 12:00 --- This is the same exgettext bug as bug 42467. *** This bug has been marked as a duplicate of 42467 *** -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42468
[Bug translation/42469] option help strings not properly using TAB
--- Comment #1 from jsm28 at gcc dot gnu dot org 2009-12-23 12:08 --- Part of this appears to be the same exgettext issue as bug 42467. The rest appears to be option help strings using one or more spaces where a single TAB should be used: common.opt:-Wframe-larger-than= Warn if a function's stack frame requires more than bytes common.opt:-fcompare-debug[=] Compile with and without e.g. -gtoggle, and compare the final-insns dump common.opt:-fdbg-cnt=:[,:,...]Set the debug counter limit. common.opt:-fira-verbose= Control IRA's level of diagnostic messages. common.opt:-flto-compression-level= Use zlib compression level for IL common.opt:-fplugin-arg--[=] Specify argument = for plugin c.opt:-imultilib Set to be the multilib include subdirectory fortran/lang.opt:-fblas-matmul-limit=Size of the smallest matrix for which matmul will use BLAS fortran/lang.opt:-finit-character= Initialize local character variables to ASCII value n fortran/lang.opt:-finit-integer= Initialize local integer variables to n fortran/lang.opt:-finit-logical= Initialize local logical variables fortran/lang.opt:-finit-real= Initialize local real variables fortran/lang.opt:-fmax-array-constructor=Maximum number of objects in an array constructor -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||40883 nThis|| Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-12-23 12:08:18 date|| Summary|19 localization fails with |option help strings not |gcc ---help=fortran |properly using TAB http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42469
[Bug fortran/42477] New: Runtime segfault with -fopenmp -static
Consider this simple program: use omp_lib print *, 'Number of processors:', omp_get_num_procs() end After compiling this with "-fopenmp -static -fbacktrace", executing it gives the output: Number of processors: 2 Program received signal 11 (SIGSEGV): Segmentation fault. Backtrace for this error: + function __restore_rt (0x41EAB0) from file sigaction.c The segfault is gone when compiling without the -static flag. Also this seems to be a Fortran-only problem. An equivalent C program does not run into the segfault. -- Summary: Runtime segfault with -fopenmp -static Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: janus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42477
[Bug fortran/42478] New: [meta-bug] gfortran OpenMP bugs
-- Summary: [meta-bug] gfortran OpenMP bugs Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: janus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42478
[Bug fortran/42477] Runtime segfault with -fopenmp -static
--- Comment #1 from janus at gcc dot gnu dot org 2009-12-23 13:29 --- Btw, one also gets the segfault without actually calling 'omp_get_num_procs': subroutine s !$ use omp_lib !$ print *, 'Number of processors:', omp_get_num_procs() end subroutine end This program can be compiled and run also without -fopenmp, and does absolutely nothing (besides producing a segfault with -fopenmp -static). -- janus at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.4.1 4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42477
[Bug fortran/42477] Runtime segfault with -fopenmp -static
--- Comment #2 from dfranke at gcc dot gnu dot org 2009-12-23 13:32 --- Dupe of PR30471? -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42477
[Bug fortran/42477] Runtime segfault with -fopenmp -static
--- Comment #3 from janus at gcc dot gnu dot org 2009-12-23 13:41 --- (In reply to comment #2) > Dupe of PR30471? Ah, yes, indeed. The segfault is cured by the workaround from comment #7 of that PR (i.e. compiling with -fopenmp -static -Wl,--whole-archive -lpthread -Wl,--no-whole-archive). *** This bug has been marked as a duplicate of 30471 *** -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42477
[Bug libgomp/30471] OpenMP with static linking fails in fortran on amd64
--- Comment #10 from janus at gcc dot gnu dot org 2009-12-23 13:41 --- *** Bug 42477 has been marked as a duplicate of this bug. *** -- janus at gcc dot gnu dot org changed: What|Removed |Added CC||janus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30471
[Bug fortran/42478] [meta-bug] gfortran OpenMP bugs
--- Comment #1 from dfranke at gcc dot gnu dot org 2009-12-23 13:49 --- Shouldn't the "openmp" keyword (http://gcc.gnu.org/bugzilla/describekeywords.cgi) be sufficient? -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42478
[Bug middle-end/42479] New: Wrong-code for induct.f90 with " -O3 -floop-block"
At revision 155425 the executable for induct.f90 compiled with " -O3 -floop-block" gives: ... Maximum wand/quad abs rel mutual inductance = 1.84138324899744549E-002 ... instead of ... Maximum wand/quad abs rel mutual inductance = 5.95379428444659381E-002 ... when compiled with "-O2 -floop-block". Note that the wrong code runs in ~8.5s, while the fastest right code runs in ~14s. -- Summary: Wrong-code for induct.f90 with " -O3 -floop-block" Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC build triplet: x86_64-apple-darwin10 GCC host triplet: x86_64-apple-darwin10 GCC target triplet: x86_64-apple-darwin10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42479
[Bug middle-end/42480] New: Wrong-code for air.f90 with "-O2 -fgraphite-identity"
At revision 155425 the executable for air.f90 compiled with "-O2 -fgraphite-identity" gives: ... ITERATION# TIME FINAL MASS RESIDUAL 14 100.43187820 0.0100 NaN deltat, final t, iterations 100.00100.4318782042 14 14 NaN The executable obtained with "-O1 -fgraphite-identity" is correct. -- Summary: Wrong-code for air.f90 with "-O2 -fgraphite-identity" Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC build triplet: x86_64-apple-darwin10 GCC host triplet: x86_64-apple-darwin10 GCC target triplet: x86_64-apple-darwin10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42480
[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64
--- Comment #39 from dominiq at lps dot ens dot fr 2009-12-23 14:09 --- With the patch in comment #37, the tests pass, but are not vectorized. I did a mistake after applying the patch in comment #38 and I am doing a "quick" bootstrap (~5h). I have regtested the patch in comment #31 and I have ~75 regressions on x86_64-apple-darwin10 in the gcc vect test suite (~100 on powerpc-apple-darwin9). Is this expected? and do you want the list? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082
[Bug java/42307] WalkerTest execution failures
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2009-12-23 14:09 --- Proposed patch at http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00998.html. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42307
[Bug target/42208] gcc trunk incorrectly linking against /usr/lib/libgcc_s.1.dylib
--- Comment #7 from howarth at nitro dot med dot uc dot edu 2009-12-23 14:10 --- Current behavior is correct. -- howarth at nitro dot med dot uc dot edu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42208
[Bug middle-end/42476] "warning: will never be executed" about code which is executed with "-Wunreachable-code"
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-12-23 14:37 --- Note -Wunreachable-code has since ben removed from the trunk ... -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42476
[Bug fortran/42478] [meta-bug] gfortran OpenMP bugs
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-12-23 14:43 --- (In reply to comment #1) > Shouldn't the "openmp" keyword > (http://gcc.gnu.org/bugzilla/describekeywords.cgi) be sufficient? Yes it should ... -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42478
[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64
--- Comment #40 from irar at il dot ibm dot com 2009-12-23 14:49 --- (In reply to comment #39) > I have regtested the patch in comment #31 and I have ~75 regressions on > x86_64-apple-darwin10 in the gcc vect test suite (~100 on > powerpc-apple-darwin9). Is this expected? and do you want the list? Yes, it is expected, it is not a bug fixing patch (as well as the rest of the hacks I asked you to check), it disables a feature - alignment forcing, so some tests are supposed to fail. Thanks, Ira -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082
[Bug objc/35165] Massive failures of objc on i686-apple-darwin9
--- Comment #6 from developer at sandoe-acoustics dot co dot uk 2009-12-23 15:04 --- http://gcc.gnu.org/ml/gcc-patches/2009-12/msg01081.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35165
[Bug libmudflap/42279] libmudflap checks with the wrong CPP for execinfo.h
--- Comment #5 from ramana at gcc dot gnu dot org 2009-12-23 15:12 --- (In reply to comment #4) > Created an attachment (id=19267) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19267&action=view) [edit] > Fix for libmudflap + libstdc++v3 for gcc 4.4.2 > > In gcc 4.4.2, libstdc++v3 is also affected by the CPP probelm. > > I attach the fix for gcc 4.4.2 that fixes both libstdc++v3 and libmudflap > builds, and I imagine, any target library build. > Please again send this to the mailing list rather than attaching the fix here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42279
[Bug debug/31004] arm ABI bug in transfer structure on the 4th parameter
--- Comment #2 from rearnsha at gcc dot gnu dot org 2009-12-23 15:20
---
Fixed by Paul's patch:
http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00378.html
Prior to this patch, when debugging the testcase I see:
(gdb)
subfunc (a=492, b=2097148, c=0, d=...) at test.c:9
9 printf("a %x b %x c %x d.y %x d.z %x\n",a,b,c,d.y,d.z);
With the patch, I see:
subfunc (a=0, b=1, c=2, d=...) at test.c:9
9 printf("a %x b %x c %x d.y %x d.z %x\n",a,b,c,d.y,d.z);
(gdb) p d
$1 = {y = 3, z = 4}
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution||FIXED
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31004
[Bug fortran/42481] New: generic interface not recognized
! In this program, gfortran fails to identify the generic interface sub for ! sub_int. The compiler gives this error message: ! ! > gfortran prog.f90 ! prog.f90:40.9: ! ! call sub(1) ! 1 ! Error: Type mismatch in argument 'x' at (1); passed INTEGER(4) to REAL(4) ! ! However, if the use statements in program prog are switched so that ! use mod2 comes before use mod1, it correctly identifies the generic ! interface and compiles. ! ! This is with the following version of gfortran: ! > gfortran --version ! GNU Fortran (GCC) 4.5.0 20091205 (experimental) [trunk revision 155016] module mod1 contains subroutine sub(x) real x end subroutine sub end module mod1 module mod2 use mod1 interface sub module procedure sub, sub_int end interface sub contains subroutine sub_int(i) integer i end subroutine sub_int end module mod2 program prog use mod1 use mod2 call sub(1) end program prog -- Summary: generic interface not recognized Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: william dot mitchell at nist dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42481
[Bug target/42404] Incorrect CFI generated
--- Comment #2 from ramana at gcc dot gnu dot org 2009-12-23 15:25 --- Can't see anything in the backend that does CFI in prologue and epilogue for the ARM port. Reclassifying as a target bug rather than a debug bug. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|debug |target Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-12-23 15:25:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42404
[Bug middle-end/42482] New: [4.5 Regression] Many graphite test failures
On Linux/Intel64, revision 155424 gave: FAIL: g++.dg/graphite/pr41305.C (test for excess errors) FAIL: g++.dg/graphite/pr41305.C (test for excess errors) FAIL: g++.dg/graphite/pr42130.C execution test FAIL: gcc.dg/graphite/pr40281.c (test for excess errors) FAIL: gfortran.dg/graphite/pr42393.f90 -O (internal compiler error) FAIL: gfortran.dg/graphite/pr42393.f90 -O (internal compiler error) FAIL: gfortran.dg/graphite/pr42393.f90 -O (test for excess errors) FAIL: gfortran.dg/graphite/pr42393.f90 -O (test for excess errors) Revision 155415 is OK. -- Summary: [4.5 Regression] Many graphite test failures Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42482
[Bug libmudflap/42279] libmudflap checks with the wrong CPP for execinfo.h
--- Comment #6 from viriketo at gmail dot com 2009-12-23 15:34 --- Done. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42279
[Bug target/40670] Load floating point constant 0 directly
--- Comment #4 from ramana at gcc dot gnu dot org 2009-12-23 16:29 --- Subject: Bug 40670 Author: ramana Date: Wed Dec 23 16:29:12 2009 New Revision: 155427 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155427 Log: Pass floating point constant moves to integer registers as mov immediates for Thumb1. 2009-12-23 Ramana Radhakrishnan PR target/40670 * config/arm/arm.md: Split for Thumb1 as well. * gcc.target/arm/pr40670.c: New test. Added: trunk/gcc/testsuite/gcc.target/arm/pr40670.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.md trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40670
[Bug bootstrap/42093] [4.5 regression] bootstrap hangs in stage2 run of build/gengtype
--- Comment #6 from ramana at gcc dot gnu dot org 2009-12-23 16:36 --- Subject: Bug 42093 Author: ramana Date: Wed Dec 23 16:36:40 2009 New Revision: 155428 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155428 Log: Fix PR target/42093 2009-12-23 Ramana Radhakrishnan PR target/42093 * config/arm/arm.h (CASE_VECTOR_PC_RELATIVE): Fix macro usage to TARGET_THUMB1. (CASE_VECTOR_SHORTEN_MODE): Allow signed offsets only for TARGET_THUMB1. 2009-12-23 Ramana Radhakrishnan PR target/42093 * gcc.target/arm/pr42093.c: New test. Added: trunk/gcc/testsuite/gcc.target/arm/pr42093.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.h trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42093
[Bug target/40670] Load floating point constant 0 directly
--- Comment #5 from ramana at gcc dot gnu dot org 2009-12-23 16:37 --- Fixed. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40670
[Bug debug/42454] [4.5 Regression] debug_ranges table contains empty range for unused .text section with -ffunction-sections
--- Comment #5 from jakub at gcc dot gnu dot org 2009-12-23 16:54 --- Subject: Bug 42454 Author: jakub Date: Wed Dec 23 16:54:35 2009 New Revision: 155429 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155429 Log: PR debug/42454 * dwarf2out.c (add_ranges_by_labels_to_AT_range_list): New function. (dwarf2out_finish): Call add_ranges_by_labels_to_AT_range_list. * gcc.dg/debug/dwarf2/aranges-fnsec-1.c: Add check for .debug_ranges. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/debug/dwarf2/aranges-fnsec-1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42454
[Bug rtl-optimization/42475] ICE at -O1 and above: internal compiler error: in simplify_subreg, at simplify-rtx.c:4954
--- Comment #3 from jakub at gcc dot gnu dot org 2009-12-23 17:04 --- Subject: Bug 42475 Author: jakub Date: Wed Dec 23 17:04:07 2009 New Revision: 155430 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155430 Log: PR rtl-optimization/42475 * combine.c (make_compound_operation) : Use mode of SUBREG_REG (x) instead of tem's mode. * gcc.dg/pr42475.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr42475.c Modified: trunk/gcc/ChangeLog trunk/gcc/combine.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42475
[Bug rtl-optimization/42475] ICE at -O1 and above: internal compiler error: in simplify_subreg, at simplify-rtx.c:4954
--- Comment #4 from jakub at gcc dot gnu dot org 2009-12-23 17:07 --- Subject: Bug 42475 Author: jakub Date: Wed Dec 23 17:07:04 2009 New Revision: 155431 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155431 Log: PR rtl-optimization/42475 * combine.c (make_compound_operation) : Use mode of SUBREG_REG (x) instead of tem's mode. * gcc.dg/pr42475.c: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr42475.c Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/combine.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42475
[Bug debug/42454] [4.5 Regression] debug_ranges table contains empty range for unused .text section with -ffunction-sections
--- Comment #6 from jakub at gcc dot gnu dot org 2009-12-23 17:09 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42454
[Bug rtl-optimization/42475] ICE at -O1 and above: internal compiler error: in simplify_subreg, at simplify-rtx.c:4954
--- Comment #5 from jakub at gcc dot gnu dot org 2009-12-23 17:09 --- Fixed in 4.4/4.5. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42475
[Bug tree-optimization/42462] wrong-code with computed-goto
--- Comment #2 from wouter dot vermaelen at scarlet dot be 2009-12-23 17:21 --- Seems this problem got introduced in revision 152492 (152491 still works, 152492 shows the problem). 2009-10-06 Martin Jambor PR bootstrap/41395 * opts.c (decode_options): Run IPA-SRA at -O2. (Though this patch is probably not the root cause). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42462
[Bug middle-end/42130] [graphite-branch] dealII fails
--- Comment #9 from spop at gcc dot gnu dot org 2009-12-23 17:37 --- The testcase still fails with -fgraphite-identity. -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42130
[Bug c/42483] New: AVR fails all whopr/lto tests
When LTO is enabled AVR fails all whopr/lto tests: Testsuite fails all lto/whopr tests: Example: Executing on host: /media/verbatim/gcchead/obj-dir/gcc/xgcc -B/media/verbatim/gcchead/obj-dir/gcc/ /media/verbatim/gcchead/trunk/gcc/testsuite/gcc.c-torture/execute/builtins/abs-1.c /media/verbatim/gcchead/trunk/gcc/testsuite/gcc.c-torture/execute/builtins/abs-1-lib.c /media/verbatim/gcchead/trunk/gcc/testsuite/gcc.c-torture/execute/builtins/lib/main.c -w -O2 -flto -fno-builtin-abs -DSTACK_SIZE=2048 -DNO_TRAMPOLINES -DSIGNAL_SUPPRESS -mmcu=atmega128 /home/andy/winavrfiles/avrtest/dejagnuboards/exit.c -Wl,-u,vfprintf -lprintf_flt -Wl,-Tbss=0x802000,--defsym=__heap_end=0x80 -lm -o /media/verbatim/gcchead/obj-dir/gcc/testsuite/gcc/abs-1.x6(timeout = 300) spawn /media/verbatim/gcchead/obj-dir/gcc/xgcc -B/media/verbatim/gcchead/obj-dir/gcc/ /media/verbatim/gcchead/trunk/gcc/testsuite/gcc.c-torture/execute/builtins/abs-1.c /media/verbatim/gcchead/trunk/gcc/testsuite/gcc.c-torture/execute/builtins/abs-1-lib.c /media/verbatim/gcchead/trunk/gcc/testsuite/gcc.c-torture/execute/builtins/lib/main.c -w -O2 -flto -fno-builtin-abs -DSTACK_SIZE=2048 -DNO_TRAMPOLINES -DSIGNAL_SUPPRESS -mmcu=atmega128 /home/andy/winavrfiles/avrtest/dejagnuboards/exit.c -Wl,-u,vfprintf -lprintf_flt -Wl,-Tbss=0x802000,--defsym=__heap_end=0x80 -lm -o /media/verbatim/gcchead/obj-dir/gcc/testsuite/gcc/abs-1.x6 /home/andy/local/avr/lib/gcc/avr/4.5.0/../../../../avr/bin/ld: -f may not be used without -shared compiler exited with status 1 output is: /home/andy/local/avr/lib/gcc/avr/4.5.0/../../../../avr/bin/ld: -f may not be used without -shared FAIL: gcc.c-torture/execute/builtins/abs-1.c compilation, -O2 -flto Note LTO was built using patch from http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42457 -- Summary: AVR fails all whopr/lto tests Product: gcc Version: lto Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hutchinsonandy at gcc dot gnu dot org GCC host triplet: i686-pc-linux-gnu GCC target triplet: avr-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42483
[Bug tree-optimization/41305] ICE with -O3 -floop-interchange
--- Comment #3 from spop at gcc dot gnu dot org 2009-12-23 18:11 --- The testcase fails without graphite at -O0, probably a problem in the C++ front-end: stopping the execution randomly, I get the following backtraces: #0 0x00660ccc in structural_comptypes (t1=0x7f097e143690, t2=0x7f097df37e70, strict=0) at ../../gcc/cp/typeck.c:1170 #1 0x006631a7 in comptypes (t1=0x7f097e143690, t2=0x7f097df37e70, strict=0) at ../../gcc/cp/typeck.c:1298 #2 0x0054e11f in template_args_equal (ot=0x7f097e143690, nt=0x7f097df37e70) at ../../gcc/cp/pt.c:5924 #3 0x0054e38b in comp_template_args (oldargs=0x7f097e147fc8, newargs=0x7f097df40398) at ../../gcc/cp/pt.c:5947 #4 0x0066190c in structural_comptypes (t1=0x7f097e14a000, t2=0x7f097df3f7e0, strict=0) at ../../gcc/cp/typeck.c:1169 #5 0x006631a7 in comptypes (t1=0x7f097e14a000, t2=0x7f097df3f7e0, strict=0) at ../../gcc/cp/typeck.c:1298 #6 0x0054e11f in template_args_equal (ot=0x7f097e14a000, nt=0x7f097df3f7e0) at ../../gcc/cp/pt.c:5924 #7 0x0054e38b in comp_template_args (oldargs=0x7f097e14cfa0, newargs=0x7f097df47370) at ../../gcc/cp/pt.c:5947 #8 0x0066190c in structural_comptypes (t1=0x7f097e152930, t2=0x7f097df49150, strict=0) at ../../gcc/cp/typeck.c:1169 #0 0x0054d873 in template_args_equal (ot=Cannot access memory at address 0x7fffab5c5fb8) at ../../gcc/cp/pt.c:5881 #1 0x0054e38b in comp_template_args (oldargs=0x7f097ea9e5f0, newargs=0x7f097e8b9528) at ../../gcc/cp/pt.c:5947 #2 0x0066190c in structural_comptypes (t1=0x7f097ea9fbd0, t2=0x7f097e8baa80, strict=0) at ../../gcc/cp/typeck.c:1169 #3 0x006631a7 in comptypes (t1=0x7f097ea9fbd0, t2=0x7f097e8baa80, strict=0) at ../../gcc/cp/typeck.c:1298 #4 0x0054e11f in template_args_equal (ot=0x7f097ea9fbd0, nt=0x7f097e8baa80) at ../../gcc/cp/pt.c:5924 #5 0x0054e38b in comp_template_args (oldargs=0x7f097e8a05c8, newargs=0x7f097e8c1500) at ../../gcc/cp/pt.c:5947 #6 0x0066190c in structural_comptypes (t1=0x7f097e8a1540, t2=0x7f097e8c33f0, strict=0) at ../../gcc/cp/typeck.c:1169 #7 0x006631a7 in comptypes (t1=0x7f097e8a1540, t2=0x7f097e8c33f0, strict=0) at ../../gcc/cp/typeck.c:1298 #8 0x0054e11f in template_args_equal (ot=0x7f097e8a1540, nt=0x7f097e8c33f0) at ../../gcc/cp/pt.c:5924 This stops after one or two minutes, depending on stack ulimit. With an older compiler, I get this time: time g++-4.3 -O3 -c ~/gcc/graphite/gcc/testsuite/g++.dg/graphite/pr41305.C real0m0.103s user0m0.072s sys 0m0.012s -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41305
[Bug c++/41305] Infinite recursion with g++ at -O0
--- Comment #4 from spop at gcc dot gnu dot org 2009-12-23 18:15 --- This used to work on 2009-10-15 on the graphite branch. -- spop at gcc dot gnu dot org changed: What|Removed |Added Component|tree-optimization |c++ Keywords|ice-on-valid-code | Priority|P3 |P1 Summary|ICE with -O3 -floop-|Infinite recursion with g++ |interchange |at -O0 Version|4.4.2 |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41305
[Bug middle-end/42393] [4.5 Regression] [graphite] internal compiler error: in check_loop_closed_ssa_use
--- Comment #6 from spop at gcc dot gnu dot org 2009-12-23 18:27 --- Seems like this is fixed by the patch from PR42221. -- spop at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||42221 Status|RESOLVED|UNCONFIRMED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42393
read() wont allow me to read files larger than 2 gig (on a 64bit)
Hi Sorry if I'm asking on the wrong mailinglist, but I've asked on various forums and I havn't found a solution. I can't read files larger than 2 gig on my ubuntu64bit using 'read()', the problem is not related to the allocation itself, which works. Attached is a sample program that illustrates this. I've tried with various, compiler flags like -D_FILE_OFFSET_BITS=64 According to man 2 read, the maximum is limited by SSIZE_MAX which is defined in /usr/include/bits/posix1_lim.h # define SSIZE_MAX LONG_MAX And LONG_MAX is defined in /usr/include/limits.h as # if __WORDSIZE == 64 # define LONG_MAX 9223372036854775807L # else # define LONG_MAX 2147483647L # endif # define LONG_MIN (-LONG_MAX - 1L) Either this is a bug in the ubuntu buildsystem, or my build system is broken. Can anyone with a 64 try to run the above program. Thanks edit: by the way readelf -h ./a.out ELF Header: Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 Class: ELF64 Data: 2's complement, little endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: EXEC (Executable file) Machine: Advanced Micro Devices X86-64 Version: 0x1 Entry point address: 0x400750 Start of program headers: 64 (bytes into file) Start of section headers: 5312 (bytes into file) Flags: 0x0 Size of this header: 64 (bytes) Size of program headers: 56 (bytes) Number of program headers: 9 Size of section headers: 64 (bytes) Number of section headers: 37 Section header string table index: 34 ldd ./a.out linux-vdso.so.1 => (0x7fff689ff000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x7ffee433e000) libm.so.6 => /lib/libm.so.6 (0x7ffee40ba000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x7ffee3ea3000) libc.so.6 => /lib/libc.so.6 (0x7ffee3b34000) /lib64/ld-linux-x86-64.so.2 (0x7ffee464e000) uname -a Linux csi 2.6.31-15-generic #50-Ubuntu SMP Tue Nov 10 14:53:52 UTC 2009 x86_64 GNU/Linux read.cpp Description: Binary data
[Bug target/40956] GCSE opportunity in if statement
--- Comment #3 from davidxl at gcc dot gnu dot org 2009-12-23 19:37 ---
This bug is ARM specific (thumb) mode. In x86, the hoisting is unnecessary as
the move instruction support the imm form.
The issue here is more in the GIMPLE canonicalization (target specific). In
this case, the IR should be in the following form to expose the hoisting.
if (...) {
temp = 0;
*p = temp;
}
else
{
temp = 0;
*(p+1) = temp;
}
--
davidxl at gcc dot gnu dot org changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|DUPLICATE |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40956
[Bug c++/41305] Infinite recursion with g++ at -O0
--- Comment #5 from hjl dot tools at gmail dot com 2009-12-23 20:12 --- It is caused by revision 153958: http://gcc.gnu.org/ml/gcc-cvs/2009-11/msg00176.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||jason at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41305
[Bug c++/41305] Infinite recursion with g++ at -O0
-- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-12-23 20:12:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41305
[Bug driver/41564] -fdump-tree-all for lto does not work as expected
--- Comment #8 from hjl dot tools at gmail dot com 2009-12-23 21:01 --- Since LTO tree dump is quite different, can't we give it a different command line option, something like -fdump-tree-lto-all, instead of enabling it with -fdump-tree-all? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41564
[Bug c++/33041] g++ incorrectly resolves an identically named templated struct in a super class
--- Comment #4 from redi at gcc dot gnu dot org 2009-12-23 21:17 --- A recent 4.5.0 doesn't accept this: pr33041.cc: In function int main(): pr33041.cc:20:26: error: no match for operator<< in std::cout << foo::foo compilation terminated due to -Wfatal-errors. Adding some parentheses gives: pr33041.cc: In function int main(): pr33041.cc:20:31: error: expected primary-expression before double pr33041.cc:20:31: error: expected ) before double This might have been changed by the fixes for bug 9050 or bug 11764 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33041
[Bug c++/32081] Conflicting exception specifications not rejected in template specialization
-- redi at gcc dot gnu dot org changed: What|Removed |Added CC||redi at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.4.2 Last reconfirmed|-00-00 00:00:00 |2009-12-23 21:20:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32081
[Bug middle-end/42484] New: ICE with -fopenmp
Consider the following Fortran snippet: subroutine sub integer :: nRead !$omp critical if (nRead<3) return !$omp end critical end subroutine Compiling this with "gfortran -fopenmp" results in a segfault (with 4.4.1 and current trunk on x86_64-unknown-linux-gnu). The backtrace is: #0 0x00a0abcc in main_block_label (label=0x77f64180) at /home/jweil/gcc45/trunk/gcc/tree-cfg.c:1064 #1 0x00a0b157 in cleanup_dead_labels () at /home/jweil/gcc45/trunk/gcc/tree-cfg.c:1192 #2 0x00a08f27 in build_gimple_cfg (seq=0x77f54600) at /home/jweil/gcc45/trunk/gcc/tree-cfg.c:201 #3 0x00a08fd1 in execute_build_cfg () at /home/jweil/gcc45/trunk/gcc/tree-cfg.c:238 #4 0x00907d9b in execute_one_pass (pass=0x16c4dc0) at /home/jweil/gcc45/trunk/gcc/passes.c:1556 #5 0x00907f8f in execute_pass_list (pass=0x16c4dc0) at /home/jweil/gcc45/trunk/gcc/passes.c:1611 #6 0x00a7fe21 in tree_lowering_passes (fn=0x77f63f00) at /home/jweil/gcc45/trunk/gcc/tree-optimize.c:364 #7 0x00cc9f23 in cgraph_lower_function (node=0x77e7d4e0) at /home/jweil/gcc45/trunk/gcc/cgraphunit.c:499 #8 0x00ccadf3 in cgraph_analyze_function (node=0x77e7d4e0) at /home/jweil/gcc45/trunk/gcc/cgraphunit.c:847 #9 0x00ccb347 in cgraph_analyze_functions () at /home/jweil/gcc45/trunk/gcc/cgraphunit.c:979 #10 0x00ccb7b8 in cgraph_finalize_compilation_unit () at /home/jweil/gcc45/trunk/gcc/cgraphunit.c:1084 #11 0x008aa088 in write_global_declarations () at /home/jweil/gcc45/trunk/gcc/langhooks.c:309 #12 0x009fe59d in compile_file () at /home/jweil/gcc45/trunk/gcc/toplev.c:1061 #13 0x00a00775 in do_compile () at /home/jweil/gcc45/trunk/gcc/toplev.c:2387 #14 0x00a0084b in toplev_main (argc=3, argv=0x7fffe2c8) at /home/jweil/gcc45/trunk/gcc/toplev.c:2429 #15 0x005dbcac in main (argc=3, argv=0x7fffe2c8) at /home/jweil/gcc45/trunk/gcc/main.c:35 -- Summary: ICE with -fopenmp Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: janus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42484
[Bug c++/36236] ICE with forwarding variadic function template in class template
--- Comment #2 from redi at gcc dot gnu dot org 2009-12-23 22:25 --- the original testcase now gives: pr36236.cc: In function int main(): pr36236.cc:21:11: sorry, unimplemented: mangling template_id_expr pr36236.cc:21:11: sorry, unimplemented: mangling template_id_expr and the one in comment 1 compiles without error this is probably a dup of one of the other template mangling PRs -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36236
[Bug fortran/42481] generic interface not recognized
--- Comment #1 from anlauf at gmx dot de 2009-12-23 22:31 --- (In reply to comment #0) Funny, ifort 11.1, xlf 12.1.0.5 and Sunstudio 12.1 accept the code, but nagfor 5.2 rejects it with: NAG Fortran Compiler Release 5.2(686) Warning: prog.f90, line 23: Unused dummy variable X detected at SUB@ Warning: prog.f90, line 34: Unused dummy variable I detected at SUB_INT@ Error: prog.f90, line 40: Symbol SUB found both in module MOD1 and in MOD2 detected at c...@sub [NAG Fortran Compiler pass 1 error termination, 1 error, 2 warnings] -- anlauf at gmx dot de changed: What|Removed |Added CC||anlauf at gmx dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42481
[Bug fortran/42481] generic interface not recognized
--- Comment #2 from anlauf at gmx dot de 2009-12-23 22:39 --- Note that I personally would declare sub as generic in mod1, e.g. module mod1 interface sub module procedure sub end interface contains subroutine sub(x) real x end subroutine sub end module mod1 and remove the corresponding module procedure in mod2, as this resolves the compilation errors with gfortran and nagfor. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42481
[Bug c++/36236] ICE with forwarding variadic function template in class template
--- Comment #3 from paolo dot carlini at oracle dot com 2009-12-23 22:59 --- *** This bug has been marked as a duplicate of 38600 *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36236
[Bug c++/38600] Trouble mangling template_id_expr
--- Comment #10 from paolo dot carlini at oracle dot com 2009-12-23 22:59 --- *** Bug 36236 has been marked as a duplicate of this bug. *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||mcalabrese_gp at hotmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38600
[Bug c++/40044] ICE when resolves overloaded functions
--- Comment #2 from paolo dot carlini at oracle dot com 2009-12-23 23:00 --- Dodji, is this just a duplicate of PR38600? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40044
[Bug c++/189] [DR176] parse error in qualified member name lookup
--- Comment #18 from redi at gcc dot gnu dot org 2009-12-23 23:31 --- *** Bug 37350 has been marked as a duplicate of this bug. *** -- redi at gcc dot gnu dot org changed: What|Removed |Added CC||ian at airs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=189
[Bug c++/37350] Specialized template base class name not accepted
--- Comment #5 from redi at gcc dot gnu dot org 2009-12-23 23:31 --- *** This bug has been marked as a duplicate of 189 *** -- redi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37350
[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64
--- Comment #41 from dominiq at lps dot ens dot fr 2009-12-23 23:34 --- With the patch in comment #38, the tests fail: [karma] f90/bug% gfcp -O3 where_2.f90 [karma] f90/bug% a.out 100 100 100 210 210 210 310 337 310 310 Abort [karma] f90/bug% gfcp -m64 -O3 where_2.f90 [karma] f90/bug% a.out 100 100 100 210 210 210 310 310 337 310 Abort -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082
[Bug c++/36848] const/nonconst virtual function ambiguity deserves a warning
--- Comment #1 from redi at gcc dot gnu dot org 2009-12-23 23:47 ---
When GCC supports C++ attributes you could get the diagnostics you want like
this:
class A_noconst [[base_check]] : public A {
...
};
class A_const [[base_check]] : public A {
...
};
c.f. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2928.htm
As I said in bug 31397 c12 it would be better to implement those attributes
than to add warning switches
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36848
[Bug middle-end/42181] [4.5 Regression] -fgraphite-identity miscompiles or ICEs on air.f90
--- Comment #7 from howarth at nitro dot med dot uc dot edu 2009-12-24 00:14 --- This still appears to be broken at r155434 on x86_64-apple-darwin10 with... gfortran -O2 -fgraphite-identity air.f90 -o air ./air AIRFLOW IN A BOX Version 2.0 (c) Hanley Innovations 1995 1.2E-002 0.210.000 0.100010 272.769998272.769998272.769998 272.7699980. 11 12 X-DATA 1 0. 0.100014 2 5.00028E-002 0.220004 3 0.10001 0.24 4 0.20001 0.400024 5 0.2 0.54 6 0.40002 0.599984 7 0.5 0.699964 8 0.59998 0.800044 9 0.69996 0.900024 10 0.80004 0.969974 11 0.900021.4 Y-DATA 0. 0.100014 4.8E-002 0.149994 8.00017E-002 0.200014 0.14999 0.24 0.20001 0.400024 0.2 0.54 0.40002 0.599984 0.5 0.699964 0.59998 0.800044 0.69996 0.890014 0.80004 0.949964 0.949961.4 ITERATION# TIME FINAL MASS RESIDUAL 14 100.43187820 0.0100 NaN deltat, final t, iterations 100.00100.4318782042 14 14 NaN -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42181
[Bug middle-end/42181] [4.5 Regression] -fgraphite-identity miscompiles or ICEs on air.f90
--- Comment #8 from howarth at nitro dot med dot uc dot edu 2009-12-24 00:15 --- Still broke on x86_64-apple-darwin10. -- howarth at nitro dot med dot uc dot edu changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42181
[Bug middle-end/42181] [4.5 Regression] -fgraphite-identity miscompiles or ICEs on air.f90
--- Comment #9 from howarth at nitro dot med dot uc dot edu 2009-12-24 00:18 --- Created an attachment (id=19380) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19380&action=view) assembly from 'gfortran -O2 -fgraphite-identity air.f90 --save-temps -o air' on x86_64-apple-darwin10 at r155434 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42181
[Bug middle-end/42181] [4.5 Regression] -fgraphite-identity miscompiles or ICEs on air.f90
--- Comment #10 from howarth at nitro dot med dot uc dot edu 2009-12-24 00:20 --- Problem doesn't exist for -O1 -fgraphite-identity on x86_64-apple-darwin10. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42181
[Bug driver/42485] New: [4.4 regression] -V switch broken
Starting at GCC 4.4.0, the -V switch doesn't work: $ gcc-4.1 -V4.3 -dumpversion 4.3.4 $ gcc-4.4 -V4.3 -dumpversion $ -- Summary: [4.4 regression] -V switch broken Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: arthur dot loiret at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42485
[Bug middle-end/42178] [4.5 Regression] gcc.dg/graphite/interchange-8.c causes ICE
--- Comment #11 from howarth at nitro dot med dot uc dot edu 2009-12-24 01:26 --- I still get an ICE on x86_64-apple-darwin10 at r155434 as... Executing on host: /sw/src/fink.build/gcc45-4.4.999-20091223/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc45-4.4.999-20091223/darwin_objdir/gcc/ /sw/src/fink.build/gcc45-4.4.999-20091223/gcc-4.5-20091223/gcc/testsuite/gcc.dg/graphite/interchange-8.c -O2 -fdump-tree-graphite-all -floop-interchange -fno-loop-block -fno-loop-strip-mine -ffast-math -S -o interchange-8.s(timeout = 300) /sw/src/fink.build/gcc45-4.4.999-20091223/gcc-4.5-20091223/gcc/testsuite/gcc.dg/graphite/interchange-8.c: In function 'foo': /sw/src/fink.build/gcc45-4.4.999-20091223/gcc-4.5-20091223/gcc/testsuite/gcc.dg/graphite/interchange-8.c:2:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. compiler exited with status 1 output is: /sw/src/fink.build/gcc45-4.4.999-20091223/gcc-4.5-20091223/gcc/testsuite/gcc.dg/graphite/interchange-8.c: In function 'foo': /sw/src/fink.build/gcc45-4.4.999-20091223/gcc-4.5-20091223/gcc/testsuite/gcc.dg/graphite/interchange-8.c:2:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. FAIL: gcc.dg/graphite/interchange-8.c (internal compiler error) FAIL: gcc.dg/graphite/interchange-8.c (test for excess errors) Excess errors: /sw/src/fink.build/gcc45-4.4.999-20091223/gcc-4.5-20091223/gcc/testsuite/gcc.dg/graphite/interchange-8.c:2:1: internal compiler error: Segmentation fault XFAIL: gcc.dg/graphite/interchange-8.c scan-tree-dump-times graphite "will be interchanged" 1 -- howarth at nitro dot med dot uc dot edu changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42178
[Bug middle-end/42178] [4.5 Regression] gcc.dg/graphite/interchange-8.c causes ICE
--- Comment #12 from howarth at nitro dot med dot uc dot edu 2009-12-24 01:29 --- This backtraces with the Apple gdb as... Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0004 0x0001004e17e8 in lst_interchange_select_inner (scop=, outer_father=, outer=, inner_father=) at ../../gcc-4.5-20091223/gcc/graphite-interchange.c:706 706 for (inner = 0; VEC_iterate (lst_p, LST_SEQ (inner_father), inner, l); inner++) (gdb) bt #0 0x0001004e17e8 in lst_interchange_select_inner (scop=, outer_father=, outer=, inner_father=) at ../../gcc-4.5-20091223/gcc/graphite-interchange.c:706 #1 0x0001004e18fe in lst_interchange_select_inner (scop=, outer_father=, outer=, inner_father=) at ../../gcc-4.5-20091223/gcc/graphite-interchange.c:684 #2 0x0001004e2bb6 in lst_interchange_select_outer (scop=0x14182cc80, loop=0x141826b50, outer=0) at ../../gcc-4.5-20091223/gcc/graphite-interchange.c:732 #3 0x0001004e2c21 in lst_interchange_select_outer (scop=0x14182cc80, loop=0x141826f30, outer=) at ../../gcc-4.5-20091223/gcc/graphite-interchange.c:743 #4 0x0001004e2c5e in scop_do_interchange (scop=0x14182cc80) at ../../gcc-4.5-20091223/gcc/graphite-interchange.c:754 #5 0x0001004e41b8 in apply_poly_transforms (scop=0x14182cc80) at ../../gcc-4.5-20091223/gcc/graphite-poly.c:260 #6 0x0001004cfa93 in graphite_transform_loops () at ../../gcc-4.5-20091223/gcc/graphite.c:276 #7 0x00010077356a in graphite_transforms () at ../../gcc-4.5-20091223/gcc/tree-ssa-loop.c:300 #8 0x0001005b580e in execute_one_pass (pass=0x100c13960) at ../../gcc-4.5-20091223/gcc/passes.c:1561 #9 0x0001005b5add in execute_pass_list (pass=0x100c13960) at ../../gcc-4.5-20091223/gcc/passes.c:1616 #10 0x0001005b5aef in execute_pass_list (pass=0x100c136c0) at ../../gcc-4.5-20091223/gcc/passes.c:1617 #11 0x0001005b5aef in execute_pass_list (pass=0x100c12d00) at ../../gcc-4.5-20091223/gcc/passes.c:1617 #12 0x0001006e4f78 in tree_rest_of_compilation (fndecl=0x141e09900) at ../../gcc-4.5-20091223/gcc/tree-optimize.c:413 #13 0x00010089fa13 in cgraph_expand_function (node=) at ../../gcc-4.5-20091223/gcc/cgraphunit.c:1544 #14 0x0001008a290a in cgraph_optimize () at ../../gcc-4.5-20091223/gcc/cgraphunit.c:1623 #15 0x0001008a2eed in cgraph_finalize_compilation_unit () at ../../gcc-4.5-20091223/gcc/cgraphunit.c:1093 #16 0x00010001ff02 in c_write_global_declarations () at ../../gcc-4.5-20091223/gcc/c-decl.c:9490 #17 0x00010067abe2 in toplev_main (argc=28, argv=0x7fff5fbfeb58) at ../../gcc-4.5-20091223/gcc/toplev.c:1061 #18 0x00011514 in start () (gdb) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42178
[Bug middle-end/42178] [4.5 Regression] gcc.dg/graphite/interchange-8.c causes ICE
--- Comment #13 from howarth at nitro dot med dot uc dot edu 2009-12-24 01:35 --- Note that gcc.dg/graphite/block-4.c also ICEs with essentially the same backtrace... Executing on host: /sw/src/fink.build/gcc45-4.4.999-20091223/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc45-4.4.999-20091223/darwin_objdir/gcc/ /sw/src/fink.build/gcc45-4.4.999-20091223/gcc-4.5-20091223/gcc/testsuite/gcc.dg/graphite/block-4.c -O2 -floop-block -fno-loop-strip-mine -fno-loop-interchange -fdump-tree-graphite-all -S -o block-4.s(timeout = 300) /sw/src/fink.build/gcc45-4.4.999-20091223/gcc-4.5-20091223/gcc/testsuite/gcc.dg/graphite/block-4.c: In function 'test': /sw/src/fink.build/gcc45-4.4.999-20091223/gcc-4.5-20091223/gcc/testsuite/gcc.dg/graphite/block-4.c:8:6: 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. compiler exited with status 1 output is: /sw/src/fink.build/gcc45-4.4.999-20091223/gcc-4.5-20091223/gcc/testsuite/gcc.dg/graphite/block-4.c: In function 'test': /sw/src/fink.build/gcc45-4.4.999-20091223/gcc-4.5-20091223/gcc/testsuite/gcc.dg/graphite/block-4.c:8:6: 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. FAIL: gcc.dg/graphite/block-4.c (internal compiler error) FAIL: gcc.dg/graphite/block-4.c (test for excess errors) Excess errors: /sw/src/fink.build/gcc45-4.4.999-20091223/gcc-4.5-20091223/gcc/testsuite/gcc.dg/graphite/block-4.c:8:6: internal compiler error: Segmentation fault Executing on host: /sw/src/fink.build/gcc45-4.4.999-20091223/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc45-4.4.999-20091223/darwin_objdir/gcc/ /sw/src/fink.build/gcc45-4.4.999-20091223/gcc-4.5-20091223/gcc/testsuite/gcc.dg/graphite/block-5.c -O2 -floop-block -fno-loop-strip-mine -fno-loop-interchange -fdump-tree-graphite-all -S -o block-5.s(timeout = 300) PASS: gcc.dg/graphite/block-5.c (test for excess errors) XFAIL: gcc.dg/graphite/block-5.c scan-tree-dump-times graphite "Interchange valid for loops 0 and 1:" 2 Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0002 0x0001004e17e8 in lst_interchange_select_inner (scop=, outer_father=, outer=, inner_father=) at ../../gcc-4.5-20091223/gcc/graphite-interchange.c:706 706 for (inner = 0; VEC_iterate (lst_p, LST_SEQ (inner_father), inner, l); inner++) (gdb) bt #0 0x0001004e17e8 in lst_interchange_select_inner (scop=, outer_father=, outer=, inner_father=) at ../../gcc-4.5-20091223/gcc/graphite-interchange.c:706 #1 0x0001004e18fe in lst_interchange_select_inner (scop=, outer_father=, outer=, inner_father=) at ../../gcc-4.5-20091223/gcc/graphite-interchange.c:684 #2 0x0001004e18fe in lst_interchange_select_inner (scop=, outer_father=, outer=, inner_father=) at ../../gcc-4.5-20091223/gcc/graphite-interchange.c:684 #3 0x0001004e2bb6 in lst_interchange_select_outer (scop=0x141826800, loop=0x100d11370, outer=0) at ../../gcc-4.5-20091223/gcc/graphite-interchange.c:732 #4 0x0001004e2c21 in lst_interchange_select_outer (scop=0x141826800, loop=0x1418ad9c0, outer=) at ../../gcc-4.5-20091223/gcc/graphite-interchange.c:743 #5 0x0001004e2c21 in lst_interchange_select_outer (scop=0x141826800, loop=0x1418ad9e0, outer=) at ../../gcc-4.5-20091223/gcc/graphite-interchange.c:743 #6 0x0001004e2c5e in scop_do_interchange (scop=0x141826800) at ../../gcc-4.5-20091223/gcc/graphite-interchange.c:754 #7 0x0001004d31a3 in scop_do_block (scop=) at ../../gcc-4.5-20091223/gcc/graphite-blocking.c:293 #8 0x0001004e41e8 in apply_poly_transforms (scop=0x141826800) at ../../gcc-4.5-20091223/gcc/graphite-poly.c:253 #9 0x0001004cfa93 in graphite_transform_loops () at ../../gcc-4.5-20091223/gcc/graphite.c:276 #10 0x00010077356a in graphite_transforms () at ../../gcc-4.5-20091223/gcc/tree-ssa-loop.c:300 #11 0x0001005b580e in execute_one_pass (pass=0x100c13960) at ../../gcc-4.5-20091223/gcc/passes.c:1561 #12 0x0001005b5add in execute_pass_list (pass=0x100c13960) at ../../gcc-4.5-20091223/gcc/passes.c:1616 #13 0x0001005b5aef in execute_pass_list (pass=0x100c136c0) at ../../gcc-4.5-20091223/gcc/passes.c:1617 #14 0x0001005b5aef in execute_pass_list (pass=0x100c12d00) at ../../gcc-4.5-20091223/gcc/passes.c:1617 #15 0x0001006e4f78 in tree_rest_of_compilation (fndecl=0x141e09900) at ../../gcc-4.5-20091223/gcc/tree-optimize.c:413 #16 0x00010089fa13 in cgraph_expand_function (node=) at ../../gcc-4.5-20091223/gcc/cgraphunit.c:1544 #17 0x0001008a290a in cgraph_optimize () at ../../gcc-4.5-20091223/gcc/cgraphunit.c:1623 #18 0x0001008a2eed in cgraph_finalize_compilation_unit () at ../../gcc-4.5-20091223/gcc/cgraphunit.c:1093 #19 0x00010001ff02 in c_write_global
[Bug target/42486] New: Parameter spilling can be merged into function prologue
Compile the attached source code with options -Os -mthumb, gcc generates:
sort_basket:
push{r4, r5, r6, r7, lr}
sub sp, sp, #20
str r1, [sp, #8] // A
b .L10
.L13:
mov r0, r4
.L10:
ldr r1, [sp, #8]
add r3, r0, r1
...
Instruction A spills parameter into stack, it is always executed at the start
of the function, so it can be merged into the function prologue
push{r1, r4, r5, r6, r7, lr}
--
Summary: Parameter spilling can be merged into function prologue
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42486
[Bug target/42486] Parameter spilling can be merged into function prologue
--- Comment #1 from carrot at google dot com 2009-12-24 01:47 --- Created an attachment (id=19381) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19381&action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42486
[Bug tree-optimization/42334] segfault in graphite-poly.h for 200.sixtrack
--- Comment #9 from howarth at nitro dot med dot uc dot edu 2009-12-24 02:29 --- On x86_64-apple-darwin10, the two new test cases are cause ICEs... FAIL: gfortran.dg/graphite/pr42334-1.f -O (internal compiler error) FAIL: gfortran.dg/graphite/pr42334-1.f -O (test for excess errors) FAIL: gfortran.dg/graphite/pr42393.f90 -O (internal compiler error) FAIL: gfortran.dg/graphite/pr42393.f90 -O (test for excess errors) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42334
[Bug tree-optimization/42334] segfault in graphite-poly.h for 200.sixtrack
--- Comment #10 from howarth at nitro dot med dot uc dot edu 2009-12-24 02:34 --- The pr42334-1.f test case fails as... Executing on host: /sw/src/fink.build/gcc45-4.4.999-20091223/darwin_objdir/gcc/testsuite/gfortran/../../gfortran -B/sw/src/fink.build/gcc45-4.4.999-20091223/darwin_objdir/gcc/testsuite/gfortran/../../ /sw/src/fink.build/gcc45-4.4.999-20091223/gcc-4.5-20091223/gcc/testsuite/gfortran.dg/graphite/pr42334-1.f -O -O2 -floop-interchange -S -o pr42334-1.s(timeout = 300) /sw/src/fink.build/gcc45-4.4.999-20091223/gcc-4.5-20091223/gcc/testsuite/gfortran.dg/graphite/pr42334-1.f: In function 'linel': /sw/src/fink.build/gcc45-4.4.999-20091223/gcc-4.5-20091223/gcc/testsuite/gfortran.dg/graphite/pr42334-1.f:3:0: 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. compiler exited with status 1 output is: /sw/src/fink.build/gcc45-4.4.999-20091223/gcc-4.5-20091223/gcc/testsuite/gfortran.dg/graphite/pr42334-1.f: In function 'linel': /sw/src/fink.build/gcc45-4.4.999-20091223/gcc-4.5-20091223/gcc/testsuite/gfortran.dg/graphite/pr42334-1.f:3:0: 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. FAIL: gfortran.dg/graphite/pr42334-1.f -O (internal compiler error) FAIL: gfortran.dg/graphite/pr42334-1.f -O (test for excess errors) Excess errors: /sw/src/fink.build/gcc45-4.4.999-20091223/gcc-4.5-20091223/gcc/testsuite/gfortran.dg/graphite/pr42334-1.f:3:0: internal compiler error: Segmentation fault and backtraces as Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0002 0x0001005355c8 in lst_interchange_select_inner (scop=, outer_father=, outer=, inner_father=) at ../../gcc-4.5-20091223/gcc/graphite-interchange.c:706 706 for (inner = 0; VEC_iterate (lst_p, LST_SEQ (inner_father), inner, l); inner++) (gdb) bt #0 0x0001005355c8 in lst_interchange_select_inner (scop=, outer_father=, outer=, inner_father=) at ../../gcc-4.5-20091223/gcc/graphite-interchange.c:706 #1 0x0001005356de in lst_interchange_select_inner (scop=, outer_father=, outer=, inner_father=) at ../../gcc-4.5-20091223/gcc/graphite-interchange.c:684 #2 0x000100536996 in lst_interchange_select_outer (scop=0x14182d360, loop=0x14185d390, outer=1) at ../../gcc-4.5-20091223/gcc/graphite-interchange.c:732 #3 0x000100536a01 in lst_interchange_select_outer (scop=0x14182d360, loop=0x141831f80, outer=) at ../../gcc-4.5-20091223/gcc/graphite-interchange.c:743 #4 0x000100536a01 in lst_interchange_select_outer (scop=0x14182d360, loop=0x141831fa0, outer=) at ../../gcc-4.5-20091223/gcc/graphite-interchange.c:743 #5 0x000100536a3e in scop_do_interchange (scop=0x14182d360) at ../../gcc-4.5-20091223/gcc/graphite-interchange.c:754 #6 0x000100537f98 in apply_poly_transforms (scop=0x14182d360) at ../../gcc-4.5-20091223/gcc/graphite-poly.c:260 #7 0x000100523873 in graphite_transform_loops () at ../../gcc-4.5-20091223/gcc/graphite.c:276 #8 0x0001007c734a in graphite_transforms () at ../../gcc-4.5-20091223/gcc/tree-ssa-loop.c:300 #9 0x0001006095ee in execute_one_pass (pass=0x100c7fda0) at ../../gcc-4.5-20091223/gcc/passes.c:1561 #10 0x0001006098bd in execute_pass_list (pass=0x100c7fda0) at ../../gcc-4.5-20091223/gcc/passes.c:1616 #11 0x0001006098cf in execute_pass_list (pass=0x100c7fb00) at ../../gcc-4.5-20091223/gcc/passes.c:1617 #12 0x0001006098cf in execute_pass_list (pass=0x100c7f140) at ../../gcc-4.5-20091223/gcc/passes.c:1617 #13 0x000100738d58 in tree_rest_of_compilation (fndecl=0x141df1e00) at ../../gcc-4.5-20091223/gcc/tree-optimize.c:413 #14 0x0001008f37f3 in cgraph_expand_function (node=) at ../../gcc-4.5-20091223/gcc/cgraphunit.c:1544 #15 0x0001008f66ea in cgraph_optimize () at ../../gcc-4.5-20091223/gcc/cgraphunit.c:1623 #16 0x0001008f6ccd in cgraph_finalize_compilation_unit () at ../../gcc-4.5-20091223/gcc/cgraphunit.c:1093 #17 0x00010059b8b6 in write_global_declarations () at ../../gcc-4.5-20091223/gcc/langhooks.c:309 #18 0x0001006ce9c2 in toplev_main (argc=19, argv=0x7fff5fbfee70) at ../../gcc-4.5-20091223/gcc/toplev.c:1061 #19 0x00011534 in start () (gdb) at r155434. Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/sw/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin10.2.0/4.5.0/lto-wrapper Target: x86_64-apple-darwin10.2.0 Configured with: ../gcc-4.5-20091223/configure --prefix=/sw --prefix=/sw/lib/gcc4.5 --mandir=/sw/share/man --infodir=/sw/share/info --enable-languages=c,c++,fortran,objc,obj-c++,java --with-gmp=/sw --with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-mpc=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --disable-libj
[Bug middle-end/42393] [4.5 Regression] [graphite] internal compiler error: in check_loop_closed_ssa_use
--- Comment #7 from howarth at nitro dot med dot uc dot edu 2009-12-24 02:37 --- Still fails on x86_64-apple-darwin10 at r155434... Executing on host: /sw/src/fink.build/gcc45-4.4.999-20091223/darwin_objdir/gcc/testsuite/gfortran/../../gfortran -B/sw/src/fink.build/gcc45-4.4.999-20091223/darwin_objdir/gcc/testsuite/gfortran/../../ /sw/src/fink.build/gcc45-4.4.999-20091223/gcc-4.5-20091223/gcc/testsuite/gfortran.dg/graphite/pr42393.f90 -O -fgraphite-identity -O2 -S -o pr42393.s(timeout = 300) /sw/src/fink.build/gcc45-4.4.999-20091223/gcc-4.5-20091223/gcc/testsuite/gfortran.dg/graphite/pr42393.f90: In function 'basym': /sw/src/fink.build/gcc45-4.4.999-20091223/gcc-4.5-20091223/gcc/testsuite/gfortran.dg/graphite/pr42393.f90:6:0: internal compiler error: in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:424 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. compiler exited with status 1 output is: /sw/src/fink.build/gcc45-4.4.999-20091223/gcc-4.5-20091223/gcc/testsuite/gfortran.dg/graphite/pr42393.f90: In function 'basym': /sw/src/fink.build/gcc45-4.4.999-20091223/gcc-4.5-20091223/gcc/testsuite/gfortran.dg/graphite/pr42393.f90:6:0: internal compiler error: in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:424 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. FAIL: gfortran.dg/graphite/pr42393.f90 -O (internal compiler error) FAIL: gfortran.dg/graphite/pr42393.f90 -O (test for excess errors) Excess errors: /sw/src/fink.build/gcc45-4.4.999-20091223/gcc-4.5-20091223/gcc/testsuite/gfortran.dg/graphite/pr42393.f90:6:0: internal compiler error: in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:424 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42393
[Bug middle-end/42393] [4.5 Regression] [graphite] internal compiler error: in check_loop_closed_ssa_use
--- Comment #8 from howarth at nitro dot med dot uc dot edu 2009-12-24 03:56 --- This can't be backtraced after the crash but the last breakpoint on tree-ssa-loop-manip.c:425 before the crash shows... Breakpoint 1, check_loop_closed_ssa_use (bb=0x141e793a8, use=0x141e90160) at ../../gcc-4.5-20091223/gcc/tree-ssa-loop-manip.c:425 425 } #0 check_loop_closed_ssa_use (bb=0x141e793a8, use=0x141e90160) at ../../gcc-4.5-20091223/gcc/tree-ssa-loop-manip.c:425 #1 0x0001007b9010 in verify_loop_closed_ssa () at ../../gcc-4.5-20091223/gcc/tree-ssa-loop-manip.c:464 #2 0x000100527d99 in translate_clast (region=, stmt=, next_e=, rename_map=, newivs=, newivs_index=, bb_pbb_mapping=, params_index=) at ../../gcc-4.5-20091223/gcc/graphite-clast-to-gimple.c:65 #3 0x0001005286fc in translate_clast (region=, stmt=, next_e=, rename_map=, newivs=, newivs_index=, bb_pbb_mapping=, params_index=) at ../../gcc-4.5-20091223/gcc/graphite-clast-to-gimple.c:832 #4 0x00010052a294 in gloog (scop=, bb_pbb_mapping=) at ../../gcc-4.5-20091223/gcc/graphite-clast-to-gimple.c:1451 #5 0x000100523882 in graphite_transform_loops () at ../../gcc-4.5-20091223/gcc/graphite.c:277 #6 0x0001007c734a in graphite_transforms () at ../../gcc-4.5-20091223/gcc/tree-ssa-loop.c:300 #7 0x0001006095ee in execute_one_pass (pass=0x100c7fda0) at ../../gcc-4.5-20091223/gcc/passes.c:1561 #8 0x0001006098bd in execute_pass_list (pass=0x100c7fda0) at ../../gcc-4.5-20091223/gcc/passes.c:1616 #9 0x0001006098cf in execute_pass_list (pass=0x100c7fb00) at ../../gcc-4.5-20091223/gcc/passes.c:1617 #10 0x0001006098cf in execute_pass_list (pass=0x100c7f140) at ../../gcc-4.5-20091223/gcc/passes.c:1617 #11 0x000100738d58 in tree_rest_of_compilation (fndecl=0x141df1c00) at ../../gcc-4.5-20091223/gcc/tree-optimize.c:413 #12 0x0001008f37f3 in cgraph_expand_function (node=) at ../../gcc-4.5-20091223/gcc/cgraphunit.c:1544 #13 0x0001008f66ea in cgraph_optimize () at ../../gcc-4.5-20091223/gcc/cgraphunit.c:1623 #14 0x0001008f6ccd in cgraph_finalize_compilation_unit () at ../../gcc-4.5-20091223/gcc/cgraphunit.c:1093 #15 0x00010059b8b6 in write_global_declarations () at ../../gcc-4.5-20091223/gcc/langhooks.c:309 #16 0x0001006ce9c2 in toplev_main (argc=18, argv=0x7fff5fbfd9c8) at ../../gcc-4.5-20091223/gcc/toplev.c:1061 #17 0x00011534 in start () /sw/src/fink.build/gcc45-4.4.999-20091223/gcc-4.5-20091223/gcc/testsuite/gfortran.dg/graphite/pr42393.f90: In function basym: /sw/src/fink.build/gcc45-4.4.999-20091223/gcc-4.5-20091223/gcc/testsuite/gfortran.dg/graphite/pr42393.f90:6:0: internal compiler error: in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:424 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. Program exited with code 04. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42393
[Bug c/42487] New: FAIL: gcc.dg/debug/dwarf2/aranges-fnsec-1.c scan-assembler DW_AT_ranges
The new testcase... FAIL: gcc.dg/debug/dwarf2/aranges-fnsec-1.c scan-assembler DW_AT_ranges fails on x86_64-apple-darwin10... Executing on host: /sw/src/fink.build/gcc45-4.4.999-20091223/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc45-4.4.999-20091223/darwin_objdir/gcc/ /sw/src/fink.build/gcc45-4.4.999-20091223/gcc-4.5-20091223/gcc/testsuite/gcc.dg/debug/dwarf2/aranges-fnsec-1.c -gdwarf-2 -ffunction-sections -w -dA -S -o aranges-fnsec-1.s(timeout = 300) PASS: gcc.dg/debug/dwarf2/aranges-fnsec-1.c (test for excess errors) PASS: gcc.dg/debug/dwarf2/aranges-fnsec-1.c scan-assembler-not \\.Letext0-\\.Ltext0 PASS: gcc.dg/debug/dwarf2/aranges-fnsec-1.c scan-assembler-not \\.Ltext0[^\n\r]*Offset 0x0 FAIL: gcc.dg/debug/dwarf2/aranges-fnsec-1.c scan-assembler DW_AT_ranges -- Summary: FAIL: gcc.dg/debug/dwarf2/aranges-fnsec-1.c scan- assembler DW_AT_ranges Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: howarth at nitro dot med dot uc dot edu GCC build triplet: x86_64-apple-darwin10 GCC host triplet: x86_64-apple-darwin10 GCC target triplet: x86_64-apple-darwin10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42487
[Bug c/42487] FAIL: gcc.dg/debug/dwarf2/aranges-fnsec-1.c scan-assembler DW_AT_ranges
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2009-12-24 04:02 --- Created an attachment (id=19382) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19382&action=view) assembly for gcc.dg/debug/dwarf2/aranges-fnsec-1.c on x86_64-apple-darwin10 Generated with... /sw/src/fink.build/gcc45-4.4.999-20091223/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc45-4.4.999-20091223/darwin_objdir/gcc/ /sw/src/fink.build/gcc45-4.4.999-20091223/gcc-4.5-20091223/gcc/testsuite/gcc.dg/debug/dwarf2/aranges-fnsec-1.c -gdwarf-2 -ffunction-sections -w -dA -S -o aranges-fnsec-1.s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42487
[Bug c++/42488] New: spurious strict-aliasing warning
The following very simple program is giving me a warning with g++ 4.4.2 with
-Wall (or -Wstrict-aliasing=1, 2 or 3). I don't think it should be giving the
warning, so I think this is a bug.
Replacing std::complex with a simple user-defined complex-like class makes the
warning go away, so maybe there is a bug in the complex class?
Also, replacing the virtual inheritance with normal inheritance makes the
warning go away.
Likewise removing the A class and moving the virtual inheritance to C : virtual
public B.
Or if I make the argument of foo a reference.
===
#include
struct A {
virtual int value() const=0;
};
struct B : virtual public A {
bool isOne() const { return A::value() == 1; }
};
struct C : public B {
int value() const { return 1; }
};
struct D {
void foo(std::complex x) const; // foo is extern
};
void callFoo()
{
C c;
D d;
if (c.isOne()) d.foo(0);
}
===
The warning produced is:
>g++-4 -c -O2 -Wstrict-aliasing foo.cpp
foo.cpp: In function void callFoo():
foo.cpp:9: warning: dereferencing pointer does break
strict-aliasing rules
foo.cpp:9: note: initialized from here
This appears to me to be different from similar bugs: 41838, 39390 which
reference the same warning, but maybe it is related.
--
Summary: spurious strict-aliasing warning
Product: gcc
Version: 4.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: michael at jarvis dot net
GCC build triplet: i686-apple-darwin9
GCC host triplet: i686-apple-darwin9
GCC target triplet: i686-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42488
[Bug c++/42488] spurious strict-aliasing warning
--- Comment #1 from michael at jarvis dot net 2009-12-24 05:12 --- Created an attachment (id=19383) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19383&action=view) source file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42488
[Bug c++/42488] spurious strict-aliasing warning
--- Comment #2 from michael at jarvis dot net 2009-12-24 05:12 --- Created an attachment (id=19384) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19384&action=view) preprocessed source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42488
[Bug c++/42488] spurious strict-aliasing warning
--- Comment #3 from michael at jarvis dot net 2009-12-24 05:13 --- Created an attachment (id=19385) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19385&action=view) full g++ -v output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42488
[Bug middle-end/42488] spurious strict-aliasing warning
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-12-24 05:40 ---
Here is a reduced testcase without the include:
struct complex
{
complex(float b = 0.0, float c = 0.0) { __real__ a = b; __imag__ a = c; }
_Complex float a;
};
struct A {
virtual int value() const=0;
};
struct B : virtual public A {
bool isOne() const { return A::value() == 1; }
};
struct C : public B {
int value() const { return 1; }
};
struct D {
void foo(complex x) const;
};
void callFoo()
{
C c;
D d;
if (c.isOne()) d.foo(0);
}
CUT
Note making the complex a non-POD makes the warning go away.
Also it works on the trunk.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|c++ |middle-end
Keywords||diagnostic
Known to work||4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42488
[Bug rtl-optimization/42388] [4.5 Regression] ICE in move_bb_info with sel-sched and modulo-sched for 176.gcc
--- Comment #3 from abel at gcc dot gnu dot org 2009-12-24 07:39 ---
The problem was that the failing assert is actually too strict, when an empty
block is removed, its predecessor could be outside the region. After fixing
this, I have also further robustified the function to expect empty blocks with
no succs or preds, as this problem showed itself yet another time via the
single failed test of the patch on ia64.
* sel-sched-ir.c (maybe_tidy_empty_bb): Do not delete empty blocks
that have no predecessors nor successors. Do not call move_bb_info
for empty blocks outside of current region.
---
gcc/sel-sched-ir.c | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/gcc/sel-sched-ir.c b/gcc/sel-sched-ir.c
index 3c2989a..0950f2a 100644
--- a/gcc/sel-sched-ir.c
+++ b/gcc/sel-sched-ir.c
@@ -3519,12 +3519,15 @@ maybe_tidy_empty_bb (basic_block bb)
bool rescan_p;
/* Keep empty bb only if this block immediately precedes EXIT and
- has incoming non-fallthrough edge. Otherwise remove it. */
+ has incoming non-fallthrough edge, or it has no predecessors or
+ successors. Otherwise remove it. */
if (!sel_bb_empty_p (bb)
|| (single_succ_p (bb)
&& single_succ (bb) == EXIT_BLOCK_PTR
&& (!single_pred_p (bb)
- || !(single_pred_edge (bb)->flags & EDGE_FALLTHRU
+ || !(single_pred_edge (bb)->flags & EDGE_FALLTHRU)))
+ || EDGE_COUNT (bb->preds) == 0
+ || EDGE_COUNT (bb->succs) == 0)
return false;
/* Do not attempt to redirect complex edges. */
@@ -3574,7 +3577,8 @@ maybe_tidy_empty_bb (basic_block bb)
{
gcc_assert (pred_bb != NULL);
- move_bb_info (pred_bb, bb);
+ if (in_current_region_p (pred_bb))
+ move_bb_info (pred_bb, bb);
remove_empty_bb (bb, true);
}
--
abel at gcc dot gnu dot org changed:
What|Removed |Added
CC||abel at gcc dot gnu dot org,
||amonakov at gcc dot gnu dot
||org
AssignedTo|unassigned at gcc dot gnu |abel at gcc dot gnu dot org
|dot org |
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-12-24 07:39:24
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42388
