Young Teenie so risque and pretty!
http://xochupogadertas.com
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-09-20 06:09 ---
Actually, wait GCC outputs the correct thing:
case dw_val_class_die_ref:
if (AT_ref_external (a))
{
char *sym = AT_ref (a)-die_symbol;
gcc_assert (sym);
--- Comment #3 from d dot obermann at callassoftware dot com 2006-09-20
06:38 ---
I have this problem on AIX 5.3 with gcc 4.1.1 (also with 4.0.2)
In a small program the code below works but when I add this to my application,
the code is never executed. (My application is about 440MB
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-20 06:58 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #13 from bonzini at gnu dot org 2006-09-20 07:07 ---
reopening...
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|RESOLVED
--- Comment #14 from bonzini at gnu dot org 2006-09-20 07:07 ---
... because the appropriate resolution is WONTFIX
--
bonzini at gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||rejects-valid
Known to fail||3.0.4
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-20 07:12 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2006-09-20 07:50
---
(In reply to comment #7)
If you stll think that this is a libgfortran bug (I don't)
you could add
setvbuf(stdout, NULL, _IOLBF, 0);
to unix.c:output_stream() so that stdout always is line-buffered even
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-09-20 07:54
---
Not specific to mingw32.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2006-09-20 07:56
---
Any news on enabling libgcj by default?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19970
--- Comment #2 from pluto at agmk dot net 2006-09-20 08:00 ---
(In reply to comment #1)
I cannot reproduce this with 4.2.0 20060311 or 4.0.3 or 4.1.0 20060208.
Are you sure that you don't have a patch that causes problems?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24669#c3 causes
--- Comment #17 from fxcoudert at gcc dot gnu dot org 2006-09-20 08:01
---
Cross-building for mingw32 now works for me, and this bug has been inactive
long enough that we can close it. If someone has recent data on this, please
reopen!
--
fxcoudert at gcc dot gnu dot org changed:
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2006-09-20 08:05
---
I think this is fixed on 4.2:
$ gcc a.c
a.c:16:1: warning: setjmp redefined
In file included from a.c:7:
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/setjmp.h:41:1:
warning: this is the location of
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-09-20 08:12
---
double __attribute__((cdecl)) sqrt (double);
double __attribute__((stdcall)) log (double);
double cos (double);
With this code, we still (gcc-4.2) get:
$ gcc -c -W -Wall -mrtd b.c
b.c:1: warning:
--- Comment #2 from jakub at gcc dot gnu dot org 2006-09-20 08:22 ---
Subject: Bug 28046
Author: jakub
Date: Wed Sep 20 08:22:04 2006
New Revision: 117077
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117077
Log:
PR middle-end/28046
* c-omp.c
--- Comment #2 from tobias dot burnus at physik dot fu-berlin dot de
2006-09-20 08:27 ---
I looked what other are writing:
gfortran:
Fortran runtime error: Array reference out of bounds for array 'r', upper bound
of dimension 1 exceeded (in file 'array2.f90', at line
--- Comment #3 from jakub at gcc dot gnu dot org 2006-09-20 09:04 ---
Fixed on the trunk and redhat/gcc-4_1-branch.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from paul dot thomas at jet dot uk 2006-09-20 09:22 ---
(In reply to comment #15)
looks like there is agreement that the problem is fixed.
I am afraid to say that I do not agree entirely; the above takes 6 seconds to
compile with ifort on my Athlon 1700 a vapeur. The
--- Comment #3 from chris at bubblescope dot net 2006-09-20 09:50 ---
Actually, I think deque could do with a better max_size.
Some tests:
vectorint v;
v.resize(v.max_size());
Throws bad_alloc.
dequeint v;
v.resize(v.max_size());
Bus errors.
This is on i686-apple-darwin8, 4.0.1
Hi,
a recently introduced range check not only kills
legacy code that I use, but also gives a misleading
error message:
% cat gfcbug42.f
INTEGER IBALL(4)
DATA IBALL / Z'FF',
+ Z'' ,
+ Z'FF',
+ Z'' /
--- Comment #7 from dannysmith at users dot sourceforge dot net 2006-09-20
09:52 ---
(In reply to comment #6)
I think this is fixed on 4.2:
Its still broken on my machine
Try after compiling the testcase with optimization turned on.
Danny
--
--- Comment #1 from anlauf at gmx dot de 2006-09-20 09:53 ---
Created an attachment (id=12299)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12299action=view)
Legacy code example
Compiles fine with every other compiler out there.
--
--- Comment #4 from pcarlini at suse dot de 2006-09-20 10:09 ---
(In reply to comment #3)
Actually, I think deque could do with a better max_size.
It's not at all clear to me what we can possibly do in the general case of
discontiguous containers. Certainly, we don't want Segmentation
--- Comment #5 from chris at bubblescope dot net 2006-09-20 10:15 ---
The reason I bought this up here, is because I thought (and I could be wrong,
sorry) that the overflow was being caused by the fact that we allow the
container size to get too big, and if we pull max_size() down to a
--- Comment #6 from pcarlini at suse dot de 2006-09-20 10:22 ---
(In reply to comment #5)
The reason I bought this up here, is because I thought (and I could be wrong,
sorry) that the overflow was being caused by the fact that we allow the
container size to get too big, and if we
--- Comment #7 from pcarlini at suse dot de 2006-09-20 10:45 ---
... and in fact, even for vector, I think we can only reasonably provide a
time-independent upper-bound, because in general we cannot know how much memory
each element' constructor is going to allocate... No, I'm more and
--- Comment #8 from chris at bubblescope dot net 2006-09-20 11:10 ---
I agree also we can't do any better. On 64 bit systems it will be even harder
to give anything sensible.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29134
#include stdio.h
char str[] = abc;
const char *a1 = str;
struct A { operator const char *() {return str;} } a2;
volatile char *b1 = str;
struct B { operator volatile char *() {return str;} } b2;
int
main()
{
printf (%p\n, a1);
printf (%p\n, b1);
printf (%p\n, (const char *)a2);
printf
--- Comment #9 from tobias dot burnus at physik dot fu-berlin dot de
2006-09-20 11:57 ---
I think this is fixed.
If there are other errors, not covered, one could still reopen this bug or
create a new one.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23375
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-09-20 12:58 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-20 13:21 ---
So not a bug with the FSF GCC so closing.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pluto at agmk dot net 2006-09-20 13:25 ---
(In reply to comment #3)
Following patch to ix86_address_cost:
this patch causes the PR29124.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24669
--- Comment #9 from pcarlini at suse dot de 2006-09-20 15:00 ---
(In reply to comment #8)
I agree also we can't do any better. On 64 bit systems it will be even harder
to give anything sensible.
I'm only wondering whether it would make sense to divide by sizeof(T) also in
the other
--- Comment #6 from bkoz at gcc dot gnu dot org 2006-09-20 15:18 ---
Huh. Dave, is revision 116942M the same as revision 116942?
Of these, 19_diagnostics/23591_thread-1.c is probably the easiest to debug.
Since this is the linux target, and not the hpux target, the code paths for the
--- Comment #10 from pcarlini at suse dot de 2006-09-20 15:57 ---
(In reply to comment #9)
I'm only wondering whether it would make sense to divide by sizeof(T) also in
the other containers beside vector: the upper bound would be somewhat tighter
and still correct, AFAICS. What do
While passing -Djava.library.path=foobar to GCJ leads to the expected behaviour
on linux, it seems to be ignored on windows.
Actually System.getProperty(java.library.path) returns the correct value on
both plattforms, but System.loadLibrary() only uses it on linux.
--
Summary:
Runtime.exec(String[] cmdarray, String[] envp) doesn't set the environment on
windows but it works on linux.
This can be reproduced with the attached files (both compiled to executables
and CreateEnv calling PrintEnv).
--
Summary: [win32] Runtime.exec(String[] cmdarray, String[]
--- Comment #1 from mtrudel at gmx dot ch 2006-09-20 16:32 ---
Created an attachment (id=12300)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12300action=view)
Program that uses Runtime.exec(...)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29151
--- Comment #2 from mtrudel at gmx dot ch 2006-09-20 16:33 ---
Created an attachment (id=12301)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12301action=view)
Program that gets called by Runtime.exec(...) and doesn't have the environment
set
--
--- Comment #6 from bugreports at nn7 dot de 2006-09-20 16:38 ---
I am getting exactly the same here on ppc (so it is not just arm specific):
$ c++ -v
Using built-in specs.
Target: powerpc-linux-gnu
Configured with: ../src/configure -v
--- Comment #10 from sje at gcc dot gnu dot org 2006-09-20 16:41 ---
Subject: Bug 28574
Author: sje
Date: Wed Sep 20 16:41:12 2006
New Revision: 117084
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117084
Log:
PR target/28574
* ifcvt.c (dead_or_predicable): Don't
Currently, due to the absence of a 64-bit port for Darwin PPC, the libffi
suffers massive failures on that architecture at -m64...
=== libffi Summary for unix/-m32 ===
# of expected passes1068
# of expected failures 8
# of unsupported tests 8
--- Comment #1 from mtrudel at gmx dot ch 2006-09-20 16:49 ---
Tom commented this on the mailing list. Might be useful:
Offhand I would expect this to work ok. You might verify that USE_LTDL is set
on Windows; see the two definitions of _Jv_SetDLLSearchPath in
natSystemProperties.cc.
--- Comment #11 from sje at cup dot hp dot com 2006-09-20 16:49 ---
Fix is now checked in.
--
sje at cup dot hp dot com changed:
What|Removed |Added
--- Comment #2 from tromey at gcc dot gnu dot org 2006-09-20 16:53 ---
This will be fixed by the ecj merge; we're deleting this version of gcjh.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
The new Unsafe code assumes pthreads in a number of places.
This blocks a merge.
--
Summary: [ecj] clean up pthread assumptions
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #16 from tromey at gcc dot gnu dot org 2006-09-20 16:57 ---
Yes, this is a regression.
It works fine with -O2 with my system compiler (FC5 gcc, based on gcc 4.1).
It also works fine with -O2 using my gcc 4.1 build.
It fails with svn head.
--
--- Comment #2 from tromey at gcc dot gnu dot org 2006-09-20 17:04 ---
Yes, I plan on making an ecj jar download available.
In the near term I will put one on gcc.gnu.org (or elsewhere).
In the longer term I plan to get my ecj changes upstream, and then
we will be able to point people
On Wed, 2006-09-20 at 16:38 +, bugreports at nn7 dot de wrote:
--- Comment #6 from bugreports at nn7 dot de 2006-09-20 16:38 ---
I am getting exactly the same here on ppc (so it is not just arm specific):
Yes it is. The bug you are getting with PPC is a different bug and
should
--- Comment #7 from pinskia at physics dot uc dot edu 2006-09-20 17:16
---
Subject: Re: [4.1/4.2 regression] ICE in extract_insn,
at recog.c:2084 (unrecognizable insn) [arm]
On Wed, 2006-09-20 at 16:38 +, bugreports at nn7 dot de wrote:
--- Comment #6 from
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29152
--- Comment #17 from ebotcazou at gcc dot gnu dot org 2006-09-20 17:38
---
Yes, this is a regression.
It works fine with -O2 with my system compiler (FC5 gcc, based on gcc 4.1).
It also works fine with -O2 using my gcc 4.1 build.
It fails with svn head.
Thanks for the info.
--
--- Comment #18 from ebotcazou at gcc dot gnu dot org 2006-09-20 17:39
---
Investigating.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2006-09-20 17:42
---
Thanks for the fix.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org |
Overview:
The following C generates bad assembler on both PowerPC and Intel, even with no
optimization:
*( *pDest++ )++ = *pSource++;
Ripping this apart into two lines succeeds, thus:
**pDest = *pSource++;
*( *pDest++ )++;
System Description:
System: Apple OS X 10.4 (gcc 4.0.1) and
--- Comment #7 from sgilbertson at gcc dot gnu dot org 2006-09-20 18:45
---
I checked out revision 117082 (trunk) and successfully built a few static
binaries with it. So unless Thomas saw a different problem than I did, I'd say
it's fixed.
Configured with: ../gcc/configure
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-20 18:47 ---
**pDest = *pSource++;
*( *pDest++ )++;
[t1.c : 1055] D.1948 = *pWriteBuf;
[t1.c : 1055] D.1949 = *pReadBuf;
[t1.c : 1055] *D.1948 = D.1949;
[t1.c : 1055] pReadBuf = pReadBuf + 1B;
[t1.c : 1056] D.1950
--- Comment #22 from jconner at gcc dot gnu dot org 2006-09-20 18:57
---
Subject: Bug 25505
Author: jconner
Date: Wed Sep 20 18:57:46 2006
New Revision: 117091
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117091
Log:
2006-09-20 Josh Conner [EMAIL PROTECTED]
PR
--- Comment #8 from tromey at gcc dot gnu dot org 2006-09-20 19:15 ---
ok, I'm closing.
Please reopen if it is still a problem.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pluto at agmk dot net 2006-09-20 20:44 ---
(In reply to comment #7)
and one more misscompiled program - gzip-1.3.5.
this time 4.1.2 with -O2 -fwrapv produces wrong code.
$ dd if=/dev/zero of=foo count=10
$ gzip foo
$ gzip -d foo.gz
$ gzip: foo.gz: invalid
--- Comment #9 from pluto at agmk dot net 2006-09-20 20:44 ---
Created an attachment (id=12302)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12302action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28230
--- Comment #5 from guerby at gcc dot gnu dot org 2006-09-20 20:46 ---
Subject: Bug 28716
Author: guerby
Date: Wed Sep 20 20:46:28 2006
New Revision: 117092
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117092
Log:
2006-08-20 Laurent GUERBY [EMAIL PROTECTED]
PR
--- Comment #7 from sje at cup dot hp dot com 2006-09-20 21:23 ---
This bug is weird. If I remove the code in cse_insn where the dest_addr_elt
field is used, I still get the bug. So the problem occurs when creating the
dest_addr_elt data, not when using it. This makes no sense to me,
--- Comment #6 from laurent at guerby dot net 2006-09-20 21:51 ---
Fixed on 4.2
--
laurent at guerby dot net changed:
What|Removed |Added
Status|NEW
Dear Readers,
Although this is not a bug report I tought I better to ask
my problem in here and ask you if you can help me.
I have to add some user defined procedures or types to C and to alter GCC
to detect these changes, actually I want to alter the C language
definition which is given to GCC.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26698
--- Comment #2 from lopezibanez at gmail dot com 2006-09-20 22:04 ---
I can confirm this in a recent build of GCC: (GNU) 4.2.0 20060913
(experimental) on i686-pc-linux-gnu.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28405
--- Comment #1 from steven at gcc dot gnu dot org 2006-09-20 22:05 ---
The bug database is no place for this kind of question. First you should look
for answers in the source code. This will be trial and error, but this is your
exercise so don't ask us to make it for you. If you get
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28077
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28096
--- Comment #3 from steven at gcc dot gnu dot org 2006-09-20 22:19 ---
*** This bug has been marked as a duplicate of 24929 ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from steven at gcc dot gnu dot org 2006-09-20 22:19 ---
*** Bug 28405 has been marked as a duplicate of this bug. ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
The testcase below gets misscompiled at -O2.
The alias info looks this way:
Dereferenced pointers
xa, UID 1527, struct test1 *, symbol memory tag: SMT.4, default def: xa_4
xb, UID 1528, struct test2 *, symbol memory tag: SMT.5, default def: xb_3
Symbol memory tags
SMT.4, UID 1547, struct
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28183
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28211
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||alias
Known to fail||4.2.0
--- Comment #4 from mmitchel at gcc dot gnu dot org 2006-09-20 22:26
---
Marked as P5 because this is marked as applying to Alpha/OSF. If this problem
applies to other platforms, please set back to P3 with explanatory comment.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28307
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-20 22:26 ---
Confirmed, a regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28604
--- Comment #4 from abs at absd dot org 2006-09-20 22:27 ---
Seeing the same issue with gcc 3.4.6 on NetBSD/i386 4.0_BETA using gmake 3.81
and SHELL=/bin/tcsh
--
abs at absd dot org changed:
What|Removed |Added
--- Comment #2 from mmitchel at gcc dot gnu dot org 2006-09-20 22:32
---
A meta-bug would be helpful.
I've marked this P2, since this bug doesn't actually result in a
user-observable problem on a single host -- but it is extremely desirable from
the point of view of us, as GCC
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29020
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29021
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29022
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29024
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29039
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29048
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29080
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29091
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29092
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-09-20 22:49
---
The language linkage of the type is supposed to matter in some cases -- but G++
doesn't implement that, so I don't think the difference is observable in GNU
C++. In any case, we should try to make the file
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29105
--- Comment #8 from pbrook at gcc dot gnu dot org 2006-09-20 22:55 ---
IIRC my change can cause entries to be present into the hash table that
wouldn't have been there before. However this should be harmless. I don't have
any helpful suggestons why this is broken.
--
--- Comment #9 from dannysmith at gcc dot gnu dot org 2006-09-20 23:27
---
Subject: Bug 27650
Author: dannysmith
Date: Wed Sep 20 23:27:05 2006
New Revision: 117096
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117096
Log:
PR target/27650
* class.c
--- Comment #10 from pluto at agmk dot net 2006-09-20 23:31 ---
i have a reduced testcase:
$ cat tmp.c
void foo( unsigned long bb, unsigned short tn, unsigned e, unsigned* w )
{
unsigned n = tn + bb;
do {
e = (e n) ? e : *w;
n -= (e n)
--- Comment #10 from dannysmith at gcc dot gnu dot org 2006-09-20 23:32
---
Subject: Bug 27650
Author: dannysmith
Date: Wed Sep 20 23:32:07 2006
New Revision: 117097
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117097
Log:
PR target/27650
*
--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2006-09-20
23:33 ---
Subject: Re: [4.2 Regression] Timeouts in libstdc++, libjava and libgomp
testsuites
Huh. Dave, is revision 116942M the same as revision 116942?
I applied r116954 to 116942.
Of these,
1 - 100 of 138 matches
Mail list logo
