Xiangling Liao via llvm-dev
2020-Oct-30 21:01 UTC
[llvm-dev] Questions about ctor/dtor attribute related diagnostics
Hi, I noticed that there are some diagnostics discrepancies between clang and gcc related to `__attribute__((constructor(n)))` and `__attribute__((destructor(n)))`. *[clang]* It seems priorities >65535 and <0 on ctor/dtor functions are ignored and are set back to default 65535 in clang and Clang only gives an error when > 32-bit unsigned value specified. *[g++]* g++ gives an error for any values <0 and >65535. I am wondering should we let Clang's diagnostics match g++ to make things clearer to the user? Or why Clang emits an error for *>32-bit unsigned value* only? Thank you, Xiangling -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201030/d7cb5ddc/attachment.html>
Xiangling Liao via llvm-dev
2020-Nov-05 14:10 UTC
[llvm-dev] Questions about ctor/dtor attribute related diagnostics
ping. On Fri, Oct 30, 2020 at 5:01 PM Xiangling Liao <xiangxdh at gmail.com> wrote:> Hi, > > I noticed that there are some diagnostics discrepancies between clang and > gcc related to `__attribute__((constructor(n)))` and > `__attribute__((destructor(n)))`. > > *[clang]* > It seems priorities >65535 and <0 on ctor/dtor functions are ignored and > are set back to default 65535 in clang and Clang only gives an error when > > 32-bit unsigned value specified. > > *[g++]* > g++ gives an error for any values <0 and >65535. > > I am wondering should we let Clang's diagnostics match g++ to make things > clearer to the user? Or why Clang emits an error for *>32-bit unsigned > value* only? > > Thank you, > Xiangling >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201105/bc20766c/attachment.html>
Aaron Ballman via llvm-dev
2020-Nov-05 14:30 UTC
[llvm-dev] Questions about ctor/dtor attribute related diagnostics
On Fri, Oct 30, 2020 at 5:03 PM Xiangling Liao via llvm-dev <llvm-dev at lists.llvm.org> wrote:> > Hi, > > I noticed that there are some diagnostics discrepancies between clang and gcc related to `__attribute__((constructor(n)))` and `__attribute__((destructor(n)))`. > > [clang] > It seems priorities >65535 and <0 on ctor/dtor functions are ignored and are set back to default 65535 in clang and Clang only gives an error when > 32-bit unsigned value specified. > > [g++] > g++ gives an error for any values <0 and >65535. > > I am wondering should we let Clang's diagnostics match g++ to make things clearer to the user? Or why Clang emits an error for >32-bit unsigned value only?The code for this lives in SemaDeclAttr.cpp in `handleConstructorAttr()` and `handleDestructorAttr()`, both of which are defined similarly as trying to read the attribute argument as an unsigned 32-bit value. If the value is outside of the range of a 32-bit unsigned number, the `checkUInt32Argument()` helper function will diagnose it as an error. We don't have any further range checking happening for the argument, though. I think it's reasonable for us to match GCC's behavior with diagnostics here. You could model the check after what is done in `handleInitPriorityAttr()` which has to do a similar range check. However, you should also verify whether values < 0 or > 65535 are reserved to the implementation itself (perhaps are used as part of system headers like glibc) as they are with `init_priority` values < 101 or > 65535. The `init_priority` attribute shows how to exclude system headers from the range check if that's needed. ~Aaron> > Thank you, > Xiangling > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Fāng-ruì Sòng via llvm-dev
2020-Nov-05 16:46 UTC
[llvm-dev] Questions about ctor/dtor attribute related diagnostics
On Thu, Nov 5, 2020 at 6:31 AM Aaron Ballman via llvm-dev <llvm-dev at lists.llvm.org> wrote:> > On Fri, Oct 30, 2020 at 5:03 PM Xiangling Liao via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > > > Hi, > > > > I noticed that there are some diagnostics discrepancies between clang and gcc related to `__attribute__((constructor(n)))` and `__attribute__((destructor(n)))`. > > > > [clang] > > It seems priorities >65535 and <0 on ctor/dtor functions are ignored and are set back to default 65535 in clang and Clang only gives an error when > 32-bit unsigned value specified. > > > > [g++] > > g++ gives an error for any values <0 and >65535. > > > > I am wondering should we let Clang's diagnostics match g++ to make things clearer to the user? Or why Clang emits an error for >32-bit unsigned value only? > > The code for this lives in SemaDeclAttr.cpp in > `handleConstructorAttr()` and `handleDestructorAttr()`, both of which > are defined similarly as trying to read the attribute argument as an > unsigned 32-bit value. If the value is outside of the range of a > 32-bit unsigned number, the `checkUInt32Argument()` helper function > will diagnose it as an error. We don't have any further range checking > happening for the argument, though. > > I think it's reasonable for us to match GCC's behavior with > diagnostics here. You could model the check after what is done in > `handleInitPriorityAttr()` which has to do a similar range check. > However, you should also verify whether values < 0 or > 65535 are > reserved to the implementation itself (perhaps are used as part of > system headers like glibc) as they are with `init_priority` values < > 101 or > 65535. The `init_priority` attribute shows how to exclude > system headers from the range check if that's needed. > > ~AaronSupplement: the range [0,100] is reserved for use by system runtime libraries and will be warned by -Wprio-ctor-dtor (unimplemented in Clang). I added #pragma GCC diagnostic ignored "-Wprio-ctor-dtor" for exactly this diagnostic in compiler-rt/lib/profile/GCDAProfiling.c> > > > Thank you, > > Xiangling-- 宋方睿
Maybe Matching Threads
- Questions about ctor/dtor attribute related diagnostics
- [PATCH v3] drm/nouveau: Move irq setup/teardown to pci ctor/dtor
- [PATCH] drm/nouveau: Move irq setup/teardown to pci ctor/dtor
- [PATCH v2] drm/nouveau: Move irq setup/teardown to pci ctor/dtor
- [PATCH v3] drm/nouveau: Move irq setup/teardown to pci ctor/dtor