[Bug c++/33515] Inconsistent warning about defined but not used
--- Comment #2 from mec at google dot com 2007-09-21 05:59 --- Created an attachment (id=14237) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14237action=view) Test program Compile with: gcc -Wall -S z3.cc This program does give a warning about a1 defined-but-not-used. I believe this is incorrect. The real point is that z2.cc and z3.cc should behave consistently. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33515
[Bug bootstrap/33511] make fails with no rule to make target 'all' in directory gcc
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2007-09-21 06:24 --- ../gcc-4.2.1/configure --enable-languages=c,c++,objc,obj-c++ --with-gnu-as --with-gnu-ld Please follow the instructions at: http://gcc.gnu.org/install/specific.html#x-x-solaris2 -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33511
[Bug testsuite/20003] libmudflap.cth timeouts too short
--- Comment #5 from belyshev at depni dot sinp dot msu dot ru 2007-09-21 06:56 --- Problem still persists, see eg. http://gcc.gnu.org/ml/gcc-testresults/2007-09/msg00911.html pass40-frag fails due to small timeout (not every box can create 20K threads in 20 seconds especially under high load of make -j4). pass37-frag and pass39-frag also fail due to improper use of sched_yield(), this patch cures problem for me most of the time: Index: gcc43/libmudflap/testsuite/libmudflap.cth/pass37-frag.c === --- gcc43.orig/libmudflap/testsuite/libmudflap.cth/pass37-frag.c +++ gcc43/libmudflap/testsuite/libmudflap.cth/pass37-frag.c @@ -20,7 +20,6 @@ func (void *p) libmudflap. */ array[x] = i; } - sched_yield (); /* sleep (1); */ } return (NULL); Index: gcc43/libmudflap/testsuite/libmudflap.cth/pass39-frag.c === --- gcc43.orig/libmudflap/testsuite/libmudflap.cth/pass39-frag.c +++ gcc43/libmudflap/testsuite/libmudflap.cth/pass39-frag.c @@ -20,7 +20,6 @@ func (void *p) assert (arrays[i] != NULL); arrays[i][x] = i; free (arrays[i]); - sched_yield (); /* sleep (1); */ } return (NULL); -- belyshev at depni dot sinp dot msu dot ru changed: What|Removed |Added CC||fche at redhat dot com, ||belyshev at depni dot sinp ||dot msu dot ru Last reconfirmed|2005-10-11 07:32:46 |2007-09-21 06:56:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20003
[Bug bootstrap/32009] [4.3 Regression] building gcc4-4.3.0-20070518 failed on OSX 10.3.9
--- Comment #19 from bonzini at gnu dot org 2007-09-21 07:50 --- I have a patch, I'll get around to testing it next week, promised. :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32009
[Bug fortran/33513] error reported on correct initialization code.
--- Comment #2 from burnus at gcc dot gnu dot org 2007-09-21 07:58 --- I can reproduce the problem with gfortran 4.1 and 4.2 with -std=f95/-std=f2003; however, gfortran 4.3.0 compiles this program with -std=f95 without showing this error. I therefore suggest you to either don't use -std=f95 or -std=f2003 for this file or to use the 4.3.0 compiler of gfortran, available from, e.g., http://gcc.gnu.org/wiki/GFortranBinaries As this bug is no regression, does not generate wrong code and can easily be worked around by not using -std=f*, we will not backport the fixes to GCC 4.2.x or even 4.1.x. (Last but not least in order to not inadvertently induce regressions.) It would be nice, if you could confirm that the error is indeed fixed in GCC 4.3.0. Thanks for reporting the bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33513
[Bug c++/33516] [4.0/4.1/4.2/4.3 Regression] Rejects typedef qualified name-lookup
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-09-21 08:56 --- What I can find that supports rejecting the code is: 3.4.3(1) Qualified name lookup: If the name found is not a class-name (clause 9) or namespace-name (7.3.1), the program is ill-formed. 7.1.3 The typedef specifier it says: A name declared with the typedef specifier becomes a typedef-name. but then the last example should be rejected as well? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33516
[Bug c++/33516] New: [4.0/4.1/4.2/4.3 Regression] Rejects typedef qualified name-lookup
struct foo_bar;
typedef foo_bar bar;
struct foo_bar {
typedef int baz;
bar::baz ii;
};
t.C:7: error: baz in class bar does not name a type
or as originally reported:
struct foo_bar;
namespace foo {
typedef foo_bar bar;
};
struct foo_bar {
typedef int baz;
foo::bar::baz ii;
};
t.C:9: error: baz in class foo::bar does not name a type
moving the declaration of ii out of foo_bar, the code is accepted:
struct foo_bar;
typedef foo_bar bar;
struct foo_bar {
typedef int baz;
};
bar::baz ii;
EDG happily accepts the code in strict-ansi mode.
--
Summary: [4.0/4.1/4.2/4.3 Regression] Rejects typedef qualified
name-lookup
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33516
[Bug c++/33515] Inconsistent warning about defined but not used when there is an error
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-09-21 09:08 --- I think there is already a bug about this. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|Inconsistent warning about |Inconsistent warning about |defined but not used |defined but not used when ||there is an error http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33515
[Bug c++/32205] defined but not used warning given or not depending on other errors
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-09-21 09:09 --- *** Bug 33515 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||mec at google dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32205
[Bug c++/33515] Inconsistent warning about defined but not used when there is an error
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-09-21 09:09 --- Yep, PR 32205. *** This bug has been marked as a duplicate of 32205 *** -- 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=33515
unsigned long long bitfield RTL generation bug (H8 specific ?)
Hi Jeff, Hi Kazu,
We have run across an H8300 RTL generation bug which I think might be
generic, rather than specific to the H8300, although it may only
trigger for small targets.
Given the following source file:
struct fields { unsigned long long u2 : 33; } flags;
int main (void) { flags.u2 = 0x1ULL; return 0; }
Compile with an h8300-elf toolchain. (I used -O2 but this is not
necessary in order to reproduce the bug). If you run this inside
GDB and break on the return you will find that flags.u2 only
contains 0x1!
Looking at the RTL generated in the expand pass (105r.expand) shows
that something very weird is going on. (RTL trimmed slightly for
this email):
;; flags.u2 = 1
(insn 11 (set (reg:HI 19) (const:HI (plus:HI (symbol_ref:HI
(flags)) (const_int 2
(insn 12 (set (reg:HI 20) (mem:HI (reg:HI 19)))
(insn 13 (set (reg:HI 21) (ior:HI (reg:HI 20) (const_int 0x7fff)))
(insn 14 (set (mem:HI (reg:HI 19)) (reg:HI 21))
(insn 15 (set (reg:HI 22) (const:HI (plus:HI (symbol_ref:HI
(flags)) (const_int 4
(insn 16 (set (reg:QI 23) (mem:QI (reg:HI 22)))
(insn 17 (set (reg:QI 24) (ior:QI (reg:QI 23) (const_int 0x80)))
(insn 18 (set (mem:QI (reg:HI 22)) (reg:QI 24))
(insn 19 (set (reg:HI 25) (symbol_ref:HI (flags)))
(insn 20 (set (reg:HI 26) (mem:HI (reg:HI 25)))
(insn 21 (set (reg:HI 27) (and:HI (reg:HI 26) (const_int 0x8000)))
(insn 22 (set (mem:HI (reg:HI 25)) (reg:HI 27))
(insn 23 (set (reg:HI 28) (const:HI (plus:HI (symbol_ref:HI
(flags)) (const_int 2
(insn 24 (set (reg:QI 29) (mem:QI (reg:HI 28)))
(insn 25 (set (reg:QI 30) (ior:QI (reg:QI 29) (const_int 0x80)))
(insn 26 (set (mem:QI (reg:HI 28)) (reg:QI 30))
(insn 27 (set (reg:HI 31) (symbol_ref:HI (flags)))
(insn 28 (set (reg:QI 32) (mem:QI (reg:HI 31)))
(insn 29 (set (reg:QI 33) (and:QI (reg:QI 32) (const_int 0x7f)))
(insn 30 (set (mem:QI (reg:HI 31)) (reg:QI 33))
Gcc appears to have a completely broken idea of how the u2 bitfield
is laid out. When I saw that this was happening in RTL generation
I baulked and decided to call in the big guns - you guys :-)
What do you think. Is this a generic bitfield allocation problem in
gcc ?
Cheers
Nick
[Bug middle-end/33280] [4.3 regression] FAIL: gcc.c-torture/execute/990404-1.c execution at -O3
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Summary|FAIL: gcc.c-|[4.3 regression] FAIL: |torture/execute/990404-1.c |gcc.c- |execution at -O3|torture/execute/990404-1.c ||execution at -O3 Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33280
[Bug tree-optimization/33508] [4.3 Regression] tree struct aliasing goes into a loop marking call clobbers.
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-09-21 09:37 --- Subject: Bug 33508 Author: rguenth Date: Fri Sep 21 09:36:52 2007 New Revision: 128645 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128645 Log: 2007-09-21 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/33508 * tree-ssa-alias.c (mark_aliases_call_clobbered): Avoid quadratic loop by keeping a bitmap of variables we have to clobber all subvariables for. (set_initial_properties): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-alias.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33508
[Bug c/33238] [4.1/4.2 Regression] ICE on statement expression using variable-sized structure in tree_low_cst, at tree.c:4502
--- Comment #4 from jakub at gcc dot gnu dot org 2007-09-21 09:50 --- Fixed so far for 4.3. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.0.0 4.1.2 4.2.1 4.3.0 |4.0.0 4.1.2 4.2.1 Known to work|3.4.6 |3.4.6 4.3.0 Summary|[4.1/4.2/4.3 Regression] ICE|[4.1/4.2 Regression] ICE on |on statement expression |statement expression using |using variable-sized|variable-sized structure in |structure in tree_low_cst, |tree_low_cst, at tree.c:4502 |at tree.c:4502 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33238
[Bug c/27301] [4.0/4.1/4.2 Regression] ICE on convoluted inline asm with m (statement expression and vla)
--- Comment #8 from jakub at gcc dot gnu dot org 2007-09-21 09:50 --- Fixed so far in 4.3. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Known to work||4.3.0 Summary|[4.0/4.1/4.2/4.3 Regression]|[4.0/4.1/4.2 Regression] ICE |ICE on convoluted inline asm|on convoluted inline asm |with m (statement |with m (statement |expression and vla) |expression and vla) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27301
[Bug c++/33496] [4.3 regression] ICE with sizeof for invalid argument pack
--- Comment #2 from jakub at gcc dot gnu dot org 2007-09-21 09:51 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33496
[Bug tree-optimization/33508] [4.3 Regression] tree struct aliasing goes into a loop marking call clobbers.
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-09-21 09:38 --- 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=33508
[Bug tree-optimization/33146] [4.3 Regression] ICE in build_polynomial_chrec, at tree-chrec.h:136
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-09-21 10:20 --- The problem is that fold_binary converts (long)ptr * -1 to (long)-ptr: /* Transform x * -1 into -x. */ if (integer_all_onesp (arg1)) return fold_convert (type, negate_expr (arg0)); we shouldn't negate a pointer I think. Still if we negate op0 here, negate_expr strips sing-nops and ends up producing -ptr again :/ Sort of a mess... (asserting that we do not call negate_expr on pointers reveals even more problems) Anyway, the following fixes it: Index: fold-const.c === --- fold-const.c(revision 128644) +++ fold-const.c(working copy) @@ -10242,7 +10242,7 @@ fold_binary (enum tree_code code, tree t return non_lvalue (fold_convert (type, arg0)); /* Transform x * -1 into -x. */ if (integer_all_onesp (arg1)) - return fold_convert (type, negate_expr (arg0)); + return fold_convert (type, negate_expr (op0)); /* Transform x * -C into -x * C if x is easily negatable. */ if (TREE_CODE (arg1) == INTEGER_CST tree_int_cst_sgn (arg1) == -1 Index: tree.h === --- tree.h (revision 128644) +++ tree.h (working copy) @@ -1019,7 +1019,9 @@ extern void omp_clause_range_check_faile (TYPE_MODE (TREE_TYPE (EXP))\ == TYPE_MODE (TREE_TYPE (TREE_OPERAND (EXP, 0 \ (TYPE_UNSIGNED (TREE_TYPE (EXP))\ -== TYPE_UNSIGNED (TREE_TYPE (TREE_OPERAND (EXP, 0) \ +== TYPE_UNSIGNED (TREE_TYPE (TREE_OPERAND (EXP, 0 \ + (POINTER_TYPE_P (TREE_TYPE (EXP)) \ +== POINTER_TYPE_P (TREE_TYPE (TREE_OPERAND (EXP, 0) \ (EXP) = TREE_OPERAND (EXP, 0) /* Like STRIP_NOPS, but don't alter the TREE_TYPE either. */ Andrew, with POINTER_PLUS_EXPR, do we still allow negating a pointer? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33146
[Bug fortran/33037] TRANSFER should warn on mismatched sizes
--- Comment #6 from burnus at gcc dot gnu dot org 2007-09-21 10:21 --- Subject: Bug 33037 Author: burnus Date: Fri Sep 21 10:21:29 2007 New Revision: 128646 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128646 Log: 2007-09-21 Tobias Burnus [EMAIL PROTECTED] PR fortran/33037 * simplify.c (gfc_simplify_transfer): Warn if source size is smaller than result size. 2007-09-21 Tobias Burnus [EMAIL PROTECTED] PR fortran/33037 * gfortran.dg/transfer_check_1.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/transfer_check_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/simplify.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33037
[Bug c/33517] New: bit field cause an internal compiler error: in schedule_region
Compiler:
v850-elf-gcc -v
Reading specs from /usr/local/gcc333/lib/gcc-lib/v850-elf/3.3.3/specs
Configured with: ../configure --target=v850-elf --prefix=/usr/local/gcc333
--with-newlib --enable-languages=c
Thread model: single
gcc version 3.3.3
Source code:
typedef unsigned long long int U64;// 64-bit unsigned integer
typedef unsigned long int U32;// 32-bit unsigned integer
typedef unsigned short int U16;// 16-bit unsigned integer
typedef unsigned char U8; //8-bit unsigned integer
typedef signed long long intS64;// 64-bit integer
typedef signed long int S32;// 32-bit integer
typedef signed short intS16;// 16-bit integer
typedef signed char S8; //8-bit integer
#define REG_CNT 9
typedef struct
{
// register configuration structure
U8 bit1:1;
U8 bit2:1;
U8 bit3:1;
U8 bit4:1 ;
U8 bit5:1;
U8 Par;
} REG_CONF_S;
static REG_CONF_S regConf[ REG_CNT ];
extern U8 readRegConfEep( U8 reg, REG_CONF_S *confPtr );
extern U8 writeRegConfEep( U8 reg, const REG_CONF_S * const confPtr );
/* Function /
int writeRegOnAutoScroll( int reg, int newAutoScroll )
/*/
{
REG_CONF_S eepConf;
if (reg REG_CNT) // valid register
{
// read old conf
if ( readRegConfEep( reg, eepConf ) == 0 )
{
eepConf.bit5 = newAutoScroll ? 1 : 0; // new state to conf
if ( writeRegConfEep( reg, eepConf ) == 0 ) // OK
{
regConf[ reg ] = eepConf; // restore ram
return 0;
}
else // eeprom error
{
return -3;
}
}
else // eeprom error
{
return -3;
}
}
else // invalid reg number
{
return -2;
}
} // writeRegOnAutoScroll
compile command:
v850-elf-gcc -mv850e -mdisable-callt -Wall -O2 -c -o ccerror.o ccerror.c
Error:
ccerror.c: In function `writeRegOnAutoScroll':
ccerror.c:75: internal compiler error: in schedule_region, at sched-rgn.c:2849
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
Compilation exited abnormally with code 1 at Fri Sep 21 11:16:49
Comments:
If I remove -O2 from command line then the error disappers,
also if I change the bit field bit5 before bit4 the compiler works good.
(Do the function work good in target system - that I don't know yet, but I will
test it soon)
Native compiler 3.4.2 compiles good
I had search that kind error from bug list, but I didn't find, so I write new
one.
t: Veikko Turkia
--
Summary: bit field cause an internal compiler error: in
schedule_region
Product: gcc
Version: 3.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: veikko dot turkia at enermet dot com
GCC build triplet: v850-elf-gcc -mv850e -mdisable-callt -Wall -O2 -c -o
ccerror.o c
GCC host triplet: linux fedora core release 3 kernel 2.6.9-1.667smp on an
i686
GCC target triplet: NEC v850 es
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33517
[Bug fortran/33037] TRANSFER should warn on mismatched sizes
--- Comment #7 from burnus at gcc dot gnu dot org 2007-09-21 10:32 --- Partially fixed. Missing: Check whether the size of the LHS is bigger than the result of TRANSFER (see example in this PR's comment 0). The current fix gives the warning only if the specified (SIZE=...) result size is larger than the source size (cf. example in bug 31610 comment 0). -- burnus at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|gcc version 4.3.0 20070511 | |(experimental) | GCC host triplet|powerpc-apple-darwin8.9.0 | GCC target triplet|powerpc-apple-darwin8.9.0 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33037
[Bug fortran/33455] MERGE intrinsic: Check for same string lengths
--- Comment #2 from burnus at gcc dot gnu dot org 2007-09-21 10:44 --- Subject: Bug 33455 Author: burnus Date: Fri Sep 21 10:44:20 2007 New Revision: 128647 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128647 Log: 2007-09-21 Tobias Burnus [EMAIL PROTECTED] PR fortran/33455 * check.c (check_same_strlen): New function. (gfc_check_merge): Use it. 2007-09-21 Tobias Burnus [EMAIL PROTECTED] PR fortran/33455 * gfortran.dg/merge_char_3.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/merge_char_2.f90 Modified: trunk/gcc/fortran/check.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33455
[Bug libfortran/26253] fallback scalbn doesn't handle denormals correctly
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-09-21 10:54 --- Subject: Bug 26253 Author: fxcoudert Date: Fri Sep 21 10:54:20 2007 New Revision: 128648 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128648 Log: PR libfortran/26253 * intrinsics/c99_functions.c (scalbn): Use ldexp if appopriate. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/intrinsics/c99_functions.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26253
[Bug libfortran/26253] fallback scalbn doesn't handle denormals correctly
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2007-09-21 10:55 --- This should now be fixed. Please reopen if I fumbled in any way and the issue is still present. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26253
[Bug fortran/33455] MERGE intrinsic: Check for same string lengths
--- Comment #3 from burnus at gcc dot gnu dot org 2007-09-21 11:27 --- Fixed on the trunk (4.3.0). -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33455
[Bug fortran/33439] OpenMP: Incorrect error message for chunksize variable
--- Comment #6 from jakub at gcc dot gnu dot org 2007-09-21 11:17 --- Subject: Bug 33439 Author: jakub Date: Fri Sep 21 11:17:13 2007 New Revision: 128649 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128649 Log: PR fortran/33439 * gfortran.dg/gomp/pr33439.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/gomp/pr33439.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33439
[Bug libfortran/30780] FPE in CPU_TIME (and possibly others) with -ffpe-trap=underflow
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2007-09-21 11:59 --- (In reply to comment #9) Maybe one should put it additionally also in the documentation of the CPU_TIME intrinsic subroutine. Yep, but I suspect that CPU_TIME is not the only routine library routine that can trigger this exception. I don't feel like going through all library routines and check which can fail, but the I/O system certainly can trigger it also, as Jerry observed, so I was thinking of adding a more general kind of remark. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30780
[Bug libfortran/30780] FPE in CPU_TIME (and possibly others) with -ffpe-trap=underflow
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-09-21 11:37 --- I'm changing this into a documentation PR, and assign it to myself. It was decided that there really isn't a good way to provide high-quality timer functions with precision-loss trapping. We need to document this shortcoming in the -ffpe-trap option doc. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED GCC target triplet|x86_64-redhat-linux | Keywords||documentation Last reconfirmed|2007-02-13 04:26:26 |2007-09-21 11:37:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30780
[Bug libfortran/30780] FPE in CPU_TIME (and possibly others) with -ffpe-trap=underflow
--- Comment #9 from burnus at gcc dot gnu dot org 2007-09-21 11:45 --- We need to document this shortcoming in the -ffpe-trap option doc. Maybe one should put it additionally also in the documentation of the CPU_TIME intrinsic subroutine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30780
[Bug c++/30659] [4.0/4.1/4.2/4.3 Regression] ICE in undefined template
-- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30659
[Bug target/33381] [4.2 regression] miscompilation casting signed long to void*
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-09-21 13:04 ---
Shorter testcase:
void x(void *data);
void test()
{
long i;
for (i = 0; i 5; i++)
if (i 0)
x((void *)(i - 1));
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33381
[Bug target/33381] [4.2 regression] miscompilation casting signed long to void*
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-09-21 13:36 --- This was fixed by the introduction of pointer-plus, which removed all traces of fold_used_pointer* in tree-scalar-evolution.c. A safe patch would go along the following: Index: tree-vrp.c === --- tree-vrp.c (revision 128649) +++ tree-vrp.c (working copy) @@ -2482,6 +2482,13 @@ adjust_range_with_scev (value_range_t *v if (vr-type == VR_ANTI_RANGE) return; + /* Don't try to feed SCEV with casts to pointer type. */ + if (TREE_CODE (stmt) == MODIFY_EXPR + (TREE_CODE (TREE_OPERAND (stmt, 1)) == NOP_EXPR + || TREE_CODE (TREE_OPERAND (stmt, 1)) == CONVERT_EXPR) + POINTER_TYPE_P (TREE_TYPE (TREE_OPERAND (stmt, 1 +return; + chrec = instantiate_parameters (loop, analyze_scalar_evolution (loop, var)); if (TREE_CODE (chrec) != POLYNOMIAL_CHREC) return; -- 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-09-11 11:31:46 |2007-09-21 13:36:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33381
[Bug tree-optimization/33099] [4.2 Regression] Scalar evolutions confusing VRP with pointer values that wrap around
-- 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-17 20:18:57 |2007-09-21 13:55:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33099
[Bug middle-end/33472] ICE and invalid rtl sharing with complex on x86_64-mingw
--- Comment #5 from ktietz at onevision dot com 2007-09-21 13:26 ---
The bug is related to i386.c function 'return_in_memory_ms_64':
The return statement of this function has to be extended by SCmode.
Patch looks like:
static int
return_in_memory_ms_64 (const_tree type, enum machine_mode mode)
{
HOST_WIDE_INT size = int_size_in_bytes (type);
/* __m128 and friends are returned in xmm0. */
if (size == 16 VECTOR_MODE_P (mode))
return 0;
/* Otherwise, the size must be exactly in [1248]. */
- return (size != 1 size != 2 size != 4 size != 8);
+ return (size != 1 size != 2 size != 4 size != 8) || mode == SCmode;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33472
[Bug c++/33518] New: unused code changes the result of name lookup
Hello,
I know this may look like issue #15910, but please read still. g++ refuses to
compile the following code because it wants to use std::distance. But if I
remove the code about class Wx, which is not used anywhere, g++ now uses
::distance without complaining. Whichever the right answer is, g++ is not being
consistent here. Note that comeau and sunCC both use ::distance in both cases.
#include iterator
namespace boost
{
namespace detail {
struct empty_base {};
using std::distance;
}
template class T, class B = ::boost::detail::empty_base
struct ordered_field_operators1 {};
}
namespace CGAL {
template class NT_
class Quotient
: boost::ordered_field_operators1 QuotientNT_
{
};
class MP_Float{};
namespace INTERN_MP_FLOAT {
double to_double(const MP_Float);
double to_double(const QuotientMP_Float);
}
template class T class Wx{};
template class Wx MP_Float
{
public:
class To_double
{
public:
double operator()( const MP_Float x ) const {
return INTERN_MP_FLOAT::to_double( x );
}
};
};
}
typedef CGAL::QuotientCGAL::MP_Float NT;
namespace C{
template class T struct TutorialR{};
template class T struct Point{};
}
typedef C::PointC::TutorialRNT Point;
double distance(const Point p, const Point q)
{
return 3;
}
int main()
{
Point p1;
Point p2;
distance(p1,p2);
return 0;
}
--
Summary: unused code changes the result of name lookup
Product: gcc
Version: 4.2.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: marc dot glisse at normalesup dot org
GCC host triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33518
[Bug libfortran/31546] add --enable-intermodule
--- Comment #9 from aldot at gcc dot gnu dot org 2007-09-21 15:54 --- Created an attachment (id=14238) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14238action=view) add --enable-intermodule for libgfortran 2007-09-21 Bernhard Fischer aldot PR fortran/31546 * (configure.ac): Add --enable-intermodule for onestep build. * (Makefile.am): Handle onestep build. * (configure, Makefile.in): Regenerate. -- aldot at gcc dot gnu dot org changed: What|Removed |Added Attachment #14096|0 |1 is obsolete|| Attachment #14116|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31546
[Bug libfortran/31546] add --enable-intermodule
--- Comment #10 from aldot at gcc dot gnu dot org 2007-09-21 15:56 --- fx, I cannot apply this patch since i cannot autoreconf with the appropriate versions of autoconf and automake. Can you apply it with the regenerated files, please (and assign this bug to you, if you want)? TIA, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31546
[Bug fortran/33499] Spurious errors compiling a module with a contained function with an ENTRY
--- Comment #1 from pault at gcc dot gnu dot org 2007-09-21 15:27 --- Confirmed - thanks for the report. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33499
[Bug c/33519] New: Invalid code generated with a combination of thumb, AAPCS and -Os.
GCC generates odd code sequence..
Part of the source (full source in attachment):
usbd_status
usbd_do_request_flags_pipe(usbd_device_handle dev, usbd_pipe_handle pipe,
usb_device_request_t *req, void *data, u_int16_t flags, int *actlen,
u_int32_t timeout)
{
usbd_xfer_handle xfer;
usbd_status err;
xfer = usbd_alloc_xfer(dev);
...
objdump output:
usbd_do_request_flags_pipe:
0: b5f0push{r4, r5, r6, r7, lr}
2: b089sub sp, #36
4: 1c14addsr4, r2, #0
6: 9a0fldr r2, [sp, #60]
8: 1c1eaddsr6, r3, #0
a: 605astr r2, [r3, #4]-- writes using r3 (data)
c: 9b10ldr r3, [sp, #64]
e: 9007str r0, [sp, #28]
10: 609bstr r3, [r3, #8]
12: ab0eadd r3, sp, #56
14: 9106str r1, [sp, #24]
16: 881fldrhr7, [r3, #0]
18: f7ff fffe bl 0 usbd_alloc_xfer
And here's objdump output when compiled with the same options but gcc 4.2.1:
usbd_do_request_flags_pipe:
0: b5f0push{r4, r5, r6, r7, lr}
2: b089sub sp, #36
4: 1c1eaddsr6, r3, #0
6: ab0eadd r3, sp, #56
8: 9007str r0, [sp, #28]
a: 9106str r1, [sp, #24]
c: 1c14addsr4, r2, #0
e: 881fldrhr7, [r3, #0]
10: f7ff fffe bl 0 usbd_alloc_xfer
Environment:
System: Linux kivi 2.6.20-16-generic #2 SMP Thu Jun 7 20:19:32 UTC 2007 i686
GNU/Linux
Architecture: i686
host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: arm-unknown-elf
configured with: /s/devel/gcc-4.1.1/configure --target=arm-elf --with-gnu-as
--with-gcc --with-gnu-ld --enable-languages=c --disable-libstdc
--disable-hosted-libstdcxx --disable-libstdcxx --disable-libstdcxx-v3
--disable-libstdcxx_v3 --disable-nls --disable-shared --disable-threads
--disable-libmudflap --disable-libssp --disable-libgomp --disable-libstdcxx-pch
--prefix=/emb/arm-elf-gcc-4.1.1 --program-prefix=arm-elf- --program-suffix=
--with-newlib -v --without-headers -v
How-To-Repeat:
Compile the test case like:
# arm-elf-gcc -Os -Wall -Werror -mcpu=arm920t -mlittle-endian -mthumb
-mabi=aapcs -c usbdi.c -o usbdi.o
--- Comment #1 from sami dot kantoluoto at embedtronics dot fi 2007-09-21
16:29 ---
Fix:
Work arounds: gcc 4.2.1, optimize for speed instead of size.
--
Summary: Invalid code generated with a combination of thumb,
AAPCS and -Os.
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sami dot kantoluoto at embedtronics dot fi
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: arm-unknown-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33519
[Bug c/33519] Invalid code generated with a combination of thumb, AAPCS and -Os.
--- Comment #2 from sami dot kantoluoto at embedtronics dot fi 2007-09-21 16:32 --- Created an attachment (id=14239) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14239action=view) Test case Source code triggering the bug added. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33519
[Bug fortran/33376] [4.3 regression] USE with renaming, assembler message: symbol already defined
--- Comment #3 from pault at gcc dot gnu dot org 2007-09-21 16:48 --- Hi Harald! The number of your testcase is depressing but I'll take it on anyway; it's related to PR7, as well as PR31564, whose patch caused this regression. There is some wierdness going on with name-mangling that I am sure is the cause. Cheers Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33376
[Bug c++/25137] Warning missing braces around initializer causing problems with tr1::array
--- Comment #11 from pcarlini at suse dot de 2007-09-21 16:50 --- Looking into it: I mean to investigate whether a relaxed warning per Comment #9 is implementable in a decently clean way. -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-09-21 16:50:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25137
[Bug fortran/33499] Spurious errors compiling a module with a contained function with an ENTRY
--- Comment #2 from pault at gcc dot gnu dot org 2007-09-21 16:38 --- Hmmm. It helps to actually confirm it. -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-09-21 16:38:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33499
[Bug fortran/33376] [4.3 regression] USE with renaming, assembler message: symbol already defined
--- Comment #4 from pault at gcc dot gnu dot org 2007-09-21 17:18 --- It's mine. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-09-10 11:36:44 |2007-09-21 17:18:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33376
[Bug c++/33520] Usage of extern inline functions violates C++ standard dcl 7.1.2 (4)
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-09-21 18:47 --- In fact it does. This is a hard bug to fix without all translation units aviable at compile time. So I am going to close as won't fix. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33520
[Bug c++/33520] New: Usage of extern inline functions violates C++ standard dcl 7.1.2 (4)
According to C++ standard 7.1.2 (4):
An inline function shall be defined in every translation unit in which
it is used and shall have exactly the same definition in every case
For the following code:
-
inline.cc
-
#include stdio.h
inline void foo() {
printf(Hey!\n);
}
void bar() {
foo();
}
--
main.cc
--
extern void foo();
int main() {
foo();
return 0;
}
--
g++ -std=c++98 main.cc inline.cc
creates a program and does not report any violation of the standard.
--
Summary: Usage of extern inline functions violates C++ standard
dcl 7.1.2 (4)
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at artemfrolov dot fastmail dot fm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33520
[Bug c++/33520] Usage of extern inline functions violates C++ standard dcl 7.1.2 (4)
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-09-21 18:43 --- I think it also mentions in the same pargraph that this violation does not have to be diagnostic. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33520
[Bug c++/28293] ICE on invalid typedef
--- Comment #2 from pcarlini at suse dot de 2007-09-21 19:12 --- On it. -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28293
[Bug c++/33521] -m128bit-long-double and printf don't mix
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-09-21 19:18 --- And -m128bit-long-double is an ABI change so what do you expect??? -- 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=33521
[Bug c++/33521] New: -m128bit-long-double and printf don't mix
[#include stdlib.h // EXIT_SUCCESS
#include stdio.h // printf
int main(int argc, char** argv) {
long double ld = 1.0;
printf(ld = %Lg, string = %s\n, ld, foo);
return (EXIT_SUCCESS);
}]
[g++ -m128bit-long-double -Wall main.cpp -o test ./test]
With the wider long double, a corrupted value is printed at %s. If the ld
declaration is changed to [long double ld = 1.0, lda[10];], nothing is printed,
and if the declaration is changed to [long double ld = 1.0, lda[1];],
(null) is printed (without the quotes). If the -m128bit-long-double flag is
omitted, or if the %Lg is omitted (and its corresponding argument), no problems
occur (although I have not tested all 12 combinations). If this shouldn't be
tried at all (printf is in a library that was compiled with normal-width long
doubles), it would be nice to at least have a warning about it, but there seems
to be more than that going on. I may have no further interest in this issue,
which was encountered during some experiments.
--
Summary: -m128bit-long-double and printf don't mix
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Raf_Schietekat at ieee dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33521
[Bug fortran/33522] New: Incorrect warning messages about uninitialized variables
These incorrect messages have been appearing lately. The variables are always and only accessed in the save branch of the switch statements - so they will never and can never be used uninitialized. [dranta:~/tests/gfortran-D] dir% gfortran -c -O2 -Wuninitialized module_files.f90 module_files.f90: In function 'my_sio_file_read_common': module_files.f90:36: warning: 'scratch_r8.dim[1].stride' may be used uninitialized in this function module_files.f90:36: warning: 'scratch_r8.offset' may be used uninitialized in this function module_files.f90:35: warning: 'scratch_i4.dim[1].stride' may be used uninitialized in this function module_files.f90:35: warning: 'scratch_i4.offset' may be used uninitialized in this function [dranta:~/tests/gfortran-D] dir% gfortran --v Using built-in specs. Target: powerpc-apple-darwin8.10.0 Configured with: ../gcc/configure --disable-bootstrap --enable-multilib --prefix=/usr/local/gfortran --enable-languages=c,fortran Thread model: posix gcc version 4.3.0 20070921 (experimental) (GCC) -- Summary: Incorrect warning messages about uninitialized variables Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dir at lanl dot gov GCC host triplet: powerpc-apple-darwin8.10.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33522
[Bug fortran/33522] Incorrect warning messages about uninitialized variables
--- Comment #1 from dir at lanl dot gov 2007-09-21 19:25 --- Created an attachment (id=14240) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14240action=view) The fortran source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33522
[Bug fortran/33523] New: Incorrect warning messages about uninitialized variables
These incorrect messages have been appearing lately. The variables are always and only accessed in the save branch of the switch statements - so they will never and can never be used uninitialized. [dranta:~/tests/gfortran-D] dir% gfortran -c -O2 -Wuninitialized module_files.f90 module_files.f90: In function 'my_sio_file_read_common': module_files.f90:36: warning: 'scratch_r8.dim[1].stride' may be used uninitialized in this function module_files.f90:36: warning: 'scratch_r8.offset' may be used uninitialized in this function module_files.f90:35: warning: 'scratch_i4.dim[1].stride' may be used uninitialized in this function module_files.f90:35: warning: 'scratch_i4.offset' may be used uninitialized in this function [dranta:~/tests/gfortran-D] dir% gfortran --v Using built-in specs. Target: powerpc-apple-darwin8.10.0 Configured with: ../gcc/configure --disable-bootstrap --enable-multilib --prefix=/usr/local/gfortran --enable-languages=c,fortran Thread model: posix gcc version 4.3.0 20070921 (experimental) (GCC) -- Summary: Incorrect warning messages about uninitialized variables Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dir at lanl dot gov GCC host triplet: powerpc-apple-darwin8.10.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33523
[Bug c++/29615] Class can't be friends of itself?
-- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29615
[Bug libfortran/31546] add --enable-intermodule
--- Comment #11 from fxcoudert at gcc dot gnu dot org 2007-09-21 19:49 --- Subject: Bug 31546 Author: fxcoudert Date: Fri Sep 21 19:49:34 2007 New Revision: 128654 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128654 Log: PR fortran/31546 * (configure.ac): Add --enable-intermodule for onestep build. * (Makefile.am): Handle onestep build. * (configure, Makefile.in): Regenerate. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/Makefile.am trunk/libgfortran/Makefile.in trunk/libgfortran/configure trunk/libgfortran/configure.ac -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31546
[Bug libfortran/31546] add --enable-intermodule
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2007-09-21 19:50 --- Fixed. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31546
[Bug libfortran/21226] unix_stream small_buffer unaligned
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-09-21 19:53 --- Closing. small_buffer will go away when we implement PR 25561 (Eventually get rid of the Alloc Stream Facility). -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21226
[Bug libfortran/22307] Missing tests for actual library functions
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-09-21 19:55 --- Closing, as we probably want one testsuite (in gcc/testsuite) rather than adding a separate library testsuite. (http://gcc.gnu.org/ml/fortran/2007-09/msg00234.html) -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22307
[Bug fortran/21881] ICE instead of error for large arrays in derived types
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-09-21 19:56 --- For now, we should simply change the ICE into a standard error. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Severity|enhancement |normal Component|libfortran |fortran Keywords||ice-on-valid-code Last reconfirmed|2005-12-28 06:36:10 |2007-09-21 19:56:35 date|| Summary|Array descriptors limit |ICE instead of error for |derived type sizes |large arrays in derived ||types http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21881
[Bug rtl-optimization/30113] [4.1 Regression] ICE in trunc_int_for_mode
--- Comment #6 from pthaugen at gcc dot gnu dot org 2007-09-21 20:17 --- Subject: Bug 30113 Author: pthaugen Date: Fri Sep 21 20:17:04 2007 New Revision: 128656 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128656 Log: 2007-09-21 Pat Haugen [EMAIL PROTECTED] Backport the following patch: 2006-12-11 Zdenek Dvorak [EMAIL PROTECTED] PR rtl-optimization/30113 * loop-iv.c (implies_p): Require the mode of the operands to be scalar. Modified: branches/ibm/gcc-4_1-branch/gcc/ChangeLog branches/ibm/gcc-4_1-branch/gcc/loop-iv.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30113
[Bug bootstrap/33511] make fails with no rule to make target 'all' in directory gcc
--- Comment #4 from gmills at library dot berkeley dot edu 2007-09-21 20:34 --- With the following configure string /usr/local/src/gcc-4.2.1/configure --enable-languages=c,c++,objc,obj-c++ --with-gnu-as --with-gnu-ld I am getting this error. In file included from /usr/local/src/gcc-4.2.1-target/sparc-sun-solaris2.8/libstdc++-v3/include/ext/pb_ds/detail/standard_policies.hpp:51, from /usr/local/src/gcc-4.2.1-target/sparc-sun-solaris2.8/libstdc++-v3/include/ext/pb_ds/assoc_container.hpp:52, from /usr/local/src/gcc-4.2.1/libstdc++-v3/include/precompiled/extc++.h:59: /usr/local/src/gcc-4.2.1-target/sparc-sun-solaris2.8/libstdc++-v3/include/ext/pb_ds/hash_policy.hpp:293:81: error: ext/pb_ds/detail/resize_policy/hash_load_check_resize_trigger_imp.hpp: No such file or directory In file included from /usr/local/src/gcc-4.2.1-target/sparc-sun-solaris2.8/libstdc++-v3/include/ext/pb_ds/detail/rb_tree_map_/rb_tree_.hpp:54, from /usr/local/src/gcc-4.2.1-target/sparc-sun-solaris2.8/libstdc++-v3/include/ext/pb_ds/detail/container_base_dispatch.hpp:61, from /usr/local/src/gcc-4.2.1-target/sparc-sun-solaris2.8/libstdc++-v3/include/ext/pb_ds/assoc_container.hpp:53, from /usr/local/src/gcc-4.2.1/libstdc++-v3/include/precompiled/extc++.h:59: /usr/local/src/gcc-4.2.1-target/sparc-sun-solaris2.8/libstdc++-v3/include/ext/pb_ds/detail/bin_search_tree_/bin_search_tree_.hpp:473:81: error: ext/pb_ds/detail/bin_search_tree_/constructors_destructor_fn_imps.hpp: No such file or directory make[4]: *** [sparc-sun-solaris2.8/bits/extc++.h.gch/O2g.gch] Error 1 make[4]: Leaving directory `/usr/local/src/gcc-4.2.1-target/sparc-sun-solaris2.8/libstdc++-v3/include' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/usr/local/src/gcc-4.2.1-target/sparc-sun-solaris2.8/libstdc++-v3' make[2]: *** [all] Error 2 make[2]: Leaving directory `/usr/local/src/gcc-4.2.1-target/sparc-sun-solaris2.8/libstdc++-v3' make[1]: *** [all-target-libstdc++-v3] Error 2 make[1]: Leaving directory `/usr/local/src/gcc-4.2.1-target' make: *** [all] Error 2 -- gmills at library dot berkeley dot edu changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33511
[Bug bootstrap/33511] make fails with no rule to make target 'all' in directory gcc
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2007-09-21 20:40 --- /usr/local/src/gcc-4.2.1/configure --enable-languages=c,c++,objc,obj-c++ --with-gnu-as --with-gnu-ld I am getting this error. Aren't you again building within the source tree? -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33511
[Bug target/33524] New: SSE5 vectorized SI-DI conversions broken
If you use -O2 -ftree-vectorize -msse5 (or now -O3 -msse5), the compiler generates an insn not found message, because there is a typo in i386.c. -- Summary: SSE5 vectorized SI-DI conversions broken Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: michael dot meissner at amd dot com GCC build triplet: x86_64-pc-gnu-linux GCC host triplet: x86_64-pc-gnu-linux GCC target triplet: x86_64-pc-gnu-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33524
[Bug target/33524] SSE5 vectorized SI-DI conversions broken
--- Comment #1 from michael dot meissner at amd dot com 2007-09-21 20:50 --- Created an attachment (id=14241) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14241action=view) Patch to fix problem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33524
[Bug target/33524] SSE5 vectorized SI-DI conversions broken
--- Comment #2 from michael dot meissner at amd dot com 2007-09-21 20:51 --- Created an attachment (id=14242) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14242action=view) Test case that replicates the file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33524
[Bug fortran/33334] User-defined type as function result: use-assocciated not accepted
--- Comment #2 from pault at gcc dot gnu dot org 2007-09-21 20:55 --- I've just sorted PRs 7 and 33376, so I'll tunr back to these fellows next. This is confirmed, of course. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-09-21 20:55:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4
[Bug bootstrap/33511] make fails with no rule to make target 'all' in directory gcc
--- Comment #6 from gmills at library dot berkeley dot edu 2007-09-21 20:56 --- Subject: Re: make fails with no rule to make target 'all' in directory gcc No, I'm building in a target directory Garey Mills ebotcazou at gcc dot gnu dot org wrote: --- Comment #5 from ebotcazou at gcc dot gnu dot org 2007-09-21 20:40 --- /usr/local/src/gcc-4.2.1/configure --enable-languages=c,c++,objc,obj-c++ --with-gnu-as --with-gnu-ld I am getting this error. Aren't you again building within the source tree? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33511
[Bug rtl-optimization/30113] [4.1 Regression] ICE in trunc_int_for_mode
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2007-09-21 20:45 --- How come no testcase has been committed with the fix? -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30113
[Bug bootstrap/33511] make fails with no rule to make target 'all' in directory gcc
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2007-09-21 21:19 --- No, I'm building in a target directory OK. Which config shell do you use? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33511
[Bug bootstrap/33511] make fails with no rule to make target 'all' in directory gcc
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-09-21 21:46 --- Also which tar did you untar the tar ball with? GNU tar is required to support long file name lengths. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33511
[Bug bootstrap/33511] make fails with no rule to make target 'all' in directory gcc
--- Comment #9 from gmills at library dot berkeley dot edu 2007-09-21 21:48 --- Subject: Re: make fails with no rule to make target 'all' in directory gcc ksh ebotcazou at gcc dot gnu dot org wrote: --- Comment #7 from ebotcazou at gcc dot gnu dot org 2007-09-21 21:19 --- No, I'm building in a target directory OK. Which config shell do you use? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33511
[Bug bootstrap/33511] make fails with no rule to make target 'all' in directory gcc
--- Comment #10 from gmills at library dot berkeley dot edu 2007-09-21 21:49 --- Subject: Re: make fails with no rule to make target 'all' in directory gcc gnu tar. pinskia at gcc dot gnu dot org wrote: --- Comment #8 from pinskia at gcc dot gnu dot org 2007-09-21 21:46 --- Also which tar did you untar the tar ball with? GNU tar is required to support long file name lengths. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33511
[Bug c++/33521] -m128bit-long-double and printf don't mix
--- Comment #2 from Raf_Schietekat at ieee dot org 2007-09-21 21:36 --- If anything, not to be snapped at. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33521
[Bug fortran/33525] New: crash in if ( i .gt. 0 .and. a(i) .gt. 0 ) when a(0) is out of bounds
the if statement crashes the code: program t integer*4 i real*4 a(10) do i = 1, 10 a(i) = i end do i = 0 if ( i .gt. 0 .and. a(i) .gt. 0 ) then i = i + 1 write(*,*) i end if end $ gfortran -fbounds-check -o t.exe t.f $ t.exe Fortran runtime error: Array reference out of bounds for array 'a', lower bound of dimension 1 exceeded (in file 't.f', at line 8) With all other FORTAN compilers I've worked so far this does not happen as after the first condition is not fulfilled the second is never tested. This problem makes impossible to develope a program in GFROTRAN environment. -- Summary: crash in if ( i .gt. 0 .and. a(i) .gt. 0 ) when a(0) is out of bounds Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dusan dot turk at ijs dot si http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33525
[Bug c++/29615] Class can't be friends of itself?
-- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|pcarlini at suse dot de |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29615
[Bug fortran/33525] crash in if ( i .gt. 0 .and. a(i) .gt. 0 ) when a(0) is out of bounds
--- Comment #1 from kargl at gcc dot gnu dot org 2007-09-21 23:03 --- The Fortran language does not guarantee the order of the evaluation of the logical expression in your IF statement. A fortran processor can try to evaluate a(0) .gt. 0 before the i .gt. 0 expression. Your code is broken and possibly illegal Fortran. Rewrite your code as you meant: i = 0 if ( i .gt. 0) then if (a(i) .gt. 0 ) then i = i + 1 write(*,*) i end if end if -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33525
[Bug middle-end/33280] [4.3 regression] FAIL: gcc.c-torture/execute/990404-1.c execution at -O3
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2007-09-21 23:35 --- Subject: Re: [4.3 regression] FAIL: gcc.c-torture/execute/990404-1.c execution at -O3 Seems to have disappeared between 128564 and 128587. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33280
[Bug c++/31988] new operator should not permit default first parameter
--- Comment #1 from pcarlini at suse dot de 2007-09-22 00:04 --- On it. -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-09-22 00:04:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31988
[Bug middle-end/33436] Bad constant output with TARGET_ASM_ALIGNED_DI_OP
--- Comment #1 from danglin at gcc dot gnu dot org 2007-09-22 01:18 ---
Although it might be possible to fix this at an earlier point,
things go seriously wrong in emit_group_load_1. We have:
Breakpoint 7, emit_group_load_1 (tmps=0x83fffdff4a70,
dst=0x83fffdfb7540, orig_src=0x83fffdfacf30,
type=0x83fffdf9b750, ssize=16) at ../../gcc/gcc/expr.c:1779
1779 else if (CONSTANT_P (src))
(gdb) p debug_rtx (src)
(const_double 4919131751843889152 [0x] 1229782938533634594
[0x] 0 [0x0] 0 [0x0])
$7 = void
(gdb) p debug_rtx (dst)
(parallel:BLK [
(expr_list:REG_DEP_TRUE (reg:DI 66 [ result ])
(const_int 0 [0x0]))
(expr_list:REG_DEP_TRUE (reg:DI 67 [ result+8 ])
(const_int 8 [0x8]))
])
As can be seen, dst is a parallel but src is a CONST_DOUBLE. The code
as currently written assigns src to both parts of the parallel.
I believe this occurs because hppa64 doesn't support TImode.
The break above is in a modified version of expr.c which appears to
correct the problem. Here's the diff:
Index: expr.c
===
--- expr.c (revision 128642)
+++ expr.c (working copy)
@@ -1776,8 +1776,23 @@
else if (CONSTANT_P (src) GET_MODE (dst) != BLKmode
XVECLEN (dst, 0) 1)
tmps[i] = simplify_gen_subreg (mode, src, GET_MODE(dst), bytepos);
- else if (CONSTANT_P (src)
- || (REG_P (src) GET_MODE (src) == mode))
+ else if (CONSTANT_P (src))
+ {
+ if ((HOST_WIDE_INT) bytelen == ssize)
+ tmps[i] = src;
+ else
+ {
+ rtx first, second;
+
+ gcc_assert (i = 1);
+ split_double (src, first, second);
+ if (i)
+ tmps[i] = second;
+ else
+ tmps[i] = first;
+ }
+ }
+ else if (REG_P (src) GET_MODE (src) == mode)
tmps[i] = src;
else
tmps[i] = extract_bit_field (src, bytelen * BITS_PER_UNIT,
I used split_double because neither simplify_subreg or extract_bit_field
handle this.
I'm a little unhappy about splitting the double but in some cases it is
possible to load the values without forcing them to memory. In any event,
this is a rare situation.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33436
[Bug fortran/33526] New: FAIL: gfortran.dg/openmp_stack.f90 -O0 (test for excess errors)
Executing on host: /xxx/gnu/gcc/objdir/gcc/testsuite/gfortran/../../gfortran -B/ xxx/gnu/gcc/objdir/gcc/testsuite/gfortran/../../ /xxx/gnu/gcc/gcc/gcc/testsuite/ gfortran.dg/openmp_stack.f90 -O0 -fopenmp -S -o openmp_stack.s(timeout = 600) gfortran: unrecognized option '-pthread' output is: gfortran: unrecognized option '-pthread' FAIL: gfortran.dg/openmp_stack.f90 -O0 (test for excess errors) Excess errors: gfortran: unrecognized option '-pthread' -- Summary: FAIL: gfortran.dg/openmp_stack.f90 -O0 (test for excess errors) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa1.1-hp-hpux10.20 GCC host triplet: hppa1.1-hp-hpux10.20 GCC target triplet: hppa1.1-hp-hpux10.20 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33526
[Bug fortran/33037] TRANSFER should warn on mismatched sizes
--- Comment #8 from patchapp at dberlin dot org 2007-09-22 01:36 --- Subject: Bug number PR33037 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-09/msg01664.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33037
[Bug fortran/33455] MERGE intrinsic: Check for same string lengths
--- Comment #4 from patchapp at dberlin dot org 2007-09-22 01:36 --- Subject: Bug number PR33455 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-09/msg01663.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33455
[Bug fortran/33445] Diagnose !$OMP as an error in free format unless it is a continuation line
--- Comment #10 from patchapp at dberlin dot org 2007-09-22 01:37 --- Subject: Bug number PR33445 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-09/msg01683.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33445
[Bug c++/33515] Inconsistent warning about defined but not used when there is an error
--- Comment #5 from bangerth at dealii dot org 2007-09-22 03:57 ---
This code:
class Alpha { public: Alpha(); };
static Alpha* a1 = new Alpha;
should definitely not draw a warning because during the initialization
of the variable, the constructor of Alpha is run which could have side
effects. Doing stuff like this is actually a fairly frequently used
idiom whereby we can assure that certain resources are already allocated
before we even get to main().
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
CC||bangerth at dealii dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33515
[Bug c++/33521] -m128bit-long-double and printf don't mix
--- Comment #3 from bangerth at dealii dot org 2007-09-22 04:10 --- It seems rather hard to diagnose this. If you change the ABI by using a floating point representation using a different size of builtin types, you probably have to build all libraries that you link with with the same flags or the kind of wreak that you describe will happen. Now, the bigger question is of course whether the compiler can help you detect the case where you ignore that rule, i.e. compile an object file created with -m128bit-long-double with a libc that was compiled without. The compiler is, in this case, actually the wrong tool to do so -- if anything, the linker could do that, but it would have to have some sort of clue that the object files (or libraries) that you link together were created with incompatible flags -- and worse that you also intend to call functions that will be incompatible with each other if called across object file boundaries. I think that we don't want to go down this avenue. It probably amounts to solving the halting problem if the linker had to make that determination. For example, it may be that you didn't re-compile your libc but never intended to call any libc functions that take floating point arguments. Then there is no danger. Or you intend to call printf which takes all arguments through ... and therefore transparently to the linker. So if you call printf only ever with integer arguments, then your program is ok, but if you call it with fp args then you're in trouble. I guess this is a case where we simply have to trust that you know what you're doing because trying to second guess will just lead to an incredible complex code that will be wrong too often... So I concur with Andrew, though I think he could have explained things a bit nicer :-) W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33521
[Bug c++/33516] [4.0/4.1/4.2/4.3 Regression] Rejects typedef qualified name-lookup
--- Comment #2 from bangerth at dealii dot org 2007-09-22 04:14 --- (In reply to comment #1) What I can find that supports rejecting the code is: 3.4.3(1) Qualified name lookup: If the name found is not a class-name (clause 9) or namespace-name (7.3.1), the program is ill-formed. 7.1.3 The typedef specifier it says: A name declared with the typedef specifier becomes a typedef-name. but then the last example should be rejected as well? I think this isn't the problem you run into. The real problem with the typedef is that if you use typedef_name::nested_name from within the class that typedef_name points to, then typedef_name is still an incomplete type because you haven't reached the closing brace yet. In your last example, you *have* reached the closing brace and the pointed class is complete so using typedef_name::nested_name succeeds. W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33516
[Bug c++/33185] [4.3 Regression] ICE: canonical types differ for identical types T [] and T []
--- Comment #8 from rwgk at yahoo dot com 2007-09-22 04:22 --- Created an attachment (id=14243) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14243action=view) reproducer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33185
[Bug c++/33185] [4.3 Regression] ICE: canonical types differ for identical types T [] and T []
--- Comment #9 from rwgk at yahoo dot com 2007-09-22 04:23 --- Info regarding Comment #8: Fedora Core release 5 (Bordeaux) % uname -r -m 2.6.15-1.2054_FC5 x86_64 % g++ -fpermissive -c -fPIC -I/usr/include/python2.4 ice_canonical.cpp ice_canonical.cpp: In function 'void init_module()': ice_canonical.cpp:8: internal compiler error: canonical types differ for identical types const char [3] and const char [3] Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. The result is the same with: g++ (GCC) 4.3.0 20070919 (experimental) SVN revision 128608 as-is g++ (GCC) 4.3.0 20070922 (experimental) SVN revision 128661M where the M is because I've locally applied the patch from Comment #7. Apparently, the patch isn't the whole solution. Note: the -fpermissive is required to avoid the new changes meaning error. I've already fixed the boost SVN trunk so that the -fpermissive is no longer required. I can reproduce the same ICE based on the boost SVN trunk, without using the -fpermissive. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33185
[Bug c++/33518] unused code changes the result of name lookup
--- Comment #1 from bangerth at dealii dot org 2007-09-22 04:32 --- It is true that both icc and sunCC compile the code both without and with the declaration of the class Wx, whereas we don't in the former case. Will have to investigate some more some other time... W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33518
[Bug tree-optimization/33458] [4.3 regression] ICE PHI def is not a GIMPLE value
--- Comment #3 from rwgk at yahoo dot com 2007-09-22 04:59 --- I'm getting an ICE that looks very similar (below). However, I cannot reproduce the ICE with the test case posted when this issue was opened. Therefore I'm wondering if my ICE is different. What is the platform, and what is the exact g++ command to reproduce the ICE with the original test case? Reducing the sources leading to my ICE is probably serious work... My platform is: Fedora Core release 5 (Bordeaux) % uname -r -m 2.6.15-1.2054_FC5 x86_64 g++ (GCC) 4.3.0 20070919 (experimental) SVN revision 128608 g++ (GCC) 4.3.0 20070922 (experimental) SVN revision 128661 ice_gimple.cpp: In constructor 'scitbx::iso_surface::triangulationCoordinatesType, ValueType::triangulation(scitbx::af::const_refValueType, scitbx::af::c_grid_padded3ul, long unsigned int , ValueType, const scitbx::af::tinyIndexValueType, 3ul, bool) [with CoordinatesType = double, ValueType = double]': ice_gimple.cpp:32: error: invalid operand to binary operator this_2(D)-n_cells.D.101998.elems[0]; ice_gimple.cpp:32: error: PHI def is not a GIMPLE value result_34 = PHI this_2(D)-n_cells.D.101998.elems[0](2), result_36(3) this_2(D)-n_cells.D.101998.elems[0]; ice_gimple.cpp:32: error: invalid operand to binary operator this_2(D)-cell_lengths.D.104936.elems[0]; ice_gimple.cpp:32: error: PHI def is not a GIMPLE value result_48 = PHI this_2(D)-cell_lengths.D.104936.elems[0](5), result_51(6) this_2(D)-cell_lengths.D.104936.elems[0]; ice_gimple.cpp:32: internal compiler error: verify_stmts failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33458
