[Bug tree-optimization/30563] [4.3 Regression] ice for legal code with flags -O2 -fno-unit-at-a-time
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-01-24 07:33 ---
(In reply to comment #2)
Reduced testcase for that ICE:
extern __inline double
strtod (void)
{
}
strtol (void)
{
return strtod ();
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Component|c |tree-optimization
Ever Confirmed|0 |1
Keywords||ice-on-valid-code
Last reconfirmed|-00-00 00:00:00 |2007-01-24 07:33:12
date||
Summary|ice for legal code with |[4.3 Regression] ice for
|flags -O2 -fno-unit-at-a- |legal code with flags -O2 -
|time|fno-unit-at-a-time
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30563
[Bug tree-optimization/30564] [4.3 Regression] ice for legal code with -O3
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-01-24 07:24 --- Remove the dead code and it works. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30564
[Bug tree-optimization/30564] [4.3 Regression] ice for legal code with -O3
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-01-24 07:20 ---
Reduced testcase:
static int RawOrEnc = 0;
static inline void addpair(int fp, int un)
{
if (RawOrEnc == 0 && fp != un)
RawOrEnc = 1;
}
int f(int un0, char *a, unsigned int __s2_len)
{
addpair(un0, un0);
__s2_len < 4 ? __builtin_strcmp (a, "-") : 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30564
[Bug c++/30567] -fPIC -O3 optimizer bug (32-bit target only)
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-01-24 06:57 --- This works for me with "4.2.0 20061204" and "4.3.0 20070122": [EMAIL PROTECTED] pr30567]$ ~/gcc-4.2/bin/g++ -O3 -fPIC dbg.cpp [EMAIL PROTECTED] pr30567]$ !./ ./a.out 1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30567
[Bug middle-end/30568] -ftrapping-math should prevent folding/dead code stripping of some builtins
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-01-24 06:54 --- Part of the problem here is that darwin turns on no math-errno by default which turns the builtin functions into pure functions and since we don't use the result, we DCE it. pure functions are not allowed to trap IIRC the rules. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30568
[Bug target/30572] [4.3 Regression] libstdc++ links against /libgcc_s.1.dylib instead of $(prefix)/lib/libgcc_s.1.dylib
-- echristo at apple dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |echristo at apple dot com |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-01-24 06:40:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30572
[Bug target/30572] [4.3 Regression] libstdc++ links against /libgcc_s.1.dylib instead of $(prefix)/lib/libgcc_s.1.dylib
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-24 06:35 --- libgcc_s.1.dylib has the correct install name as far as I can tell (otool -L output): libgcc_s.1.dylib: /Users/pinskia/gcc-trunk-java/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.6) libstdc++6.dylib output: otool -L libstdc++.6.dylib libstdc++.6.dylib: /Users/pinskia/gcc-trunk-java/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.10.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.6) /libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30572
[Bug target/30572] [4.3 Regression] libstdc++ links against /libgcc_s.1.dylib instead of $(prefix)/lib/libgcc_s.1.dylib
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30572
[Bug target/30572] New: [4.3 Regression] libstdc++ links against /libgcc_s.1.dylib instead of $(prefix)/lib/libgcc_s.1.dylib
I don't know when this broke but this has been here between http://gcc.gnu.org/ml/gcc-testresults/2007-01/msg00121.html (rev 120402) and http://gcc.gnu.org/ml/gcc-testresults/2007-01/msg00134.html (rev 120429) For some reason I think this was caused by the toplevel libgcc which was introduced inbetween those revisions. Also I thought I tested toplevel libgcc on ppc-darwin with getting no failures. -- Summary: [4.3 Regression] libstdc++ links against /libgcc_s.1.dylib instead of $(prefix)/lib/libgcc_s.1.dylib Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org GCC target triplet: powerpc-darwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30572
[Bug objc/27438] [4.1/4.2/4.3 Regression] [unit-at-a-time] '_OBJC_INSTANCE_0' defined but not used warning
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-01-24 06:06 --- Subject: Bug 27438 Author: pinskia Date: Wed Jan 24 06:06:29 2007 New Revision: 121104 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121104 Log: 2007-01-23 Andrew Pinski <[EMAIL PROTECTED]> PR objc/27438 * objc-act.c (objc_add_static_instance): Mark the decl as TREE_USED. 2007-01-23 Andrew Pinski <[EMAIL PROTECTED]> PR objc/27438 * objc.dg/const-str-12.m: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/objc.dg/const-str-12.m - copied unchanged from r121102, trunk/gcc/testsuite/objc.dg/const-str-12.m Modified: branches/gcc-4_2-branch/gcc/objc/ChangeLog branches/gcc-4_2-branch/gcc/objc/objc-act.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27438
[Bug objc/27438] [4.1/4.2/4.3 Regression] [unit-at-a-time] '_OBJC_INSTANCE_0' defined but not used warning
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-01-24 06:06 --- Subject: Bug 27438 Author: pinskia Date: Wed Jan 24 06:06:29 2007 New Revision: 121104 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121104 Log: 2007-01-23 Andrew Pinski <[EMAIL PROTECTED]> PR objc/27438 * objc-act.c (objc_add_static_instance): Mark the decl as TREE_USED. 2007-01-23 Andrew Pinski <[EMAIL PROTECTED]> PR objc/27438 * objc.dg/const-str-12.m: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/objc.dg/const-str-12.m - copied unchanged from r121102, trunk/gcc/testsuite/objc.dg/const-str-12.m Modified: branches/gcc-4_2-branch/gcc/objc/ChangeLog branches/gcc-4_2-branch/gcc/objc/objc-act.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog --- Comment #12 from pinskia at gcc dot gnu dot org 2007-01-24 06:06 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27438
[Bug objc/27438] [4.1/4.2/4.3 Regression] [unit-at-a-time] '_OBJC_INSTANCE_0' defined but not used warning
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-01-24 06:06 --- Subject: Bug 27438 Author: pinskia Date: Wed Jan 24 06:06:07 2007 New Revision: 121103 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121103 Log: 2007-01-23 Andrew Pinski <[EMAIL PROTECTED]> PR objc/27438 * objc-act.c (objc_add_static_instance): Mark the decl as TREE_USED. 2007-01-23 Andrew Pinski <[EMAIL PROTECTED]> PR objc/27438 * objc.dg/const-str-12.m: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/objc.dg/const-str-12.m - copied unchanged from r121102, trunk/gcc/testsuite/objc.dg/const-str-12.m Modified: branches/gcc-4_1-branch/gcc/objc/ChangeLog branches/gcc-4_1-branch/gcc/objc/objc-act.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27438
[Bug objc/27438] [4.1/4.2/4.3 Regression] [unit-at-a-time] '_OBJC_INSTANCE_0' defined but not used warning
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-01-24 06:01 --- Subject: Bug 27438 Author: pinskia Date: Wed Jan 24 06:01:09 2007 New Revision: 121102 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121102 Log: 2007-01-23 Andrew Pinski <[EMAIL PROTECTED]> PR objc/27438 * objc-act.c (objc_add_static_instance): Mark the decl as TREE_USED. 2007-01-23 Andrew Pinski <[EMAIL PROTECTED]> PR objc/27438 * objc.dg/const-str-12.m: New test. Added: trunk/gcc/testsuite/objc.dg/const-str-12.m Modified: trunk/gcc/objc/ChangeLog trunk/gcc/objc/objc-act.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27438
[Bug java/30454] [4.3 Regression] empty "zip" file in class path can cause leakage of file streams
--- Comment #17 from pinskia at gcc dot gnu dot org 2007-01-24 05:46 --- Subject: Bug 30454 Author: pinskia Date: Wed Jan 24 05:46:09 2007 New Revision: 121101 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121101 Log: 2007-01-23 Andrew Pinski <[EMAIL PROTECTED]> PR java/30454 * jcf-io.c (opendir_in_zip): Close the file and free zipf before returning after an error. Modified: trunk/gcc/java/ChangeLog trunk/gcc/java/jcf-io.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30454
[Bug java/30454] [4.3 Regression] empty "zip" file in class path can cause leakage of file streams
--- Comment #16 from pinskia at gcc dot gnu dot org 2007-01-24 05:46 --- Fixed finally. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30454
[Bug libstdc++/30571] Use of C++0x keywords in libstdc++-v3 headers
--- Comment #2 from doug dot gregor at gmail dot com 2007-01-24 04:36 --- (In reply to comment #1) > This is the normal problem adding a keyword in any language, I don't see why > C++0x 's static_assert not use a keyword in the already reserved identifier > namespace? The C++ committee opted to give this new functionality a new keyword, knowing that it breaks backward compatibility (in an admittedly small way). If we don't like the spelling, this is the time to complain directly to the committee. Unless we get them to change the spelling (very doubtful), we're going to have to deal with this. Other keywords are coming down the pipe... I expect that by April we'll also have "decltype" and "constexpr" to deal with, and in the future we'll probably also see "concept" and "concept_map", among other things. The -Wc++0x-compat warning is proposed to help us (and our users) make this transition smoothly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30571
[Bug bootstrap/30342] Tough time building 4.2.0 (CVS) on WinXP with Cygwin
--- Comment #4 from rob1weld at aol dot com 2007-01-24 04:26 --- The newest test results for building according to these instructions are here: http://gcc.gnu.org/ml/gcc-testresults/2007-01/msg00811.html Most tests are completed with a dozen (or less) errors - that is not too bad with _every_ possible option enabled. Libmudflap is usable (for debugging, then recompile with the feature off) and most of the errors are "output pattern test" errors (which, to ME, means that the expect script is not catching the output correctly) discounting those errors there are very few errors remaining. I'm looking into the Java test to see why there are so many errors. I did make a couple of bug reports but Java is not my strongest language - I can only hope that someone else will fix it for the cygwin platform :) . Overall 4.2.0 is testing very well (on _my_ platform), there are fewer errors reported than "make -k check" on 4.1.1 (release) - this does not mean it actually "works" better, only that the error checking does not find errors ;) . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30342
[Bug libstdc++/30571] Use of C++0x keywords in libstdc++-v3 headers
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-24 04:23 --- This is the normal problem adding a keyword in any language, I don't see why C++0x 's static_assert not use a keyword in the already reserved identifier namespace? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30571
[Bug libgcj/30570] Word "DEBUG" used as a variable in VMAccessController.java breaks build
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-24 04:19 --- DEBUG is NOT in the reserved identifier namespace so it should be ok, so I am thinking this is either a cygwin header bug or a wind32 header bug. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Component|java|libgcj http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30570
[Bug rtl-optimization/30367] gfortran compile times excessive for routines with large numbers of local variables
--- Comment #22 from pinskia at gcc dot gnu dot org 2007-01-24 04:17 --- (In reply to comment #21) > So, can we publish builds that yield reasonable compile times? I.e., gcc > configured with --disable-checking. The builds on gcc.gnu.org/wiki are not published by the FSF. The FSF does not publish any binaries really. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30367
[Bug libstdc++/30571] New: Use of C++0x keywords in libstdc++-v3 headers
The headers in ext/pb_ds use the identifier `static_assert' as the name of a class (which emulates static assertions). The class itself is declared in libstdc++-v3/include/ext/pb_ds/detail/type_utils.hpp and is used from a handful of other headers. This means that these facilities cannot be used with -std=c++0x and will warn if the -Wc++0x-compat flag goes in (see http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01971.html). I have two suggestions: 1) Rename class `static_assert' to something that isn't a C++0x keyword. 2) When __GXX_EXPERIMENTAL_CXX0X__ is defined, change the macro PB_DS_STATIC_ASSERT to use the real static_assert instead of this workaround. The macro is defined in several places, all of which will have to change anyway (when the static_assert class is renamed). I know this affects 4.3; I'm not sure if it affects (or matters for) 4.2 or earlier, but I suggest at least doing #1 everywhere that ext/pb_ds is available. -- Summary: Use of C++0x keywords in libstdc++-v3 headers Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: doug dot gregor at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30571
[Bug java/30570] New: Word "DEBUG" used as a variable in VMAccessController.java breaks build
I don't know if the severity might be a "blocker" but since I have a fix (which
is not so good - but works for me) I did not want to elevate the level and take
anyone away from something more important.
I'm getting an error during "make bootstrap" that halts the build.
In file included from
/cygdrive/C/makecygwin/gcc-4_2-branch/libjava/java/security/natVMAccessController.cc:17:
./java/security/VMAccessController.h:35: error: expected unqualified-id before
numeric constant
make[3]: *** [java/security/natVMAccessController.lo] Error 1
make[3]: Leaving directory
`/cygdrive/c/gcc-4_2-branch-build/i686-pc-cygwin/libjava'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory
`/cygdrive/c/gcc-4_2-branch-build/i686-pc-cygwin/libjava'
make[1]: *** [all-target-libjava] Error 2
make[1]: Leaving directory `/cygdrive/c/gcc-4_2-branch-build'
make: *** [bootstrap] Error 2
The ".java" file is here:
gcc-4_2-branch/libjava/java/security/VMAccessController.java
The ".cc" file is here:
gcc-4_2-branch/libjava/java/security/natVMAccessController.cc
The ".h" file is made here:
name=`echo classpath/lib/java/security/VMAccessController.class | sed -e
's/\.class$//' -e 's,classpath/lib/,,'`; \
/cygdrive/C/makecygwin/gcc-4_2-branch/mkinstalldirs `dirname $name`; \
./../.././gcc/gcjh -d . -classpath '' -bootclasspath classpath/lib
$name
Fix: Alter
/cygdrive/c/gcc-4_2-branch-build/i686-pc-cygwin/libjava/java/security/VMAccessController.h
(a file built during the compile) by changing the ".h" file as shown below. Now
re-type "make bootstrap".
Origonal (end of created ".h" file):
class java::security::VMAccessController : public ::java::lang::Object
{
private:
static void debug (::java::lang::String *);
VMAccessController ();
public: // actually package-private
static void pushContext (::java::security::AccessControlContext *);
static void popContext ();
static ::java::security::AccessControlContext *getContext ();
private:
static JArray< ::java::lang::Object *> *getStack ();
static ::java::security::AccessControlContext *DEFAULT_CONTEXT;
static const jint DEBUG = 1L;
public:
static ::java::lang::Class class$;
};
New:
class java::security::VMAccessController : public ::java::lang::Object
{
private:
static void debug (::java::lang::String *);
VMAccessController ();
public: // actually package-private
static void pushContext (::java::security::AccessControlContext *);
static void popContext ();
static ::java::security::AccessControlContext *getContext ();
private:
static JArray< ::java::lang::Object *> *getStack ();
static ::java::security::AccessControlContext *DEFAULT_CONTEXT;
#define DEBUG_TMP DEBUG
#undef DEBUG
static const jint DEBUG = 1L;
#define DEBUG DEBUG_TMP
public:
static ::java::lang::Class class$;
};
I am reluctant to change the ".java" or ".cc" for fear of breaking something.
The file gcc-4_2-branch/libjava/java/security/VMAccessController.java defines
the following:
private static final boolean DEBUG = gnu.classpath.Configuration.DEBUG;
Java wants the name "DEBUG" but so does something else (the compiler) so I get
the error "expected unqualified-id before numeric constant". The ".ii" file
(without my fix) makes the line in question "static const jint DEBUG = 1L;"
change to "static const jint = 1L;".
The compiler simply defines the word "DEBUG" to "" (empty string). My 'fix'
saves the value (in case it is ever defined) and restores it immediately after
it is finished.
Unfortunatley my fix requires you to wait until the file is made, and edit it
before it is used - there is enough time to do that but you need to be there at
the right time. Alternatley I can wait for the make to fail, edit the file and
continue.
I examined the ".ii" file and there are only two lines with the word
"debug/DEBUG" in them:
static void debug (::java::lang::String *); and static const jint DEBUG = 1L;
Only the capitalized word 'DEBUG' is affected, there are no other occurances of
the
word "DEBUG" in the ".ii" file so it must be a hidden internal compiler word.
If I check the "-D"'s for both my cc1.exe's I get this:
gcc/xgcc -g -v test.c
/usr/lib/gcc/i686-pc-cygwin/4.2.0/cc1.exe -quiet -v -iprefix
/cygdrive/c/gcc-4_2-branch-build/stage3-gcc/../lib/gcc/i686-pc-cygwin/4.2.0/
-D__CYGWIN32__ -D__CYGWIN__ -Dunix -D__unix__ -D__unix -idirafter
/usr/lib/gcc/i686-pc-cygwin/4.2.0/../../../../include/w32api -idirafter
/usr/lib/gcc/i686-pc-cygwin/4.2.0/../../../../i686-pc-cygwin/lib/../../include/w32api
test.c -quiet -dumpbase test.c -mtune=athlon-xp -march=athlon-xp -auxbase test
-g -version -o /cygdrive/c/DOCUME~1/HP_ADM~1/LOCALS~1/Temp/ccSrUn2h.s
gcc/xgcc -Bgcc -g -v test.c
gcc/cc1.exe -quiet -v -iprefix
/cygdrive/c/gcc-4_2-branch-build/stage3-gcc/../lib/gcc/i686-pc-cygwin/4.2.0/
-isystem gcc/include -D__CYGWIN32__ -D__CYGWIN__ -Dunix -D__unix__ -D__unix
-idirafter /usr/lib/gcc/i686-pc-cygwin/4.2.0/../../../../include/w32api
-idirafter
/usr/lib/gcc/i686-
[Bug rtl-optimization/30367] gfortran compile times excessive for routines with large numbers of local variables
--- Comment #21 from Bil dot Kleb at NASA dot gov 2007-01-24 03:50 --- So, can we publish builds that yield reasonable compile times? I.e., gcc configured with --disable-checking. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30367
[Bug rtl-optimization/30367] gfortran compile times excessive for routines with large numbers of local variables
--- Comment #20 from pinskia at gcc dot gnu dot org 2007-01-24 03:41 --- I should mention that the extra compile time spend with a --enable-checking build is internal checking in the compiler can be expensive at some points causing these compile time explosions. For an example, a checking alogorthim might be 2^x while the normal code is x^2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30367
[Bug rtl-optimization/30367] gfortran compile times excessive for routines with large numbers of local variables
--- Comment #19 from pinskia at gcc dot gnu dot org 2007-01-24 03:35 --- I think we can declare this as invalid then, as all compile times for the files are under 3 seconds. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30367
[Bug rtl-optimization/30367] gfortran compile times excessive for routines with large numbers of local variables
--- Comment #18 from Bil dot Kleb at NASA dot gov 2007-01-24 03:18 --- Created an attachment (id=12946) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12946&action=view) A make log with --disable-checking gfortran -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30367
[Bug rtl-optimization/30367] gfortran compile times excessive for routines with large numbers of local variables
--- Comment #17 from Bil dot Kleb at NASA dot gov 2007-01-24 03:16 --- I managed to compile from SVN source with --disable-checking, and now the compilation times for the offending routines are on the order of a second! I will attach the new make log in case you'd like to compare with the first. (Note: our code has undergone small changes in the interim.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30367
[Bug middle-end/30568] -ftrapping-math should prevent folding/dead code stripping of some builtins
--- Comment #2 from joseph at codesourcery dot com 2007-01-24 02:37 --- Subject: Re: New: -ftrapping-math should prevent folding/dead code stripping of some builtins On Wed, 24 Jan 2007, geoffk at gcc dot gnu dot org wrote: > when compiled with -ftrapping-math, should show that some flags are set, > FE_INVALID I think (maybe others). Instead it shows that no flags are set, > because GCC has completely folded out the call to acos(). I think this is the same as bug 29186. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30568
[Bug rtl-optimization/30367] gfortran compile times excessive for routines with large numbers of local variables
--- Comment #16 from jvdelisle at gcc dot gnu dot org 2007-01-24 02:21 --- The build scripts are automated and I don't think I have access to tweak those so I sent a note to FX to see if he can do so -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30367
[Bug c/30569] New: FLT_ROUNDS is wrong
ginclude/float.h has: /* Addition rounds to 0: zero, 1: nearest, 2: +inf, 3: -inf, -1: unknown. */ /* ??? This is supposed to change with calls to fesetround in . */ #undef FLT_ROUNDS #define FLT_ROUNDS 1 GCC should have a builtin which returns the correct value for FLT_ROUNDS at any time, and use it in this header. -- Summary: FLT_ROUNDS is wrong Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: FIXME Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: geoffk at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30569
[Bug middle-end/30568] -ftrapping-math should prevent folding/dead code stripping of some builtins
--- Comment #1 from geoffk at gcc dot gnu dot org 2007-01-24 02:11 --- Other builtins where this can apply are pow() and lround(). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30568
[Bug middle-end/30568] New: -ftrapping-math should prevent folding/dead code stripping of some builtins
This program:
#include
#include
#include
main()
{
unsigned flags;
feclearexcept(FE_ALL_EXCEPT);
(void)acos(1.1);
flags = fetestexcept(FE_ALL_EXCEPT);
printf("(void)acos( %e ) gives flags 0x%8x\n", 1.1, flags & FE_ALL_EXCEPT);
}
when compiled with -ftrapping-math, should show that some flags are set,
FE_INVALID I think (maybe others). Instead it shows that no flags are set,
because GCC has completely folded out the call to acos().
--
Summary: -ftrapping-math should prevent folding/dead code
stripping of some builtins
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: geoffk at gcc dot gnu dot org
GCC target triplet: *-*-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30568
[Bug fortran/30532] ^Z as EOF?
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2007-01-24 02:03 --- Subject: Bug 30532 Author: jvdelisle Date: Wed Jan 24 02:02:52 2007 New Revision: 121100 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121100 Log: 2007-01-23 Jerry DeLisle <[EMAIL PROTECTED]> PR fortran/30532 * gfortran.dg/ctrl-z.f90: New test. 2007-01-23 Jerry DeLisle <[EMAIL PROTECTED]> PR fortran/30481 * gfortran.dg/namelist_assumed_char.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/ctrl-z.f90 trunk/gcc/testsuite/gfortran.dg/namelist_assumed_char.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30532
[Bug fortran/30481] Accepts namelist-group object with assumed character length
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-01-24 02:03 --- Subject: Bug 30481 Author: jvdelisle Date: Wed Jan 24 02:02:52 2007 New Revision: 121100 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121100 Log: 2007-01-23 Jerry DeLisle <[EMAIL PROTECTED]> PR fortran/30532 * gfortran.dg/ctrl-z.f90: New test. 2007-01-23 Jerry DeLisle <[EMAIL PROTECTED]> PR fortran/30481 * gfortran.dg/namelist_assumed_char.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/ctrl-z.f90 trunk/gcc/testsuite/gfortran.dg/namelist_assumed_char.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30481
[Bug fortran/30532] ^Z as EOF?
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-01-24 01:57 --- Subject: Bug 30532 Author: jvdelisle Date: Wed Jan 24 01:56:55 2007 New Revision: 121099 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121099 Log: 2007-01-23 Jerry DeLisle <[EMAIL PROTECTED]> PR fortran/30532 * scanner.c (load_line): Remove check fot ctrl-z and don't gobble. 2007-01-23 Paul Thomas <[EMAIL PROTECTED]> PR fortran/30481 * match.c (gfc_match_namelist): Add check for assumed size character in namelist and provide error if found. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/match.c trunk/gcc/fortran/scanner.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30532
[Bug fortran/30481] Accepts namelist-group object with assumed character length
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-01-24 01:57 --- Subject: Bug 30481 Author: jvdelisle Date: Wed Jan 24 01:56:55 2007 New Revision: 121099 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121099 Log: 2007-01-23 Jerry DeLisle <[EMAIL PROTECTED]> PR fortran/30532 * scanner.c (load_line): Remove check fot ctrl-z and don't gobble. 2007-01-23 Paul Thomas <[EMAIL PROTECTED]> PR fortran/30481 * match.c (gfc_match_namelist): Add check for assumed size character in namelist and provide error if found. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/match.c trunk/gcc/fortran/scanner.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30481
[Bug c++/29018] empty enum accepted
--- Comment #5 from manu at gcc dot gnu dot org 2007-01-24 01:31 --- (In reply to comment #4) > I think we want to fix the test cases, but I don't want to sign up to fix them > myself. > "I think" is not enough. It would be nice to be able tell to whoever takes the burden of implementing this that fixing the testcases is OK and that such patch will be approved (and give any hints about the better way to fix the testcases). Since this affects testcases for g++ and libstdc++, this may require approval from more than one maintainer. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29018
[Bug other/28322] GCC new warnings and compatibility
--- Comment #3 from manu at gcc dot gnu dot org 2007-01-24 01:15 --- I agree with most of what you say but, unfortunately, unless someone that can approve a patch for this also agrees, it is pointless even to think about how to implement it. Also, bugzilla is not closely followed by GCC maintainers (except Andrew Pinski, but Andrew is not human, he lives in bugzilla's mind). You may have better luck in [EMAIL PROTECTED] (if you get ignored, you may need to try a few times, though). I would recommend to raise one point at a time. For example, 1. GCC should ignore unknown -Wno-* options if no other warnings are to be issued. This is always correct since the only effect of such an option would be to suppress warnings which might otherwise be issued. If no warnings are to be issued at all then treating even an unknown suppression as a no-op is clearly correct. If you get the appropriate maintainer to agree on this point, I volunteer to implement it for GCC 4.3 (subject to my free time, but it will be high in my priority list). You may ever convince the release manager to add it to GCC 4.2 before it is released. Good luck! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28322
[Bug c++/29018] empty enum accepted
--- Comment #4 from sje at cup dot hp dot com 2007-01-24 00:34 --- I think we want to fix the test cases, but I don't want to sign up to fix them myself. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29018
[Bug c++/30567] -fPIC -O3 optimizer bug (32-bit target only)
--- Comment #1 from rwgk at yahoo dot com 2007-01-24 00:10 --- Created an attachment (id=12945) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12945&action=view) standalone reproducer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30567
[Bug c++/30567] New: -fPIC -O3 optimizer bug (32-bit target only)
Platform: Fedora Core release 4 (Stentz) Linux sharptail.lbl.gov 2.6.11-1.1369_FC4smp #1 SMP Thu Jun 2 23:08:39 EDT 2005 i686 i686 i386 GNU/Linux % g++ -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: /net/rosie/scratch2/rwgk/gcc-4_2-branch/configure --prefix=/net/cci-filer1/vol1/tmp/rwgk/gcc_4_2-branch_2007_01_22_0959_fc4_i686 --enable-languages=c,c++,fortran Thread model: posix gcc version 4.2.0 20070122 (prerelease) I'll upload a standalone reproducer. Sorry it is not minimal, but it is already heavily reduced from the original code and has only standard header dependencies. To reproduce the problem: g++ -fPIC -O0 ~/dbg.cpp ; ./a.out 1 g++ -fPIC -O3 ~/dbg.cpp ; ./a.out 0 g++ -fPIC -O3 ~/dbg.cpp -DSCITBX_MAT3_TRACE_SIMPLE ; ./a.out 1 g++ -O3 ~/dbg.cpp ; ./a.out 1 The output should be "1" in all cases. The error occurs in the rot_mx::type() function near the end of the reproducer. Inserting std::cout statements in this function makes the error go away. Therefore I don't know what exactly is going wrong. By chance I noticed that the SCITBX_MAT3_TRACE_SIMPLE change (see code) also works around the problem. However, the trace() function always works if called directly. I noticed the error the first time on Dec 29, 2006 under 32-bit Fedora 6. Therefore I believe it is not Fedora 4 or 6 specific, but a general 32-bit optimizer problem. The gcc svn versions from Dec 29 and Jan 22 both work flawlessly on a 64-bit platfrom (Fedora 5). I hope you can take it from here. Let me know if you need any other information. -- Summary: -fPIC -O3 optimizer bug (32-bit target only) Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rwgk at yahoo dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30567
[Bug tree-optimization/30558] ICE with OpenMP and exceptions
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-01-23 23:46 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|c++ |tree-optimization Ever Confirmed|0 |1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2007-01-23 23:46:37 date|| Summary|ICE with gcc-4.2 when |ICE with OpenMP and |compiling blitz++-program |exceptions |using exceptions| Version|unknown |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30558
[Bug c++/30558] ICE with gcc-4.2 when compiling blitz++-program using exceptions
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-01-23 23:43 --- Created an attachment (id=12944) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12944&action=view) reduced testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30558
[Bug target/30517] Inefficient address calculation on i386
--- Comment #3 from astrange at ithinksw dot com 2007-01-23 23:36 --- > If they are the same size (and there is no speed impact), there is actually no > point to expect that they should compile to the same thing. Of course; I meant that they're the same size at the moment. The optimal version of the first is smaller, though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30517
[Bug tree-optimization/30565] ICE with -O1 -ftree-pre -ftree-loop-linear -funroll-loops
--- Comment #2 from drab at kepler dot fjfi dot cvut dot cz 2007-01-23 23:34 --- (In reply to comment #0) > > gcc -O1 -ftree-pre -ftree-loop-linear -funroll-loops -c psycho_n1.c -o > psycho_n1.o > ... > Removal of any of the optimizing flags makes it compile. Tested on i686. Sorry, you can forget the -funroll-loops, that is not required there to produce the ICE. So just this is enough: gcc -O1 -ftree-pre -ftree-loop-linear -c psycho_n1.c -o psycho_n1.o -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30565
[Bug c++/30566] New: -Wshadow warns about clashes between nested function parameters in C++
The following program:
void f( int x )
{
class InnerClass
{
public:
static void g( int x )
{
// empty
}
};
}
produces a warning:
t.cc: In static member function 'static void f(int)::InnerClass::g(int)':
t.cc:7: warning: declaration of 'int x' shadows a parameter
t.cc:1: warning: shadowed declaration is here
But it would be invalid for any function in InnerClass to try and use the outer
"int x" (and in fact if you try it, you correctly get an error).
--
Summary: -Wshadow warns about clashes between nested function
parameters in C++
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: geoffk at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30566
[Bug tree-optimization/24309] [4.1/4.2/4.3 Regression] ICE with -O3 -ftree-loop-linear
--- Comment #14 from drab at kepler dot fjfi dot cvut dot cz 2007-01-23 23:19 --- I've tested my original testcase for this bug and it seems to work for me on i686 and gcc version 4.3.0 20070121 (experimental). So, it seems to be fixed. Can anyone confirm, please? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24309
[Bug tree-optimization/30565] ICE with -O1 -ftree-pre -ftree-loop-linear -funroll-loops
--- Comment #1 from drab at kepler dot fjfi dot cvut dot cz 2007-01-23 23:08 --- Created an attachment (id=12943) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12943&action=view) Triggers the bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30565
[Bug tree-optimization/30565] New: ICE with -O1 -ftree-pre -ftree-loop-linear -funroll-loops
Hi, the attached code, when compiled with the following gcc: $ gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../../../gcc-SVN-20070121/gcc-SVN-20070121/configure --prefix=/usr/local/MDLinux/opt/gcc-4.3 --exec-prefix=/usr/local/MDLinux/opt/gcc-4.3 --sysconfdir=/etc --libdir=/usr/local/MDLinux/opt/gcc-4.3/lib --libexecdir=/usr/local/MDLinux/opt/gcc-4.3/libexec --sharedstatedir=/var --localstatedir=/var --program-suffix=-4.3 --with-x-includes=/usr/X11R6/include --with-x-libraries=/usr/X11R6/lib --enable-shared --enable-static --with-gnu-as --with-gnu-ld --with-stabs --enable-threads=posix --enable-version-specific-runtime-libs --disable-werror --enable-tls --disable-coverage --disable-libgcj --disable-checking --enable-multilib --with-x --enable-cmath --enable-libstdcxx-debug --enable-fast-character --enable-hash-synchronization --with-system-zlib --with-libbanshee --with-demangler-in-ld --disable-rpath --with-arch=athlon-xp --disable-libada --enable-languages=c,c++,fortran Thread model: posix gcc version 4.3.0 20070121 (experimental) using following command line: gcc -O1 -ftree-pre -ftree-loop-linear -funroll-loops -c psycho_n1.c -o psycho_n1.o ICEs like this: psycho_n1.c: In function âpsycho_n1â: psycho_n1.c:64: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. Removal of any of the optimizing flags makes it compile. Tested on i686. -- Summary: ICE with -O1 -ftree-pre -ftree-loop-linear -funroll- loops Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: drab at kepler dot fjfi dot cvut dot cz GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30565
[Bug libgcj/30513] [4.3 Regression] Bootstrap failure with libgcj on sparc-sun-solaris2.10
-- andreast at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |andreast at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-01-20 01:22:11 |2007-01-23 22:54:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30513
[Bug c++/27492] [4.0/4.1/4.2/4.3 regression] ICE on invalid covariant return type
--- Comment #5 from simartin at gcc dot gnu dot org 2007-01-23 22:34 --- Subject: Bug 27492 Author: simartin Date: Tue Jan 23 22:33:51 2007 New Revision: 121089 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121089 Log: 2007-01-23 Simon Martin <[EMAIL PROTECTED]> PR c++/27492 * decl.c (duplicate_decls): Don't reset DECL_INVALID_OVERRIDER_P for function decls. Added: trunk/gcc/testsuite/g++.dg/inherit/covariant15.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27492
[Bug libgcj/30513] [4.3 Regression] Bootstrap failure with libgcj on sparc-sun-solaris2.10
--- Comment #9 from andreast at gcc dot gnu dot org 2007-01-23 22:10 --- Here is what I get when I add -ansi to the CXX flags: gnu/java/nio/channels/natFileChannelImpl.cc: In member function 'void gnu::java::nio::channels::FileChannelImpl::implTruncate(jlong)': gnu/java/nio/channels/natFileChannelImpl.cc:262: error: invalid cast from type 'off_t' to type 'jlong' gnu/java/nio/channels/natFileChannelImpl.cc:268: error: invalid cast from type 'off_t' to type 'jlong' gnu/java/nio/channels/natFileChannelImpl.cc:270: error: no matching function for call to 'longlong_t::longlong_t(__java_long)' /export/data/devel-test/gcc-svn/objdir/./gcc/include/sys/types.h:70: note: candidates are: longlong_t::longlong_t() /export/data/devel-test/gcc-svn/objdir/./gcc/include/sys/types.h:70: note: longlong_t::longlong_t(const longlong_t&) gnu/java/nio/channels/natFileChannelImpl.cc:274: error: conversion from 'jlong' to non-scalar type 'off_t' requested gnu/java/nio/channels/natFileChannelImpl.cc:279: error: no matching function for call to 'longlong_t::longlong_t(jlong&)' /export/data/devel-test/gcc-svn/objdir/./gcc/include/sys/types.h:70: note: candidates are: longlong_t::longlong_t() /export/data/devel-test/gcc-svn/objdir/./gcc/include/sys/types.h:70: note: longlong_t::longlong_t(const longlong_t&) gnu/java/nio/channels/natFileChannelImpl.cc:282: error: no matching function for call to 'longlong_t::longlong_t(jlong&)' /export/data/devel-test/gcc-svn/objdir/./gcc/include/sys/types.h:70: note: candidates are: longlong_t::longlong_t() /export/data/devel-test/gcc-svn/objdir/./gcc/include/sys/types.h:70: note: longlong_t::longlong_t(const longlong_t&) gnu/java/nio/channels/natFileChannelImpl.cc: In member function 'void gnu::java::nio::channels::FileChannelImpl::seek(jlong)': gnu/java/nio/channels/natFileChannelImpl.cc:294: error: no matching function for call to 'longlong_t::longlong_t(jlong&)' /export/data/devel-test/gcc-svn/objdir/./gcc/include/sys/types.h:70: note: candidates are: longlong_t::longlong_t() /export/data/devel-test/gcc-svn/objdir/./gcc/include/sys/types.h:70: note: longlong_t::longlong_t(const longlong_t&) gnu/java/nio/channels/natFileChannelImpl.cc:295: error: no match for 'operator==' in 'r == -0x1' gnu/java/nio/channels/natFileChannelImpl.cc:297: error: cannot convert 'off_t' to 'jlong' in assignment gnu/java/nio/channels/natFileChannelImpl.cc: In member function 'virtual jlong gnu::java::nio::channels::FileChannelImpl::size()': gnu/java/nio/channels/natFileChannelImpl.cc:306: error: cannot convert 'off_t' to 'jlong' in return gnu/java/nio/channels/natFileChannelImpl.cc: In member function 'jint gnu::java::nio::channels::FileChannelImpl::available()': gnu/java/nio/channels/natFileChannelImpl.cc:423: error: conversion from 'int' to non-scalar type 'longlong_t' requested gnu/java/nio/channels/natFileChannelImpl.cc:426: error: conversion from 'int' to non-scalar type 'off_t' requested gnu/java/nio/channels/natFileChannelImpl.cc:426: error: no matching function for call to 'longlong_t::longlong_t(int)' /export/data/devel-test/gcc-svn/objdir/./gcc/include/sys/types.h:70: note: candidates are: longlong_t::longlong_t() /export/data/devel-test/gcc-svn/objdir/./gcc/include/sys/types.h:70: note: longlong_t::longlong_t(const longlong_t&) gnu/java/nio/channels/natFileChannelImpl.cc:428: error: no match for 'operator-' in 'sb.stat::st_size - where' gnu/java/nio/channels/natFileChannelImpl.cc: In member function 'jboolean gnu::java::nio::channels::FileChannelImpl::lock(jlong, jlong, jboolean, jboolean)': gnu/java/nio/channels/natFileChannelImpl.cc:464: error: no match for 'operator=' in 'lockdata.flock::l_start = pos' /export/data/devel-test/gcc-svn/objdir/./gcc/include/sys/types.h:70: note: candidates are: longlong_t& longlong_t::operator=(const longlong_t&) gnu/java/nio/channels/natFileChannelImpl.cc:465: error: no match for 'operator=' in 'lockdata.flock::l_len = len' /export/data/devel-test/gcc-svn/objdir/./gcc/include/sys/types.h:70: note: candidates are: longlong_t& longlong_t::operator=(const longlong_t&) gnu/java/nio/channels/natFileChannelImpl.cc: In member function 'void gnu::java::nio::channels::FileChannelImpl::unlock(jlong, jlong)': gnu/java/nio/channels/natFileChannelImpl.cc:483: error: no match for 'operator=' in 'lockdata.flock::l_start = pos' /export/data/devel-test/gcc-svn/objdir/./gcc/include/sys/types.h:70: note: candidates are: longlong_t& longlong_t::operator=(const longlong_t&) gnu/java/nio/channels/natFileChannelImpl.cc:484: error: no match for 'operator=' in 'lockdata.flock::l_len = len' /export/data/devel-test/gcc-svn/objdir/./gcc/include/sys/types.h:70: note: candidates are: longlong_t& longlong_t::operator=(const longlong_t&) gnu/java/nio/channels/natFileChannelImpl.cc: In member function 'java::nio::MappedByteBuffer* gnu::java::nio::channels::FileChannelImpl::mapImpl(jchar, jlong, jint)':
[Bug tree-optimization/30564] [4.3 Regression] ice for legal code with -O3
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |tree-optimization Keywords||ice-on-valid-code Summary|ice for legal code with -O3 |[4.3 Regression] ice for ||legal code with -O3 Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30564
[Bug c/30564] ice for legal code with -O3
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-01-23 21:56 --- Created an attachment (id=12942) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12942&action=view) somewhat reduced testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30564
[Bug c/30564] ice for legal code with -O3
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-01-23 21:55 --- Honza, we're not folding the comparison on inlining and later ICE in tree-vrp because of this (from the einline dump): # fp1_5 = PHI :; i_30 = fp0_6; goto (); :; D.1689_35 = unicount[i_3]; D.1690_36 = D.1689_35 == 0; D.1691_37 = i_3 != i_3; D.1692_38 = D.1690_36 && D.1691_37; if (D.1692_38) goto ; else goto ; :; RawOrEnc = 1; look at the i_3 != i_3 -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Component|tree-optimization |c Ever Confirmed|0 |1 Keywords|ice-on-valid-code | Last reconfirmed|-00-00 00:00:00 |2007-01-23 21:55:31 date|| Summary|[4.3 Regression] ice for|ice for legal code with -O3 |legal code with -O3 | Target Milestone|4.3.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30564
[Bug tree-optimization/30564] [4.3 Regression] ice for legal code with -O3
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |tree-optimization Keywords||ice-on-valid-code Summary|ice for legal code with -O3 |[4.3 Regression] ice for ||legal code with -O3 Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30564
[Bug c/30563] ice for legal code with flags -O2 -fno-unit-at-a-time
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-01-23 21:36 --- This is most likely a dup of bug 30537. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||30537 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30563
[Bug c/30564] ice for legal code with -O3
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-01-23 21:29 --- Nice one. (gdb) up #1 0x085aa055 in extract_range_from_assert (vr_p=0xbf806324, expr=0xb7ba1ee8) at /home/richard/src/trunk/gcc/tree-vrp.c:845 845 gcc_assert (limit != var); (gdb) call debug_generic_expr (expr) ASSERT_EXPR reducing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30564
[Bug c/30563] ice for legal code with flags -O2 -fno-unit-at-a-time
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-01-23 21:27 --- I get ./cc1 -quiet t.i -O -fno-unit-at-a-time t.i: In function atof: t.i:1156: internal compiler error: in optimize_inline_calls, at tree-inline.c:2674 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org Summary|ice for legal code with |ice for legal code with |flags -O2 -fno-unit-at-a- |flags -O2 -fno-unit-at-a- |time|time http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30563
[Bug c++/30558] ICE with gcc-4.2 when compiling blitz++-program using exceptions
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-01-23 21:19 --- reducing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30558
[Bug tree-optimization/29516] gfortran miscompiled
--- Comment #36 from rakdver at gcc dot gnu dot org 2007-01-23 21:19 --- Patch for 4.2: http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01941.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29516
[Bug c/30564] ice for legal code with -O3
--- Comment #1 from dcb314 at hotmail dot com 2007-01-23 21:00 --- Created an attachment (id=12941) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12941&action=view) C source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30564
[Bug c/30564] New: ice for legal code with -O3
I just tried to compile Suse Linux package lynx-2.8.6_rel2-23 with the GNU C compiler version 4.3 snapshot 20070119. The compiler said gcc -DLINUX -D_GNU_SOURCE -DHAVE_CONFIG_H -I../.. -I../../src -I../../src/chrtrans -I../../WWW/Library/Implementation -I../../ -O3 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -pipe -c ./makeuctb.c ./makeuctb.c: In function 'main': ./makeuctb.c:253: internal compiler error: in extract_range_from_assert, at tree-vrp.c:820 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. Preprocessed source code attached. Flag -O3 required. -- Summary: ice for legal code with -O3 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dcb314 at hotmail dot com GCC host triplet: x86_64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30564
[Bug c/30563] ice for legal code with flags -O2 -fno-unit-at-a-time
--- Comment #1 from dcb314 at hotmail dot com 2007-01-23 20:57 --- Created an attachment (id=12940) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12940&action=view) C source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30563
[Bug c/30563] New: ice for legal code with flags -O2 -fno-unit-at-a-time
I just tried to compile Suse Linux package lsvpd-0.16.0-35 with the GNU C compiler version 4.3 snapshot 20070119. The compiler said cc -O2 -g -fmessage-length=0 -D_FORTIFY_SOURCE=2 -fno-unit-at-a-time -I../lib -c -o node_handler.o node_handler.c node_handler.c:213: error: inlined_to pointer is set but no predecessors found call_inits/151(-1): (inline copy in main/144) availability:available(93) 19 insns tree finalized inlinable called by: calls: node_handler.c:213: internal compiler error: verify_cgraph_node failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. Preprocessed source code attached. Flags -O2 -fno-unit-at-a-time required. -- Summary: ice for legal code with flags -O2 -fno-unit-at-a-time Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dcb314 at hotmail dot com GCC host triplet: x86_64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30563
[Bug fortran/30554] ICE in mio_pointer_ref at module.c:1945
--- Comment #2 from burnus at gcc dot gnu dot org 2007-01-23 20:56 ---
Some more debug information:
The error occurs when the symbol "hessian" is written.
The error is gone if one removes the ": only ENERGY_CONSTRAINT" or the "use
atoms" from the POTENTIAL_ENERGY module (if you have {atom,constraint}.mod
files, the two use statements in POTENTIAL_ENERGY are enough to cause the ICE.)
Till write_symbol everything looks fine (and a printf(sym-name) prints
"hessian" before the ICE occurs.)
==1963== Invalid read of size 8
==1963==at 0x43C85E: mio_pointer_ref (module.c:1945)
==1963==by 0x43CCB6: mio_symbol_ref (module.c:2174)
==1963==by 0x43CD38: mio_symtree_ref (module.c:2200)
==1963==by 0x43D767: mio_expr (module.c:2699)
==1963==by 0x43C5E1: mio_array_spec (module.c:1846)
==1963==by 0x43DCC8: mio_symbol (module.c:2946)
==1963==by 0x43EC5B: write_symbol (module.c:3640)
==1963==by 0x43EE0E: write_symbol1 (module.c:3708)
==1963==by 0x43EDC1: write_symbol1 (module.c:3701)
==1963==by 0x43F149: write_module (module.c:3828)
==1963==by 0x43F34D: gfc_dump_module (module.c:3891)
==1963==by 0x446C2A: gfc_parse_file (parse.c:3239)
==1963== Address 0x28 is not stack'd, malloc'd or (recently) free'd
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30554
[Bug c++/30562] ice for legal code with -O2
--- Comment #1 from dcb314 at hotmail dot com 2007-01-23 20:55 --- Created an attachment (id=12939) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12939&action=view) C++ source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30562
[Bug c++/30562] New: ice for legal code with -O2
I just tried to compile Suse Linux package limal-ca-mgm-1.2.9-14 with the GNU C++ compiler version 4.3 snapshot 20070119. The compiler said /usr/include/blocxx/List.hpp: In member function 'void blocxx4::List::push_back(const T&) [with T = blocxx4::String]': /usr/include/blocxx/List.hpp:362: internal compiler error: in referenced_var_lookup, at tree-dfa.c:626 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. Preprocessed source code attached. Flag -O2 required. -- Summary: ice for legal code with -O2 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dcb314 at hotmail dot com GCC host triplet: x86_64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30562
[Bug middle-end/27416] ICE on invalid firstprivate/lastprivate
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-09-03 21:39:59 |2007-01-23 20:31:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27416
[Bug c/23587] Missing "warning: comparison is always false due to limited range of data type"
--- Comment #3 from pluto at agmk dot net 2007-01-23 20:15 --- *** Bug 29694 has been marked as a duplicate of this bug. *** -- pluto at agmk dot net changed: What|Removed |Added CC||pluto at agmk dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23587
[Bug other/29694] missed warnings about comparisons which are always true/false.
--- Comment #7 from pluto at agmk dot net 2007-01-23 20:15 --- (In reply to comment #4) > Subject: Re: missed warnings about comparisons which are always true/false. > > "manu at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: > > | Wextra warns for this, what is the bug? > > I believe pluto wants -Walways-true to cover this. > > -- Gaby exactly. *** This bug has been marked as a duplicate of 23587 *** -- pluto at agmk dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29694
[Bug libgcj/30550] Missing dependencies for ecjx target
--- Comment #3 from hjl at lucon dot org 2007-01-23 20:08 --- Fixed. -- hjl at lucon dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30550
[Bug libgcj/30550] Missing dependencies for ecjx target
--- Comment #2 from hjl at gcc dot gnu dot org 2007-01-23 20:01 --- Subject: Bug 30550 Author: hjl Date: Tue Jan 23 20:01:40 2007 New Revision: 121086 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121086 Log: 2007-01-23 H.J. Lu <[EMAIL PROTECTED]> PR libgcj/30550 * Makefile.am (ecjx_DEPENDENCIES): Add libgcj_bc.la if needed. * Makefile.in: Regenerated. Modified: trunk/libjava/ChangeLog trunk/libjava/Makefile.am trunk/libjava/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30550
[Bug middle-end/7651] Define -Wextra strictly in terms of other warning flags
--- Comment #22 from patchapp at dberlin dot org 2007-01-23 19:45 --- Subject: Bug number PR7651 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01933.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7651
[Bug libstdc++/30561] New: istream::operator>>(int&) broken
Here's a test case for the problem I point out in c++std-lib-17897. It shows
that operator>>(int&) behaves differently (and, I claim, incorrectly) from
operator>>(long&) or any other extractor except the one for short (which is
affected for the same reason).
$ cat t.cpp && g++ t.cpp -static && ./a.out
#include
#include
#include
struct NumPunct: std::numpunct
{
std::string do_grouping () const { return "\3"; }
char do_thousands_sep () const { return ';'; }
};
template
T extract (const char *s)
{
std::istringstream strm (s);
strm.imbue (std::locale (strm.getloc (), new NumPunct));
T x = T ();
strm >> x;
assert ((strm.failbit | strm.eofbit) == strm.rdstate ());
return x;
}
int main ()
{
assert (123L == extract("1;2;3"));
assert (123 == extract("1;2;3"));
}
Assertion failed: 123 == extract("1;2;3"), file t.cpp, line 26
Abort (core dumped)
--
Summary: istream::operator>>(int&) broken
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30561
[Bug fortran/29799] More informative message if a symbol is found in two modules
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-01-23 18:35:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29799
[Bug target/30486] segfault in aggregate_value_p while bootstrapping fortran
-- tbm at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|x86_64-linux-gnu| GCC host triplet|arm-linux-uclibcgnueabi | GCC target triplet|arm-linux-uclibcgnueabi |arm-linux-uclibcgnueabi,arm- ||linux-gnueabi Keywords||build, ice-on-valid-code Known to fail||4.1.0 4.2.0 Last reconfirmed|-00-00 00:00:00 |2007-01-23 17:53:28 date|| Summary|ICE in aggregate_value_p|segfault in ||aggregate_value_p while ||bootstrapping fortran http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30486
[Bug target/30486] ICE in aggregate_value_p
--- Comment #1 from tbm at cyrius dot com 2007-01-23 17:51 --- My backtrace looks slightly different but I can confirm this bug for arm-linux-gnueabi. Lennert Buytenhek reported on debian-arm that fortran fails to bootstrap when building natively and I verified that the testcase also segfaults for me - both with current GCC 4.1 and 4.2 from SVN. Program received signal SIGSEGV, Segmentation fault. aggregate_value_p (exp=0x0, fntype=0x0) at /home/tbm/scratch/gcc-4.2/gcc/function.c:1756 1756 tree type = (TYPE_P (exp)) ? exp : TREE_TYPE (exp); (gdb) where #0 aggregate_value_p (exp=0x0, fntype=0x0) at /home/tbm/scratch/gcc-4.2/gcc/function.c:1756 #1 0x004d9b7b in emit_library_call_value_1 (retval=1, orgfun=0x2b407a3468e0, value=0x0, fn_type=LCT_CONST, outmode=TImode, nargs=, p=0x7fff30ef3e20) at /home/tbm/scratch/gcc-4.2/gcc/calls.c:3312 #2 0x004da125 in emit_library_call_value (orgfun=0x0, value=0x0, fn_type=LCT_THROW, outmode=TImode, nargs=2) at /home/tbm/scratch/gcc-4.2/gcc/calls.c:3967 #3 0x005d49ba in expand_twoval_binop_libfunc (binoptab=, op0=0x2b407a363f20, op1=0x2b407a363f00, targ0=0x0, targ1=0x2b407a380320, code=MOD) at /home/tbm/scratch/gcc-4.2/gcc/optabs.c:2283 #4 0x005289cf in expand_divmod (rem_flag=1, code=, mode=DImode, op0=0x2b407a363f20, op1=0x2b407a363f00, target=0x2b407a363ee0, unsignedp=0) at /home/tbm/scratch/gcc-4.2/gcc/expmed.c:4914 #5 0x0052e887 in expand_expr_real_1 (exp=0x2b407a2d4280, target=0x2b407a363ee0, tmode=, modifier=, alt_rtl=0x7fff30ef4270) at /home/tbm/scratch/gcc-4.2/gcc/expr.c:8189 #6 0x005327c9 in expand_expr_real (exp=0x2b407a2d4280, target=0x2b407a363ee0, tmode=DImode, modifier=EXPAND_NORMAL, alt_rtl=0x7fff30ef4270) at /home/tbm/scratch/gcc-4.2/gcc/expr.c:6706 #7 0x0053783d in store_expr (exp=0x0, target=0x2b407a363ee0, call_param_p=0) at /home/tbm/scratch/gcc-4.2/gcc/expr.c:4370 #8 0x00539147 in expand_assignment (to=0x2b407a37e160, from=) at /home/tbm/scratch/gcc-4.2/gcc/expr.c:4249 #9 0x0052e709 in expand_expr_real_1 (exp=0x2b407a2d4460, target=0x2b407a2d3400, tmode=, modifier=, alt_rtl=) at /home/tbm/scratch/gcc-4.2/gcc/expr.c:8604 #10 0x005326b9 in expand_expr_real (exp=0x2b407a2d4460, target=0x2b407a2d3400, tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at /home/tbm/scratch/gcc-4.2/gcc/expr.c:6700 #11 0x00629049 in expand_expr_stmt (exp=0x0) at /home/tbm/scratch/gcc-4.2/gcc/expr.h:493 #12 0x0064fed0 in expand_gimple_basic_block (bb=0x2b407a37f100) at /home/tbm/scratch/gcc-4.2/gcc/cfgexpand.c:1383 #13 0x00650eda in tree_expand_cfg () at /home/tbm/scratch/gcc-4.2/gcc/cfgexpand.c:1649 #14 0x0064d4b8 in execute_one_pass (pass=0x9db040) at /home/tbm/scratch/gcc-4.2/gcc/passes.c:870 #15 0x0064d60c in execute_pass_list (pass=0x9db040) at /home/tbm/scratch/gcc-4.2/gcc/passes.c:917 #16 0x0048c22e in tree_rest_of_compilation (fndecl=0x2b407a37b1c0) -- tbm at cyrius dot com changed: What|Removed |Added CC||tbm at cyrius dot com, ||pbrook at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30486
[Bug ada/30560] gnatchop behaves differently dependend on argv[0] -- make check-ada fails
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-01-23 17:27 --- Subject: Bug 30560 Author: rguenth Date: Tue Jan 23 17:27:22 2007 New Revision: 121083 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121083 Log: 2007-01-23 Richard Guenther <[EMAIL PROTECTED]> PR testsuite/30560 * ada/acats/run_acats: Do not call gnatmake or gnatchop with full path. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/ada/acats/run_acats -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30560
[Bug c++/30558] ICE with gcc-4.2 when compiling blitz++-program using exceptions
--- Comment #2 from supermar at gmx dot de 2007-01-23 17:22 --- The uncompressed preprocessed source is 1,7MB (unless I'm doing something wrong here, it's just the -E flag to the usual compiler call, right?). I uploaded it to http://data.marssoft.de/attachment-bug-30558.bz2 Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30558
[Bug bootstrap/30510] [4.3 Regression] Gcc failed to bootstrap
--- Comment #14 from hjl at lucon dot org 2007-01-23 17:22 --- With revision 121082, I still got cc1: warning/export/build/gnu/gcc/build-ia64-linux/./prev-gcc/xgcc -B/export/build/gnu/gcc/build-ia64-linux/./prev-gcc/ -B/usr/gcc-4.3/ia64-unknown-linux-gnu/bin/ -c -DUSE_LIBUNWIND_EXCEPTIONS -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -Werror -Wc++-compat-DHAVE_CONFIG_H -I. -Icp -I/net/gnu-13/export/gnu/src/gcc/gcc/gcc -I/net/gnu-13/export/gnu/src/gcc/gcc/gcc/cp -I/net/gnu-13/export/gnu/src/gcc/gcc/gcc/../include -I/net/gnu-13/export/gnu/src/gcc/gcc/gcc/../libcpp/include -I/net/gnu-13/export/gnu/src/gcc/gcc/gcc/../libdecnumber -I/net/gnu-13/export/gnu/src/gcc/gcc/gcc/../libdecnumber/dpd -I../libdecnumber /net/gnu-13/export/gnu/src/gcc/gcc/gcc/cp/parser.c -o cp/parser.o s being treated as errors /net/gnu-13/export/gnu/src/gcc/gcc/gcc/cp/parser.c: In function cp_parser_type_specifier: /net/gnu-13/export/gnu/src/gcc/gcc/gcc/cp/parser.c:13206: warning: bases may be used uninitialized in this function /net/gnu-13/export/gnu/src/gcc/gcc/gcc/cp/parser.c:13206: note: bases was declared here I used --enable-checking=assert to configure gcc. -- hjl at lucon dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30510
[Bug ada/30560] gnatchop behaves differently dependend on argv[0] -- make check-ada fails
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-01-23 17:09 --- The testsuite is fixed by the following which should be safe because we're adding the path of $host_gnat* to PATH first. Index: run_acats === --- run_acats (revision 121081) +++ run_acats (working copy) @@ -40,7 +40,7 @@ echo '#!/bin/sh' > host_gnatchop echo PATH=`dirname $host_gnatchop`:'$PATH' >> host_gnatchop echo unset ADA_INCLUDE_PATH ADA_OBJECTS_PATH GCC_EXEC_PREFIX >> host_gnatchop echo export PATH >> host_gnatchop -echo exec $host_gnatchop '"$@"' >> host_gnatchop +echo exec gnatchop '"$@"' >> host_gnatchop chmod +x host_gnatchop @@ -48,7 +48,7 @@ echo '#!/bin/sh' > host_gnatmake echo PATH=`dirname $host_gnatmake`:'$PATH' >> host_gnatmake echo unset ADA_INCLUDE_PATH ADA_OBJECTS_PATH GCC_EXEC_PREFIX >> host_gnatmake echo export PATH >> host_gnatmake -echo exec $host_gnatmake '"$@"' >> host_gnatmake +echo exec gnatmake '"$@"' >> host_gnatmake chmod +x host_gnatmake -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30560
[Bug ada/30560] New: gnatchop behaves differently dependend on argv[0] -- make check-ada fails
I have
lrwxrwxrwx 1 root root 12 Jan 22 14:54 /usr/bin/gnatchop -> gnatchop-4.1
-rwxr-xr-x 1 root root 285224 Nov 25 12:24 /usr/bin/gnatchop-4.1
calling
> gnatchop x.adb
works as expected, calling
> gnatchop-4.1 x.adb
does not (PR29127), and
> /usr/bin/gnatchop x.adb
doesn't work either! (which breaks the acats host_gnatchop script)
It looks like gnatchop follows symlinks on each path component if
argv[0] is not gnatchop. From strace of the last case:
execve("/usr/bin/gnatchop", ["/usr/bin/gnatchop", "support/checkfil.ada"], [/*
80 vars */]) = 0
...
getcwd("/abuild/rguenther/obj/gcc/testsuite/ada/acats", 4096) = 46
readlink("/usr", 0x7fff76f33480, 4098) = -1 EINVAL (Invalid argument)
readlink("/usr/bin", 0x7fff76f33480, 4098) = -1 EINVAL (Invalid argument)
stat("support/checkfil.ada", {st_mode=S_IFREG|0644, st_size=7893, ...}) = 0
stat("support/checkfil.ada", {st_mode=S_IFREG|0644, st_size=7893, ...}) = 0
getcwd("/abuild/rguenther/obj/gcc/testsuite/ada/acats", 4096) = 46
readlink("/usr", 0x7fff76f332c0, 4098) = -1 EINVAL (Invalid argument)
readlink("/usr/bin", 0x7fff76f332c0, 4098) = -1 EINVAL (Invalid argument)
readlink("/usr/bin/gnatchop", "gnatchop-4.1", 4098) = 12
readlink("/usr/bin/gnatchop-4.1", 0x7fff76f332c0, 4098) = -1 EINVAL (Invalid
argument)
stat("/usr/bin/gnatchop-gcc", 0x7fff76f362c0) = -1 ENOENT (No such file or
directory)
stat("/usr/local/bin/gnatchop-gcc", 0x7fff76f362c0) = -1 ENOENT (No such file
or directory)
stat("/usr/bin/gnatchop-gcc", 0x7fff76f362c0) = -1 ENOENT (No such file or
direc
...
This causes make check-ada to fail like
=== acats support ===
Generating support files...gnatmake --GCC="/abuild/rguenther/obj/gcc/xgcc
-B/abuild/rguenther/obj/gcc/" -gnatws -O2
/space/rguenther/src/svn/trunk/gcc/testsuite/ada/acats/support/impbit.adb
-largs --GCC="/abuild/rguenther/obj/gcc/xgcc -B/abuild/rguenther/obj/gcc/"
/abuild/rguenther/obj/gcc/xgcc -c
-I/space/rguenther/src/svn/trunk/gcc/testsuite/ada/acats/support/
-B/abuild/rguenther/obj/gcc/ -gnatws -O2 -I-
/space/rguenther/src/svn/trunk/gcc/testsuite/ada/acats/support/impbit.adb
gnatbind -x impbit.ali
gnatlink impbit.ali --GCC=/abuild/rguenther/obj/gcc/xgcc
-B/abuild/rguenther/obj/gcc/
target_bit= 64
target_insn=nop
gnatchop-gcc: installation problem, executable not found
no source files written
gnatchop-gcc: installation problem, executable not found
no source files written
...
--
Summary: gnatchop behaves differently dependend on argv[0] --
make check-ada fails
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
OtherBugsDependingO 29127
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30560
[Bug bootstrap/30510] [4.3 Regression] Gcc failed to bootstrap
--- Comment #13 from martin at mpa-garching dot mpg dot de 2007-01-23 16:53 --- Could this be an enable-checking issue? I'm only seeing the problem when configuring with "--enable-checking=release", otherwise the compiler bootstraps fine. This is on i686-pc-linux-gnu. (I also have export BOOT_CFLAGS="-O2" export CFLAGS="-O2" if that makes a difference.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30510
[Bug bootstrap/30541] Top-level should pass GNATBIND, GNATLINK and GNATMAKE variables down
--- Comment #14 from rguenth at gcc dot gnu dot org 2007-01-23 16:37 --- Subject: Bug 30541 Author: rguenth Date: Tue Jan 23 16:37:09 2007 New Revision: 121082 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121082 Log: 2007-01-23 Richard Guenther <[EMAIL PROTECTED]> PR bootstrap/30541 * Makefile.def (flags_to_pass): Add GNATBIND and GNATMAKE. * Makefile.tpl (GNATBIND): Substitute it. (GNATMAKE): Likewise. (POSTSTAGE1_FLAGS_TO_PASS): Pass staged GNATBIND instead of STAGE_PREFIX. * Makefile.in: Regenerate. * configure: Regenerate. config/ * acx.m4 (ACX_PROG_GNAT): Check for gnatmake. libada/ * Makefile.in (STAGE_PREFIX): Do not define. (FLAGS_TO_PASS): Do not pass STAGE_PREFIX. gnattools/ * Makefile.in (STAGE_PREFIX): Do not define. ada/ * Make-lang.in: Replace invocations of gnatmake with $(GNATMAKE). (gnatboot2): Pass staged GNATMAKE instead of STAGE_PREFIX. (gnatboot3): Likewise. (GNATBIND): Do not define. * Makefile.in (GNATBIND): Do not define. Modified: trunk/ChangeLog trunk/Makefile.def trunk/Makefile.in trunk/Makefile.tpl trunk/config/ChangeLog trunk/config/acx.m4 trunk/configure trunk/gcc/ada/ChangeLog trunk/gcc/ada/Make-lang.in trunk/gcc/ada/Makefile.in trunk/gnattools/ChangeLog trunk/gnattools/Makefile.in trunk/libada/ChangeLog trunk/libada/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30541
[Bug c++/30558] ICE with gcc-4.2 when compiling blitz++-program using exceptions
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-23 16:27 --- Can you attach the preprocessed source? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30558
[Bug fortran/30549] compiler warning in resolve.c: possibly uninitialized use of name
--- Comment #5 from mueller at gcc dot gnu dot org 2007-01-23 16:26 --- fortran seems to bootstrap now. -- mueller at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30549
[Bug c/30559] compiler loops forever with flag -O3
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-01-23 16:25 --- This should be fixed with http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01728.html I think. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30559
[Bug c/30559] compiler loops forever with flag -O3
--- Comment #1 from dcb314 at hotmail dot com 2007-01-23 16:13 --- Created an attachment (id=12938) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12938&action=view) C source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30559
[Bug c/30559] New: compiler loops forever with flag -O3
I just tried to compile Suse Linux package libnasl-2.2.6-40 with the new GNU C compiler version 4.3 snapshot 20070119. I used compiler flag -O3. The compiler appeared to hang for more than 30 minutes when compiling source code file regex.c. I tried compiling the same file with the same compiler and flag -O2 and the compiler took 5 seconds. I tried compiling the same file with gcc 4.1.2 and flag -O3 and that compiler took 2.3 seconds. I checked the memory usage of the 20070119 compiler and it was about 40Megs on an idle system with 512Meg of RAM fitted. Preprocessed source code attached. Flag -O3 required. -- Summary: compiler loops forever with flag -O3 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dcb314 at hotmail dot com GCC host triplet: x86_64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30559
[Bug bootstrap/30556] should not call gnatmake/xnmake after stage1
--- Comment #5 from charlet at gcc dot gnu dot org 2007-01-23 16:10 --- << Is the file placed in srcdir? If not, it's *right* to generate the file on every stage. >> Fair enough. Then there's nothing to fix or improve here. Arno -- charlet at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30556
[Bug bootstrap/30510] [4.3 Regression] Gcc failed to bootstrap
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-01-23 16:06 --- Two, I don't see any warning from cp/parser.c at all. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30510
[Bug bootstrap/30510] [4.3 Regression] Gcc failed to bootstrap
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-01-23 16:04 --- For one your resolve.c patch is incorrect, see PR 30549. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||30549 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30510
[Bug bootstrap/30510] [4.3 Regression] Gcc failed to bootstrap
--- Comment #10 from hjl at lucon dot org 2007-01-23 16:02 --- http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01882.html works for me with revision 121081. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30510
[Bug bootstrap/30556] should not call gnatmake/xnmake after stage1
--- Comment #4 from bonzini at gnu dot org 2007-01-23 16:02 --- Is the file placed in srcdir? If not, it's *right* to generate the file on every stage. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30556
[Bug bootstrap/30510] [4.3 Regression] Gcc failed to bootstrap
--- Comment #9 from hjl at lucon dot org 2007-01-23 16:00 --- -r121081 fails here too. -- hjl at lucon dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30510
[Bug c++/30558] New: ICE with gcc-4.2 when compiling blitz++-program using exceptions
The following small program gives an segmentation fault when compiled like
this:
extgccsrc> g++ -Wall -fopenmp -O2 -I$POLDEST/ext/include -L$POLDEST/ext/lib
-otest test.cc -lblitz -lgomp -lm
test2.cc: In function int main():
test2.cc:7: internal compiler error: Segmentation fault
When removing the 'try-catch'-part it works fine.
#include
#include
int main()
{
try
{
blitz::Array,3> gradients(100,1,1);
gradients = blitz::TinyVector(0,0,0);
#pragma omp parallel for
for( int lev = 0; lev < 100; ++lev)
{
blitz::TinyVector pos( lev,1,1);
blitz::TinyVector normGradForward =
gradients(pos);
blitz::TinyVector normGradLeft =
blitz::cross( normGradForward, normGradForward);
}
}
catch( std::exception& err)
{
std::cerr << err.what() << std::endl
<< "try -h for help\n";
}
return 0;
}
Here my specs:
extgccsrc> gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: [...]/extgccsrc/gcc-4.2-20070117/configure
--enable-languages=c,c++ --prefix=[...]/extgcc-x86_64_gcc4 --enable-shared
--with-system-zlib --enable-threads=posix --enable-nls --enable-__cxa_atexit
--without-included-gettext --enable-clocale=gnu --enable-libstdcxx-debug
--enable-debug --with-mpfr=[...]/extgcc-x86_64_gcc4
--with-gmp=[...]/extgcc-x86_64_gcc4 --enable-checking=release
--disable-multilib --disable-werror --enable-bootstrap
Thread model: posix
gcc version 4.2.0 20070117 (prerelease)
--
Summary: ICE with gcc-4.2 when compiling blitz++-program using
exceptions
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: supermar at gmx dot de
GCC host triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30558
[Bug c++/28236] wrong "control reaches" warning with enums.
--- Comment #8 from manu at gcc dot gnu dot org 2007-01-23 15:57 --- (In reply to comment #7) > > * PR 12242 > * PR 27975 > * PR 12242 This should have been: * PR 12242 * PR 27975 * PR 30357 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28236
[Bug c++/28236] wrong "control reaches" warning with enums.
--- Comment #7 from manu at gcc dot gnu dot org 2007-01-23 15:55 ---
(In reply to comment #6)
>
> an assignment of int to enum produces an error,
> so how ( in defined non-hax0r way ) enum can be any integer?
> if it can be, then what's difference between enum and int?
Undefined behaviour exists. It can happen. It will happen. Is casting a "hax0r
way"?
[EMAIL PROTECTED]:~$ cat test.cc
#include
typedef enum { foo, bar } e;
int zoo( e __e )
{
switch ( __e )
{
case foo: return -1;
case bar: return +1;
}
}
int main()
{
printf("%d\n", zoo((e)10));
return 0;
}
[EMAIL PROTECTED]:~$ g++ -pedantic test.cc -o test
[EMAIL PROTECTED]:~$ ./test
-1209364588
We have requests for warnings about out-of-range enum conversions in C++:
* PR 12242
* PR 27975
* PR 12242
Again, I am just trying to understand the issue here. You will get a more
expert opinion about the standard and whether this is an actual bug or you
should have a default: case in your switch statements in the gcc@gcc.gnu.org
mailing list.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28236
[Bug bootstrap/30510] [4.3 Regression] Gcc failed to bootstrap
--- Comment #8 from pinskia at physics dot uc dot edu 2007-01-23 15:50 --- Subject: Re: [4.3 Regression] Gcc failed to bootstrap > > > > --- Comment #7 from mueller at gcc dot gnu dot org 2007-01-23 15:47 > --- > which revision is that? -r121081 fails here revision 121050, and 121076. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30510
