[Bug c/64509] _Generic throws error in unselected generic association

[maurits.de.jong at ericsson dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64509

--- Comment #4 from Martien de Jong maurits.de.jong at ericsson dot com ---
I understand. What a shallow and ugly feature it is then. I think it can only
usefully be employed using a preprocessor macro, yet it is part of the 
expression syntax. It is meant to resolve type issues, yet all variants
should be type-sane. You can indeed implement something like tgmath.h with it,
but only if the types can be implictly converted.

BTW, I notice that

./gcc/ginclude/tgmath.h

uses

__builtin_classify_type
__builtin_types_compatible_p
__builtin_choose_expr

Will it move to using _Generic() ?

[Bug c/64509] New: _Generic throws error in unselected generic association

[maurits.de.jong at ericsson dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64509

Bug ID: 64509
   Summary: _Generic throws error in unselected generic
association
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: maurits.de.jong at ericsson dot com

Created attachment 34387
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34387action=edit
The offending source separately

I would have expected this to work (basically insert a conversion function
call if the type doesn't match):


-
typedef struct {
int x;
} mystruct;

extern int __f(int);
extern int __stoi(mystruct);

void call(void)
{
mystruct S = {1};

double z = _Generic((S), mystruct: __f(__stoi(S)), default: __f(S));
}
-

but the typechecker is not happy about __f(S), which is in an association 
not relevant for the controlling expression:

The standard says:

  None of the expressions from any other generic association of the generic
  selection is evaluated.

Of course, evaluation is different from typechecking, but since the construct
is intended to conditionalise based on types, wouldn't it make sense to only
typecheck the selected association?




bash$ ./bin/gcc -std=c11 -v generic.c
Using built-in specs.
COLLECT_GCC=./bin/gcc
COLLECT_LTO_WRAPPER=/space/radmmj/gcc492/gcc-4.9.2/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/space/radmmj/gcc492/gcc-4.9.2 :
(reconfigured) ../configure --prefix=/space/radmmj/gcc492/gcc-4.9.2
--enable-languages=c
Thread model: posix
gcc version 4.9.2 (GCC) 
COLLECT_GCC_OPTIONS='-std=c11' '-v' '-mtune=generic' '-march=x86-64'
 /space/radmmj/gcc492/gcc-4.9.2/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2/cc1
-quiet -v -imultiarch x86_64-linux-gnu generic.c -quiet -dumpbase generic.c
-mtune=generic -march=x86-64 -auxbase generic -std=c11 -version -o
/tmp/ccEshK6s.s
GNU C (GCC) version 4.9.2 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.9.2, GMP version 4.3.2, MPFR version 2.4.2,
MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory /usr/local/include/x86_64-linux-gnu
ignoring nonexistent directory
/space/radmmj/gcc492/gcc-4.9.2/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../x86_64-unknown-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
 /space/radmmj/gcc492/gcc-4.9.2/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/include
 /usr/local/include
 /space/radmmj/gcc492/gcc-4.9.2/include

/space/radmmj/gcc492/gcc-4.9.2/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
GNU C (GCC) version 4.9.2 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.9.2, GMP version 4.3.2, MPFR version 2.4.2,
MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 1bfa4fb39c457521c17e15d89fa44581
generic.c: In function ‘call’:
generic.c:12:69: error: incompatible type for argument 1 of ‘__f’
 double z = _Generic((S), mystruct: __f(__stoi(S)), default: __f(S));
 ^
generic.c:5:12: note: expected ‘int’ but argument is of type ‘mystruct’
 extern int __f(int);
^

[Bug c/64509] _Generic throws error in unselected generic association

[maurits.de.jong at ericsson dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64509

--- Comment #2 from Martien de Jong maurits.de.jong at ericsson dot com ---
That's just rephrasing my bugreport. The question is, should it type check
while parsing an expression that may not be realized? The entire idea of
switching on a type is to prevent and fix type errors, no?