Hello everyone,
I am trying to see how a new type qualifier only for pointer variables is
suitable to be in standard semantically. I have this thread (
https://gcc.gnu.org/ml/gcc-patches/2019-08/msg02015.html ) where Joseph
discussed a bit about what a new type qualifier should satisfy. Can
somebo
On Wed, Jul 24, 2019 at 1:41 AM Akshat Garg wrote:
> Hi all,
>
> I have tried to make the dependent_ptr qualification act as volatile
> during the RTL passes to bypass the RTL optimizations for now. Here is the
> patch
> https://github.com
, 2019 at 3:16 PM Richard Biener
wrote:
> On Mon, Jul 22, 2019 at 10:54 AM Akshat Garg wrote:
>
>> On Mon, Jul 22, 2019 at 2:11 PM Richard Biener <
>> richard.guent...@gmail.com> wrote:
>>
>>> On Mon, Jul 22, 2019 at 2:27 AM Akshat Garg wrote:
>>&g
On Mon, Jul 22, 2019 at 2:11 PM Richard Biener
wrote:
> On Mon, Jul 22, 2019 at 2:27 AM Akshat Garg wrote:
>
>> Hi all,
>> Consider part of an example(figure 20) from doc P0190R4(
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0190r4.pdf)
>> shown
3 PM Akshat Garg wrote:
> On Tue, Jul 2, 2019 at 9:06 PM Jason Merrill wrote:
>
>> On Mon, Jul 1, 2019 at 8:59 PM Paul E. McKenney
>> wrote:
>> >
>> > On Tue, Jul 02, 2019 at 05:58:48AM +0530, Akshat Garg wrote:
>> > > On Tue, Jun 25, 2019 at 9:4
On Tue, Jul 2, 2019 at 9:06 PM Jason Merrill wrote:
> On Mon, Jul 1, 2019 at 8:59 PM Paul E. McKenney
> wrote:
> >
> > On Tue, Jul 02, 2019 at 05:58:48AM +0530, Akshat Garg wrote:
> > > On Tue, Jun 25, 2019 at 9:49 PM Akshat Garg wrote:
> > >
> >
Hi all,
We are working on making memory_order_consume not get promoted to
memory_order_acquire. Here is a little background on the work we are doing
https://gcc.gnu.org/ml/gcc/2019-07/msg00038.html
We are able to parse _Dependent_ptr from C front-end. The patch files are
given here.
https://githu
On Sun, Jul 7, 2019 at 9:48 PM Akshat Garg wrote:
> On Sun, Jul 7, 2019 at 7:49 PM Paul E. McKenney
> wrote:
>
>> On Sat, Jul 06, 2019 at 12:39:45PM +0530, Akshat Garg wrote:
>> > On Sat, Jul 6, 2019 at 1:09 AM Akshat Garg wrote:
>> >
>> > > On
On Fri, 5 Jul, 2019, 4:50 PM Richard Biener,
wrote:
> On Fri, Jul 5, 2019 at 1:08 AM Akshat Garg wrote:
> >
> > On Thu, Jul 4, 2019 at 11:39 PM Jakub Jelinek wrote:
> >>
> >> On Thu, Jul 04, 2019 at 10:40:15AM -0700, Paul E. McKenney wrote:
> >> &
On Thu, Jul 4, 2019 at 11:39 PM Jakub Jelinek wrote:
> On Thu, Jul 04, 2019 at 10:40:15AM -0700, Paul E. McKenney wrote:
> > > I think fully guaranteeing this is hard (besides when you use
> > > volatile), we have the very same issue when dealing with
> > > pointer provenance rules, known for yea
On Tue, Jul 2, 2019 at 9:06 PM Jason Merrill wrote:
> On Mon, Jul 1, 2019 at 8:59 PM Paul E. McKenney
> wrote:
> >
> > On Tue, Jul 02, 2019 at 05:58:48AM +0530, Akshat Garg wrote:
> > > On Tue, Jun 25, 2019 at 9:49 PM Akshat Garg wrote:
> > >
> >
On Tue, Jul 2, 2019 at 8:40 PM Paul E. McKenney
wrote:
> On Tue, Jul 02, 2019 at 02:15:55PM +0100, Ramana Radhakrishnan wrote:
> > On Tue, Jul 2, 2019 at 1:38 PM Paul E. McKenney
> wrote:
> >
> > >
> > > Once a user-created non-dependent pointer is assigned to, it is OK to
> > > break the depend
On Tue, 2 Jul, 2019, 3:52 PM Ramana Radhakrishnan, <
ramana@googlemail.com> wrote:
> On Tue, Jul 2, 2019 at 1:29 AM Akshat Garg wrote:
> >
> > On Tue, Jun 25, 2019 at 9:49 PM Akshat Garg wrote:
> >>
> >> On Tue, Jun 25, 2019 at 4:04 PM Ramana Radh
On Tue, Jun 25, 2019 at 9:49 PM Akshat Garg wrote:
> On Tue, Jun 25, 2019 at 4:04 PM Ramana Radhakrishnan <
> ramana@googlemail.com> wrote:
>
>> On Tue, Jun 25, 2019 at 11:03 AM Akshat Garg wrote:
>> >
>> > As we have some working front-end code for _D
On Tue, Jun 25, 2019 at 4:04 PM Ramana Radhakrishnan <
ramana@googlemail.com> wrote:
> On Tue, Jun 25, 2019 at 11:03 AM Akshat Garg wrote:
> >
> > As we have some working front-end code for _Dependent_ptr, What should
> we do next? What I understand, we can star
---
commit fb4187bc3872a50880159232cf336f0a03505fa8
Author: Akshat Garg
Date: Sat Jun 8 15:06:23 2019 +0530
Add _Dependent_ptr qualifier
diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
index 4057be3..6d37851 100644
--- a/gcc/c-family/c-common.c
+++ b/gcc/c-family/c
On Sun, Jun 23, 2019 at 3:27 AM Jonathan Wakely
wrote:
> On Sat, 22 Jun 2019 at 12:25, Akshat Garg wrote:
> >
> > On Sat, Jun 22, 2019 at 1:10 PM Andreas Schwab
> > wrote:
> >
> > > On Jun 22 2019, Akshat Garg wrote:
> > >
> > > > I be
On Sat, Jun 22, 2019 at 1:10 PM Andreas Schwab
wrote:
> On Jun 22 2019, Akshat Garg wrote:
>
> > I believe I should be getting a warning like:
> > warning: initialization from incompatible pointer type
> > [-Wincompatible-pointer-types]
> > but in the gcc.log
Hello all,
I have been trying to run a test which assigns a value from non-atomic to
an atomic pointer type. The code is as follows:
/* File: xyz.c */
/* { dg-do compile } */
/* { dg-options "-std=c11 -pedantic-errors" } */
#include
typedef __SIZE_TYPE__ size_t;
extern void abort (void);
exte
On Sun, Jun 9, 2019 at 1:57 AM Jonathan Wakely
wrote:
> On Sat, 8 Jun 2019 at 19:03, Akshat Garg wrote:
> >
> > On Sat, Jun 8, 2019 at 9:20 PM Eric Botcazou
> wrote:
> >
> > > > Makefile:2323: recipe for target 'do-check' failed
> > > >
On Sat, Jun 8, 2019 at 9:20 PM Eric Botcazou wrote:
> > Makefile:2323: recipe for target 'do-check' failed
> > make: *** [do-check] Error 2
> > make: Target 'check' not remade because of errors.
> >
> > Please, can anyone let me know what am I doing wrong?
>
> Nothing, this just means that there
Hello all,
GCC build details:
Using built-in specs.
COLLECT_GCC=../build/gcc/xgcc
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --enable-languages=c,c++
Thread model: posix
gcc version 10.0.0 20190607 (experimental) (GCC)
I have been trying to run the testsuite using the gcc trun
22 matches
Mail list logo
