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

[mikestump at comcast dot net]

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/52795] FAIL: gcc.dg/tree-prof/pr34999.c compilation, -fprofile-use -D_PROFILE_USE on {x86_64,i386}-apple-darwin{10,11} at -m64

[mikestump at comcast dot net]

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

[mikestump at comcast dot net]

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

[mikestump at comcast dot net]

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

[mikestump at comcast dot net]

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 testsuite/80221] Contrib script to rewrite testcase from absolute to relative line numbers

[mikestump at comcast dot net]

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 target/57438] bootstrap fails on x86_64 darwin in stage2 linking cc1

[mikestump at comcast dot net]

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 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

[mikestump at comcast dot net]

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, 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 testsuite/20567] dg-options in gcc.c-torture

[mikestump at comcast dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20567

Mike Stump mikestump at comcast dot net changed:

   What|Removed |Added

 CC||mikestump at comcast dot net

--- Comment #7 from Mike Stump mikestump at comcast dot net ---
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

[mikestump at comcast dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63188

Mike Stump mikestump at comcast dot net changed:

   What|Removed |Added

 CC||mikestump at comcast dot net

--- Comment #7 from Mike Stump mikestump at comcast dot net ---
Ok.

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

[mikestump at comcast dot net]

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)

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 target/60732] FAIL: g++.dg/ext/altivec-7.C -std=* scan-assembler _Z3fooDv*

[mikestump at comcast dot net]

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

[mikestump at comcast dot net]

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

[mikestump at comcast dot net]

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

[mikestump at comcast dot net]

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

[mikestump at comcast dot net]

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

[mikestump at comcast dot net]

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

[mikestump at comcast dot net]

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  
  
AVX is enabled.

llvm has:

  // The first 8 512-bit vector arguments are passed in ZMM registers.
  CCIfNotVarArgCCIfType[v16i32, v8i64, v16f32, v8f64],
CCIfSubtargethasAVX512(),
CCAssignToReg[ZMM0, ZMM1, ZMM2, ZMM3, ZMM4, ZMM5, ZMM6, ZMM7],

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

[mikestump at comcast dot net]

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

[mikestump at comcast dot net]

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

[mikestump at comcast dot net]

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

[mikestump at comcast dot net]

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

[mikestump at comcast dot net]

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/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 testsuite/53028] add dg-pedantic

[mikestump at comcast dot net]

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 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 testsuite/53028] add dg-pedantic

[mikestump at comcast dot net]

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
testing, with one set of options.

[Bug testsuite/53028] add dg-pedantic

[mikestump at comcast dot net]

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
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

[mikestump at comcast dot net]

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, 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 boehm-gc/52179] boehm-gc incompatible with aslr on darwin11

[mikestump at comcast dot net]

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
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

[mikestump at comcast dot net]

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

[mikestump at comcast dot net]

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

[mikestump at comcast dot net]

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 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

[mikestump at comcast dot net]

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 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 target/52268] tls support should be added for darwin11

[mikestump at comcast dot net]

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 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

[mikestump at comcast dot net]

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

[mikestump at comcast dot net]

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 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/45233] FAIL: gcc.c-torture/compile/pr44707.c

[mikestump at comcast dot net]

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 was expecting to see code motion to change lifetime.

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

[mikestump at comcast dot net]

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

[mikestump at comcast dot net]

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
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

[mikestump at comcast dot net]

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 - 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.

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

[mikestump at comcast dot net]

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 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

[mikestump at comcast dot net]

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

[mikestump at comcast dot net]

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*

[mikestump at comcast dot net]

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

[mikestump at comcast dot net]

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

[mikestump at comcast dot net]

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
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 bootstrap/48474] gcc fails to bootstrap

[mikestump at comcast dot net]

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 a pattern
for eh_return, then things don't compile.

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

[mikestump at comcast dot net]

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. 
llvm-gcc is old and getting older every day.  The dragon egg bits are newer and
more compelling.

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

[mikestump at comcast dot net]

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 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 bootstrap/44107] libstdc++ (dylib) is built with an erroneous dependency towards /usr/lib

[mikestump at comcast dot net]

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 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 objc/39753] [4.3/4.4/4.5/4.6/4.7 Regression] Objective-C(++) and C90 strict-aliasing interaction bug

[mikestump at comcast dot net]

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

[mikestump at comcast dot net]

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

[mikestump at comcast dot net]

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

[mikestump at comcast dot net]

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

[mikestump at comcast dot net]

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, and by
that time, we'd need one.

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

[mikestump at comcast dot net]

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 to
get Apple to do that.  This might then require an FSF binutils.

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

[mikestump at comcast dot net]

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

[mikestump at comcast dot net]

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 before, just can't recall where exactly.  In theory, the two should be
virtually identical, or one of them is wrong.

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

[mikestump at comcast dot net]

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 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

[mikestump at comcast dot net]

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

[mikestump at comcast dot net]

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, 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

[mikestump at comcast dot net]

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

[mikestump at comcast dot net]

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.
 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

[mikestump at comcast dot net]

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

[mikestump at comcast dot net]

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

[mikestump at comcast dot net]

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 this
bug report, and this bug report details it in enough detail...

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

[mikestump at comcast dot net]

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

[mikestump at comcast dot net]

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}}}\   
  %{.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

[mikestump at comcast dot net]

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

[mikestump at comcast dot net]

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

[mikestump at comcast dot net]

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 propose to not back port.

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

[mikestump at comcast dot net]

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. 
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 stdbool.h 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

[mikestump at comcast dot net]

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 bool _Bool

on darwin.  Arguably, this is correct for every non-broken system as well.

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

[mikestump at comcast dot net]

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

[mikestump at comcast dot net]

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

[mikestump at comcast dot net]

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 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 target/43751] dsymutil is not called for fortran and, under some circumstances not for other FEs.

[mikestump at comcast dot net]

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
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

[mikestump at comcast dot net]

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
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

[mikestump at comcast dot net]

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 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 target/23071] Darwin alignment ignores attribute packed for first 'double' element of a struct

[mikestump at comcast dot net]

--- 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/36399] ABI bug on darwin/x86-32

[mikestump at comcast dot net]

--- 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

[mikestump at comcast dot net]

--- 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 testsuite/40459] g++.dg/abi/mangle*.C fail on darwin

[mikestump at comcast dot net]

--- 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

[mikestump at comcast dot net]

--- 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

[mikestump at comcast dot net]

--- 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

[mikestump at comcast dot net]

--- 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

[mikestump at comcast dot net]

--- 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

[mikestump at comcast dot net]

--- 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

[mikestump at comcast dot net]

--- 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