On Thu, Aug 25, 2005 at 11:00:50AM -0400, DJ Delorie wrote:
>> FWIW, I should note that GCJ already has support for @file
>> style list of input files:
>>
>> http://gcc.gnu.org/onlinedocs/gcj/Input-and-output-files.html
>>
>> and has had it for quite some time now.
>
>DJGPP and Cygwin hosted pr
Attached file tells everything.
> I am nearly ready to commit this patch but I went overboard and had it
> search in mingw and MSYS locations for the program to run (i.e.,
> "/bin/sh").
Since there's no MinGW shell, there's no point in looking in there.
Then it occurred to me that maybe this was a little too
> "product specif
On Aug 25, 2005, at 5:53 PM, Ivan Novick wrote:
Yes understood, but thats the whole point, cygwin runs on a windows
machine...
Odd, I was running it on a solaris machine not windows. Maybe you
forgot to recompile it on a UNIX machine?
configure --with-headers=/cygwin/usr/include --with-li
Ivan Novick <[EMAIL PROTECTED]> wrote:
> Can you recommend a solution for compiling Windows DLLs on any variation of
UNIX?
You want mingw, I think. The doc for this is somewhat scanty.
See e.g.
http://www.mingw.org/mingwfaq.shtml#faq-cross
http://wiki.wxwidgets.org/wiki.pl?Install_The_Mingw_Cro
On Aug 25, 2005, at 5:53 PM, Ivan Novick wrote:
Yes understood, but thats the whole point, cygwin runs on a windows
machine... I would like to use a UNIX machine to compile the
Windows DLL.
You can cross compile to cygwin using gcc.
An old link from google with "cross compiler cygwin" is
Yes understood, but thats the whole point, cygwin runs on a windows
machine... I would like to use a UNIX machine to compile the Windows
DLL.
From a system admin point of view, we would like to have a UNIX
compile host to produce the DLL, since we primarily only deal with
UNIX anyway.
H
On Aug 25, 2005, at 5:09 PM, Ivan Novick wrote:
Can you recommend a solution for compiling Windows DLLs on any
variation of UNIX?
Yes, just use cygwin, see the cygwin folks for details.
Can you recommend a solution for compiling Windows DLLs on any
variation of UNIX?
We currently do this with Cygwin/Windows, but would like to go one
step further and do the builds on a UNIX machine that produces
Windows DLLs.
Thanks for any advice,
Ivan
Snapshot gcc-4.0-20050825 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20050825/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.0 CVS branch
with the following options: -rgcc-ss-4_0-20050825
You'll
> but I don't think DJ and I are yet seeing eye-to-eye on (b).
I think it's a bad idea to choose a solution that requires each
application (we have many) to be modified to call an extra function.
It would be far better to have the OS manage it transparently.
However, I don't see a way to do that
Tristan Wibberley wrote:
Mark Mitchell wrote:
However, there's demonstrable interest in this feature for GNU/Linux as
well, from the lists, and for Java on all operating systems.
Please don't use '@filename' on Linux, use a normal switch with an
argument. The problems of '-' being used fo
-Original Message-
From: jacky
Sent: Monday, Aug 20, 2005 5:14 PM
To: Amelie
Cc: Vera, Chris
Subject: wow !
http://optimum.atw.hu
Etienne Lorrain wrote:
> Investigated again a big increase of size going from GCC-3.4 to 4.x
> (gcc (GCC) 4.0.2 20050811 (prerelease)) on my Gujin-v1.2, quickly way
> to reproduce:
If you want this fixed, you should file a bug report into our bugzilla
database.
Here is a quicker way to reprod
Dale Johannesen wrote:
> This is wrong, because 4 bytes starting at 73 goes outside the original
> object and can
> cause a page fault.
FYI You can write a testcase for this by using mmap to allocate a page
of memory, putting a copy of the structure 76 bytes from the end of the
mmapped region, and
Ralf Schubert wrote:
> is there any reference about the warning- and error-messages gcc (e.g.
> 4.0.1) produces when compiling a C-source code ?
> What I'm looking for is a summary with some explanations. I tried hard,
> but couldn't find something suitable.
We don't have a list of all of the warn
On Thu, Aug 25, 2005 at 12:37:32PM -0700, Ian Lance Taylor wrote:
> For what it's worth, as I told Fariborz, I suspect that returning 0 is
> correct for SFmode, but I'm somewhat doubtful for DFmode.
Indeed.
> And his test case is odd since the resulting code has more instructions
> and is larger.
On Thu, Aug 25, 2005 at 04:00:53PM -0400, DJ Delorie wrote:
>> So, should it default to finding an executable on the path first and
>> then look for MinGW/MSYS versions of the program if it can't find
>> the executable on the path?
>
>Hmmm... 99% of the cases will be "#!/bin/sh" anyway. What's the
Mark Mitchell wrote:
> However, there's demonstrable interest in this feature for GNU/Linux as
> well, from the lists, and for Java on all operating systems.
>
Please don't use '@filename' on Linux, use a normal switch with an
argument. The problems of '-' being used for switches is bad enough
On Aug 25, 2005, at 3:59 PM, Fariborz Jahanian wrote:
I think the problem may be somewhere else. I got the same xmm0 code
sequence on Linux/ia32 with -msse3 -mfpmath=sse. However, I got
xorl%eax, %eax
movq%rax, 16(%rdi)
movq%rax, 8(%rdi)
movq%rax
On Aug 25, 2005, at 12:47 PM, H. J. Lu wrote:
On Thu, Aug 25, 2005 at 12:37:32PM -0700, Ian Lance Taylor wrote:
Fariborz Jahanian <[EMAIL PROTECTED]> writes:
Forgot to attach the patch:
Index: i386.c
===
RCS file: /cvs/gcc/gc
> So, should it default to finding an executable on the path first and
> then look for MinGW/MSYS versions of the program if it can't find
> the executable on the path?
Hmmm... 99% of the cases will be "#!/bin/sh" anyway. What's the
"right" shell to run for that in MinGW? If you can detect MinG
On Thu, Aug 25, 2005 at 02:59:24PM -0400, DJ Delorie wrote:
>pex-win32 is used by both MinGW and generic "winnt" targets, so I'd
>say keeping it generic is preferred, but if MinGW can be detected, add
>those checks too.
So, should it default to finding an executable on the path first and
then look
On Thu, Aug 25, 2005 at 12:37:32PM -0700, Ian Lance Taylor wrote:
> Fariborz Jahanian <[EMAIL PROTECTED]> writes:
>
> > Forgot to attach the patch:
> >
> > Index: i386.c
> > ===
> > RCS file: /cvs/gcc/gcc/gcc/config/i386/i386.c,v
> >
Fariborz Jahanian <[EMAIL PROTECTED]> writes:
> Forgot to attach the patch:
>
> Index: i386.c
> ===
> RCS file: /cvs/gcc/gcc/gcc/config/i386/i386.c,v
> retrieving revision 1.795.4.33
> diff -c -p -r1.795.4.33 i386.c
> *** i386.c
Dale Johannesen <[EMAIL PROTECTED]> writes:
> The test of f->b comes out as
>
>testl $1048512, 73(%eax)
>
> This is wrong, because 4 bytes starting at 73 goes outside the
> original object and can
> cause a page fault. The change from referencing a word at offset 72
> to offset 73
> happen
pex-win32 is used by both MinGW and generic "winnt" targets, so I'd
say keeping it generic is preferred, but if MinGW can be detected, add
those checks too.
Using WindowsRoutinesForQueryingStuff is fine; that file is already
Win32 specific. Just don't break the mscdll stuff ;-)
On Thu, Aug 11, 2005 at 02:20:04PM -0400, Christopher Faylor wrote:
>On Wed, Aug 10, 2005 at 05:30:03PM -0400, DJ Delorie wrote:
>>> Well, it's stopping a real fix for the MinGW build failure being made.
>>> Adding #! support to libiberty won't work because the problem scripts
>>> have MSYS/Cygwin
On Thu, Aug 25, 2005 at 10:51:42AM -0400, DJ Delorie wrote:
>
> > I'm not sure how I can "fix MinGW"; see above. Also, if a MinGW
> > application wants to invoke some other Windows program, the behavior
> > should be the same as if I compiled that application with Visual C, or
> > Intel's C co
DJ Delorie wrote:
feature even on Unix systems. But on Unix systems I think we need to
at least consider the possibility of real source file names starting
with '@'. The patch as it stands will have a rather perplexing effect
if such a file is compiled. Maybe that's OK.
This is different fro
On Thu, Aug 25, 2005 at 10:27:12AM -0700, Ian Lance Taylor wrote:
> Mark Mitchell <[EMAIL PROTECTED]> writes:
>
> > I've created a new 4.2 Project page for "response files", which is
> > what Microsoft calls files that contain command-line options.
> > Conventionally, if you pass "@file" as an arg
* Florian Weimer:
> * Dale Johannesen:
>
>> The test of f->b comes out as
>>
>> testl $1048512, 73(%eax)
>>
>> This is wrong, because 4 bytes starting at 73 goes outside the
>> original object and can cause a page fault.
>
> sizeof (struct Flags) is 76, so this isn't a bug, IMHO.
Scratch that,
On Aug 25, 2005, at 2:09 PM, Fariborz Jahanian wrote:
Compiled with -O1 -mdynamic-no-pic -march=pentium4 produces:
pxor%xmm0, %xmm0
movsd %xmm0, 16(%eax)
movsd %xmm0, 8(%eax)
movsd %xmm0, (%eax)
But following code results in 7% performance gain in eon
Forgot to attach the patch:
Index: i386.c
===
RCS file: /cvs/gcc/gcc/gcc/config/i386/i386.c,v
retrieving revision 1.795.4.33
diff -c -p -r1.795.4.33 i386.c
*** i386.c 15 Aug 2005 23:36:10 - 1.795.4.33
--- i386.c 25
* Dale Johannesen:
> The test of f->b comes out as
>
> testl $1048512, 73(%eax)
>
> This is wrong, because 4 bytes starting at 73 goes outside the
> original object and can cause a page fault.
sizeof (struct Flags) is 76, so this isn't a bug, IMHO.
(Note! I am starting a new thread of an old thread because of old
thread's corruption which prevented me from responding).
Following test case:
struct S {
double d1, d2, d3;
};
struct S ms()
{
struct S s = {0,0,0};
return s;
}
Compiled with -O1 -mdynamic-no-pic -march
20548 seems to be fixed on x86_64 (I've put it in WAITING for powerpc
and hppa where it was also reported), but two new regressions appeared,
those are probably unrelated to your patch:
23564: c52104f c52104h (run) missing check
23565: c32001e (run x86_64 only) inccorect array bounds
I didn't che
The following demonstrates a bug in combine
(x86 -mtune=pentiumpro -O2):
struct Flags {
int filler[18];
unsigned int a:14;
unsigned int b:14;
unsigned int c:1;
unsigned int d:1;
unsigned int e:1;
unsigned int f:1;
};
extern int bar(int), baz();
int foo (struct Flags *f) {
if (f->
On Thu, Aug 25, 2005 at 06:49:06PM +0530, Ashwin Kolhe wrote:
> I am actually trying to find out WHY and WHEN peep2_reg_dead_p
> was introduced.
When the peephole2 pass was introduced. Another feature of the
peephole2 pass is that we can allocate *new* scratch registers,
and the pattern fails to
On Thu, 2005-08-25 at 02:42 -0400, James Morrison wrote:
> Hey,
>
> I'm going to do more testing on this, but it seems this patch reduces the
> number of DOM iterations from the number of else if statements in pr19097 to
> 2 DOM iterations.
Certainly any time we can optimize more of the compari
> gcc -c ./@foop.cpp
>
> and of course the same goes for files with names that begin with '-'.
That only works if the argument reflects a file name, and not some
other syntactical sugar. Granted, gcc has no such arguments, but
libiberty has a wider scope than just gcc.
> feature even on Unix systems. But on Unix systems I think we need to
> at least consider the possibility of real source file names starting
> with '@'. The patch as it stands will have a rather perplexing effect
> if such a file is compiled. Maybe that's OK.
What DJGPP and Cygwin do is thusl
On Thu, Aug 25, 2005 at 10:27:12AM -0700, Ian Lance Taylor wrote:
> [ re: @file ]
> Without getting into whether it's a good idea to overcome OS
> limitations in this way, I do think that response files are a useful
> feature even on Unix systems. But on Unix systems I think we need to
> at least
Mark Mitchell <[EMAIL PROTECTED]> writes:
> I've created a new 4.2 Project page for "response files", which is
> what Microsoft calls files that contain command-line options.
> Conventionally, if you pass "@file" as an argument to a program, the
> file is read, and the contents are treated as comm
On Aug 25, 2005, at 6:19 AM, Ashwin Kolhe wrote:
I am actually trying to find out WHY and WHEN peep2_reg_dead_p
was introduced. I checked the mailing list but dint find anything
relavent.
Did you do a cvs diff/log and hunt it down, read the check-in
comment, then find a PR number and read it,
On Aug 24, 2005, at 3:54 PM, Jiang Long wrote:
After a while I got the following errors with :
configure: error: `target_alias' was not set in the previous run
configure: error: changes in the environment can compromise the build
configure: error: run `make distclean' and/or `rm ./config.cache
On Thu, Aug 25, 2005 at 06:09:25PM +0200, Florian Weimer wrote:
> * Andi Kleen:
>
> > Linux has a similar limit which comes from the OS (normally around 32k)
> > So it would be useful there for extreme cases too.
>
> IIRC, FreeBSD has a rather low limit, too. And there were discussions
> about
> And there were discussions about command line length problems in the GCC
build process on VMS.
The problem on VMS is not so much total command line length as element
length, e.g. strlen (argv [x]). A single element cannot exceed 1024
characters or something like that (have to look it up to b
On Thu, Aug 25, 2005 at 06:09:25PM +0200, Florian Weimer wrote:
> * Andi Kleen:
>
> > Linux has a similar limit which comes from the OS (normally around 32k)
> > So it would be useful there for extreme cases too.
>
> IIRC, FreeBSD has a rather low limit, too. And there were discussions
> about
* Andi Kleen:
> Linux has a similar limit which comes from the OS (normally around 32k)
> So it would be useful there for extreme cases too.
IIRC, FreeBSD has a rather low limit, too. And there were discussions
about command line length problems in the GCC build process on VMS.
On Wed, 2005-08-24 at 18:28 -0400, Daniel Berlin wrote:
> > If we take this after DCE, we still refer to a statement which no longer
> > exists which we don't collect in the GC.
> As i said when i pointed this out to you, we should probably skip
> walking common.chain on SSA_NAME.
> But that's non-
On Wed, 2005-08-24 at 18:19 -0400, Andrew Pinski wrote:
> I am writing a "quick and dirty" DCE pass which is faster the
> current DCE and does not do anything with stores/loads.
FWIW, I've always been a fan of a very very simple DCE pass
which can be scheduled often, possibly after every pass that
> Ive never been a big fan of having to call something to release
> ssa_names, its too bug prone. I would much prefer to see something like
> a cleanup pass done every once in a while... an ssa-name garbage
> collector if you will :-). It seems to me that between major
> optimization passes, any
On Thu, Aug 25, 2005 at 02:02:48PM +0530, Ashwin wrote:
> However if the pattern happens to be something like this :
>
> op0 = 1
> op0 = op0 leftshift op2
Ah, I see. Well, peep2_reg_dead_p doesn't include "or_set" in its
definition, so it shouldn't do what you're suggesting. I wouldn't
be oppos
On 8/25/05, DJ Delorie <[EMAIL PROTECTED]> wrote:
>
> > FWIW, I should note that GCJ already has support for @file
> > style list of input files:
> >
> > http://gcc.gnu.org/onlinedocs/gcj/Input-and-output-files.html
> >
> > and has had it for quite some time now.
>
> DJGPP and Cygwin hosted pro
> "Jim" == James E Wilson <[EMAIL PROTECTED]> writes:
Jim> The interface between the front ends and cgraph really needs to be
Jim> worked out here. Currently, the C and C++ front ends are calling some
Jim> cgraph functions in different orders, and we are having lots of debug
Jim> related prob
> "Ranjit" == Ranjit Mathew <[EMAIL PROTECTED]> writes:
Ranjit> FWIW, I should note that GCJ already has support for @file
Ranjit> style list of input files:
Ranjit> http://gcc.gnu.org/onlinedocs/gcj/Input-and-output-files.html
Ranjit> and has had it for quite some time now.
Also, the inter
> Yup. Simple things like 'ls *' or 'rm -rf a*' can bring you all the joy.
I hesitate to point out that the problem isn't long command lines per
se, it's that we have a poor way of specifying large quantities of
information that, perhaps, belongs in an include file somehow.
#define FOOINC "/usr/
DJ Delorie wrote:
Only on one out of three supported windows platforms. The other two
already have it as part of the "os".
but that one out of three is by far the most
important one in practice!
DJ Delorie wrote:
I'm not sure how I can "fix MinGW"; see above. Also, if a MinGW
application wants to invoke some other Windows program, the behavior
should be the same as if I compiled that application with Visual C, or
Intel's C compiler, or whatever; if we were using magic to pass
command
> FWIW, I should note that GCJ already has support for @file
> style list of input files:
>
> http://gcc.gnu.org/onlinedocs/gcj/Input-and-output-files.html
>
> and has had it for quite some time now.
DJGPP and Cygwin hosted programs will never see these options, because
the runtime has alread
> Mark's patch is apparently necessary for good Windows support,
Only on one out of three supported windows platforms. The other two
already have it as part of the "os".
> I'm not sure how I can "fix MinGW"; see above. Also, if a MinGW
> application wants to invoke some other Windows program, the behavior
> should be the same as if I compiled that application with Visual C, or
> Intel's C compiler, or whatever; if we were using magic to pass
> command-line ar
> Do you mean the source code? A hint: grep ^func_name *.c will get to it
> for every function in gcc.
>
> In this case it is in recog.c, look at peep2_reg_dead_p but also
> peep2_regno_dead_p. There are other peep2_* functions you may use.
>
> Paolo
I am sorry.. I think u got me wrong. I have
On 2005-08-25, at 13:57, Paolo Bonzini wrote:
Marcin Dalecki wrote:
On 2005-08-25, at 09:14, Christoph Hellwig wrote:
That's what I meant with my comment btw. It's a horrible idea to
put in all the junk to support inferior OSes into gcc and all other
other programs, and with cygwin and djg
Ashwin Kolhe wrote:
On 8/25/05, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
I consider this to be less readable than the peep2 way to do it,
especially if your peephole2 had three or four instructions. And
peep2_regno_dead_p uses an array (a circular buffer) so it's more
efficient. Indeed dea
On 8/25/05, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
> I consider this to be less readable than the peep2 way to do it,
> especially if your peephole2 had three or four instructions. And
> peep2_regno_dead_p uses an array (a circular buffer) so it's more
> efficient. Indeed dead_or_set_p even has
Marcin Dalecki wrote:
On 2005-08-25, at 09:14, Christoph Hellwig wrote:
That's what I meant with my comment btw. It's a horrible idea to
put in all the junk to support inferior OSes into gcc and all other
other programs, and with cygwin and djgpp there are already two nice
enviroments for tha
operands[0] == operands[1] || peep2_regno_dead_p (2, operands[0])
Exactly.. this is the same thing as calling dead_or_set_p(insn,
operands[0]).
i am sorry, since we are using peephole2, the variable "insn" points
to the first insn in the template and not the last. so the call should
be
On 2005-08-25, at 09:14, Christoph Hellwig wrote:
That's what I meant with my comment btw. It's a horrible idea to
put in all the junk to support inferior OSes into gcc and all other
other programs, and with cygwin and djgpp there are already two nice
enviroments for that.
man xargs?
Andi Kleen wrote:
Mark Mitchell <[EMAIL PROTECTED]> writes:
I'm not sure what you're saying. The limitation on command-line
length can be in either the shell, or the OS. In Windows 2000, the
limitation comes primarily from the Windows command shell.
Linux has a similar limit which comes fr
On 8/25/05, Ashwin Kolhe <[EMAIL PROTECTED]> wrote:
> > You'll have something like this in your test
> >
> > operands[0] == operands[1] || peep2_regno_dead_p (2, operands[0])
> >
> > i.e. you only need to test for op0's death if it is different from op1.
> >
> > Paolo
> >
>
> Exactly.. this is the
GCC supports many proprietary systems and non-GNU systems, even
though that isn't the purpose of the GCC project according to the
mission statement. Not everyone is happy about that, but that's
just the way it is. IMHO if you're going to support proprietary
systems then you might as well try y
> You'll have something like this in your test
>
> operands[0] == operands[1] || peep2_regno_dead_p (2, operands[0])
>
> i.e. you only need to test for op0's death if it is different from op1.
>
> Paolo
>
Exactly.. this is the same thing as calling dead_or_set_p(insn,
operands[0]). If it can
On i386, GCC currently emits calls to libm math functions like f.i.
sin(). This pessimizes code a lot if we are using SSE math, as we need to
obey the standard i387 FP ABI. The sub-target specific math routines
library will provide a way to present different ABI math routines to GCC,
possibly
On Thu, 2005-08-25 12:49:16 +0200, Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Thursday 25 August 2005 12:45, Jan-Benedict Glaw wrote:
> > Linux uses 32 pages, which results in 128KB on 4K architecture (eg.
> > i386, m68k, sparc32, ...) or 256KB on 8K architectures (eg. Alpha,
> > UltraSparc, ...).
On Thursday 25 August 2005 12:45, Jan-Benedict Glaw wrote:
> Linux uses 32 pages, which results in 128KB on 4K architecture (eg.
> i386, m68k, sparc32, ...) or 256KB on 8K architectures (eg. Alpha,
> UltraSparc, ...).
Yes you're right. Somehow I only remembered the number 32.
Anyways, it's still
On Thu, 2005-08-25 12:31:34 +0200, Andi Kleen <[EMAIL PROTECTED]> wrote:
> Mark Mitchell <[EMAIL PROTECTED]> writes:
> > I'm not sure what you're saying. The limitation on command-line
> > length can be in either the shell, or the OS. In Windows 2000, the
> > limitation comes primarily from the W
On Wed, 2005-08-24 at 21:26 -0400, Daniel Berlin wrote:
> On Wed, 2005-08-24 at 19:19 -0400, Andrew MacLeod wrote:
> > removing a stmt doesn't mean that the def is no longer needed.
>
> That ws the goal of the extra argument, however
I noticed this after I sent the note :-). I didn't like the ex
I want GCC to work well for people, no matter what operating system they
are using. This is a feature that everyone who produces Windows-hosted
versions of GCC ends up implementing; I'd like to keep us all from
having to keep reinventing the wheel.
Indeed there's a quite old ve
Mark Mitchell <[EMAIL PROTECTED]> writes:
>
> I'm not sure what you're saying. The limitation on command-line
> length can be in either the shell, or the OS. In Windows 2000, the
> limitation comes primarily from the Windows command shell.
Linux has a similar limit which comes from the OS (norm
On Thursday 25 August 2005 07:12, Christoph Hellwig wrote:
> > On systems with small command-line buffers, this is a must-have
> > feature.
>
> Do you really want every application to work around a broken propritary
> system?
GCC supports many proprietary systems and non-GNU systems, even
though t
Ashwin wrote:
The problem in front of me is something like this..
op0 = 1
op1 = op0 leftshift op2
This will be optimized to
op1 = 1 leftshift op2 (by the peephole2 pass to the rtl pattern
corresponding to this and hence the requirement that op0 should be dead
after insn2)
However if the pat
The problem in front of me is something like this..
op0 = 1
op1 = op0 leftshift op2
The above is a part of the template to be matched, with one of the
conditions that op0 should be dead after the 2nd insn.
This will be optimized to
op1 = 1 leftshift op2 (by the peephole2 pass to the rtl patter
Christoph Hellwig wrote:
That's what I meant with my comment btw. It's a horrible idea to
put in all the junk to support inferior OSes into gcc and all other
other programs, and with cygwin and djgpp there are already two nice
enviroments for that. If Mark wants to duplicate that in MinGw that
I have met the same question. My solution to this is just to
remove ./config.cache in every sub-directories and try again. This
solution is effective although I am not sure about it. Anyone
could confirm or deny this.
I think "make distclean" should be done before ./configure if the
Jiang Long wrote:
Hello,
I am compiling GCC-4.0.1 with the following :
../gcc-4.0.1/configure --enable-tree-browser=yes
--prefix=/home/jiang/DEV/gcc-dev/trunk/install
--enable-languages=c,c++ --enable-maintainer-mode=yes
After a while I got the following errors with :
Adding multilib suppo
On Thu, Aug 25, 2005 at 01:29:05AM -0400, DJ Delorie wrote:
> It sounds like you're interested in MinGW. If you really wanted to
> help MinGW users, you'd fix MinGW so that it supported these the same
> way that DJGPP and Cygwin do, for *all* MinGW applications, not just
> gcc. I'd have to have t
On 8/25/05, Andrew Pinski <[EMAIL PROTECTED]> wrote:
> >
> > > In the last 24 hours, something has gone in which makes
> > > the GCJ interpreter "gij" abort on even simple "Hello World"
> > > classes. For example, the "RuntimeCheck" program in
> > > the Jacks testsuite:
> >
> > I had (probably) t
89 matches
Mail list logo
