Re: [PATCH] sockaddr.3type: BUGS: Document that libc should be fixed using a union
Hi, I have opened a defect at austin group https://www.austingroupbugs.net/view.php?id=1641 Bastien Le lun. 6 févr. 2023 à 18:45, Eric Blake a écrit : > > On Sun, Feb 05, 2023 at 04:28:36PM +0100, Alejandro Colomar wrote: > > Regardless of the merits of the patch, let's not introduce typos: > > > +++ b/man3type/sockaddr.3type > > @@ -120,6 +120,26 @@ .SH NOTES > > .I > > and > > .IR . > > +.SH BUGS > > +.I sockaddr_storage > > +was designed back when strict aliasing wasn't a problem. > > +Back then, > > +one would define a variable of that type, > > +and then access it as any of the other > > +.IR sockaddr_ * > > +types, > > +depending on the value of the first member. > > +This is Undefined Behavior. > > +However, there is no way to use these APIs without invoking Unedfined > > Behavior, > > Undefined > > > +either in the user program or in libc, > > +so it is still recommended to use this method. > > +The only correct way to use different types in an API is through a union. > > +However, > > +that union must be implemented in the library, > > +since the type must be shared between the library and user code, > > +so libc should be fixed by implementing > > +.I sockaddr_storage > > +as a union. > > .SH SEE ALSO > > .BR accept (2), > > .BR bind (2), > > Also, while I could raise the issue with the Austin Group on your > behalf to get the POSIX wording improved, I think it would work better > if you initiate a bug report rather than having me do it: > > https://www.austingroupbugs.net/main_page.php > > -- > Eric Blake, Principal Software Engineer > Red Hat, Inc. +1-919-301-3266 > Virtualization: qemu.org | libvirt.org >
Re: [GSoC] gccrs Unicode support
Thank you everyone for your advice. Some kinds of names are restricted to unicode alphabetic/numeric in Rust. And the current definition of the table defined in libcpp/ucind.h lacks some rows representing which characters are alphabetic/numeric. But it is not a problem because it seems to be easy to add missing rows to the table and use it in the Rust frontend. 2023年3月16日(木) 21:59 Mark Wielaard : > You might want to research whether NFC normalization of identifiers is > required to be done by the lexer or parser in Rust and how it interacts > with proc macros. Yes, NFC normalization must be done by the lexer, which may be complex and hard to implement. libunistring can also be used for normalization, so is it good to use libunistring only in the normalization process? Raiki Tamura
Re: [GSoC] gccrs Unicode support
On Sat, 18 Mar 2023, 08:32 Raiki Tamura via Gcc, wrote: > Thank you everyone for your advice. > Some kinds of names are restricted to unicode alphabetic/numeric in Rust. > Doesn't it use the same rules as C++, based on XID_Start and XID_Continue? That should already be supported.
Re: [GSoC] gccrs Unicode support
2023年3月18日(土) 17:47 Jonathan Wakely : > On Sat, 18 Mar 2023, 08:32 Raiki Tamura via Gcc, wrote: > >> Thank you everyone for your advice. >> Some kinds of names are restricted to unicode alphabetic/numeric in Rust. >> > > Doesn't it use the same rules as C++, based on XID_Start and XID_Continue? > That should already be supported. > Yes, C++ and Rust use the same rules for identifiers (described in UAX#31) and we can reuse it in the lexer of gccrs. I was talking about values of Rust's crate_name attributes, which only allow Unicode alphabetic/numeric characters. (Ref: https://doc.rust-lang.org/reference/crates-and-source-files.html#the-crate_name-attribute ) Raiki Tamura
Re: [GSoC] gccrs Unicode support
On Sat, Mar 18, 2023 at 05:59:34PM +0900, Raiki Tamura wrote: > 2023年3月18日(土) 17:47 Jonathan Wakely : > > > On Sat, 18 Mar 2023, 08:32 Raiki Tamura via Gcc, wrote: > > > >> Thank you everyone for your advice. > >> Some kinds of names are restricted to unicode alphabetic/numeric in Rust. > >> > > > > Doesn't it use the same rules as C++, based on XID_Start and XID_Continue? > > That should already be supported. > > > > Yes, C++ and Rust use the same rules for identifiers (described in UAX#31) > and we can reuse it in the lexer of gccrs. > I was talking about values of Rust's crate_name attributes, which only > allow Unicode alphabetic/numeric characters. > (Ref: > https://doc.rust-lang.org/reference/crates-and-source-files.html#the-crate_name-attribute > ) That is a pretty simple thing, so no need to use an extra library for that. As is documented in contrib/unicode/README, the Unicode *.txt files are already checked in and there are several generators of tables. libcpp/makeucnid.cc already creates tables based on the UnicodeData.txt DerivedNormalizationProps.txt DerivedCoreProperties.txt files, including NFC/NKFC, it is true it doesn't currently compute whether a character is alphanumeric. That is either Alphabetic DerivedCoreProperties.txt property, or for numeric Nd, Nl or No category (3rd column) in UnicodeData.txt. Should be a few lines to add that support to libcpp/makeucnid.cc, the only question is if it won't make the ucnranges array much larger if it differentiates based on another ALPHANUM flag. If it doesn't grow too much, let's put it there, if it would grow too much, perhaps we should emit it in a separate table. Jakub
Re: #include cobol
On Mon, Feb 27, 2023 at 10:13 AM James K. Lowden wrote: > To the GCC community and GCC Steering Committee: Greetings! > > We at COBOLworx would like GCC to consider our gcobol front-end for > inclusion in the GCC project. We would like to contribute it to the > GNU Toolchain and have it merged into GCC. > > We believe our work is further along than any previous GCC Cobol > effort. As you may know, we have been working on the project for over > a year. Much of the last 9 months have been devoted to testing for > correctness. The compiler now passes the core module of the NIST > CCVS-85 test suite. Although not ready for production use by any > means, we expect to pass all relevant aspects of CCVS-85 later this > year. > > Old as it is, Cobol is far from dead. Estimates run into billions of > lines written, with millions more added each year, even today. But -- > because there has never been a free, fully functional, > source-to-machine compiler for it -- Cobol remains largely locked > behind expensive, proprietary walls. GCC can change that. > > Cobol also offers a window into what was and might yet be. In Seibel's > "Coders at Work", Fran Allen put it this way: > > "There was a debate between Steve Johnson, of Bell Labs, who > were supporting C, and one of our people, Bill Harrison The nubbin > of the debate was Steve's defense of not having to build optimizers > anymore because the programmer would take care of it." > > and > > "By 1960, we had a long list of amazing languages: Lisp, APL, > Fortran, COBOL, Algol 60. These are higher-level than C. We have > seriously regressed since C developed." > > Modern hardware, and GCC's 100 optimization passes, are evidence Fran > Allen was right. Cobol, with its 2 dozen high-level verbs and > integrated I/O, provides a theoretical opportunity to surpass even C's > performance in its problem domain, because the compiler has more > information and more leeway. > > As a technical matter, to be sure we are far from achieving that goal. > It is, as I said, an opportunity. As we hone our skills, we look > forward to learning together with others to make it a reality. > > Signed, > > Marty Heyman, James K. Lowden, Robert Dubner > The GCC Steering Committee has approved GCobol as a new front-end for the GNU Compiler Collection. Congratulations! This is the administrative approval. The initial patches must be technically approved by a GCC Global Reviewer. Please coordinate this with the GCC Global Reviewers and Release Managers for the next or future Stage 1 development cycle. GCC welcomes support for new languages. COBOL is an important but niche language in 2023. GCobol will not be a primary language that is considered critical for a GCC Release, and if GCobol becomes a maintenance burden, the GCC SC and community may revisit support for COBOL. We look forward to COBOL support in a future release of GCC. Thanks, David
Re: cgraph: does node->inlined_to imply node->clones is non-empty?
Hi Martin,
Thank you for the thorough response, and apologies for replying so late
(I'm busy most hours of most workdays nowadays).
Martin Jambor writes:
> Hello,
>
> I had been aware of your message even before Martin Liška pointed to it,
> but I could not answer the questions without looking into the problem
> myself.
>
> On Mon, Mar 13 2023, Arsen Arsenović via Gcc wrote:
>> Hi,
>>
>> I was debugging PR96059 and ran into a question which does not seem
>> obvious from the code.
>
> Thanks for looking into old bugs, it really is appreciated!
My pleasure.
>> When the original inline
>> happens, ipa-inline-transform.cc:clone_inlined_nodes decides not to make
>> a clone, since the function being cloned is a master clone but with no
>> non-inline clones.
>
> The reason is rather that cloning can simply be avoided if you know that
> you do not need an offline copy, for anything, be it other normal calls,
> calls from outside of the compilation unit, indirect calls, virtual
> calls, calls through aliases, thunks... that you do not need the intact
> body of the function to create other inline copies, other specialized
> clones... and maybe I forgot about something. But this is an efficiency
> thing.
Right. I was just trying to be specific about which requirement in the
if turned out to be false.
>>
>> For the test case in the PR, in ipa.cc:remove_unreachable_nodes, GCC
>> seems to try to remove an unreachable function that was already inlined
>> into a different unreachable function.
>
> No, it fails to remove it. It is still there but should not have been,
> that is the problem.
Ah - I see.
>>
>> This decision later trips up the gcc_assert in:
>>
>> /* Inline clones might be kept around so their materializing allows further
>> cloning. If the function the clone is inlined into is removed, we need
>> to turn it into normal cone. */
>> FOR_EACH_FUNCTION (node)
>> {
>> if (node->inlined_to
>>&& !node->callers)
>> {
>>gcc_assert (node->clones);
>>node->inlined_to = NULL;
>>update_inlined_to_pointer (node, node);
>> }
>> node->aux = NULL;
>> }
>>
>> .. because it is expecting that an inlined function without callers
>> (which is necessarily true here as this function is unreachable and so
>> was ->remove ()'d earlier) has clones.
>
> The assert makes sure that if we encounter an inlined-to node without
> any caller, that it merely holds as the holder of the function body for
> its other specialized (think IPA-CP) or inline clones. If node->clones
> is false, there are no such clones and it was a bug to mark the node as
> required during the removal of unreachable nodes.
I see. That makes sense. So, this assert is placed here by convenience
rather than being this invariant being absolutely required for the
purpose of the loop? (it is related, so this placement makes sense, I
just want to confirm whether it's a "mandatory" invariant)
>>
>> Either removing the assertion or making clone_inline_nodes clone when
>> there are no existing clones 'fixes' (suppresses, but I haven't verified
>> whether the results are correct) the problem.
>>
>> Is this gcc_assert correct in that an inlined function without callers
>> necessarily must have clones?
>
> It is correct. An inlined function without a caller is even a logical
> oxymoron and can only exist if it has the purpose described above (and
> even then probably only in a fairly special circumstances).
Right. I wasn't quite sure whether setting inlined_to would remove that
caller, but if I understood right, it should not.
What is interesting, though, is that there is an attempt to remove this
node during ipa_inline:
(gdb) bt
#0 cgraph_edge::remove_callee (
this= -> )>)
at ../../gcc/gcc/cgraph.h:3299
#1 0x00d03c37 in cgraph_node::remove_callees (this=) at
../../gcc/gcc/cgraph.cc:1743
#2 0x00d04387 in cgraph_node::remove (this=) at ../../gcc/gcc/cgraph.cc:1884
#3 0x010da74f in symbol_table::remove_unreachable_nodes
(this=0x76ddb000, file=0x77a814c0 <_IO_2_1_stderr_>) at
../../gcc/gcc/ipa.cc:518
#4 0x02b51e53 in ipa_inline () at
../../gcc/gcc/ipa-inline.cc:2761
#5 0x02b52cf7 in (anonymous
namespace)::pass_ipa_inline::execute (this=0x3c8d5b0) at
../../gcc/gcc/ipa-inline.cc:3153
(etc)
... I presume that my assumption that cgraph_node::remove () should
remove nodes from the cgraph_node::next chain is wrong?
>>
>> And as a side question, do all clone nodes have a ->clones pointing to
>> the same list of all clones, or are they in a tree-ish arrangement,
>> where clones of clones end up forming a tree, with the clone_of pointer
>> being a pointer to the parent?
>
> The latter, they form a tree.
I see, that makes sense. Thanks.
>> (in this instance, the node that trips
>> the assert has a nullptr clone_of and clones value, which would AIUI
>> imply that it is the original)
>
> Yes.
>
>> This train of th
[no subject]
-- .HY
gcc-12-20230318 is now available
Snapshot gcc-12-20230318 is now available on https://gcc.gnu.org/pub/gcc/snapshots/12-20230318/ 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 e62896ef77788dfdec9dd6eb649db1b08d395d86 You'll find: gcc-12-20230318.tar.xz Complete GCC SHA256=dbfd72bb25204ff9ae92f47e00c07a1aa19fc664f2499b9c7b12dfc71f6b2e52 SHA1=35378444fe4ba791255aeb941692eb73f4950abd Diffs from 12-20230311 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.
GSoC 2023
Hello, I am Ankesh Pandey, a 3rd year Computer Science Undergraduate. I am interested in contributing for the following projects: 1. Unicode support: Our Lexer and AST do not support Unicode strings and identifiers, which we need to be a Rust compiler. The project will require a student to work mostly in the Lexer and AST but the changes here will ripple all the way through our HIR and code-generation passes. For example, in implementing Unicode support, it will make sense to ensure we improve location info, so instead of simply passing around Unicode strings in the IR's we should create a unique string data structure which also contains location info to improve our error diagnostics and debug information. *Difficulty: Hard Size: 350 hours (large) Mentors: Arthur and/or Philip* 2. Improving user errors: We recently merged code enabling the Rust frontend to emit error codes similarly to rustc. We'd like for gccrs to be able to emit the same errors codes as rustc, in order to help bridge the gap between our two testsuites and enable us to eventually run the rustc one. The student will have to research rustc error codes, their various guarantees, and emit them throughout the frontend code. We would also like the code responsible for emitting errors to get more fleshed out and allow more functionality. Finally, this will also be a good project to start looking at a better user experience for gccrs: emitting more errors, in more places, with more hints to the users about ways to fix the code. *Difficulty: Medium Size: 175 (medium) Mentors: Arthur and/or Philip* I am really good at C, C++ and have decent experience working with FLEX and YACC and hence would be an appropriate candidate for the same. It would be great if you can give me insights on how I can formalize my proposal for GSoC 2023. Hoping to contribute to the organization through GSoC 2023. Thank you. -- The information contained in this electronic communication is intended solely for the individual(s) or entity to which it is addressed. It may contain proprietary, confidential and/or legally privileged information. Any review, retransmission, dissemination, printing, copying or other use of, or taking any action in reliance on the contents of this information by person(s) or entities other than the intended recipient is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us by responding to this email or telephone and immediately and permanently delete all copies of this message and any attachments from your system(s). The contents of this message do not necessarily represent the views or policies of BITS Pilani.
