[Bug middle-end/20991] [4.0 Regression] ICE in cgraph_mark_reachable_node
--- Additional Comments From matz at suse dot de 2005-04-15 06:51 --- Perhaps due to the IPA infrastructure? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20991
[Bug c++/21040] New: Segmentation fault on template/typedef typo
g++ reports: "gpp_bug.cpp:10: internal compiler error: Segmentation fault", on
both Gentoo Linux (gcc 3.3.5) and Solaris (gcc 3.3.2).
Full output of "g++ gpp_bug.cpp":
gpp_bug.cpp: In function `void func()':
gpp_bug.cpp:10: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://bugs.gentoo.org/> for instructions.
Preprocessed source stored into /tmp/ccIkMcGH.out file, please attach this to
your bugreport.
Output of "g++ -v" on the Linux system:
Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5/specs
Configured with: /var/tmp/portage/gcc-3.3.5-r1/work/gcc-3.3.5/configure
--enable-version-specific-runtime-libs --prefix=/usr
--bindir=/usr/i686-pc-linux-gnu/gcc-bin/3.3.5
--includedir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3.5
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3.5/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3.5/info
--with-gxx-include-dir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5/include/g++-v3
--host=i686-pc-linux-gnu --disable-altivec --enable-nls
--without-included-gettext --enable-__cxa_atexit --enable-clocale=gnu
--with-system-zlib --disable-checking --disable-werror
--disable-libunwind-exceptions --enable-shared --enable-threads=posix
--disable-multilib --enable-java-awt=gtk --enable-languages=c,c++,f77,java
Thread model: posix
gcc version 3.3.5 (Gentoo Linux 3.3.5-r1, ssp-3.3.2-3, pie-8.7.7.1)
Offending source code:
//BEGIN SOURCE CODE:
template
struct bar {
typedef T INNER_TYPE_DEF;
};
template
void func(){
typedef typename bar::INNER_TYPE_DEF LOCAL_TYPE_DEF;
LOCAL_TYPE_DEF b;
}
int main(){ }
//END SOURCE CODE
Obviously "LOCAL_TYPE_DEF" is nonsensical, I stumbled on this segfault as a
result of a typo.
--
Summary: Segmentation fault on template/typedef typo
Product: gcc
Version: 3.3.5
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sjanssen at cse dot unl dot edu
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21040
[Bug preprocessor/21039] libcpp incorrectly handles different headers with same name
--- Additional Comments From matz at suse dot de 2005-04-15 06:21 --- Created an attachment (id=8640) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8640&action=view) Tarball with the testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21039
[Bug preprocessor/21039] New: libcpp incorrectly handles different headers with same name
This hits when compiling rrdtools, which creates a perl .xs module. It's and autoconf package, and hence has a config.h. perl also has a config.h used from it's headers (by doing a 'include "config.h"', so the one from the perl include dir is used correctly), which has a multiple include guard. Once the perl config.h is included the source goes on, and tries to include it's own config.h. There is no way anymore due to the bug. It tries to do this with '#include ', i.e. just searching the -I paths (which are setup correctly, so it could find it in ../config.h). But this doesn't work anymore (it did with 3.3.x), as somehow it seems that the place of config.h as it first was found is cached (the perl one), and then the ../config.h one isn't even tried. To demonstrate this I've put a tarball below. After unpacking, please do: % cd a % find -type f ./b/header.h ./b/inc-b.h ./c/inc.c ./header.h % cd c % gcc-4 -E -I .. -I ../b inc.c # 1 "inc.c" # 1 "" # 1 "" # 1 "inc.c" # 1 "../b/inc-b.h" 1 # 1 "../b/header.h" 1 B # 1 "../b/inc-b.h" 2 # 2 "inc.c" 2 Note how the two include directives in inc.c have no effect, _although_ -I .. is before -I ../b in the cmdline. gcc 3 does it correctly: % gcc-3 -E -I .. -I ../b inc.c | grep header.h # 1 "inc.c" # 1 "" # 1 "" # 1 "inc.c" # 1 "../b/inc-b.h" 1 # 1 "../b/header.h" 1 B # 2 "../b/inc-b.h" 2 # 2 "inc.c" 2 # 1 "../header.h" 1 A # 3 "inc.c" 2 # 1 "../header.h" 1 A # 4 "inc.c" 2 -- Summary: libcpp incorrectly handles different headers with same name Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: matz at suse dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21039
[Bug fortran/21034] internal compiler error: in gfc_trans_auto_array_allocation, at fortran/trans-array.c:3036
--- Additional Comments From nicolas dot girard at nerim dot net 2005-04-15 06:10 --- Created an attachment (id=8639) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8639&action=view) Source files -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21034
[Bug fortran/21034] internal compiler error: in gfc_trans_auto_array_allocation, at fortran/trans-array.c:3036
--- Additional Comments From nicolas dot girard at nerim dot net 2005-04-15 06:09 --- Sure. Actually the main file is a .F file. The tgz I'm about to attach contain the following files: - main.F : main file - guess.h params.h pinch_complet.h prec.h: included by the preprocessor - routines.h.ok : when renamed to routines.h, the program compiles fine - routines.h.bug: when renamed to routines.h, causes the bug to appear "$ diff routines.*" gives: 408c408 < subroutine solution(n,xf,fg,h1,h2,beta,pas,tolerance,nmax,xav) --- > subroutine solution(xf,fg,h1,h2,beta,pas,tolerance,nmax,xav) 438c438 < parameter (n1=5,n2=5,ndims=10) --- > parameter (n1=5,n2=5,n=1024,ndims=10) All I did was to add "n" as a new parameter of the solution() subroutine ; here the call to solution() is unchanged but adding a variable corresponding to n in the function call changes nothing, the bug still appears. Thanks again, cheers -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21034
[Bug c++/21038] Poor diagnostic
--- Additional Comments From igodard at pacbell dot net 2005-04-15 06:04 --- Yes, it's a design flaw of C that parens and bracked are so overloaded that the compiler (or the human) can't tell if the problem is too many openers or not enough closers. Still, every little bit helps :-) Ivan -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21038
[Bug tree-optimization/21029] [4.1 Regression] vrp miscompiles Ada front-end, drops loop exit test in well-defined wrap-around circumstances
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-15
05:56 ---
Subject: [PR tree-optimization/21029, RFC] harmful chrec type conversions
I started out by handling the specific case that the Ada front-end
triggers, reduced to function f() in the attached testcase. Later on,
as I understood the failure more, I figured I'd exercise some other
cases, and painted myself into a corner in which each combination of
widening-or-narrowing signedness-changing-or-not conversion that
chrec_convert() might be asked to handle would be harmed by simply
converting CHREC_LEFT and CHREC_RIGHT to the requested type, and the
strategy we already used for widening conversions gave us correct
results.
Are there good reasons to try to perform the conversions in place and
try to work around the loss of information elsewhere, or is this
approach reasonable?
This is not a final patch; if the idea is considered sound, I'd simply
remove the if and the then-dead remaining code in chrec_convert.
Meanwhile, I'm bootstrapping this on amd64-linux-gnu.
Comments?
Index: gcc/ChangeLog
from Alexandre Oliva <[EMAIL PROTECTED]>
PR tree-optimization/21029
* tree-chrec.c (chrec_convert): Handle same-precision integral
types that differ in signedness like widening conversions.
Index: gcc/tree-chrec.c
===
RCS file: /cvs/gcc/gcc/gcc/tree-chrec.c,v
retrieving revision 2.14
diff -u -p -r2.14 tree-chrec.c
--- gcc/tree-chrec.c 5 Apr 2005 07:06:23 - 2.14
+++ gcc/tree-chrec.c 15 Apr 2005 05:40:27 -
@@ -1033,7 +1033,16 @@ chrec_convert (tree type,
if (ct == type)
return chrec;
- if (TYPE_PRECISION (ct) < TYPE_PRECISION (type))
+ if (1 /* Even truncations need to carry information about
+ well-defined overflows in narrowing conversions that might
+ have invoked undefined behavior should the operations be
+ performed directly in the narrow type. */
+ || TYPE_PRECISION (ct) < TYPE_PRECISION (type)
+ /* Sign changes may involve well-defined overflows; avoid
+silently dropping the signedness change.
+??? Should we limit ourselves to same-precision types here? */
+ || (INTEGRAL_TYPE_P (ct) && INTEGRAL_TYPE_P (type)
+ && TYPE_UNSIGNED (ct) != TYPE_UNSIGNED (type)))
return count_ev_in_wider_type (type, chrec);
switch (TREE_CODE (chrec))
Index: gcc/testsuite/ChangeLog
from Alexandre Oliva <[EMAIL PROTECTED]>
PR tree-optimization/21029
* gcc.dg/tree-ssa/pr21029.c: New.
Index: gcc/testsuite/gcc.dg/tree-ssa/pr21029.c
===
RCS file: gcc/testsuite/gcc.dg/tree-ssa/pr21029.c
diff -N gcc/testsuite/gcc.dg/tree-ssa/pr21029.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ gcc/testsuite/gcc.dg/tree-ssa/pr21029.c 15 Apr 2005 05:40:41 -
@@ -0,0 +1,176 @@
+/* { dg-do run } */
+/* { dg-options "-O2" } */
+
+/* PR tree-optimization/21029
+
+ f() used to get optimized to an infinite loop by tree-vrp, because
+ j is assumed to be non-negative. Even though the conversion from
+ unsigned to signed has unspecified results if the expression value
+ is not representable in the signed type, the compiler itself (e.g.,
+ the Ada front end) depends on wrap-around behavior. */
+
+unsigned int g(void) {
+ return (unsigned int)g;
+}
+
+unsigned int f(void) {
+ unsigned int k = g ();
+
+ unsigned char i = 123;
+ signed char j;
+
+ do
+if ((j = (signed char) i) < 0)
+ break;
+else
+ i++;
+ while (1);
+
+ /* This is here just so that the compiler introduces ASSERT_EXPR so
+ as to run the vrp pass. Yuck. */
+ if (i <= k)
+k = i - 2;
+ else
+k = k + 3;
+
+ return k;
+}
+
+/* Now let's torture it a bit further. Narrowing conversions need
+ similar treatment. */
+
+unsigned int f1 (void) {
+ unsigned int k = g ();
+
+ unsigned short i = 123;
+ signed char j;
+
+ do
+if ((j = (signed char) i) < 0)
+ break;
+else
+ i++;
+ while (1);
+
+ /* This is here just so that the compiler introduces ASSERT_EXPR so
+ as to run the vrp pass. Yuck. */
+ if (i <= k)
+k = i - 2;
+ else
+k = k + 3;
+
+ return k;
+}
+
+/* And so do widening conversions. */
+
+unsigned int f2 (void) {
+ unsigned int k = g ();
+
+ unsigned char i = 123;
+ signed short j;
+
+ do
+if ((j = (signed short) (signed char) i) < 0)
+ break;
+else
+ i++;
+ while (1);
+
+ /* This is here just so that the compiler introduces ASSERT_EXPR so
+ as to run the vrp pass. Yuck. */
+ if (i <= k)
+k = i - 2;
+ else
+k = k + 3;
+
+ return k;
+}
+
+/* Check same-sign truncations with an increment that turns into
+ decrements. */
+
+unsigned int f3 (void) {
+ unsigned int k = g ();
+
+ signed short i = 5;
+ signed char j;
+
+ do
+if ((j = (signed char) i) < 0)
+ break;
+else
+ i += 255;
+ while (
[Bug tree-optimization/21004] [4.1 Regression] gcc.dg/builtins-53.c fails
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-15 05:44 --- Subject: Bug 21004 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-15 05:43:57 Modified files: gcc: ChangeLog convert.c builtins.c gcc/testsuite : ChangeLog gcc/testsuite/gcc.dg: builtins-53.c Log message: PR tree-optimization/21004 * convert.c (convert_to_integer): Convert ceilf, ceill, floorf and floorl in c99 mode only. * builtins.c (expand_builtin_int_roundingfn): Assert that fallback_fndecl is not NULL_TREE. testsuite: PR tree-optimization/21004 * gcc.dg/builtins-53.c: Include builtins-config.h. Check floorf, ceilf, floorl and ceill transformations only when HAVE_C99_RUNTIME is defined. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8301&r2=2.8302 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/convert.c.diff?cvsroot=gcc&r1=1.60&r2=1.61 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/builtins.c.diff?cvsroot=gcc&r1=1.453&r2=1.454 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5353&r2=1.5354 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/builtins-53.c.diff?cvsroot=gcc&r1=1.3&r2=1.4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21004
[Bug java/21022] bootstrap error compiling libgcj with awt support on darwin-ppc
-- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Keywords||build, ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21022
[Bug c++/21038] Poor diagnostic
--- Additional Comments From bangerth at dealii dot org 2005-04-15 05:36 --- It may also very well be the case that the shown opening brace isn't the one that is unmatched, but that you forgot to close a block somewhere in the middle. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21038
[Bug middle-end/20991] [4.0 Regression] ICE in cgraph_mark_reachable_node
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-15 05:36 --- Hmm, all of the testcases listed here work on the mainline. -- What|Removed |Added Known to work||4.1.0 Summary|[4.0/4.1 Regression] ICE in |[4.0 Regression] ICE in |cgraph_mark_reachable_node |cgraph_mark_reachable_node http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20991
[Bug c++/21012] [4.0/4.1 regression] incorrect name lookup from nested struct
--- Additional Comments From bangerth at dealii dot org 2005-04-15 05:31 --- The unqualified name Foo is looked up within the class hierarchy, and finds the name of the base class. W. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21012
[Bug c++/21008] [3.4/4.0/4.1 Regression] Acess failure in accessing data member of base class from derived template class
--- Additional Comments From bangerth at dealii dot org 2005-04-15 05:29 --- A::foo_ is not template-dependent, so it is looked up and bound at the time of template definition, not at instantiation time. Because template-dependent base classes are not visible at the time, the access is assumed to be from the outside, not within the class hierarchy through this->, and the error, though surprising, is correct. W. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21008
[Bug bootstrap/21037] [4.0 RC1] Bootstrap failure (ld: TOC overflow)
--- Additional Comments From ltg at zes dot uni-bremen dot de 2005-04-15 05:25 --- Subject: RE: [4.0 RC1] Bootstrap failure (ld: TOC overflow) On 15-Apr-2005 pinskia at physics dot uc dot edu wrote: > > It is already done for BOOT_LDFLAGS. OK. I configured now with: BOOT_LDFLAGS="-Wl,-bbigtoc" CC="/usr/local/bin/gcc -maix64" CFLAGS="-O9 -maix64 -maltivec -mabi=altivec" CXXFLAGS="-g -O9 -maix64 -maltivec -mabi=altivec" CFLAGS_FOR_TARGET="-O9 -maix64 -maltivec -mabi=altivec" LIBCFLAGS="-g -O9 -maix64 -maltivec -mabi=altivec" LIBCXXFLAGS="-g -O9 -maix64 -maltivec -mabi=altivec" /devel/build/gcc-4.0.0-20050410/configure --enable-threads=aix --enable-version-specific-runtime-libs --disable-nls --enable-libgcj-debug --enable-libgcj-multifile --with-x --enable-gtk-cairo --enable-gather-detailed-mem-stats --enable-languages=c,c++,f95,java,objc and built with: BOOT_CFLAGS="-O9 -maix64" BOOT_LDFLAGS="-Wl,-bbigtoc" CFLAGS="-O9 -maix64" CXXFLAGS="-O9 -maix64" LIBCFLAGS="-g -O9 -maix64" LIBCXXFLAGS="-g -O9 -maix64 -fno-implicit-templates" nohup /usr/local/bin/make bootstrap& and it seems that BOOT_LDFLAGS is completely ignored by the build process, resulting in the same TOC overflow. Lothar -- E-Mail: [EMAIL PROTECTED] Date: 15-Apr-2005 Time: 05:44:28 This message was sent by XFMail -- -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21037
[Bug libfortran/18495] Intrinisc function SPREAD is broken
--- Additional Comments From paulthomas2 at wanadoo dot fr 2005-04-15 05:07 --- Subject: Re: Intrinisc function SPREAD is broken > > >This appears to fix the benchmark in question. > > > I believe that reshape needs the same/similar fix. Is ret->data = NULL guaranteed for temporaries? This is what I would have done but the question that I asked on the original PR is still unanswered - is it the caller or the callee who should be arranging the correct amount of memory for a temporary object? Paul T -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18495
[Bug c++/21038] Poor diagnostic
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-15
04:05 ---
I don't know if it would useful or not. Take the following:
void g(); void h();
void f()
{
//. say about 100 lines
if (a) {
//. say about 100 lines
//. say about 100 lines
}
well you would get the wrong thing marked and it would not help you in general.
--
What|Removed |Added
Severity|normal |enhancement
Keywords||diagnostic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21038
[Bug tree-optimization/20936] [4.1 Regression] tree check: accessed operand 2 of view_convert_expr with 1 operands
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-15 04:05 --- Testing the obvious fix. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |kazu at cs dot umass dot edu |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20936
Re: Interesting bug with imLib2/glut, or compiler error?
On Apr 14, 2005, at 10:32 PM, Jay Summet wrote: -BEGIN PGP SIGNED MESSAGE- I ran into an interesting bug when attempting to add imlib2 to a program that uses GLUT. The program would compile/link fine, but segfault when the imlib_load_image() call was made. (initial call to imlib) The fix? change: int time; to: //int time; time is a standard C function so if you declare a variable, well you just overwrote it, this is not a GCC bug or even a imLib2/glut bug but a bug in your program. -- Pinski
[Bug target/20126] [3.3/3.4/4.0 Regression] Inlined memcmp makes one argument null on entry
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-15 03:31 --- Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail On Apr 12, 2005, Roger Sayle <[EMAIL PROTECTED]> wrote: > I still like your fallbacks, that by trying harder we perform better > optimization, The more I think about this, the more I have the impression that perhaps the fallbacks are not necessary. My gut feeling (that has been wrong before, so take that with a grain of salt) is that, if we mark the giv as ignored, its assignment within the loop won't be removed (if they ever are, I'm not entirely sure), so if we introduce a new assignment, we're wasting cpu cycles either in the compiler, if it has to remove the redundant set, or at run-time, if it can't figure that out. My feeling stems from the fact that we've never had (AFAIK) a situation in which the failure to make the change caused a miscompilation, except in the case of a biv whose final assignment was hoisted before the loop. I can't quite figure out why this would ever make sense; it appears to me that computing its final value after the loop is always profitable is always better because it would reduce register pressure, but I may be way off here. In the two other cases that were exposed by attempts to report failures in the substitution (namely, the Ada bootstrap error that Jakub reported against an earlier version of the patch, and the arm-elf build failure that Josh reported), the value was there, and, since the code actually refrained from checking the result of validate_change, perhaps it really didn't matter whether the substitution worked. At least until we started swimming bivs to before the loop... So I'm wondering if taking out all of the workarounds and going back to something like what is now in the 4.0 branch, except for the use of validate_change_maybe_volatile, wouldn't get us exactly what we want. Unfortunately, cases in which the substitution fails are quite rare, and the loop code isn't exactly trivial, so it's hard to decide whether we've just been lucky, or the code was already mostly correct. Anyhow, in the meantime, could I check in the patch to fix Josh's asm-elf build failure? I haven't been able to bootstrap the tree lately because of PR21029, but I know it would bootstrap successfully on amd64-linux-gnu (it would never hit the point that I changed :-), and I know it fixes the arm-elf problem. It would be nice to keep the hard failure in place for a bit longer, such that we stood a better chance of finding other situations that might require work arounds. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20126
[Bug middle-end/20991] [4.0/4.1 Regression] ICE in cgraph_mark_reachable_node
--- Additional Comments From matz at suse dot de 2005-04-15 03:16 ---
One strange thing is, that the call to getWidth() in B is already in .generic:
if (retval.1)
{
getWidth (&i_bnds);
}
while the call to getWidth() in isEmpty() (which is inlined later into B()) is
D.1595 = this->_vptr.IMG_Rect;
D.1596 = *D.1595;
D.1597 = OBJ_TYPE_REF(D.1596;this->0) (this);
D.1594 = D.1597 == 0;
Both are actually virtual calls of course, so I wonder why they are represented
differently. Note that this doesn't change if I make B() a method of IMG_Rect.
I thought initially that might be a difference, as isEmpty is one.
Another fact is, that if I comment out the totally unrelated useless decl for
getVisibility(), it works. The .i01.cgraph dump in that case shows these
Initial entry points: void B() void A()
Unit entry points: void B() void A() virtual bool IMG_Rect::isEmpty() const
virtual int IMG_Rect::getWidth() const
while when it breaks (i.e. when getVisibility is there) it looks like:
Initial entry points: void B() void A()
Unit entry points: void B() void A()
See how the two methods in question are now missing. As they are declared
inline this
actually should be okay, and that getVisibility makes a difference might be
another bug,
which hides this one sometimes.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20991
[Bug middle-end/20739] [4.0/4.1 regression] ICE in gimplify_addr_expr
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-15 03:09 --- Subject: Bug 20739 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-15 03:09:51 Modified files: gcc: ChangeLog gimplify.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg/tree-ssa: pr20739.c Log message: gcc/ChangeLog: PR middle-end/20739 * gimplify.c (gimplify_addr_expr): Compensate for removal of e.g. cv-qualification conversions. gcc/testsuite/ChangeLog: PR middle-end/20739 * gcc.dg/tree-ssa/pr20739.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8299&r2=2.8300 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/gimplify.c.diff?cvsroot=gcc&r1=2.122&r2=2.123 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5352&r2=1.5353 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr20739.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20739
[Bug middle-end/20991] [4.0/4.1 Regression] ICE in cgraph_mark_reachable_node
--- Additional Comments From matz at suse dot de 2005-04-15 02:40 ---
We see this error in blender. I was able to reduce it quite a bit to this:
struct IMG_Rect {
virtual inline int getWidth() const;
virtual inline bool isEmpty() const;
virtual int getVisibility(int) const;
};
inline int IMG_Rect::getWidth() const
{
return 1;
}
inline bool IMG_Rect::isEmpty() const
{
return (getWidth() == 0);
}
void A()
{
IMG_Rect i_bnds;
if (i_bnds.isEmpty())
i_bnds.getWidth();
}
void B()
{
IMG_Rect i_bnds;
if (i_bnds.isEmpty())
i_bnds.getWidth();
}
--
What|Removed |Added
CC||matz at suse dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20991
[Bug tree-optimization/21029] [4.1 Regression] vrp miscompiles Ada front-end, drops loop exit test in well-defined wrap-around circumstances
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-15 02:40 --- > Hmm? VRP is automatically enabled at -O2 and higher. But it doesn't run unless we find some ASSERT_EXPR, and if all we have is a simple loop, no such ASSERT_EXPR is introduced. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21029
Interesting bug with imLib2/glut, or compiler error?
-BEGIN PGP SIGNED MESSAGE- I ran into an interesting bug when attempting to add imlib2 to a program that uses GLUT. The program would compile/link fine, but segfault when the imlib_load_image() call was made. (initial call to imlib) The fix? change: int time; to: //int time; the time integer variable was a global variable that was left over from a FPS counter I had in the program at one pointit was not used at this time. The program has no dynamic allocation, so it shouldn't be a pointer error, and because I got no compile/link errors it shouldn't have been getting confused with some other global variable... So, it could be a tool error (gcc) or a really funky interaction between imlib2 and glut/OpenGL. In any case, if you care to try to replicate it, I've included all the files. Attached, or at the following URL: www.cc.gatech.edu/~summetj/drafts/funky_error.tar.gz ./doit compiles and runs the good one, and ./doit_bad compiles the bad one, and then segfaults. (at least, on my Mandrake 10.1 box...) The VERSIONS directory lists a lot of information about what GL/MESA/imLib2 versions I'm using (whatever came with Mandrake...) Jay -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQCVAwUBQl8n17WkkhmZq4xxAQFOzwP+KD2U89xSiNdO2Bbo8XOLPBGbxJ5tqNoq tQRSysxOB2j8ChmYkXhnioIlQ0sdcNn6jeAfBRq+I0507rk2s5xZ7/xXCZrZx0Xt lgbJyeTPi1gp10FS70DFsaL5UbqjtqVoyn+O+pKIqbYZA9ZXaumubRA2Q0lXgnrx ZsFeWyfPPgI= =lIu2 -END PGP SIGNATURE- funky_error.tar.gz Description: application/gzip
[Bug middle-end/20739] [4.0/4.1 regression] ICE in gimplify_addr_expr
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-15 02:32 --- Subject: Re: [PR middle-end/20739] lvalue cond-expr gimplification may crash on cv-qual diffs On Apr 14, 2005, Alexandre Oliva <[EMAIL PROTECTED]> wrote: > Bootstrap and regtest pased on amd64-linux-gnu, at least for mainline. > I'm retesting on the branch, since I'm not entirely sure I actually > tested it there. Bootstrap and test completed on amd64-linux-gnu. > Index: gcc/ChangeLog > from Alexandre Oliva <[EMAIL PROTECTED]> > PR middle-end/20739 > * gimplify.c (gimplify_addr_expr): Compensate for removal of > e.g. cv-qualification conversions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20739
[Bug tree-optimization/21021] [4.1 Regression] ICE in tree-vrp building glibc
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-15 01:31 --- Just checked in a workaround patch. For a real fix, keep an eye on PR 21024. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21021
[Bug tree-optimization/21021] [4.1 Regression] ICE in tree-vrp building glibc
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-15 01:29 --- Subject: Bug 21021 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-15 01:29:44 Modified files: gcc: ChangeLog tree-vrp.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.c-torture/compile: pr21021.c Log message: gcc/ PR tree-optimization/21021 * tree-vrp.c (compare_values): Work around a bug in the front end that produces a comparison of mismatched types. testsuite/ PR tree-optimization/21021 * gcc.c-torture/compile/pr21021.c: New. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8297&r2=2.8298 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-vrp.c.diff?cvsroot=gcc&r1=2.7&r2=2.8 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5350&r2=1.5351 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/compile/pr21021.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21021
[Bug bootstrap/21037] [4.0 RC1] Bootstrap failure (ld: TOC overflow)
--- Additional Comments From ltg at zes dot uni-bremen dot de 2005-04-15 01:08 --- Subject: RE: [4.0 RC1] Bootstrap failure (ld: TOC overflow) On 15-Apr-2005 pinskia at gcc dot gnu dot org wrote: > > --- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-15 > 00:51 --- > Also what gcc are you starting with? [EMAIL PROTECTED]:/devel/build> gcc -v Reading specs from /usr/local/lib/gcc/powerpc-ibm-aix5.2.0.0/3.4.3/specs Configured with: ../gcc-3.4.3/configure --enable-threads=aix --enable-version-specific-runtime-libs --disable-nls --enable-libgcj-debug --enable-libgcj-multifile --with-x --enable-gtk-cairo --enable-gather-detailed-mem-stats Thread model: aix gcc version 3.4.3 Lothar -- E-Mail: [EMAIL PROTECTED] Date: 15-Apr-2005 Time: 03:03:45 This message was sent by XFMail -- -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21037
[Bug c++/21038] New: Poor diagnostic
In:
void foo() {
int i;
int j;
int k;
you get:
~/ootbc/members/src$ g++ foo.cc
foo.cc: In function `void foo()':
foo.cc:5: error: expected `}' at end of input
The disgnostic should show the line number of the unmatched opener "{". Finding
mismatched brackets can be a real pain in lengthy or nested code such as .h
files for collection template classes.
Ivan
--
Summary: Poor diagnostic
Product: gcc
Version: 3.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21038
[Bug bootstrap/21037] [4.0 RC1] Bootstrap failure (ld: TOC overflow)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-15 00:51 --- Also what gcc are you starting with? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21037
[Bug bootstrap/21037] [4.0 RC1] Bootstrap failure (ld: TOC overflow)
--- Additional Comments From pinskia at physics dot uc dot edu 2005-04-15 00:49 --- Subject: Re: New: [4.0 RC1] Bootstrap failure (ld: TOC overflow) On Apr 14, 2005, at 8:45 PM, ltg at zes dot uni-bremen dot de wrote: > I tried to build gcc-4.0.0-20050410 (RC1) and got the following error: > > BOOT_CFLAGS="-O9 -maix64" CFLAGS="-O9 -maix64" CXXFLAGS="-O9 -maix64" > LIBCFLAGS="-g -O9 -maix64" LIBCXXFLAGS="-g -O9 -maix64 > -fno-implicit-templates" > nohup /usr/local/bin/make bootstrap& > > It looks like at least the 64bit build on powerpc-ibm-aix5.2.0.0 needs > a "-Wl,-bbigtoc" as a default flag. It is already done for BOOT_LDFLAGS. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21037
Re: [Bug bootstrap/21037] New: [4.0 RC1] Bootstrap failure (ld: TOC overflow)
On Apr 14, 2005, at 8:45 PM, ltg at zes dot uni-bremen dot de wrote: I tried to build gcc-4.0.0-20050410 (RC1) and got the following error: BOOT_CFLAGS="-O9 -maix64" CFLAGS="-O9 -maix64" CXXFLAGS="-O9 -maix64" LIBCFLAGS="-g -O9 -maix64" LIBCXXFLAGS="-g -O9 -maix64 -fno-implicit-templates" nohup /usr/local/bin/make bootstrap& It looks like at least the 64bit build on powerpc-ibm-aix5.2.0.0 needs a "-Wl,-bbigtoc" as a default flag. It is already done for BOOT_LDFLAGS. -- Pinski
[Bug bootstrap/21037] New: [4.0 RC1] Bootstrap failure (ld: TOC overflow)
I tried to build gcc-4.0.0-20050410 (RC1) and got the following error: /usr/local/bin/gcc -maix64 -g -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition-DHAVE_CONFIG_H -o cc1 \ c-parse.o c-lang.o stub-objc.o attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o c-semantics.o c-incpath.o cppdefault.o c-ppoutput.o c-cppbuiltin.o prefix.o c-objc-common.o c-dump.o c-pch.o rs6000-c.o c-gimplify.o tree-mudflap.o c-pretty-print.o main.o libbackend.a ../libcpp/libcpp.a ../libcpp/libcpp.a -liconv ../libiberty/libiberty.a ld: 0711-781 ERROR: TOC overflow. TOC size: 102280 Maximum size: 65536 collect2: ld returned 12 exit status make[2]: *** [cc1] Error 1 make[2]: Leaving directory `/devel/build/objdir.400pre/gcc' make[1]: *** [stage1_build] Error 2 make[1]: Leaving directory `/devel/build/objdir.400pre/gcc' make: *** [bootstrap] Error 2 This is my configure commandline: CC="/usr/local/bin/gcc -maix64" CFLAGS="-O9 -maix64 -maltivec -mabi=altivec" CXXFLAGS="-g -O9 -maix64 -maltivec -mabi=altivec" CFLAGS_FOR_TARGET="-O9 -maix64 -maltivec -mabi=altivec" LIBCFLAGS="-g -O9 -maix64 -maltivec -mabi=altivec" LIBCXXFLAGS="-g -O9 -maix64 -maltivec -mabi=altivec" /devel/build/gcc-4.0.0-20050410/configure --enable-threads=aix --enable-version-specific-runtime-libs --disable-nls --enable-libgcj-debug --enable-libgcj-multifile --with-x --enable-gtk-cairo --enable-gather-detailed-mem-stats --enable-languages=c,c++,f95,java,objc And my make commandline: BOOT_CFLAGS="-O9 -maix64" CFLAGS="-O9 -maix64" CXXFLAGS="-O9 -maix64" LIBCFLAGS="-g -O9 -maix64" LIBCXXFLAGS="-g -O9 -maix64 -fno-implicit-templates" nohup /usr/local/bin/make bootstrap& It looks like at least the 64bit build on powerpc-ibm-aix5.2.0.0 needs a "-Wl,-bbigtoc" as a default flag. Lothar -- Summary: [4.0 RC1] Bootstrap failure (ld: TOC overflow) Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ltg at zes dot uni-bremen dot de CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: powerpc-ibm-aix5.2.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21037
[Bug java/21036] New: gcj ICE compiling Azureus 2.2.0.2 to native code
Description of problem: gcj ICEs compiling Azureus 2.2.0.2 to native code. Version-Release number of selected component (if applicable): gcc-java-4.0.0-0.42 from RedHat Fedora Core Development How reproducible: Always Steps to Reproduce: 1. Download and unpack Azureus 2.2.0.2 from http://azureus.sourceforge.net/download.php 2. Run gcj -fPIC -fjni -findirect-dispatch -shared -Wl,-Bsymbolic --classpath=swt.jar:swt-pi.jar:swt-mozilla.jar Azureus2.2.0.2.jar -o Azureus2.2.0.2.jar.so Actual results: org/gudy/azureus2/core3/tracker/client/classic/TrackerStatus.java: In class 'org.gudy.azureus2.core3.tracker.client.classic.TrackerStatus': org/gudy/azureus2/core3/tracker/client/classic/TrackerStatus.java: In method 'org.gudy.azureus2.core3.tracker.client.classic.TrackerStatus.scrapeUDP(java.net.URL,java.io.ByteArrayOutputStream,byte[])': org/gudy/azureus2/core3/tracker/client/classic/TrackerStatus.java:813: internal compiler error: in update_aliases, at java/decl.c:166 Please submit a full bug report, with preprocessed source if appropriate. See http://bugzilla.redhat.com/bugzilla> for instructions. Expected results: Success. Additional info: Happens with several other sets of command line options (including no options except --classpath and -o). -- Summary: gcj ICE compiling Azureus 2.2.0.2 to native code Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: luca dot barbieri at gmail dot com CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org GCC build triplet: i386-redhat-linux GCC host triplet: i386-redhat-linux GCC target triplet: i386-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21036
[Bug middle-end/14311] builtins for atomic operations needed
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-14 23:37 --- Subject: Bug 14311 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-14 23:37:47 Modified files: gcc: ChangeLog builtin-types.def builtins.c builtins.def c-common.c c-common.h c-typeck.c expr.c expr.h genopinit.c optabs.c optabs.h gcc/doc: extend.texi md.texi Added files: gcc/testsuite/gcc.c-torture/compile: sync-1.c gcc/testsuite/gcc.dg: sync-1.c Log message: PR middle-end/14311 * builtin-types.def (BT_BOOL, BT_VOLATILE_PTR, BT_I1, BT_I2, BT_I4, BT_I8, BT_FN_VOID_VPTR, BT_FN_I1_VPTR_I1, BT_FN_I2_VPTR_I2, BT_FN_I4_VPTR_I4, BT_FN_I8_VPTR_I8, BT_FN_BOOL_VPTR_I1_I1, BT_FN_BOOL_VPTR_I2_I2, BT_FN_BOOL_VPTR_I4_I4, BT_FN_BOOL_VPTR_I8_I8, BT_FN_I1_VPTR_I1_I1, BT_FN_I2_VPTR_I2_I2, BT_FN_I4_VPTR_I4_I4, BT_FN_I8_VPTR_I8_I8): New. * builtins.def (DEF_SYNC_BUILTIN): New. (BUILT_IN_FETCH_AND_ADD_N, BUILT_IN_FETCH_AND_ADD_1, BUILT_IN_FETCH_AND_ADD_2, BUILT_IN_FETCH_AND_ADD_4, BUILT_IN_FETCH_AND_ADD_8, BUILT_IN_FETCH_AND_SUB_N, BUILT_IN_FETCH_AND_SUB_1, BUILT_IN_FETCH_AND_SUB_2, BUILT_IN_FETCH_AND_SUB_4, BUILT_IN_FETCH_AND_SUB_8, BUILT_IN_FETCH_AND_OR_N, BUILT_IN_FETCH_AND_OR_1, BUILT_IN_FETCH_AND_OR_2, BUILT_IN_FETCH_AND_OR_4, BUILT_IN_FETCH_AND_OR_8, BUILT_IN_FETCH_AND_AND_N, BUILT_IN_FETCH_AND_AND_1, BUILT_IN_FETCH_AND_AND_2, BUILT_IN_FETCH_AND_AND_4, BUILT_IN_FETCH_AND_AND_8, BUILT_IN_FETCH_AND_XOR_N, BUILT_IN_FETCH_AND_XOR_1, BUILT_IN_FETCH_AND_XOR_2, BUILT_IN_FETCH_AND_XOR_4, BUILT_IN_FETCH_AND_XOR_8, BUILT_IN_FETCH_AND_NAND_N, BUILT_IN_FETCH_AND_NAND_1, BUILT_IN_FETCH_AND_NAND_2, BUILT_IN_FETCH_AND_NAND_4, BUILT_IN_FETCH_AND_NAND_8, BUILT_IN_ADD_AND_FETCH_N, BUILT_IN_ADD_AND_FETCH_1, BUILT_IN_ADD_AND_FETCH_2, BUILT_IN_ADD_AND_FETCH_4, BUILT_IN_ADD_AND_FETCH_8, BUILT_IN_SUB_AND_FETCH_N, BUILT_IN_SUB_AND_FETCH_1, BUILT_IN_SUB_AND_FETCH_2, BUILT_IN_SUB_AND_FETCH_4, BUILT_IN_SUB_AND_FETCH_8, BUILT_IN_OR_AND_FETCH_N, BUILT_IN_OR_AND_FETCH_1, BUILT_IN_OR_AND_FETCH_2, BUILT_IN_OR_AND_FETCH_4, BUILT_IN_OR_AND_FETCH_8, BUILT_IN_AND_AND_FETCH_N, BUILT_IN_AND_AND_FETCH_1, BUILT_IN_AND_AND_FETCH_2, BUILT_IN_AND_AND_FETCH_4, BUILT_IN_AND_AND_FETCH_8, BUILT_IN_XOR_AND_FETCH_N, BUILT_IN_XOR_AND_FETCH_1, BUILT_IN_XOR_AND_FETCH_2, BUILT_IN_XOR_AND_FETCH_4, BUILT_IN_XOR_AND_FETCH_8, BUILT_IN_NAND_AND_FETCH_N, BUILT_IN_NAND_AND_FETCH_1, BUILT_IN_NAND_AND_FETCH_2, BUILT_IN_NAND_AND_FETCH_4, BUILT_IN_NAND_AND_FETCH_8, BUILT_IN_BOOL_COMPARE_AND_SWAP_N, BUILT_IN_BOOL_COMPARE_AND_SWAP_1, BUILT_IN_BOOL_COMPARE_AND_SWAP_2, BUILT_IN_BOOL_COMPARE_AND_SWAP_4, BUILT_IN_BOOL_COMPARE_AND_SWAP_8, BUILT_IN_VAL_COMPARE_AND_SWAP_N, BUILT_IN_VAL_COMPARE_AND_SWAP_1, BUILT_IN_VAL_COMPARE_AND_SWAP_2, BUILT_IN_VAL_COMPARE_AND_SWAP_4, BUILT_IN_VAL_COMPARE_AND_SWAP_8, BUILT_IN_LOCK_TEST_AND_SET_N, BUILT_IN_LOCK_TEST_AND_SET_1, BUILT_IN_LOCK_TEST_AND_SET_2, BUILT_IN_LOCK_TEST_AND_SET_4, BUILT_IN_LOCK_TEST_AND_SET_8, BUILT_IN_LOCK_RELEASE_N, BUILT_IN_LOCK_RELEASE_1, BUILT_IN_LOCK_RELEASE_2, BUILT_IN_LOCK_RELEASE_4, BUILT_IN_LOCK_RELEASE_8, BUILT_IN_SYNCHRONIZE: New. * builtins.c (called_as_built_in): Rewrite from CALLED_AS_BUILT_IN as a function. Accept __sync_ as a prefix as well. (expand_builtin_sync_operation, expand_builtin_compare_and_swap, expand_builtin_lock_test_and_set, expand_builtin_synchronize, expand_builtin_lock_release): New. (expand_builtin): Call them. * c-common.c (DEF_BUILTIN): Don't require __builtin_ prefix if neither BOTH_P nor FALLBACK_P are defined. (builtin_type_for_size): New. (sync_resolve_size, sync_resolve_params, sync_resolve_return): New. (resolve_overloaded_builtin): New. * c-common.h (resolve_overloaded_builtin): Declare. (builtin_type_for_size): Declare. * c-typeck.c (build_function_call): Invoke resolve_overloaded_builtin. * expr.c (sync_add_optab, sync_sub_optab, sync_ior_optab, sync_and_optab, sync_xor_optab, sync_nand_optab, sync_old_add_optab, sync_old_sub_optab, sync_old_ior_optab, sync_old_and_optab, sync_old_xor_optab, sync_old_nand_optab, sync_new_add_optab, sync_new_sub_optab, sync_new_ior_optab, sync_new_and_optab, sync_new_xor_optab, sync_new_nand_optab, sync_compare_and_swap, sync_compare_and_swap_cc, sync_lock_test_and_set, sync_lock_release): New. * optabs.h: Declare them. * expr.h (expand_val
[Bug fortran/21034] internal compiler error: in gfc_trans_auto_array_allocation, at fortran/trans-array.c:3036
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-14 23:33 --- Could you attach the .f90 file? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21034
[Bug tree-optimization/21021] [4.1 Regression] ICE in tree-vrp building glibc
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-14 23:07 --- Patch posted: http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01668.html -- What|Removed |Added CC||dnovillo at gcc dot gnu dot ||org AssignedTo|dnovillo at gcc dot gnu dot |kazu at cs dot umass dot edu |org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21021
[Bug tree-optimization/21030] [4.1 Regression] ICE in set_value_range building 176.gcc with -O2
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-14 23:02 --- A comment in the patch says "Tested on i686-pc-linux-gnu", but it just means that it will have been tested by the time I post this patch. :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21030
[Bug libstdc++/21035] New: Documentation for std::basic_string::compare() incorrect
The comments in basic_string.h above std::basic_string::compare(...) and therefore the Doxygen-generated documentation do not correctly describe the behaviour of the compare() member function. In all cases, the comments describe compare() as comparing strings by length first, and calling traits::compare second. However, the code (and presumably the standard?) performs these in the opposite order, to provide a proper lexicographical compare. -- Summary: Documentation for std::basic_string::compare() incorrect Product: gcc Version: unknown Status: UNCONFIRMED Severity: minor Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: IRSWalker at ntlworld dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21035
[Bug tree-optimization/21030] [4.1 Regression] ICE in set_value_range building 176.gcc with -O2
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-14 23:01 --- Created an attachment (id=8638) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8638&action=view) patch -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |kazu at cs dot umass dot edu |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21030
[Bug fortran/21034] internal compiler error: in gfc_trans_auto_array_allocation, at fortran/trans-array.c:3036
--- Additional Comments From nicolas dot girard at nerim dot net 2005-04-14 22:35 --- Created an attachment (id=8637) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8637&action=view) Assembler file generated using the -save-temps option -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21034
[Bug fortran/21034] New: internal compiler error: in gfc_trans_auto_array_allocation, at fortran/trans-array.c:3036
Hi, I was in the process of translating a program written in f77 into f90 when this bug occurred. All I did was to add parameters to a function ; these parameters must correspond to the dimensions of arrays, as I want to allocate memory to them dynamically. I declared my arrays like: real*8,dimension(n1,n2) tab1, tab2 and n1 and n2 are the two variables I added in the parameters of my function. "$ gfc --version" gives: GNU Fortran 95 (GCC 4.1.0 20050413 (experimental)) Compilation options: -ffixed-line-length-132 -Wall -static I'm completely stuck because of this problem, therefore if you had the slightest idea, even just to get round this, I'd be *much* interested... Many thanks in advance ! -- Summary: internal compiler error: in gfc_trans_auto_array_allocation, at fortran/trans- array.c:3036 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: nicolas dot girard at nerim dot net CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21034
[Bug c/19435] spurious warnings with nested array constructors
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-04-14 22:25 --- *** Bug 21033 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||acct4290 at dedion dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19435
[Bug c/21033] Erroneous "excess elements in array initializer" warning
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-04-14 22:25 --- *** This bug has been marked as a duplicate of 19435 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21033
[Bug c/21033] Erroneous "excess elements in array initializer" warning
--- Additional Comments From acct4290 at dedion dot com 2005-04-14 22:14 --- Created an attachment (id=8636) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8636&action=view) Preprocessed (.i) file for test case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21033
[Bug tree-optimization/21030] [4.1 Regression] ICE in set_value_range building 176.gcc with -O2
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-14 22:14
---
Reduced down to:
void
foo (int unit)
{
int i;
for (i = 0; unit; i++, unit--)
{
if (i >= 0)
{
int j = i;
while (j)
j--;
}
}
}
--
What|Removed |Added
CC||kazu at cs dot umass dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21030
[Bug c/21033] Erroneous "excess elements in array initializer" warning
--- Additional Comments From acct4290 at dedion dot com 2005-04-14 22:12 --- Created an attachment (id=8635) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8635&action=view) Source file for self-contained test case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21033
[Bug c/21033] New: Erroneous "excess elements in array initializer" warning
gcc erroneously reports "excess elements in array initializer" under certain
circumstances (sample code attached). I'm using gcc 3.3.3 under Fedora Core 2,
but I've seen the same problem on 3.4 and 4.0 experimental.
begin self-contained test program bug.c
/* I know you don't want #includes, but this is here just for the
* sake of printf(). It can probably be safely removed. */
#include
/
* This array is okay.
/
int *a[] =
{
(int []) { 1, 2, 3, 4, 0 },
(int []) { 5, 6, 0 },
(int []) { 7, 8, 9, 10, 11, 12, 13, 0 },
(int []) { 14, 0 }
};
/
* This array should be identical. It contains all the same
* elements as a[], but this time the size (4) is specified.
* Gcc generates "excess element" warnings for each sub-array
* with more than 4 elements, even though the length of these
* arrays has NOT been specified.
/
int *b[4] =
{
(int []) { 1, 2, 3, 4, 0 }, /*
WARNING: excess elements in array initializer */
(int []) { 5, 6, 0 },
(int []) { 7, 8, 9, 10, 11, 12, 13, 0 },/* WARNING: excess
elements in array initializer */
(int []) { 14, 0 }
};
/
* This array is the same as b[], except the size of each sub-
* array is specified. It compiles without warnings and looks
* the same as a[] when passed to print_array().
/
int *c[4] =
{
(int [5]) { 1, 2, 3, 4, 0 },
(int [3]) { 5, 6, 0 },
(int [8]) { 7, 8, 9, 10, 11, 12, 13, 0 },
(int [2]) { 14, 0 }
};
/
* Not only does the compiler throw warnings, it also produces
* different code. On my machine, print_array() produces the
* same output from a[] and c[], but not from b[].
/
void
print_array (int **ptr, int count)
{
int i, j;
for (i=0; i < count; i++)
for (j=0; ptr[i][j]; j++)
printf ("%d ", ptr[i][j]);
printf ("\n");
}
int main (int argc, char **argv)
{
print_array (a, sizeof (a) / sizeof (*a));
print_array (b, sizeof (b) / sizeof (*b));
print_array (c, sizeof (c) / sizeof (*c));
return 0;
}
end self-contained test program bug.c
Here is the gcc command line. Where should I attach the -save-temps
output files?
# gcc -v -save-temps bug.c
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --disable-libunwind-exceptions --with-system-zlib
--enable-__cxa_atexit --host=i386-redhat-linux
Thread model: posix
gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7)
/usr/lib/gcc-lib/i386-redhat-linux/3.3.3/cc1 -E -quiet -v -D__GNUC__=3
-D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=3 bug.c bug.i
ignoring nonexistent directory "/usr/i386-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/usr/lib/gcc-lib/i386-redhat-linux/3.3.3/include
/usr/include
End of search list.
/usr/lib/gcc-lib/i386-redhat-linux/3.3.3/cc1 -fpreprocessed bug.i -quiet
-dumpbase bug.c -auxbase bug -version -o bug.s
GNU C version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) (i386-redhat-linux)
compiled by GNU C version 3.3.3 20040412 (Red Hat Linux 3.3.3-7).
GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=129392
bug.c:23: warning: excess elements in array initializer
bug.c:23: warning: (near initialization for `(anonymous)')
bug.c:25: warning: excess elements in array initializer
bug.c:25: warning: (near initialization for `(anonymous)')
bug.c:25: warning: excess elements in array initializer
bug.c:25: warning: (near initialization for `(anonymous)')
bug.c:25: warning: excess elements in array initializer
bug.c:25: warning: (near initialization for `(anonymous)')
bug.c:25: warning: excess elements in array initializer
bug.c:25: warning: (near initialization for `(anonymous)')
as -V -Qy -o bug.o bug.s
GNU assembler version 2.15.90.0.3 (i386-redhat-linux) using BFD version
2.15.90.0.3 20040415
/usr/lib/gcc-lib/i386-redhat-linux/3.3.3/collect2 --eh-frame-hdr -m elf_i386
-dynamic-linker /lib/ld-linux.so.2
/usr/lib/gcc-lib/i386-redhat-linux/3.3.3/../../../crt1.o
/usr/lib/gcc-lib/i386-redhat-linux/3.3.3/../../../crti.o
/usr/lib/gcc-lib/i386-redhat-linux/3.3.3/crtbegin.o
-L/usr/lib/gcc-lib/i386-redhat-linux/3.3.3
-L/usr/lib/gcc-lib/i386-redhat-linux/3.3.3/../../.. bug.o -lgcc --as-needed
-lg
[Bug middle-end/21032] GCC 3.4.3 wrongly reorders floating-point operations
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-14 22:01 --- Note neg just flips a bit so it is correct anyways and there is no loss of precession. This also happens on ppc darwin, I don't know what to make of this. A C person has to comment to say something about this. -- What|Removed |Added Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21032
[Bug c/21032] New: GCC 3.4.3 wrongly reorders floating-point operations
If you compile the function
void assign2(float* a, double b) {
volatile float v = -b;
*a = -v;
}
you will see that GCC 3.4.3, e.g., at -O2, produces
fldl12(%ebp)
fstps -20(%ebp)
movl8(%ebp), %eax
flds-20(%ebp)
fchs
fstps -4(%ebp)
flds-4(%ebp)
fchs
fstps (%eax)
where the first sign change is performed /after/ reducing the
precision and not /before/, as I believe it should (according
to ISO/IEC 9899, 5.1.2.3#13, 6.3.1.5#2 and 6.3.1.8#2).
The produced code seems also very badly optimized, considering
that something like
fldl12(%ebp)
fchs
fstps -4(%ebp)
flds-4(%ebp)
fchs
fstps (%eax)
would be significantly more efficient (besides being correct).
The same problem can be seen with gcc-4.0.0 20050406 (Fedora Core 3).
Roberto Bagnara
--
Summary: GCC 3.4.3 wrongly reorders floating-point operations
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bagnara at cs dot unipr dot it
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21032
[Bug libfortran/18495] Intrinisc function SPREAD is broken
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-04-14 21:49 --- Created an attachment (id=8634) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8634&action=view) Proposed fix for PR 18495. This appears to fix the benchmark in question. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18495
[Bug c++/20912] C++ FE emitting assignments to read-only global symbols
--- Additional Comments From schlie at comcast dot net 2005-04-14 21:28 --- (In reply to comment #0) I guess I misunderstand the problem, as given: const double ggPi = 3.14159265358979323846; double const divPi = 1 / ggPi; It would seem that neither ggPi or divPI should be designated "unchanging" at the tree/rtl level, as neither are global static const objects, although: 3.14159265358979323846 is, if stored as a value; as opposed to being inlined in the code as an immediate. ggPi and divPi are simply variables which are initialized with values at runtime; where the fact that they're "const" has prevented an assignment (other than an initializing one) being accepted as valid during semantic analysis. Where post semantic analysis, they're just variables just like any others which happen to have no assignments specified post initialization (as enforced by the front end); so should not be marked READONLY/unchanging to begin with, it would seem? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20912
[Bug tree-optimization/21031] Another missed forward propagation opportunity
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-14 20:50 --- Confirmed, I thought I saw a bug like before. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-14 20:50:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21031
[Bug tree-optimization/21030] [4.1 Regression] ICE in set_value_range building 176.gcc with -O2
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-14 20:44 --- Confirmed, also happens on i686-pc-linux-gnu. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2005-04-14 20:44:19 date|| Summary|ICE in set_value_range |[4.1 Regression] ICE in |building 176.gcc with -O2 |set_value_range building ||176.gcc with -O2 Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21030
[Bug tree-optimization/21031] New: Another missed forward propagation opportunity
Consider:
int
foo (int a)
{
int b = a != 0;
unsigned char c = b;
if (c)
return 1;
else
return 0;
}
We end up with code like this:
b_3 = a_2 != 0;
c_4 = (unsigned char) b_3;
if (c_4 != 0) goto ; else goto ;
We want to forward-propagate the preceding two statements into the COND_EXPR
and get
if (a_2 != 0) goto ; else goto ;
Unlike forward propagation opportunities noted in PR 14754 or PR15558,
this kind of opportunity occurs often in practice.
--
Summary: Another missed forward propagation opportunity
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P2
Component: tree-optimization
AssignedTo: kazu at cs dot umass dot edu
ReportedBy: kazu at cs dot umass dot edu
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21031
[Bug tree-optimization/21030] ICE in set_value_range building 176.gcc with -O2
--- Additional Comments From janis at gcc dot gnu dot org 2005-04-14 20:43 --- Created an attachment (id=8633) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8633&action=view) minimized test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21030
[Bug tree-optimization/21029] [4.1 Regression] vrp miscompiles Ada front-end, drops loop exit test in well-defined wrap-around circumstances
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-14 20:42 --- (In reply to comment #3) > The other thing is that signed integer wrapping is defined if we add -fwrapv > which means we now miss > compile some java programs too. Actually I tried basically the same program with the casts removed and it worked, it has to do with the casts. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21029
[Bug tree-optimization/21030] New: ICE in set_value_range building 176.gcc with -O2
Mainline GCC for powerpc-linux gets an ICE compiling 176.gcc from SPEC CPU2000 with -O2, as shown with this minimized test case: elm3b149% /home/janis/tools/gcc-mline-20050414/bin/gcc -O2 -c bug.c bug.c: In function ‘schedule_unit’: bug.c:5: internal compiler error: in set_value_range, at tree-vrp.c:124 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. That abort is in checking code added on 2005-04-09 by dnovillo. -- Summary: ICE in set_value_range building 176.gcc with -O2 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: janis at gcc dot gnu dot org CC: dnovillo at gcc dot gnu dot org,gcc-bugs at gcc dot gnu dot org GCC build triplet: powerpc-linux GCC host triplet: powerpc-linux GCC target triplet: powerpc-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21030
[Bug tree-optimization/21029] [4.1 Regression] vrp miscompiles Ada front-end, drops loop exit test in well-defined wrap-around circumstances
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-14 20:25 --- The other thing is that signed integer wrapping is defined if we add -fwrapv which means we now miss compile some java programs too. Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2005-04-14 20:25:02 date|| Summary|vrp miscompiles Ada front- |[4.1 Regression] vrp |end, drops loop exit test in|miscompiles Ada front-end, |well-defined wrap-around|drops loop exit test in |circumstances |well-defined wrap-around ||circumstances Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21029
[Bug tree-optimization/21029] vrp miscompiles Ada front-end, drops loop exit test in well-defined wrap-around circumstances
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-14
20:19 ---
Created an attachment (id=8632)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8632&action=view)
C testcase that triggers the bug
The problem is that (from the vrp dump):
Simulating statement (from ssa_edges): jD.1487_6 = (intD.0) iD.1486_1;
Visiting statement:
jD.1487_6 = (intD.0) iD.1486_1;
(analyze_scalar_evolution
(loop_nb = 1)
(scalar = j_6)
(get_scalar_evolution
(scalar = j_6)
(scalar_evolution = {123, +, 1}_1))
(set_scalar_evolution
(scalar = j_6)
(scalar_evolution = {123, +, 1}_1))
)
Found new range [123, 2147483647] for j_6
[...]
Visiting statement:
if (jD.1487_6 < 0) goto ; else goto ;
Visiting conditional with predicate: j_6 < 0
With known ranges
j_6: [123, 2147483647]
Predicate evaluates to: 0
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21029
[Bug tree-optimization/21029] vrp miscompiles Ada front-end, drops loop exit test in well-defined wrap-around circumstances
--- Additional Comments From dnovillo at redhat dot com 2005-04-14 20:18 --- Subject: Re: New: vrp miscompiles Ada front-end, drops loop exit test in well-defined wrap-around circumstances On Thu, Apr 14, 2005 at 08:16:09PM -, aoliva at gcc dot gnu dot org wrote: > Unfortunately, vrp seldom kicks in, so it's a bit difficult to > duplicate the problem. > Hmm? VRP is automatically enabled at -O2 and higher. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21029
[Bug tree-optimization/21029] New: vrp miscompiles Ada front-end, drops loop exit test in well-defined wrap-around circumstances
csets___elabb gets miscompiled in stage2, such that stage3 enters and endless loop compiling ada.ads. Unfortunately, vrp seldom kicks in, so it's a bit difficult to duplicate the problem. Perhaps it would make sense to add a command-line option to force vrp on, and add that to torture, just to see how it goes? -- Summary: vrp miscompiles Ada front-end, drops loop exit test in well-defined wrap-around circumstances Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: tree-optimization AssignedTo: dnovillo at gcc dot gnu dot org ReportedBy: aoliva at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21029
[Bug target/21017] ppc 64bit target not using rlwinm
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-14 19:40 --- Looks like subregs are getting in the way. Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-14 19:40:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21017
[Bug ada/6872] can't build cross including ada to powerpc-ibm-aix4.3.3.0
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-14 19:35 --- *** Bug 21028 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||ltg at zes dot uni-bremen ||dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6872
[Bug ada/21028] Cross build failure from i686-linux to powerpc-aix5.2
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-14 19:35 --- *** This bug has been marked as a duplicate of 6872 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21028
[Bug ada/21028] New: Cross build failure from i686-linux to powerpc-aix5.2
I tried to build a gcc-3.4-20050408 cross compiler for a powerpc-aix5.2 system, and I got the following: gcc -O9 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long-DHAVE_CONFIG_H gcov-dump.o version.o ../libiberty/libiberty.a -o gcov-dump gcc -c -O9 -mminimal-toc -gnatpg -gnata -I- -I. -Iada -I/home/ltg/software/src/work/gcc-3.4-20050408/gcc/ada /home/ltg/software/src/work/gcc-3.4-20050408/gcc/ada/ada.ads -o ada/ada.o gnat1: error: invalid option `minimal-toc' make[1]: *** [ada/ada.o] Error 1 make[1]: Leaving directory `/home/ltg/software/src/work/objdir/gcc' make: *** [all-gcc] Error 2 Lothar -- Summary: Cross build failure from i686-linux to powerpc-aix5.2 Product: gcc Version: 3.4.4 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ltg at zes dot uni-bremen dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21028
[Bug target/20813] [4.1 Regression] ICE in gen_reg_rtx for 3 spec tests
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-14 19:30 --- (In reply to comment #2) > Here's a minimized test case that fails on powerpc64-linux with -m64 -O2: > On IRC pinskia pointed out that powerpc64-linux supports older CPUs by > default than does powerpc-darwin. The ICE doesn't happen with -mcpu=power3; > I didn't try earlier cpus. The only 64bit PPC CPU that does not support these optional instruction is the rs64a. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20813
[Bug fortran/17758] gfortran_abort and some others should be marked as noreturn
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-14 19:22 --- *** Bug 21027 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||tkoenig at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17758
[Bug fortran/21027] Triple call to _gfortran_runtime_error with -fbounds-check
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-14 19:22 --- This is a dup of bug 17758, which I reported when I was looking into a tree-optimizator ICE long time ago. I also noticed just recently when I was about to work on PR 17758, that _gfortran_runtime_error needed to be marked as noreturn also. *** This bug has been marked as a duplicate of 17758 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21027
[Bug fortran/21027] New: Triple call to _gfortran_runtime_error with -fbounds-check
$ cat bounds-check.f90
program main
integer, parameter :: n=10
integer :: m,i
integer a(n), b(n)
call foo(a,m)
do i=1,m
b(i) = a(i)*a(i)
end do
print *,b(1:m)
end program main
subroutine foo(a)
integer a(10)
a = 2
m = 12
end subroutine foo
$ gfortran -fbounds-check -fdump-tree-optimized -O2 -S bounds-check.f90
gets me (from the .t71.optimized file):
bb 0>:
foo (&a, &m);
D.474 = m;
if (D.474 > 0) goto ; else goto ;
:;
ivtmp.19 = 0;
:;
if (__builtin_expect (ivtmp.19 > 9, 0) != 0) goto ; else goto ;
:;
_gfortran_runtime_error ("Array reference out of bounds", "bounds-check.f90",
5);
_gfortran_runtime_error ("Array reference out of bounds", "bounds-check.f90",
5);
_gfortran_runtime_error ("Array reference out of bounds", "bounds-check.f90",
5);
:;
D.499 = *&a[ivtmp.19];
*&b[ivtmp.19] = D.499 * D.499;
ivtmp.19 = ivtmp.19 + 1;
if (() D.474 == ivtmp.19) goto ; else goto ;
which is still present in the assembly code:
.L16:
movl$5, %ecx
movl$.LC0, %edx
movl%ecx, 8(%esp)
movl%edx, 4(%esp)
movl$.LC1, (%esp)
call_gfortran_runtime_error
movl$5, %eax
movl%eax, 8(%esp)
movl$.LC0, %eax
movl%eax, 4(%esp)
movl$.LC1, (%esp)
call_gfortran_runtime_error
movl$5, %eax
movl%eax, 8(%esp)
movl$.LC0, %eax
movl%eax, 4(%esp)
movl$.LC1, (%esp)
call_gfortran_runtime_error
jmp .L5
Maybe it would help if _gfortran_runtime_error was marked
as non-returning.
--
Summary: Triple call to _gfortran_runtime_error with -fbounds-
check
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tkoenig at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21027
[Bug libgcj/21020] java.lang.NoSuchFieldError regression from earlier 4.0.0 snapshot
--- Additional Comments From mark at gcc dot gnu dot org 2005-04-14 19:14 --- This was "fixed" by the following patch on the 4.0 branch (20050414): 2005-04-14 Tom Tromey <[EMAIL PROTECTED]> * java/lang/natClassLoader.cc (_Jv_FindClass): Use system loader, not boot loader. (_Jv_RegisterInitiatingLoader): Likewise. (_Jv_UnregisterInitiatingLoader): Likewise. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21020
[Bug c++/21026] ICE in check_tag_decl, at cp/decl.c:3516
-- What|Removed |Added Known to fail||3.4.4 3.3.5 Known to work||4.0.0 4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21026
[Bug c++/21026] New: ICE in check_tag_decl, at cp/decl.c:3516
// compile with -O0
template class C
{
void f ()
{
typedef typeof(*this) int;
}
};
// not a regression, fixed in 4.0 and above:
// Search converges between 2004-06-24-trunk (#471) and 2004-06-26-trunk (#472).
--
Summary: ICE in check_tag_decl, at cp/decl.c:3516
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: belyshev at depni dot sinp dot msu dot ru
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21026
[Bug c++/20552] [3.3/3.4 Regression] ICE in write_type, at cp/mangle.c:1579
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-14 19:10 --- Fixed on the mainline: : Search converges between 2004-03-01-trunk (#446) and 2004-04-01-trunk (#447). Broke: : Search converges between 2001-03-18-trunk (#11) and 2001-03-25-trunk (#12). -- What|Removed |Added Summary|[3.4 Regression] ICE in |[3.3/3.4 Regression] ICE in |write_type, at |write_type, at |cp/mangle.c:1579|cp/mangle.c:1579 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20552
[Bug c++/20552] [3.4 Regression] ICE in write_type, at cp/mangle.c:1579
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru
2005-04-14 19:02 ---
// reduced testcase
template class C
{
void f ()
{
typedef int U;
typedef typeof(*this) U;
}
};
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Known to fail||3.4.4
Known to work|4.0.0 4.1.0 |4.0.0 4.1.0 3.3.5
Last reconfirmed|-00-00 00:00:00 |2005-04-14 19:02:49
date||
Summary|ICE on invalid code |[3.4 Regression] ICE in
||write_type, at
||cp/mangle.c:1579
Target Milestone|--- |3.4.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20552
[Bug libgcj/21020] java.lang.NoSuchFieldError regression from earlier 4.0.0 snapshot
--- Additional Comments From aph at gcc dot gnu dot org 2005-04-14 18:47 --- Do you want me to post the patch, then? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21020
[Bug testsuite/21010] New gcc.dg/vect tests fail
--- Additional Comments From janis at gcc dot gnu dot org 2005-04-14 18:22 --- Fixed with the patch. Today the tests pass on powerpc64-linux. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21010
[Bug target/20813] [4.1 Regression] ICE in gen_reg_rtx for 3 spec tests
--- Additional Comments From janis at gcc dot gnu dot org 2005-04-14 18:18
---
Here's a minimized test case that fails on powerpc64-linux with -m64 -O2:
extern void bar (void *);
extern double x;
void
foo (void)
{
char buf2 [32][1024];
bar (buf2 [(int) x]);
}
On IRC pinskia pointed out that powerpc64-linux supports older CPUs by
default than does powerpc-darwin. The ICE doesn't happen with -mcpu=power3;
I didn't try earlier cpus.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20813
[Bug libgcj/21020] java.lang.NoSuchFieldError regression from earlier 4.0.0 snapshot
--- Additional Comments From tromey at gcc dot gnu dot org 2005-04-14 18:05 --- For 4.0, my recent system class loader patch works around this problem. The attached patch should go in the trunk asap. I looked at all other users of _Jv_FindClassFromSignature, and this was the only problem caller. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21020
[Bug target/20634] code fails to compile/code generation issue with -funit-at-a-time
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru
2005-04-14 18:02 ---
reduced testcase, compile with '-O1 -fschedule-insns -funit-at-a-time',
fails with 3.3-hammer, 3.4, 4.0 and mainline, introduced in 2003:
: Search converges between 2003-07-11-trunk (#291) and 2003-07-12-trunk (#292).
--
unsigned int strlen (const char *);
static void append (char *p0, char **pp, int *j, char *p1)
{
int k = strlen (p0);
if (p1 && pp)
k += strlen (p1);
if (*j + k)
while (*j);
}
int yyparse (int foo)
{
if (foo)
append (0, 0, 0, 0);
else
append (0, 0, 0, 0);
}
--
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |2005-04-14 18:02:56
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20634
[Bug testsuite/21010] New gcc.dg/vect tests fail
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-14 18:02 --- Subject: Bug 21010 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-14 18:02:37 Modified files: gcc/testsuite/gcc.dg/vect: vect-ifcvt-1.c vect-ifcvt-2.c vect-ifcvt-3.c vect-ifcvt-4.c vect-ifcvt-5.c vect-ifcvt-6.c vect-ifcvt-7.c vect-ifcvt-9.c gcc/testsuite : ChangeLog Log message: PR testsuite/21010 * gcc.dg/vect/vect-ifcvt-1.c: Remove dg-do, add cleanup. * gcc.dg/vect/vect-ifcvt-2.c: Ditto. * gcc.dg/vect/vect-ifcvt-3.c: Ditto. * gcc.dg/vect/vect-ifcvt-4.c: Ditto. * gcc.dg/vect/vect-ifcvt-5.c: Ditto. * gcc.dg/vect/vect-ifcvt-6.c: Ditto. * gcc.dg/vect/vect-ifcvt-7.c: Ditto. * gcc.dg/vect/vect-ifcvt-9.c: Ditto. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/vect/vect-ifcvt-1.c.diff?cvsroot=gcc&r1=1.2&r2=1.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/vect/vect-ifcvt-2.c.diff?cvsroot=gcc&r1=1.2&r2=1.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/vect/vect-ifcvt-3.c.diff?cvsroot=gcc&r1=1.2&r2=1.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/vect/vect-ifcvt-4.c.diff?cvsroot=gcc&r1=1.2&r2=1.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/vect/vect-ifcvt-5.c.diff?cvsroot=gcc&r1=1.2&r2=1.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/vect/vect-ifcvt-6.c.diff?cvsroot=gcc&r1=1.2&r2=1.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/vect/vect-ifcvt-7.c.diff?cvsroot=gcc&r1=1.2&r2=1.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/vect/vect-ifcvt-9.c.diff?cvsroot=gcc&r1=1.2&r2=1.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5349&r2=1.5350 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21010
[Bug target/20126] [3.3/3.4/4.0 Regression] Inlined memcmp makes one argument null on entry
--- Additional Comments From roger at eyesopen dot com 2005-04-14 17:37 --- You'll notice in loop.c that everywhere that we currently set all_reduced to zero, we also set ignore to true. This change is to avoid wasting CPU cycles, if we know that an IV can't be eliminated, there's no point in trying to modify any more instructions that use it. At best, this incurs wasted CPU cycles, at worst we'll end up substituting in some places and not others, which will result in requiring both the original IV *and* the replacement IV which will increase register pressure in the loop. As your (Alex's) testing showed, I'm not sure that its strictly required for correctness, it's mainly to preserve consistency with the exisiting all_reduced invariants by using the same idiom as used elsewhere, but also as a potential compile-time/run-time micro-optimization. However for 4.0, I thought it best to reuse/copy the existing idiom, rather than risk clearing all_reduced without setting ignore (which may have potentially exposed code paths not seen before). We still need the 4.1 variant to be tested/committed to mainline. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20126
[Bug target/20126] [3.3/3.4/4.0 Regression] Inlined memcmp makes one argument null on entry
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-14 17:21 --- Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail On Apr 12, 2005, Roger Sayle <[EMAIL PROTECTED]> wrote: > ! v->ignore = 1; What's the point of the statement above? If we actually know the giv reg has the right value, why not use it for other purposes as well? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20126
[Bug middle-end/20739] [4.0/4.1 regression] ICE in gimplify_addr_expr
--- Additional Comments From roger at eyesopen dot com 2005-04-14 17:19 --- Thanks Alex! This is OK for mainline. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20739
[Bug middle-end/20739] [4.0/4.1 regression] ICE in gimplify_addr_expr
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-14
17:03 ---
Subject: Re: [PR middle-end/20739] lvalue cond-expr gimplification may crash on
cv-qual diffs
On Apr 4, 2005, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> If the operands of a cond-expr used as an lvalue differ in cv
> qualification, the front-end adds nop_exprs to add cv qualifiers that
> the gimplifier drops when simplifying &(T const)*v. The `&' was added
> by gimplify_cond_expr.
> The problem is that gimplify_addr_expr gimplifies its operand in such
> a way that the nop_expr is dropped, and nothing puts it back in, so
> when we test that, in the indirect_ref case in gimplify_addr_expr, the
> types are compatible, the test fails because of the missing
> cv-qualifier in the pointed-to type. This patch fixes this.
> Ok to install if bootstrap and regtest on amd64-linux-gnu pass?
Bootstrap and regtest pased on amd64-linux-gnu, at least for mainline.
I'm retesting on the branch, since I'm not entirely sure I actually
tested it there.
Index: gcc/ChangeLog
from Alexandre Oliva <[EMAIL PROTECTED]>
PR middle-end/20739
* gimplify.c (gimplify_addr_expr): Compensate for removal of
e.g. cv-qualification conversions.
Index: gcc/gimplify.c
===
RCS file: /cvs/gcc/gcc/gcc/gimplify.c,v
retrieving revision 2.122
diff -u -p -r2.122 gimplify.c
--- gcc/gimplify.c 1 Apr 2005 03:42:41 - 2.122
+++ gcc/gimplify.c 4 Apr 2005 11:28:04 -
@@ -3229,6 +3232,9 @@ gimplify_addr_expr (tree *expr_p, tree *
builtins like __builtin_va_end). */
/* Caution: the silent array decomposition semantics we allow for
ADDR_EXPR means we can't always discard the pair. */
+ /* Gimplification of the ADDR_EXPR operand may drop
+cv-qualification conversions, so make sure we add them if
+needed. */
{
tree op00 = TREE_OPERAND (op0, 0);
tree t_expr = TREE_TYPE (expr);
@@ -3238,9 +3244,9 @@ gimplify_addr_expr (tree *expr_p, tree *
{
#ifdef ENABLE_CHECKING
tree t_op0 = TREE_TYPE (op0);
- gcc_assert (TREE_CODE (t_op0) == ARRAY_TYPE
- && POINTER_TYPE_P (t_expr)
- && cpt_same_type (TREE_TYPE (t_op0),
+ gcc_assert (POINTER_TYPE_P (t_expr)
+ && cpt_same_type (TREE_CODE (t_op0) == ARRAY_TYPE
+ ? TREE_TYPE (t_op0) : t_op0,
TREE_TYPE (t_expr))
&& POINTER_TYPE_P (t_op00)
&& cpt_same_type (t_op0, TREE_TYPE (t_op00)));
Index: gcc/testsuite/ChangeLog
from Alexandre Oliva <[EMAIL PROTECTED]>
PR middle-end/20739
* gcc.dg/tree-ssa/pr20739.c: New test.
Index: gcc/testsuite/gcc.dg/tree-ssa/pr20739.c
===
RCS file: gcc/testsuite/gcc.dg/tree-ssa/pr20739.c
diff -N gcc/testsuite/gcc.dg/tree-ssa/pr20739.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ gcc/testsuite/gcc.dg/tree-ssa/pr20739.c 4 Apr 2005 11:28:20 -
@@ -0,0 +1,24 @@
+/* PR middle-end/20739 */
+
+/* dg-do compile */
+/* dg-options "-O" */
+
+/* We used to fail to compile this because gimplification dropped the
+ conversion that added the const qualifier to the sub-expression
+ involving baz, and then immediately noticed and reported its
+ absence. */
+
+typedef struct
+{
+char chars[5];
+}
+baz_t;
+
+extern baz_t * baz;
+
+extern void foo (baz_t);
+int
+bar (const baz_t * ls)
+{
+foo (ls == 0 ? *(&baz[0]) : *ls);
+}
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist [EMAIL PROTECTED], gnu.org}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20739
[Bug c++/21025] [3.4/4.0/4.1 Regression] ICE on template
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-14 16:52 --- Confirmed. It also worked with "3.4.0 20040116" which means it was broken after the branch of 3.4.0. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||ice-on-valid-code Known to fail||3.4.0 4.0.0 4.1.0 Known to work||3.3.3 Last reconfirmed|-00-00 00:00:00 |2005-04-14 16:52:50 date|| Summary|ICE on template |[3.4/4.0/4.1 Regression] ICE ||on template Target Milestone|--- |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21025
[Bug middle-end/20965] [4.1 Regression] GCC can no longer build itself on ppc-darwin
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-14 16:49 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-14 16:49:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20965
[Bug c/21024] Type mismatch in a comparison.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-14 16:48 --- Confirmed. This has been wrong since "3.5.0 20040909". -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-14 16:48:13 date|| Version|unknown |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21024
[Bug c++/21025] New: ICE on template
3.4.3 seg faults on this:
template struct X { char x[N]; };
template X<1 + sizeof(T) - sizeof(T)> F(T const &);
template struct S { int d() { F(1); } };
Appears to be quite dependent on the fact that the template argument
involves "sizeof(T) - sizeof(T)" - if the - is changed to a +, it works.
Ok in 3.3.2, and ok if S is not a template.
--
Summary: ICE on template
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: algrant at acm dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21025
[Bug tree-optimization/20773] ICE: SEGV building jar file
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru 2005-04-14 16:33 --- Created an attachment (id=8631) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8631&action=view) smaller testcase (4749 bytes) confirmed on amd64 with both 4.0.0 and mainline. -- What|Removed |Added Attachment #8539 is|0 |1 obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20773
[Bug target/21017] ppc 64bit target not using rlwinm
-- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21017
[Bug c/21024] New: Type mismatch in a comparison.
Consider:
extern void *bar (void);
int
foo (unsigned int *p)
{
const void *r = bar ();
if (r >= (const void *) *p)
return 1;
return 0;
}
t03.generic looks like so.
foo (p)
{
void * D.1155;
unsigned int D.1156;
int D.1157;
const void * r;
D.1155 = bar ();
r = D.1155;
D.1156 = *p;
if (D.1156 <= r)
{
D.1157 = 1;
return D.1157;
}
else
{
}
D.1157 = 0;
return D.1157;
}
Note that "if (D.1156 <= r)" has a type mismatch, namely an integer type
v.s. a pointer type.
This PR is the real cause of PR 21021.
--
Summary: Type mismatch in a comparison.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kazu at cs dot umass dot edu
CC: dnovillo at redhat dot com,gcc-bugs at gcc dot gnu dot
org
OtherBugsDependingO 21021
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21024
[Bug tree-optimization/21021] [4.1 Regression] ICE in tree-vrp building glibc
-- What|Removed |Added BugsThisDependsOn||21024 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21021
[Bug libmudflap/21023] New: mudflap reports errors
Yesterday I upgraded my fedora core 3 instalation and got gcc4 installed.
I tested the mudflap code and found a problem. The reduced test case is
below.
when I have two programs a.c and b.c
-- a.c --
typedef struct { char *name; } dummy;
dummy d[] = { {"a"}, {0} };
-- b.c --
typedef struct { char *name; } dummy;
extern dummy d[];
int
main (void)
{
dummy *pd = d;
while (pd->name)
{
printf ("%s\n", pd->name);
pd++;
}
}
and compile this with:
gcc4 -fmudflap a.c b.c -o a -lmudflap
when I run the program I get:
a
***
mudflap violation 1 (check/read): time=1113495140.046642 ptr=0x8049a00 size=4
pc=0xb7eff322 location=`b.c:9 (main)'
/usr/lib/libmudflap.so.0(__mf_check+0x44) [0xb7eff322]
./a(main+0x8b) [0x8048787]
/usr/lib/libmudflap.so.0(__wrap_main+0x1d8) [0xb7f0004e]
Nearby object 1: checked region begins 8B before and ends 5B before
mudflap object 0x80ca090: name=`__mf_lc_mask'
bounds=[0x8049a08,0x8049a0b] size=4 area=no-access check=0r/0w liveness=0
alloc time=1113495140.046375 pc=0xb7effe0a
Nearby object 2: checked region begins 16B before and ends 13B before
mudflap object 0x80ca028: name=`__mf_lookup_cache'
bounds=[0x8049a10,0x80c9a0f] size=524288 area=no-access check=0r/0w liveness=0
alloc time=1113495140.046371 pc=0xb7effe0a
number of nearby objects: 2
There should be no error.
I think the problem is in tree-mudflap.c in function mudflap_finish_file.
Here is a check for TREE_STATIC. I think this should be !TREE_PUBLIC ???
I assigned this to 4.0.1 because I probably can not assign this to 4.0.0
anymore?
--
Summary: mudflap reports errors
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libmudflap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hermantenbrugge at home dot nl
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i386-redhat-linux
GCC host triplet: i386-redhat-linux
GCC target triplet: i386-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21023
Bug: Segmentation fault
I wrote a program that is fine compiling by MS VC 7.1 or higher and works correctly. It also is compiling by CodeWarior 8.0. Unfortunately gcc says subj. :( Source code you can find in attach. gcc --version gcc (GCC) 3.3.5 (Gentoo Linux 3.3.5-r1, ssp-3.3.2-3, pie-8.7.7.1) Copyright (C) 2003 Free Software Foundation, Inc. bash-2.05b$ uname -a Linux ziggurat 2.6.10-gentoo-r6with_mppe #6 Tue Mar 15 17:39:51 EET 2005 i686 AMD Athlon(tm) AuthenticAMD GNU/Linux dcc was compiled by command emerge gcc program was compiled by command gcc 6.cpp compiler output is bash-2.05b$ gcc 6.cpp loki/HierarchyGenerators.h: In instantiation of `Loki::GenLinearHierarchy, Loki::Typelist, Loki::NullType> >, Chain::Functor, Chain::Stub>': 6.cpp:50: instantiated from `ChainWrapper, Loki::Typelist, Loki::NullType> >, Chain::Functor, Chai ::Stub> >' 6.cpp:71: instantiated from `Loki::GenScatterHierarchy, Loki::Typelist, Loki::NullType> >, Chain:: unctor, Chain::Stub>, ChainWrapper>' 6.cpp:71: instantiated from `Loki::GenScatterHierarchy, Loki::Typelist, Loki::NullType> >, C ain::Functor, Chain::Stub>, Loki::Typelist, Loki::Typelist, Loki::NullType> >, Chain::Functor, Chain::Stub>, Loki::NullType> >, ChainWrapper>' 6.cpp:71: instantiated from here loki/HierarchyGenerators.h:222: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://bugs.gentoo.org/> for instructions. Preprocessed source stored into /tmp/ccW13tKm.out file, please attach this to y ur bugreport. -- Best Regards, Antonio code.tar.bz2 Description: BZip2 compressed data
[Bug target/20924] [4.0 regression] inline float divide does not set correct fpu status flags
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-14 15:53 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20924
[Bug tree-optimization/21021] [4.1 Regression] ICE in tree-vrp building glibc
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-14 15:51 --- Before VRP (even before ASSERT_EXPR insertion), we have const void * r; unsigned int D.1157; void * D.1156; : : if (r_3 >= D.1157_5) goto ; else goto ; Note that we already have a type-mismatched comparison - an integer v.s. a pointer. tree-vrp.c:maybe_add_assert_expr inserts the following ASSERT_EXPR in the "else" branch of the "if" statement. r_14 = ASSERT_EXPR ; Eventually the propagation engine visits this ASSERT_EXPR with a call tree like so. simulate_stmt vrp_visit_stmt vrp_visit_assignment extract_range_from_expr extract_range_from_assert (ASSERT_EXPR ) value_ranges_intersect_p ([D.1156_2, D.1156_2], [0, D.1157_5 - 1]) value_inside_range (D.1157_5 - 1, [D.1156_2, D.1156_2]) compare_values (D.1157_5 - 1, D.1156_2) compare_values does some limited symbolic comparisons. In this case, it checks whether D.1156_2 == INF so that if that's the case, we can deduce that D.1157_5 - 1 < D.1156_2 But we cannot compute TYPE_MAX_VALUE (TREE_TYPE (D.1156_2)) because D.1156_2 is of a pointer type, causing the ICE. The root cause of the problem is that we have a type-mismatched comparison. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21021
[Bug target/20924] [4.0 regression] inline float divide does not set correct fpu status flags
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-14 15:43 --- Subject: Bug 20924 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-04-14 15:43:07 Modified files: gcc: ChangeLog gcc/config/ia64: ia64.md Log message: PR target/20924 * config/ia64/ia64.md (divsf3_internal_lat): Generate frcpa with fpsr 0 instead of fpsr 1. (divsf3_internal_thr): Ditto. (divdf3_internal_lat): Ditto. (divdf3_internal_thr): Ditto. (divxf3_internal_lat): Ditto. (divxf3_internal_thr): Ditto. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.153&r2=2.7592.2.154 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/ia64/ia64.md.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.146.8.1&r2=1.146.8.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20924
[Bug tree-optimization/20963] [4.1 Regression] ICE tree check: expected value_handle, have addr_expr in value_exists_in_set_bitmap, at tree-ssa-pre.c:437
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-14 15:25 --- Subject: Bug 20963 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-14 15:25:02 Modified files: gcc: ChangeLog tree-ssa-pre.c Log message: 2005-04-14 Daniel Berlin <[EMAIL PROTECTED]> Fix PR tree-optimization/20963 * tree-ssa-pre.c (compute_avail): Remove special case for TREE_INVARIANT. (create_expression_by_pieces): Add value numbers for forced out statements. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8288&r2=2.8289 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-pre.c.diff?cvsroot=gcc&r1=2.74&r2=2.75 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20963
