Re: RFC v2: Re: cacheflush.2

[Michael Kerrisk (man-pages) via Gcc]

i Alex,

On 12/10/20 9:56 PM, Alejandro Colomar (man-pages) wrote:
> Hi all,
> 
> v2:
> 
> [
> NOTES
>Unless  you  need  the finer grained control that this system
>call provides, you probably want  to  use  the  GCC  built-in
>function  __builtin___clear_cache(),  which  provides  a more
>portable interface:
> 
>void __builtin___clear_cache(void *begin, void *end);
> ]

This seems a reasonable text to me, but I think it would be helpful
to say a little more precisely what kind of portability we are
talking about here.

Greater ortability across Linux architectures? Greater portability
across platforms supported by GCC (including non-Linux) platforms?
Something else?

Thanks,

Michael


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Re: Integer division on x86 -m32

[Andrew Haley via Gcc]

On 11/12/2020 07:12, Marc Glisse wrote:
> On Thu, 10 Dec 2020, Lucas de Almeida via Gcc wrote:
> 
>> when performing (int64_t) foo / (int32_t) bar in gcc under x86, a call to
>> __divdi3 is always output, even though it seems the use of the idiv
>> instruction could be faster.
> 
> IIRC, idiv requires that the quotient fit in 32 bits, while your C code 
> doesn't. (1LL << 60) / 3 would cause an error with idiv.

Isn't that an integer overflow, which is undefined behaviour?

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. 
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: The conditions when convert from double to float is permitted?

[Xionghu Luo via Gcc]

On 2020/12/11 15:47, Richard Biener wrote:
>> Note that the add/sub sequence is different for (3) and (4) since
>> -funsafe-math-optimizations is implicitly true.  "fp-contract=fast" in
>> (1) and (2) could avoid Inf as fmads could handle float overflow (verified
>> it on Power, not sure other targets support this), but without float
>> value-range info, it is unsafe to change computation from double to
>> float even for only add/sub expressions.
> Yes.  As said it's difficult to second guess the programmer here.
> The existing cases doing promotion look at unary functions,
> doing exp->expf when arguments are promoted floats and the
> return value is casted back to float.  That's also a common programmer
> "error" not knowing expf or assuming some kind of magic overloading.

Yes, that is "(float) fabs (float)" -> "(float) fabsf (float)" as (1), 
that seems should be done in front end to generate fabsf or "warning" to 
programmer? 
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326#c4, refused by Andew and 
Joseph,
reason is front end shouldn't do any optimization there.)

Currently, gimple code already generates below code(though no ABSF_EXPR or 
EXPF_EXPR),
but due to ABS_EXPR return double, many double conversions are also produced
for the MUL and ADD operations, and that why I propose to do it in match.pd.
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326#c9, also refused by you due 
to
complex static pattern matching, also it will cause potential Inf issue like 
last mail.)

1) cat liv.c.006t.gimple
__attribute__((noinline))
foo (float x, float y, float z)
{
  float D.4356;

  _1 = ABS_EXPR ;
  _2 = (double) _1;
  _3 = (double) y;
  _4 = _2 * _3;
  _5 = (double) z;
  _6 = _4 + _5;
  D.4356 = (float) _6;
  return D.4356;
}

For "(float) fabs (double)" like (2), it is not quite reasonable to do fabs -> 
fabsf.

2) cat liv.c.006t.gimple
__attribute__((noinline))
foo (double x, float y, float z)
{
  float D.4356;

  _1 = ABS_EXPR ;
  _2 = (double) y;
  _3 = _1 * _2;
  _4 = (double) z;
  _5 = _3 + _4;
  D.4356 = (float) _5;
  return D.4356;
}

>
> So I'm not entirely convinced such transform is a good idea, at least
> by default with -ffast-math.  Maybe have a -fassume-float-limited-range
> or so documented as that we assume that double or long double values
> used fit in floats?

Thanks for the idea, just to confirm where should this option work,  In match.pd
or gimple pass for only abs/exp to absf/expf, etc?  Even with the option, I am
afraid the option is still not effective for computation? 


Thanks,
Xionghu

Re: The conditions when convert from double to float is permitted?

[Xionghu Luo via Gcc]

On 2020/12/11 15:47, Richard Biener wrote:
>> Note that the add/sub sequence is different for (3) and (4) since
>> -funsafe-math-optimizations is implicitly true.  "fp-contract=fast" in
>> (1) and (2) could avoid Inf as fmads could handle float overflow (verified
>> it on Power, not sure other targets support this), but without float
>> value-range info, it is unsafe to change computation from double to
>> float even for only add/sub expressions.
> Yes.  As said it's difficult to second guess the programmer here.
> The existing cases doing promotion look at unary functions,
> doing exp->expf when arguments are promoted floats and the
> return value is casted back to float.  That's also a common programmer
> "error" not knowing expf or assuming some kind of magic overloading.

Yes, that is "(float) fabs (float)" -> "(float) fabsf (float)" as (1), 
that seems should be done in front end to generate fabsf or "warning" to 
programmer? 
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326#c4, refused by Andew and 
Joseph,
reason is front end shouldn't do any optimization there.)

Currently, gimple code already generates below code(though no ABSF_EXPR or 
EXPF_EXPR),
but due to ABS_EXPR return double, many double conversions are also produced
for the MUL and ADD operations, and that why I propose to do it in match.pd.
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326#c9, also refused by you due 
to
complex static pattern matching, also it will cause potential Inf issue like 
last mail.)

1) cat liv.c.006t.gimple
__attribute__((noinline))
foo (float x, float y, float z)
{
  float D.4356;

  _1 = ABS_EXPR ;
  _2 = (double) _1;
  _3 = (double) y;
  _4 = _2 * _3;
  _5 = (double) z;
  _6 = _4 + _5;
  D.4356 = (float) _6;
  return D.4356;
}

For "(float) fabs (double)" like (2), it is not quite reasonable to do fabs -> 
fabsf.

2) cat liv.c.006t.gimple
__attribute__((noinline))
foo (double x, float y, float z)
{
  float D.4356;

  _1 = ABS_EXPR ;
  _2 = (double) y;
  _3 = _1 * _2;
  _4 = (double) z;
  _5 = _3 + _4;
  D.4356 = (float) _5;
  return D.4356;
}

> 
> So I'm not entirely convinced such transform is a good idea, at least
> by default with -ffast-math.  Maybe have a -fassume-float-limited-range
> or so documented as that we assume that double or long double values
> used fit in floats?

Thanks for the idea, just to confirm where should this option work,  In match.pd
or gimple pass for only abs/exp to absf/expf, etc?  Even with the option, I am
afraid the option is still not effective for computation? :)


Thanks,
Xionghu

Re: The conditions when convert from double to float is permitted?

[Richard Biener via Gcc]

On Fri, Dec 11, 2020 at 10:44 AM Xionghu Luo  wrote:
>
>
> On 2020/12/11 15:47, Richard Biener wrote:
> >> Note that the add/sub sequence is different for (3) and (4) since
> >> -funsafe-math-optimizations is implicitly true.  "fp-contract=fast" in
> >> (1) and (2) could avoid Inf as fmads could handle float overflow (verified
> >> it on Power, not sure other targets support this), but without float
> >> value-range info, it is unsafe to change computation from double to
> >> float even for only add/sub expressions.
> > Yes.  As said it's difficult to second guess the programmer here.
> > The existing cases doing promotion look at unary functions,
> > doing exp->expf when arguments are promoted floats and the
> > return value is casted back to float.  That's also a common programmer
> > "error" not knowing expf or assuming some kind of magic overloading.
>
> Yes, that is "(float) fabs (float)" -> "(float) fabsf (float)" as (1),
> that seems should be done in front end to generate fabsf or "warning" to 
> programmer?
> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326#c4, refused by Andew and 
> Joseph,
> reason is front end shouldn't do any optimization there.)
>
> Currently, gimple code already generates below code(though no ABSF_EXPR or 
> EXPF_EXPR),
> but due to ABS_EXPR return double, many double conversions are also produced
> for the MUL and ADD operations, and that why I propose to do it in match.pd.
> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326#c9, also refused by you 
> due to
> complex static pattern matching, also it will cause potential Inf issue like 
> last mail.)
>
> 1) cat liv.c.006t.gimple
> __attribute__((noinline))
> foo (float x, float y, float z)
> {
>   float D.4356;
>
>   _1 = ABS_EXPR ;
>   _2 = (double) _1;
>   _3 = (double) y;
>   _4 = _2 * _3;
>   _5 = (double) z;
>   _6 = _4 + _5;
>   D.4356 = (float) _6;
>   return D.4356;
> }
>
> For "(float) fabs (double)" like (2), it is not quite reasonable to do fabs 
> -> fabsf.

what's the error case you are worried about in this particular case?

> 2) cat liv.c.006t.gimple
> __attribute__((noinline))
> foo (double x, float y, float z)
> {
>   float D.4356;
>
>   _1 = ABS_EXPR ;
>   _2 = (double) y;
>   _3 = _1 * _2;
>   _4 = (double) z;
>   _5 = _3 + _4;
>   D.4356 = (float) _5;
>   return D.4356;
> }
>
> >
> > So I'm not entirely convinced such transform is a good idea, at least
> > by default with -ffast-math.  Maybe have a -fassume-float-limited-range
> > or so documented as that we assume that double or long double values
> > used fit in floats?
>
> Thanks for the idea, just to confirm where should this option work,  In 
> match.pd
> or gimple pass for only abs/exp to absf/expf, etc?  Even with the option, I am
> afraid the option is still not effective for computation?

I still think that covering all "good" cases in match.pd will require excessive
matching and that it is better done in a pass (this would include removing
the frontend handling for math functions).  Note that for example
(float)((double)x + (double)y) with float x and y is also eligible to demotion
to float, likewise may some compositions like
(float)(sin((double)x)*cos ((double)y))
for float x and y since we can constrain ranges here.  Likewise
(float)((double)x + fabs ((double)y)) for float x and y.  The
propagation would need
to stop when the range needed increases in unknown ways.

>
> Thanks,
> Xionghu
>
>

Re: Integer division on x86 -m32

[Alexander Monakov via Gcc]

On Fri, 11 Dec 2020, Andrew Haley via Gcc wrote:

> On 11/12/2020 07:12, Marc Glisse wrote:
> > On Thu, 10 Dec 2020, Lucas de Almeida via Gcc wrote:
> > 
> >> when performing (int64_t) foo / (int32_t) bar in gcc under x86, a call to
> >> __divdi3 is always output, even though it seems the use of the idiv
> >> instruction could be faster.
> > 
> > IIRC, idiv requires that the quotient fit in 32 bits, while your C code 
> > doesn't. (1LL << 60) / 3 would cause an error with idiv.
> 
> Isn't that an integer overflow, which is undefined behaviour?

No, see my other response in this thread. The division happens in type 'int64_t'
aka 'long long' (no overflow), and then int64_t result is converted to int32_t
in an implementation-defined manner (without UB).

Generally speaking an implementation-defined signal may be raised if the result
would not fit in int32_t, but GCC defines the behavior as bitwise truncation
in all cases.

Alexander

Re: gcc/DATESTAMP not updated any longer

[Rainer Orth]

Rainer Orth  writes:

> I noticed that gcc/DATESTAMP isn't updated any longer after this
> Friday.  I doubt this is intentional...

This has happened again tonight...

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: The conditions when convert from double to float is permitted?

[Segher Boessenkool]

On Fri, Dec 11, 2020 at 03:54:44PM +0800, Xionghu Luo wrote:
> +cc.
> 
> 
> On 2020/12/11 14:25, Xionghu Luo via Gcc wrote:
> >Thanks,
> >
> >On 2020/12/10 17:12, Richard Biener wrote:
> >>>2) From PR90070:
> >>>
> >>>double temp1 = (double)r->red;
> >>>double temp2 = (double)aggregate.red;
> >>>double temp3 = temp2 + (temp1 * 5.0);
> >>temp1 * 5 could be not representable in float but the
> >>result of the add could so the transform could result
> >>in -+Inf where the original computation was fine (but
> >>still very large result).

Since both "red"s here are unsigned 16-bit integers, the result fits in
an unsigned 19-bit integer, so both SP float and integer calculations
woould work just fine here.

> >>Usually in such cases one could say we should implement some
> >>diagnostic hints to the user that he might consider refactoring
> >>his code to use float computations because we cannot really say
> >>whether it's safe (we do at the moment not implement value-range
> >>propagation for floating point types).
> >>
> >
> >foo (double x, float y, float z)
> >   {
> >   return ( fabs (x) * y - z ) ;
> >   }

Since x is double, you have to do this all in double precision, even with
-ffast-math!  The subtraction could do catastrophic cancellation.

> >But the add/sub could also produces INF similarly,
> >
> >   foo (double x, float y, float z)
> >   {
> >  return ( -fabs (x) + y + z ) ;
> >   }

Here you can lose on the order of just a single bit, so it is okay to do
all this in single precision with -ffast-math.

> >Note that the add/sub sequence is different for (3) and (4) since
> >-funsafe-math-optimizations is implicitly true.  "fp-contract=fast" in
> >(1) and (2) could avoid Inf as fmads could handle float overflow (verified
> >it on Power, not sure other targets support this), but without float
> >value-range info, it is unsafe to change computation from double to
> >float even for only add/sub expressions.

Yeah exactly.


Segher

Re: The conditions when convert from double to float is permitted?

[Segher Boessenkool]

On Fri, Dec 11, 2020 at 05:38:30PM +0800, Xionghu Luo wrote:
> On 2020/12/11 15:47, Richard Biener wrote:
> >> Note that the add/sub sequence is different for (3) and (4) since
> >> -funsafe-math-optimizations is implicitly true.  "fp-contract=fast" in
> >> (1) and (2) could avoid Inf as fmads could handle float overflow (verified
> >> it on Power, not sure other targets support this), but without float
> >> value-range info, it is unsafe to change computation from double to
> >> float even for only add/sub expressions.
> > Yes.  As said it's difficult to second guess the programmer here.
> > The existing cases doing promotion look at unary functions,
> > doing exp->expf when arguments are promoted floats and the
> > return value is casted back to float.  That's also a common programmer
> > "error" not knowing expf or assuming some kind of magic overloading.
> 
> Yes, that is "(float) fabs (float)" -> "(float) fabsf (float)" as (1), 
> that seems should be done in front end to generate fabsf or "warning" to 
> programmer? 

Doing it in the frontend means we'll have to do it in every frontend
separately.  This optimisation is valid in any language.

> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326#c4, refused by Andew and 
> Joseph,
> reason is front end shouldn't do any optimization there.)

Yeah.  It currently *does* in many cases, but that is bad architecture.

> For "(float) fabs (double)" like (2), it is not quite reasonable to do fabs 
> -> fabsf.

It brings no benefit to have fabsf over fabs insns, either.


Segher

Re: RFC v2: Re: cacheflush.2

[Alejandro Colomar (man-pages) via Gcc]

Hi Michael,

On 12/11/20 9:15 AM, Michael Kerrisk (man-pages) wrote:
> i Alex,
> 
> On 12/10/20 9:56 PM, Alejandro Colomar (man-pages) wrote:
>> Hi all,
>>
>> v2:
>>
>> [
>> NOTES
>>Unless  you  need  the finer grained control that this system
>>call provides, you probably want  to  use  the  GCC  built-in
>>function  __builtin___clear_cache(),  which  provides  a more
>>portable interface:
>>
>>void __builtin___clear_cache(void *begin, void *end);
>> ]
> 
> This seems a reasonable text to me, but I think it would be helpful
> to say a little more precisely what kind of portability we are
> talking about here.
Sure.

> 
> Greater ortability across Linux architectures? Greater portability
> across platforms supported by GCC (including non-Linux) platforms?
> Something else?

'... which provides a portable interface across platforms supported by
GCC:' sounds good.

Maybe GCC devs have something more to add.

Thanks,

Alex

> 
> Thanks,
> 
> Michael
> 
> 

-- 
Alejandro Colomar
Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es

Re: gcc/DATESTAMP not updated any longer

[Martin Liška]

On 12/11/20 2:17 PM, Rainer Orth wrote:

Rainer Orth  writes:


I noticed that gcc/DATESTAMP isn't updated any longer after this
Friday.  I doubt this is intentional...


This has happened again tonight...

Rainer



Thanks for heads up. I'm aware of it and I don't see reason why (running the
update script in dry mode works).

@Jakub: Can you please take a look?

Thanks,
Martin

Re: cacheflush.2

[Alejandro Colomar (man-pages) via Gcc]

It looks like GCC recently moved from 'char *' to 'void *'.
This SO question[1] (4 years ago) quotes the GCC docs
and they had 'char *'.
Maybe Clang hasn't noticed the change.
I'll report a bug.

[1]: https://stackoverflow.com/q/35741814/6872717

On 12/9/20 8:15 PM, Alejandro Colomar (man-pages) wrote:
> Hi Heinrich,
> 
> It looks like a bug (or at least an undocumented divergence from GCC) in
> Clang/LLVM.  Or I couldn't find the documentation for it.
> 
> Clang uses 'char *':
> https://github.com/llvm/llvm-project/blob/7faf62a80bfc3a9dfe34133681fcc31f8e8d658b/clang/include/clang/Basic/Builtins.def#L583
> 
> GCC uses 'void *':
> https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html
> 
> I CCd Clang and GCC lists; maybe they know about that divergence.
> 
> Cheers,
> 
> Alex
> 
> On 12/9/20 7:48 PM, Heinrich Schuchardt wrote:
>> On 12/9/20 7:34 PM, Alejandro Colomar (man-pages) wrote:
>>> Hi Heinrich & Michael,
>>>
>>> What about the following?:
>>>
>>> [
>>> NOTES
>>>     GCC provides a similar function, which may be useful on  archi‐
>>>     tectures that lack this system call:
>>>
>>>     void __builtin___clear_cache(void *begin, void *end);
>>> ]
>>
>> I just checked building with Clang/LLVM. There the arguments are of type
>> (char *). See the following error output:
>>
>> +arch/sandbox/cpu/cache.c:19:26: error: passing 'uint8_t *' (aka
>> 'unsigned char *') to parameter of type 'char *' converts between
>> pointers to integer types with different sign [-Werror,-Wpointer-sign]
>> +    __builtin___clear_cache(state->ram_buf,
>> +    ^~
>> +arch/sandbox/cpu/cache.c:20:12: error: passing 'uint8_t *' (aka
>> 'unsigned char *') to parameter of type 'char *' converts between
>> pointers to integer types with different sign [-Werror,-Wpointer-sign]
>> +    state->ram_buf + state->ram_size);
>> +    ^~~~
>>
>> Best regards
>>
>> Heinrich
>>
>>>
>>> Cheers,
>>>
>>> Alex
>>>
>>> On 12/9/20 7:04 PM, Heinrich Schuchardt wrote:
 Hello Michael,

 function cacheflush() does not exist on many architectures.

 It would have saved me a lot of time if the man-page had referenced
 GCC's

 void __builtin___clear_cache(void *begin, void *end)

 Maybe you can add it to NOTES.

 Best regards

 heirnich
>>>
>>
> 

-- 
Alejandro Colomar
Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es

RFC v3: Re: cacheflush.2

[Alejandro Colomar (man-pages) via Gcc]

Hi all,

Please review this text:

[
NOTES
   Unless  you  need  the finer grained control that this system
   call provides, you probably want  to  use  the  GCC  built-in
   function  __builtin___clear_cache(),  which  provides  a more
   portable interface:

   void __builtin___clear_cache(void *begin, void *end);

   On platforms that don't require  instruction  cache  flushes,
   __builtin___clear_cache() has no effect.

   Note:  On  some  GCC-compatible compilers, such as clang, the
   prototype for this function uses char * instead of void *.
]

Thanks,

Alex

On 12/11/20 7:02 PM, Alejandro Colomar (man-pages) wrote:
> Hi Michael,
> 
> On 12/11/20 9:15 AM, Michael Kerrisk (man-pages) wrote:
>> i Alex,
>>
>> On 12/10/20 9:56 PM, Alejandro Colomar (man-pages) wrote:
>>> Hi all,
>>>
>>> v2:
>>>
>>> [
>>> NOTES
>>>Unless  you  need  the finer grained control that this system
>>>call provides, you probably want  to  use  the  GCC  built-in
>>>function  __builtin___clear_cache(),  which  provides  a more
>>>portable interface:
>>>
>>>void __builtin___clear_cache(void *begin, void *end);
>>> ]
>>
>> This seems a reasonable text to me, but I think it would be helpful
>> to say a little more precisely what kind of portability we are
>> talking about here.
> Sure.
> 
>>
>> Greater ortability across Linux architectures? Greater portability
>> across platforms supported by GCC (including non-Linux) platforms?
>> Something else?
> 
> '... which provides a portable interface across platforms supported by
> GCC:' sounds good.
> 
> Maybe GCC devs have something more to add.

> 
> Thanks,
> 
> Alex
> 
>>
>> Thanks,
>>
>> Michael
>>
>>
> 

-- 
Alejandro Colomar
Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es

RFC v4: Re: cacheflush.2

[Alejandro Colomar (man-pages) via Gcc]

I forgot to add a junk to the text.

v4:

NOTES
   Unless  you  need  the finer grained control that this system
   call provides, you probably want  to  use  the  GCC  built-in
   function __builtin___clear_cache(), which provides a portable
   interface across platforms supported by  GCC  and  compatible
   compilers:

//Maybe 'and compatible compilers' is redundant and I should remove it?

   void __builtin___clear_cache(void *begin, void *end);

   On  platforms  that  don't require instruction cache flushes,
   __builtin___clear_cache() has no effect.

   Note: On some GCC-compatible compilers, such  as  clang,  the
   prototype for this function uses char * instead of void *.


On 12/11/20 7:22 PM, Alejandro Colomar (man-pages) wrote:
> Hi all,
> 
> Please review this text:
> 
> [
> NOTES
>Unless  you  need  the finer grained control that this system
>call provides, you probably want  to  use  the  GCC  built-in
>function  __builtin___clear_cache(),  which  provides  a more
>portable interface:
> 
>void __builtin___clear_cache(void *begin, void *end);
> 
>On platforms that don't require  instruction  cache  flushes,
>__builtin___clear_cache() has no effect.
> 
>Note:  On  some  GCC-compatible compilers, such as clang, the
>prototype for this function uses char * instead of void *.
> ]
> 
> Thanks,
> 
> Alex
> 
> On 12/11/20 7:02 PM, Alejandro Colomar (man-pages) wrote:
>> Hi Michael,
>>
>> On 12/11/20 9:15 AM, Michael Kerrisk (man-pages) wrote:
>>> i Alex,
>>>
>>> On 12/10/20 9:56 PM, Alejandro Colomar (man-pages) wrote:
 Hi all,

 v2:

 [
 NOTES
Unless  you  need  the finer grained control that this system
call provides, you probably want  to  use  the  GCC  built-in
function  __builtin___clear_cache(),  which  provides  a more
portable interface:

void __builtin___clear_cache(void *begin, void *end);
 ]
>>>
>>> This seems a reasonable text to me, but I think it would be helpful
>>> to say a little more precisely what kind of portability we are
>>> talking about here.
>> Sure.
>>
>>>
>>> Greater ortability across Linux architectures? Greater portability
>>> across platforms supported by GCC (including non-Linux) platforms?
>>> Something else?
>>
>> '... which provides a portable interface across platforms supported by
>> GCC:' sounds good.
>>
>> Maybe GCC devs have something more to add.
> 
>>
>> Thanks,
>>
>> Alex
>>
>>>
>>> Thanks,
>>>
>>> Michael
>>>
>>>
>>
> 

-- 
Alejandro Colomar
Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es

Re: gcc/DATESTAMP not updated any longer

[Jakub Jelinek via Gcc]

On Fri, Dec 11, 2020 at 07:04:28PM +0100, Martin Liška wrote:
> On 12/11/20 2:17 PM, Rainer Orth wrote:
> > Rainer Orth  writes:
> > 
> > > I noticed that gcc/DATESTAMP isn't updated any longer after this
> > > Friday.  I doubt this is intentional...
> > 
> > This has happened again tonight...
> > 
> > Rainer
> > 
> 
> Thanks for heads up. I'm aware of it and I don't see reason why (running the
> update script in dry mode works).
> 
> @Jakub: Can you please take a look?

When running it manually it just completed without problems.
So, no idea what happened.

Jakub

gcc-9-20201211 is now available

[GCC Administrator via Gcc]

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

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

You'll find:

 gcc-9-20201211.tar.xzComplete GCC

  SHA256=2ea4feabefd8be3f09a96256131dd49edc8367f3aa014c03a2b47b9d18604c1c
  SHA1=7363f4b6f4d535865ae699485619a66925932588

Diffs from 9-20201204 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-9
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.