Bb g. Hg hh. Hggjg ggjh jh j cb23"€* ca*
-- Mensaje original --
> De: gcc-requ...@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-requ...@gcc.gnu.org
>
> You can reach the person managing the list at
> gcc-ow...@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 <f...@redhat.com>
> To: Federico Iezzi <fie...@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 <paulkon...@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 <paulkon...@comcast.net>
> To: Stefan Kanthak <stefan.kant...@nexgo.de>
> Cc: g...@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.kant...@nexgo.de>
> wrote:
> >
> > "Paul Koning" <paulkon...@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 <mjam...@suse.cz>
> To: GCC Mailing List <gcc@gcc.gnu.org>,
> Gfortran mailing list <fort...@gcc.gnu.org>,
> libstd...@gcc.gnu.org,
> gcc-r...@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 <ja...@redhat.com>
> To: Paul Koning <paulkon...@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 <paulkon...@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 <jcb62...@gmail.com>
> To: NightStrike <nightstr...@gmail.com>
> Cc: Jacek Caban <ja...@codeweavers.com>,
> fort...@gcc.gnu.org,
> Eric Pouech <eric.pou...@orange.fr>,
> gcc@gcc.gnu.org <gcc@gcc.gnu.org>,
> deja...@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
>
>
>
