--- Comment #12 from amacleod at redhat dot com 2006-04-26 18:59 ---
I have a patch to change the implementation of immediate uses forthcoming
which, as a side effect, cleans up the operand scanner time in this file:
on my x86 cross powerpc64:
before patch:
tree operand scan
--- Comment #17 from amacleod at redhat dot com 2006-04-26 20:38 ---
Created an attachment (id=11336)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11336&action=view)
Possible patch
Maybe. there is a work around I have an initial patch for. It re-covers up
the problem
--- Comment #13 from amacleod at redhat dot com 2006-04-27 02:29 ---
The patch for speeding up the operand cache has been posted to gcc-patches:
http://gcc.gnu.org/ml/gcc-patches/2006-04/msg01017.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
--- Comment #14 from amacleod at redhat dot com 2006-04-27 02:30 ---
I should point out that its a patch for mainline. Conversion to 4.1 requires
some minor tweaking.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
--- Comment #5 from amacleod at redhat dot com 2006-05-02 15:38 ---
The assert condition is not flawed. It has exposed a second bug with the old
immuse iterator scheme that was also hidden by the old algorithm work around
Jeff had implemented.
When iterating over the immediate uses
--- Comment #6 from amacleod at redhat dot com 2006-05-02 15:40 ---
Created an attachment (id=11361)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11361&action=view)
proposed patch
This is the patch undergoing testing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27381
--- Comment #21 from amacleod at redhat dot com 2006-05-16 15:16 ---
Actually, no, no new news :-). I had forgotten about this one. I'll run it
again today and check it in if no problems show up.
You want it against 4.1 and mainline? or do you want to try it against
mainline
--- Comment #22 from amacleod at redhat dot com 2006-05-16 20:48 ---
Bootstraps on the 4.1 branch on i686-pc-linux-gnu and produces no new testsuite
failures. It also allows the original testcase to compile.
The mainline version is now running.
Since it seems to be blocking other
--- Comment #5 from amacleod at redhat dot com 2006-05-25 01:17 ---
That stuff was all changed at the same time. You must have a mix of pre and
post checkin code. Perhaps you updated just some files? A clean checkout works
fine for me.
2006-05-23 Andrew MacLeod <[EMAIL PROTEC
--- Comment #10 from amacleod at redhat dot com 2006-05-30 22:05 ---
Created an attachment (id=11540)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11540&action=view)
proposed patch
yeah, not terribly suprising the bug came back. The original patch I applied
fixed a long s
--- Comment #9 from amacleod at redhat dot com 2006-06-05 15:46 ---
This thread is moving dangerously close to work in progress.. :-)
I'll have something more definitive to say about it in a few weeks, but I'm
looking at doing significant register pressure reduction at out o
--- Comment #13 from amacleod at redhat dot com 2006-06-06 14:43 ---
Created an attachment (id=11609)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11609&action=view)
assert to add if Jakub's idea is implemented.
So do you want to fix it Jakub's way instead of ha
--- Comment #16 from amacleod at redhat dot com 2006-06-06 19:41 ---
yes, this appears to fix PR 27894 as well.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27793
--- Comment #40 from amacleod at redhat dot com 2009-01-26 16:16 ---
Created an attachment (id=17185)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17185&action=view)
possible patch
The problem is due to a check that was added to is_replaceable_p() in
tree-ssa-ter.c. I
--- Comment #5 from amacleod at redhat dot com 2009-07-30 18:40 ---
I just checked in the code to track locations through PHI arguments.
Comments and patch is located:
http://gcc.gnu.org/ml/gcc-patches/2009-07/msg01729.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26475
--- Comment #5 from amacleod at redhat dot com 2005-11-11 16:09 ---
Created an attachment (id=10214)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10214&action=view)
patch for the problem
In an attempt to prevent an infinite loop when verifying the immediate use
li
--- Comment #16 from amacleod at redhat dot com 2006-01-19 19:50 ---
Created an attachment (id=10678)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10678&action=view)
updated patch
I updated the patch to the current mainline, and have built and verified no
additional fail
--- Comment #7 from amacleod at redhat dot com 2006-07-27 16:35 ---
There is always the danger of losing track of exceptions.
Another option is to create an inline routine in tree-flow-inline.h which does
what you lay out, and then change set_bb_for_stmt to call it, looking something
--- Comment #40 from amacleod at redhat dot com 2006-08-19 21:58 ---
I'll take a look. On the new out-of-ssa branch I've already converted the
coalesce list from a linked list type linear algorithm to a hash table, as well
as changed the live on entry and live on exit imple
--- Comment #47 from amacleod at redhat dot com 2006-08-25 01:37 ---
Created an attachment (id=12135)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12135&action=view)
patch to resolve some of the SSA to Normal slowdowns.
By re-implementing the live on entry/exit code, I
--- Comment #48 from amacleod at redhat dot com 2006-08-25 01:42 ---
Created an attachment (id=12136)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12136&action=view)
Patch for the remaining SSA to Normal time issues
I've attached a patch to address the slowdowns i
--- Comment #49 from amacleod at redhat dot com 2006-08-25 01:56 ---
links to the 2 notes on gcc-patches:
live range changes: http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00895.html
TER changes: http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00896.html
--
http://gcc.gnu.org
--- Comment #51 from amacleod at redhat dot com 2006-08-28 17:37 ---
Huh. I didn't realize bugzilla scanned the entire checkin message looking for
bug numbers This has been checked in on a branch, so you can ignore the
preceeding note's commentary. it's just a
--- Comment #4 from amacleod at redhat dot com 2006-10-02 13:56 ---
This is not something out of ssa can resolve on its own.
given this sequence:
# s_2 = PHI ;
# d_1 = PHI ;
:;
D.1287_8 = MEM[base: d_1];
s_9 = s_2 + D.1287_8; <<<--- s_2 and s_9 have differe
--- Comment #5 from amacleod at redhat dot com 2006-10-02 14:01 ---
I guess you can flatten the goto slightly.
this is still something that is not really in the scope of out of ssa. part of
the root of this problem is that the PHI is really just a copy, but the fact
that it remains a
--- Comment #7 from amacleod at redhat dot com 2006-10-02 22:13 ---
Its not that you are expecting too much, just in the wrong place from my point
of view :-) Changing the out of ssa algorithm or implementation isnt going to
change this code. It requires changing the code out of ssa
--- Comment #24 from amacleod at redhat dot com 2006-10-04 22:33 ---
The updated version of TER that will go into 4.3 during stage 1 resolves this
problem... TER no longer tracks dependencies the way it use to. It will replace
the expression, resulting in:
main ()
{
:
__asm__
--- Comment #14 from amacleod at redhat dot com 2006-10-10 14:03 ---
TER acts only within a basic block, and that will probably not change. Its
primary function is simply to mash trees back together so the expander gets a
better look.
This is more likely to handled by the RABLET work
--- Comment #15 from amacleod at redhat dot com 2006-10-16 14:36 ---
Or we can just backport the fix from mainline to 4.1 which changes the
immediate use iterators and eliminates this kind of problem. Bug 26854 and a
couple of small follow up patches on 4/28 and 5/2. They've be
--- Comment #7 from amacleod at redhat dot com 2007-03-05 22:43 ---
Created an attachment (id=13149)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13149&action=view)
proposed patch for 4.3
This patch removes one of the temporary copies. With this minor tuning of one
--- Comment #8 from amacleod at redhat dot com 2007-03-05 22:52 ---
Created an attachment (id=13150)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13150&action=view)
proposed patch for 4.2
This is the same patch for the 4.2 compiler. Unfortunately, its not quite good
--- Comment #9 from amacleod at redhat dot com 2007-03-06 15:01 ---
actually, mainline isn't working either. A closer examination shows the code
generated has an extra offset of -4 in the compare that shouldn't be there.
This patch triggers a bug in rtl's fwprop pass
--- Comment #7 from amacleod at redhat dot com 2007-03-08 20:12 ---
Looking at the original testcase, the complaint is that _t_8232 and _t_3 are
both used in the PHI definition of _t_7. (using mainline from march 5th)
ie, _t_7(ab) = PHI <, _t_8232, ... , _t_3, ...>
--- Comment #8 from amacleod at redhat dot com 2007-03-08 20:20 ---
-fno-tree-fre makes the test case compile, which is further indication FRE is
the problem.
--
amacleod at redhat dot com changed:
What|Removed |Added
--- Comment #30 from amacleod at redhat dot com 2007-03-12 13:11 ---
Err, yeah. thats right. TER doesn't run without optimization, and I forgot this
was more than just an optimization issue. Where is that work to do basic SSA
optimizations at -O0 when you need it?? :-)
--
--- Comment #10 from amacleod at redhat dot com 2007-03-12 13:33 ---
They do all have the (ab) next to them, I was just indicating that they all
occurred in a PHI together, and hence needed to be coalesced. I should have
been more precise.
Well, _t_3 definately does have the (ab) flag
--- Comment #17 from amacleod at redhat dot com 2007-04-05 14:23 ---
Is the output from .optimized different? (once the ssa versions numbers have
been stripped). Those PHIs should be irrelevant, the question is whether the
different versioning has any effect.
The only way I can
--- Comment #19 from amacleod at redhat dot com 2007-04-05 17:24 ---
what are you using for a compiler? Im using a mainline from mid march, and with
it, my .optimized files diff exactly the same, and I get the aforementioned
time differences in the executables.
(sse.c and sse-bad.c are
--- Comment #3 from amacleod at redhat dot com 2007-04-21 22:23 ---
I think this is actually fallout from the removal of V_MUSTDEFs, which predated
mem-ssa going in. Although it may have been checked into mainline at the same
time as mem-ssa now that I think about it. The work was
--- Additional Comments From amacleod at redhat dot com 2005-03-21 15:52
---
Well, I dont think there is anything out of ssa should do here. a_1 and a_2 are
2 distinct live ranges, and should therefore be generated that way. There isnt
much choice about the 2 assignments either
--- Additional Comments From amacleod at redhat dot com 2005-04-11 15:13
---
Why would you say that? I get the same failure with a build from April 1 before
immuses was checked in.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20926
--- Comment #8 from amacleod at redhat dot com 2008-09-04 16:09 ---
out of ssa generally expects that there is no dead code.
I think the original logic was that you never want to generate code for dead
statements, so DCE would be run just before out of ssa.
It assumes any conflicts
--- Comment #10 from amacleod at redhat dot com 2008-09-04 16:51 ---
As long as it removes any dead PHIs, it would be sufficient. Other types of
dead statements don't have 'unexpected' side effects across basic block
boundaries, and should be handled fine. Other than b
--- Comment #13 from amacleod at redhat dot com 2008-09-17 14:34 ---
I was in the middle of updating this PR and taking possesion :-)
Upon further reflection, I don't think it is acceptable for out-of-ssa to
generate incorrect code simply because an optimization wasn't run
--- Comment #15 from amacleod at redhat dot com 2008-09-17 14:39 ---
Created an attachment (id=16343)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16343&action=view)
potential patch 1
This is the first option which simply doesn't add the result of a PHI with no
--- Comment #16 from amacleod at redhat dot com 2008-09-17 14:48 ---
Created an attachment (id=16345)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16345&action=view)
Potential patch #2
This is the other option, eliminate dead PHIs. compiling all of GCC .c files
at -O3, i
--- Comment #17 from amacleod at redhat dot com 2008-09-17 21:55 ---
Created an attachment (id=16348)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16348&action=view)
Patch submitted
Doh. The last patch for the dead code removal had a disabling check in it that
I was us
--- Comment #2 from amacleod at redhat dot com 2008-09-18 20:00 ---
I will also look into it and take out some of the excess checking which is
probably not necessary anymore.
--
amacleod at redhat dot com changed:
What|Removed |Added
--- Comment #19 from amacleod at redhat dot com 2008-09-18 20:04 ---
The patch should be fine for 4.3, but I'll give it a few days in mainline and
see if anything shows up on any overnight or weekly runs
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37102
--- Comment #5 from amacleod at redhat dot com 2008-09-18 20:19 ---
huh, didn't I already see a patch go by to move this check to after all the
BB's were processed instead of doing it after each BB??
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37567
--- Comment #6 from amacleod at redhat dot com 2008-09-18 20:23 ---
here it is
http://gcc.gnu.org/ml/gcc-patches/2008-09/msg01072.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37567
--- Comment #9 from amacleod at redhat dot com 2008-09-19 13:27 ---
Created an attachment (id=16362)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16362&action=view)
patch to fix the bug
Looking a little closer, Im going to change Honza's patch a little. Since the
c
--- Comment #14 from amacleod at redhat dot com 2008-10-27 16:21 ---
TER's job is to create larger expressions for the expander so that we get
better instruction selection during the initial expansion from trees/tuples to
RTL.
It does this by simply expanding the definition of a
--- Comment #12 from amacleod at redhat dot com 2008-01-17 21:54 ---
Bah. I missed getting the PR in the checkin message.
Committed the proposed patch and the testcase as revision 131610. Bootstrapped
and regression tested on x86_64-linux-gnu
Follow on conversations about const
--- Comment #41 from amacleod at redhat dot com 2008-02-01 17:46 ---
TER will not replace any load into an expression if there is more than one use
of the load. Your sample shows multiple uses of each load. If it did this
substitution, it could be introducing worse code, it doesn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96397
--- Comment #2 from Andrew Macleod ---
if I read this right, the basic premise is:
x = p1 - 4, so if x + 8 doesn't overflow, then p1 - 4 couldn't have
underflowed, and therefore x must be > p1
which is a little more complicated than just back p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96542
--- Comment #5 from Andrew Macleod ---
I think this all goes away when multi-range is enabled.
The original testcase produces:
=== BB 2
x_4(D) unsigned int VARYING
:
tmp_5 = x_4(D) != 0;
_1 = (int) tmp_5;
_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96542
--- Comment #6 from Andrew Macleod ---
Likewise, for
unsigned
baz (unsigned int x)
{
if (x >= 4) return 32;
return (-1U >> x) * 16;
}
=== BB 2
x_3(D) unsigned int VARYING
_4 UNDEFINED
:
if (x_3(D) > 3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23577
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92506
--- Comment #2 from Andrew Macleod ---
Created attachment 47265
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47265&action=edit
patch to resolve the issue
Traced it back to a typo in operator_abs::fold_range() when I did the
conversion wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92506
--- Comment #3 from Andrew Macleod ---
Author: amacleod
Date: Thu Nov 14 19:02:48 2019
New Revision: 278259
URL: https://gcc.gnu.org/viewcvs?rev=278259&root=gcc&view=rev
Log:
2019-11-14 Andrew MacLeod
PR tree-optimization/92506
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54005
--- Comment #2 from Andrew Macleod 2012-08-08
15:04:21 UTC ---
I don't think that is right.
A type may not be always lock free from the compiler's perspective, so
__atomic_always_lock_free() will return false.
The compiler will issue a call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54005
--- Comment #4 from Andrew Macleod 2012-08-14
03:20:09 UTC ---
A GCC port is incorrect if it is issuing any kind of lock. GCC is only allowed
to issue a lock free sequence of some sort. If a lock is required, then a call
to libatomic must be m
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54005
--- Comment #5 from Andrew Macleod 2012-08-14
03:27:28 UTC ---
huh, somehow this got submitted before I finished. :-P
For libstdc++, the macros SHOULD use __atomic_always_lock_free() since they are
intended to be used in #ifdef's and such and we
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54005
--- Comment #7 from Andrew Macleod 2012-08-14
13:45:50 UTC ---
If NULL is passed as the second parameter, *both* functions are per type. They
only become per-object based when an object is actually passed as the second
parameter. libstdc++ cou
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54005
--- Comment #9 from Andrew Macleod 2012-08-14
22:44:53 UTC ---
Actually, that's the way __atomic_is_lock_free() has always been implemented
(even in 4.7).
The change is simply wrong and needs to be reverted. __atomic_is_lock_free()
*must* ca
||
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-08-23
AssignedTo|unassigned at gcc dot |amacleod at redhat dot com
|gnu.org |
Ever Confirmed|0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54087
--- Comment #9 from Andrew Macleod 2012-10-01
15:50:26 UTC ---
Author: amacleod
Date: Mon Oct 1 15:50:09 2012
New Revision: 191929
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191929
Log:
2012-10-01 Andrew MacLeod
||2012-10-09
AssignedTo|unassigned at gcc dot |amacleod at redhat dot com
|gnu.org |
Ever Confirmed|0 |1
--- Comment #1 from Andrew Macleod 2012-10-09
18:34:08 UTC ---
Created attachment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54861
--- Comment #2 from Andrew Macleod 2012-10-09
18:40:16 UTC ---
Author: amacleod
Date: Tue Oct 9 18:40:02 2012
New Revision: 192268
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192268
Log:
2012-10-09 Andrew MacLeod
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54861
--- Comment #4 from Andrew Macleod 2012-10-10
20:47:48 UTC ---
Author: amacleod
Date: Wed Oct 10 20:47:39 2012
New Revision: 192332
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192332
Log:
2012-10-10 Andrew MacLeod
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46567
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57926
--- Comment #4 from Andrew Macleod ---
Short answer.. I'm not a sure, but it appears to be a g++ thing.
I looks like g++ is using ARRAY_TYPE instead of POINTER_TYPE. the 4.8 branch
does the same thing, but it does seem odd to me. That means any
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57926
Andrew Macleod changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |amacleod at redhat dot
com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57926
--- Comment #7 from Andrew Macleod ---
btw, that patch passes bootstrap and a new testcase based on a modified version
of the bug report test.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57926
Andrew Macleod changed:
What|Removed |Added
CC||rth at gcc dot gnu.org
--- Comment #9 fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50583
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51011
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51011
--- Comment #4 from Andrew Macleod 2011-11-08
03:18:36 UTC ---
Yeah, it looks like I'll have to change the built-in mechanism slightly. I
followed the __sync methodology, but they dont resolve to function calls unless
they are in libgcc I think.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51026
--- Comment #2 from Andrew Macleod 2011-11-08
13:32:51 UTC ---
Its fixed by the revert in that changelog to atomic_base.h. The problem is
there is a missing dependency in the makefiles, which is how it got through in
the first place.. and increm
||2011-11-09
AssignedTo|unassigned at gcc dot |amacleod at redhat dot com
|gnu.org |
Ever Confirmed|0 |1
--- Comment #1 from Andrew Macleod 2011-11-09
19:09:58 UTC ---
Created attachment 25773
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51038
Andrew Macleod changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51040
--- Comment #2 from Andrew Macleod 2011-11-10
16:39:36 UTC ---
Author: amacleod
Date: Thu Nov 10 16:39:32 2011
New Revision: 181259
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181259
Log:
PR rtl-optimization/51040
* optabs.c (e
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51038
--- Comment #2 from Andrew Macleod 2011-11-10
20:38:46 UTC ---
Author: amacleod
Date: Thu Nov 10 20:38:33 2011
New Revision: 181271
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181271
Log:
PR middle-end/51038
libstdc++-v3
*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52190
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52190
--- Comment #3 from Andrew Macleod 2012-02-10
18:37:22 UTC ---
Author: amacleod
Date: Fri Feb 10 18:37:18 2012
New Revision: 184112
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184112
Log:
2012-02-10 Andrew MacLeod
PR c/52190
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52201
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52215
--- Comment #7 from Andrew Macleod 2012-02-13
15:27:04 UTC ---
I think that is better.. its is just the I{1,2,4,8,16} we care about.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52190
--- Comment #5 from Andrew Macleod 2012-02-13
15:37:38 UTC ---
Author: amacleod
Date: Mon Feb 13 15:37:33 2012
New Revision: 184156
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184156
Log:
2012-02-13 Andrew MacLeod
PR c/52190
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52201
--- Comment #4 from Andrew Macleod 2012-02-24
19:47:18 UTC ---
Created attachment 26746
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26746
disable tests if no atomic support present
That test case really shouldn't be running. To make su
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52382
Andrew Macleod changed:
What|Removed |Added
CC||bkoz at gcc dot gnu.org
--- Comment #4 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52558
--- Comment #3 from Andrew Macleod 2012-03-12
15:24:35 UTC ---
Created attachment 26881
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26881
Testcase for simulate-threads
I've modified the testcase so that it runs in gcc.dg/simulate-thread
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52558
--- Comment #8 from Andrew Macleod 2012-03-12
15:50:13 UTC ---
We can still perform store motion out of a loop, we just can't put the store on
a path which is executed if the loop isn't executed.
In this case, we actually made the code *slower*.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51258
--- Comment #20 from Andrew Macleod 2012-03-22
12:10:45 UTC ---
Is this not resolved in 4.7? I thought we had changed the timeouts back to
normal and added other mechanisms to avoid large infinite loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52929
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58938
--- Comment #7 from Andrew Macleod ---
(In reply to Jonathan Wakely from comment #6)
> (In reply to Rafał Rawicki from comment #3)
> > This is a regression, because a more specific _GLIBCXX_ATOMIC_BUILTINS_4 was
> > defined (but is no longer avail
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: amacleod at redhat dot com
on x86_64-unknown-linux-gnu bootstrap fails during configuration of libcilkrts.
When testing for a functioning c++ compiler, the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58697
--- Comment #8 from Andrew Macleod ---
Really? Trunk fails for me this morning. Works fine at -O2, but I get a
segfault at -O3 on x86_64-unknown-linux-gnu
Andrew
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59260
--- Comment #3 from Andrew Macleod ---
Author: amacleod
Date: Mon Nov 25 13:23:09 2013
New Revision: 205352
URL: http://gcc.gnu.org/viewcvs?rev=205352&root=gcc&view=rev
Log:
PR bootstrap/59260
* fold-const.c: Include hash-table.h.
Modif
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51102
--- Comment #1 from Andrew Macleod 2011-11-16
15:43:23 UTC ---
Author: amacleod
Date: Wed Nov 16 15:43:15 2011
New Revision: 181414
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181414
Log:
2011-11-16 Andrew MacLeod
PR libstdc++
1 - 100 of 877 matches
Mail list logo
