Re: GNU OMPD implementation
Hi, On 01.12.21 19:35, Martin Jambor wrote: On Tue, Nov 30 2021, Mohamed Atef wrote: Where is the variable of the OpenMP version defined? The GCC code itself does not make a difference, contrary to C/C++/Fortran which have -std= OpenMP 4.5 (also known as 201511) is fully supported (minus bugs). Thus, that's the version number (201511) reported to the user. For Fortran, the 'openmp_version' parameter in the module 'omp_lib' and in omp_lib.h come from libgomp/omp_lib.f90.in and libgomp/omp_lib.h.in. For C/C++ (or Fortran with -cpp for the preprocessor), the value is in _OPENMP and is defined in gcc/c-family/c-cppbuiltin.c. However, while GCC only claims 4.5/201511 support, OpenMP 5.0 and 5.1 are partially implemented, cf. https://gcc.gnu.org/onlinedocs/libgomp/OpenMP-Implementation-Status.html Thus, when a later version of the spec changed behavior, GCC might not have 4.5 semantic but 5.0, 5.1 or even 5.2 (or later) semantic. This happens either when implementing a 5.x feature or when a bug in the spec was found which has then be fixed. For completeness, for exported symbols in libgomp, some versioning exists, cf. libgomp/libgomp.map. Thanks for working on OMPD! Tobias - Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955
Re: odd internal failure
On Wed, Dec 1, 2021 at 9:56 PM Gary Oblock wrote:
>
> Richard,
>
> I rebuilt at "-O0" and that particular call now works but on a call to
> the same function with a different offset it fails. 😱
use a debugger to see why
> Thanks,
>
> Gary
>
>
>
> From: Richard Biener
> Sent: Wednesday, December 1, 2021 1:09 AM
> To: Gary Oblock
> Cc: gcc@gcc.gnu.org
> Subject: Re: odd internal failure
>
> [EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please
> be mindful of safe email handling and proprietary information protection
> practices.]
>
>
> On Wed, Dec 1, 2021 at 8:46 AM Gary Oblock via Gcc wrote:
> >
> > What is happening should be trivial to determine but for some reason it's
> > not. I'd normally bounce this off a coworker but given the pandemic
> > and modern dispersed hiring practices it's not even remotely possible.
> >
> > I'm making this call and tree_to_uhwi is failing on an internal error.
> > That's normally easy to fix, but here is where the weirdness kicks in.
> >
> > unsigned HOST_WIDE_INT wi_offset = tree_to_uhwi (offset);
> >
> > tree_to_uhwi from tree.h is:
> >
> > extern inline __attribute__ ((__gnu_inline__)) unsigned HOST_WIDE_INT
> > tree_to_uhwi (const_tree t)
> > {
> > gcc_assert (tree_fits_uhwi_p (t));
> > return TREE_INT_CST_LOW (t);
> > }
> >
> > and
> >
> > tree_fits_uhwi_p from tree.c is
> >
> > bool
> > tree_fits_uhwi_p (const_tree t)
> > {
> > return (t != NULL_TREE
> > && TREE_CODE (t) == INTEGER_CST
> > && wi::fits_uhwi_p (wi::to_widest (t)));
> > }
> >
> > Here's what this instrumentation shows (DEBUG_A is an indenting fprintf to
> > stderr.)
> >
> > DEBUG_A ("TREE_CODE(offset) = %s && ", code_str (TREE_CODE (offset)));
> > DEBUG_A ("fits %s\n", wi::fits_uhwi_p (wi::to_widest (offset)) ? "true" :
> > "false");
> > DEBUG_A ("tree_fits_uhwi_p(offset) %s\n",tree_fits_uhwi_p (offset) ?
> > "true" : "false");
> >
> >TREE_CODE(offset) = INTEGER_CST && fits true
> >tree_fits_uhwi_p(offset) true
> >
> > By the way, offset is:
> >
> > _Literal (struct BASKET * *) 8
> >
> > And it's an operand of:
> >
> > MEM[(struct BASKET * *)&perm + 8B]
> >
> > Any clues on what's going on here?
>
> it should just work.
>
> > Thanks,
> >
> > Gary
> >
>
> Btw, try to setup things so you don't spam below stuff to public mailing
> lists.
>
> > 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: odd internal failure
On Thu, 2021-12-02 at 12:40 +0100, Richard Biener via Gcc wrote:
> On Wed, Dec 1, 2021 at 9:56 PM Gary Oblock
> wrote:
> >
> > Richard,
> >
> > I rebuilt at "-O0" and that particular call now works but on a call
> > to
> > the same function with a different offset it fails. 😱
>
> use a debugger to see why
In case you haven't seen them, I put together some tips on debugging
GCC here:
https://dmalcolm.fedorapeople.org/gcc/newbies-guide/debugging.html
https://github.com/davidmalcolm/gcc-newbies-guide/blob/master/debugging.rst
Inserting print statements only gets you so far; at some point you
really need a debugger.
Dave
>
> > Thanks,
> >
> > Gary
> >
> >
> >
> > From: Richard Biener
> > Sent: Wednesday, December 1, 2021 1:09 AM
> > To: Gary Oblock
> > Cc: gcc@gcc.gnu.org
> > Subject: Re: odd internal failure
> >
> > [EXTERNAL EMAIL NOTICE: This email originated from an external
> > sender. Please be mindful of safe email handling and proprietary
> > information protection practices.]
> >
> >
> > On Wed, Dec 1, 2021 at 8:46 AM Gary Oblock via Gcc
> > wrote:
> > >
> > > What is happening should be trivial to determine but for some
> > > reason it's
> > > not. I'd normally bounce this off a coworker but given the pandemic
> > > and modern dispersed hiring practices it's not even remotely
> > > possible.
> > >
> > > I'm making this call and tree_to_uhwi is failing on an internal
> > > error.
> > > That's normally easy to fix, but here is where the weirdness kicks
> > > in.
> > >
> > > unsigned HOST_WIDE_INT wi_offset = tree_to_uhwi (offset);
> > >
> > > tree_to_uhwi from tree.h is:
> > >
> > > extern inline __attribute__ ((__gnu_inline__)) unsigned
> > > HOST_WIDE_INT
> > > tree_to_uhwi (const_tree t)
> > > {
> > > gcc_assert (tree_fits_uhwi_p (t));
> > > return TREE_INT_CST_LOW (t);
> > > }
> > >
> > > and
> > >
> > > tree_fits_uhwi_p from tree.c is
> > >
> > > bool
> > > tree_fits_uhwi_p (const_tree t)
> > > {
> > > return (t != NULL_TREE
> > > && TREE_CODE (t) == INTEGER_CST
> > > && wi::fits_uhwi_p (wi::to_widest (t)));
> > > }
> > >
> > > Here's what this instrumentation shows (DEBUG_A is an indenting
> > > fprintf to
> > > stderr.)
> > >
> > > DEBUG_A ("TREE_CODE(offset) = %s && ", code_str (TREE_CODE
> > > (offset)));
> > > DEBUG_A ("fits %s\n", wi::fits_uhwi_p (wi::to_widest (offset)) ?
> > > "true" : "false");
> > > DEBUG_A ("tree_fits_uhwi_p(offset) %s\n",tree_fits_uhwi_p
> > > (offset) ? "true" : "false");
> > >
> > > TREE_CODE(offset) = INTEGER_CST && fits true
> > > tree_fits_uhwi_p(offset) true
> > >
> > > By the way, offset is:
> > >
> > > _Literal (struct BASKET * *) 8
> > >
> > > And it's an operand of:
> > >
> > > MEM[(struct BASKET * *)&perm + 8B]
> > >
> > > Any clues on what's going on here?
> >
> > it should just work.
> >
> > > Thanks,
> > >
> > > Gary
> > >
> >
> > Btw, try to setup things so you don't spam below stuff to public
> > mailing lists.
> >
> > > 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: ISO C3X proposal: nonnull qualifier
On 11/16/21 13:34, Alejandro Colomar (man-pages) wrote:
$ cat _Nonnull.c
#include
int *_Nonnull f(int *_Nullable p)
{
if (!p)
exit(1);
return p;
}
int *_Nonnull g(int *_Null_unspecified p)
{
return p;
}
int *_Nonnull h(int *p)
{
return p;
}
int *_Nullable i(int *_Nonnull p)
{
return p;
}
---
I see other problems:
- I don't get a warning from g(), nor from h(), which I'd want.
To get something like const-safety,
we need to design it so that it can be enforced;
either you guarantee that a pointer cannot be NULL (_Nonnull),
or you cannot guarantee it (not _Nonnull).
Otherwise,
[[gnu::nonnull]] would seem better to me.
So, I'd leave out of the design everything but _Nonnull,
and consider everything else as nullable by default.
Getting warnings from h() and g() would be easy to impose. Just forbid
implicit addition of _Nonnull qualifier.
- I get a warning from f().
Ideally,
a programmer should not need to cast
(casts are dangerous),
to convert a nullable pointer to a _nonnull pointer.
For that,
appropriate checks should be in the preceeding code.
Otherwise, a diagnostic should be issued.
To be on the safe side,
if a compiler has doubts,
it should diagnose.
There's some Clang document that talks about something similar.
I don't know its validity,
or if it was a draft before _Nonnull qualifiers.
I came with an idea that would make this QoI, so that the ISO standard
wouldn't need to force every compiler to be flow-sensitive, which would
be a bad precedent.
Implicit additions of the qualifier could be allowed to be warned
_always_ by the standard.
As an extension, quality compilers may not warn when they can see a NULL
check just before the assignment.
User code could make of the following macro, to avoid having to add
casts everywhere, which would be as bad as not having _Nonnull at all.
I got the idea from the GCC __builtin_xxx_overflow() builtins.
#if defined(__cplusplus)
#define const_cast(t, x) const_cast(x)
#else
#define const_cast(t, x) ((t) (x))
#endif
#if !defined(cplusplus)
#define auto __auto_type
#endif
#define nonnull_assign(nn, p) \
({\
auto p_ = p; \
auto nn_ = nn;\
\
if (p_ == NULL) \
*nn_ = const_cast(typeof(nn_), p_); \
\
p_ == NULL; \
})
And use it like this:
int *_Nonnull f(int *_Nullable p)
{
int *_Nonnull q;
if (nonnull_assign(&q, p))
exit(1);
return q;
}
That way there's only one place where there's a cast, so it can be
easily audited. The above would be warning-free, without requiring a
lot of complexity into the compiler.
Please, forgive the extensive use of GNU extensions in the above snippet
(and the redefinition of auto), as I forgive those who don't use them :)
So, now this can be made non-flow-sensitive, which was a big concern.
And now the biggest concern I can see is that this qualifier works
opposite to const (here discarding is allowed but not adding it), and
that is contrary to how compilers have been working for now. As far as
I could read in the standard, there's no mention to qualifiers being
dropped in an rvalue; Joseph, could you please confirm? Also, as I
already mentioned, Clang already implements this somehow without
discarding the _Nonnull qualifier, so I guess this can be done.
Cheers,
Alex
--
Alejandro Colomar
Linux man-pages comaintainer; http://www.kernel.org/doc/man-pages/
Re: ISO C3X proposal: nonnull qualifier
On 12/2/21 21:24, Alejandro Colomar (man-pages) wrote:
#define nonnull_assign(nn, p) \
({ \
auto p_ = p; \
auto nn_ = nn; \
\
if (p_ == NULL) \
*nn_ = const_cast(typeof(nn_), p_); \
D'oh, this check should be the opposite, of course :)
\
p_ == NULL; \
})
And I forgot to mention, that this macro intentionally leaves the
nonnull pointer (nn) uninitialized in the case of a NULL input pointer
(p), so that the compiler can then warn about an uninitialized variable
if it's used uninitialized.
Cheers,
Alex
--
Alejandro Colomar
Linux man-pages comaintainer; http://www.kernel.org/doc/man-pages/
Re: ISO C3X proposal: nonnull qualifier
On Thu, 2 Dec 2021, Alejandro Colomar (man-pages) via Gcc wrote: > So, now this can be made non-flow-sensitive, which was a big concern. And now > the biggest concern I can see is that this qualifier works opposite to const > (here discarding is allowed but not adding it), and that is contrary to how For all existing qualifiers, the rules about discarding are rules about permitted assignments (and conversions as if by assignment) between pointers and concern the qualifiers on pointer target types: 6.5.16.1 is the key subclause concerning implicit conversions, and any proposal for changes in that area needs to be precise about exactly what textual changes are proposed to 6.5.16.1. > compilers have been working for now. As far as I could read in the standard, > there's no mention to qualifiers being dropped in an rvalue; Joseph, could you > please confirm? Also, as I already mentioned, Clang already implements this lvalue-to-rvalue conversion drops qualifiers (and _Atomic). "If the lvalue has qualified type, the value has the unqualified version of the type of the lvalue; additionally, if the lvalue has atomic type, the value has the non-atomic version of the type of the lvalue; otherwise, the value has the type of the lvalue." (6.3.2.1). -- Joseph S. Myers jos...@codesourcery.com
gcc-9-20211202 is now available
Snapshot gcc-9-20211202 is now available on https://gcc.gnu.org/pub/gcc/snapshots/9-20211202/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 9 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-9 revision 1e41474603a88bbc2b715dc981f7ef5d3238bdb6 You'll find: gcc-9-20211202.tar.xzComplete GCC SHA256=0f91df803c7a2121c7cf34277cf95d051f9003262f3dcfe03204a73752ac75a1 SHA1=1fec08d021b01e4d9db7cf6bed1986a6b3bcd5be Diffs from 9-20211125 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-9 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.
Re: [power-ieee128] What should the math functions be annotated with?
On 01.12.21 21:54, Jakub Jelinek via Fortran wrote: Inside of libgfortran, I think it should depend on some macro defined in libgfortran.h. #if defined(__powerpc64__) && __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ \ && defined __GLIBC_PREREQ && __GLIBC_PREREQ (2, 32) then #define MATHFUNC(funcname) __ ## funcname ## ieee128 (i.e. use the functions that will be used when one uses e.g. sinl in C when compiled with -mabi=ieeelongdouble), but I'm not sure if those need to be declared by libgfortran or math.h declares them). Otherwise (when libgfortran is compiled against glibc older than 2.32) it should use #define MATHFUNC(funcname) funcname ## q i.e. use the libquadmath APIs). The current Ubuntu does not have these functions: ubuntu@gcc-fortran:/lib/powerpc64le-linux-gnu$ nm libm.a 2>/dev/null | grep ieee128 ubuntu@gcc-fortran:/lib/powerpc64le-linux-gnu$ Will they be supplied in the future, or with the advanced toolchain? Regards Thomas
