From: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
To: Tobias Burnus <tobias@codesourcery.com>
Cc: rep.dot.nop@gmail.com, fortran <fortran@gcc.gnu.org>
Subject: Re: [Patch] Fortran: Fix reallocation on assignment for kind=4 strings [PR107508]
Date: Sun, 6 Nov 2022 00:45:19 +0100 [thread overview]
Message-ID: <20221106004519.71f07ebd@nbbrfq> (raw)
In-Reply-To: <dee92d68-139c-9a2d-325e-2c3f402291e8@codesourcery.com>
On Sat, 5 Nov 2022 23:28:47 +0100
Tobias Burnus <tobias@codesourcery.com> wrote:
[no comment. I wonder why we malloc versus realloc in the first place,
i'd realloc always for starters. We end up calling into libc anyway, we
don't inline any of those calls and we suffer lib-boundary non-IPA
trouble either way, still, no? So why the conditional on our side?
valgrind certainly does not have a problem either way and i'd hope our
analyzer doesn't either. So what's that dance good for anyway? If you
did not remove it altogether anyway that is. ]
> PPS: I lost track of pending patches. Are they any which I should
> review?
You could poke honza in a while (which i will do if there is
interest) WRT
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/605081.html
needed iff we want to have (a cleaned-up version, including
gfortran.texi hunk) what David Love asked for in
https://gcc.gnu.org/pipermail/fortran/2022-October/058395.html
and where Thomas König expressed possible interest as per
https://gcc.gnu.org/pipermail/fortran/2022-November/058441.html
to add support for attribute target_clones.
I tested only c,c++,fortran,lto, don't have cycles for all langs, so if
you do d,ada,m2,..
The other 2 trivial hunks stemming from looking around that
attribute were approved already by Jeff and Richi, i'll push them
sometimes next week or during next weekend.
But David Love raised a question about more of the attributes supported
by the C FE, not just target_clones.
What are your thoughts around those?
blindvt> Tobias___, hi. You might have seen that David Love asked for
blindvt> attribute target_clones. Are there other attributes that you
blindvt> think would be helpful to support?
blindvt> i think flatten would be potentially usable, at least for
blindvt> power-users.
blindvt> not sure about simd. Maybe that? Or something
blindvt> else too? WDYT?
blindvt> i'm willing to spend one or two evenings on
blindvt> these, if you folks thing they are worth adding...
Apart from that, folks will certainly point at other patches pending
review..
thanks and cheers,
next prev parent reply other threads:[~2022-11-05 23:46 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-05 22:28 Tobias Burnus
2022-11-05 23:45 ` Bernhard Reutner-Fischer [this message]
2022-11-06 20:32 ` Mikael Morin
2022-11-06 22:15 ` Tobias Burnus
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20221106004519.71f07ebd@nbbrfq \
--to=rep.dot.nop@gmail.com \
--cc=fortran@gcc.gnu.org \
--cc=tobias@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).