GCC 8.3 Status Report (2019-02-09)
Status == Both GCC 8.3 P1s we had yesterday were fixed, so let's aim for the first release candidate of 8.3 on February, 15th and, if all goes well, for 8.3 release on February, 22nd. Quality Data Priority # Change from last report --- --- P10 - 1 P2 204 + 7 P3 25 - 3 P4 165 P5 24 --- --- Total P1-P3 229 + 3 Total 418 + 3 Previous Report === https://gcc.gnu.org/ml/gcc/2019-02/msg00027.html
Re: GCC 8.3 Status Report (2019-02-09)
On Sat, Feb 9, 2019 at 1:12 AM Jakub Jelinek wrote: > > Status > == > > Both GCC 8.3 P1s we had yesterday were fixed, so let's aim for the first > release candidate of 8.3 on February, 15th and, if all goes well, for > 8.3 release on February, 22nd. > This is a new C++ regression on GCC 8 branch: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89267 > Quality Data > > > Priority # Change from last report > --- --- > P10 - 1 > P2 204 + 7 > P3 25 - 3 > P4 165 > P5 24 > --- --- > Total P1-P3 229 + 3 > Total 418 + 3 > > > Previous Report > === > > https://gcc.gnu.org/ml/gcc/2019-02/msg00027.html -- H.J.
GCC GSOC 2019
Hi, I am Shubham Narlawar. Currently, I am a Computer Engineering undergrad student at Pune University, India. I am interested in contributing to GCC for GSOC 2019. We have done a project from GCC GSOC 2018 idea list which is implementing Csmith fuzzer leveraging GCC C Extensions under the guidance of Andi Kleen. Csmith is a C fuzzer which generates standard C code but no extensions. We implemented few of GCC C extensions in Csmith (which now we call it as "Extended Csmith"). Extended Csmith is now able to fuzz extensions along with standard C code. Following GCC C Extensions are implemented in Csmith currently - 1. Labels as Values (Computed Goto) 2. Local Labels 3. Typeof 4. __int128 - Signed and unsigned integer of size 128 bits. 5. Cast to Union 6. Label attributes - hot cold 7. Variable attributes - a) aligned b) unused c) section 8. Binary constants 9. Statement Expression 10. Transactional memory relaxed - tm_relaxed (not a GCC C extension) Note - Different Combinations of these extensions can be used while generating random C code using extended csmith. Here is the github link of the project. https://github.com/Sameeranjoshi/csmith/tree/gcc-extensions Currently, We are running extended csmith on gcc10 of GCC Compile Farm Project and found following bugs - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89135 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89153 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87118 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89223 We expect to find more bugs in GCC as the gcc compiler is being stress tested now. Code coverage - Csmith vs Extended Csmith Csmith i.e. [without gcc extn ] line - 35.2 function - 43.2 branch - 25.7 Extended Csmith [with gcc extn] line - 35.7 function - 43.9 branch - 26.1 %gain line - 0.5% function - 0.7% branch - 0.4% For GSOC 2019, I am proposing below project idea - Implementation of following extensions in the Csmith - 1. Function attributes - aligned, alloc_align, always_inline, hot, cold, deprecated, nothrow, used, etc 2. Vector extensions 3. Transactional Memory extensions 4. Type attributes and remaining GCC C extensions. Benefits to GCC - 1. Increased code coverage. 2. There is a possibility of finding more bugs after adding the above extensions. Thanks and Regards. Shubham Narlawar
[GSoC 2019] [extending Csmith for fuzzing OpenMp extensions]
Hi,I am an undergraduate student currently in final year of computer science and engineering degree course from Pune University, India. I and Shubham have been working on Last year's GSoC project idea : Implement a fuzzer leveraging GCC extensions. Fuzzers like csmith are fairly good at finding compiler bugs. But they only generate standard C, but no extensions. GCC has many extensions, which are not covered. It would be good to extend a fuzzer like csmith to fuzz extensions like OpenMP, attributes, vector extensions, etc. Then run the fuzzer and report compiler bugs. since June 2018 under the guidance of mentor Andi Kleen. I worked on generating GCC C language extensions here is the link (coverage reports,implemented extension's list,bugs found,test cases, and usage are in README file on github) github Link: https://github.com/Sameeranjoshi/csmith/tree/gcc-extensions We choose this as our university project as well, and are still fuzzing the extensions on compiler farm. Based on the previous work I would like to propose the following idea for GSoC 2019: Extending Csmith for OpenMP extensions. I would implement following constructs of OpenMP 1.PARALLEL CONSTRUCT 2.WORKSHARING CONSTRUCTS - 2.1 sections 2.2 single 2.3 loop constructs 2.4 master construct 3.TEAMS CONSTRUCT 4.TASKING CONSTRUCT - 4.1 task 4.2 taskloop 4.3 taskloop simd 4.4 taskyield 5.SYNCHRONIZATION CONSTRUCTS - 5.1 critical 5.2 atomic 5.3 barrier 5.4 taskwait 5.5 taskgroup 6.DATA SHARING ATTRIBUTES - 6.1 private 6.2 public 6.3 firstprivate 6.4 lastprivate Also, I would like to work on the target constrains if time permits. The main challenge what I think would be to ensure that there aren't any data races and data conflicts so that the parallelized program is not undefined. Usage for the GCC community : 1. It might have slight large increments in code coverage and trigger a lot of unique code . I have watched A "Hands-on" Introduction to OpenMP | Tim Mattson, Intel all 4 parts https://www.youtube.com/watch?v=pRtTIW9-Nr0 I have started reading the specification of latest 5.0 standard. Please suggest if this could be an interesting idea for upcoming GSoC ? Thanks, Sameeran Joshi
