[Bug fortran/23323] New: Internal compiler error with CHARACTER functions and -fdefault-integer-8
When compiling the following subroutine test.F: --- snip SUBROUTINE BUG(ID,PARNAM) IMPLICIT NONE C .. Scalar Arguments .. CHARACTER *8 PARNAM INTEGER ID C .. External Functions .. CHARACTER *8 PANAME EXTERNAL PANAME C PARNAM = PANAME(ID) C RETURN END --- snap using gfortran -v -save-temps -fdefault-integer-8 -c test.F gives an internal compiler error: Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../../gcc-4.0.1/configure --prefix=/tmp2/denk/GCC4.0.1 --exec-p refix=/tmp2/denk/GCC4.0.1/LINUXAMD64 --enable-languages=c,c++,f95,java --with-gm p=/tmp2/denk/GCC4.0.1/LINUXAMD64 --with-mpfr=/tmp2/denk/GCC4.0.1 Thread model: posix gcc version 4.0.1 /share/kruemel/tmp2/denk/GCC4.0.1/LINUXAMD64/bin/../libexec/gcc/x86_64-unknown- linux-gnu/4.0.1/cc1 -E -traditional-cpp -D_LANGUAGE_FORTRAN -quiet -v -iprefix / share/kruemel/tmp2/denk/GCC4.0.1/LINUXAMD64/bin/../lib/gcc/x86_64-unknown-linux- gnu/4.0.1/ test.F -mtune=k8 -fdefault-integer-8 -fpch-preprocess -o test.f cc1: warning: command line option "-fdefault-integer-8" is valid for F95 but not for C ignoring nonexistent directory "/share/kruemel/tmp2/denk/GCC4.0.1/LINUXAMD64/bin /../lib/gcc/x86_64-unknown-linux-gnu/4.0.1/../../../../x86_64-unknown-linux-gnu/ include" ignoring duplicate directory "/tmp2/denk/GCC4.0.1/LINUXAMD64/lib/gcc/x86_64-unkn own-linux-gnu/4.0.1/include" ignoring nonexistent directory "/tmp2/denk/GCC4.0.1/LINUXAMD64/lib/gcc/x86_64-un known-linux-gnu/4.0.1/../../../../x86_64-unknown-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /share/kruemel/tmp2/denk/GCC4.0.1/LINUXAMD64/bin/../lib/gcc/x86_64-unknown-linu x-gnu/4.0.1/include /usr/local/include /tmp2/denk/GCC4.0.1/include /usr/include End of search list. /share/kruemel/tmp2/denk/GCC4.0.1/LINUXAMD64/bin/../libexec/gcc/x86_64-unknown- linux-gnu/4.0.1/f951 test.f -ffixed-form -quiet -dumpbase test.F -mtune=k8 -auxb ase test -version -fdefault-integer-8 -o test.s GNU F95 version 4.0.1 (x86_64-unknown-linux-gnu) compiled by GNU C version 4.0.1. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 test.F: In function 'bug': test.F:1: internal compiler error: in gfc_conv_string_tmp, at fortran/trans-expr .c:782 Removing the option -fdefault-integer-8 gives a sucessful compile. -- Summary: Internal compiler error with CHARACTER functions and - fdefault-integer-8 Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: georg dot denk at infineon dot com CC: gcc-bugs at gcc dot gnu dot org,georg dot denk at infineon dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: Linux kruemel 2.4.21-32.0.1.ELsmp #1 SMP Tue Jun 7 12:33:30 MEST GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23323
[Bug libstdc++/15910] can't compile self defined void distance(std::vector, std::vector)
--- Additional Comments From gdr at integrable-solutions dot net 2005-08-11 06:46 --- Subject: Re: can't compile self defined void distance(std::vector, std::vector) "adah at netstd dot com" <[EMAIL PROTECTED]> writes: | Hi Gaby, | | I have read Sutter's Modest Proposal on fixing ADL that you referred to me. If | you had told me earlier about this instead of bluntly telling me this was not a | GCC bug, It still is NOT a GCC bug, no matter how you put it. GCC correctly implements the standard specifications. Just because you happen not to like the consequences of the rules under some circumstances does not make it a GCC bug. Furthermore, I've suggested from the very outset that you take the issue to the C++ committee -- which if you have done, you would have discovered the many facets of fixes you are discovering now. That was no "bluntly telling" you. It is not a GCC bug, it is a fact. You would have learnt more about the subject when you took it to the apporpriate place, is also a fact. But, you were obsessed by the very idea that it must be a GCC bug, rejecting outright suggestions to take the issue to the appropriate places and only afterward half-admitting that is what you would have done and are putting blame on other people for your irrational refusal to give more thoughts to the issue and move and discuss it in the apporpriate forums. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910
[Bug libstdc++/15910] can't compile self defined void distance(std::vector, std::vector)
--- Additional Comments From gdr at integrable-solutions dot net 2005-08-11 06:31 --- Subject: Re: can't compile self defined void distance(std::vector, std::vector) "adah at netstd dot com" <[EMAIL PROTECTED]> writes: | > Furthermore, and more importantly, GCC bugzilla is the not the place | > to record UNEXPECTED or PROBLEM with the C++ standard. | | Is it a guideline of GCC Bugzilla that a PRoblem owing to the C++ Standard is | never considered a PRoblem at all? Ahem. Can you read? | If it is, please show me where I can read it. I'm very willing to do so if you provide evidence that you can read. | should be output. If this function is in some namespace and the original | function call is not qualified, then an additional warning on argument- | dependent lookup should be emitted. | | Simple rules. I do not think it is magic. Surely, your rules do not require magic. They just appear nonsensical to me. As argument dependent name lookup has become an essential part of C++ libraries, begining the standard one. | No. If I put it simply, then this behaviour violates the rationale of | namespaces. Which rationale? | This is not the behaviour I am currently requesting. I just wanted to told | Wolfgang there is a third way to `fix' the problem which I prefer better than | his suggestions. Essentially, you're here just to argue. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910
[Bug tree-optimization/23119] gcc.dg/vect/vect-105.c scan-tree-dump-times vectorized 1 loops 1 fails
--- Additional Comments From phython at gcc dot gnu dot org 2005-08-11 04:44 --- /home/jim/gcc/gcc/gcc/testsuite/gcc.dg/vect/vect-105.c:38: note: not vectorized: unsupported unaligned load -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-08-11 04:44:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23119
[Bug c++/23225] [4.0/4.1 Regression] tree check: expected class type, have exceptional (error_mark) in build_pointer_type_for_mode, at tree.c:4246
--- Additional Comments From phython at gcc dot gnu dot org 2005-08-11 04:22 --- fixed -- What|Removed |Added Known to fail|4.0.0 4.1.0 |4.0.0 Known to work|3.4.0 |3.4.0 4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23225
[Bug c++/23225] [4.0/4.1 Regression] tree check: expected class type, have exceptional (error_mark) in build_pointer_type_for_mode, at tree.c:4246
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-11 04:22 --- Subject: Bug 23225 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-08-11 04:21:55 Modified files: gcc: ChangeLog tree.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/parse: crash27.C Log message: 2005-08-10 James A. Morrison <[EMAIL PROTECTED]> PR c++/23225 * tree.c (build_pointer_type_for_mode): Robustify. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.9699&r2=2.9700 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree.c.diff?cvsroot=gcc&r1=1.498&r2=1.499 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5904&r2=1.5905 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/parse/crash27.C.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23225
[Bug libstdc++/15910] can't compile self defined void distance(std::vector, std::vector)
--- Additional Comments From adah at netstd dot com 2005-08-11 03:51 --- Hi Gaby, I have read Sutter's Modest Proposal on fixing ADL that you referred to me. If you had told me earlier about this instead of bluntly telling me this was not a GCC bug, I would have much more quickly given up the request to `fix' this behaviour. (Hey, PLEASE do not argue with me on this: it is just an after comment on facts.) Since the future is undecided on how to make the program pass (I believe it *is* the consensus of C++ gurus that the OP's program should compile, though it is undefined and nonportable under the current C++ Standard), it is premature to take measures to `correct' the current behaviour. However, the error message *is* user unfriendly. I suppose no one objects to this. So my request is still that the error message should be improved. Yongwei -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910
[Bug java/23300] DECL_FIELD_OFFSET == 0 versus build_field_ref
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-11 03:37 --- Hmm, I think we are not looking into the class's outer class's supper class but I don't know how to prove this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23300
[Bug java/23300] DECL_FIELD_OFFSET == 0 versus build_field_ref
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-11 03:06 --- (In reply to comment #5) > Huh, read_class is failing for java.util.SynchronizedCollection. Woops I was stupid, that should fail. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23300
[Bug java/23300] DECL_FIELD_OFFSET == 0 versus build_field_ref
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-11 02:59 --- Huh, read_class is failing for java.util.SynchronizedCollection. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23300
[Bug java/23300] DECL_FIELD_OFFSET == 0 versus build_field_ref
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-11 02:39 --- More information, maybe_layout_super_class is returning NULL. the Supper class is SynchronizedCollection. This is for java.util.Collections$SynchronizedSet. Which means we have a couple of issues like this. do_resolve_class in maybe_layout_super_class is returning null. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23300
[Bug tree-optimization/22615] [4.1 Regression] ICE in first_vi_for_offset, at tree-ssa-structalias.c:2858
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-11 02:15 --- first_vi_for_offset Just to get a search off the comments to find this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22615
[Bug java/23300] DECL_FIELD_OFFSET == 0 versus build_field_ref
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-11 02:01 --- This is definetly not a regression. Before 4.0.0, we got: javax/swing/AbstractButton.java: In class `javax.swing.AbstractButton$AccessibleAbstractButton': javax/swing/AbstractButton.java: In method `(javax.swing.AbstractButton)': javax/swing/AbstractButton.java:2011: Internal compiler error in expand_expr, at expr.c:6865 Please submit a full bug report, with preprocessed source if appropriate. See http://www.gnu.org/software/gcc/bugs.html> for instructions. -- What|Removed |Added Known to fail||3.4.0 3.0.4 3.3.3 4.0.0 ||4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23300
[Bug libstdc++/15910] can't compile self defined void distance(std::vector, std::vector)
--- Additional Comments From adah at netstd dot com 2005-08-11 02:01 --- (In reply to comment #76) > Subject: Re: can't compile self defined void distance(std::vector, std::vector) > "adah at netstd dot com" <[EMAIL PROTECTED]> writes: > | Now to your point. Please notice that my current stance is not that > | GCC should fix this `bug'. I have stated it days ago. But the > | user's failure is really UNEXPECTED, and this is a PROBLEM. > Please, do consider that the outcome of this is the specification of > "argument dependent name lookup". It is the same rules that apply > whether the function is called "distance" or "freebies" and the > namespace is called "std" or "foobar". Just saying, "ah, this is std, > therefore the outcome is unexpected" is not sufficient. To > appreciate the issue and argue you NEED to understand the rules. > Furthermore, and more importantly, GCC bugzilla is the not the place > to record UNEXPECTED or PROBLEM with the C++ standard. Is it a guideline of GCC Bugzilla that a PRoblem owing to the C++ Standard is never considered a PRoblem at all? If it is, please show me where I can read it. > | To avoid this problem, a better diagnostic message should be > | emitted. Just try compiling the OP's program to see my point. > Just consider how you would formulate the rules for name lookup to > appreciate the point people are making here. There is no magic. We > don't have the keyword "readmymind". If the instantiation of a function (its body or its return type, arguments, etc.) fails during overload resolution, then the complete name of the function should be output. If this function is in some namespace and the original function call is not qualified, then an additional warning on argument- dependent lookup should be emitted. Simple rules. I do not think it is magic. Just that some contexts need to be remembered. > [...] > | I cannot help wondering why (though this might be better discussed > | on comp.std.c++: I do hope you can discuss there). IMHO, the > | current bahaviour is violating the rationale of the std namespace. > You seem to focuse on namespace std, without understanding that this > issue has nothing particular to do with std. Would have the issue > have been different if the namespace was called std? If you think > yes, then I suggest you give it more thoughts. No. If I put it simply, then this behaviour violates the rationale of namespaces. Please notice that I always consider it a problem in the C++ compiler (nothing to do with one specific namespace) instead of libstdc++. Again I can say yes. This problem is most likely encountered by a user using the std namespace. Logically, `violates the rationale of the std namespace' does not contradict `violates the rationale of namespaces'. However, on this point you are basically right. I should have expressed better. > [...] > | c) Failure to instantiate a template function should automatically remove it > | from the candidates of overload resolution. > If you want to modify standard rules, please, again take it to the > committee in charge of C++. > -- Gaby This is not the behaviour I am currently requesting. I just wanted to told Wolfgang there is a third way to `fix' the problem which I prefer better than his suggestions. Yongwei -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910
[Bug java/23300] DECL_FIELD_OFFSET == 0 versus build_field_ref
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-11 01:58 --- [21:55] < pinskia> tromey: it is hitting class.c:2151 [21:55] < pinskia> which is causing the class not to be layout at all Here is the backtrace: #0 layout_class (this_class=0xb7cda78c) at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/java/ class.c:2151 #1 0x0805646d in safe_layout_class (class=0x0) at parse.y:5637 #2 0x0809047e in maybe_layout_super_class (super_class=0xb7cda78c, this_class=0xb795e398) at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/java/class.c:2068 #3 0x08095f5d in layout_class (this_class=0xb795e398) at /home/peshtigo/pinskia/src/gnu/gcc/src/ gcc/java/class.c:2147 #4 0x080d482e in read_class (name=0xb795d1e0) at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/ java/jcf-parse.c:608 #5 0x080d4c82 in load_class (class_or_name=0xb795d1e0, verbose=1) at /home/peshtigo/pinskia/ src/gnu/gcc/src/gcc/java/jcf-parse.c:682 #6 0x080d5163 in load_inner_classes (cur_class=Variable "cur_class" is not available. ) at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/java/jcf-parse.c:821 #7 0x080d4835 in read_class (name=0xb7952118) at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/ java/jcf-parse.c:609 #8 0x080d4c82 in load_class (class_or_name=0xb7950284, verbose=1) at /home/peshtigo/pinskia/ src/gnu/gcc/src/gcc/java/jcf-parse.c:682 #9 0x080903d0 in maybe_layout_super_class (super_class=0xb7950284, this_class=0xb795033c) at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/java/class.c:2070 #10 0x08095f5d in layout_class (this_class=0xb795033c) at /home/peshtigo/pinskia/src/gnu/gcc/ src/gcc/java/class.c:2147 #11 0x080d482e in read_class (name=0xb794f2a8) at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/ java/jcf-parse.c:608 #12 0x080d4c82 in load_class (class_or_name=0xb794f2a8, verbose=0) at /home/peshtigo/pinskia/ src/gnu/gcc/src/gcc/java/jcf-parse.c:682 #13 0x08068e2f in do_resolve_class (enclosing=Variable "enclosing" is not available. ) at parse.y:6026 #14 0x080691b0 in resolve_class (enclosing=0xb78fe958, class_type=0xb7907a6c, decl=0xb790de88, cl=0xb790de60) at parse.y:5850 #15 0x080695a3 in jdep_resolve_class (dep=0x991b660) at parse.y:5652 #16 0x08069d41 in java_complete_class () at parse.y:5703 #17 0x080d4a6c in read_class (name=0xb790be38) at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/ java/jcf-parse.c:575 #18 0x080d4c82 in load_class (class_or_name=0xb790be38, verbose=0) at /home/peshtigo/pinskia/ src/gnu/gcc/src/gcc/java/jcf-parse.c:682 #19 0x08068e2f in do_resolve_class (enclosing=Variable "enclosing" is not available. ) at parse.y:6026 #20 0x080691b0 in resolve_class (enclosing=0xb7aad6e8, class_type=0xb7ab7f74, decl=0xb7ac2000, cl=0xb7ac1898) at parse.y:5850 #21 0x080695a3 in jdep_resolve_class (dep=0x9915b00) at parse.y:5652 #22 0x08069d41 in java_complete_class () at parse.y:5703 #23 0x080d4a6c in read_class (name=0xb7ab3500) at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/ java/jcf-parse.c:575 #24 0x080d4c82 in load_class (class_or_name=0xb7ab3500, verbose=0) at /home/peshtigo/pinskia/ src/gnu/gcc/src/gcc/java/jcf-parse.c:682 #25 0x08068e2f in do_resolve_class (enclosing=Variable "enclosing" is not available. ) at parse.y:6026 #26 0x080691b0 in resolve_class (enclosing=0xb7d1db60, class_type=0xb7d5e508, decl=0xb7d5f730, cl=0xb7d5f6e0) at parse.y:5850 #27 0x080695a3 in jdep_resolve_class (dep=0x9832060) at parse.y:5652 #28 0x08069d41 in java_complete_class () at parse.y:5703 #29 0x080d4a6c in read_class (name=0xb7d216b8) at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/ java/jcf-parse.c:575 #30 0x080d4c82 in load_class (class_or_name=0xb7d1f228, verbose=0) at /home/peshtigo/pinskia/ src/gnu/gcc/src/gcc/java/jcf-parse.c:682 #31 0x08068780 in do_resolve_class (enclosing=0xb7cb1138, import_type=0x0, class_type=0xb7cd1bdc, decl=0x0, cl=Variable "cl" is not available. ) at parse.y:6030 #32 0x08068642 in do_resolve_class (enclosing=Variable "enclosing" is not available. ) at parse.y:3717 #33 0x080691b0 in resolve_class (enclosing=0xb7cb1138, class_type=0xb7cd1bdc, decl=0xb7cb1138, cl=0xb7cd5f78) at parse.y:5850 #34 0x080695a3 in jdep_resolve_class (dep=0x97faa80) at parse.y:5652 #35 0x08069d41 in java_complete_class () at parse.y:5703 #36 0x080d5d21 in java_parse_file (set_yydebug=0) at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/ java/jcf-parse.c:1280 #37 0x0839cd60 in toplev_main (argc=0, argv=0xbfea4624) at /home/peshtigo/pinskia/src/gnu/gcc/ src/gcc/toplev.c:971 #38 0x003e7ad4 in __libc_start_main () from /lib/tls/libc.so.6 #39 0x08049cd1 in _start () I cannot debug it further as I debugging with an optimized compiled. -- What|Removed |Added Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23300
[Bug target/23322] performance regression, possibly related to caching
--- Additional Comments From danalis at cis dot udel dot edu 2005-08-11 00:58 --- Created an attachment (id=9466) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9466&action=view) Source code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23322
[Bug target/23322] New: performance regression, possibly related to caching
We ran the bench++ suite, mentioned as well in http://gcc.gnu.org/ml/gcc/2005-08/msg00197.html , using -O2 and we noticed one more interesting case. Namely, S05m runs slower (x4) when compiled with g++-4.0.1 than when compiled with either g++-2.95.3, or g++-4.1.0-20050723. This regression does not occur when -O3 is used. Apparently, it is related to the existance of a *dead* cerr, as changing the cerr to printf makes the regression go away, and the assembly shorter. Is this a caching effect? -- Summary: performance regression, possibly related to caching Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danalis at cis dot udel dot edu CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: i686-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23322
[Bug libfortran/23321] New: Direct unformatted read beyond EOF cores
c Summary: Direct unformatted read beyond EOF cores c This program demonstrates a bug in gfortran/libgfortran. c The bug is that a c program dumps core when reading beyond the end of c a access='direct', form='unformatted' file instead c of transfering control to 'err=' label. c Also, returns incorrectly when reading at end of file. c To test cdd if=/dev/zero of=shortfile bs=11811 count=1 c./a.out cBus error (core dumped) cdd if=/dev/zero of=shortfile bs=11812 count=1 c./a.out cshould not get here cbefore 779 inbuf(1)= 32 cSTOP 0 cNote: in the above case, the value of inbuf(1) got set to a space c When compiled with ifort or g77, the correct output is produced c in both cases. c./a.out cat 779, all is good c Problem occurs in cGNU Fortran 95 (GCC 4.0.1) cGNU Fortran 95 (GCC 4.0.2 20050804 (prerelease)) cGNU Fortran 95 (GCC 4.1.0 20050806 (experimental)) c gfortran -v c Using built-in specs. c Target: i686-pc-linux-gnu c Configured with: ../../NetSrc/gcc-4.1-20050806/configure --prefix=/home/bswift/afrl/ builddev/NetInst/gcc-4.1-20050806 --enable-languages=c,f95 --with-gmp=/home/bswift/afrl/ builddev/NetInst/gmp-4.1.4 --with-mpfr=/home/bswift/afrl/builddev/NetInst/mpfr-2.1.2 c Thread model: posix c gcc version 4.1.0 20050806 (experimental) implicit none integernbytes integer inbuflen parameter (inbuflen=32768) integer*1 inbuf(inbuflen) integer k inbuf(1)=5 nbytes=11812 open(35,file='shortfile',access='direct',recl=nbytes,form $ ='unformatted') read(35,rec=2,err=779) (inbuf(k),k=1,nbytes) write(*,*) 'should not get here' write(*,*) 'before 779 inbuf(1)=',inbuf(1) stop 779 write(*,*) 'at 779, all is good' end -- Summary: Direct unformatted read beyond EOF cores Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bsp at kithrup dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23321
[Bug java/19629] simple anonymous constructor bug
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-11 00:02 --- Hmm, it ICEs now on the mainline after the error, I want to say the ICE is regression. -- What|Removed |Added Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19629
[Bug java/2499] Class members should be inherited from implemented interfaces
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-10 23:55 --- And now it just rejects it. -- What|Removed |Added Keywords|ice-on-valid-code | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2499
[Bug java/23300] DECL_FIELD_OFFSET == 0 versus build_field_ref
-- What|Removed |Added OtherBugsDependingO||18131 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23300
[Bug java/23300] DECL_FIELD_OFFSET == 0 versus build_field_ref
--- Additional Comments From tromey at gcc dot gnu dot org 2005-08-10 23:11 --- Here's the failure: /home/tromey/Merge/build/gcc/gcj -B/home/tromey/Merge/build/i686-pc-linux-gnu/libjava/ -B/home/tromey/Merge/build/gcc/ -ffloat-store -fclasspath= -fbootclasspath=/home/tromey/Merge/build/i686-pc-linux-gnu/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -c -MT javax/swing.lo -MD -MP -MF javax/swing.deps @javax/swing.list -fPIC -o javax/.libs/swing.o ../../../gcc/libjava/classpath/javax/swing/JPasswordField.java: In class 'javax.swing.JPasswordField$AccessibleJPasswordField': ../../../gcc/libjava/classpath/javax/swing/JPasswordField.java: In constructor '(javax.swing.JPasswordField)': ../../../gcc/libjava/classpath/javax/swing/JPasswordField.java:61: internal compiler error: Segmentation fault -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23300
[Bug tree-optimization/23320] [4.1 Regression] ICE in in base_addr_differ_p, at tree-data-ref.c:430
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-08-10 22:23 --- Ira, this is because your assert's don't match the conditions that will cause it to return: We early exit if we have if (DR_BASE_OBJECT (dra) && DR_BASE_OBJECT (drb)) The assert a little later however, tests: gcc_assert (!DR_BASE_OBJECT (dra) && !DR_BASE_OBJECT (drb)); I note the comment: /* Compare base objects first if possible. If DR_BASE_OBJECT is NULL, it means that the data-ref is of INDIRECT_REF, and alias analysis will be applied to reveal the dependence. */ You probably then should be testing if (DR_TYPE (dra) == ARRAY_TYPE && DR_TYPE (drb) == ARRAY_TYPE) not base object nullness. -- What|Removed |Added CC||irar at il dot ibm dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23320
[Bug tree-optimization/23320] [4.1 Regression] ICE in in base_addr_differ_p, at tree-data-ref.c:430
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-10
22:10 ---
Here is a slightly smaller testcase:
void euifrac (int *i, short *p, int k)
{
unsigned int ll = 0;
unsigned short xi[9] = {0};
do
{
int i;
unsigned short *x = xi;
for (i = 2; i < 8; i++)
*p++ = *x++;
ll = (ll << 16) | xi[2];
} while ((k -= 16) > 0);
*i = ll;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23320
[Bug tree-optimization/23320] [4.1 Regression] ICE in in base_addr_differ_p, at tree-data-ref.c:430
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-10 22:01 --- Confirmed, a regression from 4.0.0. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Known to fail||4.1.0 Known to work||4.0.0 Last reconfirmed|-00-00 00:00:00 |2005-08-10 22:01:56 date|| Summary|ICE in in |[4.1 Regression] ICE in in |base_addr_differ_p, at tree-|base_addr_differ_p, at tree- |data-ref.c:430 |data-ref.c:430 Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23320
[Bug tree-optimization/23320] New: ICE in in base_addr_differ_p, at tree-data-ref.c:430
This is blocking the GCC in SPEC2000 from building on SUSE's AMD64 test boxes.
===
extern int foo (unsigned short *x);
static int __attribute__((noinline))
foo2 (x, sc)
unsigned short *x;
int sc;
{
return foo (x);
}
void
euifrac (unsigned short *x, unsigned int *i, unsigned short *frac)
{
unsigned int ll;
unsigned short xi[(6 +3)];
int j, k;
foo (xi);
k = (int) xi[1] - ((0x3fff) - 1);
if (k > 32)
{
*i = ~(0L);
foo (xi);
}
else if (k > 16)
{
j = k - ((k >> 4) << 4);
foo2 (xi, j);
ll = xi[2];
k -= j;
do
{
int i;
register unsigned short *p;
register unsigned short *x = xi;
p = x + 2;
x += 2 + 1;
for (i = 2; i < (6 +3) - 1; i++)
*p++ = *x++;
*p = 0;
ll = (ll << 16) | xi[2];
}
while ((k -= 16) > 0);
*i = ll;
}
foo (xi);
foo2 (xi, *frac);
}
===
$ ./cc1 -O3 -ftree-loop-linear t.c
foo2 euifrac
Analyzing compilation unitPerforming intraprocedural optimizations
Assembling functions:
foo2 euifrac
t.c: In function 'euifrac':
t.c:13: internal compiler error: in base_addr_differ_p, at tree-data-ref.c:430
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
$ ./cc1 --version
GNU C version 4.1.0 20050810 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 3.3.4 (pre 3.3.5 20040809).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
$
--
Summary: ICE in in base_addr_differ_p, at tree-data-ref.c:430
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: steven at gcc dot gnu dot org
CC: dberlin at gcc dot gnu dot org,gcc-bugs at gcc dot gnu
dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23320
[Bug ada/23319] [4.1 Regression] Compiler crash with interface as generic formal parameter
-- What|Removed |Added Severity|critical|normal Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23319
[Bug ada/23319] [4.1 Regression] Compiler crash with interface as generic formal parameter
--- Additional Comments From laurent at guerby dot net 2005-08-10 21:22 --- Confirmed on 4.1.0 20050809 (experimental) (i686-pc-linux-gnu). 4.0.x gives an error so I assume ICE on invalid for now. [EMAIL PROTECTED]:~/tmp/b23319> gcc -c -gnat05 test.adb pkg.ads:4:25: expecting generic type definition here [EMAIL PROTECTED]:~/tmp/b23319> gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: /home/guerby/work/gcc/version-4.0/configure --prefix=/home/guerby/work/gcc/install/install-20050810T125640 --enable-languages=ada,c --enable-__cxa_atexit --disable-nls --enable-threads=posix --disable-multilib --enable-checking Thread model: posix gcc version 4.0.2 20050810 (prerelease) -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||ice-on-invalid-code Last reconfirmed|-00-00 00:00:00 |2005-08-10 21:22:41 date|| Summary|Compiler crash with |[4.1 Regression] Compiler |interface as generic formal |crash with interface as |parameter |generic formal parameter http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23319
[Bug ada/23319] Compiler crash with interface as generic formal parameter
--- Additional Comments From kafka dot fr at laposte dot net 2005-08-10 20:57 --- Created an attachment (id=9465) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9465&action=view) Files to trigger the bug (concatenated for use with gnatchop) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23319
[Bug ada/23319] New: Compiler crash with interface as generic formal parameter
Full output from gnatmake : --8<-8<-8<-8<-8<-8<-8<-8<-8<-8<--- [EMAIL PROTECTED](0) test $ gnatmake -gnat05 test gcc -c -gnat05 test.adb +===GNAT BUG DETECTED==+ | 4.1.0 20050806 (experimental) (i686-pc-linux-gnu) Program_Error sem_ch12.adb:2051 explicit raise| | Error detected at pkg.ads:5:7| | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. list may be incomplete compilation abandoned gnatmake: "test.adb" compilation error --8<-8<-8<-8<-8<-8<-8<-8<-8<-8<--- Configure command for gcc : ../gcc-4.1-20050806/configure --prefix=/home/yves/Programs/gcc-bin/ --enable-languages=ada,c,c++ Build command for gcc : make CFLAGS='-O' LIBCFLAGS='-g -O2' LIBCXXFLAGS='-g -O2 -fno-implicit-templates' bootstrap Using gcc 3.3.5 as preinstalled compiler : [EMAIL PROTECTED](0) ~ $ gcc -v Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.5/specs Configured with: ../src/configure -v --enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared --with-system-zlib --enable-nls --without-included-gettext --enable-__cxa_atexit --enable-clocale=gnu --enable-debug --enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc i486-linux Thread model: posix gcc version 3.3.5 (Debian 1:3.3.5-8ubuntu2) Using GNAT 3.15p as pre-installed Ada compiler, as packaged by kubuntu. -- Summary: Compiler crash with interface as generic formal parameter Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: critical Priority: P2 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kafka dot fr at laposte dot net CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: gcc (GCC) 4.1.0 20050806 (experimental) GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23319
[Bug fortran/21594] [4.0 only] FAIL: gfortran.dg/eoshift.f90 -O0 execution test
-- Bug 21594 depends on bug 22143, which changed state. Bug 22143 Summary: missing kinds 1 and 2 for eoshift and cshift http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22143 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21594
[Bug libfortran/22143] missing kinds 1 and 2 for eoshift and cshift
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-08-10 20:32 --- Fixed in mainline and 4.0. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22143
[Bug rtl-optimization/21887] missed optimization with globals (-mdynamic-no-pic)
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-10 20:31 --- Subject: Bug 21887 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-08-10 20:31:30 Modified files: gcc: ChangeLog Log message: forgot to add the PR marker: 2005-08-10 Andrew Pinski <[EMAIL PROTECTED]> PR target/21887 * config/darwin.c (machopic_indirect_data_reference): Use a new register for the high part when generating dynamic-no-pic code. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.9697&r2=2.9698 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21887
[Bug rtl-optimization/21887] missed optimization with globals (-mdynamic-no-pic)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-10 20:31 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21887
[Bug classpath/22580] [4.1 Regression] 'make -j' doesn't affect source->bytecode compilation
--- Additional Comments From cvs-commit at developer dot classpath dot org 2005-08-10 20:27 --- Subject: Bug 22580 CVSROOT:/cvsroot/classpath Module name:classpath Branch: Changes by: Tom Tromey <[EMAIL PROTECTED]> 05/08/10 18:53:25 Modified files: . : ChangeLog lib: Makefile.am Log message: For PR classpath/22580: * lib/Makefile.am (compile-classes): Made conditional on FOUND_GCJ. (JAVAC): Redefined when FOUND_GCJ. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/ChangeLog.diff?tr1=1.4377&tr2=1.4378&r1=text&r2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/lib/Makefile.am.diff?tr1=1.96&tr2=1.97&r1=text&r2=text -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22580
[Bug classpath/23238] split-for-gcj.sh should use CONFIG_SHELL
--- Additional Comments From cvs-commit at developer dot classpath dot org 2005-08-10 20:27 --- Subject: Bug 23238 CVSROOT:/cvsroot/classpath Module name:classpath Branch: Changes by: Tom Tromey <[EMAIL PROTECTED]> 05/08/10 18:40:13 Modified files: . : ChangeLog lib: Makefile.am Log message: * lib/Makefile.am (JAVAC): Use $(SHELL) to invoke split-for-gcj.sh. For PR classpath/23238. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/ChangeLog.diff?tr1=1.4376&tr2=1.4377&r1=text&r2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/lib/Makefile.am.diff?tr1=1.95&tr2=1.96&r1=text&r2=text -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23238
[Bug libfortran/22143] missing kinds 1 and 2 for eoshift and cshift
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-10 20:25 --- Subject: Bug 22143 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-08-10 20:25:02 Modified files: gcc/fortran: ChangeLog gfortran.h resolve.c iresolve.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gfortran.dg: shift-kind.f90 Log message: 2005-08-10 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/22143 gfortran.h: Declare new function gfc_resolve_dim_arg. resolve.c: New function gfc_resolve_dim_arg. iresolve.c (gfc_resolve_all): Use gfc_resolve_dim_arg. (gfc_resolve_any): Likewise. (gfc_resolve_count): Likewise. (gfc_resolve_cshift): Likewise. If the kind of shift is less gfc_default_integer_kind, convert it to default integer type. (gfc_resolve_eoshift): Likewise. (gfc_resolve_maxloc): Use gfc_resolve_dim_arg. (gfc_resolve_maxval): Likewise. (gfc_resolve_minloc): Likewise. (gfc_resolve_minval): Likewise. (gfc_resolve_product): Likewise. (gfc_resolve_spread): Likewise. (gfc_resolve_sum): Likewise. 2005-08-10 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/22143 gfortran.dg/shift-kind.f90: New testcase. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.335.2.103&r2=1.335.2.104 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/gfortran.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.58.2.12&r2=1.58.2.13 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/resolve.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.34.2.13&r2=1.34.2.14 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/iresolve.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.32.2.3&r2=1.32.2.4 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.327&r2=1.5084.2.328 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/shift-kind.f90.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22143
[Bug fortran/23318] program works correctly with -g option but fails with -O option on LINUX
--- Additional Comments From kargl at gcc dot gnu dot org 2005-08-10 20:19 --- I suggest running the code through ftnchek and fixing potential problems. These looks suspicious Warning in module MAIN in file show_bug.f: Variables used before set IDATWR used at line 15 file show_bug.f; never set N1 used at line 18 file show_bug.f; never set Warning: Common block ISUBST Elements used but never set: NSUBST Warning: Common block ADINAI Elements used but never set: TSTART Warning: Subprogram TIMFUN argument data type mismatch at position 2: Dummy arg IPNT in module TIMFUN line 35 file show_bug.f is type intg Actual arg A(N1) in module MAIN line 24 file show_bug.f is type real*8 Warning: Subprogram TIMFUN argument arrayness mismatch at position 1: Dummy arg RGST in module TIMFUN line 35 file show_bug.f is whole array Actual arg A(M5) in module MAIN line 24 file show_bug.f is array element and at position 2: Dummy arg IPNT in module TIMFUN line 35 file show_bug.f is whole array Actual arg A(N1) in module MAIN line 24 file show_bug.f is array element and at position 3: Dummy arg TIMV in module TIMFUN line 35 file show_bug.f is whole array Actual arg A(M2) in module MAIN line 24 file show_bug.f is array element Warning: Subprogram TIMFUN argument usage mismatch at position 1: Dummy arg RGST in module TIMFUN line 35 file show_bug.f is modified Actual arg A(M5) in module MAIN line 24 file show_bug.f may be same as arg 5: A(M4) and at position 2: Dummy arg IPNT in module TIMFUN line 35 file show_bug.f is modified Actual arg A(N1) in module MAIN line 24 file show_bug.f may be same as arg 1: A(M5) and at position 3: Dummy arg TIMV in module TIMFUN line 35 file show_bug.f is modified Actual arg A(M2) in module MAIN line 24 file show_bug.f may be same as arg 2: A(N1) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23318
[Bug libfortran/22143] missing kinds 1 and 2 for eoshift and cshift
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-10 20:16 --- Subject: Bug 22143 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-08-10 20:16:29 Modified files: gcc/fortran: ChangeLog gfortran.h resolve.c iresolve.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gfortran.dg: shift-kind.f90 Log message: 2005-08-10 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/22143 gfortran.h: Declare new function gfc_resolve_dim_arg. resolve.c: New function gfc_resolve_dim_arg. iresolve.c (gfc_resolve_all): Use gfc_resolve_dim_arg. (gfc_resolve_any): Likewise. (gfc_resolve_count): Likewise. (gfc_resolve_cshift): Likewise. If the kind of shift is less gfc_default_integer_kind, convert it to default integer type. (gfc_resolve_eoshift): Likewise. (gfc_resolve_maxloc): Use gfc_resolve_dim_arg. (gfc_resolve_maxval): Likewise. (gfc_resolve_minloc): Likewise. (gfc_resolve_minval): Likewise. (gfc_resolve_product): Likewise. (gfc_resolve_spread): Likewise. (gfc_resolve_sum): Likewise. 2005-08-10 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/22143 gfortran.dg/shift-kind.f90: New testcase. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&r1=1.518&r2=1.519 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/gfortran.h.diff?cvsroot=gcc&r1=1.78&r2=1.79 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/resolve.c.diff?cvsroot=gcc&r1=1.50&r2=1.51 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/iresolve.c.diff?cvsroot=gcc&r1=1.37&r2=1.38 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5903&r2=1.5904 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/shift-kind.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22143
[Bug target/22225] Tru64 UNIX testsuite failure: gcc.dg/vect/pr18536.c: ICE in in alphaev4_insn_pipe
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-08-10 19:44:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
[Bug tree-optimization/15353] [tree-ssa] Merge two "if"s if one subsumes the other.
--- Additional Comments From law at redhat dot com 2005-08-10 18:57 ---
Subject: Re: [tree-ssa] Merge two "if"s if
one subsumes the other.
On Sat, 2005-06-11 at 19:16 +, pinskia at gcc dot gnu dot org wrote:
> --- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-11
> 19:16 ---
> (In reply to comment #3)
> > And it should merge them, too, like for
>
> I better testcase which shows why we don't convert i > j || i == j into i >= j
> which is reduced from Richard's tramp3d:
> int g(void);
> int h(void);
> int f(int *i, int *j)
> {
> while (1)
> {
> if (*i > *j || *i == *j)
> break;
> return g();
> }
> return h();
> }
At first I thought we might be able to do this via VRP. But after more
thought, I don't see this kind of transformation fitting into the VRP
framework.
It wouldn't be terribly hard to write a new optimizer to perform this
transformation, and I would expect it would be pretty efficient. It
would need to run after copy propagation and DCE since useless
copies would easily get in the way of successful optimization.
I'm pretty sure it could be done with a single pass through the IL.
Jeff
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15353
[Bug classpath/22580] [4.1 Regression] 'make -j' doesn't affect source->bytecode compilation
--- Additional Comments From tromey at gcc dot gnu dot org 2005-08-10 18:53 --- I checked in a fix to classpath. I'll pull it into libgcj with the next update. (If it is more urgent I can pull it in separately sooner.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22580
[Bug classpath/22580] [4.1 Regression] 'make -j' doesn't affect source->bytecode compilation
--- Additional Comments From tromey at gcc dot gnu dot org 2005-08-10 18:47 --- I'm handling this. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-07-21 05:03:09 |2005-08-10 18:47:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22580
[Bug target/22225] Tru64 UNIX testsuite failure: gcc.dg/vect/pr18536.c: ICE in in alphaev4_insn_pipe
--- Additional Comments From ro at gcc dot gnu dot org 2005-08-10 18:32 --- There are three additional similar failures now, perhaps Richard could have a look: +FAIL: gcc.dg/vect/vect-reduc-7.c (test for excess errors) +WARNING: gcc.dg/vect/vect-reduc-7.c compilation failed to produce executable Excess errors: /vol/gnu/src/gcc/gcc-dist/gcc/testsuite/gcc.dg/vect/vect-reduc-7.c:40: internal compiler error: in alphaev4_insn_pipe, at config/alpha/alpha.c:8794 +FAIL: gcc.dg/vect/vect-reduc-8.c (test for excess errors) +WARNING: gcc.dg/vect/vect-reduc-8.c compilation failed to produce executable +FAIL: gcc.dg/vect/vect-reduc-9.c (test for excess errors) +WARNING: gcc.dg/vect/vect-reduc-9.c compilation failed to produce executable -- What|Removed |Added CC||rth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
[Bug fortran/23318] New: program works correctly with -g option but fails with -O option on LINUX
This program run Ok on the Macintosh or on LINUX with the -g option, but fails with the -O option on LINUX. dir/junk2> gfortran -w -O -o timefun timefun.f dir/junk2> timefun < timefun.in 1t i m e f u n c t i o n d a t a number of time functions (ntfn) =1 max number of points in time functions (nptm) =2 time function number =1 number of time points =2 time value function 0.00.000E+00 1.00.100E+01 "" error time is larger than in the time function 2 2 1 1 1.00 1.00 STOP 0 dir/junk2> gfortran -w -g -o timefun timefun.f dir/junk2> timefun < timefun.in 1t i m e f u n c t i o n d a t a number of time functions (ntfn) =1 max number of points in time functions (nptm) =2 time function number =1 number of time points =2 time value function 0.00.000E+00 1.00.100E+01 STOP 0 dir/junk2> cat timefun.in 12 12 0.0.1.1. dir/junk2> cat timefun.f program main implicit real*8 (a-h,o-z) save common /sol/ numnp,neq,nwk,nwm,nwc,numest,midest,maxest,nste,ma common/const/ dt,dta,acoef(21),dtod,iope common a(1000) dt=0.1d0 dta=0.1d0 nste=10 itwo=2 read (5,1010) ntfn,nptm if (idatwr.le.1) write (6,2250) ntfn,nptm c if (ntfn.eq.0) go to 15 m2=n1 + ntfn m3=m2 + ntfn*nptm*itwo m4=m3 + ntfn*nptm*itwo m5=m4 + ntfn*nste*itwo m6=m5 + ntfn*itwo - 1 c call timfun (a(m5),a(n1),a(m2),a(m3),a(m4),ntfn,nptm) 15 continue stop 1010 format (16i5) 2250 format (1h1,35ht i m e f u n c t i o n d a t a //4x, 148h number of time functions (ntfn) =,i5//4x, 248h max number of points in time functions (nptm) =,i5) end subroutine timfun (rgst,ipnt,timv,rv,rg,ntfn,nptm) c c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . c . . c . subroutine to calculate time function values at all time points . c . the time function values are stored in rg . c . . c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . c implicit real*8 (a-h,o-z) save c common /isubst/ isub,nsubst,nsub,ntuse,negls,negnls,numnps, 1nodcon,nodret,idofs(6),ndofs,neqs,nwks,maxes, 2mas,nstape,iloa(9),krsizm,neqc common /sol/ numnp,neq,nwk,nwm,nwc,numest,midest,maxest,nste,ma common /var/ ng,modex,iupdt,kstep,itemax,ieqref,ite,kpri, 1 iref,iequit,ipri,kplotn,kplote common/const/ dt,dta,acoef(21),dtod,iope common /adinai/ opvar(7),tstart,irint,istote common /prcon/ idatwr,ipric,npb,idc,ivc,iac,ipc,ipnode(3,15) c dimension rg(ntfn,1),timv(nptm,1),rv(nptm,1),ipnt(1),rgst(1) c c write(6,*)tstart,dt,dta,nptm,ntfn,nste do 100 l=1,ntfn read (5,1000) ll,npts if (ll - l) 80,90,80 80 write (6,2000) stop c 90 if (idatwr.le.1) write (6,2002) l,npts ipnt(ll)=npts read (5,1020) (timv(i,ll),rv(i,ll),i=1,npts) if (idatwr.gt.1) go to 95 write (6,2004) (timv(i,ll),rv(i,ll),i=1,npts) 95 if (npts.le.nptm) go to 100 write (6,2100) l,npts,nptm stop 100 continue c nt=13 if (nsubst.gt.0) nt=15 rewind nt do 200 l=1,ntfn rgst(l)=rv(1,l) npts=ipnt(l) time=tstart + dt timep=tstart + dta i=0 k=1 120 i=i + 1 if (i-npts) 190,130,130 130 write (6,2010) write(6,*)i,npts,ntfn,l,time,timep stop c 190 ddr=rv(i+1,l) - rv(i,l) ddt=timv(i+1,l) - timv(i,l) if (ddt) 110,120,150 110 write (6,2020) stop 150 slope=ddr/ddt 180 if (timv(i+1,l)-time) 120,140,140 140 rg(l,k)=rv(i,l) + slope*(timep-timv(i,l)) timep=time + dta time=time + dt k=k + 1 if (nste-k) 195,180,180 195 write (nt) rgst(l),(rg(l,k),k=1,nste),npts, 1 (rv(j,l),timv(j,l),j=1,npts) 200 continue c return c 1000 format (2i5) 1020 format (8f10.0) 2000 format (43h "" error time functions out of order ) 2002 format (/25h time function number =,i5/ 1 25h number of time points =,i5//4x, 2 25h time value function/) 2004 format (3x,f12.5,2x,e15.7) 2010 format (53h "" error time is larger than in the time function) 2020 format (42h "" error time points are out of order ) 2100 format (///28h *** i n p u t e r r o r -// 130h detected by subroutine timfun/ 230h while reading time functions // 3 5x,23h time function number =,i5/ 4 5x,36h number of points in thi
[Bug middle-end/23312] [4.0/4.1 Regression] ACATS ICE (32) gimplify_one_sizepos, at gimplify.c:4659
--- Additional Comments From laurent at guerby dot net 2005-08-10 17:35 --- On 4.0 x86 and x86_64, we also have the 32 4.1 ICE: a54b02a c32001a c34001a c34001c c34001d c34001f c34011b c35003a c35003b c35502b c35502p c35508a c35508b c35508e c35508g c35508l c35508o c35508p c36104a c37005a c43215a c43215b c433001 c45242b c55b15a c64104k c64105c c95008a c95085k c95086c cc3601a cxacb01 But we have an additional four of the same ICE: c36104b c46041a c46042a c87b14c Total 36 ICE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23312
[Bug target/21824] [meta-bug] bootstrap bugs for *-gnu*
-- Bug 21824 depends on bug 21819, which changed state. Bug 21819 Summary: i*86-*-gnu* not enabled in configure.ac http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21819 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21824
[Bug libffi/21819] i*86-*-gnu* not enabled in configure.ac
--- Additional Comments From tromey at gcc dot gnu dot org 2005-08-10 17:19 --- I checked in the fix. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21819
[Bug libffi/21819] i*86-*-gnu* not enabled in configure.ac
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-10 17:19 --- Subject: Bug 21819 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-08-10 17:19:03 Modified files: libffi : ChangeLog configure configure.ac Log message: 2005-08-10 Alfred M. Szmidt <[EMAIL PROTECTED]> PR libffi/21819: * configure: Rebuilt. * configure.ac: Handle i*86-*-gnu*. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libffi/ChangeLog.diff?cvsroot=gcc&r1=1.246&r2=1.247 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libffi/configure.diff?cvsroot=gcc&r1=1.80&r2=1.81 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libffi/configure.ac.diff?cvsroot=gcc&r1=1.16&r2=1.17 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21819
[Bug libffi/21819] i*86-*-gnu* not enabled in configure.ac
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-10 17:18 --- Subject: Bug 21819 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-08-10 17:18:38 Modified files: libffi : ChangeLog configure configure.ac Log message: 2005-08-10 Alfred M. Szmidt <[EMAIL PROTECTED]> PR libffi/21819: * configure: Rebuilt. * configure.ac: Handle i*86-*-gnu*. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libffi/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.222.2.4&r2=1.222.2.5 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libffi/configure.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.71&r2=1.71.10.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libffi/configure.ac.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.9&r2=1.9.12.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21819
[Bug tree-optimization/22444] [4.1 regression] testsuite failure:23_containers/set/explicit_instantiation/2.cc ICE
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-08-10
16:25 ---
Backtrace of the ICE
#0 internal_error (gmsgid=0x882bbf8 "tree check: %s, have %s in %s, at %s:%d")
at diagnostic.c:534
#1 0x085f4b11 in tree_check_failed (node=0x402892c0,
file=0x87b4728 "../../../src/gcc-unpatched/gcc/tree-into-ssa.c", line=466,
function=0x87b4fcd "is_old_name") at tree.c:5854
#2 0x0825a791 in is_old_name (name=0x402892c0) at tree-into-ssa.c:466
#3 0x0825aba0 in maybe_replace_use (use_p=0x4031c234) at tree-into-ssa.c:1383
#4 0x082560a2 in rewrite_update_stmt (walk_data=0xbfffeb70, bb=0x40285730, si=
{tsi = {ptr = 0x4023c6c0, container = 0x4027cf00}, bb = 0x40285730})
at tree-into-ssa.c:1471
#5 0x08288101 in walk_dominator_tree (walk_data=0xbfffeb70, bb=0x40285730)
at domwalk.c:196
#6 0x0828817c in walk_dominator_tree (walk_data=0xbfffeb70, bb=0x40285690)
at domwalk.c:212
#7 0x0825650c in rewrite_blocks (entry=0x40285690, what=REWRITE_UPDATE,
blocks=0x88f4750) at tree-into-ssa.c:1617
#8 0x08258bbd in update_ssa (update_flags=128) at tree-into-ssa.c:2799
#9 0x0861bb82 in execute_todo (pass=0x8851660, flags=151, use_required=0 '\0')
at passes.c:701
(gdb) print *pass
$1 = {name = 0x87b655c "alias", gate = 0,
execute = 0x8270142 , sub = 0x0, next = 0x8854100,
static_pass_number = 22, tv_id = 33, properties_required = 92,
properties_provided = 604, properties_destroyed = 0, todo_flags_start = 0,
todo_flags_finish = 151, letter = 0 '\0'}
the ICE vanishes if -fdump-tree-original, i.e. dumping before the ICE, and
even if dumping after the ICE with f.i. -fdump-tree-vars. GCAC checking
doesn't complain about anything, so does valgrind.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22444
[Bug tree-optimization/23297] immediate uses hosed after CCP
--- Additional Comments From amacleod at redhat dot com 2005-08-10 15:55
---
A quick glance shows that parse_ssa_operands() does not expect to receive a tree
that looks like:
b.c[d_5].i
get_expr_operands is called on this, and when processing COMPONENT_REF:
ref = okay_component_ref_for_subvars (expr, &offset, &size);
if (ref)
{
subvar_t svars = get_subvars_for_var (ref);
subvar_t sv;
for (sv = svars; sv; sv = sv->next)
{
bool exact;
if (overlap_subvar (offset, size, sv, &exact))
{
int subvar_flags = flags;
if (!exact)
subvar_flags &= ~opf_kill_def;
add_stmt_operand (&sv->var, s_ann, subvar_flags);
}
}
}
else
get_expr_operands (stmt, &TREE_OPERAND (expr, 0),
flags & ~opf_kill_def);
if okay_component_ref_for_subvars() is true (which it is in this case), we never
call get_expr_operands on the rest of the expression, which contains the array
ref. Therefore the operand builder never sees the use of d_5 in the expression,
and chaos breaks out as you have observed.
I dont pay much attention to the semantics of gimple, but either b.c[d_5].i is
not valid gimple, or you have to be prepared to explore the component ref deeper
in get_expr_operands. I would have expected to trip over this earlier if it was
valid, but what do I know :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23297
[Bug libstdc++/23317] operator>>( istream&, int& ) does not work for enum values
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-10 15:37 --- In 3.4 and above, I get: t4.cc:16: error: ambiguous overload for operator>> in Temp >> (int)Val /home/gates/pinskia/linux/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../include/c++/4.1.0/istream: 131: note: candidates are: std::basic_istream<_CharT, _Traits>& std::basic_istream<_CharT, _Traits>:: operator>>(std::basic_istream<_CharT, _Traits>& (*)(std::basic_istream<_CharT, _Traits>&)) [with _CharT = char, _Traits = std::char_traits] /home/gates/pinskia/linux/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../include/c++/4.1.0/istream: 134: note: std::basic_istream<_CharT, _Traits>& std::basic_istream<_CharT, _Traits>:: operator>>(std::basic_ios<_CharT, _Traits>& (*)(std::basic_ios<_CharT, _Traits>&)) [with _CharT = char, _Traits = std::char_traits] /home/gates/pinskia/linux/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../include/c++/4.1.0/istream: 137: note: std::basic_istream<_CharT, _Traits>& std::basic_istream<_CharT, _Traits>:: operator>>(std::ios_base& (*)(std::ios_base&)) [with _CharT = char, _Traits = std::char_traits] /home/gates/pinskia/linux/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../include/c++/4.1.0/istream: 230: note: std::basic_istream<_CharT, _Traits>& std::basic_istream<_CharT, _Traits>:: operator>>(std::basic_streambuf<_CharT, _Traits>*) [with _CharT = char, _Traits = std:: char_traits] I don't think this is valid code. Actually it is not, you are invoking one of the bad extensions in GCC which was removed for 3.4 called the lvalue extension. So this was fixed to reject the code in 3.4.0. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c++ |libstdc++ Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23317
Re: [patch] pr 21302 Max line length in free form mode
On Mon, Aug 08, 2005 at 02:14:42PM -0700, Steve Kargl wrote:
>On Mon, Aug 08, 2005 at 09:23:07AM +0200, Bernhard Fischer wrote:
>> + if (gfc_option.fixed_line_length == 72) /* default */
>> +maxlen = GFC_MAX_LINE;
>Unless I misunderstand the above, the following
>
> gfortran -ffixed_line_length=72 test.f90
>
>will use GFC_MAX_LINE, which is 132 (not the requested
>length of 72).
right. Corrected patch attached.
gcc-line-length.diff:
PR 21302
* gcc/fortran/options.c: initialize fixed_line_length to -1.
* gcc/fortran/scanner.c (load_line): default fixed_line_length
to GFC_MAX_LINE for FORM_FREE else default to 72. If a line
length was given, use it.
Perhaps also check that the line-length given is not too big?
Something like
gcc-line-length-max.diff:
* gcc/fortran/options.c: make sure that -ffixed-line-length
is less than 1048577.
ok?
--
Bernhard
Index: gcc/fortran/options.c
===
RCS file: /cvsroot/gcc/gcc/gcc/fortran/options.c,v
retrieving revision 1.22
diff -u -p -r1.22 options.c
--- gcc/fortran/options.c 25 Jun 2005 00:40:35 - 1.22
+++ gcc/fortran/options.c 10 Aug 2005 13:20:22 -
@@ -45,7 +45,7 @@ gfc_init_options (unsigned int argc ATTR
gfc_option.source = NULL;
gfc_option.module_dir = NULL;
gfc_option.source_form = FORM_UNKNOWN;
- gfc_option.fixed_line_length = 72;
+ gfc_option.fixed_line_length = -1;
gfc_option.max_identifier_length = GFC_MAX_SYMBOL_LEN;
gfc_option.verbose = 0;
Index: gcc/fortran/scanner.c
===
RCS file: /cvsroot/gcc/gcc/gcc/fortran/scanner.c,v
retrieving revision 1.23
diff -u -p -r1.23 scanner.c
--- gcc/fortran/scanner.c 9 Aug 2005 08:08:28 - 1.23
+++ gcc/fortran/scanner.c 10 Aug 2005 13:20:22 -
@@ -690,8 +690,11 @@ load_line (FILE * input, char **pbuf, in
char *buffer;
/* Determine the maximum allowed line length. */
- if (gfc_current_form == FORM_FREE)
-maxlen = GFC_MAX_LINE;
+ if (gfc_option.fixed_line_length == -1)
+if (gfc_current_form == FORM_FREE)
+ maxlen = GFC_MAX_LINE;
+else
+ maxlen = 72; /* GFC_DEFAULT_LINE */
else
maxlen = gfc_option.fixed_line_length;
Index: gcc/fortran/options.c
===
RCS file: /cvsroot/gcc/gcc/gcc/fortran/options.c,v
retrieving revision 1.22
diff -u -p -r1.22 options.c
--- gcc/fortran/options.c 25 Jun 2005 00:40:35 - 1.22
+++ gcc/fortran/options.c 10 Aug 2005 14:51:53 -
@@ -289,6 +289,9 @@ gfc_handle_option (size_t scode, const c
case OPT_ffixed_line_length_:
if (value != 0 && value < 7)
gfc_fatal_error ("Fixed line length must be at least seven.");
+ else
+ if (value > 1048576)
+ gfc_fatal_error ("Fixed line length must be at most 1048576.");
gfc_option.fixed_line_length = value;
break;
[Bug c++/23317] operator>>( istream&, int& ) does not work for enum values
--- Additional Comments From peter at gamelogic dot com 2005-08-10 15:27 --- Created an attachment (id=9463) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9463&action=view) Test case which shows failing and successful examples of this bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23317
[Bug c++/23317] New: operator>>( istream&, int& ) does not work for enum values
Assigning to an enum value from, for example, an istringstream fails, but the failure bit on the istream is not set. Using an int temporary works just fine. The .ii file is attached. The output of g++ -v -save-temps Test.cpp is: Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.5/specs Configured with: ../src/configure -v --enable-languages=c,c++,java,f77,pascal,objc,ada,treelang -- prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/ include/c++/3.3 --enable-shared --enable-__cxa_atexit --with-system-zlib --enable-nls --without- included-gettext --enable-clocale=gnu --enable-debug --enable-java-gc=boehm --enable-java- awt=xlib --enable-objc-gc i486-linux Thread model: posix gcc version 3.3.5 (Debian 1:3.3.5-13) /usr/lib/gcc-lib/i486-linux/3.3.5/cc1plus -E -D__GNUG__=3 -quiet -v -D__GNUC__=3 -D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=5 -D_GNU_SOURCE Test.cpp Test.ii ignoring nonexistent directory "/usr/i486-linux/include" #include "..." search starts here: #include <...> search starts here: /usr/include/c++/3.3 /usr/include/c++/3.3/i486-linux /usr/include/c++/3.3/backward /usr/local/include /usr/lib/gcc-lib/i486-linux/3.3.5/include /usr/include End of search list. /usr/lib/gcc-lib/i486-linux/3.3.5/cc1plus -fpreprocessed Test.ii -quiet -dumpbase Test.cpp -auxbase Test -version -o Test.s GNU C++ version 3.3.5 (Debian 1:3.3.5-13) (i486-linux) compiled by GNU C version 3.3.5 (Debian 1:3.3.5-13). GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=129009 as -V -Qy -o Test.o Test.s GNU assembler version 2.15 (i386-linux) using BFD version 2.15 /usr/lib/gcc-lib/i486-linux/3.3.5/collect2 --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld- linux.so.2 /usr/lib/gcc-lib/i486-linux/3.3.5/../../../crt1.o /usr/lib/gcc-lib/i486-linux/3.3.5/../../../ crti.o /usr/lib/gcc-lib/i486-linux/3.3.5/crtbegin.o -L/usr/lib/gcc-lib/i486-linux/3.3.5 -L/usr/lib/ gcc-lib/i486-linux/3.3.5/../../.. Test.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc-lib/ i486-linux/3.3.5/crtend.o /usr/lib/gcc-lib/i486-linux/3.3.5/../../../crtn.o Release: g++ (GCC) 3.3.5 (Debian 1:3.3.5-13) Environment: (Debian) Linux 2.4.26, i686 pc -- Summary: operator>>( istream&, int& ) does not work for enum values Product: gcc Version: 3.3.5 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: peter at gamelogic dot com CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i486-linux GCC host triplet: i486-linux GCC target triplet: i486-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23317
[Bug c++/23316] Unused copy constructor can't be private
--- Additional Comments From christian dot engstrom at glindra dot se 2005-08-10 14:41 --- Subject: Re: Unused copy constructor can't be private giovannibajo at libero dot it wrote: > Please read: > http://gcc.gnu.org/gcc-3.4/changes.html Quite right. That was indeed a surprising rule. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23316
[Bug c++/23316] Unused copy constructor can't be private
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-10
13:53 ---
Please read: http://gcc.gnu.org/gcc-3.4/changes.html:
When binding an rvalue of class type to a reference, the copy constructor of
the class must be
accessible. For instance, consider the following code:
class A
{
public:
A();
private:
A(const A&); // private copy ctor
};
A makeA(void);
void foo(const A&);
void bar(void)
{
foo(A()); // error, copy ctor is not accessible
foo(makeA()); // error, copy ctor is not accessible
A a1;
foo(a1);// OK, a1 is a lvalue
}
-
This is invalid and is rejected as expected.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23316
[Bug c++/23316] Unused copy constructor can't be private
--- Additional Comments From giovannibajo at libero dot it 2005-08-10 13:52 --- Please read: http://gcc.gnu.org/gcc-3.4/changes.html -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23316
[Bug middle-end/22439] [4.0/4.1 regression] ICE with char VLA and __SIZE_TYPE__ argument (so no cast)
--- Additional Comments From giovannibajo at libero dot it 2005-08-10 13:49 --- No testcase was added, so reopening this until the testcase is committed. -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22439
[Bug c++/23316] New: Unused copy constructor can't be private
The program below compiles and behaves as expected with gcc 3.3.1(*), but not
with 3.4.2. I believe that it is the older version of the compiler that is
right.
gcc 3.4.2 will not compile the program as long as the copy constructor for the
"x" class is private, even though the copy constructor should never be called
(outside function "make_x", which is a friend of "x").
If the copy constructor is made public, the program compiles with gcc 3.4.2 and
gives the same result as it did with gcc 3.3.1.
It appears that the copy constructor is in fact never called at all, not even
inside the function "make_x", but I assume that avoiding the copy constructor
when returning the function value in "make_x" is a legal optimization made by
the compiler.
-
(*) I actually made one further simplification of the example after I tried it
the last time under 3.3.1, and I since I no longer have convenient access to
that version of gcc I have been unable to rerun the test with the old compiler.
But I still belive that the first sentence is a true statement.
The program:
---
#include
class x
{
public:
x() {std::cout << "x() default constructor" << std::endl;}
private:
x(const x& c) {std::cout << "x(x) copy constructor" << std::endl;}
friend const x make_x();
};
const x make_x() {return x();}
inline void func(const x& p) {}
int main (int argc, char* argv[])
{
// The next line compiles with gcc 3.3.1, but not with 3.4.2,
// when x's copy constructor is private.
func(make_x());
return 0;
}
Error message from gcc 3.4.2:
---
e53_gcc.cpp: In function `int main(int, char**)':
e53_gcc.cpp:9: error: `x::x(const x&)' is private
e53_gcc.cpp:21: error: within this context
Version number from gcc 3.4.2:
---
gcc (GCC) 3.4.2 (mingw-special)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Version number from gcc 3.3.1 (the old version that works as expected):
---
gcc (GCC) 3.3.1 (mingw special 20030804-1)
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
--
Summary: Unused copy constructor can't be private
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: christian dot engstrom at glindra dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23316
[Bug tree-optimization/22444] [4.1 regression] testsuite failure:23_containers/set/explicit_instantiation/2.cc ICE
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-08-10 12:58 --- I'm reducing the testcase from 23310 at the moment. Trying to produce both an ice-on-valid and a (smaller) ice-on-invalid (or ice-on-ice, whatever will come out of it ;)). -- What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22444
[Bug testsuite/23239] gcc.dg/tree-prof/val-prof-5.c scan-tree-dump Div.mod by constant b..=997 transformation on insn fails
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-10 12:17 --- (In reply to comment #2) > Isn't this a testsuite issue? Yes, Confirmed. -- What|Removed |Added CC||hubicka at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Component|target |testsuite Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-08-10 12:17:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23239
[Bug tree-optimization/23311] [4.0 regression] GCC produces wrong code
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-10 12:14 --- Lets keep this in waiting until there is a testcase. -- What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23311
[Bug target/23240] gcc.c-torture/execute/pr23135.c execution fails
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-10 12:12 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-08-10 12:12:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23240
[Bug tree-optimization/23311] [4.0 regression] GCC produces wrong code
--- Additional Comments From Tobias dot Kranz at bka dot bund dot de 2005-08-10 12:12 --- The same with the current snapshot! :-( (1) Compiling samba with gcc-4.0-20050804 works, but when i run 'smbd --help' smbd crashes again! When I compile it with gcc-3.4.3 ist works fine. (2) I'm sorry but I don't know how to produce a preprocessed testcase out of the samba sources. But maybe s.o. else -who knows the samba sources well- is able to produce a testcase out of the samba source. The configure-options I used are attached. -- What|Removed |Added Status|WAITING |NEW Ever Confirmed||1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23311
[Bug target/23309] m32r-linux-gcc ICE: in extract_insn, at recog.c
-- What|Removed |Added Component|c |target Keywords||ice-on-valid-code Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23309
[Bug fortran/23308] named common block confused as procedure - runtime segfault
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-10 11:50 --- Confirmed, ICC also does not warn or error out. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-08-10 11:50:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23308
[Bug java/23315] java produces mismatch types in MODIFY_EXPR, down cast
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-10 11:46 --- Forgot to say this is to native from source. t.2.java: In class 't1': t.2.java: In method 't1.gg(t1)': t.2.java:1: error: statement types mismatch t5D.369 = D.410; struct t1D.364 * struct t2D.370 * t.2.java:1: internal compiler error: verify_stmts failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23315
[Bug java/23314] java produces mismatch types in MODIFY_EXPR
--- Additional Comments From aph at gcc dot gnu dot org 2005-08-10 11:43 --- It's okay, your first testcase was adequately reduced. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23314
[Bug other/22368] [meta-bugs] mis-match types in GCC
-- What|Removed |Added BugsThisDependsOn||23315 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22368
[Bug java/23315] New: java produces mismatch types in MODIFY_EXPR, down cast
Testcase:
class t1
{
native t2 getParent();
void gg(t1 t5)
{
t5 = t5.getParent();
}
}
class t2 extends t1 { }
The other testcase reduced from gnu/awt/LightweightRedirector.java.
Again use the first patch in PR 22368.
--
Summary: java produces mismatch types in MODIFY_EXPR, down cast
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: aph at gcc dot gnu dot org,gcc-bugs at gcc dot gnu dot
org,java-prs at gcc dot gnu dot org
OtherBugsDependingO 22368
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23315
[Bug java/23314] java produces mismatch types in MODIFY_EXPR
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-10
11:41 ---
More reduced testcase:
class t1
{
void getParent(){t1 tt = null;}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23314
[Bug libstdc++/15910] can't compile self defined void distance(std::vector, std::vector)
--- Additional Comments From gdr at integrable-solutions dot net 2005-08-10 11:35 --- Subject: Re: can't compile self defined void distance(std::vector, std::vector) "adah at netstd dot com" <[EMAIL PROTECTED]> writes: | Now to your point. Please notice that my current stance is not that | GCC should fix this `bug'. I have stated it days ago. But the | user's failure is really UNEXPECTED, and this is a PROBLEM. Please, do consider that the outcome of this is the specification of "argument dependent name lookup". It is the same rules that apply whether the function is called "distance" or "freebies" and the namespace is called "std" or "foobar". Just saying, "ah, this is std, therefore the outcome is unexpected" is not sufficient. To appreciate the issue and argue you NEED to understand the rules. Furthermore, and more importantly, GCC bugzilla is the not the place to record UNEXPECTED or PROBLEM with the C++ standard. | To avoid this problem, a better diagnostic message should be | emitted. Just try compiling the OP's program to see my point. Just consider how you would formulate the rules for name lookup to appreciate the point people are making here. There is no magic. We don't have the keyword "readmymind". [...] | I cannot help wondering why (though this might be better discussed | on comp.std.c++: I do hope you can discuss there). IMHO, the | current bahaviour is violating the rationale of the std namespace. You seem to focuse on namespace std, without understanding that this issue has nothing particular to do with std. Would have the issue have been different if the namespace was called std? If you think yes, then I suggest you give it more thoughts. [...] | c) Failure to instantiate a template function should automatically remove it | from the candidates of overload resolution. If you want to modify standard rules, please, again take it to the committee in charge of C++. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910
[Bug inline-asm/11807] GCC should error out when clobbering the stack pointer and frame pointer
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-10 11:28 --- (In reply to comment #18) > Small testcase from PR 23313, showing ICE on invalid: the code does not ICE but creates "wrong code" at runtime. -- What|Removed |Added Severity|normal |minor Keywords|ice-on-invalid-code | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11807
[Bug inline-asm/11807] GCC should error out when clobbering the stack pointer and frame pointer
--- Additional Comments From giovannibajo at libero dot it 2005-08-10
11:25 ---
Small testcase from PR 23313, showing ICE on invalid:
-
int main(){
int i;
asm (
"xorl %%ebp, %%ebp\n\t"
"movl %0, %%ebp\n\t"
:: "m" (i)
: "%ebp"
);
return 0;
}
-
This makes this PR a bug, not simply an enhancement.
--
What|Removed |Added
Severity|enhancement |normal
Keywords||ice-on-invalid-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11807
[Bug java/23314] java produces mismatch types in MODIFY_EXPR
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-10 11:22 --- This was reduced from gnu/awt/LightweightRedirector.java -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23314
[Bug other/22368] [meta-bugs] mis-match types in GCC
-- What|Removed |Added BugsThisDependsOn||23314 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22368
[Bug java/23314] New: java produces mismatch types in MODIFY_EXPR
Testcase, compile to native from source:
class t
{
void f(Object[] releaseTargets)
{
releaseTargets[0] = null;
}
}
t.2.java: In method 't.f(java.lang.Object[])':
t.2.java:1: error: statement types mismatch
releaseTargets.0D.397->dataD.387[D.405] = 0B;
struct *
voidD.8 *
t.2.java:1: internal compiler error: verify_stmts failed
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
Again use the first patch in PR 22368.
--
Summary: java produces mismatch types in MODIFY_EXPR
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: aph at gcc dot gnu dot org,gcc-bugs at gcc dot gnu dot
org,java-prs at gcc dot gnu dot org
OtherBugsDependingO 22368
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23314
[Bug c++/23307] [3.4/4.0/4.1 Regression] ICE in cp_parser_template_id, at cp/parser.c:8564 with Boost remote_call_manager
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-10 10:53 --- 4.0.0 ICEs for me so does 3.4.0. 3.3.3 does not. -- What|Removed |Added GCC build triplet|i686-pc-linux-gnu | GCC host triplet|i686-pc-linux-gnu | GCC target triplet|i686-pc-linux-gnu | Known to fail|4.1.0 |4.1.0 3.4.0 4.0.0 Known to work|4.0.2 |3.3.3 Summary|ICE in |[3.4/4.0/4.1 Regression] ICE |cp_parser_template_id, at |in cp_parser_template_id, at |cp/parser.c:8564 with Boost |cp/parser.c:8564 with Boost |remote_call_manager |remote_call_manager Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23307
[Bug inline-asm/11807] GCC should error out when clobbering the stack pointer and frame pointer
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-10 10:47 --- *** Bug 23313 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||michaelni at gmx dot at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11807
[Bug inline-asm/23313] gcc ignores ebp on the clobber list
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-10 10:47 --- This is a dup of bug 11807. at -O1 and above, we get an error: t.c: In function `main': t.c:11: error: bp cannot be used in asm here *** This bug has been marked as a duplicate of 11807 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23313
[Bug inline-asm/11807] GCC should error out when clobbering the stack pointer and frame pointer
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-10 10:46 --- Frame pointer is still not fixed at -O0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11807
[Bug inline-asm/23313] New: gcc ignores ebp on the clobber list
* the code segfaults
* there is no error message, not even a warning
* the docs dont say ebp on the clobber list has undefinied behaviour though you
could argue its common knowledgde that gcc-asm has undefined behavior in general
testcase:
int main(){
int i;
asm (
"xorl %%ebp, %%ebp\n\t"
"movl %0, %%ebp\n\t"
:: "m" (i)
: "%ebp"
);
return 0;
}
--
Summary: gcc ignores ebp on the clobber list
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: michaelni at gmx dot at
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: x86-linux
GCC host triplet: x86-linux
GCC target triplet: x86-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23313
[Bug middle-end/23312] [4.0/4.1 Regression] ACATS ICE (32) gimplify_one_sizepos, at gimplify.c:4659
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-10 10:33 --- I think this was caused by: 2005-08-08 Richard Henderson <[EMAIL PROTECTED]> PR 22439 * gimplify.c (gimplify_one_sizepos): Preserve the original type. Which means it is also on the 4.0 branch too. -- What|Removed |Added CC||rth at gcc dot gnu dot org Component|ada |middle-end Known to fail||4.1.0 Known to work||4.0.0 Summary|[4.1 Regression] ACATS ICE |[4.0/4.1 Regression] ACATS |(32) gimplify_one_sizepos, |ICE (32) |at gimplify.c:4659 |gimplify_one_sizepos, at ||gimplify.c:4659 Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23312
[Bug tree-optimization/22444] [4.1 regression] testsuite failure:23_containers/set/explicit_instantiation/2.cc ICE
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-10 10:30 --- *** Bug 23310 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||bkoz at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22444
[Bug c++/23310] ICE: stl_set.h:318: internal compiler error: Segmentation fault
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-10 10:30 --- *** This bug has been marked as a duplicate of 22444 *** -- What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23310
[Bug ada/23312] [4.1 Regression] ACATS ICE (32) gimplify_one_sizepos, at gimplify.c:4659
--- Additional Comments From laurent at guerby dot net 2005-08-10 10:29 --- cc3601a cxacb01 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23312
[Bug ada/23312] [4.1 Regression] ACATS ICE (32) gimplify_one_sizepos, at gimplify.c:4659
--- Additional Comments From laurent at guerby dot net 2005-08-10 10:29 --- Forgot the list: a54b02a c32001a c34001a c34001c c34001d c34001f c34011b c35003a c35003b c35502b c35502p c35508a c35508b c35508e c35508g c35508l c35508o c35508p c36104b c37005a c43215a c43215b c433001 c45242b c55b15a c64104k c64105c c95008a c95085k c95086c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23312
[Bug ada/23312] New: [4.1 Regression] ACATS ICE (32) gimplify_one_sizepos, at gimplify.c:4659
32 similar ICEs appeared on x86 and x86_64 between: LAST_UPDATED: Sat Aug 6 15:29:38 UTC 2005 LAST_UPDATED: Tue Aug 9 20:10:22 UTC 2005 +===GNAT BUG DETECTED==+ | 4.1.0 20050809 (experimental) (x86_64-unknown-linux-gnu) GCC error: | | tree check: expected integer_type, have enumeral_type in | |gimplify_one_sizepos, at gimplify.c:4659 | ... -- Summary: [4.1 Regression] ACATS ICE (32) gimplify_one_sizepos, at gimplify.c:4659 Product: gcc Version: 4.1.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,pinskia at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23312
[Bug middle-end/23294] fold does not fold a*C+a to a*(C+1) or a*C-a to a*(C-1)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-10 10:26 --- (In reply to comment #3) > I believe we can only do so for -fwrapv (but we don't) or for unsigned (which > we > also don't do). I may look at this somewhen in the future. Why do you believe that with -fno-wrapv, overflow is undefined so anything can happen. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23294
[Bug tree-optimization/23311] [4.0 regression] GCC produces wrong code
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru 2005-08-10 10:07 --- We need at least preprocessed testcase to reproduce wrong-code bug. And please try current snapshot of 4.0 branch, there are some bugs fixed: ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20050804/gcc-4.0-20050804.tar.bz2 -- What|Removed |Added Status|UNCONFIRMED |WAITING Component|c |tree-optimization Keywords||wrong-code Known to fail||4.0.1 Known to work||3.4.3 Summary|GCC produces wrong code |[4.0 regression] GCC ||produces wrong code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23311
[Bug c/23311] New: GCC produces wrong code
When compiling samba-3.0.14a with the attached configure-options, the smbd and winbindd are crashing randomly when started with the '--help'-Option. Sometimes the show the beginning of the help-screen an then they crash with SIGSEGV. The next time there is an infinite loop of the help-screen. It seems to me as if the both situations are taking turns. I'm quite sure that the Problem is caused by gcc-4.0.1 because when I compile the samba source with gcc-3.4.3 it works perfectly. Sys-Infos: gcc -v: Configured with: ../gcc-4.0.1/configure --prefix=/usr --with-gnu-as --with-gnu-ld --enable-threads --enable-languages=c,c++,objc,java,treelang --enable-__cxa_atexit --with-x --enable-shared --enable-nls Thread model: posix gcc version 4.0.1 gcc-3.4.3 -v: Reading specs from /usr/lib/gcc/i686-pc-linux-gnu/3.4.3/specs Configured with: ../gcc-3.4.3/configure --prefix=/usr --with-gnu-as --with-gnu-ld --enable-threads --enable-languages=c,c++,objc,java,treelang --enable-__cxa_atexit --with-x --enable-shared --enable-nls --program-suffix=-3.4.3 Thread model: posix gcc version 3.4.3 Samba v. 3.0.14a - Configure-options: ./configure \ --enable-shared \ --with-smbmount \ --with-libsmbclient \ --without-ldap \ --with-pam \ --prefix=/usr \ --mandir=/usr/share/man \ --infodir=/usr/share/info \ --sysconfdir=/etc/samba \ --with-logfilebase=/var/log/samba \ --with-configdir=/etc/samba \ --with-lockdir=/var/lock/samba \ --with-piddir=/var/run/samba -- Summary: GCC produces wrong code Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Tobias dot Kranz at bka dot bund dot de CC: gcc-bugs at gcc dot gnu dot org 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=23311
[Bug c++/23310] ICE: stl_set.h:318: internal compiler error: Segmentation fault
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-08-10 09:40 --- Maybe too fast in blaming IVOPTs -- the ICE is during update_ssa of the alias pass, and -fdump-tree-alias fixes it. This is a duplicate bug of ... ? (I had this personally at one time) Maybe it's worth minimizing, maybe not, I'll try. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23310
[Bug c++/23310] ICE: stl_set.h:318: internal compiler error: Segmentation fault
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-08-10 09:32 --- Confirmed. /mnt/hd/bld/gcc/i686-pc-linux-gnu/libstdc++-v3/include/bits/stl_set.h: In member function âstd::pair, _Compare, typename _Alloc::rebind<_Key>::other>::const_iterator, bool> std::set<_Key, _Compare, _Alloc>::insert(const _Key&) [with _Key = int, _Compare = std::less, _Alloc = std::allocator]â: /mnt/hd/bld/gcc/i686-pc-linux-gnu/libstdc++-v3/include/bits/stl_set.h:318: internal compiler error: tree check: expected ssa_name, have var_decl in is_old_name, at tree-into-ssa.c:466 IVOPTs bug. Aka, -fno-ivopts fixes it. Sigh. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-08-10 09:32:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23310
[Bug target/18170] [4.0/4.1 Regression] m32r-elf-as, m32r-linux-as debug relocation error for c++
--- Additional Comments From inaoka dot kazuhiro at renesas dot com 2005-08-10 09:27 --- m32r is no longer affected. -- What|Removed |Added Status|WAITING |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18170
[Bug middle-end/23294] fold does not fold a*C+a to a*(C+1) or a*C-a to a*(C-1)
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-08-10
09:23 ---
I believe we can only do so for -fwrapv (but we don't) or for unsigned (which we
also don't do). I may look at this somewhen in the future.
We also don't canonicalize
int f(int a)
{
return a + a + a;
}
which I believe we did at some time?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23294
[Bug c/23309] m32r-linux-gcc ICE: in extract_insn, at recog.c
--- Additional Comments From inaoka dot kazuhiro at renesas dot com 2005-08-10 09:20 --- Fixed in 4.0.1. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23309
[Bug target/23305] Inlining related regression for gcc-4.x
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-08-10 09:15 --- I can confirm a ~2.x time slowdown going from -O2 to -O2 -finline-functions on i686. Though this is unfortunate. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-08-10 09:15:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23305
[Bug c++/23307] ICE in cp_parser_template_id, at cp/parser.c:8564 with Boost remote_call_manager
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-08-10 08:58 --- Patch submitted. -- What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||08/msg00560.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23307
