Attendance, Leave, Employee On-boarding, Payroll Software | Demo

[Arpit Singh via Gcc]

Hello! Hope you're doing great!

I just wanted to check in case you are looking for an HR automation tool. We
have an HRMS capable of automating all the functions of the HR department.

The system can help the organization automate the mentioned functions:
Attendance, Leave, Employee On-boarding, Payroll, Expenses, and Separation
etc...

Let us know if you are interested. We would be happy to schedule an Online
DEMO for the same, we require the following details:

Date & Time, Company Size, Company Website and Contact no.

Looking forward to your reply.

Thank you
HR Manager

Re: Odd Python errors in the G++ testsuite

[Maciej W. Rozycki]

Hi Ben,

 This has fallen between the cracks.

On Mon, 9 Oct 2023, Ben Boeckel wrote:

> On Mon, Oct 09, 2023 at 20:12:01 +0100, Maciej W. Rozycki wrote:
> >  I'm seeing these tracebacks for several cases across the G++ testsuite:
> > 
> > Executing on host: python3 -c "import sys; assert sys.version_info >= (3, 
> > 6)"(timeout = 300)
> > spawn -ignore SIGHUP python3 -c import sys; assert sys.version_info >= (3, 
> > 6)
> 
> What version of Python3 do you have? The test suite might not actually
> properly handle not having 3.7 (i.e., skip the tests that require it).

 One system has:

$ python3 --version
Python 3.10.12
$ 

and the other has:

$ python3 --version
Python 3.9.2
$ 

-- are these correct versions?

> > rules/0/primary-output is ok: p1689-1.o
> 
> I wrote these tests.

 Ack.

> > rules/0/provides/0/logical-name is ok: foo
> > rules/0/provides/0/is-interface is ok: True
> > Traceback (most recent call last):
> >   File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 218, in 
> > 
> > is_ok = validate_p1689(actual, expect)
> >   File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 182, in 
> > validate_p1689
> > return compare_json([], actual_json, expect_json)
> >   File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 145, in 
> > compare_json
> > is_ok = _compare_object(path, actual, expect)
> >   File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 66, in 
> > _compare_object
> > sub_error = compare_json(path + [key], actual[key], expect[key])
> >   File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 151, in 
> > compare_json
> > is_ok = _compare_array(path, actual, expect)
> >   File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 87, in 
> > _compare_array
> > sub_error = compare_json(path + [str(idx)], a, e)
> >   File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 145, in 
> > compare_json
> > is_ok = _compare_object(path, actual, expect)
> >   File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 66, in 
> > _compare_object
> > sub_error = compare_json(path + [key], actual[key], expect[key])
> >   File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 149, in 
> > compare_json
> > actual = set(actual)
> > TypeError: unhashable type: 'dict'
> 
> I'm not sure how this ends up with a dictionary in it… Can you
> `print(actual)` before this?

 I'll see if I can still reproduce the issue and add some diagnostics if 
so.

> > and also these intermittent failures for other cases:
> > 
> > Executing on host: python3 -c "import sys; assert sys.version_info >= (3, 
> > 6)"(timeout = 300)
> > spawn -ignore SIGHUP python3 -c import sys; assert sys.version_info >= (3, 
> > 6)
> > rules/0/primary-output is ok: p1689-2.o
> > rules/0/provides/0/logical-name is ok: foo:part1
> > rules/0/provides/0/is-interface is ok: True
> > ERROR: length mismatch at rules/0/requires: actual: "1" expect: "0"
> > version is ok: 0
> > revision is ok: 0
> > FAIL: ERROR: length mismatch at rules/0/requires: actual: "1" expect: "0"
> > 
> > This does seem to me like something not working as intended.  As a Python 
> > non-expert I have troubles concluding what is going on here and whether 
> > these tracebacks are indeed supposed to be there, or whether it is a sign 
> > of a problem.  And these failures I don't even know where they come from.  
> > 
> >  Does anyone know?  Is there a way to run the offending commands by hand?  
> > The relevant invocation lines do not appear in the test log file for one 
> > to copy and paste, which I think is not the right way of doing things in 
> > our environment.
> > 
> >  These issues seem independent from the test host environment as I can see 
> > them on both a `powerpc64le-linux-gnu' and an `x86_64-linux-gnu' machine 
> > in `riscv64-linux-gnu' target testing.
> 
> Do they all have pre-3.7 Python3 versions?

 None of them, as noted above.

  Maciej

Re: [Patch, stage-1, RFC]: i386: attribute regparm/stdcall and vaargs

[Bernhard Reutner-Fischer via Gcc]

Hi Joseph!

On Tue, 30 Jan 2024 14:54:49 + (UTC)
Joseph Myers  wrote:

> On Tue, 30 Jan 2024, Bernhard Reutner-Fischer via Gcc wrote:
> 
> > * builtin-attrs.def (ATTR_TM_NOTHROW_RT_LIST): Use ATTR_NOTHROW_LIST
> > instead of ATTR_TM_NOTHROW_LIST, thus removing ATTR_TM_REGPARM.  
> 
> That doesn't make sense.  ATTR_TM_NOTHROW_RT_LIST is specifically a 
> transactional memory attribute list, but you're removing all transactional 
> memory attributes from it.  A list without the "*tm regparm" internal 
> attribute would have a different name.
> 

AFAICS there is no pre-existing attr list with just returns_twice and
nothrow. Would ATTR_NOTHROW_RT_LIST be more appropriate as name, and
should i move this up to before the format attribute lists, before
DEF_FORMAT_ATTRIBUTE?

Alternatively, there is an existing ATTR_RT_NOTHROW_LEAF_LIST
used by setjmp. But that would add leaf to _ITM_beginTransaction where
it was not marked leaf before. Would it be appropriate to use this for
_ITM_beginTransaction too, which behaves setjmp()ish AFAICS?

thanks

Re: [Patch, stage-1, RFC]: i386: attribute regparm/stdcall and vaargs

[Joseph Myers via Gcc]

On Fri, 2 Feb 2024, Bernhard Reutner-Fischer via Gcc wrote:

> Hi Joseph!
> 
> On Tue, 30 Jan 2024 14:54:49 + (UTC)
> Joseph Myers  wrote:
> 
> > On Tue, 30 Jan 2024, Bernhard Reutner-Fischer via Gcc wrote:
> > 
> > >   * builtin-attrs.def (ATTR_TM_NOTHROW_RT_LIST): Use ATTR_NOTHROW_LIST
> > >   instead of ATTR_TM_NOTHROW_LIST, thus removing ATTR_TM_REGPARM.  
> > 
> > That doesn't make sense.  ATTR_TM_NOTHROW_RT_LIST is specifically a 
> > transactional memory attribute list, but you're removing all transactional 
> > memory attributes from it.  A list without the "*tm regparm" internal 
> > attribute would have a different name.
> > 
> 
> AFAICS there is no pre-existing attr list with just returns_twice and
> nothrow. Would ATTR_NOTHROW_RT_LIST be more appropriate as name, and
> should i move this up to before the format attribute lists, before
> DEF_FORMAT_ATTRIBUTE?

Yes, both of those seem appropriate for such an attribute list.

I do not know what attributes are appropriate for _ITM_beginTransaction.

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

(in)consistency of libgcc symbol versions

[Jakub Jelinek via Gcc]

Hi!

Seems libgcc mostly uses triplets after GCC_ in symbol version names in the
last few years (looking at GCC 5+):

find -name \*.ver -o -name \*.ver.in | xargs grep 
'GCC_[156789][0-9]*\.[0-9]*\.[0-9]* '
./config/i386/libgcc-glibc.ver:%inherit GCC_12.0.0 GCC_7.0.0
./config/i386/libgcc-glibc.ver:GCC_12.0.0 {
./config/i386/libgcc-glibc.ver:%inherit GCC_13.0.0 GCC_12.0.0
./config/i386/libgcc-glibc.ver:GCC_13.0.0 {
./config/i386/libgcc-glibc.ver:%inherit GCC_14.0.0 GCC_13.0.0
./config/i386/libgcc-glibc.ver:GCC_14.0.0 {
./config/i386/libgcc-bsd.ver:GCC_7.0.0 {
./config/i386/libgcc-sol2.ver:GCC_7.0.0 {
./config/i386/libgcc-darwin.ver:%inherit GCC_12.0.0 GCC_7.0.0
./config/i386/libgcc-darwin.ver:GCC_12.0.0 {
./config/ia64/libgcc-glibc.ver:GCC_7.0.0 {
./config/aarch64/libgcc-softfp.ver:%inherit GCC_13.0.0 GCC_11.0.0
./config/aarch64/libgcc-softfp.ver:GCC_13.0.0 {
./config/pru/libgcc-eabi.ver:GCC_9.0.0 {
./libgcc-std.ver.in:%inherit GCC_7.0.0 GCC_4.8.0
./libgcc-std.ver.in:GCC_7.0.0 {
./libgcc-std.ver.in:%inherit GCC_14.0.0 GCC_7.0.0
./libgcc-std.ver.in:GCC_14.0.0 {

But there are some outliers to this:

find -name \*.ver -o -name \*.ver.in | xargs grep 
'GCC_[156789][0-9]*\(\|\.[0-9]*\) '
./config/mips/libgcc-mips.ver:GCC_14.0 {
./config/i386/libgcc-mingw.ver:GCC_13 {
./config/aarch64/libgcc-softfp.ver:GCC_11.0 {
./config/aarch64/libgcc-sme.ver:GCC_14.0 {
./config/rs6000/libgcc-aix-cxa.ver:GCC_5 {

I guess it is too late for the GCC 5, 11 and 13 symvers now, but shouldn't
we at least change the GCC_14.0 symvers to GCC_14.0.0 (i.e. aarch64 and
mips)?

./config/aarch64/libgcc-softfp.ver even contains weirdness like
GCC_11.0 {
...
%inherit GCC_13.0.0 GCC_11.0.0
but bet that is too late too.

Jakub

Re: GCC GSoC 2024: Call for project ideas and mentors

[Martin Jambor]

Hello,

this is just a reminder that the organization application period of GSoC
2024 closes on Tuesday February 6th (6pm UTC).  We have already applied
but that is when we are expected to have our project idea list basically
ready.  So please review old ideas and if you have a new one and/or
would like to be a mentor, please speak up.

Thanks,

Martin


On Mon, Jan 15 2024, Martin Jambor wrote:
[...]
>  The most important bit: 
>
> I would like to ask all (moderately) seasoned GCC contributors to
> consider mentoring a contributor this year and ideally also come up with
> a project that they would like to lead.  I'm collecting proposal on our
> wiki page https://gcc.gnu.org/wiki/SummerOfCode - feel free to add yours
> to the top list there.  Or, if you are unsure, post your offer and
> project idea as a reply here to the mailing list.
>
> Additionally, if you have added an idea to the list in the recent years,
> please review it whether it is still up-to-date or needs adjusting or
> should be removed altogether.
>
> =
>
> At this point, we need to collect list of project ideas.  Eventually,
> each listed project idea should have:
>
>   a) a project title,
>   b) more detailed description of the project (2-5 sentences),
>   c) expected outcomes (we do have a catch-almost-all formulation that
>  outcome is generally patches at the bottom of the list on the
>  wiki),
>   d) skills required/preferred,
>   e) project size - whether it is expected to take approximately 350,
>  175 or just 90 hours (the last option in new in 2024, see below),
>   f) difficulty (easy, hard or medium, but we don't really have easy
>  projects), and
>   g) expected mentors.
>
> Project ideas that come without an offer to also mentor them are always
> fun to discuss, by all means feel free to reply to this email with yours
> and I will attempt to find a mentor, but please be aware that we can
> only use the suggestion it if we actually find one or ideally two.
>
> Everybody in the GCC community is invited to go over
> https://gcc.gnu.org/wiki/SummerOfCode and remove any outdated or
> otherwise bad project suggestions and help improve viable ones.
>
> Finally, please continue helping (prospective) students figure stuff out
> about GCC like you have always done in the past.
>
> As far as I know, GSoC 2024 should be quite similar to the last year,
> the most important parameters probably are these:
>
>   - Contributors (formerly students) must either be full-time students
> or be "beginners to open source."
>
>   - There are now three project sizes: roughly 90 hors (small), roughly
> 175 hours (medium-sized) and roughly 350 hours (large) of work in
> total.  The small option is new this year but because our projects
> usually have a lengthy learning period, I think we will usually want
> to stick to the medium and large variants.
>
>   - Timing should be pretty much as flexible as last year.  The
> recommended "standard" duration is 12 weeks but depending on
> contributor's and mentor's needs and circumstances, projects can
> take anywhere between 10 and 22 weeks.  There will be one mid-term
> and one final evaluation.
>
> For further details you can see:
>
>   - The announcement of GSoC 2024:
> 
> https://opensource.googleblog.com/2023/11/google-summer-of-code-2024-celebrating-20th-year.html
>
>   - GSoC rules:
> https://summerofcode.withgoogle.com/rules
>
>   - The detailed GSoC 2024 timeline:
> https://developers.google.com/open-source/gsoc/timeline
>
>   - Elaborate project idea guidelines:
> https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list
>
> Thank you very much for your participation and help.  Let's hope we
> attract some great contributors again this year.
>
> Martin

Re: Update on GCC 14 C type safety changes/warnings as errors

[Florian Weimer via Gcc]

* Martin Jambor:

> Given you probably have the most experience with it, can you please also
> suggest an entry to https://gcc.gnu.org/gcc-14/porting_to.html that
> would describe this change?  (I was thinking of proposing something
> myself, but I don't really know just how much verbose such an entry
> should be.)

Thank you for the reminder.  I veered somewhat on the verbose side and
submitted:

  [PATCH] Notes on the warnings-as-errors change in GCC 14
  


Florian

gcc-12-20240202 is now available

[GCC Administrator via Gcc]

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

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

You'll find:

 gcc-12-20240202.tar.xz   Complete GCC

  SHA256=fde19be26aebc01f74d4b18f6ac56cd8ee09c4a61ca0dc1da8b88d0026249305
  SHA1=fcdab7bbeb3db4786a249f8b015b02abc020c86f

Diffs from 12-20240126 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-12
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.