Perl possible bugs with gcc 10, -O3 and unaligned long pointer deref

A bug was reported to the Sereal project which was traced to a change
in behavior of gcc.

https://github.com/Sereal/Sereal/issues/229

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

The bug relates to unaligned pointer dereference operations which we
do in Perl in certain places (hash engine in particular).

We should probably look into testing perl with this:

https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html

A known solution is to compile with -O2, or to use
-fno-tree-loop-vectorize with -O3.

From the gcc bug report:

"your unsigned long objects are not aligned according
to the type which makes the accesses undefined (actually C even specifies
forming the pointer itself is undefined)"

I feel like we had a discussion about this recently and I argued this
would never change, so I need to eat some crow.

cheers,
Yves




-- 
perl -Mre=debug -e "/just|another|perl|hacker/"
0
demerphq
7/29/2020 8:17:26 AM
perl.perl5.porters 48176 articles. 1 followers. Follow

2 Replies
14 Views

Similar Articles

[PageSpeed] 55

--000000000000c4e0e505ab97d244
Content-Type: text/plain; charset="UTF-8"

On Wed, Jul 29, 2020 at 10:17 AM demerphq <demerphq@gmail.com> wrote:

> A bug was reported to the Sereal project which was traced to a change
> in behavior of gcc.
>
> https://github.com/Sereal/Sereal/issues/229
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96326
>
> The bug relates to unaligned pointer dereference operations which we
> do in Perl in certain places (hash engine in particular).
>
> We should probably look into testing perl with this:
>
> https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html
>
> A known solution is to compile with -O2, or to use
> -fno-tree-loop-vectorize with -O3.
>
> From the gcc bug report:
>
> "your unsigned long objects are not aligned according
> to the type which makes the accesses undefined (actually C even specifies
> forming the pointer itself is undefined)"
>
> I feel like we had a discussion about this recently and I argued this
> would never change, so I need to eat some crow.
>

Wouldn't such code already be problematic on architectures with strict
alignment requirements? (e.g. SPARC) And hence we should have noticed
already if we have such a problem?

Leon

--000000000000c4e0e505ab97d244
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wed, Jul 29, 2020 at 10:17 AM demerphq &lt;<a href=3D"m=
ailto:demerphq@gmail.com">demerphq@gmail.com</a>&gt; wrote:<br><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">A bug wa=
s reported to the Sereal project which was traced to a change<br>
in behavior of gcc.<br>
<br>
<a href=3D"https://github.com/Sereal/Sereal/issues/229" rel=3D"noreferrer" =
target=3D"_blank">https://github.com/Sereal/Sereal/issues/229</a><br>
<br>
<a href=3D"https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D96326" rel=3D"nor=
eferrer" target=3D"_blank">https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D9=
6326</a><br>
<br>
The bug relates to unaligned pointer dereference operations which we<br>
do in Perl in certain places (hash engine in particular).<br>
<br>
We should probably look into testing perl with this:<br>
<br>
<a href=3D"https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html" rel=
=3D"noreferrer" target=3D"_blank">https://clang.llvm.org/docs/UndefinedBeha=
viorSanitizer.html</a><br>
<br>
A known solution is to compile with -O2, or to use<br>
-fno-tree-loop-vectorize with -O3.<br>
<br>
From the gcc bug report:<br>
<br>
&quot;your unsigned long objects are not aligned according<br>
to the type which makes the accesses undefined (actually C even specifies<b=
r>
forming the pointer itself is undefined)&quot;<br>
<br>
I feel like we had a discussion about this recently and I argued this<br>
would never change, so I need to eat some crow.<br></blockquote><div><br></=
div><div>Wouldn&#39;t such code already be problematic on architectures wit=
h strict alignment requirements? (e.g. SPARC) And hence we should have noti=
ced already if we have such a problem?</div><div><br></div><div>Leon<br></d=
iv></div></div>

--000000000000c4e0e505ab97d244--
0
fawaka
7/29/2020 5:23:14 PM
On Wed, Jul 29, 2020 at 10:17:26AM +0200, demerphq wrote:
> A bug was reported to the Sereal project which was traced to a change
> in behavior of gcc.
> 
> https://github.com/Sereal/Sereal/issues/229
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96326
> 
> The bug relates to unaligned pointer dereference operations which we
> do in Perl in certain places (hash engine in particular).
> 
> We should probably look into testing perl with this:
> 
> https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html
> 
> A known solution is to compile with -O2, or to use
> -fno-tree-loop-vectorize with -O3.
> 
> >From the gcc bug report:
> 
> "your unsigned long objects are not aligned according
> to the type which makes the accesses undefined (actually C even specifies
> forming the pointer itself is undefined)"
> 
> I feel like we had a discussion about this recently and I argued this
> would never change, so I need to eat some crow.

In blead (and 5.32) the versions of the macros that try unaligned
access are guarded by C<#ifdef USE_UNALIGNED_PTR_DEREF> which perl
never defines itself.  See ed16b18d62c264e7e9331ea67931b66b7d976bb9
for that change and b8c77730539d8b2e48e6f7431c34b95ea893926b for the
merge where unaligned access was originally removed.

So it may be a problem in 5.30, but it's not a problem in 5.32 or
blead unless you explicitly request it.

IIRC the original issue was that compilers were optimizing the
original d_u32align probe on systems that don't allow unaligned access
to make it look like the system did support it.

Tony
0
tony
7/30/2020 4:06:45 AM
Reply: