Re: PPC64 libmvec implementation of sincos

[Szabolcs Nagy]

On 27/09/2019 20:23, GT wrote:
> I am attempting to create a vector version of sincos for PPC64.
> The relevant discussion thread is on the GLIBC libc-alpha mailing list.
> Navigate it beginning at 
> https://sourceware.org/ml/libc-alpha/2019-09/msg00334.html
> 
> The intention is to reuse as much as possible from the existing GCC 
> implementation of other libmvec functions.
> My questions are: Which function(s) in GCC;
> 
> 1. Gather scalar function input arguments, from multiple loop iterations, 
> into a single vector input argument for the vector function version?
> 2. Distribute scalar function outputs, to appropriate loop iteration result, 
> from the single vector function output result?
> 
> I am referring especially to vectorization of sin and cos.

i wonder if gcc can auto-vectorize scalar sincos
calls, the vectorizer seems to want the calls to
have no side-effect, but attribute pure or const
is not appropriate for sincos (which has no return
value but takes writable pointer args)

"#pragma omp simd" on a loop seems to work but i
could not get unannotated sincos loops to vectorize.

it seems it would be nice if we could add pure/const
somehow (maybe to the simd variant only? afaik openmp
requires no sideeffects for simd variants, but that's
probably only for explicitly marked loops?)

make static method find_reloads_address_1(...) extern accessible

[stefan]

I've implemented LEGITIMIZE_RELOAD_ADDRESS and that implementation is
calling find_reloads_address_1.

My implementation adds double indirect addressing to the m68k target and
since the use of an outer index register or offset depends on the use of
an inner index register or offset, since only one index register and one
offset is allowed per address. => The recursive reload implementation does
not work. So the LEGITIMIZE_RELOAD_ADDRESS takes care of the whole address
at once.

How are the chances that a static method of reload is converted into an
extern accessible method, if a patch would requires it?

Regards

Stefan

Eorror compiling GCC-4.8.0 for Solaris 2.9 and 2.10

[Lincoln]

Hi GNU.ORG,

I am getting the error below when I try to compile gcc-4.8.0.  Can someone 
assist me with a possible solution:


"/tmp/gcc-4.8.0/libcpp/files.c", line 1268: Error: Cannot assign char* to int.
"/tmp/gcc-4.8.0/libcpp/files.c", line 1371: Warning (Anachronism): Formal 
argument 2 of type extern "C" int(*)(void**,void*) in call to 
htab_traverse(htab*, extern "C" int(*)(void**,void*), void*) is being passed 
int(*)(void**,void*).
"/tmp/gcc-4.8.0/libcpp/files.c", line 1380: Warning (Anachronism): Formal 
argument 4 of type extern "C" int(*)(const void*,const void*) in call to 
std::qsort(void*, unsigned, unsigned, extern "C" int(*)(const void*,const 
void*)) is being passed int(*)(const void*,const void*).
"/tmp/gcc-4.8.0/libcpp/files.c", line 1386: Error: The function "__flsbuf" must 
have a prototype.
"/tmp/gcc-4.8.0/libcpp/files.c", line 1530: Error: The function "__filbuf" must 
have a prototype.
"/tmp/gcc-4.8.0/libcpp/files.c", line 1570: Error: The function "__filbuf" must 
have a prototype.
"/tmp/gcc-4.8.0/libcpp/files.c", line 1584: Error: The function "__filbuf" must 
have a prototype.
"/tmp/gcc-4.8.0/libcpp/files.c", line 1597: Error: The function "__filbuf" must 
have a prototype.
"/tmp/gcc-4.8.0/libcpp/files.c", line 1677: Error: The function "__flsbuf" must 
have a prototype.
"/tmp/gcc-4.8.0/libcpp/files.c", line 1834: Warning (Anachronism): Formal 
argument 4 of type extern "C" int(*)(const void*,const void*) in call to 
std::qsort(void*, unsigned, unsigned, extern "C" int(*)(const void*,const 
void*)) is being pa
ssed int(*)(const void*,const void*).
"/tmp/gcc-4.8.0/libcpp/files.c", line 1932: Warning (Anachronism): Formal 
argument 5 of type extern "C" int(*)(const void*,const void*) in call to 
std::bsearch(const void*, const void*, unsigned, unsigned, extern "C" 
int(*)(const void*,cons
t void*)) is being passed int(*)(const void*,const void*).
7 Error(s) and 11 Warning(s) detected.
make[3]: *** [Makefile:223: files.o] Error 7
make[3]: Leaving directory '/tmp/gcc-4.8.0/objdir/libcpp'
make[2]: *** [Makefile:9816: all-stage1-libcpp] Error 2
make[2]: Leaving directory '/tmp/gcc-4.8.0/objdir'
make[1]: *** [Makefile:20357: stage1-bubble] Error 2
make[1]: Leaving directory '/tmp/gcc-4.8.0/objdir'
make: *** [Makefile:889: all] Error 2


Thank you,

Lincoln...
---
The wheel is spinning, but the hamster is asleep!
Yes! The Truth is Out There, Somewhere!

RFC: Enabling fixed point modes on x86

[Martin Ling]

Hi all, new to the list.

Attached is a very short patch which enables the use of fixed point
modes on x86 targets. I first created this a couple of years ago for
gcc 7 and have just updated it for current git master.

I have not sent this to the patches list as I do not expect it to be
anywhere near merge-ready. Rather, I was hoping to have a conversation
about what is missing and what else might need to be done for fixed
point modes to become officially supported on x86, or whether that's
even desirable.

My initial motivation for this was that we have a C codebase primarily
written for an embedded ARM target with no FPU, which makes extensive
use of the fract/accum types available on that target. To simplify
development we wanted to be able to build & test this code on
x86 systems. Performance (on x86) was not a concern for us.

Although I had no prior knowlede of gcc internals/development I started
looking at what might be needed to enable fixed point support on x86,
and it seems like very little is needed for it to work:

gcc/config/i386/i386.c:

- classify_argument() needs to classify the *Q and *A modes as per their
  corresponding integer modes.

- ix86_scalar_mode_supported_p needs to forward to
  default_fixed_point_supported_p for ALL_SCALAR_FIXED_POINT_MODE_P.

gcc/configure[.ac]:

- allow --enable-fixed-point for i?86* and x86_64*

With these changes, everything seems to "just work". The fixed point
helper functions in libgcc/fixed-bit.c are built automatically for all
the possible mode combinations, and get linked in as needed by the
resulting compiler. The tests in gcc/testsuite/gcc.dg/fixed-point pass.

Of course, everything is emulated - no special instruction sequences are
generated, and the resulting code is probably no faster than could be
achieved using libfixmath or similar libraries.

But even without a performance advantage this is useful - it allows
compatibility with fixed point code written for other platforms, and
enables fixed point code to be written more clearly on x86, by use of
special types rather than library functions.

I am guessing however that there is a lot more that needs to be thought
about before anything like this could be merged.

For starters, by doing this I have implicitly invented an ABI for fixed
point types on x86 (they get passed exactly like correspondingly-sized
integers, I suppose). This ABI would be unique to gcc.

I have also implicitly set the numbers of integral and fractional bits
for each mode to the gcc defaults (which are specified in the docs at
https://gcc.gnu.org/onlinedocs/gccint/Machine-Modes.html).

I don't know the x86 instruction set (and its many extensions) well, and
haven't thought about how fixed point operations could be implemented
most efficiently with it, and whether that would affect the choice of
format for each mode.

And yet, this works and is useful (to us at least).

What else have I missed? What else would be needed for this to be
supported? And does anyone see any value in adding this, or should I
just keep this to myself as an out of tree patch?

Regards,


Martin
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 9a87413ee..aa8fb910c 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -2300,6 +2300,20 @@ classify_argument (machine_mode mode, const_tree type,
 case E_CSImode:
 case E_CHImode:
 case E_CQImode:
+case E_QQmode:
+case E_UQQmode:
+case E_HQmode:
+case E_UHQmode:
+case E_SQmode:
+case E_USQmode:
+case E_DQmode:
+case E_UDQmode:
+case E_HAmode:
+case E_UHAmode:
+case E_SAmode:
+case E_USAmode:
+case E_DAmode:
+case E_UDAmode:
   {
 	int size = bit_offset + (int) GET_MODE_BITSIZE (mode);
 
@@ -2332,6 +2346,10 @@ classify_argument (machine_mode mode, const_tree type,
   }
 case E_CDImode:
 case E_TImode:
+case E_TQmode:
+case E_UTQmode:
+case E_TAmode:
+case E_UTAmode:
   classes[0] = classes[1] = X86_64_INTEGER_CLASS;
   return 2;
 case E_COImode:
@@ -20618,6 +20636,8 @@ ix86_scalar_mode_supported_p (scalar_mode mode)
 {
   if (DECIMAL_FLOAT_MODE_P (mode))
 return default_decimal_float_supported_p ();
+  else if (ALL_SCALAR_FIXED_POINT_MODE_P (mode))
+return default_fixed_point_supported_p ();
   else if (mode == TFmode)
 return true;
   else
diff --git a/gcc/configure b/gcc/configure
index 22cf194a8..1ac52cfbd 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -7634,6 +7634,10 @@ else
 mips*-*-*)
   enable_fixed_point=yes
   ;;
+
+i?86*-*-* | x86_64*-*-*)
+  enable_fixed_point=yes
+  ;;
 *)
   { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: fixed-point is not supported for this target, ignored" >&5
 $as_echo "$as_me: WARNING: fixed-point is not supported for this target, ignored" >&2;}
diff --git a/gcc/configure.ac b/gcc/configure.ac
index 5c60d0f8d..f12e87a01 100644
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -868,6 +8

Re: RFC: Enabling fixed point modes on x86

[Joseph Myers]

On Mon, 30 Sep 2019, Martin Ling wrote:

> For starters, by doing this I have implicitly invented an ABI for fixed
> point types on x86 (they get passed exactly like correspondingly-sized
> integers, I suppose). This ABI would be unique to gcc.
> 
> I have also implicitly set the numbers of integral and fractional bits
> for each mode to the gcc defaults (which are specified in the docs at
> https://gcc.gnu.org/onlinedocs/gccint/Machine-Modes.html).

Yes - and we had the discussion at the Cauldron recently about trying to 
coordinate ABIs for new features with anyone who might wish to support 
those in other implementations.

In the case of x86, there are ABI mailing lists ia32-...@googlegroups.com 
and x86-64-...@googlegroups.com that can be consulted (though they don't 
always come to a conclusion when issues are raised, it's probably 
necessary to be quite active about pushing things to a conclusion and 
getting it into the ABI repositories).

I should also mention the concern I previously expressed that the present 
implementation approach for fixed-point support in GCC is questionable and 
it might be better to have GIMPLE lowering of fixed-point types to normal 
integer ones, with some extra GIMPLE operations but without separate 
machine modes .  
This is not however intended to block addition of fixed-point support to 
any architecture based on the existing approach, given that we don't have 
an implementation based on such lowering (and the same ABI issues would 
still apply this this approach).

-- 
Joseph S. Myers
jos...@codesourcery.com

state of play/strategy for including Modula-2 into the trunk (licence queries)

[Gaius Mulley]

Hello,

I thought I'd seek advice on how to get the Modula-2 front end into
trunk and also give a state of play.


State of play
=

Currently the gm2-trunk passes all but one regression test on amd64.
Other architectures/platforms vary.  In early September the whole number
overflow detection was completed, which was the final ISO feature
required.  The compiler and libraries completely implement the ISO
standard.  The good news is that the focus is now bug
hunting/fixing/maintainance and updating all boiler-plates.

I'm currently semi-manually walking the source tree updating all GPL
boiler-plates.  All compiler source files have been changed to GPL3.

http://git.savannah.gnu.org/cgit/gm2.git/tree/gcc-versionno/gcc/gm2/gm2-compiler

All library source files have been changed to GPL3 with runtime
exception in these directories:

http://git.savannah.gnu.org/cgit/gm2.git/tree/gcc-versionno/gcc/gm2/gm2-libs
http://git.savannah.gnu.org/cgit/gm2.git/tree/gcc-versionno/gcc/gm2/gm2-libs-min
http://git.savannah.gnu.org/cgit/gm2.git/tree/gcc-versionno/gcc/gm2/gm2-libs-pim
http://git.savannah.gnu.org/cgit/gm2.git/tree/gcc-versionno/gcc/gm2/gm2-libs-iso
http://git.savannah.gnu.org/cgit/gm2.git/tree/gcc-versionno/gcc/gm2/gm2-libs-coroutines
http://git.savannah.gnu.org/cgit/gm2.git/tree/gcc-versionno/gcc/gm2/gm2-libiberty
http://git.savannah.gnu.org/cgit/gm2.git/tree/gcc-versionno/gcc/gm2/gm2-libs-ch

Is this correct?  Without wishing to seem presumptuous - is it preferred to
use the project name GCC or stick with GNU Modula-2?

(I still need to visit:
http://git.savannah.gnu.org/cgit/gm2.git/tree/gcc-versionno/libgm2)

gm2 does use GNU libpth (to create context and switch contexts).
Although it doesn't need libpth for single process programs.  I think
the GNU libpth project is no longer maintained, so I've included it in:

http://git.savannah.gnu.org/cgit/gm2.git/tree/gcc-versionno/libgm2/libpth/pth

I assuming this is okay as it is an official GNU project?  It contains
the important clause:

>  This library is free software; you can redistribute it and/or
>  modify it under the terms of the GNU Lesser General Public
>  License as published by the Free Software Foundation; either
>  version 2.1 of the License, or (at your option) any later version.

in its source files - so I plan to bump this to GPL3 with runtime
exception.  Is this sensible and what is expected?

Anyway I thought it best to ask these questions even though there is
still a little way to go - but the finishing line is in sight!  (In
terms of visiting each and every file and checking the boiler-plates).

I've yet to tackle the regression test directory and the examples
directory.  I also need to check all Makefiles, script files and double
check the texi files.

Once the tree of source file visiting is complete, how should I proceed?

My default plan would be to work on the compiler driver patches again
after applying the changes advised.  If/when they go through ask for a
review of the tree for inclusion:

http://git.savannah.gnu.org/cgit/gm2.git/tree/gcc-versionno

again is this sensible?  Are there [obvious] issues I've missed?
What would you prefer?

many thanks,

regards,
Gaius

ღ Why you respond so long in mine letter?

[Colette]

Hello,my love. I seen you in Facebook today and so I would like to see you.
Ma name Grace
I do some Account wit my nice pictures.
I will waiting your arms.
my second nickname : Phelps442.

honey find me!!

Re: PPC64 libmvec implementation of sincos

[GT]

‐‐‐ Original Message ‐‐‐
On Monday, September 30, 2019 9:52 AM, Szabolcs Nagy  
wrote:

> On 27/09/2019 20:23, GT wrote:
>
> > I am attempting to create a vector version of sincos for PPC64.
> > The relevant discussion thread is on the GLIBC libc-alpha mailing list.
> > Navigate it beginning at 
> > https://sourceware.org/ml/libc-alpha/2019-09/msg00334.html
> > The intention is to reuse as much as possible from the existing GCC 
> > implementation of other libmvec functions.
> > My questions are: Which function(s) in GCC;
> >
> > 1.  Gather scalar function input arguments, from multiple loop iterations, 
> > into a single vector input argument for the vector function version?
> > 2.  Distribute scalar function outputs, to appropriate loop iteration 
> > result, from the single vector function output result?
> >
> > I am referring especially to vectorization of sin and cos.
>
> i wonder if gcc can auto-vectorize scalar sincos
> calls, the vectorizer seems to want the calls to
> have no side-effect, but attribute pure or const
> is not appropriate for sincos (which has no return
> value but takes writable pointer args)

1.  Do you mean whether x86_64 already does auto-vectorize sincos?
2.  Where in the code do you see the vectorizer require no side-effect?

> "#pragma omp simd" on a loop seems to work but i
> could not get unannotated sincos loops to vectorize.
>
> it seems it would be nice if we could add pure/const
> somehow (maybe to the simd variant only? afaik openmp
> requires no sideeffects for simd variants, but that's
> probably only for explicitly marked loops?)

1. Example 1 and Example 2 at https://sourceware.org/glibc/wiki/libmvec show 
the 2 different
ways to activate auto-vectorization. When you refer to "unannotated sincos", 
which of
the 2 techniques do you mean?
2. Which function was auto-vectorized by "pragma omp simd" in the loop?

Moving to C++11

[Nicholas Krause]

Greetings Jonathan and Jason,

I was wondering what work is required to move to C++11. Seems your

both interested in getting this done and so am I. Perhaps we start

similar to Git with a wiki page about what features would be useful

and then start migrating the makefiles to allow for this.

So far according to the previous discussion it seems that the community

would like these features:

1. Template Aliases

2. Better narrowing supprot for core types

2. Auto for local variables

3. std::move,rvalues

4. For each loops

Let me know if I missed something but I will be glad to help out with this,

Nick

Re: PPC64 libmvec implementation of sincos

[Szabolcs Nagy]

On 30/09/2019 18:30, GT wrote:
> ‐‐‐ Original Message ‐‐‐
> On Monday, September 30, 2019 9:52 AM, Szabolcs Nagy  
> wrote:
> 
>> On 27/09/2019 20:23, GT wrote:
>>
>>> I am attempting to create a vector version of sincos for PPC64.
>>> The relevant discussion thread is on the GLIBC libc-alpha mailing list.
>>> Navigate it beginning at 
>>> https://sourceware.org/ml/libc-alpha/2019-09/msg00334.html
>>> The intention is to reuse as much as possible from the existing GCC 
>>> implementation of other libmvec functions.
>>> My questions are: Which function(s) in GCC;
>>>
>>> 1.  Gather scalar function input arguments, from multiple loop iterations, 
>>> into a single vector input argument for the vector function version?
>>> 2.  Distribute scalar function outputs, to appropriate loop iteration 
>>> result, from the single vector function output result?
>>>
>>> I am referring especially to vectorization of sin and cos.
>>
>> i wonder if gcc can auto-vectorize scalar sincos
>> calls, the vectorizer seems to want the calls to
>> have no side-effect, but attribute pure or const
>> is not appropriate for sincos (which has no return
>> value but takes writable pointer args)
> 
> 1.  Do you mean whether x86_64 already does auto-vectorize sincos?

any current target with simd attribute or omp delcare simd support.

> 2.  Where in the code do you see the vectorizer require no side-effect?

i don't know where it is in the code, but

__attribute__((simd)) float foo (float);

void bar (float *restrict a, float *restrict b)
{
for(int i=0; i<4000; i++)
a[i] = foo (b[i]);
}

is not vectorized, however it gets vectorized if

i add __attribute__((const)) to foo
OR
if i add '#pragma omp simd' to the loop and compile with
-fopenmp-simd.

(which makes sense to me: you don't want to vectorize
if you don't know the side-effects, otoh, there is no
attribute to say that i know there will be no side-effects
in functions taking pointer arguments so i don't see
how sincos can get vectorized)

>> "#pragma omp simd" on a loop seems to work but i
>> could not get unannotated sincos loops to vectorize.
>>
>> it seems it would be nice if we could add pure/const
>> somehow (maybe to the simd variant only? afaik openmp
>> requires no sideeffects for simd variants, but that's
>> probably only for explicitly marked loops?)
> 
> 1. Example 1 and Example 2 at https://sourceware.org/glibc/wiki/libmvec show 
> the 2 different
> ways to activate auto-vectorization. When you refer to "unannotated sincos", 
> which of
> the 2 techniques do you mean?

example 1 annotates the loop with #pragma omp simd.
(and requires -fopenmp-simd cflag to work)

example 2 is my goal where -ftree-vectorize is enough
without annotation.

> 2. Which function was auto-vectorized by "pragma omp simd" in the loop?

see example above.

Re: PPC64 libmvec implementation of sincos

[Richard Biener]

On September 30, 2019 3:52:52 PM GMT+02:00, Szabolcs Nagy 
 wrote:
>On 27/09/2019 20:23, GT wrote:
>> I am attempting to create a vector version of sincos for PPC64.
>> The relevant discussion thread is on the GLIBC libc-alpha mailing
>list.
>> Navigate it beginning at
>https://sourceware.org/ml/libc-alpha/2019-09/msg00334.html
>> 
>> The intention is to reuse as much as possible from the existing GCC
>implementation of other libmvec functions.
>> My questions are: Which function(s) in GCC;
>> 
>> 1. Gather scalar function input arguments, from multiple loop
>iterations, into a single vector input argument for the vector function
>version?
>> 2. Distribute scalar function outputs, to appropriate loop iteration
>result, from the single vector function output result?
>> 
>> I am referring especially to vectorization of sin and cos.
>
>i wonder if gcc can auto-vectorize scalar sincos
>calls, the vectorizer seems to want the calls to
>have no side-effect, but attribute pure or const
>is not appropriate for sincos (which has no return
>value but takes writable pointer args)

We have __builtin_cexpi for that but not sure if any of the mechanisms can 
provide a mapping to a vectorized variant. 

>"#pragma omp simd" on a loop seems to work but i
>could not get unannotated sincos loops to vectorize.
>
>it seems it would be nice if we could add pure/const
>somehow (maybe to the simd variant only? afaik openmp
>requires no sideeffects for simd variants, but that's
>probably only for explicitly marked loops?)

Re: git conversion of GCC wwwdocs repository

[Joseph Myers]

As far as I can tell from the discussion, people are happy with the 
version of the conversion using @gcc.gnu.org addresses.  When shall we (do 
a final conversion if there are any commits postdating that one and) 
switch over to it as the live repository, set up hooks and update 
documentation of editing the website?

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: RFC: Followup to PR91593

[Jerry DeLisle]

Copying gcc list for additional thoughts on a possible bogus warning.

On 9/29/19 9:02 AM, Jerry DeLisle wrote:

Hi all,


--- snip ---


diff --git a/libgfortran/io/write.c b/libgfortran/io/write.c
index 4ef35561fdd..fc046efbe34 100644
--- a/libgfortran/io/write.c
+++ b/libgfortran/io/write.c
@@ -1031,7 +1031,7 @@ btoa_big (const char *s, char *buffer, int len, 
GFC_UINTEGER_LARGEST *n)

    else
  {
    const char *p = s + len - 1;
-  for (i = 0; i < len; i++)
+  for (i = 0; i < len - 1; i++)
  {
    char c = *p;



--- snip ---

The first attempt to fix (above) is completely off.  I have tried various 
combinations of code changes and I am beginning to think the warning is bogus:


In function ‘btoa_big’,
inlined from ‘write_b’ at ../../../trunk/libgfortran/io/write.c:1217:11:
../../../trunk/libgfortran/io/write.c:1052:6: warning: writing 1 byte into a 
region of size 0 [-Wstringop-overflow=]

 1052 |   *q = '\0';
  |   ~~~^~

Using gdb I have watched the pointer address stored in q and the setting of the 
string of bytes doing the binary to ascii conversion. I have also checked the 
length of the buffer being used and its is what I would expect with length of 129.


However, the warning only goes away if I add an additional 8 bytes to the buffer 
(suspicious).


So doing the following eliminates the warning:

diff --git a/libgfortran/io/write.c b/libgfortran/io/write.c
index 4ef35561fdd..fd0e46851e4 100644
--- a/libgfortran/io/write.c
+++ b/libgfortran/io/write.c
@@ -1204,7 +1204,7 @@ void
 write_b (st_parameter_dt *dtp, const fnode *f, const char *source, int len)
 {
   const char *p;
-  char itoa_buf[GFC_BTOA_BUF_SIZE];
+  char itoa_buf[GFC_BTOA_BUF_SIZE + 8];
   GFC_UINTEGER_LARGEST n = 0;

   if (len > (int) sizeof (GFC_UINTEGER_LARGEST))

Any suggestions? I am certainly not seeing it.

Regards,

Jerry

Re: RFC: Followup to PR91593

[Steve Kargl]

On Mon, Sep 30, 2019 at 08:40:29PM -0700, Jerry DeLisle wrote:
> Copying gcc list for additional thoughts on a possible bogus warning.
> 
> On 9/29/19 9:02 AM, Jerry DeLisle wrote:
> > Hi all,
> > 
> --- snip ---
> 
> > diff --git a/libgfortran/io/write.c b/libgfortran/io/write.c
> > index 4ef35561fdd..fc046efbe34 100644
> > --- a/libgfortran/io/write.c
> > +++ b/libgfortran/io/write.c
> > @@ -1031,7 +1031,7 @@ btoa_big (const char *s, char *buffer, int len, 
> > GFC_UINTEGER_LARGEST *n)
> >     else
> >   {
> >     const char *p = s + len - 1;
> > -  for (i = 0; i < len; i++)
> > +  for (i = 0; i < len - 1; i++)
> >   {
> >     char c = *p;
> > 
> 
> --- snip ---
> 
> The first attempt to fix (above) is completely off.  I have tried various 
> combinations of code changes and I am beginning to think the warning is bogus:
> 
> In function ‘btoa_big’,
>  inlined from ‘write_b’ at ../../../trunk/libgfortran/io/write.c:1217:11:
> ../../../trunk/libgfortran/io/write.c:1052:6: warning: writing 1 byte into a 
> region of size 0 [-Wstringop-overflow=]
>   1052 |   *q = '\0';
>|   ~~~^~
> 
> Using gdb I have watched the pointer address stored in q and the setting of 
> the 
> string of bytes doing the binary to ascii conversion. I have also checked the 
> length of the buffer being used and its is what I would expect with length of 
> 129.
> 
> However, the warning only goes away if I add an additional 8 bytes to the 
> buffer 
> (suspicious).
> 
> So doing the following eliminates the warning:
> 
> diff --git a/libgfortran/io/write.c b/libgfortran/io/write.c
> index 4ef35561fdd..fd0e46851e4 100644
> --- a/libgfortran/io/write.c
> +++ b/libgfortran/io/write.c
> @@ -1204,7 +1204,7 @@ void
>   write_b (st_parameter_dt *dtp, const fnode *f, const char *source, int len)
>   {
> const char *p;
> -  char itoa_buf[GFC_BTOA_BUF_SIZE];
> +  char itoa_buf[GFC_BTOA_BUF_SIZE + 8];
> GFC_UINTEGER_LARGEST n = 0;
> 
> if (len > (int) sizeof (GFC_UINTEGER_LARGEST))
> 
> Any suggestions? I am certainly not seeing it.
> 

Can you just zero memory and remove the explicit setting
of the terminating '\0'?

  q = buffer;
  memset(q, 0, len);

-- 
Steve

Re: RFC: Followup to PR91593

[Steve Kargl]

On Mon, Sep 30, 2019 at 08:51:51PM -0700, Steve Kargl wrote:
> 
> Can you just zero memory and remove the explicit setting
> of the terminating '\0'?
> 
>   q = buffer;
>   memset(q, 0, len);
> 

(may be dup)

Upon further reading of the code, does buffer have
8*len+1 length?  You would need to do memset(q,0,8*len+1).

-- 
Steve