Weekly Notice-AICSE2020 Invite Papers for Pub.(Ei|CPCI|SCOPUS)
| | | | 01 CALL FOR PAPERS | | Now Submit Research Paper to AICSE2020 Dear authors and scholars, we, as the committee members and speakers, heartily welcome you to Shang-hai (China) for attendance at the AICSE2020 -2020 International Conference on Artificial Intelligence, Computer and Software Engineering! We invite you to give speech on your work of research for discussion with worldwide scholars and we expect you to give advice to make AICSE2020 successful and fruitful! | | 02 | | How to Submit Papers I. Prepare your papers with the template and fill in the submission form before submission. II. Send your paper with the submission form to our email before deadline: aicse2...@sina.com III. Submit before January 13 and please submit your original unpublished papers for reviewing. Please provide contact author name and tel as email subject:Submission+Name+Tel | | Opening AICSE2020 | Visit website: w ww.ai cs e202 0.org | Join and attend on March 22-23, Shanghai (China) Online Publish and Index Papers and articles will all be published if accepted after reviewing and all articles will be updated online with open access (free viewing and downloading). Papers will also be submitted toEi(Engineering), CPCI(ISSHP) and CNKI indexafter publication. | | | | | | | | | | | | | | | |
Re: Frontend access to target-related options
I've found the code for the target hooks for both the C-family and D frontends (or at least their implementation for the i386 platform). The C-family ones seem like they probably are too tied to the preprocessor to be usable for other languages (which I assume is the reason that the D frontend created their own target hooks). I'm not sure if functions like "cpp_assert" and "cpp_define" are actually directly defined or if they have a macro indirection layer (like lang hooks have macro indirection layers with LANG_HOOKS_INIT), but I suspect that they're defined, and so the one-definition rule of C++ prevents any overloading from any other frontend. As such, the C-family target hooks appear to be unusable for my purpose. On the other hand, the D frontend target hooks don't appear to provide enough information relating to the target system to be useful (e.g. they seem to be missing features like SSE support and whatever). As such, I think it looks like I'd have to add a new target hook. How would I go about doing this? Is there any documentation on doing so? Thanks, Theo On Tue, Jan 7, 2020 at 9:16 PM Richard Biener wrote: > On Thu, Jan 2, 2020 at 5:54 PM Nathan Sidwell wrote: > > > > On 1/1/20 4:31 AM, The Other wrote: > > > Hi, > > > I'm currently working on a Rust frontend for GCC. Rust has some > > > language-level conditional compilation features based on the presence > or > > > lack of features in the target architecture (e.g. SSE, AVX, a static C > > > runtime) as well as the target CPU architecture itself, target OS, and > > > various other target-related information (such as pointer width and > > > endianness). > > > > > > As such, the frontend parser requires this target-related option > > > information to be available to it. I was wondering if there was an > > > architecture-neutral way of accessing this data (if it is even stored). > > > I've looked into options.h but I cannot figure out how to use it in an > > > architecture-neutral way. > > > > Um, AVX and such are arch-specific. It sounds like you need some kind > > of (new?) langhook that targets can register? > > You mean target hook. Depending on the actual piece of info such hook > might already exist though. > > Richard. > > > nathan > > > > -- > > Nathan Sidwell >
__patchable_function_entries is flawed
On 2020-01-07, Szabolcs Nagy wrote:
On 07/01/2020 07:25, Fangrui Song wrote:
On 2020-01-06, Fangrui Song wrote:
The addresses of NOPs are collected in a section named
__patchable_function_entries.
A __patchable_function_entries entry is relocated by a symbolic relocation
(e.g. R_X86_64_64, R_AARCH64_ABS64, R_PPC64_ADDR64).
In -shared or -pie mode, the linker will create a dynamic relocation
(non-preemptible: relative relocation (e.g. R_X86_64_RELATIVE);
preemptible: symbolic relocation (e.g. R_X86_64_64)).
In either case, the section contents will be modified at runtime.
Thus, the section should have the SHF_WRITE flag to avoid text relocations
(DF_TEXTREL).
pie/pic should either imply writable __patchable_function_entries,
or __patchable_function_entries should be documented to be offsets
from some base address in the module: the users of it have to modify
.text and do lowlevel hacks so they should be able to handle such
arithmetics.
i think it's worth opening a gcc bug report.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93194 patch posted to gcc-patches.
PC-relative relocation types (R_X86_64_64, R_AARCH64_PREL64,
R_PPC64_REL64) can avoid dynamic relocations, and avoid the need for
SHF_WRITE. Unfortunately, it seems we cannot re-interpret
__patchable_function_entries. I have found 2 other problems with the
current __patchable_function_entries. Perhaps we need a new design.
* https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93197
__patchable_function_entries will always be collected by --gc-sections
(.tmp_vmlinux1 is not linked with --gc-sections, so it appears that
the Linux kernel is not affected.)
I think the solution requires a GNU ld and gold side fix:
https://sourceware.org/bugzilla/show_bug.cgi?id=24526
If you clang>=8, you can play with clang -fstack-size-section -c a.cc
Basically I think __patchable_function_entry has to behave like .stack_sizes .
* https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93195
__patchable_function_entries should consider comdat groups.
It can cause linker failures (GNU ld, gold and lld). It is fairly
easy to trigger with C++ inline.
(OK, the Linux kernel does not speak C++.)
(Clang's function multi-versioning implementation uses comdat, even in
C. I don't have an example with GCC. My GCC __attribute__((target(..))) is
broken.)
The two issues make -fpatchable-function-entry useless for user
applications. I still hope we can make the solution more general, not
restricted to the Linux kernel. We've already implemented enough GCC
options for dynamic ftrace (with regs) and live patching: -mfentry
-mnop-mcount -mrecord-mcount -mhotpatch -fpatchable-function-entry.
FWIW I am working on a clang/llvm patch https://reviews.llvm.org/D72215
I have tried resolving these problems.
("o" (SHF_LINK_ORDER+sh_link) is not recognized by GNU as.)
Re: Frontend access to target-related options
On Wed, Jan 8, 2020 at 1:16 AM The Other wrote: > > I've found the code for the target hooks for both the C-family and D > frontends (or at least their implementation for the i386 platform). The > C-family ones seem like they probably are too tied to the preprocessor to > be usable for other languages (which I assume is the reason that the D > frontend created their own target hooks). I'm not sure if functions like > "cpp_assert" and "cpp_define" are actually directly defined or if they have > a macro indirection layer (like lang hooks have macro indirection layers > with LANG_HOOKS_INIT), but I suspect that they're defined, and so the > one-definition rule of C++ prevents any overloading from any other > frontend. As such, the C-family target hooks appear to be unusable for my > purpose. > > On the other hand, the D frontend target hooks don't appear to provide > enough information relating to the target system to be useful (e.g. they > seem to be missing features like SSE support and whatever). GCC has a generic vector support so usually other languages don't need to export that. What exact information do you need to provide here? That is what does Rust need for SSE support? Can you just use the generic vector support or are there intrinsics (builtins) support that is needed? Do you need to know about the builtins that the target supplies? and then make intrinsics out of them? Why not a rust_target_objs like there is for c_target_objs/cxx_target_objs in config.gcc. Just like how D added d_target_objs too? And then you have one or two defines which will add the builtins like you need to do it. Thanks, Andrew Pinski > As such, I think it looks like I'd have to add a new target hook. How would > I go about doing this? Is there any documentation on doing so? > > Thanks, > Theo > > On Tue, Jan 7, 2020 at 9:16 PM Richard Biener > wrote: > > > On Thu, Jan 2, 2020 at 5:54 PM Nathan Sidwell wrote: > > > > > > On 1/1/20 4:31 AM, The Other wrote: > > > > Hi, > > > > I'm currently working on a Rust frontend for GCC. Rust has some > > > > language-level conditional compilation features based on the presence > > or > > > > lack of features in the target architecture (e.g. SSE, AVX, a static C > > > > runtime) as well as the target CPU architecture itself, target OS, and > > > > various other target-related information (such as pointer width and > > > > endianness). > > > > > > > > As such, the frontend parser requires this target-related option > > > > information to be available to it. I was wondering if there was an > > > > architecture-neutral way of accessing this data (if it is even stored). > > > > I've looked into options.h but I cannot figure out how to use it in an > > > > architecture-neutral way. > > > > > > Um, AVX and such are arch-specific. It sounds like you need some kind > > > of (new?) langhook that targets can register? > > > > You mean target hook. Depending on the actual piece of info such hook > > might already exist though. > > > > Richard. > > > > > nathan > > > > > > -- > > > Nathan Sidwell > >
Re: Frontend access to target-related options
I'm just working from the somewhat incomplete Rust spec at this point - intrinsics and other complicated target-dependent stuff don't seem to be part of it. Rust seems to provide vector intrinsics through libraries with inline assembly. For the frontend, I just need a list of strings describing the "features available", which is used for conditional compilation. Like how you'd use preprocessor macros to do #ifdef __SSE__. Basically, what I need doesn't really have anything to do with vector support - I just need to know about the presence or lack of presence of features. I was intending to do a rust_target_objs if there were no other alternatives, as I would have to do one for every supported target to my knowledge, which seems like a waste of effort if I could leverage a pre-existing target hook. By the way, is the x_target_objs file the only required one for a target hook like that? Or are other files with other code required? Thanks, Theo On Wed, Jan 8, 2020 at 6:04 PM Andrew Pinski wrote: > On Wed, Jan 8, 2020 at 1:16 AM The Other wrote: > > > > I've found the code for the target hooks for both the C-family and D > > frontends (or at least their implementation for the i386 platform). The > > C-family ones seem like they probably are too tied to the preprocessor to > > be usable for other languages (which I assume is the reason that the D > > frontend created their own target hooks). I'm not sure if functions like > > "cpp_assert" and "cpp_define" are actually directly defined or if they > have > > a macro indirection layer (like lang hooks have macro indirection layers > > with LANG_HOOKS_INIT), but I suspect that they're defined, and so the > > one-definition rule of C++ prevents any overloading from any other > > frontend. As such, the C-family target hooks appear to be unusable for my > > purpose. > > > > On the other hand, the D frontend target hooks don't appear to provide > > enough information relating to the target system to be useful (e.g. they > > seem to be missing features like SSE support and whatever). > > GCC has a generic vector support so usually other languages don't need > to export that. > What exact information do you need to provide here? That is what does > Rust need for SSE support? > Can you just use the generic vector support or are there intrinsics > (builtins) support that is needed? > Do you need to know about the builtins that the target supplies? and > then make intrinsics out of them? > > Why not a rust_target_objs like there is for > c_target_objs/cxx_target_objs in config.gcc. > Just like how D added d_target_objs too? > And then you have one or two defines which will add the builtins like > you need to do it. > > Thanks, > Andrew Pinski > > > As such, I think it looks like I'd have to add a new target hook. How > would > > I go about doing this? Is there any documentation on doing so? > > > > Thanks, > > Theo > > > > On Tue, Jan 7, 2020 at 9:16 PM Richard Biener < > richard.guent...@gmail.com> > > wrote: > > > > > On Thu, Jan 2, 2020 at 5:54 PM Nathan Sidwell wrote: > > > > > > > > On 1/1/20 4:31 AM, The Other wrote: > > > > > Hi, > > > > > I'm currently working on a Rust frontend for GCC. Rust has some > > > > > language-level conditional compilation features based on the > presence > > > or > > > > > lack of features in the target architecture (e.g. SSE, AVX, a > static C > > > > > runtime) as well as the target CPU architecture itself, target OS, > and > > > > > various other target-related information (such as pointer width and > > > > > endianness). > > > > > > > > > > As such, the frontend parser requires this target-related option > > > > > information to be available to it. I was wondering if there was an > > > > > architecture-neutral way of accessing this data (if it is even > stored). > > > > > I've looked into options.h but I cannot figure out how to use it > in an > > > > > architecture-neutral way. > > > > > > > > Um, AVX and such are arch-specific. It sounds like you need some > kind > > > > of (new?) langhook that targets can register? > > > > > > You mean target hook. Depending on the actual piece of info such hook > > > might already exist though. > > > > > > Richard. > > > > > > > nathan > > > > > > > > -- > > > > Nathan Sidwell > > > >
[INTERNAL] LLVM v9.0.1
Hi everyone, LLVM v9.0.1 is available at folder “/grid/common/test/llvm-v9.0.1rh65”, for lnx86 platform. This release contains bug-fixes for the LLVM 9.0.0 release. This release is API and ABI compatible with 9.0.0. It is NOT officially supported by Cadence and should NOT be used to compile Cadence products that will be shipped for customers. The proposal is for performance tests and code improvement/verification. IT does NOT contain IWYU(include what you use), because it is still not available for LLVM v9.0.1. Changelog --> http://releases.llvm.org/9.0.0/docs/ReleaseNotes.html Regards, -- Rogerio
Re: Proposal for the transition timetable for the move to GIT
> On Dec 30, 2019, at 7:08 PM, Richard Earnshaw (lists) > wrote: > > On 30/12/2019 15:49, Maxim Kuvyrkov wrote: >>> On Dec 30, 2019, at 6:31 PM, Richard Earnshaw (lists) >>> wrote: >>> >>> On 30/12/2019 13:00, Maxim Kuvyrkov wrote: > On Dec 30, 2019, at 1:24 AM, Richard Earnshaw (lists) > wrote: > > On 29/12/2019 18:30, Maxim Kuvyrkov wrote: >> Below are several more issues I found in reposurgeon-6a conversion >> comparing it against gcc-reparent conversion. >> >> I am sure, these and whatever other problems I may find in the >> reposurgeon conversion can be fixed in time. However, I don't see why >> should bother. My conversion has been available since summer 2019, I >> made it ready in time for GCC Cauldron 2019, and it didn't change in any >> significant way since then. >> >> With the "Missed merges" problem (see below) I don't see how reposurgeon >> conversion can be considered "ready". Also, I expected a diligent >> developer to compare new conversion (aka reposurgeon's) against existing >> conversion (aka gcc-pretty / gcc-reparent) before declaring the new >> conversion "better" or even "ready". The data I'm seeing in differences >> between my and reposurgeon conversions shows that gcc-reparent >> conversion is /better/. >> >> I suggest that GCC community adopts either gcc-pretty or gcc-reparent >> conversion. I welcome Richard E. to modify his summary scripts to work >> with svn-git scripts, which should be straightforward, and I'm ready to >> help. >> > > I don't think either of these conversions are any more ready to use than > the reposurgeon one, possibly less so. In fact, there are still some > major issues to resolve first before they can be considered. > > gcc-pretty has completely wrong parent information for the gcc-3 era > release tags, showing the tags as being made directly from trunk with > massive deltas representing the roll-up of all the commits that were > made on the gcc-3 release branch. I will clarify the above statement, and please correct me where you think I'm wrong. Gcc-pretty conversion has the exact right parent information for the gcc-3 era release tags as recorded in SVN version history. Gcc-pretty conversion aims to produce an exact copy of SVN history in git. IMO, it manages to do so just fine. It is a different thing that SVN history has a screwed up record of gcc-3 era tags. >>> >>> It's not screwed up in svn. Svn shows the correct history information for >>> the gcc-3 era release tags, but the git-svn conversion in gcc-pretty does >>> not. >>> >>> For example, looking at gcc_3_0_release in expr.c with git blame and svn >>> blame shows >> >> In SVN history tags/gcc_3_0_release has been copied off /trunk:39596 and in >> the same commit bunch of files were replaced from /branches/gcc-3_0-branch/ >> (and from different revisions of this branch!). >> >> $ svn log -qv --stop-on-copy file://$(pwd)/tags/gcc_3_0_release | grep >> "/tags/gcc_3_0_release \|/tags/gcc_3_0_release/gcc/expr.c >> \|/tags/gcc_3_0_release/gcc/reload.c " >> A /tags/gcc_3_0_release (from /trunk:39596) >> R /tags/gcc_3_0_release/gcc/expr.c (from >> /branches/gcc-3_0-branch/gcc/expr.c:43255) >> R /tags/gcc_3_0_release/gcc/reload.c (from >> /branches/gcc-3_0-branch/gcc/reload.c:42007) >> > > Right, (and wrong). You have to understand how the release branches and > tags are represented in CVS to understand why the SVN conversion is done > this way. When a branch was created in CVS a tag was added to each > commit which would then be used in any future revisions along that > branch. But until a commit is made on that branch, the release branch > is just a placeholder. > > When a CVS release tag is created, the tag labels the relevant commit > that is to be used. If that commit is unchanged from the trunk revision > (no commit on the branch), then that is what gets labelled, and it > *appears* to still come from trunk - but that does not matter, since it > is the same as the version on trunk. > > The svn copy operations are formed from this set of information by > copying the SVN revision of trunk that applied at the point the branch > was made, and then overriding the copy information for each file that > was then modified on the branch with information about that copy. This > is sufficient for svn to fully understand the history information for > each and every file in the tag. > > Unfortunately, git-svn mis-interprets this when building its graph of > what happened and while it copies the right *content* into the release > branch, it does not copy the right *history*. The SVN R operation > copies the history from named revision, not just the content. That's > the significant difference between the two. > > R >> IMO, from such history (absent e
Re: Proposal for the transition timetable for the move to GIT
Maxim Kuvyrkov : > Once gcc-reparent conversion is regenerated, I'll do another round of > comparisons between it and whatever the latest reposurgeon version is. Thanks, Maxim. Those comparisons have been very helpful to Joseph and Richard and to the reposurgeon devteam as well. They use your feedback to find places where their comment-processing scripts could be improved; we've used it learn what additional oddities in ChangeLogs we need to be able to handle automatically. -- http://www.catb.org/~esr/";>Eric S. Raymond
Re: Proposal for the transition timetable for the move to GIT
On Wed, 8 Jan 2020, Eric S. Raymond wrote: > They use your feedback to find places where their comment-processing > scripts could be improved; we've used it learn what additional > oddities in ChangeLogs we need to be able to handle automatically. I've used comparisons of authors in the two conversions - in cases where they get different human identities for the author, not just different email addresses or name variants - to identify cases for manual review, since ChangeLog parsing is the most subjective part of doing a conversion and cases where different heuristics produce different results indicate those worthy of manual review. Apart from about 1600 with no changes to ChangeLog files but a ChangeLog entry in the commit message, which I reviewed mostly automatically to make sure I agreed with Maxim's author extraction with only limited manual checks on those that looked like suspect cases, that involved reviewing around 3000 commits manually; I've now completed that review. Some of those are also subjective cases even after review (for example, where the commit involved one person backporting another person's patch). In the set of around 1200 commits with both ChangeLog and non-ChangeLog files being changed, which did not look like backports, for example, I arrived at around 400 author improvements from this review (not all of them the same authors as in Maxim's conversion), while for around 800 commits I concluded the reposurgeon author was preferable. (The typical case where reposurgeon does better is where successive commits add new ChangeLog entries under an existing ChangeLog header. The typical case where I added fixes was where a commit made nonsubstantive changes under an existing header, as well as adding new entries, which is hard to distinguish automatically from a multi-author commit so reposurgeon conservatively treats as a multi-author commit.) In the case of ChangeLog-only commits, where reposurgeon assumes they are likely to be fixing typos or similar and so does not extract an attribution from ChangeLog files in such commits, manual review identified many cases (especially in the earlier parts of the history) where the ChangeLog was committed separately from the substantive parts of the patch and so a better attribution could be assigned to those substantive commits. I consider the reposurgeon-based conversion machinery to be in essentially its final state now; I don't have any further authors to review, Richard doesn't have any further Bugzilla-based commit summaries to review and we don't know of any relevant reposurgeon bugs or missing features. I'm running a conversion now to verify both the current state of the fixups and the Makefile integration of the conversion and subsequent automated validation, and will make that converted repository available for final checks if this succeeds. Compared to the previous converted repository, this one has many author fixups, a fix for a bug in the author fixups where they broke commit dates, and reposurgeon improvements to avoid producing unidiomatic empty git commits in the converted repository for things such as branch and tag creation. This converted repository uses the ref rearrangements along the lines proposed by Richard (so dead branches and vendor branches are available but not fetched by default); the objects from the existing git mirror will also be included in the repository (so existing gitweb links to such objects in list archives continue to work, for example, as long as they aren't links to objects that were made unreachable at some point in the mirror's history), but again under ref names that are not fetched by default. As noted on overseers, once Saturday's DATESTAMP update has run at 00:16 UTC on Saturday, I intend to add a README.MOVED_TO_GIT file on SVN trunk and change the SVN hooks to make SVN readonly, then disable gccadmin's cron jobs that build snapshots and update online documentation until they are ready to run with the git repository. Once the existing git mirror has picked up the last changes I'll make that read-only and disable that cron job as well, and start the conversion process with a view to having the converted repository in place this weekend (it could either be made writable as soon as I think it's ready, or left read-only until people have had time to do any final checks on Monday). Before then, I'll work on hooks, documentation and maintainer-scripts updates. As well as having objects from the existing git mirror available under refs that are not fetched by default, that mirror will remain available read-only at git://gcc.gnu.org/git/gcc-old.git (which already exists, currently a symlink to the mirror). -- Joseph S. Myers jos...@codesourcery.com
Comparing types at LTO time
There doesn't seem to be a way to compare types at LTO time. The functions same_type_p and comptypes are front end only if I'm not totally confused (which is quite possible) and type_hash_eq doesn't seem to apply for structure types. Please, any advice would be welcome. Thanks, Gary Oblock
Re: Proposal for the transition timetable for the move to GIT
On Wed, Jan 08, 2020 at 11:34:32PM +, Joseph Myers wrote: > As noted on overseers, once Saturday's DATESTAMP update has run at 00:16 > UTC on Saturday, I intend to add a README.MOVED_TO_GIT file on SVN trunk > and change the SVN hooks to make SVN readonly, then disable gccadmin's > cron jobs that build snapshots and update online documentation until they > are ready to run with the git repository. Once the existing git mirror > has picked up the last changes I'll make that read-only and disable that > cron job as well, and start the conversion process with a view to having > the converted repository in place this weekend (it could either be made > writable as soon as I think it's ready, or left read-only until people > have had time to do any final checks on Monday). Before then, I'll work > on hooks, documentation and maintainer-scripts updates. Where and when and by who was it decided to use this conversion? Will it at least be *tested* first? Segher
Re: Proposal for the transition timetable for the move to GIT
On Wed, 2020-01-08 at 23:34 +, Joseph Myers wrote: > > As noted on overseers, once Saturday's DATESTAMP update has run at 00:16 > UTC on Saturday, I intend to add a README.MOVED_TO_GIT file on SVN trunk > and change the SVN hooks to make SVN readonly, then disable gccadmin's > cron jobs that build snapshots and update online documentation until they > are ready to run with the git repository. Once the existing git mirror > has picked up the last changes I'll make that read-only and disable that > cron job as well, and start the conversion process with a view to having > the converted repository in place this weekend (it could either be made > writable as soon as I think it's ready, or left read-only until people > have had time to do any final checks on Monday). Before then, I'll work > on hooks, documentation and maintainer-scripts updates. Is there any chance we could get one more trunk snapshot before the conversion starts -- even if that means firing up the snapshot process Friday? It'd be quite useful for the ongoing Fedora build testing. If it's a significant hassle, then don't worry, I'll create one manually. Jeff >
