GSoC: OMPD conversation
Hello team, I just wanted to give an update to my current progress. I spent most of the time looking over OMPD documentation again and studying LLVM's approach to it. > > > > If it is all the same, and since I am familiar with working on github, > may > > I work on github? I took the liberty of creating the fork of gcc-mirror > to > > my account. I would like to create a major develop branch within the > fork, > > and create minor develop branches from that branch. I would also like to > > plan out my tasks using their Issue tracking system. The minor develop > > branch code would be reviewed via PR by any interested parties, > > particularly Jakub, after which it would be squash-merged to the major > > develop branch of the fork. We can discuss further on the interval for > the > > patch-via-email process to merge the code to upstream, which I assume > would > > happen when the code reaches certain maturity, or at least at the end of > > this project. > > If that is how you like to work, I guess we can try it out. Just please > keep in mind that: > > 1) We are used to reviewing patches in our email clients and prefer it >to reviews in web-based tools. I have quite a lot of customizations >in place that I am used to and so prefer it to >one-method-fits-everyone web tools. > I understand. This kind of information is exactly what I wanted to know so I can adjust my work process to fit the community needs. My I follow the above process of making PR but also create a patch using 'git diff' command and share that with the mailing list? > > 2) Do not spend too much time thinking about how to organize the >project. The time is better spent actually thinking about the >project itself, particularly because I expect this one to entail a >lot of experimenting with an occasional dead end. > I understand. I just thought this discussion belonged to me getting to know how to work with the community and therefore fit the community bonding period theme. I am very excited to get to actually work, too. > > >> Having said that, if you'd like to do a hangouts video call to say hello > >> to each other and perhaps to discuss some issues with setting up your > >> work, I personally am definitely happy to do that too. As a regular > >> communication tool, I did not find videoconferencing to be very useful > >> in the past (but I guess I can be persuaded to try again). > > > > Hmm. In my last coop that ended during pandemic, we used the video > > conferencing tool to do daily stand-ups so the team can keep tabs on how > > different parts of the project is going and give suggestions as needed. A > > little off-topic, but how often would you like to discuss my progress of > > the project? > > So... ideally the stream of emails discussing the overall approach, > followed by a stream of patches and reviews would make it completely > unnecessary to ask you for some kind of regular status reports. > Nevertheless, if some task takes you more than a 4-5 work-days in which > you don't get back to us, please send us a quick summary of what you > have been working on. This arrangement of course means that you need to > reach out to us if you believe you are stuck, so please do. > > But let me reiterate that I am willing to try a videoconference or two > if you think it would be useful at any point. > Would it be nice to have a face-to-face conversation perhaps in the first week of June? Perhaps open to any interested community member to discuss the beginnings of the OMPD? > > >> > >> Dumps will show you what the compiler produces but most of the work in > >> this project will probably be done in the run-time library libgomp. So > >> look at its source, the generated dump files should show you what are > >> the entry points and when they are called. Please make sure you > >> understand how the library works for simple OpenMP (example) programs. > >> Ask more questions. > >> > > I will try compiling the test cases you mentioned and try to understand > the > > gimple more in depth. I will also try to see which part of the libgomp is > > making the translation. Is it correct for me to assume that libgomp is > all > > about reading C code and manipulate GIMPLE? > > > > No, GCC, the compiler, reads C and then goes through various stages of > intermediate representations of the C code, one of which is gimple, > optimizes it and produces an assembly. > > If that C file contains OpenMP directives (and you compile with > -fopenmp) many of those are converted in one way or another into calls > into the "GNU offloading and multi-processing (run-time) library:" > libgomp. It used to be just GNU OpenMP library but now it is also the > run-time library for OpenACC. > > For example, #pragma omp parallel is compiled in a way that the body of > the construct is outlined into a special artificial function and the > construct itself is compiled into a call to a function GOMP_parallel, > with a reference to the function w
Re: Two new proposals to the upcoming C2X standard
Hi David, -Wsizeof-pointer-div isn't required by the standard, so any compiler other than gcc or clang is not required to emit anything to the user. In such compilers, the security risk would still be there and would be up to the maintainers' willingness to implement such feature (or developers' to provide their own safe ARRAY_SIZE macro, if possible). IMHO, the standard should find a way to detect this situation at compile-time, which is the reason why I though a new keyword (_Lengthof) would provide better semantics than status quo and a way to emit a meaningful diagnostic message if being incorrectly used. However, I would like _Typeof/typeof + to be added to the standard too, although I am not sure whether this has been already suggested to the committee (if so, with no success). Could you please help me bringing up reasons why it should be proposed to the committee? I would prefer _Typeof over C++'s decltype to avoid confusion among users. C and C++ compatibility is already too complex to provide yet another keyword that has slightly different behavior depending on the language. OTOH, I see no suggestions regarding the second proposal (static compound literals inside body functions). Do you find this proposal acceptable? Thank you very much for your feedback. -- Xavier Del Campo Romero May 29, 2020, 08:06 by david.br...@hesbynett.no: > On 28/05/2020 23:01, Xavier Del Campo Romero via Gcc wrote: > >> Hello gcc team, >> >> I have sent the following proposals to the committee, but they require them >> to be implemented at least into two major compilers, so I am proposing them >> to be implemented into gcc. This is going to be a rather lengthy e-mail, so >> TL;DR: >> >> Proposal 1: New pointer-proof keyword _Lengthof to determine array length >> Motivation: solve silent bugs when a pointer is accidentally used instead of >> an array >> > > In gcc, the simple "#define ARRAY_SIZE(a) sizeof (a) / sizeof *(a)" gives a > compile-time warning if passed a pointer, since the introduction of > "-Wsizeof-pointer-div" in -Wall in gcc 8. > > I am not convinced that anyone who would be careful enough in their coding to > use such a new "_Lengthof" feature would not already be using "-Wall" at > least. So for gcc, the new keyword would, I think, be useless. And for any > compiler without an equivalent warning (clang has it from version 7), it > would likely to be easier to add the warning rather than the keyword. > > Many people have figured out alternative "ARRAY_SIZE" macros that work with > existing compilers and give compile-time warnings on naked pointers. But > like your suggestion below, they rely on compiler extensions such as gcc's > "typeof". > > > So my counter-proposal for you would be to recommend gcc's "typeof" as a new > keyword (spelt "_Typeof", with "typeof" as a macro in , in solid > C tradition). > > Then you have a feature that has a long-established history in two major > compilers (gcc and clang, at least), has been massively used in real-world > code for decades, and has a huge range of useful use-cases. Get "typeof" into > the C standards and many people will thank you! And then your _Lengthof > becomes a simple macro that can be put in a standard header file, and needs > no established implementation to be acceptable. (And you don't need any help > from gcc or clang, except perhaps for describing the details of the semantics > of "typeof".) >
Re: [IMPORTANT] ChangeLog related changes
On Tue, May 26, 2020 at 03:14:02PM +0200, Andreas Schwab wrote:
> On Mai 26 2020, Martin Liška wrote:
>
> > subprocess.check_output('git show --name-only --pretty="" | '
> > 'grep ChangeLog | '
>
> git show --name-only --pretty= -- '*ChangeLog*'
Or even just
git checkout HEAD $(git show --name-only --pretty= -- '*ChangeLog*')
after you did any such attempted backport that touched changelogs, and
you should be good to go.
(This is also easy to do manually).
Segher
Re: Two new proposals to the upcoming C2X standard
Hi, On 31/05/2020 22:24, Xavier Del Campo Romero wrote: Hi David, -Wsizeof-pointer-div isn't required by the standard, so any compiler other than gcc or clang is not required to emit anything to the user. In such compilers, the security risk would still be there and would be up to the maintainers' willingness to implement such feature (or developers' to provide their own safe ARRAY_SIZE macro, if possible). IMHO, the standard should find a way to detect this situation at compile-time, which is the reason why I though a new keyword (_Lengthof) would provide better semantics than status quo and a way to emit a meaningful diagnostic message if being incorrectly used. The suggested _Lengthof does not add any semantics or changes to the language - a program that uses _Lengthof correctly (i.e., with a parameter that does not give an error) could equally have used a plain ARRAY_SIZE macro to get identical semantics and identical code. For code that is designed for "release" - for people other than the authors or maintainers to use - it makes no difference. It is a feature that is only useful as an aid to developers who are interested in using tools with good warning messages, and interested in using those tools as much as possible (otherwise they wouldn't bother with a C20 specific feature). Such users will already get warnings from gcc or clang, or use macros like Linux's safe array size macro (or equivalents for whatever compiler and tools they use for development). These things don't need to be supported by a range of compilers. So as far as I see it, the only people that would be interested in using _Lengthof already have access to the safety if gives, and the people who probably /should/ use it, would not. The idea in itself is not bad, but I feel that the practice is not going to be useful to anyone. However, I would like _Typeof/typeof + to be added to the standard too, although I am not sure whether this has been already suggested to the committee (if so, with no success). Could you please help me bringing up reasons why it should be proposed to the committee? It is very useful, and it has existed for many years in at least two compilers. (I guess I could give a number of examples of where I have found it useful, if you need it.) I would prefer _Typeof over C++'s decltype to avoid confusion among users. C and C++ compatibility is already too complex to provide yet another keyword that has slightly different behavior depending on the language. Agreed. "typeof" predates "decltype" and I don't think "decltype" would add anything useful to C that you don't get from "typeof". Adding "typedef" to C2x would just be documenting and standardising a long-standing existing feature. OTOH, I see no suggestions regarding the second proposal (static compound literals inside body functions). Do you find this proposal acceptable? I thought it seems perfectly reasonable, but had nothing to add beyond that - so I left it for others to comment. Thank you very much for your feedback. Thank /you/ for trying to improve the language standard. It is not an easy task! mvh., David -- Xavier Del Campo Romero May 29, 2020, 08:06 by david.br...@hesbynett.no: On 28/05/2020 23:01, Xavier Del Campo Romero via Gcc wrote: Hello gcc team, I have sent the following proposals to the committee, but they require them to be implemented at least into two major compilers, so I am proposing them to be implemented into gcc. This is going to be a rather lengthy e-mail, so TL;DR: Proposal 1: New pointer-proof keyword _Lengthof to determine array length Motivation: solve silent bugs when a pointer is accidentally used instead of an array In gcc, the simple "#define ARRAY_SIZE(a) sizeof (a) / sizeof *(a)" gives a compile-time warning if passed a pointer, since the introduction of "-Wsizeof-pointer-div" in -Wall in gcc 8. I am not convinced that anyone who would be careful enough in their coding to use such a new "_Lengthof" feature would not already be using "-Wall" at least. So for gcc, the new keyword would, I think, be useless. And for any compiler without an equivalent warning (clang has it from version 7), it would likely to be easier to add the warning rather than the keyword. Many people have figured out alternative "ARRAY_SIZE" macros that work with existing compilers and give compile-time warnings on naked pointers. But like your suggestion below, they rely on compiler extensions such as gcc's "typeof". So my counter-proposal for you would be to recommend gcc's "typeof" as a new keyword (spelt "_Typeof", with "typeof" as a macro in , in solid C tradition). Then you have a feature that has a long-established history in two major compilers (gcc and clang, at least), has been massively used i
gcc-11-20200531 is now available
Snapshot gcc-11-20200531 is now available on https://gcc.gnu.org/pub/gcc/snapshots/11-20200531/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 11 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch master revision 0edfc1fd22405ee8e946101e44cd8edc0ee12047 You'll find: gcc-11-20200531.tar.xz Complete GCC SHA256=0fd609056587f3b4e2d15d754b89fe514ef06ec88fffcc0183f1b19af8fc47c2 SHA1=e5b1285666712341b28cd8bcb62cedfde6f1ec60 Diffs from 11-20200524 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-11 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: [RFC] Closing of all remaining Bugzilla PRs against powerpcspe
> Hi, > > > PRs from the second group were filed by me, so if there's consensus to > close all > of them, the ones from this second group I can close myself. I don't have > the > right permissions to modify PRs reported by someone else, so I'd like to > ask a > volunteer to step up and close the ones from the first group. > > WDYT? I can do both, if you want, or just the first group? Your choice. But let's hear other opinions first. >>> >>> Thanks. I think I'll close the second group myself, as they constitute >>> almost >>> half of the total amount. >> >> Okido, thanks! > > Two full weeks have passed without any new input from either former port > maintainer or global maintainers, so it's probably about time to go ahead and > wrap it up. Segher, ping?
