[Bug c/43845] New: Segfault when using __attribute__((const)), versions 4.4.3 and 4.6
I was playing around with __attribute__((const)), not realizing that what I actually should have used was __attribute__((pure)). But regardless of the fact that I was using these attributes incorrectly, gcc obviously shouldn't segfault. First comment will have the preprocessed source that generates this segfault. I tested gcc 4.4.3 and gcc 4.6 svn r158591. It probably crashes on all intermediate versions; I just didn't have them around to test. -- Summary: Segfault when using __attribute__((const)), versions 4.4.3 and 4.6 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: darkshikari at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43845
[Bug c/43845] Segfault when using __attribute__((const)), versions 4.4.3 and 4.6
--- Comment #1 from darkshikari at gmail dot com 2010-04-22 06:01 --- Created an attachment (id=20457) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20457action=view) Preprocessed source that produces the segfault -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43845
[Bug tree-optimization/43846] New: 4.5.0 regression, array vs members, dead code removal issues
Hello,
As instructed in http://gcc.gnu.org/ml/gcc/2010-04/msg00505.html i'm filing
this.
I've noticed gcc 4.5 has more trouble than it used to to removed dead stores
when dealing with arrays, as exemplified by
$ cat huh.cc
struct foo_t {
float x, y, z;
foo_t() {}
foo_t(float a, float b, float c) : x(a),y(b),z(c) {}
friend foo_t operator*(foo_t lhs, float s) { return foo_t(lhs.x*s,
lhs.y*s, lhs.z*s); }
friend float dot(foo_t lhs, foo_t rhs) { return lhs.x*rhs.x +
lhs.y*rhs.y + lhs.z*rhs.z; }
};
struct bar_t {
float m[3];
bar_t() {}
bar_t(float a, float b, float c) { m[0]=a; m[1]=b; m[2]=c; }
friend bar_t operator*(bar_t lhs, float s) { return bar_t(lhs.m[0]*s,
lhs.m[1]*s, lhs.m[2]*s); }
friend float dot(bar_t lhs, bar_t rhs) { return lhs.m[0]*rhs.m[0] +
lhs.m[1]*rhs.m[1] + lhs.m[2]*rhs.m[2]; }
};
namespace {
templatetypename T float magsqr(T v) { return dot(v, v); }
templatetypename T T norm(T v) { return
v*(1/__builtin_sqrtf(magsqr(v))); }
}
void frob1(const foo_t a, foo_t b) { b = norm(a); }
void frob2(const bar_t a, bar_t b) { b = norm(a); }
int main() { return 0; }
$ /usr/local/gcc-4.5.0/bin/g++ -O2 -ffast-math -march=native huh.cc
Whereas frob1 and frob2 do not differ with, say, gcc 4.4.1, they now do.
$ /usr/local/gcc-4.5.0/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/usr/local/gcc-4.5.0/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/gcc-4.5.0/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/usr/local/gcc-4.5.0
--enable-languages=c,c++ --enable-threads=posix --disable-checking
--disable-nls --with-system-zlib --disable-shared --enable-checking=none
--disable-bootstrap --enable-mpfr --enable-gold
Thread model: posix
gcc version 4.5.0 (GCC)
$ g++ -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.1-4ubuntu9'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--enable-multiarch --enable-linker-build-id --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --disable-werror
--with-arch-32=i486 --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu9)
--
Summary: 4.5.0 regression, array vs members, dead code removal
issues
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbptbp at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43846
[Bug c/43827] Intrinsic possibility: does not alias global data
--- Comment #6 from darkshikari at gmail dot com 2010-04-22 06:31 --- It seems that __attribute__((pure)) can already do this for many instances of this situation--but it doesn't work for function pointers. Is this an arbitrary limitation, or would serious work be necessary to make ((pure)) work for function pointers? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43827
[Bug libfortran/43844] open(unit, status=scratch) fails to create tempporary file
--- Comment #3 from burnus at gcc dot gnu dot org 2010-04-22 06:57 --- I also do not like: if (tempdir == NULL) tempdir = DEFAULT_TEMPDIR; /* This is /tmp. */ My feeling is that, e.g., on Windows this won't work; I do not know whether before the environment variables GFORTRAN_TMPDIR, TMP and TEMP are used or not, but /tmp does exist on many Windows systems. Kai, what's the best way to find out the temporary directory under Windows (MinGW/MinGW64/Cygwin)? And, do you see something obviously wrong with the code in comment 1 (alias http://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libgfortran/io/unix.c;hb=HEAD#l868 ) -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||ktietz at gcc dot gnu dot ||org, burnus at gcc dot gnu ||dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43844
[Bug rtl-optimization/43804] [4.5/4.6 regression] ICE in reload_cse_simplify_operands
--- Comment #8 from mkuvyrkov at gcc dot gnu dot org 2010-04-22 07:09 --- Subject: Re: [4.5/4.6 regression] ICE in reload_cse_simplify_operands On 4/22/10 3:40 AM, schwab at linux-m68k dot org wrote: --- Comment #7 from schwab at linux-m68k dot org 2010-04-21 23:40 --- I think 'T' should accept tls references like 's' does. Do you mean the following? == (define_constraint T Used for operands that satisfy 's' when -mpcrel is not in effect. (and (match_code symbol_ref,label_ref,const) (match_test !flag_pic || m68k_tls_reference_p (op, true == Yes, that should fix this particular problem, but one could equally successfully argue that T then should then accept usual PIC GOT references too. I just do not understand the background behind T constraint. Sigh. Maybe, it was introduced as an optimization to stop GCC from putting addresses (symbol_refs, etc) into data registers and then reloading them into address registers. Most probably, current GCC register allocator will do a just that without this kind of manual tweaking on the backend side. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43804
[Bug fortran/43841] Missing temporary for ELEMENTAL function call
--- Comment #3 from anlauf at gmx dot de 2010-04-22 07:27 --- (In reply to comment #2) PR43843 looks like a duplicate. It is. I simply reduced the program in the mail to a testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43841
[Bug tree-optimization/43845] [4.4/4.5 Regression] Segfault when using __attribute__((const)), versions 4.4.3 and 4.6
--- Comment #2 from falk at debian dot org 2010-04-22 07:35 ---
Confirmed on x86-64, already in 4.3, but not in 4.1. Here is a testcase that
gives an SSA verification error on 4.6 instead of segfaulting:
typedef int __attribute__ ((const)) (*x264_pixel_cmp_t)(void);
typedef struct {
x264_pixel_cmp_t ssd;
} x264_pixel_function_t;
int x264_pixel_ssd_wxh (x264_pixel_function_t *pf, int i_width) {
int i_ssd = 0, x;
for (x = 0; x i_width; x++)
i_ssd += pf-ssd();
return i_ssd;
}
% gcc -c -O3 -W -Wall mini.c
mini.c: In function x264_pixel_ssd_wxh:
mini.c:7:5: error: definition in block 3 does not dominate use in block 5
for SSA_NAME: D.2728_7 in statement:
D.2737_15 = D.2728_7 ();
mini.c:7:5: internal compiler error: verify_ssa failed
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
--
falk at debian dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|c |tree-optimization
Ever Confirmed|0 |1
Known to fail||4.1.3
Known to work||4.3.4 4.4.3 4.5.0 4.6.0
Summary|Segfault when using |[4.4/4.5 Regression]
|__attribute__((const)), |Segfault when using
|versions 4.4.3 and 4.6 |__attribute__((const)),
||versions 4.4.3 and 4.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43845
[Bug libfortran/43844] open(unit, status=scratch) fails to create tempporary file
--- Comment #4 from ktietz at gcc dot gnu dot org 2010-04-22 07:42 --- (In reply to comment #3) My feeling is that, e.g., on Windows this won't work; I do not know whether before the environment variables GFORTRAN_TMPDIR, TMP and TEMP are used or not, but /tmp does exist on many Windows systems. Kai, what's the best way to find out the temporary directory under Windows (MinGW/MinGW64/Cygwin)? And, do you see something obviously wrong with the code in comment 1 (alias http://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libgfortran/io/unix.c;hb=HEAD#l868 ) I would use here the platform API GetTempPath. This seems to be the best solution here. In general TEMP and/or TMP are defined in environment, but they need to be there defined. So This functions should do the proper thing for win32 targets (beside cygwin, as here /tmp/ is of course valid). Kai -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43844
[Bug c++/43818] internal compiler error: Segmentation fault
--- Comment #10 from oberlaender at fzi dot de 2010-04-22 07:47 --- (In reply to comment #9) I'm still thinking it's a problem with running out of memory, PAE doesn't increase the total memory available to a single process How would I find out if that is the issue? The numbers reported by my strace output seem harmless to me (but then I'm no expert with that tool). I'm going to try and compile a debug version of gcc-4.4.3. Will make STAGE2_CFLAGS=-g -O0 STAGE3_CFLAGS=-g -O0 all make install produce the result I'm looking for? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43818
[Bug c++/43818] internal compiler error: Segmentation fault
--- Comment #11 from oberlaender at fzi dot de 2010-04-22 07:59 --- Created an attachment (id=20458) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20458action=view) Output of strace -F -emmap2,mremap,brk,setrlimit g++ -c -O2 bugtest.ii Of course strace is pointless if I don't follow forks. This strace output follows cc1plus as well. It still looks harmless to me though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43818
[Bug libfortran/43844] open(unit, status=scratch) fails to create tempporary file
--- Comment #5 from burnus at gcc dot gnu dot org 2010-04-22 08:03 ---
(In reply to comment #3)
or not, but /tmp does exist on many Windows systems.
I wanted to write: does not.
(In reply to comment #4)
I would use here the platform API GetTempPath. This seems to be the best
solution here. In general TEMP and/or TMP are defined in environment, but they
need to be there defined.
I think Kai wanted to write: do _not_ need to.
GetTempPath:
http://msdn.microsoft.com/en-us/library/aa364992%28VS.85%29.aspx
with the example:
dwRetVal = GetTempPath(MAX_PATH, // length of the buffer
lpTempPathBuffer); // buffer for path
if (dwRetVal MAX_PATH || (dwRetVal == 0))
{
PrintError(TEXT(GetTempPath failed));
As GetTempPath also checks TMP and TEMP, one does not need to check for
TMP/TEMP before.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43844
[Bug fortran/43843] Wrong-code due to missing temporary with user-defined operatator
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-04-22 08:25 --- *** This bug has been marked as a duplicate of 43841 *** -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43843
[Bug fortran/43841] Missing temporary for ELEMENTAL function call
--- Comment #4 from dfranke at gcc dot gnu dot org 2010-04-22 08:25 --- *** Bug 43843 has been marked as a duplicate of this bug. *** -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43841
[Bug fortran/43841] Missing temporary for ELEMENTAL function call
--- Comment #5 from burnus at gcc dot gnu dot org 2010-04-22 08:28 ---
From PR 43843:
Reported by Kyle Horne at http://gcc.gnu.org/ml/fortran/2010-04/msg00215.html
There is a missing temporary for user-defined operators:
type(polar_t),dimension(3)::b
b = polar_t(1.0,0.5)
b(:) = b(:)/b(1)
The latter is translated into:
struct polar_t * D.1551;
D.1551 = b[0];
S.5 = 1;
while (1)
{
if (S.5 3) goto L.3;
b[S.5 + -1] = div_pp (b[S.5 + -1], D.1551);
S.5 = S.5 + 1;
}
L.3:;
but that fails as one overrides *D.1551 alias b[0] alias B(1) in the first
iteration instead of evaluating first all of the RHS before assigning to the
LHS.
Work with ifort and NAG, fails with GCC 4.1, 4.2, 4.3, 4.4, 4.5, and 4.6
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
CC||pault at gcc dot gnu dot org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2010-04-22 08:28:12
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43841
[Bug c++/43818] internal compiler error: Segmentation fault
--- Comment #12 from oberlaender at fzi dot de 2010-04-22 08:31 --- (From update of attachment 20443) Use a better MIME type. -- oberlaender at fzi dot de changed: What|Removed |Added Attachment #20443|application/postscript |application/octet-stream mime type|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43818
[Bug fortran/43829] Scalarization of reductions
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-04-22 08:34 --- Subject: Bug 43829 Author: rguenth Date: Thu Apr 22 08:34:41 2010 New Revision: 158632 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158632 Log: 2010-04-22 Richard Guenther rguent...@suse.de PR fortran/43829 * resolve.c (gfc_resolve_index): Wrap around ... (gfc_resolve_index_1): ... this. Add parameter to allow any integer kind index type. (resolve_array_ref): Allow any integer kind for the start index of an array ref. * gfortran.dg/vector_subscript_6.f90: New testcase. * gfortran.dg/assign_10.f90: Adjust. Added: trunk/gcc/testsuite/gfortran.dg/vector_subscript_6.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/assign_10.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43829
[Bug tree-optimization/43842] [4.6 Regression] ice in vect_create_epilog_for_reduction
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-04-22 08:51 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||irar at gcc dot gnu dot org, ||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to work||4.5.0 Last reconfirmed|-00-00 00:00:00 |2010-04-22 08:51:50 date|| Summary|ice in |[4.6 Regression] ice in |vect_create_epilog_for_reduc|vect_create_epilog_for_reduc |tion|tion Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43842
[Bug other/43847] New: gcc_cv_objdump pointing to wrong one in gcc/configure
The code in 'gcc-4.5.0/gcc/configure' :
clip ---
pluginlibs=
if test x$enable_plugin = xyes; then
{ $as_echo $as_me:${as_lineno-$LINENO}: checking for exported symbols 5
$as_echo_n checking for exported symbols... 6; }
echo int main() {return 0;} int foobar() {return 0;} conftest.c
${CC} ${CFLAGS} ${LDFLAGS} conftest.c -o conftest /dev/null 21
if $gcc_cv_objdump -T conftest | grep foobar /dev/null; then
: # No need to use a flag
else
{ $as_echo $as_me:${as_lineno-$LINENO}: checking for -rdynamic 5
$as_echo_n checking for -rdynamic... 6; }
${CC} ${CFLAGS} ${LDFLAGS} -rdynamic conftest.c -o conftest /dev/null
21
if $gcc_cv_objdump -T conftest | grep foobar /dev/null; then
pluginlibs=-rdynamic
else
enable_plugin=no
fi
fi
clip ---
will cause an error when the $target-objdump doesn't understand the $host
binaries like :
clip ---
Links are now set up to build a cross-compiler
from x86_64-unknown-linux-gnu to arm-unknown-elf.
checking for exported symbols...
/usr/local/cross-gcc-arm-elf-4.5.0/arm-elf/bin/objdump:
conftest: File format not recognized
checking for -rdynamic...
/usr/local/cross-gcc-arm-elf-4.5.0/arm-elf/bin/objdump:
conftest: File format not recognized
clip ---
The host GCC (CC) compiles and links a program and then the executable
will be looked with 'objdump' ($gcc_cv_objdump). But the latter is now
pointing to the target one!
--
Summary: gcc_cv_objdump pointing to wrong one in gcc/configure
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kai dot ruottu at wippies dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43847
[Bug tree-optimization/43846] [4.5 Regression] array vs members, total scalarization issues
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-04-22 09:07 --- Hm, frob1 looks like _Z5frob1RK5foo_tRS_: .LFB18: movss (%rdi), %xmm3 movss 4(%rdi), %xmm2 movaps %xmm3, %xmm4 movaps %xmm2, %xmm0 mulss %xmm3, %xmm4 movss 8(%rdi), %xmm1 mulss %xmm2, %xmm0 addss %xmm4, %xmm0 movaps %xmm1, %xmm4 mulss %xmm1, %xmm4 addss %xmm4, %xmm0 rsqrtss %xmm0, %xmm4 mulss %xmm4, %xmm0 mulss %xmm4, %xmm0 mulss .LC1(%rip), %xmm4 addss .LC0(%rip), %xmm0 mulss %xmm4, %xmm0 mulss %xmm0, %xmm3 mulss %xmm0, %xmm2 mulss %xmm1, %xmm0 movss %xmm3, (%rsi) movss %xmm2, 4(%rsi) movss %xmm0, 8(%rsi) ret and frob2 like _Z5frob2RK5bar_tRS_: .LFB19: movss (%rdi), %xmm3 movss 4(%rdi), %xmm2 movaps %xmm3, %xmm4 movaps %xmm2, %xmm0 mulss %xmm3, %xmm4 movss 8(%rdi), %xmm1 mulss %xmm2, %xmm0 addss %xmm4, %xmm0 movaps %xmm1, %xmm4 mulss %xmm1, %xmm4 addss %xmm4, %xmm0 rsqrtss %xmm0, %xmm4 mulss %xmm4, %xmm0 mulss %xmm4, %xmm0 mulss .LC1(%rip), %xmm4 addss .LC0(%rip), %xmm0 mulss %xmm4, %xmm0 mulss %xmm0, %xmm3 mulss %xmm0, %xmm2 mulss %xmm1, %xmm0 movss %xmm3, -24(%rsp) movss %xmm2, -20(%rsp) movq-24(%rsp), %rax movss %xmm0, -16(%rsp) movq%rax, (%rsi) movl-16(%rsp), %eax movl%eax, 8(%rsi) ret so it's an aggregate copy that is not scalarized in frob2: b_1(D)-x = D.2444_20; b_1(D)-y = D.2443_19; b_1(D)-z = D.2442_18; return; vs. D.2464.m[0] = D.2473_20; D.2464.m[1] = D.2472_19; D.2464.m[2] = D.2471_18; *b_1(D) = D.2464; return; all inlining happens during early inlining and frob1 and frob2 are reasonably similar after early inlining. But then we have early SRA which does ;; Function void frob1(const foo_t, foo_t) (_Z5frob1RK5foo_tRS_) Candidate (2452): D.2452 Candidate (2434): v Candidate (2435): D.2435 Will attempt to totally scalarize D.2435 (UID: 2435): Will attempt to totally scalarize D.2452 (UID: 2452): Marking v offset: 0, size: 32: to be replaced. Marking v offset: 32, size: 32: to be replaced. Marking v offset: 64, size: 32: to be replaced. ... ;; Function void frob2(const bar_t, bar_t) (_Z5frob2RK5bar_tRS_) Candidate (2481): D.2481 Candidate (2464): D.2464 Candidate (2463): v Marking v offset: 0, size: 32: to be replaced. Marking v offset: 32, size: 32: to be replaced. Marking v offset: 64, size: 32: to be replaced. ... ! Disqualifying D.2464 - No scalar replacements to be created. so it doesn't consider the struct with the array for total scalarization for some reason. Martin? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||jamborm at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-04-22 09:07:40 date|| Summary|4.5.0 regression, array vs |[4.5 Regression] array vs |members, dead code removal |members, total scalarization |issues |issues Target Milestone|--- |4.5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43846
[Bug c++/43818] internal compiler error: Segmentation fault
--- Comment #13 from oberlaender at fzi dot de 2010-04-22 09:13 --- Created an attachment (id=20459) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20459action=view) Output from a gdb session on g++-4.4.3 OK, almost right. I created a debug build for gcc-4.4.3: $ g++-4.4.3 -v Using built-in specs. Target: i486-linux-gnu Configured with: ../gcc-4.4.3/configure --prefix=/home/oberlaen/local/stow/gcc-4.4.3/ --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++ --enable-shared --disable-multiarch --enable-linker-build-id --with-system-zlib --without-included-gettext --enable-threads=posix --program-suffix=-4.4.3 --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-targets=all --disable-multilib --disable-werror --with-arch-32=i486 --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.4.3 (GCC) I built with make CFLAGS=-g -O0 CXXFLAGS=-g -O0 STAGE2_CFLAGS=-g -O0 STAGE3_CFLAGS=-g -O0 I then ran g++-4.4.3 -save-temps -o bugtest.out -c -O2 bugtest.ii and extracted the cc1plus command line through strace. The attachment contains the results from a gdb run on cc1plus -fpreprocessed bugtest.ii -quiet -dumpbase bugtest.ii -mtune=generic -march=i486 -auxbase bugtest -O2 -o bugtest.s Hope this tells you something. Please tell me if I can get you any more info. Best regards, Jan -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43818
[Bug tree-optimization/43845] [4.4/4.5 Regression] Segfault when using __attribute__((const)), versions 4.4.3 and 4.6
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-04-22 09:13 --- Confirmed. It's (partial-)PRE, all branches have the verification error, 4.3 works ok. Mine. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Keywords||ice-on-valid-code Known to fail|4.1.3 |4.4.3 4.5.0 4.6.0 Known to work|4.3.4 4.4.3 4.5.0 4.6.0 |4.3.4 Last reconfirmed|-00-00 00:00:00 |2010-04-22 09:13:57 date|| Target Milestone|--- |4.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43845
[Bug c++/43818] internal compiler error: Segmentation fault
--- Comment #14 from oberlaender at fzi dot de 2010-04-22 09:19 --- (In reply to comment #13) Oh, and another thing: at the moment of the segfault, memory usage says $ ps v -C cc1plus PID TTY STAT TIME MAJFL TRS DRS RSS %MEM COMMAND 19072 pts/2T 0:00 0 10015 36428 34760 0.8 cc1plus... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43818
[Bug rtl-optimization/43804] [4.5/4.6 regression] ICE in reload_cse_simplify_operands
--- Comment #9 from schwab at linux-m68k dot org 2010-04-22 09:20 --- Probably the author of T didn't realise that !-mpcrel in (!-mpcrel 's') is already implied. It is already a no-op in the -mpcrel case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43804
[Bug libfortran/43844] open(unit, status=scratch) fails to create tempporary file
--- Comment #6 from burnus at gcc dot gnu dot org 2010-04-22 09:21 --- Created an attachment (id=20460) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20460action=view) Draft patch for GetTempPath; fix for mktemp (In reply to comment #2) The if and do .. while block may execute mktemp more than once. ?? I think the idea is: If a file has been created between calling mktemp and calling open (race condition), it tries again with a new file name. I think that part looks - in principle - fine. * * * Kai has found the issue: while (!(fd == -1 errno == EEXIST) mktemp (template)); The NOT (!) is wrong - the condition should be: while (fd == -1 errno == EEXIST mktemp (template)); This should be checked into 4.4/4.5/4.6. * * * Additionally, I tried to get GetTempPath working, but that draft might not even compile. That would be for 4.6 only. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43844
[Bug libfortran/43844] open(unit, status=scratch) fails to create tempporary file
--- Comment #7 from burnus at gcc dot gnu dot org 2010-04-22 09:25 --- Side note: template = get_mem (strlen (tempdir) + 20); Can one change the 20 into 19 or 18 + 1 ? The string /gfortrantmpXX has 18 characters and '\0' has one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43844
[Bug middle-end/29274] [4.3/4.4/4.5/4.6 Regression] not using mulsidi3
--- Comment #11 from bernds at gcc dot gnu dot org 2010-04-22 09:31 --- Subject: Bug 29274 Author: bernds Date: Thu Apr 22 09:30:27 2010 New Revision: 158633 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158633 Log: gcc/ PR middle-end/29274 * optabs.h (expand_widening_mult): Declare. * tree-pass.h (pass_optimize_widening_mul): Declare. * tree-ssa-math-opts.c (execute_optimize_widening_mul, gate_optimize_widening_mul): New static functions. (pass_optimize_widening_mul): New. * expr.c (expand_expr_real_2) case WIDEN_MULT_EXPR: New case. case MULT_EXPR: Remove support for widening multiplies. * tree.def (WIDEN_MULT_EXPR): Tweak comment. * cfgexpand.c (expand_debug_expr) case WIDEN_MULT_EXPR: Use simplify_gen_unary rather than directly building extensions. * tree-cfg.c (verify_gimple_assign_binary): Add tests for WIDEN_MULT_EXPR. * expmed.c (expand_widening_mult): New function. * passes.c (init_optimization_passes): Add pass_optimize_widening_mul. gcc/testsuite/ PR middle-end/29274 * gcc.target/i386/wmul-1.c: New test. * gcc.target/i386/wmul-2.c: New test. * gcc.target/bfin/wmul-1.c: New test. * gcc.target/bfin/wmul-2.c: New test. Added: trunk/gcc/testsuite/gcc.target/bfin/wmul-1.c trunk/gcc/testsuite/gcc.target/bfin/wmul-2.c trunk/gcc/testsuite/gcc.target/i386/wmul-1.c trunk/gcc/testsuite/gcc.target/i386/wmul-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/cfgexpand.c trunk/gcc/expmed.c trunk/gcc/expr.c trunk/gcc/passes.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-cfg.c trunk/gcc/tree-pass.h trunk/gcc/tree-ssa-math-opts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29274
[Bug fortran/43836] [4.4 Regression] ice with -fexceptions and -fopenmp
--- Comment #7 from jakub at gcc dot gnu dot org 2010-04-22 09:39 --- Fixed for 4.4.4/4.5.1/4.6.0. -- 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=43836
[Bug target/43662] [4.4/4.5/4.6 Regression] ICE in insert_save with ms_abi attribute
--- Comment #16 from jakub at gcc dot gnu dot org 2010-04-22 09:43 --- 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=43662
[Bug target/42498] GCC can't use smull to compute int * int -- long long
--- Comment #4 from bernds at codesourcery dot com 2010-04-22 10:01 --- Fixed now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42498
[Bug middle-end/29274] [4.3/4.4/4.5 Regression] not using mulsidi3
--- Comment #12 from rguenth at gcc dot gnu dot org 2010-04-22 10:11 --- Fixed for 4.6. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to work|3.4.2 |3.4.2 4.6.0 Summary|[4.3/4.4/4.5/4.6 Regression]|[4.3/4.4/4.5 Regression] not |not using mulsidi3 |using mulsidi3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29274
[Bug c++/43818] internal compiler error: Segmentation fault
--- Comment #15 from redi at gcc dot gnu dot org 2010-04-22 10:50 --- Thanks for the extra info - I can't reproduce it, but I can't test on a real 32bit host. In the absence of any suggestions from anyone else, could you try reconfiguring with --enable-checking=all instead of --enable-checking=release ? That will enable some internal consistency checks, which make the compiler slower but might reveal where it's going wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43818
[Bug tree-optimization/43845] [4.4/4.5 Regression] Segfault when using __attribute__((const)), versions 4.4.3 and 4.6
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-04-22 11:20 --- Subject: Bug 43845 Author: rguenth Date: Thu Apr 22 11:19:45 2010 New Revision: 158641 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158641 Log: 2010-04-22 Richard Guenther rguent...@suse.de PR tree-optimization/43845 * tree-ssa-pre.c (create_component_ref_by_pieces_1): Properly lookup the CALL_EXPR function and arguments. * gcc.c-torture/compile/pr43845.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr43845.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-pre.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43845
[Bug tree-optimization/43845] [4.4/4.5 Regression] Segfault when using __attribute__((const)), versions 4.4.3 and 4.6
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-04-22 11:20 --- Fixed on the trunk. Backports pending testing. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.4.3 4.5.0 4.6.0 |4.4.3 4.5.0 Known to work|4.3.4 |4.3.4 4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43845
[Bug c++/43818] internal compiler error: Segmentation fault
--- Comment #16 from rguenth at gcc dot gnu dot org 2010-04-22 11:25 --- This has been fixed on the 4.4 branch, I can reproduce it with 4.4.3. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to fail||4.4.3 Known to work||4.3.4 4.4.4 4.5.0 Resolution||FIXED Target Milestone|--- |4.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43818
[Bug middle-end/29274] [4.3/4.4/4.5 Regression] not using mulsidi3
--- Comment #13 from bernds at gcc dot gnu dot org 2010-04-22 11:26 --- Subject: Bug 29274 Author: bernds Date: Thu Apr 22 11:25:44 2010 New Revision: 158642 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158642 Log: PR middle-end/29274 * gcc.target/arm/wmul-1.c: New test. * gcc.target/arm/wmul-2.c: New test. Added: trunk/gcc/testsuite/gcc.target/arm/wmul-1.c trunk/gcc/testsuite/gcc.target/arm/wmul-2.c Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29274
[Bug tree-optimization/43848] New: [4.6 Regression]: can
With revision @Y@ this test passed. From revision @Z@ and on, this test has failed as follows: @V@ With the message in the logfile being: @U@ @A@@C@ aut...@w@ of patches in suspect revision range CC:ed. -- Summary: [4.6 Regression]: can Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hp at gcc dot gnu dot org GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: cris-axis-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43848
[Bug middle-end/43848] [4.6 Regression]: can't build libgcc for cris-elf with r158633
--- Comment #1 from hp at gcc dot gnu dot org 2010-04-22 11:42 --- (oops, fat-fingered the return key before filling in details properly in my bug-template) With r158630, libgcc, built. With r158633 and on, including 158639, I see: /tmp/hpautotest-gcc1/cris-elf/gccobj/./gcc/xgcc -B/tmp/hpautotest-gcc1/cris-elf/gccobj/./gcc/ -nostdinc -B/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/newlib/ -isystem /tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/newlib/targ-include -isystem /tmp/hpautotest-gcc1/gcc/newlib/libc/include -B/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/libgloss/cris -L/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/libgloss/libnosys -L/tmp/hpautotest-gcc1/gcc/libgloss/cris -B/tmp/hpautotest-gcc1/cris-elf/pre/cris-elf/bin/ -B/tmp/hpautotest-gcc1/cris-elf/pre/cris-elf/lib/ -isystem /tmp/hpautotest-gcc1/cris-elf/pre/cris-elf/include -isystem /tmp/hpautotest-gcc1/cris-elf/pre/cris-elf/sys-include-g -O2 -march=v10 -mbest-lib-options -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../.././gcc -I/tmp/hpautotest-gcc1/gcc/libgcc -I/tmp/hpautotest-gcc1/gcc/libgcc/. -I/tmp/hpautotest-gcc1/gcc/libgcc/../gcc -I/tmp/hpautotest-gcc1/gcc/libgcc/../include -DHAVE_CC_TLS -DUSE_EMUTLS -o _mulvsi3.o -MT _mulvsi3.o -MD -MP -MF _mulvsi3.dep -DL_mulvsi3 -c /tmp/hpautotest-gcc1/gcc/libgcc/../gcc/libgcc2.c \ /tmp/hpautotest-gcc1/gcc/libgcc/../gcc/libgcc2.c: In function '__mulvsi3': /tmp/hpautotest-gcc1/gcc/libgcc/../gcc/libgcc2.c:159:16: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[4]: *** [_mulvsi3.o] Error 1 make[4]: Leaving directory `/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/v10/libgcc' Author of applicable ChangeLog entry in this range CC:ed. Will attach libgcc.i momentarily. -- hp at gcc dot gnu dot org changed: What|Removed |Added CC||bernds at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Component|tree-optimization |middle-end Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-04-22 11:42:48 date|| Summary|[4.6 Regression]: can |[4.6 Regression]: can't ||build libgcc for cris-elf ||with r158633 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43848
[Bug tree-optimization/43842] [4.6 Regression] ice in vect_create_epilog_for_reduction
-- irar at il dot ibm dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |irar at il dot ibm dot com |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-04-22 08:51:50 |2010-04-22 11:46:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43842
[Bug middle-end/43848] [4.6 Regression]: can't build libgcc for cris-elf with r158633
--- Comment #2 from dominiq at lps dot ens dot fr 2010-04-22 11:51 --- Same thing on x86_64-apple-darwin10: bootstrap fails at revision 158642 with ... /opt/gcc/p_build/./gcc/xgcc -B/opt/gcc/p_build/./gcc/ -B/opt/gcc/gcc4.6p/x86_64-apple-darwin10/bin/ -B/opt/gcc/gcc4.6p/x86_64-apple-darwin10/lib/ -isystem /opt/gcc/gcc4.6p/x86_64-apple-darwin10/include -isystem /opt/gcc/gcc4.6p/x86_64-apple-darwin10/sys-include-g -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -pipe -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../.././gcc -I../../../p_work/libgcc -I../../../p_work/libgcc/. -I../../../p_work/libgcc/../gcc -I../../../p_work/libgcc/../include -DHAVE_CC_TLS -DUSE_EMUTLS -o __main_s.o -MT __main_s.o -MD -MP -MF __main_s.dep -DSHARED -DL__main -c ../../../p_work/libgcc/../gcc/libgcc2.c ../../../../p_work/libgcc/../gcc/libgcc2.c: In function '__mulvsi3': ../../../../p_work/libgcc/../gcc/libgcc2.c:159:16: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[5]: *** [_mulvsi3.o] Error 1 make[4]: *** [multi-do] Error 1 make[3]: *** [all-multi] Error 2 make[3]: *** Waiting for unfinished jobs make[2]: *** [all-stage1-target-libgcc] Error 2 make[1]: *** [stage1-bubble] Error 2 make: *** [all] Error 2 Note bootstrap failures on other platforms: http://gcc.gnu.org/ml/gcc-regression/2010-04/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43848
[Bug middle-end/43848] [4.6 Regression]: can't build libgcc for cris-elf with r158633
--- Comment #3 from hp at gcc dot gnu dot org 2010-04-22 11:58 --- Created an attachment (id=20461) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20461action=view) preprocessed libgcc2.i Reproduce using r158642 with ./cc1 -fpreprocessed libgcc2.i -march=v10 -O2 -o libgcc2x.s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43848
[Bug middle-end/43848] [4.6 Regression]: can't build libgcc for cris-elf with r158633
--- Comment #4 from bernds at codesourcery dot com 2010-04-22 12:02 --- I somehow managed not to check in the optabs.h change in the first commit. Can you try again with r158643? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43848
[Bug target/43597] Move and compare with 0 can be combined
--- Comment #7 from carrot at google dot com 2010-04-22 12:26 ---
(In reply to comment #6)
I can't see how it would hurt to allow combine to always merge insns that are
known to be consecutive (ie to ignore CLASS_LIKELY_SPILLED_P if
prev_nonenote_insn(consumer) == producer).
I implemented the following patch
Index: combine.c
===
--- combine.c (revision 158539)
+++ combine.c (working copy)
@@ -384,6 +384,7 @@ static void do_SUBST_INT (int *, int);
static void init_reg_last (void);
static void setup_incoming_promotions (rtx);
static void set_nonzero_bits_and_sign_copies (rtx, const_rtx, void *);
+static bool reg_likely_spilled_p (rtx, rtx, bool);
static int cant_combine_insn_p (rtx);
static int can_combine_p (rtx, rtx, rtx, rtx, rtx *, rtx *);
static int combinable_i3pat (rtx, rtx *, rtx, rtx, int, rtx *);
@@ -1987,6 +1988,22 @@ contains_muldiv (rtx x)
}
}
+
+static bool
+reg_likely_spilled_p (rtx insn, rtx reg, bool reg_set)
+{
+ unsigned regno = REGNO (reg);
+ if (!reg_set)
+{
+ rtx prev_insn = prev_nonnote_insn_bb (insn);
+ if ((prev_insn != NULL_RTX) df_reg_defined (prev_insn, reg))
+return false;
+}
+
+ return ((regno FIRST_PSEUDO_REGISTER) !fixed_regs[regno]
+ CLASS_LIKELY_SPILLED_P (REGNO_REG_CLASS (regno)));
+}
+
/* Determine whether INSN can be used in a combination. Return nonzero if
not. This is used in try_combine to detect early some cases where we
can't perform combinations. */
@@ -2020,12 +2037,8 @@ cant_combine_insn_p (rtx insn)
if (GET_CODE (dest) == SUBREG)
dest = SUBREG_REG (dest);
if (REG_P (src) REG_P (dest)
- ((REGNO (src) FIRST_PSEUDO_REGISTER
- ! fixed_regs[REGNO (src)]
- CLASS_LIKELY_SPILLED_P (REGNO_REG_CLASS (REGNO (src
- || (REGNO (dest) FIRST_PSEUDO_REGISTER
- ! fixed_regs[REGNO (dest)]
- CLASS_LIKELY_SPILLED_P (REGNO_REG_CLASS (REGNO (dest))
+ (reg_likely_spilled_p (insn, src, false)
+ || reg_likely_spilled_p (insn, dest, true)))
return 1;
return 0;
It can indeed combine the mov and cmp instructions. But it causes an x86
failure. Compile the following code with options -march=x86-64 -O2
extern long xxx (long);
int
gen_type (long x, long y)
{
int size = (xxx (x) / xxx (y));
return size;
}
GCC generates:
c-aux-info.i:7:1: error: unable to find a register to spill in class 'AREG'
c-aux-info.i:7:1: error: this is the insn:
(insn 13 12 19 2 c-aux-info.i:5 (parallel [
(set (reg:DI 0 ax [67])
(div:DI (reg:DI 3 bx [orig:58 D.2722 ] [58])
(reg:DI 0 ax)))
(set (reg:DI 1 dx [68])
(mod:DI (reg:DI 3 bx [orig:58 D.2722 ] [58])
(reg:DI 0 ax)))
(clobber (reg:CC 17 flags))
]) 353 {*divmoddi4} (expr_list:REG_DEAD (reg:DI 3 bx [orig:58 D.2722 ]
[58])
(expr_list:REG_DEAD (reg:DI 0 ax)
(expr_list:REG_UNUSED (reg:DI 1 dx [68])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil))
c-aux-info.i:7:1: internal compiler error: in spill_failure, at reload1.c:2158
The root cause is with this patch, the original code sequence
(insn 12 11 13 2 c-aux-info.i:5 (set (reg:DI 59 [ D.2723 ])
(reg:DI 0 ax)) 89 {*movdi_1_rex64} (expr_list:REG_DEAD (reg:DI 0 ax)
(nil)))
(insn 13 12 19 2 c-aux-info.i:5 (parallel [
(set (reg:DI 67)
(div:DI (reg:DI 58 [ D.2722 ])
(reg:DI 59 [ D.2723 ])))
(set (reg:DI 68)
(mod:DI (reg:DI 58 [ D.2722 ])
(reg:DI 59 [ D.2723 ])))
(clobber (reg:CC 17 flags))
]) 353 {*divmoddi4} (expr_list:REG_DEAD (reg:DI 59 [ D.2723 ])
(expr_list:REG_DEAD (reg:DI 58 [ D.2722 ])
(expr_list:REG_UNUSED (reg:DI 68)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil))
is merged into
(insn 13 12 19 2 c-aux-info.i:5 (parallel [
(set (reg:DI 67)
(div:DI (reg:DI 58 [ D.2722 ])
(reg:DI 0 ax)))
(set (reg:DI 68)
(mod:DI (reg:DI 58 [ D.2722 ])
(reg:DI 0 ax)))
(clobber (reg:CC 17 flags))
]) 353 {*divmoddi4} (expr_list:REG_DEAD (reg:DI 0 ax)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_UNUSED (reg:DI 68)
(expr_list:REG_DEAD (reg:DI 58 [ D.2722 ])
(nil))
and it failed in register allocation.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43597
[Bug tree-optimization/43846] [4.5 Regression] array vs members, total scalarization issues
--- Comment #2 from jamborm at gcc dot gnu dot org 2010-04-22 12:35 --- (In reply to comment #1) so it doesn't consider the struct with the array for total scalarization for some reason. Martin? Well, that was a deliberate decision when fixing PR 42585 (see type_consists_of_records_p). The code is simpler because it does not have to know how to iterate over the array index domain. Of course, we can alleviate this restriction and learn how to iterate. However, all the accesses for the whole array are already created, that is not the issue. The problem basically is that when we see the sequence D.2035.m[0] = D.2044_20; D.2035.m[1] = D.2043_19; D.2035.m[2] = D.2042_18; *b_1(D) = D.2035; (and there are no other accesses to D.2035) the condition that tries to prevent us from creating unnecessary replacements kicks in and we decide not to scalarize. The intent of the current code (possibly among other reasons) was to avoid going through a replacement when the whole structure was then passed as an argument to a function and similar situations. But it should not be very difficult to change the condition (in analyze_access_subtree) to handle both situations right. Doing this, rather than total scalarization for arrays (which should be only useful as a substitute for a copy propagation) should enable us to handle even huge arrays. I'll get to this right after dealing with PR 43835. -- jamborm at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jamborm at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-04-22 09:07:40 |2010-04-22 12:35:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43846
[Bug middle-end/43848] [4.6 Regression]: can't build libgcc for cris-elf with r158633
--- Comment #5 from hp at gcc dot gnu dot org 2010-04-22 12:38 --- I'd expect a missing prototype to cause a -Werror breakage rather than the built cc1 to ICE, but there you go; that did it. Closing as libgcc for cris-elf now builds, thanks for the quick turnaround. -- hp at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43848
[Bug fortran/43849] New: Add _gfortran_finalize function to close down the library
Currently, gfortran only has start up routines, cf. http://gcc.gnu.org/onlinedocs/gfortran/Non_002dFortran-Main-Program.html I think it makes sense to also add shutdown routines. Currently, _gfortran_abort calls: close_units (); Additionally, one should call: flush_all_units (); For some reasons _gfortran_exit_i(4,8) does not. And, I think it would make sense to call the unit flushing (via the shutdown routine) also for STOP and when leaving the main program. And non-Fortran main programs should do the same (cf. link above). The (externally visible) shutdown routine shall return and leave the exiting of the program to the caller. -- Summary: Add _gfortran_finalize function to close down the library Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43849
[Bug lto/43850] New: ice: tree code �template_type_parm� is not supported in gimple streams
ma...@pc-31c:~/Hmfe/Fields2 gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/home/marco/local/gcc-4.5.0/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../configure --enable-threads=posix --prefix=/home/marco/local/gcc-4.5.0 --enable-shared --enable-__cxa_atexit --enable-libstdcxx-allocator=new --with-cpu=opteron --enable-languages=c,c++,fortran --with-mpfr=/home/marco/local/mpfr-2.4.2 --with-mpc=/home/marco/local/mpc-0.8.1 --enable-gold --enable-lto Thread model: posix gcc version 4.5.0 (GCC) Error: ma...@pc-31c:~/Hmfe/Fields2 g++ -c -flto Tensor1st.ii /home/marco/Hmfe/HelMo/Src/GeoMathLib/Tensor1st.C:233:2: internal compiler error: tree code template_type_parm is not supported in gimple streams -- Summary: ice: tree code template_type_parm is not supported in gimple streams Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: morandini at aero dot polimi dot it 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=43850
[Bug lto/43850] ice: tree code �template_type_parm� is not supported in gimple streams
--- Comment #1 from morandini at aero dot polimi dot it 2010-04-22 12:55 --- Created an attachment (id=20462) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20462action=view) preprocessed file triggering the bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43850
[Bug ada/33420] Assert_Failure at atree.adb:886 on function call
--- Comment #8 from jdgressett at hotmail dot com 2010-04-22 12:56 --- This seems to be fixed in gcc 4.5.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33420
[Bug c++/26256] ignores using declaration
--- Comment #2 from fabien dot chene at gmail dot com 2010-04-22 13:16 --- Mine... -- fabien dot chene at gmail dot com changed: What|Removed |Added CC||fabien dot chene at gmail ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26256
[Bug fortran/43849] Add _gfortran_finalize function to close down the library
--- Comment #1 from burnus at gcc dot gnu dot org 2010-04-22 13:19 --- Thus: a) Create a function named, e.g., _gfortran_shutdown/_gfortran_finalize, which calls flush_all_units (); close_units (); b) Call it from: _gfortran_abort _gfortran_stop_numeric; _gfortran_stop_string; _gfortran_error_stop_string _gfortran_error_stop_numeric (not yet existing) and maybe from the run-time error calls such as _gfortran_runtime_error _gfortran_runtime_error_at c) Change trans-decl.c's create_main_function to call it d) Update gfortran.texi e) Add a call to the gfortran CAF library for ERROR STOP -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43849
[Bug fortran/43851] New: Add _gfortran_error_stop_numeric
There are two STOP statements in Fortran: STOP constant default-integer-expr or constant string-expr ERROR STOP constant default-integer-expr or constant string-expr The first one is for normal stopping of the program, the second one for error abort. This works in so far that ERROR STOP string returns a non-zero exit status code and STOP string returns zero. (The numeric version returns the number.) However, the text output is different. For string one gets: STOP my string ERROR STOP my string but for numeric output one just gets STOP 1 i.e. always STOP and never ERROR STOP. The reason is that a _gfortran_error_stop_numeric function is missing. -- Summary: Add _gfortran_error_stop_numeric Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43851
[Bug fortran/43849] Add _gfortran_finalize function to close down the library
--- Comment #2 from burnus at gcc dot gnu dot org 2010-04-22 13:29 --- Forgot to mention that one can then also print the exception status: 8.4 STOP and ERROR STOP statements (F2008 FDIS): If any exception (cf. 14 Exceptions and IEEE arithmetic) is signaling on that image, the processor shall issue a warning indicating which exceptions are signaling; this warning shall be on the unit identified by the named constant ERROR_UNIT (13.8.2.8). It is recommended that the stop code is made available by formatted output to the same unit. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43849
[Bug fortran/43851] Add _gfortran_error_stop_numeric
--- Comment #1 from burnus at gcc dot gnu dot org 2010-04-22 13:30 --- Additionally, the (ERROR) STOP output should be printed to STDERR and not to STDOUT per: 8.4 STOP and ERROR STOP statements (F2008 FDIS): If any exception (cf. 14 Exceptions and IEEE arithmetic) is signaling on that image, the processor shall issue a warning indicating which exceptions are signaling; this warning shall be on the unit identified by the named constant ERROR_UNIT (13.8.2.8). It is recommended that the stop code is made available by formatted output to the same unit. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43851
[Bug middle-end/43740] [4.5/4.6 Regression] FAIL: gcc.dg/tree-ssa/20031015-1.c (internal compiler error)
--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2010-04-22 13:42 --- Subject: Re: [4.5/4.6 Regression] FAIL: gcc.dg/tree-ssa/20031015-1.c (internal compiler error) The same failures are present on trunk with --enable-checking=release. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43740
[Bug libfortran/43844] open(unit, status=scratch) fails to create tempporary file
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2010-04-22 13:52 --- I will fix all this on trunk tonight and if we get good test results I will port it back. Thanks Kai. My eye was telling me something was not right there. Thanks Tobias too. I have a mingw build mostly working, so I may even be able to test this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43844
[Bug fortran/43829] Scalarization of reductions
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-04-22 14:00 --- Now onto subroutine test1(esss,Ix,Iyz) real(kind=kind(1.0d0)), dimension(:), intent(out) :: esss real(kind=kind(1.0d0)), dimension(:,:) :: Ix,Iyz esss = sum(Ix * Iyz, 1) end subroutine noting that we can exchange the sum and the indexing of the assignment making the sum() of rank one (and thus eligible for inline expansion). Thus, expand it as do i=1,size(esss) esss(i) = sum(Ix(i,:) * Iyz(i,:)) end do An even simpler testcase where we want to do this exchange is subroutine test0(esss,Ix,Iyz) real(kind=kind(1.0d0)), dimension(:), intent(out) :: esss real(kind=kind(1.0d0)), dimension(:,:), intent(in) :: Ix esss = sum(Ix, 1) end subroutine Thus, whenever the reduction is one-dimensional (though in this simpler testcase we do not avoid the temporary for the sum intrinsic argument which was the point of the excercise). So, slightly more complicated to show that this is still beneficial: subroutine test0(esss,Ix,Iyz) real(kind=kind(1.0d0)), dimension(:), intent(out) :: esss real(kind=kind(1.0d0)), dimension(:,:), intent(in) :: Ix esss = esss + sum(Ix, 1) end subroutine -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43829
[Bug c++/43852] New: Embedded systems friendly libstdc++
You can configure the standard C++ library in two ways to reduce the code size and dependencies on external libraries: 1. --enable-cxx-flags=-fno-exceptions This does currently not work, due to an error in guard.cc which defines recursive_init_error::~recursive_init_error() and this results in a dependency on pure.cc and this one pulls in the IO library. 2. --disable-hosted-libstdcxx This is also broken currently (try to build it). Embedded targets may provide a hosted C environment, but in some cases it is useless to provide output messages. Also the IO library is quite huge. Two files in libstdc++/libsupc++ pull in the IO library: pure.cc and eh_term_handler.cc (via vterminate.cc). It would be nice to have a configure option (like --enable-verbose-cxx) to enable or disable the output generation in these files. -- Summary: Embedded systems friendly libstdc++ Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sebastian dot huber at embedded-brains dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43852
[Bug c++/43852] Embedded systems friendly libstdc++
--- Comment #1 from sebastian dot huber at embedded-brains dot de 2010-04-22 14:25 --- Created an attachment (id=20463) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20463action=view) Example how to implement it -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43852
[Bug libstdc++/43852] Embedded systems friendly libstdc++
--- Comment #2 from redi at gcc dot gnu dot org 2010-04-22 14:51 --- So this should be three bugs, one for each of the build problems and one enhancement request for a semi-hosted environment. I don't think verbose is a good name for the default case, I would prefer something like quiet for your suggested new mode -- redi at gcc dot gnu dot org changed: What|Removed |Added Component|c++ |libstdc++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43852
[Bug target/39105] Warning about unused libgcc.a when using SGI linker
--- Comment #2 from ro at gcc dot gnu dot org 2010-04-22 15:04 --- Mine. -- ro at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ro at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-04-22 15:04:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39105
[Bug target/39105] Warning about unused libgcc.a when using SGI linker
--- Comment #3 from ro at gcc dot gnu dot org 2010-04-22 15:07 --- Discovered independently and fixed for 4.5.0. -- ro at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2010- ||01/msg00537.html Status|ASSIGNED|RESOLVED Keywords||patch Known to work||4.5.0 Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39105
[Bug debug/40462] [4.5/4.6 Regression] ICE in dwarf2out_begin_epilogue, at dwarf2out.c:2773 while compiling mlib-tgt.adb
--- Comment #11 from ro at gcc dot gnu dot org 2010-04-22 15:09 --- Not an IRIX issue any longer. -- ro at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|mips-sgi-irix6.5| GCC host triplet|mips-sgi-irix6.5| GCC target triplet|mips-sgi-irix6.5 sparc- |sparc-rtems4.10 |rtems4.10 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40462
[Bug bootstrap/40522] IRIX 6.5 bootstrap fails: size of array 'test_real_width' is negative
--- Comment #1 from ro at gcc dot gnu dot org 2010-04-22 15:10 --- Long fixed. -- ro at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40522
[Bug lto/43850] ice: tree code �template_type_parm� is not supported in gimple streams
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-04-22 15:17 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code, lto Last reconfirmed|-00-00 00:00:00 |2010-04-22 15:17:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43850
[Bug lto/43850] ice: tree code �template_type_parm� is not supported in gimple streams
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-04-22 15:17 --- I will have a looksee. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-04-22 15:17:02 |2010-04-22 15:17:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43850
[Bug bootstrap/41996] lto-elf.c fails to compile on IRIX 6.5
--- Comment #5 from ro at gcc dot gnu dot org 2010-04-22 15:18 --- Fixed for 4.5.0. -- ro at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41996
[Bug lto/43850] ice: tree code �template_type_parm� is not supported in gimple streams
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-04-22 15:22 --- It's TYPE_ARG_TYPES of a FUNCTION_TYPE when writing the FUNCTION_DECL of void_cast_register which isn't instantiated. Reducing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43850
[Bug libstdc++/43738] basic_file_stdio.cc uses ioctl on a fd, but not available on mingw32
--- Comment #13 from sherpya at netfarm dot it 2010-04-22 15:31 --- I can build 4.5.0 without problems, I think here no source is pulling in winsock header -- sherpya at netfarm dot it changed: What|Removed |Added CC||sherpya at netfarm dot it http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43738
[Bug tree-optimization/43842] [4.6 Regression] ice in vect_create_epilog_for_reduction
--- Comment #2 from hjl dot tools at gmail dot com 2010-04-22 15:38 --- It is caused by revision 158506: http://gcc.gnu.org/ml/gcc-cvs/2010-04/msg00612.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43842
[Bug fortran/43829] Scalarization of reductions
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-04-22 15:39 ---
Reduced testcase:
template class T void void_cast_register(T *) __attribute__ ((used));
template class T void void_cast_register(T *) { }
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43829
[Bug lto/43850] ice: tree code �template_type_parm� is not supported in gimple streams
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-04-22 15:40 ---
Reduced testcase:
template class T void void_cast_register(T *) __attribute__ ((used));
template class T void void_cast_register(T *) { }
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43850
[Bug c++/43850] ice: tree code �template_type_parm� is not supported in gimple streams
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-04-22 15:41 --- Frontend bug. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|rguenth at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW Component|lto |c++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43850
[Bug c++/43818] internal compiler error: Segmentation fault
--- Comment #17 from oberlaender at fzi dot de 2010-04-22 15:48 --- (In reply to comment #16) This has been fixed on the 4.4 branch, I can reproduce it with 4.4.3. OK, thanks for the information. I'm currently compiling gcc from the 4.4 branch in svn to verify. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43818
[Bug libgcj/40860] [4.4/4.5/4.6 regression] regressions in libjava testsuite on arm-linux
--- Comment #41 from aph at gcc dot gnu dot org 2010-04-22 16:07 --- Subject: Bug 40860 Author: aph Date: Thu Apr 22 16:06:39 2010 New Revision: 158648 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158648 Log: 2010-04-19 Andrew Haley a...@redhat.com PR libgcj/40860 * configure.ac: Handle --no-merge-exidx-entries. Modified: branches/gcc-4_5-branch/libjava/ChangeLog branches/gcc-4_5-branch/libjava/configure branches/gcc-4_5-branch/libjava/configure.ac -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40860
[Bug libgcj/40860] [4.4/4.5/4.6 regression] regressions in libjava testsuite on arm-linux
--- Comment #42 from aph at gcc dot gnu dot org 2010-04-22 16:08 --- Fixed. -- aph at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40860
[Bug bootstrap/20488] Makefile: Must be a separator on line 774. Stop.
--- Comment #13 from ro at gcc dot gnu dot org 2010-04-22 16:09 --- Reopened ... -- ro at gcc dot gnu dot org changed: What|Removed |Added Status|VERIFIED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20488
[Bug bootstrap/20488] Makefile: Must be a separator on line 774. Stop.
--- Comment #14 from ro at gcc dot gnu dot org 2010-04-22 16:09 --- ... to close as fixed. -- ro at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20488
[Bug testsuite/21954] gcc.dg/compat/struct-layout-1 fails to link on Tru64 UNIX V4.0F
--- Comment #1 from ro at gcc dot gnu dot org 2010-04-22 16:12 --- IRIX 5.3 is affected as well, as would be any target without snprintf. -- ro at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC target triplet|alpha-dec-osf4.0f |alpha-dec-osf4.0f, mips-sgi- ||irix5.3 Known to fail||4.5.0 Last reconfirmed|-00-00 00:00:00 |2010-04-22 16:12:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21954
[Bug c++/22007] Stack overflow in g++.dg/eh/cleanup1.C
--- Comment #4 from ro at gcc dot gnu dot org 2010-04-22 16:18 --- Works on both alpha-dec-osf4.0f and alpha-dec-osf5.1b as of 20100330, so removing Tru64 UNIX target. -- ro at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|alpha-dec-osf4.0f | GCC host triplet|alpha-dec-osf4.0f | GCC target triplet|alpha-dec-osf4.0f |x86_64-pc-mingw32 Summary|New testsuite failure on|Stack overflow in |Tru64 UNIX V4.0F: |g++.dg/eh/cleanup1.C |g++.dg/eh/cleanup1.C| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22007
[Bug target/22224] Several Tru64 UNIX testsuite failures: Length of .lcomm was less than 1
--- Comment #1 from ro at gcc dot gnu dot org 2010-04-22 16:32 --- Mine. -- ro at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ro at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-04-22 16:32:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4
[Bug target/22224] Several Tru64 UNIX testsuite failures: Length of .lcomm was less than 1
--- Comment #2 from ro at gcc dot gnu dot org 2010-04-22 16:34 --- Patch posted. -- ro at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2010- ||04/msg01013.html Keywords||patch Known to fail||4.5.0 4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4
[Bug libobjc/26402] thr-objc.c might define _XOPEN_SOURCE unnecessarily
--- Comment #2 from ro at gcc dot gnu dot org 2010-04-22 16:37 --- Long fixed. -- ro at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||02/msg01289.html Status|NEW |RESOLVED Keywords||patch Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26402
[Bug target/38706] [4.4 Regression] ../../../../src/libstdc++-v3/src/strstream.cc:419: internal compiler error: Segmentation fault
--- Comment #14 from ro at gcc dot gnu dot org 2010-04-22 16:44 --- *** Bug 36851 has been marked as a duplicate of this bug. *** -- 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=38706
[Bug target/36851] [4.4/4.5/4.6 regression] cc1plus SEGV compiling strstream.cc on Tru64 UNIX
--- Comment #15 from ro at gcc dot gnu dot org 2010-04-22 16:44 --- Long fixed. *** This bug has been marked as a duplicate of 38706 *** -- ro at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36851
[Bug ada/40346] Many Ada tests fail on Tru64 UNIX V4.0F/V5.1B
--- Comment #3 from ro at gcc dot gnu dot org 2010-04-22 16:46 --- Long fixed. -- ro at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40346
[Bug libffi/40701] [4.5/4.6 regression] Many libffi tests fail to compile on Tru64 UNIX
--- Comment #4 from ro at gcc dot gnu dot org 2010-04-22 16:47 --- Mine. -- ro at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ro at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-04-22 16:47:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40701
[Bug libffi/40701] [4.5/4.6 regression] Many libffi tests fail to compile on Tru64 UNIX
--- Comment #5 from ro at gcc dot gnu dot org 2010-04-22 16:48 --- Fixed by patch above. -- ro at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2010- ||01/msg00339.html Status|ASSIGNED|RESOLVED Keywords||patch Resolution||FIXED Target Milestone|4.5.1 |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40701
[Bug bootstrap/41465] bootstrap failed - ../libdecnumber/gstdint.h:80: error: two or more data types in declaration specifiers
--- Comment #3 from ro at gcc dot gnu dot org 2010-04-22 16:51 --- Already fixed for 4.5.0. -- ro at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2009- ||12/msg00621.html Status|UNCONFIRMED |RESOLVED Keywords||patch Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41465
[Bug bootstrap/43847] test for plugin is using wrong objdump for host != target
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-04-22 16:54 --- Actually gcc_cv_objdump is correct for the rest of configure.ac; just we are using the incorrect one for the plugin test. Also note we need to use the one for built for the build for the host. (for Canadian crosses). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|other |bootstrap Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-04-22 16:54:18 date|| Summary|gcc_cv_objdump pointing to |test for plugin is using |wrong one in gcc/configure |wrong objdump for host != ||target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43847
[Bug libstdc++/43852] Embedded systems friendly libstdc++
--- Comment #3 from paolo dot carlini at oracle dot com 2010-04-22 17:02 --- Good point about splitting to two or three bugs, because the build issues can probably be fixed in the 4_5-branch too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43852
[Bug tree-optimization/43846] [4.5 Regression] array vs members, total scalarization issues
--- Comment #3 from davidxl at gcc dot gnu dot org 2010-04-22 17:04 --- (In reply to comment #2) (In reply to comment #1) so it doesn't consider the struct with the array for total scalarization for some reason. Martin? Well, that was a deliberate decision when fixing PR 42585 (see type_consists_of_records_p). The code is simpler because it does not have to know how to iterate over the array index domain. Of course, we can alleviate this restriction and learn how to iterate. However, all the accesses for the whole array are already created, that is not the issue. The problem basically is that when we see the sequence D.2035.m[0] = D.2044_20; D.2035.m[1] = D.2043_19; D.2035.m[2] = D.2042_18; *b_1(D) = D.2035; (and there are no other accesses to D.2035) the condition that tries to prevent us from creating unnecessary replacements kicks in and we decide not to scalarize. This code sequence looks like a good motivating factor for scalarizing/expansion. In fact, small arrays should be treated the same way as records if all accesses are through compile time constant indices. This is a common scenario after full unrolling. The intent of the current code (possibly among other reasons) was to avoid going through a replacement when the whole structure was then passed as an argument to a function and similar situations. If the temp aggregate is passed to call and the calling convention is not exposed at the IL level, then it is not a good sra candidate as no copy (both code and storage) elimination will be exposed. In this one, the temp aggregate is used as the RHS of an assignment, thus it is a good candidate to expand. So will be the reverse case: aggregate1 = aggregate2; .. ... = aggregate1.e1; ... = aggregate1.e2; David But it should not be very difficult to change the condition (in analyze_access_subtree) to handle both situations right. Doing this, rather than total scalarization for arrays (which should be only useful as a substitute for a copy propagation) should enable us to handle even huge arrays. I'll get to this right after dealing with PR 43835. -- davidxl at gcc dot gnu dot org changed: What|Removed |Added CC||xinliangli at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43846
[Bug tree-optimization/43846] [4.5 Regression] array vs members, total scalarization issues
--- Comment #4 from jamborm at gcc dot gnu dot org 2010-04-22 17:18 --- Created an attachment (id=20464) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20464action=view) Proposed fix I'm currently testing this patch and will submit it tomorrow if everything goes OK. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43846
[Bug middle-end/43853] New: [4.6 Regression] FAIL: gcc.dg/lto/20090126-1 c_lto_20090126-1_0.o-c_lto_20090126-1_0.o
On Linux/x86, revision 158610 gave FAIL: gcc.dg/lto/20090126-1 c_lto_20090126-1_0.o-c_lto_20090126-1_0.o link, (internal compiler error) Revision 158595 is OK. -- Summary: [4.6 Regression] FAIL: gcc.dg/lto/20090126-1 c_lto_20090126-1_0.o-c_lto_20090126-1_0.o Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43853
[Bug middle-end/43835] [4.5 Regression] IPA-SRA doesn't rewrite attributes
--- Comment #4 from jamborm at gcc dot gnu dot org 2010-04-22 17:30 --- A fix has been submitted to the mailing list: http://gcc.gnu.org/ml/gcc-patches/2010-04/msg01400.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43835
[Bug lto/43823] [lto] ICE during linking in testsuite
--- Comment #6 from sgk at troutmask dot apl dot washington dot edu 2010-04-22 17:38 --- Subject: Re: [lto] ICE during linking in testsuite On Wed, Apr 21, 2010 at 08:22:26PM -, rguenth at gcc dot gnu dot org wrote: I guess you have to debug it - I do not have a freebsd system available. This appears to be an incompatibility with with FreeBSD's libelf implementation. After downloading libelf-0.8.12.tar.gz as listed in the Prerequites webpage, I get troutmask:sgk[203] bash [...@troutmask ~/gcc/obj4x/gcc]$ gmake check-gfortran RUNTESTFLAGS=lto.exp === gfortran Summary === # of expected passes124 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43823
[Bug testsuite/43482] Fix *.log tests merged output containing ===
--- Comment #3 from irar at gcc dot gnu dot org 2010-04-22 18:03 --- Subject: Bug 43482 Author: irar Date: Thu Apr 22 18:03:01 2010 New Revision: 158650 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158650 Log: PR tree-optimization/43482 * tree-vect-loop.c (vect_create_epilog_for_reduction): Handle loop unrolling in update of exit phis. Fix comment. * tree-vect-slp.c (vect_analyze_slp): Check that there are at least two reduction statements in the loop before starting SLP analysis. Added: trunk/gcc/testsuite/gcc.dg/vect/pr43842.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-loop.c trunk/gcc/tree-vect-slp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43482
[Bug tree-optimization/43842] [4.6 Regression] ice in vect_create_epilog_for_reduction
--- Comment #3 from hjl dot tools at gmail dot com 2010-04-22 18:07 --- I think revision 158650: http://gcc.gnu.org/ml/gcc-cvs/2010-04/msg00756.html is the fix for this bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43842
[Bug testsuite/43482] Fix *.log tests merged output containing ===
--- Comment #4 from jan dot kratochvil at redhat dot com 2010-04-22 18:09 --- Comment 3 has a typo, it should have been for: PR tree-optimization/43842 -- jan dot kratochvil at redhat dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43482
[Bug tree-optimization/43854] New: names for compiler generated temporaries are too long
Looking at tree dumps, most variables used are compiler generated temporaries and they have names like pretmp.DECIMAL_NUMBER If instead of DECIMAL_NUMBER the same number bug in hex was used, this would reduce the memory used for those temporary names. This simple patch (that does not take care of all the temporaries, only a subset): Index: defaults.h === --- defaults.h (revision 158360) +++ defaults.h (working copy) @@ -46,12 +46,12 @@ #ifndef ASM_PN_FORMAT # ifndef NO_DOT_IN_LABEL -# define ASM_PN_FORMAT %s.%lu +# define ASM_PN_FORMAT %s.%lx # else # ifndef NO_DOLLAR_IN_LABEL -# define ASM_PN_FORMAT %s$%lu +# define ASM_PN_FORMAT %s$%lx # else -# define ASM_PN_FORMAT __%s_%lu +# define ASM_PN_FORMAT __%s_%lx # endif # endif #endif /* ! ASM_PN_FORMAT */ has this effect on the string pool (for an average size C file (dispnew.c from emacs): Before: avg. entry 17.04 bytes (+/- 8.46) after: avg. entry 16.99 bytes (+/- 8.50) so it's something given how small the change was. The difference would be even bigger if instead of base 32 or base 64 were used instead of hex, but that's a larger change... Also pretmp prehitmp and ivtmp prefixes are too long, they could be one or two letters... -- Summary: names for compiler generated temporaries are too long Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dann at godzilla dot ics dot uci dot edu GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43854
