RE: RFC: GIMPLE tuples. Design and implementation proposal
On 12 July 2007 05:21, [EMAIL PROTECTED] wrote: >> On 7/10/07, [EMAIL PROTECTED] writes: >>> On 7/10/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: You haven't >>> explained what advantages CIL's IR has over GIMPLE. I thought it was >>> well explained on page: _http://hal.cs.berkeley.edu/cil/cil001.html_ > (http://hal.cs.berkeley.edu/cil/cil001.html) > >> No, since as i said, their IR is the same as GIMPLE. > > > You may say that but I am not the only one who says that CIL is both higher > level and lower level than what > we are using. IE: the _lower_ level portion is _simpler_ than GIMPLE - > which _is_ what you want, is it not ? No, the tuples project is not remotely about introducing a new intermediate representation, it's a minor tweak to the one we already have to reorganise some datastructures so they are more memory efficient. What you /appear/ to be suggesting sounds more like "Why doesn't everyone drop what they're doing and spend the next few years ripping the guts out of the compiler and replacing it with some other compiler". > As I mentioned, it is your project to do your own way. I just would not > want to see you spend a lot of time coding to > duplicate prior work. Sure, there might well be design techniques and algorithms worth adopting and adapting, but the chances of large chunks of code being meaningfully transplantable are pretty small. > You say you have already seen what I have suggested > and want to start from scratch. OK. "Start from scratch"? We already *have* GIMPLE. The tuples project is a minor adjustment to it. cheers, DaveK -- Can't think of a witty .sigline today
Bootstrap broken on trunk rev. 126573
Hi, bootstrap is broken on trunk during stage1: echo '/home/xtv/gcc-devel/gcc/gcc/c-common.c' >> tmp-gi.list echo '/home/xtv/gcc-devel/gcc/gcc/c-common.h' >> tmp-gi.list echo '/home/xtv/gcc-devel/gcc/gcc/c-pragma.h' >> tmp-gi.list echo '/home/xtv/gcc-devel/gcc/gcc/c-pragma.c' >> tmp-gi.list echo '/home/xtv/gcc-devel/gcc/gcc/c-objc-common.c' >> tmp-gi.list echo '/home/xtv/gcc-devel/gcc/gcc/c-parser.c' >> tmp-gi.list /bin/sh /home/xtv/gcc-devel/gcc/gcc/../move-if-change tmp-gi.list gtyp-input.list echo timestamp > s-gtyp-input build/gengtype /home/xtv/gcc-devel/gcc/gcc gtyp-input.list /home/xtv/gcc-devel/gcc/gcc/../include/splay-tree.h:55: unidentified type `libi_uhostptr_t' /home/xtv/gcc-devel/gcc/gcc/../include/splay-tree.h:56: unidentified type `libi_uhostptr_t' make[3]: *** [s-gtype] Error 1 make[3]: Leaving directory `/home/xtv/gcc-devel/gcc/obj/gcc' make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory `/home/xtv/gcc-devel/gcc/obj' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/home/xtv/gcc-devel/gcc/obj' make: *** [bootstrap] Error 2 gcc_build: error: Could not bootstrap the compiler when building with ./contrib/gcc_build -c "--prefix=/home/xtv --enable-languages=c,c++,objc,fortran,obj-c++ --enable-bootstrap --enable-decimal-float=bid" -d /home/xtv/gcc-devel/gcc -o obj bootstrap The "broken" splay-tree.h: [EMAIL PROTECTED] ~/gcc-devel/gcc $ svn info include/splay-tree.h Path: include/splay-tree.h Name: splay-tree.h URL: svn://gcc.gnu.org/svn/gcc/trunk/include/splay-tree.h Repository Root: svn://gcc.gnu.org/svn/gcc Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4 Revision: 126573 Node Kind: file Schedule: normal Last Changed Author: nickc Last Changed Rev: 126573 Last Changed Date: 2007-07-12 09:22:06 +0200 (Thu, 12 Jul 2007) Text Last Updated: 2007-07-12 09:53:24 +0200 (Thu, 12 Jul 2007) Properties Last Updated: 2007-07-12 09:53:24 +0200 (Thu, 12 Jul 2007) Checksum: 820949be19461c4cf27fdab7d0c0 Best regards, Thomas
GDB testsuite + dejagnu uses gcc compiler by default, how to configure testsuite to use other 'c' compilers (like cross compilers arm-cc, etc)
From: Venkatesan Jeevanandam Sent: Thursday, July 12, 2007 2:40 PM To: '[EMAIL PROTECTED]'; 'gcc@gcc.gnu.org' Subject: RE: GDB testsuite + dejagnu uses gcc compiler by default, how to configure testsuite to use other 'c' compilers (like cross compilers arm-cc, etc) From: Venkatesan Jeevanandam Sent: Thursday, July 12, 2007 2:38 PM To: [EMAIL PROTECTED]; gcc@gcc.gnu.org Subject: GDB testsuite + dejagnu uses gcc compiler by default, how to configure testsuite to use other 'c' compilers (like cross compilers arm-cc, etc) Importance: High Hi I am testing a cross compiler debugger (arch-gdb). I want to use arch-cc compiler to compile the testsuite 'c' files, however gcc is considered as a default compiler. $runtest - -tool gdb - - tool_exec arch-gdb The above command, runs gdb testsuite successfully, using gcc compiler. I added target dependent board file, $runtest - -tool gdb - -tool_exec arch-gdb - -target_board arch_board , I am getting the below error, "gdb compile failed, default_target_compile: No compiler to compile with" Using /usr/local/share/dejagnu/config/gdb-comm.exp as generic interface file for target. Using ./config/tile-eval.exp as tool-and-target-specific interface file. Running ./gdb.base/return.exp ... gdb compile failed, default_target_compile: No compiler to compile with Running ./gdb.base/radix.exp ... Running ./gdb.base/gcore.exp ... How to configure dejagnu / gdb testsuite to use arch-cc instead of gcc...? Please help me. Regards, J Venkatesan | DISCLAIMER: This message (including attachment if any) is confidential and may be privileged. Before opening attachments please check them for viruses and defects. MindTree Consulting Limited (MindTree) will not be responsible for any viruses or defects or any forwarded attachments emanating either from within MindTree or outside. If you have received this message by mistake please notify the sender by return e-mail and delete this message from your system. Any unauthorized use or dissemination of this message in whole or in part is strictly prohibited.Please note that e-mails are susceptible to change and MindTree shall not be liable for any improper, untimely or incomplete transmission. E-mail may contain viruses. Before opening attachments please check them for viruses and defects. While MindTree Consulting Limited (MindTree) has put in place checks to minimize the risks, MindTree will not be responsible for any viruses or defects or any forwarded attachments emanating either from within MindTree or outside.
Re: AMD64 ABI compatibility
Hi,
I am nearly through :) The remaining macros left to be ported are
REGPARM_MAX and SSE_REGPARM_MAX. The sysv_abi uses 6 regs and 8 sses,
ms_abi uses 4 regs and 4 sse registers. The problem is for example the use
in i386.md of SSE_REGPARM_MAX without any hint, how to choose the required
abi. Do you have an idea how this could be done ?
Cheers,
i.A. Kai Tietz
| (\_/) This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| (")_(") world domination.
--
OneVision Software Entwicklungs GmbH & Co. KG
Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg
Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 - www.OneVision.com
Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050
Handelsregister: HRA 6744, Amtsgericht Regensburg
Komplementärin: OneVision Software Entwicklungs Verwaltungs GmbH
Dr.-Leo-Ritter-Straße 9 – 93049 Regensburg
Handelsregister: HRB 8932, Amtsgericht Regensburg - Geschäftsführer:
Ulrike Döhler, Manuela Kluger
FW: GDB testsuite + dejagnu uses gcc compiler by default, how to configure testsuite to use other 'c' compilers (like cross compilers arm-cc, etc)
From: Venkatesan Jeevanandam Sent: Thursday, July 12, 2007 2:38 PM To: [EMAIL PROTECTED]; gcc@gcc.gnu.org Subject: GDB testsuite + dejagnu uses gcc compiler by default, how to configure testsuite to use other 'c' compilers (like cross compilers arm-cc, etc) Importance: High Hi I am testing a cross compiler debugger (arch-gdb). I want to use arch-cc compiler to compile the testsuite 'c' files, however gcc is considered as a default compiler. $runtest - -tool gdb - - tool_exec arch-gdb The above command, runs gdb testsuite successfully, using gcc compiler. I added target dependent board file, $runtest - -tool gdb - -tool_exec arch-gdb - -target_board arch_board , I am getting the below error, "gdb compile failed, default_target_compile: No compiler to compile with" Using /usr/local/share/dejagnu/config/gdb-comm.exp as generic interface file for target. Using ./config/tile-eval.exp as tool-and-target-specific interface file. Running ./gdb.base/return.exp ... gdb compile failed, default_target_compile: No compiler to compile with Running ./gdb.base/radix.exp ... Running ./gdb.base/gcore.exp ... How to configure dejagnu / gdb testsuite to use arch-cc instead of gcc...? Please help me. Regards, J Venkatesan | DISCLAIMER: This message (including attachment if any) is confidential and may be privileged. Before opening attachments please check them for viruses and defects. MindTree Consulting Limited (MindTree) will not be responsible for any viruses or defects or any forwarded attachments emanating either from within MindTree or outside. If you have received this message by mistake please notify the sender by return e-mail and delete this message from your system. Any unauthorized use or dissemination of this message in whole or in part is strictly prohibited.Please note that e-mails are susceptible to change and MindTree shall not be liable for any improper, untimely or incomplete transmission. E-mail may contain viruses. Before opening attachments please check them for viruses and defects. While MindTree Consulting Limited (MindTree) has put in place checks to minimize the risks, MindTree will not be responsible for any viruses or defects or any forwarded attachments emanating either from within MindTree or outside.
Re: RFH: GPLv3
Mark Mitchell <[EMAIL PROTECTED]> writes: | The GCC SC is still discussing a few of the finer points of the | transition to GPLv3. Thanks for the update! [...] | 3. After GCC 4.2.1 is released, we will renumber the branch to GCC 4.3. | What would have been GCC 4.2.2 will instead be GCC 4.3.3, to try to | emphasize the GPLv3 switch. The GCC mainline will then be GCC 4.4. What a mess! (Sorry). Was the option of closing the GCC-4.2.x branch considered, instead of releasing GCC-4.2.2 as GCC-4.3.2? [...] | It has also not yet been decided whether backports of bug-fixes from | GPLv3 versions of GCC to older GPLv2 versions of GCC (e.g., GCC 4.1) We can make a final release from GCC-4.1.x and close it definitely. We should strive for some kind of mononiticy in terms of release series and licensing. -- Gaby
Re: RFH: GPLv3
On 12 Jul 2007 04:37:20 -0500, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote: Mark Mitchell <[EMAIL PROTECTED]> writes: | The GCC SC is still discussing a few of the finer points of the | transition to GPLv3. Thanks for the update! [...] | 3. After GCC 4.2.1 is released, we will renumber the branch to GCC 4.3. | What would have been GCC 4.2.2 will instead be GCC 4.3.3, to try to | emphasize the GPLv3 switch. The GCC mainline will then be GCC 4.4. What a mess! (Sorry). Was the option of closing the GCC-4.2.x branch considered, instead of releasing GCC-4.2.2 as GCC-4.3.2? I agree, this looks like a mess (and it will definitely confuse users). Closing the branch would be an option, but the tricky question what happens if there are backports from mainline fixes to the (closed) branch as part of vendor releases remains. (Likewise for the 4.1 branch) I would definitely like to have a public statement from the FSF on this issue. I suppose backporting your own fixes is a no-brainer, as you don't lose the rights to re-license your own contributions, but without an official statement from the FSF there will be still a lot of confusion on this issue. | It has also not yet been decided whether backports of bug-fixes from | GPLv3 versions of GCC to older GPLv2 versions of GCC (e.g., GCC 4.1) We can make a final release from GCC-4.1.x and close it definitely. We should strive for some kind of mononiticy in terms of release series and licensing. We can just close the branch. Though I expect vendors to continue to need to maintain it for another 5+ years. Maybe we can get mutual agreement from contributors to re-license their contributions to currently active branches under GPL v2 as well and this way side-stepping the FSF on this matter. Richard.
Re: RFH: GPLv3
Hi Mark, Will someone (or someones) please volunteer to change the various files that mention GPLv2 to mention GPLv3 instead, to change the COPYING file in the gcc/ directory, and to look for other things that need to change? I volunteer. It has not yet been decided what to do about files that are part of run-time libraries and are covered by GPL/LGPL + exception. Therefore, no changes to to what ? :-) I assume that there is a missing part of that last sentence which reads "these files will take place at the moment". I think however that a small change to such files may be necessary. If I change the contents of the COPYING file over to GPLv3, then I think that it might be wise to create a new file - COPYING_v2 - which contains the GPLv2 and which can be referred to in the copyright notice of files which are still under the GPLv2. It has also not yet been decided whether backports of bug-fixes from GPLv3 versions of GCC to older GPLv2 versions of GCC (e.g., GCC 4.1) will result in the patched compilers being GPLv3. If you have thoughts about that, you might wish to contact the FSF. This is what the FSF had to say when I raised this issue with them for the binutils project: : Since the previous releases were licensed under GPLv2 or later, all : maintainers need to do is upgrade their backport to GPLv3 or later -- : then they'll be able to incorporate patches that were never released : under GPLv2. Cheers Nick
New bootstrap failure ppc64
I still haven't been able to get a clean bootstrap on trunk for ppc64. This time, it seems as if a recent PRE change is overwriting memory. The failure shows up while building libgcc with the stage1 compiler (attached). Running cc1 with valgrind shows a memory overwrite problem in tree-ssa-pre.c. So the failure may be related to this patch: +2007-07-11 Daniel Berlin <[EMAIL PROTECTED]> + + PR tree-optimization/32663 + + * tree.h (VALUE_HANDLE_VUSES): Remove. + (struct tree_value_handle): Remove vuses. + + * tree-vn.c (create_value_handle_for_expr): Don't set + VALUE_HANDLE_VUSES. + + * tree-ssa-pre.c (expression_vuses): New. + (alloc_expression_id): Set up expression_vuses. + (get_expression_vuses): New. + (set_expression_vuses): Ditto. + (clear_expression_ids): Modify for expression_vuses. + (phi_translate_1): Ditto. + (phi_translate_set): Ditto. + (value_dies_in_block_x): Ditto + (valid_in_sets): Ditto. + (add_to_sets): Ditto. + (find_existing_value_expr): Ditto. + (create_value_handle_for_expr): Ditto. + (make_values_for_stmt): Ditto. + (vuse_equiv): Remove. Valgrind shows: $ valgrind /home/dnovillo/perf/sbox/gcc/local.ppc64/bld/./gcc/cc1 -fpreprocessed libgcc2.i -quiet -dumpbase libgcc2.c -mno-minimal-toc -mlong-double-128 -auxbase-strip _lshrdi3.o -g -g -g -O2 -O2 -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -version -fkeep-inline-functions -fPIC -fvisibility=hidden -o libgcc2.s ==15400== Memcheck, a memory error detector. ==15400== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al. ==15400== Using LibVEX rev 1658, a library for dynamic binary translation. ==15400== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP. ==15400== Using valgrind-3.2.1, a dynamic binary instrumentation framework. ==15400== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al. ==15400== For more details, rerun with: -v ==15400== GNU C version 4.3.0 20070712 (experimental) (powerpc64-unknown-linux-gnu) compiled by GNU C version 4.1.2 20070626 (Red Hat 4.1.2-13), GMP version 4.2.1, MPFR version 2.2.1. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: f98afd126838ac20d9a920faa1d71e5c ==15400== Invalid read of size 8 ==15400==at 0x104AE494: VEC_vuse_vec_base_replace (tree-ssa-pre.c:189) ==15400==by 0x104AE440: set_expression_vuses (tree-ssa-pre.c:264) ==15400==by 0x104ADCD8: phi_translate_1 (tree-ssa-pre.c:1221) ==15400==by 0x104AE6CC: phi_translate (tree-ssa-pre.c:1355) ==15400==by 0x104AE778: phi_translate_set (tree-ssa-pre.c:1381) ==15400==by 0x104AFB9C: defer_or_phi_translate_block (tree-ssa-pre.c:1643) ==15400==by 0x104AFDF4: compute_antic_aux (tree-ssa-pre.c:1704) ==15400==by 0x104B19D8: compute_antic (tree-ssa-pre.c:2005) ==15400==by 0x104B89DC: execute_pre (tree-ssa-pre.c:3948) ==15400==by 0x104B8B44: do_pre (tree-ssa-pre.c:3981) ==15400==by 0x102B0A04: execute_one_pass (passes.c:1125) ==15400==by 0x102B0C38: execute_pass_list (passes.c:1178) ==15400== Address 0x4944C78 is 0 bytes after a block of size 440 free'd ==15400==at 0x4017090: realloc (vg_replace_malloc.c:306) ==15400==by 0x108D7FE4: xrealloc (xmalloc.c:179) ==15400==by 0x1055CBFC: vec_heap_o_reserve_1 (vec.c:177) ==15400==by 0x1055CC9C: vec_heap_p_reserve (vec.c:190) ==15400==by 0x104AB6D8: VEC_vuse_vec_heap_reserve (tree-ssa-pre.c:190) ==15400==by 0x104AB5E4: VEC_vuse_vec_heap_safe_push (tree-ssa-pre.c:190) ==15400==by 0x104AB29C: alloc_expression_id (tree-ssa-pre.c:212) ==15400==by 0x104AB198: get_or_alloc_expression_id (tree-ssa-pre.c:237) ==15400==by 0x104AE42C: set_expression_vuses (tree-ssa-pre.c:264) ==15400==by 0x104ADCD8: phi_translate_1 (tree-ssa-pre.c:1221) ==15400==by 0x104AE6CC: phi_translate (tree-ssa-pre.c:1355) ==15400==by 0x104AE778: phi_translate_set (tree-ssa-pre.c:1381) ==15400== ==15400== Invalid write of size 8 ==15400==at 0x104AE4B4: VEC_vuse_vec_base_replace (tree-ssa-pre.c:189) ==15400==by 0x104AE440: set_expression_vuses (tree-ssa-pre.c:264) ==15400==by 0x104ADCD8: phi_translate_1 (tree-ssa-pre.c:1221) ==15400==by 0x104AE6CC: phi_translate (tree-ssa-pre.c:1355) ==15400==by 0x104AE778: phi_translate_set (tree-ssa-pre.c:1381) ==15400==by 0x104AFB9C: defer_or_phi_translate_block (tree-ssa-pre.c:1643) ==15400==by 0x104AFDF4: compute_antic_aux (tree-ssa-pre.c:1704) ==15400==by 0x104B19D8: compute_antic (tree-ssa-pre.c:2005) ==15400==by 0x104B89DC: execute_pre (tree-ssa-pre.c:3948) ==15400==by 0x104B8B44: do_pre (tree-ssa-pre.c:3981) ==15400==by 0x102B0A04: execute_one_pass (passes.c:1125) ==15400==by 0x102B0C38: execute_pass_list (passes.c:1178) ==15400== Address 0x4944C78 is 0 bytes after a bloc
Re: Bootstrap broken on trunk rev. 126573
Hi Thomas,
> bootstrap is broken on trunk during stage1:
Seems to be not in general. It is related to the whitespaces for the new
types used in splay-tree.h. If shrink them, it seems to work as Uros
detected. This smells, that the gengtype-lex.l has problems about too much
spaces in a typedef.
> The "broken" splay-tree.h:
Shrink the whitespaces out of the new types. This seems to be a
work-a-round.
Regards,
i.A. Kai Tietz
| (\_/) This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| (")_(") world domination.
--
OneVision Software Entwicklungs GmbH & Co. KG
Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg
Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 - www.OneVision.com
Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050
Handelsregister: HRA 6744, Amtsgericht Regensburg
Komplementärin: OneVision Software Entwicklungs Verwaltungs GmbH
Dr.-Leo-Ritter-Straße 9 – 93049 Regensburg
Handelsregister: HRB 8932, Amtsgericht Regensburg - Geschäftsführer:
Ulrike Döhler, Manuela Kluger
Re: RFH: GPLv3
Mark Mitchell wrote:
The GCC SC is still discussing a few of the finer points of the
transition to GPLv3.[...]
Good!
Here is my initial opinion on some point you asked; but please ignore it if it
hurts somebody!
3. After GCC 4.2.1 is released, we will renumber the branch to GCC 4.3.
What would have been GCC 4.2.2 will instead be GCC 4.3.3, to try to
emphasize the GPLv3 switch. The GCC mainline will then be GCC 4.4.
I find this surprising and a bit confusing! My first reaction (maybe not enough thought) is that most users don't care
much about GCC source code, only about its functionality (making an executable from C or C++ source code). I am not very
sure that a "minor" change on the GCC source code license should affect so significantly the version numbering.
Maybe it might be simpler for every one to keep the 4.2.2 number the same, while putting an emphasis in its README or
release notes about license version change.
In other words, for GCC and most of its users, the main freedom of the 4 freedoms in GPL is the right to use the GCC
compiler to compiles one's own stuff (even proprietary code). AFAIK this stays the same in GPLv2 and GPLv3.
Even if the license is changing, the ordinary user will very probably be able to mix (e.g. link) her object code
compiled by gcc-4.2.1 and her object code compiled what you call gcc-4.3.3 and what I would prefer calling gcc-4.2.2
But I am not a lawyer, nor a free license guru, so feel free to ignore my initial feelings on this. Do what you feel
best and a big thanks for your work!
Regards
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet | mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: RFH: GPLv3
On 7/12/07, Basile STARYNKEVITCH <[EMAIL PROTECTED]> wrote: Mark Mitchell wrote: > 3. After GCC 4.2.1 is released, we will renumber the branch to GCC 4.3. > What would have been GCC 4.2.2 will instead be GCC 4.3.3, to try to > emphasize the GPLv3 switch. The GCC mainline will then be GCC 4.4. I find this surprising and a bit confusing! My first reaction (maybe not enough thought) is that most users don't care much about GCC source code, only about its functionality (making an executable from C or C++ source code). I am not very sure that a "minor" change on the GCC source code license should affect so significantly the version numbering. I had the same reaction. A new major release of GCC implies new features and other technical enhancements, not just a new license. Just imagine the flood of user questions and complaints when they download GCC 4.3, expecting to find their favorite new feature that they were told would be in GCC 4.3, and "all I got was this crummy new license." Shouldn't we at least have some carrot with this stick? Could we ask the SC to reconsider the change in the GCC major version numbering for GPLv3? Or, at the very least, explain why it is important to change the major version number for a mere license change? Why not just change the license on mainline for the GCC 4.3 release (whenever it happens), and leave GCC 4.2 as the last release series using GPLv2? - Doug
Re: RFH: GPLv3
> Doug Gregor writes: Doug> Could we ask the SC to reconsider the change in the GCC major version Doug> numbering for GPLv3? Or, at the very least, explain why it is Doug> important to change the major version number for a mere license Doug> change? To avoid confusion among GCC users who do not expect a bug fix release to introuduce a new license. David
RE: RFH: GPLv3
On 12 July 2007 15:29, Doug Gregor wrote: > On 7/12/07, Basile STARYNKEVITCH <[EMAIL PROTECTED]> wrote: >> Mark Mitchell wrote: >>> 3. After GCC 4.2.1 is released, we will renumber the branch to GCC 4.3. >>> What would have been GCC 4.2.2 will instead be GCC 4.3.3, to try to >>> emphasize the GPLv3 switch. The GCC mainline will then be GCC 4.4. >> >> I find this surprising and a bit confusing! My first reaction (maybe not >> enough thought) is that most users don't care much about GCC source code, >> only about its functionality (making an executable from C or C++ source >> code). I am not very sure that a "minor" change on the GCC source code >> license should affect so significantly the version numbering. > > I had the same reaction. A new major release of GCC Ok, hadn't you better both stop right there. "Major" release? "significantly" affect the version numbering? We're going from 4.2 to 4.3. That's the MINOR release number that's changing. cheers, DaveK -- Can't think of a witty .sigline today
Re: RFH: GPLv3
Mark Mitchell <[EMAIL PROTECTED]> writes: > 2. GCC 4.2.1 will be the last GPLv2 release. The FSF will permit > backports from mainline to GCC 4.2.1, if necessary, to be downlicensed > to GPLv2, as part of that release. I believe that we should make a clear statement with that release that any future backport from a later gcc release requires relicensing the changed files to be GPLv3 or later. I believe this is consistent with the two different licensing requirements, and I believe it is feasible if inconvenient for vendors who distribute patched gcc releases. > 3. After GCC 4.2.1 is released, we will renumber the branch to GCC 4.3. > What would have been GCC 4.2.2 will instead be GCC 4.3.3, to try to > emphasize the GPLv3 switch. The GCC mainline will then be GCC 4.4. That seems really really confusing. I appreciate that the SC is facing contradictory requirements. But I think there must be a better solution. Moving from 4.2.1 to 4.3.3 will have us writing explanations to users and distributors for the next five years. My personal preference would be to acknowledge that for our users there is no significant difference between GPLv2 and GPLv3. And we should acknowledge that people backporting patches from later releases are already going to have to relicense to GPLv3. Therefore, we should simply change gcc 4.2.2 to be GPLv3. This is a lot of churn on the branch, and I wish it were unnecessary, but presumably the FSF requires it. I think that choice is the lesser evil. The only people who may be discomfited by that choice are distributors of gcc who are unwilling to distribute code licensed under GPLv3. But for those people, renaming gcc 4.2.2 to gcc 4.3.3 will not help them in any meaningful way. I think it will suffice to clearly announce the licensing change in the documentation and announcements for both gcc 4.2.1 (under GPLv2) and gcc 4.2.2 (under GPLv3). And, of course, we should help any concerned distributors to understand that, for gcc, GPLv3 does not impose any requirements that were not already implicitly present in GPLv2. (I personally only know of one potentially recalcitrant distributor, and, again, renaming gcc 4.2.2 to gcc 4.3.3 will not help them.) > It has not yet been decided what to do about files that are part of > run-time libraries and are covered by GPL/LGPL + exception. Therefore, > no changes to I find this truncated sentence to be slightly ominous as I believe there is only one plausible choice for those files: we must convert them to be GPLv3/LGPLv3 + exception, where the exception is identical or equivalent to the current one. Adding any restrictions to the licensing of those files will cost us a significant portion of our user base. > It has also not yet been decided whether backports of bug-fixes from > GPLv3 versions of GCC to older GPLv2 versions of GCC (e.g., GCC 4.1) > will result in the patched compilers being GPLv3. If you have thoughts > about that, you might wish to contact the FSF. I believe it will result in the patched compilers being GPLv3, and I believe that is acceptable if inconvenient. If the FSF will grant a dispensation here, that would be clearly helpful. But any such dispensation would have to avoid opening a huge licensing hole for anybody who wants to stick to GPLv2, to prevent them from simply building a permanent branch of gcc 4.1 and backporting and relicensing all future gcc changes. Ian
Re: GDB testsuite + dejagnu uses gcc compiler by default, how to configure testsuite to use other 'c' compilers (like cross compilers arm-cc, etc)
"Venkatesan Jeevanandam" <[EMAIL PROTECTED]> writes: > DISCLAIMER: > This message (including attachment if any) is confidential and may be > privileged. Before opening attachments please check them for viruses and > defects. MindTree Consulting Limited (MindTree) will not be responsible for > any viruses or defects or any forwarded attachments emanating either from > within MindTree or outside. If you have received this message by mistake > please notify the sender by return e-mail and delete this message from your > system. Any unauthorized use or dissemination of this message in whole or in > part is strictly prohibited.Please note that e-mails are susceptible to > change and MindTree shall not be liable for any improper, untimely or > incomplete transmission. > E-mail may contain viruses. Before opening attachments please check them for > viruses and defects. While MindTree Consulting Limited (MindTree) has put in > place checks to minimize the risks, MindTree will not be responsible for any > viruses or defects or any forwarded attachments emanating either from within > MindTree or outside. Please do not send messages with this sort of disclaimer to the gcc.gnu.org mailing lists. They are against list policy (http://gcc.gnu.org/lists.html). If you are unable to remove the disclaimer from e-mail sent from your company, then I recommend using a free web-based e-mail account. Thanks. (Also your message was inappropriate for the gcc@gcc.gnu.org mailing list. Try [EMAIL PROTECTED] or [EMAIL PROTECTED]) Ian
Re: RFH: GPLv3
David Edelsohn <[EMAIL PROTECTED]> writes: > > Doug Gregor writes: > > Doug> Could we ask the SC to reconsider the change in the GCC major version > Doug> numbering for GPLv3? Or, at the very least, explain why it is > Doug> important to change the major version number for a mere license > Doug> change? > > To avoid confusion among GCC users who do not expect a bug fix > release to introuduce a new license. To pile on after my earlier message, I would say that the change in license does not matter at all, not even a tiny bit, for gcc *users*. It only matters for gcc *distributors*. And I think the vastly smaller population of gcc distributors can be reached by appropriate use of documentation and announcements. Whereas the change in version numbering does matter for users. Ian
Re: RFH: GPLv3
On 7/12/07, David Edelsohn <[EMAIL PROTECTED]> wrote: > Doug Gregor writes: Doug> Could we ask the SC to reconsider the change in the GCC major version Doug> numbering for GPLv3? Or, at the very least, explain why it is Doug> important to change the major version number for a mere license Doug> change? To avoid confusion among GCC users who do not expect a bug fix release to introuduce a new license. I agree with Ian on this one... to users, the new license just doesn't matter. It needs to be prominently stated in the release nodes, in the README, etc., but it's the technical changes that matter to GCC users. It seems obvious to me that it would be easiest to just move today's mainline over to GPLv3, and have every GCC release >= 4.3 be GPLv3. We could then either cut off the GCC 4.2 branch entirely or leave it GPLv2. Then there are no surprises for anyone. - Doug
Re: RFH: GPLv3
> Ian Lance Taylor writes: Ian> To pile on after my earlier message, I would say that the change in Ian> license does not matter at all, not even a tiny bit, for gcc *users*. Ian> It only matters for gcc *distributors*. And I think the vastly Ian> smaller population of gcc distributors can be reached by appropriate Ian> use of documentation and announcements. I completely agree that the license change does not matter in reality, but reality is different than perception. Members of the GCC SC have received feedback from users who are concerned. Some end users need approval from their legal department for a change of license of their software. This means that the users may need legal approval for a bug fix because of the license change. Also, for example see the way that Samba is handling the license change. David
Re: RFH: GPLv3
> Doug Gregor writes: Doug> It seems obvious to me that it would be easiest to just move today's Doug> mainline over to GPLv3, and have every GCC release >= 4.3 be GPLv3. We Doug> could then either cut off the GCC 4.2 branch entirely or leave it Doug> GPLv2. Then there are no surprises for anyone. Leaving released branches as GPLv2 is not an option. That definitely would be the path of least surprise. David
RE: RFH: GPLv3
On 12 July 2007 15:54, David Edelsohn wrote: >> Doug Gregor writes: > > Doug> It seems obvious to me that it would be easiest to just move today's > Doug> mainline over to GPLv3, and have every GCC release >= 4.3 be GPLv3. We > Doug> could then either cut off the GCC 4.2 branch entirely or leave it > Doug> GPLv2. Then there are no surprises for anyone. > > Leaving released branches as GPLv2 is not an option. What, even *closed* release branches? cheers, DaveK -- Can't think of a witty .sigline today
Re: RFH: GPLv3
On 7/12/07, Dave Korn <[EMAIL PROTECTED]> wrote: On 12 July 2007 15:29, Doug Gregor wrote: > I had the same reaction. A new major release of GCC Ok, hadn't you better both stop right there. "Major" release? "significantly" affect the version numbering? We're going from 4.2 to 4.3. That's the MINOR release number that's changing. *Sigh* We could haggle over terminology, and while you are technically right, you've side-stepped the point. Each GCC release series changes either the minor or the major version number, but to users the effect is the same. New features come in, old features are changed/fixed/deprecated/removed, and there is some porting effort involved that is not there when the subminor/patchlevel version changes within a release series. For C++ programmers, the "minor" release of GCC 3.4 was a major porting effort, while the "major" release of GCC 4.0 didn't affect their code much because most of that work was in the middle-end that users don't see. Hence, from a GCC user's perspective, each new release series is a "major" release, because it indicates that things are going to change, and they are probably going to have to port their code, retest, re-run benchmarks, etc. That's "major" to them (us). So, feel free to re-read my note from the perspective that a "major" release is something that has an impact on users, and "minor" is something that typically does not. But, please, let's not haggle over terminology. - Doug
Re: RFH: GPLv3
Dave Korn wrote:
On 12 July 2007 15:29, Doug Gregor wrote:
On 7/12/07, Basile STARYNKEVITCH <[EMAIL PROTECTED]> wrote:
Mark Mitchell wrote:
3. After GCC 4.2.1 is released, we will renumber the branch to GCC 4.3.
What would have been GCC 4.2.2 will instead be GCC 4.3.3, to try to
emphasize the GPLv3 switch. The GCC mainline will then be GCC 4.4.
I find this surprising and a bit confusing! My first reaction (maybe not
enough thought) is that most users don't care much about GCC source code,
only about its functionality (making an executable from C or C++ source
code). I am not very sure that a "minor" change on the GCC source code
license should affect so significantly the version numbering.
I had the same reaction. A new major release of GCC
Ok, hadn't you better both stop right there. "Major" release?
"significantly" affect the version numbering? We're going from 4.2 to 4.3.
That's the MINOR release number that's changing.
Agreed, but I believe remembering that linking object code compiled from C++ source by gcc-4.0 with object code compiled
from C++ source by gcc-4.1 (or maybe it was 4.1 & 4.2) failed in some corner cases. But perhaps my memory is wrong and I
might be confusing with gcc-3.4 vs gcc-4.0.
If all object code compiled by same major (but different minor) version of GCC is expected to be and almost always has
been compatible in the past (e.g. gcc-3.2 vs gcc-3.3 for example, or gcc-4.0 vs gcc-4.1) I retract my comment.
Still, I do believe that almost all my distant colleagues from CEA http://www.cea.fr/ (notably compiling their numerical
code for e.g. nuclear, astronomical or thermodynamical numerical computations) will find funny a version number change
from 4.2 to 4.2 only for the compiler license change. Most of them don't care about GPLv2 vs GPLv3 for the compiler,
they just want to compile their (sadly proprietary) numerical code (in Fortran or C++).
IMHO the only persons who really care about GPLv2 vs GPLv3 are open-source enthusiasts (and active open-source
contributors). Unfortunately, they are probably a minority in the huge set of GCC users: I believe that in all the
gcc-4.1 processes on the entire Earth which have been running yesterday july 11th 2007 from 0:00GMT to 23:59GMT, most of
them has been -on that day- compiling proprietary code, and even more of them don't care about the GPLv2 to GPLv3 change
in the GCC compiler, and won't understand a 4.2.2 -> 4.3.3 version string transition.
Very few of the developers I know which are using Linux and GCC are paid to develop open-source applications. Almost
everyone is compiling proprietary applications with GCC.
But I understand it is a very political trade-off to decide about GCC versioning scheme, so I leave it to people who
know. But since Mark Mitchell gently asked, I just gave my uninformed opinion, and I praise him and the whole SC for the
GPLv2 -> GPLv3 transition (which very probably means a lot of work for them).
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet | mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: RFH: GPLv3
> Dave Korn writes: Doug> could then either cut off the GCC 4.2 branch entirely or leave it Doug> GPLv2. Then there are no surprises for anyone. >> Leaving released branches as GPLv2 is not an option. Dave> What, even *closed* release branches? The comment referred to GCC 4.2. GCC 4.2 branch may not remain under GPLv2. GCC 4.1 branch may not remain under GPLv2. Closing the GCC 4.2 branch is impractical -- we must provide support until the next feature release, currently called GCC 4.3. Any patches backported to a release branch from mainline after mainline is relicensed to GPLv3 will cause the branch to be subject to GPLv3, unless the original author explicitly contributes the patch to the branch under GPLv2. David
RE: RFH: GPLv3
On 12 July 2007 16:06, Dave Korn wrote: > On 12 July 2007 15:54, David Edelsohn wrote: > >>> Doug Gregor writes: >> >> Doug> It seems obvious to me that it would be easiest to just move today's >> Doug> mainline over to GPLv3, and have every GCC release >= 4.3 be GPLv3. >> We Doug> could then either cut off the GCC 4.2 branch entirely or leave it >> Doug> GPLv2. Then there are no surprises for anyone. >> >> Leaving released branches as GPLv2 is not an option. > > What, even *closed* release branches? I've just read that again. I guess you're saying that option b) is not an option so cutting it off would be a necessity. Pardon the noise. cheers, DaveK -- Can't think of a witty .sigline today
Major Differences between gcc4.2 and gcc3.3
I want to know the major differences between gcc4.2 and gcc3.3. Can some one point to a document/page where I can find this information.
RE: Major Differences between gcc4.2 and gcc3.3
On 12 July 2007 16:26, Mayank Kumar wrote: > I want to know the major differences between gcc4.2 and gcc3.3. Can some > one point to a document/page where I can find this information. It doesn't exist in one nice document, but you can gather the cumulative changes from the per-release-series change notes: http://gcc.gnu.org/gcc-3.3/changes.html http://gcc.gnu.org/gcc-3.4/changes.html http://gcc.gnu.org/gcc-4.0/changes.html http://gcc.gnu.org/gcc-4.1/changes.html http://gcc.gnu.org/gcc-4.2/changes.html cheers, DaveK -- Can't think of a witty .sigline today
Re: Test gcc.c-torture/execute/align-3.c
> Feel free to either (a) #ifdef out the first part of the test on IA64,
> or (b) delete the first part of the test altogether.
Since it fails on other platforms (b) seems like the better alternative.
OK to checkin this patch?
Steve Ellcey
[EMAIL PROTECTED]
2007-07-12 Steve Ellcey <[EMAIL PROTECTED]>
* gcc.c-torture/execute/align-3.c: Remove function addr check.
Index: gcc.c-torture/execute/align-3.c
===
--- gcc.c-torture/execute/align-3.c (revision 126565)
+++ gcc.c-torture/execute/align-3.c (working copy)
@@ -6,8 +6,6 @@ void func(void)
int main()
{
- if (((long)func & 0xFF) != 0)
-abort ();
if (__alignof__(func) != 256)
abort ();
return 0;
Re: RFH: GPLv3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Edelsohn wrote: >> Doug Gregor writes: > > Doug> It seems obvious to me that it would be easiest to just move today's > Doug> mainline over to GPLv3, and have every GCC release >= 4.3 be GPLv3. We > Doug> could then either cut off the GCC 4.2 branch entirely or leave it > Doug> GPLv2. Then there are no surprises for anyone. > > Leaving released branches as GPLv2 is not an option. That > definitely would be the path of least surprise. Why is it not an option? - --BDS - -- Benjamin Smedberg Platform Guru Mozilla Corporation [EMAIL PROTECTED] http://benjamin.smedbergs.us/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGlkqfSSwGp5sTYNkRAid2AKDa67NkOEy/3XBQAhzDqkxV4pFI/QCcCbRx XbDhAsRG7xpXKtJKUXwos3c= =dK44 -END PGP SIGNATURE-
Re: RFH: GPLv3
> Benjamin Smedberg writes: Doug> It seems obvious to me that it would be easiest to just move today's Doug> mainline over to GPLv3, and have every GCC release >= 4.3 be GPLv3. We Doug> could then either cut off the GCC 4.2 branch entirely or leave it Doug> GPLv2. Then there are no surprises for anyone. >> >> Leaving released branches as GPLv2 is not an option. That >> definitely would be the path of least surprise. Ben> Why is it not an option? Because the FSF says it is not an option. The FSF holds the copyright and decides on the licensing. David
Re: RFH: GPLv3
> My personal preference would be to acknowledge that for our users > there is no significant difference between GPLv2 and GPLv3. I agree with this. I think renaming 4.2.2 to 4.3.3 will result in lots of unnecessary confusion.
Re: RFH: GPLv3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Richard Guenther wrote: >> | It has also not yet been decided whether backports of bug-fixes from >> | GPLv3 versions of GCC to older GPLv2 versions of GCC (e.g., GCC 4.1) >> >> We can make a final release from GCC-4.1.x and close it definitely. >> We should strive for some kind of mononiticy in terms of release >> series and licensing. > > We can just close the branch. Though I expect vendors to continue to need > to maintain it for another 5+ years. Maybe we can get mutual agreement > from contributors to re-license their contributions to currently active > branches > under GPL v2 as well and this way side-stepping the FSF on this matter. This sounds ideal, but I'm concerned a little bit about how this interacts with the copyright assignment to FSF. When a contributor assigns copyright to FSF, do they still have the right to license their changes separately? - --BDS - -- Benjamin Smedberg Platform Guru Mozilla Corporation [EMAIL PROTECTED] http://benjamin.smedbergs.us/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGlkulSSwGp5sTYNkRAhkvAJ41Ki5bNRPYYg6ruN9osh1ebXq2wQCfSjTy 9iM05WCf/CPmr4C8Qny4+GQ= =r9D3 -END PGP SIGNATURE-
Re: RFH: GPLv3
>> It has not yet been decided what to do about files that are part of >> run-time libraries and are covered by GPL/LGPL + exception. >> Therefore, no changes to >I find this truncated sentence to be slightly ominous as I believe >there is only one plausible choice for those files: we must convert >them to be GPLv3/LGPLv3 + exception, where the exception is identical >or equivalent to the current one. Adding any restrictions to the >licensing of those files will cost us a significant portion of our >user base. I see this as a less ominous development than you. I think the issue is that the FSF may be trying to come up with a unified GPLv3 + exception that libjava, libstdc++, libgfortran, libgcc, etc. can all use. The current exception wording is being reviewed with the existing GPLv3 text by lawyers. Certainly, this would be an improvement over the current practice. -benjamin
Re: RFH: GPLv3
On 7/12/07 11:43 AM, Richard Kenner wrote: >> My personal preference would be to acknowledge that for our users >> there is no significant difference between GPLv2 and GPLv3. > > I agree with this. I think renaming 4.2.2 to 4.3.3 will result in > lots of unnecessary confusion. > Likewise. As was suggested on IRC, we could append a letter to the version number (say 4.2.2G) or something distinctive, but don't skip version numbers in such an odd way. It will be confusing and will give us no end of support headaches.
Re: RFH: GPLv3
> Any patches backported to a release branch from mainline after > mainline is relicensed to GPLv3 will cause the branch to be subject to > GPLv3, unless the original author explicitly contributes the patch to the > branch under GPLv2. That doesn't seem an unreasonable requirement and if that's all that's needed to keep the release branches under GPLv2, it seems worth the effort to me.
Re: RFH: GPLv3
> This sounds ideal, but I'm concerned a little bit about how this interacts > with the copyright assignment to FSF. When a contributor assigns copyright > to FSF, do they still have the right to license their changes separately? Yes.
Re: RFH: GPLv3
> Because the FSF says it is not an option. The FSF holds the > copyright and decides on the licensing. True, but RMS has been known to change his mind when people point out to him the consequences of a decision.
Re: RFH: GPLv3
> Richard Kenner writes: >> Because the FSF says it is not an option. The FSF holds the >> copyright and decides on the licensing. Richard> True, but RMS has been known to change his mind when people point out to him Richard> the consequences of a decision. The GCC SC has not been able to persuaded RMS so far. David
Re: RFH: GPLv3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Edelsohn wrote: >> Benjamin Smedberg writes: > > Doug> It seems obvious to me that it would be easiest to just move today's > Doug> mainline over to GPLv3, and have every GCC release >= 4.3 be GPLv3. We > Doug> could then either cut off the GCC 4.2 branch entirely or leave it > Doug> GPLv2. Then there are no surprises for anyone. >>> Leaving released branches as GPLv2 is not an option. That >>> definitely would be the path of least surprise. > > Ben> Why is it not an option? > > Because the FSF says it is not an option. The FSF holds the > copyright and decides on the licensing. Obviously the FSF can relicense any code they want to GPL3... that doesn't mean that this community couldn't decide to only accept patches to the GCC4.2 branch that are licensed under the GPL2+. - --BDS - -- Benjamin Smedberg Platform Guru Mozilla Corporation [EMAIL PROTECTED] http://benjamin.smedbergs.us/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGlk4QSSwGp5sTYNkRAuYhAKCcXUJVQvIzjSfGgJmUo3vDaeu98ACghYPp q2jrLjWBpStLUFRI+5Ui2iY= =WYom -END PGP SIGNATURE-
Re: RFH: GPLv3
David Edelsohn <[EMAIL PROTECTED]> writes: | > Doug Gregor writes: | | Doug> Could we ask the SC to reconsider the change in the GCC major version | Doug> numbering for GPLv3? Or, at the very least, explain why it is | Doug> important to change the major version number for a mere license | Doug> change? | | To avoid confusion among GCC users who do not expect a bug fix | release to introuduce a new license. then, let's close the tree. It is far less confusing than the proposed renaming scheme. -- Gaby
Re: RFH: GPLv3
David Edelsohn wrote: Leaving released branches as GPLv2 is not an option. Dave> What, even *closed* release branches? The comment referred to GCC 4.2. GCC 4.2 branch may not remain under GPLv2. GCC 4.1 branch may not remain under GPLv2. Closing the GCC 4.2 branch is impractical -- we must provide support until the next feature release, currently called GCC 4.3. Any patches backported to a release branch from mainline after mainline is relicensed to GPLv3 will cause the branch to be subject to GPLv3, unless the original author explicitly contributes the patch to the branch under GPLv2. I don't think that's true. Given that all copyrights are assigned to the FSF, the FSF could license these changes as GPLv2+ (in 4.2) and GPLv3+ (in 4.3 and up) without a problem. The original author's wishes do not come into play. Bernd -- This footer brought to you by insane German lawmakers. Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif
Re: RFH: GPLv3
> Bernd Schmidt writes: Bernd> I don't think that's true. Given that all copyrights are assigned to Bernd> the FSF, the FSF could license these changes as GPLv2+ (in 4.2) and Bernd> GPLv3+ (in 4.3 and up) without a problem. The original author's wishes Bernd> do not come into play. Wrong. The original author can license his or her own code to others using different licenses. David
Re: RFH: GPLv3
> Bernd Schmidt writes: Bernd> I don't think that's true. Given that all copyrights are assigned to Bernd> the FSF, the FSF could license these changes as GPLv2+ (in 4.2) and Bernd> GPLv3+ (in 4.3 and up) without a problem. The original author's wishes Bernd> do not come into play. Quoting RMS: "...I recognize that author of a bug fix can make it available under GPLv2" David
Re: RFH: GPLv3
> Bernd> I don't think that's true. Given that all copyrights are assigned to > Bernd> the FSF, the FSF could license these changes as GPLv2+ (in 4.2) and > Bernd> GPLv3+ (in 4.3 and up) without a problem. The original author's > Bernd> wishes do not come into play. > > Wrong. The original author can license his or her own code to > others using different licenses. Yes, but the claim was somewhat the opposite: since any assignments on file were done when GPLv2 was current, one could argue that the author has ALREADY consented to release their code under both GPLv2 and GPLv3 without any further approval. I agree with that as well, but also see the point that once the patch has been placed into a GPLv3 file, it's quite unclear what license would result from a "backport" of the patch: in some sense, you'd have to start from the original (GPLv2) patch and apply it to the branch rather than a more conventional "backport". What a mess!
Re: RFH: GPLv3
Mark Mitchell wrote: The GCC SC is still discussing a few of the finer points of the transition to GPLv3. 3. After GCC 4.2.1 is released, we will renumber the branch to GCC 4.3. What would have been GCC 4.2.2 will instead be GCC 4.3.3, to try to emphasize the GPLv3 switch. The GCC mainline will then be GCC 4.4. This seems to confabulate the meaning of version numbers to now mean something about licensing. The difference between 4.2.1 and 4.2.2 would normally be considered a minor bug fix release, under this scheme of calling it 4.3.3, one would be misled to think that this is a minor bug fix for a non-existent minor release. The version numbering scheme correlating to functional changes is more valuable than any (IMO insubstantial) benefit of identifying the change in license version. -- Michael Eager[EMAIL PROTECTED] 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: RFH: GPLv3
David Edelsohn wrote: Bernd Schmidt writes: Bernd> I don't think that's true. Given that all copyrights are assigned to Bernd> the FSF, the FSF could license these changes as GPLv2+ (in 4.2) and Bernd> GPLv3+ (in 4.3 and up) without a problem. The original author's wishes Bernd> do not come into play. Wrong. The original author can license his or her own code to others using different licenses. Under the license assignment, both FSF and the author can license the code under different licenses. -- Michael Eager[EMAIL PROTECTED] 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: RFH: GPLv3
On Thu, Jul 12, 2007 at 05:53:52PM +0200, Bernd Schmidt wrote: > I don't think that's true. Given that all copyrights are assigned to the > FSF, > the FSF could license these changes as GPLv2+ (in 4.2) and GPLv3+ (in 4.3 and > up) without a problem. The original author's wishes do not come into play. I believe the key point here is that the FSF does not wish to do so. -- Daniel Jacobowitz CodeSourcery
Re: RFH: GPLv3
Ian Lance Taylor wrote: Mark Mitchell <[EMAIL PROTECTED]> writes: 2. GCC 4.2.1 will be the last GPLv2 release. The FSF will permit backports from mainline to GCC 4.2.1, if necessary, to be downlicensed to GPLv2, as part of that release. I believe that we should make a clear statement with that release that any future backport from a later gcc release requires relicensing the changed files to be GPLv3 or later. I believe this is consistent with the two different licensing requirements, and I believe it is feasible if inconvenient for vendors who distribute patched gcc releases. If I understand you, that means that backporting a fix from gcc-4.4 to gcc-3.4 would suddenly make everything in gcc-3.4 fall under GPLv3. I understand that you may be talking about public branches, but there are (many) people who are currently using and maintaining previous releases. The same rules would apply equally to private backports of patches. This would be chaotic. Acme Co's version of gcc-3.4 might be GPLv2 while MegaCorp's gcc-3.4 might be GPLv3. My personal preference would be to acknowledge that for our users there is no significant difference between GPLv2 and GPLv3. And we should acknowledge that people backporting patches from later releases are already going to have to relicense to GPLv3. That's going to stop all private development until corporate legal folks get into sync with GPLv3. The only people who may be discomfited by that choice are distributors of gcc who are unwilling to distribute code licensed under GPLv3. And anyone using any past release. -- Michael Eager[EMAIL PROTECTED] 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: RFH: GPLv3
On Wed, Jul 11, 2007 at 09:58:51PM -0700, Mark Mitchell wrote: > The GCC SC is still discussing a few of the finer points of the > transition to GPLv3. > > However, here are the things that have now been decided: > > 1. The compiler proper (e.g., files used only in cc1, cc1plus, the > driver, etc.) should all be converted to GPLv3 ASAP. > > Will someone (or someones) please volunteer to change the various files > that mention GPLv2 to mention GPLv3 instead, to change the COPYING file > in the gcc/ directory, and to look for other things that need to change? > > 2. GCC 4.2.1 will be the last GPLv2 release. The FSF will permit > backports from mainline to GCC 4.2.1, if necessary, to be downlicensed > to GPLv2, as part of that release. > > 3. After GCC 4.2.1 is released, we will renumber the branch to GCC 4.3. > What would have been GCC 4.2.2 will instead be GCC 4.3.3, to try to > emphasize the GPLv3 switch. The GCC mainline will then be GCC 4.4. > > It has not yet been decided what to do about files that are part of > run-time libraries and are covered by GPL/LGPL + exception. Therefore, > no changes to > > It has also not yet been decided whether backports of bug-fixes from > GPLv3 versions of GCC to older GPLv2 versions of GCC (e.g., GCC 4.1) > will result in the patched compilers being GPLv3. If you have thoughts > about that, you might wish to contact the FSF. As a user, I would prefer not to have GCC's version change from 4.2 to 4.3. But assuming the copyright owner (FSF) does want us to change the version number, why not go to 5.2.2 instead of 4.2.2. What would have been 4.3 will now be 5.3 or 6. To accomidate code that checks __GNUC_MAJOR_VERSION__ for feature tests, I would suggest that the historical branches (what is 4.2 and 4.1 right now) keep the major version to 4, but that the new releases (ie what is currently 4.3) would change the major version to 5. To the people that argue changing the major version number should only be reserved for major things, I would respond that changing the license terms *IS A MAJOR THING*, and it furthers the political goals of the FSF. Note, while disclaimers are generally implied, I must stress that in this particular case, it is my opinion, and not necessarily the view of my employer. -- Michael Meissner, AMD 90 Central Street, MS 83-29, Boxborough, MA, 01719, USA [EMAIL PROTECTED]
Host/Target confusion in Dwarf output
I was looking through dwarf2out.c, tracking down the cause for different assembly code being generated when gcc was run on 32-bit and 64-bit hosts. In dwarf2out.c, there are several places where decisions about what to generate in the .s file are based on HOST_BITS_PER_WIDE_INT or HOST_BITS_PER_WIDE_LONG or similar. For example, when generating a long long value, on a 32-bit host, the *target* assembly code will contain two .4byte ops, while on a 64-bit host, a single .8byte op is generated. There are a number of other differences. The assembler for a 32-bit target might not have a .8byte operator. So, when run on a 32-bit host, everything is OK. On a 64-bit host, the assembly fails. It seems to me that the same assembly code should be generated independent of whether gcc is run on a 32-bit or 64-bit host and all of these HOST_* tests should actually be target domain parameters, like BITS_PER_WORD. Comments? -- Michael Eager[EMAIL PROTECTED] 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: RFH: GPLv3
Nick Clifton wrote: > Hi Mark, > >> Will someone (or someones) please volunteer to change the various files >> that mention GPLv2 to mention GPLv3 instead, to change the COPYING file >> in the gcc/ directory, and to look for other things that need to change? > > I volunteer. Thank you! >> It has not yet been decided what to do about files that are part of >> run-time libraries and are covered by GPL/LGPL + exception. Therefore, >> no changes to > > to what ? :-) I assume that there is a missing part of that last > sentence which reads "these files will take place at the moment". Yes, that's correct. Sorry! > I think however that a small change to such files may be necessary. If I > change the contents of the COPYING file over to GPLv3, then I think that it > might be wise to create a new file - COPYING_v2 - which contains the GPLv2 > and which can be referred to in the copyright notice of files which are still > under the GPLv2. Good point! I'd suggest doing this first: make a COPYING_v2, then update GPL/LGPL + exception things to point at it, then change COPYING to v3 and update source files that say "v2 or later". Please err on the side of caution; it will be harder to go back to V2 if we accidentally make something V3 than it will be to go forward to V3 if we miss something. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Failing matrix tests
Is anyone else seeing failures on the gcc.dg/matrix tests? I am getting
the following failures on IA64 HP-UX:
FAIL: gcc.dg/matrix/matrix-1.c scan-ipa-dump-times Flattened 3 dimensions 1
FAIL: gcc.dg/matrix/matrix-2.c scan-ipa-dump-times Flattened 2 dimensions 1
FAIL: gcc.dg/matrix/matrix-3.c scan-ipa-dump-times Flattened 2 dimensions 1
FAIL: gcc.dg/matrix/matrix-6.c scan-ipa-dump-times Flattened 2 dimensions 1
FAIL: gcc.dg/matrix/transpose-1.c scan-ipa-dump-times Flattened 3 dimensions 1
FAIL: gcc.dg/matrix/transpose-1.c scan-ipa-dump-times Transposed 3
FAIL: gcc.dg/matrix/transpose-2.c scan-ipa-dump-times Flattened 3 dimensions 1
FAIL: gcc.dg/matrix/transpose-3.c scan-ipa-dump-times Flattened 2 dimensions 1
FAIL: gcc.dg/matrix/transpose-3.c scan-ipa-dump-times Transposed 2
On my HPPA platforms I also get:
FAIL: gcc.dg/matrix/transpose-4.c scan-ipa-dump-times Flattened 3 dimensions 1
FAIL: gcc.dg/matrix/transpose-4.c scan-ipa-dump-times Transposed 2
FAIL: gcc.dg/matrix/transpose-5.c scan-ipa-dump-times Flattened 3 dimensions 1
FAIL: gcc.dg/matrix/transpose-6.c scan-ipa-dump-times Flattened 3 dimensions 1
The main difference between IA64 HP-UX and IA64 Linux (where I do not
see these failures) is big-endian vs. little-endian so I was wondering
if any other big-endian platforms in particular are seeing these
failures? When I look at the matrix-1.c.038i.matrix-reorg file output
on HP-UX and Linux, the Linux one starts with some comments about
putting symbols into SSA form and doing an incremental SSA update. That
is missing from the HP-UX version, HP-UX starts with:
Matrix "vel"; Escaping Level: 1, Num Dims: 3, Malloc Dims: 1,
mem_init ()
{
Linux (after the SSA comments) has:
Matrix "vel"; Escaping Level: 3, Num Dims: 3, Malloc Dims: 3,
Flattened 3 dimensions
mem_init ()
{
Andrew, I cc'ed you because of this email
, it mentions some
matrix failures on MIPS when testing on the PTR-PLUS branch. I don't
actually know if my failures are related to PTR-PLUS or not.
Steve Ellcey
[EMAIL PROTECTED]
RE: Host/Target confusion in Dwarf output
On 12 July 2007 17:23, Michael Eager wrote: > I was looking through dwarf2out.c, tracking down the > cause for different assembly code being generated > when gcc was run on 32-bit and 64-bit hosts. > > In dwarf2out.c, there are several places where decisions > about what to generate in the .s file are based on > HOST_BITS_PER_WIDE_INT or HOST_BITS_PER_WIDE_LONG or > similar. For example, when generating a long long value, > on a 32-bit host, the *target* assembly code will contain > two .4byte ops, while on a 64-bit host, a single .8byte > op is generated. There are a number of other differences. > > The assembler for a 32-bit target might not have a .8byte > operator. So, when run on a 32-bit host, everything is OK. > On a 64-bit host, the assembly fails. > > It seems to me that the same assembly code should be generated > independent of whether gcc is run on a 32-bit or 64-bit > host and all of these HOST_* tests should actually be > target domain parameters, like BITS_PER_WORD. > > Comments? Sounds right to me. Basing codegen decisions on HOST_ is just plain wrong and has been an ongoing source of bugs down the years. cheers, DaveK -- Can't think of a witty .sigline today
Re: Host/Target confusion in Dwarf output
On 7/12/07, Dave Korn <[EMAIL PROTECTED]> wrote: On 12 July 2007 17:23, Michael Eager wrote: Sounds right to me. Basing codegen decisions on HOST_ is just plain wrong and has been an ongoing source of bugs down the years. Except in this case, the code gen is the same, just the assembly file is different. I don't think comparing two assembly files is a good test, comparing two object files is different and should be the same between the two compilers. -- Pinski
Re: RFH: GPLv3
I would prefer the following numbering: 4.2.1 last full patchlevel release of gcc under GPLv2 4.2.1.x patch releases to gcc 4.2.1 where only patches with GPLv2 license are applied 4.2.2 The first GPLv3 patchlevel release of gcc 4.2 Rationale: Because some people want to stay with GPLv2 for the time being, there undoubtably will be patched gcc 4.2.1 versions that are still GPLv2. By having an official branch for such versions, we make version confusion less likely. By having these versions carry a sub-patchlevel off 4.2.1, it is also apparent that these versions are restricted in what patches can be used, while 4.2.2 and later vesions are not restrained in the same way. Moreover, when someone gets to an ftp site to download a gcc tarball, the 4.2.1.1 version will stick out, and with possibly adding a README.GPLv3 and README.4.2.1.x files, that (in addition to the already discussed announcements / release notes) should be sufficient to inform users of the license change, so we can dispese with a painful version renumbering.
Re: RFH: GPLv3
Mark Mitchell <[EMAIL PROTECTED]> writes: > 1. The compiler proper (e.g., files used only in cc1, cc1plus, the > driver, etc.) should all be converted to GPLv3 ASAP. I'll note that libiberty is not used "only" in gcc. We still need to coordinate that change separately. > 2. GCC 4.2.1 will be the last GPLv2 release. The FSF will permit > backports from mainline to GCC 4.2.1, if necessary, to be downlicensed > to GPLv2, as part of that release. > > 3. After GCC 4.2.1 is released, we will renumber the branch to GCC 4.3. > What would have been GCC 4.2.2 will instead be GCC 4.3.3, to try to > emphasize the GPLv3 switch. The GCC mainline will then be GCC 4.4. I write this with a heavy hand, but... I read these as "4.2.1 is the last 4.2 release". Pulling a 4.3.3 from that branch is, IMHO, stupid and confusing. If 4.2.1 is the last 4.2 release, the 4.2 branch is DEAD (svn topology notwithstanding). The next release cannot be 4.3.3, that makes no sense. The next release would be 4.3.0, regardless of where it came from. However, we've been telling users "feature X will be in 4.3" for some time, please don't turn us into liars. I can see the slashdot headline now: "GCC 4.2.1 to be last 4.2 release; next major release is 4.3.3, without any of the promised 4.3 features." Users don't care about our svn branching structure, they only care about release numbers and functionality. Vendors only care slightly, because they want to know the origin path of changes, but they don't always mirror our branching structure (RH doesn't). But they have to explain features vs version to customers. The SC says they don't have a choice, but they do. They can choose to stay with the current 4.3-as-head and let the 4.2 branch die with 4.2.1 (just hold off the 4.2.1 release until 4.3 is released ;). That honors the FSF's hard-headed goals, without causing confusion for the people who use and care about gcc. I, as a technical contributor, will not support the "4.3.3 follows 4.2.1" decision. If RMS wants to screw the users, let RMS write the patches. I care about the users too much to participate in this type of fiasco. Perhaps others who feel as I do will agree, and the FSF will find that there's nobody left to work on 4.3.3 any more. Then what? As an aside, I consider version numbers to be, at least partially, a technical issue, since so many packaging systems rely on them making sense in a programatical way. In that respect, the SC should not be acting unilaterally, as they are not supposed to make technical decisions.
Re: RFH: GPLv3
Michael Eager <[EMAIL PROTECTED]> writes: > Ian Lance Taylor wrote: > > Mark Mitchell <[EMAIL PROTECTED]> writes: > > > >> 2. GCC 4.2.1 will be the last GPLv2 release. The FSF will permit > >> backports from mainline to GCC 4.2.1, if necessary, to be downlicensed > >> to GPLv2, as part of that release. > > I believe that we should make a clear statement with that release > > that > > any future backport from a later gcc release requires relicensing the > > changed files to be GPLv3 or later. I believe this is consistent with > > the two different licensing requirements, and I believe it is feasible > > if inconvenient for vendors who distribute patched gcc releases. > > If I understand you, that means that backporting a fix from gcc-4.4 > to gcc-3.4 would suddenly make everything in gcc-3.4 fall under GPLv3. > > I understand that you may be talking about public branches, but > there are (many) people who are currently using and maintaining > previous releases. The same rules would apply equally to private > backports of patches. > > This would be chaotic. Acme Co's version of gcc-3.4 might be GPLv2 > while MegaCorp's gcc-3.4 might be GPLv3. Your understanding of what I am saying is correct. I agree that this is not ideal. However, I do not see an alternative. And you didn't propose one. I encourage you to think of one. That said, I don't really agree with your claim that having some versions of gcc 3.4 under GPLv2 and some under GPLv3 will be "chaotic." For gcc users, the licenses simply don't differ significantly. > > My personal preference would be to acknowledge that for our users > > there is no significant difference between GPLv2 and GPLv3. And we > > should acknowledge that people backporting patches from later releases > > are already going to have to relicense to GPLv3. > > That's going to stop all private development until corporate legal > folks get into sync with GPLv3. Correct, for people who distribute gcc. > > The only people who may be discomfited by that choice are distributors > > of gcc who are unwilling to distribute code licensed under GPLv3. > > And anyone using any past release. Incorrect. It only matters for distributors, not users. Again, I am just the messenger here. I would like to see a different approach, but what could that be? Ian
Re: RFH: GPLv3
David Edelsohn <[EMAIL PROTECTED]> writes: > > Ian Lance Taylor writes: > > Ian> To pile on after my earlier message, I would say that the change in > Ian> license does not matter at all, not even a tiny bit, for gcc *users*. > Ian> It only matters for gcc *distributors*. And I think the vastly > Ian> smaller population of gcc distributors can be reached by appropriate > Ian> use of documentation and announcements. > > I completely agree that the license change does not matter in > reality, but reality is different than perception. Members of the GCC SC > have received feedback from users who are concerned. We should address that concern as much as we can, but to me it does not follow that we should change gcc versioning in a peculiar way. I think that will cause more confusion than it will solve. > Some end users need approval from their legal department for a > change of license of their software. This means that the users may need > legal approval for a bug fix because of the license change. As far as I can see, that is going to be true whether or not we bump the release number. If you can explain otherwise, I would love to hear it. > Also, for example see the way that Samba is handling the license > change. Samba is simply bumping to 3.2.0. They aren't moving from 3.0.26 to 3.2.27. If you want to release gcc 4.2.2, and then release gcc 4.3.0 from the gcc 4.2 branch, and make mainline gcc the eventual gcc 4.4.0, I'm on board with that. That is easy enough to understand and not too difficult to implement. What I'm disagreeing with is moving from gcc 4.2.2 to gcc 4.3.3. Ian
Re: RFH: GPLv3
Ian Lance Taylor <[EMAIL PROTECTED]> writes: [...] > My personal preference would be to acknowledge that for our users > there is no significant difference between GPLv2 and GPLv3. And we > should acknowledge that people backporting patches from later releases > are already going to have to relicense to GPLv3. Therefore, we should > simply change gcc 4.2.2 to be GPLv3. This is a lot of churn on the > branch, and I wish it were unnecessary, but presumably the FSF > requires it. I think that choice is the lesser evil. Strongly agreed! Personally, I think that bumping version number is the worst possible solution of all proposed.
RE: Host/Target confusion in Dwarf output
On 12 July 2007 17:51, Andrew Pinski wrote: > On 7/12/07, Dave Korn <[EMAIL PROTECTED]> wrote: >> On 12 July 2007 17:23, Michael Eager wrote: >> >> Sounds right to me. Basing codegen decisions on HOST_ is just plain >> wrong and has been an ongoing source of bugs down the years. > > Except in this case, the code gen is the same, just the assembly file > is different. I don't think comparing two assembly files is a good > test, comparing two object files is different and should be the same > between the two compilers. I think it's not clearly defined: it's one of the goals for gcc to produce the same "output" when compiling a given source with a given set of flags regardless of any of the properties of the host, but I don't think it's specified whether "output" means the assembler source output by gcc itself, or the object filess that are, after all, technically the outputs of gas, not gcc Also, wasn't this part of a problem just a little while ago when 64-bit arithmetic was introduced in gas? I have this memory there was an issue when each of the 32-bit words that make up a 64-bit pair got sign-promoted independently and then something went wrong, or at any rate went differently from when there was a single .8byte value. I'll go see if I can find it in the archives. cheers, DaveK -- Can't think of a witty .sigline today
Re: RFH: GPLv3
Ian Lance Taylor wrote: >>> The only people who may be discomfited by that choice are distributors >>> of gcc who are unwilling to distribute code licensed under GPLv3. >> And anyone using any past release. > > Incorrect. It only matters for distributors, not users. > Again, I am just the messenger here. I would like to see a different > approach, but what could that be? I have suggested to RMS that the FSF allow downlicensing of backports of GPLv3 code that met two condition: (1) the backport fixed a bug, rather than added a feature, and (2) the backport was less than 1000 lines of code. The point of (2) is to prevent abuse of (1). If you claim that some great new feature is a bug fix, you still lose because it's too big. So, you can't avoid GPLv3 by just "backporting" forever; the new GPLv3 features will pull you forward. I also suggested that GCC the 4.2.x branch be permitted to remain GPLv2. But, RMS has said that GCC 4.2.1 must be the last release under GPLv2, and that it happen before the end of July (which was the plan all along). I don't think it's fruitful to discuss any changes to this particular item (e.g., delaying GCC 4.2.1, releasing GCC 4.2.2 as GPLv2, etc.); I think that RMS has made his decision. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: RFH: GPLv3
> Ian Lance Taylor writes: Ian> Samba is simply bumping to 3.2.0. They aren't moving from 3.0.26 to Ian> 3.2.27. Ian> If you want to release gcc 4.2.2, and then release gcc 4.3.0 from the Ian> gcc 4.2 branch, and make mainline gcc the eventual gcc 4.4.0, I'm on Ian> board with that. That is easy enough to understand and not too Ian> difficult to implement. What I'm disagreeing with is moving from gcc Ian> 4.2.2 to gcc 4.3.3. I agree. Let me try to stop some confusion and accusations right here. RMS *did not* request or specify GCC 4.3.3 following GCC 4.2.2. That was a proposal from a member of the GCC SC. The numbering of the first GPLv3 release was not a requirement from RMS or the FSF. David
Re: RFH: GPLv3
I rarely de-lurk, but: It seems to have been suggested that (with at least some new patches being "GPLv2 or later" in some lawful way acceptable to FSF): 0. Bump no version numbers to reflect license changes. It seems to me that there have been proposed (with all new patches being "GPLv3 or later"): 1. Bump both minor and sub-minor numbers. 2. Bump the major number(s). I think that we also could do one of: 3. Bump only the minor numbers, but twice (to avoid 2 different 4.3.x series). Start with new subminors. Changes to 4.2 would go in 4.4.x. Mainline would be in 4.5.x. 4. Bump only the subminor number. Maybe correcting license holes could be considered sort of a bugfix. MHO (best first) is 0,4,3, huge gap 1, 2. -- R. D. Flowers Earth Rising 481 days until they pay 558 days until he leaves
RE: RFH: GPLv3
On 12 July 2007 17:59, Ian Lance Taylor wrote:
> If you want to release gcc 4.2.2, and then release gcc 4.3.0 from the
> gcc 4.2 branch, and make mainline gcc the eventual gcc 4.4.0, I'm on
> board with that. That is easy enough to understand and not too
> difficult to implement. What I'm disagreeing with is moving from gcc
> 4.2.2 to gcc 4.3.3.
I agree with this sentiment. Go from 4.2.2->4.3.3 with no 4.3.{0-2}?
That's just incoherent.
cheers,
DaveK
--
Can't think of a witty .sigline today
Re: RFH: GPLv3
David Edelsohn wrote: > Let me try to stop some confusion and accusations right here. RMS > *did not* request or specify GCC 4.3.3 following GCC 4.2.2. That was a > proposal from a member of the GCC SC. The numbering of the first GPLv3 > release was not a requirement from RMS or the FSF. I don't particularly have a dog in the version number fight. I think it's potentially surprising to have a "bug fix release" contain a major licensing change -- whether or not it particularly affects users, it's certainly a big deal, as witnessed by the fact that it's at the top of the FSF's priority list! But, if there's a clear consensus here, I'm fine with that. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: RFH: GPLv3
Diego Novillo wrote: On 7/12/07 11:43 AM, Richard Kenner wrote: My personal preference would be to acknowledge that for our users there is no significant difference between GPLv2 and GPLv3. I agree with this. I think renaming 4.2.2 to 4.3.3 will result in lots of unnecessary confusion. Likewise. As was suggested on IRC, we could append a letter to the version number (say 4.2.2G) or something distinctive, but don't skip version numbers in such an odd way. I would very much agree with this, if it's possible. 4.2.2_GPLv3, perhaps? This would also allow another release or two from the 4.1 branch, rather than making the decision to close it prematurely for notational reasons. - Brooks
Re: RFH: GPLv3
Michael Eager wrote: Ian Lance Taylor wrote: I believe that we should make a clear statement with that release that any future backport from a later gcc release requires relicensing the changed files to be GPLv3 or later. I believe this is consistent with the two different licensing requirements, and I believe it is feasible if inconvenient for vendors who distribute patched gcc releases. If I understand you, that means that backporting a fix from gcc-4.4 to gcc-3.4 would suddenly make everything in gcc-3.4 fall under GPLv3. I understand that you may be talking about public branches, but there are (many) people who are currently using and maintaining previous releases. The same rules would apply equally to private backports of patches. This would be chaotic. Acme Co's version of gcc-3.4 might be GPLv2 while MegaCorp's gcc-3.4 might be GPLv3. Will, not would. This is, in practice, not an avoidable hypothetical. The alternative would be to allow Acme Co to backport patches and leave the code GPLv2, and if we do that, someone is going to backport enough patches to make a version of gcc-3.4 which is entirely and completely identical to gcc-4.4, and claim that they can distribute it as GPLv2. Even if we were to leave the 4.1 and 4.2 branches open as GPLv2, this problem would still happen with things that only got committed to 4.3 and later. - Brooks
Re: RFH: GPLv3
$.02 from a user who has been following the discussion: 1. Don't jack with the version numbers. This is confusing. 2. Turn off public access to the code while changing license text in the source. 3. Backports to current stuff should stay under current licence, i.e. a gcc 4.2.1 containing bits and pieces of 4.3 should stay under GPLv2 until 4.3 is released. If a 4.2.2 comes out after the release of 4.3, it should go to GPLv3. I.e, all open branches should change licenses at once. 4. gcc should put a short reference to the license in the version string. My MingGW version of gcc describes itself as "gcc version 3.4.5 (mingw special)" A future MinGW version should do something like "gcc version 4.3.0 (mingw special) GPLv3". Every vendor who distributes a tweaked gcc should be requested to to implement this ASAP. 5. It probably wouldn't hurt to have a command-line option to describe the license(s) in more detail. This would be especially useful when using compilers from vendors like AdaCore who have products like GNAT GPL which has a run-time library that is governed by GPL rather than LGPL. 6. gcc isn't the only software product that will be affected by confusion about the license. gcc should provide a small license-display library that users can use in their own products. This would be easy enough for any user to implement, but if it comes with gcc, it would be more likely to be widely used.
Re: RFH: GPLv3
On Thu, 2007-07-12 at 09:58 -0700, Ian Lance Taylor wrote: > If you want to release gcc 4.2.2, and then release gcc 4.3.0 from the > gcc 4.2 branch, and make mainline gcc the eventual gcc 4.4.0, I'm on > board with that. That is easy enough to understand and not too > difficult to implement. What I'm disagreeing with is moving from gcc > 4.2.2 to gcc 4.3.3. This would be similar to going from GCC 3.1.1 to GCC 3.2 when there was a break in binary compatibility. Janis
Re: RFH: GPLv3
Ian Lance Taylor wrote: Michael Eager <[EMAIL PROTECTED]> writes: Ian Lance Taylor wrote: Mark Mitchell <[EMAIL PROTECTED]> writes: 2. GCC 4.2.1 will be the last GPLv2 release. The FSF will permit backports from mainline to GCC 4.2.1, if necessary, to be downlicensed to GPLv2, as part of that release. I believe that we should make a clear statement with that release that any future backport from a later gcc release requires relicensing the changed files to be GPLv3 or later. I believe this is consistent with the two different licensing requirements, and I believe it is feasible if inconvenient for vendors who distribute patched gcc releases. If I understand you, that means that backporting a fix from gcc-4.4 to gcc-3.4 would suddenly make everything in gcc-3.4 fall under GPLv3. I understand that you may be talking about public branches, but there are (many) people who are currently using and maintaining previous releases. The same rules would apply equally to private backports of patches. This would be chaotic. Acme Co's version of gcc-3.4 might be GPLv2 while MegaCorp's gcc-3.4 might be GPLv3. Your understanding of what I am saying is correct. I agree that this is not ideal. However, I do not see an alternative. And you didn't propose one. I encourage you to think of one. Here's an alternative: Since copyright is owned by FSF, they (via the steering committee) can license them under different licenses. Patches applied to gcc-4. are licensed under GPLv3. Patches applied to previous versions are licensed under GPLv2. I understand Daniel's comment that the FSF doesn't want to do this, but the other way is simply chaos. That said, I don't really agree with your claim that having some versions of gcc 3.4 under GPLv2 and some under GPLv3 will be "chaotic." For gcc users, the licenses simply don't differ significantly. Users include legal departments at major (and minor) corporations. I've found myself in the curious position of explaining patent and copyright law to lawyers, and I've even managed to get them to agree with me on rare occasions. I can assert that GPLv2 and GPLv3 are not substantially different, but I have little belief that they will take my word as gospel. I anticipate that almost every legal department will want to review the 11 pages of the GPLv3 in detail before they agree to distribute under that license. This is not high on their priority list and there is no compelling reason why they need to do this before other pressing matters. The simple expedient is that legal departments will say that until they have reviewed GPLv3, that only GPLv2 is acceptable. This makes for an interesting situation. If I develop a patch to correct problem in a client's version of gcc, I can apply it without problem. If I submit it to FSF (although most of my fixes are to proprietary code, some are general), then whether the client can use this under GPLv2 or not depends on whether they get it directly from me or as part of distribution from FSF. Patches which are applied to the head which also fix problems in prior branches would be excluded, since they would be GPLv3. As proposed, applying a GPLv3 patch to any earlier version (whether on a open source branch or not) would convert that version to GPLv3, as I read provisions of GPLv3 5.b and 5.c, which say that the "modified work" must be distributed under *this* license. For public branches, this means that at some unknown time, the entire branch might be converted to GPLv3 and any fix in that branch would become GPLv3, even if that fix were applied months ago. I could pick up a fix on Monday that was GPLv2, and pick up the same fix on Tuesday, and discover (or more likely, not discover) that the same fix was GPLv3. I think this is a fine working definition of chaotic. In the face of chaos, most corporations are going to simply stop and wait for the maelstrom to subside. My personal preference would be to acknowledge that for our users there is no significant difference between GPLv2 and GPLv3. And we should acknowledge that people backporting patches from later releases are already going to have to relicense to GPLv3. That's going to stop all private development until corporate legal folks get into sync with GPLv3. Correct, for people who distribute gcc. All of the semiconductor companies, for instance. The only people who may be discomfited by that choice are distributors of gcc who are unwilling to distribute code licensed under GPLv3. And anyone using any past release. Incorrect. It only matters for distributors, not users. Sorry, where do the users get their versions of GCC? From distributors. Suggesting that you can make it difficult for a distributor to apply fixes to gcc without affecting their users is hiding the impact of the problem. Again, I am just the messenger here. I would like to see a different approach, but what could that be? Dual licensing, where patches applied to exiting G
Re: RFH: GPLv3
Brooks Moses wrote:
Diego Novillo wrote:
On 7/12/07 11:43 AM, Richard Kenner wrote:
My personal preference would be to acknowledge that for our users
there is no significant difference between GPLv2 and GPLv3.
I agree with this. I think renaming 4.2.2 to 4.3.3 will result in
lots of unnecessary confusion.
Likewise. As was suggested on IRC, we could append a letter to the
version number (say 4.2.2G) or something distinctive, but don't skip
version numbers in such an odd way.
I would very much agree with this, if it's possible. 4.2.2_GPLv3, perhaps?
I very much agree with this.
Also (and I am too young to know) how (and when and if) was the GPLv1 -> GPLv2 transition handled? Or is GCC older than
GPLv1 (I am just asking, maybe past history could help).
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet | mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: RFH: GPLv3
Mark Mitchell wrote: David Edelsohn wrote: Let me try to stop some confusion and accusations right here. RMS *did not* request or specify GCC 4.3.3 following GCC 4.2.2. That was a proposal from a member of the GCC SC. The numbering of the first GPLv3 release was not a requirement from RMS or the FSF. I don't particularly have a dog in the version number fight. I think it's potentially surprising to have a "bug fix release" contain a major licensing change -- whether or not it particularly affects users, it's certainly a big deal, as witnessed by the fact that it's at the top of the FSF's priority list! But, if there's a clear consensus here, I'm fine with that. It may be worth pointing out that this is going to happen anyway on the distributed versions, if there are vendors still providing 4.1 (or 4.0) with backported patches. Better, IMHO, to have the FSF address the surprise rather than leave the distributors to do it individually and haphazardly. - Brooks
RE: RFH: GPLv3
On 12 July 2007 18:42, Janis Johnson wrote: > On Thu, 2007-07-12 at 09:58 -0700, Ian Lance Taylor wrote: >> If you want to release gcc 4.2.2, and then release gcc 4.3.0 from the >> gcc 4.2 branch, and make mainline gcc the eventual gcc 4.4.0, I'm on >> board with that. That is easy enough to understand and not too >> difficult to implement. What I'm disagreeing with is moving from gcc >> 4.2.2 to gcc 4.3.3. > > This would be similar to going from GCC 3.1.1 to GCC 3.2 when there > was a break in binary compatibility. Well, it would be more similar to going from 3.1.1 to 3.2.2 and never having had a 3.2.0 or a 3.2.1 . cheers, DaveK -- Can't think of a witty .sigline today
RE: RFH: GPLv3
On Thu, 2007-07-12 at 18:47 +0100, Dave Korn wrote: > On 12 July 2007 18:42, Janis Johnson wrote: > > > On Thu, 2007-07-12 at 09:58 -0700, Ian Lance Taylor wrote: > >> If you want to release gcc 4.2.2, and then release gcc 4.3.0 from the > >> gcc 4.2 branch, and make mainline gcc the eventual gcc 4.4.0, I'm on > >> board with that. That is easy enough to understand and not too > >> difficult to implement. What I'm disagreeing with is moving from gcc > >> 4.2.2 to gcc 4.3.3. > > > > This would be similar to going from GCC 3.1.1 to GCC 3.2 when there > > was a break in binary compatibility. > > Well, it would be more similar to going from 3.1.1 to 3.2.2 and never having > had a 3.2.0 or a 3.2.1 . I meant that Ian's suggestion of going from 4.2.1 to 4.3.0, instead of to 4.3.3, is a good idea and is similar to going from 3.1.1 to 3.2. Janis
Re: RFH: GPLv3
Serge Belyshev wrote: Personally, I think that bumping version number is the worst possible solution of all proposed. To me it seems essential to change the version number when changing the license. Technical compiler folk may not regard the license change as a significant one, but for the user base it is. Many companies using gcc will not be able to move forward to gpl3 based software without their attorneys approving the change, a process that can be time consuming. For such companies, having a very clear notion of what is gpl2 and what is gpl3 may be critical.
Re: Host/Target confusion in Dwarf output
Michael Eager <[EMAIL PROTECTED]> writes: > I was looking through dwarf2out.c, tracking down the > cause for different assembly code being generated > when gcc was run on 32-bit and 64-bit hosts. > > In dwarf2out.c, there are several places where decisions > about what to generate in the .s file are based on > HOST_BITS_PER_WIDE_INT or HOST_BITS_PER_WIDE_LONG or > similar. For example, when generating a long long value, > on a 32-bit host, the *target* assembly code will contain > two .4byte ops, while on a 64-bit host, a single .8byte > op is generated. There are a number of other differences. > > The assembler for a 32-bit target might not have a .8byte > operator. So, when run on a 32-bit host, everything is OK. > On a 64-bit host, the assembly fails. > > It seems to me that the same assembly code should be generated > independent of whether gcc is run on a 32-bit or 64-bit > host and all of these HOST_* tests should actually be > target domain parameters, like BITS_PER_WORD. It is sad but true that there are various cases in gcc which differ based on the size of an integer on the host. So far as I know none of them amount to bugs, but as you've seen they do lead to different code generation. The most obvious difference here is that CONST_INTs in RTL are stored as HOST_WIDE_INTs. And it is that difference which are you seeing, propagated into the debug code. I think that in general it would be good to fix these issues, so that we generate the same assembler code for a given target from any host. The cases to really think through in detail are a 32-bit host and a 64-bit target. With the current definition of RTL, I don't think you can fix dwarf2out.c independently of fixing other parts of the compiler. But, if I am wrong in that, go for it. Ian
Re: RFH: GPLv3
Basile STARYNKEVITCH <[EMAIL PROTECTED]> writes: > Also (and I am too young to know) how (and when and if) was the GPLv1 > -> GPLv2 transition handled? Or is GCC older than GPLv1 (I am just > asking, maybe past history could help). I believe gcc 2.0 was the first GPLv2 version of gcc. There were other significant changes, mainly in the area of supporting RISC processors, so the change in major version number was reasonable anyhow. There were no release branches back then, so there was no major issue with the transition. Ian
Re: Test gcc.c-torture/execute/align-3.c
On 12/07/2007, at 8:30 AM, Steve Ellcey wrote: Feel free to either (a) #ifdef out the first part of the test on IA64, or (b) delete the first part of the test altogether. Since it fails on other platforms (b) seems like the better alternative. OK to checkin this patch? OK. 2007-07-12 Steve Ellcey <[EMAIL PROTECTED]> * gcc.c-torture/execute/align-3.c: Remove function addr check. smime.p7s Description: S/MIME cryptographic signature
kind of regression -fprofile-* between r126538 and r126587
Hi *, when compiling crafty-20.14 with CFLAGS='$(CFLAGS) -Wall -pipe -D_REENTRANT -march=i686 -O3 \ -fprofile-use -fbranch-probabilities -fomit-frame-pointer \ -ftree-vectorize -ftree-vectorizer-verbose=1 -msse2 \ -fno-gcse -mpreferred-stack-boundary=2' with rev. 125687 crafty breaks severly -- with rev. 126538 it compiles and runs smoothly. As you can see, there are a lot of options involved and crafty is a big program so I'm not able to provide a reduced testcase and file a PR in bugzilla. But maybe someone can take this as a hint. Best regards, Thomas p.s.: when compiling without -fprofile-use, there is an almost 10% speedup from r126538 to r126587.. congrats!!! r126538 -> Raw nodes per second: 1043604 r126587 -> Raw nodes per second: 1132738
Re: RFH: GPLv3
Michael Eager <[EMAIL PROTECTED]> writes: > Here's an alternative: > > Since copyright is owned by FSF, they (via the steering committee) > can license them under different licenses. > > Patches applied to gcc-4. are licensed under GPLv3. > Patches applied to previous versions are licensed under GPLv2. Well, we've now seen Mark's proposal along those lines. It is apparently a non-starter with the FSF. > I think this is a fine working definition of chaotic. I think that once legal teams are onboard with GPLv3, it won't be a problem. If they don't get onboard with GPLv3, then they are stuck with previously released versions of gcc, and they will be forced to develop any patches independently. That is not ideal but does not seem to be avoidable. There are competing contradictory requirements. The FSF owns the software, so they win. So it goes. > In the face of chaos, most corporations are going to simply > stop and wait for the maelstrom to subside. Yes. From our point of view as free software developers, I believe that will be not ideal, but acceptable. The maelstrom will subside. It won't take more than a few months. Ian
Re: GCC 4.2.1 Status Report (2007-07-10)
> The next scheduled GCC 4.2.x release is GCC 4.2.1 on July 13th. PR 32199 is a regression in behavior from 4.2.0. Although a libjava build regression is probably not sufficient justification to block the scheduled release, the change that triggered this regression has nothing to do the java/libjava. As of yesterday, libjava still didn't build on hppa2.0w-hp-hpux11.11 with the 4.2.1 branch. Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
Regarding bug 32505
I've been wanting to contribute code to gcc, but since i don't know it too much i thought of starting from this bug (which, btw recreates on my machine with gcc 4.2). I've found out this bug and begun working it. I've started writing code in maybe_process_partial_specialization after push_template_decl. My current idea for how to solve the bug is as following: First, i need to run on DECL_TEMPLATE_INSTANTIATIONS (for each tree in there i should also check that it is an INSTANTIATON and not a SPEICALIZATION) of the most_general_template from which this template has been instantiated. For each instantiation, i need to somehow check two things: 1) Can it be instantiated from the newly created partial specialization? 2) Is the partial specialization more specific than the one from which the instantiation has already been implemented. My question is, how can i find out from which template the existing instantiation has been made? From the check i've made, i think that CLASSTYPE_TI_TEMPLATE always give the most general template, and not it's partial specializations. Is there any way for me to get it? I've tried doing something using most_specialized_class (not successful) and I believe that it may work too, but it may be less efficient. I hope I'm sending this to the right people, have a nice day and thanks in advance. -- 11101010 - it's a way of life
Re: Host/Target confusion in Dwarf output
On Jul 12, 2007, at 9:23 AM, Michael Eager wrote: I was looking through dwarf2out.c, tracking down the cause for different assembly code being generated when gcc was run on 32-bit and 64-bit hosts. When QAing, it is very useful to be able to compare two .s files. This means that we should strive for them being bit identical. Does that mean we should do tons of work to make that happen, no, or waste tons of compile time to make that happen, no. But, if at all possible and reasonable to do, we should do it. For the harder cases, just think of a long term strategy to make it work, and try and socialize that direction to go in.
Re: Host/Target confusion in Dwarf output
Ian Lance Taylor wrote: Michael Eager <[EMAIL PROTECTED]> writes: It seems to me that the same assembly code should be generated independent of whether gcc is run on a 32-bit or 64-bit host and all of these HOST_* tests should actually be target domain parameters, like BITS_PER_WORD. It is sad but true that there are various cases in gcc which differ based on the size of an integer on the host. So far as I know none of them amount to bugs, but as you've seen they do lead to different code generation. The most obvious difference here is that CONST_INTs in RTL are stored as HOST_WIDE_INTs. And it is that difference which are you seeing, propagated into the debug code. In this case, the difference is not trivial. On a 64-bit host, gcc generates code that the assembler rejects and, if I recall correctly, DWARF_FORM_8 which is not supported by the target binutils. That latter may be a binutils defect. Either way, it counts as a bug if the compile doesn't finish. Why would the RTL represent target CONST_INT as HOST_WIDE_INT? Confusion between host and target? I think that in general it would be good to fix these issues, so that we generate the same assembler code for a given target from any host. The cases to really think through in detail are a 32-bit host and a 64-bit target. I don't have that combination, that could be problematic. With the current definition of RTL, I don't think you can fix dwarf2out.c independently of fixing other parts of the compiler. But, if I am wrong in that, go for it. Jeez, I hope that's not the case. I don't want to start fixing a small problem in DWARF output and end up re-architecting the RTL. (I'm exaggerating, but only a little). -- Michael Eager[EMAIL PROTECTED] 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: Host/Target confusion in Dwarf output
Mike Stump wrote: On Jul 12, 2007, at 9:23 AM, Michael Eager wrote: I was looking through dwarf2out.c, tracking down the cause for different assembly code being generated when gcc was run on 32-bit and 64-bit hosts. When QAing, it is very useful to be able to compare two .s files. This means that we should strive for them being bit identical. Does that mean we should do tons of work to make that happen, no, or waste tons of compile time to make that happen, no. But, if at all possible and reasonable to do, we should do it. For the harder cases, just think of a long term strategy to make it work, and try and socialize that direction to go in. Agreed. I probably wouldn't have noticed the differences if they didn't cause the compile to fail. If the differences were benign, as I first though, I probably would have shrugged, said "that's not good", and continued on. -- Michael Eager[EMAIL PROTECTED] 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: Host/Target confusion in Dwarf output
> Why would the RTL represent target CONST_INT as HOST_WIDE_INT? HOST_WIDE_INT is the wide integer type used throughout the compiler. -- Eric Botcazou
Re: RFH: GPLv3
On 7/12/07, Mark Mitchell <[EMAIL PROTECTED]> wrote: Ian Lance Taylor wrote: >>> The only people who may be discomfited by that choice are distributors >>> of gcc who are unwilling to distribute code licensed under GPLv3. >> And anyone using any past release. > > Incorrect. It only matters for distributors, not users. > Again, I am just the messenger here. I would like to see a different > approach, but what could that be? I have suggested to RMS that the FSF allow downlicensing of backports of GPLv3 code that met two condition: (1) the backport fixed a bug, rather than added a feature, and (2) the backport was less than 1000 lines of code. The point of (2) is to prevent abuse of (1). If you claim that some great new feature is a bug fix, you still lose because it's too big. So, you can't avoid GPLv3 by just "backporting" forever; the new GPLv3 features will pull you forward. I also suggested that GCC the 4.2.x branch be permitted to remain GPLv2. But, RMS has said that GCC 4.2.1 must be the last release under GPLv2, and that it happen before the end of July (which was the plan all along). I don't think it's fruitful to discuss any changes to this particular item (e.g., delaying GCC 4.2.1, releasing GCC 4.2.2 as GPLv2, etc.); I think that RMS has made his decision. As the 4.1 branch, while we don't expect any new releases from it, is still open for bugfixes, can we as GCC community decide to only accept dual-licensed (so, fine for GPL v2) patches to it? Otherwise we should definitely close this branch. Richard.
Re: Host/Target confusion in Dwarf output
Eric Botcazou wrote: Why would the RTL represent target CONST_INT as HOST_WIDE_INT? HOST_WIDE_INT is the wide integer type used throughout the compiler. I haven't looked at the definition. Is it guaranteed to hold all target integer sizes? How does this work for 32-bit hosts and 64-bit targets? -- Michael Eager[EMAIL PROTECTED] 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: RFH: GPLv3
Ian Lance Taylor wrote: If they don't get onboard with GPLv3, then they are stuck with previously released versions of gcc, and they will be forced to develop any patches independently. That is not ideal but does not seem to be avoidable. There are competing contradictory requirements. The FSF owns the software, so they win. So it goes. Seems absolutely avoidable, IMO. I'm not exactly sure what the actual requirement are, but I don't see that they need to be contradictory. With flexibility comes adoption of the GPLv3. With dogma and inflexibility comes resistance. The current plan applies the GPLv3 not just to the future releases, but also indirectly to past releases. That may or may not have been anticipated, but it looks like the result. That's at odds with what I understand to be the FSF's public statements about GPLv3. The rationale that "FSF owns the code" so "FSF dictates the rules" is one of the least appealing aspects of this. [I'll put away my soap box. For now.] -- Michael Eager[EMAIL PROTECTED] 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: GCC 4.2.1 Status Report (2007-07-10)
On 7/12/07, John David Anglin <[EMAIL PROTECTED]> wrote: > The next scheduled GCC 4.2.x release is GCC 4.2.1 on July 13th. PR 32199 is a regression in behavior from 4.2.0. Although a libjava build regression is probably not sufficient justification to block the scheduled release, the change that triggered this regression has nothing to do the java/libjava. Except it was done to fix insane times compiling other things. It is a traditional time/space tradeoff for an extremely large file. I warned at the point I committed it that it may cause issues. It has indeed caused memory issues on some platforms. I'm working on some more memory usage reduction for points-to. Though at some point i can't backport everything in 4.3 into 4.2 to make it work like 4.3 does.
Re: Host/Target confusion in Dwarf output
> HOST_WIDE_INT is the wide integer type used throughout the compiler. I haven't looked at the definition. Is it guaranteed to hold all target integer sizes? No. How does this work for 32-bit hosts and 64-bit targets? Often we use "long long" for HOST_WIDE_INT, but in other cases, the answer is "not as well as we might like".
Re: Host/Target confusion in Dwarf output
> How does this work for 32-bit hosts and 64-bit targets? Some (most?) 64-bit targets require a 64-bit HOST_WIDE_INT. -- Eric Botcazou
Re: Host/Target confusion in Dwarf output
> > How does this work for 32-bit hosts and 64-bit targets? > > Some (most?) 64-bit targets require a 64-bit HOST_WIDE_INT. They don't REQUIRE it, but just miss a lot of optimization if that isn't the case (since things that would otherwise be CONST_INT will now be CONST_DOUBLE and folding will be harder).
Re: RFH: GPLv3
DJ Delorie wrote: I read these as "4.2.1 is the last 4.2 release". Pulling a 4.3.3 from that branch is, IMHO, stupid and confusing. If 4.2.1 is the last 4.2 release, the 4.2 branch is DEAD (svn topology notwithstanding). The next release cannot be 4.3.3, that makes no sense. The next release would be 4.3.0, regardless of where it came from. However, we've been telling users "feature X will be in 4.3" for some time, please don't turn us into liars. We are, what, about six months out from having the current 4.3 branch ready for release? And 4.2.1 will be released in a week or two, so there's not any present urgency to a further release there yet. We _could_, hypothetically speaking, avoid some of the confusion problems you mention by waiting until mainline is ready for release, and releasing it as 4.4.0, and only _then_ doing the next release in the 4.2-branch sequence (which we'd call 4.3.0). Yes, this would mean that 4.3.0 and 4.4.0 are released essentially simultaneously, and it would mean waiting three extra months for an official 4.2-branch update. Might be worth it, though. On the other hand, this also means that even with the present schedule and stuff, it's only three months or so between "Ok, so here's 4.3.0, which doesn't have what we'd said would be in it" and "And now here's 4.4.0, which does have all that", and that isn't _that_ long. - Brooks
Re: Host/Target confusion in Dwarf output
> They don't REQUIRE it, but just miss a lot of optimization if that isn't > the case (since things that would otherwise be CONST_INT will now be > CONST_DOUBLE and folding will be harder). # need_64bit_hwint Set to yes if HOST_WIDE_INT must be 64 bits wide # for this target. This is true iff this target # supports "long" or "wchar_t" wider than 32 bits. alpha*-*-*) cpu_type=alpha need_64bit_hwint=yes ;; x86_64-*-*) cpu_type=i386 extra_headers="mmintrin.h mm3dnow.h xmmintrin.h emmintrin.h pmmintrin.h tmmintrin.h ammintrin.h smmintrin.h nmmintrin.h" need_64bit_hwint=yes ;; ia64-*-*) extra_headers=ia64intrin.h need_64bit_hwint=yes ;; mips*-*-*) cpu_type=mips need_64bit_hwint=yes ;; powerpc*-*-*) cpu_type=rs6000 extra_headers="ppc-asm.h altivec.h spe.h" need_64bit_hwint=yes case x$with_cpu in xpowerpc64|xdefault64|x6[23]0|x970|xG5|xpower[3456]|xpower6x|xrs64a) cpu_is_64bit=yes ;; esac ;; rs6000*-*-*) need_64bit_hwint=yes ;; sparc64*-*-*) cpu_type=sparc need_64bit_hwint=yes ;; spu*-*-*) cpu_type=spu need_64bit_hwint=yes ;; s390*-*-*) cpu_type=s390 need_64bit_hwint=yes ;; sh[123456789lbe]*-*-*) cpu_type=sh need_64bit_hwint=yes ;; -- Eric Botcazou
Re: Host/Target confusion in Dwarf output
> > They don't REQUIRE it, but just miss a lot of optimization if that isn't > > the case (since things that would otherwise be CONST_INT will now be > > CONST_DOUBLE and folding will be harder). > > # need_64bit_hwint Set to yes if HOST_WIDE_INT must be 64 bits wide > # for this target. This is true iff this target > # supports "long" or "wchar_t" wider than 32 bits. Sorry: I guess my information is dated. What changed so that it's now required?
Trouble with powerpc64 mfpgpr patch
I extracted the MFPGPR hunks from Peter Bergner's "[PATCH] Add POWER6
machine description", posted on 2006-11-01 and dropped them into
gcc-4.0.3, but the result fails with "error: insn does not satisfy its
constraints":
.../src/gcc-4.0.3/gcc/config/rs6000/darwin-ldouble.c: In function
'__gcc_qadd':
.../src/gcc-4.0.3/gcc/config/rs6000/darwin-ldouble.c:127: error: insn
does not satisfy its constraints:
(insn 193 64 152 4
.../src/gcc-4.0.3/gcc/config/rs6000/darwin-ldouble.c:110 (set (reg:DF 10 10)
(plus:DF (reg:DF 34 2 [orig:124 D.1365 ] [124])
(reg:DF 32 0 [146]))) 177 {*adddf3_fpr} (nil)
(expr_list:REG_DEAD (reg:DF 34 2 [orig:124 D.1365 ] [124])
(expr_list:REG_DEAD (reg:DF 32 0 [146])
(nil
.../src/gcc-4.0.3/gcc/config/rs6000/darwin-ldouble.c:127: internal
compiler error: in copyprop_hardreg_forward_1, at regrename.c:1583
Please submit a full bug report,
with preprocessed source if appropriate.
The complaint is about operand[0], which is an integer register with
DFmode. FYI, I did my own work to put mftgpr/mffgpr into GCC-4.0.x last
year, and ran into this same problem. I solved it by changing the
operand predicates everywhere I found an "f" constraint so that the
predicate only allowed FP regs rather than the permissive
gpc_reg_operand. Alhough this worked, I didn't like it because the
change was very invasive, so when I saw that Peter's patch didn't muck
with the FP operand predicates, I wanted to use it instead. Alas, I
have the same problem with integer registers matching gpc_reg_operand,
but not satisfying the "f" constraint. What am I missing? Is there
something inhospitable about GCC-4.0 vs. the trunk for Peter's
changes? The patch I used is attached.
Thanks, Greg
2006-11-01 Pete Steinmetz <[EMAIL PROTECTED]>
Peter Bergner <[EMAIL PROTECTED]>
* config/rs6000/rs6000.md (define_attr "type"): Add mffgpr
and mftgpr attributes.
(floatsidf2,fix_truncdfsi2): use TARGET_MFPGPR.
(fix_truncdfsi2_mfpgpr): New.
(floatsidf_ppc64_mfpgpr): New.
(floatsidf_ppc64): Added !TARGET_MFPGPR condition.
(movdf_hardfloat64_mfpgpr,movdi_mfpgpr): New.
(movdf_hardfloat64): Added !TARGET_MFPGPR condition.
(movdi_internal64): Added !TARGET_MFPGPR and related conditions.
* config/rs6000/rs6000.h (TARGET_MFPGPR): New.
(SECONDARY_MEMORY_NEEDED): Use TARGET_MFPGPR.
(SECONDARY_MEMORY_NEEDED): Added mode!=DFmode and mode!=DImode
conditions.
Index: gcc-4.0.3/gcc/config/rs6000/rs6000.h
===
--- gcc-4.0.3.orig/gcc/config/rs6000/rs6000.h
+++ gcc-4.0.3/gcc/config/rs6000/rs6000.h
@@ -201,6 +201,9 @@ extern int target_flags;
/* Use single field mfcr instruction. */
#define MASK_MFCRF 0x0008
+/* Use FP <-> GP register moves. */
+#define MASK_MFPGPR0x0020
+
/* The only remaining free bits are 0x0060. linux64.h uses
0x0010, and sysv4.h uses 0x0080 -> 0x4000.
0x8000 is not available because target_flags is signed. */
@@ -223,6 +226,7 @@ extern int target_flags;
#define TARGET_SCHED_PROLOG(target_flags & MASK_SCHED_PROLOG)
#define TARGET_ALTIVEC (target_flags & MASK_ALTIVEC)
#define TARGET_AIX_STRUCT_RET (target_flags & MASK_AIX_STRUCT_RET)
+#define TARGET_MFPGPR (target_flags & MASK_MFPGPR)
/* Define TARGET_MFCRF if the target assembler supports the optional
field operand for mfcr and the target processor supports the
@@ -234,7 +238,6 @@ extern int target_flags;
#define TARGET_MFCRF 0
#endif
-
#define TARGET_32BIT (! TARGET_64BIT)
#define TARGET_HARD_FLOAT (! TARGET_SOFT_FLOAT)
#define TARGET_UPDATE (! TARGET_NO_UPDATE)
@@ -365,6 +368,10 @@ extern int target_flags;
N_("Generate single field mfcr instruction")}, \
{"no-mfcrf", - MASK_MFCRF, \
N_("Do not generate single field mfcr instruction")},\
+ {"mfpgpr", MASK_MFPGPR,\
+ N_("Generate moves between floating and general
registers")}, \
+ {"no-mfpgpr",- MASK_MFPGPR,
\
+ N_("Do not generate moves between floating and general
registers")},\
SUBTARGET_SWITCHES \
{"", TARGET_DEFAULT | MASK_SCHED_PROLOG, \
""}}
@@ -1413,12 +1420,18 @@ enum reg_class
secondary_reload_class (CLASS, MODE, IN)
/* If we are copying between FP or AltiVec registers and anything
- else, we need a memory location. */
-
-#define SECONDARY_MEMORY_NEEDED(CLASS1,CLASS2,MODE)\
- ((CLASS1) != (CLASS2) && ((CLASS1) == FLOAT_REGS \
- || (CLASS2) == FL
Re: Host/Target confusion in Dwarf output
> Sorry: I guess my information is dated. What changed so that it's now > required? I presume the reasons you gave + the usual nasty bugs prompted someone to decide that it was not worth the troubles after all. -- Eric Botcazou
Re: Host/Target confusion in Dwarf output
Eric Botcazou wrote: How does this work for 32-bit hosts and 64-bit targets? Some (most?) 64-bit targets require a 64-bit HOST_WIDE_INT. Meaning that I can't build gcc-ppc64 on an IA32 host? Yuck! So much for cross-platform tools. -- Michael Eager[EMAIL PROTECTED] 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: Host/Target confusion in Dwarf output
On 7/12/07, Michael Eager <[EMAIL PROTECTED]> wrote: Meaning that I can't build gcc-ppc64 on an IA32 host? HUH? Yes you can, HWI is a64bit integer type there (aka long long). -- Pinski
