Re: GCC + libJIT instead of LLVM

[Kirill Kononenko]

Hello


After many considerations, I want to let everyone know about a release
of my work done in a package:



0.1.2.5 + / 0.1.2 1/2 version release (code name: "libJIT-ON-TESTOSTERONE")

* main branch + libJIT-linear-scan-register-allocator
* Add optimization levels for IA-32 from 0 to 4
* Add a new specialized ABI called INTERNAL
* Add brand new optimized object code generator (level 1, 2, 3, 4 of
optimization)
* Various low-level machine dependent optimizations and tricks
* Aggressive optimization of division by integer constants as
  by Torbjorn Granlund and Peter L. Montgomery in "Division By
Invariant Integers using Multiplication"
* Add primitive code generators for MMX/Streaming SIMD
Extensions/SSE/SSE2/SSE3 and others
* Use SIMD SSE/SSE2/SSE3 for floating point values and operations
(level 1, 2, 3, 4 of optimization)
* Data-flow and control-flow based analysis (level 1, 2, 3, 4 of
optimization)
* Fast liveness analysis (level 2 of optimization)
* Dead-code elimination (level 4 of optimization)
* Full liveness analysis (level 3, 4 of optimization)
* Linear scan register allocator algorithm (level 2)
* Bin packing register allocator algorithm (level 3, 4)
* Tested on DotGNU Portable.NET Common Language Runtime
  / a Microsoft Common Intermediate Language Virtual Machine

(a special "unofficial" research release version


Download is at:

http://libjit-linear-scan-register-allocator.googlecode.com/files/libjit-0.1.2.5%2B.tar.gz



This work gives a lot of improvement and beats Mono in all benchmarks.

I want to also let know that this is a research project and there is
no target to compete with Novell, or Apple. Simply because it is not
possible. But I am rather looking for cooperation for benefits of all
sides. I will be honored if this work can be a base for a cooperation
with Mono for example.


Thanks,
Kirill


2009/4/3 Diego Novillo :
> On Fri, Apr 3, 2009 at 10:54, Kirill Kononenko
>  wrote:
>
>> What I want to identify is how both a VM engine(ILDJIT,
>> .NET for example, Mono, Portable.NET), gcc and libJIT could be
>> extended with minimal changes to both, for best user experience for
>> example, is it speed performance, benchmark, code size, or power
>> consumption.
>
> You still need to do the steps Ian outlined in his message.  For GCC
> maintainers to accept changes (minimal as they may be), you have to
> justify those changes, propose a patch and submit for review.
>
> Whether the patch is approved or not will depend on whether you
> convinced the GCC maintainers that the feature is useful and that it
> complies with http://gcc.gnu.org/contribute.html.
>
> It seems like you are still early in your design cycle.  You still
> need to complete steps 1-3 in Ian's list.
>
>
> Diego.
>

Bootstrap on powerpc-linux trunk broken between r145531 and r145540 internal compiler error: in fold_convert, at fold-const.c:2506

[Laurent GUERBY]

Hi,

The compile farm powerpc-linux tester (gcc53) now fails to bootstrap,
from the ChangeLog and the message I would guess this was caused by PR
8781/37892 patch.

Sincerely,

Laurent

Updated to revision 145531.
=> OK

Updating SVN tree
Ugcc/tree-ssa-sccvn.c
Ugcc/tree-ssa-sccvn.h
Ugcc/ChangeLog
Agcc/testsuite/gcc.c-torture/execute/pr39501.c
Agcc/testsuite/gcc.c-torture/execute/pr39501.x
Agcc/testsuite/gcc.c-torture/compile/pr39636.c
Agcc/testsuite/gcc.dg/tree-ssa/ssa-pre-25.c
Ugcc/testsuite/ChangeLog
Agcc/testsuite/g++.dg/tree-ssa/pr8781.C
Ugcc/unwind-dw2.c
Ugcc/unwind-dw2.h
Ugcc/tree-ssa-pre.c
Ugcc/tree-ssa-forwprop.c
Ugcc/tree-ssa.c
Ugcc/config/arm/arm.md
Ugcc/tree-ssa-operands.c
Updated to revision 145540.
=> FAIL

/home/guerby/build/./gcc/xgcc -B/home/guerby/build/./gcc/ 
-B/n/53/guerby/install-trunk/powerpc-unknown-linux-gnu/bin/ 
-B/n/53/guerby/install-trunk/powerpc-unknown-linux-gnu/lib/ -isystem 
/n/53/guerby/instal\
l-trunk/powerpc-unknown-linux-gnu/include -isystem 
/n/53/guerby/install-trunk/powerpc-unknown-linux-gnu/sys-include -g -O2 
-msoft-float -fPIC -mstrict-align -O2  -g -O2 -DIN_GCC   -W -Wall 
-Wwrite-strings -\
Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition  
-isystem ./include  -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 
-D__GCC_FLOAT_NOT_NEEDED  -mlong-double-128 -I. -I. -I../../.././gcc\
 -I../../../../trunk/libgcc -I../../../../trunk/libgcc/. 
-I../../../../trunk/libgcc/../gcc -I../../../../trunk/libgcc/../include 
-I../../../../trunk/libgcc/../libdecnumber/dpd -I../../../../trunk/libgcc/../\
libdecnumber -DHAVE_CC_TLS -o decQuad.o -MT decQuad.o -MD -MP -MF decQuad.dep 
-c ../../../../trunk/libgcc/../libdecnumber/decQuad.c
In file included from ../../../../trunk/libgcc/../libdecnumber/decQuad.c:145:
../../../../trunk/libgcc/../libdecnumber/decBasic.c: In function 
'decFiniteMultiply':
../../../../trunk/libgcc/../libdecnumber/decBasic.c:723: internal compiler 
error: in fold_convert, at fold-const.c:2506
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[5]: *** [decQuad.o] Error 1
make[5]: Leaving directory 
`/home/guerby/build/powerpc-unknown-linux-gnu/nof/libgcc'
make[4]: *** [multi-do] Error 1
make[4]: Leaving directory `/home/guerby/build/powerpc-unknown-linux-gnu/libgcc'
make[3]: *** [all-multi] Error 2
make[3]: Leaving directory `/home/guerby/build/powerpc-unknown-linux-gnu/libgcc'
make[2]: *** [all-stage1-target-libgcc] Error 2
make[2]: Leaving directory `/home/guerby/build'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/home/guerby/build'
make: *** [bootstrap] Error 2

svn diff -r 145531:145540
...
+2009-04-04  Richard Guenther  
+
+   * tree-ssa.c (verify_ssa): With -O0 we do not need VOPs.
+   * tree-ssa-operands.c (append_vdef): Do not append VOPs at -O0.
+   (append_vuse): Likewise.
+
+2009-04-04  Jakub Jelinek  
+
+   * unwind-dw2.h (_Unwind_FrameState): Add REG_UNDEFINED enum value.
+   * unwind-dw2.c (execute_cfa_program): Set how to REG_UNDEFINED
+   instead of REG_UNSAVED for DW_CFA_undefined.
+   (uw_update_context_1): Handle REG_UNDEFINED the same as REG_UNSAVED.
+   (uw_update_context): If RA column is REG_UNDEFINED, mark it as
+   outermost frame.
+
+2009-04-04  Richard Earnshaw  
+
+   PR target/39501
+   * arm.md (movsfcc): Disable if not TARGET_HARD_FLOAT.
+   * testsuite/gcc.c-torture/execute/pr39501.c: New file.
+   * testsuite/gcc.c-torture/execute/pr39501.x: New file.
+
+2009-04-04  Richard Guenther  
+
+   PR tree-optimization/8781
+   PR tree-optimization/37892
+   * tree-ssa-sccvn.h (vn_reference_fold_indirect): Declare.
+   * tree-ssa-sccvn.c (vn_reference_fold_indirect): New function.
+   (valueize_refs): Call it for *& valueizations.
+   (shared_reference_ops_from_ref): Rename to ...
+   (valueize_shared_reference_ops_from_ref): ... this and valueize.
+   (shared_reference_ops_from_call): Rename to ...
+   (valueize_shared_reference_ops_from_call): ... this and valueize.
+   (vn_reference_lookup): Update.
+   (visit_reference_op_call): Likewise.
+   * tree-ssa-pre.c (phi_translate_1): Fold *&.
+   (eliminate): Value-replace the call address in call statements.
+
+2009-04-04  Richard Guenther  
+
+   PR tree-optimization/39636
+   * tree-ssa-forwprop.c
+   (forward_propagate_addr_into_variable_array_index): Check for
+   GIMPLE_ASSIGN before accessing the rhs code.
+

Re: fwprop and CSE const anchor opt

[Richard Sandiford]

Adam Nemet  writes:
> Richard Sandiford writes:
>> Adam Nemet  writes:
>> > In order for my CSE const anchor patch to work I needed to drastically 
>> > lower
>> > the cost of immediate addition in the MIPS backend.  This was acceptable 
>> > as a
>> > proof of concept but not in general of course.
>> >
>> > The problem is with "single-insn"/simple constants.  We would also like 
>> > these
>> > to use const anchors in the hope that the resulting expression would get
>> > propagated into MEM expressions.  I was hoping that fwprop would do this
>> > propagation for me.  However, since a single-insn constant load is cheaper
>> > than an immediate addition (make sense), fwprop is free to propagate either
>> > (1) into (2) or (2) into (3) here:
>> >
>> >   (1) a <- C
>> >   |
>> >   +--> (2) b <- a + D
>> >   ||
>> >   |+--> (3) mem(b)
>> >   |
>> >   +--> (4) use(a)
>> >
>> > Which one it does depends on which one it tries first.  Right now we go in
>> > insn order so we'd do (1) to (2) preventing to do (2) to (3) later.
>> 
>> Probably a dumb question, sorry, but is this only a problem for MIPS when
>> C + D is in the range [0x8000, 0x]?  Or is the (1)->(2) substitution
>> somehow succeeding in other cases?
>
> Right and no.  I wasn't very precise saying single-insn constants; I should
> have said single-insn constants produced with ORI using the zero register.
> (The testcase in PR/33699 is really good :).)

OK.  I suppose addresses in that range aren't really going to be used
in practice, but I can see it's good to be thorough if we can be.

> * Synthesizing multi-insns constants from const anchors make sense regardless
> whether the constant is used as an address so I am adjusting the cost system
> to make those stick independent of the context.  I still need to benchmark
> this.

Out of interest, what sort of changes did you need to make?  Do you care
about the cases where rtx_costs is applied to a pattern that won't later
be checked by recog (such as the calls from the expander)?  Or do you
just care about the cases where rtx_costs is used to check whether a
validate_change would be profitable?

(I was going to launch into a bit of background about the current MIPS
constant costs, but I thought I'd better ask first, in case it ends up
deflecting the thread too much.)

Richard

Re: GCC + libJIT instead of LLVM

[Kirill Kononenko]

About the benchmarks you know what I mean I guess. That they don't
prove anything, no matter how hard other people want to prove the
inverse. Concrete figures will be in incoming research papers I am
working right now. So just don't start right now with saying give us
figures :-)


Thanks,
Kirill

2009/4/5 Kirill Kononenko :
>
>
> After many considerations, I want to let everyone know about a release
> of my work done in a package:
>
>
>
> 0.1.2.5 + / 0.1.2 1/2 version release (code name: "libJIT-ON-TESTOSTERONE")
>
>        * main branch + libJIT-linear-scan-register-allocator
>        * Add optimization levels for IA-32 from 0 to 4
>        * Add a new specialized ABI called INTERNAL
>        * Add brand new optimized object code generator (level 1, 2, 3, 4 of
> optimization)
>        * Various low-level machine dependent optimizations and tricks
>        * Aggressive optimization of division by integer constants as
>          by Torbjorn Granlund and Peter L. Montgomery in "Division By
> Invariant Integers using Multiplication"
>        * Add primitive code generators for MMX/Streaming SIMD
> Extensions/SSE/SSE2/SSE3 and others
>        * Use SIMD SSE/SSE2/SSE3 for floating point values and operations
> (level 1, 2, 3, 4 of optimization)
>        * Data-flow and control-flow based analysis (level 1, 2, 3, 4 of
> optimization)
>        * Fast liveness analysis (level 2 of optimization)
>        * Dead-code elimination (level 4 of optimization)
>        * Full liveness analysis (level 3, 4 of optimization)
>        * Linear scan register allocator algorithm (level 2)
>        * Bin packing register allocator algorithm (level 3, 4)
>        * Tested on DotGNU Portable.NET Common Language Runtime
>          / a Microsoft Common Intermediate Language Virtual Machine
>
> (a special "unofficial" research release version
> 
>
> Download is at:
>
> http://libjit-linear-scan-register-allocator.googlecode.com/files/libjit-0.1.2.5%2B.tar.gz
>
>
>
> This work gives a lot of improvement and beats Mono in all benchmarks.
>
> I want to also let know that this is a research project and there is
> no target to compete with Novell, or Apple. Simply because it is not
> possible. But I am rather looking for cooperation for benefits of all
> sides. I will be honored if this work can be a base for a cooperation
> with Mono for example.
>
>
> Thanks,
> Kirill
>
>
> 2009/4/3 Diego Novillo :
>> On Fri, Apr 3, 2009 at 10:54, Kirill Kononenko
>>  wrote:
>>
>>> What I want to identify is how both a VM engine(ILDJIT,
>>> .NET for example, Mono, Portable.NET), gcc and libJIT could be
>>> extended with minimal changes to both, for best user experience for
>>> example, is it speed performance, benchmark, code size, or power
>>> consumption.
>>
>> You still need to do the steps Ian outlined in his message.  For GCC
>> maintainers to accept changes (minimal as they may be), you have to
>> justify those changes, propose a patch and submit for review.
>>
>> Whether the patch is approved or not will depend on whether you
>> convinced the GCC maintainers that the feature is useful and that it
>> complies with http://gcc.gnu.org/contribute.html.
>>
>> It seems like you are still early in your design cycle.  You still
>> need to complete steps 1-3 in Ian's list.
>>
>>
>> Diego.
>>
>

Bootstrap broken on sparc-linux trunk between 145310:145425 because of new genattrtab.c va_arg (p, HOST_WIDE_INT) warning

[Laurent GUERBY]

Hi,

On sparc-linux gcc54 I get at rev 145425:

/home/guerby/build/./prev-gcc/xgcc -B/home/guerby/build/./prev-gcc/ 
-B/n/54/guerby/install-trunk/sparc64-unknown-linux-gnu/bin/ -c  -g -O2 -DIN_GCC 
  -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-p\
rototypes -Wcast-qual -Wold-style-definition -Wc++-compat 
-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros 
-Wno-overlength-strings -Werror -fno-common  -DHAVE_CONFIG_H -DGENERATOR_FI\
LE -I. -Ibuild -I../../trunk/gcc -I../../trunk/gcc/build 
-I../../trunk/gcc/../include -I../../trunk/gcc/../libcpp/include 
-I/opt/cfarm/mpfr-2.3.2/include -I../../trunk/gcc/../libdecnumber 
-I../../trunk/gcc/\
../libdecnumber/dpd -I../libdecnumber-o build/genattrtab.o 
../../trunk/gcc/genattrtab.c
cc1: warnings being treated as errors
../../trunk/gcc/genattrtab.c: In function 'attr_rtx':
../../trunk/gcc/genattrtab.c:478: error: 'va_arg_tmp.68' may be used 
uninitialized in this function
../../trunk/gcc/genattrtab.c:478: note: 'va_arg_tmp.68' was declared here
../../trunk/gcc/genattrtab.c:506: error: 'va_arg_tmp.71' may be used 
uninitialized in this function
../../trunk/gcc/genattrtab.c:506: note: 'va_arg_tmp.71' was declared here
make[3]: *** [build/genattrtab.o] Error 1
make[3]: Leaving directory `/home/guerby/build/gcc'
make[2]: *** [all-stage2-gcc] Error 2
make[2]: Leaving directory `/home/guerby/build'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/home/guerby/build'
make: *** [bootstrap] Error 2

Both warnings are on the same type of code:

HOST_WIDE_INT arg0 = va_arg (p, HOST_WIDE_INT);

va_arg (p, HOST_WIDE_INT)

It was working at rev 145310, lots of change so hard to guess which
one caused the failure.

I'm thinking of changing my auto tester to report a broken bootstrap
(the first time a bootstrap fails), is there a normalized way to
report such failures to gcc-testresults@ or g...@?

http://gcc.gnu.org/wiki/CompileFarm
gcc01 i686  trunk  4h00 (-j 2)
gcc02 i686  4.43h30 (-j 2)
gcc13 x86_64trunk  3h30
gcc15 x86_644.46h30 (-j 2)
gcc40 powerpc64 trunk  6h00
gcc41 ia64  trunk 26h00
gcc50 armv5tel  trunk 37h00 (C only)
gcc52 mipseltrunk 21h00
gcc53 powerpc   trunk  7h30
gcc54 sparc trunk 22h00
gcc61 hppa  trunk 22h00

Laurent

+2009-04-01  Janis Johnson  
+
+   PR c/29027
+   * c-lex.c (interpret_float): Default (no suffix) is double.
+
+2009-04-1  Xinliang David Li  
+
+   * config/i386/i386.c (legitimate_constant_p): Recognize
+   all one vector constant.
+
+2009-04-01 Jan-Benedict Glaw 
+
+   * gcc/config/vax/vax.c: Add #includes to silence warnings.
+   Change #include order to silence two warnings.
+
+2009-04-01 Jan-Benedict Glaw 
+
+   * gcc/config/vax/linux.h (TARGET_DEFAULT): Add the MASK_QMATH flag bit.
+   (ASM_SPEC): Pass -k to the assembler for PIC code.
+
+2009-04-01 Jan-Benedict Glaw 
+
+   * gcc/config.gcc: Add vax-*-linux* to the switch.
+   * gcc/config/vax/linux.h: New file. (TARGET_VERSION,
+   TARGET_OS_CPP_BUILTINS, TARGET_DEFAULT, CPP_SPEC, LINK_SPEC): Define.
+
+2009-04-01 Jan-Benedict Glaw 
+
+   * gcc/config/vax/vax.c (vax_output_int_move, adjacent_operands_p):
+   Use predicate macros instead of GET_CODE() == foo.
+   * gcc/config/vax/vax.md (movsi_2, movstrictqi, and3, ashrsi3,
+   ashlsi3, rotrsi3, ): Likewise.
+
+2009-04-01 Jan-Benedict Glaw 
+
+   * gcc/config/vax/builtins.md (jbbssiqi, jbbssihi, jbbssisi, jbbcciqi,
+   jbbccihi, jbbccisi): Remova trailing whitespace.
+   * gcc/config/vax/constraints.md: Likewise.
+   * gcc/config/vax/elf.h: (ASM_PREFERRED_EH_DATA_FORMAT): Likewise.
+   * gcc/config/vax/openbsd1.h (OBSD_OLD_GAS): Likewise.
+   * gcc/config/vax/predicates.md: Likewise.
+   * gcc/config/vax/vax.c (print_operand_address, vax_output_int_move,
+   vax_expand_addsub_di_operands, adjacent_operands_p): Likewise.
+   * gcc/config/vax/vax.h: Likewise.
+   * gcc/config/vax/vax.md (nonlocal_goto): Likewise.
+
+2009-04-01 Jan-Benedict Glaw 
+
+   * gcc/config/vax/vax.c (vax_float_literal, vax_output_int_move)
+   (indirectable_address_p, adjacent_operands_p): Add spaces around
+   braces.
+   * gcc/config/vax/vax-protos.h (adjacent_operands_p): Likewise.
+
+2009-04-01 Jan-Benedict Glaw 
+
+   * gcc/config/vax/vax.c (legitimate_constant_address_p,
+   legitimate_constant_p, indirectable_address_p, nonindexed_address_p,
+   index_term_p, reg_plus_index_p, legitimate_address_p,
+   vax_mode_dependent_address_p): Update comments to match functions
+   modified by the recent int->bool conversion.
+
+2009-04-01 Jan-Benedict Glaw 
+
+   * gcc/config/vax/builtins.md: Update copyright message.
+   * gcc/config/vax/constraints.md: Likewise.
+   * gcc/config/vax/netbsd-elf.h: Likewise.
+   * gcc/config/vax/predicates.md: Likewise.
+   * gcc/config/vax/vax-protos.h: Likewis

Re: Bootstrap broken on sparc-linux trunk between 145310:145425 because of new genattrtab.c va_arg (p, HOST_WIDE_INT) warning

[H.J. Lu]

On Sun, Apr 5, 2009 at 2:25 AM, Laurent GUERBY  wrote:
> Hi,
>
> On sparc-linux gcc54 I get at rev 145425:
>
> /home/guerby/build/./prev-gcc/xgcc -B/home/guerby/build/./prev-gcc/ 
> -B/n/54/guerby/install-trunk/sparc64-unknown-linux-gnu/bin/ -c  -g -O2 
> -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-p\
> rototypes -Wcast-qual -Wold-style-definition -Wc++-compat 
> -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros 
> -Wno-overlength-strings -Werror -fno-common  -DHAVE_CONFIG_H -DGENERATOR_FI\
> LE -I. -Ibuild -I../../trunk/gcc -I../../trunk/gcc/build 
> -I../../trunk/gcc/../include -I../../trunk/gcc/../libcpp/include 
> -I/opt/cfarm/mpfr-2.3.2/include -I../../trunk/gcc/../libdecnumber 
> -I../../trunk/gcc/\
> ../libdecnumber/dpd -I../libdecnumber    -o build/genattrtab.o 
> ../../trunk/gcc/genattrtab.c
> cc1: warnings being treated as errors
> ../../trunk/gcc/genattrtab.c: In function 'attr_rtx':
> ../../trunk/gcc/genattrtab.c:478: error: 'va_arg_tmp.68' may be used 
> uninitialized in this function
> ../../trunk/gcc/genattrtab.c:478: note: 'va_arg_tmp.68' was declared here
> ../../trunk/gcc/genattrtab.c:506: error: 'va_arg_tmp.71' may be used 
> uninitialized in this function
> ../../trunk/gcc/genattrtab.c:506: note: 'va_arg_tmp.71' was declared here
> make[3]: *** [build/genattrtab.o] Error 1
> make[3]: Leaving directory `/home/guerby/build/gcc'
> make[2]: *** [all-stage2-gcc] Error 2
> make[2]: Leaving directory `/home/guerby/build'
> make[1]: *** [stage2-bubble] Error 2
> make[1]: Leaving directory `/home/guerby/build'
> make: *** [bootstrap] Error 2
>
> Both warnings are on the same type of code:
>
> HOST_WIDE_INT arg0 = va_arg (p, HOST_WIDE_INT);
>
> va_arg (p, HOST_WIDE_INT)
>
> It was working at rev 145310, lots of change so hard to guess which
> one caused the failure.
>
> I'm thinking of changing my auto tester to report a broken bootstrap
> (the first time a bootstrap fails), is there a normalized way to
> report such failures to gcc-testresults@ or g...@?
>

I report it to gcc-regress...@.


H.J.

[fortran] spurious initialized warning with select-case?

[Daniel Franke]

Hi all.

Here's another spurious(?) uninitialized warning. As the full range is 
implied, the question is, if this a fortran or a middle-end problem:

$> cat range.f90
FUNCTION f(n)
  INTEGER, INTENT(in) :: n
  REAL:: f

  SELECT CASE (n)
CASE ( :-1); f = -1.0
CASE (0);f =  0.0
CASE (1: );  f =  1.0
  END SELECT
END FUNCTION

$> gfortran-svn -c -O -Wall -fdump-tree-... range.f90
range.f90: In function 'f':
range.f90:1: warning: '__result_f' may be used uninitialized in this function

After optimization, the dump shows:
:
  switch (*n;) , case -2147483648 ... -1: , case 0: L.3, 
case 1 ... 2147483647: L.4>

Is there any way that 'default' may be reached?
Any pointers how to silence this?

Thanks

Daniel

Annoucing regressions and bootstrap fail? (was: Bootstrap broken on sparc-linux trunk between 145310:145425 because of new genattrtab.c va_arg (p, HOST_WIDE_INT) warning)

[Laurent GUERBY]

On Sun, 2009-04-05 at 08:25 -0700, H.J. Lu wrote:
> On Sun, Apr 5, 2009 at 2:25 AM, Laurent GUERBY  wrote:

> > I'm thinking of changing my auto tester to report a broken bootstrap
> > (the first time a bootstrap fails), is there a normalized way to
> > report such failures to gcc-testresults@ or g...@?

> 
> I report it to gcc-regress...@.

It's documented by http://gcc.gnu.org/lists.html as "read-only":

gcc-regression is a read-only moderate volume list where regression
results for the GCC compilers are posted.

So I thought one couldn't post to it.

If there's consensus that's the right place to send automatic regression
and bootstrap fail reports I'll do that then.

Laurent

Debugging gcc front end

[Guilherme Puglia]

Hi!

or better, hello again! I have posted a question (with my class friend
Eduardo) about 2 or 3 weeks ago. My question was about the grammar
wich gcc C front end use.

Happily, I found the answer of my question. Now, I'm having other
trouble. I wanna insert some "predefined" AST's tree nodes.

To solve my problem I wanna debug the C front end. I was trying to
debug the gcc main function, toplev_main. Unfortunately, I can't
insert a break point in this line.

I saw the site http://gcc.gnu.org/wiki/DebuggingGCC and
http://gcc.gnu.org/ml/gcc/2004-03/msg01195.html

But I don't understand where is "my path". And how to insert the break point.

If somebody can help me, I appreciated that.

Thanks so much!

Guilherme



-- 
--
"Never memorize something that you can look up." - Albert Einstein
--

Re: [fortran] spurious initialized warning with select-case?

[Steve Kargl]

On Sun, Apr 05, 2009 at 05:48:44PM +0200, Daniel Franke wrote:
> Hi all.
> 
> Here's another spurious(?) uninitialized warning. As the full range is 
> implied, the question is, if this a fortran or a middle-end problem:
> 
> $> cat range.f90
> FUNCTION f(n)
>   INTEGER, INTENT(in) :: n
>   REAL:: f
> 
>   SELECT CASE (n)
> CASE ( :-1); f = -1.0
> CASE (0);f =  0.0
> CASE (1: );  f =  1.0
>   END SELECT
> END FUNCTION
> 
> $> gfortran-svn -c -O -Wall -fdump-tree-... range.f90
> range.f90: In function 'f':
> range.f90:1: warning: '__result_f' may be used uninitialized in this function
> 
> After optimization, the dump shows:
> :
>   switch (*n;) , case -2147483648 ... -1: , case 0: L.3, 
> case 1 ... 2147483647: L.4>
> 
> Is there any way that 'default' may be reached?
> Any pointers how to silence this?
> 

I'm not sure if it would work and I have idea where in trans*.c
you need to do this, but if you mark the tree as used with
something like

TREE_USED (__result_f) = 1

the middle-end may be silenced.
-- 
Steve

Re: [fortran] spurious initialized warning with select-case?

[Eric Botcazou]

> I'm not sure if it would work and I have idea where in trans*.c
> you need to do this, but if you mark the tree as used with
> something like
>
> TREE_USED (__result_f) = 1
>
> the middle-end may be silenced.

I think that TREE_NO_WARNING would be more appropriate for this purpose.

-- 
Eric Botcazou

Re: Bootstrap on powerpc-linux trunk broken between r145531 and r145540 internal compiler error: in fold_convert, at fold-const.c:2506

[Richard Guenther]

On Sun, Apr 5, 2009 at 11:01 AM, Laurent GUERBY  wrote:
> Hi,
>
> The compile farm powerpc-linux tester (gcc53) now fails to bootstrap,
> from the ChangeLog and the message I would guess this was caused by PR
> 8781/37892 patch.

Please open a bugzilla if one doesn't already exist and attach preprocessed
source so the bug can be reproduced with a cross compiler.

Thanks,
Richard.

> Sincerely,
>
> Laurent
>
> Updated to revision 145531.
> => OK
>
> Updating SVN tree
> U    gcc/tree-ssa-sccvn.c
> U    gcc/tree-ssa-sccvn.h
> U    gcc/ChangeLog
> A    gcc/testsuite/gcc.c-torture/execute/pr39501.c
> A    gcc/testsuite/gcc.c-torture/execute/pr39501.x
> A    gcc/testsuite/gcc.c-torture/compile/pr39636.c
> A    gcc/testsuite/gcc.dg/tree-ssa/ssa-pre-25.c
> U    gcc/testsuite/ChangeLog
> A    gcc/testsuite/g++.dg/tree-ssa/pr8781.C
> U    gcc/unwind-dw2.c
> U    gcc/unwind-dw2.h
> U    gcc/tree-ssa-pre.c
> U    gcc/tree-ssa-forwprop.c
> U    gcc/tree-ssa.c
> U    gcc/config/arm/arm.md
> U    gcc/tree-ssa-operands.c
> Updated to revision 145540.
> => FAIL
>
> /home/guerby/build/./gcc/xgcc -B/home/guerby/build/./gcc/ 
> -B/n/53/guerby/install-trunk/powerpc-unknown-linux-gnu/bin/ 
> -B/n/53/guerby/install-trunk/powerpc-unknown-linux-gnu/lib/ -isystem 
> /n/53/guerby/instal\
> l-trunk/powerpc-unknown-linux-gnu/include -isystem 
> /n/53/guerby/install-trunk/powerpc-unknown-linux-gnu/sys-include -g -O2 
> -msoft-float -fPIC -mstrict-align -O2  -g -O2 -DIN_GCC   -W -Wall 
> -Wwrite-strings -\
> Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition  
> -isystem ./include  -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 
> -D__GCC_FLOAT_NOT_NEEDED  -mlong-double-128 -I. -I. -I../../.././gcc\
>  -I../../../../trunk/libgcc -I../../../../trunk/libgcc/. 
> -I../../../../trunk/libgcc/../gcc -I../../../../trunk/libgcc/../include 
> -I../../../../trunk/libgcc/../libdecnumber/dpd -I../../../../trunk/libgcc/../\
> libdecnumber -DHAVE_CC_TLS -o decQuad.o -MT decQuad.o -MD -MP -MF decQuad.dep 
> -c ../../../../trunk/libgcc/../libdecnumber/decQuad.c
> In file included from ../../../../trunk/libgcc/../libdecnumber/decQuad.c:145:
> ../../../../trunk/libgcc/../libdecnumber/decBasic.c: In function 
> 'decFiniteMultiply':
> ../../../../trunk/libgcc/../libdecnumber/decBasic.c:723: internal compiler 
> error: in fold_convert, at fold-const.c:2506
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
> make[5]: *** [decQuad.o] Error 1
> make[5]: Leaving directory 
> `/home/guerby/build/powerpc-unknown-linux-gnu/nof/libgcc'
> make[4]: *** [multi-do] Error 1
> make[4]: Leaving directory 
> `/home/guerby/build/powerpc-unknown-linux-gnu/libgcc'
> make[3]: *** [all-multi] Error 2
> make[3]: Leaving directory 
> `/home/guerby/build/powerpc-unknown-linux-gnu/libgcc'
> make[2]: *** [all-stage1-target-libgcc] Error 2
> make[2]: Leaving directory `/home/guerby/build'
> make[1]: *** [stage1-bubble] Error 2
> make[1]: Leaving directory `/home/guerby/build'
> make: *** [bootstrap] Error 2
>
> svn diff -r 145531:145540
> ...
> +2009-04-04  Richard Guenther  
> +
> +       * tree-ssa.c (verify_ssa): With -O0 we do not need VOPs.
> +       * tree-ssa-operands.c (append_vdef): Do not append VOPs at -O0.
> +       (append_vuse): Likewise.
> +
> +2009-04-04  Jakub Jelinek  
> +
> +       * unwind-dw2.h (_Unwind_FrameState): Add REG_UNDEFINED enum value.
> +       * unwind-dw2.c (execute_cfa_program): Set how to REG_UNDEFINED
> +       instead of REG_UNSAVED for DW_CFA_undefined.
> +       (uw_update_context_1): Handle REG_UNDEFINED the same as REG_UNSAVED.
> +       (uw_update_context): If RA column is REG_UNDEFINED, mark it as
> +       outermost frame.
> +
> +2009-04-04  Richard Earnshaw  
> +
> +       PR target/39501
> +       * arm.md (movsfcc): Disable if not TARGET_HARD_FLOAT.
> +       * testsuite/gcc.c-torture/execute/pr39501.c: New file.
> +       * testsuite/gcc.c-torture/execute/pr39501.x: New file.
> +
> +2009-04-04  Richard Guenther  
> +
> +       PR tree-optimization/8781
> +       PR tree-optimization/37892
> +       * tree-ssa-sccvn.h (vn_reference_fold_indirect): Declare.
> +       * tree-ssa-sccvn.c (vn_reference_fold_indirect): New function.
> +       (valueize_refs): Call it for *& valueizations.
> +       (shared_reference_ops_from_ref): Rename to ...
> +       (valueize_shared_reference_ops_from_ref): ... this and valueize.
> +       (shared_reference_ops_from_call): Rename to ...
> +       (valueize_shared_reference_ops_from_call): ... this and valueize.
> +       (vn_reference_lookup): Update.
> +       (visit_reference_op_call): Likewise.
> +       * tree-ssa-pre.c (phi_translate_1): Fold *&.
> +       (eliminate): Value-replace the call address in call statements.
> +
> +2009-04-04  Richard Guenther  
> +
> +       PR tree-optimization/39636
> +       * tree-ssa-forwprop.c
> +       (forward_propagate_addr_into_variable_array_index): Check for

Re: [fortran] spurious initialized warning with select-case?

[Daniel Franke]

On Sunday 05 April 2009 18:56:20 Eric Botcazou wrote:
> > I'm not sure if it would work and I have idea where in trans*.c
> > you need to do this, but if you mark the tree as used with
> > something like
> >
> > TREE_USED (__result_f) = 1
> >
> > the middle-end may be silenced.
>
> I think that TREE_NO_WARNING would be more appropriate for this purpose.

I found that the warning doesn't show up if the testcase is changed:

FUNCTION f(n)
  INTEGER, INTENT(in) :: n
  REAL:: f

  SELECT CASE (n)
CASE ( :-1);   f = 0.0  ! was -1.0
CASE (0);  f = 0.0
CASE (1: );f = 0.0  ! was  1.0
  END SELECT
END FUNCTION

Here, the optimizer removes the select-case completely, so it "knows" that the 
full range is covered:

f (integer(kind=4) & n)
{
:
  return 0.0;
}

Conclusion: the "default" clause in the generic case is wrong?

Daniel

Re: fwprop and CSE const anchor opt

[Adam Nemet]

Richard Sandiford writes:
> Adam Nemet  writes:
> > * Synthesizing multi-insns constants from const anchors make sense 
> > regardless
> > whether the constant is used as an address so I am adjusting the cost system
> > to make those stick independent of the context.  I still need to benchmark
> > this.
> 
> Out of interest, what sort of changes did you need to make?  Do you care
> about the cases where rtx_costs is applied to a pattern that won't later
> be checked by recog (such as the calls from the expander)?  Or do you
> just care about the cases where rtx_costs is used to check whether a
> validate_change would be profitable?

I am glad you asked because I myself was going to ask you some questions in
this area ;).

I think the best way to formulate the profitability question for multi-insn
constants in CSE is this.  We found an expression using a const-anchor that is
equivalent to the REG_EQUAL note on the insn.  We go with the const-anchor
expression if it is cheaper than the REG_EQUAL expression.

Comparing the cost of the actual source in the insn against the const-anchor
expression would ignore the fact that the preceding instructions buiding up
the constants become redundant with the const-anchor expression.

I also have an alternative solution that feels more hackish and gives less
control to the backend but works with the current cost model.  For a
multi-insn constant if the current cost and the cost of the new expression are
equal we prefer the new expression.  This works for MIPS because AFAICT we
always replace a binary expression with another one of the same cost.

The problem with the first approach and I feel you were anticipating this with
your question is that multi-insn constants have a cost of zero in the MIPS
backend currently.  Or with the code from mips_rtx_costs:

case CONST_INT:
[...]
  /* When not optimizing for size, we care more about the cost
 of hot code, and hot code is often in a loop.  If a constant
 operand needs to be forced into a register, we will often be
 able to hoist the constant load out of the loop, so the load
 should not contribute to the cost.  */
  if (!optimize_size
  || mips_immediate_operand_p (outer_code, INTVAL (x)))
{
  *total = 0;
  return true;
}

That is really hard to beat for an immediate add, which is COSTS_N_INSNS (1).

Since you already offered :), can you please explain where the above code is
needed and whether we can refine the picture a little bit.  It definitely
feels like the above cost value is only true in certain contexts.  This might
be a naive comment but maybe somehow limiting the effect to that particular
context would be a good improvement.

Adam

gcc-4.3-20090405 is now available

[gccadmin]

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

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

You'll find:

gcc-4.3-20090405.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.3-20090405.tar.bz2 C front end and core compiler

gcc-ada-4.3-20090405.tar.bz2  Ada front end and runtime

gcc-fortran-4.3-20090405.tar.bz2  Fortran front end and runtime

gcc-g++-4.3-20090405.tar.bz2  C++ front end and runtime

gcc-java-4.3-20090405.tar.bz2 Java front end and runtime

gcc-objc-4.3-20090405.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.3-20090405.tar.bz2The GCC testsuite

Diffs from 4.3-20090329 are available in the diffs/ subdirectory.

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