Third GC 13.1 Release Candidate available from gcc.gnu.org

[Richard Biener via Gcc]

The third release candidate for GCC 13.1 is available from

 https://gcc.gnu.org/pub/gcc/snapshots/13.1.0-RC-20230421/
 ftp://gcc.gnu.org/pub/gcc/snapshots/13.1.0-RC-20230421/

and shortly its mirrors.  It has been generated from git commit
r13-7231-gf980561c60b044.

It contains a fix for https://gcc.gnu.org/PR109564 which we
introduced late by improving a fix for an issue in the same area.
It also contains a fix for https://gcc.gnu.org/PR109556.

I have so far bootstrapped and tested the release candidate on
x86_64-linux.  Please test it and report any issues to bugzilla.

If all goes well, we'd still like to release 13.1 on Wednesday, April 
26th.

Re: [PATCH] sockaddr.3type: Document that sockaddr_storage is the API to be used

[Alejandro Colomar via Gcc]

Hi Eric,

On 4/14/23 18:08, Zack Weinberg via Libc-alpha wrote:
> On 2023-04-06 3:37 PM, Eric Blake wrote:
>> Since Issue 7 is tied to C99, and Issue 8 will be tied to C17, both of
>> which use the same section number despite being a different edition of
>> the C standard, being that specific may work.  Or, we might try
>> something focusing more on wording instead of document location, as
>> in:
>>
>> Additionally, the structures shall be defined in such a way that the
>> compiler treats an access to the stored value of the sa_family_t
>> member of any of these structures, via an lvalue expression whose type
>> involves any other one of these structures, as permissible even if the
>> types involved would not otherwise be deemed compatible with the
>> effective type of the object ultimately being accessed.

The wording I see in 
doesn't seem to cover the case of aliasing a sockaddr_storage as a
protocol-specific address for setting other members.

Aliasing rules don't allow one to declare an object of type
sockaddr_storage and then fill the structure as if it were another
structure, even if alignment and size are correct.  We would need
some wording that says something like:

When a pointer to a sockaddr_storage structure is first aliased as a
pointer to a protocol-specific address structure, the effective type
of the object will be set to the protocol-specific structure.

This is similar to what happens when malloc(3) is assigned to a
non-character type.  That's a big hammer, but it does the job.  Maybe
we would need some looser language?  I CCd GCC, in case they have
concerns about this wording.

Cheers,
Alex

> 
> I quite like this way of putting it.  It subsumes both what I wrote and 
> the related potential headache with deciding whether the sa_family_t 
> field is considered an object or just a range of bytes within a larger 
> object.
> 
> zw

-- 

GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH] sockaddr.3type: Document that sockaddr_storage is the API to be used

[Alejandro Colomar via Gcc]

On 4/21/23 16:58, Alejandro Colomar wrote:
> Hi Eric,
> 
> On 4/14/23 18:08, Zack Weinberg via Libc-alpha wrote:
>> On 2023-04-06 3:37 PM, Eric Blake wrote:
>>> Since Issue 7 is tied to C99, and Issue 8 will be tied to C17, both of
>>> which use the same section number despite being a different edition of
>>> the C standard, being that specific may work.  Or, we might try
>>> something focusing more on wording instead of document location, as
>>> in:
>>>
>>> Additionally, the structures shall be defined in such a way that the
>>> compiler treats an access to the stored value of the sa_family_t
>>> member of any of these structures, via an lvalue expression whose type
>>> involves any other one of these structures, as permissible even if the
>>> types involved would not otherwise be deemed compatible with the
>>> effective type of the object ultimately being accessed.
> 
> The wording I see in 
> doesn't seem to cover the case of aliasing a sockaddr_storage as a
> protocol-specific address for setting other members.
> 
> Aliasing rules don't allow one to declare an object of type
> sockaddr_storage and then fill the structure as if it were another
> structure, even if alignment and size are correct.  We would need
> some wording that says something like:
> 
> When a pointer to a sockaddr_storage structure is first aliased as a
> pointer to a protocol-specific address structure, the effective type
> of the object will be set to the protocol-specific structure.
> 
> This is similar to what happens when malloc(3) is assigned to a
> non-character type.  That's a big hammer, but it does the job.  Maybe
> we would need some looser language?  I CCd GCC, in case they have
> concerns about this wording.
> 
> Cheers,
> Alex
> 
>>
>> I quite like this way of putting it.  It subsumes both what I wrote and 
>> the related potential headache with deciding whether the sa_family_t 
>> field is considered an object or just a range of bytes within a larger 
>> object.
>>
>> zw
> 

For the man pages, I've rewritten it to the following:


$ git diff
diff --git a/man3type/sockaddr.3type b/man3type/sockaddr.3type
index 2fdf56c59..e610aa0f5 100644
--- a/man3type/sockaddr.3type
+++ b/man3type/sockaddr.3type
@@ -117,6 +117,14 @@ .SH HISTORY
 was invented by POSIX.
 See also
 .BR accept (2).
+.PP
+These structures were invented before modern ISO C strict-aliasing rules.
+If aliasing rules are applied strictly,
+these structures would be impossible to use
+without invoking Undefined Behavior (UB).
+POSIX Issue 8 will fix this by requiring that implementations
+make sure that these structures
+can be safely used as they were designed.
 .SH NOTES
 .I socklen_t
 is also defined in


I guess this is simple enough that it should work as documentation.

-- 

GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH] sockaddr.3type: Document that sockaddr_storage is the API to be used

[Eric Blake via Gcc]

On Fri, Apr 21, 2023 at 05:00:14PM +0200, Alejandro Colomar wrote:
> > 
> > The wording I see in 
> > doesn't seem to cover the case of aliasing a sockaddr_storage as a
> > protocol-specific address for setting other members.
> > 
> > Aliasing rules don't allow one to declare an object of type
> > sockaddr_storage and then fill the structure as if it were another
> > structure, even if alignment and size are correct.  We would need
> > some wording that says something like:
> > 
> > When a pointer to a sockaddr_storage structure is first aliased as a
> > pointer to a protocol-specific address structure, the effective type
> > of the object will be set to the protocol-specific structure.

I'll add that as a comment to the Austin Group page; it seems like a
reasonable statement of intent (POSIX already says that struct
sockaddr_storage is sufficiently sized and aligned; all that remains
is for the compiler to be aware that we intend to use a
more-appropriate effective type once we have the storage allocated).

> > 
> > This is similar to what happens when malloc(3) is assigned to a
> > non-character type.  That's a big hammer, but it does the job.  Maybe
> > we would need some looser language?  I CCd GCC, in case they have
> > concerns about this wording.
> > 
> > Cheers,
> > Alex
> > 
> >>
> >> I quite like this way of putting it.  It subsumes both what I wrote and 
> >> the related potential headache with deciding whether the sa_family_t 
> >> field is considered an object or just a range of bytes within a larger 
> >> object.
> >>
> >> zw
> > 
> 
> For the man pages, I've rewritten it to the following:
> 
> 
> $ git diff
> diff --git a/man3type/sockaddr.3type b/man3type/sockaddr.3type
> index 2fdf56c59..e610aa0f5 100644
> --- a/man3type/sockaddr.3type
> +++ b/man3type/sockaddr.3type
> @@ -117,6 +117,14 @@ .SH HISTORY
>  was invented by POSIX.
>  See also
>  .BR accept (2).
> +.PP
> +These structures were invented before modern ISO C strict-aliasing rules.
> +If aliasing rules are applied strictly,
> +these structures would be impossible to use

Maybe "extremely difficult" instead of "impossible" to use (if I
understand this thread correctly, it is possible to memcpy() from one
struct into different storage of a different effective type where the
memcpy()'s intermediate aliasing through char* avoids the UB).

> +without invoking Undefined Behavior (UB).
> +POSIX Issue 8 will fix this by requiring that implementations
> +make sure that these structures
> +can be safely used as they were designed.
>  .SH NOTES
>  .I socklen_t
>  is also defined in
> 
> 
> I guess this is simple enough that it should work as documentation.

It seems fine from my perspective.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Re: gcc parameter -mcrtdll= for choosing Windows C RunTime DLL library

[Pali Rohár via Gcc]

On Sunday 04 December 2022 20:48:30 LIU Hao wrote:
> 在 2022-12-04 20:16, Pali Rohár via Gcc 写道:
> > Hello! I would like to ask gcc people, what do you think about such
> > proposed -mcrtdll= parameter?
> > 
> > There are lot of unofficial gcc patches which implement this -mcrtdll=
> > parameter and this parameter is present in more gcc forks.
> > So it looks like that this parameter is useful for more people.
> > 
> 
> I vote +1 for this in GCC 14.
> 
> GCC 13 (i.e. current master branch) is at stage3 so it's not an option at 
> this moment.
> 
> 
> -- 
> Best regards,
> LIU Hao
> 

Hello! If I'm looking correctly, gcc 13 was already branched. So what
revisiting this -mcrtdll= parameter now?

Re: GCC-13 Branch with RISC-V Performance-Related Backports

[Sam James via Gcc]

Palmer Dabbelt  writes:

> We talked about this a bit on IRC, but just to reflect it to the
> mailing lists:
>
> On Tue, 18 Apr 2023 05:34:11 PDT (-0700), s...@gentoo.org wrote:
>>
>> Palmer Dabbelt  writes:
>>
>>> Based on some discussions, it looks like a handful of vendors are
>>> planning on maintaining GCC-13 branches that include various
>>> performance-related backports (ie, patches not suitable for the
>>> standard GCC-13 release branch).
>>>
>>> I don't think we'd actually agreed to a set of branch rules, but it
>>> seems like the following were where the discussion ended up:
>>>
>>> * Make a "riscv" vendor branch.  I don't think we came up with a name,
>>>   but "riscv/gcc-13-perf" seems fine to me.
>>> * Regularly rebase the branch on the GCC-13 release branch.
>>> * Only accept backports that have landed on trunk.
>>
>> I'm a bit concerned about how distributions are supposed to handle this.
>>
>> I can see riscv enthusiasts asking us to package the vendor branch -
>> which presumably won't get automatic snapshots created, so that's a bit
>> more manual work already. But supposing we switched to it entirely for
>> riscv, that might be ok. But what if there's also users who want the
>> conservative setup?
>>
>> This feels (not to be a downer, sorry!) like a mess in the making
>> from the distribution perspective.
>
> No problem, that's why we have these sorts of threads.
>
>> I've got to ask: given riscv isn't yet (as far as I understand), a
>> "premier platform" in GCC terms, couldn't you just be more liberal
>> with backports for riscv at least up until 13.2, or similar?
>
> We've been pretty liberal about backports, but there's always some
> stuff that's just too much to for the standard branch.  It's looking
> like 14 is shaping up to be a big one because of all the vector work
> going on, a lot of which is likely to touch core GCC code.
>

Fair point.

>> This is also a lot of work for a platform I don't even have access to
>> (we have Gentoo developers with riscv hardware, but not sure any of
>> it is powerful enough to be regularly testing this in addition to
>> the regular branch for riscv). If even a handful of other arches started
>> doing this, I would be completely overwhelmed with work.
>>
>> Would this also be a long-term thing or just for 13?
>
> We've essentailly done this for every release, it's just been at the
> RISC-V github.  Ideally we'll stop needing to be special, but given
> the history that might take a while.  The difference here is that
> we're trying to keep this at sourceware intsead of the RISC-V github,
> but that's really just because we've had so many headaches with RVI.
>
> As to whether or not distros ship it: I've always been against distros
> shipping the RISC-V branches, as they're full of stuff that's not
> suitable for normal GCC releases and those policies are in place for a
> reason.  I know there's some vendors who ship them, but that's mostly
> in the embedded space and folks tend to have out of tree patches
> anyway so no big deal.
>
> I treat these as more of a performance preview of the next GCC
> release, a handful of vendors were maintaining those internally.  I'd
> love if we could just use trunk for that, but it's generally not
> viable because too much stuff fails to build.

Thanks Palmer, I didn't realise this context - having this to refer to
is enough for me, because if nothing else, if someone asks me about it,
I can cite this :)

That makes sense to me & thank you for explaining!

>
>>> There's a few others that I'd like to add, just based on poking around:
>>>
>>> * No new regressions for anything that's backported.
>>> * Use "git cherry-pick -x" from the trunk commit.
>>>
>>> We're starting to land some gcc-14 patches already, so I'd prefer to
>>> make the branch sooner rather than later.  Unless there's any
>>> objections, I'll push what's at
>>> github.com/palmer-dabbelt/gcc/gcc-13-perf as a vendor branch.
>>
>> thanks,
>> sam

best,
sam


signature.asc
Description: PGP signature

[PATCH v3] sockaddr.3type: POSIX Issue 8 will solve strict-aliasing issues with these types

[Alejandro Colomar via Gcc]

Link: 
Reported-by: Bastien Roucariès 
Reported-by: Alejandro Colomar 
Reviewed-by: Eric Blake 
Cc: glibc 
Cc: GCC 
Cc: Stefan Puiu 
Cc: Igor Sysoev 
Cc: Rich Felker 
Cc: Andrew Clayton 
Cc: Richard Biener 
Cc: Zack Weinberg 
Cc: Florian Weimer 
Cc: Joseph Myers 
Cc: Jakub Jelinek 
Cc: Sam James 
Signed-off-by: Alejandro Colomar 
---

Hi Eric,

I took your informal review as a "Reviewed-by".  Please confirm.
I've also modified the small wording thingy you suggested.

I'll float this patch in the list in case anyone has comments, and
will push some time this weekend (depending on many variables).

Cheers,
Alex

 man3type/sockaddr.3type | 8 
 1 file changed, 8 insertions(+)

diff --git a/man3type/sockaddr.3type b/man3type/sockaddr.3type
index 2fdf56c59..cf8d601f5 100644
--- a/man3type/sockaddr.3type
+++ b/man3type/sockaddr.3type
@@ -117,6 +117,14 @@ .SH HISTORY
 was invented by POSIX.
 See also
 .BR accept (2).
+.PP
+These structures were invented before modern ISO C strict-aliasing rules.
+If aliasing rules are applied strictly,
+these structures would be extremely difficult to use
+without invoking Undefined Behavior.
+POSIX Issue 8 will fix this by requiring that implementations
+make sure that these structures
+can be safely used as they were designed.
 .SH NOTES
 .I socklen_t
 is also defined in
-- 
2.40.0

Re: [PATCH v3] sockaddr.3type: POSIX Issue 8 will solve strict-aliasing issues with these types

[Eric Blake via Gcc]

On Fri, Apr 21, 2023 at 10:27:18PM +0200, Alejandro Colomar wrote:
> Link: 
> Reported-by: Bastien Roucariès 
> Reported-by: Alejandro Colomar 
> Reviewed-by: Eric Blake 
> Cc: glibc 
> Cc: GCC 
> Cc: Stefan Puiu 
> Cc: Igor Sysoev 
> Cc: Rich Felker 
> Cc: Andrew Clayton 
> Cc: Richard Biener 
> Cc: Zack Weinberg 
> Cc: Florian Weimer 
> Cc: Joseph Myers 
> Cc: Jakub Jelinek 
> Cc: Sam James 
> Signed-off-by: Alejandro Colomar 
> ---
> 
> Hi Eric,
> 
> I took your informal review as a "Reviewed-by".  Please confirm.
> I've also modified the small wording thingy you suggested.

For the avoidance of doubt ;)

Reviewed-by: Eric Blake 


-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Re: Third GC 13.1 Release Candidate available from gcc.gnu.org

[William Seurer via Gcc]

I bootstrapped and tested this on powerpc64 power 7, 8, 9, and 10 and on 
both BE and LE and saw nothing unexpected.


On 4/21/23 2:47 AM, Richard Biener via Gcc wrote:

The third release candidate for GCC 13.1 is available from

  https://gcc.gnu.org/pub/gcc/snapshots/13.1.0-RC-20230421/
  ftp://gcc.gnu.org/pub/gcc/snapshots/13.1.0-RC-20230421/

and shortly its mirrors.  It has been generated from git commit
r13-7231-gf980561c60b044.

It contains a fix for https://gcc.gnu.org/PR109564 which we
introduced late by improving a fix for an issue in the same area.
It also contains a fix for https://gcc.gnu.org/PR109556.

I have so far bootstrapped and tested the release candidate on
x86_64-linux.  Please test it and report any issues to bugzilla.

If all goes well, we'd still like to release 13.1 on Wednesday, April
26th.

gcc-12-20230421 is now available

[GCC Administrator via Gcc]

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

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

You'll find:

 gcc-12-20230421.tar.xz   Complete GCC

  SHA256=9e6e42d2e02db6c9c0bd01eb7ae79eaa6d699803ee0cebf5bd2f6b8e5cdb1cab
  SHA1=2b3e457fef2f5df4c907f39b33201ac4577fc26a

Diffs from 12-20230415 are available in the diffs/ subdirectory.

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