On 9/24/2012 6:53 AM, Jerome Huck wrote:
from Mr Jerome Huck
Good morning.
I have been using the GCC suite on Windows, mainly in the various
Fortran. 77, 2003,... Thanks for those tools ! The Little Google Nexus 7
seems a wonderfull tool. I would like to know if we can expect a version
of GCC
On 10/10/2012 10:48 AM, Joseph S. Myers wrote:
On Wed, 10 Oct 2012, Gabor Loki wrote:
2) repeat all the compilation commands related to the previous list in
the proper environment. The only thing which I have added to the
compilation command is an extra -E option to preprocess every sources.
On 10/10/2012 4:16 PM, Joseph S. Myers wrote:
I'm not talking about the relation between the headings textually located
in a source file and the license of that source file. I'm talking about
the relation between the license of a .o file and the license of .h files
#included at several levels
confirm your
intepretation, but it's risky to rely on such opinions.
BTW, it is no surprise that you got no response from
licens...@fsf.org.
Robert Dewar
I'm pretty certain I have correctly interpreted GPL,v3. I have good
reasons to believe that. However, I'm willing to read your
interpretation of the GPL,v3, if you have any.
If you are certain enough, then you can of course proceed
on that assumption. I have no interest in giving my opinion
on
On 11/7/2012 8:17 AM, nk...@physics.auth.gr wrote:
I disagree.
I think you are wrong, however it is not really productive to express it.
I would not casually ignore Richard's opinion, he has FAR more
experience here than you do, and far more familiarity with
the issues involved.
On 11/7/2012 9:44 AM, nk...@physics.auth.gr wrote:
Quoting Richard Kenner ken...@vlsi1.ultra.nyu.edu:
There are not many lawyers in Greece that deal with open-source licenses.
The legal issue here has nothing whatsoever to do with open-source
licenses: the exact same issue comes up with
On 11/7/2012 11:08 AM, Richard Kenner wrote:
Correct. A court of competent jurisdiction can decide whether your scheme
conforms to the relevant licenses; neither licens...@fsf.org nor the
people on this list can.
A minor correction: licens...@fsf.org *could* determine that since they are
the
For me the most annoying thing about HTML burdened emails
is idiots who choose totally inappropriate fonts, that make
their stuff really hard to read. I choose a font for plain
text emails that is just right on my screen etc. I do NOT
want it overridden. And as for people who use color etc,
well
2) The fact that Android refuses to provide a non-HTML e-mail capability
is ridiculous but does not seem to me to be a reason for us to change
our policy.
Surely there are altenrative email client for Android that have plain
text capability???
On 11/24/2012 12:59 PM, Daniel Berlin wrote:
On Sat, Nov 24, 2012 at 12:47 PM, Robert Dewar de...@adacore.com wrote:
2) The fact that Android refuses to provide a non-HTML e-mail capability
is ridiculous but does not seem to me to be a reason for us to change
our policy.
Surely
On 11/24/2012 1:13 PM, Jonathan Wakely wrote:
The official gmail app, which obviously integrates well with gmail and
is good in most other ways, won't send non-html mails.
There seem to be a variety of alternatives
On 12/12/2012 1:01 PM, Steven Bosscher wrote:
Hello,
Linux support for i386 has been removed. Should we do the same for GCC?
The oldest ix86 variant that'd be supported would be i486.
Are there any embedded chips that still use the 386 instruction set?
On 12/12/2012 2:52 PM, Steven Bosscher wrote:
And as usual: If you use an almost 30 years old architecture, why
would you need the latest-and-greatest compiler technology?
Seriously...
Well the embedded folk often end up with precisely this dichotomy :-)
But if no sign of 386 embedded chips,
Intel stopped producing embedded 386 chips in 2007.
Right, but this architecture is not protected, so the
question is whether there are other vendors producing
compatible chips. I don't know the answer.
On 12/13/2012 7:26 AM, Steven Bosscher wrote:
Ralf has found one such a vendor, it seems.
But to me, that doesn't automatically imply that GCC must continue to
support such a target. Other criteria should also be considered. For
instance, quality of implementation and maintenance burden.
On 12/14/2012 3:13 PM, Cynthia Rempel wrote:
Hi,
RTEMS still supports the i386, and there are many i386 machines still
in use. Deprecating the i386 will negatively impact RTEMS ability to
support the i386. As Steven Bosscher said, the benefits are small,
and the impact would be serious for
Having read this whole thread, Ivote for deprecating the 386.
People using this ancient architecture can perfectly well use
older versions of gcc that have this support.
On 12/15/2012 12:42 AM, Ralf Corsepius wrote:
If you want a port to be live show that it is live by posting regular
testresults to gcc-testresults.
Not all of this world is Linux nor backed by large teams at
companies :) We simply do not have the resources do to this.
But that's the
On 12/15/2012 12:32 PM, Cynthia Rempel wrote:
Hi,
Thanks for the fast response!
So to keep an architecture supported by GCC, we would need to:
Three or more times a year preferably either during OR after
stage3
1. use the SVN version of gcc, 2. patch with an RTEMS patch, 3. use
On 1/2/2013 12:26 PM, Jeff Law wrote:
Any thoughts on doing something similar?
I've always found lazily updating the copyright years to be error prone.
If we could just update all of them now, which is OK according to the
FSF guidelines we could avoid one class of problems.
For GNAT at
On 1/16/2013 6:54 AM, Mischa Baars wrote:
]
And indeed apparently the answer then is '2'. However, I don't think
this is correct. If that means that there is an error in the C
specification, then there probably is an error in the specification.
The C specification seems perfectly reasonable to
On 1/16/2013 7:10 AM, Mischa Baars wrote:
And as I have said before: if you are satisfied with the answer '2',
then so be it and you keep the compiler the way it is, personally I'm am
not able to accept changes to the sources anyway. I don't think it is
the right answer though.
The fact that
About the time Clang does because GCC now has to compete.
How about that? Clang is currently slightly ahead and GCC really needs
to change if it is to continue to be the best.
Best is measured by many metrics, and it is unrealistic to expect
any product to be best in all respects.
Anyway, it
On 1/24/2013 9:10 AM, Alec Teal wrote:
Alec I am eager to see what you guys think, this is a 'feature' I've
wanted for a long time and you all seem approachable rather than the
distant compiler gods I expected.
I certainly see the point of this proposal, indeed introducing
this kind of strong
On 1/24/2013 10:02 AM, Jeffrey Walton wrote:
What I am not clear about is when an operation is deemed undefined
or implementation defined.
The compiler is free to assume that no arithmetic operation
on signed integers results in overflow. It is allowed to
take advantage of such assumptions in
On 1/24/2013 10:33 AM, Jeffrey Walton wrote:
In this case, I claim we must perform the operation. Its the result
that we can't use under some circumstances (namely, overflow or wrap).
You do not have to do the operation if the program has an
overflow. The compiler can reason about this, so
On 1/28/2013 6:48 AM, Alec Teal wrote:
On 28/01/13 10:41, Jonathan Wakely wrote:
On 28 January 2013 06:18, Alec Teal wrote:
the very
nature of just putting the word hard before a typedef is something I find
appealing
I've already explained why that's not likely to be acceptable, because
Forgive me, but I don't see where anything is guaranteed to be zero'd
before use. I'm likely wrong somewhere since you disagree.
http://en.wikipedia.org/wiki/.bss
This is about what happens to work, and specifically notes that it is
not part of the C standard. There is a big difference
Wrong. It specifies that objects with static storage duration that
aren't explicitely initialized are initialized with null pointers, or
zeros depending on type. 6.7.8.10.
OK, that means that the comments of my last mesage don't apply to
variables of this type. So they should at least
On 5/11/2013 5:42 AM, jacob navia wrote:
1) The fsin instruction is ONE instruction! The sin routine is (at
least) thousand instructions!
Even if the fsin instruction itself is slow it should be thousand
times faster than the
complicated routine gcc calls.
2) The FPU is at 64 bits
As 1) only way is measure that. Compile following an we will see who is
rigth.
Right, probably you should have done that before posting
anything! (I leave the experiment up to you!)
cat
#include math.h
int main(){ int i;
double x=0;
double ret=0;
double f;
On 5/11/2013 10:46 AM, Robert Dewar wrote:
As 1) only way is measure that. Compile following an we will see who is
rigth.
Right, probably you should have done that before posting
anything! (I leave the experiment up to you!)
And of course this experiment says nothing about accuracy!
. Certainly
you have to be a floating-point expert to even touch it!
Robert Dewar
Erik Trulsson wrote:
Ken Thompson (one of the original creators of Unix) *did* put such a hack into
their C compiler which would automatically add backdoor code when it
compiled the 'login' program. This was many years ago and AFAIK the hacked
Unix version was never released into the wild.
Erik Trulsson wrote:
And reading Ken's ACM paper (http://www.acm.org/classics/sep95/) certainly
gives me the impression that he is talking about a real program, not just a
purely hypothetical case:
[...]
I would like to present to you the cutest program I ever wrote. I
will do this in
Alinabi wrote:
Subject: sub-optimal code for packed boolean arrays in Ada -- bug or
inherent limitation
Certainly not a bug, the code generated is correct, it is just not
optimal. Surely it could be fixed if someone had the energy to do so.
I see no particular gain in filing a bug report, it
Richard Kenner wrote:
Will gcc add the optimization support in the future (method 1)?
Since GCC is a volunteer project, the answer for any sort of question
like that is if somebody writes it, it'll exist and if they don't, it
won't. There's no good way to predict what projects people will
Serge Belyshev wrote:
Personally, I think that bumping version number is the worst possible solution
of all proposed.
To me it seems essential to change the version number when changing the
license. Technical compiler folk may not regard the license change as a
significant one, but for the
Alexandre Oliva wrote:
Anyone who had their heads in the sand for the past 18 months when
GPLv3 was being publicly discussed and developed, or wasn't at the GCC
Summit last year when I mentioned that the FSF would most certainly
want to upgrade the license of every project whose copyright it
Nicholas Nethercote wrote:
One way to view it: the license is a feature. Therefore changing the
license is changing a feature. Therefore what was going to be 4.2.2 should
become 4.3.0.
I certainly agree that the license is a feature, and a pretty
important one for many users.
Michael Eager wrote:
Saying that license is an interoperability issue doesn't make it one.
No, saying that is not what makes it so, that's true.
However, the fact is that licensing *is* an interoperability issue,
since it has to do with what units can be mixed together in a
particular
Michael Eager wrote:
Unfortunately, as I understand it, this is not the case. If you
apply a GPLv3 patch to a previously GPLv2 branch after August 1, then
this entire branch, and all files in it, magically and silently
becomes GPLv3. (This is unless FSF agrees with Mark's proposal
to dual
Brooks Moses wrote:
Robert Dewar wrote:
One could of course just take a blanket view that everything
on the site is, as of a certain moment, licensed under GPLv3
(note you don't have to change file headers to achieve this,
the file headers have no particular legal significance in
any case
Richard Kenner wrote:
At what point in this process, and by what mechanism, does a patch become a
GPLv2 patch or a GPLv3 patch. I'd argue that the patch itself has no
such status at all: as of the time it's posted, its copyright is owned by
the FSF, but that's all that's happened. The
Richard Kenner wrote:
Actually the whole notion of violating a license is a confused one. The
violation is of the copyright, the license merely gives some cases in
which copying is allowed. If you copy outside the license you have not
violated the license, you have simply infringed the
Richard Kenner wrote:
Actually the whole notion of violating a license is a confused one. The
violation is of the copyright, the license merely gives some cases in
which copying is allowed. If you copy outside the license you have not
violated the license, you have simply infringed the
Richard Kenner wrote:
Actually, this is a good point. While the FSF may declare that all
patches after Aug 1 are GPLv3, unless they take affirmative action
to assert the copyright and license, courts may determine that they
waive rights under these. Especially if a reasonable person would
Sunzir Deepur wrote:
hi list,
is there a meaning for control flow graphs of assembly files (.S)
(e.g. those that are emitted using -fdump-rtl-*) ?
if not - then how are assembly file being optimized ? I guess
that assembly files can be made more efficient by many of gcc's
optimizations too,
Patrick Flannery wrote:
Any suggestions or pointers to related work would be much appreciated.
The GNAT front end generates the kind of information you are suggesting
for Ada (see format of ali files), and GPS has a refactoring tool that
makes use of this information, so that might be one
Sunzir Deepur wrote:
On 7/22/07, Robert Dewar [EMAIL PROTECTED] wrote:
Sunzir Deepur wrote:
is there a meaning for control flow graphs of assembly files (.S)
(e.g. those that are emitted using -fdump-rtl-*) ?
this is neither possible nor desirable.
Ok. but is there a way to produce CFG
Ben Elliston wrote:
On Tue, 2007-07-24 at 10:48 +0100, Manuel López-Ibáñez wrote:
GCC is thoroughly tested. None the less, there is always room for
improvement, so if you have time to implement your ideas or write
documentation, you are welcome to contribute.
If you build the compiler
Joe Buck wrote:
Right. However, some coverage-oriented methodologies explicitly mark code
that is expected to be unreachable, and produce unit tests to exercise at
least some of the defensive code that no longer gets run by the compiler
as a whole. If any volunteers would like to take on the
Laurent GUERBY wrote:
On Thu, 2007-07-26 at 17:13 -0400, Diego Novillo wrote:
Or maybe this is not a good idea, but I have certainly seen some folks
that complain about our less than friendly practices.
Alternative would be to keep gcc@ and document that
emails with subject tag [BEGINNER]
Ronny Peine wrote:
Hi,
my questions is, why not use the element construction algorithm? The Thomson
Algorithm creates an epsilon-NFA which needs quite a lot of memory. The
element construction creates an NFA directly and therefor has fewer states.
Well, this is only interesting in the
Ian Lance Taylor wrote:
It's fairly difficult. You want a way to turn off specific warnings
for specific parts of the IR. The IR is combined and rearranged
during optimization, so you need to figure out how to make the warning
control track those changes.
A simpler approach, used in the
DJ Delorie wrote:
Ian Lance Taylor [EMAIL PROTECTED] writes:
Let's do that.
We've already talked about keeping track of the source location of
each #pragma, and searching them for the state at a given line. The
diagnostic machinery seems to be able to tell what file/line each
diagnostic is
Andrew Walrond wrote:
Michael Meissner wrote:
We have performance results that show GCC now delivers outstanding performance
on AMD's Quad-core Barcelona processors. We've just posted our SPECint results
tests with GCC 4.1.2 on AMD's Quad-core Barcelona processors. We just want to
thank all
Daniel, Michael J wrote:
Hi!
I'm interested in static stack analysis tools.
Either using someone else's or creating.
Where would I find existing tools?
Where would I find existing contracter software developers?
michael
AdaCore has a tool called gnatstack. Check with AdaCore
for details.
Erik Trulsson wrote:
It is also worth noting that just declaring a variable 'volatile' does not
help all that much in making it safer to use in a threded environment if you
have multiple CPUs. (There is nothing that says that a multi-CPU system has
to have any kind of automatic
skaller wrote:
I think this is the wrong idea. Deprecated does carry a lot
of weight. It allows a new compiler without a legacy
to elide the feature and specify it is ISO compliant
'minus' the deprecated features, which is quite different
from 'non-compliant'.
are you sure? I thought
Andrew Haley wrote:
Hmmm. This is an interesting idea, but it sounds to me as though it's
somewhat at variance with what is proposed by the C++ threads working
group. In any case, gcc will certainly implement whatever the
standards committees come up with, but that is probably two years
away.
skaller wrote:
So I am guessing the Felix version is lucky there are
no gratuitous temporaries to be saved when this happens,
and the C code is unlucky and there are.
Maybe someone who knows how the optimiser works can comment?
One problem with departing from the ABI even on a local level
David Daney wrote:
They did use pthreads though. Code correctness in this case does not
depend on the number of processor cores.
True, but in practice real multiprocessing shows up such bugs
more often ...
David Daney
skaller wrote:
On Fri, 2007-10-26 at 20:26 -0400, Robert Dewar wrote:
skaller wrote:
So I am guessing the Felix version is lucky there are
no gratuitous temporaries to be saved when this happens,
and the C code is unlucky and there are.
Maybe someone who knows how the optimiser works can
Samuel Tardieu wrote:
On 26/10, Robert Dewar wrote:
| Of course in Ada there is a clear notion of threads semantic, and
| a clear definition of what the meaning of code is in the presence
| of threads, so the specific situation discussed here is easy to
| deal with (though Ada takes the view
Florian Weimer wrote:
* Robert Dewar:
In the following example, is the access to Shared considered
unsynchronized even though what looks like a proper lock is used
around it?
Yes, it is unsynchronized. Why would you think otherwise?
The signaling rules are dynamic, not static. Only
Bart Van Assche wrote:
My opinion is that, given the importance of multithreading, it should
be documented in the gcc manual which optimizations can cause trouble
in multithreaded software (such as (3) and (4)). It should also be
documented which compiler flags must be used to disable
Erik Trulsson wrote:
Unfortunately it seems that the POSIX standard for threads say that as long
as access to a shared variable is protected by a mutex there is no need to
use 'volatile'.
How does it say this, in some semantically precise way, or with hand
waving as in this sentence.
This
Darryl Miles wrote:
This then leads into the question. Is a pointer allowed to be invalid.
I'm sure I have read a comment on this before, along the line of the
spec says it must be valid or a certain number of other values (like
zero or one past being valid). But I can not cite chapter and
Michael Matz wrote:
Hi,
On Mon, 29 Oct 2007, Robert Dewar wrote:
One thing that seems missing from this thread is any quantitative
analysis of the value of this optimization.
Please read my mails carefully.
Well perhaps some emails got lost, but to be clear what I am looking
for is actual
Michael Matz wrote:
456.hmmer is not a small benchmark, but a real world scientific
application for protein sequence analysis using hidden markov models. It
just so happens that it also is a standardized benchmark in cpu2006.
A single data point is not data in the sense I refer to. What you
Joe Buck wrote:
From: Dave Korn [EMAIL PROTECTED]
Better write your own compiler then.
On Sun, Oct 28, 2007 at 06:34:01PM -0700, David Miller wrote:
If this becomes the common attitude of GCC developers, you can pretty
much guarentee this will drive people to work on LLVM and other
Andi Kleen wrote:
Robert Dewar [EMAIL PROTECTED] writes:
a) the standard allows the optimization (or rather does not forbid it)
Assuming it is an optimization. See
http://gcc.gnu.org/ml/gcc/2007-10/msg00607.html
for a counter example. In general cache misses are so costly that anything
skaller wrote:
On Mon, 2007-10-29 at 21:03 +0100, Andi Kleen wrote:
On Mon, Oct 29, 2007 at 03:51:27PM -0400, Robert Dewar wrote:
Sure, well nearly every optimization has some case where it is a
pessimization (one interesting thing that happens is that if you
change the length of generated
Andi Kleen wrote:
On Mon, Oct 29, 2007 at 03:51:27PM -0400, Robert Dewar wrote:
Sure, well nearly every optimization has some case where it is a
pessimization (one interesting thing that happens is that if you
change the length of generated code in *any* way you may be unlucky
and cause
Robert Dewar wrote:
Yes, of course! unrolling loops is often an overall loss
Note also that excessive inlining often is a loss due to
increase in icache pressure. In Ada it is the style to
carefully mark inlinable routines with pragma Inline, and
we often find in Ada that use of -O3, which
Olivier Galibert wrote:
On Sat, Nov 03, 2007 at 03:38:51AM +1100, skaller wrote:
My argument is basically: there is no need for any such
feature in a well written program. Each thread already has
its own local stack. Global variables should not be used
in the first place (except for signals etc
skaller wrote:
This is not true. If you use a register for any purpose like this,
it can't be used for anything else and that has a cost.
On x86_64 which I use, every register is valuable. Don't you dare
take one away, it would have a serious performance impact AND
it would stop ME using that
Jack Howarth wrote:
Is an external copy of GNAT really required to build the
ada language in gcc trunk? On powerpc-apple-darwin9, I am
seeing configure fail with...
configure: error: GNAT is required to build ada
...when ada is added to the language set. Certainly
this isn't the desired
David Miller wrote:
But we don't need a fortran compiler to compile the gfortran compiler,
and we don't need a c++ compiler to compile the g++ compiler, and we
don't even need a java compiler to compile the gcj compiler.
That's because they are written in C
Sorry, I just couldn't resist.
David Miller wrote:
The trick is to have a program that, even if massively suboptimal, can
compile ADA code for the purposes of bootstrapping the ADA compiler
and is written in C.
No trick here, Ada is a complex language and even a simple Ada
compiler that you envision is a huge amount of
Robert Dewar wrote:
No trick here, Ada is a complex language and even a simple Ada
compiler that you envision is a huge amount of work, but if you
feel it is practical, by all means go ahead and create such a beast!
By the way, early on we thought quite a bit about how to bootstrap
from C
Li Wang wrote:
Hi,
I wonder if any efforts have been made to retarget GCC to VLIW
backend.Is there any project trying to do that? Is it included in the
GCC mainstream? Thanks.
the ia64 is a VLIW architecture!
Regards,
Li Wang
David Edelsohn wrote:
Dave Korn writes:
Dave I don't understand: why wouldn't designing it so that they have to be
Dave implemented as DSOs and hence are covered by the
Dave anything-directly-linked-in-is-GPL'd clause do the job? Or is the concern
Dave that people will write trivial
Tom Tromey wrote:
First, aren't we already in this situation? There are at least 2
compilers out there that re-use parts of GCC by serializing trees and
then reading them into a different back end.
It's not obvious to me that this is consistent with the GPL ..
interesting issue ...
Second,
Brendon Costa wrote:
The concern is the many forms of shim layers that possibly could
be written more easily with a plug-in framework.
there is also a difference in these two scenarios:
1. a) Company X writes a modification to GCC to generate special
intermediate stuff with format Y.
b)
Brendon Costa wrote:
The patch against GCC is GPL, the main library that is capable of
manipulating the data exported by the patched GCC is LGPL and could
theoretically be under any license.
Whose theory? You don't know that!
What i was trying to point out is that proprietary projects can
Florian Weimer wrote:
* Robert Dewar:
Tom Tromey wrote:
First, aren't we already in this situation? There are at least 2
compilers out there that re-use parts of GCC by serializing trees and
then reading them into a different back end.
It's not obvious to me that this is consistent
My general feelings on this subject:
1. I don't think we should care much about the ability to
*SET* values of variables in optimized code. You can
definitely do without that. So if a variable exists in
two places, no problem, just register one of them.
2. It is much more important to have
Alexandre Oliva wrote:
On Nov 8, 2007, Robert Dewar [EMAIL PROTECTED] wrote:
My general feelings on this subject:
1. I don't think we should care much about the ability to
*SET* values of variables in optimized code.
Indeed. We should care about correctness of debug information
Ian Lance Taylor wrote:
Alexandre Oliva [EMAIL PROTECTED] writes:
So... The compiler is outputting code that tells other tools where to
look for certain variables at run time, but it's putting incorrect
information there. How can you possibly argue that this is not a code
correctness issue?
Andrew Pinski wrote:
I have to ask, do you want an optimizing compiler or one which
generates full debugging information
Both!
I would like modes which do the following
a) reasonable amount of optimization that does not intefere too much
with debugging. The old GCC 3 -O1 was a close
Seongbae Park (¹Ú¼º¹è, ÚÓà÷ÛÆ) wrote:
Most people
fall in this camp
and this is what gcc has implemented. This camp doesn't want to change the code
so that they can get better debugging information.
This is definitely not the case. At least among our users, very few fall
into this camp. But in
Daniel Jacobowitz wrote:
Careful. Eliminating reads from memory messes up debugger
modification of variables, unless you can explain to the debugger that
the variable is currently in both locations - this has been discussed
but AFAIK there is no representation for it yet. Changing the memory
Diego Novillo wrote:
No, this argument is fallacious. Plug-ins and poor documentation are
not, and should not be related. Poor documentation is an orthogonal
problem which ALSO needs to be addressed.
Actually to me if you have plug-ins, good documentation of the plug-in
interface is
Gabriel Dos Reis wrote:
Robert Dewar [EMAIL PROTECTED] writes:
| It's interestinng to note that in the Ada world, there is an ISO
| standard for plugins, which is compiler/vendor neutral (at least
| in theory, in practice there are some implementation dependencies).
| That's the ASIS interface
Richard Kenner wrote:
Robert Dewar [EMAIL PROTECTED] writes:
| It's interestinng to note that in the Ada world, there is an ISO
| standard for plugins, which is compiler/vendor neutral (at least
| in theory, in practice there are some implementation dependencies).
| That's the ASIS interface
Richard Kenner wrote:
So I am not sure I understand Richard's points above, so let me be clear
about what ASIS is.
It is a set of libraries, and a well defined API, that allows generic
tools to be written that have full access to the semantic information
discovered by the compiler. This API is
Richard Guenther wrote:
On Nov 22, 2007 8:22 PM, Frank Ch. Eigler [EMAIL PROTECTED] wrote:
Mark Mitchell [EMAIL PROTECTED] writes:
[...]
Who is we? What better debugging are GCC users demanding? What
debugging difficulties are they experiencing? Who is that set of users?
What
1 - 100 of 990 matches
Mail list logo
