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 t
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?
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 by
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. Ar
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46037
--- Comment #23 from Mike Stump 2011-01-12
00:46:43 UTC ---
Ok.
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...
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.
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}}}\
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?
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 repor
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 seco
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.
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
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.
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 debug
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... :-)
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.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57753
--- Comment #3 from Mike Stump ---
These should go in config/*darwin* I think.
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-
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. :-)
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?
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 mot
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/m
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
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.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52220
--- Comment #4 from Mike Stump 2012-02-16
17:16:39 UTC ---
Thanks.
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_STACK
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
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
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.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52179
--- Comment #25 from Mike Stump 2012-02-23
21:53:04 UTC ---
Ok.
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 opti
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 t
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, meanin
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
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.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47016
--- Comment #5 from Mike Stump ---
Let's see if Iain needs it for anything…
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41090
--- Comment #24 from Mike Stump ---
Thanks for the fix and the update guys.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52795
--- Comment #15 from Mike Stump ---
Can the bug be marked as resolved? :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81037
--- Comment #5 from Mike Stump ---
Fixed in 6.4. Leaving open for 5 backports.
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.
:-(
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80221
Mike Stump changed:
What|Removed |Added
CC||mikestump at comcast dot net
--- Comment
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 sus
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61146
--- Comment #19 from Mike Stump ---
Nope.
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?
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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 f
--- 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
--- 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
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 j
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20567
Mike Stump changed:
What|Removed |Added
CC||mikestump at comcast dot net
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63188
Mike Stump changed:
What|Removed |Added
CC||mikestump at comcast dot net
--- Comment
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 iden
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 wh
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.
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.
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
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.
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.
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...
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.
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
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 c
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
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
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.
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
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 Appl
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
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 wh
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 pr
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.
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.
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.
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.)
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, ig
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
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.
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. :
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
88 matches
Mail list logo
