Re: [EXT] Re: Option processing question

On Mon, Jan 13, 2020 at 9:28 PM Gary Oblock wrote: > > If I have an optimization set up to run in LTO (call it my_opt) and > the flags -flto-partition=one, -flto options and -fmy-opt are set > then the optimization might or might not be run depending of whether > it can all fit in one partition. >

Re: [EXT] Re: Option processing question

> On Mon, Jan 13, 2020 at 9:28 PM Gary Oblock wrote: > > > > If I have an optimization set up to run in LTO (call it my_opt) and > > the flags -flto-partition=one, -flto options and -fmy-opt are set > > then the optimization might or might not be run depending of whether > > it can all fit in one

contrib/gcc_update does not work

gcc_update, when called from newly initialized and pulled tree does not work: --cut here-- $ contrib/gcc_update Updating GIT tree There is no tracking information for the current branch. Please specify which branch you want to rebase against. See git-pull(1) for details. git pull If you wi

Re: git conversion in progress

Am 11.01.20 um 02:18 schrieb Joseph Myers: I encourage people to continue to work on improving the documentation for using git with GCC ( and list some of the things that it seems

Whitespace at the start of first line of commit

Hi! I've noticed that a couple of Jason's commits show up in gcc-cvs in mutt as: [gcc r10-5937] ?PR c++/92582 - ICE with member template as requirement. The ? in there comes from a tab character, the full subject is like Subject: =?utf-8?q?=5Bgcc_r10-5937=5D_=09PR_c++/92582_-_ICE_with_member_temp

Re: contrib/gcc_update does not work

On Tue, 14 Jan 2020 at 09:22, Uros Bizjak wrote: > > gcc_update, when called from newly initialized and pulled tree does not work: Initialized how? If you do a 'git clone' then it correctly checks out master and sets it to track origin/master. > > --cut here-- > $ contrib/gcc_update > Updating G

Re: contrib/gcc_update does not work

On Tue, Jan 14, 2020 at 11:34 AM Jonathan Wakely wrote: > > On Tue, 14 Jan 2020 at 09:22, Uros Bizjak wrote: > > > > gcc_update, when called from newly initialized and pulled tree does not > > work: > > Initialized how? 1035 mkdir gcc 1036 cd gcc 1037 git init 1038 git pull https://gcc.

Re: contrib/gcc_update does not work

On Tue, 14 Jan 2020 at 10:38, Uros Bizjak wrote: > > On Tue, Jan 14, 2020 at 11:34 AM Jonathan Wakely > wrote: > > > > On Tue, 14 Jan 2020 at 09:22, Uros Bizjak wrote: > > > > > > gcc_update, when called from newly initialized and pulled tree does not > > > work: > > > > Initialized how? > >

Re: git conversion in progress

Am 11.01.20 um 02:18 schrieb Joseph Myers: I encourage people to continue to work on improving the documentation for using git with GCC ( and list some of the things that it seems

Re: git conversion in progress

On 14/01/2020 11:01, Georg-Johann Lay wrote: > Am 11.01.20 um 02:18 schrieb Joseph Myers: >> I encourage people to continue to work on improving the documentation for >> using git with GCC >> ( and >>

Re: git conversion in progress

On Jan 14 2020, Georg-Johann Lay wrote: > or can be achieved by > > git config [--global] core.editor="...". Space instead of = between key and value. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for somethi

Do we want to add -fsanitize=function?

Hi. The missing sanitizer reports about violations of function signatures for indirect calls, like: $ cat sanitize-function.cpp #include void f() {} void (*fnpointer) (int); void save () { fnpointer = reinterpret_cast(reinterpret_cast(f)); } int main(void) { save (); fnpointer (32); }

Re: git conversion in progress

Am 14.01.20 um 12:34 schrieb Andreas Schwab: On Jan 14 2020, Georg-Johann Lay wrote: git clone --reference original-gcc ... Don't use --reference. It is too easy to lose work if you don't know what you are doing. Andreas. Well, then it should not be proposed in git.html then? There may b

Re: git conversion in progress

On Jan 14 2020, Georg-Johann Lay wrote: > git clone --reference original-gcc ... Don't use --reference. It is too easy to lose work if you don't know what you are doing. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1

Re: git conversion in progress

On Tue, Jan 14, 2020 at 12:34:13PM +0100, Andreas Schwab wrote: > On Jan 14 2020, Georg-Johann Lay wrote: > > > git clone --reference original-gcc ... > > Don't use --reference. It is too easy to lose work if you don't know > what you are doing. Wouldn't git clone --reference original-gcc --dis

Re: Do we want to add -fsanitize=function?

On Tue, Jan 14, 2020 at 12:36:11PM +0100, Martin Liška wrote: > The missing sanitizer reports about violations of function signatures > for indirect calls, like: > > $ cat sanitize-function.cpp > #include > > void f() {} > void (*fnpointer) (int); > > void save () { > fnpointer = reinterpret_

Re: contrib/gcc_update does not work

On Tue, Jan 14, 2020 at 11:44 AM Jonathan Wakely wrote: > > On Tue, 14 Jan 2020 at 10:38, Uros Bizjak wrote: > > > > On Tue, Jan 14, 2020 at 11:34 AM Jonathan Wakely > > wrote: > > > > > > On Tue, 14 Jan 2020 at 09:22, Uros Bizjak wrote: > > > > > > > > gcc_update, when called from newly initi

Re: contrib/gcc_update does not work

On Tue, Jan 14, 2020 at 4:10 AM Richard Biener wrote: > > On Tue, Jan 14, 2020 at 11:44 AM Jonathan Wakely > wrote: > > > > On Tue, 14 Jan 2020 at 10:38, Uros Bizjak wrote: > > > > > > On Tue, Jan 14, 2020 at 11:34 AM Jonathan Wakely > > > wrote: > > > > > > > > On Tue, 14 Jan 2020 at 09:22,

Re: git conversion in progress

On Jan 14 2020, Jakub Jelinek wrote: > On Tue, Jan 14, 2020 at 12:34:13PM +0100, Andreas Schwab wrote: >> On Jan 14 2020, Georg-Johann Lay wrote: >> >> > git clone --reference original-gcc ... >> >> Don't use --reference. It is too easy to lose work if you don't know >> what you are doing. > >

Re: contrib/gcc_update does not work

On Jan 14 2020, Andrew Pinski wrote: > On Tue, Jan 14, 2020 at 4:10 AM Richard Biener > wrote: >> >> On Tue, Jan 14, 2020 at 11:44 AM Jonathan Wakely >> wrote: >> > >> > On Tue, 14 Jan 2020 at 10:38, Uros Bizjak wrote: >> > > >> > > On Tue, Jan 14, 2020 at 11:34 AM Jonathan Wakely >> > > wro

Re: Do we want to add -fsanitize=function?

On 1/14/20 12:54 PM, Jakub Jelinek wrote: On Tue, Jan 14, 2020 at 12:36:11PM +0100, Martin Liška wrote: The missing sanitizer reports about violations of function signatures for indirect calls, like: $ cat sanitize-function.cpp #include void f() {} void (*fnpointer) (int); void save () {

Re: Do we want to add -fsanitize=function?

On Tue, Jan 14, 2020 at 01:57:47PM +0100, Martin Liška wrote: > > seems to be what they emit on x86_64. Now, wonder what they do on other > > targets > > Other targets are not supported :P > > > , and how does it play with all the other options that add stuff > > to the start of functions, e.g.

Re: git conversion in progress

On Tue, 14 Jan 2020 at 11:37, Georg-Johann Lay wrote: > > Am 14.01.20 um 12:34 schrieb Andreas Schwab: > > On Jan 14 2020, Georg-Johann Lay wrote: > > > >> git clone --reference original-gcc ... > > > > Don't use --reference. It is too easy to lose work if you don't know > > what you are doing. >

Re: contrib/gcc_update does not work

On Tue, 14 Jan 2020 at 12:46, Andreas Schwab wrote: > > On Jan 14 2020, Andrew Pinski wrote: > > > On Tue, Jan 14, 2020 at 4:10 AM Richard Biener > > wrote: > >> > >> On Tue, Jan 14, 2020 at 11:44 AM Jonathan Wakely > >> wrote: > >> > > >> > On Tue, 14 Jan 2020 at 10:38, Uros Bizjak wrote: > >

Re: git conversion in progress

On 14/01/2020 13:00, Jonathan Wakely wrote: On Tue, 14 Jan 2020 at 11:37, Georg-Johann Lay wrote: Am 14.01.20 um 12:34 schrieb Andreas Schwab: On Jan 14 2020, Georg-Johann Lay wrote: git clone --reference original-gcc ... Don't use --reference. It is too easy to lose work if you don't kn

Re: Do we want to add -fsanitize=function?

On 1/14/20 1:59 PM, Jakub Jelinek wrote: On Tue, Jan 14, 2020 at 01:57:47PM +0100, Martin Liška wrote: seems to be what they emit on x86_64. Now, wonder what they do on other targets Other targets are not supported :P , and how does it play with all the other options that add stuff to the s

Re: Do we want to add -fsanitize=function?

On Tue, Jan 14, 2020 at 02:56:38PM +0100, Martin Liška wrote: > On 1/14/20 1:59 PM, Jakub Jelinek wrote: > > On Tue, Jan 14, 2020 at 01:57:47PM +0100, Martin Liška wrote: > > > > seems to be what they emit on x86_64. Now, wonder what they do on other > > > > targets > > > > > > Other targets are

Re: git conversion in progress

Hi, On Tue, Jan 14 2020, Andreas Schwab wrote: > On Jan 14 2020, Georg-Johann Lay wrote: > >> git clone --reference original-gcc ... > > Don't use --reference. It is too easy to lose work if you don't know > what you are doing. What are the risks, assuming I won't delete the referenced repo whic

Re: git conversion in progress

On Jan 14 2020, Martin Jambor wrote: > Hi, > > On Tue, Jan 14 2020, Andreas Schwab wrote: >> On Jan 14 2020, Georg-Johann Lay wrote: >> >>> git clone --reference original-gcc ... >> >> Don't use --reference. It is too easy to lose work if you don't know >> what you are doing. > > What are the ris

Re: git conversion in progress

On Tue, 14 Jan 2020 at 14:28, Martin Jambor wrote: > > Hi, > > On Tue, Jan 14 2020, Andreas Schwab wrote: > > On Jan 14 2020, Georg-Johann Lay wrote: > > > >> git clone --reference original-gcc ... > > > > Don't use --reference. It is too easy to lose work if you don't know > > what you are doing

Re: Do we want to add -fsanitize=function?

On 1/14/20 3:00 PM, Jakub Jelinek wrote: But then the compiler should just fail if you mix the two, rather than emitting something that doesn't work at all. Or better fix the design, so that it can grok an endbr64 together with the following jump as another magic. Sure. One can make an error wh

Re: Do we want to add -fsanitize=function?

On Tue, Jan 14, 2020 at 04:15:54PM +0100, Martin Liška wrote: > On 1/14/20 3:00 PM, Jakub Jelinek wrote: > > But then the compiler should just fail if you mix the two, rather than > > emitting something that doesn't work at all. > > Or better fix the design, so that it can grok an endbr64 together

Towards removal of gcc/DATESTAMP

Hi! The following command prints the same string as DATESTAMP file contains in all gcc-7 and later based branches I've tried so far (and nothing when e.g. invoked from within svn checkout). o=$(git config --get gcc-config.upstream); test -z "$o" && o=origin; r=$(cat BASE-VER | cut -d. -f 1); b=

Help with new GCC git workflow...

As somewhat of a git newbie and given gcc developers will do a git push of our changes rather than employing a git pull development model, I'd like a little hand holding on what my new gcc git workflow should be, so I don't screw up the upstream repo by pushing something to the wrong place. :-) I

Re: git conversion in progress

On Tue, 14 Jan 2020, Georg-Johann Lay wrote: > In order to set user.name and user.email, the doc is using --global. At least > for me, the latter is not what I want because I am using git in other contexts > than contributing to GCC (and am using different e-mail then). Using --global is the sim

Re: Whitespace at the start of first line of commit

On Tue, 14 Jan 2020, Jakub Jelinek wrote: > (untested), another, suggested by Richard on IRC, would be to reject > commits where the first line starts with whitespace. I'd suggest making the hooks reject whitespace at the start of the first line of the commit message. -- Joseph S. Myers jos...

Re: git conversion in progress

On Tue, 14 Jan 2020, Georg-Johann Lay wrote: > A branch called branchname can be checked out with the following command: > > git clone -b branchname ... > > Referring to this as "checking out" is confusing IMO, because it may be > confused with > git checkout -b branchname > > Whereas t

Re: git conversion in progress

On Tue, 14 Jan 2020, Richard Earnshaw wrote: > Well it's likely that the server would have to repack the objects on the > fly to supply just one branch; and it does that less well than the base > pack). So you'd probably end up with a much larger initial download > than just fetching the entire h

Re: Towards removal of gcc/DATESTAMP

On Tue, Jan 14, 2020 at 04:52:12PM +0100, Jakub Jelinek wrote: > The following command prints the same string as DATESTAMP file > contains in all gcc-7 and later based branches I've tried so far (and nothing > when > e.g. invoked from within svn checkout). Jonathan wondered on IRC about the weird

Re: Towards removal of gcc/DATESTAMP

On Tue, 14 Jan 2020, Jakub Jelinek wrote: > o=$(git config --get gcc-config.upstream); test -z "$o" && o=origin; r=$(cat > BASE-VER | cut -d. -f 1); b=; if git rev-parse --verify --quiet > $o/releases/gcc-$r >/dev/null; then b=origin/releases/gcc-$r; elif git > rev-parse --verify --quiet $o/rel

Re: Help with new GCC git workflow...

Peter Bergner : > At this point, I get a little confused. :-) I know to submit my patch > for review, I'll want to squash my commits down into one patch, but how > does one do that? Should I do that now or only when I'm ready to > push this change to the upstream repo or ??? Do I need to even do

Re: Help with new GCC git workflow...

On 14/01/20 10:07 -0600, Peter Bergner wrote: As somewhat of a git newbie and given gcc developers will do a git push of our changes rather than employing a git pull development model, I'd like a little hand holding on what my new gcc git workflow should be, so I don't screw up the upstream repo

Re: Help with new GCC git workflow...

Le 14/01/2020 à 17:07, Peter Bergner a écrit : As somewhat of a git newbie and given gcc developers will do a git push of our changes rather than employing a git pull development model, I'd like a little hand holding on what my new gcc git workflow should be, so I don't screw up the upstream repo

Re: Help with new GCC git workflow...

On Tue, Jan 14, 2020 at 12:12 PM Jonathan Wakely wrote: > On 14/01/20 10:07 -0600, Peter Bergner wrote: > >As somewhat of a git newbie and given gcc developers will do a git push of > >our changes rather than employing a git pull development model, I'd like > >a little hand holding on what my new

Re: Help with new GCC git workflow...

On Tue, 14 Jan 2020, Jason Merrill wrote: > I think we're prohibiting merges to master. We definitely don't want > merges of branches with commits that don't each satisfy the normal rules > for commits. Yes. The hooks prevent pushing a merge commit to master or a release branch. A branch can

Re: Help with new GCC git workflow...

On Tue, 14 Jan 2020, Jonathan Wakely wrote: > > ...and this is just for changes going to trunk. How does all this change > > when I want to push changes to a release or vendor branch? > > It's pretty similar. Create a branch from the release branch, merge it > back to the release branch. > > Pe

Re: git conversion in progress

On Tue, Jan 14, 2020 at 9:56 AM Andreas Schwab wrote: > On Jan 14 2020, Martin Jambor wrote: > > > On Tue, Jan 14 2020, Andreas Schwab wrote: > >> On Jan 14 2020, Georg-Johann Lay wrote: > >> > >>> git clone --reference original-gcc ... > >> > >> Don't use --reference. It is too easy to lose w

Re: git conversion in progress

On Tue, 14 Jan 2020, Jason Merrill wrote: > I notice that git.html on the website doesn't match what's currently in > wwwdocs git, is automatic updating broken? /www/gcc/wwwdocs-checkout/cgi-bin/gcc-gitref.cgi had local changes (committed, but not reverted in that checkout before they were commi

Re: git conversion in progress

On Tue, Jan 14, 2020 at 06:06:36PM +, Joseph Myers wrote: > On Tue, 14 Jan 2020, Jason Merrill wrote: > > > I notice that git.html on the website doesn't match what's currently in > > wwwdocs git, is automatic updating broken? > > /www/gcc/wwwdocs-checkout/cgi-bin/gcc-gitref.cgi had local cha

Re: git conversion in progress

Hi, On Tue, Jan 14 2020, Andreas Schwab wrote: > On Jan 14 2020, Martin Jambor wrote: > >> Hi, >> >> On Tue, Jan 14 2020, Andreas Schwab wrote: >>> On Jan 14 2020, Georg-Johann Lay wrote: >>> git clone --reference original-gcc ... >>> >>> Don't use --reference. It is too easy to lose work if

Re: Need sanity check on DSE vs expander issue

On Fri, 2019-12-20 at 12:08 +0100, Richard Biener wrote: > On December 20, 2019 8:25:18 AM GMT+01:00, Jeff Law wrote: > > On Fri, 2019-12-20 at 08:09 +0100, Richard Biener wrote: > > > On December 20, 2019 3:20:40 AM GMT+01:00, Jeff Law > > wrote: > > > > I need a sanity check here. > > > > > >

Re: Help with new GCC git workflow...

On 14/01/20 17:05 +, Jonathan Wakely wrote: On 14/01/20 10:07 -0600, Peter Bergner wrote: As somewhat of a git newbie and given gcc developers will do a git push of our changes rather than employing a git pull development model, I'd like a little hand holding on what my new gcc git workflow

Re: Help with new GCC git workflow...

On 1/14/20 5:45 PM, Jonathan Wakely wrote: On 14/01/20 17:05 +, Jonathan Wakely wrote: On 14/01/20 10:07 -0600, Peter Bergner wrote: As somewhat of a git newbie and given gcc developers will do a git push of our changes rather than employing a git pull development model, I'd like a little

Silly GIT related question

If you just do a clone and don't checkout a branch, is this equivalent the top of the trunk in the old scheme? If not then how do I get the top of trunk? Thanks for your patience, Gary Oblock

Re: Silly GIT related question

On Wed, Jan 15, 2020 at 03:11:13AM +, Gary Oblock wrote: > If you just do a clone and don't checkout a branch, is this equivalent > the top of the trunk in the old scheme? Yes. More details in "git help clone". -- Alan Modra Australia Development Lab, IBM