[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 those systems has been done.
[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 2012-08-20 16:24:49 UTC --- Looks good to me... HJ?
[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 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. What code assumes _Bool is 1 byte? That would be the root cause that needs fixing. > I think (subject to Mike's agreement) that, since Darwin's does > not > set bool to int for GCC > 3 You're misreading it: $ cat t.c int sz = sizeof(_Bool); $ gcc -arch ppc t.c -S -o - .machine ppc7400 _sz: .long4 > .. that we should default to one byte bools on PPC darwin (there is no effect > on x86). No, that would be bad.
[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 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 bool _Bool on darwin. Arguably, this is correct for every non-broken system as well.
[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 2011-01-12 00:46:43 UTC --- Ok.
[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 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/47269] DSYMUTIL_SPEC doesn't handle -gtoggle
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47269
--- Comment #2 from Mike Stump 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 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}}}\
%{.c|.cc|.C|.cpp|.cp|.c++|.cxx|.CPP|.m|.mm: \
%{gdwarf-2:%{!gstabs*:%{!g0: -dsym
}
%(gtoggle:
%{!gdwarf-2:%{!gstabs*:%{!g0: -idsym}}}\
%{.c|.cc|.C|.cpp|.cp|.c++|.cxx|.CPP|.m|.mm: \
%{!gdwarf-2:%{!gstabs*:%{!g0: -dsym
}
that said, I'd have the explain in detail exactly what happens with -g0 and
-gstabs. You'd have to check to {} nesting to make sure I the } at the very
end is right.
[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 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 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 this bug report, and this bug report details it in enough detail...
[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 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. If you don't, then a second set of hands testing would be nice, if we want to put this into the tree before stage1. Richard, should the darwin fix go in now, or wait til stage1?
[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 2011-02-20 19:35:26 UTC --- Is this a dup of PR47822? If so, that's been fixed twice over already.
[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 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, but not sufficient. So, if someone has a rs6000, I'll fix it, if you point out the line that dies or the data structure that it was playing with.
[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 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 #23 from Mike Stump 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 rosetta, and apparently debugging no longer works. :-( Odd. [ long pause ] Truly, odd, I just updated and removed that hunk from comment #6, and presto, the testcase that failed for me earlier, now works. I did do a restrap this time to try and avoid more uncleanliness.
[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 2011-02-22 11:56:37 UTC --- Iain reports it is fixed for him as well... :-)
[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 --- 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/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 --- These should go in config/*darwin* I think.
[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 --- On Sep 6, 2013, at 8:43 AM, howarth at nitro dot med.uc.edu wrote: >* i386.c (ix86_hard_regno_mode_ok): AVX modes are valid only when > >AVX is enabled. llvm has: // The first 8 512-bit vector arguments are passed in ZMM registers. CCIfNotVarArg>>>, just after the sse registers… conceptually, I wonder if gcc is missing that.
[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 --- Don't know… I'd assume there exists a paper somewhere that says it. :-)
[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 2011-10-26 21:12:58 UTC --- Do we know what patch broke this?
[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 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 was expecting to see code motion to change lifetime.
[Bug testsuite/53028] add dg-pedantic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53028
--- Comment #11 from Mike Stump 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/gcc-patches/2012-04/msg01778.html
Two comments. First, this, at most can test just one case, I mean, we don't
test all cases. Second, I don't see -Werror anywhere. I don't see -w
anywhere. Maybe I missed how these test these two options...
> Perhaps we can devise an indirect
> way to test that a warning is enabled by a certain option. We could have
> { dg-warning-with-option "Wlong-long" "ISO C90 does not support 'long long'"
> },
> which will match the option shown with -fdiagnostics-show-option. Can we at
> least have this?
I like the idea that we have a way to write one test case instead of three...
I certainly won't object.
> Fair enough. But the duplicated testcases are still being added!
I'd rather error on the side of letting the FE people do what they want.
[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 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 such... I think that is a good way forward. If they would fix it in a .x minor OS release, I'm fine with simply requiring the user update their system as well, though, I wouldn't holds ones breath for the update.
[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 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 was as gcc is normally
wired. I suspect it should be fairly close. I'm thinking this should be easy
to wire up.
[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 2012-02-16 17:16:39 UTC --- Thanks.
[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 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 they have NO_PTHREAD_GET_STACKADDR_NP, so, I can't guess why they have it, though, I would be interested in their experience with it. Anyway, propose a patch for gcconfig.h and I would likely approve it.
[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 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 HAVE_PTHREAD_GET_STACKADDR_NP #define STACKBOTTOM (ptr_t)pthread_get_stackaddr_np(pthread_self()) #endif This should cover all the issues with NO_PTHREAD...
[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 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 DARWIN block there. In the code in the file I mentioned, as a replacement to the #define that exists today.
[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 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 2012-02-23 21:53:04 UTC --- Ok.
[Bug testsuite/53028] add dg-pedantic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53028 --- Comment #2 from Mike Stump 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 testing, with one set of options.
[Bug testsuite/53028] add dg-pedantic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53028 --- Comment #4 from Mike Stump 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 but one of them that either test for the warning or error, it is a cost benefit valuation. As for what is possible in DjeaGnu, it is turing complete, so, one can put in anything for which a turing machine can compute the answer, however, the bar is higher than that. The question is, is it a good idea. To answer this, my experience tells me, no, not really. Now, other people's experiences differ, and I could be swayed by their experience. For example, please provide 10 PRs in which we had regressions that could have been caught, but weren't, because we didn't have such testing. If none, then, what exactly is the benefit you see? For the torture options, history is littered with oodles of such bugs, in fact, the shear numbers caused people to do the entire torture framework. It was put in, to try and permanently stem the tide of such bugs, so they never happen again, or, at least to reduce in a major way, the shear numbers and to enhance the reliability of the compiler, and hence, it's reputation. Experience tells me, 20-20 hind sight, that the motivation was good and the results are worth it and that it was the right decision. It also tells me that removing the torture options would be a mistake and we would sink back into where we were before if we wanted to try and remove them. Now, a counter point. -pedantic-errors often will not work well because of things in system header files. It might be reasonable to #include all the system headers in a torture setup to ensure that C, C++, pedantic, pedantic errors, c89, c99 and so on, all work. The benefit, as failures are found, we can fixinclude or engineer some sort of solution, so that the user has a nice experience with the compiler. I think spending time on this, it a better cost/benefit choice. So, to recap, ripping out all but one solve the duplication problem you point out, it solves the duplication of creation effort you point out, it solves the duplication of maintaining the testsuite you point out. It also has the added benefit of not wasting valuable testing time testing things that never fail. The above I think is generally true, but I concede there are specific instances where it is not. I'll help you understand what I wrote, but I don't know what part you don't understand. That dejagnu is a regression suite? What the word regression means? That one test is sufficient to test a pedantic message?
[Bug testsuite/53028] add dg-pedantic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53028 --- Comment #6 from Mike Stump 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, please include a testcase, meaning, one testcase. One is certainly reasonable. For some work, for some cases, they might want 2 or 3 testcases, but, those I suspect should be rare to very rare. The requirements for 3 for that change should not be read as to be generally require 3 for all future changes... or, at least, that'd be my interpretation.
[Bug testsuite/53028] add dg-pedantic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53028
--- Comment #9 from Mike Stump 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 are free to require it, what they say goes. I like the idea of
testing new code, just I think it could be over done.
I'll give you an example, I think we all can agree on.
Let's say we add a warning. The code goes in, and a single testcase:
main() {
i = code to produce warning; // warning
}
but, we don't also test:
-pedantic-errors
main() {
i = code to produce warning; // warning
}
even though, it is reasonable. We could, but don't. Why don't we, because it
isn't worth the testing time and the maintenance time. Testing it once, and
assuming that no one will accidentally change the warning is reasonable. We
also don't test that the warning goes away with -w. We don't test the warning
turns into an error with -Werror.
How many times has one of these tests caught someone modifying a pedantic into
a warning? How many times has one of these tests caught someone modifying a
pedantic into an error? How many times did someone modify a pedantic in one of
the two ways because a testcase wasn't present?
Feel free to use your best recollection for the above answers. I can't help
but think the numbers are so low, as to not be worth the cost of the additional
testcases.
[Bug bootstrap/48474] gcc fails to bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48474 --- Comment #4 from Mike Stump --- patches to the gcc-patches list get lost and ignored. Bugzilla is forever. Looks like I chose wisely.
[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 --- Let's see if Iain needs it for anything…
[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 --- Thanks for the fix and the update guys.
[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/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 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 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 nasty.
[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 #2 from Mike Stump --- Look forward to incorporating the changes made by the script.
[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 suspect. I think we should exclude any number greater than some small int, say, 9. So, .-9 .. .+9 in the new form only. If outside that range, I think I'd rather punt. The idea is that the absolute number at least has a line number that in an editor you can go directly to, and it corresponds with the number in the error messages directly, aiding understanding which one is referred to without having to ungoop the relative number first. Let's see if anyone else has any comments. If not, I'd pre-approve the change with the range reduced.
[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 --- 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 --- Nope.
[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 --- 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 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. -- mikestump at comcast dot net changed: What|Removed |Added CC||mikestump at comcast dot net 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/show_bug.cgi?id=43061
[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 #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 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 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 certain the
signal handers have to cope as code gen can do:
_h:
subl$12, %esp
movl$1, %eax
addl$12, %esp
ret
for int h () { return 1; } and certainly we can take a signal at _h+0, where
esp isn't aligned. Given that, we can omit sp alignments for leaf functions
(and no tail calls either), even on machines where otherwise an alignment is
required, as long as any variables on the stack are correctly aligned.
When this optimization is added, we can undo the r157197 change.
--
mikestump at comcast dot net changed:
What|Removed |Added
CC| |mikestump at comcast dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42313
[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/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;
struct {
char x;
struct Test t;
} b = { 1, { 2, 3}};
compared to:
struct Test {
double D /* __attribute__((packed,aligned(4))) */;
short X;
} x;
struct {
char x;
struct Test t;
} b = { 1, { 2, 3}};
--
mikestump at comcast dot net changed:
What|Removed |Added
CC||mikestump at comcast dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23071
[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 --- 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) CONSTANT_P is true for more than just all kinds of constant number. This patch undoes that part of the wide-int patches. but the ChangeLog was like this: PR target/61396 * config/rs6000/rs6000.c (paired_expand_vector_init): Only allow constant numbers, not general constants. (rs6000_expand_vector_init): Ditto. You used to do this, but stopped. The problem with how you are doing it is that the svn bugzilla integration actually looks for the PR target/ line and links the change in svn into bugzilla. Without that, no link. Thanks.
[Bug testsuite/20567] dg-options in gcc.c-torture
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20567 Mike Stump changed: What|Removed |Added CC||mikestump at comcast dot net --- Comment #7 from Mike Stump --- gcc.c-torture/execute ignores dg-options settings has been fixed to honor it. They now use the dg framework driver. All the .x files are now gone. The annotations have been updated. No testcase specifies -O2 anymore. One does -O, but that I think is for correctness. As for compile/981006-1.c, run was never needed to show the bug, so, assemble alone is sufficient. I don't know what might pop up from not using -w, I suspect that was just inherited by default. If you want to remove it (and manage any fall out, I'd be fine with that. I don't think it matters much. The testcase isn't testing other warnings, just the one.
[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 changed: What|Removed |Added CC||mikestump at comcast dot net --- Comment #7 from Mike Stump --- Ok.
[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 --- 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, and the feature testing should be to identify incomplete or broken things. Given the propensity for people to write a test, is this 2.x or later, that is a direct indication they wrote it wrong in the first place. Tests should always be 2.x or earlier to identify broken.
[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 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 before, just can't recall where exactly. In theory, the two should be virtually identical, or one of them is wrong.
[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 2011-03-12 16:23:45 UTC --- Ok for the patch in comment #9.
[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 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, and by that time, we'd need one.
[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 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 to get Apple to do that. This might then require an FSF binutils.
[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 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 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 2011-03-14 23:39:21 UTC --- Seems reasonable to me...
[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 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 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 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 include $prefix/lib? I fear this is going to be a hard bug... If one wants any compatibility, the routines in gcc_s from /usr/lib have to be used, in particular, the unwinder. But, that is exactly the thing that appears to be causing the problems. I think we're going to need a test case, or if you could, could you try and binary search the gcc trunk for the patch that caused this to break for you? Also, you have this in bootstrap, does that mean that this doesn't bootstrap? If you could include the error messages from the bootstrap, or the name of the gcc test case in the testsuite that is failing, that would help. Thanks.
[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 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 the problems in other bug reports completely or partially. I prefer that as enough work is put in to fix one bug report, that that bug report is then marked as fixed, and other the other bug reports that are completely solved by it are then marked as dup of that bug.
[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 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. llvm-gcc is old and getting older every day. The dragon egg bits are newer and more compelling.
[Bug bootstrap/48474] gcc fails to bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48474 --- Comment #2 from Mike Stump 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 a pattern for eh_return, then things don't compile.
[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 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 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
equally well.
Ok?
Index: gcc.dg/tree-ssa/ssa-ccp-17.c
===
--- gcc.dg/tree-ssa/ssa-ccp-17.c(revision 1272)
+++ gcc.dg/tree-ssa/ssa-ccp-17.c(working copy)
@@ -18,7 +18,7 @@
return ((struct Foo *)p)->i;
}
-const struct Foo g;
+extern const struct Foo g;
int foobar(void)
{
[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 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 remain. If so, please file a Apple bug report. If fixed, we can simply require the newer Xcode. If it won't work on darwin9, and we care, we could have the .f addition in darwin10.h alone. I don't favor the stripping, but I'g go along with a darwin9 stripper and a darwin10 and later no strip version.
[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 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 temporary real .o files created by the compilation process cannot be removed until after it finishes running, including any sub-invocations of the compiler that contribute content.
[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 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 the time and investigate why this
> doesn't happen.
Ah, I can explain it, collect2 does `stuff', and what it does is to remove the
lto temporary files, early. The below are the files that are too early, and
will `fix' the issue.
Index: collect2.c
===
--- collect2.c(revision 167409)
+++ collect2.c(working copy)
@@ -1056,7 +1056,9 @@
fork_execute ("ld", out_lto_ld_argv);
free (lto_ld_argv);
+#if 0
maybe_unlink_list (lto_o_files);
+#endif
}
else if (force)
{
If collect2 was folded into gcc.c and all the lto stuff was flat, inside gcc.c
and then we let record_temp_file register _all_ the temporary files, and the
let gcc.c delete the temporary files at the end, all work work just fine.
[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 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 if it is sufficient to actually fix the problem at hand. The problem is there are temporary files removed by subpasses during the subpass. The above doesn't lengthen the lifetime of those temporary files, so can't fix the problem. Compare and contrast another potential design: Add an environment variable that identifies a file in which additions can be made of temporary object files to remove once the link is done. If any subpart of the compilation process wants to create to create intermediate .o files, they can instead write into that named file, the names of the temporary files to delete, then the top level driver (one with no environment variable set, can delete them, at the very end. This even works for linker plugin files and cover just about every type of tech or architecture for the compilation process save distribution, caching and compilation server. I'd propose we handle those later, as necessary. The advantages of this over the last one is, it is complete, it would always work, regardless of nesting complexities, doesn't require any changes to `ld', and works, even when collect2 isn't used.
[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 2010-12-07 16:42:04 UTC --- Oh, one can use -Wl,-dsym in the time being with this patch.
[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 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 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 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 propose to not back port.
[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 2011-06-13 03:32:11 UTC --- Ok. (When the engineering work is done.)
[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 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 hung up on darwin -c stuff, ignore that, that's not the bug, even if bugs do exist in that area.
[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 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 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 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 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 about what to do for Ada. :-( I'll pre-approve the solution you two decide on.
[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 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 - likely to be a bundle of laughs (unless you know of a > downloadable ada binary for Darwin 9 or 10 at least). Jack or the Ada folks might have a pointer. google turns up http://aadl.enst.fr/ocarina/releases/, if you have ppc or rosetta.
