[Bug target/33132] New: m32r: ICE: RTL check: expected elt 0 type 'i' or 'n', have 'w' (rtx const_int) in insn_current_length, at insn-attrtab.c:29: RTL check: expected elt 0 type 'i' or 'n', have 'w
This happens building libssp at revision 127638:
libtool: compile: /home/rask/build/gcc-m32r-unknown-elf/./gcc/xgcc
-B/home/rask/build/gcc-m32r-unknown-elf/./gcc/ -nostdinc
-B/home/rask/build/gcc-m32r-unknown-elf/m32r-unknown-elf/newlib/ -isystem
/home/rask/build/gcc-m32r-unknown-elf/m32r-unknown-elf/newlib/targ-include
-isystem /n/12/rask/src/all/newlib/libc/include
-B/home/rask/build/gcc-m32r-unknown-elf/m32r-unknown-elf/libgloss/m32r
-L/home/rask/build/gcc-m32r-unknown-elf/m32r-unknown-elf/libgloss/libnosys
-L/n/12/rask/src/all/libgloss/m32r -B/usr/local/m32r-unknown-elf/bin/
-B/usr/local/m32r-unknown-elf/lib/ -isystem /usr/local/m32r-unknown-elf/include
-isystem /usr/local/m32r-unknown-elf/sys-include
-L/home/rask/build/gcc-m32r-unknown-elf/./ld -DHAVE_CONFIG_H -I.
-I/n/12/rask/src/all/libssp -I. -g -Os -MT libssp_nonshared_la-ssp-local.lo -MD
-MP -MF .deps/libssp_nonshared_la-ssp-local.Tpo -c
/n/12/rask/src/all/libssp/ssp-local.c -fPIC -DPIC -o
libssp_nonshared_la-ssp-local.o
/n/12/rask/src/all/libssp/ssp-local.c: In function '__stack_chk_fail_local':
/n/12/rask/src/all/libssp/ssp-local.c:50: internal compiler error: RTL check:
expected elt 0 type 'i' or 'n', have 'w' (rtx const_int) in
insn_current_length, at insn-attrtab.c:29
(gdb) frame 2
#2 0x008d900d in insn_current_length (insn=0x2aabbee71820) at
insn-attrtab.c:106
106 if ((unsigned) (((INSN_ADDRESSES_SET_P () ? INSN_ADDRESSES
(INSN_UID (GET_CODE (operands[0]) == LABEL_REF ? XEXP (operands[0], 0) :
operands[0])) : 0) - (insn_current_reference_address (insn))) + (300)) <
(unsigned) (600))
(gdb) list
101 return 4;
102 }
103
104 case 41: /* *branch_insn */
105 extract_insn_cached (insn);
106 if ((unsigned) (((INSN_ADDRESSES_SET_P () ? INSN_ADDRESSES
(INSN_UID (GET_CODE (operands[0]) == LABEL_REF ? XEXP (operands[0], 0) :
operands[0])) : 0) - (insn_current_reference_address (insn))) + (300)) <
(unsigned) (600))
107 {
108 return 2;
109 }
110 else
(gdb) call debug_rtx (insn)
(insn:TI 17 16 19 /n/12/rask/src/all/libssp/ssp-local.c:48 (parallel [
(clobber (reg:SI 14 lr))
(set (reg:SI 12 r12)
(unspec [
(symbol_ref:SI ("_GLOBAL_OFFSET_TABLE_"))
] 5))
(use (const_int 1 [0x1]))
]) 76 {get_pc} (expr_list:REG_UNUSED (reg:SI 14 lr)
(nil)))
(gdb) frame 1
#1 0x006cbac7 in rtl_check_failed_type2 (r=0x2aabbee6c410, n=0,
c1=105, c2=110, file=, line=29,
func=0xad8d20 "insn_current_length") at /n/12/rask/src/all/gcc/rtl.c:501
501 internal_error
(gdb) call debug_rtx (r)
(const_int 1 [0x1])
--
Summary: m32r: ICE: RTL check: expected elt 0 type 'i' or 'n',
have 'w' (rtx const_int) in insn_current_length, at
insn-attrtab.c:29: RTL check: expected elt 0 type 'i' or
'n', have 'w' (rtx const_int) in insn_current_length, at
insn-attrtab.c:29
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, build, ice-checking
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rask at gcc dot gnu dot org
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: m32r-unknown-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33132
[Bug middle-end/33122] [4.3 Regression] Mistaken type mismatch error prevents bootstrap
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-08-21 08:24 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33122
[Bug middle-end/33122] [4.3 Regression] Mistaken type mismatch error prevents bootstrap
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-08-21 08:24 --- Subject: Bug 33122 Author: rguenth Date: Tue Aug 21 08:23:50 2007 New Revision: 127659 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127659 Log: 2007-08-21 Richard Guenther <[EMAIL PROTECTED]> PR middle-end/33122 * fold-const.c (fold_binary): Remove index +p PTR folding. Fix types of POINTER_PLUS_EXPR generated by folding of (PTR +p B) +p A. * gcc.c-torture/compile/pr33122.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr33122.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33122
[Bug target/33133] New: [4.3 Regression] ICE in try_ready, at haifa-sched.c:2958 with -O3
I'm getting the following ICE at -O3 with current SVN: (sid)[EMAIL PROTECTED]:~$ /usr/lib/gcc-snapshot/bin/gcc -c -O3 ncpfs-ncplib.c ncpfs-ncplib.c: In function 'newpassencrypt': ncpfs-ncplib.c:46: warning: incompatible implicit declaration of built-in function 'memcpy' ncpfs-ncplib.c:48: internal compiler error: in try_ready, at haifa-sched.c:2958 Please submit a full bug report, ... This worked with 20070811. -- Summary: [4.3 Regression] ICE in try_ready, at haifa-sched.c:2958 with -O3 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tbm at cyrius dot com GCC target triplet: ia64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33133
[Bug target/33133] [4.3 Regression] ICE in try_ready, at haifa-sched.c:2958 with -O3
--- Comment #1 from tbm at cyrius dot com 2007-08-21 08:29 ---
Testcase:
static char newshuffle[256 + 16] = {
0x0f, 0x08, 0x05, 0x07, 0x0c, 0x02, 0x0e, 0x09, 0x00, 0x01, 0x06, 0x0d,
0x03, 0x04, 0x0b, 0x0a, 0x02, 0x0c, 0x0e, 0x06, 0x0f, 0x00, 0x01, 0x08,
0x0d, 0x03, 0x0a, 0x04, 0x09, 0x0b, 0x05, 0x07, 0x05, 0x02, 0x09, 0x0f,
0x0c, 0x04, 0x0d, 0x00, 0x0e, 0x0a, 0x06, 0x08, 0x0b, 0x01, 0x03, 0x07,
0x0f, 0x0d, 0x02, 0x06, 0x07, 0x08, 0x05, 0x09, 0x00, 0x04, 0x0c, 0x03,
0x01, 0x0a, 0x0b, 0x0e, 0x05, 0x0e, 0x02, 0x0b, 0x0d, 0x0a, 0x07, 0x00,
0x08, 0x06, 0x04, 0x01, 0x0f, 0x0c, 0x03, 0x09, 0x08, 0x02, 0x0f, 0x0a,
0x05, 0x09, 0x06, 0x0c, 0x00, 0x0b, 0x01, 0x0d, 0x07, 0x03, 0x04, 0x0e,
0x0e, 0x08, 0x00, 0x09, 0x04, 0x0b, 0x02, 0x07, 0x0c, 0x03, 0x0a, 0x05,
0x0d, 0x01, 0x06, 0x0f, 0x01, 0x04, 0x08, 0x0a, 0x0d, 0x0b, 0x07, 0x0e,
0x05, 0x0f, 0x03, 0x09, 0x00, 0x02, 0x06, 0x0c, 0x05, 0x03, 0x0c, 0x08,
0x0b, 0x02, 0x0e, 0x0a, 0x04, 0x01, 0x0d, 0x00, 0x06, 0x07, 0x0f, 0x09,
0x06, 0x00, 0x0b, 0x0e, 0x0d, 0x04, 0x0c, 0x0f, 0x07, 0x02, 0x08, 0x0a,
0x01, 0x05, 0x03, 0x09, 0x0b, 0x05, 0x0a, 0x0e, 0x0f, 0x01, 0x0c, 0x00,
0x06, 0x04, 0x02, 0x09, 0x03, 0x0d, 0x07, 0x08, 0x07, 0x02, 0x0a, 0x00,
0x0e, 0x08, 0x0f, 0x04, 0x0c, 0x0b, 0x09, 0x01, 0x05, 0x0d, 0x03, 0x06,
0x07, 0x04, 0x0f, 0x09, 0x05, 0x01, 0x0c, 0x0b, 0x00, 0x03, 0x08, 0x0e,
0x02, 0x0a, 0x06, 0x0d, 0x09, 0x04, 0x08, 0x00, 0x0a, 0x03, 0x01, 0x0c,
0x05, 0x0f, 0x07, 0x02, 0x0b, 0x0e, 0x06, 0x0d, 0x09, 0x05, 0x04, 0x07,
0x0e, 0x08, 0x03, 0x01, 0x0d, 0x0b, 0x0c, 0x02, 0x00, 0x0f, 0x06, 0x0a,
0x09, 0x0a, 0x0b, 0x0d, 0x05, 0x03, 0x0f, 0x00, 0x01, 0x0c, 0x08, 0x07,
0x06, 0x04, 0x0e, 0x02, 0x03, 0x0e, 0x0f, 0x02, 0x0d, 0x0c, 0x04, 0x05,
0x09, 0x06, 0x00, 0x01, 0x0b, 0x07, 0x0a, 0x08,
};newpassencrypt (char *old, char *new, char *out)
{
char *p, *bx;
char copy[8];
int i, di, ax;
char cl, dl, ch;
for (i = 0; i < 16; i++)
{
for (bx = old + 7; bx > old; bx--)
{
*bx = ((bx[-1] >> 4) & 0x0f) | ((*bx) << 4);
}
for (di = 0; di < 16; di++)
{
if (newshuffle[di + 0x100] & 1)
ch = ((copy[newshuffle[di + 0x100] / 2] >> 4) & 0x0f);
else
ch = copy[newshuffle[di + 0x100] / 2] & 0x0f;
out[di / 2] |= ((di & 1) ? ch << 4 : ch);
}
memcpy (copy, out, 8);
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33133
[Bug target/33133] [4.3 Regression] ICE in try_ready, at haifa-sched.c:2958 with -O3
--- Comment #2 from tbm at cyrius dot com 2007-08-21 08:31 --- Probably caused by: 2007-08-14 Maxim Kuvyrkov <[EMAIL PROTECTED]> * sched-int.h (struct _dep): Rename field 'kind' to 'type'. (DEP_KIND): Rename to DEP_TYPE. Update all uses. ... -- tbm at cyrius dot com changed: What|Removed |Added CC||mkuvyrkov at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33133
[Bug c++/30680] Spurious "might be used uninitialized" warning in STL use.
--- Comment #1 from manu at gcc dot gnu dot org 2007-08-21 09:00 --- Hi, could you attach a preprocessed testcase (*.i) generated by adding -save-temps ? The minimal the testcase, the better. Thanks. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30680
[Bug middle-end/32912] [4.3 Regression] ICE with vector code
--- Comment #3 from jakub at gcc dot gnu dot org 2007-08-21 09:22 --- Subject: Bug 32912 Author: jakub Date: Tue Aug 21 09:22:14 2007 New Revision: 127661 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127661 Log: PR middle-end/32912 * fold-const.c (fold_unary): Optimize BIT_NOT_EXPR of VECTOR_CST. (fold_binary): Handle vectors in X | ~X and X ^ ~X optimizations. * gcc.dg/pr32912-1.c: New test. * gcc.dg/pr32912-2.c: New test. * gcc.dg/pr32912-3.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr32912-1.c trunk/gcc/testsuite/gcc.dg/pr32912-2.c trunk/gcc/testsuite/gcc.dg/pr32912-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32912
[Bug debug/32563] [4.2/4.3 regression] ICE on pointer arithmetic
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-08-21 10:11 --- Well, not entirely true. The problem is that sizetype is sign extended, and we convert from unsigned long to unsigned long sizetype, so the representation changes which causes fit_double_type to say we overflowed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32563
[Bug debug/32610] [4.2/4.3 regression] ICE in gen_tagged_type_instantiation_die, at dwarf2out.c:12762
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||08/msg01339.html Status|NEW |ASSIGNED Last reconfirmed|2007-08-06 15:45:53 |2007-08-21 10:15:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32610
[Bug tree-optimization/33134] New: [4.3 Regression] ICE in set_value_range, at tree-vrp.c:325
I'm seeing the following ICE with current trunk. This goes back at least to 20070720. (sid)25719:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/g++ -c -O2 fox1.6-fxgifio.cc fox1.6-fxgifio.cc: In function 'bool fxsaveGIF(FXStream&)': fox1.6-fxgifio.cc:10: internal compiler error: in set_value_range, at tree-vrp.c:326 Please submit a full bug report, with preprocessed source if appropriate. -- Summary: [4.3 Regression] ICE in set_value_range, at tree- vrp.c:325 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tbm at cyrius dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33134
[Bug tree-optimization/33134] [4.3 Regression] ICE in set_value_range, at tree-vrp.c:325
--- Comment #1 from tbm at cyrius dot com 2007-08-21 10:23 ---
Testcase:
/* Testcase by Martin Michlmayr <[EMAIL PROTECTED]> */
class FXObject;
class FXStream
{
public:FXStream (const FXObject *cont = __null);
FXStream & operator<< (const unsigned char &v);
};
bool fxsaveGIF (FXStream &store)
{
int bitsperpixel;
unsigned char c1;
c1 = 0x80;
c1 |= (bitsperpixel - 1) << 4;
store << c1;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33134
[Bug c++/7302] -Wnon-virtual-dtor should't complain of protected dtor
--- Comment #25 from cesarb at cesarb dot net 2007-08-21 10:54 ---
The testcase seems to be missing one case where it should warn:
class H
{
protected:
~H();
public:
virtual void deleteme() = 0;
};
H::~H()
{
}
void
H::deleteme()
{
delete this;
}
class I : public H
{
protected:
~I();
public:
virtual void deleteme() { H::deleteme(); }
void oops();
};
I::~I()
{
}
void
I::oops()
{
deleteme();
}
Here, H must have a virtual destructor. The point where it can know it should
warn is the "delete this;" line.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7302
[Bug c++/32596] [4.3 Regression] ICE with inline template specialization in anonymous namespace
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||08/msg00954.html Status|NEW |ASSIGNED Last reconfirmed|2007-07-08 10:46:52 |2007-08-21 10:54:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32596
[Bug target/33135] New: [SH] -ffinite-math-only should not be on by default
The documentation of -ffinite-math-only states "This option should never be turned on by any '-O' option" but for sh's -mieee it is said "the default is set to -ffinite-math-only" (-mieee is unset by default) as a result the -ffinite-math-only is turned on by default for the sh for all optimisation levels. on chapter 2 it was reenforced that: ... "*By default*, it (gcc) will act as the compiler for a hosted implementation" ... and a conforming hosted implementation supports the whole standard. So either the documentation is false or infinite float values should be supported (by default). The ability to perform optimum floating point code is preserved by explicitly setting it. -- Summary: [SH] -ffinite-math-only should not be on by default Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: christian dot bruel at st dot com GCC target triplet: sh-superh-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33135
[Bug debug/32563] [4.2/4.3 regression] ICE on pointer arithmetic
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-08-21 11:47 --- Not true either. host_integerp returns false for sizetype -1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32563
[Bug tree-optimization/33134] [4.3 Regression] ICE in set_value_range, at tree-vrp.c:325
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-08-21 12:09 --- Confirmed. Value numbering constant propagates c1 = 128; to c1.1_6 = (signed char)c1; and creates a constant with overflow flag set which confuses VRP signed overflow handling. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||iant at google dot com, ||dberlin at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-08-21 12:09:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33134
[Bug regression/33136] New: -Os generated code grew almost twice 4.2.1 versus 4.1.1
When you compile attached testcase with 4.1.1 and 4.2.1, resulting .o modules have following sizes: $ size insmod.i-411.o insmod.i-421.o textdata bss dec hex filename 288 0 0 288 120 insmod.i-411.o 543 0 0 543 21f insmod.i-421.o Testcase was built using following command line: gcc -std=gnu99 \ -Os -fno-builtin-strlen -finline-limit=0 -fomit-frame-pointer \ -ffunction-sections -fdata-sections -fno-guess-branch-probability \ -funsigned-char -static-libgcc \ -falign-functions=1 -falign-jumps=1 -falign-labels=1 -falign-loops=1 \ -march=i386 -mpreferred-stack-boundary=2 \ -fverbose-asm -S insmod.i.c -- Summary: -Os generated code grew almost twice 4.2.1 versus 4.1.1 Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: regression AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: vda dot linux at googlemail dot com GCC build triplet: i386-pc-linux-gnu GCC host triplet: i386-pc-linux-gnu GCC target triplet: i386-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33136
[Bug regression/33136] -Os generated code grew almost twice 4.2.1 versus 4.1.1
--- Comment #1 from vda dot linux at googlemail dot com 2007-08-21 12:23 --- Created an attachment (id=14086) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14086&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33136
[Bug regression/33136] -Os generated code grew almost twice 4.2.1 versus 4.1.1
--- Comment #2 from vda dot linux at googlemail dot com 2007-08-21 12:26 --- Created an attachment (id=14087) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14087&action=view) assembler output generated by 4.1.1 Sorry, don't have native gcc 4.1.1 at this machine, but have i486-linux-uclibc-gcc 4.1.1 and 4.2.1. Thus attaching asm output generated by these. Generated code should be identical, I think. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33136
[Bug regression/33136] -Os generated code grew almost twice 4.2.1 versus 4.1.1
--- Comment #3 from vda dot linux at googlemail dot com 2007-08-21 12:26 --- Created an attachment (id=14088) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14088&action=view) assembler output generated by 4.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33136
[Bug regression/33136] -Os generated code grew almost twice 4.2.1 versus 4.1.1
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-08-21 13:10 --- 4.1 somehow has better alias information, you can verify this by adding -fno-strict-aliasing to 4.1 and get the same (worse) result as with 4.2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33136
[Bug tree-optimization/33136] [4.2/4.3 Regression] -Os generated code grew almost twice 4.2.1 versus 4.1.1
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-08-21 13:12 --- trunk regresses even more -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|regression |tree-optimization Ever Confirmed|0 |1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2007-08-21 13:12:38 date|| Summary|-Os generated code grew |[4.2/4.3 Regression] -Os |almost twice 4.2.1 versus |generated code grew almost |4.1.1 |twice 4.2.1 versus 4.1.1 Target Milestone|--- |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33136
[Bug tree-optimization/32723] [4.2 Regression] memory hog in solve_graph
--- Comment #12 from pixel at mandriva dot com 2007-08-21 13:29 --- i do know it works nicely with gcc 4.3 but i still get the "memory hog" behaviour using branches/gcc-4_2-branch, ie: % /usr/lib/gcc/i586-mandriva-linux-gnu/4.2.1/cc1 -O2 fail.c runs with memory RSS raising up to 1G many times. i've also tried with gcc-4.2-4.2.1-4 from debian (which has a SVN snapshot from 20070812): % ulimit -v 90 % /usr/lib/gcc/i486-linux-gnu/4.2.1/cc1 fail.c -O2 _create Analyzing compilation unitPerforming interprocedural optimizations Assembling functions: _create cc1: out of memory allocating 4064 bytes after a total of 877277184 bytes -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32723
[Bug tree-optimization/33134] [4.3 Regression] ICE in set_value_range, at tree-vrp.c:325
--- Comment #3 from ian at airs dot com 2007-08-21 13:59 ---
Index: gcc/tree-vrp.c
===
--- gcc/tree-vrp.c (revision 127491)
Testing this patch.
+++ gcc/tree-vrp.c (working copy)
@@ -2641,7 +2641,7 @@ adjust_range_with_scev (value_range_t *v
/* Like in PR19590, scev can return a constant function. */
if (is_gimple_min_invariant (chrec))
{
- set_value_range (vr, VR_RANGE, chrec, chrec, vr->equiv);
+ set_value_range_to_value (vr, chrec, vr->equiv);
return;
}
--
ian at airs dot com changed:
What|Removed |Added
CC|iant at google dot com |ian at airs dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33134
[Bug libfortran/23138] [mingw32] real(16) values are printed incorrectly
--- Comment #14 from fxcoudert at gcc dot gnu dot org 2007-08-21 14:02 --- I've asked the mingw-users mailing-list about this issue: http://sourceforge.net/mailarchive/message.php?msg_name=19c433eb0708210654h3b419607t5f2985edfc809348%40mail.gmail.com (PS: the impact of this bug will be mitigated when Jerry's per-kind-IO patch will go in; it will also be easier to work around it by simply casting to and from doubles.) -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||dannysmith at gcc dot gnu ||dot org Known to fail||4.3.0 4.2.1 4.1.3 Last reconfirmed|2006-09-28 14:11:03 |2007-08-21 14:02:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23138
[Bug middle-end/32946] [4.3 Regression] ICE with -fpredictive-commoning in build_classic_dist_vector_1
--- Comment #6 from jakub at gcc dot gnu dot org 2007-08-21 14:18 --- Testing a patch. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-07-31 18:24:59 |2007-08-21 14:18:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32946
[Bug tree-optimization/32573] [4.3 Regression] ice for legal code with -O3
--- Comment #4 from jakub at gcc dot gnu dot org 2007-08-21 14:13 --- Testing a patch. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-07-31 18:38:32 |2007-08-21 14:13:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32573
[Bug target/32338] [4.3 Regression] Error: .prologue within prologue
--- Comment #7 from tbm at cyrius dot com 2007-08-21 14:39 --- Can an ia64-maintainer approve one of the patches Jakub has suggested? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32338
[Bug middle-end/33137] New: [4.3 Regression] Segfault in build_classic_dist_vector_1 in gcc/tree-data-ref.c
I'm seeing the following segfault with current trunk. This also happens with trunk from 20070720, but compiles fine with trunk from 20070616. (sid)25752:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/gcc -c -O3 freecell-solver-state.c freecell-solver-state.c: In function 'freecell_solver_canonize_state': freecell-solver-state.c:21: 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. (gdb) run -O3 ~/freecell-solver-state.c Starting program: /home/tbm/tmp/gcc/gcc-4.3-20070821-r127666/gcc/cc1 -O3 ~/freecell-solver-state.c fcs_card_compare freecell_solver_canonize_state Analyzing compilation unit Performing interprocedural optimizations Assembling fu nctions: fcs_card_compare freecell_solver_canonize_state Program received signal SIGSEGV, Segmentation fault. build_classic_dist_vector_1 (ddr=0xf324c0, ddr_a=0xf3cb40, ddr_b=0xf57c60, dist_v=0x2af788c2fd00, init_b=0x7fff2292be57 "[EMAIL PROTECTED]", index_carry=0x7fff2292be50) at gcc/tree-data-ref.c:2717 2717 if (chrec_contains_undetermined (SUB_DISTANCE (subscript))) (gdb) where #0 build_classic_dist_vector_1 (ddr=0xf324c0, ddr_a=0xf3cb40, ddr_b=0xf57c60, dist_v=0x2af788c2fd00, init_b=0x7fff2292be57 "[EMAIL PROTECTED]", index_carry=0x7fff2292be50) at gcc/tree-data-ref.c:2717 #1 0x006d0230 in subscript_dependence_tester (ddr=0xf324c0, loop_nest=0x2af788d28140) at gcc/tree-data-ref.c:3019 #2 0x006d13fc in compute_all_dependences (datarefs=0xf2e1e0, dependence_relations=0x7fff2292c158, loop_nest=0xf2e2b0, compute_self_and_rr=1 '\001') at gcc/tree-data-ref.c:3827 #3 0x006d207c in compute_data_dependences_for_loop (loop=0x2af788d28140, compute_self_and_read_read_dependences=1 '\001', datarefs=0x7fff2292c160, dependence_relations=0x7fff2292c158) at gcc/tree-data-ref.c:4139 #4 0x00a42ec0 in tree_predictive_commoning () at gcc/tree-predcom.c:2487 #5 0x0077be37 in run_tree_predictive_commoning () at gcc/tree-ssa-loop.c:183 #6 0x00629227 in execute_one_pass (pass=0xe87940) at gcc/passes.c:1108 #7 0x006293ec in execute_pass_list (pass=0xe87940) at gcc/passes.c:1161 #8 0x006293fe in execute_pass_list (pass=0xe877c0) at gcc/passes.c:1162 #9 0x006293fe in execute_pass_list (pass=0xe86c20) at gcc/passes.c:1162 #10 0x006fd2bf in tree_rest_of_compilation (fndecl=0x2af788d0cd00) at gcc/tree-optimize.c:405 #11 0x008656c0 in cgraph_expand_function (node=0x2af788d0ce00) at gcc/cgraphunit.c:1077 #12 0x00866ea5 in cgraph_optimize () at gcc/cgraphunit.c:1146 #13 0x00414af0 in c_write_global_declarations () at gcc/c-decl.c:8072 #14 0x006a30f3 in toplev_main (argc=, argv=) at gcc/toplev.c:1058 #15 0x2af788831b44 in __libc_start_main () from /lib/libc.so.6 #16 0x00404449 in _start () (gdb) -- Summary: [4.3 Regression] Segfault in build_classic_dist_vector_1 in gcc/tree-data-ref.c Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tbm at cyrius dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33137
[Bug middle-end/33137] [4.3 Regression] Segfault in build_classic_dist_vector_1 in gcc/tree-data-ref.c
--- Comment #2 from tbm at cyrius dot com 2007-08-21 14:55 ---
/* Testcase by Martin Michlmayr <[EMAIL PROTECTED]> */
struct fcs_struct_state_t
{
char freecells[4];
};
typedef struct fcs_struct_state_t fcs_state_t;
struct fcs_struct_state_with_locations_t
{
fcs_state_t s;
};
typedef struct fcs_struct_state_with_locations_t fcs_state_with_locations_t;
fcs_card_compare (const char *card1, const char *card2)
{
if (((*card1) & 0x0F) > ((*card2) & 0x0F))
return 1;
return -1;
}
freecell_solver_canonize_state (fcs_state_with_locations_t *state,
int freecells_num)
{
int b, c;
for (b = 1; b < freecells_num; b++)
{
c = b;
while ((c > 0)
&&
(fcs_card_compare
(&(state->s.freecells[c]), &(state->s.freecells[c - 1])) < 0))
{
state->s.freecells[c] = state->s.freecells[c - 1];
c--;
}
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33137
[Bug middle-end/33137] [4.3 Regression] Segfault in build_classic_dist_vector_1 in gcc/tree-data-ref.c
--- Comment #1 from tbm at cyrius dot com 2007-08-21 14:55 --- I wonder if this got introduced by one of Sebastian Pop's patches. -- tbm at cyrius dot com changed: What|Removed |Added CC||sebpop at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33137
[Bug c++/32400] [4.3 Regression] ICE in expand_or_defer_fn, at cp/semantics.c:3220
--- Comment #8 from jakub at gcc dot gnu dot org 2007-08-21 15:29 --- The patch for PR32596 fixes this as well. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||08/msg00954.html Status|NEW |ASSIGNED Last reconfirmed|-00-00 00:00:00 |2007-08-21 15:29:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32400
[Bug target/33138] New: [4.3 Regression] rejects valid? assembler, segfaults
There are two issues here: - the inline assembly is rejected at -O. I don't know if the assembler code is valid, but fwiw it's accepted by gcc 4.1 and 4.2. - gcc segfaults. I see this with current trunk and with trunk from 20070720. (sid)27576:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/gcc -c -O samhain-sh_tiger1_64.c samhain-sh_tiger1_64.c: In function 'tiger_compress': samhain-sh_tiger1_64.c:12: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm' samhain-sh_tiger1_64.c:12: error: 'asm' operand has impossible constraints samhain-sh_tiger1_64.c: In function 'tiger_t': samhain-sh_tiger1_64.c:23: 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. For Debian GNU/Linux specific bug reporting instructions, see . zsh: exit 1 /usr/lib/gcc-snapshot/bin/gcc -c -O samhain-sh_tiger1_64.c (sid)27577:[EMAIL PROTECTED]: ~] gcc-4.1 -c -O samhain-sh_tiger1_64.c (sid)27578:[EMAIL PROTECTED]: ~] gcc-4.2 -c -O samhain-sh_tiger1_64.c (sid)27579:[EMAIL PROTECTED]: ~] -- Summary: [4.3 Regression] rejects valid? assembler, segfaults Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tbm at cyrius dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33138
[Bug target/33138] [4.3 Regression] rejects valid? assembler, segfaults
--- Comment #2 from tbm at cyrius dot com 2007-08-21 15:33 --- BTW, the segfault goes away when I remove the last 3 lines (function tiger_t). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33138
[Bug fortran/33105] F2003: Support is_iostat_end & is_iostat_eor intrinsics
--- Comment #3 from burnus at gcc dot gnu dot org 2007-08-21 15:46 --- > I wasn't even aware of their existence! Me neither. I found it in the NAG f95 release notes. > I'll do it (unless you want to?), thanks for the doc patch. Go ahead. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33105
[Bug target/33138] [4.3 Regression] rejects valid? assembler, segfaults
--- Comment #1 from tbm at cyrius dot com 2007-08-21 15:32 ---
typedef unsigned long int word64;
extern word64 tiger_table[4 * 256];
tiger_compress (word64 * str, word64 state[3])
{
{
register word64 a, b, c;
word64 aa, bb, cc;
word64 x0, x1, x2, x3, x4, x5, x6, x7;
b = ((word64 *) state)[1];
bb = b;
cc = c;
__asm__ ("movl%10, %%ebx \n" " movq%11, %%rcx \n" "
movq%13, %%rdx \n" "movq%6, %%r8 \n" " xorq%%r8, %2
\n" " andq%2, %%rbx \n" " andq %2, %%rcx \n" "
andq%2, %%rdx \n" "shrl$(16-3), %%ebx \n" " shrq $(32-3),
%%rcx \n" " shrq$(48-3), %%rdx \n" " movzbl %2b, %%eax \n" "
movzwl %2w, %
%edi\n" " movq(%7,%%rax,8), %%rsi \n" " shrl$(8), %%edi
\n" " movq%2, %%
rax \n" " xorq(2048*1)(%7,%%rbx), %%rsi \n" "movq%2,
%%rbx \n" "shrl $24, %%eax \n" " andq%12, %%rbx \n" " xorq
(2048*2)(%7,%%rcx), %%rsi \n" "shrq $(40-3), %%rbx \n" " movq
%2, %%rcx \n" "xorq(2048*3)(%7,%%rdx), %%rsi \n"
" movq(2048*3)(%7,%%rdi,8), %%rdx \n" " shrq$56, %%rcx \n"
"xorq(2048*
2)(%7,%%rax,8), %%rdx \n" "xorq(2048*1)(%7,%%rbx), %%rdx \n" "
subq %%rsi, %0 \n"
" xorq(%7,%%rcx,8), %%rdx \n" " addq %%rdx, %1 \n" "leaq
(%1,%1,8), %1\n": "+r"
(c), "+r" (a), "+r" (b): "r" (c), "r" (a), "r" (b), "m" (x7), "r"
(&tiger_table), "i" (0xFFL), "i" (0
xFF00L), "i" (0xFFL), "r" (0xFFLL), "r" (0xFF00LL), "r"
(0xFFLL):"3",
"%rax", "%rbx", "%rcx", "%rdx", "%rsi", "%edi",
"%r8");
{
}
b -= bb;
c += cc;
((word64 *) state)[1] = b;
((word64 *) state)[2] = c;
};
}
tiger_t (word64 * str, word64 length, word64 res[3])
{
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33138
[Bug tree-optimization/33136] [4.2/4.3 Regression] -Os generated code grew almost twice 4.2.1 versus 4.1.1
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-08-21 16:20 --- Actually I think this might be related to removing iterative jump threading and not aliasing. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33136
[Bug target/33123] internal compiler error: in decode_addr_const ( arm-linux-gcc 3.4.6)
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-21 16:21 --- Do you have the preprocessed source? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33123
[Bug target/33123] internal compiler error: in decode_addr_const ( arm-linux-gcc 3.4.6)
--- Comment #3 from hemant dot jaiswal at gmail dot com 2007-08-21 16:24 --- Created an attachment (id=14089) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14089&action=view) pre-processed source file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33123
no warning message with -Wall
I mistakenly used memcpy (s, '\0', 5); instead of memset (s, '\0', 5); but the gcc compiler gave no warnings (using -Wall). I would expect a message like: "the second parameter is not a pointer". -Mike Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s user panel and lay it on us. http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7
Re: no warning message with -Wall
On 8/21/07, Michael Williamson <[EMAIL PROTECTED]> wrote: > I would expect a message like: > > "the second parameter is not a pointer". Because '\0' can converted to a pointer type as it is a 0 (for a NULL pointer). -- Pinski
[Bug fortran/32980] Vendor extension: Intrinsic functions (D)GAMMA, LGAMMA (ALGAMA/DLGAMA)
--- Comment #3 from burnus at gcc dot gnu dot org 2007-08-21 17:06 --- Created an attachment (id=14090) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14090&action=view) invoke.texi patch Note: I did not mention "Fortran 2008" and I also did not include "LOG_GAMMA" (F2008 name of "LGAMMA"). LGAMMA: lgamma,lgammaf,lgammal are part of C99. GAMMA: "gamma" is a vendor extension, but C99 has the "true Gamma function": tgamma, tgammaf, tgammal. (Contrary to Fortran, C allows all values but returns NaN (neg.int.) or +/-INF (+/-0) for values excluded in Fortran.) As the functions are part of C99, gcc offers these as BUILD_IN_*. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32980
[Bug fortran/32980] Vendor extension: Intrinsic functions (D)GAMMA, LGAMMA (ALGAMA/DLGAMA)
--- Comment #4 from burnus at gcc dot gnu dot org 2007-08-21 17:08 --- Created an attachment (id=14091) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14091&action=view) invoke.texi patch Note: I did not mention "Fortran 2008" and I also did not include "LOG_GAMMA" (F2008 name of "LGAMMA"). LGAMMA: lgamma,lgammaf,lgammal are part of C99. GAMMA: "gamma" is a vendor extension, but C99 has the "true Gamma function": tgamma, tgammaf, tgammal. (Contrary to Fortran, C allows all values but returns NaN (neg.int.) or +/-INF (+/-0) for values excluded in Fortran.) As the functions are part of C99, gcc offers these as BUILD_IN_*. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32980
[Bug debug/32610] [4.2/4.3 regression] ICE in gen_tagged_type_instantiation_die, at dwarf2out.c:12762
--- Comment #3 from jakub at gcc dot gnu dot org 2007-08-21 17:11 --- Subject: Bug 32610 Author: jakub Date: Tue Aug 21 17:11:20 2007 New Revision: 127669 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127669 Log: PR debug/32610 * dwarf2out.c (gen_decl_die): Don't call gen_tagged_type_instantiation_die if decl doesn't have tagged type. * gcc.dg/debug/pr32610.c: New test. Added: trunk/gcc/testsuite/gcc.dg/debug/pr32610.c Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32610
[Bug tree-optimization/33134] [4.3 Regression] ICE in set_value_range, at tree-vrp.c:325
--- Comment #4 from tbm at cyrius dot com 2007-08-21 17:25 ---
better (C based) testcase:
/* Testcase by Martin Michlmayr <[EMAIL PROTECTED]> */
ui_create_cursor (unsigned char *andmask)
{
unsigned char *cursor, *pcursor;
unsigned char nextbit;
for (nextbit = 0x80; nextbit != 0; nextbit >>= 1)
*pcursor |= (~(*andmask) & nextbit);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33134
[Bug fortran/32980] Vendor extension: Intrinsic functions (D)GAMMA, LGAMMA (ALGAMA/DLGAMA)
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-08-21 17:42 --- Few comments: * F2008 draft says: "The intrinsic function ATAN is extended so that ATAN (Y, X) is ATAN2 (Y,X)." We'll need to take care of that too. * Will we want a -std=f2008 separate from f2003, or do we consider f2003 an alias for f2008 (F2008 being, after all, a minor improvement to F2003)? * scaled-erfc will require a library implementation, because it's not widely available on systems out there -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32980
[Bug fortran/32980] Vendor extension: Intrinsic functions (D)GAMMA, LGAMMA (ALGAMA/DLGAMA)
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-08-21 17:52 --- (In reply to comment #5) > * scaled-erfc will require a library implementation, because it's not widely > available on systems out there I should have added this link: http://www.netlib.org/specfun/erf -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32980
[Bug c++/32567] [4.3 regression] ICE on invalid use of parameter pack
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||08/msg01382.html Status|NEW |ASSIGNED Last reconfirmed|2007-08-06 15:29:20 |2007-08-21 18:26:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32567
[Bug fortran/32980] Vendor extension: Intrinsic functions (D)GAMMA, LGAMMA (ALGAMA/DLGAMA)
--- Comment #7 from burnus at gcc dot gnu dot org 2007-08-21 19:04 --- > * Will we want a -std=f2008 separate from f2003, or do we consider f2003 an > alias for f2008 (F2008 being, after all, a minor improvement to F2003)? Who said that it will be a minor change compared to Fortran 2003 [except that it was supposed to be one]? With Co-Arrays and submodules and a couple of other changes I wouldn't claim so. I'm definitely in favour of having -std=f2008, however, I'm not sure it is already time to introduce such features. (I need the vendor intrinsic GAMMA which I want to be compatible to Fortran 2008; currently I don't care of Fortran 2008 nor do I want to promote it, yet.) The current time line of Fortran 2008 is: 2007-12 First working draft available 2008-02 WG5 review of working draft 2008-04 WG5 approval of draft CD [...] 2009-07 Final CD submitted for approval I think we should wait at least for the first working draft until we start with -std=f2008. Only shortly ago (2007-08-13), the BITS type and the macros were (fortunately) dropped which shows that things are still in a flux -- not that I expect LOG_GAMMA and GAMMA to change/disappear esp. as they are compatible with C. The other mentioned intrinsic changes are also unlikely to change [better ask Toon before adding]. We already have a F2008 feature: We allow "CONTAINS" followed by no contained procedure. When we introduce STD_F2008, one should change the error message there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32980
[Bug fortran/32980] Vendor extension: Intrinsic functions (D)GAMMA, LGAMMA (ALGAMA/DLGAMA)
--- Comment #8 from patchapp at dberlin dot org 2007-08-21 19:06 --- Subject: Bug number PR32980 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01386.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32980
[Bug middle-end/33007] [4.3 Regression] builtin lround doesn't work
-- 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|2007-08-07 03:23:02 |2007-08-21 19:13:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33007
[Bug tree-optimization/30840] [4.3 Regression] ice for legal code with flags -O3 -fno-strict-aliasing
--- Comment #13 from reichelt at gcc dot gnu dot org 2007-08-21 19:50
---
Here's an even smaller testcase:
=
int *p;
inline int foo(int *q)
{
if (*q)
*q = 0;
return *q;
}
void bar(int *r, int i)
{
int *s;
while (--i)
*(s = r) = foo(p);
++(*s);
*s = foo(p);
}
==
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30840
[Bug c++/22238] Awful error messages with virtual functions
--- Comment #14 from reichelt at gcc dot gnu dot org 2007-08-21 19:56 --- The pointer_plus_exprt stuff has been fixed. We are now back to error messages like bug.cc: In member function 'void B::bar()': bug.cc:4: error: could not convert '(((A*)this) + ((unsigned int)(*(int*)( ((B*)this)->B::_vptr.B + 0xfff4u->A::foo()' to 'bool' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22238
[Bug c++/31131] [4.2 regression] ICE on invalid constructor definition
--- Comment #3 from reichelt at gcc dot gnu dot org 2007-08-21 20:06 --- The ICE vanished on mainline between 2007-08-05 and 2007-08-15. I'd guess this is due to the fix for PR 27211. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||27211 Summary|[4.2/4.3 regression] ICE on |[4.2 regression] ICE on |invalid constructor |invalid constructor |definition |definition Bug 31131 depends on bug 27211, which changed state. Bug 27211 Summary: Bogus error "template definition of non-template" when there is no non-template http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27211 What|Old Value |New Value Status|NEW |ASSIGNED Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31131
[Bug c++/22238] Awful error messages with virtual functions
--- Comment #15 from gdr at cs dot tamu dot edu 2007-08-21 20:27 --- Subject: Re: Awful error messages with virtual functions "reichelt at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | The pointer_plus_exprt stuff has been fixed. | | We are now back to error messages like | | bug.cc: In member function 'void B::bar()': | bug.cc:4: error: could not convert '(((A*)this) + ((unsigned int)(*(int*)( | ((B*)this)->B::_vptr.B + 0xfff4u->A::foo()' to 'bool' Until we have a separate higher level representation in the C++ front-end, this is going to be hard to fix correctly. The alternative is that we don't print expressions at all -- but that cure seems to me to be worse than the disease. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22238
[Bug fortran/33139] New: array pointer assignment gives incorrect dimensions
In some cases, when doing a pointer assignment with a arrays, the upper and lower bounds on the pointer are not the same as on the pointee. This happens in the convoluted case of a pointer declared in a module that is assigned to in a subroutine. In the caller of that subroutine, the bounds of that pointer are coming out incorrect. Below is a sample code showing the problem. It can be built without any compiler options. I get this with the most recent version of gfortran on linux (FC5). $ gfortran --version GNU Fortran (GCC) 4.3.0 20070821 (experimental) [trunk revision 127658] Here is the sample program --- module Lattice integer:: ndrft real(kind=8),pointer:: drftzs(:) end module Lattice program badpointerdims use Lattice real(kind=8),pointer:: p(:) ndrft = 100 allocate(p(0:100)) call topsetpointerdrftzs(p) print*,"p bounds ",lbound(p),ubound(p) print*,"drftzs bounds ",lbound(drftzs),ubound(drftzs) stop end badpointerdims subroutine setpointerdrftzs(p) use Lattice real(kind=8),target::p(0:ndrft) drftzs => p return end setpointerdrftzs --- The program prints the following output p bounds0 100 d bounds1 101 I would expect that the d bounds be the same as the p bounds. Thanks for your help! Dave -- Summary: array pointer assignment gives incorrect dimensions Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dpgrote at lbl dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33139
[Bug tree-optimization/33140] New: [4.3 Regression] ICE in build2_stat, at tree.c:3115
I'm getting the following ICE with current trunk. This appeared between 20070720 and 20070811. (sid)25830:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/gcc -c -O2 pari-base1.c pari-base1.c: In function 'initzeta': pari-base1.c:42: internal compiler error: in build2_stat, at tree.c:3115 Please submit a full bug report, with preprocessed source if appropriate. -- Summary: [4.3 Regression] ICE in build2_stat, at tree.c:3115 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tbm at cyrius dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33140
[Bug tree-optimization/33140] [4.3 Regression] ICE in build2_stat, at tree.c:3115
--- Comment #1 from tbm at cyrius dot com 2007-08-21 21:03 --- Maybe caused by this change? 2008-08-05 Andrew Pinski <[EMAIL PROTECTED]> -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33140
[Bug fortran/33141] New: Intrinsic procedures: Improve warning/error with -std=*
1. There should be a -W* option which gives a warning if a user procedure has the same name as an intrinsic procedure (in the enabled -std=); e.g. Warning: 'GAMMA' declared at (1) is also the name of an intrinsic. It can only be called via an explicit interface or if declared EXTERNAL. (http://gcc.gnu.org/ml/fortran/2007-08/msg00464.html) 2. (Based on discussion on IRC and email of FX, Daniel and me) Give a better error message with -std=* if the intrinsic procedure is not available. Currently, the warning not only depends on -std=* but also on -W*. Expected: gfortran -std=f95 Error: Extension: Intrinsic 'asinh' at (1) is not available in the selected standard; either use -std=gnu, provide an explicit interface or declare as EXTERNAL. gfortran -std=f95 -fall-intrinsics Warning: Extension: Internal implementation of intrinsic 'asinh' at (1) takes precedence over any user-supplied procedure -- Summary: Intrinsic procedures: Improve warning/error with -std=* Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: diagnostic 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=33141
[Bug tree-optimization/33140] [4.3 Regression] ICE in build2_stat, at tree.c:3115
--- Comment #2 from tbm at cyrius dot com 2007-08-21 21:03 ---
typedef long unsigned int size_t;
typedef struct
{
}
ldiv_t;
typedef unsigned long int ulong;
enum
{
t_INT = 1, t_REAL = 2, t_INTMOD = 3, t_FRAC = 4, t_COMPLEX = 6, t_PADIC =
15, t_QFI = 16, t_VEC = 17, t_COL = 18, t_MAT = 19, t_LIST = 20, t_STR =
21, t_VECSMALL = 22
};
typedef long *GEN;
typedef ulong pari_sp;
extern pari_sp avma, bot, top;
GEN gerepileuptoleaf (pari_sp av, GEN q);
GEN mulir (GEN x, GEN y);
GEN mulrr (GEN x, GEN y);
__inline__ static GEN
new_chunk (size_t x)
{
const GEN z = ((GEN) avma) - x;
return z;
}
__inline__ static GEN
cgetg (long x, long y)
{
const GEN z = new_chunk ((size_t) x);
return z;
}
mpadd (GEN x, GEN y)
{
}
__inline__ static GEN
mpmul (GEN x, GEN y)
{
return (((long) ulong *) (y))[0]) >> ((1L << (3 + 3)) - 7))) ==
t_INT) ? mulir (y, x) : mulrr (x, y);
}
GEN checkbnf_i (GEN bnf);
initzeta (GEN pol, long prec)
{
GEN nfz, nf, gr1, gr2, gru, p1, p2, cst, coef, bnf = checkbnf_i (pol);
GEN limx, resi, zet, C, coeflog, racpi, aij, tabj, colzero, *tabcstn,
*tabcstni;
long N0, i0, r1, r2, r, R, N, i, j, k, n, bit =
(((prec) - 2) << (3 + 3)) + 6;
pari_sp av, av2;
C = cgetg (r + 1, t_MAT);
{
GEN aiji = (((GEN *) (aij))[i]);
for (k = 1; k <= r; k++)
{
{
GEN tabjn = (((GEN *) (tabj))[n]), p2 =
mpmul GEN *) (aiji))[1 + k]), (((GEN *) (tabjn))[1]));
for (j = 2; j <= r - k + 1; j++)
mpadd (p2,
mpmul GEN *) (aiji))[j + k]),
(((GEN *) (tabjn))[j])));
}
(((GEN **) (C))[k][i]) = gerepileuptoleaf (av2, p1);
}
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33140
[Bug rtl-optimization/32557] [4.3 Regression] internal compiler error: RTL check: expected code 'reg', have 'subreg' in rhs_regno, at rtl.h:956
--- Comment #8 from patchapp at dberlin dot org 2007-08-21 21:25 --- Subject: Bug number PR rtl-optimization/32557 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01404.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32557
[Bug tree-optimization/32949] suboptimal address generation for int indices on 64-bit targets
--- Comment #1 from rakdver at gcc dot gnu dot org 2007-08-21 21:29 --- This patch fixes the problem: Index: tree-ssa-loop-niter.c === *** tree-ssa-loop-niter.c (revision 127674) --- tree-ssa-loop-niter.c (working copy) *** scev_probably_wraps_p (tree base, tree s *** 2969,2977 2032, 2040, 0, 8, ..., but the code is still legal. */ if (chrec_contains_undetermined (base) ! || chrec_contains_undetermined (step) ! || TREE_CODE (step) != INTEGER_CST) ! return true; if (integer_zerop (step)) return false; --- 2969,2975 2032, 2040, 0, 8, ..., but the code is still legal. */ if (chrec_contains_undetermined (base) ! || chrec_contains_undetermined (step)) if (integer_zerop (step)) return false; *** scev_probably_wraps_p (tree base, tree s *** 2981,2986 --- 2979,2989 if (use_overflow_semantics && nowrap_type_p (type)) return false; + /* To be able to use estimates on number of iterations of the loop, + we must have an upper bound on the absolute value of the step. */ + if (TREE_CODE (step) != INTEGER_CST) + return true; + /* Don't issue signed overflow warnings. */ fold_defer_overflow_warnings (); -- rakdver at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-08-21 21:29:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32949
[Bug target/33142] New: wrong code with abs in comparison
[ forwarded from http://bugs.debian.org/429657 ]
[EMAIL PROTECTED]:/tmp% cat test.c
int abs(int j);
void abort(void);
__attribute__((noinline)) int lisp_atan2(long dy, long dx) {
if (dx <= 0)
if (dy > 0)
return abs(dx) <= abs(dy);
return 0;
}
int main() {
volatile long dy = 63, dx = -77;
if (lisp_atan2(dy, dx))
abort();
return 0;
}
[EMAIL PROTECTED]:/tmp% gcc-4.1 -O1 test.c && ./a.out
[EMAIL PROTECTED]:/tmp% gcc-4.1 -O2 test.c && ./a.out
zsh: abort ./a.out
not reproducible on alpha or amd64, or with 4.2.
--
Summary: wrong code with abs in comparison
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: falk at debian dot org
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=33142
[Bug tree-optimization/33134] [4.3 Regression] ICE in set_value_range, at tree-vrp.c:325
--- Comment #5 from ian at gcc dot gnu dot org 2007-08-21 21:35 --- Subject: Bug 33134 Author: ian Date: Tue Aug 21 21:35:06 2007 New Revision: 127679 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127679 Log: ./: PR tree-optimization/33134 * tree-vrp.c (adjust_range_with_scev): Call set_value_range_to_value. testsuite/: PR tree-optimization/33134 * g++.dg/tree-ssa/pr33134.C: New test. Added: trunk/gcc/testsuite/g++.dg/tree-ssa/pr33134.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33134
[Bug tree-optimization/33142] [4.1 Regression] wrong code with VRP through ABS_EXPR
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-08-21 21:36 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Component|target |tree-optimization Ever Confirmed|0 |1 Known to fail||4.1.3 Last reconfirmed|-00-00 00:00:00 |2007-08-21 21:36:04 date|| Summary|wrong code with abs in |[4.1 Regression] wrong code |comparison |with VRP through ABS_EXPR Target Milestone|--- |4.1.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33142
[Bug tree-optimization/33134] [4.3 Regression] ICE in set_value_range, at tree-vrp.c:325
--- Comment #6 from ian at airs dot com 2007-08-21 21:44 --- Fixed. -- ian at airs dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33134
[Bug libgcj/33114] jc1 segault building lljava/java/util/AbstractMap.java
--- Comment #2 from dps at simpson dot demon dot co dot uk 2007-08-21
21:49 ---
Subject: Re: jc1 segault building
lljava/java/util/AbstractMap.java
No CLASSPATH variable exists in the build environment.
The compiler was confiugred with
../gcc/configure --prefix=/usr --enabled-shared
and the gcc, libjava, etc source tree was in ../gcc. The gcc source itself was
in ../gcc/gcc.
The make command was "make bootstrap" or "nice make bootstrap". Using a
completely clean directory did not change anything.
The segfault is repeatable on at least my system. The jc1 instance was
extracted from the last compile command with --verbose and -save-temps. A lot
of versions of the source from svn are all affected. (I hace been sitting on
this misbehaviour for at least a week.)
If you add
if (n_initialised==0)
{
fprintf(stderr, "fini_ssa_operands called with n_initialsised==0\n");
return;
}
at the top of fini_ssa_operands then I get a pile of those messages after the
complains about non extant methods and no segfault. Instead gcj returns
"correctly" with exit status 1. Arguably this not ideal but IMHO a distinct
improvement.
I took this as evidence that no input whatsoever was meant to lead to
fini_ssa_operands calls when n_initialised is 0. (Exactly how far the code has
proceeded from the java frontend to the backend before the segfault strikes I
have not determined.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33114
[Bug tree-optimization/33142] [4.1 Regression] wrong code with VRP through ABS_EXPR
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-08-21 22:00 --- Created an attachment (id=14092) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14092&action=view) untested patch The problem is we compare for TYPE_MIN_VALUE by pointer, but the conversion from long to int in ABS_EXPR <(int) dx> is useless so we end up comparing differently typed (but same valued) integer type bounds. Ian fixed this with the overflow warning stuff with 4.2 and trunk. -- 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 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33142
[Bug fortran/33141] Intrinsic procedures: Improve warning/error with -std=*
--- Comment #1 from kargl at gcc dot gnu dot org 2007-08-21 22:31 --- See PR 20248 before you change -fall-intrinsics behavior. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33141
[Bug preprocessor/33143] New: preprocess should ignore trigraphs in /* */ comments
http://gcc.gnu.org/onlinedocs/gcc-4.2.1/gcc/Warning-Options.html#Warning-Options-Wtrigraphs -Wtrigraphs Warn if any trigraphs are encountered that might change the meaning of the program (trigraphs within comments are not warned about). This warning is enabled by -Wall. Right now, trigraphs in // comments are not warned about. Trigraphs in /* */ comments are warned about, but should not be. Trigraphs in #if 0 ... #endif are also warned about, but it would probably be too sticky to change that behavior. Example: [EMAIL PROTECTED]:~/exp-trigraph$ cat z1.cc #if 0 ??-??- #endif /* ??-??- */ // ??-??- [EMAIL PROTECTED]:~/exp-trigraph$ /home/mec/gcc-4.2.1/install/bin/g++ -E z1.cc # 1 "z1.cc" # 1 "" # 1 "" # 1 "z1.cc" z1.cc:2:1: warning: trigraph ??- ignored, use -trigraphs to enable z1.cc:2:4: warning: trigraph ??- ignored, use -trigraphs to enable [EMAIL PROTECTED]:~/exp-trigraph$ /home/mec/gcc-4.3-20070810/install/bin/g++ -E z1.cc # 1 "z1.cc" # 1 "" # 1 "" # 1 "z1.cc" z1.cc:2:1: warning: trigraph ??- ignored, use -trigraphs to enable z1.cc:2:4: warning: trigraph ??- ignored, use -trigraphs to enable -- Summary: preprocess should ignore trigraphs in /* */ comments Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mec at google dot com 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=33143
[Bug preprocessor/33143] preprocess should ignore trigraphs in /* */ comments
--- Comment #1 from mec at google dot com 2007-08-22 00:35 --- Created an attachment (id=14093) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14093&action=view) C++ source file with trigraphs in comments and #if 0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33143
[Bug preprocessor/33143] preprocess should ignore trigraphs in /* */ comments
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-22 00:37 --- > Trigraphs in #if 0 ... #endif No that is correct to warn in that context as text inside #if 0 ... #endif are supposed to be tokens. Now in multiple line comments, they should not be warned about. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33143
Bad code generation with -O2 (ARM7 architecture)
I have found an instance of bad code generation. It happens in function
with complex control flow and lots of gotos.
I have isolated the bad code and produced debug output.
The fragment produces this output:
/* First, check if the sequence number of the incoming packet is
what we're expecting next. If not, we send out an ACK with the
correct numbers in. */
printf("seq nos %d %d %d
%d\n",BUF->seqno[0],BUF->seqno[1],BUF->seqno[2],BUF->seqno[3]);
printf("rcv_next %d %d %d
%d\n",uip_connr->rcv_nxt[0],uip_connr->rcv_nxt[1],uip_connr->rcv_nxt[2],uip_
connr->rcv_nxt[3]);
if(uip_len > 0 &&
((BUF->seqno[0] != uip_connr->rcv_nxt[0]) ||
(BUF->seqno[1] != uip_connr->rcv_nxt[1]) ||
(BUF->seqno[2] != uip_connr->rcv_nxt[2]) ||
(BUF->seqno[3] != uip_connr->rcv_nxt[3])))
{
UIP_LOG("BUG1 comparison failed");
goto send_ack;
}
seq nos 139 174 46 67
rcv_next 139 174 46 67
uIP log message: BUG1 comparison failed
When I make simple test of the comparison the generated code is OK.
When this comparison is part of complex function the generated code
is incorrect. Compiling with -O0 generates good code.
I would like your advise what to do next for debugging this code.
[Bug preprocessor/33143] preprocess should ignore trigraphs in /* */ comments
--- Comment #3 from joseph at codesourcery dot com 2007-08-22 01:13 --- Subject: Re: preprocess should ignore trigraphs in /* */ comments On Wed, 22 Aug 2007, pinskia at gcc dot gnu dot org wrote: > Now in multiple line comments, they should not be warned about. Unless of course they affect whether the comment ends or not. That is, /* ... *??/ / where the comment ends only if trigraphs are enabled. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33143
[Bug driver/33144] New: -march=native does not work on darwin
This works:
/usr/local/bin/gcc -O3 -mtune=native -c Weapon.c
This does not:
/usr/local/bin/gcc -march=native Weapon.c -c -O3
Weapon.c:1: error: bad value (native) for -march= switch
Weapon.c:1: error: bad value (native) for -mtune= switch
gcc -v yields:
Using built-in specs.
Target: i386-apple-darwin8.10.1
Configured with: ../gcc-4.2.1/configure --disable-checking --enable-
languages=c,c++,fortran --with-arch=nocona
Thread model: posix
gcc version 4.2.1
=
Per a suggestion from Ian Lance Taylor:
/usr/local/bin/gcc -v -c -O3 -march=native Weapon.c
/usr/local/libexec/gcc/i386-apple-darwin8.10.1/4.2.1/cc1 -quiet -v -
D__DYNAMIC__ Weapon.c -fPIC -quiet -dumpbase Weapon.c -march=native -
auxbase Weapon -O3 -version -o /var/tmp//ccSVG0aD.s
=
To which he replied with the issue:
The problem is that the driver code is not working, and the bug is
that gcc doesn't handle that correctly. There is some code in gcc to
handle the driver code failing, and it works for -mtune=native, but
not for -march=native.
The driver code is supposed to change the -march=native to be
-march=XXX for your CPU. The code is in
gcc/config/i386/driver-i386.c.
OK, I see the problem. The code in gcc/config/i386/linux.h looks like
this:
#define CC1_SPEC "%(cc1_cpu) %{profile:-p}"
gcc/config/i386/darwin.h looks like this:
#define CC1_SPEC "%{!mkernel:%{!static:%{!mdynamic-no-pic:-fPIC}}} \
%{!mmacosx-version-min=*:-mmacosx-version-min=%(darwin_minversion)} \
%{g: %{!fno-eliminate-unused-debug-symbols: -feliminate-unused-debug-symbols
}}"
The version in darwin.h is missing the %(cc1_cpu).
So there are two bugs: the darwin.h code does not invoke the driver
code for -march=native or -mtune=native, and the i386.c code does not
correctly handle -march=native. The effect of the first bug is that
neither -march=native nor -mtune=native work on Darwin. The effect of
the second bug is that -march=native actually gives an error, rather
than being equivalent to -march=generic.
--
Summary: -march=native does not work on darwin
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fago at caltech dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33144
[Bug fortran/33139] array pointer assignment gives incorrect dimensions
--- Comment #1 from burnus at gcc dot gnu dot org 2007-08-22 06:36 --- Minimal example: implicit none real, TARGET :: a(0:100) real, pointer :: p(:) p => a print *, lbound(a), ubound(a) print *, lbound(p), ubound(p) end Prints: 0 100 1 101 instead of (ifort, NAG f95, g95): 0 100 0 100 "7.4.2.1 Data pointer assignment" "If no bounds-remapping-list is specified, the extent of a dimension of data-pointer-object is the extent of the corresponding dimension of data-target. [...] the lower bound of each dimension is the result of the intrinsic function LBOUND (13.7.60) applied to the corresponding dimension of data-target. The upper bound of each dimension is one less than the sum of the lower bound and the extent." -- burnus at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||32834 nThis|| Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2007-08-22 06:36:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33139
