[Bug fortran/18850] padding within a sequence type
--- Additional Comments From Thomas dot Koenig at online dot de 2004-12-06 08:37 --- (In reply to comment #1) Alternatively, do other compilers omit padding in sequence types? ifort does so, unless the '-pad' option is given: http://www.intel.com/software/products/compilers/flin/docs/for_ug2/cmp_algn.htm So does Compaq fortran, unless you specify /align:sequence : http://h18009.www1.hp.com/fortran/docs/vf-html/pg/pgualopt.htm xlf also does it, but marks it as an extension: http://www-1.ibm.com/support/docview.wss?uid=swg27003923aid=1 , page 454: # The size of a sequence derived type is equal to the number of bytes # of storage needed to hold all of the components of that derived type. The point seems somewhat to be in contention as far as a standards requirement is concerned: http://j3-fortran.org/doc/meeting/150/99-190.txt I've changed the bug type to enhancement with this. -- What|Removed |Added Severity|normal |enhancement Status|WAITING |NEW Ever Confirmed||1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18850
complex numbers
Hello
I have found a bug in the implementation of the complex library of
g++ and the complex.h library of the gcc (c99 support).
The simplest program that demonstrates the bug is:
#includeiostream
#includecomplex
using namespace std;
int main() {
complexdouble a = 1.0/0.0; // + infinity
complexdouble b = 1.0;
complexdouble c = b/a; // should be 0 but is (NaN,NaN)
cout a endl;
cout b endl;
cout c endl;
}
Since all values are real one should expect the result 0
(the IEEE floating-point value for 1/infinity). More serious is that
if a contains a large but representable value for which |a|^2 is not
representable the implementation will yields bad results. For example
let a be the largest representable number and b be a/2 then b/a should
be 0.5 and not NaN.
The bug comes from the naive implementation
a + b Iac + bd bc - ad
--- = --- + --- I
c + d Ic^2+d^2 c^2+d^2
We get unnecessary overflow errors if c^2+d^2 is too large.
For a better result one should use the following formula due to Smith
(see What Every Computer Scientist Should Know About Floating-Point
Arithmetic http://cch.loria.fr/documentation/IEEE754/)
| a + b(d/c) c - a(d/c)
| -- + -- I if |d| |c|
a + b I| c + d(d/c) a + d(d/c)
--- = |
c + d I| b + a(c/d) -a+ b(c/d)
| -- + -- I if |d| = |c|
| d + c(c/d) d + c(c/d)
Even better we should test for |d| = |c| and definie
a + b I a + b s c - a s
--- =--- + --- if |d| = |c|
c + d I c + d s d + c s
where s = 1 if c and d have the same sign bit and s = -1
otherwise. (Especially if c = +0.0 and d = -0.0 we must set s = -1.)
This improves the results if |c|=|d|=0 or |c|=|d|=infinity.
So my suggestion is to add template specialization for the
operator/= for the types complexfloat complexdouble and
complexlong double that use Smith formula. (For integer types I
think we should stay with the old implementation.)
I would volunteer to fix the c++ library.
But I have less experience in C99 so it would be better if another can
fix the c library. I guess that the same bug will be present in the
libraries of the other languages (Fortan, etc.), but I have not tested it.
I am sorry but I have difficulties with the bug database, so I send
you the mail directly.
With best regards
Andreas Klein
Institute for Mathematics and Computer Science
[EMAIL PROTECTED]
University of Kassel
Germany
[Bug bootstrap/18853] New: Bootstrap Problem
I compiled the actual snapshot 20041205 with gcc from last week using ../gcc40/configure --prefix=/usr/local/gcc40c --program-suffix=40c --with- arch=opteron --enable-languages=c,c++ --enable-checking and CFLAGS=-pipe -g -O3 -march=opteron -fmessage-length=0 -falign-loops=16 -falign-jumps=16 -falign-functions=32 -fstrict-aliasing -fsched-interblock -ffast-math -funroll-all-loops -funit-at-a-time -fpeel-loops -ftracer -funswitch-loops -loop-optimize2 -fmove-loop-invariants -fgcse-after-reload -frename-registers -modulo-sched --param max-gcse-passes=5 --param max-unrolled-insns=600 --param inline-unit-growth=300 --param large-function-growth=400 I got an segfault on my opteron system and an ICE on a ppc system. On both system I did a full boostrap using CFLAGS=-pipe -g -O2 -march=opteron -fmessage-length=0 CFLAGS_FOR_BUILD=full options On both system this bootstrap completed. I installed the compiler, cleared the object dir and did a configure / make with CFLAGS=full options. On both systems I got ICEs as shown below. Michael Cieslinski gcc40 -c -pipe -g -O3 -march=opteron -fmessage-length=0 -falign-loops=16 - falign-jumps=16 -falign-functions=32 -fstrict-aliasing -fsched-interblock - ffast-math -funroll-all-loops -funit-at-a-time -fpeel-loops -ftracer - funswitch-loops -floop-optimize2 -fmove-loop-invariants -fgcse-after-reload - frename-registers -fmodulo-sched --param max-gcse-passes=5 --param max- unrolled-insns=600 --param inline-unit-growth=300 --param large-function- growth=400 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing- prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style- definition -fno-common -DHAVE_CONFIG_H-I. -I. -I../../gcc40/gcc - I../../gcc40/gcc/. -I../../gcc40/gcc/../include - I../../gcc40/gcc/../libcpp/include ../../gcc40/gcc/jump.c -o jump.o ../../gcc40/gcc/jump.c: In function 'reversed_comparison_code_parts': ../../gcc40/gcc/jump.c:440: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. gcc40c -c -pipe -g -O3 -mcpu=G5 -maltivec -mabi=altivec -fmessage-length=0 - falign-loops=16 -falign-jumps=16 -falign-functions=32 -fstrict-aliasing -fsched- interblock -ffast-math -funroll-all-loops -funit-at-a-time -fpeel-loops - ftracer -funswitch-loops -floop-optimize2 -fmove-loop-invariants -fgcse-after- reload -frename-registers -fmodulo-sched --param max-gcse-passes=5 --param max- unrolled-insns=600 --param inline-unit-growth=300 --param large-function- growth=400 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing- prototypes -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE-I. -Ibuild - I../../gcc40/gcc -I../../gcc40/gcc/build -I../../gcc40/gcc/../include - I../../gcc40/gcc/../libcpp/include \ -o build/genautomata.o ../../gcc40/gcc/genautomata.c ../../gcc40/gcc/genautomata.c: In function 'transform_3': ../../gcc40/gcc/genautomata.c:5238: error: verify_flow_info: Incorrect fallthru 140-141 ../../gcc40/gcc/genautomata.c:5238: error: wrong insn in the fallthru edge (barrier 1554 1532 1534) ../../gcc40/gcc/genautomata.c:5238: internal compiler error: in rtl_verify_flow_info, at cfgrtl.c:2198 Please submit a full bug report, with preprocessed source if appropriate. -- Summary: Bootstrap Problem Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: micis at gmx dot de CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: x86_64-redhat-linux GCC host triplet: x86_64-redhat-linux GCC target triplet: x86_64-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18853
[Bug bootstrap/18853] Bootstrap Problem
--- Additional Comments From giovannibajo at libero dot it 2004-12-06 09:40 --- Please, generate the preprocessed sources for the failing files by adding -- save-temps to the command line. Attach the .i files to this bug report. Also, verify that you can reproduce the error by compiling the .i files using the correctly bootstraped GCC40, invoked with the full option set. -- What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18853
[Bug tree-optimization/18704] [4.0 Regression] Inlining limits cause 340% performance regression
--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de 2004-12-06 09:53 --- Subject: Re: [4.0 Regression] Inlining limits cause 340% performance regression On 6 Dec 2004, pinskia at gcc dot gnu dot org wrote: No reason to keep this one open, there is PR 17863 still. Also note I heard from Honza that the tree profiling branch with feedback can optimizate better than with your leafy patch. Wow, that would be cool. Does the tree-profiling branch contain the cfg inliner? I'll try it asap. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18704
[Bug regression/18776] [4.0 Regression] Libgfortran doesn't build again
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-12-06 09:55 --- So is this another problem with RTH's complex patches? Yes, and fixing it the straightforward way leads to more failures with complex integers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18776
[Bug c++/18100] [3.4/4.0 regression] template member with same name as class not rejected
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2004-12-06 10:25 --- Patch for 4.0 submitted: http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00388.html Patch for 3.4 in progress. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18100
[Bug middle-end/18590] [3.3/3.4 regression] ICE in add_insn_before, at emit-rtl.c:3599
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-06 11:19 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00383.html. -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18590
[Bug target/18751] [4.0 Regression] ICE in expr.c:5083, profiledbootstrap
--- Additional Comments From amodra at bigpond dot net dot au 2004-12-06 11:26 --- I think this particular problem was introduced with one of Geoff's patches, http://gcc.gnu.org/ml/gcc-patches/2004-08/msg00022.html rs6000_mode_dependent_address returns true for LO_SUM addresses, which in turn makes them not offsettable. Thus movdi_internal32 won't match DImode gpr stores. It's clear that LO_SUM addresses can't be offset (since an offset may bump the final address over a 64k+32k boundary, and the compiler can't know when this might happen). Also, the rtl generated by -fprofile-generate looks OK. I don't think there's anything wrong with Geoff's patch either, but it's boxed us into a corner. A fix that will work (I think) is to limit legitimate_lo_sum_address_p to 32 bit modes, but that could pessimize all loads and stores of 64 bit values. -- What|Removed |Added CC||geoffk at geoffk dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18751
[Bug c++/18825] [4.0 Regression] ICE segmentation fault in wv2
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2004-12-06 11:45 --- We forget to complete the type. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |lerdsuwa at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18825
Hey, dude, it's me ^_^ :P
Looking forward for a response :P password -- 07072 Potentially Dangerous Attachment Removed. The file Msg.zip has been blocked. File quarantined as: 663d20ae.TextFile.zip.
[Bug target/18341] [4.0 regression] mmix-knuth-mmixware testsuite failure: gcc.dg/builtins-18.c
--- Additional Comments From nickc at redhat dot com 2004-12-06 12:32 --- Fixed by this patch: gcc/testsuite/ChangeLog 2004-12-06 Nick Clifton [EMAIL PROTECTED] by this patch: * gcc.dg/builtins-config.h: Use sys/types.h instead of limits.h because the latter comes from gcc's include/ directory and not the newlib/libc/include directory. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18341
[Bug target/18342] mmix-knuth-mmixware testsuite failure: gcc.dg/builtins-20.c
--- Additional Comments From nickc at redhat dot com 2004-12-06 12:32 --- Fixed by this patch: gcc/testsuite/ChangeLog 2004-12-06 Nick Clifton [EMAIL PROTECTED] * gcc.dg/builtins-config.h: Use sys/types.h instead of limits.h because the latter comes from gcc's include/ directory and not the newlib/libc/include directory. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18342
[Bug tree-optimization/18704] [4.0 Regression] Inlining limits cause 340% performance regression
--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de 2004-12-06 12:33 --- Subject: Re: [4.0 Regression] Inlining limits cause 340% performance regression On 6 Dec 2004, pinskia at gcc dot gnu dot org wrote: No reason to keep this one open, there is PR 17863 still. Also note I heard from Honza that the tree profiling branch with feedback can optimizate better than with your leafy patch. I tried tree-profiling branch and profile-based inlining is actually worse than normal inlining with inline-unit-growth=150. Worse by a factor of four. So, no cigar yet. And btw. profile based inlining seems to be ignorant of inline-unit-growth (at least it doesnt improve for greater values). And generating the profile is _very_ slow (for the tramp3d testcase). Runtime increases about 100 fold - not very good for creating a meaningful profile. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18704
[Bug target/18341] [4.0 regression] mmix-knuth-mmixware testsuite failure: gcc.dg/builtins-18.c
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-06 12:34 --- Close it this time. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18341
[Bug target/18350] mmix-knuth-mmixware testsuite failure: gcc.dg/torture/builtin-convert-1.c (1-3 actually) gcc.dg/torture/builtin-power-1.c
--- Additional Comments From nickc at redhat dot com 2004-12-06 12:35 --- Fixed by this patch: gcc/testsuite/ChangeLog 2004-12-06 Nick Clifton [EMAIL PROTECTED] * gcc.dg/builtins-config.h: Use sys/types.h instead of limits.h because the latter comes from gcc's include/ directory and not the newlib/libc/include directory. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18350
[Bug target/18342] mmix-knuth-mmixware testsuite failure: gcc.dg/builtins-20.c
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-06 12:35 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18342
[Bug tree-optimization/18704] [4.0 Regression] Inlining limits cause 340% performance regression
--- Additional Comments From hubicka at ucw dot cz 2004-12-06 12:44 --- Subject: Re: [4.0 Regression] Inlining limits cause 340% performance regression --- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de 2004-12-06 09:53 --- Subject: Re: [4.0 Regression] Inlining limits cause 340% performance regression On 6 Dec 2004, pinskia at gcc dot gnu dot org wrote: No reason to keep this one open, there is PR 17863 still. Also note I heard from Honza that the tree profiling branch with feedback can optimizate better than with your leafy patch. Wow, that would be cool. Does the tree-profiling branch contain the cfg inliner? I'll try it asap. The cfg inliner per se is not too interesting. What matters here is the code size esitmation and profitability estimation. I am playing with this now and trying to get profile based inlining working. For -n10 and tramp3d.cc I need 2m14s on mainline, 1m31s on the current tree-profiling. With my new implementation I need 0m27s with profile feedback and 2m53s without. I wonder what makes the new heuristics work worse without profiling, but just increasing the inline-unit-growth very slightly (to 155) I get 0m42s. This might be just little unstability in the order of inlining decisions affecting this. I would be curious how those results compare to leafify and whether the 0m27s is not caused by missoptimization. Unless I will observe it otherwise (on SPEC with intermodule), I will apply my current patch and try to improve the profitability analysis without profiling incrementally. Ideally we ought to build estimated profile and use it, but that needs some work so for the moment I guess I will try to experiment with making loop depth available to the cgraph code. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18704 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18704
[Bug tree-optimization/18704] [4.0 Regression] Inlining limits cause 340% performance regression
--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen
dot de 2004-12-06 13:18 ---
Subject: Re: [4.0 Regression] Inlining limits
cause 340% performance regression
On 6 Dec 2004, hubicka at ucw dot cz wrote:
The cfg inliner per se is not too interesting. What matters here is the
code size esitmation and profitability estimation. I am playing with
this now and trying to get profile based inlining working.
Yes, I guess the cfg inliner and some early dead code removal passes
should improve code size metrics for stuff like
template class X
struct Foo
{
enum { val = X::val };
void foo()
{
if (val)
...
else
...
}
};
with val being const.
For -n10 and tramp3d.cc I need 2m14s on mainline, 1m31s on the current
tree-profiling. With my new implementation I need 0m27s with profile
feedback and 2m53s without. I wonder what makes the new heuristics work
worse without profiling, but just increasing the inline-unit-growth very
slightly (to 155) I get 0m42s. This might be just little unstability in
Note that inline-unit-growth is 50 by default, so 155 is not slightly
increased.
the order of inlining decisions affecting this. I would be curious how
those results compare to leafify and whether the 0m27s is not caused by
missoptimization.
You can check for misoptimization by looking at the final output.
I.e. the rh,vx,vy and vz sums should be nearly zero, the T sum
will increase with the number of iterations.
With mainline, -O2 -fpeel-loops -march=pentium4 -ffast-math
-D__NO_MATH_INLINES (we still need explicit -fpeel-loops for
unrolling for (i=0;i3;++i) a[i]=0;), I need 0m17s for -n 10 with
leafification turned on, with it turned off, runtime increases
to 0m31s with --param inline-unit-growth=175.
Unless I will observe it otherwise (on SPEC with intermodule), I will
apply my current patch and try to improve the profitability analysis
without profiling incrementally. Ideally we ought to build estimated
profile and use it, but that needs some work so for the moment I guess I
will try to experiment with making loop depth available to the cgraph
code.
Yes, loops could be auto-leafified, but it will be difficult to
statically check if that is worthwhile.
Richard.
--
Richard Guenther richard dot guenther at uni-tuebingen dot de
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18704
[Bug tree-optimization/18704] [4.0 Regression] Inlining limits cause 340% performance regression
--- Additional Comments From hubicka at ucw dot cz 2004-12-06 13:40 ---
Subject: Re: [4.0 Regression] Inlining limits cause 340% performance regression
--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen
dot de 2004-12-06 13:18 ---
Subject: Re: [4.0 Regression] Inlining limits
cause 340% performance regression
On 6 Dec 2004, hubicka at ucw dot cz wrote:
The cfg inliner per se is not too interesting. What matters here is the
code size esitmation and profitability estimation. I am playing with
this now and trying to get profile based inlining working.
Yes, I guess the cfg inliner and some early dead code removal passes
should improve code size metrics for stuff like
template class X
struct Foo
{
enum { val = X::val };
void foo()
{
if (val)
...
else
...
}
};
with val being const.
For -n10 and tramp3d.cc I need 2m14s on mainline, 1m31s on the current
tree-profiling. With my new implementation I need 0m27s with profile
feedback and 2m53s without. I wonder what makes the new heuristics work
worse without profiling, but just increasing the inline-unit-growth very
slightly (to 155) I get 0m42s. This might be just little unstability in
Note that inline-unit-growth is 50 by default, so 155 is not slightly
increased.
OK, I will play around with 55 then :)
the order of inlining decisions affecting this. I would be curious how
those results compare to leafify and whether the 0m27s is not caused by
missoptimization.
You can check for misoptimization by looking at the final output.
I.e. the rh,vx,vy and vz sums should be nearly zero, the T sum
will increase with the number of iterations.
With mainline, -O2 -fpeel-loops -march=pentium4 -ffast-math
-D__NO_MATH_INLINES (we still need explicit -fpeel-loops for
unrolling for (i=0;i3;++i) a[i]=0;), I need 0m17s for -n 10 with
leafification turned on, with it turned off, runtime increases
to 0m31s with --param inline-unit-growth=175.
I compiled with -O3, would be possible for you to measure how much
speedup you get on mainline with -O3 and -O3+lefify? That would
probably allow me relate those numbers somehow.
Unless I will observe it otherwise (on SPEC with intermodule), I will
apply my current patch and try to improve the profitability analysis
without profiling incrementally. Ideally we ought to build estimated
profile and use it, but that needs some work so for the moment I guess I
will try to experiment with making loop depth available to the cgraph
code.
Yes, loops could be auto-leafified, but it will be difficult to
statically check if that is worthwhile.
I guess just increasing priority for calls inside loops (something like
dividing current cost estimation by loop nest) would do good job for
now, but first I need to convince myself that the new rewrite does
resonable job even for current cost metric before moving on.
Honza
Richard.
--
Richard Guenther richard dot guenther at uni-tuebingen dot de
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18704
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18704
[Bug c/18854] New: Want warning for potential NULL-dereferences
1 #include stdlib.h
2 int main(int argc, char *argv[]) {
3 volatile char *monkey = (char*)malloc(1234);
4 monkey[0] = '\0';
5 return 0;
6 }
Since malloc() on line 3 can return NULL, I'd like a warning on line 4.
Likewise, if -Wnonnull is enabled, passing a potential NULL pointer to a
function marked with the nonnull attribute should give me a warning as well.
IMO, all function returning pointers should be considered to potentially return
NULL, unless the opposite can be proved.
A function attribute saying that some function will never return NULL might be
useful, but I'll leave that up to the potential implementer to implement or not.
As this warning can potentially trigger in a lot of places in otherwise working
code, this warning should be optional and (at least to begin with) default to
off.
--
Summary: Want warning for potential NULL-dereferences
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: walles at mailblocks dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18854
[Bug target/18831] section .stack overlaps section .text
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-06 14:18 --- Not a GCC bug, report this to binutils, http://sources.redhat.com/bugs.html. -- What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18831
[Bug c/18854] Want warning for potential NULL-dereferences
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-06 14:19 --- *** This bug has been marked as a duplicate of 16351 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Keywords||diagnostic Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18854
[Bug c/16351] NULL dereference warnings
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-06 14:19 --- *** Bug 18854 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||walles at mailblocks dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
[Bug target/18350] mmix-knuth-mmixware testsuite failure: gcc.dg/torture/builtin-convert-1.c (1-3 actually) gcc.dg/torture/builtin-power-1.c
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-06 14:20 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18350
[Bug tree-optimization/18704] [4.0 Regression] Inlining limits cause 340% performance regression
--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de 2004-12-06 14:31 --- Subject: Re: [4.0 Regression] Inlining limits cause 340% performance regression On 6 Dec 2004, hubicka at ucw dot cz wrote: the order of inlining decisions affecting this. I would be curious how those results compare to leafify and whether the 0m27s is not caused by missoptimization. You can check for misoptimization by looking at the final output. I.e. the rh,vx,vy and vz sums should be nearly zero, the T sum will increase with the number of iterations. With mainline, -O2 -fpeel-loops -march=pentium4 -ffast-math -D__NO_MATH_INLINES (we still need explicit -fpeel-loops for unrolling for (i=0;i3;++i) a[i]=0;), I need 0m17s for -n 10 with leafification turned on, with it turned off, runtime increases to 0m31s with --param inline-unit-growth=175. I compiled with -O3, would be possible for you to measure how much speedup you get on mainline with -O3 and -O3+lefify? That would probably allow me relate those numbers somehow. 0m23s for -O3+leafify, 1m54s for -O3, 0m35s for -O3 --param inline-unit-growth=150. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18704
[Bug java/14853] [3.3/3.4/4.0 Regression] Assignment to final field permitted when compiling to native
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-06 15:31 --- Subject: Bug 14853 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-06 15:30:57 Modified files: libjava: ChangeLog Added files: libjava/testsuite/libjava.compile: PR14853.java PR14853.xfail Log message: For PR java/14853: * testsuite/libjava.compile/PR14853.java: New file. * testsuite/libjava.compile/PR14853.xfail: New file. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gccr1=1.3259r2=1.3260 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/testsuite/libjava.compile/PR14853.java.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/testsuite/libjava.compile/PR14853.xfail.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14853
[Bug java/14853] [3.3/3.4/4.0 Regression] Assignment to final field permitted when compiling to native
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-06 15:32 --- Subject: Bug 14853 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-06 15:32:38 Modified files: gcc/java : ChangeLog java-tree.h parse.y check-init.c Log message: PR java/14853: * java-tree.h (extract_field_decl): Declare. * parse.y (extract_field_decl): Renamed from strip_out_static_field_access_decl. No longer static. * check-init.c (get_variable_decl): Unwrap COMPOUND_EXPRs. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/ChangeLog.diff?cvsroot=gccr1=1.1516r2=1.1517 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/java-tree.h.diff?cvsroot=gccr1=1.223r2=1.224 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/parse.y.diff?cvsroot=gccr1=1.524r2=1.525 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/check-init.c.diff?cvsroot=gccr1=1.61r2=1.62 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14853
[Bug java/14853] [3.3/3.4/4.0 Regression] Assignment to final field permitted when compiling to native
--- Additional Comments From tromey at gcc dot gnu dot org 2004-12-06 15:33 --- Fix checked in, will appear in gcc 4.0 -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14853
[Bug java/13607] [meta-bug] access problems in java front-end
-- Bug 13607 depends on bug 14853, which changed state. Bug 14853 Summary: [3.3/3.4/4.0 Regression] Assignment to final field permitted when compiling to native http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14853 What|Old Value |New Value Status|NEW |ASSIGNED Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13607
[Bug c++/18855] New: illegal code compiles and segfaults in runtime
The following mistyped illegal code compiles. The resulted executable crashes
because of the accepted illegal pointers.
// ---
struct Base {};
struct Derived : protected Base {
operator const Base* () const {
return *this; // --- Illegal type, should be written without *
}
};
int main()
{
Derived der;
const Base *bp = static_castconst Base*(der);
(void) bp; // --- Avoid warning
return 0;
}
//
Compiled with the command:
g++ -Wall -ansi -pedantic source.cpp
Detailed configuration info is:
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --host=i386-redhat-linux
Thread model: posix
gcc version 3.4.1 20040714 (Red Hat 3.4.1-7)
GNU C++ version 3.4.1 20040714 (Red Hat 3.4.1-7) (i386-redhat-linux)
compiled by GNU C version 3.4.1 20040714 (Red Hat 3.4.1-7).
GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=64160
as -V -Qy -o /tmp/cco9w5Jv.o /tmp/ccCvMY8N.s
--
Summary: illegal code compiles and segfaults in runtime
Product: gcc
Version: 3.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: istvan dot zolyomi at gmail dot com
CC: gcc-bugs at gcc dot gnu dot org,scamel at elte dot hu
GCC build triplet: gcc version 3.4.1 20040714 (Red Hat 3.4.1-7)
GCC host triplet: Linux
GCC target triplet: i386
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18855
[Bug c++/18855] illegal code compiles and segfaults in runtime
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-06
15:56 ---
operator const Base* () const {
return *this; // --- Illegal type, should be written without *
}
This is not invalid code, this becomes an infite loop though because
(Base*)(*this) just calls the same
operator again.
--
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18855
[Bug target/17451] [3.4 Regression] ICE at insn-output.c:1495 with -O1
--- Additional Comments From belyshev at lubercy dot com 2004-12-06 15:58 --- Was fixed by this patch: 2004-10-18 Jakub Jelinek [EMAIL PROTECTED] * config/i386/i386.md (addqi_1_slp): Test for incdec_operand operand 1 instead of 2 -- What|Removed |Added Status|REOPENED|RESOLVED Known to fail|3.4.1 3.4.3 |3.4.1 3.4.2 Known to work|3.3.5 3.4.0 4.0.0 |3.3.5 3.4.0 3.4.3 4.0.0 Resolution||FIXED Target Milestone|3.4.4 |3.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17451
[Bug libstdc++/18837] testsuite_performance.h:63: error: redefinition of 'struct mallinfo'
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-06 16:50 --- Subject: Bug 18837 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2004-12-06 16:50:44 Modified files: libstdc++-v3 : ChangeLog libstdc++-v3/testsuite: testsuite_performance.h Log message: 2004-12-06 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/18837 * testsuite/testsuite_performance.h: Fix mallinfo macros for hpux. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.2224.2.202r2=1.2224.2.203 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/testsuite_performance.h.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.11.4.2r2=1.11.4.3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18837
[Bug libstdc++/18837] testsuite_performance.h:63: error: redefinition of 'struct mallinfo'
-- What|Removed |Added Target Milestone|4.0.0 |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18837
[Bug middle-end/18852] [3.4 Regression] 8 tests fail: SIGSEGV for stack growth failure
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-12-06 16:54 --- Most probably already fixed, but waiting for the confirmation. -- What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18852
[Bug c++/17972] [3.4 Regression] const/pure functions result in bad asm
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-12-06 17:15 --- Alan, unless I'm mistaken, the testcase you filed doesn't fail on x86. Moreover, the assembly code you posted contains an infinite loop that can't reasonably come from the code. -- What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17972
[Bug middle-end/18641] [4.0 Regression] Another ICE caused by reload of a psuedo reg into f0 for a DImode expr
--- Additional Comments From dje at watson dot ibm dot com 2004-12-06 17:16 --- Subject: Re: [4.0 Regression] Another ICE caused by reload of a psuedo reg into f0 for a DImode expr The following patch implements the two suggestions. It fixes the ICE on AIX, but continues to produce an ICE on Mac OS X. Also, the CONST_INT case only should be relevant in 64-bit mode. Index: rs6000.h === RCS file: /cvs/gcc/gcc/gcc/config/rs6000/rs6000.h,v retrieving revision 1.348 diff -c -p -r1.348 rs6000.h *** rs6000.h27 Nov 2004 22:45:24 - 1.348 --- rs6000.h6 Dec 2004 17:14:18 - *** enum reg_class *** 1397,1404 */ #define PREFERRED_RELOAD_CLASS(X,CLASS) \ ! (((GET_CODE (X) == CONST_DOUBLE \ ! GET_MODE_CLASS (GET_MODE (X)) == MODE_FLOAT) \ ? NO_REGS \ : (GET_MODE_CLASS (GET_MODE (X)) == MODE_INT \ (CLASS) == NON_SPECIAL_REGS)\ --- 1397,1404 */ #define PREFERRED_RELOAD_CLASS(X,CLASS) \ ! (((CONSTANT_P (X) \ ! reg_classes_intersect_p ((CLASS), FLOAT_REGS))\ ? NO_REGS \ : (GET_MODE_CLASS (GET_MODE (X)) == MODE_INT \ (CLASS) == NON_SPECIAL_REGS)\ Index: rs6000.md === RCS file: /cvs/gcc/gcc/gcc/config/rs6000/rs6000.md,v retrieving revision 1.336 diff -c -p -r1.336 rs6000.md *** rs6000.md 1 Dec 2004 17:18:38 - 1.336 --- rs6000.md 6 Dec 2004 17:14:18 - *** *** 8496,8502 ; List r-r after r-o, otherwise reload will try to reload a ; non-offsettable address by using r-r which won't make progress. (define_insn *movdi_internal32 ! [(set (match_operand:DI 0 nonimmediate_operand =o,r,r,f,f,m,r) (match_operand:DI 1 input_operand r,r,m,f,m,f,IJKnGHF))] ! TARGET_POWERPC64 (gpc_reg_operand (operands[0], DImode) --- 8496,8502 ; List r-r after r-o, otherwise reload will try to reload a ; non-offsettable address by using r-r which won't make progress. (define_insn *movdi_internal32 ! [(set (match_operand:DI 0 nonimmediate_operand =o,r,r,!*f,!*f,m,r) (match_operand:DI 1 input_operand r,r,m,f,m,f,IJKnGHF))] ! TARGET_POWERPC64 (gpc_reg_operand (operands[0], DImode) *** *** 8567,8573 }) (define_insn *movdi_internal64 ! [(set (match_operand:DI 0 nonimmediate_operand =r,r,m,r,r,r,r,??f,f,m,r,*h,*h) (match_operand:DI 1 input_operand r,m,r,I,L,nF,R,f,m,f,*h,r,0))] TARGET_POWERPC64 (gpc_reg_operand (operands[0], DImode) --- 8567,8573 }) (define_insn *movdi_internal64 ! [(set (match_operand:DI 0 nonimmediate_operand =r,r,m,r,r,r,r,!*f,!*f,m,r,*h,*h) (match_operand:DI 1 input_operand r,m,r,I,L,nF,R,f,m,f,*h,r,0))] TARGET_POWERPC64 (gpc_reg_operand (operands[0], DImode) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18641
[Bug middle-end/18641] [4.0 Regression] Another ICE caused by reload of a psuedo reg into f0 for a DImode expr
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-06 17:29 --- T(In reply to comment #22) Subject: Re: [4.0 Regression] Another ICE caused by reload of a psuedo reg into f0 for a DImode expr The following patch implements the two suggestions. It fixes the ICE on AIX, but continues to produce an ICE on Mac OS X. That is because darwin defines its own PREFERRED_RELOAD_CLASS, why I don't know. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18641
[Bug c++/18829] Error signale on an unexisting line
--- Additional Comments From federicotomassetti at yahoo dot it 2004-12-06 17:50 --- Subject: Re: Error signale on an unexisting line --- pinskia at gcc dot gnu dot org [EMAIL PROTECTED] ha scritto: --- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-06 05:15 --- Also can you read http://gcc.gnu.org/bugs.html and provide the preprocessed source? I'm afraid I can't, I modifie that code and don't have an exact backup... I learned the lesson for the next time... -- What|Removed |Added CC| |pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |WAITING Keywords| |diagnostic http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18829 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. ___ Nuovo Yahoo! Messenger: E' molto più divertente: Audibles, Avatar, Webcam, Giochi, Rubrica… Scaricalo ora! http://it.messenger.yahoo.it -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18829
[Bug middle-end/18852] [3.4 Regression] 8 tests fail: SIGSEGV for stack growth failure
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca 2004-12-06 17:52 --- Subject: Re: [3.4 Regression] 8 tests fail: SIGSEGV for Most probably already fixed, but waiting for the confirmation. -- What|Removed |Added Status|UNCONFIRMED |WAITING It's fixed. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18852
[Bug middle-end/18641] [4.0 Regression] Another ICE caused by reload of a psuedo reg into f0 for a DImode expr
--- Additional Comments From fjahanian at apple dot com 2004-12-06 17:55 --- I applied the patch to fsf-mainline (including darwin.h) and it worked for me. I will do the bootstrap, dejagnu testing and let you know how it went. - Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18641
[Bug java/13607] [meta-bug] access problems in java front-end
-- Bug 13607 depends on bug 14853, which changed state. Bug 14853 Summary: [3.3/3.4 Regression] Assignment to final field permitted when compiling to native http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14853 What|Old Value |New Value Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13607
[Bug java/14853] [3.3/3.4 Regression] Assignment to final field permitted when compiling to native
--- Additional Comments From giovannibajo at libero dot it 2004-12-06 18:31 --- This is a regression on active branches, so the bug should stay open until it's fixed there. Is a backport of your patch feasable for the 3.4 and 3.3 branches? -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | Summary|[3.3/3.4/4.0 Regression]|[3.3/3.4 Regression] |Assignment to final field |Assignment to final field |permitted when compiling to |permitted when compiling to |native |native http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14853
[Bug middle-end/18852] [3.4 Regression] 8 tests fail: SIGSEGV for stack growth failure
--- Additional Comments From giovannibajo at libero dot it 2004-12-06 18:34 --- Fixed -- What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18852
[Bug java/14853] [3.3/3.4 Regression] Assignment to final field permitted when compiling to native
--- Additional Comments From tromey at gcc dot gnu dot org 2004-12-06 18:34 --- The patch should probably apply as-is to 3.4. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14853
[Bug java/14853] [3.3/3.4 Regression] Assignment to final field permitted when compiling to native
--- Additional Comments From giovannibajo at libero dot it 2004-12-06 18:38 --- Will you test it there then? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14853
[Bug target/18665] [3.4/4.0 Regression] -ftrapv borks up simple integer arithmetic
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-12-06 18:45 --- The (useless?) mode promotion from SImode to DImode comes from: http://gcc.gnu.org/ml/gcc-patches/2003-02/msg00625.html -- What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18665
[Bug target/18665] [3.4/4.0 Regression] -ftrapv borks up simple integer arithmetic
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-12-06 18:47 --- Richard, why do we not register optabs for modes smaller than word_mode now? This appears to hurt 64-bit targets. -- What|Removed |Added CC||rth at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18665
[Bug debug/18856] New: Missing .loc information after prologue
The attached program is extracted from the gdb testsuite (gdb.base/annota3.c) According to Dan, the code generated by gcc is missing a .loc directive: http://sources.redhat.com/ml/gdb-patches/2004-12/msg00143.html i.e. gcc generates: .loc 1 6 0 handle_USR1: .PROC .CALLINFO FRAME=64,NO_CALLS,SAVE_SP,ENTRY_GR=3 .ENTRY copy %r3,%r1 .LCFI0: copy %r30,%r3 .LCFI1: stwm %r1,64(%r30) .LCFI2: stw %r26,-36(%r3) ldo 64(%r3),%r30 ldwm -64(%r30),%r3 bv,n %r0(%r2) .EXIT .PROCEND but there should be another .loc 1 6 0 before the ldo insn. gcc-3.4 handles this properly. -- Summary: Missing .loc information after prologue Product: gcc Version: 3.3.5 Status: UNCONFIRMED Severity: normal Priority: P2 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tausq at debian dot org CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: hppa-unknown-linux GCC host triplet: hppa-unknown-linux GCC target triplet: hppa-unknown-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18856
[Bug debug/18856] Missing .loc information after prologue
--- Additional Comments From tausq at debian dot org 2004-12-06 18:50 --- Created an attachment (id=7692) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7692action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18856
[Bug debug/18856] Missing .loc information after prologue
-- What|Removed |Added Known to work||3.4.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18856
[Bug libfortran/18857] New: MATMUL failing with ALLOCATED matrices, unless base indices given
The below fails with CYGWIN_NT_5.1 + Windows XP (SP2) on AMD Athlon XP2600+ (M) assertion a-base == 0 failed: file ../../../gcc-4.0- 20041205/libgfortran/generated/matmul_r8.c, line 157 Aborted (core dumped) This does not happen on my Athlon XP1700 machine, nor on a PIV. I have built the 20041205 cvs and tried various snapshots, all with the same result. !unless matmul line is substituted program test_matmul INTEGER, parameter :: n=2,m=2 real(kind=8), dimension(:,:),allocatable:: unity,x,w allocate(unity(N,N),x(N,M),w(N,M)) unity(:,1)=(/1,0/);x(:,1)=(/1,2/) unity(:,2)=(/0,1/);x(:,2)=(/3,4/) w=matmul(unity,x) !crashes !w(1:,1:)=matmul(unity(1:,1:),x(1:,1:)) !does not print *,all(w.eq.w) deallocate(unity,x,w) end program test_matmul -- Summary: MATMUL failing with ALLOCATED matrices, unless base indices given Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: paulthomas2 at wanadoo dot fr CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18857
PR java/18811 [4.0 Regression] rhug build problem, regression?
Please try this.
Index: gjavah.c
===
RCS file: /cvs/gcc/gcc/gcc/java/gjavah.c,v
retrieving revision 1.124
diff -c -2 -p -r1.124 gjavah.c
*** gjavah.c25 Nov 2004 11:13:37 - 1.124
--- gjavah.c6 Dec 2004 19:15:39 -
*** throwable_p (const unsigned char *clname
*** 1235,1239
int super_length = -1;
const char *classfile_name = find_class ((char *) current, strlen
((const char *) current),
! jcf, 0);
if (! classfile_name)
--- 1235,1239
int super_length = -1;
const char *classfile_name = find_class ((char *) current, strlen
((const char *) current),
! jcf, 0, 0);
if (! classfile_name)
*** main (int argc, char** argv)
*** 2521,2525
if (! output_file)
jcf_dependency_reset ();
! classfile_name = find_class (classname, strlen (classname), jcf, 0);
if (classfile_name == NULL)
{
--- 2521,2525
if (! output_file)
jcf_dependency_reset ();
! classfile_name = find_class (classname, strlen (classname), jcf, 0, 0);
if (classfile_name == NULL)
{
Index: java-tree.h
===
RCS file: /cvs/gcc/gcc/gcc/java/java-tree.h,v
retrieving revision 1.223
diff -c -2 -p -r1.223 java-tree.h
*** java-tree.h 26 Nov 2004 18:04:45 - 1.223
--- java-tree.h 6 Dec 2004 19:15:40 -
*** extern int is_array_type_p (tree);
*** 1248,1251
--- 1248,1252
extern HOST_WIDE_INT java_array_type_length (tree);
extern int read_class (tree);
+ extern int read_class_from_source (tree);
extern void load_class (tree, int);
Index: jcf-dump.c
===
RCS file: /cvs/gcc/gcc/gcc/java/jcf-dump.c,v
retrieving revision 1.64
diff -c -2 -p -r1.64 jcf-dump.c
*** jcf-dump.c 25 Nov 2004 11:13:38 - 1.64
--- jcf-dump.c 6 Dec 2004 19:15:40 -
*** main (int argc, char** argv)
*** 1036,1040
{
char *arg = argv[argi];
! const char *class_filename = find_class (arg, strlen (arg), jcf, 0);
if (class_filename == NULL)
class_filename = find_classfile (arg, jcf, NULL);
--- 1036,1040
{
char *arg = argv[argi];
! const char *class_filename = find_class (arg, strlen (arg), jcf, 0,
0);
if (class_filename == NULL)
class_filename = find_classfile (arg, jcf, NULL);
Index: jcf-io.c
===
RCS file: /cvs/gcc/gcc/gcc/java/jcf-io.c,v
retrieving revision 1.53
diff -c -2 -p -r1.53 jcf-io.c
*** jcf-io.c17 Oct 2004 22:51:35 - 1.53
--- jcf-io.c6 Dec 2004 19:15:40 -
*** static htab_t memoized_class_lookups;
*** 422,430
to it. Returns NULL on failure. If JCF != NULL, it is suitably
initialized. SOURCE_OK is true if we should also look for .java
!file. */
const char *
find_class (const char *classname, int classname_length, JCF *jcf,
! int source_ok)
{
int fd;
--- 422,431
to it. Returns NULL on failure. If JCF != NULL, it is suitably
initialized. SOURCE_OK is true if we should also look for .java
!file. SOURCE_ONLY is true iff we should only look for .java
!files. */
const char *
find_class (const char *classname, int classname_length, JCF *jcf,
! int source_ok, int source_only)
{
int fd;
*** find_class (const char *classname, int c
*** 464,468
{
const char *path_name = jcf_path_name (entry);
! if (class != 0)
{
int dir_len;
--- 465,469
{
const char *path_name = jcf_path_name (entry);
! if (class != 0 ! source_only)
{
int dir_len;
Index: jcf-parse.c
===
RCS file: /cvs/gcc/gcc/gcc/java/jcf-parse.c,v
retrieving revision 1.180
diff -c -2 -p -r1.180 jcf-parse.c
*** jcf-parse.c 28 Nov 2004 06:49:48 - 1.180
--- jcf-parse.c 6 Dec 2004 19:15:41 -
*** static void set_source_filename (JCF *,
*** 107,110
--- 107,111
static void jcf_parse (struct JCF*);
static void load_inner_classes (tree);
+ static int read_class_worker (tree, int);
/* Handle Deprecated attribute. */
*** int
*** 514,517
--- 515,530
read_class (tree name)
{
+ return read_class_worker (name, 0);
+ }
+
+ int
+ read_class_from_source (tree name)
+ {
+ return read_class_worker (name, 1);
+ }
+
+ static int
+ read_class_worker (tree name, int source_only)
+ {
JCF this_jcf, *jcf;
tree icv, class = NULL_TREE;
*** read_class (tree name)
*** 534,538
jcf = this_jcf;
[Bug ada/18858] New: ACATS ICE ce2109b ce2404b ce2410b at -O0: in expand_assignment, at expr.c:3756
On x86 and x86_64 when compiled at -O0 ce2109b ce2404b ce2410b ICE the same way, no ICE and pass on ia64. The tests pass at -O2 on x86 and x86_64. +===GNAT BUG DETECTED==+ | 4.0.0 20041206 (experimental) (i686-pc-linux-gnu) GCC error: | | in expand_assignment, at expr.c:3756 | | Error detected at ce2109b.adb:80:5 | +===GNAT BUG DETECTED==+ | 4.0.0 20041206 (experimental) (i686-pc-linux-gnu) GCC error: | | in expand_assignment, at expr.c:3756 | | Error detected at ce2404b.adb:82:5 | +===GNAT BUG DETECTED==+ | 4.0.0 20041206 (experimental) (i686-pc-linux-gnu) GCC error: | | in expand_assignment, at expr.c:3756 | | Error detected at ce2410b.adb:84:5 | -- Summary: ACATS ICE ce2109b ce2404b ce2410b at -O0: in expand_assignment, at expr.c:3756 Product: gcc Version: 4.0.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P2 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: laurent at guerby dot net CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18858
[Bug driver/18549] -save-temps option ends with corrupt object file
--- Additional Comments From pschober at gmx dot ch 2004-12-06 20:00 --- Output with -v option : Reading specs from C:\Programme\WinAVR\bin\..\lib\gcc-lib\avr\3.3.1\specs Configured with: ../configure --prefix=/e/avrdev/install --target=avr --enable-languages=c,c++ --disable-nls --enable-win32-registry=WinAVR Thread model: single gcc version 3.3.1 C:\Programme\WinAVR\bin\..\lib\gcc-lib\avr\3.3.1\cc1.exe -E -quiet -v -iprefix C:\Programme\WinAVR\bin/../lib/gcc-lib/avr\3.3.1\ -D__GNUC__=3 -D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=1 foo.c -mmcu=atmega16 foo.i ignoring nonexistent directory C:/Programme/WinAVR/avr/sys-include ignoring nonexistent directory /e/avrdev/install/include ignoring nonexistant directory /e/avrdev/install/lib/gcc-lib/acr/3.3.1/include ignoring nonexistant directory /e/avrdev/install/avr/sys-include ignoring nonexistant directory /e/avrdev/install/avr/include #include ... search starts here: #include ... search starts here: C:/Programme/WinAVR/lib/gcc-lib/avr/3.3.1/include C:/Programme/WinAVR/avr/include End of search list. C:\Programme\WinAVR\bin\..\lib\gcc-lib\avr\3.3.1\cc1.exe -fpreprocessed foo.i -quiet -dumpbase foo.c -mmcu=atmega16 -auxbase foo -version -o foo.s GNU C version 3.3.1 (avr) compiled by GNU C version 3.2 (mingw special 20020817-1). GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=131011 C:\Programme\WinAVR\bin\..\lib\gcc-lib\avr\3.3.1\..\..\..\..\avr\bin\as.exe --traditional-format -mmcu=atmega16 -o foo.o C:\DOKUME~1\PS\LOKALE~1\Temp/ccSq.s The only difference is the last line (C:\DOKUME~1\PS\LOKALE~1\Temp/ccSq.s) It changes randomly , e.g. : C:\DOKUME~1\PS\LOKALE~1\Temp/ccaA.s C:\DOKUME~1\PS\LOKALE~1\Temp/ccmC.s . . . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18549
[Bug ada/18859] New: ACATS ICE c37305a at -O0: in tree_low_cst, at tree.c:3839
Happens when using -O0 on x86, x86_64 and ia64 (works at -O2 on the same platforms). +===GNAT BUG DETECTED==+ | 4.0.0 20041206 (experimental) (i686-pc-linux-gnu) GCC error: | | in tree_low_cst, at tree.c:3839 | | Error detected at c37305a.adb:82:5 | -- Summary: ACATS ICE c37305a at -O0: in tree_low_cst, at tree.c:3839 Product: gcc Version: 4.0.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P2 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: laurent at guerby dot net CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18859
[Bug ada/18860] New: ACATS ICE cd30001 at -O0: in expand_expr_addr_expr_1, at expr.c:6229
Happens on x86, x86_64 and ia64 at -O0 (pass at -O2 on all platforms). +===GNAT BUG DETECTED==+ | 4.0.0 20041206 (experimental) (i686-pc-linux-gnu) GCC error: | | in expand_expr_addr_expr_1, at expr.c:6229 | | Error detected at cd30001_0.adb:68:7 | -- Summary: ACATS ICE cd30001 at -O0: in expand_expr_addr_expr_1, at expr.c:6229 Product: gcc Version: 4.0.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P2 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: laurent at guerby dot net CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18860
[Bug target/18847] ACATS ICE cxa5012 on ia64: insn does not satisfy its constraints reload_cse_simplify_operands, at postreload.c:391
--- Additional Comments From laurent at guerby dot net 2004-12-06 20:06 --- On x86_64 at -O0 this tests SEGV at runtime (but on x86 -O0 it works and on ia64 at -O0 it also works). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18847
[Bug ada/18727] ACATS c43214c fails at runtime
--- Additional Comments From laurent at guerby dot net 2004-12-06 20:09 --- At -O0 the test PASS on x86, x86_64 and ia64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18727
[Bug ada/18663] ACATS ICE cc1221d expected integer_cst, have nop_expr in tree_int_cst_lt, at tree.c:3779
--- Additional Comments From laurent at guerby dot net 2004-12-06 20:10 --- The test PASS at -O0 on x86, x86_64 and ia64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18663
[Bug tree-optimization/18659] [4.0 Regression] ACATS ICE in bug in tree-sra.c:1507 on x86 and ppc-darwin (6 FAIL)
--- Additional Comments From laurent at guerby dot net 2004-12-06 20:12 --- This test PASS at -O0 on x86, x86_64 and ia64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18659
[Bug tree-optimization/18658] [4.0 Regression] ACATS ICE c330001 simplify-rtx.c:3780 (propagating a constant across a VIEW_CONVERT_EXPR)
--- Additional Comments From laurent at guerby dot net 2004-12-06 20:14 --- The test PASS at -O0 on x86, x86_64 and ia64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18658
[Bug tree-optimization/18601] [4.0 Regression] tree cfglceanup is slow
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-06 20:22 --- Subject: Bug 18601 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-06 20:22:02 Modified files: gcc: ChangeLog tree-cfg.c tree-flow.h Log message: PR tree-optimization/18601 * tree-cfg.c (thread_jumps, thread_jumps_from_bb): Removed. (tree_forwarder_block_p): Do not consider blocks that are its own successors forwarders. (cleanup_forwarder_blocks, remove_forwarder_block): New functions. (cleanup_tree_cfg): Use cleanup_forwarder_blocks instead of thread_jumps. * tree-flow.h (bb_ann_d): Remove forwardable. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.6726r2=2.6727 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-cfg.c.diff?cvsroot=gccr1=2.132r2=2.133 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-flow.h.diff?cvsroot=gccr1=2.73r2=2.74 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18601
[Bug tree-optimization/18601] [4.0 Regression] tree cfglceanup is slow
--- Additional Comments From kazu at cs dot umass dot edu 2004-12-06 20:23 --- Just checked in a patch. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18601
[Bug target/18665] [3.4/4.0 Regression] -ftrapv borks up simple integer arithmetic
--- Additional Comments From rth at gcc dot gnu dot org 2004-12-06 20:51 --- Look at the routines we implement in libgcc and ask again. We never did implement sub-word routines. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18665
[Bug debug/18856] [3.3 only] Missing .loc information after prologue
-- What|Removed |Added Keywords||wrong-debug Summary|Missing .loc information|[3.3 only] Missing .loc |after prologue |information after prologue Target Milestone|--- |3.3.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18856
[Bug target/17643] [3.3/3.4/4.0 Regression] ICE in propagate_one_insn, at flow.c:1582
--- Additional Comments From belyshev at lubercy dot com 2004-12-06 20:54 --- Regression from 3.0.4 -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 GCC host triplet|hppa-linux-gnu | Keywords||ice-on-valid-code Known to fail||3.4.2 3.4.4 3.3.4 3.2.3 ||4.0.0 Known to work||3.0.4 Last reconfirmed|-00-00 00:00:00 |2004-12-06 20:54:39 date|| Summary|ICE in propagate_one_insn, |[3.3/3.4/4.0 Regression] ICE |at flow.c:1582 |in propagate_one_insn, at ||flow.c:1582 Target Milestone|--- |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17643
[Bug driver/18549] -save-temps option ends with corrupt object file
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-06 21:28 --- What I was trying to ask for was the output of: avr-gcc -c -mmcu=atmega16 -save-temps foo.c -v avr-gcc -c -mmcu=atmega16 foo.c -v -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18549
[Bug libfortran/18857] MATMUL failing with ALLOCATED matrices, unless base indices given
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-06 21:29 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-12-06 21:29:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18857
[Bug rtl-optimization/17728] [3.4 Regression] ICE in extract_insn, at recog.c:2083, unrecognizable insn
--- Additional Comments From belyshev at lubercy dot com 2004-12-06 21:29
---
/* reduced testcase, use -O0 */
void div (register int *d, int i, int j, short k)
{
d [i] = j / k;
}
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
GCC build triplet|hppa2.0w-hp-hpux11.00 |
GCC host triplet|hppa2.0w-hp-hpux11.00 |
Known to fail||3.4.1 3.4.4
Known to work||3.3.4 4.0.0
Last reconfirmed|-00-00 00:00:00 |2004-12-06 21:29:58
date||
Summary|ICE in extract_insn, at |[3.4 Regression] ICE in
|recog.c:2083, unrecognizable|extract_insn, at
|insn|recog.c:2083, unrecognizable
||insn
Target Milestone|--- |3.4.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17728
[Bug debug/18856] [3.3 only, regression] Missing .loc information after prologue
-- What|Removed |Added Known to work|3.4.2 |3.0.4 3.4.2 Summary|[3.3 only] Missing .loc |[3.3 only, regression] |information after prologue |Missing .loc information ||after prologue http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18856
[Bug target/18766] Inefficient code with -mfpmath=387,sse
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-06 21:34 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-12-06 21:34:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18766
[Bug debug/18856] [3.3 regression] Missing .loc information after prologue
-- What|Removed |Added Summary|[3.3 only, regression] |[3.3 regression] Missing |Missing .loc information|.loc information after |after prologue |prologue http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18856
[Bug driver/18549] -save-temps option ends with corrupt object file
--- Additional Comments From dannysmith at users dot sourceforge dot net 2004-12-06 21:36 --- It looks like you are mingw host. If so, could you try trunk. This looks like dup of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5620 Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18549
[Bug other/5620] [3.3/3.4/4.0 Regression] GCC -save-temps foo.c fails to build foo.o
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-06 21:37 --- *** Bug 18549 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||pschober at gmx dot ch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5620
[Bug driver/18549] -save-temps option ends with corrupt object file
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-06 21:37 --- *** This bug has been marked as a duplicate of 5620 *** -- What|Removed |Added Status|WAITING |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18549
[Bug c++/18829] Error signale on an unexisting line
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-06 21:42 --- So lets close this now, I think there was a bug like this already fixed on the mainline also. -- What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18829
Re: complex numbers
Andreas Klein [EMAIL PROTECTED] writes:
| Hello
|
| I have found a bug in the implementation of the complex library of
| g++ and the complex.h library of the gcc (c99 support).
|
| The simplest program that demonstrates the bug is:
|
|
|
| #includeiostream
| #includecomplex
|
| using namespace std;
|
| int main() {
| complexdouble a = 1.0/0.0; // + infinity
| complexdouble b = 1.0;
| complexdouble c = b/a; // should be 0 but is (NaN,NaN)
|
| cout a endl;
| cout b endl;
| cout c endl;
| }
|
|
|
| Since all values are real one should expect the result 0
| (the IEEE floating-point value for 1/infinity). More serious is that
| if a contains a large but representable value for which |a|^2 is not
| representable the implementation will yields bad results. For example
| let a be the largest representable number and b be a/2 then b/a should
| be 0.5 and not NaN.
|
| The bug comes from the naive implementation
|
| a + b Iac + bd bc - ad
| --- = --- + --- I
| c + d Ic^2+d^2 c^2+d^2
|
| We get unnecessary overflow errors if c^2+d^2 is too large.
|
As a matter of fact, the implementation of complex is criticized,
once in a while, because it does NOT use the grammar school rule you
present above. However, for float, double, long double it specializes
to __complex__ T which is what the compiler uses to implement complex
numbers in C99 and Fortran. So, the problem is a compiler problem not
libstdc++ problem.
[...]
| So my suggestion is to add template specialization for the
| operator/= for the types complexfloat complexdouble and
| complexlong double that use Smith formula. (For integer types I
| think we should stay with the old implementation.)
Did you look at the actual implementation?
-- Gaby
[Bug rtl-optimization/17356] [4.0 Regression] [Ada] [ia64] ACATS c41325a other ICE, also while building libada
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-06 21:57 --- Hmm, looks like something changed recently: http://gcc.gnu.org/ml/gcc-testresults/2004-12/msg00280.html http://gcc.gnu.org/ml/gcc-testresults/2004-12/msg00248.html Or those results compiled at -O0? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17356
[Bug rtl-optimization/17356] [4.0 Regression] [Ada] [ia64] ACATS c41325a other ICE, also while building libada
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-06 21:58 --- Ignore the first link, that was for 3.4.4. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17356
[Bug c++/18249] C++ parser i18n problems
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-12-06 22:04:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18249
[Bug c++/18248] c_parse_error i18n problems
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-12-06 22:04:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18248
[Bug middle-end/18785] [4.0 Regression] isdigit builtin function fails with EBCDIC character sets
--- Additional Comments From kghazi at verizon dot net 2004-12-06 22:06 --- Subject: Re: [4.0 Regression] isdigit builtin function fails with EBCDIC character sets Out of curiousity, do you have any problems with builtin printf's conversion of printf(hello world\n) - puts(hello world) ? That transformation doesn't even use TARGET_NEWLINE, instead checking directly for '\n'. --Kaveh -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18785
[Bug rtl-optimization/17356] [4.0 Regression] [Ada] [ia64] ACATS c41325a other ICE, also while building libada
--- Additional Comments From laurent at guerby dot net 2004-12-06 22:24 --- (In reply to comment #8) Hmm, looks like something changed recently: http://gcc.gnu.org/ml/gcc-testresults/2004-12/msg00248.html Or those results compiled at -O0? Yes the 4.0 run was done at -O0 per my request and Andreas sent me the full ACATS log, I've used it to file some new PRs and add some ia64 information on existing PRs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17356
[Bug ada/18859] ACATS ICE c37305a at -O0: in tree_low_cst, at tree.c:3839
-- What|Removed |Added CC||schwab at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18859
[Bug ada/18860] ACATS ICE cd30001 at -O0: in expand_expr_addr_expr_1, at expr.c:6229
-- What|Removed |Added CC||schwab at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18860
[Bug middle-end/18861] New: [4.0 Regression] ICE Segmentation fault in try_crossjump_to_edge at ../../gcc/gcc/cfgcleanup.c:1637
use '-O2 -finline-functions -ftracer -floop-optimize2' to reproduce:
extern void fancy_abort (void) __attribute__ ((__noreturn__));
int
reverse_condition (int code)
{
switch (code)
{
case 4:
return 3;
case 3:
return 4;
case 6:
return 7;
case 7:
return 8;
case 8:
return 5;
case 5:
return 6;
default:
fancy_abort ();
}
}
int
reversed_comparison_code_parts (int code, int code2)
{
switch (code)
{
case 4:
case 3:
return reverse_condition (code);
}
if (code2 == 1)
return reverse_condition (code);
return 0;
}
backtrace:
Program received signal SIGSEGV, Segmentation fault.
try_crossjump_to_edge (mode=19, e1=0x7, e2=0x40219a08) at
../../gcc/gcc/cfgcleanup.c:1637
1637 s-count += s2-count;
(gdb) bt
#0 try_crossjump_to_edge (mode=19, e1=0x7, e2=0x40219a08) at
../../gcc/gcc/cfgcleanup.c:1637
#1 0x08178cfa in try_crossjump_bb (mode=19, bb=0x4021acb0) at
../../gcc/gcc/cfgcleanup.c:1810
#2 0x08179acc in cleanup_cfg (mode=19) at ../../gcc/gcc/cfgcleanup.c:1997
#3 0x083b8127 in rest_of_handle_flow2 () at ../../gcc/gcc/passes.c:1322
#4 0x083b8b20 in rest_of_compilation () at ../../gcc/gcc/passes.c:1728
#5 0x080c91aa in execute_pass_list (pass=0x852ba80) at
../../gcc/gcc/tree-optimize.c:516
#6 0x080c93f1 in tree_rest_of_compilation (fndecl=0x4020f244)
at ../../gcc/gcc/tree-optimize.c:652
#7 0x080615d1 in c_expand_body (fndecl=0x4020f244) at
../../gcc/gcc/c-decl.c:6387
#8 0x083e1167 in cgraph_expand_function (node=0x4020f4fc) at
../../gcc/gcc/cgraphunit.c:822
#9 0x083e1e8b in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1689
#10 0x0838fa67 in toplev_main (argc=1075931488, argv=0x85d1498) at
../../gcc/gcc/toplev.c:1005
#11 0x080a7bae in main (argc=1075931488, argv=0x40216960) at
../../gcc/gcc/main.c:35
--
Summary: [4.0 Regression] ICE Segmentation fault in
try_crossjump_to_edge at ../../gcc/gcc/cfgcleanup.c:1637
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: belyshev at lubercy dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18861
[Bug bootstrap/18853] Bootstrap Problem
--- Additional Comments From belyshev at lubercy dot com 2004-12-06 22:45 --- testcase reduced from jump.i is now in bug 18861 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18853
[Bug middle-end/18861] [4.0 Regression] ICE Segmentation fault in try_crossjump_to_edge at ../../gcc/gcc/cfgcleanup.c:1637
--- Additional Comments From belyshev at lubercy dot com 2004-12-06 22:58 --- : Search converges between 2004-10-25-161001-trunk (#610) and 2004-10-26-161001-trunk (#611). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18861
[Bug middle-end/18861] [4.0 Regression] ICE Segmentation fault in try_crossjump_to_edge at ../../gcc/gcc/cfgcleanup.c:1637 with two switches (table jumps)
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-06
23:07 ---
: Search converges between 2004-10-26-161001-trunk (#611) and
2004-11-03-014001-trunk
(#612).
Confirmed.
Here is a testcase down to one function:
extern void abort (void) __attribute__ ((__noreturn__));
int reversed_comparison_code_parts (int code, int code2)
{
int D1131;
if (code = 3)
{
switch (code)
{
case 3: return 4;
case 4: return 3;
case 5: return 6;
case 6: return 7;
case 7: return 8;
case 8: return 5;
default : abort ();
}
}
switch (code)
{
case 3: return 4;
case 4: return 3;
case 5: return 6;
case 6: return 7;
case 7: return 8;
case 8: return 5;
default : abort ();
}
}
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |2004-12-06 23:07:59
date||
Summary|[4.0 Regression] ICE|[4.0 Regression] ICE
|Segmentation fault in |Segmentation fault in
|try_crossjump_to_edge at|try_crossjump_to_edge at
|../../gcc/gcc/cfgcleanup.c:1|../../gcc/gcc/cfgcleanup.c:1
|637 |637 with two switches (table
||jumps)
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18861
[Bug c++/17972] [3.4 Regression] const/pure functions result in bad asm
--- Additional Comments From amodra at bigpond dot net dot au 2004-12-06
23:31 ---
I checked again with a current x86 gcc, 3.4.4 20041206, and the problem is still
there. Note that this only happens with cc1plus. As to why we get the
impossible assembly, what happens is that the inline function cti gets
expanded twice, but the first return label is used for both expansions:
cti body
jump ret_label
ret_label
cti body
jump ret_label
A simpler testcase is:
struct thread_info
{
short preempt_count;
} x;
static inline struct thread_info *cti (void) __attribute__ ((const));
static inline struct thread_info *cti (void)
{
return x;
}
void fn (void)
{
++cti()-preempt_count;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17972
[Bug middle-end/18641] [4.0 Regression] Another ICE caused by reload of a psuedo reg into f0 for a DImode expr
--- Additional Comments From fjahanian at apple dot com 2004-12-06 23:32
---
David's patch (including darwin.h patch attached here) successufully
bootstrapped, dejagnu tested
on apple-ppc-darwin. Please apply the patch to mainline.
Index: darwin.h
===
RCS file: /cvs/gcc/gcc/gcc/config/rs6000/darwin.h,v
retrieving revision 1.72
diff -c -p -r1.72 darwin.h
*** darwin.h27 Nov 2004 22:45:22 - 1.72
--- darwin.h6 Dec 2004 17:56:34 -
*** do {
\
*** 344,351
#undef PREFERRED_RELOAD_CLASS
#define PREFERRED_RELOAD_CLASS(X,CLASS) \
! ((GET_CODE (X) == CONST_DOUBLE \
! GET_MODE_CLASS (GET_MODE (X)) == MODE_FLOAT) \
? NO_REGS \
: ((GET_CODE (X) == SYMBOL_REF || GET_CODE (X) == HIGH)\
reg_class_subset_p (BASE_REGS, (CLASS))) \
--- 344,351
#undef PREFERRED_RELOAD_CLASS
#define PREFERRED_RELOAD_CLASS(X,CLASS) \
! ((CONSTANT_P (X)\
!reg_classes_intersect_p ((CLASS), FLOAT_REGS))\
? NO_REGS \
: ((GET_CODE (X) == SYMBOL_REF || GET_CODE (X) == HIGH)\
reg_class_subset_p (BASE_REGS, (CLASS))) \
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18641
[Bug rtl-optimization/17810] [3.4 Regression] internal compiler error: in verify_local_live_at_start for arm-rtems, arm-linux
--- Additional Comments From belyshev at lubercy dot com 2004-12-06 23:53
---
/* slightly reduced testcase, use '-mcpu=arm920 -O3' */
struct sui_event;
typedef struct sui_event
{
unsigned short what;
int abrakadabra [3];
} sui_event_t;
static sui_event_t sui_event_buf;
static sui_event_t sui_global_event_buf;
short draw_request;
int
sui_get_uid_event ()
{
int rc;
if (rc 0)
return rc;
return 0;
}
int
sui_get_event (sui_event_t *event, int k)
{
if (k != 0)
{
*event = sui_event_buf;
sui_event_buf.what = 0;
return 0;
}
if (sui_global_event_buf.what != 0)
{
*event = sui_global_event_buf;
return 0;
}
memset (event, 0, sizeof (sui_event_t));
if (sui_get_uid_event () 0)
return 1;
if (draw_request)
{
draw_request = 0;
return 1;
}
return 0;
}
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
GCC build triplet|i586-pc-linux-gnu |
GCC host triplet|i586-pc-linux-gnu |
Known to fail||3.4.2 3.4.4
Known to work||3.3.4
Last reconfirmed|-00-00 00:00:00 |2004-12-06 23:53:41
date||
Summary|internal compiler error: in |[3.4 Regression] internal
|verify_local_live_at_start |compiler error: in
|for arm-rtems, arm-linux|verify_local_live_at_start
||for arm-rtems, arm-linux
Target Milestone|--- |3.4.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17810
[Bug target/18542] [3.4 only] ICE: output_operand: invalid expression as operand
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Known to fail|3.4.0 3.4.3 |3.4.0 3.4.3 3.4.4 Last reconfirmed|-00-00 00:00:00 |2004-12-07 00:02:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18542
[Bug target/18542] [3.4 regression] ICE: output_operand: invalid expression as operand
--- Additional Comments From belyshev at lubercy dot com 2004-12-07 00:15 --- *** Bug 18563 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18542
[Bug target/18564] ICE: output_operand: invalid expression as operand
--- Additional Comments From belyshev at lubercy dot com 2004-12-07 00:15 --- *** This bug has been marked as a duplicate of 18542 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18564
[Bug target/18563] ICE: output_operand: invalid expression as operand
--- Additional Comments From belyshev at lubercy dot com 2004-12-07 00:15 --- *** This bug has been marked as a duplicate of 18542 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18563
[Bug target/18542] [3.4 regression] ICE: output_operand: invalid expression as operand
--- Additional Comments From belyshev at lubercy dot com 2004-12-07 00:15 --- *** Bug 18564 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18542
[Bug bootstrap/15212] [3.4/4.0 Regression] bootstrap fails on interix3
--- Additional Comments From tfillmore at beatware dot com 2004-12-07 00:29 --- (In reply to comment #14) I'm taking a look at this. Since I don't have interix, I need help from the bug reporter. I've now set up an Interix system for the purpose of providing shell accounts. Anyone who would like access for testing/development of GCC should email me and I'll create an account for them. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15212
