[Bug c/39903] ICE in tmpdir-gcc.dg-struct-layout-1/t026 c_compat_(x,y)_tst.o compile at -m64
--- Comment #6 from ubizjak at gmail dot com 2009-04-26 07:20 ---
Confirmed on x86_64-linux, reduced testcase:
--cut here--
struct S2456
{
double a;
struct {} b[];
};
struct S2456 s2456;
extern void check2456va (struct S2456);
void test2456 (void)
{
check2456va (s2456);
}
--cut here--
gcc t.c
t.c: In function test2456:
t.c:13: note: The ABI of passing struct with a flexible array member has
changed in GCC 4.4
t.c:13: internal compiler error: in emit_move_insn, at expr.c:3386
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-04-26 07:20:29
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39903
[Bug c++/39906] New: Accepted invalid member template specialization in derived class
struct Base
{
template
struct Kind
{
typedef T type;
};
};
struct Derived : public Base { };
template <>
struct Derived::Kind // Should fail to compile here
{
typedef int type;
};
int main(void) { }
I believe the above code should be rejected but gcc 4.1.2 accepted it. Global
scope explicit member template specialization of the inner struct Kind is shown
to be in the Derived class. (It is rejected by Comeau). gcc correctly rejects
in the case of member template functions but not in case of structs/classes.
Compiler information:
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --with-cpu=generic
--host=i386-redhat-linux
Thread model: posix
gcc version 4.1.2 20070925 (Red Hat 4.1.2-33)
--
Summary: Accepted invalid member template specialization in
derived class
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sutambe at yahoo dot com
GCC build triplet: i386-redhat-linux
GCC host triplet: i386-redhat-linux
GCC target triplet: i386-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39906
[Bug target/32107] bad codegen for vector initialization in Altivec
--- Comment #5 from eres at il dot ibm dot com 2009-04-26 07:29 --- (In reply to comment #2) > Mine. The patches which I have from the PS3 toolchain fixes this one, it is > related to PR 32110 also. I see this problem still exits on trunk -r146794. If you still have the patch I will be happy to test it. -- eres at il dot ibm dot com changed: What|Removed |Added CC||eres at il dot ibm dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32107
[Bug testsuite/39710] gcc.misc-tests/help.exp doesn't work when configured with --enable-checking=assert
--- Comment #2 from rwild at gcc dot gnu dot org 2009-04-26 08:19 --- Subject: Bug 39710 Author: rwild Date: Sun Apr 26 08:18:48 2009 New Revision: 146795 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146795 Log: gcc/ PR testsuite/39710 * opts.c (undocumented_msg): Do not leave blank even with ENABLE_CHECKING. Modified: trunk/gcc/ChangeLog trunk/gcc/opts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39710
[Bug testsuite/39710] gcc.misc-tests/help.exp doesn't work when configured with --enable-checking=assert
--- Comment #3 from rwild at gcc dot gnu dot org 2009-04-26 08:20 --- Fixed. -- rwild at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39710
The best HYIP Started
http://fxtradefund.com/ http://www.etoro-investor.com/
The best HYIP Started
http://fxtradefund.com/ http://www.etoro-investor.com/
The best HYIP Started
http://fxtradefund.com/ http://www.etoro-investor.com/
The best HYIP Started
http://fxtradefund.com/ http://www.etoro-investor.com/
The best HYIP Started
http://fxtradefund.com/ http://www.etoro-investor.com/
The best HYIP Started
http://fxtradefund.com/ http://www.etoro-investor.com/
[Bug tree-optimization/39907] New: Aligned access to unaligned address
The following code (a reduced gcc.target/x86_64/abi/test_struct_returning.c)
fails during execution with segmentation fault when compiled with -O1
-ftree-vectorize -fno-vect-cost-model asm-support.S (in directory
gcc.target/x86_64/abi/):
#include
#include "defines.h"
#include "macros.h"
#include "args.h"
struct S_600
{
float f[4];
};
struct S_600 f_600 ()
{
struct S_600 s;
int i;
for (i = 0; i < 4; i++)
s.f[i] = 42;
return s;
}
int
main (void)
{
struct S_600 s;
s = WRAP_RET(f_600) ();
return 0;
}
The failure occurs in
0x0040063b in f_600 ()
1: x/i $pc 0x40063b : movaps %xmm0,0xffd8(%rsp)
(gdb)
Program received signal SIGSEGV, Segmentation fault.
0x0040063b in f_600 ()
1: x/i $pc 0x40063b : movaps %xmm0,0xffd8(%rsp)
rsp0x7fff408944c0 0x7fff408944c0
xmm0 {v4_float = {0x2a, 0x2a, 0x2a, 0x2a}, v2_double = {0xc2114,
0xc2114}, v16_int8 = {0x0, 0x0, 0x28,
0x42, 0x0, 0x0, 0x28, 0x42, 0x0, 0x0, 0x28, 0x42, 0x0, 0x0, 0x28, 0x42},
v8_int16 = {0x0, 0x4228, 0x0, 0x4228, 0x0,
0x4228, 0x0, 0x4228}, v4_int32 = {0x4228, 0x4228, 0x4228,
0x4228}, v2_int64 = {0x42284228,
0x42284228}, uint128 = 0x4228422842284228}
The alignment is forced by the vectorizer in function
vect_compute_data_ref_alignment() the same way as in pass
pass_ipa_increase_alignment. But if 's' is global and not local in f_600 (i.e.,
when the alignment is forced in pass_ipa_increase_alignment) there is no
segfault.
I also tried to remove WRAP_RET(), and put f_600 and main in different files
(in order to prevent their elimination). But this way there was no segfault
either.
Another check: if the vectorizer forces alignment but also uses peeling (with
the help of a hack), there is still a segfault:
0x0040065f in f_600 ()
1: x/i $pc 0x40065f :movaps 362(%rip),%xmm0#
0x4007d0 <_IO_stdin_used+16>
(gdb)
1: x/i $pc 0x400666 :movaps %xmm0,(%rdx)
(gdb)
Program received signal SIGSEGV, Segmentation fault.
0x00400666 in f_600 ()
1: x/i $pc 0x400666 :movaps %xmm0,(%rdx)
(gdb) info all-registers
rdx0x7fff2a759358 140733905736536
rip0x400666 0x400666
If after forcing the alignment, the vectorizer escapes and doesn't do anything
else, there is no segfault.
--
Summary: Aligned access to unaligned address
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: irar at il dot ibm dot com
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=39907
[Bug tree-optimization/39908] New: Aligned access to unaligned address
The following code (a reduced gcc.target/x86_64/abi/test_struct_returning.c)
fails during execution with segmentation fault when compiled with -O1
-ftree-vectorize -fno-vect-cost-model asm-support.S (in directory
gcc.target/x86_64/abi/):
#include
#include "defines.h"
#include "macros.h"
#include "args.h"
struct S_600
{
float f[4];
};
struct S_600 f_600 ()
{
struct S_600 s;
int i;
for (i = 0; i < 4; i++)
s.f[i] = 42;
return s;
}
int
main (void)
{
struct S_600 s;
s = WRAP_RET(f_600) ();
return 0;
}
The failure occurs in
0x0040063b in f_600 ()
1: x/i $pc 0x40063b : movaps %xmm0,0xffd8(%rsp)
(gdb)
Program received signal SIGSEGV, Segmentation fault.
0x0040063b in f_600 ()
1: x/i $pc 0x40063b : movaps %xmm0,0xffd8(%rsp)
rsp0x7fff408944c0 0x7fff408944c0
xmm0 {v4_float = {0x2a, 0x2a, 0x2a, 0x2a}, v2_double = {0xc2114,
0xc2114}, v16_int8 = {0x0, 0x0, 0x28,
0x42, 0x0, 0x0, 0x28, 0x42, 0x0, 0x0, 0x28, 0x42, 0x0, 0x0, 0x28, 0x42},
v8_int16 = {0x0, 0x4228, 0x0, 0x4228, 0x0,
0x4228, 0x0, 0x4228}, v4_int32 = {0x4228, 0x4228, 0x4228,
0x4228}, v2_int64 = {0x42284228,
0x42284228}, uint128 = 0x4228422842284228}
The alignment is forced by the vectorizer in function
vect_compute_data_ref_alignment() the same way as in pass
pass_ipa_increase_alignment. But if 's' is global and not local in f_600 (i.e.,
when the alignment is forced in pass_ipa_increase_alignment) there is no
segfault.
I also tried to remove WRAP_RET(), and put f_600 and main in different files
(in order to prevent their elimination). But this way there was no segfault
either.
Another check: if the vectorizer forces alignment but also uses peeling (with
the help of a hack), there is still a segfault:
0x0040065f in f_600 ()
1: x/i $pc 0x40065f :movaps 362(%rip),%xmm0#
0x4007d0 <_IO_stdin_used+16>
(gdb)
1: x/i $pc 0x400666 :movaps %xmm0,(%rdx)
(gdb)
Program received signal SIGSEGV, Segmentation fault.
0x00400666 in f_600 ()
1: x/i $pc 0x400666 :movaps %xmm0,(%rdx)
(gdb) info all-registers
rdx0x7fff2a759358 140733905736536
rip0x400666 0x400666
If after forcing the alignment, the vectorizer escapes and doesn't do anything
else, there is no segfault.
--
Summary: Aligned access to unaligned address
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: irar at il dot ibm dot com
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=39908
[Bug c/39556] statics in C99 inline functions later declared extern
--- Comment #1 from jsm28 at gcc dot gnu dot org 2009-04-26 13:40 --- Subject: Bug 39556 Author: jsm28 Date: Sun Apr 26 13:40:19 2009 New Revision: 146800 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146800 Log: PR c/39556 * c-tree.h (enum c_inline_static_type): New. (record_inline_static): Declare. * c-decl.c (struct c_inline_static, c_inline_statics, record_inline_static, check_inline_statics): New. (pop_file_scope): Call check_inline_statics. (start_decl): Call record_inline_static instead of pedwarning directly for static in inline function. * c-typeck.c (build_external_ref): Call record_inline_static instead of pedwarning directly for static referenced in inline function. testsuite: * gcc.dg/inline-34.c: New test. Added: trunk/gcc/testsuite/gcc.dg/inline-34.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-decl.c trunk/gcc/c-tree.h trunk/gcc/c-typeck.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39556
[Bug c/39556] statics in C99 inline functions later declared extern
--- Comment #2 from jsm28 at gcc dot gnu dot org 2009-04-26 13:41 --- Fixed for 4.5. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.5.0 Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39556
[Bug libstdc++/39909] New: non-TLS version of std::call_once causes terminate
I'm entering this bug to track:
http://gcc.gnu.org/ml/libstdc++/2009-04/msg9.html
The following program fails using gcc configured --disable-tls
#include
#include
#include
std::once_flag flag;
int value = 0;
struct Inc { void operator()() const { ++value; } };
struct Func
{
void operator()() const
{
Inc inc;
for (int i = 0; i < 1; ++i)
std::call_once(flag, inc);
}
};
int main()
{
Func f;
std::thread t1(f);
std::thread t2(f);
std::thread t3(f);
t1.join();
t2.join();
t3.join();
assert( value == 1 );
return 0;
}
Multiple threads try to call unique_lock::lock() on the same object
simultaneously, after the first one acquires the lock the subsequent threads
will fail due to this check in unique_lock::lock()
else if (_M_owns)
__throw_system_error(int(errc::resource_deadlock_would_occur));
The unhandled exceptions terminate the program.
The obvious fix is to stop using a single, global lock object shared between
all threads, and use a different lock object in each thread's stack, sharing a
global mutex. Concurrent operations on a single mutex are safe, but not on a
single lock.
That fix requires an ABI change, since __get_once_functor_lock is exported. An
alternative would be to replicate the code used when TLS is available, but
using pthread_getspecific / pthread_setspecific instead.
--
Summary: non-TLS version of std::call_once causes terminate
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jwakely dot gcc at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39909
[Bug libstdc++/39909] non-TLS version of std::call_once causes terminate
--- Comment #1 from paolo dot carlini at oracle dot com 2009-04-26 14:28 --- Just in case Chris wants to help with this. -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||cfairles at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39909
[Bug target/39910] New: [4.5 regression] i386: Error: suffix or operands invalid for `fidivr'
Building Wine started to fail on i386-unknown-freebsd7.1 with the
following failure mode:
...gcc -c -I. -I. -I../../include -I../../include
-D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing
-Wdeclaration-after-statement -Wwrite-strings -Wtype-limits -Wpointer-arith
-I/usr/local/include -g -O2 -o graphics.o graphics.c
{standard input}: Assembler messages:
{standard input}:7118: Error: suffix or operands invalid for `fidivr'
{standard input}:7123: Error: suffix or operands invalid for `fidivr'
gmake[2]: *** [graphics.o] Error 1
gmake[2]: Leaving directory `/usr/test/Wine/dlls/gdiplus'
gmake[1]: *** [gdiplus] Error 2
gmake[1]: Leaving directory `/usr/test/Wine/dlls'
gmake: *** [dlls] Error 2
The assembly code in question is:
.loc 1 1023 0
movl(%esi), %eax
movl16(%ebp), %edx
filds 14(%edx)
fidivrw 6(%edx) <-- here
fstps 12(%eax)
.loc 1 1024 0
movl(%esi), %eax
filds 14(%edx)
fidivrw 10(%edx)<-- here
fstps 16(%eax)
.loc 1 1025 0
Sadly, FreeBSD still uses gas 2.15; still, this is a regression.
--
Summary: [4.5 regression] i386: Error: suffix or operands invalid
for `fidivr'
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gerald at pfeifer dot com
GCC host triplet: i386-unknown-freebsd7.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39910
[Bug target/39910] [4.5 regression] i386: Error: suffix or operands invalid for `fidivr'
--- Comment #1 from gerald at pfeifer dot com 2009-04-26 14:58 --- Created an attachment (id=17698) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17698&action=view) Preprocessed source file (created using -save-temps) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39910
[Bug target/39910] [4.5 regression] i386: Error: suffix or operands invalid for `fidivr'
--- Comment #2 from gerald at pfeifer dot com 2009-04-26 14:59 --- Created an attachment (id=17699) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17699&action=view) Assembly file (created using -save-temps) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39910
[Bug target/35936] Cannot compile libgcc.S on avr
--- Comment #2 from laci at monda dot hu 2009-04-26 15:15 --- Same bug for me. I've compiled gcc using ../configure --target=avr --program-prefix="avr-" --enable-languages=c /home/laci/download/gcc-4.4.0/avr-gcc/./gcc/xgcc -B/home/laci/download/gcc-4.4.0/avr-gcc/./gcc/ -B/usr/local/avr/bin/ -B/usr/local/avr/lib/ -isystem /usr/local/avr/include -isystem /usr/local/avr/sys-include -g -O2 -mmcu=avr31 -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -isystem ./include -DDF=SF -Dinhibit_libc -mcall-prologues -Os -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../.././gcc -I../../../../libgcc -I../../../../libgcc/. -I../../../../libgcc/../gcc -I../../../../libgcc/../include -DHAVE_CC_TLS -o _tablejump_elpm.o -MT _tablejump_elpm.o -MD -MP -MF _tablejump_elpm.dep -DL_tablejump_elpm -xassembler-with-cpp \ -c ../../../../libgcc/../gcc/config/avr/libgcc.S ../../../../libgcc/../gcc/config/avr/libgcc.S: Assembler messages: ../../../../libgcc/../gcc/config/avr/libgcc.S:886: Error: illegal opcode elpm for mcu avr3 ../../../../libgcc/../gcc/config/avr/libgcc.S:889: Error: illegal opcode elpm for mcu avr3 -- laci at monda dot hu changed: What|Removed |Added CC||laci at monda dot hu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35936
[Bug target/39897] [4.5 Regression] Revision 146761 caused libgomp.fortran/omp_atomic1.f90
--- Comment #3 from hjl dot tools at gmail dot com 2009-04-26 15:37 --- *** Bug 39910 has been marked as a duplicate of this bug. *** -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||gerald at pfeifer dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39897
[Bug target/39910] [4.5 regression] i386: Error: suffix or operands invalid for `fidivr'
--- Comment #3 from hjl dot tools at gmail dot com 2009-04-26 15:37 --- *** This bug has been marked as a duplicate of 39897 *** -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39910
[Bug target/39910] [4.5 regression] i386: Error: suffix or operands invalid for `fidivr'
--- Comment #4 from gerald at pfeifer dot com 2009-04-26 15:39 --- Created an attachment (id=17700) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17700&action=view) Second preprocessed source file (created using -save-temps) And I'm seeing similiar errors for a different file, this time for fiadd and fisub. vartype.c: Assembler messages: vartype.c:13174: Error: suffix or operands invalid for `fiadd' vartype.c:13208: Error: suffix or operands invalid for `fisub' vartype.c:13716: Error: suffix or operands invalid for `fiadd' vartype.c:13757: Error: suffix or operands invalid for `fisub' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39910
[Bug target/39910] [4.5 regression] i386: Error: suffix or operands invalid for `fidivr'
--- Comment #5 from gerald at pfeifer dot com 2009-04-26 15:40 --- Created an attachment (id=17701) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17701&action=view) Second assembly file (created using -save-temps) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39910
[Bug target/39911] New: The 'z' suffix doesn't work with 16bit integer insn
[...@gnu-34 gcc]$ cat /tmp/x.c
void bar1()
{
char foo;
asm volatile ("mov%z0 %1, %0": "+m" (foo): "ir" (23));
}
void bar2()
{
short foo;
asm volatile ("mov%z0 %1, %0": "+m" (foo): "ir" (23));
}
void bar3()
{
int foo;
asm volatile ("mov%z0 %1, %0": "+m" (foo): "ir" (23));
}
void bar4()
{
long long foo;
asm volatile ("mov%z0 %1, %0": "+m" (foo): "ir" (23));
}
[...@gnu-34 gcc]$ ./xgcc -B./ -c /tmp/x.c
/tmp/x.c: Assembler messages:
/tmp/x.c:10: Error: no instruction mnemonic suffix given and no register
operands; can't size instruction
[...@gnu-34 gcc]$
--
Summary: The 'z' suffix doesn't work with 16bit integer insn
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
GCC target triplet: x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39911
[Bug tree-optimization/36188] missed CCP
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-04-26 16:36 --- comment #5 doesn't work anymore because CCP no longer tracks stores. What we would need is predication in value-numbering. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||dberlin at gcc dot gnu dot ||org, rguenth at gcc dot gnu ||dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36188
[Bug fortran/36754] Compile-time bound-checking for allocatable arrays with known bonds
--- Comment #6 from dominiq at lps dot ens dot fr 2009-04-26 16:43 --- I get an error at compile time with gfortran 4.2.3, 4.3.3, 4.4.0, and trunk (intel-darwin9). Is this PR valid? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36754
[Bug middle-end/39904] [4.3 Regressions] Loop is completely skipped due to wrong types in SCEV const-prop
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-04-26 16:49 ---
SCEV const-prop produces for m
D.2395_7 = n.11_27 + -2147483648;
m_19 = D.2395_7 * 2;
which has undefined signed overflow which triggers VRP to deduce wrong
value ranges.
Analyzing # of iterations of loop 1
exit condition [1, + , 1](no_overflow) < n.11_27
bounds on difference of bases: 0 ... 2147483646
result:
# of iterations (unsigned int) n.11_27 + 4294967295, bounded by 2147483646
(set_nb_iterations_in_loop = (unsigned int) n.11_27 + 4294967295))
(chrec_apply
(varying_loop = 1
)
(chrec = {2, +, 2}_1)
(x = (int) ((unsigned int) n.11_27 + 4294967295))
(res = (n.11_27 + -2147483648) * 2))
4.4 instead uses correct types:
Analyzing # of iterations of loop 1
exit condition [1, + , 1](no_overflow) < n.11_28
bounds on difference of bases: 0 ... 2147483646
result:
# of iterations (unsigned int) n.11_28 + 0x0, bounded by 2147483646
(set_nb_iterations_in_loop = (unsigned int) n.11_28 + 0x0))
(chrec_apply
(varying_loop = 1
)
(chrec = {2, +, 2}_1)
(x = (int) ((unsigned int) n.11_28 + 0x0))
(res = (int) ((unsigned int) n.11_28 * 2)))
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||wrong-code
Known to fail||4.3.3
Known to work||4.2.4 4.4.0
Last reconfirmed|-00-00 00:00:00 |2009-04-26 16:49:41
date||
Summary|Loop is completely skipped |[4.3 Regressions] Loop is
||completely skipped due to
||wrong types in SCEV const-
||prop
Target Milestone|--- |4.3.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39904
[Bug fortran/39879] [4.3/4.4/4.5 Regression] double free or corruption abort with gfortran
--- Comment #8 from pault at gcc dot gnu dot org 2009-04-26 16:49 --- I have an "obvious" (ie. after three hours staring at it:-( ) fix that is regtesting. I'd better take the PR! Paul -- 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|2009-04-24 18:00:01 |2009-04-26 16:49:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39879
[Bug c++/39906] Accepted invalid member template specialization in derived class
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-04-26 16:52 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||accepts-invalid Known to fail||4.5.0 Last reconfirmed|-00-00 00:00:00 |2009-04-26 16:52:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39906
[Bug fortran/36754] Compile-time bound-checking for allocatable arrays with known bonds
--- Comment #7 from burnus at gcc dot gnu dot org 2009-04-26 16:54 --- > I get an error at compile time with gfortran 4.2.3, 4.3.3, 4.4.0, and trunk > (intel-darwin9). Is this PR valid? Good question - I get now the same error for comment 0, which makes the report INVALID. I don't get an error for comment 4. I think it is in principle detectable, but difficult -> WONTFIX? At run time, I get for comment 4 "(0/11)" instead of the proper "(1/12)", but I think the off-by-one bug is tracked elsewhere. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36754
[Bug tree-optimization/39907] Aligned access to unaligned address
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-04-26 16:54 --- *** Bug 39908 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39907
[Bug tree-optimization/39908] Aligned access to unaligned address
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-04-26 16:54 --- *** This bug has been marked as a duplicate of 39907 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39908
[Bug c/39581] VLA types at file scope wrongly rejected
--- Comment #1 from jsm28 at gcc dot gnu dot org 2009-04-26 17:00 --- Subject: Bug 39581 Author: jsm28 Date: Sun Apr 26 17:00:04 2009 New Revision: 146806 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146806 Log: PR c/39581 * c-decl.c (global_bindings_p): Return negative value. (c_variable_size): New. Based on variable_size from stor-layout.c. (grokdeclarator): Call c_variable_size not variable_size. testsuite: * gcc.dg/c99-const-expr-14.c, gcc.dg/gnu99-const-expr-4.c, gcc.dg/vla-21.c: New tests. Added: trunk/gcc/testsuite/gcc.dg/c99-const-expr-14.c trunk/gcc/testsuite/gcc.dg/gnu99-const-expr-4.c trunk/gcc/testsuite/gcc.dg/vla-21.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39581
[Bug c/39581] VLA types at file scope wrongly rejected
--- Comment #2 from jsm28 at gcc dot gnu dot org 2009-04-26 17:01 --- Fixed for 4.5. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.5.0 Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39581
[Bug middle-end/39824] [4.5 Regression] ice in fold-const.c
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-04-26 17:05 --- Fixed. -- 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=39824
[Bug tree-optimization/39764] ICE in set_lattice_value, at tree-ssa-ccp.c:468 with -ffinite-math-only
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-04-26 17:06 --- Fix-ed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39764
[Bug c/39889] [4.4 Regression] Bogus -Wunused-value warning
--- Comment #1 from bangerth at gmail dot com 2009-04-26 17:10 --- Jakub, does your patch also fix PR 39875? Thanks W. -- bangerth at gmail dot com changed: What|Removed |Added CC||bangerth at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39889
[Bug c++/39875] [4.5 regression] Wrong "value computed is not used" warning
--- Comment #1 from bangerth at gmail dot com 2009-04-26 17:10 --- May be related to PR 39889. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39875
[Bug tree-optimization/39612] [4.3/4.4/4.5 Regression] LIM inserts loads from uninitialized local memory
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-04-26 17:34 ---
void foo(int *);
void f2(int dst[3], int R)
{
int i, inter[2];
for (i = 1; i < R; i++) {
inter[0] = 1;
inter[1] = 1;
}
foo(inter);
}
Warns at -Os or also at -O2 if you disable loop header copying. So maybe
we should avoid doing loads from local memory in places we do not know
will be executed.
On trunk simply the warning doesn't work anymore, the loads are still there,
same for 4.3.
The loads are not removed by any pass (without loop header copying) and the
loop remains. Note that even with -Os -ftree-ch no loop header copying
is performed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to work||4.2.4
Summary|[4.4/4.5 Regression]|[4.3/4.4/4.5 Regression] LIM
|Incorrect warning issued Re |inserts loads from
|variable *is* used |uninitialized local memory
|uninitialized in this |
|function|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39612
[Bug c/39912] New: FAIL: tmpdir-gcc.dg-struct-layout-1/t001 c_compat_x_tst.o-c_compat_y_tst.o execute
The FAIL: tmpdir-gcc.dg-struct-layout-1/t001 c_compat_x_tst.o-c_compat_y_tst.o
execute test fails on powerpc-apple-darwin9 at -m64. The offending section of
the test is the single line...
T(94,struct atal16{}a;,)
in t001_test.h. With that line deleted, the remainder of the test case passes
without errors. I am
attaching the preprocessed source files generated for this testcase compile as
follows with only that single line in t001_main.h using the commands...
/sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/
-I/sw/src/fink.build/gcc44-4.4.0-1000/gcc-4.4.0/gcc/testsuite
/gcc.dg/compat -fno-common -DSKIP_DECIMAL_FLOAT -c -m64 --save-temps -o
c_compat_main_tst.o
/sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/testsuite/gcc/gcc.dg-struct-lay
out-1/t001_main.c
/sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/ -w
-I/sw/src/fink.build/gcc44-4.4.0-1000/gcc-4.4.0/gcc/testsu
ite/gcc.dg/compat -fno-common -DSKIP_DECIMAL_FLOAT -c -m64 --save-temps -o
c_compat_x_tst.o
/sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/testsuite/gcc/gcc.dg-struct-lay
out-1//t001_x.c
/sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/ -w
-I/sw/src/fink.build/gcc44-4.4.0-1000/gcc-4.4.0/gcc/testsu
ite/gcc.dg/compat -fno-common -DSKIP_DECIMAL_FLOAT -c -m64 --save-temps -o
c_compat_y_tst.o
/sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/testsuite/gcc/gcc.dg-struct-lay
out-1//t001_y.c
/sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/ c_compat_main_tst.o
c_compat_x_tst.o c_compat_y_tst.o -I/sw/s
rc/fink.build/gcc44-4.4.0-1000/gcc-4.4.0/gcc/testsuite/gcc.dg/compat
-fno-common -lm -m64 -o tmpdir-gcc-dg-struct-layout-1-t001-01.exe
./tmpdir-gcc-dg-struct-layout-1-t001-01.exe
The compiler was built with the specs...
Using built-in specs.
Target: powerpc-apple-darwin9
Configured with: ../gcc-4.4.0/configure --prefix=/sw --prefix=/sw/lib/gcc4.4
--mandir=/sw/share/man --infodir=/sw/share/info
--enable-languages=c,c++,fortran,objc,java --with-gmp=/sw
--with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-system-zlib
--x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
--disable-libjava-multilib --build=powerpc-apple-darwin9
--host=powerpc-apple-darwin9 --target=powerpc-apple-darwin9
Thread model: posix
gcc version 4.4.0 (GCC)
--
Summary: FAIL: tmpdir-gcc.dg-struct-layout-1/t001
c_compat_x_tst.o-c_compat_y_tst.o execute
Product: gcc
Version: 4.4.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: powerpc-apple-darwin9
GCC host triplet: powerpc-apple-darwin9
GCC target triplet: powerpc-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39912
[Bug c/39912] FAIL: tmpdir-gcc.dg-struct-layout-1/t001 c_compat_x_tst.o-c_compat_y_tst.o execute
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2009-04-26 17:38 --- Created an attachment (id=17702) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17702&action=view) preprocessed source for t001_x.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39912
[Bug rtl-optimization/39836] [4.4/4.5 regression] unoptimal code generated
--- Comment #4 from vmakarov at redhat dot com 2009-04-26 17:38 ---
The first test case is just an example that RA is a heuristic
solution. Even heuristic algorithm which works worse in average
sometimes can generate a better solution than ones working better in
average.
Here is IRA log of pseudo assignments. Different assignments made by
the old RA are in parenthesis:
Popping a0(r133,l0) -- assign reg 4
Popping a4(r138,l0) -- assign reg 5
Popping a3(r145,l0) -- assign reg 6
Popping a7(r137,l0) -- assign reg 7 (4) <-- key point
Popping a2(r146,l0) -- spill (7)
Popping a9(r139,l0) -- assign reg 2
Popping a10(r147,l0) -- assign reg 6 (1)
Popping a1(r134,l0) -- assign reg 0
Popping a5(r143,l0) -- assign reg 7 (4)
Popping a6(r135,l0) -- assign reg 0
Popping a8(r140,l0) -- assign reg 5 (2)
If IRA assigned hard reg 4 instead of 7 to pseudo 137, all pseudos
would get registers including r139. The old RA assigns 4 to r137
because it prefers the first hard reg in register allocation order if
all other conditions are equal. IRA assigns 7 because it has smaller
cost than 4. The cost is smaller because IRA hopes that r135 could
get 4 later (which is not happened). That is because there is a copy
connected the two allocnos.
cp4:a0(r133)<->a6(r135)@125:shuffle
This copy (called shuffle) is originated from case as in the following
situation
r2 = op (..., r1) and r1 is becoming dead.
Assigning the hard register of r1 to r2 in this situation usually
results in better RA (please read a literature about RA).
The following patch ignoring the shuffle copies results in the same RA
for this test:
Index: gcc/ira-color.c
===
--- gcc/ira-color.c (revision 146788)
+++ gcc/ira-color.c (working copy)
@@ -298,16 +298,18 @@ update_copy_costs (ira_allocno_t allocno
(&ALLOCNO_UPDATED_HARD_REG_COSTS (another_allocno), cover_class,
ALLOCNO_UPDATED_COVER_CLASS_COST (another_allocno),
ALLOCNO_HARD_REG_COSTS (another_allocno));
- ira_allocate_and_set_or_copy_costs
- (&ALLOCNO_UPDATED_CONFLICT_HARD_REG_COSTS (another_allocno),
-cover_class, 0,
-ALLOCNO_CONFLICT_HARD_REG_COSTS (another_allocno));
i = ira_class_hard_reg_index[cover_class][hard_regno];
ira_assert (i >= 0);
ALLOCNO_UPDATED_HARD_REG_COSTS (another_allocno)[i] += update_cost;
- ALLOCNO_UPDATED_CONFLICT_HARD_REG_COSTS (another_allocno)[i]
- += update_cost;
-
+ if (cp->insn != NULL_RTX || cp->constraint_p)
+ {
+ ira_allocate_and_set_or_copy_costs
+ (&ALLOCNO_UPDATED_CONFLICT_HARD_REG_COSTS (another_allocno),
+cover_class, 0,
+ALLOCNO_CONFLICT_HARD_REG_COSTS (another_allocno));
+ ALLOCNO_UPDATED_CONFLICT_HARD_REG_COSTS (another_allocno)[i]
+ += update_cost;
+ }
queue_update_cost (another_allocno, divisor * COST_HOP_DIVISOR);
}
}
But this patch does not improve RA in average (today I checked code
size and performance of SPEC2000 for Core i7 in 32-bit mode). So I
have no sense to commit the patch.
As for the second test I did not find a difference to worry about (I
checked the mainline and gcc-4.3.1 using -march=armv5te
-mthumb-interwork -Os -mthumb):
--- a0.s2009-04-24 17:40:54.0 -0400
+++ a1.s2009-04-24 17:40:36.0 -0400
@@ -1,8 +1,5 @@
.code 16
.file "a.i"
- .section.rodata
-.LC0:
- .ascii "abc\000"
.text
.align 2
.global test
@@ -11,31 +8,35 @@
.type test, %function
test:
push{r4, r5, r6, r7, lr}
- ldr r5, [r0]
- mov r7, r0
- ldrbr3, [r5]
+ ldr r4, [r0]
+ mov r5, r0
+ ldrbr3, [r4]
cmp r3, #91
bne .L2
- mov r0, r5
- ldrbr4, [r5, #1]
+ mov r0, r4
+ ldrbr7, [r4, #1]
bl func
- add r6, r5, #1
- strbr4, [r5, #1]
+ add r6, r4, #1
+ strbr7, [r4, #1]
cmp r0, #0
bne .L3
- mov r5, r6
+ mov r4, r6
.L2:
ldr r0, .L5
mov r1, #0
bl func2
- mov r6, r5
+ mov r6, r4
.L3:
- str r6, [r7]
+ str r6, [r5]
@ sp needed for prologue
pop {r4, r5, r6, r7, pc}
.L6:
.align 2
.L5:
- .word .LC0
+ .word .LANCHOR0
.size test, .-test
- .ident "GCC: (GNU) 4.3.4 20090424 (prerelease)"
+ .section.rodata
+ .set.LANCHOR0,. + 0
+.LC0:
+ .ascii "abc\000"
+ .ident "GCC: (GNU) 4.5.0 20090423 (experimental)"
--
[Bug c/39912] FAIL: tmpdir-gcc.dg-struct-layout-1/t001 c_compat_x_tst.o-c_compat_y_tst.o execute
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2009-04-26 17:38 --- Created an attachment (id=17703) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17703&action=view) preprocessed source for t001_y.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39912
[Bug fortran/36754] Compile-time bound-checking for allocatable arrays with known bonds
--- Comment #8 from dominiq at lps dot ens dot fr 2009-04-26 17:38 --- > I don't get an error for comment 4. I think it is in principle detectable, but > difficult -> WONTFIX? Confirmed. It may already be in one (or several) opened PR in the [meta] PR27766. I have started to look at it, but it is quite messy. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36754
[Bug c/39912] FAIL: tmpdir-gcc.dg-struct-layout-1/t001 c_compat_x_tst.o-c_compat_y_tst.o execute
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2009-04-26 17:39 --- Created an attachment (id=17704) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17704&action=view) preprocessed source for t001_main.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39912
[Bug c/39912] FAIL: tmpdir-gcc.dg-struct-layout-1/t001 c_compat_x_tst.o-c_compat_y_tst.o execute
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2009-04-26 17:39 --- Created an attachment (id=17705) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17705&action=view) assembly file for t001_x.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39912
[Bug c/39912] FAIL: tmpdir-gcc.dg-struct-layout-1/t001 c_compat_x_tst.o-c_compat_y_tst.o execute
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2009-04-26 17:40 --- Created an attachment (id=17706) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17706&action=view) assembly file for t001_y.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39912
[Bug c/39912] FAIL: tmpdir-gcc.dg-struct-layout-1/t001 c_compat_x_tst.o-c_compat_y_tst.o execute
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2009-04-26 17:40 --- Created an attachment (id=17708) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17708&action=view) assembly file for t001_main.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39912
[Bug libstdc++/39909] non-TLS version of std::call_once causes terminate
--- Comment #2 from jwakely dot gcc at gmail dot com 2009-04-26 17:40 --- Created an attachment (id=17707) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17707&action=view) fix call_once without breaking ABI Fix call_once to not use the global lock object, but retain the global for ABI reasons. __once_proxy detects if it was called by new code that provides the address of a local lock object, or by old code that uses the global lock. Without that check any uses of call_once inlined in old objects will be liable to deadlock (because the global lock won't be unlocked before invoking the functor) or segfaults (if the pointer is null when __once_proxy uses it). Multiple concurrent calls to call_once from old object code will still terminate, but it should be OK for new object code to use call_once freely, and even for exactly one thread using the old call_once to run concurrently with new code using call_once (because there would only be the single thread using the global lock object.) This patch adds the new symbols to the GLIBCXX_3.4.11 version but they should be in a new 3.4.12 block - I don't know what I need to do for that. Tested x86_64/linux --disable-tls -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39909
[Bug fortran/36754] Compile-time bound-checking for allocatable arrays with known bonds
--- Comment #9 from dominiq at lps dot ens dot fr 2009-04-26 17:47 --- > I don't get an error for comment 4. This may be a duplicate of PR36683(?). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36754
[Bug libstdc++/39909] non-TLS version of std::call_once causes terminate
--- Comment #3 from paolo dot carlini at oracle dot com 2009-04-26 17:53 --- Thanks Jon, for following up about this. Let's try to close the issue during the next days... About 3.4.12, it's just matter of manually editing gnu.ver, adding the block + manually adding GLIBCXX_3.4.12 to testsuite_abi.cc. Then regression testing should still succeed after the changes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39909
[Bug libstdc++/39909] non-TLS version of std::call_once causes terminate
-- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-04-26 17:53:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39909
[Bug libstdc++/39909] non-TLS version of std::call_once causes terminate
--- Comment #4 from jwakely dot gcc at gmail dot com 2009-04-26 18:06 --- Created an attachment (id=17709) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17709&action=view) use GLIBCXX_3.4.12 version for new symbols same patch again, with the new symbols using a new version and testsuite changes included -- jwakely dot gcc at gmail dot com changed: What|Removed |Added Attachment #17707|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39909
[Bug c++/24118] Access control bug for base class of templates
--- Comment #2 from sutambe at yahoo dot com 2009-04-26 18:19 --- Another similar access control related issue is bug #33934 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33934) -- sutambe at yahoo dot com changed: What|Removed |Added CC||sutambe at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24118
[Bug c/39913] New: tmpdir-gcc.dg-struct-layout-1/t003 c_compat_x_tst.o-c_compat_y_tst.o execute failure
The tmpdir-gcc.dg-struct-layout-1/t003 c_compat_x_tst.o-c_compat_y_tst.o
execute test case fails on powerpc-apple-darwin9 when compiled at -m64. The
offending lines in t003_test.h causing this failure are...
T(693,double atal2 a;Tal16long b;short int
c;struct{}d;,F(693,a,-9109.968750,89665.703125)F(693,b,-2780362564512530142LL,-188249301918206LL)F(693,c,29451,-6341))
T(760,float a;long double b;unsigned long int c;signed char
d;,F(760,a,-218391.812500,-167965.062500)F(760,b,-122404.406250,-90172.859375)F(760,c,2933687826322174624U
LL,14862826394269793540ULL)F(760,d,55,64))
With those lines deleted the remainder of the test case passes its execution
test. I am attaching the preprocessed and assembly source files for the
testcase with only those two lines in t003_test.h compiled with...
/sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/
-I/sw/src/fink.build/gcc44-4.4.0-1000/gcc-4.4.0/g
cc/testsuite/gcc.dg/compat -fno-common -DSKIP_DECIMAL_FLOAT -c -m64
--save-temps -o c_compat_main_tst.o
/sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/testsui
te/gcc/gcc.dg-struct-layout-1/t003_main.c
/sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/ -w
-I/sw/src/fink.build/gcc44-4.4.0-1000/gcc-4.4.
0/gcc/testsuite/gcc.dg/compat -fno-common -DSKIP_DECIMAL_FLOAT -c -m64
--save-temps -o c_compat_x_tst.o
/sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/testsui
te/gcc/gcc.dg-struct-layout-1//t003_x.c
/sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/ -w
-I/sw/src/fink.build/gcc44-4.4.0-1000/gcc-4.4.
0/gcc/testsuite/gcc.dg/compat -fno-common -DSKIP_DECIMAL_FLOAT -c -m64
--save-temps -o c_compat_y_tst.o
/sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/testsui
te/gcc/gcc.dg-struct-layout-1//t003_y.c
/sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/ c_compat_main_tst.o
c_compat_x_tst.o c_compat_y_ts
t.o
-I/sw/src/fink.build/gcc44-4.4.0-1000/gcc-4.4.0/gcc/testsuite/gcc.dg/compat
-fno-common -lm -m64 -o tmpdir-gcc-dg-struct-layout-1-t003-01.exe
./tmpdir-gcc-dg-struct-layout-1-t003-01.exe
using a the gcc 4.4.0 compiler built with the following specs...
Using built-in specs.
Target: powerpc-apple-darwin9
Configured with: ../gcc-4.4.0/configure --prefix=/sw --prefix=/sw/lib/gcc4.4
--mandir=/sw/share/man --infodir=/sw/share/info
--enable-languages=c,c++,fortran,objc,java --with-gmp=/sw
--with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-system-zlib
--x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
--disable-libjava-multilib --build=powerpc-apple-darwin9
--host=powerpc-apple-darwin9 --target=powerpc-apple-darwin9
Thread model: posix
gcc version 4.4.0 (GCC)
--
Summary: tmpdir-gcc.dg-struct-layout-1/t003 c_compat_x_tst.o-
c_compat_y_tst.o execute failure
Product: gcc
Version: 4.4.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: powerpc-apple-darwin9
GCC host triplet: powerpc-apple-darwin9
GCC target triplet: powerpc-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39913
[Bug c/39913] tmpdir-gcc.dg-struct-layout-1/t003 c_compat_x_tst.o-c_compat_y_tst.o execute failure
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2009-04-26 18:20 --- Created an attachment (id=17710) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17710&action=view) preprocessed source for t003_x.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39913
[Bug c/39913] tmpdir-gcc.dg-struct-layout-1/t003 c_compat_x_tst.o-c_compat_y_tst.o execute failure
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2009-04-26 18:21 --- Created an attachment (id=17711) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17711&action=view) preprocessed source for t003_y.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39913
[Bug c/39913] tmpdir-gcc.dg-struct-layout-1/t003 c_compat_x_tst.o-c_compat_y_tst.o execute failure
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2009-04-26 18:21 --- Created an attachment (id=17712) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17712&action=view) preprocessed source for t003_main.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39913
[Bug c/39913] tmpdir-gcc.dg-struct-layout-1/t003 c_compat_x_tst.o-c_compat_y_tst.o execute failure
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2009-04-26 18:22 --- Created an attachment (id=17713) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17713&action=view) assembly file for t003_x.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39913
[Bug c/39913] tmpdir-gcc.dg-struct-layout-1/t003 c_compat_x_tst.o-c_compat_y_tst.o execute failure
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2009-04-26 18:22 --- Created an attachment (id=17714) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17714&action=view) assembly file for t003_y.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39913
[Bug target/39545] Structures with flexible array member passed/returned incorrectly
--- Comment #9 from ubizjak at gmail dot com 2009-04-26 18:22 --- (In reply to comment #6) > 2009-03-29 H.J. Lu > > PR target/39545 > * config/i386/i386.c (classify_argument): Ignore flexible array > member in struct and warn ABI change. This patch caused PR39903. -- ubizjak at gmail dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39545
[Bug c/39913] tmpdir-gcc.dg-struct-layout-1/t003 c_compat_x_tst.o-c_compat_y_tst.o execute failure
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2009-04-26 18:23 --- Created an attachment (id=17715) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17715&action=view) assembly file for t003_main.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39913
[Bug regression/39914] New: 96% performance regression in floating point code; part of the problem started 2009/03/12-13
With this compiler: gcc version 4.4.0 20090312 (experimental) [trunk revision 144801] (GCC) running the test in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928 (same .i file, same instructions for reproducing, same compiler options, same everything) gives a time of 132 ms cpu time (132 user, 0 system) with assembly code in the main loop of .L2958: movq%rdx, %rcx addq(%r11), %rcx leaq4(%rdx), %r14 movq%rcx, (%rdi) addq$4, %rcx movq%rcx, (%r10) movq(%r11), %rcx addq(%rdi), %rcx movq%rcx, (%rsi) addq$4, %rcx movq%rcx, (%r9) movq(%r11), %r12 addq(%rsi), %r12 movq%r12, (%rbp) addq$4, %r12 movq%r12, (%r15) movq(%rax), %rcx addq$7, %rcx movsd (%rcx,%r12,2), %xmm7 movq(%rbp), %r12 leaq(%rcx,%rdx,2), %r13 addq$8, %rdx movsd (%r13), %xmm4 movsd (%rcx,%r12,2), %xmm10 movq(%r9), %r12 movsd (%rcx,%r12,2), %xmm5 movq(%rsi), %r12 movsd (%rcx,%r12,2), %xmm6 movq(%r10), %r12 movsd (%rcx,%r12,2), %xmm13 movq(%rdi), %r12 movsd (%rcx,%r12,2), %xmm11 leaq(%r14,%r14), %r12 movsd (%rcx,%r12), %xmm9 movq24(%r8), %rcx movapd %xmm11, %xmm14 movsd 15(%rcx), %xmm1 movsd 7(%rcx), %xmm2 movapd %xmm1, %xmm8 movsd 31(%rcx), %xmm3 movapd %xmm2, %xmm12 mulsd %xmm10, %xmm8 mulsd %xmm7, %xmm12 mulsd %xmm2, %xmm10 mulsd %xmm1, %xmm7 movsd 23(%rcx), %xmm0 addsd %xmm8, %xmm12 movapd %xmm2, %xmm8 mulsd %xmm6, %xmm2 subsd %xmm7, %xmm10 movapd %xmm1, %xmm7 mulsd %xmm5, %xmm1 mulsd %xmm6, %xmm7 movapd %xmm4, %xmm6 mulsd %xmm5, %xmm8 movapd %xmm9, %xmm5 subsd %xmm10, %xmm14 subsd %xmm1, %xmm2 movapd %xmm3, %xmm1 addsd %xmm11, %xmm10 xorpd .LC5(%rip), %xmm1 addsd %xmm7, %xmm8 movapd %xmm13, %xmm7 subsd %xmm2, %xmm6 subsd %xmm12, %xmm7 subsd %xmm8, %xmm5 addsd %xmm4, %xmm2 movapd %xmm0, %xmm4 addsd %xmm9, %xmm8 movapd %xmm1, %xmm9 mulsd %xmm14, %xmm4 addsd %xmm13, %xmm12 mulsd %xmm7, %xmm9 mulsd %xmm1, %xmm14 movapd %xmm3, %xmm1 mulsd %xmm0, %xmm7 mulsd %xmm10, %xmm1 mulsd %xmm0, %xmm10 addsd %xmm9, %xmm4 subsd %xmm7, %xmm14 movapd %xmm0, %xmm7 movapd %xmm2, %xmm0 mulsd %xmm12, %xmm7 mulsd %xmm3, %xmm12 addsd %xmm1, %xmm7 subsd %xmm12, %xmm10 addsd %xmm10, %xmm0 subsd %xmm10, %xmm2 movsd %xmm0, (%r13) movapd %xmm8, %xmm0 movq(%rax), %rcx subsd %xmm7, %xmm8 addsd %xmm7, %xmm0 movsd %xmm0, 7(%r12,%rcx) movq(%rdi), %r12 movq(%rax), %rcx movapd %xmm6, %xmm0 subsd %xmm14, %xmm6 movsd %xmm2, 7(%rcx,%r12,2) movq(%r10), %r12 movq(%rax), %rcx addsd %xmm14, %xmm0 movsd %xmm8, 7(%rcx,%r12,2) movq(%rsi), %r12 movq(%rax), %rcx movsd %xmm0, 7(%rcx,%r12,2) movapd %xmm5, %xmm0 movq(%r9), %r12 movq(%rax), %rcx subsd %xmm4, %xmm5 addsd %xmm4, %xmm0 movsd %xmm0, 7(%rcx,%r12,2) movq(%rbp), %r12 movq(%rax), %rcx movsd %xmm6, 7(%rcx,%r12,2) movq(%r15), %r12 movq(%rax), %rcx movsd %xmm5, 7(%rcx,%r12,2) cmpq%rdx, -104(%rsp) jg .L2958 movq%r14, -104(%rsp) With this compiler /pkgs/gcc-mainline/bin/gcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /tmp/lucier/gcc/mainline/configure --enable-checking=release --prefix=/pkgs/gcc-mainline --enable-languages=c --enable-gather-detailed-mem-stats Thread model: posix gcc version 4.4.0 20090313 (experimental) [trunk revision 144829] (GCC) one gets a time of 212 ms cpu time (212 user, 0 system) and the assembly language for the main loop is .L2946: movq%rbx, %rdx addq(%r11), %rdx leaq4(%rbx), %rbp movq%rdx, (%rsi) addq$4, %rdx movq%rdx, (%r10) movq(%r11), %rdx addq(%rsi), %rdx movq%rdx, (%rcx) addq$4, %rdx movq%rdx, (%r9) movq(%r11), %r13 addq(%rcx), %r13 movq%r13, (%r8) addq$4, %r13 movq%r13, (%r15) movq(%rax), %rdx add
[Bug tree-optimization/33928] [4.3/4.4/4.5 Regression] 30% performance slowdown in floating-point code caused by r118475
--- Comment #52 from lucier at math dot purdue dot edu 2009-04-26 18:27 --- I narrowed down the new performance regression to code added some time around March 12, 2009, so I changed back the subject line of this PR to reflect the performance regression caused only by the code added 2006-11-03 and added a new PR http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39914 to reflect the effects of the March, 2009, code. -- lucier at math dot purdue dot edu changed: What|Removed |Added Summary|[4.3/4.4/4.5 Regression] 79%|[4.3/4.4/4.5 Regression] 30% |performance slowdown in |performance slowdown in |floating-point code |floating-point code caused |partially caused by r118475|by r118475 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
[Bug tree-optimization/39612] [4.3/4.4/4.5 Regression] LIM inserts loads from uninitialized local memory
--- Comment #5 from rakdver at gcc dot gnu dot org 2009-04-26 18:37 ---
(In reply to comment #4)
> void foo(int *);
> void f2(int dst[3], int R)
> {
> int i, inter[2];
>
> for (i = 1; i < R; i++) {
> inter[0] = 1;
> inter[1] = 1;
> }
>
> foo(inter);
> }
>
> Warns at -Os or also at -O2 if you disable loop header copying.
Right. The initial value of inter may reach the call to foo (when R <= 1), so
we must issue (and keep) the loads if we want to perform lsm without loop
header copying. While I recognize that adding the loads from (possibly)
uninitialized memory is somewhat annoying, limiting lsm only to loops where we
can prove that this does not happen does not make much sense, either.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39612
[Bug target/39911] The 'z' suffix doesn't work with 16bit integer insn
--- Comment #1 from hjl dot tools at gmail dot com 2009-04-26 18:42 --- Created an attachment (id=17716) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17716&action=view) A patch Since "%z' never really worked on integer instructions, this patch makes "%Z" for integer instructions only while providing backward compatibility for existing asm statements. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39911
[Bug regression/39914] 96% performance regression in floating point code; part of the problem started 2009/03/12-13
--- Comment #1 from ubizjak at gmail dot com 2009-04-26 18:43 --- There are a couple of possible candidates in this range: URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144812 Log: 2009-03-12 Vladimir Makarov PR debug/39432 * ira-int.h (struct allocno): Fix comment for calls_crossed_num. * ira-conflicts.c (ira_build_conflicts): Prohibit call used registers for allocnos created from user-defined variables. URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144817 Log: 2009-03-12 H.J. Lu PR target/38824 * config/i386/i386.md: Compare REGNO on the new peephole2 patterns. URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144823 Log: gcc/ 2009-03-12 H.J. Lu PR target/39445 * config/i386/i386.c (ix86_expand_push): Don't set memory alignment. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39914
[Bug c/39915] New: tmpdir-gcc.dg-struct-layout-1/t005 c_compat_x_tst.o-c_compat_y_tst.o execute failure at -m64
The tmpdir-gcc.dg-struct-layout-1/t005 c_compat_x_tst.o-c_compat_y_tst.o execute testcase fails at -m64 on powerpc-apple-darwin9. The offending line in t005_test.h is... T(998,df a;Talllong b:BQN(20);long long int c:BQN(1);TE4 d:19;long int e;,F(998,a,140017.484375,-160009.218750)B(998,b,-303431,345440)B(998,c,0,0)B(998,d,e4_253,e4_2)F(998,e,3562377756672343063LL,5761410617366885841LL)) With that line removed, the remainder of the t005 test case passes its execution test. I am attaching the proprocessed and assembly files from the t005 test case compiled with the single line above using the commands... /sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/ -I/sw/src/fink.build/gcc44-4.4.0-1000/gcc-4.4.0/gcc/testsuite/gcc.dg/compat -fno-common -DSKIP_DECIMAL_FLOAT -c -m64 --save-temps -o c_compat_main_tst.o /sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/testsuite/gcc/gcc.dg-struct-layout-1/t005_main.c /sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/ -w -I/sw/src/fink.build/gcc44-4.4.0-1000/gcc-4.4.0/gcc/testsuite/gcc.dg/compat -fno-common -DSKIP_DECIMAL_FLOAT -c -m64 --save-temps -o c_compat_x_tst.o /sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/testsuite/gcc/gcc.dg-struct-layout-1//t005_x.c /sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/ -w -I/sw/src/fink.build/gcc44-4.4.0-1000/gcc-4.4.0/gcc/testsuite/gcc.dg/compat -fno-common -DSKIP_DECIMAL_FLOAT -c -m64 --save-temps -o c_compat_y_tst.o /sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/testsuite/gcc/gcc.dg-struct-layout-1//t005_y.c /sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/ c_compat_main_tst.o c_compat_x_tst.o c_compat_y_tst.o -I/sw/src/fink.build/gcc44-4.4.0-1000/gcc-4.4.0/gcc/testsuite/gcc.dg/compat -fno-common -lm -m64 -o tmpdir-gcc-dg-struct-layout-1-t005-01.exe The compiler was built with the specs... Using built-in specs. Target: powerpc-apple-darwin9 Configured with: ../gcc-4.4.0/configure --prefix=/sw --prefix=/sw/lib/gcc4.4 --mandir=/sw/share/man --infodir=/sw/share/info --enable-languages=c,c++,fortran,objc,java --with-gmp=/sw --with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --disable-libjava-multilib --build=powerpc-apple-darwin9 --host=powerpc-apple-darwin9 --target=powerpc-apple-darwin9 Thread model: posix gcc version 4.4.0 (GCC) -- Summary: tmpdir-gcc.dg-struct-layout-1/t005 c_compat_x_tst.o- c_compat_y_tst.o execute failure at -m64 Product: gcc Version: 4.4.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: powerpc-apple-darwin9 GCC host triplet: powerpc-apple-darwin9 GCC target triplet: powerpc-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39915
[Bug tree-optimization/39612] [4.3/4.4/4.5 Regression] LIM inserts loads from uninitialized local memory
--- Comment #6 from rguenther at suse dot de 2009-04-26 18:44 ---
Subject: Re: [4.3/4.4/4.5 Regression] LIM
inserts loads from uninitialized local memory
On Sun, 26 Apr 2009, rakdver at gcc dot gnu dot org wrote:
> --- Comment #5 from rakdver at gcc dot gnu dot org 2009-04-26 18:37
> ---
> (In reply to comment #4)
> > void foo(int *);
> > void f2(int dst[3], int R)
> > {
> > int i, inter[2];
> >
> > for (i = 1; i < R; i++) {
> > inter[0] = 1;
> > inter[1] = 1;
> > }
> >
> > foo(inter);
> > }
> >
> > Warns at -Os or also at -O2 if you disable loop header copying.
>
> Right. The initial value of inter may reach the call to foo (when R <= 1), so
> we must issue (and keep) the loads if we want to perform lsm without loop
> header copying. While I recognize that adding the loads from (possibly)
> uninitialized memory is somewhat annoying, limiting lsm only to loops where we
> can prove that this does not happen does not make much sense, either.
Ok. I guess setting TREE_NO_WARNING on the inserted loads could avoid
the uninitialized warning in 4.4.
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39612
[Bug target/39911] The 'z' suffix doesn't work with 16bit integer insn
--- Comment #2 from hjl dot tools at gmail dot com 2009-04-26 18:45 --- Created an attachment (id=17717) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17717&action=view) A patch The updated patch. -- hjl dot tools at gmail dot com changed: What|Removed |Added Attachment #17716|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39911
[Bug c/39915] tmpdir-gcc.dg-struct-layout-1/t005 c_compat_x_tst.o-c_compat_y_tst.o execute failure at -m64
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2009-04-26 18:45 --- Created an attachment (id=17718) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17718&action=view) preprocessed source for t005_x.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39915
[Bug c/39915] tmpdir-gcc.dg-struct-layout-1/t005 c_compat_x_tst.o-c_compat_y_tst.o execute failure at -m64
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2009-04-26 18:45 --- Created an attachment (id=17719) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17719&action=view) preprocessed source for t005_y.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39915
[Bug c/39915] tmpdir-gcc.dg-struct-layout-1/t005 c_compat_x_tst.o-c_compat_y_tst.o execute failure at -m64
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2009-04-26 18:46 --- Created an attachment (id=17720) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17720&action=view) preprocessed source for t005_main.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39915
[Bug c/39915] tmpdir-gcc.dg-struct-layout-1/t005 c_compat_x_tst.o-c_compat_y_tst.o execute failure at -m64
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2009-04-26 18:46 --- Created an attachment (id=17721) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17721&action=view) assembly file for t005_x.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39915
[Bug c/39915] tmpdir-gcc.dg-struct-layout-1/t005 c_compat_x_tst.o-c_compat_y_tst.o execute failure at -m64
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2009-04-26 18:47 --- Created an attachment (id=17722) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17722&action=view) assembly file for t005_y.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39915
[Bug c/39915] tmpdir-gcc.dg-struct-layout-1/t005 c_compat_x_tst.o-c_compat_y_tst.o execute failure at -m64
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2009-04-26 18:47 --- Created an attachment (id=17723) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17723&action=view) assembly file for t005_main.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39915
[Bug c/39889] [4.4 Regression] Bogus -Wunused-value warning
--- Comment #2 from jakub at gcc dot gnu dot org 2009-04-26 18:51 --- Subject: Bug 39889 Author: jakub Date: Sun Apr 26 18:51:07 2009 New Revision: 146811 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146811 Log: PR c/39889 * stmt.c (warn_if_unused_value): Look through NON_LVALUE_EXPR. * gcc.dg/Wunused-value-3.c: New test. Added: trunk/gcc/testsuite/gcc.dg/Wunused-value-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/fortran/ChangeLog trunk/gcc/stmt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39889
[Bug c/39889] [4.4 Regression] Bogus -Wunused-value warning
--- Comment #3 from jakub at gcc dot gnu dot org 2009-04-26 18:53 --- Subject: Bug 39889 Author: jakub Date: Sun Apr 26 18:53:41 2009 New Revision: 146812 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146812 Log: PR c/39889 * stmt.c (warn_if_unused_value): Look through NON_LVALUE_EXPR. * gcc.dg/Wunused-value-3.c: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/Wunused-value-3.c Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/stmt.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39889
[Bug target/39911] The 'z' suffix doesn't work with 16bit integer insn
--- Comment #3 from ubizjak at gmail dot com 2009-04-26 18:55 --- (In reply to comment #1) > Created an attachment (id=17716) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17716&action=view) [edit] > A patch > > Since "%z' never really worked on integer instructions, this > patch makes "%Z" for integer instructions only while providing > backward compatibility for existing asm statements. But this issue arises because users want %z on integer insn! My proposal is, to enhance %Z to handle all x87 operands/instructions and leave %z for integer instructions. I hope there is no users of %z with x87 insns. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39911
[Bug inline-asm/39543] [4.4/4.5 Regression] Reload failure on mplayer from SVN
--- Comment #14 from jakub at gcc dot gnu dot org 2009-04-26 18:56 --- Subject: Bug 39543 Author: jakub Date: Sun Apr 26 18:56:14 2009 New Revision: 146813 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146813 Log: PR inline-asm/39543 * fwprop.c (forward_propagate_asm): New function. (forward_propagate_and_simplify): Propagate also into __asm, if it doesn't increase the number of referenced registers. * gcc.target/i386/pr39543-1.c: New test. * gcc.target/i386/pr39543-2.c: New test. * gcc.target/i386/pr39543-3.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr39543-1.c trunk/gcc/testsuite/gcc.target/i386/pr39543-2.c trunk/gcc/testsuite/gcc.target/i386/pr39543-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/fwprop.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39543
[Bug inline-asm/39543] [4.4/4.5 Regression] Reload failure on mplayer from SVN
--- Comment #15 from jakub at gcc dot gnu dot org 2009-04-26 18:58 --- Subject: Bug 39543 Author: jakub Date: Sun Apr 26 18:58:04 2009 New Revision: 146814 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146814 Log: PR inline-asm/39543 * fwprop.c (forward_propagate_asm): New function. (forward_propagate_and_simplify): Propagate also into __asm, if it doesn't increase the number of referenced registers. * gcc.target/i386/pr39543-1.c: New test. * gcc.target/i386/pr39543-2.c: New test. * gcc.target/i386/pr39543-3.c: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/gcc.target/i386/pr39543-1.c - copied unchanged from r146813, trunk/gcc/testsuite/gcc.target/i386/pr39543-1.c branches/gcc-4_4-branch/gcc/testsuite/gcc.target/i386/pr39543-2.c - copied unchanged from r146813, trunk/gcc/testsuite/gcc.target/i386/pr39543-2.c branches/gcc-4_4-branch/gcc/testsuite/gcc.target/i386/pr39543-3.c - copied unchanged from r146813, trunk/gcc/testsuite/gcc.target/i386/pr39543-3.c Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/fwprop.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39543
[Bug target/39911] The 'z' suffix doesn't work with 16bit integer insn
--- Comment #4 from hjl dot tools at gmail dot com 2009-04-26 19:03 --- (In reply to comment #3) > (In reply to comment #1) > > Created an attachment (id=17716) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17716&action=view) [edit] > > A patch > > > > Since "%z' never really worked on integer instructions, this > > patch makes "%Z" for integer instructions only while providing > > backward compatibility for existing asm statements. > > But this issue arises because users want %z on integer insn! > > My proposal is, to enhance %Z to handle all x87 operands/instructions and > leave > %z for integer instructions. I hope there is no users of %z with x87 insns. > It may break existing working asm statements with "%z" on x87 instructions. Since "%z" never really worked on asm statements with "%z" on integer insns, there is little risk to break existing working asm statements with "%z" for my proposal. With older gcc, asm statements with "%z" on integer insns don't work. With fixed gcc, they can use "%Z". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39911
[Bug c/39916] New: tmpdir-gcc.dg-struct-layout-1/t006 c_compat_x_tst.o-c_compat_y_tst.o execute failure at -m64
The tmpdir-gcc.dg-struct-layout-1/t006 c_compat_x_tst.o-c_compat_y_tst.o
execute testcase fails at -m64 on powerpc-apple-darwin9. The offending line in
t006_test.h causing this failure is...
T(1082,struct{char b;TE0 c[7];char * d[20];long double e atal16;long long int
f;}a[0];,)
With that line deleted, the remainder of the test case passes without errors. I
am attached the preprocessed and assembly files generated for the testcase
compiled as follows...
/sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/
-I/sw/src/fink.build/gcc44-4.4.0-1000/gcc-4.4.0/gcc/testsuite/gcc.dg/compat
-fno-common -DSKIP_DECIMAL_FLOAT -c -m64 --save-temps -o c_compat_main_tst.o
/sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/testsuite/gcc/gcc.dg-struct-layout-1/t006_main.c
/sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/ -w
-I/sw/src/fink.build/gcc44-4.4.0-1000/gcc-4.4.0/gcc/testsuite/gcc.dg/compat
-fno-common -DSKIP_DECIMAL_FLOAT -c -m64 --save-temps -o c_compat_x_tst.o
/sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/testsuite/gcc/gcc.dg-struct-layout-1//t006_x.c
/sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/ -w
-I/sw/src/fink.build/gcc44-4.4.0-1000/gcc-4.4.0/gcc/testsuite/gcc.dg/compat
-fno-common -DSKIP_DECIMAL_FLOAT -c -m64 --save-temps -o c_compat_y_tst.o
/sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/testsuite/gcc/gcc.dg-struct-layout-1//t006_y.c
/sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/ c_compat_main_tst.o
c_compat_x_tst.o c_compat_y_tst.o
-I/sw/src/fink.build/gcc44-4.4.0-1000/gcc-4.4.0/gcc/testsuite/gcc.dg/compat
-fno-common -lm -m6
4 -o tmpdir-gcc-dg-struct-layout-1-t006-01.exe
The compiler was built with the specs...
Using built-in specs.
Target: powerpc-apple-darwin9
Configured with: ../gcc-4.4.0/configure --prefix=/sw --prefix=/sw/lib/gcc4.4
--mandir=/sw/share/man --infodir=/sw/share/info
--enable-languages=c,c++,fortran,objc,java --with-gmp=/sw
--with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-system-zlib
--x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
--disable-libjava-multilib --build=powerpc-apple-darwin9
--host=powerpc-apple-darwin9 --target=powerpc-apple-darwin9
Thread model: posix
gcc version 4.4.0 (GCC)
--
Summary: tmpdir-gcc.dg-struct-layout-1/t006 c_compat_x_tst.o-
c_compat_y_tst.o execute failure at -m64
Product: gcc
Version: 4.4.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: powerpc-apple-darwin9
GCC host triplet: powerpc-apple-darwin9
GCC target triplet: powerpc-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39916
[Bug c/39916] tmpdir-gcc.dg-struct-layout-1/t006 c_compat_x_tst.o-c_compat_y_tst.o execute failure at -m64
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2009-04-26 19:04 --- Created an attachment (id=17724) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17724&action=view) preprocessed source for t006_x.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39916
[Bug c/39916] tmpdir-gcc.dg-struct-layout-1/t006 c_compat_x_tst.o-c_compat_y_tst.o execute failure at -m64
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2009-04-26 19:05 --- Created an attachment (id=17725) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17725&action=view) preprocessed source for t006_y.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39916
[Bug c/39916] tmpdir-gcc.dg-struct-layout-1/t006 c_compat_x_tst.o-c_compat_y_tst.o execute failure at -m64
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2009-04-26 19:05 --- Created an attachment (id=17726) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17726&action=view) preprocessed source for t006_main.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39916
[Bug c/39916] tmpdir-gcc.dg-struct-layout-1/t006 c_compat_x_tst.o-c_compat_y_tst.o execute failure at -m64
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2009-04-26 19:06 --- Created an attachment (id=17727) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17727&action=view) assembly file for t006_x.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39916
[Bug c/39916] tmpdir-gcc.dg-struct-layout-1/t006 c_compat_x_tst.o-c_compat_y_tst.o execute failure at -m64
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2009-04-26 19:07 --- Created an attachment (id=17728) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17728&action=view) assembly file for t006_y.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39916
[Bug c/39916] tmpdir-gcc.dg-struct-layout-1/t006 c_compat_x_tst.o-c_compat_y_tst.o execute failure at -m64
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2009-04-26 19:07 --- Created an attachment (id=17729) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17729&action=view) assembly file for t006_main.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39916
[Bug c/39889] [4.4 Regression] Bogus -Wunused-value warning
--- Comment #4 from jakub at gcc dot gnu dot org 2009-04-26 19:08 --- This is unrelated to PR39875, which looks like purely C++ FE issue. -- 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=39889
[Bug inline-asm/39543] [4.4/4.5 Regression] Reload failure on mplayer from SVN
--- Comment #16 from jakub at gcc dot gnu dot org 2009-04-26 19:09 --- 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=39543
[Bug target/39911] The 'z' suffix doesn't work with 16bit integer insn
--- Comment #5 from jakub at gcc dot gnu dot org 2009-04-26 19:15 --- I agree with H.J. on this, IMHO %zN should stay as it used to always work and users that want to use something on integer instructions should use the new %ZN. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39911
[Bug fortran/39879] [4.3/4.4/4.5 Regression] double free or corruption abort with gfortran
--- Comment #9 from pault at gcc dot gnu dot org 2009-04-26 19:22 --- (In reply to comment #8) > I have an "obvious" (ie. after three hours staring at it:-( ) fix that is Index: gcc/fortran/resolve.c === --- gcc/fortran/resolve.c (revision 146772) +++ gcc/fortran/resolve.c (working copy) @@ -6645,7 +6645,8 @@ if (rhs->expr_type == EXPR_VARIABLE && rhs->symtree->n.sym->ts.type == BT_DERIVED && has_default_initializer (rhs->symtree->n.sym->ts.derived) - && (lhs->symtree->n.sym == rhs->symtree->n.sym)) + && (lhs->symtree->n.sym == rhs->symtree->n.sym) + && !(rhs->ref || lhs->ref)) code->ext.actual->next->expr = gfc_get_parentheses (rhs); return true; which regtests OK but I need a day or so to dwell on. Although the above is my doing, I do not recall for the life of me why a temporary had to be added in this case. I will attempt to recall that and figure out exactly which cases are counter-indicated. By the way, David, thanks for the report! Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39879
[Bug c++/39875] [4.5 regression] Wrong "value computed is not used" warning
--- Comment #2 from jakub at gcc dot gnu dot org 2009-04-26 19:23 ---
No need for templates:
void foo ()
{
int *i;
(void) *i; // { dg-bogus "value computed is not used" }
}
This was caused by
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146132
(PR39551). convert_to_void doesn't know if the conversion to void was caused
by explicit cast (in this testcase, no warning should be emitted) or implicit
(when it should be emitted).
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
CC||lcwu at gcc dot gnu dot org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-04-26 19:23:28
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39875
[Bug fortran/39893] gfortran ICE on invalid program
--- Comment #6 from kargl at gcc dot gnu dot org 2009-04-26 19:28 --- Subject: Bug 39893 Author: kargl Date: Sun Apr 26 19:27:50 2009 New Revision: 146816 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146816 Log: 2009-04-26 Steven G. Kargl PR fortran/39893 * gfortran.dg/assumed_charlen_dummy.f90: New Test. 2009-04-26 Steven G. Kargl PR fortran/39893 fortran/data.c (gfc_assign_data_value): If the lvalue is an assumed character length entity in a data statement, then return FAILURE to prevent segmentation fault. Added: trunk/gcc/testsuite/gfortran.dg/assumed_charlen_dummy.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/data.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39893
[Bug fortran/39893] [4.4] gfortran ICE on invalid program
--- Comment #7 from kargl at gcc dot gnu dot org 2009-04-26 19:30 --- Fixed on trunk. I'll backport to 4.4. branch in a week. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Summary|gfortran ICE on invalid |[4.4] gfortran ICE on |program |invalid program http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39893
[Bug c/39917] New: tmpdir-gcc.dg-struct-layout-1/t008 c_compat_x_tst.o-c_compat_y_tst.o execute failure at -m64
The tmpdir-gcc.dg-struct-layout-1/t008 c_compat_x_tst.o-c_compat_y_tst.o
execute testcase fails at -m64 on powerpc-apple-darwin9. The offending section
of the testcase is the single line...
T(1234,double a;signed char atal16 b;union{unsigned int d;struct{}e;}c;short
int f;unsigned char
g;,F(1234,a,-125234.421875,-6063.015625)F(1234,b,-105,88)F(1234,c.d,3504478143U,3116938342U)F(1234,f,-15109,-23068)F(1234,g,236U,127U))
When this line is removed from the t008_test.h, the remainder of the test case
passes. I am attaching the preprocessed source and assembly files generated for
this test case compiled with the single line above using the commands...
/sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/
-I/sw/src/fink.build/gcc44-4.4.0-1000/gcc-4.4.0/gcc/testsuite/gcc.dg/compat
-fno-common -DSKIP_DECIMAL_FLOAT -c -m64 --save-temps -o c_compat_main_tst.
o
/sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/testsuite/gcc/gcc.dg-struct-layout-1/t008_main.c
/sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/ -w
-I/sw/src/fink.build/gcc44-4.4.0-1000/gcc-4.4.0/gcc/testsuite/gcc.dg/compat
-fno-common -DSKIP_DECIMAL_FLOAT -c -m64 --save-temps -o c_compat_x_tst.o
/sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/testsuite/gcc/gcc.dg-struct-layout-1//t008_x.c
/sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/ -w
-I/sw/src/fink.build/gcc44-4.4.0-1000/gcc-4.4.0/gcc/testsuite/gcc.dg/compat
-fno-common -DSKIP_DECIMAL_FLOAT -c -m64 --save-temps -o c_compat_y_tst.o
/sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/testsuite/gcc/gcc.dg-struct-layout-1//t008_y.c
/sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/ c_compat_main_tst.o
c_compat_x_tst.o c_compat_y_tst.o
-I/sw/src/fink.build/gcc44-4.4.0-1000/gcc-4.4.0/gcc/testsuite/gcc.dg/compat
-fno-common -lm -m64 -o tmpdir-gcc-dg-struct-layout-1-t008-01.exe
The compiler was built with the specs...
Using built-in specs.
Target: powerpc-apple-darwin9
Configured with: ../gcc-4.4.0/configure --prefix=/sw --prefix=/sw/lib/gcc4.4
--mandir=/sw/share/man --infodir=/sw/share/info
--enable-languages=c,c++,fortran,objc,java --with-gmp=/sw
--with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-system-zlib
--x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
--disable-libjava-multilib --build=powerpc-apple-darwin9
--host=powerpc-apple-darwin9 --target=powerpc-apple-darwin9
Thread model: posix
gcc version 4.4.0 (GCC)
--
Summary: tmpdir-gcc.dg-struct-layout-1/t008 c_compat_x_tst.o-
c_compat_y_tst.o execute failure at -m64
Product: gcc
Version: 4.4.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: powerpc-apple-darwin9
GCC host triplet: powerpc-apple-darwin9
GCC target triplet: powerpc-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39917
[Bug c/39917] tmpdir-gcc.dg-struct-layout-1/t008 c_compat_x_tst.o-c_compat_y_tst.o execute failure at -m64
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2009-04-26 19:35 --- Created an attachment (id=17730) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17730&action=view) preprocessed source for t008_x.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39917
