Re: libsanitizer: sync from master

On 4/28/23 11:23, Florian Weimer wrote: > * Martin Liška: > >> On 4/26/23 20:31, Florian Weimer wrote: >>> * Martin Liška: >>> >>>> On 11/15/22 16:47, Martin Liška wrote: >>>>> Hi. >>>>> >>>>> I've just

Re: libsanitizer: sync from master

On 4/26/23 20:31, Florian Weimer wrote: > * Martin Liška: > >> On 11/15/22 16:47, Martin Liška wrote: >>> Hi. >>> >>> I've just pushed libsanitizer update that was tested on x86_64-linux and >>> ppc64le-linux systems. >>> Moreover, I

Re: libsanitizer: sync from master

On 4/26/23 21:23, H.J. Lu wrote: > On Wed, Apr 26, 2023 at 6:52 AM Martin Liška wrote: >> >> On 11/15/22 16:47, Martin Liška wrote: >>> Hi. >>> >>> I've just pushed libsanitizer update that was tested on x86_64-linux and >>> ppc64le-linu

Re: libsanitizer: sync from master

On 11/15/22 16:47, Martin Liška wrote: > Hi. > > I've just pushed libsanitizer update that was tested on x86_64-linux and > ppc64le-linux systems. > Moreover, I run bootstrap on x86_64-linux and checked ABI difference with > abidiff. Hello. And I've done the

Re: Stepping down as gcov maintainer and callgraph reviewer

On 2/16/23 20:46, Jan Hubicka wrote: > I am sad to hear this news and will definitely miss you as coleague > and co-maintaner. Thank you for all the work on GCC! Thank you all for the nice words! And especially to Honza, who was my diploma thesis supervisor and showed me the community. Actually

Re: Using __gnu_lto_slim to detect -fno-fat-lto-objects

On 2/22/23 09:28, Florian Weimer via Gcc wrote: > * Richard Biener: > >> On Wed, Feb 22, 2023 at 9:19 AM Florian Weimer via Gcc >> wrote: >>> >>> Can we use the COMMON symbol __gnu_lto_slim to detect >>> -fno-fat-lto-objects on contemporary GNU/Linux (with the LTO linker >>> plugin)? >> >> Yes.

Stepping down as gcov maintainer and callgraph reviewer

Hello GCC community. After spending last decade (including my diploma thesis even more) of my life working on GCC, I decided to leave the project and try a different job. I would like to thank all the community members I had change to interact with, I learned so much and enjoyed the journey! I'll

Re: Git 'hooks/post_receive.py': UnicodeDecodeError: 'utf8' codec can't decode byte 0xff in position 2766: invalid start byte

On 2/16/23 13:26, Thomas Schwinge wrote: > Hi! > > The following is not an actual problem for me or GCC/Rust; just for your > information: Hello. Thanks for letting me know. > > I've just pushed to GCC devel/rust/master branch > Git commits cc23831ec66..74913f718b0, which 'hooks/post_receive.p

Re: Document how to build PGO-optimized GCC version

On 12/28/22 06:48, Andrew Pinski via Gcc wrote: > But distros do provide more recent prebuilt binaries, you could ask > them to build using PGO (some do already I think). Yes, I can confirm that the openSUSE gccX pacakges utlize both PGO and LTO during the compiler bootstrap. So, you can use: htt

Re: new ubsan handler

On 12/19/22 10:25, Martin Uecker wrote: Am Montag, dem 19.12.2022 um 09:44 +0100 schrieb Martin Liška: On 12/17/22 20:35, Martin Uecker wrote: Hi all, what is the process for adding a new UBsan handler? Hello. Yes, we sync the run-time library from LLVM project. So a new sanitizer should

Re: new ubsan handler

On 12/17/22 20:35, Martin Uecker wrote: Hi all, what is the process for adding a new UBsan handler? Hello. Yes, we sync the run-time library from LLVM project. So a new sanitizer should go there first. We have the source in the GCC tree, but I guess this should go via LLVM? And the com

Re: Missing optimization: mempcpy(3) vs memcpy(3)

On 12/9/22 18:11, Alejandro Colomar via Gcc wrote: > I expect the compiler to be knowledgeable enough to call whatever is fastest, > whatever it is, but be consistent in both cases.  However, here are the  > results: Hi. Note the glibc implementation of mempcpy typically uses (calls) memcpy, thu

Re: About -fasan-shadow-offset option

On 11/16/22 10:01, tao.z...@amlogic.com wrote: > Dear gcc: > Hello. Based on quick discussion with Jakub, we believe fasan-shadow-symbol= would be a non-trivial amount of work and we rather suggest doing a per-system build with investigated -fasan-shadow-offset. Cheers, Martin > I am

Re: [RFC] Function Multi Versioning on Arm

On 7/18/22 12:36, Daniel Kiss via Gcc wrote: > Hello, > > We are going to add Function Multiversioning [1] support to Arm architectures. > The specification is made public as beta[2] to ensure toolchain that follows > Arm > C Language Extension will implement it in the same way. > > A few tweaks

libsanitizer: sync from master

Hi. I've just pushed libsanitizer update that was tested on x86_64-linux and ppc64le-linux systems. Moreover, I run bootstrap on x86_64-linux and checked ABI difference with abidiff. Pushed as r13-4068-g3037f11fb86eda. Cheers, Martin

Re: GCC 13.0.0 Status Report (2022-11-14), Stage 3 in effect now

On 11/15/22 11:07, Jakub Jelinek wrote: > On Tue, Nov 15, 2022 at 11:02:53AM +0100, Martin Liška wrote: >>> Is it allowed to merge libsanitizer from LLVM in stage 3? If not I'd >>> like to cherry pick some commits from LLVM [to fix some stupid errors >>

Re: Revert Sphinx documentation [Was: Issues with Sphinx]

On 11/14/22 14:06, Gerald Pfeifer wrote: > On Mon, 14 Nov 2022, Martin Liška wrote: >> The situation with the Sphinx migration went out of control. The TODO >> list overwhelmed me and there are road-blocks that can't be easily fixed >> with what Sphinx currently support

Re: GCC 13.0.0 Status Report (2022-11-14), Stage 3 in effect now

On 11/14/22 18:21, Xi Ruoyao wrote: > Hi Martin, > Hello. > Is it allowed to merge libsanitizer from LLVM in stage 3? If not I'd > like to cherry pick some commits from LLVM [to fix some stupid errors > I've made in LoongArch libasan :(]. I'm sorry but I was really busy with the porting of the

Re: Revert Sphinx documentation [Was: Issues with Sphinx]

On 11/14/22 03:49, Martin Liška wrote: > I'm going to revert the patchset during today (Monday) and I'll send a patch > with a couple > of new changes that landed in the period of time we used Sphinx. The revert is done and I included ce51e8439a491910348a1c5aea43b55f000ba8ac

Revert Sphinx documentation [Was: Issues with Sphinx]

Hi. The situation with the Sphinx migration went out of control. The TODO list overwhelmed me and there are road-blocks that can't be easily fixed with what Sphinx currently supports. That would require addition of an upstream support and a possible new Sphinx release. Let me summarize the bigge

Re: Announcement: Porting the Docs to Sphinx - tomorrow

On 11/11/22 22:10, Sandra Loosemore wrote: > On 11/11/22 13:52, Gerald Pfeifer wrote: >> On Tue, 8 Nov 2022, Martin Liška wrote: >>> After the migration, people should be able to build (and install) GCC >>> even if they miss Sphinx (similar happens now if you miss

Re: Links to web pages are broken.

On 11/11/22 13:14, Georg-Johann Lay wrote: > > > Am 11.11.22 um 09:48 schrieb Martin Liška: >> On 11/10/22 18:01, Jonathan Wakely wrote: >>> Maybe just "docs" or "trunkdocs" or "latestdocs" instead of >>> "onlinedocs-new&quo

Re: Links to web pages are broken.

On 11/10/22 18:01, Jonathan Wakely wrote: > Maybe just "docs" or "trunkdocs" or "latestdocs" instead of > "onlinedocs-new", since that is (1) very long, and (2) will look silly > in ten years when it's not new and we need to add > onlinedocs-even-newer 😉 I do support it, it would be probably nicer

Re: Links to web pages are broken.

On 11/10/22 15:45, Georg-Johann Lay wrote: Hi, I just observed that links like https://gcc.gnu.org/install/configure.html ceased to work.  Presumably this is to sphinx stuff, but it would be great if not hundreds of links across the web to GCC pages like the above would be 404. I know that th

Re: Announcement: Porting the Docs to Sphinx - 9. November 2022

On 11/9/22 18:14, Joseph Myers wrote: On Wed, 9 Nov 2022, Martin Liška wrote: 1) not synchronized content among lib*/Makefile.in and lib*/Makefile.am. Apparently, I modified the generated Makefile.in file with the rules like: doc/info/texinfo/libitm.info: $(SPHINX_FILES) + if [ x

Re: Announcement: Porting the Docs to Sphinx - 9. November 2022

On 10/20/22 18:43, Joseph Myers wrote: > On Thu, 20 Oct 2022, Martin Liška wrote: > >>> Also, but not strictly part of the release issue: >>> >>> (d) Builds with missing or old Sphinx should work regardless of whether >>> such files are in the source di

Announcement: Porting the Docs to Sphinx - tomorrow

Hi. Tomorrow in the morning (UTC time), I'm going to migrate the documentation to Sphinx. The final version of the branch can be seen here: $ git fetch origin refs/users/marxin/heads/sphinx-final $ git co FETCH_HEAD URL: https://splichal.eu/gccsphinx-final/ TL;DR; After the migration, people

Re: Announcement: Porting the Docs to Sphinx - 9. November 2022

On 10/20/22 17:35, Joseph Myers wrote: > On Thu, 20 Oct 2022, Martin Liška wrote: > >>> Could generated man and info pages be provided as a tarball on >>> gcc.gnu.org or ftp.gnu.org? >> >> Not planning doing that. > > Release tarballs (but not snaps

Re: Announcement: Porting the Docs to Sphinx - 9. November 2022

On 10/20/22 13:55, Xi Ruoyao wrote: > On Thu, 2022-10-20 at 13:53 +0200, Martin Liška wrote: >> On 10/20/22 13:49, Xi Ruoyao wrote: >>> (CC our team members.) >>> >>> On Thu, 2022-10-20 at 13:27 +0200, Martin Liška wrote: >>>>> Ouch.  This will

Re: Announcement: Porting the Docs to Sphinx - 9. November 2022

On 10/20/22 13:49, Xi Ruoyao wrote: > (CC our team members.) > > On Thu, 2022-10-20 at 13:27 +0200, Martin Liška wrote: >>> Ouch.  This will be very painful for Linux From Scratch.  We'll need to >>> add 23 Python modules to build the documentation, while we on

Re: Announcement: Porting the Docs to Sphinx - 9. November 2022

On 10/20/22 04:26, Xi Ruoyao wrote: > On Mon, 2022-10-17 at 15:28 +0200, Martin Liška wrote: >> Hello. >> >> Based on the very positive feedback I was given at the Cauldron Sphinx >> Documentation BoF, >> I'm planning migrating the documentation on 9th No

Re: Announcement: Porting the Docs to Sphinx - 9. November 2022

On 10/19/22 18:30, Sandra Loosemore wrote: > On 10/19/22 05:09, Martin Liška wrote: >> On 10/18/22 00:26, Sandra Loosemore wrote: >>> On 10/17/22 07:28, Martin Liška wrote: >>>> Hello. >>>> >>>> Based on the very positive feedback I wa

Re: Announcement: Porting the Docs to Sphinx - 9. November 2022

On 10/19/22 18:42, Joseph Myers wrote: > On Wed, 19 Oct 2022, Martin Liška wrote: > >>> Currently, there is a tarball with texinfo sources for all the manuals >>> for each version. >> >> Well, then equivalent would be packaging all .rst files together with th

Re: Announcement: Porting the Docs to Sphinx - 9. November 2022

On 10/19/22 13:09, Martin Liška wrote: > There ePUB would be likely better output format. What do you think? I've just included ePUB books: https://splichal.eu/scripts/sphinx/#epub Martin

Re: Announcement: Porting the Docs to Sphinx - 9. November 2022

On 10/18/22 00:26, Sandra Loosemore wrote: > On 10/17/22 07:28, Martin Liška wrote: >> Hello. >> >> Based on the very positive feedback I was given at the Cauldron Sphinx >> Documentation BoF, >> I'm planning migrating the documentation on 9th November. T

Re: Announcement: Porting the Docs to Sphinx - 9. November 2022

On 10/19/22 10:13, Paul Iannetta wrote: > On Wed, Oct 19, 2022 at 09:24:06AM +0200, Martin Liška wrote: >> On 10/17/22 16:16, Paul Iannetta wrote: >>> Hi Martin, >>> >>> Thank you very much for porting the documentation to Sphinx, it is >>> very conve

Re: Announcement: Porting the Docs to Sphinx - 9. November 2022

o pages on our web pages, people typically get these from their distribution packages. Does it help? Or do you expect any change regarding what we publish at: https://gcc.gnu.org/onlinedocs/ ? Cheers, Martin > > Paul > > On Mon, Oct 17, 2022 at 03:28:34PM +0200, Martin Liška wrote: &

Re: [PATCH RESEND 0/1] RFC: P1689R5 support

On 10/18/22 14:22, Ben Boeckel wrote: > On Thu, Oct 13, 2022 at 13:08:46 -0400, David Malcolm wrote: >> On Mon, 2022-10-10 at 16:21 -0400, Jason Merrill wrote: >>> David Malcolm would probably know best about JSON wrangling. >> >> Unfortunately our JSON output doesn't make any guarantees about the

GNU Tools Cauldron 2022 - video recordings

Hello, Video recordings of the GNU Tools Cauldron 2022 are available now at YouTube: https://www.youtube.com/playlist?list=PL_GiHdX17WtzDK0OVhD_u_a3ti4shpXLl Cheers, Martin

Announcement: Porting the Docs to Sphinx - 9. November 2022

Hello. Based on the very positive feedback I was given at the Cauldron Sphinx Documentation BoF, I'm planning migrating the documentation on 9th November. There are still some minor comments from Sandra when it comes to the PDF output, but we can address that once the conversion is done. The r

Re: Surprising CFG construction with goto from then to else

On 9/16/22 13:05, Jørgen Kvalsvik wrote: > Gentle ping. Any idea if the edge split is still useful and/or how to test > for it? @Honza: Can you please reply here? Thanks, Martin > > Thanks, > Jørgen > > On 08/09/2022 12:30, Jørgen Kvalsvik wrote: >> On 02/09/2022 14:22, Richard Biener wrote:

Re: [RFC] database with API information

On 9/7/22 12:56, Richard Sandiford via Gcc wrote: > Ulrich Drepper via Gcc writes: >> I talked to Jonathan the other day about adding all the C++ library APIs to >> the name hint file now that the size of the table is not really a concern >> anymore. >> >> Jonathan mentioned that he has to create

Weird instability of automake-1.15.1

Hi. I see a weird behavior when I run: AUTOCONF=autoconf-2.69 ~/bin/automake-1.15.1/bin/automake in one of my gcc git repos: $ ~/Programming/gcc/gotools> AUTOCONF=autoconf-2.69 ~/bin/automake-1.15.1/bin/automake $ git diff | cat (no output) However, if I clone a fresh repo I see: $ git clone

Re: [PATCH] gcov: fix file and function summary information

On 8/24/22 09:12, Jørgen Kvalsvik wrote: > I tested it and get the file summary as expected: > > File 'demo.cc' > Lines executed:84.62% of 26 > Branches executed:100.00% of 6 > Taken at least once:50.00% of 6 > Calls executed:100.00% of 4 > Creating 'demo.cc.gcov' > > Thanks, > Jørgen Great, I'v

[PATCH] gcov: fix file and function summary information

Patch can bootstrap on x86_64-linux-gnu and survives regression tests. Jorgen: Can you please test it before I'll install it? Thanks, Martin gcc/ChangeLog: * gcov.cc (add_line_counts): Add group functions to coverage summary. (accumulate_line_counts): Similarly for files

Re: gccgo emits GIMPLE with temporaries for boolean expressions unlike gcc, gdc

CCing Go maintainer. Martin On 8/3/22 15:25, j wrote: > > Hello, > > I've proposed a patch [1] for condition coverage profiling in gcc, > implemented in the middle-end alongside the branch coverage. I've written > most of the tests for C and a few for C++ and finally got around to try it > w

Re: Porting the Docs to Sphinx - project status

On 1/31/22 15:06, Martin Liška wrote: > Hello. > > It's about 5 months since the last project status update: > https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577108.html > Now it's pretty clear that it won't be merged before GCC 12.1 gets released. >

Re: Setting up editors for the GNU/GCC coding style?

On 7/28/22 21:49, Tim Lange wrote: > > > On Thu, Jul 28 2022 at 02:46:58 PM -0400, David Malcolm via Gcc > wrote: >> Is there documentation on setting up text editors to work with our >> coding style?  A lot of the next generation of developers aren't using >> vi or emacs; they's using VS Code,

Re: [RFC] Function Multi Versioning on Arm

On 7/22/22 10:40, Daniel Kiss wrote: > IMHO it would make sense if the “default" attribute becomes optional for > “target”. I'm not against it, but it can be done incrementally. Cheers, Martin

Re: [RFC] Function Multi Versioning on Arm

On 7/21/22 19:49, Daniel Kiss wrote: > Hello, > > Thanks for the quick reply, see mine inline. >> On 2022. Jul 19., at 12:01, Martin Liška wrote: >> >> On 7/18/22 12:36, Daniel Kiss via Gcc wrote: >>> Hello, >>> >>> We are go

Re: [RFC] Function Multi Versioning on Arm

On 7/18/22 12:36, Daniel Kiss via Gcc wrote: > Hello, > > We are going to add Function Multiversioning [1] support to Arm architectures. > The specification is made public as beta[2] to ensure toolchain that follows > Arm > C Language Extension will implement it in the same way. > > A few tweaks

Re: Creating a wrapper around a function at compile time

On 7/14/22 16:25, Erick Ochoa wrote: > > > On Thu, 14 Jul 2022 at 16:10, Martin Liška <mailto:mli...@suse.cz>> wrote: > > On 7/14/22 16:08, Erick Ochoa via Gcc wrote: > > Last time I checked, value profiling can only track a single value per

Re: Creating a wrapper around a function at compile time

On 7/14/22 16:08, Erick Ochoa via Gcc wrote: > Last time I checked, value profiling can only track a single value per > statement. Hi. Take a look at HIST_TYPE_INDIR_CALL which we use for tracking at maximum 32 (#define GCOV_TOPN_MAXIMUM_TRACKED_VALUES 32) and we use for indirect call speculative

Re: Bad performance (with GCC 11.3.0 - O3) of a small etude in C

On 7/8/22 06:31, Georgi Marinov via Gcc wrote: > Hi, > just wanted to let you know that I found that GCC 11.3.0 -O3 is generating > code with many unnecessary jumps (while CLANG 14.0.1 -O3 not) in a small > partitioning (for Quicksort) 15 lines of code etude. > In case you are interested I will s

Re: Documentation format question

On 5/27/22 22:05, Andrew MacLeod via Gcc wrote: > On 5/27/22 02:38, Richard Biener wrote: >> On Wed, May 25, 2022 at 10:36 PM Andrew MacLeod via Gcc >> wrote: >>> I am going to get to some documentation for ranger and its components >>> later this cycle. >>> >>> I use to stick these sorts things

Re: [committed] exec-stack warning for test which wants executable stacks

On 4/24/22 19:42, Jeff Law via Gcc wrote: > About a week ago many targets started failing pr94157_0.c test like this > (bfin-elf, but many other targets are also affected): > >> spawn -ignore SIGHUP /home/jlaw/test/obj/bfin-elf/obj/gcc/gcc/xgcc >> -B/home/jlaw/test/obj/bfin-elf/obj/gcc/gcc/ c_lt

Re: Switch statement optimization

On 4/18/22 16:41, Paul Koning via Gcc wrote: In switch statements with dense case values, the typical result is a jump table, which is fast. If the values are sparse, a tree of compares is generated instead. What if nearly all cases are dense but there are a few outliers? An example appears

Re: [GSoC]Bypass assembler when generating LTO object files

On 4/12/22 11:58, Richard Biener wrote: On Tue, Apr 12, 2022 at 11:20 AM Jan Hubicka via Gcc wrote: Hi, On 08-Apr-2022, at 6:32 PM, Jan Hubicka wrote: Ankur, I was browsing the list of submitted GSoC projects this year and the project regarding bypassing assembler when generating LTO ob

Re: MC/DC support for gcov?

On 3/31/22 16:55, Sebastian Huber wrote: Hello, gcov supports currently branch coverage. Some projects require modified condition/decision coverage (MC/DC): https://en.wikipedia.org/wiki/Modified_condition/decision_coverage In general, 100% branch coverage does not imply 100% MC/DC coverage:

Re: Porting the Docs to Sphinx - project status

On 2/4/22 14:40, Matthias Klose wrote: On 1/31/22 15:06, Martin Liška wrote: Hello. It's about 5 months since the last project status update: https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577108.html Now it's pretty clear that it won't be merged before GCC 12.1 gets rele

Re: what is the difference with and without crc extension support

same. According to your experience， what is the reason about it? Dunno. Cheers, Martin Martin Liška 于2022年3月3日周四 21:48写道： On 3/3/22 14:41, Dongjiu Geng via Gcc wrote: Hi, My program does not use CRC instructions，but I find the compiled binary has much difference between using

Re: what is the difference with and without crc extension support

On 3/3/22 14:41, Dongjiu Geng via Gcc wrote: Hi, My program does not use CRC instructions，but I find the compiled binary has much difference between using "-march=armv8-a+crc" and using "-march=armv8-a". Even stranger, when I use "-march=armv8-a+crc", I find my compiled binary can not run.

Porting the Docs to Sphinx - project status

Hello. It's about 5 months since the last project status update: https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577108.html Now it's pretty clear that it won't be merged before GCC 12.1 gets released. So where we are? I contacted documentation maintainers (Gerald, Sandra and Joseph) at t

Re: [PATCH] git-backport: support renamed .cc files in commit message.

On 1/18/22 20:10, Harald Anlauf via Fortran wrote: Am 17.01.22 um 22:26 schrieb Martin Liška: On 1/12/22 16:54, Martin Liška wrote: There's a patch that enhances git-backport so that it updates commit messages for files which name ends now with .cc and is still .c on a branch. The patc

Re: [ANNOUNCEMENT] Mass rename of C++ .c files to .cc suffix is going to happen on Jan 17 evening UTC TZ

On 1/18/22 14:10, Richard Earnshaw wrote: Is that worth adding to contrib/gcc-git-customization.sh ? Yes, can you please do that? Thanks, Martin

Re: [ANNOUNCEMENT] Mass rename of C++ .c files to .cc suffix is going to happen on Jan 17 evening UTC TZ

LGTM. I've just installed that, the Ada testsuite should work now. Martin

Re: [ANNOUNCEMENT] Mass rename of C++ .c files to .cc suffix is going to happen on Jan 17 evening UTC TZ

On 1/18/22 09:53, Richard Biener wrote: Technically all release managers are also global reviewers, but I agree the speciality of the Ada setup (esp. the runtime being in gcc/) could have been anticipated. Yeah, I thought that building Ada FE is enough for testing effort, sorry. I would like t

Re: [ANNOUNCEMENT] Mass rename of C++ .c files to .cc suffix is going to happen on Jan 17 evening UTC TZ

On 1/18/22 09:36, Eric Botcazou wrote: Martin, The renaming patches have been just installed and I've built a few target compilers so far. I'll be online in ~10 hours from now so I can address potential issues caused by the patch. Who approved it though? Release managers. The renaming of

Re: [ANNOUNCEMENT] Mass rename of C++ .c files to .cc suffix is going to happen on Jan 17 evening UTC TZ

On 1/13/22 12:01, Martin Liška wrote: Hello. Based on the discussion with release managers, the change is going to happen after stage4 begins. Martin Hi. The renaming patches have been just installed and I've built a few target compilers so far. I'll be online in ~10 hours fro

Re: [PATCH] git-backport: support renamed .cc files in commit message.

On 1/12/22 16:54, Martin Liška wrote: There's a patch that enhances git-backport so that it updates commit messages for files which name ends now with .cc and is still .c on a branch. The patch has been installed as I've made the renaming now. Cheers, Martin

Re: git hooks: too strict check

On 1/14/22 17:10, Michael Matz wrote: You can't have that, the check is correct. There are filesystems (NTFS for instance) that are case-preserving but case-insensitive, on those you really can't have two files that differ only in casing. You need to find a different solution, either consistent

Re: [PATCH] git-backport: support renamed .cc files in commit message.

On 1/14/22 08:44, Bernhard Reutner-Fischer wrote: On Wed, 12 Jan 2022 16:54:46 +0100 Martin Liška wrote: +def replace_file_in_changelog(lines, filename): +if not filename.endswith('.cc'): +return + +# consider all componenets of a path: gcc/ipa-icf.cc +whil

git hooks: too strict check

Hello. I'm working on a testsuite clean-up where some of the files are wrongly named. More precisely, so files have .cc extension and should use .C. However there's existing C test-case and it leads to: marxin@marxinbox:~/Programming/gcc/gcc/testsuite> find . -name test-asm.* ./jit.dg/test-asm.C

[ANNOUNCEMENT] Mass rename of C++ .c files to .cc suffix is going to happen on Jan 17 evening UTC TZ

Hello. Based on the discussion with release managers, the change is going to happen after stage4 begins. Martin

[PATCH] git-backport: support renamed .cc files in commit message.

Hi. There's a patch that enhances git-backport so that it updates commit messages for files which name ends now with .cc and is still .c on a branch. Example usage: $ git show test commit 8ed4b2cb9aa158c0ef418fd1ac66271664904604 (test) Author: Martin Liska Date: Wed Jan 12 16:08:13 2022 +010

Re: [PATCH] Mass rename of C++ .c files to .cc suffix

On 1/11/22 17:16, Jakub Jelinek wrote: On Tue, Jan 11, 2022 at 05:03:34PM +0100, Martin Liška wrote: On 1/11/22 16:56, Jakub Jelinek wrote: While e.g. libcpp or gcc are in C++. Which means I should rename .c files under libcpp, right? Is there any other folder from gcc/ and libcpp/ that

Re: [PATCH] Mass rename of C++ .c files to .cc suffix

On 1/11/22 16:56, Jakub Jelinek wrote: While e.g. libcpp or gcc are in C++. Which means I should rename .c files under libcpp, right? Is there any other folder from gcc/ and libcpp/ that would need that as well? Martin

Re: [PATCH] Mass rename of C++ .c files to .cc suffix

On 1/11/22 16:48, Toon Moene wrote: On 1/11/22 13:56, Martin Liška wrote: Patch can bootstrap on x86_64-linux-gnu and survives regression tests. Plus it survives build of all FEs (--enable-languages=all) on x86_64-linux-gnu and I've built all cross compilers. Does this also rename .c

[PATCH] Mass rename of C++ .c files to .cc suffix

Hello. I've got a patch series that does the renaming. It contains of 2 automatic scripts ([1] and [2]) that were run as: $ gcc-renaming-candidates.py gcc --rename && git commit -a -m 'Rename files.' && rename-gcc.py . -vv && git commit -a -m 'Automatic renaming' The first scripts does the ren

Re: Mass rename of C++ .c files to .cc suffix?

On 1/7/22 12:05, Jonathan Wakely via Gcc wrote: References to .cc files in the commit message won't get changed to .c automatically, but maybe the gcc-backport alias could be taught to do that. Hi. +1 for me. I'm willing to extend gcc-backport script to support renaming files in the commit mes

Re: Issue with a flag that I defined getting set to zero

On 1/7/22 09:30, Gary Oblock wrote: Regarding the corporate legal gibberish. It's automatic and not under my control also we're not supposed to use private emails for work... I respect that. But please respect me that I won't reply to your emails any longer. I don't want to follow the condition

Re: Issue with a flag that I defined getting set to zero

On 1/7/22 09:10, Gary Oblock via Gcc wrote: An optimization flag that I recently added is being set to zero in push_cfun (which after a couple of levels of calls cl_optimization_restore to this.) Question is: what's the value of the flag in your IPA pass if you set -finterleaving-index-32-bits?

Update of git-hooks (uses Python 3.x)?

Hello. Note that binutils updated the git-hooks, which now uses Python 3: https://github.com/AdaCore/git-hooks I'm asking because we're facing again an encoding issue (spotted by Jakub): remote: Traceback (most recent call last): remote: File "hooks/post_receive.py", line 118, in remote:

Re: New ThreadSanitizer runtime (v3)

On 11/30/21 05:17, Dmitry Vyukov wrote: On Mon, 29 Nov 2021 at 19:16, Martin Liška wrote: On 11/22/21 20:01, Dmitry Vyukov wrote: I've already reverted the change. So I will include a fix into the next version. Thanks for notifying. Hello. Am I correct that the patch set is inst

Re: gccadmin hooks: make it a public git repo

On 12/14/21 17:14, Jonathan Wakely wrote: git clone gcc.gnu.org:/home/gccadmin/hooks-bin Works for me as well, thanks! So as Joseph mentioned, we are really prepared for the transition as there's only the email_to.py script that can be ported. Cheers, Martin

Re: gccadmin hooks: make it a public git repo

On 12/13/21 21:58, Joseph Myers wrote: There is a repository (/home/gccadmin/hooks-bin/.git), it's just not a bare one (so not suitable for pushing to) and not public (but anyone in the gcc group should be able to clone it, read-only, over ssh). All right, I would be happy at least with that. S

Re: gccadmin hooks: make it a public git repo

21 09:11, Martin Liška wrote: PING^1 On 1/14/21 10:02 AM, Martin Liška wrote: On 1/13/21 6:00 PM, Joseph Myers wrote: I'm fine with having it set up with a public repository. Ok, can you please do it Joseph? If you have a public (bare) repository that would of course need to have its ow

Re: New ThreadSanitizer runtime (v3)

On 11/22/21 20:01, Dmitry Vyukov wrote: I've already reverted the change. So I will include a fix into the next version. Thanks for notifying. Hello. Am I correct that the patch set is installed again? Any near future plans for another revert of the patch? Do you think it's the right time to

Re: distinguishing gcc compilation valgrind false positives

On 11/25/21 13:00, Zdenek Sojka via Gcc wrote: which is already reported ashttps://gcc.gnu.org/PR101292 , the other warnings are still there: Hello. Please create a bugzilla entry for this. Thanks, Martin

Re: New ThreadSanitizer runtime (v3)

On 11/22/21 20:00, Dmitry Vyukov wrote: Not sure about gcc, but in clang the old no_sanitize_thread attribute disabled only part of instrumentation (only memory accesses, but not atomics and function entry/exit). The new attribute disables all instrumentation. And what about no_sanitize("thread

Re: New ThreadSanitizer runtime (v3)

On 11/22/21 16:22, Dmitry Vyukov wrote: I wanted to give heads up regarding a significant re-design of the ThreadSanitizer runtime: https://reviews.llvm.org/D112603 Currently it's submitted: https://github.com/llvm/llvm-project/commit/1784fe0532a69ead17793bced060a9bf9d232027 And I noticed the f

Re: New ThreadSanitizer runtime (v3)

On 11/22/21 16:22, Dmitry Vyukov wrote: Hi gcc developers, Hello. I wanted to give heads up regarding a significant re-design of the Thanks for it. ThreadSanitizer runtime: https://reviews.llvm.org/D112603 Currently it's submitted: https://github.com/llvm/llvm-project/commit/1784fe0532a6

Re: [PATCH] Bump required minimum DejaGnu version to 1.5.3

On 11/4/21 12:55, Segher Boessenkool wrote: On Fri, Oct 29, 2021 at 09:32:21AM +0200, Richard Biener via Gcc-patches wrote: On Fri, Oct 29, 2021 at 2:42 AM Bernhard Reutner-Fischer via Gcc-patches wrote: From: Bernhard Reutner-Fischer Bump required DejaGnu version to 1.5.3 (or later). Ok fo

Re: Old installation docs

On 10/20/21 18:59, Jonathan Wakely via Gcc wrote: On Wed, 20 Oct 2021 at 17:40, Joseph Myers wrote: On Wed, 20 Oct 2021, Jonathan Wakely via Gcc wrote: https://gcc.gnu.org/install/ says: "There are also some old installation instructions , which are most

Re: Broken links on website

On 10/12/21 10:12, Ryan Plant wrote: Just a quick heads-up , https://gcc.gnu.org/install/binaries.html currently has two broken links. "MinGW" leads to a dead site covered in domain-parking ads, and the "mingw-w64" one 404s. I believe the current links for those projects are https://osdn.net/proj

Re: [TCWG CI] 471.omnetpp slowed down by 8% after gcc: Avoid invalid loop transformations in jump threading registry.

On 10/11/21 13:05, Maxim Kuvyrkov wrote: On 8 Oct 2021, at 13:22, Martin Jambor wrote: Hi, On Fri, Oct 01 2021, Gerald Pfeifer wrote: On Wed, 29 Sep 2021, Maxim Kuvyrkov via Gcc wrote: Configurations that track master branches have 3-day intervals. Configurations that track release branches

Re: Exact inform format escape sequence (GCC 10 or GCC 11)

On 9/10/21 15:05, Basile Starynkevitch wrote: Hello all, In the Bismon static source code analyzer on https://github.com/bstarynk/bismon/ commit ad8b6270691e (funded by http://decoder-project.eu/ ) which contains some GPLv3+ GCC plugin code under directory gccplugins/ I am getting when c

Re: Error message from push to branch

On 9/13/21 20:04, Thomas König wrote: Hi, I tried to merge trunk to into the coarray_native branch in preparation of some further work.  After some problems, it seems that the commit worked.  However, pushing it resulted in an error message, and it seems there was no e-mail to the gcc-cvs mailin

Re: GCC documentation: porting to Sphinx

On 8/10/21 17:43, Martin Liška wrote: Hello. I've just pushed the rebased branch here: https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=log;h=refs/users/marxin/heads/sphinx-v4 which I force push once I rebase it. One can fetch the branch with: $ git fetch origin refs/users/marxin/heads/sphi

Re: post-commit hook failure

On 8/25/21 17:56, Michael Matz wrote: Hello, On Wed, 25 Aug 2021, Martin Liška wrote: remote: File "hooks/post_receive.py", line 47, in post_receive_one remote: update.send_email_notifications() remote: File "/sourceware1/projects/src-home/git-hooks/hooks/upda

  1   2   3   4   5   6   7   >