Re: odd internal failure
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.
[RISCV][CANCELED] RISC-V GNU Toolchain Biweekly Sync-up call (Dec 2, 2021)
Hi all, FYI The next RISC-V GNU Toolchain Biweekly Sync is cancelled because there were not too many new topics in the past weeks. The next meeting is scheduled for Dec 16, 2021. -- Best wishes, Wei Wu (吴伟)
Re: GNU OMPD implementation
Hi, On Tue, Nov 30 2021, Mohamed Atef wrote: > Hello, > for the gdb part it's already understood. gdb documentation explains > how to extend gdb functionality using python, and we looked at clang code > and now it's very clear how to provide OMPD functions with parameters. great to hear that. > > From OpenMP API specification 5.1 section 5.6 > "The OpenMP implementation must define several entry point symbols through > which execution > must pass when particular events occur and data collection for OMPD is > enabled. A tool can enable > notification of an event by setting a breakpoint at the address of the > entry point symbol." > > We need to add OMPD support to libgomp, and the debugger should be notified > that it has entered a new parallel region so we make dummy functions (or > labels) at every start and end of (parallel, task, thread) regions (note : > they should not be optimized). For a proof of concept phase you can make them functions with attributes used and noipa and we can figure out how to come up with a less terrible solution later. > > for the structures that we need to access in the runtime > for example here: > > https://github.com/gcc-mirror/gcc/blob/master/libgomp/icv.c#L38 > > if OMPD needs to get the max threads of the target program it literally > repeat the call so we use callbacks to get the address of struct > gomp_task_icv then we read its value the we get the value of nthreads_var > variable > for example : callbacks->lookup(icv)->access(nthreads_var) > > for now: > We finished the initialization phase and we're now working on how to test > the initialization of both the library and the target process. > We finished 5.5.1, 5.5.2, but for 5.5.4 i need to know the OpenMP version. When you are ready to share some git repo or something, please do so. > Where is the variable of the OpenMP version defined? I do not know if there even is one. The OpenMP implementation often has only partial implementation of features in the newer versions of the standard so coming up with one definitive version may be tricky. > > --- > > Current issues, > > to get the variable names from the target needs to move from the debugger > space to the target process space to lookup the values so we can use > something like (std::map) to save the values of the symbols that we got > before but we don't use C++. > Can we use C++ ? . If not, Can we implement it ourselves? Please don't use C++ for the runtime. libgomp has a header file for hash tables, but as you say... > Now we're thinking of leaving it as it's (access the target every time you > need to read or lookup.) and after finishing the project we can think of > something like caching the variables or any other way. ...this can be dealt with later. Unless it is not viable even for simple testcases, starting with linear searches and improving later is probably a better approach. > > OMPD will support CPUs for now. Is that okay? Yes, absolutely. > > > > for the macroziation part: > the lookup and read_memory callbacks should be provided with the sizes of > the variable they need to look for or read? > OMPD doesn't know the size of runtime data structures and can not access > the dwarf at the runtime. Well, there is the ompd_callback_sizeof_fn_t thing... but I admit I am not sure how exactly they envision it should be used, especially given things like padding in between structure fields. > so we need to do that manually: > #define OMPD_FOREACH_SIZEOF(OMPD_SIZEOF)\ > OMPD_SIZEOF(gomp_task_icv)\ > OMPD_SIZEOF(gomp_task)\ > OMPD_SIZEOF(gomp_team) > > #define OMPD_DECLARE_SIZEOF(t) __UINT64_TYPE__ ompd_sizeof__##t; > OMPD_FOREACH_SIZEOF(OMPD_DECLARE_SIZEOF) > #undef OMPD_DECLARE_SIZEOF > > we will generate these symbols as needed, so it's okay. Again, Jakub will eventually have to accept the approach but I do not see anything particularly wrong with it. I just wonder whether you'll need offsets of individual interesting fields as well. Anyway, thanks for the encouraging news and good luck, Martin
[power-ieee128] What should the math functions be annotated with?
I am currently working on implementing the IEEE 128-bit floating on POWER. One of the things to decide is what to call the math functions for the library calls. Example: libgfortran/generated/bessel_r16.c currently has #if defined(GFC_REAL_16_IS_FLOAT128) #define MATHFUNC(funcname) funcname ## q #else #define MATHFUNC(funcname) funcname ## l #endif (This is actually generated from an m4 file). For the BesselJ functions, for example, either the library functions jnq or jnl will be called. We have chosen *_r17.c and _c17.c as the naming conventions for library functions using IEEE 128-bit, and the files will be compiled with mabi=ieeelongdouble. So, what should the suffix for math functions be? I assume they will be picked up from some library. Somebody else than me will have to make sure this is done correctly, though :-) Regards Thomas So, what should the math functions be called so that they are actually found in the library?
Re: [power-ieee128] What should the math functions be annotated with?
On Wed, Dec 01, 2021 at 09:34:47PM +0100, Thomas Koenig via Gcc wrote: > I am currently working on implementing the IEEE 128-bit floating > on POWER. One of the things to decide is what to call the > math functions for the library calls. > > Example: libgfortran/generated/bessel_r16.c currently has > > #if defined(GFC_REAL_16_IS_FLOAT128) > #define MATHFUNC(funcname) funcname ## q > #else > #define MATHFUNC(funcname) funcname ## l > #endif > > (This is actually generated from an m4 file). > > For the BesselJ functions, for example, either the library functions jnq > or jnl will be called. I think it depends. 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). Now, when compiler itself actually emits calls like sinl etc. itself, IMHO it should use solely those __ ## funcname ## ieee128 functions, because that means either user uses explicit -mabi=ieeelongdouble and at that point he needs to make sure he has glibc 2.32 or later, or the compiler is configured to default to -mabi=ieeelongdouble and user doesn't use -mabi=ibmlongdouble (then presumably again user has to make sure glibc 2.32 or later is used). The reason to use libquadmath as fallback inside of libgfortran is so that one can build gcc against older glibc and keep the libgfortran ABI, and then use the compiler against newer glibc (or the older glibc assuming ibmlongdouble is used). Jakub
Re: odd internal failure
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. 😱
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: [cfe-dev] ISO C3X proposal: nonnull qualifier
Hi Dmitry, On 11/23/21 13:45, Dmitri Gribenko wrote: >> >> Let's imagine a scenario where C3X specifies that non-qualified pointers >> are nonnull. And there's only a qualifier, _Nullable, to allow NULL. >> Asigning _Nullable to nonnull would issue a diagnostic. > > I think C3X specifying that non-qualified pointers are nonnnull would > be a showstopper, I don't think it is likely to happen given how the > users and the committee value backward compatibility that C has > offered throughout the decades. Agreed. I even found some cases where it would cause previously-correct code to misbehave, so changing normal pointers to mean nonnull pointers is not possible at this point. Compilers may allow that with pragmas anyway. > > If I were to speculate what would happen if C3X did flip the default, > I think it would be treated by the community as a language fork. Yes > Pre-C3X headers won't work correctly when included in C3X programs, > making incremental adoption of C3X syntax, as it was intended to be > used, impossible. Projects would likely invent a NULLABLE macro, which > would expand to _Nullable in C3X and nothing in earlier versions, to > enable an incremental transition. > > That's why Clang introduced the pragma, enabling new rules to be > adopted incrementally. Let's avoid forking C :) > >> Also, do you have any experience in avoiding to diagnose a _Nullable to >> nonnull assignment _after_ explicitly comparing to NULL? I.e., allow >> the following: >> >> int *_Nullable p; >> int *q; >> >> if (!p) >> q = p; > > Internally at Google we have a checker based on the dataflow analysis > framework (https://lists.llvm.org/pipermail/cfe-dev/2021-October/069098.html) > that diagnoses usages of std::optional::value() not guarded by > has_value(). We are planning to upstream it after we finish > upstreaming the dataflow framework itself. Ensuring guarded usage of > std::optional::value() is very similar to diagnosing dereferences > of nullable pointers. I think a lot of the experience is transferable. > However, we haven't attempted to implement a pointer nullability check > yet, so I don't yet understand all corner cases that arise in real > world software. > > However, fundamentally, there are a few questions that you need to answer: > > - does _Nullable create a distinct type or not? It is extremely > important when you consider C++. Let's talk about _Nonnull, which is more likely to be added. I would say no. Neither const or restrict create a new type, but a qualified version of a type. _Nonnull has a behavior somewhat in between restrict and const. > > - do you want nullability-related diagnostics to be mandatory, or > optional? For example, a compiler is not required to issue a > diagnostic about a program that violates the constraints of > `restrict`. I think this should be similar to const, so a mandatory warning would be better. But still I have doubts, because this is much more complex to diagnose than const violations (there should be no diagnostic after an explicit NULL check). > > If _Nullable does not create a distinct type, and `T*` is the same > type as `T* _Nullable`, then we can't rely on the regular type system > mechanisms to issue diagnostics. > > If _Nullable creates a distinct type, then according to regular C type > checking rules, you would get a warning on the `q = p` assignment > regardless of the `if (!p)` check. That's how the C type system works, > it is not flow-sensitive. > > If we want the diagnostics to be fllow-sensitive like in your example > (I think it would be the best choice), then we need to add a new > flow-sensitive component to the C type system. I don't think there is > a precedent for this in C right now. I'm not sure how the committee or > implementors would react to such a proposal. Yes, it's complex. It should be flow-sensitive. Right now there's a precedent, I think: 'restrict'. But there are no mandatory warnings AFAIK. This would go one step further, and would probably be the most complex addition to the language ever. A minimal complying compiler would need to be much more complex than ever, which is a bad thing. Right now I have two voices in my head saying opposite things: on one hand this would add a lot of complexity to the C language, and I don't like that; on the other hand, this would make standard C much more safe than it is regarding pointers, and for the plain user, it would reduce the cognitive complexity of making sure null pointers are not passed where they shouldn't. GCC adding _Nonnull before the standard would be a good first step. Cheers, Alex
Re: [power-ieee128] What should the math functions be annotated with?
On Wed, Dec 01, 2021 at 09:54:50PM +0100, Jakub Jelinek wrote:
> 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).
To answer this myself, just tried on Fedora 34 and we'd need to
declare those ourselves.
Because math.h for -mabi=ibmlongdouble (which we want to compile
the libgfortran *.c files with so that REAL16 is long double as before)
only has prototypes like:
extern long double sinl (long double __x) __attribute__ ((__nothrow__ ,
__leaf__)); extern long double __sinl (long double __x) __attribute__
((__nothrow__ , __leaf__));
and with -mabi=ieeelongdouble it has:
extern long double sinl (long double __x) __asm__ ("" "__sinieee128")
__attribute__ ((__nothrow__ , __leaf__)); extern long double __sinl (long
double __x) __asm__ ("" "sinieee128") __attribute__ ((__nothrow__ ,
__leaf__));
but in neither case there is what we actually need for libgfortran,
which is
extern __float128 __sinieee128 (__float128) __attribute__ ((__nothrow__,
__leaf__));
Jakub
Re: [cfe-dev] ISO C3X proposal: nonnull qualifier
Hi Alejandro,
On Wed, Dec 1, 2021 at 11:24 PM Alejandro Colomar (man-pages)
wrote:
> On 11/23/21 13:45, Dmitri Gribenko wrote:
> > If I were to speculate what would happen if C3X did flip the default,
> > I think it would be treated by the community as a language fork.
>
> Yes
>
> > Pre-C3X headers won't work correctly when included in C3X programs,
> > making incremental adoption of C3X syntax, as it was intended to be
> > used, impossible. Projects would likely invent a NULLABLE macro, which
> > would expand to _Nullable in C3X and nothing in earlier versions, to
> > enable an incremental transition.
> >
> > That's why Clang introduced the pragma, enabling new rules to be
> > adopted incrementally.
>
> Let's avoid forking C :)
Do you consider the standard pragma `#pragma STDC FENV_ACCESS` to be a
language fork? If not, why is a pragma to control nullability of
pointers different?
Dmitri
--
main(i,j){for(i=2;;i++){for(j=2;j*/
Re: [cfe-dev] ISO C3X proposal: nonnull qualifier
Hi Dmitri On 12/2/21 01:39, Dmitri Gribenko wrote: Pre-C3X headers won't work correctly when included in C3X programs, making incremental adoption of C3X syntax, as it was intended to be used, impossible. Projects would likely invent a NULLABLE macro, which would expand to _Nullable in C3X and nothing in earlier versions, to enable an incremental transition. That's why Clang introduced the pragma, enabling new rules to be adopted incrementally. Let's avoid forking C :) Do you consider the standard pragma `#pragma STDC FENV_ACCESS` to be a language fork? If not, why is a pragma to control nullability of pointers different? Sorry, I put the reply at a wrong point in the quote. I didn't refer to the pragma, but the the previous paragraph. Basically, I meant let's not add _Nullable to C3X, and add just _Nonnull. Cheers, Alex
How to use bfloat16 type in GCC ?
Has GCC supported soft-fp for bfloat16 ? Thanks, — Jojo
