Re: Can we please have the old mailing list back

[Jeff Law via Gcc]

On Fri, 2020-03-27 at 10:45 -0400, Christopher Faylor wrote:
> On Fri, Mar 27, 2020 at 07:00:59AM +0100, Bernd Edlinger wrote:
> > PS: I would CC you, Christopher Faylor, but your email address is
> > "cgf-use-the-mailinglist-ple...@gnu.org", so whatever I send there
> > would not reach you.
> 
> Well duh?  Not being cc'ed is the literal point of the email address.
> 
> Anyway, no one ever said that mhonarc was unavailable on CentOS 8.  We
> are using the archiver that's built into mailman which required very
> little effort to get up and running.  It's in use on scores, if not
> hundreds of sites around the web.
> 
> What I asked was if there was a public-inbox rpm available.
> 
> Anyway, since this is entirely a volunteer effort on my part and every
> daytime hour I spend working on it costs me money, I'm going to go with
> the answer "I don't have the time/don't want to" as the response to "Why
> don't you do X"
> 
> If people want to get a collection going and offer to pay for some
> improvements/changes to sourceware then I, personally, would consider
> spending more time on it.  Or maybe another overseer will jump in and
> offer to convert the system to majordomo or something.
I think one of the things folks need to keep in mind is that maintenance of
sourceware/gcc is a volunteer effort.  Chris, Frank, & co inherited a system 
that
we set up in the late 90s and have taken loving care of it since, often with
little or no recognition for their efforts.

The original system was pretty highly customized as the tools in the late 90s 
weren't nearly as standardized and the tools that were standardized had
significant performance and feature deficiencies.  Thus qmail+ezmlm.  Sigh.   It
made sense at the time, but that time has past.

Given changes in the landscape over the last 20+ years, I absolutely support the
move to standardized tools, particularly those for which we could potentially 
get
support.  So that would mean something like RHEL, but not EPEL.  Furthermore, I
strongly support the desire to bring the configuration of those tools closer and
closer to the default configurations.

As an ex IT guy, I've gone both directions depending on the project I was
supporting and certainly see the pros and cons of going highly customized vs as
generic as possible.  In my opinion Chris & Frank are doing the right thing here
and I would not support reverting or revisiting the decisions they made as part
of this upgrade.  Yes it means a slight bit of pain as everyone gets used to the
new system, but it's the right long term direction.

jeff

Re: Can we please have the old mailing list back

[Jeff Law via Gcc]

On Sat, 2020-03-28 at 18:46 +, Maciej W. Rozycki wrote:
> On Fri, 27 Mar 2020, Jeff Law via Gcc wrote:
> 
> > As an ex IT guy, I've gone both directions depending on the project I was
> > supporting and certainly see the pros and cons of going highly customized vs
> > as
> > generic as possible.  In my opinion Chris & Frank are doing the right thing
> > here
> > and I would not support reverting or revisiting the decisions they made as
> > part
> > of this upgrade.  Yes it means a slight bit of pain as everyone gets used to
> > the
> > new system, but it's the right long term direction.
> 
>  I think being software developers we are in this comfortable position 
> that we can actually make changes to software ourselves if we find 
> problems or usability issues.  So if something is perceived wrong, then 
> how about proposing a patch instead to the relevant piece of software so 
> that the expected feature is present in a future version (that we can then 
> seamlessly upgrade to)?
> 
>  For example I found it useful on a couple of occasions to be able to 
> retrieve the original message verbatim from the archive, when the message 
> didn't reach my mailbox for one reason or another.  That might be via a 
> web page, or better yet a list server command.  If the new archiver is 
> missing this feature, then I think the way to move forward is to propose a 
> change to add it to the archiver, which would solve the actual problem on 
> one hand while keeping the life of our volunteer IT people easy enough on 
> the other.
Just to be clear, something like the ability to download the original message
verbatim is critical to the project.  That's a capability we have to have and
thus some pain to make that possible is reasonable.

But in general we should be moving, to standardized tools and standardized
configurations when reasonably possible.  I don't think switching back to
qmail+ezmlm would be the right move though.

jeff

Re: Request to deprecate offloading to HSAIL in GCC

[Jeff Law via Gcc]

On Thu, 2020-04-09 at 21:17 +0200, Jakub Jelinek wrote:
> On Thu, Apr 09, 2020 at 07:43:02PM +0200, Martin Jambor wrote:
> > Therefore it is only fair to warn the community and any possible hidden
> > users or would-be users that it is very likely that I will propose
> > removal of HSAIL offloading in the course of GCC 11 development cycle
> > and I would like to formally deprecate it.
> 
> LGTM.
Me too.

Jeff
> 

Re: SH Port Status

[Jeff Law via Gcc]

On Mon, 2020-04-20 at 14:47 -0500, Joel Sherrill wrote:
> Hi
> 
> Over at RTEMS, we were discussing ports to deprecate/obsolete
> and the SH seems to be on everyone's candidate list. I can't seem
> to find any gcc test results sh-unknown-elf since 2009 and none
> for sh-rtems. I know I posted some but when, I can't say. But the
> new  mailing list  setup may be messing that up. I expected more
> recent results.
> 
> (1) Is my search right? Have there been no test results in 10 years?
> 
> (2) Is the toolchain in jeopardy?
> 
> (3) I know there was an effort to do an open implementation with
> j-core.org but there is no News or download item newer than 2016.
> Is this architecture effectively dead except for legacy hardware out
> in the field (Sega?)
> 
> I'm leaning to RTEMS dropping support for the SH after we branch
> a release and wondering if the GCC community knows anything that
> I don't.
I'm not aware of the SH toolchain being in any jeopardy. 


I'm doing weekly bootstrap (yes, really) & regression tests for {sh4,sh4eb}-
linux-gnu and daily builds of {sh3,sh3b}-linux-gnu.  See

http://gcc.gnu.org/jenkins

The Linux kernel is currently broken, but I suspect it's a transient issue as it
was fine until a week ago -- my tester usually builds the kernel too, but that's
been temporarily disabled for SH targets.

jeff

Re: SH Port Status

[Jeff Law via Gcc]

On Mon, 2020-04-20 at 15:29 -0500, Joel Sherrill wrote:
> 
> 
> On Mon, Apr 20, 2020, 3:13 PM Jeff Law  wrote:
> > On Mon, 2020-04-20 at 14:47 -0500, Joel Sherrill wrote:
> > > Hi
> > > 
> > > Over at RTEMS, we were discussing ports to deprecate/obsolete
> > > and the SH seems to be on everyone's candidate list. I can't seem
> > > to find any gcc test results sh-unknown-elf since 2009 and none
> > > for sh-rtems. I know I posted some but when, I can't say. But the
> > > new  mailing list  setup may be messing that up. I expected more
> > > recent results.
> > > 
> > > (1) Is my search right? Have there been no test results in 10 years?
> > > 
> > > (2) Is the toolchain in jeopardy?
> > > 
> > > (3) I know there was an effort to do an open implementation with
> > > j-core.org but there is no News or download item newer than 2016.
> > > Is this architecture effectively dead except for legacy hardware out
> > > in the field (Sega?)
> > > 
> > > I'm leaning to RTEMS dropping support for the SH after we branch
> > > a release and wondering if the GCC community knows anything that
> > > I don't.
> > I'm not aware of the SH toolchain being in any jeopardy. 
> > 
> > 
> > I'm doing weekly bootstrap (yes, really) & regression tests for {sh4,sh4eb}-
> > linux-gnu and daily builds of {sh3,sh3b}-linux-gnu.  See
> > 
> > http://gcc.gnu.org/jenkins
> 
> Awesome!
> > 
> > The Linux kernel is currently broken, but I suspect it's a transient issue 
> > as
> > it
> > was fine until a week ago -- my tester usually builds the kernel too, but
> > that's
> > been temporarily disabled for SH targets.
> 
> Thanks Jeff! Are you using the simulator in gdb? That's what we have a BSP 
> for?
I'm using qemu -- it's user mode emulation is strong enough that I can create a
little sh4 native root filesystem and bootstrap GCC within it.


> 
> We build the cross RTEMS tools regularly on Linux, Mac, FreeBSD, Mingw, and
> Cygwin. All of our BSPs build including sh1 and the odd sh2e. 
> 
> Our BSP status for the gdb simulator is unknown. We replaced a lot of testing
> infrastructure scripting and the SH hasn't gotten to the top of the list.
ACK.  In general, if there's a qemu solution, that's my preference these days. 
For the *-elf targets I usually have to fall back to the old gdb-sim bits.

> 
> So we both are building a lot and making sure rot hasn't set in. But in
> practice, is this worth the trouble anymore?
I'm not sure about that ;-)  I haven't seen anyone suggest removal of the port 
or
anything like that.  The port doesn't use CC0, so there's essentially zero 
chance
it'll be deprecated for gcc-11.  I believe the port is not using LRA, so if/when
we move on deprecating reload, SH might be at some degree of risk.

jeff
> 

Re: AVR CC0 transition

[Jeff Law via Gcc]

On Wed, 2020-04-22 at 22:01 +0530, Senthil Kumar via Gcc wrote:
> Hi,
> 
> I'm thinking about attempting to do the CC0 transition for the
> AVR port in my spare time.  I've read the CC0Transition gcc wiki
> page, and as the AVR ISA does not have non-condition-code
> clobbering arithmetic instructions, concluded that I'd have to
> follow the steps outlined for case #2.
> 
> Are there any other things I need to watch out for?
Not offhand.  You might want to look at how Bernd did the m68k though.  I think 
a
conceptually similar transition would be reasonable for AVR as well as the
alternative would be dropping the AVR port.

Jeff

Re: AVR CC0 transition

[Jeff Law via Gcc]

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

GCC is a volunteer project, so nothing is preventing them from getting directly
involved with the transition by hiring/sponsoring someone to do it and/or
generally maintain/improve the AVR port, nor does anything stand in their way of
participating indirectly via the bug bounty program that's been started for the
AVR transition.

Jeff

Re: AVR CC0 transition

[Jeff Law via Gcc]

On Thu, 2020-04-23 at 07:41 +0530, Senthil Kumar wrote:
> On Wed, Apr 22, 2020 at 10:08 PM Jeff Law  wrote:
> > On Wed, 2020-04-22 at 22:01 +0530, Senthil Kumar via Gcc wrote:
> > > Hi,
> > > 
> > > I'm thinking about attempting to do the CC0 transition for the
> > > AVR port in my spare time.  I've read the CC0Transition gcc wiki
> > > page, and as the AVR ISA does not have non-condition-code
> > > clobbering arithmetic instructions, concluded that I'd have to
> > > follow the steps outlined for case #2.
> > > 
> > > Are there any other things I need to watch out for?
> > Not offhand.  You might want to look at how Bernd did the m68k though.  I
> > think a
> > conceptually similar transition would be reasonable for AVR as well as the
> > alternative would be dropping the AVR port.
> 
> Hi Jeff,
> 
> Thanks, I will take a look at Bernd's work. IIRC, he took a
> different approach from what was suggested in the wiki, right?
Right.  Conceptually he brought the cc0-setter insn back into the cc0-user insn,
but kept some ability to remove the cc0-setter when the previous insn had set 
the
condition codes in a useful way.

Jeff
> 

Re: Not usable email content encoding

[Jeff Law via Gcc]

On Thu, 2020-04-23 at 09:34 +0100, Jonathan Wakely via Gcc wrote:
> On Thu, 23 Apr 2020 at 06:49, Florian Weimer wrote:
> > * Tamar Christina:
> > 
> > > A bit late to the party, but this really doesn't work that well
> > > because until recent version of gitlab there was no fairness
> > > guarantee.  another patch could be approved after mine (with hours
> > > in between because of CI) and yet still get merged first causing my
> > > own patch to no longer apply, you'd rebase and roll the dice again.
> > > To fix this they added merge trains
> > > https://docs.gitlab.com/ee/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/
> > > 
> > > but trains for GCC Will likely be very short because of Changelog
> > > conflicts.  So I don't think an automated merge workflow would work
> > > for projects where every single commit changes the same files.
> > 
> > I had not thought about that.
> > 
> > Does Gitlab support pluggable merge helpers?  The gnulib changelog
> > auto-merger did a great job when we were still writing changelogs for
> > glibc.
> 
> I've been having problems with it recently, e.g.
> https://gcc.gnu.org/g:e76100ced607218a3bf had to fix a changelog,
> because https://gcc.gnu.org/g:d76925e46fad09fc9be67 put my changelog
> entry in the wrong place in gcc/testsuite/Changelog, as a result of a
> rebase using merge-changelog.
> 
> Maybe we should follow glibc and get rid of ChangeLog files before
> trying to use automated CI and Git workflows.
This is precisely why I want to get rid of ChangeLogs and instead generate them
from the VCS as part of the release process.  Ultimately I want to be able to 
use
workflows where I can push a button on something that's gone through a CI cycle
or "git am" and not have to go back and fix things *by hand*.

What we do with ChangeLogs is (*&@#$*)(*&^ insane from an efficient workflow
standpoint.

jeff

Re: Not usable email content encoding

[Jeff Law via Gcc]

On Thu, 2020-04-23 at 06:46 -0500, Segher Boessenkool wrote:
> Hi!
> 
> On Thu, Apr 23, 2020 at 12:54:04AM +, Tamar Christina wrote:
> > but trains for GCC Will likely be very short because of Changelog conflicts.
> 
> Why that?  Your patches should *not* touch changelog files, ever.
> 
> For CI it is probably easiest if the CI never gets to see the changelog
> at all, and that isn't hard to do ;-)
*Nothing* should touch changelog files :-)  They should be generated from the
VCS.  IMHO of course.

That implies that the patch includes a proper ChangeLog entry in the commit
message.  It also implies that if we muck one up, then we live with it rather
than going back and rewriting them.

jeff

Re: Not usable email content encoding

[Jeff Law via Gcc]

On Thu, 2020-04-23 at 15:14 -0600, Tom Tromey wrote:
> > > > > > "Segher" == Segher Boessenkool  writes:
> 
> Segher> My point was that this should *never* be part of patches, already.
> 
> FWIW, I use a few scripts so that I can keep ChangeLogs as files.
> That's what I do when working on gdb.
> 
> https://github.com/tromey/git-gnu-changelog
> 
> This is easier on the whole, IME, because it means there is no extra
> manual step before pushing.
Right.  And that's really my goal here -- eliminate the manual steps.  Ideally I
want to be able to git am; git push on a good patch.  Manual steps for good
patches need to be excised from the workflow.  The ChangeLog file is a major
problem in that regard.



> 
> Of course, better would be to remove ChangeLogs entirely (including not
> putting anything like them into a commit message), because they are
> largely not useful and are just make-work.  Again IMNSHO -- I know there
> are some folks who read them, but I basically never have since switching
> to git.
I read them less and less.  At this point I think I read them to see if a
particular patch in my queue has already been applied.  Otherwise I'm using the
git info.

jeff

Re: Not usable email content encoding

[Jeff Law via Gcc]

On Fri, 2020-04-24 at 22:01 +0200, Martin Jambor wrote:
> Hi,
> 
> On Fri, Apr 24 2020, Segher Boessenkool wrote:
> > Hi!
> > 
> > On Fri, Apr 24, 2020 at 05:48:38PM +0200, Thomas Koenig wrote:
> > > > Of course, better would be to remove ChangeLogs entirely (including not
> > > > putting anything like them into a commit message), because they are
> > > > largely not useful and are just make-work.
> > > 
> > > I disagree. I find them quite useful.
> > 
> > For what?  And, can that be provided some other way?
> 
> I often have a look at them when reviewing a patch.  It is great when
> they clearly indicate whether a change is some form of restructuring or
> a functional change and broadly speaking what it is.  Then I just know
> what to look for.
> 
> I also find writing them useful as it forces me to go through every
> patch one last time before submitting it :-) If you spend some time
> configuring your text editor and git, the boilerplate stuff can be
> generated automatically.
Agreed on all the points above.  I can't count how many patches I've written
through the years, then got to the ChangeLog step and realized that further work
was needed.

> 
> I do not think this can be provided in any other way that would not
> resemble a ChangeLog.  I do support the effort to put them into commit
> messages only though (and then perhaps generate the files from that).
That's where I lean as well.  I could also live with the ChangeLog being
generated by a commit hook and the like.  Ultimately it's the manual steps in
applying patches that I want to eliminate from our workflows and the ChangeLog
file consistently results in the need for manual intervention.

jeff

Re: GCC Testsuite patches break AIX

[Jeff Law via Gcc]

On Wed, 2020-05-27 at 11:16 -0300, Alexandre Oliva wrote:
> Hello, David,
> 
> On May 26, 2020, David Edelsohn  wrote:
> 
> > Complaints about -dA, -dD, -dumpbase, etc.
> 
> This was the main symptom of the problem fixed in the follow-up commit
> r11-635-g6232d02b4fce4c67d39815aa8fb956e4b10a4e1b
> 
> Could you please confirm that you did NOT have this commit in your
> failing build, and that the patch above fixes the problem for you as it
> did for others?
> 
> 
> > This patch was not properly tested on all targets.
> 
> This problem had nothing to do with targets.  Having Ada enabled, which
> I've nearly always and very long done to increase test coverage, was
> what kept the preexisting bug latent in my testing.
> 
> 
> Sorry that I failed to catch it before the initial check in.
Any thoughts on the massive breakage on the embedded ports in the testsuite? 
Essentially every test that links is failing like this:

> Executing on host: /home/jenkins/workspace/c6x-elf/c6x-elf-obj/gcc/gcc/xgcc
> -B/home/jenkins/workspace/c6x-elf/c6x-elf-obj/gcc/gcc/
> /home/jenkins/gcc/gcc/testsuite/gcc.c-torture/execute/2112-1.c
> gcc_tg.o-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
> -fdiagnostics-color=never  -fdiagnostics-urls=never-O0  -w   -msim {} {}  
> -
> Wl,-wrap,exit -Wl,-wrap,_exit -Wl,-wrap,main -Wl,-wrap,abort -lm  -o
> ./2112-1.exe(timeout = 300)
> spawn -ignore SIGHUP /home/jenkins/workspace/c6x-elf/c6x-elf-obj/gcc/gcc/xgcc
> -B/home/jenkins/workspace/c6x-elf/c6x-elf-obj/gcc/gcc/
> /home/jenkins/gcc/gcc/testsuite/gcc.c-torture/execute/2112-1.c gcc_tg.o
> -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-
> color=never -fdiagnostics-urls=never -O0 -w -msim   -Wl,-wrap,exit -Wl,-
> wrap,_exit -Wl,-wrap,main -Wl,-wrap,abort -lm -o ./2112-1.exe^M
> xgcc: error: : No such file or directory^M
> xgcc: error: : No such file or directory^M
> compiler exited with status 1
> FAIL: gcc.c-torture/execute/2112-1.c   -O0  (test for excess errors)
> Excess errors:
> xgcc: error: : No such file or directory
> xgcc: error: : No such file or directory
> 


Sadly there's no additional output that would help us figure out what went 
wrong.

jeff

Re: AArch64 failures on tester

[Jeff Law via Gcc]

On Fri, 2020-06-05 at 14:27 +, Alex Coplan wrote:
> Hello,
> 
> Recently Jeff's tester picked up some test failures on AArch64. These
> are now fixed as of commit ab563903 but the aarch64-linux-gnu build is
> still failing with the following output:
> 
>   Old tests that failed, that have disappeared (8 tests): (Eeek!)
>   
>   g++.dg/warn/Wtype-limits-Wextra.C  -std=gnu++14  (test for bogus messages, 
> line 61)
>   g++.dg/warn/Wtype-limits-Wextra.C  -std=gnu++17  (test for bogus messages, 
> line 61)
>   g++.dg/warn/Wtype-limits-Wextra.C  -std=gnu++2a  (test for bogus messages, 
> line 61)
>   g++.dg/warn/Wtype-limits-Wextra.C  -std=gnu++98  (test for bogus messages, 
> line 61)
>   g++.dg/warn/Wtype-limits.C  -std=gnu++14  (test for bogus messages, line 61)
>   g++.dg/warn/Wtype-limits.C  -std=gnu++17  (test for bogus messages, line 61)
>   g++.dg/warn/Wtype-limits.C  -std=gnu++2a  (test for bogus messages, line 61)
>   g++.dg/warn/Wtype-limits.C  -std=gnu++98  (test for bogus messages, line 61)
That will not cause the tester to fail.  It only cares about regressions, ie
something that passed before, but fails now.

I'd like to flip it to fail for stuff like you've shown above, but we're having
enough trouble keeping things green when only looking at regressions :(

jeff

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

[Jeff Law via Gcc]

On Thu, 2020-04-23 at 10:40 +, xuemaosheng wrote:
> Product: GCC
> Component: rtl-optimization
> Version: 7.3.0
> 
> 
> If we add the flag DO_PREDICATION in scheduling ebb, the compiler will try to 
> predicate the insn when the producer insn has been issued,
> and put the consumer insn into suitable queue.  For example as shown in 
> schedule verbose dump file:
> 
> ;;  | insn | prio |
> ..
> ;;  |  387 |   27 | t1=a5==0   AGS0|AGS1
> ;;  |  388 |   27 | pc={(t1!=0)?L184:pc}   PCU
> ;;  |  459 |   26 | ev10=[a0+0xbc0]AGL0|AGL1
> ..
> 
> 
> ;;1--> +  387 t1=a5==0:AGS0|AGS1
> 
> deferring rescan insn with uid = 459.
> ;;  dependencies resolved: insn +  459 predicated
> ;;  Ready-->Q: insn +  459: queued for 2 cycles (change queue 
> index)
> ;;  tick updated: insn +  459 into queue with cost=2
> 
> insn 387 is a test insn, insn 388 is a jump insn, insn 459 is a load insn.
> After predicating, insn 459 convert into this form: [!t1] ev10 = [a0+0xbc0]
> and put insn 459 into queue[3]. INSN_TICK (459) = 3;
> 
> After issuing jump insn 388, the compiler will try to resotre pattern in insn 
> 459 as shown in the following dump files.
> 
> ;;  Ready list after ready_sort:  +  388:94:prio=27
> ;;  Ready list (t =   1):+  388:94:prio=27
> [1;1]:388
> ;;1--> +  388 pc={(t1!=0)?L184:pc}:PCU
> restoring pattern for insn 459
> deferring rescan insn with uid = 459.
> 
> However, the INSN_TICK of insn 459 doesn't calculate again.
> Actually, after restoring pattern, the insn can issue more earlier.
> If we recalculate the INSN_TICK of insn 459, we will get INSN_TICK (459) = 2, 
> then the load insn 459 can issue at clock t = 2 instead of clock t = 3.
> 
> So, can we add the following code to recalculate the INSN_TICK in function 
> restore pattern?
> 
> restore_pattern (dep_t dep, bool immediately)
> {
>   rtx_insn *next = DEP_CON (dep);
>   int tick = INSN_TICK (next);
> 
> .
> 
>   if (DEP_TYPE (dep) == REG_DEP_CONTROL)
> {
>   if (sched_verbose >= 5)
>   fprintf (sched_dump, "restoring pattern for insn %d\n",
>INSN_UID (next));
>   haifa_change_pattern (next, ORIG_PAT (next));
> +update_insn_after_change (next);
> +if ((TODO_SPEC (next) & (HARD_DEP | DEP_POSTPONED)) == 0)
> +  {
> +fix_tick_ready (next);
> +tick = INSN_TICK (next);
> +  }
> }
> ...
> 
> I found the similar code in function apply_replacement (dep_t dep, bool 
> immediately).
> 
> I think this patch can improve instruction parallelism.
It's a possibility -- it'd need to be tested of course.

I don't think anyone is actively working on improving predication support, so
it's possible that you're going to find more issues.  Also note you were looking
at gcc-7.3.0.  Work like this should be done on the trunk -- that's what you'll
need to test against and produce patches against.

jeff

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

[Jeff Law via Gcc]

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

jeff

Re: Re-optimize instrumented GIMPLE code

[Jeff Law via Gcc]

On Wed, 2020-06-17 at 15:10 +0800, Shuai Wang via Gcc wrote:
> Dear Martin,
> 
> Thanks for the information. I am tentatively experimenting some random
> gadgets; given the critical if condition belonging to each sanitizer check,
> i will do some data flow analysis and then decide whether to remove that
> check or not (done). If so, I will rewrite that if condition into always
> false (done), and hope I can re-launch the dead code elimination pass of
> GCC to automatically remove that particular sanitizer check (and the if
> condition).
> 
> This is just some random hacks, so probably far from the adoption stage...
> If it does, then i will be glad to reach out and discuss more on the
> details (although i am not sure how it goes)...
If you just ensure that the cfg cleanups are done when the pass is done the 
right things will just happen.  CFG cleanups are typically signaled by 
returning TODO_cleanup_cfg at the end of the pass.  There should be numerous 
examples throughout the GCC source code.

jeff

Re: Hoisting DFmode loads out of loops..

[Jeff Law via Gcc]

On Thu, 2020-06-25 at 15:46 -0400, Alan Lehotsky wrote:
> I’m working on a GCC 8.3 port to a load/store architecture with a 32-bit 
> data-path between registers and memory;  
> 
> looking at the gcc.dg/loop-9.c test, I fail to pass because I have split the 
> move of a double constant to memory into multiple moves (4 in fact, because I 
> only have a 16-bit immediate mode.)
> 
> The (define_insn_and_split “movdf” …) is conditioned on “reload_completed”.
> 
> Is there some other trick I need get the constant hoisted.  I have already 
> set the rtx cost of the CONST_DOUBLE ridiculously high (like 10 insns)
Hi Alan, it's been a long time...

We'd probably need to set the RTL.  A variety of things can get in the way of
LICM.  For example, I'd expect subregs to be problematical because they can look
like RMW operations.

jeff

Re: Hoisting DFmode loads out of loops..

[Jeff Law via Gcc]

On Fri, 2020-06-26 at 01:24 +, Alan Lehotsky wrote:
> > On Jun 25, 2020, at 6:37 PM, Jeff Law  wrote:
> > 
> > On Thu, 2020-06-25 at 15:46 -0400, Alan Lehotsky wrote:
> > > I’m working on a GCC 8.3 port to a load/store architecture with a 32-bit 
> > > data-path between registers and memory;  
> > > 
> > > looking at the gcc.dg/loop-9.c test, I fail to pass because I have split 
> > > the move of a double constant to memory into multiple moves (4 in fact, 
> > > because I only have a 16-bit immediate mode.)
> > > 
> > > The (define_insn_and_split “movdf” …) is conditioned on 
> > > “reload_completed”.
> > > 
> > > Is there some other trick I need get the constant hoisted.  I have 
> > > already set the rtx cost of the CONST_DOUBLE ridiculously high (like 10 
> > > insns)
> >  Hi Alan, it's been a long time...
> > 
> > We'd probably need to set the RTL.  A variety of things can get in the way 
> > of
> > LICM.  For example, I'd expect subregs to be problematical because they can 
> > look
> > like RMW operations.
> > 
> > jeff
> > 
>  
> 
> Hello to you too, Jeff….   I’ve been lurking for the last decade or so, last 
> port I actually did was was GCC 4 based, so lots of new stuff to try and wrap 
> my head around.  I certainly am grateful for anybody with suggestions as to 
> how to track down this problem (I’m not terribly eager to do a 
> parallel stepping thru a x86 gcc in parallel with my port to see where they 
> diverge in the loop-invariant recognition.) 
> 
> Although in crafting this expanded email, I see that the x86 has already 
> decided to store the constant 18.4242 in the .rodata section by the start of 
> loop-invariance so there’s a
> 
> (set (reg:DF…. ) (mem:DF  (symbol_ref ….)))
> 
> and I bet that’s far easier to move out of the loop than it would be to split 
> the original
> 
> (set (mem:DF…) (const_double:DF ….))
Yea, the former is definitely easier to apply LICM since we just have to
disambiguate the load against any stores in the loop.  The latter would have to
disamgiguate against the loads in the loop and possibly the stores as well.

I don't think loop-invariant.c would do anything with either form though.  LCM
(aka PRE) would probably have the best chance to handle the first form.  And,
yup, that's where it gets handled on x86.

jeff
> 

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

[Jeff Law via Gcc]

On Wed, 2020-07-01 at 11:19 +0100, Matthew Malcomson wrote:
> Hello,
> 
> I asked on IRC on Monday but since it didn't get any responses and the 
> mailing list doesn't require someone paying attention at the moment I 
> ask I'm asking here too.
> 
> 
> I've seen that  `expand_builtin_init_trampoline` generates a 
> `gen_rtx_MEM (BLKmode, ...)` on something returned from `expand_normal`.
> 
> On AArch64 with `-mabi=ilp32` the address from `expand_normal` is in 
> `ptr_mode` which is SImode.
> 
> This means the RTX the backend gets is something like `(mem:BLK (reg:SI 
> ...))`
> 
> 
> Since Pmode is DImode in the AArch64 backend, this is a little awkward 
> to deal with.
> The current code works with `ptr_mode`, but it calls a function path 
> which ICE's on a larger trampoline size.
> 
> 
> Many other functions in builtins.c generate MEM patterns with a Pmode 
> address by either using `convert_memory_address` (like 
> expand_builtin_nonlocal_goto and expand_builtin_atomic_compare_exchange)
> or using `memory_address` through `get_mem_rtx` (like 
> expand_builtin_strncpy, expand_movstr, or expand_builtin_memory_copy_args).
> 
> 
> Is this generation of such MEM patterns with ptr_mode rather than Pmode 
> in expand_builtin_init_trampoline and expand_builtin_init_descriptor 
> deliberate, or should we change them?
> (Note I guess that passing a different mode to the backends might cause 
> ICE's that will need to be fixed on a few different targets -- it would 
> on AArch64).
In general, most things should be using Pmode.  However, you have to be careful
when you're dealing with the memory storage vs an address we're actually going 
to
use in a memory dereference, pointer arithmetic, etc.  This distinction comes up
in trampolines because they have to pull a pointer out of memory, then use it. 
So there's some parts that use ptr_mode and others in Pmode.

Few targets have to deal with this stuff, so it's  a bit fragile and not 
terribly
well documented.

jeff

Re: Clobber REG_CC only for some constraint alternatives?

[Jeff Law via Gcc]

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

So I started with that on the H8, even though it did result in some code
efficiency regressions.  Then I started pulling apart those patterns when 
testing
showed it was worth the effort.

Jeff

Re: Clobber REG_CC only for some constraint alternatives?

[Jeff Law via Gcc]

On Thu, 2020-08-20 at 21:36 +0530, Senthil Kumar Selvaraj via Gcc wrote:
> Pip Cet writes:
> 
> > On Tue, Aug 18, 2020 at 6:52 AM Senthil Kumar Selvaraj
> >  wrote:
> > > > recognize such insns, but as it stands that define_insn would
> > > > recognize the incorrect insn:
> > > > 
> > > > [(set (reg:QI 0) (const_int 0))
> > > >  (clobber (scratch:CC))]
> > > 
> > > get_cc_reg_clobber_rtx also looks at the insn itself (i.e. whatever
> > > the erstwhile NOTICE_UPDATE_CC hook did), so if the cc attribute is LDI,
> > > and operands[1] is const0_rtx, it would return cc_reg_rtx as the clobber 
> > > reg.
> > > 
> > > AFAICT, some passes after reload verify if operands match constraints,
> > > and that would work in this case - I'm not sure if the pattern you
> > > mentioned could show up, outside of wrong splitters/peepholes in the md 
> > > file.
> > 
> > I don't think they can, but it's still another case of lying to GCC.
> > 
> > At the very least, output_movqi should assert that it isn't asked to
> > produce code for this situation.
> 
> I agree.
> > > Another approach would be to conservatively use a 'c' constraint and
> > > clobber REG_CC for all reg-reg moves.
> > 
> > I'd prefer splitting the constraint alternatives to have one clear-r0
> > alternative, an ldi alternative, and a clear -r1_31 alternative.
> > 
> > As for define_subst, is it really worth it? If I'm reading the
> > documentation correctly, it's not powerful enough to deal with scratch
> > operands on its own, so we'd probably need three or four variants of
> > define_subst just to handle those cases.
> 
> Is this related to cmpelim not looking at REG_CC clobber if there are
> other (clobber scratch..) preceding it?
> > I'm probably missing something obvious, but what's the reason for
> > keeping the CC-clobbering post-reload splitter when we already have a
> > CC-setting one? Are there significant post-reload optimizations that
> > can deal with a clobber but not an arbitrary assignment to CC? If so,
> > wouldn't it be better to fix those optimizations?
> 
> The post-reload splitter introduces the clobber. The wiki
> suggests that approach if most insns clobber REG_CC, perhaps because of
> the missed optimizations you describe below?
If most patterns set/clobber the flags, then yes, it's slightly better to only
expose them after reload.   Various passes that directly grub through RTL rather
than using helpers like single_set will optimize things better.

That's the approach I've taken with the H8 conversion, which is basically 
working
at this point and when I have the time I walk through various minor codegen
inefficiences.

Jeff

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

[Jeff Law via Gcc]

On Wed, 2020-08-05 at 18:12 +0100, Richard Sandiford wrote:
> PR96191 [https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96191]
> was a bug raised against the aarch64 implementation of -fstack-protector.
> As it happens, the same bug affected arm, but AFAICT those are the only
> two affected targets.
> 
> -fstack-protector works by:
> 
> * creating a special canary slot in the stack frame,
> * initialising it with a special canary value, and then
> * checking at the end of the function whether the canary slot still has
>   the correct value.
> 
> If the slot has changed value, the function calls a special stack-smash
> handler that would typically abort the program.
> 
> On many targets, the code that sets up and tests the canary slot will
> need to load the canary value into registers.  However, GCC tries
> to guarantee that this value does not remain in registers beyond the
> “test” and “set” operations.  For example, the documentation of the
> stack_protect_test pattern says:
> 
>   This pattern, if defined, compares a @code{ptr_mode} value from the
>   valid memory location in operand 1 with the memory in operand 0 without
>   leaving the value in a register afterward and branches to operand 2 if
>   the values were equal.
> 
>   If this pattern is not defined, then a plain compare pattern and
>   conditional branch pattern is used.
> 
> The bug in the PR was that aarch64 (and arm) did this when setting up
> the canary slot, but not when testing it.
> 
> However, it's not obvious (to me) whether this is really necessary and
> what it's really protecting against.  Even if we zero out the registers
> after these patterns, the canary value is still readily available by
> other means:
I suspect folks were just being paranoid and trying to do the right thing. The
fact there's other way to get at the data doesn't necessarily mean we should
leave it lying around in a convenient register.


> 
> (1) We don't make any effort to hide the address of the canary value
> (typically &__stack_chk_guard, although some targets support
> alternatives).  It's not obvious what “hiding” this address
> would actually mean in practice, since it would often be easily
> predictable from other non-secret addresses.
Well, isn't that only when the target doesn't support storing the guard in 
thread
local storage??   ie, I don't think you can get it consistently this way.

Now the pointer guard is a completely different story and I've been trying to 
get
that fixed for years ;(  Though I must admit it was awful nice to have it
available in a global when I needed to debug a problem related to pointer
mangling in glibc...



> 
> (2) The canary value is often available in stack locations, such as:
> 
> (a) a canary in the current function, if the current function
> uses stack-smash protection
> 
> (b) a “protected” caller further up the call stack
> 
> (c) canary values left around by previous calls, if the canary value
> happens to occupy “dead space” in the current frame
> 
> And being on the stack is of course fundamental to the whole scheme.
Yea, but these you have to go and find ;-)

> 

Jeff

Re: Clobber REG_CC only for some constraint alternatives?

[Jeff Law via Gcc]

On Tue, 2020-08-25 at 23:58 -0400, Hans-Peter Nilsson wrote:
> On Mon, 24 Aug 2020, Jeff Law via Gcc wrote:
> > On Thu, 2020-08-20 at 21:36 +0530, Senthil Kumar Selvaraj via Gcc wrote:
> > > The post-reload splitter introduces the clobber. The wiki
> > > suggests that approach if most insns clobber REG_CC, perhaps because of
> > > the missed optimizations you describe below?
> > If most patterns set/clobber the flags, then yes, it's slightly better to 
> > only
> > expose them after reload.   Various passes that directly grub through RTL 
> > rather
> > than using helpers like single_set will optimize things better.
> 
> The "slightly" being omissions like the one fixed in combine.c
> last month. ;-)  There's one in reload too ("Discard obvious
> no-ops, even without -O"), but it seems to be acting the other
> way(!)
Yea, this is the kind of thing I'm thinking of when I say "slightly".

> 
> If, for a machine where most insns clobber REG_CC, you instead
> emit with the clobber initially, you can have a tidier port: one
> define_subst:ed pattern instead of...  How many is it with the
> only-expose-after-reload method (counting define_insn,
> define_split, possibly a define_expand too that wasn't there for
> cc0)?  Two or three, per (original) insn with cc0?
It depends :-)  On the H8 I've tried to focus efforts on creating the additional
patterns only when they're actually helpful.  So it'd normally be 2X or 3X the
number of patterns, but it's slightly less on the H8.

I pondered a define_subst approach, but with my lack of experience with
define_subst and the head start from my son on the mechanical changes it seemed
easier to just continue without define_subst.

jeff

Re: Clobber REG_CC only for some constraint alternatives?

[Jeff Law via Gcc]

On Wed, 2020-08-26 at 11:18 +, Pip Cet wrote:
> On Mon, Aug 24, 2020 at 6:18 PM Jeff Law  wrote:
> > > The post-reload splitter introduces the clobber. The wiki
> > > suggests that approach if most insns clobber REG_CC, perhaps because of
> > > the missed optimizations you describe below?
> > If most patterns set/clobber the flags, then yes, it's slightly better to 
> > only
> > expose them after reload.   Various passes that directly grub through RTL 
> > rather
> > than using helpers like single_set will optimize things better.
> 
> I think I made it to the next pitfall :-)
> 
> The cmpelim pass tries to recognize cc-setting variants of insns.
> Whether or not there is one (i.e. whether or not the insn should be
> recognized) depends on the "cc" attribute, which depends on which
> alternative is used. So I did the obvious thing, and put a condition
> in the define_insn which depends on get_cc_attr (insn). But
> get_cc_attr() tries to recognize the insn, so we recurse indefinitely
> and die with a segfault.
> 
> Things appear to work with a somewhat subtle hack: we recognize that a
> false positive from the inner recognition isn't harmful, because the
> outer condition will still catch invalid cases.
> 
>   static int recurse = 0;
>   if (recurse)
> return gen_rtx_REG (CCmode, REG_CC); // causes the insn to be recognized
>   recurse++;
>   int old_insn_code = INSN_CODE (insn);
>   enum attr_cc cc = get_attr_cc (insn);
>   INSN_CODE (insn) = old_insn_code;
>   recurse--;
> 
> But surely that's not the right way?
> 
> Note that whether there is a CC-setting variant depends not just on
> the "cc" attr, but also on the precise operands for some values of the
> "cc" attr, which requires hairy C code to figure out.
> 
> Is it possible to avoid this situation by avoiding constraint
> alternatives, and defining insns separately for each of them?
You can split most things up like you've suggested.  The exception would be the
movXX patterns.

Jeff

Re: Clobber REG_CC only for some constraint alternatives?

[Jeff Law via Gcc]

On Thu, 2020-08-27 at 16:31 +0530, Senthil Kumar Selvaraj wrote:
> Pip Cet writes:
> 
> > On Mon, Aug 24, 2020 at 6:18 PM Jeff Law  wrote:
> > > > The post-reload splitter introduces the clobber. The wiki
> > > > suggests that approach if most insns clobber REG_CC, perhaps because of
> > > > the missed optimizations you describe below?
> > > If most patterns set/clobber the flags, then yes, it's slightly better to 
> > > only
> > > expose them after reload.   Various passes that directly grub through RTL 
> > > rather
> > > than using helpers like single_set will optimize things better.
> > 
> > I think I made it to the next pitfall :-)
> > 
> > The cmpelim pass tries to recognize cc-setting variants of insns.
> > Whether or not there is one (i.e. whether or not the insn should be
> > recognized) depends on the "cc" attribute, which depends on which
> > alternative is used. So I did the obvious thing, and put a condition
> > in the define_insn which depends on get_cc_attr (insn). But
> > get_cc_attr() tries to recognize the insn, so we recurse indefinitely
> > and die with a segfault.
> > 
> > Things appear to work with a somewhat subtle hack: we recognize that a
> > false positive from the inner recognition isn't harmful, because the
> > outer condition will still catch invalid cases.
> > 
> >   static int recurse = 0;
> >   if (recurse)
> > return gen_rtx_REG (CCmode, REG_CC); // causes the insn to be recognized
> >   recurse++;
> >   int old_insn_code = INSN_CODE (insn);
> >   enum attr_cc cc = get_attr_cc (insn);
> >   INSN_CODE (insn) = old_insn_code;
> >   recurse--;
> > 
> > But surely that's not the right way?
> > 
> > Note that whether there is a CC-setting variant depends not just on
> > the "cc" attr, but also on the precise operands for some values of the
> > "cc" attr, which requires hairy C code to figure out.
> 
> This is only for ldi and plus cc attribute values, right? Can we
> conservatively have only the clobber, and see how it impacts generated code?
You should always be able to claim its clobbered, to get things running, then
evaluate if it's worth trying to model that case more accurately to get better
compare elimination.

jeff

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

[Jeff Law via Gcc]

On 9/18/20 8:13 AM, sathesh edara via Gcc wrote:
> Hi All,
>I am looking for a patch file to forbid emitting lwl/lwr/swl/swr
> instructions in gcc-5.5.0 for mips.
> I see the link below, which has already submitted a patch ( gcc 3..4.1) for
> this.
>
> https://gcc.gnu.org/pipermail/gcc/2005-February/139667.html
>   Could you please give pointers/links to download this patch file  to
> achieve above functionality?

To the best of my knowledge no patch was ever officially submitted --
there was just a list discussion where Ian gave suggestions to Mile, but
no actual code submission.


Note that those instructions are only available on certain MIPS
processor variants and you can use flags to control the processor
variant GCC compiles for.  See the details in the GCC manual. (MIPS
Options).  If those options are insufficient to give you the control you
need, then you'll have to hack the sources yourself and build your own
compilers.


Jeff



pEpkey.asc
Description: application/pgp-keys

Re: CSE deletes valid REG_EQUAL?

[Jeff Law via Gcc]

On 11/12/20 7:02 PM, Xionghu Luo via Gcc wrote:
> Hi all,
>
> In PR51505(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51505), Paolo Bonzini 
> added the code to delete REG_EQUAL notes in df_remove_dead_eq_notes:
>
> gcc/df-problems.c:
> df_remove_dead_eq_notes (rtx_insn *insn, bitmap live)
> {
> ...
>   case REG_EQUAL:
>   case REG_EQUIV:
> {
>   /* Remove the notes that refer to dead registers.  As we have at 
> most
>  one REG_EQUAL/EQUIV note, all of EQ_USES will refer to this note
>  so we need to purge the complete EQ_USES vector when removing
>  the note using df_notes_rescan.  */
>   df_ref use;
>   bool deleted = false;
>
>   FOR_EACH_INSN_EQ_USE (use, insn)
> if (DF_REF_REGNO (use) >= FIRST_PSEUDO_REGISTER
> && DF_REF_LOC (use)
> && (DF_REF_FLAGS (use) & DF_REF_IN_NOTE)
> && !bitmap_bit_p (live, DF_REF_REGNO (use))
> && loc_mentioned_in_p (DF_REF_LOC (use), XEXP (link, 0)))
>   {
> deleted = true;
> break;
>   }
>   if (deleted)
> {
>   rtx next;
>   if (REG_DEAD_DEBUGGING)
> df_print_note ("deleting: ", insn, link);
>   next = XEXP (link, 1);
>   free_EXPR_LIST_node (link);
>   *pprev = link = next;
>   df_notes_rescan (insn);
> }
> ...
> }
>
>
> while I have a test case as below:
>
>
> typedef long myint_t;
> __attribute__ ((noinline)) myint_t
> hash_loop (myint_t nblocks, myint_t hash)
> {
> int i;
> for (i = 0; i < nblocks; i++)
>   hash = ((hash + 13) | hash) + 0x66546b64;
> return hash;
> }
>
> before cse1:
>
>22: L22:
>16: NOTE_INSN_BASIC_BLOCK 4
>17: r125:DI=r120:DI+0xd
>18: r118:DI=r125:DI|r120:DI
>19: r126:DI=r118:DI+0x6654
>20: r120:DI=r126:DI+0x6b64
>   REG_EQUAL r118:DI+0x66546b64
>21: r119:DI=r119:DI-0x1
>23: r127:CC=cmp(r119:DI,0)
>24: pc={(r127:CC!=0)?L22:pc}
>   REG_BR_PROB 955630228
>
> The dump in cse1:
>
>16: NOTE_INSN_BASIC_BLOCK 4
>17: r125:DI=r120:DI+0xd
>18: r118:DI=r125:DI|r120:DI
>   REG_DEAD r125:DI
>   REG_DEAD r120:DI
>19: r126:DI=r118:DI+0x6654
>   REG_DEAD r118:DI
>20: r120:DI=r126:DI+0x6b64
>   REG_DEAD r126:DI
>21: r119:DI=r119:DI-0x1
>23: r127:CC=cmp(r119:DI,0)
>24: pc={(r127:CC!=0)?L22:pc}
>   REG_DEAD r127:CC
>   REG_BR_PROB 955630228
>   ; pc falls through to BB 6
>
>
> The output shows "REQ_EQUAL r118:DI+0x66546b64" is deleted by 
> df_remove_dead_eq_notes,
> but r120:DI is not REG_DEAD here, so is it correct here to check insn use and 
> find that
> r118:DI is dead then do the delete?

It doesn't matter where the death occurs, any REG_DEAD note will cause
the REG_EQUAL note to be removed.  So given the death note for r118,
then any REG_EQUAL note that references r118 will be removed.  This is
overly pessimistic as the note may still be valid/useful at some
points.  See

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92291


Jeff


ps.  Note that a REG_EQUAL note is valid at a particular point in the IL
-- it is not a function-wide equivalence.  So you have to be careful
using such values as they can be invalidated by other statements. 
Contrast to a REG_EQUIV note where the equivalence is global and you
don't have to worry about invalidation.

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

[Jeff Law via Gcc]

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

 On 2019/11/21 8:10 PM, Richard Biener wrote:
> On Thu, Nov 21, 2019 at 10:22 AM Li Jia He 
 wrote:
>> Hi,
>>
>> I found for the follow code:
>>
>> #define N 256
>> int a[N][N][N], b[N][N][N];
>> int d[N][N], c[N][N];
>> void __attribute__((noinline))
>> double_reduc (int n)
>> {
>> for (int k = 0; k < n; k++)
>> {
>>   for (int l = 0; l < n; l++)
>>{
>>  c[k][l] = 0;
>>   for (int m = 0; m < n; m++)
>> c[k][l] += a[k][m][l] * d[k][m] + b[k][m][l] * d[k][m];
>>}
>> }
>> }
>>
>> I dumped the file after loop interchange and got the following
 information:
>>  [local count: 118111600]:
>> # m_46 = PHI <0(7), m_45(11)>
>> # ivtmp_44 = PHI <_42(7), ivtmp_43(11)>
>> _39 = _49 + 1;
>>
>>  [local count: 955630224]:
>> # l_48 = PHI <0(3), l_47(12)>
>> # ivtmp_41 = PHI <_39(3), ivtmp_40(12)>
>> c_I_I_lsm.5_18 = c[k_28][l_48];
>> c_I_I_lsm.5_53 = m_46 != 0 ? c_I_I_lsm.5_18 : 0;
>> _2 = a[k_28][m_46][l_48];
>> _3 = d[k_28][m_46];
>> _4 = _2 * _3;
>> _5 = b[k_28][m_46][l_48];
>> _6 = _3 * _5;
>> _7 = _4 + _6;
>> _8 = _7 + c_I_I_lsm.5_53;
>> c[k_28][l_48] = _8;
>> l_47 = l_48 + 1;
>> ivtmp_40 = ivtmp_41 - 1;
>> if (ivtmp_40 != 0)
>>   goto ; [89.00%]
>> else
>>   goto ; [11.00%]
>>
>> we can see '_3 = d[k_28][m_46];'  is a loop invariant.
>> Do we need to add a loop invariant motion pass after the loop
 interchange?
> There is one at the end of the loop pipeline.
 Hi,

 The one at the end of the loop pipeline may miss some optimization
 opportunities.  If we vectorize the above code (a.c.158t.vect), we
 can get information similar to the following:

 bb 3:
  # m_46 = PHI <0(7), m_45(11)>  // loop m, outer loop
   if (_59 <= 2)
 goto bb 20;
   else
 goto bb 15;

 bb 15:
   _89 = d[k_28][m_46];
   vect_cst__90 = {_89, _89, _89, _89};

 bb 4:
# l_48 = PHI  // loop l, inner loop
   vect__6.23_100 = vect_cst__99 * vect__5.22_98;
if (ivtmp_110 < bnd.8_1)
 goto bb 12;
   else
 goto bb 17;

 bb 20:
 bb 18:
_27 = d[k_28][m_46];
 if (ivtmp_12 != 0)
 goto bb 19;
   else
 goto bb 21;

 Vectorization will do some conversions in this case.  We can see
 ‘ _89 = d[k_28][m_46];’ and ‘_27 = d[k_28][m_46];’ are loop invariant
 relative to loop l.  We can move ‘d[k_28][m_46]’ to the front of
 ‘if (_59 <= 2)’ to get rid of loading data from memory in both
 branches.

 The one at at the end of the loop pipeline can't handle this situation.
 If we move d[k_28][m_46] from loop l to loop m before doing
 vectorization, we can get rid of this situation.
>>> But we can't run every pass after every other. With multiple passes having 
>>> ordering issues is inevitable.
>>>
>>> Now - interchange could trigger a region based invariant motion just for 
>>> the nest it interchanged. But that doesn't exist right now.
>> With data reference/dependence information in the pass, I think it
>> could be quite straightforward.  Didn't realize that we need it
>> before.
> FYI, attachment is a simple fix in loop interchange for the reported
> issue. It's untested, neither for GCC10.
>
> Thanks,
> bin
>> Thanks,
>> bin
>>> Richard.
>>>
>>> linterchange-invariant-dataref-motion.patch
>>>
So it looks like Martin and Richi are working on this right now.  I'm
going to drop this from my queue.


jeff

Re: CSE deletes valid REG_EQUAL?

[Jeff Law via Gcc]

On 11/13/20 6:55 AM, Segher Boessenkool wrote:
> Hi guys,
>
> On Thu, Nov 12, 2020 at 09:10:14PM -0700, Jeff Law wrote:
>> On 11/12/20 7:02 PM, Xionghu Luo via Gcc wrote:
>>> The output shows "REQ_EQUAL r118:DI+0x66546b64" is deleted by 
>>> df_remove_dead_eq_notes,
>>> but r120:DI is not REG_DEAD here, so is it correct here to check insn use 
>>> and find that
>>> r118:DI is dead then do the delete?
>> It doesn't matter where the death occurs, any REG_DEAD note will cause
>> the REG_EQUAL note to be removed.  So given the death note for r118,
>> then any REG_EQUAL note that references r118 will be removed.  This is
>> overly pessimistic as the note may still be valid/useful at some
>> points.  See
>>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92291
> The note even *always* is valid where it is!  As you say, the REG_EQUAL
> is only (necessarily) valid at *that* insn.  And this insn *sets* the
> reg (that is the only case when a REG_EQ* is allowed at all), so if the
> eq reg is dead (i.e. unused) the whole insn is, and the insn can be
> removed.
>
> Removing all REG_EQUAL notes for regs that become dead anywhere seems
> to just be a thinko?  All pseudos are dead somewhere!  (Yeah okay,
> infinite loops, but other than that.)
Yea, but the code which wipes the notes probably has no sense of where
in the RTL stream the note is valid and where it is not.  So it does the
fairly dumb thing and just ends up wiping them all away because as you
noted, most pseudos have a death somewhere.  One might argue that the
code is OK as-is, but just needs to be run later.  After cse2 would be
the most logical location since CSE is probably the heaviest user of the
notes.  But I'd worry that the problems referenced in c#2 of bz51505
could crop up in other contexts than just combine.

jeff

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

[Jeff Law via Gcc]

On 11/17/20 2:26 AM, Thomas Schwinge wrote:
> Hi!
>
> (As discussed before...), in 2020, email doesn't work anymore the way it
> did years ago...  ;-/ (Let's please *not* discuss this here.)
>
> So we're now dealing with emails with "From: [...] via Gcc-patches
> ", etc.
>
> ... which occasionally then ends up in Git commit author:
>
> On 2020-11-17T00:15:36+, Jeff Law via Gcc-cvs  wrote:
>> https://gcc.gnu.org/g:a019766f996f57e53a8d1a9e72033e1e1487a150
>>
>> commit r11-5068-ga019766f996f57e53a8d1a9e72033e1e1487a150
>> Author: Armin Brauns via Gcc-patches 
> Should we have a Git commit hook to catch that (and similar variants)?
>
>
> (This is not to blame Jeff, of course; it's very easy to not notice
> that.)
Yea.  I keep having to remember which header to pull the author from.  I
strongly suspected one or more had slipped through.

jeff

Re: Incremental updating of SSA_NAMEs that are passed to b_c_p

[Jeff Law via Gcc]

On 10/27/20 12:34 PM, Ilya Leoshkevich wrote:
> Hi,
>
> I'd like to revive the old discussion regarding the interaction of
> jump threading and b_c_p causing the latter to incorrectly return 1 in
> certain cases:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2020-June/547236.html
> https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549288.html
>
> The conclusion was that this happening during threading is just a
> symptom of a deeper problem: SSA_NAMEs that are passed to b_c_p should
> not be registered for incremental updating.
That's perhaps not as precise as we'd like to be.

Simply registering the SSA_NAME isn't the problem.  It's the need to
generate a PHI to resolve the incremental update that causes the
problems.    And as much as anything it's a sanity check that we're not
filtering out jump threading cases that we should (ignore the case for
now where the PHI we generate is a degenerate).

Now it may be painful to actually detect those cases.  I haven't looked
at the into-ssa bits in years.



>
> I performed a little experiment and added an assertion to
> create_new_def_for:
>
> --- a/gcc/tree-into-ssa.c
> +++ b/gcc/tree-into-ssa.c
> @@ -2996,6 +3014,8 @@ create_new_def_for (tree old_name, gimple *stmt,
> def_operand_p def)
>  {
>tree new_name;
>  
> +  gcc_checking_assert (!used_by_bcp_p (old_name));
> +
>timevar_push (TV_TREE_SSA_INCREMENTAL);
>  
>if (!update_ssa_initialized_fn)
>
> This has of course fired when performing basic block duplication during
> threading, which can be fixed by avoiding duplication of basic blocks
> wi
> th b_c_p calls:
>
> --- a/gcc/tree-cfg.c
> +++ b/gcc/tree-cfg.c
> @@ -6224,7 +6224,8 @@ gimple_can_duplicate_bb_p (const_basic_block bb)
>   || gimple_call_internal_p (g, IFN_GOMP_SIMT_EXIT)
>   || gimple_call_internal_p (g, IFN_GOMP_SIMT_VOTE_ANY)
>   || gimple_call_internal_p (g, IFN_GOMP_SIMT_XCHG_BFLY)
> - || gimple_call_internal_p (g, IFN_GOMP_SIMT_XCHG_IDX)))
> + || gimple_call_internal_p (g, IFN_GOMP_SIMT_XCHG_IDX)
> + || gimple_call_builtin_p (g, BUILT_IN_CONSTANT_P)))
> return false;
>  }
Yea, that's a reasonable place to start with the checking assert to see
how pervasive these problems are.  I probably wouldn't just blindly
disable threading through blocks with b_c_p call, but again, it seems
like a reasonable thing to do to help get a sense of other problem areas.

>
> The second occurrence is a bit more interesting:
>
> gimple *
> vrp_insert::build_assert_expr_for (tree cond, tree v)
> {
>   ...
>   a = build2 (ASSERT_EXPR, TREE_TYPE (v), v, cond);
>   assertion = gimple_build_assign (NULL_TREE, a);
>   ...
>   tree new_def = create_new_def_for (v, assertion, NULL);
>
> The fix is also simple though:
>
> --- a/gcc/tree-vrp.c
> +++ b/gcc/tree-vrp.c
> @@ -3101,6 +3101,9 @@ vrp_insert::process_assert_insertions_for (tree
> name, assert_locus *loc)
>if (loc->expr == loc->val)
>  return false;
>  
> +  if (used_by_bcp_p (name))
> +return false;
> +
>cond = build2 (loc->comp_code, boolean_type_node, loc->expr, loc-
>> val);
>assert_stmt = build_assert_expr_for (cond, name);
>if (loc->e)
>
> My original testcase did not trigger anything else.  I'm planning to
> check how this affects the testsuite, but before going further I would
> like to ask: is this the right direction now?  To me it looks a
> little-bit more heavy-handed than the original approach, but maybe it's
> worth it.
It seems  a bit heavy-handed.  But that's not based on any hard data,
just a sense that we may not want to disable threading this aggressively.

jeff

Re: DWARF64 gcc/clang flag discussion

[Jeff Law via Gcc]

On 11/23/20 7:38 PM, David Blaikie via Gcc wrote:
> On Mon, Nov 23, 2020 at 12:32 AM Richard Biener
>  wrote:
>> On Sat, Nov 21, 2020 at 1:21 AM m...@klomp.org  wrote:
>>> On Fri, Nov 20, 2020 at 08:22:26PM +, Alexander Yermolovich wrote:
 On llvm side of compiler world there has been work done by Igor Kudrin to 
 enable DWARF64.
 I am trying to add a flag to Clang to enable DWARF64 generation. 
 https://reviews.llvm.org/D90507
 In review David Blaikie pointed out that there has been a discussion on 
 what to call this flag:
 https://linuxplumbersconf.org/event/7/contributions/746/attachments/578/1018/DWARF5-64.pdf
 https://linuxplumbersconf.org/event/7/sessions/90/attachments/583/1201/dwarf-bof-notes-aug24-lpc-2020.txt
 https://www.mail-archive.com/gcc@gcc.gnu.org/msg92495.html

 Reading through that it doesn't look like there is a consensus on what it 
 should be.

 From discussion there is seems to be mixed opinion if it should be
 -f or -g. Primarily centered around if -g prefix implies
 turning on generation of debug information.

 Now that LLVM can actually generate DWARF64 for ELF, can we come to 
 consensus on the name?
>>> I don't believe any firm consensus was reached on naming yet.  But I
>>> would pick -fdwarf32/-fdwarf64.
>> I would pick -gdwarf32/-gdwarf64 (are we sure the DWARF spec will
>> never reach version 32 or 64?
>> maybe -g32 / -g64 similar to -m32/-m64 are good enough?)
> Any sense of a good way to break the tie/uncertainty?
>
> Alternatively: If Clang picks something here (likely from within this
> range of candidates - though given I've got a fair bit of say on the
> Clang side, and if left to me, I'd probably lean heavily on the
> -fdwarf32/64 side), is it likely that choice will tend to be adopted
> by GCC? I'd rather not get out of sync, but I expect a bit hard to get
> a conclusion on the GCC side without patches in progress, etc. Got a
> sense of who are the people who would likely be deciders/patch
> approvers for such a naming choice on the GCC side?
Historically debugging options belong under -g on the GCC side and
options that twiddle code generation are under -f.  So -gdwarf32
/-gdwarf64 or -g32/-g64 seem like the right options for GCC.

jeff

Re: DWARF64 gcc/clang flag discussion

[Jeff Law via Gcc]

On 11/23/20 8:03 PM, David Blaikie wrote:
> On Mon, Nov 23, 2020 at 6:59 PM Jeff Law  wrote:
>>
>>
>> On 11/23/20 7:38 PM, David Blaikie via Gcc wrote:
>>> On Mon, Nov 23, 2020 at 12:32 AM Richard Biener
>>>  wrote:
 On Sat, Nov 21, 2020 at 1:21 AM m...@klomp.org  wrote:
> On Fri, Nov 20, 2020 at 08:22:26PM +, Alexander Yermolovich wrote:
>> On llvm side of compiler world there has been work done by Igor Kudrin 
>> to enable DWARF64.
>> I am trying to add a flag to Clang to enable DWARF64 generation. 
>> https://reviews.llvm.org/D90507
>> In review David Blaikie pointed out that there has been a discussion on 
>> what to call this flag:
>> https://linuxplumbersconf.org/event/7/contributions/746/attachments/578/1018/DWARF5-64.pdf
>> https://linuxplumbersconf.org/event/7/sessions/90/attachments/583/1201/dwarf-bof-notes-aug24-lpc-2020.txt
>> https://www.mail-archive.com/gcc@gcc.gnu.org/msg92495.html
>>
>> Reading through that it doesn't look like there is a consensus on what 
>> it should be.
>>
>> From discussion there is seems to be mixed opinion if it should be
>> -f or -g. Primarily centered around if -g prefix implies
>> turning on generation of debug information.
>>
>> Now that LLVM can actually generate DWARF64 for ELF, can we come to 
>> consensus on the name?
> I don't believe any firm consensus was reached on naming yet.  But I
> would pick -fdwarf32/-fdwarf64.
 I would pick -gdwarf32/-gdwarf64 (are we sure the DWARF spec will
 never reach version 32 or 64?
 maybe -g32 / -g64 similar to -m32/-m64 are good enough?)
>>> Any sense of a good way to break the tie/uncertainty?
>>>
>>> Alternatively: If Clang picks something here (likely from within this
>>> range of candidates - though given I've got a fair bit of say on the
>>> Clang side, and if left to me, I'd probably lean heavily on the
>>> -fdwarf32/64 side), is it likely that choice will tend to be adopted
>>> by GCC? I'd rather not get out of sync, but I expect a bit hard to get
>>> a conclusion on the GCC side without patches in progress, etc. Got a
>>> sense of who are the people who would likely be deciders/patch
>>> approvers for such a naming choice on the GCC side?
>> Historically debugging options belong under -g on the GCC side and
>> options that twiddle code generation are under -f.  So -gdwarf32
>> /-gdwarf64 or -g32/-g64 seem like the right options for GCC.
> Did you happen to catch the other thread linked above (
> https://www.mail-archive.com/gcc@gcc.gnu.org/msg92495.html ) where
> there are a fair few examples of both -g and -f flags affecting debug
> info (& significant contributors, like Cary, who seem to share some of
> the "-f flags seem reasonable for
> debug-info-affecting-but-not-activating flags" perspective), combined
> with the ambiguity of "does this -g* option enable debug info, or only
> tweak how debug info would be emitted if debug info is otherwise
> requested"?
Yes.  While there are examples where that historical model hasn't been
followed, I don't think that's a good reason to make it worse than it
already is.  I still think it belongs in the -g namespace.

jeff

Re: DWARF64 gcc/clang flag discussion

[Jeff Law via Gcc]

On 11/24/20 4:11 AM, Jakub Jelinek via Gcc wrote:
> On Tue, Nov 24, 2020 at 12:04:45PM +0100, Mark Wielaard wrote:
>> Hi,
>>
>> On Tue, 2020-11-24 at 08:50 +0100, Richard Biener wrote:
>>> On Tue, Nov 24, 2020 at 8:45 AM Jakub Jelinek  wrote:
 I agree with Richard and I'd lean towards -gdwarf32/-gdwarf64, even
 when DWARF 32 is released in 81 years from now or how many, it would
 use -gdwarf-32.
>>> Works for me.  Let's go with -gdwarf32/64.
>> I don't have a strong opinion, so if that is the consensus, lets go
>> with that. The only open question (which I wanted to avoid by picking
>> -f...) is whether it enables generating debuginfo as is normal when
>> using any -goption, or whether you need another -goption to explicitly
>> turn on debuginfo generation when using -gdwarf32/64? My preference
>> would be that any option starting with -g enables debuginfo generation
>> and no additional -g is needed to keep things consistent.
> I think we lost that consistency already, I think -gsplit-dwarf has been
> changed quite recently not to imply -g.
>
> That said, for -gdwarf32/64, I think it is more sensible to enable debug
> info than not to.
That works for me.
jeff

Re: Possible code to remove DECL_NONSHAREABLE?

[Jeff Law via Gcc]

On 11/27/20 5:47 AM, Matthew Malcomson via Gcc wrote:
> Hi there,
>
> I was just looking through the history of how some code came about,
> and get the impression that DECL_NONSHAREABLE was meant to be removed.
>
> It seems like it was added to solve PR49103, with the idea that it
> could be removed once a more robust solution was added.
>
> Original comment and email mentioning the idea of this not being the
> final solution:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49103#c12
> https://gcc.gnu.org/legacy-ml/gcc-patches/2011-06/msg00480.html
>
> Email mentioning the idea to remove it later
> https://gcc.gnu.org/legacy-ml/gcc-patches/2011-06/msg01025.html
>
>
> I seems that the more invasive solution was eventually added.
> https://gcc.gnu.org/legacy-ml/gcc-patches/2011-11/msg00253.html
> Commit 47598145be, From-SVN: r181172
>
>
> Does that mean that the original DECL_NONSHAREABLE hack can be removed?
> (It seems like the extra bit in the tree structure can't since it's
> now used for something else, but I suspect we can still remove the
> code using it for this DECL_NONSHAREABLE purpose).
>
> I've ran a quick test on an AArch64 native configuration I had handy
> and that fortran test still passed, but don't have the time to look
> into it fully (especially given how I'm not familiar with this area).
Seems like a gcc-12 thing to me.

jeff

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

[Jeff Law via Gcc]

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

Jeff

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

[Jeff Law via Gcc]

On 12/7/20 6:06 PM, Jim Wilson wrote:
> I'm not aware of any other target that has a similar feature, so I thought
> a bit of discussion first might be useful.
>
> For most ISAs, there is one organization that owns it, and does development
> internally, in private.  For RISC-V, the ISA is owned by RISC-V
> International which has no developers.  The development all happens
> externally, in public, spread across at least a dozen different
> organizations.  So we have the problem of coordinating this work,
> especially for draft versions of extensions.  So we would like to add
> support for draft extensions to mainline, controlled by a
> -menable-experimental-extensions option.  For features enabled by this
> option, there would be no guarantee that the next compiler release is
> compatible with the previous one, since the draft extension may change in
> incompatible ways.
>
> LLVM already has support for this option.
> http://lists.llvm.org/pipermail/llvm-dev/2020-January/138364.html
> https://reviews.llvm.org/D73891
>
> We are still discussing the details of how this will work.  We may want to
> limit this to 'stable" draft extensions, and put the unstable drafts on a
> vendor branch.
>
> We have been doing work on branches in the github.com riscv tree, but there
> are issues with tracking who has copyright assignments, issues with
> identifying who exactly a github user actually is, and issues with getting
> the right set of people right access to the trees.  These won't be problems
> if we are using the FSF trees instead.
>
> We want this draft extension support on mainline for the same reasons that
> the LLVM developers do, to ensure that everyone is working in the same
> branch in the upstream tree.  And it is easiest to do that if that branch
> is mainline.
>
> This is just a binutils and gcc proposal at the moment, but we might need
> something on the gdb side later, like a
>   set riscv experimental-extensions 1
> or whatever command to enable support for draft extensions.
It seems reasonable to me.  The worst thing that happens is you find
it's not terribly better than what we're currently doing and we scramble
the process again to work better.

jeff

Re: Pytest usage in DejaGNU?

[Jeff Law via Gcc]

On 12/14/20 9:02 AM, Martin Liška wrote:
> Hello.
>
> GCOV tests suffer from tests that would cover the intermediate format.
> It's a JSON format and and I'm attaching an example of its output.
>
> I would really like to use Python to make more complex tests:
>
> $ cat test_json.py
> import pytest
> import json
>
> def test_gcov_output():
>     data = json.load(open('gcov.json'))
>     assert len(data['files']) == 1
>     f0 = data['files'][0]
>     assert f0['file'] == 'gcov-lambda.C'
>     assert len(f0['functions']) == 3
>
>     fns = {}
>     for fn in f0['functions']:
>     fns[fn['name']] = fn
>     lines = f0['lines']
>
>     for line in lines:
>     lineno = line['line_number']
>     linefn = line['function_name']
>     assert linefn in fns
>     fn = fns[linefn]
>     assert fn['start_line'] <= lineno and lineno <= fn['end_line']
>
> I see it pretty complicated to do the same in DejaGNU. Mainly due the
> missing
> JSON parser.
>
> Would it be possible to make optional Python tests in our testsuite?
> I can imagine a simple pytest wrapper that will do something like:
>
> +proc pytest-execute { dgargs } {
> +    verbose "dg-pytest-execute: ${dgargs}" 2
> +    set script [lindex $dgargs 0]
> +    verbose "  script: ${script}" 2
> +
> +    spawn -noecho pytest -rA -s --tb=no $script
> +
> +    expect {
> +  -re "FAILED .*" {
> +   fail "pytest $expect_out(0,string)"
> +  }
> +  -re "PASSED .*" {
> +   pass "pytest $expect_out(0,string)"
> +  }
> +    }
> +}
>
> as Pytest can provide a reasonable close output:
>
> ===
> short test summary info
> 
> PASSED test_json.py::test_gcov_output
> PASSED test_json.py::test_gcov_output
> PASSED test_json.py::test_gcov_output
I thought we already approved using python elsewhere (JIT?  Analyzer?)

jeff

Re: CC0 removal branch

[Jeff Law via Gcc]

On 12/15/20 10:27 AM, Segher Boessenkool wrote:
> Hi!
>
> I have updated my CC0 removal branch I started in 2019:
>   refs/users/segher/heads/cc0
> (yes I know this needs some patch series work; this branch rebases).
>
> I have tested it all on powerpc*, and sill test it with cross-compilers
> to all Linux targets later today.  I already know one problem that will
> run into: the h8300 port still uses cc0!  In peepholes, and also in
> h8300.c (cc0_rtx).  All that is dead code I bet, but that still doesn't
> compile if CC0 is removed ;-)
It's dead code.  The peepholes a shouldn't be included by the main .md
file.  I've got a partial conversion of those here.  Still lots of
cleanup and improvements queued up.  Don't let anything H8 related get
in the way :-)  If it breaks, I'll take care of it.


jeff

Re: Copyright assignment for Rust-GCC

[Jeff Law via Gcc]

On 1/4/21 3:28 AM, Nala Ginrut via Gcc wrote:
> Hi Folks!
> This mail is about the development of Rust frontend of GCC.
>
> To avoid misunderstanding, please let me introduce Rust-GCC briefly.
> In 2013, Philip Herron had announced the project in GCC mailing-list:
> https://gcc.gnu.org/legacy-ml/gcc/2013-12/msg00017.html
> In 2019, @SimplyTheOther had contributed the almost complete parser and
> AST.
> And I helped to do some trival work to make it work with the latest GCC
> at that time.
> Of course there're more contributors that I can't mention one by one.
> At that time, a small community of Rust-GCC had formed. We're interested
> in continuing it till it can be merged into GCC.
> https://github.com/Rust-GCC/gccrs
> So this is the brief history.
>
> Now we have a question, when should we assign copyright paper for GNU?
As soon as possible.

> Last time I assigned the copyright paper, I noticed that the paper
> mentioned the project name. But Rust-GCC hasn't been recogonized by GCC
> community yet, so I'm not sure if it's the correct time to consider this
> issue.
ISTM that the assignment should be for "gcc" since presumably the final
goal is to get the Rust front-end integrated into GCC, right?

jeff

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

[Jeff Law via Gcc]

On 1/4/21 3:23 AM, Salah Mosbah via Gcc wrote:
> Hi Janus,
>
> How can I report some high impact security vulnerabilities that I have
> found on gnu.org
> web app?
>
> Also, does gnu.org has a bug bounty program or reporting bugs reward policy?
>
> The vulnerabilities that I have found affects the core API of gnu.org which
> allows unauthorized users to get access to other user's data that they
> don't have access to it.
For gnu.org you'd need to contact the administrators of that domain,
which presumably you find contact information for on www.gnu.org.

If it's a problem with gcc.gnu.org, then the details should be sent to
overse...@gcc.gnu.org

Jeff

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

[Jeff Law via Gcc]

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

Re: gengtype and automatically generated files

[Jeff Law via Gcc]

On 1/4/21 10:40 AM, Bill Schmidt via Gcc wrote:
> Hi!  I'm attempting to do something that may not have been done
> before, so I'm looking for advice, or a pointer to where, in fact, it
> has been done before. :)
>
> I'm automatically generating a back-end header file that declares some
> structures that include trees, and a bunch of global variables that
> are also trees.  I've marked everything up appropriately, but I also
> need to teach the garbage collector that this file exists.
>
> Most back-end files are automatically scanned by gengtype.  Per the
> documentation, anything that isn't handled automatically needs to be
> added to target_gtfiles in config.gcc.  However, I can't come up with
> a syntax for describing a file in the gcc/ build subdirectory.  Some
> places in config.gcc allow "./filename" as shorthand for "filename"
> being in the current build directory, but that doesn't seem to work
> for adding something to gtyp-input.list.
>
> Any recommendations on what I should do next?  At the moment it looks
> like I might have to hack on gengtype to invent a way to scan a file
> in the build directory, but I have a mild amount of hope that someone
> has solved this before.  Thanks for any help!
Yea, I don't see any indication this has ever been done before.  I'm a
bit surprised that ./ doesn't work since gengtype runs from
the build directory and has to reference things in the source directory
and ./ would seem to naturally reference the build directory

Jeff

Re: Copyright assignment for Rust-GCC

[Jeff Law via Gcc]

On 1/4/21 11:01 PM, Eric Gallager via Gcc wrote:
> On Mon, Jan 4, 2021 at 11:13 AM David Edelsohn via Gcc 
> wrote:
>
>> On Mon, Jan 4, 2021 at 5:29 AM Nala Ginrut via Gcc 
>> wrote:
>>> Hi Folks!
>>> This mail is about the development of Rust frontend of GCC.
>>>
>>> To avoid misunderstanding, please let me introduce Rust-GCC briefly.
>>> In 2013, Philip Herron had announced the project in GCC mailing-list:
>>> https://gcc.gnu.org/legacy-ml/gcc/2013-12/msg00017.html
>>> In 2019, @SimplyTheOther had contributed the almost complete parser and
>>> AST.
>>> And I helped to do some trivial work to make it work with the latest GCC
>>> at that time.
>>> Of course there are more contributors that I can't mention one by one.
>>> At that time, a small community of Rust-GCC had formed. We're interested
>>> in continuing it till it can be merged into GCC.
>>> https://github.com/Rust-GCC/gccrs
>>> So this is the brief history.
>>>
>>> Now we have a question, when should we assign copyright paper for GNU?
>>> Last time I assigned the copyright paper, I noticed that the paper
>>> mentioned the project name. But Rust-GCC hasn't been recognized by GCC
>>> community yet, so I'm not sure if it's the correct time to consider this
>>> issue.
>>>
>>> Comments are welcome.
>> As Jeff wrote, the assignment is for the GNU Compiler Collection (GCC)
>> project, not for specific languages.  One does /not/ submit separate
>> assignments for GNU Fortran, GNU C++, GNU Go, GNU Ada, GNU Modula2,
>> etc.
>>
>>
> Speaking of Modula2, has that frontend made it into mainline GCC yet? I see
> there was a bugzilla component for it added, but I don't remember seeing
> anything about it in the changes.html file for any existing releases...
No.  I haven't seen anyone even trying in a while.

jeff

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

[Jeff Law via Gcc]

On 1/8/21 10:39 AM, Bruce Korb via Gcc wrote:
> Hi,
>
> You are supposed to be able to post once you've subscribed.
>
> Also, GCC's code analysis is wrong. "name_bf" contains *NO MORE* than
> MAXNAMELEN characters. That is provable.
>
> "def_str" points into a buffer of size ((MAXNAMELEN * 2) + 8) and at
> an offset maximum of MAXNAMELEN+1 (also provable), meaning that at a
> minimum there are MAXNAMELEN+6 bytes left in the buffer.
>
> That objected-to sprintf can add a maximum of MAXNAMELEN + 4 to where
> "def_str" points.
>
> GCC is wrong. It is unable to figure out how far into the buffer
> "def_str" can point.
Can you get a .i file, command line and file a report.  It'd be appreciated.

jeff

Re: Reporting a typo in gfortran intrinsic procedure webpage

[Jeff Law via Gcc]

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


Jeff
commit 34215a7a3a359d700a520f1d5bdaec835f0b5180
Author: Jeff Law 
Date:   Wed Feb 3 15:01:19 2021 -0700

Fix typo in Fortran manual

gcc/fortran:
* intrinsic.texi (ANINT): Fix typo.

diff --git a/gcc/fortran/intrinsic.texi b/gcc/fortran/intrinsic.texi
index 5debe94773b..63416bce7fd 100644
--- a/gcc/fortran/intrinsic.texi
+++ b/gcc/fortran/intrinsic.texi
@@ -1232,7 +1232,7 @@ end program test_anint
 @item @emph{Specific names}:
 @multitable @columnfractions .20 .20 .20 .25
 @item Name@tab Argument @tab Return type  @tab Standard
-@item @code{AINT(A)}  @tab @code{REAL(4) A} @tab @code{REAL(4)}   @tab Fortran 
77 and later
+@item @code{ANINT(A)}  @tab @code{REAL(4) A} @tab @code{REAL(4)}   @tab 
Fortran 77 and later
 @item @code{DNINT(A)} @tab @code{REAL(8) A} @tab @code{REAL(8)}   @tab Fortran 
77 and later
 @end multitable
 @end table

David Malcolm as GCC static analyzer maintainer

[Jeff Law via Gcc]

I am pleased to announce that the GCC Steering Committee has appointed 
David Malcolm as maintainer of the GCC static analyzer.



David, please update your listing in the MAINTAINERS file.


Thanks,


Jeff

Dimitar Dimitrov as TI PRU maintainer

[Jeff Law via Gcc]

I am pleased to announce that the GCC Steering Committee has appointed 
Dimitar Dimitrov as maintainer of the TI PRU port in GCC.



Dimitar, please update your listing in the MAINTAINERS file. Sorry it's 
taken so long to make this happen.  It just kept slipping off my radar.



Thanks,

Jeff

Re: Remove RMS from the GCC Steering Committee

[Jeff Law via Gcc]

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


To those who have crossed the line (no, I'm not going to call them out 
by name) -- please tone things done.  We have a long history here of not 
banning individuals from posting and I don't want to see this discussion 
escalate to the point where we're forced to take what I would consider 
drastic measures.


To those on the receiving end, I'm terribly sorry that some people can't 
disagree in a civil manner and I hope their behavior does not discourage 
you from continuing to contribute to GCC.


Jeff

Re: Remove RMS from the GCC Steering Committee

[Jeff Law via Gcc]

On 3/27/2021 2:49 PM, Martin Liška wrote:

On 3/26/21 9:02 PM, Nathan Sidwell wrote:
Dear members of the GCC Steering Committee (SC),  I ask you to remove 
Richard Stallman (RMS)


I do fully support Nathan's request.


Speaking strictly for myself, not as a representative of the steering 
committee or Tachyum, I also fully support Nathan's request.



jeff

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

[Jeff Law via Gcc]

On 3/31/2021 5:11 PM, Giacomo Tesio wrote:


10 out of 13 members of the GCC steering committee work either for
American corporations (8), their subsidiaries (1) or an American
University (1) recently covered by the press in India [3].
Also, 4 of these work for the same corporation (IBM / Red Hat).


Actually, it's just 3 working for IBM/Red Hat.  My affiliation changed 
earlier this month.  I've updated the page appropriately.





The other 3 are from German GmbH (2) or from a Nederlands public agency.


To me, and to billions of people, this shows a huge cultural bias.


It's more historical than anything.  The majority of members on the 
committee were there since its inception back in the late 90s.  We are 
looking at how to increase diversity on the committee, but that's a 
separate and distinct issue from removal of RMS.



Jeff

Re: GCC association with the FSF

[Jeff Law via Gcc]

On 4/7/2021 11:17 AM, Jonathan Wakely via Gcc wrote:

On Wed, 7 Apr 2021 at 15:04, David Malcolm wrote:

For myself, I'm interested in copyleft low-level tools being used to
build a Free Software operating system, but the "GNU" name may be
permanently tarnished for me; I have no wish to be associated with a
self-appointed "chief GNUisance".  I hope the FSF can be saved, since
it would be extremely inconvenient to have to move.

This matches my feelings. If the FSF can be saved, fine, but I don't
think GCC needs to remain associated with it.

If the GNU name is a problem, rename the projects to be simply "GCC",
"Glibc", "GDB" etc without being an initialism.


Speaking strictly for myself, that works for me as well and I'd support 
such a proposal.



jeff

Re: Default debug format for AVR

[Jeff Law via Gcc]

On 4/8/2021 8:06 AM, Simon Marchi via Gcc wrote:

On 2021-04-08 9:11 a.m., David Edelsohn wrote:

AIX continues to use and support STABS, although it is transitioning
to DWARF.  If this is intended as a general statement about removal of
STABS support in GCC,

Yes, it is.

Richard.

Richard,

It is inappropriate to unilaterally make this decision without
discussion with all affected ports and maintainers, without warning,
and without deprecation.  I request that you rescind this decision.

It is somewhat ironic to act as a dictator when we are having a
discussion about dictatorial behavior in GCC leadership.

I don't really want to start such a debate about GCC politics.  If stabs
is not ready to be deleted, that's fine.  But it would be good to go
through all targets for which it is the default (like avr), and see if
they are ready to be switched to DWARF.  That's a baby step towards
eventually deleting it.


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



jeff

Re: GCC association with the FSF

[Jeff Law via Gcc]

On 4/13/2021 12:01 AM, Richard Biener via Gcc wrote:

On Mon, Apr 12, 2021 at 11:24 PM Nathan Sidwell  wrote:

On 4/12/21 5:32 AM, Richard Biener via Gcc wrote:


Please concentrate on the important things, we're supposed to get a
release of GCC 11 out of the door.

Then it is important this is resolved.

Maybe - but it is very apparent that the current "discussion" will lead nowhere.


I would disagree with that Richi.  While there are elements in this 
discussion that are unhelpful, the overall question about GCC 
association with the FSF and GNU is a good one to be working through.



An EGCS-like split like we had in the late 90s is, IMHO, a definite 
possibility here and judging the mood of the GCC development community 
is vital to guiding decisions we need to make as a project.


Jeff





.  Without strong support from the development community splits like 
that aren't likely to be successful.  And to be clear, what *I* will be 
looking at is how those doing the real work respond, not the ramblings 
of folks who

Re: Default debug format for AVR

[Jeff Law via Gcc]

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

I am not requesting a continuation of support for STABS to be
obstinate.  AIX has some support for DWARF, but STABS continues to be
the primary debug format on AIX.  Binutils does not fully function on
AIX and the AIX native tools support for DWARF is incomplete.  Also,
AIX uses XCOFF file format, not ELF, so DWARF syntax needs to be
adapted and all of the tools need to agree on the way that AIX symbols
are represented in DWARF.


Just to be clear, I didn't think you were being obstinate at all.  I was 
just pointing out that I think the other ports can and probably should 
change now (well, start of gcc-12 cycle), but that AIX can't yet.


Jeff

Re: GCC association with the FSF

[Jeff Law via Gcc]

On 4/13/2021 10:52 AM, Thomas Koenig wrote:

On 13.04.21 16:40, Jeff Law via Gcc wrote:
An EGCS-like split like we had in the late 90s is, IMHO, a definite 
possibility here


Such a move would, in all probability, leave both parts of the split
GCC with too few developers to compete against LLVM, thus rendering
GCC irrelevant and ruining an important project for free software.

(I don't like the idea, for the record).


I'm not sure there'll be that much of a community split.  Based on what 
I've seen *so far* it'd be less of a split than we had with EGCS.  But 
that's precisely why I want folks to chime in, particularly those doing 
the day-to-date development work -- I want to see what the likely impact 
on the development community would be rather than going with just what 
*I* want.



jeff

Re: GCC association with the FSF

[Jeff Law via Gcc]

On 4/13/2021 11:32 AM, Thomas Koenig via Gcc wrote:


On 13.04.21 19:19, Jeff Law via Gcc wrote:
I'm not sure there'll be that much of a community split.  Based on 
what I've seen *so far* it'd be less of a split than we had with 
EGCS.  But that's precisely why I want folks to chime in, 
particularly those doing the day-to-date development work -- I want 
to see what the likely impact on the development community would be 
rather than going with just what *I* want.


If such a split were to occur, it would probably cost you gfortran.
We're in a precarious situation as is.


Hmm, I'm not following gfortran closely.  Is there a reason to believe 
that the gfortran developers would split across the two projects?  If 
so, that's a significant issue.  If you've got a pointer to a 
discussion, I'm happy to take it and read up on things.





So, goodbye to SPEC for both branches in the medium term.


That depends, of course.


Jeff

Re: removing toxic emailers

[Jeff Law via Gcc]

On 4/14/2021 8:08 AM, Nathan Sidwell wrote:

On 4/14/21 9:18 AM, Eric S. Raymond wrote:

Nathan Sidwell :
Do we have a policy about removing list subscribers that send 
abusive or
other toxic emails?  do we have a code of conduct?  Searching the 
wiki or

website finds nothing.  The mission statement mentions nothing.


I'm not a GCC insider, but I know a few things about the social
dynamics of voluntarist subcultures. You might recall I wrote a book
about that once.

The choice to have a policy for ejecting jerks has serious costs.
One of those costs is the kind of rancorous dispute that has been
burning like a brushfire on this list the last few weeks. Another,
particularly serious for hackers - is that such a policy is hostile to
autists and others who have poor interaction skills but can ship good
code.  This is a significant percentage of your current and future
potential contributors, enough that excluding them is a real problem.

Most seriously: the rules, whatever they are, will be gamed by people
whose objectives are not "ship useful software". You will be fortunate
if the gamers' objectives are as relatively innocuous as "gain points
in monkey status competition by beating up funny-colored monkeys";
there are much worse cases that have been known to crash even projects
with nearly as much history and social inertia as this one.

Compared to these costs, the overhead of tolerating a few jerks and
assholes is pretty much trivial.  That's hard to see right now because
the jerks are visible and the costs of formal policing are
hypothetical, but I strongly advise you against going down the Code of
Conduct route regardless of how fashionable that looks right now.  I
have forty years of observer-participant anthropology in intentional
online communities, beginning with the disintegration of the USENET
cabal back in the 1980s, telling me that will not end well.

You're better off with an informal system of moderator fiat and
*without* rules that beg to become a subject of dispute and
manipulation. A strong norm about off-list behavior and politics being
out of bounds here is also helpful.

You face a choice between being a community that is about shipping code
and one that is embroiled in perpetual controversy over who gets to
play here and on what terms.  Choose wisely.



I'd just like to eject the jerks, because they make the place 
unwelcoming.  I wouldn't associate with them in physical space, I 
don't want to associate with them here.  And yes, I fully realize 
there are other ways I can choose to not associate with them here.


We've generally avoided kicking folks off the lists -- it's been done 
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.


Jeff

Re: GCC association with the FSF

[Jeff Law via Gcc]

On 4/14/2021 6:08 AM, Richard Biener via Gcc wrote:

On April 14, 2021 12:19:16 PM GMT+02:00, Jonathan Wakely via Gcc 
 wrote:

N.B. Jeff is no longer @redhat.com so I've changed the CC

On Wed, 14 Apr 2021 at 11:03, Thomas Koenig 
wrote:

- All gfortran developers move to the new branch.  This will not
happen, I can guarantee you that.

This is the part I'm curious about (the rest is obvious, it follows

>from there being finite resources and the nature of any fork). But I'm

not going to press for reasons.

Note the only viable fork will be on the current hosting (which isn't FSF controlled) 
with the downside of eventually losing the gcc.gnu.org DNS and thus a need to 
"switch" to a sourceware.org name.
I strongly suspect you're right here.  Ultimately if one fork reaches 
critical mass, then it survives and the other dies.  That's a function 
of the developer community.   Right now I don't see the nightmare 
scenario of both forks being viable playing out -- however I'm more 
concerned now than I was before due Thomas's comments.





Given there would be actual work involved on the FSF side to keep a "fork" with 
the exact same setup (and thus transparent with existing setups) I don't see it keeping 
live (but I see somebody populating savannah with sources).


Absolutely.  I could even see a small community continuing to push the 
FSF fork for a while until it becomes abundantly clear that only one 
fork is long term viable.  That's what happened with EGCS -- the 
majority of the developer community went with the EGCS fork with a small 
community staying on the FSF fork.  Eventually it became clear that EGCS 
had much broader developer support and the FSF fork ultimately withered 
away.



Jeff

Re: removing toxic emailers

[Jeff Law via Gcc]

On 4/14/2021 8:49 AM, Jonathan Wakely via Gcc wrote:

On Wed, 14 Apr 2021 at 15:39, Thomas Koenig wrote:

On 14.04.21 15:18, Eric S. Raymond wrote:

A strong norm about off-list behavior and politics being
out of bounds here is also helpful.

That would have banned the whole discussion about the potential
fork from the start.

No, because once again, I raised the topic of a fork because I do not
feel that association with GNU or FSF benefits the GCC project. I did
not say "we have to cancel them because I don't like their politics"
(as it happens, I do like their politics, which is why I've spent two
decades writing copyleft code for GCC, I just think they have failed
to evolve and are sadly irrelevant today).


[ Speaking for myself, not the steering committee or my employer... ]


Well said (and I'm not being sarcastic).  While my politics may not line 
up 100% with those of the FSF, GNU project or RMS, they have been close 
enough for me to spend 30+ years of my life working on GNU tools.  I 
agree with you Jon that the organizations and RMS personally have failed 
to evolve -- and I'll go a step further than you did in this message and 
state that, IMHO, they are actively harmful to GCC and the free software 
movement in general.



I don't relish the idea of forking GCC again.  Been there, done that, it 
was painful.  But again, I think we're at a point where it's necessary 
again.



Jeff

Re: GCC association with the FSF

[Jeff Law via Gcc]

On 4/14/2021 10:55 AM, Christopher Dimech wrote:

Sent: Thursday, April 15, 2021 at 4:35 AM
From: "Toon Moene" 
To: "Jeff Law" , "Richard Biener" , "Jonathan Wakely" 
, "Jonathan Wakely via Gcc" , "Thomas Koenig" 
Subject: Re: GCC association with the FSF

On 4/14/21 6:18 PM, Jeff Law via Gcc wrote:


On 4/14/2021 6:08 AM, Richard Biener via Gcc wrote:

On April 14, 2021 12:19:16 PM GMT+02:00, Jonathan Wakely via Gcc
 wrote:

N.B. Jeff is no longer @redhat.com so I've changed the CC
On Wed, 14 Apr 2021 at 11:03, Thomas Koenig 
wrote:

- All gfortran developers move to the new branch.  This will not
     happen, I can guarantee you that.

This is the part I'm curious about (the rest is obvious, it follows

>from there being finite resources and the nature of any fork). But I'm

not going to press for reasons.

Note the only viable fork will be on the current hosting (which isn't
FSF controlled) with the downside of eventually losing the gcc.gnu.org
DNS and thus a need to "switch" to a sourceware.org name.

I strongly suspect you're right here.  Ultimately if one fork reaches
critical mass, then it survives and the other dies.  That's a function
of the developer community.   Right now I don't see the nightmare
scenario of both forks being viable playing out -- however I'm more
concerned now than I was before due Thomas's comments.

When plans for the EGCS were underway, and the (then) Fortran supporters
were into the plans, it scared the hell out of me, because it was
completely unclear to me where it would end.

But in the end: I am a supporter of Free Software, not a organization,
or a person, but *developers* who support Free Software.

That's what got me to go for the fork of EGCS - and I have not been
disappointed.

--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands

The two projects once again united because multiple forks are proved to be
inefficient and unwieldy.   As long as the license terms for free software
are met and there is compatibility, I am pleased.


Umm, no.  The projects re-united because the FSF fork wasn't viable and 
we structured EGCS so that if it was successful it could supplant the 
FSF fork.  Toon, myself and others were part of that process.



jeff

Re: removing toxic emailers

[Jeff Law via Gcc]

On 4/14/2021 2:39 PM, Ian Lance Taylor wrote:

On Wed, Apr 14, 2021 at 9:08 AM Jeff Law via Gcc  wrote:

once or twice when physical violence with threatened, but that's about
it (aside from spammers).  I don't think we want to get too deep into
moderation and the like -- IMHO it 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?

(I'm raising this as a kind of first principle.  If there is a system
for banning people from the list, there are various things to discuss
as to how that might work.  And I've seen it work effectively in other
communities.  But if we don't agree on that first principle, there is
no point to continuing.)


It's been a long time, but I think when we've banned someone it's been 
through the steering committee.


But yes, I understand your point and it's a good one and I think we can 
probably find some common ground there -- but even so I think banning 
should be a rare event and some official outreach to the offender should 
happen first.



jeff

Re: removing toxic emailers

[Jeff Law via Gcc]

On 4/15/2021 2:26 PM, Chris Punches via Gcc wrote:

What I see here in sum is another high level tightly integrated Red Hat
employee saying the gist of "I'm really not saying it out of my
employer's interest and it has nothing to do with my personal
feelings".

Every single proponent of this argument that I have seen so far is
employed by one of the same 5 companies and "really isn't doing it on
behalf of my company I swear".

Why is it almost exclusively that specific crowd saying it here, then?

I just don't buy it.  Please say anything that would not support the
emerging theory that these companies are using integrated employees to
try to emulate justification/pretext for a rift to attack the free
software world.  Anything at all.


[ Again, speaking or myself, not my employer or for the steering 
committee. ]



So first, my employer (Tachyum) has had absolutely no clue what's going 
on with this discussion until yesterday afternoon when I mentioned it in 
passing.  We're much more focused on getting our bits where they need to 
be rather than policy, procedures and politics of the upstream 
projects.  However they have repeatedly, up to the CEO level emphasized 
that upstreaming our work and being good players in the various relevant 
communities is important and the various concerns I raised around that 
prior to joining were answered to my satisfaction.



Second, I was the technical lead for Red Hat's tools team until about a 
month ago.  I've also held management positions in Red Hat (and Cygnus 
prior to the acquisition) during my 25+ year career there.  Red Hat and 
Cygnus have consistently worked through the years to be good stewards 
for the GNU tools.  Management  has consistently had a hands-off 
approach to the upstream community, allowing engineers to exercise their 
own judgment on if when and how to engage in various discussions.  The 
only time management got involved in these kinds of discussions was to 
throw support behind EGCS -- including being supportive of bringing in 
outside advisors for what ultimately became the steering committee.



You may not buy it, but that's OK.   That's ultimately your decision to 
make.



I do buy it.  It's consistent with what I've seen over nearly three 
decades of dealing with GNU tools and what I've *directly observed* as 
part of the leadership and management teams.



Jeff

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

[Jeff Law via Gcc]

On 4/16/2021 9:57 AM, Thomas Koenig via Gcc wrote:

Hello world,

realising that my e-mails may have done more harm than good,
I will now unsubscribe from the gcc mailing list, so please
don't expect a reply unless you copy me in.


I don't think your emails have done any harm.  I find them quite 
valuable, so I'm sad to see you dropping yourself from the gcc@ list.



jeff

Re: removing toxic emailers

[Jeff Law via Gcc]

On 4/16/2021 10:08 PM, Frosku wrote:

On Sat Apr 17, 2021 at 5:05 AM BST, Ian Lance Taylor wrote:

On Fri, Apr 16, 2021 at 4:16 PM Frosku  wrote:

When I refer to a 'California cultural standard', that's not prescriptive. It's
just a reference to the fact that a *lot* of the SC live in California, and any
culture prescribed by the steering committee will be overly influenced by that
commonality.

To the best of my knowledge, 2 of the 13 members of the GCC steering
committee live in California.

Ian

And the rest of the west coast United States / New England?


I'm not aware of anywhere in the US that is a monoculture in the way you 
seem to be implying.  And if you really believe there are those kinds of 
monocultures , then you're showing a high degree of ignorance.


FTR, I've never resided on the west coast of the US or in the 
traditionally defined New England states.



Jeff

Re: Can I push code to GCC?

[Jeff Law via Gcc]

On 5/10/2021 7:01 AM, juzhe.zh...@rivai.ai wrote:

Hi, I am a compiler engineer base on GCC in China. Recently, I develop a new pattern 
for vector widen multiply-accumulator(I call it widen fma) because the ISA in my 
project has the instruction (vwmacc). I develop a lot of code especiallly frontend 
(gimple&&generic) int GCC. This is useful for my project, but I am not sure 
whether it is useful for GCC overall. Can I deliver the code?  And maybe you guys can 
check my code and refine it to have a better quality. Thank you!


The process for contributing code is to post the patch to the 
gcc-patches mailing list for design/implementation review.  For new 
contributors, if the patch is acceptable, someone will commit it for 
you.  Over time if you make several contributions, then we'll set you up 
with write access to the repository.



jeff

Re: Update to GCC copyright assignment policy

[Jeff Law via Gcc]

On 6/1/2021 5:22 PM, Eric Gallager via Gcc wrote:

On Tue, Jun 1, 2021 at 10:02 AM David Edelsohn via Gcc  wrote:

GCC was created as part of the GNU Project but has grown to operate as
an autonomous project.

The GCC Steering Committee has decided to relax the requirement to
assign copyright for all changes to the Free Software Foundation.  GCC
will continue to be developed, distributed, and licensed under the GNU
General Public License v3.0. GCC will now accept contributions with or
without an FSF copyright assignment. This change is consistent with
the practices of many other major Free Software projects, such as the
Linux kernel.

Contributors who have an FSF Copyright Assignment don't need to
change anything.  Contributors who wish to utilize the Developer Certificate
of Origin[1] should add a Signed-off-by message to their commit messages.
Developers with commit access may add their name to the DCO list in the
MAINTAINERS file to certify the DCO for all future commits in lieu of individual
Signed-off-by messages for each commit.

The GCC Steering Committee continues to affirm the principles of Free
Software, and that will never change.

- The GCC Steering Committee

[1] https://developercertificate.org/

One thing I'm wondering about this change is if it allows certain old
changes that previously couldn't be upstreamed to now be upstreamed?
For example, when I have asked about trying to forward-port certain
changes from Apple's old gcc-4.2 branch, I was told that one reason
this couldn't happen was because Apple hadn't assigned copyright for
those changes. Of course, there are still the technical difficulties
of the fact that 4.2 has bitrotted considerably in the years since its
last release, but regardless of those, are the legal difficulties at
least now out of the way?
Read the DCO.   If you can satisfy the terms of the DCO, then yes it 
would help.  But DCO still has requirements that may not be easily met 
unless you are the author or know the author and can communicate with them.


jeff

Re: replacing the backwards threader and more

[Jeff Law via Gcc]

On 6/9/2021 9:34 AM, Aldy Hernandez wrote:



On 6/9/21 2:09 PM, Richard Biener wrote:
On Wed, Jun 9, 2021 at 1:50 PM Aldy Hernandez via Gcc 
 wrote:


Hi Jeff.  Hi folks.

What started as a foray into severing the old (forward) threader's
dependency on evrp, turned into a rewrite of the backwards threader
code.  I'd like to discuss the possibility of replacing the current
backwards threader with a new one that gets far more threads and can
potentially subsume all threaders in the future.

I won't include code here, as it will just detract from the high level
discussion.  But if it helps, I could post what I have, which just 
needs

some cleanups and porting to the latest trunk changes Andrew has made.

Currently the backwards threader works by traversing DEF chains through
PHIs leading to possible paths that start in a constant.  When such a
path is found, it is checked to see if it is profitable, and if so, the
constant path is threaded.  The current implementation is rather 
limited

since backwards paths must end in a constant.  For example, the
backwards threader can't get any of the tests in
gcc.dg/tree-ssa/ssa-thread-14.c:

    if (a && b)
  foo ();
    if (!b && c)
  bar ();

etc.

After my refactoring patches to the threading code, it is now possible
to drop in an alternate implementation that shares the profitability
code (is this path profitable?), the jump registry, and the actual jump
threading code.  I have leveraged this to write a ranger-based threader
that gets every single thread the current code gets, plus 90-130% more.

Here are the details from the branch, which should be very similar to
trunk.  I'm presenting the branch numbers because they contain Andrew's
upcoming relational query which significantly juices up the results.

New threader:
   ethread:65043    (+3.06%)
   dom:32450  (-13.3%)
   backwards threader:72482   (+89.6%)
   vrp:40532  (-30.7%)
    Total threaded:  210507 (+6.70%)

This means that the new code gets 89.6% more jump threading
opportunities than the code I want to replace.  In doing so, it reduces
the amount of DOM threading opportunities by 13.3% and by 30.7% from 
the

VRP jump threader.  The total  improvement across the jump threading
opportunities in the compiler is 6.70%.

However, these are pessimistic numbers...

I have noticed that some of the threading opportunities that DOM and 
VRP

now get are not because they're smarter, but because they're picking up
opportunities that the new code exposes.  I experimented with 
running an
iterative threader, and then seeing what VRP and DOM could actually 
get.

   This is too expensive to do in real life, but it at least shows what
the effect of the new code is on DOM/VRP's abilities:

    Iterative threader:
  ethread:65043    (+3.06%)
  dom:31170    (-16.7%)
  thread:86717    (+127%)
  vrp:33851    (-42.2%)
    Total threaded:  216781 (+9.90%)

This means that the new code not only gets 127% more cases, but it
reduces the DOM and VRP opportunities considerably (16.7% and 42.2%
respectively).   The end result is that we have the possibility of
getting almost 10% more jump threading opportunities in the entire
compilation run.


Yeah, DOM once was iterating ...

You probably have noticed that we have very man (way too many)
'thread' passes, often in close succession with each other or
DOM or VRP.  So in the above numbers I wonder if you can break
down the numbers individually for the actual passes (in their order)?


Sure, I can do that.  Let me whip up the old branch and gather some info.
I'll save you some time.  The jump threaders in VRP are doing the least 
amount of lifting and the ones we want to kill first.  IIRC the one from 
vrp2 is doing nearly nothing at this point.



Jeff

Re: replacing the backwards threader and more

[Jeff Law via Gcc]

On 6/9/2021 2:39 PM, Aldy Hernandez wrote:



On 6/9/21 9:47 PM, Jeff Law wrote:



On 6/9/2021 9:34 AM, Aldy Hernandez wrote:



On 6/9/21 2:09 PM, Richard Biener wrote:
On Wed, Jun 9, 2021 at 1:50 PM Aldy Hernandez via Gcc 
 wrote:


Hi Jeff.  Hi folks.

What started as a foray into severing the old (forward) threader's
dependency on evrp, turned into a rewrite of the backwards threader
code.  I'd like to discuss the possibility of replacing the current
backwards threader with a new one that gets far more threads and can
potentially subsume all threaders in the future.

I won't include code here, as it will just detract from the high 
level
discussion.  But if it helps, I could post what I have, which just 
needs
some cleanups and porting to the latest trunk changes Andrew has 
made.


Currently the backwards threader works by traversing DEF chains 
through

PHIs leading to possible paths that start in a constant. When such a
path is found, it is checked to see if it is profitable, and if 
so, the
constant path is threaded.  The current implementation is rather 
limited

since backwards paths must end in a constant.  For example, the
backwards threader can't get any of the tests in
gcc.dg/tree-ssa/ssa-thread-14.c:

    if (a && b)
  foo ();
    if (!b && c)
  bar ();

etc.

After my refactoring patches to the threading code, it is now 
possible

to drop in an alternate implementation that shares the profitability
code (is this path profitable?), the jump registry, and the actual 
jump
threading code.  I have leveraged this to write a ranger-based 
threader
that gets every single thread the current code gets, plus 90-130% 
more.


Here are the details from the branch, which should be very similar to
trunk.  I'm presenting the branch numbers because they contain 
Andrew's

upcoming relational query which significantly juices up the results.

New threader:
   ethread:65043    (+3.06%)
   dom:32450  (-13.3%)
   backwards threader:72482   (+89.6%)
   vrp:40532  (-30.7%)
    Total threaded:  210507 (+6.70%)

This means that the new code gets 89.6% more jump threading
opportunities than the code I want to replace.  In doing so, it 
reduces
the amount of DOM threading opportunities by 13.3% and by 30.7% 
from the

VRP jump threader.  The total  improvement across the jump threading
opportunities in the compiler is 6.70%.

However, these are pessimistic numbers...

I have noticed that some of the threading opportunities that DOM 
and VRP
now get are not because they're smarter, but because they're 
picking up
opportunities that the new code exposes.  I experimented with 
running an
iterative threader, and then seeing what VRP and DOM could 
actually get.
   This is too expensive to do in real life, but it at least shows 
what

the effect of the new code is on DOM/VRP's abilities:

    Iterative threader:
  ethread:65043    (+3.06%)
  dom:31170    (-16.7%)
  thread:86717    (+127%)
  vrp:33851    (-42.2%)
    Total threaded:  216781 (+9.90%)

This means that the new code not only gets 127% more cases, but it
reduces the DOM and VRP opportunities considerably (16.7% and 42.2%
respectively).   The end result is that we have the possibility of
getting almost 10% more jump threading opportunities in the entire
compilation run.


Yeah, DOM once was iterating ...

You probably have noticed that we have very man (way too many)
'thread' passes, often in close succession with each other or
DOM or VRP.  So in the above numbers I wonder if you can break
down the numbers individually for the actual passes (in their order)?


Sure, I can do that.  Let me whip up the old branch and gather some 
info.
I'll save you some time.  The jump threaders in VRP are doing the 
least amount of lifting and the ones we want to kill first. IIRC the 
one from vrp2 is doing nearly nothing at this point.


Sure, that was going to be my next target.

What are your thoughts on replacing the current backwards threader, 
though?  That's basically ready to go.

Going to take a deep dive into it Saturday.

Jeff

Re: replacing the backwards threader and more

[Jeff Law via Gcc]

On 6/9/2021 5:48 AM, Aldy Hernandez wrote:

Hi Jeff.  Hi folks.

What started as a foray into severing the old (forward) threader's 
dependency on evrp, turned into a rewrite of the backwards threader 
code.  I'd like to discuss the possibility of replacing the current 
backwards threader with a new one that gets far more threads and can 
potentially subsume all threaders in the future.


I won't include code here, as it will just detract from the high level 
discussion.  But if it helps, I could post what I have, which just 
needs some cleanups and porting to the latest trunk changes Andrew has 
made.


Currently the backwards threader works by traversing DEF chains 
through PHIs leading to possible paths that start in a constant. When 
such a path is found, it is checked to see if it is profitable, and if 
so, the constant path is threaded.  The current implementation is 
rather limited since backwards paths must end in a constant.  For 
example, the backwards threader can't get any of the tests in 
gcc.dg/tree-ssa/ssa-thread-14.c:


  if (a && b)
    foo ();
  if (!b && c)
    bar ();

etc.
Right.  And these kinds of cases are particularly interesting to capture 
-- not only do you remove the runtime test/compare, all the setup code 
usually dies as well.  I can't remember who, but someone added some bits 
to detect these cases in DOM a while back and while the number of 
additional jumps threaded wasn't great, the overall impact was much 
better than we initially realized.   Instead of allowign removal of a 
single compare/branch, it typically allowed removal of a chain of 
logicals that fed the conditional.




After my refactoring patches to the threading code, it is now possible 
to drop in an alternate implementation that shares the profitability 
code (is this path profitable?), the jump registry, and the actual 
jump threading code.  I have leveraged this to write a ranger-based 
threader that gets every single thread the current code gets, plus 
90-130% more.

Sweet.



Here are the details from the branch, which should be very similar to 
trunk.  I'm presenting the branch numbers because they contain 
Andrew's upcoming relational query which significantly juices up the 
results.
Yea, I'm not surprised that the relational query helps significantly 
here.  And I'm not surprised that we can do much better with the 
backwards threader with a rewrite.


Much of the ranger design was with the idea behind using it in the 
backwards jump threader in mind.  Backwards threading is, IMHO, a much 
better way to think about the problem.  THe backwards threader also has 
a much stronger region copier -- so we don't have to live with the 
various limitations of the old jump threading approach.






New threader:
 ethread:65043    (+3.06%)
 dom:32450  (-13.3%)
 backwards threader:72482   (+89.6%)
 vrp:40532  (-30.7%)
  Total threaded:  210507 (+6.70%)

This means that the new code gets 89.6% more jump threading 
opportunities than the code I want to replace.  In doing so, it 
reduces the amount of DOM threading opportunities by 13.3% and by 
30.7% from the VRP jump threader.  The total  improvement across the 
jump threading opportunities in the compiler is 6.70%.
This looks good at first glance.  It's worth noting that the backwards 
threader runs before the others, so, yea, as it captures more stuff I 
would expect DOM/VRP to capture fewer things.    It would be interesting 
to know the breakdown of things caught by VRP1/VRP2 and how much of that 
is secondary opportunities that are only appearing because we've done a 
better job earlier.


And just to be clear, I expect that we're going to leave some of those 
secondary opportunities on the table -- we just don't want it to be too 
many :-)  When I last looked at this my sense was wiring the backwards 
threader and ranger together should be enough to subsume VRP1/VRP2 jump 
threading.




However, these are pessimistic numbers...

I have noticed that some of the threading opportunities that DOM and 
VRP now get are not because they're smarter, but because they're 
picking up opportunities that the new code exposes.  I experimented 
with running an iterative threader, and then seeing what VRP and DOM 
could actually get.  This is too expensive to do in real life, but it 
at least shows what the effect of the new code is on DOM/VRP's abilities:


  Iterative threader:
    ethread:65043    (+3.06%)
    dom:31170    (-16.7%)
    thread:86717    (+127%)
    vrp:33851    (-42.2%)
  Total threaded:  216781 (+9.90%)

This means that the new code not only gets 127% more cases, but it 
reduces the DOM and VRP opportunities considerably (16.7% and 42.2% 
respectively).   The end result is that we have the possibility of 
getting almost 10% more jump threading opportunities in the entire 
compilation run.


(Note that the new code gets even more opportunities, but I'm only 
reporting the profitable ones that made it 

Re: replacing the backwards threader and more

[Jeff Law via Gcc]

On 6/14/2021 12:40 AM, Richard Biener wrote:



I bet it's going to be tougher to remove DOM's threader.  It knows how
to do thinks like resolve memory references using temporary equivalences
and such.  But I bet it's enough to drop the VRP based threaders.

Yes.  In fact I am wondering if adding threading to the not iterating FRE
would make it possible to drop DOM, replacing it with instances of FRE.

I'd think so.  I'd approach as:

1. Remove the VRP threader instances.
2. Drop cprop and redundancy elimination from DOM using FRE instead
3. What's left of DOM is just forward jump threading.  Revamp & 
simplify.  Then either make it a distinct pass or as a sub-pass of FRE.


But one could just as easily look at adding threading to FRE and just 
killing DOM and its jump threading.


Jeff

Re: replacing the backwards threader and more

[Jeff Law via Gcc]

On 6/14/2021 11:39 PM, Aldy Hernandez wrote:



On 6/15/21 6:03 AM, Jeff Law wrote:



On 6/14/2021 12:40 AM, Richard Biener wrote:



I bet it's going to be tougher to remove DOM's threader.  It knows how
to do thinks like resolve memory references using temporary 
equivalences

and such.  But I bet it's enough to drop the VRP based threaders.
Yes.  In fact I am wondering if adding threading to the not 
iterating FRE

would make it possible to drop DOM, replacing it with instances of FRE.

I'd think so.  I'd approach as:

1. Remove the VRP threader instances.
2. Drop cprop and redundancy elimination from DOM using FRE instead
3. What's left of DOM is just forward jump threading.  Revamp & 
simplify.  Then either make it a distinct pass or as a sub-pass of FRE.


But one could just as easily look at adding threading to FRE and just 
killing DOM and its jump threading.


Andrew will hopefully be contributing the relational work this week. 
Once he does so, I will gather more granular stats for VRP1/VRP2 so we 
can assess the situation.


Also, a bunch of tests needed to be tweaked because the new code picks 
up so many threads.  I'm waiting for the relational work to avoid 
having to adjust the tests again.


I would personally prefer to add an item 0 to the above list: replace 
current backwards threader code with the rewrite.  I would hate to 
replace all threaders at once and deal with the fallout. Perhaps it's 
better to replace the backward threaders, and once that settles move 
onto VRP[12]??
Sorry, yes, there's a step #0, replace the backwards threader. Mentally 
I groups that with "Remove VRP threader instsances", but it's a distinct 
step and a prerequisite.


jeff

Aldy Hernandez and Andrew MacLeod as VRP maintainers

[Jeff Law via Gcc]

I am pleased to announce that the GCC Steering Committee has appointed 
Aldy Hernandez and Ian MacLeod as maintainers for the VRP subsystem 
(EVRP, VRP, Ranger).


Aldy/Andrew, please update the MAINTAINERS file appropriately.

Thanks,
jeff

Re: replacing the backwards threader and more

[Jeff Law via Gcc]

On 6/21/2021 8:40 AM, Aldy Hernandez wrote:



On 6/9/21 2:09 PM, Richard Biener wrote:
On Wed, Jun 9, 2021 at 1:50 PM Aldy Hernandez via Gcc 
 wrote:


Hi Jeff.  Hi folks.

What started as a foray into severing the old (forward) threader's
dependency on evrp, turned into a rewrite of the backwards threader
code.  I'd like to discuss the possibility of replacing the current
backwards threader with a new one that gets far more threads and can
potentially subsume all threaders in the future.

I won't include code here, as it will just detract from the high level
discussion.  But if it helps, I could post what I have, which just 
needs

some cleanups and porting to the latest trunk changes Andrew has made.

Currently the backwards threader works by traversing DEF chains through
PHIs leading to possible paths that start in a constant.  When such a
path is found, it is checked to see if it is profitable, and if so, the
constant path is threaded.  The current implementation is rather 
limited

since backwards paths must end in a constant.  For example, the
backwards threader can't get any of the tests in
gcc.dg/tree-ssa/ssa-thread-14.c:

    if (a && b)
  foo ();
    if (!b && c)
  bar ();

etc.

After my refactoring patches to the threading code, it is now possible
to drop in an alternate implementation that shares the profitability
code (is this path profitable?), the jump registry, and the actual jump
threading code.  I have leveraged this to write a ranger-based threader
that gets every single thread the current code gets, plus 90-130% more.

Here are the details from the branch, which should be very similar to
trunk.  I'm presenting the branch numbers because they contain Andrew's
upcoming relational query which significantly juices up the results.

New threader:
   ethread:65043    (+3.06%)
   dom:32450  (-13.3%)
   backwards threader:72482   (+89.6%)
   vrp:40532  (-30.7%)
    Total threaded:  210507 (+6.70%)

This means that the new code gets 89.6% more jump threading
opportunities than the code I want to replace.  In doing so, it reduces
the amount of DOM threading opportunities by 13.3% and by 30.7% from 
the

VRP jump threader.  The total  improvement across the jump threading
opportunities in the compiler is 6.70%.

However, these are pessimistic numbers...

I have noticed that some of the threading opportunities that DOM and 
VRP

now get are not because they're smarter, but because they're picking up
opportunities that the new code exposes.  I experimented with 
running an
iterative threader, and then seeing what VRP and DOM could actually 
get.

   This is too expensive to do in real life, but it at least shows what
the effect of the new code is on DOM/VRP's abilities:

    Iterative threader:
  ethread:65043    (+3.06%)
  dom:31170    (-16.7%)
  thread:86717    (+127%)
  vrp:33851    (-42.2%)
    Total threaded:  216781 (+9.90%)

This means that the new code not only gets 127% more cases, but it
reduces the DOM and VRP opportunities considerably (16.7% and 42.2%
respectively).   The end result is that we have the possibility of
getting almost 10% more jump threading opportunities in the entire
compilation run.


Yeah, DOM once was iterating ...

You probably have noticed that we have very man (way too many)
'thread' passes, often in close succession with each other or
DOM or VRP.  So in the above numbers I wonder if you can break
down the numbers individually for the actual passes (in their order)?


As promised.

*** LEGACY:
ethread42:61152 30.1369% (61152 threads for 30.1% of total)
thread117:29646 14.6101%
vrp118:62088 30.5982%
thread132:2232 1.09997%
dom133:31116 15.3346%
thread197:1950 0.960998%
dom198:10661 5.25395%
thread200:587 0.289285%
vrp201:3482 1.716%
Total:  202914


The above is from current trunk with my patches applied, defaulting to 
legacy mode.  It follows the pass number nomenclature in the 
*.statistics files.


New threader code (This is what I envision current trunk to look with 
my patchset):


*** RANGER:
ethread42:64389 30.2242%
thread117:49449 23.2114%
vrp118:46118 21.6478%
thread132:8153 3.82702%
dom133:27168 12.7527%
thread197:5542 2.60141%
dom198:8191 3.84485%
thread200:1038 0.487237%
vrp201:2990 1.40351%
Total:  213038
So this makes me think we should focus on dropping thread197, thread200, 
& vrp201 and I'd probably focus on vrp201 first since we know we want to 
get rid of it anyway and that may change the data for thread???.  Then 
I'd be looking at thread200 and thread197 in that order.  I suspect that 
at least some of the cases in thread200 and vrp201 are exposed by dom198.



Jeff

Re: Proper Place for builtin_define(__ELF__)

[Jeff Law via Gcc]

On 7/21/2021 6:31 PM, Michael Eager wrote:



On 7/21/21 5:22 PM, Joel Sherrill wrote:



On Wed, Jul 21, 2021, 7:12 PM Michael Eager > wrote:


    On 7/21/21 2:28 PM, Joel Sherrill wrote:
 > Hi
 >
 > We are in the process of porting RTEMS to the Microblaze and 
gcc does

 > not have __ELF__ as a predefine. In looking around at where to
    add it,
 > it looks like there are multiple ways to do it. We see 
variations on

 > the following patterns:
 >
 > + dbxelf.h
 > + OS specific header in config/
 > + Arch/OS specific header
 >
 > Integrating dbxelf.h into the microblaze seems risky for one 
simple

 > builtin_define(). Adding it to config/microblaze/rtems.h won't
    address
 > the microblaze-elf target.
 >
 > A suggestion on where to add the builtin_predefine is 
appreciated.


    There are very few defines for __ELF__ in the GCC target files.


Many  targets include dbxelf.h from the config.gcc script. There are 
130 references to that file there. That seems to be where most 
architectures get it.


AFAIK, no one has ever tried to build microblaze to generate stabs,
and I can't see a good reason why anyone would.  Including dbxelf.h
seems wrong.  I don't have an answer why other arch's do that.
Avoiding dbxelf would be advisable.  We're really only supporting stabs 
for for aix anymore.  We need to start excising dbxelf from all the 
places it's being used.


jeff

Re: Proper Place for builtin_define(__ELF__)

[Jeff Law via Gcc]

On 7/22/2021 8:12 AM, Joel Sherrill wrote:

On Wed, Jul 21, 2021 at 10:08 PM Jeff Law  wrote:



On 7/21/2021 6:31 PM, Michael Eager wrote:


On 7/21/21 5:22 PM, Joel Sherrill wrote:


On Wed, Jul 21, 2021, 7:12 PM Michael Eager mailto:ea...@eagercon.com>> wrote:

 On 7/21/21 2:28 PM, Joel Sherrill wrote:
  > Hi
  >
  > We are in the process of porting RTEMS to the Microblaze and
gcc does
  > not have __ELF__ as a predefine. In looking around at where to
 add it,
  > it looks like there are multiple ways to do it. We see
variations on
  > the following patterns:
  >
  > + dbxelf.h
  > + OS specific header in config/
  > + Arch/OS specific header
  >
  > Integrating dbxelf.h into the microblaze seems risky for one
simple
  > builtin_define(). Adding it to config/microblaze/rtems.h won't
 address
  > the microblaze-elf target.
  >
  > A suggestion on where to add the builtin_predefine is
appreciated.

 There are very few defines for __ELF__ in the GCC target files.


Many  targets include dbxelf.h from the config.gcc script. There are
130 references to that file there. That seems to be where most
architectures get it.

AFAIK, no one has ever tried to build microblaze to generate stabs,
and I can't see a good reason why anyone would.  Including dbxelf.h
seems wrong.  I don't have an answer why other arch's do that.

Avoiding dbxelf would be advisable.  We're really only supporting stabs
for for aix anymore.  We need to start excising dbxelf from all the
places it's being used.

That will take some work.

Yup.  But it's clearly the right thing to do.



What about elfos.h which is referenced 168 times in config.gcc?

Unfortunately, dbxelf.h and elfos.h appear to be used together a lot.
Grep'ing for "dbxelf.h elfos.h" in config.gcc resulted in 128 hits.
I think most of elfos.h is OK, we just need to rip out the bits for 
embedded stabs contained therein.



jeff

Re: Failures building glibc with mainline GCC

[Jeff Law via Gcc]

On 7/30/2021 10:19 AM, Aldy Hernandez via Libc-alpha wrote:

There's a new jump threader in GCC which is much more aggressive, and
may trigger latent problems with other warning passes, especially
-Warray-bounds, -Woverflow, and -Wuninitialized.

Do your problems go away if you take out commit 2e96b5f14e?

I have notes throughout the commit analyzing variants of the above
warnings (for example my addendum to gcc.c-torture/compile/pr83510.c).
So far, all the warnings I've seen are legitimate jump threading
opportunities that we are now doing, but which throw off the warning
passes.

Before the inclusion of the new threader, I had warned that this could
happen.  Perhaps we'll have to come up a way to reduce the false
positives.
I should be able to get you testcases for at least some of these.  I 
strongly suspect it's the new threader.  First up will be the iconf 
stringop-overflow failures which should hit your inbox shortly.


Jeff

Re: Failures building glibc with mainline GCC

[Jeff Law via Gcc]

On 7/30/2021 10:19 AM, Aldy Hernandez via Libc-alpha wrote:

There's a new jump threader in GCC which is much more aggressive, and
may trigger latent problems with other warning passes, especially
-Warray-bounds, -Woverflow, and -Wuninitialized.

[ ... ]
Ugh.  First attempt got blocked as message was slightly too big.

I think this is pretty generic as I've seen it on multiple ports and 
Joseph mentioned them as well.


With an s390-linux-gnu (not s390x!) cross compiler you should be able to 
trigger:


bash-5.1# s390-linux-gnu-gcc -std=gnu99 -O2 -Wall -mlong-double-128 *.i
In file included from t.61.c:437:
In function 'from_t_61_single',
    inlined from 'gconv' at ../iconv/skeleton.c:568:15:
../iconv/loop.c:440:22: warning: writing 1 byte into a region of size 0 
[-Wstringop-overflow=]

In file included from t.61.c:437:
../iconv/loop.c: In function 'gconv':
../iconv/loop.c:382:17: note: at offset 2 into destination object 
'bytebuf' of size 2



I don't know if it's a real failure or a false positive.  I haven't even 
bisected, but I suspect the new threader is the triggering change.  
Ideally the threader threaded a path we hadn't previously and by some 
chain of events exposed a out of bounds write that needs to be fixed.





Jeff


t.61.i.gz
Description: GNU Zip compressed data

Re: gcc_assert() and inhibit_libc

[Jeff Law via Gcc]

On 8/16/2021 11:06 AM, Jakub Jelinek via Gcc wrote:

On Mon, Aug 16, 2021 at 12:50:49PM -0400, Jason Merrill via Gcc wrote:

The trap builtin is target-specific. Making this system-specific (in
this case RTEMS) could be an issue.

Is that necessary?  Are there interesting targets that don't have a trap insn?

Depends on the definition of interesting.
I think avr, bpf, c6x, cr16, epiphany, fr30, frv, ft32, h8300, lm32, m32c, 
m32r, mcore,
mmix, mn10300, moxie, msp430, or1k, pdp11, pru, rl78, rx, sh, stormy16, v850 
and vax
don't have trap insn, while
aarch64, alpha, arc, arm, bfin, cris, csky, gcn, i386, ia64, iq2000, m68k, 
microblaze,
mips, nds32, nios2, nvptx, pa, riscv, rs6000, s390, sparc, tilegx, tilepro, 
visium and xtensa
have them.
Probably safer to say "no trap insn currently defined".  I'd bet 
multiple targets in the first set have trap insns defined in their ISA, 
but not in the MD file.


jeff

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

[Jeff Law via Gcc]

On 9/9/2021 2:14 AM, Aldy Hernandez wrote:



On 9/8/21 8:13 PM, Michael Matz wrote:

Hello,

[lame answer to self]

On Wed, 8 Sep 2021, Michael Matz wrote:


The forward threader guards against this by simply disallowing
threadings that involve different loops.  As I see


The thread in question (5->9->3) is all within the same outer loop,
though. BTW, the backward threader also disallows threading across
different loops (see path_crosses_loops variable).

...
Maybe it's possible to not disable threading over latches 
alltogether in
the backward threader (like it's tried now), but I haven't looked at 
the
specific situation here in depth, so take my view only as opinion 
from a

large distance :-)


I've now looked at the concrete situation.  So yeah, the whole path 
is in

the same loop, crosses the latch, _and there's code following the latch
on that path_.  (I.e. the latch isn't the last block in the path).  In
particular, after loop_optimizer_init() (before any threading) we have:

    [local count: 118111600]:
   # j_19 = PHI 
   sum_11 = c[j_19];
   if (n_10(D) > 0)
 goto ; [89.00%]
   else
 goto ; [11.00%]

   [local count: 105119324]:
...

    [local count: 118111600]:
   # sum_21 = PHI 
   c[j_19] = sum_21;
   j_13 = j_19 + 1;
   if (n_10(D) > j_13)
 goto ; [89.00%]
   else
 goto ; [11.00%]

    [local count: 105119324]:
   goto ; [100.00%]

With bb9 the outer (empty) latch, bb3 the outer header, and bb8 the
pre-header of inner loop, but more importantly something that's not 
at the

start of the outer loop.

Now, any thread that includes the backedge 9->3 _including_ its
destination (i.e. where the backedge isn't the last to-be-redirected 
edge)
necessarily duplicates all code from that destination onto the back 
edge.

Here it's the load from c[j] into sum_11.

The important part is the code is emitted onto the back edge,
conceptually; in reality it's simply included into the (new) latch block
(the duplicate of bb9, which is bb12 intermediately, then named bb7 
after

cfg_cleanup).

That's what we can't have for some of our structural loop optimizers:
there must be no code executed after the exit test (e.g. in the latch
block).  (This requirement makes reasoning about which code is or isn't
executed completely for an iteration trivial; simply everything in the
body is always executed; e.g. loop interchange uses this to check that
there are no memory references after the exit test, because those would
then be only conditional and hence make loop interchange very awkward).

Note that this situation can't be later rectified anymore: the 
duplicated

instructions (because they are memory refs) must remain after the exit
test.  Only by rerolling/unrotating the loop (i.e. noticing that the
memory refs on the loop-entry path and on the back edge are equivalent)
would that be possible, but that's something we aren't capable of.  Even
if we were that would simply just revert the whole work that the 
threader

did, so it's better to not even do that to start with.

I believe something like below would be appropriate, it disables 
threading

if the path contains a latch at the non-last position (due to being
backwards on the non-first position in the array).  I.e. it disables
rotating the loop if there's danger of polluting the back edge. It might
be improved if the blocks following (preceding!) the latch are themself
empty because then no code is duplicated.  It might also be improved if
the latch is already non-empty.  That code should probably only be 
active

before the loop optimizers, but currently the backward threader isn't
differentiating between before/after loop-optims.

I haven't tested this patch at all, except that it fixes the testcase :)


Thanks for looking at this.

I think you're onto something with this approach.  Perhaps in addition 
to the loop header threading Richard mentions.


Your patch causes some regressions, but I think most are noise from 
FSM tests that must be adjusted.  However, there are some other ones 
that are curious:


> FAIL: gcc.dg/tree-ssa/ldist-22.c scan-tree-dump ldist "generated 
memset zero"

> FAIL: gcc.dg/tree-ssa/pr66752-3.c scan-tree-dump-not dce2 "if .flag"
< XFAIL: gcc.dg/shrink-wrap-loop.c scan-rtl-dump pro_and_epilogue 
"Performing shrink-wrapping"
< XFAIL: gcc.dg/Warray-bounds-87.c pr101671 (test for bogus messages, 
line 36)
> FAIL: libgomp.graphite/force-parallel-4.c scan-tree-dump-times 
graphite "1 loops carried no dependency" 1
> FAIL: libgomp.graphite/force-parallel-4.c scan-tree-dump-times 
optimized "loopfn.1" 4
> FAIL: libgomp.graphite/force-parallel-8.c scan-tree-dump-times 
graphite "5 loops carried no dependency" 1


Interestingly your patch is fixing shrink-wrap-loop.c and 
Warray-bounds-87, both of which were introduced by the backward 
threader rewrite.  At least the Warray-bounds was the threader peeling 
off an iteration that caused a bogus warning.


The ldist-22 regression is interesting though:

void foo ()

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

[Jeff Law via Gcc]

On 9/9/2021 2:58 AM, Richard Biener wrote:

On Thu, Sep 9, 2021 at 10:36 AM Aldy Hernandez  wrote:



On 9/9/21 9:45 AM, Richard Biener wrote:

On Thu, Sep 9, 2021 at 9:37 AM Aldy Hernandez  wrote:



On 9/9/21 8:57 AM, Richard Biener wrote:

On Wed, Sep 8, 2021 at 8:13 PM Michael Matz  wrote:

Hello,

[lame answer to self]

On Wed, 8 Sep 2021, Michael Matz wrote:


The forward threader guards against this by simply disallowing
threadings that involve different loops.  As I see

The thread in question (5->9->3) is all within the same outer loop,
though. BTW, the backward threader also disallows threading across
different loops (see path_crosses_loops variable).

...

Maybe it's possible to not disable threading over latches alltogether in
the backward threader (like it's tried now), but I haven't looked at the
specific situation here in depth, so take my view only as opinion from a
large distance :-)

I've now looked at the concrete situation.  So yeah, the whole path is in
the same loop, crosses the latch, _and there's code following the latch
on that path_.  (I.e. the latch isn't the last block in the path).  In
particular, after loop_optimizer_init() (before any threading) we have:

  [local count: 118111600]:
 # j_19 = PHI 
 sum_11 = c[j_19];
 if (n_10(D) > 0)
   goto ; [89.00%]
 else
   goto ; [11.00%]

 [local count: 105119324]:
...

  [local count: 118111600]:
 # sum_21 = PHI 
 c[j_19] = sum_21;
 j_13 = j_19 + 1;
 if (n_10(D) > j_13)
   goto ; [89.00%]
 else
   goto ; [11.00%]

  [local count: 105119324]:
 goto ; [100.00%]

With bb9 the outer (empty) latch, bb3 the outer header, and bb8 the
pre-header of inner loop, but more importantly something that's not at the
start of the outer loop.

Now, any thread that includes the backedge 9->3 _including_ its
destination (i.e. where the backedge isn't the last to-be-redirected edge)
necessarily duplicates all code from that destination onto the back edge.
Here it's the load from c[j] into sum_11.

The important part is the code is emitted onto the back edge,
conceptually; in reality it's simply included into the (new) latch block
(the duplicate of bb9, which is bb12 intermediately, then named bb7 after
cfg_cleanup).

That's what we can't have for some of our structural loop optimizers:
there must be no code executed after the exit test (e.g. in the latch
block).  (This requirement makes reasoning about which code is or isn't
executed completely for an iteration trivial; simply everything in the
body is always executed; e.g. loop interchange uses this to check that
there are no memory references after the exit test, because those would
then be only conditional and hence make loop interchange very awkward).

Note that this situation can't be later rectified anymore: the duplicated
instructions (because they are memory refs) must remain after the exit
test.  Only by rerolling/unrotating the loop (i.e. noticing that the
memory refs on the loop-entry path and on the back edge are equivalent)
would that be possible, but that's something we aren't capable of.  Even
if we were that would simply just revert the whole work that the threader
did, so it's better to not even do that to start with.

I believe something like below would be appropriate, it disables threading
if the path contains a latch at the non-last position (due to being
backwards on the non-first position in the array).  I.e. it disables
rotating the loop if there's danger of polluting the back edge.  It might
be improved if the blocks following (preceding!) the latch are themself
empty because then no code is duplicated.  It might also be improved if
the latch is already non-empty.  That code should probably only be active
before the loop optimizers, but currently the backward threader isn't
differentiating between before/after loop-optims.

I haven't tested this patch at all, except that it fixes the testcase :)

Lame comment at the current end of the thread - it's not threading through the

I don't know why y'all keep using the word "lame".  On the contrary,
these are incredibly useful explanations.  Thanks.


latch but threading through the loop header that's problematic, at least if the
end of the threading path ends within the loop (threading through the header
to the loop exit is fine).  Because in that situation you effectively created an
alternate loop entry.  Threading through the latch into the loop header is
fine but with simple latches that likely will never happen (if there are no
simple latches then the latch can contain the loop exit test).

See tree-ssa-threadupdate.c:thread_block_1

 e2 = path->last ()->e;
 if (!e2 || noloop_only)
   {
 /* If NOLOOP_ONLY is true, we only allow threading through the
header of a loop to exit edges.  */

 /* One case occurs when there was loop header buried in a jump
threading path that crosses 

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

[Jeff Law via Gcc]

On 9/9/2021 3:21 AM, Aldy Hernandez wrote:




   /* If this path does not thread through the loop latch, then we are
  using the FSM threader to find old style jump threads. This
  is good, except the FSM threader does not re-use an existing
  threading path to reduce code duplication.

  So for that case, drastically reduce the number of statements
  we are allowed to copy.  */


*blink*

Woah.  The backward threader has been using FSM threads 
indiscriminately as far as I can remember.  I wonder what would break 
if we "fixed it".
?!?  I'm not sure what you're suggesting here.  If you s/FSM 
threader/backwards threader/ in the comment does it make more sense?   
The term FSM really should largely have been dropped as the backwards 
threader was improved to handle more cases.









so these cases should use the "old style" validity/costing metrics 
and thus

classify threading opportunities in a different way?


Jeff, do you have any insight here?

This is precisely what you're cleaning up.






I think today "backwards" vs, "forwards" only refers to the way we find
threading opportunities.


Yes, it's a mess.

I ran some experiments a while back, and my current work on the 
enhanced solver/threader, can fold virtually everything the 
DOM/threader gets (even with its use of const_and_copies, avail_exprs, 
and evrp_range_analyzer), while getting 5% more DOM threads and 1% 
more overall threads.  That is, I've been testing if the path solver 
can solve everything the DOM threader needs (the hybrid approach I 
mentioned).


Unfortunately, replacing the forward threader right now is not 
feasible for a few reasons:
Right.  But I thought the short term goal was to replace/remove the 
forward threading from VRP.   Dropping from DOM is going to be tougher.




a) The const_and_copies/avail_exprs relation framework can do floats, 
and that's next year's ranger work.
Right.  I'd actually run into this as well when I wanted to drop all the 
range bits out of DOM and rely exclusively on EVRP.   It'd still be a 
step forward to rip out the EVRP engine from DOM and simplify all the 
code that derives one equivalence from another so that it's only working 
on FP values.




b) Even though we can seemingly fold everything DOM/threader does, in 
order to replace it with a backward threader instance we'd have to 
merge the cost/profitability code scattered throughout the forward 
threader, as well as the EDGE_FSM* / EDGE_COPY* business.
Right.  This is a prerequisite.  Though some of the costing will need to 
be conditional on the threader being used.  Refer back to the discussion 
around how the forward threader can commonize thread paths that lead to 
the same destination while the backwards threader can not.




c) DOM changes the IL as it goes.  Though we could conceivably divorce 
do the threading after DOM is done.
The only reason threading runs in parallel with DOM is so that it can 
use the context sensitive equivalences.  With the infrastructure you're 
building, there's a reasonable chance we can move to a model where we 
run DOM (and in the long term a simpler DOM) and threading as distinct, 
independent passes.


Jeff

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

[Jeff Law via Gcc]

On 9/9/2021 4:15 AM, Richard Biener wrote:



b) Even though we can seemingly fold everything DOM/threader does, in
order to replace it with a backward threader instance we'd have to merge
the cost/profitability code scattered throughout the forward threader,
as well as the EDGE_FSM* / EDGE_COPY* business.

c) DOM changes the IL as it goes.  Though we could conceivably divorce
do the threading after DOM is done.

Yeah, it does not actually process/simplify the blocks copied by threading.
In fact I think it only registers jump threading opportunities during the DOM
walk and commits them only later.  But it of course uses its avail / copies
stack to find them - that part you cannot easily divorce.
Well, divorcing from using the context sensitive avail/copies is part of 
what Aldy & Andrew have been working on.  All indications I've seen are 
they're on track to be able to do that.


And yes, it only registers the threads and waits until after DOM is done 
to transform the CFG.  That in and of itself introduces all kinds of 
complexity.  If we can get to the point where we don't need the context 
sensitive avail/copies, then we've got a real shot at untangling DOM and 
threading which would be a huge maintainability win in my mind.




DOM is also yet another value-numbering framework - one could think
of stripping it down from that side, keeping the threading bits only
(but you'd still have the avail / copies bits).
Yes.  I think you and I touched on this a while back.    At a high level 
I'd prefer to have FRE rather than DOM doing the bulk of the redundant 
expression elimination.  The big blocker there was the tight integration 
of DOM and threading.  But if Aldy can untangle that we can then 
evaluate replacing DOM with FRE.





That said, it has one nice property it can leverage due to its incredibly
simple memory redundancy handling, in that it usually performs way less
alias queries than FRE (even when you run the latter in non-iterative mode).
DOM as an infrastructure for optimization is probably reaching the end 
of its useful life.  FRE has a lot more going for it.




But the same way DOM can register jump threading opportunities FRE
could do as well.
I'd advise against that and instead look towards a model where no pass 
has integrated jump threading and the only jump threading module we have 
is the backwards threader.


jeff

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

[Jeff Law via Gcc]

On 9/10/2021 10:05 AM, Aldy Hernandez wrote:



On 9/10/21 5:43 PM, Jeff Law wrote:



On 9/9/2021 3:21 AM, Aldy Hernandez wrote:




   /* If this path does not thread through the loop latch, then we are
  using the FSM threader to find old style jump threads. This
  is good, except the FSM threader does not re-use an existing
  threading path to reduce code duplication.

  So for that case, drastically reduce the number of statements
  we are allowed to copy.  */


*blink*

Woah.  The backward threader has been using FSM threads 
indiscriminately as far as I can remember.  I wonder what would 
break if we "fixed it".
?!?  I'm not sure what you're suggesting here.  If you s/FSM 
threader/backwards threader/ in the comment does it make more sense? 
The term FSM really should largely have been dropped as the backwards 
threader was improved to handle more cases.


back_threader_registry::register_path() uses EDGE_FSM_THREAD as the 
thread type to register threads.  I was wondering if it should have 
been some combination of EDGE_START_JUMP_THREAD / 
EDGE_*_COPY_SRC_BLOCK, etc.  I (purposely) know nothing about the 
underlying threading types ;-). But if the backwards threader has been 
improved, then perhaps we should just remove the confusing FSM 
references.
No we shouldn't change it to any of the other types. EDGE_FSM_THREAD 
means a thread found by the backwards threader and it's the key used to 
determine which of the two CFG updating mechanisms should be used, the 
generic copier in the case of EDGE_FSM_THREAD.



Changing the name, yes, absolutely.  I probably should have done that 
when the original FSM threader was tweaked to handle generic threading.


As you've probably heard me mention before, all the EDGE_FSM_THREAD 
stuff in the registry really could be pulled out.   The registry's 
purpose is to deal with the two stage nature of jump threading in DOM 
(find threads, then optimize them later).  I don't think any of the 
backwards threading bits need that two stage handling.


My current thinking is that replacing the forward VRP threader with a 
hybrid one is a gentler approach to the longer term goal of replacing 
the forward threader altogether.  However, all the work I've been 
doing could go either way-- we could try the forward/VRP replacement 
or a hybrid approach.  It will all use the path solver underneath.
And that's probably a reasonable intermediate step on the way towards 
removing the VRP threading.




My main problem with replacing the forward/VRP with a backward client 
is that the cost models are so different that it was difficult to 
compare how we fared.  I constantly ran into threads the solver could 
handle just fine, but profitable_path_p was holding it back.

Yea.  Sorry about that tangle of insanity



FWIW, we get virtually everything the forward threader gets, minus a 
very few things.  At least when I plug in the solver to the 
DOM/forwarder threader, it can solve everything it can (minus noise 
and floats).
So once you plug those bits in, we don't have to carry around the 
avail/copies tables for the threader anymore, right?  That's a nice 
cleanup in and of itself.




If you prefer a backward threader instance to replace the VRP/forward 
threader, I'm game.  It's just harder to compare. Either way (backward 
threader or a hybrid forward+solver) uses the same underlying solver 
which is solid.
I think we can go hybrid, then look at the next step, which could well 
be bringing some consistency into the costing models.




c) DOM changes the IL as it goes.  Though we could conceivably 
divorce do the threading after DOM is done.
The only reason threading runs in parallel with DOM is so that it can 
use the context sensitive equivalences.  With the infrastructure 
you're building, there's a reasonable chance we can move to a model 
where we run DOM (and in the long term a simpler DOM) and threading 
as distinct, independent passes.


Andrew mumbled something about replacing all of DOM eventually :-). 
Well, except that value-numbering business I bet.
Essentially a realization of Bodik's work in GCC.   The nugget in there 
is it's a path sensitive optimizer.  That's kindof what I've envisioned 
DOM turning into.


1. We separate out jump threading from DOM.
2. We replace the bulk of DOM with FRE
3. The remnants of DOM turn into a path sensitive optimizer (and for 
god's sake we don't want to call it DOM anymore :-)




Jeff

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

[Jeff Law via Gcc]

On 9/27/2021 7:52 AM, Aldy Hernandez wrote:

[CCing Jeff and list for broader audience]

On 9/27/21 2:53 PM, Maxim Kuvyrkov wrote:

Hi Aldy,

Your patch seems to slow down 471.omnetpp by 8% at -O3.  Could you 
please take a look if this is something that could be easily fixed?


First of all, thanks for chasing this down.  It's incredibly useful to 
have these types of bug reports.


Jeff and I have been discussing the repercussions of adjusting the 
loop crossing restrictions in the various threaders.  He's seen some 
regressions in embedded targets when disallowing certain corner cases 
of loop crossing threads causes all sorts of grief.


Out of curiosity, does the attached (untested) patch fix the regression?
And just a note, that patch doesn't seem to fix the regressions on 
visium or rl78.    I haven't checked any of the other regressing targets 
yet.


jeff

Re: dejagnu version update?

[Jeff Law via Gcc]

On 10/27/2021 5:00 PM, Bernhard Reutner-Fischer wrote:

On Sat, 4 Aug 2018 18:32:24 +0200
Bernhard Reutner-Fischer  wrote:


On Tue, 16 May 2017 at 21:08, Mike Stump  wrote:

On May 16, 2017, at 5:16 AM, Jonathan Wakely  wrote:

The change I care about in 1.5.3

So, we haven't talked much about the version people want most.  If we update, 
might as well get something that more people care about.  1.5.3 is in ubuntu 
LTS 16.04 and Fedora 24, so it's been around awhile.  SUSU is said to be using 
1.6, in the post 1.4.4 systems.  People stated they want 1.5.2 and 1.5.3, so, 
I'm inclined to say, let's shoot for 1.5.3 when we do update.

As for the machines in the FSF compile farm, nah, tail wagging the dog.  I'd 
rather just update the requirement, and the owners or users of those machines 
can install a new dejagnu, if they are using one that is too old and they want 
to support testing gcc.

So.. let me ping that, again, now that another year has passed :)

or another 3 or 4 :)

PS: Recap: https://gcc.gnu.org/ml/fortran/2012-03/msg00094.html was
later applied as
http://git.savannah.gnu.org/gitweb/?p=dejagnu.git;a=commit;h=5481f29161477520c691d525653323b82fa47ad7
and was part of the dejagnu-1.5.2 release from 2015. Jonathan requires
1.5.3 for libstdc++ testing.

(i.e.
http://git.savannah.gnu.org/gitweb/?p=dejagnu.git;a=commit;h=5256bd82343000c76bc0e48139003f90b6184347
 )

The libdirs fix would allow us to remove the 150 occurrences of the
load_gcc_lib hack, refer to the patch to the fortran list back then.
AFAIR this is still not fixed: +# BUG: gcc-dg calls
gcc-set-multilib-library-path but does not load gcc-defs!

debian-stable (i think 9 ATM), Ubuntu LTS ship versions recent enough
to contain both fixes. Commercial distros seem to ship fixed versions,
too.

It seems in May 2020 there was a thread on gcc with about the same
subject: https://gcc.gnu.org/pipermail/gcc/2020-May/232427.html
where Mike suggests to have approved to bump the required minimum
version to 1.5.3.
So who's in the position to update the
https://gcc.gnu.org/install/prerequisites.html
to s/1.4.4/1.5.3/g && git commit -m 'bump dejagnu required version' ?
All kinds of people.  Submit a patch and I bet it'll get approved. More 
than anything I suspect it's out-of-sight-out-of-mind at this point 
holding us back.


jeff

Re: -Wuninitialized false positives and threading knobs

[Jeff Law via Gcc]

On 10/31/2021 6:12 AM, Aldy Hernandez wrote:

After Jeff's explanation of the symbiosis between jump threading and
the uninit pass, I'm beginning to see that (almost) every
Wuninitialized warning is cause for reflection.  It usually hides a
missing jump thread.  I investigated one such false positive
(uninit-pred-7_a.c) and indeed, there's a missing thread.  The
question is what to do about it.

This seemingly simple test is now regressing as can be seen by the
xfail I added.

This looks amazingly familiar.  You might want to look at this old thread:

https://gcc.gnu.org/pipermail/gcc-patches/2017-May/474229.html


What happened was that threading did a better job, but in the process 
the shape of the CFG changed in ways that made it harder for the 
predicate analysis pass to prune paths.  Richi & I never reached any 
kind of conclusion on that patch, so it's never been applied.


Remember, that the whole point behind the predicate analysis pass is to 
deal with infeasible paths that may be the in the CFG, including cases 
where the threaders may have found a jump thread, but not optimized it 
due to code size considerations.


So one of the first things I'd do is look at the dumps prior to your 
changes and see if the uninitialized use was still in the IL in 
the.uninit dump, but was analyzed as properly guarded by predicate analysis.




What happens is that we now thread far more than before, causing the
distance from definition to use to expand.  The threading candidate
that would make the Wuninitialized go away is there, and the backward
threader can see it, but it refuses to thread it because the number of
statements would be too large.

Right.



This is interesting because it means threading is causing larger IL
that in turn keeps us from threading some unreachable paths later on
because the paths are too large.
Yes.  This is not unexpected.  Jump threading reduces dynamic 
conditional jumps and statements executed, but often at the expense of 
increasing code size, much like PRE.  Jump threading also can create 
scenarios that can't be handled by the predicate analysis pass.


The other thing to review is whether or not you're accounting for 
statements that are going to be removed as a result of jump threading.  
I had Alex implement that a few years back for the forward threader.  
Essentially statements which exist merely to compute the conditional we 
thread are going to be removed and we need not worry about the cost of 
copying them which allowed us to thread many cases we had missed before 
without increasing codesize.


Anyway, those are the research areas to look at first, then we'll figure 
out what the next steps are.


JEff

Re: GCC's excellent tail-call optimizations

[Jeff Law via Gcc]

On 11/5/2021 8:13 AM, Andrew Appel wrote:

Dear GCC developers:

TL;DR Can I talk to a maintainer of gcc's tail-call optimizer to learn more 
about the very impressive technology behind it? Or is there a paper, or 
documentation, that explains it?

No paper or documentation I'm aware of.




I am sure you know that gcc does a much better job of tail-call optimizations 
than its competitors. Recently I noticed this little gem:

void f( void *p);

int h( int n, void *p)
{
{
void *a[ 10 ];
a[ 0 ]= p;
f(( void *)a);
}
return h(n, p);
}

With the inner curly braces, gcc turns the call to h into a jump. Without the 
inner curly braces, gcc does not do tail-call optimization. This is exactly 
correct, because we cannot know whether f() stores its argument in a place 
where later calls to h() might access it. The inner braces ensure that a[] is 
officially deallocated before the call to h.
Right.  The lifetime of the object is critical to knowing if its safe to 
tail call.


The easiest way to see what GCC does is via its debugging dumps.  In 
this particular case we're dealing with tail recursion which is 
happening entirely in the gimple optimizers.  So 
-fdump-tree-all-blocks-details will give you the relevant debugging dumps.


The dumps are numbered based on the pass ordering in the compiler. 
Looking at the pass before "tailr1" we have:


;; Function h (h, funcdef_no=0, decl_uid=1938, cgraph_uid=1, 
symbol_order=0)


h (int n, void * p)
{
  void * a[10];
  int _8;

;;   basic block 2, loop depth 0, maybe hot
;;    prev block 0, next block 1, flags: (NEW, VISITED)
;;    pred:   ENTRY (FALLTHRU,EXECUTABLE)
  a[0] = p_2(D);
  f (&a);
  a ={v} {CLOBBER};
  _8 = h (n_6(D), p_2(D));
  return _8;
;;    succ:   EXIT (EXECUTABLE)

}

Note the a = {v}{CLOBBER}.  That's the end of the lifetime of "a" and 
it's how we know tail recursion optimization is safe in this particular 
case.  In the .tailr1 dump we have:


;; Function h (h, funcdef_no=0, decl_uid=1938, cgraph_uid=1, symbol_order=0)

Eliminated tail recursion in bb 2 : _8 = h (n_6(D), p_2(D));


Updating SSA:
creating PHI node in block #2 for .MEM
Registering new PHI nodes in block #0
Registering new PHI nodes in block #2
Updating SSA information for statement a[0] = p_2(D);
Updating SSA information for statement f (&a);
Updating SSA information for statement a ={v} {CLOBBER};

Symbols to be put in SSA form
{ D.1944 }
Incremental SSA update started at block: 0
Number of blocks in CFG: 3
Number of blocks to update: 2 ( 67%)
Affected blocks: 0 2


fix_loop_structure: fixing up loops for function
flow_loops_find: discovered new loop 1 with header 2
h (int n, void * p)
{
  void * a[10];

;;   basic block 2, loop depth 1, maybe hot
;;    prev block 0, next block 1, flags: (NEW, VISITED)
;;    pred:   ENTRY (FALLTHRU,EXECUTABLE)
;;    2 (FALLTHRU,DFS_BACK,EXECUTABLE)
  a[0] = p_2(D);
  f (&a);
  a ={v} {CLOBBER};
  goto ; [INV]
;;    succ:   2 (FALLTHRU,DFS_BACK,EXECUTABLE)

}

And you can see we've turned the tail recursive call into a simple jump 
which creates a loop.







Clang/llvm does not tail-call-optimize this program.

So, congratulations.

I would enjoy speaking to one of you who is knowledgeable about how gcc does 
this.

A few years ago I wrote some compiler textbooks,
Modern Compiler Implementation in C, in ML, in Java (Cambridge University Press)
and I am still interested in these things. More to the point, I use C as the 
target for a functional-language compiler, for which tail-call optimization is 
very important.

Yup.  Got it on my bookshelf somewhere.



So please let me know,
* is there a paper somewhere that describes the approach that gcc takes for TCO?
* I'm particularly interested in how gcc's intermediate language represents the 
fact that a[] is deallocated at the first close-curly-brace
* Would someone like to Zoom sometime to tell me about this?
The dump files are going to be the best window into this stuff. There 
are cases where we just mark potential tail call sites, but have to 
defer the final decision until later in the optimizer pipeline, but this 
case is simple enough that we don't need to query the target's 
capabilities, look at stack usage, worry about argument mappings, etc.


jeff

Re: distinguishing gcc compilation valgrind false positives

[Jeff Law via Gcc]

On 11/24/2021 12:15 PM, Paul Floyd via Gcc wrote:


On 24/11/2021 20:05, Zdenek Sojka via Gcc wrote:

Hello,

from time to time, I come upon a testcase that failed during the 
automated

runs, but passes during reduction; there are valgrind warnings present,
however. How do I distinguish what warnings are valid and which are 
false

positives? Is there any way gcc could prevent generating the false
positives?



What makes you think that any are false positives?

Memcheck generally has a low false positive rate (though I am little 
biased).


You need to read the source and decide based on that.
Agreed.  Work from the assumption it's a real GCC issue until proven 
otherwise.


I believe GCC has annotations to help valgrind that are turned on by a 
magic configuration option as well.


Finally, there is an issue with sparsesets that will trigger a warning 
from valgrind.  Those are the only ones I would consistently ignore from 
GCC.


Jeff

Re: Question about match.pd

[Jeff Law via Gcc]

On 11/24/2021 2:19 PM, Navid Rahimi via Gcc wrote:

Hi GCC community,

I have a question about pattern matching in match.pd.

So I have a pattern like this [1]:
#define CMP !=
bool f(bool c, int i) { return (c << i) CMP 0; }
bool g(bool c, int i) { return c CMP 0;}

It is verifiably correct to transfer f to g [2]. Although this pattern looks simple, but the 
problem rises because GIMPLE converts booleans to int before "<<" operation.
So at the end you have boolean->integer->boolean conversion and the shift will 
happen on the integer in the middle.

For example, for something like:

bool g(bool c){return (c << 22);}

The GIMPLE is:
_Bool g (_Bool c)
{
   int _1;
   int _2;
   _Bool _4;

[local count: 1073741824]:
   _1 = (int) c_3(D);
   _2 = _1 << 22;
   _4 = _2 != 0;
   return _4;
}

I wrote a patch to fix this problem in match.pd:

+(match boolean_valued_p
+ @0
+ (if (TREE_CODE (type) == BOOLEAN_TYPE
+  && TYPE_PRECISION (type) == 1)))
+(for op (tcc_comparison truth_and truth_andif truth_or truth_orif truth_xor)
+ (match boolean_valued_p
+  (op @0 @1)))
+(match boolean_valued_p
+  (truth_not @0))

+/* cmp : ==, != */
+/* ((B0 << x) cmp 0) -> B0 cmp 0 */
+(for cmp (eq ne)
+ (simplify
+  (cmp (lshift (convert@3 boolean_valued_p@0) @1) integer_zerop@2)
+   (if (TREE_CODE (TREE_TYPE (@3)) == INTEGER_TYPE
+   && (GIMPLE || !TREE_SIDE_EFFECTS (@1)))
+(cmp @0 @2


But the problem is I am not able to restrict to the cases I am interested in. 
There are many hits in other libraries I have tried compiling with trunk+patch.

Any feedback?

1) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98956
2) https://alive2.llvm.org/ce/z/UUTJ_v
It would help to also see the cases you're triggering that you do not 
want to trigger.


Could we think of the optimization opportunity in a different way?


(A << B) eq/ne 0  -> A eq/ne (0U >> B)

And I would expect the 0U >> B to get simplified to 0.

Would looking at things that way help?

jeff

Re: distinguishing gcc compilation valgrind false positives

[Jeff Law via Gcc]

On 11/24/2021 12:41 PM, Zdenek Sojka wrote:

Hello Jeff,

-- Původní e-mail --
Od: Jeff Law via Gcc 
Komu: Paul Floyd , gcc@gcc.gnu.org
Datum: 24. 11. 2021 20:33:02
Předmět: Re: distinguishing gcc compilation valgrind false positives




On 11/24/2021 12:15 PM, Paul Floyd via Gcc wrote:
>
> On 24/11/2021 20:05, Zdenek Sojka via Gcc wrote:
>> Hello,
>>
>> from time to time, I come upon a testcase that failed during the
>> automated
>> runs, but passes during reduction; there are valgrind warnings
present,
>> however. How do I distinguish what warnings are valid and which
are
>> false
>> positives? Is there any way gcc could prevent generating the false
>> positives?
>
>
> What makes you think that any are false positives?
>
> Memcheck generally has a low false positive rate (though I am
little
> biased).
>
> You need to read the source and decide based on that.
Agreed.  Work from the assumption it's a real GCC issue until proven
otherwise.

I believe GCC has annotations to help valgrind that are turned on
by a
magic configuration option as well.


I have gcc configured with --enable-valgrind-annotations , if that is 
the one you are talking about?



Almost certainly.  I



I could also use a valgrind suppression file; this is also part of my 
question, if there is one readily available



I'm not aware of a suppression file, but it'd be nice to have one.

jeff

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

[Jeff Law via Gcc]

On 1/7/2022 3:25 AM, Martin Jambor wrote:

Hi,

Would anyone be terribly against mass renaming all *.c files (that are
actually C++ files) within the gcc subdirectory to ones with .cc suffix?

We already have 47 files with suffix .cc directly in the gcc
subdirectory and 160 if we also count those in (non-testsuite)
subdirectories, while the majority of our non-header C++ files still has
the .c suffix.

I have already missed stuff when grepping because I did not include *.cc
files and the inconsistency is also just ugly and must be very confusing
to anyone who encounters it for the first time.

Since we have switched to git, this should have quite small effect on
anyone who does their development on branches.  With Martin Liška we did
a few experiments and git blame, git rebase and even git gcc-backport
worked seamlessly across a rename.

I would be fine waiting with it until GCC 12 gets released but see
little value in doing so.

What do others think?  (Any important caveats I might have missed?)
I think it's well past time we do this.   There may be a bit of pain 
with cherry-picking across the rename point, but we should just deal 
with it.


jeff

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

[Jeff Law via Gcc]

On 1/7/2022 7:49 AM, Jeff Law wrote:



On 1/7/2022 3:25 AM, Martin Jambor wrote:

Hi,

Would anyone be terribly against mass renaming all *.c files (that are
actually C++ files) within the gcc subdirectory to ones with .cc suffix?

We already have 47 files with suffix .cc directly in the gcc
subdirectory and 160 if we also count those in (non-testsuite)
subdirectories, while the majority of our non-header C++ files still has
the .c suffix.

I have already missed stuff when grepping because I did not include *.cc
files and the inconsistency is also just ugly and must be very confusing
to anyone who encounters it for the first time.

Since we have switched to git, this should have quite small effect on
anyone who does their development on branches.  With Martin Liška we did
a few experiments and git blame, git rebase and even git gcc-backport
worked seamlessly across a rename.

I would be fine waiting with it until GCC 12 gets released but see
little value in doing so.

What do others think?  (Any important caveats I might have missed?)
I think it's well past time we do this.   There may be a bit of pain 
with cherry-picking across the rename point, but we should just deal 
with it.
 I realized this might be mis-interpreted.  The "well past time" was 
really meant to signal that I think we probably should have made this 
change long ago and that waiting even longer just doesn't make sense to me.


I'm fully in favor and have no objections to making it now.  I wouldn't 
be terribly surprised if it's less intrusive to make now rather than 
after gcc-12 is released.  Making it now affects trunk->gcc11 and 
earlier backports which should be smaller than trunk->gcc-12 backports 
we'd be making in the summer/fall if we were to defer until after gcc-12.


jeff

Re: Help with an ABI peculiarity

[Jeff Law via Gcc]

On 1/7/2022 2:55 PM, Paul Koning via Gcc wrote:



On Jan 7, 2022, at 4:06 PM, Iain Sandoe  wrote:

Hi Folks,

In the aarch64 Darwin ABI we have an unusual (OK, several unusual) feature of 
the calling convention.

When an argument is passed *in a register* and it is integral and less than SI 
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).
Most targets these days use registers for parameter passing and 
obviously we can run out of registers on all of them.  The key property 
is the size/alignment of the argument differs depending on if it's pass 
in a register (get promoted) or passed in memory (not promoted).  I'm 
not immediately aware of another ABI with that feature.  Though I 
haven't really gone looking.


jeff

Re: Uninit warnings due to optimizing short-circuit conditionals

[Jeff Law via Gcc]

On 2/14/2022 8:57 AM, David Malcolm via Gcc wrote:

[CCing Mark in the hopes of insight from the valgrind side of things]

There is a false positive from -Wanalyzer-use-of-uninitialized-value on
gcc.dg/analyzer/pr102692.c here:

   ‘fix_overlays_before’: events 1-3
 |
 |   75 |   while (tail
 |  |  
 |   76 |  && (tem = make_lisp_ptr (tail, 5),
 |  |  ^~
 |  |  |
 |  |  (1) following ‘false’ branch (when ‘tail’ is NULL)...
 |   77 |  (end = marker_position (XOVERLAY (tem)->end)) >= 
pos))
 |  |  ~
 |..
 |   82 |   if (!tail || end < prev || !tail->next)
 |  |   ~~~
 |  |   ||
 |  |   |(3) use of uninitialized value ‘end’ here
 |  |   (2) ...to here
 |

The issue is that inner || of the conditionals have been folded within the
frontend from a chain of control flow:

5   │   if (tail == 0B) goto ; else goto ;
6   │   :
7   │   if (end < prev) goto ; else goto ;
8   │   :
9   │   _1 = tail->next;
   10   │   if (_1 == 0B) goto ; else goto ;
   11   │   :

to an OR expr (and then to a bitwise-or by the gimplifier):

5   │   _1 = tail == 0B;
6   │   _2 = end < prev;
7   │   _3 = _1 | _2;
8   │   if (_3 != 0) goto ; else goto ;
9   │   :
   10   │   _4 = tail->next;
   11   │   if (_4 == 0B) goto ; else goto ;

This happens for sufficiently simple conditionals in fold_truth_andor.
In particular, the (end < prev) is short-circuited without optimization,
but is evaluated with optimization, leading to the false positive.

Given how early this folding occurs, it seems the simplest fix is to
try to detect places where this optimization appears to have happened,
and suppress uninit warnings within the statement that would have
been short-circuited (and thus e.g. ignoring them when evaluating _2
above for the case where _1 is known to be true at the (_1 | _2) , and
thus _2 being redundant).

Attached is a patch that implements this.

There are some more details in the patch, but I'm wondering if this is a
known problem, and how e.g. valgrind copes with such code.  My patch
feels like something of a hack, but I'm not sure of any other way around
it given that the conditional is folded directly within the frontend.
Presumably when "tail ==0", "end" is initialized somewhere?  If so, yes, 
this is a known issue.  There's a BZ about it somewhere (I don' t have 
the # handy, but it's probably on the Wuninitialized tracker).



Jeff

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

[Jeff Law via Gcc]

About a week ago many targets started failing pr94157_0.c test like this 
(bfin-elf, but many other targets are also affected):


spawn -ignore SIGHUP /home/jlaw/test/obj/bfin-elf/obj/gcc/gcc/xgcc 
-B/home/jlaw/test/obj/bfin-elf/obj/gcc/gcc/ c_lto_pr94157_0.o 
-fdiagnostics-plain-output -dumpbase  -O0 -fipa-vrp -flto 
-Wa,--noexecstack -Wa,--noexecstack -Wa,--execstack -Wa,--execstack 
-Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack 
-Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack 
-Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -msim 
-Wl,-wrap,exit -Wl,-wrap,_exit -Wl,-wrap,main -Wl,-wrap,abort 
-Wl,gcc_tg.o -o gcc-dg-lto-pr94157-01.exe^M
/home/jlaw/test/obj/bfin-elf/installed/bfin-elf/bin/ld: warning: 
/tmp/ccfJUEvZ.ltrans0.ltrans.o: requires executable stack (because the 
.note.GNU-stack section is executable)^M
FAIL: gcc.dg/lto/pr94157 c_lto_pr94157_0.o-c_lto_pr94157_0.o link,  
-O0 -fipa-vrp -flto -Wa,--noexecstack -Wa,--noexecstack 
-Wa,--execstack  -Wa,--execstack -Wa,--execstack -Wa,--execstack 
-Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack 
-Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack 
-Wa,--execstack -Wa,--execstack


This is due to a new binutils warning.  This patch just suppresses the 
warning for the one test where we explicitly wanted an executable stack.


I'm guessing the repeated -Wa,--noexecstack options in this test are 
supposed to trigger a  buffer overflow or something similar, so I left 
those alone and just appended to the argument list.


I used -z execstack rather than --no-warn-execstack as the former is 
recognized by older versions of ld, but the latter is a new option.


The other approach would have been to prune the warning, but this seemed 
better since we'd like most tests to fail if somehow their stacks were 
executable.



Committed to the trunk.

Jeff

commit 6b7441a46c771aa6ecdc0c8ed96197417d036b9a
Author: Jeff Law 
Date:   Sun Apr 24 13:38:14 2022 -0400

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

gcc/testsuite
* gcc.dg/lto/pr94157_0.c: Also request executable stack from
the linker.

diff --git a/gcc/testsuite/gcc.dg/lto/pr94157_0.c 
b/gcc/testsuite/gcc.dg/lto/pr94157_0.c
index a6e308b855b..a76141b1809 100644
--- a/gcc/testsuite/gcc.dg/lto/pr94157_0.c
+++ b/gcc/testsuite/gcc.dg/lto/pr94157_0.c
@@ -1,6 +1,6 @@
 /* { dg-lto-do link } */
 /* { dg-require-effective-target gas } */
-/* { dg-lto-options { { -O0 -fipa-vrp -flto -Wa,--noexecstack 
-Wa,--noexecstack -Wa,--execstack  -Wa,--execstack -Wa,--execstack 
-Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack 
-Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack 
-Wa,--execstack } } } */
+/* { dg-lto-options { { -O0 -fipa-vrp -flto -Wa,--noexecstack 
-Wa,--noexecstack -Wa,--execstack  -Wa,--execstack -Wa,--execstack 
-Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack 
-Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack 
-Wa,--execstack -Wl,-z,execstack} } } */
 
 int main() {
 

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

[Jeff Law via Gcc]

On 4/25/2022 6:56 AM, Martin Liška wrote:



I used -z execstack rather than --no-warn-execstack as the former is recognized 
by older versions of ld, but the latter is a new option.

Thanks for it.
Unfortunately, I should have looked at the other failures that have 
popped up over the last week.  Essentially all the nested function tests 
are failing on some targets due to the same linker warning.


Either pruning or adding  the option to all those tests is going to be 
necessary ;(


jeff

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

[Jeff Law via Gcc]

On 4/25/2022 8:42 AM, Nick Clifton wrote:

Hi Jeff,

I used -z execstack rather than --no-warn-execstack as the former 
is recognized by older versions of ld, but the latter is a new option.

Thanks for it.
Unfortunately, I should have looked at the other failures that have 
popped up over the last week.  Essentially all the nested function 
tests are failing on some targets due to the same linker warning.


Either pruning or adding  the option to all those tests is going to 
be necessary ;(


Sorry for causing you so much hassle.
No worries.  It's a very reasonable warning.  And it's only if you're 
testing with the latest binutils that it causes problems -- which is one 
of the goals of the tester -- to find this stuff when it happens, not 
6-12 months later.




  If it helps, Alan has already added
some pruning code to binutils/testsuite/lib/binutils-common.exp in the
prune_extra_warnings proc...
Yea.  I saw that.  I ultimately decided against pruning as it would be 
useful to know if a test suddenly needs execstack.   That would 
generally be a sign of something gone horribly wrong.  I just (locally) 
added the magic to the rest of the affected tests and I'm testing it now.


jeff

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

[Jeff Law via Gcc]

On 4/25/2022 9:26 AM, Nick Clifton wrote:

Hi Jeff,

  Just FYI - I am also looking at adding in another warning.  This 
time for
  when the linker creates a PT_LOAD segment which has all of the RWX 
flags
  set.  At the moment my testing seems to show that it only causes 
problems
  when a custom linker script is used that defines its own program 
headers

  and does not provide separate headers for code and data.
That also sounds quite reasonable.    My biggest worry would be the 
embedded targets which have their own linker scripts -- but like the 
executable stack warning, I think you should go for it and we'll deal 
with the fallout.


jeff