Andrew Pinski wrote:
On Jun 5, 2005, at 1:41 PM, Devang Patel wrote:
On Jun 5, 2005, at 10:18 AM, Mark Mitchell wrote:
Here are three bugs I'd really like to see fixed.
* 21528: SRA and/or aliasing problem.
* 21847: DCE over-eagerness.
* 20928: IA32 ICE.
* 19523: [4.0/4.1 Regre
company, now, that we would have to drop it if
it were not maintained. That could be part of negotiating with them
to get a commitment of support.
We could also ask them whether they plan to provide support for GDB
and the binutils, or when they plan to release the manual so that
others can do so
Andrew Pinski wrote:
On Jun 5, 2005, at 2:01 PM, Mark Mitchell wrote:
I agree that these are both serious, though neither seems to rise to
the level of the KDE issues, in that these both affect "only"
debugging. PR 19523 affects only stabs, which I do not think is the
defa
t the GCC
bits with the actual FSF binutils bits. Our current internal versions
are based on GCC 3.3.2 and we have some ugly binutils hacks that are
being cleaned up as we push out to the FSF.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Diego Novillo wrote:
On Sun, Jun 05, 2005 at 10:18:05AM -0700, Mark Mitchell wrote:
* 21528: SRA and/or aliasing problem.
I'll take a look at this tomorrow.
Thanks!
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
e. Dan Jacobowitz and/or Nathan Sidwell and/or Phil
Edwards would be good choices.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
that I had a strong opinion up
front, and I really do think this ought to be up to you, but if that's
the conclusion you draw, that's certainly fine. You should certainly
feel free to ask MIPS for more information, if you need that to help
judge the contribution.
Thanks,
--
Mark M
s out, assuming all goes well.
Thanks,
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
ose the door on the code-generation bugs that are causing
us to do *this* release.
I plan to make the final release this weekend, unless major problems arise.
Thanks,
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Andrew Pinski wrote:
On Jun 8, 2005, at 12:57 PM, Mark Mitchell wrote:
The GCC 4.0.1 RC1 prerelease is available here:
ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.1-20050607/
Please test these tarballs, and let me know about showstoppers.
Can I revert a patch which I accidentally applied
4.0 soon, your patch would be
included automatically.
would be nice.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
eeing one of several problems...)
We're in a holding pattern (branch frozen) until we resolve these issues.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
assembler
if the user tries to use a 64-bit compiler with a 32-bit assembler.
OK?
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
2005-06-13 Mark Mitchell <[EMAIL PROTECTED]>
* config/i386/x86-64.h (ASM_SPEC): Explicitly pass --64 to the
assembler in 64-bit m
Daniel Jacobowitz wrote:
On Mon, Jun 13, 2005 at 12:56:36PM -0700, Richard Henderson wrote:
On Mon, Jun 13, 2005 at 11:16:04AM -0700, Mark Mitchell wrote:
1. For a bi-arch compiler for which 32-bit code is the default, we no
longer need to override ASM_SPEC.
Well, this is the only way
sion testing is good, and hugely useful --
but what makes it *really* valuable is having someone who comes in every
morning, looks at the output, and figures out who to blame, and, if
necessary, fixes the problem herself.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Scott Robert Ladd wrote:
That is exactly my point. Mark chastises people for talking about
testing, implying that we are lazy for not providing patches.
I don't deny that reality. Mark seems to feel that fixing bugs is as
easy as testing and bug reporting, and it is not.
Actually, I
4.0.0 as well?
Thanks,
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Joseph S. Myers wrote:
On Wed, 15 Jun 2005, Jakub Jelinek wrote:
On Tue, Jun 14, 2005 at 04:43:47PM -0700, Mark Mitchell wrote:
Right now, the libstdc++ versioning/ABI situation is is all that stands
between us and 4.0.1 RC2, now that Jakub has fixed the GLIBC miscompilation.
Weren'
omment in this thread so far has been that libm
might somehow rely on EP (ie can't use the _FPU_SET_CW workaround).
which code is this? I'd guess it might be related to using series
approximations, and the code could either set CW or accept 64b results.
regards, mark hahn.
Volker Reichelt wrote:
Hi Mark,
you wrote
Those who have been watching carefully will note that there is no sign of an
actual
4.0.1 release.
since the branch has been frozen for quite sime time now, a lot of patches
for the 4.0 branch have piled up.
Given the facts that
a) we'll
during the summit next week...
Thanks,
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
This version looks correct to me. Thanks!
Would you please comment on PR 22111? This is apparently a new
testsuite failure from the changes.
Thanks,
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
to talk to my advisor to see if he'd let me
continue working on it on my own and open source it, or if he is going
to release it at some point.
If you are interested, email me back off list and I'll talk to my advisor.
Mark Loeser
signature.asc
Description: OpenPGP digital signature
something like this for
mainline too?
This is OK, even for 4.0.1. It's also OK for mainline, and for 4.0.2,
if you don't get it checked in before 4.0.1.
Thanks,
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
;ll wander over to the summit, and see whose brains are available for
picking about these things.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Andrew Pinski wrote:
* PR 21985, in which we are mis-folding expressions involving pointer
arithmetic.
And this is fixed on the mainline already.
The same patch does fix the problem on the branch; I'm now running a
bootstrap/test cycle using that patch.
Thanks,
--
Mark Mit
From: Ben Elliston <[EMAIL PROTECTED]>
Date: Fri, 24 Jun 2005 23:50:58 +1000
For the second year in a row, about 30 people discussed removing the
replicated copies of the DejaGnu and Expect sources from the src
repository at the GCC Summit testing BOF.
The version of Expect in t
would not break with GCC, even though they
work with other compilers, seems likely to be high.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
7;ll build
RC3, and then, hopefully, a few days later, put out the final release.
I'm sorry this is dragging out, but I think it's worth getting this bug
fixed.
FYI,
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Jeffrey A Law wrote:
On Tue, 2005-06-28 at 00:20 -0700, Mark Mitchell wrote:
As stated earlier, the only patches I'm considering for 4.0.1 at present
are wrong-code cases on primary platforms. There are several open, but
the only one I consider a show-stopper is PR 22051, which Jeff L
piled well, and so don't think about this situation. In particular,
I often use unsigned types when the underlying quantity really is always
non-negative, and I'm saddened to learn that doing that would result in
inferior code.)
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Daniel Berlin wrote:
On Tue, 28 Jun 2005, Mark Mitchell wrote:
Joe Buck wrote:
I don't think we should give the user any such promise, and if we do
give such a promise, we will never catch icc. The main problem is that
we will no longer be able to optimize many loops.
It'
w this cycle,
but that's always the case; we'll leave some things for the next cycle.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Bryce McKinlay wrote:
Mark,
Could we get an exemption from the freeze rules for low-risk, runtime
only libgcj fixes as determined by the libgcj maintainers?
I don't think we want to do that.
First, we're close to a release. We've been waiting on one fix since
Friday, a
coming week.
I know that some of you have been frustruated by the delays, but they
have been in the service of fixing critical bugs. This is a volunteer
project, and some of our volunteers have a lot of things on their plates.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Zack Weinberg asked me to forward this to the GCC mailing list.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
--- Begin Message ---
I appear to have been too quick off the gun unsubscribing to the GCC
mailing lists; this message bounced. Would you please forward it
there
ines are
substantially more limited than the Solaris 8, 9 and 10 machines.
Hmph. I'm not going to worry about this too much, on the grounds that
Solaris 7 is pretty old now...
Thanks for the report!
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Ulrich Weigand wrote:
Mark Mitchell wrote:
GCC 4.0.1 RC3 is now available here:
ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.1-20050702/
With luck, this will be the last 4.0.1 release candidate.
Please do download tarballs from the above URL and confirm that they
work OK on your systems
uch a
function.)
I'm not sure why any declaration with dependent type is ever reaching
the middle end. That sounds like a problem to me, unless its purely in
the context of debugging information.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
if that doesn't already exist.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
not be caring
about DECL_SIZE on a PARM_DECL from a template. If it is, I'd like to
know where.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Paul Brook wrote:
On Sunday 03 July 2005 19:21, Mark Mitchell wrote:
GCC 4.0.1 RC3 is now available here:
ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.1-20050702/
With luck, this will be the last 4.0.1 release candidate.
Please do download tarballs from the above URL and confirm that they
Andreas Tobler wrote:
Darwin here:
http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00221.html
Thanks.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Kaz Kojima wrote:
Mark Mitchell <[EMAIL PROTECTED]> wrote:
GCC 4.0.1 RC3 is now available here:
ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.1-20050702/
With luck, this will be the last 4.0.1 release candidate.
Please do download tarballs from the above URL and confirm that they
work
ls libstdc++ install on powerpc64-linux
21551 ia64-unknown-linux-gnu ia64 bootstrap failed
I'm virtually certainly that 21523 was not present in 4.0.0. I'm not
sure about the other.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
, and GCC, in particular, transcend national
boundaries. National politics have no place here; in the context of
GCC, at least, we are all united in the common goal of building a great
compiler.
Please do not check in any similar comments in the future.
Thanks,
--
Mark Mitchell
CodeSourcery
Giovanni Bajo wrote:
Mark,
I have a simple C++ patch which I need to clean up for submission (it makes us
not print default arguments for template parameters in diagnostics, which is
much requested from the Boost community). It doesn't qualify for Stage 3
though, so I would like to know w
The release is in the gcc/gcc-4.0.1 subdirectory.
As usual, a vast number of people contributed to this release -- far too
many to thank by name!
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
for 6.75 hours from now, and
go ahead and update the web site.
Thanks!
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
possible that I just missed it.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
o this when the C++ front end is finished.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
ith my program so
that it's binary compatible with other distros... there must be a way. If
anyone has any tips or advice I'd appreciate it.
Thanks
Mark
Mark Cuss, B. Sc.
Real Time Systems Analyst
System Administrator
CDL Systems Ltd
Suite 230
3553 - 31 Street NW
Calgary, AB, Canada
Phone: 403 289 1733 ext 226
Fax: 403 289 3967
www.cdlsystems.com
self reference.
I think that's the right choice. The function type is no more
cv-qualified than any other function type; the only thing that's
cv-qualified is the type pointed to by the first argument.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
urgent; I hope bug affecting code
semantics for X is not just "request for enhancement".
Not for me to judge. That's why we have Mark.
For the record, I agree with what looks to have been the outcome of this
thread: that it makes sense to consider an object volatile iff the
Giovanni Bajo wrote:
Mark Mitchell <[EMAIL PROTECTED]> wrote:
The function type is no more
cv-qualified than any other function type; the only thing that's
cv-qualified is the type pointed to by the first argument.
The standard does not agree with you though, see 9.3.1/3.
It
INTER_TYPE pointing to a
METHOD_TYPE or member FUNCTION_TYPE. Such things should be replaced
with the RECORD_TYPEs we presently use to represent pointers to member
functions.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
nt end. For example, "(a.*b)()" gets turned
into various manipulations of low-level as soon as it is processed.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
x27;t have it yet, so RECORD_TYPEs are
going to continue be used to represent pointers-to-member functions for
some time.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
est of the
compiler; you should be able to (a) use configure to detect features of
your as/ld, (b) build the compiler, (c) install it, and, only then, (d)
start building libraries.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
iler out of the build directory, which causes all manner of
complication.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
doing OK. As this is
Stage 3, the focus is now on fixing bugs, and that's certainly what we
need to do. Stage 3 is scheduled to end September 8th. I think
that's going to end up slipping, unless we really start knocking down
bugs, but hopefully we can get close.
--
Mark Mitchell
CodeS
Andrew Pinski wrote:
On Jul 22, 2005, at 4:22 PM, Mark Mitchell wrote:
There are 225 regressions open against GCC 4.1. About half of these
(119) are not regressions in 4.0, i.e., they are new regressions
introduced in the course of 4.1. While it does seem that the
regression rate has
Andrew Pinski wrote:
On Jul 22, 2005, at 5:05 PM, Mark Mitchell wrote:
Andrew Pinski wrote:
On Jul 22, 2005, at 4:22 PM, Mark Mitchell wrote:
There are 225 regressions open against GCC 4.1. About half of these
(119) are not regressions in 4.0, i.e., they are new regressions
introduced in
Andrew Pinski wrote:
On Jul 22, 2005, at 5:08 PM, Mark Mitchell wrote:
Please! (Otherwise, I'm happy to do it myself.)
All done.
Thanks.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
x27;s customers doing scientific computing will be
rather pissed off.
Mark
the debug generator can work around that by skipping the type if it so
pleases.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
un-solaris2.9
--with-sysroot=/cdl/apps/.software/linux/gcc-3.4.4-x86-sparc-build/sysroot --with-gnu-as
--with-gnu-ld --prefix=/cdl/apps/.software/linux/gcc-3.4.4-x86-sparc
--enable-languages=c,c++Thread model: posixgcc version [EMAIL PROTECTED] helloworld]$ Thanks
Mark Mark Cuss, B. Sc. Real Time S
Gerald Pfeifer wrote:
On Fri, 22 Jul 2005, Mark Mitchell wrote:
We have been in Stage 3 for a little while now. I'm sure a few more
patches that were proposed in Stage 2 will find their way into 4.1,
but we're approximately feature-complete at this point.
I just committed the
hey'd work on any
distro.
#2 - I'd never heard of LSB or lsbcc... I've just done a google and turned
up an article on an IBM website on building binary-compatible Linux
applications... Thanks for the pointer on this one - it looks like this may
be the way to go.
Mark
--
ith the "Oh,
that app was built on RH 8 so it won't run on RH 7.3" problems, so I'm
trying to find a solution where I can configure my build system in such a
way that I can distribute a set of libraries with my applications to that it
will run on any distro - at least all of
Oh! I didn't know you could do that! Thanks very much!
Mark
- Original Message -
From: "Haren Visavadia" <[EMAIL PROTECTED]>
To: "Mark Cuss" <[EMAIL PROTECTED]>
Cc:
Sent: Tuesday, July 26, 2005 1:29 PM
Subject: Re: How to make an application l
efix/bin/sparc-sun-solaris-2.9-g++ can't - any ideas why this might be?
I've tried including the path to values-Xa.o with -L but that hasn't helped?
I'd really appreciate some pointers on this one.
Thanks in advance
Mark
- Original Message -
From: "Mark Cuss
t those don't
need any extra action at all.)
If you don't have cvs access to classpath on savannah, but would like to
and I you didn't get an email from me yet, please let me know.
Cheers,
Mark
--
Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-tra
4(next_byte(offset, bytecode)) << 8;
rtn |= uint64(next_byte(offset, bytecode));
return *reinterpret_cast(&rtn);
}
Full source code to a demonstration of the bug, and a Makefile is at
http://mjfrazer.org/~mjfrazer/tmp/pack-test/
The tar file in the directory contains all the other files, so you just
need to grab that.
cheers
-mark
Richard Guenther <[EMAIL PROTECTED]> [05/08/02 09:29]:
> Try -fno-strict-aliasing. This may be related to PR23192.
-fno-strict-aliasing does indeed make the problem go away.
thanks!
-mark
--
Forget your stupid theme park! I'm gonna make my own! With hookers! And
blackjack! In fa
Mark Frazer <[EMAIL PROTECTED]> [05/08/02 09:18]:
> Hello. I'm not on the list, so please CC me with any replies.
>
> I have come across a bug found during some code which serializes
> doubles. The bug is only encountered when the optimization level is set
> to -O2 or
Mark Frazer <[EMAIL PROTECTED]> [05/08/02 09:32]:
> Richard Guenther <[EMAIL PROTECTED]> [05/08/02 09:29]:
> > Try -fno-strict-aliasing. This may be related to PR23192.
>
> -fno-strict-aliasing does indeed make the problem go away.
changing the de-serialization
;ll poll the
Wiki for new projects, but I think people might appreciate mail to the
GCC mailing list when you add something.
See:
http://gcc.gnu.org/wiki/GCC%204.2%20Projects
for some guidelines.
Thanks,
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Giovanni Bajo wrote:
Mark,
- with your commit for PR 20142, you also committed a hunk to name-lookup.c
which is not described in the ChangeLog. It is also unclear whether it is
effectively need for that PR or not, but nonetheless it went in, so the entry
should probably be fixed
I wanted you
The SC doesn't want
to be involved in making such a list, or approving it; that should be
done by consensus of the maintainers. But, this conclusion should
remove the objection that "there is no official statement on this". You
should probably also mark the appropriate
Giovanni Bajo wrote:
Mark,
- with your commit for PR 20142, you also committed a hunk to name-lookup.c
which is not described in the ChangeLog. It is also unclear whether it is
effectively need for that PR or not, but nonetheless it went in, so the entry
should probably be fixed.
Thanks for
simple enough to be viable in
that timeframe. But, if Paolo can fix this without having to add #!, I
think that would be great.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Daniel Jacobowitz wrote:
On Wed, Aug 10, 2005 at 10:05:26AM -0700, Mark Mitchell wrote:
Christopher Faylor wrote:
This would conflict with my proposed changes to pex-win32.c . It seems
like getting '#!' functioning on mingw would be a better solution than
relying on $(LN) on min
loyal opposition; let's get on with
the fix you and DJ like. :-)
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Marcin Dalecki wrote:
On 2005-08-10, at 19:05, Mark Mitchell wrote:
The even more correct solution is to not build anything with the
compiler (including libgcc) until after it is installed. Then, it
will just look where it would normally look, and all will be well.
install host
Andreas Schwab wrote:
Mark Mitchell <[EMAIL PROTECTED]> writes:
The even more correct solution is to not build anything with the
compiler (including libgcc) until after it is installed. Then, it will
just look where it would normally look, and all will be well.
You sure don
ing on clean-ups and
new features -- and truly concentrate on fixing bugs. I don't want to
be draconian about that, but let's get the bugs fixed.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
Andrew Pinski wrote:
On Aug 22, 2005, at 1:27 AM, Mark Mitchell wrote:
(Quite a few of the diagnostic messages
stem from the design decision to issue warnings from the
optimizers...)
Only 8 out of 49 at that, though some are very minor as two are just
complaining wording of the warning
Ian Lance Taylor wrote:
Mark Mitchell <[EMAIL PROTECTED]> writes:
My first comment is that we had a lot of bugs targeted at 4.1.0 that
should never have been so targeted. Please remember that bugs that do
not effect primary or secondary targets should not have a target
milestone. The
DJ Delorie wrote:
This certainly wasn't my intention, please change it to 79L.
How's this? It passes both m32c and x86-64.
2005-08-23 DJ Delorie <[EMAIL PROTECTED]>
* gcc.c-torture/execute/stdarg-2.c (main): Make sure long
constants have the L suffix
4.2 opens?
Branches are for major work and a new pass is not that major.
It's also fine to create a new branch for this work. That let's other
people see what you're working on.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
ing XRESIZEVEC) that should be made before committing
to mainline.
And, as penance for posting new features in Stage 3, I'm committing to
fixing some C++ bugs before bedtime.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
2005-08-24 Mark Mitchell <[EMAIL PROTECTED]>
Christoph Hellwig wrote:
On Wed, Aug 24, 2005 at 09:50:32PM -0700, Mark Mitchell wrote:
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
c,
in practice.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
ss
command-line arguments, we'd be breaking things.
We have the same OS problem in almost every UNIX, to one degree or
another. Older UNIX variants certainly had this problem in spades. But
it's not a big deal to me if people don't want this for systems other
than MinGW, but
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 tha
of MinGW crt0 code that users could optionally select when they
want @-file behavior in an application. (Of course, we could do that
for shebang handling too.)
However, there's demonstrable interest in this feature for GNU/Linux as
well, from the lists, and for Java on all operating syste
;t experiment heavily enough.
If a condition for acceptance is making "@string" silently accepted if
"string" is not a file, for example, I'll happily implement that.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
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 proble
very late in the
game. We would have to factor out the code so that we could avoid the
buildargv behavior that creates a non-empty argv from an empty string,
but other than that it seems like we could just leverage the quoting
behavior that's already there.
Thanks,
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
401 - 500 of 1839 matches
Mail list logo
