This certainly doesn't occur in gcc mainline. In fact, I improved the error message, and added a error test to gcc just yesterday. On 8/9/07, Chris Lattner <sabre at nondot.org> wrote:> On Wed, 8 Aug 2007, Nikhil A. Patil wrote: > > I think I found a bug. I don't know if it's in upstream gcc or llvm-gcc4. > > Looks like a bug, please file a bugzilla entry. > > -Chris > > > int func() > > { > > const int *arr; > > arr[0] = 1; > > } > > > > $ llvm-gcc main.c -c; echo $? > > 0 > > > > $ gcc main.c -c > > main.c: In function 'func': > > main.c:4: error: assignment of read-only location > > > > The difference disappears when arr[0] is replaced by *arr. > > > > (I tried the above with gcc 4.1.2, 3.4.6, 4.0.3. (I don't have access > > to 4.0.1, off which llvm-gcc seems to be derived.) > > > > nikhil > > > > On 08/08/2007, Chris Lattner <sabre at nondot.org> wrote: > >> This property isn't preserved on the llvm ir, because const can always > >> be cast away. If you want mod information, then I suggest using the > >> aliasanalysis interface to get mod ref info for a call. > >> > >> -Chris > >> > >> http://nondot.org/sabre > >> http://llvm.org > >> > >> On Aug 8, 2007, at 12:07 AM, "Ryan M. Lefever" <lefever at crhc.uiuc.edu> > >> wrote: > >> > >>> How is c's const keyword translated when compiling c into llvm > >>> bytecode. > >>> I'm specifically interested in const pointer function arguments. > >>> Consider a function declared as follows in c: > >>> > >>> void f(const int* arg); > >>> > >>> When I examine f in llvm bytecode, how can I tell that arg is a > >>> pointer, > >>> whose contents can only be read, not written. > >>> > >>> Regards, > >>> Ryan > >>> _______________________________________________ > >>> LLVM Developers mailing list > >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >> _______________________________________________ > >> LLVM Developers mailing list > >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >> > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > -Chris > > -- > http://nondot.org/sabre/ > http://llvm.org/ > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
On Thu, 9 Aug 2007, Daniel Berlin wrote:> This certainly doesn't occur in gcc mainline. > In fact, I improved the error message, and added a error test to gcc > just yesterday.Yep, clang reports: t.c:4:12: error: read-only variable is not assignable arr[0] = 1; ~~~~~~ ^ 1 diagnostic generated. so this is specific to llvm-gcc somehow. -Chris> On 8/9/07, Chris Lattner <sabre at nondot.org> wrote: >> On Wed, 8 Aug 2007, Nikhil A. Patil wrote: >>> I think I found a bug. I don't know if it's in upstream gcc or llvm-gcc4. >> >> Looks like a bug, please file a bugzilla entry. >> >> -Chris >> >>> int func() >>> { >>> const int *arr; >>> arr[0] = 1; >>> } >>> >>> $ llvm-gcc main.c -c; echo $? >>> 0 >>> >>> $ gcc main.c -c >>> main.c: In function 'func': >>> main.c:4: error: assignment of read-only location >>> >>> The difference disappears when arr[0] is replaced by *arr. >>> >>> (I tried the above with gcc 4.1.2, 3.4.6, 4.0.3. (I don't have access >>> to 4.0.1, off which llvm-gcc seems to be derived.) >>> >>> nikhil >>> >>> On 08/08/2007, Chris Lattner <sabre at nondot.org> wrote: >>>> This property isn't preserved on the llvm ir, because const can always >>>> be cast away. If you want mod information, then I suggest using the >>>> aliasanalysis interface to get mod ref info for a call. >>>> >>>> -Chris >>>> >>>> http://nondot.org/sabre >>>> http://llvm.org >>>> >>>> On Aug 8, 2007, at 12:07 AM, "Ryan M. Lefever" <lefever at crhc.uiuc.edu> >>>> wrote: >>>> >>>>> How is c's const keyword translated when compiling c into llvm >>>>> bytecode. >>>>> I'm specifically interested in const pointer function arguments. >>>>> Consider a function declared as follows in c: >>>>> >>>>> void f(const int* arg); >>>>> >>>>> When I examine f in llvm bytecode, how can I tell that arg is a >>>>> pointer, >>>>> whose contents can only be read, not written. >>>>> >>>>> Regards, >>>>> Ryan >>>>> _______________________________________________ >>>>> LLVM Developers mailing list >>>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>>> _______________________________________________ >>>> LLVM Developers mailing list >>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>> >> >> -Chris >> >> -- >> http://nondot.org/sabre/ >> http://llvm.org/ >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-Chris -- http://nondot.org/sabre/ http://llvm.org/
I have filed the bug, and added your comments.
http://llvm.org/bugs/show_bug.cgi?id=1603
nikhil
On 09/08/07, Chris Lattner <sabre at nondot.org>
wrote:> On Thu, 9 Aug 2007, Daniel Berlin wrote:
> > This certainly doesn't occur in gcc mainline.
> > In fact, I improved the error message, and added a error test to gcc
> > just yesterday.
>
> Yep, clang reports:
>
> t.c:4:12: error: read-only variable is not assignable
> arr[0] = 1;
> ~~~~~~ ^
> 1 diagnostic generated.
>
> so this is specific to llvm-gcc somehow.
>
> -Chris
>
> > On 8/9/07, Chris Lattner <sabre at nondot.org> wrote:
> >> On Wed, 8 Aug 2007, Nikhil A. Patil wrote:
> >>> I think I found a bug. I don't know if it's in
upstream gcc or llvm-gcc4.
> >>
> >> Looks like a bug, please file a bugzilla entry.
> >>
> >> -Chris
> >>
> >>> int func()
> >>> {
> >>> const int *arr;
> >>> arr[0] = 1;
> >>> }
> >>>
> >>> $ llvm-gcc main.c -c; echo $?
> >>> 0
> >>>
> >>> $ gcc main.c -c
> >>> main.c: In function 'func':
> >>> main.c:4: error: assignment of read-only location
> >>>
> >>> The difference disappears when arr[0] is replaced by *arr.
> >>>
> >>> (I tried the above with gcc 4.1.2, 3.4.6, 4.0.3. (I don't
have access
> >>> to 4.0.1, off which llvm-gcc seems to be derived.)
> >>>
> >>> nikhil
> >>>
> >>> On 08/08/2007, Chris Lattner <sabre at nondot.org>
wrote:
> >>>> This property isn't preserved on the llvm ir, because
const can always
> >>>> be cast away. If you want mod information, then I suggest
using the
> >>>> aliasanalysis interface to get mod ref info for a call.
> >>>>
> >>>> -Chris
> >>>>
> >>>> http://nondot.org/sabre
> >>>> http://llvm.org
> >>>>
> >>>> On Aug 8, 2007, at 12:07 AM, "Ryan M. Lefever"
<lefever at crhc.uiuc.edu>
> >>>> wrote:
> >>>>
> >>>>> How is c's const keyword translated when compiling
c into llvm
> >>>>> bytecode.
> >>>>> I'm specifically interested in const pointer
function arguments.
> >>>>> Consider a function declared as follows in c:
> >>>>>
> >>>>> void f(const int* arg);
> >>>>>
> >>>>> When I examine f in llvm bytecode, how can I tell that
arg is a
> >>>>> pointer,
> >>>>> whose contents can only be read, not written.
> >>>>>
> >>>>> Regards,
> >>>>> Ryan
> >>>>> _______________________________________________
> >>>>> LLVM Developers mailing list
> >>>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> >>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >>>> _______________________________________________
> >>>> LLVM Developers mailing list
> >>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> >>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >>>>
> >>> _______________________________________________
> >>> LLVM Developers mailing list
> >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >>>
> >>
> >> -Chris
> >>
> >> --
> >> http://nondot.org/sabre/
> >> http://llvm.org/
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >>
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >
>
> -Chris
>
> --
> http://nondot.org/sabre/
> http://llvm.org/
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>