Re: gcc/DATESTAMP not updated any longer

[Martin Liška]

On 12/11/20 7:26 PM, Jakub Jelinek wrote:

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


Morning.

Unfortunately, today we have similar problem. Master was bumped, but
not any of the release branches:

commit c5853240cdae1e727a65d1300e05307e5197bc69 (origin/releases/gcc-10)
Author: GCC Administrator 
Date:   Sun Dec 13 00:16:57 2020 +

Daily bump.

Can you please Jakub redirect output of the script to a /tmp/xxx.log files?

Again, running that in dry mode is fine:

./contrib/gcc-changelog/git_update_version.py -d.
=== Working on: master ===
branch pulled and checked out
3 revisions since last Daily bump
writing to ./libstdc++-v3/ChangeLog
writing to ./gcc/ChangeLog
writing to ./gcc/testsuite/ChangeLog
branch diff written to ./master.patch
branch is done

=== Working on: releases/gcc-10 ===
branch pulled and checked out
1 revisions since last Daily bump
branch diff written to ./gcc-10.patch
branch is done

=== Working on: releases/gcc-8 ===
branch pulled and checked out
1 revisions since last Daily bump
branch diff written to ./gcc-8.patch
branch is done

=== Working on: releases/gcc-9 ===
branch pulled and checked out
1 revisions since last Daily bump
branch diff written to ./gcc-9.patch
branch is done

Thanks,
Martin

Re: gcc/DATESTAMP not updated any longer

[Jakub Jelinek via Gcc]

On Mon, Dec 14, 2020 at 09:59:22AM +0100, Martin Liška wrote:
> On 12/11/20 7:26 PM, Jakub Jelinek wrote:
> > When running it manually it just completed without problems.
> > So, no idea what happened.
> 
> Morning.
> 
> Unfortunately, today we have similar problem. Master was bumped, but
> not any of the release branches:
> 
> commit c5853240cdae1e727a65d1300e05307e5197bc69 (origin/releases/gcc-10)
> Author: GCC Administrator 
> Date:   Sun Dec 13 00:16:57 2020 +
> 
> Daily bump.
> 
> Can you please Jakub redirect output of the script to a /tmp/xxx.log files?
> 
> Again, running that in dry mode is fine:

In non-dry mode it is fine too:
$ /home/gccadmin/scripts/update_version_git
=== Working on: master ===
branch pulled and checked out
3 revisions since last Daily bump
DATESTAMP unchanged
branch is done

=== Working on: releases/gcc-10 ===
branch pulled and checked out
1 revisions since last Daily bump
DATESTAMP will be changed:
branch is pushed
branch is done

=== Working on: releases/gcc-8 ===
branch pulled and checked out
1 revisions since last Daily bump
DATESTAMP will be changed:
branch is pushed
branch is done

=== Working on: releases/gcc-9 ===
branch pulled and checked out
1 revisions since last Daily bump
DATESTAMP will be changed:
branch is pushed
branch is done

Note, last night r11 DATESTAMP bump actually succeeded, it was the other
branches that failed.

Jakub

Re: gcc/DATESTAMP not updated any longer

[Martin Liška]

On 12/14/20 10:05 AM, Jakub Jelinek wrote:

Note, last night r11 DATESTAMP bump actually succeeded, it was the other
branches that failed.


I know.

So please try to output the script output to a log. So that we can analyze
for the next time.

Thanks,
Martin

Re: gcc/DATESTAMP not updated any longer

[Jakub Jelinek via Gcc]

On Mon, Dec 14, 2020 at 10:21:15AM +0100, Martin Liška wrote:
> On 12/14/20 10:05 AM, Jakub Jelinek wrote:
> > Note, last night r11 DATESTAMP bump actually succeeded, it was the other
> > branches that failed.
> 
> I know.
> 
> So please try to output the script output to a log. So that we can analyze
> for the next time.

I've added that to the crontab, but it remains to be seen if it is the
process itself crashing, or something external killing it.

Jakub

Re: gcc/DATESTAMP not updated any longer

[Martin Liška]

On 12/14/20 10:23 AM, Jakub Jelinek wrote:

On Mon, Dec 14, 2020 at 10:21:15AM +0100, Martin Liška wrote:

On 12/14/20 10:05 AM, Jakub Jelinek wrote:

Note, last night r11 DATESTAMP bump actually succeeded, it was the other
branches that failed.


I know.

So please try to output the script output to a log. So that we can analyze
for the next time.


I've added that to the crontab, but it remains to be seen if it is the
process itself crashing, or something external killing it.


Why so?

The following should log always

0 * * * * /path/to/script.. >> /tmp/gcc-daily-bump.log 2>&1

right?

Martin



Jakub

Re: gcc/DATESTAMP not updated any longer

[Andreas Schwab]

On Dez 14 2020, Martin Liška wrote:

> On 12/11/20 7:26 PM, Jakub Jelinek wrote:
>> When running it manually it just completed without problems.
>> So, no idea what happened.
>
> Morning.
>
> Unfortunately, today we have similar problem. Master was bumped, but
> not any of the release branches:

Perhaps it was competing with an ongoing push?

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: gcc/DATESTAMP not updated any longer

[Jakub Jelinek via Gcc]

On Mon, Dec 14, 2020 at 11:02:44AM +0100, Andreas Schwab wrote:
> On Dez 14 2020, Martin Liška wrote:
> 
> > On 12/11/20 7:26 PM, Jakub Jelinek wrote:
> >> When running it manually it just completed without problems.
> >> So, no idea what happened.
> >
> > Morning.
> >
> > Unfortunately, today we have similar problem. Master was bumped, but
> > not any of the release branches:
> 
> Perhaps it was competing with an ongoing push?

Unlikely.  Because last successful commit to the repo before has been more
than 3 hours before the datestamp update time and first successful commit to
the repo after it has been more than 6 hours after it.

Jakub

Mail delivery failed: returning message to sender

[Mail Delivery System]

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  gcc@gcc.gnu.org
host gcc.gnu.org [8.43.85.97]
SMTP error from remote mail server after end of data:
550 5.7.1 Blocked by SpamAssassin
Reporting-MTA: dns; ashburn-va-datacenter.serverpoint.com

Action: failed
Final-Recipient: rfc822;gcc@gcc.gnu.org
Status: 5.0.0
Remote-MTA: dns; gcc.gnu.org
Diagnostic-Code: smtp; 550 5.7.1 Blocked by SpamAssassin

Pytest usage in DejaGNU?

[Martin Liška]

Hello.

GCOV tests suffer from tests that would cover the intermediate format.
It's a JSON format and and I'm attaching an example of its output.

I would really like to use Python to make more complex tests:

$ cat test_json.py
import pytest
import json

def test_gcov_output():
data = json.load(open('gcov.json'))
assert len(data['files']) == 1
f0 = data['files'][0]
assert f0['file'] == 'gcov-lambda.C'
assert len(f0['functions']) == 3

fns = {}
for fn in f0['functions']:
fns[fn['name']] = fn
lines = f0['lines']

for line in lines:
lineno = line['line_number']
linefn = line['function_name']
assert linefn in fns
fn = fns[linefn]
assert fn['start_line'] <= lineno and lineno <= fn['end_line']

I see it pretty complicated to do the same in DejaGNU. Mainly due the missing
JSON parser.

Would it be possible to make optional Python tests in our testsuite?
I can imagine a simple pytest wrapper that will do something like:

+proc pytest-execute { dgargs } {
+verbose "dg-pytest-execute: ${dgargs}" 2
+set script [lindex $dgargs 0]
+verbose "  script: ${script}" 2
+
+spawn -noecho pytest -rA -s --tb=no $script
+
+expect {
+  -re "FAILED .*" {
+   fail "pytest $expect_out(0,string)"
+  }
+  -re "PASSED .*" {
+   pass "pytest $expect_out(0,string)"
+  }
+}
+}

as Pytest can provide a reasonable close output:

===
 short test summary info 

PASSED test_json.py::test_gcov_output
PASSED test_json.py::test_gcov_output
PASSED test_json.py::test_gcov_output

Thoughts?
Martin


gcov.json
Description: application/json

Re: [EXTERNAL]Re: MIPS Maintainer

[Chao-ying Fu]

Hi Maciej,

> > >  Well, it's up to the GCC steering committee really to appoint 
> > > maintainers 
> > > , however you can post patches and 
> > > help 
> > > with getting reviews through right away.  There hasn't been much traffic 
> > > with the MIPS port recently, but there has been some and it always helps 
> > > to have someone provide input.
> > 
> >   I got David Edelsohn's email and replied to him yesterday.
> > We have some small tweaks in GCC and can send the patches.

>  Please note that GCC is in Stage 3 as from Nov 16th, so if these are bug 
> fixes, then they may still qualify for inclusion with the upcoming GCC 11 
> release expected May-ish next year, but you need to hurry and submit them 
> ASAP.  Otherwise you'll have to wait until trunk reopens for general 
> development around the time of the release.

>  See:  for the release pattern and: 
>  for the most 
> recent status (always linked from the:  home page).

> > There is a big patch for nanoMIPS that stays as-is for long time.
> > It will take time to get the patch working against the latest code base,
> > if the community wants to include nanoMIPS in GCC.

 > I am glad this has not been lost, contrary to the fears I have expressed 
> in a discussion on the MIPS/NetBSD mailing list as recently as last week.

  It's great to know.

>  This is however a major new feature, so it will definitely have to wait 
> for Stage 1.  You may post the patch(es) regardless, however they may not 
> attract much attention as people are busy with QA for GCC 11, especially 
> as in the current situation it is likely it will have to be a general 
> maintainer to approve such a change.  Mind that given how it has been 
> defined the nanoMIPS ISA might be considered an entirely new port/platform 
> though it will depend on how the support for it has been wired into GCC (I 
> don't know the details myself, I wasn't following that development).

>  Also you will have to have binutils support approved and committed first, 
> and given their semiannual release schedule you may well start working on 
> a submission right away, so that at least you have a chance to have that 
> included with the Jul 2021 release (surely you won't make it for the Jan 
> 2021 one).

>  David has kindly explained the rest: just post the changes and have them 
> reviewed, and it's up to the community to decide if a new maintainer is 
> required and if so, who will that be.

  Yes, we will submit patches to get reviewed. Let the community decide if a 
new MIPS maintainer is needed.

>  And last but not least, please make sure you are covered by a copyright 
> assignment with FSF under your current employment.

  Yes, I will try to get a copyright assignment with FSF under Wave Computing.
My old ssh key is not working to clone GCC or Binutils git. I will need some 
help, later.

  Thanks a lot!

Regards,
Chao-ying

Re: Pytest usage in DejaGNU?

[Jeff Law via Gcc]

On 12/14/20 9:02 AM, Martin Liška wrote:
> Hello.
>
> GCOV tests suffer from tests that would cover the intermediate format.
> It's a JSON format and and I'm attaching an example of its output.
>
> I would really like to use Python to make more complex tests:
>
> $ cat test_json.py
> import pytest
> import json
>
> def test_gcov_output():
>     data = json.load(open('gcov.json'))
>     assert len(data['files']) == 1
>     f0 = data['files'][0]
>     assert f0['file'] == 'gcov-lambda.C'
>     assert len(f0['functions']) == 3
>
>     fns = {}
>     for fn in f0['functions']:
>     fns[fn['name']] = fn
>     lines = f0['lines']
>
>     for line in lines:
>     lineno = line['line_number']
>     linefn = line['function_name']
>     assert linefn in fns
>     fn = fns[linefn]
>     assert fn['start_line'] <= lineno and lineno <= fn['end_line']
>
> I see it pretty complicated to do the same in DejaGNU. Mainly due the
> missing
> JSON parser.
>
> Would it be possible to make optional Python tests in our testsuite?
> I can imagine a simple pytest wrapper that will do something like:
>
> +proc pytest-execute { dgargs } {
> +    verbose "dg-pytest-execute: ${dgargs}" 2
> +    set script [lindex $dgargs 0]
> +    verbose "  script: ${script}" 2
> +
> +    spawn -noecho pytest -rA -s --tb=no $script
> +
> +    expect {
> +  -re "FAILED .*" {
> +   fail "pytest $expect_out(0,string)"
> +  }
> +  -re "PASSED .*" {
> +   pass "pytest $expect_out(0,string)"
> +  }
> +    }
> +}
>
> as Pytest can provide a reasonable close output:
>
> ===
> short test summary info
> 
> PASSED test_json.py::test_gcov_output
> PASSED test_json.py::test_gcov_output
> PASSED test_json.py::test_gcov_output
I thought we already approved using python elsewhere (JIT?  Analyzer?)

jeff

Re: cacheflush.2

[Martin Sebor via Gcc]

On 12/11/20 11:14 AM, Alejandro Colomar (man-pages) via Gcc wrote:

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 *'.


__builtin___clear_cache in GCC has always been declared to take
void*.  The signature in the manual was recently corrected to match
the implementation, i.e., from char* to void*, in r269082.

Martin


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

Re: Pytest usage in DejaGNU?

[Joseph Myers]

On Mon, 14 Dec 2020, Martin Liška wrote:

> +spawn -noecho pytest -rA -s --tb=no $script

"pytest" might not be the right command everywhere.  If I install 
python3-pytest on Ubuntu 20.04 I only get /usr/bin/pytest-3 not 
/usr/bin/pytest.

There is a clear advantage to any usage of Python only depending on the 
standard library and not other Python packages.

> PASSED test_json.py::test_gcov_output
> PASSED test_json.py::test_gcov_output
> PASSED test_json.py::test_gcov_output

The names after "PASS: " or "FAIL: " in DejaGnu output should be unique 
(and not depend on whether the test in question passes or fails, or on 
variables such as the build directory); there should not be three tests 
with the same name.

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

Re: Pytest usage in DejaGNU?

[Matthias Klose]

On 12/14/20 10:21 PM, Joseph Myers wrote:
> On Mon, 14 Dec 2020, Martin Liška wrote:
> 
>> +spawn -noecho pytest -rA -s --tb=no $script
> 
> "pytest" might not be the right command everywhere.  If I install 
> python3-pytest on Ubuntu 20.04 I only get /usr/bin/pytest-3 not 
> /usr/bin/pytest.

 -m pytest should work everywhere.

Re: cacheflush.2

[Alejandro Colomar (man-pages) via Gcc]

Hello Martin,

Thanks for the correction!
Then the prototypes that changes from 'char *' to 'void *' in r269082
were not exposed to the user, right?
I guess then those are just internal implementation where GCC did use
'char *'.

Where is the actual prototype exposed to the user declared?

Thanks,

Alex

P.S.: Michael, wait for a patch revision (v6).

On 12/14/20 10:13 PM, Martin Sebor wrote:
> On 12/11/20 11:14 AM, Alejandro Colomar (man-pages) via Gcc wrote:
>> 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 *'.
> 
> __builtin___clear_cache in GCC has always been declared to take
> void*.  The signature in the manual was recently corrected to match
> the implementation, i.e., from char* to void*, in r269082.
> 
> Martin
> 
>> 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

Re: gcc/DATESTAMP not updated any longer

[Joseph Myers]

On Fri, 11 Dec 2020, 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).

https://gcc.gnu.org/pipermail/gccadmin/2020q4/017037.html

OSError: [Errno 28] No space left on device: 
'/tmp/tmp.Zq3p6D4MxS/gcc/.git/objects/objn31xpefh' -> 
'/tmp/tmp.Zq3p6D4MxS/gcc/.git/objects/db/ffb02a4bcdd4ec04af3db75d86b8cc2e52bdff'

Maybe change the script to use /sourceware/snapshot-tmp/gcc (which has 
rather more space) instead of /tmp?

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

Re: gcc/DATESTAMP not updated any longer

[Joseph Myers]

On Mon, 14 Dec 2020, Martin Liška wrote:

> On 12/11/20 7:26 PM, Jakub Jelinek wrote:
> > When running it manually it just completed without problems.
> > So, no idea what happened.
> 
> Morning.
> 
> Unfortunately, today we have similar problem. Master was bumped, but
> not any of the release branches:

https://gcc.gnu.org/pipermail/gccadmin/2020q4/017046.html

FileNotFoundError: [Errno 2] No such file or directory: 
'/tmp/tmp.k6tFzmcsug/gcc/.git/objects/objb2sgga3i' -> 
'/tmp/tmp.k6tFzmcsug/gcc/.git/objects/06/788005095bcff66279c3254e910d934941ca9d'

No idea why the Python git implementation apparently being used by this 
code would produce such an error.

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