[Bug ada/18302] ACATS tests hang: c74004a, c960004, and others
--- Comment #19 from aaronavay62 at aaronwl dot com 2008-05-04 07:32 --- On i386-pc-mingw32, these are the tests that fail on 4.3.0. Hanging idle (at 0% CPU): c74004a c940010 c94002f c94002g c94008a c953001 Hanging busy (at 100% CPU): c960004 c974001 c974002 c974013 -- aaronavay62 at aaronwl dot com changed: What|Removed |Added GCC build triplet|i?86-*-*| Last reconfirmed|2004-12-08 19:44:18 |2008-05-04 07:32:53 date|| Summary|ACATS test c953002 (and |ACATS tests hang: c74004a, |others) hangs |c960004, and others Target Milestone|4.0.0 |--- Version|4.0.0 |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18302
[Bug tree-optimization/36119] [4.4 regression] internal compiler error: in vectorizable_assignment, at tree-vect-transform.c:3671
--- Comment #1 from irar at il dot ibm dot com 2008-05-04 08:00 --- I don't get the ICE: revision 134926, x86_64-linux, same flags. The loop in line 14 gets vectorized. Ira -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36119
[Bug bootstrap/36121] New: config/i386/i386.c: array index out of range
I just tried to compile the GNU C compiler version 4.4 snapshot 20080502
with the Intel C compiler.
The Intel C compiler said
../../src/gcc-4.4-20080502/gcc/config/i386/i386.c(20878): warning #175:
subscript out of range
The source code is
pat = GEN_FCN (icode) (target, args[0].op, args[1].op,
args[2].op);
but
struct
{
rtx op;
enum machine_mode mode;
} args[2];
so args[ 2].op doesn't exist. Suggest make local variable args one
bigger.
--
Summary: config/i386/i386.c: array index out of range
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dcb314 at hotmail dot com
GCC host triplet: x86_64-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36121
[Bug fortran/35990] run-time abort for PACK of run-time zero sized array
--- Comment #5 from tkoenig at gcc dot gnu dot org 2008-05-04 08:06 --- Subject: Bug 35990 Author: tkoenig Date: Sun May 4 08:06:02 2008 New Revision: 134927 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134927 Log: 2008-05-04 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/35990 * intrinsics/pack_generic.c: If an extent of the source array is less then zero, set it to zero. Set the source pointer to NULL if the source size is zero. Set the total number of elements to zero if the vector has an extent less or equal to zero. * m4/pack.m4: Set the source pointer to NULL if the source array is zero-sized. Set the total number of elemements to zero if the vector has an extent less or equal to zero. * generated/pack_i1.c: Regenerated. * generated/pack_i2.c: Regenerated. * generated/pack_i4.c: Regenerated. * generated/pack_i8.c: Regenerated. * generated/pack_i16.c: Regenerated. * generated/pack_r4.c: Regenerated. * generated/pack_r8.c: Regenerated. * generated/pack_r10.c: Regenerated. * generated/pack_r16.c: Regenerated. * generated/pack_c4.c: Regenerated. * generated/pack_c8.c: Regenerated. * generated/pack_c10.c: Regenerated. * generated/pack_c16.c: Regenerated. 2008-05-04 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/35990 * gfortran.dg/intrinsic_pack_4.f90: New test case. Added: trunk/gcc/testsuite/gfortran.dg/intrinsic_pack_4.f90 Modified: trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/generated/pack_c10.c trunk/libgfortran/generated/pack_c16.c trunk/libgfortran/generated/pack_c4.c trunk/libgfortran/generated/pack_c8.c trunk/libgfortran/generated/pack_i1.c trunk/libgfortran/generated/pack_i16.c trunk/libgfortran/generated/pack_i2.c trunk/libgfortran/generated/pack_i4.c trunk/libgfortran/generated/pack_i8.c trunk/libgfortran/generated/pack_r10.c trunk/libgfortran/generated/pack_r16.c trunk/libgfortran/generated/pack_r4.c trunk/libgfortran/generated/pack_r8.c trunk/libgfortran/m4/pack.m4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35990
[Bug fortran/35990] run-time abort for PACK of run-time zero sized array
--- Comment #6 from tkoenig at gcc dot gnu dot org 2008-05-04 09:03 --- Fixed on trunk. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.3.1 Known to work||4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35990
[Bug fortran/35990] run-time abort for PACK of run-time zero sized array
--- Comment #7 from dominiq at lps dot ens dot fr 2008-05-04 09:59 --- If I am not mistaken, the patch for libgfortran/intrinsics/pack_generic.c has not been commited yet. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35990
[Bug tree-optimization/36119] [4.4 regression] internal compiler error: in vectorizable_assignment, at tree-vect-transform.c:3671
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-05-04 10:47 ---
I can reproduce this on i686 with -O3 -mfpmath=sse -msse2 (r134902):
#1 0x086d592d in vectorizable_assignment (stmt=0xb7c9dcb0, bsi=0xbff3b824,
vec_stmt=0xbff3b7c0, slp_node=0xab9ca08)
at /home/richard/src/trunk/gcc/tree-vect-transform.c:3671
3671 gcc_assert (ncopies >= 1);
(gdb) print ncopies
$1 = 0
(gdb) call debug_generic_expr (stmt)
D.989_84 = ((D.988_83))
hmm, I guess I missed a place to teach the vectorizer that PAREN_EXPR is
a vectorizable_assignment.
(gdb) print *stmt_info
$4 = {type = assignment_vec_info_type, stmt = 0xb7c9dcb0,
loop_vinfo = 0xab97730, relevant = vect_used_in_loop, live = 0 '\0',
vectype = 0xb7c71208, vectorized_stmt = 0x0, data_ref_info = 0x0,
dr_base_address = 0x0, dr_init = 0x0, dr_offset = 0x0, dr_step = 0x0,
dr_aligned_to = 0x0, in_pattern_p = 0 '\0', related_stmt = 0x0,
same_align_refs = 0xab77820, def_type = vect_loop_def, first_dr = 0x0,
next_dr = 0x0, size = 0, store_count = 0, gap = 0, same_dr_stmt = 0x0,
read_write_dep = 0 '\0', cost = {outside_of_loop = 0, inside_of_loop = 1},
slp_type = pure_slp}
(gdb) print *loop_vinfo
$5 = {loop = 0xb7ca5688, bbs = 0xab67b98, num_iters = 0xb7c9d914,
num_iters_unchanged = 0xb7c9d914, min_profitable_iters = 0,
vectorizable = 1 '\001', vectorization_factor = 1, unaligned_dr = 0x0,
peeling_for_alignment = 0, ptr_mask = 15, datarefs = 0xab7d710,
ddrs = 0xab996e0, may_alias_ddrs = 0xab77858,
may_misalign_stmts = 0xab6c960, loop_line_number = 0,
strided_stores = 0xab6c080, slp_instances = 0xab7bcf8,
slp_unrolling_factor = 1}
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2008-05-04 10:47:08
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36119
[Bug fortran/35990] run-time abort for PACK of run-time zero sized array
--- Comment #8 from tkoenig at gcc dot gnu dot org 2008-05-04 10:15 --- Subject: Bug 35990 Author: tkoenig Date: Sun May 4 10:14:49 2008 New Revision: 134928 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134928 Log: 2008-05-04 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/35990 * intrinsics/pack_generic.c: Really commit. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/intrinsics/pack_generic.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35990
[Bug fortran/35990] run-time abort for PACK of run-time zero sized array
--- Comment #9 from tkoenig at netcologne dot de 2008-05-04 10:15 --- Subject: Re: run-time abort for PACK of run-time zero sized array On Sun, 2008-05-04 at 09:59 +, dominiq at lps dot ens dot fr wrote: > > --- Comment #7 from dominiq at lps dot ens dot fr 2008-05-04 09:59 > --- > If I am not mistaken, the patch for libgfortran/intrinsics/pack_generic.c has > not been commited yet. Thanks a lot, Dominique! I just committed that part. Thomas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35990
[Bug tree-optimization/36119] [4.4 regression] internal compiler error: in vectorizable_assignment, at tree-vect-transform.c:3671
--- Comment #3 from irar at il dot ibm dot com 2008-05-04 11:13 --- In my dump this stmt is vectorized ok: bug.F:14: note: -->vectorizing statement: D.1055_23 = ((D.1054_22)) bug.F:14: note: transform statement. bug.F:14: note: vect_is_simple_use: operand ((D.1054_22)) bug.F:14: note: non-associatable copy. bug.F:14: note: def_stmt: D.1054_22 = D.1051_19 - D.1053_21 bug.F:14: note: type of def: 3. bug.F:14: note: transform assignment. bug.F:14: note: vect_get_vec_def_for_operand: ((D.1054_22)) bug.F:14: note: vect_is_simple_use: operand ((D.1054_22)) bug.F:14: note: non-associatable copy. bug.F:14: note: def_stmt: D.1054_22 = D.1051_19 - D.1053_21 bug.F:14: note: type of def: 3. bug.F:14: note: def = D.1054_22 def_stmt = D.1054_22 = D.1051_19 - D.1053_21 bug.F:14: note: add new stmt: vect_var_.63_162 = vect_var_.62_161 I also see that vectorization factor is 1 in your dump. I think that this is the problem here, since ncopies = vf/nunits (nunits number of elements in the vector of this type). Could you please attach the vectorizer dump file? Ira -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36119
[Bug tree-optimization/36119] [4.4 regression] internal compiler error: in vectorizable_assignment, at tree-vect-transform.c:3671
--- Comment #4 from irar at il dot ibm dot com 2008-05-04 11:21 --- If it is really a try to SLP, I think this patch will fix the ICE: Index: tree-vect-transform.c === --- tree-vect-transform.c (revision 134926) +++ tree-vect-transform.c (working copy) @@ -3668,6 +3668,11 @@ vectorizable_assignment (tree stmt, bloc VEC(tree,heap) *vec_oprnds = NULL; tree vop; + /* FORNOW: SLP with multiple types is not supported. The SLP analysis verifies + this, so we can safely override NCOPIES with 1 here. */ + if (slp_node) +ncopies = 1; + gcc_assert (ncopies >= 1); if (ncopies > 1) return false; /* FORNOW */ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36119
[Bug fortran/36112] Bounds-checking on character length not working for array-constructors
--- Comment #5 from d at domob dot eu 2008-05-04 11:23 --- Now I believe I found out where the problem might be; as far as I can tell, gfc_array_ctor_strlen in trans-array.c is the point where we determine the length of the elements of a character array constructor; in the loop over all elements, it seems that the output length is overwritten on each iteration, thus returning the length of the last element, as I reported above. I can't really tell how this value is used later and if this behaviour is correct and the error comes later, but breaking the loop there after the first iteration gives the correct result for the test-case I was looking at, so the problem might really be there. Any ideas/suggestions/comments on this? And now I'll probably really wait... :D -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36112
[Bug tree-optimization/36119] [4.4 regression] internal compiler error: in vectorizable_assignment, at tree-vect-transform.c:3671
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-05-04 11:24 --- Created an attachment (id=15574) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15574&action=view) vectorizer dump Attached. The last line indeed hints at SLP: t.f90:14: note: -->vectorizing SLP node starting from: D.989_84 = ((D.988_83)) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36119
[Bug tree-optimization/36119] [4.4 regression] internal compiler error: in vectorizable_assignment, at tree-vect-transform.c:3671
--- Comment #6 from irar at il dot ibm dot com 2008-05-04 11:49 --- (In reply to comment #5) > Created an attachment (id=15574) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15574&action=view) [edit] > vectorizer dump > > Attached. Thanks! > The last line indeed hints at SLP: > > t.f90:14: note: -->vectorizing SLP node starting from: D.989_84 = > ((D.988_83)) > I am pretty sure now that the patch in comment #4 fixes the ICE. Could someone please verify this? Ira -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36119
[Bug tree-optimization/36119] [4.4 regression] internal compiler error: in vectorizable_assignment, at tree-vect-transform.c:3671
--- Comment #7 from rguenther at suse dot de 2008-05-04 11:53 --- Subject: Re: [4.4 regression] internal compiler error: in vectorizable_assignment, at tree-vect-transform.c:3671 On Sun, 4 May 2008, irar at il dot ibm dot com wrote: > --- Comment #6 from irar at il dot ibm dot com 2008-05-04 11:49 --- > (In reply to comment #5) > > Created an attachment (id=15574) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15574&action=view) > --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15574&action=view) [edit] > > vectorizer dump > > > > Attached. > > Thanks! > > > The last line indeed hints at SLP: > > > > t.f90:14: note: -->vectorizing SLP node starting from: D.989_84 = > > ((D.988_83)) > > > > I am pretty sure now that the patch in comment #4 fixes the ICE. > Could someone please verify this? It does - and the loop is vectorized. But it looks like a hack ;) Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36119
[Bug tree-optimization/36119] [4.4 regression] internal compiler error: in vectorizable_assignment, at tree-vect-transform.c:3671
--- Comment #8 from irar at il dot ibm dot com 2008-05-04 12:07 --- (In reply to comment #7) > It does - and the loop is vectorized. But it looks like a hack ;) It is not. We actually do this in all vectorizable_...() that support SLP. SLP currently does not support multiple types (I am working on this right now). So in the analysis phase we check that there is only one type in the loop before we try to SLP it. In loop-based vectorization of loops with multiple types we generate "copies" of stmts of the bigger type, and the number of copies is vf/nunits. In SLP this expression is meaningless, therefore, we overwrite NCOPIES with 1 (which is the correct number of copies in case there is only one type in the loop). Ira > > Richard. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36119
[Bug tree-optimization/36119] [4.4 regression] internal compiler error: in vectorizable_assignment, at tree-vect-transform.c:3671
--- Comment #9 from rguenther at suse dot de 2008-05-04 12:22 --- Subject: Re: [4.4 regression] internal compiler error: in vectorizable_assignment, at tree-vect-transform.c:3671 On Sun, 4 May 2008, irar at il dot ibm dot com wrote: > --- Comment #8 from irar at il dot ibm dot com 2008-05-04 12:07 --- > (In reply to comment #7) > > It does - and the loop is vectorized. But it looks like a hack ;) > > It is not. We actually do this in all vectorizable_...() that support SLP. > SLP currently does not support multiple types (I am working on this right > now). > So in the analysis phase we check that there is only one type in the loop > before we try to SLP it. In loop-based vectorization of loops with multiple > types we generate "copies" of stmts of the bigger type, and the number of > copies is vf/nunits. In SLP this expression is meaningless, therefore, we > overwrite NCOPIES with 1 (which is the correct number of copies in case there > is only one type in the loop). Ah, I see. Can you give the patch bootstrap & test? I'll pre-approve it here. Thanks, Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36119
[Bug tree-optimization/36119] [4.4 regression] internal compiler error: in vectorizable_assignment, at tree-vect-transform.c:3671
--- Comment #10 from irar at il dot ibm dot com 2008-05-04 12:26 --- (In reply to comment #9) > Can you give the patch bootstrap & test? I'll pre-approve > it here. Sure, for both trunk and 4.3.1, I guess. Ira > > Thanks, > Richard. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36119
[Bug c++/36122] New: Arm EABI C++ optimiser handles bit fields incorrectly
The program shows a problem where the compiler
seems to do 16-bit arithmetic on a 15-bit field.
In the program below,
None of the 'false' conditions within a 'doRead'
should be generated by the arguments passed but
when compiled with -O2 the tests yield false
but when compiled with -O work fine.
Any assistance/advice would be greatly appreciated
=
cat bitsBug.cxx
=
#include
typedef unsigned intuint32_t;
union BugType {
struct fieldType {
uint32_ta : 15;
uint32_tb : 1;
uint32_t : 16;
} field;
uint32_t word;
};
extern bool doRead( const uint32_t count, const uint32_t size, BugType bits1,
BugType bits2 );
int main( int argc, char *argv[] )
{
uint32_t count = 0x10;
uint32_t size = 0x40;
BugType bits1, bits2;
bits1.word = 0x0030;
bits2.word = 0x8030;
if( doRead(count, size, bits1, bits2) ) {
printf( "Passed.\n" );
return 0;
}
printf( "Failed!\n" );
return 42;
}
bool doRead( const uint32_t count, const uint32_t size, BugType bits1, BugType
bits2 )
{
if( (bits1.field.a + count) >= size ) {
bits1.field.b = !bits1.field.b;
bits1.field.a -= size;
}
bits1.field.a += count;
if( bits1.field.b == bits2.field.b ) {
if( bits1.field.a > bits2.field.a ) {
return false;
}
} else {
if( bits1.field.a < bits2.field.a ) {
return false;
}
}
return true;
}
# -
# arm-3d-linux-gnueabi-g++ -v -save-temps -Wall -O2 bitsBug.cxx
# -
Using built-in specs.
Target: arm-3d-linux-gnueabi
Configured with: /homes/system/s5_eabi_tools/gcc-4.2.3/gcc-4.2.3/configure
--prefix=/opt/s5toolsl21/lx_eabi --with-gnu-as --with-gnu-ld
--with-as=/opt/s5toolsl21/lx_eabi/bin/arm-3d-linux-gnueabi-as
--with-ld=/opt/s5toolsl21/lx_eabi/bin/arm-3d-linux-gnueabi-ld
--srcdir=/homes/system/s5_eabi_tools/gcc-4.2.3/gcc-4.2.3
--with-sysroot=/opt/s5toolsl21/syslx_eabi --target=arm-3d-linux-gnueabi
--with-cpu=arm926ej-s --enable-languages=c,c++ --without-newlib
Thread model: posix
gcc version 4.2.3
/opt/s5toolsl21/lx_eabi/libexec/gcc/arm-3d-linux-gnueabi/4.2.3/cc1plus -E
-quiet -v -D_GNU_SOURCE bitsBug.cxx -mcpu=arm926ej-s -Wall -O2 -fpch-preprocess
-o bitsBug.ii
ignoring nonexistent directory "/opt/s5toolsl21/syslx_eabi/usr/local/include"
#include "..." search starts here:
#include <...> search starts here:
/opt/s5toolsl21/lx_eabi/lib/gcc/arm-3d-linux-gnueabi/4.2.3/../../../../arm-3d-linux-gnueabi/include/c++/4.2.3
/opt/s5toolsl21/lx_eabi/lib/gcc/arm-3d-linux-gnueabi/4.2.3/../../../../arm-3d-linux-gnueabi/include/c++/4.2.3/arm-3d-linux-gnueabi
/opt/s5toolsl21/lx_eabi/lib/gcc/arm-3d-linux-gnueabi/4.2.3/../../../../arm-3d-linux-gnueabi/include/c++/4.2.3/backward
/opt/s5toolsl21/lx_eabi/lib/gcc/arm-3d-linux-gnueabi/4.2.3/include
/opt/s5toolsl21/lx_eabi/lib/gcc/arm-3d-linux-gnueabi/4.2.3/../../../../arm-3d-linux-gnueabi/include
/opt/s5toolsl21/syslx_eabi/usr/include
End of search list.
/opt/s5toolsl21/lx_eabi/libexec/gcc/arm-3d-linux-gnueabi/4.2.3/cc1plus
-fpreprocessed bitsBug.ii -quiet -dumpbase bitsBug.cxx -mcpu=arm926ej-s
-auxbase bitsBug -O2 -Wall -version -o bitsBug.s
GNU C++ version 4.2.3 (arm-3d-linux-gnueabi)
compiled by GNU C version 4.2.3.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 929c2a5646bf300132f7a0467b753b75
/opt/s5toolsl21/lx_eabi/bin/arm-3d-linux-gnueabi-as -mcpu=arm926ej-s -meabi=4
-o bitsBug.o bitsBug.s
/opt/s5toolsl21/lx_eabi/libexec/gcc/arm-3d-linux-gnueabi/4.2.3/collect2
--sysroot=/opt/s5toolsl21/syslx_eabi --eh-frame-hdr -dynamic-linker
/lib/ld-linux.so.3 -X -m armelf_linux_eabi
/opt/s5toolsl21/syslx_eabi/usr/lib/crt1.o
/opt/s5toolsl21/syslx_eabi/usr/lib/crti.o
/opt/s5toolsl21/lx_eabi/lib/gcc/arm-3d-linux-gnueabi/4.2.3/crtbegin.o
-L/opt/s5toolsl21/lx_eabi/lib/gcc/arm-3d-linux-gnueabi/4.2.3
-L/opt/s5toolsl21/lx_eabi/lib/gcc/arm-3d-linux-gnueabi/4.2.3/../../../../arm-3d-linux-gnueabi/lib
-L/opt/s5toolsl21/syslx_eabi/lib -L/opt/s5toolsl21/syslx_eabi/usr/lib bitsBug.o
-lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
/opt/s5toolsl21/lx_eabi/lib/gcc/arm-3d-linux-gnueabi/4.2.3/crtend.o
/opt/s5toolsl21/syslx_eabi/usr/lib/crtn.o
#-
#arm-3d-linux-gnueabi-g++ -v -save-temps -Wall -O2 bitsBug.cxx
#cat bitsBug.ii
#-
# 1 "bitsBug.cxx"
# 1 ""
# 1 ""
# 1 "bitsBug.cxx"
# 23 "bitsBug.cxx"
# 1 "/opt/s5toolsl21/syslx_eabi/usr/include/stdio.h" 1 3 4
# 28 "/opt/s5toolsl21/syslx_eabi/usr/include/stdio.h" 3 4
# 1 "/opt/s5toolsl21/syslx_eabi/usr/include/features.h" 1 3 4
# 330 "/opt/s5toolsl21/syslx_eabi/usr/include/features.h" 3 4
# 1 "/opt/s5toolsl21/syslx_eabi/usr/include/sys/cdefs.h" 1 3 4
# 348 "
[Bug tree-optimization/36119] [4.4 regression] internal compiler error: in vectorizable_assignment, at tree-vect-transform.c:3671
--- Comment #11 from rguenther at suse dot de 2008-05-04 12:41 --- Subject: Re: [4.4 regression] internal compiler error: in vectorizable_assignment, at tree-vect-transform.c:3671 On Sun, 4 May 2008, irar at il dot ibm dot com wrote: > > > --- Comment #10 from irar at il dot ibm dot com 2008-05-04 12:26 --- > (In reply to comment #9) > > Can you give the patch bootstrap & test? I'll pre-approve > > it here. > > Sure, for both trunk and 4.3.1, I guess. Yes. Thanks. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36119
[Bug target/36055] Missed optimsation of QI register loads
--- Comment #2 from hutchinsonandy at gcc dot gnu dot org 2008-05-04 12:58 --- A testcase is difficult since it cannot be isolate from other optimisations. The the problem is "obvious". It can be seen by doing RTL dump and looking at preferred register classes. Any source operand that can take register or immediate value should use "rL" before any "i" constraint. L is zero, which can be loaded into any destination and does not require the destination to be "d" class register used for other immediate values. There may be other instance of this in other patterns. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36055
[Bug fortran/35995] ANY, ALL, and COUNT errors for zero sized sections
--- Comment #4 from tkoenig at gcc dot gnu dot org 2008-05-04 14:46 --- Created an attachment (id=15575) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15575&action=view) proposed patch Testing this patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35995
[Bug bootstrap/36121] config/i386/i386.c: array index out of range
--- Comment #1 from hjl at gcc dot gnu dot org 2008-05-04 15:22 --- Subject: Bug 36121 Author: hjl Date: Sun May 4 15:22:05 2008 New Revision: 134932 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134932 Log: 2008-05-04 H.J. Lu <[EMAIL PROTECTED]> PR target/36121 * config/i386/i386.c (ix86_expand_special_args_builtin): Remove 3 argument handling. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36121
[Bug bootstrap/36121] config/i386/i386.c: array index out of range
--- Comment #2 from hjl dot tools at gmail dot com 2008-05-04 15:27 --- Fixed by http://gcc.gnu.org/ml/gcc-patches/2008-05/msg00206.html -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36121
[Bug tree-optimization/36118] [4.4 Regressions] inline-related regressions
--- Comment #1 from hjl dot tools at gmail dot com 2008-05-04 15:35 --- *** This bug has been marked as a duplicate of 36100 *** -- 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=36118
[Bug tree-optimization/36100] [4.4 Regression] always_inline attribute is broken at -O0
--- Comment #9 from hjl dot tools at gmail dot com 2008-05-04 15:35 --- *** Bug 36118 has been marked as a duplicate of this bug. *** -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||hp at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36100
[Bug preprocessor/36123] New: wrong #if 1/-2 and (-1)/2 overflow warnings
gcc dislikes this prefix to a program depending on C99 integer division: $ cat bug.c #if 1/-2 || (-1)/2 # error "integer division rounding away from zero not supported" #endif $ gcc-4.2.2 -fsyntax-only bug.c bug.c:1:12: warning: integer overflow in preprocessor expression bug.c:1:21: warning: integer overflow in preprocessor expression It doesn't complain about #if 1/2 || (-1)/(-2), nor nonzero expressions #if 3/-2 || (-3)/2. (Well, the latter reaches the #error directive of course.) Checked for gcc 4.2.2, 4.0.2 and 3.4.6. -- Summary: wrong #if 1/-2 and (-1)/2 overflow warnings Product: gcc Version: 4.2.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: h dot b dot furuseth at usit dot uio dot no GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36123
[Bug c/36124] New: conditional loop becomes infinite loop in -O2 (gcc 4.2 -> 4.3 regression)
Hi,
It seems to have some regression in gcc 4.3, visible on arm targets as well as
x86_64.
I originally already reported it to Debian bugtracking system
[http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=472867]
I tested it against the latest gcc snapshot:
gcc (GCC) 4.3.1 20080501 (prerelease)
gcc has been built with no option, only srcdir/configure && make.
preprocessed content:
# 1 "c.c"
# 1 ""
# 1 ""
# 1 "c.c"
extern void func(void*);
void test()
{
register long *foo = (long*) 1024;
register int index;
for(index=0;index<1024;index++)
func(foo--);
}
This is a simple loop indexed on an integer. It should be finite, but when
compiling with -O2 (and -O3) the compiler removes the end condition.
gcc -S -O2 extract:
.LCFI0:
movl$1024, %edi
.p2align 4,,10
.p2align 3
.L2:
leaq-8(%rdi), %rbx
callfunc
movq%rbx, %rdi
jmp .L2
Note that when using char* or non-pointer type for foo variable, it compiles
successfully.
--
Summary: conditional loop becomes infinite loop in -O2 (gcc 4.2 -
> 4.3 regression)
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: cyprien+gccbug at cypou dot net
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=36124
[Bug middle-end/36124] conditional loop becomes infinite loop in -O2 (gcc 4.2 -> 4.3 regression)
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-04 16:34 --- Pointers types overflow is undefined which is what you are seeing. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36124
[Bug middle-end/36124] conditional loop becomes infinite loop in -O2 (gcc 4.2 -> 4.3 regression)
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-05-04 16:45 --- (In reply to comment #2) > shouldn't gcc report a warning in this case ? Maybe, but really depending on undefined behavior is bad too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36124
[Bug middle-end/36124] conditional loop becomes infinite loop in -O2 (gcc 4.2 -> 4.3 regression)
--- Comment #2 from cyprien+gccbug at cypou dot net 2008-05-04 16:41 --- shouldn't gcc report a warning in this case ? because silently entering an infinite loop is not very kind... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36124
[Bug middle-end/36124] conditional loop becomes infinite loop in -O2 (gcc 4.2 -> 4.3 regression)
--- Comment #4 from kargl at gcc dot gnu dot org 2008-05-04 17:01 --- (In reply to comment #2) > shouldn't gcc report a warning in this case ? > > because silently entering an infinite loop is not very kind... > If your code invokes undefined behavior, how is gcc going to read your mind? Maybe the programmer meant to enter an infinite, so a warning isn't correct. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36124
[Bug middle-end/36124] conditional loop becomes infinite loop in -O2 (gcc 4.2 -> 4.3 regression)
--- Comment #5 from cyprien+gccbug at cypou dot net 2008-05-04 17:03
---
Now, this code should not rely on undefined behaviour:
extern void func(int,void*);
void test()
{
register long *foo = (long*) (4*sizeof(*foo)) - 1;
register int index;
for(index=0;index<4;index++)
func(index,foo--);
}
it still make an infinite loop, while last func call is done with foo parameter
(nil).
Do you mean I explicitely ask gcc to use foo as end-of-loop condition ??
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36124
[Bug middle-end/36124] conditional loop becomes infinite loop in -O2 (gcc 4.2 -> 4.3 regression)
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-05-04 17:09 --- >Now, this code should not rely on undefined behaviour: It does because incrementing or decrementing to a NULL Pointer is undefined. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36124
[Bug middle-end/36125] New: FAIL: 26_numerics/complex/13450.cc: ICE in verify_gimple_expr, at tree-cfg.c:3962
Executing on host: /test/gnu/gcc/objdir/./gcc/g++ -shared-libgcc -B/test/gnu/gcc /objdir/./gcc -nostdinc++ -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++ -v3/src -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/src/.libs -B/o pt/gnu/gcc/gcc-4.4.0/hppa2.0w-hp-hpux11.11/bin/ -B/opt/gnu/gcc/gcc-4.4.0/hppa2.0 w-hp-hpux11.11/lib/ -isystem /opt/gnu/gcc/gcc-4.4.0/hppa2.0w-hp-hpux11.11/includ e -isystem /opt/gnu/gcc/gcc-4.4.0/hppa2.0w-hp-hpux11.11/sys-include -g -O2 -D_GL IBCXX_ASSERT -fmessage-length=0 -g -O2 -g -O2 -DLOCALEDIR="." -nostdinc++ -I/t est/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/hppa2.0w-hp-hpux11 .11 -I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include -I/test/gn u/gcc/gcc/libstdc++-v3/libsupc++ -I/test/gnu/gcc/gcc/libstdc++-v3/include/backwa rd -I/test/gnu/gcc/gcc/libstdc++-v3/testsuite/util /test/gnu/gcc/gcc/libstdc++-v 3/testsuite/26_numerics/complex/13450.cc-include bits/stdc++.h ./libtestc++. a -lm -o ./13450.exe(timeout = 600) /test/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/complex/13450.cc: In functi on 'void test01_do(T, T) [with T = long double]': /test/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/complex/13450.cc:71: inst antiated from here /test/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/complex/13450.cc:28: intern al compiler error: in verify_gimple_expr, at tree-cfg.c:3962 -- Summary: FAIL: 26_numerics/complex/13450.cc: ICE in verify_gimple_expr, at tree-cfg.c:3962 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa2.0w-hp-hpux11.11 GCC host triplet: hppa2.0w-hp-hpux11.11 GCC target triplet: hppa2.0w-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36125
[Bug middle-end/36125] FAIL: 26_numerics/complex/13450.cc: ICE in verify_gimple_expr, at tree-cfg.c:3962
--- Comment #1 from danglin at gcc dot gnu dot org 2008-05-04 17:15 --- 27_io/basic_istream/extractors_arithmetic/char/9555-ia.cc and 27_io/basic_istream/extractors_arithmetic/wchar_t/9555-ia.cc also fail with the same error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36125
[Bug middle-end/36124] conditional loop becomes infinite loop in -O2 (gcc 4.2 -> 4.3 regression)
--- Comment #7 from cyprien+gccbug at cypou dot net 2008-05-04 17:31 --- it's right, using --foo unstead of foo-- gives a better result. But it does not make me happy (about the possibility of a bug) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36124
[Bug middle-end/36125] [4.4 Regression] FAIL: 26_numerics/complex/13450.cc: ICE in verify_gimple_expr, at tree-cfg.c:3962
--- Comment #2 from danglin at gcc dot gnu dot org 2008-05-04 18:03 --- Breakpoint 1, verify_gimple_expr (expr=0x7ae94318) at ../../gcc/gcc/tree-cfg.c:3962 3962 gcc_unreachable (); (gdb) bt #0 verify_gimple_expr (expr=0x7ae94318) at ../../gcc/gcc/tree-cfg.c:3962 #1 0x003cf16c in verify_gimple_2 (stmts=0x20) at ../../gcc/gcc/tree-cfg.c:4041 #2 0x003cf47c in verify_gimple_1 (stmts=0x833800) at ../../gcc/gcc/tree-cfg.c:4139 #3 0x00346df4 in gimplify_body (body_p=0x7ae6d138, fndecl=0x7ae90fc8, do_parms=60 '<') at ../../gcc/gcc/gimplify.c:6536 #4 0x0034731c in gimplify_function_tree (fndecl=0x7ae6d0e0) at ../../gcc/gcc/gimplify.c:6576 #5 0x001f5fc0 in c_genericize (fndecl=0x7ae6d0e0) at ../../gcc/gcc/c-gimplify.c:105 #6 0x001ae814 in cp_genericize (fndecl=0x7ae6d0e0) at ../../gcc/gcc/cp/cp-gimplify.c:774 #7 0x00060ec0 in finish_function (flags=0) at ../../gcc/gcc/cp/decl.c:11932 #8 0x000a7500 in instantiate_decl (d=0x1d, defer_ok=34, expl_inst_class_mem_p=224 '?') at ../../gcc/gcc/cp/pt.c:15146 #9 0x000baf70 in instantiate_pending_templates (retries=8599552) at ../../gcc/gcc/cp/pt.c:15231 #10 0x000e9198 in cp_write_global_declarations () at ../../gcc/gcc/cp/decl2.c:3273 #11 0x003c153c in toplev_main (argc=1073972576, argv=0x4006005c) at ../../gcc/gcc/toplev.c:971 #12 0x002065cc in main (argc=8599552, argv=0x2) at ../../gcc/gcc/main.c:35 (gdb) p debug_tree (expr) unit size align 64 symtab 20 alias set 29 canonical type 60340e80 precision 128 pointer_to_this reference_to_this > addressable used TF file /test/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/complex/13450.cc line 28 col 26 size unit size align 64 context chain > -- danglin at gcc dot gnu dot org changed: What|Removed |Added Summary|FAIL: |[4.4 Regression] FAIL: |26_numerics/complex/13450.cc|26_numerics/complex/13450.cc |: ICE in verify_gimple_expr,|: ICE in verify_gimple_expr, |at tree-cfg.c:3962 |at tree-cfg.c:3962 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36125
[Bug fortran/35995] ANY, ALL, and COUNT errors for zero sized sections
--- Comment #5 from tkoenig at gcc dot gnu dot org 2008-05-04 18:11 --- sum, product etc are also affected. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35995
[Bug preprocessor/36123] wrong #if 1/-2 and (-1)/2 overflow warnings
--- Comment #1 from tromey at gcc dot gnu dot org 2008-05-04 18:43 --- Note that this was fixed by: 2007-05-02 Eric Christopher <[EMAIL PROTECTED]> * expr.c (num_div_op): Don't overflow if the result is zero. This is in 4.3. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-05-04 18:43:54 date|| Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36123
[Bug preprocessor/36123] wrong #if 1/-2 and (-1)/2 overflow warnings
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-05-04 18:47 --- Closing as fixed then. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36123
[Bug fortran/35995] ANY, ALL, and COUNT errors for zero sized sections
--- Comment #6 from tkoenig at gcc dot gnu dot org 2008-05-04 19:08 --- Subject: Bug 35995 Author: tkoenig Date: Sun May 4 19:07:28 2008 New Revision: 134934 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134934 Log: 2008-05-04 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/35995 * m4/ifunction_logical.m4: If the extent of "array" is less than zero, set it to zero. Use an explicit flag for breaking out of the main loop to avoid, because the data pointer for "array" may be NULL for an empty array. * m4/ifunction.m4: Likewise. * generated/all_l1.c: Regenerated. * generated/all_l16.c: Regenerated. * generated/all_l2.c: Regenerated. * generated/all_l4.c: Regenerated. * generated/all_l8.c: Regenerated. * generated/any_l1.c: Regenerated. * generated/any_l16.c: Regenerated. * generated/any_l2.c: Regenerated. * generated/any_l4.c: Regenerated. * generated/any_l8.c: Regenerated. * generated/count_16_l.c: Regenerated. * generated/count_1_l.c: Regenerated. * generated/count_2_l.c: Regenerated. * generated/count_4_l.c: Regenerated. * generated/count_8_l.c: Regenerated. * generated/maxloc1_16_i1.c: Regenerated. * generated/maxloc1_16_i16.c: Regenerated. * generated/maxloc1_16_i2.c: Regenerated. * generated/maxloc1_16_i4.c: Regenerated. * generated/maxloc1_16_i8.c: Regenerated. * generated/maxloc1_16_r10.c: Regenerated. * generated/maxloc1_16_r16.c: Regenerated. * generated/maxloc1_16_r4.c: Regenerated. * generated/maxloc1_16_r8.c: Regenerated. * generated/maxloc1_4_i1.c: Regenerated. * generated/maxloc1_4_i16.c: Regenerated. * generated/maxloc1_4_i2.c: Regenerated. * generated/maxloc1_4_i4.c: Regenerated. * generated/maxloc1_4_i8.c: Regenerated. * generated/maxloc1_4_r10.c: Regenerated. * generated/maxloc1_4_r16.c: Regenerated. * generated/maxloc1_4_r4.c: Regenerated. * generated/maxloc1_4_r8.c: Regenerated. * generated/maxloc1_8_i1.c: Regenerated. * generated/maxloc1_8_i16.c: Regenerated. * generated/maxloc1_8_i2.c: Regenerated. * generated/maxloc1_8_i4.c: Regenerated. * generated/maxloc1_8_i8.c: Regenerated. * generated/maxloc1_8_r10.c: Regenerated. * generated/maxloc1_8_r16.c: Regenerated. * generated/maxloc1_8_r4.c: Regenerated. * generated/maxloc1_8_r8.c: Regenerated. * generated/maxval_i1.c: Regenerated. * generated/maxval_i16.c: Regenerated. * generated/maxval_i2.c: Regenerated. * generated/maxval_i4.c: Regenerated. * generated/maxval_i8.c: Regenerated. * generated/maxval_r10.c: Regenerated. * generated/maxval_r16.c: Regenerated. * generated/maxval_r4.c: Regenerated. * generated/maxval_r8.c: Regenerated. * generated/minloc1_16_i1.c: Regenerated. * generated/minloc1_16_i16.c: Regenerated. * generated/minloc1_16_i2.c: Regenerated. * generated/minloc1_16_i4.c: Regenerated. * generated/minloc1_16_i8.c: Regenerated. * generated/minloc1_16_r10.c: Regenerated. * generated/minloc1_16_r16.c: Regenerated. * generated/minloc1_16_r4.c: Regenerated. * generated/minloc1_16_r8.c: Regenerated. * generated/minloc1_4_i1.c: Regenerated. * generated/minloc1_4_i16.c: Regenerated. * generated/minloc1_4_i2.c: Regenerated. * generated/minloc1_4_i4.c: Regenerated. * generated/minloc1_4_i8.c: Regenerated. * generated/minloc1_4_r10.c: Regenerated. * generated/minloc1_4_r16.c: Regenerated. * generated/minloc1_4_r4.c: Regenerated. * generated/minloc1_4_r8.c: Regenerated. * generated/minloc1_8_i1.c: Regenerated. * generated/minloc1_8_i16.c: Regenerated. * generated/minloc1_8_i2.c: Regenerated. * generated/minloc1_8_i4.c: Regenerated. * generated/minloc1_8_i8.c: Regenerated. * generated/minloc1_8_r10.c: Regenerated. * generated/minloc1_8_r16.c: Regenerated. * generated/minloc1_8_r4.c: Regenerated. * generated/minloc1_8_r8.c: Regenerated. * generated/minval_i1.c: Regenerated. * generated/minval_i16.c: Regenerated. * generated/minval_i2.c: Regenerated. * generated/minval_i4.c: Regenerated. * generated/minval_i8.c: Regenerated. * generated/minval_r10.c: Regenerated. * generated/minval_r16.c: Regenerated. * generated/minval_r4.c: Regenerated. * generated/minval_r8.c: Regenerated. * generated/product_c10.c: Regenerated. * generated/product_c16.c: Regenerated. * generated/product_c4.c: Regenerated. * generated/product_c8.c: Regenerated. * gener
[Bug fortran/35995] ANY, ALL, and COUNT errors for zero sized sections
--- Comment #7 from tkoenig at gcc dot gnu dot org 2008-05-04 19:08 --- Fixed on trunk. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.3.1 Known to work||4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35995
[Bug target/36090] [4.3/4.4 Regression] ppc64 cacoshl miscompilation
--- Comment #26 from jakub at gcc dot gnu dot org 2008-05-04 19:47 ---
Created an attachment (id=15576)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15576&action=view)
gcc44-pr36090.patch
Patch I've bootstrapped on 4.3 branch on {i386,x86_64,ppc,ppc64}-linux, no
regressions.
Note that while this fixes this regression, IMNSHO rs6000_legitimate_address
check needs to be tightened up anyway, to match what the output routine
actually accepts (with current print_operand_address code the first MINUS when
going through XEXP (x, 0) must be symbol - .LCTOC*).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36090
[Bug target/36090] [4.3/4.4 Regression] ppc64 cacoshl miscompilation
--- Comment #27 from dje at gcc dot gnu dot org 2008-05-04 20:08 --- I was planning to add asserts in print_operand_address ensuring that the operand was the TOC SYMBOL_REF. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36090
[Bug middle-end/36124] conditional loop becomes infinite loop in -O2 (gcc 4.2 -> 4.3 regression)
--- Comment #8 from cyprien+gccbug at cypou dot net 2008-05-04 20:13 --- On some embedded machines, the SDRAM lays on 0x address. So it is not so meaningless to increment or decrement from/to NULL pointer. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36124
[Bug libfortran/32770] [Meta-bug] -fdefault-integer-8 issues
--- Comment #33 from tkoenig at gcc dot gnu dot org 2008-05-04 20:57 --- Subject: Bug 32770 Author: tkoenig Date: Sun May 4 20:56:30 2008 New Revision: 134936 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134936 Log: 2008-05-04 Thomas Koenig <[EMAIL PROTECTED]> PR fortran/32770 * gfortran.dg/any_all_1.f90: Adjust kinds to make test pass with -fdefault-integer-8. * gfortran.dg/maxloc_bounds_4.f90: Likewise. * gfortran.dg/maxloc_bounds_5.f90: Likewise. * gfortran.dg/maxloc_bounds_7.f90: Likewise. Modified: trunk/gcc/testsuite/gfortran.dg/any_all_1.f90 trunk/gcc/testsuite/gfortran.dg/maxloc_bounds_4.f90 trunk/gcc/testsuite/gfortran.dg/maxloc_bounds_5.f90 trunk/gcc/testsuite/gfortran.dg/maxloc_bounds_7.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32770
[Bug fortran/35719] pointer to zero sized array not associated
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-05-04 21:29 ---
The problem is that we set ila1 to a null pointer if its
size is zero:
D.647 = size.6 * 4;
if (D.647 < 0)
{
_gfortran_runtime_error (&"Attempt to allocate a negative amount of
memory."[1]{lb: 1 sz: 1});
}
if (D.647 == 0)
{
D.648 = 0B;
}
else
{
D.648 = __builtin_malloc (D.647);
if (D.648 == 0B)
{
_gfortran_os_error (&"Memory allocation failed"[1]{lb: 1 sz: 1});
}
}
ila1 = (integer(kind=4)[0:D.644] *) D.648;
It isn't clear to me why we do this (maybe as a debugging aid?).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35719
[Bug middle-end/36125] [4.4 Regression] FAIL: 26_numerics/complex/13450.cc: ICE in verify_gimple_expr, at tree-cfg.c:3962
--- Comment #3 from danglin at gcc dot gnu dot org 2008-05-04 21:43 --- (gdb) p debug_tree (rhs) unit size align 64 symtab 20 alias set 29 canonical type 60340e80 precision 128 pointer_to_this reference_to_this > addressable used TF file /test/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/complex/13450.cc line 28 col 26 size unit size align 64 context initial arg-type value-expr addressable used TF file /test/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/complex/13450.cc line 28 col 26 size unit size align 64 context chain addressable used TF file /test/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/complex/13450.cc line 28 col 26 size unit size align 64 context chain >> chain > $2 = void (gdb) p debug_tree (lhs) unit size align 64 symtab 20 alias set 29 canonical type 60340e80 precision 128 pointer_to_this reference_to_this > addressable used TF file /test/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/complex/13450.cc line 28 col 26 size unit size align 64 context chain > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36125
[Bug ada/35792] Illegal program not detected, RM 3.10.1(4/2)
--- Comment #5 from sam at gcc dot gnu dot org 2008-05-04 23:03 --- Yes, I've seen this, but I expect an answer to another one very soon, which would make the test case pass (I think the test case has the error message at the right place), that's why I haven't fixed it yet. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35792
[Bug other/36126] New: ICE: postreload.c:401
$ gcc -O1 -c -o vc1.o vc1.i In file included from E:/msys/1.0/usrc/ffmpeg/src/libavcodec/mpegvideo.h:33, from E:/msys/1.0/usrc/ffmpeg/src/libavcodec/vc1.c:31: E:/msys/1.0/usrc/ffmpeg/src/libavcodec/bitstream.h: In function 'decode012': E:/msys/1.0/usrc/ffmpeg/src/libavcodec/bitstream.h:951: internal compiler error: Segmentation fault $ gcc -O1 -c -o vc1.o vc1.i -fno-defer-pop -fno-delayed-branch -fno-guess-branch-probability E:/msys/1.0/usrc/ffmpeg/src/libavcodec/vc1.c: In function 'decode_colskip': E:/msys/1.0/usrc/ffmpeg/src/libavcodec/vc1.c:175: internal compiler error: Segmentation fault $ gcc -O1 -c -o vc1.o vc1.i -fno-defer-pop -fno-delayed-branch -fno-guess-branch-probability -fno-cprop-registers - fno-loop-optimize -fno-if-conversion -fno-if-conversion2 -fno-tree-ccp -fno-tree-dce -fno-tree-dominator-opts -fno- tree-dse -fno-tree-ter -fno-tree-lrs -fno-tree-sra -fno-tree-copyrename -fno-tree-fre -fno-tree-ch -fno-unit-at-a-t ime E:/msys/1.0/usrc/ffmpeg/src/libavcodec/vc1.c: In function 'vc1_init_common': E:/msys/1.0/usrc/ffmpeg/src/libavcodec/vc1.c:113: internal compiler error: Segmentation fault $ gcc -O1 -c -o vc1.o vc1.i -fno-defer-pop -fno-delayed-branch -fno-guess-branch-probability -fno-cprop-registers - fno-loop-optimize -fno-if-conversion -fno-if-conversion2 -fno-tree-ccp -fno-tree-dce -fno-tree-dominator-opts -fno- tree-dse -fno-tree-ter -fno-tree-lrs -fno-tree-sra -fno-tree-copyrename -fno-tree-fre -fno-tree-ch -fno-unit-at-a-t ime -fno-merge-constants -fno-omit-frame-pointer E:/msys/1.0/usrc/ffmpeg/src/libavcodec/vc1.c: In function 'vc1_init_common': E:/msys/1.0/usrc/ffmpeg/src/libavcodec/vc1.c:113: internal compiler error: Segmentation fault The above is a list of ICE's and how the location changed as I added -fno options. With every option added, the ICE remained. Dooing a backtrace yields this: (gdb) Starting program: c:/mingw/bin/../libexec/gcc/x86_64-pc-mingw32/4.4.0/cc1.exe -fpreprocessed vc1.i -quiet -dum pbase vc1.i -mtune=generic -auxbase-strip vc1.o -O1 -version -fno-defer-pop -fno-delayed-branch -fno-guess-branch-pr obability -fno-cprop-registers -fno-loop-optimize -fno-if-conversion -fno-if-conversion2 -fno-tree-ccp -fno-tree-dce -fno-tree-dominator-opts -fno-tree-dse -fno-tree-ter -fno-tree-lrs -fno-tree-sra -fno-tree-copyrename -fno-tree-fre -fno-tree-ch -fno-unit-at-a-time -fno-merge-constants -fno-omit-frame-pointer -o a.s Program received signal SIGSEGV, Segmentation fault. 0x07ff7fc52b00 in ?? () (gdb) bt #0 0x07ff7fc52b00 in ?? () #1 0x00abbe2c in reload_cse_simplify_operands (insn=0x4f0f050, testreg=0x4d725e0) at ../../build/gcc-svn/gcc/gcc/postreload.c:401 #2 0x00abc66f in reload_cse_regs_1 (first=0x4f2afc0) at ../../build/gcc-svn/gcc/gcc/postreload.c:174 #3 0x00abc700 in reload_cse_regs (first=0x0) at ../../build/gcc-svn/gcc/gcc/postreload.c:70 #4 0x00abd69d in rest_of_handle_postreload () at ../../build/gcc-svn/gcc/gcc/postreload.c:1579 #5 0x006277d6 in execute_one_pass (pass=0xc900e0) at ../../build/gcc-svn/gcc/gcc/passes.c:1133 #6 0x00627a5d in execute_pass_list (pass=0xc900e0) at ../../build/gcc-svn/gcc/gcc/passes.c:1192 #7 0x00627a6f in execute_pass_list (pass=0xc4a120) at ../../build/gcc-svn/gcc/gcc/passes.c:1193 #8 0x00627a6f in execute_pass_list (pass=0xc4a0c0) at ../../build/gcc-svn/gcc/gcc/passes.c:1193 #9 0x0081a62f in tree_rest_of_compilation (fndecl=0x4b178f0) at ../../build/gcc-svn/gcc/gcc/tree-optimize.c:420 #10 0x006299d2 in cgraph_expand_function (node=0x4e1) at ../../build/gcc-svn/gcc/gcc/cgraphunit.c:1157 #11 0x0062bb17 in cgraph_assemble_pending_functions () at ../../build/gcc-svn/gcc/gcc/cgraphunit.c:523 #12 0x0062b34a in cgraph_finalize_function (decl=0x4b178f0, nested=0 '\0') at ../../build/gcc-svn/gcc/gcc/cgraphunit.c:641 #13 0x0040c0b3 in finish_function () at ../../build/gcc-svn/gcc/gcc/c-decl.c:6781 #14 0x0048680b in c_parser_declaration_or_fndef (parser=0x47f10c0, fndef_ok=1 '\001', empty_ok=, nested=0 '\0', start_attr_ok=) at ../../build/gcc-svn/gcc/gcc/c-parser.c:1420 #15 0x004877d4 in c_parser_external_declaration (parser=0x47f10c0) at ../../build/gcc-svn/gcc/gcc/c-parser.c:1175 #16 0x004886dd in c_parse_file () at ../../build/gcc-svn/gcc/gcc/c-parser.c:1077 #17 0x0046ccd5 in c_common_parse_file ( set_yydebug=) at ../../build/gcc-svn/gcc/gcc/c-opts.c:1280 #18 0x0064860f in toplev_main (argc=, argv=) at ../../build/gcc-svn/gcc/gcc/toplev.c:962 #19 0x004013da in __tmainCRTStartup () at ../mingw-w64-crt/crt64/crtexe.c:259 #20 0x77d5964c in ?? () (gdb) (gdb) p recog_data.n_alternatives $1 = 19 '\023' (gdb) p alternative_nregs (gdb) No symbol "alternative_nregs" in current context. This ICE occurs u
[Bug other/36126] ICE: postreload.c:401
--- Comment #1 from nightstrike at gmail dot com 2008-05-04 23:35 --- Created an attachment (id=15577) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15577&action=view) Preprocessed source This is the preprocessed source that is used in the compilations mentioned in the PR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36126
[Bug middle-end/36125] [4.4 Regression] FAIL: 26_numerics/complex/13450.cc: ICE in verify_gimple_expr, at tree-cfg.c:3962
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36125
[Bug middle-end/36125] [4.4 Regression] FAIL: 26_numerics/complex/13450.cc: ICE in verify_gimple_expr, at tree-cfg.c:3962
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-05-05 00:12 --- Both a and a.143 are marked as addressable. Interesting. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36125
[Bug target/32871] [avr] Bad optimisation - gcc is pushing too many registers
--- Comment #8 from hutchinsonandy at gcc dot gnu dot org 2008-05-05 01:15 --- The following information from Kenny Zadeck, shows why the solution does not work. This limitation is not avoidable at the present time without causing compilation time/memory regressions on other targets. So we will have to live with the overly cautious saving of registers. > The target computes offset (INITIAL_ELIMINATION_OFFSET). This is called > several times during register allocation (no doubt because something > changes). Offset is a function of the number of registers saved. So I used > DF_REG_DEF_CHAIN to work out precisely saved registers. But this information > is out of date and so the offset is wrong. > However, info provided by df_regs_ever_live_p, is updated. > > So I think the live info is updated in global.c but not the chains. Is there > a sane way around this or should I put this one on "too difficult list"? > > best regards > There are a three things to consider: 1) Incremental updating is turned off during global. This was perhaps a mistake, but what I did not want to get into was rescanning each insn that uses/defines a register whenever that register gets assigned. By turning off rescanning, each insn is only rescanned once, after all of its operands have had their registers assigned. 2) Turning this off is most likely the cause of your grief. It is possible that you could move the call to turn off scanning until later, after your bit of foolishness happens but before the actual registers are assigned, but the truth is that i really do not really understand the information flow within global/reload so i did not consider something like this. 3) Incremental scanning could be turned back on, but the cost is quite high because most insns have many operands and because reload can change the assignment of registers after global gets finished. Kenny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32871
[Bug tree-optimization/36127] New: bad choice of loop IVs above -Os on x86
> /usr/local/gcc44/bin/gcc -v [..] gcc version 4.4.0 20080503 (experimental) (GCC) > gcc -O3 -mfpmath=sse -fno-pic -fno-tree-vectorize -S himenoBMTxps.c With -O2/-O3, the inner loop in jacobi() in this program ends containing a lot of this: movss _p-4(%edi,%edx,4), %xmm0 movl-96(%ebp), %edi subss _p-4(%edi,%edx,4), %xmm0 movl-108(%ebp), %edi subss _p-4(%edi,%edx,4), %xmm0 movl-92(%ebp), %edi addss _p-4(%edi,%edx,4), %xmm0 movl-124(%ebp), %edi At -O1 or -Os, it instead produces: movss 34056(%eax), %xmm0 subss 33024(%eax), %xmm0 subss -33024(%eax), %xmm0 addss -34056(%eax), %xmm0 which is much better. On core 2 it claims to be 40% faster at -Os. IIRC this isn't a problem on x86-64, but IRA+-O3 was much worse again. -- Summary: bad choice of loop IVs above -Os on x86 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: astrange at ithinksw dot com GCC target triplet: i?86-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36127
[Bug tree-optimization/36127] bad choice of loop IVs above -Os on x86
--- Comment #1 from astrange at ithinksw dot com 2008-05-05 02:12 --- Created an attachment (id=15578) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15578&action=view) source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36127
[Bug tree-optimization/36127] bad choice of loop IVs above -Os on x86
-- astrange at ithinksw dot com changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36127
[Bug tree-optimization/36127] bad choice of loop IVs above -Os on x86
--- Comment #2 from astrange at ithinksw dot com 2008-05-05 02:12 --- Created an attachment (id=15579) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15579&action=view) compiled at -O3 on darwin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36127
[Bug tree-optimization/36127] bad choice of loop IVs above -Os on x86
--- Comment #3 from astrange at ithinksw dot com 2008-05-05 02:13 --- Created an attachment (id=15580) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15580&action=view) and at -Os -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36127
[Bug target/36121] config/i386/i386.c: array index out of range
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|bootstrap |target Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36121
[Bug c++/36122] Arm EABI C++ optimiser handles bit fields incorrectly
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-05 04:50 --- This is most likely a dup of bug 33887 and has been fixed for GCC 4.3.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36122
[Bug tree-optimization/36100] [4.4 Regression] always_inline attribute is broken at -O0
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|normal |blocker Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||rejects-valid, wrong-code Last reconfirmed|-00-00 00:00:00 |2008-05-05 04:51:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36100
[Bug rtl-optimization/36111] [4.4 Regression] GCC 4.4.0-20080501 failed to compile openmpi's malloc.c file.
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-05-05 04:59 ---
Here is a further reduced testcase:
typedef struct {
int lock;
int pad0_;
} mutex_t;
static mutex_t main_arena;
void __malloc_check_init()
{
for(;;)
__asm__ __volatile__ ("": "+m"(main_arena.lock) );
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
Last reconfirmed|2008-05-03 09:50:18 |2008-05-05 04:59:19
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36111
[Bug tree-optimization/36084] not folding of (int[
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-05-05 05:03 --- If we had put the size in pointer to the array type, then this gets foldded. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36084
[Bug middle-end/36071] [4.4 Regression] segmentation fault
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-valid-code Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36071
[Bug inline-asm/36092] [4.4 Regression] invalid rtl sharing found in the insn
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-05-05 05:05 --- *** This bug has been marked as a duplicate of 36111 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36092
[Bug rtl-optimization/36111] [4.4 Regression] GCC 4.4.0-20080501 failed to compile openmpi's malloc.c file.
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-05-05 05:05 --- *** Bug 36092 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||steve49152 at yahoo dot ca http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36111
[Bug c++/36107] weak constructor product unvalid asm
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-05 05:10 --- Even if the code assembled for 3.3.6 or 3.4.x, the weak reference was not being emitted. So this is not a regression really. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-05-05 05:10:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36107
[Bug java/35999] GCJ Crash while compiling eclipse 64-bit on Ubuntu Hardy
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35999
[Bug middle-end/36003] pass_fast_rtl_byte_dce is disabled currently because of breakage in cris-elf and others targets
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-05-05 05:13 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC host triplet|x86_64-unknown-linux-gnu| Last reconfirmed|-00-00 00:00:00 |2008-05-05 05:13:12 date|| Summary|[4.4 Regression] df-byte- |pass_fast_rtl_byte_dce is |scan.c changes broke cris- |disabled currently because |elf compiling libgcc|of breakage in cris-elf and ||others targets http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36003
[Bug c++/36002] Error messages report wrong, invalid function type.
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-05 05:20 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2008-05-05 05:20:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36002
[Bug tree-optimization/36010] Loop interchange not performed
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36010
[Bug tree-optimization/36011] Loop interchange not performed, data dependence analysis defect
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36011
[Bug c/36024] Incorrect function name in linking error
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-05-05 05:22 --- This is not a bug, the names are in the reserved implementation namespace. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36024
[Bug debug/36037] [4.4 regression] segfault in gt_ggc_mx_dw_loc_descr_struct
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Component|middle-end |debug Keywords||GC, ice-on-valid-code Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36037
[Bug libstdc++/36022] stl templates exported as weak symbols though visibility hidden is used
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-05 05:27 --- The std:: namespace is supposed to be exposed and is marked as such in the libstdc++ headers. So I don't think this is a bug. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c++ |libstdc++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36022
[Bug fortran/36096] F2008 Bessel: Documentation/diagnostic errors
--- Comment #1 from burnus at gcc dot gnu dot org 2008-05-05 05:28 ---
> ERF, ERFC, GAMMA, and LOG_GAMMA returned NaN for REAL*10 inputs in
> my test. EXPONENT returned garbage for REAL*10 and FRACTION
There is another thing which has to be addressed. On Windows there seems to be
no "long double" support for some C99 functions. FX writes in the same thread:
> > I would assume that the absence of BESSEL_J0, BESSEL_J1, BESSEL_Y0, and
> > BESSEL_Y1 for REAL(10) inputs for non-initialization expressions for
> > both Win32 and Win64 is a different issue altogether.
>
> This isn't, for now, treated as a bug: Windows C library doesn't provide
> these C99 intrinsic functions ({j,y}{0,1}l). It's been our policy until
> now that while we provide fallback versions of some C99 intrinsics when
> they're missing (for example, float variants or double variants), support
> for real types larger than double (real kinds 10 and 16) entirely relies
> on the system libraries for mathematical intrinsics. Maybe this should be
> documented somewhere, but I don't know really where. Suggestions as to a
> point where to insert this in our current documentation are welcome.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36096
[Bug other/36046] Demangler fails on templates with non-type reference parameters
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-05-05 05:28 --- As mentioned in the other bug report, it is hard to handle the -fabi-version=2 version of the mangled string. We handle correctly the correctly mangled already. So closing as won't fix. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36046
[Bug testsuite/36053] [4.4 Regression]: ERROR: tcl error sourcing gcc/gcc/testsuite/gcc.dg/dg.exp
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36053
[Bug tree-optimization/36009] PRE causes missed loop store motion, store sinking doesn't work
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36009
[Bug fortran/35997] [4.3/4.4 regression] Used function interface bug
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.3/4.4 regression]Used|[4.3/4.4 regression] Used |function interface bug |function interface bug Target Milestone|--- |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35997
[Bug ada/36007] [4.4 regression] verify_gimple failed
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36007
[Bug target/36095] __builtin_ia32_crc32di shouldn't defined in 32bit
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36095
[Bug fortran/36103] gfortran crash with zh_CN locale - error_print error ?
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36103
[Bug c/35961] Erroneous error message using gcc-4.3.0 when signedness warning thrown
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-05 05:36 --- This is expected behavior. We no longer error out about an unkown warning option unless there is an error/warning already. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35961
[Bug middle-end/35973] Incorrect warning: will never be executed
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-05 05:38 --- The warning looks fine for me, it is saying selog_on(&sel) will never be executed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35973
[Bug middle-end/35973] Incorrect warning: will never be executed
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-05-05 05:40 --- Sorry I mean: [t.c : 24] D.1191_5 = sel.enabled; [t.c : 24] iftmp.1_6 = D.1191_5 != 42; As far as I can tell this warning is correct. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35973
[Bug objc/35996] ICE while building simple ObjC code with -fobjc-gc
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-05 05:42 --- IIRC -fobjc-gc is only useful for the NeXT runtime. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35996
[Bug fortran/35719] pointer to zero sized array not associated
--- Comment #3 from burnus at gcc dot gnu dot org 2008-05-05 05:46 --- (In reply to comment #2) > The problem is that we set ila1 to a null pointer if its > size is zero: [...] > It isn't clear to me why we do this (maybe as a debugging aid?). Well, if we don't assign anything, the memory content is not well defined. Doing than associated(ptr[, otherPtr]) gives then a random result including not-associated. Currently, ptr.data == NULL -> unassociated and ptr.data != NULL => associated works well, except for zero-sized arrays. One possibility is to allocate something for zero-sized arrays, e.g. one element. The array bounds ensure than that the program still knows that the size of the array is zero. The extra allocation wastes memory, but usually one element is quite small and zero-sized arrays are not very common. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35719
[Bug middle-end/35736] [4.4 regression] ICE with continue and -Wall
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-05-05 05:49 --- *** Bug 35893 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||dcb314 at hotmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35736
[Bug c/35893] ice for legal code
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-05-05 05:49 --- We have a predict_expr. *** This bug has been marked as a duplicate of 35736 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35893
[Bug other/35486] Can't build gimple-tuples-branch
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-05-05 05:50 --- I don't think this is true any more. The tuples branch should now be able to bootstrap without any issues. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35486
[Bug c/35503] Warning about restricted pointers?
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Keywords||diagnostic http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35503
[Bug tree-optimization/35501] Wrong value returned from const int
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-05 05:51 --- Actually it does not make sense to have any other value than 3 here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35501
[Bug c++/35483] GCC on AIX doesn't support dollar in symbols name.
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-05-05 05:54 --- I don't think this is a real bug. Also patches should be off of the trunk and submitted to [EMAIL PROTECTED] -- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC host triplet|powerpc-ibm-aix6.1.0.0 | GCC target triplet||powerpc-ibm-aix6.1.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35483
[Bug c/35550] gcc: Internal error: Segmentation fault (program as)
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-05 05:55 --- The assembler is crashing and not GCC. So this is best to file this bug to binutils project. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35550
[Bug c/35547] -Wparentheses not useful in its current form
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35547
[Bug middle-end/35560] Missing CSE/PRE for memory operations involved in virtual call.
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35560
[Bug fortran/36096] F2008 Bessel: Documentation/diagnostic errors
--- Comment #2 from kargl at gcc dot gnu dot org 2008-05-05 06:06 --- (In reply to comment #1) > > ERF, ERFC, GAMMA, and LOG_GAMMA returned NaN for REAL*10 inputs in > > my test. EXPONENT returned garbage for REAL*10 and FRACTION > > There is another thing which has to be addressed. On Windows there seems to be > no "long double" support for some C99 functions. FX writes in the same thread: > This is true for many operating systems. For example, none of the *BSD systems have a complete C99 libm. It's not windows specific. It took me nearly 2 years to get a sqrtl() committed to FreeBSD. Note sqrtl() is special in that ieee754 requires correct rounding in all rounding modes. It took between 6 to 9 months to get sinl(), cosl(), and tanl() committed to FreeBSD. Writing standard conforming libm functions that have accept ULP is much harder than one might think. The simplest fix is to add a note to the Intrinsic Procedure section of the manual stating the ligfortran/gfortran depends on a C99 libm. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36096
