[Bug bootstrap/45751] [4.6 Regression] Bootstrap failure: at stage 1 xgcc segfault
--- Comment #4 from iains at gcc dot gnu dot org 2010-09-23 09:34 --- this appears to be to do with the driver construction of a default macosx-version-min. ./gcc/xgcc -Bgcc -dumpspecs = bus error ./gcc/xgcc -Bgcc -dumpspecs -mmacosx-version-min=10.5 = completes normally. Initial debugging suggests that the constructed option is being flagged as error=4 (wrong language) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45751
[Bug bootstrap/45751] [4.6 Regression] Bootstrap failure: at stage 1 xgcc segfault
--- Comment #5 from iains at gcc dot gnu dot org 2010-09-23 10:35 --- if the array was intended to be an array of structs then this fixes: Index: gcc/config/darwin-driver.c === --- gcc/config/darwin-driver.c (revision 164549) +++ gcc/config/darwin-driver.c (working copy) @@ -128,7 +128,7 @@ darwin_default_min_version (unsigned int *decoded_ generate_option (OPT_mmacosx_version_min_, new_flag, 1, CL_DRIVER, (*decoded_options)[1]); memcpy (*decoded_options + 2, argv + 1, - (argc - 1) * sizeof (struct cl_decoded_option *)); + (argc - 1) * sizeof (struct cl_decoded_option)); return; parse_failed: -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45751
[Bug middle-end/45730] Undefined symbol __gnu_cxx::stdio_sync_filebufchar, std::char_traitschar ::xsgetn(char*, long)
--- Comment #6 from iains at gcc dot gnu dot org 2010-09-21 13:01 --- (In reply to comment #5) Thus, I would say middle-end? However, certainly doesn't happen on Linux, for some reason... Honza, in case please recategorize. This happens also on i686-darwin9 at m32 m64. However, it does _not_ occur on powerpc-darwin9. -- iains at gcc dot gnu dot org changed: What|Removed |Added CC||iains at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-09-21 13:01:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45730
[Bug c++/45645] pr44972.C fails with error: �__assert_fail� was not declared in this scope
--- Comment #9 from iains at gcc dot gnu dot org 2010-09-21 14:13 --- Subject: Bug 45645 Author: iains Date: Tue Sep 21 14:12:58 2010 New Revision: 164479 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164479 Log: 2010-09-21 Jonathan Wakely r...@gcc.gnu.org Jack Howarth howa...@bromo.med.uc.edu PR c++/45645 * g++.dg/torture/pr44972.C: Use portable assert(). Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/torture/pr44972.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45645
[Bug testsuite/45692] FAIL: objc/execute/exceptions/throw-nil.m execution on darwin with -m32
--- Comment #5 from iains at gcc dot gnu dot org 2010-09-17 17:05 ---
(In reply to comment #4)
Ok ... I fixed the testcase in trunk.
Is there not a simpler way to fix the test with dejagnu directives?
Probably. :-)
well that's why I added the /torture dir under objc.dg - if tests require that
..
(also obj-c++.gc/torture)
If possible, it would be better to add all new tests under
objc.dg/{,torture,} as necessary... and avoid objc/*
.. it gives access to more flexible and selective features - which can help in
the transition to ObjC2 on NeXT.
if there are a significant number of new gnu-runtime-only-torture tests - then
perhaps we should create a gnu-runtime subdir under the torture heading. If
there are not many that are gnu-only (as at present) then dg-skip works for
me.
We could maybe tidy up all the files in that directory ;-)
yeah, it would be good to move all of the objc/* to objc.dg - when someone has
time.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45692
[Bug middle-end/45585] [4.6 Regression] ICE on powerpc-apple-darwin9 for gfortran.dg/transfer_simplify_2.f90 with -O2 -m64
--- Comment #1 from iains at gcc dot gnu dot org 2010-09-08 09:20 --- also on powerpc64-darwin9 -- iains at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-09-08 09:20:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45585
[Bug middle-end/45534] [4.6 Regression] ICE in refs_may_alias_p_1, at tree-ssa-alias.c:1031
--- Comment #15 from iains at gcc dot gnu dot org 2010-09-06 18:07 --- (In reply to comment #14) Subject: Bug 45534 New Revision: 163913 2010-09-06 Richard Guenther rguent...@suse.de PR tree-optimization/45534 * tree-ssa-address.c (create_mem_ref_raw): Add verify parameter. (create_mem_ref): Do verify the created TARGET_MEM_REF is valid on the target. (maybe_fold_tmr): Do not verify the created TARGET_MEM_REF is valid on the target. fixed on i686-darwin9. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45534
[Bug middle-end/45534] [4.6 Regression] ICE in refs_may_alias_p_1, at tree-ssa-alias.c:1031
--- Comment #7 from iains at gcc dot gnu dot org 2010-09-05 14:24 --- (In reply to comment #6) (In reply to comment #5) -v for one failing testcase - I want to see what standard -march/tune your config uses. we default to generic (FWIW, the same fail occurs also for me on i686-darwin9 with -mtune=core2). $ /GCC/gcc-4-6-reghunt-build/gcc/xgcc -B/GCC/gcc-4-6-reghunt-build/gcc/ /GCC/gcc-4-6-reghunt/libgomp/testsuite/libgomp.fortran/appendix-a/a.16.1.f90 -B/GCC/gcc-4-6-reghunt-build/i686-apple-darwin9/x86_64/libgomp/ -B/GCC/gcc-4-6-reghunt-build/i686-apple-darwin9/x86_64/libgomp/.libs -I/GCC/gcc-4-6-reghunt-build/i686-apple-darwin9/x86_64/libgomp -I/GCC/gcc-4-6-reghunt/libgomp/testsuite/.. -shared-libgcc -fmessage-length=0 -fopenmp -Os -B/GCC/gcc-4-6-reghunt-build/i686-apple-darwin9/x86_64/libgomp/../libgfortran/.libs -L/GCC/gcc-4-6-reghunt-build/i686-apple-darwin9/x86_64/libgomp/.libs -lgomp -L/GCC/gcc-4-6-reghunt-build/i686-apple-darwin9/x86_64/libgomp/../libgfortran/.libs -lgfortran -lm -m64 -o ./a.16.1.exe -v Reading specs from /GCC/gcc-4-6-reghunt-build/gcc/specs COLLECT_GCC=/GCC/gcc-4-6-reghunt-build/gcc/xgcc COLLECT_LTO_WRAPPER=/GCC/gcc-4-6-reghunt-build/gcc/lto-wrapper Target: i686-apple-darwin9 Configured with: ../gcc-4-6-reghunt/configure --prefix=/GCC/tobjc --target=i686-apple-darwin9 --host=i686-apple-darwin9 --build=i686-apple-darwin9 --enable-version-specific-runtime-libs --enable-threads --enable-checking=yes --program-suffix=-4.6rh --with-libiconv-prefix=/usr --with-system-zlib --enable-languages=c,fortran CC=gcc-4.2 CXX=g++-4.2 Thread model: posix gcc version 4.6.0 20100905 (experimental) [trunk revision 163877] (GCC) COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.5.8' '-B' '/GCC/gcc-4-6-reghunt-build/gcc/' '-B' '/GCC/gcc-4-6-reghunt-build/i686-apple-darwin9/x86_64/libgomp/' '-B' '/GCC/gcc-4-6-reghunt-build/i686-apple-darwin9/x86_64/libgomp/.libs' '-I' '/GCC/gcc-4-6-reghunt-build/i686-apple-darwin9/x86_64/libgomp' '-I' '/GCC/gcc-4-6-reghunt/libgomp/testsuite/..' '-shared-libgcc' '-fmessage-length=0' '-fopenmp' '-Os' '-B' '/GCC/gcc-4-6-reghunt-build/i686-apple-darwin9/x86_64/libgomp/../libgfortran/.libs' '-L/GCC/gcc-4-6-reghunt-build/i686-apple-darwin9/x86_64/libgomp/.libs' '-L/GCC/gcc-4-6-reghunt-build/i686-apple-darwin9/x86_64/libgomp/../libgfortran/.libs' '-m64' '-o' './a.16.1.exe' '-v' '-mtune=generic' /GCC/gcc-4-6-reghunt-build/gcc/f951 /GCC/gcc-4-6-reghunt/libgomp/testsuite/libgomp.fortran/appendix-a/a.16.1.f90 -I /GCC/gcc-4-6-reghunt-build/i686-apple-darwin9/x86_64/libgomp -I /GCC/gcc-4-6-reghunt/libgomp/testsuite/.. -fPIC -quiet -dumpbase a.16.1.f90 -mmacosx-version-min=10.5.8 -m64 -mtune=generic -auxbase a.16.1 -Os -version -fmessage-length=0 -fopenmp -fintrinsic-modules-path finclude -o /var/folders/OW/OW-PGOtgHbKakssxFpJpkU++-0E/-Tmp-//cc74lrzb.s GNU Fortran (GCC) version 4.6.0 20100905 (experimental) [trunk revision 163877] (i686-apple-darwin9) compiled by GNU C version 4.6.0 20100905 (experimental) [trunk revision 163877], GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU Fortran (GCC) version 4.6.0 20100905 (experimental) [trunk revision 163877] (i686-apple-darwin9) compiled by GNU C version 4.6.0 20100905 (experimental) [trunk revision 163877], GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 /GCC/gcc-4-6-reghunt/libgomp/testsuite/libgomp.fortran/appendix-a/a.16.1.f90: In function a16: /GCC/gcc-4-6-reghunt/libgomp/testsuite/libgomp.fortran/appendix-a/a.16.1.f90:26:0: internal compiler error: in refs_may_alias_p_1, at tree-ssa-alias.c:1040 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45534
[Bug middle-end/45534] [4.6 Regression] ICE in refs_may_alias_p_1, at tree-ssa-alias.c:1031
--- Comment #12 from iains at gcc dot gnu dot org 2010-09-05 16:46 --- (In reply to comment #10) Apparently this pr does not show up for i686-apple-darwin9 (see http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg00452.html ). it does at m64 see c#7 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45534
[Bug middle-end/45534] [4.6 Regression] ICE in refs_may_alias_p_1, at tree-ssa-alias.c:1031
-- iains at gcc dot gnu dot org changed: What|Removed |Added CC||iains at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-09-04 12:05:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45534
[Bug target/44309] ../../gcc-4.5/gcc/config/t-darwin:25: warning: overriding commands for target `darwin.o'
--- Comment #2 from iains at gcc dot gnu dot org 2010-08-30 08:33 --- indeed - closing as fixed. -- iains at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44309
[Bug lto/44812] m32 lto produces non-relocatable subtraction expression errors
--- Comment #29 from iains at gcc dot gnu dot org 2010-08-27 17:38 --- (In reply to comment #12) Subject: Re: m32 lto produces non-relocatable subtraction expression errors Hmm, actually the symbol is not changed, since it is externally visible symbol. I guess the problem would be that the symbol is used by 2 units, so both of them gets the declaration, but both of them gets the declaration with initializer (not extern). To avoid duplicate definitions, varpool.c is testing in_other_partition and prevents calling assemble_variable on them. so one gets emitted and the other doesn't? This works just fine on ELF since extern vars don't need to be announced. we don't need to announce them either ... (assemble_external() is a no-op). Here we apparently need to get it assembled, but it is not getting via assemble_external. we need to get the right entry into the machopic tables - if the var is local to the TU ... Rebuilding the decl to DECL_EXTERN is probably possible, but somewhat hackish. I guess this is just allowing it to be assembled... === It is possible that the following is the root of the problem; when deciding how to output a var darwin/macho-pic takes the presence of an initializer as evidence that the var is defined in the current TU and that, therefore, it can reference it locally and doesn't need to output the other stuff. unless the var passes through assemble_var () this will not get done. assemble_external () seems a bit hackish too... I'm not clear why the two instances are not coalesced by the whopr process? Is that to cater for file-scope vars? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44812
[Bug lto/44812] m32 lto produces non-relocatable subtraction expression errors
--- Comment #9 from iains at gcc dot gnu dot org 2010-08-24 13:47 --- (In reply to comment #5) Hmm, the problem seems to be that partitioning puts mumble into one partition, while in first partition it uses local (IP) relative way to access it: movl_mumble-L001$pb(%ebx), %eax and assembler refuse it. What is proper way to access hidden symbol from other .s file? Take a look at the output of compilation without lto .. .. the symbol is indirected - since it cannot be guaranteed to be within reach otherwise; so (by convention) _mumble-L001$pb = L__mumble$non_lazy_ptr-L001$pb .. .non_lazy_symbol_pointer L_mumble$non_lazy_ptr: .indirect_symbol _mumble .long 0 -- iains at gcc dot gnu dot org changed: What|Removed |Added CC||iains at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44812
[Bug lto/44812] m32 lto produces non-relocatable subtraction expression errors
--- Comment #10 from iains at gcc dot gnu dot org 2010-08-24 14:11 --- (In reply to comment #9) (In reply to comment #5) Hmm, the problem seems to be that partitioning puts mumble into one partition, while in first partition it uses local (IP) relative way to access it: movl_mumble-L001$pb(%ebx), %eax and assembler refuse it. What is proper way to access hidden symbol from other .s file? Take a look at the output of compilation without lto .. .. the symbol is indirected - since it cannot be guaranteed to be within reach otherwise; which you already posted, I don't think the hidden attribute is relevant, looking at other fails. local symbols need to be registered with machopic_define_symbol() (see config/darwin.h ASM_DECLARE_OBJECT_NAME). they are processed via machopic_finish() called from darwin_file_end () [config/darwin.c] which , I assume is still called in the lto case? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44812
[Bug lto/44812] m32 lto produces non-relocatable subtraction expression errors
--- Comment #11 from iains at gcc dot gnu dot org 2010-08-24 14:37 --- essentially to turn the last comment around: IIUC, if whopr changes a symbol from external to local then it needs to register that symbol with machopic_define_symbol () -- and ensure that (* targetm.encode_section_info) (DECL, DECL_RTL (DECL), false); gets called too.. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44812
[Bug lto/44812] m32 lto produces non-relocatable subtraction expression errors
--- Comment #13 from iains at gcc dot gnu dot org 2010-08-24 15:17 --- (In reply to comment #12) Subject: Re: m32 lto produces non-relocatable subtraction expression errors Hmm, actually the symbol is not changed, since it is externally visible symbol. ah, OK. assemble_external (). is a no-op on darwin (unless the symbol is weak). since we don't declare ASM_OUTPUT_EXTERNAL. There might be some trick with marking the symbols weak/weak_import but I know nothing of the internals of lto to comment further. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44812
[Bug debug/42487] FAIL: gcc.dg/debug/dwarf2/aranges-fnsec-1.c scan-assembler DW_AT_ranges
--- Comment #7 from iains at gcc dot gnu dot org 2010-08-18 08:21 --- Subject: Bug 42487 Author: iains Date: Wed Aug 18 08:21:43 2010 New Revision: 163326 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163326 Log: PR debug/42487 * lib/target-supports.exp (check_effective_target_function_sections): New. * gcc.dg/debug/dwarf2/aranges-fnsec-1.c: Check that the target supports function sections before proceding. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/debug/dwarf2/aranges-fnsec-1.c trunk/gcc/testsuite/lib/target-supports.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42487
[Bug java/41991] gcj segfaults on i686-apple-darwin9 and x86_64-apple-darwin9
--- Comment #49 from iains at gcc dot gnu dot org 2010-08-17 13:13 --- the patch attached to http://gcc.gnu.org/ml/gcc-patches/2010-08/msg01249.html solves the problem by suppression of the epilogues in _eh_frames; the patch might be an incomplete solution to darwin-dwarf2 issues. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991
[Bug objc/41848] Extra Objective C test failures because of section anchors.
--- Comment #8 from iains at gcc dot gnu dot org 2010-08-11 09:11 --- (In reply to comment #7) (In reply to comment #5) -(hopefully) Andrew's analysis is correct (but, I guess I'd like to know why it fixed them ... ).. IIRC the issue with section anchors and the objective-c front-end was the decl was being finialized in size after it had been pushed into the variable cgraph. So you moved that pushing later which fixed this issue. And in fact you can now test powerpc-linux (or AIX; I think darwin now too) removing the check in the back-end for objc language and section anchors. indeed, there are a couple of other issues with section anchors (on darwin) but the ObjC ones are resolved there too. Closing as fixed. -- iains at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41848
[Bug middle-end/44121] [4.6 Regression] multiple char-related fails.
--- Comment #20 from iains at gcc dot gnu dot org 2010-08-11 10:21 --- also on i686-darwin9, closing as fixed. -- iains at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44121
[Bug tree-optimization/44137] [4.6 Regression]: objc.dg/torture/tls/thr-init-2.m and thr-init.m
--- Comment #4 from iains at gcc dot gnu dot org 2010-08-11 10:22 --- AFAICT from testing on cris-elf Xd from i686-darwin9 this is fixed. -- iains at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44137
[Bug middle-end/44276] [4.6 Regression]: gcc.dg/tls/alias-1.c
--- Comment #13 from iains at gcc dot gnu dot org 2010-08-11 10:23 --- AFAICT, from testing on cris-elf Xf from i686-darwin9 this is fixed. -- iains at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44276
[Bug java/41991] gcj segfaults on i686-apple-darwin9 and x86_64-apple-darwin9
--- Comment #44 from iains at gcc dot gnu dot org 2010-08-11 12:32 --- I do not think the current solution is complete/correct. For 4.5.x and current trunk we still have a significant problem. (4.4.x apparently still works, as of 4.4.5/r163091, at least for trivial cases) [apollo is i686-darwin9 with r163091 bootstrapped and installed; CWD=build-top-level]. apollo:gcc-4-5-branch-build$ /GCC/gcc-4-5-install/bin/gcj-4.5 ../tests/HelloWorld.java --main=HelloWorld -o hw gcj-4.5: Internal error: Abort trap (program ecj1): FAILS apollo:gcc-4-5-branch-build$ DYLD_LIBRARY_PATH=gcc /GCC/gcc-4-5-install/bin/gcj-4.5 ../tests/HelloWorld.java --main=HelloWorld -o hw . OK - builds... try to invoke the generated exe: apollo:gcc-4-5-branch-build./hw ... a long wait ... (on powerpc-darwin9 .. you get some interesting error messages about repeated allocation of 1Gb memory chunks :/). Abort trap apollo:gcc-4-5-branch-build$ DYLD_LIBRARY_PATH=gcc ./hw Hello, World Incidentally, this applies equally if one starts from HelloWorld.class It seems to me that we have some dependancy issue that is causing libgcj to link (some) symbols from fsf/libgcc_s.1dylib that should really be linked from /usr/lib/libgcc_s.1.dylib - i.e. the unwinder is being invoked in two different libs :( see = 4.6-trunk behaves the same on Darwin9, I've not tried Darwin10 (for reasons which should be evident below). = Taking the case of Darwin9/OSX 10.5: (a) the code for _Unwind_FindEnclosingFunction c. as posted on http://www.opensource.apple.com/release/mac-os-x-1058/ is the same as fsf-gcc (AFAICT from browsing it online) -- so I'm not sure why we added in the darwin10_Unwind_FindEnclosingFunction (it's the same code as already present in the system lib). [having said that, even if the system code _is_ broken and unusable, (b) applies. and one needs to work around the breakage without bypassing said system code] (b) As the design(s) stand, we can only have one unwinder.. the choices are: 1/ to use the system one in which case you can integrate your code with system-supplied libraries [which is what, I suspect, the majority of users want] 2/ You can replace the system unwinder with the one in fsf-path/libgcc_s.1.dylib - in which case you must point DYLD to that before invoking any code generated by gcj (including the compiler itself). That code cannot use _any_ system facilities that might require the unwinder. (ergo, the test-suite passes, but one can't build a general application using arbitrary system facilities). it seems we have (2) at present, and I wonder how useful that is to the majority of end users? (I guess there is also option (3) - overwrite the system libgcc_s with the fsf one .. but, if you do that, then you must take responsibility for any other system breakage or security issues you cause ... not a route I'd recommend for most end-users ;)). = Incidentally, this is the whole reason we implemented the libgcc_ext.dylib --- so that extensions to gcc (like emutls) could be applied to OSX without interfering with the unwinder ;) .. and that is the reason that both /usr/lib/libgccs.1.dylib _and_ fsf/libgcc_s.1.dylib are linked into darwin executables, (taking advantage of the different namespaces). However, in this case, if I regress the darwin10_Unwind_FindEnclosingFunction change out, the code still fails - which indicates to me that: (i) somewhere else in the build of libgcj or the classpath there is a dependency on some part of the unwinder that is being satisfied by a link from fsf/libgcc_s.1dylib (although a look at the Makefile didn't show anything obvious, perhaps someone more familiar with libjava would be able to spot it?). (ii) or.. that there's a bug/incompatibility between the system unwinder fsf gcc that we haven't worked around. in the case of (ii) the endgame is much the same as for darwin 10 = For Darwin10/OSX10.6 (a) I'm not sure that the current libjava design applies; it seems that the relevant routines might have been replaced by no-ops (from comments posted elsewhere, and a quick check of otool -tv -p _Unwind_FindEnclosingFunction). I.E the unwinder has changed to a different implementation.. However, as for darwin9, (b) applies - one can replace the system unwinder with the one in libgcc - but, again, that means the user will be limited to self-contained code. = If no-one has time to implement an integration of libjava with the Darwin 10 unwinders [and/or fix the breakage with Darwin9] (I don't, sorry), then essentially gcj 4.5 is unusable on current Darwin in any other manner than stand-alone (and, frankly, I wonder how generally useful that is?). -- iains at gcc dot gnu dot org changed: What|Removed |Added
[Bug middle-end/17982] stop calling assemble_external before final assembly output time
--- Comment #35 from iains at gcc dot gnu dot org 2010-08-10 13:01 ---
(In reply to comment #34)
I think the ones in calls.c are OK. So only ObjC still calls
assemble_external. Iain?
AFAICT, assemble_external () [no longer?] emits any assembly nor does it call
DECL_ASSEMBLER_NAME:
it seems to check for a weak function and add that to the weak functions list
and then (if the target defines ASM_OUTPUT_EXTERNAL) adds the decl to the
pending list which is output from assemble_pending_externals () called from
toplev.c.
varasm (assemble variable) says:
/* Normally no need to say anything here for external references,
since assemble_external is called by the language-specific code
when a declaration is first seen. */
if (DECL_EXTERNAL (decl))
return;
I would imagine that if this were replaced by:
if (DECL_EXTERNAL (decl))
{
assemble_external (decl);
return;
}
we should be able to remove the calls in ObjC (I'll try this later).
OTOH, I wonder if we have a case of a solved problem with the bug left
open?
[BTW, I also have checking the status of 24777 on my TODO.]
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17982
[Bug target/45196] ld: warning: can't add line info to anonymous symbol
--- Comment #1 from iains at gcc dot gnu dot org 2010-08-05 14:23 ---
does this solve the problem?
(it's a hack - we should ensure that the debug sections do not appear in
between our program sections, but that's for another day).
Index: gcc/config/darwin.c
===
--- gcc/config/darwin.c (revision 162881)
+++ gcc/config/darwin.c (working copy)
@@ -1699,6 +1699,23 @@ darwin_asm_output_dwarf_delta (FILE *file, int siz
void
darwin_file_start (void)
{
+ fputs (\t.const\n\t.static_const\n\t.cstring\n, asm_out_file) ;
+ fputs (\t.literal4\n\t.literal8\n\t.literal16\n, asm_out_file) ;
+ fputs (\t.data\n\t.static_data\n\t.const_data\n, asm_out_file) ;
+ if (!TARGET_64BIT)
+{
+ if (flag_pic == 2)
+ fputs (\t.picsymbol_stub\n, asm_out_file) ;
+ else
+ fputs (\t.symbol_stub\n, asm_out_file) ;
+ fputs (\t.lazy_symbol_pointer\n\t.non_lazy_symbol_pointer\n,
asm_out_file);
+ fputs (\t.section __TEXT,__textcoal_nt,coalesced,pure_instructions\n,
asm_out_file);
+}
+ else
+{
+ fputs (\t.section
__TEXT,__eh_frame,coalesced,no_toc+strip_static_syms+live_support\n,
asm_out_file) ;
+}
+ in_section = NULL;
if (write_symbols == DWARF2_DEBUG)
{
static const char * const debugnames[] =
--
iains at gcc dot gnu dot org changed:
What|Removed |Added
CC||iains at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45196
[Bug c/45054] [4.6 Regression] struct-by-value-1.c fail.
--- Comment #1 from iains at gcc dot gnu dot org 2010-07-31 10:31 --- confirmed as per: http://gcc.gnu.org/ml/gcc-patches/2010-07/msg01959.html cc-ing Bernd. -- iains at gcc dot gnu dot org changed: What|Removed |Added CC||bernds at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-07-31 10:31:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45054
[Bug middle-end/45150] New: [4.6 Regression] bootstrap debug-compare fail
i686-apple-darwin9 bootstrap is broken since r162678 (with an ICE reported for other targets as well). Since this was fixed (at r162697), it has unmasked another fail which is still present at 162778. unfortunately, the other bootstrap bug prevents narrowing this down more... however; This is a compare-debug fail of cfgexpand.o. Looking at the .s files (to be attached) there seem to be instruction ordering differences. this bug is _not_ present in powerpc-apple-darwin9 or x86_64-apple-darwin10. -- Summary: [4.6 Regression] bootstrap debug-compare fail Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: iains at gcc dot gnu dot org GCC target triplet: i686-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45150
[Bug middle-end/45150] [4.6 Regression] bootstrap debug-compare fail
--- Comment #1 from iains at gcc dot gnu dot org 2010-07-31 13:21 --- Created an attachment (id=21364) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21364action=view) .i and .s files from cfgexpand for stage2 3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45150
[Bug middle-end/45150] [4.6 Regression] bootstrap debug-compare fail
--- Comment #2 from iains at gcc dot gnu dot org 2010-07-31 13:26 --- cc-ing Bernd having reviewed the svn logs between r162678 and 162697. -- iains at gcc dot gnu dot org changed: What|Removed |Added CC||bernds at gcc dot gnu dot ||org Summary|[4.6 Regression] bootstrap |[4.6 Regression] bootstrap |debug-compare fail |debug-compare fail http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45150
[Bug middle-end/45150] [4.6 Regression] bootstrap debug-compare fail
--- Comment #3 from iains at gcc dot gnu dot org 2010-07-31 18:47 --- this is a bit tedious to work through ... but for example in _expand_one_stack_var_at: we have for stage2 : * cmovae %edx, %eax # tmp143,, max_align cmpl$0, 52(%esp)#, %sfp jbe L252#, L245: movl%eax, 48(%esp) # max_align, %sfp L227: movzwl %cx, %eax # D.53575, tmp154 sall$6, %eax#, tmp154 addlL_tree_contains_struct$non_lazy_ptr-L044$pb(%ebx), %eax #, tmp155 *** and for stage 3: cmovae %edx, %eax # tmp143,, max_align LM516: cmpl$0, 52(%esp)#, %sfp jbe L252#, L245: LM517: movl%eax, 48(%esp) # max_align, %sfp movl$0, 52(%esp)#, %sfp L227: LVL348: LBB2461: LM518: movzwl %cx, %eax # D.53575, tmp154 sall$6, %eax#, tmp154 addlL_tree_contains_struct$non_lazy_ptr-L044$pb(%ebx), %eax #, tmp155 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45150
[Bug objc/44140] ObjC lto/whopr fails
--- Comment #19 from iains at gcc dot gnu dot org 2010-07-27 12:03 --- Subject: Bug 44140 Author: iains Date: Tue Jul 27 12:02:50 2010 New Revision: 162563 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162563 Log: re-enable tls and lto tests for ObjC/C++ PR ObjC/44140 * obj-c++.dg/torture/tls/thr-init-1.mm: Re-enable test. * obj-c++.dg/torture/tls/thr-init-2.mm: Ditto. * obj-c++.dg/torture/tls/thr-init-3.mm: Ditto. * obj-c++.dg/torture/trivial.mm: Ditto. * objc.dg/torture/tls/thr-init-2.m: Ditto. * objc.dg/torture/tls/thr-init-3.m: Ditto. * objc.dg/torture/tls/thr-init.m: Ditto. * objc.dg/torture/trivial.m: Ditto. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/obj-c++.dg/torture/tls/thr-init-1.mm trunk/gcc/testsuite/obj-c++.dg/torture/tls/thr-init-2.mm trunk/gcc/testsuite/obj-c++.dg/torture/tls/thr-init-3.mm trunk/gcc/testsuite/obj-c++.dg/torture/trivial.mm trunk/gcc/testsuite/objc.dg/torture/tls/thr-init-2.m trunk/gcc/testsuite/objc.dg/torture/tls/thr-init-3.m trunk/gcc/testsuite/objc.dg/torture/tls/thr-init.m trunk/gcc/testsuite/objc.dg/torture/trivial.m -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44140
[Bug target/35491] wrong ABI for some struct passing with vector code
--- Comment #4 from iains at gcc dot gnu dot org 2010-07-27 13:24 --- Subject: Bug 35491 Author: iains Date: Tue Jul 27 13:24:08 2010 New Revision: 162567 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162567 Log: PR target/35491 PR target/29090 Merge from Apple local 4.2.1. 2005-05-11 Stan Shebs sh...@apple.com Fix 64-bit varargs for Darwin (Radar 4028089). * config/rs6000/rs6000.h (rs6000_args): New field floats_in_gpr. * config/rs6000/rs6000.c (rs6000_darwin64_record_arg_advance_flush): Add argument, add case for 8-byte register half-filled with a float. (rs6000_darwin64_record_arg_advance_recurse): Detect and handle single-precision floats specially. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c trunk/gcc/config/rs6000/rs6000.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35491
[Bug target/29090] gcc.dg-struct-layout-1 failures on Darwin PPC at -m64
--- Comment #21 from iains at gcc dot gnu dot org 2010-07-27 13:24 --- Subject: Bug 29090 Author: iains Date: Tue Jul 27 13:24:08 2010 New Revision: 162567 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162567 Log: PR target/35491 PR target/29090 Merge from Apple local 4.2.1. 2005-05-11 Stan Shebs sh...@apple.com Fix 64-bit varargs for Darwin (Radar 4028089). * config/rs6000/rs6000.h (rs6000_args): New field floats_in_gpr. * config/rs6000/rs6000.c (rs6000_darwin64_record_arg_advance_flush): Add argument, add case for 8-byte register half-filled with a float. (rs6000_darwin64_record_arg_advance_recurse): Detect and handle single-precision floats specially. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c trunk/gcc/config/rs6000/rs6000.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29090
[Bug target/29090] gcc.dg-struct-layout-1 failures on Darwin PPC at -m64
--- Comment #22 from iains at gcc dot gnu dot org 2010-07-27 13:26 --- Subject: Bug 29090 Author: iains Date: Tue Jul 27 13:26:34 2010 New Revision: 162568 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162568 Log: PR target/29090 * config/rs6000/rs6000.c (rs6000_gimplify_va_arg): Special-case the Darwin64 ABI, for zero-sized objects. Modified: trunk/gcc/config/rs6000/rs6000.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29090
[Bug testsuite/38526] WARNING: Could not compile gcc.dg/compat/struct-layout-1 generator
--- Comment #7 from iains at gcc dot gnu dot org 2010-07-24 07:46 --- fixed -- iains at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38526
[Bug target/39912] FAIL: tmpdir-gcc.dg-struct-layout-1/t001 c_compat_x_tst.o-c_compat_y_tst.o execute
--- Comment #7 from iains at gcc dot gnu dot org 2010-07-24 07:56 --- *** This bug has been marked as a duplicate of 29090 *** -- iains at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39912
[Bug target/29090] gcc.dg-struct-layout-1 failures on Darwin PPC at -m64
--- Comment #11 from iains at gcc dot gnu dot org 2010-07-24 07:56 --- *** Bug 39912 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29090
[Bug target/39913] tmpdir-gcc.dg-struct-layout-1/t003 c_compat_x_tst.o-c_compat_y_tst.o execute failure
--- Comment #7 from iains at gcc dot gnu dot org 2010-07-24 07:57 --- *** This bug has been marked as a duplicate of 29090 *** -- iains at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39913
[Bug target/29090] gcc.dg-struct-layout-1 failures on Darwin PPC at -m64
--- Comment #12 from iains at gcc dot gnu dot org 2010-07-24 07:57 --- *** Bug 39913 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29090
[Bug target/39915] tmpdir-gcc.dg-struct-layout-1/t005 c_compat_x_tst.o-c_compat_y_tst.o execute failure at -m64
--- Comment #7 from iains at gcc dot gnu dot org 2010-07-24 07:58 --- *** This bug has been marked as a duplicate of 29090 *** -- iains at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39915
[Bug target/29090] gcc.dg-struct-layout-1 failures on Darwin PPC at -m64
--- Comment #13 from iains at gcc dot gnu dot org 2010-07-24 07:58 --- *** Bug 39915 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29090
[Bug target/29090] gcc.dg-struct-layout-1 failures on Darwin PPC at -m64
--- Comment #14 from iains at gcc dot gnu dot org 2010-07-24 07:58 --- *** Bug 39916 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29090
[Bug target/39916] tmpdir-gcc.dg-struct-layout-1/t006 c_compat_x_tst.o-c_compat_y_tst.o execute failure at -m64
--- Comment #7 from iains at gcc dot gnu dot org 2010-07-24 07:58 --- *** This bug has been marked as a duplicate of 29090 *** -- iains at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39916
[Bug target/39917] tmpdir-gcc.dg-struct-layout-1/t008 c_compat_x_tst.o-c_compat_y_tst.o execute failure at -m64
--- Comment #7 from iains at gcc dot gnu dot org 2010-07-24 07:59 --- *** This bug has been marked as a duplicate of 29090 *** -- iains at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39917
[Bug target/29090] gcc.dg-struct-layout-1 failures on Darwin PPC at -m64
--- Comment #15 from iains at gcc dot gnu dot org 2010-07-24 07:59 --- *** Bug 39917 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29090
[Bug target/39918] tmpdir-gcc.dg-struct-layout-1/t016 c_compat_x_tst.o-c_compat_y_tst.o execute at -m64
--- Comment #7 from iains at gcc dot gnu dot org 2010-07-24 07:59 --- *** This bug has been marked as a duplicate of 29090 *** -- iains at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39918
[Bug target/29090] gcc.dg-struct-layout-1 failures on Darwin PPC at -m64
--- Comment #16 from iains at gcc dot gnu dot org 2010-07-24 07:59 --- *** Bug 39918 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29090
[Bug target/39919] tmpdir-gcc.dg-struct-layout-1/t024 c_compat_x_tst.o-c_compat_y_tst.o execute fails at -m64
--- Comment #7 from iains at gcc dot gnu dot org 2010-07-24 08:00 --- *** This bug has been marked as a duplicate of 29090 *** -- iains at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39919
[Bug target/29090] gcc.dg-struct-layout-1 failures on Darwin PPC at -m64
--- Comment #17 from iains at gcc dot gnu dot org 2010-07-24 08:00 --- *** Bug 39919 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29090
[Bug target/29090] gcc.dg-struct-layout-1 failures on Darwin PPC at -m64
--- Comment #18 from iains at gcc dot gnu dot org 2010-07-24 08:00 --- *** Bug 39920 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29090
[Bug target/39920] tmpdir-gcc.dg-struct-layout-1/t026 c_compat_x_tst.o-c_compat_y_tst.o execute at -m64
--- Comment #7 from iains at gcc dot gnu dot org 2010-07-24 08:00 --- *** This bug has been marked as a duplicate of 29090 *** -- iains at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39920
[Bug target/29090] gcc.dg-struct-layout-1 failures on Darwin PPC at -m64
--- Comment #19 from iains at gcc dot gnu dot org 2010-07-24 08:01 --- *** Bug 39921 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29090
[Bug target/39921] tmpdir-gcc.dg-struct-layout-1/t027 c_compat_x_tst.o-c_compat_y_tst.o execute failure at -m64
--- Comment #7 from iains at gcc dot gnu dot org 2010-07-24 08:01 --- *** This bug has been marked as a duplicate of 29090 *** -- iains at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39921
[Bug target/18742] small struct not passed correctly as vararg
--- Comment #5 from iains at gcc dot gnu dot org 2010-07-24 08:08 --- fixed at least = 4.4 -- iains at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18742
[Bug target/29090] gcc.dg-struct-layout-1 failures on Darwin PPC at -m64
--- Comment #20 from iains at gcc dot gnu dot org 2010-07-24 08:41 --- http://gcc.gnu.org/ml/gcc-patches/2010-07/msg01944.html http://gcc.gnu.org/ml/gcc-patches/2010-07/msg01945.html -- iains at gcc dot gnu dot org changed: What|Removed |Added CC||iains at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29090
[Bug target/35491] wrong ABI for some struct passing with vector code
--- Comment #3 from iains at gcc dot gnu dot org 2010-07-24 08:41 --- http://gcc.gnu.org/ml/gcc-patches/2010-07/msg01944.html -- iains at gcc dot gnu dot org changed: What|Removed |Added CC||iains at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35491
[Bug c/45054] New: [4.6 regression] struct-by-value-1.c fail.
Executing on host: /Volumes/ScratchCS/gcc-4-6-trunk-build/gcc/xgcc -B/Volumes/ScratchCS/gcc-4-6-trunk-build/gcc/ /GCC/gcc-live-trunk/gcc/testsuite/gcc.dg/struct-by-value-1.c -O2 -lm -m32 -o ./struct-by-value-1.exe(timeout = 120) /GCC/gcc-live-trunk/gcc/testsuite/gcc.dg/struct-by-value-1.c: In function 'testit3': /GCC/gcc-live-trunk/gcc/testsuite/gcc.dg/struct-by-value-1.c:56:1: internal compiler error: in replace_pseudos_in, at reload1.c:609 Please submit a full bug report [possibly caused by 160947] -- Summary: [4.6 regression] struct-by-value-1.c fail. Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: iains at gcc dot gnu dot org GCC target triplet: powerpc-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45054
[Bug testsuite/44418] FAIL: gcc.target/powerpc/recip-[123].c on powerpc-apple-darwin9
--- Comment #6 from iains at gcc dot gnu dot org 2010-07-24 14:24 --- fixed -- iains at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44418
[Bug middle-end/44121] [4.6 Regression] multiple char-related fails.
--- Comment #16 from iains at gcc dot gnu dot org 2010-07-23 13:15 --- (In reply to comment #15) This seems fixed? well certainly not for 32 bit versions: as of r162456 (i686) just tested locally and... ... ppc (162433) http://gcc.gnu.org/ml/gcc-testresults/2010-07/msg02130.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44121
[Bug target/26262] Named section support should infer segment name
--- Comment #3 from iains at gcc dot gnu dot org 2010-07-20 14:17 --- (In reply to comment #2) This is still a problem. Iain, one for you? I'll take a shufftie.. ... can one overload attribute handling? (i.e. can I sneek a darwin-specific handler in via the target table in darwin.h .. or do I need to deal with this in c-family?) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26262
[Bug target/26262] Named section support should infer segment name
--- Comment #4 from iains at gcc dot gnu dot org 2010-07-20 14:34 --- having said that, isn't this just a problem of bad source code? if the target is darwin - then the section name should be specified appropriately surely? I guess filling it in automatically would be possible, by some kind of back-end manipulation if we detect that DECL_SECTION_NAME is set and the string is invalid.. ... but it seems a bit breakable (for example, if we get darwin working with gas...) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26262
[Bug c/43797] __attribute__((deprecated(message))) produces unexpected messages in some cases.
--- Comment #3 from iains at gcc dot gnu dot org 2010-07-18 11:52 --- http://gcc.gnu.org/ml/gcc-patches/2010-07/msg01432.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43797
[Bug testsuite/42843] --enable-build-with-cxx plugin tests fail
--- Comment #22 from iains at gcc dot gnu dot org 2010-07-17 07:20 ---
(In reply to comment #16)
Created an attachment (id=21188)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21188action=view) [edit]
proposed patch
This patch should restore the use of the previous stage compiler for plugins.
This is working fine in respect of putting the bootstrap compiler in and,
when --enable-build-with-cxx is given, the g++ plugins work on powerpc-darwin9.
When --enable-build-with-cxx is not given, several of them fail
(attribute_plugin-test-1, pragma_plugin-test-1, dumb-plugin-test-1).
This is because the compiler is ${objdir}/xgcc and the plugin names end .c
therefore they are built as standard c.
If it is intended that plugins for g++ should be build-able as straight 'c',
then there is an issue the plugin examples.
otherwise, we need to arrange the the plugins get built by g++ when they are
intended to be used within it.
(this is not as simple as changing their filenames to end .C, since the
includes are defined in lib/plugin-support.exp and they don't include any
consideration of the possibility that c++ headers might be needed).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42843
[Bug target/44862] bootstrap with --enable-build-with-cxx and --with-libiconv-prefix fails
--- Comment #7 from iains at gcc dot gnu dot org 2010-07-17 08:22 --- Subject: Bug 44862 Author: iains Date: Sat Jul 17 08:22:09 2010 New Revision: 162275 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162275 Log: 2010-07-17 Jack Howarth howa...@bromo.med.uc.edu PR target/44862 * Makefile.tpl (POSTSTAGE1_CXX_EXPORT): Provide -B option to allow for link spec %s substitutions for libstdc++.a on darwin. * Makefile.in: Regenerate. Modified: trunk/ChangeLog trunk/Makefile.in trunk/Makefile.tpl -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44862
[Bug testsuite/44418] FAIL: gcc.target/powerpc/recip-[123].c on powerpc-apple-darwin9
--- Comment #4 from iains at gcc dot gnu dot org 2010-07-17 11:16 --- http://gcc.gnu.org/ml/gcc-patches/2010-07/msg01407.html -- iains at gcc dot gnu dot org changed: What|Removed |Added CC||iains at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44418
[Bug testsuite/44418] FAIL: gcc.target/powerpc/recip-[123].c on powerpc-apple-darwin9
--- Comment #5 from iains at gcc dot gnu dot org 2010-07-17 14:51 --- Subject: Bug 44418 Author: iains Date: Sat Jul 17 14:51:20 2010 New Revision: 162277 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162277 Log: PR testsuite/44418 * gcc.target/powerpc/recip-1.c: Do not run for powerpc*-apple-darwin* * gcc.target/powerpc/recip-2.c: Ditto. * gcc.target/powerpc/recip-3.c: Ditto. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/powerpc/recip-1.c trunk/gcc/testsuite/gcc.target/powerpc/recip-2.c trunk/gcc/testsuite/gcc.target/powerpc/recip-3.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44418
[Bug testsuite/42843] --enable-build-with-cxx plugin tests fail
--- Comment #21 from iains at gcc dot gnu dot org 2010-07-16 08:39 --- Subject: Bug 42843 Author: iains Date: Fri Jul 16 08:39:37 2010 New Revision: 162254 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162254 Log: 2010-07-16 Jack Howarth howa...@bromo.med.uc.edu PR testsuite/42843 * gcc.dg/plugin/selfassign.c: Include diagnostic.h. * gcc.dg/plugin/ggcplug.c: Likewise. * g++.dg/plugin/selfassign.c: Likewise. * g++.dg/plugin/attribute_plugin.c: Likewise. * g++.dg/plugin/dumb_plugin.c: Likewise. * g++.dg/plugin/pragma_plugin.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/plugin/attribute_plugin.c trunk/gcc/testsuite/g++.dg/plugin/dumb_plugin.c trunk/gcc/testsuite/g++.dg/plugin/pragma_plugin.c trunk/gcc/testsuite/g++.dg/plugin/selfassign.c trunk/gcc/testsuite/gcc.dg/plugin/ggcplug.c trunk/gcc/testsuite/gcc.dg/plugin/selfassign.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42843
[Bug objc/44140] ObjC lto/whopr fails
--- Comment #18 from iains at gcc dot gnu dot org 2010-07-13 11:01 --- fixed -- iains at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44140
[Bug objc/44488] objc test inconsistencies w/ / w/out --enable-build-with-cxx
--- Comment #9 from iains at gcc dot gnu dot org 2010-07-13 15:20 --- Subject: Bug 44488 Author: iains Date: Tue Jul 13 15:20:21 2010 New Revision: 162144 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162144 Log: PR objc/44488 * lib/objc-torture.exp (objc-set-runtime-options): Base runtime list on the target. Make sure that we can assemble the emitted asm when the test type is 'compile'. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/lib/objc-torture.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44488
[Bug objc/44488] objc test inconsistencies w/ / w/out --enable-build-with-cxx
--- Comment #10 from iains at gcc dot gnu dot org 2010-07-13 15:32 --- of course, there should not be different behavior with/without --enable-build-with-cxx, so I guess that the test-suite fix is only part of the solution. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44488
[Bug middle-end/44276] [4.6 Regression]: gcc.dg/tls/alias-1.c
--- Comment #11 from iains at gcc dot gnu dot org 2010-07-13 20:30 --- (In reply to comment #9) (I could reply yes to your original question, however, but that's irrelevant; the simulator supports cris-axis-linux-gnu too, but you don't want to build for that target, it's a slightly more complicated. :) actually, on reflection, I do ... ... I assume that you're saying that building a sysroot is tricky? ... or is there one that's downloadable ? (BTW, this bug should be fixed v. soon) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44276
[Bug testsuite/42843] --enable-build-with-cxx plugin tests fail
--- Comment #10 from iains at gcc dot gnu dot org 2010-07-12 12:54 --- (In reply to comment #9) (In reply to comment #8) Perhaps we just need something like... In the native boostrap case, you probably want CC_FOR_TARGET / CFLAGS_FOR_TARGET / CXX_FOR_TARGET / CXXFLAGS_FOR_TARGET, but you still need COMPILER COMPILER_FLAGS (or its equivalent) in the case of non-bootstrap builds (native or otherwise). since the plugin is to run on the host, looking at the top level makefile HOST_EXPORTS defines CC - so, as you say, the current settings in gcc/Makefile are honoring that. However, it's clear that CC is ending up set to the bootstrap compiler and not the one built for stage2/3. I wonder if that means that HOST_EXPORTS needs to be re-written for each stage.. Is there any cross-tool known to support plugins? (I get no response for cris-elf, s390x, mipsia64 and armel-linux-gnueabi). No error, just silently skips all plugin tests. Or is there a requirement that the host compiler is = some gcc version in that case? -- iains at gcc dot gnu dot org changed: What|Removed |Added CC||iains at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42843
[Bug testsuite/42843] --enable-build-with-cxx plugin tests fail
--- Comment #12 from iains at gcc dot gnu dot org 2010-07-12 13:19 --- (In reply to comment #10) Is there any cross-tool known to support plugins? (I get no response for cris-elf, s390x, mipsia64 and armel-linux-gnueabi). No error, just silently skips all plugin tests. hmm this is a configury/make issue (possibly darwin-specific), I suspect that the switch changes to deal with linker attributes are being driven on target keys and not on host ones. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42843
[Bug testsuite/42843] --enable-build-with-cxx plugin tests fail
--- Comment #13 from iains at gcc dot gnu dot org 2010-07-12 13:28 ---
(In reply to comment #12)
(In reply to comment #10)
Is there any cross-tool known to support plugins? (I get no response for
cris-elf, s390x, mipsia64 and armel-linux-gnueabi). No error, just silently
skips all plugin tests.
hmm this is a configury/make issue (possibly darwin-specific),
I suspect that the switch changes to deal with linker attributes are being
driven on target keys and not on host ones.
nope, not that :
case ${host} in
*-*-darwin*)
CFLAGS=`echo $CFLAGS | sed s/-mdynamic-no-pic//g` == a local change I
made for powerpc.
CFLAGS=$CFLAGS -fPIC
LDFLAGS=$LDFLAGS -shared -undefined dynamic_lookup
;;
*)
CFLAGS=$CFLAGS -fPIC
LDFLAGS=$LDFLAGS -fPIC -shared
;;
esac
I'll have to check the config.log more carefully.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42843
[Bug testsuite/42843] --enable-build-with-cxx plugin tests fail
--- Comment #14 from iains at gcc dot gnu dot org 2010-07-12 15:00 ---
(In reply to comment #13)
I'll have to check the config.log more carefully.
OK. possible a can of wiggly things here...
case ${host} in
*-*-darwin*)
export_sym_check=$gcc_cv_nm -g === maybe these need to be $NM
;;
*)
export_sym_check=$gcc_cv_objdump -T ... and $OBJDUMP in any
event, the correct host tool
;;
esac
looks fine - until you find that gcc_cv_nm is being set to
../binutils/nm == nm-for-target
when host==build (and we've built the tool).
AS_VAR_SET_IF(gcc_cv_nm,, [
if test -f $gcc_cv_binutils_srcdir/configure.in \
test -f ../binutils/Makefile \
test x$build = x$host; then
gcc_cv_nm=../binutils/nm-new$build_exeext
elif test -x nm$build_exeext; then
gcc_cv_nm=./nm$build_exeext
elif test -x $NM_FOR_TARGET; then
gcc_cv_nm=$NM_FOR_TARGET
else
AC_PATH_PROG(gcc_cv_nm, $NM_FOR_TARGET)
fi])
I'm not sure what the right version of nm/objdump is - but clearly, one for
the host not the target ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42843
[Bug objc/41848] Extra Objective C test failures because of section anchors.
--- Comment #6 from iains at gcc dot gnu dot org 2010-07-12 19:15 --- (In reply to comment #5) I do not see the fails shown in: http://gcc.gnu.org/ml/gcc-testresults/2010-07/msg00563.html with my current tree [162035] - but I'm using simulator combined tree build - with glibc from a Debian distribution (I forget which, but can check if it's important). -(hopefully) Andrew's analysis is correct (but, I guess I'd like to know why it fixed them ... ).. the fails are gone at: http://gcc.gnu.org/ml/gcc-testresults/2010-07/msg01082.html which is the first result post 162030 - consistent. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41848
[Bug testsuite/44518] [4.5/4.6 regression] objc++ encode-2.mm and encode-3.mm fail on several platforms
--- Comment #12 from iains at gcc dot gnu dot org 2010-07-11 09:55 --- back-ported to 4.5 as r162037, closing as fixed -- iains at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44518
[Bug objc/44488] objc test inconsistencies w/ / w/out --enable-build-with-cxx
--- Comment #7 from iains at gcc dot gnu dot org 2010-07-10 10:38 --- Created an attachment (id=21173) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21173action=view) improve robustness of runtime option choices. This should resolve the case where -fnext-runtime would be considered valid (for compile tests) because the target (non-darwin) system happened to have objc headers in the same place as a standard darwin installation. Tested on i686-apple-darwin9 [build --enable-build-with-cxx] , cris-elf (sim) and mipsabi64-elf (sim) with no changes in fails or counts on make check-gcc-objc. let me know if it solve that aspect of the problem for you. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44488
[Bug objc/41848] Extra Objective C test failures because of section anchors.
--- Comment #2 from iains at gcc dot gnu dot org 2010-07-10 16:43 --- is this still current? I can't reproduce any compile problems on arm-unknown-eabi or armel-unknown-gnueabi (as cross-tools hosted under i686-apple-darwin). -- iains at gcc dot gnu dot org changed: What|Removed |Added CC||iains at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41848
[Bug objc/41848] Extra Objective C test failures because of section anchors.
--- Comment #5 from iains at gcc dot gnu dot org 2010-07-10 19:40 --- I do not see the fails shown in: http://gcc.gnu.org/ml/gcc-testresults/2010-07/msg00563.html with my current tree [162035] - but I'm using simulator combined tree build - with glibc from a Debian distribution (I forget which, but can check if it's important). -(hopefully) Andrew's analysis is correct (but, I guess I'd like to know why it fixed them ... ).. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41848
[Bug bootstrap/44146] r159371 breaks bootstrap on x86_64-apple-darwin10
--- Comment #24 from iains at gcc dot gnu dot org 2010-07-10 19:48 --- AFAIK this has been cleared for some time now. -- iains at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44146
[Bug middle-end/44121] [4.6 Regression] multiple char-related fails.
--- Comment #13 from iains at gcc dot gnu dot org 2010-07-11 00:25 --- this is still present, AFAICT, for *-*-darwin* at r162047. Honza, since it was your patch that triggered this, any ideas on what we could do to debug/solve this one? in particular this; error: Inline clone with address taken is still happening. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44121
[Bug objc/44488] objc test inconsistencies w/ / w/out --enable-build-with-cxx
--- Comment #6 from iains at gcc dot gnu dot org 2010-07-09 23:40 --- (In reply to comment #4) Is the compiler supposed to ignore an installed objc gnu runtime when testing in the build directory with -fnext-runtime? Well, it's actually the other way round - it needs to find the pre-installed one on a Darwin system to succeed for NeXT (which happens to be in /usr/include/objc). That path is built into the compiler. I guess it's generally the case (across various parts of the test suite) that installed versions can, unfortunately, interfere with uninstalled testing. I will try to refine the test in some way to make this less likely to happen. The -fnext-runtime flag should be tested on anything other than a Darwin system (although most, if not all, of the compile tests would succeed it's kinda pointless). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44488
[Bug objc/44140] ObjC lto/whopr fails
--- Comment #17 from iains at gcc dot gnu dot org 2010-07-10 00:22 --- Subject: Bug 44140 Author: iains Date: Sat Jul 10 00:22:35 2010 New Revision: 162030 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162030 Log: make ObjC do LTO. gcc/ PR objc/44140 * config/darwin.c (output_objc_section_asm_op): Save and restore section when outputting ObjC section list. testsuite/ PR objc/44140 * objc.dg/lto/trivial-1_0.m: New. * objc.dg/lto/lto.exp: New. * obj-c++.dg/lto/trivial-1_0.mm: New. * obj-c++.dg/lto/lto.exp: New. * objc.dg/symtab-1.m: Adjust sizes. * objc.dg/image-info.m: Do not run for gnu-runtime. gcc/objc/ PR objc/44140 * objc-act.c: build_objc_string_decl() remove declaration. (finish_var_decl): Remove forcing of var output and marking as Used. (init_def_list): Use integer_zero_node. (init_objc_symtab): Use integer_zero_node, make the short integer type specific on relevant nodes. (generate_objc_symtab_decl): Remove call to forward_declare_categories(). Use null_pointer_node where appropriate. (build_module_descriptor): Comment and mark this item as DECL_PRESERVE_P. (generate_static_references): Use gcc_unreachable instead of abort (). (diagnose_missing_method): New. (build_next_selector_translation_table): New. (build_gnu_selector_translation_table): New. (add_objc_string): Merge code from build_objc_string_decl... ... and delete build_objc_string_decl(). (generate_dispatch_table): Make integer types explicit. (generate_category): Pass implent and arrange for the data to be extracted within the routine. Do not start new vars, but finish the ones collcted during parsing. (generate_shared_structures): Likewise. (finish_objc): Reorder code so that we finish variables before referencing them. Save the global data before calling meta-data creation routines, and pass the current reference to the two main routines. Only call generate_objc_image_info () for the NeXT runtime. (generate_classref_translation_entry): Comment on and make this item DECL_PRESERVE_P. (handle_class_ref): Use varpool interfaces, comment on and make this item DECL_PRESERVE_P. (handle_impent): Likewise. (generate_objc_image_info): Only generate when the content is non-zero. Make integer types explict. Added: trunk/gcc/testsuite/obj-c++.dg/lto/ trunk/gcc/testsuite/obj-c++.dg/lto/lto.exp trunk/gcc/testsuite/obj-c++.dg/lto/trivial-1_0.mm trunk/gcc/testsuite/objc.dg/lto/ trunk/gcc/testsuite/objc.dg/lto/lto.exp trunk/gcc/testsuite/objc.dg/lto/trivial-1_0.m Modified: trunk/gcc/ChangeLog trunk/gcc/config/darwin.c trunk/gcc/objc/ChangeLog trunk/gcc/objc/objc-act.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/objc.dg/image-info.m trunk/gcc/testsuite/objc.dg/symtab-1.m -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44140
[Bug testsuite/44518] [4.5/4.6 regression] objc++ encode-2.mm and encode-3.mm fail on several platforms
--- Comment #11 from iains at gcc dot gnu dot org 2010-07-03 08:16 --- Subject: Bug 44518 Author: iains Date: Sat Jul 3 08:15:59 2010 New Revision: 161769 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161769 Log: 2010-07-03 Iain Sandoe ia...@gcc.gnu.org Mikael Pettersson mi...@it.uu.se PR testsuite/44518 * obj-c++.dg/encode-2.mm: Produce object and save temps. Make signed-ness of chars explicit. Scan the object for strings that are split by some target assemblers. * obj-c++.dg/encode-3.mm: Make the signed-ness of chars explicit. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/obj-c++.dg/encode-2.mm trunk/gcc/testsuite/obj-c++.dg/encode-3.mm -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44518
[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.
--- Comment #41 from iains at gcc dot gnu dot org 2010-07-03 16:45 --- this should do it, asm problems solved. http://gcc.gnu.org/ml/gcc-patches/2010-07/msg00262.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44132
[Bug objc/35165] Massive failures of objc on i686-apple-darwin9
--- Comment #18 from iains at gcc dot gnu dot org 2010-07-02 10:23 --- additional tweaks: r161687 (trunk) r161688 (4.5). r161692 (trunk) r161693 (4.5) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35165
[Bug testsuite/44651] gcc.target/x86_64/abi/callabi/leaf-[1,2].c fail on darwin
--- Comment #4 from iains at gcc dot gnu dot org 2010-07-01 17:45 --- confirmed, also on i686-apple-darwin9 @ m64 -- iains at gcc dot gnu dot org changed: What|Removed |Added CC||iains at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-07-01 17:45:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44651
[Bug bootstrap/44699] [4.6 Regression] Bootstrap failure for x86_64-apple-darwin10: ICE while compiling genmodes.c
--- Comment #14 from iains at gcc dot gnu dot org 2010-06-30 08:39 --- (In reply to comment #13) @r161591 with this: The patch in http://gcc.gnu.org/ml/gcc-patches/2010-06/msg03011.html (and the patch to correct emit_unwind_label) === I no longer get the build_real fail - but this instead : /GCC/gcc-live-trunk/gcc/coverage.c: In function htab_counts_entry_hash: /GCC/gcc-live-trunk/gcc/coverage.c:151:1: error: unrecognizable insn: (insn 28 7 29 2 /GCC/gcc-live-trunk/gcc/coverage.c:150 (set (reg:DI 1 dx) (mem/s:SI (plus:DI (reg/v/f:DI 5 di [orig:64 of ] [64]) (const_int 4 [0x4])) [8 entry_2-ctr+0 S4 A32])) -1 (nil)) /GCC/gcc-live-trunk/gcc/coverage.c:151:1: internal compiler error: in extract_insn, at recog.c:2127 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44699
[Bug bootstrap/44699] [4.6 Regression] Bootstrap failure for x86_64-apple-darwin10: ICE while compiling genmodes.c
--- Comment #15 from iains at gcc dot gnu dot org 2010-06-30 08:59 --- (In reply to comment #14) (In reply to comment #13) @r161591 with this: The patch in http://gcc.gnu.org/ml/gcc-patches/2010-06/msg03011.html (and the patch to correct emit_unwind_label) === I no longer get the build_real fail - but this instead : /GCC/gcc-live-trunk/gcc/coverage.c: In function htab_counts_entry_hash: /GCC/gcc-live-trunk/gcc/coverage.c:151:1: error: unrecognizable insn: (insn 28 7 29 2 /GCC/gcc-live-trunk/gcc/coverage.c:150 (set (reg:DI 1 dx) (mem/s:SI (plus:DI (reg/v/f:DI 5 di [orig:64 of ] [64]) (const_int 4 [0x4])) [8 entry_2-ctr+0 S4 A32])) -1 (nil)) /GCC/gcc-live-trunk/gcc/coverage.c:151:1: internal compiler error: in extract_insn, at recog.c:2127 ah, that's PR44721 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44699
[Bug other/44034] target hooks are hard to maintain
--- Comment #7 from iains at gcc dot gnu dot org 2010-06-30 14:34 --- Subject: Bug 44034 Author: iains Date: Wed Jun 30 14:33:40 2010 New Revision: 161606 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161606 Log: PR other/44034 * config/darwin.c (darwin_override_options): Use renamed targetm.asm_out.emit_unwind_label. Modified: trunk/gcc/ChangeLog trunk/gcc/config/darwin.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44034
[Bug bootstrap/44699] [4.6 Regression] Bootstrap failure for x86_64-apple-darwin10: ICE while compiling genmodes.c
--- Comment #12 from iains at gcc dot gnu dot org 2010-06-29 18:45 --- also fails when the bootstrap compiler is gcc-4.2 (apple 4.2.1). i688-apple-darwin9 is ok for the same trunk rev. -- iains at gcc dot gnu dot org changed: What|Removed |Added CC||iains at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44699
[Bug bootstrap/44720] [4.6 Regression] Yet another bootstrap failure on x86_64-apple-darwin10
--- Comment #1 from iains at gcc dot gnu dot org 2010-06-29 20:33 --- http://gcc.gnu.org/ml/gcc-patches/2010-06/msg03042.html -- iains at gcc dot gnu dot org changed: What|Removed |Added CC||iains at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44720
[Bug bootstrap/44509] [4.6 Regression] Revision 160626 breaks bootstrap on *-apple-darwin*
--- Comment #15 from iains at gcc dot gnu dot org 2010-06-13 11:35 --- powerpc64-darwin9; failed in stage3: In file included from /usr/include/math.h:26:0, from /GCC/gcc-live-trunk/gcc/genautomata.c:117: /usr/include/architecture/ppc/math.h: In function â__inline_isnormalfâ: /usr/include/architecture/ppc/math.h:216:3: internal compiler error: in lazy_hex_fp_value, at c-family/c-cppbuiltin.c:987 when I re-ran bootstrap as a single process - I noticed the following warnings: --- number -I/GCC/gcc-live-trunk/gcc/../libdecnumber/dpd -I../libdecnumber \ -o build/gencondmd.o build/gencondmd.c /GCC/gcc-live-trunk/gcc/config/rs6000/rs6000.md:5608:1: warning: implicit declaration of function âRS6000_RECIP_HAVE_RSQRT_Pâ [-Wimplicit-function-declaration] --- -DBASEVER=\4.6.0\ /GCC/gcc-live-trunk/gcc/c-family/c-cppbuiltin.c -o c-family/c-cppbuiltin.o /GCC/gcc-live-trunk/gcc/c-family/c-cppbuiltin.c: In function âbuiltin_define_with_hex_fp_valueâ: /GCC/gcc-live-trunk/gcc/c-family/c-cppbuiltin.c:1023:7: warning: enum conversion in assignment is invalid in C++ [-Wc++-compat] - -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44509
[Bug testsuite/44518] [4.5/4.6 regression] objc++ encode-2.mm and encode-3.mm fail on several platforms
--- Comment #2 from iains at gcc dot gnu dot org 2010-06-13 15:26 --- Subject: Bug 44518 Author: iains Date: Sun Jun 13 15:26:22 2010 New Revision: 160682 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160682 Log: partial reversion of r160541. PR testsuite/44518 * obj-c++.dg/encode-2.mm: XFAIL new test for all targets. * obj-c++.dg/encode-3.mm: Restore XFAIL run for all targets. Modified: branches/gcc-4_5-branch/gcc/testsuite/ChangeLog branches/gcc-4_5-branch/gcc/testsuite/obj-c++.dg/encode-2.mm branches/gcc-4_5-branch/gcc/testsuite/obj-c++.dg/encode-3.mm -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44518
[Bug testsuite/44518] [4.5/4.6 regression] objc++ encode-2.mm and encode-3.mm fail on several platforms
--- Comment #3 from iains at gcc dot gnu dot org 2010-06-13 15:31 --- (In reply to comment #1) Ian - testsuite regressions are not acceptable on the branch (XPASSes are ok though). Well, of course, the patch did not cause any regressions on targets I have access to. These now XPASS. I need to find out what the failing targets have in common (apart from me not having access). I'll see about making some cross-tools. powerpc*-darwin9 passes and, apparently, *86*-linux-gnu (I checked Lu's output) - so there's a permutation that needs covering. thanks for letting me know. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44518
[Bug testsuite/44518] [4.5/4.6 regression] objc++ encode-2.mm and encode-3.mm fail on several platforms
--- Comment #6 from iains at gcc dot gnu dot org 2010-06-13 17:04 --- (In reply to comment #4) (In reply to comment #3) powerpc*-darwin9 passes and, apparently, *86*-linux-gnu (I checked Lu's output) I've scanned the gcc-testresults list archive for May and June quite carefully, and I don't think anyone is testing obj-c++ on i686 or x86_64 linux. I always test i686-pc-linux-gnu .. and some of the regression test machines include various permutations. Hopefully, I'll be able to test x86_64 in the not-too-distant future. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44518
[Bug testsuite/44518] [4.5/4.6 regression] objc++ encode-2.mm and encode-3.mm fail on several platforms
--- Comment #7 from iains at gcc dot gnu dot org 2010-06-13 17:07 ---
(In reply to comment #5)
Created an attachment (id=20903)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20903action=view) [edit]
correction to encode-2.mm
On powerpc64 encode-2.mm fails because the test case scans the assembly output
for the string {?={Vecdouble=ddi}{Vecfloat=ffi}fd{Vecchar=cci}i}, but
on
powerpc64 it is {?={Vecdouble=ddi}{Vecfloat=ffi}fd{Vecchar=CCi}i}.
Note the different case for the CC part. That's because the test case
instantiates a Vec with plain char and expects it to mangle to c. However,
plain char maps to either signed or unsigned char depending on the machine,
and
those two types mangle differently. Apparently c corresponds to signed
char.
Adjusting the test case to explicitly say signed char fixes it on powerpc64.
Indeed, good catch, thanks.
I'll stick that in the melting pot for the next round - there are other encode
updates needed.
Too late to do any more for 4.5.1 anyway, I suspect.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44518
[Bug testsuite/44518] [4.5/4.6 regression] objc++ encode-2.mm and encode-3.mm fail on several platforms
--- Comment #9 from iains at gcc dot gnu dot org 2010-06-13 17:20 ---
(In reply to comment #8)
On ARM encode-2.mm fails in part for the same plain char mangles differently
reason as on powerpc64, but also due to a backend oddity. Here's how the
string is output in the assembly file on ARM:
.ascii {?={Vecdouble=ddi}{Vecfloat=ffi}fd{Vecchar=CC
.ascii i}i}\000
For some reason the ARM backend breaks not very long string literals into
chunks. That's ok in principle because the data is correct in the object
file,
but it means that testsuite scan-assembler operations become unreliable.
Ideally the test should scan the object file for the string instead, but there
doesn't seem to be a way to do that.
It seems gcc on i686 will also break up long string literals, but it allows
for
much much longer strings before doing that.
I can put a target-specific scanasm (once I know what to scan for). They look
a little unwieldy - but they work.
Just having a go at making some cross-tools - at least that's a start for asm
syntax issues.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44518
[Bug testsuite/25763] objc.dg/stubify-*.m, and obj-c++.dg/stubify-*.mm fail on i686-darwin
--- Comment #5 from iains at gcc dot gnu dot org 2010-06-11 08:32 --- closing as fixed after back-porting to the 4.5 release branch at r160482 -- iains at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25763
