On March 26, 2021 4:20:28 PM GMT+01:00, Florian Weimer
wrote:
>* Richard Biener:
>
>>> I think H.J. needs this for a function that isn't even
>always_inline,
>>> just extern inline __attribute__ ((gnu_inline)). Is that aspect
>>> something that could be solved for GCC 11?
>>
>> But that should a
* Richard Biener:
>> I think H.J. needs this for a function that isn't even always_inline,
>> just extern inline __attribute__ ((gnu_inline)). Is that aspect
>> something that could be solved for GCC 11?
>
> But that should already work, no? Yes, it won't inline but also not
> error. Unless gli
On Fri, Mar 26, 2021 at 2:49 PM Florian Weimer wrote:
>
> * Jakub Jelinek via Gcc-patches:
>
> > On Thu, Mar 25, 2021 at 11:36:37AM -0700, H.J. Lu via Gcc-patches wrote:
> >> How can we move forward with it? I'd like to resolve it in GCC 11.
> >
> > I think it is too late for GCC 11 for this.
> >
* Jakub Jelinek via Gcc-patches:
> On Thu, Mar 25, 2021 at 11:36:37AM -0700, H.J. Lu via Gcc-patches wrote:
>> How can we move forward with it? I'd like to resolve it in GCC 11.
>
> I think it is too late for GCC 11 for this.
> Especially if the solution would be that we change the behavior of ex
On Fri, Mar 26, 2021 at 11:26 AM Jakub Jelinek wrote:
>
> On Fri, Mar 26, 2021 at 11:13:21AM +0100, Richard Biener wrote:
> > On Fri, Mar 26, 2021 at 9:34 AM Jakub Jelinek via Gcc-patches
> > wrote:
> > >
> > > On Thu, Mar 25, 2021 at 11:36:37AM -0700, H.J. Lu via Gcc-patches wrote:
> > > > How c
On Fri, Mar 26, 2021 at 11:13:21AM +0100, Richard Biener wrote:
> On Fri, Mar 26, 2021 at 9:34 AM Jakub Jelinek via Gcc-patches
> wrote:
> >
> > On Thu, Mar 25, 2021 at 11:36:37AM -0700, H.J. Lu via Gcc-patches wrote:
> > > How can we move forward with it? I'd like to resolve it in GCC 11.
> >
>
On Fri, Mar 26, 2021 at 9:34 AM Jakub Jelinek via Gcc-patches
wrote:
>
> On Thu, Mar 25, 2021 at 11:36:37AM -0700, H.J. Lu via Gcc-patches wrote:
> > How can we move forward with it? I'd like to resolve it in GCC 11.
>
> I think it is too late for GCC 11 for this.
> Especially if the solution wou
On Thu, Mar 25, 2021 at 11:36:37AM -0700, H.J. Lu via Gcc-patches wrote:
> How can we move forward with it? I'd like to resolve it in GCC 11.
I think it is too late for GCC 11 for this.
Especially if the solution would be that we change the behavior of existing
attribute, we would need enough tim
On Thu, Mar 25, 2021 at 7:37 PM H.J. Lu wrote:
>
> On Thu, Mar 25, 2021 at 7:54 AM Jakub Jelinek via Gcc-patches
> wrote:
> >
> > On Thu, Mar 25, 2021 at 03:40:51PM +0100, Richard Biener wrote:
> > > I think the "proper" way to do this is to have 'open' above end up
> > > refering to the out-of-l
On Thu, Mar 25, 2021 at 7:54 AM Jakub Jelinek via Gcc-patches
wrote:
>
> On Thu, Mar 25, 2021 at 03:40:51PM +0100, Richard Biener wrote:
> > I think the "proper" way to do this is to have 'open' above end up
> > refering to the out-of-line 'open' in the DSO, _not_ to emit the
> > fortification wra
On Thu, Mar 25, 2021 at 03:40:51PM +0100, Richard Biener wrote:
> I think the "proper" way to do this is to have 'open' above end up
> refering to the out-of-line 'open' in the DSO, _not_ to emit the
> fortification wrapper out-of-line. But then, yes, it shouldn't
> be always-inline then. It shou
On Thu, Mar 25, 2021 at 3:32 PM Jakub Jelinek wrote:
>
> On Thu, Mar 25, 2021 at 03:24:38PM +0100, Richard Biener wrote:
> > Well, but in all of those cases the program was invalid (and is diagnosed).
> > So it simply means "always inline". That we abuse the always-inline
> > (error) diagnostic t
On Thu, Mar 25, 2021 at 03:24:38PM +0100, Richard Biener wrote:
> Well, but in all of those cases the program was invalid (and is diagnosed).
> So it simply means "always inline". That we abuse the always-inline
> (error) diagnostic to tell users about possible problems (and in HJs case
> and the
On Thu, Mar 25, 2021 at 2:39 PM Jakub Jelinek wrote:
>
> On Thu, Mar 25, 2021 at 02:21:21PM +0100, Richard Biener wrote:
> > Err, but _which_ mismatches do you ignore with such new attribute?
>
> We'd need to define it.
>
> > If I have __rdtsc and compile that into a -mno-rdtsc unit/function would
On Thu, Mar 25, 2021 at 7:59 AM Uros Bizjak wrote:
>
> On Wed, Mar 24, 2021 at 6:23 PM H.J. Lu wrote:
> >
> > For always_inline in system headers, we don't know if caller's ISAs are
> > compatible with callee's ISAs until much later. Skip ISA check for
> > always_inline in system headers if call
On Thu, Mar 25, 2021 at 02:21:21PM +0100, Richard Biener wrote:
> Err, but _which_ mismatches do you ignore with such new attribute?
We'd need to define it.
> If I have __rdtsc and compile that into a -mno-rdtsc unit/function would
> that be OK?
There is no -mno-rdtsc or -mrdtsc, rdtsc insn is a
On Thu, Mar 25, 2021 at 2:25 PM H.J. Lu via Gcc-patches
wrote:
>
> On Thu, Mar 25, 2021 at 6:13 AM Jakub Jelinek wrote:
> >
> > On Thu, Mar 25, 2021 at 02:02:16PM +0100, Uros Bizjak wrote:
> > > > Aren't *intrin.h system headers too?
> > >
> > > I was under impression that they are not, since the
On Thu, Mar 25, 2021 at 6:13 AM Jakub Jelinek wrote:
>
> On Thu, Mar 25, 2021 at 02:02:16PM +0100, Uros Bizjak wrote:
> > > Aren't *intrin.h system headers too?
> >
> > I was under impression that they are not, since they live outside of
> > /usr/include.
>
> Yes, they aren't in /usr/include, but
On Thu, Mar 25, 2021 at 2:14 PM Jakub Jelinek via Gcc-patches
wrote:
>
> On Thu, Mar 25, 2021 at 02:02:16PM +0100, Uros Bizjak wrote:
> > > Aren't *intrin.h system headers too?
> >
> > I was under impression that they are not, since they live outside of
> > /usr/include.
>
> Yes, they aren't in /u
On Thu, Mar 25, 2021 at 02:02:16PM +0100, Uros Bizjak wrote:
> > Aren't *intrin.h system headers too?
>
> I was under impression that they are not, since they live outside of
> /usr/include.
Yes, they aren't in /usr/include, but they are still system headers.
If I preprocess something that #inclu
On Thu, Mar 25, 2021 at 2:03 PM Uros Bizjak via Gcc-patches
wrote:
>
> On Thu, Mar 25, 2021 at 1:54 PM Jakub Jelinek wrote:
> >
> > On Wed, Mar 24, 2021 at 10:23:44AM -0700, H.J. Lu via Gcc-patches wrote:
> > > For always_inline in system headers, we don't know if caller's ISAs are
> > > compatib
On Thu, Mar 25, 2021 at 1:54 PM Jakub Jelinek wrote:
>
> On Wed, Mar 24, 2021 at 10:23:44AM -0700, H.J. Lu via Gcc-patches wrote:
> > For always_inline in system headers, we don't know if caller's ISAs are
> > compatible with callee's ISAs until much later. Skip ISA check for
> > always_inline in
On Wed, Mar 24, 2021 at 10:23:44AM -0700, H.J. Lu via Gcc-patches wrote:
> For always_inline in system headers, we don't know if caller's ISAs are
> compatible with callee's ISAs until much later. Skip ISA check for
> always_inline in system headers if caller has target attribute.
>
> gcc/
>
>
On Wed, Mar 24, 2021 at 6:23 PM H.J. Lu wrote:
>
> For always_inline in system headers, we don't know if caller's ISAs are
> compatible with callee's ISAs until much later. Skip ISA check for
> always_inline in system headers if caller has target attribute.
>
> gcc/
>
> PR target/98209
>
For always_inline in system headers, we don't know if caller's ISAs are
compatible with callee's ISAs until much later. Skip ISA check for
always_inline in system headers if caller has target attribute.
gcc/
PR target/98209
PR target/99744
* config/i386/i386.c (ix86_can_i
25 matches
Mail list logo
