Re: Versions of Perl on GCC Prerequisites page
On Thu, Jul 23, 2020 at 9:59 AM Thomas Koenig wrote: > > On the page https://gcc.gnu.org/install/prerequisites.html it says: > > > > Perl version between 5.6.1 and 5.6.24 > > > > Necessary when targeting Darwin, building ‘libstdc++’, and not using > > --disable-symvers. Necessary when targeting Solaris 2 with Solaris ld and > > not using --disable-symvers. > > > > Necessary when regenerating Makefile dependencies in libiberty. Necessary > > when regenerating libiberty/functions.texi. Necessary when generating > > manpages from Texinfo manuals. Used by various scripts to generate some > > files included in the source repository (mainly Unicode-related and > rarely > > changing) from source tables. > > > > Used by automake. > > > > My impression is that Perl 5.6.x is long obsolete (5.6.0 was released in > > March 2000), and the available 5.6.x versions were 5.6.0, 5.6.1 and 5.6.2 > > (never 5.6.24). Much later versions of Perl (5.32.0 is current) will > work > > fine. > > Do they also work with --enable-maintainer-mode? IIRC, they break with > automake. > Not sure, but… If not, then we should leave it as it is. > There is no Perl 5.6.24 — there never was a Perl 5.6.24. There was never a Perl 5.6.3, or Perl 5.6.4, let alone 5.6.24. Therefore, the upper version number should be changed to a valid version of Perl — or eliminated with "or any later version of Perl 5.x" or some such verbiage. Maybe the intent is to cite Perl 5.24 or 5.24.0. And if it is, then maybe that can be updated to Perl 5.32.0, and maybe it can't. But Perl 5.6.24 is WRONG because it is a non-existent version of Perl. I'm not sure what the upper version number should be changed to, but citing a fictional version doesn't help anyone (though people have ignored the fiction for a long time so maybe it doesn't hurt much). I don't mind about the lower version number — at least version 5.6.1 existed, and it might, I suppose, still be in use in some places, though it seems unlikely that anyone using or maintaining GCC 10.2.0 would be using such an antique version of Perl. There might be a good reason why 5.6.0 can't be used but 5.6.1 can — I fear that such fine-grained detail is probably lost in the mists of history. Wikipedia gives a history of Perl versions, but mainly for the 5.x.0 versions for stable releases (so it omits 5.7.x, 5.9.x and all other versions above 5.6 with an odd minor version number, as those are development/unstable versions): https://en.wikipedia.org/wiki/Perl_5_version_history The PerlDoc site gives a very detailed version history including release candidates, etc: https://perldoc.perl.org/perlhist.html Equally, if no-one else cares about the fictional version, then I guess I've raised a pointless issue. Sorry. -- Jonathan Leffler #include Guardian of DBD::Informix - v2018.1031 - http://dbi.perl.org "Blessed are we who can laugh at ourselves, for we shall never cease to be amused."
Re: Loading plugins with arm-none-eabi-gcc
Sorry I am a newbie to cross compilation, but overall, as far as I can see, the following two options both won't work: 1. If I compile instrument_cov.so with gcc as a x86-64bit ELF executable, then it throws the above error (mentioned in my first email) when being loaded by arm-none-eabi-gcc 2. If I compile instrument_cov.so with arm-none-eabi-gcc as a ARM executable, while it looks "consistent" with arm-none-eabi-gcc, but how come it can be correctly loaded and executed on my Ubuntu x86-64 bit? That does not make any sense, right? Am I missing something? Best, Shuai On Wed, Jul 22, 2020 at 7:22 PM Shuai Wang wrote: > Dear Andrew, > > Thanks a lot. Let me make sure I understand the entire picture here. So > basically on my Ubuntu 18.04 x86 machine, I use: > > 1. gcc (version 10.0; x86) to compile arm-none-eabi-gcc. > > 2. And also use gcc (version 10.0; x86) to compile the plugin; I tested a > number of x86 applications and the plugin works fine. > > 3. Right now I want to use arm-none-eabi-gcc to load the plugin and do > some instrumentation on the GIMPLE code of a program, which is going to be > compiled into an ARM binary code. > > So your point is that this won't work, am I right? You are expecting to: > > 1. gcc (version 10.0; x86) to compile arm-none-eabi-gcc. > > 2. And also use arm-none-eabi-gcc to compile the plugin > > 3. Use arm-none-eabi-gcc to load the plugin and do some instrumentation on > the GIMPLE code of a program, which is going to be compiled into an ARM > binary code. > > Am I right? Then my question is, what binary format at step 2 I need to > compile the plugin program into? x86, or ARM? > > Best, > Shuai > > > > On Wed, Jul 22, 2020 at 4:20 PM Andrew Pinski wrote: > >> On Wed, Jul 22, 2020 at 12:45 AM Shuai Wang >> wrote: >> > >> > Hey Andrew, >> > >> > Thanks a lot for getting back to me. No I am not. Let me clarify the >> context here: >> > >> > 1. On my Ubuntu (x86-64 version), I use x86 gcc (version 10.0) to >> compile this plugin, and test this plugin on various programs' GIMPLE code >> during its compilation with x86 gcc (version 10.0). >> > >> > 2. Then, I switched to use arm-none-eabi-gcc to load this plugin, and >> encountered the above issue. >> >> Right because you did not recompile the plugin to use the headers of >> arm-none-eabi-gcc compiler. You need to recompile the plugin for that >> compiler using the native GCC you compiled the compiler with; that is >> you might need to recompile the compiler too. >> There is no stable plugin API/ABI here and that is what you are running >> into. >> >> Thanks, >> Andrew >> >> > >> > 3. Since I am doing a cross-platform compilation (on Ubuntu x86), I am >> anticipating to NOT directly compile my plugin (as a typical .so shared >> library) into an ARM library, right? Otherwise it cannot be loaded and >> executed on x86 Ubuntu, right? >> > >> > 4. Then it seems to me that still, the proper way is to compile a x86 >> plugin, and then somewhat use the arm-none-eabi-gcc to load the plugin >> during cross architecture compilation? >> > >> > Best, >> > Shuai >> > >> > >> > >> > On Wed, Jul 22, 2020 at 3:20 PM Andrew Pinski >> wrote: >> >> >> >> On Tue, Jul 21, 2020 at 11:25 PM Shuai Wang via Gcc >> wrote: >> >> > >> >> > Hello, >> >> > >> >> > I am currently trying to migrate a gcc plugin that has been well >> developed >> >> > for x86 code to ARM platform (for arm-none-eabi-gcc). >> >> > >> >> > Currently I did the following steps: >> >> > >> >> > 1. write a hello world program t.c >> >> > >> >> > 2. compile with the following commands: >> >> > >> >> > ➜ arm-none-eabi-gcc -v >> >> > .. >> >> > gcc version 9.3.1 20200408 (release) (GNU Arm Embedded >> Toolchain >> >> > 9-2020-q2-update) >> >> > >> >> > ➜ arm-none-eabi-gcc -S -mcpu=cortex-m3 -mthumb -fdump-tree-all >> t.c >> >> > >> >> > It works fine, and can smoothly print out all gimple code at >> different >> >> > stages. >> >> > >> >> > 3. Load my plugin (the plugin is compiled by x64 gcc version 10.0): >> >> > >> >> > ➜ file instrument_san_cov.so >> >> > instrument_san_cov.so: ELF 64-bit LSB shared object, x86-64, version >> 1 >> >> > (SYSV), dynamically linked, with debug_info, not stripped >> >> > ➜ file arm-none-eabi-gcc >> >> > arm-none-eabi-gcc: ELF 64-bit LSB executable, x86-64, version 1 >> (SYSV), >> >> > dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for >> GNU/Linux >> >> > 2.6.24, BuildID[sha1]=fbadd6adc8607f595caeccae919f3bab9df2d7a6, >> stripped >> >> > >> >> > ➜ arm-none-eabi-gcc -fplugin=./instrument_cov.so -S -mcpu=cortex-m3 >> >> > -mthumb -fdump-tree-all t.c >> >> > cc1: error: cannot load plugin ./instrument_cov.so >> >> >./instrument_cov.so: undefined symbol: >> >> > _Z20build_string_literaliPKcP9tree_nodem >> >> > >> >> > ➜ c++filt -n _Z20build_string_literaliPKcP9tree_nodem >> >> > build_string_literal(int, char const*, tree_node*, unsigned long) >> >> > >> >> > >> >> > It s
gcc-8-20200723 is now available
Snapshot gcc-8-20200723 is now available on https://gcc.gnu.org/pub/gcc/snapshots/8-20200723/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 8 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-8 revision 41c072bded24642d6b4a38e3f5e2890c1aa8c5a1 You'll find: gcc-8-20200723.tar.xzComplete GCC SHA256=3010160a430c615563910810c6e560833dac23c8bd7d0df819ecec4c7799cae6 SHA1=376ca93a274c109c6742b9313c069c1696c75136 Diffs from 8-20200716 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-8 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.
Re: Versions of Perl on GCC Prerequisites page
Hi Jonathan, On the page https://gcc.gnu.org/install/prerequisites.html it says: Perl version between 5.6.1 and 5.6.24 Necessary when targeting Darwin, building ‘libstdc++’, and not using --disable-symvers. Necessary when targeting Solaris 2 with Solaris ld and not using --disable-symvers. Necessary when regenerating Makefile dependencies in libiberty. Necessary when regenerating libiberty/functions.texi. Necessary when generating manpages from Texinfo manuals. Used by various scripts to generate some files included in the source repository (mainly Unicode-related and rarely changing) from source tables. Used by automake. My impression is that Perl 5.6.x is long obsolete (5.6.0 was released in March 2000), and the available 5.6.x versions were 5.6.0, 5.6.1 and 5.6.2 (never 5.6.24). Much later versions of Perl (5.32.0 is current) will work fine. Do they also work with --enable-maintainer-mode? IIRC, they break with automake. If not, then we should leave it as it is. Regards Thomas
Re: Versions of Perl on GCC Prerequisites page
Hi Jonathan, > On the page https://gcc.gnu.org/install/prerequisites.html it says: > > Perl version between 5.6.1 and 5.6.24 > > Necessary when targeting Darwin, building ‘libstdc++’, and not using > --disable-symvers. Necessary when targeting Solaris 2 with Solaris ld and > not using --disable-symvers. > > Necessary when regenerating Makefile dependencies in libiberty. Necessary > when regenerating libiberty/functions.texi. Necessary when generating > manpages from Texinfo manuals. Used by various scripts to generate some > files included in the source repository (mainly Unicode-related and rarely > changing) from source tables. > > Used by automake. > > My impression is that Perl 5.6.x is long obsolete (5.6.0 was released in > March 2000), and the available 5.6.x versions were 5.6.0, 5.6.1 and 5.6.2 > (never 5.6.24). Much later versions of Perl (5.32.0 is current) will work > fine. Should the range of usable versions be updated? Should it list > 5.6.1 to 5.32.0? Or should it list some slightly later version such as > 5.10.1 as the lowest supported version? why would you raise the minimum version if older onces continue to work? That just confuses users of older systems for no gain. Unless we know that versions beyond a certain point don't work, I'd remove the upper limit. However, before doing so the rationale for the current limit should be investigated and both uses (Darwin and Solaris) checked. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Versions of Perl on GCC Prerequisites page
On the page https://gcc.gnu.org/install/prerequisites.html it says: Perl version between 5.6.1 and 5.6.24 Necessary when targeting Darwin, building ‘libstdc++’, and not using --disable-symvers. Necessary when targeting Solaris 2 with Solaris ld and not using --disable-symvers. Necessary when regenerating Makefile dependencies in libiberty. Necessary when regenerating libiberty/functions.texi. Necessary when generating manpages from Texinfo manuals. Used by various scripts to generate some files included in the source repository (mainly Unicode-related and rarely changing) from source tables. Used by automake. My impression is that Perl 5.6.x is long obsolete (5.6.0 was released in March 2000), and the available 5.6.x versions were 5.6.0, 5.6.1 and 5.6.2 (never 5.6.24). Much later versions of Perl (5.32.0 is current) will work fine. Should the range of usable versions be updated? Should it list 5.6.1 to 5.32.0? Or should it list some slightly later version such as 5.10.1 as the lowest supported version? -- Jonathan Leffler #include Guardian of DBD::Informix - v2018.1031 - http://dbi.perl.org "Blessed are we who can laugh at ourselves, for we shall never cease to be amused."
Re: New x86-64 micro-architecture levels
On Thu, Jul 23, 2020 at 5:44 AM Michael Matz wrote: > > Hello, > > On Wed, 22 Jul 2020, Mallappa, Premachandra wrote: > > > > That's deliberate, so that we can use the same x86-* names for 32-bit > > > library selection (once we define matching micro-architecture levels > > > there). > > > > Understood. > > > > > If numbers are out, what should we use instead? > > > x86-sse4, x86-avx2, x86-avx512? Would that work? > > > > Yes please, I think we have to choose somewhere, above would be more > > descriptive > > And IMHO that's exactly the problem. These names should _not_ be > descriptive, because any description invokes a wrong feeling of precision. > E.g. what Florian already mentioned: sse4 - does it imply 4.1 and 4.2, or > avx512: what of F, CD, ER, PF, VL, DQ, BW, IFMA, VBMI, 4VNNIW, 4FMAPS, > VPOPCNTDQ, VNNI, VBMI2, BITALG, VP2INTERSECT, GFNI, VPCLMULQDQ, VAES does > that one imply (rhethorical question, list shown just to make sillyness > explicit). > > Regarding precision: I think we should rule out any mathematically correct > scheme, e.g. one in which every ISA subset gets an index and the directory > name contains a hexnumber constructed by bits with the corresponding index > being one or zero, depending on if the ISA subset is required or not: I > think we're currently at about 40 ISA subsets, and hence would end up in > names like x86-32001afff and x86-22001afef (the latter missing two subset > compared to the former). > > No, IMHO the non-vendor names should be non-descript, and either be > numbers or characters, of which I would vote for characters, i.e. A, B, C. > Obviously, as already mentioned here, the mapping of level to feature set > needs to be described in documentation somewhere, and should be maintained > by either glibc, glibc/gcc/llvm or psABI people. > > I don't have many suggestions about vendor names, be them ISA-subset > market names, or core names or company names. I will just note that using > such names has lead to an explosion of number of names without very good > separation between them. As long as we're only talking about -march= > cmdline flags that may have been okay, if silly, but under this proposal > every such name is potentially a subdirectory containing many shared > libraries, and one that potentially needs to be searched at every library > looking in the dynamic linker; so it's prudent to limit the size of this > name set as well. > > As for which subsets should or shouldn't be required in which level: I > think the current suggestions all sound good, ultimately it's always going > to be some compromise. > We can have x86-64, x86-64-v1, x86-64-v2, .. These pseudo names should be clearly documented. -- H.J.
RE: New x86-64 micro-architecture levels
Hello, On Wed, 22 Jul 2020, Mallappa, Premachandra wrote: > > That's deliberate, so that we can use the same x86-* names for 32-bit > > library selection (once we define matching micro-architecture levels there). > > Understood. > > > If numbers are out, what should we use instead? > > x86-sse4, x86-avx2, x86-avx512? Would that work? > > Yes please, I think we have to choose somewhere, above would be more > descriptive And IMHO that's exactly the problem. These names should _not_ be descriptive, because any description invokes a wrong feeling of precision. E.g. what Florian already mentioned: sse4 - does it imply 4.1 and 4.2, or avx512: what of F, CD, ER, PF, VL, DQ, BW, IFMA, VBMI, 4VNNIW, 4FMAPS, VPOPCNTDQ, VNNI, VBMI2, BITALG, VP2INTERSECT, GFNI, VPCLMULQDQ, VAES does that one imply (rhethorical question, list shown just to make sillyness explicit). Regarding precision: I think we should rule out any mathematically correct scheme, e.g. one in which every ISA subset gets an index and the directory name contains a hexnumber constructed by bits with the corresponding index being one or zero, depending on if the ISA subset is required or not: I think we're currently at about 40 ISA subsets, and hence would end up in names like x86-32001afff and x86-22001afef (the latter missing two subset compared to the former). No, IMHO the non-vendor names should be non-descript, and either be numbers or characters, of which I would vote for characters, i.e. A, B, C. Obviously, as already mentioned here, the mapping of level to feature set needs to be described in documentation somewhere, and should be maintained by either glibc, glibc/gcc/llvm or psABI people. I don't have many suggestions about vendor names, be them ISA-subset market names, or core names or company names. I will just note that using such names has lead to an explosion of number of names without very good separation between them. As long as we're only talking about -march= cmdline flags that may have been okay, if silly, but under this proposal every such name is potentially a subdirectory containing many shared libraries, and one that potentially needs to be searched at every library looking in the dynamic linker; so it's prudent to limit the size of this name set as well. As for which subsets should or shouldn't be required in which level: I think the current suggestions all sound good, ultimately it's always going to be some compromise. Ciao, Michael.
Re: GCC 10.2 Released
On Thu, 23 Jul 2020 at 12:19, Jonathan Wakely wrote: > > On Thu, 23 Jul 2020 at 09:34, ireng ajah via Gcc wrote: > > > > Hi.. > > > > Can you remove my email from your list? > > No, you have to do it yourself. See > https://gcc.gnu.org/lists.html#subscribe for instructions. I followed those simple instructions and sent an unsubscribe request for you. Just click on the link in the email.
Re: GCC 10.2 Released
On Thu, 23 Jul 2020 at 09:34, ireng ajah via Gcc wrote: > > Hi.. > > Can you remove my email from your list? No, you have to do it yourself. See https://gcc.gnu.org/lists.html#subscribe for instructions.
Re: t/47153851 GCC 10.2 Released
Could somebody at Google please turn this crap off. It might be confused by the change in the List-Id headers a few months ago, but whatever the reason, please stop it. On Thu, 23 Jul 2020 at 08:56, Google Ticket System via Gcc wrote: > > You have been CC'd on a Google Ticket The GNU Compiler > Collection version 10.2 has been released. > > GCC 10.2 is a bug-fix release from the GCC 10 branch > containing important fixes for regressions and serious bugs in > GCC 10.1 with more than 94 bugs fixed since the previous release. > > This release is available from the FTP servers listed at: > > http://www.gnu.org/order/ftp.html > > Please do not contact me directly regarding questions or comments > about this release. Instead, use the resources available from > http://gcc.gnu.org. > > As always, a vast number of people contributed to this GCC release > -- far too many to thank them individually! > Reply to this email to update this ticket.
Re: t/47153851 GCC 10.2 Released
You have been CC'd on a ticket that has been updated. Message from Could somebody at Google please turn this crap off. It might be confused by the change in the List-Id headers a few months ago, but whatever the reason, please stop it. On Thu, 23 Jul 2020 at 08:56, Google Ticket System via Gcc wrote: Reply to this email to update this ticket.
Re: ERR: ChangeLog, DATESTAMP, BASE-VER and DEV-PHASE updates
On 7/13/20 5:31 PM, Martin Sebor via Gcc wrote: On 7/13/20 8:21 AM, Martin Sebor wrote: Could someone explain what the following error means and how to avoid it? It's for a commit to the 10 branch with the usual commit message format and changes to only .c/.C files (same as in r11-1899). There's nothing more about the subject of the ERR at the link it points to than what it says. remote: *** ChangeLog format failed: remote: ERR: ChangeLog, DATESTAMP, BASE-VER and DEV-PHASE updates should be done separately from normal commits remote: remote: Please see: https://gcc.gnu.org/codingconventions.html#ChangeLogs remote: remote: error: hook declined to update refs/heads/releases/gcc-10 To git+ssh://gcc.gnu.org/git/gcc.git The cause of the error turned out to be that for some reason, after a rebase, the diff I was trying to push also contained upstream ChangeLog updates that I didn't scroll far enough in the commit log to see. Hello Martin. That seems to me like a quite rare case. I'm not planning to handle it in a special way. Martin I don't know if this happens often enough to make improving the error worthwhile or if it was just my luck that I did something silly this time, but mentioning the pathnames of the changed ChangeLog, DATESTAMP, BASE-VER, and DEV-PHASE files in the error message found in the commit would help avoid the confusion. E.g., something like: remote: Error: found one or more ChangeLog, DATESTAMP, BASE-VER or DEV-PHASE files in commit: ...list of pathnames of files... Updates to these files should be made separately from those to ordinary files. Martin
Invitation
Re: GCC 10.2 Released
Hi.. Can you remove my email from your list? On Thu, 23 Jul 2020 at 14:47, Richard Biener wrote: > The GNU Compiler Collection version 10.2 has been released. > > GCC 10.2 is a bug-fix release from the GCC 10 branch > containing important fixes for regressions and serious bugs in > GCC 10.1 with more than 94 bugs fixed since the previous release. > > This release is available from the FTP servers listed at: > > http://www.gnu.org/order/ftp.html > > Please do not contact me directly regarding questions or comments > about this release. Instead, use the resources available from > http://gcc.gnu.org. > > As always, a vast number of people contributed to this GCC release > -- far too many to thank them individually! > -- Kind Regards Ireng Ajah
Juno Auto Response. Re: GCC 10.2 Released
I am no longer using this email account. Please use other means to contact me so I can give you my new email address. I am no longer using this email account. Please use other means to contact me so I can give you my new email address. I am no longer using this email account. Please use other means to contact me so I can give you my new email address. I am no longer using this email account. Please use other means to contact me so I can give you my new email address. I am no longer using this email account. Please use other means to contact me so I can give you my new email address. I am no longer using this email account. Please use other means to contact me so I can give you my new email address. I am no longer using this email account. Please use other means to contact me so I can give you my new email address. I am no longer using this email account. Please use other means to contact me so I can give you my new email address. I am no longer using this email account. Please use other means to contact me so I can give you my new email address. I am no longer using this email account. Please use other means to contact me so I can give you my new email address. I am no longer using this email account. Please use other means to contact me so I can give you my new email address. I am no longer using this email account. Please use other means to contact me so I can give you my new email address. I am no longer using this email account. Please use other means to contact me so I can give you my new email address. Sponsored by https://www.newser.com/?utm_source=part&utm_medium=uol&utm_campaign=rss_taglines_more 'No Reason for Panic': Worker on White House Grounds Has Virus http://thirdpartyoffers.juno.com/TGL3131/5f193a19c0b5d3a192d37st02duc1 FBI Links 'Anti-Feminist Attorney' to a Second Murder http://thirdpartyoffers.juno.com/TGL3131/5f193a19dc3ff3a192d37st02duc2 AOC Rejects 'Apology' from GOP Congressman http://thirdpartyoffers.juno.com/TGL3131/5f193a1a2b523a192d37st02duc3
t/47153851 GCC 10.2 Released
You have been CC'd on a Google Ticket The GNU Compiler Collection version 10.2 has been released. GCC 10.2 is a bug-fix release from the GCC 10 branch containing important fixes for regressions and serious bugs in GCC 10.1 with more than 94 bugs fixed since the previous release. This release is available from the FTP servers listed at: http://www.gnu.org/order/ftp.html Please do not contact me directly regarding questions or comments about this release. Instead, use the resources available from http://gcc.gnu.org. As always, a vast number of people contributed to this GCC release -- far too many to thank them individually! Reply to this email to update this ticket.
GCC 10.2 Released
The GNU Compiler Collection version 10.2 has been released. GCC 10.2 is a bug-fix release from the GCC 10 branch containing important fixes for regressions and serious bugs in GCC 10.1 with more than 94 bugs fixed since the previous release. This release is available from the FTP servers listed at: http://www.gnu.org/order/ftp.html Please do not contact me directly regarding questions or comments about this release. Instead, use the resources available from http://gcc.gnu.org. As always, a vast number of people contributed to this GCC release -- far too many to thank them individually!
GCC 10.2.1 Status Report (2020-07-23)
Status == The GCC 10.2 release process has been completed and the GCC 10 branch is now again open for regression and documentation fixes. Quality Data Priority # Change from last report --- --- P1 P2 219 + 1 P3 57 + 4 P4 176 P5 22 --- --- Total P1-P3 276 + 5 Total 474 + 5 Previous Report === https://gcc.gnu.org/pipermail/gcc/2020-July/233135.html
