Re: [RFC] MAINTAINERS: require a BZ account field
On 24/06/2024 23:34, Arsen Arsenović via Gcc wrote: I was also proposing (and would like to re-air that here) enforcing that the committer field of each commit is a (valid) @gcc.gnu.org email. This can be configured repo-locally via: $ git config committer.email @gcc.gnu.org Git has supported this since 39ab4d0951ba64edcfae7809740715991b44fa6d (v2.22.0). This makes a permanent association of each commit to its authors Sourceware account. This should not inhibit pushes, as the committer should be a reflection of who /applied/ a patch, and anyone applying a patch that can also push has a Sourceware account. It also should not inhibit any workflow, as it should be automatic. This will make it hard to a) find emails from a maintainer/committer in the mailing list archives -- since it's not generally possible to send "From:" a @gcc.gnu.org address -- and b) make it hard to compile statistics about contributions from corporate domains (which people do do). I do not object to having the bugzilla account also listed in MAINTAINERS, although I've never had trouble finding people by name. Andrew
Re: [RFC] MAINTAINERS: require a BZ account field
Hi, Andrew Stubbs writes: > On 24/06/2024 23:34, Arsen Arsenović via Gcc wrote: >> I was also proposing (and would like to re-air that here) enforcing that >> the committer field of each commit is a (valid) @gcc.gnu.org email. >> This can be configured repo-locally via: >>$ git config committer.email @gcc.gnu.org >> Git has supported this since 39ab4d0951ba64edcfae7809740715991b44fa6d >> (v2.22.0). >> This makes a permanent association of each commit to its authors >> Sourceware account. >> This should not inhibit pushes, as the committer should be a reflection >> of who /applied/ a patch, and anyone applying a patch that can also push >> has a Sourceware account. It also should not inhibit any workflow, as >> it should be automatic. > > This will make it hard to a) find emails from a maintainer/committer in the > mailing list archives -- since it's not generally possible to send "From:" a > @gcc.gnu.org address -- and b) make it hard to compile statistics about > contributions from corporate domains (which people do do). I'm not sure that is the case - the committer field is separate to the author field, so all statistics one could do with the author field remain unaltered. For instance (as I've been doing that for a while), here's what a commit of mine looks like under that scheme: commit 36cb7be477885a2464fe9a70467278c7debd5e79 Author: Arsen Arsenović AuthorDate: Thu Nov 16 23:50:30 2023 +0100 Commit: Arsen Arsenović CommitDate: Wed Dec 13 13:17:35 2023 +0100 gettext: disable install, docs targets, libasprintf, threads More often than not, the committer field is redundant with the author field. The email I use for correspondence is still present (and, in fact, is the only one visible with the default git log and show formats). It is possible that someone could be doing statistics based on the committer field, if they also want to, say, count patches applied by members of some company, but I'm not sure how wide-spread that is. -- Arsen Arsenović signature.asc Description: PGP signature
Re: [RFC] MAINTAINERS: require a BZ account field
On 25/06/2024 10:05, Arsen Arsenović wrote: Hi, Andrew Stubbs writes: On 24/06/2024 23:34, Arsen Arsenović via Gcc wrote: I was also proposing (and would like to re-air that here) enforcing that the committer field of each commit is a (valid) @gcc.gnu.org email. This can be configured repo-locally via: $ git config committer.email @gcc.gnu.org Git has supported this since 39ab4d0951ba64edcfae7809740715991b44fa6d (v2.22.0). This makes a permanent association of each commit to its authors Sourceware account. This should not inhibit pushes, as the committer should be a reflection of who /applied/ a patch, and anyone applying a patch that can also push has a Sourceware account. It also should not inhibit any workflow, as it should be automatic. This will make it hard to a) find emails from a maintainer/committer in the mailing list archives -- since it's not generally possible to send "From:" a @gcc.gnu.org address -- and b) make it hard to compile statistics about contributions from corporate domains (which people do do). I'm not sure that is the case - the committer field is separate to the author field, so all statistics one could do with the author field remain unaltered. For instance (as I've been doing that for a while), here's what a commit of mine looks like under that scheme: commit 36cb7be477885a2464fe9a70467278c7debd5e79 Author: Arsen Arsenović AuthorDate: Thu Nov 16 23:50:30 2023 +0100 Commit: Arsen Arsenović CommitDate: Wed Dec 13 13:17:35 2023 +0100 gettext: disable install, docs targets, libasprintf, threads More often than not, the committer field is redundant with the author field. The email I use for correspondence is still present (and, in fact, is the only one visible with the default git log and show formats). It is possible that someone could be doing statistics based on the committer field, if they also want to, say, count patches applied by members of some company, but I'm not sure how wide-spread that is. OK; fair point. Andrew
Re: [RFC] MAINTAINERS: require a BZ account field
On Tue, Jun 25, 2024 at 12:36 AM Arsen Arsenović via Gcc wrote: > > Hi, > > Sam James via Gcc writes: > > > Hi! > > > > This comes up in #gcc on IRC every so often, so finally > > writing an RFC. > > > > What? > > --- > > > > I propose that MAINTAINERS be modified to be of the form, > > adding an extra field for their GCC/sourceware account: > >> sourceware account> > > Joe Bloggsjoeblo...@example.com jblo...@gcc.gnu.org > > > > Further, that the field must not be blank (-> must have a BZ account; > > there were/are some without at all)! > > > > Why? > > --- > > > > 1) This is tied to whether or not people should use their committer email > > on Bugzilla or a personal email. A lot of people don't seem to use their > > committer email (-> no permissions) and end up not closing bugs, so > > pinskia (and often myself these days) end up doing it for them. > > > > 2) It's standard practice to wish to CC the committer of a bisect result > > - or to CC someone who you know wrote patches on a subject area. Doing > > this on Bugzilla is challenging when there's no map between committer > > <-> BZ account. > > > > Specifically, there are folks who have git committer+author as > > joeblo...@example.com (or maybe even coold...@example.com) where the > > local part of the address has *no relation* to their GCC/sw account, > > so finding who to CC is difficult without e.g. trawling through gcc-cvs > > mails or asking overseers for help. > > I was also proposing (and would like to re-air that here) enforcing that > the committer field of each commit is a (valid) @gcc.gnu.org email. > This can be configured repo-locally via: > > $ git config committer.email @gcc.gnu.org > > Git has supported this since 39ab4d0951ba64edcfae7809740715991b44fa6d > (v2.22.0). > > This makes a permanent association of each commit to its authors > Sourceware account. I'd welcome this - care to create a patch for contrib/gcc-git-customization.sh? > This should not inhibit pushes, as the committer should be a reflection > of who /applied/ a patch, and anyone applying a patch that can also push > has a Sourceware account. It also should not inhibit any workflow, as > it should be automatic. > > > Summary > > --- > > > > TL;DR: The proposal is: > > > > 1) MAINTAINERS should list a field containing either the gcc.gnu.org > > email in full, or their gcc username (bikeshedding semi-welcome); > > > > 2) It should become a requirement that to be in MAINTAINERS, one must > > possess a Bugzilla account (ideally using their gcc.gnu.org email). > > -- > Arsen Arsenović
Re: [RFC] MAINTAINERS: require a BZ account field
On Tue, 25 Jun 2024 at 10:06, Arsen Arsenović via Gcc wrote: > > Hi, > > Andrew Stubbs writes: > > > On 24/06/2024 23:34, Arsen Arsenović via Gcc wrote: > >> I was also proposing (and would like to re-air that here) enforcing that > >> the committer field of each commit is a (valid) @gcc.gnu.org email. > >> This can be configured repo-locally via: > >>$ git config committer.email @gcc.gnu.org > >> Git has supported this since 39ab4d0951ba64edcfae7809740715991b44fa6d > >> (v2.22.0). > >> This makes a permanent association of each commit to its authors > >> Sourceware account. > >> This should not inhibit pushes, as the committer should be a reflection > >> of who /applied/ a patch, and anyone applying a patch that can also push > >> has a Sourceware account. It also should not inhibit any workflow, as > >> it should be automatic. > > > > This will make it hard to a) find emails from a maintainer/committer in the > > mailing list archives -- since it's not generally possible to send "From:" a > > @gcc.gnu.org address -- and b) make it hard to compile statistics about > > contributions from corporate domains (which people do do). > > I'm not sure that is the case - the committer field is separate to the > author field, so all statistics one could do with the author field > remain unaltered. For instance (as I've been doing that for a while), > here's what a commit of mine looks like under that scheme: > > commit 36cb7be477885a2464fe9a70467278c7debd5e79 > Author: Arsen Arsenović > AuthorDate: Thu Nov 16 23:50:30 2023 +0100 > Commit: Arsen Arsenović > CommitDate: Wed Dec 13 13:17:35 2023 +0100 > > gettext: disable install, docs targets, libasprintf, threads > > More often than not, the committer field is redundant with the author > field. > > The email I use for correspondence is still present (and, in fact, is > the only one visible with the default git log and show formats). Right, and this is of course no different to when I push a commit on behalf of somebody who doesn't have a sourceware account. The Author field is the person who wrote the code, and the Committer field is the person who pushed it (me). As soon as Arsen suggested this on IRC I updated my git config. I think it is quote logical for the committer to be the @gcc.gnu.org account name, because that is literally who pushed it - you're using your SSH key to push as usern...@gcc.gnu.org. And this is how all commits looked in the Subversion days, when a commit was associated with a username, and there was no separate Author (except as noted in the ChangeLog file). With Git we can correctly track the Author and Committer separately, and I like the suggestion to use different "identities" for those two roles. I write most of my patches as part of my dayjob, so the author is jwakely@redhat, but I push them using my sourceware account which existed long before I joined Red Hat, so for my future commits the committer is going to be r...@gcc.gnu.org.
Re: gnatlink vs. -mthumb -march=armv7-a+simd -mfloat-abi=hard
On 24.06.24 16:06, Sebastian Huber wrote:
On 28.04.22 10:16, Sebastian Huber wrote:
Hello,
I test currently the Ada support for RTEMS in GCC 12. We have a
-mthumb -march=armv7-a+simd -mfloat-abi=hard multilib for which the
Ada RTS is built like this:
make[4]: Entering directory
'/tmp/sh/b-gcc-arm-rtems6/arm-rtems6/thumb/armv7-a+simd/hard/libada'
make -C ../../../../.././gcc/ada "MAKEOVERRIDES=" "LDFLAGS=-mthumb
-march=armv7-a+simd -mfloat-abi=hard" "LN_S=ln -s" "SHELL=/bin/sh"
"GNATLIBFLAGS=-W -Wall -gnatpg -nostdinc -mthumb -march=armv7-a+simd
-mfloat-abi=hard" "GNATLIBCFLAGS=-g -O2 -mthumb -march=armv7-a+simd
-mfloat-abi=hard" "GNATLIBCFLAGS_FOR_C=-W -Wall -g -O2 -g -O2
-fexceptions -DIN_RTS -DHAVE_GETIPINFO -mthumb -march=armv7-a+simd
-mfloat-abi=hard" "PICFLAG_FOR_TARGET=-fPIC" "THREAD_KIND=native"
"TRACE=no" "MULTISUBDIR=/thumb/armv7-a+simd/hard"
"libsubdir=/tmp/sh/i-arm-rtems6/lib64/gcc/arm-rtems6/12.0.1/thumb/armv7-a+simd/hard" "toolexeclibdir=/tmp/sh/i-arm-rtems6/lib64/gcc/arm-rtems6/12.0.1/thumb/armv7-a+simd/hard/adalib" "objext=.o" "prefix=/tmp/sh/i-arm-rtems6" "exeext=.exeext.should.not.be.used " 'CC=the.host.compiler.should.not.be.needed' "GCC_FOR_TARGET=/tmp/sh/b-gcc-arm-rtems6/./gcc/xgcc -B/tmp/sh/b-gcc-arm-rtems6/./gcc/ -nostdinc -B/tmp/sh/b-gcc-arm-rtems6/arm-rtems6/newlib/ -isystem /tmp/sh/b-gcc-arm-rtems6/arm-rtems6/newlib/targ-include -isystem /home/EB/sebastian_h/src/gcc/newlib/libc/include -B/tmp/sh/i-arm-rtems6/arm-rtems6/bin/ -B/tmp/sh/i-arm-rtems6/arm-rtems6/lib/ -isystem /tmp/sh/i-arm-rtems6/arm-rtems6/include -isystem /tmp/sh/i-arm-rtems6/arm-rtems6/sys-include " "CFLAGS=-g -O2 -mthumb -march=armv7-a+simd -mfloat-abi=hard" ./bldtools/oscons/xoscons
When I try to link a test application I get this error:
arm-rtems7-gnatlink
/tmp/sh/b-rtems/arm/realview_pbx_a9_qemu/testsuites/ada/samples/nsecs/nsecs.ali testsuites/ada/samples/nsecs/init.o -qnolinkcmds -T linkcmds.realview_pbx_a9_qemu -Wl,--wrap=printf -Wl,--wrap=puts -Wl,--wrap=putchar -L. -lrtemscpu -lrtemsbsp -lrtemstest -qrtems -mthumb -march=armv7-a+simd -mfloat-abi=hard -mtune=cortex-a9 -Wl,--gc-sections -L/home/EB/sebastian_h/src/rtems/bsps/arm/shared/start -L/home/EB/sebastian_h/src/rtems/bsps/arm/realview-pbx-a9/start -o /tmp/sh/b-rtems/arm/realview_pbx_a9_qemu/testsuites/ada/ada_nsecs.exe
/opt/rtems/7/lib/gcc/arm-rtems7/12.0.1/thumb/armv7-a+simd/hard/adainclude/s-secsta.ads:288:9:
sorry, unimplemented: Thumb-1 'hard-float' VFP ABI
The s-secsta.ads seems to be from the right multilib directory
(Thumb-2), however, I get a sorry message related to Thumb-1?
I tried it again with GCC 13, but the problem still exists. I tried to
use strace to get some more insights (the environment variables are
partially shown):
[pid 110912] execve("/opt/rtems-6-zynq-1/bin/arm-rtems6-gnatmake",
["/opt/rtems-6-zynq-1/bin/arm-rtems6-gnatmake", "-D",
"testsuites/ada/tmtests/tm20", "-bargs", "-Mgnat_main", "-margs",
"-Icpukit/include/adainclude",
"-I../../../../src/rtems/cpukit/include/adainclude",
"-Itestsuites/ada/support",
"-I../../../../src/rtems/testsuites/ada/support", "-cargs",
"-march=armv7-a", "-mthumb", "-mfpu=neon", "-mfloat-abi=hard",
"-mtune=cortex-a9", "-largs", "testsuites/ada/tmtests/tm20/init.o",
"-Wl,--wrap=printf", "-Wl,--wrap=puts", "-Wl,--wrap=putchar", "-L.",
"-lrtemscpu", "-lrtemsbsp", "-lrtemstest", "-qrtems", "-march=armv7-a",
"-mthumb", "-mfpu=neon", "-mfloat-abi=hard", "-mtune=cortex-a9",
"-Wl,--gc-sections",
"-L/opt/rtems-6-zynq-1/src/rtems/bsps/arm/shared/start",
"-L/opt/rtems-6-zynq-1/src/rtems/bsps/arm/xilinx-zynq/start", "-margs",
"-a",
"/opt/rtems-6-zynq-1/src/rtems/testsuites/ada/tmtests/tm20/tm20.adb",
"-o",
"/opt/rtems-6-zynq-1/build/arm-xilinx_zynq_zc702-bsp-extra/arm/xilinx_zynq_zc702/testsuites/ada/ada_tm20.exe"], []
[pid 110913] execve("/opt/rtems-6-zynq-1//bin/arm-rtems6-gcc",
["/opt/rtems-6-zynq-1//bin/arm-rtems6-gcc", "-march=armv7-a", "-mthumb",
"-mfpu=neon", "-mfloat-abi=hard", "-mtune=cortex-a9", "-march=armv7-a",
"-mthumb", "-mfpu=neon", "-mfloat-abi=hard", "-mtune=cortex-a9",
"-print-multi-directory"], []) = 0
The above call is used to get the multi-lib directory. Which yields:
--RTS=thumb/armv7-a+simd/hard
The flags seem to be obtained by getting all "-m" flags from the
previous "-cargs" and "-largs". So, each flags appears twice.
[pid 110914] execve("/opt/rtems-6-zynq-1//bin/arm-rtems6-gnatbind",
["/opt/rtems-6-zynq-1//bin/arm-rtems6-gnatbind",
"-aO/opt/rtems-6-zynq-1/build/arm-xilinx_zynq_zc702-bsp-extra/arm/xilinx_zynq_zc702/testsuites/ada/tmtests/tm20", "-Mgnat_main", "-Icpukit/include/adainclude", "-I../../../../src/rtems/cpukit/include/adainclude", "-Itestsuites/ada/support", "-I../../../../src/rtems/testsuites/ada/support", "--RTS=thumb/armv7-a+simd/hard", "-x", "/opt/rtems-6-zynq-1/build/arm-xilinx_zynq_zc702-bsp-extra/arm/xilinx_zynq_zc702/testsuites/ada/tmtests/tm20/tm20.ali"], []) = 0
[pid 110915] execve("/opt/rtems-6-zy
Re: gnatlink vs. -mthumb -march=armv7-a+simd -mfloat-abi=hard
On 25.06.24 14:53, Sebastian Huber wrote:
On 24.06.24 16:06, Sebastian Huber wrote:
On 28.04.22 10:16, Sebastian Huber wrote:
Hello,
I test currently the Ada support for RTEMS in GCC 12. We have a
-mthumb -march=armv7-a+simd -mfloat-abi=hard multilib for which the
Ada RTS is built like this:
make[4]: Entering directory
'/tmp/sh/b-gcc-arm-rtems6/arm-rtems6/thumb/armv7-a+simd/hard/libada'
make -C ../../../../.././gcc/ada "MAKEOVERRIDES=" "LDFLAGS=-mthumb
-march=armv7-a+simd -mfloat-abi=hard" "LN_S=ln -s" "SHELL=/bin/sh"
"GNATLIBFLAGS=-W -Wall -gnatpg -nostdinc -mthumb -march=armv7-a+simd
-mfloat-abi=hard" "GNATLIBCFLAGS=-g -O2 -mthumb -march=armv7-a+simd
-mfloat-abi=hard" "GNATLIBCFLAGS_FOR_C=-W -Wall -g -O2 -g -O2
-fexceptions -DIN_RTS -DHAVE_GETIPINFO -mthumb -march=armv7-a+simd
-mfloat-abi=hard" "PICFLAG_FOR_TARGET=-fPIC" "THREAD_KIND=native"
"TRACE=no" "MULTISUBDIR=/thumb/armv7-a+simd/hard"
"libsubdir=/tmp/sh/i-arm-rtems6/lib64/gcc/arm-rtems6/12.0.1/thumb/armv7-a+simd/hard" "toolexeclibdir=/tmp/sh/i-arm-rtems6/lib64/gcc/arm-rtems6/12.0.1/thumb/armv7-a+simd/hard/adalib" "objext=.o" "prefix=/tmp/sh/i-arm-rtems6" "exeext=.exeext.should.not.be.used " 'CC=the.host.compiler.should.not.be.needed' "GCC_FOR_TARGET=/tmp/sh/b-gcc-arm-rtems6/./gcc/xgcc -B/tmp/sh/b-gcc-arm-rtems6/./gcc/ -nostdinc -B/tmp/sh/b-gcc-arm-rtems6/arm-rtems6/newlib/ -isystem /tmp/sh/b-gcc-arm-rtems6/arm-rtems6/newlib/targ-include -isystem /home/EB/sebastian_h/src/gcc/newlib/libc/include -B/tmp/sh/i-arm-rtems6/arm-rtems6/bin/ -B/tmp/sh/i-arm-rtems6/arm-rtems6/lib/ -isystem /tmp/sh/i-arm-rtems6/arm-rtems6/include -isystem /tmp/sh/i-arm-rtems6/arm-rtems6/sys-include " "CFLAGS=-g -O2 -mthumb -march=armv7-a+simd -mfloat-abi=hard" ./bldtools/oscons/xoscons
When I try to link a test application I get this error:
arm-rtems7-gnatlink
/tmp/sh/b-rtems/arm/realview_pbx_a9_qemu/testsuites/ada/samples/nsecs/nsecs.ali testsuites/ada/samples/nsecs/init.o -qnolinkcmds -T linkcmds.realview_pbx_a9_qemu -Wl,--wrap=printf -Wl,--wrap=puts -Wl,--wrap=putchar -L. -lrtemscpu -lrtemsbsp -lrtemstest -qrtems -mthumb -march=armv7-a+simd -mfloat-abi=hard -mtune=cortex-a9 -Wl,--gc-sections -L/home/EB/sebastian_h/src/rtems/bsps/arm/shared/start -L/home/EB/sebastian_h/src/rtems/bsps/arm/realview-pbx-a9/start -o /tmp/sh/b-rtems/arm/realview_pbx_a9_qemu/testsuites/ada/ada_nsecs.exe
/opt/rtems/7/lib/gcc/arm-rtems7/12.0.1/thumb/armv7-a+simd/hard/adainclude/s-secsta.ads:288:9:
sorry, unimplemented: Thumb-1 'hard-float' VFP ABI
The s-secsta.ads seems to be from the right multilib directory
(Thumb-2), however, I get a sorry message related to Thumb-1?
I tried it again with GCC 13, but the problem still exists. I tried to
use strace to get some more insights (the environment variables are
partially shown):
[pid 110912] execve("/opt/rtems-6-zynq-1/bin/arm-rtems6-gnatmake",
["/opt/rtems-6-zynq-1/bin/arm-rtems6-gnatmake", "-D",
"testsuites/ada/tmtests/tm20", "-bargs", "-Mgnat_main", "-margs",
"-Icpukit/include/adainclude",
"-I../../../../src/rtems/cpukit/include/adainclude",
"-Itestsuites/ada/support",
"-I../../../../src/rtems/testsuites/ada/support", "-cargs",
"-march=armv7-a", "-mthumb", "-mfpu=neon", "-mfloat-abi=hard",
"-mtune=cortex-a9", "-largs", "testsuites/ada/tmtests/tm20/init.o",
"-Wl,--wrap=printf", "-Wl,--wrap=puts", "-Wl,--wrap=putchar", "-L.",
"-lrtemscpu", "-lrtemsbsp", "-lrtemstest", "-qrtems",
"-march=armv7-a", "-mthumb", "-mfpu=neon", "-mfloat-abi=hard",
"-mtune=cortex-a9", "-Wl,--gc-sections",
"-L/opt/rtems-6-zynq-1/src/rtems/bsps/arm/shared/start",
"-L/opt/rtems-6-zynq-1/src/rtems/bsps/arm/xilinx-zynq/start",
"-margs", "-a",
"/opt/rtems-6-zynq-1/src/rtems/testsuites/ada/tmtests/tm20/tm20.adb",
"-o",
"/opt/rtems-6-zynq-1/build/arm-xilinx_zynq_zc702-bsp-extra/arm/xilinx_zynq_zc702/testsuites/ada/ada_tm20.exe"], []
[pid 110913] execve("/opt/rtems-6-zynq-1//bin/arm-rtems6-gcc",
["/opt/rtems-6-zynq-1//bin/arm-rtems6-gcc", "-march=armv7-a",
"-mthumb", "-mfpu=neon", "-mfloat-abi=hard", "-mtune=cortex-a9",
"-march=armv7-a", "-mthumb", "-mfpu=neon", "-mfloat-abi=hard",
"-mtune=cortex-a9", "-print-multi-directory"], []) = 0
The above call is used to get the multi-lib directory. Which yields:
--RTS=thumb/armv7-a+simd/hard
The flags seem to be obtained by getting all "-m" flags from the
previous "-cargs" and "-largs". So, each flags appears twice.
[pid 110914] execve("/opt/rtems-6-zynq-1//bin/arm-rtems6-gnatbind",
["/opt/rtems-6-zynq-1//bin/arm-rtems6-gnatbind",
"-aO/opt/rtems-6-zynq-1/build/arm-xilinx_zynq_zc702-bsp-extra/arm/xilinx_zynq_zc702/testsuites/ada/tmtests/tm20", "-Mgnat_main", "-Icpukit/include/adainclude", "-I../../../../src/rtems/cpukit/include/adainclude", "-Itestsuites/ada/support", "-I../../../../src/rtems/testsuites/ada/support", "--RTS=thumb/armv7-a+simd/hard", "-x", "/opt/rtems-6-zynq-1/build/arm-xilinx_zynq_zc702-bsp-extra/arm/xilinx_zynq_zc702/testsuites/ada/tmtests/tm20/tm20.ali"], [])
Re: [RFC] MAINTAINERS: require a BZ account field
Hi,
Richard Biener writes:
> [snip]
>> I was also proposing (and would like to re-air that here) enforcing
>> that the committer field of each commit is a (valid) @gcc.gnu.org
>> email. This can be configured repo-locally via:
>>
>> $ git config committer.email @gcc.gnu.org
>>
>> Git has supported this since 39ab4d0951ba64edcfae7809740715991b44fa6d
>> (v2.22.0).
>>
>> This makes a permanent association of each commit to its authors
>> Sourceware account.
>
> I'd welcome this - care to create a patch for
> contrib/gcc-git-customization.sh?
Sure - I've attached a partial patch. I didn't find the hook which runs
on each push to check commits, so the current patch is minimal. Is that
also in the tree? I could try hacking it to check commits.
--
Arsen Arsenović
From c7ca9e26693a707a0aa9f87aeb35717f5fecdc79 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Arsen=20Arsenovi=C4=87?=
Date: Tue, 25 Jun 2024 20:57:34 +0200
Subject: [PATCH] git-customizations: set committer email to @gcc.gnu.org email
See discussion at
https://inbox.sourceware.org/gcc/87y16uowix@gentoo.org/
contrib/ChangeLog:
* gcc-git-customization.sh: Set committer.email to
remote...@gcc.gnu.org.
---
contrib/gcc-git-customization.sh | 1 +
1 file changed, 1 insertion(+)
diff --git a/contrib/gcc-git-customization.sh b/contrib/gcc-git-customization.sh
index 54bd35ea1aab..9e23e71f4204 100755
--- a/contrib/gcc-git-customization.sh
+++ b/contrib/gcc-git-customization.sh
@@ -129,6 +129,7 @@ fi
ask "Account name on gcc.gnu.org (for your personal branches area)"
"$remote_id" remote_id
git config "gcc-config.user" "$remote_id"
+git config "committer.email" "${remote_id}@gcc.gnu.org"
old_pfx=$(git config --get "gcc-config.userpfx")
if [ "x$old_pfx" = "x" ]
--
2.45.2
signature.asc
Description: PGP signature
Re: [RFC] MAINTAINERS: require a BZ account field
Am 25.06.24 um 21:08 schrieb Arsen Arsenović via Gcc: Richard Biener writes: I'd welcome this - care to create a patch for contrib/gcc-git-customization.sh? Sure - I've attached a partial patch. I didn't find the hook which runs on each push to check commits, so the current patch is minimal. Is that also in the tree? I could try hacking it to check commits. Will this also influence commits to, for example, github?
Re: [RFC] MAINTAINERS: require a BZ account field
Hi, Thomas Koenig via Gcc writes: > Am 25.06.24 um 21:08 schrieb Arsen Arsenović via Gcc: > >> Richard Biener writes: > >>> I'd welcome this - care to create a patch for >>> contrib/gcc-git-customization.sh? >> Sure - I've attached a partial patch. I didn't find the hook which runs >> on each push to check commits, so the current patch is minimal. Is that >> also in the tree? I could try hacking it to check commits. > > Will this also influence commits to, for example, github? In the sense that their contents will be changed, yes - commits are independent of remote, so their committer field is common for all remotes. However, since only the committer field changes, and usually commits are tracked by the author field, that might not be too big of an issue. I've been pushing to SourceHut and GitHub with a committer.email set to arsen at gcc dot gnu dot org for a while now, here are example commits from both: https://git.sr.ht/~arsen/gcc/commit/0290e3ce8c017701bc5f665daf5ea438b3cd996f https://github.com/ArsenArsen/gcc/commit/ee6cc90 Note that, in the latter, GitHub attributes the commit to a non-GitHub account as committer, but it is still attributed to my account by author, if that is of concern. Note also that GH verifies GPG by *committer* (which makes sense..). This is why it states that my commit is unverified - I never added my sourceware/gcc.gnu.org email to GH. -- Arsen Arsenović signature.asc Description: PGP signature
Re: gnatlink vs. -mthumb -march=armv7-a+simd -mfloat-abi=hard
> Here, the "-march=armv7-a+simd" was moved after the "-gnatez". So this > option is dropped in switch-c.adb and doesn't get added to the ALI file. This comes from the spec magic implemented in ada/gcc-interface/lang-specs.h and it looks like the '+' character is not matched by '*' or some such. -- Eric Botcazou
Straw poll on shifts with out of range operands
I am in the middle of improving the isolation path pass for shifts with out of range operands. There are 3 options we could do really: 1) isolate the path to __builtin_unreachable 2) isolate the path to __builtin_trap This is what is currently done for null pointer and divide by zero 3) isolate the path and turn the shift into zero constant This happens currently for explicit use in both match (in many cases) and VRP for others. All 3 are not hard to implement. This comes up in the context of https://gcc.gnu.org/PR115636 where the original requestor thinks it should be #3 but I suspect they didn't realize it was undefined behavior then. 2 seems the best for user experience. 1 seems like the best for optimizations. 3 is more in line with how other parts of the compiler handle it. So the question I have is which one should we go for? (is there another option I missed besides not do anything) Thanks, Andrew Pinski
Re: Straw poll on shifts with out of range operands
On 6/25/24 8:44 PM, Andrew Pinski via Gcc wrote: I am in the middle of improving the isolation path pass for shifts with out of range operands. There are 3 options we could do really: 1) isolate the path to __builtin_unreachable 2) isolate the path to __builtin_trap This is what is currently done for null pointer and divide by zero 3) isolate the path and turn the shift into zero constant This happens currently for explicit use in both match (in many cases) and VRP for others. All 3 are not hard to implement. This comes up in the context of https://gcc.gnu.org/PR115636 where the original requestor thinks it should be #3 but I suspect they didn't realize it was undefined behavior then. 2 seems the best for user experience. 1 seems like the best for optimizations. 3 is more in line with how other parts of the compiler handle it. So the question I have is which one should we go for? (is there another option I missed besides not do anything) There was a time when we were thinking about having a knob that would allow one to select which of the 3 approaches makes the most sense given the expected execution environment. While I prefer #2, some have (reasonably) argued that it's not appropriate behavior for code in a library. I'm not a fan of #1 because it allows unpredictable code execution. Essentially you just fall into whatever code was after the bogus shift in the executable and hope for the best. One day this is going to bite us hard from a security standpoint. #3 isn't great, but it's not terrible either. Jeff
Re: gnatlink vs. -mthumb -march=armv7-a+simd -mfloat-abi=hard
Hello Eric,
On 26.06.24 01:35, Eric Botcazou wrote:
Here, the "-march=armv7-a+simd" was moved after the "-gnatez". So this
option is dropped in switch-c.adb and doesn't get added to the ALI file.
This comes from the spec magic implemented in ada/gcc-interface/lang-specs.h
and it looks like the '+' character is not matched by '*' or some such.
thanks for the hint. So, maybe the problem is here:
%{gnatea:-gnatez} %{g*&m*&f*} \
From the documentation
(https://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html):
%{S*}
Substitutes all the switches specified to GCC whose names start
with -S, but which also take an argument. This is used for switches like
-o, -D, -I, etc. GCC considers -o foo as being one switch whose name
starts with ‘o’. %{o*} substitutes this text, including the space. Thus
two arguments are generated.
%{S*&T*}
Like %{S*}, but preserve order of S and T options (the order of S
and T in the spec is not significant). There can be any number of
ampersand-separated variables; for each the wild card is optional.
Useful for CPP as ‘%{D*&U*&A*}’.
It looks like this is working as documented. I checked this with the
following spec file:
*startfile:
BEGIN %{g*&m*&f*} END
On my x86_64 host GCC, this works fine:
gcc -specs=test.spec -wrapper echo main.c -mfoo=bar+blub -march=armv7-a+simd
... BEGIN -mfoo=bar+blub -march=armv7-a+simd END ...
On the arm GCC, it looks good also:
arm-rtems6-gcc -specs=test.spec -wrapper echo main.c -mfoo=bar+blub
-march=armv7-a+simd
... BEGIN -mfoo=bar+blub -marm -mlibarch=armv7-a -march=armv7-a END ...
arm-rtems6-gcc -specs=test.spec -wrapper echo main.c -mfoo=bar+blub
-march=armv7-a+simd -mfloat-abi=hard
... BEGIN -mfoo=bar+blub -mfloat-abi=hard -marm -mlibarch=armv7-a+simd
-march=armv7-a+simd END ...
--
embedded brains GmbH & Co. KG
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
Re: Straw poll on shifts with out of range operands
On Wed, Jun 26, 2024 at 4:59 AM Jeff Law via Gcc wrote: > > > > On 6/25/24 8:44 PM, Andrew Pinski via Gcc wrote: > > I am in the middle of improving the isolation path pass for shifts > > with out of range operands. > > There are 3 options we could do really: > > 1) isolate the path to __builtin_unreachable > > 2) isolate the path to __builtin_trap > > This is what is currently done for null pointer and divide by zero > > 3) isolate the path and turn the shift into zero constant > > This happens currently for explicit use in both match (in many > > cases) and VRP for others. How is isolation if we do 3) any useful? IIRC the path isolation pass would only look for literal out-of-range shifts? Or do you plan to use range info? If we do 3) why not let range folding deal with this then? > > > > All 3 are not hard to implement. > > This comes up in the context of https://gcc.gnu.org/PR115636 where the > > original requestor thinks it should be #3 but I suspect they didn't > > realize it was undefined behavior then. > > 2 seems the best for user experience. > > 1 seems like the best for optimizations. > > 3 is more in line with how other parts of the compiler handle it. > > > > So the question I have is which one should we go for? (is there > > another option I missed besides not do anything) > There was a time when we were thinking about having a knob that would > allow one to select which of the 3 approaches makes the most sense given > the expected execution environment. Since we do 3) already elsewhere I'd say we should do that by default and have the other options behind a command-line switch - though we already have UBSAN for that and that is going to be much more reliable than the late path isolation done after folding catched most cases via 3)? > While I prefer #2, some have (reasonably) argued that it's not > appropriate behavior for code in a library. > > I'm not a fan of #1 because it allows unpredictable code execution. > Essentially you just fall into whatever code was after the bogus shift > in the executable and hope for the best. One day this is going to bite > us hard from a security standpoint. > > #3 isn't great, but it's not terrible either. > > Jeff
