Displaying 19 results from an estimated 19 matches for "biener".
Did you mean:
diener
2016 Mar 18
3
Redundant load in llvm's codegen compares to gcc when accessing escaped pointer?
...efinition.
> > Is llvm too conservative, or gcc too aggressive in this pattern?
>
> In my opinion, in the face of -fno-strict-aliasing, GCC is being too
> aggressive. It would be interesting to hear what they think.
We discussed this issue briefly on the #gcc IRC channel.
Richard Biener pointed out that bar cannot make c point to &c - 8,
because computing that pointer would be invalid. So c->f1_ cannot
clobber c itself.
--
Markus
2011 May 23
1
delegation of admin rights
...er this as a candidate for a request for enhancement ? This would
be very useful in a delegated administration
environment, like most larger organizations, hosting & ISP, and other
environments where delegation is an important
and very much needed ability.
thanks a bunch,
-- Ariel
--
Ariel Biener
e-mail: ariel at post.tau.ac.il
PGP: http://www.tau.ac.il/~ariel/pgp.html
2020 Jul 13
2
New x86-64 micro-architecture levels
On 13.07.2020 09:40, Florian Weimer wrote:
> * Richard Biener:
>>> 2. I have a library with AVX2 and FMA, which directory should it go?
>>
>> Eventually GCC/gas can annotate objects with the lowest architecture
>> level that is applicable?
>
> H.J. has patches for ELF program properties. I think
> GNU_PROPERTY_X86_ISA_1_N...
2016 Mar 19
2
Redundant load in llvm's codegen compares to gcc when accessing escaped pointer?
...gt; >
>>>> > In my opinion, in the face of -fno-strict-aliasing, GCC is being too
>>>> > aggressive. It would be interesting to hear what they think.
>>>>
>>>> We discussed this issue briefly on the #gcc IRC channel.
>>>> Richard Biener pointed out that bar cannot make c point to &c - 8,
>>>> because computing that pointer would be invalid. So c->f1_ cannot
>>>> clobber c itself.
>>>>
>>>> --
>>>> Markus
>>>> ____________________________________________...
2018 Nov 29
2
PROPOSAL: Extend inline asm syntax with size spec
Hi.
On Wed, Oct 10, 2018 at 1:14 AM Segher Boessenkool
<segher at kernel.crashing.org> wrote:
>
> On Mon, Oct 08, 2018 at 11:07:46AM +0200, Richard Biener wrote:
> > On Mon, 8 Oct 2018, Segher Boessenkool wrote:
> > > On Sun, Oct 07, 2018 at 03:53:26PM +0000, Michael Matz wrote:
> > > > On Sun, 7 Oct 2018, Segher Boessenkool wrote:
> > > > > On Sun, Oct 07, 2018 at 11:18:06AM +0200, Borislav Petkov wrote:
>...
2018 Nov 29
2
PROPOSAL: Extend inline asm syntax with size spec
Hi.
On Wed, Oct 10, 2018 at 1:14 AM Segher Boessenkool
<segher at kernel.crashing.org> wrote:
>
> On Mon, Oct 08, 2018 at 11:07:46AM +0200, Richard Biener wrote:
> > On Mon, 8 Oct 2018, Segher Boessenkool wrote:
> > > On Sun, Oct 07, 2018 at 03:53:26PM +0000, Michael Matz wrote:
> > > > On Sun, 7 Oct 2018, Segher Boessenkool wrote:
> > > > > On Sun, Oct 07, 2018 at 11:18:06AM +0200, Borislav Petkov wrote:
>...
2016 Mar 22
0
Redundant load in llvm's codegen compares to gcc when accessing escaped pointer?
...;t be an object of type PB at c-8.
>>
>> (IE any valid object must be sizeof(PB) away in either direction, which means it's not possible for c->f1_ to clobber c no matter what bar does)
>>> We discussed this issue briefly on the #gcc IRC channel.
>>> Richard Biener pointed out that bar cannot make c point to &c - 8,
>>> because computing that pointer would be invalid. So c->f1_ cannot
>>> clobber c itself.
>>>
>>> --
>>> Markus
2016 Mar 18
4
Redundant load in llvm's codegen compares to gcc when accessing escaped pointer?
...cc too aggressive in this pattern?
>> >
>> > In my opinion, in the face of -fno-strict-aliasing, GCC is being too
>> > aggressive. It would be interesting to hear what they think.
>>
>> We discussed this issue briefly on the #gcc IRC channel.
>> Richard Biener pointed out that bar cannot make c point to &c - 8,
>> because computing that pointer would be invalid. So c->f1_ cannot
>> clobber c itself.
>>
>> --
>> Markus
>> _______________________________________________
>> LLVM Developers mailing list
>&g...
2020 Jul 22
2
New x86-64 micro-architecture levels
* Richard Biener:
> On Wed, Jul 22, 2020 at 10:58 AM Florian Weimer via Gcc <gcc at gcc.gnu.org> wrote:
>>
>> * Dongsheng Song:
>>
>> > I fully agree these names (100/101, A/B/C/D) are not very intuitive, I
>> > recommend using isa tags by year (e.g. x64_2010, x64_2014)...
2020 Jul 13
3
New x86-64 micro-architecture levels
On Fri, Jul 10, 2020 at 11:45 PM H.J. Lu via Gcc <gcc at gcc.gnu.org> wrote:
>
> On Fri, Jul 10, 2020 at 10:30 AM Florian Weimer <fweimer at redhat.com> wrote:
> >
> > Most Linux distributions still compile against the original x86-64
> > baseline that was based on the AMD K8 (minus the 3DNow! parts, for Intel
> > EM64T compatibility).
> >
> >
2020 Jul 22
3
New x86-64 micro-architecture levels
* Dongsheng Song:
> I fully agree these names (100/101, A/B/C/D) are not very intuitive, I
> recommend using isa tags by year (e.g. x64_2010, x64_2014) like the
> python's platform tags (e.g. manylinux2010, manylinux2014).
I started out with a year number, but that was before the was Level A.
Too many new CPUs only fall under level A unfortunately because they do
not even have AVX.
2018 Oct 10
0
PROPOSAL: Extend inline asm syntax with size spec
* Segher Boessenkool <segher at kernel.crashing.org> wrote:
> On Mon, Oct 08, 2018 at 11:07:46AM +0200, Richard Biener wrote:
> > On Mon, 8 Oct 2018, Segher Boessenkool wrote:
> > > On Sun, Oct 07, 2018 at 03:53:26PM +0000, Michael Matz wrote:
> > > > On Sun, 7 Oct 2018, Segher Boessenkool wrote:
> > > > > On Sun, Oct 07, 2018 at 11:18:06AM +0200, Borislav Petkov wrote:
>...
2018 Oct 10
0
PROPOSAL: Extend inline asm syntax with size spec
* Richard Biener <rguenther at suse.de> wrote:
> Can kernel folks give this a second and third thought please so we
> don't implement sth that in the end won't satisfy you guys?
So this basically passes '0 size' to the inliner, which should be better
than passing in the explicit size,...
2018 Nov 29
0
PROPOSAL: Extend inline asm syntax with size spec
On Thu, Nov 29, 2018 at 02:09:25PM +0100, Richard Biener wrote:
> I'd be not opposed to backporting the asm inline support.
Even better! :-)
> Of course we still have to be happy with it and install the patch ;)
>
> Are you (kernel folks) happy with asm inline ()?
Yes, I think we are:
https://lkml.kernel.org/r/20181031125526.GA13219...
2016 Mar 23
1
Redundant load in llvm's codegen compares to gcc when accessing escaped pointer?
...> >>
> >> (IE any valid object must be sizeof(PB) away in either direction,
> which means it's not possible for c->f1_ to clobber c no matter what bar
> does)
>
> >>> We discussed this issue briefly on the #gcc IRC channel.
> >>> Richard Biener pointed out that bar cannot make c point to &c - 8,
> >>> because computing that pointer would be invalid. So c->f1_ cannot
> >>> clobber c itself.
> >>>
> >>> --
> >>> Markus
> _______________________________________________
>...
2016 Mar 15
2
Redundant load in llvm's codegen compares to gcc when accessing escaped pointer?
Hi,
Please look at this c code:
typedef struct _PB {
void* data; /* required.*/
int f1_;
float f2_;
} PB;
PB** bar(PB** t);
void qux(PB* c) {
bar(&c); /* c is escaped because of bar */
c->f1_ = 0;
c->f2_ = 0.f;
}
// gcc-5.2.1 with -fno-strict-aliasing -O2 on x86
call bar
movq 8(%rsp), %rax
movl $0, 8(%rax)
movl $0x00000000, 12(%rax)
// llvm
2009 Oct 05
1
dovecot 1.0.15 upgrading to dovecot 1.1.x or 1.2.x, and POP3 UIDL issue
Hi,
We're upgrading a cluster of servers from v1.0.15 to
v1.1.x or v1.2.x. It appears that the UIDL generation mechanism
has changed, and thus we'll be getting POP3 dups with users
that leave mail on server (which is a nasty practice, I know).
From checking the sources, and performing a number of controlled
tests in various scenarios, here is the outcome:
upgrade from 1.0.15 to
2018 Aug 12
4
GCC 5 and -Wstrict-aliasing in JSON.h
I did some more extensive testing and found that all GCCs older than 7
trigger the warning, but only if CMAKE_BUILD_TYPE=Release (which I
guess indicates optimizations are enabled).
There's a patch up for disabling the warning here:
https://reviews.llvm.org/D50607.
I still feel a little uncomfortable, because I think Jonathan makes an
excellent point -- if GCC thinks there's a
2018 Aug 17
0
GCC 5 and -Wstrict-aliasing in JSON.h
On Tue, 14 Aug 2018, Andrew Haley wrote:
> On 08/14/2018 11:55 AM, Kim Gräsman wrote:
> > On Tue, Aug 14, 2018 at 11:51 AM Andrew Haley <aph at redhat.com> wrote:
> >>
> >> On 08/12/2018 02:19 PM, Kim Gräsman wrote:
> >>> I still feel a little uncomfortable, because I think Jonathan makes an
> >>> excellent point -- if GCC thinks