When trying to build the 20060906 gcc snapshot with gcc version 4.0.1 (built on
same machine) on a (quad) multiprocessor i686 GNU/Linux|SMP system (4GB RAM),
(not using ANY configure flags at all, issuing a plain "make") using the Linux
2.6.17.4 kernel (with enabled and working SMP support) I have
--- Comment #1 from WISD00M at GMX dot NET 2006-09-12 23:53 ---
Created an attachment (id=12238)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12238&action=view)
config.cache created by running ./configure w/o any flags
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29049
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-12 23:53 ---
I was able to compile 20060909 on i686-linux-gnu just fine.
How did you configure GCC?
Did you build in the src directory?
How did you invoke make to build GCC?
What is the output of ./config.guess in the source dir
--- Comment #3 from WISD00M at GMX dot NET 2006-09-12 23:54 ---
Created an attachment (id=12239)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12239&action=view)
config.log as created by configure
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29049
--- Comment #4 from WISD00M at GMX dot NET 2006-09-12 23:54 ---
Created an attachment (id=12240)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12240&action=view)
config.status as created by configure
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29049
--- Comment #5 from WISD00M at GMX dot NET 2006-09-12 23:55 ---
Created an attachment (id=12241)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12241&action=view)
toplevel Makefile created by configure
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29049
--- Comment #6 from WISD00M at GMX dot NET 2006-09-12 23:56 ---
Created an attachment (id=12242)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12242&action=view)
Makefile from gcc sub folder as created by configure
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29049
--- Comment #7 from WISD00M at GMX dot NET 2006-09-12 23:57 ---
Created an attachment (id=12243)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12243&action=view)
complete log from running make using "-d" debug switch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29049
--- Comment #8 from WISD00M at GMX dot NET 2006-09-12 23:58 ---
Created an attachment (id=12244)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12244&action=view)
last hundred lines of the complete Makefile log w/ debug output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2904
--- Comment #9 from WISD00M at GMX dot NET 2006-09-13 00:09 ---
> I was able to compile 20060909 on i686-linux-gnu just fine.
so was I, but not on a SMP (multi-processor) machine
> How did you configure GCC?
as I mentioned in the original report, I didn't use any configure whatsoever
or
--- Comment #10 from WISD00M at GMX dot NET 2006-09-13 00:12 ---
> > How did you configure GCC?
> as I mentioned in the original report, I didn't use any configure whatsoever
originally
Just for clarification: I missed to write "configure flags", of course I DID
use configure!
--
h
--- Comment #11 from WISD00M at GMX dot NET 2006-09-13 00:14 ---
Created an attachment (id=12245)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12245&action=view)
environment variables as requested
these are the environment variables that are set in bash for the root user
currentl
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2006-09-13 00:21
---
Thanks for taking the time to figure this out. I just have not had the time to
get setup to investigate. I am unassigning myself.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27964
--- Comment #12 from WISD00M at GMX dot NET 2006-09-13 00:24 ---
> > I was able to compile 20060909 on i686-linux-gnu just fine.
> so was I, but not on a SMP (multi-processor) machine
Just to summarize my original and somewhat lengthy reply: I have come to the
assumption that the SMP av
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-09-13 00:27
---
(In reply to comment #12)
No it does not. Are you sure you don't have some bad hardware?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29049
--- Comment #14 from WISD00M at GMX dot NET 2006-09-13 00:30 ---
Sorry, I just realized that I somehow managed to forget to post the actual
error and warning messages:
/root/tmp/plain/./gcc/xgcc -B/root/tmp/plain/./gcc/
-B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/
[EMAIL PROTECTED] current]$ cat f.f
character*10 a(4,2) /'aaa','bbb','ccc','ddd'/
end
[EMAIL PROTECTED] current]$ /usr/local/bin/gfortran -c f.f
f.f:0: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.
--- Comment #15 from WISD00M at GMX dot NET 2006-09-13 00:36 ---
> No it does not.
Well, as I said: it's just an assumption-for the lack of a better explanation
right now.
>Are you sure you don't have some bad hardware?
well, define "bad hardware"-the system works without any problems w
--- Comment #16 from WISD00M at GMX dot NET 2006-09-13 00:44 ---
Also, with regards to "bad hardware": this is a multiprocessor server system
that's in use every day, it's got numerous inbuilt hardware failure-detection
mechanisms, so as soon as there's a CPU, memory or hard disk problem
--- Comment #17 from WISD00M at GMX dot NET 2006-09-13 00:51 ---
> No it does not. Are you sure you don't have some bad hardware?
Just to summarize everything again: the "hardware" problem you anticipate would
then vanish partially when providing the "-m32" switch to xgcc/cc1 directly
--- Comment #18 from joseph at codesourcery dot com 2006-09-13 00:56
---
Subject: Re: New: possible problem: building gcc >= 4.2
on i686 GNU/Linux|SMP (non-64bit) platform fails
On Tue, 12 Sep 2006, WISD00M at GMX dot NET wrote:
> ./xgcc -B./ -B/usr/local/i686-pc-linux-gnu/bin/ -is
--- Comment #9 from jsm28 at gcc dot gnu dot org 2006-09-13 01:04 ---
Subject: Bug 14634
Author: jsm28
Date: Wed Sep 13 01:04:18 2006
New Revision: 116915
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116915
Log:
libcpp:
PR c/28768
PR preprocessor/14634
--- Comment #7 from jsm28 at gcc dot gnu dot org 2006-09-13 01:04 ---
Subject: Bug 28768
Author: jsm28
Date: Wed Sep 13 01:04:18 2006
New Revision: 116915
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116915
Log:
libcpp:
PR c/28768
PR preprocessor/14634
--- Comment #19 from WISD00M at GMX dot NET 2006-09-13 01:10 ---
Created an attachment (id=12246)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12246&action=view)
the complete configargs.h file from the build gcc sub directory
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=290
--- Comment #20 from WISD00M at GMX dot NET 2006-09-13 01:11 ---
I'm sorry, I obviously messed up the first translation unit that fails in my
original posting (the error that I posted was already a later error, when I had
adjusted the Makefile already). So, from a (FRESH) tarball extract
--- Comment #21 from WISD00M at GMX dot NET 2006-09-13 01:16 ---
Just for your info, when I now (again) MANUALLY ADD "-m32" to the parameter
list, everything works again as expected:
Reading specs from ./specs
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.2-20060906/configure
Th
[EMAIL PROTECTED] current]$ cat f.f
character*10 a(4,2) /'aaa','bbb','ccc','ddd'/
end
[EMAIL PROTECTED] current]$ /usr/local/bin/gfortran -c f.f
f.f:0: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.
[EMAIL PROTECTED] current]$ cat f.f
character*10 a(4,2) /'aaa','bbb','ccc','ddd'/
end
[EMAIL PROTECTED] current]$ /usr/local/bin/gfortran -c f.f
f.f:0: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-13 01:40 ---
*** This bug has been marked as a duplicate of 29051 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-13 01:40 ---
*** Bug 29052 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29051
--- Comment #10 from jsm28 at gcc dot gnu dot org 2006-09-13 02:27 ---
Fixed in 4.2.0 by making this a mandatory pedwarn.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #8 from jsm28 at gcc dot gnu dot org 2006-09-13 02:28 ---
Fixed in 4.2.0 by making this a mandatory pedwarn; I don't consider this
suitable to apply to past release branches which have had releases without the
pedwarn.
--
jsm28 at gcc dot gnu dot org changed:
With the following test case and no optimization, the dtp pointer is duplicated
resulting in the dtp-rec values getting mixed up during consecutive writes:
program avl
implicit none
real dt, t, a(10)
integer i, place
dt = 1.e-6
a = real( (/ (i, i=1, 10) /) )
open(unit=11, file='a
--- Comment #1 from kargl at gcc dot gnu dot org 2006-09-13 02:45 ---
It fails at all optimization levels on FreeBSD.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29053
--- Comment #22 from hjl at lucon dot org 2006-09-13 02:56 ---
I only saw this with gcc plus the biarch patch. I have no problem with building
gcc 4.2 on Linux/x86 SMP machines.
--
hjl at lucon dot org changed:
What|Removed |Added
-
--- Comment #1 from fang at csl dot cornell dot edu 2006-09-13 03:00
---
As you've written it, class C doesn't have any non-static members. Struct C::s
hasn't been declared as a member object of C. const int i is a member of C::s,
not C, so C() without member initializers should be ac
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-13 03:05 ---
(In reply to comment #1)
> It fails at all optimization levels on FreeBSD.
If a.dat and b.dat are still there, nothing changes in file size. Make sure
you removed them before running the program.
--
http://gcc.
--- Comment #23 from WISD00M at GMX dot NET 2006-09-13 03:16 ---
(In reply to comment #22)
> I only saw this with gcc plus the biarch patch.
what exactly is "this", could you be more specific?
did you see the VERY SAME type of error/warnings while trying to build?
and NO: this is an van
The following program:
struct A {
template
static A create(U) {}
};
namespace N {
class B {
B() {}
friend A A::create(const char*);
};
}
int main()
{
A a;
a.create("test");
}
compiled as follows:
g++ -v -c test.cpp
produces an ICE:
Using built-in specs.
Targe
--- Comment #24 from WISD00M at GMX dot NET 2006-09-13 03:24 ---
weird enough, when configuring target/host/build all set to
"i586-pc-linux-gnu", the whole make process still cancels at the same point,
even though the 64 bit stuff should theoretically not even be touched at
all(?).
thus
--- Comment #4 from bangerth at dealii dot org 2006-09-13 03:32 ---
With today's 4.1.x snapshot and on x86_64, I get this at -O2:
.L4:
mov %edx, %eax
incl%edx
cmpl%edx, %ecx
movl%esi, (%rdi,%rax,4)
jne .L4
-
--- Comment #3 from bangerth at dealii dot org 2006-09-13 03:34 ---
This appears to be working now on x86_64 with last night's gcc 4.1.x
subversion.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #1 from bangerth at dealii dot org 2006-09-13 03:39 ---
Confirmed. I see the same behavior on x86_64-linux-unknown-gnu. This
is a regression from 3.4.x that is present in at least the 4.0.x and 4.1.x
release branches (don't know about mainline).
W.
--
bangerth at dealii
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-13 03:49 ---
(In reply to comment #0)
> Note, when you add:
> int i = ((x.g(&x)), 3);
> a suitable diagnostic is emitted.
Now we don't do that either but that is a different bug.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-09-13 03:57 ---
(In reply to comment #3)
> Now we don't do that either but that is a different bug.
Actually we do reject it with -pedantic so that is not a different bug after
all but a change, a delerate change in fact.
--
ht
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-13 03:59 ---
This is not a regression on the mainline because of PR 24427.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from dannysmith at users dot sourceforge dot net 2006-09-13
03:59 ---
(In reply to comment #5)
> This is not DLL-related, the following code doesn't have the expected
> behaviour
> (although it works fine on i686-linux, even in the static case):
With gcc version 4.2.0
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9861
--- Comment #6 from bangerth at dealii dot org 2006-09-13 04:02 ---
Isn't this a duplicate of PR 28173 now?
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-13 04:03 ---
(In reply to comment #0)
> I am assuming the mangling change was deliberate. If so, the demangler should
> be updated.
The mangling change was to fix PR 9861. Maybe there is note linked from there
about how this sh
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-09-13 04:08 ---
(In reply to comment #6)
> Isn't this a duplicate of PR 28173 now?
Besides PR 28173 is a regression.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24427
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-13 04:18 ---
*** Bug 29050 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29051
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-13 04:18 ---
*** This bug has been marked as a duplicate of 29051 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
The testcase gcc.target/powerpc/darwin-bool-1.c fails when compiled on
Darwin PPC at -m64. It appears that sizeof(_Bool) returns 1 when the code
is compiled at -m64 rather than 4.
--
Summary: gcc.target/powerpc/darwin-bool-1.c fails on powerpc-
apple-darwin8 at -m6
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-09-13 04:25 ---
(In reply to comment #4)
> That means we get the same bad code there in both cases :-(
Actually that is better code than was produced before. Only the extra move is
there now. Except I don't get your results for e
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-13 04:27 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-13 04:28 ---
The testcase is invalid for -m64.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
/configure --prefix=/sw
--prefix=/sw/lib/gcc4 --enable-languages=c,c++,fortran
--infodir=/sw/lib/gcc4/share/info --with-gmp=/sw --with-included-gettext
--host=powerpc-apple-darwin8 --with-libiconv-prefix=/sw
Thread model: posix
gcc version 4.2.0 20060912 (experimental)
--
Summary
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2006-09-13
04:31 ---
Created an attachment (id=12247)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12247&action=view)
preprocessed file for ppc-negeq0-1.c generated on Darwin PPC at -m64
--
http://gcc.gnu.org/bugzil
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2006-09-13
04:32 ---
Created an attachment (id=12248)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12248&action=view)
assembly file for ppc-negeq0-1.c created on Darwin PPC at -m64
--
http://gcc.gnu.org/bugzilla/sho
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-13 04:32 ---
This also fails on powerpc64-linux-gnu but I have not looked into it yet.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
x=/sw
--prefix=/sw/lib/gcc4 --enable-languages=c,c++,fortran
--infodir=/sw/lib/gcc4/share/info --with-gmp=/sw --with-included-gettext
--host=powerpc-apple-darwin8 --with-libiconv-prefix=/sw
Thread model: posix
gcc version 4.2.0 20060912 (experimental)
--
Summary: gcc.target/powerpc/ppc64-a
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2006-09-13
04:39 ---
Created an attachment (id=12249)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12249&action=view)
preprocessed file for ppc64-abi-1.c generated on Darwin PPC at -m64
--
http://gcc.gnu.org/bugzill
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2006-09-13
04:40 ---
Created an attachment (id=12250)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12250&action=view)
assembly file for ppc64-abi-1.c created on Darwin PPC at -m64
--
http://gcc.gnu.org/bugzilla/show
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-13 04:44 ---
The testcase has not been updated for Darwin's asm syntax.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #25 from WISD00M at GMX dot NET 2006-09-13 05:02 ---
Just for your info: I just tried to compile the two previous official releases
on the same machine to troubleshoot this issue further (using no configure/make
flags WHATSOEVER, building in a separate build directory in both
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2006-09-13
05:07 ---
Andrew,
I am assuming this is the same old issue of Darwin prefixing
GPR references with 'r'. Can you suggest a test patch to achieve
that in this test?
Jack
--
http://gcc.gnu.org/
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-09-13 05:20 ---
(In reply to comment #4)
> Andrew,
> I am assuming this is the same old issue of Darwin prefixing
> GPR references with 'r'. Can you suggest a test patch to achieve
> that in this test?
It is not the same isue,
--- Comment #40 from pinskia at gcc dot gnu dot org 2006-09-13 05:25
---
Fixed on the mainline.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-13 05:25 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #26 from hjl at lucon dot org 2006-09-13 05:46 ---
I have a dual Northwood with HT. I am running 2.6.9 kernel from RHEL 4 U4. Can
you show me the output of
# uname -a
# cat /proc/cpuinfo
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29049
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-09-13 06:02 ---
No feedback in 3 months so closing.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-09-13 06:05 ---
This is nothing we can really do for very very old versions of GCC really, they
are no longer supported.
By the way when building 3.3.4, you should use make bootstrap and not just
make, it will most likely pass at t
--- Comment #7 from bkoz at gcc dot gnu dot org 2006-09-13 06:19 ---
For the record, I'm strongly in favor of variadic templates. Key parts of TR1
(tuple, functional) necessitate some kind of compiler support in order to have
full implementations: the current limits on tuple size are an
--- Comment #27 from WISD00M at GMX dot NET 2006-09-13 06:19 ---
(In reply to comment #26)
> # uname -a
as previously mentioned (comment #9), it's: "Linux syssiphus 2.6.17.4 #1 SMP
PREEMPT Mon Sep 11 14:42:28 CEST 2006 i686 unknown"
> # cat /proc/cpuinfo
processor : 0
vendor_id
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-13 06:21 ---
Confirmed, this is a regression as partition_stack_vars is new in 4.0.x.
I am thinking about either creating a meta-bug or a keyword about all the
problems with unstable sorts/hashing with memory addresses problems.
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-09-13 06:23 ---
(In reply to comment #7)
> Is there a good reason why gcc can't officially support being built without a
> libc by either figuring out that there's no libc itself or by offering some
> kind of --i-do-not-have-a-libc
--- Comment #5 from bkoz at gcc dot gnu dot org 2006-09-13 06:26 ---
Janis, this is how to set timeout on the "make check" command line:
time make check RUNTESTFLAGS="-v -v -v -v --tool_opts timeout=300"
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28870
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|minor |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29028
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-13 06:29 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #2 from rsandifo at gcc dot gnu dot org 2006-09-13 06:31
---
Subject: Bug 28982
Author: rsandifo
Date: Wed Sep 13 06:30:59 2006
New Revision: 116919
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116919
Log:
gcc/
PR rtl-optimization/28982
* reload.c
--- Comment #3 from rsandifo at gcc dot gnu dot org 2006-09-13 06:32
---
Patch applied
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #3 from ian at airs dot com 2006-09-13 06:36 ---
When I run the demangler on
_ZN5jmain4mainEJvP6JArrayIPN4java4lang6StringEE
I get
void jmain::main(JArray*)
The relevant patch went in on 2005-12-10 to libiberty/cp-demangle.c. Can you
confirm that you have that patch
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-09-13 06:39 ---
(In reply to comment #3)
> When I run the demangler on
> _ZN5jmain4mainEJvP6JArrayIPN4java4lang6StringEE
> I get
> void jmain::main(JArray*)
What happens when running it in "Java" mode (note the -s java)?
-
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2006-09-13 06:46
---
Investigating.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Assigne
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-09-13 06:56 ---
This one works for me but I doubt it is correct:
Index: ../../gcc/ipa-utils.c
===
--- ../../gcc/ipa-utils.c (revision 116919)
+++ ../../gcc/ipa-ut
101 - 186 of 186 matches
Mail list logo
