Re: Adding -Wshadow=local to gcc build rules
On Wed, Sep 18, 2019 at 3:09 PM Bernd Edlinger wrote: > > Hi, > > I'm currently trying to add -Wshadow=local to the gcc build rules. > I started with -Wshadow, but gave up that idea immediately. > > As you could expect the current code base has plenty of shadowed > local variables. Most are trivial to resolve, some are less trivial. > I am not finished yet, but it is clear that it will be a rather big > patch. > > I would like to ask you if you agree that would be a desirable step, > in improving code quality in the gcc tree. I wonder if -Wshadow=compatible-local is easier to achieve? Richard. > > > Thanks > Bernd.
Re: How can I build new functions on the fly during optimization?
On Thu, Sep 19, 2019 at 4:27 AM Gary Oblock wrote: > > I'm trying to build new functions on the fly during optimization. > For those of you that have not been following my previous questions, > this is structure reorganization optimization related. For example when > somebody frees an array of type fu, I'd like to build a new > function _reorg_free_fu which does the correct things for a > transformed array of type _reorg_fu. > > I've run across uses of these: > build_fn_decl > gimple_build_call > However, I don't see any code going any further than that. > > Anybody have any ideas about how I can accomplish the rest of > what I need to do? Note, I'll be doing this during LTRANS. One of the few examples is cgraph_node::expand_thunk where it builds a GIMPLE thunk. The other is in ipa.c, cgraph_build_static_cdtor_1 but using a GENERIC body. Most others do sth like cloning an existing function or moving part of the CFG to a new function. Richard. > Thanks, > > Gary Oblock
gcc.opensuse.org and periodic builds
Hi. As slightly discussed at the Cauldron, I would like to announce more pages linked at gcc.opensuse.org. Following links can be found on the website: - We've running SPEC benchmarks in LNT for more than a year - OBS testing project - I'm build ~40 packages with latest GCC master on daily basis (some packages are failing and will be fixed once released) - LCOV - line coverage of the GCC compiler (built weekly) - Doxygen - a generated documentation (built weekly) - Clang warnings - filtered clang warnings on the GCC (built weekly) - clang-static-analyzer - static analyzer run on the GCC (I'm also providing a diff against a baseline) Martin
Re: Proposal for the transition timetable for the move to GIT
On Tue, Sep 17, 2019 at 3:02 PM Richard Earnshaw (lists) wrote: > There should be NO CHANGE to the other processes and policies that we > have, eg patch reviews, ChangeLog policies etc at this time. Adding > requirements for this will just slow down the transition by > over-complicating things. A little aside; I fully support the above, lets change one thing at a time. But it would be nice with some short documentation about the git workflow that we'll start with (which, presumably, at least initially shouldn't differ too much from the svn workflow many are familiar with for the reasons you mention above), particularly for those not that familiar with git, or have only used git together with github or such. One thing that's unclear to me is how should I actually make my stuff appear in the public repo? Say I want to work on some particular thing: 1. git checkout -b pr1234-foo # A private branch based on latest trunk 2. Then when I'm happy, I send out a patch for review, either manually or with git format-patch + send-email. 3. Patch goes through a few revisions, and is approved. 4. Now what? 4a) Do I merge my private branch to master (err, trunk?), then commit and push? 4b) Or do I first rebase my branch on top of the latest master, to produce a slightly less branchy history? 4c) Or do I (manually?) apply my patch on master, to create a linear history? 4d) Something else entirely? Thanks, -- Janne Blomqvist
Go on and discover how to isolate “resting trends”, buy them, and watch them snap back to life
Hello! Email: g...@gnu.org Our international company has about 65 Internet projects related to crypto currencies and ICO. Now we recruit staff from all over the world. CHECK IT OUT HERE Primary salary $295k yearly E-workers wanted. - No Special Skills Needed - No Previous Job Experience Required - No Crypto Trading Experience Needed Our Requirements: >> Internet access >> Computer knowledge >> A 2-5 hours of free time daily >> Sharp Mind Average earnings is $801 daily, part-time, no set hours. At the moment there are 68 vacancy left. CLICK HERE TO START Best wishes, Oliver Walton HR Manager Unsubscribe ArcaMax Publishing, Inc., 729 Thimble Shoals Blvd., Suite 1-B, Newport News, VA 23606
Re: Proposal for the transition timetable for the move to GIT
On Thu, Sep 19, 2019 at 5:04 AM Janne Blomqvist wrote: > > One thing that's unclear to me is how should I actually make my stuff > appear in the public repo? Say I want to work on some particular > thing: > This is essentially a git workflow question. A simple and useful workflow to consider is the GitHub Flow: https://guides.github.com/introduction/flow/. Others to consider are on the GitLab Flow page: https://docs.gitlab.com/ee/workflow/gitlab_flow.html and on Atlassian's Git Flow page: https://docs.gitlab.com/ee/workflow/gitlab_flow.html. Where will the GCC git repository be hosted? > 1. git checkout -b pr1234-foo # A private branch based on latest trunk > 2. Then when I'm happy, I send out a patch for review, either manually > or with git format-patch + send-email. > Will GCC allow workflows other than emailing patches? It could make contributing more inviting to new developers. A large community of developers has grown up around the above workflows and are used to using the related tools. I realize emailing patches probably seems simple to GCC developers, but that practice is one of the main reasons I haven't contributed code to GCC even though I have supported GCC development financially and I frequently interact with GCC developers. My problems with email have been many. I have often forgotten to set my emails to plain text so my emails to GCC lists bounce and I have to resend them (often hours later if I didn't see the bounce right away). When I receive patches from GCC developers, I get frustrated with determining what -p argument to pass when applying the patch. I'm equally daunted with the process of searching through emails to find related discussions rather than having all the dialogue about a pull request (which contains the same information as a patch) in one place. And with plain-text emails as the medium, I really miss the ability to format dialogues with Markdown, including inserting hyperlinks but also to tie comments to specific lines of code in a browser interface to the pull request, etc. 3. Patch goes through a few revisions, and is approved. > 4. Now what? > 4a) Do I merge my private branch to master (err, trunk?), then commit and > push? > It's safer to first merge master into your branch and then retest with all the new commits that have hit master since you branched. If you test right after merging and find no problems (and no new commits hit master while you're testing), then the head of your branch will reflect the state master will reach when you merge into master so you know it's safe to do so. > 4b) Or do I first rebase my branch on top of the latest master, to > produce a slightly less branchy history? > A lot of people find rebasing to be overly complicated and error-prone (with the exception of interactive rebasing for the purpose of squashing commits that haven't been pushed to the remote repository). The above merging steps are easier at the expense of having merge commits in the history, which I think is good to better document the branching history. > 4c) Or do I (manually?) apply my patch on master, to create a linear > history? See above. I recommend "git merge" over manually applying patches. > 4d) Something else entirely? > A lot of the testing can be automated. For example, on GitHub, git hooks can be set up to ensure that if a branch has an open pull request against master (or other designated branches), tests run for that branch every time a new commit is pushed to it. Damian
Re: Proposal for the transition timetable for the move to GIT
On Thu, Sep 19, 2019 at 5:43 PM Damian Rouson
wrote:
>
>
>
> On Thu, Sep 19, 2019 at 5:04 AM Janne Blomqvist
> wrote:
>>
>>
>> One thing that's unclear to me is how should I actually make my stuff
>> appear in the public repo? Say I want to work on some particular
>> thing:
>
>
> This is essentially a git workflow question.
Yes. What I'm saying is we ("we" as in whoever is responsible for the
git conversion, or the gcc development community in general) should
have some kind of workflow documented. Doesn't have to be an academic
paper or a best-seller book written by some self-styled "thought
leader", but there should be some guidance. A page in the wiki or in
wwwdocs is good enough for me.
> A simple and useful workflow to consider is the
> GitHub Flow: https://guides.github.com/introduction/flow/. Others to
> consider are on the
> GitLab Flow page: https://docs.gitlab.com/ee/workflow/gitlab_flow.html and on
> Atlassian's
> Git Flow page: https://docs.gitlab.com/ee/workflow/gitlab_flow.html. Where
> will the GCC
> git repository be hosted?
Yes, I'm aware (though I do think gitflow is a bit too overcomplicated
for its own good, but YMMV).
>> 1. git checkout -b pr1234-foo # A private branch based on latest trunk
>> 2. Then when I'm happy, I send out a patch for review, either manually
>> or with git format-patch + send-email.
>
>
> Will GCC allow workflows other than emailing patches? It could make
> contributing more
> inviting to new developers. A large community of developers has grown up
> around the
> above workflows and are used to using the related tools. I realize emailing
> patches
> probably seems simple to GCC developers, but that practice is one of the main
> reasons I
> haven't contributed code to GCC even though I have supported GCC development
> financially
> and I frequently interact with GCC developers. My problems with email have
> been many.
> I have often forgotten to set my emails to plain text so my emails to GCC
> lists bounce and
> I have to resend them (often hours later if I didn't see the bounce right
> away). When I
> receive patches from GCC developers, I get frustrated with determining what
> -p argument
> to pass when applying the patch. I'm equally daunted with the process of
> searching through
> emails to find related discussions rather than having all the dialogue about
> a pull request
> (which contains the same information as a patch) in one place. And with
> plain-text emails
> as the medium, I really miss the ability to format dialogues with Markdown,
> including inserting
> hyperlinks but also to tie comments to specific lines of code in a browser
> interface to the
> pull request, etc.
I do see the attractiveness of these kinds of tools, however as the
original message in this thread stated, at this point we have enough
to chew on just getting the git transition done. Spending another year
(or more!) bikeshedding various other workflow improvements to tack on
to the git transition would be a mistake. After the git transition is
done and the smoke has settled, we can start thinking whether we want
to move away from the current email-based workflow.
As for the email-based workflow, the nice thing with git is that it
has nice support for it, via the format-patch, send-email, am, and
apply commands. So at least it will be an improvement upon the current
svn-based workflow.
>> 3. Patch goes through a few revisions, and is approved.
>> 4. Now what?
>> 4a) Do I merge my private branch to master (err, trunk?), then commit and
>> push?
>
>
> It's safer to first merge master into your branch and then retest with all
> the new commits
> that have hit master since you branched. If you test right after merging and
> find no
> problems (and no new commits hit master while you're testing), then the head
> of your
> branch will reflect the state master will reach when you merge into master so
> you know
> it's safe to do so.
Ugh. Merging master into your branch and then merging your branch back
into master makes the history somewhat convoluted, IMHO.
> A lot of the testing can be automated. For example, on GitHub, git hooks can
> be set up
> to ensure that if a branch has an open pull request against master (or other
> designated
> branches), tests run for that branch every time a new commit is pushed to it.
Sure. Again, something to look into once the git transition itself is
done, IMHO.
--
Janne Blomqvist
Re: Proposal for the transition timetable for the move to GIT
On 19/09/2019 13:04, Janne Blomqvist wrote: On Tue, Sep 17, 2019 at 3:02 PM Richard Earnshaw (lists) wrote: There should be NO CHANGE to the other processes and policies that we have, eg patch reviews, ChangeLog policies etc at this time. Adding requirements for this will just slow down the transition by over-complicating things. A little aside; I fully support the above, lets change one thing at a time. But it would be nice with some short documentation about the git workflow that we'll start with (which, presumably, at least initially shouldn't differ too much from the svn workflow many are familiar with for the reasons you mention above), particularly for those not that familiar with git, or have only used git together with github or such. One thing that's unclear to me is how should I actually make my stuff appear in the public repo? Say I want to work on some particular thing: 1. git checkout -b pr1234-foo # A private branch based on latest trunk 2. Then when I'm happy, I send out a patch for review, either manually or with git format-patch + send-email. 3. Patch goes through a few revisions, and is approved. 4. Now what? 4a) Do I merge my private branch to master (err, trunk?), then commit and push? 4b) Or do I first rebase my branch on top of the latest master, to produce a slightly less branchy history? 4c) Or do I (manually?) apply my patch on master, to create a linear history? 4d) Something else entirely? Thanks, I believe the current intent is that, at least for now, the trunk and release branches will be simple linear chains of commits (no merges). This is the same workflow as is currently used in gdb, binutils and glibc, and we will likely lift the hooks to enforce this from those projects. See the separate discussion on the git hooks for a bit more detail. What individuals do on private branches is up to them. Similarly for development branches (policy set by branch owner), but they will need linearizing (or maybe squashing) before they can be merged to trunk. The aim is to keep the workflow as close as possible to the existing one to start with. I'd expect most developers to work by posting patches to gcc-patches as before, though 'git format-patch' emails may well be acceptable (quite a few developers use a workflow much like that already). This will all be written up before the switch... R.
Re: Proposal for the transition timetable for the move to GIT
> On Sep 17, 2019, at 3:02 PM, Richard Earnshaw (lists) > wrote: > > At the Cauldron this weekend the overwhelming view for the move to GIT soon > was finally expressed. > ... > > So in summary my proposed timetable would be: > > Monday 16th December 2019 - cut off date for picking which git conversion to > use > > Tuesday 31st December 2019 - SVN repo becomes read-only at end of stage 3. > > Thursday 2nd January 2020 - (ie read-only + 2 days) new git repo comes on > line for live commits. > > Doing this over the new year holiday period has both advantages and > disadvantages. On the one hand the traffic is light, so the impact to most > developers will be quite low; on the other, it is a holiday period, so > getting the right key folk to help might be difficult. I won't object > strongly if others feel that slipping a few days (but not weeks) would make > things significantly easier. The timetable looks entirely reasonable to me. I have regenerated my primary version this week, and it's up at https://git.linaro.org/people/maxim-kuvyrkov/gcc-pretty.git/ . So far I have received only minor issue reports about it, and all known problems have been fixed. I could use a bit more scrutiny :-). Regards, -- Maxim Kuvyrkov www.linaro.org
Re: Proposal for the transition timetable for the move to GIT
Thanks to you and Janne for the thoughtful replies. I understand better the immediate goals now. Damian On Thu, Sep 19, 2019 at 08:31 Richard Earnshaw (lists) < richard.earns...@arm.com> wrote: > On 19/09/2019 13:04, Janne Blomqvist wrote: > > On Tue, Sep 17, 2019 at 3:02 PM Richard Earnshaw (lists) > > wrote: > >> There should be NO CHANGE to the other processes and policies that we > >> have, eg patch reviews, ChangeLog policies etc at this time. Adding > >> requirements for this will just slow down the transition by > >> over-complicating things. > > > > A little aside; I fully support the above, lets change one thing at a > > time. But it would be nice with some short documentation about the git > > workflow that we'll start with (which, presumably, at least initially > > shouldn't differ too much from the svn workflow many are familiar with > > for the reasons you mention above), particularly for those not that > > familiar with git, or have only used git together with github or such. > > > > One thing that's unclear to me is how should I actually make my stuff > > appear in the public repo? Say I want to work on some particular > > thing: > > > > 1. git checkout -b pr1234-foo # A private branch based on latest trunk > > 2. Then when I'm happy, I send out a patch for review, either manually > > or with git format-patch + send-email. > > 3. Patch goes through a few revisions, and is approved. > > 4. Now what? > > 4a) Do I merge my private branch to master (err, trunk?), then commit > and push? > > 4b) Or do I first rebase my branch on top of the latest master, to > > produce a slightly less branchy history? > > 4c) Or do I (manually?) apply my patch on master, to create a linear > history? > > 4d) Something else entirely? > > > > Thanks, > > > > I believe the current intent is that, at least for now, the trunk and > release branches will be simple linear chains of commits (no merges). > > This is the same workflow as is currently used in gdb, binutils and > glibc, and we will likely lift the hooks to enforce this from those > projects. See the separate discussion on the git hooks for a bit more > detail. > > What individuals do on private branches is up to them. Similarly for > development branches (policy set by branch owner), but they will need > linearizing (or maybe squashing) before they can be merged to trunk. > > The aim is to keep the workflow as close as possible to the existing one > to start with. I'd expect most developers to work by posting patches to > gcc-patches as before, though 'git format-patch' emails may well be > acceptable (quite a few developers use a workflow much like that already). > > This will all be written up before the switch... > > R. >
Re: Proposal for the transition timetable for the move to GIT
> On Sep 17, 2019, at 8:02 AM, Richard Earnshaw (lists) > wrote: > > ... > So in summary my proposed timetable would be: > > Monday 16th December 2019 - cut off date for picking which git conversion to > use > > Tuesday 31st December 2019 - SVN repo becomes read-only at end of stage 3. > > Thursday 2nd January 2020 - (ie read-only + 2 days) new git repo comes on > line for live commits. That sounds ok but it feels incomplete; there are additional steps and dates needed leading up to the 16th December decision point. I would suggest: 1 December 2019: final version of each proposed conversion tool is available, trial conversion repository of the full GCC SVN repository is posted for public examination. That allows 2 weeks for the different tools and their output to get the scrutiny needed for the picking decision to be made. 2 weeks may be more than needed (or possibly, less), but in any case I think this piece needs to be called out. paul
More relaxed -Wvla option (allowing VLA pointers)
Hi!
Some projects (most notably the linux-kernel) choose to use -Wvla to
warn on
usage of variable length array. The primary reason is usually that it
can
cause stack overflows if the programmer isn't careful, which introduces
a
security vulnerability.
I think an overlooked advantage of VLA's is the ability to create
indexable
multi-dimensional arrays with run-time sizes. These arrays doesn't have
to be
allocated on the stack, they can also be pointers to head-allocated
memory.
VLA's can also be useful to document preconditions on array-sizes in
function-prototypes.
I would like to suggest an option to warn against creating VLA objects
on the
stack, but not for VLA-pointers. When that is enabled the following
scenarios
will not emit warnings:
Scenario 1. Using decayed pointers from VLA's in function parameters
int sum(int n, int a[n]);
Scenario 2. Using pointers and manipulating pointers to VLA objects
float (*matrix1)[n][m] = malloc(sizeof *matrix);
float (*matrix2)[m] = malloc(n * sizeof *matrix);
While creating a VLA object on stack would still emit a warning:
int f(int n) {
int a[n]; // warning for creating a VLA object on the stack
}
Also note that scenario 1 can occur when including header files from a
library
that uses VLA's in function prototypes to annotate dynamic array sizes.
I
personally would like to see more libraries use C99 VLA's to annotate
array
sizes in function prototypes, but it would be annoying if that makes
them
unusable with "-Wvla".
I think this could either be an entirely new option, maybe called
"-Wvla-stack". Or an option to use in combination with -Wvla, maybe
called
"-Wno-vla-pointer" which has the same behavior when used like
"-Wvla -Wno-vla-pointer".
Just thought this would preserve many of the advantages of VLA's for
software
projects hesitant to enable VLAs completely to avoid stack smashing.
You may
implement it if you want, but I would be glad if you would consider it.
Regards,
Elias Åström
gcc-7-20190919 is now available
Snapshot gcc-7-20190919 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/7-20190919/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-7-branch revision 275982 You'll find: gcc-7-20190919.tar.xzComplete GCC SHA256=a1f9f6a148ca5c238756bef22c64ddd635f10d6c0209d38c02eaf371a51f6809 SHA1=540256e571ef87ff18df8c310a87bac79d00ccb1 Diffs from 7-20190912 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-7 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
gcc/testsuite/go/index0-out.x spinning
All my Fedora 30 builds on x86_64 today have gotten stuck on index0-out.x spinning indefinitely. I build and test all languages, including Go, so I'm wondering if anyone else who builds Go sees the same thing or if you know of a workaround. Thanks Martin
Re: gcc/testsuite/go/index0-out.x spinning
On Thu, Sep 19, 2019 at 7:10 PM Martin Sebor wrote: > > All my Fedora 30 builds on x86_64 today have gotten stuck on > index0-out.x spinning indefinitely. I build and test all > languages, including Go, so I'm wondering if anyone else who > builds Go sees the same thing or if you know of a workaround. For what it's worth, I don't see this on Debian rodete at GCC SVN revision 275986. Ian
