[Bug libgcj/42658] [4.5 regression] ICE in _Jv_Linker::verify_class ../.././libjava/link.cc:1904

[davek at gcc dot gnu dot org]

--- Comment #15 from davek at gcc dot gnu dot org  2010-01-11 08:16 ---
just waiting to see if this can be reproduced with clean sources.


-- 

davek at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug target/40730] redundant memory load

[stevenb dot gcc at gmail dot com]

--- Comment #11 from stevenb dot gcc at gmail dot com  2010-01-11 08:22 
---
Subject: Re:  redundant memory load

On Mon, Jan 11, 2010 at 7:47 AM, carrot at google dot com
gcc-bugzi...@gcc.gnu.org wrote:
 iterate:
 push{lr}
 ldr r3, [r1]
 .L6:
 str r3, [r0]
 sub r2, r3, #0
 bne .L5
 b   .L3
 .L4:
 ldr r3, [r3, #8]
 b   .L6
 .L5:
 ldr r1, [r3, #4]
 cmp r1, #0
 beq .L4
 .L3:
 str r2, [r0, #12]
 @ sp needed for prologue
 pop {pc}

 Carrot, could you please double-check that this is still correct code?


 Yes, it is correct.
 There are still 13 instructions, I think it is related to unoptimized basic
 block order.

Yes, I would have expected the block starting with .L4 to be *after*
the block starting with .L5, something like so:

iterate:
push{lr}
ldr r3, [r1]
.L6:
str r3, [r0]
sub r2, r3, #0
beq .L3
.L5:
ldr r1, [r3, #4]
cmp r1, #0
bne .L3
ldr r3, [r3, #8]
b   .L6
.L3:
str r2, [r0, #12]
@ sp needed for prologue
pop {pc}

Does that look correct?  And if so, could you see if there is an open
bug report about this; or otherwise file a new PR and add me to the
CC-list?


-- 


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

[Bug fortran/42684] [4.5 Regression] ICE when interface operator(xx) available through host and use assoc in module procedure

[burnus at gcc dot gnu dot org]

-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

OtherBugsDependingO||32834
  nThis||
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  GCC build triplet|i686-pc-mingw32 |
   GCC host triplet|i686-pc-mingw32 |
 GCC target triplet|i686-pc-mingw32 |
   Keywords||ice-on-valid-code
   Last reconfirmed|-00-00 00:00:00 |2010-01-11 08:32:42
   date||
Summary|ICE when interface  |[4.5 Regression] ICE when
   |operator(xx) available  |interface operator(xx)
   |through host and use assoc  |available through host and
   |in module procedure |use assoc in module
   ||procedure
   Target Milestone|--- |4.5.0


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

[Bug debug/42648] [4.5 Regression] gcc.dg/guality/pr41353-1.c FAILs at -On, n 0

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2010-01-11 08:35 ---
See e.g. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41353#c11 for one of the
possible reasons.


-- 


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

[Bug java/41745] Segmentation fault when ecj.jar is run as a binary compiled by gcj

[gerald at pfeifer dot com]

--- Comment #12 from gerald at pfeifer dot com  2010-01-11 08:36 ---
Closing per previous comment.

Yuri, is it possible a different (older) run-time library was picked
up during your original tests?


-- 

gerald at pfeifer dot com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/42684] [4.5 Regression] ICE when interface operator(xx) available through host and use assoc in module procedure

[dominiq at lps dot ens dot fr]

--- Comment #4 from dominiq at lps dot ens dot fr  2010-01-11 08:50 ---
Looks similar to pr42677. The patch in comment#3 fixes these PRs, but misses
also really(?) ambiguous interfaces, see:

gcc/testsuite/gfortran.dg/defined_operators_1.f90
gcc/testsuite/gfortran.dg/generic_7.f90
gcc/testsuite/gfortran.dg/interface_5.f90
gcc/testsuite/gfortran.dg/interface_6.f90
gcc/testsuite/gfortran.dg/interface_7.f90
gcc/testsuite/gfortran.dg/operator_5.f90
gcc/testsuite/gfortran.dg/proc_ptr_comp_20.f90


-- 


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

[Bug fortran/42677] [4.5 Regression] Bogus Error: Ambiguous interfaces '...' in intrinsic assignment operator

[dominiq at lps dot ens dot fr]

--- Comment #4 from dominiq at lps dot ens dot fr  2010-01-11 08:51 ---
Similar to pr42677 (see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42684#c4 ).


-- 


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

[Bug fortran/42677] [4.5 Regression] Bogus Error: Ambiguous interfaces '...' in intrinsic assignment operator

[dominiq at lps dot ens dot fr]

--- Comment #5 from dominiq at lps dot ens dot fr  2010-01-11 08:52 ---
 Similar to pr42677

Wrong window!-( Similar to pr42684.


-- 


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

[Bug target/40730] redundant memory load

[carrot at google dot com]

--- Comment #12 from carrot at google dot com  2010-01-11 08:55 ---
(In reply to comment #11)
 Yes, I would have expected the block starting with .L4 to be *after*
 the block starting with .L5, something like so:
 
 iterate:
 push{lr}
 ldr r3, [r1]
 .L6:
 str r3, [r0]
 sub r2, r3, #0
 beq .L3
 .L5:
 ldr r1, [r3, #4]
 cmp r1, #0
 bne .L3
 ldr r3, [r3, #8]
 b   .L6
 .L3:
 str r2, [r0, #12]
 @ sp needed for prologue
 pop {pc}
 
 Does that look correct?  And if so, could you see if there is an open
 bug report about this; or otherwise file a new PR and add me to the
 CC-list?
 

It is correct. The basic block ordering issue (-Os) has been observed several
times. Following are related PRs:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41004
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41396


-- 


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

[Bug debug/42662] [4.5 Regression] invalid rtl sharing found in the insn

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2010-01-11 09:25 ---
Testing a patch.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2010-01-09 17:25:17 |2010-01-11 09:25:27
   date||


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

[Bug translation/42467] exgettext should not remove TABs from option help strings

[pzhao at gcc dot gnu dot org]

--- Comment #6 from pzhao at gcc dot gnu dot org  2010-01-11 09:33 ---
Fixed for 4.5.0


-- 

pzhao at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug translation/42469] option help strings not properly using TAB

[pzhao at gcc dot gnu dot org]

--- Comment #3 from pzhao at gcc dot gnu dot org  2010-01-11 09:34 ---
Fixed for 4.5.0


-- 

pzhao at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/41004] missed merge of basic blocks

[steven at gcc dot gnu dot org]

--- Comment #6 from steven at gcc dot gnu dot org  2010-01-11 09:35 ---
Re. comment #5 -- rth, any suggestions what an algorithm would look like to
minimize the number of branches, or the total size of all of the branch
instructions?  And what do you mean with some clever changes to the
shorten_branches code?  Did you mean the calculation of insn sizes, or
avoiding padding, or something else completely?  Hope you can help a bit...


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rth at gcc dot gnu dot org


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

[Bug debug/42662] [4.5 Regression] invalid rtl sharing found in the insn

[jzhang918 at gmail dot com]

--- Comment #5 from jzhang918 at gmail dot com  2010-01-11 09:36 ---
I just submitted a patch several days ago:

http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00130.html

I think it might be able to fix this bug.


-- 


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

[Bug c++/42687] New: The prevention of ADL with the help of parentheses doesn't work

[max at e-soft dot ru]

g++ doesn't accept correct code:

namespace N
{
struct S { };
void f(const S ) { }
}

void f(const N::S ) { }

int main()
{
N::S v;
(f)(v); // no ambiguity: ADL is prevented with (), only ::f is considered
}

--
References:

1) http://www.josuttis.com/tmplbook/ - 9.2.1 Argument-Dependent Lookup,
page 123.

2) http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n3000.pdf -
3.4.2 Argument-dependent name lookup, example on page 46.


-- 
   Summary: The prevention of ADL with the help of parentheses
doesn't work
   Product: gcc
   Version: 4.4.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: max at e-soft dot ru


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

[Bug debug/42662] [4.5 Regression] invalid rtl sharing found in the insn

[jakub at gcc dot gnu dot org]

--- Comment #6 from jakub at gcc dot gnu dot org  2010-01-11 09:46 ---
Created an attachment (id=19537)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19537action=view)
gcc45-pr42662.patch

Fix.

Regarding the above mentioned patch, it looks like a big hammer, which will
create a lot of garbage.  Are you sure you have investigated where exactly the
sharing originates from?  On the line this patch is fixing XEXP (op0, 0) is
used
twice, once inside the plus and once as the second comparison operand.  So it
is clearly where the bug is introduced.  Another place which also introduces
something similar (x*x scalar floating optimization) already uses properly
copy_rtx.


-- 


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

[Bug debug/42662] [4.5 Regression] invalid rtl sharing found in the insn

[jzhang918 at gmail dot com]

--- Comment #7 from jzhang918 at gmail dot com  2010-01-11 10:11 ---
Sorry, I should have checked my patch with the test code you posted before I
added that comment. My patch does not fix this one.


-- 


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

[Bug fortran/42680] [fortran-dev, Regression] ICE in gimplify_expr, at gimplify.c:7176

[dominiq at lps dot ens dot fr]

--- Comment #7 from dominiq at lps dot ens dot fr  2010-01-11 10:27 ---
(In reply to comment #6)
 This patch, reverting only the change to interface.c, appears to fix the
 problem.  No other regressions in testsuite.

The patch reintroduces pr42353 for the test in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42353#c1 .


-- 


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

[Bug tree-optimization/42645] -fcompare-debug failure at -O1

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2010-01-11 10:31 ---
The problem here are different holes in SSA_NAMEs - with
-fvar-tracking-assignments most of the SSA_NAME_VERSION values are one larger
than without it.  -fcompare-debug dumps include these versions in some MEMs, so
it triggers the failure, on this testcase no actual code difference is present
though.  The difference shows up during early inlining,
#0  make_ssa_name_fn (fn=0x71e8a6c0, var=0x71e9ebe0, stmt=0x0) at
../../gcc/tree-ssanames.c:126
#1  0x00e97142 in make_ssa_name (var=0x71e9ebe0, stmt=0x0) at
../../gcc/tree-flow-inline.h:1247
#2  0x00e9741d in remap_ssa_name (name=0x71de2898,
id=0x7fffde90) at ../../gcc/tree-inline.c:202
#3  0x00e9a9b7 in remap_gimple_op_r (tp=0x71ddf238,
walk_subtrees=0x7fffd6b0, data=0x7fffda50) at
../../gcc/tree-inline.c:738
#4  0x00dc3988 in walk_tree_1 (tp=0x71ddf238, func=0xe9a936
remap_gimple_op_r, data=0x7fffda50, pset=0x0, lh=0)
at ../../gcc/tree.c:9978
#5  0x00ea13bb in copy_debug_stmt (stmt=0x71ddf200,
id=0x7fffde90) at ../../gcc/tree-inline.c:2163
#6  0x00ea1441 in copy_debug_stmts (id=0x7fffde90) at
../../gcc/tree-inline.c:2192
creates a SSA_NAME which of course -g0 doesn't create.  The debug stmt is even
reset immediately afterwards.


-- 


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

[Bug tree-optimization/42645] -fcompare-debug failure at -O1

[zsojka at seznam dot cz]

--- Comment #3 from zsojka at seznam dot cz  2010-01-11 10:45 ---
Created an attachment (id=19538)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19538action=view)
different reduced testcase

$ /mnt/svn/gcc-trunk/binary-155777-lto/bin/g++ -O1 -fcompare-debug -c
testcase-min15-manual.ii
g++: testcase-min15-manual.ii: -fcompare-debug failure (length)

Testcases like these are often created by delta when reducing with grepping for
'-fcompare-debug failure'. The important part in both testcases seems to be no
return statement in function returning non-void with returned value stored to
a variable.


-- 


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

[Bug middle-end/42068] [4.5 regression] ICE in function_and_variable_visibility breaks Ada bootstrap

[ebotcazou at gcc dot gnu dot org]

--- Comment #9 from ebotcazou at gcc dot gnu dot org  2010-01-11 11:27 
---
Jan, are you there?


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||hubicka at ucw dot cz


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

[Bug tree-optimization/42645] -fcompare-debug failure at -O1

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2010-01-11 11:28 ---
Testing a fix.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-01-11 11:28:30
   date||


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

[Bug ada/42518] Alignment issue prevents building 64 bit RTS on Snow Leopard

[ebotcazou at gcc dot gnu dot org]

--- Comment #13 from ebotcazou at gcc dot gnu dot org  2010-01-11 11:30 
---
I think we should consider that x86_64-apple-darwin is not supported in 4.4 and
make sure that it will be in 4.5, in particular fix PR middle-end/42068.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |NEW
 Ever Confirmed|0   |1
   GCC host triplet|i386-apple-darwin10.2.0 |
   Last reconfirmed|-00-00 00:00:00 |2010-01-11 11:30:17
   date||


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

[Bug middle-end/42220] [4.5 Regression] FAIL: gfortran.dg/complex_intrinsic_5.f90 -m64 -O -frename-registers

[ebotcazou at gcc dot gnu dot org]

--- Comment #17 from ebotcazou at gcc dot gnu dot org  2010-01-11 11:31 
---
Still present?


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug tree-optimization/42645] -fcompare-debug failure at -O1

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2010-01-11 12:12 ---
Created an attachment (id=19539)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19539action=view)
gcc45-pr42645.patch

Fix I'm going to bootstrap/regtest.


-- 


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

[Bug debug/42657] Missing debug info for a variable

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2010-01-11 12:18 ---
http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00430.html
http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00431.html


-- 


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

[Bug middle-end/42220] [4.5 Regression] FAIL: gfortran.dg/complex_intrinsic_5.f90 -m64 -O -frename-registers

[dominiq at lps dot ens dot fr]

--- Comment #18 from dominiq at lps dot ens dot fr  2010-01-11 12:20 ---
 Still present?

Yes!-(If it has not been fixed meanwhile, it still fails at revision 155621).


-- 

dominiq at lps dot ens dot fr changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED


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

[Bug fortran/41478] Corrupted memory using PACK for derived-types with allocated components

[dominiq at lps dot ens dot fr]

--- Comment #20 from dominiq at lps dot ens dot fr  2010-01-11 12:29 ---
The patch in comment #19, passes all my tests, but (otherwise you'ld be
disappointed;-) compiling the reduced test in comment #8 gives a Segmentation
fault

pr41478_1.f90:7:0: internal compiler error: Segmentation fault

Backtrace:

(gdb) run pr41478_1.f90
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /opt/gcc/gcc4.5w/libexec/gcc/x86_64-apple-darwin10/4.5.0/f951
pr41478_1.f90
 MAIN__
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x
0x0001000aeee1 in structure_alloc_comps (der_type=value temporarily
unavailable, due to optimizations, decl=value temporarily unavailable, due to
optimizations, dest=value temporarily unavailable, due to optimizations,
rank=value temporarily unavailable, due to optimizations, purpose=3) at
../../work/gcc/fortran/trans-array.c:6014
6014  tmp = gfc_duplicate_allocatable(dcmp, comp, ctype,
c-as-rank);
(gdb) bt
#0  0x0001000aeee1 in structure_alloc_comps (der_type=value temporarily
unavailable, due to optimizations, decl=value temporarily unavailable, due to
optimizations, dest=value temporarily unavailable, due to optimizations,
rank=value temporarily unavailable, due to optimizations, purpose=3) at
../../work/gcc/fortran/trans-array.c:6014
#1  0x0001000aed7c in structure_alloc_comps (der_type=value temporarily
unavailable, due to optimizations, decl=0x141df5500, dest=value temporarily
unavailable, due to optimizations, rank=value temporarily unavailable, due to
optimizations, purpose=3) at ../../work/gcc/fortran/trans-array.c:5874
#2  0x0001000c7ed6 in gfc_conv_procedure_call (se=0x7fff5fbfea70,
sym=value temporarily unavailable, due to optimizations, arg=0x14180aef0,
expr=value temporarily unavailable, due to optimizations, append_args=value
temporarily unavailable, due to optimizations) at
../../work/gcc/fortran/trans-expr.c:3383
#3  0x0001000d7abb in conv_generic_with_optional_char_arg
(se=0x7fff5fbfea70, expr=0x141816b10) at
../../work/gcc/fortran/trans-intrinsic.c:3432
#4  0x0001000d8aeb in gfc_conv_intrinsic_function (se=0x7fff5fbfea70,
expr=0x141816b10) at ../../work/gcc/fortran/trans-intrinsic.c:5074
#5  0x0001000c8e36 in gfc_conv_function_expr (se=0x7fff5fbfea70,
expr=value temporarily unavailable, due to optimizations) at
../../work/gcc/fortran/trans-expr.c:3722
#6  0x0001000ca508 in gfc_trans_assignment (expr1=0x1418165c0,
expr2=0x141816b10, init_flag=0 '\0') at
../../work/gcc/fortran/trans-expr.c:4827
#7  0x0001000a5c06 in gfc_trans_code (code=0x1418172a0) at
../../work/gcc/fortran/trans.c:1086
#8  0x0001000c1d57 in gfc_generate_function_code (ns=value temporarily
unavailable, due to optimizations) at ../../work/gcc/fortran/trans-decl.c:4383
#9  0x000100068c3f in gfc_parse_file () at
../../work/gcc/fortran/parse.c:4242
#10 0x0001000a0d0c in gfc_be_parse_file (set_yydebug=value temporarily
unavailable, due to optimizations) at ../../work/gcc/fortran/f95-lang.c:239
#11 0x0001006cf01a in toplev_main (argc=2, argv=0x7fff5fbfee28) at
../../work/gcc/toplev.c:1053
#12 0x00010d54 in start ()


-- 


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

[Bug rtl-optimization/20070] If-conversion can't match equivalent code, and cross-jumping only works for literal matches

[rahul at icerasemi dot com]

--- Comment #32 from rahul at icerasemi dot com  2010-01-11 12:34 ---
I will re-test on our port and report my findings, cheers!


-- 


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

[Bug lto/41569] .../prev-gcc/xgcc used for the install step of the lto-plugin

[rguenth at gcc dot gnu dot org]

--- Comment #16 from rguenth at gcc dot gnu dot org  2010-01-11 12:38 
---
Subject: Bug 41569

Author: rguenth
Date: Mon Jan 11 12:38:09 2010
New Revision: 155809

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155809
Log:
2010-01-11  Richard Guenther  rguent...@suse.de

PR lto/41569
* Makefile.def (all-lto-plugin): Depend on all-gcc.
* Makefile.in: Regenerated.

lto-plugin/
* Makefile.am: Disable dependencies.
* Makefile.in: Regenerated.

Modified:
trunk/ChangeLog
trunk/Makefile.def
trunk/Makefile.in
trunk/lto-plugin/ChangeLog
trunk/lto-plugin/Makefile.am
trunk/lto-plugin/Makefile.in


-- 


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

[Bug fortran/41478] Corrupted memory using PACK for derived-types with allocated components

[pault at gcc dot gnu dot org]

--- Comment #21 from pault at gcc dot gnu dot org  2010-01-11 12:50 ---
(In reply to comment #20)
 The patch in comment #19, passes all my tests, but (otherwise you'ld be
 disappointed;-) compiling the reduced test in comment #8 gives a Segmentation
 fault

Oh, that's weird!  Does the original testcase and the one supplied with the
patch work?

Thanks

Paul 


-- 


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

[Bug fortran/41478] Corrupted memory using PACK for derived-types with allocated components

[burnus at gcc dot gnu dot org]

--- Comment #22 from burnus at gcc dot gnu dot org  2010-01-11 13:06 ---
(In reply to comment #20)
 The patch in comment #19, passes all my tests, but (otherwise you'ld be
 disappointed;-) compiling the reduced test in comment #8 gives a Segmentation
 fault
[...]
 ../../work/gcc/fortran/trans-array.c:6014
 6014  tmp = gfc_duplicate_allocatable(dcmp, comp, ctype,
 c-as-rank);

Because of that line: Dominique, do you have the draft patch for PR 42647
installed? If so, it might be the reason for the problem. Just to add another
possibility for the failure.


-- 


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

[Bug lto/42426] ICE in get_resolution (lto)

[d dot g dot gorbachev at gmail dot com]

--- Comment #4 from d dot g dot gorbachev at gmail dot com  2010-01-11 
13:08 ---
Fixed in r155800.


-- 

d dot g dot gorbachev at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug fortran/41478] Corrupted memory using PACK for derived-types with allocated components

[dominiq at lps dot ens dot fr]

--- Comment #23 from dominiq at lps dot ens dot fr  2010-01-11 13:50 ---
(In reply to comment #21)
 Oh, that's weird!  Does the original testcase and the one supplied with the
 patch work?

Yes, it was under all my tests.

(In reply to comment #22)
 Because of that line: Dominique, do you have the draft patch for PR 42647
 installed? If so, it might be the reason for the problem. Just to add another
 possibility for the failure.

Good catch! yes I do have the draft patch for PR 42647 (and others!). I was
thinking of applying the patch to another tree, but I have not done yet.


-- 


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

[Bug fortran/41478] Corrupted memory using PACK for derived-types with allocated components

[dominiq at lps dot ens dot fr]

--- Comment #24 from dominiq at lps dot ens dot fr  2010-01-11 14:04 ---
(In reply to comment #23)
  Because of that line: Dominique, do you have the draft patch for PR 42647
  installed? If so, it might be the reason for the problem. Just to add 
  another
  possibility for the failure.

 Good catch! yes I do have the draft patch for PR 42647 (and others!). I was
 thinking of applying the patch to another tree, but I have not done yet.

I have reverted the patch for PR 42647 and I still see the segmentation fault
(offset by -1 for the lines of trans-array.c in the backtrace).


-- 


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

[Bug c/42688] New: gcc 4.3.3 with -O2 thinks a often non-zero expression is always zero

[mnemo at minimum dot se]

When you build sqlite using GCC and -O2 parameter you get the following
warning. During runtime EXPR_FULLSIZE-nSize is mostly non-zero so it seems
that the GCC optimizer makes some assumptions that doesn't not always hold
true.

In function ‘memset’,
inlined from ‘exprDup’ at sqlite3.c:61011:
/usr/include/bits/string3.h:82: warning: call to ‘__warn_memset_zero_len’
declared with attribute warning: memset used with constant zero length
parameter; this could be due to transposed parameters

Repro steps:
0. install GCC 4.3.3
1. fetch and unpack sqlite from this URL:
http://www.sqlite.org/sqlite-amalgamation-3.6.22.tar.gz
2. run gcc -O2 sqlite3.c

Background: this issue was originally posted to the sqlite project as a sqlite
bug but they dismissed it as a GCC bug instead (which I believe is correct):
http://www.sqlite.org/src/tktview?name=f51d950180


-- 
   Summary: gcc 4.3.3 with -O2 thinks a often non-zero expression is
always zero
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mnemo at minimum dot se


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

[Bug target/42671] Thumb2 generate more instructions than Thumb1 to load GOT address

[ramana at gcc dot gnu dot org]

-- 

ramana at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-01-11 14:30:01
   date||


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

[Bug rtl-optimization/42246] ICE in init_seqno for 186.crafty with sel-sched

[abel at gcc dot gnu dot org]

--- Comment #4 from abel at gcc dot gnu dot org  2010-01-11 14:35 ---
(In reply to comment #2)

This is the other bug in our region walk iterator that happens when pipelining
outer loops.  When looking for loop exits from an inner loop that is contained
in the outer loop currently being pipelined, we need to work harder to skip
several consecutive inner loops if needed.  The iterator assumes that all
preheaders of inner loops are available, so when skipping an inner loop, it
expects to find a block of an outer loop (which is possibly the preheader of
the next inner loop).  When we are removing empty blocks in the region body,
this is not the case, and we are immediately hitting the header of the next
inner loop.  Fortunately, the bug is rather easily fixed by using the already
implemented infrastructure as below.

* sel-sched-ir.h (get_all_loop_exits): Include exits from inner
loops.

diff --git a/gcc/sel-sched-ir.h b/gcc/sel-sched-ir.h
index 06082ac..317258c 100644
--- a/gcc/sel-sched-ir.h
+++ b/gcc/sel-sched-ir.h
@@ -1147,7 +1147,8 @@ get_all_loop_exits (basic_block bb)

   /* Traverse all loop headers.  */
   for (i = 0; VEC_iterate (edge, exits, i, e); i++)
-   if (in_current_region_p (e-dest))
+   if (in_current_region_p (e-dest)
+   || inner_loop_header_p (e-dest))
  {
VEC(edge, heap) *next_exits = get_all_loop_exits (e-dest);



-- 


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

[Bug target/42689] New: bad formatting of specs diagnostics

[jsm28 at gcc dot gnu dot org]

Various diagnostics produced from specs with %e and %n are badly formatted.

There should be no \n or other whitespace at the end of these diagnostics,
since the driver inserts a newline at the end automatically.

A single diagnostic should not be split across multiple messages, for
the sake of translation; put it on one source line, one message, even
if long.

config/i386/linux-unwind.h should be in gcc/po/EXCLUDES to avoid
a non-diagnostic being wrongly extracted for translation.

#line 50 config/vax/vax.h
_(profiling not supported with -mg\n)
#line 51 config/vax/vax.h
_(profiling not supported with -mg\n)
#line 186 config/i386/linux-unwind.h
_(ax ; {int $0x80 | syscall)
#line 87 config/pa/pa-hpux10.h
_(Warning: consider linking with `-static' as system libraries with\n)
#line 88 config/pa/pa-hpux10.h
_(  profiling support are only provided in archive format)
#line 90 config/pa/pa-hpux10.h
_(Warning: consider linking with `-static' as system libraries with\n)
#line 91 config/pa/pa-hpux10.h
_(  profiling support are only provided in archive format)
#line 98 config/pa/pa-hpux10.h
_(Warning: consider linking with `-static' as system libraries with\n)
#line 99 config/pa/pa-hpux10.h
_(  profiling support are only provided in archive format)
#line 101 config/pa/pa-hpux10.h
_(Warning: consider linking with `-static' as system libraries with\n)
#line 102 config/pa/pa-hpux10.h
_(  profiling support are only provided in archive format)
#line 108 config/pa/pa-hpux11.h
_(Warning: consider linking with `-static' as system libraries with\n)
#line 109 config/pa/pa-hpux11.h
_(  profiling support are only provided in archive format)
#line 111 config/pa/pa-hpux11.h
_(Warning: consider linking with `-static' as system libraries with\n)
#line 112 config/pa/pa-hpux11.h
_(  profiling support are only provided in archive format)
#line 34 config/i386/nwld.h
_(Static linking is not supported.\n)
#line 30 config/pa/pa64-hpux.h
_(Warning: consider linking with `-static' as system libraries with\n)
#line 31 config/pa/pa64-hpux.h
_(  profiling support are only provided in archive format)
#line 33 config/pa/pa64-hpux.h
_(Warning: consider linking with `-static' as system libraries with\n)
#line 34 config/pa/pa64-hpux.h
_(  profiling support are only provided in archive format)
#line 42 config/pa/pa64-hpux.h
_(Warning: consider linking with `-static' as system libraries with\n)
#line 43 config/pa/pa64-hpux.h
_(  profiling support are only provided in archive format)
#line 45 config/pa/pa64-hpux.h
_(Warning: consider linking with `-static' as system libraries with\n)
#line 46 config/pa/pa64-hpux.h
_(  profiling support are only provided in archive format)
#line 31 config/arm/freebsd.h
_(consider using `-pg' instead of `-p' with gprof(1) )
#line 543 config/i386/i386.h
_(`-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead.\n)
#line 546 config/i386/i386.h
_(`-mintel-syntax' is deprecated. Use `-masm=intel' instead.\n)
#line 548 config/i386/i386.h
_('-msse5' was removed.\n)
#line 550 config/i386/i386.h
_(`-mno-intel-syntax' is deprecated. Use `-masm=att' instead.\n)


-- 
   Summary: bad formatting of specs diagnostics
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jsm28 at gcc dot gnu dot org
OtherBugsDependingO 40883
 nThis:


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

[Bug target/42689] bad formatting of specs diagnostics

[jsm28 at gcc dot gnu dot org]

--- Comment #1 from jsm28 at gcc dot gnu dot org  2010-01-11 15:04 ---
Correction: the newlines get removed before the messages are printed.
But they don't get removed by exgettext either before or after the patch
for bug 39521.  As they are unnecessary (at least once the message pairs
are converted into single messages), they should be removed.


-- 


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

[Bug middle-end/42245] ICE in verify_backedges for 197.parser with sel-sched

[amonakov at gcc dot gnu dot org]

--- Comment #7 from amonakov at gcc dot gnu dot org  2010-01-11 15:04 
---
Our previous patch (http://gcc.gnu.org/ml/gcc-patches/2009-12/msg01215.html)
failed to correctly fix the problem, and the new testcase uncovers a flaw in
that implementation.

We 'forgot' to recompute topological order if it was invalidated in
tidy_control_flow but not in maybe_tidy_empty_bb called from that function. 
Fixed by passing recompute_toporder_p to the latter on top of the mentioned
previous patch as below (the patch also makes maybe_tidy_empty_bb static by
moving the only caller into the same file).

* sel-sched-ir.c (maybe_tidy_empty_bb): Make static.  Add new
argument.  Update all callers.
(purge_empty_blocks): Export and move from...
* sel-sched.c (purge_empty_blocks): ... here.  Delete.
* sel-sched-ir.h (maybe_tidy_empty_bb): Delete prototype.
(purge_empty_blocks): Declare.

diff --git a/gcc/sel-sched-ir.c b/gcc/sel-sched-ir.c
index cffee1c..e20df17 100644
--- a/gcc/sel-sched-ir.c
+++ b/gcc/sel-sched-ir.c
@@ -3538,13 +3538,13 @@ sel_recompute_toporder (void)
 }

 /* Tidy the possibly empty block BB.  */
-bool
-maybe_tidy_empty_bb (basic_block bb)
+static bool
+maybe_tidy_empty_bb (basic_block bb, bool recompute_toporder_p)
 {
   basic_block succ_bb, pred_bb;
   edge e;
   edge_iterator ei;
-  bool rescan_p, recompute_toporder_p = false;
+  bool rescan_p;

   /* Keep empty bb only if this block immediately precedes EXIT and
  has incoming non-fallthrough edge, or it has no predecessors or
@@ -3630,7 +3630,7 @@ tidy_control_flow (basic_block xbb, bool full_tidying)
   insn_t first, last;

   /* First check whether XBB is empty.  */
-  changed = maybe_tidy_empty_bb (xbb);
+  changed = maybe_tidy_empty_bb (xbb, false);
   if (changed || !full_tidying)
 return changed;

@@ -3694,7 +3694,7 @@ tidy_control_flow (basic_block xbb, bool full_tidying)
  that contained that jump, becomes empty too.  In such case
  remove it too.  */
   if (sel_bb_empty_p (xbb-prev_bb))
-changed = maybe_tidy_empty_bb (xbb-prev_bb);
+changed = maybe_tidy_empty_bb (xbb-prev_bb, recompute_toporder_p);
   else if (recompute_toporder_p)
sel_recompute_toporder ();
 }
@@ -3702,6 +3702,24 @@ tidy_control_flow (basic_block xbb, bool full_tidying)
   return changed;
 }

+/* Purge meaningless empty blocks in the middle of a region.  */
+void
+purge_empty_blocks (void)
+{
+  /* Do not attempt to delete preheader.  */
+  int i = sel_is_loop_preheader_p (BASIC_BLOCK (BB_TO_BLOCK (0))) ? 1 : 0;
+
+  while (i  current_nr_blocks)
+{
+  basic_block b = BASIC_BLOCK (BB_TO_BLOCK (i));
+
+  if (maybe_tidy_empty_bb (b, false))
+   continue;
+
+  i++;
+}
+}
+
 /* Rip-off INSN from the insn stream.  When ONLY_DISCONNECT is true,
do not delete insn's data, because it will be later re-emitted.
Return true if we have removed some blocks afterwards.  */
diff --git a/gcc/sel-sched-ir.h b/gcc/sel-sched-ir.h
index 317258c..b5121c0 100644
--- a/gcc/sel-sched-ir.h
+++ b/gcc/sel-sched-ir.h
@@ -1619,7 +1619,7 @@ extern bool tidy_control_flow (basic_block, bool);
 extern void free_bb_note_pool (void);

 extern void sel_remove_empty_bb (basic_block, bool, bool);
-extern bool maybe_tidy_empty_bb (basic_block bb);
+extern void purge_empty_blocks (void);
 extern basic_block sel_split_edge (edge);
 extern basic_block sel_create_recovery_block (insn_t);
 extern void sel_merge_blocks (basic_block, basic_block);
diff --git a/gcc/sel-sched.c b/gcc/sel-sched.c
index 37be754..9271b80 100644
--- a/gcc/sel-sched.c
+++ b/gcc/sel-sched.c
@@ -6790,24 +6790,6 @@ setup_current_loop_nest (int rgn)
   gcc_assert (LOOP_MARKED_FOR_PIPELINING_P (current_loop_nest));
 }

-/* Purge meaningless empty blocks in the middle of a region.  */
-static void
-purge_empty_blocks (void)
-{
-  /* Do not attempt to delete preheader.  */
-  int i = sel_is_loop_preheader_p (BASIC_BLOCK (BB_TO_BLOCK (0))) ? 1 : 0;
-
-  while (i  current_nr_blocks)
-{
-  basic_block b = BASIC_BLOCK (BB_TO_BLOCK (i));
-
-  if (maybe_tidy_empty_bb (b))
-   continue;
-
-  i++;
-}
-}
-
 /* Compute instruction priorities for current region.  */
 static void
 sel_compute_priorities (int rgn)


-- 


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

[Bug lto/42690] New: Undefined reference errors with -flto -fuse-linker-plugin

[d dot g dot gorbachev at gmail dot com]

-- 
   Summary: Undefined reference errors with -flto -fuse-linker-
plugin
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: d dot g dot gorbachev at gmail 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=42690

[Bug lto/42690] Undefined reference errors with -flto -fuse-linker-plugin

[d dot g dot gorbachev at gmail dot com]

--- Comment #1 from d dot g dot gorbachev at gmail dot com  2010-01-11 
15:25 ---
Created an attachment (id=19541)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19541action=view)
testcase

GCC 4.5.0 20100107.

gcc -flto -fuse-linker-plugin pr42690.c -DBUG


-- 


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

[Bug lto/42665] Internal compiler exception in with gfortran when using -fwhole-program -flto -fopenmp

[jjcogliati-r1 at yahoo dot com]

--- Comment #7 from jjcogliati-r1 at yahoo dot com  2010-01-11 15:50 ---
(In reply to comment #6)

 Try
 
 Index: gcc/gimple.c
 ===
 --- gcc/gimple.c(revision 155739)
 +++ gcc/gimple.c(working copy)
 @@ -3707,8 +3707,10 @@ iterative_hash_gimple_type (tree type, h
/* For integer types hash the types min/max values and the string flag.  
 */
if (TREE_CODE (type) == INTEGER_TYPE)
  {
 -  v = iterative_hash_expr (TYPE_MIN_VALUE (type), v);
 -  v = iterative_hash_expr (TYPE_MAX_VALUE (type), v);
 +  if (TYPE_MIN_VALUE (type))
 +   v = iterative_hash_expr (TYPE_MIN_VALUE (type), v);
 +  if (TYPE_MAX_VALUE (type))
 +   v = iterative_hash_expr (TYPE_MAX_VALUE (type), v);
v = iterative_hash_hashval_t (TYPE_STRING_FLAG (type), v);
  }
 
 


I tried that patch.  Still errors out with backtrace:
#0  iterative_hash_expr (t=0x71e96b70, val=154387133)
at ../../gcc-4.5-20100107/gcc/tree.c:6592
#1  0x005ee1fc in iterative_hash_gimple_type (type=0x71df3888, 
val=value optimized out, sccstack=0x7fffda38, sccstate=0x126a440, 
sccstate_obstack=0x7fffd9e0)
at ../../gcc-4.5-20100107/gcc/gimple.c:3713
#2  0x005ee843 in visit (t=0x71df3888, state=0x126b4b0, 
v=1159414094, sccstack=0x7fffda38, sccstate=0x126a440, 
sccstate_obstack=0x7fffd9e0)
at ../../gcc-4.5-20100107/gcc/gimple.c:3599
#3  0x005ee276 in iterative_hash_gimple_type (type=0x71df37e0, 
val=value optimized out, sccstack=0x7fffda38, sccstate=0x126a440, 
sccstate_obstack=0x7fffd9e0)
at ../../gcc-4.5-20100107/gcc/gimple.c:3722
#4  0x005ee843 in visit (t=0x71df37e0, state=0x126b4a0, 
v=4237831805, sccstack=0x7fffda38, sccstate=0x126a440, 
sccstate_obstack=0x7fffd9e0)
at ../../gcc-4.5-20100107/gcc/gimple.c:3599
#5  0x005ee180 in iterative_hash_gimple_type (type=0x71df3bd0, 
val=value optimized out, sccstack=0x7fffda38, sccstate=0x126a440, 
sccstate_obstack=0x7fffd9e0)
at ../../gcc-4.5-20100107/gcc/gimple.c:3703
#6  0x005ee6eb in gimple_type_hash (p=0x71df3bd0)
at ../../gcc-4.5-20100107/gcc/gimple.c:3831
#7  0x00bfb821 in htab_find_slot (htab=0x11de980, 
element=0x71df3bd0, insert=INSERT)
at ../../gcc-4.5-20100107/libiberty/hashtab.c:681
#8  0x005f76e3 in gimple_register_type (t=0x71df3bd0)
at ../../gcc-4.5-20100107/gcc/gimple.c:3873
#9  0x005f76c6 in gimple_register_type (t=0x71df3738)
at ../../gcc-4.5-20100107/gcc/gimple.c:3868
#10 0x0048cbb7 in lto_read_in_decl_state (data=value optimized out, 
state=value optimized out) at ../../gcc-4.5-20100107/gcc/lto/lto.c:174
#11 0x0048f036 in lto_read_decls (resolutions=value optimized out, 
data=value optimized out, decl_data=value optimized out)
at ../../gcc-4.5-20100107/gcc/lto/lto.c:237
#12 lto_file_read (resolutions=value optimized out, 
data=value optimized out, decl_data=value optimized out)
at ../../gcc-4.5-20100107/gcc/lto/lto.c:377
#13 read_cgraph_and_symbols (resolutions=value optimized out, 
data=value optimized out, decl_data=value optimized out)
at ../../gcc-4.5-20100107/gcc/lto/lto.c:1839
#14 lto_main (resolutions=value optimized out, data=value optimized out, 
decl_data=value optimized out)
at ../../gcc-4.5-20100107/gcc/lto/lto.c:2061
#15 0x0073fc26 in compile_file ()
at ../../gcc-4.5-20100107/gcc/toplev.c:1053
#16 do_compile () at ../../gcc-4.5-20100107/gcc/toplev.c:2405
#17 toplev_main () at ../../gcc-4.5-20100107/gcc/toplev.c:2447
#18 0x00378c01eb1d in __libc_start_main (main=value optimized out, 
argc=value optimized out, ubp_av=value optimized out, 
init=value optimized out, fini=value optimized out, 
rtld_fini=value optimized out, stack_end=value optimized out)
at libc-start.c:220

Same generally looking types as above (ERROR_MARK, INTEGER_TYPE ...)

Is there anyway for me to find out what filename and line number are being
compiled at this point?  That would help me figure out a smaller testcase.


-- 


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

[Bug c++/40239] Aggregate initialization requires copy constructor

[dodji at gcc dot gnu dot org]

-- 

dodji at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dodji at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-08-25 15:44:03 |2010-01-11 15:53:43
   date||


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

[Bug lto/42665] Internal compiler exception in with gfortran when using -fwhole-program -flto -fopenmp

[rguenther at suse dot de]

--- Comment #8 from rguenther at suse dot de  2010-01-11 15:54 ---
Subject: Re:  Internal compiler exception in with gfortran
 when using  -fwhole-program -flto -fopenmp

On Mon, 11 Jan 2010, jjcogliati-r1 at yahoo dot com wrote:

 
 
 --- Comment #7 from jjcogliati-r1 at yahoo dot com  2010-01-11 15:50 
 ---
 (In reply to comment #6)
 
  Try
  
  Index: gcc/gimple.c
  ===
  --- gcc/gimple.c(revision 155739)
  +++ gcc/gimple.c(working copy)
  @@ -3707,8 +3707,10 @@ iterative_hash_gimple_type (tree type, h
 /* For integer types hash the types min/max values and the string flag.  
  */
 if (TREE_CODE (type) == INTEGER_TYPE)
   {
  -  v = iterative_hash_expr (TYPE_MIN_VALUE (type), v);
  -  v = iterative_hash_expr (TYPE_MAX_VALUE (type), v);
  +  if (TYPE_MIN_VALUE (type))
  +   v = iterative_hash_expr (TYPE_MIN_VALUE (type), v);
  +  if (TYPE_MAX_VALUE (type))
  +   v = iterative_hash_expr (TYPE_MAX_VALUE (type), v);
 v = iterative_hash_hashval_t (TYPE_STRING_FLAG (type), v);
   }
  
  
 
 
 I tried that patch.  Still errors out with backtrace:
 #0  iterative_hash_expr (t=0x71e96b70, val=154387133)
 at ../../gcc-4.5-20100107/gcc/tree.c:6592
 #1  0x005ee1fc in iterative_hash_gimple_type (type=0x71df3888, 
 val=value optimized out, sccstack=0x7fffda38, sccstate=0x126a440, 
 sccstate_obstack=0x7fffd9e0)
 at ../../gcc-4.5-20100107/gcc/gimple.c:3713
 #2  0x005ee843 in visit (t=0x71df3888, state=0x126b4b0, 
 v=1159414094, sccstack=0x7fffda38, sccstate=0x126a440, 
 sccstate_obstack=0x7fffd9e0)
 at ../../gcc-4.5-20100107/gcc/gimple.c:3599
 #3  0x005ee276 in iterative_hash_gimple_type (type=0x71df37e0, 
 val=value optimized out, sccstack=0x7fffda38, sccstate=0x126a440, 
 sccstate_obstack=0x7fffd9e0)
 at ../../gcc-4.5-20100107/gcc/gimple.c:3722
 #4  0x005ee843 in visit (t=0x71df37e0, state=0x126b4a0, 
 v=4237831805, sccstack=0x7fffda38, sccstate=0x126a440, 
 sccstate_obstack=0x7fffd9e0)
 at ../../gcc-4.5-20100107/gcc/gimple.c:3599
 #5  0x005ee180 in iterative_hash_gimple_type (type=0x71df3bd0, 
 val=value optimized out, sccstack=0x7fffda38, sccstate=0x126a440, 
 sccstate_obstack=0x7fffd9e0)
 at ../../gcc-4.5-20100107/gcc/gimple.c:3703
 #6  0x005ee6eb in gimple_type_hash (p=0x71df3bd0)
 at ../../gcc-4.5-20100107/gcc/gimple.c:3831
 #7  0x00bfb821 in htab_find_slot (htab=0x11de980, 
 element=0x71df3bd0, insert=INSERT)
 at ../../gcc-4.5-20100107/libiberty/hashtab.c:681
 #8  0x005f76e3 in gimple_register_type (t=0x71df3bd0)
 at ../../gcc-4.5-20100107/gcc/gimple.c:3873
 #9  0x005f76c6 in gimple_register_type (t=0x71df3738)
 at ../../gcc-4.5-20100107/gcc/gimple.c:3868
 #10 0x0048cbb7 in lto_read_in_decl_state (data=value optimized out, 
 state=value optimized out) at ../../gcc-4.5-20100107/gcc/lto/lto.c:174
 #11 0x0048f036 in lto_read_decls (resolutions=value optimized out, 
 data=value optimized out, decl_data=value optimized out)
 at ../../gcc-4.5-20100107/gcc/lto/lto.c:237
 #12 lto_file_read (resolutions=value optimized out, 
 data=value optimized out, decl_data=value optimized out)
 at ../../gcc-4.5-20100107/gcc/lto/lto.c:377
 #13 read_cgraph_and_symbols (resolutions=value optimized out, 
 data=value optimized out, decl_data=value optimized out)
 at ../../gcc-4.5-20100107/gcc/lto/lto.c:1839
 #14 lto_main (resolutions=value optimized out, data=value optimized out, 
 decl_data=value optimized out)
 at ../../gcc-4.5-20100107/gcc/lto/lto.c:2061
 #15 0x0073fc26 in compile_file ()
 at ../../gcc-4.5-20100107/gcc/toplev.c:1053
 #16 do_compile () at ../../gcc-4.5-20100107/gcc/toplev.c:2405
 #17 toplev_main () at ../../gcc-4.5-20100107/gcc/toplev.c:2447
 #18 0x00378c01eb1d in __libc_start_main (main=value optimized out, 
 argc=value optimized out, ubp_av=value optimized out, 
 init=value optimized out, fini=value optimized out, 
 rtld_fini=value optimized out, stack_end=value optimized out)
 at libc-start.c:220
 
 Same generally looking types as above (ERROR_MARK, INTEGER_TYPE ...)
 
 Is there anyway for me to find out what filename and line number are being
 compiled at this point?  That would help me figure out a smaller testcase.

Not really.  A big testcase is ok - we have automated tools to reduce it.

Richard.


-- 


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

[Bug tree-optimization/42652] vectorizer created unaligned vector insns

[law at redhat dot com]

--- Comment #6 from law at redhat dot com  2010-01-11 17:14 ---
Subject: Re:  vectorizer created unaligned vector
 insns

On 01/10/10 01:22, irar at il dot ibm dot com wrote:
 --- Comment #5 from irar at il dot ibm dot com  2010-01-10 08:22 ---
 In vector_alignment_reachable_p() we check if an access is packed using
 contains_packed_reference(). For packed accesses we return false, meaning
 alignment is unreachable and peeling cannot be used.

 In the attached testcase contains_packed_reference() returns false for
 palette_5.

Right.  If you look more closely at the way the code works, there's no 
way contains_packed_reference is ever going to return true.  It simply 
isn't passed the right information.  It'd need to be looking at the base 
address's type (not the base object).  Furthermore, 
contains_packed_reference simply isn't designed to dive into types.  It 
primarily works on exprs and only references the underlying type when it 
encounters a COMPONENT_REF.

As Richard apparently pointed out in the past, this code is not 
conservatively correct -- if it can't prove the item is properly 
aligned, then a runtime check is required.

So while I think we might be able to fix this specific instance by 
improving the code around the call to contains_packed_reference, I think 
we have a bigger problem as it's fairly trivial to change the test so 
that the addresses of interest are parameters and alignment info is 
effectively unknown.


Jeff


-- 


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

[Bug lto/42665] Internal compiler exception in with gfortran when using -fwhole-program -flto -fopenmp

[jjcogliati-r1 at yahoo dot com]

--- Comment #9 from jjcogliati-r1 at yahoo dot com  2010-01-11 17:15 ---
My hunch, (and I could be wrong since my knowledge of gcc's tree code was zero
as of Friday morning) is that it is trying to find the array's min and max
size, but that only the min location is available, and that the max value is
undefined.  Since this is fortran code, there are a number of places that I do
that.  Is that plausible, and if so, how would I check this hunch?

Getting permission for me to get you the full code would involve a lot of
bureaucracy (weeks to months).  

(gdb) p type-base
$32 = {code = ARRAY_TYPE, side_effects_flag = 0, constant_flag = 0, 
  addressable_flag = 0, volatile_flag = 0, readonly_flag = 0, 
  unsigned_flag = 0, asm_written_flag = 0, nowarning_flag = 0, used_flag = 0, 
  nothrow_flag = 0, static_flag = 0, public_flag = 0, private_flag = 0, 
  protected_flag = 0, deprecated_flag = 0, saturating_flag = 0, 
  default_def_flag = 0, lang_flag_0 = 0, lang_flag_1 = 0, lang_flag_2 = 0, 
  lang_flag_3 = 0, lang_flag_4 = 0, lang_flag_5 = 0, lang_flag_6 = 0, 
  visited = 0, packed_flag = 0, user_align = 0, spare = 0, address_space = 0}
(gdb) list
3717  /* For array types hash their domain and the string flag.  */
3718  if (TREE_CODE (type) == ARRAY_TYPE
3719   TYPE_DOMAIN (type))
3720{
3721  v = iterative_hash_hashval_t (TYPE_STRING_FLAG (type), v);
3722  v = visit (TYPE_DOMAIN (type), state, v,
3723 sccstack, sccstate, sccstate_obstack);
3724}
3725
3726  /* Recurse for aggregates with a single element type.  */
(gdb) where
#0  iterative_hash_expr (t=0x71e96b70, val=154387133)
at ../../gcc-4.5-20100107/gcc/tree.c:6592
#1  0x005ee1fc in iterative_hash_gimple_type (type=0x71df3888, 
val=value optimized out, sccstack=0x7fffda38, sccstate=0x126a440, 
sccstate_obstack=0x7fffd9e0)
at ../../gcc-4.5-20100107/gcc/gimple.c:3713
#2  0x005ee843 in visit (t=0x71df3888, state=0x126b4b0, 
v=1159414094, sccstack=0x7fffda38, sccstate=0x126a440, 
sccstate_obstack=0x7fffd9e0)
at ../../gcc-4.5-20100107/gcc/gimple.c:3599
#3  0x005ee276 in iterative_hash_gimple_type (type=0x71df37e0, 
val=value optimized out, sccstack=0x7fffda38, sccstate=0x126a440, 
sccstate_obstack=0x7fffd9e0)
at ../../gcc-4.5-20100107/gcc/gimple.c:3722
(gdb) down
#2  0x005ee843 in visit (t=0x71df3888, state=0x126b4b0, 
v=1159414094, sccstack=0x7fffda38, sccstate=0x126a440, 
sccstate_obstack=0x7fffd9e0)
at ../../gcc-4.5-20100107/gcc/gimple.c:3599
3599  tem = iterative_hash_gimple_type (t, v,
(gdb) down
#1  0x005ee1fc in iterative_hash_gimple_type (type=0x71df3888, 
val=value optimized out, sccstack=0x7fffda38, sccstate=0x126a440, 
sccstate_obstack=0x7fffd9e0)
at ../../gcc-4.5-20100107/gcc/gimple.c:3713
3713   v = iterative_hash_expr (TYPE_MAX_VALUE (type), v);
(gdb) p type-type.minval
$33 = (tree) 0x71d995c8
(gdb) p (type-type.minval)-base
$34 = {code = INTEGER_CST, side_effects_flag = 0, constant_flag = 1, 
  addressable_flag = 0, volatile_flag = 0, readonly_flag = 0, 
  unsigned_flag = 0, asm_written_flag = 0, nowarning_flag = 0, used_flag = 0, 
  nothrow_flag = 0, static_flag = 0, public_flag = 0, private_flag = 0, 
  protected_flag = 0, deprecated_flag = 0, saturating_flag = 0, 
  default_def_flag = 0, lang_flag_0 = 0, lang_flag_1 = 0, lang_flag_2 = 0, 
  lang_flag_3 = 0, lang_flag_4 = 0, lang_flag_5 = 0, lang_flag_6 = 0, 
  visited = 0, packed_flag = 0, user_align = 0, spare = 0, address_space = 0}
(gdb) p (type-type.maxval)-base
$35 = {code = ERROR_MARK, side_effects_flag = 0, constant_flag = 0, 
  addressable_flag = 0, volatile_flag = 0, readonly_flag = 0, 
  unsigned_flag = 0, asm_written_flag = 0, nowarning_flag = 0, used_flag = 0, 
  nothrow_flag = 0, static_flag = 0, public_flag = 0, private_flag = 0, 
  protected_flag = 0, deprecated_flag = 0, saturating_flag = 0, 
  default_def_flag = 0, lang_flag_0 = 0, lang_flag_1 = 0, lang_flag_2 = 0, 
  lang_flag_3 = 0, lang_flag_4 = 0, lang_flag_5 = 0, lang_flag_6 = 0, 
  visited = 0, packed_flag = 0, user_align = 0, spare = 0, address_space = 0}


-- 


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

[Bug tree-optimization/42652] vectorizer created unaligned vector insns

[law at redhat dot com]

--- Comment #7 from law at redhat dot com  2010-01-11 17:16 ---
Subject: Re:  vectorizer created unaligned vector
 insns

On 01/08/10 10:25, rguenth at gcc dot gnu dot org wrote:
 --- Comment #4 from rguenth at gcc dot gnu dot org  2010-01-08 17:25 
 ---
 Well, indeed we have a certain weakness in how we represent pointers to
 possibly (un-)aligned stuff.  See PR39954 for another case.  Maybe this
 bug is really a duplicate of the underlying problems.


PR39954 is slightly different, though it would apply if we started 
looking at passing the address of palette-ents as a parameter.

Jeff


-- 


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

[Bug lto/42665] Internal compiler exception in with gfortran when using -fwhole-program -flto -fopenmp

[rguenther at suse dot de]

--- Comment #10 from rguenther at suse dot de  2010-01-11 17:22 ---
Subject: Re:  Internal compiler exception in with gfortran
 when using  -fwhole-program -flto -fopenmp

On Mon, 11 Jan 2010, jjcogliati-r1 at yahoo dot com wrote:

 
 
 --- Comment #9 from jjcogliati-r1 at yahoo dot com  2010-01-11 17:15 
 ---
 My hunch, (and I could be wrong since my knowledge of gcc's tree code was zero
 as of Friday morning) is that it is trying to find the array's min and max
 size, but that only the min location is available, and that the max value is
 undefined.  Since this is fortran code, there are a number of places that I do
 that.  Is that plausible, and if so, how would I check this hunch?

It should never be error_mark_node ...

 Getting permission for me to get you the full code would involve a lot of
 bureaucracy (weeks to months).  

Oh, I see ...

You could try putting an assert in 
lto-streamer-out.c:lto_output_ts_type_tree_pointers so that
the TYPE_MIN/MAXVAL are not error_mark_node.

That would point you to the file and function.

Richard.

 (gdb) p type-base
 $32 = {code = ARRAY_TYPE, side_effects_flag = 0, constant_flag = 0, 
   addressable_flag = 0, volatile_flag = 0, readonly_flag = 0, 
   unsigned_flag = 0, asm_written_flag = 0, nowarning_flag = 0, used_flag = 0, 
   nothrow_flag = 0, static_flag = 0, public_flag = 0, private_flag = 0, 
   protected_flag = 0, deprecated_flag = 0, saturating_flag = 0, 
   default_def_flag = 0, lang_flag_0 = 0, lang_flag_1 = 0, lang_flag_2 = 0, 
   lang_flag_3 = 0, lang_flag_4 = 0, lang_flag_5 = 0, lang_flag_6 = 0, 
   visited = 0, packed_flag = 0, user_align = 0, spare = 0, address_space = 0}
 (gdb) list
 3717  /* For array types hash their domain and the string flag.  */
 3718  if (TREE_CODE (type) == ARRAY_TYPE
 3719   TYPE_DOMAIN (type))
 3720{
 3721  v = iterative_hash_hashval_t (TYPE_STRING_FLAG (type), v);
 3722  v = visit (TYPE_DOMAIN (type), state, v,
 3723 sccstack, sccstate, sccstate_obstack);
 3724}
 3725
 3726  /* Recurse for aggregates with a single element type.  */
 (gdb) where
 #0  iterative_hash_expr (t=0x71e96b70, val=154387133)
 at ../../gcc-4.5-20100107/gcc/tree.c:6592
 #1  0x005ee1fc in iterative_hash_gimple_type (type=0x71df3888, 
 val=value optimized out, sccstack=0x7fffda38, sccstate=0x126a440, 
 sccstate_obstack=0x7fffd9e0)
 at ../../gcc-4.5-20100107/gcc/gimple.c:3713
 #2  0x005ee843 in visit (t=0x71df3888, state=0x126b4b0, 
 v=1159414094, sccstack=0x7fffda38, sccstate=0x126a440, 
 sccstate_obstack=0x7fffd9e0)
 at ../../gcc-4.5-20100107/gcc/gimple.c:3599
 #3  0x005ee276 in iterative_hash_gimple_type (type=0x71df37e0, 
 val=value optimized out, sccstack=0x7fffda38, sccstate=0x126a440, 
 sccstate_obstack=0x7fffd9e0)
 at ../../gcc-4.5-20100107/gcc/gimple.c:3722
 (gdb) down
 #2  0x005ee843 in visit (t=0x71df3888, state=0x126b4b0, 
 v=1159414094, sccstack=0x7fffda38, sccstate=0x126a440, 
 sccstate_obstack=0x7fffd9e0)
 at ../../gcc-4.5-20100107/gcc/gimple.c:3599
 3599  tem = iterative_hash_gimple_type (t, v,
 (gdb) down
 #1  0x005ee1fc in iterative_hash_gimple_type (type=0x71df3888, 
 val=value optimized out, sccstack=0x7fffda38, sccstate=0x126a440, 
 sccstate_obstack=0x7fffd9e0)
 at ../../gcc-4.5-20100107/gcc/gimple.c:3713
 3713   v = iterative_hash_expr (TYPE_MAX_VALUE (type), v);
 (gdb) p type-type.minval
 $33 = (tree) 0x71d995c8
 (gdb) p (type-type.minval)-base
 $34 = {code = INTEGER_CST, side_effects_flag = 0, constant_flag = 1, 
   addressable_flag = 0, volatile_flag = 0, readonly_flag = 0, 
   unsigned_flag = 0, asm_written_flag = 0, nowarning_flag = 0, used_flag = 0, 
   nothrow_flag = 0, static_flag = 0, public_flag = 0, private_flag = 0, 
   protected_flag = 0, deprecated_flag = 0, saturating_flag = 0, 
   default_def_flag = 0, lang_flag_0 = 0, lang_flag_1 = 0, lang_flag_2 = 0, 
   lang_flag_3 = 0, lang_flag_4 = 0, lang_flag_5 = 0, lang_flag_6 = 0, 
   visited = 0, packed_flag = 0, user_align = 0, spare = 0, address_space = 0}
 (gdb) p (type-type.maxval)-base
 $35 = {code = ERROR_MARK, side_effects_flag = 0, constant_flag = 0, 
   addressable_flag = 0, volatile_flag = 0, readonly_flag = 0, 
   unsigned_flag = 0, asm_written_flag = 0, nowarning_flag = 0, used_flag = 0, 
   nothrow_flag = 0, static_flag = 0, public_flag = 0, private_flag = 0, 
   protected_flag = 0, deprecated_flag = 0, saturating_flag = 0, 
   default_def_flag = 0, lang_flag_0 = 0, lang_flag_1 = 0, lang_flag_2 = 0, 
   lang_flag_3 = 0, lang_flag_4 = 0, lang_flag_5 = 0, lang_flag_6 = 0, 
   visited = 0, packed_flag = 0, user_align = 0, spare = 0, address_space = 0}
 
 
 


-- 


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

[Bug fortran/36161] gfc_error formats are not marked gcc-internal-format in po file

[goeran at uddeborg dot se]

--- Comment #18 from goeran at uddeborg dot se  2010-01-11 17:27 ---
I did try it out as you suggested, and it seems to work just fine.

(I.e. messages from fortran/arith.c were said to come from fortraarith.c in the
pot file.  But I didn't bother to investigate that, it wasn't what I was there
to check.)

I thought we had to wait for gettext 0.18 for this, but apparently not.

One detail I happened to see: The messages defined in gfc_arith_error doesn't
get any gcc-internal-format marker, though they do contain %L.  Do you want a
separate bugzilla about that?


-- 

goeran at uddeborg dot se changed:

   What|Removed |Added

 Status|RESOLVED|VERIFIED


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

[Bug libgcj/42658] [4.5 regression] ICE in _Jv_Linker::verify_class ../.././libjava/link.cc:1904

[davek at gcc dot gnu dot org]

--- Comment #16 from davek at gcc dot gnu dot org  2010-01-11 17:39 ---
Confirmed that it was just a glitch of some kind.


-- 

davek at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID


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

[Bug fortran/41478] Corrupted memory using PACK for derived-types with allocated components

[dominiq at lps dot ens dot fr]

--- Comment #25 from dominiq at lps dot ens dot fr  2010-01-11 17:50 ---
I have applied the patch in comment #19 to a clean fortran-exp and I still see
the segmentation fault when compiling the test in comment #8.


-- 


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

[Bug middle-end/42674] [4.4/4.5 Regression] Bogus no return statement in function returning non-void warning

[manu at gcc dot gnu dot org]

--- Comment #3 from manu at gcc dot gnu dot org  2010-01-11 18:17 ---
There must be some reason why this:

  if (warn_return_type
   TREE_CODE (TREE_TYPE (TREE_TYPE (fndecl))) != VOID_TYPE
   !current_function_returns_value  !current_function_returns_null
  /* Don't complain if we are no-return.  */
   !current_function_returns_abnormally
  /* Don't warn for main().  */
   !MAIN_NAME_P (DECL_NAME (fndecl))
  /* Or if they didn't actually specify a return type.  */
   !C_FUNCTION_IMPLICIT_INT (fndecl)
  /* Normally, with -Wreturn-type, flow will complain, but we might
 optimize out static functions.  */
   !TREE_PUBLIC (fndecl))
{
  warning (OPT_Wreturn_type,
   no return statement in function returning non-void);
  TREE_NO_WARNING (fndecl) = 1;
}

is not triggered in C (even without the __noreturn__?), whereas this is:

  if (warn_return_type
   TREE_CODE (TREE_TYPE (fntype)) != VOID_TYPE
   !dependent_type_p (TREE_TYPE (fntype))
   !current_function_returns_value  !current_function_returns_null
  /* Don't complain if we abort or throw.  */
   !current_function_returns_abnormally
   !DECL_NAME (DECL_RESULT (fndecl))
   !TREE_NO_WARNING (fndecl)
  /* Structor return values (if any) are set by the compiler.  */
   !DECL_CONSTRUCTOR_P (fndecl)
   !DECL_DESTRUCTOR_P (fndecl))
{
  warning (OPT_Wreturn_type,
   no return statement in function returning non-void);
  TREE_NO_WARNING (fndecl) = 1;
}

I think this may be actually two bugs, one is the noreturn which should set
current_function_returns_abnormally to true, so no warning. Another is that the
function is not marked as never returning because of the infinite loop.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org


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

[Bug debug/41371] [4.5 Regression] var-tracking is slow and memory hungry

[jakub at gcc dot gnu dot org]

--- Comment #10 from jakub at gcc dot gnu dot org  2010-01-11 18:23 ---
I've looked briefly at the #c4 testcase, and the problem seems to be extremely
long loc_chains.  var-tracking e.g. stops for huge amount of time (many
minutes) on one bb, EH pad with 162 incoming EH edges (and no others).  Each of
those 162 incoming EH edges has roughly 1800 vars in its out hash table, with
just one problematic one - which has around 650 items in
var-var_part[0].loc_chain chain.  There are ~ 2 other vars with loc_chain
chain lengths in the 40s and the rest is with chain length below 10.  The CPU
eater is intersect_loc_chains.
For each of the 650 loc_chain entries it calls find_loc_in_1pdv, which, as the
vast majority of the entries in s2var's loc_chain are VALUEs, looks stuff up in
the hash table and recurses.

I wonder whether for large loc_chain lengths we just couldn't use a temporary
hash table.  If we see in intersect_loc_chains that chain length is beyond
certain threshold, populate a temporary hash table by doing what
find_loc_in_1pdv does (except instead of rtx_equal_p and returning early it
seeing a match it would record each loc into the hash table and continue
walking).  Then intersect_loc_chains could just walk this hash table instead of
searching through it again and again, avoiding the O(loc_chain_length^2)
complexity.


-- 


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

[Bug fortran/41478] Corrupted memory using PACK for derived-types with allocated components

[pault at gcc dot gnu dot org]

--- Comment #26 from pault at gcc dot gnu dot org  2010-01-11 18:23 ---
(In reply to comment #25)
 I have applied the patch in comment #19 to a clean fortran-exp and I still see
 the segmentation fault when compiling the test in comment #8.
 
A  that's because allocatable scalars are incompletely implemented.

I'll give it a try.

Paul


-- 


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

[Bug c++/42687] The prevention of ADL with the help of parentheses doesn't work

[jwakely dot gcc at gmail dot com]

--- Comment #1 from jwakely dot gcc at gmail dot com  2010-01-11 18:37 
---
This was changed by
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#705 and didn't
appear in the working draft until November.
It's hardly surprising that a compiler released in October doesn't support it


-- 


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

[Bug c++/40146] Unexplained 'anonymous' is used uninitialized in this function warning

[manu at gcc dot gnu dot org]

--- Comment #13 from manu at gcc dot gnu dot org  2010-01-11 18:39 ---
If this doesn't occur in GCC 4.5, the best we can do is to put the testcases in
the testsuite and close this. Many things changed from 4.4. to 4.5 that may
have cause the bug to disappear and that won't be backported, so even looking
for them would be a waste of developer's time.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org


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

[Bug c++/41970] Unjustified anonymous type warning

[manu at gcc dot gnu dot org]

--- Comment #10 from manu at gcc dot gnu dot org  2010-01-11 18:46 ---
(From update of attachment 19531)
This file has nothing to do with this bug.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #19531|0   |1
is obsolete||


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

[Bug c++/41970] Unjustified anonymous type warning

[manu at gcc dot gnu dot org]

--- Comment #11 from manu at gcc dot gnu dot org  2010-01-11 18:52 ---
(In reply to comment #9)
 Please recategorize this report as diagnostic quality, confirm, and assign
 it.

Bugs are not assigned, they are taken. But confirmed it is. Patches welcome.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||diagnostic
   Last reconfirmed|-00-00 00:00:00 |2010-01-11 18:52:09
   date||


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

[Bug c++/41970] use of a type with no linkage to declare a variable with linkage

[manu at gcc dot gnu dot org]

--- Comment #12 from manu at gcc dot gnu dot org  2010-01-11 18:54 ---
Comeau rejects it. Is this accepts-invalid, then?


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|Unjustified anonymous type|use of a type with no
   |warning |linkage to declare a
   ||variable with linkage


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

[Bug lto/42665] Internal compiler exception in with gfortran when using -fwhole-program -flto -fopenmp

[jjcogliati-r1 at yahoo dot com]

--- Comment #11 from jjcogliati-r1 at yahoo dot com  2010-01-11 18:58 
---
(In reply to comment #10)
 Subject: Re:  Internal compiler exception in with gfortran
  when using  -fwhole-program -flto -fopenmp
 
 On Mon, 11 Jan 2010, jjcogliati-r1 at yahoo dot com wrote:
 
  
  
  --- Comment #9 from jjcogliati-r1 at yahoo dot com  2010-01-11 17:15 
  ---
  My hunch, (and I could be wrong since my knowledge of gcc's tree code was 
  zero
  as of Friday morning) is that it is trying to find the array's min and max
  size, but that only the min location is available, and that the max value is
  undefined.  Since this is fortran code, there are a number of places that I 
  do
  that.  Is that plausible, and if so, how would I check this hunch?
 
 It should never be error_mark_node ...

Okay, so:
(gdb) down
#3  0x005ee276 in iterative_hash_gimple_type (type=0x71df37e0, 
val=value optimized out, sccstack=0x7fffda38, sccstate=0x126a440, 
sccstate_obstack=0x7fffd9e0)
at ../../gcc-4.5-20100107/gcc/gimple.c:3722
3722  v = visit (TYPE_DOMAIN (type), state, v,
(gdb) p type-type.values-type.maxval-base
$67 = {code = ERROR_MARK, side_effects_flag = 0, constant_flag = 0, 
  addressable_flag = 0, volatile_flag = 0, readonly_flag = 0, 
  unsigned_flag = 0, asm_written_flag = 0, nowarning_flag = 0, used_flag = 0, 
  nothrow_flag = 0, static_flag = 0, public_flag = 0, private_flag = 0, 
  protected_flag = 0, deprecated_flag = 0, saturating_flag = 0, 
  default_def_flag = 0, lang_flag_0 = 0, lang_flag_1 = 0, lang_flag_2 = 0, 
  lang_flag_3 = 0, lang_flag_4 = 0, lang_flag_5 = 0, lang_flag_6 = 0, 
  visited = 0, packed_flag = 0, user_align = 0, spare = 0, address_space = 0}

That should not have happened, since it is ERROR_MARK

I think the assert that would have triggered would need to check:
TREE_CODE (TYPE_MAX_VALUE (TYPE_DOMAIN (type) )) != ERROR_MARK
tho it would probably need to check a few of the intermediate values.


-- 


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

[Bug tree-optimization/42157] [4.5 regression] ICE building stage 1 libgcc: SEGV in compare_access_positions

[ro at CeBiTec dot Uni-Bielefeld dot DE]

--- Comment #16 from ro at CeBiTec dot Uni-Bielefeld dot DE  2010-01-11 
19:05 ---
Subject: Re:  [4.5 regression] ICE building stage 1 libgcc: SEGV in
compare_access_positions

 --- Comment #13 from ro at CeBiTec dot Uni-Bielefeld dot DE  2010-01-06 
 11:55 ---
[...]
 I'm now running a C-only bootstrap with that patch on mips-sgi-irix5.3.
 Your previous patch allowed a full bootstrap to finish without a
 replacement qsort in libiberty.

That bootstrap finally completed, so the bug is definitely gone on IRIX
5.3, too.

Thanks.
Rainer


-- 


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

[Bug middle-end/42674] [4.4/4.5 Regression] Bogus no return statement in function returning non-void warning

[davek at gcc dot gnu dot org]

--- Comment #4 from davek at gcc dot gnu dot org  2010-01-11 19:07 ---
(In reply to comment #3)
 (even without the __noreturn__?)

  Yes, even without.

 I think this may be actually two bugs, one is the noreturn which should set
 current_function_returns_abnormally to true, so no warning. Another is that 
 the
 function is not marked as never returning because of the infinite loop.

  Sounds right to me.  Ok to leave them both under this one PR, or should we
separate them?


-- 


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

[Bug middle-end/14187] [tree-ssa] C restricted pointers are not properly implemented

[manu at gcc dot gnu dot org]

--- Comment #18 from manu at gcc dot gnu dot org  2010-01-11 19:23 ---
(In reply to comment #17)
 Fixed.
 

Richard, since this is a new feature of GCC 4.5, shouldn't we mention it in the
GCC 4.5 changes.html?

Even something short would be welcome by users, such as:

Better optimizations when using the a
href=http://gcc.gnu.org/onlinedocs/gcc/Restricted-Pointers.html;restrict
keyword/a.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org


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

[Bug middle-end/42691] New: Wrong REG_EQUAL note is added to SUBREG node

[jingyu at google dot com]

A wrong REG_EQUAL is attached to SUBREG during forward propagation.

Before fwprop1 
(insn 56 55 57 3 double.cpp:12 (set (reg/v:DI 180 [ _D_inf ])
(const_int 0 [0x0])) 164 {*thumb1_movdi_insn} (nil))
(insn 60 59 61 3 double.cpp:12 (set (reg:SI 189)
(const_int 2146435072 [0x7ff0])) 168 {*thumb1_movsi_insn} (nil))
(insn 62 61 63 3 double.cpp:12 (set (subreg:SI (reg/v:DI 180 [ _D_inf ]) 4)
(reg:SI 189)) 168 {*thumb1_movsi_insn} (nil))

After fwprop1, a note REG_EQUAL (const_int 2146435072 [0x7ff0] is
attached to insn 62.

(insn 56 54 60 3 double.cpp:12 (set (reg/v:DI 180 [ _D_inf ])
(const_int 0 [0x0])) 164 {*thumb1_movdi_insn} (nil))
(insn 60 56 62 3 double.cpp:12 (set (reg:SI 189)
(const_int 2146435072 [0x7ff0])) 168 {*thumb1_movsi_insn} (nil))

(insn 62 60 63 3 double.cpp:12 (set (subreg:SI (reg/v:DI 180 [ _D_inf ]) 4)
(reg:SI 189)) 168 {*thumb1_movsi_insn} (expr_list:REG_EQUAL (const_int
2
146435072 [0x7ff0])
(nil)))

Then at combine pass, when the three insns are combined into one insn, the
operand of the set note becomes [0x7ff0], but the REG_EQUAL note is
still [0x7ff0].

(insn 62 155 63 3 double.cpp:12 (set (reg/v:DI 180 [ _D_inf ])
(const_int 9218868437227405312 [0x7ff0])) 164
{*thumb1_movdi_insn} (expr_list:REG_EQUAL (const_int 2146435072 [0x7ff0])
(nil)))

If the wrong REG_EQUAL is not used in later optimization, then nothing wrong is
observed. However, we find a case that the bug is triggered at ira pass.

What happens is at ira pass, in reload() (reload1.c), gcc tries to find SET
REG(regno) = const N. When gcc finds one, it records constant equivalent in
reg_equiv_constant so that the use of the register will be substituted by
find_reloads. gcc puts reg_equiv_constant[regno]=x. However, notice that, x
here is the value from the REG_EQUAL note, not the SET operand. In our case,
the value in reg 180 is 0x7ff0, but gcc says
reg_equiv_constant[180]=0x7ff0. Later, when gcc tries to simplify the
SUBREG for insn 65, it picks the wrong value in reg_equiv_const[180] and passes
the wrong value to insn 65.

(insn 65 64 66 3 double.cpp:13 (set (reg:DF 2 r2)
(subreg:DF (reg/v:DI 180 [ _D_inf ]) 0)) 183 {*thumb_movdf_insn} (nil))

becomes

(insn 65 64 66 3 double.cpp:13 (set (reg:DF 2 r2)
(const_double:DF 1.06047983010398252661938461763305382790433594771e-314 
[0x0.ffep-1043])) 183 {*thumb_movdf_insn} (nil))

The const_double in insn 65 is wrong.


test case double.cpp:

union _D_rep {
  unsigned short rep[4];
  double val;
};

int add(double* key, double* table)
{
  unsigned i = 0;
  double* deletedEntry = 0;
  while (1) {
double* entry = table + i;
_D_rep _D_inf = {{ 0, 0, 0, 0x7ff0 }};
if (*entry == _D_inf.val)
  break;

if (*entry == *key)
  return 0;

_D_rep _D_inf2 = {{ 0, 0, 0, 0x7ff0 }};
if (_D_inf2.val)
  deletedEntry = entry;

i++;
  }
  if (deletedEntry)
return 1;
  return 0;
}

The command is:
arm-eabi-g++ -Os -mthumb double.cpp -c -o double.o


-- 
   Summary: Wrong REG_EQUAL note is added to SUBREG node
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jingyu at google dot com
 GCC build triplet: X86_64-linux-gnu
  GCC host triplet: X86_64-linux-gnu
GCC target triplet: arm-unknown-eabi


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

[Bug middle-end/42691] Wrong REG_EQUAL note is added to SUBREG node

[jingyu at google dot com]

--- Comment #1 from jingyu at google dot com  2010-01-11 19:59 ---
I forgot to paste the wrong assembly code.

arm-eabi-g++ -Os -mthumb double.cpp --save-temps -c -o double.o

The assembly for the following part
_D_rep _D_inf = {{ 0, 0, 0, 0x7ff0 }};
if (*entry == _D_inf.val)
  break;
is
ldr r3, .L10+4  ;;  _D_inf higher part
ldr r2, .L10  ;; _D_inf lower part
mov r0, r5
mov r1, r6
bl  __aeabi_dcmpeq

.L10:
.word   2146435072  ;; 0x7ff0
.word   0

The value loaded for _D_inf is wrong.
It is a little-endian target.


-- 


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

[Bug fortran/36161] gfc_error formats are not marked gcc-internal-format in po file

[burnus at gcc dot gnu dot org]

--- Comment #19 from burnus at gcc dot gnu dot org  2010-01-11 20:21 ---
(In reply to comment #1)
 One detail I happened to see: The messages defined in gfc_arith_error doesn't
 get any gcc-internal-format marker, though they do contain %L.  Do you want a
 separate bugzilla about that?

Yes please.


-- 


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

[Bug c++/42692] New: Invalid member lookup when member template class is involved

[igusarov at mail dot ru]

The bug is: if a class definition has a nested template class, then whenever a
code refers to a name in the nested class, gcc searches it not in the nested
template class, but it the outer class.

The bug results in gcc accepting a source text that should not be compiled, and
incorrectly compiling a valid source text. Complete compilable example is
included at the end of this report. I was able to reproduce this behaviour back
to gcc 4.2.1, 3.3.2 and 2.95.3.

Explanation. Please consider the following class definition:

struct root
{
  template typename Y
  struct chain
  {
  };
};

As you see, the structure root::chainany_type has no members. However, gcc
accepts and compiles type declarations like

typedef  root::chaintype_1::chaintype_2::chaintype_3   my_type;

, where my_type becomes root::chaintype_3, asif each chain template were
looked up in the root class.

You can use the following example to reproduce the bug. The example is
compilable, which is wrong.

//---
struct root
{
  template typename Y
  struct chain
  {
  };
};

struct o1;
struct o2;
struct o3;

typedef   root::chaino1 p1;
typedef   root::chaino2::chaino1  p2;  /* - should be error */
typedef   root::chaino3::chaino2::chaino1   p3;  /* - should be error */

int main()
{
  p1 x1;
  p2 x2;
  p3 x3;

  x1 = x2 = x3; /* gcc thinks that they are of the same type! */

  return 0;
}


-- 
   Summary: Invalid member lookup when member template class is
involved
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igusarov at mail dot ru
 GCC build triplet: amd64-unknown-freebsd7.1
  GCC host triplet: amd64-unknown-freebsd7.1
GCC target triplet: amd64-unknown-freebsd7.1


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

[Bug target/42416] ICE in rs6000_bulitin_vec_perm for 177.mesa with -mvsx

[janis at gcc dot gnu dot org]

--- Comment #5 from janis at gcc dot gnu dot org  2010-01-11 20:29 ---
Subject: Bug 42416

Author: janis
Date: Mon Jan 11 20:29:40 2010
New Revision: 155816

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155816
Log:
PR target/42416
* config/rs6000/rs6000.c (rs6000_override_options): On targets
that support VSX, warn for -mno-altivec if vsx is not disabled,
and disable vsx.
* gcc.target/powerpc/warn-1.c: New test.
* gcc.target/powerpc/warn-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/powerpc/warn-1.c
trunk/gcc/testsuite/gcc.target/powerpc/warn-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/42692] Invalid member lookup when member template class is involved

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2010-01-11 20:59 
---
Mainline is fine.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to fail||4.4.1
  Known to work||4.5.0
 Resolution||WORKSFORME


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

[Bug fortran/42693] New: Missing gcc-internal-format on messages from gfc_arith_error

[goeran at uddeborg dot se]

The strings returned from gfc_arith_error in gcc/fortran/arith.h contain the
location marker %L.  But as noticed in bug 36161, they are not marked
gcc-internal-format.  This marking is valuable to avoid mistakes in the
translation.


-- 
   Summary: Missing gcc-internal-format on messages from
gfc_arith_error
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: goeran at uddeborg dot se


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

[Bug fortran/36161] gfc_error formats are not marked gcc-internal-format in po file

[goeran at uddeborg dot se]

--- Comment #20 from goeran at uddeborg dot se  2010-01-11 21:02 ---
(In reply to comment #19)
 Yes please.

I've filed bug 42693 about that.


-- 


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

[Bug ada/42518] Alignment issue prevents building 64 bit RTS on Snow Leopard

[simon at pushface dot org]

--- Comment #14 from simon at pushface dot org  2010-01-11 21:35 ---
Concur with Eric.

Um, I could submit a patch for PR middle-end/42068 if it would help? Not aware
of procedure here.


-- 


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

[Bug rtl-optimization/42694] New: Compiler could optimize pow (x, 0.75) into sqrt (x) * sqrt (sqrt (x))

[meissner at gcc dot gnu dot org]

Right now, the compiler has no special code to optimize pow (x, 0.75) into
something like sqrt (x) * sqrt (sqrt (x)) under -ffast-math, nor pow (x, 0.25)
into sqrt (sqrt (x)).  On machines with a builtin sqrt instruction, it is often
times faster to do the calculations using sqrt than calling the pow function. 
In particular, x**0.75 shows up in the bwaves spec 2006 benchmark.

For sqrt (sqrt (x)) vs pow (x, 0.25), I see:
IBM power6: 9.2 times faster
Intel core2 laptop: 5 times faster
AMD K8 system: 3.2 times faster

For sqrt (x) * sqrt (sqrt (x)) vs. pow (x, 0.75), I see:
IBM power6: 6.1 times faster
Intel core2 laptop: 3.4 times faster
AMD K8 system: 2.3 times faster

In addition, the compiler optimizes sqrt (sqrt (x)) into pow (x, 0.25), and
similar optimizations.

This should be fixed by adding a hook to say what the relative speed of sqrt
and cbrt vs. pow, so that the backend can control whether or not this
optimization should be done.  By default, the optimization is probably only
useful if -Os is used on machines that have a hardware sqrt instruction.


-- 
   Summary: Compiler could optimize pow (x, 0.75) into sqrt (x) *
sqrt (sqrt (x))
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: meissner at gcc dot gnu dot org
ReportedBy: meissner at gcc dot gnu dot org
 GCC build triplet: powerpc64-unknown-linux-gnu
  GCC host triplet: powerpc64-unknown-linux-gnu
GCC target triplet: powerpc64-unknown-linux-gnu


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

[Bug ada/42518] Alignment issue prevents building 64 bit RTS on Snow Leopard

[ebotcazou at gcc dot gnu dot org]

--- Comment #15 from ebotcazou at gcc dot gnu dot org  2010-01-11 21:41 
---
 Um, I could submit a patch for PR middle-end/42068 if it would help? Not aware
 of procedure here.

You'd need to go through the full testing procedure described here:
  http://gcc.gnu.org/contribute.html


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX


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

[Bug rtl-optimization/42694] Compiler could optimize pow (x, 0.75) into sqrt (x) * sqrt (sqrt (x))

[meissner at gcc dot gnu dot org]

--- Comment #1 from meissner at gcc dot gnu dot org  2010-01-11 21:42 
---
Created an attachment (id=19542)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19542action=view)
Program to demonstrate the slowdown

This program calculates the speed of various pow arguments.


-- 


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

[Bug bootstrap/42695] New: gcc/config/vxworks.c not compatible with gcc/tree

[simon at pushface dot org]

The build fails with

../../gcc-trunk-svn/gcc/config/vxworks.c: In function
‘vxworks_emutls_var_fields’:
../../gcc-trunk-svn/gcc/config/vxworks.c:73:27: error: macro build_decl
requires 4 arguments, but only 3 given
../../gcc-trunk-svn/gcc/config/vxworks.c:72:11: error: ‘build_decl’ undeclared
(first use in this function)
../../gcc-trunk-svn/gcc/config/vxworks.c:72:11: error: (Each undeclared
identifier is reported only once
../../gcc-trunk-svn/gcc/config/vxworks.c:72:11: error: for each function it
appears in.)
../../gcc-trunk-svn/gcc/config/vxworks.c:78:27: error: macro build_decl
requires 4 arguments, but only 3 given
../../gcc-trunk-svn/gcc/config/vxworks.c:84:27: error: macro build_decl
requires 4 arguments, but only 3 given

because in gcc/tree.h r148442 a new argument of type location_t was inserted in
the first position in build_decl_stat().

I got the build to proceed by supplying UNKNOWN_LOCATION for this parameter (as
in builtins.c).


-- 
   Summary: gcc/config/vxworks.c not compatible with gcc/tree
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: simon at pushface dot org
 GCC build triplet: i386-apple-darwin9.6.0
  GCC host triplet: i386-apple-darwin9.6.0
GCC target triplet: powerpc-wrs-vxworks


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

[Bug bootstrap/42695] gcc/config/vxworks.c not compatible with gcc/tree

[simon at pushface dot org]

--- Comment #1 from simon at pushface dot org  2010-01-11 21:47 ---
Created an attachment (id=19543)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19543action=view)
Patch to gcc/config/vxworks.c

Adds new parameter required by change to gcc/tree.


-- 


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

[Bug middle-end/41674] [4.5 Regression] /usr/ccs/bin/ld: Unsatisfied symbols: _GLOBAL__I_65535_0_main

[danglin at gcc dot gnu dot org]

--- Comment #9 from danglin at gcc dot gnu dot org  2010-01-11 21:51 ---
Patch here:
http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00066.html


-- 


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

[Bug rtl-optimization/42691] problematic REG_EQUAL note added to SUBREG

[ebotcazou at gcc dot gnu dot org]

--- Comment #2 from ebotcazou at gcc dot gnu dot org  2010-01-11 22:00 
---
The REG_EQUAL note is correct after fwprop but not after combine, so the
problem lies in combine.  The note should have been removed by
adjust_for_new_dest since the destination of I3 has changed.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu dot
   ||org
  Component|middle-end  |rtl-optimization
Summary|Wrong REG_EQUAL note is |problematic REG_EQUAL note
   |added to SUBREG node|added to SUBREG


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

[Bug middle-end/42245] ICE in verify_backedges for 197.parser with sel-sched

[janis at gcc dot gnu dot org]

--- Comment #8 from janis at gcc dot gnu dot org  2010-01-11 22:10 ---
I bootstrapped on powerpc64-linux c,c++,fortran with the earlier big
selective-scheduling patch plus the patch in comment #7 of this PR and the
patch in comment #4 of PR42246.  The resulting GCC gets no failures for SPEC
CPU2000 using several combinations of selective-scheduling options.  Thanks for
being so responsive!


-- 


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

[Bug middle-end/42068] [4.5 regression] ICE in function_and_variable_visibility breaks Ada bootstrap

[simon at pushface dot org]

--- Comment #10 from simon at pushface dot org  2010-01-11 22:12 ---
I have (locally!) rolled back the change to ipa.c in r154121 as suggested and
successfully built a compiler which successfully compiles the test case in
p.txt. Will that be an adequate basis for a patch to resolve this PR for 4.5.0?


-- 


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

[Bug fortran/42693] Missing gcc-internal-format on messages from gfc_arith_error

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2010-01-11 22:29 ---
Confirm. One possibility would be to modify
  gcc/po/exgettext
to recognize %L -- while a simple hack would be to use:

--- arith.c (Revision 155812)
+++ arith.c
@@ -91,6 +91,7 @@
   switch (code)
 {
 case ARITH_OK:
+  /* xgettext:gcc-internal-format */
   p = _(Arithmetic OK at %L);
   break;
 case ARITH_OVERFLOW:

etc.


-- 


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

[Bug c/42483] AVR fails all whopr/lto tests

[hutchinsonandy at gcc dot gnu dot org]

--- Comment #1 from hutchinsonandy at gcc dot gnu dot org  2010-01-11 23:21 
---
Due to target defining linker name.

Fixed 4.5 HEAD

Author: hutchinsonandy
Date: Mon Jan 11 23:12:14 2010
New Revision: 155819

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155819
Log:
2010-01-11  Andy Hutchinson  hutchinsona...@gcc.gnu.org

* config/avr/avr.h (LINKER_NAME): Remove. 

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/avr/avr.h


-- 

hutchinsonandy at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug target/42542] Vectorizer produces incorrect results on max/min of unsigned intergers

[sje at cup dot hp dot com]

--- Comment #21 from sje at cup dot hp dot com  2010-01-11 23:32 ---
Created an attachment (id=19544)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19544action=view)
ia64 patch (fixes int, not short or char)


-- 


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

[Bug target/42542] Vectorizer produces incorrect results on max/min of unsigned intergers

[sje at cup dot hp dot com]

--- Comment #22 from sje at cup dot hp dot com  2010-01-11 23:33 ---
I am looking at this on IA64 and fixing it for V2SI seems simple enough.  
I will attach a patch.  But I am not sure what to do for V4HI and V8QI. 
The current code uses an 'unsigned saturating subtraction' and that
seems to be what x86 is using for V16QI and V8HI.  But when I run
pr42542-2.c and pr42542-3.c (short and char) on IA64 they fail.  My
patch does make pr42542-1.c (int) work.  I tried handling V4HI and V8QI
in the same way as V2SI but that didn't seem to work either.


-- 


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

[Bug target/42542] Vectorizer produces incorrect results on max/min of unsigned intergers

[hjl dot tools at gmail dot com]

--- Comment #23 from hjl dot tools at gmail dot com  2010-01-12 00:41 
---
(In reply to comment #22)
 I am looking at this on IA64 and fixing it for V2SI seems simple enough.  
 I will attach a patch.  But I am not sure what to do for V4HI and V8QI. 
 The current code uses an 'unsigned saturating subtraction' and that
 seems to be what x86 is using for V16QI and V8HI.  But when I run
 pr42542-2.c and pr42542-3.c (short and char) on IA64 they fail.  My
 patch does make pr42542-1.c (int) work.  I tried handling V4HI and V8QI
 in the same way as V2SI but that didn't seem to work either.
 

What was the problem with V4HI and V8QI? The existing code works
OK on pr42542-2.c and pr42542-3.c for me.


-- 


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

[Bug lto/42696] New: lto1 error with -fsigned-char and char comparison

[janis at gcc dot gnu dot org]

SPEC CPU2006 tests 464.h264ref and 482.sphinx3 fail to build on powerpc64-linux
with -m64 -lto -fsigned-char.  For some reason we've added the option
-fsigned-char to the SPEC config files for those two tests; without it both
tests fail at runtime for -m64, but it doesn't affect the results for -m32. 
The failure to build with -flto might be due to some problem with -fsigned-char
on powerpc64, rather than a problem with LTO.

Here's a minimized testcase:

-
extern char *a;
extern int f;

void
foo (void)
{
  f = (*a != '-');
} 
-

And here's what happens:

elm3b149% /home/janis/tools/gcc-trunk-anonsvn/bin/gcc -m64 -flto -fsigned-char
bug.c -c
elm3b149% /home/janis/tools/gcc-trunk-anonsvn/bin/gcc -m64 -flto -fsigned-char
bug.o -shared -o x.so
In function ‘foo’:
lto1: error: type mismatch in indirect reference
unnamed-signed:8
unnamed-unsigned:8

D.1228_2 = *a.0_1;

lto1: internal compiler error: verify_stmts failed
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
lto-wrapper: /home/janis/tools/gcc-trunk-anonsvn/bin/gcc returned 1 exit status
collect2: lto-wrapper returned 1 exit status

If the type of 'a' is signed char then everything works fine.


-- 
   Summary: lto1 error with -fsigned-char and char comparison
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janis at gcc dot gnu dot org
GCC target triplet: powerpc64-linux


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

[Bug libstdc++/35569] [c++0x] std::bind result functor doesn't accept rvalues

[redi at gcc dot gnu dot org]

--- Comment #11 from redi at gcc dot gnu dot org  2010-01-12 00:54 ---
Subject: Bug 35569

Author: redi
Date: Tue Jan 12 00:53:30 2010
New Revision: 155826

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155826
Log:
2010-01-12  Jonathan Wakely  jwakely@gmail.com

PR libstdc++/24803
PR libstdc++/35569
PR libstdc++/42593
* include/std/functional (bind): Forward rvalues and detect correct
result type of bound function object.
* include/std/mutex (call_once): Specify bind result type.
* testsuite/20_util/reference_wrapper/invoke.cc: Remove invalid tests.
* testsuite/20_util/reference_wrapper/24803.cc: Remove invalid tests
and enable FIXME tests.
* testsuite/20_util/bind/35569.cc: New.
* testsuite/20_util/bind/ref2.cc: New.
* testsuite/20_util/bind/38889.cc: New.
* testsuite/20_util/bind/ref_neg.cc: New.
* testsuite/20_util/bind/42593.cc: New.


Added:
trunk/libstdc++-v3/testsuite/20_util/bind/35569.cc
trunk/libstdc++-v3/testsuite/20_util/bind/38889.cc
trunk/libstdc++-v3/testsuite/20_util/bind/42593.cc
trunk/libstdc++-v3/testsuite/20_util/bind/ref2.cc
trunk/libstdc++-v3/testsuite/20_util/bind/ref_neg.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/functional
trunk/libstdc++-v3/include/std/mutex
trunk/libstdc++-v3/testsuite/20_util/reference_wrapper/24803.cc
trunk/libstdc++-v3/testsuite/20_util/reference_wrapper/invoke.cc


-- 


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

[Bug libstdc++/42593] [c++0x] [4.5 Regression] std::bind not assignable to std::function

[redi at gcc dot gnu dot org]

--- Comment #17 from redi at gcc dot gnu dot org  2010-01-12 00:54 ---
Subject: Bug 42593

Author: redi
Date: Tue Jan 12 00:53:30 2010
New Revision: 155826

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155826
Log:
2010-01-12  Jonathan Wakely  jwakely@gmail.com

PR libstdc++/24803
PR libstdc++/35569
PR libstdc++/42593
* include/std/functional (bind): Forward rvalues and detect correct
result type of bound function object.
* include/std/mutex (call_once): Specify bind result type.
* testsuite/20_util/reference_wrapper/invoke.cc: Remove invalid tests.
* testsuite/20_util/reference_wrapper/24803.cc: Remove invalid tests
and enable FIXME tests.
* testsuite/20_util/bind/35569.cc: New.
* testsuite/20_util/bind/ref2.cc: New.
* testsuite/20_util/bind/38889.cc: New.
* testsuite/20_util/bind/ref_neg.cc: New.
* testsuite/20_util/bind/42593.cc: New.


Added:
trunk/libstdc++-v3/testsuite/20_util/bind/35569.cc
trunk/libstdc++-v3/testsuite/20_util/bind/38889.cc
trunk/libstdc++-v3/testsuite/20_util/bind/42593.cc
trunk/libstdc++-v3/testsuite/20_util/bind/ref2.cc
trunk/libstdc++-v3/testsuite/20_util/bind/ref_neg.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/functional
trunk/libstdc++-v3/include/std/mutex
trunk/libstdc++-v3/testsuite/20_util/reference_wrapper/24803.cc
trunk/libstdc++-v3/testsuite/20_util/reference_wrapper/invoke.cc


-- 


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

[Bug libstdc++/24803] [c++0x] reference_wrapper and pointers to member functions

[redi at gcc dot gnu dot org]

--- Comment #18 from redi at gcc dot gnu dot org  2010-01-12 00:54 ---
Subject: Bug 24803

Author: redi
Date: Tue Jan 12 00:53:30 2010
New Revision: 155826

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155826
Log:
2010-01-12  Jonathan Wakely  jwakely@gmail.com

PR libstdc++/24803
PR libstdc++/35569
PR libstdc++/42593
* include/std/functional (bind): Forward rvalues and detect correct
result type of bound function object.
* include/std/mutex (call_once): Specify bind result type.
* testsuite/20_util/reference_wrapper/invoke.cc: Remove invalid tests.
* testsuite/20_util/reference_wrapper/24803.cc: Remove invalid tests
and enable FIXME tests.
* testsuite/20_util/bind/35569.cc: New.
* testsuite/20_util/bind/ref2.cc: New.
* testsuite/20_util/bind/38889.cc: New.
* testsuite/20_util/bind/ref_neg.cc: New.
* testsuite/20_util/bind/42593.cc: New.


Added:
trunk/libstdc++-v3/testsuite/20_util/bind/35569.cc
trunk/libstdc++-v3/testsuite/20_util/bind/38889.cc
trunk/libstdc++-v3/testsuite/20_util/bind/42593.cc
trunk/libstdc++-v3/testsuite/20_util/bind/ref2.cc
trunk/libstdc++-v3/testsuite/20_util/bind/ref_neg.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/functional
trunk/libstdc++-v3/include/std/mutex
trunk/libstdc++-v3/testsuite/20_util/reference_wrapper/24803.cc
trunk/libstdc++-v3/testsuite/20_util/reference_wrapper/invoke.cc


-- 


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

[Bug libstdc++/35569] [c++0x] std::bind result functor doesn't accept rvalues

[redi at gcc dot gnu dot org]

--- Comment #12 from redi at gcc dot gnu dot org  2010-01-12 00:54 ---
Fixed for 4.5.0


-- 

redi at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.5.0


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

[Bug libstdc++/42593] [c++0x] [4.5 Regression] std::bind not assignable to std::function

[redi at gcc dot gnu dot org]

--- Comment #18 from redi at gcc dot gnu dot org  2010-01-12 00:55 ---
Fixed for 4.5.0


-- 

redi at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.5.0


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

[Bug target/42542] Vectorizer produces incorrect results on max/min of unsigned intergers

[sje at cup dot hp dot com]

--- Comment #24 from sje at cup dot hp dot com  2010-01-12 00:58 ---
Never mind, when I copied (and modified) the x86 tests for ia64 I forgot to put
a 'return 0' at the end of the main program so I was getting a non-zero exit. 
I will test my patch tonight and if all looks good submit it tomorrow.


-- 


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

[Bug c++/41970] use of a type with no linkage to declare a variable with linkage

[redi at gcc dot gnu dot org]

--- Comment #13 from redi at gcc dot gnu dot org  2010-01-12 01:00 ---
(In reply to comment #12)
 Comeau rejects it. Is this accepts-invalid, then?
 

I think so, as I suggested in comment 3


-- 


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

[Bug c++/41970] use of a type with no linkage to declare a variable with linkage

[redi at gcc dot gnu dot org]

--- Comment #14 from redi at gcc dot gnu dot org  2010-01-12 01:08 ---
(In reply to comment #9)
 requires six posts from experts to explain.

I'm not sure where you got that number, after my second comment I was
correcting my own typos or your misunderstanding of unnamed namespaces :)


-- 


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

[Bug c++/41970] use of a type with no linkage to declare a variable with linkage

[igodard at pacbell dot net]

--- Comment #15 from igodard at pacbell dot net  2010-01-12 01:12 ---
Should I submit a second report so there is one for accepts invalid and a
different one for diagnostic quality?


-- 


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

[Bug rtl-optimization/42691] problematic REG_EQUAL note added to SUBREG

[jingyu at google dot com]

--- Comment #3 from jingyu at google dot com  2010-01-12 02:45 ---
Subject: Re:  problematic REG_EQUAL note added to 
SUBREG

On Mon, Jan 11, 2010 at 2:00 PM, ebotcazou at gcc dot gnu dot org
gcc-bugzi...@gcc.gnu.org wrote:


 --- Comment #2 from ebotcazou at gcc dot gnu dot org  2010-01-11 22:00 
 ---
 The REG_EQUAL note is correct after fwprop but not after combine, so the
 problem lies in combine.  The note should have been removed by
 adjust_for_new_dest since the destination of I3 has changed.


Unfortunately, the note is not removed by adjust_for_new_dest.

I traced gcc and saw how it combined insn 156 and insn 62.

First, gcc works out a new pattern newpat which sets
0x7ff0 to reg 180 and jumps to validate_replacement,
where it checks if the result of combination a valid instruction.

line3061:  /* Is the result of combination a valid instruction?  */
line3062:  insn_code_number = recog_for_combine (newpat, i3, new_i3_notes);

In our case, insn_code_number is 164.

Then gcc comes to line3657. Since changed_i3_dest is 0, gcc does not
call adjust_for_new_dest at all.

line3657:
if (changed_i3_dest)
{
  PATTERN (i3) = newpat;
  adjust_for_new_dest (i3);
}

After this, there is no chance where the note of i3 can be removed.

I did not read the entire combine pass. So I am not sure whether it is
fine to just add something like this after line3062 where
recog_for_combine is called.

  if (insn_code_number = 0)
changed_i3_dest = 1;

Another option to fix this problem is not to attach REG_EQUAL note to
set subreg reg at all during forward propagation.
Index: fwprop.c
==
=
--- fwprop.c(revision 155510)
+++ fwprop.c(working copy)
@@ -1297,7 +1297,7 @@ forward_propagate_and_simplify (df_ref u
   recognized.  Either we're already replacing in the note, or
   we'll separately try plugging the definition in the note and
   simplifying.  */
-  set_reg_equal = (note == NULL_RTX);
+  set_reg_equal = (note == NULL_RTX  REG_P (SET_DEST (use_set)));
   }

 if (GET_MODE (*loc) == VOIDmode)

I have tested this patch on arm-unknown-eabi target. There is no regression.

What do you think?

Thanks,
Jing


 --

 ebotcazou at gcc dot gnu dot org changed:

           What    |Removed                     |Added
 
                 CC|                            |ebotcazou at gcc dot gnu dot
                   |                            |org
          Component|middle-end                  |rtl-optimization
            Summary|Wrong REG_EQUAL note is     |problematic REG_EQUAL note
                   |added to SUBREG node        |added to SUBREG


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

 --- You are receiving this mail because: ---
 You reported the bug, or are watching the reporter.



-- 


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

[Bug middle-end/41290] [4.5 regression] ICE: edge points to wrong declaration

[foom at fuhm dot net]

--- Comment #13 from foom at fuhm dot net  2010-01-12 06:27 ---
The crash is still present for my code. I'm using:
g++ (Debian 20091228-2) 4.5.0 20091228 (experimental) [trunk revision 155486]
on AMD64.

Passing -fno-ipa-cp also makes the bug disappear for me. But apparently r154673
did not fix the underlying issue, only make it unreproducible with the test
case here. I can try again to minimize, but I'm not optimistic: this bug seems
to appear and disappear almost randomly with minor adjustments to the code, and
unfortunately I cannot post my complete code.


-- 


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