Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implicit fallthrough warning on GCC 7.x #1581

Closed
russel opened this issue Feb 14, 2017 · 11 comments
Closed

Implicit fallthrough warning on GCC 7.x #1581

russel opened this issue Feb 14, 2017 · 11 comments

Comments

@russel
Copy link
Contributor

russel commented Feb 14, 2017

I have git master up-to-date as at 2017-02-14T08:13+00:00, with Fedora Rawhide fully up to date, and attempt to build Pony results in:

|> make
Makefile:224: WARNING: Unsupported LLVM version: 3.9.0
Makefile:225: Please use LLVM 3.7.1, 3.8.1, or 3.9.1
actor.c
messageq.c
fun.c
src/libponyrt/ds/fun.c: In function ‘siphash24’:
src/libponyrt/ds/fun.c:46:15: error: this statement may fall through [-Werror=implicit-fallthrough=]
     case 7: b |= ((uint64_t)in[6]) << 48;
             ~~^~~~~~~~~~~~~~~~~~~~~~~~~~
src/libponyrt/ds/fun.c:47:5: note: here
     case 6: b |= ((uint64_t)in[5]) << 40;
     ^~~~
src/libponyrt/ds/fun.c:47:15: error: this statement may fall through [-Werror=implicit-fallthrough=]
     case 6: b |= ((uint64_t)in[5]) << 40;
             ~~^~~~~~~~~~~~~~~~~~~~~~~~~~
src/libponyrt/ds/fun.c:48:5: note: here
     case 5: b |= ((uint64_t)in[4]) << 32;
     ^~~~
src/libponyrt/ds/fun.c:48:15: error: this statement may fall through [-Werror=implicit-fallthrough=]
     case 5: b |= ((uint64_t)in[4]) << 32;
             ~~^~~~~~~~~~~~~~~~~~~~~~~~~~
src/libponyrt/ds/fun.c:49:5: note: here
     case 4: b |= ((uint64_t)in[3]) << 24;
     ^~~~
src/libponyrt/ds/fun.c:49:15: error: this statement may fall through [-Werror=implicit-fallthrough=]
     case 4: b |= ((uint64_t)in[3]) << 24;
             ~~^~~~~~~~~~~~~~~~~~~~~~~~~~
src/libponyrt/ds/fun.c:50:5: note: here
     case 3: b |= ((uint64_t)in[2]) << 16;
     ^~~~
src/libponyrt/ds/fun.c:50:15: error: this statement may fall through [-Werror=implicit-fallthrough=]
     case 3: b |= ((uint64_t)in[2]) << 16;
             ~~^~~~~~~~~~~~~~~~~~~~~~~~~~
src/libponyrt/ds/fun.c:51:5: note: here
     case 2: b |= ((uint64_t)in[1]) << 8;
     ^~~~
src/libponyrt/ds/fun.c:51:15: error: this statement may fall through [-Werror=implicit-fallthrough=]
     case 2: b |= ((uint64_t)in[1]) << 8;
             ~~^~~~~~~~~~~~~~~~~~~~~~~~~
src/libponyrt/ds/fun.c:52:5: note: here
     case 1: b |= ((uint64_t)in[0]);
     ^~~~
cc1: all warnings being treated as errors
@jemc
Copy link
Member

jemc commented Feb 14, 2017

@russel - Can you please let us know which gcc or clang version you are using to compile Pony?

@russel
Copy link
Contributor Author

russel commented Feb 14, 2017

Apologies, I should have been explicit. I am using Fedora Rawhide GCC which is now 7.0.1.

@sylvanc
Copy link
Contributor

sylvanc commented Feb 14, 2017

https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html

It looks like gcc 7 has added a default fallthrough warning behaviour. Note that it isn't present in gcc 6:

https://gcc.gnu.org/onlinedocs/gcc-6.3.0/gcc/Warning-Options.html

The default level (3) accepts various regular expressions as "fallthrough indicators", along with a gcc specific attribute. I suggest we pick one that level 4 also recognises, and add it in fun.c (which appears to be the only place we use fallthrough). For example:

// -fallthrough

@jemc jemc changed the title Pony will not build on Rawhide Implicit fallthrough warning on GCC 7.x Feb 14, 2017
@russel
Copy link
Contributor Author

russel commented Feb 14, 2017

@sylvanc @jemc Closing this was premature, I'm afraid. I pulled to bfb4b94 and then:

|> make
Makefile:224: WARNING: Unsupported LLVM version: 3.9.0
Makefile:225: Please use LLVM 3.7.1, 3.8.1, or 3.9.1
actor.c
messageq.c
fun.c
src/libponyrt/ds/fun.c: In function ‘siphash24’:
src/libponyrt/ds/fun.c:46:15: error: this statement may fall through [-Werror=implicit-fallthrough=]
     case 7: b |= ((uint64_t)in[6]) << 48; // -fallthrough
             ~~^~~~~~~~~~~~~~~~~~~~~~~~~~
src/libponyrt/ds/fun.c:47:5: note: here
     case 6: b |= ((uint64_t)in[5]) << 40; // -fallthrough
     ^~~~
src/libponyrt/ds/fun.c:47:15: error: this statement may fall through [-Werror=implicit-fallthrough=]
     case 6: b |= ((uint64_t)in[5]) << 40; // -fallthrough
             ~~^~~~~~~~~~~~~~~~~~~~~~~~~~
src/libponyrt/ds/fun.c:48:5: note: here
     case 5: b |= ((uint64_t)in[4]) << 32; // -fallthrough
     ^~~~
src/libponyrt/ds/fun.c:48:15: error: this statement may fall through [-Werror=implicit-fallthrough=]
     case 5: b |= ((uint64_t)in[4]) << 32; // -fallthrough
             ~~^~~~~~~~~~~~~~~~~~~~~~~~~~
src/libponyrt/ds/fun.c:49:5: note: here
     case 4: b |= ((uint64_t)in[3]) << 24; // -fallthrough
     ^~~~
src/libponyrt/ds/fun.c:49:15: error: this statement may fall through [-Werror=implicit-fallthrough=]
     case 4: b |= ((uint64_t)in[3]) << 24; // -fallthrough
             ~~^~~~~~~~~~~~~~~~~~~~~~~~~~
src/libponyrt/ds/fun.c:50:5: note: here
     case 3: b |= ((uint64_t)in[2]) << 16; // -fallthrough
     ^~~~
src/libponyrt/ds/fun.c:50:15: error: this statement may fall through [-Werror=implicit-fallthrough=]
     case 3: b |= ((uint64_t)in[2]) << 16; // -fallthrough
             ~~^~~~~~~~~~~~~~~~~~~~~~~~~~
src/libponyrt/ds/fun.c:51:5: note: here
     case 2: b |= ((uint64_t)in[1]) << 8;  // -fallthrough
     ^~~~
src/libponyrt/ds/fun.c:51:15: error: this statement may fall through [-Werror=implicit-fallthrough=]
     case 2: b |= ((uint64_t)in[1]) << 8;  // -fallthrough
             ~~^~~~~~~~~~~~~~~~~~~~~~~~~
src/libponyrt/ds/fun.c:52:5: note: here
     case 1: b |= ((uint64_t)in[0]);
     ^~~~
cc1: all warnings being treated as errors
|> gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl --enable-libmpx --enable-offload-targets=nvptx-none --without-cuda-driver --enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 7.0.1 20170204 (Red Hat 7.0.1-0.6) (GCC) 

@jemc jemc reopened this Feb 14, 2017
@jemc
Copy link
Member

jemc commented Feb 14, 2017

@russel if you could experiment with variations on the fallthrough comment, and with varying levels for this warning from -Wimplicit-fallthrough=4 to -Wimplicit-fallthrough=0, it would speed up the troubleshooting process a lot, as I don't currently have access to GCC 7.

You can change the compiler build flags in the Makefile here.

@russel
Copy link
Contributor Author

russel commented Feb 14, 2017

@jemc Rather than just play, I will get advice from a person/people who will know the answer off the top of their head(s).

@jwakely
Copy link

jwakely commented Feb 14, 2017

Try removing the hyphen, or removing the space i.e. // fallthrough or //-fallthrough, but not // -fallthrough

// fallthrough matches the regex [ \t.!]*([Ee]lse,? |[Ii]ntentional(ly)? )? fall(s | |-)?thr(ough|u)[ \t.!]*(-[^\n\r]*)?

//-fallthrough matches the regex -fallthrough (which is one of the standard Lint comments, which GCC recognises for compatibility with code that is already commented for Lint checking).

@russel
Copy link
Contributor Author

russel commented Feb 14, 2017

@jemc I took the - out, and everything compiles. I'll proffer a pull request.

@russel
Copy link
Contributor Author

russel commented Feb 14, 2017

@jwakely Thanks for the data, much appreciated.

@jemc
Copy link
Member

jemc commented Feb 14, 2017

Ah, I didn't realize that leading whitespace counted as part of the matching regular expression for -fallthrough. Just leaving out the - as you suggest seems like the best option.

@jwakely Thanks for the help, we appreciate it!

@russel Thanks, I'll look forward to the pull request.

@russel
Copy link
Contributor Author

russel commented Feb 14, 2017

Pull request #1585 is currently running the tests.

@jemc jemc closed this as completed Feb 14, 2017
omac777 referenced this issue in QubesOS/qubes-builder Jul 20, 2017
Until this document is updated if will be helpful if it points to the IMO excellent Archlinux template building instructions.
perlun added a commit to chaos4ever/chaos that referenced this issue Sep 27, 2017
perlun added a commit to chaos4ever/chaos that referenced this issue Sep 27, 2017
* Travis: Support newer gcc versions

In fact, run on both gcc 4.9, 5, 6 and 7. This is probably overkill in the long run. If it turns out to be a maintenance nightmare, we can drop one or more of these easily.

* Attempt to fix warning w/ gcc 6 and 7.

* Attempt to fix gcc-7 compile error

Inspired by this: https://stackoverflow.com/questions/47981/how-do-you-set-clear-and-toggle-a-single-bit

* TIL: Explicit case fallthrough

More details: https://developers.redhat.com/blog/2017/03/10/wimplicit-fallthrough-in-gcc-7/

* Attempted workaround for -Wimplicit-fallthrough

The comment approach did not work for me; the warning level seemed not to be 3 as it ought to be. Maybe if we explicitly set it to 4, things will work.

* ARCH_CFLAGS was only being used when compiling chaos.

Should be used when compiling the libraries and servers also.

* Try level 3 instead.

* One more try to get it working.

* Googled for -Wimplicit-fallthrough

This should work. The commment must be outside of the block, if it exists...

* One more futile attempt to get it working w/ gcc-7

* One more try

Inspired by ponylang/ponyc#1581
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants