public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "tschwinge at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug libgomp/107041] New: [13 Regression] C '-Wenum-int-mismatch' diagnostic for OpenACC 'acc_on_device' Date: Mon, 26 Sep 2022 13:42:27 +0000 [thread overview] Message-ID: <bug-107041-4@http.gcc.gnu.org/bugzilla/> (raw) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107041 Bug ID: 107041 Summary: [13 Regression] C '-Wenum-int-mismatch' diagnostic for OpenACC 'acc_on_device' Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: openacc Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: tschwinge at gcc dot gnu.org CC: burnus at gcc dot gnu.org, jakub at gcc dot gnu.org, mpolacek at gcc dot gnu.org, vries at gcc dot gnu.org Target Milestone: --- Clean for C++: $ printf '#include <openacc.h>\nint foo(){ return acc_on_device(acc_device_host); }\n' | build-gcc/gcc/xgcc -Bbuild-gcc/gcc -Isource-gcc/libgomp -x c++ - -fopenacc -S -Wall ..., but not anymore for C: $ printf '#include <openacc.h>\nint foo(){ return acc_on_device(acc_device_host); }\n' | build-gcc/gcc/xgcc -Bbuild-gcc/gcc -Isource-gcc/libgomp -x c - -fopenacc -S -Wall In file included from <stdin>:1: source-gcc/libgomp/openacc.h:103:5: warning: conflicting types for ‘acc_on_device’ due to enum/integer mismatch; have ‘int(acc_device_t)’ [-Wenum-int-mismatch] 103 | int acc_on_device (acc_device_t __arg) __GOACC_NOTHROW; | ^~~~~~~~~~~~~ That's commit r13-627-g7da9a089608b0ca09683332ce014fb6184842724 "c: Implement new -Wenum-int-mismatch warning [PR105131]". This causes excess errors (only!) for 'libgomp.oacc-c/../libgomp.oacc-c-c++-common/host_data-1.c' (when its prerequisites are met); that's one of the few libgomp test cases where '-Wall' is in effect. (I'd "complained" about lack of '-Wall' testing before.) OpenACC 'acc_on_device' is implemented as follows: libgomp/openacc.h-#ifdef __cplusplus libgomp/openacc.h:int acc_on_device (int __arg) __GOACC_NOTHROW; libgomp/openacc.h-#else libgomp/openacc.h:int acc_on_device (acc_device_t __arg) __GOACC_NOTHROW; libgomp/openacc.h-#endif libgomp/openacc.h-#ifdef __cplusplus libgomp/openacc.h-[...] libgomp/openacc.h- libgomp/openacc.h-/* Forwarding function with correctly typed arg. */ libgomp/openacc.h- libgomp/openacc.h-#pragma acc routine seq libgomp/openacc.h:inline int acc_on_device (acc_device_t __arg) __GOACC_NOTHROW libgomp/openacc.h-{ libgomp/openacc.h: return acc_on_device ((int) __arg); libgomp/openacc.h-} libgomp/openacc.h-#endif gcc/omp-builtins.def:DEF_GOACC_BUILTIN_COMPILER (BUILT_IN_ACC_ON_DEVICE, "acc_on_device", gcc/omp-builtins.def- BT_FN_INT_INT, ATTR_CONST_NOTHROW_LEAF_LIST) libgomp/oacc-init.c:/* For -O and higher, the compiler always attempts to expand acc_on_device, but libgomp/oacc-init.c- if the user disables the builtin, or calls it via a pointer, we'll need this libgomp/oacc-init.c- version. libgomp/oacc-init.c- libgomp/oacc-init.c- Compile this with optimization, so that the compiler expands libgomp/oacc-init.c- this, rather than generating infinitely recursive code. libgomp/oacc-init.c- libgomp/oacc-init.c: The function just forwards its argument to __builtin_acc_on_device. It does libgomp/oacc-init.c- not verify that the argument is a valid acc_device_t enumeration value. */ libgomp/oacc-init.c- libgomp/oacc-init.c-int __attribute__ ((__optimize__ ("O2"))) libgomp/oacc-init.c:acc_on_device (acc_device_t dev) libgomp/oacc-init.c-{ libgomp/oacc-init.c: return __builtin_acc_on_device (dev); libgomp/oacc-init.c-} libgomp/oacc-init.c- libgomp/oacc-init.c:ialias (acc_on_device) If I remember correctly, the reason for the "strange" prototyping/forwarding is that GCC builtins don't allow for 'enum' arguments? (I may be misremembering.) --- Maybe a fix for this would fall out of Tom's patch for PR82391 "[openacc] acc_on_device not folded at -O0"? (I've paged out all state of that one, unfortunately.)
next reply other threads:[~2022-09-26 13:42 UTC|newest] Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-09-26 13:42 tschwinge at gcc dot gnu.org [this message] 2022-09-27 8:50 ` [Bug libgomp/107041] " rguenth at gcc dot gnu.org 2022-12-22 14:35 ` rguenth at gcc dot gnu.org 2023-03-27 13:55 ` rguenth at gcc dot gnu.org 2023-04-17 15:23 ` [Bug libgomp/107041] [13/14 " jakub at gcc dot gnu.org 2023-04-17 17:36 ` jakub at gcc dot gnu.org 2023-04-18 8:39 ` jakub at gcc dot gnu.org 2023-04-20 17:30 ` cvs-commit at gcc dot gnu.org 2023-04-26 6:56 ` rguenth at gcc dot gnu.org 2023-04-26 8:37 ` cvs-commit at gcc dot gnu.org 2023-04-26 8:38 ` jakub at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-107041-4@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).