Here's the patch:

Werner Koch <wk@gnupg.org> added the comment:

Please show me the disassembly of an example along with the commands and program
versions you used to create an object file with removed wipememory code.

volatile is used to make sure the writes actually hit the
memory. gcc is not allowed to remove that for the simple reason, it
can't know whether this plain RAM or a device mapped into the address
space. That is the whole point of using volatile and it has been
introduced back in the 80ies for just this reason (back than to write
to video memory).

One relatively unimportant misunderstanding is due to the fact that
the standard only talks about accesses to volatile objects. It does
not talk about accesses via volatile qualified pointers. Some
programmers believe that using a pointer-to-volatile should be
handled as though it pointed to a volatile object. That is not
guaranteed by the standard and is therefore not portable. However,
this is relatively unimportant because gcc does in fact treat a
pointer-to-volatile as though it pointed to a volatile object.

It says that it's not guaranteed and it's not portable by the C
language itself.

So, you are right that volatile qualifier to a pointer should be
avoided (from viewpoint of portability).

I think that I am also right that it works with GCC implementation
(in 2008, at least).

I'm actually more concerned that the optimizer will remove the code
because it surmises its a dead store. That's the issue I am trying to
articulate.

You shouldn't use volatile for that when compiling with GCC.

Any references which support this opinion of yours, please?

On Tue, Jun 16, 2015 at 4:31 AM, NIIBE Yutaka via BTS
<gnupg@bugs.g10code.com> wrote:

NIIBE Yutaka <gniibe@fsij.org> added the comment:

I think that JW had some confusion. I believe that his argument is irrelevant
for libgcrypt's implementation of wipememory.

Changed status to 'unread'. I'm not chatting.

I was able to duplicate Bug 1862: Building static GnuPG 2.1.2 fails due to
multiply defined symbols.

/home/jwalton/Desktop/gcrypt-2.0-analyze/libgpg-error-1.18/src/visibility.c:46:
multiple definition of `gpg_err_code_from_errno'
t-support.o:/home/jwalton/Desktop/gcrypt-2.0-analyze/gnupg-2.1.2/common/t-support.c:137:
first defined here
/home/jwalton/gpg-analyze/lib/libgpg-error.a(libgpg_error_la-visibility.o): In
function `gpg_err_code_from_syserror':
/home/jwalton/Desktop/gcrypt-2.0-analyze/libgpg-error-1.18/src/visibility.c:58:
multiple definition of `gpg_err_code_from_syserror'
t-support.o:/home/jwalton/Desktop/gcrypt-2.0-analyze/gnupg-2.1.2/common/t-support.c:151:
first defined here
collect2: error: ld returned 1 exit status
make[3]: * [t-stringhelp] Error 1
make[3]: Leaving directory
`/home/jwalton/Desktop/gcrypt-2.0-analyze/gnupg-2.1.2/common'
make[2]: * [all] Error 2
make[2]: Leaving directory
`/home/jwalton/Desktop/gcrypt-2.0-analyze/gnupg-2.1.2/common'
make[1]: * [all-recursive] Error 1
make[1]: Leaving directory `/home/jwalton/Desktop/gcrypt-2.0-analyze/gnupg-2.1.2'
make: * [all] Error 2

LIBRARY=gnupg
VERSION=2.1.2
FILE="$LIBRARY-$VERSION"

export PREFIX=/usr/local

cd "$FILE"
./configure --enable-static --disable-shared
--with-libgpg-error-prefix="$PREFIX" --with-libassuan-prefix="$PREFIX"
--with-ksba-prefix="$PREFIX" --with-npth-prefix="$PREFIX"
--with-libgcrypt-prefix="$PREFIX" --prefix="$PREFIX"

make

Changed status to 'unread'. I am not chatting.

Also see "Is a misaligned load due to a cast undefined behavior?"
(http://stackoverflow.com/q/28893303) on Stack Overflow.

I wanted to verify it was in fact undefined behavior.

Changed status to 'unread'. I'm not chatting.

Changed status to 'unread'. I'm not chatting.

Changed status to 'unread'. I'm not chatting.

Updated cert.c which initializes the variable algo.

The following still harbors undefined behavior, but I did not want to touch it
due to fears of breaking the zeoizer:

cipher-gcm.c:1144:7: runtime error: store to misaligned address...
cipher-gcm.c:1145:7: runtime error: store to misaligned address...
cipher-gcm.c:1146:7: runtime error: store to misaligned address...

wipememory (c->u_mode.gcm.tagiv, GCRY_GCM_BLOCK_LEN);  // Line 1144
wipememory (c->u_mode.gcm.aadlen, sizeof (c->u_mode.gcm.aadlen)); // Line 1145
wipememory (c->u_mode.gcm.datalen, sizeof (c->u_mode.gcm.datalen)); //

Line 1146

cipher-ccm.c:280:7: runtime error: store to misaligned address...

wipememory (c->u_mode.ccm.macbuf, 16);  // Line 280

Attached is the script I am using to acceptance test the suite. It requires
Clang 3.5 (Clang 3.5 recipe was provided with Bug 1872).