Bug 85425 - gcc 6.2.1 fails to catch error in function calling arguments
Summary: gcc 6.2.1 fails to catch error in function calling arguments
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: c (show other bugs)
Version: 6.2.1
: P3 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: diagnostic
Depends on:
Blocks:
 
Reported: 2018-04-16 19:05 UTC by Gerhard Heinzel
Modified: 2021-10-09 17:19 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2018-04-16 00:00:00


Attachments
preprocessed single C input file (20.92 KB, text/plain)
2018-04-16 19:05 UTC, Gerhard Heinzel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Gerhard Heinzel 2018-04-16 19:05:31 UTC
Created attachment 43953 [details]
preprocessed single C input file

Dear gcc maintainers,

First let me say that I am a very happy and grateful user of gcc since about 25 years.
I program in C under Linux and try to encourage my students to do the same.
Such C programs are the workhorse of my physics research group, although I have
to admit that the younger students now prefer C++ which I never really got used to.

Anyway, here is the bug:

The attached program, which is already reduced to a single file that
contains about 5% of the code of the full thing, 
does _NOT_ trigger an error although in my opinion it should,
when compiled with

gcc-6 -Wall -Wextra -c fail_contour.i

A function is called with messed up order of parameters,
mixing int with double.

The function is declared and defined as

contour_point_t ghhrobust_search 
(contour_point_t * p, contour_point_t plast, double ax, double ay, int type)

but called as

p = ghhrobust_search (ptrials, plast, type, ax, ay);

where the integer variable "type" is at position 3 instead of at the end.

gcc (version info below) does not catch this error, which
I consider a bug.

Possibly I made a stupid mistake, in which case I'd be
grateful for a short notice.
I have tried to follow the bug reporting instructions.
If this is a real problem, I'd of course be willing to
submit more information or try to reduce the problem further
to a minimal case, although I suspect that you are much better
at that than I am.

With best greetings and thanks for your support,

Gerhard Heinzel.

-----


Using built-in specs.
COLLECT_GCC=gcc-6
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,fortran,ada,go --enable-offload-targets=hsa --enable-checking=release --with-gxx-include-dir=/usr/include/c++/6 --enable-ssp --disable-libssp --disable-libvtv --disable-libcc1 --disable-plugin --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --with-default-libstdcxx-abi=gcc4-compatible --enable-version-specific-runtime-libs --enable-linker-build-id --enable-linux-futex --enable-gnu-indirect-function --program-suffix=-6 --without-system-libunwind --enable-multilib --with-arch-32=x86-64 --with-tune=generic --build=x86_64-suse-linux --host=x86_64-suse-linux
Thread model: posix
gcc version 6.2.1 20160826 [gcc-6-branch revision 239773] (SUSE Linux) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-c' '-mtune=generic' '-march=x86-64'
 /usr/lib64/gcc/x86_64-suse-linux/6/cc1 -E -quiet -v fail_contour.c -mtune=generic -march=x86-64 -Wall -Wextra -fpch-preprocess -o fail_contour.i
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib64/gcc/x86_64-suse-linux/6/include
 /usr/local/include
 /usr/lib64/gcc/x86_64-suse-linux/6/include-fixed
 /usr/lib64/gcc/x86_64-suse-linux/6/../../../../x86_64-suse-linux/include
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-c' '-mtune=generic' '-march=x86-64'
 /usr/lib64/gcc/x86_64-suse-linux/6/cc1 -fpreprocessed fail_contour.i -quiet -dumpbase fail_contour.c -mtune=generic -march=x86-64 -auxbase fail_contour -Wall -Wextra -version -o fail_contour.s
GNU C11 (SUSE Linux) version 6.2.1 20160826 [gcc-6-branch revision 239773] (x86_64-suse-linux)
        compiled by GNU C version 6.2.1 20160826 [gcc-6-branch revision 239773], GMP version 5.1.3, MPFR version 3.1.2, MPC version 1.0.2, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C11 (SUSE Linux) version 6.2.1 20160826 [gcc-6-branch revision 239773] (x86_64-suse-linux)
        compiled by GNU C version 6.2.1 20160826 [gcc-6-branch revision 239773], GMP version 5.1.3, MPFR version 3.1.2, MPC version 1.0.2, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 9c15a1c4f36e0692cc50ecfa3c25d889
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-c' '-mtune=generic' '-march=x86-64'
 /usr/lib64/gcc/x86_64-suse-linux/6/../../../../x86_64-suse-linux/bin/as -v --64 -o fail_contour.o fail_contour.s
GNU assembler version 2.29.1 (x86_64-suse-linux) using BFD version (GNU Binutils; openSUSE Leap 42.3) 2.29.1
COMPILER_PATH=/usr/lib64/gcc/x86_64-suse-linux/6/:/usr/lib64/gcc/x86_64-suse-linux/6/:/usr/lib64/gcc/x86_64-suse-linux/:/usr/lib64/gcc/x86_64-suse-linux/6/:/usr/lib64/gcc/x86_64-suse-linux/:/usr/lib64/gcc/x86_64-suse-linux/6/../../../../x86_64-suse-linux/bin/
LIBRARY_PATH=/usr/lib64/gcc/x86_64-suse-linux/6/:/usr/lib64/gcc/x86_64-suse-linux/6/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/lib64/gcc/x86_64-suse-linux/6/../../../../x86_64-suse-linux/lib/:/usr/lib64/gcc/x86_64-suse-linux/6/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-c' '-mtune=generic' '-march=x86-64'
Comment 1 Jonathan Wakely 2018-04-16 19:48:23 UTC
The example can be reduced to:

void ghhrobust_search (double ay, int type) { }

void f(int i, double d) { ghhrobust_search(i, d); }

This must not produce an error, because it is 100% valid according to the C standard. An int can be converted to a double and a double can be converted to an int, so the code is valid.

If you use -Wconversion you get a warning:


a.c: In function ‘void f(int, double)’:
a.c:3:48: warning: conversion to ‘int’ from ‘double’ may alter its value [-Wfloat-conversion]
 void f(int i, double d) { ghhrobust_search(i, d); }
                                                ^

This seems to be what you're looking for. Indeed, compiling your attached code with -Wconversion gives a warning on the relevant line:

fail_contour.c: In function ‘contour_trace’:
fail_contour.c:203:56: warning: conversion to ‘int’ from ‘double’ may alter its value [-Wfloat-conversion]
Comment 2 Gerhard Heinzel 2018-04-16 20:05:44 UTC
(In reply to Jonathan Wakely from comment #1)

Many thanks for your quick response. 
I normally don't use -Wconversion because it floods me with
uninteresting errors about size_t, floor(), and code from bison/flex etc. 
But I'll try to use it more now.

Cheers,

Gerhard


> The example can be reduced to:
> 
> void ghhrobust_search (double ay, int type) { }
> 
> void f(int i, double d) { ghhrobust_search(i, d); }
> 
> This must not produce an error, because it is 100% valid according to the C
> standard. An int can be converted to a double and a double can be converted
> to an int, so the code is valid.
> 
> If you use -Wconversion you get a warning:
> 
> 
> a.c: In function ‘void f(int, double)’:
> a.c:3:48: warning: conversion to ‘int’ from ‘double’ may alter its value
> [-Wfloat-conversion]
>  void f(int i, double d) { ghhrobust_search(i, d); }
>                                                 ^
> 
> This seems to be what you're looking for. Indeed, compiling your attached
> code with -Wconversion gives a warning on the relevant line:
> 
> fail_contour.c: In function ‘contour_trace’:
> fail_contour.c:203:56: warning: conversion to ‘int’ from ‘double’ may alter
> its value [-Wfloat-conversion]
Comment 3 Jonathan Wakely 2018-04-16 20:20:52 UTC
(In reply to Gerhard Heinzel from comment #2)
> (In reply to Jonathan Wakely from comment #1)
> 
> Many thanks for your quick response. 
> I normally don't use -Wconversion because it floods me with
> uninteresting errors about size_t, floor(), and code from bison/flex etc. 

Yes, it's true that it produces a lot of warnings (which is why it isn't enabled by -Wall).

It might be possible to add a new warning for cases where the arguments are "obviously" transposed.

For example, in my reduced version:

void ghhrobust_search (double ay, int type) { }

void f(int i, double d) { ghhrobust_search(i, d); }

Although both conversions are allowed by the language, the fact that swapping the arguments would require no conversions could be used to detect cases that might be accidental.

Confirming as an enhancement request for a new warning.