[Bug target/32830] shared library create by hppa64-hp11.11 can't run.
--- Comment #4 from cnstar9988 at gmail dot com 2007-07-20 07:31 --- On HPPA64, there are some warning. /home/beans/gcc-build/build/./gcc/xgcc -B/home/beans/gcc-build/build/./gcc/ -B/opt/gcc-4.2.1/lp64/hppa64-hp-hpux11.11/bin/ -B/opt/gcc-4.2.1/lp64/hppa64-hp-hpux11.11/lib/ -isystem /opt/gcc-4.2.1/lp64/hppa64-hp-hpux11.11/include -isystem /opt/gcc-4.2.1/lp64/hppa64-hp-hpux11.11/sys-include -O2 -g -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I. -I../../src/gcc -I../../src/gcc/. -I../../src/gcc/../include -I../../src/gcc/../libcpp/include -I../../src/gcc/../libdecnumber -I../libdecnumber -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-toplevel-reorder \ -c ../../src/gcc/crtstuff.c -DCRT_BEGIN \ -o crtbegin.o ../../src/gcc/crtstuff.c: In function '__do_global_dtors_aux': ../../src/gcc/crtstuff.c:298: warning: the address of '__deregister_frame_info' will always evaluate as 'true' ../../src/gcc/crtstuff.c: In function 'frame_dummy': ../../src/gcc/crtstuff.c:332: warning: the address of '__register_frame_info' will always evaluate as 'true' /home/beans/gcc-build/build/./gcc/xgcc -B/home/beans/gcc-build/build/./gcc/ -B/opt/gcc-4.2.1/lp64/hppa64-hp-hpux11.11/bin/ -B/opt/gcc-4.2.1/lp64/hppa64-hp-hpux11.11/lib/ -isystem /opt/gcc-4.2.1/lp64/hppa64-hp-hpux11.11/include -isystem /opt/gcc-4.2.1/lp64/hppa64-hp-hpux11.11/sys-include -O2 -g -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I. -I../../src/gcc -I../../src/gcc/. -I../../src/gcc/../include -I../../src/gcc/../libcpp/include -I../../src/gcc/../libdecnumber -I../libdecnumber -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-toplevel-reorder \ -c ../../src/gcc/crtstuff.c -DCRT_END \ -o crtend.o /home/beans/gcc-build/build/./gcc/xgcc -B/home/beans/gcc-build/build/./gcc/ -B/opt/gcc-4.2.1/lp64/hppa64-hp-hpux11.11/bin/ -B/opt/gcc-4.2.1/lp64/hppa64-hp-hpux11.11/lib/ -isystem /opt/gcc-4.2.1/lp64/hppa64-hp-hpux11.11/include -isystem /opt/gcc-4.2.1/lp64/hppa64-hp-hpux11.11/sys-include -O2 -g -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I. -I../../src/gcc -I../../src/gcc/. -I../../src/gcc/../include -I../../src/gcc/../libcpp/include -I../../src/gcc/../libdecnumber -I../libdecnumber -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-toplevel-reorder \ -c ../../src/gcc/crtstuff.c -DCRT_BEGIN -DCRTSTUFFS_O \ -o crtbeginS.o ../../src/gcc/crtstuff.c: In function '__do_global_dtors_aux': ../../src/gcc/crtstuff.c:276: warning: the address of '__cxa_finalize' will always evaluate as 'true' ../../src/gcc/crtstuff.c:298: warning: the address of '__deregister_frame_info' will always evaluate as 'true' ../../src/gcc/crtstuff.c: In function 'frame_dummy': ../../src/gcc/crtstuff.c:332: warning: the address of '__register_frame_info' will always evaluate as 'true' /home/beans/gcc-build/build/./gcc/xgcc -B/home/beans/gcc-build/build/./gcc/ -B/opt/gcc-4.2.1/lp64/hppa64-hp-hpux11.11/bin/ -B/opt/gcc-4.2.1/lp64/hppa64-hp-hpux11.11/lib/ -isystem /opt/gcc-4.2.1/lp64/hppa64-hp-hpux11.11/include -isystem /opt/gcc-4.2.1/lp64/hppa64-hp-hpux11.11/sys-include -O2 -g -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I. -I../../src/gcc -I../../src/gcc/. -I../../src/gcc/../include -I../../src/gcc/../libcpp/include -I../../src/gcc/../libdecnumber -I../libdecnumber -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-toplevel-reorder \ -c ../../src/gcc/crtstuff.c -DCRT_END -DCRTSTUFFS_O \ -o crtendS.o /home/beans/gcc-build/build/./gcc/xgcc -B/home/beans/gcc-build/build/./gcc/ -B/opt/gcc-4.2.1/lp64/hppa64-hp-hpux11.11/bin/ -B/opt/gcc-4.2.1/lp64/hppa64-hp-hpux11.11/lib/ -isystem /opt/gcc-4.2.1/lp64/hppa64-hp-hpux11.11/include -isystem /opt/gcc-4.2.1/lp64/hppa64-hp-hpux11.11/sys-include -O2 -g -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I. -I../../src/gcc -I../../src/gcc/. -I../../src/gcc/../include -I../../src/gcc/../libcpp/include -I../../src/gcc/../libdecnumber -I../libdecnumber -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-toplevel-reorder \ -c ../../src/gcc/crtstuff.c -DCRT_BEGIN -DCRTSTUFFT_O \ -o crtbeginT.o ../../src/gcc/crtstuff.c: In function '__do_global_dtors_aux': ../../src/gcc/crtstuff.c:298: warning: the address of '__deregister_frame_info' will always evaluate as 'true' ../../src/gcc/crtst
[Bug fortran/32834] New: [Meta-bugs] 'Fortran 95'-only failures
This meta-bug tries to list all rejects-valid and ice-on-valid-code that can be triggered with standard Fortran 95 conforming code, are not arch specific, and can not reasonably be called a limit of the compiler. In full agreement with pault, I think fixing these should be a priority. -- Summary: [Meta-bugs] 'Fortran 95'-only failures Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32834
[Bug bootstrap/32835] New: Bootstrap failure under SGI Irix
Hi! I have lately been unable to build Gcc from developpment sources under SGI Irix: it fails at bootstrap with [...] rm -f stage_current make[3]: Leaving directory `/USER/philippe/Irix/Compilation/Gcc' Comparing stages 2 and 3 warning: ./cc1-checksum.o differs Bootstrap comparison failure! /fortran/trans-array.o differs /build/genattrtab.o differs /omega.o differs /tree-cfg.o differs make[2]: *** [compare] Error 1 make[2]: Leaving directory `/USER/philippe/Irix/Compilation/Gcc' make[1]: *** [stage3-bubble] Error 2 make[1]: Leaving directory `/USER/philippe/Irix/Compilation/Gcc' make: *** [bootstrap] Error 2 I was last able to build successfully the 15/06/2007 (with freshly updated sources), aftewards I didn't try for a while: I am now trying to pinpoint the first revision to fail so as to find the offending patch... Cheers! Philippe PS: uname -a: IRIX64 fuel3 6.5 01100304 IP35 -- Summary: Bootstrap failure under SGI Irix Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: P dot Schaffnit at access dot rwth-aachen dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32835
[Bug fortran/32834] [Meta-bugs] 'Fortran 95'-only failures
--- Comment #1 from jv244 at cam dot ac dot uk 2007-07-20 08:20 --- only 1 open since 2005, 2 open since 2006, others are 2007. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32834
[Bug tree-optimization/19910] [4.2/4.3 regression] ICE with -ftree-loop-linear
--- Comment #15 from uros at gcc dot gnu dot org 2007-07-20 09:44 --- Subject: Bug 19910 Author: uros Date: Fri Jul 20 09:43:52 2007 New Revision: 126799 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126799 Log: PR tree-optimization/19910 * gcc.dg/pr19910.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr19910.c Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19910
[Bug java/32836] New: infinite loop (SIGSEGV) in java::lang::Throwable::fillInStackTrace
This is Fedora 7. $ gcj -v Using built-in specs. Reading specs from /usr/lib/gcc/i386-redhat-linux/4.1.2/libgcj.spec rename spec startfile to startfileorig rename spec lib to liborig Target: i386-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --with-cpu=generic --host=i386-redhat-linux Thread model: posix gcc version 4.1.2 20070502 (Red Hat 4.1.2-12) There is this curious stack trace (in GDB): ... #7889 #7890 0x006fc7e6 in ?? () from /lib/libgcc_s.so.1 #7891 0x006fd6b2 in _Unwind_Backtrace () from /lib/libgcc_s.so.1 #7892 0x02d9ac4e in _Jv_StackTrace::GetStackTrace () from /usr/lib/libgcj.so.8rh #7893 0x02dd5ecc in java::lang::VMThrowable::fillInStackTrace () from /usr/lib/libgcj.so.8rh #7894 0x03259492 in java::lang::Throwable::fillInStackTrace () from /usr/lib/libgcj.so.8rh #7895 0x03258ddd in java::lang::Throwable::Throwable () from /usr/lib/libgcj.so.8rh #7896 0x03258da3 in java::lang::Throwable::Throwable () from /usr/lib/libgcj.so.8rh #7897 0x0323cefb in java::lang::Exception::Exception () from /usr/lib/libgcj.so.8rh #7898 0x0324369b in java::lang::RuntimeException::RuntimeException () from /usr/lib/libgcj.so.8rh #7899 0x032418db in java::lang::NullPointerException::NullPointerException () from /usr/lib/libgcj.so.8rh #7900 0x02d89b08 in ?? () from /usr/lib/libgcj.so.8rh #7901 #7902 0x006fc7e6 in ?? () from /lib/libgcc_s.so.1 #7903 0x006fd6b2 in _Unwind_Backtrace () from /lib/libgcc_s.so.1 ---Type to continue, or q to quit--- #7904 0x02d9ac4e in _Jv_StackTrace::GetStackTrace () from /usr/lib/libgcj.so.8rh #7905 0x02dd5ecc in java::lang::VMThrowable::fillInStackTrace () from /usr/lib/libgcj.so.8rh #7906 0x03259492 in java::lang::Throwable::fillInStackTrace () from /usr/lib/libgcj.so.8rh #7907 0x03258ddd in java::lang::Throwable::Throwable () from /usr/lib/libgcj.so.8rh #7908 0x03258da3 in java::lang::Throwable::Throwable () from /usr/lib/libgcj.so.8rh #7909 0x0323cefb in java::lang::Exception::Exception () from /usr/lib/libgcj.so.8rh #7910 0x0324369b in java::lang::RuntimeException::RuntimeException () from /usr/lib/libgcj.so.8rh #7911 0x032418db in java::lang::NullPointerException::NullPointerException () from /usr/lib/libgcj.so.8rh #7912 0x02d89b08 in ?? () from /usr/lib/libgcj.so.8rh #7913 #7914 0x006fc7e6 in ?? () from /lib/libgcc_s.so.1 #7915 0x006fd6b2 in _Unwind_Backtrace () from /lib/libgcc_s.so.1 #7916 0x02d9ac4e in _Jv_StackTrace::GetStackTrace () from /usr/lib/libgcj.so.8rh #7917 0x02dd5ecc in java::lang::VMThrowable::fillInStackTrace () from /usr/lib/libgcj.so.8rh #7918 0x03259492 in java::lang::Throwable::fillInStackTrace () from /usr/lib/libgcj.so.8rh #7919 0x03258ddd in java::lang::Throwable::Throwable () from /usr/lib/libgcj.so.8rh #7920 0x03258da3 in java::lang::Throwable::Throwable () from /usr/lib/libgcj.so.8rh #7921 0x0323cefb in java::lang::Exception::Exception () from /usr/lib/libgcj.so.8rh #7922 0x0324369b in java::lang::RuntimeException::RuntimeException () from /usr/lib/libgcj.so.8rh #7923 0x032418db in java::lang::NullPointerException::NullPointerException () from /usr/lib/libgcj.so.8rh #7924 0x02d89b08 in ?? () from /usr/lib/libgcj.so.8rh #7925 #7926 0x08368d70 in aga::stpcpy (dest=0x64353f5d "", _src=0x836c92b "&ssi=") at chomp.cpp:174 As you can see, fillInStackTrace goes into an infinite loop, presumably due to SIGSEGV in itself, until it stack overflows. I can provide the binary and the core if somebody is interested in fixing this. -- Summary: infinite loop (SIGSEGV) in java::lang::Throwable::fillInStackTrace Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: artem at bizlink dot ru GCC build triplet: i386-redhat-linux GCC host triplet: i386-redhat-linux GCC target triplet: i386-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32836
[Bug java/32836] infinite loop (SIGSEGV) in java::lang::Throwable::fillInStackTrace
--- Comment #1 from artem at bizlink dot ru 2007-07-20 10:00 --- In fact, I have two cores with this infinite loop, and they both are very large: $ l total 304808 drwxr-xr-x 2 artemgr artemgr 4096 2007-07-20 11:58 ./ drwxr-xr-x 8 artemgr artemgr 4096 2007-07-20 11:57 ../ -rwxr-xr-x 1 artemgr artemgr 18949540 2007-07-20 11:25 ads* -rw--- 1 artemgr artemgr 2317770752 2007-07-20 08:44 core.11043 -rw--- 1 artemgr artemgr 2296696832 2007-07-20 08:38 core.7490 Could be that it's some kind of an out of memory error? Still, it is triggered only from this fillInStackTrace, otherwise the program is working fine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32836
[Bug testsuite/32837] New: FAIL: gcc.dg/pragma-darwin.c
copy of my mail
http://gcc.gnu.org/ml/gcc/2007-07/msg00515.html
The test gcc.dg/pragma-darwin.c fails with
FAIL: gcc.dg/pragma-darwin.c (test for errors, line 15)
FAIL: gcc.dg/pragma-darwin.c (test for errors, line 16)
FAIL: gcc.dg/pragma-darwin.c (test for errors, line 17)
FAIL: gcc.dg/pragma-darwin.c (test for errors, line 18)
FAIL: gcc.dg/pragma-darwin.c (test for errors, line 19)
FAIL: gcc.dg/pragma-darwin.c (test for errors, line 67)
FAIL: gcc.dg/pragma-darwin.c (test for errors, line 68)
FAIL: gcc.dg/pragma-darwin.c (test for excess errors)
(see http://gcc.gnu.org/ml/gcc-testresults/2007-07/msg00621.html)
Apparently gcc 4.3 emits only warnings while the test expects errors:
...
#pragma options 23 /* { dg-error "malformed '#pragma options'" } */
#pragma options align /* { dg-error "malformed '#pragma options'" } */
#pragma options align natural /* { dg-error "malformed '#pragma options'" } */
#pragma options align=45 /* { dg-error "malformed '#pragma options'" } */
#pragma options align=foo /* { dg-error "malformed '#pragma options align" } */
...
#pragma unused /* { dg-error "missing '.' after '#pragma unused" } */
#pragma unused (a /* { dg-error "missing '.' after '#pragma unused" } */
...
--
Summary: FAIL: gcc.dg/pragma-darwin.c
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
GCC target triplet: powerpc-apple-darwin8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32837
[Bug bootstrap/32835] [4.3 regression] Bootstrap failure under SGI Irix
--- Comment #1 from ro at gcc dot gnu dot org 2007-07-20 10:28 --- As of r126744, I observe the same problem. With ada included, I get two additional differences: ./ada/b_gnat1.o differs ./ada/b_gnatb.o differs My last successful mainline bootstrap was on 20070622, on 20070702 it already failed in stage 1 or 2 (I don't recall the exact circumstances and the tree is gone). -- ro at gcc dot gnu dot org changed: What|Removed |Added CC||ro at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-20 10:28:29 date|| Summary|Bootstrap failure under SGI |[4.3 regression] Bootstrap |Irix|failure under SGI Irix http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32835
[Bug java/32836] infinite loop (SIGSEGV) in java::lang::Throwable::fillInStackTrace
--- Comment #2 from artem at bizlink dot ru 2007-07-20 10:38 --- > In fact, I have two cores with this infinite loop, > and they both are very large 12 mb when compressed with p7zip, so I can still deliver upon request. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32836
[Bug bootstrap/32835] [4.3 regression] Bootstrap failure under SGI Irix
--- Comment #2 from P dot Schaffnit at access dot rwth-aachen dot de 2007-07-20 10:55 --- This is actually known (I missed it...): see Richard Sandiford's answer at http://gcc.gnu.org/ml/fortran/2007-07/msg00389.html Philippe -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32835
[Bug java/32836] infinite loop (SIGSEGV) in java::lang::Throwable::fillInStackTrace
--- Comment #3 from artem at bizlink dot ru 2007-07-20 11:27 --- To clarify: this is a buffer overflow, catched by the GCJ SIGSEGV handler. GCJ then tries to build a strack trace, but stack is obviously broken. Still, it's not pretty that GCJ goes into an infinite loop via SIGSEGV handler, and then into stack overflow, so I think it would be good if that infinite loop condition can be detected somehow (for example, by traversing the intact part of the stack trace we can easily see that we are already invoked from the SIGSEGV handler twice or more!). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32836
[Bug java/32836] infinite loop (SIGSEGV) in java::lang::Throwable::fillInStackTrace
--- Comment #4 from artem at bizlink dot ru 2007-07-20 11:34 --- I think the best JVM-compatible action then would be to shutdown the failed thread, but let the other threads continue... -- artem at bizlink dot ru changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32836
[Bug java/32836] infinite loop (SIGSEGV) in java::lang::Throwable::fillInStackTrace
--- Comment #5 from artem at bizlink dot ru 2007-07-20 11:39 --- > I think the best JVM-compatible action then would be > to shutdown the failed thread, > but let the other threads continue... E... I wasn't really going to post this. Forgot to clear the textarea. Sorry. I don't think it's possible to detect reliably if this is a thread-local problem or not, so the best action is still to abort, but at least it will abort without consuming (2 GB?) of stack space and hard disk space (for the core). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32836
[Bug tree-optimization/32698] [4.3 regression] inefficient pointer expression
--- Comment #14 from rguenth at gcc dot gnu dot org 2007-07-20 11:48 --- For current mainline I get (-O2) foo: pushl %ebp movl%esp, %ebp movl8(%ebp), %ecx movl12(%ebp), %edx popl%ebp movl8(%ecx,%edx,4), %eax addl4(%ecx,%edx,4), %eax addl12(%ecx,%edx,4), %eax ret Can you be more specific about what processor tuning you are using? That is, can you provide the output of adding -v to the gcc commandline that produces the mainline results in the last comment? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32698
[Bug target/32838] New: gcc generates incorrect trampoline code in thumb mode
When using nested functions, the trampoline code will destroy register 9 while loading the static chain. This is even noted in gcc/config/arm/arm.h: XXX FIXME: When the trampoline returns, r8 will be clobbered. (it will be r9 and not r8...). The attached patch avoids clobbering r9. -- Summary: gcc generates incorrect trampoline code in thumb mode Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: leo at marco dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32838
[Bug target/32838] gcc generates incorrect trampoline code in thumb mode
--- Comment #1 from leo at marco dot de 2007-07-20 11:53 --- Created an attachment (id=13943) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13943&action=view) fix for the reported bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32838
[Bug tree-optimization/32698] [4.3 regression] inefficient pointer expression
--- Comment #15 from zippel at gcc dot gnu dot org 2007-07-20 11:58 --- In the examples I used -fomit-frame-pointer. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32698
[Bug c++/32832] Seg fault on member function that does not return a val
--- Comment #2 from CyrusOmega at gmail dot com 2007-07-20 11:56 --- Subject: Re: Seg fault on member function that does not return a val Is there ANY case where this action would NOT result in a segfault!? Specifically, it is segfaulting because something is being freed that was never created in the first place, or that has already been freed. If my code doesn't say what to return, then shouldn't the compiler either A) return the default object of the type the func will return or B) give an error telling me to fix the problem. I don't know what the spec says but this undefined behavior seems rather serious and should either be a default warning or the compiler should offer a consistent reaction. I am not bashing gcc in any way, just expression the opinion of a long timer coder that is trying to help make gcc even better. I will start using -Wall for everything ;) Thanks, Andrew On 20 Jul 2007 04:36:57 -, pinskia at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote: > > > --- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-20 04:36 > --- > This is only undefined behavior which is why we only warn about it. > > > -- > > pinskia at gcc dot gnu dot org changed: > >What|Removed |Added > > Status|UNCONFIRMED |RESOLVED > Resolution||INVALID > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32832 > > --- You are receiving this mail because: --- > You reported the bug, or are watching the reporter. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32832
[Bug target/32838] gcc generates incorrect trampoline code in thumb mode
--- Comment #2 from leo at marco dot de 2007-07-20 11:55 --- (In reply to comment #0) I forgot to mention that this happens only for thumb mode. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32838
[Bug fortran/32834] [Meta-bug] 'Fortran 95'-only failures
-- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||meta-bug Last reconfirmed|-00-00 00:00:00 |2007-07-20 12:25:13 date|| Summary|[Meta-bugs] 'Fortran 95'- |[Meta-bug] 'Fortran 95'-only |only failures |failures http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32834
[Bug c++/32839] New: internal compiler error: Segmentation fault (templates)
Yesterday, one of my collegues ran into an internal compiler error when playing with some template code. Although she ran into the ICE on Mac OS X with an Apple gcc 4.01 build, it was easy enough to reproduce it on a linux box with a GNU gcc build. I'm logging this against 4.2.1, but it seems every 4.x version segfaults; I tested with 4.02, 4.1-20060113 (yep, some old build laying around), 4.2.1 and even with the latest 4.3-20070713. I created a small test case (see attachment) and this is the output I get with 4.2.1: [EMAIL PROTECTED]:~/bugs/ice> ~/opt/gcc-4.2.1/bin/g++ -v -o test test.cpp Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.2.1/configure --prefix=/home/dannyb/opt/gcc-4.2.1 --enable-languages=c,c++ Thread model: posix gcc version 4.2.1 /home/dannyb/opt/gcc-4.2.1/libexec/gcc/i686-pc-linux-gnu/4.2.1/cc1plus -quiet -v -D_GNU_SOURCE test.cpp -quiet -dumpbase test.cpp -mtune=generic -auxbase test -version -o /tmp/ccyPKN6k.s ignoring nonexistent directory "/home/dannyb/opt/gcc-4.2.1/lib/gcc/i686-pc-linux-gnu/4.2.1/../../../../i686-pc-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /home/dannyb/opt/gcc-4.2.1/lib/gcc/i686-pc-linux-gnu/4.2.1/../../../../include/c++/4.2.1 /home/dannyb/opt/gcc-4.2.1/lib/gcc/i686-pc-linux-gnu/4.2.1/../../../../include/c++/4.2.1/i686-pc-linux-gnu /home/dannyb/opt/gcc-4.2.1/lib/gcc/i686-pc-linux-gnu/4.2.1/../../../../include/c++/4.2.1/backward /usr/local/include /home/dannyb/opt/gcc-4.2.1/include /home/dannyb/opt/gcc-4.2.1/lib/gcc/i686-pc-linux-gnu/4.2.1/include /usr/include End of search list. GNU C++ version 4.2.1 (i686-pc-linux-gnu) compiled by GNU C version 4.2.1. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: cfede80d80c2b8e19355e4026d77f0b9 test.cpp: In member function void ScopeImpl::Execute() [with F = void (*)(int)]: test.cpp:31: instantiated from static void ScopeImplBase::SafeExecute(J&) [with J = ScopeImpl] test.cpp:50: instantiated from ScopeImpl::~ScopeImpl() [with F = void (*)(int)] test.cpp:46: instantiated from static void ScopeImpl::MakeGuard(F) [with F = void (*)(int)] test.cpp:68: instantiated from void DoAtExit(F) [with F = void (*)(int)] test.cpp:74: instantiated from here test.cpp:54: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- Summary: internal compiler error: Segmentation fault (templates) Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danny dot boelens at artwork-systems dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32839
[Bug c++/32839] internal compiler error: Segmentation fault (templates)
--- Comment #1 from danny dot boelens at artwork-systems dot com 2007-07-20 12:41 --- Created an attachment (id=13944) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13944&action=view) Test case that triggers the ICE -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32839
[Bug bootstrap/32829] CVS bootstrap failure with as: unrecognised option -Qy
--- Comment #2 from brian dot sidebotham at gmail dot com 2007-07-20 13:16 --- Earlier in the build, I get a line which I've just noticed scanning through some logs: CONFIGURE:14040: test - Too many arguments I suspect this is the cause of the problem, as it checks the version of as being used and enables leb128 if as > 2.11 I am not near my linux box at the moment, so cannot fix the line and re-build to make sure this is the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32829
[Bug bootstrap/32829] CVS bootstrap failure with as: unrecognised option -Qy
--- Comment #3 from brian dot sidebotham at gmail dot com 2007-07-20 13:18
---
appologies, in my previous post:
CONFIGURE:14040: test - Too many arguments
should more accurately read -
${srcdir}/gcc/configure:14040: test - Too many arguments
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32829
[Bug bootstrap/32840] New: bootstrap broken on ix86-linux-gnu targets with --enable-targets=all
the libstdc++ configure fails with configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES. the build is configured with --enable-languages=c,c++ --prefix=/usr/lib/gcc-snapshot --enable-shared --with-system-zlib --disable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-targets=all --disable-werror --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu checking if /home/packages/gcc/snap/gcc-snapshot-20070720/build/./gcc/xgcc -B/home/packages/gcc/snap/gcc-snapshot-20070720/build/./gcc/ -B/usr/lib/gcc-snapshot/i486-linux-gnu/bin/ -B/usr/lib/gcc-snapshot/i486-linux-gnu/lib/ -isystem /usr/lib/gcc-snapshot/i486-linux-gnu/include -isystem /usr/lib/gcc-snapshot/i486-linux-gnu/sys-include -m64 supports -c -o file.o... (cached) yes checking whether the /home/packages/gcc/snap/gcc-snapshot-20070720/build/./gcc/xgcc -B/home/packages/gcc/snap/gcc-snapshot-20070720/build/./gcc/ -B/usr/lib/gcc-snapshot/i486-linux-gnu/bin/ -B/usr/lib/gcc-snapshot/i486-linux-gnu/lib/ -isystem /usr/lib/gcc-snapshot/i486-linux-gnu/include -isystem /usr/lib/gcc-snapshot/i486-linux-gnu/sys-include -m64 linker (/home/packages/gcc/snap/gcc-snapshot-20070720/build/./gcc/collect-ld -m elf_x86_64) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES. make[3]: *** [configure-target-libstdc++-v3] Error 1 make[3]: Leaving directory `/home/packages/gcc/snap/gcc-snapshot-20070720/build' make[2]: *** [bootstrap-lean] Error 2 -- Summary: bootstrap broken on ix86-linux-gnu targets with -- enable-targets=all Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: debian-gcc at lists dot debian dot org GCC target triplet: i486-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32840
[Bug libgcj/32836] infinite loop (SIGSEGV) in java::lang::Throwable::fillInStackTrace
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|enhancement |normal Component|java|libgcj http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32836
[Bug other/32833] libgcc_s.so binary, version `GCC_4.2.0' not found
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-20 14:54 --- You need to set LD_LIBRARY_PATH to the correct location to include the newest version of libgcc_s. libgcc_s is backwards compatiable but not fowards compatiable. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal Status|UNCONFIRMED |RESOLVED Component|c |other Resolution||INVALID Summary|libgcc_s.so binary, version |libgcc_s.so binary, version |`GCC_4.2.0' not found |`GCC_4.2.0' not found http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32833
[Bug target/31325] gcj support for ARM EABI
--- Comment #13 from aph at gcc dot gnu dot org 2007-07-20 15:11 --- Do you have copyright assignment? If you do, please submit these patches to [EMAIL PROTECTED] and [EMAIL PROTECTED] -- aph at gcc dot gnu dot org changed: What|Removed |Added CC||aph at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31325
[Bug target/31325] gcj support for ARM EABI
--- Comment #14 from aph at gcc dot gnu dot org 2007-07-20 15:15 --- Actually, forget that last message. Most of these patches seem to be gcc 4.2 based and the libffi and gij patches are already done. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31325
[Bug tree-optimization/32720] [4.3 Regression] No coalesce ssa_names
--- Comment #10 from bonzini at gnu dot org 2007-07-20 15:47 --- Andrew, could you make a C testcase maybe?... -- bonzini at gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32720
[Bug tree-optimization/32698] [4.3 regression] inefficient pointer expression
--- Comment #16 from rguenth at gcc dot gnu dot org 2007-07-20 16:05 --- That makes it foo: movl4(%esp), %ecx movl8(%esp), %edx movl8(%ecx,%edx,4), %eax addl4(%ecx,%edx,4), %eax addl12(%ecx,%edx,4), %eax ret for me. Still different from what you claim. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32698
[Bug tree-optimization/32698] [4.3 regression] inefficient pointer expression
--- Comment #17 from zippel at gcc dot gnu dot org 2007-07-20 16:21 --- Which claim? It's exactly the third code example in comment #13 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32698
[Bug fortran/32827] IMPORT fails for TYPE when also used in INTERFACE
--- Comment #1 from tkoenig at gcc dot gnu dot org 2007-07-20 16:22 --- Not architecture specific. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|same - but with bug fix for | |fortran/32801 included | GCC host triplet|i386-portbld-freebsd6.2 -- | |4.3.0 20070713 | |(experimental) | GCC target triplet|same| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32827
[Bug tree-optimization/32698] [4.3 regression] inefficient pointer expression
--- Comment #18 from rguenth at gcc dot gnu dot org 2007-07-20 16:35 --- I mean Current gcc finally produces: *p = (a + 1) * 4; *(p + 4) = (a + 2) * 4; *(p + 8) = (a + 3) * 4; movl8(%esp), %eax movl4(%esp), %ecx leal4(,%eax,4), %edx movl%edx, (%ecx) leal8(,%eax,4), %edx leal12(,%eax,4), %eax movl%edx, 4(%ecx) movl%eax, 8(%ecx) ret This has now the largest code size of all versions. This new canonical form IMHO clearly conflicts with what is expected at RTL level, so I don't understand why it's so important to use this one. Could you maybe explain the reason behind this choice? which suggests that current trunk is worse with the patch. Or am I confused and you are happy with the code generated by current trunk for the original testcase? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32698
[Bug fortran/28397] Check format mismatches at compile time
--- Comment #1 from tkoenig at gcc dot gnu dot org 2007-07-20 16:41 --- *** Bug 32816 has been marked as a duplicate of this bug. *** -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28397
[Bug fortran/32816] Compile-time check for No data-edit descriptor for effective item
--- Comment #1 from tkoenig at gcc dot gnu dot org 2007-07-20 16:41 --- *** This bug has been marked as a duplicate of 28397 *** -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32816
[Bug fortran/30814] non-conforming array sizes in PACK should raise an error
--- Comment #2 from patchapp at dberlin dot org 2007-07-20 16:43 --- Subject: Bug number PR 30814 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01597.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30814
[Bug fortran/32834] [Meta-bug] 'Fortran 95'-only failures
--- Comment #2 from tkoenig at gcc dot gnu dot org 2007-07-20 16:42 --- Should we open another PR for wrong-code errors? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32834
[Bug fortran/32834] [Meta-bug] 'Fortran 95'-only failures
--- Comment #3 from jv244 at cam dot ac dot uk 2007-07-20 17:02 --- (In reply to comment #2) > Should we open another PR for wrong-code errors? no, I overlooked that keyword, and they belong to this category (though I'll again ignore arch specific ones). I'll add them to the list shortly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32834
[Bug target/31325] gcj support for ARM EABI
--- Comment #15 from s_j_newbury at yahoo dot co dot uk 2007-07-20 17:16 --- (In reply to comment #14) > Actually, forget that last message. Most of these patches seem to be gcc 4.2 > based and the libffi and gij patches are already done. > I'm not sure what the current status of all this is at the moment, I've not got time to work on it right now. As an aside, currently gcc 4.3 does not build for iWMMXt, it hits an ICE while compiling libgcc with the stage1 compiler, so I can't test that for my target anyway (if it isn't fixed in the next snapshot I'll post a new bug report for it). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31325
[Bug fortran/32834] [Meta-bug] 'Fortran 95'-only failures
--- Comment #4 from jv244 at cam dot ac dot uk 2007-07-20 17:17 --- from the 19 wrong code bugs I've only retained 8 that I judged as user visible, F95, and triggered without additional options. -- jv244 at cam dot ac dot uk changed: What|Removed |Added BugsThisDependsOn||30625, 31205, 31211, 31487, ||31608 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32834
[Bug tree-optimization/32698] [4.3 regression] inefficient pointer expression
--- Comment #20 from rguenth at gcc dot gnu dot org 2007-07-20 17:22
---
Whoops ;) I missed that.
I have a counter-example that is better with the patch in the same way yours
is worse with it.
void f(unsigned int *p, unsigned int a)
{
p[0] = a * 4 + 4;
p[1] = a * 8 + 8;
p[2] = a * 12 + 12;
}
As I said, the fold canonicalization is just canonicalization, the code
generation has to be fixed elsewhere.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32698
[Bug tree-optimization/32698] [4.3 regression] inefficient pointer expression
--- Comment #19 from zippel at gcc dot gnu dot org 2007-07-20 17:06 --- There is another small source example inbetween, which is used to produce all code examples following it. :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32698
[Bug fortran/32823] [4.3 regression] internal compiler error: in gfc_trans_assignment_1
--- Comment #3 from patchapp at dberlin dot org 2007-07-20 19:05 --- Subject: Bug number PR32823 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01601.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32823
[Bug libfortran/23272] [mingw32] inquire via filename fails
--- Comment #6 from jv244 at cam dot ac dot uk 2007-07-20 19:35 --- should one add a mingw maintainer to the CC? BTW, this one misses the wrong-code keyword (and I don't have permission to add it, which is annoying). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23272
[Bug fortran/31265] Rejects valid with -std=f95: Error with RESHAPE on REAL initialization
--- Comment #1 from jv244 at cam dot ac dot uk 2007-07-20 19:55 --- this misses rejects-valid keyword -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31265
[Bug testsuite/32841] New: FAIL: gfortran.dg/edit_real_1.f90 on Darwin8
Copy of http://gcc.gnu.org/ml/fortran/2007-07/msg00388.html
I have finally decided to give a shot to OSX 10.4 on my G5 and I do
see the edit_real_1.f90 failure. The culprit is:
write (s, '(1PE10.3,A)') huge(0d0), "z"
The follwoing reduced code:
! { dg-do run }
! Check real value edit descriptors
! Also checks that rounding is performed correctly
program edit_real_1
character(len=20) s
character(len=20) x
parameter (x = "")
print *, huge(0d0), nearest(huge(0d0), -1.0d0)
print '(2(1PG30.18))', huge(0d0), nearest(huge(0d0), -1.0d0)
s = x
write (s, '(1PG10.3,A)') huge(0d0), "z"
print *, s
! E format, very large number.
! Used to overflow with positive scale factor
s = x
write (s, '(1PE10.3,A)') huge(0d0), "z"
print *, s
! The actual value is target specific, so just do a basic check
if ((s(1:1) .eq. "*") .or. (s(7:7) .ne. "+") .or. &
(s(11:11) .ne. "z")) call abort
end
gives under OSX 10.3:
1.797693134862316E+308 1.797693134862316E+308
1.797693134862315708+308 1.797693134862315509+308
1.798+308z
1.798+308z
while it gives under 10.4:
+Infinity 1.797693134862316E+308
+Infinity 1.797693134862315509+308
+Infinityz
+Infinityz
Abort
One can argue that huge(0d0) rounded to three digits is +Infinity,
but I think it is a bug to get +Infinity with the 18 digit precision.
Any idea on how to trace the problem?
Dominique
BTW when I said under OSX 10.3, it was not accurate, I meant
gfortran 4.3 compiled under 10.3, but run under 10.4
Following mails:
http://gcc.gnu.org/ml/fortran/2007-07/msg00393.html
http://gcc.gnu.org/ml/fortran/2007-07/msg00399.html
http://gcc.gnu.org/ml/fortran/2007-07/msg00400.html
--
Summary: FAIL: gfortran.dg/edit_real_1.f90 on Darwin8
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
GCC target triplet: powerpc-apple-darwin8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32841
[Bug testsuite/32841] FAIL: gfortran.dg/edit_real_1.f90 on Darwin8
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-07-20 20:54 --- The WTITEing of "Infinity" is dependent on the following C code in io/write.c res = isfinite (n); if (res == 0) So if the isfinite function is broken on this system, that would explain this problem. Can you test with a C program to see if indeed this is the problem? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32841
[Bug testsuite/32841] FAIL: gfortran.dg/edit_real_1.f90 on Darwin8
--- Comment #2 from dominiq at lps dot ens dot fr 2007-07-20 21:00 --- Subject: Re: FAIL: gfortran.dg/edit_real_1.f90 on Darwin8 > Can you test with a C program to see if indeed this is the problem? My knowledge of C it very limited, you know!-( Could you send me some canvas to start with? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32841
[Bug testsuite/32841] FAIL: gfortran.dg/edit_real_1.f90 on Darwin8
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-07-20 21:01 --- Additional note: isfinite may be getting redefined in libgfortran.h /* The isfinite macro is only available with C99, but some non-C99 systems still provide fpclassify, and there is a `finite' function in BSD. Also, isfinite is broken on Cygwin. When isfinite is not available, try to use one of the alternatives, or bail out. */ #if defined(HAVE_BROKEN_ISFINITE) || defined(__CYGWIN__) #undef isfinite #endif #if defined(HAVE_BROKEN_ISNAN) #undef isnan #endif #if defined(HAVE_BROKEN_FPCLASSIFY) #undef fpclassify #endif #if !defined(isfinite) #if !defined(fpclassify) #define isfinite(x) ((x) - (x) == 0) #else #define isfinite(x) (fpclassify(x) != FP_NAN && fpclassify(x) != FP_INFINITE) #endif /* !defined(fpclassify) */ #endif /* !defined(isfinite) */ #if !defined(isnan) #if !defined(fpclassify) #define isnan(x) ((x) != (x)) #else #define isnan(x) (fpclassify(x) == FP_NAN) #endif /* !defined(fpclassify) */ #endif /* !defined(isfinite) */ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32841
[Bug testsuite/32841] FAIL: gfortran.dg/edit_real_1.f90 on Darwin8
--- Comment #4 from dominiq at lps dot ens dot fr 2007-07-20 21:20 ---
Subject: Re: FAIL: gfortran.dg/edit_real_1.f90 on
Darwin8
I don't know if the following code is correct, but it returns 1:
#include
#include
int main()
{
double x;
x = 1.79769313486231570814527423731704356798070567526e+308;
printf("%1d \n", isfinite(x));
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32841
[Bug fortran/32842] New: Useroperator
>From the ISO_VARYING_STRING testsuite (vst_2.f90)
The following program prints an empty string instead of "Hello".
PROGRAM VST_2
USE ISO_VARYING_STRING
IMPLICIT NONE
CHARACTER(LEN=5) :: char_arb(2)
type(VARYING_STRING) :: str_ara(2)
char_arb(1)= "Hello"
char_arb(2)= "World"
str_ara = char_arb
!print *, char_arb(1)
print *, char(str_ara(1))
END PROGRAM VST_2
The program works accidentally for an array size of 1 (instead of 2). What is
the meaning of the inner for ("while(1)") loop? Simplified dump:
for(S.1 = 1; S.1 <= 2; S.1++)
{
for(S.3 = 1; S.3 <= 2; S3++)
{
struct varying_string D.1375
struct varying_string varying_string.2
varying_string.data = NULL
D.1375 = varying_string.2
deallocate(str_ara[S.3].data)
str_ara[S.3].data = NULL
str_ara[S.3] = D.1375
}
deallocate(str_ara[S.1].data)
str_ara[S.1].data = NULL;
op_assign_vs_ch(&str_ara[S.1], &char_arab[S1], 5)
}
Using the following as module instead of the full-fledged module gives even a
crash at "print *, char(str_ara(1))". Example works without valgrind problems
with g95 and NAG f95.
module iso_varying_string
implicit none
integer, parameter :: GET_BUFFER_LEN = 256
type varying_string
character(LEN=1), dimension(:), allocatable :: chars
end type varying_string
interface assignment(=)
module procedure op_assign_VS_CH
end interface assignment(=)
contains
elemental subroutine op_assign_VS_CH (var, exp)
type(varying_string), intent(out) :: var
character(LEN=*), intent(in) :: exp
var = var_str(exp)
end subroutine op_assign_VS_CH
elemental function var_str (char) result (string)
character(LEN=*), intent(in) :: char
type(varying_string) :: string
integer :: length
integer :: i_char
length = LEN(char)
ALLOCATE(string%chars(length))
forall(i_char = 1:length)
string%chars(i_char) = char(i_char:i_char)
end forall
end function var_str
end module iso_varying_string
--
Summary: Useroperator
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32842
[Bug target/29517] Exception handling not thread-safe on AIX5.x and HP-UX
--- Comment #9 from chris at cdnorthamerica dot com 2007-07-20 21:22 --- This fails for me too on HPUX 11.11, gcc 4.1.1: [EMAIL PROTECTED]:121>uname -a HP-UX wendy B.11.11 U 9000/785 1681839108 unlimited-user license [EMAIL PROTECTED]:122>make /opt/hp-gcc64-4.1.1/bin/g++ -pthread crashme.cpp -o crashme -lpthread [EMAIL PROTECTED]:123>~/dev/.dev/gdb/hpux-hppa-11.11/bin/gdb crashme GNU gdb 6.4 Copyright 2005 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "hppa64-hp-hpux11.11"...(no debugging symbols found) (gdb) run 5 10 Starting program: /home/cmm/hpux/crashme 5 10 Detaching after fork from child process 17434. Detaching after fork from child process 17435. Detaching after fork from child process 17436. (no debugging symbols found) (no debugging symbols found) [New process 17433, lwp 886906] Pass 1: Throwing exception in thread 0 [New process 17433, lwp 886907] Pass 1: Throwing exception in thread 1 [New process 17433, lwp 886908] Pass 1: Throwing exception in thread 2 [New process 17433, lwp 886909] Pass 1: Throwing exception in thread 3 [New process 17433, lwp 886910] Pass 1: Throwing exception in thread 4 Program received signal SIGSEGV, Segmentation fault. [Switching to process 17433, lwp 886910] _Unwind_SetGR (context=, index=, val=) at /tmp/gcc-4.1.1.tar.gz/gcc-4.1.1/gcc/unwind-dw2.c:176 176 /tmp/gcc-4.1.1.tar.gz/gcc-4.1.1/gcc/unwind-dw2.c: No such file or directory. in /tmp/gcc-4.1.1.tar.gz/gcc-4.1.1/gcc/unwind-dw2.c (gdb) bt #0 _Unwind_SetGR (context=, index=, val=) at /tmp/gcc-4.1.1.tar.gz/gcc-4.1.1/gcc/unwind-dw2.c:176 #1 0x83ffbffc66c8 in __gxx_personality_v0 (version=, actions=6, exception_class=, ue_header=0x8001000c4038, context=0x83ffbfc8b490) at /tmp/gcc-4.1.1.tar.gz/gcc-4.1.1/libstdc++-v3/libsupc++/eh_personality.cc:672 #2 0x83ffbfe36218 in _Unwind_RaiseException_Phase2 (exc=, context=) at unwind.inc:66 #3 0x83ffbfe36524 in _Unwind_RaiseException (exc=) at unwind.inc:135 #4 0x83ffbffc6b70 in __cxa_throw (obj=, tinfo=0x14, dest=0x8001000c4038) at /tmp/gcc-4.1.1.tar.gz/gcc-4.1.1/libstdc++-v3/libsupc++/eh_throw.cc:72 #5 0x40002bd8 in f () #6 0x83ffbffdb250 in __pthread_body () from /lib/pa20_64/libpthread.1 #7 0x83ffbffdb250 in __pthread_body () from /lib/pa20_64/libpthread.1 #8 0x83ffbffdb250 in __pthread_body () from /lib/pa20_64/libpthread.1 #9 0x83ffbffdb250 in __pthread_body () from /lib/pa20_64/libpthread.1 Cannot access memory at address 0x83ffbfc8afb0 (gdb) quit The program is running. Exit anyway? (y or n) y [EMAIL PROTECTED]:124>/opt/hp-gcc64-4.1.1/bin/g++ -v Using built-in specs. Target: hppa64-hp-hpux11.11 Configured with: /tmp/gcc-4.1.1.tar.gz/gcc-4.1.1/configure --host=hppa64-hp-hpux11.11 --target=hppa64-hp-hpux11.11 --build=hppa64-hp -hpux11.11 --prefix=/opt/hp-gcc64-4.1.1 --enable-languages=c,c++ --with-gnu-as --without-gnu-ld --with-ld=/usr/ccs/bin/ld --enable-t hreads=posix Thread model: posix gcc version 4.1.1 [EMAIL PROTECTED]:125> -- chris at cdnorthamerica dot com changed: What|Removed |Added CC||chris at cdnorthamerica dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29517
[Bug testsuite/32841] FAIL: gfortran.dg/edit_real_1.f90 on Darwin8
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-07-20 21:41
---
Try this:
#include
#include
#include
int
main ()
{
double x, y;
x = 1.79769313486231570814527423731704356798070567526e+308;
printf("%52.47e\n", x);
printf("isfinite = %d\n", isfinite(x));
printf("isfinite = %d\n", isfinite(1.1 * x));
return 0;
}
compiled with: gcc -std=c99 -lm test.c
I get:
$ gcc -std=c99 -lm test.c
$ ./a.out
1.79769313486231570814527423731704356798070567526e+308
isfinite = 1
isfinite = 0
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32841
[Bug testsuite/32841] FAIL: gfortran.dg/edit_real_1.f90 on Darwin8
--- Comment #6 from dominiq at lps dot ens dot fr 2007-07-20 22:08 --- Subject: Re: FAIL: gfortran.dg/edit_real_1.f90 on Darwin8 > Try this: ... I get 1.79769313486231570814527423731704356798070567526e+308 isfinite = 1 isfinite = 0 There is something I don't understand: in libgfortran/configure I read: # Check for a isfinite macro that works on long doubles. so it seems that HAVE_BROKEN_ISFINITE is set if isfinite is broken for long doubles (which seems likely, see the Jack's comment), but it is then used in libgfortran/libgfortran.h to redefine isfinite (corresponding to double?). Am I missing something? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32841
[Bug testsuite/32841] FAIL: gfortran.dg/edit_real_1.f90 on Darwin8
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2007-07-20 22:21 --- Can you post the config.h file from your build directory? blddir/archdir/libgfortran/config.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32841
[Bug testsuite/32841] FAIL: gfortran.dg/edit_real_1.f90 on Darwin8
--- Comment #8 from dominiq at lps dot ens dot fr 2007-07-20 22:28 --- Subject: Re: FAIL: gfortran.dg/edit_real_1.f90 on Darwin8 > Can you post the config.h file from your build directory? Unfortunately, it is gone (fink install) and I'll be away for two days. So not before Monday evening French time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32841
[Bug middle-end/32668] The type-generic builtins apply default promotions
--- Comment #6 from patchapp at dberlin dot org 2007-07-21 04:44 --- Subject: Bug number PR 32668 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01594.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32668
[Bug c/32843] New: [4.3 Regression] : libffi.call/return_sc.c
On Linux/ia32, this patch http://gcc.gnu.org/ml/gcc-cvs/2007-07/msg00336.html caused FAIL: libffi.call/return_sc.c -O0 -W -Wall execution test FAIL: libffi.call/return_sc.c -O2 execution test FAIL: libffi.call/return_sc.c -O3 execution test -- Summary: [4.3 Regression] : libffi.call/return_sc.c Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32843
