Re: Signing your git commits

> On Sep 16, 2024, at 8:13 AM, Richard Biener via Gcc wrote: > > On Mon, Sep 16, 2024 at 1:37 PM Jonathan Wakely via Gcc > wrote: >> >> Git supports signing commits with a GPG key, and more recently (since >> Git 2.34) also started supporting signing with an SSH key. The latter >> is IMHO m

Re: How to target a processor with very primitive addressing modes?

> On Jun 10, 2024, at 11:48 AM, Georg-Johann Lay wrote: > > > > Am 08.06.24 um 11:32 schrieb Mikael Pettersson via Gcc: >> On Thu, Jun 6, 2024 at 8:59 PM Dimitar Dimitrov wrote: >>> Have you tried defining TARGET_LEGITIMIZE_ADDRESS for your target? From >>> a quick search I see that the iq2

Re: How to target a processor with very primitive addressing modes?

> On Jun 10, 2024, at 4:47 AM, Florian Weimer via Gcc wrote: > > * Jeff Law via Gcc: > >> If he's got a CC register exposed prior to LRA and LRA needs to insert >> any code, that inserted code may clobber the CC state. This is >> discussed in the reload-to-LRA transition wiki page. > > Do y

Re: How to target a processor with very primitive addressing modes?

> On Jun 8, 2024, at 1:12 PM, Jeff Law wrote: > > > > On 6/8/24 10:45 AM, Paul Koning via Gcc wrote: >>> On Jun 8, 2024, at 5:32 AM, Mikael Pettersson via Gcc >>> wrote: >>> >>> On Thu, Jun 6, 2024 at 8:59 PM Dimitar Dimitrov wrote: >

Re: How to target a processor with very primitive addressing modes?

> On Jun 8, 2024, at 5:32 AM, Mikael Pettersson via Gcc wrote: > > On Thu, Jun 6, 2024 at 8:59 PM Dimitar Dimitrov wrote: >> Have you tried defining TARGET_LEGITIMIZE_ADDRESS for your target? From >> a quick search I see that the iq2000 and rx backends are rewriting some >> PLUS expression ad

Re: How to avoid some built-in expansions in gcc?

> On May 31, 2024, at 11:06 AM, Georg-Johann Lay wrote: > > > > Am 31.05.24 um 17:00 schrieb Paul Koning: >>> On May 31, 2024, at 9:52 AM, Georg-Johann Lay wrote: >>> >>> What's the recommended way to stop built-in expansions in gcc? >

Re: How to avoid some built-in expansions in gcc?

> On May 31, 2024, at 9:52 AM, Georg-Johann Lay wrote: > > What's the recommended way to stop built-in expansions in gcc? > > For example, avr-gcc expands isinff() to a bloated version of an isinff() > implementation that's written in asm (PR115307). > > Johann Isn't that up to the target

Re: [committed] PATCH for Re: Stepping down as maintainer for ARC and Epiphany

> On May 21, 2024, at 9:57 AM, Jeff Law wrote: > > > > On 5/21/24 12:05 AM, Richard Biener via Gcc wrote: >> On Mon, May 20, 2024 at 4:45 PM Gerald Pfeifer wrote: >>> >>> On Wed, 5 Jul 2023, Joern Rennecke wrote: I haven't worked with these targets in years and can't really do se

Re: [RFC] Linux system call builtins

> On Apr 9, 2024, at 9:48 PM, Matheus Afonso Martins Moreira via Gcc > wrote: > > ... > MIPS calling conventions work like this: > >> mips/n32,64 a0 a1 a2 a3 a4 a5 >> mips/o32a0 a1 a2 a3 ... >> mips/o32args5-8 are passed on the stack Yes, for regular function calls, but at least in

Re: Sourceware mitigating and preventing the next xz-backdoor

> On Apr 9, 2024, at 3:59 PM, Jonathon Anderson via Gcc wrote: > > On Tue, Apr 9, 2024, 10:57 Andreas Schwab wrote: > >> On Apr 09 2024, anderson.jonath...@gmail.com wrote: >> >>> - This xz backdoor injection unpacked attacker-controlled files and ran >> them during `configure`. Newer build

Re: [RFC] Linux system call builtins

> On Apr 8, 2024, at 4:01 PM, Paul Iannetta via Gcc wrote: > > On Mon, Apr 08, 2024 at 11:26:40AM -0700, Andrew Pinski wrote: >> On Mon, Apr 8, 2024 at 11:20 AM Paul Iannetta via Gcc >> wrote: >>> ... >> Also do you sign or zero extend a 32bit argument for LP64 targets? >> Right now it is no

Re: Sourceware mitigating and preventing the next xz-backdoor

> On Apr 3, 2024, at 2:04 PM, Toon Moene wrote: > > On 4/1/24 17:06, Mark Wielaard wrote: > >> A big thanks to everybody working this long Easter weekend who helped >> analyze the xz-backdoor and making sure the impact on Sourceware and >> the hosted projects was minimal. > > Thanks for thos

Re: Sourceware mitigating and preventing the next xz-backdoor

> On Apr 3, 2024, at 10:00 AM, Michael Matz wrote: > > Hello, > > On Wed, 3 Apr 2024, Martin Uecker via Gcc wrote: > Seems reasonable, but note that it wouldn't make any difference to this attack. The liblzma library was modified to corrupt the sshd binary, when sshd was link

Re: Sourceware mitigating and preventing the next xz-backdoor

> On Apr 2, 2024, at 6:08 PM, Guinevere Larsen wrote: > > On 4/2/24 16:54, Sandra Loosemore wrote: >> On 4/1/24 09:06, Mark Wielaard wrote: >>> A big thanks to everybody working this long Easter weekend who helped >>> analyze the xz-backdoor and making sure the impact on Sourceware and >>> the

Re: Sourceware mitigating and preventing the next xz-backdoor

> On Apr 2, 2024, at 4:03 PM, Paul Eggert wrote: > > On 4/2/24 12:54, Sandra Loosemore wrote: >> Do we to harden our process, too, to require all patches to be signed off by >> someone else before committing? > > It's easy for an attacker to arrange to have "someone else" in cahoots. > > Al

Re: Odd Python errors in the G++ testsuite

> On Oct 9, 2023, at 7:42 PM, Ben Boeckel via Gcc wrote: > > On Mon, Oct 09, 2023 at 20:12:01 +0100, Maciej W. Rozycki wrote: >> I'm seeing these tracebacks for several cases across the G++ testsuite: >> >> Executing on host: python3 -c "import sys; assert sys.version_info >= (3, >> 6)"(

Re: Complex numbers in compilers - upcoming GNU Tools Cauldron.

> On Sep 12, 2023, at 7:12 AM, Martin Uecker via Gcc wrote: > > Am Dienstag, dem 12.09.2023 um 11:25 +0200 schrieb Richard Biener via Gcc: >>> ... >> >> Lack of applications / benchmarks using complex numbers is also a >> problem for any work on this. > > I could probably provide some exampl

Re: Unexpected behavior of gcc on pointer dereference & increment

> On Sep 1, 2023, at 12:35 PM, Tomas Bortoli via Gcc wrote: > > Hi, > > I recently discovered that the following C statement: > > pointer++; > > is semantically equivalent to the following: > > *pointer++; > > Is this due to operators' priority? To me, that looks weird. Yes, https://en.c

Re: Porting to a custom ISA

> On Aug 15, 2023, at 8:49 AM, MegaIng wrote: > > > On Aug 15, 2023, at 7:37 AM, Paul Koning wrote: > >> >>> On Aug 15, 2023, at 7:37 AM, MegaIng via Gcc wrote: >>> >>> ... >>> Also, on another backend I saw comments relating to

Re: Porting to a custom ISA

> On Aug 15, 2023, at 8:06 AM, Richard Biener via Gcc wrote: > > On Tue, Aug 15, 2023 at 1:38 PM MegaIng via Gcc wrote: >> ... >> And a bit more concrete with something I am having a hard time >> debugging. I am getting errors `invalid_void`, seemingly triggered by an >> absent of `gen_return

Re: Porting to a custom ISA

> On Aug 15, 2023, at 7:37 AM, MegaIng via Gcc wrote: > > ... > Also, on another backend I saw comments relating to libgcc (or newlib?) not > working that well on systems where int is 16bit. Is that still true, and what > is the best workaround? I haven't seen that comment and it doesn't ma

Re: Where to place warning about non-optimized tail and sibling calls

I'm puzzled. The fundamental rule of optimization is that it doesn't change the (defined) semantics of the program. How is it possible to write valid C that is correct only if some optimization is done? In other words, if it matters whether an optimization is done or not, that suggests to me

Re: LRA for avr: help with FP and elimination

> On Jul 27, 2023, at 7:50 AM, Maciej W. Rozycki wrote: > > On Fri, 14 Jul 2023, Vladimir Makarov via Gcc wrote: > >>> On the avr, the stack pointer (SP) >>> is not used to access stack slots >> It is very uncommon target then. > > Same with the VAX target. SP is used for outgoing functi

Re: abi

Because implementing an ABI, or dealing with an incompatibnle change, is hard work. Also, ABI stability means that old binaries work. So ABI stability isn't so much a requirement for the compiler as it is a requirement for any sane operating system. An OS that changes ABI without an extremely

Re: abi

It does, for machine architectures that have multiple ABIs. MIPS is an example where GCC has supported this for at least 20 years. paul > On Jul 6, 2023, at 5:19 PM, André Albergaria Coelho via Gcc > wrote: > > Could gcc have an option to specify ABI? > > say > > > gcc something.c

Re: Will GCC eventually learn to use BSR or even TZCNT on AMD/Intel processors?

> On Jun 5, 2023, at 8:09 PM, Dave Blanchard wrote: > > On Tue, 6 Jun 2023 01:59:42 +0200 > Gabriel Ravier wrote: > >> [nothing of value] > > If this guy's threads are such a terrible waste of your time, how about > employing your email client's filters to ignore his posts (and mine too) a

Re: End of subscription

> On May 23, 2023, at 10:08 PM, LIU Hao via Gcc wrote: > > 在 2023/5/19 20:59, Florian Weimer via Gcc 写道: >> * Jonathan Wakely via Gcc: >>> Unfortunately even the Gmail web UI doesn't offer an unsubscribe >>> option, despite knowing the mails come from a list and showing: >>> >>> mailing list:

Re: More C type errors by default for GCC 14

> On May 10, 2023, at 10:39 AM, Eli Zaretskii via Gcc wrote: > >> ... >> Sweeping problems under the carpet and hoping no one trips over the >> bumps is, at best, pushing problems down the road for future developers. > > I'm not sweeping anything. This is not GCC's problem to solve, that's

Re: I have questions regarding the 4.3 codebase...

> On Mar 23, 2023, at 10:13 AM, Sid Maxwell via Gcc wrote: > > Thanks for reaching out, Julian, I greatly appreciate your help. Please > forgive and over- or under-sharing. If I've left something out, please let > me know. > > From my pdp10.md: > > ;; JIRA sw_gcc-68. gcc recognizes the "m

Re: LRA produces RTL not meeting constraint

> On Jan 11, 2023, at 7:38 PM, Paul Koning via Gcc wrote: > > > >> On Jan 11, 2023, at 2:52 PM, Segher Boessenkool >> wrote: >> >> Hi Paul, >> >> On Tue, Jan 10, 2023 at 02:39:34PM -0500, Paul Koning via Gcc wrote: >>> In

Re: LRA produces RTL not meeting constraint

> On Jan 11, 2023, at 2:52 PM, Segher Boessenkool > wrote: > > Hi Paul, > > On Tue, Jan 10, 2023 at 02:39:34PM -0500, Paul Koning via Gcc wrote: >> In pdp11.md I have: >> >> (define_insn_and_split "addhi3" >> [(set (match_operand:HI 0 &

LRA produces RTL not meeting constraint

In pdp11.md I have: (define_insn_and_split "addhi3" [(set (match_operand:HI 0 "nonimmediate_operand" "=rR,rR,Q,Q") (plus:HI (match_operand:HI 1 "general_operand" "%0,0,0,0") (match_operand:HI 2 "general_operand" "rRLM,Qi,rRLM,Qi")))] "" "#" "reload_completed" [(p

Re: Widening multiplication, but no narrowing division [i386/AMD64]

> On Jan 9, 2023, at 11:27 AM, Stefan Kanthak wrote: > > "Paul Koning" wrote: > >>> ... > >> Yes, I was thinking the same. But I spent a while on that pattern -- I >> wanted to support div/mod as a single operation because the machine has &g

struct vs. class in GCC source

Building on Mac with Clang I get warnings like this: ../../../gcc/gcc/cgraph.h:2629:28: warning: struct 'cgraph_edge' was previously declared as a class; this is valid, but may result in linker errors under the Microsoft C++ ABI [-Wmismatched-tags] It seems to be talking about a MS bug (since C

Re: Widening multiplication, but no narrowing division [i386/AMD64]

> On Jan 9, 2023, at 10:20 AM, Stefan Kanthak wrote: > > "Paul Koning" wrote: > >>> On Jan 9, 2023, at 7:20 AM, Stefan Kanthak wrote: >>> >>> Hi, >>> >>> GCC (and other C compilers too) support the widening multiplicat

Re: Widening multiplication, but no narrowing division [i386/AMD64]

> On Jan 9, 2023, at 7:20 AM, Stefan Kanthak wrote: > > Hi, > > GCC (and other C compilers too) support the widening multiplication > of i386/AMD64 processors, but DON'T support their narrowing division: I wonder if this changed in the recent past. I have a pattern for this type of thing i

Re: [BUG] missing warning for pointer arithmetic out of bounds

> On Dec 13, 2022, at 2:08 PM, Alejandro Colomar via Gcc > wrote: > > Hi! > > For the following program: > > >$ cat buf.c >#include > >int main(void) >{ >char *p, buf[5]; > >p = buf + 6; >printf("%p\n", p); >} > > > There are no warnings in

Re: Good grief Charlie Brown

> On Dec 13, 2022, at 2:09 PM, Dave Blanchard wrote: > > Since my response did not get posted (maybe one of the words wasn't allowed? > or because I attached binaries?) here it is again: > ... I'm puzzled. What is your purpose? What result do you expect from your messages? What action wo

Re: Can't build Ada

> On Nov 26, 2022, at 11:42 AM, Arnaud Charlet via Gcc wrote: > > >>> The current statement (https://gcc.gnu.org/install/prerequisites.html) is: >>> >>> GNAT >>> In order to build GNAT, the Ada compiler, you need a working GNAT compiler >>> (GCC version 5.1 or later). >>> >>> so, if 5.1 i

Re: Can't build Ada

> On Nov 26, 2022, at 11:52 AM, Iain Sandoe wrote: > > > >> On 26 Nov 2022, at 16:42, Arnaud Charlet wrote: >> >> The current statement (https://gcc.gnu.org/install/prerequisites.html) is: GNAT In order to build GNAT, the Ada compiler, you need a working GNAT compile

Re: Can't build Ada

> On Nov 26, 2022, at 10:58 AM, Iain Sandoe wrote: > > Hi Paul, > > I am part way through the exercise on both macOS 11 (X86) and 12 (Arm64). > > ** However, I am using gcc-7.5 as the bootstrap compiler, not gcc-5.1. I'm not using 5.1 -- I only quoted that version number because the install

Re: GNU = Junkware

> On Nov 26, 2022, at 4:20 AM, Dave Blanchard wrote: > > No, I'm not trolling, just venting here for a moment. So sick of garbage ass, > crusty junkware that's always a battle to the death to accomplish anything. I don't know who you are or why you feel a need to spew obscenities on the GCC

Re: Can't build Ada

> On Nov 25, 2022, at 3:46 PM, Iain Sandoe wrote: > > Hi Paul, > >> On 25 Nov 2022, at 20:13, Andrew Pinski via Gcc wrote: >> >> On Fri, Nov 25, 2022 at 12:08 PM Paul Koning wrote: >>> >>>> On Nov 25, 2022, at 3:03 PM, Andrew Pinski

Re: Can't build Ada

> On Nov 25, 2022, at 3:03 PM, Andrew Pinski wrote: > > On Fri, Nov 25, 2022 at 11:59 AM Paul Koning via Gcc wrote: >> >> I'm trying to use fairly recent GCC sources (the gcc-darwin branch to be >> precise) to build Ada, starting with the latest (2020)

Can't build Ada

I'm trying to use fairly recent GCC sources (the gcc-darwin branch to be precise) to build Ada, starting with the latest (2020) release of Gnat from Adacore. It fails for several reasons. One is that two source files use [ ] for array initializer brackets when ( ) is apparently supposed to be

Re: clarification question

> On Oct 22, 2022, at 2:38 PM, Marc Glisse via Gcc wrote: > > On Sat, 22 Oct 2022, Péntek Imre via Gcc wrote: > >> https://gcc.gnu.org/backends.html >> >> by "Architecture does not have a single condition code register" do you mean >> it has none or do you mean it has multiple? > > Either.

Re: Possible C++ method signature warning feature?

> On Aug 10, 2022, at 9:25 PM, Andrew Pinski wrote: > > On Wed, Aug 10, 2022 at 6:20 PM Paul Koning via Gcc wrote: >> >> There's a C++ problem I keep running into, in a very large body of software >> with lots of subclassing. >> >> There&#x

Possible C++ method signature warning feature?

There's a C++ problem I keep running into, in a very large body of software with lots of subclassing. There's a base class that defines a set of interface methods, not all pure virtual (some define the default behavior). A number of subclasses override some but not all of these. Now I find my

Re: Signed vs. unsigned compares

> On Jun 17, 2022, at 11:51 AM, Andreas Schwab wrote: > > On Jun 17 2022, Paul Koning via Gcc wrote: > >> In expanding a longer-than-word compare, I need to do things differently >> depending on whether a signed vs. unsigned compare is needed. But it seems >>

Signed vs. unsigned compares

Question for target code: In expanding a longer-than-word compare, I need to do things differently depending on whether a signed vs. unsigned compare is needed. But it seems the compare operation applies to either. How can I do this in the target code? paul

Switch statement optimization

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 in the NFS protocol parser, where you get a sw

Re: Benchmark recommendations needed

> On Feb 22, 2022, at 4:26 PM, Gary Oblock via Gcc wrote: > > Andras, > > The whole point of benchmarks is to judge a processor's performance. > That being said, just crippling GCC is not reasonable because > processors must be judged in the appropriate context and that > includes the current

Re: reordering of trapping operations and volatile

> On Jan 15, 2022, at 4:28 PM, Martin Sebor wrote: > > On 1/14/22 07:58, Paul Koning via Gcc wrote: >>> On Jan 14, 2022, at 9:15 AM, Michael Matz via Gcc wrote: >>> >>>> ... >>> But right now that's equivalent to making it obser

Re: reordering of trapping operations and volatile

> On Jan 14, 2022, at 9:15 AM, Michael Matz via Gcc wrote: > > Hello, > > On Thu, 13 Jan 2022, Martin Uecker wrote: > > Handling all volatile accesses in the very same way would be > possible but quite some work I don't see much value in. I see some value. But

Re: Help with an ABI peculiarity

> 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 it is promoted (with appropriate s

Re: __builtin_addc support??

> On Oct 27, 2021, at 12:12 PM, sotrdg sotrdg via Gcc wrote: > > 79173 – add-with-carry and subtract-with-borrow support (x86_64 and others) > (gnu.org) > > What I find quite interesting is things like this. > > Since llvm clang provides _

Re: Developer branches

> On Sep 15, 2021, at 5:21 PM, Joseph Myers wrote: > > On Wed, 15 Sep 2021, Paul Koning via Gcc wrote: > >> Some questions about developer branches: >> >> 1. Who may create one? Who may write to them? >> 2. Are they required to be listed in https://gcc

Re: Developer branches

> On Sep 15, 2021, at 4:34 PM, Jonathan Wakely wrote: > > On Wed, 15 Sept 2021 at 21:12, Paul Koning via Gcc wrote: >> >> Some questions about developer branches: >> >> 1. Who may create one? Who may write to them? >> 2. Are they required to be list

Developer branches

Some questions about developer branches: 1. Who may create one? Who may write to them? 2. Are they required to be listed in https://gcc.gnu.org/git.html ? I notice it mentioned a whole pile of them, most of which don't seem to exist. It's a bit confusing since this seems to be a concept that i

Re: Optional machine prefix for programs in for -B dirs, matching Clang

> On Aug 4, 2021, at 3:32 AM, Jonathan Wakely via Gcc wrote: > > On Wed, 4 Aug 2021, 08:26 John Ericson wrote: > >> Problem: >> >> It's somewhat annoying to have to tell GCC --with-as=... --with-ld=... >> just to prefix those commands the same way GCC is prefixed. >> > > Doesn't GCC automa

Re: GCC 10.2: undefined reference to vtable: missing its key function

> On Jun 6, 2021, at 5:41 PM, Paul Smith wrote: > > I have a class which is NOT, as far as I can see, polymorphic. > > It doesn't inherit from any other class and none of its methods are > declared virtual. The class implementation and all its callers all > compile just fine. > > Is there s

Re: RFC: New mechanism for hard reg operands to inline asm

> On Jun 4, 2021, at 2:02 PM, Andreas Krebbel via Gcc wrote: > > Hi, > > I wonder if we could replace the register asm construct for > inline assemblies with something a bit nicer and more obvious. > E.g. turning this (real world example from IBM Z kernel code): > > int diag8_response(int cm

Re: Update to GCC copyright assignment policy

> On Jun 1, 2021, at 12:44 PM, Joseph Myers wrote: > > On Tue, 1 Jun 2021, David Edelsohn via Gcc wrote: > >> The copyright author will be listed as "Free Software Foundation, >> Inc." and/or "The GNU Toolchain Authors", as appropriate. > > And copyright notices naming "The GNU Toolchain Aut

Re: Update to GCC copyright assignment policy

> On Jun 1, 2021, at 12:09 PM, David Edelsohn via Gcc wrote: > > On Tue, Jun 1, 2021 at 10:40 AM Paul Koning wrote: >> >>> On Jun 1, 2021, at 10:31 AM, David Edelsohn via Gcc wrote: >>> >>> The copyright author will be listed as "Free

Re: Update to GCC copyright assignment policy

> On Jun 1, 2021, at 11:08 AM, Jason Merrill via Gcc wrote: > > On Tue, Jun 1, 2021 at 10:52 AM D. Hugh Redelmeier wrote: > >> | From: Mark Wielaard >> >> | This seems a pretty bad policy to be honest. >> | Why was there no public discussion on this? >> >> Agreed. I also agree with the r

Re: Update to GCC copyright assignment policy

> On Jun 1, 2021, at 10:31 AM, David Edelsohn via Gcc wrote: > > The copyright author will be listed as "Free Software Foundation, > Inc." and/or "The GNU Toolchain Authors", as appropriate. What does that mean? FSF is a well defined organization. "The GNU Toolchain Authors" sounds like on

Re: On US corporate influence over Free Software and the GCC Steering Committee

> On Apr 20, 2021, at 9:22 AM, David Starner via Gcc wrote: > > Giacomo Tesio wrote: >> ... >> Please, do not create a hostile environment for indipendent contributors. > > What do you mean by independent? If you're independently wealthy and > don't need to work, you can avoid this. If you're

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

> On Apr 16, 2021, at 2:41 PM, NightStrike via Gcc wrote: > >> ... > > I was under the (likely incorrect, please enlighten me) impression > that the meteoric rise of LLVM had more to do with the license > allowing corporate contributors to ship derived works in binary form > without sharing p

Re: removing toxic emailers

> On Apr 15, 2021, at 7:44 PM, Frosku wrote: > > On Fri Apr 16, 2021 at 12:36 AM BST, Christopher Dimech wrote: >> >> The commercial use of free software is our hope, not our fear. When >> people >> at IBM began to come to free software, wanting to recommend it and use >> it, >> and maybe dis

Re: removing toxic emailers

> On Apr 15, 2021, at 11:17 AM, Iain Sandoe wrote: > > ... > responding in general to this part of the thread. > > * The GCC environment is not hostile, and has not been for the 15 or so > years I’ve been part of the community. Glad to see you feel that way; my view matches yours. > * We wo

Re: removing toxic emailers

> On Apr 14, 2021, at 5:38 PM, Ian Lance Taylor wrote: > > On Wed, Apr 14, 2021 at 1:49 PM Paul Koning wrote: >> >>> ... >> >> This is why I asked the question "who decides?" Given a disagreement in >> which the proposed reme

Re: removing toxic emailers

> On Apr 14, 2021, at 4:39 PM, Ian Lance Taylor via Gcc 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 t

Re: removing toxic emailers

> On Apr 14, 2021, at 2:19 PM, Nathan Sidwell wrote: > > On 4/14/21 12:52 PM, Martin Jambor wrote: >> Hi Nathan, >> On Wed, Apr 14 2021, Nathan Sidwell wrote: >>> Do we have a policy about removing list subscribers that send abusive or >>> other toxic emails? do we have a code of conduct? Se

Re: GCC association with the FSF

> On Apr 9, 2021, at 2:27 AM, Alfred M. Szmidt via Gcc wrote: > > These discussions are slightly off topic for gcc@, I'd suggest they > are moved to gnu-misc-discuss@ or some other more suitable list. More than "slightly", in my view. I'm close to putting this thread into my "send straight

Re: Remove RMS from the GCC Steering Committee

I may have lost it in the enormous flood of text, but I want to ask these general questions. 1. Is there a published code of conduct for GCC community members, possibly different ones depending on which level of the organization you're in? 2. Is there a formal process for receiving claims of in

Re: 4.2 source

> On Jun 9, 2020, at 10:02 AM, James Dugan > wrote: > > Hello, > This is a long shot, but is there any archive of the 4.2 source code? I need > a build for a rhel5.4 server to support a p2v migration. I checked the > successful builds page and see that this version of rhel was not done for

Re: AVR CC0 transition

> On Apr 22, 2020, at 10:11 PM, Senthil Kumar via Gcc 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 tim

Re: [RFC] Characters per line: from punch card (80) to line printer (132) (was: [Patch][OpenMP/OpenACC/Fortran] Fix mapping of optional (present|absent) arguments)

> On Dec 5, 2019, at 11:17 AM, Joseph Myers wrote: > > On Thu, 5 Dec 2019, Thomas Schwinge wrote: > >> In the relevant session at the GNU Tools Cauldron 2019, Michael Meissner >> stated that even he is not using a 80 x 24 terminal anymore, and that >> should tell us something. ;-) >> >> So,

Re: syncing the GCC vax port, atomic issue

> On Sep 20, 2019, at 9:18 PM, co...@sdf.org wrote: > > On Fri, Sep 20, 2019 at 10:07:59PM +, co...@sdf.org wrote: >> Introducing the reversed jbb* patterns doesn't seem to help with the >> original issue. It crashes building libatomic. > > My loose understanding of what is going on: > - G

Re: Proposal for the transition timetable for the move to GIT

> On Sep 17, 2019, at 8:02 AM, Richard Earnshaw (lists) > wrote: > > ... > So in summary my proposed timetable would be: > > Monday 16th December 2019 - cut off date for picking which git conversion to > use > > Tuesday 31st December 2019 - SVN repo becomes read-only at end of stage 3. >

Re: asking for __attribute__((aligned()) clarification

> On Aug 21, 2019, at 10:57 AM, Alexander Monakov wrote: > > On Wed, 21 Aug 2019, Paul Koning wrote: > >> I agree, but if the new approach generates a warning for code that was >> written >> to the old rules, that would be unfortunate. > > FWIW I do

Re: asking for __attribute__((aligned()) clarification

> On Aug 21, 2019, at 10:28 AM, Alexander Monakov wrote: > > On Tue, 20 Aug 2019, "Markus Fröschle" wrote: > >> Thank you (and others) for your answers. Now I'm just as smart as before, >> however. >> >> Is it a supported, documented, 'long term' feature we can rely on or not? >> >> If yes

Re: asking for __attribute__((aligned()) clarification

> On Aug 19, 2019, at 10:08 AM, Alexander Monakov wrote: > > On Mon, 19 Aug 2019, Richard Earnshaw (lists) wrote: > >> Correct, but note that you can only pack structs and unions, not basic types. >> there is no way of under-aligning a basic type except by wrapping it in a >> struct. > > I d

Re: asking for __attribute__((aligned()) clarification

> On Aug 19, 2019, at 8:46 AM, Markus Fröschle wrote: > > All, > > this is my first post on these lists, so please bear with me. > > My question is about gcc's __attribute__((aligned()). Please consider the > following code: > > #include > > typedef uint32_t uuint32_t __attribute__((alig

Re: Indirect memory addresses vs. lra

> On Aug 9, 2019, at 10:16 AM, Segher Boessenkool > wrote: > > Hi! > > On Fri, Aug 09, 2019 at 10:14:39AM +0200, John Darrington wrote: >> On Thu, Aug 08, 2019 at 01:57:41PM -0600, Jeff Law wrote: >> >> ... However I wonder if this issue is >> related to the other major outstanding proble

Re: Indirect memory addresses vs. lra

> On Aug 8, 2019, at 1:21 PM, Segher Boessenkool > wrote: > > On Thu, Aug 08, 2019 at 12:43:52PM -0400, Paul Koning wrote: >>> On Aug 8, 2019, at 12:25 PM, Vladimir Makarov wrote: >>> The old reload (reload[1].c) supports such addressing. As modern >&g

Re: Indirect memory addresses vs. lra

> On Aug 8, 2019, at 1:21 PM, Segher Boessenkool > wrote: > > On Thu, Aug 08, 2019 at 12:43:52PM -0400, Paul Koning wrote: >>> On Aug 8, 2019, at 12:25 PM, Vladimir Makarov wrote: >>> The old reload (reload[1].c) supports such addressing. As modern >&g

Re: Indirect memory addresses vs. lra

> On Aug 8, 2019, at 12:25 PM, Vladimir Makarov wrote: > > > On 2019-08-04 3:18 p.m., John Darrington wrote: >> I'm trying to write a back-end for an architecture (s12z - the ISA you can >> download from [1]). This arch accepts indirect memory addresses. That is >> to >> say, those of the

Re: syncing the GCC vax port

> On Mar 30, 2019, at 5:03 AM, co...@sdf.org wrote: > > hi folks, > > i was interesting in tackling some problems gcc netbsd/vax has. > it has some ICEs which are in reload phase. searching around, the answer > to that is "switch to LRA first". Now, I don't quite know what that is > yet, but I

Re: Annoying silly warning emitted by gcc?

> On Jan 23, 2019, at 7:15 PM, Warren D Smith wrote: > > x = x^x; > > The purpose of the above is to load "x" with zero. > For very wide types, say 256 bits wide, explicitly loading 0 > is deprecated by Intel since taking too much memory. > XORing x with itself always yields 0 and is allegedl

Re: [RFC] Update Stage 4 description

> On Jan 9, 2019, at 3:42 AM, Tom de Vries wrote: > > [ To revisit https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00385.html ] > > The current formulation for the description of Stage 4 here ( > https://gcc.gnu.org/develop.html ) is: > ... > During this period, the only (non-documentation) cha

Re: Bug in divmodhi4(), plus poor inperformant code

> On Dec 5, 2018, at 11:23 AM, Segher Boessenkool > wrote: > > On Wed, Dec 05, 2018 at 02:19:14AM +0100, Stefan Kanthak wrote: >> "Paul Koning" wrote: >> >>> Yes, that's a rather nasty cut & paste error I made. >> >>

Re: Bug in divmodhi4(), plus poor inperformant code

> On Dec 4, 2018, at 8:19 PM, Stefan Kanthak wrote: > > "Paul Koning" wrote: > >> Yes, that's a rather nasty cut & paste error I made. > > I suspected that. > Replacing >!(den & (1L<<31)) > with >(signed short) den

Re: Bug in divmodhi4(), plus poor inperformant code

Yes, that's a rather nasty cut & paste error I made. But if the 31 is changed to a 15, is the code correct? I would think so. For optimization I'd think that an assembly language version would make more sense, and a few targets do that. paul > On Dec 4, 2018, at 5:51 PM, Stefan Kant

Re: LRA reload produces invalid insn

> On Nov 2, 2018, at 9:34 AM, Peter Bergner wrote: > > On 11/1/18 10:37 PM, Vladimir Makarov wrote: >> On 11/01/2018 08:25 PM, Paul Koning wrote: >>> Is this an LRA bug, or is there something I need to do in the target to >>> prevent this happening? &

Re: LRA reload produces invalid insn

> On Nov 1, 2018, at 8:49 PM, Peter Bergner wrote: > > On 11/1/18 7:25 PM, Paul Koning wrote: >> I'm running the testsuite on the pdp11 target, and I get a failure when >> using LRA that works correctly with the old allocator. The issue is that >> LRA is p

LRA reload produces invalid insn

I'm running the testsuite on the pdp11 target, and I get a failure when using LRA that works correctly with the old allocator. The issue is that LRA is producing an insn that is invalid (it violates the constraints stated in the insn definition). The insn in the IRA dump looks like this: (ins

Re: dg-add-options ieee ?

> On Oct 31, 2018, at 5:47 PM, Joseph Myers wrote: > > On Wed, 31 Oct 2018, Paul Koning wrote: > >> So you mean, add a new keyword (say, "ieee") to dg-effective-target that >> means "run this test only on ieee targets"? > > Note that differ

Re: dg-add-options ieee ?

> On Oct 31, 2018, at 4:11 PM, Rainer Orth > wrote: > > Hi Paul, > >> Ok, thanks. So adding a dg-skip-if for my target is indeed correct. Will >> do so. > > please don't: since this is going to be common, please add a > corresponding effective-target keyword instead, together with > sour

Re: Builtin mismatch warning

> On Oct 31, 2018, at 4:21 PM, Martin Sebor wrote: > > On 10/31/2018 12:15 PM, Paul Koning wrote: >> I noticed a curious inconsistency. >> >> Some testcases (like gcc.dg/Wrestrict-4.c) have declarations like this: >> >> void *alloca(); >>

  1   2   3   4   >