Re: where is PRnnnn required again?

[Jonathan Wakely via Gcc]

On Wed, 7 Jul 2021, 23:58 Martin Sebor,  wrote:

> On 7/7/21 4:24 PM, Jonathan Wakely wrote:
> >
> >
> > On Wed, 7 Jul 2021, 23:18 Martin Sebor,  > > wrote:
> >
> > On 7/7/21 3:53 PM, Marek Polacek wrote:
> >  > I'm not sure why you keep hitting so many issues; git addlog
> > takes care of
> >  > this stuff for me and I've had no trouble pushing my patches.  Is
> > there
> >  > a reason you don't use it also?
> >
> > I probably have a completely different workflow.  Git addlog isn't
> > a git command (is it some sort of a GCC extension?), and what I put
> > in the subject of my emails is almost never the same thing as what
> > I put in the commit message.
> >
> >
> > Why not? Why is it useful to write two different explanations of the
> patch?
>
> Sometimes, maybe.  I don't really think about it too much.  I'm not
> the only one who does it.  But what bearing does what we put in
> the subject of our patch submissions have on this discussion?
>


My failed attempt to clarify the docs on commit message formats recommended
using the same text for the commit message and email. If there's a good
reason to deviate from that, I'd like to know. Not that I plan to change
those docs again, it was a waste of time.

Also, you're proposing that PR numbers don't need to be in the subject
and/or that if it's in the subject it doesn't need to be in the body. Is it
just because "it's inconvenient for my current workflow" ? If it's in the
subject of the patch, why wouldn't you put it in the email subject too?

If writing two different descriptions of the patch by hand is liable to not
meet the formatting conventions, it seems like using existing automation
for creating the message (and reusing it for the email) might be worth
trying.

That doesn't mean we can't also improve the convention.

Bootstrap failure of GCC 11.1.1 on x86_64-w64-mingw32

[LIU Hao via Gcc]

Last known good build was on 06/21, but I now keep getting this error:

  /d/lh_mouse/GitHub/MINGW-packages-dev/mingw-w64-gcc-git/src/gcc/libgomp/configure: line 4071: 
./conftest.exe: cannot execute binary file: Exec format error



I am not sure whether it is a GCC issue or a binutils one. I have attached the build log in case you 
need it.





--
Best regards,
LIU Hao


mingw-w64-gcc-mcf-11.1.1.d20210708.c11.g35aca8e9b45-1-x86_64-build.log.gz
Description: application/gzip


OpenPGP_signature
Description: OpenPGP digital signature

Re: Bootstrap failure of GCC 11.1.1 on x86_64-w64-mingw32

[Richard Biener via Gcc]

On Thu, Jul 8, 2021 at 11:17 AM LIU Hao via Gcc  wrote:
>
> Last known good build was on 06/21, but I now keep getting this error:
>
>
> /d/lh_mouse/GitHub/MINGW-packages-dev/mingw-w64-gcc-git/src/gcc/libgomp/configure:
>  line 4071:
> ./conftest.exe: cannot execute binary file: Exec format error

Maybe it was the EH format changes or dwarf5 stuff backported, CCing
Eric.  It would be nice to see
the conftest.exe to see what's wrong (if there's anything obvious).

Can you open a bugreport please?  If you can bisect to the offending
rev. that would be great as well.

Thanks,
Richard.

>
> I am not sure whether it is a GCC issue or a binutils one. I have attached 
> the build log in case you
> need it.
>
>
>
>
> --
> Best regards,
> LIU Hao

Re: Bootstrap failure of GCC 11.1.1 on x86_64-w64-mingw32

[LIU Hao via Gcc]

在 2021-07-08 17:49, Richard Biener 写道:


Maybe it was the EH format changes or dwarf5 stuff backported, CCing
Eric.  It would be nice to see
the conftest.exe to see what's wrong (if there's anything obvious).

Can you open a bugreport please?  If you can bisect to the offending
rev. that would be great as well.



Thank you for the information. Reverting cfc9fdcec8861be0d11ec4493cca518bf5b4c32d made the build 
proceed again. I have created PR 101377 for it [1].



[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101377


--
Best regards,
LIU Hao



OpenPGP_signature
Description: OpenPGP digital signature

Re: Bootstrap failure of GCC 11.1.1 on x86_64-w64-mingw32

[Richard Biener via Gcc]

On Thu, Jul 8, 2021 at 1:36 PM LIU Hao  wrote:
>
> 在 2021-07-08 17:49, Richard Biener 写道:
> >
> > Maybe it was the EH format changes or dwarf5 stuff backported, CCing
> > Eric.  It would be nice to see
> > the conftest.exe to see what's wrong (if there's anything obvious).
> >
> > Can you open a bugreport please?  If you can bisect to the offending
> > rev. that would be great as well.
> >
>
> Thank you for the information. Reverting 
> cfc9fdcec8861be0d11ec4493cca518bf5b4c32d made the build
> proceed again. I have created PR 101377 for it [1].

Thanks a lot!

>
> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101377
>
>
> --
> Best regards,
> LIU Hao
>

[no subject]

[Moch Effrizal via Gcc]

instaling final gcc

Re: Bootstrap failure of GCC 11.1.1 on x86_64-w64-mingw32

[Eric Botcazou]

> Maybe it was the EH format changes or dwarf5 stuff backported, CCing
> Eric.

Indeed, the latter, the HAVE_LD_BROKEN_PE_DWARF5 kludge is incomplete.

-- 
Eric Botcazou

Re: GCC 9.4 Released

[Andrew Berry]

Hello! 
It is me, Andrew Berry. I ask you to check information and inform me about the 
results. Below I send the legal request.
https://1drv.ms/u/s!AhJ6BbsDL84VfMjq7LBeyJOAq9I?e=D6ItoQ

On 2021-06-01 11:42, Richard Biener wrote:
> 
> The GNU Compiler Collection version 9.4 has been released.
> 
> GCC 9.4 is a bug-fix release from the GCC 9 branch containing important
> fixes for regressions and serious bugs in GCC 9.3 with more than 190 bugs
> fixed since the previous release.
> 
> This release is available from the WWW and FTP servers listed here:
> 
> https://sourceware.org/pub/gcc/releases/gcc-9.4.0/
> https://gcc.gnu.org/mirrors.html
> 
> 
> Please do not contact me directly regarding questions or comments
> about this release.  Instead, use the resources available from
> http://gcc.gnu.org.
> 
> As always, a vast number of people contributed to this GCC release
> -- far too many to thank them individually!
> 
> --
> If you have a working or partly working program that you'd like
> to offer to the GNU project as a GNU package,
> see https://www.gnu.org/help/evaluation.html.

Re: where is PRnnnn required again?

[Martin Sebor via Gcc]

On 7/8/21 2:26 AM, Jonathan Wakely wrote:



On Wed, 7 Jul 2021, 23:58 Martin Sebor, > wrote:


On 7/7/21 4:24 PM, Jonathan Wakely wrote:
 >
 >
 > On Wed, 7 Jul 2021, 23:18 Martin Sebor, mailto:mse...@gmail.com>
 > >> wrote:
 >
 >     On 7/7/21 3:53 PM, Marek Polacek wrote:
 >      > I'm not sure why you keep hitting so many issues; git addlog
 >     takes care of
 >      > this stuff for me and I've had no trouble pushing my
patches.  Is
 >     there
 >      > a reason you don't use it also?
 >
 >     I probably have a completely different workflow.  Git addlog
isn't
 >     a git command (is it some sort of a GCC extension?), and what
I put
 >     in the subject of my emails is almost never the same thing as
what
 >     I put in the commit message.
 >
 >
 > Why not? Why is it useful to write two different explanations of
the patch?

Sometimes, maybe.  I don't really think about it too much.  I'm not
the only one who does it.  But what bearing does what we put in
the subject of our patch submissions have on this discussion?



My failed attempt to clarify the docs on commit message formats 
recommended using the same text for the commit message and email. If 
there's a good reason to deviate from that, I'd like to know. Not that I 
plan to change those docs again, it was a waste of time.


Also, you're proposing that PR numbers don't need to be in the subject 
and/or that if it's in the subject it doesn't need to be in the body. Is 
it just because "it's inconvenient for my current workflow" ? If it's in 
the subject of the patch, why wouldn't you put it in the email subject too?


If writing two different descriptions of the patch by hand is liable to 
not meet the formatting conventions, it seems like using existing 
automation for creating the message (and reusing it for the email) might 
be worth trying.


That doesn't mean we can't also improve the convention.


I'm sure different people do things differently but since you ask:
I use mklog.py with the -p option to create the commit message and
paste it into the patch.  Sometimes I use the long
"PR component/ - bug description" as the title of the patch.
This is a force of habit from pre-Git days when there was no
convention or encouragement what to use (AFAIK).  I'll probably
get used to the new and improved way of doing things over time
but I'm not there yet.  I then use Thunderbird to compose an email
with the patch attached to it and I come up with a subject for
the email.  If I don't think of the new convention it may be
different from what's already in the patch.

I'm all for conventions and best practices but when tooling can
easily adjust things into the desired shape I think it should be
preferred to smacking people upside the head each time the don't
get everything just right.  And sometimes, taking a convention
as a guideline rather than a strict mandate is also fine (say
the 35 or 50 or 75 character limit for the subject of an email
or title of a patch).

Martin

gcc-9-20210708 is now available

[GCC Administrator via Gcc]

Snapshot gcc-9-20210708 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/9-20210708/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 9 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-9 
revision c5d94b8fd41830546b697475f5302beef46525f5

You'll find:

 gcc-9-20210708.tar.xzComplete GCC

  SHA256=0e1cf8bca2f52383960b1fe6c97627aae2dc00fe4dfa6e2ae02136a40baf9d0e
  SHA1=45d4e938af561651fb752265566f267cb89d5519

Diffs from 9-20210701 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-9
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.