Re: Gcc Digest, Vol 35, Issue 13

Re: Gcc Digest, Vol 35, Issue 13

[miguel.laredo]

Bb g. Hg hh. Hggjg ggjh jh j cb23"€* 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
> 
> Send Gcc mailing list submissions to
> 	gcc@gcc.gnu.org
> 
> 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
> 
> You can reach the person managing the list at
> 	gcc-owner@gcc.gnu.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Gcc digest..."
> 
> Today's Topics:
> 
>    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)
> 
> From: Frank Ch. Eigl <fche@redhat.com>
> To: Federico Iezzi <fiezzi@google.com>
> 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)
> 
> Federico Iezzi via Gcc <gccd a,@gcc.gnu.org> writes:
> 
> > [...]
> > 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
> 
> This has been unblocked add ZsszXcfsf d sdcs fcddsc.  We sometimes must block large subnets when
> abusive traffic comes from there.
> 
> - FChE
> 
> 
> 
> From: Paul Koning <paulkoning@comcast.net>
> To: GCC Development <gcc@gcc.gnu.org>
> Subject: struct vs. class in GCC source
> Date: Tue, 10 Jan 2023 15:50:24 +0100 (CET)
> 
> 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 linker 
> 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 if it would 
> be worth changing the code to use just one of "struct" or "class" for any 
> given type.  (And then the convention would presumably be that a POD type is 
> called "struct" and other types are "class".)
> 
> 	paul
> 
> 
> 
> From: Paul Koning <paulkoning@comcast.net>
> To: Stefan Kanthak <stefan.kanthak@nexgo.de>
> Cc: gcc@gnu.org
> Subject: Re: Widening multiplication, but no narrowing division
>   [i386/AMD64]
> Date: Tue, 10 Jan 2023 17:49:03 +0100 (CET)
> 
> 
> 
> > On Jan 9, 2023, at 11:27 AM, Stefan Kanthak <stefan.kanthak@nexgo.de> 
> wrote:
> > 
> > "Paul Koning" <paulkoning@comcast.net> wrote:
> > 
> >>> ...
> > 
> >> 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 has
> >> 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.
> > 
> > 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.
> 
> It turns out I was confused by the RTL generated by my pattern.  That 
> pattern is for divmodhi, so it works as desired given same-size inputs.  
> 
> I'm wondering if the case of longer dividend -- which is a common thing for 
> several machines -- could be handled by a define_peephole2 that matches the 
> sign-extend of the divisor followed by the (longer) divide.  I made a stab 
> at that but what I wrote wasn't valid.
> 
> So, question to the list:  suppose I want to write RTL that matches what 
> Stefan is talking about, with a div or mod or divmod that has si results and 
> a di dividend (or hi results and an si dividend), how would you do that?  
> Can a define_peephole2 do it, and if so, what would it look like?
> 
> 	paul
> 
> 
> 
> 
> From: Martin Jambor <mjambor@suse.cz>
> To: GCC Mailing List <gcc@gcc.gnu.org>,
>  Gfortran mailing list <fortran@gcc.gnu.org>,
>  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)
> 
> Hello,
> 
> 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.
> 
> ======================== The most important bit: ========================
> 
> 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.
> 
> =========================================================================
> 
> At this point, we need to collect list of project ideas.  Eventually,
> each listed project idea should have:
> 
>   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.
> 
> 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.
> 
> 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.
> 
> Finally, please continue helping (prospective) students figure stuff out
> about GCC like you have always done in the past.
> 
> As far as I know, GSoC 2023 should be quite similar to the last year,
> the most important parameters probably are these:
> 
>   - Contributors (formerly students) must either be students or be
>     "beginners to open source" (or both).
> 
>   - There are two project sizes, roughly 175 hours (medium-sized) and
>     roughly 350 hours (large) in total.
> 
>   - 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.
> 
> For further details you can see:
> 
>   - The announcement of GSoC 2023:
>     https://opensource.googleblog.com/2022/11/get-ready-for-google-summer-of-
> code-2023.html
>     
>   - GSoC rules:
>     https://summerofcode.withgoogle.com/rules
> 
>   - The detailed GSoC 2023 timeline:
>     https://developers.google.com/open-source/gsoc/timeline
> 
>   - Elaborate project idea guidelines:
>     https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list

> 
> 
> Thank you for your participation and help.  Let's hope we attract some
> great contributors again this year.
> 
> Martin
> 
> 
> From: Jason Merrill <jason@redhat.com>
> To: Paul Koning <paulkoning@comcast.net>
> Cc: GCC Development <gcc@gcc.gnu.org>
> Subject: Re: struct vs. class in GCC source
> Date: Tue, 10 Jan 2023 20:29:17 +0100 (CET)
> 
> On Tue, Jan 10, 2023 at 9:51 AM Paul Koning via Gcc <gcc@gcc.gnu.org> 
> wrote:
> 
> > 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 linker
> > 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 if 
> it
> > would be worth changing the code to use just one of "struct" or "class" 
> for
> > any given type.  (And then the convention would presumably be that a POD
> > type is called "struct" and other types are "class".)
> >
> 
> Yes, it might be worth adding -Wmismatched-tags to STRICT_WARN.  Is
> bootstrapping with VC++ is supported?
> 
> Jason
> 
> 
> From: Paul Koning <paulkoning@comcast.net>
> To: GCC Development <gcc@gcc.gnu.org>
> Subject: LRA produces RTL not meeting constraint
> Date: Tue, 10 Jan 2023 20:39:34 +0100 (CET)
> 
> In pdp11.md I have:
> 
> (define_insn_and_split "addhi3"
>   [(set (match_operand:HI 0 "nonimmediate_operand" "=rR,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")])
> 
> While compiling libgcc2.c I see this RTL in the .ira dump file:
> 
> (insn 49 48 53 5 (set (reg/f:HI 136)
>         (plus:HI (reg/f:HI 5 r5)
>             (const_int -8 [0xfffffffffffffff8]))) 
> "../../../../../gcc/libgcc/libgcc2.c":276:4 68 {addhi3}
>      (expr_list:REG_EQUIV (plus:HI (reg/f:HI 5 r5)
>             (const_int -8 [0xfffffffffffffff8]))
>         (nil)))
> 
> Then in the .reload dump it appears this way:
> 
> (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)))
> 
> which obviously causes an ICE because that RTL doesn't meet the constraints. 
>  This happens only when LRA is used.
> 
> I also see this in the .reload file, but I don't know what it means:
> 
> 	 Choosing alt 1 in insn 49:  (0) rR  (1) 0  (2) Qi {addhi3}
>             1 Non-pseudo reload: reject+=2
>             1 Non input pseudo reload: reject++
>             Cycle danger: overall += LRA_MAX_REJECT
>           alt=0,overall=609,losers=1,rld_nregs=2
>             alt=1: Bad operand -- refuse
>             alt=2: Bad operand -- refuse
>           alt=3,overall=0,losers=0,rld_nregs=0
> 
> Any ideas?  I ran into this when trying to make LRA the default for this 
> target.
> 
> 	paul
> 
> 
> 
> From: Jacob Bachmeyer <jcb62281@gmail.com>
> To: NightStrike <nightstrike@gmail.com>
> Cc: Jacek Caban <jacek@codeweavers.com>,
>  fortran@gcc.gnu.org,
>  Eric Pouech <eric.pouech@orange.fr>,
>  gcc@gcc.gnu.org <gcc@gcc.gnu.org>,
>  dejagnu@gnu.org
> Subject: Re: testsuite under wine
> Date: Wed, 11 Jan 2023 03:30:07 +0100 (CET)
> 
> 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?
> 
> Two problems:  first, you need zero-or-more \r and *one*-or-more \n.  
> Second, dg-output is not defined as an anchored match, and therefore 
> cannot do this automatically.
> 
> >   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).
> 
> Do not worry about classic Mac OS---running DejaGnu on that platform is 
> not possible, nor is it possible to run test programs remotely on that 
> platform.  Classic Mac OS is a pure-GUI system with no command interface 
> whatsoever.  Even the Mac port of Tcl simply /does/ /not/ /have/ the Tcl 
> exec(n) command.  Due to limitations of the platform, porting Expect to 
> classic Mac OS is simply not possible.  Any compatibility layer would be 
> reasonably expected to translate CR<->LF, if, for example, someone wrote 
> a telnet server (and associated POSIX-alike environment) for Mac OS.
> 
> The later Mac OS X is a quasi-POSIX mostly compatible with the GNU 
> system that uses POSIX line endings.  DejaGnu should run normally there.
> 
> Are there other systems that used bare CR as end-of-line?  If not, the 
> correct pattern is therefore {\r*\n} (here written using braces as 
> quotes around the pattern).
> 
> 
> -- Jacob
> 
> 
>