Detecting superfluous "else"
Hi, it makes me 'crazy' when I see such if-else constructs: if (x) return 7; else return 4; (Of course in this case one better would use the shorthand "return x ? 7 : 4;", but that's not the issue here) The 'else' is obviously superfluous/redundant, ie. unneeded at all: if (x) return 7; return 4; Is it possible to warn about such unneccessary occurances of "else"? If not, then I suggest to add a new warning code -Wsuperfluous-else or -Wredundant-else or so. Thx
GCC 8.2 Status Report (2018-07-19), branch frozen for release
Status == The GCC 8 branch is frozen for preparation of the GCC 8.2 release. All changes to the branch now require release manager approval. Previous Report === https://gcc.gnu.org/ml/gcc/2018-07/msg00194.html
Re: [RFC] Adding Python as a possible language and it's usage
* Segher Boessenkool: > What would the advantage of using Python be? I haven't heard any yet. > Awk may be a bit clunky but at least it is easily readable for anyone. I'm not an experienced awk programmer, but I don't think plain awk supports arrays of arrays, so there's really no good way to emulate user-defined data types and structure the code.
GCC 8.2 Release Candidate available from gcc.gnu.org
A release candidate for GCC 8.2 is available from ftp://gcc.gnu.org/pub/gcc/snapshots/8.2.0-RC-20180719/ and shortly its mirrors. It has been generated from SVN revision 262876. I have so far bootstrapped and tested the release candidate on x86_64-unknown-linux-gnu. Please test it and report any issues to bugzilla. If all goes well I'd like to release 8.2 on Thursday, July 26th.
Re: Detecting superfluous "else"
> On Jul 19, 2018, at 4:49 AM, U.Mutlu wrote: > > Hi, > it makes me 'crazy' when I see such if-else constructs: > if (x) >return 7; > else >return 4; > > (Of course in this case one better would use the shorthand "return x ? 7 : > 4;", but that's not the issue here) > > The 'else' is obviously superfluous/redundant, ie. unneeded at all: > if (x) >return 7; > return 4; > > Is it possible to warn about such unneccessary occurances of "else"? > If not, then I suggest to add a new warning code -Wsuperfluous-else or > -Wredundant-else or so. I don't see any reason to warn about that code. It's perfectly valid, and in my view is clearer than the alternative. I've written both but I most often write the "else" variant for the reason that it expresses the semantics explicitly. Warnings are appropriate for code that is known to be a source of bugs, or where there is a reasonable chance that the intent of the programmer doesn't match what was actually written. That's not the case here. paul
Re: Detecting superfluous "else"
On Thu, 19 Jul 2018 at 14:01, Paul Koning wrote: > Warnings are appropriate for code that is known to be a source of bugs, or > where there is a reasonable chance that the intent of the programmer doesn't > match what was actually written. That's not the case here. Agreed. This seems to be a purely stylistic preference.
RE: [RFC] Adding Python as a possible language and it's usage
Boris Kolpackov wrote: > From: Paul Koning > > I wonder what will be the expected way to obtain a suitable version of > > Python if one is not available on the build machine? With awk I can > > build it from source pretty much anywhere. Is building newer versions > > of Python on older targets a similarly straightforward process > > (somehow I doubt it)? What about Windows? > > It's the same sort of thing: untar > the sources, configure, make, make install. The code is larger than awk but > the process is no more difficult. Python build chain on windows does not support building with gcc It was surprise for me to discover that, but this is how it is. Very inconvenient. > For Windows there are pre-built kits. Ditto > for a number of other popular operating systems. This suits for simple cases or for "popular" ones, but greatly complicate things if it isn't
Re: [RFC] Adding Python as a possible language and it's usage
On 07/18/2018 03:28 PM, Segher Boessenkool wrote: > On Wed, Jul 18, 2018 at 11:51:36AM +0200, Richard Biener wrote: >> We already conditionally require Perl for building for some targets so I >> wonder >> if using perl would be better ... > > At least perl is GPL (Python is not). > > > What would the advantage of using Python be? I haven't heard any yet. > Awk may be a bit clunky but at least it is easily readable for anyone. I've found python *far* easier to read than awk. And you can actually run a debugger on your python code to see what it's doing. Jeff
Re: Detecting superfluous "else"
On 7/19/18, U.Mutlu wrote: > Hi, > it makes me 'crazy' when I see such if-else constructs: >if (x) > return 7; >else > return 4; > > (Of course in this case one better would use the shorthand "return x ? 7 : > 4;", but that's not the issue here) > > The 'else' is obviously superfluous/redundant, ie. unneeded at all: >if (x) > return 7; >return 4; > > Is it possible to warn about such unneccessary occurances of "else"? > If not, then I suggest to add a new warning code -Wsuperfluous-else or > -Wredundant-else or so. > > Thx > Semi-related: bug 81851: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81851 (my disagreement with that request is similar to my disagreement with this request)
Re: [RFC] Adding Python as a possible language and it's usage
On 7/19/18, Jeff Law wrote: > On 07/18/2018 03:28 PM, Segher Boessenkool wrote: >> On Wed, Jul 18, 2018 at 11:51:36AM +0200, Richard Biener wrote: >>> We already conditionally require Perl for building for some targets so I >>> wonder >>> if using perl would be better ... >> >> At least perl is GPL (Python is not). >> >> >> What would the advantage of using Python be? I haven't heard any yet. >> Awk may be a bit clunky but at least it is easily readable for anyone. > I've found python *far* easier to read than awk. And you can actually > run a debugger on your python code to see what it's doing. > Jeff > gawk comes with a debugger, too: https://www.gnu.org/software/gawk/manual/html_node/Debugger.html
Re: [RFC] Adding Python as a possible language and it's usage
On 19/07/18 12:30, Florian Weimer wrote: > * Segher Boessenkool: > >> What would the advantage of using Python be? I haven't heard any yet. >> Awk may be a bit clunky but at least it is easily readable for anyone. > > I'm not an experienced awk programmer, but I don't think plain awk > supports arrays of arrays, so there's really no good way to emulate > user-defined data types and structure the code. > You can do multi-dimentional arrays in awk. They're flattened a bit like tcl ones are, but there are ways of iterating over a dimention. See, for example, config/arm/parsecpu.awk which gets up to tricks like that. R.
Re: Making GNU GCC choose_multiplier in expmed.c significantly faster
On 07/10/2018 05:09 AM, colinb2 . wrote: > Feel free to copy this email and attachment to anyone who might be interested. > I'm very happy to answer any questions anyone has. > The program can be compiled and run like this on Linux with GNU GCC: > gcc -O2 -o expmed2.exe expmed2.c > ./expmed2.exe > > This email deals with making part of the GNU GCC compiler - integer division > by a constant divisor - faster. (The calculation of the parameters for the > machine code will be faster; compiled programs won't run faster.) > Further down I mention inequality (1) which can be used to make the LLVM > compiler somewhat faster, because that currently uses code based on (2). > I don't know what - if anything - the Java JVM uses for this, or how other > compilers do this, but these ideas may be useful there. > > By significantly faster I mean I have benchmarked alternative versions of > choose_multiplier which on my low specification netbook can take maybe less > than > half the time the current version takes. Time saved in compilation is much > less > important than time saved in running compiled programs, but the code for the > faster versions is about the same length as the code for the current version, > and is only a bit more complicated, so is worth considering? Improvements to compile time behavior are always worth considering. > > Licencing: in Fractint people's words "Don't want money, want recognition!" > The version choose_multiplier_v2 is based - but improves - on what's in > the GCC choose_multiplier function in file expmed.c, so the GCC licence. > The version choose_multiplier_v4 is based - but improves - on magicu2 in > "Hacker's Delight", so the licence is you needn't acknowledge the source > but it would be nice to credit the code as from > magicu2 in "Hacker's Delight" by Henry S Warren http://hackersdelight.org > with improvements by Colin Bartlett . > This latter also applies to choose_multiplier_power2_divrem because that > is also an obvious (?) idea from magicu2 in "Hacker's Delight". */ So a key issue with GCC is that for nontrivial code to be included in GCC, the code's author must assign their copyright ownership to the FSF. > > The idea is using "wide int" seems slow compared to "unsigned HOST_WIDE_INT", > so it makes sense to avoid using "wide int" as much as possible. Sure, but the use of wide_int types has certain advantages and if possible we'd like that class to be just as efficient as a HOST_WIDE_INT for common operations on 32 and 64 bit types. In fact, for 32 and 64 bit types, wide_int is supposed to generate the same code as HOST_WIDE_INT. At least that was the state in 2013 when wide_int was introduced. So it may be worth spending some time figuring out why changing the types changes the performance. If you're going to argue to use HOST_WIDE_INT, then you'll have to think about how you're going to support 128bit or wider target data types which is the whole point behind the introduction of wide_int. Anyway, I think these higher level questions/concerns need to be addressed before we can reasonably discuss replacing wide_int with HOST_WIDE_INT. WRT algorithmic changes. ISTM it would be best to address those separately from the wide_int vs HOST_WIDE_INT discussion. An algorithmic change should have the same impact regardless of whether we're using wide_int or HOST_WIDE_INT. We can easily > rewrite choose_multiplier to only use "wide int" to calculate the initial > mlow; > this is choose_multiplier_v2. An alternative for choose_multiplier_v2 > completely > avoids using "wide int" by iterating upwards for the initial mlow, but if that > benchmarks as faster than using "wide int" even once (I suspect it might) then > just iterating upwards may even be a bit faster; this is choose_multiplier_v4. So the most obvious take-away from this is to answer the question of whether or not iterating upwards for the initial mlow is a win or not. If so, that might be able to go forward independent of any other changes. > > The attachment is self-contained, and I have checked that the values produced > agree with a "Hacker's Delight" table of M/2^s for small d and n=precision=32. Rather than attaching new implementations, the generally preferred packaging is diffs against the trunk. Jeff
gcc-gnat for Linux/MIPS-32bit-be, and HPPA2
hi is there any chance someone has a working gcc-ada compiler? for - Linux/MIPS (big endian, MIPS3, MIPS4 or MIPS32) - Linux/HPPA2 I have successfully compiled gcc-ada for SGI_IRIX (MIPS4/BE) but ... every attempt to create a cross-compiler(1) fails on HPPA I have never seen an Ada compiler I can use gnat on Irix to crosscompile a gcc-ada for Linux, but I need instructions since I have never done anything similar. For HPPA I am lost (1) host = Irix-MIPS4/BE target = Linux/MIPS32/BE
Re: [RFC] Adding Python as a possible language and it's usage
David Malcolm wrote: >On Tue, 2018-07-17 at 14:49 +0200, Martin Liška wrote: >> I've recently touched AWK option generate machinery and it's >> quite unpleasant to make any adjustments. My question is >> simple: can we starting using a scripting language like Python >> and replace usage of the AWK scripts? It's probably question >> for Steering committee, but I would like to see feedback from >> community. > >As you know, I'm a fan of Python. As I noted elsewhere in this >thread, one issue is Python 2 vs Python 3 (and minimum >versions). Within Python 2.*, Python 2.6 onwards is broadly >compatible with Python 3.*, and there's a well-known common >subset that works in both languages. > >To what extent would this complicate bootstrap? (I don't think >so, in that it would appear to be just an external build-time >dependency on the build machine). > >Would this make it harder for people to build GCC? It's one >more dependency, but CPython is widely available and relatively >easy to build. (I don't have experience of doing bring-up of a >new architecture, though). Hello, I have recently been working on bringing up a new Debian port for the riscv64 architecture from scratch, so I would like to add some of my personal experiences here. Adding a dependency on python for building gcc would make life for distribution porters quite a bit harder. There are a bunch of packages that are more or less essential for a modern Linux distribution but at the same time extremely difficult to properly cross-build. For a distribution porter trying to bootstrap a new architecture, this means that one has to resort to native building sooner or later, i.e. one has to build native toolchain packages and then work forward from there. During the bootstrap process it is often necessary to break dependency cycles and natively rebuild toolchain packages with different build-profiles enabled, or to build newer versions of the same toolchain packages with bugfixes for the new architecture. A dependency on python would mean that to be able to do a native rebuild of the toolchain one would need a native python. The problem here is that python has an enormous number of transitive build-dependencies and not all of them are easily cross-buildable, i.e. one needs a native compiler to build some of them in a bootstrap scenario. This can lead to a catch-22-style situation where one would need a native python package and its dependencies for natively building the gcc package and a native gcc package for building (some of) the dependencies of the python package. With awk we don't have this problem as in contrast to python awk doesn't pull in any dependencies that aren't required by gcc anyway. From a distro porter's point of view I would therefore appreciate very much if it would be possible to avoid adding a python dependency to the gcc build process. Regards, Karsten P.S.: I am not subscribed to the list, so it would be nice if you could CC me on replies. -- Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt- oder Meinungsforschung.
Re: gcc-gnat for Linux/MIPS-32bit-be, and HPPA2
On 07/19/2018 02:19 PM, Carlo Pisani wrote: > hi > is there any chance someone has a working gcc-ada compiler? for > - Linux/MIPS (big endian, MIPS3, MIPS4 or MIPS32) > - Linux/HPPA2 > > I have successfully compiled gcc-ada for SGI_IRIX (MIPS4/BE) > but ... every attempt to create a cross-compiler(1) fails > > on HPPA I have never seen an Ada compiler We certainly had it on PA HPUX. Of course that platform is long dead. It looks like Debian's PA port has had an Ada compiler in the past. I'd be surprised if they still don't -- once you've built it once it's fairly easy to carry forward. jeff
Re: Making GNU GCC choose_multiplier in expmed.c significantly faster
On 7/19/18, Jeff Law wrote: > On 07/10/2018 05:09 AM, colinb2 . wrote: > Improvements to compile time behavior are always worth considering. The points you make below about wide_int might address this, albeit in a somewhat different way from the way I am proposing. > So a key issue with GCC is that for nontrivial code to be included in > GCC, the code's author must assign their copyright ownership to the FSF. That's OK for choose_multiplier_v2 which is what I'm suggesting as a replacement for choose_multiplier. >> The idea is using "wide int" seems slow compared to "unsigned HOST_WIDE_INT", >> so it makes sense to avoid using "wide int" as much as possible. > Sure, but the use of wide_int types has certain advantages and if > possible we'd like that class to be just as efficient as a HOST_WIDE_INT > for common operations on 32 and 64 bit types. That makes sense, and *if* you can do it has some advantages over what I was proposing. Reviewing my code I realised that I needed to split off two special cases (i) d=1 and (ii) PRECISIONhttps://github.com/colinb2r/expmed2 > In fact, for 32 and 64 bit types, wide_int is supposed to generate the > same code as HOST_WIDE_INT. At least that was the state in 2013 when > wide_int was introduced. So it may be worth spending some time figuring > out why changing the types changes the performance. I was assuming that it was something intrinsic to the way wide_int had to be implemented that made it substantially slower than fixed width like HOST_WIDE_INT, and I was also assuming that earlier versions of choose_multiplier which didn't use wide_int, but used an equivalent extended precision would have a similar lack of speed? I did look at earlier versions of choose_multiplier, and I have a vague recollection that one of the earlier implementations basically used HOST_WIDE_INT throughout, using auxiliary variables to indicate that mlow and mhigh need an extra bit. Looked at like that it becomes sort of obvious why an extended precision integer is likely to be slower than a fixed width HOST_WIDE_INT: if nothing else, there is more "housekeeping" involved? > If you're going to argue to use HOST_WIDE_INT, then you'll have to think > about how you're going to support 128bit or wider target data types > which is the whole point behind the introduction of wide_int. > > Anyway, I think these higher level questions/concerns need to be > addressed before we can reasonably discuss replacing wide_int with > HOST_WIDE_INT. In principle I agree with both these paragraphs. But that said the current choose_multiplier happily (?) switches between using wide_int and HOST_WIDE_INT, and at its end the multiplier is of type unsigned HOST_WIDE_INT, so if we're focussing on choose_multiplier (rather than the broader issue of making wide_int faster in general) I don't think these valid points actually apply to choose_multiplier? If what you were saying was strictly true for choose_multiplier, then it could use wide_int throughout, only switching to HOST_WIDE_INT at the end? But that's not how it's written. > WRT algorithmic changes. ISTM it would be best to address those > separately from the wide_int vs HOST_WIDE_INT discussion. An > algorithmic change should have the same impact regardless of whether > we're using wide_int or HOST_WIDE_INT. Yes. Or to be precise, wide_int ought to be able to replace HOST_WIDE_INT, but the reverse might not be true? Taking choose_multiplier as an example, we must be rather more careful going from wide_int to HOST_WIDE_INT than going from HOST_WIDE_INT to wide_int? > Rather than attaching new implementations, the generally preferred > packaging is diffs against the trunk. That makes sense. Unfortunately I don't feel I have the competence to do that, but that's a bridge that can if necessary be crossed in an appropriate way when the time comes? > Jeff Thanks for your pertinent comments. I must confess I had rather assumed that after over a week without any "bites" that my post wasn't going to attract any comments, so finding your response just now was a welcome surprise.
gcc-7-20180719 is now available
Snapshot gcc-7-20180719 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/7-20180719/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-7-branch revision 262892 You'll find: gcc-7-20180719.tar.xzComplete GCC SHA256=7e06ff699355dca7d90a54400995447f29a78a9ccdc39d9b7d56109993dc25a0 SHA1=ad34b842e44c07b41fe36173ede253e86d6a0e3e Diffs from 7-20180712 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-7 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] Adding Python as a possible language and it's usage
On 20/07/2018, at 4:12 AM, Richard Earnshaw (lists) mailto:richard.earns...@arm.com>> wrote: > On 19/07/18 12:30, Florian Weimer wrote: >> * Segher Boessenkool: >> >>> What would the advantage of using Python be? I haven't heard any yet. >>> Awk may be a bit clunky but at least it is easily readable for anyone. >> >> I'm not an experienced awk programmer, but I don't think plain awk >> supports arrays of arrays, so there's really no good way to emulate >> user-defined data types and structure the code. >> > > You can do multi-dimentional arrays in awk. They're flattened a bit > like tcl ones are, but there are ways of iterating over a dimention. > See, for example, config/arm/parsecpu.awk which gets up to tricks like that. Has it occurred to anyone to write a lean and fast tool in the host C++ subset that is allowable for use in the host tools. I guess this is currently C++98/GNU++98. This adds no additional dependencies. Sure it is a slight level of effort higher than writing an awk script, but with a modern C++ this is less of a case as it has ever been in the past. I personally use C++11/14 as a substitute for python type programs that would normally be considered script language material, mostly due to fluency and the fact that modern C++ has grown more tractable as a replacement for “fast to code in” languages given it is much faster to code in than C. LLVM discussed changing the host compiler language feature dependencies to C++11/C++14. There are obvious but not insurmountable bootstrap requirements. i.e. for very old systems it will require an intermediate C++11/C++14 compiler to bootstrap LLVM 6.0. Here is LLVM's new compiler baseline and it seems to require CentOS 7. - Clang 3.1 - GCC 4.8 - Visual Studio 2015 (Update 3) [1] https://llvm.org/docs/GettingStarted.html#getting-a-modern-host-c-toolchain I find I can be very productive and nearly as concise in C++11 as I can in many script languages due to modern versions of , , , , , , auto, lambdas, etc. It’s relatively easy to write memory clean code from the get go using std::unique_ptr<> and sparing amounts of std::shared_ptr<>) and the new C++11 for comprehensions, initializer lists and various other enhancements can make coding in “modern C++” relatively friendly and productive. In the words of Bjarne Stroustrup: It feels like a new language. I can point to examples of small text processing utilities that i’ve written that could be written in python with a relatively similar amount of effort. Fluency with STL and the use of lean idioms. STL and structs (data hiding is only a header tweak away from being broken in a language like C++, and the use of struct and is similar to language like python which resorts to using underscores or “idiomatic enforcement”). i.e. there are lightweight, fast and productive modern C++ idioms that work well with vectors, sets, maps and unique_ptr or shared_ptr automatic memory management. I find with modern idioms these programs valgrind clean almost always. Would modern-C++ (for generated files) be considered for GCC 9? The new idioms may make parts of the code considerable more concise and could allow use of some of the new automatic memory management features. The reason I’m suggesting this, is that for anything other than a trivial command line invocation of sed or awk, I would tend to write a modern C++ program to do text processing versus a script langauge like python. Firstly it is faster, Secondly I am proficient enough and the set and map functionality combined with the new automatic memory management is sufficient enough that complex nested data structures and text processing can handled with relative ease. Note: I do tend to avoid iostream and instead use stdc FILE * and fopen/fread/frwite/fclose or POSIX open/read/write/close if I want to avoid buffering. I find iostream performance is not that great. How conservative are we? Is C++11 going go be available for use in GCC before C++2x in 202x. Indeed would improve some of the Windows/UNIX interoperability. I’ve found that writing C++11/14 allows me to write in an idiomatic C/C++ subset that is quite stable across platforms. We now even have on Windows. There has been quite a bit of convergence. Having the constraint that modern C++11/14 can only be used for generated files lessens the burden as the distribution build can maintain the same base compiler dependencies. Michael.
