Re: tree decl stored during LGEN does not map to a symtab_node during WPA
Hi, I noticed this is also happening also for local variables. Again, storing tree declarations on a summary during LGEN and then at WPA time reading from those summaries. I can print the declaration, but when I try to look for its node in the symtab I get NULL as the return value. Any help is appreciated. Thanks! On Wed, 7 Jul 2021 at 11:27, Erick Ochoa wrote: > > Hi, > > I am saving some tree declarations during LGEN that I will be later > analyzing at WPA time. I am able to read the decl from my summaries > and print it at WPA time. It corresponds to a global variable. > However, whenever I use symtab_node::get (decl) during WPA time I keep > getting NULL. > > Does anyone know why that might be the case? Is it possible that other > optimizations are rewriting global variables during LGEN (or prior > WPA)? The variable I am looking at is a static const char typeinfo > name for a class in the program I am analyzing. I don't think this is > an issue since other type info names have an associated symtab_node. > > Thanks!
Re: tree decl stored during LGEN does not map to a symtab_node during WPA
On Fri, Jul 9, 2021 at 9:52 AM Erick Ochoa via Gcc wrote: > > Hi, I noticed this is also happening also for local variables. Again, > storing tree declarations on a summary during LGEN and then at WPA > time reading from those summaries. I can print the declaration, but > when I try to look for its node in the symtab I get NULL as the return > value. > > Any help is appreciated. Thanks! I'm not too familiar with it but I think you're supposed to stream encoded symtab references during LGEN/WPA, the decls are subject to symtab merging and I'm not quite sure that happens when you read your summaries. Note locals do not have carpool nodes. Richard. > On Wed, 7 Jul 2021 at 11:27, Erick Ochoa wrote: > > > > Hi, > > > > I am saving some tree declarations during LGEN that I will be later > > analyzing at WPA time. I am able to read the decl from my summaries > > and print it at WPA time. It corresponds to a global variable. > > However, whenever I use symtab_node::get (decl) during WPA time I keep > > getting NULL. > > > > Does anyone know why that might be the case? Is it possible that other > > optimizations are rewriting global variables during LGEN (or prior > > WPA)? The variable I am looking at is a static const char typeinfo > > name for a class in the program I am analyzing. I don't think this is > > an issue since other type info names have an associated symtab_node. > > > > Thanks!
Some libgcc headers are missing the runtime exception
Hi, It was pointed out to me off-list that config/aarch64/value-unwind.h is missing the runtime exception. It looks like a few other files are too; a fuller list is: libgcc/config/aarch64/value-unwind.h libgcc/config/frv/frv-abi.h libgcc/config/i386/value-unwind.h libgcc/config/pa/pa64-hpux-lib.h Certainly for the aarch64 file this was simply a mistake; it seems to have been copied from the i386 version, both of which reference the runtime exception but don't actually include it. What's the procedure for fixing this? Can we treat it as a textual error or do the files need to be formally relicensed? Thanks, Richard
Re: Some libgcc headers are missing the runtime exception
On Fri, Jul 9, 2021 at 12:53 PM Richard Sandiford via Gcc wrote: > > Hi, > > It was pointed out to me off-list that config/aarch64/value-unwind.h > is missing the runtime exception. It looks like a few other files > are too; a fuller list is: > > libgcc/config/aarch64/value-unwind.h > libgcc/config/frv/frv-abi.h > libgcc/config/i386/value-unwind.h > libgcc/config/pa/pa64-hpux-lib.h > > Certainly for the aarch64 file this was simply a mistake; > it seems to have been copied from the i386 version, both of which > reference the runtime exception but don't actually include it. > > What's the procedure for fixing this? Can we treat it as a textual > error or do the files need to be formally relicensed? I'm unsure what you mean by "formally relicensed". It generally is considered a textual omission. The runtime library components of GCC are intended to be licensed under the runtime exception, which was granted and approved at the time of introduction. In addition, it would be good to start adding the correct SPDX License Identifier to all of these files. Thanks, David
Re: Some libgcc headers are missing the runtime exception
David Edelsohn writes: > On Fri, Jul 9, 2021 at 12:53 PM Richard Sandiford via Gcc > wrote: >> >> Hi, >> >> It was pointed out to me off-list that config/aarch64/value-unwind.h >> is missing the runtime exception. It looks like a few other files >> are too; a fuller list is: >> >> libgcc/config/aarch64/value-unwind.h >> libgcc/config/frv/frv-abi.h >> libgcc/config/i386/value-unwind.h >> libgcc/config/pa/pa64-hpux-lib.h >> >> Certainly for the aarch64 file this was simply a mistake; >> it seems to have been copied from the i386 version, both of which >> reference the runtime exception but don't actually include it. >> >> What's the procedure for fixing this? Can we treat it as a textual >> error or do the files need to be formally relicensed? > > I'm unsure what you mean by "formally relicensed". It seemed like there were two possibilities: the licence of the files is actually GPL + exception despite what the text says (the textual error case), or the licence of the files is plain GPL because the text has said so since the introduction of the files. In the latter case I'd have imagined that someone would need to relicense the code so that it is GPL + exception. > It generally is considered a textual omission. The runtime library > components of GCC are intended to be licensed under the runtime > exception, which was granted and approved at the time of introduction. OK, thanks. So would a patch to fix at least the i386 and aarch64 header files be acceptable? (I'm happy to fix the other two as well if that's definitely the right thing to do. It's just that there's more history involved there…) Richard
Re: Some libgcc headers are missing the runtime exception
On Fri, Jul 9, 2021 at 1:31 PM Richard Sandiford wrote: > > David Edelsohn writes: > > On Fri, Jul 9, 2021 at 12:53 PM Richard Sandiford via Gcc > > wrote: > >> > >> Hi, > >> > >> It was pointed out to me off-list that config/aarch64/value-unwind.h > >> is missing the runtime exception. It looks like a few other files > >> are too; a fuller list is: > >> > >> libgcc/config/aarch64/value-unwind.h > >> libgcc/config/frv/frv-abi.h > >> libgcc/config/i386/value-unwind.h > >> libgcc/config/pa/pa64-hpux-lib.h > >> > >> Certainly for the aarch64 file this was simply a mistake; > >> it seems to have been copied from the i386 version, both of which > >> reference the runtime exception but don't actually include it. > >> > >> What's the procedure for fixing this? Can we treat it as a textual > >> error or do the files need to be formally relicensed? > > > > I'm unsure what you mean by "formally relicensed". > > It seemed like there were two possibilities: the licence of the files > is actually GPL + exception despite what the text says (the textual > error case), or the licence of the files is plain GPL because the text > has said so since the introduction of the files. In the latter case > I'd have imagined that someone would need to relicense the code so > that it is GPL + exception. > > > It generally is considered a textual omission. The runtime library > > components of GCC are intended to be licensed under the runtime > > exception, which was granted and approved at the time of introduction. > > OK, thanks. So would a patch to fix at least the i386 and aarch64 header > files be acceptable? (I'm happy to fix the other two as well if that's > definitely the right thing to do. It's just that there's more history > involved there…) Please correct the text in the files. The files in libgcc used in the GCC runtime are intended to be licensed with the runtime exception and GCC previously was granted approval for that licensing and purpose. As you are asking the question, I sincerely doubt that ARM and Cavium intended to apply a license without the exception to those files. And similarly for Intel and FRV. The runtime exception explicitly was intended for this purpose and usage at the time that GCC received approval to apply the exception. Thanks, David
Re: Some libgcc headers are missing the runtime exception
On Fri, Jul 9, 2021 at 10:40 AM David Edelsohn via Gcc wrote: > > On Fri, Jul 9, 2021 at 1:31 PM Richard Sandiford > wrote: > > > > David Edelsohn writes: > > > On Fri, Jul 9, 2021 at 12:53 PM Richard Sandiford via Gcc > > > wrote: > > >> > > >> Hi, > > >> > > >> It was pointed out to me off-list that config/aarch64/value-unwind.h > > >> is missing the runtime exception. It looks like a few other files > > >> are too; a fuller list is: > > >> > > >> libgcc/config/aarch64/value-unwind.h > > >> libgcc/config/frv/frv-abi.h > > >> libgcc/config/i386/value-unwind.h > > >> libgcc/config/pa/pa64-hpux-lib.h > > >> > > >> Certainly for the aarch64 file this was simply a mistake; > > >> it seems to have been copied from the i386 version, both of which > > >> reference the runtime exception but don't actually include it. > > >> > > >> What's the procedure for fixing this? Can we treat it as a textual > > >> error or do the files need to be formally relicensed? > > > > > > I'm unsure what you mean by "formally relicensed". > > > > It seemed like there were two possibilities: the licence of the files > > is actually GPL + exception despite what the text says (the textual > > error case), or the licence of the files is plain GPL because the text > > has said so since the introduction of the files. In the latter case > > I'd have imagined that someone would need to relicense the code so > > that it is GPL + exception. > > > > > It generally is considered a textual omission. The runtime library > > > components of GCC are intended to be licensed under the runtime > > > exception, which was granted and approved at the time of introduction. > > > > OK, thanks. So would a patch to fix at least the i386 and aarch64 header > > files be acceptable? (I'm happy to fix the other two as well if that's > > definitely the right thing to do. It's just that there's more history > > involved there…) > > Please correct the text in the files. The files in libgcc used in the > GCC runtime are intended to be licensed with the runtime exception and > GCC previously was granted approval for that licensing and purpose. > > As you are asking the question, I sincerely doubt that ARM and Cavium > intended to apply a license without the exception to those files. And > similarly for Intel and FRV. Yes I did not intend to apply without the exception. Thanks, Andrew Pinski > > The runtime exception explicitly was intended for this purpose and > usage at the time that GCC received approval to apply the exception. > > Thanks, David
gcc-10-20210709 is now available
Snapshot gcc-10-20210709 is now available on https://gcc.gnu.org/pub/gcc/snapshots/10-20210709/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 10 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-10 revision ca094af16ce810b1e553e000354b5d64a9b90a1a You'll find: gcc-10-20210709.tar.xz Complete GCC SHA256=018a5613465e3e362174108cca2a635e2b136a381e661bada1be27896da99782 SHA1=2ad6abc2ed892c9af7de81619a75806279d30f0d Diffs from 10-20210702 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-10 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Liste "Ertan Altun.. E-MAIL.. aertan...@gmail.com" auf Google Maps ansehen
Google Ertan Altun Ertan Altun Ich habe eine Liste mit dir geteilt In Google Maps ansehen Google © 2018 Google LLC 1600 Amphitheatre Parkway, Mountain View, CA 94043 Von Ertan Altun über Google Maps gesendet
