--- Comment #5 from steven at gcc dot gnu dot org 2010-07-18 17:21 ---
It looks like a store is scheduled wrong.
Slightly reduced test case:
-- 8< #define vector
__attribute__((vector_size(16) ))
vector int f1(vector int t, int a)
{
((int*
--- Comment #4 from steven at gcc dot gnu dot org 2010-07-17 23:27 ---
Confirmed with r162278. Scheduling after reload (which is bundling for the ia64
backend) seems to cause this:
$ ./xgcc -B. -O2 vector-2.c -fno-inline -fPIC ; echo Testing ; ./a.out
Testing
Aborted
$ ./xgcc -B. -O2
--- Comment #6 from steven at gcc dot gnu dot org 2010-07-17 22:57 ---
Not mine anymore.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
--- Comment #1 from steven at gcc dot gnu dot org 2010-07-17 22:56 ---
Jakub, please do not forget about this one for stage1 GCC 4.6.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #54 from steven at gcc dot gnu dot org 2010-07-17 22:55 ---
FIXED in r162047.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from steven at gcc dot gnu dot org 2010-07-17 22:34 ---
Ideally, the code would look at the CFG instead, like the loop above it, that
uses FOR_EACH_BB_REVERSE. But most of the postreload.c code ignores the CFG,
unfortunately...
--
http://gcc.gnu.org/bugzilla
--- Comment #10 from steven at gcc dot gnu dot org 2010-07-15 23:09 ---
Pinski, got test case?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from steven at gcc dot gnu dot org 2010-07-15 23:08 ---
If the quoted comment in this bug's comment #0 is true, then this bug should be
fixable with MEM_REF.
--
steven at gcc dot gnu dot org changed:
What|Removed |
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33097
--- Comment #4 from steven at gcc dot gnu dot org 2010-07-15 23:05 ---
Fixed in the previous decade.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from steven at gcc dot gnu dot org 2010-07-15 23:02 ---
Wasn't this done (at least partially) by Martin?
--
steven at gcc dot gnu dot org changed:
What|Removed |
--- Comment #4 from steven at gcc dot gnu dot org 2010-07-15 22:56 ---
Fixed by Nathan Froyd's patches.
--
steven at gcc dot gnu dot org changed:
What|Removed |
--- Comment #3 from steven at gcc dot gnu dot org 2010-07-15 22:50 ---
Would be quite useful, though, for languages that do not have/allow pointer
arithmetic.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from steven at gcc dot gnu dot org 2010-07-15 22:43 ---
I would be surprised if this is not fixed now. Can someone with Java-fu check?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from steven at gcc dot gnu dot org 2010-07-13 11:28 ---
We have a separate bug for malloced memory. So this bug is FIXED.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #19 from steven at gcc dot gnu dot org 2010-07-13 11:27 ---
Ehm, Richi, WONTFIX why? Is this not what you added the alias attributes for?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17064
--- Comment #5 from steven at gcc dot gnu dot org 2010-07-13 11:00 ---
Insofar something that doesn't exist anymore can be considered broken, this bug
is FIXED:
;; Function x (x)
x ()
{
intD.0 aD.1233;
intD.0 D.1983;
# BLOCK 2 freq:1
# PRED: ENTRY [100.0%] (fallthru
--- Comment #5 from steven at gcc dot gnu dot org 2010-07-13 10:55 ---
Test case of comment #4 still fails with r162134.
Not sure what is expected for the test case of comment #0, but I'm assuming the
point is that the store of the reduction should be sunk. That doesn't ha
--- Comment #4 from steven at gcc dot gnu dot org 2010-07-13 10:49 ---
GCC 4.1 and GCC 4.2 are no longer maintained => WONTFIX.
--
steven at gcc dot gnu dot org changed:
What|Removed |Ad
--- Comment #9 from steven at gcc dot gnu dot org 2010-07-13 10:48 ---
Restrict has been implemented anew for GCC 4.6. Does that fix this bug?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from steven at gcc dot gnu dot org 2010-07-13 10:37 ---
Still present.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Last reconfirmed
--- Comment #5 from steven at gcc dot gnu dot org 2010-07-13 10:33 ---
r162134 at -O3:
;; Function h (h)
h (int * a)
{
:
*a_1(D) = 1;
return;
}
;; Function g (g)
g ()
{
int t1;
int t;
int t.0;
int D.1984;
:
t = 0;
h (&t);
t1_1 = t;
g1 (t1_1);
t.0_2 = t;
--- Comment #15 from steven at gcc dot gnu dot org 2010-07-13 10:29 ---
Still not fixed with r162134:
;; Function bar (bar)
bar ()
{
int prephitmp.4;
:
prephitmp.4_1 = i;
switch (prephitmp.4_1) , case 0: >
:
foo ();
prephitmp.4_7 = i;
# prephitmp.4_8 = PHI
:
swi
--- Comment #17 from steven at gcc dot gnu dot org 2010-07-13 10:21 ---
>From common.opt r161963:
fargument-alias
Common
Does nothing. Preserved for backward compatibility.
fargument-noalias
Common
Does nothing. Preserved for backward compatibility.
fargument-noalias-global
Com
--- Comment #3 from steven at gcc dot gnu dot org 2010-07-13 09:43 ---
I'll have a look.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Assig
--- Comment #3 from steven at gcc dot gnu dot org 2010-07-13 09:41 ---
Works with GCC 4.3, 4.4, 4.5, and trunk.
GCC 4.2 is no longer maintained, so this bug will not be fixed.
Richi, perhaps you can use the test case, put it in the test suite?
--
steven at gcc dot gnu dot org
--- Comment #2 from steven at gcc dot gnu dot org 2010-07-13 09:39 ---
Alias analysis has had two rewrites since last time someone commented on this
bug. Is this still a problem on the trunk?
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from steven at gcc dot gnu dot org 2010-07-12 09:54 ---
The correct answer is: "here is no sequence point between the two modifications
to x.".
If you don't know what a sequence point is, use Google (see first hit,
Wikipedia).
If you don't know C, do
--- Comment #21 from steven at gcc dot gnu dot org 2010-07-12 07:26 ---
I think this should not go into GCC 4.3 anyway. The problem is not a
regression, and the patch is non-obvious, so it's just not appropriate for a
stable release branch.
--
steven at gcc dot gnu dot org ch
--- Comment #4 from steven at gcc dot gnu dot org 2010-07-11 22:58 ---
Add TDF_SLIM?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44911
--- Comment #2 from steven at gcc dot gnu dot org 2010-07-11 22:56 ---
Martin, SRA related => yours?
--
steven at gcc dot gnu dot org changed:
What|Removed |Ad
--- Comment #16 from steven at gcc dot gnu dot org 2010-07-11 22:55 ---
Brief explanation about what the patch does:
* have a pointer to the location of the invariant within an rtx. The existing
code assumes a complete RHS is invariant, but with the patch GCC can move
invariants out of
--- Comment #15 from steven at gcc dot gnu dot org 2010-07-11 22:48 ---
Well, it's probably worth trying a little harder to grok them, then. Zdenek has
already said that the fix looks OK in principle, but I am not interested at all
in working on this patch anymore (especially not
--- Comment #13 from steven at gcc dot gnu dot org 2010-07-11 11:40 ---
Does the prototype fix of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36758#c21
help?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39837
--- Comment #3 from steven at gcc dot gnu dot org 2010-07-11 11:37 ---
Should this (and the other one) not be mentioned upstream somehow?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44904
--- Comment #3 from steven at gcc dot gnu dot org 2010-07-06 16:58 ---
Caused by, or exposed by ... in both cases your responsibility to investigate.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44838
--- Comment #14 from steven at gcc dot gnu dot org 2010-07-05 22:55 ---
The word 'bubblestrap' doesn't appear anywhere anymore in wwwdocs, and only in
ChangeLogs in trunk/*. And the GCC 4.2 branch is now closed.
So this bug is no longer relevant => WONTFIX.
--
ste
--- Comment #4 from steven at gcc dot gnu dot org 2010-07-03 22:03 ---
FWIW:
Apple should have its own bugurlMacPro:~ stevenb$ uname -a
Darwin MacPro.local 10.4.0 Darwin Kernel Version 10.4.0: Fri Apr 23 18:28:53
PDT 2010; root:xnu-1504.7.4~1/RELEASE_I386 i386
MacPro:~ stevenb$ gcc
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot
|dot org
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot
|dot org
--- Comment #5 from steven at gcc dot gnu dot org 2010-06-04 07:45 ---
AFAIU, you can't randomly change signed to unsigned, due to different overflow
semantics, which is why IVOPTS doesn't make this change itself. Imagine you
enter the loop with count = 0, and with a seco
--- Comment #2 from steven at gcc dot gnu dot org 2010-06-02 15:18 ---
Obviously mine.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
--- Comment #3 from steven at gcc dot gnu dot org 2010-06-02 09:13 ---
http://gcc.gnu.org/ml/gcc-cvs/2010-06/msg00056.html
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from steven at gcc dot gnu dot org 2010-06-02 09:02 ---
Alright, this hunk is apparently necessary, although I don't see how. Oh well.
I'll put it back.
Index: gimplify.c
===
--- gimplify.c (revis
--- Comment #2 from steven at gcc dot gnu dot org 2010-06-02 08:54 ---
HOIST should do this. You will have to check in the RTL dumps that the code is
exposed properly to this optimization.
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #26 from steven at gcc dot gnu dot org 2010-06-01 20:50 ---
May become relevant to GCC itself again if GCC wants to link to a static
libstdc++
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from steven at gcc dot gnu dot org 2010-05-30 16:55 ---
Should not ICE, though.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44332
--- Comment #1 from steven at gcc dot gnu dot org 2010-05-28 15:53 ---
Comes from dependency of FUNCTION_H on TM_H.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from steven at gcc dot gnu dot org 2010-05-28 14:51 ---
It looks like the mode field of struct fixed_value has to be streamed in/out
for LTO.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from steven at gcc dot gnu dot org 2010-05-28 13:10 ---
svn revision number? target triplet?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44312
--- Comment #1 from steven at gcc dot gnu dot org 2010-05-28 13:06 ---
This is OK, those files have only content for certain configurations (with
CLOOG, doloop pattern in the backend, etc.). You should look for a way to
suppress the warning without adding new symbols at random
--- Comment #3 from steven at gcc dot gnu dot org 2010-05-28 10:29 ---
This is not FIXED at all, just papered over.
See http://gcc.gnu.org/ml/gcc-patches/2010-05/msg02193.html
Please don't close bugs as FIXED if they have not been actually fixed.
--
steven at gcc dot gnu do
--- Comment #3 from steven at gcc dot gnu dot org 2010-05-28 10:26 ---
No regression patches pending, so the remaining pending patches will not be
committed to the GCC 4.5 release branch.
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #9 from steven at gcc dot gnu dot org 2010-05-28 10:24 ---
.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #2 from steven at gcc dot gnu dot org 2010-05-23 21:08 ---
CC: to alpha maintainer.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #49 from steven at gcc dot gnu dot org 2010-05-23 21:02 ---
Let's change the bug type at least, from a meta bug to a normal bug.
--
steven at gcc dot gnu dot org changed:
What|Removed |
--- Comment #1 from steven at gcc dot gnu dot org 2010-05-23 18:13 ---
Did you build with --enable-checking=release?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44256
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot
|dot org
--- Comment #3 from steven at gcc dot gnu dot org 2010-05-18 14:08 ---
Fixed for GCC 4.5.1 and later.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from steven at gcc dot gnu dot org 2010-05-18 14:07 ---
Subject: Bug 44184
Author: steven
Date: Tue May 18 14:06:31 2010
New Revision: 159532
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159532
Log:
gcc/
PR lto/44184
* lto-stream
--- Comment #1 from steven at gcc dot gnu dot org 2010-05-18 13:52 ---
Subject: Bug 44184
Author: steven
Date: Tue May 18 13:51:50 2010
New Revision: 159531
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159531
Log:
gcc/
PR lto/44184
* lto-stream
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
GCC build triplet|x86_64-pc-linux-gnu |
GCC host triplet|x86_64-pc-linux-gnu |
GCC target triplet
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot
|dot org
--- Comment #3 from steven at gcc dot gnu dot org 2010-05-15 23:04 ---
Why is flag_exceptions not just streamed out/in with other options?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44150
--- Comment #1 from steven at gcc dot gnu dot org 2010-05-13 23:33 ---
Confirmed, this is a case where a def could be sunk closer to its first use.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from steven at gcc dot gnu dot org 2010-05-11 10:24 ---
There is a GIMPLE uncprop pass for this. Could you verify that after this pass
there is just one assignment of the constant to an SSA_NAME? If so, the problem
is in the RTL CPROP pass, otherwise we have to look at
--- Comment #8 from steven at gcc dot gnu dot org 2010-05-10 21:29 ---
IMA will not be fixed. Actually, it never worked properly to begin with...
GCC 4.5 has -flto, but I don't expect it will do much better than IMA, from a
memory usage point of view. GCC 4.5 also has -fwhopr, but
--- Comment #1 from steven at gcc dot gnu dot org 2010-05-10 12:51 ---
+1 for the idea of a new "plugin" category.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44056
--- Comment #4 from steven at gcc dot gnu dot org 2010-05-10 11:00 ---
In other words: not an issue.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from steven at gcc dot gnu dot org 2010-05-10 06:55 ---
Re. comment #1:
(1) For this, there is the noinline attribute, as you already knew.
(2) See the noclone attribute
(3) See the regparm attribute
(4) You could use volatile and things like that, or put the unit in a
--- Comment #26 from steven at gcc dot gnu dot org 2010-05-08 10:38 ---
VEC_safe_push is quite safe, actually. But it may re-allocate the VEC. If you
really believe that VEC_safe_push is the problem here, then you should perhaps
look if a VEC is being passed around incorrectly somewhere
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #1 from steven at gcc dot gnu dot org 2010-05-07 22:31 ---
Ah, the old argument. But true. GCC internals documentation is almost
constantly out of sync with reality because of this. It's been like this for
years now and it is an underestimated problem.
Anyway, conf
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #1 from steven at gcc dot gnu dot org 2010-05-07 22:28 ---
Indeed. A serious issue.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #43 from steven at gcc dot gnu dot org 2010-05-07 22:23 ---
FIXED for x86_64-apple-darwin:
http://gcc.gnu.org/viewcvs?view=revision&revision=159173
ix86 and ppc* are still to be done.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43729
--- Comment #19 from steven at gcc dot gnu dot org 2010-05-06 21:38 ---
One possibility is to see if the glibc patches for this issue can be merged
into eglibc... Maxim what do you think?
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from steven at gcc dot gnu dot org 2010-05-05 21:36 ---
r114283 has been committed with some changes to fix bootstrap.
The other patches may take a bit more time. Not one of the revisions I brought
over passes bootstrap or testing without further modifications
--- Comment #8 from steven at gcc dot gnu dot org 2010-05-05 13:52 ---
I think that's an oversight, then. You shouldn't have to use the delayed edge
insert functions if you've pre-split all edges. Perhaps PRE can always use the
_immediate insert functions, and save a walk
--- Comment #5 from steven at gcc dot gnu dot org 2010-05-05 13:10 ---
I don't understand. We insert on edges now? Even though all critical edges are
split? I thought that if you insert on a critical edge, the commit is
instantanous, not delayed.
--
http://gcc.gnu.org/bug
--- Comment #4 from steven at gcc dot gnu dot org 2010-05-04 12:09 ---
What a horrible rule...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39427
--- Comment #39 from steven at gcc dot gnu dot org 2010-05-03 22:15 ---
I still don't understand the 32 bits problem.
Without LTO, there is this code in the for 2008_0.i:
L_mumble$non_lazy_ptr:
.indirect_symbol _mumble
In the WPA code mumble is gone in the cod
--- Comment #4 from steven at gcc dot gnu dot org 2010-05-03 20:46 ---
Created an attachment (id=20551)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20551&action=view)
Ported: r114283 r114291 r114307 r114348 r114396 r114397 r114400 r114401
--
http://gcc.gnu.org/b
--- Comment #3 from steven at gcc dot gnu dot org 2010-05-03 19:36 ---
OK, that didn't work... I'll just comment per revision.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43977
--- Comment #2 from steven at gcc dot gnu dot org 2010-05-03 19:35 ---
(From update of attachment 20548)
>
>r124989 | olga | 2007-05-23 14:49:49 +0200 (Wed, 23 Ma
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #1 from steven at gcc dot gnu dot org 2010-05-03 18:08 ---
Created an attachment (id=20548)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20548&action=view)
List of commits to the oldlto branch upto the rename point
The attached list was generated with:
svn d
oduct: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: meta-bug
Severity: enhancement
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: steven at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/sh
--- Comment #27 from steven at gcc dot gnu dot org 2010-05-03 16:56 ---
Zdenek, has anyone told you how amazing your contribution is here? Wow!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43879
--- Comment #24 from steven at gcc dot gnu dot org 2010-05-01 21:51 ---
Created an attachment (id=20527)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20527&action=view)
final patch
I plan to submit this, but with 32 bits disabled because I get failures I don'
--- Comment #20 from steven at gcc dot gnu dot org 2010-05-01 14:43 ---
On x86_64-unknown-linux-gnu, I see that gcc.dg/lto/20090126 also fails (see
http://gcc.gnu.org/ml/gcc-testresults/2010-05/msg00031.html). So the test
suite results on x86_64-darwin are the same as on x86_64-linux
--- Comment #19 from steven at gcc dot gnu dot org 2010-05-01 14:40 ---
Created an attachment (id=20526)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20526&action=view)
proof-of-concept patch, with Mach-O writer implemented now
Remaining failures due to missing supp
--- Comment #12 from steven at gcc dot gnu dot org 2010-04-30 13:22 ---
Iain, perhaps you should request to be confirmed as ObjC maintainer.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32052
--- Comment #17 from steven at gcc dot gnu dot org 2010-04-29 11:39 ---
I've played a bit with modified .s files by hand, and as/ld work if the LTO
sections follow the other sections.
The normal order of output with -flto looks like this in the .s file:
LTO sections (the __GN
--- Comment #16 from steven at gcc dot gnu dot org 2010-04-29 10:48 ---
Re. comment #14 this is now Apple radar 7920267. Let's see if someone on their
end can cq. is willing to help us out here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43729
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #7 from steven at gcc dot gnu dot org 2010-04-28 19:54 ---
Created an attachment (id=20509)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20509&action=view)
preprocessed test case, copied from comment #0
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39883
--- Comment #15 from steven at gcc dot gnu dot org 2010-04-28 19:50 ---
Re. comment #14, this is obviously related to LTO but we (gcc) don't do
anything with relocations. I'll try to reproduce this problem, but I suspect it
is an assembler or linker bug.
--
http://g
--- Comment #12 from steven at gcc dot gnu dot org 2010-04-27 20:25 ---
Created an attachment (id=20500)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20500&action=view)
proof-of-concept patch
This doesn't even include a Mach-O writer yet (except for the to be re
--- Comment #1 from steven at gcc dot gnu dot org 2010-04-26 17:21 ---
Regression from GCC 4.3, which still had libcall notes.
--- t.s.434 2010-04-26 10:21:18.0 -0700
+++ t.s.442 2010-04-26 10:21:36.0 -0700
@@ -2,6 +2,7 @@
.pred.safe_across_calls p1-p5
101 - 200 of 3051 matches
Mail list logo
