Displaying 8 results from an estimated 8 matches for "unsequenced".
Did you mean:
sequenced
2018 Feb 20
3
[GSOC 2018] Information gathering
...I'm Paul Semel, a French student in computer science. I am currently in
my 4th year (1st year of graduate school) at EPITA and enrolled in the
system and security laboratory of the school.
I would be very interested in working on a LLVM project during this
GSoC. Implementing a PoC for an unsequenced modification checker in CSA
helped me discover LLVM. However, I would like to dive deeper in this
project.
I've seen some of the proposals, and I would like to ask a few questions
about two of those.
As you might have guessed, I have some interest in the checker for
dangling string pointe...
2018 Mar 02
2
[cfe-dev] [GSOC 2018] Information gathering
Hey, welcome!
I'm curious about the unsequenced modification checker, is it something
that I should have seen but missed for whatever reason? It might be
useful, and I think I'm seeing why don't compiler warnings cover all
cases, i.e. why the analyzer's path sensitivity would help here. But I
can't answer until I see it :) -e...
2018 Mar 01
0
[cfe-dev] [GSOC 2018] Information gathering
...French student in computer science. I am currently in
> my 4th year (1st year of graduate school) at EPITA and enrolled in the
> system and security laboratory of the school.
>
> I would be very interested in working on a LLVM project during this
> GSoC. Implementing a PoC for an unsequenced modification checker in CSA
> helped me discover LLVM. However, I would like to dive deeper in this
> project.
>
> I've seen some of the proposals, and I would like to ask a few questions
> about two of those.
>
> As you might have guessed, I have some interest in the...
2018 Mar 06
0
[cfe-dev] [GSOC 2018] Information gathering
Hi,
Thanks for replying !
On 03/02/2018 10:58 PM, Artem Dergachev wrote:
> Hey, welcome!
>
> I'm curious about the unsequenced modification checker, is it something
> that I should have seen but missed for whatever reason? It might be
> useful, and I think I'm seeing why don't compiler warnings cover all
> cases, i.e. why the analyzer's path sensitivity would help here. But I
> can't answer...
2014 Apr 08
2
[LLVMdev] Why "I = ++I" instead of "++I" in COFFDump.cpp ?
On Mon, Apr 7, 2014 at 12:09 PM, Joerg Sonnenberger <joerg at britannica.bec.de
> wrote:
> On Mon, Apr 07, 2014 at 08:38:58AM -0600, Richard wrote:
> > Oops, meant to send this to the mailing list instead of to Reid
> > privately. (Why cc the mailing list instead of just sending to the
> > mailing list?)
> >
> > In article <CACs=
>
2018 Mar 08
2
[cfe-dev] [GSOC 2018] Information gathering
...omputer science. I am currently
>> in my 4th year (1st year of graduate school) at EPITA and enrolled in
>> the system and security laboratory of the school.
>>
>> I would be very interested in working on a LLVM project during this
>> GSoC. Implementing a PoC for an unsequenced modification checker in
>> CSA helped me discover LLVM. However, I would like to dive deeper in
>> this project.
>>
>> I've seen some of the proposals, and I would like to ask a few
>> questions about two of those.
>>
>> As you might have guessed, I...
2018 Jul 12
2
[RFC] A nofree (and nosynch) function attribute: Mixing dereferenceable and delete
..., nor a region of storage of suitable size and
> alignment to contain an object of the reference's type (4.5
> [intro.object], 6.8 [basic.life], 6.9 [basic.types]), the behavior is
> undefined."
>
> My take is that, if the end of the duration of the region of storage
> is unsequenced with respect to the binding of the reference, then
> behavior is undefined. Generally when we refer to a thing happening
> while some condition is true, we mean that the execution point when
> the condition became true is sequenced before the thing happening, and
> the execution point w...
2018 Jul 11
3
[RFC] A nofree (and nosynch) function attribute: Mixing dereferenceable and delete
[+Richard]
On 07/11/2018 08:29 AM, Sanjoy Das wrote:
> I'm not sure if nosynch is sufficient. What if we had:
>
> void f(int& x) {
> if (false) {
> int r0 = x;
> }
> }
>
> // other thread
> free(<pointer to x>);
>
> The source program is race free, but LLVM may speculate the read from
> x (seeing that it is dereferenceable) creating a