Re: future versions

2015-03-21 Thread Jack Howarth 
On Sat, Mar 21, 2015 at 1:45 AM, Markus Trippelsdorf
 wrote:
> On 2015.03.20 at 20:08 -0400, Jack Howarth wrote:
>> What was the final decision concerning future versioning of FSF
>> gcc post-5.0? In particular, I am confused about the designation of
>> maintenance releases of 5.0. Will the next maintenance release be 5.1
>> or 5.0.1? I assume if it is 5.1, then after branching for release of
>> 5.0, trunk will become 6.0, no?
>
> http://gcc.gnu.org/develop.html#num_scheme

So according to that webpage, trunk becomes 6.0 and the first
maintenance release of 5.0 becomes 5.1 (with 5.0.1 being the
pre-release state of the gcc-5_0-branch prior to the actual 5.1
maintenance release). What is confusing me is all of these references
in the mailing list to postponing bug fixes until 5.2 instead of 5.1
(https://gcc.gnu.org/ml/gcc-patches/2015-03/msg01129.html for
example). What is that all about?

>
> --
> Markus

Re: future versions

2015-03-21 Thread Markus Trippelsdorf 
On 2015.03.21 at 12:11 -0400, Jack Howarth wrote:
> On Sat, Mar 21, 2015 at 1:45 AM, Markus Trippelsdorf
>  wrote:
> > On 2015.03.20 at 20:08 -0400, Jack Howarth wrote:
> >> What was the final decision concerning future versioning of FSF
> >> gcc post-5.0? In particular, I am confused about the designation of
> >> maintenance releases of 5.0. Will the next maintenance release be 5.1
> >> or 5.0.1? I assume if it is 5.1, then after branching for release of
> >> 5.0, trunk will become 6.0, no?
> >
> > http://gcc.gnu.org/develop.html#num_scheme
> 
> So according to that webpage, trunk becomes 6.0 and the first
> maintenance release of 5.0 becomes 5.1 (with 5.0.1 being the
> pre-release state of the gcc-5_0-branch prior to the actual 5.1
> maintenance release). What is confusing me is all of these references
> in the mailing list to postponing bug fixes until 5.2 instead of 5.1
> (https://gcc.gnu.org/ml/gcc-patches/2015-03/msg01129.html for
> example). What is that all about?

The first release of gcc-5 will be 5.1.0. There will be no 5.0.0
release...

-- 
Markus

Re: How to implement '@' GDB-like operator for libcc1

2015-03-21 Thread Jan Kratochvil 
On Mon, 16 Mar 2015 15:43:21 +0100, Tom Tromey wrote:
> It seems like there should be some kind of reference to &op0, that is,
> lowering ATSIGN_EXPR to *(typeof(OP0)[OP1]*)(&OP0).

OK, I got it now.  I was using GDB-like 'struct type *' where 'struct value *'
should have been as in GCC both are 'tree'.

After fixing that it started working:

https://github.com/jankratochvil/gcc/commit/abe7d19e06d4daed79720cd1465a1f87763d2095

ret = copy_node (op0);
TREE_TYPE (ret) = build_array_type_nelts (TREE_TYPE (op0), tree_to_uhwi 
(op1));


> Also, I this has to consider the case where OP1 is not a constant.

I find that already checked in gcc/c/c-typeck.c .


Thanks,
Jan

Re: [gsoc2015] Is Gimple FE eligible for gsoc this year?

2015-03-21 Thread xue yinsong 
I add the following code in parser.c to replace htab:

…
struct gimple_symtab_hasher : ggc_cache_hasher
{
  /* Return the hash value of the declaration name of a gimple_symtab_entry_def
  object pointed by ENTRY.  */
  static hashval_t hash(struct gimple_symtab_entry_def *base){return 
IDENTIFIER_HASH_VALUE(base->id);}
  /* Returns non-zero if ENTRY1 and ENTRY2 point to gimple_symtab_entry_def
  objects corresponding to the same declaration.  */
  static bool equal (const struct gimple_symtab_entry_def *base1, const struct 
gimple_symtab_entry_def *base2){return base1->id == base2->id;}
  static void 
  handle_cache_entry(struct gimple_symtab_entry_def *&m)
  {
extern void gt_ggc_mx (struct gimple_symtab_entry_def *&);
if (m == HTAB_EMPTY_ENTRY || m == HTAB_DELETED_ENTRY)
  return;
else if (ggc_marked_p (m->id))
  gt_ggc_mx (m);
else
  m = static_cast (HTAB_DELETED_ENTRY);
  }
};

/* Gimple symbol table.  */
static GTY((cache)) hash_table *gimple_symtab;
…

But I got undefined symbols when compiling it:
…
Undefined symbols for architecture x86_64:
  "gt_ggc_mx(gimple_symtab_entry_def*&)", referenced from:
  gt_clear_caches_gt_gimple_parser_h() in parser.o
  "gt_pch_nx(gimple_symtab_entry_def*&)", referenced from:
  gt_pch_nx_hash_table_gimple_symtab_hasher_(void*) in parser.o
  "_c_global_trees", referenced from:
  gimple_main() in parser.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
make[3]: *** [gimple1] Error 1
make[2]: *** [all-stage2-gcc] Error 2
make[1]: *** [stage2-bubble] Error 2
make: *** [all] Error 2

Could someone tell me how to fix this?



—
Regards,
Yinsong
>