the
top of tree. Configure parameters are the same.
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
a link from libdecnumber/dpd/gstdint.h to libgcc/gstdint.h fixes the
problem.
Is there a better fix?
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
., is described in the Dwarf Standard on page 166.
See http://dwarfstd.org.
If you are looking for translation between gcc register numbers
and the Dwarf register numbers, look in dwarf2out.c. Search for
DBX_REGISTER_NUMBER.
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650
On 09/13/2011 10:58 AM, Richard Sandiford wrote:
As per the subject. Tested by making sure that there were no new
warnings building microblaze-elf, and that there were no changes
in the assembly output for the C and C++ testsuite. OK to install?
OK.
--
Michael Eagerea...@eagercon.com
in the
object files is localized in format-specific routines, actual collection
of the data is more implicit than explicit.
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
that different targets would have different meanings
for the macro opcodes.
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
On 07/22/2011 02:08 PM, Richard Henderson wrote:
On 07/22/2011 12:54 PM, Michael Eager wrote:
The definition of opcodes in the line number table is different from
opcodes in other tables, including a modified macro table. There
are many opcodes (essentially every possible value is used
On 07/22/2011 02:20 PM, Richard Henderson wrote:
On 07/22/2011 02:16 PM, Michael Eager wrote:
On 07/22/2011 02:08 PM, Richard Henderson wrote:
On 07/22/2011 12:54 PM, Michael Eager wrote:
The definition of opcodes in the line number table is different from
opcodes in other tables, including
into either
.debug_macinfo or .debug_macro, depending on which was present.
I think that your modifications would be a significant improvement to DWARF.
Please submit a proposal at http://dwarfstd.org/Comment.php.
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
On 07/20/2011 11:00 AM, Jakub Jelinek wrote:
On Wed, Jul 20, 2011 at 10:16:10AM -0700, Michael Eager wrote:
It took me a few days to review the current DWARF macinfo specification
and review this proposal.
The existing macro data format is clearly in need of revision. I don't
think
when max_depth is greater than 17. If -g is
specified, this later results in attempting to generate a DWARF location
list much larger than the 0x size limit, resulting in an assert failure.
Changelog:
2011-07-20 Michael Eager ea...@eagercon.com
* params.def
On 07/20/2011 01:23 PM, Jakub Jelinek wrote:
On Wed, Jul 20, 2011 at 01:07:40PM -0700, Michael Eager wrote:
I've run into a problem with this change when building microblaze-xilinx-elf.
When compiling _divdi3.o, cselib_expand_value_rtx_1 returns a huge rtx
tree for variable _r1 when max_depth
On 07/20/2011 01:48 PM, Jakub Jelinek wrote:
On Wed, Jul 20, 2011 at 01:28:46PM -0700, Michael Eager wrote:
On 07/20/2011 01:23 PM, Jakub Jelinek wrote:
On Wed, Jul 20, 2011 at 01:07:40PM -0700, Michael Eager wrote:
I've run into a problem with this change when building microblaze-xilinx-elf
++ and
see what g++ generates, then try to match it with gfortran.
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
in the awkward position of a language
standard being revised so that the DWARF definition no longer matched.
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
to target maintainers for the target specific changes. That said,
I'm not familiar enough with the area of the patch. But yes,
it's stage1 now - so if anyone else wants to approve this patch...
Microblaze change OK.
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325
= 0;
+ }
+ /* Fall through. */
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
it for MicroBlaze is no longer needed.
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Ralf Wildenhues wrote:
Hello Michael,
* Michael Eager wrote on Fri, Oct 22, 2010 at 10:35:48PM CEST:
Paolo Carlini wrote:
On 10/22/2010 08:43 PM, Michael Eager wrote:
I'm seeing test suite failures in g++ caused by
linking with the wrong libstdc++.so.
It looks like g++.exp always appends
into this problem?
Is this supposed to work in a different way?
Anyone come up with a fix?
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Paolo Carlini wrote:
On 10/22/2010 08:43 PM, Michael Eager wrote:
Hi --
I'm seeing test suite failures in g++ caused by
linking with the wrong libstdc++.so.
It looks like g++.exp always appends the default
directory
append flags -L${gccpath}/libstdc++-v3/src/.libs
instead of
append flags
the result. (This doesn't happen with soft-fp.)
int r = 0, s = 0;
float a = 1.0, x = NaN;
r = (a = x);
s = (a x);
should result in r == s == 0. CSE translates this (more
or less) into
r = (a = x);
s = !r;
Is there a way to prevent CSE from optimizing FP comparisons?
--
Michael Eager
David Edelsohn wrote:
I am pleased to announce that the GCC Steering Committee has
accepted the Microblaze port for inclusion in GCC and appointed
Michael Eager as port maintainer.
Thanks!
Adding myself to maintainer list.
Index: MAINTAINERS
Joel Sherrill wrote:
On 09/28/2010 01:56 PM, Michael Eager wrote:
David Edelsohn wrote:
I am pleased to announce that the GCC Steering Committee has
accepted the Microblaze port for inclusion in GCC and appointed
Michael Eager as port maintainer.
Thanks!
Congratulations!
Does your
on.
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Michael Eager wrote:
The final version of DWARF Version 4 is available
for download from http://dwarfstd.org.
A technical problem generating the PDF of the DWARF
Version 4 standard has been corrected. Please see
following announcement.
--
Michael Eagerea...@eagercon.com
1960 Park Blvd
a broad range of companies,
including Apple, ARM, CodeSourcery, Concurrent Computer, Eager Consulting,
Google, Hewlett-Packard, IBM, RedHat, SGI, Sun Microsystems, and TotalView, as
well as unaffiliated individuals with significant experience in compiler and
debugger development.
Michael Eager
The final version of DWARF Version 4 is available
for download from http://dwarfstd.org.
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
-04/msg01907.html
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg01906.html
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
version will be
published. Additional information about DWARF, including how to subscribe to the
DWARF mailing list, can also be found on the website. Questions about the DWARF
Debugging Information Format or the DWARF Committee can be directed to the DWARF
Committee Chair, Michael Eager, at mailto:i
The microblaze branch has been synced with gcc-head and
updated to gcc-4.5.0.
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
of the output? Is this a GNU
bug or just an unsupported feature?
It looks like a GCC bug to me. GCC does generate DW_TAG_typedef
for other typedefs.
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
correct this to
generate the real type name?
A better question might by why there is no DW_TAG_typedef
DIE which looks like
DW_TAG_typedef
DW_AT_name: BASE_UNION
DW_AT_type: 1279
BTW gcc-4.3.2 generates
DW_AT_name: anonymous union
which is also incorrect.
--
Michael Eager
I've updated the Microblaze branch to gcc-4.5.
It has passed gcc regression tests reasonably well.
I still have some minor cleanup to do -- updating
copyright notices, checking indents, and so forth.
What's the best process for merging this into head?
Should I submit a patch?
--
Michael Eager
/cmpu instructions only take a register. Other instructions
which can be used for equality or signed comparisons (xor or sub)
can take an immediate operand. I'll see how they can be added.
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Joern Rennecke wrote:
Quoting Michael Eager ea...@eagercon.com:
Hi --
I'm working on creating the cstore and cbranch templates
for the Xilinx MicroBlaze processor.
In theory cstore / cbranch should be the future, but the last time I tried
to use them, they didn't quite work right yet
?
Any suggestions on better ways to model the MicroBlaze
comparison operations?
Are there some restriction on using eq/ne/lt/... the
way I am?
Any suggestions on how to fix the problem in CSE?
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
://lists.dwarfstd.org/listinfo.cgi/dwarf-announce-dwarfstd.org
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Jeff Law wrote:
On 11/30/09 14:48, Michael Eager wrote:
Jeff Law wrote:
On 11/30/09 14:17, Michael Eager wrote:
I've run into a situation where assign_hard_reg()
decides that there are no registers available.
That can certainly happen. It's also the case that assign_hard_reg
may decide
doesn't allow memory, so I'm unclear why
mem_cost is being set. allows_mem[] is zero for all
operands in the insn.
Can anyone give me some guidance here?
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Jeff Law wrote:
On 11/30/09 14:17, Michael Eager wrote:
I've run into a situation where assign_hard_reg()
decides that there are no registers available.
That can certainly happen. It's also the case that assign_hard_reg may
decide that memory is cheaper than a register and refuse to assign
Jeff Law wrote:
On 11/30/09 14:48, Michael Eager wrote:
Jeff Law wrote:
On 11/30/09 14:17, Michael Eager wrote:
I've run into a situation where assign_hard_reg()
decides that there are no registers available.
That can certainly happen. It's also the case that assign_hard_reg
may decide
I've checked in patches to the microblaze branch
to bring it into sync with gcc-4.4.2. This has been
tagged with microblaze-4.4.2.
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
sumanth wrote:
Hi,
How can I make sure the debugging information printed by my
compiler for extern variables is correct.
Make sure you compile with -g. If you don't generate
debug info for the variable, gdb will default to printing
it as an unknown symbol.
--
Michael Eagerea
Hi --
This is just a heads-up that I'm working on GCC support
for the Xilinx MicroBlaze. It is currently based on
gcc-4.1.2 and I'm porting it to gcc-4.5.0.
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
proved to be harder than in GCC's side (since we're
already assuming things, it would just be another workaround).
Luis
On Tue, 2009-07-21 at 08:38 -0500, Peter Bergner wrote:
On Thu, 2009-07-16 at 13:55 -0700, Michael Eager wrote:
I've tracked down a failure in gdb to hit a breakpoint
set
is
executed, the branch (1) is taken, jumping over the the breakpoint.
I think that the .loc at (2) should not be generated, since it is
in the middle of the prologue code.
I'll file a bug report unless someone already has done so.
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA
Olivier Hainque wrote:
Michael Eager wrote:
I'll reverse-engineer the table unless I can find something
more descriptive than the comments in gcc or gdb.
FWIW, I did a similar exercise long ago and synthesized my
understanding in ada/raise-gcc.c, where the Ada personality routine
Michael Matz wrote:
Hi,
On Fri, 15 May 2009, Michael Eager wrote:
Is there any documentation on the contents of .eh_frame
and the augmentations used?
.eh_frame simply contains normal unwinding information, in DWARF2(34)
format, you're familiar with that :)
And nothing more, specifically
Michael Matz wrote:
Hi,
On Sun, 17 May 2009, Michael Eager wrote:
But the _format_ of the LSDA is not specified. It's really an
implementation detail of the compiler/language and doesn't have to be
agreed upon for mixing .o files from different compilers, as every
compilation unit can have
Is there any documentation on the contents of .eh_frame
and the augmentations used? IIRC, the data describes the
try blocks and the catch handlers, but I'm looking for
the gory details.
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Ian Lance Taylor wrote:
Michael Eager ea...@eagercon.com writes:
Is there any documentation on the contents of .eh_frame
and the augmentations used? IIRC, the data describes the
try blocks and the catch handlers, but I'm looking for
the gory details.
I don't know of any docs. Docs would
Dave Korn wrote:
Michael Eager wrote:
Does anyone have any suggestions on how to get one of
these tests to fail consistently, or a different approach
to finding the cause of the intermittent failures?
Perhaps hack the testsuite to run the tests under gdb, setting a breakpoint
on abort
that this is a problem only on powerpc
and perhaps only powerpc-eabi.
Does anyone have any suggestions on how to get one of
these tests to fail consistently, or a different approach
to finding the cause of the intermittent failures?
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306
Dave Korn wrote:
Michael Eager wrote:
Does anyone have any suggestions on how to get one of
these tests to fail consistently, or a different approach
to finding the cause of the intermittent failures?
Perhaps hack the testsuite to run the tests under gdb, setting a breakpoint
on abort
::classic_table()’:
.../build/powerpc-eabi/libstdc++-v3/include/powerpc-eabi/bits/ctype_noninline.h:43: error: ‘_ctype_’ was not declared in
this scope
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Jeff Law wrote:
Richard Henderson wrote:
Michael Eager wrote:
Another possibility is illegal rtl sharing.
If you mean that an rtx would be pointed to by two different
insn's, how would that happen? (Excluding someone mucking
things up deliberately or accidentally.)
Generally this sort
Richard Henderson wrote:
Ian Lance Taylor wrote:
Michael Eager [EMAIL PROTECTED] writes:
I'm running into a situation where reload is replacing
a pseudo-register in an insn with a memory reference.
The problem is that this is happening in a memory ref.
The initial pattern is something like
Ian Lance Taylor wrote:
Michael Eager [EMAIL PROTECTED] writes:
I'm running into a situation where reload is replacing
a pseudo-register in an insn with a memory reference.
The problem is that this is happening in a memory ref.
The initial pattern is something like
(set (reg/v:SI 1) (mem
a load from reg-equiv to a reg
rather than replace the pseudo-reg with the reg-equiv?
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
it.
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
a
register interlock.
Are there any targets with register interlock where
gcc handles moving instructions between conflicting
instructions?
Any suggestions on how this might be represented
in .md files? It doesn't seem that the pipeline
description would seem appropriate.
--
Michael Eager[EMAIL
Richard Sandiford wrote:
Michael Eager [EMAIL PROTECTED] writes:
I have a processor which does not have hardware
register interlocks, somewhat like the MIPS I.
A register used in one instruction may not be
referenced for a certain number of instructions.
If I recall correctly, for the MIPS I
Joseph S. Myers wrote:
On Fri, 4 Apr 2008, Michael Eager wrote:
Xilinx has a PowerPC 405 processor with an attached
single precision floating point processor. I have a
patch which supports this FP unit, but want to clean
it up a bit before submitting it.
What do you propose as the function
TARGET_DOUBLE_FLOAT
efdctuiz %0,%1
[(set_attr type fp)])
for an instruction on E500 only with double precision FP.
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Daniel Jacobowitz wrote:
On Sun, Apr 06, 2008 at 10:25:38AM -0700, Michael Eager wrote:
For an instruction supported on all variants (both BookE and E500)
with a double precision FPU.
I think you have your terminology switched. E500 is (very
approximately) an implementation of Book E
prefer having the feature explicit. The other is to retain TARGET_FPRS
instead of using TARGET_E500, since this would be more feature-based
rather than processor model based.
Comments and/or suggestions?
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
running aclocal v. 1.10, autoconf v. 2.61)
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
/autoconf/lang.m4 says that is
provided by both autoconf-2.61-9 and autoconf-2.59-12. So
I really don't know whether 2.61 has been replaced by 2.59
or not.
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Paolo Carlini wrote:
Michael Eager wrote:
I'm trying to update configure in gcc/libstdc++-v3.
Provided you have the correct versions of autoconf and automake, as
indicated, just running autoreconf certainly works.
Not for me. :-(
Autoreconf gives the same errors from aclocal.
--
Michael
Ralf Wildenhues wrote:
* Michael Eager wrote on Mon, Mar 24, 2008 at 08:53:22PM CET:
Paolo Carlini wrote:
Michael Eager wrote:
I'm trying to update configure in gcc/libstdc++-v3.
Provided you have the correct versions of autoconf and automake, as
indicated, just running autoreconf certainly
Brian Dessent wrote:
Michael Eager wrote:
I've noticed a problem with the patch:
if test ${with_newlib+set} = set; then
AC_LIBTOOL_DLOPEN
fi
The test always succeeds. When $with_newlib is yes,
${with_newlib+set} is set.
If I change this to the old style test
if test x
Peter O'Gorman wrote:
Michael Eager wrote:
I've noticed a problem with the patch:
if test ${with_newlib+set} = set; then
AC_LIBTOOL_DLOPEN
fi
The test always succeeds. When $with_newlib is yes,
${with_newlib+set} is set.
If I change this to the old style test
if test x$with_newlib
Ian Lance Taylor wrote:
Michael Eager [EMAIL PROTECTED] writes:
I patched the code to only count the occurrence if the
locations are different. Any idea if that has adverse
consequences?
I would expect that to work. But before bringing it back to mainline
I'd like to find out why
+= count_occurrences (PATTERN (insn), XEXP (i1, 0), 0);
}
Sure enough, i1 matches substed.
reg_equiv_memory_loc[regno] (the source for substed) is the same as
reg_equiv_alt_mem_list[regno].
Why is this unexpected and what might cause it?
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd
Ian Lance Taylor wrote:
Michael Eager [EMAIL PROTECTED] writes:
I'm trying to understand an assertion failure in reload1.c:8135.
In delete_output_reload(), I'm getting an assertion failure
in this code:
for (i1 = reg_equiv_alt_mem_list [REGNO (reg)]; i1; i1 = XEXP (i1, 1
Michael Eager wrote:
Joseph S. Myers wrote:
On Tue, 27 Nov 2007, Michael Eager wrote:
I think that there is a pervasive understanding that SImode is
single precision integer, 32-bits long.
Only among contributors not considering non-8-bit bytes. SImode is 4
times QImode, 4*BITS_PER_UNIT
Joseph S. Myers wrote:
On Mon, 26 Nov 2007, Michael Eager wrote:
Well, can't do that. This is not target dependent.
DImode gets defined, and used, for long long in unwind-dw2.c.
Is it defined what DWARF unwind information looks like when made up of
bytes wider than 8 bits? Certainly GCC's
Joseph S. Myers wrote:
On Tue, 27 Nov 2007, Michael Eager wrote:
I think that there is a pervasive understanding that SImode is
single precision integer, 32-bits long.
Only among contributors not considering non-8-bit bytes. SImode is 4
times QImode, 4*BITS_PER_UNIT bits, and may not exist
,
without any reference to bytesize.
Is there a different way to define word-addressed targets?
Or should I just pretend it has byte addressing?
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
operations respectively.
Well, can't do that. This is not target dependent.
DImode gets defined, and used, for long long in unwind-dw2.c.
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
.
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
there are clean room implementations of proprietary software
-- to prevent just the copyright contamination which you describe.
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
no contract. This seems to be a common confusion, which FSF has tried
to dispel. A contract requires two (or more) parties to come to an agreement.
GPL is a license. The GPL is not a contract. There isn't even an implied
contract.
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo
* here, where the underlying license
derives from the file being patched, not the patch itself. There's a big
difference!
I was talking about patches -- copyrightable creative works which may
be assigned and licensed. You appear to be talking about something else.
--
Michael Eager[EMAIL
Robert Dewar wrote:
Michael Eager wrote:
GPL is a license. The GPL is not a contract. There isn't even an
implied
contract.
You really are NOT a lawyer (or at least I would presume that from what
you are writing). Much of the above is just WAY off!
I am not a lawyer, but there is still
months.
The concern which I raised is not about the GPLv3. It is in the
policy decisions which FSF makes about applying patches to source
which was previously released under GPLv2. This is not something
which the FSF disclosed in the past.
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd
. Neither are present in the GPL.
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
a legal right to use the software.
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
speaking)
under which that software can be used.
No, no, no. A consideration is an exchange of value. It's part of a contract.
A license is not a contract.
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
is anonymous. Agreement to abide by
the conditions of the license is (a) not a meeting of the minds, it's a
condition of the license, and (b) it's not a valuable consideration, again
it is a condition of the license.
I'm done with this discussion. It's not going anywhere.
--
Michael Eager
Dave Korn wrote:
On 16 July 2007 18:51, Michael Eager wrote:
I'm done with this discussion. It's not going anywhere.
That would have been just a tad more impressive if it wasn't at the end of a
long stretch of self-justification. As it was, it comes across more like
trying to have
developed.
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
of it to my friend, I would have to remember to tell her that
the file isn't licensed under what it says it's licensed under. That's
also not good.
Yes, the situation seems chaotic and confusing. Not a good thing.
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650
be either coincidence if they
happened to be identical, or a requirement of the context.
But this second patch is really irrelevant to the discussion at hand.
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
number
will not tell you whether the code is licensed under GPLv2 or GPLv3.
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Robert Dewar wrote:
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
Krzysztof Halasa wrote:
Michael Eager [EMAIL PROTECTED] writes:
Not until someone updates the txt. Which should happen quickly,
but if someone applies a GPLv3 patch to a previously GPLv2 branch,
the entire branch becomes GPLv3, whether the COPYING file was
updated or not.
Come
make it one.
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
201 - 300 of 363 matches
Mail list logo
