[Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93492 --- Comment #33 from Mike Stump --- Please, unless you expect it to work in an OS independent way, please conditionalize on the systems it is known to work on, meaning, it important for it to work on it, you think all the work for it to work on

[Bug target/52795] FAIL: gcc.dg/tree-prof/pr34999.c compilation, -fprofile-use -D_PROFILE_USE on {x86_64,i386}-apple-darwin{10,11} at -m64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52795 --- Comment #15 from Mike Stump --- Can the bug be marked as resolved? :-)

[Bug bootstrap/78251] config/gettext.m4 and config/iconv.m4 contaminate CPPFLAGS

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78251 --- Comment #3 from Mike Stump --- I've been avoiding this bug for years by just removing the unwind.h header. :-(

[Bug bootstrap/81037] Xcode 9 requires back ports on gcc-5-branch and gcc-6-branch for bootstrapping under Xcode 9

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81037 --- Comment #5 from Mike Stump --- Fixed in 6.4. Leaving open for 5 backports.

[Bug testsuite/80221] Contrib script to rewrite testcase from absolute to relative line numbers

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80221 --- Comment #6 from Mike Stump --- Comment on attachment 41059 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41059 Result from running script The . and .-1, .+1, .-2 forms are fine. The .-62 forms are as problematic as the original I

[Bug testsuite/80221] Contrib script to rewrite testcase from absolute to relative line numbers

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80221 Mike Stump changed: What|Removed |Added CC||mikestump at comcast dot net --- Comment

[Bug target/57438] bootstrap fails on x86_64 darwin in stage2 linking cc1

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438 --- Comment #31 from Mike Stump --- On Nov 6, 2016, at 12:22 PM, iains at gcc dot gnu.org wrote: > I have backports for 6.x and 5.x if wanted. Yes please. I think it is safe enough and the problem is really kinda

[Bug target/66509] the new clang-based assembler in Xcode 7 on 10.11 fails on the libjava/java/lang/reflect/natArray.cc file from FSF gcc 5.1 at -m32

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66509 --- Comment #12 from Mike Stump mikestump at comcast dot net --- Here is a case where we wish for actual feature testing of all the bits instead of the coarse grain, are we FSF gas 2.9 or later. Default should be things work nicely

[Bug testsuite/20567] dg-options in gcc.c-torture

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20567 Mike Stump mikestump at comcast dot net changed: What|Removed |Added CC||mikestump

[Bug bootstrap/63188] [5 Regression] r214954 breaks bootstrap on x86_64-apple-darwin13

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63188 Mike Stump mikestump at comcast dot net changed: What|Removed |Added CC||mikestump

[Bug target/61396] [4.10 regression] ICE in simplify_immed_subreg

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61396 --- Comment #7 from Mike Stump mikestump at comcast dot net --- So when you compose the svn comments, compose them from a cut and paste of sed 20q ChangeLog, exactly. In this case, you did this: rs6000: fix for PR61396 (wide-int fallout

[Bug target/60732] FAIL: g++.dg/ext/altivec-7.C -std=* scan-assembler _Z3fooDv*

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60732 --- Comment #9 from Mike Stump mikestump at comcast dot net --- So, I’m still left wondering if the difference in behavior between linux and darwin is a bug in itself or not… Do we know which code or what change gives rise to that?

[Bug other/61146] wide-int error when building GCC with clang

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61146 --- Comment #15 from Mike Stump mikestump at comcast dot net --- Short answer, error checking. Remove them and one removes some error checking.

[Bug other/61146] wide-int error when building GCC with clang

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61146 --- Comment #19 from Mike Stump mikestump at comcast dot net --- Nope.

[Bug c++/41090] [4.7/4.8/4.9 Regression] Using static label reference in c++ class constructor produces wrong code

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41090 --- Comment #24 from Mike Stump mikestump at comcast dot net --- Thanks for the fix and the update guys.

[Bug bootstrap/47016] bootstrap on darwin needs much more disk space than expected to complete

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47016 --- Comment #5 from Mike Stump mikestump at comcast dot net --- Let's see if Iain needs it for anything…

[Bug bootstrap/48474] gcc fails to bootstrap

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48474 --- Comment #4 from Mike Stump mikestump at comcast dot net --- patches to the gcc-patches list get lost and ignored. Bugzilla is forever. Looks like I chose wisely.

[Bug target/58269] [4.9 Regression] ICE when building libobjc on x86_64-apple-darwin* after revision 201915

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58269 --- Comment #18 from Mike Stump mikestump at comcast dot net --- On Sep 6, 2013, at 8:43 AM, howarth at nitro dot med.uc.edu gcc-bugzi...@gcc.gnu.org wrote: * i386.c (ix86_hard_regno_mode_ok): AVX modes are valid only when

[Bug target/58269] [4.9 Regression] ICE when building libobjc on x86_64-apple-darwin* after revision 201915

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58269 --- Comment #21 from Mike Stump mikestump at comcast dot net --- Don't know… I'd assume there exists a paper somewhere that says it. :-)

[Bug target/57753] FSF gcc bootstrap needs to use xcrun to bootstrap post-darwin12

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57753 --- Comment #3 from Mike Stump mikestump at comcast dot net --- These should go in config/*darwin* I think.

[Bug bootstrap/57438] bootstrap fails on x86_64 darwin in stage2 linking cc1

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438 --- Comment #9 from Mike Stump mikestump at comcast dot net --- If you can attach the .s file for varasm.c that does result in the crash that would be good. If this is a regression, identifying the change that broken it would be handy. Thanks.

[Bug target/54257] gcc.target/i386/pr53249.c failure at -m64 on x86_64-apple-darwin

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54257 --- Comment #3 from Mike Stump mikestump at comcast dot net 2012-08-20 16:24:49 UTC --- Looks good to me... HJ?

[Bug testsuite/53028] add dg-pedantic

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53028 --- Comment #11 from Mike Stump mikestump at comcast dot net 2012-04-30 01:08:24 UTC --- also don't test that the warning goes away with -w. We don't test the warning turns into an error with -Werror. Don't we? http://gcc.gnu.org/ml

[Bug testsuite/53028] add dg-pedantic

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53028 --- Comment #9 from Mike Stump mikestump at comcast dot net 2012-04-24 00:31:35 UTC --- Since little proof was added to support the assertion that the additional testing is useful, I can remain skeptical about it, though, the CFE people certainly

[Bug testsuite/53028] add dg-pedantic

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53028 --- Comment #2 from Mike Stump mikestump at comcast dot net 2012-04-18 17:35:23 UTC --- I don't see much value in this. The primary idea of the gcc testsuite is as a regression suite. For a regression, there is just one bit of code that you're

[Bug testsuite/53028] add dg-pedantic

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53028 --- Comment #4 from Mike Stump mikestump at comcast dot net 2012-04-18 20:01:23 UTC --- You explained yourself properly. Just because there are hundreds that do this, doesn't mean that I necessarily agree with them. Personally, I'd rip out all

[Bug testsuite/53028] add dg-pedantic

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53028 --- Comment #6 from Mike Stump mikestump at comcast dot net 2012-04-18 22:42:55 UTC --- So, do you have a pointer to where a maintainer said that they require 3 duplicates for a piece of work? For all similar future work? They usually say

[Bug boehm-gc/52179] boehm-gc incompatible with aslr on darwin11

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52179 --- Comment #20 from Mike Stump mikestump at comcast dot net 2012-02-23 18:45:28 UTC --- Where do you want the second change made? Let me repeat myself: the code is in boehm-gc/include/private/gcconfig.h, so the patch should change the ifdef

[Bug boehm-gc/52179] boehm-gc incompatible with aslr on darwin11

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52179 --- Comment #23 from Mike Stump mikestump at comcast dot net 2012-02-23 18:56:31 UTC --- I think the patch in 17 is Ok.

[Bug boehm-gc/52179] boehm-gc incompatible with aslr on darwin11

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52179 --- Comment #25 from Mike Stump mikestump at comcast dot net 2012-02-23 21:53:04 UTC --- Ok.

[Bug boehm-gc/52179] boehm-gc incompatible with aslr on darwin11

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52179 --- Comment #10 from Mike Stump mikestump at comcast dot net 2012-02-23 04:34:30 UTC --- The proposed patch is wrong, the code is in boehm-gc/include/private/gcconfig.h, so the patch should change the ifdef DARWIN block there. I don't know why

[Bug boehm-gc/52179] boehm-gc incompatible with aslr on darwin11

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52179 --- Comment #11 from Mike Stump mikestump at comcast dot net 2012-02-23 04:56:55 UTC --- Ah, the better way to do that would be to have: AC_CHECK_FUNCS([pthread_get_stackaddr_np]) in configure.ac, and then just have #ifdef

[Bug target/52268] tls support should be added for darwin11

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52268 --- Comment #1 from Mike Stump mikestump at comcast dot net 2012-02-16 17:15:47 UTC --- If you could snapshot some codegen, say void foo() { static __thread int i = 42; ++i; } or somesuch, we could see if they wired it up the same

[Bug libitm/52220] FAIL: libitm.c++/eh-1.C execution test due to Xcode 4 weakref linker bug

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52220 --- Comment #4 from Mike Stump mikestump at comcast dot net 2012-02-16 17:16:39 UTC --- Thanks.

[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906 --- Comment #52 from Mike Stump mikestump at comcast dot net 2012-02-03 20:44:16 UTC --- OK. I'd missed that - in which case no objection to the unconditional disable from me. We can even fixincludes it away! I'm fine with #undef or some

[Bug target/45233] FAIL: gcc.c-torture/compile/pr44707.c

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45233 --- Comment #9 from Mike Stump mikestump at comcast dot net 2011-11-09 17:03:21 UTC --- Ok. Yeah, combine has a habit of removing a complex thing at one point and rebuilding at another point, mainly to shorten the lifetime. Mentally, I guess I

[Bug lto/50876] unrecognized command line option '-Zmultiply_defined suppress regressions for lto.exp on x86_64-apple-darwin11

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50876 --- Comment #2 from Mike Stump mikestump at comcast dot net 2011-10-26 21:12:58 UTC --- Do we know what patch broke this?

[Bug lto/49992] lto-bootstrap reveals duplicate symbols on x86_64-apple-darwin11

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49992 --- Comment #42 from Mike Stump mikestump at comcast dot net 2011-08-11 13:26:18 UTC --- Ick. Oh well. Ok, how about outright removing for all darwin releases the -c setting? I think the only thing this could break was fortran. I have no clue

[Bug target/49992] lto-bootstrap reveals duplicate symbols on x86_64-apple-darwin11

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49992 --- Comment #45 from Mike Stump mikestump at comcast dot net 2011-08-11 16:32:50 UTC --- On Aug 11, 2011, at 6:48 AM, iains at gcc dot gnu.org wrote: It's on my TODO to bootstrap a version of ADA - I guess that means doing a canadian from linux

[Bug lto/49992] lto-bootstrap reveals duplicate symbols on x86_64-apple-darwin11

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49992 --- Comment #27 from Mike Stump mikestump at comcast dot net 2011-08-09 17:29:28 UTC --- So, the fix is trivial but you guys are wondering in the weeds. Make the symbols unique and be done with it, that, or remove one of them. You are getting

[Bug lto/49992] lto-bootstrap reveals duplicate symbols on x86_64-apple-darwin11

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49992 --- Comment #29 from Mike Stump mikestump at comcast dot net 2011-08-09 17:55:15 UTC --- From the thread last time we talked about this code: http://gcc.gnu.org/ml/gcc-patches/2002-12/msg01183.html

[Bug lto/49992] lto-bootstrap reveals duplicate symbols on x86_64-apple-darwin11

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49992 --- Comment #33 from Mike Stump mikestump at comcast dot net 2011-08-09 20:58:15 UTC --- The patches are wrong, so, I don't favor them. The patch to fix this, is the patch to either boost things to -fno-common, or to fix trim_filename.

[Bug driver/49371] xgcc: error: unrecognized option '-pie' on *-apple-darwin*

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49371 --- Comment #22 from Mike Stump mikestump at comcast dot net 2011-06-13 03:32:11 UTC --- Ok. (When the engineering work is done.)

[Bug testsuite/48506] ssa-ccp-17.c = g.i fails

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48506 --- Comment #5 from Mike Stump mikestump at comcast dot net 2011-04-08 22:35:19 UTC --- Ah, insight, this is a no-common port I'm working on, so indeed an initializer would fix it for me.

[Bug testsuite/48506] ssa-ccp-17.c = g.i fails

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48506 --- Comment #6 from Mike Stump mikestump at comcast dot net 2011-04-08 22:41:16 UTC --- How about something like the below. I't leaves the scan alone (nice property), ensures there is a memory access and will work on common and no-common ports

[Bug bootstrap/48474] gcc fails to bootstrap

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48474 --- Comment #2 from Mike Stump mikestump at comcast dot net 2011-04-07 19:41:04 UTC --- I'd expect that I could change the target to make things compile. The point of the bug report was to report a rough edge where if one doesn't define

[Bug target/48301] Xcode 4.0's llvm-gcc can't bootstrap gcc 4.6.0 or trunk

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48301 --- Comment #4 from Mike Stump mikestump at comcast dot net 2011-03-28 17:41:36 UTC --- If there is an easy work around in gcc to avoid the problem, we could entertain that, but, generally, I'd be more interested in clang failures going forward

[Bug bootstrap/44107] libstdc++ (dylib) is built with an erroneous dependency towards /usr/lib

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107 --- Comment #15 from Mike Stump mikestump at comcast dot net 2011-03-21 18:53:12 UTC --- I'd trust the person doing the work. :-) They usually have more state on exactly what problem they are fixing and if the work for any one bug covers

[Bug bootstrap/44107] libstdc++ (dylib) is built with an erroneous dependency towards /usr/lib

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107 --- Comment #3 from Mike Stump mikestump at comcast dot net 2011-03-19 09:49:35 UTC --- With an appropriate DYLD_LIBRARY_PATH, the problem disappears. So, can you elaborate? Which value makes the problem disappear? I'd assume you if you

[Bug objc/39753] [4.3/4.4/4.5/4.6/4.7 Regression] Objective-C(++) and C90 strict-aliasing interaction bug

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39753 --- Comment #12 from Mike Stump mikestump at comcast dot net 2011-03-19 03:58:25 UTC --- Any warnings generated that are invalid are bugs. These bugs should be filed, and we'll fix them. Please attach an example file that generate warnings.

[Bug objc/48109] Objective-C class defs/refs are lost under LTO on Darwin for ABI0/1

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48109 --- Comment #1 from Mike Stump mikestump at comcast dot net 2011-03-14 10:23:19 UTC --- Not sure it matters, but, marking them as used should be enough... Note, there are a couple of ways to mark things. TREE_USED and the lto incantation.

[Bug target/48108] lto should be containerized in a single mach-o section on darwin

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48108 --- Comment #4 from Mike Stump mikestump at comcast dot net 2011-03-14 23:34:38 UTC --- WDYT? Sounds fine to me.

[Bug objc/48109] Objective-C class defs/refs are lost under LTO on Darwin for ABI0/1

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48109 --- Comment #8 from Mike Stump mikestump at comcast dot net 2011-03-14 23:39:21 UTC --- Seems reasonable to me...

[Bug lto/48086] bootstrap-lto creates c-common.s with too many sections on x86_64-apple-darwin10

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48086 --- Comment #20 from Mike Stump mikestump at comcast dot net 2011-03-14 03:09:08 UTC --- I'm ambivalent. If people developing or following would like one, feel free to create one. Depending on how safe it is, we could put it in sooner

[Bug lto/48108] lto should be containerized in a single mach-o section on darwin

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48108 --- Comment #2 from Mike Stump mikestump at comcast dot net 2011-03-14 03:13:27 UTC --- Another fix might be to have pure elf .o files... ld I think will read elf .o files... [s] Don't tell anyone I said that. If not, we might be able

[Bug target/47997] gcc on macosx: ld: warning: -fwritable-strings not compatible with literal CF/NSString

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47997 --- Comment #11 from Mike Stump mikestump at comcast dot net 2011-03-12 16:23:45 UTC --- Ok for the patch in comment #9.

[Bug target/47997] gcc on macosx: ld: warning: -fwritable-strings not compatible with literal CF/NSString

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47997 --- Comment #7 from Mike Stump mikestump at comcast dot net 2011-03-07 18:16:13 UTC --- Ok, you can look for strlen (s) == IDENTIFIER_LENGTH (x) in either the darwin.[ch] files, or, failing one there, in the backend files... I know I've seen one

[Bug target/47822] [4.6 Regression] Multiple test suite failures due to revision 170321

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47822 --- Comment #23 from Mike Stump mikestump at comcast dot net 2011-02-22 11:53:56 UTC --- I am confused, both Iain and myself still see failures on ppc even with my patch. Iain said they were dying on BUILT_IN_SQRTL. I can't debug, as I'm using

[Bug target/47822] [4.6 Regression] Multiple test suite failures due to revision 170321

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47822 --- Comment #24 from Mike Stump mikestump at comcast dot net 2011-02-22 11:56:37 UTC --- Iain reports it is fixed for him as well... :-)

[Bug target/47822] [4.6 Regression] Multiple test suite failures due to revision 170321

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47822 --- Comment #19 from Mike Stump mikestump at comcast dot net 2011-02-21 20:58:35 UTC --- ? The patch does touch rs6000 is the same way as we touch i386. I think there is an additional issue on ppc. My previous patch is necessary

[Bug target/47822] [4.6 Regression] Multiple test suite failures due to revision 170321

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47822 --- Comment #20 from Mike Stump mikestump at comcast dot net 2011-02-21 21:02:16 UTC --- Ah, never mind, we have another thread going where the problem was pointed out. Sorry for missing it.

[Bug target/47822] [4.6 Regression] Multiple test suite failures due to revision 170321

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47822 --- Comment #11 from Mike Stump mikestump at comcast dot net 2011-02-20 19:23:07 UTC --- Could you try building with the patch on a ppc box if you have one, without the Fix to tree.c in it, so that it will fail, if the problem isn't really fixed

[Bug bootstrap/47826] r170321 breaks bootstrap-lto on x86_64-apple-darwin10

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47826 --- Comment #4 from Mike Stump mikestump at comcast dot net 2011-02-20 19:35:26 UTC --- Is this a dup of PR47822? If so, that's been fixed twice over already.

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558 --- Comment #68 from Mike Stump mikestump at comcast dot net 2011-02-07 22:20:11 UTC --- So, what you are saying is that the system routine produces an answer that isn't correct down to the last digit of precision for at least 1 input?

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558 --- Comment #70 from Mike Stump mikestump at comcast dot net 2011-02-08 03:44:09 UTC --- If you would like to change the comments to clarify the nasty details, I'll pre-approve it; though, I think it is unnecessary, as that work references

[Bug target/47269] DSYMUTIL_SPEC doesn't handle -gtoggle

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47269 --- Comment #2 from Mike Stump mikestump at comcast dot net 2011-02-06 01:10:06 UTC --- Luckily specs can do this: %{!fdump=*:%{!fsyntax-only:foo}} says to put in foo, if those two flags are not given; this is and.

[Bug target/47269] DSYMUTIL_SPEC doesn't handle -gtoggle

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47269 --- Comment #3 from Mike Stump mikestump at comcast dot net 2011-02-06 01:31:52 UTC --- If I understand what they intend, though, the documentation isn't clear on this point: %{!gtoggle: %{gdwarf-2:%{!gstabs*:%{!g0: -idsym

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558 --- Comment #37 from Mike Stump mikestump at comcast dot net 2011-02-04 00:43:50 UTC --- Let me know when the dust settles and you guys agree on the path forward and I will decloak... I've been trying to avoid reading/understanding the issue...

[Bug target/46037] --enable-stage1-languages=c,lto --enable-languages=c,lto --with-build-config=bootstrap-lto fails on darwin

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46037 --- Comment #23 from Mike Stump mikestump at comcast dot net 2011-01-12 00:46:43 UTC --- Ok.

[Bug target/33120] Data not put in BSS section on Mac OS

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33120 --- Comment #24 from Mike Stump mikestump at comcast dot net 2010-12-16 21:05:06 UTC --- Yeah, I don't think it is too important to back port. The next release is coming out soon, and I don't think its a big issue and has always been there. I'd

[Bug testsuite/46912] [4.6 Regression] Test failures for g++.dg/plugin/*plugin*.C on powerpc-apple-darwin9

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46912 --- Comment #3 from Mike Stump mikestump at comcast dot net 2010-12-16 21:59:44 UTC --- it's all fall-out from the different assumed sizes of Bool (see also 46902). ? bool/_Bool is 4 on pcc. Making it any other size introduces a abi bug

[Bug testsuite/46912] [4.6 Regression] Test failures for g++.dg/plugin/*plugin*.C on powerpc-apple-darwin9

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46912 --- Comment #5 from Mike Stump mikestump at comcast dot net 2010-12-16 22:42:34 UTC --- On Dec 16, 2010, at 2:06 PM, iains at gcc dot gnu.org wrote: gcc/system.h : # define bool unsigned char This is wrong. The solution is simple: #define

[Bug middle-end/46916] gcc.dg/torture/stackalign/non-local-goto-[1,2].c ICEs compiler due to r167727

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46916 --- Comment #11 from Mike Stump mikestump at comcast dot net 2010-12-13 22:55:12 UTC --- I don't think this should be necessary. One section should be enough. If you have specific concerns, let me know, I could just be missing something.

[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749 --- Comment #42 from Mike Stump mikestump at comcast dot net 2010-12-07 16:42:04 UTC --- Oh, one can use -Wl,-dsym in the time being with this patch.

[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749 --- Comment #35 from Mike Stump mikestump at comcast dot net 2010-12-05 21:13:30 UTC --- Surely this design isn't complete as it doesn't cover the changes or the requirements for lto. Without those, I can't review the design to see

[Bug target/43751] dsymutil is not called for fortran and, under some circumstances not for other FEs.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43751 --- Comment #10 from Mike Stump mikestump at comcast dot net 2010-12-03 20:17:03 UTC --- Jack says that some of the spurious warnings are fixed in Xcode 3.2.3. I have 3.2.4 on my system. Could you update Xcode and see if any we care about

[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749 --- Comment #29 from Mike Stump mikestump at comcast dot net 2010-12-03 23:13:02 UTC --- The darwin people have to design a more robust way to run dsymutil. Ok. How's this, you must run LINK_COMMAND_SPEC to link. When you run it, any

[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749 --- Comment #31 from Mike Stump mikestump at comcast dot net 2010-12-04 00:18:07 UTC --- On Dec 3, 2010, at 3:20 PM, rguenther at suse dot de wrote: yes, I would have expected that this happens already. Now, I (or somebody else) needs to take

[Bug target/23071] Darwin alignment ignores attribute packed for first 'double' element of a struct

--- Comment #8 from mikestump at comcast dot net 2010-03-22 23:18 --- The previous behavior was fairly broken, adding packed, _increased_ the alignment. A user that adds packing, never wants more alignment: struct Test { double D __attribute__((packed,aligned(4))); short X; } x

[Bug target/36399] ABI bug on darwin/x86-32

--- Comment #13 from mikestump at comcast dot net 2010-03-18 22:57 --- Fix checked in as r157553. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36399

[Bug target/42313] FAIL: gcc.target/i386/builtin-unreachable.c scan-assembler-not %e[bs]p on i686 darwin

--- Comment #7 from mikestump at comcast dot net 2010-03-03 16:56 --- I fixed the test case to not expect the unimplemented optimization in r157197, however, it would be nice to ensure the async signal handlers can handle unaligned stacks and to perform this optimization. I'm fairly

[Bug testsuite/40459] g++.dg/abi/mangle*.C fail on darwin

--- Comment #13 from mikestump at comcast dot net 2010-03-01 00:23 --- This is a dup of c++/42748, which has now been fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40459

[Bug objc/43061] 47 new GCC h...@156527 regressions

--- Comment #39 from mikestump at comcast dot net 2010-02-19 19:15 --- I checked in the real back end change in r156907. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43061

[Bug middle-end/43125] [4.5 Regression] Revision 156907 failed gcc.dg/attr-used.c

--- Comment #1 from mikestump at comcast dot net 2010-02-20 01:21 --- I'm building up a linux cross compiler now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43125

[Bug middle-end/43125] [4.5 Regression] Revision 156907 failed gcc.dg/attr-used.c

--- Comment #2 from mikestump at comcast dot net 2010-02-20 06:16 --- Patch submitted http://gcc.gnu.org/ml/gcc-patches/2010-02/msg00812.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43125

[Bug objc/43061] 47 new GCC h...@156527 regressions

--- Comment #36 from mikestump at comcast dot net 2010-02-18 22:06 --- I've checked in a slightly updated fix in r156877. Let us know if all the regressions are fixed now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43061

[Bug objc/43061] 47 new GCC h...@156527 regressions

--- Comment #35 from mikestump at comcast dot net 2010-02-16 16:25 --- Ok to the last patch for now. Feel free to file a bug about checking DECL_PRESERVE_P and add a pointer to remove the setting of DECL_ATTRIBUTES from the frontend, thanks. -- http://gcc.gnu.org/bugzilla

[Bug objc/43061] 47 new GCC h...@156527 regressions

--- Comment #24 from mikestump at comcast dot net 2010-02-15 17:38 --- Yes, I think IainS is on the right track, all things in objc_cls_refs escape and can be read and written to in unexpected ways by the runtime. Setting TREE_ADDRESSABLE sounds like a reasonable step forward