On Fri, Apr 12, 2019 at 5:31 PM Peter Sewell wrote:
>
> On Fri, 12 Apr 2019 at 15:51, Jeff Law wrote:
> >
> > On 4/2/19 2:11 AM, Peter Sewell wrote:
> > > Dear all,
> > >
> > > continuing the discussion from the 2018 GNU Tools Cauldron, we
> > > (the WG14 C memory object model study group) now
>
On 17/04/2019, Richard Biener wrote:
> On Fri, Apr 12, 2019 at 5:31 PM Peter Sewell
> wrote:
>>
>> On Fri, 12 Apr 2019 at 15:51, Jeff Law wrote:
>> >
>> > On 4/2/19 2:11 AM, Peter Sewell wrote:
>> > > Dear all,
>> > >
>> > > continuing the discussion from the 2018 GNU Tools Cauldron, we
>> > > (
On Wed, Apr 17, 2019 at 11:15 AM Peter Sewell wrote:
>
> On 17/04/2019, Richard Biener wrote:
> > On Fri, Apr 12, 2019 at 5:31 PM Peter Sewell
> > wrote:
> >>
> >> On Fri, 12 Apr 2019 at 15:51, Jeff Law wrote:
> >> >
> >> > On 4/2/19 2:11 AM, Peter Sewell wrote:
> >> > > Dear all,
> >> > >
> >>
Hi Richard,
Am Mittwoch, den 17.04.2019, 11:41 +0200 schrieb Richard Biener:
> On Wed, Apr 17, 2019 at 11:15 AM Peter Sewell
> wrote:
> >
> > On 17/04/2019, Richard Biener wrote:
> > > On Fri, Apr 12, 2019 at 5:31 PM Peter Sewell
> > > wrote:
...
> > > So this is not what GCC implements whi
On Wed, Apr 17, 2019 at 1:53 PM Uecker, Martin
wrote:
>
>
> Hi Richard,
>
> Am Mittwoch, den 17.04.2019, 11:41 +0200 schrieb Richard Biener:
> > On Wed, Apr 17, 2019 at 11:15 AM Peter Sewell
> > wrote:
> > >
> > > On 17/04/2019, Richard Biener wrote:
> > > > On Fri, Apr 12, 2019 at 5:31 PM Pete
Am Mittwoch, den 17.04.2019, 14:41 +0200 schrieb Richard Biener:
> On Wed, Apr 17, 2019 at 1:53 PM Uecker, Martin
> wrote:
> >
> > > Since
> > > your proposal is based on an abstract machine there isn't anything
> > > like a pointer with multiple provenances (which "anything" is), just
> > > po
On Wed, Apr 17, 2019 at 2:56 PM Uecker, Martin
wrote:
>
> Am Mittwoch, den 17.04.2019, 14:41 +0200 schrieb Richard Biener:
> > On Wed, Apr 17, 2019 at 1:53 PM Uecker, Martin
> > wrote:
>
> > >
> > > > Since
> > > > your proposal is based on an abstract machine there isn't anything
> > > > like a
Am Mittwoch, den 17.04.2019, 15:34 +0200 schrieb Richard Biener:
> On Wed, Apr 17, 2019 at 2:56 PM Uecker, Martin
> wrote:
> >
> > Am Mittwoch, den 17.04.2019, 14:41 +0200 schrieb Richard Biener:
> > > On Wed, Apr 17, 2019 at 1:53 PM Uecker, Martin
> > > wrote:
> > > >
> > > > > Since
> > > >
On Mon, 1 Apr 2019, Patrick Palka wrote:
> > > > A possibly related project is to "defer" output of diagnostics
> > > > until we know the stmt/expression we emit it for survived dead
> > > > code elimination. Here there's the question what to key the
> > > > diagnostic off and how to move it (
On Wed, 3 Apr 2019, Richard Biener wrote:
> > 1) Is there some reason to align vectors on the same boundary
> > as their size no matter how big it is? I can't find such
> > a requirement in the ABIs I looked at. Or would it be more
> > appropriate to align the big ones on the preferr
On Mon, 8 Apr 2019, Richard Biener wrote:
> That is, the C testcase
>
> const char x[1024*1024] = {};
>
> reproduces the "issue". The comment in bss_initializer_p though
> explicitely says
>
> /* Do not put non-common constants into the .bss section, they belong in
> a readonly section,
On Wed, 17 Apr 2019 at 15:12, Uecker, Martin
wrote:
>
> Am Mittwoch, den 17.04.2019, 15:34 +0200 schrieb Richard Biener:
> > On Wed, Apr 17, 2019 at 2:56 PM Uecker, Martin
> > wrote:
> > >
> > > Am Mittwoch, den 17.04.2019, 14:41 +0200 schrieb Richard Biener:
> > > > On Wed, Apr 17, 2019 at 1:53
t;, 3);
|^~~
.text
.globl f
.type f, @function
f:
.LFB0:
.cfi_startproc
ret
.cfi_endproc
.LFE0:
.size f, .-f
.ident "GCC: (GNU) 9.0.1 20190417 (experimental)"
.section.note.GNU-stack,"",@progbits
13 matches
Mail list logo
