Re: [PATCH v2 1/2] system_data_types.7: Add 'void *'

[Vincent Lefevre]

On 2020-10-12 11:36:57 +0200, Michael Kerrisk (man-pages) via Gcc wrote:
> Hello Vincent,
> 
> On Thu, 8 Oct 2020 at 15:52, Vincent Lefevre  wrote:
> >
> > On 2020-10-01 18:55:04 +0200, Alejandro Colomar via Gcc wrote:
[...]
> > > The most explicit paragraph in dlsym is the following:
> > >
> > > [[
> > > Note that conversion from a void * pointer to a function pointer as in:
> > >
> > > fptr = (int (*)(int))dlsym(handle, "my_function");
> > >
> > > is not defined by the ISO C standard.
> > > This standard requires this conversion to work correctly
> > > on conforming implementations.
> > > ]]
> >
> > I think that "this conversion" applies only to the dlsym context,
> > and the conversion isn't defined in general. Imagine that the
> > void * pointer to function pointer conversion requires the compiler
> > to generate additional code. The compiler may be able to detect
> > that dlsym will not be used in some contexts (e.g. because of
> > always false condition) and do not generate such additional code,
> > making the conversion to have undefined behavior.
> 
> Thanks. It's a good point that you raise.
> 
> I agree that the wording in the standard is not too clear. But I
> believe the intent really is to allow
> [void *] <==> [function pointer] casts.

In this case, this should be standardized. In particular, there
is an issue with the rationale...

> The most relevant pieces I can find are as follows:
> 
> In the current standard, in CHANGE HISTORY for dlsum():
> 
> [[
> Issue 6
> IEEE Std 1003.1-2001/Cor 1-2002, item XSH/TC1/D6/14 is applied,
> correcting an example, and
> adding text to the RATIONALE describing issues related to conversion
> of pointers to functions
> and back again.
> Issue 7
> POSIX.1-2008, Technical Corrigendum 1, XSH/TC1-2008/0074 [74] is applied.
> ]]
> 
> https://www.austingroupbugs.net/view.php?id=74
> This is a little thin. The initial report says:
> "The intent is simply to permit dlsym to use a void * as its return type."
> and no one seems to have questioned that.
> 
> And then in https://pubs.opengroup.org/onlinepubs/7899949299/toc.pdf
> (TC1 for POSIXX.1-2001)
> 
> there is:
> 
> [[
> Change Number: XSH/TC1/D6/14 [XSH ERN 13]
> On Page: 259  Line: 8566,8590  Section: dlsym
> In the EXAMPLES section, change from:
> fptr = (int (*)(int))dlsym(handle, "my_function");
> to:
> *(void **)(&fptr) = dlsym(handle, "my_function");
> In the RATIONALE section on Page 260, Line 8590, change from:
> "None."
> to:
> "The C Standard does not require that pointers to functions can be
> cast back and forth to pointers to data. Indeed, the C Standard
> does not require that an object of type void* can hold a pointer
> to a function.  Systems supporting the X/Open System Interfaces
> Extension, however, do require that an object of type void* can
> hold a pointer to a function.  The result of converting a pointer
> to a function into a pointer to another data type (except void*)
> is still undefined, however.
> ]]

The last sentence is rather strange. This means that conversion
between pointers would not be transitive, contrary to the intent
of ISO C (via the transitivity of "correctly aligned").

In ISO C, the conversion of a void * to a pointer to another data type
is undefined only if the resulting pointer is not correctly aligned.

In particular, my interpretation of ISO C is that a conversion of
a void * to a char * is always defined. So, if the conversion of
a function pointer to void * is well-defined as a general rule, I
expect that the conversion of a function pointer to char * is also
well-defined, contrary to what the rationale says.

> And one finds the above text in POSIX.1-2001 TC1 spec for dlsym(),
> although it was removed in POSIX.1-2008, and now we have just the
> smaller text that is present in the dlsym() page. But along the way, I
> can find nothing that speaks against the notion that POSIX was aiming
> to allow the more general cast of [void *] <==> [function pointer].
> Your thoughts?

The equivalence of representation between function pointers and void *
may seem natural on von Neumann architectures, but what if functions,
or at least *some* functions (not those returned by dlsym), are from
a separate addressing model? For instance, one could think that some
compilers might implement particular standard functions only as
builtins, with some special handling when pointers to such functions
are used.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

https://gcc.gnu.org/

[Annie J.Seay via Gcc]

   Hello.

I need your this site for guest posting. This time my budget is low. So i
can pay you 10$ each post. So please accepted my offer i send you article
soon.

gcc-8-20201022 is now available

[GCC Administrator via Gcc]

Snapshot gcc-8-20201022 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/8-20201022/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 8 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-8 
revision 2819cdd8ff8e15ed5efb4095143cf531cf3e50f9

You'll find:

 gcc-8-20201022.tar.xzComplete GCC

  SHA256=6294addd898163fe89f19e5074414ca8eed49766d9ec5aaad40729a3006b364d
  SHA1=918ed7e844d3a79583f2b511bd90f3128d6f364f

Diffs from 8-20201015 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-8
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Missing functionality

[Gary Oblock via Gcc]

I'm finishing up coding my patterns for the structure reorganization
optimization. They recognize certain instructions and replace them
other instructions. I've got some code that generates gimple which is
inserted as it's created with gsi_insert_before.  This code is
something I'd like to use at other points in my optimization so I'd
like to create a function to do this.

Now comes the interesting bit. I'd like to use gimple sequences and
after reading the internals documentation I put together something
using gimple_seq_add_stmt to add the generated gimple to a new
sequence. After this I tried inserting the sequence into the basic
block's sequence with gsi_link_seq_before. It turns out there is no
gsi_link_seq_before! I could probably write one myself but that begs
the question, why is there no gsi_link_seq_before and what should I
use instead?

Thank

Gary


CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for 
the sole use of the intended recipient(s) and contains information that is 
confidential and proprietary to Ampere Computing or its subsidiaries. It is to 
be used solely for the purpose of furthering the parties' business 
relationship. Any unauthorized review, copying, or distribution of this email 
(or any attachments thereto) is strictly prohibited. If you are not the 
intended recipient, please contact the sender immediately and permanently 
delete the original and any copies of this email and any attachments thereto.

Regarding last question

[Gary Oblock via Gcc]

Never mind... assume I'm grumbling about the documentation.

;-(

Gary


CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for 
the sole use of the intended recipient(s) and contains information that is 
confidential and proprietary to Ampere Computing or its subsidiaries. It is to 
be used solely for the purpose of furthering the parties' business 
relationship. Any unauthorized review, copying, or distribution of this email 
(or any attachments thereto) is strictly prohibited. If you are not the 
intended recipient, please contact the sender immediately and permanently 
delete the original and any copies of this email and any attachments thereto.

Re: Missing functionality

[Richard Biener via Gcc]

On Fri, Oct 23, 2020 at 5:10 AM Gary Oblock via Gcc  wrote:
>
> I'm finishing up coding my patterns for the structure reorganization
> optimization. They recognize certain instructions and replace them
> other instructions. I've got some code that generates gimple which is
> inserted as it's created with gsi_insert_before.  This code is
> something I'd like to use at other points in my optimization so I'd
> like to create a function to do this.
>
> Now comes the interesting bit. I'd like to use gimple sequences and
> after reading the internals documentation I put together something
> using gimple_seq_add_stmt to add the generated gimple to a new
> sequence. After this I tried inserting the sequence into the basic
> block's sequence with gsi_link_seq_before. It turns out there is no
> gsi_link_seq_before! I could probably write one myself but that begs
> the question, why is there no gsi_link_seq_before and what should I
> use instead?

gsi_insert_seq_before

> Thank
>
> Gary
>
>
> CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is 
> for the sole use of the intended recipient(s) and contains information that 
> is confidential and proprietary to Ampere Computing or its subsidiaries. It 
> is to be used solely for the purpose of furthering the parties' business 
> relationship. Any unauthorized review, copying, or distribution of this email 
> (or any attachments thereto) is strictly prohibited. If you are not the 
> intended recipient, please contact the sender immediately and permanently 
> delete the original and any copies of this email and any attachments thereto.