Scripts to build Cross-GCC, Clang, and QEMU on Cygwin and MSYS2/MinGW-w64
Hi, friends I have some scripts to build Cross-GCC, Clang, and QEMU on Cygwin and MSYS2/MinGW-w64 at: https://github.com/xu-chiheng/Tool I hope the scripts are useful for those interested in building the projects on Windows.
gcc-11-20230518 is now available
Snapshot gcc-11-20230518 is now available on https://gcc.gnu.org/pub/gcc/snapshots/11-20230518/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 11 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-11 revision ae5112f230f05e8a693931a44bf2fd20bef58f85 You'll find: gcc-11-20230518.tar.xz Complete GCC SHA256=69133190a97bcfb2ab5da7e7144ede77866bcc7e62009ce274a6ee05532b23f8 SHA1=07d94c79a121eefbed058672e1e5ae137313f992 Diffs from 11-20230511 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-11 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.
Re: [wish] Flexible array members in unions
> On May 18, 2023, at 12:25 PM, Martin Uecker via Gcc wrote:
>
>
>
>> On Thu, May 11, 2023 at 11:14 PM Kees Cook via Gcc wrote:
>>>
>>> On Thu, May 11, 2023 at 08:53:52PM +, Joseph Myers wrote:
On Thu, 11 May 2023, Kees Cook via Gcc wrote:
> On Thu, May 11, 2023 at 06:29:10PM +0200, Alejandro Colomar wrote:
>> On 5/11/23 18:07, Alejandro Colomar wrote:
>> [...]
>>> Would you allow flexible array members in unions? Is there any
>>> strong reason to disallow them?
>
> Yes please!! And alone in a struct, too.
>
> AFAICT, there is no mechanical/architectural reason to disallow them
> (especially since they _can_ be constructed with some fancy tricks,
> and they behave as expected.) My understanding is that it's disallowed
> due to an overly strict reading of the very terse language that created
> flexible arrays in C99.
Standard C has no such thing as a zero-size object or type, which would
lead to problems with a struct or union that only contains a flexible
array member there.
>
> (I think it is fundamentally not too problematic to have zero-size
> objects, although it would take some work to specify the semantics
> exactly.)
>
> But my preference would be to make structs / unions with FAM an
> incomplete type which would then restrict their use (for the cases
> now supported we would need backwards compatible exceptions).
> We could then allow such a struct / union as the last member
> of another struct / union which would make this an incomplete
> type too.
Yes, I like this approach.
And we can make them GCC extensions first, promote to C standard later.
My proposed patch sets (originally targeted on GCC13, now might need to target
on GCC14) will
make one part of the above a GCC extension:
Allowing the struct with FAM as the last member of another struct. (See
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101832)
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614794.html
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614793.html
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614790.html
I’d like these changes going into GCC first to improve this area.
>
> We then would need a special macro (based on a builtin) instead
> of sizeof to get the size, but this would be safer anyway.
>
> In principle, an even better solution would be to allow dynamic
> arrays because then it has a dynamic bound where the type with
> the bound could propagate to some user. Bounds checking would
> work as expected and more cases.
>
> struct foo {
> int len;
> char buf[.len];
> };
>
> But this takes a bit more work to get right.
>
>>>
>>> Ah-ha, okay. That root cause makes sense now.
>>
>> Hmm. but then the workaround
>>
>> struct X {
>> int n;
>> union u {
>> char at_least_size_one;
>> int iarr[];
>> short sarr[];
>> };
>> };
>>
>> doesn't work either. We could make that a GNU extension without
>> adverse effects?
>
> I think we could allow this even without the "at_least_size_one"
> without a problem when allowing the use of such unions only as
> a last member of some structure. Allowing it elsewhere seems
> questionable anyway.
Yes, Such an union can be treated as an flexible array member
(just multiple flexible arrays sharing the same storage). Therefore it’s
reasonable
To only allow it as the last field of a structure.
thanks.
Qing.
>
>> Richard.
>>
>>> Why are zero-sized objects missing in Standard C? Or, perhaps, the better
>>> question is: what's needed to support the idea of a zero-sized object?
>
> Probably a lot of convincing that it actually does not cause problems,
> and is useful. Also a lot of work in making sure the standard is revised
> everywhere where it is necessary. I think zero sized objects and
> especially arrays are very useful also to avoid special code for corner
> cases in numerical algorithms. But I think here some restrictions on
> the use of the FAM will do.
>
>
> Martin
Re: [wish] Flexible array members in unions
> On Thu, May 11, 2023 at 11:14 PM Kees Cook via Gcc wrote:
> >
> > On Thu, May 11, 2023 at 08:53:52PM +, Joseph Myers wrote:
> > > On Thu, 11 May 2023, Kees Cook via Gcc wrote:
> > >
> > > > On Thu, May 11, 2023 at 06:29:10PM +0200, Alejandro Colomar wrote:
> > > > > On 5/11/23 18:07, Alejandro Colomar wrote:
> > > > > [...]
> > > > > > Would you allow flexible array members in unions? Is there any
> > > > > > strong reason to disallow them?
> > > >
> > > > Yes please!! And alone in a struct, too.
> > > >
> > > > AFAICT, there is no mechanical/architectural reason to disallow them
> > > > (especially since they _can_ be constructed with some fancy tricks,
> > > > and they behave as expected.) My understanding is that it's disallowed
> > > > due to an overly strict reading of the very terse language that created
> > > > flexible arrays in C99.
> > >
> > > Standard C has no such thing as a zero-size object or type, which would
> > > lead to problems with a struct or union that only contains a flexible
> > > array member there.
(I think it is fundamentally not too problematic to have zero-size
objects, although it would take some work to specify the semantics
exactly.)
But my preference would be to make structs / unions with FAM an
incomplete type which would then restrict their use (for the cases
now supported we would need backwards compatible exceptions).
We could then allow such a struct / union as the last member
of another struct / union which would make this an incomplete
type too.
We then would need a special macro (based on a builtin) instead
of sizeof to get the size, but this would be safer anyway.
In principle, an even better solution would be to allow dynamic
arrays because then it has a dynamic bound where the type with
the bound could propagate to some user. Bounds checking would
work as expected and more cases.
struct foo {
int len;
char buf[.len];
};
But this takes a bit more work to get right.
> >
> > Ah-ha, okay. That root cause makes sense now.
>
> Hmm. but then the workaround
>
> struct X {
> int n;
> union u {
> char at_least_size_one;
> int iarr[];
> short sarr[];
> };
> };
>
> doesn't work either. We could make that a GNU extension without
> adverse effects?
I think we could allow this even without the "at_least_size_one"
without a problem when allowing the use of such unions only as
a last member of some structure. Allowing it elsewhere seems
questionable anyway.
> Richard.
>
> > Why are zero-sized objects missing in Standard C? Or, perhaps, the better
> > question is: what's needed to support the idea of a zero-sized object?
Probably a lot of convincing that it actually does not cause problems,
and is useful. Also a lot of work in making sure the standard is revised
everywhere where it is necessary. I think zero sized objects and
especially arrays are very useful also to avoid special code for corner
cases in numerical algorithms. But I think here some restrictions on
the use of the FAM will do.
Martin
Re: LSP based on GCC
On Thu, 2023-05-18 at 10:52 -0400, Ben Boeckel wrote: > PCH files can "be ignored" in some sense because they can be > recalculated from `#include` files pretty easily. Module files, > however, cannot. This makes it even more important that there be a GCC-based LSP server, if a Clang-based one can't read GCC module files AND module files are required to exist. Without a GCC-based LSP server, it means you have to build your modules for _both_ GCC (for compilation) _and_ Clang (for LSP) which would be extremely frustrating. It would also likely make Eli's initial contention that you need to install a full Clang compiler to use a Clang-based LSP server, into a reality.
Re: LSP based on GCC
On Thu, May 18, 2023 at 09:25:04 -0400, Paul Smith wrote: > On Wed, 2023-05-17 at 18:38 -0400, Ben Boeckel wrote: > > FWIW, this is only going to get worse with C++ modules. > > There's no reason it should. Of course the right answer is to tell > people to fix their build systems and if they want to use a different > compiler AND use PCH, they use the appropriate suffix for that > compiler. > > But even if you don't want to do that the fix in this case is trivial. > I even sent a patch (although since I don't know the clang code there's > no doubt that it was not done "the right way" and needed to be > massaged), they just never cared about it. > > The GCC PCH files use a special 4-byte prefix in every file; all you > have to do in clang is, if you find a .gch file open the file and read > the first 4 bytes and if it's a real GCC PCH file you ignore it and if > it's actually a Clang PCH with a malformed name you complain bitterly > and dump core er, I mean, you read it silently as if it had the > right name. PCH files can "be ignored" in some sense because they can be recalculated from `#include` files pretty easily. Module files, however, cannot. > One would hope that, if the GCC module files have a similar compiler- > specific format (I'm not too familiar with modules) they also use a > similar magic number at the beginning of the file. GCC module files are use ELF containers, so there's plenty of metadata to know it's not-for-Clang. But Clang will need to make its own version of these module files to know what, if anything, is provided by it by sources that import it to make any kind of useful suggestions. > But anyway this is losing the thread of Eli's hopeful request. Agreed. A GCC-based LSP will help immensely with GCC-using projects (whether it be Emacs or Vim on the other end of the LSP pipe ;) ). --Ben
Re: LSP based on GCC
On Wed, May 17, 2023 at 11:47 AM David Malcolm via Gcc wrote: > On Wed, 2023-05-17 at 17:28 +0300, Eli Zaretskii via Gcc wrote: > > Dear GCC developers, > > [CCing Frank, re the systemtap LSP implementation] > > Hi Eli > > > Emacs 29, to be released soon, will come with a built-in client for > > the LSP protocol. This allows to enhance important Emacs features, > > such as at-point documentation, on-the-fly diagnostic annotations, > > finding definitions and uses of program identifiers, enhanced > > completion of symbols and code, etc., based on capabilities of LSP > > servers. > > Excellent. Do you have a handy link to the specific LSP methods that > Emacs consumes? > > > > > The Emacs LSP client comes with support for many popular LSP servers > > OOTB and for all the programming languages supported by Emacs. > > However, all the available servers for C and C++ languages are based > > on Clang. AFAIU, this is because GCC does not yet have its own > > implementation of the LSP. I found this message posted to gcc- > > patches > > in 2017: > > > > https://gcc.gnu.org/legacy-ml/gcc-patches/2017-07/msg01448.html > > > > which described the initial implementation of LSP in GCC, but I seem > > to be unable to find out what happened with that since then. > > > > Are there plans for implementing the LSP in GCC? If so, which GCC > > version is expected to have this included? > > I wrote that prototype, but I haven't touched it since 2017, and I > already have more than enough other work, alas. I'm happy to help if > someone wants to pick up the work and finish it. > Maybe create a BZ and gcc.gnu.org/projects entry for this work? Jason
Re: LSP based on GCC
On Wed, 2023-05-17 at 18:38 -0400, Ben Boeckel wrote: > > egregious example I'm aware of is that they look for GCC-named > > precompiled headers (.gch), even though the Clang PCH format is > > completely different. So if Clang (and the LSP servers built on > > it) find a .gch header file they will try to read it, fail, and > > give an error. I filed a bug about this in 2019 but it's been > > ignored. > > > > This means you need to modify your LSP server arguments to omit any > > PCH compiler command line arguments; for environments based on > > auto-generated definitions like compile_commands.json this is > > frustrating. > > FWIW, this is only going to get worse with C++ modules. There's no reason it should. Of course the right answer is to tell people to fix their build systems and if they want to use a different compiler AND use PCH, they use the appropriate suffix for that compiler. But even if you don't want to do that the fix in this case is trivial. I even sent a patch (although since I don't know the clang code there's no doubt that it was not done "the right way" and needed to be massaged), they just never cared about it. The GCC PCH files use a special 4-byte prefix in every file; all you have to do in clang is, if you find a .gch file open the file and read the first 4 bytes and if it's a real GCC PCH file you ignore it and if it's actually a Clang PCH with a malformed name you complain bitterly and dump core er, I mean, you read it silently as if it had the right name. One would hope that, if the GCC module files have a similar compiler- specific format (I'm not too familiar with modules) they also use a similar magic number at the beginning of the file. But anyway this is losing the thread of Eli's hopeful request.
Re: Taking Over MIPS Maintenance
YunQiang Su writes: > Greetings all, > > I would like to self-nominate as the new GCC MIPS maintainer. Matthew Fortune > is listed in MAINTAINERS as the current maintainer of GCC's MIPS Port. > However, it has been years since he left MIPS Technologies and had since been > inactive. > > I currently work for CIP United Inc., which is the exclusive licensor and > operator of MIPS IPs in China, Hong Kong, and Macau. Part of our operations > include maintaining open source software solutions for MIPS and we are > looking to continue maintaining GCC's MIPS port. As the director of the > company's software ecosystem department, I have been working with GCC and > contributed code to the upstream repository since 2021. In September 2021, I > was given write access to the repository: > > https://gcc.gnu.org/git/?p=gcc.git&a=search&h=HEAD&st=author&s=YunQiang+Su > > Please let me know about your thoughts on this proposal. FWIW, I'd support this. The MIPS port has been unmaintained for many years now. As the previous maintainer before Matthew, I've tried to cover the area a bit. But (a) It's now close to 15 years since I did any meaningful MIPS work, so I've forgotten a great deal. (b) Most new work will be specific to MIPSr6, which I have never used. (c) It's been very difficult to find the time. It would be more usual to wait a bit longer until someone becomes maintainer. But IMO that's only sensible when there's an existing maintainer to cover the interim. Thanks, Richard
