[Bug debug/43176] var-tracking fails to notice a value change
--- Comment #7 from jakub at gcc dot gnu dot org 2010-03-06 09:36 --- Created an attachment (id=20035) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20035&action=view) gcc45-pr43176.patch Updated patch. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Attachment #20028|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43176
[Bug fortran/43265] [4.3/4.4/4.5 Regression] No EOF condition if reading with '(x)' from an empty file
--- Comment #10 from burnus at gcc dot gnu dot org 2010-03-06 09:49 --- In terms of the standard, probably everything is OK for I/O: "The set of input/output error conditions is processor dependent." (See "9.11.1 General" for a non-definition when EOF occurs.) Looking at other compilers: * If "X" is the only edit descriptor and there is no marker left in the input buffer (i.e. no '\n'), an End Of File error occurs. (gfortran: No error - this PR) * If one reads, e.g. "i2" from a record where either only a record marker follows or only the end-of-file, one reads the value "0" and no error occurs. (gfortran: No error if record marker follows, but error if only eof follows. Note that reading '(a)' from "a" does not give an error while reading from "" gives an error.) * If one reads "(i2,100x,i2,100x)" or "(100x,2i2)" from a record, one gets two "0" and no error, independent whether the record buffer contains "", "" or " ". (gfortran: If there is a record marker, the result is the same; otherwise an EOF error occurs, unless two integer values could be read - then the trailing "100x" does not cause any error.) I think the result of the other compilers is sensible. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43265
[Bug c/39170] provide an option to silence -Wconversion warnings for bit-fields
--- Comment #11 from manu at gcc dot gnu dot org 2010-03-06 12:18 --- (In reply to comment #10) > However, with so many lines of legacy code out there using bit-filed that have > been proven to work, it doesn't make sense to revisit/modify them. Would it > be > possible for gcc to provide a -Wbitfield-conversion flag in new releases and > make 39170 an enhancement (preferably high priority)? Seriously, I am not the "maintainer" of GCC diagnostics or even Wconversion. Anyone can contribute! Yes, it may be possible to provide such an option. I am not against such an option and even if I were I cannot stop you from implementing it and getting it approved by GCC maintainers. I don't know how much work it would be to implement it, and out of kindness I might invest some of my free time to try to do it for GCC 4.6. But even if I might try, that won't happen before summer almost for sure, and then GCC 4.6 won't be available before late next year. -- manu at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-03-06 12:18:44 date|| Summary|cannot silence -Wconversion |provide an option to silence |warnings for bit-fields |-Wconversion warnings for ||bit-fields http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39170
[Bug c++/43273] New: use in template constant from another template
such code cause ICE or template instantiation depth exceeds maximum error,
if uncomment (1) and comment (2) all compiles successfully.
#include
#include
template
struct ConstDependOnType;
template <>
struct ConstDependOnType {
enum { val1 = 4 };
};
template
struct Foo {
//1
//enum { val1 = 4 };
//2
enum { val1 = ConstDependOnType::val1 };
template struct SubFoo;
template
struct SubFoo {
enum { value = SubFoo::value };
};
template
struct SubFoo {
enum { value = a };
};
};
int main()
{
printf("%d\n", static_cast(Foo::SubFoo<5>::value));
}
--
Summary: use in template constant from another template
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dushistov at mail dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43273
[Bug target/43264] Arithmetic expression error
--- Comment #4 from n-takeda at kwansei dot ac dot jp 2010-03-06 13:10 --- (In reply to comment #3) > What is the size of long on h8300-elf? > The size of long is 32bit. LONG_MAX is 2,147,483,647. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43264
[Bug tree-optimization/43269] [4.5 Regression] removing non dead store
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-03-06 14:05 --- Yeah. Mine. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-03-05 19:07:56 |2010-03-06 14:05:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43269
[Bug tree-optimization/43270] array-bounds false negative
--- Comment #13 from rguenth at gcc dot gnu dot org 2010-03-06 14:27
---
Err - it's just because the code is broken:
tree low_bound, up_bound = array_ref_up_bound (ref);
low_sub = up_sub = TREE_OPERAND (ref, 1);
if (!up_bound || TREE_NO_WARNING (ref)
|| TREE_CODE (up_bound) != INTEGER_CST
/* Can not check flexible arrays. */
|| (TYPE_SIZE (TREE_TYPE (ref)) == NULL_TREE
&& TYPE_DOMAIN (TREE_TYPE (ref)) != NULL_TREE
&& TYPE_MAX_VALUE (TYPE_DOMAIN (TREE_TYPE (ref))) == NULL_TREE)
well - this checks TYPE_SIZE/DOMAIN on the element type ...
and the struct hack check is too strict:
/* Accesses after the end of arrays of size 0 (gcc
extension) and 1 are likely intentional ("struct
hack"). */
|| compare_tree_int (up_bound, 1) <= 0)
Replacing that with a more proper (but still too strict) check like
/* Accesses after the end of arrays at the end of structures
are likely intentional ("struct hack"). */
if (TREE_CODE (TREE_OPERAND (ref, 0)) == COMPONENT_REF
&& !TREE_CHAIN (TREE_OPERAND (TREE_OPERAND (ref, 0), 1)))
return;
gets you
t.C: In function 'int main()':
t.C:27:45: warning: array subscript is above array bounds
it doesn't print that this is from an inlined constructor though.
--
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
Severity|normal |enhancement
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2010-03-06 14:27:49
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43270
[Bug tree-optimization/43270] array-bounds false negative
--- Comment #14 from rguenth at gcc dot gnu dot org 2010-03-06 14:28 --- Created an attachment (id=20036) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20036&action=view) untested patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43270
[Bug middle-end/43274] New: [4.5 regression] Revision 157244 failed libgomp.graphite/force-parallel-2.c
On Linux/x86, revision 157244: http://gcc.gnu.org/ml/gcc-cvs/2010-03/msg00116.html caused: FAIL: libgomp.graphite/force-parallel-2.c scan-tree-dump-times graphite "2 loops carried no dependency" 2 -- Summary: [4.5 regression] Revision 157244 failed libgomp.graphite/force-parallel-2.c Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43274
[Bug middle-end/43274] [4.5 regression] Revision 157244 failed libgomp.graphite/force-parallel-2.c
-- hjl dot tools at gmail dot com changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43274
[Bug c++/43275] New: Unclear error message
This error message:
error: type 'type1' is not derived from 'type2'
is rather unclear. The first reaction is to look at the source, see that
indeed, type1 is not derived from type2, and say "... and why does that
matter?!"
Source:
template < typename A > struct B {
typedef int C;
};
template < typename A > struct D {
struct E {
B < A >::C f;
};
};
6: error: type 'B' is not derived from type 'D::E'
6: error: expected ';' before 'f'
The problem here is that there should be a 'typename' before 'B::C', but the
error message contains no hint of that, in addition to missing any hint of why
the compiler would expect a derived type here anyway.
--
Summary: Unclear error message
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kai dot extern at googlemail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43275
[Bug bootstrap/43276] New: [4.5 Regression] lto-elf.c:388:10: error: 'EM_SPARC'
/test/gnu/gcc/objdir/./prev-gcc/xgcc -B/test/gnu/gcc/objdir/./prev-gcc/ -B/opt/g nu64/gcc/gcc-4.5.0/hppa64-hp-hpux11.11/bin/ -B/opt/gnu64/gcc/gcc-4.5.0/hppa64-hp -hpux11.11/bin/ -B/opt/gnu64/gcc/gcc-4.5.0/hppa64-hp-hpux11.11/lib/ -isystem /op t/gnu64/gcc/gcc-4.5.0/hppa64-hp-hpux11.11/include -isystem /opt/gnu64/gcc/gcc-4. 5.0/hppa64-hp-hpux11.11/sys-include-c -g -O2 -DIN_GCC -W -Wall -Wwrite-st rings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attr ibute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wer ror -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -I. -Ilto - I../../gcc/gcc -I../../gcc/gcc/lto -I../../gcc/gcc/../include -I../../gcc/gcc/.. /libcpp/include -I/opt/gnu64/gcc/gcc-4.5.0/include -I../../gcc/gcc/../libdecnum ber -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I/opt/gnu64/include -I/opt/gnu64/include/libelf ../../gcc/gcc/lto/lto-elf.c -o lto/lto-elf.o ../../gcc/gcc/lto/lto-elf.c: In function 'is_compatible_architecture': ../../gcc/gcc/lto/lto-elf.c:388:10: error: 'EM_SPARC' undeclared (first use in t his function) ../../gcc/gcc/lto/lto-elf.c:388:10: note: each undeclared identifier is reported only once for each function it appears in ../../gcc/gcc/lto/lto-elf.c:389:26: error: 'EM_SPARC32PLUS' undeclared (first us e in this function) make[3]: *** [lto/lto-elf.o] Error 1 -- Summary: [4.5 Regression] lto-elf.c:388:10: error: 'EM_SPARC' Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa64-hp-hpux11.11 GCC host triplet: hppa64-hp-hpux11.11 GCC target triplet: hppa64-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43276
[Bug bootstrap/43276] [4.5 Regression] lto-elf.c:388:10: error: 'EM_SPARC'
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2010-03-06 15:58 --- It is defined in /usr/include/libelf/elf_repl.h for libelf 0.8.12 so you'll need to find out what's going on here. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43276
[Bug bootstrap/43276] [4.5 Regression] lto-elf.c:388:10: error: 'EM_SPARC'
--- Comment #2 from danglin at gcc dot gnu dot org 2010-03-06 16:08 --- libelf uses the system's , not libelf/elf_repl.h. The system headers don't provide the SPARC defines. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43276
[Bug bootstrap/43276] [4.5 Regression] lto-elf.c:388:10: error: 'EM_SPARC'
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2010-03-06 16:19 --- > libelf uses the system's , not libelf/elf_repl.h. The system > headers don't provide the SPARC defines. I see, one of those "severely broken" systems libelf/sys_elf.h talks about. We can probably put a kludge in lto-elf.c for HP-UX, the values are universal. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43276
[Bug fortran/41056] ICE with -finline-limit=600 and -fwhole-file: type mismatch between an SSA_NAME and its symbol
--- Comment #7 from dominiq at lps dot ens dot fr 2010-03-06 17:09 ---
With the following patch the test in comment #6 is hopefully valid (it compiles
with '-O2 -fwhole-file', but gives an ICE with '-O3 -fwhole-file'):
--- pr41056.f90 2010-02-24 17:38:27.0 +0100
+++ pr41056_db.f90 2010-02-24 17:55:51.0 +0100
@@ -1,16 +1,19 @@
-! { dg-do compile }
MODULE MAIN1
INTEGER :: INCSET , IXYSET , IEVSET , IHLSET , IFGSET, DBGUNT
+ INTEGER, PARAMETER :: NLVLS = 20
LOGICAL ISTA , IEND , NEWID , UNSTAB , STABLE , DEBUG
LOGICAL :: PVMRM=.FALSE.
CHARACTER SRCTYP*8
ALLOCATABLE :: SRCTYP(:)
+ REAL :: GRIDHT(NLVLS) , GRIDWS(NLVLS), GRIDSV(NLVLS), GRIDSW(NLVLS) ,
GRIDEPS(NLVLS)
END
USE MAIN1
+ allocate(SRCTYP(2))
+ ISRC = 1
IF ( STABLE .OR. (UNSTAB .AND. (HS.GE.ZI)) ) THEN
IF ( PPF.LT.1.0 ) THEN
CALL GINTRP(GRIDHT(NDXEFF),GRIDSV(NDXEFF),GRIDHT(NDXEFF+1), &
- & HTEFF,EPSEFF3)
+ & HTEFF,EPSEFF3,VALUE)
ENDIF
ENDIF
IF ( SRCTYP(ISRC).EQ.'POINT' ) THEN
@@ -53,3 +56,7 @@
IF ( STABLE .OR. (UNSTAB .AND. (HS.GE.ZI)) ) THEN
ENDIF
END
+ SUBROUTINE GINTRP(HTBELO,VBELOW,HTABOV,VABOVE,REQDHT,VALUE)
+ REAL VALUE , HTBELO , VBELOW , HTABOV , VABOVE , REQDHT
+ END
+
[macbook] f90/bug% gfc -O3 -fwhole-file pr41056_db.f90
pr41056_db.f90: In function 'anyavg_.clone.0':
pr41056_db.f90:47:0: error: type mismatch between an SSA_NAME and its symbol
while verifying SSA_NAME hts_1 in statement
hts_1 = (real(kind=4)[0:D.1596] * restrict) &gridht;
pr41056_db.f90:47:0: error: type mismatch between an SSA_NAME and its symbol
pr41056_db.f90:47:0: error: in statement
hts_1 = (real(kind=4)[0:D.1596] * restrict) &gridht;
pr41056_db.f90:47:0: internal compiler error: verify_ssa failed
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41056
[Bug c++/43277] New: thrower function with inlined stack destructor crash on darwin
A very simple exception test case results in an abort trap:
host% cat exctest.cpp
struct StackThing {
~StackThing() { }
};
struct Thrower {
static void Throw() {
StackThing obj;
throw -1;
}
};
int main() {
try {
Thrower::Throw();
} catch (...) { }
}
host% g++-4.4.3 exctest.cpp && ./a.out
Abort trap
host%
The problem is absent if the exception and stack object are not in a thrower
function, or if the stack object has no destructor.
This is using an all-defaults build of the 4.4.3 tarball on MacOS X 10.6.2
(Darwin Kernel Version 10.2.0: Tue Nov 3 10:37:10 PST 2009;
root:xnu-1486.2.11~1/RELEASE_I386 i386)
--
Summary: thrower function with inlined stack destructor crash on
darwin
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: larsfolser at gmail dot com
GCC host triplet: 4.4.3
GCC target triplet: 4.4.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43277
[Bug java/43278] New: shs.h:62: syntax error before `*' token
uname -a
Linux jericho.southkc.net 2.6.17-1.2187_FC5.6axp #1 Tue Feb 27 02:55:25 MSK
2007 alpha alpha alpha GNU/Linux
[r...@jericho libjava]# cat /proc/cpuinfo
cpu : Alpha
cpu model : EV68AL
cpu variation : 7
cpu revision: 0
cpu serial number :
system type : Nautilus
system variation: 0
system revision : 0
system serial number:
cycle frequency [Hz]: 796430335 est.
timer frequency [Hz]: 1024.00
page size [bytes] : 8192
phys. address bits : 44
max. addr. space # : 255
BogoMIPS: 1586.36
kernel unaligned acc: 0 (pc=0,va=0)
user unaligned acc : 0 (pc=0,va=0)
platform string : UP1500 796 MHz
cpus detected : 1
L1 Icache : 64K, 2-way, 64b line
L1 Dcache : 64K, 2-way, 64b line
L2 cache: 8192K, 1-way, 64b line
L3 cache: n/a
make[1]: Entering directory
`/usr/src/redhat/BUILD/gcc-3.2.3-alphaev5/alpha-alph a-linux/libjava'
if [ -z "" ]; then \
true; \
else \
rootpre=`pwd`/; export rootpre; \
srcrootpre=`cd ../../../gcc-3.2.3/libjava; pwd`/; export srcrootpre; \
lib=`echo ${rootpre} | sed -e 's,^.*/\([^/][^/]*\)/$,\1,'`; \
compiler="/usr/src/redhat/BUILD/gcc-3.2.3-alphaev5/gcc/xgcc
-B/usr/src/redhat/ BUILD/gcc-3.2.3-alphaev5/gcc/
-B/prefix/alpha-alpha-linux/bin/ -B/prefix/alpha-a lpha-linux/lib/ -isystem
/prefix/alpha-alpha-linux/include"; \
for i in `${compiler} --print-multi-lib 2>/dev/null`; do \
dir=`echo $i | sed -e 's/;.*$//'`; \
if [ "${dir}" = "." ]; then \
true; \
else \
if [ -d ../${dir}/${lib} ]; then \
flags=`echo $i | sed -e 's/^[^;]*;//' -e 's/@/ -/g'`; \
if (cd ../${dir}/${lib}; make \
CFLAGS="-O -mieee -w -pipe -L/usr/lib/alpha-redhat-linux3E/lib
-I/usr/lib/alpha-redhat-linux3E/include -mieee ${flags}" \
prefix="/prefix" \
exec_prefix="/prefix" \
GCJFLAGS="-g -O ${flags}" \
CXXFLAGS="-g -O -D_GNU_SOURCE -mieee ${flags}" \
LIBCFLAGS=" ${flags}" \
LIBCXXFLAGS=" ${flags}" \
LDFLAGS=" ${flags}" \
DESTDIR="" \
all); then \
true; \
else \
exit 1; \
fi; \
else true; \
fi; \
fi; \
done; \
fi
make[1]: Leaving directory
`/usr/src/redhat/BUILD/gcc-3.2.3-alphaev5/alpha-alpha -linux/libjava'
Making all in libltdl
make[1]: Entering directory
`/usr/src/redhat/BUILD/gcc-3.2.3-alphaev5/alpha-alph a-linux/libjava/libltdl'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory
`/usr/src/redhat/BUILD/gcc-3.2.3-alphaev5/alpha-alpha -linux/libjava/libltdl'
Making all in testsuite
make[1]: Entering directory
`/usr/src/redhat/BUILD/gcc-3.2.3-alphaev5/alpha-alph a-linux/libjava/testsuite'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory
`/usr/src/redhat/BUILD/gcc-3.2.3-alphaev5/alpha-alpha -linux/libjava/testsuite'
Making all in gcj
make[1]: Entering directory
`/usr/src/redhat/BUILD/gcc-3.2.3-alphaev5/alpha-alph a-linux/libjava/gcj'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory
`/usr/src/redhat/BUILD/gcc-3.2.3-alphaev5/alpha-alpha -linux/libjava/gcj'
Making all in include
make[1]: Entering directory
`/usr/src/redhat/BUILD/gcc-3.2.3-alphaev5/alpha-alph a-linux/libjava/include'
make[1]: Leaving directory
`/usr/src/redhat/BUILD/gcc-3.2.3-alphaev5/alpha-alpha -linux/libjava/include'
make[1]: Entering directory
`/usr/src/redhat/BUILD/gcc-3.2.3-alphaev5/alpha-alph a-linux/libjava'
/bin/sh ./libtool --tag=CXX --mode=compile
/usr/src/redhat/BUILD/gcc-3.2.3-alpha ev5/gcc/xgcc -shared-libgcc
-B/usr/src/redhat/BUILD/gcc-3.2.3-alphaev5/gcc/ -nos tdinc++
-L/usr/src/redhat/BUILD/gcc-3.2.3-alphaev5/alpha-alpha-linux/libstdc++- v3/src
-L/usr/src/redhat/BUILD/gcc-3.2.3-alphaev5/alpha-alpha-linux/libstdc++-v3
/src/.libs -B/prefix/alpha-alpha-linux/bin/ -B/prefix/alpha-alpha-linux/lib/
-is ystem /prefix/alpha-alpha-linux/include -DHAVE_CONFIG_H -I.
-I../../../gcc-3.2.3 /libjava -I./include -I./gcj -I../../../gcc-3.2.3/libjava
-Iinclude -I../../../g cc-3.2.3/libjava/include
-I../../../gcc-3.2.3/libjava/../boehm-gc/include -DGC_L INUX_THREADS=1
-D_REENTRANT=1 -DSILENT=1 -DNO_SIGNALS=1 -DNO_EXECUTE_PERMISSION= 1
-DALL_INTERIOR_POINTERS=1 -DJAVA_FINALIZATION=1 -DGC_GCJ_SUPPORT=1 -DATOMIC_UN
COLLECTABLE=1 -I../../../gcc-3.2.3/libjava/libltdl
-I../../../gcc-3.2.3/libjav a/libltdl
-I../../../gcc-3.2.3/libjava/.././libjava/../gcc -I../../../gcc-3.2.3/
libjava/../zlib -I../../../gcc-3.2.3/libjava/../libffi/include
-I../libffi/inclu de -fno-rtti -fnon-call-exceptions -fdollars-in-identifiers
-mieee -W -Wall - D_GNU_SOURCE -DPREFIX="\"/prefix\"" -g -O -D_GNU_SOURCE
-mieee -MD -MT gnu/gcj/i o/natSimpleSHSStream.lo -MF
gnu/gcj/io/natSimpleSHSStream.pp -c -o gnu/gcj/io/na tSimpleSHSStream.lo
../../../gcc-3.2.3/libjava/gnu/gcj/io/natSimpleSHSStream.cc
/usr/src/redhat/BUILD/gcc-3.2.
[Bug c++/43277] thrower function with inlined stack destructor crash on darwin
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2010-03-06 19:09 --- This doesn't occur with gcc trunk on x86_64-apple-darwin10 but does for gcc 4.4.3. Perhaps backporting r151960 to avoid compact unwind code on gcc 4.4 branch for darwin10 would solve this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43277
[Bug fortran/41056] ICE with -finline-limit=600 and -fwhole-file: type mismatch between an SSA_NAME and its symbol
--- Comment #8 from burnus at gcc dot gnu dot org 2010-03-06 19:42 --- Created an attachment (id=20037) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20037&action=view) Another reduced test case; 34 lines, shows no warning with NAG f95 and gfortran And another test case. Just 34 lines - and shows no warning with NAG f95 nor with gfortran -std=f95 -Wall -pedantic. It is now small enough to ICE with "-O3 -flto" or with "-O3 -fwhole-file". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41056
[Bug c++/43277] thrower function with inlined stack destructor crash on darwin
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2010-03-06 20:22 --- r151960 doesn't eliminate the problem in gcc 4.4 branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43277
[Bug debug/41371] [4.5 Regression] var-tracking is slow and memory hungry
--- Comment #18 from aoliva at gcc dot gnu dot org 2010-03-06 20:26 --- Subject: Bug 41371 Author: aoliva Date: Sat Mar 6 20:26:15 2010 New Revision: 157257 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157257 Log: * var-tracking.c (dataflow_set_merge): Swap src and src2. Reverted: 2010-01-13 Jakub Jelinek PR debug/41371 * var-tracking.c (values_to_unmark): New variable. (find_loc_in_1pdv): Clear VALUE_RECURSED_INTO of values in values_to_unmark vector. Moved body to... (find_loc_in_1pdv_1): ... this. Don't clear VALUE_RECURSED_INTO, instead queue it into values_to_unmark vector. (vt_find_locations): Free values_to_unmark vector. Modified: trunk/gcc/ChangeLog trunk/gcc/var-tracking.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
[Bug debug/42897] [4.5 Regression] yet another ice in verify_ssa
--- Comment #5 from aoliva at gcc dot gnu dot org 2010-03-06 20:28 --- Subject: Bug 42897 Author: aoliva Date: Sat Mar 6 20:28:04 2010 New Revision: 157258 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157258 Log: PR debug/42897 * tree-vect-loop.c (vect_transform_loop): Kill out-of-loop debug uses of relevant DEFs that are dead outside the loop too. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vect-loop.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42897
[Bug debug/42897] [4.5 Regression] yet another ice in verify_ssa
--- Comment #6 from aoliva at gcc dot gnu dot org 2010-03-06 20:30 --- Subject: Bug 42897 Author: aoliva Date: Sat Mar 6 20:30:10 2010 New Revision: 157259 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157259 Log: PR debug/42897 * gimple-iterator.c (gsi_remove): Propagate only PHI DEFs removed permanently. Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-iterator.c trunk/gcc/tree-phinodes.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42897
[Bug debug/42897] [4.5 Regression] yet another ice in verify_ssa
--- Comment #7 from aoliva at gcc dot gnu dot org 2010-03-06 21:08 --- Fixed -- aoliva at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42897
[Bug c++/43272] -Wmissing-prototypes doesn't work in C++ mode
--- Comment #2 from erh+gcc at nimenees dot com 2010-03-06 21:34 --- So does this mean bug #13687 is going to be reopened? Or is there some workaround that hasn't been mentioned? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43272
[Bug fortran/41056] ICE with -finline-limit=600 and -fwhole-file: type mismatch between an SSA_NAME and its symbol
--- Comment #9 from burnus at gcc dot gnu dot org 2010-03-06 22:58 --- (In reply to comment #8) > Created an attachment (id=20037) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20037&action=view) -- reduced test case /dev/shm/test/domi14.f90:7:0: error: type mismatch between an SSA_NAME and its symbol while verifying SSA_NAME hts_1 in statement hts_1 = (real(kind=4)[0:D.1549] * restrict) &gridws; (In reply to comment #2) The SSA name has GFC_ARRAY_TYPE_P set on the pointer type while the var decl has not. Some debugging: If one looks at gfc_get_symbol_decl, "hts" and "gridws" have GFC_ARRAY_TYPE_P == 1 (i.e. TYPE (sym->backend_decl / s->backend_decl)). In gfc_conv_procedure_call, TYPE (parmse.expr) (created via gfc_conv_array_parameter) has GFC_ARRAY_TYPE_P == 0; however, manually setting it to 1 does not seem to help. The expression looses (in gfc_conv_array_parameter) the GFC_ARRAY_TYPE_P attribute via the call to gfc_build_addr_expr; while the basetype is 1, the natural type is 0. But as written above: manually setting it to 1 does not seem to help. -- burnus at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|*-apple-darwin9 | GCC host triplet|*-apple-darwin9 | GCC target triplet|*-apple-darwin9 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41056
[Bug c++/43277] thrower function with inlined stack destructor crash on darwin
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2010-03-07 00:00 --- This bug occurs in both gcc 4.4.3 and 4.4.2 on x86_64-apple-darwin10, however it doesn't occur under x86_64-apple-darwin9. This may be a compatibility issue with the FSF gcc unwinder code executed on the libSystem unwinder under darwin10. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43277
[Bug target/43277] thrower function with inlined stack destructor crash on darwin
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-03-07 00:02 --- This is most likely related to PR 43099. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43277
[Bug target/43277] thrower function with inlined stack destructor crash on darwin
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2010-03-07 02:01 --- I wonder if the remaining failure on *86*-apple-darwin9 for PR41991 could also be due to PR43099? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43277
[Bug c++/12909] ambiguity in mangling vector types
--- Comment #21 from jason at gcc dot gnu dot org 2010-03-07 05:36 --- Hmm, that's odd. Why would Darwin satisfy dg-require-alias when it doesn't have ASM_OUTPUT_DEF? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12909
[Bug c++/43272] -Wmissing-prototypes doesn't work in C++ mode
--- Comment #3 from bangerth at gmail dot com 2010-03-07 05:49 --- (In reply to comment #2) > So does this mean bug #13687 is going to be reopened? Or is there some > workaround that hasn't been mentioned? No. I think the issue has been discussed at length there. W. -- bangerth at gmail dot com changed: What|Removed |Added CC||bangerth at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43272
