[m-rev.] for review: making pointer_equal a builtin
Zoltan Somogyi
zoltan.somogyi at runbox.com
Thu Nov 27 20:10:06 AEDT 2014
On Thu, 27 Nov 2014 18:00:30 +1100, Peter Wang <novalazy at gmail.com> wrote:
> > There was an inline pragma on its definition, but most programs, including
> > the compiler, are not compiled with the intermodule optimization options
> > that would allow this to take effect. Making it a builtin gets around this
> > problem.
>
> Minor point: most programs are compiled without intermodule optimization
> _during development_.
I don't know about you, but I don't enable intermodule optimization
on the compiler even when I install it.
> > +std_binop_to_elds(StdBinOp, EldsBinOp) :-
> > + require_complete_switch [StdBinOp]
> > + (
> > + ( StdBinOp = body
> > + ; StdBinOp = array_index(_)
> > + ; StdBinOp = unsigned_le
> > + ; StdBinOp = float_from_dword % XXX used to fail IMPLICITLY
> > + ; StdBinOp = float_word_bits % XXX used to fail IMPLICITLY
> > + ; StdBinOp = str_cmp % XXX used to fail IMPLICITLY
> > + ; StdBinOp = pointer_equal_conservative % handled in our caller
> > + ),
> > + fail
>
> That's fine. None of those ops would be used in the Erlang backend as
> far as I can tell. erl_gen_simple_expr would throw an exception if they
> were used.
OK, I will remove the XXXs, but I am still troubled by the "as far
as I can tell". I could also tell that these wouldn't be used during
a bootcheck, since if they were, the caller of the above predicate
would have aborted the program. The question is, how could you
guarantee that they wouldn't be used in ANY program?
The reason I asked was because I couldn't see how to provide
such a guarantee. I will think about that later.
> The rest looks okay as well. Please try installing the java, csharp,
> erlang grades if you haven't already done so.
I am afraid such attempts would tell me only that I don't have C#
or Erlang installed on my machine, and that my JDK is too ancient.
For some reason, I can't apt-get install anything nowadays. Whenever
I try apt-get install for *anything*, I get this error:
gpg: symbol lookup error: /usr/local/lib/libreadline.so.6gpg: : symbol lookup errorundefined symbol: UP: /usr/local/lib/libreadline.so.6:
undefined symbol: UP
dpkg: error processing apt (--configure):
subprocess installed post-installation script returned error exit status 127
Would anyone have any clue as to how to fix this?
(I have a clue about the reason: I had to install libreadline by ftping
and compiling the source, since I couldn't get the library via apt-get.)
Would anyone object if I committed this diff without those
bootchecks? I think the implementations of the new builtin
for the Java, C# and Erlang backends are simple enough
that the chances of a bug are not that high, and if they
do arise, the workaround is dead simple (just comment out
the few lines of builtin_ops.m that recognize the builtin).
Zoltan.
More information about the reviews
mailing list