Re: Can we please have the old mailing list back

On Fri, 2020-03-27 at 10:45 -0400, Christopher Faylor wrote: > On Fri, Mar 27, 2020 at 07:00:59AM +0100, Bernd Edlinger wrote: > > PS: I would CC you, Christopher Faylor, but your email address is > > "cgf-use-the-mailinglist-ple...@gnu.org", so whatever I send there > > would not reach you. > > W

Re: Can we please have the old mailing list back

On Sat, 2020-03-28 at 18:46 +, Maciej W. Rozycki wrote: > On Fri, 27 Mar 2020, Jeff Law via Gcc wrote: > > > As an ex IT guy, I've gone both directions depending on the project I was > > supporting and certainly see the pros and cons of going highly customized v

Re: Request to deprecate offloading to HSAIL in GCC

On Thu, 2020-04-09 at 21:17 +0200, Jakub Jelinek wrote: > On Thu, Apr 09, 2020 at 07:43:02PM +0200, Martin Jambor wrote: > > Therefore it is only fair to warn the community and any possible hidden > > users or would-be users that it is very likely that I will propose > > removal of HSAIL offloading

Re: SH Port Status

On Mon, 2020-04-20 at 14:47 -0500, Joel Sherrill wrote: > Hi > > Over at RTEMS, we were discussing ports to deprecate/obsolete > and the SH seems to be on everyone's candidate list. I can't seem > to find any gcc test results sh-unknown-elf since 2009 and none > for sh-rtems. I know I posted some

Re: SH Port Status

On Mon, 2020-04-20 at 15:29 -0500, Joel Sherrill wrote: > > > On Mon, Apr 20, 2020, 3:13 PM Jeff Law wrote: > > On Mon, 2020-04-20 at 14:47 -0500, Joel Sherrill wrote: > > > Hi > > > > > > Over at RTEMS, we were discussing ports to deprecate/obsolete > > > and the SH seems to be on everyone's c

Re: AVR CC0 transition

On Wed, 2020-04-22 at 22:01 +0530, Senthil Kumar via Gcc wrote: > Hi, > > I'm thinking about attempting to do the CC0 transition for the > AVR port in my spare time. I've read the CC0Transition gcc wiki > page, and as the AVR ISA does not have non-condition-code > clobbering arithmetic instructio

Re: AVR CC0 transition

On Wed, 2020-04-22 at 19:52 +0200, Moritz Strübe wrote: > Am 22.04.2020 um 18:38 schrieb Jeff Law via Gcc: > > [..] as the > > alternative would be dropping the AVR port. > > Shouldn't that work be sponsored by Microchip (or whoever currently owns > AVR)? Ardu

Re: AVR CC0 transition

On Thu, 2020-04-23 at 07:41 +0530, Senthil Kumar wrote: > On Wed, Apr 22, 2020 at 10:08 PM Jeff Law wrote: > > On Wed, 2020-04-22 at 22:01 +0530, Senthil Kumar via Gcc wrote: > > > Hi, > > > > > > I'm thinking about attempting to do the CC0 transition for the > > > AVR port in my spare time. I'v

Re: Not usable email content encoding

On Thu, 2020-04-23 at 09:34 +0100, Jonathan Wakely via Gcc wrote: > On Thu, 23 Apr 2020 at 06:49, Florian Weimer wrote: > > * Tamar Christina: > > > > > A bit late to the party, but this really doesn't work that well > > > because until recent version of gitlab there was no fairness > > > guarante

Re: Not usable email content encoding

On Thu, 2020-04-23 at 06:46 -0500, Segher Boessenkool wrote: > Hi! > > On Thu, Apr 23, 2020 at 12:54:04AM +, Tamar Christina wrote: > > but trains for GCC Will likely be very short because of Changelog conflicts. > > Why that? Your patches should *not* touch changelog files, ever. > > For C

Re: Not usable email content encoding

On Thu, 2020-04-23 at 15:14 -0600, Tom Tromey wrote: > > > > > > "Segher" == Segher Boessenkool writes: > > Segher> My point was that this should *never* be part of patches, already. > > FWIW, I use a few scripts so that I can keep ChangeLogs as files. > That's what I do when working on gdb. >

Re: Not usable email content encoding

On Fri, 2020-04-24 at 22:01 +0200, Martin Jambor wrote: > Hi, > > On Fri, Apr 24 2020, Segher Boessenkool wrote: > > Hi! > > > > On Fri, Apr 24, 2020 at 05:48:38PM +0200, Thomas Koenig wrote: > > > > Of course, better would be to remove ChangeLogs entirely (including not > > > > putting anything

Re: GCC Testsuite patches break AIX

On Wed, 2020-05-27 at 11:16 -0300, Alexandre Oliva wrote: > Hello, David, > > On May 26, 2020, David Edelsohn wrote: > > > Complaints about -dA, -dD, -dumpbase, etc. > > This was the main symptom of the problem fixed in the follow-up commit > r11-635-g6232d02b4fce4c67d39815aa8fb956e4b10a4e1b >

Re: AArch64 failures on tester

On Fri, 2020-06-05 at 14:27 +, Alex Coplan wrote: > Hello, > > Recently Jeff's tester picked up some test failures on AArch64. These > are now fixed as of commit ab563903 but the aarch64-linux-gnu build is > still failing with the following output: > > Old tests that failed, that have disap

Re: [haifa-sched][restore_pattern] Can we recalculate INSN_TICK for the dependence type of REG_DEP_CONTROL？

On Thu, 2020-04-23 at 10:40 +, xuemaosheng wrote: > Product: GCC > Component: rtl-optimization > Version: 7.3.0 > > > If we add the flag DO_PREDICATION in scheduling ebb, the compiler will try to > predicate the insn when the producer insn has been issued, > and put the consumer insn into su

Re: Hello gcc. Why -fvtable-gc was removed from the compiler?

On Tue, 2020-06-09 at 20:35 +, sotrdg sotrdg via Gcc wrote: > What’s wrong with eliminating unused virtual functions in the binary? Nothing inherently wrong with the concept. But the implementation left a lot to be desired and I think it was ultimately scrapped as unmaintainable. jeff

Re: Re-optimize instrumented GIMPLE code

On Wed, 2020-06-17 at 15:10 +0800, Shuai Wang via Gcc wrote: > Dear Martin, > > Thanks for the information. I am tentatively experimenting some random > gadgets; given the critical if condition belonging to each sanitizer check, > i will do some data flow analysis and then decide whether to remove

Re: Hoisting DFmode loads out of loops..

On Thu, 2020-06-25 at 15:46 -0400, Alan Lehotsky wrote: > I’m working on a GCC 8.3 port to a load/store architecture with a 32-bit > data-path between registers and memory; > > looking at the gcc.dg/loop-9.c test, I fail to pass because I have split the > move of a double constant to memory in

Re: Hoisting DFmode loads out of loops..

On Fri, 2020-06-26 at 01:24 +, Alan Lehotsky wrote: > > On Jun 25, 2020, at 6:37 PM, Jeff Law wrote: > > > > On Thu, 2020-06-25 at 15:46 -0400, Alan Lehotsky wrote: > > > I’m working on a GCC 8.3 port to a load/store architecture with a 32-bit > > > data-path between registers and memory;

Re: Should the `expand` functions in builtin.c generate MEM patterns with ptr_mode addresses (instead of Pmode)

On Wed, 2020-07-01 at 11:19 +0100, Matthew Malcomson wrote: > Hello, > > I asked on IRC on Monday but since it didn't get any responses and the > mailing list doesn't require someone paying attention at the moment I > ask I'm asking here too. > > > I've seen that `expand_builtin_init_trampoli

Re: Clobber REG_CC only for some constraint alternatives?

On Fri, 2020-08-14 at 16:46 +0530, Senthil Kumar Selvaraj wrote: > Hi, > > I'm working on porting AVR to MODE_CC, and there are quite a few > patterns that clobber the condition code reg only for certain > constraint alternatives. For e.g., Yea. H8 has the same issue. It's worth noting tha

Re: Clobber REG_CC only for some constraint alternatives?

On Thu, 2020-08-20 at 21:36 +0530, Senthil Kumar Selvaraj via Gcc wrote: > Pip Cet writes: > > > On Tue, Aug 18, 2020 at 6:52 AM Senthil Kumar Selvaraj > > wrote: > > > > recognize such insns, but as it stands that define_insn would > > > > recognize the incorrect insn: > > > > > > > > [(set (re

Re: Does -fstack-protector really need to clear registers?

On Wed, 2020-08-05 at 18:12 +0100, Richard Sandiford wrote: > PR96191 [https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96191] > was a bug raised against the aarch64 implementation of -fstack-protector. > As it happens, the same bug affected arm, but AFAICT those are the only > two affected targets. >

Re: Clobber REG_CC only for some constraint alternatives?

On Tue, 2020-08-25 at 23:58 -0400, Hans-Peter Nilsson wrote: > On Mon, 24 Aug 2020, Jeff Law via Gcc wrote: > > On Thu, 2020-08-20 at 21:36 +0530, Senthil Kumar Selvaraj via Gcc wrote: > > > The post-reload splitter introduces the clobber. The wiki > > > suggests

Re: Clobber REG_CC only for some constraint alternatives?

On Wed, 2020-08-26 at 11:18 +, Pip Cet wrote: > On Mon, Aug 24, 2020 at 6:18 PM Jeff Law wrote: > > > The post-reload splitter introduces the clobber. The wiki > > > suggests that approach if most insns clobber REG_CC, perhaps because of > > > the missed optimizations you describe below? > > I

Re: Clobber REG_CC only for some constraint alternatives?

On Thu, 2020-08-27 at 16:31 +0530, Senthil Kumar Selvaraj wrote: > Pip Cet writes: > > > On Mon, Aug 24, 2020 at 6:18 PM Jeff Law wrote: > > > > The post-reload splitter introduces the clobber. The wiki > > > > suggests that approach if most insns clobber REG_CC, perhaps because of > > > > the mi

Re: Forbid emiting lwl, lwr, swl and swr in gcc 3.4.1

On 9/18/20 8:13 AM, sathesh edara via Gcc wrote: > Hi All, >I am looking for a patch file to forbid emitting lwl/lwr/swl/swr > instructions in gcc-5.5.0 for mips. > I see the link below, which has already submitted a patch ( gcc 3..4.1) for > this. > > https://gcc.gnu.org/pipermail/gcc/2005-Fe

Re: CSE deletes valid REG_EQUAL?

On 11/12/20 7:02 PM, Xionghu Luo via Gcc wrote: > Hi all, > > In PR51505(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51505), Paolo Bonzini > added the code to delete REG_EQUAL notes in df_remove_dead_eq_notes: > > gcc/df-problems.c: > df_remove_dead_eq_notes (rtx_insn *insn, bitmap live) > { >

Re: Do we need to do a loop invariant motion after loop interchange ?

On 11/23/19 11:26 PM, Bin.Cheng wrote: > On Fri, Nov 22, 2019 at 3:23 PM Bin.Cheng wrote: >> On Fri, Nov 22, 2019 at 3:19 PM Richard Biener >> wrote: >>> On November 22, 2019 6:51:38 AM GMT+01:00, Li Jia He >>> wrote: On 2019/11/21 8:10 PM, Richard Biener wrote: > On Thu, Nov 21

Re: CSE deletes valid REG_EQUAL?

On 11/13/20 6:55 AM, Segher Boessenkool wrote: > Hi guys, > > On Thu, Nov 12, 2020 at 09:10:14PM -0700, Jeff Law wrote: >> On 11/12/20 7:02 PM, Xionghu Luo via Gcc wrote: >>> The output shows "REQ_EQUAL r118:DI+0x66546b64" is deleted by >>> df_remove_dead_eq_notes, >>> but r120:DI is not REG_DE

Re: Git commit "Author: [...] via Gcc-patches " (was: [gcc r11-5068] Update documentation for spec files)

ia Gcc-patches > ", etc. > > ... which occasionally then ends up in Git commit author: > > On 2020-11-17T00:15:36+, Jeff Law via Gcc-cvs wrote: >> https://gcc.gnu.org/g:a019766f996f57e53a8d1a9e72033e1e1487a150 >> >> commit r11-5068-ga019766f996f57e53a8d1a9e7203

Re: Incremental updating of SSA_NAMEs that are passed to b_c_p

On 10/27/20 12:34 PM, Ilya Leoshkevich wrote: > Hi, > > I'd like to revive the old discussion regarding the interaction of > jump threading and b_c_p causing the latter to incorrectly return 1 in > certain cases: > > https://gcc.gnu.org/pipermail/gcc-patches/2020-June/547236.html > https://gcc.g

Re: DWARF64 gcc/clang flag discussion

On 11/23/20 7:38 PM, David Blaikie via Gcc wrote: > On Mon, Nov 23, 2020 at 12:32 AM Richard Biener > wrote: >> On Sat, Nov 21, 2020 at 1:21 AM m...@klomp.org wrote: >>> On Fri, Nov 20, 2020 at 08:22:26PM +, Alexander Yermolovich wrote: On llvm side of compiler world there has been wo

Re: DWARF64 gcc/clang flag discussion

On 11/23/20 8:03 PM, David Blaikie wrote: > On Mon, Nov 23, 2020 at 6:59 PM Jeff Law wrote: >> >> >> On 11/23/20 7:38 PM, David Blaikie via Gcc wrote: >>> On Mon, Nov 23, 2020 at 12:32 AM Richard Biener >>> wrote: On Sat, Nov 21, 2020 at 1:21 AM m...@klomp.org wrote: > On Fri, Nov 20

Re: DWARF64 gcc/clang flag discussion

On 11/24/20 4:11 AM, Jakub Jelinek via Gcc wrote: > On Tue, Nov 24, 2020 at 12:04:45PM +0100, Mark Wielaard wrote: >> Hi, >> >> On Tue, 2020-11-24 at 08:50 +0100, Richard Biener wrote: >>> On Tue, Nov 24, 2020 at 8:45 AM Jakub Jelinek wrote: I agree with Richard and I'd lean towards -gdwar

Re: Possible code to remove DECL_NONSHAREABLE?

On 11/27/20 5:47 AM, Matthew Malcomson via Gcc wrote: > Hi there, > > I was just looking through the history of how some code came about, > and get the impression that DECL_NONSHAREABLE was meant to be removed. > > It seems like it was added to solve PR49103, with the idea that it > could be rem

Re: DejaGnu diagnostics checking confused, possibly related to 'dg-line'?

On 11/24/20 6:16 AM, Thomas Schwinge wrote: > Hi! > > Ping. Anybody got an opinion on the approach we should take? Could we set warning_threshold to a value to inhibit this behavior completely.  It seems backwards to me that warnings have this effect. Jeff

Re: RISC-V -menable-experimental-extensions option

On 12/7/20 6:06 PM, Jim Wilson wrote: > I'm not aware of any other target that has a similar feature, so I thought > a bit of discussion first might be useful. > > For most ISAs, there is one organization that owns it, and does development > internally, in private. For RISC-V, the ISA is owned

Re: Pytest usage in DejaGNU?

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 pyte

Re: CC0 removal branch

On 12/15/20 10:27 AM, Segher Boessenkool wrote: > Hi! > > I have updated my CC0 removal branch I started in 2019: > refs/users/segher/heads/cc0 > (yes I know this needs some patch series work; this branch rebases). > > I have tested it all on powerpc*, and sill test it with cross-compilers > t

Re: Copyright assignment for Rust-GCC

On 1/4/21 3:28 AM, Nala Ginrut via Gcc wrote: > Hi Folks! > This mail is about the development of Rust frontend of GCC. > > To avoid misunderstanding, please let me introduce Rust-GCC briefly. > In 2013, Philip Herron had announced the project in GCC mailing-list: > https://gcc.gnu.org/legacy-ml

Re: Security vulnerabilities affects core API authorization of gnu.org

On 1/4/21 3:23 AM, Salah Mosbah via Gcc wrote: > Hi Janus, > > How can I report some high impact security vulnerabilities that I have > found on gnu.org > web app? > > Also, does gnu.org has a bug bounty program or reporting bugs reward policy? > > The vulnerabilities that I have found affects t

Re: Security vulnerabilities affects core API authorization of gnu.org

On 1/4/21 10:40 AM, Salah Mosbah wrote: > Hi Jeff, > > Does gnu.org  has a bug bounty program or reporting > bugs reward policy? I have no idea. jeff >

Re: gengtype and automatically generated files

On 1/4/21 10:40 AM, Bill Schmidt via Gcc wrote: > Hi!  I'm attempting to do something that may not have been done > before, so I'm looking for advice, or a pointer to where, in fact, it > has been done before. :) > > I'm automatically generating a back-end header file that declares some > struct

Re: Copyright assignment for Rust-GCC

On 1/4/21 11:01 PM, Eric Gallager via Gcc wrote: > On Mon, Jan 4, 2021 at 11:13 AM David Edelsohn via Gcc > wrote: > >> On Mon, Jan 4, 2021 at 5:29 AM Nala Ginrut via Gcc >> wrote: >>> Hi Folks! >>> This mail is about the development of Rust frontend of GCC. >>> >>> To avoid misunderstanding,

Re: Fw: Problems with compiling autogen with GCC8 or newer versions

On 1/8/21 10:39 AM, Bruce Korb via Gcc wrote: > Hi, > > You are supposed to be able to post once you've subscribed. > > Also, GCC's code analysis is wrong. "name_bf" contains *NO MORE* than > MAXNAMELEN characters. That is provable. > > "def_str" points into a buffer of size ((MAXNAMELEN * 2) +

Re: Reporting a typo in gfortran intrinsic procedure webpage

On 1/24/21 6:04 PM, zheng via Gcc wrote: > I'd like to report a typo on page > https://gcc.gnu.org/onlinedocs/gfortran/ANINT.html#ANINT . In the last table > on this webpage, AINT should be ANINT. Thanks.  This is what I pushed to the trunk to fix the typo: Jeff commit 34215a7a3a359d700a520

David Malcolm as GCC static analyzer maintainer

I am pleased to announce that the GCC Steering Committee has appointed David Malcolm as maintainer of the GCC static analyzer. David, please update your listing in the MAINTAINERS file. Thanks, Jeff

Dimitar Dimitrov as TI PRU maintainer

I am pleased to announce that the GCC Steering Committee has appointed Dimitar Dimitrov as maintainer of the TI PRU port in GCC. Dimitar, please update your listing in the MAINTAINERS file. Sorry it's taken so long to make this happen.  It just kept slipping off my radar. Thanks, Jeff

Re: Remove RMS from the GCC Steering Committee

Setting aside whether or not RMS should be associated with the GCC project for a bit, I'm particularly concerned about the tone of some of the messages on this thread.  People can and will have differences, and that is fine.  But the discussion needs to stay civil. To those who have crosse

Re: Remove RMS from the GCC Steering Committee

On 3/27/2021 2:49 PM, Martin Liška wrote: On 3/26/21 9:02 PM, Nathan Sidwell wrote: Dear members of the GCC Steering Committee (SC),  I ask you to remove Richard Stallman (RMS) I do fully support Nathan's request. Speaking strictly for myself, not as a representative of the steering commi

Re: RMS removed from the GCC Steering Committee (was: Remove RMS...)

On 3/31/2021 5:11 PM, Giacomo Tesio wrote: 10 out of 13 members of the GCC steering committee work either for American corporations (8), their subsidiaries (1) or an American University (1) recently covered by the press in India [3]. Also, 4 of these work for the same corporation (IBM / Red Ha

Re: GCC association with the FSF

On 4/7/2021 11:17 AM, Jonathan Wakely via Gcc wrote: On Wed, 7 Apr 2021 at 15:04, David Malcolm wrote: For myself, I'm interested in copyleft low-level tools being used to build a Free Software operating system, but the "GNU" name may be permanently tarnished for me; I have no wish to be assoc

Re: Default debug format for AVR

On 4/8/2021 8:06 AM, Simon Marchi via Gcc wrote: On 2021-04-08 9:11 a.m., David Edelsohn wrote: AIX continues to use and support STABS, although it is transitioning to DWARF. If this is intended as a general statement about removal of STABS support in GCC, Yes, it is. Richard. Richard, It

Re: GCC association with the FSF

On 4/13/2021 12:01 AM, Richard Biener via Gcc wrote: On Mon, Apr 12, 2021 at 11:24 PM Nathan Sidwell wrote: On 4/12/21 5:32 AM, Richard Biener via Gcc wrote: Please concentrate on the important things, we're supposed to get a release of GCC 11 out of the door. Then it is important this is

Re: Default debug format for AVR

Agreed. I'd bet AIX is the outlier here and that most, if not all, other ports that may currently be stabs-by-default can switch to dwarf-by-default with no significant fallout. So we fix everything we can while we wait for AIX to move forward. I am not requesting a continuation of support

Re: GCC association with the FSF

On 4/13/2021 10:52 AM, Thomas Koenig wrote: On 13.04.21 16:40, Jeff Law via Gcc wrote: An EGCS-like split like we had in the late 90s is, IMHO, a definite possibility here Such a move would, in all probability, leave both parts of the split GCC with too few developers to compete against

Re: GCC association with the FSF

On 4/13/2021 11:32 AM, Thomas Koenig via Gcc wrote: On 13.04.21 19:19, Jeff Law via Gcc wrote: I'm not sure there'll be that much of a community split.  Based on what I've seen *so far* it'd be less of a split than we had with EGCS.  But that's precisely why

Re: removing toxic emailers

On 4/14/2021 8:08 AM, Nathan Sidwell wrote: On 4/14/21 9:18 AM, Eric S. Raymond wrote: Nathan Sidwell : Do we have a policy about removing list subscribers that send abusive or other toxic emails?  do we have a code of conduct?  Searching the wiki or website finds nothing.  The mission stat

Re: GCC association with the FSF

On 4/14/2021 6:08 AM, Richard Biener via Gcc wrote: On April 14, 2021 12:19:16 PM GMT+02:00, Jonathan Wakely via Gcc wrote: N.B. Jeff is no longer @redhat.com so I've changed the CC On Wed, 14 Apr 2021 at 11:03, Thomas Koenig wrote: - All gfortran developers move to the new branch. This

Re: removing toxic emailers

On 4/14/2021 8:49 AM, Jonathan Wakely via Gcc wrote: On Wed, 14 Apr 2021 at 15:39, Thomas Koenig wrote: On 14.04.21 15:18, Eric S. Raymond wrote: A strong norm about off-list behavior and politics being out of bounds here is also helpful. That would have banned the whole discussion about the

Re: GCC association with the FSF

On 4/14/2021 10:55 AM, Christopher Dimech wrote: Sent: Thursday, April 15, 2021 at 4:35 AM From: "Toon Moene" To: "Jeff Law" , "Richard Biener" , "Jonathan Wakely" , "Jonathan Wakely via Gcc" , "Thomas Koenig" Subject: Re: GCC as

Re: removing toxic emailers

On 4/14/2021 2:39 PM, Ian Lance Taylor wrote: On Wed, Apr 14, 2021 at 9:08 AM Jeff Law via Gcc wrote: once or twice when physical violence with threatened, but that's about it (aside from spammers). I don't think we want to get too deep into moderation and the like -- IMHO it sh

Re: removing toxic emailers

On 4/15/2021 2:26 PM, Chris Punches via Gcc wrote: What I see here in sum is another high level tightly integrated Red Hat employee saying the gist of "I'm really not saying it out of my employer's interest and it has nothing to do with my personal feelings". Every single proponent of this arg

Re: A suggestion for going forward from the RMS/FSF debate

On 4/16/2021 9:57 AM, Thomas Koenig via Gcc wrote: Hello world, realising that my e-mails may have done more harm than good, I will now unsubscribe from the gcc mailing list, so please don't expect a reply unless you copy me in. I don't think your emails have done any harm.  I find them quit

Re: removing toxic emailers

On 4/16/2021 10:08 PM, Frosku wrote: On Sat Apr 17, 2021 at 5:05 AM BST, Ian Lance Taylor wrote: On Fri, Apr 16, 2021 at 4:16 PM Frosku wrote: When I refer to a 'California cultural standard', that's not prescriptive. It's just a reference to the fact that a *lot* of the SC live in Californi

Re: Can I push code to GCC?

On 5/10/2021 7:01 AM, juzhe.zh...@rivai.ai wrote: Hi, I am a compiler engineer base on GCC in China. Recently, I develop a new pattern for vector widen multiply-accumulator(I call it widen fma) because the ISA in my project has the instruction (vwmacc). I develop a lot of code especiallly fro

Re: Update to GCC copyright assignment policy

On 6/1/2021 5:22 PM, Eric Gallager via Gcc wrote: On Tue, Jun 1, 2021 at 10:02 AM David Edelsohn via Gcc wrote: GCC was created as part of the GNU Project but has grown to operate as an autonomous project. The GCC Steering Committee has decided to relax the requirement to assign copyright f

Re: replacing the backwards threader and more

On 6/9/2021 9:34 AM, Aldy Hernandez wrote: On 6/9/21 2:09 PM, Richard Biener wrote: On Wed, Jun 9, 2021 at 1:50 PM Aldy Hernandez via Gcc wrote: Hi Jeff.  Hi folks. What started as a foray into severing the old (forward) threader's dependency on evrp, turned into a rewrite of the backwa

Re: replacing the backwards threader and more

On 6/9/2021 2:39 PM, Aldy Hernandez wrote: On 6/9/21 9:47 PM, Jeff Law wrote: On 6/9/2021 9:34 AM, Aldy Hernandez wrote: On 6/9/21 2:09 PM, Richard Biener wrote: On Wed, Jun 9, 2021 at 1:50 PM Aldy Hernandez via Gcc wrote: Hi Jeff.  Hi folks. What started as a foray into severing

Re: replacing the backwards threader and more

On 6/9/2021 5:48 AM, Aldy Hernandez wrote: Hi Jeff.  Hi folks. What started as a foray into severing the old (forward) threader's dependency on evrp, turned into a rewrite of the backwards threader code.  I'd like to discuss the possibility of replacing the current backwards threader with

Re: replacing the backwards threader and more

On 6/14/2021 12:40 AM, Richard Biener wrote: I bet it's going to be tougher to remove DOM's threader. It knows how to do thinks like resolve memory references using temporary equivalences and such. But I bet it's enough to drop the VRP based threaders. Yes. In fact I am wondering if addi

Re: replacing the backwards threader and more

On 6/14/2021 11:39 PM, Aldy Hernandez wrote: On 6/15/21 6:03 AM, Jeff Law wrote: On 6/14/2021 12:40 AM, Richard Biener wrote: I bet it's going to be tougher to remove DOM's threader.  It knows how to do thinks like resolve memory references using temporary equivalences and such.  But

Aldy Hernandez and Andrew MacLeod as VRP maintainers

I am pleased to announce that the GCC Steering Committee has appointed Aldy Hernandez and Ian MacLeod as maintainers for the VRP subsystem (EVRP, VRP, Ranger). Aldy/Andrew, please update the MAINTAINERS file appropriately. Thanks, jeff

Re: replacing the backwards threader and more

On 6/21/2021 8:40 AM, Aldy Hernandez wrote: On 6/9/21 2:09 PM, Richard Biener wrote: On Wed, Jun 9, 2021 at 1:50 PM Aldy Hernandez via Gcc wrote: Hi Jeff.  Hi folks. What started as a foray into severing the old (forward) threader's dependency on evrp, turned into a rewrite of the backw

Re: Proper Place for builtin_define(__ELF__)

On 7/21/2021 6:31 PM, Michael Eager wrote: On 7/21/21 5:22 PM, Joel Sherrill wrote: On Wed, Jul 21, 2021, 7:12 PM Michael Eager > wrote:     On 7/21/21 2:28 PM, Joel Sherrill wrote: > Hi > > We are in the process of porting RTEMS to the Microbla

Re: Proper Place for builtin_define(__ELF__)

On 7/22/2021 8:12 AM, Joel Sherrill wrote: On Wed, Jul 21, 2021 at 10:08 PM Jeff Law wrote: On 7/21/2021 6:31 PM, Michael Eager wrote: On 7/21/21 5:22 PM, Joel Sherrill wrote: On Wed, Jul 21, 2021, 7:12 PM Michael Eager mailto:ea...@eagercon.com>> wrote: On 7/21/21 2:28 PM, Joel

Re: Failures building glibc with mainline GCC

On 7/30/2021 10:19 AM, Aldy Hernandez via Libc-alpha wrote: There's a new jump threader in GCC which is much more aggressive, and may trigger latent problems with other warning passes, especially -Warray-bounds, -Woverflow, and -Wuninitialized. Do your problems go away if you take out commit

Re: Failures building glibc with mainline GCC

On 7/30/2021 10:19 AM, Aldy Hernandez via Libc-alpha wrote: There's a new jump threader in GCC which is much more aggressive, and may trigger latent problems with other warning passes, especially -Warray-bounds, -Woverflow, and -Wuninitialized. [ ... ] Ugh.  First attempt got blocked as messag

Re: gcc_assert() and inhibit_libc

On 8/16/2021 11:06 AM, Jakub Jelinek via Gcc wrote: On Mon, Aug 16, 2021 at 12:50:49PM -0400, Jason Merrill via Gcc wrote: The trap builtin is target-specific. Making this system-specific (in this case RTEMS) could be an issue. Is that necessary? Are there interesting targets that don't hav

Re: More aggressive threading causing loop-interchange-9.c regression

On 9/9/2021 2:14 AM, Aldy Hernandez wrote: On 9/8/21 8:13 PM, Michael Matz wrote: Hello, [lame answer to self] On Wed, 8 Sep 2021, Michael Matz wrote: The forward threader guards against this by simply disallowing threadings that involve different loops.  As I see The thread in questi

Re: More aggressive threading causing loop-interchange-9.c regression

On 9/9/2021 2:58 AM, Richard Biener wrote: On Thu, Sep 9, 2021 at 10:36 AM Aldy Hernandez wrote: On 9/9/21 9:45 AM, Richard Biener wrote: On Thu, Sep 9, 2021 at 9:37 AM Aldy Hernandez wrote: On 9/9/21 8:57 AM, Richard Biener wrote: On Wed, Sep 8, 2021 at 8:13 PM Michael Matz wrote:

Re: More aggressive threading causing loop-interchange-9.c regression

On 9/9/2021 3:21 AM, Aldy Hernandez wrote:    /* If this path does not thread through the loop latch, then we are   using the FSM threader to find old style jump threads. This   is good, except the FSM threader does not re-use an existing   threading path to reduce code duplicat

Re: More aggressive threading causing loop-interchange-9.c regression

On 9/9/2021 4:15 AM, Richard Biener wrote: b) Even though we can seemingly fold everything DOM/threader does, in order to replace it with a backward threader instance we'd have to merge the cost/profitability code scattered throughout the forward threader, as well as the EDGE_FSM* / EDGE_COP

Re: More aggressive threading causing loop-interchange-9.c regression

On 9/10/2021 10:05 AM, Aldy Hernandez wrote: On 9/10/21 5:43 PM, Jeff Law wrote: On 9/9/2021 3:21 AM, Aldy Hernandez wrote:    /* If this path does not thread through the loop latch, then we are   using the FSM threader to find old style jump threads. This   is good, except th

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

On 9/27/2021 7:52 AM, Aldy Hernandez wrote: [CCing Jeff and list for broader audience] On 9/27/21 2:53 PM, Maxim Kuvyrkov wrote: Hi Aldy, Your patch seems to slow down 471.omnetpp by 8% at -O3.  Could you please take a look if this is something that could be easily fixed? First of all, t

Re: dejagnu version update?

On 10/27/2021 5:00 PM, Bernhard Reutner-Fischer wrote: On Sat, 4 Aug 2018 18:32:24 +0200 Bernhard Reutner-Fischer wrote: On Tue, 16 May 2017 at 21:08, Mike Stump wrote: On May 16, 2017, at 5:16 AM, Jonathan Wakely wrote: The change I care about in 1.5.3 So, we haven't talked much about

Re: -Wuninitialized false positives and threading knobs

On 10/31/2021 6:12 AM, Aldy Hernandez wrote: After Jeff's explanation of the symbiosis between jump threading and the uninit pass, I'm beginning to see that (almost) every Wuninitialized warning is cause for reflection. It usually hides a missing jump thread. I investigated one such false po

Re: GCC's excellent tail-call optimizations

On 11/5/2021 8:13 AM, Andrew Appel wrote: Dear GCC developers: TL;DR Can I talk to a maintainer of gcc's tail-call optimizer to learn more about the very impressive technology behind it? Or is there a paper, or documentation, that explains it? No paper or documentation I'm aware of. I

Re: distinguishing gcc compilation valgrind false positives

On 11/24/2021 12:15 PM, Paul Floyd via Gcc wrote: On 24/11/2021 20:05, Zdenek Sojka via Gcc wrote: Hello, from time to time, I come upon a testcase that failed during the automated runs, but passes during reduction; there are valgrind warnings present, however. How do I distinguish what w

Re: Question about match.pd

On 11/24/2021 2:19 PM, Navid Rahimi via Gcc wrote: Hi GCC community, I have a question about pattern matching in match.pd. So I have a pattern like this [1]: #define CMP != bool f(bool c, int i) { return (c << i) CMP 0; } bool g(bool c, int i) { return c CMP 0;} It is verifiably correct to

Re: distinguishing gcc compilation valgrind false positives

On 11/24/2021 12:41 PM, Zdenek Sojka wrote: Hello Jeff, -- Původní e-mail -- Od: Jeff Law via Gcc Komu: Paul Floyd , gcc@gcc.gnu.org Datum: 24. 11. 2021 20:33:02 Předmět: Re: distinguishing gcc compilation valgrind false positives On 11/24/2021 12:15 PM, Paul Floyd

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

On 1/7/2022 3:25 AM, Martin Jambor wrote: Hi, Would anyone be terribly against mass renaming all *.c files (that are actually C++ files) within the gcc subdirectory to ones with .cc suffix? We already have 47 files with suffix .cc directly in the gcc subdirectory and 160 if we also count tho

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

On 1/7/2022 7:49 AM, Jeff Law wrote: On 1/7/2022 3:25 AM, Martin Jambor wrote: Hi, Would anyone be terribly against mass renaming all *.c files (that are actually C++ files) within the gcc subdirectory to ones with .cc suffix? We already have 47 files with suffix .cc directly in the gcc s

Re: Help with an ABI peculiarity

On 1/7/2022 2:55 PM, Paul Koning via Gcc wrote: On Jan 7, 2022, at 4:06 PM, Iain Sandoe wrote: Hi Folks, In the aarch64 Darwin ABI we have an unusual (OK, several unusual) feature of the calling convention. When an argument is passed *in a register* and it is integral and less than SI

Re: Uninit warnings due to optimizing short-circuit conditionals

On 2/14/2022 8:57 AM, David Malcolm via Gcc wrote: [CCing Mark in the hopes of insight from the valgrind side of things] There is a false positive from -Wanalyzer-use-of-uninitialized-value on gcc.dg/analyzer/pr102692.c here: ‘fix_overlays_before’: events 1-3 | | 75 | while

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

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_lto_pr94157_0.o -fdiagnostics-plain-output -dumpbase 

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

On 4/25/2022 6:56 AM, Martin Liška wrote: I used -z execstack rather than --no-warn-execstack as the former is recognized by older versions of ld, but the latter is a new option. Thanks for it. Unfortunately, I should have looked at the other failures that have popped up over the last wee

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

On 4/25/2022 8:42 AM, Nick Clifton wrote: Hi Jeff, I used -z execstack rather than --no-warn-execstack as the former is recognized by older versions of ld, but the latter is a new option. Thanks for it. Unfortunately, I should have looked at the other failures that have popped up over the

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

On 4/25/2022 9:26 AM, Nick Clifton wrote: Hi Jeff,   Just FYI - I am also looking at adding in another warning.  This time for   when the linker creates a PT_LOAD segment which has all of the RWX flags   set.  At the moment my testing seems to show that it only causes problems   when a cus

  1   2   >