eing asked by people who
will apparently be unable to participate. We'll try to answer those as
breaks in the conversation occur.
Thanks,
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
that what the FSF wants?
That last consideration, of course, does not apply to not-FSF GCC, e.g.,
to a release that Basile does himself.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
y agree that it would be nice to eliminate macros.
Yes, the (informally agreed) policy is to have hooks, not macros. There
may be situations where that is technically impossible, but I'd expect
those to be very rare.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
, but you'd be able to dual-license the code in the
plug-in if you chose to do that.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
er decisions from the FSF
on licensing issues, I have none. I've worked on several such issues
with the FSF over the years, and they've all been lengthy processes. If
I knew how to do it faster, I certainly would. The best way to work
with the FSF on license issues is always to expla
_SPACE_KEYWORDS.
>
> * config/spu/spu.h (TARGET_ADDR_SPACE_KEYWORDS): Remove.
> (REGISTER_TARGET_PRAGMAS): Call c_register_addr_space.
>
> * doc/tm.texi (Named Address Spaces): Mention c_register_addr_space.
> Remove TARGET_ADDR_SPACE_KEYWORDS.
OK.
understand the full situation with MELT. But, you cannot
combine GPL'd and GFDL's stuff, so I don't think you can auto-generate
GFDL documentation from GPL'd code on the MELT branch. You could
generate GPL'd documentation, though.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
further the
interests of the FSF (and, in fact, I've argued to RMS that at least in
the context of GCC it would do so), but I don't think any of us have the
right to do that without the FSF's permission.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
ves the quality of the product -- but I can't argue that
this is true for the manual pages.
But, if we could get the documentation for command-line options into
GPL'd code in a structured way, then I think you could probably generate
GPL'd manual pages from that.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
trying to focus on use of the
GPL'd code in GFDL manuals and vice versa, particularly in the context
of GCC's manuals, as a way of reducing developer effort and improving
the documentation.
Thanks,
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
strictly; for
example, we might forbid use of virtual functions, or multiple
inheritance, or overloading. But, we'll take advantage of some obvious
benefits, like use of std::vector in lieu of VEC.h.
I will report further once the SC discussion has reached a conclusion.
--
Mark Mitchell
uld urge the rest of us not to spend too much time in the C++
coding-standards bikeshed; we're not going to win or lose too much
because we do or do not permit default parameters.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
Eric Botcazou wrote:
>> We do require long long for 32->64 cross compilers.
>
> Right, only in this case, and I don't see why this should be changed with the
> transition to C++, that's orthogonal.
I agree.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
s natural to use actual C++ inheritance there. But, there's no a
priori reason to start making other things inherit from each other or
start trying to factor out base classes that we don't currently have,
unless it's actually demonstrably useful to do so.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
e willing to use. Step 2 is
for someone to propose a C++-using patch that does something useful and
get it approved. So far, I've seen a lot of input on Step 1, but nobody
that wants to step up and take responsibility for the task. Any takers?
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
help, of
course.) I would expect that this delta will be quite small in the
scope of a complete compiler bootstrap, especially if you include
building libstdc++ and/or libjava.
As usual, we won't know for sure until we measure.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
than more. We have C code that works, and we have a group of
developers comfortable in C. We lose if we break our code, and even
more if alienate those developers.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
existing C codebase, and we have a developer team made up of experienced
C programmers, not all of whom are used to programming in C++. So, we
need to take those factors into account.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
olks want to use C in the
Fortran front-end, then -- except to the extent required by the common
interfaces, those files could read as if they were C code. But, I think
they'd still need to be compiled with a C++ compiler because they'll
probably pull in headers that use C++ constructs.
of the initial set of
coding guidelines. I would, however, expect that they will be one of
the first advanced features to make their way into GCC in the future.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
hat's where we get
maximum bang from allowing use of C++, but it could certainly be done.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
e used to
implement all of GCC, including front-ends, back-ends, and common code.
Where we currently use C, we wish to instead use C++.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
o how the FSF wants to deal with the code
it owns, however, is not obvious to me.
I have asked RMS to clarify.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
e.)
> I would even imagine that later, one could configure GCC to have only a
> C++ front-end, but no more a C one.
I suppose, though thinking about that doesn't seem a great use of time
at this point.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
e data structures, thereby avoiding casts up and
down the hierarchy. Including, for example, declaring a routine that's
supposed to take a DECL as taking a tree_decl&, instead of just a tree *.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
uld you like to receive
comments? Directly on the Wiki page, or by email?
Thanks,
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
ly confused by the VEC APIs, for example; using std::vector
seems much better. And, using those kinds of things doesn't require a
lot of knowledge of C++ arcana, even if the implementations may use some
of that arcana.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
MS.
(An obvious strategy generate these manuals under the GPL, rather than
the GFDL, thereby dodging the issue. But, RMS does not want GCC having
GPL'd manuals. Maybe if we show him what we want to do, he will
conclude that GPL'd manuals are an acceptable outcome, and easier than
trying to do license exceptions.)
Thanks,
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
eps and provide the inputs
and outputs of the process for some of these issues? I want to able to
show RMS an actual input file, an actual output file, and describe the
transformation process that leads from one to the other.
Thanks,
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
ly with RMS.)
Because this scheme depends not on a general license exception, but
rather on particular power that the FSF has by virtue of owning the
code, the ultimate downstream recipient cannot be guaranteed that they
can rebuild the documentation.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
ibuting* those regenerated docs.
Indeed; I was too casual in my description. Dave can regenerate the
docs, and even pass them around his company, but he can't distribute them.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
t sections and such as are on the existing manuals.
(If it were up to me, manuals would just be GPL, whether or not that's a
great license for documentation. But, it's not up to me.)
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
assign code to them in part precisely so that it can change the licenses
at will. I think RMS does recognize that this issue for distributors is
a problem in this situation, though. He also doesn't feel that he can
get a license exception very quickly, though, if at all.)
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
t.) So, anyhow, it looks
to me as if current consensus is trending in the direction you suggest...
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
to generate GFDL'd documentation, including the right for
downstream recipients to regenerate the documentation, will take a long
time. I'm disappointed to see these "islands" (GPLv2 vs. GPLv3 vs.
GFDL) of code and documentation that cannot be combined, but that seems
to be the
ake "a + b" be
arbitrarily complex if "a" and "b" are instances of class types and you
have overloaded "+". But, if you just recompile your C program as C++,
it doesn't suddenly get significantly bigger or slower.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
"+".
>>
> And, in general, we are trying to avoid situations where seemingly
> simple code does something expensive, right?
Right.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
ith GPL code
"extern int foo" is not something that is going to be covered by
copyright; there's no expression in something like that. I don't think
anybody should be worried.
Thanks,
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
nerates cross-reference information. I think you can
reasonably distinguish the kind of thing that comes out of JavaDoc or
Doxygen from a manual. If you don't know what kind of output JavaDoc
and Doxygen produce, please go read about them for a while and look at
some examples.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
; http://gcc.gnu.org/wiki/MELT%20tutorial?action=AttachFile&do=view&target=GCC-MELT--gcc-internals-snapshot.pdf
That contains much more than cross-reference documentation!
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
meaningful RTL), and we don't know that it
doesn't work, it's reasonable to put this into GCC, changing the
documentation to specify the semantics of this form of RTL, and then
fixing any bugs as they occur.
Thanks,
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
; and names. With the bodies of the descriptions of the semantics of the
> hooks (in .texi or comments), yes, but not with the names and types of
> hooks and their arguments.
I agree. Joern, I don't think anything in the ChangeLogs that you are
writing is going to be a
r policy is that we can't remove it.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
n instead. (We'd also give
up any ability to relicense code going forward (e.g., between GPL and
GFDL) since we'd likely have many copyright holders, and no practical
hope of getting them all to agree on any change.) But, as long as we do
want to be an FSF project, we have to play by the FS
tart to build interesting
static-checking tools, including, for example, domain-specific tools
that could check requirements of the Linux kernel. This would be a
powerful and exciting feature to have in GCC.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
the time. I think we should allow some judgment, and, as you say, we
should provide transparency with respect to which testing was done.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
ht now is actively
working on improving the plug-in API in the way that I suggested. So,
yes, I would be happy if someone would like to work on that and to
contribute patches. I will volunteer to help review patches that move
in this direction.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
ch to reflect that change.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
? htdocs/.#cvs.html.1.178
? htdocs/cvs.html.~1.178.~
? htdocs/develop.html.~1.62.~
? htdocs/index.html.~1.538.~
Index: htdocs/gcc-4.6/criteria
that depends on the toolchain triplet to
determine ABI is inherently busted is pretty persuasive.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
adly from this problem. Deriving ABI
behavior from triplets is a problem that's caused brokenness for
multilib'd toolchains in various packages.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
FSF policy point
of view.
2. Can we move GPL'd code into GFDL'd manuals, or copy text from GFDL's
manuals into GPL'd code, or auto-generated GFDL's manuals from GPL'd code?
This got complicated; see previous postings. But, it's not relevant to
your question, since you're not trying to do that.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
relicense manuals under the GPL, or (b) for the FSF to add an
exception to the GFDL, making it compatible with the GPL in some way.
However, I have no evidence that the FSF is considering either of these
ideas; RMS didn't provide encouraging feedback when I made such suggestions.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
ual, from GPL'd source
code. If the FSF's policy of using the GFDL on manuals means that we
can't have as good a user's manual as we would otherwise, then --
whatever its purported benefits -- the GFDL is not serving us well, and
we should continue making that case to the FSF.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
e a problem. I call this is a hack, because
we're changing the code license to deal with a problem created by the
FSF's insistence on a separate license for documentation, but, hey, it
might work.
Do you think we should just ask the FSF to dual-license all of GCC?
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
Ian Lance Taylor wrote:
>> Do you think we should just ask the FSF to dual-license all of GCC?
>
> Sure, it might at least be worth finding out whether they think there is
> any problem with that.
I've asked on the SC list.
Thanks,
--
Mark Mitchell
CodeSourcery
m...@c
e things back and forth between code and documentation at will), and
which benefited users (by making it easier for us to generate better
documentation).
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
. Movement in that direction should
not be of concern to the FSF; the point of the GFDL was to prevent
people removing the FSF's philosophical statements in its manuals, not
to prevent GPL'd content from being used in manuals.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
thus far has not seemed terribly
concerned about the inability to move things between code and documentation.
A few of the other SC members have weighed in, but it would certainly be
helpful if more would do so.
Thanks,
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
st that on the SC list -- not that you need my permission!
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
x27;d contributions to be licensed under the GFDL, but that's not
terribly useful unless we can get some dispensation for the existing code.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
will be unable to attend, and we will try to address those
questions during the Q&A session.
We very much appreciated everyone's participation during the previous
session, and look forward to doing it again!
Gerald, would you please update the web site as you see fit (if at all)?
Than
Mark Mitchell wrote:
> As before, feel free to put questions that you would like to ask on this
> Wiki page:
I failed to include the URL.
It is:
http://gcc.gnu.org/wiki/Release%20Manager%20Q%26A
Thanks,
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
t escalating the issue is more helpful. GCC is not
> the only project with this problem.
Sadly, at this point, RMS is simply taking the position that this is not
a problem worth solving.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
F's objectives (manuals were
under the GPL for ages without the world ending), and which GCC's
competitors can do. That's a suboptimal policy.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
learly that he
thinks that you *cannot* do this?
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
uggest that we do that in the context of FSF GCC?
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
ion. If this is really about
documentation quality, the FSF could simply have a policy saying that
GNU maintainers should not do this -- there is no reason to have a legal
prohibition preventing people from doing it!
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
ether before you end up with something that is
more than mere aggregation.
None of this really answers the key question, which is, in my opinion,
what is the GFDL actually buying us? And, if all it's buying us is that
people can't remove the FSF's philosophical statements in manua
this mirror seems to be stuck at versions around late 2009.
regards, mark hahn.
general idea is reasonable. I also think it might be worth
>> spending a few minutes thinking about whether we can implement some more
>> general diagnostic suppression mechanism. E.g.,
>>int x __attribute__ ((ignore ("-Wuninitialized")));
>
> Or this.
FWIW, I t
to indicate that you were knowingly not initializing i.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
the programming model in C++.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
ot;int x = x;" as
a synonym for the forseeable future; whether or not it's good language
design it has been a de facto part of GNU C for a long time.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
.
Thank you,
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
nation of the
SC's perception of the importance of the target and the technical stats
of the port. I can raise the issue with the SC, if you like, but,
personally, I'm not sure that 64-bit Windows is significant enough as a
target platform for GCC to merit that status.
Thanks,
--
Mark Mitchel
ertainly heard of some interest in 64-bit Windows, but nowhere near as
much as 32-bit Windows or Cygwin.
I certainly don't mind raising the issue, if you want me to do that; I'm
happy to carry messages to the SC independent of my own opinions.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
cked in our favor :)
OK, I've asked the SC to consider it.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
ion, and that we should not warn in
that specific case even if we should warn about calls to functions
written by users. But, the cast to double is valid on all platforms, so
I'm not sure that's a bad solution either.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
case, yes, I guess an assembly-scan test in
target-supports.exp is the best that we can do.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
,
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
your mail like all the compiler needs to do is to read
the binary contents of a named section. Isn't that something that BFD
does well?
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
oid a single compiler build requiring
multiple object-file reading libraries.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
!) I certainly have no
problem with using elfcpp over libelf.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
reason that this would be desirable?
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
the compiler and then we can implement that
interface as we please. I agree that a fallback to an external objcopy
is plausible, as is linking with BFD.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
istorical; gcc/cc1/as/ld mirror typical UNIX
compilers of the era at which GCC was built. collect2 was presumably
necessary because of dependence on proprietary ld; if we could assume
GNU ld (or GOLD) everywhere, we could fold that functionality directly
into the linker.
--
Mark Mitchell
CodeS
gure and Makefile changes are sufficiently obvious given the
> other changes as to not require approval.
This all looks good to me, and seems like a reasonable solution. I
think libiberty is as good a place as any for the routines, FWIW.
Thanks,
--
Mark Mitchell
CodeSourcery
m...@codesourcer
at do people think about this idea?
Thank you,
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
x27;s try and do that.
Thank you,
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
ligation to fix the
problem. All we're changing is whether you build Java by default;
nothing else.
Thank you,
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
we *do* have a
consensus: remove Java from default languages, but do leave it in
autotesters (with consequences as above).
Thank you,
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
let a possible change on the Ada side prevent us from making the Java
change.
Thank you,
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
explicit
> --enable-languages option with java. Andrew has also asked to receive
> e-mail when there is a Java bug.
We have a machine doing GCC builds for GNU Classpath. Are there scripts
for official autotesters that can automatically detect regressions and
send email to the right people?
Thanks,
Mark
In general, I think the
patch needs a paragraph-long comment explaining what the problem is and
how this approach solves it.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Steven Bosscher wrote:
> On Friday 20 January 2006 18:21, Mark Mitchell wrote:
>
>>Richard Guenther wrote:
>>
>>>A patch was also posted based on ideas in the audit trail. It's third
>>>incarnation at
>>>http://gcc.gnu.org/ml/gcc-patches/2006-
Richard Guenther wrote:
>>patch needs a paragraph-long comment explaining what the problem is and
>>how this approach solves it.
>
> Ok, I'll try to come up with an explanation.
Thanks!
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
f the problematic cases and sufficiently non-harmful in other
cases as to merit inclusion, given that we don't have a better solution?
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Richard Henderson wrote:
> On Fri, Jan 20, 2006 at 01:26:51PM -0800, Mark Mitchell wrote:
>
>>I guess a secondary question is: is the workaround sufficiently useful
>>in many of the problematic cases and sufficiently non-harmful in other
>>cases as to merit inclusion, gi
Joe Buck wrote:
> It is PR 25892.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Jan 2006 16:55:54 - GOMP - Diego Novillo
>
> So I am requesting that we go through a 48 hour period starting Monday
> (as the weekends are usually quiet for patch committing) for a stage 3
> type regression only/bug fixes.
I'm inclined to agree. Any objections?
--
Mark Mit
901 - 1000 of 1834 matches
Mail list logo
