[Bug target/36070] m68k/coldfire gcc build breaks due to sc_fpstate, sc_fpregs reference

[mkuvyrkov at gcc dot gnu dot org]

--- Comment #1 from mkuvyrkov at gcc dot gnu dot org  2009-09-02 07:34 
---
This is fixed on trunk.


-- 

mkuvyrkov at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36070

[Bug target/36070] m68k/coldfire gcc build breaks due to sc_fpstate, sc_fpregs reference

[mkuvyrkov at gcc dot gnu dot org]

--- Comment #2 from mkuvyrkov at gcc dot gnu dot org  2009-09-02 07:37 
---
If you'd like to backport the fix, it is in revision
http://gcc.gnu.org/viewcvs?view=revision&revision=149663


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36070

[Bug fortran/41053] internal compiler error: in emit_swap_insn, at reg-stack.c:827

[burnus at gcc dot gnu dot org]

--- Comment #11 from burnus at gcc dot gnu dot org  2009-09-02 09:46 ---
> > I just downloaded CPMD and built it under gfortran 4.4.1 and 4.5.0 (revision
> > 151047) without trouble.
>
> gcc version 4.5.0 20090528 (experimental) [trunk revision 147953] (SUSE 
> Linux) 

Could you try with a newer version? If PR 40587 was indeed the problem then it
should be fixed in 2009-07-03 (trunk revision 149212). That would also explain
why it works for Dominique.

Newer openSUSE builds can be found at
http://software.opensuse.org/search?baseproject=ALL&p=1&q=gcc45-fortran


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41053

[Bug libstdc++/41216] G++ failed to correctly resolve the template parameters.

[paolo dot carlini at oracle dot com]

--- Comment #6 from paolo dot carlini at oracle dot com  2009-09-02 09:48 
---
Note: probably the old behavior will be restored in 4.5 as a side effect of
other changes, but this type of code plays very risky games and even if it
compiles, can well lead to wrong runtime behavior. Thus I definitely suggest
fixing it for portability. As I said, according to the standard in order to
instantiate std::vector with Inner, Inner must be CopyConstructible, that is,
among other requirements, this type of code:

  Inner inner1;
  Inner inner2(inner1);

must lead to an inner2 equivalent to inner1. However, in Inner, the second line
of code above actually triggers the templatized constructor, which uses an
extractor, etc, something definitely *not* guaranteed to copy inner1. Adding to
Inner an Inner(Inner&) and an Inner(const Inner&) would for example fix it.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41216

[Bug libstdc++/41216] G++ failed to correctly resolve the template parameters.

[yimingli0126 at 163 dot com]

--- Comment #7 from yimingli0126 at 163 dot com  2009-09-02 10:33 ---
Thanks.

I have added explicit copy constructors both Inner(Inner const&) and
Inner(Inner&) to the class Inner, which are superior to template < class
IStream > Inner (IStream&) when the complier decides which should be called, so
that now the codes work well.

Here are the new sample codes:

struct Inner {
  template < class IStream > friend IStream& operator >> ( IStream& in, Inner&
inner );

  Inner() : data(0) {}
  Inner( Inner const& inner ) : data(inner.data) {} // Make the class
copy-constructable.
  Inner( Inner& );  // Only declaration is necessary fo gcc.
  template < class IStream > explicit Inner( IStream& in ) { operator >>
(in,*this); }

  int data;
};

template < class IStream >
IStream& operator >> ( IStream& in, Inner& inner )
{
  in >> inner.data;
  return in;
}

struct Outter {
  template < class IStream > friend IStream& operator >> ( IStream& in, Outter&
outter );

  Outter() {}
  Outter( Outter const& outter) {}  // Make the class copy-constructable.
  Outter( Outter& );  // Only declaration is necessary.
  template < class IStream > explicit Outter( IStream& in ) { operator >>
(in,*this); }

  std::vector inners;
};

template < class IStream >
IStream& operator >> ( IStream& in, Outter& outter )
{
  outter.inners.push_back(Inner(in));
  return in;
}

int main ( int argc, char* argv[] )
{
  Inner inner(std::cin);
  Outter outter(std::cin);
  return 0;
}

Actually, becuase there is a delcaration of Inner(Inner&), the instance of
template < class IStream > Outter( IStream& ) with IStream = Inner is
suppressed.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41216

[Bug regression/41188] move_invariant_reg() damages CBRANCH instructions with CLOBBER attribute

[amylaar at gcc dot gnu dot org]

--- Comment #6 from amylaar at gcc dot gnu dot org  2009-09-02 12:18 ---
Note that I discovered this bug in the milepost code only after single-stepping
through the SIMD co-processor code to find out what was going wrong.
A match_dup is only effective when an instruction is recognized, and reload
only cares about all the constraints being satisfied.  Since the instruction
was recognized before move_invariant_reg, its insn_code was cached, and as far
as all the subsequent passes were concerned, there was no reason to
re-recognize the instruction which had the invalid change.

In other cases, e.g. when reload has to do some real work, you might see an
ICE.


-- 

amylaar at gcc dot gnu dot org changed:

   What|Removed |Added

  GCC build triplet|independent (i686-cygwin)   |independent (i686-cygwin) /
   ||x86_64-unknown-linux-gnu
   ||(gc...@fsff
 GCC target triplet|msp430 (see below)  |msp430 (see below) / --
   ||target=arc-elf32 --with-
   ||extra-target-list
   Keywords||ice-on-valid-code, wrong-
   ||code


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41188

[Bug regression/41188] move_invariant_reg() damages CBRANCH instructions with CLOBBER attribute

[amylaar at gcc dot gnu dot org]

--- Comment #7 from amylaar at gcc dot gnu dot org  2009-09-02 12:27 ---
(In reply to comment #0)
> 3.1. For my needs, I have patched loop-invariant.c by adding the following
> function to explicitly record all CLOBBER references from INSN that match USE
> references:
> static void record_clobber_uses_workaround(rtx insn, struct invariant *inv,
> struct df_ref *use)
> {
> rtx pat = PATTERN(insn);
> if (GET_CODE(pat) == PARALLEL)
> {
> int len = XVECLEN(pat, 0);
> int idx = 0;
> 
> for (idx = 0; idx < len; idx++)
> {
> rtx subexp = XVECEXP(pat, 0, idx);
> if (GET_CODE(subexp) == CLOBBER)
> {
> if (XEXP (subexp, 0) == *DF_REF_REAL_LOC 
> (use))
> record_use (inv->def, &XEXP (subexp,
> 0), DF_REF_INSN (use));
> }   
> }
> }
> }
> The record_uses() function got patched accordingly:
>  if (inv)
> +  {
> record_use (inv->def, DF_REF_REAL_LOC (use), DF_REF_INSN (use));
> +   record_clobber_uses_workaround(insn, inv, use); 
> +  }

This change is incorrect because a register ceases to be a loop invariant
if it is clobbered.

> 3.2. I would recommend re-analyzing the more common case, when a single
> instruction uses and defines the same register, and decide, whether loop
> optimizations in loop-invariant.c should move such register. The bug does not
> seem to affect most architectures, however, specific INSN patterns, as
> described above, do trigger it. Maybe, a common function returning the list of
> all "match_dup"-ed references for a given INSN and an operand to detect such
> cases in a uniform way.

That would not be general enough.  You could also have an insn predicate which
requires specific correlations and/or properties of the operands.

Using validate_change, as I did in my patch, also covers these contingencies.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41188

[Bug regression/41188] move_invariant_reg() damages CBRANCH instructions with CLOBBER attribute

[amylaar at gcc dot gnu dot org]

--- Comment #8 from amylaar at gcc dot gnu dot org  2009-09-02 12:35 ---
Somehow bugzilla keeps eating some of the text I put in the Target: field.
My target settings were:
--target=arc-elf32 --with-extra-target-list='mxp-elf'


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41188

[Bug bootstrap/41224] New: [4.5 Regression] Bootstrap broken on powerpc-apple-darwin9 at revision 151318

[dominiq at lps dot ens dot fr]

At revision 151318 bootstrap fails on powerpc-apple-darwin9 (see also
http://gcc.gnu.org/ml/gcc-regression/2009-09/msg00015.html) with:

info --split-size=500 --split-size=500"  compare
rm -f stage_current
Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1obj-checksum.o differs
warning: gcc/cc1objplus-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
Bootstrap comparison failure!
gcc/alias.o differs
gcc/alloc-pool.o differs
gcc/attribs.o differs
gcc/auto-inc-dec.o differs
gcc/bb-reorder.o differs
gcc/bitmap.o differs
gcc/bt-load.o differs
gcc/build/errors.o differs
gcc/build/gcov-iov.o differs
gcc/build/genattr.o differs
gcc/build/genattrtab.o differs
gcc/build/genautomata.o differs
gcc/build/gencheck.o differs
gcc/build/genchecksum.o differs
gcc/build/gencodes.o differs
gcc/build/genconditions.o differs
gcc/build/gencondmd.o differs
gcc/build/genconfig.o differs
gcc/build/genconstants.o differs
gcc/build/genemit.o differs
gcc/build/genextract.o differs
gcc/build/genflags.o differs
gcc/build/gengenrtl.o differs
gcc/build/gengtype-lex.o differs
gcc/build/gengtype-parse.o differs
gcc/build/gengtype.o differs
gcc/build/genmddeps.o differs
gcc/build/genmodes.o differs
gcc/build/genopinit.o differs
gcc/build/genoutput.o differs
gcc/build/genpeep.o differs
gcc/build/genpreds.o differs
gcc/build/genrecog.o differs
gcc/build/gensupport.o differs
gcc/build/ggc-none.o differs
gcc/build/min-insn-modes.o differs
gcc/build/print-rtl.o differs
gcc/build/read-rtl.o differs
gcc/build/rtl.o differs
gcc/build/vec.o differs
gcc/builtins.o differs
gcc/c-aux-info.o differs
gcc/c-common.o differs
gcc/c-convert.o differs
gcc/c-cppbuiltin.o differs
gcc/c-decl.o differs
gcc/c-dump.o differs
gcc/c-errors.o differs
gcc/c-format.o differs
gcc/c-gimplify.o differs
gcc/c-lang.o differs
gcc/c-lex.o differs
gcc/c-objc-common.o differs
gcc/c-omp.o differs
gcc/c-opts.o differs
gcc/c-parser.o differs
gcc/c-pch.o differs
gcc/c-ppoutput.o differs
gcc/c-pragma.o differs
gcc/c-pretty-print.o differs
gcc/c-semantics.o differs
gcc/c-typeck.o differs
gcc/caller-save.o differs
gcc/calls.o differs
gcc/cfg.o differs
gcc/cfganal.o differs
gcc/cfgbuild.o differs
gcc/cfgcleanup.o differs
gcc/cfgexpand.o differs
gcc/cfghooks.o differs
gcc/cfglayout.o differs
gcc/cfgloop.o differs
gcc/cfgloopanal.o differs
gcc/cfgloopmanip.o differs
gcc/cfgrtl.o differs
gcc/cgraph.o differs
gcc/cgraphbuild.o differs
gcc/cgraphunit.o differs
gcc/collect2-aix.o differs
gcc/collect2.o differs
gcc/combine-stack-adj.o differs
gcc/combine.o differs
gcc/convert.o differs
gcc/coverage.o differs
gcc/cp/call.o differs
gcc/cp/class.o differs
gcc/cp/cp-gimplify.o differs
gcc/cp/cp-lang.o differs
gcc/cp/cp-objcp-common.o differs
gcc/cp/cvt.o differs
gcc/cp/cxx-pretty-print.o differs
gcc/cp/decl.o differs
gcc/cp/decl2.o differs
gcc/cp/dump.o differs
gcc/cp/error.o differs
gcc/cp/except.o differs
gcc/cp/expr.o differs
gcc/cp/friend.o differs
gcc/cp/init.o differs
gcc/cp/lex.o differs
gcc/cp/mangle.o differs
gcc/cp/method.o differs
gcc/cp/name-lookup.o differs
gcc/cp/optimize.o differs
gcc/cp/parser.o differs
gcc/cp/pt.o differs
gcc/cp/ptree.o differs
gcc/cp/repo.o differs
gcc/cp/rtti.o differs
gcc/cp/search.o differs
gcc/cp/semantics.o differs
gcc/cp/tree.o differs
gcc/cp/typeck.o differs
gcc/cp/typeck2.o differs
gcc/cppdefault.o differs
gcc/cppspec.o differs
gcc/cse.o differs
gcc/cselib.o differs
gcc/darwin-c.o differs
gcc/darwin-driver.o differs
gcc/darwin-f.o differs
gcc/darwin.o differs
gcc/dbgcnt.o differs
gcc/dbxout.o differs
gcc/dce.o differs
gcc/ddg.o differs
gcc/debug.o differs
gcc/df-byte-scan.o differs
gcc/df-core.o differs
gcc/df-problems.o differs
gcc/df-scan.o differs
gcc/dfp.o differs
gcc/diagnostic.o differs
gcc/dojump.o differs
gcc/dominance.o differs
gcc/domwalk.o differs
gcc/double-int.o differs
gcc/driver-rs6000.o differs
gcc/dse.o differs
gcc/dummy-checksum.o differs
gcc/dwarf2asm.o differs
gcc/dwarf2out.o differs
gcc/ebitmap.o differs
gcc/emit-rtl.o differs
gcc/errors.o differs
gcc/et-forest.o differs
gcc/except.o differs
gcc/explow.o differs
gcc/expmed.o differs
gcc/expr.o differs
gcc/final.o differs
gcc/fixed-value.o differs
gcc/fold-const.o differs
gcc/fortran/arith.o differs
gcc/fortran/array.o differs
gcc/fortran/bbt.o differs
gcc/fortran/check.o differs
gcc/fortran/convert.o differs
gcc/fortran/cpp.o differs
gcc/fortran/data.o differs
gcc/fortran/decl.o differs
gcc/fortran/dependency.o differs
gcc/fortran/dump-parse-tree.o differs
gcc/fortran/error.o differs
gcc/fortran/expr.o differs
gcc/fortran/f95-lang.o differs
gcc/fortran/interface.o differs
gcc/fortran/intrinsic.o differs
gcc/fortran/io.o differs
gcc/fortran/iresolve.o differs
gcc/fortran/match.o differs
gcc/fortran/matchexp.o differs
gcc/fortran/misc.o differs
gcc/fortran/module.o differs
gcc/fortran/openmp.o differs
gcc/fortran/options.o differs
gcc/fortran/parse.o differs
gcc/fortran/primary.o differs
gcc/fortran/resolve.o differs
gcc/fortran/scanner.o diff

[Bug bootstrap/41224] [4.5 Regression] Bootstrap broken on powerpc-apple-darwin9 at revision 151318

[dominiq at lps dot ens dot fr]

--- Comment #1 from dominiq at lps dot ens dot fr  2009-09-02 13:15 ---
This is likely due to r151311, hence added Alexandre Oliva in the CC list.


-- 

dominiq at lps dot ens dot fr changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu dot
   ||org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41224

[Bug bootstrap/41224] [4.5 Regression] Bootstrap broken on powerpc-apple-darwin9 at revision 151318

[howarth at nitro dot med dot uc dot edu]

--- Comment #2 from howarth at nitro dot med dot uc dot edu  2009-09-02 
13:33 ---
Does this also effect i*86-apple-darwin* and x86_64-apple-darwin*?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41224

[Bug middle-end/41225] New: VTA: internal compiler error: in vect_stmt_relevant_p, at tree-vect-stmts.c:150

[jv244 at cam dot ac dot uk]

trying '-fvar-tracking-assignments' with current trunk on CP2K, I get the
following ICE:

gfortran -c -fvar-tracking-assignments -O2 -ffast-math -funroll-loops
-ftree-vectorize -march=native -ffree-form -D__GFORTRAN -D__FFTSG -D__FFTW3
-D__LIBINT -I/ext/software/64/gfortran-suite/include
-D__COMPILE_ARCH="\"Linux-x86-64-gfortran\"" -D__COMPILE_DATE="\"Wed Sep  2
15:32:16 CEST 2009\"" -D__COMPILE_HOST="\"pcihopt3\""
-D__COMPILE_LASTCVS="\"/wfn_fitting_methods.F/1.12/Tue Sep  1 16:19:34
2009//\"" /data03/vondele/clean/cp2k/src/../src/hfx_contract_block.F
/data03/vondele/clean/cp2k/src/../src/hfx_contract_block.F: In function
‘block_15_1_1_1’:
/data03/vondele/clean/cp2k/src/../src/hfx_contract_block.F:18231:0: internal
compiler error: in vect_stmt_relevant_p, at tree-vect-stmts.c:150
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

looking for a testcase


-- 
   Summary: VTA: internal compiler error: in vect_stmt_relevant_p,
at tree-vect-stmts.c:150
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41225

[Bug middle-end/41225] VTA: internal compiler error: in vect_stmt_relevant_p, at tree-vect-stmts.c:150

[jv244 at cam dot ac dot uk]

--- Comment #1 from jv244 at cam dot ac dot uk  2009-09-02 13:40 ---
Created an attachment (id=18465)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18465&action=view)
testcase 

compile with:

gfortran -c -fvar-tracking-assignments -O2 -ffast-math -funroll-loops
-ftree-vectorize -march=native PR41225.f90

-v reports:

Target: x86_64-unknown-linux-gnu
Configured with: /data03/vondele/gcc_trunk/gcc/configure --disable-bootstrap
--prefix=/data03/vondele/gcc_trunk/build --enable-languages=c,c++,fortran
--disable-multilib --with-ppl=/data03/vondele/gcc_trunk/build/
--with-cloog=/data03/vondele/gcc_trunk/build/
Thread model: posix
gcc version 4.5.0 20090902 (experimental) [trunk revision 151319] (GCC)
COLLECT_GCC_OPTIONS='-c' '-fvar-tracking-assignments' '-O2' '-ffast-math'
'-funroll-loops' '-ftree-vectorize'  '-v'

/data03/vondele/gcc_trunk/build/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/f951
PR41225.f90 -march=k8-sse3 -mcx16 -msahf --param l1-cache-size=64 --param
l1-cache-line-size=64 --param l2-cache-size=1024 -mtune=k8 -quiet -dumpbase
PR41225.f90 -auxbase PR41225 -O2 -version -fvar-tracking-assignments
-ffast-math -funroll-loops -ftree-vectorize -fintrinsic-modules-path
/data03/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/finclude
-o /tmp/ccvJZHDG.s


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41225

[Bug bootstrap/41224] [4.5 Regression] Bootstrap broken on powerpc-apple-darwin9 at revision 151318

[dominiq at lps dot ens dot fr]

--- Comment #3 from dominiq at lps dot ens dot fr  2009-09-02 13:40 ---
> Does this also effect i*86-apple-darwin* and x86_64-apple-darwin*?

I don't know since I did not updated trunk on my macbook. I am waiting for the
mess be sorted out before doins so.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41224

[Bug middle-end/41225] VTA: internal compiler error: in vect_stmt_relevant_p, at tree-vect-stmts.c:150

[jv244 at cam dot ac dot uk]

--- Comment #2 from jv244 at cam dot ac dot uk  2009-09-02 13:43 ---
reduced testcase:

  SUBROUTINE block_15_1_1_1(kbd,kbc,kad,kac,pbd,pbc,pad,pac,prim,scale)
INTEGER, PARAMETER :: dp=8
REAL(KIND=dp) :: kbd(1*1), kbc(1*1), kad(15*1), kac(15*1), pbd(1*1), &
  pbc(1*1), pad(15*1), pac(15*1), prim(15*1*1*1), scale
INTEGER  :: ma, mb, mc, md, p_index
  DO md = 1,1
DO mc = 1,1
  DO mb = 1,1
DO ma = 1,15
  p_index=p_index+1
  tmp = scale*prim(p_index)
  ks_bd = ks_bd + tmp* pac((mc-1)*15+ma)
END DO
kbd((md-1)*1+mb) = kbd((md-1)*1+mb) - ks_bd
  END DO
END DO
  END DO
  END SUBROUTINE block_15_1_1_1


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41225

[Bug target/41211] internal compiler error when using x86_64-w64-mingw32-gcc to build sqlite3 alter.c

[drangon dot mail at gmail dot com]

--- Comment #7 from drangon dot mail at gmail dot com  2009-09-02 13:48 
---
I recompile the whole toolchain using today's newest code, the same result,
cross compiler runs fine, native compiler runs crash.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41211

[Bug debug/41226] New: [4.5 regression] Revision 151313 caused many regressions on trunk

[hjl dot tools at gmail dot com]

On Linux/ia32, revision 151313 gave:

FAIL: gcc.c-torture/compile/pr40753.c  -O3 -g  (internal compiler error)
FAIL: gcc.c-torture/compile/pr40753.c  -O3 -g  (test for excess errors)
FAIL: gcc.dg/guality/example.c  -O0  (test for excess errors)
FAIL: gcc.dg/guality/example.c  -O1  (test for excess errors)
FAIL: gcc.dg/guality/example.c  -O2  (test for excess errors)
FAIL: gcc.dg/guality/example.c  -O3 -fomit-frame-pointer  (test for excess
errors)
FAIL: gcc.dg/guality/example.c  -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  (test for excess errors)
FAIL: gcc.dg/guality/example.c  -O3 -fomit-frame-pointer -funroll-loops  (test
for excess errors)
FAIL: gcc.dg/guality/example.c  -O3 -g  (test for excess errors)
FAIL: gcc.dg/guality/example.c  -Os  (test for excess errors)
FAIL: gcc.dg/guality/guality.c  -O0  (test for excess errors)
FAIL: gcc.dg/guality/guality.c  -O1  (test for excess errors)
FAIL: gcc.dg/guality/guality.c  -O2  (test for excess errors)
FAIL: gcc.dg/guality/guality.c  -O3 -fomit-frame-pointer  (test for excess
errors)
FAIL: gcc.dg/guality/guality.c  -O3 -g  (test for excess errors)
FAIL: gcc.dg/guality/guality.c  -Os  (test for excess errors)

Revision 151310 is OK.


-- 
   Summary: [4.5 regression] Revision 151313 caused many regressions
on trunk
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41226

[Bug debug/41226] [4.5 regression] Revision 151313 caused many regressions on trunk

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41226

[Bug debug/41226] [4.5 regression] Revision 151313 caused many regressions on trunk

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2009-09-02 14:19 ---
Only pr40753.c is a regression, the rest are new tests.  And guality tests are
very much expected to FAIL when -fvar-tracking-assignments isn't enabled (to be
enabled in SVN today), or if you don't have very latest gdb.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|4.5.0   |---


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41226

[Bug fortran/41227] New: COMMON block, BIND(C) and LTO interoperability issues

[burnus at gcc dot gnu dot org]

There are interoperability issues with
   integer :: single_variable
   COMMON /name/ single_variable
and C. Currently, gfortran generates the equivalent to
   struct { int single_variable }
however - at least with BIND(C) - it should be compatible to
   int single_variable

That's what bind_c_coms.f90/bind_c_coms_driver.c test and which is failing with
-flto on the LTO branch.

See Fortran 2003, "15.3 Interoperation with C global variables":

"A C variable with external linkage interoperates with a common block that has 
 been specified in a BIND statement
(1) if the C variable is of a struct type and the variables that are members of
the common block are interoperable with corresponding components of the
struct type, or
(2) if the common block contains a single variable, and the variable is
interoperable with the C variable."

 * * *

Next question: What should happen without BIND(C)?
Answer: In F2003, "5.5.2.4 Differences between named common and blank common"
one finds:

"A blank common block has the same properties as a named common block, except 
 for the following:  [...]
(2) Named common blocks of the same name shall be of the same size in all 
scoping units of a program in which they appear, but blank common blocks
may be of different sizes."

By construction, blank common names are not accessible from C. Thus from the
standard, one could do the "struct"-less version for named commons and the
"struct" version for blank commons.

I do not know whether there are compatibility issues with old programs;
however, the general advice was to use "struct".

 * * *

I think one should drop some kind of note in the Release Notes and add a few
words about COMMON to
http://gcc.gnu.org/onlinedocs/gfortran/Mixed_002dLanguage-Programming.html

Another huge issue is padding: In C one has - by default - padding, in Fortran
(according to the language standard) not. gfortran uses padding (cf.
-fno-align-commons), however. One probably should exclude the BIND(C) COMMONS
from the -fno-align-commons option and should check that C does exactly the
same padding.

See also PR 41209 for a means to set, e.g., the padding.


-- 
   Summary: COMMON block, BIND(C) and LTO interoperability issues
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41227

[Bug debug/41226] [4.5 regression] Revision 151313 caused many regressions on trunk

[joseph at codesourcery dot com]

--- Comment #2 from joseph at codesourcery dot com  2009-09-02 14:39 ---
Subject: Re:  [4.5 regression] Revision 151313 caused many
 regressions on trunk

On Wed, 2 Sep 2009, jakub at gcc dot gnu dot org wrote:

> Only pr40753.c is a regression, the rest are new tests.  And guality tests are
> very much expected to FAIL when -fvar-tracking-assignments isn't enabled (to 
> be
> enabled in SVN today), or if you don't have very latest gdb.

There is a difference between expected to fail on execution and expected 
to fail to compile.  This bug report is reporting that they are failing to 
compile, and it's only execution that's XFAILed.  What are the "excess 
errors" in the log?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41226

[Bug bootstrap/41228] New: [4.5 regression] Solaris 10/x86 comparison failure after VTA merge

[ro at gcc dot gnu dot org]

After the VTA merge (i.e. as of rev. 151322, bootstrap on i386-pc-solaris2.10
fails since all? object files miscompare between stages 2 and 3.  To
investigate
this, I've rebuild stage2 and stage3 plugin.o with -save-temps. The two .s
files
differ by additional .debug_* sections in stage3, together with many labels
(which shouldn't affect the object files), .loc statements.  This accounts for
a significant size difference between the .o files:

-rw-r--r-- 1 ro gcc 32480 Sep  2 15:18 stage1-gcc/plugin.o
-rw-r--r-- 1 ro gcc  9936 Sep  2 16:29 stage2-gcc/plugin.o
-rw-r--r-- 1 ro gcc 35852 Sep  2 16:29 stage3-gcc/plugin.o

The stage2 plugin.o was built with

/vol/gcc/obj/gcc-4.5.0-20090902/10-gcc/./prev-gcc/xgcc
-B/vol/gcc/obj/gcc-4.5.0-20090902/10-gcc/./prev-gcc/
-B/vol/gcc/i386-pc-solaris2.10/bin/ -B/vol/gcc/i386-pc-solaris2.10/bin/
-B/vol/gcc/i386-pc-solaris2.10/lib/ -isystem
/vol/gcc/i386-pc-solaris2.10/include -isystem
/vol/gcc/i386-pc-solaris2.10/sys-include-c  -g -O2 -gtoggle -DIN_GCC   -W
-Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Werror -Wold-style-definition -Wc++-compat -fno-common
 -DHAVE_CONFIG_H -I. -I. -I/vol/gcc/src/gcc-dist/gcc
-I/vol/gcc/src/gcc-dist/gcc/. -I/vol/gcc/src/gcc-dist/gcc/../include
-I/vol/gcc/src/gcc-dist/gcc/../libcpp/include -I/vol/gcc/include
-I/vol/gcc/include -I/vol/gcc/src/gcc-dist/gcc/../libdecnumber
-I/vol/gcc/src/gcc-dist/gcc/../libdecnumber/dpd -I../libdecnumber   
/vol/gcc/src/gcc-dist/gcc/plugin.c -o plugin.o

the stage3 plugin.o with
/vol/gcc/obj/gcc-4.5.0-20090902/10-gcc/./prev-gcc/xgcc
-B/vol/gcc/obj/gcc-4.5.0-20090902/10-gcc/./prev-gcc/
-B/vol/gcc/i386-pc-solaris2.10/bin/ -B/vol/gcc/i386-pc-solaris2.10/bin/
-B/vol/gcc/i386-pc-solaris2.10/lib/ -isystem
/vol/gcc/i386-pc-solaris2.10/include -isystem
/vol/gcc/i386-pc-solaris2.10/sys-include-c  -g -O2 -DIN_GCC   -W -Wall
-Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Werror -Wold-style-definition -Wc++-compat -fno-common
 -DHAVE_CONFIG_H -I. -I. -I/vol/gcc/src/gcc-dist/gcc
-I/vol/gcc/src/gcc-dist/gcc/. -I/vol/gcc/src/gcc-dist/gcc/../include
-I/vol/gcc/src/gcc-dist/gcc/../libcpp/include -I/vol/gcc/include
-I/vol/gcc/include -I/vol/gcc/src/gcc-dist/gcc/../libdecnumber
-I/vol/gcc/src/gcc-dist/gcc/../libdecnumber/dpd -I../libdecnumber   
/vol/gcc/src/gcc-dist/gcc/plugin.c -o plugin.o

I'm attaching the .i and both .s files for further investigation.

sparc-sun-solaris2.11 bootstrap just broke in the same way.


-- 
   Summary: [4.5 regression] Solaris 10/x86 comparison failure after
VTA merge
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: aoliva at gcc dot gnu dot org
ReportedBy: ro at gcc dot gnu dot org
 GCC build triplet: i386-pc-solaris2.10
  GCC host triplet: i386-pc-solaris2.10
GCC target triplet: i386-pc-solaris2.10


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41228

[Bug bootstrap/41228] [4.5 regression] Solaris 10/x86 comparison failure after VTA merge

[ro at gcc dot gnu dot org]

--- Comment #1 from ro at gcc dot gnu dot org  2009-09-02 14:44 ---
Created an attachment (id=18466)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18466&action=view)
preprocessed plugin.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41228

[Bug bootstrap/41228] [4.5 regression] Solaris 10/x86 comparison failure after VTA merge

[ro at gcc dot gnu dot org]

--- Comment #2 from ro at gcc dot gnu dot org  2009-09-02 14:44 ---
Created an attachment (id=18467)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18467&action=view)
stage2 plugin.s


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41228

[Bug bootstrap/41228] [4.5 regression] Solaris 10/x86 comparison failure after VTA merge

[ro at gcc dot gnu dot org]

--- Comment #3 from ro at gcc dot gnu dot org  2009-09-02 14:45 ---
Created an attachment (id=18468)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18468&action=view)
stage3 plugin.s


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41228

[Bug bootstrap/41224] [4.5 Regression] Bootstrap broken on powerpc-apple-darwin9 at revision 151318

[aoliva at gcc dot gnu dot org]

--- Comment #4 from aoliva at gcc dot gnu dot org  2009-09-02 14:52 ---
Hello, Dominique, thanks for the report.

Would you please run:

  # /path/to/srcdir/contrib/compare-debug --preserve stage[23]-gcc/intl.o

and let me know what it outputs.  Comparing the objdump output for both
.stripped object files would be desirable as well.  I'm wondering whether there
was a failure to strip them, or some compare failure because of the naïve use
of cmp.

If strip won't get object files that would pass compare, then compare-debug
will have to be disabled for this platform.  But maybe there's some simple
work-around, like using the tail&compare compare code that we use elsewhere.

Thanks in advance,


-- 

aoliva at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |aoliva at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-09-02 14:52:13
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41224

[Bug libfortran/41169] [4.5 regression] libgfortran fails to build on Solaris 10+: '_Imaginary_I' undeclared

[ro at gcc dot gnu dot org]

--- Comment #8 from ro at gcc dot gnu dot org  2009-09-02 14:59 ---
Subject: Bug 41169

Author: ro
Date: Wed Sep  2 14:58:50 2009
New Revision: 151331

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151331
Log:
PR libfortran/41169
* inclhack.def (irix_complex): New fix.
(solaris_complex): Likewise.
* fixincl.x: Regenerate.
* tests/base/complex.h [IRIX_COMPLEX_CHECK, SOLARIS_COMPLEX_CHECK]:
New tests.

Modified:
trunk/fixincludes/ChangeLog
trunk/fixincludes/fixincl.x
trunk/fixincludes/inclhack.def
trunk/fixincludes/tests/base/complex.h


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41169

[Bug libfortran/41169] [4.5 regression] libgfortran fails to build on Solaris 10+: '_Imaginary_I' undeclared

[ro at gcc dot gnu dot org]

--- Comment #9 from ro at gcc dot gnu dot org  2009-09-02 15:01 ---
Fixed for 4.5.0.


-- 

ro at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41169

[Bug bootstrap/41224] [4.5 Regression] Bootstrap broken on powerpc-apple-darwin9 at revision 151318

[dominiq at lps dot ens dot fr]

--- Comment #5 from dominiq at lps dot ens dot fr  2009-09-02 15:07 ---
> Would you please run:

[karma] gcc/darwin_buildw% ../_gcc_clean/contrib/compare-debug --preserve
stage2-gcc/intl.o stage3-gcc/intl.o
strip: symbols referenced by relocation entries that can't be stripped in:
/opt/gcc/darwin_buildw/stage2-gcc/intl.o.stripped..
dyld_stub_binding_helper
_setlocale
_libintl_gettext
_libintl_textdomain
_wcswidth
_mbstowcs
_nl_langinfo
_strcasecmp
_libintl_bindtextdomain
_strcmp
strip: symbols referenced by relocation entries that can't be stripped in:
/opt/gcc/darwin_buildw/stage3-gcc/intl.o.stripped..
dyld_stub_binding_helper
_setlocale
_libintl_gettext
_libintl_textdomain
_wcswidth
_mbstowcs
_nl_langinfo
_strcasecmp
_libintl_bindtextdomain
_strcmp
stage2-gcc/intl.o.stripped.. stage3-gcc/intl.o.stripped.. differ: char 23, line
2
stripping off .eh_frame, then retrying
failed to strip off .eh_frame
stage2-gcc/intl.o.stripped.. stage3-gcc/intl.o.stripped.. differ: char 23, line
2
preserving stage2-gcc/intl.o.stripped.. stage3-gcc/intl.o.stripped..

Comparing the outputs of hexdump -C gives the following (I can attach the full
files if needed):

[karma] gcc/darwin_buildw% diff stripd_2 stripd_3
2,5c2,5
< 0010  00 00 00 03 00 00 01 f4  00 00 20 00 00 00 00 01  |..
.|
< 0020  00 00 01 8c 00 00 00 00  00 00 00 00 00 00 00 00 
||
< 0030  00 00 00 00 00 00 00 00  00 00 03 04 00 00 02 10 
||
< 0040  00 00 03 04 00 00 00 07  00 00 00 07 00 00 00 05 
||
---
> 0010  00 00 00 03 00 00 04 e0  00 00 20 00 00 00 00 01  |.. .|
> 0020  00 00 04 78 00 00 00 00  00 00 00 00 00 00 00 00  |...x|
> 0030  00 00 00 00 00 00 00 00  00 00 0f 74 00 00 04 fc  |...t|
> 0040  00 00 0f 74 00 00 00 07  00 00 00 07 00 00 00 10  |...t|
8,80c8,326
< 0070  00 00 00 00 00 00 00 00  00 00 01 f0 00 00 02 10 
||
< 0080  00 00 00 02 00 00 05 14  00 00 00 54 80 00 04 00 
|...T|
< 0090  00 00 00 00 00 00 00 00  5f 5f 63 73 74 72 69 6e 
|__cstrin|
< 00a0  67 00 00 00 00 00 00 00  5f 5f 54 45 58 54 00 00 
|g...__TEXT..|
< 00b0  00 00 00 00 00 00 00 00  00 00 01 f0 00 00 00 48 
|...H|
< 00c0  00 00 04 00 00 00 00 02  00 00 00 00 00 00 00 00 
||
< 00d0  00 00 00 02 00 00 00 00  00 00 00 00 5f 5f 64 61 
|__da|
< 00e0  74 61 00 00 00 00 00 00  00 00 00 00 5f 5f 44 41 
|ta..__DA|
< 00f0  54 41 00 00 00 00 00 00  00 00 00 00 00 00 02 38 
|TA.8|
...
< 0400  00 00 00 00 67 63 63 00  2f 6f 70 74 2f 67 63 63 
|gcc./opt/gcc|
< 0410  2f 67 63 63 34 2e 35 77  2f 73 68 61 72 65 2f 6c 
|/gcc4.5w/share/l|
< 0420  6f 63 61 6c 65 00 00 00  60 00 00 00 27 00 00 00 
|ocale...`...'...|
< 0430  75 74 66 2d 38 00 00 00  75 74 66 38 00 00 00 00 
|utf-8...utf8|
< 0440  e2 80 98 00 e2 80 99 00  00 00 02 1c 00 00 02 1c 
||
< 0450  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 
||
< 0460  3d 60 00 00 85 8b 02 e0  7d 89 03 a6 4e 80 04 20  |=`..}...N..
|
< 0470  3d 60 00 00 85 8b 02 e4  7d 89 03 a6 4e 80 04 20  |=`..}...N..
|
< 0480  3d 60 00 00 85 8b 02 e8  7d 89 03 a6 4e 80 04 20  |=`..}...N..
|
< 0490  3d 60 00 00 85 8b 02 ec  7d 89 03 a6 4e 80 04 20  |=`..}...N..
|
< 04a0  3d 60 00 00 85 8b 02 f0  7d 89 03 a6 4e 80 04 20  |=`..}...N..
|
< 04b0  3d 60 00 00 85 8b 02 f4  7d 89 03 a6 4e 80 04 20  |=`..}...N..
|
< 04c0  3d 60 00 00 85 8b 02 f8  7d 89 03 a6 4e 80 04 20  |=`..}...N..
|
< 04d0  3d 60 00 00 85 8b 02 fc  7d 89 03 a6 4e 80 04 20  |=`..}...N..
|
< 04e0  3d 60 00 00 85 8b 03 00  7d 89 03 a6 4e 80 04 20  |=`..}...N..
|
< 04f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 
||
---
> 0070  00 00 00 00 00 00 00 00  00 00 01 f0 00 00 04 fc  ||
> 0080  00 00 00 02 00 00 14 70  00 00 00 54 80 00 04 00  |...p...T|
> 0090  00 00 00 00 00 00 00 00  5f 5f 64 65 62 75 67 5f  |__debug_|
> 00a0  66 72 61 6d 65 00 00 00  5f 5f 44 57 41 52 46 00  |frame...__DWARF.|
> 00b0  00 00 00 00 00 00 00 00  00 00 01 f0 00 00 00 88  ||
> 00c0  00 00 06 ec 00 00 00 02  00 00 17 10 00 00 00 02  ||
> 00d0  02 00 00 00 00 00 00 00  00 00 00 00 5f 5f 64 65  |__de|
> 00e0  62 75 67 5f 69 6e 66 6f  00 00 00 00 5f 5f 44 57  |bug_info__DW|
> 00f0  41 52 46 00 00 00 00 00  00 00 00 00 00 00 02 78  |ARFx|
> 0100  00 00 05 fa 00 00 07 74  00 00 00 00 00 00 17 20  |...t... |
...
> 1400  85 8b 0f 60 7d 89 03 a6  4e 80 04 20 3d 60 00 00  |...`}...N.. =`..|
> 1410  85 8b 0f 64 7d 89 03 a6  4e 80 04 20 3d 60 00 00  |...d}...N.. =`..|
> 1420  85 8b 0f 68 7d 89 03 a6  4e 80 04 20 3d 60 00 00  |...h}...N.. =`..|
> 1430  85 8

[Bug bootstrap/41228] [4.5 regression] Solaris 10/x86 comparison failure after VTA merge

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2009-09-02 15:14 ---
bootstrap-debug intentionally compares (stripped) -g compiled objects with
(stripped) -g0 compiled objects.
Please provide info requested in:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41224#c4


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu dot
   ||org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41228

[Bug bootstrap/41224] [4.5 Regression] Bootstrap broken on powerpc-apple-darwin9 at revision 151318

[aoliva at gcc dot gnu dot org]

--- Comment #6 from aoliva at gcc dot gnu dot org  2009-09-02 15:22 ---
Thanks.  Clearly stripping like that isn't going to be enough, and it's not
just a matter of skipping a few initial bytes with a timestamp or somesuch.

Oh well...  Back to the drawing board.  Unless we can find some way to get the
same object file out of compilations with and without -g, this platform (and
possibly others) will have to make do with the more expensive -fcompare-debug
:-(

Now I'm trying to figure out how to test whether this works.  Like, ideally we
should perform a compile-and-compare test using the stage1 compiler in order to
decide what flags to use for the stage2 and stage3 by default.

Meanwhile, please override the build with "BUILD_CONFIG=". 
config/bootstrap-debug-lean.mk should probably be tweaked to not do -gtoggle or
compare-debug, so that it adds to config/bootstrap-debug.mk, rather than
duplicating it in a way that would fail on darwin too.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41224

[Bug bootstrap/41228] [4.5 regression] Solaris 10/x86 comparison failure after VTA merge

[ro at techfak dot uni-bielefeld dot de]

--- Comment #5 from ro at techfak dot uni-bielefeld dot de  2009-09-02 
15:25 ---
Subject: Re:  [4.5 regression] Solaris 10/x86 comparison failure after VTA
merge

jakub at gcc dot gnu dot org writes:

> bootstrap-debug intentionally compares (stripped) -g compiled objects with
> (stripped) -g0 compiled objects.
> Please provide info requested in:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41224#c4

r...@zingana 192 > /vol/gcc/src/gcc-dist/contrib/compare-debug --preserve
stage[23]-gcc/plugin.o
stage2-gcc/plugin.o.stripped. stage3-gcc/plugin.o.stripped. differ: char 33,
line 1
preserving stage2-gcc/plugin.o.stripped. stage3-gcc/plugin.o.stripped.

objdump -s output is identical, but e.g. objdump -h output differs
considerably, though only in file offsets:

--- stage2-gcc/plugin.o.stripped.objdump2009-09-02 17:23:20.999895800
+0200
+++ stage3-gcc/plugin.o.stripped.objdump2009-09-02 17:23:23.631184000
+0200
@@ -1,19 +1,19 @@

-stage2-gcc/plugin.o.stripped: file format elf32-i386
+stage3-gcc/plugin.o.stripped: file format elf32-i386

 Sections:
 Idx Name  Size  VMA   LMA   File off  Algn
   0 .text 0ce9      0034  2**2
   CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
-  1 .data 0078      0d20  2**5
+  1 .data 0078      12a0  2**5
   CONTENTS, ALLOC, LOAD, RELOC, DATA
-  2 .bss  003c      0da0  2**5
+  2 .bss  003c      13a0  2**5
   ALLOC
-  3 .rodata.str1.1 019e      0da0  2**0
+  3 .rodata.str1.1 019e      13a0  2**0
   CONTENTS, ALLOC, LOAD, READONLY, DATA
-  4 .rodata.str1.4 0338      0f40  2**2
+  4 .rodata.str1.4 0338      1540  2**2
   CONTENTS, ALLOC, LOAD, READONLY, DATA
-  5 .rodata   01b3      1280  2**5
+  5 .rodata   01b3      1880  2**5
   CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
-  6 .comment  0042      1433  2**0
+  6 .comment  0042      1b04  2**0
   CONTENTS, READONLY

Let me know what else you need from objdump.

Rainer


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41228

[Bug target/40977] Problem with code like this: res = ((uint64_t)resh << 32) | resl;

[ami_stuff at o2 dot pl]

--- Comment #3 from ami_stuff at o2 dot pl  2009-09-02 15:32 ---
GCC 4.5.0 (20090827) - additional move.l compared to GCC 4.4.2 (20090825):

#NO_APP
.text
.even
.globl  _MUL64
_MUL64:
movem.l #16128,-(sp)
move.l 28(sp),a0
move.l 32(sp),a1
#APP
;# 45 "2.c" 1
| Inlined umul_ppmm
move.l a0,d0
move.l a1,d1
move.l d0,d2
swapd0
move.l d1,d3
swapd1
move.w d2,d4
mulud3,d4
mulud1,d2
mulud0,d3
mulud0,d1
move.l d4,d0
eor.w  d0,d0
swapd0
add.l  d0,d2
add.l  d3,d2
jcc 1f
add.l  #65536,d1
1:  swapd2
moveq   #0,d0
move.w d2,d0
move.w d4,d2
move.l d2,d6
add.l  d1,d0
move.l d0,d5
#NO_APP
move.l d5,d2
tst.l a0
jge L2
sub.l a1,d2
L2:
tst.l a1
jge L3
sub.l a0,d2
L3:
move.l d2,d0
clr.l d1
move.l d0,d2
move.l d1,d3
or.l d6,d3
move.l d2,d6
move.l d3,d7
move.l d2,d0
move.l d7,d1
movem.l (sp)+,#252
rts


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40977

[Bug target/41095] 4x bigger object when compiled with -O3 option

[ami_stuff at o2 dot pl]

--- Comment #7 from ami_stuff at o2 dot pl  2009-09-02 15:42 ---
GCC 4.5.0 (20090827): 888KB


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41095

[Bug tree-optimization/41112] [4.5 regression] ACATS c43205b fails at -O2 (tree-sra)

[jamborm at gcc dot gnu dot org]

--- Comment #2 from jamborm at gcc dot gnu dot org  2009-09-02 15:54 ---
(In reply to comment #0)
I was able to re-produce and fix the error using the reduced test
case but the testcase given in the description - c43205b - does not
fail for me anywhere.

> 
> Looks like the new SRA is not fully prepared to handle arrays with
> non-constant bounds for its TYPE_DOMAIN.
> 

Right.  The following patch will stop SRA from looking at such
arrays.  After this gets in, can you please add the reduced test case
to the test suite?  I am not sure where (and exactly how) to put it.
Thanks.



2009-09-02  Martin Jambor  

* tree-sra.c (type_internals_preclude_sra_p): Disqualify array
types with non-constant domain bounds.

Index: mine/gcc/tree-sra.c
===
--- mine.orig/gcc/tree-sra.c
+++ mine/gcc/tree-sra.c
@@ -548,6 +548,8 @@ type_internals_preclude_sra_p (tree type
   return false;

 case ARRAY_TYPE:
+  if (TREE_CODE (TYPE_MIN_VALUE (TYPE_DOMAIN (type))) != INTEGER_CST)
+   return false;
   et = TREE_TYPE (type);

   if (AGGREGATE_TYPE_P (et))


-- 

jamborm at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jamborm at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-09-02 15:54:58
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41112

[Bug bootstrap/41224] [4.5 Regression] Bootstrap broken on powerpc-apple-darwin9 at revision 151318

[dominiq at lps dot ens dot fr]

--- Comment #7 from dominiq at lps dot ens dot fr  2009-09-02 16:11 ---
I had a look at contrib/compare-debug: neither 'objcopy' nor 'strip --help'
works on darwin.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41224

[Bug regression/41188] move_invariant_reg() damages CBRANCH instructions with CLOBBER attribute

[shcherbakov at daad-alumni dot de]

--- Comment #9 from shcherbakov at daad-alumni dot de  2009-09-02 16:12 
---
> This change is incorrect because a register ceases to be a loop invariant
> if it is clobbered.

Agreed. Tested your patch. Works fine for me.

Is there any way to know, from which version will the patch be included in gcc
releases?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41188

[Bug rtl-optimization/24319] [4.3/4.4/4.5 regression] amd64 register spill error with -fschedule-insns

[vmakarov at redhat dot com]

--- Comment #19 from vmakarov at redhat dot com  2009-09-02 16:14 ---
  As I wrote, implementing register pressure-sensitive insn scheduling needs to
look at all insns (ready or not) with resolved dependencies.  In an extreme
cases, such insns could b 10-100 more than the ready ones.  Scheduling
algorithm in gcc has at best Nlog(N) complexity where N is #insn with resolved
dependencies but probably it is even worse.

  I could try to make some constraints on # of considered insns.

  I guess you should submit a new bug when the patch will be in the trunk.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24319

[Bug bootstrap/41224] [4.5 Regression] Bootstrap broken on powerpc-apple-darwin9 at revision 151318

[howarth at nitro dot med dot uc dot edu]

--- Comment #8 from howarth at nitro dot med dot uc dot edu  2009-09-02 
16:15 ---
(In reply to comment #7)
> I had a look at contrib/compare-debug: neither 'objcopy' nor 'strip --help'
> works on darwin.
> 

I'll test gcc trunk on x86_64-apple-darwin10 tonight to make sure that we don't
have better luck with the newer linker in Xcode 3.2 or that this linker issue
isn't architecture specific.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41224

[Bug bootstrap/41228] [4.5 regression] Solaris 10/x86 comparison failure after VTA merge

[aoliva at gcc dot gnu dot org]

--- Comment #6 from aoliva at gcc dot gnu dot org  2009-09-02 16:18 ---
Thanks, Rainer.  Could I ask for your help in coming up with a minimal testcase
that, compiled with both -g and -g0, fails the contrib/compare-debug test?  I
see no other alternative than to test whether something like that stands a
chance of working before setting out to build stage2 with -gtoggle.  Thanks in
advance,


-- 

aoliva at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-09-02 16:18:54
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41228

[Bug regression/41188] move_invariant_reg() damages CBRANCH instructions with CLOBBER attribute

[amylaar at gcc dot gnu dot org]

--- Comment #10 from amylaar at gcc dot gnu dot org  2009-09-02 16:22 
---
(In reply to comment #9)
> Is there any way to know, from which version will the patch be included in gcc
> releases?

If a patch is installed with a suitable PR marker in the log entry, you will
get notification via this PR.
At any rate, this bug should not be closed till it is fixed in mainline, and
again, you will be notified when this PR changes state.  You can then check
http://gcc.gnu.org/develop.html#timeline what the current development plans
are.  Note, although patches generally have to be installed in mainline first,
that does not automatically mean that they will be installed in active release
branches; they have to be approved specifically for each branch before they
can be installed/backported there.
Not all patches that could be installed/backported in release branches
actually are, depending on what the priorities for the release and the
imact assessment of the patch is.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41188

[Bug bootstrap/41224] [4.5 Regression] Bootstrap broken on powerpc-apple-darwin9 at revision 151318

[aoliva at gcc dot gnu dot org]

--- Comment #9 from aoliva at gcc dot gnu dot org  2009-09-02 16:23 ---
Thanks, Dominique.  These won't matter, they only help if .eh_frame is the only
difference.  Would you please help Rainer in bug 41228 come up with a testcase
that, compiled with -g and -g0, will fail the compare-debug test?  This will
enable us to perform some configure-time test on whether or not to enable
bootstrap-debug.  Thanks in advance,


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41224

[Bug bootstrap/41228] [4.5 regression] Solaris 10/x86 comparison failure after VTA merge

[ro at techfak dot uni-bielefeld dot de]

--- Comment #7 from ro at techfak dot uni-bielefeld dot de  2009-09-02 
16:30 ---
Subject: Re:  [4.5 regression] Solaris 10/x86 comparison failure after VTA
merge

aoliva at gcc dot gnu dot org writes:

> Thanks, Rainer.  Could I ask for your help in coming up with a minimal 
> testcase
> that, compiled with both -g and -g0, fails the contrib/compare-debug test?  I
> see no other alternative than to test whether something like that stands a
> chance of working before setting out to build stage2 with -gtoggle.  Thanks in
> advance,

Sure: I obviously care about Solaris (and IRIX and Tru64 UNIX :-), and even
a minimal hello.c fails the test:

r...@zingana 218 > cat hello.c
int
main (void)
{
  return 0;
}
r...@zingana 219 > ./xgcc -B./ -g0 -c hello.c -o hello-g0.o
r...@zingana 220 > ./xgcc -B./ -g -c hello.c -o hello-g.o
r...@zingana 221 > /vol/gcc/src/gcc-dist/contrib/compare-debug --preserve
hello-g0.o hello-g.o
hello-g0.o.stripped. hello-g.o.stripped. differ: char 33, line 1
preserving hello-g0.o.stripped. hello-g.o.stripped.
r...@zingana 222 > ls -l hello*.o*
-rw-r--r-- 1 ro gcc 1964 Sep  2 18:23 hello-g.o
-rw-r--r-- 1 ro gcc  884 Sep  2 18:21 hello-g.o.stripped
-rw-r--r-- 1 ro gcc  884 Sep  2 18:23 hello-g.o.stripped.
-rw-r--r-- 1 ro gcc  630 Sep  2 18:23 hello-g0.o
-rw-r--r-- 1 ro gcc  630 Sep  2 18:21 hello-g0.o.stripped
-rw-r--r-- 1 ro gcc  630 Sep  2 18:23 hello-g0.o.stripped.

Rainer


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41228

[Bug bootstrap/41224] [4.5 Regression] Bootstrap broken on powerpc-apple-darwin9 at revision 151318

[dominiq at lps dot ens dot fr]

--- Comment #10 from dominiq at lps dot ens dot fr  2009-09-02 16:39 ---
For the hello test in comment #7 of pr41228 I get:

[karma] gcc/darwin_buildw% ../_gcc_clean/contrib/compare-debug --preserve
hello-g0.o hello-g.o
hello-g0.o.stripped hello-g.o.stripped differ: char 23, line 2
stripping off .eh_frame, then retrying
failed to strip off .eh_frame
hello-g0.o.stripped hello-g.o.stripped differ: char 23, line 2
preserving hello-g0.o.stripped hello-g.o.stripped


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41224

[Bug rtl-optimization/24319] [4.3/4.4/4.5 regression] amd64 register spill error with -fschedule-insns

[lucier at math dot purdue dot edu]

--- Comment #20 from lucier at math dot purdue dot edu  2009-09-02 16:52 
---
Vlad:

Thank you for your reply.

The times I reported are for "-fschedule-insns" without "-fpressure-sched".

The times with the addition of "-fpressure-sched" are not much greater than
with "-fschedule-insns" by itself:

With -fschedule-insns

 scheduling:  22.89 (41%) usr   0.02 ( 2%) sys  22.93 (40%) wall   
2125 kB ( 1%) ggc
 integrated RA :   9.15 (16%) usr   0.06 ( 6%) sys   9.21 (16%) wall   
5488 kB ( 3%) ggc
 scheduling 2  :   0.60 ( 1%) usr   0.00 ( 0%) sys   0.62 ( 1%) wall   
 422 kB ( 0%) ggc
 TOTAL :  55.67 0.9356.66
180793 kB

with -fschedule-insns -fsched-pressure

 scheduling:  23.31 (42%) usr   0.02 ( 2%) sys  23.36 (41%) wall   
2125 kB ( 1%) ggc
 integrated RA :   9.18 (16%) usr   0.04 ( 4%) sys   9.22 (16%) wall   
5517 kB ( 3%) ggc
 scheduling 2  :   0.58 ( 1%) usr   0.01 ( 1%) sys   0.58 ( 1%) wall   
 251 kB ( 0%) ggc
 TOTAL :  55.77 1.0056.89
179606 kB

and with neither -fschedule-insns nor -fsched-pressure:

 integrated RA :   6.40 (21%) usr   0.05 ( 5%) sys   6.41 (21%) wall   
5087 kB ( 3%) ggc
 scheduling 2  :   0.58 ( 2%) usr   0.01 ( 1%) sys   0.60 ( 2%) wall   
 244 kB ( 0%) ggc
 TOTAL :  29.84 0.9830.83
176587 kB

So pre--register allocation instruction scheduling even without the new
register pressure--aware algorithm takes quite a bit of time.

I'll try to build a profiled gcc, and then if I find something I'll put it in a
new PR.

Brad


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24319

[Bug rtl-optimization/24319] [4.3/4.4/4.5 regression] amd64 register spill error with -fschedule-insns

[vmakarov at redhat dot com]

--- Comment #21 from vmakarov at redhat dot com  2009-09-02 17:11 ---
I see.  I though you compared '-fschedule-insns' and '-fschedule-insns
-fsched-pressure'.

Your numbers shows the same as I reported for SPEC2000.  The -fsched-pressure
adds upto 3% compiler time (for power6) on x86 and x86_64 it is practically the
same time (although -fsched-pressure does more job, it is compensated by
smaller # of insns after RA).

I did not analyzed your code but I think your code is quite specific and
probably has a lot of parallelism which creates long ready and queue list.  You
could play with param max-pending-list-length to see will it help.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24319

[Bug bootstrap/41228] [4.5 regression] Solaris 10/x86 comparison failure after VTA merge

[jakub at gcc dot gnu dot org]

--- Comment #8 from jakub at gcc dot gnu dot org  2009-09-02 17:21 ---
If Solaris strip reorders the sections, I'm afraid either we have to compare
one section by one, or somehow force them to be reordered in the same order, or
give up on bootstrap-debug on Solaris when not using GNU ld/strip.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41228

[Bug rtl-optimization/24319] [4.3/4.4/4.5 regression] amd64 register spill error with -fschedule-insns

[lucier at math dot purdue dot edu]

--- Comment #22 from lucier at math dot purdue dot edu  2009-09-02 17:24 
---
The output of gprof on this example is at

http://www.math.purdue.edu/~lucier/bugzilla/11/gprof.out.gz

Everything that takes more than a second is

Each sample counts as 0.01 seconds.
  %   cumulative   self  self total   
 time   seconds   secondscalls   s/call   s/call  name
 10.73  4.45 4.4515565 0.00 0.00  pop_scope
  7.28  7.47 3.02 314259938 0.00 0.00  free_list
  7.04 10.39 2.92 5575 0.00 0.00  dfs_enumerate_from
  5.62 12.72 2.33 314988148 0.00 0.00  alloc_INSN_LIST
  5.28 14.91 2.19 5292 0.00 0.00  get_loop_exit_edges
  5.14 17.04 2.13 331244515 0.00 0.00  bitmap_set_bit
  3.28 18.40 1.36   135329 0.00 0.00  sched_analyze_insn
  3.09 19.68 1.2829650 0.00 0.00  free_deps
  2.75 20.82 1.14 21773210 0.00 0.00  bitmap_bit_p
  2.35 21.80 0.98 14093247 0.00 0.00  dominated_by_p
  1.99 22.62 0.83  5357385 0.00 0.00  bitmap_ior_into
  1.88 23.40 0.78  199 0.00 0.00 
inverted_post_order_compute
  1.57 24.05 0.65  342 0.00 0.01  df_worklist_dataflow
  1.37 24.62 0.57 51278357 0.00 0.00  decl_jump_unsafe
  1.35 25.18 0.56 26181017 0.00 0.00  flow_bb_inside_loop_p
  1.13 25.65 0.47  201 0.00 0.00  post_order_compute

Nothing immediate jumps out at me.

Brad


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24319

[Bug c++/41214] [4.5 regression] Null pointer dereferenced in _Unwind_SetGR()

[d dot g dot gorbachev at gmail dot com]

--- Comment #3 from d dot g dot gorbachev at gmail dot com  2009-09-02 
17:24 ---
a testcase:

int main(void) { try { throw 0; } catch (int) { } return 0; }

About analysis, it will take some time. I think it is better to file a bug
right away then to wait results.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41214

[Bug bootstrap/41224] [4.5 Regression] Bootstrap broken on powerpc-apple-darwin9 at revision 151318

[mrs at apple dot com]

--- Comment #11 from mrs at apple dot com  2009-09-02 17:41 ---
dwarfdump exists on 10.5 and 10.6.  Not sure if that would help at all (I've
not been following what people are doing).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41224

[Bug tree-optimization/40744] SRA scalarizes dead objects, single-use objects

[jamborm at gcc dot gnu dot org]

--- Comment #8 from jamborm at gcc dot gnu dot org  2009-09-02 18:03 ---
Hi,

I have committed the patch as revision 151345 after another
bootstrap/testing.  Unfortunately I forgot to annotate them with this
PR number in the change log and so the commits did not appear here
automatically.  I will try to remember the next time.

Thus, this should be fixed.


-- 

jamborm at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40744

[Bug middle-end/41229] New: VTA: internal compiler error: verify_ssa failed

[jv244 at cam dot ac dot uk]

current trunk:

> gfortran -cpp -c -fvar-tracking-assignments -O2 bug.f90
bug.f90: In function ‘cp_fm_triangular_multiply’:
bug.f90:1:0: error: expected an SSA_NAME object
bug.f90:1:0: error: in statement
# DEBUG istat => stat.0
bug.f90:1:0: internal compiler error: verify_ssa failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


> cat bug.f90
SUBROUTINE cp_fm_triangular_multiply()
INTEGER, PARAMETER :: dp=KIND(0.0D0)
REAL(dp), ALLOCATABLE, DIMENSION(:)  :: tau, work
REAL(KIND=dp), DIMENSION(:, :), POINTER  :: a
ndim = SIZE(a,2)
ALLOCATE(tau(ndim),STAT=istat)
ALLOCATE(work(2*ndim),STAT=istat)
END SUBROUTINE


-- 
   Summary: VTA: internal compiler error: verify_ssa failed
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41229

[Bug lto/41230] New: [LTO] Segfault using -flto with -fvar-tracking-assignments

[rmansfield at qnx dot com]

I suppose this PR is a bit premature, but after the VTA merge using
-fvar-tracking-assignments with -flto

$ cat seg.c
void foo() {
  int hex = 0x4;
}
$ ./xgcc -B. seg.c -flto -fvar-tracking-assignments -c
r...@avarice:~/gcc/lto/x86-build/gcc$ ./xgcc -B. seg.o -flto -shared   
In file included from :0:0:
seg.c: In function 'foo':
seg.c:1:6: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper: ././xgcc returned 1 exit status
collect2: lto-wrapper returned 1 exit status


-- 
   Summary: [LTO] Segfault using -flto with -fvar-tracking-
assignments
   Product: gcc
   Version: lto
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rmansfield at qnx dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41230

[Bug lto/41230] [LTO] Segfault using -flto with -fvar-tracking-assignments

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-09-02 19:31 ---
I will have a look.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org
Summary|[LTO] Segfault using -flto  |[LTO] Segfault using -flto
   |with -fvar-tracking-|with -fvar-tracking-
   |assignments |assignments


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41230

[Bug bootstrap/41228] [4.5 regression] Solaris 10/x86 comparison failure after VTA merge

[howarth at nitro dot med dot uc dot edu]

--- Comment #9 from howarth at nitro dot med dot uc dot edu  2009-09-02 
19:54 ---
(In reply to comment #8)
> If Solaris strip reorders the sections, I'm afraid either we have to compare
> one section by one, or somehow force them to be reordered in the same order, 
> or
> give up on bootstrap-debug on Solaris when not using GNU ld/strip.
> 

I wonder if this could be the same reason that the comparison of stage2 and
stage3
fails on powerpc-apple-darwin9 (PR41224)?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41228

[Bug bootstrap/41224] [4.5 Regression] Bootstrap broken on powerpc-apple-darwin9 at revision 151318

[howarth at nitro dot med dot uc dot edu]

--- Comment #12 from howarth at nitro dot med dot uc dot edu  2009-09-02 
19:57 ---
(In reply to comment #11)
> dwarfdump exists on 10.5 and 10.6.  Not sure if that would help at all (I've
> not been following what people are doing).
> 

Mike,
   Can you find out if the darwin's strip reorders the sections? This seems to
by why Solaris's comparison of stage2 and stage3 is failing (PR41228)? If so
is there an option to suppress the reordering?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41224

[Bug lto/41230] [LTO] Segfault using -flto with -fvar-tracking-assignments

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-09-02 20:13 ---
You need to include -fvar-tracking-assignments in the final link as well.  I
guess we need to either special-case it or drop debug stmts on stream-in if
-fvta is not set.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-09-02 20:13:39
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41230

[Bug bootstrap/41224] [4.5 Regression] Bootstrap broken on powerpc-apple-darwin9 at revision 151318

[mrs at apple dot com]

--- Comment #13 from mrs at apple dot com  2009-09-02 20:17 ---
Subject: Re:  [4.5 Regression] Bootstrap broken on powerpc-apple-darwin9 at
revision 151318

On Sep 2, 2009, at 12:57 PM, howarth at nitro dot med dot uc dot edu  
wrote:
> --- Comment #12 from howarth at nitro dot med dot uc dot edu   
> 2009-09-02 19:57 ---
> (In reply to comment #11)
>> dwarfdump exists on 10.5 and 10.6.  Not sure if that would help at  
>> all (I've
>> not been following what people are doing).
>
> Can you find out if the darwin's strip reorders the sections? This  
> seems to
> by why Solaris's comparison of stage2 and stage3 is failing  
> (PR41228)? If so
> is there an option to suppress the reordering?

No option.  I suspect it can.  You should be able to run otool and  
print the sections out.  As I recall, the order printed, is the order  
in the file.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41224

[Bug bootstrap/41228] [4.5 regression] Solaris 10/x86 comparison failure after VTA merge

[dominiq at lps dot ens dot fr]

--- Comment #10 from dominiq at lps dot ens dot fr  2009-09-02 20:27 ---
> I wonder if this could be the same reason that the comparison of stage2 
> and stage3 fails on powerpc-apple-darwin9 (PR41224)?

I don't think so, strip (if it does anything) is leaving DWARF stuff in the *.o
files.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41228

[Bug lto/41230] [LTO] Segfault using -flto with -fvar-tracking-assignments

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-09-02 20:30 ---
Hmm, dropping the stmt looks like it would be a "hack".  Alex - if I just set
flag_var_tracking_assignments to 1 if I encounter a GIMPLE_DEBUG during read-in
I get

t.c: In function 'foo':
t.c:1:6: error: unrecognizable insn:
(debug_insn 6 5 14 t.c:3 (var_location:SI hex (mem/c/i:SI (plus:SI (reg/f:SI 20
frame)
(const_int -4 [0xfffc])) [0 hex+0 S4 A32])) -1 (nil))
t.c:1:6: internal compiler error: in insn_default_length, at
config/i386/i386.md:544
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

is there sth else that I need to do to "enable" VTA?


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu dot
   ||org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41230

[Bug lto/41230] [LTO] Segfault using -flto with -fvar-tracking-assignments

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2009-09-02 20:34 ---
Dropping the stmts works for at least the testcase, but it looks ugly.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41230

[Bug bootstrap/41180] can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6

[mrs at apple dot com]

--- Comment #21 from mrs at apple dot com  2009-09-02 20:37 ---
The patch in #19 is wrong.  If you configure a x86->ppc64 compile, it would
want to use -m32, which is wrong.  We experimented with a change like that in
#20 and it resulted in failures; I can't imagine any good coming from it.  In
short, CC isn't a variable that can be changed here, like this, only
tentative_cc can be.  I don't know what these two bits are trying to fix, so, I
can't say what the right solution is.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41180

[Bug lto/41230] [LTO] Segfault using -flto with -fvar-tracking-assignments

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2009-09-02 20:55 ---
Note that in general you have to repeat all options on the link command line,
otherwise you are building with -O0 there.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41230

[Bug bootstrap/41180] can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6

[howarth at nitro dot med dot uc dot edu]

--- Comment #23 from howarth at nitro dot med dot uc dot edu  2009-09-02 
21:44 ---
I should clarify that the proposed change in comment 20 only triggers if the
host is x86_64-apple-darwin* (which would be the case once the config,guess
change goes in) and will in that case only add -m32 to the options if the
target matches i[[3456789]]86-*-darwin*. I don't see how that would
accidentally trigger on any other cross compiles.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41180

[Bug rtl-optimization/41171] register allocator undoing optimal schedule

[bergner at gcc dot gnu dot org]

--- Comment #6 from bergner at gcc dot gnu dot org  2009-09-02 21:47 ---
My patch solved the problem, but was very very neutral wrt SPEC2000 scores. 
Vlad's idea of moving update_equiv_regs() into its own pass before sched1 makes
sense to me and seems to produce better performing code too, so his patch wins.
:)  Thanks Vlad.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41171

[Bug libstdc++/41220] [4.5 Regression] Make clean; make; make check doesn't work fine anymore

[rwild at gcc dot gnu dot org]

--- Comment #1 from rwild at gcc dot gnu dot org  2009-09-02 21:55 ---
patch at .

BTW, please don't use "Subject says it all" messages, the subject may be
changed in a bug report, that makes it difficult for later readers.  Thanks.


-- 

rwild at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rwild at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-09-02 21:55:16
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41220

[Bug bootstrap/41180] can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6

[howarth at nitro dot med dot uc dot edu]

--- Comment #22 from howarth at nitro dot med dot uc dot edu  2009-09-02 
21:41 ---
Mike,
  The fix in comment 20 originated from your email to me...

>On Aug 28, 2009, at 8:48 AM, Jack Howarth wrote:
>>   Can you take a look at PR41180 (specifically
>> comment 9). I think we should propose a configure
>> change for gcc 4.4.2 and trunk that utilizes
>> 'sysctl -n hw.cpu64bit_capable' on darwin10 to
>> set the triplet to x86_64-apple-darwin10 instead
>> of i386-apple-darwin10 as is blindly done now.
>> I am rather unfamilar with configure and was
>> hoping you might have some suggestions on how
>> this should be best done.
>
>Just fix config.guess to say x86_64-apple-darwin10, if `$CC t.c && file
>a.out` == x86_64.
>That gets most of it.  Besides that, when targetting i686-apple-darwin,
>$(CC) -m32 should be used, see:
>
>  # APPLE LOCAL begin dynamic-no-pic
>  i[[3456789]]86-*-darwin*)
>host_makefile_frag="config/mh-x86-darwin"
># gcc can default to x86_64 code generation, avoid that
>if test "${build}" = "${host}"; then
>  CC="${CC-gcc} -m32"
>fi
>;;
>  # APPLE LOCAL end dynamic-no-pic
>
>from configure.in.
>

You neglected to consider in the recommendation for the configure.(in/ac)
change that the config.guess patch would change the case section where
the -m32 option would be needed. The current config.guess will always
report i386-apple-darwin whereas the proposed config.guess change would
tether the processor name to the actual default code generation/execution
which is properly x86_64 on darwin10. This means that the -m32 option would
be applied in the x86_64 match of the case statement and only if the target
was i[3456789]86-*-darwin*. So I don't understand how it could cause problems
since it only triggers the addition of -m32 for i[3456789]86 targets.
   I did try substituting tentative_cc but I believe that wasn't causing -m32
to be used in the configure tests (but I'll revisit that issue). Outside of
changing CC to tentative_cc, I think that the logic of the patch proposed
in Comment 20 is correct but ONLY after the config.guess change proposed in
http://gcc.gnu.org/ml/gcc-patches/2009-09/msg00087.html is accepted upstream.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41180

[Bug libstdc++/41220] [4.5 Regression] Make clean; make; make check doesn't work fine anymore

[paolo dot carlini at oracle dot com]

--- Comment #2 from paolo dot carlini at oracle dot com  2009-09-02 22:03 
---
Thanks for fixing this small but annoying issue. By the way, my subjects are
perfect as they are, thus your point is moot ;)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41220

[Bug libstdc++/41220] [4.5 Regression] Make clean; make; make check doesn't work fine anymore

[rwild at gcc dot gnu dot org]

--- Comment #3 from rwild at gcc dot gnu dot org  2009-09-02 22:03 ---
Subject: Bug 41220

Author: rwild
Date: Wed Sep  2 22:03:32 2009
New Revision: 151351

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151351
Log:
Fix 'make clean' to remove stamp-host file in libstdc++-v3/include.

libstdc++-v3/:
PR libstdc++/41220
* include/Makefile.am (CLEANFILES): Add stamp-host.
* include/Makefile.in: Regenerate.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/Makefile.am
trunk/libstdc++-v3/include/Makefile.in


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41220

[Bug libstdc++/41220] [4.5 Regression] Make clean; make; make check doesn't work fine anymore

[rwild at gcc dot gnu dot org]

--- Comment #4 from rwild at gcc dot gnu dot org  2009-09-02 22:09 ---
Fixed.


-- 

rwild at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41220

[Bug bootstrap/41180] can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6

[howarth at nitro dot med dot uc dot edu]

--- Comment #24 from howarth at nitro dot med dot uc dot edu  2009-09-02 
22:22 ---
We could also add (as a separate patch) a change identical to what Apple uses
in their gcc which only triggers on the  i[[3456789]]86-*-darwin* host and
target but this should be unnecessary after the config.guess change goes in.
After the config.guess change, it would only serve to idiot-proof configure for
the case of someone passing the  i[[3456789]]86-*-darwin10 host on a Snow
Leopard machine that is actually running and generating x86_64 binaries (and
will be identified properly by the patched config.guess as
x86_64-apple-darwin10).


-- 

howarth at nitro dot med dot uc dot edu changed:

   What|Removed |Added

 CC||howarth at nitro dot med dot
   ||uc dot edu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41180

[Bug lto/41230] [LTO] Segfault using -flto with -fvar-tracking-assignments

[rmansfield at qnx dot com]

--- Comment #6 from rmansfield at qnx dot com  2009-09-02 22:50 ---
(In reply to comment #5)
> Note that in general you have to repeat all options on the link command line,
> otherwise you are building with -O0 there.

Yep, I realize that. I just came across this crash by accidentally leaving
-fvar-tracking-assignments off the link line. Improper usage that cause
crashes/ICEs are still worth PRs, right? 

The non-reduced testcase was built with -O2 as well as a number of other
options for compiling/linking but since they didn't effect whether or not the
crash occurred I left them out of the report.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41230

[Bug c++/41231] New: Error when declaring a nested template member class of a dependent template class a friend

[pleexed at gmail dot com]

Hello,

this is my first bug report, so please don't be harsh with me in case i did
something wrong.

I'm on Ubuntu Jaunty i386, with all the packages installed from and updated to
the most recent version of the official repositories. I'm trying to build for
that system too (no cross-compiling).

This is the g++ version I have:
$ g++ --version
g++ (Ubuntu 4.3.2-2ubuntu9) 4.3.3 20081217 (prerelease)
$ g++ -dumpmachine
i486-linux-gnu

And this how I invoke g++:
$ g++ -Wall test.cpp
test.cpp:11: error: expected identifier before ';' token
test.cpp:11: error: friend declaration does not name a class or function

I have distilled the testcase to just a few lines, and saved them to test.cpp.
I'll paste the contents here:
template class Outer
{
public:
template class Inner
{
};
};

template class Friend
{
friend class Outer::template Inner; //line 11
};

I don't see why this code should not compile, and the "tryitout" version of
Comeau compiles this in strict mode, and so does Visual C++ 2008.
Unfortunately, I cannot install any other version of g++ right now, but I have
asked someone with gcc 4.4.x on freenode ##C++ to try to compile that code
snippet, and he had the same result as I had. geordi is a bot in that channel
to which you can send small samples of code to compile, and it says it runs
"g++ (GCC) 4.5.0 20090803 (experimental)". geordi cannot compile that code
either.

Can you please give me some insight into why this code fails to compile with
g++? In any case, be it g++ that is wrong or right in refusing to compile, is
there a workaround I can use to achieve what I need?

I'm happy to assist you should you need further tests or data.


-- 
   Summary: Error when declaring a nested template member class of a
dependent template class a friend
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pleexed at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41231

[Bug bootstrap/41224] [4.5 Regression] Bootstrap broken on powerpc-apple-darwin9 at revision 151318

[howarth at nitro dot med dot uc dot edu]

--- Comment #14 from howarth at nitro dot med dot uc dot edu  2009-09-02 
23:18 ---
I get the same bootstrap failure on x86_64-apple-darwin10. If I diff the output
of dwarfdump on the stage2-zlib/libz_a-zutil.o and stage3-zlib/libz_a-zutil.o
(which showed 'zlib/libz_a-zutil.o differs', I get...

--- libz_a-zutil.o.stage2   2009-09-02 19:10:28.0 -0400
+++ libz_a-zutil.o.stage3   2009-09-02 19:10:12.0 -0400
@@ -2,5 +2,266 @@
  File: libz_a-zutil.o (x86_64)
 --
 .debug_info contents:
-< EMPTY >
+
+0x: Compile Unit: length = 0x02fe  version = 0x0002  abbr_offset =
0x  addr_size = 0x08  (next CU at 0x0302)
+
+0x000b: TAG_compile_unit [1] *
+ AT_producer( "GNU C 4.5.0 20090902 (experimental)" )
+ AT_language( DW_LANG_C89 )
+     AT_name( "../../gcc-4.5-20090902/zlib/zutil.c" )
+ AT_comp_dir(
"/sw/src/fink.build/gcc45-4.4.999-20090902/darwin_objdir/zlib" )
+ AT_low_pc( 0x )
+ AT_high_pc( 0x005d )
+ AT_stmt_list( 0x )
+
+0x00a6: TAG_base_type [2]  
+ AT_byte_size( 0x01 )
+ AT_encoding( DW_ATE_unsigned_char )
+ AT_name( "unsigned char" )
+
+0x00b7: TAG_base_type [2]  
+ AT_byte_size( 0x04 )
+ AT_encoding( DW_ATE_unsigned )
+ AT_name( "unsigned int" )
+
+0x00c7: TAG_typedef [3]  
+ AT_name( "uLong" )
+     AT_decl_file(
"/sw/src/fink.build/gcc45-4.4.999-20090902/gcc-4.5-20090902/zlib/zconf.h" )
+ AT_decl_line( 264 )
+ AT_type( {0x00d5} ( long unsigned int ) )
+
+0x00d5: TAG_base_type [2]  
+ AT_byte_size( 0x08 )
+ AT_encoding( DW_ATE_unsigned )
+ AT_name( "long unsigned int" )
+
+0x00ea: TAG_base_type [2]  
+ AT_byte_size( 0x01 )
+ AT_encoding( DW_ATE_signed_char )
+ AT_name( "char" )
+
+0x00f2: TAG_base_type [2]  
+ AT_byte_size( 0x04 )
+ AT_encoding( DW_ATE_signed )
+ AT_name( "int" )
+
+0x00f9: TAG_typedef [3]  
+ AT_name( "voidpf" )
+ AT_decl_file(
"/sw/src/fink.build/gcc45-4.4.999-20090902/gcc-4.5-20090902/zlib/zconf.h" )
+ AT_decl_line( 279 )
+ AT_type( {0x0108} ( * ) )
+
+0x0108: TAG_pointer_type [4]  
+ AT_byte_size( 0x08 )
+
+0x010a: TAG_base_type [2]  
+ AT_byte_size( 0x08 )
+ AT_encoding( DW_ATE_signed )
+ AT_name( "long int" )
+
+0x0116: TAG_base_type [2]  
+ AT_byte_size( 0x01 )
+ AT_encoding( DW_ATE_signed_char )
+ AT_name( "signed char" )
+
+0x0125: TAG_base_type [2]  
+ AT_byte_size( 0x02 )
+ AT_encoding( DW_ATE_signed )
+ AT_name( "short int" )
+
+0x0132: TAG_base_type [2]  
+ AT_byte_size( 0x02 )
+ AT_encoding( DW_ATE_unsigned )
+ AT_name( "short unsigned int" )
+
+0x0148: TAG_base_type [2]  
+ AT_byte_size( 0x08 )
+ AT_encoding( DW_ATE_signed )
+ AT_name( "long long int" )
+
+0x0159: TAG_base_type [2]  
+ AT_byte_size( 0x08 )
+ AT_encoding( DW_ATE_unsigned )
+ AT_name( "long long unsigned int" )
+
+0x0173: TAG_base_type [5]  
+ AT_byte_size( 0x08 )
+ AT_encoding( DW_ATE_unsigned )
+
+0x00000176:     TAG_subprogram [6]  
+ AT_external( 0x01 )
+ AT_name( "zlibVersion" )
+ AT_decl_file(
"/sw/src/fink.build/gcc45-4.4.999-20090902/gcc-4.5-20090902/zlib/zutil.c" )
+ AT_decl_line( 27 )
+ AT_prototyped( 0x01 )
+ AT_type( {0x019f} ( const char* ) )
+ AT_low_pc( 0x )
+ AT_high_pc( 0x000d )
+ AT_frame_base( 0x
+0x - 0x0001: rsp+8
+0x0001 - 0x000b: rsp+16
+0x000b - 0x000c: rbp+16
+0x000c - 0x000d: rsp+8 )
+
+0x019f: TAG_pointer_type [7]  
+ AT_byte_size( 0x08 )
+ AT_type( {0x01a5} ( const char ) )
+
+0x01a5: TAG_const_type [8]  
+

[Bug bootstrap/41180] can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6

[howarth at nitro dot med dot uc dot edu]

--- Comment #25 from howarth at nitro dot med dot uc dot edu  2009-09-02 
23:37 ---
Mike,
   I double checked and using tentative_cc doesn't results in a failure in
configure at...

checking for correct version of gmp.h... yes
checking for correct version of mpfr.h... yes
checking for the correct version of mpc.h... no
checking for the correct version of the gmp/mpfr libraries... no
configure: error: Building GCC requires GMP 4.2+ and MPFR 2.3.2+.
Try the --with-gmp and/or --with-mpfr options to specify their locations.
Copies of these libraries' source code can be found at their respective
hosting sites as well as at ftp://gcc.gnu.org/pub/gcc/infrastructure/.
See also http://gcc.gnu.org/install/prerequisites.html for additional info.
If you obtained GMP and/or MPFR from a vendor distribution package, make
sure that you have installed both the libraries and the header files.
They may be located in separate packages.

Only if I use CC like the Apple gcc's configure does the -m32 get passed all
the way
through to the gmp test. There must have been a reason why Apple used CC rather
than
tentative_cc here.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41180

[Bug bootstrap/41180] can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6

[mrs at apple dot com]

--- Comment #26 from mrs at apple dot com  2009-09-03 00:20 ---
First, config.guess is orthogonal to the entire discussion, because of that, we
never need to mention it again.

Next, we do a case analysis of every combination of host/target and build…  We
engineer each case to work as desired.  Once that is done, you'll discover that
we absolutely do need the i386 case to set -m32.  If that isn't done, the
compiler defaults to 64-bit, and that runs counter to the command implied by
the i386, which is to generate 32-bit code.  So, the fragment I sent is
absolutely required, unchanged.  You can know this is true by configure
--build=i386-apple-darwin10 on a 64-bit SL box and running file on gcc/expr.o. 
If it is 64-bit, it is wrong.

-m32 should never be set because the x86_64 case.  x86_64 means 64-bit, so, the
most it implies is -m64.  For this reason, #19 must be wrong.  x86_64 implying
-m64 is useful for gcc's that default to 32-bit code-gen.  I don't have that in
my tree, as I don't have to worry much about older systems and older compilers.
 For the FSF tree, it would be nice to have that.  You can know this is true by
configuring --build=x86_64-apple-darwin on a Leopard box (where gcc defaults to
32-bit) and running file on gcc/expr.o.  If it is 32-bit, it is wrong.

darwin10 supports and runs on 32-bit only processors.  In that case, x86_64
isn't the default code-gen, contrary to your statement in #22.

It is improper to test target in #20, as target has no influence. 
--host=i386-apple-darwin --target=arm-elf implies -m32.  Build one, then run
file gcc/expr.o.  If that file is 64-bit, it is wrong.

The changes to configure.ac are independent of config.guess, so your assertion
that the changes are only appropriate after config.guess is accepted, is wrong.
 You can see this by configure --build=i386-apple-darwin10 and running file
gcc/expr.o and noticing it is wrong currently on SL.  It is says 64-bit, it is
wrong.

For the comment in #24, no, that isn't its only purpose.  The purpose of it
would be to allow one to configure --host=i386-apple-darwin10
--build=i386-apple-darwin10, and have gcc do what it is told to do, which is to
generate 32-bit binaries.

Now, all that aside, you only need to change the patches I suggested, if there
is an error in them.  You've not identified one error, therefore you don't need
to change them.  If you want to change them, please explain the error.

Lastly, tentative_cc won't work as well as setting CC.  My comment in #15 is
wrong, CC must be used.

As for the libraries.  You have to build them appropriately, and give to gcc,
the appropriate libs.  I build them universal, so what I give gcc is trivially,
always good.  If you build just one architecture, you have to build the
libraries with the same 32/64-bitness as you want to build the compiler.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41180

[Bug c++/41233] New: Templated conversion operator produces symbol name that won't demangle

[zackw at panix dot com]

This program

  class Source;
  class Dest;

  struct converter
  {
converter(Source *s) {}
template operator D*();
  };

  Dest* f(Source* s) { return converter(s); }

when compiled by several different versions of g++ (I tried 4.3.4 and 4.4.1;
the person who asked me to reduce the test case found the problem on OSX with
some version of Apple-modified gcc 4.2), produces this symbol name for the
conversion operator:

  _ZN9convertercvPT_I4DestEEv

c++filt from binutils 2.19 will not demangle this symbol.  I have not been able
to figure out for certain whether this is an incorrect mangling, a demangler
bug, or both.  These variations demangle to close approximations of the right
thing:

  _ZN9convertercvT_IN4DestEEEv -> converter::operator Dest()
  _ZN9convertercvT_IPN4DestEEEv -> converter::operator Dest*()

but 

  _ZN9convertercvPT_IN4DestEEEv

does not demangle, either.


-- 
   Summary: Templated conversion operator produces symbol name that
won't demangle
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zackw at panix dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41233

[Bug debug/41232] New: VTA: SSA name in freelist but still referenced

[rmansfield at qnx dot com]

gcc version 4.5.0 20090902 (experimental) [trunk revision 151353] (GCC)

$ cat ice.i
void malloc_init() {
  char *cptr;
  char buf[1];
  int tmbd = atoi(cptr);
  if (tmbd > 0)
tmbd = (tmbd <= 124) ? tmbd : 124;
   else
tmbd = 0;
   sprintf(buf, "%d\n", tmbd);
}
$ ./xgcc -B. -O1 ice.i -c ice.i: In function 'malloc_init':
ice.i:9:4: warning: incompatible implicit declaration of built-in function
'sprintf'
$ ./xgcc -B. -O1 -fvar-tracking-assignments ice.i -c
ice.i: In function 'malloc_init':
ice.i:9:4: warning: incompatible implicit declaration of built-in function
'sprintf'
ice.i:1:6: error: SSA name in freelist but still referenced
tmbd_4
cc1: note: in statement
tmbd_9 = MAX_EXPR ;

ice.i:1:6: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.


-- 
   Summary: VTA: SSA name in freelist but still referenced
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rmansfield at qnx dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41232

[Bug bootstrap/41180] can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6

[howarth at nitro dot med dot uc dot edu]

--- Comment #27 from howarth at nitro dot med dot uc dot edu  2009-09-03 
00:56 ---
Mike,
 Regarding passing -m32 within the x86_64 host case, I was considering the
case of trying to cross compile the i686-apple-darwin10 target on the
x86_64-apple-darwin10 host.  While this sounds odd, we currently do this on
i386 fink for 10.6 (but we cheat by using wrappers for the compilers that pass
-m32 and explicitly pass --build=i686-apple-darwin10 --host=i686-apple-darwin10
 --target=i686-apple-darwin10 to gcc's configure). Without my proposed patch in
comment 10, if the user passed...

--host=x86_64-apple-darwin10 --target=i686-apple-darwin10

the i[[3456789]]86-*-darwin* host case won't be triggered but rather the absent
x86_64-*-darwin* host case. Without the patch, no -m32 will be added to CC
and the compiler will attempt to build the i686-apple-darwin10 compiler with
the default m64 code generation. 

If I remove the change from comment 20 and use the stock configure from gcc
trunk with...

../gcc/configure --prefix=/Users/howarth/dist
--enable-languages=c,c++,fortran,objc,java --with-arch=nocona
--with-tune=generic --host=x86_64-apple-darwin10 --target=i686-apple-darwin9
--with-gmp=/sw --with-libiconv-prefix=/sw --with-system-zlib
--x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib

where /sw is a i386 fink installation containing i386 binaries for gmp/mpfr, I
get the configure failure...

checking for correct version of gmp.h... yes
checking for correct version of mpfr.h... yes
checking for the correct version of mpc.h... no
checking for the correct version of the gmp/mpfr libraries... no
configure: error: Building GCC requires GMP 4.2+ and MPFR 2.3.2+.
Try the --with-gmp and/or --with-mpfr options to specify their locations.
Copies of these libraries' source code can be found at their respective
hosting sites as well as at ftp://gcc.gnu.org/pub/gcc/infrastructure/.
See also http://gcc.gnu.org/install/prerequisites.html for additional info.
If you obtained GMP and/or MPFR from a vendor distribution package, make
sure that you have installed both the libraries and the header files.
They may be located in separate packages.

Adding Apple's patch as...

@@ -3645,6 +3653,12 @@
   powerpc-*-darwin*)
 host_makefile_frag="config/mh-ppc-darwin"
 ;;
+  i[3456789]86-*-darwin*)
+# gcc can default to x86_64 code generation, avoid that
+if test "${build}" = "${host}"; then
+ CC="${CC-gcc} -m32"
+fi
+;;
   powerpc-*-aix*)
 host_makefile_frag="config/mh-ppc-aix"
 ;;

won't help in this case because 1) the host is set to x86_64-apple-darwin10 so
this case never
executes and 2) the target and host don't match anyway to set CC to have -m32.
I would also remind
you that the Apple system compiler in SL shows...

Using built-in specs.
Target: i686-apple-darwin10
Configured with: /var/tmp/gcc/gcc-5646~6/src/configure --disable-checking
--enable-werror --prefix=/usr --mandir=/share/man
--enable-languages=c,objc,c++,obj-c++
--program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib
--build=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1
--program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10
--target=i686-apple-darwin10
Thread model: posix
gcc version 4.2.1 (Apple Inc. build 5646)

which is exactly the triplet combination for --host and --target that I am
looking at. Only if I add my proposed patch in Comment 20 does configure
complete properly for the --host=x86_64-apple-darwin10
--target=i686-apple-darwin10 combination producing 32-bit binaries.

[Macintosh-2:~/work] howarth% ../gcc/configure --prefix=/Users/howarth/dist
--enable-languages=c,c++,fortran,objc,java --with-arch=nocona
--with-tune=generic --host=x86_64-apple-darwin10 --target=i686-apple-darwin9
--with-gmp=/sw --with-libiconv-prefix=/sw --with-system-zlib
--x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
configure: WARNING: If you wanted to set the --build type, don't use --host.
If a cross compiler is detected then cross compile mode will be used.
checking build system type... x86_64-apple-darwin10.0.0
checking host system type... x86_64-apple-darwin10
checking target system type... i686-apple-darwin9
checking for a BSD-compatible install... /usr/bin/install -c
checking whether ln works... yes
checking whether ln -s works... yes
checking for a sed that does not truncate output... /usr/bin/sed
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking for x86_64-apple-darwin10-gcc... gcc -m32
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... 
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc -m32 accepts -g... yes
checking for gcc -m32 option to accept ISO C89... none needed
checking for x86_64-apple-darwin

[Bug target/41176] ICE in reload_cse_simplify_operands at postreload.c:396

[lucier at math dot purdue dot edu]

--- Comment #2 from lucier at math dot purdue dot edu  2009-09-03 02:37 
---
I thought Vlad's scheduling/register allocation patch here

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

which solves PR24319, might fix this problem, but it does not.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41176

[Bug other/41234] New: Configure fails to find non-existant g++ preprocessor flag with syntax errors

[xenofears at gmail dot com]

I am unsure if this is due to host/target, build, or unrelated to triplets
altogether. 

Configure in Stage 2 gcc fails to determine to proper -E flag for the g++
preprocessor (in a 3-Stage build ../prev-gcc/g++ doesn't exist, so it shouldn't
report anything), and instead reports an odd "/lib/cpp". Stage 1 is unaffected,
and the build continues anyway. This is probably the same for Stage 3, but I
haven't made it through the now-possible Win64 Native gcc build yet, it is a
slow and fragile process.

I have seen this error before however, with libgcc configure in a single-stage
build, so it is not a unique to the gcc subdir configure or a 3-Stage build,
and in that case it caused failure.

I have copied all the relevant information out of the logs. Note the syntax
errors in the failed test.

The failed test configure log (Stage-2 gcc):


configure:13317: checking how to run the C++ preprocessor
configure:13344:  /home/Peter/gcc-trunk/build2/./prev-gcc/g++
-B/home/Peter/gcc-trunk/build2/./prev-gcc/
-B/usr/system64/x86_64-w64-mingw32/bin/ -nostdinc++
-I/home/Peter/gcc-trunk/build2/prev-x86_64-w64-mingw32/libstdc++-v3/include/x86_64-w64-mingw32
-I/home/Peter/gcc-trunk/build2/prev-x86_64-w64-mingw32/libstdc++-v3/include
-I/home/Peter/gcc-trunk/build2/../libstdc++-v3/libsupc++
-L/home/Peter/gcc-trunk/build2/prev-x86_64-w64-mingw32/libstdc++-v3/src/.libs
-E  conftest.cpp
/home/Peter/gcc-trunk/gcc/configure: line 2543:
/home/Peter/gcc-trunk/build2/./prev-gcc/g++: No such file or directory
configure:13344: $? = 127
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL ""
| #define HAVE_GNU_LD 0
| #define HAVE_GNU_AS 0
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| #define __EXTENSIONS__ 1
| #define _ALL_SOURCE 1
| #define _GNU_SOURCE 1
| #define _POSIX_PTHREAD_SEMANTICS 1
| #define _TANDEM_SOURCE 1
| #define SIZEOF_VOID_P 8
| #define SIZEOF_SHORT 2
| #define SIZEOF_INT 4
| #define SIZEOF_LONG 4
| #define HAVE_LONG_LONG 1
| #define SIZEOF_LONG_LONG 8
| #define HAVE___INT64 1
| #define SIZEOF___INT64 8
| #define ENABLE_CHECKING 1
| #define ENABLE_ASSERT_CHECKING 1
| #define ENABLE_GIMPLE_CHECKING 1
| #define ENABLE_RUNTIME_CHECKING 1
| #define ENABLE_TREE_CHECKING 1
| #define ENABLE_TYPES_CHECKING 1
| #define ENABLE_RTL_FLAG_CHECKING 1
| #define ENABLE_GC_CHECKING 1
| #define ENABLE_DECIMAL_FLOAT 0
| #define ENABLE_DECIMAL_BID_FORMAT 0
| #define ENABLE_FIXED_POINT 0
| #define STDC_HEADERS 1
| #define TIME_WITH_SYS_TIME 1
| #define STRING_WITH_STRINGS 1
| #define HAVE_LIMITS_H 1
| #define HAVE_STDDEF_H 1
| #define HAVE_STRING_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_TIME_H 1
| #define HAVE_ICONV_H 1
| #define HAVE_FCNTL_H 1
| #define HAVE_UNISTD_H 1
| #define HAVE_SYS_FILE_H 1
| #define HAVE_SYS_TIME_H 1
| #define HAVE_SYS_PARAM_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_DIRECT_H 1
| #define HAVE_MALLOC_H 1
| #define HAVE_LOCALE_H 1
| #define HAVE_WCHAR_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_CLOCK 1
| #define HAVE_ATOLL 1
| #define HAVE_GETTIMEOFDAY 1
| #define HAVE_MBSTOWCS 1
| #define HAVE_SETLOCALE 1
| #define HAVE_WORKING_MBSTOWCS 1
| #define caddr_t char *
| #define vfork fork
| #define HAVE_ICONV 1
| #define ICONV_CONST const
| #define HAVE_DECL_GETENV 1
| #define HAVE_DECL_ATOL 1
| #define HAVE_DECL_ASPRINTF 0
| #define HAVE_DECL_SBRK 0
| #define HAVE_DECL_ABORT 1
| #define HAVE_DECL_ATOF 1
| #define HAVE_DECL_GETCWD 1
| #define HAVE_DECL_GETWD 0
| #define HAVE_DECL_STRSIGNAL 1
| #define HAVE_DECL_STRSTR 1
| #define HAVE_DECL_STRVERSCMP 0
| #define HAVE_DECL_ERRNO 1
| #define HAVE_DECL_SNPRINTF 1
| #define HAVE_DECL_VSNPRINTF 1
| #define HAVE_DECL_VASPRINTF 0
| #define HAVE_DECL_MALLOC 1
| #define HAVE_DECL_REALLOC 1
| #define HAVE_DECL_CALLOC 1
| #define HAVE_DECL_FREE 1
| #define HAVE_DECL_BASENAME 0
| #define HAVE_DECL_GETOPT 0
| #define HAVE_DECL_CLOCK 1
| #define HAVE_DECL_GETPAGESIZE 0
| #define HAVE_DECL_CLEARERR_UNLOCKED 0
| #define HAVE_DECL_FEOF_UNLOCKED 0
| #define HAVE_DECL_FERROR_UNLOCKED 0
| #define HAVE_DECL_FFLUSH_UNLOCKED 0
| #define HAVE_DECL_FGETC_UNLOCKED 0
| #define HAVE_DECL_FGETS_UNLOCKED 0
| #define HAVE_DECL_FILENO_UNLOCKED 0
| #define HAVE_DECL_FPRINTF_UNLOCKED 0
| #define HAVE_DECL_FPUTC_UNLOCKED 0
| #define HAVE_DECL_FPUTS_UNLOCKED 0
| #define HAVE_DECL_FREAD_UNLOCKED 0
| #define HAVE_DECL_FWRITE_UNLOCKED 0
| #define HAVE_DECL_GETCHAR_UNLOCKED 0
| #define HAVE_DECL_GETC_UNLOCKED 0
| #define HAVE_DECL_PUTCHAR_UNLOCKED 0
| #define HAVE_DECL_PUTC_UNLOCKED 0
| #define HAVE_DECL_GETRLIMIT 0
| #define HAVE_DECL_SETRLIMIT 0
| #define HAVE_DECL_GETRUSAGE 0
| #define rlim_t l

[Bug debug/41226] [4.5 regression] Revision 151313 caused many regressions on trunk

[aoliva at gcc dot gnu dot org]

--- Comment #3 from aoliva at gcc dot gnu dot org  2009-09-03 05:35 ---
It was revision 151312 that brought the new failures, actually.  151313 turned
the run-time failures into expected failures, but it did nothing to the cast of
pointer to integer of different size that affects x86_32.  I'll look into a way
to avoid that warning.  Thanks for the report,


-- 

aoliva at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |aoliva at gcc dot gnu dot
   |dot org |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41226

[Bug fortran/41235] New: Missing explicit interface for variable-length character functions

[burnus at gcc dot gnu dot org]

From
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/d710371aed91e75f#

The following program is invalid. This is diagnosed at compile time by ifort,

test.f90(19): error #6832: This passed length character name has been used in
an invalid context.   [BIGFUNC]
   character(i) bigfunc
^

and NAG f95

Error: test.f90: CHARACTER*1024 function BIGFUNC referenced with non-constant
length from LEVEL1

and open95

openf95-916 openf95: ERROR LEVEL1, File = test.f90, Line = 19, Column = 17
  "BIGFUNC" has a variable length character result, therefore it must have an
explicit interface.

and g95

   character(i) bigfunc
1
Error: Nonconstant character function 'bigfunc' at (1) must have an explicit
interface

But not in gfortran - even not with -fwhole-file -fcheck=all.

program main
   implicit none
   character(4) level1
   character(4) answer
   integer i

   do i = 1024, 1, -1023
  write(*,'(a,i0)') 'Invoking level1 with i = ', i
  answer = level1(i)
  write(*,'(a)') 'Back from level1'
  write(*,'(a,i0,2a)') 'i = ', i, ', answer = ', answer
   end do
end program main

function level1(i)
   implicit none
   integer i
   character(4) level1
   character(i) bigfunc

   level1 = bigfunc()
end function level1

function bigfunc()
   implicit none
   character(1024) bigfunc

   bigfunc = repeat('b',len(bigfunc))
end function bigfunc


-- 
   Summary: Missing explicit interface for variable-length character
functions
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: accepts-invalid, diagnostic
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41235

[Bug middle-end/41229] [4.5 Regression] VTA: internal compiler error: verify_ssa failed

[jv244 at cam dot ac dot uk]

--- Comment #1 from jv244 at cam dot ac dot uk  2009-09-03 06:46 ---
this is now failing at '-O2 -g' with current trunk.


-- 

jv244 at cam dot ac dot uk changed:

   What|Removed |Added

  Known to fail||4.5.0
  Known to work||4.4.2
Summary|VTA: internal compiler  |[4.5 Regression] VTA:
   |error: verify_ssa failed|internal compiler error:
   ||verify_ssa failed
   Target Milestone|--- |4.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41229

[Bug middle-end/41225] [4.5 Regression] VTA: internal compiler error: in vect_stmt_relevant_p, at tree-vect-stmts.c:150

[jv244 at cam dot ac dot uk]

--- Comment #3 from jv244 at cam dot ac dot uk  2009-09-03 06:48 ---
gfortran -c  -O2 -ffast-math -funroll-loops -ftree-vectorize -march=native -g
bug.f90

now fails.


-- 

jv244 at cam dot ac dot uk changed:

   What|Removed |Added

  Known to fail||4.5.0
  Known to work||4.4.2
Summary|VTA: internal compiler  |[4.5 Regression] VTA:
   |error: in   |internal compiler error: in
   |vect_stmt_relevant_p, at|vect_stmt_relevant_p, at
   |tree-vect-stmts.c:150   |tree-vect-stmts.c:150
   Target Milestone|--- |4.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41225

[Bug debug/40660] [4.5 Regression] Weird break points with 4.5, works with 4.4

[jv244 at cam dot ac dot uk]

--- Comment #12 from jv244 at cam dot ac dot uk  2009-09-03 06:50 ---
looks like this is fixed on trunk.


-- 

jv244 at cam dot ac dot uk changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40660

[Bug c++/41214] [4.5 regression] Null pointer dereferenced in _Unwind_SetGR()

[d dot g dot gorbachev at gmail dot com]

--- Comment #4 from d dot g dot gorbachev at gmail dot com  2009-09-03 
06:51 ---
Created an attachment (id=18469)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18469&action=view)
Patch


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41214

[Bug fortran/41219] libgfortran build warnings

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2009-09-03 06:55 ---
Thomas, I think do to your changes one now gets a warning (unused argument) for
libgfortran/intrinsics/unpack_generic.c.

The last argument of unpack_internal ("index_type fsize") is no longer used; as
the function is static, one can simply remove it and update the callers (where
some __attribute__((unused)) has then to be added).

Is there really no need for the argument? Any any case, can you have a look and
create a patch?


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-09-03 06:55:42
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41219