From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from msg-1.mailo.com (msg-1.mailo.com [213.182.54.11]) by sourceware.org (Postfix) with ESMTPS id 0ECB638493CA for ; Mon, 13 Feb 2023 14:02:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0ECB638493CA Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=mailo.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mailo.com DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mailo.com; s=mailo; t=1676296973; bh=Gh8TmfMgDUKTo09+YpOXRAMOGWJorpYfJlazgVr6WhU=; h=X-EA-Auth:From:To:Date:Subject:MIME-Version:X-Mailer:Message-ID: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=GSb8myeztLKtda+TQ+fctL3oTZZ28UvV7wxpMHQUGyaJrYVMDjN4zso6bBLL9L6aA XAUyXgma/i21bBLn1BEcE3z2kNqNteAwHVTk+MaQkrrfTF2mLHoikxkU1eoOqtyt9R s+gk43Thia5Rq87wuqCT6XFI3R9nJ0e9ztgGyIJM= Received: by app.mailo.com with http webmail; Mon, 13 Feb 2023 15:02:53 +0100 (CET) X-EA-Auth: Rt1I+Xb6IA7Kp+/j0uOqjwUA9sQqZQGzF2JmxUX3Uyd7rl7ZuimYg1ra3W2e1C6h+8Q9ah073qivvhVg0avrLjcepNODyvi0 From: miguel.laredo@mailo.com To: gcc@gcc.gnu.org Date: Mon, 13 Feb 2023 15:02:53 +0100 (CET) Subject: Re: Gcc Digest, Vol 35, Issue 13 X-Priority: 3 MIME-Version: 1.0 X-Mailer: COMS/EA22.05/r20221103 Message-ID: In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=4.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FOREIGN_BODY1,KAM_ASCII_DIVIDERS,KAM_NUMSUBJECT,KAM_SHORT,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Level: **** X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Bb g. Hg hh. Hggjg ggjh jh j cb23"=E2=82=AC* ca* -- Mensaje original -- > De: gcc-request@gcc.gnu.org > A: gcc@gcc.gnu.org > Asunto: Gcc Digest, Vol 35, Issue 13 > Fecha: 11/01/2023 03:30:13 Europe/Paris >=20 > Send Gcc mailing list submissions to > gcc@gcc.gnu.org >=20 > To subscribe or unsubscribe via the World Wide Web, visit > https://gcc.gnu.org/mailman/listinfo/gcc > or, via email, send a message with subject or body 'help' to > gcc-request@gcc.gnu.org >=20 > You can reach the person managing the list at > gcc-owner@gcc.gnu.org >=20 > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Gcc digest..." >=20 > Today's Topics: >=20 > 1. Re: urgent - Google Cloud public subnet blacklisted by > gcc.org (Frank Ch. Eigler) > 2. struct vs. class in GCC source (Paul Koning) > 3. Re: Widening multiplication, but no narrowing division > [i386/AMD64] (Paul Koning) > 4. GCC GSoC 2023: Call for project ideas and mentors (Martin Jambor) > 5. Re: struct vs. class in GCC source (Jason Merrill) > 6. LRA produces RTL not meeting constraint (Paul Koning) > 7. Re: testsuitexddddddddxddwdxwSd sax dddx dddd d under wine (Jacob = Bachmeyer) >=20 > From: Frank Ch. Eigl > To: Federico Iezzi > Cc: gcc@gcc.gnu.org > Subject: Re: urgent - Google Cloud public subnet blacklisted by > gcc.org > Date: Tue, 10 Jan 2023 15:42:13 +0100 (CET) >=20 > Federico Iezzi via Gcc writes: >=20 > > [...] > > It seems like the GCC frontend/WAF have blacklisted the entire subnet > > used by Google Cloud for Internet access. > > [...] > > $ curl ifconfig.me > > 35.234.162.99 >=20 > This has been unblocked add ZsszXcfsf d sdcs fcddsc. We sometimes must = block large subnets when > abusive traffic comes from there. >=20 > - FChE >=20 >=20 >=20 > From: Paul Koning > To: GCC Development > Subject: struct vs. class in GCC source > Date: Tue, 10 Jan 2023 15:50:24 +0100 (CET) >=20 > Building on Mac with Clang I get warnings like this: >=20 > ../../../gcc/gcc/cgraph.h:2629:28: warning: struct 'cgraph_edge' was=20 > previously declared as a class; this is valid, but may result in linker= =20 > errors under the Microsoft C++ ABI [-Wmismatched-tags] >=20 > It seems to be talking about a MS bug (since C++ says struct and class m= ean=20 > the same thing other than the default access). Still, I wonder if it wo= uld=20 > be worth changing the code to use just one of "struct" or "class" for an= y=20 > given type. (And then the convention would presumably be that a POD typ= e is=20 > called "struct" and other types are "class".) >=20 > paul >=20 >=20 >=20 > From: Paul Koning > To: Stefan Kanthak > Cc: gcc@gnu.org > Subject: Re: Widening multiplication, but no narrowing division > [i386/AMD64] > Date: Tue, 10 Jan 2023 17:49:03 +0100 (CET) >=20 >=20 >=20 > > On Jan 9, 2023, at 11:27 AM, Stefan Kanthak = =20 > wrote: > >=20 > > "Paul Koning" wrote: > >=20 > >>> ... > >=20 > >> Yes, I was thinking the same. But I spent a while on that pattern --= I > >> wanted to support div/mod as a single operation because the machine h= as > >> that primitive. And I'm pretty sure I saw it work before I committed > >> that change. That's why I'm wondering if something changed. > >=20 > > I can't tell from the past how GCC once worked, but today it can't > > (or doesn't) use such patterns, at least not on i386/AMD64 processors. >=20 > It turns out I was confused by the RTL generated by my pattern. That=20 > pattern is for divmodhi, so it works as desired given same-size inputs. = =20 >=20 > I'm wondering if the case of longer dividend -- which is a common thing = for=20 > several machines -- could be handled by a define_peephole2 that matches = the=20 > sign-extend of the divisor followed by the (longer) divide. I made a st= ab=20 > at that but what I wrote wasn't valid. >=20 > So, question to the list: suppose I want to write RTL that matches what= =20 > Stefan is talking about, with a div or mod or divmod that has si results= and=20 > a di dividend (or hi results and an si dividend), how would you do that?= =20 > Can a define_peephole2 do it, and if so, what would it look like? >=20 > paul >=20 >=20 >=20 >=20 > From: Martin Jambor > To: GCC Mailing List , > Gfortran mailing list , > libstdc++@gcc.gnu.org, > gcc-rust@gcc.gnu.org > Subject: GCC GSoC 2023: Call for project ideas and mentors > Date: Tue, 10 Jan 2023 19:25:06 +0100 (CET) >=20 > Hello, >=20 > another year has passed and Google has announced there will be again > Google Summer of Code (GsoC) in 2023 and the deadline for organizations > to apply is already approaching (February 7th). I'd like to volunteer > to be the main Org Admin for GCC again so let me know if you think I > shouldn't or that someone else should or if you want to do it instead, > but otherwise I'll assume that I will. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= The most important bit: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D >=20 > I would like to ask all (moderately) seasoned GCC contributors to > consider mentoring a student this year and ideally also come up with a > project that they would like to lead. I'm collecting proposal on our > wiki page https://gcc.gnu.org/wiki/SummerOfCode - feel free to add yours > to the top list there. Or, if you are unsure, post your offer and > project idea as a reply here to the mailing list. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > At this point, we need to collect list of project ideas. Eventually, > each listed project idea should have: >=20 > a) a project title, > b) more detailed description of the project (2-5 sentences), > c) expected outcomes (we do have a catch-almost-all formulation that > outcome is generally patches at the bottom of the list in the > wiki), > d) skills required/preferred, > e) project size (whether approximately 175 or 350 hours), > f) difficulty (easy, hard or medium, but we don't really have easy > projects), and > g) expected mentors. >=20 > Project ideas that come without an offer to also mentor them are always > fun to discuss, by all means feel free to reply to this email with yours > and I will attempt to find a mentor, but please be aware that we can > only use the suggestion it if we actually find one or ideally two. >=20 > Everybody in the GCC community is invited to go over > https://gcc.gnu.org/wiki/SummerOfCode and remove any outdated or > otherwise bad project suggestions and help improve viable ones. >=20 > Finally, please continue helping (prospective) students figure stuff out > about GCC like you have always done in the past. >=20 > As far as I know, GSoC 2023 should be quite similar to the last year, > the most important parameters probably are these: >=20 > - Contributors (formerly students) must either be students or be > "beginners to open source" (or both). >=20 > - There are two project sizes, roughly 175 hours (medium-sized) and > roughly 350 hours (large) in total. >=20 > - Timing should be pretty much as flexible as last year. Two years > ago it was 12 weeks for everyone but now projects can take anywhere > between 10 and 22 weeks. (But I'd prefer if we tried to fit into 20 > at maximum, even that means deadlines would get close to stage 1 > end.) There will be one mid-term and one final evaluation. >=20 > For further details you can see: >=20 > - The announcement of GSoC 2023: > https://opensource.googleblog.com/2022/11/get-ready-for-google-summe= r-of- > code-2023.html > =20 > - GSoC rules: > https://summerofcode.withgoogle.com/rules >=20 > - The detailed GSoC 2023 timeline: > https://developers.google.com/open-source/gsoc/timeline >=20 > - Elaborate project idea guidelines: > https://google.github.io/gsocguides/mentor/defining-a-project-ideas-= list >=20 >=20 > Thank you for your participation and help. Let's hope we attract some > great contributors again this year. >=20 > Martin >=20 >=20 > From: Jason Merrill > To: Paul Koning > Cc: GCC Development > Subject: Re: struct vs. class in GCC source > Date: Tue, 10 Jan 2023 20:29:17 +0100 (CET) >=20 > On Tue, Jan 10, 2023 at 9:51 AM Paul Koning via Gcc =20 > wrote: >=20 > > Building on Mac with Clang I get warnings like this: > > > > ../../../gcc/gcc/cgraph.h:2629:28: warning: struct 'cgraph_edge' was > > previously declared as a class; this is valid, but may result in linke= r > > errors under the Microsoft C++ ABI [-Wmismatched-tags] > > > > It seems to be talking about a MS bug (since C++ says struct and class > > mean the same thing other than the default access). Still, I wonder i= f=20 > it > > would be worth changing the code to use just one of "struct" or "class= "=20 > for > > any given type. (And then the convention would presumably be that a P= OD > > type is called "struct" and other types are "class".) > > >=20 > Yes, it might be worth adding -Wmismatched-tags to STRICT_WARN. Is > bootstrapping with VC++ is supported? >=20 > Jason >=20 >=20 > From: Paul Koning > To: GCC Development > Subject: LRA produces RTL not meeting constraint > Date: Tue, 10 Jan 2023 20:39:34 +0100 (CET) >=20 > In pdp11.md I have: >=20 > (define_insn_and_split "addhi3" > [(set (match_operand:HI 0 "nonimmediate_operand" "=3DrR,rR,Q,Q") > (plus:HI (match_operand:HI 1 "general_operand" "%0,0,0,0") > (match_operand:HI 2 "general_operand" "rRLM,Qi,rRLM,Qi")))] > "" > "#" > "reload_completed" > [(parallel [(set (match_dup 0) > (plus:HI (match_dup 1) (match_dup 2))) > (clobber (reg:CC CC_REGNUM))])] > "" > [(set_attr "length" "2,4,4,6")]) >=20 > While compiling libgcc2.c I see this RTL in the .ira dump file: >=20 > (insn 49 48 53 5 (set (reg/f:HI 136) > (plus:HI (reg/f:HI 5 r5) > (const_int -8 [0xfffffffffffffff8])))=20 > "../../../../../gcc/libgcc/libgcc2.c":276:4 68 {addhi3} > (expr_list:REG_EQUIV (plus:HI (reg/f:HI 5 r5) > (const_int -8 [0xfffffffffffffff8])) > (nil))) >=20 > Then in the .reload dump it appears this way: >=20 > (insn 49 48 53 5 (set (reg/f:HI 5 r5 [136]) > (plus:HI (reg/f:HI 6 sp) > (const_int 40 [0x28]))) "../../../../../gcc/libgcc/libgcc2.c= ":276 > :4 68 {addhi3} > (expr_list:REG_EQUIV (plus:HI (reg/f:HI 5 r5) > (const_int -8 [0xfffffffffffffff8])) > (nil))) >=20 > which obviously causes an ICE because that RTL doesn't meet the constrai= nts.=20 > This happens only when LRA is used. >=20 > I also see this in the .reload file, but I don't know what it means: >=20 > Choosing alt 1 in insn 49: (0) rR (1) 0 (2) Qi {addhi3} > 1 Non-pseudo reload: reject+=3D2 > 1 Non input pseudo reload: reject++ > Cycle danger: overall +=3D LRA_MAX_REJECT > alt=3D0,overall=3D609,losers=3D1,rld_nregs=3D2 > alt=3D1: Bad operand -- refuse > alt=3D2: Bad operand -- refuse > alt=3D3,overall=3D0,losers=3D0,rld_nregs=3D0 >=20 > Any ideas? I ran into this when trying to make LRA the default for this= =20 > target. >=20 > paul >=20 >=20 >=20 > From: Jacob Bachmeyer > To: NightStrike > Cc: Jacek Caban , > fortran@gcc.gnu.org, > Eric Pouech , > gcc@gcc.gnu.org , > dejagnu@gnu.org > Subject: Re: testsuite under wine > Date: Wed, 11 Jan 2023 03:30:07 +0100 (CET) >=20 > NightStrike wrote: > > [...] > > I did another little test to try to better understand your point. I > > ran a linux native testsuite under a simulator that just sets SIM to " > > ". This resulted in extra ^M's also, although many tests pass because > > they're already looking for \r\n to accommodate windows. So I think > > I've come around to grasp what you've been heroically re-explaining... > > > > So if we have to modify every test in the entire testsuite to check > > for zero or more \r's followed by zero or more \n's, would it be > > better to add a dg-output-line proc that does this automatically > > everywhere? >=20 > Two problems: first, you need zero-or-more \r and *one*-or-more \n. =20 > Second, dg-output is not defined as an anchored match, and therefore=20 > cannot do this automatically. >=20 > > I feel like changing every output pattern test won't be > > too maintainable. You had mentioned previously modifying ${tool}_load > > to filter out extra \r's, but I couldn't see where or how to do that. > > > > For completeness, setting a random selection of tests to look for > > \r*\n? worked (this would cover even deprecated systems that only use > > CR as well as flagging the weird rust case of \r\r\n\n as bad). >=20 > Do not worry about classic Mac OS---running DejaGnu on that platform is= =20 > not possible, nor is it possible to run test programs remotely on that= =20 > platform. Classic Mac OS is a pure-GUI system with no command interface= =20 > whatsoever. Even the Mac port of Tcl simply /does/ /not/ /have/ the Tcl= =20 > exec(n) command. Due to limitations of the platform, porting Expect to= =20 > classic Mac OS is simply not possible. Any compatibility layer would be= =20 > reasonably expected to translate CR<->LF, if, for example, someone wrote= =20 > a telnet server (and associated POSIX-alike environment) for Mac OS. >=20 > The later Mac OS X is a quasi-POSIX mostly compatible with the GNU=20 > system that uses POSIX line endings. DejaGnu should run normally there. >=20 > Are there other systems that used bare CR as end-of-line? If not, the= =20 > correct pattern is therefore {\r*\n} (here written using braces as=20 > quotes around the pattern). >=20 >=20 > -- Jacob >=20 >=20 >