Re: question about GTY macro

2014-05-08 Thread Richard Biener 
On Thu, May 8, 2014 at 7:21 AM, DJ Delorie  wrote:
>
> Given this in tree.h:
>
>   struct int_n_trees_t {
> tree signed_type;
> tree unsigned_type;
>   };

Mark with GTY(())

>   extern struct int_n_trees_t int_n_trees[NUM_INT_N_ENTS];

Likewise.  See how global_trees is marked for example.  But likely
you forgot to mark struct int_n_trees_t to be considered for GC.

Richard.

> And this in tree.c:
>
>   struct int_n_trees_t int_n_trees [NUM_INT_N_ENTS];
>
> What is the right way to mark these for garbage collection?
>
> I can't seem to get int_n_trees[] to show up in any of the gc-related
> generated files.
>
> I need the int_n_trees[] trees to be locked into memory, but I see
> signs that they're being reclaimed instead.

Re: Resurrecting -Wunreachable

2014-05-08 Thread Florian Weimer 

On 05/07/2014 02:43 PM, Richard Biener wrote:


The more challenging issue with early GIMPLE is that loops have already been
lowered to gotos, so adopting the syntax-based Java reachability rules is
impossible.  Oh dear.


Perfect is the enemy of the good (no false positives and no false
negatives).  I don't think you can get all you want starting at GIMPLE.
And the "earlier" you start the more you need to implement a whole compiler.


We already had an unreachable code warning at a later stage in the 
compiler.  Its reporting was so confusing that it head to be removed.  I 
don't think this approach works.



And you have of course to precisely define what you consider
"unreachable" (considering a global const bool debug = true/false; and
if (debug) guarded code - compared to using the preprocessor).


I plan to follow the Java rules, with necessary adjustments due to 
language differences:




They are based on syntax (except for the infinite loop case), so they 
are much more predictable from a developer perspective.


There are other warnings which benefit greatly from information 
collected during optimization, but unreachable code doesn't.


--
Florian Weimer / Red Hat Product Security Team

Re: Resurrecting -Wunreachable

2014-05-08 Thread Richard Biener 
On Thu, May 8, 2014 at 10:21 AM, Florian Weimer  wrote:
> On 05/07/2014 02:43 PM, Richard Biener wrote:
>
>>> The more challenging issue with early GIMPLE is that loops have already
>>> been
>>> lowered to gotos, so adopting the syntax-based Java reachability rules is
>>> impossible.  Oh dear.
>>
>>
>> Perfect is the enemy of the good (no false positives and no false
>> negatives).  I don't think you can get all you want starting at GIMPLE.
>> And the "earlier" you start the more you need to implement a whole
>> compiler.
>
>
> We already had an unreachable code warning at a later stage in the compiler.
> Its reporting was so confusing that it head to be removed.  I don't think
> this approach works.
>
>
>> And you have of course to precisely define what you consider
>> "unreachable" (considering a global const bool debug = true/false; and
>> if (debug) guarded code - compared to using the preprocessor).
>
>
> I plan to follow the Java rules, with necessary adjustments due to language
> differences:
>
> 
>
> They are based on syntax (except for the infinite loop case), so they are
> much more predictable from a developer perspective.
>
> There are other warnings which benefit greatly from information collected
> during optimization, but unreachable code doesn't.

Then I suggest to implement this warning in the frontends - as surely
you'll have differently modified "Java rules" for different frontends.
At the time a frontend calls cgraph_finalize_function () its AST is
supposed to be in GENERIC (+ FE extensions to GENERIC) form
(so for Fortran it's already lowered too much I guess).  So that could
be a (kind-of) common point to implement this for C/C++ at least.

Richard.

>
> --
> Florian Weimer / Red Hat Product Security Team

Re: Change the calling conventions only for the intrinsic functions.

2014-05-08 Thread Georg-Johann Lay 

Am 05/07/2014 04:20 PM, schrieb Umesh Kalappa:

Hi All ,

We are porting GCC  4.8.1 for the customized hardware, where the
current calling convention used as arguments are passed  by stack and
return value by register.

But we do have some intrinsic functions(that are supplied by hardware
folks ) which has the calling convention like both arguments and
return value are passed by stack.

So question is that currently the backend using  usually  conventions
like arguments are  passed by stack ad return value by register ,But
how do we can model that only intrinsic uses the caller stack space
for return value  over registers.


Introduce a new function attribute and attach this attribute to the built-in's 
decl, e.g. in TARGET_INIT_BUILTINS, TARGET_BUILTIN_DECL. Then use the attribute 
to adjust the calling convention in TARGET_FUNCTION_ARG and alike.



Appreciate  any hints or shed some lights  on the same.


Johann

LRA and splitters

2014-05-08 Thread Mike Stump 
So, I was wondering about patterns like:

(define_insn_and_split "*setcc_di_1"
  [(set (match_operand:DI 0 "register_operand" "=q")
(match_operator:DI 1 "ix86_comparison_operator"
  [(reg FLAGS_REG) (const_int 0)]))]
  "TARGET_64BIT && !TARGET_PARTIAL_REG_STALL"
  "#"
  "&& reload_completed"
  [(set (match_dup 2) (match_dup 1))
   (set (match_dup 0) (zero_extend:DI (match_dup 2)))]
{
  PUT_MODE (operands[1], QImode);   

  operands[2] = gen_lowpart (QImode, operands[0]);  

})

on the x86.  X86 is an always LRA port, and with LRA it seems reload_completed 
is always 0, and so that disables these splitters?

I have a port that I am converting, and noticed this and am wondering what the 
path forward is for me.

Re: LRA and splitters

2014-05-08 Thread Jakub Jelinek 
On Thu, May 08, 2014 at 10:15:06AM -0700, Mike Stump wrote:
> So, I was wondering about patterns like:
> 
> (define_insn_and_split "*setcc_di_1"
>   [(set (match_operand:DI 0 "register_operand" "=q")
> (match_operator:DI 1 "ix86_comparison_operator"
>   [(reg FLAGS_REG) (const_int 0)]))]
>   "TARGET_64BIT && !TARGET_PARTIAL_REG_STALL"
>   "#"
>   "&& reload_completed"
>   [(set (match_dup 2) (match_dup 1))
>(set (match_dup 0) (zero_extend:DI (match_dup 2)))]
> {
>   PUT_MODE (operands[1], QImode); 
>   
>   operands[2] = gen_lowpart (QImode, operands[0]);
>   
> })
> 
> on the x86.  X86 is an always LRA port, and with LRA it seems 
> reload_completed is always 0, and so that disables these splitters?

No.  reload_completed flag is set after reload or LRA has completed, see
lra.c.  It is only reload_in_progress flag that is never true for LRA, where
it has lra_in_progress instead.

Jakub

gcc-4.8-20140508 is now available

2014-05-08 Thread gccadmin 
Snapshot gcc-4.8-20140508 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20140508/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

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

You'll find:

 gcc-4.8-20140508.tar.bz2 Complete GCC

  MD5=959ab9fe33df88d9d25682a0c31120c8
  SHA1=f9d62e5c221af565cbcf24864741a8f0dc63c10d

Diffs from 4.8-20140501 are available in the diffs/ subdirectory.

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

iq2000-elf: wide-int fallout (was: we are starting the wide int merge)

2014-05-08 Thread Jan-Benedict Glaw 
[...]

Just found this for iq2000:

g++ -c   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -fno-exceptions 
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings 
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic 
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common  
-DHAVE_CONFIG_H -I. -I. -I/home/jbglaw/repos/gcc/gcc 
-I/home/jbglaw/repos/gcc/gcc/. -I/home/jbglaw/repos/gcc/gcc/../include 
-I/home/jbglaw/repos/gcc/gcc/../libcpp/include -I/opt/cfarm/gmp-latest/include 
-I/opt/cfarm/mpfr-latest/include -I/opt/cfarm/mpc-latest/include  
-I/home/jbglaw/repos/gcc/gcc/../libdecnumber 
-I/home/jbglaw/repos/gcc/gcc/../libdecnumber/dpd -I../libdecnumber 
-I/home/jbglaw/repos/gcc/gcc/../libbacktrace-o wide-int.o -MT wide-int.o 
-MMD -MP -MF ./.deps/wide-int.TPo /home/jbglaw/repos/gcc/gcc/wide-int.cc
/home/jbglaw/repos/gcc/gcc/wide-int.cc:37:56: error: unable to emulate 'TI'
 typedef unsigned int UTItype __attribute__ ((mode (TI)));
^
make[1]: *** [wide-int.o] Error 1



See build 222669 
(http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=222669)
for more details.

MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
Signature of: 17:44 <@uschebit> Evangelist ist doch ein Vertriebler
the second  :   für unverkäufliche Produkte, oder? (#korsett, 20120821)


signature.asc
Description: Digital signature

Re: iq2000-elf: wide-int fallout (was: we are starting the wide int merge)

2014-05-08 Thread Oleg Endo 
On Fri, 2014-05-09 at 00:48 +0200, Jan-Benedict Glaw wrote:
> [...]
> 
> Just found this for iq2000:
> 
> g++ -c   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -fno-exceptions 
> -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing 
> -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual 
> -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings 
> -fno-common  -DHAVE_CONFIG_H -I. -I. -I/home/jbglaw/repos/gcc/gcc 
> -I/home/jbglaw/repos/gcc/gcc/. -I/home/jbglaw/repos/gcc/gcc/../include 
> -I/home/jbglaw/repos/gcc/gcc/../libcpp/include 
> -I/opt/cfarm/gmp-latest/include -I/opt/cfarm/mpfr-latest/include 
> -I/opt/cfarm/mpc-latest/include  -I/home/jbglaw/repos/gcc/gcc/../libdecnumber 
> -I/home/jbglaw/repos/gcc/gcc/../libdecnumber/dpd -I../libdecnumber 
> -I/home/jbglaw/repos/gcc/gcc/../libbacktrace-o wide-int.o -MT wide-int.o 
> -MMD -MP -MF ./.deps/wide-int.TPo /home/jbglaw/repos/gcc/gcc/wide-int.cc
> /home/jbglaw/repos/gcc/gcc/wide-int.cc:37:56: error: unable to emulate 'TI'
>  typedef unsigned int UTItype __attribute__ ((mode (TI)));
> ^
> make[1]: *** [wide-int.o] Error 1

I also just ran into that.  Seems to be a host issue.  This one seems to
fix it: http://gcc.gnu.org/ml/gcc-patches/2014-05/msg00527.html

Another wide-int merge fallout I ran into:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61120

Cheers,
Oleg

UTItype fallout (was: wide-int fallout)

2014-05-08 Thread Jan-Benedict Glaw 
On Fri, 2014-05-09 00:48:39 +0200, Jan-Benedict Glaw  wrote:
> Just found this for iq2000:
> 
> g++ -c   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -fno-exceptions 
> -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing 
> -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual 
> -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings 
> -fno-common  -DHAVE_CONFIG_H -I. -I. -I/home/jbglaw/repos/gcc/gcc 
> -I/home/jbglaw/repos/gcc/gcc/. -I/home/jbglaw/repos/gcc/gcc/../include 
> -I/home/jbglaw/repos/gcc/gcc/../libcpp/include 
> -I/opt/cfarm/gmp-latest/include -I/opt/cfarm/mpfr-latest/include 
> -I/opt/cfarm/mpc-latest/include  -I/home/jbglaw/repos/gcc/gcc/../libdecnumber 
> -I/home/jbglaw/repos/gcc/gcc/../libdecnumber/dpd -I../libdecnumber 
> -I/home/jbglaw/repos/gcc/gcc/../libbacktrace-o wide-int.o -MT wide-int.o 
> -MMD -MP -MF ./.deps/wide-int.TPo /home/jbglaw/repos/gcc/gcc/wide-int.cc
> /home/jbglaw/repos/gcc/gcc/wide-int.cc:37:56: error: unable to emulate 'TI'
>  typedef unsigned int UTItype __attribute__ ((mode (TI)));
> ^
> make[1]: *** [wide-int.o] Error 1
> 
> See build 222669 
> (http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=222669)
> for more details.

That isn't actually fallout from the wide-int merge, but of later
added code.

Other targets affected are moxie-elf, aarch64_be-elf, alpha-linux,
cr16-elf, ppc-linux, hppa-linux, arc-elf, younameit.

MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
Signature of:  Alles sollte so einfach wie möglich gemacht sein.
the second  :  Aber nicht einfacher.  (Einstein)


signature.asc
Description: Digital signature