Re: GCC 4.8.1 MIPS

2013-07-21 Thread Hendrik Greving 
The enum opt_code in gcc/options.h looks like this;

enum opt_code
{
  N_OPTS,
  OPT_SPECIAL_unknown,
  OPT_SPECIAL_ignore,
  OPT_SPECIAL_program_name,
  OPT_SPECIAL_input_file
};

I have a feeling I am missing something. Any idea what?

Thanks,
Regards,
Hendrik Greving

On Sat, Jul 20, 2013 at 6:28 PM, Hendrik Greving
 wrote:
> I tried to build a cross-compiler for mips target, I wanted to see how
> mips handles certain target macros (I basically want to look at
> mips.ii). In any case, when compiling, I am getting this error:
>
> ../../gcc-4.8.1/gcc/lto-wrapper.c: In function ‘void
> merge_and_complain(cl_decoded_option**, unsigned int*,
> cl_decoded_option*, unsigned int)’:
> ../../gcc-4.8.1/gcc/lto-wrapper.c:407:7: error: ‘OPT_fPIC’ was not
> declared in this scope
> ../../gcc-4.8.1/gcc/lto-wrapper.c:408:7: error: ‘OPT_fpic’ was not
> declared in this scope
> ../../gcc-4.8.1/gcc/lto-wrapper.c:409:7: error: ‘OPT_fpie’ was not
> declared in this scope
> ../../gcc-4.8.1/gcc/lto-wrapper.c:410:7: error: ‘OPT_fcommon’ was not
> declared in this scope
> [..]
> and more...
>
> Do I need newer binutils? i386 target compiles fine.
>
> Regards,
> Hendrik Greving

Re: note generating in case of type confliction

2013-07-21 Thread Klin Iop 
Yes, you're right.
The actual message is "expected %qT but argument is of type %qT" (found in c- 
typeck.c line: 4039), where tree-types are compared (tree type with tree 
rhstype). 
Sorry for the mistake and thank you. 






Von: Jonathan Wakely 
An: Klin Iop  
CC: "gcc@gcc.gnu.org"  
Gesendet: 20:00 Donnerstag, 18.Juli 2013
Betreff: Re: note generating in case of type confliction


On 18 July 2013 20:32, Klin Iop wrote:
> Hello,
>
> I'm mostly new to gcc, so I don't really have a real idea how notes are 
> generated. More exactly I would like to know, how types are compared during 
> compilation, and what makes the compiler decide to throw a message in case 
> they aren't equal. There is this message "note: expected `type` but argument 
> is type of `type`".

Are you sure that's what it says?
In the current sources search for "but argument" in
gcc/c-family/c-format.c, in the GCC 4.4 sources search in
gcc/c-typeck.c

gcc-4.9-20130721 is now available

2013-07-21 Thread gccadmin 
Snapshot gcc-4.9-20130721 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20130721/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.9 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 201112

You'll find:

 gcc-4.9-20130721.tar.bz2 Complete GCC

  MD5=bdd43b6aba4897440926c4f050d7db36
  SHA1=bf17c26cc927d12c2d895c343241c5d32dd711b3

Diffs from 4.9-20130714 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.9
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.

Re: RFC: Gimple combine/folding interface

2013-07-21 Thread Andrew Pinski 
On Fri, Jul 19, 2013 at 5:09 PM, Andrew Pinski  wrote:
> I was creating a new gimple/folding interface and wanted some opinions
> on the interface.
>
> typedef double_int (*nonzerobits_t)(tree var);
> typedef tree (*valueizer_t)(tree var);
>
> class gimple_combine
> {
> public:
>   gimple_combine(nonzerobits_t a, valueizer_t b) : nonzerobitsf(a),
> valueizerv(b), allow_full_reassiocation(false) {}
>   gimple_combine() : nonzerobitsf(NULL), valueizerv(NULL),
> allow_full_reassiocation(false) {}
>   gimple_combine(bool reas) : nonzerobitsf(NULL), valueizerv(NULL),
> allow_full_reassiocation(reas) {}
>   tree build2 (location_t, enum tree_code, tree, tree, tree);
>   tree build1 (location_t, enum tree_code, tree, tree);
>   tree build3 (location_t, enum tree_code, tree, tree, tree, tree);
>   tree combine (gimple);
> private:
>   nonzerobits_t nonzerobitsf;
>   valueizer_t valueizerv;
>   bool allow_full_reassiocation;
>   tree binary (location_t, enum tree_code, tree, tree, tree);
>   tree unary (location_t, enum tree_code, tree, tree);
>   tree ternary (location_t, enum tree_code, tree, tree, tree, tree);
> };
>
> bool replace_rhs_after_ssa_combine (gimple_stmt_iterator *, tree);
>
> This is what I have so far and wonder if there is anything else I
> should include.
>
> This will be used to replace the folding code in fold-const.c and 
> gimple-fold.c.

I placed what I decided in a branch in git:

http://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/gimple-ssa-combine.h;h=3d597291c1756cdf6e3318fd190ac70911ceb702;hb=d32468a31ab5e50fabab3a04303f6892ad890fd5

Note I won't have time to work on this again until the middle of August or so.

The status of the current patch is that it is able to build libgcc but
there are some addition ICEs due to checking to make sure all of the
forwprop optimizations are pushed over to gimple_combine (since I
started this work on an older code base).

Thanks,
Andrew Pinski

>
> Thanks,
> Andrew Pinski