[Bug c/70742] Support div as a builtin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70742 Andrew Pinski changed: What|Removed |Added Assignee|andres.tiraboschi@tallertec |unassigned at gcc dot gnu.org |hnologies.com | Status|ASSIGNED|NEW
[Bug c/70742] Support div as a builtin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70742 Andrew Pinski changed: What|Removed |Added CC||david at westcontrol dot com --- Comment #15 from Andrew Pinski --- *** Bug 100890 has been marked as a duplicate of this bug. ***
[Bug c/70742] Support div as a builtin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70742
--- Comment #14 from Richard Biener ---
We could implement __builtin_ variants with a different ABI, returning the
quotiend and remainder in a (GCC extension) _Complex int type. The library
would then do
#define div(a, b) ({ div_t res; _Complex int r = __builtin_div(a,b); res.quot =
_Real r; res.rem = _Imag r; res; })
that's without an inline function. It's also way nicer to GCC internally,
not requiring memory for the return value - we'd have to lower to this kind
of internal code anyways to make code-generation good.
[Bug c/70742] Support div as a builtin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70742 Eric Gallager changed: What|Removed |Added Status|NEW |ASSIGNED CC||egallager at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |andres.tiraboschi@tallertec ||hnologies.com --- Comment #13 from Eric Gallager --- (In reply to Daniel Gutson from comment #4) > Please assign this to andres.tirabos...@tallertechnologies.com OK, done
[Bug c/70742] Support div as a builtin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70742 --- Comment #12 from joseph at codesourcery dot com --- A script that assumes build = host = target is obviously unacceptable. You can't do any compilations for $target at all when configuring GCC, only when configuring its runtime libraries such as libgcc, because there may not be a pre-existing compiler for $target at all. You can grep target headers if they are available at configure time, but that's all, and they may not be available. I think you'd need to defer associating a declaration with a built-in function until after the declaration of div in a system header has been seen, at which point you have the header's declaration of div_t available (ISO C doesn't allow calling div without including the header that declares it). This delayed declaration does of course make it different from all existing built-in functions.
[Bug c/70742] Support div as a builtin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70742 --- Comment #11 from Marcos Diaz --- (In reply to Daniel Gutson from comment #10) > (In reply to Marc Glisse from comment #8) > > "The div, ldiv, and lldiv functions return a structure of type div_t, > > ldiv_t, and lldiv_t, respectively, comprising both the quotient and the > > remainder. The structures shall contain (in either order) the members quot > > (the quotient) and rem (the remainder), each of which has the same type as > > the arguments numer and denom." > > > > So while we know the names and types of the fields, we don't know their > > order (unless stdlib.h was included). > > > IIUC, this is a new situation that has never occurred before regarding > builtins. > If so, maybe a new mechanism should be developed, that we add a couple of > offsetof(div_t) sometime during the building of gcc so the offsets are known > by the builtins. IOW, some kind of script invoked by the build system that > generates a header file containing the offsets of the members of the > structure... > Maybe something like the attachment > (https://gcc.gnu.org/bugzilla/attachment.cgi?id=38323) > Then, we include the generated header file (which contains the offsets) from > the source file that implements the builtin. > > Would this be acceptable? I'm not sure what about the first time when > bootstrapping, or when building a cross-compiler. But that way the offsets will remain hard-coded into the compiler, and it won't will be able to work with another libc or user definition of div_t
[Bug c/70742] Support div as a builtin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70742 --- Comment #10 from Daniel Gutson --- (In reply to Marc Glisse from comment #8) > "The div, ldiv, and lldiv functions return a structure of type div_t, > ldiv_t, and lldiv_t, respectively, comprising both the quotient and the > remainder. The structures shall contain (in either order) the members quot > (the quotient) and rem (the remainder), each of which has the same type as > the arguments numer and denom." > > So while we know the names and types of the fields, we don't know their > order (unless stdlib.h was included). IIUC, this is a new situation that has never occurred before regarding builtins. If so, maybe a new mechanism should be developed, that we add a couple of offsetof(div_t) sometime during the building of gcc so the offsets are known by the builtins. IOW, some kind of script invoked by the build system that generates a header file containing the offsets of the members of the structure... Maybe something like the attachment (https://gcc.gnu.org/bugzilla/attachment.cgi?id=38323) Then, we include the generated header file (which contains the offsets) from the source file that implements the builtin. Would this be acceptable? I'm not sure what about the first time when bootstrapping, or when building a cross-compiler.
[Bug c/70742] Support div as a builtin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70742 --- Comment #9 from Daniel Gutson --- Created attachment 38323 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38323=edit sample script to be called from the build system
[Bug c/70742] Support div as a builtin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70742 --- Comment #8 from Marc Glisse --- "The div, ldiv, and lldiv functions return a structure of type div_t, ldiv_t, and lldiv_t, respectively, comprising both the quotient and the remainder. The structures shall contain (in either order) the members quot (the quotient) and rem (the remainder), each of which has the same type as the arguments numer and denom." So while we know the names and types of the fields, we don't know their order (unless stdlib.h was included).
[Bug c/70742] Support div as a builtin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70742 --- Comment #7 from Richard Biener --- The compiler would need to provide div_t as a builtin-type. Or the standard specifies it enough so that layout issues are no worry.
[Bug c/70742] Support div as a builtin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70742
--- Comment #6 from Daniel Gutson
---
(In reply to Marc Glisse from comment #5)
> It seems to me that the reason we don't already have div as a builtin is
> that we need to know the layout of div_t.
>
> In a header, you don't really need inline asm:
> inline div_t div(int a, int b){ div_t q; q.quot=a/b; q.rem=a%b; return q; }
:) that was the whole discussion with the glibc maintainers: they don't want
inline functions. Please look at the discussions there, and consider to join.
[Bug c/70742] Support div as a builtin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70742
--- Comment #5 from Marc Glisse ---
It seems to me that the reason we don't already have div as a builtin is that
we need to know the layout of div_t.
In a header, you don't really need inline asm:
inline div_t div(int a, int b){ div_t q; q.quot=a/b; q.rem=a%b; return q; }
[Bug c/70742] Support div as a builtin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70742 --- Comment #4 from Daniel Gutson --- Please assign this to andres.tirabos...@tallertechnologies.com
[Bug c/70742] Support div as a builtin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70742 --- Comment #3 from Daniel Gutson --- (In reply to Andrew Pinski from comment #1) > Let me reword the summary. what you want is div and ldiv and imaxdiv to be and lldiv > supported as a builtin, in that it expands correctly to do the div/mod > inlined. > > >The goal is that std::div and cstdlib's div can be reimplemented as calling > >this builtin. > > Or rather they stay the way they are and GCC rewrites it to be correct. AKA > no reimplementing at all.
[Bug c/70742] Support div as a builtin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70742 --- Comment #2 from Daniel Gutson --- (In reply to Andrew Pinski from comment #1) > Let me reword the summary. what you want is div and ldiv and imaxdiv to be > supported as a builtin, in that it expands correctly to do the div/mod > inlined. > > >The goal is that std::div and cstdlib's div can be reimplemented as calling > >this builtin. > > Or rather they stay the way they are and GCC rewrites it to be correct. AKA > no reimplementing at all. That's correct, my bad: the goal is actually not touching the library at all.
[Bug c/70742] Support div as a builtin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70742 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2016-04-20 Summary|Add a builtin for obtaining |Support div as a builtin |a quotient and remainder of | |an integer division | Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Let me reword the summary. what you want is div and ldiv and imaxdiv to be supported as a builtin, in that it expands correctly to do the div/mod inlined. >The goal is that std::div and cstdlib's div can be reimplemented as calling >this builtin. Or rather they stay the way they are and GCC rewrites it to be correct. AKA no reimplementing at all.
