This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c/70742] Support div as a builtin


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

--- Comment #11 from Marcos Diaz <marcos.diaz at tallertechnologies dot com> ---
(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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]