[Bug middle-end/32285] [4.1 Regression] Miscompilation with pure _Complex returning call inside another fn's argument list
--- Comment #10 from jakub at gcc dot gnu dot org 2007-06-20 06:36 --- Subject: Bug 32285 Author: jakub Date: Wed Jun 20 06:35:55 2007 New Revision: 125873 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125873 Log: PR middle-end/32285 * calls.c (precompute_arguments): Also precompute CALL_EXPR arguments if ACCUMULATE_OUTGOING_ARGS. * gcc.c-torture/execute/20070614-1.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/20070614-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/calls.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32285
[Bug inline-asm/32109] [4.1/4.2/4.3 regression] ICE with inline-asm and class with destructor
--- Comment #2 from jakub at gcc dot gnu dot org 2007-06-20 06:37 --- Subject: Bug 32109 Author: jakub Date: Wed Jun 20 06:37:17 2007 New Revision: 125874 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125874 Log: PR inline-asm/32109 * gimplify.c (gimplify_asm_expr): Issue error if type is addressable and !allows_mem. * g++.dg/ext/asm10.C: New test. Added: trunk/gcc/testsuite/g++.dg/ext/asm10.C Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32109
[Bug middle-end/31959] [4.3 Regression] ICE in expand_builtin_expect, at builtins.c:5112
--- Comment #4 from jakub at gcc dot gnu dot org 2007-06-20 06:40 --- Subject: Bug 31959 Author: jakub Date: Wed Jun 20 06:39:53 2007 New Revision: 125875 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125875 Log: PR middle-end/31959 * builtins.c: Include diagnostic.h. (expand_builtin_expect): Make gcc_assert more permissive. * Makefile.in (builtins.o): Depend on $(DIAGNOSTIC_H). * gcc.dg/pr31959.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr31959.c Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/builtins.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31959
[Bug middle-end/32285] [4.1 Regression] Miscompilation with pure _Complex returning call inside another fn's argument list
--- Comment #11 from jakub at gcc dot gnu dot org 2007-06-20 06:44 --- Subject: Bug 32285 Author: jakub Date: Wed Jun 20 06:44:26 2007 New Revision: 125877 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125877 Log: PR middle-end/32285 * calls.c (precompute_arguments): Also precompute CALL_EXPR arguments if ACCUMULATE_OUTGOING_ARGS. * gcc.c-torture/execute/20070614-1.c: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/gcc.c-torture/execute/20070614-1.c Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/calls.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32285
[Bug inline-asm/32109] [4.1/4.2/4.3 regression] ICE with inline-asm and class with destructor
--- Comment #3 from jakub at gcc dot gnu dot org 2007-06-20 06:46 --- Subject: Bug 32109 Author: jakub Date: Wed Jun 20 06:46:31 2007 New Revision: 125878 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125878 Log: PR inline-asm/32109 * gimplify.c (gimplify_asm_expr): Issue error if type is addressable and !allows_mem. * g++.dg/ext/asm10.C: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/ext/asm10.C Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/gimplify.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32109
[Bug middle-end/32285] [4.1 Regression] Miscompilation with pure _Complex returning call inside another fn's argument list
--- Comment #12 from jakub at gcc dot gnu dot org 2007-06-20 06:50 --- Subject: Bug 32285 Author: jakub Date: Wed Jun 20 06:50:23 2007 New Revision: 125879 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125879 Log: PR middle-end/32285 * calls.c (precompute_arguments): Also precompute CALL_EXPR arguments if ACCUMULATE_OUTGOING_ARGS. * gcc.c-torture/execute/20070614-1.c: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.c-torture/execute/20070614-1.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/calls.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32285
[Bug inline-asm/32109] [4.1/4.2/4.3 regression] ICE with inline-asm and class with destructor
--- Comment #4 from jakub at gcc dot gnu dot org 2007-06-20 06:51 --- Subject: Bug 32109 Author: jakub Date: Wed Jun 20 06:51:47 2007 New Revision: 125880 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125880 Log: PR inline-asm/32109 * gimplify.c (gimplify_asm_expr): Issue error if type is addressable and !allows_mem. * g++.dg/ext/asm10.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/asm10.C Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/gimplify.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32109
[Bug rtl-optimization/32405] assertion failure in loop-iv.c; probable dataflow regression
--- Comment #2 from rakdver at gcc dot gnu dot org 2007-06-20 06:56 --- Subject: Bug 32405 Author: rakdver Date: Wed Jun 20 06:56:26 2007 New Revision: 125881 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125881 Log: PR rtl-optimization/32405 * loop-iv.c (iv_get_reaching_def): Fail for partial defs. Modified: trunk/gcc/ChangeLog trunk/gcc/loop-iv.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32405
[Bug rtl-optimization/32405] assertion failure in loop-iv.c; probable dataflow regression
--- Comment #3 from rakdver at gcc dot gnu dot org 2007-06-20 06:57 --- Should be fixed now. -- rakdver at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32405
[Bug target/32406] [4.3 Regression] MIPS: FAIL in nestfunc-6.c at -O3
--- Comment #2 from daney at gcc dot gnu dot org 2007-06-20 07:11 --- Created an attachment (id=13739) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13739action=view) First patch attempt. I think this patch fixes this bug. The test case looks better from my cross-compiler. I will bootstrap it to be sure. I don't really like the patch that much though. It forces $gp to be loaded in a nonlocal_goto_receiver, which fixes the bug in cases where $gp is needed. If $gp is not needed, it would be nice not to force it to be restored. In vain I tried to mark $gp as clobbered in hope that it would be magically restored if needed. I guess I need a bit more RTL foo. If there are two function calls in the nonlocal goto target (two uses of $gp with a clobber between), the second call has $gp restored. I think there should be a way to make the first use of $gp to cause $gp to be restored, but I don't know what it is. Thanks to Hans-Peter Nilsson for the pointer. -- daney at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |daney at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32406
[Bug bootstrap/32272] make exit because build/genmodes.exe doesn't exist
--- Comment #1 from boris at phidani dot be 2007-06-20 07:18 --- got same problem with gcc 4.2.0 on suse linux 9.0: I did: /opt/gcc-4.2.0/configure --program-suffix=-4.2.0 then: make CFLAGS='-O' LIBCFLAGS='-g -O2' LIBCXXFLAGS='-g -O2 -fno-implicit-templates' bootstrap Here is the last lines of the output: snip ar cru libdecnumber.a decNumber.o decContext.o decUtility.o decimal32.o decimal64.o decimal128.o ranlib libdecnumber.a make[3]: Leaving directory `/opt/gcc-4.2.0-obj/libdecnumber' make[3]: Entering directory `/opt/gcc-4.2.0-obj/gcc' TARGET_CPU_DEFAULT= \ HEADERS=auto-host.h ansidecl.h DEFINES= \ /bin/sh /opt/gcc-4.2.0/gcc/mkconfig.sh config.h TARGET_CPU_DEFAULT= \ HEADERS=options.h config/i386/i386.h config/i386/unix.h config/i386/att.h config/dbxelf.h config/elfos.h config/svr4.h config/linux.h config/i386/linux.h defaults.h DEFINES=UCLIBC_DEFAULT=0 \ /bin/sh /opt/gcc-4.2.0/gcc/mkconfig.sh tm.h gawk -f /opt/gcc-4.2.0/gcc/opt-gather.awk /opt/gcc-4.2.0/gcc/treelang/lang.opt /opt/gcc-4.2.0/gcc/c.opt /opt/gcc-4.2.0/gcc/common.opt /opt/gcc-4.2.0/gcc/config/i386/i386.opt /opt/gcc-4.2.0/gcc/config/linux.opt tmp-optionlist /bin/sh /opt/gcc-4.2.0/gcc/../move-if-change tmp-optionlist optionlist echo timestamp s-options gawk -f /opt/gcc-4.2.0/gcc/opt-functions.awk -f /opt/gcc-4.2.0/gcc/opth-gen.awk \ optionlist tmp-options.h /bin/sh /opt/gcc-4.2.0/gcc/../move-if-change tmp-options.h options.h echo timestamp s-options-h TARGET_CPU_DEFAULT= \ HEADERS=auto-host.h ansidecl.h DEFINES= \ /bin/sh /opt/gcc-4.2.0/gcc/mkconfig.sh bconfig.h gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I/opt/gcc-4.2.0/gcc -I/opt/gcc-4.2.0/gcc/build -I/opt/gcc-4.2.0/gcc/../include -I/opt/gcc-4.2.0/gcc/../libcpp/include -I/opt/gcc-4.2.0/gcc/../libdecnumber -I../libdecnumber-o build/errors.o /opt/gcc-4.2.0/gcc/errors.c build/genmodes -h tmp-modes.h /bin/sh: line 1: build/genmodes: No such file or directory make[3]: *** [s-modes-h] Error 127 make[3]: Leaving directory `/opt/gcc-4.2.0-obj/gcc' make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory `/opt/gcc-4.2.0-obj' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/opt/gcc-4.2.0-obj' make: *** [bootstrap] Error 2 -- boris at phidani dot be changed: What|Removed |Added CC||boris at phidani dot be http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32272
[Bug bootstrap/32024] ICE - libgcc2.c:557: internal compiler error: in fold_checksum_tree, at fold-const.c:12652
--- Comment #10 from ubizjak at gmail dot com 2007-06-20 08:23 ---
Confirmed, configure gcc with --enable=checking=fold
--cut here--
typedef union
{
struct {int low, high;} s;
long long ll;
} DWunion;
long long
__muldi3 (long long u, long long v)
{
const DWunion uu = {.ll = u};
const DWunion vv = {.ll = v};
DWunion w = {.ll = 0 };
w.s.high += ((unsigned int) uu.s.low * (unsigned int) vv.s.high
+ (unsigned int) uu.s.high * (unsigned int) vv.s.low);
return w.ll;
}
--cut here--
gcc -O2:
mul.c: In function '__muldi3':
mul.c:9: internal compiler error: in fold_checksum_tree, at fold-const.c:12775
Please submit a full bug report,
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|middle-end |bootstrap
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2007-06-20 08:23:06
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32024
[Bug c++/32412] New: Passing struct as parameter breaks SRA for stack-allocated struct inside called function
sra-bug.C (below) contains a function which stack-allocates a local struct
containing two small arrays. The function depends on SRA to eliminate repeated
memory accesses to the two arrays as it streams over a large, third array.
The performance of the executables resulting from
g++ -Wall -O3 -msse3 -fpeel-loops sra-bug.C
and
g++ -Wall -O3 -msse3 -fpeel-loops sra-bug.C -DTRIGGER_BUG
differs by exactly 2x on my machine (a 2.66GHz Core2 quad Xeon), with the
runtime increasing from .395 ns/value/entry to .790 ns/value/entry.
The only difference between the two versions is whether the array pointer and
count are passed as separate arguments (fast) or wrapped in a struct (slow),
even though the latter gets copied into local variables before use. Use of the
__restrict keyword didn't seem to make a difference. The assembler output shows
that excessive loads and stores nearly double the instruction count of the
unrolled inner loop for the slower case.
FYI gcc-4.2.0 shows similar behavior, though its output is slower than 4.1 for
both cases (.420ns vs 1.10ns). gcc-4.3-20070617 performs equally badly on both
versions of the code (.690 ns/value/entry).
sra-bug.C:
===
#include emmintrin.h
#include stdint.h
#include cassert
#include cstdio
#include sys/time.h
struct stopwatch_t {
struct timeval tv; long long mark;
stopwatch_t() { reset(); }
double time_ns() {
long long old_mark = mark; reset(); return 1e3*(mark - old_mark);
}
void reset() {
gettimeofday(tv, NULL); mark = tv.tv_usec + tv.tv_sec*100ll;
}
};
templateint N, class T, class Action
inline void unrolled_loop(T* entries, Action action) {
for(int i=0; i N; i++) action(entries[i]);
}
static __m128i const ALL_ZEROS = {0ull, 0ull};
static __m128i const ALL_ONES = {~0ull, ~0ull};
static int const COUNT=4;
struct Action16 {
__m128i _results[COUNT];
__m128i _values[COUNT];
__m128i* _dest;
Action16(__m128i* dest, uint64_t const* values) : _dest(dest) {
for(int i=0; i COUNT; i++) {
_results[i] = ALL_ZEROS;
_values[i] = _mm_set1_epi16((short) values[i]);
}
}
void operator()(__m128i const entry) {
for(int i=0; i COUNT; i++)
_results[i] |= _mm_cmpeq_epi16(_values[i], entry);
}
~Action16() {
for(int i=0; i COUNT; i++)
_dest[i] = _mm_movemask_epi8(_results[i])? ALL_ONES : ALL_ZEROS;
}
};
struct wrapper {
__m128i const* entries;
int count;
};
#ifdef TRIGGER_BUG
void foo(__m128i* dest, uint64_t const* values, wrapper const w) {
__m128i const* entries = w.entries; int count = w.count;
#else
void foo(__m128i* dest, uint64_t const* values, __m128i const* entries, int
coun
t) {
#endif
static int const unroll_count=16;
Action16 action(dest, values);
assert((count % unroll_count) == 0);
for(int i=0; i+unroll_count count; i+=unroll_count)
unrolled_loopunroll_count(entries[i], action);
}
int main() {
int VALUE_COUNT = 100;
int LIST_SIZE = 2048;
uint64_t* values = new uint64_t[VALUE_COUNT];
__m128i* dest = (__m128i*) _mm_malloc(16*VALUE_COUNT, 16);
__m128i entries[LIST_SIZE];
wrapper w = {entries, LIST_SIZE};
stopwatch_t timer;
for(int j=0; j 5; j++) {
for(int i=0; i VALUE_COUNT; i+= COUNT) {
#ifdef TRIGGER_BUG
foo(dest+i, values+i, w);
#else
foo(dest+i, values+i, entries, LIST_SIZE);
#endif
}
printf(%.3lf ns/value/entry\n, timer.time_ns()/LIST_SIZE/VALUE_COUNT);
}
}
--
Summary: Passing struct as parameter breaks SRA for stack-
allocated struct inside called function
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: scovich at gmail dot com
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32412
[Bug c++/32413] New: [4.3 Regression] internal compiler error: in reload_cse_simplify_operands, at postreload.c:396
svn revision:125876
cc -c -mno-cygwin -mdll -fno-rtti -mthreads -pipe -D_WINGDI_ -DUCLIBCPP
-D_GLIBC
PP_HAVE_MBSTATE_T -D_WIN32_IE=0x0500 -msse4a -DARCH_IS_IA32 -DARCH_IS_32BIT
-DHA
VE_MMX -w -DNDEBUG -UDEBUG -DFFDEBUG=0 -I. -I.. -Iuclibc++ -Ibaseclasses
-I../ba
seclasses -IimgFilters -I../imgFilters -Implayer -I../mplayer -Isettings
-I../se
ttings -Isettings/filters -I../settings/filters -Icodecs -I../codecs
-Isubtitles
-I../subtitles -Iconvert -I../convert -Idialog -I../dialog -IaudioFilters
-I../
audioFilters -Icygwin -I../cygwin -Iffmpeg -I../ffmpeg -Iacm -I../acm -Ixiph
-I.
./xiph -Ifilters -I../filters -Imuxers -I../muxers -O4 -march=core2
-mtune=core2
-fomit-frame-pointer -finline-functions -finline -frename-registers -fweb
-funi
t-at-a-time -o ffdshow_all.o ffdshow_all.cpp
In file included from ffdshow_all.cpp:37:
DeCSSInputPin.cpp: In member function 'virtual long int
CDeCSSInputPin::Set(cons
t GUID, ULONG, void*, ULONG, void*, ULONG)':
DeCSSInputPin.cpp:254: error: insn does not satisfy its constraints:
(insn 1194 592 593 19 CSSscramble.cpp:174 (set (reg:QI 22 xmm1 [orig:545
t5.7036
1 ] [545])
(reg:QI 0 ax)) 43 {*movqi_1} (nil))
DeCSSInputPin.cpp:254: internal compiler error: in
reload_cse_simplify_operands,
at postreload.c:396
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
make: *** [ffdshow_all.o] Error 1
cc: warning: -pipe ignored because -save-temps specified
In file included from ffdshow_all.cpp:38:
DeCSSInputPin.cpp: In member function 'virtual long int
CDeCSSInputPin::Set(cons
t GUID, ULONG, void*, ULONG, void*, ULONG)':
DeCSSInputPin.cpp:254: error: insn does not satisfy its constraints:
(insn 1194 592 593 19 CSSscramble.cpp:174 (set (reg:QI 22 xmm1 [orig:545
t5.7036
1 ] [545])
(reg:QI 0 ax)) 43 {*movqi_1} (nil))
DeCSSInputPin.cpp:254: internal compiler error: in
reload_cse_simplify_operands,
at postreload.c:396
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
--
Summary: [4.3 Regression] internal compiler error: in
reload_cse_simplify_operands, at postreload.c:396
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jojelino at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32413
[Bug c++/32413] [4.3 Regression] internal compiler error: in reload_cse_simplify_operands, at postreload.c:396
--- Comment #1 from jojelino at gmail dot com 2007-06-20 08:39 --- Created an attachment (id=13740) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13740action=view) preprocessed file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32413
[Bug fortran/32140] [4.3 Regression] Miscompilation with -O1
--- Comment #19 from jv244 at cam dot ac dot uk 2007-06-20 08:48 --- (In reply to comment #17) Here is the fix which I am testing, basically instead of creating (typeof(array[0] *)array we create array[lb]: did this fix test OK ? Since it fixes the CP2K issue, I would hope that it could be posted for review soon. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32140
[Bug fortran/32140] [4.3 Regression] Miscompilation with -O1
--- Comment #20 from fxcoudert at gcc dot gnu dot org 2007-06-20 08:52 --- (In reply to comment #19) did this fix test OK ? Since it fixes the CP2K issue, I would hope that it could be posted for review soon. The patch is OK to commit along with a testcase from this PR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32140
[Bug bootstrap/32024] ICE - libgcc2.c:557: internal compiler error: in fold_checksum_tree, at fold-const.c:12652
--- Comment #11 from ubizjak at gmail dot com 2007-06-20 08:55 --- backtrace: (gdb) bt #0 fancy_abort (file=0x8a02980 ../../gcc-svn/trunk/gcc/fold-const.c, line=12775, function=0x8a021be fold_checksum_tree) at ../../gcc-svn/trunk/gcc/diagnostic.c:656 #1 0x08207fc1 in fold_checksum_tree (expr=0xb7f55de4, ctx=0xbfab4df0, ht=0x92ce1e8) at ../../gcc-svn/trunk/gcc/fold-const.c:12775 #2 0x082077bf in fold_checksum_tree (expr=0xb7f5b138, ctx=0xbfab4df0, ht=0x92ce1e8) at ../../gcc-svn/trunk/gcc/fold-const.c:12779 #3 0x0823b69e in fold_build1_stat (code=NOP_EXPR, type=0xb7eb5360, op0=0xb7f5b138) at ../../gcc-svn/trunk/gcc/fold-const.c:12892 #4 0x0823b9f7 in fold_convert (type=0xb7eb5360, arg=0xb7f5b138) at ../../gcc-svn/trunk/gcc/fold-const.c:2281 #5 0x0894307c in chrec_convert_1 (type=0xb7eb5360, chrec=0xb7f5b138, at_stmt=0xb7f55e00, use_overflow_semantics=1 '\001') at ../../gcc-svn/trunk/gcc/tree-chrec.c:1308 #6 0x0842482b in interpret_rhs_modify_stmt (loop=0xb7f57c38, at_stmt=0xb7f55e00, opnd1=0xb7f4e1a0, type=0xb7eb5360) at -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32024
[Bug bootstrap/32024] ICE - libgcc2.c:557: internal compiler error: in fold_checksum_tree, at fold-const.c:12652
--- Comment #12 from ubizjak at gmail dot com 2007-06-20 08:59 --- (In reply to comment #11) backtrace: (gdb) frame 4 #4 0x0823b9f7 in fold_convert (type=0xb7eb5360, arg=0xb7f5b138) at ../../gcc-svn/trunk/gcc/fold-const.c:2281 (gdb) p debug_tree (arg) ssa_name 0xb7f5b138 type integer_type 0xb7eb52f4 int sizes-gimplified public SI size integer_cst 0xb7ea6658 constant invariant 32 unit size integer_cst 0xb7ea6444 constant invariant 4 align 32 symtab 0 alias set 4 canonical type 0xb7eb52f4 precision 32 min integer_cst 0xb7ea6604 -2147483648 max integer_cst 0xb7ea6620 2147483647 pointer_to_this pointer_type 0xb7ebb798 visited var var_decl 0xb7f57114 D.1650 def_stmt gimple_modify_stmt 0xb7f55de4 version 3 So, chrec_convert_1() is sending ssa_name into fold_convert(). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32024
[Bug bootstrap/32024] ICE - libgcc2.c:557: internal compiler error: in fold_checksum_tree, at fold-const.c:12652
--- Comment #13 from ubizjak at gmail dot com 2007-06-20 09:03 --- svn blame of tree-chrec.c 114057rakdver /* If we cannot propagate the cast inside the chrec, just keep the cast. */ 114057rakdver keep_cast: 100718 spop res = fold_convert (type, chrec); 97607 ebotcazou -- ubizjak at gmail dot com changed: What|Removed |Added CC||spop at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32024
[Bug target/32414] New: [4.1/4.2 Regression] Poor code for inner loop on i386
/* { dg-do compile } */
/* { dg-options -O2 -m32 -mtune=generic } */
typedef unsigned short int uint16_t;
typedef unsigned int uint32_t;
extern int get_src_stride(void);
extern int get_dst_stride(void);
void
foo (uint32_t *pSrc, uint32_t *pDst, uint16_t width, uint16_t height)
{
uint32_t *dstLine;
register uint32_t *dst;
uint32_t *srcLine;
register uint32_t *src;
int dstStride, srcStride;
uint16_t w;
srcStride = get_src_stride ();
dstStride = get_dst_stride ();
dstLine = pDst;
srcLine = pSrc;
while (height--)
{
dst = dstLine;
dstLine += dstStride;
src = srcLine;
srcLine += srcStride;
w = width;
while (w--)
*dst++ = *src++ | 0xFF00;
}
}
generates extremely poor code for the inner loop in 4.1 and 4.2:
.L6:
movl-16(%ebp), %eax # src,
subw$1, -34(%ebp) #, w
addl$4, -16(%ebp) #, src
movl(%eax), %ecx#,
movl-20(%ebp), %eax # dst,
orl $-16777216, %ecx#,
movl%ecx, (%eax)#,
addl$4, %eax#,
cmpw$-1, -34(%ebp) #, w
movl%eax, -20(%ebp) #, dst
je .L4 #,
jmp .L6 #
I believe this has been introduced by the
http://gcc.gnu.org/ml/gcc-patches/2005-07/msg02021.html
patch and fixed by
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg02095.html
on the trunk. The generated loop isn't perfect on the trunk:
.L4:
movl(%ebx), %eax#* src, tmp82
addl$4, %ebx#, src
subw$1, -14(%ebp) #, w
orl $-16777216, %eax#, tmp82
movl%eax, (%edi)# tmp82,* dst
addl$4, %edi#, dst
cmpw$-1, -14(%ebp) #, w
je .L3 #,
jmp .L4 #
but still far better than what 4.1 and 4.2 generate.
Slightly modified:
typedef unsigned short int uint16_t;
typedef unsigned int uint32_t;
extern int get_src_stride(void);
extern int get_dst_stride(void);
void
foo (uint32_t *pSrc, uint32_t *pDst, uint16_t width, uint16_t height)
{
uint32_t *dstLine;
register uint32_t *dst;
uint32_t *srcLine;
register uint32_t *src;
int dstStride, srcStride;
uint32_t w;
srcStride = get_src_stride ();
dstStride = get_dst_stride ();
dstLine = pDst;
srcLine = pSrc;
while (height--)
{
dst = dstLine;
dstLine += dstStride;
src = srcLine;
srcLine += srcStride;
for (w = 0; w width; w++)
dst[w] = src[w] | 0xFF00;
}
}
generates more compact code:
.L4:
movl(%edx,%ecx,4), %eax #* srcLine, tmp79
orl $-16777216, %eax#, tmp79
movl%eax, (%ebx,%ecx,4) # tmp79,* dstLine
addl$1, %ecx#, w
cmpl%esi, %ecx # width, w
jae .L3 #,
jmp .L4 #
--
Summary: [4.1/4.2 Regression] Poor code for inner loop on i386
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
GCC target triplet: i386-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32414
[Bug middle-end/32285] [4.1 Regression] Miscompilation with pure _Complex returning call inside another fn's argument list
--- Comment #13 from jakub at gcc dot gnu dot org 2007-06-20 09:24 --- Fixed in SVN, the performance regression caused by PR25550 patch is still present though. -- 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=32285
[Bug fortran/32404] Wrong-code with sbdart (valgrind errors, different output)
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-06-20 09:41 --- I can reproduce what you see, nor make any sense of the instructions comparing the outputs: when I do what you indicate, all I see in the output is a namelist-type of scalar values: INPUT IDATM= 4, AMIX= -1.00 , ISAT= 0, WLINF= 0.55011920929 , WLSUP= 0.55011920929 , WLINC= 0.00 , SZA= 0.00 , CSZA= -1.00 , SOLFAC= 1.00 , NF= 2, IDAY= 0, TIME= 16.0 , ALAT= -64.7669982910156 , ALON= -64.0670013427734 , ZPRES= -1.00 , PBAR= -1.00 , SCLH2O= -1.00 , UW= -1.00 , UO3= -1.00 , O3TRP= -1.00 , ZTRP= 0.00 , XRSC= 1.00 , XN2= -1.00 , XO2= -1.00 , XCO2= -1.00 , XCH4= -1.00 , XN2O= -1.00 , XCO= -1.00 , XNO2= -1.00 , XSO2= -1.00 , XNH3= -1.00 , XNO= -1.00 , XHNO3= -1.00 , XO4= 1.00 , ISALB= 0, ALBCON= 0.00 , SC= 5*3.402823466385289E+038 , ZCLOUD= 5*0.00 , TCLOUD= 5*0.00 , LWP= 5*0.00 , NRE= 5*8.00 , RHCLD= -1.00 , KRHCLR= 0, JAER= 5*0 , ZAER= 5*0.00 , TAERST= 5*0.00 , IAER= 0, VIS= -1.00 , RHAER= -1.00 , TBAER= -1.00 , WLBAER= 150*-1.00 , QBAER= 150*-1.00 , ABAER= 0.00 , WBAER= 150*-1.00 , GBAER= 150*-1.00 , PMAER= 44850*-1.00 , ZBAER= 65*-1.00 , DBAER= 65*-1.00 , NOTHRM= -1, NOSCT= 0, KDIST= 3, ZGRID1= 1.00 , ZGRID2= 30.0 , NGRID= 0, IDB= 20*0 , ZOUT= 0.00 , 100. , IOUT= 10, PRNT= 7*F, TEMIS= 0.00 , NSTR= 0, NZEN= 0, UZEN= 40*-1.00 , VZEN= 40*90.0 , NPHI= 0, PHI= 40*-1.00 , SAZA= 180. , IMOMC= 3, IMOMA= 3, TTEMP= -1.00 , BTEMP= -1.00 , CORINT=F, SPOWDER=F, / What do you call columns in this output? -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Keywords|wrong-code | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32404
[Bug tree-optimization/32199] jc1: out of memory allocating 4072 bytes after a total of 805021000 bytes
--- Comment #3 from ro at gcc dot gnu dot org 2007-06-20 09:44 ---
I observe the same problem (also affecting gnu-xml.lo) on
alpha-dec-osf{4.0f,5.1b}.
VM consumption for org-omg.lo is at 1.5 GB now, a machine with 768 MB physical
memory crawls along for hours compiling the file. I had to double swap space
from 2 GB to 4 GB to be able to compile at all, while there was on such problem
in gcc 4.2.0 as of 20070506.
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
CC||ro at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32199
[Bug inline-asm/32109] [4.1/4.2/4.3 regression] ICE with inline-asm and class with destructor
--- Comment #5 from jakub at gcc dot gnu dot org 2007-06-20 09:46 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32109
[Bug middle-end/31959] [4.3 Regression] ICE in expand_builtin_expect, at builtins.c:5112
--- Comment #5 from jakub at gcc dot gnu dot org 2007-06-20 09:48 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31959
[Bug target/32414] [4.1/4.2 Regression] Poor code for inner loop on i386
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Keywords||missed-optimization Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32414
[Bug bootstrap/12019] check for working C compiler on newlib targets fails due to missing crt0.o
--- Comment #2 from rask at sygehus dot dk 2007-06-20 11:00 --- Does it work for you if you apply patch 3 from bug other/32154? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12019
[Bug other/32154] sim-crt0.o/crt0.o isn't found during configure due to missing -L or -B
--- Comment #10 from bonzini at gnu dot org 2007-06-20 11:13 --- DJ, do you think this patch is ok? -- bonzini at gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32154
[Bug tree-optimization/31866] [4.3 Regression] ICE with tree check error: expected ssa_name, have var_decl in create_outofssa_var_map
-- 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|NEW |ASSIGNED Last reconfirmed|2007-05-09 01:45:25 |2007-06-20 11:23:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31866
[Bug middle-end/31490] Compile error section type conflict
--- Comment #11 from schwab at suse dot de 2007-06-20 11:32 --- Also broken on ia64. -- schwab at suse dot de changed: What|Removed |Added GCC target triplet|powerpc64-*-linux-gnu |powerpc64-*-linux-gnu,ia64- ||*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31490
[Bug c/32415] New: libgcc_s not found in library search path with --enable-version-specific-runtime-libs
Minimal program in test.c:
int main() {}
Compile:
# /var/scratch/lionelb/usr/gcc-4.1.2/bin/gcc -v test.c
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /var/scratch/lionelb/usr/src/gcc-4.1.2/configure
--prefix=/var/scratch/lionelb/usr/gcc-4.1.2 --enable-languages=c,c++,fortran
--enable-version-specific-runtime-libs
--with-build-time-tools=/var/scratch/lionelb/usr/binutils-2.17/bin
--with-as=/var/scratch/lionelb/usr/binutils-2.17/bin/as
--with-ld=/var/scratch/lionelb/usr/binutils-2.17/bin/ld --enable-__cxa_atexit
Thread model: posix
gcc version 4.1.2
/var/scratch/lionelb/usr/gcc-4.1.2/libexec/gcc/x86_64-unknown-linux-gnu/4.1.2/cc1
-quiet -v test.c -quiet -dumpbase test.c -mtune=k8 -auxbase test -version -o
/tmp/cc92Pr4G.s
ignoring nonexistent directory
/var/scratch/lionelb/usr/gcc-4.1.2/lib/gcc/x86_64-unknown-linux-gnu/4.1.2/../../../../x86_64-unknown-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/usr/local/include
/var/scratch/lionelb/usr/gcc-4.1.2/include
/var/scratch/lionelb/usr/gcc-4.1.2/lib/gcc/x86_64-unknown-linux-gnu/4.1.2/include
/usr/include
End of search list.
GNU C version 4.1.2 (x86_64-unknown-linux-gnu)
compiled by GNU C version 3.4.6 20060404 (Red Hat 3.4.6-8).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 2f59716e3dacf2fc2f167478c592
/var/scratch/lionelb/usr/binutils-2.17/bin/as -V -Qy -o /tmp/ccgIgKwi.o
/tmp/cc92Pr4G.s
GNU assembler version 2.17 (x86_64-unknown-linux-gnu) using BFD version 2.17
/var/scratch/lionelb/usr/gcc-4.1.2/libexec/gcc/x86_64-unknown-linux-gnu/4.1.2/collect2
--eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2
/usr/lib/../lib64/crt1.o /usr/lib/../lib64/crti.o
/var/scratch/lionelb/usr/gcc-4.1.2/lib/gcc/x86_64-unknown-linux-gnu/4.1.2/crtbegin.o
-L/var/scratch/lionelb/usr/gcc-4.1.2/lib/gcc/x86_64-unknown-linux-gnu/4.1.2
-L/var/scratch/lionelb/usr/gcc-4.1.2/lib/gcc/x86_64-unknown-linux-gnu/4.1.2/../../..
-L/lib/../lib64 -L/usr/lib/../lib64 /tmp/ccgIgKwi.o -lgcc --as-needed -lgcc_s
--no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed
/var/scratch/lionelb/usr/gcc-4.1.2/lib/gcc/x86_64-unknown-linux-gnu/4.1.2/crtend.o
/usr/lib/../lib64/crtn.o
/var/scratch/lionelb/usr/binutils-2.17/bin/ld: cannot find -lgcc_s
collect2: ld returned 1 exit status
Now:
# find /var/scratch/lionelb/usr/gcc-4.1.2 -name libgcc_s*
/var/scratch/lionelb/usr/gcc-4.1.2/lib/gcc/x86_64-unknown-linux-gnu/lib/libgcc_s.so
/var/scratch/lionelb/usr/gcc-4.1.2/lib/gcc/x86_64-unknown-linux-gnu/lib/libgcc_s.so.1
/var/scratch/lionelb/usr/gcc-4.1.2/lib/gcc/x86_64-unknown-linux-gnu/lib64/libgcc_s.so
/var/scratch/lionelb/usr/gcc-4.1.2/lib/gcc/x86_64-unknown-linux-gnu/lib64/libgcc_s.so.1
so it doesn't look as if gcc is looking in the right place for libgcc_s.
This problem appears to affect GCC 4.2.0 as well.
--
Summary: libgcc_s not found in library search path with --enable-
version-specific-runtime-libs
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lionelb dot nospam at gmail dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32415
[Bug fortran/32298] MINLOC / MAXLOC: off-by one for PARAMETER arrays
--- Comment #3 from pault at gcc dot gnu dot org 2007-06-20 12:15 ---
This does the job by detecting the generation of a temporary. In this case the
loop is zero based but the calculated value for the position does not reflect
this.
I'll have a think about whether or not this is the cleanest way to fix the bug
and then I will submit tonight.
Paul
Index: gcc/fortran/trans-intrinsic.c
===
*** gcc/fortran/trans-intrinsic.c (révision 125706)
--- gcc/fortran/trans-intrinsic.c (copie de travail)
*** gfc_conv_intrinsic_minmaxloc (gfc_se * s
*** 2046,2052
gfc_add_modify_expr (ifblock, limit, arrayse.expr);
/* Remember where we are. */
! gfc_add_modify_expr (ifblock, pos, loop.loopvar[0]);
ifbody = gfc_finish_block (ifblock);
--- 2046,2060
gfc_add_modify_expr (ifblock, limit, arrayse.expr);
/* Remember where we are. */
! if (loop.temp_dim)
! {
! tmp = build2 (PLUS_EXPR, TREE_TYPE (pos),
! loop.loopvar[0],
! build_int_cst (type, 1));
! gfc_add_modify_expr (ifblock, pos, tmp);
! }
! else
! gfc_add_modify_expr (ifblock, pos, loop.loopvar[0]);
ifbody = gfc_finish_block (ifblock);
*** gfc_conv_intrinsic_minmaxloc (gfc_se * s
*** 2099,2109
gfc_cleanup_loop (loop);
/* Return a value in the range 1..SIZE(array). */
! tmp = fold_build2 (MINUS_EXPR, gfc_array_index_type, loop.from[0],
!gfc_index_one_node);
! tmp = fold_build2 (MINUS_EXPR, gfc_array_index_type, pos, tmp);
/* And convert to the required type. */
! se-expr = convert (type, tmp);
}
static void
--- 2107,2120
gfc_cleanup_loop (loop);
/* Return a value in the range 1..SIZE(array). */
! if (!loop.temp_dim)
! {
! tmp = fold_build2 (MINUS_EXPR, gfc_array_index_type, loop.from[0],
!gfc_index_one_node);
! pos = fold_build2 (MINUS_EXPR, gfc_array_index_type, pos, tmp);
! }
/* And convert to the required type. */
! se-expr = convert (type, pos);
}
static void
Index: gcc/testsuite/gfortran.dg/minmax_loc_1.f90
===
*** gcc/testsuite/gfortran.dg/minmax_loc_1.f90 (révision 0)
--- gcc/testsuite/gfortran.dg/minmax_loc_1.f90 (révision 0)
***
*** 0
--- 1,29
+ ! { dg-do run }
+ ! Tests the fix for PR32298, in which the scalarizer would generate
+ ! a temporary in the course of evaluating MINLOC or MAXLOC, thereby
+ ! setting the start of the scalarizer loop to zero.
+ !
+ ! Contributed by Jens Bischoff [EMAIL PROTECTED]
+ !
+ PROGRAM ERR_MINLOC
+
+INTEGER, PARAMETER :: N = 7
+
+DOUBLE PRECISION, DIMENSION (N), PARAMETER :: A
+ = (/ 0.3D0, 0.455D0, 0.6D0, 0.7D0, 0.72D0, 0.76D0, 0.79D0 /)
+
+DOUBLE PRECISION :: B
+INTEGER :: I, J(N), K(N)
+
+ DO I = 1, N
+ B = A(I)
+ J(I) = MINLOC (ABS (A - B), 1)
+ K(I) = MAXLOC (ABS (A - B), 1)
+ END DO
+
+ if (any (J .NE. (/1,2,3,4,5,6,7/))) call abort ()
+ if (any (K .NE. (/7,7,1,1,1,1,1/))) call abort ()
+
+ STOP
+
+ END PROGRAM ERR_MINLOC
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org
|dot org |
Status|NEW |ASSIGNED
Last reconfirmed|2007-06-12 16:05:26 |2007-06-20 12:15:24
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32298
[Bug bootstrap/32024] ICE - libgcc2.c:557: internal compiler error: in fold_checksum_tree, at fold-const.c:12652
--- Comment #14 from rguenth at gcc dot gnu dot org 2007-06-20 12:28 --- Don't use fold checking, it's broken. *** This bug has been marked as a duplicate of 20623 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32024
[Bug middle-end/20623] ICE: fold check: original tree changed by fold with --enable-checking=fold
--- Comment #14 from rguenth at gcc dot gnu dot org 2007-06-20 12:28 --- *** Bug 32024 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rob1weld at aol dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20623
[Bug c++/32416] New: pointer-to-member stuff inconsistently compiled without warning
I. CODE SAMPLE
#include stdio.h
#define SHOWBUG
class A;
class F
{
public:
F(A *x, void (A::*y)()) : m_x(x), m_y(y) {}
void operator()();
private:
A *m_x;
void (A::*m_y)();
};
#ifdef SHOWBUG
void F::operator()() { (m_x-*m_y)(); }
#endif
class A
{
public:
void f() { printf(A::f()\n); }
};
#ifndef SHOWBUG
void F::operator()() { (m_x-*m_y)(); }
#endif
int main()
{
A x;
F f(x, A::f);
f();
}
II. EXPLANATION
A is a class that has a method void f().
F is a class that wraps a void(A::*)() method.
The program creates an A object, then it creates an F object
that wraps the void f() method of the created A object,
then it invokes operator() of the F object.
The expected behaviour is that invoking the operator() of the F object
should trigger the invocation of the f() method of the wrapped A object
(which would print something on the console).
The observed behaviour is that the A::f() method sometimes is invoked
(as expected) and sometimes is not invoked (incorrect?).
Whether the A::f() is correctly invoked by invoking the F::operator()
method depends on the respective order in which class A and F::operator()
are defined.
By setting #define SHOWBUG, the A::f() is not invoked.
By setting #undef SHOWBUG, the A::f() is invoked (as expected).
The problem is that in both cases the code compiles fine with no warning
whatsoever (even with -Wall).
--
Summary: pointer-to-member stuff inconsistently compiled without
warning
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: emmanuel dot garcia at infoterra dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32416
[Bug target/32413] [4.3 Regression] internal compiler error: in reload_cse_simplify_operands, at postreload.c:396
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Component|c++ |target GCC target triplet||i686-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32413
[Bug other/32411] GCC Collect2 adds extra -lm's to link commands even when not linking with -lm.
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-20 12:55 --- The page http://gcc.gnu.org/gcc-4.3/changes.html#mpfropts says libm is being replaced with libmpfr. No it does not say that, please stop reading the changes page incorrectly. What it is saying is that inside the compiler, GCC will now do constant folding. You are wrong that GCC is replacing libm with mpfr. -- 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=32411
[Bug target/32406] [4.3 Regression] MIPS: FAIL in nestfunc-6.c at -O3
--- Comment #3 from richard at codesourcery dot com 2007-06-20 12:56 --- Subject: Re: [4.3 Regression] MIPS: FAIL in nestfunc-6.c at -O3 daney at gcc dot gnu dot org [EMAIL PROTECTED] writes: I don't really like the patch that much though. It forces $gp to be loaded in a nonlocal_goto_receiver, which fixes the bug in cases where $gp is needed. If $gp is not needed, it would be nice not to force it to be restored. In vain I tried to mark $gp as clobbered in hope that it would be magically restored if needed. I guess I need a bit more RTL foo. If there are two function calls in the nonlocal goto target (two uses of $gp with a clobber between), the second call has $gp restored. I think there should be a way to make the first use of $gp to cause $gp to be restored, but I don't know what it is. The post-reload splitter converts the unspec_volatile into an ordinary move. In theory (TM), if the restore isn't needed, it should get deleted as dead after that point. Stepping back, the model here is that anything up to and including the post-reload splitters can introduce new uses of pic_offset_table_rtx. (This includes reload, which might need new uses of pic_offset_table_rtx in order to access the constant pool. It also includes high/lo_sum accesses that we previously modelled as being purely symbolic; this higher-level, register-free form is easier to optimise.) So we basically consider $gp to be live throughout the function before the post-reload splitters. At that point, when using explicit relocs, every use of $gp becomes explicit, and normal liveness rules apply. Do you have an example of a function that does need $gp at some point, but which restores $gp unnecessarily at other points? I suppose there will be cases where a function with a nonlocal goto doesn't need $gp at all, but sets $gp up anyway because of the set in the receiver pattern. I can think of a way of dealing with that, but it will mean adding special cases. I wonder how often it would trigger. Richard -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32406
[Bug middle-end/32412] Passing struct as parameter breaks SRA for stack-allocated struct inside called function
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-20 12:57 --- wrapper const w You are passing via reference which does not break SRA, just changes the ABI and such. This is a very very hard problem to solve without the whole program. I wondering if I should close it as won't fix. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c++ |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32412
[Bug middle-end/32417] New: [4.3 Regression] 416.gamess ICEs
/gcc/spec/sb-balakirew-head-64-2006/x86_64/install-hack/bin/gfortran -c -o nmr.fppized.o-O2 -DSPEC_CPU_LP64 -ffixed-form nmr.fppized.f nmr.fppized.f: In function 'oneints': nmr.fppized.f:617: internal compiler error: in build2_stat, at tree.c:3074 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- Summary: [4.3 Regression] 416.gamess ICEs Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32417
[Bug target/32418] New: ICE in global_alloc, at global.c:514
Configure gcc like this: $ [...]/configure --target m32c-unknown-elf --with-newlib--enable-sim --disable-gdb --disable-nls --enable-languages=c,c++,java The attached file fails to compile: $ ./xgcc -B./ ~/unwind-dw2.c -S -dp -o /dev/null -O2 /n/08/rask/src/gcc/libgcc/../gcc/unwind.inc: In function '_Unwind_Resume': /n/08/rask/src/gcc/libgcc/../gcc/unwind.inc:241: internal compiler error: in global_alloc, at global.c:514 -- Summary: ICE in global_alloc, at global.c:514 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rask at sygehus dot dk GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: m32c-unknown-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32418
[Bug middle-end/32417] [4.3 Regression] 416.gamess ICEs
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-06-20 13:20 --- Created an attachment (id=13741) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13741action=view) testcase Testcase that fails with -O2 -ffixed-form -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32417
[Bug middle-end/32417] [4.3 Regression] 416.gamess ICEs
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-06-20 13:21 ---
#0 fancy_abort (
file=0xe87fc8 /space/rguenther/src/svn/pointer_plus/gcc/tree.c,
line=3074, function=0xe893df build2_stat)
at /space/rguenther/src/svn/pointer_plus/gcc/diagnostic.c:656
#1 0x00a28c7e in build2_stat (code=MULT_EXPR, tt=0x2ab8fd777600,
arg0=0x2ab8fe1bc8c0, arg1=0x2ab8fe1acb70)
at /space/rguenther/src/svn/pointer_plus/gcc/tree.c:3074
#2 0x006b4c2b in fold_build2_stat (code=MULT_EXPR,
type=0x2ab8fd777600, op0=0x2ab8fe1bc8c0, op1=0x2ab8fe1acb70)
at /space/rguenther/src/svn/pointer_plus/gcc/fold-const.c:12943
#3 0x00d5df39 in aff_combination_add_elt (comb=0x7fffad3af9f0,
elt=0x2ab8fe137840, scale={low = 4, high = 0})
at /space/rguenther/src/svn/pointer_plus/gcc/tree-affine.c:175
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot
|dot org |org
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32417
[Bug target/32419] New: ICE in global_alloc, at global.c:514
Configure gcc like this: $ [...]/configure --target m32c-unknown-elf --with-newlib--enable-sim --disable-gdb --disable-nls --enable-languages=c,c++,java The attached file fails to compile: $ ./xgcc -B./ ~/unwind-dw2.c -S -dp -o /dev/null -O2 /n/08/rask/src/gcc/libgcc/../gcc/unwind.inc: In function '_Unwind_Resume': /n/08/rask/src/gcc/libgcc/../gcc/unwind.inc:241: internal compiler error: in global_alloc, at global.c:514 -- Summary: ICE in global_alloc, at global.c:514 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rask at sygehus dot dk GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: m32c-unknown-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32419
[Bug target/32418] ICE in global_alloc, at global.c:514
--- Comment #1 from rask at sygehus dot dk 2007-06-20 13:21 --- Created an attachment (id=13742) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13742action=view) Preprocessed testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32418
[Bug target/32420] New: ICE in global_alloc, at global.c:514
Configure gcc like this: $ [...]/configure --target m32c-unknown-elf --with-newlib--enable-sim --disable-gdb --disable-nls --enable-languages=c,c++,java The attached file fails to compile: $ ./xgcc -B./ ~/unwind-dw2.c -S -dp -o /dev/null -O2 /n/08/rask/src/gcc/libgcc/../gcc/unwind.inc: In function '_Unwind_Resume': /n/08/rask/src/gcc/libgcc/../gcc/unwind.inc:241: internal compiler error: in global_alloc, at global.c:514 -- Summary: ICE in global_alloc, at global.c:514 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rask at sygehus dot dk GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: m32c-unknown-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32420
[Bug fortran/32140] [4.3 Regression] Miscompilation with -O1
--- Comment #21 from pinskia at gmail dot com 2007-06-20 13:22 --- Subject: Re: [4.3 Regression] Miscompilation with -O1 did this fix test OK ? Since it fixes the CP2K issue, I would hope that it could be posted for review soon. I can't get to testing this patch fully until Friday evening (PST) at the earliest. Sorry about that. My machine was crashing and then I left for Japan on Monday and won't get access to a machine until Friday at the earliest with all the meetings in Japan. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32140
[Bug target/32418] ICE in global_alloc, at global.c:514
--- Comment #2 from rask at sygehus dot dk 2007-06-20 13:24 --- *** Bug 32420 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32418
[Bug target/32420] ICE in global_alloc, at global.c:514
--- Comment #1 from rask at sygehus dot dk 2007-06-20 13:24 --- *** This bug has been marked as a duplicate of 32418 *** -- rask at sygehus dot dk changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32420
[Bug target/32419] ICE in global_alloc, at global.c:514
--- Comment #1 from rask at sygehus dot dk 2007-06-20 13:25 --- *** This bug has been marked as a duplicate of 32418 *** -- rask at sygehus dot dk changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32419
[Bug target/32418] ICE in global_alloc, at global.c:514
--- Comment #3 from rask at sygehus dot dk 2007-06-20 13:25 --- *** Bug 32419 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32418
[Bug tree-optimization/32421] New: [4.3 Regression] -ftree-vectorize -msse2 ICEs in build2_stat when vectorizing POINTER_PLUS_EXPR
Testcase:
int f(int **restrict a, int ** restrict b)
{
int i;
for(i= 0;i32;i++)
a[i] = b[i] + 1;
}
--
Summary: [4.3 Regression] -ftree-vectorize -msse2 ICEs in
build2_stat when vectorizing POINTER_PLUS_EXPR
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32421
[Bug tree-optimization/32421] [4.3 Regression] -ftree-vectorize -msse2 ICEs in build2_stat when vectorizing POINTER_PLUS_EXPR
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-20 13:34 --- Mine. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-06-20 13:34:42 date|| Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32421
[Bug target/32335] libgcc build failure, ICE in cselib_record_set, at cselib.c:1508
--- Comment #10 from rask at sygehus dot dk 2007-06-20 13:41 --- I'm adding the m32c back because the testcase for bug 32069 fails with optimization turned on: $ ./xgcc -B./ /n/08/rask/src/gcc/gcc/testsuite/gcc.dg/pr32069.c -S -dp -o /dev/null -O1 /n/08/rask/src/gcc/gcc/testsuite/gcc.dg/pr32069.c: In function 'segfault': /n/08/rask/src/gcc/gcc/testsuite/gcc.dg/pr32069.c:7: internal compiler error: in cselib_record_set, at cselib.c:1508 (gdb) call debug_rtx(insn) (jump_insn 62 61 63 2 /n/08/rask/src/gcc/gcc/testsuite/gcc.dg/pr32069.c:7 (parallel [ (set (reg:PSI 8 sp) (plus:PSI (reg:PSI 7 fb) (const_int 2 [0x2]))) (set (reg:PSI 7 fb) (mem:PSI (reg:PSI 7 fb) [0 S4 A8])) (return) ]) -1 (nil)) -- rask at sygehus dot dk changed: What|Removed |Added GCC target triplet|avr-unknown-elf |avr-unknown-elf m32c- ||unknown-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32335
[Bug c++/32416] pointer-to-member stuff inconsistently compiled without warning
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-20 13:44 --- *** This bug has been marked as a duplicate of 15684 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32416
[Bug c++/15684] Pointer to member function called on incomplete type should diag
--- Comment #16 from pinskia at gcc dot gnu dot org 2007-06-20 13:44 --- *** Bug 32416 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||emmanuel dot garcia at ||infoterra dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15684
[Bug target/32335] libgcc build failure, ICE in cselib_record_set, at cselib.c:1508
--- Comment #11 from rask at sygehus dot dk 2007-06-20 13:52 --- Ah, notice the mismatch in register sizes between prologue and epilogue: (insn/f 59 5 60 2 /n/08/rask/src/gcc/gcc/testsuite/gcc.dg/pr32069.c:5 (parallel [ (set/f (mem:HI (plus:HI (reg/f:HI 8 sp) (const_int -2 [0xfffe])) [0 S2 A8]) (reg/f:HI 7 fb)) (set/f (reg/f:HI 7 fb) (reg/f:HI 8 sp)) (set/f (reg/f:HI 8 sp) (minus:HI (reg/f:HI 8 sp) (const_int 2 [0x2]))) ]) -1 (nil)) -- rask at sygehus dot dk changed: What|Removed |Added GCC target triplet|avr-unknown-elf m32c- |avr-unknown-elf |unknown-elf | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32335
[Bug fortran/32140] [4.3 Regression] Miscompilation with -O1
--- Comment #22 from rguenth at gcc dot gnu dot org 2007-06-20 13:53 --- It would be nice if a fortraner could make the testcase not output to stdout/err but to /dev/null instead. open(6,'/dev/null') didn't work for me ;) Just to make a testcase suitable for the testsuite. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32140
[Bug fortran/32140] [4.3 Regression] Miscompilation with -O1
--- Comment #23 from rguenth at gcc dot gnu dot org 2007-06-20 13:55 --- stupid me. open(6,file='/dev/null') works. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32140
[Bug fortran/32140] [4.3 Regression] Miscompilation with -O1
--- Comment #24 from jv244 at cam dot ac dot uk 2007-06-20 14:03 --- (In reply to comment #22) It would be nice if a fortraner could make the testcase not output to stdout/err but to /dev/null instead. open(6,'/dev/null') didn't work for me ;) Just to make a testcase suitable for the testsuite. The following testcase, for an unpatched compiler, aborts at -O1, works fine at -O0, and doesn't write to stdout/stderr... I guess that fits the testsuite ? MODULE TEST CONTAINS PURE FUNCTION s2a_3(s1,s2,s3) RESULT(a) CHARACTER(LEN=*), INTENT(IN) :: s1, s2, s3 CHARACTER(LEN=4), DIMENSION(3):: a a(1)=s1; a(2)=s2; a(3)=s3 END FUNCTION END MODULE USE TEST character(len=12) :: line write(line,'(3A4)') s2a_3(a,bb,ccc) IF (line.NE.a bb ccc) CALL ABORT() END -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32140
[Bug fortran/32140] [4.3 Regression] Miscompilation with -O1
--- Comment #25 from pinskia at gcc dot gnu dot org 2007-06-20 14:03 --- Here is a testcase which also checks the resulting array is correct: MODULE TEST CONTAINS PURE FUNCTION s2a_3(s1,s2,s3) RESULT(a) CHARACTER(LEN=*), INTENT(IN) :: s1, s2, s3 CHARACTER(LEN=1000), DIMENSION(3):: a a(1)=s1; a(2)=s2; a(3)=s3 END FUNCTION END MODULE USE TEST character(LEN=80) :: b(3) b=s2a_3(Distribution by marix blocks, Distribution by matrix rows, Distribution by matrix columns) if (b(1) .eq. Distribution by marix blocks) call abort(); if (b(2) .eq. Distribution by matrix rows) call abort(); if (b(3) .eq. Distribution by matrix columns) call abort(); END -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32140
[Bug fortran/32140] [4.3 Regression] Miscompilation with -O1
--- Comment #26 from pinskia at gcc dot gnu dot org 2007-06-20 14:05 --- (In reply to comment #25) Here is a testcase which also checks the resulting array is correct: oh s/eq/ne/ I did not test mine and it is 11pm and I have to get up early in the morning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32140
[Bug fortran/32140] [4.3 Regression] Miscompilation with -O1
--- Comment #27 from rguenther at suse dot de 2007-06-20 14:07 --- Subject: Re: [4.3 Regression] Miscompilation with -O1 On Wed, 20 Jun 2007, jv244 at cam dot ac dot uk wrote: --- Comment #24 from jv244 at cam dot ac dot uk 2007-06-20 14:03 --- (In reply to comment #22) It would be nice if a fortraner could make the testcase not output to stdout/err but to /dev/null instead. open(6,'/dev/null') didn't work for me ;) Just to make a testcase suitable for the testsuite. The following testcase, for an unpatched compiler, aborts at -O1, works fine at -O0, and doesn't write to stdout/stderr... I guess that fits the testsuite ? Yep, I'll use that. Thanks, Richard. MODULE TEST CONTAINS PURE FUNCTION s2a_3(s1,s2,s3) RESULT(a) CHARACTER(LEN=*), INTENT(IN) :: s1, s2, s3 CHARACTER(LEN=4), DIMENSION(3):: a a(1)=s1; a(2)=s2; a(3)=s3 END FUNCTION END MODULE USE TEST character(len=12) :: line write(line,'(3A4)') s2a_3(a,bb,ccc) IF (line.NE.a bb ccc) CALL ABORT() END -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32140
[Bug fortran/32393] gfortran - incorrect run time results
--- Comment #11 from dir at lanl dot gov 2007-06-20 14:15 --- It is easy to make this test case to a completely legal FORTRAN program. Keeping the BUG and making it into a completely legal FORTRAN program is more difficult, but likely possible. However, the problem that gfortran is having with the program is that it does not take the full effect of the equivalence (jt,tt) into account. This is where the real problem is and where I expected some disagreement. Each line of code in the important loop is legal and the loop has compiled and run correctly on dozens of FORTRAN compilers with and without optimization, but one could argue with some justification that the sequence instructions does something illegal. I will consider it RESOLVED INVALID on that basis. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393
[Bug libstdc++/32422] New: Problem reading floats with exponent marker but no exponent
When reading malformed floats like 3.14e using operator, it appears like
the e character is removed from the input stream but the fact that the stream
state does not signal that something went wrong.
$ cat lcast.cpp
#include sstream
#include iostream
using namespace std;
int main()
{
stringstream buf;
buf.str(1e);
float r;
buf r;
cout float== r endl;
cout tellg()== buf.tellg() endl;
cout fail()== buf.fail() endl;
}
$ g++ lcast.cpp./a.out
float==1
tellg()==2
fail()==0
This was noticed in the context of the boost library. There,
boost::lexical_castfloat(1e) silently return 1.0, which is surprising. E.g.
a compiler would reject float x = 1e saying exponent has no digits or
something along these lines.
--
Summary: Problem reading floats with exponent marker but no
exponent
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kreckel at ginac dot de
GCC build triplet: x86_64-suse-linux
GCC host triplet: x86_64-suse-linux
GCC target triplet: x86_64-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32422
[Bug middle-end/32423] New: gcc.c-torture/compile/20020604-1.c ICEs
gcc.c-torture/compile/20020604-1.c ICEs if compiled with
-O3 -fomit-frame-pointer -mcpu=5485.
Here is a reduced testcase min.c.
unsigned int
foo (unsigned int n)
{
float c[8192];
unsigned int i;
unsigned int d = 0;
union {
float r;
unsigned int i;
} e;
for (i = 0; i n; i++)
{
e.r = c[i];
d = e.i;
}
return d;
}
I get:
$ ./cc1 -quiet -O3 -fomit-frame-pointer -mcpu=5485 min.c
min.c: In function 'foo':
min.c:17: error: insn does not satisfy its constraints:
(insn 42 73 43 5 min.c:13 (set (mem/s/c:SF (plus:SI (reg/f:SI 15 %sp)
(reg:SI 2 %d2)) [0 e.r+0 S4 A16])
(mem/s:SF (post_inc:SI (reg:SI 8 %a0 [orig:55 ivtmp.30 ] [55])) [3 c S4
A16])) 46 {movsf_cf_hard} (expr_list:REG_INC (reg:SI 8 %a0 [orig:55 ivtmp.30 ]
[55])
(nil)))
min.c:17: internal compiler error: in reload_cse_simplify_operands, at
postreload.c:396
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
A quick analysis shows that the following appears in min.c.172r.greg.
(insn 42 73 43 5 min.c:13 (set (mem/s/c:SF (plus:SI (reg/f:SI 15 %sp)
(reg:SI 2 %d2)) [0 e.r+0 S4 A16])
(mem/s:SF (post_inc:SI (reg:SI 8 %a0 [orig:55 ivtmp.30 ] [55])) [3 c S4
A16])) 46 {movsf_cf_hard} (expr_list:REG_INC (reg:SI 8 %a0 [orig:55 ivtmp.30 ]
[55])
(nil)))
Notice that SET_SRC has an address of the form SP + D2, which is
invalid on ColdFire.
--
Summary: gcc.c-torture/compile/20020604-1.c ICEs
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kazu at gcc dot gnu dot org
GCC target triplet: m68k-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32423
[Bug target/32424] New: gcc.c-torture/compile/20050303-1.c FAILs
gcc.c-torture/compile/20050303-1.c FAILs like so:
$ ./cc1 -quiet -mcpu=5485 20050303-1.c
20050303-1.c: In function 'crc':
20050303-1.c:10: error: unable to generate reloads for:
(insn 8 7 9 3 20050303-1.c:8 (parallel [
(set (cc0)
(compare (reg:DI 30 [ D.1560 ])
(const_double -1 [0x] 0 [0x0] 0 [0x0] 0 [0x0] 0
[0x0] 0 [0x0])))
(clobber (reg:DI 31))
]) 12 {*m68k.md:302} (expr_list:REG_UNUSED (reg:DI 31)
(nil)))
20050303-1.c:10: internal compiler error: in find_reloads, at reload.c:3733
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
--
Summary: gcc.c-torture/compile/20050303-1.c FAILs
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kazu at gcc dot gnu dot org
GCC target triplet: m68k-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32424
[Bug c++/32425] New: -O breaks executable (/usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found)
Minimal program file hello.cpp:
#include iostream
int main()
{
std::cout hello world\n;
return 0;
}
Compiled as follows:
# /var/scratch/lionelb/usr/gcc-4.2.0/bin/g++ -v -static-libgcc -O hello.cpp
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /var/scratch/lionelb/usr/src/gcc-4.2.0/configure
--prefix=/var/scratch/lionelb/usr/gcc-4.2.0 --enable-languages=c,c++,fortran
--enable-version-specific-runtime-libs
--with-build-time-tools=/var/scratch/lionelb/usr/binutils-2.17/bin
--with-as=/var/scratch/lionelb/usr/binutils-2.17/bin/as
--with-ld=/var/scratch/lionelb/usr/binutils-2.17/bin/ld --enable-__cxa_atexit
Thread model: posix
gcc version 4.2.0
/var/scratch/lionelb/usr/gcc-4.2.0/libexec/gcc/x86_64-unknown-linux-gnu/4.2.0/cc1plus
-quiet -v -D_GNU_SOURCE hello.cpp -quiet -dumpbase hello.cpp -mtune=generic
-auxbase hello -O -version -o /tmp/ccCOiRAs.s
ignoring nonexistent directory
/var/scratch/lionelb/usr/gcc-4.2.0/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/../../../../x86_64-unknown-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/var/scratch/lionelb/usr/gcc-4.2.0/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/include/c++
/var/scratch/lionelb/usr/gcc-4.2.0/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/include/c++/x86_64-unknown-linux-gnu
/var/scratch/lionelb/usr/gcc-4.2.0/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/include/c++/backward
/usr/local/include
/var/scratch/lionelb/usr/gcc-4.2.0/include
/var/scratch/lionelb/usr/gcc-4.2.0/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/include
/usr/include
End of search list.
GNU C++ version 4.2.0 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.2.0.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 2397c1b5728582bf7ba9c1e7650657db
/var/scratch/lionelb/usr/binutils-2.17/bin/as -V -Qy -o /tmp/ccmsgJch.o
/tmp/ccCOiRAs.s
GNU assembler version 2.17 (x86_64-unknown-linux-gnu) using BFD version 2.17
/var/scratch/lionelb/usr/gcc-4.2.0/libexec/gcc/x86_64-unknown-linux-gnu/4.2.0/collect2
--eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2
/usr/lib/../lib64/crt1.o /usr/lib/../lib64/crti.o
/var/scratch/lionelb/usr/gcc-4.2.0/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/crtbegin.o
-L/var/scratch/lionelb/usr/gcc-4.2.0/lib/gcc/x86_64-unknown-linux-gnu/4.2.0
-L/var/scratch/lionelb/usr/gcc-4.2.0/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/../../../../lib64
-L/lib/../lib64 -L/usr/lib/../lib64
-L/var/scratch/lionelb/usr/gcc-4.2.0/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/../../..
/tmp/ccmsgJch.o -lstdc++ -lm -lgcc -lgcc_eh -lc -lgcc -lgcc_eh
/var/scratch/lionelb/usr/gcc-4.2.0/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/crtend.o
/usr/lib/../lib64/crtn.o
Compiles without error (note: the -static-libgcc is to work around a problem
reported in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32415)
Running the executable gives:
# ./a.out
./a.out: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required
by ./a.out)
If compiled *without* the -O flag the program runs normally as expected.
Higher optimization levels cause the same error, but -Os does not.
I cannot reproduce the error with a simpler program.
gcc 4.1.2 configured identically does not exhibit the problem.
I find it puzzling that the error is reported for /usr/lib64/libstdc++.so.6,
since there is a libstdc++.so.6.0.9 (plus appropriate links) in
/var/scratch/lionelb/usr/gcc-4.2.0/lib/gcc/x86_64-unknown-linux-gnu/4.2.0
which appears before /usr/lib64 in the link line.
--
Summary: -O breaks executable (/usr/lib64/libstdc++.so.6: version
`GLIBCXX_3.4.9' not found)
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lionelb dot nospam at gmail dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32425
[Bug middle-end/32362] ICE: in lookup_decl_in_outer_ctx, at omp-low.c:1508
-- 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|NEW |ASSIGNED Last reconfirmed|2007-06-16 07:05:39 |2007-06-20 14:25:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32362
[Bug c++/32425] -O breaks executable (/usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found)
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-20 14:27 --- And this is not a bug, you need to setup LD_LIBRARY_PATH correctly to point to where the latest version of libstdc++ reside which means where --enable-version-specific-runtime-libs puts the library. Note -static-libgcc is wrong here too because of exceptions. -- 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=32425
[Bug target/32426] New: gcc.c-torture/execute/mayalias-2.c FAILs
gcc.c-torture/execute/mayalias-2.c FAILs like so: $ ./cc1 -quiet -O1 -g -mcpu=5485 mayalias-2.c mayalias-2.c:2: internal compiler error: in splice_child_die, at dwarf2out.c:5593 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- Summary: gcc.c-torture/execute/mayalias-2.c FAILs Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kazu at gcc dot gnu dot org GCC target triplet: m68k-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32426
[Bug target/32426] gcc.c-torture/execute/mayalias-2.c FAILs
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-20 14:30 --- *** This bug has been marked as a duplicate of 28834 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32426
[Bug debug/28834] [4.0/4.1/4.2/4.3 Regression] -g crashes sometimes when using may_alias and structs (ICE in splice_child_die)
--- Comment #25 from pinskia at gcc dot gnu dot org 2007-06-20 14:30 --- *** Bug 32426 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||kazu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28834
[Bug target/32427] New: gcc.dg/invalid-call-1.c FAILs
gcc.dg/invalid-call-1.c FAILs like so: $ ./cc1 -quiet -O2 invalid-call-1.c invalid-call-1.c: In function 'foo': invalid-call-1.c:16: warning: function called through a non-compatible type invalid-call-1.c:16: note: if this code is reached, the program will abort invalid-call-1.c:18: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- Summary: gcc.dg/invalid-call-1.c FAILs Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kazu at gcc dot gnu dot org GCC target triplet: m68k-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32427
[Bug rtl-optimization/32427] gcc.dg/invalid-call-1.c FAILs
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-20 14:37 --- This is most likely the scheduler crashing. The code is valid but undefined. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Component|target |rtl-optimization Keywords|ice-on-invalid-code |ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32427
[Bug tree-optimization/32328] 4.2.0: -O2 causes skipped code
--- Comment #6 from tdragon at tdragon dot net 2007-06-20 14:44 --- Created an attachment (id=13743) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13743action=view) Better testcase; compile with -O2, use with alias_main.c Compiling this file with -O2 and linking with the object file from alias_main.c creates a program that demonstrates the miscompilation. Curiously, compiling with -O2 and -fno-strict-aliasing produces a correct compilation. -- tdragon at tdragon dot net changed: What|Removed |Added Attachment #13701|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32328
[Bug tree-optimization/32328] 4.2.0: -O2 causes skipped code
--- Comment #7 from tdragon at tdragon dot net 2007-06-20 14:46 --- Created an attachment (id=13744) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13744action=view) Better testcase pt.2; use with alias1.c Compile this file with any or no additional options as desired; linking with the object file from alias1.c to create a program that demonstrates the miscompilation, if alias1.c was compiled with -O2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32328
[Bug tree-optimization/32328] 4.2.0: -O2 causes skipped code
--- Comment #8 from tdragon at tdragon dot net 2007-06-20 14:52 --- Not seeing any further action or confirmation on this yet, I've gone ahead and created a simpler testcase. It's plain that, when using -O2, line 14 of alias1.c is skipped. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32328
[Bug fortran/32140] [4.3 Regression] Miscompilation with -O1
--- Comment #28 from rguenth at gcc dot gnu dot org 2007-06-20 14:57 --- Subject: Bug 32140 Author: rguenth Date: Wed Jun 20 14:57:10 2007 New Revision: 125886 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125886 Log: 2007-06-20 Andrew Pinski [EMAIL PROTECTED] Richard Guenther [EMAIL PROTECTED] PR fortran/32140 * trans.c (gfc_build_addr_expr): Use the correct types. * gfortran.fortran-torture/execute/pr32140.f90: New testcase. Added: trunk/gcc/testsuite/gfortran.fortran-torture/execute/pr32140.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32140
[Bug fortran/32140] [4.3 Regression] Miscompilation with -O1
--- Comment #29 from rguenth at gcc dot gnu dot org 2007-06-20 14:59 --- Fixe.d -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32140
[Bug c++/32425] -O breaks executable (/usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found)
--- Comment #2 from lionelb dot nospam at gmail dot com 2007-06-20 15:01 --- (In reply to comment #1) And this is not a bug, you need to setup LD_LIBRARY_PATH correctly to point to where the latest version of libstdc++ reside which means where --enable-version-specific-runtime-libs puts the library. I see; that does solve the problem (as does using -Wl,-rpath ... maybe not recommended). Odd that I only hit that with the -O (and not with 4.1.2 at all). I guess that was just lucky. Note -static-libgcc is wrong here too because of exceptions. As mentioned in the report, please see: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32415 I may have a workaround for this now. BTW what are the implications for exceptions of linking with -static-libgcc? Cheers, Lionel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32425
[Bug translation/32428] New: odd french translation of strict aliasing -related warnings
French translations for strict aliasing -related warnings are a bit odd, here is a patch. -- Summary: odd french translation of strict aliasing -related warnings Product: gcc Version: 4.1.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: translation AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: samuel dot thibault at ens-lyon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32428
[Bug translation/32428] odd french translation of strict aliasing -related warnings
--- Comment #1 from samuel dot thibault at ens-lyon dot org 2007-06-20 15:09 --- Created an attachment (id=13745) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13745action=view) better translations for strict aliasing -related warnings -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32428
[Bug tree-optimization/32328] [4.2 Regression] -fstrict-aliasing causes skipped code
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-06-20 15:12 ---
Confirmed.
struct barstruct { char const* some_string; };
void changethepointer(struct barstruct**);
void baz()
{
struct barstruct bar1;
struct barstruct* barptr = bar1;
changethepointer(barptr);
barptr-some_string = Everything's OK!;
}
We end up with
baz ()
{
struct barstruct * barptr;
struct barstruct bar1;
struct barstruct * barptr.0;
bb 2:
# barptr_2 = V_MUST_DEF barptr_1;
barptr = bar1;
# barptr_6 = V_MAY_DEF barptr_2;
# SFT.1_7 = V_MAY_DEF SFT.1_4;
# NONLOCAL.7_8 = V_MAY_DEF NONLOCAL.7_5;
changethepointer (barptr);
# VUSE barptr_6;
barptr.0_3 = barptr;
# SFT.1_9 = V_MAY_DEF SFT.1_7;
barptr.0_3-some_string = Everything\'s OK![0];
return;
}
because of a wrong points-to set again:
barptr.0_3 = { bar1 }
The constraints are
Constraints:
ANYTHING = ANYTHING
READONLY = ANYTHING
INTEGER = ANYTHING
ESCAPED_VARS = *ESCAPED_VARS
NONLOCAL.7 = ESCAPED_VARS
ESCAPED_VARS = NONLOCAL.7
ESCAPED_VARS = NONLOCAL.7
barptr = bar1
ESCAPED_VARS = bar1
ESCAPED_VARS = barptr
barptr.0_3 = barptr
where ESCAPED_VARS = barptr looks wrong? I'd say it needs to be
ESCAPED_VARS = barptr instead.
Danny?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||dberlin at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2007-06-20 15:12:52
date||
Summary|4.2.0: -O2 causes skipped |[4.2 Regression] -fstrict-
|code|aliasing causes skipped code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32328
[Bug translation/32428] odd french translation of strict aliasing -related warnings
--- Comment #2 from samuel dot thibault at ens-lyon dot org 2007-06-20 15:15 --- Created an attachment (id=13746) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13746action=view) yet better translation Sorry for reposting a patch so soon, but someone told me enfreindre is better for rules. -- samuel dot thibault at ens-lyon dot org changed: What|Removed |Added Attachment #13745|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32428
[Bug tree-optimization/32328] [4.2/4.3 Regression] -fstrict-aliasing causes skipped code
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-06-20 15:16
---
trunk has the same problem, but different constraints:
Constraints:
ANYTHING = ANYTHING
READONLY = ANYTHING
INTEGER = ANYTHING
barptr = bar1
barptr.0_1 = barptr
Points-to sets
NULL = { }
ANYTHING = { ANYTHING }
READONLY = { ANYTHING }
INTEGER = { ANYTHING }
barptr = { bar1 }
bar1 = { }
barptr.0_1 = same as barptr
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to work||4.1.2
Summary|[4.2 Regression] -fstrict- |[4.2/4.3 Regression] -
|aliasing causes skipped code|fstrict-aliasing causes
||skipped code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32328
[Bug middle-end/32429] New: [PPC, missing optimization] stack space not optimized when stack not used
A variety of options prepare some additional space on the stack. It isn't optimized when stack isn't used. Those options are: version options 3.3 -fpic -fPIC -mabi=altivec 4.1.2 -fpic -fPIC -fpie -fPIE -maltivec 4.2.0 -fpic -fPIC -fpie -fPIE -maltivec 4.3-pre -fpic -fPIC -fpie -fPIE problem with -maltivec has been partially fixed in 4.3 (see bug 32401) $ gcc-3.3 --version gcc-3.3 (GCC) 3.3.6 (Debian 1:3.3.6-15) $ gcc-3.3 -S -O2 empty.c grep -A3 empty: empty.s empty: blr .size empty, .-empty .section.note.GNU-stack,,@progbits $ gcc-3.3 -S -O2 -fpic empty.c grep -A3 empty: empty.s empty: stwu 1,-32(1) addi 1,1,32 blr $ gcc-3.3 -S -O2 -fPIC empty.c grep -A3 empty: empty.s empty: stwu 1,-32(1) addi 1,1,32 blr $ gcc-3.3 -S -O2 -maltivec empty.c grep -A3 empty: empty.s empty: blr .size empty, .-empty .section.note.GNU-stack,,@progbits $ gcc-3.3 -S -O2 -maltivec -mabi=altivec empty.c grep -A3 empty: empty.s empty: stwu 1,-16(1) addi 1,1,16 blr $ gcc-3.3 -S -O2 -fpic -maltivec -mabi=altivec empty.c grep -A3 empty: empty.s empty: stwu 1,-32(1) addi 1,1,32 blr $ gcc-3.3 -S -O2 -fPIC -maltivec -mabi=altivec empty.c grep -A3 empty: empty.s empty: stwu 1,-32(1) addi 1,1,32 blr $ gcc --version gcc (GCC) 4.1.2 (PLD-Linux) $ gcc -S -O2 empty.c grep -A3 empty: empty.s empty: blr .size empty, .-empty .ident GCC: (GNU) 4.1.2 (PLD-Linux) $ gcc -S -O2 -fpic empty.c grep -A3 empty: empty.s empty: stwu 1,-16(1) addi 1,1,16 blr $ gcc -S -O2 -fPIC empty.c grep -A3 empty: empty.s empty: stwu 1,-16(1) addi 1,1,16 blr $ gcc -S -O2 -fpie empty.c grep -A3 empty: empty.s empty: stwu 1,-16(1) addi 1,1,16 blr $ gcc -S -O2 -fPIE empty.c grep -A3 empty: empty.s empty: stwu 1,-16(1) addi 1,1,16 blr $ gcc -S -O2 -maltivec empty.c grep -A3 empty: empty.s empty: stwu 1,-16(1) addi 1,1,16 blr $ gcc -S -O2 -maltivec -mabi=altivec empty.c grep -A3 empty: empty.s empty: stwu 1,-16(1) addi 1,1,16 blr $ gcc -S -O2 -fpic -maltivec -mabi=altivec empty.c grep -A3 empty: empty.s empty: stwu 1,-32(1) addi 1,1,32 blr $ gcc -S -O2 -fpie -maltivec -mabi=altivec empty.c grep -A3 empty: empty.s empty: stwu 1,-32(1) addi 1,1,32 blr $ gcc-4.3 --version gcc-4.3 (GCC) 4.3.0 20070615 (experimental) $ gcc-4.3 -S -O2 empty.c grep -A3 empty: empty.s empty: blr .size empty, .-empty .ident GCC: (GNU) 4.3.0 20070615 (experimental) $ gcc-4.3 -S -O2 -fpic empty.c grep -A3 empty: empty.s empty: stwu 1,-16(1) addi 1,1,16 blr $ gcc-4.3 -S -O2 -fPIC empty.c grep -A3 empty: empty.s empty: stwu 1,-16(1) addi 1,1,16 blr $ gcc-4.3 -S -O2 -fpie empty.c grep -A3 empty: empty.s empty: stwu 1,-16(1) addi 1,1,16 blr $ gcc-4.3 -S -O2 -fPIE empty.c grep -A3 empty: empty.s empty: stwu 1,-16(1) addi 1,1,16 blr $ gcc-4.3 -S -O2 -maltivec empty.c grep -A3 empty: empty.s empty: blr .size empty, .-empty .ident GCC: (GNU) 4.3.0 20070615 (experimental) $ gcc-4.3 -S -O2 -maltivec -mabi=altivec empty.c grep -A3 empty: empty.s empty: blr .size empty, .-empty .ident GCC: (GNU) 4.3.0 20070615 (experimental) $ gcc-4.3 -S -O2 -fpic -maltivec -mabi=altivec empty.c grep -A3 empty: empty.s empty: stwu 1,-32(1) addi 1,1,32 blr $ gcc-4.3 -S -O2 -fPIC -maltivec -mabi=altivec empty.c grep -A3 empty: empty.s empty: stwu 1,-32(1) addi 1,1,32 blr $ gcc-4.3 -S -O2 -fpie -maltivec -mabi=altivec empty.c grep -A3 empty: empty.s empty: stwu 1,-32(1) addi 1,1,32 blr $ gcc-4.3 -S -O2 -fPIE -maltivec -mabi=altivec empty.c grep -A3 empty: empty.s empty: stwu 1,-32(1) addi 1,1,32 blr -- Summary: [PPC, missing optimization] stack space not optimized when stack not used Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sparky at pld-linux dot org GCC target triplet: powerpc-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32429
[Bug fortran/31683] bogus warnings with optional arguments
--- Comment #8 from jv244 at cam dot ac dot uk 2007-06-20 15:20 --- this really seems a duplicate of PR 31688, so I'll close this PR and reopen 31688. If one wants to get the error message mentioned in comment #6, I suggest to open a new PR. *** This bug has been marked as a duplicate of 31688 *** -- jv244 at cam dot ac dot uk changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31683
[Bug middle-end/31688] Bogus may be used uninitialized warning
--- Comment #2 from jv244 at cam dot ac dot uk 2007-06-20 15:20 --- *** Bug 31683 has been marked as a duplicate of this bug. *** -- jv244 at cam dot ac dot uk changed: What|Removed |Added CC||jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31688
[Bug middle-end/31688] Bogus may be used uninitialized warning
--- Comment #3 from jv244 at cam dot ac dot uk 2007-06-20 15:25 --- Tobias, could you reopen this bug (I can't). This is different from PR 5035. Whereas PR 5035 warns about variables present in the users code, these warnings come from frontend generated variables (i.e. offset.7 is nowhere present in the users code). These warnings are thus needlessly confusing and supposedly can be easily supressed by giving them proper attributes in the fronted. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31688
[Bug c/32415] libgcc_s not found in library search path with --enable-version-specific-runtime-libs
--- Comment #1 from lionelb dot nospam at gmail dot com 2007-06-20 15:31 --- (In reply to comment #0) I can work around this by symlinking: to ../lib64/libgcc_s.so from /var/scratch/lionelb/usr/gcc-4.1.2/lib/gcc/x86_64-unknown-linux-gnu/4.1.2 and: to ../../lib/libgcc_s.so from /var/scratch/lionelb/usr/gcc-4.1.2/lib/gcc/x86_64-unknown-linux-gnu/4.1.2/32 Is this advisable? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32415
[Bug tree-optimization/32328] [4.2/4.3 Regression] -fstrict-aliasing causes skipped code
--- Comment #11 from tdragon at tdragon dot net 2007-06-20 15:35 --- Not sure if this is relevant or just GCC working differently on my target system, but I don't encounter the bug using -fstrict-aliasing, or in fact using individually the entire set of options under -O and -O2 on http://gcc.gnu.org/onlinedocs/gcc-4.2.0/gcc/Optimize-Options.html -- only when I specifically use the option -O2. i.e. gcc -fstrict-aliasing -c alias1.c DOESN'T, for me, cause the bug but gcc -O2 -c alias1.c DOES. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32328
[Bug fortran/32393] gfortran - incorrect run time results
--- Comment #12 from dominiq at lps dot ens dot fr 2007-06-20 15:43 --- With the following changes to the original code: [karma] f90/bug% diff -u pr32393.f pr32393_mod.f --- pr32393.f Mon Jun 18 16:46:48 2007 +++ pr32393_mod.f Wed Jun 20 17:40:03 2007 @@ -16,7 +16,7 @@ c+-+ character its1*4 character title*72 - integert +! integert real cc, ctrans, dprod2, sdb, sdm, $ stdb, stdm, sum, ttt, uf, $ vf, wsf @@ -99,6 +99,7 @@ c| skip second variation if cc matrix = 0 | c+-+ call scprod (ns*ns,1,1,cc,cc,sum) + sum = 0 if (sum.le.0.)go to 180 c+-+ c| choose appropriate computational routine| @@ -182,8 +183,10 @@ not=6 nvg=3 iprec = 1 - call vr2 ( intp, ivg, ccrans, cc, ns, stdb, stdm, t, - $ k2, nlin, istab ) +! call vr2 ( intp, ivg, ccrans, cc, ns, stdb, stdm, t, +! $ k2, nlin, istab ) + call vr2 ( 0, ivg, ccrans, cc, ns, stdb, stdm, t, + $ 0, 0, 0 ) stop end subroutine clect2 I get with gfortran: [karma] f90/bug% gfc -g -O3 pr32393_mod.f [karma] f90/bug% a.out 1 lower triangular matrix with 3 rows row 10.8000E+01 row 20.9000E+01 0.1000E+02 row 30.1100E+02 0.1200E+02 0.1300E+02 iprec = 1 1 lower triangular matrix with 3 rows row 10.1600E+02 row 20.9000E+01 0.2000E+02 row 30.1100E+02 0.1200E+02 0.2600E+02 [karma] f90/bug% gfc -g -O1 pr32393_mod.f [karma] f90/bug% a.out 1 lower triangular matrix with 3 rows row 10.8000E+01 row 20.9000E+01 0.1000E+02 row 30.1100E+02 0.1200E+02 0.1300E+02 iprec = 1 1 lower triangular matrix with 3 rows row 10.1600E+02 row 20.9000E+01 0.2000E+02 row 30.1100E+02 0.1200E+02 0.2600E+02 [karma] f90/bug% gfc -g -O1 -ffast-math -funroll-loops pr32393_mod.f [karma] f90/bug% a.out 1 lower triangular matrix with 3 rows row 10.8000E+01 row 20.9000E+01 0.1000E+02 row 30.1100E+02 0.1200E+02 0.1300E+02 iprec = 1 1 lower triangular matrix with 3 rows row 10.1600E+02 row 20.9000E+01 0.2000E+02 row 30.1100E+02 0.1200E+02 0.2600E+02 [karma] f90/bug% gfc -g pr32393_mod.f [karma] f90/bug% a.out 1 lower triangular matrix with 3 rows row 10.8000E+01 row 20.9000E+01 0.1000E+02 row 30.1100E+02 0.1200E+02 0.1300E+02 iprec = 1 1 lower triangular matrix with 3 rows row 10.1600E+02 row 20.9000E+01 0.2000E+02 row 30.1100E+02 0.1200E+02 0.2600E+02 Note that I have only given some values to variables used in tests (plus set t to real). BTW I do not see (beside obfuscation) the interest of the constructs: jt=t(j2) tt=.5*tt t(j2)=jt where jt and tt are equivalenced! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393
[Bug libstdc++/32422] Problem reading floats with exponent marker but no exponent
--- Comment #1 from pcarlini at suse dot de 2007-06-20 15:53 --- This is a known behavior (we even have testcases for it): the issue is that (for C++03 at least) we definitely want consistency with C scanf, and the latter in many implementations behaves incorrectly. See this glibc PR of mine: http://sources.redhat.com/bugzilla/show_bug.cgi?id=1765 We can reconsider the issue in the C++0x context, not earlier than that. -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-06-20 15:53:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32422
[Bug libstdc++/32422] Problem reading floats with exponent marker but no exponent
-- pcarlini at suse dot de changed: What|Removed |Added Status|NEW |SUSPENDED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32422
[Bug fortran/32393] gfortran - incorrect run time results
--- Comment #13 from burnus at gcc dot gnu dot org 2007-06-20 16:20 --- However, the problem that gfortran is having with the program is that it does not take the full effect of the equivalence (jt,tt) into account. This is where the real problem is and where I expected some disagreement. I would not be surprised if some bug is lurking there, but my problem is that if the program is invalid and produces different results with different compilers, it is a bit difficult to pinpoint the problem. What is actually the expected result? Depending on the compiler and compiler setting, I get completely different results for the second triangular matrix. (The first matrix remains always the same.) NAG f95 -dusty refuses to compile the program. gfortran with -O0 to -O3, sunf95 (default settings), g95 (-O0) and Intel's ifort (-O1) give: row 10.1600E+02 row 20.9000E+01 0.2000E+02 row 30.1100E+02 0.1200E+02 0.2600E+02 ifort -O2 (= ifort w/ default settings) and gfortran -O3 -ffast-math give: row 10.E+00 row 20.9000E+01 0.E+00 row 30.1100E+02 0.1200E+02 0.E+00 g95 -O2 gives: row 10.8000E+01 row 20.9000E+01 0.1000E+02 row 30.1100E+02 0.1200E+02 0.1300E+02 Thus which compiler is right? Are all right? What exactly is the bug / expected output? Is it fixed meanwhile as I get for -O3 w/o -ffast-math the same output as for -O0? Is it platform dependent? I use 4.3.0 20070620 (x86_64-unknown-linux-gnu) and the unmodified version (or equivalently the version as modified by Dominique). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393
[Bug middle-end/32399] [4.3 Regression] ICE in build2_stat, at tree.c:3074
--- Comment #5 from marcus at jet dot franken dot de 2007-06-20 16:21 --- i have tested it and it works. (i have also fixed the Wine code ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32399
[Bug fortran/32365] OpenMP: Better error message for specification statement in executable section
--- Comment #1 from jakub at gcc dot gnu dot org 2007-06-20 16:23 --- There is nothing special about ST_OMP_THREADPRIVATE here, the Fortran parser as whole behaves this way. You get the same if you write say subroutine test integer :: i i = 1 common /myi/ i end subroutine test etc. Handling just ST_OMP_THREADPRIVATE specially would be IMHO a mistake, what perhaps could be done is e.g. adding something like case_decl: gfc_error (%s statement can't appear after the first executable statement at %C, gfc_ascii_statement (st)); reject_statement (); break; into parse_executable before default: return st; in there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32365
[Bug fortran/31688] Bogus may be used uninitialized warning
--- Comment #4 from burnus at gcc dot gnu dot org 2007-06-20 16:25 --- Tobias, could you reopen this bug (I can't). This is different from PR 5035. Whereas PR 5035 warns about variables present in the users code, these warnings come from frontend generated variables Well, for the middle end it is all the same. These warnings are thus needlessly confusing and supposedly can be easily supressed by giving them proper attributes in the fronted. I don't know how one should properly handle these in the front end (without unneeded initialization of variables), but I reopened the bug and moved it to the Fortran front end. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Component|middle-end |fortran Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31688
