date:20130308

g++ member function .at() for arrays

2013-03-08 Thread Robin Whittle

I am a newbie to this list.  Thanks for GCC, g++ the C++ standard
library and GDB!  Apologies in advance if I have missed a web page where
this question is answered.  Perhaps this question belongs on the
libstdc++ list.

With g++ 4:4.7.2-1 and libstdc++6 4.7.2-4, installed on 64 bit Debian,
using the -std=c++11 compiler option, I attempted to compile code such as:

  aa1.at(1) = aa1.at(2) + aa1.at(3);
  cout << aa1.size() << endl;

where aa1 is an array of ints.  The error message was:

   error: request for member 'at' in 'aa1', which is of
   non-class type 'int [4]'.

Yet these lines for vectors and deques:

  vv1.at(1) = vv1.at(2) + vv1.at(3);
  dd1.at(1) = dd1.at(2) + dd1.at(3);

compiled and worked fine.  Both of these lines were implemented with
bounds checking.


According to my understanding of the near-final draft standard
n3242-1.pdf, page 729, in the last item of Table 101, the member
function at() should provide bounds checked access to:

  basic_string, string, array, deque and vector.

As far as I can tell, this does not work for arrays in 4.7.2.  Am I
missing a compiler option?

I think the .at() member function should apply to arrays, according to:

  http://en.cppreference.com/w/cpp/container/array/at

and page 265 of N. M. Josuttis "The C++ Standard Library 2nd Ed.".

I couldn't see specific mention of this at:


http://gcc.gnu.org/onlinedocs/gcc-4.7.2/libstdc++/manual/manual/status.html#status.iso.2011

other than the line:

  23.2.3  Sequence containers  Y


I am not sure if this functionality would be in g++ or libstdc++ or both
and I am not sure where to look in the documentation to see if it is or
will be implemented.  I didn't make any progress Googling for the
compiler error text or for any relevant terms I could think of.

Thanks again for GCC!

  - Robin

Re: g++ member function .at() for arrays

2013-03-08 Thread Robin Whittle

Further to my previous message, the start of my program is:

#include 
#include 

#include 
#include 
#include 

using std::vector;
using std::deque;
using std::cout;
using std::endl;

int main(int argc, char **argv)
{
   int aa1[4] = {0, 1, 2, 3};
   vector vv1{50, 51, 52, 53};
   deque dd1{100, 101, 102, 103};


  - Robin

Re: g++ member function .at() for arrays

2013-03-08 Thread James Dennett

On Fri, Mar 8, 2013 at 12:42 AM, Robin Whittle  wrote:
> I am a newbie to this list.  Thanks for GCC, g++ the C++ standard
> library and GDB!  Apologies in advance if I have missed a web page where
> this question is answered.  Perhaps this question belongs on the
> libstdc++ list.

It doesn't belong to gcc@gcc.gnu.org, which is for discussion of the
development of the compiler.  The user support list is
gcc-h...@gcc.gnu.org.  As your question is really more about C++ than
about GCC, you might also try a generic C++ forum.

> With g++ 4:4.7.2-1 and libstdc++6 4.7.2-4, installed on 64 bit Debian,
> using the -std=c++11 compiler option, I attempted to compile code such as:
>
>   aa1.at(1) = aa1.at(2) + aa1.at(3);
>   cout << aa1.size() << endl;
>
> where aa1 is an array of ints.  The error message was:
>
>error: request for member 'at' in 'aa1', which is of
>non-class type 'int [4]'.
>
> Yet these lines for vectors and deques:
>
>   vv1.at(1) = vv1.at(2) + vv1.at(3);
>   dd1.at(1) = dd1.at(2) + dd1.at(3);
>
> compiled and worked fine.  Both of these lines were implemented with
> bounds checking.
>
> According to my understanding of the near-final draft standard
> n3242-1.pdf, page 729, in the last item of Table 101, the member
> function at() should provide bounds checked access to:
>
>   basic_string, string, array, deque and vector.
>
> As far as I can tell, this does not work for arrays in 4.7.2.  Am I
> missing a compiler option?

No, but you do need to read about the difference between (buiilt-in)
arrays and instances of std::array types.  std::array has at; built-in
arrays such as int[4] do not have member functions (only classes do).

-- James

Re: g++ member function .at() for arrays

2013-03-08 Thread Florian Weimer


On 03/08/2013 10:07 AM, Robin Whittle wrote:

Further to my previous message, the start of my program is:



int aa1[4] = {0, 1, 2, 3};


This should work:

  std::array aa1 = {0, 1, 2, 3};

Your question is more appropriate for the gcc-help mailing list.  I'm 
redirecting it there.


--
Florian Weimer / Red Hat Product Security Team

ADDR_SPACE_CONVERT_EXPR always expanded to 0?

2013-03-08 Thread Georg-Johann Lay

While implementing PR56263 (Strict address-space checking for AVR), I
encountered the problem that pointer casts with address spaces are always
expanded as const_int 0.

The problem occurs if the attached patch that implements PR56263 and the
following code is compiled as

$ avr-gcc -Os flash-cast.c -S -mstrict-addr-space-subsets


#define PROGMEM __attribute__((__progmem__))

#define PSTR(s) \
  (__extension__\
   ({   \
 static const char __c[] PROGMEM = (s); \
 &__c[0];   \
   }))

extern void print (const __memx char*, ...);

const __flash char *p;

void f (const char *c)
{
c = (const char*) p;

print ((const __flash char*) PSTR ("Hallo flash"));
}



The corresponding .expand dump reads:


f (const char * c)
{
  static const char __c[12] = "Hallo flash";
  const  char * _2;
  const  char * _3;

;;   basic block 2, loop depth 0
;;pred:   ENTRY
  _2 = (const  char *) (&__c[0]);
  _3 = (const  char *) _2;
  print (_3); [tail call]
  return;
;;succ:   EXIT

}


but the expression is always emit as (const_int 0).


Trying to track this issue, I ended up in build1_stat which enters the default
case for "code" (ADDR_SPACE_CONVERT_EXPR at that time) and returns the
following tree:


(gdb) p t
$62 = (tree) 0xb7bb4578
(gdb) pt
 
unit size 
align 8 symtab 0 alias set -1 canonical type 0xb7bc3a20 precision 8
min  max 
pointer_to_this >
unsigned HI
size 
unit size 
align 8 symtab 0 alias set -1 canonical type 0xb7bc3a80>
readonly constant
arg 0 
public unsigned HI size  unit size

align 8 symtab 0 alias set -1 canonical type 0xb7b4f2a0
pointer_to_this >
readonly constant
arg 0 
readonly arg 0 
arg 1 
flash-cast.c:18:128>
flash-cast.c:18:124>>

Problem is the arg 1  at the end which leads
to the expansion of 0.

The call chain is:

#0  build1_stat (code=ADDR_SPACE_CONVERT_EXPR, type=0xb7bc3a80,
node=0xb7bb449c) at ../../../gcc.gnu.org/trunk/gcc/tree.c:3848
(gdb) bt
#0  build1_stat (code=ADDR_SPACE_CONVERT_EXPR, type=0xb7bc3a80,
node=0xb7bb449c) at ../../../gcc.gnu.org/trunk/gcc/tree.c:3848
#1  0x08286be0 in gimple_assign_rhs_to_tree (stmt=0xb7bc2c30) at
../../../gcc.gnu.org/trunk/gcc/cfgexpand.c:86
#2  0x0837047f in expand_expr_real_1 (exp=0xb7b972f8, target=0x0,
tmode=VOIDmode, modifier=EXPAND_STACK_PARM, alt_rtl=0x0) at
../../../gcc.gnu.org/trunk/gcc/expr.c:9274
#3  0x083762f2 in expand_expr_real (exp=0xb7b972f8, target=0x0, tmode=VOIDmode,
modifier=EXPAND_STACK_PARM, alt_rtl=0x0) at
../../../gcc.gnu.org/trunk/gcc/expr.c:7863
#4  0x08376a7e in expand_expr (exp=0xb7b972f8, target=0x0, mode=VOIDmode,
modifier=EXPAND_STACK_PARM) at ../../../gcc.gnu.org/trunk/gcc/expr.h:444
#5  0x0836ae96 in expand_expr_real_2 (ops=0xbfffca10, target=0x0,
tmode=VOIDmode, modifier=EXPAND_STACK_PARM) at
../../../gcc.gnu.org/trunk/gcc/expr.c:8150
#6  0x08376234 in expand_expr_real_1 (exp=0xb7bb4564, target=0x0,
tmode=VOIDmode, modifier=EXPAND_STACK_PARM, alt_rtl=0x0) at
../../../gcc.gnu.org/trunk/gcc/expr.c:10491
#7  0x083762f2 in expand_expr_real (exp=0xb7bb4564, target=0x0, tmode=VOIDmode,
modifier=EXPAND_STACK_PARM, alt_rtl=0x0) at
../../../gcc.gnu.org/trunk/gcc/expr.c:7863
#8  0x083704a6 in expand_expr_real_1 (exp=0xb7b97320, target=0x0,
tmode=VOIDmode, modifier=EXPAND_STACK_PARM, alt_rtl=0x0) at
../../../gcc.gnu.org/trunk/gcc/expr.c:9274
#9  0x083762f2 in expand_expr_real (exp=0xb7b97320, target=0x0, tmode=VOIDmode,
modifier=EXPAND_STACK_PARM, alt_rtl=0x0) at
../../../gcc.gnu.org/trunk/gcc/expr.c:7863
#10 0x0826ae1a in expand_expr (exp=0xb7b97320, target=0x0, mode=VOIDmode,
modifier=EXPAND_STACK_PARM) at ../../../gcc.gnu.org/trunk/gcc/expr.h:444
#11 0x0826c215 in store_one_arg (arg=0xbfffd130, argblock=0x0, flags=0,
variable_size=0, reg_parm_stack_space=0) at
../../../gcc.gnu.org/trunk/gcc/calls.c:4500
#12 0x08274d79 in expand_call (exp=0xb7b46640, target=0x0, ignore=1) at
../../../gcc.gnu.org/trunk/gcc/calls.c:3040
#13 0x08375088 in expand_expr_real_1 (exp=0xb7b46640, target=0x0,
tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at
../../../gcc.gnu.org/trunk/gcc/expr.c:10209
#14 0x0828cb86 in expand_call_stmt (stmt=0xb7fde140) at
../../../gcc.gnu.org/trunk/gcc/cfgexpand.c:2114

...


The problem comes apparent in #5 expand_expr_real_2

 if (targetm.addr_space.subset_p (as_to, as_from)
 || targetm.addr_space.subset_p (as_from, as_to))
   {
 op0 = expand_expr (treeop0, NULL_RTX, VOIDmode, modifier);
 op0 = targetm.addr_space.convert (op0, treeop0_type, type);
 gcc_assert (op0);
 return op0;

Re: ADDR_SPACE_CONVERT_EXPR always expanded to 0?

2013-03-08 Thread Richard Biener

On Fri, Mar 8, 2013 at 2:57 PM, Georg-Johann Lay  wrote:
> While implementing PR56263 (Strict address-space checking for AVR), I
> encountered the problem that pointer casts with address spaces are always
> expanded as const_int 0.
>
> The problem occurs if the attached patch that implements PR56263 and the
> following code is compiled as
>
> $ avr-gcc -Os flash-cast.c -S -mstrict-addr-space-subsets
>
>
> #define PROGMEM __attribute__((__progmem__))
>
> #define PSTR(s) \
>   (__extension__\
>({   \
>  static const char __c[] PROGMEM = (s); \
>  &__c[0];   \
>}))
>
> extern void print (const __memx char*, ...);
>
> const __flash char *p;
>
> void f (const char *c)
> {
> c = (const char*) p;
>
> print ((const __flash char*) PSTR ("Hallo flash"));
> }
>
>
>
> The corresponding .expand dump reads:
>
>
> f (const char * c)
> {
>   static const char __c[12] = "Hallo flash";
>   const  char * _2;
>   const  char * _3;
>
> ;;   basic block 2, loop depth 0
> ;;pred:   ENTRY
>   _2 = (const  char *) (&__c[0]);
>   _3 = (const  char *) _2;
>   print (_3); [tail call]
>   return;
> ;;succ:   EXIT
>
> }
>
>
> but the expression is always emit as (const_int 0).
>
>
> Trying to track this issue, I ended up in build1_stat which enters the default
> case for "code" (ADDR_SPACE_CONVERT_EXPR at that time) and returns the
> following tree:
>
>
> (gdb) p t
> $62 = (tree) 0xb7bb4578
> (gdb) pt
>   type  type  address-space-1 string-flag QI
> size 
> unit size 
> align 8 symtab 0 alias set -1 canonical type 0xb7bc3a20 precision 
> 8
> min  max 
> pointer_to_this >
> unsigned HI
> size 
> unit size 
> align 8 symtab 0 alias set -1 canonical type 0xb7bc3a80>
> readonly constant
> arg 0  type 
> public unsigned HI size  unit size
> 
> align 8 symtab 0 alias set -1 canonical type 0xb7b4f2a0
> pointer_to_this >
> readonly constant
> arg 0 
> readonly arg 0 
> arg 1 
> flash-cast.c:18:128>
> flash-cast.c:18:124>>
>
> Problem is the arg 1  at the end which 
> leads
> to the expansion of 0.
>
> The call chain is:
>
> #0  build1_stat (code=ADDR_SPACE_CONVERT_EXPR, type=0xb7bc3a80,
> node=0xb7bb449c) at ../../../gcc.gnu.org/trunk/gcc/tree.c:3848
> (gdb) bt
> #0  build1_stat (code=ADDR_SPACE_CONVERT_EXPR, type=0xb7bc3a80,
> node=0xb7bb449c) at ../../../gcc.gnu.org/trunk/gcc/tree.c:3848
> #1  0x08286be0 in gimple_assign_rhs_to_tree (stmt=0xb7bc2c30) at
> ../../../gcc.gnu.org/trunk/gcc/cfgexpand.c:86
> #2  0x0837047f in expand_expr_real_1 (exp=0xb7b972f8, target=0x0,
> tmode=VOIDmode, modifier=EXPAND_STACK_PARM, alt_rtl=0x0) at
> ../../../gcc.gnu.org/trunk/gcc/expr.c:9274
> #3  0x083762f2 in expand_expr_real (exp=0xb7b972f8, target=0x0, 
> tmode=VOIDmode,
> modifier=EXPAND_STACK_PARM, alt_rtl=0x0) at
> ../../../gcc.gnu.org/trunk/gcc/expr.c:7863
> #4  0x08376a7e in expand_expr (exp=0xb7b972f8, target=0x0, mode=VOIDmode,
> modifier=EXPAND_STACK_PARM) at ../../../gcc.gnu.org/trunk/gcc/expr.h:444
> #5  0x0836ae96 in expand_expr_real_2 (ops=0xbfffca10, target=0x0,
> tmode=VOIDmode, modifier=EXPAND_STACK_PARM) at
> ../../../gcc.gnu.org/trunk/gcc/expr.c:8150
> #6  0x08376234 in expand_expr_real_1 (exp=0xb7bb4564, target=0x0,
> tmode=VOIDmode, modifier=EXPAND_STACK_PARM, alt_rtl=0x0) at
> ../../../gcc.gnu.org/trunk/gcc/expr.c:10491
> #7  0x083762f2 in expand_expr_real (exp=0xb7bb4564, target=0x0, 
> tmode=VOIDmode,
> modifier=EXPAND_STACK_PARM, alt_rtl=0x0) at
> ../../../gcc.gnu.org/trunk/gcc/expr.c:7863
> #8  0x083704a6 in expand_expr_real_1 (exp=0xb7b97320, target=0x0,
> tmode=VOIDmode, modifier=EXPAND_STACK_PARM, alt_rtl=0x0) at
> ../../../gcc.gnu.org/trunk/gcc/expr.c:9274
> #9  0x083762f2 in expand_expr_real (exp=0xb7b97320, target=0x0, 
> tmode=VOIDmode,
> modifier=EXPAND_STACK_PARM, alt_rtl=0x0) at
> ../../../gcc.gnu.org/trunk/gcc/expr.c:7863
> #10 0x0826ae1a in expand_expr (exp=0xb7b97320, target=0x0, mode=VOIDmode,
> modifier=EXPAND_STACK_PARM) at ../../../gcc.gnu.org/trunk/gcc/expr.h:444
> #11 0x0826c215 in store_one_arg (arg=0xbfffd130, argblock=0x0, flags=0,
> variable_size=0, reg_parm_stack_space=0) at
> ../../../gcc.gnu.org/trunk/gcc/calls.c:4500
> #12 0x08274d79 in expand_call (exp=0xb7b46640, target=0x0, ignore=1) at
> ../../../gcc.gnu.org/trunk/gcc/calls.c:3040
> #13 0x08375088 in expand_expr_real_1 (exp=0xb7b46640, target=0x0,
> tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at
> ../../../gcc.gnu.org/trunk/gcc/expr.c:10209
> #14 0x0828cb86 in expand_call_stmt (stmt=0xb7fde140) at
> ../../../gcc.gnu.org/trunk/gcc/cfgexpand.c:2114
>
>

Re: ADDR_SPACE_CONVERT_EXPR always expanded to 0?

2013-03-08 Thread Richard Biener

On Fri, Mar 8, 2013 at 3:19 PM, Richard Biener
 wrote:
> On Fri, Mar 8, 2013 at 2:57 PM, Georg-Johann Lay  wrote:
>> While implementing PR56263 (Strict address-space checking for AVR), I
>> encountered the problem that pointer casts with address spaces are always
>> expanded as const_int 0.
>>
>> The problem occurs if the attached patch that implements PR56263 and the
>> following code is compiled as
>>
>> $ avr-gcc -Os flash-cast.c -S -mstrict-addr-space-subsets
>>
>>
>> #define PROGMEM __attribute__((__progmem__))
>>
>> #define PSTR(s) \
>>   (__extension__\
>>({   \
>>  static const char __c[] PROGMEM = (s); \
>>  &__c[0];   \
>>}))
>>
>> extern void print (const __memx char*, ...);
>>
>> const __flash char *p;
>>
>> void f (const char *c)
>> {
>> c = (const char*) p;
>>
>> print ((const __flash char*) PSTR ("Hallo flash"));
>> }
>>
>>
>>
>> The corresponding .expand dump reads:
>>
>>
>> f (const char * c)
>> {
>>   static const char __c[12] = "Hallo flash";
>>   const  char * _2;
>>   const  char * _3;
>>
>> ;;   basic block 2, loop depth 0
>> ;;pred:   ENTRY
>>   _2 = (const  char *) (&__c[0]);
>>   _3 = (const  char *) _2;
>>   print (_3); [tail call]
>>   return;
>> ;;succ:   EXIT
>>
>> }
>>
>>
>> but the expression is always emit as (const_int 0).
>>
>>
>> Trying to track this issue, I ended up in build1_stat which enters the 
>> default
>> case for "code" (ADDR_SPACE_CONVERT_EXPR at that time) and returns the
>> following tree:
>>
>>
>> (gdb) p t
>> $62 = (tree) 0xb7bb4578
>> (gdb) pt
>>  > type > type > address-space-1 string-flag QI
>> size 
>> unit size 
>> align 8 symtab 0 alias set -1 canonical type 0xb7bc3a20 
>> precision 8
>> min  max 
>> pointer_to_this >
>> unsigned HI
>> size 
>> unit size 
>> align 8 symtab 0 alias set -1 canonical type 0xb7bc3a80>
>> readonly constant
>> arg 0 > type 
>> public unsigned HI size  unit size
>> 
>> align 8 symtab 0 alias set -1 canonical type 0xb7b4f2a0
>> pointer_to_this >
>> readonly constant
>> arg 0 
>> readonly arg 0 
>> arg 1 
>> flash-cast.c:18:128>
>> flash-cast.c:18:124>>
>>
>> Problem is the arg 1  at the end which 
>> leads
>> to the expansion of 0.
>>
>> The call chain is:
>>
>> #0  build1_stat (code=ADDR_SPACE_CONVERT_EXPR, type=0xb7bc3a80,
>> node=0xb7bb449c) at ../../../gcc.gnu.org/trunk/gcc/tree.c:3848
>> (gdb) bt
>> #0  build1_stat (code=ADDR_SPACE_CONVERT_EXPR, type=0xb7bc3a80,
>> node=0xb7bb449c) at ../../../gcc.gnu.org/trunk/gcc/tree.c:3848
>> #1  0x08286be0 in gimple_assign_rhs_to_tree (stmt=0xb7bc2c30) at
>> ../../../gcc.gnu.org/trunk/gcc/cfgexpand.c:86
>> #2  0x0837047f in expand_expr_real_1 (exp=0xb7b972f8, target=0x0,
>> tmode=VOIDmode, modifier=EXPAND_STACK_PARM, alt_rtl=0x0) at
>> ../../../gcc.gnu.org/trunk/gcc/expr.c:9274
>> #3  0x083762f2 in expand_expr_real (exp=0xb7b972f8, target=0x0, 
>> tmode=VOIDmode,
>> modifier=EXPAND_STACK_PARM, alt_rtl=0x0) at
>> ../../../gcc.gnu.org/trunk/gcc/expr.c:7863
>> #4  0x08376a7e in expand_expr (exp=0xb7b972f8, target=0x0, mode=VOIDmode,
>> modifier=EXPAND_STACK_PARM) at ../../../gcc.gnu.org/trunk/gcc/expr.h:444
>> #5  0x0836ae96 in expand_expr_real_2 (ops=0xbfffca10, target=0x0,
>> tmode=VOIDmode, modifier=EXPAND_STACK_PARM) at
>> ../../../gcc.gnu.org/trunk/gcc/expr.c:8150
>> #6  0x08376234 in expand_expr_real_1 (exp=0xb7bb4564, target=0x0,
>> tmode=VOIDmode, modifier=EXPAND_STACK_PARM, alt_rtl=0x0) at
>> ../../../gcc.gnu.org/trunk/gcc/expr.c:10491
>> #7  0x083762f2 in expand_expr_real (exp=0xb7bb4564, target=0x0, 
>> tmode=VOIDmode,
>> modifier=EXPAND_STACK_PARM, alt_rtl=0x0) at
>> ../../../gcc.gnu.org/trunk/gcc/expr.c:7863
>> #8  0x083704a6 in expand_expr_real_1 (exp=0xb7b97320, target=0x0,
>> tmode=VOIDmode, modifier=EXPAND_STACK_PARM, alt_rtl=0x0) at
>> ../../../gcc.gnu.org/trunk/gcc/expr.c:9274
>> #9  0x083762f2 in expand_expr_real (exp=0xb7b97320, target=0x0, 
>> tmode=VOIDmode,
>> modifier=EXPAND_STACK_PARM, alt_rtl=0x0) at
>> ../../../gcc.gnu.org/trunk/gcc/expr.c:7863
>> #10 0x0826ae1a in expand_expr (exp=0xb7b97320, target=0x0, mode=VOIDmode,
>> modifier=EXPAND_STACK_PARM) at ../../../gcc.gnu.org/trunk/gcc/expr.h:444
>> #11 0x0826c215 in store_one_arg (arg=0xbfffd130, argblock=0x0, flags=0,
>> variable_size=0, reg_parm_stack_space=0) at
>> ../../../gcc.gnu.org/trunk/gcc/calls.c:4500
>> #12 0x08274d79 in expand_call (exp=0xb7b46640, target=0x0, ignore=1) at
>> ../../../gcc.gnu.org/trunk/gcc/calls.c:3040
>> #13 0x08375088 in expand_expr_real_1 (exp=0xb7b46640, target=0x0,
>> tmode=VOIDmod

Re: ADDR_SPACE_CONVERT_EXPR always expanded to 0?

2013-03-08 Thread Georg-Johann Lay

Richard Biener wrote:
> On Fri, Mar 8, 2013 at 3:19 PM, Richard Biener
>  wrote:
>> On Fri, Mar 8, 2013 at 2:57 PM, Georg-Johann Lay wrote:
>>> While implementing PR56263 (Strict address-space checking for AVR), I
>>> encountered the problem that pointer casts with address spaces are always
>>> expanded as const_int 0.
>>>
>>> The problem occurs if the attached patch that implements PR56263 and the
>>> following code is compiled as
>>>
>>> $ avr-gcc -Os flash-cast.c -S -mstrict-addr-space-subsets
>>>
>>>
>>> #define PROGMEM __attribute__((__progmem__))
>>>
>>> #define PSTR(s) \
>>>   (__extension__\
>>>({   \
>>>  static const char __c[] PROGMEM = (s); \
>>>  &__c[0];   \
>>>}))
>>>
>>> extern void print (const __memx char*, ...);
>>>
>>> const __flash char *p;
>>>
>>> void f (const char *c)
>>> {
>>> c = (const char*) p;
>>>
>>> print ((const __flash char*) PSTR ("Hallo flash"));
>>> }
>>>
>>>
>>>
>>> The corresponding .expand dump reads:
>>>
>>>
>>> f (const char * c)
>>> {
>>>   static const char __c[12] = "Hallo flash";
>>>   const  char * _2;
>>>   const  char * _3;
>>>
>>> ;;   basic block 2, loop depth 0
>>> ;;pred:   ENTRY
>>>   _2 = (const  char *) (&__c[0]);
>>>   _3 = (const  char *) _2;
>>>   print (_3); [tail call]
>>>   return;
>>> ;;succ:   EXIT
>>>
>>> }
>>>
>>>
>>> but the expression is always emit as (const_int 0).
>>>
>>>
>>> Trying to track this issue, I ended up in build1_stat which enters the 
>>> default
>>> case for "code" (ADDR_SPACE_CONVERT_EXPR at that time) and returns the
>>> following tree:
>>>
>>>
>>> (gdb) p t
>>> $62 = (tree) 0xb7bb4578
>>> (gdb) pt
>>>  >> type >> type >> address-space-1 string-flag QI
>>> size 
>>> unit size 
>>> align 8 symtab 0 alias set -1 canonical type 0xb7bc3a20 
>>> precision 8
>>> min  max 
>>> pointer_to_this >
>>> unsigned HI
>>> size 
>>> unit size 
>>> align 8 symtab 0 alias set -1 canonical type 0xb7bc3a80>
>>> readonly constant
>>> arg 0 >> type 
>>> public unsigned HI size  unit size
>>> 
>>> align 8 symtab 0 alias set -1 canonical type 0xb7b4f2a0
>>> pointer_to_this >
>>> readonly constant
>>> arg 0 
>>> readonly arg 0 
>>> arg 1 
>>> flash-cast.c:18:128>
>>> flash-cast.c:18:124>>
>>>
>>> Problem is the arg 1  at the end which 
>>> leads
>>> to the expansion of 0.
>>>
>>> The call chain is:
>>>
>>> #0  build1_stat (code=ADDR_SPACE_CONVERT_EXPR, type=0xb7bc3a80,
>>> node=0xb7bb449c) at ../../../gcc.gnu.org/trunk/gcc/tree.c:3848
>>> (gdb) bt
>>> #0  build1_stat (code=ADDR_SPACE_CONVERT_EXPR, type=0xb7bc3a80,
>>> node=0xb7bb449c) at ../../../gcc.gnu.org/trunk/gcc/tree.c:3848
>>> #1  0x08286be0 in gimple_assign_rhs_to_tree (stmt=0xb7bc2c30) at
>>> ../../../gcc.gnu.org/trunk/gcc/cfgexpand.c:86
>>> #2  0x0837047f in expand_expr_real_1 (exp=0xb7b972f8, target=0x0,
>>> tmode=VOIDmode, modifier=EXPAND_STACK_PARM, alt_rtl=0x0) at
>>> ../../../gcc.gnu.org/trunk/gcc/expr.c:9274
>>> #3  0x083762f2 in expand_expr_real (exp=0xb7b972f8, target=0x0, 
>>> tmode=VOIDmode,
>>> modifier=EXPAND_STACK_PARM, alt_rtl=0x0) at
>>> ../../../gcc.gnu.org/trunk/gcc/expr.c:7863
>>> #4  0x08376a7e in expand_expr (exp=0xb7b972f8, target=0x0, mode=VOIDmode,
>>> modifier=EXPAND_STACK_PARM) at ../../../gcc.gnu.org/trunk/gcc/expr.h:444
>>> #5  0x0836ae96 in expand_expr_real_2 (ops=0xbfffca10, target=0x0,
>>> tmode=VOIDmode, modifier=EXPAND_STACK_PARM) at
>>> ../../../gcc.gnu.org/trunk/gcc/expr.c:8150
>>> #6  0x08376234 in expand_expr_real_1 (exp=0xb7bb4564, target=0x0,
>>> tmode=VOIDmode, modifier=EXPAND_STACK_PARM, alt_rtl=0x0) at
>>> ../../../gcc.gnu.org/trunk/gcc/expr.c:10491
>>> #7  0x083762f2 in expand_expr_real (exp=0xb7bb4564, target=0x0, 
>>> tmode=VOIDmode,
>>> modifier=EXPAND_STACK_PARM, alt_rtl=0x0) at
>>> ../../../gcc.gnu.org/trunk/gcc/expr.c:7863
>>> #8  0x083704a6 in expand_expr_real_1 (exp=0xb7b97320, target=0x0,
>>> tmode=VOIDmode, modifier=EXPAND_STACK_PARM, alt_rtl=0x0) at
>>> ../../../gcc.gnu.org/trunk/gcc/expr.c:9274
>>> #9  0x083762f2 in expand_expr_real (exp=0xb7b97320, target=0x0, 
>>> tmode=VOIDmode,
>>> modifier=EXPAND_STACK_PARM, alt_rtl=0x0) at
>>> ../../../gcc.gnu.org/trunk/gcc/expr.c:7863
>>> #10 0x0826ae1a in expand_expr (exp=0xb7b97320, target=0x0, mode=VOIDmode,
>>> modifier=EXPAND_STACK_PARM) at ../../../gcc.gnu.org/trunk/gcc/expr.h:444
>>> #11 0x0826c215 in store_one_arg (arg=0xbfffd130, argblock=0x0, flags=0,
>>> variable_size=0, reg_parm_stack_space=0) at
>>> ../../../gcc.gnu.org/trunk/gcc/calls.c:4500
>>> #12 0x08274d79 in expand_call (exp=0xb7b4

GNU MPFR 3.1.2 Release Candidate

2013-03-08 Thread Vincent Lefevre

The release of GNU MPFR 3.1.2 ("canard à l'orange" patch level 2)
is imminent. Please help to make this release as good as possible
by downloading and testing this release candidate:

http://www.mpfr.org/mpfr-3.1.2/mpfr-3.1.2-rc1.tar.xz
http://www.mpfr.org/mpfr-3.1.2/mpfr-3.1.2-rc1.tar.bz2
http://www.mpfr.org/mpfr-3.1.2/mpfr-3.1.2-rc1.tar.gz
http://www.mpfr.org/mpfr-3.1.2/mpfr-3.1.2-rc1.zip

The MD5's:
3a95e02c8dc2897638eb998da837e63a  mpfr-3.1.2-rc1.tar.bz2
a273dd7752039b8753e09afdd9f0506b  mpfr-3.1.2-rc1.tar.gz
d8019782b2d3007c60fd292856a59104  mpfr-3.1.2-rc1.tar.xz
abb2a2fde5109219ab1bef2d55cb5742  mpfr-3.1.2-rc1.zip

The SHA1's:
38b1cd6f6ab0190d4b991d4bcdb24d112c9f  mpfr-3.1.2-rc1.tar.bz2
9a64b70a3d55c7f8a7faf81cf8f1ad74453dab3b  mpfr-3.1.2-rc1.tar.gz
36d0de647a00527f88c762363e449fcfc6be1375  mpfr-3.1.2-rc1.tar.xz
fc1b9df7a3779c115d1b4eb1aff5cc0f42b5307a  mpfr-3.1.2-rc1.zip

The signatures:
http://www.mpfr.org/mpfr-3.1.2/mpfr-3.1.2-rc1.tar.xz.asc
http://www.mpfr.org/mpfr-3.1.2/mpfr-3.1.2-rc1.tar.bz2.asc
http://www.mpfr.org/mpfr-3.1.2/mpfr-3.1.2-rc1.tar.gz.asc
http://www.mpfr.org/mpfr-3.1.2/mpfr-3.1.2-rc1.zip.asc

Each tarball is signed by Vincent Lefèvre. This can be verified
using the DSA key ID 98C3739D; this key can be retrieved with:

  gpg --recv-keys 98C3739D

or by downloading it from .
The key fingerprint is:

  07F3 DBBE CC1A 3960 5078  094D 980C 1976 98C3 739D

The signatures can be verified with: gpg --verify 
You should check that the key fingerprint matches.

Changes from version 3.1.1 to version 3.1.2:
- Bug fixes (see  or ChangeLog file).
- Updated examples to the MPFR 3.x API.

Note: The official tarballs for MPFR up to 3.1.1 were affected by a
vulnerability for "make distcheck" due to a bug in old GNU Automake
versions: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3386
One of the purposes of this release is to provide tarballs without
this vulnerability.

Please send success and failure reports with "./config.guess" output
to .

If no problems are found, GNU MPFR 3.1.2 should be released
around 2013-03-13.

Regards,

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Question on building a variably modified type at parameter scope

2013-03-08 Thread YU Chenkan

I found this is a bug in my front end because I used the same type for the
parameters in different functions, so the references to the parameter in
the structure messed up.

The thing I want to implement is creating something like this pointers in
C++ of structure type whose variably modified fields depend on other
fields.

So the problem is the reference of this parameter differs from function to
function, and therefore, in the most straightforward solution, I have to
deep copy the whole structure for each function, so it can correctly refer
to the parameter.

However, I want to avoid the deep copy.

So, first, I guess it's not safe to share the same PARM_DECL among
different functions, is it true?

If true, is it possible to refer to the first parameter of whatever
functions in the same way, so I can use the same type built upon that
reference?

And if so, at which stage, I can build such a reference?

Thanks,
Chenkan

>> I believe this should be possible.  I believe that Ada has constructs
>> like this.  I think you will need to use a PLACEHOLDER_EXPR to get the
>> right thing to happen.
>
> In Ada, we indeed have the mechanism in its full generality, i.e.
>
>   struct S { int a; int b[a]; };
>
> will work anywhere, and for this the PLACEHOLDER_EXPR machinery is needed.
>
> But it seems to me that the case at stake is more specific:
>
>   void f (struct S { int a; int b[s.a]; } s) { }
>
> because struct S is defined at parameter scope and s.a is a known object,
> so
> perhaps the use of the (heavy) PLACEHOLDER_EXPR machinery could be
> avoided.
>
> --
> Eric Botcazou
>

Re: Question on building a variably modified type at parameter scope

2013-03-08 Thread Eric Botcazou

> I found this is a bug in my front end because I used the same type for the
> parameters in different functions, so the references to the parameter in
> the structure messed up.
> 
> The thing I want to implement is creating something like this pointers in
> C++ of structure type whose variably modified fields depend on other
> fields.
> 
> So the problem is the reference of this parameter differs from function to
> function, and therefore, in the most straightforward solution, I have to
> deep copy the whole structure for each function, so it can correctly refer
> to the parameter.
> 
> However, I want to avoid the deep copy.
> 
> So, first, I guess it's not safe to share the same PARM_DECL among
> different functions, is it true?

Yes, you cannot share a PARM_DECL.

> If true, is it possible to refer to the first parameter of whatever
> functions in the same way, so I can use the same type built upon that
> reference?

No, I don't think so, at least in GENERIC.  Maybe the C++ front-end has some 
mechanism for "this" though, but I'm no C++ expert.

> And if so, at which stage, I can build such a reference?

If you want to build the type once for all, generically, and instantiate it 
for each function, you'll probably need to go the PLACEHOLDER_EXPR route as 
suggested by Ian.  The idea is to translate S.a in:

  struct S { int a; int b[S.a]; };

as COMPONENT_REF  where PLACEHOLDER_EXPR has the 
type of struct S and FIELD_DECL is a.  This is supported by the middle-end.
Then, in the front-end, each time S.a is used _in the code_, you instantiate 
it by means of SUBSTITUTE_PLACEHOLDER_IN_EXPR.  The middle-end will do the 
same when S.a is implicitly used as the size of the array for example.

See the Ada front-end for practical references (ada/gcc-interface).

-- 
Eric Botcazou

GSOC 2013 ranking rubric for potential projects

2013-03-08 Thread Benjamin De Kosnik


Hey all. 

I'm getting private email about potential project for Google Summer of
Code 2013. This is great, and I'm glad to see interest. 

Although I've enjoyed mentoring people in the past, I will not be
mentoring this year. However, I do plan on reviewing potential
GCC/libstdc++ GSOC applications, and voting to select winning projects.
I'm using a different selection criteria this year, and wish to share
it with potential participants so that they understand how to maximize
their chance for selection.

Some background on GCC/libstdc++ GSOC is here:
http://gcc.gnu.org/wiki/SummerOfCode#Application

I will plus potential projects if I see:

1) past evidence of participation in open source community. This can be
bugzillas, mailing list participation, beta testing in any form, etc.
Be detailed. Be specific. There is never too much info here.

2) proactive stance on assignment paperwork. Getting FSF assignments in
place for studen contributors located outside the USA during the North
American summer months seems to be especially painful. If you want to
work on GCC, and know what you want to do enough to propose something
for GSOC, then start getting the assignment in place immediately.
There is no "too soon." (IMHO "future" assignments are perfect for this
because then participants can work, when it's ready to integrate it can
be done simply without having to know exact file names or directories.)

3) post project proposal on public GNU mailing lists

4) timely discussion and replies of project proposal on GNU mailing
lists

5) a mentor volunteer for the project

6) a project that looks interesting to me or fills a known need

best,
-benjamin

gcc-4.6-20130308 is now available

2013-03-08 Thread gccadmin

Snapshot gcc-4.6-20130308 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20130308/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.6 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_6-branch 
revision 196562

You'll find:

 gcc-4.6-20130308.tar.bz2 Complete GCC

  MD5=60083276da1a35a8445038a29acad698
  SHA1=3f1c6e0c51c2562aee649318b8cc0cd40232cec3

Diffs from 4.6-20130301 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.6
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

g++ member function .at() for arrays

Re: g++ member function .at() for arrays

Re: g++ member function .at() for arrays

Re: g++ member function .at() for arrays

ADDR_SPACE_CONVERT_EXPR always expanded to 0?

Re: ADDR_SPACE_CONVERT_EXPR always expanded to 0?

Re: ADDR_SPACE_CONVERT_EXPR always expanded to 0?

Re: ADDR_SPACE_CONVERT_EXPR always expanded to 0?

GNU MPFR 3.1.2 Release Candidate

Re: Question on building a variably modified type at parameter scope

Re: Question on building a variably modified type at parameter scope

GSOC 2013 ranking rubric for potential projects

gcc-4.6-20130308 is now available

13 matches

Site Navigation

Mail list logo

Footer information