Re: Warning annoyances in list_read.c
On 2017.03.26 at 19:30 -0700, Steve Kargl wrote: > On Sun, Mar 26, 2017 at 06:45:07PM -0700, Jerry DeLisle wrote: > > On 03/26/2017 11:45 AM, Steve Kargl wrote: > > > On Sun, Mar 26, 2017 at 11:27:59AM -0700, Jerry DeLisle wrote: > > >> > > >> +#pragma GCC diagnostic push > > >> +#pragma GCC diagnostic ignored "-Wimplicit-fallthrough" > > > > > > IMNSHO, the correct fix is to complain loudly to whomever > > > added -Wimplicit-fallthrough to compiler options. It should > > > be removed (especially if is has been added to -Wall). > > > > > > You can also probably add -Wno-implicit-fallthrough to > > > libgfortran/configure.ac at > > > > > > # Add -Wall -fno-repack-arrays -fno-underscoring if we are using GCC. > > > if test "x$GCC" = "xyes"; then > > > AM_FCFLAGS="-I . -Wall -Werror -fimplicit-none -fno-repack-arrays > > > -fno-underscoring" > > > > > > > Problem I have is I don't know who to complain to. I think there is a bit > > of a > > glass wall going on here anyway, so what would be the point of complaining > > if > > the retrievers of the message all have the ON-OFF switch in the OFF > > position. > > (After all, I do not have a PHD, I am not a computer science graduate, why > > bother looking down ones nose at a low life such as myself, OMG its an > > engineer, > > what the hell does he know.) > > > > Maybe these warnings are being turned on as a matter of policy, but truth > > is, > > when I build 50 times a day, the warnings flying by are masking the errors > > or > > other warnings that may be important. For example, I inadvertently passed a > > ptr > > to a function rather than the *ptr. > > > > The warning that ensued flew by mixed in with all the other crap warnings > > and I > > did not see it. That cost me wasted cycle time (remember, I am not an > > expert and > > should not be expected to see such things. Hell, for that matter I should > > not > > even be doing any of this work. :) > > > > This option is clearly enforceing someone's preferred markup of > adding a comment to explicitly note a fall through. Candidate > individual to complain to > > If he added a new option affecting libgfortran, then he should > fix up libgfortran. He didn't add the warning to specifically annoy fortran developers. It is trivial to add seven gcc_fallthrough() or breaks for someone who knows the code and the person who added the warning obviously doesn't. -- Markus
Re: Warning annoyances in list_read.c
On Sun, Mar 26, 2017 at 06:45:07PM -0700, Jerry DeLisle wrote: > On 03/26/2017 11:45 AM, Steve Kargl wrote: > > On Sun, Mar 26, 2017 at 11:27:59AM -0700, Jerry DeLisle wrote: > >> > >> +#pragma GCC diagnostic push > >> +#pragma GCC diagnostic ignored "-Wimplicit-fallthrough" > > > > IMNSHO, the correct fix is to complain loudly to whomever > > added -Wimplicit-fallthrough to compiler options. It should > > be removed (especially if is has been added to -Wall). > > > > You can also probably add -Wno-implicit-fallthrough to > > libgfortran/configure.ac at > > > > # Add -Wall -fno-repack-arrays -fno-underscoring if we are using GCC. > > if test "x$GCC" = "xyes"; then > > AM_FCFLAGS="-I . -Wall -Werror -fimplicit-none -fno-repack-arrays > > -fno-underscoring" > > > > Problem I have is I don't know who to complain to. I think there is a bit of a > glass wall going on here anyway, so what would be the point of complaining if > the retrievers of the message all have the ON-OFF switch in the OFF position. > (After all, I do not have a PHD, I am not a computer science graduate, why > bother looking down ones nose at a low life such as myself, OMG its an > engineer, > what the hell does he know.) > > Maybe these warnings are being turned on as a matter of policy, but truth is, > when I build 50 times a day, the warnings flying by are masking the errors or > other warnings that may be important. For example, I inadvertently passed a > ptr > to a function rather than the *ptr. > > The warning that ensued flew by mixed in with all the other crap warnings and > I > did not see it. That cost me wasted cycle time (remember, I am not an expert > and > should not be expected to see such things. Hell, for that matter I should not > even be doing any of this work. :) > This option is clearly enforceing someone's preferred markup of adding a comment to explicitly note a fall through. Candidate individual to complain to 2016-09-26 Marek Polacek PR c/7652 * common.opt (Wimplicit-fallthrough): New option. * doc/extend.texi: Document statement attributes and the fallthrough attribute. * doc/invoke.texi: Document -Wimplicit-fallthrough. * gimple.h (gimple_call_internal_p): New function. * gimplify.c (struct gimplify_ctx): Add in_switch_expr. (struct label_entry): New struct. (find_label_entry): New function. (case_label_p): New function. (collect_fallthrough_labels): New function. (last_stmt_in_scope): New function. (should_warn_for_implicit_fallthrough): New function. (warn_implicit_fallthrough_r): New function. (maybe_warn_implicit_fallthrough): New function. (expand_FALLTHROUGH_r): New function. (expand_FALLTHROUGH): New function. (gimplify_switch_expr): Call maybe_warn_implicit_fallthrough and expand_FALLTHROUGH for the innermost GIMPLE_SWITCH. (gimplify_label_expr): New function. (gimplify_case_label_expr): Set location. (gimplify_expr): Call gimplify_label_expr. * internal-fn.c (expand_FALLTHROUGH): New function. * internal-fn.def (FALLTHROUGH): New internal function. * langhooks.c (lang_GNU_OBJC): New function. * langhooks.h (lang_GNU_OBJC): Declare. * system.h (gcc_fallthrough): Define. * tree-core.h: Add FALLTHROUGH_LABEL_P comment. * tree.h (FALLTHROUGH_LABEL_P): Define. If he added a new option affecting libgfortran, then he should fix up libgfortran. -- Steve 20161221 https://www.youtube.com/watch?v=IbCHE-hONow
Re: Warning annoyances in list_read.c
On 03/26/2017 11:45 AM, Steve Kargl wrote: > On Sun, Mar 26, 2017 at 11:27:59AM -0700, Jerry DeLisle wrote: >> >> +#pragma GCC diagnostic push >> +#pragma GCC diagnostic ignored "-Wimplicit-fallthrough" > > IMNSHO, the correct fix is to complain loudly to whomever > added -Wimplicit-fallthrough to compiler options. It should > be removed (especially if is has been added to -Wall). > > You can also probably add -Wno-implicit-fallthrough to > libgfortran/configure.ac at > > # Add -Wall -fno-repack-arrays -fno-underscoring if we are using GCC. > if test "x$GCC" = "xyes"; then > AM_FCFLAGS="-I . -Wall -Werror -fimplicit-none -fno-repack-arrays > -fno-underscoring" > Problem I have is I don't know who to complain to. I think there is a bit of a glass wall going on here anyway, so what would be the point of complaining if the retrievers of the message all have the ON-OFF switch in the OFF position. (After all, I do not have a PHD, I am not a computer science graduate, why bother looking down ones nose at a low life such as myself, OMG its an engineer, what the hell does he know.) Maybe these warnings are being turned on as a matter of policy, but truth is, when I build 50 times a day, the warnings flying by are masking the errors or other warnings that may be important. For example, I inadvertently passed a ptr to a function rather than the *ptr. The warning that ensued flew by mixed in with all the other crap warnings and I did not see it. That cost me wasted cycle time (remember, I am not an expert and should not be expected to see such things. Hell, for that matter I should not even be doing any of this work. :) Cheers everybody, its been dark and gray all day. Jerry
Re: Historic gcc 0.9 tapes
On 03/25/2017 12:26 AM, Marshall Lee Whittaker wrote: Hi, I was looking through the historic archives of gcc at ftp.vim.org and found a very old version of gcc dating back to 1987. I was wondering if the below thread still applies? As in, does anybody happen to have any very old original tapes containing gcc 0.9 beta? I would really love to find one if so. Maybe stuffed off in a broom closet somewhere? I know it's not terribly useful these days... but I find vintage computer stuff fascinating. ftp://gcc.gnu.org/pub/gcc/old-releases/gcc-1/ Has a gcc-0.9 release in it. jeff
gcc-7-20170326 is now available
Snapshot gcc-7-20170326 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/7-20170326/ 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/trunk revision 246486 You'll find: gcc-7-20170326.tar.bz2 Complete GCC SHA256=8114651a53314ed5277d6a1b2993c9fa49530dd37bcebd29db6a6d2c6472f376 SHA1=208613551890b5ec98a868d2afe9a465b9c52723 Diffs from 7-20170319 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: C++17 by default in gcc-8
On Sunday 26 March 2017, Egor Pugin wrote: > Hi, > > It's a bit early question, but still. > C++ releases became more predictive and regular. > What do you think about settings -std=c++17 (or gnu++17) for gcc-8 as > default c++ mode? > What is your policy regarding default c++ standards in gcc? It would make sense in it being the second release with full c++17 support, so we could expect the support to be mature in gcc 8. I am a little sceptical personally though, because I just recently got burned by a C++17 change, where a number of uses of functor classes broke because pointers to functions with noexcept is now a separate type. So code that worked with C++14 is now illegal in C++17 and requires doubling the number of specialized functor templates, and still isn't fully source compatible with C++14 (though all nice clean code will be compatible) Best regards `Allan
C++17 by default in gcc-8
Hi, It's a bit early question, but still. C++ releases became more predictive and regular. What do you think about settings -std=c++17 (or gnu++17) for gcc-8 as default c++ mode? What is your policy regarding default c++ standards in gcc? -- Egor Pugin
