[llvm-dev] DenseMap/ValueMap: is M[New]=M[Old] valid ?

David Blaikie via llvm-dev llvm-dev at lists.llvm.org
Thu Sep 26 23:16:28 PDT 2019


I'd be surprised if Clang or GCC's behavior here varied depending on the
size of anything, but maybe?

In any case, C++17 or so requires the RHS to be evaluated before the LHS
for assignments - so this is now /always/ wrong, not just unspecified
(which, I guess, also always wrong... just sometimes accidentally right) as
it was before.

On Thu, Sep 26, 2019 at 10:58 PM Martin Storsjö <martin at martin.st> wrote:

> I actually ran into an elusive bug with this exact same issue some time
> ago as well, see https://bugs.llvm.org/show_bug.cgi?id=42065 and
> https://reviews.llvm.org/D62624.
>
> The strange thing about that bug was that it only showed up if built with
> GCC; Clang dereferenced the right hand side reference before evaluating
> the left hand side, as long as the value type was as small as the
> reference itself.
>
> // Martin
>
> On Thu, 26 Sep 2019, David Blaikie via llvm-dev wrote:
>
> > Yep - You'd have to separate them for correctness if "NewKey" might not
> > already be in "M".
> >
> > On Thu, Sep 26, 2019 at 2:48 PM Jeroen Dobbelaere via llvm-dev
> > <llvm-dev at lists.llvm.org> wrote:
> >       Hi,
> >
> >       I have a question about llvm/ADT/DenseMap.h and
> >       llvm/IR/ValueMap.h:
> >
> >       When you have a:
> >            MapType M;
> >
> >       is it safe to do:
> >           M[NewKey] = M[OldKey];
> >
> >       or do you need to do it in two steps:
> >          auto tmp = M[OldKey]; // ensure the reference to M[OldKey] is
> >       copied, before reassigning.
> >          M[NewKey] = tmp;      // might reallocate
> >
> >       aka, will a possible allocation for M[NewKey] invalidate the
> >       reference that M[OldKey] returns ?
> >
> >       Greetings,
> >
> >       Jeroen Dobbelaere
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190926/47fdae40/attachment-0001.html>


More information about the llvm-dev mailing list