[Bug rtl-optimization/42269] [4.4/4.5 Regression] Extra sign extension instructions generated
--- Comment #7 from ubizjak at gmail dot com 2009-12-09 08:28 --- Fixed by: Author: rth Date: Tue Dec 8 23:39:20 2009 New Revision: 155095 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155095 Log: * combine.c (setup_incoming_promotions): Fix sign-extend of zero-extend case; tidy conditions. Modified: trunk/gcc/ChangeLog trunk/gcc/combine.c -- ubizjak at gmail dot com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42269
[Bug other/42333] complex division failure on darwin10 with -lm
--- Comment #19 from dominiq at lps dot ens dot fr 2009-12-09 09:31 --- As far as generation of a test case is concerned - why not just use the asm generated by 4.5? I did that and the assembly generated on darwin10 works fine on darwin9. I can fill a bug report to Apple to know if its a bug (regression) or a feature. On what to do about builtin-math-7.c testcase, my inclination is we should just XFAIL it for darwin10 since fixing darwin's ___divdc3 won't help with distributions out in the field. For the moment I'll prefer to keep the failure until the use of -lm in the testsuite is clarified: My understanding of the testsuite is that it is supposed to check that the gcc compilers are working as expected on a given target. Does it make any sense to pass the tests with -lm when it is not used in normal use of the compilers? If yes, why? If no, what must be changed in gcc to run the testsuite (at least on Darwin) without adding -lm to the tests? (see also related questions in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473#c87). I am planning to ask these question in the gcc list, but I won't have much time to do it before this evening, so if someone want to beat me for it, he is welcome! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333
[Bug middle-end/42339] New: [graphite] Autopar on SPEC 2006 fails
gcc.gnu.org/svn/gcc/tr...@154983 Linux 2.6.22.17-0.1-default #1 SMP x86_64 x86_64 x86_64 GNU/Linux ../../git_trunk/configure --disable-bootstrap --enable-languages=c,c++,fortran --with-cloog=/home/grosser/gcc/tools/bin/cloog-ppl-old --with-ppl=/home/grosser/gcc/tools/bin/ppl --with-gmp=/usr/local --with-mpfr=/home/grosser/gcc/tools/bin/mpfr --prefix=/home/grosser/gcc/gcc/install/trunk-old base flags: -O2 -fno-loop-block -fno-loop-strip-mine peak flags: -O2 -fno-loop-block -fno-loop-strip-mine -ftree-parallelize-loops=4 -floop-parallelize-all What I get: 1. perlbench and cactusADM have a runtime error with autopar enabled 2. gcc goes in an invinite loop. All the other benchmarks work, but do not have any performance differences. -- Summary: [graphite] Autopar on SPEC 2006 fails Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: grosser at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42339
[Bug c++/42338] [c++0x] ICE on decltype usage with templates
--- Comment #1 from paolo dot carlini at oracle dot com 2009-12-09 09:50 --- Jason, the ICE happens in mangle.c, write_expression gets a null argument. Is this another variant of c++/38600 and the likes? -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||jason at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42338
[Bug c++/42336] [c++0x] ICE with pointer-to-member-function decltype argument in template function
--- Comment #1 from paolo dot carlini at oracle dot com 2009-12-09 09:53 --- This one happens *only* with -O2 and -g, should be recategorized as debug and/or optimization? Thanks for any help triaging it... -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||aoliva at gcc dot gnu dot ||org, jason at gcc dot gnu ||dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42336
[Bug c++/42340] New: templated member func vanish from assembler code when -O2 is used
Using the below code snipped (bug.C), and compiling it using:
gcc -Wall -O2 -save-temps -c -o bug.o bug.C
causes _ZN1B1fIiEEvPT_ to disappear from the .s-file, and later on breaking the
link. Using -O1 works fine.
bug.C
struct B {
template class T void f(T * t);
void dummyInst();
};
template class T void
B::f(T * t)
{
}
void
B::dummyInst() {
f((int*)0);
}
--
Summary: templated member func vanish from assembler code when -
O2 is used
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jaeschke at de dot ibm dot com
GCC build triplet: i486-linux-gnu
GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42340
[Bug c++/42340] templated member func vanish from assembler code when -O2 is used
--- Comment #1 from paolo dot carlini at oracle dot com 2009-12-09 11:08 --- I'm seeing this happening in 4.3.x too, isn't new in 4.4.x. Now, I'm not sure to understand which is the problem: indeed, it disappears, but it's also true that nothing calls it. I would ask you to provide a short testcase which doesn't link anymore and was fine before (4.2.x?). Thanks. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42340
[Bug tree-optimization/42341] New: ICE in insert_value_copy_on_edge, at tree-outof-ssa.c:228
Attached object file crashes with lto compilation on alphaev68 cross:
~/gcc-build-alpha/gcc/lto1 -O0 c_lto_20090116_0.o
Performing interprocedural optimizations
whole-program inlineAssembling functions:
foo
In file included from :0:0:
/home/uros/gcc-svn/trunk/gcc/testsuite/gcc.dg/lto/20090116_0.c: In function
foo:
/home/uros/gcc-svn/trunk/gcc/testsuite/gcc.dg/lto/20090116_0.c:5:5: internal
compiler error: in insert_value_copy_on_edge, at tree-outof-ssa.c:228
Please submit a full bug report,
...
Breakpoint 1, fancy_abort (
file=0xa6fa28 ../../gcc-svn/trunk/gcc/tree-outof-ssa.c, line=228,
function=0xa6ff50 insert_value_copy_on_edge)
at ../../gcc-svn/trunk/gcc/diagnostic.c:727
727 {
(gdb) bt
#0 fancy_abort (file=0xa6fa28 ../../gcc-svn/trunk/gcc/tree-outof-ssa.c,
line=228, function=0xa6ff50 insert_value_copy_on_edge)
at ../../gcc-svn/trunk/gcc/diagnostic.c:727
#1 0x0076b1a5 in insert_value_copy_on_edge (e=0x2b72551e7040, dest=1,
src=0x2b7255135c58, locus=147)
at ../../gcc-svn/trunk/gcc/tree-outof-ssa.c:228
#2 0x0076c835 in eliminate_phi (e=0x2b72551e7040, g=0x102c9f0)
at ../../gcc-svn/trunk/gcc/tree-outof-ssa.c:678
#3 0x0076cf94 in expand_phi_nodes (sa=0xd8b820)
at ../../gcc-svn/trunk/gcc/tree-outof-ssa.c:840
#4 0x004bd201 in gimple_expand_cfg ()
at ../../gcc-svn/trunk/gcc/cfgexpand.c:3585
#5 0x00677919 in execute_one_pass (pass=0xd4d5e0)
at ../../gcc-svn/trunk/gcc/passes.c:1543
(gdb) up
#1 0x0076b1a5 in insert_value_copy_on_edge (e=0x2b72551e7040, dest=1,
src=0x2b7255135c58, locus=147)
at ../../gcc-svn/trunk/gcc/tree-outof-ssa.c:228
228 gcc_assert (dest_mode == GET_MODE (SA.partition_to_pseudo[dest]));
(gdb) p dest_mode
$1 = DImode
(gdb) p SA.partition_to_pseudo[dest]
$2 = (rtx) 0x2b72551df240
(gdb) p debug_rtx (SA.partition_to_pseudo[dest])
(mem/c/i:SI (plus:DI (reg/f:DI 65 virtual-stack-vars)
(const_int 4 [0x4])) [0 i+0 S4 A32])
$3 = void
This is reproductable with a cross to alpha-linux-elf.
--
Summary: ICE in insert_value_copy_on_edge, at tree-outof-
ssa.c:228
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ubizjak at gmail dot com
GCC build triplet: x86_64-pc-linux-gnu
GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: alphaev68-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42341
[Bug tree-optimization/42341] ICE in insert_value_copy_on_edge, at tree-outof-ssa.c:228
--- Comment #1 from ubizjak at gmail dot com 2009-12-09 11:22 --- Created an attachment (id=19264) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19264action=view) Object file that triggers the ICE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42341
[Bug ada/42342] New: Please clarify the rules regarding relationships between project files
(Forwarding and rephrasing http://bugs.debian.org/559447) The GNAT project manager has the concepts of project files and library project file; a library project file is one that has the two attributes Library_Name and Library_Dir; it can also have additional attributes like Library_ALI_Dir which is what triggered the bug. The GNAT project manager also has the concepts of project file extensions, virtual extensions and the with keyword which define two kinds of relationships between packages (a virtual extension creates extends relationahips across an entire project tree). The documentation is unclear about the interactions between the two kinds of project files and the two kinds of relationships. application project with application project: OK application project with library project: OK application project extends library project: ERROR (1) application project extends application project: OK library project with application project: ERROR (2) library project with library project: OK library project extends library project: OK (3) library project extends application project: ERROR (4) (1) unless the application project recompiles the entire library, without -fPIC, into the executables, which defeats the purpose of a library entirely (2) unless the library project recompiles the application sources, with -fPIC if dynamic library, into its own Object_Dir and Library_ALI_Dir, which defeats the purpose of the application project (3) the extension replaces the parent, i.e. it creates a new library that includes the object files of both the parent and of the extension; the extension may replace some of the sources, objects and ALI files of the parent with its own, as well as add new ones. Consequently, the extension has its own Library_Name, Library_Dir, Object_Dir and Library_ALI_Dir that are necessarily different from the ones of the parent. This is incompatible with extends all because extends all does not allow redefining these attributes. (4) unless the library project recompiles all the application's source files, with -fPIC if dynamic library, into its own Object_Dir, which defeats the purpose of the application project I think that GNAT should diagnose the errors (1), (2) and (4) and additionally the error of applying extends all to a library project as in this example: project Foo is -- library project for Library_Name use foo; for Library_Dir use /usr/bin; for Library_Kind use dynamic; for Source_Dirs use (/usr/share/ada/adainclude/foo); for Library_ALI_Dir use /usr/lib/ada/adalib/foo; for Externally_Built use true; end Foo; with foo; project Parent is end Parent; project Extension extends all parent; -- error (3) end Extension; Could someone please comment on the above? There seems to be another, more trivial, bug in the project manager: the virtual extension of Foo seems to inherit the Library_Dir but not the Library_ALI_Dir. Consequently, GNAT looks for the ALI files in /usr/lib instead of /usr/lib/ada/adalib/foo and fails. -- Summary: Please clarify the rules regarding relationships between project files Product: gcc Version: 4.4.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ludovic at ludovic-brenta dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42342
[Bug c++/42340] templated member func vanish from assembler code when -O2 is used
--- Comment #2 from redi at gcc dot gnu dot org 2009-12-09 11:29 --- If another translation unit is relying on finding an instantiation in bug.o then you should use an explicit instantiation to ensure it is present, or the other translation unit should include the definition of B::f -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42340
[Bug c++/42340] templated member func vanish from assembler code when -O2 is used
--- Comment #3 from paolo dot carlini at oracle dot com 2009-12-09 11:34 --- This is expected, any optimizing compiler (e.g., ICC behaves the same as GCC) will get rid of that implicit instantiation, while inlining. Really, this is not going to change. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42340
[Bug tree-optimization/42341] ICE in insert_value_copy_on_edge, at tree-outof-ssa.c:228
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-12-09 11:35 --- How was the object file built? (I suppose this is simply a testsuite failure of gcc.dg/lto/20090116?) There was a dup for this for other archs I believe and the issue is basically -Ox vs. -O0 compile which breaks some out-of-SSA invariants. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Keywords||lto http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42341
[Bug other/42333] complex division failure on darwin10 with -lm
--- Comment #20 from developer at sandoe-acoustics dot co dot uk
2009-12-09 11:37 ---
(In reply to comment #17)
(In reply to comment #15)
(In reply to comment #13)
You can try filing a bug report at Apple, but I think a better route
would be
to see if we can avoid linking in the system ___divdc3 from FSF GCC.
Summary (for Dominique's test case):
working [regardless of placement of -lm]:
Darwin 9 [ppc/i686]
Apple 4.0,4.2
FSF 4.5
Darwin 10
Apple 4.0, 4.2
FSF 4.5 without -lm
FSF 4.5 fails with the placement of -lm (which causes linkage of
/usr/lib/libSystem version of ___divdc3)
the latter can be emulated using Apple's 4.2 by compiling the asm output from
FSF 4.5 for Dominique's test case.
So; Apple's two compilers that produce in-line code for ___divdc3 are
apparently 'doing the right thing' (in spite of your concern about potential
optimization issues). We might look at porting the relevant .md sections to
FSF ...
The regression is in the library version of ___divdc3 supplied in Darwin10
(i.e. nothing to do with FSF gcc); This could be radared (although as you say
there is not much motivation to fix something that is unused).
I repeat my earlier question:
Why is -lm being used for this test case?
Darwin, AFAIR, does not use -lm . { see comment in gcc/config/darwin.h #define
MATH_LIBRARY }
(of course, one could argue that it should be harmless, in an ideal world)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333
[Bug other/42333] complex division failure on darwin10 with -lm
--- Comment #21 from rguenth at gcc dot gnu dot org 2009-12-09 11:42 --- As a workaround in gcc I suggest to strip -lm in the darwin specific specs processing. Otherwise this is not a GCC bug (again), but a darwin bug - why do they always creep into gcc bugzilla ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333
[Bug fortran/38913] Fortran does not set TYPE_CANONICAL properly
--- Comment #18 from jv244 at cam dot ac dot uk 2009-12-09 11:49 --- still fails with current trunk -- jv244 at cam dot ac dot uk changed: What|Removed |Added Last reconfirmed|2009-09-22 15:44:58 |2009-12-09 11:49:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38913
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #51 from jv244 at cam dot ac dot uk 2009-12-09 11:50 --- still failing with current trunk, also leading to miscomples (see PR38913). As a consequence, should one disable -fwhole-file (and consequently -flto) for Fortran before release? -- jv244 at cam dot ac dot uk changed: What|Removed |Added Last reconfirmed|2009-05-04 09:10:10 |2009-12-09 11:50:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #52 from rguenther at suse dot de 2009-12-09 11:52 --- Subject: Re: Problems with -fwhole-file On Wed, 9 Dec 2009, jv244 at cam dot ac dot uk wrote: --- Comment #51 from jv244 at cam dot ac dot uk 2009-12-09 11:50 --- still failing with current trunk, also leading to miscomples (see PR38913). As a consequence, should one disable -fwhole-file (and consequently -flto) for Fortran before release? As neither is enabled by default I instead recommend to document the experimental status instead. Note that -flto works around most of the frontend issues by performing its own type and decl unification. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug tree-optimization/42341] ICE in insert_value_copy_on_edge, at tree-outof-ssa.c:228
--- Comment #3 from ubizjak at gmail dot com 2009-12-09 13:03 --- (In reply to comment #2) How was the object file built? (I suppose this is simply a testsuite failure of gcc.dg/lto/20090116?) There was a dup for this for other archs I believe and the issue is basically -Ox vs. -O0 compile which breaks some out-of-SSA invariants. Yes, it was built with: /home/uros/gcc-build-alpha/gcc/xgcc -B/home/uros/gcc-build-alpha/gcc/ -O1 -fwhopr -fPIC -c -o c_lto_20090116_0.o /home/uros/gcc-svn/trunk/gcc/testsuite/gcc.dg/lto/20090116_0.c (I'm not aware of any similar bugreport). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42341
[Bug bootstrap/37079] cannot find -lgcc_s
--- Comment #8 from 3dw4rd at verizon dot net 2009-12-09 13:22 --- Subject: Re: cannot find -lgcc_s howarth at nitro dot med dot uc dot edu wrote: --- Comment #7 from howarth at nitro dot med dot uc dot edu 2009-12-09 04:21 --- (In reply to comment #6) I have this problem of MacOSX 10.3 $ gcc -v Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs Thread model: posix gcc version 3.3 20030304 (Apple Computer, Inc. build 1671) When I do a make on an empty directory it gets all the way into stage3 linking libstdc++ until this: /usr/bin/ld: can't locate file for: -lgcc_s.10.4 There are several libgcc_s around: MacOSX:~/obj ed$ find . -name libgcc_s\* ./gcc/libgcc_s.1.dylib ./gcc/libgcc_s_ppc64.1.dylib ./gcc/libgcc_s_x86_64.1.dylib ./powerpc-apple-darwin7.9.0/libgcc/libgcc_s.1.dylib ./powerpc-apple-darwin7.9.0/libgcc/libgcc_s.dylib ./prev-gcc/libgcc_s.1.dylib ./prev-gcc/libgcc_s_ppc64.1.dylib ./prev-gcc/libgcc_s_x86_64.1.dylib ./prev-powerpc-apple-darwin7.9.0/libgcc/libgcc_s.1.dylib ./prev-powerpc-apple-darwin7.9.0/libgcc/libgcc_s.dylib ./stage1-gcc/libgcc_s.1.dylib ./stage1-gcc/libgcc_s_ppc64.1.dylib ./stage1-gcc/libgcc_s_x86_64.1.dylib ./stage1-powerpc-apple-darwin7.9.0/libgcc/libgcc_s.1.dylib ./stage1-powerpc-apple-darwin7.9.0/libgcc/libgcc_s.dylib I'm actually surprised by the ppc64 and x86_64 libs - I'm not building a cross compiler. I would be shocked if gcc trunk built on darwin7. Unless I am mistaken, we now assume that all darwin targets support dwarf which isn't the default case until Xcode 2.4 (10.4). I've been bootstrapping trunk happily up till about a couple months ago: 10.15.2009. Also, I've noticed a lot of issues with libgcc_s on other targets. It looks like a build system change. Is there a way to get the SVN version of a gcc? I remember some discussion of that way back. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37079
[Bug debug/41679] [4.5 Regression] internal compiler error: in loc_cmp, at var-tracking.c:2433
--- Comment #7 from kedars at marvell dot com 2009-12-09 13:29 --- Applied the three patches. These DO fix the issue mentioned above. Is it safe to continue using these patches in gcc until the next stable release arrives? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41679
[Bug bootstrap/42343] New: gcc 3.2.x fails to build with current gcc versions
When trying to build gcc 3.2.3 (or gcc-3_2-branch) with a less outdated version of gcc [unfortunately, this is sometimes necessary to build a matching compiler for an embedded device...], gcc barfs on the use of trigraphs as lvalues. I'm attaching patches to fix this; chances are it's too late to get them info the 3.2 branch, but maybe the report (and patches) will help others running into this. -- Summary: gcc 3.2.x fails to build with current gcc versions Product: gcc Version: 3.2.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bero at arklinux dot org GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: arm920t-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42343
[Bug bootstrap/42343] gcc 3.2.x fails to build with current gcc versions
--- Comment #1 from bero at arklinux dot org 2009-12-09 13:55 --- Created an attachment (id=19265) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19265action=view) Fix for obstack.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42343
[Bug bootstrap/42343] gcc 3.2.x fails to build with current gcc versions
--- Comment #2 from bero at arklinux dot org 2009-12-09 13:56 --- Created an attachment (id=19266) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19266action=view) Fix for decl.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42343
[Bug tree-optimization/42284] failing tree check in graphite-sese-to-poly.c for 164.gzip
-- spop at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |spop at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-12-09 14:26:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42284
[Bug tree-optimization/42285] ICE in Graphite's scan_tree_for_params for 416.gamess
--- Comment #4 from spop at gcc dot gnu dot org 2009-12-09 15:18 --- Subject: Bug 42285 Author: spop Date: Wed Dec 9 15:18:22 2009 New Revision: 155108 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155108 Log: Fix PR42285. 2009-12-08 Sebastian Pop seb...@gmail.com PR middle-end/42285 * graphite-scop-detection.c (graphite_can_represent_init): Also handle more complex MULT_EXPRs containing parameters by recursion on the structure. * testsuite/gfortran.dg/graphite/pr42285.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/graphite/pr42285.f90 Modified: trunk/gcc/ChangeLog.graphite trunk/gcc/graphite-scop-detection.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42285
[Bug other/42333] complex division failure on darwin10 with -lm
--- Comment #22 from developer at sandoe-acoustics dot co dot uk
2009-12-09 15:21 ---
(In reply to comment #21)
As a workaround in gcc I suggest to strip -lm in the darwin specific specs
one could also suggest the following patch to unix.exp (or providing a darwin
infrastructure):
@@ -30,8 +30,8 @@
#set_board_info host_library_path [file dirname [file dirname [file dirname
[file dirname [file dirname [exec [find_gcc] --print-prog-name=cc1]]/lib
-# Do not use -lm on Cygwin
-if { [istarget *-*-cygwin*] } {
+# Do not use -lm on Cygwin or Darwin
+if { [istarget *-*-cygwin*] || [istarget *-*-darwin*] } {
set_board_info mathlib
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333
[Bug bootstrap/42343] gcc 3.2.x fails to build with current gcc versions
--- Comment #3 from ramana at gcc dot gnu dot org 2009-12-09 15:35 --- Bugzilla is for trunk and the currently maintained release branches. gcc 3.2 is no longer actively maintained. Ramana -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Priority|P3 |P5 Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42343
[Bug rtl-optimization/42226] [missed optimization] inefficient byte access when -Os is specified
--- Comment #3 from ramana at gcc dot gnu dot org 2009-12-09 15:48 --- Only with trunk - this is a performance and size regression. The correct answer might be to define thumb1 specific size costs . At the minute thumb1_rtx_costs is used for both speed and size. -- ramana 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-12-09 15:48:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42226
[Bug c/41797] Segmentation fault on compiling using pre-compiled headers
--- Comment #4 from ramana at gcc dot gnu dot org 2009-12-09 16:04 --- Do you still see this problem ? Can you provide a backtrace or some more information about this one ? I don't see this as of 4.4 from yesterday. mkdir test.gch gcc -x c-header -marm -fmem-report -ftime-report -c -march=armv5te test.h -o test.gch/c Memory still allocated at the end of the compilation process Size AllocatedUsedOverhead 8 81925856 192 128 156k153k 1404 256 40962048 32 512 40961536 32 102440963072 32 2048 32k 32k256 4096 20k 20k160 8192 16k 16k 64 65536 64k 64k 32 104 68k 66k612 96 4096 96 36 80 4096 160 36 5688k 86k880 88 4096 176 36 64 40961984 40 32 168k166k 2016 40 81924920 88 1624k 20k384 48 40961008 40 Total684k645k 6372 String pool entries 1574 identifiers 1574 (100.00%) slots 16384 deleted 0 bytes 21k (4095M overhead) table size 64k coll/search 0.0573 ins/search 0.7274 avg. entry 14.01 bytes (+/- 7.79) longest entry 45 ??? tree nodes created (No per-node statistics) Type hash: size 1021, 286 elements, 0.295706 collisions DECL_DEBUG_EXPR hash: size 1021, 0 elements, 0.00 collisions DECL_VALUE_EXPR hash: size 1021, 0 elements, 0.00 collisions No gimple statistics Execution times (seconds) parser: 0.09 (75%) usr 0.01 (100%) sys 0.32 (73%) wall 104 kB (17%) ggc TOTAL : 0.12 0.01 0.44 617 kB gcc -c -marm -fmem-report -ftime-report -march=armv5te -include test test.c Memory still allocated at the end of the compilation process Size AllocatedUsedOverhead 8228k224k 5440 128 1216k 1112k 9728 256 940k681k 7520 512 164k 70k 1312 10242064k 2062k 16k 2048 636k634k 4864 40961308k156k 10k 8192 96k 88k352 16384912k 80k 1824 32768192k128k192 65536192k192k 96 131072128k 0 32 262144256k256k 32 104 1232k 1216k 10k 96 152k149k 1368 80 2368k 2356k 20k 56 3408k 3399k 32k 88 2660k 2534k 23k 64 4052k 4049k 39k 3211M 11M134k 4010M 10M113k 1616M 16M270k 48 2820k 2597k 27k Total 62M 59M731k String pool entries 11239 identifiers 11239 (100.00%) slots 16384 deleted 0 bytes 115k (4095M overhead) table size 64k coll/search 0.5970 ins/search 0.0827 avg. entry 10.50 bytes (+/- 5.95) longest entry 45 ??? tree nodes created (No per-node statistics) Type hash: size 4093, 2786 elements, 0.998014 collisions DECL_DEBUG_EXPR hash: size 4093, 1657 elements, 1.080266 collisions DECL_VALUE_EXPR hash: size 1021, 0 elements, 0.00 collisions No gimple statistics Execution times (seconds) callgraph construction: 0.50 ( 1%) usr 0.00 ( 0%) sys 1.02 ( 1%) wall 1535 kB ( 2%) ggc callgraph optimization: 0.18 ( 1%) usr 0.01 ( 1%) sys 0.44 ( 0%) wall 1030 kB ( 1%) ggc cfg cleanup : 0.25 ( 1%) usr 0.01 ( 1%) sys 0.69 ( 1%) wall 25 kB ( 0%) ggc trivially dead code : 0.23 ( 1%) usr 0.01 ( 1%) sys 0.55 ( 1%) wall 0 kB ( 0%) ggc df live regs : 0.34 ( 1%) usr 0.00 ( 0%) sys 0.88 ( 1%) wall 0 kB ( 0%) ggc df reg dead/unused notes: 0.64 ( 2%) usr 0.02 ( 1%) sys 1.61 ( 2%) wall 1246 kB ( 2%) ggc register information : 0.30 ( 1%) usr 0.01 ( 1%) sys 0.70 ( 1%) wall 0 kB ( 0%) ggc alias analysis: 0.21 ( 1%) usr 0.00 ( 0%) sys 0.49 ( 1%) wall 386 kB ( 0%) ggc rebuild jump labels : 0.15 ( 0%) usr 0.02 ( 1%) sys 0.50 ( 1%) wall 0 kB ( 0%) ggc preprocessing : 0.79 ( 2%) usr 0.14 ( 8%) sys 2.22 ( 2%) wall 728 kB ( 1%) ggc lexical analysis : 0.51 ( 1%) usr 0.29 (16%) sys 1.90 ( 2%) wall 0 kB ( 0%) ggc parser: 1.79 ( 5%) usr 0.27 (15%) sys 4.55 ( 5%) wall 9896 kB (13%) ggc inline heuristics : 0.16 ( 0%) usr 0.01 ( 1%) sys
[Bug tree-optimization/41035] AIX cexp builtin underflow
--- Comment #3 from mikpe at it dot uu dot se 2009-12-09 16:07 --- (In reply to comment #2) libmpfr must be a shared object because libmpc relies on hidden, global state in libmpfr. If libmpfr is linked statically with libmpc and with GCC, each receives different instances of the global variables. If that's true then that's a horrible horrible bug in libmpc! I generally build private static-only gmp and mpfr libs for gcc-4.3 and above to avoid any interaction with whatever libs the rest of the system may or may not have. -- mikpe at it dot uu dot se changed: What|Removed |Added CC||mikpe at it dot uu dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41035
[Bug target/16350] gcc only understands little endian ARM systems
--- Comment #25 from ramana at gcc dot gnu dot org 2009-12-09 16:10 --- *** Bug 42081 has been marked as a duplicate of this bug. *** -- ramana at gcc dot gnu dot org changed: What|Removed |Added CC||tom at giftssoft dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16350
[Bug target/42081] big-endian arm MULTILIB_DEFAULTS hard-coded to little-endian
--- Comment #2 from ramana at gcc dot gnu dot org 2009-12-09 16:10 --- Dup of 16350. *** This bug has been marked as a duplicate of 16350 *** -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42081
[Bug regression/42258] redundant register move around mul instruction
-- ramana 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-12-09 16:12:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42258
[Bug libmudflap/42318] The newer libtool scripts break the build of libmudflap regarding the start files
--- Comment #4 from ramana at gcc dot gnu dot org 2009-12-09 16:25 --- (In reply to comment #1) I add that this happens also in native builds (host=build=target) Sorry, your bug report is contradictory - you say this is a native build but your host is x86_64-linux and your target is arm-linux-gnueabi . -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42318
[Bug libmudflap/42318] The newer libtool scripts break the build of libmudflap regarding the start files
--- Comment #5 from viriketo at gmail dot com 2009-12-09 16:27 --- I added first the report for making a cross-compiler, and I later *added* that the same problem happens building a native compiler. I agree closing the issue because of other reasons, but not because I wrote it contradictory. I think I wrote that quite clear about the problem happening in the build of cross and native compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42318
[Bug tree-optimization/41035] AIX cexp builtin underflow
--- Comment #4 from dje at gcc dot gnu dot org 2009-12-09 16:36 --- I think the problem is bad design of MPFR, not a bug in MPC. GCC uses mpfr_clear_flags(), mpfr_overflow_p() and mpfr_underflow_p() for results of computations in both MPFR and MPC, which uses MPFR. These rely on the MPFR global variable __gmpfr_flags. If libmpfr is a static library and libmpc is a shared library, libmpc and GCC will have their own, private copies of __gmpfr_flags. If both libraries are static or both libraries are shared, only one copy of the variable should exist. There sometimes are reasons to have both shared and static libraries and the current interaction creates a hidden dependency between the libraries. I think it would be a much better design to associate the flag with the variable containing the computational result than some global state. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41035
[Bug libmudflap/42279] libmudflap checks with the wrong CPP for execinfo.h
-- ramana 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-12-09 16:38:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42279
[Bug libmudflap/42279] libmudflap checks with the wrong CPP for execinfo.h
--- Comment #4 from viriketo at gmail dot com 2009-12-09 16:46 --- Created an attachment (id=19267) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19267action=view) Fix for libmudflap + libstdc++v3 for gcc 4.4.2 In gcc 4.4.2, libstdc++v3 is also affected by the CPP probelm. I attach the fix for gcc 4.4.2 that fixes both libstdc++v3 and libmudflap builds, and I imagine, any target library build. -- viriketo at gmail dot com changed: What|Removed |Added Attachment #19226|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42279
[Bug other/42333] complex division failure on darwin10 with -lm
--- Comment #23 from howarth at nitro dot med dot uc dot edu 2009-12-09
16:47 ---
Wouldn't that be limited to a subset of darwin
@@ -30,8 +30,8 @@
#set_board_info host_library_path [file dirname [file dirname [file dirname
[file dirname [file dirname [exec [find_gcc] --print-prog-name=cc1]]/lib
-# Do not use -lm on Cygwin
-if { [istarget *-*-cygwin*] } {
+# Do not use -lm on Cygwin or Darwin
+if { [istarget *-*-cygwin*] || [istarget *-*-darwin[921]*] } {
set_board_info mathlib
}
I thought at some point in past c code on darwin did require linking in -lm,
no?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333
[Bug libffi/42289] libffi fails to build with binutils-2.20 on ARM
--- Comment #3 from ramana at gcc dot gnu dot org 2009-12-09 16:49 --- Please submit the patch upstream as requested. this is a 4.3 only bug. -- ramana 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-12-09 16:49:26 date|| Target Milestone|--- |4.3.5 Version|unknown |4.3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42289
[Bug inline-asm/42321] NEON/VFP registers from inline assembly clobber list are saved/restored incorrectly
--- Comment #4 from ramana at gcc dot gnu dot org 2009-12-09 16:55 --- This occurs with arm-eabi cross as well. Ramana -- ramana at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org GCC build triplet|armv4tl-softfloat-linux-|armv4tl-softfloat-linux- |gnueabi |gnueabi, x86_64-linux GCC host triplet|armv4tl-softfloat-linux-|armv4tl-softfloat-linux- |gnueabi |gnueabi, x86_64-linux GCC target triplet|armv4tl-softfloat-linux-|armv4tl-softfloat-linux- |gnueabi |gnueabi, arm-eabi Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42321
[Bug target/42235] redundant memory move from parameter space to spill space
-- ramana 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-12-09 16:55:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42235
[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852
--- Comment #14 from ramana at gcc dot gnu dot org 2009-12-09 17:09 --- (In reply to comment #13) I am just re-testing it on vangelis with size estimates ignoring it. Honza - Any updates on this ? Ramana Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
[Bug target/37987] iwmmxt: insn does not satisfy its constraints on (int64_t)
-- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-12-09 17:10:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37987
[Bug other/42333] complex division failure on darwin10 with -lm
--- Comment #24 from developer at sandoe-acoustics dot co dot uk 2009-12-09 17:36 --- (In reply to comment #21) As a workaround in gcc I suggest to strip -lm in the darwin specific specs processing. Otherwise this is not a GCC bug (again), but a darwin bug - why do they always creep into gcc bugzilla ... well, the bug here is either in the gcc testsuite or dejagnu (depending on one's pov). The compiler behaves as expected when provided with the correct linker flags. The fact that this issue reveals an underlying Darwin10 bug is incidental (that bug should never bite us). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333
[Bug target/42324] Gcc doesn't follow x86-64 psABI on _Bool
--- Comment #9 from hjl dot tools at gmail dot com 2009-12-09 17:43 --- Created an attachment (id=19268) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19268action=view) Source and object files These are sources and object files generated by gcc 4.4, icc 11.1 and Sun Studio 12 Update 1 at -O. The results are 1. All compilers access _Bool as one byte when reading function return and function parameters. 2. icc 11.1 and Sun Studio 12 Update 1 clear bits 1-63 when writing function return and function parameters. 3. Gcc 4.4 clears bits 1-7 when writing function return. 4. Gcc 4.4 clears bits 1-31 when writing function parameters. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42324
[Bug tree-optimization/42344] New: ICE in rs6000.md with ipa-sra for 252.eon
GCC trunk gets a ICE when building SPEC CPU2000 test 252.eon with -O2 -fPIC
-fno-inline, but not with -fno-ipa-sra, on powerpc-linux with secureplt
enabled, as demonstrated by this minimized testcase:
class mrSurfaceList
{
public:
int *operator[] (int i) const { }
};
int *
makeGrid (mrSurfaceList * l)
{
return (*l)[0];
}
elm3b149% /home/janis/tools/gcc-trunk-anonsvn/bin/g++ -c -O2 -fPIC -fno-inline
bug.cc
bug.cc: In function int* makeGrid(mrSurfaceList*):
bug.cc:10:1: internal compiler error: in output_507, at
config/rs6000/rs6000.md:12527
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
The ICE begins with this patch, which adds IPA SRA:
http://gcc.gnu.org/viewcvs?view=revrev=151800
r151800 | jamborm | 2009-09-17 11:35:38 + (Thu, 17 Sep 2009)
--
Summary: ICE in rs6000.md with ipa-sra for 252.eon
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janis at gcc dot gnu dot org
GCC target triplet: powerpc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42344
[Bug fortran/42335] [OOP] ICE on CLASS IS (bad_identifier)
--- Comment #1 from janus at gcc dot gnu dot org 2009-12-09 18:03 --- Error: 'bad_id' at (1) is not an accessible derived type f951: internal compiler error: Segmentation fault Confirmed. The same happens for TYPE IS (bad_id). -- janus 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-12-09 18:03:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42335
[Bug fortran/42335] [OOP] ICE on CLASS IS (bad_identifier)
--- Comment #2 from janus at gcc dot gnu dot org 2009-12-09 18:06 --- Backtrace: #0 0x00549274 in gfc_find_sym_tree (name=0x7fffd840 v, ns=0x17a28b0, parent_flag=1, result=0x7fffd750) at /home/jweil/gcc45/fortran-dev/gcc/fortran/symbol.c:2507 #1 0x0054970e in gfc_get_ha_sym_tree (name=0x7fffd840 v, result=0x7fffd7d0) at /home/jweil/gcc45/fortran-dev/gcc/fortran/symbol.c:2679 #2 0x00517810 in gfc_match_rvalue (result=0x7fffd908) at /home/jweil/gcc45/fortran-dev/gcc/fortran/primary.c:2505 #3 0x004fdadf in match_primary (result=0x7fffd908) at /home/jweil/gcc45/fortran-dev/gcc/fortran/matchexp.c:161 #4 0x004fdc5a in match_level_1 (result=0x7fffd960) at /home/jweil/gcc45/fortran-dev/gcc/fortran/matchexp.c:234 #5 0x004fdd0a in match_mult_operand (result=0x7fffd9c0) at /home/jweil/gcc45/fortran-dev/gcc/fortran/matchexp.c:288 #6 0x004fdf06 in match_add_operand (result=0x7fffda08) at /home/jweil/gcc45/fortran-dev/gcc/fortran/matchexp.c:377 #7 0x004fe1b2 in match_level_2 (result=0x7fffda60) at /home/jweil/gcc45/fortran-dev/gcc/fortran/matchexp.c:501 #8 0x004fe33c in match_level_3 (result=0x7fffdac0) at /home/jweil/gcc45/fortran-dev/gcc/fortran/matchexp.c:572 #9 0x004fe43b in match_level_4 (result=0x7fffdb10) at /home/jweil/gcc45/fortran-dev/gcc/fortran/matchexp.c:620 #10 0x004fe6c9 in match_and_operand (result=0x7fffdb60) at /home/jweil/gcc45/fortran-dev/gcc/fortran/matchexp.c:714 #11 0x004fe74d in match_or_operand (result=0x7fffdbb0) at /home/jweil/gcc45/fortran-dev/gcc/fortran/matchexp.c:743 #12 0x004fe84c in match_equiv_operand (result=0x7fffdc00) at /home/jweil/gcc45/fortran-dev/gcc/fortran/matchexp.c:786 #13 0x004fe94b in match_level_5 (result=0x7fffdc50) at /home/jweil/gcc45/fortran-dev/gcc/fortran/matchexp.c:832 #14 0x004fea89 in gfc_match_expr (result=0x7fffddc8) at /home/jweil/gcc45/fortran-dev/gcc/fortran/matchexp.c:891 #15 0x004f751e in gfc_match (target=0x10f534e %e%t) at /home/jweil/gcc45/fortran-dev/gcc/fortran/match.c:1102 #16 0x004f7b53 in gfc_match_assignment () at /home/jweil/gcc45/fortran-dev/gcc/fortran/match.c:1300 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42335
[Bug tree-optimization/42337] GCC ICE in compute_antic, at tree-ssa-pre.c:2534
--- Comment #2 from davidxl at gcc dot gnu dot org 2009-12-09 18:07 --- Fixed in r155111. -- davidxl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42337
[Bug fortran/42335] [OOP] ICE on CLASS IS (bad_identifier)
--- Comment #3 from janus at gcc dot gnu dot org 2009-12-09 18:17 ---
Mine.
I think this one-liner is all that's needed:
Index: gcc/fortran/symbol.c
===
--- gcc/fortran/symbol.c(revision 155023)
+++ gcc/fortran/symbol.c(working copy)
@@ -2476,7 +2476,7 @@ select_type_insert_tmp (gfc_symtree **st)
{
gfc_select_type_stack *stack = select_type_stack;
for (; stack; stack = stack-prev)
-if ((*st)-n.sym == stack-selector)
+if ((*st)-n.sym == stack-selector stack-tmp)
*st = stack-tmp;
}
With this, the test case gives:
c0.f90:16.20:
class is (bad_id) ! ICE
1
Error: 'bad_id' at (1) is not an accessible derived type
c0.f90:17.36:
this%elements(:) = v%elements(:)
1
Error: 'elements' at (1) is not a member of the 'vector_class' structure
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org
|dot org |
Status|NEW |ASSIGNED
Last reconfirmed|2009-12-09 18:03:21 |2009-12-09 18:17:30
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42335
[Bug other/42333] complex division failure on darwin10 with -lm
--- Comment #25 from mrs at apple dot com 2009-12-09 18:29 --- I've filed radr://7457013 for libSystem (aka libm on 10.6) to improve the accuracy of ___divdc3. If that were fixed, then having -lm or not wouldn't matter. -- mrs at apple dot com changed: What|Removed |Added CC||mrs at apple dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333
[Bug other/42333] complex division failure on darwin10 with -lm
--- Comment #26 from howarth at nitro dot med dot uc dot edu 2009-12-09 18:40 --- I am still a bit confused about this bug. When we leave -lm out of the linkage of builtin-math-7.exe, where does the ___divdc3 call get resolved from? Shouldn't it be coming libSystem since that always appears first on the command line? http://developer.apple.com/mac/library/documentation/Porting/Conceptual/PortingUnix/compiling/compiling.html suggests that should be the case... The libSystem library also includes functions that you would normally expect to find in libc and libm, RPC services, and a name resolver. Because libSystem is automatically linked into your application, you do not need to explicitly add it to the compilers link line. For your convenience, many of these libraries exist as symbolic links to libSystem, so while explicitly linking against -lm (for example) is not needed, it will not cause an error. So this sounds more like an darwin linker bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333
[Bug java/41991] gcj segfaults on i686-apple-darwin* and x86_64-apple-darwin*
--- Comment #33 from bryce at gcc dot gnu dot org 2009-12-09 18:45 --- Subject: Bug 41991 Author: bryce Date: Wed Dec 9 18:45:13 2009 New Revision: 155113 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155113 Log: 2009-12-09 Bryce McKinlay bmckin...@gmail.com PR java/41991 * configure.ac (SYSTEMSPEC): Pass -allow_stack_execute to Darwin linker. * Makefile.am (gij_LDFLAGS): Remove extra_gij_ldflags. * configure: Regenerate. * Makefile.in: Regenerate. Modified: trunk/libjava/ChangeLog trunk/libjava/Makefile.am trunk/libjava/Makefile.in trunk/libjava/configure trunk/libjava/configure.ac trunk/libjava/gcj/Makefile.in trunk/libjava/include/Makefile.in trunk/libjava/testsuite/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991
[Bug java/41991] gcj segfaults on i686-apple-darwin* and x86_64-apple-darwin*
--- Comment #34 from bryce at gcc dot gnu dot org 2009-12-09 18:46 --- Subject: Bug 41991 Author: bryce Date: Wed Dec 9 18:46:11 2009 New Revision: 155114 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155114 Log: 2009-12-09 Bryce McKinlay bmckin...@gmail.com PR java/41991 * configure.ac (SYSTEMSPEC): Pass -allow_stack_execute to Darwin linker. * Makefile.am (gij_LDFLAGS): Remove extra_gij_ldflags. * configure: Regenerate. * Makefile.in: Regenerate. Modified: branches/gcc-4_4-branch/libjava/ChangeLog branches/gcc-4_4-branch/libjava/Makefile.am branches/gcc-4_4-branch/libjava/Makefile.in branches/gcc-4_4-branch/libjava/configure branches/gcc-4_4-branch/libjava/configure.ac branches/gcc-4_4-branch/libjava/gcj/Makefile.in branches/gcc-4_4-branch/libjava/include/Makefile.in branches/gcc-4_4-branch/libjava/testsuite/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991
[Bug other/42333] complex division failure on darwin10 with -lm
--- Comment #27 from mrs at apple dot com 2009-12-09 18:48 --- nm | grep ___divdc3 on all the objects and libraries on the link line, will tell you from where this symbol can be resolved. Reading the link line, will tell you the order ld will resolve in, but you have to realize that .dylibs always resolve first, before .a files (such a libgcc.a). This is explained in the ld man page. See -search_paths_first for more detail. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333
[Bug other/42333] complex division failure on darwin10 with -lm
--- Comment #28 from ghazi at gcc dot gnu dot org 2009-12-09 18:55 --- (In reply to comment #26) I am still a bit confused about this bug. When we leave -lm out of the linkage of builtin-math-7.exe, where does the ___divdc3 call get resolved from? The ___divdc3 function is defined in FSF GCC's libgcc2.so, which is what you want here. That version correctly handles overflow scenarios in complex division. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333
[Bug bootstrap/42345] New: cannot force 32 bit toolchain only
On: 2.6.31.6-162.fc12.x86_64 I configure: $src/gcc-trunk/configure --prefix=$bld/H-i686-gcc --enable-languages=c,c++ --enable-checking=release --with-cpu=i686 --target=i686-unknown-linux-gnu --disable-multilib Thinking this will give me a 32-bit defaulting i686 compiler. Gives: checking for i686-unknown-linux-gnu-gcc... /mnt/share/bld/gcc-i686/./gcc/xgcc -B/mnt/share/bld/gcc-i686/./gcc/ -B/mnt/share/bld/H-i686-gcc/i686-unknown-linux-gnu/bin/ -B/mnt/share/bld/H-i686-gcc/i686-unknown-linux-gnu/lib/ -isystem /mnt/share/bld/H-i686-gcc/i686-unknown-linux-gnu/include -isystem /mnt/share/bld/H-i686-gcc/i686-unknown-linux-gnu/sys-include checking for suffix of object files... configure: error: in `/mnt/share/bld/gcc-i686/i686-unknown-linux-gnu/libgcc': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. I've attached config.log. Is there a supported set of config options for this? -- Summary: cannot force 32 bit toolchain only Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bkoz at gcc dot gnu dot org GCC build triplet: x86_64-unknown-linux-gnu GCC target triplet: i686-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42345
[Bug bootstrap/42345] cannot force 32 bit toolchain only
--- Comment #1 from bkoz at gcc dot gnu dot org 2009-12-09 19:34 --- Created an attachment (id=19269) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19269action=view) configure output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42345
[Bug bootstrap/42345] cannot force 32 bit toolchain only
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-12-09 19:36 --- Can you attach /mnt/share/bld/gcc-i686/i686-unknown-linux-gnu/libgcc/config.log ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42345
[Bug bootstrap/42345] cannot force 32 bit toolchain only
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-12-09 19:37 --- But most likely you need to set CC=gcc -m32 to force the original gcc to be 32bits. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42345
[Bug bootstrap/42345] cannot force 32 bit toolchain only
--- Comment #4 from bkoz at gcc dot gnu dot org 2009-12-09 19:58 --- Result as per CC=gcc -m32 build in config2.log Ends with: checking for i686-unknown-linux-gnu-gcc... /mnt/share/bld/gcc-i686/./gcc/xgcc -B/mnt/share/bld/gcc-i686/./gcc/ -B/mnt/share/bld/H-i686-gcc/i686-unknown-linux-gnu/bin/ -B/mnt/share/bld/H-i686-gcc/i686-unknown-linux-gnu/lib/ -isystem /mnt/share/bld/H-i686-gcc/i686-unknown-linux-gnu/include -isystem /mnt/share/bld/H-i686-gcc/i686-unknown-linux-gnu/sys-include checking for suffix of object files... configure: error: in `/mnt/share/bld/gcc-i686/i686-unknown-linux-gnu/libgcc': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. make[1]: *** [configure-target-libgcc] Error 1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42345
[Bug bootstrap/42345] cannot force 32 bit toolchain only
--- Comment #5 from bkoz at gcc dot gnu dot org 2009-12-09 19:58 --- Created an attachment (id=19270) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19270action=view) configure output when CC=gcc -m32 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42345
[Bug bootstrap/42345] cannot force 32 bit toolchain only
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-12-09 20:01 --- You are still attaching the toplevel config.log which is not useful in this case since the libgcc is failing to compile. It might be the case that as is not being passed --32. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42345
[Bug bootstrap/42345] cannot force 32 bit toolchain only
--- Comment #7 from bkoz at gcc dot gnu dot org 2009-12-09 20:15 --- Created an attachment (id=19271) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19271action=view) target/libgcc config.log -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42345
[Bug bootstrap/42345] cannot force 32 bit toolchain only
--- Comment #8 from bkoz at gcc dot gnu dot org 2009-12-09 20:16 --- Sorry about that Andrew. Thanks for your help. I have attached the target/libgcc config.log. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42345
[Bug bootstrap/42345] cannot force 32 bit toolchain only
--- Comment #9 from pinskia at gcc dot gnu dot org 2009-12-09 20:21 --- /mnt/share/bld/gcc-i686/./gcc/as: line 83: exec: : not found That means as was not being found ... Try using either --with-as= or setting build=host=target (that is --target=i686-unknown-linux-gnu --host=i686-unknown-linux-gnu --build=i686-unknown-linux-gnu ). So what is happening right now is that you are building a cross compiler which normally finds as as i686-unknown-linux-gnu-as (likewise for ld and ar). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42345
[Bug bootstrap/42345] cannot force 32 bit toolchain only
--- Comment #11 from bkoz at gcc dot gnu dot org 2009-12-09 20:58 --- Created an attachment (id=19272) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19272action=view) libgcc/config.log -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42345
[Bug bootstrap/42345] cannot force 32 bit toolchain only
--- Comment #10 from bkoz at gcc dot gnu dot org 2009-12-09 20:58 --- result from --build/--target/--host == i686-unknown-linux-gnu in config4.libgcc.log. Fails with: In file included from /usr/include/features.h:376:0, from /usr/include/stdio.h:28, from /mnt/share/src/gcc-trunk/libgcc/../gcc/tsystem.h:87, from /mnt/share/src/gcc-trunk/libgcc/../gcc/libgcc2.c:29: /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory compilation terminated. make[3]: *** [_muldi3.o] Error 1 make[3]: Leaving directory `/mnt/share/bld/gcc-i686/i686-unknown-linux-gnu/libgcc' make[2]: *** [all-stage1-target-libgcc] Error 2 make[2]: Leaving directory `/mnt/share/bld/gcc-i686' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42345
[Bug bootstrap/42345] cannot force 32 bit toolchain only
--- Comment #12 from bkoz at gcc dot gnu dot org 2009-12-09 21:01 --- on the whole though, I don't know why just --with-cpu=i686 isn't enough. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42345
[Bug bootstrap/42345] cannot force 32 bit toolchain only
--- Comment #13 from jakub at gcc dot gnu dot org 2009-12-09 21:05 ---
Regarding #c10, on Fedora just yum install
{glibc-devel,libmpc-devel,mpfr-devel,gmp-devel,elfutils-libelf-devel}.i686
If you want to build a 32-bit only gcc (with 32-bit HWI) on x86-64, I usually:
mkdir ~/hbin32
cat ~/hbin32/as \EOF
#!/bin/sh
exec /usr/bin/as --32 $@
EOF
cat ~/hbin32/g++ \EOF
#!/bin/sh
exec /usr/bin/g++ -m32 $@
EOF
cat ~/hbin32/gcc \EOF
#!/bin/sh
exec /usr/bin/gcc -m32 $@
EOF
cat ~/hbin32/ld \EOF
#!/bin/sh
exec /usr/bin/ld -m elf_i386 -L /usr/lib/ $@
EOF
chmod 755 ~/hbin32/{as,g++,gcc,ld}
PATH=~/hbin32:$PATH i386 /configure ...
PATH=~/hbin32:$PATH i386 make -j...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42345
[Bug libstdc++/42273] atomic_2.h:111: = instead of == in if
--- Comment #6 from bkoz at gcc dot gnu dot org 2009-12-09 21:22 --- Mine. Adjusting for 4.4. branch. -- bkoz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bkoz at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-12-09 21:22:20 date|| Target Milestone|--- |4.4.3 Version|4.5.0 |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42273
[Bug fortran/34402] Diagnose illegal initialization of derived type containing allocatable component
--- Comment #6 from dfranke at gcc dot gnu dot org 2009-12-09 22:05 --- (In reply to comment #5) See 7.1.7(3) in F2003 (and 7.1.12(3) in the F2008 draft.) Walter, thanks for reference! -- dfranke at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dfranke at gcc dot gnu dot |dot org |org Status|WAITING |ASSIGNED Last reconfirmed|2007-12-09 13:07:58 |2009-12-09 22:05:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34402
[Bug libstdc++/42273] atomic_2.h:111: = instead of == in if
--- Comment #7 from bkoz at gcc dot gnu dot org 2009-12-09 22:07 --- Subject: Bug 42273 Author: bkoz Date: Wed Dec 9 22:06:59 2009 New Revision: 155117 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155117 Log: 2009-12-09 Roman Odaisky to.roma.from.bu...@qwertty.com PR libstdc++/42273 * include/bits/atomic_2.h: Fix typo. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/atomic_2.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42273
[Bug libstdc++/42273] atomic_2.h:111: = instead of == in if
--- Comment #8 from bkoz at gcc dot gnu dot org 2009-12-09 22:39 --- Subject: Bug 42273 Author: bkoz Date: Wed Dec 9 22:38:57 2009 New Revision: 155118 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155118 Log: 2009-12-09 Roman Odaisky to.roma.from.bu...@qwertty.com PR libstdc++/42273 * include/bits/atomic_2.h: Fix typo. Modified: branches/gcc-4_4-branch/libstdc++-v3/ChangeLog branches/gcc-4_4-branch/libstdc++-v3/include/bits/atomic_2.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42273
[Bug other/42333] complex division failure on darwin10 with -lm
--- Comment #29 from howarth at nitro dot med dot uc dot edu 2009-12-09 23:06 --- Ah, I understand now gcc-4 -O2 builtin-math-7-reduced.c ./a.out otool -L ./a.out ./a.out: /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 246.0.0) /sw/lib/gcc4.5/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.0.0) gcc-4 -O2 -mmacosx-version-min=10.5 builtin-math-7-reduced.c ./a.out Abort otool -L ./a.out ./a.out: /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 246.0.0) /sw/lib/gcc4.5/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.0.0) So while at first glance, the same __divdc3 symbol from /usr/lib/libgcc_s.1.dylib should be resolved as from /usr/lib/libSystem.B.dylib... nm /usr/lib/libgcc_s.1.dylib | grep ___divdc3 0019fa1e S $ld$hide$os10.4$___divdc3 0019fa1f S $ld$hide$os10.5$___divdc3 001640d0 T ___divdc3 nm /usr/lib/libSystem.B.dylib | grep ___divdc3 0019fa1e S $ld$hide$os10.4$___divdc3 0019fa1f S $ld$hide$os10.5$___divdc3 001640d0 T ___divdc3 without explicitly passing -mmacosx-version-min=10.5 to gcc, the __dividc3 is ignored in /usr/lib/libgcc_s.1.dylib and gotten from /sw/lib/gcc4.5/lib/libgcc_s.1.dylib instead. When we pass -lm, the linkage of /usr/lib/libSystem.B.dylib provides ___dividc3. gcc-4 -O2 builtin-math-7-reduced.c -lm ./a.out Abort otool -L ./a.out ./a.out: /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.0.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 246.0.0) /sw/lib/gcc4.5/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) This clears up my confusion about why usr/lib/libgcc_s.1.dylib wasn't providing ___dividc3 even though it appeared earlier in the linkage. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333
[Bug objc/42293] Can't build ObjC runtime library with GC for W32 target
--- Comment #5 from d dot g dot gorbachev at gmail dot com 2009-12-09 23:43 --- In mingw-w64 platform headers we worked-a-round this by checking for __OBJC__ to check, if we shouldn't define BOOL. The hack exists in mingw32 headers, too: 230 typedef int WINBOOL,*PWINBOOL,*LPWINBOOL; 231 /* FIXME: Is there a good solution to this? */ 232 #ifndef XFree86Server 233 #ifndef __OBJC__ 234 typedef WINBOOL BOOL; 235 #else 236 #define BOOL WINBOOL 237 #endif 238 typedef unsigned char BYTE; 239 #endif /* ndef XFree86Server */ 240 typedef BOOL *PBOOL,*LPBOOL; But libobjc is written in plain C, not in Objective-C. So when compiling, __OBJC__ isn't defined and hack does not work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42293
[Bug c++/42336] [c++0x] ICE with pointer-to-member-function decltype argument in template function
--- Comment #2 from aaz at althenia dot net 2009-12-10 00:07 --- To be more specific, it happens only with -O -fipa-sra -finline-small-functions -g -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42336
[Bug libffi/40700] [4.5 Regression] All amd64 libffi execution tests fail on Solaris 10/x86
--- Comment #2 from ro at gcc dot gnu dot org 2009-12-10 01:34 --- Mine. -- ro at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ro at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-12-10 01:34:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40700
[Bug libffi/40700] [4.5 Regression] All amd64 libffi execution tests fail on Solaris 10/x86
--- Comment #3 from ro at gcc dot gnu dot org 2009-12-10 01:45 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00517.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40700
[Bug bootstrap/42345] cannot force 32 bit toolchain only
--- Comment #14 from bkoz at gcc dot gnu dot org 2009-12-10 02:53 --- #c13 works for me, thanks jakub -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42345
[Bug bootstrap/42345] cannot force 32 bit toolchain only
--- Comment #15 from bkoz at gcc dot gnu dot org 2009-12-10 02:54 --- You can do it, although process is a bit convoluted. So, WORKSFORME. -- bkoz at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42345
