SUBREG Unrecognizable RTL

[daniel tian]

Hi:

Yeah. You are right. Here is another RTL unrecognized.  It happened
after reload.

(insn 749 156 147 22 (set (reg:HI 5 R5)
(subreg:HI (mem/c:SI (plus:SI (reg/f:SI 15 R15)
(const_int 108 [0x6c])) [19 d0+0 S4 A32]) 0)) -1 (nil))

I traced the lots of functions like: reload, reload_as_needed,
emit_reload_insn, do_input_reload, emit_input_reload_insn in reload1.c
file. But I couldn't get any clue.
the gcc clashed in function: cleanup_subreg_operands. Because you can
see the RTL seems move reg to reg,  actually it load data from memory.
My target didn't accept this kind of RTL. The memory area is the
pseduo register.94. But the reg_renumber[i] < 0 &&
reg_equiv_memory_loc[i], then the pseduo register.94 was replaced with
memory location.

But I 've no idea about why it generates this kind of unrecognized RTL.
I have been hampered this problem for a while.

Any suggestion is appreciated.
Thanks very much.

Re: SUBREG Unrecognizable RTL

[daniel tian]

here are some information from the libgcc2.c.176r.greg. (BTY: the
error happened when cc1 build the libgcc2.c)

Reloads for insn # 147
Reload 0: reload_out (SI) = (reg/v:SI 99 [ __d0 ])
GENERAL_REGS, RELOAD_FOR_OUTPUT (opnum = 0)
reload_out_reg: (reg/v:SI 99 [ __d0 ])
reload_reg_rtx: (reg:SI 5 R5)
Reload 1: reload_in (HI) = (subreg:HI (reg/v:SI 94 [ d0 ]) 0)
GENERAL_REGS, RELOAD_FOR_INPUT (opnum = 1)
reload_in_reg: (subreg:HI (reg/v:SI 94 [ d0 ]) 0)
reload_reg_rtx: (reg:HI 5 R5)

So does it mean when the pseduo register 94 allocated fail, the memory
location will be substitute ?

Re: [LTO] Request for testing: Last merge from trunk before final merge

[Richard Guenther]

On Tue, Sep 29, 2009 at 2:39 PM, Richard Guenther
 wrote:
> On Tue, Sep 29, 2009 at 2:22 PM, Joseph S. Myers
>  wrote:
>> On Tue, 29 Sep 2009, Richard Guenther wrote:
>>
>>> The summary is as follows, extra errors compared to a run
>>> without the merge patch applied:
>>>
>>> i586:
>>>
>>> FAIL: gcc.dg/attr-warn-unused-result.c (internal compiler error)
>>> FAIL: gcc.dg/attr-warn-unused-result.c (test for excess errors)
>>> FAIL: gcc.dg/visibility-7.c  (test for warnings, line 8)
>>> FAIL: gcc.dg/visibility-7.c (test for excess errors)
>>> FAIL: gcc.misc-tests/i386-pf-3dnow-1.c scan-assembler prefetch
>>> FAIL: gcc.misc-tests/i386-pf-3dnow-1.c scan-assembler prefetchw
>>> FAIL: gcc.misc-tests/i386-pf-athlon-1.c scan-assembler prefetchnta
>>> FAIL: gcc.misc-tests/i386-pf-athlon-1.c scan-assembler prefetcht
>>> FAIL: gcc.misc-tests/i386-pf-athlon-1.c scan-assembler prefetchw
>>> FAIL: gcc.misc-tests/i386-pf-sse-1.c scan-assembler prefetchnta
>>> FAIL: gcc.misc-tests/i386-pf-sse-1.c scan-assembler prefetcht0
>>> FAIL: gcc.misc-tests/i386-pf-sse-1.c scan-assembler prefetcht1
>>> FAIL: gcc.misc-tests/i386-pf-sse-1.c scan-assembler prefetcht2
>>> FAIL: 26_numerics/headers/cmath/fabs_inline.cc (test for excess errors)
>>
>> These are non-LTO tests without any LTO options being used, i.e.
>> regressions introduced by the merge.  They will therefore need fixing
>> before the merge can be committed to trunk.  (The
>> attr-warn-unused-result.c and visibility-7.c ones appear on mutliple
>> targets in this list.)
>
> The i386-pf-* tests are somehow executing not only for the
> specified torture options in i386-prefetch.exp but also for
> "", the empty option.  This causes the extra fails.
>
> This is because of the torture-options.exp changes, I have a patch.

All the above have been fixed.  A new round of testing shows

New failures for head-ia64
FAIL: gcc.c-torture/execute/vector-2.c execution,  -O2 -flto
FAIL: gcc.c-torture/execute/vector-2.c execution,  -O2 -fwhopr
FAIL: gcc.dg/torture/builtin-math-7.c  -O2 -flto  (internal compiler error)
FAIL: gcc.dg/torture/builtin-math-7.c  -O2 -flto  (test for excess errors)
FAIL: gcc.dg/torture/builtin-math-7.c  -O2 -fwhopr  (internal compiler error)
FAIL: gcc.dg/torture/builtin-math-7.c  -O2 -fwhopr  (test for excess errors)
FAIL: gfortran.dg/lto/pr40725 f_lto_pr40725_0.o-f_lto_pr40725_1.o
execute -O2 -flto
FAIL: gfortran.dg/lto/pr40725 f_lto_pr40725_0.o-f_lto_pr40725_1.o
execute -O2 -fwhopr
FAIL: g++.dg/lto/20081217-1 cp_lto_20081217-1_0.o-cp_lto_20081217-1_0.o link
FAIL: g++.dg/lto/20081217-2 cp_lto_20081217-2_0.o-cp_lto_20081217-2_0.o link
FAIL: g++.dg/lto/20090106 cp_lto_20090106_0.o-cp_lto_20090106_0.o link
FAIL: g++.dg/lto/20090311 cp_lto_20090311_0.o-cp_lto_20090311_1.o link
FAIL: g++.dg/lto/20090311 cp_lto_20090311_0.o-cp_lto_20090311_1.o
link,  (internal compiler error)

New failures for head-i586
FAIL: gcc.dg/torture/builtin-math-7.c  -O2 -flto  (internal compiler error)
FAIL: gcc.dg/torture/builtin-math-7.c  -O2 -flto  (test for excess errors)
FAIL: gcc.dg/torture/builtin-math-7.c  -O2 -fwhopr  (internal compiler error)
FAIL: gcc.dg/torture/builtin-math-7.c  -O2 -fwhopr  (test for excess errors)
FAIL: gfortran.dg/lto/pr40725 f_lto_pr40725_0.o-f_lto_pr40725_1.o
execute -O2 -flto
FAIL: gfortran.dg/lto/pr40725 f_lto_pr40725_0.o-f_lto_pr40725_1.o
execute -O2 -fwhopr
FAIL: g++.dg/lto/20081109 cp_lto_20081109_0.o-cp_lto_20081109_1.o
execute -O0 -fwhopr
FAIL: g++.dg/lto/20081109 cp_lto_20081109_0.o-cp_lto_20081109_1.o
execute -O2 -fwhopr
FAIL: g++.dg/lto/20090106 cp_lto_20090106_0.o-cp_lto_20090106_0.o link
FAIL: g++.dg/lto/20090311 cp_lto_20090311_0.o-cp_lto_20090311_1.o link
FAIL: g++.dg/lto/20090311 cp_lto_20090311_0.o-cp_lto_20090311_1.o
link,  (internal compiler error)
FAIL: 26_numerics/headers/cmath/fabs_inline.cc (test for excess errors)

New failures for head-ppc64
FAIL: gcc.c-torture/execute/20071030-1.c execution,  -O2 -flto
FAIL: gcc.c-torture/execute/20071030-1.c execution,  -O2 -fwhopr
FAIL: gcc.dg/lto/20090116 c_lto_20090116_0.o-c_lto_20090116_0.o link,
(internal compiler error)
FAIL: gcc.dg/vmx/3a-01.c  -O2 -flto  execution test
FAIL: gcc.dg/vmx/3a-01.c  -O2 -fwhopr  execution test
FAIL: gcc.dg/vmx/3a-01a.c  -O2 -flto  execution test
FAIL: gcc.dg/vmx/3a-01a.c  -O2 -fwhopr  execution test
FAIL: gcc.dg/vmx/3a-01m.c  -O2 -flto  execution test
FAIL: gcc.dg/vmx/3a-01m.c  -O2 -fwhopr  execution test
FAIL: gcc.dg/vmx/3a-03.c  -O2 -flto  (test for excess errors)
FAIL: gcc.dg/vmx/3a-03.c  -O2 -fwhopr  (test for excess errors)
FAIL: gcc.dg/vmx/3a-03m.c  -O2 -flto  (test for excess errors)
FAIL: gcc.dg/vmx/3a-03m.c  -O2 -fwhopr  (test for excess errors)
FAIL: gcc.dg/vmx/3a-04.c  -O2 -flto  (test for excess errors)
FAIL: gcc.dg/vmx/3a-04.c  -O2 -fwhopr  (test for excess errors)
FAIL: gcc.dg/vmx/3a-04m.c  -O2 -flto  (test for excess errors)
FAIL: gcc.dg/vmx/3a-04m.c  -O2 -fwhopr  (test for excess errors)
FAIL: gcc.dg/vmx/3a-05.c  -O2 -flto  (test for excess errors)
FAI

Re: GCC 4.5 Status Report (2009-09-19)

[Richard Guenther]

On Wed, 30 Sep 2009, Gerald Pfeifer wrote:

> On Tue, 29 Sep 2009, Dave Korn wrote:
> > We have ~48 hours left for stage 1 and I can't be confident of getting 
> > it reviewed in the remaining time, so I'd like to make a special 
> > request: can you, as RM, please say that this is OK in principle and 
> > that if I can get v3 approval (it already has all other necessary 
> > approvals) I can check it in during stage 3 before we branch?
> 
> Historically I think we have been flexible for patches that have been
> submitted during stage 1.
> 
> Now, submitting a one liner as your first attempt at a new pass today
> and then claiming the rest are just fixes, would be a stretch :-), but
> for a patch like yours it does not seem unreasonable.

Just to followup once and answer all the multiple requests that have
been (and will be) come up - during stage 3 it is up to the respective
maintainers to decide what is considered a bugfix and whether to allow
changes to go in that were submitted during stage 1.  The release
managers trust the maintainers to make stage 3 a success - which means
mainly fixing fallout from stage 1 or to complete features that have
been checked in during stage 1.

Thanks,
Richard.

Re: complete_unrolli / complete_unroll

[Richard Guenther]

On Tue, Sep 29, 2009 at 8:23 PM, David Edelsohn  wrote:
> On Thu, Aug 20, 2009 at 4:48 AM, Richard Guenther
>  wrote:
>
>> Can't we use graphite to re-roll loops?  That is, compress the
>> polyhedron by introducing a new parameter?  But maybe I am
>> not good at guessing what your initial bloat issue looks like.
>>
>> The reason I'm asking is that there is enough code out in the
>> wild that has loops with manually unrolled bodies - I have seen
>> up to 16 times here.
>
> Do we want to try to address this partially in GCC 4.5?  Providing
> some way to disable early unrolling either explicitly or implicitly
> when Graphite is enabled?
>
> Early unrolling can cause two problems:
>
> 1) Increase the size of SCoPs, which increases memory consumption and
> analysis time.
>
> 2) Confusing SCoP analysis.
>
> Separate from re-rolling and other long-term solutions, it would be
> helpful for Graphite if there was some explicit control over early
> unrolling to help with experimentation.

I can definitely look into that - can someone open a bugreport
and assign it to me please?

Thanks,
RIchard.

> Thanks, David
>

Re: DImode operations

[daniel tian]

Hi,
   Thanks for your guys advice. Now the gcc is built succeed first
time(without headers).
   Now I have to keep going for newlib.
   Thanks very much.

Re: [LTO] Request for testing: Last merge from trunk before final merge

[Joseph S. Myers]

On Wed, 30 Sep 2009, Richard Guenther wrote:

> New failures for head-i586

> FAIL: 26_numerics/headers/cmath/fabs_inline.cc (test for excess errors)

This is a failure of a non-LTO test, so a regression.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [LTO] Request for testing: Last merge from trunk before final merge

[Richard Guenther]

On Wed, Sep 30, 2009 at 2:35 PM, Joseph S. Myers
 wrote:
> On Wed, 30 Sep 2009, Richard Guenther wrote:
>
>> New failures for head-i586
>
>> FAIL: 26_numerics/headers/cmath/fabs_inline.cc (test for excess errors)
>
> This is a failure of a non-LTO test, so a regression.

You are right.  It doesn't reproduce with the patch to fix the
gcc.dg/attr-warn-unused-result.c FAIL on x86_64 with -m32.
The above testing was without that patch (but I stipped the
known FAILs that patch fixed ...).

I'll double-check on native i586.

Richard.

Re: SUBREG Unrecognizable RTL

[Dave Korn]

daniel tian wrote:
> here are some information from the libgcc2.c.176r.greg. (BTY: the
> error happened when cc1 build the libgcc2.c)
> 
> Reloads for insn # 147
> Reload 0: reload_out (SI) = (reg/v:SI 99 [ __d0 ])
>   GENERAL_REGS, RELOAD_FOR_OUTPUT (opnum = 0)
>   reload_out_reg: (reg/v:SI 99 [ __d0 ])
>   reload_reg_rtx: (reg:SI 5 R5)
> Reload 1: reload_in (HI) = (subreg:HI (reg/v:SI 94 [ d0 ]) 0)
>   GENERAL_REGS, RELOAD_FOR_INPUT (opnum = 1)
>   reload_in_reg: (subreg:HI (reg/v:SI 94 [ d0 ]) 0)
>   reload_reg_rtx: (reg:HI 5 R5)
> 
> So does it mean when the pseduo register 94 allocated fail, the memory
> location will be substitute ?

  Yes, when the register allocator can't find a spare register for a variable,
it makes use of a stack slot instead.

> (insn 749 156 147 22 (set (reg:HI 5 R5)
> (subreg:HI (mem/c:SI (plus:SI (reg/f:SI 15 R15)
> (const_int 108 [0x6c])) [19 d0+0 S4 A32]) 0)) -1 (nil))

  So, does your CPU support HImode sized load and store operations?

cheers,
  DaveK

Re: GCC 4.5 Status Report (2009-09-19)

[Jack Howarth]

On Wed, Sep 30, 2009 at 10:49:40AM +0200, Richard Guenther wrote:
> > 
> > Now, submitting a one liner as your first atte...@a new pass today
> > and then claiming the rest are just fixes, would be a stretch :-), but
> > for a patch like yours it does not seem unreasonable.
> 
> Just to followup once and answer all the multiple requests that have
> been (and will be) come up - during stage 3 it is up to the respective
> maintainers to decide what is considered a bugfix and whether to allow
> changes to go in that were submitted during stage 1.  The release
> managers trust the maintainers to make stage 3 a success - which means
> mainly fixing fallout from stage 1 or to complete features that have
> been checked in during stage 1.
> 
> Thanks,
> Richard.
> 

Richard,
   Is it safe to assume that with the LTO patches currently
unreviewed, the Oct. 1st deadline for stage 1 will be pushed
back? I ask because Iain is still working on the final patch
to solve PR39888 for darwin. If we in fact miss the transition
to stage 1, can this patch still go into gcc 4.5 since it is
target specific? Allowing it in would have the advantage of
setting the stage for reinstalling...

http://gcc.gnu.org/ml/gcc-patches/2008-12/msg01259.html

into gcc 4.5 without breaking darwin (since we could
just default on -muse-shared-libgcc-ext for that platform).
Thanks in advance for any clarifications as I am really
hoping some form of...

http://gcc.gnu.org/bugzilla/attachment.cgi?id=18657

can make it into gcc 4.5.
  Jack

Re: define_memory_constraint and REG_OK_STRICT

[Richard Henderson]

On 09/29/2009 09:46 PM, Mohamed Shafi wrote:

  bool strict =  reload_completed ? true : false;


What happens if you set "strict = false" here?
That's what ARM does.


r~

i370 port - constructing compile script

[Paul Edwards]

What is the best way to go from this:

Makefile:

C_AND_OBJC_OBJS = attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o 
c-typeck.o \

 c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o c-semantics.o \

C_OBJS = c-lang.o stub-objc.o $(C_AND_OBJC_OBJS)

OBJS-common = \
^Iinsn-attrtab.o \
^Iinsn-automata.o \
^Iinsn-emit.o \
^Iinsn-extract.o \

to:

call stdcomp alias.c %1 %2 %3 %4 %5 %6 %7 %8 %9
call stdcomp alloc-pool.c %1 %2 %3 %4 %5 %6 %7 %8 %9
call stdcomp attribs.c %1 %2 %3 %4 %5 %6 %7 %8 %9
call stdcomp bb-reorder.c %1 %2 %3 %4 %5 %6 %7 %8 %9
call stdcomp bitmap.c %1 %2 %3 %4 %5 %6 %7 %8 %9
call stdcomp bt-load.c %1 %2 %3 %4 %5 %6 %7 %8 %9
call stdcomp builtins.c %1 %2 %3 %4 %5 %6 %7 %8 %9
call stdcomp caller-save.c %1 %2 %3 %4 %5 %6 %7 %8 %9
call stdcomp calls.c %1 %2 %3 %4 %5 %6 %7 %8 %9
call stdcomp c-aux-info.c %1 %2 %3 %4 %5 %6 %7 %8 %9
call stdcomp c-common.c %1 %2 %3 %4 %5 %6 %7 %8 %9

and then finally to:

//ALIASEXEC ST2CMP,MEMBER=ALIAS
//al...@po EXEC ST2CMP,member=al...@po
//ATTRIBS  EXEC ST2CMP,MEMBER=ATTRIBS
//b...@reord EXEC ST2CMP,member...@reord
//BITMAP   EXEC ST2CMP,MEMBER=BITMAP
//b...@load  EXEC ST2CMP,member...@load
//BUILTINS EXEC ST2CMP,MEMBER=BUILTINS
//cal...@s EXEC ST2CMP,member=cal...@s
//CALLSEXEC ST2CMP,MEMBER=CALLS
//c...@aux@IN EXEC ST2CMP,membe...@aux@IN
//c...@common EXEC ST2CMP,membe...@common


I am happy to construct all of this on a Unix system with the various
tools (m4 etc) available.

But from the Unix system, I need to be able to generate the
above very simple compile script, which is a precursor to creating
very simple JCL steps (trust me, you don't want to see what
ST2CMP looks like).  Note that the JCL has the filenames
truncated to 8 characters, listed twice, uppercased, and '-'
and '_' converted to '@'.

I assume I need a C program to do such a conversion.  I'm happy
to write that C program.  But what's the best way to work with
the existing infrastructure when writing and running that C
program?

One idea I had was to have a target that listed all the variables,
and then just had an "echo" as the rule to make the ".o" from
".c", and then I could just go "make" to get all the object files
listed out, and then I run a separate C program to convert that
into the various scripts.

Note that the objective is to basically get a list (in the above
format) of all necessary C source in order to be able to compile
(to assembler, not .o) C programs.  I will be building a single
executable, ie combining the C front end and i370 back end
into a single executable.  I know that it is possible, because
I already have it working (on 3.4.6).  Now the objective is to do
it properly.  :-)

Also note that I'm not 100% sure what variables to use to get
the minimum required source, although I would guess
GCC_OBJS, C_OBJS plus the individual files listed in
ALL_HOST_OBJS.  This would be something that would be
good to have an explicit variable for - the minimum C files
required in the process of converting C to assembler (even
though in normal configurations, those C files reside in
different executables).  So I would like to define such a
variable prior to doing the above.

Thanks.  Paul.


P.S. Here are the (intrusive) changes I have had to make so far
to get (maybe 3/4 of) GCC 4.4 to compile on a C90-only platform:

Index: gcc/system.h
===
RCS file: /cvsroot/gcc4/gcc/system.h,v
retrieving revision 1.1.1.1
diff -r1.1.1.1 system.h
180a181

#ifdef HAVE_SYS_TYPES_H

181a183

#endif

Index: include/sort.h
===
RCS file: /cvsroot/gcc4/include/sort.h,v
retrieving revision 1.1.1.1
diff -r1.1.1.1 sort.h
24a25

#ifdef HAVE_SYS_TYPES_H

25a27

#endif

Index: libcpp/include/cpplib.h
===
RCS file: /cvsroot/gcc4/libcpp/include/cpplib.h,v
retrieving revision 1.1.1.1
diff -r1.1.1.1 cpplib.h
26a27

#ifdef HAVE_SYS_TYPES_H

27a29,30

#endif


542,543c545,546
<   ino_t ino;
<   dev_t dev;
---

  /* ino_t ino; */
  /* dev_t dev; */

Index: libiberty/xmemdup.c
===
RCS file: /cvsroot/gcc4/libiberty/xmemdup.c,v
retrieving revision 1.1.1.1
diff -r1.1.1.1 xmemdup.c
23a24

#ifdef HAVE_SYS_TYPES_H

24a26

#endif

Index: libiberty/xstrdup.c
===
RCS file: /cvsroot/gcc4/libiberty/xstrdup.c,v
retrieving revision 1.1.1.1
diff -r1.1.1.1 xstrdup.c
18a19

#ifdef HAVE_SYS_TYPES_H

19a21

#endif


ie very little.

Not sure what the proper way to deal with that ino_t and dev_t is, but in
the past I've simply created my own typedefs:

typedef int ino_t;
typedef int dev_t;

and included them in config.h

But I'll deal with that after I've got a comprehensive list of source files.

Re: [LTO] Request for testing: Last merge from trunk before final merge

[Michael Meissner]

On Wed, Sep 30, 2009 at 10:41:26AM +0200, Richard Guenther wrote:
> I think the vmx testcases fail on me because I don't have a
> POWER7 machine to test on.  But it would be nice if ppc
> people would look at this.  Mike?

I or the others in my group should look at the failures.  Note, VMX is the
altivec instruction set, not the new power7 (VSX) instruction set.  Power6
machines should have altivec support.

-- 
Michael Meissner, IBM
4 Technology Place Drive, MS 2203A, Westford, MA, 01886, USA
meiss...@linux.vnet.ibm.com

Re: i370 port - constructing compile script

[Richard Henderson]

On 09/30/2009 08:00 AM, Paul Edwards wrote:

What is the best way to go from this:

Makefile:


The easy way to convert a Makefile to a shell script is "make -n".  That 
will print out all of the commands that make would run.  From there it's 
a Mere Matter of Programming to have perl (or whatever) edit that down 
into your JCL scripts.



r~

how to get the .dfa output file in gcc

[ddmetro]

Hi All,

We are trying to get the .dfa output file, showing details about the
automaton constructed for - instruction scheduling, using pipeline hazard
detector. However we are unable to do so.

We tried
(a.)uncommenting - (automata_option "v") - in ia64.md file
(b.)adding v_flag = 1 in gen_automata_option() function of genautomata.c
file
and running: make insn-automata.c

None of these gave a .dfa output file.
 
Target language for which optimization is being done: C
Target machine architecture: i686
GCC version: 4.4.1

Kindly help us with our issue.

Thanking All
-Dhiraj

-- 
View this message in context: 
http://www.nabble.com/how-to-get-the-.dfa-output-file-in-gcc-tp25685438p25685438.html
Sent from the gcc - Dev mailing list archive at Nabble.com.

Re: [LTO] Request for testing: Last merge from trunk before final merge

[Rainer Orth]

Diego Novillo  writes:

> In preparation for the final merge into mainline.  I need to test
> the branch on various platforms.  Richi is currently testing on
> i586, ppc, ppc64, ia64, s390, s390x.
> 
> If anyone has free cycles I would appreciate results from other
> ELF-capable targets.

I've run those for sparc-sun-solaris2.11, i386-pc-solaris2.10 and
mips-sgi-irix6.5.  Details below.

> $ svn co svn://gcc.gnu.org/svn/gcc/branches/lto
> $ mkdir bld && cd bld
> $ ../lto/configure --enable-lto && make

Why just a make and no make bootstrap?  This is also on the LTO wiki page,
which btw. is confusing since it states `Last updated: 07-Jul-2009'.  For
all my tests, I've just run regular bootstraps.

> You will need to have libelf 0.8.12 installed
> (http://www.mr511.de/software/libelf-0.8.12.tar.gz)

libelf 0.8.12 builds without problems on Solaris 10 and 11, but fails out
of the box on IRIX 6.5.  I've contacted the maintainer about this, and he
suggested configuring with

$ ac_cv_header_elf_h=no ac_cv_header_sys_elf_h=no ./configure

as a hack.  This works for now, until I ran into PR lto/40790 which is
still unfixed.  I stopped here, but it should be possible to use
GCC_HEADER_STDINT to work around this.

I've posted testsuite results for sparc-sun-solaris2.11 to

http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg02772.html

and compared them with mainline results as of 20090922.  Ada is missing
here, since I had to use a non-Ada enabled bootstrap compiler due to PR
bootstrap/39020.

@@ -20,13 +15,19 @@
 
=== g++ Summary for unix ===
 
[...]
 
 Running target unix/-m64
+FAIL: tmpdir-g++.dg-struct-layout-1/t003 cp_compat_x_tst.o-cp_compat_y_tst.o 
execute "-O2","-fwhopr"
+FAIL: tmpdir-g++.dg-struct-layout-1/t003 cp_compat_x_tst.o-cp_compat_y_tst.o 
execute "-O2","-flto"
+FAIL: tmpdir-g++.dg-struct-layout-1/t019 cp_compat_x_tst.o-cp_compat_y_tst.o 
execute "-O2","-fwhopr"
+FAIL: tmpdir-g++.dg-struct-layout-1/t019 cp_compat_x_tst.o-cp_compat_y_tst.o 
execute "-O2","-flto"
+FAIL: tmpdir-g++.dg-struct-layout-1/t030 cp_compat_x_tst.o-cp_compat_y_tst.o 
execute "-O2","-fwhopr"
+FAIL: tmpdir-g++.dg-struct-layout-1/t030 cp_compat_x_tst.o-cp_compat_y_tst.o 
execute "-O2","-flto"

There's no indication in the logs why those fail, the 32-bit tests are
fine.

=== gcc tests ===
[...] 
@@ -64,18 +65,22 @@
 FAIL: gcc.c-torture/compile/pr38789.c  -O3 -fomit-frame-pointer  (test for 
excess errors)
 FAIL: gcc.c-torture/compile/pr38789.c  -O3 -g  (test for excess errors)
 FAIL: gcc.c-torture/compile/pr38789.c  -Os  (test for excess errors)
+FAIL: gcc.c-torture/compile/pr38789.c  -O2 -flto  (test for excess errors)
+FAIL: gcc.c-torture/compile/pr38789.c  -O2 -fwhopr  (test for excess errors)

The test fails without -flto/-fwhopr as well: Sun as cannot cope with the
input.  I've filed PR testsuite/41522 for that.

 FAIL: gcc.c-torture/execute/pr38819.c execution,  -O2 
 FAIL: gcc.c-torture/execute/pr38819.c execution,  -O3 -fomit-frame-pointer 
 FAIL: gcc.c-torture/execute/pr38819.c execution,  -O3 -fomit-frame-pointer 
-funroll-loops 
 FAIL: gcc.c-torture/execute/pr38819.c execution,  -O3 -fomit-frame-pointer 
-funroll-all-loops -finline-functions 
 FAIL: gcc.c-torture/execute/pr38819.c execution,  -O3 -g 
+FAIL: gcc.c-torture/execute/pr38819.c execution,  -O2 -flto 
+FAIL: gcc.c-torture/execute/pr38819.c execution,  -O2 -fwhopr 

Similarly here: already fails without -flto.

+FAIL: gcc.dg/lto/20081120-1 c_lto_20081120-1_0.o-c_lto_20081120-1_1.o link
+UNRESOLVED: gcc.dg/lto/20081120-1 c_lto_20081120-1_0.o-c_lto_20081120-1_1.o 
execute -flto -shared

This fails like this:

output is:
Text relocation remains referenced
against symbol  offset  in file
stat64  0x4 c_lto_20081120-1_0.o
stat64  0x4 c_lto_20081120-1_1.o
ld: fatal: relocations remain against allocatable but non-writable sections
collect2: ld returned 1 exit status

FAIL: gcc.dg/lto/20081120-1 c_lto_20081120-1_0.o-c_lto_20081120-1_1.o link

It seems like -flto -shared doesn't create PIC code here for some reason.

+FAIL: gcc.dg/lto/20081201-2 c_lto_20081201-2_0.o-c_lto_20081201-2_1.o execute 
-O3 -fwhopr

No hint why this fails.

+FAIL: gcc.dg/lto/20090729 c_lto_20090729_0.o-c_lto_20090729_1.o link
+UNRESOLVED: gcc.dg/lto/20090729 c_lto_20090729_0.o-c_lto_20090729_1.o execute 
-w

output is:
ld: warning: symbol `i' has differing sizes:
(file c_lto_20090729_0.o value=0x8; file c_lto_20090729_1.o value=0x4);
c_lto_20090729_0.o definition taken
ld: warning: symbol `j' has differing sizes:
(file c_lto_20090729_0.o value=0x4; file c_lto_20090729_1.o value=0x8);
c_lto_20090729_1.o definition taken

This seems like it cannot work.

 FAIL: gcc.dg/torture/pr26565.c  -O1  execution test
 FAIL: gcc.dg/torture/pr26565.c  -O2  execution test
 FAIL: gcc.dg/torture/pr26565.c  -Os  execution test

Re: [LTO] Request for testing: Last merge from trunk before final merge

[Diego Novillo]

On Wed, Sep 30, 2009 at 13:36, Rainer Orth  
wrote:

>> $ svn co svn://gcc.gnu.org/svn/gcc/branches/lto
>> $ mkdir bld && cd bld
>> $ ../lto/configure --enable-lto && make
>
> Why just a make and no make bootstrap?

It's not necessary, but I wanted to make sure that you force LTO.  If
not, configure tries to detect LTO support and silently does nothing
if it can't enable.  If you force it, however, it gives you an error.

>  This is also on the LTO wiki page,
> which btw. is confusing since it states `Last updated: 07-Jul-2009'.  For
> all my tests, I've just run regular bootstraps.

I updated the wiki yesterday.  But I did not remove the --enable-lto
bit.  I will clarify why it's suggested.

Thanks for all the testing.  I'll followup after I finish processing
all the feedback from reviewers.


Diego.

Re: [LTO] Request for testing: Last merge from trunk before final merge

[Adam Nemet]

Diego Novillo  writes:
> If anyone has free cycles I would appreciate results from other
> ELF-capable targets.

The branch on mipsisa64-elf looks good (no regressions with languages
c,c++,objc):

  http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg02717.html

baseline:

  http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg02777.html

In addition to what has already been reported we have these failures in
the new lto tests:

FAIL: g++.dg/lto/20081109-1 cp_lto_20081109-1_0.o-cp_lto_20081109-1_0.o link
FAIL: g++.dg/lto/20081118 cp_lto_20081118_0.o-cp_lto_20081118_1.o link
FAIL: g++.dg/lto/20081119-1 cp_lto_20081119-1_0.o-cp_lto_20081119-1_1.o link
FAIL: g++.dg/lto/20081120-1 cp_lto_20081120-1_0.o-cp_lto_20081120-1_1.o link
FAIL: g++.dg/lto/20081120-2 cp_lto_20081120-2_0.o-cp_lto_20081120-2_1.o link
FAIL: g++.dg/lto/20081123 cp_lto_20081123_0.o-cp_lto_20081123_1.o link
FAIL: g++.dg/lto/20081204-1 cp_lto_20081204-1_0.o-cp_lto_20081204-1_1.o link
FAIL: g++.dg/lto/20081219 cp_lto_20081219_0.o-cp_lto_20081219_1.o link
FAIL: g++.dg/lto/20090302 cp_lto_20090302_0.o-cp_lto_20090302_1.o link
FAIL: g++.dg/lto/20090313 cp_lto_20090313_0.o-cp_lto_20090313_1.o link
FAIL: gcc.dg/lto/20081120-1 c_lto_20081120-1_0.o-c_lto_20081120-1_1.o link
FAIL: gcc.dg/lto/20081120-2 c_lto_20081120-2_0.o-c_lto_20081120-2_1.o link
FAIL: gcc.dg/lto/20081204-1 c_lto_20081204-1_0.o-c_lto_20081204-1_1.o link
FAIL: gcc.dg/lto/20081212-1 c_lto_20081212-1_0.o-c_lto_20081212-1_0.o link

  /home/anemet/src/gcc-lto/mipsisa64-elf/gcc/../ld/ld-new:
  /home/anemet/src/gcc-lto/mipsisa64-elf/mipsisa64-elf/./libgloss/mips/crt0.o:
  relocation R_MIPS_HI16 against `hardware_hazard_hook' can not be used
  when making a shared object; recompile with -fPIC

FAIL: g++.dg/lto/20081109 cp_lto_20081109_0.o-cp_lto_20081109_1.o execute -O0 
-fwhopr

  terminate called after throwing an instance of 'int'

FAIL: g++.dg/lto/20081109 cp_lto_20081109_0.o-cp_lto_20081109_1.o link,  
(internal compiler error)
FAIL: g++.dg/lto/20090311-1 cp_lto_20090311-1_0.o-cp_lto_20090311-1_1.o link,  
(internal compiler error)
FAIL: gcc.dg/lto/20081112 c_lto_20081112_0.o-c_lto_20081112_1.o link,  
(internal compiler error)
FAIL: gcc.dg/lto/20081118 c_lto_20081118_0.o-c_lto_20081118_2.o link,  
(internal compiler error)

  lto1: internal compiler error: Segmentation fault
  Please submit a full bug report,
  with preprocessed source if appropriate.
  See  for instructions.

FAIL: g++.dg/lto/20090311 cp_lto_20090311_0.o-cp_lto_20090311_1.o link
FAIL: g++.dg/lto/20090311 cp_lto_20090311_0.o-cp_lto_20090311_1.o link,  
(internal compiler error)
FAIL: g++.dg/lto/20090106 cp_lto_20090106_0.o-cp_lto_20090106_0.o link
FAIL: g++.dg/lto/20090106 cp_lto_20090106_0.o-cp_lto_20090106_0.o link

  (It's strange that these have the same name.)

  cp_lto_20090106_0.wpa.ltrans.o:(.rodata+0xbc): undefined reference to 
`_ZThn8_N1
  
00_GLOBAL__N__home_anemet_src_gcc_lto_combined_gcc_testsuite_g__.dg_lto_20090106
  _0.C__36F381533LMND1Ev.1183.1258'
  cp_lto_20090106_0.wpa.ltrans.o:(.rodata+0xc4): undefined reference to 
`_ZThn8_N1
  
00_GLOBAL__N__home_anemet_src_gcc_lto_combined_gcc_testsuite_g__.dg_lto_20090106
  _0.C__36F381533LMND0Ev.1236.1255'
  collect2: ld returned 1 exit status
  compiler exited with status 1
  output is:
  cp_lto_20090106_0.wpa.ltrans.o:(.rodata+0xbc): undefined reference to 
`_ZThn8_N1
  
00_GLOBAL__N__home_anemet_src_gcc_lto_combined_gcc_testsuite_g__.dg_lto_20090106
  _0.C__36F381533LMND1Ev.1183.1258'
  cp_lto_20090106_0.wpa.ltrans.o:(.rodata+0xc4): undefined reference to 
`_ZThn8_N1
  
00_GLOBAL__N__home_anemet_src_gcc_lto_combined_gcc_testsuite_g__.dg_lto_20090106
  _0.C__36F381533LMND0Ev.1236.1255'
  collect2: ld returned 1 exit status

Re: [LTO] Request for testing: Last merge from trunk before final merge

[Richard Guenther]

On Wed, Sep 30, 2009 at 7:36 PM, Rainer Orth
 wrote:
> Diego Novillo  writes:
>
>> In preparation for the final merge into mainline.  I need to test
>> the branch on various platforms.  Richi is currently testing on
>> i586, ppc, ppc64, ia64, s390, s390x.
>>
>> If anyone has free cycles I would appreciate results from other
>> ELF-capable targets.
>
> I've run those for sparc-sun-solaris2.11, i386-pc-solaris2.10 and
> mips-sgi-irix6.5.  Details below.
>
>> $ svn co svn://gcc.gnu.org/svn/gcc/branches/lto
>> $ mkdir bld && cd bld
>> $ ../lto/configure --enable-lto && make
>
> Why just a make and no make bootstrap?  This is also on the LTO wiki page,
> which btw. is confusing since it states `Last updated: 07-Jul-2009'.  For
> all my tests, I've just run regular bootstraps.
>
>> You will need to have libelf 0.8.12 installed
>> (http://www.mr511.de/software/libelf-0.8.12.tar.gz)
>
> libelf 0.8.12 builds without problems on Solaris 10 and 11, but fails out
> of the box on IRIX 6.5.  I've contacted the maintainer about this, and he
> suggested configuring with
>
> $ ac_cv_header_elf_h=no ac_cv_header_sys_elf_h=no ./configure
>
> as a hack.  This works for now, until I ran into PR lto/40790 which is
> still unfixed.  I stopped here, but it should be possible to use
> GCC_HEADER_STDINT to work around this.
>
> I've posted testsuite results for sparc-sun-solaris2.11 to
>
>        http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg02772.html
>
> and compared them with mainline results as of 20090922.  Ada is missing
> here, since I had to use a non-Ada enabled bootstrap compiler due to PR
> bootstrap/39020.
>
> @@ -20,13 +15,19 @@
>
>                === g++ Summary for unix ===
>
> [...]
>
>  Running target unix/-m64
> +FAIL: tmpdir-g++.dg-struct-layout-1/t003 cp_compat_x_tst.o-cp_compat_y_tst.o 
> execute "-O2","-fwhopr"
> +FAIL: tmpdir-g++.dg-struct-layout-1/t003 cp_compat_x_tst.o-cp_compat_y_tst.o 
> execute "-O2","-flto"
> +FAIL: tmpdir-g++.dg-struct-layout-1/t019 cp_compat_x_tst.o-cp_compat_y_tst.o 
> execute "-O2","-fwhopr"
> +FAIL: tmpdir-g++.dg-struct-layout-1/t019 cp_compat_x_tst.o-cp_compat_y_tst.o 
> execute "-O2","-flto"
> +FAIL: tmpdir-g++.dg-struct-layout-1/t030 cp_compat_x_tst.o-cp_compat_y_tst.o 
> execute "-O2","-fwhopr"
> +FAIL: tmpdir-g++.dg-struct-layout-1/t030 cp_compat_x_tst.o-cp_compat_y_tst.o 
> execute "-O2","-flto"
>
> There's no indication in the logs why those fail, the 32-bit tests are
> fine.
>
>                === gcc tests ===
> [...]
> @@ -64,18 +65,22 @@
>  FAIL: gcc.c-torture/compile/pr38789.c  -O3 -fomit-frame-pointer  (test for 
> excess errors)
>  FAIL: gcc.c-torture/compile/pr38789.c  -O3 -g  (test for excess errors)
>  FAIL: gcc.c-torture/compile/pr38789.c  -Os  (test for excess errors)
> +FAIL: gcc.c-torture/compile/pr38789.c  -O2 -flto  (test for excess errors)
> +FAIL: gcc.c-torture/compile/pr38789.c  -O2 -fwhopr  (test for excess errors)
>
> The test fails without -flto/-fwhopr as well: Sun as cannot cope with the
> input.  I've filed PR testsuite/41522 for that.
>
>  FAIL: gcc.c-torture/execute/pr38819.c execution,  -O2
>  FAIL: gcc.c-torture/execute/pr38819.c execution,  -O3 -fomit-frame-pointer
>  FAIL: gcc.c-torture/execute/pr38819.c execution,  -O3 -fomit-frame-pointer 
> -funroll-loops
>  FAIL: gcc.c-torture/execute/pr38819.c execution,  -O3 -fomit-frame-pointer 
> -funroll-all-loops -finline-functions
>  FAIL: gcc.c-torture/execute/pr38819.c execution,  -O3 -g
> +FAIL: gcc.c-torture/execute/pr38819.c execution,  -O2 -flto
> +FAIL: gcc.c-torture/execute/pr38819.c execution,  -O2 -fwhopr
>
> Similarly here: already fails without -flto.
>
> +FAIL: gcc.dg/lto/20081120-1 c_lto_20081120-1_0.o-c_lto_20081120-1_1.o link
> +UNRESOLVED: gcc.dg/lto/20081120-1 c_lto_20081120-1_0.o-c_lto_20081120-1_1.o 
> execute -flto -shared
>
> This fails like this:
>
> output is:
> Text relocation remains                         referenced
>    against symbol                  offset      in file
> stat64                              0x4         c_lto_20081120-1_0.o
> stat64                              0x4         c_lto_20081120-1_1.o
> ld: fatal: relocations remain against allocatable but non-writable sections
> collect2: ld returned 1 exit status
>
> FAIL: gcc.dg/lto/20081120-1 c_lto_20081120-1_0.o-c_lto_20081120-1_1.o link
>
> It seems like -flto -shared doesn't create PIC code here for some reason.
>
> +FAIL: gcc.dg/lto/20081201-2 c_lto_20081201-2_0.o-c_lto_20081201-2_1.o 
> execute -O3 -fwhopr
>
> No hint why this fails.
>
> +FAIL: gcc.dg/lto/20090729 c_lto_20090729_0.o-c_lto_20090729_1.o link
> +UNRESOLVED: gcc.dg/lto/20090729 c_lto_20090729_0.o-c_lto_20090729_1.o 
> execute -w
>
> output is:
> ld: warning: symbol `i' has differing sizes:
>        (file c_lto_20090729_0.o value=0x8; file c_lto_20090729_1.o value=0x4);
>        c_lto_20090729_0.o definition taken
> ld: warning: symbol `j' has differing sizes:
>        (file c_lto_20090729_0.o value=0x4; file c_lto_20090729_1.o value=0x8);

"massive" inline

[Alexander Shabanov]

Hello!

Could you please clarify whether or not g++ takes into an account
explicitly specified inline qualifier for the class member function
implemented in the class body?

I know that according to C++ standard such a function shall be
qualified as inline no matter whether "inline" qualifier specified or
not, but I still have doubts regarding gcc behavior on that (mostly
because I've seen vast amount of the production code written in this
manner).

I mean whether the code

class A
{
  inline void foo() { ... }
};

is absolutely equal to

class A
{
  void foo() { ... }
};

in *any* circumstances or not?

Thanks in advance.

-- 
Best regards,
Alexander Shabanov

Re: "massive" inline

[Andrew Pinski]

On Wed, Sep 30, 2009 at 12:39 PM, Alexander Shabanov
 wrote:
> I mean whether the code
>
> class A
> {
>  inline void foo() { ... }
> };
>
> is absolutely equal to
>
> class A
> {
>  void foo() { ... }
> };
>
> in *any* circumstances or not?

They are the same unless you do -fno-default-inline and then the
second version is not marked as inline.

Thanks,
Andrew Pinski

Re: [LTO] Request for testing: Last merge from trunk before final merge

[Marc Glisse]

On Wed, 30 Sep 2009, Richard Guenther wrote:


On Wed, Sep 30, 2009 at 7:36 PM, Rainer Orth
 wrote:

+FAIL: gcc.dg/lto/20090729 c_lto_20090729_0.o-c_lto_20090729_1.o link
+UNRESOLVED: gcc.dg/lto/20090729 c_lto_20090729_0.o-c_lto_20090729_1.o execute 
-w

output is:
ld: warning: symbol `i' has differing sizes:
       (file c_lto_20090729_0.o value=0x8; file c_lto_20090729_1.o value=0x4);
       c_lto_20090729_0.o definition taken
ld: warning: symbol `j' has differing sizes:
       (file c_lto_20090729_0.o value=0x4; file c_lto_20090729_1.o value=0x8);
       c_lto_20090729_1.o definition taken

This seems like it cannot work.


Ah.  We don't expect the linker to complain here - GNU ld accepts different
size common sections.  The testcase is reduced from broken SPEC CPU 2000
source ...

If you happen to know a linker option that would silence the warning ...


http://docs.sun.com/app/docs/doc/817-1984/chapter2-88783?a=view#chapter2-7
seems to recommend the -t linker flag.


--
Marc Glisse

Re: i370 port - constructing compile script

[Paul Edwards]

What is the best way to go from this:

Makefile:


The easy way to convert a Makefile to a shell script is "make -n".  That 
will print out all of the commands that make would run.  From there it's a 
Mere Matter of Programming to have perl (or whatever) edit that down into 
your JCL scripts.


Hi Richard.  Thanks for your reply.

1. That would include a lot of irrelevant commands - compiles and
links of the generator files interspersed with what I actually need
to go into the stage 1 executable on the target machine.

Maybe a variable STAGE1_OBJS would be suitable?

2. If the normal way to do things is to parse the make -n output
with perl etc, that's fine, I'll do it that way.  I was just wondering
if the proper way was to incorporate the logic into a Makefile
rule and get that rule repeatedly executed rather than just
having a simple "echo".  It seems to me that having a generic
rule to execute an external script would be neater???


BTW, I remember your name from the i370 md.  Why were you
interested in i370 at the time (probably many years ago)?  Or
was someone else just asking a public question and you
answered it (like now)?

BFN.  Paul.



 else
   {
   /* implementation suggested by  Richard Henderson  
*/

   rtx reg1 = gen_reg_rtx (DImode);
   rtx reg2 = gen_reg_rtx (DImode);
   rtx result = operands[0];
   rtx mem1 = operands[1];
   rtx mem2 = operands[2];
   rtx len = operands[3];
   if (!CONSTANT_P (len))
 len = force_reg (SImode, len);

   /* Load up the address+length pairs.  */
   emit_insn (gen_rtx_CLOBBER (VOIDmode, reg1));
   emit_move_insn (gen_rtx_SUBREG (SImode, reg1, 0),
   force_operand (XEXP (mem1, 0), NULL_RTX));
   emit_move_insn (gen_rtx_SUBREG (SImode, reg1, GET_MODE_SIZE 
(SImode)),


   emit_insn (gen_rtx_CLOBBER (VOIDmode, reg2));
   emit_move_insn (gen_rtx_SUBREG (SImode, reg2, 0),
   force_operand (XEXP (mem2, 0), NULL_RTX));
   emit_move_insn (gen_rtx_SUBREG (SImode, reg2, GET_MODE_SIZE 
(SImode)),


   /* Compare! */
   emit_insn (gen_cmpmemsi_1 (result, reg1, reg2));
   }
 DONE;
}")

Headsup: Rogue or hacked account spamming via RT? re: [gnu.org #263454]

[Dave Korn via RT]

Hello GNU webmasters,

  I hope this is the right place to report what appears to be a problem at
rt.gnu.org, I couldn't find an explicit contact address for it.

  We just got two posts on the GCC mailing list with the subject line
"[gnu.org #263454] Take home $204,000.00 this month":

http://gcc.gnu.org/ml/gcc/2009-09/msg00650.html
http://gcc.gnu.org/ml/gcc/2009-09/msg00651.html

and according to the headers (visible by the "raw text" links at the above
URLs) these appear to have genuinely originated at rt.gnu.org via the web
interface:

> From gcc-return-156943-listarch-gcc=gcc dot gnu dot org at gcc dot gnu dot 
> org Wed Sep 30 21:26:16 2009
> Return-Path:  gnu dot org>
> Delivered-To: listarch-gcc at gcc dot gnu dot org
> Received: (qmail 965 invoked by alias); 30 Sep 2009 21:26:15 -
> Received: (qmail 927 invoked by uid 22791); 30 Sep 2009 21:26:14 -
> X-SWARE-Spam-Status: No, hits=3.3 required=5.0
> tests=BAYES_20,CTYME_IXHASH,GENERIC_IXHASH,SPF_PASS
> X-Spam-Check-By: sourceware.org
> Received: from fencepost.gnu.org (HELO fencepost.gnu.org) (140.186.70.10) 
> by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 30 Sep 2009 21:26:12 
> +
> Received: from mail.gnu.org ([199.232.76.166]:35875 helo=mx10.gnu.org)
> by fencepost.gnu.org with esmtp (Exim 4.67) (envelope-from 
> )  id 1Mt6gc-aj-Hs for g...@gnu.org; Wed, 30 
> Sep 2009 17:26:10 -0400
> Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 
> 4.60)  (envelope-from )  id 1Mt6gN-0003BZ-IS 
> for g...@gnu.org; Wed, 30 Sep 2009 17:26:09 -0400
> Received: from rt.gnu.org ([199.232.76.167]:48703)by monty-python.gnu.org 
> with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32)   (Exim 4.60) 
> (envelope-from )  id 1Mt6fy-00034y-H1; Wed, 30 Sep 2009 
> 17:25:31 -0400
> Received: from www-data by rt.gnu.org with local (Exim 4.69)  (envelope-from 
> )  id 1Mt6lf-0007l4-40; Wed, 30 Sep 2009 17:31:23 -0400
> Subject: [gnu.org #263454] Take home $204,000.00 this month
> From: "Jose E dot  Marchesi via RT" 
> Reply-To: tasks at gnu dot org
> In-Reply-To:
> References: 
> Message-ID: 
> X-RT-Loop-Prevention: gnu.org
> RT-Ticket: gnu.org #263454
> Managed-by: RT 3.4.5 (http://www.bestpractical.com/rt/)
> RT-Originator: jema...@gnu.org

  Somebody with administrative access probably needs to take an urgent look at
who's in control of the "jemarch" account, I think.

cheers,
  DaveK

Headsup: Rogue or hacked account spamming via RT? re: [gnu.org #263454]

[Dave Korn via RT]

Hello GNU webmasters,

  I hope this is the right place to report what appears to be a problem at
rt.gnu.org, I couldn't find an explicit contact address for it.

  We just got two posts on the GCC mailing list with the subject line
"[gnu.org #263454] Take home $204,000.00 this month":

http://gcc.gnu.org/ml/gcc/2009-09/msg00650.html
http://gcc.gnu.org/ml/gcc/2009-09/msg00651.html

and according to the headers (visible by the "raw text" links at the above
URLs) these appear to have genuinely originated at rt.gnu.org via the web
interface:

> From gcc-return-156943-listarch-gcc=gcc dot gnu dot org at gcc dot gnu dot 
> org Wed Sep 30 21:26:16 2009
> Return-Path:  gnu dot org>
> Delivered-To: listarch-gcc at gcc dot gnu dot org
> Received: (qmail 965 invoked by alias); 30 Sep 2009 21:26:15 -
> Received: (qmail 927 invoked by uid 22791); 30 Sep 2009 21:26:14 -
> X-SWARE-Spam-Status: No, hits=3.3 required=5.0
> tests=BAYES_20,CTYME_IXHASH,GENERIC_IXHASH,SPF_PASS
> X-Spam-Check-By: sourceware.org
> Received: from fencepost.gnu.org (HELO fencepost.gnu.org) (140.186.70.10) 
> by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 30 Sep 2009 21:26:12 
> +
> Received: from mail.gnu.org ([199.232.76.166]:35875 helo=mx10.gnu.org)
> by fencepost.gnu.org with esmtp (Exim 4.67) (envelope-from 
> )  id 1Mt6gc-aj-Hs for g...@gnu.org; Wed, 30 
> Sep 2009 17:26:10 -0400
> Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 
> 4.60)  (envelope-from )  id 1Mt6gN-0003BZ-IS 
> for g...@gnu.org; Wed, 30 Sep 2009 17:26:09 -0400
> Received: from rt.gnu.org ([199.232.76.167]:48703)by monty-python.gnu.org 
> with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32)   (Exim 4.60) 
> (envelope-from )  id 1Mt6fy-00034y-H1; Wed, 30 Sep 2009 
> 17:25:31 -0400
> Received: from www-data by rt.gnu.org with local (Exim 4.69)  (envelope-from 
> )  id 1Mt6lf-0007l4-40; Wed, 30 Sep 2009 17:31:23 -0400
> Subject: [gnu.org #263454] Take home $204,000.00 this month
> From: "Jose E dot  Marchesi via RT" 
> Reply-To: tasks at gnu dot org
> In-Reply-To:
> References: 
> Message-ID: 
> X-RT-Loop-Prevention: gnu.org
> RT-Ticket: gnu.org #263454
> Managed-by: RT 3.4.5 (http://www.bestpractical.com/rt/)
> RT-Originator: jema...@gnu.org

  Somebody with administrative access probably needs to take an urgent look at
who's in control of the "jemarch" account, I think.

cheers,
  DaveK

Re: [LTO] Request for testing: Last merge from trunk before final merge

[Kaz Kojima]

Diego Novillo  wrote:
> In preparation for the final merge into mainline.  I need to test
> the branch on various platforms.  Richi is currently testing on
> i586, ppc, ppc64, ia64, s390, s390x.
> 
> If anyone has free cycles I would appreciate results from other
> ELF-capable targets.
> 
> $ svn co svn://gcc.gnu.org/svn/gcc/branches/lto
> $ mkdir bld && cd bld
> $ ../lto/configure --enable-lto && make
> 
> You will need to have libelf 0.8.12 installed
> (http://www.mr511.de/software/libelf-0.8.12.tar.gz)

The result for x86 cross sh4-unknown-linux-gnu looks similar
to those reported for other targets.  The cross compiler was
configured with

../TMP/lto/configure --host=i686-pc-linux-gnu --target=sh4-unknown-linux-gnu 
--enable-lto --enable-shared --enable-threads=posix --enable-clocale=gnu 
--enable-libgcj --with-ld=/usr/local/bin/sh4-unknown-linux-gnu-ld 
--with-as=/usr/local/bin/sh4-unknown-linux-gnu-as --with-sysroot=/exp/ldroot 
--with-mpfr=/opt2/i686-pc-linux-gnu --with-gmp=/opt2/i686-pc-linux-gnu 
--with-mpc=/opt2/i686-pc-linux-gnu --enable-languages=c,c++,fortran,java,objc

The host is Fedora 11 and the version of cross ld is
2.20.51.20090913.
The result of compare_tests against the head
  http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg02758.html
is here.

New tests that FAIL:

g++.dg/lto/20081109 cp_lto_20081109_0.o-cp_lto_20081109_1.o execute -O0 -fwhopr
g++.dg/lto/20081109 cp_lto_20081109_0.o-cp_lto_20081109_1.o link,  (internal 
compiler error)
g++.dg/lto/20090106 cp_lto_20090106_0.o-cp_lto_20090106_0.o link
g++.dg/lto/20090106 cp_lto_20090106_0.o-cp_lto_20090106_0.o link

  terminate called after throwing an instance of 'int'

g++.dg/lto/20090311 cp_lto_20090311_0.o-cp_lto_20090311_1.o link
g++.dg/lto/20090311 cp_lto_20090311_0.o-cp_lto_20090311_1.o link,  (internal 
compiler error)
g++.dg/lto/20090311-1 cp_lto_20090311-1_0.o-cp_lto_20090311-1_1.o link,  
(internal compiler error)

  lto1: internal compiler error: Segmentation fault

gcc.dg/lto/20081112 c_lto_20081112_0.o-c_lto_20081112_1.o link,  (internal 
compiler error)
gcc.dg/lto/20081118 c_lto_20081118_0.o-c_lto_20081118_2.o link,  (internal 
compiler error)
gcc.dg/lto/20090218 c_lto_20090218_0.o-c_lto_20090218_3.o link,  (internal 
compiler error)
gcc.dg/lto/20090218-2 c_lto_20090218-2_0.o-c_lto_20090218-2_1.o link,  
(internal compiler error)

  lto1: internal compiler error: Segmentation fault

gcc.dg/torture/builtin-math-7.c  -O2 -flto  (internal compiler error)
gcc.dg/torture/builtin-math-7.c  -O2 -flto  (test for excess errors)
gcc.dg/torture/builtin-math-7.c  -O2 -fwhopr  (internal compiler error)
gcc.dg/torture/builtin-math-7.c  -O2 -fwhopr  (test for excess errors)

  /exp/ldroot/dodes/TMP/lto/gcc/testsuite/gcc.dg/torture/builtin-math-7.c:59:5: 
internal compiler error: Segmentation fault

gfortran.dg/lto/pr40724 f_lto_pr40724_0.o-f_lto_pr40724_1.o link,  (internal 
compiler error)
gfortran.dg/lto/pr40725 f_lto_pr40725_0.o-f_lto_pr40725_1.o execute -O2 -flto
gfortran.dg/lto/pr40725 f_lto_pr40725_0.o-f_lto_pr40725_1.o execute -O2 -fwhopr

  lto1: internal compiler error: Segmentation fault

Regards,
kaz

Re: Headsup: Rogue or hacked account spamming via RT? re: [gnu.org #263454]

[Daniel Jacobowitz]

On Wed, Sep 30, 2009 at 06:48:02PM -0400, Dave Korn via RT wrote:
> 
> Hello GNU webmasters,
> 
>   I hope this is the right place to report what appears to be a problem at
> rt.gnu.org, I couldn't find an explicit contact address for it.
> 
>   We just got two posts on the GCC mailing list with the subject line
> "[gnu.org #263454] Take home $204,000.00 this month":
> 
> http://gcc.gnu.org/ml/gcc/2009-09/msg00650.html
> http://gcc.gnu.org/ml/gcc/2009-09/msg00651.html
> 
> and according to the headers (visible by the "raw text" links at the above
> URLs) these appear to have genuinely originated at rt.gnu.org via the web
> interface:

Isn't this more likely the RT admins closing spam reports?

-- 
Daniel Jacobowitz
CodeSourcery

Re: Headsup: Rogue or hacked account spamming via RT? re:

[Dave Korn]

Daniel Jacobowitz wrote:
> On Wed, Sep 30, 2009 at 06:48:02PM -0400, Dave Korn via RT wrote:
>> Hello GNU webmasters,
>>
>>   I hope this is the right place to report what appears to be a problem at
>> rt.gnu.org, I couldn't find an explicit contact address for it.
>>
>>   We just got two posts on the GCC mailing list with the subject line
>> "[gnu.org #263454] Take home $204,000.00 this month":
>>
>> http://gcc.gnu.org/ml/gcc/2009-09/msg00650.html
>> http://gcc.gnu.org/ml/gcc/2009-09/msg00651.html
>>
>> and according to the headers (visible by the "raw text" links at the above
>> URLs) these appear to have genuinely originated at rt.gnu.org via the web
>> interface:
> 
> Isn't this more likely the RT admins closing spam reports?

  It could be, I haven't seen anything like it happening before.  Does it
often result in email to the lists?

  I should have thought not to add the ticket # to the subject line though, I
assume that's why this post got mirrored here when I sent it to the webmasters
list.  Sorry for the noise all.

cheers,
  DaveK

GCC 4.5 Status Report (2009-10-01)

[Richard Guenther]

Status
==

The trunk is in Stage 3.  Stage 3 will end on Nov 30th after which
the trunk will be open for regression and documentation fixes only.
Stage 3 is for general bugfixing, what is considered a bugfix is
up to the maintainers.  At the discretion of the maintainers patches
that were finished during Stage 1 but have not yet been reviewed or
committed may be still applied.  Please have the release quality
in mind when approving late patches.

Once the remaining pieces have been approved the trunk will freeze
for the merge of the LTO branch which Diego will announce.

There are still new ports pending review and approval.  As usual
new ports can be accepted also during Stage 3.

Surprisingly the quality data improved, a good start into Stage 3!

Quality Data


Priority  # Change from Last Report
--- ---
P1   19 - 3
P2  108 - 3
P37 + 1
--- ---
Total   134 - 5

Previous Report
===

http://gcc.gnu.org/ml/gcc/2009-09/msg00357.html

The next report will be sent by Jakub.

-- 
Richard Guenther 
Novell / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex

Re: GCC 4.5 Status Report (2009-10-01)

[Gabriel Dos Reis]

On Wed, Sep 30, 2009 at 6:23 PM, Richard Guenther  wrote:
>
> Status
> ==
>
> The trunk is in Stage 3.

some of us are living in a timezone where it is still September 30, 2009. :-/

-- Gaby

Re: GCC 4.5 Status Report (2009-10-01)

[Richard Guenther]

On Wed, 30 Sep 2009, Gabriel Dos Reis wrote:

> On Wed, Sep 30, 2009 at 6:23 PM, Richard Guenther  wrote:
> >
> > Status
> > ==
> >
> > The trunk is in Stage 3.
> 
> some of us are living in a timezone where it is still September 30, 2009. :-/

Sorry ;)  I expect the news will take some time to spread (heh, now I
know you have recognized the fact! ;)).  At your discretion you can
choose to interpret the mail as sent-in-the-future, as the subject
suggests.

Richard.

-- 
Richard Guenther 
Novell / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex

Re: i370 port - constructing compile script

[Ian Lance Taylor]

"Paul Edwards"  writes:

> 2. If the normal way to do things is to parse the make -n output
> with perl etc, that's fine, I'll do it that way.  I was just wondering
> if the proper way was to incorporate the logic into a Makefile
> rule and get that rule repeatedly executed rather than just
> having a simple "echo".  It seems to me that having a generic
> rule to execute an external script would be neater???

I'm not sure what you are suggesting here, but I do know that it
wouldn't make sense for us to change the gcc Makefile to use a rule
which executes an external script.

The "normal way to do things" is to use GNU make.  I think you are the
first person trying to build gcc without it.

Ian

Re: i370 port - constructing compile script

[Joseph S. Myers]

On Wed, 30 Sep 2009, Ian Lance Taylor wrote:

> "Paul Edwards"  writes:
> 
> > 2. If the normal way to do things is to parse the make -n output
> > with perl etc, that's fine, I'll do it that way.  I was just wondering
> > if the proper way was to incorporate the logic into a Makefile
> > rule and get that rule repeatedly executed rather than just
> > having a simple "echo".  It seems to me that having a generic
> > rule to execute an external script would be neater???
> 
> I'm not sure what you are suggesting here, but I do know that it
> wouldn't make sense for us to change the gcc Makefile to use a rule
> which executes an external script.
> 
> The "normal way to do things" is to use GNU make.  I think you are the
> first person trying to build gcc without it.

Not the first - BSDs have been known to import GCC sources into their 
repositories and write their own build system using BSD make.  No doubt 
this is a lot of work that needs repeating for each new version imported - 
that's the price you pay if you don't want to use the normal GCC build 
system.

(And GCC didn't always require GNU make - but the BSDs replacing the build 
system are a much closer analogy here than ordinary builds of old versions 
with other make implementations before GNU make was required.)

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: GCC 4.5 Status Report (2009-09-19)

[Neil Vachharajani]

Hi Richard,

I have several patches that I've emailed to gcc-patches (some a few
days ago, some a bit longer).  They are still pending code review.
Will this still be able to make it into gcc 4.5?  The list of patches
is as follows:

http://gcc.gnu.org/ml/gcc-patches/2009-09/msg01170.html
http://gcc.gnu.org/ml/gcc-patches/2009-09/msg01590.html
http://gcc.gnu.org/ml/gcc-patches/2009-09/msg02119.html

Thanks,
Neil

On Sat, Sep 19, 2009 at 1:57 PM, Richard Guenther  wrote:
>
> Status
> ==
>
> The trunk is in Stage 1.  Stage 1 will end on Sep 30th.  After Stage 1
> Stage 3 follows with only bugfixes and no new features allowed.
> Stage 3 will end Nov 30th.
>
> Since the last status report we have merged the VTA branch and pieces
> of the LTO branch.  The named address-spaces changes are still pending
> review but I expect it to be merged before the end of Stage 1.
> The rest of the LTO branch will be merged last, which practically
> means after Stage 1 is over.  Thus, starting Oct 1st the trunk will
> be frozen for the LTO merge and I'll announce Stage 3 once the merge
> is completed.
>
> There are still new ports pending review and approval.  As usual
> new ports can be accepted also during Stage 3.
>
> We've been accumulating quite a number of P1 bugs.  Entering Stage 3
> should allow to improve considerably here in a short time.
>
> Quality Data
> 
>
> Priority          #     Change from Last Report
>         ---     ---
> P1               22     + 6
> P2              111     + 7
> P3                6     + 6
>         ---     ---
> Total           139     +19
>
> Previous Report
> ===
>
> http://gcc.gnu.org/ml/gcc/2009-08/msg00427.html
>
> The next report will be sent by me announcing Stage 3 begin.
>
> --
> Richard Guenther 
> Novell / SUSE Labs
> SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus 
> Rex
>



-- 
Neil Vachharajani
Google
650-214-1804

Dw2 CIE no longer contains personality routine augmentation?

[Dave Korn]

Hi everyone,

  I'm using g++.old-deja/g++.brendan/new3.C as a testcase to investigate a
problem with dllimport at the moment, and noticed something a bit unusual:

  Here is the CIE data from new3.C as compiled with gcc-4.3.4

>   .section.eh_frame,"w"
> Lframe1:
>   .long   LECIE1-LSCIE1
> LSCIE1:
>   .long   0x0
>   .byte   0x1
>   .def___gxx_personality_v0;  .scl2;  .type   32; .endef
>   .ascii "zP\0"
>   .uleb128 0x1
>   .sleb128 -4
>   .byte   0x8
>   .uleb128 0x5
>   .byte   0x0
>   .long   ___gxx_personality_v0
>   .byte   0xc
>   .uleb128 0x4
>   .uleb128 0x4
>   .byte   0x88
>   .uleb128 0x1
>   .align 4
> LECIE1:

  And now with gcc tr...@152230, I see that the generated CIE no longer has
any augmentation, particularly it doesn't point to the personality routine any
more:

> LFE21:
>   .section.eh_frame,"w"
> Lframe1:
>   .long   LECIE1-LSCIE1
> LSCIE1:
>   .long   0x0
>   .byte   0x1
>   .ascii "\0"
>   .uleb128 0x1
>   .sleb128 -4
>   .byte   0x8
>   .byte   0xc
>   .uleb128 0x4
>   .uleb128 0x4
>   .byte   0x88
>   .uleb128 0x1
>   .align 4
> LECIE1:

  Is this intentional?

cheers,
  DaveK

Re: [LTO] Request for testing: Last merge from trunk before final merge

[Andrew Pinski]

I ran LTO for spu-elf.
Most of the gcc.dg/lto.exp fail because -shared is not support as
there are no shared library support for SPU yet.
In fact there is an error running the lto.exp testsuite from dejagnu:
+ERROR: tcl error sourcing
/home/apinski/src/lto/gcc/gcc/testsuite/gcc.dg/lto/lto.exp.
+ERROR: can't read "name": no such variable
This is because 20081212-1 fails to link and we are still trying to do
scan-symbol.

In the G++ testsuite, we have other issues.
With -fPIC, GCC defaults to erroring out if there is a runtime
relocation will happen, which causes some of the testcases to fail.

And one ICE:
+FAIL: g++.dg/lto/20090311 cp_lto_20090311_0.o-cp_lto_20090311_1.o
link,  (internal compiler error)
lto1: internal compiler error: in duplicate_node_data, at ipa-pure-const.c:633^M

This is at  -O2 -flto .

A link error:
FAIL: g++.dg/lto/20090311 cp_lto_20090311_0.o-cp_lto_20090311_1.o link
cp_lto_20090311_1.wpa.ltrans.o:(.rodata._ZTV2C2[_ZTV2C2]+0x8):
undefined reference to `_ZN2C2D1Ev'^Mcollect2: ld returned 1 exit
status^M
This is at -O2 -fwhopr.

Other than those issues, the results look like the trunk with addition
failures at -O2 -flto which also happen at -O2.

One failure without LTO which looks like it was introduced in just
recently (between revision 152285 and 152343):
FAIL: g++.dg/eh/crossjump1.C (test for excess errors)

I almost want to say
2009-09-30  Diego Novillo  
2009-09-30  Diego Novillo  
+
+   * cp/tree.c (cp_free_lang_data): Assert that DECL is a
+   FUNCTION_DECL or a VAR_DECL.
+   Call uses_template_params and check for
+   DECL_TEMPLATE_INSTANTIATION or
+   DECL_TEMPLATE_SPECIALIZATION

introduced it.  As I tested spu-elf before that patch without lto
enabled and that testcase worked.

As an aside looks like the testsuite link line does not record the
optimization level which was used which means there might be a couple
of the "tests" with the same name.

Thanks,
Andrew Pinski

Re: [LTO] Request for testing: Last merge from trunk before final merge

[Andrew Pinski]

On Wed, Sep 30, 2009 at 9:58 PM, Andrew Pinski  wrote:
> One failure without LTO which looks like it was introduced in just
> recently (between revision 152285 and 152343):
> FAIL: g++.dg/eh/crossjump1.C (test for excess errors)
>
> I almost want to say
> 2009-09-30  Diego Novillo  
> 2009-09-30  Diego Novillo  
> +
> +       * cp/tree.c (cp_free_lang_data): Assert that DECL is a
> +       FUNCTION_DECL or a VAR_DECL.
> +       Call uses_template_params and check for
> +       DECL_TEMPLATE_INSTANTIATION or
> +       DECL_TEMPLATE_SPECIALIZATION
>
> introduced it.  As I tested spu-elf before that patch without lto
> enabled and that testcase worked.

Oh and _S_empty_rep_storage looks like symbol is not being mangled
either as I think it is really std::string::_S_empty_rep_storage.

Thanks,
Andrew Pinski

Re: SUBREG Unrecognizable RTL

[daniel tian]

Yeah. My target do have instructions support load/store HImode. And
the problem is fix. I just don't understand why.  Here is the
information I gotta: http://gcc.gnu.org/ml/gcc/2005-01/msg00788.html.
I defined a predicate function rice_memory_operand which calls the
function memory operand directly, and nothing else it do. I wrote it
because it's convenient to debug. This is the what make the RTL
unrecognizable.

This is weird. I have to hack it later.
Anyway, after fixed it, gcc is build success which means a great
forward step for me.

Thanks for your guys'help.
Best Wishes.

daniel