Re: [RFC] Linux system call builtins

[Paul Koning via Gcc]

> 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 the case of NetBSD, not for 
syscalls.  They have a somewhat odd calling convention that doesn't match any 
of the normal function call ABIs, though it's similar.

paul

Re: Sourceware mitigating and preventing the next xz-backdoor

[Paul Koning via Gcc]

> 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 systems implement a build abstraction
>> (aka DSL) that acts similar to a sandbox and enforces rules (e.g. the only
>> code run during `meson setup` is from `meson.build` files and CMake).
>> Generally speaking the only way to disobey those rules is via an "escape"
>> command (e.g. `run_command()`) of which there are few. This reduces the
>> task of auditing the build scripts for sandbox-breaking malicious intent
>> significantly, only the "escapes" need investigation and they which
>> should(tm) be rare for well-behaved projects.
>> 
>> Just like you can put your backdoor in *.m4 files, you can put them in
>> *.cmake files.
> 
> 
> CMake has its own sandbox and rules and escapes (granted, much more of
> them). But regardless, the injection code would be committed to the
> repository (point 2) and would not hold up to a source directory mounted
> read-only (point 3).

Why would the injection code necessarily be committed to the repository?  It 
wasn't in the xz attack -- one hole in the procedures is that the kits didn't 
match the repository and no checks caught this.  I don't see how a different 
build system would cure that issue.  Instead, there needs to be some sort of 
audit that verifies there aren't rogue or modified elements in the kit.

paul

Re: [RFC] Linux system call builtins

[Paul Koning via Gcc]

> 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 not obvious nor documented in your examples.
>> 
> 
> Another case would be targets allowing an immediate argument for their
> syscall instruction.  Sign extend is probably always an error, zero
> extend may give the expected results. 

It depends on the ABI.  For example, on MIPS, pointers are treated as signed 
when extending from 32 to 64 bits.

paul

Re: Sourceware mitigating and preventing the next xz-backdoor

[Paul Koning via Gcc]

> 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 those efforts !
> 
> Now, I have seen two more days of thinking about this vulnerability ... but 
> no one seem to address the following issues:
> 
> A hack was made in liblzma, which, when the code was executed by a daemon 
> that by virtue of its function, *has* to be run as root, was effective.
> 
> Two questions arise (as far as I am concerned):
> 
> 1. Do daemons like sshd *have* to be linked with shared libraries ?
>   Or could it be left to the security minded of the downstream
>   (binary) distributions to link it statically with known & proven
>   correct libraries ?

I would add: should IFUNC be deleted?  Or alternatively, should it be strictly 
limited only to non-security-sensitive applications when not running as root?

> 2. Is it a limitation of the Unix / Linux daemon concept that, once
>   such a process needs root access, it has to have root access
>   *always* - even when performing trivial tasks like compressing
>   data ?

Clearly not, given the existence of the "seteuid" syscall.

> I recall quite well (vis-a-vis question 2) that the VMS equivalent would drop 
> all privileges at the start of the code, and request only those relevant when 
> actually needed (e.g., to open a file for reading that was owned by [the 
> equivalent on VMS] of root - or perform other functions that only root could 
> do), and then drop them immediately afterwards again.

Yes, and with additional effort all "root" type applications could be written 
that way.

paul

Re: Sourceware mitigating and preventing the next xz-backdoor

[Paul Koning via Gcc]

> 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 linked against liblzma.  The actual attack
 occurred via a connection to a corrupt sshd.  If sshd was running as
 root, as is normal, the attacker had root access to the machine.  None
 of the attacking steps had anything to do with having root access
 while building or installing the program.
>> 
>> There does not seem a single good solution against something like this.
>> 
>> My take a way is that software needs to become less complex. Do 
>> we really still need complex build systems such as autoconf?
> 
> Do we really need complex languages like C++ to write our software in?  
> SCNR :)  Complexity lies in the eye of the beholder, but to be honest in 
> the software that we're dealing with here, the build system or autoconf 
> does _not_ come to mind first when thinking about complexity.
> 
> (And, FWIW, testing for features isn't "complex".  And have you looked at 
> other build systems?  I have, and none of them are less complex, just 
> opaque in different ways from make+autotools).
> 
> Ciao,
> Michael.

I would tend to agree with that even given my limited exposure to alternatives.

One aspect of the present attack that needs to be cured is that -- as I 
understand it -- the open source repository was fine but the kit as distributed 
had been subverted.  In other words, the standard assumption that the 
repository actually corresponds to the released code was not valid.  And 
furthermore, that it wasn't unusual for the kit to contain different or 
additional elements, just that it wasn't supposed to differ in malicious ways.

One possible answer is for all elements of kits to be made explicitly visible, 
though generated files probably don't want to be held in a normal source 
control system.  Another possible answer is for consumers of kits to treat kits 
as suspect, and have them unpacked and examined -- including any elements not 
source controlled -- before acceptance.  I think the first option is better 
because it exposes these additional elements to ongoing scrutiny from the 
entire community, rather than only one-time inspection by release managers who 
are probably quite pressed for time.

Either way, the reasons for these extra files to exist and the manner in which 
they are supposed to be generated would need to be both well documented and 
readily reproducible by outside parties.

paul

Re: Sourceware mitigating and preventing the next xz-backdoor

[Paul Koning via Gcc]

> 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 hosted projects was minimal.
>>> 
>>> This email isn't about the xz-backdoor itself. Do see Sam James FAQ
>>> https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27
>>> (Sorry for the github link, but this one does seem viewable without
>>> proprietary javascript)
>>> 
>>> We should discuss what we have been doing and should do more to
>>> mitigate and prevent the next xz-backdoor. There are a couple of
>>> Sourceware services that can help with that.
>>> 
>>> TLDR;
>>> - Replicatable isolated container/VMs are nice, we want more.
>>> - autoregen buildbots, it should be transparent (and automated) how to
>>>regenerate build/source files.
>>> - Automate (snapshot) releases tarballs.
>>> - Reproducible releases (from git).
>>> 
>>> [snip]
>> 
>> While I appreciate the effort to harden the Sourceware infrastructure 
>> against malicious attacks and want to join in on thanking everyone who 
>> helped analyze this issue, to me it seems like the much bigger problem is 
>> that XZ had a maintainer who appears to have acted in bad faith.  Are the 
>> development processes used by the GNU toolchain components robust enough to 
>> cope with deliberate sabotage of the code base?  Do we have enough eyes 
>> available to ensure that every commit, even those by designated maintainers, 
>> is vetted by someone else?  Do we to harden our process, too, to require all 
>> patches to be signed off by someone else before committing?
>> 
>> -Sandra
>> 
>> 
> What likely happened for the maintainer who acted in bad faith was that they 
> entered the project with bad faith intent from the start - seeing as they 
> were only involved with the project for 2 years, and there was much social 
> pressure from fake email accounts for the single maintainer of XZ to accept 
> help.
> 
> While we would obviously like to have more area maintainers and possibly 
> global maintainers to help spread the load, I don't think any of the projects 
> listed here are all that susceptible to the same type of social engineering. 
> For one, getting the same type of blanket approval would be a much more 
> involved process because we already have a reasonable amount of people with 
> those privileges, no one is dealing with burnout and sassy customers saying 
> we aren't doing enough.
> 
> Beyond that, we (GDB) are already experimenting with approved-by, and I think 
> glibc was doing the same. That guarantees at least a second set of eyes that 
> analyzed and agreed with the patch, I don't think signed-off would add more 
> than that tag (even if security was not the reason why we implemented them).
> 
> -- 
> Cheers,
> Guinevere Larsen
> She/Her/Hers

I agree that GDB, and for that matter other projects with significant numbers 
of contributors, are not nearly as likely to be vulnerable to this sort of 
attack.  But I worry that xz may not be the only project that's small enough to 
be vulnerable, and be security-relevant in not so obvious ways.

One question that comes to mind is whether there has been an effort across the 
open source community to identify possible other targets of such attacks.  
Contributions elsewhere by the suspect in this case are an obvious concern, but 
similar scenarios with different names could also be.  That probably should be 
an ongoing activity: whenever some external component is used, it would be 
worth knowing how it is maintained, and how many eyeballs are involved.  Even 
if this isn't done by everyone, it seems like a proper precaution for security 
sensitive projects.

Another question that comes to mind: I would guess that relevant law 
enforcement agencies are already looking into this, but it would seem 
appropriate for those closest to the attacked software to reach out explicitly 
and assist in any criminal investigations.

paul

Re: Sourceware mitigating and preventing the next xz-backdoor

[Paul Koning via Gcc]

> 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.
> 
> Although signoffs can indeed help catch inadvertent mistakes, they're 
> relatively useless against determined attacks of this form, and we must 
> assume that nation-state attackers will be determined.

Another consideration is the size of the project.  "Many eyeballs" helps if 
there are plenty of people watching.  For smaller tools that have only a small 
body of contributors, it's easier for one or two malicious ones to subvert 
things.

Would it help to require (rather than just recommend) "don't use root except 
for the actual 'install' step" ?

paul

Re: [PATCH] Turn on LRA on all targets

[Paul Koning]

> 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 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 (the 
>>> RET machine instruction uses the stack frame information to restore the 
>>> previous PC, FP, SP, AP and any static registers saved by CALLS).
>> 
>> That would make sense; it's like the heuristic unwinder found in some 
>> other targets (I remember the MIPS one, which worked fairly well and 
>> allowed debugging without useable debug data).
> 
> Not really, in particular because EH unwinding has to be reliable and 
> heuristics inherently is not.

Fair enough, but what I meant is only that it's conceptually similar: unwind 
based on the code and machine state, rather than auxiliary information like 
debug data.  And I think your point was that on VAX this is indeed a reliable 
technique by virtue of the iSA.  In fact, the standard way to do exeception 
handling unwinding is part of the originail VAX architecture (via the otherwise 
unused first word (I think) of the call frame).

paul

Re: [PATCH] Turn on LRA on all targets

[Paul Koning]

> 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 ready to go in but I'll wait for State 1 to open.  Correct?

paul

Re: [PATCH] Turn on LRA on all targets

[Paul Koning]

> 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 (the 
> RET machine instruction uses the stack frame information to restore the 
> previous PC, FP, SP, AP and any static registers saved by CALLS).

That would make sense; it's like the heuristic unwinder found in some other 
targets (I remember the MIPS one, which worked fairly well and allowed 
debugging without useable debug data).

paul

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

[Paul Koning]

> 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 patch.
> 
> I thought that I’d had to include unistd.h for the first patch in this 
> thread; clearly not!
> 
> What I hope will be the final version:
> 
> ——— 8< .———
> 
> In gcc/ada/adaint.c(__gnat_get_file_names_case_sensitive), the current
> assumption for __APPLE__ is that file names are case-insensitive
> unless __arm__ or __arm64__ are defined, in which case file names are
> declared case-sensitive.
> 
> The associated comment is
>  "By default, we suppose filesystems aren't case sensitive on
>  Windows and Darwin (but they are on arm-darwin)."
> 
> This means that on aarch64-apple-darwin, file names are treated as
> case-sensitive, which is not the default case.
> 
> The true default position is that macOS file systems are
> case-insensitive, iOS file systems are case-sensitive.

Sort of.  The most common choices for Mac OS file system type are indeed case 
insensitive, but it also allows case sensitive file systems. 

paul

Re: Odd Python errors in the G++ testsuite

[Paul Koning via Gcc]

> 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)"(timeout = 300)
>> spawn -ignore SIGHUP python3 -c import sys; assert sys.version_info >= (3, 6)
> 
> What version of Python3 do you have? The test suite might not actually
> properly handle not having 3.7 (i.e., skip the tests that require it).

But the rule that you can't put a dict in a set is as old as set support (2.x 
for some small x).

paul

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

[Paul Koning via Gcc]

> 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 examples such as a FFT, 
> complex Gaussian random number generation, mandelbrot
> set computation, etc.

Another nice one might be NEC-2, an electromagnetic field analyzer used to 
model antennas and similar problems.

paul

Re: Unexpected behavior of gcc on pointer dereference & increment

[Paul Koning via Gcc]

> 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.cppreference.com/w/c/language/operator_precedence shows that.  
Liberal use of parentheses is a very good practice. 

paul

Re: RISC-V: Added support for CRC.

[Paul Koning via Gcc-patches]

> 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 advantage of it.  They just compile normally
>>> and their bitwise CRC gets optimized down to either a table lookup or a 
>>> clmul
>>> variant.  That's the real goal here.
>> 
>> The only high-profile FOSS project that carries a bitwise CRC implementation
>> I'm aware of is the 'xz' compression library. There bitwise CRC is used for
>> populating the lookup table under './configure --enable-small':
>> 
>> https://github.com/tukaani-project/xz/blob/2b871f4dbffe3801d0da3f89806b5935f758d5f3/src/liblzma/check/crc64_small.c
>> 
>> It's a well-reasoned choice and your compiler would be undoing it
>> (reintroducing the table when the bitwise CRC is employed specifically
>> to avoid carrying the table).

Is that compiled with -Os?  It would seem sensible for that to be the case, and 
for the table optimization to be suppressed if that switch is used.

paul

Re: [RFC] GCC Security policy

[Paul Koning via Gcc-patches]

> 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 timing attacks:
> https://en.wikipedia.org/wiki/Timing_attack
> 
>> No, compilers don't help with that (at least C doesn't -- Ada might be
>> better here but I don't know enough).  For sufficiently strict
>> requirements you'd have to examine both the generated machine code and
>> understand, in gruesome detail, what the timing behaviors of the executing
>> hardware are.  Good luck if it's a modern billion-transistor machine.
> 
> Yes. On the other hand, the reality in the FOSS ecosystem is that
> cryptographic libraries heavily lean on the ability to express
> a constant-time algorithm in C and get machine code that is actually
> constant-time. There's a bit of a conflict here between what we
> can promise and what people might expect of GCC, and it seems
> relevant when discussing what goes into the Security Policy.

I agree.  What should be said is that such techniques are erroneous.  The kind 
of code you're talking about inserts steps not strictly needed for the 
calculation to make it constant time (or more nearly so).  But clearly that has 
to rely on an assumption that the optimizer isn't smart enough to spot those 
unnecessary operations and delete them.  Never mind the fact that it relies on 
a notion that C statements have timing properties in the first place, which the 
standard doesn't do.

So I would argue that a serious attempt to cure timing attacks has to be coded 
in assembly language.  Even then, of course, optimizations in modern machine 
pipelines may give you trouble, but at least in that case you're writing 
explicitly for a specific ISA and are in a position to take into account its 
timing properties, to the extent they are known and defined.

paul

Re: [RFC] GCC Security policy

[Paul Koning via Gcc-patches]

> 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 the programmer and the development team to choose the right software
>> engineers and right tools.  And to have the development environment and
>> checks in place to ensure that the results are meeting the requirements.
>> 
>> It is not the role of GCC or its security policy to tell people how to do
>> their job or hobby.  This isn't a safety tag required to be attached to a
>> new mattress.
> 
> Yes (though I'm afraid the analogy with the mattress is a bit lost on me).
> Those examples were meant to illustrate the point I tried to make earlier,
> not as additions proposed for the Security Policy. Specific examples
> where we can tell people in advance that compiler output needs to be
> verified, because the compiler is not engineered to preserve those
> security-relevant properties from the source code (and we would not
> accept such accidents as security bugs).

Now I'm confused.  I thought the whole point of what GCC is trying to, and 
wants to document, is that it DOES preserve security properties.  If the source 
code is standards-compliant and contains algorithms free of security holes, 
then the compiler is supposed to deliver output code that is likewise free of 
holes -- in other words, the transformation performed by GCC does not introduce 
holes in a hole-free input.

> Granted, it is a bit of a stretch since the notion of timing-safety is
> not really well-defined for C source code, but I didn't come up with
> better examples.

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.  No, compilers don't help with that (at least C doesn't -- Ada 
might be better here but I don't know enough).  For sufficiently strict 
requirements you'd have to examine both the generated machine code and 
understand, in gruesome detail, what the timing behaviors of the executing 
hardware are.  Good luck if it's a modern billion-transistor machine.

Again, I don't see that as a security property.  If it's considered desirable 
to say something about this, fine, but the words Siddesh crafted don't fit for 
that kind of property.

paul

Re: [RFC] GCC Security policy

[Paul Koning via Gcc-patches]

> 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 verifying that arbitrary source code is "safe"
> to pass to an unsandboxed compiler, nor should we push the responsibility of
> doing that on users.

Perhaps, but clearly the compiler can't do it ("Halting problem"...) so it has 
to be clear that the solution must be outside the compiler.  

paul

Re: Porting to a custom ISA

[Paul Koning via Gcc]

> 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 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 make sense to me.  Libgcc 
>> certainly is fine for 16 bit targets -- after all, GCC supports pdp11 which 
>> is such a target.  And while newlib doesn't have pdp11 support I have done 
>> some fragments of pdp11 support for it, to give me a way to run the 
>> execution part of the GCC test suite.  One of these days I should do a 
>> better job.  As far as I know it's entirely doable.
> The comment is in msp430.h and rl78.h, line 160. And it appears quite common 
> to artifically set `UNITS_PER_WORD` to 4 instead of the correct 2 or 1 when 
> compiling libgcc accross other backends as well, including avr, gcn. Is this 
> out-of-date and no longer required for libgcc?

It simply seems wrong.  In pdp11.h UNITS_PER_WORD is 2, which is what the 
machine requires.  And that works fine.

Perhaps the issue is that the libgcc routines implement operations not handled 
by the target hardware, or by expansion in the machine description.  So for 16 
bit machines you're going to need a bunch of 32 bit support routines, but 
probably not 16 bit support routines.  There are some examples, though.  Not 
all pdp11s have divide instructions so there is a udivhi3 function in libgcc, 
and the pdp11 config files call for that to be included.  

paul

Re: Porting to a custom ISA

[Paul Koning via Gcc]

> 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` when compiling with anything higher than -O0. How
>> do I correctly provide an implementation for that? Or disable it's
>> usage? Our epilogue is non-trivial, and it doesn't look like the other
>> backends use something like `(define_insn "return" ...)`.
> 
> Somebody else has to answer this.

Again using pdp11 as an example -- it doesn't define any of the *return 
patterns either.  Instead it has a define_expand "epilogue" which calls a 
function to generate all the necessary elements, the last of which is a 
machine-specific pattern that will produce the final return instruction.  

This is using the RTL flavor of prologue/epilogue.  At one point in the past 
that target directly emitted the assembly code for those, which isn't the 
recommended approach.  I tried the RTL flavor and found it to be a better 
answer, and it certainly works for all the optimization levels.

paul

Re: Porting to a custom ISA

[Paul Koning via Gcc]

> 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 make sense to me.  Libgcc certainly 
is fine for 16 bit targets -- after all, GCC supports pdp11 which is such a 
target.  And while newlib doesn't have pdp11 support I have done some fragments 
of pdp11 support for it, to give me a way to run the execution part of the GCC 
test suite.  One of these days I should do a better job.  As far as I know it's 
entirely doable.

pdp11, in GCC, can have either 16 or 32 bit int, it's a compiler option.  
Pointers are 16 bits, of course.  And it does support larger types (even 64 
bits), expanding into multiple instructions or libgcc calls.  A lot of that is 
handled by common code; the pdp11.md machine description handles a few of them 
to optimize those cases beyond what the common code would produce.  If you're 
doing a 16 bit target you might look at pdp11 for ideas.  One limitation is 
that right now it does only C, mainly because the object format is a.out rather 
than ELF.  That could be fixed.

paul

Re: [RFC] GCC Security policy

[Paul Koning via Gcc-patches]

> 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 code.
>>> 
>>> I think this leaves open the interpretation "every wrong code bug
>>> is potentially a security bug".  I suppose that's true in a trite sense,
>>> but not in a useful sense.  As others said earlier in the thread,
>>> whether a wrong code bug in GCC leads to a security bug in the object
>>> code is too application-dependent to be a useful classification for GCC.
>>> 
>>> I think we should explicitly say that we don't generally consider wrong
>>> code bugs to be security bugs.  Leaving it implicit is bound to lead
>>> to misunderstanding.
>> I see what you mean, but the context-dependence of a bug is something GCC 
>> will have to deal with, similar to how libraries have to deal with bugs.  
>> But I agree this probably needs some more expansion.  Let me try and come up 
>> with something more detailed for that last paragraph.
> 
> How's this:
> 
> As a result, the only case for a potential security issue in the compiler is 
> when it generates vulnerable application code for valid, trusted input source 
> code.  The output application code could be considered vulnerable if it 
> produces an actual vulnerability in the target application, specifically in 
> the following cases:

You might make it explicit that we're talking about wrong code errors here -- 
in other words, the source code is correct (conforms to the standard) and the 
algorithm expressed in the source code does not have a vulnerability, but the 
generated code has semantics that differ from those of the source code such 
that it does have a vulnerability.

> - The application dereferences an invalid memory location despite the 
> application sources being valid.
> 
> - The application reads from or writes to a valid but incorrect memory 
> location, resulting in an information integrity issue or an information leak.
> 
> - The application ends up running in an infinite loop or with severe 
> degradation in performance despite the input sources having no such issue, 
> resulting in a Denial of Service.  Note that correct but non-performant code 
> is not a security issue candidate, this only applies to incorrect code that 
> may result in performance degradation.

The last sentence somewhat contradicts the preceding one.  Perhaps "...may 
result in performance degradation severe enough to amount to a denial of 
service".

> - The application crashes due to the generated incorrect code, resulting in a 
> Denial of Service.

paul

Re: RISC-V: Added support for CRC.

[Paul Koning via Gcc-patches]

> 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 experiment -- to determine if these things are
>> showing up in the real world or if this is just a benchmarking exercise.
> 
> Can you share the results of the experiment and give your estimate of what
> sort of real-world improvement is expected? I already listed the popular
> FOSS projects where CRC performance is important: the Linux kernel and
> a few compression libraries. Those projects do not use a bitwise CRC loop,
> except sometimes for table generation on startup (which needs less time
> than a page fault that may be necessary to bring in a hardcoded table).
> 
> For those projects that need a better CRC, why is the chosen solution is
> to optimize it in the compiler instead of offering them a library they
> could use with any compiler?
> 
> Was there any thought given to embedded projects that use bitwise CRC
> exactly because they little space for a hardcoded table to spare?

Or those that use smaller tables -- for example, the classic VAX microcode 
approach with a 16-entry table, doing CRC 4 bits at a time.

I agree that this seems an odd thing to optimize.  CRC is a well known CPU hog 
with well established efficient solutions, and it's hard to see  why anyone who 
needs good performance would fail to understand and apply that knowledge.

paul

Re: [RFC] GCC Security policy

[Paul Koning via Gcc-patches]

> 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
>>>>  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 think the driver is the proper point to address any
>>>>> of such
>>>>> issues - iff we want to address them at all.  Maybe a nice little
>>>>> google summer-of-code project ;)
>>>> 
>>>> What I'd really like to avoid is having all compiler bugs
>>>> (primarily ICEs)
>>>> considered to be security bugs (e.g. DoS category), it would be
>>>> terrible to
>>>> release every week a new compiler because of the "security" issues.
>>> 
>>> Indeed.  But my answer would be that such things are not DoS issues.
>>> DoS means that an external input, over which you have little control,
>>> is impairing service.  In the case of a compiler, if feeding it bad
>>> source code X.c causes it to crash, the answer is "well, then don't
>>> do that".
>> Agreed.
>> I'm not sure how to "wordsmith" this, but it seems like the sources and
>> options on the *host* are assumed to be trusted, and that the act of
>> *compiling* source on the host requires trusting them, just like the
>> act of executing the compiled code on the target does.  Though users
>> may be more familiar with sandboxing the target than the host.
>> We should spell this out further for libgccjit: libgccjit allows for
>> ahead-of-time and JIT compilation of sources - but it assumes that
>> those sources (and the compilation options) are trusted.
>> [Adding Andrea Corallo to the addressees]
>> For example, Emacs is using libgccjit to do ahead-of-time compilation
>> of Emacs bytecode.  I'm assuming that Emacs is assuming that its
>> bytecode is trusted, and that there isn't any attempt by Emacs to
>> sandbox the Emacs Lisp being processed.
>> However, consider a situation in which someone attempted to, say, embed
>> libgccjit inside a web browser to generate machine code from
>> JavaScript, where the JavaScript is potentially controlled by an
>> attacker.  I think we want to explicitly say that that if you're going
>> to do that, you need to put some other layer of defense in, so that
>> you're not blithely accepting the inputs to the compilation (sources
>> and options) from a potentially hostile source, where a crafted input
>> sources could potentially hit an ICE in the compiler and thus crash the
>> web browser.
> 
> +1, this is precisely the kind of thing the security policy should warn 
> against and suggest using sandboxing for.  The compiler (or libgccjit) isn't 
> really in a position to defend such uses, ICE or otherwise.

I agree somewhat.  But only somewhat, because the compiler's job is not to 
crash even if presented with bad inputs.  An ICE is a bug, which of course 
we've always accepted.  But as several have agreed, it's not a DoS bug, 
therefore not a security bug.

The scenario of the web browser is a valid one, and I would use it to 
illustrate a general point, which is redundancy in safety measures. If inputs 
come from possibly hostile sources, it's sound practice to have multiple layers 
of protection.  The consuming software should be robust so it doesn't fail when 
subjected to bad inputs.  But additional layers of protection in case there is 
a defect in the first layer are valuable, and sandboxing or the like (chroot, 
for example) can provide that additional defense.  This isn't really a GCC 
issue but rather a general principle of prudence.

paul

Re: [RFC] GCC Security policy

[Paul Koning via Gcc-patches]

> 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 think the driver is the proper point to address any of such
>> issues - iff we want to address them at all.  Maybe a nice little
>> google summer-of-code project ;)
> 
> What I'd really like to avoid is having all compiler bugs (primarily ICEs)
> considered to be security bugs (e.g. DoS category), it would be terrible to
> release every week a new compiler because of the "security" issues.

Indeed.  But my answer would be that such things are not DoS issues.  DoS means 
that an external input, over which you have little control, is impairing 
service.  In the case of a compiler, if feeding it bad source code X.c causes 
it to crash, the answer is "well, then don't do that".

paul

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

[Paul Koning via Gcc]

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 you're writing code with undefined semantics, and the answer is 
not to do so. 

paul

> On Aug 1, 2023, at 12:43 PM, Bradley Lucier via Gcc  wrote:
> 
> The Gambit Scheme->C compiler has an option to generate more efficient code 
> if it knows that all tail and sibling calls in the generated C code will be 
> optimized.  If gcc does not, however, optimize a tail or sibling call, the 
> generated C code may be incorrect (depending on circumstances).
> 
> So I would like to add a warning enabled by -Wdisabled-optimization so that 
> if -foptimize-sibling-calls is given and a tail or sibling call is not 
> optimized, then a warning is triggered.
> 
> I don't quite know where to place the warning.  It would be good if there 
> were one piece of code to identify all tail and sibling calls, and then 
> another piece that decides whether the optimization can be performed.
> 
> I see code in gcc/tree-tailcall.cc
> 
> suitable_for_tail_opt_p
> suitable_for_tail_call_opt_p
> 
> which are called by
> 
> tree_optimize_tail_calls_1
> 
> which takes an argument
> 
> opt_tailcalls
> 
> and it's called in one place with opt_tailcalls true and in another place 
> with opt_tailcalls false.
> 
> So I'm losing the plot here.
> 
> There is other code dealing with tail calls in gcc/calls.cc I don't seem to 
> understand at all.
> 
> Any advice?
> 
> Brad

Re: LRA for avr: help with FP and elimination

[Paul Koning via Gcc]

> 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 function arguments, 
> function calls, alloca only.  AP is used for incoming function arguments 
> and is set automatically by hardware at function entry.  FP is used for 
> local variables and is likewise set by hardware at function entry.

While most other targets maintain FP in software, doesn't the same description 
apply to any target that can have a frame pointer.  The frame pointer may be 
used only some of the time (PDP-11) or always (VAX) but when it's used local 
variable references and argument references would go through FP, not SP, right?

paul

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

[Paul Koning via Gcc-patches]

> 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
> || cfun->calls_alloca to the condition for deallocating
> the frame.
> 
> Tested with a cross to pdp11-unknown-aout.
> 
> Ok for master? (Note: I don't have commit rights.)
> 
> gcc/
> 
>   PR target/107841
>   * config/pdp11/pdp11.c (pdp11_expand_epilogue): Also
>   deallocate alloca-only frame.
> 
> gcc/testsuite/
> 
>   PR target/107841
>   * gcc.target/pdp11/pr107841.c: New test.
> ---
> gcc/config/pdp11/pdp11.cc |  2 +-
> gcc/testsuite/gcc.target/pdp11/pr107841.c | 12 
> 2 files changed, 13 insertions(+), 1 deletion(-)
> create mode 100644 gcc/testsuite/gcc.target/pdp11/pr107841.c
> 
> diff --git a/gcc/config/pdp11/pdp11.cc b/gcc/config/pdp11/pdp11.cc
> index f6dd841f184..311a1d225e0 100644
> --- a/gcc/config/pdp11/pdp11.cc
> +++ b/gcc/config/pdp11/pdp11.cc
> @@ -393,7 +393,7 @@ pdp11_expand_epilogue (void)
>   rtx x, reg, via_ac = NULL;
> 
>   /* Deallocate the local variables.  */
> -  if (fsize)
> +  if (fsize || cfun->calls_alloca)
> {
>   if (frame_pointer_needed)
>   {
> diff --git a/gcc/testsuite/gcc.target/pdp11/pr107841.c 
> b/gcc/testsuite/gcc.target/pdp11/pr107841.c
> new file mode 100644
> index 000..a363c468b0b
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/pdp11/pr107841.c
> @@ -0,0 +1,12 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2" } */
> +
> +/* Verify that the stack frame is deallocated using the frame pointer.  */
> +
> +void qq (int a)
> +{
> +char *s = __builtin_alloca (128);
> +__builtin_sprintf (s, "qq %d", 3);
> +}
> +
> +/* { dg-final { scan-assembler "mov\tr5,sp" } } */
> -- 
> 2.41.0
> 


Thanks Mikael.  I committed this fix.

paul

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

[Paul Koning via Gcc-patches]

> 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
> || cfun->calls_alloca to the condition for deallocating
> the frame.
> 
> Tested with a cross to pdp11-unknown-aout.
> 
> Ok for master? (Note: I don't have commit rights.)

Yes, thank you!

Question for the experts: how is this handled?  Do I need to apply this change 
to my workspace and commit it, with Mikael as the change author?

paul

> 
> gcc/
> 
>   PR target/107841
>   * config/pdp11/pdp11.c (pdp11_expand_epilogue): Also
>   deallocate alloca-only frame.
> 
> gcc/testsuite/
> 
>   PR target/107841
>   * gcc.target/pdp11/pr107841.c: New test.
> ---
> gcc/config/pdp11/pdp11.cc |  2 +-
> gcc/testsuite/gcc.target/pdp11/pr107841.c | 12 
> 2 files changed, 13 insertions(+), 1 deletion(-)
> create mode 100644 gcc/testsuite/gcc.target/pdp11/pr107841.c
> 
> diff --git a/gcc/config/pdp11/pdp11.cc b/gcc/config/pdp11/pdp11.cc
> index f6dd841f184..311a1d225e0 100644
> --- a/gcc/config/pdp11/pdp11.cc
> +++ b/gcc/config/pdp11/pdp11.cc
> @@ -393,7 +393,7 @@ pdp11_expand_epilogue (void)
>   rtx x, reg, via_ac = NULL;
> 
>   /* Deallocate the local variables.  */
> -  if (fsize)
> +  if (fsize || cfun->calls_alloca)
> {
>   if (frame_pointer_needed)
>   {
> diff --git a/gcc/testsuite/gcc.target/pdp11/pr107841.c 
> b/gcc/testsuite/gcc.target/pdp11/pr107841.c
> new file mode 100644
> index 000..a363c468b0b
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/pdp11/pr107841.c
> @@ -0,0 +1,12 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2" } */
> +
> +/* Verify that the stack frame is deallocated using the frame pointer.  */
> +
> +void qq (int a)
> +{
> +char *s = __builtin_alloca (128);
> +__builtin_sprintf (s, "qq %d", 3);
> +}
> +
> +/* { dg-final { scan-assembler "mov\tr5,sp" } } */
> -- 
> 2.41.0
> 

Re: abi

[Paul Koning via Gcc]

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 good reason 
is an OS that doesn't care about compatibility, which means it doesn't care 
about its customers.

The MIPS examples I pointed to are a good illustration of this.  The original 
("O32") ABI is for MIPS with 32 bit registers and 32 bit addressing.  N32 and 
N64 were introduced by SGI to support 64 bit registers, and (for N64) 64 bit 
pointers.  That's a very compelling benefit.  64 bbit addressing is obvious, 
and the performance benefit from using 64 bit registers on machines that have 
them is very large.  So there, the quite large cost of doing this was totally 
justified.

paul

> On Jul 9, 2023, at 4:55 PM, André Albergaria Coelho via Gcc  
> wrote:
> 
> If we can select the ABi for our program (using gcc), why is there a need for 
> ABI stability?!
> 
> why not put it on a define
> 
> 
> #define abi v3
> 
> int main() {
> 
> }
> 
> 
> Each user would just have to compile the code, to follow the abi...no need to 
> worry changing it
> 
> 
> thanks
> 
> 
> andre
> 

Re: abi

[Paul Koning via Gcc]

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 -g -abi 1 -o something
> 
> 
> thanks
> 
> 
> andre
> 

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

[Paul Koning via Gcc]

> 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) and 
> fuck off? 

Done.  Since you have not shown any ability to have a civilized conversation, I 
will now use my email filter to be spared any further exposure.

paul

Re: End of subscription

[Paul Koning via Gcc]

> 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: gcc@gcc.gnu.org Filter messages from this mailing list
>> It does for me, under the ⏷ menu at the end of the recipient list in the
>> message pane.  Be sure that you select a message copy that you actually
>> received through the mailing list.
> 
> The iOS official mail app does not say 'this message is from a mailing list' 
> either. All the other mails from GitHub, SourceForge, StackOverflow, ncurses 
> etc. are marked as from mailing lists. I suspect there is kinda 
> misconfiguration.

Curious, because Mac OS mail does show it as a mailing list message, offering 
up an "unsubscribe" button.  So it looks like an iOS mail bug.

paul

Re: [committed] Convert xstormy16 to LRA

[Paul Koning via Gcc-patches]

> 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 and DImode), and
> where LRA does a much worse job than reload; spills a lot
> more often to stack, even after trying every
> register-allocation-related hook I found (and also an LRA
> patch which helped only by a fraction, but regressed results
> on x86_64-linux, so let's quickly forget it again).

That observation makes me a bit worried.  While CRIS may not be a priority 
platform, that description makes it sound like a case that would be significant 
in any 32 bit platform, which would include priority ones like i386 and ARM.

If that's true, I wonder about dropping Reload.  While I understand it's been 
years since LRA was first introduced, wouldn't we even so want to go by the 
rule that a newer replacement mechanism doesn't replace an older one  until the 
replacement demonstrates comparable or better output compared with the older 
one?

paul

Re: More C type errors by default for GCC 14

[Paul Koning via Gcc]

> 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
> all.  If the developer avoids dealing with this problem, then he or
> she might be sweeping the problem under the carpet.  But this is not
> GCC's problem.

Agreed.  -Wall -Werror exists for a reason, and choosing to use that it helpful 
but not necessarily feasible for everyone if confronted with old mouldy code.

I remember a wonderful article (out of MIT?) explaining a whole bunch of 
somewhat-surprising C standard rules and why they allowed the compiler to do 
things that many people don't expect.  As I recall, a lot of those were things 
that Linux didn't want and therefore would suppress with suitable -f 
flags.  "Strict aliasing" may have been one of those -- I still remember my 
somewhat-surprised reaction when I first learned what that is and why my 
"obvious" C code was not valid.

I also agree with Eli that using C to write highly reliable code is, shall we 
say, quite a challenge.  The language just isn't well suited for that.  But GCC 
also supports Ada :-)  and now Modula-2.

paul

Re: [committed] Convert xstormy16 to LRA

[Paul Koning via Gcc-patches]

> 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
>>> -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 to LRA.  And if this works for xstormy16, it might be
>>> useful to other targets for the LRA transition; it's a difference in
>>> behaviour between reload and LRA that could potentially affect
>>> multiple targets.
>> 
>> Is there documentation for that flag?
> 
> Yes, see the section -fsplit-wide-types in
> https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html

Thanks.  So I'm wondering why that would be a problem.

The obvious question is whether it interacts badly with MD file entries that 
describe wide operations, perhaps with constraints that require things like 
odd/even register pairs.  But I would assume all that gets handled.

Along the same lines, why would a target, or a user, not do early wide 
splitting all the time?  The documentation for that option gives no clue why it 
would ever be bad.

paul

Re: [committed] Convert xstormy16 to LRA

[Paul Koning via Gcc-patches]

> 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 to LRA.  And if this
> works for xstormy16, it might be useful to other targets for the LRA
> transition;
> it's a difference in behaviour between reload and LRA that could potentially
> affect multiple targets.

Is there documentation for that flag?  

paul

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

[Paul Koning via Gcc-patches]

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.
> 
> They are however handy when debugging genmatch output.  As such this moves 
> them
> behind the -vv flag.
> 
> Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
> 
> Ok for master?
> 
> Thanks,
> Tamar
> 
> gcc/ChangeLog:
> 
>   PR bootstrap/84402
>   * genmatch.cc (output_line_directive): Only emit commented directive
>   when -vv.
>   (main): Initialize verbose.
> 
> --- inline copy of patch -- 
> diff --git a/gcc/genmatch.cc b/gcc/genmatch.cc
> index 
> 638606b2502f640e59527fc5a0b23fa3bedd0cee..6d62cdea2082d92e5ecc1102c80205115a4e3040
>  100644
> --- a/gcc/genmatch.cc
> +++ b/gcc/genmatch.cc
> @@ -209,7 +209,7 @@ output_line_directive (FILE *f, location_t location,
>   else
>   fprintf (f, "%s:%d", file, loc.line);
> }
> -  else
> +  else if (verbose == 2)
> /* Other gen programs really output line directives here, at least for
>development it's right now more convenient to have line information
>from the generated file.  Still keep the directives as comment for now
> @@ -5221,6 +5221,7 @@ main (int argc, char **argv)
> return 1;
> 
>   bool gimple = true;
> +  verbose = 0;
>   char *input = argv[argc-1];
>   for (int i = 1; i < argc - 1; ++i)
> {
> 
> 
> 
> 
> -- 
> 

Re: [committed] libgcc CRIS: Define TARGET_HAS_NO_HW_DIVIDE

[Paul Koning via Gcc-patches]

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

How so, "confused"?  The documentation says it should be defined, it doesn't 
say that it should be defined as empty.  What goes wrong if it's defined as 1 
rather than empty?

The documentation is also somewhat misleading, because it says to define it if 
the hardware has no divide instruction.  The more accurate statement is that it 
should be defined if the hardware has no 64 / 32 bit divide hardware support.  
pdp11.h points this out in a comment, because most pdp11s do have divide 
instructions but those are for 32 / 16 bits.

paul

Re: [PATCH] Turn on LRA on all targets

[Paul Koning via Gcc-patches]

> 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:
> 
> 1) Targets that already always have LRA, but that redefine the hook
> anyway.  These are gcn, pdp11, rx, sparc, vax, and xtensa.  Nothing
> really changes for these targets with this patch (but later patches
> will delete the superfluous hook implementations).

I thought that the existing coding for pdp11 makes LRA selectable (via -mlra) 
and defaults to off.  I had planned to change it to default to on but leave it 
selectable.  I suppose just having it on is ok too, although the code from LRA 
wasn't as efficient as the old last I looked (which is a while ago).

paul

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

[Paul Koning via Gcc-patches]

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

or

2. 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 insn 
immediately following the ones just matched.

"Last generated" seems to fit option 1, but I'm not sure if that's what you 
meant.  Maybe you could add some words to say more explicitly which it is.

paul

> On Apr 18, 2023, at 1:55 PM, Hans-Peter Nilsson via Gcc-patches 
>  wrote:
> 
> Generated pdf inspected.  Ok to commit?
> 
> Thoughts on fixing the IMHO wart to also expose all
> replacements to all define_peephole2?  Looks feasible
> (famous last words), but then again I haven't checked the
> history yet.
> 
> -- >8 --
> I was a bit surprised when my define_peephole2 didn't match,
> but it was because it was expected to partially match the
> generated output of a previous define_peephole2.  I had
> assumed that the algorithm exposed newly created opportunities
> to all define_peephole2's.  While things can change in that
> direction, let's start with documenting the current state.
> 
>   * doc/md.texi (define_peephole2): Document order of scanning.
> ---
> gcc/doc/md.texi | 8 
> 1 file changed, 8 insertions(+)
> 
> diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
> index 07bf8bdebffb..0f9e32d2c648 100644
> --- a/gcc/doc/md.texi
> +++ b/gcc/doc/md.texi
> @@ -9362,6 +9362,14 @@ If the preparation falls through (invokes neither 
> @code{DONE} nor
> @code{FAIL}), then the @code{define_peephole2} uses the replacement
> template.
> 
> +Insns are scanned in forward order from beginning to end for each basic
> +block, but the basic blocks are scanned in reverse order of appearance
> +in a function.  After a successful replacement, scanning for further
> +opportunities for @code{define_peephole2} matches, resumes at the last
> +generated insn.  I.e. for the example above, the first insn that can be
> +matched by another @code{define_peephole2}, is @code{(set (match_dup 3)
> +(match_dup 4))}.
> +
> @end ifset
> @ifset INTERNALS
> @node Insn Attributes
> -- 
> 2.30.2
> 

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

[Paul Koning via Gcc]

> 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 "movmemhi" 'instruction' for
> ;; doing block moves, as in struct assignment.  This pattern wasn't
> ;; present, however.  I've added it, and it's companion function
> ;; pdp10_expand_movmemhi().
> 
> (define_expand "movmemhi"
>   [(match_operand:BLK 0 "general_operand" "=r")
>(match_operand:BLK 1 "general_operand" "=r")
>(match_operand:SI 2 "general_operand" "=r")
>(match_operand:SI 3 "const_int_operand" "")
>   ]...

I don't remember that far back, but looking at current examples (like vax.md) 
that seems like an odd pattern.  vax.md has a three operand pattern with the 
first two marked as "memory_operand" and only the first one has the = modifier 
on it showing it's an output operand.

What does the 4.3 version of gccint say about it?  Or the 4.3 version of vax.md?

paul

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

[Paul Koning via Gcc-patches]

> 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 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 know such 
>>>> potential impact.
>>> 
>>> With modern highly optimized languages, not knowing the standard is going 
>>> to get you in trouble.  There was a wonderful paper from MIT a few years 
>>> ago describing all the many ways C can bite you if you don't know the rules.
>> Yes, it’s better to know the details of languages standard. -:)
>> However, I don’t think that this is a realistic expectation to the compiler 
>> users:  to know all the details of a language standard.
> Umm, they really do need to know that stuff.
> 
> If the developer fails to understand the language standard, then they're 
> likely going to write code that is ultimately undefined or doesn't behave in 
> they expect.  How is the compiler supposed to guess what the developer 
> originally intended?  How should the compiler handle the case when two 
> developers have different understandings of how a particular piece of code 
> should work?  In the end it's the language standard that defines how all this 
> stuff should work.
> 
> Failure to understand the language is a common problem and we do try to emit 
> various diagnostics to help developers avoid writing non-conformant code.  
> But ultimately if a developer fails to understand the language standard, then 
> they're going to be surprised by the behavior of their code.

Conversely, of course, the problem is that C and other languages have evolved 
to the point that you have to be a language lawyer to write valid code.  In 
other words, a substantial fraction of programmers are by definition writing 
unreliable code.  This is not a good situation, and it may be part of the 
reason why modern software has such a high rate of defects.

paul

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

[Paul Koning via Gcc-patches]

> 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 know such potential 
> impact.

With modern highly optimized languages, not knowing the standard is going to 
get you in trouble.  There was a wonderful paper from MIT a few years ago 
describing all the many ways C can bite you if you don't know the rules.

paul

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

[Paul Koning via Gcc-patches]

> 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 expansion to start with a loop, so as to
>>> still take advantage of known alignment even with long lengths, but
>>> without necessarily adding store blocks for every power of two.
> 
>> I wonder if that isn't better handled by targets via the setmem pattern,
> 
> That was indeed where I started, but then I found myself duplicating the
> logic in try_store_by_multiple_pieces on a per-target basis.
> 
> Target-specific code is great for tight optimizations, but the main
> purpose of this feature is not an optimization.  AFAICT it actually
> slows things down in general (due to code growth, and to conservative
> assumptions about alignment), 

I thought machinery like the memcpy patterns have as one of their benefits the 
ability to find the alignment of their operands and from that optimize things.  
So I don't understand why you'd say "conservative".

paul

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

[Paul Koning via Gcc-patches]

> 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 your
>>> constraints do not?  (I don't know your target well, maybe this isn't
>>> true).  Things like this should be sorted out by reload, but you get
>>> better code (and fewer problems ;-) ) if you make code that fits
>>> earlier.  The L in LRA means "local": it "just" makes things fit, it
>>> does not emphasise optimising your code.
>> 
>> The destination is "nonimmediate_operand" which matches what the machine 
>> actually does.  It's like VAX and M68k, instruction operands in general can 
>> be registers, memory references, register indirect or memory indirect, 
>> memory at register with offset, or autoinc/autodec off any register.
>> 
>> As far as operand type is concerned, SP is certainly a valid operand for an 
>> add operation, that isn't the problem.  The problem is that it's a two 
>> operand machine: the first operand of the add instruction is both source and 
>> destination.  And LRA assigned the source register to be the destination 
>> register as required, but then after doing so it replaced the destination 
>> (an FP reference) by a different register (SP reference), violating the 
>> constraint after having satisfied it earlier.
> 
> Ah okay.  Yes, something does not verify if the instructions are valid
> before doing some replacement.  Something around ELIMINABLE_REGS it
> looks like?  Maybe the dump file says more, or maybe the dump file can
> be improved.

The Reload dump file mentions in a couple of places that it sees r5 (FP) as 
eliminable, replaced by r6 (SP).  The IRA dump file says nothing.

Yes, the ELIMINABLE_REGS macro says FP can be eliminated, which is correct.  In 
fact, if it weren't for that, it would be wrong for the register allocator to 
pick it (R5) as a general register to hold the result of that addhi3.  So the 
trouble is that the replacement is made after that register allocation, and 
given the constraint the allocator actually needs to generate an additional 
instruction, a move from SP to R5 so it can then do the two-operand add the 
constraint requires.

This feels like a bug; should I file a bug report?  Or is there something the 
target code can do to make this work?  I looked through the internals manual a 
bit, it doesn't show anything helpful.  The register elimination hooks are 
rather generic and don't give me any handle to recognize cases like this one.

paul

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

[Paul Koning via Gcc-patches]

> 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 (general_operand),
>>> but this needs more info.  A testcase to reproduce the problem, to
>>> start with :-)
>> 
>> I'll try to trim it down.
>> 
>> What do you mean "too lenient"?  The first input operand (which is supposed 
>> to be the same as the output since the instruction set is 2-address) is 
>> "general_operand".  The destination is "nonimmediate_operand" which fits the 
>> constraints applied to it.
> 
> I mean general_operand accepts that sp thing you saw.  But your
> constraints do not?  (I don't know your target well, maybe this isn't
> true).  Things like this should be sorted out by reload, but you get
> better code (and fewer problems ;-) ) if you make code that fits
> earlier.  The L in LRA means "local": it "just" makes things fit, it
> does not emphasise optimising your code.

The destination is "nonimmediate_operand" which matches what the machine 
actually does.  It's like VAX and M68k, instruction operands in general can be 
registers, memory references, register indirect or memory indirect, memory at 
register with offset, or autoinc/autodec off any register.

As far as operand type is concerned, SP is certainly a valid operand for an add 
operation, that isn't the problem.  The problem is that it's a two operand 
machine: the first operand of the add instruction is both source and 
destination.  And LRA assigned the source register to be the destination 
register as required, but then after doing so it replaced the destination (an 
FP reference) by a different register (SP reference), violating the constraint 
after having satisfied it earlier.

Interesting to know what LRA stands for, I didn't know that.

paul

Re: LRA produces RTL not meeting constraint

[Paul Koning via Gcc]

> 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 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"
>>> [(parallel [(set (match_dup 0)
>>>(plus:HI (match_dup 1) (match_dup 2)))
>>>   (clobber (reg:CC CC_REGNUM))])]
>>> ""
>>> [(set_attr "length" "2,4,4,6")])
>>> 
>>> While compiling libgcc2.c I see this RTL in the .ira dump file:
>>> 
>>> (insn 49 48 53 5 (set (reg/f:HI 136)
>>>   (plus:HI (reg/f:HI 5 r5)
>>>   (const_int -8 [0xfff8]))) 
>>> "../../../../../gcc/libgcc/libgcc2.c":276:4 68 {addhi3}
>>>(expr_list:REG_EQUIV (plus:HI (reg/f:HI 5 r5)
>>>   (const_int -8 [0xfff8]))
>>>   (nil)))
>> 
>> What hard register was assigned by IRA to r136?  It shows this in the
>> .ira dump file, search for "Disposition:".
> 
> Disposition:
>3:r25  l0   mem   40:r26  l0 4   51:r31  l0   mem   47:r35  l0   mem
>   42:r45  l0 2   18:r47  l0   mem   38:r52  l0   mem   34:r54  l0   mem
>   29:r64  l0 2   21:r80  l0 0   15:r88  l0 02:r99  l0 0
>   19:r102 l0   mem5:r103 l0   mem   31:r110 l0 0   44:r114 l0 0
>   41:r115 l0   mem   46:r116 l0 0   28:r117 l0   mem   33:r118 l0 0
>   20:r119 l0 2   14:r120 l0 21:r121 l0 20:r122 l0   mem
>9:r123 l0   mem8:r124 l0   mem   55:r125 l0 0   53:r126 l0   mem
>   54:r129 l0 0   52:r135 l0 0   49:r136 l0 5   48:r137 l0 4
>   50:r139 l0 0   45:r145 l0   mem   43:r146 l0 0   39:r147 l0 0
>   36:r148 l0 5   35:r149 l0 4   37:r151 l0 0   32:r157 l0   mem
>   30:r158 l0 0   27:r159 l0 0   25:r160 l0   mem   26:r161 l0 0
>   24:r164 l0 0   22:r165 l0   mem   23:r166 l0 0   16:r170 l0   mem
>   17:r171 l0 0   11:r175 l0 0   13:r176 l0 2   12:r177 l0 2
>   10:r178 l0 06:r179 l0   mem7:r180 l0 04:r184 l0 0
> 
> so R5, if I read that correctly.  Which makes sense given that the input 
> operand is R5.  
>> 
>>> Then in the .reload dump it appears this way:
>>> 
>>> (insn 49 48 53 5 (set (reg/f:HI 5 r5 [136])
>>>   (plus:HI (reg/f:HI 6 sp)
>>>   (const_int 40 [0x28]))) 
>>> "../../../../../gcc/libgcc/libgcc2.c":276:4 68 {addhi3}
>>>(expr_list:REG_EQUIV (plus:HI (reg/f:HI 5 r5)
>>>   (const_int -8 [0xfff8]))
>>>   (nil)))
>>> 
>>> which obviously causes an ICE because that RTL doesn't meet the constraints.
>> 
>> Before reload it did not have operands[0] and operands[1] the same,
>> already?
> 
> No, and given that it's an addhi3 pattern that is fine before reload.  It's 
> reload that has to make them match because the machine instruction is two 
> operand.

It occurs to me there's a strange transformation LRA made that I don't 
understand, which is the cause of the trouble.

Input:

(insn 49 48 53 5 (set (reg/f:HI 136)
(plus:HI (reg/f:HI 5 r5)
(const_int -8 [0xfff8]))) "_mulvdi3.i":38:4 68 {addhi3}
 (expr_list:REG_EQUIV (plus:HI (reg/f:HI 5 r5)
(const_int -8 [0xfff8]))
(nil)))
(insn 53 49 50 5 (set (reg/f:HI 137)
(symbol_ref:HI ("__muldi3") [flags 0x41]  )) "_mulvdi3.i":38:4 25 {movhi}
 (expr_list:REG_EQUIV (symbol_ref:HI ("__muldi3") [flags 0x41]  
)
(nil)))

and the IRA "disposition" says it assigned R5 for R136, which is what should 
happen given that operand 1 (in the plus:HI) is R5 and the constraint says that 
operands 0 and 1 should match.

However, Reload shows that it is given:

(insn 49 48 53 5 (set (reg/f:HI 5 r5 [136])
(plus:HI (reg/f:HI 6 sp)
(const_int 40 [0x28]))) "_mulvdi3.i":38:4 68 {addhi3}
 (expr_list:REG_EQUIV (plus:HI (reg/f:HI 5 r5)
(const_int -8 [0xfff8]))
(nil)))

In other words, R136 was replaced by R5 as expected -- but at the same time, 
the source operands were replaced by something entirely different.  It is a 
misguided attempt to eliminate the frame pointer?  R5 can be the frame pointer, 
if it is needed for that purpose.  And replacing an FP reference by an SP 
reference is reasonable enough, but such a substitution has to verify that the 
constraints are still satisfied.  Is that something the target code has to 
provide?  I'm not aware of it.

paul

Re: LRA produces RTL not meeting constraint

[Paul Koning via Gcc]

> 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 "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"
>>  [(parallel [(set (match_dup 0)
>> (plus:HI (match_dup 1) (match_dup 2)))
>>(clobber (reg:CC CC_REGNUM))])]
>>  ""
>>  [(set_attr "length" "2,4,4,6")])
>> 
>> While compiling libgcc2.c I see this RTL in the .ira dump file:
>> 
>> (insn 49 48 53 5 (set (reg/f:HI 136)
>>(plus:HI (reg/f:HI 5 r5)
>>(const_int -8 [0xfff8]))) 
>> "../../../../../gcc/libgcc/libgcc2.c":276:4 68 {addhi3}
>> (expr_list:REG_EQUIV (plus:HI (reg/f:HI 5 r5)
>>(const_int -8 [0xfff8]))
>>(nil)))
> 
> What hard register was assigned by IRA to r136?  It shows this in the
> .ira dump file, search for "Disposition:".

Disposition:
3:r25  l0   mem   40:r26  l0 4   51:r31  l0   mem   47:r35  l0   mem
   42:r45  l0 2   18:r47  l0   mem   38:r52  l0   mem   34:r54  l0   mem
   29:r64  l0 2   21:r80  l0 0   15:r88  l0 02:r99  l0 0
   19:r102 l0   mem5:r103 l0   mem   31:r110 l0 0   44:r114 l0 0
   41:r115 l0   mem   46:r116 l0 0   28:r117 l0   mem   33:r118 l0 0
   20:r119 l0 2   14:r120 l0 21:r121 l0 20:r122 l0   mem
9:r123 l0   mem8:r124 l0   mem   55:r125 l0 0   53:r126 l0   mem
   54:r129 l0 0   52:r135 l0 0   49:r136 l0 5   48:r137 l0 4
   50:r139 l0 0   45:r145 l0   mem   43:r146 l0 0   39:r147 l0 0
   36:r148 l0 5   35:r149 l0 4   37:r151 l0 0   32:r157 l0   mem
   30:r158 l0 0   27:r159 l0 0   25:r160 l0   mem   26:r161 l0 0
   24:r164 l0 0   22:r165 l0   mem   23:r166 l0 0   16:r170 l0   mem
   17:r171 l0 0   11:r175 l0 0   13:r176 l0 2   12:r177 l0 2
   10:r178 l0 06:r179 l0   mem7:r180 l0 04:r184 l0 0

so R5, if I read that correctly.  Which makes sense given that the input 
operand is R5.  
> 
>> Then in the .reload dump it appears this way:
>> 
>> (insn 49 48 53 5 (set (reg/f:HI 5 r5 [136])
>>(plus:HI (reg/f:HI 6 sp)
>>(const_int 40 [0x28]))) 
>> "../../../../../gcc/libgcc/libgcc2.c":276:4 68 {addhi3}
>> (expr_list:REG_EQUIV (plus:HI (reg/f:HI 5 r5)
>>(const_int -8 [0xfff8]))
>>(nil)))
>> 
>> which obviously causes an ICE because that RTL doesn't meet the constraints.
> 
> Before reload it did not have operands[0] and operands[1] the same,
> already?

No, and given that it's an addhi3 pattern that is fine before reload.  It's 
reload that has to make them match because the machine instruction is two 
operand.

>> This happens only when LRA is used.
>> 
>> I also see this in the .reload file, but I don't know what it means:
>> 
>>   Choosing alt 1 in insn 49:  (0) rR  (1) 0  (2) Qi {addhi3}
> 
> It chose alternative 1 in this instruction, which uses constraints rR
> for operands[0], a tie to that for operands[1], and Qi for operands[2].
> 
>>1 Non-pseudo reload: reject+=2
>>1 Non input pseudo reload: reject++
>>Cycle danger: overall += LRA_MAX_REJECT
>>  alt=0,overall=609,losers=1,rld_nregs=2
>>alt=1: Bad operand -- refuse
>>alt=2: Bad operand -- refuse
>>  alt=3,overall=0,losers=0,rld_nregs=0
> 
> This is for the *next* instruction.  There is a "Choosing alt" thing
> for that right after this.  That will be alt 3: 1 and 2 are refused,
> 0 costs 609, 3 costs 0.
> 
> Reading the LRA dumps needs some getting used to ;-)

Indeed.  So does that mean the discussion about insn 48 is the interesting one? 
 That goes on for a while:

 Choosing alt 0 in insn 48:  (0) =rR  (1) RN {movhi}
1 Spill Non-pseudo into memory: reject+=3
Using memory insn operand 1: reject+=3
1 Non input pseudo reload: reject++
  alt=0,overall=13,losers=1,rld_nregs=0
0 Spill pseudo into memory: reject+=3
Using memory insn operand 0: reject+=3
0 Non input pseudo reload: reject++
1 Non-pseudo reloa

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

[Paul Koning via Gcc-patches]

> 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 GCC list about what I saw, 
>> but have received no reaction.
> 
> <https://gcc.gnu.org/pipermail/gcc/2023-January/240497.html>?

I just saw that, thanks!

> I would say your predicates are way too lenient here (general_operand),
> but this needs more info.  A testcase to reproduce the problem, to
> start with :-)

I'll try to trim it down.

What do you mean "too lenient"?  The first input operand (which is supposed to 
be the same as the output since the instruction set is 2-address) is 
"general_operand".  The destination is "nonimmediate_operand" which fits the 
constraints applied to it.

paul

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

[Paul Koning via Gcc-patches]

> 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.
>>> 
>>> And users will notice some ports will have to be removed, because those
>>> ports are not maintained / not maintained enough.  Some ports will not
>>> work with LRA, most will be easy to fix, but someone will have to do
>>> that.  If no one does so the port works sufficiently well it will have
>>> to be removed before release.
>>> 
 "In a future release" is also quite vague.
>>> 
>>> It's what we usually say in changes.html .  "In GCC 14" if you want?
>>> 
>>> I can add some stuff on how this will benefit users?
>> 
>> I guess listing the ports without LRA support might be a first step for 
>> clarification?
> 
> Every port has LRA support.
> 
> Some ports will not build later when we delete old reload, because they
> use some functions and/or data structures unique to that.

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 GCC list about what I saw, but 
have received no reaction.

If anyone can help me understand how LRA can generate RTL with register choices 
that violate the constraints listed in the MD file, I would be grateful.

paul

LRA produces RTL not meeting constraint

[Paul Koning via Gcc]

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"
  [(parallel [(set (match_dup 0)
   (plus:HI (match_dup 1) (match_dup 2)))
  (clobber (reg:CC CC_REGNUM))])]
  ""
  [(set_attr "length" "2,4,4,6")])

While compiling libgcc2.c I see this RTL in the .ira dump file:

(insn 49 48 53 5 (set (reg/f:HI 136)
(plus:HI (reg/f:HI 5 r5)
(const_int -8 [0xfff8]))) 
"../../../../../gcc/libgcc/libgcc2.c":276:4 68 {addhi3}
 (expr_list:REG_EQUIV (plus:HI (reg/f:HI 5 r5)
(const_int -8 [0xfff8]))
(nil)))

Then in the .reload dump it appears this way:

(insn 49 48 53 5 (set (reg/f:HI 5 r5 [136])
(plus:HI (reg/f:HI 6 sp)
(const_int 40 [0x28]))) "../../../../../gcc/libgcc/libgcc2.c":276:4 
68 {addhi3}
 (expr_list:REG_EQUIV (plus:HI (reg/f:HI 5 r5)
(const_int -8 [0xfff8]))
(nil)))

which obviously causes an ICE because that RTL doesn't meet the constraints.  
This happens only when LRA is used.

I also see this in the .reload file, but I don't know what it means:

 Choosing alt 1 in insn 49:  (0) rR  (1) 0  (2) Qi {addhi3}
1 Non-pseudo reload: reject+=2
1 Non input pseudo reload: reject++
Cycle danger: overall += LRA_MAX_REJECT
  alt=0,overall=609,losers=1,rld_nregs=2
alt=1: Bad operand -- refuse
alt=2: Bad operand -- refuse
  alt=3,overall=0,losers=0,rld_nregs=0

Any ideas?  I ran into this when trying to make LRA the default for this target.

paul

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

[Paul Koning via Gcc]

> 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
>> that primitive.  And I'm pretty sure I saw it work before I committed
>> that change.  That's why I'm wondering if something changed.
> 
> I can't tell from the past how GCC once worked, but today it can't
> (or doesn't) use such patterns, at least not on i386/AMD64 processors.

It turns out I was confused by the RTL generated by my pattern.  That pattern 
is for divmodhi, so it works as desired given same-size inputs.  

I'm wondering if the case of longer dividend -- which is a common thing for 
several machines -- could be handled by a define_peephole2 that matches the 
sign-extend of the divisor followed by the (longer) divide.  I made a stab at 
that but what I wrote wasn't valid.

So, question to the list:  suppose I want to write RTL that matches what Stefan 
is talking about, with a div or mod or divmod that has si results and a di 
dividend (or hi results and an si dividend), how would you do that?  Can a 
define_peephole2 do it, and if so, what would it look like?

paul

struct vs. class in GCC source

[Paul Koning via Gcc]

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++ says struct and class mean the 
same thing other than the default access).  Still, I wonder if it would be 
worth changing the code to use just one of "struct" or "class" for any given 
type.  (And then the convention would presumably be that a POD type is called 
"struct" and other types are "class".)

paul

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

[Paul Koning via Gcc]

> 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 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 in pdp11.md:
> [...]
>> and I'm pretty sure this worked at some point in the past.  
> 
> Unfortunately the C standard defines that the smaller operand (of lesser
> conversion rank), here divisor, has to undergo a conversion to the "real
> common type", i.e. the broader operand (of higher conversion rank), here
> dividend. Unless the information about promotion/conversion is handed over
> to the code generator it can't apply such patterns -- as demonstrated by
> the demo code.
> 
> regards
> Stefan

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 that 
primitive.  And I'm pretty sure I saw it work before I committed that change.  
That's why I'm wondering if something changed.

paul

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

[Paul Koning via Gcc]

> 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 in pdp11.md:

(define_expand "divmodhi4"
  [(parallel
[(set (subreg:HI (match_dup 1) 0)
(div:HI (match_operand:SI 1 "register_operand" "0")
(match_operand:HI 2 "general_operand" "g")))
 (set (subreg:HI (match_dup 1) 2)
(mod:HI (match_dup 1) (match_dup 2)))])
   (set (match_operand:HI 0 "register_operand" "=r")
(subreg:HI (match_dup 1) 0))
   (set (match_operand:HI 3 "register_operand" "=r")
(subreg:HI (match_dup 1) 2))]
  "TARGET_40_PLUS"
  "")

and I'm pretty sure this worked at some point in the past.  

paul

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

[Paul Koning via Gcc-patches]

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
> 
> ---
> htdocs/gcc-13/changes.html | 2 ++
> 1 file changed, 2 insertions(+)
> 
> diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html
> index 3876ad77543a..954469cdcfa4 100644
> --- a/htdocs/gcc-13/changes.html
> +++ b/htdocs/gcc-13/changes.html
> @@ -39,6 +39,8 @@ a work-in-progress.
> Legacy debug info compression option -gz=zlib-gnu was 
> removed
>   and the option is ignored right now.
> New debug info compression option value -gz=zstd has 
> been added.
> +Support for old reload is deprecated. It will be removed in a future
> +  release. Every target will always use LRA from then on.
> 
> 
> 
> -- 
> 1.8.3.1
> 

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

[Paul Koning via Gcc]

> 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 gcc, as I would expect:
> 
>$ gcc -Wall -Wextra buf.c -O0
> 
> Clang does warn, however:
> 
>$ clang -Weverything -Wall -Wextra buf.c -O0
>buf.c:8:17: warning: format specifies type 'void *' but the argument has 
> type 'char *' [-Wformat-pedantic]
>printf("%p\n", p);
>~~ ^
>%s
>buf.c:7:6: warning: the pointer incremented by 6 refers past the end of 
> the array (that contains 5 elements) [-Warray-bounds-pointer-arithmetic]
>p = buf + 6;
>^ ~

I thought void * is a generic pointer that accepts any pointer argument.  So a 
warning about char* being passed in seems to be flat out wrong.

>buf.c:5:2: note: array 'buf' declared here
>char *p, buf[5];
>^
>2 warnings generated.

That was discussed just days ago: C says that a pointer one past the end of the 
array is legal.  So here too it looks like Clang is wrong and GCC is right.

paul

Re: Good grief Charlie Brown

[Paul Koning via Gcc]

> 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 would you like to see?

I see some vague hints that there are some issues.  If you want those to be 
addressed, you should report them as defects through the bug tracker.  To do 
so, you should be specific as to what's failing so others can reproduce what 
you did and see what goes wrong.

Apart from that, generic "I don't like what you guys did" is obviously just 
going to get ignored as meaningless ravings.

paul

Re: Can't build Ada

[Paul Koning via Gcc]

> 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 is not working, then perhaps a PR is in order.
>> 
>> I will do that, if the "shell in Rosetta" thing doesn't cure the problem.
> 
> You won’t need to, the version of gnat you are using is recent enough, you 
> need to follow Ian’s instructions to the letter. The Ada 2022 code is a red 
> herring and is only problematic when you build a cross with a non matching 
> native, not when building a native compiler.
> 
> Arno

All I can tell you is that I'm pretty sure I'm doing what Iain said, using his 
branch (up to date), and using the compilers from the Adacore open source 
release (20200818) which is GCC 8.4.1.  And once again I got that same 
complaint about Ada2020 constructs:

/usr/local/gnat/bin/gcc -c -g -O2  -gnatpg -gnata -W -Wall -nostdinc -I- 
-I. -Iada/generated -Iada -I../../../gcc-darwin/gcc/ada -Iada/libgnat 
-I../../../gcc-darwin/gcc/ada/libgnat -Iada/gcc-interface 
-I../../../gcc-darwin/gcc/ada/gcc-interface 
../../../gcc-darwin/gcc/ada/contracts.adb -o ada/contracts.o
s-imagei.ads:95:11: declare_expression is an Ada 2020 feature
s-valueu.ads:152:09: declare_expression is an Ada 2020 feature
s-valueu.ads:160:09: declare_expression is an Ada 2020 feature
s-valueu.ads:184:06: "Subprogram_Variant" is not a valid aspect identifier
s-valuei.ads:80:11: declare_expression is an Ada 2020 feature
s-valuei.ads:95:08: declare_expression is an Ada 2020 feature
s-valuei.ads:141:06: "Subprogram_Variant" is not a valid aspect identifier
s-widthu.ads:84:09: declare_expression is an Ada 2020 feature
s-widthu.ads:93:11: run-time library configuration error
s-widthu.ads:93:11: file s-imgint.ads had parser errors
s-widthu.ads:93:11: entity "System.Img_Int.Image_Integer" not available
compilation abandoned
make[2]: *** [ada/contracts.o] Error 1

paul

Re: Can't build Ada

[Paul Koning via Gcc]

> 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 compiler 
 (GCC version 5.1 or later).
 
 so, if 5.1 is not working, then perhaps a PR is in order.
>>> 
>>> I will do that, if the "shell in Rosetta" thing doesn't cure the problem.
>> 
>> You won’t need to, the version of gnat you are using is recent enough, you 
>> need to follow Ian’s instructions to the letter. The Ada 2022 code is a red 
>> herring and is only problematic when you build a cross with a non matching 
>> native, not when building a native compiler.
> 
> One additional question/point - which branch are you trying to build the 
> cross from?
> 
> I am sure it will not work from upstream master.
> 
> Unfortunately, owing to lack of free time… aarch64-darwin is not yet 
> completely ready to upstream, so folks are using the development branch here: 
> https://github.com/iains/gcc-darwin-arm64 (which I will update later, based 
> on the master version mentioned earlier; if testing goes OK).
> 
> Iain.

That's the branch I'm using.

paul

Re: Can't build Ada

[Paul Koning via Gcc]

> 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 
documentation mentions it.  The actual bootstrap compiler is 8.4.1:

pkoning:gcc-darwin-x86 pkoning$ /usr/local/gnat/bin/gcc --version
gcc (GCC) 8.4.1 20200430 (for GNAT Community 2020 20200818)

> You might find problems unless you actually start a Rosetta 2 shell - so 
> “ arch -x86_64 bash “ 
> and then go from there (this seems to ensure that sub-processes are started 
> as x86_64)
> 
> (with this, bootstrap succeeded for both x86_64 Rosetta 2  and rebased Arm64 
> branch native - r13-4309-g309e2d95e3b9)
> 
> I will push the rebased arm64 branch when testing is done.
> 
>> So I'm guessing I'll have to do this in two parts, first build a newer but 
>> not-latest Gnat from a release that doesn't include the problematic 
>> constructs, then follow that by using the intermediate to build the current 
>> sources.
>> 
>> I wonder if this incompatibility was intentional.  If not it would be good 
>> for the Ada maintainers to fix these and ensure that the current code can 
>> still be built with the most recent public release of Gnat.  Conversely, if 
>> it is intentional, the documentation should be updated to explain how to 
>> build the current code.
> 
> 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 is not working, then perhaps a PR is in order.

I will do that, if the "shell in Rosetta" thing doesn't cure the problem.

paul

Re: GNU = Junkware

[Paul Koning via Gcc]

> 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 
technical mailing list.  Especially since you have never contributed anything 
to GCC.

Please stop.  And to the list overseers: if it doesn't stop, please apply a 
suitable blacklist.

paul

Re: Can't build Ada

[Paul Koning via Gcc]

> 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  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) release of Gnat 
>>>>> from Adacore.
>>>> 
>>>> Are you building a cross compiler or a native compiler?
>>>> If you are building a cross, you need to bootstrap a native compiler first.
>>> 
>>> I'm not sure.  The installed Gnat is x86_64-darwin; I want to build 
>>> aarch64-darwin.
>> 
>> You have to build a x86_64-darwin compiler first with the same sources
>> as you are building for aarch64-darwin.
> 
> So .. 
> 1/ if you are on arm64 Darwin, 
>  - the first step is to bootstrap the compiler using Rosetta 2 and the 
> available x86_64 gnat.
> 
> 2/ if you are on x86_64 Darwin…
>  - the first step is to bootstrap the compiler using the available x86-64 
> gnat.

Thanks all.

I tried that (#1) and got the same failure.  The trouble seems to be that the 
current sources have Ada2020 constructs in them and the available Gnat doesn't 
support that version.  The commit that introduces these (or some of them at 
least) is 91d68769419b from Feb 4, 2022.

So I'm guessing I'll have to do this in two parts, first build a newer but 
not-latest Gnat from a release that doesn't include the problematic constructs, 
then follow that by using the intermediate to build the current sources.

I wonder if this incompatibility was intentional.  If not it would be good for 
the Ada maintainers to fix these and ensure that the current code can still be 
built with the most recent public release of Gnat.  Conversely, if it is 
intentional, the documentation should be updated to explain how to build the 
current code.

paul

Re: Can't build Ada

[Paul Koning via Gcc]

> 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) release of Gnat from 
>> Adacore.
> 
> Are you building a cross compiler or a native compiler?
> If you are building a cross, you need to bootstrap a native compiler first.

I'm not sure.  The installed Gnat is x86_64-darwin; I want to build 
aarch64-darwin.

But in any case, how does that relate to the error messages I got?  They don't 
seem to have anything to do with missing compilers, but rather with the use of 
language features too new for the available (downloadable) Gnat.

paul

Can't build Ada

[Paul Koning via Gcc]

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 used instead.  Once 
I fix that, I get a pile of messages I don't know what to do about:

s-imagei.ads:95:11: declare_expression is an Ada 2020 feature
s-valueu.ads:152:09: declare_expression is an Ada 2020 feature
s-valueu.ads:160:09: declare_expression is an Ada 2020 feature
s-valueu.ads:184:06: "Subprogram_Variant" is not a valid aspect identifier
s-valuei.ads:80:11: declare_expression is an Ada 2020 feature
s-valuei.ads:95:08: declare_expression is an Ada 2020 feature
s-valuei.ads:141:06: "Subprogram_Variant" is not a valid aspect identifier
s-widthu.ads:84:09: declare_expression is an Ada 2020 feature
s-widthu.ads:93:11: run-time library configuration error
s-widthu.ads:93:11: file s-imgint.ads had parser errors
s-widthu.ads:93:11: entity "System.Img_Int.Image_Integer" not available
compilation abandoned
make[2]: *** [ada/contracts.o] Error 1

Given that the current open source Gnat is from 2020, so (apparently) it 
doesn't support Ada 2020 features, how is someone supposed to build the current 
GCC?  I looked in the prerequisites listing on the webpage, but it says that 
the Gnat that is built on GCC 5.1 is sufficient.  That seems to be wrong; the 
GCC in Gnat 2020 is 8.4.1 and it is apparently too old to work.

paul

Re: clarification question

[Paul Koning via Gcc]

> 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.
> 
> If you look at the examples below, there is a C for riscv, which has 0, and 
> one for sparc, which has several.

Also pdp11, which has two: one for floating point, one for integers, and 
conditional branches act only on the integer CC register.  So the MD has to 
describe a "move float CC to integer CC" operation.

GCC supports all these strange things quite nicely -- this is one of several 
things that the newer CCmode machinery does well and the old "cc0" stuff 
doesn't.

paul

Re: Possible C++ method signature warning feature?

[Paul Koning via Gcc]

> 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 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 myself changing the argument list of some of these methods, so I 
>> have to change the base class definitions and also track down all the 
>> subclass redefinitions.  If I miss one of the latter, that subclass method 
>> is no longer called (it now just looks like an unrelated method with a 
>> different argument list that isn't used anywhere).  Finding these things can 
>> be hard and time consuming.
>> 
>> It would be helpful to have some way to mark a method as "this is supposed 
>> to be an override of a base class method", in other words "warn me if this 
>> method doesn't override some method in a base class".
> 
> C++11's overload keyword sounds exactly what you want.
> https://en.cppreference.com/w/cpp/language/override

Perfect!  Thanks much.

paul

Possible C++ method signature warning feature?

[Paul Koning via Gcc]

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 myself changing the argument list of some of these methods, so I 
have to change the base class definitions and also track down all the subclass 
redefinitions.  If I miss one of the latter, that subclass method is no longer 
called (it now just looks like an unrelated method with a different argument 
list that isn't used anywhere).  Finding these things can be hard and time 
consuming.

It would be helpful to have some way to mark a method as "this is supposed to 
be an override of a base class method", in other words "warn me if this method 
doesn't override some method in a base class".

Does that sound like a possible thing to do, perhaps with some __attribute__ 
magic?  Would it be interesting?

paul

Re: Signed vs. unsigned compares

[Paul Koning via Gcc]

> 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 
>> the compare operation applies to either.  How can I do this in the target 
>> code?
> 
> There are both signed and unsigned comparison operations, eg. GE
> vs. GEU.
> 
> -- 
> Andreas Schwab, sch...@linux-m68k.org

It looks like what I need is to define additional CCmodes, to describe "cc mode 
valid for unsigned comparison" vs. "cc mode valid for signed comparison".  
Right now I don't make that distinction and that reportedly can produce bad 
code errors.

paul

Signed vs. unsigned compares

[Paul Koning via Gcc]

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

[Paul Koning via Gcc]

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 switch statement with cases 
for each of the opcode values.  All but one are small integers assigned in 
sequence, but one is 10044.  So the "sparse" case kicks in and a compare tree 
is generated for everything.

I can avoid this by putting in special case code for the 10044 case, then all 
the rest ends up being a jump table.  That brings up the question if GCC should 
recognize such scenarios and break up the switch statement into "dense parts" 
handled by a jump table, leaving the sorting between those as a compare tree.

paul

Re: Benchmark recommendations needed

[Paul Koning via Gcc]

> 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 state of the art compiler technology. If you have
> a new processor I'd benchmark it using the applications you built it
> for.

Exactly.  Part of what you want to see is that GCC optimizes well for the new 
machine, i.e., that there aren't artifacts of the machine description that get 
in the way of optimization.

So you'd want to use applications that are good exercises not just of the code 
generator but also the optimizer.  Dhrystone isn't really that, because it has 
evolved into mostly an optimizer test, not a machine or code generator test.

paul

Re: reordering of trapping operations and volatile

[Paul Koning via Gcc]

> 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,
>>> because we don't have any other terms than observable or
>>> undefined.  As aluded to later you would have to
>>> introduce a new concept, something pseudo-observable,
>>> which you then started doing.  So, see below.
>> I find it really hard to view this notion of doing work for UB with any 
>> favor.  The way I see it is that a program having UB is synonymous with 
>> "defective program" and for the compiler to do extra work for these doesn't 
>> make much sense to me.
> 
> This is also the official position of the C committee on record,
> but it's one that's now being challenged.
> 
>> If the issue is specifically the handling of overflow traps, perhaps a 
>> better answer would be to argue for language changes that manage such events 
>> explicitly rather than having them be undefined behavior.  Another (similar) 
>> option might be to choose a language in which this is done.  (Is Ada such a 
>> language?  I don't remember.)
> 
> A change to the language standard is only feasible if it doesn't
> overly constrain existing implementations. 

I was thinking that if a new feature is involved, rather than a new definition 
of behavior for existing code, it wouldn't be a constraint on existing 
implementations (in the sense of "what the compiler does for existing code 
written to the current rules").  In other words, suppose there was a concept of 
"trapping operations" that could be enabled by some new mechanism in the 
program text.  If you use that, then you're asking the compiler to do more work 
and your code may get slower or bigger.  But if you don't, the existing rules 
apply and nothing bad happens (other than that the compiler is somewhat larger 
and more complex due to the support for both cases).

paul

Re: reordering of trapping operations and volatile

[Paul Koning via Gcc]

> 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 an alternative could be to remove volatile
 from the observable behavior in the standard
 or make it implementation-defined whether it
 is observable or not.
>>> 
>>> But you are actually arguing for making UB be observable
>> 
>> No, I am arguing for UB not to have the power
>> to go back in time and change previous defined
>> observable behavior.
> 
> But right now that's equivalent to making it observable,
> because we don't have any other terms than observable or
> undefined.  As aluded to later you would have to
> introduce a new concept, something pseudo-observable,
> which you then started doing.  So, see below.

I find it really hard to view this notion of doing work for UB with any favor.  
The way I see it is that a program having UB is synonymous with "defective 
program" and for the compiler to do extra work for these doesn't make much 
sense to me.

If the issue is specifically the handling of overflow traps, perhaps a better 
answer would be to argue for language changes that manage such events 
explicitly rather than having them be undefined behavior.  Another (similar) 
option might be to choose a language in which this is done.  (Is Ada such a 
language?  I don't remember.)

paul

Re: Help with an ABI peculiarity

[Paul Koning via Gcc]

> 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 signedness) to SI.  This applies when the 
> function parm is named only.
> 
> When the same argument would be placed on the stack (i.e. we ran out of 
> registers) - it occupies its natural size, and is naturally aligned (so, for 
> instance, 3 QI values could be passed as 3 registers - promoted to SI .. or 
> packed into three adjacent bytes on the stack)..
> 
> The key is that we need to know that the argument will be placed in a 
> register before we decide whether to promote it.
> (similarly, the promotion is not done in the callee for the in-register case).
> 
> I am trying to figure out where to implement this.

I don't remember the MIPS machinery well enough, but is that a similar case?  
It too has register arguments (4 or 8 of them) along with stack arguments (for 
the rest).

paul

Re: __builtin_addc support??

[Paul Koning via Gcc]

> 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 __builtin_addc __builtin_subc for all targets. Can 
> we provide something similar? Since currently no solutions we can access 
> carry flag besides x86

Certainly some other targets could do this.  The LLVM builtins explicitly 
expose carry, which isn't actually what you want (you'd want the carry flag in 
the condition code to be propagated).  Presumably optimization would eliminate 
those explicit arguments and reduce them to CC references.

paul

Re: Developer branches

[Paul Koning via Gcc]

> 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.gnu.org/git.html ?  I 
>> notice it mentioned a whole pile of them, most of which don't seem to 
>> exist.
> 
> A devel/ branch (one in refs/heads/devel/) is a shared development branch, 
> which may be created by anyone with write access (who can decide how it 
> will work in terms of patch approvals etc.), should be documented in 
> git.html, and will not accept non-fast-forward pushes or branch deletion.
> 
> A user branch (in refs/users//heads/) is a personal development 
> branch, which may be created by that user (sourceware username), may not 
> necessarily be documented in git.html, and can have non-fast-forward 
> pushes or branch deletion (it's up to that user to decide the rules for 
> that branch, including for non-fast-forward pushes).  Likewise a vendor 
> branch (in refs/vendors//heads/).
> 
> All branches are subject to the same legal requirements (copyright 
> assignment or DCO for code committed there).
> ...

Thanks, that's useful.  Suppose I want to collaborate with one other person 
(for now) on pdp11 target work, does it make sense to keep that in a user 
branch since the community is so small and isolated?  I assume the other person 
would need (as a minimum) write-after-approval privs.  

paul

Re: Developer branches

[Paul Koning via Gcc]

> 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 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.
> 
> Which ones? All the one I looked for exist.

Perhaps I did the procedures wrong.  I did a git pull, then git branch -a 
|fgrep devel.  I see 24 entries.  Looking at the git.html page, that mentions a 
lot more.  Some examples that do exist: modula-2, ira-select.  Some that don't: 
the ave* branches, x86, var-template.

paul

Developer branches

[Paul Koning via Gcc]

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 is used, but not 
clearly documented on the web pages.

paul

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

[Paul Koning via Gcc]

> 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 automatically look for those commands in the --prefix directory
> that you configure GCC with? Or is that only for native compilers?

It does.  That's how I configure my cross-builds.

paul

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

[Paul Koning via Gcc]

> 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 some other way that a class can be thought to be virtual,
> stealthily (say by its usage in some other class or something)?

I may be remembering wrong, but -- doesn't dynamic_cast look for a vtable?  So 
if you do a dynamic cast mentioning that class you'd get such a reference.  Or 
is that an error when applied to a non-polymorphic class?

paul

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

[Paul Koning via Gcc]

> 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 cmdlen, char *response, int *rlen)
> {
>register unsigned long reg2 asm ("2") = (addr_t) cpcmd_buf;
>register unsigned long reg3 asm ("3") = (addr_t) response;
>register unsigned long reg4 asm ("4") = cmdlen | 0x4000L;
>register unsigned long reg5 asm ("5") = *rlen; /* <-- */
>asm volatile(
>"   diag%2,%0,0x8\n"
>"   brc 8,1f\n"
>"   agr %1,%4\n"
>"1:\n"
>: "+d" (reg4), "+d" (reg5)
>: "d" (reg2), "d" (reg3), "d" (*rlen): "cc");
>*rlen = reg5;
>return reg4;
> }
> 
> into this:
> 
> int diag8_response(int cmdlen, char *response, int *rlen)
> {
>unsigned long len = cmdlen | 0x4000L;
> 
>asm volatile(
>"   diag%2,%0,0x8\n"
>"   brc 8,1f\n"
>"   agr %1,%4\n"
>"1:\n"
>: "+{r4}" (len), "+{r5}" (*rlen)
>: "{r2}" ((addr_t)cpcmd_buf), "{r3}" ((addr_t)response), "d" 
> (*rlen): "cc");
>return len;
> }
> 
> Apart from being much easier to read because the hard regs become part
> of the inline assembly it solves also a couple of other issues:
> 
> - function calls might clobber register asm variables see BZ100908
> - the constraints for the register asm operands are superfluous
> - one register asm variable cannot be used for 2 different inline
>  assemblies if the value is expected in different hard regs
> 
> I've started with a hackish implementation for IBM Z using the
> TARGET_MD_ASM_ADJUST hook and let all the places parsing constraints
> skip over the {} parts.  But perhaps it would be useful to make this a
> generic mechanism for all targets?!
> 
> Andreas

Yes, I would think this should be made a general mechanism that any target 
could use.

I wonder if instead of creating a new mechanism you could do this simply by 
creating new constraint names, where each name matches exactly one hard 
register.  That's roughly what this amounts to, isn't it? 

paul

Re: Update to GCC copyright assignment policy

[Paul Koning via Gcc]

> 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 Authors" should not 
> include a date - that's following the recommendations at 
> https://www.linuxfoundation.org/en/blog/copyright-notices-in-open-source-software-projects/
>  
> for the form of copyright notices in projects with many copyright holders.
> 
> -- 
> Joseph S. Myers
> jos...@codesourcery.com

That's a nice document, but it makes clear that a collective designation of a 
group of authors in a copyright notice is just a convenient shorthand.  It 
mentions that the copyright notice is just a notice that doesn't actually 
affect the copyright (which remains with the individual authors or their 
employers, unless assigned).  So "GNU Toolchain Authors" is a description 
referring to a set of individual owners, one that changes over time.  It 
doesn't describe a legal body, and it isn't an owner of anything.

paul

Re: Update to GCC copyright assignment policy

[Paul Koning via Gcc]

> 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 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 one, but is it?  Or is it just a label for 
>> "the set of contributors who have contributed without assigning to FSF"?  In 
>> other words, who is the owner of such a work, the GTA, or the submitter?  
>> I'm guessing the latter.
>> 
>> That seems to create a possible future complication.  Prior to this change, 
>> the FSF (as owner of the copyright) could make changes such as replacing the 
>> GPL 2 license by GPL 3.  With the policy change, that would no longer be 
>> possible, unless you get the approval of all the copyright holders.  This 
>> may not be considered a problem, but it does seem like a change.
>> 
>> I looked at gcc.gnu.org to find the updated policy.  I don't think it's 
>> there; the "contribute" page wording still feels like the old policy.  Given 
>> the change, it would seem rather important to have the implications spelled 
>> out in full, and the new rules clearly expressed.
> 
> The GNU Toolchain Authors are all of the authors, including those with
> FSF Copyright.  All of the authors agree to the existing license,
> which is "...either version 3, or (at your option) any later version."
> If the project chooses to adopt a future update to the GPL, all of
> the authors have given permission through the existing copyright
> assignment or through certification of the DCO to utilize the newer
> license.
> 
> Thanks, David

By DCO do you mean the document you linked in your original annoucement?  If 
yes, could you point out which of the words in that document give the GCC 
project permission from the copyright holder to relicense the contributed work? 
 I do not see those words in the document you linked.

I get the feeling that the current change was rushed and not well considered.  
It certainly has that feel.  I do not remember discussion of it, I do not see 
updated policy documents on the gcc.gnu.org website.  The discussion just now 
is raising a pile of questions which are being answered with a whole bunch of 
different answers, not all consistent with each other.  If the change had been 
carefully made this would not be happening; there would instead be a known 
answer (the outcome of prior discussion) and there would be published policies 
that could be pointed to where those answers are explicitly stated.

It's not that I object to the spirit of the change, and I have contributed to a 
number of open source projects where there is no copyright assignment so that 
isn't a strange thing to me.  What concerns me is a disruptive change made with 
what seems to me to be inadequate care.

paul

Re: Update to GCC copyright assignment policy

[Paul Koning via Gcc]

> 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 rest of Mark's message.
>> 
>> (Note: I haven't contributed to GCC but I have contributed to other
>> copylefted code bases.)
>> 
>> It is important that the pool be trustable.  A tall order, but
>> solvable, I think.
>> 
>> Two pools (FSF for old stuff, something else, for new stuff if the
>> contributor prefers) should be quite managable.
>> 
>> This would allow, for example, moving to an updated copyleft if the
>> two pools agreed.  It is important that the governance of the pool be
>> trustable.
>> 
>> We've trusted the FSF and now some have qualms.  A second pool would
>> be a check on the power of the first pool.
>> 
>> Individual unassigned copyright pretty much guarantees that the
>> copyright terms can never be changed.  I don't think that that is
>> optimal.
>> 
> 
> GCC's license is "GPL version 3 or later", so if there ever needed to be a
> GPL v4, we could move to it without needing permission from anyone.

I don't think that is what the license says.  It says:

GCC is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 3, or (at your option)
any later version.

To me that means the recipient of the software can relicense it under a later 
license.  It doesn't say to me that the original distribution can do so.

paul

Re: Update to GCC copyright assignment policy

[Paul Koning via Gcc]

> 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 one, but is it?  Or is it just a label for "the set of 
contributors who have contributed without assigning to FSF"?  In other words, 
who is the owner of such a work, the GTA, or the submitter?  I'm guessing the 
latter.

That seems to create a possible future complication.  Prior to this change, the 
FSF (as owner of the copyright) could make changes such as replacing the GPL 2 
license by GPL 3.  With the policy change, that would no longer be possible, 
unless you get the approval of all the copyright holders.  This may not be 
considered a problem, but it does seem like a change.

I looked at gcc.gnu.org to find the updated policy.  I don't think it's there; 
the "contribute" page wording still feels like the old policy.  Given the 
change, it would seem rather important to have the implications spelled out in 
full, and the new rules clearly expressed.

paul

Re: [PATCH 3/3] Use startswith in targets.

[Paul Koning via Gcc-patches]

> On Mar 19, 2021, at 5:21 AM, Martin Liska  wrote:
> 
> 
> gcc/ChangeLog:
> 
>   ...
>   * config/pdp11/pdp11.c (pdp11_output_ident): Likewise.

pdp11 is ok.  Thanks.

paul

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

[Paul Koning via Gcc]

> 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 a cashier or field
> laborer or in some other poorly paid job, then your employer probably
> doesn't care. Otherwise, if you work for a company that produces
> software, even just internally, or for a university, or a company
> where your name might be associated with the company, then your
> employer may demand that you cease publicly working on Free Software.

Not necessarily.

I'll offer you my own example.  I'm the target maintainer for pdp11.  It should 
be obvious that I'm doing this as an "independent contributor", not as part of 
my job, and indeed that work is for that reason spare time work done outside of 
business hours.

I have a company copyright disclaimer in place, dating back to some years ago 
when the work I was doing on gcc did at times touch on (then) company business. 
 As a legal matter it is doubtful that my current GCC involvement even needs 
that copyright disclaimer since the work is not on company time and not in the 
company's field of enterprise.

In other words, we have jobs (unless we're retired or unemployed) as well as 
private time, and there are a number of GCC contributors who contribute their 
private time.  I take Giacomo's comment to refer to that case.

paul

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

[Paul Koning via Gcc]

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

My impression is a variation on this: that LLVM is in substantial part 
motivated by a desire to avoid GPL V3.  And that there wasn't such a push when 
GPL V2 was the version in general use.

paul

Re: removing toxic emailers

[Paul Koning via Gcc]

> 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 distribute it themselves or encourage other people to
>> distribute
>> it for them, we did not criticise them for not being non-profit virtuous
>> enough, or said "we are suspicious of you", let alone threatening them.
>> 
> 
> There is a colossal difference between commercial use and commercial
> entities buying control of projects currently governed by entities
> which are answerable to the grassroots (GNU) and then toppling that
> governance structure in favor of one which is only answerable to
> boardrooms in Silicon Valley and Seattle WA.

There are, or would be if that were a real issue.  It's not something that is 
feasible with GPL licensed code, whether the copyright is held by the FSF as it 
is for GCC, or by all the authors as for Linux.

paul

Re: removing toxic emailers

[Paul Koning via Gcc]

> 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 would notice if it became so, I’m not sure about the idea that the wool
>  can be so easily pulled over our eyes.
> 
> I confess to being concerned with the equation “code” > “conduct”; it is not
> so in my professional or personal experience.   I have seen an engineering
> team suffer great losses of performance from the excesses of one (near genius,
> but very antisocial) member - the balance was not met.  Likewise, it has been
> seen to be a poor balance when there are three gifted individuals in a 
> household
> but one persecutes the other two (for diagnosed reaons).. again balance is not
> met
> 
> One could see the equation becoming a self-fullfilling prophecy viz.
> 
> *  let us say compilers are complex, and  any significant input over length 
> of time
>   will require a resonably competent engineer.
> 
> * reasonably competent engineers with a good social habit are welcome 
> everywhere
> 
> * reasonably competent engineers with poor social habit are welcome in few 
> places.

All true.

> - those few places will easily be able to demonstrate that their progress is 
> made
>  despite the poor atmosphere, with no way to know that something better was 
> possible.
> 
> responding to the thread in general..
> 
> * Please could we try to seek concensus?
> 
> - it is disappointing to see people treating this as some kind of 
> point-scoring game
>  when to those working on the compiler day to day it is far from a game.

I'm not sure what the consensus is you're looking for.  Consensus on the 
principle that people should behave in a civil fashion? Yes, I agree with that. 
 

The difficulty, as I mentioned, is in deciding in concrete situations whether 
that principle was violated and what should be done about it.  So I think the 
easy part is the principle; the hard part is the process that will enforce the 
principle in those cases where it needs to be -- and ONLY in those cases.  
Again, if the question had come up 10 years ago I wouldn't be so worried; but 
in 2021 after years of watching people being blacklisted for daring to speak 
the wrong politics of the day, I can no longer do so.

paul

Re: removing toxic emailers

[Paul Koning via Gcc]

> 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 remedy is to ostracise a participant, it is necessary to 
>> inquire for what reason this should be done (and, perhaps, who is pushing 
>> for it to be done).  My suggestion is that this judgment can be made by the 
>> community (via secret ballot), unless it is decided to delegate that power 
>> to a smaller body, considered as trustees, or whatever you choose to call 
>> them.
> 
> Personally, I think that voting is unworkable in practice.  I think
> decisions can be reasonably delegated to a small group of trusted
> people.  A fairly common name for that group is "moderators".  It
> might be appropriate to use voting of some sort when selecting
> moderators.

Yes, that seems reasonable.  I think the NetBSD project is an example of this, 
where the membership votes for the trustees, and the trustees are responsible 
for a number of project aspects including correcting bad behavior such as we're 
discussing here.

The SC was mentioned earlier in this thread, though that's not quite so natural 
given how that is appointed.

paul

Re: removing toxic emailers

[Paul Koning via Gcc]

> 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 the like -- IMHO it should be an extremely rare event.
>> As much as I disagree with some of the comments that have been made I
>> don't think they've risen to the level of wanting/needing to ban those
>> individuals from posting.
> 
> I think it's useful to observe that there are a reasonable number of
> people who will refuse to participate in a project in which the
> mailing list has regular personal attacks and other kinds of abusive
> behavior.  I know this because I've spoken with such people myself.
> They simply say "that project is not for me" and move on.
> 
> So we don't get the choice between "everyone is welcome" and "some
> people are kicked off the list."  We get the choice between "some
> people decline to participate because it is unpleasant" and "some
> people are kicked off the list."
> 
> Given the choice of which group of people are going to participate and
> which group are not, which group do we want?

My answer is "it depends".  More precisely, in the past I would have favored 
those who decline because the environment is unpleasant -- with the implied 
assumption being that their objections are reasonable.  Given the emergency of 
cancel culture, that assumption is no longer automatically valid.

This is why I asked the question "who decides?"  Given a disagreement in which 
the proposed remedy is to ostracise a participant, it is necessary to inquire 
for what reason this should be done (and, perhaps, who is pushing for it to be 
done).  My suggestion is that this judgment can be made by the community (via 
secret ballot), unless it is decided to delegate that power to a smaller body, 
considered as trustees, or whatever you choose to call them.

paul

Re: removing toxic emailers

[Paul Koning via Gcc]

> 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?  Searching the wiki
>>> or website finds nothing.  The mission statement mentions nothing.
>> I think that (most?) people have already figured out that messages from
>> unfamiliar senders on certain topics have to be ignored.  It is much
>> easier than any moderation, which would be ugly work (someone would have
>> to read the often horrible stuff).
>> I think that you only "associate" with trolls if you feed them.  I have
>> recently made that mistake on this list once and will not repeat it.
> 
> I disagree.  Their emails pollute the list.  Just as I wouldn't like to go to 
> a bar where there are noisy jerks in a corner, I don't like to frequent an ML 
> where there are.  Bouncers exist in physical space, is it so hard to 
> electronically bounce jerks?  Is it so hard to explicitly say 'be a jerk and 
> be thrown out'?

Who decides?

Bouncers enforce the policy of the owner of the joint.  In any meetingplace 
that has an owner who has authority over who enters, it's possible to establish 
rules controlling ejection and bouncers to do the ejecting.

Our place does not have a single owner who has the authority to decide 
unilaterally "you're not wanted, leave".  What mechanism would you use instead? 
 Ostracism, in the classic Greek sense of a secret ballot to decide for or 
against banishment?

paul

Re: GCC association with the FSF

[Paul Koning via Gcc]

> 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 to trash" mail rule.  The alternative would be to unsubscribe 
gcc, which it would be nice to avoid.

paul

Re: Remove RMS from the GCC Steering Committee

[Paul Koning via Gcc]

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 infraction of this code, 
and for adjudicating such claims?

paul

Scam alert

[Paul Koning via Gcc-patches]

It's probably obvious to most, but... I just got a fairly plausible looking 
phishing email pretending that my gcc.gnu.org password was about to expire.  
The link it asked me to click on was a giveaway that the mail came from a 
criminal, but we know that these red flags can be overlooked.

So just a note in case others are being scammed as well.

paul

Re: [PATCH 2/4] PDP11: Use a mode with `const_double_zero' expressions

[Paul Koning via Gcc-patches]

> On Jan 7, 2021, at 8:50 PM, Maciej W. Rozycki  wrote:
> 
> ...
> 
> Provide a new iterator to provide copies of FP substitutions across the 
> FP modes supported as the substitutions now need to match the mode of 
> the operands.
> 
>   gcc/
>   * config/pdp11/pdp11.md (PDPfp): New mode iterator.
>   (fcc_cc, fcc_ccnz): Use it.  Add mode to `const_double_zero' and 
>   operands.
> ---
> gcc/config/pdp11/pdp11.md |   10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
> 
> gcc-pdp11-const-double-zero-mode.diff
> Index: gcc/gcc/config/pdp11/pdp11.md
> ===
> --- gcc.orig/gcc/config/pdp11/pdp11.md
> +++ gcc/gcc/config/pdp11/pdp11.md
> @@ -82,6 +82,8 @@
> 
> (define_code_iterator SHF [ashift ashiftrt lshiftrt])
> 
> +(define_mode_iterator PDPfp [SF DF])
> +
> ;; Substitution to turn a CC clobber into a CC setter.  We have four of
> ;; these: for CCmode vs. CCNZmode, and for CC_REGNUM vs. FCC_REGNUM.
> (define_subst "cc_cc"
> @@ -101,19 +103,19 @@
>(set (match_dup 0) (match_dup 1))])
> 
> (define_subst "fcc_cc"
> -  [(set (match_operand 0 "") (match_operand 1 ""))
> +  [(set (match_operand:PDPfp 0 "") (match_operand:PDPfp 1 ""))
>(clobber (reg FCC_REGNUM))]
>   ""
>   [(set (reg:CC FCC_REGNUM)
> - (compare:CC (match_dup 1) (const_double_zero)))
> + (compare:CC (match_dup 1) (const_double_zero:PDPfp)))
>(set (match_dup 0) (match_dup 1))])
> 
> (define_subst "fcc_ccnz"
> -  [(set (match_operand 0 "") (match_operand 1 ""))
> +  [(set (match_operand:PDPfp 0 "") (match_operand:PDPfp 1 ""))
>(clobber (reg FCC_REGNUM))]
>   ""
>   [(set (reg:CCNZ FCC_REGNUM)
> - (compare:CCNZ (match_dup 1) (const_double_zero)))
> + (compare:CCNZ (match_dup 1) (const_double_zero:PDPfp)))
>(set (match_dup 0) (match_dup 1))])
> 
> (define_subst_attr "cc_cc" "cc_cc" "_nocc" "_cc")


Ok.  Thanks Maciej.

paul

Re: [PATCH] avr: cc0 to mode_cc conversion

[Paul Koning via Gcc-patches]

> On Jan 5, 2021, at 8:54 AM, Senthil Kumar Selvaraj via Gcc-patches 
>  wrote:
> 
> 
> Senthil Kumar Selvaraj writes:
> 
>> Georg-Johann Lay writes:
>> 
>> ...
>>> 
>>> 2) We just saw 100reds of insns being dublicated, basically the whole
>>> machine description except for the few insns that leave cc alone.
>>> Isn't is possible to use define subst for the bulk of the insns and
>>> get a neat code that's better to grasp and to maintain?
>>> After all it's just appending a clobber of reg_cc, and in the current
>>> proposal almost 50% of the backend is just redundent repetitions of
>>> previous insns.
> 
> I could not find a way to get define_subst to do define_insn_and_split -
> other targets using the same approach (pdp11, h8300) have the
> duplication as well.

I ran into the same issue, I tried as well for the obvious reason.  I'm pretty 
sure someone told me (a) that doesn't work, and (b) the reason is xyzzy.  But I 
no long remember what the reason is, or even if I was told one.

The impression I have is that define_subst isn't a macro facility, even though 
it looks a bit like one, and that may be why it can't do what you want to do 
here.

paul