Re: [RFC] Summary of libgomp failures for offloading to nvptx from AArch64

[Richard Biener via Gcc]

On Thu, Jul 25, 2024 at 3:36 PM Prathamesh Kulkarni via Gcc
 wrote:
>
> Hi,
> I am working on enabling offloading to nvptx from AAarch64 host. As mentioned 
> on wiki (https://gcc.gnu.org/wiki/Offloading#Running_.27make_check.27),
> I ran make check-target-libgomp on AAarch64 host (and no GPU) with following 
> results:
>
> === libgomp Summary ===
>
> # of expected passes14568
> # of unexpected failures1023
> # of expected failures  309
> # of untested testcases 54
> # of unresolved testcases   992
> # of unsupported tests  644
>
> It seems majority of the tests fail due to the following 4 issues:
>
> * Compiling a minimal test-case:
>
> int main()
> {
>   int x;
>   #pragma omp target map (to: x)
>   {
> x = 0;
>   }
>   return x;
> }
>
> Compiling with -fopenmp -foffload=nvptx-none results in following issues:
>
> (1) Differing values of NUM_POLY_INT_COEFFS between host and accelerator, 
> which results in following ICE:
>
> 0x1a6e0a7 pp_quoted_string
> ../../gcc/gcc/pretty-print.cc:2277
>  0x1a6ffb3 pp_format(pretty_printer*, text_info*, urlifier const*)
> ../../gcc/gcc/pretty-print.cc:1634
>  0x1a4a3f3 diagnostic_context::report_diagnostic(diagnostic_info*)
> ../../gcc/gcc/diagnostic.cc:1612
>  0x1a4a727 diagnostic_impl
> ../../gcc/gcc/diagnostic.cc:1775
>  0x1a4e20b fatal_error(unsigned int, char const*, ...)
> ../../gcc/gcc/diagnostic.cc:2218
>  0xb3088f lto_input_mode_table(lto_file_decl_data*)
>  ../../gcc/gcc/lto-streamer-in.cc:2121
>  0x6f5cdf lto_file_finalize
> ../../gcc/gcc/lto/lto-common.cc:2285
>  0x6f5cdf lto_create_files_from_ids
> ../../gcc/gcc/lto/lto-common.cc:2309
>  0x6f5cdf lto_file_read
> ../../gcc/gcc/lto/lto-common.cc:2364
>  0x6f5cdf read_cgraph_and_symbols(unsigned int, char const**)
> ../../gcc/gcc/lto/lto-common.cc:2812
>  0x6cfb93 lto_main()
> ../../gcc/gcc/lto/lto.cc:658
>
> This is already tracked in https://gcc.gnu.org/PR96265 (and related PR's)
>
> Streaming out mode_table:
> mode = SI, mclass = 2, size = 4, prec = 32
> mode = DI, mclass = 2, size = 8, prec = 64
>
> Streaming in mode_table (in lto_input_mode_table):
> mclass = 2, size = 4, prec = 0
> (and then calculates the correct mode value by iterating over all modes of 
> mclass starting from narrowest mode)
>
> The issue is that the value for prec is not getting streamed-in correctly for 
> SImode as seen above. While streaming out from AArch64 host,
> it is 32, but while streaming in for nvptx, it is 0. This happens because of 
> differing values of NUM_POLY_INT_COEFFS between AArch64 and nvptx backend.
>
> Since NUM_POLY_INT_COEFFS is 2 for aarch64, the streamed-out values for mode, 
> precision would be <4, 0> and <32, 0>
> respectively (streamed-out in bp_pack_poly_value). Both zeros come from 
> coeffs[1] of size and prec. While streaming in however,
> NUM_POLY_INT_COEFFS is 1 for nvptx, and thus it incorrectly treats <4, 0> as 
> size and precision respectively, which is why precision
> gets streamed in as 0, and thus it encounters the above ICE.
>
> Supporting non VLA code with offloading:
>
> In the general case, it's hard to support offloading for arbitrary poly_ints 
> when NUM_POLY_INT_COEFFS differs for host and accelerator.
> For example, it's not possible to represent a degree-2 poly_int like 4 + 4x 
> (as-is) on an accelerator with NUM_POLY_INT_COEFFS == 1.
>
> However, IIUC, we can support offloading for restricted set of poly_ints 
> whose degree <= accel's NUM_POLY_INT_COEFFS, since they can be
> represented on accelerator ? For a hypothetical example, if host 
> NUM_POLY_INT_COEFFS == 3 and accel NUM_POLY_INT_COEFFS == 2, then I suppose
> we could represent a degree 2 poly_int on accelerator, but not a degree 3 
> poly_int like 3+4x+5x^2 ?
>
> Based on that, I have come up with following approach in attached 
> "quick-and-dirty" patch (p-163-2.diff):
> Stream-out host NUM_POLY_INT_COEFFS, and while streaming-in during lto1, 
> compare it with accelerator's NUM_POLY_INT_COEFFS as follows:
>
> Stream in host_num_poly_int_coeffs;
> if (host_num_poly_int_coeffs == NUM_POLY_INT_COEFFS) // NUM_POLY_INT_COEFFS 
> represents accelerator's value here.
> {
> /* Both are equal, proceed to unpacking NUM_POLY_INT_COEFFS words from 
> bitstream.  */
> }
> else if (host_num_poly_int_coeffs < NUM_POLY_INT_COEFFS)
> {
> /* Unpack host_num_poly_int_coeffs words and zero out remaining higher 
> coeffs (similar to zero-extension).  */
> }
> else
> {
> /* Unpack host_num_poly_int_coeffs words and ensure that degree of 
> streamed-out poly_int <= NUM_POLY_INT_COEFFS.  */
> }
>
> For example, with host NUM_POLY_INT_COEFFS == 2 and accel NUM_POLY_INT_COEFFS 
> == 1, this will allow streaming of "degree-1" poly_ints
> like 4+0x (which will degenerate to constant 4), but give an error for 
> streaming degree-2 poly_int like 4+4x.
>
> Following this approach,

Webnar on Intermediate Payroll for the Administrative Professional

[Triomasters via Gcc]

http://click.campaign.triomasters.com/?qs=5a121056e622108f021623cff235bd781402d61a7bdecc7506511887a0c23b17f597f8171a17528e4896a1f5edf2f294167df33135028bed
 


 Intermediate Payroll for the Administrative Professional
 

 Wednesday, August 07, 2024 | EST: 12:30 PM | PST: 09:30 AM
 

Introduction

 Government agencies, including the Department of Labor and IRS, are increasing 
their enforcement and audits. Administrative professionals are often the ones 
who are tasked with completing payroll, keeping records, ensuring compliance, 
and responding to government investigations. This webinar is intended to assist 
administrative professionals to help ensure compliance with payroll laws and be 
prepared in the event of a government review. Paying employees is one of the 
most important parts of doing business. Employees work to be paid so making 
sure they are paid timely and correctly is crucial to your business. 
 

http://click.campaign.triomasters.com/?qs=5a121056e622108f021623cff235bd781402d61a7bdecc7506511887a0c23b17f597f8171a17528e4896a1f5edf2f294167df33135028bed
 
Book Your Seat!
  

LEARNING OBJECTIVES
- You will learn what forms are needed to process employees pay
- You will learn how to calculate your employee’s pay
- Understanding of how/where to pay employee and employer taxes and 
your responsibilities
- Better knowledge of Deadlines and awareness of Fines and penalties 
that can be assessed


 Speaker: Debbie Cash, CPP
 
http://click.campaign.triomasters.com/?qs=5a121056e622108f021623cff235bd781402d61a7bdecc7506511887a0c23b17f597f8171a17528e4896a1f5edf2f294167df33135028bed
 


 Debbie Cash, CPP is a Manager of TLM Implementation at G&A Partners. G&A 
Partners is a Professional Employer Organization (PEO) that offers payroll, 
human resources, benefits management, risk management, and accounting services 
for businesses. G&A Partners acquired Employer Advantage LLC (PEO) in February 
2022. Debbie began working for the organization in 2006 as a Payroll Tax 
Specialist and Time and Attendance Specialist. She was promoted to Time/Labor 
Manager in 2021. 
 

http://click.campaign.triomasters.com/?qs=5a121056e622108f021623cff235bd781402d61a7bdecc7506511887a0c23b17f597f8171a17528e4896a1f5edf2f294167df33135028bed
 
Register Now
  


 Questions? Contact +1-855-202-3299 or
 mailto:supp...@triomasters.com
 

 This email was sent by: triomasters.com, 309 Coffeen Avenue
 Street 1200,Sheridan Wyoming - 82801 
If you no longer wish to
 receive emails from us, please
 
http://click.campaign.triomasters.com/unsub_center.aspx?qs=266763b1ce4964b6a964f0cd636a6f5f8b8b47bd7013b29ed51ef382283f97054c794cf65ae5dc6d092540ff9af3e24b197d7e4534b56360aad49131f874ff2d98f33029930dfe32
 
 Unsubscribe  

Re: n3294 - The restrict function attribute as a replacement of the restrict qualifier

[Joseph Myers via Gcc]

On Wed, 10 Jul 2024, Alejandro Colomar via Gcc wrote:

>6.7.13.x The restrict function attribute
>  Constraints
> The restrict attribute shall be applied to a function.
> 
> A 1‐based index can be specified in an  attribute  argument
> clause,  to  associate the attribute with the corresponding
> parameter of the function, which must be of a pointer type.

It's more appropriate to say "shall", and you need a requirement for the 
pointer to be a pointer to a complete object type (it makes no sense with 
function pointers, or void).  That is, something like "If an attribute 
argument clause is present, it shall have the form:

  ( constant-expression )

The constant expression shall be an integer constant expression with 
positive value.  It shall be the index, counting starting from 1, of a 
function parameter whose type is a pointer to a complete object type.".

(That might not quite be sufficient - there are the usual questions of 
exactly *when* the type needs to be complete, if it's completed part way 
through the function definition, but the standard already doesn't tend to 
specify such things very precisely.)

> (Optional.)   The argument attribute clause may be omitted,
> which is equivalent to specifying the  attribute  once  for
> each parameter that is a pointer.

For each parameter that is a pointer to a complete object type, or should 
there be a constraint violation in this case if some are pointers to such 
types and some are pointers to other types?

> If the number of elements is specified with array  notation
> (or  a compiler‐specific attribute), the array object to be
> considered for aliasing is a sub‐object of the original ar‐
> ray object, limited by the number  of  elements  specifiedr
> [1].

This is semantically problematic in the absence of something like N2906 
(different declarations could use different numbers of elements), and even 
N2906 wouldn't help for the VLA case.

>  [1]  For the following prototype:
> 
>  [[restrict(1)]] [[restrict(2)]]
>  void f(size_t n, int a[n], const int b[n]);

That declaration currently means

  void f(size_t n, int a[*], const int b[*]);

(that is, the expression giving a VLA size is ignored).  It's equivalent 
to e.g.

  void f(size_t n, int a[n + foo()], const int b[n + bar()]);

where because the size expressions are never evaluated and there's no time 
defined for evaluation, it's far from clear what anything talking about 
them giving an array size would even mean.


I know that "noalias" was included in some C89 drafts but removed from the 
final standard after objections.  Maybe someone who was around then could 
explain what "noalias" was, what the problems with it were and how it 
differs from "restrict", so we can make sure that any new proposals in 
this area don't suffer from whatever the perceived deficiencies of 
"noalias" were?

-- 
Joseph S. Myers
josmy...@redhat.com

Re: n3294 - The restrict function attribute as a replacement of the restrict qualifier

[G. Branden Robinson via Gcc]

At 2024-07-26T16:24:14+, Joseph Myers wrote:
> I know that "noalias" was included in some C89 drafts but removed from
> the final standard after objections.  Maybe someone who was around
> then could explain what "noalias" was, what the problems with it were

For this part, I think the source most often cited is Dennis Ritchie's
thunderbolt aimed directly at "noalias".

https://www.lysator.liu.se/c/dmr-on-noalias.html

> and how it differs from "restrict",

I can only disqualify myself as an authority here.

> To comprehensively address this demands so we can make sure that any
> new proposals in this area don't suffer from whatever the perceived
> deficiencies of "noalias" were?

I think it would be valuable to get such a discussion into the rationale
of the next C standard.

Regards,
Branden


signature.asc
Description: PGP signature

Re: n3294 - The restrict function attribute as a replacement of the restrict qualifier

[Paul Eggert]

On 7/26/24 09:24, Joseph Myers wrote:

  Maybe someone who was around then could
explain what "noalias" was, what the problems with it were and how it
differs from "restrict"


You can get a hint by reading Dennis Ritchie's 1988 email with the 
unforgettable bottom line "Noalias must go. This is non-negotiable."


https://www.lysator.liu.se/c/dmr-on-noalias.html

... and this is partly why I haven't read Alejandro's proposal. Fiddling 
with 'restrict' should be done only very carefully and only if there are 
really important advantages to messing around with it.

Re: n3294 - The restrict function attribute as a replacement of the restrict qualifier

[Alejandro Colomar via Gcc]

Hi Branden!

On Fri, Jul 26, 2024 at 11:35:51AM GMT, G. Branden Robinson wrote:
> At 2024-07-26T16:24:14+, Joseph Myers wrote:
> > I know that "noalias" was included in some C89 drafts but removed from
> > the final standard after objections.  Maybe someone who was around
> > then could explain what "noalias" was, what the problems with it were
> 
> For this part, I think the source most often cited is Dennis Ritchie's
> thunderbolt aimed directly at "noalias".
> 
> https://www.lysator.liu.se/c/dmr-on-noalias.html

Thanks!  It seems Dennis's concern was that it was a qualifier.
Probably the reason why restrict ended up being a qualifier on the
pointer (and thus easily ignored), instead of the pointee (it would have
caused the problems that Dennis mentioned and which anyone can guess).

Since I'm suggesting an attribute, we are pretty much safe from type
rules, and thus safe from Dennis's concerns, I think.

Have a lovely night!
Alex

> 
> > and how it differs from "restrict",
> 
> I can only disqualify myself as an authority here.
> 
> > To comprehensively address this demands so we can make sure that any
> > new proposals in this area don't suffer from whatever the perceived
> > deficiencies of "noalias" were?
> 
> I think it would be valuable to get such a discussion into the rationale
> of the next C standard.
> 
> Regards,
> Branden

-- 



signature.asc
Description: PGP signature

Re: n3294 - The restrict function attribute as a replacement of the restrict qualifier

[Alejandro Colomar via Gcc]

Hi Joseph,

On Fri, Jul 26, 2024 at 04:24:14PM GMT, Joseph Myers wrote:
> On Wed, 10 Jul 2024, Alejandro Colomar via Gcc wrote:
> 
> >6.7.13.x The restrict function attribute
> >  Constraints
> > The restrict attribute shall be applied to a function.
> > 
> > A 1‐based index can be specified in an  attribute  argument
> > clause,  to  associate the attribute with the corresponding
> > parameter of the function, which must be of a pointer type.
> 
> It's more appropriate to say "shall", and you need a requirement for the 
> pointer to be a pointer to a complete object type (it makes no sense with 
> function pointers, or void).

I don't see why it should not apply to void*.  memcpy(3) should get this
attribute:

[[alx::restrict(1)]]
[[alx::restrict(2)]]
void *memcpy(void *dst, const void *src, size_t n);

The index to which the text above refers is that '(1)' and '(2)'.

>  That is, something like "If an attribute 
> argument clause is present, it shall have the form:
> 
>   ( constant-expression )
> 
> The constant expression shall be an integer constant expression with 
> positive value.  It shall be the index, counting starting from 1, of a 
> function parameter whose type is a pointer to a complete object type.".
> 
> (That might not quite be sufficient - there are the usual questions of 
> exactly *when* the type needs to be complete, if it's completed part way 
> through the function definition, but the standard already doesn't tend to 
> specify such things very precisely.)
> 
> > (Optional.)   The argument attribute clause may be omitted,
> > which is equivalent to specifying the  attribute  once  for
> > each parameter that is a pointer.
> 
> For each parameter that is a pointer to a complete object type, or should 
> there be a constraint violation in this case if some are pointers to such 
> types and some are pointers to other types?
> 
> > If the number of elements is specified with array  notation
> > (or  a compiler‐specific attribute), the array object to be
> > considered for aliasing is a sub‐object of the original ar‐
> > ray object, limited by the number  of  elements  specifiedr
> > [1].
> 
> This is semantically problematic in the absence of something like N2906 
> (different declarations could use different numbers of elements),

Agree.  I think arrays should be fixed in C.  n2906 is a good step
towards that.  Thanks Martin!  :)

BTW, the author of n2529 didn't follow up, right?  I'd like that in, so
I'll prepare something after n2906 is merged.  Martin, would you mind
pinging me about it?

For what this [[alx::restrict]] proposal is concerned, I'd wait after
n2906 is merged for proposing that extension.

> and even 
> N2906 wouldn't help for the VLA case.

I'd basically propose that [3] or [n] means the same as [static 3] and
[static n], except for the nonnull implications of static.  Is there any
such paper?  I'm interested in presenting one for that.

Maybe it would also be interesting to wait after n2906 for that too.

> >  [1]  For the following prototype:
> > 
> >  [[restrict(1)]] [[restrict(2)]]
> >  void f(size_t n, int a[n], const int b[n]);
> 
> That declaration currently means
> 
>   void f(size_t n, int a[*], const int b[*]);

Yeah, that should be fixed in the standard.

I'll keep that extension of restrict out of a proposal until array
parameters are fixed in that regard.

> (that is, the expression giving a VLA size is ignored).  It's equivalent 
> to e.g.
> 
>   void f(size_t n, int a[n + foo()], const int b[n + bar()]);
> 
> where because the size expressions are never evaluated and there's no time 
> defined for evaluation, it's far from clear what anything talking about 
> them giving an array size would even mean.

Yup.

> I know that "noalias" was included in some C89 drafts but removed from the 
> final standard after objections.  Maybe someone who was around then could 
> explain what "noalias" was, what the problems with it were and how it 
> differs from "restrict", so we can make sure that any new proposals in 
> this area don't suffer from whatever the perceived deficiencies of 
> "noalias" were?

As I said in reply to Branden's response, it seems Dennis's concern was
that the noalias proposal was a qualifier, which admittedly makes little
sense (very much like the problems restrict has, but applied to the
pointee, which makes them much worse).

That in fact led me recently to think that an _Optional qualifier
(similar to Clang's _Nullable) as is being proposed at the moment in
n3222 is similarly DOA.  Those qualities of pointers are attributes,
which cannot be specified in the type system.

Have a lovely night!
Alex


> 
> -- 
> Joseph S. Myers
> josmy...@redhat.com


-- 



signature.asc
Description: PGP signature

Re: n3294 - The restrict function attribute as a replacement of the restrict qualifier

[Joseph Myers via Gcc]

On Fri, 26 Jul 2024, Alejandro Colomar via Gcc wrote:

> I don't see why it should not apply to void*.  memcpy(3) should get this
> attribute:
> 
>   [[alx::restrict(1)]]
>   [[alx::restrict(2)]]
>   void *memcpy(void *dst, const void *src, size_t n);

That would disallow copying between disjoint subarrays within the same 
toplevel object (and there's no way to specify an array size for void *), 
which hardly seems right.

> BTW, the author of n2529 didn't follow up, right?  I'd like that in, so
> I'll prepare something after n2906 is merged.  Martin, would you mind
> pinging me about it?

See reflector message SC22WG14.18575, 17 Nov 2020 (the former convenor 
replying when I asked about just that paper).  As far as I know the author 
has not yet provided an updated version / asked for it to be added to a 
meeting agenda.

-- 
Joseph S. Myers
josmy...@redhat.com

Re: n3294 - The restrict function attribute as a replacement of the restrict qualifier

[Alejandro Colomar via Gcc]

Hi Joseph,

On Fri, Jul 26, 2024 at 08:30:33PM GMT, Joseph Myers wrote:
> On Fri, 26 Jul 2024, Alejandro Colomar via Gcc wrote:
> 
> > I don't see why it should not apply to void*.  memcpy(3) should get this
> > attribute:
> > 
> > [[alx::restrict(1)]]
> > [[alx::restrict(2)]]
> > void *memcpy(void *dst, const void *src, size_t n);
> 
> That would disallow copying between disjoint subarrays within the same 
> toplevel object (and there's no way to specify an array size for void *), 
> which hardly seems right.

Hmmm, I sometimes forget that ISO C is so painful about void.

Has WG14 discussed in the past about the GNU extension that defines
sizeof(void) == 1?

Maybe wording that also considers compiler-specific attributes and
extensions would allow for the following:

[[gnu::access(write_only, 1, 3)]]
[[gnu::access(read_only, 2, 3)]]
[[alx::restrict(1)]]
[[alx::restrict(2)]]
void *memcpy(void *dst, const void *src, size_t n);

The GNU attribute specifies the number of elements of the subarrays, and
the GNU extension sizeof(void)==1 specifies the size of each element.
That gives us the size of the subarrays to be considered for the
restrictness.

So, ISO C wouldn't be allowed to mark malloc(3) as [[alx::restrict]]
(unless they add these GNU extensions), but GNU C could.

> > BTW, the author of n2529 didn't follow up, right?  I'd like that in, so
> > I'll prepare something after n2906 is merged.  Martin, would you mind
> > pinging me about it?
> 
> See reflector message SC22WG14.18575, 17 Nov 2020 (the former convenor 
> replying when I asked about just that paper).

Where can I find reflector messages?

>  As far as I know the author 
> has not yet provided an updated version / asked for it to be added to a 
> meeting agenda.

I think you mentioned that to me some time ago.  I guess I'll take over
then.  I'll ask for a number to propose _Nitems().

And another one to propose that [n] means the same as [static n] except
for the nonnull property of static.

Have a lovely night!
Alex

> 
> -- 
> Joseph S. Myers
> josmy...@redhat.com
> 
> 

-- 



signature.asc
Description: PGP signature

Re: n3294 - The restrict function attribute as a replacement of the restrict qualifier

[Joseph Myers via Gcc]

On Fri, 26 Jul 2024, Alejandro Colomar via Gcc wrote:

> > See reflector message SC22WG14.18575, 17 Nov 2020 (the former convenor 
> > replying when I asked about just that paper).
> 
> Where can I find reflector messages?

https://www.open-std.org/jtc1/sc22/wg14/18575

> And another one to propose that [n] means the same as [static n] except
> for the nonnull property of static.

I'm not convinced that introducing extra undefined behavior for things 
that have been valid since C89 (which would be the effect of such a change 
for any code that passes a smaller array) is a good idea - the general 
mood is to *reduce* undefined behavior.

-- 
Joseph S. Myers
josmy...@redhat.com

Re: n3294 - The restrict function attribute as a replacement of the restrict qualifier

[Alejandro Colomar via Gcc]

On Fri, Jul 26, 2024 at 09:22:42PM GMT, Joseph Myers wrote:
> On Fri, 26 Jul 2024, Alejandro Colomar via Gcc wrote:
> 
> > > See reflector message SC22WG14.18575, 17 Nov 2020 (the former convenor 
> > > replying when I asked about just that paper).
> > 
> > Where can I find reflector messages?
> 
> https://www.open-std.org/jtc1/sc22/wg14/18575

Thanks!

> 
> > And another one to propose that [n] means the same as [static n] except
> > for the nonnull property of static.
> 
> I'm not convinced that introducing extra undefined behavior for things 
> that have been valid since C89 (which would be the effect of such a change 
> for any code that passes a smaller array) is a good idea - the general 
> mood is to *reduce* undefined behavior.

While [n] has always _officially_ meant the same as [], it has never
made any sense to write code like that.  Unofficially, it has always
meant the obvious thing.

Maybe if GNU C compilers (GCC and Clang) add it first as an extension,
adding diagnostics, it would help.

Does anyone know of any existing code that uses [n] for meaning anything
other than "n elements are available to the function"?

Functions that specify [n] most likely (definitely?) already mean that
n elements are accessed, and thus passing something different than n
elements results in UB one way or another.  Having the compiler enforce
that via diagnostics and UB is probably an improvement.

Cheers,
Alex

> 
> -- 
> Joseph S. Myers
> josmy...@redhat.com
> 

-- 



signature.asc
Description: PGP signature

Re: n3294 - The restrict function attribute as a replacement of the restrict qualifier

[Martin Uecker via Gcc]

Am Freitag, dem 26.07.2024 um 23:49 +0200 schrieb Alejandro Colomar via Gcc:
> On Fri, Jul 26, 2024 at 09:22:42PM GMT, Joseph Myers wrote:
> > On Fri, 26 Jul 2024, Alejandro Colomar via Gcc wrote:
> > 
> > > > See reflector message SC22WG14.18575, 17 Nov 2020 (the former convenor 
> > > > replying when I asked about just that paper).
> > > 
> > > Where can I find reflector messages?
> > 
> > https://www.open-std.org/jtc1/sc22/wg14/18575
> 
> Thanks!
> 
> > 
> > > And another one to propose that [n] means the same as [static n] except
> > > for the nonnull property of static.
> > 
> > I'm not convinced that introducing extra undefined behavior for things 
> > that have been valid since C89 (which would be the effect of such a change 
> > for any code that passes a smaller array) is a good idea - the general 
> > mood is to *reduce* undefined behavior.
> 
> While [n] has always _officially_ meant the same as [], it has never
> made any sense to write code like that.  Unofficially, it has always
> meant the obvious thing.
> 
> Maybe if GNU C compilers (GCC and Clang) add it first as an extension,
> adding diagnostics, it would help.

Both GCC and Clang already have such diagnostics and/or run-time checks:

https://godbolt.org/z/MPnxqb9h7

Martin


> 
> Does anyone know of any existing code that uses [n] for meaning anything
> other than "n elements are available to the function"?
> 
> Functions that specify [n] most likely (definitely?) already mean that
> n elements are accessed, and thus passing something different than n
> elements results in UB one way or another.  Having the compiler enforce
> that via diagnostics and UB is probably an improvement.
> 
> Cheers,
> Alex
> 
> > 
> > -- 
> > Joseph S. Myers
> > josmy...@redhat.com
> > 
> 

Re: n3294 - The restrict function attribute as a replacement of the restrict qualifier

[Alejandro Colomar via Gcc]

On Sat, Jul 27, 2024 at 12:03:20AM GMT, Martin Uecker wrote:
> > Maybe if GNU C compilers (GCC and Clang) add it first as an extension,
> > adding diagnostics, it would help.
> 
> Both GCC and Clang already have such diagnostics and/or run-time checks:
> 
> https://godbolt.org/z/MPnxqb9h7

Hi Martin,

I guess that's prior art enough to make this UB in ISO C.  Is there any
paper for this already?  Does any of your paper cover that?  Should I
prepare one?

Have a lovely night!
Alex

-- 



signature.asc
Description: PGP signature

gcc-13-20240726 is now available

[GCC Administrator via Gcc]

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

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

You'll find:

 gcc-13-20240726.tar.xz   Complete GCC

  SHA256=b8dc2eaa37bde2e5abb7d7239a79d08e8e8de64c33ab3b10fc7a0755b74aff85
  SHA1=f19a52c10745a92412cc6d9787189d48e6f009c5

Diffs from 13-20240719 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-13
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: n3294 - The restrict function attribute as a replacement of the restrict qualifier

[Martin Uecker via Gcc]

Am Samstag, dem 27.07.2024 um 00:26 +0200 schrieb Alejandro Colomar:
> On Sat, Jul 27, 2024 at 12:03:20AM GMT, Martin Uecker wrote:
> > > Maybe if GNU C compilers (GCC and Clang) add it first as an extension,
> > > adding diagnostics, it would help.
> > 
> > Both GCC and Clang already have such diagnostics and/or run-time checks:
> > 
> > https://godbolt.org/z/MPnxqb9h7
> 
> Hi Martin,
> 
> I guess that's prior art enough to make this UB in ISO C.  Is there any
> paper for this already?  Does any of your paper cover that?  Should I
> prepare one?
> 

What do you mean by "this"?  Adding UB would likely see a lot
of opposition, even where this could enable run-time checks.  

N2906 would make 

int foo(char f[4]);
int foo(char f[5]);

a constraint violation (although having those types be incompatible
could also cause UB indirectly, this would not be its main effect).

So I think brining a new version of this paper forward would be
a possible next step, addressing the issues raised in the past.

Martin