[Bug target/42894] ICE internal consistency failure

[ramana at gcc dot gnu dot org]

--- Comment #2 from ramana at gcc dot gnu dot org  2010-01-29 08:02 ---
Created an attachment (id=19748)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19748&action=view)
Testcase

This is a Thumb1 ICE. For completeness , the architecture flags to be used are
-march=armv5te -mthumb. 

Attached is a reduced testcase. 


-- 


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

[Bug target/42894] Invalid rtl sharing in Thumb1.

[ramana at gcc dot gnu dot org]

--- Comment #3 from ramana at gcc dot gnu dot org  2010-01-29 08:04 ---
Confirmed. 


-- 

ramana at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||ice-on-valid-code
  Known to fail||4.5.0
  Known to work||4.4.3
   Last reconfirmed|-00-00 00:00:00 |2010-01-29 08:04:43
   date||
Summary|ICE internal consistency|Invalid rtl sharing in
   |failure |Thumb1.


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

[Bug target/42894] Invalid rtl sharing in Thumb1.

[ramana at gcc dot gnu dot org]

--- Comment #4 from ramana at gcc dot gnu dot org  2010-01-29 08:30 ---
Marking as P2 .


-- 

ramana at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org, rearnsha at gcc dot gnu
   ||dot org
 GCC target triplet|arm-oe-linux-uclibceabi |arm-oe-linux-uclibceabi,
   ||arm-linux-gnueabi
   Priority|P3  |P2
   Target Milestone|--- |4.5.0


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

[Bug c++/42748] warnings about 'mangling of 'va_list' has changed in GCC 4.4' not suppressed in sytem headers

[doko at ubuntu dot com]

--- Comment #12 from doko at ubuntu dot com  2010-01-29 08:37 ---
checked the patch on the 4.4 branch; the error message for the test case in the
original report is gone, but there are some warnings about the mangling in the
libstdc++ files as well. not reopening yet, as I didn't check a build on the
trunk yet.

/home/doko/gcc/4.4/gcc-4.4-4.4.3/src/libstdc++-v3/testsuite/18_support/exception
_ptr/rethrow_exception.cc:114: note: the mangling of 'va_list' has changed in
GC
C 4.4
output is:
/home/doko/gcc/4.4/gcc-4.4-4.4.3/src/libstdc++-v3/testsuite/18_support/exception
_ptr/rethrow_exception.cc:114: note: the mangling of 'va_list' has changed in
GC
C 4.4

FAIL: 18_support/exception_ptr/rethrow_exception.cc (test for excess errors)

/home/doko/gcc/4.4/gcc-4.4-4.4.3/src/libstdc++-v3/testsuite/19_diagnostics/error
_category/cons/default.cc:33: note: the mangling of 'va_list' has changed in
GCC
 4.4
output is:
/home/doko/gcc/4.4/gcc-4.4-4.4.3/src/libstdc++-v3/testsuite/19_diagnostics/error
_category/cons/default.cc:33: note: the mangling of 'va_list' has changed in
GCC
 4.4

FAIL: 19_diagnostics/error_category/cons/default.cc (test for excess errors)
/home/doko/gcc/4.4/gcc-4.4-4.4.3/src/libstdc++-v3/testsuite/19_diagnostics/error
_category/operators/equal.cc:34: note: the mangling of 'va_list' has changed in 
GCC 4.4

FAIL: 19_diagnostics/error_code/cons/1.cc (test for excess errors)
Excess errors:
/home/doko/gcc/4.4/gcc-4.4-4.4.3/src/libstdc++-v3/testsuite/19_diagnostics/error_code/cons/1.cc:45:
note: the mangling of 'va_list' has changed in GCC 4.4


-- 


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

[Bug target/42895] Low registers are preferred than register ip in thumb2 mode

[steven at gcc dot gnu dot org]

--- Comment #3 from steven at gcc dot gnu dot org  2010-01-29 08:42 ---
See arm.c:#define REG_ALLOC_ORDER. Comment before it says: " It is good to use
ip since no saving is required (though calls clobber it) and it never contains
function parameters. It is quite good to use lr since other calls may clobber
it anyway."

So in REG_ALLOC_ORDER, ip (reg 12) and lr (reg 14) come before before r4-r7:

#define REG_ALLOC_ORDER \
{   \
 3,  2,  1,  0, 12, 14,  4,  5, \
 6,  7,  8, 10,  9, 11, 13, 15, \
16, 17, 18, 19, 20, 21, 22, 23, \
27, 28, 29, 30, 31, 32, 33, 34, \
35, 36, 37, 38, 39, 40, 41, 42, \
43, 44, 45, 46, 47, 48, 49, 50, \
51, 52, 53, 54, 55, 56, 57, 58, \
59, 60, 61, 62, \
24, 25, 26, \

So the register allocator faithfully does what the IBTK has asked it to :-)


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

  GCC build triplet|i686-linux  |
   GCC host triplet|i686-linux  |
   Keywords|ra  |


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

[Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.

[chrbr at gcc dot gnu dot org]

--- Comment #25 from chrbr at gcc dot gnu dot org  2010-01-29 08:59 ---
by the way, FYI, trying to explain the differences between your results and
mine for sh4-linux. my build was is configured with --enable-target-optspace,
so all my runtime build tests are ran with -Os, not -O2 like yours. Which could
make a huge differences in CP layout...
I repass in -O2 over the week end.
Cheers


-- 


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

[Bug target/42894] [4.5 Regression] Invalid rtl sharing in Thumb1.

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2010-01-29 09:14 ---
Only RMs may set priority.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||ice-checking
   Priority|P2  |P3
Summary|Invalid rtl sharing in  |[4.5 Regression] Invalid rtl
   |Thumb1. |sharing in Thumb1.


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

[Bug libstdc++/42679] RTLD_DEEPBIND dlopen option for shared library that uses libstdc++ std::ostream crashes

[paolo dot carlini at oracle dot com]

--- Comment #15 from paolo dot carlini at oracle dot com  2010-01-29 10:08 
---
Thanks Jakub, let's see what submitter has to say.

Just want to add here that I'm building submitter' app **exactly** in the same
way with g++ / icc, on the very same machine indeed, and in the former case the
final executable crashes, in the latter it doesn't. But there are still many
details I do not understand about this new feature, sorry if I'm saying
something wrong. I suspect however that other lay users having icc installed
could also report to us a puzzling behavior.


-- 


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

[Bug target/41399] [4.5 Regression] Scheduler gives huge dependence graph compiling fortran/intrinsic.c on ARM

[rearnsha at gcc dot gnu dot org]

--- Comment #20 from rearnsha at gcc dot gnu dot org  2010-01-29 10:18 
---
(In reply to comment #18)
> Function that seems to cost the most time is add_functions(), which is one big
> basic block of ~7500 insns (~500 of them call insns).
> 
> List scheduling is quadratic in the number of insns per basic block. I don't
> know the scheduler very well, but I would expect GCC has some kind of moving
> window to limit the number of insns we consider for scheduling within a basic
> block. If so, then this is broken now.
> 

Sched-deps.c contains the following chunk of code:

  if (!deps->readonly
  && ((deps->pending_read_list_length +
deps->pending_write_list_length)
  > MAX_PENDING_LIST_LENGTH))
{
  /* Flush all pending reads and writes to prevent the pending lists
 from getting any larger.  Insn scheduling runs too slowly when
 these lists get long.  When compiling GCC with itself,
 this flush occurs 8 times for sparc, and 10 times for m88k using
 the default value of 32.  */
  flush_pending_lists (deps, insn, false, true);
}

but presumably this is not being triggered any more.
> That doesn't explain why only ARM seems to be hit by this, though.
> 


-- 


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

[Bug debug/42873] [4.5 Regression] deadlock in var tracking in recent builds

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2010-01-29 10:28 ---
Seems s is alternating between VALUE 1 and VALUE 11:
dataflow difference found: old and new follow:
  name: s
offset 0
  (value/s/u:DI 1 @0x2ff4100/0x3009f40)
  name: s
offset 0
  (value/s/u:DI 11 @0x2ff4478/0x3013980)
...
dataflow difference found: old and new follow:
  name: s
offset 0
  (value/s/u:DI 11 @0x2ff4478/0x3013980)
  name: s
offset 0
  (value/s/u:DI 1 @0x2ff4100/0x3009f40)

Both VALUE 1 and 11 are created for (reg/v/f:DI 5 di [orig:177 s ] [177])
which is a fn parameter and hasn't been ever modified within the function,
supposedly just 1 and 11 are created in different bbs.


-- 


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

[Bug target/36539] IRA doesn't account for earlyclobber asm conflicts

[law at redhat dot com]

--- Comment #9 from law at redhat dot com  2010-01-29 11:01 ---
At some point IRA's handling of earlyclobber constraints improved enough to get
the conflicts right in this PR.  Unfortunately, that is not sufficient to
generate good code.  

If we compile the testcase on i686-pc-linux-gnu with -O2 -fomit-frame-pointer,
we should be able to allocate hard regs for all the allocnos *and* do so
without generating any reloads.  Unfortunately, IRA makes poor register
selections which ultimately lead to reloading.

Pass 0 for finding pseudo/allocno costs

a0 (r68,l0) best AREG, cover GENERAL_REGS
a4 (r67,l0) best Q_REGS, cover GENERAL_REGS
a3 (r66,l0) best GENERAL_REGS, cover GENERAL_REGS
a1 (r65,l0) best GENERAL_REGS, cover GENERAL_REGS
a5 (r64,l0) best GENERAL_REGS, cover GENERAL_REGS
a2 (r63,l0) best GENERAL_REGS, cover GENERAL_REGS
a7 (r59,l0) best GENERAL_REGS, cover GENERAL_REGS
a6 (r58,l0) best GENERAL_REGS, cover GENERAL_REGS

  a0(r68,l0) costs: AREG:-1000,-1000 DREG:0,0 CREG:0,0 BREG:0,0 SIREG:0,0
DIREG:0,0 AD_REGS:0,0 CLOBBERED_REGS:0,0 Q_REGS:0,0 NON_Q_REGS:0,0
GENERAL_REGS:0,0 MEM:6000
  a1(r65,l0) costs: AREG:0,0 DREG:0,0 CREG:0,0 BREG:0,0 SIREG:0,0 DIREG:0,0
AD_REGS:0,0 CLOBBERED_REGS:0,0 Q_REGS:0,0 NON_Q_REGS:0,0 GENERAL_REGS:0,0
MEM:7000
  a2(r63,l0) costs: AREG:0,0 DREG:0,0 CREG:0,0 BREG:0,0 SIREG:0,0 DIREG:0,0
AD_REGS:0,0 CLOBBERED_REGS:0,0 Q_REGS:0,0 NON_Q_REGS:0,0 GENERAL_REGS:0,0
MEM:28000
  a3(r66,l0) costs: AREG:0,0 DREG:0,0 CREG:0,0 BREG:0,0 SIREG:0,0 DIREG:0,0
AD_REGS:0,0 CLOBBERED_REGS:0,0 Q_REGS:0,0 NON_Q_REGS:0,0 GENERAL_REGS:0,0
MEM:16000
  a4(r67,l0) costs: AREG:0,0 DREG:0,0 CREG:0,0 BREG:0,0 SIREG:4000,4000
DIREG:4000,4000 AD_REGS:0,0 CLOBBERED_REGS:0,0 Q_REGS:0,0 NON_Q_REGS:4000,4000
GENERAL_REGS:4000,4000 MEM:16000
  a5(r64,l0) costs: AREG:0,0 DREG:0,0 CREG:0,0 BREG:0,0 SIREG:0,0 DIREG:0,0
AD_REGS:0,0 CLOBBERED_REGS:0,0 Q_REGS:0,0 NON_Q_REGS:0,0 GENERAL_REGS:0,0
MEM:4000
  a6(r58,l0) costs: AREG:0,0 DREG:0,0 CREG:0,0 BREG:0,0 SIREG:0,0 DIREG:0,0
AD_REGS:0,0 CLOBBERED_REGS:0,0 Q_REGS:0,0 NON_Q_REGS:0,0 GENERAL_REGS:0,0
MEM:3000
  a7(r59,l0) costs: AREG:0,0 DREG:0,0 CREG:0,0 BREG:0,0 SIREG:0,0 DIREG:0,0
AD_REGS:0,0 CLOBBERED_REGS:0,0 Q_REGS:0,0 NON_Q_REGS:0,0 GENERAL_REGS:0,0
MEM:3000


Pass 1 for finding pseudo/allocno costs

r68: preferred AREG, alternative GENERAL_REGS, cover GENERAL_REGS
r67: preferred Q_REGS, alternative GENERAL_REGS, cover GENERAL_REGS
r66: preferred GENERAL_REGS, alternative NO_REGS, cover GENERAL_REGS
r65: preferred GENERAL_REGS, alternative NO_REGS, cover GENERAL_REGS
r64: preferred GENERAL_REGS, alternative NO_REGS, cover GENERAL_REGS
r63: preferred GENERAL_REGS, alternative NO_REGS, cover GENERAL_REGS
r59: preferred GENERAL_REGS, alternative NO_REGS, cover GENERAL_REGS
r58: preferred GENERAL_REGS, alternative NO_REGS, cover GENERAL_REGS

  a0(r68,l0) costs: AREG:-1000,-1000 DREG:0,0 CREG:0,0 BREG:0,0 SIREG:0,0
DIREG:0,0 AD_REGS:0,0 CLOBBERED_REGS:0,0 Q_REGS:0,0 NON_Q_REGS:0,0
GENERAL_REGS:0,0 MEM:6000
  a1(r65,l0) costs: AREG:0,0 DREG:0,0 CREG:0,0 BREG:0,0 SIREG:0,0 DIREG:0,0
AD_REGS:0,0 CLOBBERED_REGS:0,0 Q_REGS:0,0 NON_Q_REGS:0,0 GENERAL_REGS:0,0
MEM:7000
  a2(r63,l0) costs: AREG:0,0 DREG:0,0 CREG:0,0 BREG:0,0 SIREG:0,0 DIREG:0,0
AD_REGS:0,0 CLOBBERED_REGS:0,0 Q_REGS:0,0 NON_Q_REGS:0,0 GENERAL_REGS:0,0
MEM:28000
  a3(r66,l0) costs: AREG:0,0 DREG:0,0 CREG:0,0 BREG:0,0 SIREG:0,0 DIREG:0,0
AD_REGS:0,0 CLOBBERED_REGS:0,0 Q_REGS:0,0 NON_Q_REGS:0,0 GENERAL_REGS:0,0
MEM:16000
  a4(r67,l0) costs: AREG:0,0 DREG:0,0 CREG:0,0 BREG:0,0 SIREG:4000,4000
DIREG:4000,4000 AD_REGS:0,0 CLOBBERED_REGS:0,0 Q_REGS:0,0 NON_Q_REGS:4000,4000
GENERAL_REGS:4000,4000 MEM:16000
  a5(r64,l0) costs: AREG:0,0 DREG:0,0 CREG:0,0 BREG:0,0 SIREG:0,0 DIREG:0,0
AD_REGS:0,0 CLOBBERED_REGS:0,0 Q_REGS:0,0 NON_Q_REGS:0,0 GENERAL_REGS:0,0
MEM:4000
  a6(r58,l0) costs: AREG:0,0 DREG:0,0 CREG:0,0 BREG:0,0 SIREG:0,0 DIREG:0,0
AD_REGS:0,0 CLOBBERED_REGS:0,0 Q_REGS:0,0 NON_Q_REGS:0,0 GENERAL_REGS:0,0
MEM:3000
  a7(r59,l0) costs: AREG:0,0 DREG:0,0 CREG:0,0 BREG:0,0 SIREG:0,0 DIREG:0,0
AD_REGS:0,0 CLOBBERED_REGS:0,0 Q_REGS:0,0 NON_Q_REGS:0,0 GENERAL_REGS:0,0
MEM:3000

That looks fairly reasonable.  pseudo 68 is the return value, so assigning it
into ax is a win.  r67 wants Q_REGS so assigning it to SI, DI, or NON_Q has a
cost.


;; a0(r68,l0) conflicts:
;; total conflict hard regs:
;; conflict hard regs:
;; a1(r65,l0) conflicts: a3(r66,l0) a2(r63,l0) a4(r67,l0) a5(r64,l0)
;; total conflict hard regs: 1 2
;; conflict hard regs: 1 2
;; a2(r63,l0) conflicts: a1(r65,l0) a3(r66,l0) a4(r67,l0) a5(r64,l0) a6(r58,l0)
a7(r59,l0)
;; total conflict hard regs: 1 2
;; conflict hard regs: 1 2
;; a3(r66,l0) conflicts: a1(r65,l0) a2(r63,l0) a4(r67,l0) a5(r64,l0) a6(r58,l0)
;; total conflict hard regs: 1 2
;; conflict hard regs: 1 2
;; a4(r67,l0) conflicts: a1(r65,l0) a3(r66,l0) a2(r63,l0) a5(r64,l0)
;; total co

[Bug middle-end/37448] [4.3/4.4/4.5 Regression] gcc 4.3.1 cannot compile big function

[rguenth at gcc dot gnu dot org]

--- Comment #39 from rguenth at gcc dot gnu dot org  2010-01-29 11:26 
---
Subject: Bug 37448

Author: rguenth
Date: Fri Jan 29 11:26:27 2010
New Revision: 156343

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156343
Log:
2010-01-29  Richard Guenther  

PR middle-end/37448
* ipa-inline.c (cgraph_decide_inlining_incrementally): Avoid
quadratic behavior in most cases.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-inline.c


-- 


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

[Bug debug/42873] [4.5 Regression] deadlock in var tracking in recent builds

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2010-01-29 11:27 ---
When doing dataflow_set_merge where s variable is in VALUE 1 in one hash table
and in VALUE 11 in the other hash table, apparently always the one that is
first wins, as VALUE 11 has var->var_part[0].loc_chain->loc VALUE 1 and vice
versa, so intersect_loc_chains just picks the first one.


-- 


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

[Bug rtl-optimization/42889] [4.5 Regression] "-fcompare-debug failure (length)" with "-O1 -fgcse"

[jakub at gcc dot gnu dot org]

--- Comment #20 from jakub at gcc dot gnu dot org  2010-01-29 12:15 ---
Subject: Bug 42889

Author: jakub
Date: Fri Jan 29 12:14:47 2010
New Revision: 156344

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156344
Log:
PR rtl-optimization/42889
* df.h (df_set_bb_dirty_nonlr): New prototype.
* df-core.c (df_set_bb_dirty_nonlr): New function.
* df-scan.c (df_insn_rescan): Call it instead of
df_set_bb_dirty for DEBUG_INSNs.

* gcc.dg/pr42889.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr42889.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/df-core.c
trunk/gcc/df-scan.c
trunk/gcc/df.h
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/42748] warnings about 'mangling of 'va_list' has changed in GCC 4.4' not suppressed in sytem headers

[manu at gcc dot gnu dot org]

--- Comment #13 from manu at gcc dot gnu dot org  2010-01-29 13:09 ---
Why is this a note and not simply a warning? Anyway, in_system_header should
slowly go away, either use diagnostic_report_warnings_p (input_location) or
in_system_header_at (input_location). None of them is necessary if you just
used warning(OPT_Wpsabi,).


-- 

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=42748

[Bug debug/42896] New: [4.5 Regression] Random debug generation differences, bootstrap fails

[rguenth at gcc dot gnu dot org]

Configuring with --enable-languages=c --disable-multilib --without-build-config
bootstrap fails with

Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1obj-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
Bootstrap comparison failure!
gcc/dse.o differs
make[2]: *** [compare] Error 1

The difference happens randomly but always at the same place.  The difference
is in .debug_loc only, readelf -w differences are:

--- /tmp/t1 2010-01-29 14:06:09.0 +0100
+++ /tmp/t2 2010-01-29 14:06:14.0 +0100
@@ -29471,7 +29471,7 @@
 Raw dump of debug contents of section .debug_line:

   Offset:  0x0
-  Length:  4841
+  Length:  4837
   DWARF Version:   2
   Prologue Length: 691
   Minimum Instruction Length:  1
@@ -30960,7 +30960,7 @@
   Extended opcode 4: set Discriminator to 1
   Set is_stmt to 0
   Special opcode 159: advance Address by 11 to 0x2412 and Line by 0 to 1384
-  Extended opcode 4: set Discriminator to 6
+  Extended opcode 4: set Discriminator to 3
   Special opcode 61: advance Address by 4 to 0x2416 and Line by 0 to 1384
   Set is_stmt to 1
   Advance Line by 217 to 1601
@@ -31171,7 +31171,7 @@
   Special opcode 132: advance Address by 9 to 0x297b and Line by 1 to 1350
   Special opcode 76: advance Address by 5 to 0x2980 and Line by 1 to 1351
   Special opcode 109: advance Address by 7 to 0x2987 and Line by 6 to 1357
-  Extended opcode 4: set Discriminator to 6
+  Extended opcode 4: set Discriminator to 3
   Special opcode 174: advance Address by 12 to 0x2993 and Line by 1 to 1358
   Special opcode 160: advance Address by 11 to 0x299e and Line by 1 to 1359
   Special opcode 202: advance Address by 14 to 0x29ac and Line by 1 to 1360
@@ -31181,12 +31181,10 @@
   Set is_stmt to 0
   Advance PC by constant 17 to 0x29cc
   Special opcode 89: advance Address by 6 to 0x29d2 and Line by 0 to 1374
-  Extended opcode 4: set Discriminator to 3
-  Special opcode 145: advance Address by 10 to 0x29dc and Line by 0 to 1374
   Set is_stmt to 1
   Advance Line by 195 to 1569
-  Advance PC by constant 17 to 0x29ed
-  Special opcode 173: advance Address by 12 to 0x29f9 and Line by 0 to 1569
+  Advance PC by 39 to 0x29f9
+  Copy
   Special opcode 76: advance Address by 5 to 0x29fe and Line by 1 to 1570
   Extended opcode 4: set Discriminator to 1
   Set is_stmt to 0
@@ -31240,7 +31238,7 @@
   Special opcode 6: advance Address by 0 to 0x2b78 and Line by 1 to 1434
   Advance Line by -912 to 522
   Special opcode 145: advance Address by 10 to 0x2b82 and Line by 0 to 522
-  Extended opcode 4: set Discriminator to 3
+  Extended opcode 4: set Discriminator to 1
   Advance Line by 930 to 1452
   Advance PC by constant 17 to 0x2b93
   Special opcode 201: advance Address by 14 to 0x2ba1 and Line by 0 to 1452
@@ -34190,10 +34188,10 @@
 778d 48b1 48bb (DW_OP_reg2)
 778d 48bb 490b (DW_OP_reg5)
 778d 4bfb 4c00 (DW_OP_reg5)
-778d 4c00 4c04 (DW_OP_breg7: 32)
+778d 4c00 4c04 (DW_OP_breg3: 24)
 778d 4c1f 4c32 (DW_OP_reg5)
 778d 4e01 4e1b (DW_OP_reg5)
-778d 4e1b 4e1f (DW_OP_breg7: 32)
+778d 4e1b 4e1f (DW_OP_breg3: 24)
 778d 
 7837 4921 49c1 (DW_OP_reg13)
 7837 49c1 49cb (DW_OP_reg13)


I now run into this regularly because contrib/compare-debug does not work
for me as the host compiler inserts a .comment.SUSE.OPT section whose
content depends on whether -g is specified or not.


-- 
   Summary: [4.5 Regression] Random debug generation differences,
bootstrap fails
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
GCC target triplet: x86_64-*-linux-gnu


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

[Bug debug/42896] [4.5 Regression] Random debug generation differences, bootstrap fails

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.5.0


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

[Bug c++/42897] New: yet another ice in verify_ssa

[dcb314 at hotmail dot com]

I just tried to compile the package htmldoc-1.8.27-174.19 with the GNU
C++ compiler version 4.5 snapshot 20100128 and the compiler said

image.cxx:389:1: error: definition in block 7 does not dominate use in block 13
for SSA_NAME: i_36 in statement:
# DEBUG i => i_36
image.cxx:389:1: internal compiler error: verify_ssa failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Preprocessed source code attached. Flags -g -O3 required.

This bug looks similar to 40711 and 42299, but it does seem to be
different to me.


-- 
   Summary: yet another ice in verify_ssa
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dcb314 at hotmail dot com
  GCC host triplet: x86_64-suse-linux


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

[Bug c++/42897] yet another ice in verify_ssa

[dcb314 at hotmail dot com]

--- Comment #1 from dcb314 at hotmail dot com  2010-01-29 13:37 ---
Created an attachment (id=19749)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19749&action=view)
C++ source code


-- 


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

[Bug c++/42748] warnings about 'mangling of 'va_list' has changed in GCC 4.4' not suppressed in sytem headers

[paolo dot carlini at oracle dot com]

--- Comment #14 from paolo dot carlini at oracle dot com  2010-01-29 13:40 
---
I can see that exception_ptr.h doesn't have the system header pragma, I think
on purpose, some time ago we briefly discussed that and decided to not add it
to the libsupc++ user-visible headers, if possible.  however
*does* have it, thus, if there are problems with it in mainline, it's because
inform do not behave exactly like normal warnings, I think Joseph warned us
about that...

In general, I would say Manuel has very good points about this issue.


-- 


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

[Bug debug/42896] [4.5 Regression] Random debug generation differences, bootstrap fails

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2010-01-29 13:51 ---
r156291 is fine, r156292 is broken.


-- 


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

[Bug debug/42896] [4.5 Regression] Random debug generation differences, bootstrap fails

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-01-29 13:57 ---
var-tracking dump difference:

--- dse.c.208r.vartrack.equal   2010-01-29 14:55:01.0 +0100
+++ dse.c.208r.vartrack.differs 2010-01-29 14:54:34.0 +0100
@@ -1889899,8 +1889899,8 @@
  (value/s/u:DI 44 @#/#)
 offset 0
   (reg:DI 5 di)
-  (mem/c:DI (value/s/u:DI 4010 @#/#) [134 %sfp+-96 S8 A64])
   (mem/s/f:DI (value/s/u:DI 4010 @#/#) [111 insn_info_26->read_rec+0 S8
A64
])
+  (mem/c:DI (value/s/u:DI 4010 @#/#) [134 %sfp+-96 S8 A64])
  (value/s/u:DI 40 @#/#)
 offset 0
   (mem/c:DI (value/s/u:DI 4015 @#/#) [134 %sfp+-88 S8 A64])
@@ -1890189,8 +1890189,8 @@
  (value/s/u:DI 44 @#/#)
 offset 0
   (reg:DI 5 di)
-  (mem/c:DI (value/s/u:DI 4010 @#/#) [134 %sfp+-96 S8 A64])
   (mem/s/f:DI (value/s/u:DI 4010 @#/#) [111 insn_info_26->read_rec+0 S8
A64
])
+  (mem/c:DI (value/s/u:DI 4010 @#/#) [134 %sfp+-96 S8 A64])
  (value/s/u:DI 40 @#/#)
 offset 0
   (mem/c:DI (value/s/u:DI 4015 @#/#) [134 %sfp+-88 S8 A64])
@@ -1890480,8 +1890480,8 @@
  (value/s/u:DI 44 @#/#)
 offset 0
   (reg:DI 5 di)
-  (mem/c:DI (value/s/u:DI 4010 @#/#) [134 %sfp+-96 S8 A64])
   (mem/s/f:DI (value/s/u:DI 4010 @#/#) [111 insn_info_26->read_rec+0 S8
A64
])
+  (mem/c:DI (value/s/u:DI 4010 @#/#) [134 %sfp+-96 S8 A64])
  (value/s/u:DI 40 @#/#)
 offset 0
   (mem/c:DI (value/s/u:DI 4015 @#/#) [134 %sfp+-88 S8 A64])
@@ -1890777,8 +1890777,8 @@
  (value/s/u:DI 44 @#/#)
 offset 0
   (reg:DI 5 di)
-  (mem/c:DI (value/s/u:DI 4010 @#/#) [134 %sfp+-96 S8 A64])
   (mem/s/f:DI (value/s/u:DI 4010 @#/#) [111 insn_info_26->read_rec+0 S8
A64
])
+  (mem/c:DI (value/s/u:DI 4010 @#/#) [134 %sfp+-96 S8 A64])
  (value/s/u:DI 40 @#/#)
 offset 0
   (mem/c:DI (value/s/u:DI 4015 @#/#) [134 %sfp+-88 S8 A64])
@@ -1891090,8 +1891090,8 @@
  (value/s/u:DI 44 @#/#)
 offset 0
   (reg:DI 5 di)
-  (mem/c:DI (value/s/u:DI 4010 @#/#) [134 %sfp+-96 S8 A64])
   (mem/s/f:DI (value/s/u:DI 4010 @#/#) [111 insn_info_26->read_rec+0 S8
A64
])
+  (mem/c:DI (value/s/u:DI 4010 @#/#) [134 %sfp+-96 S8 A64])
  (value/s/u:DI 4098 @#/#)
 offset 0
   (plus:DI (value/s/u:DI 42 @#/#)
@@ -1891392,8 +1891392,8 @@
  (value/s/u:DI 44 @#/#)
 offset 0
   (reg:DI 5 di)
-  (mem/c:DI (value/s/u:DI 4010 @#/#) [134 %sfp+-96 S8 A64])
   (mem/s/f:DI (value/s/u:DI 4010 @#/#) [111 insn_info_26->read_rec+0 S8
A64
])
+  (mem/c:DI (value/s/u:DI 4010 @#/#) [134 %sfp+-96 S8 A64])
  (value/s/u:DI 4098 @#/#)
 offset 0
   (plus:DI (value/s/u:DI 42 @#/#)
@@ -1891698,8 +1891698,8 @@

etc.

@@ -2077335,7 +2077335,9 @@
  into...
 expanding (value/s/u:DI 4010 @#/#)
  into...
-expanding (value/s/u:DI 42 @#/#)
+expanding (value/s/u:DI 50 @#/#)
+ into...
+expanding (value/s/u:DI 23 @#/#)
  into...
 expanding (value/s/u/f:DI 10 @#/#)
  into...
@@ -2077895,7 +2077897,9 @@
  into...
 expanding (value/s/u:DI 4010 @#/#)
  into...
-expanding (value/s/u:DI 42 @#/#)
+expanding (value/s/u:DI 50 @#/#)
+ into...
+expanding (value/s/u:DI 23 @#/#)
  into...
 expanding (value/s/u:DI 44 @#/#)
  into...
@@ -2080479,8 +2080483,8 @@
 (mem/c:DI (plus:DI (reg/f:DI 7 sp)
 (const_int 48 [0x30])) [134 %sfp+-80 S8 A64])) 89
{*movdi_1_rex
64} (nil))

-(note 1296 190 1297 70 (var_location read_info (expr_list:REG_DEP_TRUE
(mem/c:D
I (plus:DI (reg/f:DI 7 sp)
-(const_int 32 [0x20])) [134 %sfp+-96 S8 A64])
+(note 1296 190 1297 70 (var_location read_info (expr_list:REG_DEP_TRUE
(mem/s/f
:DI (plus:DI (reg/v/f:DI 3 bx [orig:83 insn_info ] [83])
+(const_int 24 [0x18])) [111 insn_info_26->read_rec+0 S8 A64])
 (const_int 0 [0x0]))) NOTE_INSN_VAR_LOCATION)

 (note 1297 1296 191 70 (var_location mem (expr_list:REG_DEP_TRUE (reg/v/f:DI 6 
bp [orig:80 mem ] [80])
@@ -2081570,8 +2081574,8 @@
 (note 1389 173 1390 101 (var_location mem (expr_list:REG_DEP_TRUE (reg/v/f:DI
6
 bp [orig:80 mem ] [80])
 (const_int 0 [0x0]))) NOTE_INSN_VAR_LOCATION)

-(note 1390 1389 174 101 (var_location read_info (expr_list:REG_DEP_TRUE
(mem/c:
DI (plus:DI (reg/f:DI 7 sp)
-(const_int 32 [0x20])) [134 %sfp+-96 S8 A64])
+(note 1390 1389 174 101 (var_location read_info (expr_list:REG_DEP_TRUE
(mem/s/
f:DI (plus:DI (reg/v/f:DI 3 bx [orig:83 insn_info ] [83])
+(const_int 24 [0x18])) [111 insn_info_26->read_rec+0 S8 A64])
 (const_int 0 [0x0]))) NOTE_INSN_VAR_LOCATION)

 (call_insn:TI 174 1390 1391 101 ../../trunk/gcc/dse.c:522 (call (mem:QI
(symbol
_ref:DI ("vec_assert_fail") [flags 0x41]  ) [0 
S1 A8])


-- 


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

[Bug debug/42896] [4.5 Regression] Random debug generation differences, bootstrap fails

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2010-01-29 14:00 ---
Created an attachment (id=19750)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19750&action=view)
testcase

inside stage3/gcc:

obj/gcc> /abuild/rguenther/obj/./prev-gcc/cc1 -fpreprocessed dse.i -quiet
-dumpbase dse.c -mtune=generic -auxbase-strip dse.o -g -O2 -W -Wall
-Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Werror -Wold-style-definition -Wc++-compat -version
-fno-common -o dse.s1
obj/gcc> /abuild/rguenther/obj/./prev-gcc/cc1 -fpreprocessed dse.i -quiet
-dumpbase dse.c -mtune=generic -auxbase-strip dse.o -g -O2 -W -Wall
-Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Werror -Wold-style-definition -Wc++-compat -version
-fno-common -o dse.s2
obj/gcc> cmp dse.s1 dse.s2 
dse.s1 dse.s2 differ: char 285950, line 18387

--- dse.s1  2010-01-29 14:58:22.0 +0100
+++ dse.s2  2010-01-29 14:58:26.0 +0100
@@ -18384,8 +18384,8 @@
.quad   .LVL1531-.Ltext0
.quad   .LVL1532-1-.Ltext0
.value  0x2
-   .byte   0x77
-   .sleb128 32
+   .byte   0x73
+   .sleb128 24
.quad   .LVL1536-.Ltext0
.quad   .LVL1538-.Ltext0
.value  0x1
@@ -18397,8 +18397,8 @@
.quad   .LVL1576-.Ltext0
.quad   .LVL1577-1-.Ltext0
.value  0x2
-   .byte   0x77
-   .sleb128 32
+   .byte   0x73
+   .sleb128 24
.quad   0x0
.quad   0x0


-- 


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

[Bug debug/42896] [4.5 Regression] Random debug generation differences, bootstrap fails

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2010-01-29 14:04 ---
Needs randomized va-space to trigger.  My guess:

/* Determine a total order between two distinct pointers.  Compare the
   pointers as integral types if size_t is wide enough, otherwise
   resort to bitwise memory compare.  The actual order does not
   matter, we just need to be consistent, so endianness is
   irrelevant.  */

static int
tie_break_pointers (const void *p1, const void *p2)
{
  gcc_assert (p1 != p2);

  if (sizeof (size_t) >= sizeof (void*))
return (size_t)p1 < (size_t)p2 ? -1 : 1;
  else
return memcmp (&p1, &p2, sizeof (p1));
}


-- 


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

[Bug c++/42797] [4.5 Regression] call of overloaded 'allocator()' is ambiguous

[dodji at gcc dot gnu dot org]

--- Comment #4 from dodji at gcc dot gnu dot org  2010-01-29 14:31 ---
Subject: Bug 42797

Author: dodji
Date: Fri Jan 29 14:30:41 2010
New Revision: 156351

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156351
Log:
Fix PRs c++/42758, c++/42634, c++/42797

... and mitigate PR c++/42336

gcc/cp/ChangeLog:
PR c++/42758
PR c++/42634
PR c++/42336
PR c++/42797
PR c++/42880
* cp-tree.h (NON_DEFAULT_TEMPLATE_ARGS_COUNT,
SET_NON_DEFAULT_TEMPLATE_ARGS_COUNT,
GET_NON_DEFAULT_TEMPLATE_ARGS_COUNT): New accessor macros.
* pt.c (coerce_template_parms, type_unification_real,
expand_template_argument_pack, coerce_template_parameter_pack):
Set the non default template args count.
(current_template_args): Always set non defaulted
template args count when compiled with --enable-checking
(tsubst_template_args, type_unification_real): Propagate the non
defaulted template args count.
* error.c (get_non_default_template_args_count): Renamed
count_non_default_template_args into this. Don't calculate the
non default template argument count anymore. Use the new
accessor macros above to get it.
(dump_template_argument_list, dump_type, dump_decl,
dump_template_parms): Adjust.
* parser.c (cp_parser_template_argument_list): Always set defaulted
template args count when compiled with --enable-checking.

gcc/testsuite/ChangeLog:
PR c++/42758
PR c++/42634
PR c++/42336
PR c++/42797
PR c++/42880
* g++.dg/other/crash-5.C: New test.
* g++.dg/other/crash-6.C: New test.
* g++.dg/other/crash-7.C: New test.
* g++.dg/other/crash-8.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/other/crash-5.C
trunk/gcc/testsuite/g++.dg/other/crash-6.C
trunk/gcc/testsuite/g++.dg/other/crash-7.C
trunk/gcc/testsuite/g++.dg/other/crash-8.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/error.c
trunk/gcc/cp/parser.c
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/42880] trunk does not compile boost MPL

[dodji at gcc dot gnu dot org]

--- Comment #47 from dodji at gcc dot gnu dot org  2010-01-29 14:31 ---
Subject: Bug 42880

Author: dodji
Date: Fri Jan 29 14:30:41 2010
New Revision: 156351

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156351
Log:
Fix PRs c++/42758, c++/42634, c++/42797

... and mitigate PR c++/42336

gcc/cp/ChangeLog:
PR c++/42758
PR c++/42634
PR c++/42336
PR c++/42797
PR c++/42880
* cp-tree.h (NON_DEFAULT_TEMPLATE_ARGS_COUNT,
SET_NON_DEFAULT_TEMPLATE_ARGS_COUNT,
GET_NON_DEFAULT_TEMPLATE_ARGS_COUNT): New accessor macros.
* pt.c (coerce_template_parms, type_unification_real,
expand_template_argument_pack, coerce_template_parameter_pack):
Set the non default template args count.
(current_template_args): Always set non defaulted
template args count when compiled with --enable-checking
(tsubst_template_args, type_unification_real): Propagate the non
defaulted template args count.
* error.c (get_non_default_template_args_count): Renamed
count_non_default_template_args into this. Don't calculate the
non default template argument count anymore. Use the new
accessor macros above to get it.
(dump_template_argument_list, dump_type, dump_decl,
dump_template_parms): Adjust.
* parser.c (cp_parser_template_argument_list): Always set defaulted
template args count when compiled with --enable-checking.

gcc/testsuite/ChangeLog:
PR c++/42758
PR c++/42634
PR c++/42336
PR c++/42797
PR c++/42880
* g++.dg/other/crash-5.C: New test.
* g++.dg/other/crash-6.C: New test.
* g++.dg/other/crash-7.C: New test.
* g++.dg/other/crash-8.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/other/crash-5.C
trunk/gcc/testsuite/g++.dg/other/crash-6.C
trunk/gcc/testsuite/g++.dg/other/crash-7.C
trunk/gcc/testsuite/g++.dg/other/crash-8.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/error.c
trunk/gcc/cp/parser.c
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/42634] ICE with -g -O2 -std=c++0x in copy_fn_p, at cp/decl.c:9973

[dodji at gcc dot gnu dot org]

--- Comment #15 from dodji at gcc dot gnu dot org  2010-01-29 14:31 ---
Subject: Bug 42634

Author: dodji
Date: Fri Jan 29 14:30:41 2010
New Revision: 156351

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156351
Log:
Fix PRs c++/42758, c++/42634, c++/42797

... and mitigate PR c++/42336

gcc/cp/ChangeLog:
PR c++/42758
PR c++/42634
PR c++/42336
PR c++/42797
PR c++/42880
* cp-tree.h (NON_DEFAULT_TEMPLATE_ARGS_COUNT,
SET_NON_DEFAULT_TEMPLATE_ARGS_COUNT,
GET_NON_DEFAULT_TEMPLATE_ARGS_COUNT): New accessor macros.
* pt.c (coerce_template_parms, type_unification_real,
expand_template_argument_pack, coerce_template_parameter_pack):
Set the non default template args count.
(current_template_args): Always set non defaulted
template args count when compiled with --enable-checking
(tsubst_template_args, type_unification_real): Propagate the non
defaulted template args count.
* error.c (get_non_default_template_args_count): Renamed
count_non_default_template_args into this. Don't calculate the
non default template argument count anymore. Use the new
accessor macros above to get it.
(dump_template_argument_list, dump_type, dump_decl,
dump_template_parms): Adjust.
* parser.c (cp_parser_template_argument_list): Always set defaulted
template args count when compiled with --enable-checking.

gcc/testsuite/ChangeLog:
PR c++/42758
PR c++/42634
PR c++/42336
PR c++/42797
PR c++/42880
* g++.dg/other/crash-5.C: New test.
* g++.dg/other/crash-6.C: New test.
* g++.dg/other/crash-7.C: New test.
* g++.dg/other/crash-8.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/other/crash-5.C
trunk/gcc/testsuite/g++.dg/other/crash-6.C
trunk/gcc/testsuite/g++.dg/other/crash-7.C
trunk/gcc/testsuite/g++.dg/other/crash-8.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/error.c
trunk/gcc/cp/parser.c
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/42336] [4.5 Regression] ICE with pointer-to-member-function argument in template function with -fipa-sra

[dodji at gcc dot gnu dot org]

--- Comment #23 from dodji at gcc dot gnu dot org  2010-01-29 14:31 ---
Subject: Bug 42336

Author: dodji
Date: Fri Jan 29 14:30:41 2010
New Revision: 156351

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156351
Log:
Fix PRs c++/42758, c++/42634, c++/42797

... and mitigate PR c++/42336

gcc/cp/ChangeLog:
PR c++/42758
PR c++/42634
PR c++/42336
PR c++/42797
PR c++/42880
* cp-tree.h (NON_DEFAULT_TEMPLATE_ARGS_COUNT,
SET_NON_DEFAULT_TEMPLATE_ARGS_COUNT,
GET_NON_DEFAULT_TEMPLATE_ARGS_COUNT): New accessor macros.
* pt.c (coerce_template_parms, type_unification_real,
expand_template_argument_pack, coerce_template_parameter_pack):
Set the non default template args count.
(current_template_args): Always set non defaulted
template args count when compiled with --enable-checking
(tsubst_template_args, type_unification_real): Propagate the non
defaulted template args count.
* error.c (get_non_default_template_args_count): Renamed
count_non_default_template_args into this. Don't calculate the
non default template argument count anymore. Use the new
accessor macros above to get it.
(dump_template_argument_list, dump_type, dump_decl,
dump_template_parms): Adjust.
* parser.c (cp_parser_template_argument_list): Always set defaulted
template args count when compiled with --enable-checking.

gcc/testsuite/ChangeLog:
PR c++/42758
PR c++/42634
PR c++/42336
PR c++/42797
PR c++/42880
* g++.dg/other/crash-5.C: New test.
* g++.dg/other/crash-6.C: New test.
* g++.dg/other/crash-7.C: New test.
* g++.dg/other/crash-8.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/other/crash-5.C
trunk/gcc/testsuite/g++.dg/other/crash-6.C
trunk/gcc/testsuite/g++.dg/other/crash-7.C
trunk/gcc/testsuite/g++.dg/other/crash-8.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/error.c
trunk/gcc/cp/parser.c
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/42758] [4.5 Regression] ICE on assert() in function with complex(?) template argument

[dodji at gcc dot gnu dot org]

--- Comment #7 from dodji at gcc dot gnu dot org  2010-01-29 14:31 ---
Subject: Bug 42758

Author: dodji
Date: Fri Jan 29 14:30:41 2010
New Revision: 156351

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156351
Log:
Fix PRs c++/42758, c++/42634, c++/42797

... and mitigate PR c++/42336

gcc/cp/ChangeLog:
PR c++/42758
PR c++/42634
PR c++/42336
PR c++/42797
PR c++/42880
* cp-tree.h (NON_DEFAULT_TEMPLATE_ARGS_COUNT,
SET_NON_DEFAULT_TEMPLATE_ARGS_COUNT,
GET_NON_DEFAULT_TEMPLATE_ARGS_COUNT): New accessor macros.
* pt.c (coerce_template_parms, type_unification_real,
expand_template_argument_pack, coerce_template_parameter_pack):
Set the non default template args count.
(current_template_args): Always set non defaulted
template args count when compiled with --enable-checking
(tsubst_template_args, type_unification_real): Propagate the non
defaulted template args count.
* error.c (get_non_default_template_args_count): Renamed
count_non_default_template_args into this. Don't calculate the
non default template argument count anymore. Use the new
accessor macros above to get it.
(dump_template_argument_list, dump_type, dump_decl,
dump_template_parms): Adjust.
* parser.c (cp_parser_template_argument_list): Always set defaulted
template args count when compiled with --enable-checking.

gcc/testsuite/ChangeLog:
PR c++/42758
PR c++/42634
PR c++/42336
PR c++/42797
PR c++/42880
* g++.dg/other/crash-5.C: New test.
* g++.dg/other/crash-6.C: New test.
* g++.dg/other/crash-7.C: New test.
* g++.dg/other/crash-8.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/other/crash-5.C
trunk/gcc/testsuite/g++.dg/other/crash-6.C
trunk/gcc/testsuite/g++.dg/other/crash-7.C
trunk/gcc/testsuite/g++.dg/other/crash-8.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/error.c
trunk/gcc/cp/parser.c
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug libmudflap/40778] [4.5 Regression] Mudflap instrumentation missing in cloned function.

[hubicka at gcc dot gnu dot org]

--- Comment #4 from hubicka at gcc dot gnu dot org  2010-01-29 14:33 ---
Yes, the clone_of and similar datastructures are cleared because function is no
longer a virtual clone.  Probably best way to get to original function is via
DECL_ABSTRACT_ORIGIN same way as debug info does.  Is that sufficient here? (We
can always add some extra flags, but I think we should have enough of them
already.  All the other synthetic functions we do not want to instrument won't
have DECL_ABSTRACT_ORIGIN set, right?)


-- 


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

[Bug debug/42897] [4.5 Regression] yet another ice in verify_ssa

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
  Component|c++ |debug
   Keywords||ice-on-valid-code
Summary|yet another ice in  |[4.5 Regression] yet another
   |verify_ssa  |ice in verify_ssa
   Target Milestone|--- |4.5.0


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

[Bug debug/42896] [4.5 Regression] Random debug generation differences, bootstrap fails

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2010-01-29 15:00 ---
Created an attachment (id=19751)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19751&action=view)
gcc45-pr42896.patch

Try this.  If we ever hit the assertion, some more patching will be needed to
break the ties.


-- 


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

[Bug debug/42896] [4.5 Regression] Random debug generation differences, bootstrap fails

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2010-01-29 15:04 ---
After fixing the typo it ICEs with the testcase:

../../trunk/gcc/dse.c: In function 'check_mem_read_rtx':
../../trunk/gcc/dse.c:2300:1: internal compiler error: in tie_break_values, at
var-tracking.c:1179
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

which is

  if (!loc1)
{
  gcc_assert (loc2);


-- 


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

[Bug c++/42748] warnings about 'mangling of 'va_list' has changed in GCC 4.4' not suppressed in sytem headers

[mark at codesourcery dot com]

--- Comment #15 from mark at codesourcery dot com  2010-01-29 15:12 ---
Subject: Re:  warnings about 'mangling of 'va_list' has changed
 in GCC 4.4' not suppressed in sytem headers

manu at gcc dot gnu dot org wrote:

> Why is this a note and not simply a warning?

Because, as noted earlier, it's not reflective of any likely problem in
the user's code.  I think a warning is appropriate if the compiler
detects something which might indicate a bug in the application, but
this is just the compiler telling you about that something might go
wrong if you linked with code form a different version of G++.  Which is
unlikely, and might go wrong for other reasons too.


-- 


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

[Bug debug/42896] [4.5 Regression] Random debug generation differences, bootstrap fails

[jakub at gcc dot gnu dot org]

--- Comment #7 from jakub at gcc dot gnu dot org  2010-01-29 15:21 ---
:(, there apparently are VALUEs without locs so we can't always compare this
way.
Both the problematic VALUEs are created through
e = new_cselib_val (hashval, mode, x);
(the only place which doesn't assign VALUE values sequentially, but uses a
hash.
Both
(plus:DI (reg/f:DI 7 sp)
(const_int 32 [0x20]))
and
(plus:DI (reg/v/f:DI 3 bx [orig:83 insn_info ] [83])
(const_int 24 [0x18]))
hash to the same value (and while having two values with the same hashval would
be rejected inside of the same bb, it is not rejected inside of different bbs).

So the values are indeed for something completely different and thus must not
be considered equal.  On 64-bit hosts we could at no cost add some sequential
UID to the VALUEs next to value, but on 32-bit hosts it would enlarge the
struct.


-- 


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

[Bug c++/42824] [4.5 regression] c++ compilation complains about error: call of overloaded

[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|2010-01-25 19:44:07 |2010-01-29 15:37:43
   date||


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

[Bug c++/42336] [4.5 Regression] ICE with pointer-to-member-function argument in template function with -fipa-sra

[dodji at seketeli dot org]

--- Comment #24 from dodji at seketeli dot org  2010-01-29 15:48 ---
Subject: Re:  [4.5 Regression] ICE with
 pointer-to-member-function argument in template function with -fipa-sra

So this commit r156351 won't fix the root cause this issue, but I
believe it prevents the compiler from crashing. The generated
debugging info will surely still be wrong after this commit, though.


-- 


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

[Bug c++/42634] ICE with -g -O2 -std=c++0x in copy_fn_p, at cp/decl.c:9973

[dodji at gcc dot gnu dot org]

--- Comment #16 from dodji at gcc dot gnu dot org  2010-01-29 16:07 ---
Hopefully fixed in 4.5 (trunk) now.


-- 

dodji at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED


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

[Bug c++/42758] [4.5 Regression] ICE on assert() in function with complex(?) template argument

[dodji at gcc dot gnu dot org]

--- Comment #8 from dodji at gcc dot gnu dot org  2010-01-29 16:08 ---
Fixed in 4.5 (trunk)


-- 

dodji at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/42797] [4.5 Regression] call of overloaded 'allocator()' is ambiguous

[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|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-01-29 16:09:23
   date||


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

[Bug c++/42797] [4.5 Regression] call of overloaded 'allocator()' is ambiguous

[dodji at gcc dot gnu dot org]

--- Comment #5 from dodji at gcc dot gnu dot org  2010-01-29 16:09 ---
Fixed in 4.5 (trunk).


-- 

dodji at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug debug/42897] [4.5 Regression] yet another ice in verify_ssa

[hjl dot tools at gmail dot com]

--- Comment #2 from hjl dot tools at gmail dot com  2010-01-29 16:22 ---
It is caused by revision 154402:

http://gcc.gnu.org/ml/gcc-cvs/2009-11/msg00623.html


-- 


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

[Bug debug/42896] [4.5 Regression] Random debug generation differences, bootstrap fails

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2010-01-29 16:26 ---
Created an attachment (id=19752)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19752&action=view)
reduced testcase


-- 


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

[Bug middle-end/41440] SEG FAULT in CSE.C caused by bad RTL expansion

[eric dot weddington at atmel dot com]

--- Comment #12 from eric dot weddington at atmel dot com  2010-01-29 16:33 
---
Setting target milestone.


-- 

eric dot weddington at atmel dot com changed:

   What|Removed |Added

   Target Milestone|--- |4.5.0


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

[Bug testsuite/38202] [avr] FAIL: gcc.dg/torture/pr37868.c

[eric dot weddington at atmel dot com]

--- Comment #4 from eric dot weddington at atmel dot com  2010-01-29 16:43 
---
Changed Target Milestone.


-- 

eric dot weddington at atmel dot com changed:

   What|Removed |Added

   Target Milestone|--- |4.5.0


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

[Bug debug/42896] [4.5 Regression] Random debug generation differences, bootstrap fails

[jakub at gcc dot gnu dot org]

--- Comment #9 from jakub at gcc dot gnu dot org  2010-01-29 16:43 ---
In theory we could reuse the next_containing_mem field for a counter, as it
isn't used for anything once cselib_preserve_only_values is called (and I
believe canon_value_cmp is only ever used after vt_initialize phase finishes,
i.e. all VALUEs have gone through cselib_preserve_only_values. 
remove_useless_values could have a bool argument which
cselib_preserve_only_values would set, then it would just set an int in union
with next_containing_mem to a counter (incremented after each
cselib_preserve_only_values call starting at cselib_init).
The trouble is how to teach GC not to walk next_containing_mem / this int (it
isn't needed to walk next_containing_mem anyway, as all the VALUEs must be in
the hash table anyway).


-- 

jakub 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-29 16:43:04
   date||


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

[Bug target/37081] [avr] FAIL: gcc.dg/pr36998.c

[eric dot weddington at atmel dot com]

--- Comment #4 from eric dot weddington at atmel dot com  2010-01-29 16:46 
---
Setting Target Milestone.


-- 

eric dot weddington at atmel dot com changed:

   What|Removed |Added

   Target Milestone|--- |4.5.0


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

[Bug target/32871] [avr] Bad optimisation - gcc is pushing too many registers

[eric dot weddington at atmel dot com]

--- Comment #9 from eric dot weddington at atmel dot com  2010-01-29 17:01 
---
Closing as WONTFIX.


-- 

eric dot weddington at atmel dot com changed:

   What|Removed |Added

 Status|SUSPENDED   |RESOLVED
 Resolution||WONTFIX


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

[Bug libstdc++/42679] RTLD_DEEPBIND dlopen option for shared library that uses libstdc++ std::ostream crashes

[mjtruog at fastmail dot ca]

--- Comment #16 from mjtruog at fastmail dot ca  2010-01-29 17:04 ---
I am using "-fpic/-fPIC" and in fact am using:
// g++ -g -O0 main.cpp -ldl
// g++ -g -O0 -rdynamic -c -fPIC -o library.o library1.cpp
// g++ -shared -Wl,-export-dynamic -o library.so library.o

I do want to use RTLD_DEEPBIND to keep the libraries in isolation as you
mention, since I could have libraries that depend on different versions of GCC.
 I understand that it doesn't work right now with g++ linking, so I might try
to switch to gcc linking.  I just was concerned because it appeared to be
connected to libstdc++, but I guess it is a g++ linking peculiarity.  I don't
think ignoring the RTLD_DEEPBIND feature in glibc would help.


-- 


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

[Bug rtl-optimization/23726] Missed optimizations for divmod

[eric dot weddington at atmel dot com]

--- Comment #11 from eric dot weddington at atmel dot com  2010-01-29 17:07 
---
Setting Target Milestone.


-- 

eric dot weddington at atmel dot com changed:

   What|Removed |Added

   Target Milestone|--- |4.5.0


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

[Bug target/21080] Excecution test failure for avr for pr17377 test case.

[eric dot weddington at atmel dot com]

--- Comment #7 from eric dot weddington at atmel dot com  2010-01-29 17:08 
---
Setting Target Milestone.


-- 

eric dot weddington at atmel dot com changed:

   What|Removed |Added

   Target Milestone|--- |4.5.0


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

[Bug c++/41884] diagnostics: error vs. context

[jason at gcc dot gnu dot org]

--- Comment #13 from jason at gcc dot gnu dot org  2010-01-29 17:10 ---
Created an attachment (id=19753)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19753&action=view)
work snapshot

Here's a final snapshot of the work I did on this if anyone ever feels like
picking it up again.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #18955|0   |1
is obsolete||


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

[Bug c++/41884] diagnostics: error vs. context

[jason at gcc dot gnu dot org]

--- Comment #14 from jason at gcc dot gnu dot org  2010-01-29 17:11 ---
And closing.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||WONTFIX


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

[Bug middle-end/19154] miss-optimization of (x & pow2C) avr conditionals returning bool equivalent values

[eric dot weddington at atmel dot com]

--- Comment #10 from eric dot weddington at atmel dot com  2010-01-29 17:12 
---
Setting Target Milestone.


-- 

eric dot weddington at atmel dot com changed:

   What|Removed |Added

   Target Milestone|--- |4.5.0


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

[Bug debug/42896] [4.5 Regression] Random debug generation differences, bootstrap fails

[rguenther at suse dot de]

--- Comment #10 from rguenther at suse dot de  2010-01-29 17:17 ---
Subject: Re:  [4.5 Regression] Random debug generation
 differences, bootstrap fails

On Fri, 29 Jan 2010, jakub at gcc dot gnu dot org wrote:

> --- Comment #9 from jakub at gcc dot gnu dot org  2010-01-29 16:43 ---
> In theory we could reuse the next_containing_mem field for a counter, as it
> isn't used for anything once cselib_preserve_only_values is called (and I
> believe canon_value_cmp is only ever used after vt_initialize phase finishes,
> i.e. all VALUEs have gone through cselib_preserve_only_values. 
> remove_useless_values could have a bool argument which
> cselib_preserve_only_values would set, then it would just set an int in union
> with next_containing_mem to a counter (incremented after each
> cselib_preserve_only_values call starting at cselib_init).
> The trouble is how to teach GC not to walk next_containing_mem / this int (it
> isn't needed to walk next_containing_mem anyway, as all the VALUEs must be in
> the hash table anyway).

Or we could simply record the basic-block and use its index for 
tie-breaking?

Richard.


-- 


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

[Bug c++/41090] [4.3/4.4/4.5 Regression] Using static label reference in c++ class constructor produces wrong code

[jason at gcc dot gnu dot org]

-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jason at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-08-17 14:21:06 |2010-01-29 17:20:04
   date||


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

[Bug rtl-optimization/42889] [4.5 Regression] "-fcompare-debug failure (length)" with "-O1 -fgcse"

[jakub at gcc dot gnu dot org]

--- Comment #21 from jakub at gcc dot gnu dot org  2010-01-29 17:26 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug libgomp/29986] testsuite failures

[ro at gcc dot gnu dot org]

--- Comment #8 from ro at gcc dot gnu dot org  2010-01-29 17:34 ---
Mine.


-- 

ro at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |ro at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2006-11-26 14:02:53 |2010-01-29 17:34:30
   date||


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

[Bug libgomp/29986] testsuite failures

[ro at gcc dot gnu dot org]

--- Comment #9 from ro at gcc dot gnu dot org  2010-01-29 17:37 ---
Patch here:

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


-- 


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

[Bug target/31786] [avr] error: unable to find a register to spill in class 'BASE_POINTER_REGS'

[eric dot weddington at atmel dot com]

--- Comment #20 from eric dot weddington at atmel dot com  2010-01-29 17:45 
---
I have in my list that this bug as fixed in 4.4.0. Closing.


-- 

eric dot weddington at atmel dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
Summary|[4.3 Regression][avr] error:|[avr] error: unable to find
   |unable to find a register to|a register to spill in class
   |spill in class  |'BASE_POINTER_REGS'
   |'BASE_POINTER_REGS' |
   Target Milestone|4.3.5   |4.4.0


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

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

[burnus at gcc dot gnu dot org]

--- Comment #3 from burnus at gcc dot gnu dot org  2010-01-29 17:45 ---
I have now asked at comp.lang.fortran:

http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/c00efc5679b6a879

(In reply to comment #2)
> The way usually recommended is to use a struct for interoperability with
> Fortran common blocks, say http://support.microsoft.com/kb/51614

That matches - for multiple variables in the block - the Fortran 2003 standard.

> Unfortunately, the idiom "use a single variable common block, say common/x/y,
> access it via the name of the common block, followed by an underscore, say x_"
> is also common.  At least in my workplace it's the way everybody uses.

That matches what Fortran 2003 says about a single variable.

> In other words, we can't afford to break either way.

Well, as long as you do not use LTO it does not seem to matter. And if LTO you
have to decide for "struct" or against "struct". (And as a user, use BIND(C) -
either with COMMON or with TYPE - and you get a well-defined result.)

I am leaning towards using a "struct" only when there are multiple variables,
which makes BIND(C) and non-BIND(C) behave identical. If the overwhelming
opinion is differently, one can still add a "&& attr->is_bind_c".


-- 


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

[Bug target/31644] [avr] can't find a register in class 'BASE_POINTER_REGS' while reloading 'asm'

[eric dot weddington at atmel dot com]

--- Comment #10 from eric dot weddington at atmel dot com  2010-01-29 17:47 
---
I have in my list this bug as fixed in 4.4.0. Closing.


-- 

eric dot weddington at atmel dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.4.0


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

[Bug target/18617] missed volatile variable optimizations

[eric dot weddington at atmel dot com]

--- Comment #4 from eric dot weddington at atmel dot com  2010-01-29 17:50 
---
Closing as WONTFIX.


-- 

eric dot weddington at atmel dot com changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||WONTFIX


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

[Bug testsuite/41701] scan-assembler-not has false positives

[meissner at gcc dot gnu dot org]

--- Comment #2 from meissner at gcc dot gnu dot org  2010-01-29 17:53 
---
Subject: Bug 41701

Author: meissner
Date: Fri Jan 29 17:53:46 2010
New Revision: 156359

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156359
Log:
PR 41701, prevent pow in compiler pathname from a false error

Modified:
trunk/gcc/testsuite/gcc.dg/builtins-58.c


-- 


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

[Bug testsuite/41701] scan-assembler-not has false positives

[meissner at gcc dot gnu dot org]

--- Comment #3 from meissner at gcc dot gnu dot org  2010-01-29 17:54 
---
Subject: Bug 41701

Author: meissner
Date: Fri Jan 29 17:54:14 2010
New Revision: 156360

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156360
Log:
PR 41701, prevent pow in compiler pathname from a false error

Modified:
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/40850] double free in nested types with allocatable components

[mrestelli at gmail dot com]

--- Comment #7 from mrestelli at gmail dot com  2010-01-29 18:24 ---
(In reply to comment #5)
> Further reduced test case:
> 
> 
>   type t
> integer, allocatable :: d(:)
>   end type
>   type(t), allocatable :: a(:)
> 
>   allocate(a(2))
>   call sub( (/ a /) )
> 
> contains
> 
>   subroutine sub(b)
> type(t) :: b(:)
>   end subroutine
> 
> end
> 
> 
> The dump still has more than 200 lines and five __builtin_free's.
> 


Not sure if this is correct or useful, since I don't know the gfortran
internals at all, but anyway, mostly out of curiosity: my impression
is that the problem is in the lines 187-222 of the
-fdump-tree-original output file. More precisely (starting with line
186):


sub (&atmp.6);
Here we free atmp.3.data (without worrying about the allocation status
of the elements)
{
  void * D.1574;

  D.1574 = (void *) atmp.3.data;
  if (D.1574 != 0B)
{
  __builtin_free (D.1574);
}
}
Here we free atmp.6.data (again, without worrying about the allocation
status of the elements)
{
  void * D.1593;

  D.1593 = (void *) atmp.6.data;
  if (D.1593 != 0B)
{
  __builtin_free (D.1593);
}
}
Now we look at the elements of atmp.6.data to check whether we have to
free them too. It seems to the me that this block should be moved
before the previous one (or eliminated at all, as it is done for
atmp.3.data)
if ((struct t[0:] * restrict) atmp.6.data != 0B)
  {
D.1596 = (atmp.6.dim[0].ubound - atmp.6.dim[0].lbound) + 1;
D.1597 = atmp.6.dim[0].stride * D.1596;
D.1598 = D.1597 + -1;
S.8 = 0;
while (1)
  {
if (S.8 > D.1598) goto L.5;
Here we access memory that has already been freed
if ((*(struct t[0:] * restrict) atmp.6.data)[S.8].d.data != 0B)
  {
__builtin_free ((void *) (*(struct t[0:] * restrict)
atmp.6.data)[S.8].d.data);
  }
(*(struct t[0:] * restrict) atmp.6.data)[S.8].d.data = 0B;
S.8 = S.8 + 1;
  }
L.5:;
  }


-- 


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

[Bug fortran/42888] [4.5 Regression] ICE in fold_convert_loc, at fold-const.c:2670

[janus at gcc dot gnu dot org]

--- Comment #14 from janus at gcc dot gnu dot org  2010-01-29 19:01 ---
Ok, I think the best solution is to move the code setting up the initializer
back to resolve.c. Here is a patch which does so (without any testsuite
regressions):


Index: gcc/fortran/trans-stmt.c
===
--- gcc/fortran/trans-stmt.c(revision 156357)
+++ gcc/fortran/trans-stmt.c(working copy)
@@ -4176,14 +4176,6 @@ gfc_trans_allocate (gfc_code * code)
  tmp = gfc_build_memcpy_call (dst.expr, src.expr, memsz);
  gfc_add_expr_to_block (&block, tmp);
}
-  /* Add default initializer for those derived types that need them.  */
-  else if (expr->ts.type == BT_DERIVED
-  && (init_e = gfc_default_initializer (&expr->ts)))
-   {
- tmp = gfc_trans_assignment (gfc_expr_to_initialize (expr),
- init_e, true);
- gfc_add_expr_to_block (&block, tmp);
-   }

   /* Allocation of CLASS entities.  */
   gfc_free_expr (expr);
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c   (revision 156357)
+++ gcc/fortran/resolve.c   (working copy)
@@ -6099,6 +6099,7 @@ resolve_allocate_expr (gfc_expr *e, gfc_code *code
   gfc_symbol *sym;
   gfc_alloc *a;
   gfc_component *c;
+  gfc_expr *init_e;

   /* Check INTENT(IN), unless the object is a sub-component of a pointer.  */
   check_intent_in = 1;
@@ -6223,6 +6224,34 @@ resolve_allocate_expr (gfc_expr *e, gfc_code *code
 sym->name, &e->where);
   return FAILURE;
 }
+
+  if (!code->expr3)
+{
+  /* Add default initializer for those derived types that need them.  */
+  if (e->ts.type == BT_DERIVED
+ && (init_e = gfc_default_initializer (&e->ts)))
+   {
+ gfc_code *init_st = gfc_get_code ();
+ init_st->loc = code->loc;
+ init_st->op = EXEC_INIT_ASSIGN;
+ init_st->expr1 = gfc_expr_to_initialize (e);
+ init_st->expr2 = init_e;
+ init_st->next = code->next;
+ code->next = init_st;
+   }
+  else if (e->ts.type == BT_CLASS && code->ext.alloc.ts.type == BT_UNKNOWN
+  && (init_e = gfc_default_initializer
(&e->ts.u.derived->components->ts)))
+   {
+ gfc_code *init_st = gfc_get_code ();
+ init_st->loc = code->loc;
+ init_st->op = EXEC_INIT_ASSIGN;
+ init_st->expr1 = gfc_expr_to_initialize (e);
+ gfc_add_component_ref (init_st->expr1, "$data");
+ init_st->expr2 = init_e;
+ init_st->next = code->next;
+ code->next = init_st;
+   }
+}

   if (pointer || dimension == 0)
 return SUCCESS;


Note: There is another call to 'gfc_default_initializer' in
'gfc_trans_allocate', which should be moved to resolve.c too, I guess.


-- 


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

[Bug fortran/42888] [4.5 Regression] ICE in fold_convert_loc, at fold-const.c:2670

[janus at gcc dot gnu dot org]

--- Comment #15 from janus at gcc dot gnu dot org  2010-01-29 19:18 ---
(In reply to comment #14)
> Note: There is another call to 'gfc_default_initializer' in
> 'gfc_trans_allocate', which should be moved to resolve.c too, I guess.

Here is a small test case (very similar to comment #0, but with CLASS) which
confirms this:


  type t
 integer :: X = -999.0   ! Real initializer!
  end type t

  class(t), allocatable :: x
  allocate (x) ! works
  allocate (t::x)  ! ICE

end


-- 


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

[Bug c/42898] New: Problem initializing volatile structures

[gandalf at winds dot org]

I've recently upgraded to GCC 4.3.2 from 4.2.2, and I noticed a strange
change in how volatile bitmask structures are optimized.

Consider the following code (compiled using just the -O3 option):


/* 32-bit MMIO */
struct hardware {
  int parm1:8;
  int :4;
  int parm2:4;
  int parm3:15;
  int parm4:1;
};

void f1()
{
  volatile struct hardware *ptr=(void *)0x11223344;

  *ptr=(struct hardware) {
.parm1=42,
.parm2=13,
.parm3=11850,
.parm4=1,
  };
}

void f2()
{
  volatile struct hardware *ptr=(void *)0x11223344;

  struct hardware set={
.parm1=42,
.parm2=13,
.parm3=11850,
.parm4=1,
  };

  *ptr=set;
}


In GCC 4.3.2, this produces the following assembly:

f1:
movl$0, 287454020
movb$42, 287454020
movl287454020, %eax
andb$15, %ah
orb $208, %ah
movl%eax, 287454020
movl287454020, %eax
andl$-2147418113, %eax
orl $776601600, %eax
movl%eax, 287454020
movl287454020, %eax
orl $-2147483648, %eax
movl%eax, 287454020
ret

f2:
movl$-1370828758, 287454020
ret

Aren't both functions syntactically the same, and shouldn't they produce the
same optimized code as in "f2" above? This used to be the case in GCC 4.2.2.

The problem I'm seeing, apart from the lack of optimization, is that "f1"
causes 5 separate writes to a single MMIO register, instead of 1. This
particular hardware register is only expecting one write to this location, and
when multiple writes are received it causes the hardware to fail.

If this new behavior is intended, is there some sort of attribute I can add to
the code to get the original 4.2.2 behavior back?

Thanks,
 -Byron


-- 
   Summary: Problem initializing volatile structures
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gandalf at winds dot org
 GCC build triplet: x86_64-pc-linux-gnu
  GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu


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

[Bug c/42898] [4.3/4.4/4.5 Regression] volatile structures and compound literals

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2010-01-29 19:38 ---
Confirmed, I think this was caused/exposed by:
2007-11-20  Jakub Jelinek  

PR c/34146
* c-gimplify.c (optimize_compound_literals_in_ctor): New function.
(c_gimplify_expr): Use it.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||wrong-code
   Last reconfirmed|-00-00 00:00:00 |2010-01-29 19:38:02
   date||
Summary|volatile structures and |[4.3/4.4/4.5 Regression]
   |compound literals   |volatile structures and
   ||compound literals
   Target Milestone|--- |4.4.4


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

[Bug target/42895] Low registers are preferred than register ip in thumb2 mode

[carrot at google dot com]

--- Comment #4 from carrot at google dot com  2010-01-29 19:42 ---
(In reply to comment #3)
> See arm.c:#define REG_ALLOC_ORDER. Comment before it says: " It is good to use
> ip since no saving is required (though calls clobber it) and it never contains
> function parameters. It is quite good to use lr since other calls may clobber
> it anyway."
> 
> So in REG_ALLOC_ORDER, ip (reg 12) and lr (reg 14) come before before r4-r7:
> 
> #define REG_ALLOC_ORDER \
> {   \
>  3,  2,  1,  0, 12, 14,  4,  5, \
>  6,  7,  8, 10,  9, 11, 13, 15, \
> 16, 17, 18, 19, 20, 21, 22, 23, \
> 27, 28, 29, 30, 31, 32, 33, 34, \
> 35, 36, 37, 38, 39, 40, 41, 42, \
> 43, 44, 45, 46, 47, 48, 49, 50, \
> 51, 52, 53, 54, 55, 56, 57, 58, \
> 59, 60, 61, 62, \
> 24, 25, 26, \
> 
> So the register allocator faithfully does what the IBTK has asked it to :-)
> 

When I set the option -march=armv5te, gcc can generate the expected result, use
r6 and r7 instead of ip. Then I noticed the function
arm_order_regs_for_local_alloc which over writes the default REG_ALLOC_ORDER
with

/* Order of allocation of core registers for Thumb: this allocation is
   written over the corresponding initial entries of the array
   initialized with REG_ALLOC_ORDER.  We allocate all low registers
   first.  Saving and restoring a low register is usually cheaper than
   using a call-clobbered high register.  */

static const int thumb_core_reg_alloc_order[] =
{
   3,  2,  1,  0,  4,  5,  6,  7,
  14, 12,  8,  9, 10, 11, 13, 15
};

But the confusion part is:

1. It rewrites the order when the target is TARGET_THUMB, it should also impact
THUMB2.
2. When I set a breakpoint to arm_order_regs_for_local_alloc and try to find
when the order is changed, the breakpoint is never triggered, even with option
-march=armv5te.


-- 


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

[Bug target/42895] Low registers are preferred than register ip in thumb2 mode

[steven at gcc dot gnu dot org]

--- Comment #5 from steven at gcc dot gnu dot org  2010-01-29 19:49 ---
This isn't confusing at all. ORDER_REGS_FOR_LOCAL_ALLOC is unused. All targets
that define it should be fixed.


-- 


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

[Bug middle-end/42899] New: DSE fails: no-op modification of global data pessimized code-size

[aldot at gcc dot gnu dot org]

John Regehr points out this size-regression WRT 3.4:

Sometimes a function modifies globals but even so has no net effect:

http://embed.cs.utah.edu/embarrassing/jan_10/harvest/source/8A/8AB0B238.shtml
http://embed.cs.utah.edu/embarrassing/jan_10/harvest/source/14/14157FE8.shtml

Somehow gcc3 sees these but everyone else including gcc4 fails.

$ cat 8AB0B238.c
struct frame_info;
struct frame_info;
struct frame_info;
struct frame_info;
struct frame_info;
struct frame_info;
struct frame_info;
struct frame_info;
struct frame_info;
void tui_registers_changed_hook (void);
extern struct frame_info *deprecated_selected_frame;
int tui_refreshing_registers = 0;
void
tui_registers_changed_hook (void)
{
  struct frame_info *fi;

  fi = deprecated_selected_frame;
  if (fi)
{
  if (tui_refreshing_registers == 0)
{
  tui_refreshing_registers = 1;
  tui_refreshing_registers = 0;
}
}
  return;
}

$ for i in 3.4 4.4 4.5.orig-HEAD;do gcc-$i -fomit-frame-pointer -Os -c -o
8AB0B238.o-gcc-$i 8AB0B238.c;done
$ size 8AB0B238.o*
   textdata bss dec hex filename
  1   0   4   5   5 8AB0B238.o-gcc-3.4
 29   0   4  33  21 8AB0B238.o-gcc-4.4
 29   0   4  33  21 8AB0B238.o-gcc-4.5.orig-HEAD


-- 
   Summary: DSE fails: no-op modification of global data pessimized
code-size
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aldot at gcc dot gnu dot org
OtherBugsDependingO 16996
 nThis:


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

[Bug tree-optimization/42893] [4.3/4.4/4.5 Regression] Missed conditionally dead store elimination

[steven at gcc dot gnu dot org]

--- Comment #3 from steven at gcc dot gnu dot org  2010-01-29 19:58 ---
*** Bug 42899 has been marked as a duplicate of this bug. ***


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||aldot at gcc dot gnu dot org


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

[Bug middle-end/42899] DSE fails: no-op modification of global data pessimized code-size

[steven at gcc dot gnu dot org]

--- Comment #1 from steven at gcc dot gnu dot org  2010-01-29 19:58 ---


*** This bug has been marked as a duplicate of 42893 ***


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug tree-optimization/42893] [4.3/4.4/4.5 Regression] Missed conditionally dead store elimination

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2010-01-29 20:03 ---
Note, I think this works on targets where movs cannot have a mem with a
constant like most RISC targets.


-- 


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

[Bug tree-optimization/42893] [4.3/4.4/4.5 Regression] Missed conditionally dead store elimination

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2010-01-29 20:07 ---
Yep:
tui_registers_changed_hook:
blr

Which means this is the same as PR 23488 which was caused by:
2005-07-30  Jan Hubicka  

* expr.c (expand_expr_real_1): Do not load mem targets into register.
* i386.c (ix86_fixup_binary_operands): Likewise.
(ix86_expand_unary_operator): Likewise.
(ix86_expand_fp_absneg_operator): Likewise.
* optabs.c (expand_vec_cond_expr): Validate dest.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 GCC target triplet||i?86-*-*


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

[Bug fortran/42900] New: gfortran.dg/stat_[12].f90 may fail on NFS filesystems

[ro at gcc dot gnu dot org]

I've noticed that all the gfortran.dg/stat_[12].f90 fail for me on all
platforms
(i.e. sparc-sun-solaris2, alpha-dec-osf, mips-sgi-irix).

FAIL: gfortran.dg/stat_1.f90  -O0  execution test

at all optimization levels.  Running it under gdb reveals that it aborts here:

#4  0x000110f0 in MAIN__ ()
at /vol/gcc/src/hg/trunk/solaris/gcc/testsuite/gfortran.dg/stat_1.f90:19
19if (s1(6) /= getgid() .and. getgid() /= 0) call abort

Unfortunately, the test is bogus: at least on NFS with either the sgid bit set
on the parent directory or with the filesystem mounted with the grpid option,
newly created files are created with the gid of the directory, not the primary
group of the owner.

I don't know how best to fix this (maybe check if the file's group is in the 
set of supplemental groups, if libgfortran supports getgroups).


-- 
   Summary: gfortran.dg/stat_[12].f90 may fail on NFS filesystems
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ro at gcc dot gnu dot org


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

[Bug tree-optimization/42893] [4.3/4.4/4.5 Regression] Missed conditionally dead store elimination

[steven at gcc dot gnu dot org]

--- Comment #6 from steven at gcc dot gnu dot org  2010-01-29 20:17 ---
I think the issue here is more that we should look for a way to optimize this
early on. I'm guessing it's one of the ce[123] passes that cleans this up for
you on your RISCy machine? IMHO it would be better even in your case to nuke
dumb code like this in GIMPLE (enabling other optimizations, etc.).


-- 


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

[Bug tree-optimization/42893] [4.3/4.4/4.5 Regression] Missed conditionally dead store elimination

[pinskia at gcc dot gnu dot org]

--- Comment #7 from pinskia at gcc dot gnu dot org  2010-01-29 20:19 ---
(In reply to comment #6)
> I think the issue here is more that we should look for a way to optimize this
> early on. I'm guessing it's one of the ce[123] passes that cleans this up for
> you on your RISCy machine? IMHO it would be better even in your case to nuke
> dumb code like this in GIMPLE (enabling other optimizations, etc.).

Note I tested on powerpc-linux-gnu but it should work on most other targets;
just x86 is the crazy popular target which supports constants in memory stores
:).


-- 


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

[Bug tree-optimization/38785] [4.3/4.4/4.5 Regression] huge performance regression on EEMBC bitmnp01

[amylaar at gcc dot gnu dot org]

--- Comment #20 from amylaar at gcc dot gnu dot org  2010-01-29 20:33 
---
Subject: Bug 38785

Author: amylaar
Date: Fri Jan 29 20:33:19 2010
New Revision: 156365

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156365
Log:
  PR tree-optimization/38785
  2009-02-02  J"orn Rennecke  
* tree-ssa-pre.c (ppre_n_insert_for_speed_p): New function.
* (do_partial_partial_insertion): Use it to throttle
insert_into_preds_of_block calls.
* common.opt (-ftree-pre-partial-partial-obliviously): New option.
  2009-01-15  Steven Bosscher  
http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00199.html
* opts.c (decode_options): Fix initialization of
flag_tree_switch_conversion.
* tree-ssa-pre.c: Update outline of the algorithm.
(bitmap_set_and): Prototype.
(insert_into_preds_of_block): Don't report discovery of partial
redundancies here, do so from the callers instead (see below).
(do_regular_insertion): Add counter for an estimate for the number
of inserts required to eliminate a partial redundancy.  If the
current function is optimized for size, only perform the partial
redundancy elimination if this requires inserting in only one
predecessor.  Report all found partial redundancies from here.
(do_partial_partial_insertion): Report them from here too.
(insert_aux): Do not insert for partial-partial redundancies when
optimizing for size.
(do_pre): Run FRE at least, if PRE is disabled.
(gate_pre): Return true if flag_tree pre or flag_tree_fre is set.
  2009-01-15  J"orn Rennecke  
* common.opt (ftree-pre-partial-partial): New option.
* opts.c (decode_options): Initialize flag_tree_pre_partial_partial.
* tree-ssa-pre.c (execute_pre): Use flag_tree_pre_partial_partial.

Modified:
branches/mpost-opt-imp-20100127/gcc/ChangeLog.mpost
branches/mpost-opt-imp-20100127/gcc/FAILED-PATCHES
branches/mpost-opt-imp-20100127/gcc/common.opt
branches/mpost-opt-imp-20100127/gcc/opts.c
branches/mpost-opt-imp-20100127/gcc/tree-ssa-pre.c


-- 


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

[Bug target/36539] Poor register allocation from IRA

[vmakarov at redhat dot com]

--- Comment #10 from vmakarov at redhat dot com  2010-01-29 20:33 ---
Jeff, I saw analogous problem when I worked on improving IRA performance.  I
checked the approach you are proposing.  But it works considerably worse on
SPEC2000.  Finally, I found that the best conflicting cost technique works when
we change it only for one hard register when pseudo best cost is achieved on
one hard register, e.g. best cost is achieved on register class containing one
hard register or assigning particular hard register removes a copy.

Why technique you are proposing does not work well in average for classes (like
Q_REGS in this case) containing more one register? This is just my speculation.
 If # conflicting pseudos is less size of QREGS we should not modify conflict
costs of the pseudo for QREGS because QREGS for the conflicting pseudos can be
more profitable and we still will assign QREG for the pseudo.  Even if #
conflicting pseudos > size of QREGS, they still might be assigned to hard
registers which are only part of QREGS.  It is hard to predict.

I am not saying that we should not work on this problem. I think we should try
more sophisticated heuristics.  Although I don't know what one (it could be
conflict cost modifications only when register pressure for QREGS is high
during pseudo live range but such heuristic will take some time to implement
and i am not still sure that it will work better in average).

Unfortunately, there will be cases when RA could work better because RA
algorithms are heuristic ones.  What we should focus on is to improve
performance for credible benchmarks like SPEC2000/SPEC2006.


-- 


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

[Bug middle-end/37448] [4.3/4.4/4.5 Regression] gcc 4.3.1 cannot compile big function

[hubicka at ucw dot cz]

--- Comment #40 from hubicka at ucw dot cz  2010-01-29 20:54 ---
Subject: Re:  [4.3/4.4/4.5 Regression] gcc 4.3.1 cannot compile big function

> But it miscompares.  Honza?!
Patch seems sane to me, so I guess it was other bootstrap issue.
I was actually working on similar fix yesterday just in more general
setting.  Similar issue can be triggered with main inliner too, that
might provoke need to later make this caching global, but lets wait for
testcase since there might be other issues if you get that many inline
candidates and inlined calls.

Thanks for looking into this,
Honza


-- 


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

[Bug fortran/42901] New: reading array of structures from namelist fails

[arnold dot moene at wur dot nl]

Reading a namelist that contains a variable that is an array of structures
fails. Whatever the index of the array element, the values that are read are
assigned to the first array element.

Below a more or less minimal example:

PROGRAM test_nml

! Start declarations
! Struct with one member
TYPE FIELD_DESCR
   INTEGERNUMBER   ! number
END TYPE

! Array of structs
TYPE FSETUP
   TYPE (FIELD_DESCR), DIMENSION(3) :: VEL ! 3 velocity components
END TYPE

!Actual variable
TYPE (FSETUP) FIELD_SETUP

!Namelist
NAMELIST /NL_SETUP/ FIELD_SETUP
! End of declarations


! Reading succeeds, but only fills struct of first array element
READ(*,NML=NL_SETUP)
! Show failure
WRITE(*,NML=NL_SETUP)

END PROGRAM test_nml


If fed with the following namelist:

&NL_SETUP
 FIELD_SETUP%VEL(1)%NUMBER=  3,
 FIELD_SETUP%VEL(2)%NUMBER=  9,
 FIELD_SETUP%VEL(3)%NUMBER=  27,
/


The resulting output is:

&NL_SETUP
 FIELD_SETUP%VEL(1)%NUMBER= 27,
 FIELD_SETUP%VEL(2)%NUMBER=  0,
 FIELD_SETUP%VEL(3)%NUMBER=-1209668170,  /


At least ifort knows how to deal with this correctly.


-- 
   Summary: reading array of structures from namelist fails
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: arnold dot moene at wur dot nl
  GCC host triplet: Linux localhost 2.6.27.19-desktop586-1mnb
GCC target triplet: i586-manbo-linux-gnu


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

[Bug target/41399] [4.5 Regression] Scheduler gives huge dependence graph compiling fortran/intrinsic.c on ARM

[vmakarov at redhat dot com]

--- Comment #21 from vmakarov at redhat dot com  2010-01-29 21:54 ---
Thanks everyone who works on the bug.

  I am sorry that the bug was really introduced by my patch more accurately by
the part which should fix reload crashes when the 1st scheduling works for some
targets.  The patch creates huge number dependencies on stack register (r13)
which could be used for reloads according to *arm_movsi_insn.  But pseudos can
not be assigned the stack register because the register is fixed and we have
not to add dependencies for the pseudo to fix the reload craches.

The following small fix will solve the PR.

Index: ../../gcc/gcc/sched-deps.c
===
--- ../../gcc/gcc/sched-deps.c  (revision 155624)
+++ ../../gcc/gcc/sched-deps.c  (working copy)
@@ -2623,6 +2623,7 @@ sched_analyze_insn (struct deps *deps, r
   extract_insn (insn);
   preprocess_constraints ();
   ira_implicitly_set_insn_hard_regs (&temp);
+  AND_COMPL_HARD_REG_SET (temp, ira_no_alloc_regs);
   IOR_HARD_REG_SET (implicit_reg_pending_clobbers, temp);
 }

I'll submit the patch on Monday after some testing.


-- 


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

[Bug fortran/42901] reading array of structures from namelist fails

[jvdelisle at gcc dot gnu dot org]

--- Comment #1 from jvdelisle at gcc dot gnu dot org  2010-01-29 22:27 
---
I will have a look at this one.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jvdelisle at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-01-29 22:27:13
   date||


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

[Bug tree-optimization/42902] New: gcc.dg/pr34668-1.c FAILs on x86_64-unknown-linux-gnu

[amylaar at gcc dot gnu dot org]

gcc.dg/pr34668-1.c FAILs on x86_64-unknown-linux-gnu
(e.g. gcc{11,13,16}.fsffrance.org).


-- 
   Summary: gcc.dg/pr34668-1.c FAILs on x86_64-unknown-linux-gnu
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
  GCC host triplet: x86_64-unknown-linux-gnu


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

[Bug tree-optimization/42902] gcc.dg/pr34668-1.c FAILs on x86_64-unknown-linux-gnu

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2010-01-29 22:32 ---


*** This bug has been marked as a duplicate of 39959 ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c/39959] [4.5 Regression] IMA is broken

[pinskia at gcc dot gnu dot org]

--- Comment #19 from pinskia at gcc dot gnu dot org  2010-01-29 22:32 
---
*** Bug 42902 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||amylaar at gcc dot gnu dot
   ||org


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

[Bug fortran/42900] gfortran.dg/stat_[12].f90 may fail on NFS filesystems

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2010-01-29 22:35 ---
I'd say add a comment to the testcase and WONTFIX.


-- 


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

[Bug tree-optimization/42893] [4.3/4.4/4.5 Regression] Missed conditionally dead store elimination

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2010-01-29 22:37 ---
(In reply to comment #6)
> I think the issue here is more that we should look for a way to optimize this
> early on. I'm guessing it's one of the ce[123] passes that cleans this up for
> you on your RISCy machine? IMHO it would be better even in your case to nuke
> dumb code like this in GIMPLE (enabling other optimizations, etc.).

Predicated value-numbering with redundant store elimination should fix this.
Matz is working on that for 4.6.


-- 


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

[Bug middle-end/42898] [4.3/4.4/4.5 Regression] volatile structures and compound literal initializers

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-01-29 22:41 ---
Yep:

f2 ()
{
  volatile struct hardware * ptr;
  struct hardware set;

  ptr = 287454020B;
  set = {};
  set.parm1 = 42;
  set.parm2 = -3;
  set.parm3 = 11850;
  set.parm4 = -1;
  *ptr = set;
}

f1 ()
{
  volatile struct hardware * ptr;

  ptr = 287454020B;
  *ptr = {};
  ptr->parm1 = 42;
  ptr->parm2 = -3;
  ptr->parm3 = 11850;
  ptr->parm4 = -1;
}

we need to gimplify f1 exactly the same as f2, using a temporary.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|c   |middle-end
Summary|[4.3/4.4/4.5 Regression]|[4.3/4.4/4.5 Regression]
   |volatile structures and |volatile structures and
   |compound literals   |compound literal
   ||initializers


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

[Bug fortran/42888] [4.5 Regression] ICE in fold_convert_loc, at fold-const.c:2670

[janus at gcc dot gnu dot org]

--- Comment #16 from janus at gcc dot gnu dot org  2010-01-29 22:41 ---
Created an attachment (id=19754)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19754&action=view)
patch

Here is an updated patch which fixes the test case in the last comment and the
original problem.


-- 


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

[Bug middle-end/42898] [4.3/4.4/4.5 Regression] volatile structures and compound literal initializers

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|4.4.4   |4.3.6


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

[Bug middle-end/42898] [4.3/4.4/4.5 Regression] volatile structures and compound literal initializers

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2010-01-29 22:42 ---
I will have a look.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2010-01-29 19:38:02 |2010-01-29 22:42:15
   date||


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

[Bug target/41399] [4.5 Regression] Scheduler gives huge dependence graph compiling fortran/intrinsic.c on ARM

[steven at gcc dot gnu dot org]

--- Comment #22 from steven at gcc dot gnu dot org  2010-01-29 22:46 ---
FWIW: with the patch of comment #21 compile time goes down by a factor 10 and
memory tops out at 107MB with the same x86_64 X armv5tejl-unknown-linux-gnueabi
compiler as yesterday (but this time patched).


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||patch


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

[Bug target/42895] Low registers are preferred than register ip in thumb2 mode

[carrot at google dot com]

--- Comment #6 from carrot at google dot com  2010-01-29 22:47 ---
I tried to change the register order in REG_ALLOC_ORDER, moved ip and lr after
r4/r5/r6/r7, but I still got the same result.


-- 


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

[Bug fortran/42901] [4.3/4.4/4.5 Regression] reading array of structures from namelist fails

[burnus at gcc dot gnu dot org]

-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||wrong-code
  Known to fail||4.4.2 4.3.4 4.5.0
  Known to work||4.2.1 4.1.2
   Priority|P3  |P4
Summary|reading array of structures |[4.3/4.4/4.5 Regression]
   |from namelist fails |reading array of structures
   ||from namelist fails
   Target Milestone|--- |4.4.4


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

[Bug rtl-optimization/39837] [4.3/4.4/4.5 regression] extra spills due to RTL LICM

[steven at gcc dot gnu dot org]

--- Comment #7 from steven at gcc dot gnu dot org  2010-01-29 23:11 ---
Created an attachment (id=19755)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19755&action=view)
Hack to look for invariants inside MEMs

Re. comment #4:

The following code would also be correct, right?
test:
push{r4, lr}
sub sp, sp, #8
mov r3, #0
add r4, sp, #4
str r3, [sp, #4]
.L2:
mov r0, r4
bl  func
ldr r3, [r4]
cmp r3, #12
ble .L2
add sp, sp, #8
@ sp needed for prologue
pop {r4, pc}
.size   test, .-test
.ident  "GCC: (GNU) 4.5.0 20100129 (experimental) [trunk revision
156352]"

I have a really bad hack that makes loop-invariant look at addresses inside
MEMs (attached).
(Looking at Zdenek:) Would something like this in a more polished and actually
verified&tested form be a good idea?


-- 


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

[Bug target/42879] Replace "tst r3, 1" with "lsl r3, r3, 31" in thumb2

[ramana at gcc dot gnu dot org]

--- Comment #2 from ramana at gcc dot gnu dot org  2010-01-29 23:32 ---
(In reply to comment #1)
> Could be done in a peephole if there's a scratch available for the 
> destination.
> 

We already do this for Thumb1 don't we ? Turning on *tlobits_cbranch and the
appropriate bit in arm.c should be enough but GAS doesn't want to assemble lsl
r2,r3, #1 as a 16 bit instruction yet. 

cheers
Ramana


-- 


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