Re: [PATCH] Hard register asm constraint

> On Jun 26, 2024, at 8:54 AM, Stefan Schulze Frielinghaus > wrote: > > On Tue, Jun 25, 2024 at 01:02:39PM -0400, Paul Koning wrote: >> >> >>> On Jun 25, 2024, at 12:04 PM, Stefan Schulze Frielinghaus >>> wrote: >>> >>>

Re: [PATCH] Hard register asm constraint

> On Jun 25, 2024, at 12:04 PM, Stefan Schulze Frielinghaus > wrote: > > On Tue, Jun 25, 2024 at 10:03:34AM -0400, Paul Koning wrote: >> >>>>> ... >>>>> could be rewritten into >>>>> >>>>> int test (int

Re: [PATCH] Hard register asm constraint

> On Jun 24, 2024, at 1:50 AM, Stefan Schulze Frielinghaus > wrote: > > Ping. > > On Mon, Jun 10, 2024 at 07:19:19AM +0200, Stefan Schulze Frielinghaus wrote: >> Ping. >> >> On Fri, May 24, 2024 at 11:13:12AM +0200, Stefan Schulze Frielinghaus wrote: >>> This implements hard register

Re: [PATCH 30/52 v2] pdp11: Remove macro {FLOAT,DOUBLE,LONG_DOUBLE}_TYPE_SIZE

Thanks Kewen. Given that background, the patch is OK. paul > On Jun 16, 2024, at 10:01 PM, Kewen.Lin wrote: > > Hi Paul, > > on 2024/6/14 23:20, Paul Koning wrote: >> Ok, I understand better now. But if those macros are supposed to be >> replaced by hoo

Re: [PATCH 30/52 v2] pdp11: Remove macro {FLOAT,DOUBLE,LONG_DOUBLE}_TYPE_SIZE

Ok, I understand better now. But if those macros are supposed to be replaced by hook functions, could you make that replacement part of the proposed patch? paul > On Jun 13, 2024, at 11:22 PM, Kewen.Lin wrote: > > Hi Paul, > > on 2024/6/14 04:07, Paul Koning

Re: PING^1 [PATCH 30/52] pdp11: Remove macro LONG_DOUBLE_TYPE_SIZE

What is the effect of this change? The original code intended to have "float" mean a 32 bit value, and "double" a 64 bit value. There aren't any larger floats, so I defined the long double size as 64 also. Is the right answer not to define it? That part I understand, but why does the patch

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

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

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

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? &g

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

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

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

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

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

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

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 >>>

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. > >

Re: [PATCH] Turn on LRA on all targets

> On Feb 16, 2024, at 6:34 AM, Maciej W. Rozycki wrote: > > On Thu, 15 Feb 2024, Paul Koning wrote: > >>> On May 15, 2023, at 5:09 PM, Maciej W. Rozycki wrote: >>> >>> ... >>> >>> I may choose to implement a non-DWARF unwinder inste

Re: [PATCH] Turn on LRA on all targets

> On Feb 15, 2024, at 5:56 PM, Segher Boessenkool > wrote: > > On Thu, Feb 15, 2024 at 07:34:32PM +, Sam James wrote: >> I have now started doing this in PR113932. > > Thank you! > > Segher Presumably this isn't for version 14 since it's in a late stage, right? I have my bits about

Re: [PATCH] Turn on LRA on all targets

> On May 15, 2023, at 5:09 PM, Maciej W. Rozycki wrote: > > ... > > I may choose to implement a non-DWARF unwinder instead, as the VAX stack > frame is always fully described by the hardware and there is never ever a > need for debug information to be able to decode any VAX stack frame

Re: [PATCH] Fix PR ada/111909 On Darwin, determine filesystem case sensitivity at runtime

> On Nov 22, 2023, at 8:54 AM, Simon Wright wrote: > > On 21 Nov 2023, at 23:13, Iain Sandoe wrote: > >>> #if defined (__APPLE__) >>> -#include >> >> If removing unistd.h is intentional (i.e. you determined that it’s no longer >> needed for Darwin), then we should make that a separate

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

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,

Re: RISC-V: Added support for CRC.

> On Aug 16, 2023, at 3:42 PM, Philipp Tomsich wrote: > > On Wed, 16 Aug 2023 at 21:10, Alexander Monakov wrote: >> >> >> On Tue, 15 Aug 2023, Jeff Law wrote: >> >>> Because if the compiler can optimize it automatically, then the projects >>> have >>> to do literally nothing to take

Re: [RFC] GCC Security policy

> On Aug 16, 2023, at 3:53 AM, Alexander Monakov wrote: > >> ... >> Is "timing-safety" a security property? Not the way I understand that >> term. It sounds like another way to say that the code meets real time >> constraints or requirements. > > I meant in the sense of not admitting

Re: [RFC] GCC Security policy

> On Aug 15, 2023, at 8:37 PM, Alexander Monakov wrote: > >> ... >> At some point the system tools need to respect the programmer or operator. >> There is a difference between writing "Hello, World" and writing >> performance critical or safety critical code. That is the responsibility >> of

Re: [RFC] GCC Security policy

> On Aug 15, 2023, at 10:07 AM, Alexander Monakov wrote: > > > On Tue, 15 Aug 2023, Siddhesh Poyarekar wrote: > >> Does this as the first paragraph address your concerns: > > Thanks, this is nicer (see notes below). My main concern is that we shouldn't > pretend there's some method of

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

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

Re: [RFC] GCC Security policy

> On Aug 11, 2023, at 10:36 AM, Siddhesh Poyarekar wrote: > > On 2023-08-10 14:50, Siddhesh Poyarekar wrote: As a result, the only case for a potential security issue in all these cases is when it ends up generating vulnerable output for valid input source

Re: RISC-V: Added support for CRC.

> On Aug 9, 2023, at 2:32 AM, Alexander Monakov wrote: > > > On Tue, 8 Aug 2023, Jeff Law wrote: > >> If the compiler can identify a CRC and collapse it down to a table or clmul, >> that's a major win and such code does exist in the real world. That was the >> whole point behind the Fedora

Re: [RFC] GCC Security policy

> On Aug 8, 2023, at 11:55 AM, Siddhesh Poyarekar wrote: > > On 2023-08-08 11:48, David Malcolm wrote: >> On Tue, 2023-08-08 at 09:33 -0400, Paul Koning via Gcc-patches wrote: >>> >>> >>>> On Aug 8, 2023, at 9:01 AM, Jakub Jelinek via Gcc-patches

Re: [RFC] GCC Security policy

> On Aug 8, 2023, at 9:01 AM, Jakub Jelinek via Gcc-patches > wrote: > > On Tue, Aug 08, 2023 at 02:52:57PM +0200, Richard Biener via Gcc-patches > wrote: >> There's probably external tools to do this, not sure if we should replicate >> things in the driver for this. >> >> But sure, I

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

Re: [PATCH] fix pdp11_expand_epilogue (PR target/107841)

> On Jul 13, 2023, at 12:47 PM, Mikael Pettersson wrote: > > If the stack frame only contains an alloca area, then > pdp11_expand_epilogue fails to deallocate it, resulting > in callee-saved registers and the return address being > restored from the wrong stack slots. Fixed by adding > ||

Re: [PATCH] fix pdp11_expand_epilogue (PR target/107841)

> On Jul 13, 2023, at 12:47 PM, Mikael Pettersson wrote: > > If the stack frame only contains an alloca area, then > pdp11_expand_epilogue fails to deallocate it, resulting > in callee-saved registers and the return address being > restored from the wrong stack slots. Fixed by adding > ||

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

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

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)

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

Re: [committed] Convert xstormy16 to LRA

> On May 11, 2023, at 11:05 AM, Hans-Peter Nilsson via Gcc-patches > wrote: > > ... > Yes, very interesting. Thank you for sharing this. I've > seen regressions with LRA for CRIS too, for > "double-register-sized" types, which for CRIS, a 32-bit > target, translates to 64-bit types (DFmode

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: [committed] Convert xstormy16 to LRA

> On May 2, 2023, at 9:18 AM, Roger Sayle wrote: > > > On 02 May 2023 13:40, Paul Koning wrote: >>> On May 1, 2023, at 7:37 PM, Roger Sayle >> wrote: >>> >>> ... >>> The shiftsi.cc regression on xstormy16 is fixed by adding >>

Re: [committed] Convert xstormy16 to LRA

> On May 1, 2023, at 7:37 PM, Roger Sayle wrote: > > ... > The shiftsi.cc regression on xstormy16 is fixed by adding > -fno-split-wide-types. > In fact, if all the regression tests pass, I'd suggest that > flag_split_wide-types = false > should be the default on xstormy16 now that we've moved

Re: [PATCH 2/5] match.pd: Remove commented out line pragmas unless -vv is used.

On the check for verbose==2, should that be verbose >= 2 ? paul > On Apr 28, 2023, at 6:38 AM, Tamar Christina via Gcc-patches > wrote: > > Hi All, > > genmatch currently outputs commented out line directives that have no effect > but the compiler still has to parse only to discard.

Re: [committed] libgcc CRIS: Define TARGET_HAS_NO_HW_DIVIDE

> On Apr 26, 2023, at 8:05 PM, Hans-Peter Nilsson wrote: > > Not many targets define this besides msp430, pdp1, xtensa, > and arm compared to those that appear to unconditionally > have a hardware division instruction (also, pdp11 and > msp430 seem confused and should be empty instead of "1"

Re: [PATCH] Turn on LRA on all targets

> On Apr 23, 2023, at 12:47 PM, Segher Boessenkool > wrote: > > This minimal patch enables LRA for all targets. It does not clean up > the target code, nor does it do anything to generic code: it just > deletes all target definitions of TARGET_LRA_P. > > There are three kinds of changes: >

Re: [PATCH] doc: Document order of define_peephole2 scanning

I'm not sure about the meaning of part of this. "...resumes at the last generated insn." Does that mean: 1. If a match is found at some insn, the replacement defined by the matching define_peephole2 is performed, and then the scan resumes at the first of the insns produced by the

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

Re: Should -ffp-contract=off the default on GCC?

> On Mar 21, 2023, at 1:59 PM, Jeff Law via Gcc-patches > wrote: > > > > On 3/21/23 11:00, Qing Zhao via Gcc-patches wrote: >>> On Mar 21, 2023, at 12:56 PM, Paul Koning wrote: >>> >>> >>> >>>> On

Re: Should -ffp-contract=off the default on GCC?

> On Mar 21, 2023, at 11:01 AM, Qing Zhao via Gcc-patches > wrote: > > ... > Most of the compiler users are not familiar with language standards, or no > access to language standards. Without clearly documenting such warnings along > with the option explicitly, the users have not way to

Re: [RFC] Introduce -finline-memset-loops

> On Jan 13, 2023, at 8:54 PM, Alexandre Oliva via Gcc-patches > wrote: > > Hello, Richard, > > Thank you for the feedback. > > On Jan 12, 2023, Richard Biener wrote: > >> On Tue, Dec 27, 2022 at 5:12 AM Alexandre Oliva via Gcc-patches >> wrote: > >>> This patch extends the memset

Re: [PATCH] wwwdocs: Note that old reload is deprecated

> On Jan 12, 2023, at 9:40 AM, Segher Boessenkool > wrote: > > On Thu, Jan 12, 2023 at 09:17:31AM -0500, Paul Koning wrote: >>> On Jan 12, 2023, at 4:50 AM, Segher Boessenkool >>> wrote: >>> I mean general_operand accepts that sp thing you saw. But

Re: [PATCH] wwwdocs: Note that old reload is deprecated

> On Jan 12, 2023, at 4:50 AM, Segher Boessenkool > wrote: > > On Wed, Jan 11, 2023 at 05:07:47PM -0500, Paul Koning wrote: >>> On Jan 11, 2023, at 2:28 PM, Segher Boessenkool >>> wrote: >>> I would say your predicates are way too lenient here (ge

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 &

Re: [PATCH] wwwdocs: Note that old reload is deprecated

> On Jan 11, 2023, at 2:28 PM, Segher Boessenkool > wrote: > > On Wed, Jan 11, 2023 at 01:42:22PM -0500, Paul Koning wrote: >> Or, as in my case, because building with LRA as the default triggers an ICE >> that I don't understand. I posted a note to the G

Re: [PATCH] wwwdocs: Note that old reload is deprecated

> On Jan 11, 2023, at 1:32 PM, Segher Boessenkool > wrote: > > On Wed, Jan 11, 2023 at 05:27:36PM +0100, Richard Biener wrote: >>> Am 11.01.2023 um 16:17 schrieb Segher Boessenkool >>> : Note this is more info for port maintainers not for users and changes.html is for users. >>>

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"

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

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

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

Re: [PATCH] wwwdocs: Note that old reload is deprecated

Does this mean that targets that have an option to use LRA or not should now default to LRA? Some currently default to old reload. paul > On Jan 5, 2023, at 2:27 PM, Segher Boessenkool > wrote: > > Hi! > > Happy new year everyone. > > Is this patch okay to commit? > > > Segher

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

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

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

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

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) relea

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? > >

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's a bas

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

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

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

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 observable

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.

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

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://

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

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

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

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

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

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

  1   2   3   4   5   >