Re: C23 status on cppreference

[Florian Weimer]

* Joseph Myers:

> On Wed, 16 Oct 2024, Florian Weimer wrote:
>
>> * Jakub Jelinek via Gcc:
>> 
>> > Are some of the papers/features known to be fully implemented (since which
>> > version)?  E.g. for __VA_OPT__ I remember doing (and Jason too) various 
>> > fixes
>> > in the past few years, like PR89971, PR103415, PR101488.  Not really sure
>> > what exactly C23 requires.
>> 
>> Can we add a warning if bool is defined to anything that isn't _Bool
>> (either as a macro or as a type)?  If we are serious about switching
>> to C23 by default, I think that warning needs to be enabled by
>> default, due to the ABI impact.
>
> In -std=gnu23 mode, defining bool as a typedef will result in an error 
> anyway.  (Defining a macro with any of the names alignas, alignof, bool, 
> false, static_assert, thread_local, true is undefined behavior in C23, so 
> it's certainly OK to diagnose defining such a macro, even as a pedwarn / 
> error, if we wish.)
>
> I'm not sure such a warning particularly helps, however; any ABI 
> incompatibility occurs at the point where someone changes their code to 
> stop defining bool and to use the standard bool instead.  (And any problem 
> code would already have been ABI-incompatible with C++.)

The warning might encourage developers to plan for the transition and
think about the ABI impact.  I think we should try to bring across the
message that this isn't just about fixing build failures.

> Several of the tests I added -std=gnu17 to had their own definitions of 
> bool as an enum with values false and true, but I think that comes from 
> reduction of preprocessed source from GCC 2.95 (which had such a 
> definition, arising from older C9X drafts, in its ) rather than 
> being something likely to occur in user code.  I expect "typedef char 
> bool;" (or "#define bool char"), and similar with unsigned char, to be 
> much more common in applications.

Even the char definition is not fully ABI-compatible with _Bool and
can introduce undefined behavior on a switch to _Bool if not
everything is recompiled.

How to remove extra assembly code

[Ericxu833--- via Gcc]

gcc version 14.2.0 (Rev1, Built by MSYS2 project)

//test.c
#include 
int main() {

getchar();
return0;}

gcc.exe -g -O0 -x c -fno-exceptions -fno-stack-protector -fno-ident test.c -o 
test.exe

I used IDA pro to reverse engineer test.exe and found that gcc added "call 
__main" to the front of the assembly code, and then executed "jmp 
__do_global_ctors". I guess this code means to instantiate C++ objects.
My code is pure C language and does not need this code. How to remove the extra 
assembly code.

TNX.

Re: How to remove extra assembly code

[Nick Clifton via Gcc]

Hi Ericxu833,


gcc.exe -g -O0 -x c -fno-exceptions -fno-stack-protector -fno-ident test.c -o 
test.exe

I used IDA pro to reverse engineer test.exe and found that gcc added "call __main" to the 
front of the assembly code, and then executed "jmp __do_global_ctors". I guess this code 
means to instantiate C++ objects.
My code is pure C language and does not need this code. How to remove the extra 
assembly code.


Try adding -nostartfiles to your command line.

That extra code is coming from the startup file(s) that are added by
default when you use gcc to compile and then link your program.

Of course without those startup files you may not be able to run
your code, but I assume that that does not matter to you.

Cheers
  Nick

Re: How to remove extra assembly code

[LIU Hao via Gcc]

在 2024-10-17 16:07, Ericxu833--- via Gcc 写道:

I used IDA pro to reverse engineer test.exe and found that gcc added "call __main" to the 
front of the assembly code, and then executed "jmp __do_global_ctors". I guess this code 
means to instantiate C++ objects.


Yes, mostly.


My code is pure C language and does not need this code. How to remove the extra 
assembly code.


The solution is to define `WinMain()` (or `wWinMain()` with the `-municode` option), where GCC will 
not insert `__main()`.


Note the call still exists, before your main function is called.



--
Best regards,
LIU Hao


OpenPGP_signature.asc
Description: OpenPGP digital signature

gcc14.2 gprbuild not provided

[Berger, Lutz via Gcc]

Airbus Amber
Hallo,
The command "gnatmake -P" cannot be executed anymore, because 
gprbuild (gnatmake is forwarded to gprbuild in that case) is not provided. Is 
there a restriction, or why it is not provided?

Regards

Lutz Berger
Modeling and Testing System Engineer
Integrated Team PSTS - TADVSD
Airbus Defense and Space

T   +49 8 45 98 17 94 43
F   +49 8 45 98 16 69 92
E   lutz.ber...@airbus.com

Airbus Defense and Space GmbH
Rechliner Straße
D-85077 Manching
Deutschland

Airbus Defence and Space GmbH
Chairman of the Supervisory Board: Dominik Asam
Managing Directors: Dr. Michael Schoellhorn (Chairman), Marcella Hoffmann, 
Andrea Willmeroth, Harald Mannheim
Registered Office: Ottobrunn
District Court of Munich, HRB 107 648
Ust. Ident. Nr./VAT reg. no. DE167015661
This Item has been reviewed and was determined as not listed under German 
regulation, nor EU export controls, nor U.S. export controls. However, in the 
case of the item has to be resold, transferred, or otherwise disposed of to an 
embargoed country, to an end user of concern or in support of a prohibited end 
use, you may be required to obtain an export license.



THIS DOCUMENT IS NOT SUBJECT TO EXPORT CONTROL.

The information in this e-mail is confidential. The contents may not be 
disclosed or used by anyone other than the addressee. Access to this e-mail by 
anyone else is unauthorised.
If you are not the intended recipient, please notify Airbus immediately and 
delete this e-mail.
Airbus cannot accept any responsibility for the accuracy or completeness of 
this e-mail as it has been sent over public networks. If you have any concerns 
over the content of this message or its Accuracy or Integrity, please contact 
Airbus immediately.
All outgoing e-mails from Airbus are checked using regularly updated virus 
scanning software but you should take whatever measures you deem to be 
appropriate to ensure that this message and any attachments are virus free.

Re: Is -Wtraditional obsolete?

[Richard Biener via Gcc]

On Wed, Oct 16, 2024 at 7:14 PM Joseph Myers via Gcc  wrote:
>
> One issue that showed up as test failures with a default of -std=gnu23 is
> that -std=gnu23 -Wtraditional produces a "traditional C rejects ISO C
> style function definitions" warning for function definitions with empty
> parentheses, as they are treated like (void) in C23, so resulting in
> failure of several -Wtraditional tests.
>
> Clearly that's a bug (that warning should only be given for literal
> (void), not for () meaning (void)) and wouldn't be hard to fix.  But is
> there actually any current use for the -Wtraditional option?  It seems
> extremely unlikely now that compatibility with pre-C89 compilers would be
> relevant.  So maybe it would make more sense to remove -Wtraditional
> support (remove all the logic implementing the option, make it an option
> marked with Ignore in c.opt to do nothing so as not to break any build
> systems that hardcode this option) rather than fixing this bug with an
> option that's probably no longer useful.

I wonder if we should diagnose(?) and/or ignore -Wtraditional when
-std={c,gnu}89
isn't in effect.  It doesn't make much sense to allow and not diagnose
c99+ features
but complain about oddball compatibility issues with pre-ISO C.

Richard.

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

Re: How to remove extra assembly code"

[LIU Hao via Gcc]

在 2024-10-17 17:13, ericxu...@protonmail.com 写道:

Using your method, I replaced "int main()" with "int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance, 
LPSTR lpCmdLine, int nShowCmd)", and the result was more assembly code added than the previous version. After reverse 
engineering, I found that the result compiled with Visual Studio was very similar, with added "_tmainCRTStartup", 
"_InterlockedCompareExchange64", "_main()" and other codes. I guess these codes are used to process the 
parameter information of the running program.


The code is always there [1] even you don't use those parameters. You may pass `-nostartfiles` to 
GCC, but then be careful:


1. There shall be an entry-point function, which can be named arbitrarily,
   but it must return `int` and take no argument.
2. The symbolic name to this function shall be passed to GCC with
   `-Wl,--entry,ENTRYPOINT` when linking.
3. For x86-32, ESP is not aligned properly, and the function should be
   declared `__attribute__((__force_align_arg_pointer__))`.
4. For x86-32 and x86-64, the x87 FPU is initialized to 53-bit precision.
   If `long double` is used, `__asm__ ("fninit");` is required.
5. Auto-import [2] may be unusable, and there may be undefined references
   to `_pei386_runtime_relocator`. It is sometimes necessary to add
   `__declspec(dllimport)` accordingly.


[1] 
https://github.com/mingw-w64/mingw-w64/blob/cdf6b16b805ce7d02f6b1b742911ba0770b49bbb/mingw-w64-crt/crt/crtexe.c#L203-L267

[2] https://sourceware.org/binutils/docs/ld/WIN32.html

--
Best regards,
LIU Hao


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [RFC] Return Value Propagation in IPA-CP

[Dhruv Chawla via Gcc]

Hi,

Thanks for the reply!

On 16/10/24 20:25, Martin Jambor wrote:

External email: Use caution opening links or attachments


Hello,

first and foremost, sorry for a late reply.  I needed to take a larger
leave of absence for family reasons.

Comments inline:

On Thu, Aug 22 2024, Dhruv Chawla via Gcc wrote:

* Table Of Contents *

- Introduction
- Motivating Test Cases
- Proposed Solution
- Other Options
- Existing Solutions
- Primary Optimizations To Be Improved
- Front-End Attribute For Recording Return-Value Information
- Future Work
- References
- Questions

* Introduction *

Return jump functions offer a way of modeling return values of a function in
terms of its formal parameters, similar to how regular jump functions can be
used to model the actual parameters of a callee at a callsite in terms of the
formal parameters of the caller.

By discovering this information and propagating it across the program callgraph
in LTO mode, various transformations like value-range propagation, sibling-call
and chaining-call optimization can be augmented to take advantage of it and
potentially perform better optimizations.

Currently, ipa-cp models parameters using jump functions, propagates the values
of those jump functions by iterating to a fixed-point using lattices, and
clones functions by taking decisions from those lattice values.

We propose extending ipa-cp with the analysis and propagation of return jump
functions, starting with the basic case of a direct return of the form
"return x;" where "x" is any formal parameter of the function.

* Motivating Test Cases *

* Optimizing tail calls:

- PR92867

char buf[128] = { 1 };

char *foo (__SIZE_TYPE__ n)
{
return __builtin_memset (buf, ' ', n);
}

char *bar (__SIZE_TYPE__ n)
{
__builtin_memset (buf, ' ', n);
return buf;
}

Here, the call to __builtin_memset in foo gets successfully converted to a
tail-call, however the call in bar cannot be optimized to a tail-call. This is
an optimization that LLVM is able to perform.

Link to compiler explorer: https://godbolt.org/z/E81axqWTb

- PR67797

#include 

void *my_func(void *s, size_t n)
{
  memset(s, 0, n);
  return s;
}

This is a similar case to the above example. LLVM is able to optimize the call
to memset to be a tail-call as well.

Link to compiler explorer: https://godbolt.org/z/YzjGc59f8

* Optimizing chaining calls:

#include 

void f (int x, int y)
{
std::cout << x;
std::cout << y;
}

This function can be optimized to the following:

#include 

void f (int x, int y)
{
std::cout << x << y;
}

LLVM is able to perform this optimization as well:
https://godbolt.org/z/MW75on1o5

* Proposed Solution *

* Extending IPA-CP:

1. Add return jump function data structures
- This involves updating ipa_node_params to contain information regarding 
the
  return statements of the function, namely the lattice and the jump 
function
  describing the return value, where both use existing data structures.
- The ipa_node_params class is reused to avoid introducing a new class and a
  corresponding function_summary type, though it is trivial to add if deemed
  a better solution. The ipa_return_value_summary class may also be a good
  place for this information, however using it would involve moving it from
  ipa-prop.cc to ipa-prop.h.


I believe that ipa_return_value_summary should become a member of
ipa_node_params (perhaps we could think of a better name) and
ipa_return_value_sum should be removed.  All infrastructure there is to
create ipa_return_value_summary should be re-used or extended to fulfill
also the new needs.


As per the reply at https://gcc.gnu.org/pipermail/gcc/2024-
September/244856.html, we ended up splitting this out into a new structure.
Having both tree and IPA passes accessing the same structure made memory
management hard.





- Additionally, ipa_edge_args is updated to track whether or not it is a
  callgraph edge originating from a return statement. This enables the
  propagation of information in the WPA phase.


I don't understand.  I have read your reply to Honza to his question
about this and I still don't understand what you mean by this.

I believe we want to have a return function for each call graph edge,
certainly for each one that calls a non-void function.


Yeah, I believe that could have been phrased better. It just means that we track
whether or not an SSA_NAME created as a result of a gcall is used in the retval
of a return statement, either directly or through a PHI node. This is achieved
by tracking this information in ipa_edge_args (as there is one instance of this
structure for each cgraph_edge), so each gcall will have an ipa_edge_args
instance associated with it.

The return jump function is stored per-node, not per-edge. The per-edge tracking
is only done to enable propagation of the "returns_arg" attribute from callee to
caller in WPA, to potentially annotate callers with the attribute. This shows 

Re: C23 status on cppreference

[Joseph Myers via Gcc]

On Thu, 17 Oct 2024, Florian Weimer wrote:

> > I'm not sure such a warning particularly helps, however; any ABI 
> > incompatibility occurs at the point where someone changes their code to 
> > stop defining bool and to use the standard bool instead.  (And any problem 
> > code would already have been ABI-incompatible with C++.)
> 
> The warning might encourage developers to plan for the transition and
> think about the ABI impact.  I think we should try to bring across the
> message that this isn't just about fixing build failures.

Certainly there should be porting instructions much like those in 
gcc-14/porting_to.html (and those could discuss ABI considerations around 
changing bool definitions where a library is involved, in more detail than 
could go in a warning).  And it's possible that mass builds with 
comparison of configure test results would help detect any cases where 
those get perturbed by a change to -std=gnu23 as default, similar to the 
previous C modernization changes.

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

RE: [RFC] Enabling SVE with offloading to nvptx

[Richard Biener via Gcc]

On Thu, 17 Oct 2024, Prathamesh Kulkarni wrote:

> > -Original Message-
> > From: Richard Biener 
> > Sent: 16 October 2024 13:05
> > To: Prathamesh Kulkarni 
> > Cc: gcc@gcc.gnu.org; Thomas Schwinge 
> > Subject: Re: [RFC] Enabling SVE with offloading to nvptx
> > 
> > External email: Use caution opening links or attachments
> > 
> > 
> > On Tue, 15 Oct 2024, Prathamesh Kulkarni wrote:
> > 
> > > Hi,
> > > Testing libgomp with SVE enabled (-mcpu=generic+sve2), results in ~60
> > UNRESOLVED errors with following error message:
> > >
> > > lto1: fatal error: degree of 'poly_int' exceeds 'NUM_POLY_INT_COEFFS'
> > > compilation terminated.
> > > nvptx mkoffload: fatal error:
> > > ../../install/bin/aarch64-unknown-linux-gnu-accel-nvptx-none-gcc
> > returned 1 exit status compilation terminated.
> > >
> > > This behaviour can be reproduced with the following simple test-case
> > with -fopenmp -foffload=nvptx-none -mcpu=generic+sve2:
> > >
> > > #define N 1000
> > > int main ()
> > > {
> > >   int i;
> > >   int A[N] = {0}, B[N] = {0};
> > >
> > >   #pragma omp target map(i), map(tofrom: A), map(from: B)
> > >   #pragma omp simd
> > >   for (i = 0; i < N; i++)
> > > A[i] = A[i] + B[i];
> > >   return A[0];
> > > }
> > >
> > > omplower pass lowers the above loop to the following:
> > >
> > > D.4576 = .GOMP_USE_SIMT ();
> > > if (D.4576 != 0) goto ; else goto ;
> > > :
> > > {
> > >   unsigned int D.4586;
> > >   unsigned int D.4587;
> > >   int D.4588;
> > >   void * simduid.5;
> > >   void * .omp_simt.6;
> > >   int D.4596;
> > >   _Bool D.4597;
> > >   int D.4598;
> > >   unsigned int D.4599;
> > >   int D.4600;
> > >   int D.4601;
> > >   int * D.4602;
> > >   int i [value-expr: D.4588];
> > >   int i.0;
> > >
> > >   simduid.5 = .GOMP_SIMT_ENTER (simduid.5, &D.4588);
> > >   .omp_simt.6 = .GOMP_SIMT_ENTER_ALLOC (simduid.5);
> > >   D.4587 = 0;
> > >   i.0 = 0;
> > >   #pragma omp simd safelen(32) _simduid_(simduid.5)
> > _simt_ linear(i.0:1) linear(i:1)
> > >   for (i.0 = 0; i.0 < 1000; i.0 = i.0 + 1)
> > >   ...
> > > }
> > > goto ;
> > > :
> > > {
> > >   unsigned int D.4603;
> > >   unsigned int D.4604;
> > >   int D.4605[0:POLY_INT_CST [15, 16]];
> > >   void * simduid.7;
> > >   unsigned int D.4612;
> > >   int * D.4613;
> > >   int D.4614;
> > >   int i [value-expr: D.4605[D.4604]];
> > >   int i.0;
> > >
> > >   D.4604 = 0;
> > >   i.0 = 0;
> > >   #pragma omp simd safelen(POLY_INT_CST [16, 16])
> > _simduid_(simduid.7) linear(i.0:1) linear(i:1)
> > >   ...
> > >  }
> > >  :
> > >  ...
> > >
> > > For offloading to SIMT based device like nvptx, scan_omp_simd
> > > duplicates lowering of simd pragma into if-else where the if-part
> > > contains simt code-path, and else-part contains simd code-path. In
> > lower_rec_simd_input_clauses, max_vf is set to 16+16x for the above case
> > as determined by omp_max_vf, and that becomes length of the omp simd
> > array:
> > > int D.4605[0:POLY_INT_CST [15, 16]];
> > >
> > > The issue here is that, the function containing above if-else
> > > condition gets streamed out to LTO bytecode including the simd code-
> > path and the omp simd array, whose domain is [0:POLY_INT_CST[15, 16]],
> > and thus we get the above error while streaming-in POLY_INT_CST in
> > lto_input_ts_poly_tree_pointers on device side.
> > >
> > > Note that, the simd code-path is essentially dead-code on nvptx, since
> > > .GOMP_USE_SIMT() resolves to 1 during omp_device_lower pass, and later
> > > optimization passes (ccp2) remove the dead-code path and unused omp
> > simd arrays while compiling to device. So in this case, we aren't really
> > mapping POLY_INT_CST from host to device, but it gets streamed out to
> > device as an artefact of omp simd lowering.
> > >
> > > I suppose a proper fix here would be to (somehow) defer lowering of
> > > omp pragma simd after streaming out to device, so the device only sees
> > > simt code-path, and the host only sees simd code path ? Or perhaps
> > clone each function in offload region, one for host and one for SIMT
> > device, and only stream the device versions to avoid streaming out host-
> > specific IR changes ?
> > 
> > There is currently no way to have the host compiler query offload target
> > capabilities so the only true fix is

Re: gcc14.2 gprbuild not provided

[Marc Poulhiès via Gcc]

"Berger, Lutz via Gcc"  writes:

> Airbus Amber
> Hallo,
> The command "gnatmake -P" cannot be executed anymore,
> because gprbuild (gnatmake is forwarded to gprbuild in that case) is
> not provided. Is there a restriction, or why it is not provided?

Hello,

it's not new that `gnatmake -P` redirects to `gprbuild` (I think it has
been so since ~2016), and `gprbuild` has never been a part of GCC. So I
don't think the "cannot be executed anymore" is caused by a recent
change in GCC.

gprbuild can probably be installed using your distribution package
manager as it's included in most repositories now. You can also build
and install it yourself from the sources:
https://github.com/AdaCore/gprbuild.

And finally, you may be interested by using alire
(https://github.com/alire-project/alire) as it makes it really easy to
install the compiler and its companion tools.

Regards,
Marc Poulhiès

> Regards
>
> Lutz Berger
> Modeling and Testing System Engineer
> Integrated Team PSTS - TADVSD
> Airbus Defense and Space

Re: Is -Wtraditional obsolete?

[Joseph Myers via Gcc]

On Wed, 16 Oct 2024, Eric Gallager via Gcc wrote:

> > "suggest hiding %<#%s%> from traditional C with an indented %<#%>"
> 
> This is one of the things I tested when adding gcc.dg/pragma-diag-7.c
> in r8-787-g4287da829c9697:
> https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=4287da829c9697c58131666447bf8f707bd8b635

That tests have been added / updated is not evidence that the feature is 
useful.

> > "traditional C rejects the %<%.*s%> suffix"
> 
> Some coding style guidelines dislike suffixed constants; for example,
> see this passage from GCC's own README.Portability:
> 
> Suffixes on Integer Constants
> -
> 
> You should never use a 'l' suffix on integer constants ('L' is fine),
> since it can easily be confused with the number '1'.

The relevant comment on this is

  /* Traditional C only accepted the 'L' suffix.
 Suppress warning about 'LL' with -Wno-long-long.  */

and it doesn't warn about 'l' or 'L' (just 'u' or 'U') for integers.  It 
does warn about 'l' for floating point, but it also warns about 'L' there, 
so it definitely is not a warning for this particular confusion issue.

> > "function-like macro %qs must be used with arguments in traditional C"
> 
> This one just makes sense as a style guideline to me, and it would be
> good if GCC's own fix-it hint system paid attention to it, as per bug
> 81419: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81419

If someone is actually confused and expects the macro to be expanded, 
they'll get an error anyway from not having the macro expanded.  It seems 
unlikely to me that cases such as in the testsuite

#define f(X) X
int f;   // { dg-warning "function-like macro 'f' must be used with 
arguments in traditional C .-Wtraditional." }

reflect what real code is likely to do (valid without the macro expansion 
but still want a warning).  After all, C has multiple namespaces of 
identifiers within the language itself; this doesn't seem any more 
relevant to me than the other -Wtraditional warning about labels 
conflicting with variables of the same name.

> > "macro argument %qs would be stringified in traditional C"
> 
> This one I added a test for in gcc.dg/pragma-diag-7.c due to having
> seen it in real code; see r8-4796-g34b81eb96cd1df:
> https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=34b81eb96cd1df28d7f878bc1f3df607746507da

That doesn't look like real code that is confused about how macro 
expansion works.  It seems to be about the failure of #pragma GCC 
diagnostic ignored "-Wtraditional" to disable a -Wtraditional warning.  
Which says nothing about why anyone was using -Wtraditional in the first 
place, but it would seem rather unlikely for binutils-gdb code from the 
past 20 years to actually have any use for compatibility with pre-C89 
compilers.

And this warning about string contents seems exactly the kind of thing 
that can only possibly be of use if someone really does want to build code 
with a pre-C89 compiler; it makes no sense whatever otherwise to have a 
coding style rule about macro parameter names not appearing inside string 
literals.

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

RE: [RFC] Enabling SVE with offloading to nvptx

[Prathamesh Kulkarni via Gcc]

> -Original Message-
> From: Richard Biener 
> Sent: 16 October 2024 13:05
> To: Prathamesh Kulkarni 
> Cc: gcc@gcc.gnu.org; Thomas Schwinge 
> Subject: Re: [RFC] Enabling SVE with offloading to nvptx
> 
> External email: Use caution opening links or attachments
> 
> 
> On Tue, 15 Oct 2024, Prathamesh Kulkarni wrote:
> 
> > Hi,
> > Testing libgomp with SVE enabled (-mcpu=generic+sve2), results in ~60
> UNRESOLVED errors with following error message:
> >
> > lto1: fatal error: degree of 'poly_int' exceeds 'NUM_POLY_INT_COEFFS'
> > compilation terminated.
> > nvptx mkoffload: fatal error:
> > ../../install/bin/aarch64-unknown-linux-gnu-accel-nvptx-none-gcc
> returned 1 exit status compilation terminated.
> >
> > This behaviour can be reproduced with the following simple test-case
> with -fopenmp -foffload=nvptx-none -mcpu=generic+sve2:
> >
> > #define N 1000
> > int main ()
> > {
> >   int i;
> >   int A[N] = {0}, B[N] = {0};
> >
> >   #pragma omp target map(i), map(tofrom: A), map(from: B)
> >   #pragma omp simd
> >   for (i = 0; i < N; i++)
> > A[i] = A[i] + B[i];
> >   return A[0];
> > }
> >
> > omplower pass lowers the above loop to the following:
> >
> > D.4576 = .GOMP_USE_SIMT ();
> > if (D.4576 != 0) goto ; else goto ;
> > :
> > {
> >   unsigned int D.4586;
> >   unsigned int D.4587;
> >   int D.4588;
> >   void * simduid.5;
> >   void * .omp_simt.6;
> >   int D.4596;
> >   _Bool D.4597;
> >   int D.4598;
> >   unsigned int D.4599;
> >   int D.4600;
> >   int D.4601;
> >   int * D.4602;
> >   int i [value-expr: D.4588];
> >   int i.0;
> >
> >   simduid.5 = .GOMP_SIMT_ENTER (simduid.5, &D.4588);
> >   .omp_simt.6 = .GOMP_SIMT_ENTER_ALLOC (simduid.5);
> >   D.4587 = 0;
> >   i.0 = 0;
> >   #pragma omp simd safelen(32) _simduid_(simduid.5)
> _simt_ linear(i.0:1) linear(i:1)
> >   for (i.0 = 0; i.0 < 1000; i.0 = i.0 + 1)
> >   ...
> > }
> > goto ;
> > :
> > {
> >   unsigned int D.4603;
> >   unsigned int D.4604;
> >   int D.4605[0:POLY_INT_CST [15, 16]];
> >   void * simduid.7;
> >   unsigned int D.4612;
> >   int * D.4613;
> >   int D.4614;
> >   int i [value-expr: D.4605[D.4604]];
> >   int i.0;
> >
> >   D.4604 = 0;
> >   i.0 = 0;
> >   #pragma omp simd safelen(POLY_INT_CST [16, 16])
> _simduid_(simduid.7) linear(i.0:1) linear(i:1)
> >   ...
> >  }
> >  :
> >  ...
> >
> > For offloading to SIMT based device like nvptx, scan_omp_simd
> > duplicates lowering of simd pragma into if-else where the if-part
> > contains simt code-path, and else-part contains simd code-path. In
> lower_rec_simd_input_clauses, max_vf is set to 16+16x for the above case
> as determined by omp_max_vf, and that becomes length of the omp simd
> array:
> > int D.4605[0:POLY_INT_CST [15, 16]];
> >
> > The issue here is that, the function containing above if-else
> > condition gets streamed out to LTO bytecode including the simd code-
> path and the omp simd array, whose domain is [0:POLY_INT_CST[15, 16]],
> and thus we get the above error while streaming-in POLY_INT_CST in
> lto_input_ts_poly_tree_pointers on device side.
> >
> > Note that, the simd code-path is essentially dead-code on nvptx, since
> > .GOMP_USE_SIMT() resolves to 1 during omp_device_lower pass, and later
> > optimization passes (ccp2) remove the dead-code path and unused omp
> simd arrays while compiling to device. So in this case, we aren't really
> mapping POLY_INT_CST from host to device, but it gets streamed out to
> device as an artefact of omp simd lowering.
> >
> > I suppose a proper fix here would be to (somehow) defer lowering of
> > omp pragma simd after streaming out to device, so the device only sees
> > simt code-path, and the host only sees simd code path ? Or perhaps
> clone each function in offload region, one for host and one for SIMT
> device, and only stream the device versions to avoid streaming out host-
> specific IR changes ?
> 
> There is currently no way to have the host compiler query offload target
> capabilities so the only true fix is to delay OMP SIMD lowering to the
> target.
Um, I thought we could use omp_max_simt_vf from host to query if the offload 
target is SIMT ?
The function essentially iterates thru OFFLOAD_TARGET_NAMES and returns 
non-zero for nvptx.
> 
> Are we dependent on the early optimization pipeline

Alex Coplan appointed maintainer of AArch64 pair fusion pass and pair-fusion pass.

[Ramana Radhakrishnan via Gcc]

I am pleased to announce that the GCC Steering Committee has appointed
Alex Coplan as a maintainer for the AArch64 load / store pair fusion
pass.

In addition the steering committee has also appointed him as
maintainer for the Pair Fusion pass in the target independent
portions.

Please join me in congratulating Alex on his new roles. Alex , please
update your listing in the MAINTAINERS file.

Regards
Ramana

Re: BUG: realloc(p,0) is not conforming to C99/C11/C17/POSIX.1-2008

[Douglas McIlroy via Gcc]

 Pedantically, I should say valid, not unique.

More pedantically, it should be distinct from any other pointer
returned by malloc or realloc and not freed or realloced since.

Doug

On Thu, Oct 17, 2024 at 12:09 PM Alejandro Colomar  wrote:
>
> CC += JeanHeyd
>
> On Thu, Oct 17, 2024 at 05:25:55PM GMT, Alejandro Colomar wrote:
> > On Thu, Oct 17, 2024 at 05:19:07PM GMT, Alejandro Colomar wrote:
> > > CC += Robert, Joseph, gcc@
> > >
> > > On Thu, Oct 17, 2024 at 04:30:27PM GMT, Alejandro Colomar wrote:
> > > > On Thu, Oct 17, 2024 at 04:23:29PM GMT, Alejandro Colomar wrote:
> > > > > CC += Doug, as the author of the original malloc(3).
> > > > >
> > > > > On Thu, Oct 17, 2024 at 04:21:22PM GMT, Alejandro Colomar wrote:
> > > > > > Hi!
> > > > > >
> > > > > > наб and I have been researching about malloc(0) and realloc(p,0), 
> > > > > > and
> > > > > > have written our findings here:
> > > > > >
> > > > > > 
> > > > > > 
> > > > > >
> > > > > > -  Every default malloc(0) had always returned a unique pointer.
> > > > > > -  Every realloc(,0) had always behaved congruently with malloc(0).
> > > > > > -  The weird malloc(0)=NULL was a bug in SysV r2's optimized 
> > > > > > alternative
> > > > > >-lmalloc library.  The documentation still didn't allow returning
> > > > > >NULL.
> > > > > > -  SVID surprisingly documented that bug in -lmalloc as if it were 
> > > > > > the
> > > > > >only good behavior, making every default malloc(0) 
> > > > > > non-conforming.
> > > > > >This was a huge mistake/crime.  So far so good for realloc(,0).
> > > > > >
> > > > > > -  X3J11 (ANSI C) decided that realloc(p,0) shall be equivalent to
> > > > > >free(p) (allegedly, in line with their self-inflicted policy of 
> > > > > > not
> > > > > >allowing zero-size objects, which BTW was never true, since 
> > > > > > malloc(0)
> > > > > >and realloc(NULL,0) continued to support zero-size objects).  
> > > > > > This
> > > > > >was a hallucination of ANSI C.  No implementations had done this.
> > > > > >Ever.  No documentation or standards document had specified this.
> > > > > >Ever.
> > > > > > -  POSIX.1-2001 (Issue 6) blindly followed C89, making every POSIX
> > > > > >system non-conforming.
> > > > > >
> > > > > > -  C99 and POSIX.1-2008 fixed the issue, by reverting to the 
> > > > > > historical
> > > > > >realloc(p,0) behavior of being congruent to malloc(0).
> > > > > >
> > > > > > -  glibc, in 2006/2007, made a so-called bugfix change to conform to
> > > > > >C89, which effectively made realloc(p,0) non-conforming to C99.  
> > > > > > This
> > > > > >happened in the following commit:
> > > > > >
> > > > > >   commit 11bf311edc76f5ddc469a8c396e313e82d76be15
> > > > > >   Author: Ulrich Drepper 
> > > > > >   Date:   Thu Jan 11 21:51:07 2007 +
> > > > > >
> > > > > >   [BZ #2510, BZ #2830, BZ #3137, BZ #3313, BZ #3426, BZ 
> > > > > > #3465, BZ #3480, BZ #3483, BZ #
> > > > > >   3493, BZ #3514, BZ #3515, BZ #3664, BZ #3673, BZ #3674]
> > > > > >
> > > > > >   [...]
> > > > > >
> > > > > >   2006-12-08  Ulrich Drepper  
> > > > > >   * malloc/memusage.c: Handle realloc with new size 
> > > > > > of zero and
> > > > > >   non-NULL pointer correctly.
> > > > > >
> > > > > >   [...]
> > > > > >
> > > > > > Please revert that commit, and make realloc(p,0) conform to C99, 
> > > > > > C11,
> > > > > > C17, and POSIX.1-2008.  This is the historical right behavior of
> > > > > > realloc(p,0), and what the BSDs do.
> > > >
> > > > I realized that I didn't clarify what the bug is.  realloc(p,0) should
> > > > return a unique pointer, just like malloc(0) does.  Returning NULL is
> >
> > Pedantically, I should say valid, not unique.  Returning the old pointer
> > would be a valid implementation.
> >
> > > > brain-damaged.
> > > >
> > > > > >
> > > > > > That so-called bugfix probably silently broke algorithms for which 
> > > > > > 0 is
> > > > > > not a special case.
> > > > > >
> > > > > > C23 will break realloc(p,0) even further, but let's ignore that 
> > > > > > mistake.
> > > > > >
> > > > > >
> > > > > > Have a lovely day!
> > > > > > Alex
> > > > > >
> > > > > >
> > > > > > --
> > > > > > 
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > 
> > > >
> > > >
> > > >
> > > > --
> > > > 
> > >
> > >
> > >
> > > --
> > > 
> >
> >
> >
> > --
> > 
>
>
>
> --
> 

Re: BUG: realloc(p,0) is not conforming to C99/C11/C17/POSIX.1-2008

[Alejandro Colomar via Gcc]

CC += JeanHeyd

On Thu, Oct 17, 2024 at 05:25:55PM GMT, Alejandro Colomar wrote:
> On Thu, Oct 17, 2024 at 05:19:07PM GMT, Alejandro Colomar wrote:
> > CC += Robert, Joseph, gcc@
> > 
> > On Thu, Oct 17, 2024 at 04:30:27PM GMT, Alejandro Colomar wrote:
> > > On Thu, Oct 17, 2024 at 04:23:29PM GMT, Alejandro Colomar wrote:
> > > > CC += Doug, as the author of the original malloc(3).
> > > > 
> > > > On Thu, Oct 17, 2024 at 04:21:22PM GMT, Alejandro Colomar wrote:
> > > > > Hi!
> > > > > 
> > > > > наб and I have been researching about malloc(0) and realloc(p,0), and
> > > > > have written our findings here:
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > -  Every default malloc(0) had always returned a unique pointer.
> > > > > -  Every realloc(,0) had always behaved congruently with malloc(0).
> > > > > -  The weird malloc(0)=NULL was a bug in SysV r2's optimized 
> > > > > alternative
> > > > >-lmalloc library.  The documentation still didn't allow returning
> > > > >NULL.
> > > > > -  SVID surprisingly documented that bug in -lmalloc as if it were the
> > > > >only good behavior, making every default malloc(0) non-conforming.
> > > > >This was a huge mistake/crime.  So far so good for realloc(,0).
> > > > > 
> > > > > -  X3J11 (ANSI C) decided that realloc(p,0) shall be equivalent to
> > > > >free(p) (allegedly, in line with their self-inflicted policy of not
> > > > >allowing zero-size objects, which BTW was never true, since 
> > > > > malloc(0)
> > > > >and realloc(NULL,0) continued to support zero-size objects).  This
> > > > >was a hallucination of ANSI C.  No implementations had done this.
> > > > >Ever.  No documentation or standards document had specified this.
> > > > >Ever.
> > > > > -  POSIX.1-2001 (Issue 6) blindly followed C89, making every POSIX
> > > > >system non-conforming.
> > > > > 
> > > > > -  C99 and POSIX.1-2008 fixed the issue, by reverting to the 
> > > > > historical
> > > > >realloc(p,0) behavior of being congruent to malloc(0).
> > > > > 
> > > > > -  glibc, in 2006/2007, made a so-called bugfix change to conform to
> > > > >C89, which effectively made realloc(p,0) non-conforming to C99.  
> > > > > This
> > > > >happened in the following commit:
> > > > > 
> > > > >   commit 11bf311edc76f5ddc469a8c396e313e82d76be15
> > > > >   Author: Ulrich Drepper 
> > > > >   Date:   Thu Jan 11 21:51:07 2007 +
> > > > > 
> > > > >   [BZ #2510, BZ #2830, BZ #3137, BZ #3313, BZ #3426, BZ 
> > > > > #3465, BZ #3480, BZ #3483, BZ #
> > > > >   3493, BZ #3514, BZ #3515, BZ #3664, BZ #3673, BZ #3674]
> > > > > 
> > > > >   [...]
> > > > > 
> > > > >   2006-12-08  Ulrich Drepper  
> > > > >   * malloc/memusage.c: Handle realloc with new size 
> > > > > of zero and
> > > > >   non-NULL pointer correctly.
> > > > > 
> > > > >   [...]
> > > > > 
> > > > > Please revert that commit, and make realloc(p,0) conform to C99, C11,
> > > > > C17, and POSIX.1-2008.  This is the historical right behavior of
> > > > > realloc(p,0), and what the BSDs do.
> > > 
> > > I realized that I didn't clarify what the bug is.  realloc(p,0) should
> > > return a unique pointer, just like malloc(0) does.  Returning NULL is
> 
> Pedantically, I should say valid, not unique.  Returning the old pointer
> would be a valid implementation.
> 
> > > brain-damaged.
> > > 
> > > > > 
> > > > > That so-called bugfix probably silently broke algorithms for which 0 
> > > > > is
> > > > > not a special case.
> > > > > 
> > > > > C23 will break realloc(p,0) even further, but let's ignore that 
> > > > > mistake.
> > > > > 
> > > > > 
> > > > > Have a lovely day!
> > > > > Alex
> > > > > 
> > > > > 
> > > > > -- 
> > > > > 
> > > > 
> > > > 
> > > > 
> > > > -- 
> > > > 
> > > 
> > > 
> > > 
> > > -- 
> > > 
> > 
> > 
> > 
> > -- 
> > 
> 
> 
> 
> -- 
> 



-- 



signature.asc
Description: PGP signature

[RFC][AArch64] Defining lrotm3 optabs for SVE modes for TARGET_SVE2?

[Kyrylo Tkachov via Gcc]

Hello,

I’ve been optimizing various code sequences relating to vector rotates recently.
I ended up proposing we expand the vector-rotate-by-immediate optab rotlm3 for
the Advanced SIMD (Neon) modes here:
https://gcc.gnu.org/pipermail/gcc-patches/2024-October/665635.html
This expands to a ROTATE RTL code that can be later combined into more complex
instructions like XAR and for certain rotate amounts can be optimized in a 
single instruction.
If they fail to be optimized then a splitter breaks it down into an SHL + USRA 
pair.

For SVE, because we have predicates in the general case it’s not feasible to 
detect
these rotates at the RTL level, so I was hoping that GIMPLE could do it, and 
indeed
GIMPLE has many places where it can detect rotate idioms: forwprop1, bswap 
detection,
pattern matching in the vectorizer, match.pd for simple cases etc.
The vectorizer is probably a good place to do it (rather than asking the other 
places to deal
with VLA types) but I think it would need the target to affirm that it supports 
SVE vector rotates
through the lrotm3 optab, hence my question. 

Though some rotate amounts can be implemented with a single instruction (REVB, 
REVH, REVW),
the fallback expansion for TARGET_SVE2 would be a two-instruction LSL+USRA 
which is better than
what we currently emit in the motivating test case:
https://godbolt.org/z/o55or8hYv
We currently cannot combine the LSL+LSR+ORR sequence because the predicates get 
in the way during
combine (even though the instructions involved are actually unpredicated and 
the predicate would get
dropped later anyway).
It would also allow us to keep an RTL-level ROTATE long enough to combine it 
into the XAR and RAX
instructions from TARGET_SVE2_SHA3.

Finally, it would allow us to experiment with more optimal SVE-specific rotate 
sequences in the future.
For example, we could consider emitting high-throughput TBLs for rotates that 
are a multiple of 8.

I’m suggesting doing this for TARGET_SVE2 as we have the combined USRA 
instruction there,
but I wouldn’t object doing this for TARGET_SVE.

Thanks,
Kyrill

Re: BUG: realloc(p,0) is not conforming to C99/C11/C17/POSIX.1-2008

[Alejandro Colomar via Gcc]

CC += Robert, Joseph, gcc@

On Thu, Oct 17, 2024 at 04:30:27PM GMT, Alejandro Colomar wrote:
> On Thu, Oct 17, 2024 at 04:23:29PM GMT, Alejandro Colomar wrote:
> > CC += Doug, as the author of the original malloc(3).
> > 
> > On Thu, Oct 17, 2024 at 04:21:22PM GMT, Alejandro Colomar wrote:
> > > Hi!
> > > 
> > > наб and I have been researching about malloc(0) and realloc(p,0), and
> > > have written our findings here:
> > > 
> > > 
> > > 
> > > 
> > > -  Every default malloc(0) had always returned a unique pointer.
> > > -  Every realloc(,0) had always behaved congruently with malloc(0).
> > > -  The weird malloc(0)=NULL was a bug in SysV r2's optimized alternative
> > >-lmalloc library.  The documentation still didn't allow returning
> > >NULL.
> > > -  SVID surprisingly documented that bug in -lmalloc as if it were the
> > >only good behavior, making every default malloc(0) non-conforming.
> > >This was a huge mistake/crime.  So far so good for realloc(,0).
> > > 
> > > -  X3J11 (ANSI C) decided that realloc(p,0) shall be equivalent to
> > >free(p) (allegedly, in line with their self-inflicted policy of not
> > >allowing zero-size objects, which BTW was never true, since malloc(0)
> > >and realloc(NULL,0) continued to support zero-size objects).  This
> > >was a hallucination of ANSI C.  No implementations had done this.
> > >Ever.  No documentation or standards document had specified this.
> > >Ever.
> > > -  POSIX.1-2001 (Issue 6) blindly followed C89, making every POSIX
> > >system non-conforming.
> > > 
> > > -  C99 and POSIX.1-2008 fixed the issue, by reverting to the historical
> > >realloc(p,0) behavior of being congruent to malloc(0).
> > > 
> > > -  glibc, in 2006/2007, made a so-called bugfix change to conform to
> > >C89, which effectively made realloc(p,0) non-conforming to C99.  This
> > >happened in the following commit:
> > > 
> > >   commit 11bf311edc76f5ddc469a8c396e313e82d76be15
> > >   Author: Ulrich Drepper 
> > >   Date:   Thu Jan 11 21:51:07 2007 +
> > > 
> > >   [BZ #2510, BZ #2830, BZ #3137, BZ #3313, BZ #3426, BZ #3465, BZ 
> > > #3480, BZ #3483, BZ #
> > >   3493, BZ #3514, BZ #3515, BZ #3664, BZ #3673, BZ #3674]
> > > 
> > >   [...]
> > > 
> > >   2006-12-08  Ulrich Drepper  
> > >   * malloc/memusage.c: Handle realloc with new size of zero 
> > > and
> > >   non-NULL pointer correctly.
> > > 
> > >   [...]
> > > 
> > > Please revert that commit, and make realloc(p,0) conform to C99, C11,
> > > C17, and POSIX.1-2008.  This is the historical right behavior of
> > > realloc(p,0), and what the BSDs do.
> 
> I realized that I didn't clarify what the bug is.  realloc(p,0) should
> return a unique pointer, just like malloc(0) does.  Returning NULL is
> brain-damaged.
> 
> > > 
> > > That so-called bugfix probably silently broke algorithms for which 0 is
> > > not a special case.
> > > 
> > > C23 will break realloc(p,0) even further, but let's ignore that mistake.
> > > 
> > > 
> > > Have a lovely day!
> > > Alex
> > > 
> > > 
> > > -- 
> > > 
> > 
> > 
> > 
> > -- 
> > 
> 
> 
> 
> -- 
> 



-- 



signature.asc
Description: PGP signature

Re: BUG: realloc(p,0) is not conforming to C99/C11/C17/POSIX.1-2008

[Alejandro Colomar via Gcc]

On Thu, Oct 17, 2024 at 05:19:07PM GMT, Alejandro Colomar wrote:
> CC += Robert, Joseph, gcc@
> 
> On Thu, Oct 17, 2024 at 04:30:27PM GMT, Alejandro Colomar wrote:
> > On Thu, Oct 17, 2024 at 04:23:29PM GMT, Alejandro Colomar wrote:
> > > CC += Doug, as the author of the original malloc(3).
> > > 
> > > On Thu, Oct 17, 2024 at 04:21:22PM GMT, Alejandro Colomar wrote:
> > > > Hi!
> > > > 
> > > > наб and I have been researching about malloc(0) and realloc(p,0), and
> > > > have written our findings here:
> > > > 
> > > > 
> > > > 
> > > > 
> > > > -  Every default malloc(0) had always returned a unique pointer.
> > > > -  Every realloc(,0) had always behaved congruently with malloc(0).
> > > > -  The weird malloc(0)=NULL was a bug in SysV r2's optimized alternative
> > > >-lmalloc library.  The documentation still didn't allow returning
> > > >NULL.
> > > > -  SVID surprisingly documented that bug in -lmalloc as if it were the
> > > >only good behavior, making every default malloc(0) non-conforming.
> > > >This was a huge mistake/crime.  So far so good for realloc(,0).
> > > > 
> > > > -  X3J11 (ANSI C) decided that realloc(p,0) shall be equivalent to
> > > >free(p) (allegedly, in line with their self-inflicted policy of not
> > > >allowing zero-size objects, which BTW was never true, since malloc(0)
> > > >and realloc(NULL,0) continued to support zero-size objects).  This
> > > >was a hallucination of ANSI C.  No implementations had done this.
> > > >Ever.  No documentation or standards document had specified this.
> > > >Ever.
> > > > -  POSIX.1-2001 (Issue 6) blindly followed C89, making every POSIX
> > > >system non-conforming.
> > > > 
> > > > -  C99 and POSIX.1-2008 fixed the issue, by reverting to the historical
> > > >realloc(p,0) behavior of being congruent to malloc(0).
> > > > 
> > > > -  glibc, in 2006/2007, made a so-called bugfix change to conform to
> > > >C89, which effectively made realloc(p,0) non-conforming to C99.  This
> > > >happened in the following commit:
> > > > 
> > > > commit 11bf311edc76f5ddc469a8c396e313e82d76be15
> > > > Author: Ulrich Drepper 
> > > > Date:   Thu Jan 11 21:51:07 2007 +
> > > > 
> > > > [BZ #2510, BZ #2830, BZ #3137, BZ #3313, BZ #3426, BZ 
> > > > #3465, BZ #3480, BZ #3483, BZ #
> > > > 3493, BZ #3514, BZ #3515, BZ #3664, BZ #3673, BZ #3674]
> > > > 
> > > > [...]
> > > > 
> > > > 2006-12-08  Ulrich Drepper  
> > > > * malloc/memusage.c: Handle realloc with new size 
> > > > of zero and
> > > > non-NULL pointer correctly.
> > > > 
> > > > [...]
> > > > 
> > > > Please revert that commit, and make realloc(p,0) conform to C99, C11,
> > > > C17, and POSIX.1-2008.  This is the historical right behavior of
> > > > realloc(p,0), and what the BSDs do.
> > 
> > I realized that I didn't clarify what the bug is.  realloc(p,0) should
> > return a unique pointer, just like malloc(0) does.  Returning NULL is

Pedantically, I should say valid, not unique.  Returning the old pointer
would be a valid implementation.

> > brain-damaged.
> > 
> > > > 
> > > > That so-called bugfix probably silently broke algorithms for which 0 is
> > > > not a special case.
> > > > 
> > > > C23 will break realloc(p,0) even further, but let's ignore that mistake.
> > > > 
> > > > 
> > > > Have a lovely day!
> > > > Alex
> > > > 
> > > > 
> > > > -- 
> > > > 
> > > 
> > > 
> > > 
> > > -- 
> > > 
> > 
> > 
> > 
> > -- 
> > 
> 
> 
> 
> -- 
> 



-- 



signature.asc
Description: PGP signature

Re: Alex Coplan appointed maintainer of AArch64 pair fusion pass and pair-fusion pass.

[Richard Sandiford via Gcc]

Ramana Radhakrishnan via Gcc  writes:
> I am pleased to announce that the GCC Steering Committee has appointed
> Alex Coplan as a maintainer for the AArch64 load / store pair fusion
> pass.
>
> In addition the steering committee has also appointed him as
> maintainer for the Pair Fusion pass in the target independent
> portions.
>
> Please join me in congratulating Alex on his new roles. Alex , please
> update your listing in the MAINTAINERS file.

Congrats Alex!  Well deserved :)

Just wanted to add that, IMO, the AArch64 parts should be taken to
include things like aarch64-ldpstp.md, other related peepholes,
and the LDP/STP support in aarch64.cc.

Richard

Re: BUG: realloc(p,0) is not conforming to C99/C11/C17/POSIX.1-2008

[Douglas McIlroy via Gcc]

> Pedantically, I should say valid, not unique.

More pedantically, it should be distinct from any other pointer returned by
malloc or realloc and not freed or realloced since.

On Thu, Oct 17, 2024 at 11:25 AM Alejandro Colomar  wrote:

> On Thu, Oct 17, 2024 at 05:19:07PM GMT, Alejandro Colomar wrote:
> > CC += Robert, Joseph, gcc@
> >
> > On Thu, Oct 17, 2024 at 04:30:27PM GMT, Alejandro Colomar wrote:
> > > On Thu, Oct 17, 2024 at 04:23:29PM GMT, Alejandro Colomar wrote:
> > > > CC += Doug, as the author of the original malloc(3).
> > > >
> > > > On Thu, Oct 17, 2024 at 04:21:22PM GMT, Alejandro Colomar wrote:
> > > > > Hi!
> > > > >
> > > > > наб and I have been researching about malloc(0) and realloc(p,0),
> and
> > > > > have written our findings here:
> > > > >
> > > > > 
> > > > > 
> > > > >
> > > > > -  Every default malloc(0) had always returned a unique pointer.
> > > > > -  Every realloc(,0) had always behaved congruently with malloc(0).
> > > > > -  The weird malloc(0)=NULL was a bug in SysV r2's optimized
> alternative
> > > > >-lmalloc library.  The documentation still didn't allow
> returning
> > > > >NULL.
> > > > > -  SVID surprisingly documented that bug in -lmalloc as if it were
> the
> > > > >only good behavior, making every default malloc(0)
> non-conforming.
> > > > >This was a huge mistake/crime.  So far so good for realloc(,0).
> > > > >
> > > > > -  X3J11 (ANSI C) decided that realloc(p,0) shall be equivalent to
> > > > >free(p) (allegedly, in line with their self-inflicted policy of
> not
> > > > >allowing zero-size objects, which BTW was never true, since
> malloc(0)
> > > > >and realloc(NULL,0) continued to support zero-size objects).
> This
> > > > >was a hallucination of ANSI C.  No implementations had done
> this.
> > > > >Ever.  No documentation or standards document had specified
> this.
> > > > >Ever.
> > > > > -  POSIX.1-2001 (Issue 6) blindly followed C89, making every POSIX
> > > > >system non-conforming.
> > > > >
> > > > > -  C99 and POSIX.1-2008 fixed the issue, by reverting to the
> historical
> > > > >realloc(p,0) behavior of being congruent to malloc(0).
> > > > >
> > > > > -  glibc, in 2006/2007, made a so-called bugfix change to conform
> to
> > > > >C89, which effectively made realloc(p,0) non-conforming to
> C99.  This
> > > > >happened in the following commit:
> > > > >
> > > > > commit 11bf311edc76f5ddc469a8c396e313e82d76be15
> > > > > Author: Ulrich Drepper 
> > > > > Date:   Thu Jan 11 21:51:07 2007 +
> > > > >
> > > > > [BZ #2510, BZ #2830, BZ #3137, BZ #3313, BZ #3426, BZ
> #3465, BZ #3480, BZ #3483, BZ #
> > > > > 3493, BZ #3514, BZ #3515, BZ #3664, BZ #3673, BZ #3674]
> > > > >
> > > > > [...]
> > > > >
> > > > > 2006-12-08  Ulrich Drepper  
> > > > > * malloc/memusage.c: Handle realloc with new
> size of zero and
> > > > > non-NULL pointer correctly.
> > > > >
> > > > > [...]
> > > > >
> > > > > Please revert that commit, and make realloc(p,0) conform to C99,
> C11,
> > > > > C17, and POSIX.1-2008.  This is the historical right behavior of
> > > > > realloc(p,0), and what the BSDs do.
> > >
> > > I realized that I didn't clarify what the bug is.  realloc(p,0) should
> > > return a unique pointer, just like malloc(0) does.  Returning NULL is
>
> Pedantically, I should say valid, not unique.  Returning the old pointer
> would be a valid implementation.
>
> > > brain-damaged.
> > >
> > > > >
> > > > > That so-called bugfix probably silently broke algorithms for which
> 0 is
> > > > > not a special case.
> > > > >
> > > > > C23 will break realloc(p,0) even further, but let's ignore that
> mistake.
> > > > >
> > > > >
> > > > > Have a lovely day!
> > > > > Alex
> > > > >
> > > > >
> > > > > --
> > > > > 
> > > >
> > > >
> > > >
> > > > --
> > > > 
> > >
> > >
> > >
> > > --
> > > 
> >
> >
> >
> > --
> > 
>
>
>
> --
> 
>