Re: GCC documentation: porting to Sphinx
On 5/31/21 5:49 PM, Michael Matz wrote: Hello Martin, On Mon, 31 May 2021, Martin Liška wrote: I've made quite some progress with the porting of the documentation and I would like to present it to the community now: https://splichal.eu/scripts/sphinx/ Note the documentation is automatically ([1]) generated from texinfo with a GitHub workflow ([2]). One other thing I was recently thinking about, in the Spinx vs. texinfo discussion: locally available documentation browsable/searchable in terminal with info(1) (or equivalents). Yes, that's handy. I think the above (i.e. generating .rst from the texinfo file) would immediately nullify all my worries. So, just to be extra sure: your proposal now is to generate the .rst files, and that .texinfo remains the maintained sources, right? No, .texinfo files will be gone. However, Sphinx can output to info format: https://www.sphinx-doc.org/en/master/man/sphinx-build.html#cmdoption-sphinx-build-M And I've just added the generated Info pages here: https://splichal.eu/scripts/sphinx/ Hope it helps? Martin Ciao, Michael.
Re: [PATCH] Try LTO partial linking. (Was: Speed of compiling gimple-match.c)
PING^1 On 5/21/21 10:29 AM, Martin Liška wrote: On 5/20/21 5:55 PM, Jan Hubicka wrote: Quick solution is to also modify partitioner to use the local symbol names when doing incremental linking (those mixing in source code and random seeds) to avoid clashes. Good hint. I added hash based on object file name (I don't want to handle proper string escaping) and -frandom-seed. What do you think about the patch? Thanks, Martin
Re: [PATCH] Try LTO partial linking. (Was: Speed of compiling gimple-match.c)
@Richi: Can you please reply to this email? On 5/21/21 10:43 AM, Martin Liška wrote: On 5/20/21 2:54 PM, Richard Biener wrote: On Thu, May 20, 2021 at 2:34 PM Martin Liška wrote: Hello. I've got a patch candidate that leverages partial linking for a couple of selected object files. I'm sending make all-host- jX results for my machine: before: 3m18s (user 32m52s) https://gist.githubusercontent.com/marxin/223890df4d8d8e490b6b2918b77dacad/raw/1dd5eae5001295ba0230a689f7edc67284c9b742/gcc-all-host.svg after: 2m57m (user 35m) https://gist.githubusercontent.com/marxin/223890df4d8d8e490b6b2918b77dacad/raw/d659b2187cf622167841efbbe6bc93cb33855fa9/gcc-all-host-partial-lto.svg One can utilize it with: make -j16 all-host PARTIAL_LTO=1 @Segher, Andrew: Can you please measure time improvement for your slow bootstrap? One can also tweak --param=lto-partitions=16 param value. Thoughts? You're LTO linking multiple objects here - that's almost as if you were doing this for the whole of libbackend.a ... so $(OBJS)_CLFAGS += -flto and in the libbackend.a rule do a similar partial link trick. Yeah, apart from that one can't likely do partial linking for an archive: $ g++ -no-pie -flto=auto --param=lto-partitions=16 -flinker-output=nolto-rel -r libbackend.a collect2: fatal error: ld terminated with signal 11 [Segmentation fault], core dumped compilation terminated. while ld.bfd immediately finishes. That gets you half of a LTO bootstrap then. So why did you go from applying this per-file to multiple files? Does $(LINKER) have a proper rule to pick up a jobserver? When upstreaming in any form you probably have to gate it on bootstrap-lto being not active. Sure, that's reasonable, we can likely detect a -flto option in $(COMPILE), right? One more thing I face is broken dependency: $ make clean && make -j32 PARTIAL_LTO=1 g++ -fcf-protection -fno-PIE -c -g -DIN_GCC -fPIC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -Wno-unused -DHAVE_CONFIG_H -I. -I. -I/home/marxin/Programming/gcc/gcc -I/home/marxin/Programming/gcc/gcc/. -I/home/marxin/Programming/gcc/gcc/../include -I/home/marxin/Programming/gcc/gcc/../libcpp/include -I/home/marxin/Programming/gcc/gcc/../libcody -I/home/marxin/Programming/gcc/gcc/../libdecnumber -I/home/marxin/Programming/gcc/gcc/../libdecnumber/bid -I../libdecnumber -I/home/marxin/Programming/gcc/gcc/../libbacktrace -o gimple-match-lto.o -MT gimple-match-lto.o -MMD -MP -MF ./.deps/gimple-match-lto.TPo gimple-match.c -flto g++ -fcf-protection -fno-PIE -c -g -DIN_GCC -fPIC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -Wno-unused -DHAVE_CONFIG_H -I. -I. -I/home/marxin/Programming/gcc/gcc -I/home/marxin/Programming/gcc/gcc/. -I/home/marxin/Programming/gcc/gcc/../include -I/home/marxin/Programming/gcc/gcc/../libcpp/include -I/home/marxin/Programming/gcc/gcc/../libcody -I/home/marxin/Programming/gcc/gcc/../libdecnumber -I/home/marxin/Programming/gcc/gcc/../libdecnumber/bid -I../libdecnumber -I/home/marxin/Programming/gcc/gcc/../libbacktrace -o generic-match-lto.o -MT generic-match-lto.o -MMD -MP -MF ./.deps/generic-match-lto.TPo generic-match.c -flto In file included from ./tm.h:26, from /home/marxin/Programming/gcc/gcc/backend.h:28, from /home/marxin/Programming/gcc/gcc/generic-match-head.c:23, from generic-match.c:4: /home/marxin/Programming/gcc/gcc/config/i386/i386.h:2286:10: fatal error: insn-attr-common.h: No such file or directory 2286 | #include "insn-attr-common.h" | ^~~~ compilation terminated. make: *** [Makefile:2678: generic-match-lto.o] Error 1 make: *** Waiting for unfinished jobs In file included from ./tm.h:26, from /home/marxin/Programming/gcc/gcc/backend.h:28, from /home/marxin/Programming/gcc/gcc/gimple-match-head.c:23, from gimple-match.c:4: /home/marxin/Programming/gcc/gcc/config/i386/i386.h:2286:10: fatal error: insn-attr-common.h: No such file or directory 2286 | #include "insn-attr-common.h" | ^~~~ I explicitly added: gimple-match.o: gimple-match.c $(generated_files) generic-match.o: generic-match.c $(generated_files) But it's not obeyed. Martin Richard. Thanks, Martin
Re: [PATCH] Try LTO partial linking. (Was: Speed of compiling gimple-match.c)
On Tue, Jun 1, 2021 at 9:33 AM Martin Liška wrote: > > @Richi: Can you please reply to this email? Not sure what I should add here? Honza suggested to mangle the promoted symbol names. I don't really like the idea to compile multiple TUs into one object. Also +LTO_LINKER_FLAGS = -flto=auto --param=lto-partitions=16 -flinker-output=nolto-rel -r why hard-code to 16 partitions? You're side-stepping the driver diagnostic by doing compile & link separately, but in the end we're going to want sth like Giulianos -fparallel-compile that works transparently from within the driver, so the "manual" operation should try to follow that or alternatively a driver-only wrapper around the "manual" processing could be added whose implementation can be optimized later. Why do you use -flto=auto? There should be a jobserver active. > On 5/21/21 10:43 AM, Martin Liška wrote: > > On 5/20/21 2:54 PM, Richard Biener wrote: > >> On Thu, May 20, 2021 at 2:34 PM Martin Liška wrote: > >>> > >>> Hello. > >>> > >>> I've got a patch candidate that leverages partial linking for a couple of > >>> selected object files. > >>> > >>> I'm sending make all-host- jX results for my machine: > >>> > >>> before: 3m18s (user 32m52s) > >>> https://gist.githubusercontent.com/marxin/223890df4d8d8e490b6b2918b77dacad/raw/1dd5eae5001295ba0230a689f7edc67284c9b742/gcc-all-host.svg > >>> > >>> after: 2m57m (user 35m) > >>> https://gist.githubusercontent.com/marxin/223890df4d8d8e490b6b2918b77dacad/raw/d659b2187cf622167841efbbe6bc93cb33855fa9/gcc-all-host-partial-lto.svg > >>> > >>> One can utilize it with: > >>> make -j16 all-host PARTIAL_LTO=1 > >>> > >>> @Segher, Andrew: Can you please measure time improvement for your slow > >>> bootstrap? > >>> One can also tweak --param=lto-partitions=16 param value. > >>> > >>> Thoughts? > >> > >> You're LTO linking multiple objects here - that's almost as if you > >> were doing this > >> for the whole of libbackend.a ... so $(OBJS)_CLFAGS += -flto and in the > >> libbackend.a rule do a similar partial link trick. > > > > Yeah, apart from that one can't likely do partial linking for an archive: > > > > $ g++ -no-pie -flto=auto --param=lto-partitions=16 > > -flinker-output=nolto-rel -r libbackend.a > > collect2: fatal error: ld terminated with signal 11 [Segmentation fault], > > core dumped > > compilation terminated. > > > > while ld.bfd immediately finishes. > > > >> > >> That gets you half of a LTO bootstrap then. > >> > >> So why did you go from applying this per-file to multiple files? Does > >> $(LINKER) > >> have a proper rule to pick up a jobserver? > >> > >> When upstreaming in any form you probably have to gate it on bootstrap-lto > >> being not active. > > > > Sure, that's reasonable, we can likely detect a -flto option in $(COMPILE), > > right? > > > > One more thing I face is broken dependency: > > $ make clean && make -j32 PARTIAL_LTO=1 > > > > g++ -fcf-protection -fno-PIE -c -g -DIN_GCC -fPIC-fno-exceptions > > -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing > > -Wwrite-strings -Wcast-qual -Wno-error=format-diag > > -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long > > -Wno-variadic-macros -Wno-overlength-strings -fno-common -Wno-unused > > -DHAVE_CONFIG_H -I. -I. -I/home/marxin/Programming/gcc/gcc > > -I/home/marxin/Programming/gcc/gcc/. > > -I/home/marxin/Programming/gcc/gcc/../include > > -I/home/marxin/Programming/gcc/gcc/../libcpp/include > > -I/home/marxin/Programming/gcc/gcc/../libcody > > -I/home/marxin/Programming/gcc/gcc/../libdecnumber > > -I/home/marxin/Programming/gcc/gcc/../libdecnumber/bid -I../libdecnumber > > -I/home/marxin/Programming/gcc/gcc/../libbacktrace -o gimple-match-lto.o > > -MT gimple-match-lto.o -MMD -MP -MF ./.deps/gimple-match-lto.TPo > > gimple-match.c -flto > > g++ -fcf-protection -fno-PIE -c -g -DIN_GCC -fPIC-fno-exceptions > > -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing > > -Wwrite-strings -Wcast-qual -Wno-error=format-diag > > -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long > > -Wno-variadic-macros -Wno-overlength-strings -fno-common -Wno-unused > > -DHAVE_CONFIG_H -I. -I. -I/home/marxin/Programming/gcc/gcc > > -I/home/marxin/Programming/gcc/gcc/. > > -I/home/marxin/Programming/gcc/gcc/../include > > -I/home/marxin/Programming/gcc/gcc/../libcpp/include > > -I/home/marxin/Programming/gcc/gcc/../libcody > > -I/home/marxin/Programming/gcc/gcc/../libdecnumber > > -I/home/marxin/Programming/gcc/gcc/../libdecnumber/bid -I../libdecnumber > > -I/home/marxin/Programming/gcc/gcc/../libbacktrace -o generic-match-lto.o > > -MT generic-match-lto.o -MMD -MP -MF ./.deps/generic-match-lto.TPo > > generic-match.c -flto > > > > In file included from ./tm.h:26, > > from /home/marxin/Programming/gcc/gcc/backend.h:28, > > from > > /home/marxin/Programming/gcc/gcc/generic-match-head.c:23, > >
GCC 9.4.1 Status Report (2021-06-01)
Status == The GCC 9 branch is again open for regression and documentation fixes. Quality Data Priority # Change from last report --- --- P1 P2 304 P3 26 + 3 P4 173 - 1 P5 23 --- --- Total P1-P3 331 + 3 Total 527 + 2 Previous Report === https://gcc.gnu.org/pipermail/gcc/2021-May/236084.html
GCC 9.4 Released
The GNU Compiler Collection version 9.4 has been released. GCC 9.4 is a bug-fix release from the GCC 9 branch containing important fixes for regressions and serious bugs in GCC 9.3 with more than 190 bugs fixed since the previous release. This release is available from the WWW and FTP servers listed here: https://sourceware.org/pub/gcc/releases/gcc-9.4.0/ https://gcc.gnu.org/mirrors.html Please do not contact me directly regarding questions or comments about this release. Instead, use the resources available from http://gcc.gnu.org. As always, a vast number of people contributed to this GCC release -- far too many to thank them individually!
Re: [PATCH] Try LTO partial linking. (Was: Speed of compiling gimple-match.c)
On Tue, Jun 1, 2021 at 1:25 PM Martin Liška wrote: > > On 6/1/21 9:42 AM, Richard Biener wrote: > > On Tue, Jun 1, 2021 at 9:33 AM Martin Liška wrote: > >> > >> @Richi: Can you please reply to this email? > > > > Not sure what I should add here? Honza suggested to mangle the > > promoted symbol names. > > Sure and I sent a patch for that. > > > I don't > > really like the idea to compile multiple TUs into one object. Also > > What's problematic is that we'll have to wait for one another release to make > it useful > (if you don't want to build the current master with a snapshot compiler). IMHO it's a bugfix. Note that I'm not sure what the intent of the change is. If it is to speedup bootstrap then using LTO bootstrap would do the trick as well (and better) if we'd simply process all of libbackend.a this way (and thus avoid re-linking that once for each frontend). If it is to speedup dev (re-)builds then dragging in more files will make it build longer since for example insn-recog.c may be unchanged but gimple-match.c not. > > +LTO_LINKER_FLAGS = -flto=auto --param=lto-partitions=16 > > -flinker-output=nolto-rel -r > > > > why hard-code to 16 partitions? You're side-stepping the driver > > diagnostic by doing > > compile & link separately, but in the end we're going to want sth like > > Giulianos > > -fparallel-compile that works transparently from within the driver, so > > the "manual" > > operation should try to follow that or alternatively a driver-only > > wrapper around the > > "manual" processing could be added whose implementation can be optimized > > later. > > All right. Do you want me refreshing his -fparallel-compile option > introduction? I'm not sure if we've arrived at mergeable state - but if it's reasonably possible to hide s/-fparallel-compile/-flto -r -flinker-output=nolto-rel/ split into compile & link parts (avoiding the diagnostic on -flinker-output) in the driver then I think that's a very reasonable first step (after fixing the symbol privatization issue). The GSOC project then was to elide the IL streaming from the high-level operation. Richard, > > > > Why do you use -flto=auto? There should be a jobserver active. > > Yes, that should not be needed. > > Martin > > > > >> On 5/21/21 10:43 AM, Martin Liška wrote: > >>> On 5/20/21 2:54 PM, Richard Biener wrote: > On Thu, May 20, 2021 at 2:34 PM Martin Liška wrote: > > > > Hello. > > > > I've got a patch candidate that leverages partial linking for a couple > > of selected object files. > > > > I'm sending make all-host- jX results for my machine: > > > > before: 3m18s (user 32m52s) > > https://gist.githubusercontent.com/marxin/223890df4d8d8e490b6b2918b77dacad/raw/1dd5eae5001295ba0230a689f7edc67284c9b742/gcc-all-host.svg > > > > after: 2m57m (user 35m) > > https://gist.githubusercontent.com/marxin/223890df4d8d8e490b6b2918b77dacad/raw/d659b2187cf622167841efbbe6bc93cb33855fa9/gcc-all-host-partial-lto.svg > > > > One can utilize it with: > > make -j16 all-host PARTIAL_LTO=1 > > > > @Segher, Andrew: Can you please measure time improvement for your slow > > bootstrap? > > One can also tweak --param=lto-partitions=16 param value. > > > > Thoughts? > > You're LTO linking multiple objects here - that's almost as if you > were doing this > for the whole of libbackend.a ... so $(OBJS)_CLFAGS += -flto and in the > libbackend.a rule do a similar partial link trick. > >>> > >>> Yeah, apart from that one can't likely do partial linking for an archive: > >>> > >>> $ g++ -no-pie -flto=auto --param=lto-partitions=16 > >>> -flinker-output=nolto-rel -r libbackend.a > >>> collect2: fatal error: ld terminated with signal 11 [Segmentation fault], > >>> core dumped > >>> compilation terminated. > >>> > >>> while ld.bfd immediately finishes. > >>> > > That gets you half of a LTO bootstrap then. > > So why did you go from applying this per-file to multiple files? Does > $(LINKER) > have a proper rule to pick up a jobserver? > > When upstreaming in any form you probably have to gate it on > bootstrap-lto > being not active. > >>> > >>> Sure, that's reasonable, we can likely detect a -flto option in > >>> $(COMPILE), right? > >>> > >>> One more thing I face is broken dependency: > >>> $ make clean && make -j32 PARTIAL_LTO=1 > >>> > >>> g++ -fcf-protection -fno-PIE -c -g -DIN_GCC -fPIC-fno-exceptions > >>> -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing > >>> -Wwrite-strings -Wcast-qual -Wno-error=format-diag > >>> -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long > >>> -Wno-variadic-macros -Wno-overlength-strings -fno-common -Wno-unused > >>> -DHAVE_CONFIG_H -I. -I. -I/home/marxin/Programming/gcc/gcc > >>> -I/home/marxin/Programming/gcc/gcc/. > >>> -I/home/marxin/Programming/gcc/gcc/../include > >>> -I/home/marxin/Pro
Re: [PATCH] Try LTO partial linking. (Was: Speed of compiling gimple-match.c)
On 6/1/21 9:42 AM, Richard Biener wrote: On Tue, Jun 1, 2021 at 9:33 AM Martin Liška wrote: @Richi: Can you please reply to this email? Not sure what I should add here? Honza suggested to mangle the promoted symbol names. Sure and I sent a patch for that. I don't really like the idea to compile multiple TUs into one object. Also What's problematic is that we'll have to wait for one another release to make it useful (if you don't want to build the current master with a snapshot compiler). +LTO_LINKER_FLAGS = -flto=auto --param=lto-partitions=16 -flinker-output=nolto-rel -r why hard-code to 16 partitions? You're side-stepping the driver diagnostic by doing compile & link separately, but in the end we're going to want sth like Giulianos -fparallel-compile that works transparently from within the driver, so the "manual" operation should try to follow that or alternatively a driver-only wrapper around the "manual" processing could be added whose implementation can be optimized later. All right. Do you want me refreshing his -fparallel-compile option introduction? Why do you use -flto=auto? There should be a jobserver active. Yes, that should not be needed. Martin On 5/21/21 10:43 AM, Martin Liška wrote: On 5/20/21 2:54 PM, Richard Biener wrote: On Thu, May 20, 2021 at 2:34 PM Martin Liška wrote: Hello. I've got a patch candidate that leverages partial linking for a couple of selected object files. I'm sending make all-host- jX results for my machine: before: 3m18s (user 32m52s) https://gist.githubusercontent.com/marxin/223890df4d8d8e490b6b2918b77dacad/raw/1dd5eae5001295ba0230a689f7edc67284c9b742/gcc-all-host.svg after: 2m57m (user 35m) https://gist.githubusercontent.com/marxin/223890df4d8d8e490b6b2918b77dacad/raw/d659b2187cf622167841efbbe6bc93cb33855fa9/gcc-all-host-partial-lto.svg One can utilize it with: make -j16 all-host PARTIAL_LTO=1 @Segher, Andrew: Can you please measure time improvement for your slow bootstrap? One can also tweak --param=lto-partitions=16 param value. Thoughts? You're LTO linking multiple objects here - that's almost as if you were doing this for the whole of libbackend.a ... so $(OBJS)_CLFAGS += -flto and in the libbackend.a rule do a similar partial link trick. Yeah, apart from that one can't likely do partial linking for an archive: $ g++ -no-pie -flto=auto --param=lto-partitions=16 -flinker-output=nolto-rel -r libbackend.a collect2: fatal error: ld terminated with signal 11 [Segmentation fault], core dumped compilation terminated. while ld.bfd immediately finishes. That gets you half of a LTO bootstrap then. So why did you go from applying this per-file to multiple files? Does $(LINKER) have a proper rule to pick up a jobserver? When upstreaming in any form you probably have to gate it on bootstrap-lto being not active. Sure, that's reasonable, we can likely detect a -flto option in $(COMPILE), right? One more thing I face is broken dependency: $ make clean && make -j32 PARTIAL_LTO=1 g++ -fcf-protection -fno-PIE -c -g -DIN_GCC -fPIC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -Wno-unused -DHAVE_CONFIG_H -I. -I. -I/home/marxin/Programming/gcc/gcc -I/home/marxin/Programming/gcc/gcc/. -I/home/marxin/Programming/gcc/gcc/../include -I/home/marxin/Programming/gcc/gcc/../libcpp/include -I/home/marxin/Programming/gcc/gcc/../libcody -I/home/marxin/Programming/gcc/gcc/../libdecnumber -I/home/marxin/Programming/gcc/gcc/../libdecnumber/bid -I../libdecnumber -I/home/marxin/Programming/gcc/gcc/../libbacktrace -o gimple-match-lto.o -MT gimple-match-lto.o -MMD -MP -MF ./.deps/gimple-match-lto.TPo gimple-match.c -flto g++ -fcf-protection -fno-PIE -c -g -DIN_GCC -fPIC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -Wno-unused -DHAVE_CONFIG_H -I. -I. -I/home/marxin/Programming/gcc/gcc -I/home/marxin/Programming/gcc/gcc/. -I/home/marxin/Programming/gcc/gcc/../include -I/home/marxin/Programming/gcc/gcc/../libcpp/include -I/home/marxin/Programming/gcc/gcc/../libcody -I/home/marxin/Programming/gcc/gcc/../libdecnumber -I/home/marxin/Programming/gcc/gcc/../libdecnumber/bid -I../libdecnumber -I/home/marxin/Programming/gcc/gcc/../libbacktrace -o generic-match-lto.o -MT generic-match-lto.o -MMD -MP -MF ./.deps/generic-match-lto.TPo generic-match.c -flto In file included from ./tm.h:26, from /home/marxin/Programming/gcc/gcc/backend.h:28, from /home/marxin/Programming/gcc/gcc/generic-match-head.c:23, from generic-match.c:4
Re: progress update after initial GSoC virtual meetup
On Sun, 2021-05-30 at 20:38 +0530, Ankur Saini wrote:
> hello
Hi Ankur, sorry about the delayed reply (it was a long weekend here in
the US)
> I was successfully able to build gcc with bootstrapping disabled and
> using xgcc directly from the build directory instead ( reducing the
> overall build time a lot, although it still takes about half an hour to
> build but it’s much faster than before ).
Excellent.
> Also I was also able to run one single test on the built compiler.
Great.
>
> Is there anything else I should be knowing to aid in development or
> should we start planing and preparing towards the project so that we
> can have a head start during coding phase ?
I tried brainstorming "what does a new contributor to GCC's analyzer
need to be able to do"; here's what I came up with:
- able to build the analyzer from source *quickly*, for hacking on the
code. i.e. with --disable-bootstrap. We want to minimize the time it
takes to, say, hack in a print statement into a single .cc file in the
analyzer subdirectory, rebuild, and rerun. With bootstrapping
disabled, if you run "make -jsome-number-of-cores" from the build
directory's "gcc" subdirectory, it should merely rebuild the .o file
for the .cc you touched, and do some relinking (and rerun the
selftests); hopefully such an edit should take less than a minute
before you're able to run the code and see the results.
It sounds like you're close to being able to do that.
(FWIW I tend to use gdb rather than putting in print statements, I tend
to hack in gcc_unreachable into conditions that I hope are being hit,
so that execution will stop at that point in gdb if my assumptions are
correct, and then I can print things, inject calls, etc in gdb)
- able to build the analyzer with a full bootstrap (--enable-bootstrap
is the default) and running the regression test suites ("make check -
jnumber-of-cores"), On the fastest box I have this (64 cores, 128 GB
ram) this takes about 45 minutes to do the build and about 45 minutes
to do the testsuites; it used to take up to three hours total when I
was running it on a laptop (and thus was a major pain as it's no fun to
have a hot noisy laptop for several hours). Maybe it's best to have an
account on the GCC compile farm for this:
https://gcc.gnu.org/wiki/CompileFarm
IIRC you already have such an account. It might be worth trying out a
full bootstrap and testsuite run on one of the powerful machines in the
farm. I tend to use "screen" in case my ssh connection drops during
through a build, so that losing the ssh connection doesn't kill the
build.
- able to step through the code in the debugger. IIRC you've already
been doing that.
- copyright assignment paperwork to the FSF. IIRC you've already done
that.
- ability to run just a single test in the testsuite, rather than the
whole lot (so that you can easily develop new tests without having to
run everything each time you make an edit to a test). As you say
above, you've done that.
- the analyzer has testcases for C, C++ and Fortran, so you might want
to figure out the argument you need for --enable-languages= when
configuring GCC to enable those languages (but probably no others when
hacking, to speed of rebuilding GCC). Obviously you'll need C++, as
C++ support is the point of your project.
- it might be good to create a personal branch on the gcc git
repository that you can push your work to. I'm in two minds about
this, in that ideally you'd just commit your work to trunk once each
patch is approved, but maybe it's good to have a public place as a
backup of the "under development" stuff? Also, at some point we want
you to be pushing changes to the trunk, so we'll want your account to
be able to do that.
I hope all the above makes sense. Don't hesitate to ask questions;
finding things out is the whole point of this part of the GSoC
schedule.
Can anyone think of something else that's worth sorting out in this
preliminary phase?
I don't think you're meant to be spending more than an hour or so a
week in this preliminary phase until the coding period officially
starts on Monday 7th.
If you're *really* eager to start, you might want to look at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100546
This is a case where the analyzer "sees" a call through a function
pointer, and, despite figuring out what the function pointer actually
points to, entirely fails to properly handle the call, since the
supergraph and engine.cc code is looking at the static callgraph, and
needs work to handle such calls through function pointers. I started
debugging this a couple of weeks ago, and realized it has a *lot* of
similarities to the vtable case, so thought I might leave it so you can
have a go at it once the project starts properly. That said, before
the 7th you're meant to be focusing on schoolwork, I think, so we
really ought to be merely just sorting out accounts, ensuring your
coding environment is set up, etc.
Hope this is helpful
Dave
Re: GCC documentation: porting to Sphinx
Hello, On Tue, 1 Jun 2021, Martin Liška wrote: > On 5/31/21 5:49 PM, Michael Matz wrote: > > Hello Martin, > > > > On Mon, 31 May 2021, Martin Liška wrote: > > > >> I've made quite some progress with the porting of the documentation and > >> I would like to present it to the community now: > >> https://splichal.eu/scripts/sphinx/ > >> Note the documentation is automatically ([1]) generated from texinfo with > >> a > >> GitHub workflow ([2]). > > > > One other thing I was recently thinking about, in the Spinx vs. texinfo > > discussion: locally available documentation browsable/searchable in > > terminal with info(1) (or equivalents). > > Yes, that's handy. > > > I think the above (i.e. generating .rst from the texinfo file) would > > immediately nullify all my worries. So, just to be extra sure: your > > proposal now is to generate the .rst files, and that .texinfo remains > > the maintained sources, right? > > No, .texinfo files will be gone. However, Sphinx can output to info > format: > https://www.sphinx-doc.org/en/master/man/sphinx-build.html#cmdoption-sphinx-build-M I see, that's good to hear. > And I've just added the generated Info pages here: > https://splichal.eu/scripts/sphinx/ Okay, but there's something amiss, just compare a local gcc.info with that. The sphinx generated one seems to only contain command line options, but none of the other topics, in particular it seems to contain the "Invoking GCC" chapter (and only that) as top-level, and all other ones are missing (like "C implementation", "C++ implementation", "C extension", and so on). Looking at gccint.info I also seem quite some confusion, it's unclear to me if content is missing or not. But e.g. the top-level structure has a different order (a less logical one, this one is btw. shared with the order of the HTML generated docu, so it's probably specific to sphinx setup or such). Ignoring that missing content what is there right now does seem somewhat acceptable for local use, though. Ciao, Michael.
Update to GCC copyright assignment policy
GCC was created as part of the GNU Project but has grown to operate as an autonomous project. The GCC Steering Committee has decided to relax the requirement to assign copyright for all changes to the Free Software Foundation. GCC will continue to be developed, distributed, and licensed under the GNU General Public License v3.0. GCC will now accept contributions with or without an FSF copyright assignment. This change is consistent with the practices of many other major Free Software projects, such as the Linux kernel. Contributors who have an FSF Copyright Assignment don't need to change anything. Contributors who wish to utilize the Developer Certificate of Origin[1] should add a Signed-off-by message to their commit messages. Developers with commit access may add their name to the DCO list in the MAINTAINERS file to certify the DCO for all future commits in lieu of individual Signed-off-by messages for each commit. The GCC Steering Committee continues to affirm the principles of Free Software, and that will never change. - The GCC Steering Committee [1] https://developercertificate.org/
unsubscribe
> -Original Message-
> From: gcc-announce On Behalf Of Richard
> Biener
> Sent: Tuesday, June 01, 2021 4:42 AM
> To: gcc-annou...@gcc.gnu.org; gcc@gcc.gnu.org; info-...@gnu.org
> Subject: [EXT] GCC 9.4 Released
>
> [Actual Sender is gcc-announce-boun...@gcc.gnu.org]
>
> The GNU Compiler Collection version 9.4 has been released.
>
> GCC 9.4 is a bug-fix release from the GCC 9 branch containing important
> fixes for regressions and serious bugs in GCC 9.3 with more than 190 bugs
> fixed since the previous release.
>
> This release is available from the WWW and FTP servers listed here:
>
> https://sourceware.org/pub/gcc/releases/gcc-9.4.0/
> https://gcc.gnu.org/mirrors.html
>
>
> Please do not contact me directly regarding questions or comments
> about this release. Instead, use the resources available from
> http://gcc.gnu.org.
>
> As always, a vast number of people contributed to this GCC release
> -- far too many to thank them individually!
Confidentiality Notice: This electronic message transmission, including any
attachment(s), may contain confidential, proprietary, or privileged information
from CAS, a division of the American Chemical Society ("ACS"). If you have
received this transmission in error, be advised that any disclosure, copying,
distribution, or use of the contents of this information is strictly
prohibited. Please destroy all copies of the message and contact the sender
immediately by either replying to this message or calling 614-447-3600.
Re: Update to GCC copyright assignment policy
On Tue, Jun 01, 2021 at 10:00:06AM -0400, David Edelsohn via Gcc wrote: > GCC was created as part of the GNU Project but has grown to operate as > an autonomous project. > > The GCC Steering Committee has decided to relax the requirement to > assign copyright for all changes to the Free Software Foundation. GCC > will continue to be developed, distributed, and licensed under the GNU > General Public License v3.0. GCC will now accept contributions with or > without an FSF copyright assignment. This change is consistent with > the practices of many other major Free Software projects, such as the > Linux kernel. > > Contributors who have an FSF Copyright Assignment don't need to > change anything. Contributors who wish to utilize the Developer Certificate > of Origin[1] should add a Signed-off-by message to their commit messages. > Developers with commit access may add their name to the DCO list in the > MAINTAINERS file to certify the DCO for all future commits in lieu of > individual > Signed-off-by messages for each commit. > > The GCC Steering Committee continues to affirm the principles of Free > Software, and that will never change. What does this mean for the source file comments? Do we continue using contrib/update-copyright.py --this-year to update the FSF copyright notices? When a new source file (that has copyright boilerplate, not say some small testcase) is added by somebody submitting their work under FSF copyright assignment, shall the Copyright (C) 2021 Free Software Foundation, Inc. be added? What about when such a new source file is added by somebody submitting their work under DCO? Shall they list Copyright (C) 2021 John Doe or something else (note, update-copyright.py would need all such copyright lines in it). If yes and later on somebody with FSF copyright assignment modifies that, shall the Copyright (C) 2021 Free Software Foundation, Inc. line be added? Can contributors with FSF Copyright Assignment on file (or those working for companies with company wide ones) assign all their further work or just selected commits under DCO? Jakub
Re: Update to GCC copyright assignment policy
* David Edelsohn via Gcc: > GCC was created as part of the GNU Project but has grown to operate as > an autonomous project. > > The GCC Steering Committee has decided to relax the requirement to > assign copyright for all changes to the Free Software Foundation. GCC > will continue to be developed, distributed, and licensed under the GNU > General Public License v3.0. GCC will now accept contributions with or > without an FSF copyright assignment. This change is consistent with > the practices of many other major Free Software projects, such as the > Linux kernel. What about the parts of GCC with FSF copyrights that are not covered by the GPL, but the GPL with exceptions? How is it possible to move code between the parts if a contributor previously used DCO and thus gave only permission to license under the open source license “indicated in the file”? Thanks, Florian
Re: Update to GCC copyright assignment policy
Hi David, On Tue, 2021-06-01 at 10:00 -0400, David Edelsohn via Gcc wrote: > The GCC Steering Committee has decided to relax the requirement to > assign copyright for all changes to the Free Software Foundation. GCC > will continue to be developed, distributed, and licensed under the GNU > General Public License v3.0. GCC will now accept contributions with or > without an FSF copyright assignment. This change is consistent with > the practices of many other major Free Software projects, such as the > Linux kernel. > > Contributors who have an FSF Copyright Assignment don't need to > change anything. Contributors who wish to utilize the Developer Certificate > of Origin[1] should add a Signed-off-by message to their commit messages. > Developers with commit access may add their name to the DCO list in the > MAINTAINERS file to certify the DCO for all future commits in lieu of > individual > Signed-off-by messages for each commit. This seems a pretty bad policy to be honest. Why was there no public discussion on this? I certainly understand not wanting to assign copyright to the FSF anymore given the recent board decisions. But changing GCC from having a shared copyright pool to having lots of individual (or company?) copyright holders seems like a regression for a strong copyleft project. With individual copyright holders companies no longer have clear way to know whether they are in compliance unless they talk to each and every individual copyright holder (see also the linux kernel, where there are some individuals who randomly sue companies just to get some money to drop the lawsuit). And for users it will be harder to get compliant sources if they can no longer simply ask the shared copyright holder, but instead will have to get enough individual copyright holders to get a distributor into compliance. If we no longer want the FSF to be the legal guardian and copyright holder for GCC could we please find another legal entity that performs that role and helps us as a project with copyleft compliance? I would be happy to setup a shared copyright pool under the Conservancy Copyleft Compliance project for example: https://sfconservancy.org/copyleft-compliance/ Thanks, Mark
Re: Update to GCC copyright assignment policy
On Tue, Jun 1, 2021 at 10:15 AM Jakub Jelinek wrote: > > On Tue, Jun 01, 2021 at 10:00:06AM -0400, David Edelsohn via Gcc wrote: > > GCC was created as part of the GNU Project but has grown to operate as > > an autonomous project. > > > > The GCC Steering Committee has decided to relax the requirement to > > assign copyright for all changes to the Free Software Foundation. GCC > > will continue to be developed, distributed, and licensed under the GNU > > General Public License v3.0. GCC will now accept contributions with or > > without an FSF copyright assignment. This change is consistent with > > the practices of many other major Free Software projects, such as the > > Linux kernel. > > > > Contributors who have an FSF Copyright Assignment don't need to > > change anything. Contributors who wish to utilize the Developer Certificate > > of Origin[1] should add a Signed-off-by message to their commit messages. > > Developers with commit access may add their name to the DCO list in the > > MAINTAINERS file to certify the DCO for all future commits in lieu of > > individual > > Signed-off-by messages for each commit. > > > > The GCC Steering Committee continues to affirm the principles of Free > > Software, and that will never change. > > What does this mean for the source file comments? > > Do we continue using contrib/update-copyright.py --this-year to update > the FSF copyright notices? > > When a new source file (that has copyright boilerplate, not say some small > testcase) is added by somebody submitting their work under FSF copyright > assignment, shall the > Copyright (C) 2021 Free Software Foundation, Inc. > be added? > > What about when such a new source file is added by somebody submitting their > work under DCO? Shall they list > Copyright (C) 2021 John Doe > or something else (note, update-copyright.py would need all such copyright > lines in it). If yes and later on somebody with FSF copyright assignment > modifies that, shall the > Copyright (C) 2021 Free Software Foundation, Inc. > line be added? The copyright author will be listed as "Free Software Foundation, Inc." and/or "The GNU Toolchain Authors", as appropriate. > > Can contributors with FSF Copyright Assignment on file (or those working > for companies with company wide ones) assign all their further work or > just selected commits under DCO? The update to the policy does not negate any existing or future FSF copyright assignments -- it solely expands the options available. Individuals may add a Signed-off-by line or add their name to the DCO list in the MAINTAINERS file, but it doesn't change the legal framework for a contribution by an individual or company with a copyright assignment. Individuals and companies can choose how to proceed with their existing FSF copyright assignments. Individuals and companies may continue to establish new copyright assignments with the FSF. Thanks, David
Re: Update to GCC copyright assignment policy
> On Jun 1, 2021, at 10:31 AM, David Edelsohn via Gcc wrote: > > The copyright author will be listed as "Free Software Foundation, > Inc." and/or "The GNU Toolchain Authors", as appropriate. What does that mean? FSF is a well defined organization. "The GNU Toolchain Authors" sounds like one, but is it? Or is it just a label for "the set of contributors who have contributed without assigning to FSF"? In other words, who is the owner of such a work, the GTA, or the submitter? I'm guessing the latter. That seems to create a possible future complication. Prior to this change, the FSF (as owner of the copyright) could make changes such as replacing the GPL 2 license by GPL 3. With the policy change, that would no longer be possible, unless you get the approval of all the copyright holders. This may not be considered a problem, but it does seem like a change. I looked at gcc.gnu.org to find the updated policy. I don't think it's there; the "contribute" page wording still feels like the old policy. Given the change, it would seem rather important to have the implications spelled out in full, and the new rules clearly expressed. paul
Re: Update to GCC copyright assignment policy
On Tue, 2021-06-01 at 16:24 +0200, Florian Weimer via Gcc wrote: > * David Edelsohn via Gcc: > > > GCC was created as part of the GNU Project but has grown to operate as > > an autonomous project. > > > > The GCC Steering Committee has decided to relax the requirement to > > assign copyright for all changes to the Free Software Foundation. GCC > > will continue to be developed, distributed, and licensed under the GNU > > General Public License v3.0. GCC will now accept contributions with or > > without an FSF copyright assignment. This change is consistent with > > the practices of many other major Free Software projects, such as the > > Linux kernel. > > What about the parts of GCC with FSF copyrights that are not covered by > the GPL, but the GPL with exceptions? How is it possible to move code > between the parts if a contributor previously used DCO and thus gave > only permission to license under the open source license “indicated in > the file”? Depends on which DCO you uses. Various project use the following DCO, which makes clear you assign permissions under all applicable licenses (this helps if the project uses more than one, possibly incompatible, license and/or is dual licensed): Developer's Certificate of Origin By making a contribution to this project, I certify that: (a) The contribution was created in whole or in part by me, and I have the right to submit the contribution under each license indicated in, or otherwise designated as being applicable to, the file. (b) The contribution was provided directly to me by some other person who certified (a), and I have not modified it. (c) I understand and agree that the project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed. Cheers, Mark
Re: Update to GCC copyright assignment policy
GCC was created as part of the GNU Project but has grown to operate as an autonomous project. That is true for all GNU project. The GCC Steering Committee has decided to relax the requirement to assign copyright for all changes to the Free Software Foundation. GCC will continue to be developed, distributed, and licensed under the GNU General Public License v3.0. GCC will now accept contributions with or without an FSF copyright assignment. This change is consistent with the practices of many other major Free Software projects, such as the Linux kernel. The GCC steering committee is not in a position to make such a decision that is up to the GNU project head and the FSF legal counsel, it also fly against the mission statement. Not to mention that this was not discussed with anyone, including people in the GNU project.
Re: Update to GCC copyright assignment policy
| From: Mark Wielaard | This seems a pretty bad policy to be honest. | Why was there no public discussion on this? Agreed. I also agree with the rest of Mark's message. (Note: I haven't contributed to GCC but I have contributed to other copylefted code bases.) It is important that the pool be trustable. A tall order, but solvable, I think. Two pools (FSF for old stuff, something else, for new stuff if the contributor prefers) should be quite managable. This would allow, for example, moving to an updated copyleft if the two pools agreed. It is important that the governance of the pool be trustable. We've trusted the FSF and now some have qualms. A second pool would be a check on the power of the first pool. Individual unassigned copyright pretty much guarantees that the copyright terms can never be changed. I don't think that that is optimal.
Update to GCC copyright assignment policy
I am pleased to see a change based on my recommendation. The FSF should not refrain from accepting contributions based on modified versions of software in instances where the developer of the modified work is unable to get a copyright assignment of the code, but are legally allowed to use a compatible license without requiring copyright. - Christopher Dimech Society has became too quick to pass judgement and declare someone Persona Non-Grata, the most extreme form of censure a country can bestow. In a new era of destructive authoritarianism, I support Richard Stallman. Times of great crisis are also times of great opportunity. I call upon you to make this struggle yours as well ! https://stallmansupport.org/ https://www.fsf.org/ https://www.gnu.org/ > Sent: Wednesday, June 02, 2021 at 2:28 AM > From: "Mark Wielaard" > To: "David Edelsohn" , "GCC Development" > Subject: Re: Update to GCC copyright assignment policy > > Hi David, > > On Tue, 2021-06-01 at 10:00 -0400, David Edelsohn via Gcc wrote: > > The GCC Steering Committee has decided to relax the requirement to > > assign copyright for all changes to the Free Software Foundation. GCC > > will continue to be developed, distributed, and licensed under the GNU > > General Public License v3.0. GCC will now accept contributions with or > > without an FSF copyright assignment. This change is consistent with > > the practices of many other major Free Software projects, such as the > > Linux kernel. > > > > Contributors who have an FSF Copyright Assignment don't need to > > change anything. Contributors who wish to utilize the Developer Certificate > > of Origin[1] should add a Signed-off-by message to their commit messages. > > Developers with commit access may add their name to the DCO list in the > > MAINTAINERS file to certify the DCO for all future commits in lieu of > > individual > > Signed-off-by messages for each commit. > > This seems a pretty bad policy to be honest. > Why was there no public discussion on this? > > I certainly understand not wanting to assign copyright to the FSF > anymore given the recent board decisions. But changing GCC from having > a shared copyright pool to having lots of individual (or company?) > copyright holders seems like a regression for a strong copyleft > project. > > With individual copyright holders companies no longer have clear way to > know whether they are in compliance unless they talk to each and every > individual copyright holder (see also the linux kernel, where there are > some individuals who randomly sue companies just to get some money to > drop the lawsuit). And for users it will be harder to get compliant > sources if they can no longer simply ask the shared copyright holder, > but instead will have to get enough individual copyright holders to get > a distributor into compliance. > > If we no longer want the FSF to be the legal guardian and copyright > holder for GCC could we please find another legal entity that performs > that role and helps us as a project with copyleft compliance? > > I would be happy to setup a shared copyright pool under the Conservancy > Copyleft Compliance project for example: > https://sfconservancy.org/copyleft-compliance/ > > Thanks, > > Mark >
Re: Update to GCC copyright assignment policy
> > What about the parts of GCC with FSF copyrights that are not covered by > > the GPL, but the GPL with exceptions? How is it possible to move code > > between the parts if a contributor previously used DCO and thus gave > > only permission to license under the open source license "indicated in > > the file"? > > Depends on which DCO you uses. Various project use the following DCO, > which makes clear you assign permissions under all applicable licenses > (this helps if the project uses more than one, possibly incompatible, > license and/or is dual licensed): See above. The issue is if the project wants to change the status of a file from GPL to GPL plus exception. It can't do that if there was a change to the file made by somebody who did't assign the copyright. What's said in the DCO you cite doesn't help.
Re: Update to GCC copyright assignment policy
On Tue, Jun 1, 2021 at 10:52 AM D. Hugh Redelmeier wrote: > | From: Mark Wielaard > > | This seems a pretty bad policy to be honest. > | Why was there no public discussion on this? > > Agreed. I also agree with the rest of Mark's message. > > (Note: I haven't contributed to GCC but I have contributed to other > copylefted code bases.) > > It is important that the pool be trustable. A tall order, but > solvable, I think. > > Two pools (FSF for old stuff, something else, for new stuff if the > contributor prefers) should be quite managable. > > This would allow, for example, moving to an updated copyleft if the > two pools agreed. It is important that the governance of the pool be > trustable. > > We've trusted the FSF and now some have qualms. A second pool would > be a check on the power of the first pool. > > Individual unassigned copyright pretty much guarantees that the > copyright terms can never be changed. I don't think that that is > optimal. > GCC's license is "GPL version 3 or later", so if there ever needed to be a GPL v4, we could move to it without needing permission from anyone. But GPL3 has been a good license for GCC; giving up the theoretical ability to change the license (other than to a later GPL) does not seem like a significant loss. Jason
Re: Update to GCC copyright assignment policy
> GCC was created as part of the GNU Project but has grown to operate as > an autonomous project. > > The GCC Steering Committee has decided to relax the requirement to > assign copyright for all changes to the Free Software Foundation. GCC > will continue to be developed, distributed, and licensed under the GNU > General Public License v3.0. GCC will now accept contributions with or > without an FSF copyright assignment. This change is consistent with > the practices of many other major Free Software projects, such as the > Linux kernel. > > Contributors who have an FSF Copyright Assignment don't need to > change anything. Contributors who wish to utilize the Developer Certificate > of Origin[1] should add a Signed-off-by message to their commit messages. > Developers with commit access may add their name to the DCO list in the > MAINTAINERS file to certify the DCO for all future commits in lieu of > individual > Signed-off-by messages for each commit. > > The GCC Steering Committee continues to affirm the principles of Free > Software, and that will never change. > > - The GCC Steering Committee > > [1] https://developercertificate.org/ Eer, so you are changing the license of GCC from GPLv3+ to GPLv3 only?? Why current contributors (individuals and corporations) have not been consulted before making and implementing such important decisions? Corporations like my employer contribute to GCC under a certain legal setup. Changing the conditions under which the contributions happen is not something to be done unilaterally without a very good reason. The mere fact you have sent this email to a public mailing list means I have to get my management involved, and most probably lawyers too. What is the rationale after these changes anyway? I respectfully ask the GCC Steering Committee to suspend the implementation of these changes until the rationale and the practical consequences of changing the GCC contribution model and its license have been carefully thought, discussed and preferably consensuated among the GCC contributors and maintainers.
Re: Update to GCC copyright assignment policy
> On Jun 1, 2021, at 11:08 AM, Jason Merrill via Gcc wrote: > > On Tue, Jun 1, 2021 at 10:52 AM D. Hugh Redelmeier wrote: > >> | From: Mark Wielaard >> >> | This seems a pretty bad policy to be honest. >> | Why was there no public discussion on this? >> >> Agreed. I also agree with the rest of Mark's message. >> >> (Note: I haven't contributed to GCC but I have contributed to other >> copylefted code bases.) >> >> It is important that the pool be trustable. A tall order, but >> solvable, I think. >> >> Two pools (FSF for old stuff, something else, for new stuff if the >> contributor prefers) should be quite managable. >> >> This would allow, for example, moving to an updated copyleft if the >> two pools agreed. It is important that the governance of the pool be >> trustable. >> >> We've trusted the FSF and now some have qualms. A second pool would >> be a check on the power of the first pool. >> >> Individual unassigned copyright pretty much guarantees that the >> copyright terms can never be changed. I don't think that that is >> optimal. >> > > GCC's license is "GPL version 3 or later", so if there ever needed to be a > GPL v4, we could move to it without needing permission from anyone. I don't think that is what the license says. It says: GCC is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 3, or (at your option) any later version. To me that means the recipient of the software can relicense it under a later license. It doesn't say to me that the original distribution can do so. paul
Re: Update to GCC copyright assignment policy
On Tue, Jun 01, 2021 at 11:25:16AM -0400, Paul Koning via Gcc wrote: > GCC is free software; you can redistribute it and/or modify > it under the terms of the GNU General Public License as published by > the Free Software Foundation; either version 3, or (at your option) > any later version. > > To me that means the recipient of the software can relicense it under a later > license. It doesn't say to me that the original distribution can do so. IMHO that can be easily done by changing anything in the file under GPLv4+ license (if/when it exists). Because the user can then choose GPLv3+ for most of the source lines, but only GPLv4+ for those that changed, which implies GPLv4+ for the whole. Jakub
Re: Update to GCC copyright assignment policy
> What is the rationale after these changes anyway? Development of new features for libstdc++ has already moved away from gcc.gnu.org to avoid the copyright assignment. Other contributors have expressed a desire to do the same.
Re: Update to GCC copyright assignment policy
"Jose E. Marchesi via Gcc" writes: >> GCC was created as part of the GNU Project but has grown to operate as >> an autonomous project. >> >> The GCC Steering Committee has decided to relax the requirement to >> assign copyright for all changes to the Free Software Foundation. GCC >> will continue to be developed, distributed, and licensed under the GNU >> General Public License v3.0. GCC will now accept contributions with or >> without an FSF copyright assignment. This change is consistent with >> the practices of many other major Free Software projects, such as the >> Linux kernel. >> >> Contributors who have an FSF Copyright Assignment don't need to >> change anything. Contributors who wish to utilize the Developer Certificate >> of Origin[1] should add a Signed-off-by message to their commit messages. >> Developers with commit access may add their name to the DCO list in the >> MAINTAINERS file to certify the DCO for all future commits in lieu of >> individual >> Signed-off-by messages for each commit. >> >> The GCC Steering Committee continues to affirm the principles of Free >> Software, and that will never change. >> >> - The GCC Steering Committee >> >> [1] https://developercertificate.org/ > > Eer, so you are changing the license of GCC from GPLv3+ to GPLv3 only?? > > Why current contributors (individuals and corporations) have not been > consulted before making and implementing such important decisions? Can't agree more. Critiquing FSF for lack of process transparency and at the same time implementing such a drastic change with zero involvement of the community sounds bizzarre to me to say the least. [...] > I respectfully ask the GCC Steering Committee to suspend the > implementation of these changes until the rationale and the practical > consequences of changing the GCC contribution model and its license have > been carefully thought, discussed and preferably consensuated among the > GCC contributors and maintainers. Quote. Best Regards. Andrea
Re: Update to GCC copyright assignment policy
Paul Koning via Gcc writes: >> GCC's license is "GPL version 3 or later", so if there ever needed to be a >> GPL v4, we could move to it without needing permission from anyone. > > I don't think that is what the license says. It says: > > GCC is free software; you can redistribute it and/or modify > it under the terms of the GNU General Public License as published by > the Free Software Foundation; either version 3, or (at your option) > any later version. > > To me that means the recipient of the software can relicense it under > a later license. It doesn't say to me that the original distribution > can do so. I've never read it that way. To me it says "a recipient may redistribute it under terms of a newer license, but the license remains v3+ even if they do" - we're giving the recipient a choice of actions, but not power to relicense. I.e. a recipient is not permitted to relicense the code, ever. However, they may act as if it's licensed under a newer license. If they share the code, *that* recipient gets to make the same choice - v3 or newer. So if the original copyright holder can't change the license, nobody can.
Re: Update to GCC copyright assignment policy
On Tue, Jun 1, 2021 at 11:14 AM Jose E. Marchesi wrote: > > > > GCC was created as part of the GNU Project but has grown to operate as > > an autonomous project. > > > > The GCC Steering Committee has decided to relax the requirement to > > assign copyright for all changes to the Free Software Foundation. GCC > > will continue to be developed, distributed, and licensed under the GNU > > General Public License v3.0. GCC will now accept contributions with or > > without an FSF copyright assignment. This change is consistent with > > the practices of many other major Free Software projects, such as the > > Linux kernel. > > > > Contributors who have an FSF Copyright Assignment don't need to > > change anything. Contributors who wish to utilize the Developer Certificate > > of Origin[1] should add a Signed-off-by message to their commit messages. > > Developers with commit access may add their name to the DCO list in the > > MAINTAINERS file to certify the DCO for all future commits in lieu of > > individual > > Signed-off-by messages for each commit. > > > > The GCC Steering Committee continues to affirm the principles of Free > > Software, and that will never change. > > > > - The GCC Steering Committee > > > > [1] https://developercertificate.org/ > > Eer, so you are changing the license of GCC from GPLv3+ to GPLv3 only?? The current, active license in GPL v3.0. This is not an announcement of any change in license. Quoting Jason Merrill: "GCC's license is "GPL version 3 or later", so if there ever needed to be a GPL v4, we could move to it without needing permission from anyone." Thanks, David
Re: Update to GCC copyright assignment policy
On Tue, 1 Jun 2021, Paul Koning via Gcc wrote: > That seems to create a possible future complication. Prior to this > change, the FSF (as owner of the copyright) could make changes such as > replacing the GPL 2 license by GPL 3. With the policy change, that > would no longer be possible, unless you get the approval of all the > copyright holders. This may not be considered a problem, but it does > seem like a change. It is a real problem. As I recall a while ago parts of QEMU had to be removed and reimplemented from scratch when the project switched licences, because a contributor and therefore a copyright holder (whom I knew in person and who I am sure would make no fuss about it) has since passed away. Maciej
Re: Update to GCC copyright assignment policy
> What is the rationale after these changes anyway? Development of new features for libstdc++ has already moved away from gcc.gnu.org to avoid the copyright assignment. Other contributors have expressed a desire to do the same. >From the GCC mission statement: - Other components (runtime libraries, testsuites, etc) will be available under various free licenses with copyrights being held by individual authors or the FSF. So that cannot be the rationale for this.
Re: Update to GCC copyright assignment policy
On Tue, Jun 1, 2021 at 11:15 AM Jose E. Marchesi via Gcc wrote: > > > GCC was created as part of the GNU Project but has grown to operate as > > an autonomous project. > > > > The GCC Steering Committee has decided to relax the requirement to > > assign copyright for all changes to the Free Software Foundation. GCC > > will continue to be developed, distributed, and licensed under the GNU > > General Public License v3.0. GCC will now accept contributions with or > > without an FSF copyright assignment. This change is consistent with > > the practices of many other major Free Software projects, such as the > > Linux kernel. > > > > Contributors who have an FSF Copyright Assignment don't need to > > change anything. Contributors who wish to utilize the Developer > Certificate > > of Origin[1] should add a Signed-off-by message to their commit messages. > > Developers with commit access may add their name to the DCO list in the > > MAINTAINERS file to certify the DCO for all future commits in lieu of > individual > > Signed-off-by messages for each commit. > > > > The GCC Steering Committee continues to affirm the principles of Free > > Software, and that will never change. > > > > - The GCC Steering Committee > > > > [1] https://developercertificate.org/ > > Eer, so you are changing the license of GCC from GPLv3+ to GPLv3 only?? > No, there is no change in the license. > Why current contributors (individuals and corporations) have not been > consulted before making and implementing such important decisions? > Corporations like my employer contribute to GCC under a certain legal > setup. Changing the conditions under which the contributions happen is > not something to be done unilaterally without a very good reason. The > mere fact you have sent this email to a public mailing list means I have > to get my management involved, and most probably lawyers too. > Your employer is very welcome to continue to contribute under the same legal setup. Derived versions of GCC could already include code that was not assigned to the FSF; even the official GCC distribution itself has long included non-FSF-assigned code in various runtime libraries. The change is that now we will also be able to incorporate such code into the source code repository for the compiler. Jason
Re: Update to GCC copyright assignment policy
>> > GCC was created as part of the GNU Project but has grown to operate as >> > an autonomous project. >> > >> > The GCC Steering Committee has decided to relax the requirement to >> > assign copyright for all changes to the Free Software Foundation. GCC >> > will continue to be developed, distributed, and licensed under the GNU >> > General Public License v3.0. GCC will now accept contributions with or >> > without an FSF copyright assignment. This change is consistent with >> > the practices of many other major Free Software projects, such as the >> > Linux kernel. >> > >> > Contributors who have an FSF Copyright Assignment don't need to >> > change anything. Contributors who wish to utilize the Developer >> > Certificate >> > of Origin[1] should add a Signed-off-by message to their commit messages. >> > Developers with commit access may add their name to the DCO list in the >> > MAINTAINERS file to certify the DCO for all future commits in lieu of >> > individual >> > Signed-off-by messages for each commit. >> > >> > The GCC Steering Committee continues to affirm the principles of Free >> > Software, and that will never change. >> > >> > - The GCC Steering Committee >> > >> > [1] https://developercertificate.org/ >> >> Eer, so you are changing the license of GCC from GPLv3+ to GPLv3 only?? > > The current, active license in GPL v3.0. This is not an announcement > of any change in license. Thanks for confirming.
Re: Update to GCC copyright assignment policy
On Tue, Jun 1, 2021 at 10:40 AM Paul Koning wrote: > > > On Jun 1, 2021, at 10:31 AM, David Edelsohn via Gcc wrote: > > > > The copyright author will be listed as "Free Software Foundation, > > Inc." and/or "The GNU Toolchain Authors", as appropriate. > > What does that mean? FSF is a well defined organization. "The GNU Toolchain > Authors" sounds like one, but is it? Or is it just a label for "the set of > contributors who have contributed without assigning to FSF"? In other words, > who is the owner of such a work, the GTA, or the submitter? I'm guessing the > latter. > > That seems to create a possible future complication. Prior to this change, > the FSF (as owner of the copyright) could make changes such as replacing the > GPL 2 license by GPL 3. With the policy change, that would no longer be > possible, unless you get the approval of all the copyright holders. This may > not be considered a problem, but it does seem like a change. > > I looked at gcc.gnu.org to find the updated policy. I don't think it's > there; the "contribute" page wording still feels like the old policy. Given > the change, it would seem rather important to have the implications spelled > out in full, and the new rules clearly expressed. The GNU Toolchain Authors are all of the authors, including those with FSF Copyright. All of the authors agree to the existing license, which is "...either version 3, or (at your option) any later version." If the project chooses to adopt a future update to the GPL, all of the authors have given permission through the existing copyright assignment or through certification of the DCO to utilize the newer license. Thanks, David
Update to GCC copyright assignment policy
> Sent: Wednesday, June 02, 2021 at 4:01 AM > From: "Maciej W. Rozycki" > To: "Paul Koning" > Cc: "Jakub Jelinek" , "GCC Development" > Subject: Re: Update to GCC copyright assignment policy > > On Tue, 1 Jun 2021, Paul Koning via Gcc wrote: > > > That seems to create a possible future complication. Prior to this > > change, the FSF (as owner of the copyright) could make changes such as > > replacing the GPL 2 license by GPL 3. With the policy change, that > > would no longer be possible, unless you get the approval of all the > > copyright holders. This may not be considered a problem, but it does > > seem like a change. > > It is a real problem. As I recall a while ago parts of QEMU had to be > removed and reimplemented from scratch when the project switched licences, > because a contributor and therefore a copyright holder (whom I knew in > person and who I am sure would make no fuss about it) has since passed > away. > > Maciej That assumes that one wants to use the original developer version. But if a maintainer wants to include and support that piece of code for some particular reason, he should be able to do it. A free software license should not stop us from using the code, whether he died or not. Indeed the licensing is there to avoid such problems. It is also legally enforceable. It was one of wy arguments in favour. - Christopher Dimech Society has became too quick to pass judgement and declare someone Persona Non-Grata, the most extreme form of censure a country can bestow. In a new era of destructive authoritarianism, I support Richard Stallman. Times of great crisis are also times of great opportunity. I call upon you to make this struggle yours as well ! https://stallmansupport.org/ https://www.fsf.org/ https://www.gnu.org/
Re: Update to GCC copyright assignment policy
On Tue, 2021-06-01 at 11:50 -0400, David Edelsohn via Gcc wrote: > The current, active license in GPL v3.0. This is not an announcement > of any change in license. > > Quoting Jason Merrill: > > "GCC's license is "GPL version 3 or later", so if there ever needed > to be a GPL v4, we could move to it without needing permission from > anyone." It depends on what you mean by "move to it". It's true that anyone could redistribute it under GPLv4. What's not true is that you can *change the license*. For example you can't change the current wording of the license from "GPL version 3 or later" to "GPL version 4 or later". Or make any other changes to the license, without collecting approval from all copyright holders. So, if there should be some issue with GPLv3 so that you really want to stop using it (maybe a court case is decided which negates a significant element of GPLv3 and GPLv4 is released to address the issue), it won't be possible to do that easily. Someone else mentioned that new code could be released only under that license so that in effect the entirety of the codebase becomes GPLv4+. I'm not sure about that. Doing that for brand new files that were created solely by one person who wanted to use GPLv4 or later only would work I suppose. But adding changes to an existing file that was GPLv3+ and saying that these new changes are GPLv4+ would be pretty gross. You might have to list both licenses in these files, since you can't change the previously-in-use license unless you get agreement from the FSF, who currently holds the license, plus anyone else who changed the file since the assignment was relaxed. Personally I think that while assignment is a PITA and I wish it were easier, it is extremely valuable and provides a lot of flexibility, and shouldn't be abandoned without very, VERY careful consideration. And, that decision and those considerations should be documented and the responses to the issues raised here published for everyone to see.
Re: Update to GCC copyright assignment policy
>> > GCC was created as part of the GNU Project but has grown to operate as >> > an autonomous project. >> > >> > The GCC Steering Committee has decided to relax the requirement to >> > assign copyright for all changes to the Free Software Foundation. GCC >> > will continue to be developed, distributed, and licensed under the GNU >> > General Public License v3.0. GCC will now accept contributions with or >> > without an FSF copyright assignment. This change is consistent with >> > the practices of many other major Free Software projects, such as the >> > Linux kernel. >> > >> > Contributors who have an FSF Copyright Assignment don't need to >> > change anything. Contributors who wish to utilize the Developer >> Certificate >> > of Origin[1] should add a Signed-off-by message to their commit messages. >> > Developers with commit access may add their name to the DCO list in the >> > MAINTAINERS file to certify the DCO for all future commits in lieu of >> individual >> > Signed-off-by messages for each commit. >> > >> > The GCC Steering Committee continues to affirm the principles of Free >> > Software, and that will never change. >> > >> > - The GCC Steering Committee >> > >> > [1] https://developercertificate.org/ >> >> Eer, so you are changing the license of GCC from GPLv3+ to GPLv3 only?? >> > > No, there is no change in the license. Ok, then please consider changing "GCC will continue to be developed, distributed, and licensed under the GNU General Public License v3.0" to "GCC will continue to be developed, distributed, and licensed under the GNU General Public License v3.0 or any later version as published by the Free Software Foundation." in your announcement (in case you are publishing it somewhere else) to avoid misunderstandings.
Re: Update to GCC copyright assignment policy
On Tue, 1 Jun 2021, DJ Delorie via Gcc wrote: > > GCC is free software; you can redistribute it and/or modify > > it under the terms of the GNU General Public License as published by > > the Free Software Foundation; either version 3, or (at your option) > > any later version. > > > > To me that means the recipient of the software can relicense it under > > a later license. It doesn't say to me that the original distribution > > can do so. > > I've never read it that way. To me it says "a recipient may > redistribute it under terms of a newer license, but the license remains > v3+ even if they do" - we're giving the recipient a choice of actions, > but not power to relicense. My interpretation of this would be for modifications rather than original sources, so v3+ applies to unmodified sources (for obvious reasons, given that the recipient of the sources is not a copyright holder), however as a copyright holder I can release my modifications say under v4 or v4+. It is unclear to me if the newer licence will then "stick" to the rest of the sources, but I suspect it will. A copyright assignment made to FSF (or another legal entity) prevents this complication from happening. Maciej
Re: Update to GCC copyright assignment policy
On Tue, 1 Jun 2021, Christopher Dimech wrote: > > It is a real problem. As I recall a while ago parts of QEMU had to be > > removed and reimplemented from scratch when the project switched licences, > > because a contributor and therefore a copyright holder (whom I knew in > > person and who I am sure would make no fuss about it) has since passed > > away. > > That assumes that one wants to use the original developer version. But if a > maintainer > wants to include and support that piece of code for some particular reason, > he should be > able to do it. A free software license should not stop us from using the > code, whether he > died or not. Indeed the licensing is there to avoid such problems. It is > also legally > enforceable. It was one of wy arguments in favour. You can use and modify original code under the terms of the original licence (provided it permitted it), but you cannot change the licence, because you are not a copyright holder for that piece of code. Maciej
Update to GCC copyright assignment policy
> Sent: Wednesday, June 02, 2021 at 4:09 AM > From: "Paul Smith" > To: gcc@gcc.gnu.org > Subject: Re: Update to GCC copyright assignment policy > > On Tue, 2021-06-01 at 11:50 -0400, David Edelsohn via Gcc wrote: > > The current, active license in GPL v3.0. This is not an announcement > > of any change in license. > > > > Quoting Jason Merrill: > > > > "GCC's license is "GPL version 3 or later", so if there ever needed > > to be a GPL v4, we could move to it without needing permission from > > anyone." > > It depends on what you mean by "move to it". > > It's true that anyone could redistribute it under GPLv4. > > What's not true is that you can *change the license*. For example you > can't change the current wording of the license from "GPL version 3 or > later" to "GPL version 4 or later". Or make any other changes to the > license, without collecting approval from all copyright holders. > > So, if there should be some issue with GPLv3 so that you really want to > stop using it (maybe a court case is decided which negates a > significant element of GPLv3 and GPLv4 is released to address the > issue), it won't be possible to do that easily. > > Someone else mentioned that new code could be released only under that > license so that in effect the entirety of the codebase becomes GPLv4+. > > I'm not sure about that. Doing that for brand new files that were > created solely by one person who wanted to use GPLv4 or later only > would work I suppose. But adding changes to an existing file that was > GPLv3+ and saying that these new changes are GPLv4+ would be pretty > gross. You might have to list both licenses in these files, since you > can't change the previously-in-use license unless you get agreement > from the FSF, who currently holds the license, plus anyone else who > changed the file since the assignment was relaxed. You can actually re-license with another compatible license. GPLv3+ would allow you to re-license the code as GPLv4+ You do not have to keep all the previous licenses because the intention of the gpl is to give back to users those rights which copyright would otherwise withold. > Personally I think that while assignment is a PITA and I wish it were > easier, it is extremely valuable and provides a lot of flexibility, and > shouldn't be abandoned without very, VERY careful consideration. > > And, that decision and those considerations should be documented and > the responses to the issues raised here published for everyone to see. > - Christopher Dimech Society has became too quick to pass judgement and declare someone Persona Non-Grata, the most extreme form of censure a country can bestow. In a new era of destructive authoritarianism, I support Richard Stallman. Times of great crisis are also times of great opportunity. I call upon you to make this struggle yours as well ! https://stallmansupport.org/ https://www.fsf.org/ https://www.gnu.org/
Re: Update to GCC copyright assignment policy
> So that cannot be the rationale for this. I do not want to contribute my work to a project that requires FSF copyright assignment to the rest of the project, even if it wouldn't be required for (some of) my own contributions. In any case, historically libstdc++ *does* require an assignment. If you were even slightly familiar with the project you might know that.
Re: Update to GCC copyright assignment policy
But GPL3 has been a good license for GCC; giving up the theoretical ability to change the license (other than to a later GPL) does not seem like a significant loss. That will cause trouble incorperating code or documentation snippets from the code base into the GCC manual; which is not under the GNU GPL. As it is, the FSF can and does give such permission to relicense bits and bobs -- now you've entierly lost that ability. The other loss is that parts cannot be relicensed under say the Lesser GPL for whatever reasons, incase a library might be more useful outside of GCC. The FSF has always been open to create special exemptions to the copyright assignment process. This is just all ill thought, and clearly shown by the lack of any discussion with anyone.
Re: Update to GCC copyright assignment policy
"Maciej W. Rozycki" writes: > My interpretation of this would be for modifications rather than original > sources, so v3+ applies to unmodified sources (for obvious reasons, given > that the recipient of the sources is not a copyright holder), however as a > copyright holder I can release my modifications say under v4 or v4+. It > is unclear to me if the newer licence will then "stick" to the rest of the > sources, but I suspect it will. A copyright assignment made to FSF (or > another legal entity) prevents this complication from happening. I see two cases here: 1. You release a modified copy of gcc, your parts can be whatever you want, sure, as long as it's GPLv3 compatible. 2. You're contributing *to* gcc, in which case, I'd hope that any attempts to impose a different license would be rejected at the patch review step.
Re: Update to GCC copyright assignment policy
> On Jun 1, 2021, at 12:09 PM, David Edelsohn via Gcc wrote: > > On Tue, Jun 1, 2021 at 10:40 AM Paul Koning wrote: >> >>> On Jun 1, 2021, at 10:31 AM, David Edelsohn via Gcc wrote: >>> >>> The copyright author will be listed as "Free Software Foundation, >>> Inc." and/or "The GNU Toolchain Authors", as appropriate. >> >> What does that mean? FSF is a well defined organization. "The GNU >> Toolchain Authors" sounds like one, but is it? Or is it just a label for >> "the set of contributors who have contributed without assigning to FSF"? In >> other words, who is the owner of such a work, the GTA, or the submitter? >> I'm guessing the latter. >> >> That seems to create a possible future complication. Prior to this change, >> the FSF (as owner of the copyright) could make changes such as replacing the >> GPL 2 license by GPL 3. With the policy change, that would no longer be >> possible, unless you get the approval of all the copyright holders. This >> may not be considered a problem, but it does seem like a change. >> >> I looked at gcc.gnu.org to find the updated policy. I don't think it's >> there; the "contribute" page wording still feels like the old policy. Given >> the change, it would seem rather important to have the implications spelled >> out in full, and the new rules clearly expressed. > > The GNU Toolchain Authors are all of the authors, including those with > FSF Copyright. All of the authors agree to the existing license, > which is "...either version 3, or (at your option) any later version." > If the project chooses to adopt a future update to the GPL, all of > the authors have given permission through the existing copyright > assignment or through certification of the DCO to utilize the newer > license. > > Thanks, David By DCO do you mean the document you linked in your original annoucement? If yes, could you point out which of the words in that document give the GCC project permission from the copyright holder to relicense the contributed work? I do not see those words in the document you linked. I get the feeling that the current change was rushed and not well considered. It certainly has that feel. I do not remember discussion of it, I do not see updated policy documents on the gcc.gnu.org website. The discussion just now is raising a pile of questions which are being answered with a whole bunch of different answers, not all consistent with each other. If the change had been carefully made this would not be happening; there would instead be a known answer (the outcome of prior discussion) and there would be published policies that could be pointed to where those answers are explicitly stated. It's not that I object to the spirit of the change, and I have contributed to a number of open source projects where there is no copyright assignment so that isn't a strange thing to me. What concerns me is a disruptive change made with what seems to me to be inadequate care. paul
Re: Update to GCC copyright assignment policy
On Tue, 1 Jun 2021, David Edelsohn via Gcc wrote: > The copyright author will be listed as "Free Software Foundation, > Inc." and/or "The GNU Toolchain Authors", as appropriate. And copyright notices naming "The GNU Toolchain Authors" should not include a date - that's following the recommendations at https://www.linuxfoundation.org/en/blog/copyright-notices-in-open-source-software-projects/ for the form of copyright notices in projects with many copyright holders. -- Joseph S. Myers jos...@codesourcery.com
Re: Update to GCC copyright assignment policy
> On Jun 1, 2021, at 12:44 PM, Joseph Myers wrote: > > On Tue, 1 Jun 2021, David Edelsohn via Gcc wrote: > >> The copyright author will be listed as "Free Software Foundation, >> Inc." and/or "The GNU Toolchain Authors", as appropriate. > > And copyright notices naming "The GNU Toolchain Authors" should not > include a date - that's following the recommendations at > https://www.linuxfoundation.org/en/blog/copyright-notices-in-open-source-software-projects/ > > for the form of copyright notices in projects with many copyright holders. > > -- > Joseph S. Myers > jos...@codesourcery.com That's a nice document, but it makes clear that a collective designation of a group of authors in a copyright notice is just a convenient shorthand. It mentions that the copyright notice is just a notice that doesn't actually affect the copyright (which remains with the individual authors or their employers, unless assigned). So "GNU Toolchain Authors" is a description referring to a set of individual owners, one that changes over time. It doesn't describe a legal body, and it isn't an owner of anything. paul
Update to GCC copyright assignment policy
> Sent: Wednesday, June 02, 2021 at 4:24 AM > From: "Maciej W. Rozycki" > To: "Christopher Dimech" > Cc: "Paul Koning" , "Jakub Jelinek" > , "GCC Development" > Subject: Re: Update to GCC copyright assignment policy > > On Tue, 1 Jun 2021, Christopher Dimech wrote: > > > > It is a real problem. As I recall a while ago parts of QEMU had to be > > > removed and reimplemented from scratch when the project switched licences, > > > because a contributor and therefore a copyright holder (whom I knew in > > > person and who I am sure would make no fuss about it) has since passed > > > away. > > > > That assumes that one wants to use the original developer version. But if > > a maintainer > > wants to include and support that piece of code for some particular reason, > > he should be > > able to do it. A free software license should not stop us from using the > > code, whether he > > died or not. Indeed the licensing is there to avoid such problems. It is > > also legally > > enforceable. It was one of wy arguments in favour. > > You can use and modify original code under the terms of the original > licence (provided it permitted it), but you cannot change the licence, > because you are not a copyright holder for that piece of code. > > Maciej You can change it as much as the license allows you. The gpl is intended to give you back all the rights taken from you by copyright. Thusly, you are not restricted by anyone because they have the copyright of the original work. It's important that you understand this.
Update to GCC copyright assignment policy
A file should be kept with the author name, date and changes done by each contributor. Including this is the source code would make the history too long. Otherwise, such information can be put at the end of the file. - Christopher Dimech Society has became too quick to pass judgement and declare someone Persona Non-Grata, the most extreme form of censure a country can bestow. In a new era of destructive authoritarianism, I support Richard Stallman. Times of great crisis are also times of great opportunity. I call upon you to make this struggle yours as well ! https://stallmansupport.org/ https://www.fsf.org/ https://www.gnu.org/ > Sent: Wednesday, June 02, 2021 at 4:44 AM > From: "Joseph Myers" > To: "David Edelsohn" > Cc: "Jakub Jelinek" , "GCC Development" > Subject: Re: Update to GCC copyright assignment policy > > On Tue, 1 Jun 2021, David Edelsohn via Gcc wrote: > > > The copyright author will be listed as "Free Software Foundation, > > Inc." and/or "The GNU Toolchain Authors", as appropriate. > > And copyright notices naming "The GNU Toolchain Authors" should not > include a date - that's following the recommendations at > https://www.linuxfoundation.org/en/blog/copyright-notices-in-open-source-software-projects/ > for the form of copyright notices in projects with many copyright holders. > > -- > Joseph S. Myers > jos...@codesourcery.com >
[PATCH] MAINTAINERS: create DCO section; add myself to it
On Tue, 2021-06-01 at 10:00 -0400, David Edelsohn via Gcc wrote: > GCC was created as part of the GNU Project but has grown to operate > as > an autonomous project. > > The GCC Steering Committee has decided to relax the requirement to > assign copyright for all changes to the Free Software Foundation. > GCC > will continue to be developed, distributed, and licensed under the > GNU > General Public License v3.0. GCC will now accept contributions with > or > without an FSF copyright assignment. This change is consistent with > the practices of many other major Free Software projects, such as the > Linux kernel. > > Contributors who have an FSF Copyright Assignment don't need to > change anything. Contributors who wish to utilize the Developer > Certificate > of Origin[1] should add a Signed-off-by message to their commit > messages. > Developers with commit access may add their name to the DCO list in > the > MAINTAINERS file to certify the DCO for all future commits in lieu of > individual > Signed-off-by messages for each commit. > > The GCC Steering Committee continues to affirm the principles of Free > Software, and that will never change. > > - The GCC Steering Committee > > [1] https://developercertificate.org/ > The MAINTAINERS file doesn't seem to have such a "DCO list" yet; does the following patch look like what you had in mind? ChangeLog * MAINTAINERS: Create DCO section; add myself to it. --- MAINTAINERS | 12 1 file changed, 12 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index db25583b37b..1148e0915cf 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -685,3 +685,15 @@ Josef Zlomek James Dennett Christian Ehrhardt Dara Hazeghi + + +DCO +=== + +Developers with commit access may add their name to the following list +to certify the DCO (https://developercertificate.org/) for all +future commits in lieu of individual Signed-off-by messages for each commit. + + DCO list(last name alphabetical order) + +David Malcolm -- 2.26.3
Update to GCC copyright assignment policy
> Sent: Wednesday, June 02, 2021 at 4:20 AM > From: "Maciej W. Rozycki" > To: "DJ Delorie" > Cc: "Paul Koning" , gcc@gcc.gnu.org > Subject: Re: Update to GCC copyright assignment policy > > On Tue, 1 Jun 2021, DJ Delorie via Gcc wrote: > > > > GCC is free software; you can redistribute it and/or modify > > > it under the terms of the GNU General Public License as published by > > > the Free Software Foundation; either version 3, or (at your option) > > > any later version. > > > > > > To me that means the recipient of the software can relicense it under > > > a later license. It doesn't say to me that the original distribution > > > can do so. > > > > I've never read it that way. To me it says "a recipient may > > redistribute it under terms of a newer license, but the license remains > > v3+ even if they do" - we're giving the recipient a choice of actions, > > but not power to relicense. > > My interpretation of this would be for modifications rather than original > sources, so v3+ applies to unmodified sources (for obvious reasons, given > that the recipient of the sources is not a copyright holder), however as a > copyright holder I can release my modifications say under v4 or v4+. It > is unclear to me if the newer licence will then "stick" to the rest of the > sources, but I suspect it will. A copyright assignment made to FSF (or > another legal entity) prevents this complication from happening. > > Maciej No. What the copyright holder can do is the re-license by any other license he wants (even proprietary). But you can't !!! That's the basic difference. - Christopher Dimech Society has became too quick to pass judgement and declare someone Persona Non-Grata, the most extreme form of censure a country can bestow. In a new era of destructive authoritarianism, I support Richard Stallman. Times of great crisis are also times of great opportunity. I call upon you to make this struggle yours as well ! https://stallmansupport.org/ https://www.fsf.org/ https://www.gnu.org/
Re: [PATCH] MAINTAINERS: create DCO section; add myself to it
On June 1, 2021 7:30:54 PM GMT+02:00, David Malcolm via Gcc wrote: >On Tue, 2021-06-01 at 10:00 -0400, David Edelsohn via Gcc wrote: >> GCC was created as part of the GNU Project but has grown to operate >> as >> an autonomous project. >> >> The GCC Steering Committee has decided to relax the requirement to >> assign copyright for all changes to the Free Software Foundation. >> GCC >> will continue to be developed, distributed, and licensed under the >> GNU >> General Public License v3.0. GCC will now accept contributions with >> or >> without an FSF copyright assignment. This change is consistent with >> the practices of many other major Free Software projects, such as the >> Linux kernel. >> >> Contributors who have an FSF Copyright Assignment don't need to >> change anything. Contributors who wish to utilize the Developer >> Certificate >> of Origin[1] should add a Signed-off-by message to their commit >> messages. >> Developers with commit access may add their name to the DCO list in >> the >> MAINTAINERS file to certify the DCO for all future commits in lieu of >> individual >> Signed-off-by messages for each commit. >> >> The GCC Steering Committee continues to affirm the principles of Free >> Software, and that will never change. >> >> - The GCC Steering Committee >> >> [1] https://developercertificate.org/ >> > >The MAINTAINERS file doesn't seem to have such a "DCO list" >yet; does the following patch look like what you had in mind? > >ChangeLog > > * MAINTAINERS: Create DCO section; add myself to it. >--- > MAINTAINERS | 12 > 1 file changed, 12 insertions(+) > >diff --git a/MAINTAINERS b/MAINTAINERS >index db25583b37b..1148e0915cf 100644 >--- a/MAINTAINERS >+++ b/MAINTAINERS >@@ -685,3 +685,15 @@ Josef Zlomek > > James Dennett > Christian Ehrhardt > Dara Hazeghi >+ >+ >+DCO >+=== >+ >+Developers with commit access may add their name to the following list >+to certify the DCO (https://developercertificate.org/) for all There should be a verbatim copy of the DCO in this file or the repository. >+future commits in lieu of individual Signed-off-by messages for each >commit. >+ >+ DCO list(last name alphabetical order) >+ >+David Malcolm
Re: Update to GCC copyright assignment policy
On 2021-06-01 07:28, Mark Wielaard wrote: Hi David, On Tue, 2021-06-01 at 10:00 -0400, David Edelsohn via Gcc wrote: The GCC Steering Committee has decided to relax the requirement to assign copyright for all changes to the Free Software Foundation. GCC will continue to be developed, distributed, and licensed under the GNU General Public License v3.0. GCC will now accept contributions with or without an FSF copyright assignment. This change is consistent with the practices of many other major Free Software projects, such as the Linux kernel. Contributors who have an FSF Copyright Assignment don't need to change anything. Contributors who wish to utilize the Developer Certificate of Origin[1] should add a Signed-off-by message to their commit messages. Developers with commit access may add their name to the DCO list in the MAINTAINERS file to certify the DCO for all future commits in lieu of individual Signed-off-by messages for each commit. This seems a pretty bad policy to be honest. Why was there no public discussion on this? I certainly understand not wanting to assign copyright to the FSF anymore given the recent board decisions. But changing GCC from having a shared copyright pool to having lots of individual (or company?) copyright holders seems like a regression for a strong copyleft project. With individual copyright holders companies no longer have clear way to know whether they are in compliance unless they talk to each and every individual copyright holder (see also the linux kernel, where there are some individuals who randomly sue companies just to get some money to drop the lawsuit). And for users it will be harder to get compliant sources if they can no longer simply ask the shared copyright holder, but instead will have to get enough individual copyright holders to get a distributor into compliance. If we no longer want the FSF to be the legal guardian and copyright holder for GCC could we please find another legal entity that performs that role and helps us as a project with copyleft compliance? Personally, this would have been my preference. I would be happy to setup a shared copyright pool under the Conservancy Copyleft Compliance project for example: https://sfconservancy.org/copyleft-compliance/ Thanks, Mark
Update to GCC copyright assignment policy
> Sent: Wednesday, June 02, 2021 at 7:58 AM > From: "Thomas Rodgers" > To: "Mark Wielaard" > Cc: "GCC Development" > Subject: Re: Update to GCC copyright assignment policy > > On 2021-06-01 07:28, Mark Wielaard wrote: > > > Hi David, > > > > On Tue, 2021-06-01 at 10:00 -0400, David Edelsohn via Gcc wrote: > > > >> The GCC Steering Committee has decided to relax the requirement to > >> assign copyright for all changes to the Free Software Foundation. GCC > >> will continue to be developed, distributed, and licensed under the GNU > >> General Public License v3.0. GCC will now accept contributions with or > >> without an FSF copyright assignment. This change is consistent with > >> the practices of many other major Free Software projects, such as the > >> Linux kernel. > >> > >> Contributors who have an FSF Copyright Assignment don't need to > >> change anything. Contributors who wish to utilize the Developer > >> Certificate > >> of Origin[1] should add a Signed-off-by message to their commit > >> messages. > >> Developers with commit access may add their name to the DCO list in > >> the > >> MAINTAINERS file to certify the DCO for all future commits in lieu of > >> individual > >> Signed-off-by messages for each commit. > > > > This seems a pretty bad policy to be honest. > > Why was there no public discussion on this? > > > > I certainly understand not wanting to assign copyright to the FSF > > anymore given the recent board decisions. But changing GCC from having > > a shared copyright pool to having lots of individual (or company?) > > copyright holders seems like a regression for a strong copyleft > > project. > > > > With individual copyright holders companies no longer have clear way to > > know whether they are in compliance unless they talk to each and every > > individual copyright holder (see also the linux kernel, where there are > > some individuals who randomly sue companies just to get some money to > > drop the lawsuit). And for users it will be harder to get compliant > > sources if they can no longer simply ask the shared copyright holder, > > but instead will have to get enough individual copyright holders to get > > a distributor into compliance. > > > > If we no longer want the FSF to be the legal guardian and copyright > > holder for GCC could we please find another legal entity that performs > > that role and helps us as a project with copyleft compliance? > > Personally, this would have been my preference. One thing to consider is whether there exists any legal expertise for this. This obsession of GCC to disassociate from the FSF is unskilled and unnecessary. Much effort should rather be put upon doing real work, opposing the European Union Directive on Copyright in the Digital Single Market that came into force on 7 June 2019. > > I would be happy to setup a shared copyright pool under the Conservancy > > Copyleft Compliance project for example: > > https://sfconservancy.org/copyleft-compliance/ > > > > Thanks, > > > > Mark - Christopher Dimech Society has became too quick to pass judgement and declare someone Persona Non-Grata, the most extreme form of censure a country can bestow. In a new era of destructive authoritarianism, I support Richard Stallman. Times of great crisis are also times of great opportunity. I call upon you to make this struggle yours as well ! https://stallmansupport.org/ https://www.fsf.org/ https://www.gnu.org/
Re: Update to GCC copyright assignment policy
On Tue, Jun 1, 2021 at 10:02 AM David Edelsohn via Gcc wrote: > > GCC was created as part of the GNU Project but has grown to operate as > an autonomous project. > > The GCC Steering Committee has decided to relax the requirement to > assign copyright for all changes to the Free Software Foundation. GCC > will continue to be developed, distributed, and licensed under the GNU > General Public License v3.0. GCC will now accept contributions with or > without an FSF copyright assignment. This change is consistent with > the practices of many other major Free Software projects, such as the > Linux kernel. > > Contributors who have an FSF Copyright Assignment don't need to > change anything. Contributors who wish to utilize the Developer Certificate > of Origin[1] should add a Signed-off-by message to their commit messages. > Developers with commit access may add their name to the DCO list in the > MAINTAINERS file to certify the DCO for all future commits in lieu of > individual > Signed-off-by messages for each commit. > > The GCC Steering Committee continues to affirm the principles of Free > Software, and that will never change. > > - The GCC Steering Committee > > [1] https://developercertificate.org/ One thing I'm wondering about this change is if it allows certain old changes that previously couldn't be upstreamed to now be upstreamed? For example, when I have asked about trying to forward-port certain changes from Apple's old gcc-4.2 branch, I was told that one reason this couldn't happen was because Apple hadn't assigned copyright for those changes. Of course, there are still the technical difficulties of the fact that 4.2 has bitrotted considerably in the years since its last release, but regardless of those, are the legal difficulties at least now out of the way? Thanks, Eric Gallager
Re: Update to GCC copyright assignment policy
On 6/1/2021 5:22 PM, Eric Gallager via Gcc wrote: On Tue, Jun 1, 2021 at 10:02 AM David Edelsohn via Gcc wrote: GCC was created as part of the GNU Project but has grown to operate as an autonomous project. The GCC Steering Committee has decided to relax the requirement to assign copyright for all changes to the Free Software Foundation. GCC will continue to be developed, distributed, and licensed under the GNU General Public License v3.0. GCC will now accept contributions with or without an FSF copyright assignment. This change is consistent with the practices of many other major Free Software projects, such as the Linux kernel. Contributors who have an FSF Copyright Assignment don't need to change anything. Contributors who wish to utilize the Developer Certificate of Origin[1] should add a Signed-off-by message to their commit messages. Developers with commit access may add their name to the DCO list in the MAINTAINERS file to certify the DCO for all future commits in lieu of individual Signed-off-by messages for each commit. The GCC Steering Committee continues to affirm the principles of Free Software, and that will never change. - The GCC Steering Committee [1] https://developercertificate.org/ One thing I'm wondering about this change is if it allows certain old changes that previously couldn't be upstreamed to now be upstreamed? For example, when I have asked about trying to forward-port certain changes from Apple's old gcc-4.2 branch, I was told that one reason this couldn't happen was because Apple hadn't assigned copyright for those changes. Of course, there are still the technical difficulties of the fact that 4.2 has bitrotted considerably in the years since its last release, but regardless of those, are the legal difficulties at least now out of the way? Read the DCO. If you can satisfy the terms of the DCO, then yes it would help. But DCO still has requirements that may not be easily met unless you are the author or know the author and can communicate with them. jeff
