[Bug ada/40438] New: Internal error: Trace/BPT trap (program cc1obj)
Mac OSX 10.5.7 Mac mini Intel Core Duo When attempting make, compiler fails to load /usr/local/lib/libmpfr.1.dylib /usr/local/ada-4.5/bin/gcc -x objective-c -v -O0 -g-Wall -W -fstack-check -o cocoa_layouts cocoa_layouts.m -framework Cocoa Using built-in specs. Target: i686-apple-darwin9 Configured with: /Users/Shared/Developer/Compiler/gcc-head/configure --disable-checking --enable-static --prefix=/usr/local/ada-4.5 --host=i686-apple-darwin9 --target=i686-apple-darwin9 --build=i686-apple-darwin9 --enable-languages=c,ada,objc,obj-c++,c++,fortran --with-gmp=/usr/local/i686-ada-4.5 --with-mpfr=/usr/local/i686-ada-4.5 Thread model: posix gcc version 4.5.0 20090606 (experimental) [trunk revision 148233] (GCC) COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.5.7' '-v' '-O0' '-g' '-Wall' '-W' '-fstack-check' '-o' 'cocoa_layouts' '-mtune=generic' /usr/local/ada-4.5/libexec/gcc/i686-apple-darwin9/4.5.0/cc1obj -quiet -v -D__DYNAMIC__ cocoa_layouts.m -fPIC -feliminate-unused-debug-symbols -quiet -dumpbase cocoa_layouts.m -mmacosx-version-min=10.5.7 -mtune=generic -auxbase cocoa_layouts -g -O0 -Wall -W -version -fstack-check -o /var/folders/D4/D4Linq-8H2SQU87lD2DNnU+++TI/-Tmp-//ccSlI1k1.s dyld: Library not loaded: /usr/local/lib/libmpfr.1.dylib Referenced from: /usr/local/ada-4.5/libexec/gcc/i686-apple-darwin9/4.5.0/cc1obj Reason: no suitable image found. Did find: /usr/local/lib/libmpfr.1.dylib: unknown required load command 0x8022 /usr/local/lib/libmpfr.1.dylib: unknown required load command 0x8022 gcc: Internal error: Trace/BPT trap (program cc1obj) Please submit a full bug report. -- Summary: Internal error: Trace/BPT trap (program cc1obj) Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rogermc at iinet dot net dot au http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40438
[Bug ada/40438] Internal error: Trace/BPT trap (program cc1obj)
--- Comment #1 from rogermc at iinet dot net dot au 2009-06-14 07:07 --- Created an attachment (id=17992) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17992action=view) make file make file causing failure -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40438
[Bug ada/40438] Internal error: Trace/BPT trap (program cc1obj)
--- Comment #2 from rogermc at iinet dot net dot au 2009-06-14 07:13 --- Created an attachment (id=17993) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17993action=view) general.make called by make prior to GNUmakefile :/Ada_Source/cocoa-gnat-0.2 Roger$make general.make:13: Entered general.make. general.make:236: Leaving general.make. GNUmakefile:33: Current working directory is /Ada_Source/cocoa-gnat-0.2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40438
[Bug other/40438] Internal error: Trace/BPT trap (program cc1obj)
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2009-06-14 07:23 --- Nothing to do with Ada, cc1obj is the Objective-C compiler. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Component|ada |other Version|4.4.0 |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40438
[Bug libfortran/22423] Warnings when building libgfortran
--- Comment #21 from fxcoudert at gcc dot gnu dot org 2009-06-14 09:06 --- There's still a bunch of warnings: ../../../trunk/libgfortran/io/list_read.c: In function nml_read_obj: ../../../trunk/libgfortran/io/list_read.c:2345:5: warning: case value 6 not in enumerated type bt ../../../trunk/libgfortran/io/list_read.c:2392:4: warning: case value 6 not in enumerated type bt ../../../trunk/libgfortran/io/list_read.c:2469:31: warning: comparison between bt and enum anonymous ../../../trunk/libgfortran/io/list_read.c: In function nml_get_obj_data: ../../../trunk/libgfortran/io/list_read.c:2717:20: warning: comparison between bt and enum anonymous ../../../trunk/libgfortran/io/list_read.c:2739:28: warning: comparison between bt and enum anonymous ../../../trunk/libgfortran/io/list_read.c:2773:16: warning: comparison between bt and enum anonymous ../../../trunk/libgfortran/io/write.c: In function nml_write_obj: ../../../trunk/libgfortran/io/write.c:1261:17: warning: comparison between bt and enum anonymous ../../../trunk/libgfortran/io/write.c:1303:5: warning: case value 6 not in enumerated type bt ../../../trunk/libgfortran/io/write.c:1339:15: warning: comparison between bt and enum anonymous ../../../trunk/libgfortran/io/write.c:1372:6: warning: case value 6 not in enumerated type bt There is something quite wrong done here with type bt and putting values from a different enum into it. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||jb at gcc dot gnu dot org, ||fxcoudert at gcc dot gnu dot ||org Last reconfirmed|2009-05-03 16:28:50 |2009-06-14 09:06:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22423
[Bug bootstrap/37739] [4.4 Regression] bootstrap broken with core gcc gcc-4.2.x
--- Comment #14 from acrux at linuxmail dot org 2009-06-14 09:27 --- (In reply to comment #11) Fixed. it seems unfixed. Unable to bootstrap gcc-4.4.0 from itself. Problems happens only on powerpc32. failure: /home/varie/gcc/work/src/build/gcc/../../gcc-4.4.0/gcc/tree.h:192: relocation truncated to fit: R_PPC_REL24 against symbol `free@@GLIBC_2.0' defined in .plt section in /usr/lib/gcc/powerpc-unknown-linux-gnu/4.4.0/../../../crt1.o c-lang.o: In function `VEC_tree_heap_copy': /home/varie/gcc/work/src/build/gcc/../../gcc-4.4.0/gcc/tree.h:192: relocation truncated to fit: R_PPC_REL24 against symbol `memcpy@@GLIBC_2.0' defined in .plt section in /usr/lib/gcc/powerpc-unknown-linux-gnu/4.4.0/../../../crt1.o c-lang.o: In function `VEC_tree_heap_safe_grow_cleared': /home/varie/gcc/work/src/build/gcc/../../gcc-4.4.0/gcc/tree.h:192: relocation truncated to fit: R_PPC_REL24 against symbol `memset@@GLIBC_2.0' defined in .plt section in /usr/lib/gcc/powerpc-unknown-linux-gnu/4.4.0/../../../crt1.o c-lang.o: In function `VEC_constructor_elt_base_quick_insert': /home/varie/gcc/work/src/build/gcc/../../gcc-4.4.0/gcc/tree.h:1532: additional relocation overflows omitted from the output collect2: ld returned 1 exit status make[3]: *** [cc1-dummy] Error 1 make[3]: Leaving directory `/home/varie/gcc/work/src/build/gcc' make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory `/home/varie/gcc/work/src/build' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/home/varie/gcc/work/src/build' make: *** [all] Error 2 bootstrapping compiler: bash-4.0# gcc -v Using built-in specs. Target: powerpc-unknown-linux-gnu Configured with: ../gcc-4.4.0/configure --disable-multilib --prefix=/usr --libexecdir=/usr/lib --enable-languages=c,c++,objc --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-shared --disable-nls --with-x=no --enable-long-long --host=powerpc-unknown-linux-gnu --build=powerpc-unknown-linux-gnu --target=powerpc-unknown-linux-gnu Thread model: posix gcc version 4.4.0 (CRUX PPC) (GCC) and binutils-2.19.1 and glibc-2.10.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37739
[Bug rtl-optimization/39871] [4.3/4.4/4.5 regression] Code size increase on ARM due to inferior CSE
--- Comment #2 from mikpe at it dot uu dot se 2009-06-14 10:24 ---
(In reply to comment #1)
With 4.5 I see
With 4.5.0 I see:
push{lr}
sub sp, sp, #12
ldr r2, [r0]
ldr r1, [r0, #4]
mov r0, sp
str r2, [sp, #4]
bl func
add sp, sp, #12
pop {pc}
However, gcc-4.5-20090611 generates the longer 10-instruction code:
push{lr}
ldr r2, [r0]
sub sp, sp, #20
add r3, sp, #4
ldr r1, [r0, #4]
str r2, [r3, #4]
mov r0, r3
bl func
add sp, sp, #20
pop {pc}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39871
[Bug other/35151] Combine mingw names
--- Comment #5 from ktietz at gcc dot gnu dot org 2009-06-14 10:56 --- (In reply to comment #3) Subject: Bug 35151 Author: nickc Date: Fri Apr 4 11:16:10 2008 New Revision: 133892 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133892 Log: PR other/35151 * configure.ac: Combine rules for mingw32 and mingw64. * configure: Regenerate. Modified: trunk/ChangeLog trunk/configure trunk/configure.ac Was fixed. Therefore close it -- ktietz at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35151
[Bug other/40438] Internal error: Trace/BPT trap (program cc1obj)
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-06-14 11:26 --- dyld: Library not loaded: /usr/local/lib/libmpfr.1.dylib That means you have to set DYLD_LIBARY_PATH before building GCC as you installed libmpfr/libgmp in a different place than they are originally configured for. -- 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=40438
[Bug fortran/40168] missing unrolling/scalarization/reassoc/free
--- Comment #17 from rguenther at suse dot de 2009-06-14 12:31 --- Subject: Re: missing unrolling/scalarization/reassoc/free On Sat, 6 Jun 2009, jv244 at cam dot ac dot uk wrote: --- Comment #16 from jv244 at cam dot ac dot uk 2009-06-06 07:08 --- (In reply to comment #13) Subject: Bug 40168 Richard, this empty constructor patch was also OKed for 4.4 and has been on mainline for a while. http://gcc.gnu.org/ml/fortran/2009-05/msg00288.html Do you intend to commit this to 4.4.1? Yes, I had already bootstrapped tested the patch on the branch. I just didn't manage to find the time to commit it yet. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40168
[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P2 |P3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
[Bug testsuite/39537] overhaul printf formats and type casts in testsuite
--- Comment #7 from zorry at ume dot nu 2009-06-14 13:32 --- Gentoo's =gcc-4.3.3 is build with -Wformat and -Wformat-security enable to. -- zorry at ume dot nu changed: What|Removed |Added CC||zorry at ume dot nu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39537
[Bug fortran/40168] missing unrolling/scalarization/reassoc/free
--- Comment #18 from rguenth at gcc dot gnu dot org 2009-06-14 13:39 --- Subject: Bug 40168 Author: rguenth Date: Sun Jun 14 13:39:37 2009 New Revision: 148469 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148469 Log: 2009-06-14 Richard Guenther rguent...@suse.de Backport from mainline 2009-05-18 Richard Guenther rguent...@suse.de PR fortran/40168 * trans-expr.c (gfc_trans_zero_assign): For local array destinations use an assignment from an empty constructor. * gfortran.dg/array_memset_2.f90: Adjust. Modified: branches/gcc-4_4-branch/gcc/fortran/ChangeLog branches/gcc-4_4-branch/gcc/fortran/trans-expr.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/array_memset_2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40168
[Bug rtl-optimization/39871] [4.3/4.4/4.5 regression] Code size increase on ARM due to inferior CSE
--- Comment #3 from mikpe at it dot uu dot se 2009-06-14 14:06 ---
(In reply to comment #1)
With 4.5 I see
With 4.5.0 I see:
push{lr}
sub sp, sp, #12
ldr r2, [r0]
ldr r1, [r0, #4]
mov r0, sp
str r2, [sp, #4]
bl func
add sp, sp, #12
pop {pc}
I've tested every weekly gcc-4.5 snapshot and they all generate one instruction
more than this code.
How did you configure and invoke gcc-4.5 to get this 9-instruction code?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39871
[Bug testsuite/39537] overhaul printf formats and type casts in testsuite
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-06-14 14:42 --- In general patches need to be sent to gcc-patc...@gcc.gnu.org together with a ChangeLog entry following existing practice and a note how the patch was tested. Copyright assignment to the FSF is required for non-trivial patches, see also http://gcc.gnu.org/contribute.html. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39537
[Bug libstdc++/13631] Problems in messages
--- Comment #11 from mrsam at courier-mta dot com 2009-06-14 14:54 --- The first part of this bug can be solved by using dcgettext(). do_open() needs to save the text domain in the std::messages object, and do_get() needs to use it to invoke dgettext(). The patch appears to be straightforward. I have no idea about the second part of this bug. -- mrsam at courier-mta dot com changed: What|Removed |Added CC||mrsam at courier-mta dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13631
[Bug rtl-optimization/33928] [4.3/4.4/4.5 Regression] 30% performance slowdown in floating-point code caused by r118475
--- Comment #95 from lucier at math dot purdue dot edu 2009-06-14 14:59 --- The test case is compiler.i.gz -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
[Bug rtl-optimization/33928] [4.3/4.4/4.5 Regression] 30% performance slowdown in floating-point code caused by r118475
--- Comment #96 from lucier at math dot purdue dot edu 2009-06-14 15:02 --- Sorry, the gcc options are in comment 87 (the -fforward-propagate is now redundant), and without Paolo's recently proposed patch it requires about 9GB of memory to compile. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
[Bug c++/40389] optimizer bug (possibly)
--- Comment #23 from jason at redhat dot com 2009-06-14 15:39 --- Subject: Re: optimizer bug (possibly) On 06/13/2009 06:58 PM, rguenth at gcc dot gnu dot org wrote: * gimple.c (walk_stmt_load_store_addr_ops): The LHS of a call has its address taken if NRV was applied and it is addressable. This should check TREE_ADDRESSABLE on the type rather than the variable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40389
[Bug c++/40389] optimizer bug (possibly)
--- Comment #24 from jason at redhat dot com 2009-06-14 15:40 --- Subject: Re: optimizer bug (possibly) On 06/13/2009 06:58 PM, rguenth at gcc dot gnu dot org wrote: (handle_rhs_call): Use it to mark the return slot escaped if it is addressable and NRV was applied. Here too, of course. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40389
[Bug c++/40389] optimizer bug (possibly)
--- Comment #25 from rguenther at suse dot de 2009-06-14 15:41 --- Subject: Re: optimizer bug (possibly) On Sun, 14 Jun 2009, jason at redhat dot com wrote: --- Comment #23 from jason at redhat dot com 2009-06-14 15:39 --- Subject: Re: optimizer bug (possibly) On 06/13/2009 06:58 PM, rguenth at gcc dot gnu dot org wrote: * gimple.c (walk_stmt_load_store_addr_ops): The LHS of a call has its address taken if NRV was applied and it is addressable. This should check TREE_ADDRESSABLE on the type rather than the variable. For what middle-end semantics? I check TREE_ADDRESSABLE to leave it completely to the frontend if the LHS is addressable or not. So the frontend should only set it if the type is TREE_ADDRESSABLE then. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40389
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #33 from rguenth at gcc dot gnu dot org 2009-06-14 16:58 --- I am willing to help with analyzing/fixing middle-end problems with -fwhole-file, but it would be nice to have some of the progression pieces in trunk to do so ;) That said - I'm currently trying to hook up LTO for gfortran, which does seem to work for a simple two-file hello world. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug libstdc++/13631] Problems in messages
--- Comment #12 from mrsam at courier-mta dot com 2009-06-14 17:14 --- Created an attachment (id=17994) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17994action=view) Untested patch to fix the first issue Here's an untested patch to fix at least the first issue. I'll try to test it, as soon as I figure out the build system. Includes an soname bump. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13631
[Bug bootstrap/40439] New: Bootstrap broken on FreeBSD in tree.c
/usr/home/kargl/gcc/obj4x/./prev-gcc/xgcc -B/usr/home/kargl/gcc/obj4x/./prev-gcc/ -B/usr/home/kargl/work/i386-unknown-freebsd8.0/bin/ -B/usr/home/kargl/work/i386-unknown-freebsd8.0/bin/ -B/usr/home/kargl/work/i386-unknown-freebsd8.0/lib/ -isystem /usr/home/kargl/work/i386-unknown-freebsd8.0/include -isystem /usr/home/kargl/work/i386-unknown-freebsd8.0/sys-include-c -g -O2 -fomit-frame-pointer -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -Wc++-compat -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc4x/gcc -I../../gcc4x/gcc/. -I../../gcc4x/gcc/../include -I./../intl -I../../gcc4x/gcc/../libcpp/include -I/usr/local/include -I../../gcc4x/gcc/../libdecnumber -I../../gcc4x/gcc/../libdecnumber/dpd -I../libdecnumber../../gcc4x/gcc/tree.c -o tree.o cc1: warnings being treated as errors ../../gcc4x/gcc/tree.c: In function 'widest_int_cst_value': ../../gcc4x/gcc/tree.c:8502:10: error: left shift count = width of type gmake[3]: *** [tree.o] Error 1 gmake[3]: *** Waiting for unfinished jobs rm cpp.pod fsf-funding.pod gfdl.pod gcc.pod gfortran.pod gcov.pod gmake[3]: Leaving directory `/usr/home/kargl/gcc/obj4x/gcc' gmake[2]: *** [all-stage2-gcc] Error 2 gmake[2]: Leaving directory `/usr/home/kargl/gcc/obj4x' gmake[1]: *** [stage2-bubble] Error 2 gmake[1]: Leaving directory `/usr/home/kargl/gcc/obj4x' gmake: *** [bootstrap] Error 2 -- Summary: Bootstrap broken on FreeBSD in tree.c Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kargl at gcc dot gnu dot org GCC host triplet: i386-unknown-freebsd8.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40439
[Bug libstdc++/13631] Problems in messages
--- Comment #13 from rguenth at gcc dot gnu dot org 2009-06-14 17:56 --- We'll never accept an SONAME bump ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13631
[Bug bootstrap/40439] [4.5 Regression] Bootstrap broken on FreeBSD in tree.c
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||krebbel at gcc dot gnu dot ||org Summary|Bootstrap broken on FreeBSD |[4.5 Regression] Bootstrap |in tree.c |broken on FreeBSD in tree.c Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40439
[Bug bootstrap/40439] [4.5 Regression] Bootstrap broken on FreeBSD in tree.c
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-06-14 18:02 --- Sth like Index: gcc/tree.c === --- gcc/tree.c (revision 148472) +++ gcc/tree.c (working copy) @@ -8499,7 +8499,8 @@ widest_int_cst_value (const_tree x) #if HOST_BITS_PER_WIDEST_INT HOST_BITS_PER_WIDE_INT gcc_assert (HOST_BITS_PER_WIDEST_INT = 2 * HOST_BITS_PER_WIDE_INT); - val |= TREE_INT_CST_HIGH (x) HOST_BITS_PER_WIDE_INT; + val |= (((unsigned HOST_WIDEST_INT)TREE_INT_CST_HIGH (x)) + HOST_BITS_PER_WIDE_INT); #else /* Make sure the sign-extended value will fit in a HOST_WIDE_INT. */ gcc_assert (TREE_INT_CST_HIGH (x) == 0 should fix this. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|middle-end |bootstrap GCC host triplet||i386-unknown-freebsd8.0 GCC target triplet|i?86-*-*| Keywords|build | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40439
[Bug bootstrap/40439] [4.5 Regression] Bootstrap broken on FreeBSD in tree.c
--- Comment #2 from steven at gcc dot gnu dot org 2009-06-14 18:04 --- For reference: Broken by http://gcc.gnu.org/viewcvs?view=revrevision=148471 -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-06-14 18:04:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40439
[Bug bootstrap/40439] [4.5 Regression] Bootstrap broken on FreeBSD in tree.c
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-06-14 18:07 --- This only happens when host wide int is not 64bits (which it should be). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC host triplet|i386-unknown-freebsd8.0 | GCC target triplet||hwi == 32bits Keywords||build http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40439
[Bug libstdc++/13631] Problems in messages
--- Comment #14 from paolo dot carlini at oracle dot com 2009-06-14 18:25 --- That's true, unfortunately, not in the near future, anyway ;) In general, simple patches in this area managing (*) to not break the ABI would be rather quickly accepted, however. (*) When I say managing I mean it: rather dirty tricks are generally allowed, in *.cc files, at least. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13631
[Bug libstdc++/13631] Problems in messages
--- Comment #15 from mrsam at courier-mta dot com 2009-06-14 18:57 --- Although I'm the last person who'd shy away from dirty tricks, when it suits my purposes, I see none here. The catalog name received by open() needs to be stashed away somewhere, and passed as a parameter to dgettext(), by do_get(). That's the only way to eliminate the global reference, and I don't see any The only possibility I see is to define an entirely new, a replacement facet structure for std::messages, and somehow arrange newly-compiled code to bind to it, then keep both classes around. Existing code would continue to be bound to the old class, and newly-compiled code would then get bound to the new class. I'm not really familiar with the required compiler-fu that would be necessary to pull this off, though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13631
[Bug rtl-optimization/20070] If-conversion can't match equivalent code, and cross-jumping only works for literal matches
--- Comment #28 from steven at gcc dot gnu dot org 2009-06-14 19:54 --- Created an attachment (id=17995) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17995action=view) Patch agains r148322, works pre-RA only Joern's original ifcvt.c patch only dealt with pre-reload if-conversion. The subsequent changes to make struct-equiv work for crossjumping and after reload, made the code too complicated IMHO. So I've gone back to the roots of the patch. I've simplified things a bit -- mostly by using the DF machinery. This new attached patch is far from complete though. The struct-equiv code should use rtx_equal_p_cb, but the rtx_equal_p_cb needs to be modified first (to be more like for_each_rtx: 3-state and passing around a pointer to auxiliary data). The local_reg_p stuff should probably go into df-problems.c as a _p function. And so on. But the patch does work. I wanted to let folks now that this bug is not yet forgotten! -- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20070
[Bug fortran/40440] New: [4.5.0 Regression] Garbage or segmentation fault in allocatable array derived type structures
In derived type structures which are themselves array-valued garbage is stored and can produce segmentation faults. The behaviour seems erratic and not really reproduceable. The code makes use of the module iso_varying_string.f90 which can be found here (putting it in below would have exceeded the limit of 64 kb for the description): http://www.fortran.com/iso_varying_string.f95. Just compile the example below including iso_varying_string.o with 4.5.0 and run the binary. It shows where you should get garbage when using 4.5.0. I tried a stack trace and got this: Program received signal SIGABRT, Aborted. 0x2b51812c4ed5 in raise () from /lib/libc.so.6 Program received signal SIGABRT, Aborted. 0x2b166f232ed5 in raise () from /lib/libc.so.6 #0 0x2b166f232ed5 in raise () from /lib/libc.so.6 #1 0x2b166f2343f3 in abort () from /lib/libc.so.6 #2 0x2b166f26f3a8 in __libc_message () from /lib/libc.so.6 #3 0x2b166f274948 in malloc_printerr () from /lib/libc.so.6 #4 0x2b166f276a56 in free () from /lib/libc.so.6 #5 0x0040d380 in set_children.2047 () at syntax_rules.f90:752 #6 0x in ?? () The output with gfortran 4.3.1 and 4.4.0 is perfectly regular. CODE EXAMPLE: module ifiles use iso_varying_string, string_t = varying_string !NODEP! implicit none private public :: ifile_t public :: ifile_append public :: ifile_get_length public :: line_p public :: line_init public :: line_get_string_advance type :: line_entry_t private type(line_entry_t), pointer :: previous = null () type(line_entry_t), pointer :: next = null () type(string_t) :: string integer :: index end type line_entry_t type :: ifile_t private type(line_entry_t), pointer :: first = null () type(line_entry_t), pointer :: last = null () integer :: n_lines = 0 end type ifile_t type :: line_p private type(line_entry_t), pointer :: p = null () end type line_p interface ifile_append module procedure ifile_append_from_string module procedure ifile_append_from_char end interface contains subroutine line_entry_create (line, string) type(line_entry_t), pointer :: line type(string_t), intent(in) :: string allocate (line) line%string = string end subroutine line_entry_create subroutine ifile_append_from_string (ifile, string) type(ifile_t), intent(inout) :: ifile type(string_t), intent(in) :: string type(line_entry_t), pointer :: current call line_entry_create (current, string) current%index = ifile%n_lines + 1 if (associated (ifile%last)) then current%previous = ifile%last ifile%last%next = current else ifile%first = current end if ifile%last = current ifile%n_lines = current%index end subroutine ifile_append_from_string subroutine ifile_append_from_char (ifile, char) type(ifile_t), intent(inout) :: ifile character(*), intent(in) :: char call ifile_append_from_string (ifile, var_str (trim (char))) end subroutine ifile_append_from_char function ifile_get_length (ifile) result (length) integer :: length type(ifile_t), intent(in) :: ifile length = ifile%n_lines end function ifile_get_length subroutine line_init (line, ifile, back) type(line_p), intent(inout) :: line type(ifile_t), intent(in) :: ifile logical, intent(in), optional :: back if (present (back)) then if (back) then line%p = ifile%last else line%p = ifile%first end if else line%p = ifile%first end if end subroutine line_init subroutine line_advance (line) type(line_p), intent(inout) :: line if (associated (line%p)) line%p = line%p%next end subroutine line_advance function line_get_string_advance (line) result (string) type(string_t) :: string type(line_p), intent(inout) :: line if (associated (line%p)) then string = line%p%string call line_advance (line) else string = end if end function line_get_string_advance end module ifiles module syntax_rules use iso_fortran_env, only: STDERR = ERROR_UNIT use iso_varying_string, string_t = varying_string use ifiles, only: line_p, line_init, line_get_string_advance use ifiles, only: ifile_t, ifile_get_length implicit none private character, parameter, public :: BLANK = ' ', TAB = achar(9) character, parameter, public :: CR = achar(13), LF = achar(10) character(*), parameter, public :: WHITESPACE_CHARS = BLANK// TAB // CR // LF character(*), parameter, public :: LCLETTERS = abcdefghijklmnopqrstuvwxyz character(*), parameter, public :: UCLETTERS = ABCDEFGHIJKLMNOPQRSTUVWXYZ character(*), parameter, public :: DIGITS = 0123456789 character(*), parameter, public :: UNQUOTED = (),|_//LCLETTERS//UCLETTERS//DIGITS public :: S_UNKNOWN public :: S_KEYWORD public :: S_SEQUENCE public :: syntax_t public :: syntax_init
[Bug bootstrap/40439] [4.5 Regression] Bootstrap broken on FreeBSD in tree.c
--- Comment #4 from sgk at troutmask dot apl dot washington dot edu 2009-06-14 22:09 --- Subject: Re: [4.5 Regression] Bootstrap broken on FreeBSD in tree.c On Sun, Jun 14, 2009 at 06:02:26PM -, rguenth at gcc dot gnu dot org wrote: --- Comment #1 from rguenth at gcc dot gnu dot org 2009-06-14 18:02 --- Sth like Index: gcc/tree.c === --- gcc/tree.c (revision 148472) +++ gcc/tree.c (working copy) @@ -8499,7 +8499,8 @@ widest_int_cst_value (const_tree x) #if HOST_BITS_PER_WIDEST_INT HOST_BITS_PER_WIDE_INT gcc_assert (HOST_BITS_PER_WIDEST_INT = 2 * HOST_BITS_PER_WIDE_INT); - val |= TREE_INT_CST_HIGH (x) HOST_BITS_PER_WIDE_INT; + val |= (((unsigned HOST_WIDEST_INT)TREE_INT_CST_HIGH (x)) + HOST_BITS_PER_WIDE_INT); #else /* Make sure the sign-extended value will fit in a HOST_WIDE_INT. */ gcc_assert (TREE_INT_CST_HIGH (x) == 0 should fix this. The above patch fixes bootstrap. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40439
[Bug fortran/40440] [4.5.0 Regression] Garbage or segmentation fault in allocatable array derived type structures
--- Comment #1 from kargl at gcc dot gnu dot org 2009-06-14 22:14 --- Please add your code as an attachment. The severity of fortran bugs are never major unless the bug breaks bootstrap. Adjusted severity to normal. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40440
[Bug fortran/40440] [4.5.0 Regression] Garbage or segmentation fault in allocatable array derived type structures
--- Comment #2 from juergen dot reuter at desy dot de 2009-06-14 22:18 --- Created an attachment (id=17996) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17996action=view) contains modules iso_varying_string, ifiles, syntax_rules and main test program COmplete code for the test case including the module iso_varying_string -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40440
[Bug c/40441] New: UTF-8 signature support
UTF-8 signature is the UTF-8 character 'ef bb bf' at the start of a .cpp .c file. When you edit a UTF-8 file with notepad, it also put the signature at the start of the file. Microsoft Visual Studio 2008 C++ compiler reads this to detect the encoding of a text file. Without this signature, a UTF-8 const string literal with chinese characters is not read correctly in Visual C++. Please skip the 'EF BB BF' at the start of a .cpp .c file. Currently this signature causes compilation errors on GCC. Add this feature will easy the porting of WIN32 software to GCC. -- Summary: UTF-8 signature support Product: gcc Version: 4.2.3 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dh dot liu at msa dot hinet dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40441
[Bug c/40441] UTF-8 signature support
--- Comment #1 from dh dot liu at msa dot hinet dot net 2009-06-14 22:58 --- Created an attachment (id=17997) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17997action=view) the binary UTF-8 signature -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40441
[Bug preprocessor/33415] Can't compile .cpp file with UTF-8 BOM.
--- Comment #7 from jsm28 at gcc dot gnu dot org 2009-06-14 23:03 --- *** Bug 40441 has been marked as a duplicate of this bug. *** -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added CC||dh dot liu at msa dot hinet ||dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33415
[Bug c/40441] UTF-8 signature support
--- Comment #2 from jsm28 at gcc dot gnu dot org 2009-06-14 23:03 --- This was fixed for 4.4. *** This bug has been marked as a duplicate of 33415 *** -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40441
[Bug c/40442] New: Option -I and POSIX conformance (c99 utility)
GCC doesn't seem to provide a c99 utility, but some vendors provide one based on gcc. And the GCC behavior can make POSIX conformance difficult to obtain. Here's the difference. POSIX.1-2008 says[*]: -I directory Change the algorithm for searching for headers whose names are not absolute pathnames to look in the directory named by the directory pathname before looking in the usual places. Thus, headers whose names are enclosed in double-quotes ( ) shall be searched for first in the directory of the file with the #include line, then in directories named in -I options, and last in the usual places. For headers whose names are enclosed in angle brackets ( ), the header shall be searched for only in directories named in -I options and then in the usual places. Directories named in -I options shall be searched in the order specified. Implementations shall support at least ten instances of this option in a single c99 command invocation. [*] http://www.opengroup.org/onlinepubs/9699919799/utilities/c99.html So, the directories specified by -I should have the precedence over the usual places. However, this is not the behavior of gcc; from the gcc 4.3.2 man page: -I dir Add the directory dir to the list of directories to be searched for header files. Directories named by -I are searched before the standard system include directories. If the directory dir is a standard system include directory, the option is ignored to ensure that the default search order for system directories and the special treatment of system headers are not defeated . If dir begins with =, then the = will be replaced by the sysroot prefix; see --sysroot and -isysroot. As you can see, there is a difference for standard system include directories, for which the option is ignored. I suggest that GCC adds a new option to switch to the POSIX specifications. FYI, I've reported the bug against Debian here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=533124 -- Summary: Option -I and POSIX conformance (c99 utility) Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: vincent at vinc17 dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40442
[Bug c/40442] Option -I and POSIX conformance (c99 utility)
--- Comment #1 from joseph at codesourcery dot com 2009-06-15 01:01 --- Subject: Re: New: Option -I and POSIX conformance (c99 utility) On Mon, 15 Jun 2009, vincent at vinc17 dot org wrote: As you can see, there is a difference for standard system include directories, for which the option is ignored. This sounds like it is mainly a defect in POSIX; it should make it undefined behavior if you pass a -I option pointing to any directory that contains a file with the same name as any standard header (recall that standard headers do not need to correspond to physical files with the same name). Changing the search order of system directories is clearly liable to break any implementation that deliberately has more than one file of a name for some reason (maybe GCC's limits.h and glibc's version can cope with either order of inclusion, but I see no reason for a requirement for implementations to follow that), and pointing to a user's own file with the same name as a standard header is bound to cause breakage. C99 has such an undefined behavior rule in 7.1.2#3; POSIX just needs to extend it to the POSIX system headers as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40442
[Bug fortran/40443] New: Elemental procedure in genericl interface incorrectly selected in preference to specific procedure
F95 standard section 14.1.2.4.1 (particular Note 14.6) implies to me that when an elemental and a non-elemental specific procedure in a generic interface both match a reference, it is the specific instance that should be selected. The reference selected by gfortran appears to depend on the ordering of procedures in the generic interface block. I'd expect the last line of output from the following to be S, S as a result of selecting the specific procedure SpecProc. I get E, E which has come from the elemental procedure. MODULE SomeOptions IMPLICIT NONE INTERFACE ElemSpec MODULE PROCEDURE ElemProc MODULE PROCEDURE SpecProc END INTERFACE ElemSpec INTERFACE SpecElem MODULE PROCEDURE SpecProc MODULE PROCEDURE ElemProc END INTERFACE SpecElem CONTAINS ELEMENTAL SUBROUTINE ElemProc(a) CHARACTER, INTENT(OUT) :: a ! a = 'E' END SUBROUTINE ElemProc SUBROUTINE SpecProc(a) CHARACTER, INTENT(OUT) :: a(:) ! a = 'S' END SUBROUTINE SpecProc END MODULE SomeOptions PROGRAM MakeAChoice USE SomeOptions IMPLICIT NONE CHARACTER scalar, array(2) ! CALL ElemSpec(scalar) ! Should choose the elemental (and does) WRITE (*, 100) scalar CALL ElemSpec(array) ! Should choose the specific (and does) WRITE (*, 100) array ! CALL SpecElem(scalar) ! Should choose the elemental (and does) WRITE (*, 100) scalar CALL SpecElem(array) ! Should choose the specific (but doesn't) WRITE (*, 100) array ! 100 FORMAT(A,:,', ',A) END PROGRAM MakeAChoice gfortran --version GNU Fortran (GCC) 4.5.0 20090421 (experimental) [trunk revision 146519] -- Summary: Elemental procedure in genericl interface incorrectly selected in preference to specific procedure Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ian_harvey at bigpond dot com GCC build triplet: i586-pc-mingw32 GCC host triplet: i586-pc-mingw32 GCC target triplet: i586-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40443
[Bug c/40442] Option -I and POSIX conformance (c99 utility)
--- Comment #2 from vincent at vinc17 dot org 2009-06-15 02:08 ---
This may be true for standard headers, but system directories don't contain
only standard headers: in practice, they generally also contain additional
libraries. And for instance, a -I/usr/include can be useful to override
headers/libraries installed in /usr/local/{include,lib}.
Then perhaps gcc (and POSIX) should make a difference between standard headers
and other headers.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40442
[Bug target/40416] unnecessary register spill
--- Comment #3 from carrot at google dot com 2009-06-15 02:26 ---
Created an attachment (id=17998)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17998action=view)
preprocessed test case
A possible code sequence without spilling is:
push{r4, r5, r6, r7, lr}
add r6, r1, r2
mov r4, r0
lsl r7, r2, 1 // New
add r0, r0, r7// New
.loc 1 8 0
b .L2
.L5:
.loc 1 10 0
mov r7, #0
ldrsh r5, [r4, r7]
.loc 1 12 0
cmp r2, r5
bge .L3
.loc 1 14 0
ldrbr7, [r1]
strbr7, [r1, r2]
.loc 1 15 0
strhr2, [r4]
.loc 1 16 0
lsl r1, r2, #1
sub r2, r5, r2
strhr2, [r1, r4]
.L6:
.loc 1 5 0
b .L4
.L3:
.loc 1 19 0
lsl r7, r5, #1
mov ip, r7
add r4, r4, ip
.loc 1 20 0
add r1, r1, r5
.loc 1 21 0
sub r2, r2, r5
.L2:
.loc 1 8 0
cmp r2, #0
bgt .L5
b .L6
.L4:
.loc 1 30 0
mov r1, #0
--
carrot at google dot com changed:
What|Removed |Added
Attachment #17983|0 |1
is obsolete||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40416
[Bug target/40416] unnecessary register spill
--- Comment #4 from carrot at google dot com 2009-06-15 02:32 --- In the source code, only two extra variables next_runs and next_alpha need to be preserved through the while loop. But in the gcc generated code, three variables are kept through the first loop. They are next_alpha, original runs and original x. The expression (next_runs = runs + x) is moved after the loop. This caused an extra var through the loop and resulted in register spilling. The expression move is occurred in tree-ssa-sink pass. Daniel Berlin has confirmed it is a bug in this pass. From Daniel ** This looks like a bug, i think i know what causes it. When I wrote this pass, i forgot to make this check: /* It doesn't make sense to move to a dominator that post-dominates frombb, because it means we've just moved it into a path that always executes if frombb executes, instead of reducing the number of executions . */ if (dominated_by_p (CDI_POST_DOMINATORS, frombb, commondom)) happen regardless of whether it is a single use statement or not. So it will sink single use statements even if it's just moving them to places that aren't executed less frequently. Add that check (changing commondom to sinkbb) and it should stop moving it. *** End From Daniel I will send the patch later. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40416
[Bug target/40424] --verbose-asm option not list all enbaled command line option flags
--- Comment #4 from MR dot Swami dot Reddy at nsc dot com 2009-06-15 05:02 --- Created an attachment (id=17999) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17999action=view) Patch to fix this issue -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40424
[Bug target/40424] --verbose-asm option not list all enbaled command line option flags
--- Comment #5 from MR dot Swami dot Reddy at nsc dot com 2009-06-15 05:03 --- Created an attachment (id=18000) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18000action=view) Patch to fix this issue -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40424
