[Bug middle-end/40281] [4.4 Regression] -fprefetch-loop-arrays: ICE: in initialize_matrix_A, at tree-data-ref.c:1887

[spop at gcc dot gnu dot org]

--- Comment #13 from spop at gcc dot gnu dot org  2010-01-13 07:59 ---
Subject: Bug 40281

Author: spop
Date: Wed Jan 13 07:58:50 2010
New Revision: 155851

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155851
Log:
2010-01-13  Sebastian Pop  

PR middle-end/40281
* tree-scalar-evolution.c (instantiate_scev_1): Base and stride
evolutions should not variate in inner loops.

* gcc.dg/graphite/pr40281.c: New.


Added:
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/graphite/pr40281.c
Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
branches/gcc-4_4-branch/gcc/tree-scalar-evolution.c


-- 


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

[Bug middle-end/42130] [graphite-branch] dealII fails

[spop at gcc dot gnu dot org]

--- Comment #10 from spop at gcc dot gnu dot org  2010-01-13 06:33 ---
This seems to still be wrong code, so P1.


-- 

spop at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P1


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

[Bug other/42713] [4.5 Regression] ICE - segfault in tsubst

[hjl dot tools at gmail dot com]

-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

  Known to fail||4.5.0
  Known to work||4.4.2
   Target Milestone|--- |4.5.0


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

[Bug other/42713] [4.5 Regression] ICE - segfault in tsubst

[hjl dot tools at gmail dot com]

--- Comment #2 from hjl dot tools at gmail dot com  2010-01-13 05:17 ---
It is caused by revision 145440:

http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg00060.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||dseketel at redhat dot com
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-01-13 05:17:30
   date||


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

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

[jvdelisle at gcc dot gnu dot org]

--- Comment #7 from jvdelisle at gcc dot gnu dot org  2010-01-13 04:24 
---
*** Bug 42680 has been marked as a duplicate of this bug. ***


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||anlauf at gmx dot de


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

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

[jvdelisle at gcc dot gnu dot org]

--- Comment #8 from jvdelisle at gcc dot gnu dot org  2010-01-13 04:24 
---
This is a duplicate and the patch in 42684 fixes it.

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


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

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

[jvdelisle at gcc dot gnu dot org]

--- Comment #6 from jvdelisle at gcc dot gnu dot org  2010-01-13 04:23 
---
Regression testing with the following patch passes.  I used p->sym->name
instead of q->sym->name in place of NULL, but I do not think it matters.

Index: interface.c
===
--- interface.c (revision 155799)
+++ interface.c (working copy)
@@ -1126,7 +1126,7 @@
if (p->sym->name == q->sym->name && p->sym->module == q->sym->module)
  continue;

-   if (gfc_compare_interfaces (p->sym, q->sym, NULL, generic_flag, 0,
+   if (gfc_compare_interfaces (p->sym, q->sym, p->sym->name, generic_flag,
0,
NULL, 0))
  {
if (referenced)

and allows operator.f90 to compile as well as the test case in PR42680.

I think this does it.  I will submit to list for approval.


-- 


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

[Bug c/42721] New: possible integer wrong code bug

[regehr at cs dot utah dot edu]

Seen on Ubuntu 9.10.  I think "1" is the right answer.

reg...@john-home:~/volatile/bugs/tmp254$ current-gcc -O1 small.c -o small
reg...@john-home:~/volatile/bugs/tmp254$ ./small
checksum = 1
reg...@john-home:~/volatile/bugs/tmp254$ current-gcc -O2 small.c -o small
reg...@john-home:~/volatile/bugs/tmp254$ ./small
checksum = 0
reg...@john-home:~/volatile/bugs/tmp254$ current-gcc -v
Using built-in specs.
COLLECT_GCC=current-gcc
COLLECT_LTO_WRAPPER=/home/regehr/z/tmp/gcc-r155838-install/libexec/gcc/i686-pc-linux-gnu/4.5.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../configure --with-libelf=/usr/local --enable-lto
--prefix=/home/regehr/z/tmp/gcc-r155838-install --program-prefix=r155838-
--enable-languages=c,c++
Thread model: posix
gcc version 4.5.0 20100112 (experimental) (GCC) 
reg...@john-home:~/volatile/bugs/tmp254$ cat small.c
#include 
#include 

static uint64_t safe_div_uint64_t (uint64_t ui1, uint64_t ui2)
{
  return (ui2 == 0) ? ui1 : (ui1 / ui2);
}

static int8_t safe_mod_int8_t (int8_t si1, int8_t si2)
{
  return 
((si2 == 0) || ((si1 == INT8_MIN) && (si2 == (-1 ? 
si1 : 
(si1 % si2);
}

static int32_t g_5;
static int32_t g_11;

int main (void)
{
  uint64_t l_7 = 0x509CB0BEFCDF11BBLL;
  g_11 ^= l_7 && ((safe_div_uint64_t ((safe_mod_int8_t (g_5, 0)), -1L)) != 1L);
  printf ("checksum = %d\n", g_11);
  return 0;
}


-- 
   Summary: possible integer wrong code bug
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: regehr at cs dot utah dot edu
 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=42721

[Bug c/42716] [4.5 Regression] ICE in extract_range_from_assert, at tree-vrp.c:1423

[hjl dot tools at gmail dot com]

--- Comment #1 from hjl dot tools at gmail dot com  2010-01-13 03:18 ---
It is caused by revision 152563:

http://gcc.gnu.org/ml/gcc-cvs/2009-10/msg00212.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||matz at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  Known to fail||4.5.0
  Known to work||4.4.2
   Last reconfirmed|-00-00 00:00:00 |2010-01-13 03:18:38
   date||
Summary|ICE in  |[4.5 Regression] ICE in
   |extract_range_from_assert,  |extract_range_from_assert,
   |at tree-vrp.c:1423  |at tree-vrp.c:1423
   Target Milestone|--- |4.5.0
Version|unknown |4.5.0


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

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

[jvdelisle at gcc dot gnu dot org]

--- Comment #5 from jvdelisle at gcc dot gnu dot org  2010-01-13 03:13 
---
The problem is here.  Wrong argument passed to gfc_compare_interfaces.

It can't be NULL.  I am testing this patch.

Index: interface.c
===
--- interface.c (revision 155799)
+++ interface.c (working copy)
@@ -1126,7 +1126,7 @@
if (p->sym->name == q->sym->name && p->sym->module == q->sym->module)
  continue;

-   if (gfc_compare_interfaces (p->sym, q->sym, NULL, generic_flag, 0,
+   if (gfc_compare_interfaces (p->sym, q->sym, q->sym->name, generic_flag,
0,
NULL, 0))
  {
if (referenced)


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

   Last reconfirmed|2010-01-11 08:32:42 |2010-01-13 03:13:52
   date||


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

[Bug tree-optimization/42720] New: Empty loop generated at unswitch-loops with -O2 -fprofile-use

[jingyu at google dot com]

The bug is triggered with -O2 -fprofile-use.

test case, loop.cpp:

int fun_b(int hbs[], int num, void *obj) {
 int i;
 int s = 0;
 for (i = 0; i < num; i++) {
   if (obj != 0) {
 if ((int)obj - hbs[i] > 0) {
   s += hbs[i];
 }
   }
 }
 return s;
}

int main () {
 int i;
 int s = 0;
 int hbs[100];
 for (i = 0; i < 100; ++i) {
   hbs[i] = i * 2000 + 10;
 }
 for (i = 0; i < 20; ++i) {
   s += fun_b (hbs, 100, &hbs[i]);
 }
 return s;
}

Profile the program. Apparently the loop inside fun_b() is hot.

$arm-eabi-g++ loop.cpp -O2 -fprofile-use --save-temps -c -o loop.o

We we see an empty loop (.L5) if obj==0, in function fun_b.

_Z5fun_bPiiPv:
   @ args = 0, pretend = 0, frame = 0
   @ frame_needed = 0, uses_anonymous_args = 0
   @ link register save eliminated.
   cmp r1, #0
   stmfd   sp!, {r4, r5}
   mov r3, r0
   ble .L57
   cmp r2, #0   <--- "if (obj != 0)" is moved out of loop
   beq .L5
 
.L3:
   ldmfd   sp!, {r4, r5}
   bx  lr
.L5: ;;  if (obj == 0), empty loop
   add r2, r2, #1;;
   cmp r2, r1;;
   bne .L5   ;;
.L57:
   mov r0, #0
   b   .L3

The empty loop (.L5) should have been eliminated. I have tested -O2 without
-fprofile-use, where the empty loop is gone.

I find that the root cause of the inefficiency of -O2 FDO is that during
unswitch-loops, the simplification of loop conditions is missed when FDO is on. 

Let's say,
Version A: "-O2 -funswitch-loops", which does right thing.
Version B: "-O2 -fprofile-use". Version B generates an empty loop which should
be eliminated.

Before switch-loop pass, the loop (inner-most, hot) is

 loop {
if (obj != 0) {
  ...
}
  }

Both version A and version B perform one pass of unswitch-loop on this loop
body.
In function tree_unswitch_single_loop(),
after "nloop = tree_unswitch_loop (loop, bbs[i], cond)", the loop becomes

if (obj != 0) {
 loop {   < original copy of the loop
   if (obj != 0) {
 ...
   }
 }
} else {
 loop {  <- "nloop": a new copy of the loop
if (obj != 0) {
  ...
}
  }
}

Then, right before the end of tree_unswitch_single_loop(), gcc recursively
calls itself on modified loops.
  tree_unswitch_single_loop (nloop, num + 1);

>From here, Version A and Version B starts to perform differently.

For Version A ("-O2 -funswitch-loops"), gcc conditions looking for
unswitch-loop opportunity in the new loop "nloop".
It finds that the condition of the new loop can be simplified. Since obj is 0
when it comes to the new loop, gcc
replaces obj by 0. Thus the loop becomes

if (obj != 0) {
 loop {   < original copy of the loop
   if (obj != 0) {
 ...
   }
 }
} else {
 loop {   <- "nloop": a new copy of the loop
if (0 != 0) { <--- obj is replaced by "0"
  ...
}
  }
}
Therefore, in the TODO pass cleanup-cfg, the "nloop" is entirely removed.

However, for Version B ("-O2 -fprofile-use"), gcc finds that the "nloop" is a
cold loop, so it returns immediately, without checking if the condition can be
simplified. Thus nloop is not cleaned up by the following cleanup-cfg pass and
results in an empty loop.

The problematic code in is unswitch_single_loop() in loop-unswitch.c.

static void
unswitch_single_loop(struct loop *loop, ...)
{ ...
  /* Do not unswitch in cold areas.  */
  if (optimize_loop_for_size_p (loop))
{
   dump
   return;
 }
  ...
  do
{   ...
   /* Check whether the result can be predicted.  */
   for (acond = cond_checked; acond; acond = XEXP (acond, 1))
   simplify_using_condition (XEXP (acond, 0), &cond, NULL);
  ...
  } while (repeat);
...
  /* Unswitch the loop on this condition.  */
  nloop = unswitch_loop (loop, bbs[i], cond, cinsn);
  ...

  /* Invoke itself on modified loops.  */
  unswitch_single_loop (nloop, rconds, num + 1);
  unswitch_single_loop (loop, conds, num + 1);
  ...
}

To fix the empty loop problem, my thought is to propagate the conditions
immediately after nloop is inserted.

Any suggestion?

Thanks,
Jing


-- 
   Summary: Empty loop generated at unswitch-loops with -O2 -
fprofile-use
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
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=42720

[Bug c/42717] 4.5 Regression] ice: verify_ssa failed

[hjl dot tools at gmail dot com]

-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

  Known to fail||4.5.0
  Known to work||4.4.2
   Target Milestone|--- |4.5.0


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

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

[jingyu at google dot com]

--- Comment #6 from jingyu at google dot com  2010-01-13 01:18 ---
Subject: Re:  problematic REG_EQUAL note added to 
SUBREG

> We should try and set changed_i3_dest to 1 in this particular case as well.

Here is the patch which only changes changed_i3_dest for two
particular cases, where the dest of i3 really changed. The test case
attached to this bug is case2.

case 1:
   i1 = 0. i2=(parallel [(set p, ?)...]), i3=(set q, p)
-> newpat=(parallel[(set q, ?),...])
-> i3.pattern=newpat

case2:
   i1 = 0, i2=(set p, q), i3=(set subreg(s, reg(p), offset), a)
 ->newpat=(set p, )
 -> i3.pattern=newpat



Index: combine.c
===
--- combine.c   (revision 155801)
+++ combine.c   (working copy)
@@ -2531,6 +2531,10 @@ try_combine (rtx i3, rtx i2, rtx i1, int

  newpat = p2;
  i3_subst_into_i2 = 1;
+
+  /* If the result of the combination is recognized, the note of
i3
+   * needs to be removed. */
+  changed_i3_dest = 1;
  goto validate_replacement;
}
 }
@@ -2667,6 +2671,10 @@ try_combine (rtx i3, rtx i2, rtx i1, int
 immed_double_const (olo, ohi, GET_MODE (SET_DEST (temp;

  newpat = PATTERN (i2);
+
+  /* If the result of combination is recognized, the note of
i3 needs to
+   * to be removed. */
+  changed_i3_dest = 1;
  goto validate_replacement;
}
 }
@@ -3060,6 +3068,9 @@ try_combine (rtx i3, rtx i2, rtx i1, int
   /* Is the result of combination a valid instruction?  */
   insn_code_number = recog_for_combine (&newpat, i3, &new_i3_notes);

+  if (insn_code_number < 0)
+  changed_i3_dest = 0;
+
   /* If the result isn't valid, see if it is a PARALLEL of two SETs where
  the second SET's destination is a register that is unused and isn't
  marked as an instruction that might trap in an EH region.  In that case,

This patch fixes the bug.
Do you think if this patch is favorable? If yes, I will do dejagnu
test and send it to gcc-patches for review.

Thanks,
Jing


-- 


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

[Bug c/42717] ice: verify_ssa failed

[hjl dot tools at gmail dot com]

--- Comment #1 from hjl dot tools at gmail dot com  2010-01-13 01:17 ---
It is caused by revision 149199:

http://gcc.gnu.org/ml/gcc-cvs/2009-07/msg00076.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-01-13 01:17:47
   date||


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

[Bug fortran/40920] Derived type with BIND(C) - rejected as argument.

[kargl at gcc dot gnu dot org]

--- Comment #2 from kargl at gcc dot gnu dot org  2010-01-13 00:43 ---
A related issue has been reported here

http://groups.google.com/group/comp.lang.fortran/browse_frm/thread
/ddc211f2987326b8#

in particular the error message needs to be rewritten.

Error: Type 'resultat' at (1) is a parameter to the BIND(C)  procedure
'gsl_sf_lngamma_sgn_e_wrapper' but is not C interoperable because
derived type 'gsl_sf_result' is not C interoperable.

resultat is not a type, and it most definitely is not a parameter.

Possible wording

Error:  Argument 'resultat' at (1) to the BIND(C) procedure
'gsl_sf_lngamma_sgn_e_wrapper' is not ...


-- 


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

[Bug c++/42701] [4.5 Regression] ICE on error recovery

[manu at gcc dot gnu dot org]

--- Comment #5 from manu at gcc dot gnu dot org  2010-01-13 00:21 ---
The code warning:

155347  jason   user_args = args == NULL ? NULL : *args;
155347  jason   /* Under DR 147 A::A() is an invalid constructor call,
155347  jason  not a functional cast.  */
155347  jason   if (DECL_MAYBE_IN_CHARGE_CONSTRUCTOR_P (fn))
155347  jason {
155347  jason   if (! (complain & tf_error))
155347  jason   return error_mark_node;
155347  jason
155347  jason   permerror (input_location,
155347  jason"cannot call constructor %<%T::%D%> directly",
155347  jasonbasetype, name);
155347  jason   inform (input_location, "for a function-style cast,
remove the "
155347  jason "redundant %<::%D%>", name);
155347  jason   call = build_functional_cast (basetype,
build_tree_list_vec (user_args),
155347  jason   complain);
155347  jason   release_tree_vector (user_args);
155347  jason   return call;
155347  jason }

To avoid the spurious note, the code should use the idiom permerror() &&
inform(), since diagnostics functions that may be suppressed return false if
they don't print anything.


-- 


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

[Bug other/42715] [4.5 Regression] output_operand: invalid expression as operand

[hjl dot tools at gmail dot com]

--- Comment #2 from hjl dot tools at gmail dot com  2010-01-12 23:34 ---
This is caused by revision 151917:

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


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-01-12 23:34:54
   date||


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

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

[paolo dot carlini at oracle dot com]

--- Comment #6 from paolo dot carlini at oracle dot com  2010-01-12 23:33 
---
Since we are talking of etiquette, and with the obvious caveats that my mother
language is italian + all the caveats about metaphorical uses of language, I
would also suggest keeping to a minimum the uses of "pissing" ;)


-- 


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

[Bug c/42708] [4.5 Regression] ICE in gimplify_expr, at gimplify.c:6993

[jsm28 at gcc dot gnu dot org]

--- Comment #5 from jsm28 at gcc dot gnu dot org  2010-01-12 23:10 ---
Fixed for 4.5.


-- 

jsm28 at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||4.5.0
 Resolution||FIXED


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

[Bug c/42708] [4.5 Regression] ICE in gimplify_expr, at gimplify.c:6993

[jsm28 at gcc dot gnu dot org]

--- Comment #4 from jsm28 at gcc dot gnu dot org  2010-01-12 23:09 ---
Subject: Bug 42708

Author: jsm28
Date: Tue Jan 12 23:09:00 2010
New Revision: 155846

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155846
Log:
PR c/42708
* c-typeck.c (build_c_cast): Fold value cast to union type before
wrapping it in a CONSTRUCTOR.

testsuite:
* gcc.c-torture/compile/pr42708-1.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr42708-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-typeck.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug lto/42532] configuring with --enable-gold introduces many fails in the testsuite

[doko at ubuntu dot com]

--- Comment #4 from doko at ubuntu dot com  2010-01-12 23:04 ---
verified with binutils/gcc builds from 20100112 trunks


-- 


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

[Bug tree-optimization/42719] "-fcompare-debug failure" with "-O2 -ftracer"

[zsojka at seznam dot cz]

--- Comment #1 from zsojka at seznam dot cz  2010-01-12 22:24 ---
Created an attachment (id=19567)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19567&action=view)
reduced testcase

reduced from gcc/cfgexpand.c

Command line:
gcc -O2 -ftracer -fcompare-debug -c pr42719.c
or
gcc -O1 -ftree-pre -freorder-blocks -ftracer -fcompare-debug -c pr42719.c


-- 


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

[Bug tree-optimization/42719] New: "-fcompare-debug failure" with "-O2 -ftracer"

[zsojka at seznam dot cz]

Command line:
gcc -O2 -ftracer -fcompare-debug -c testcase.c
or
gcc -O1 -ftree-pre -freorder-blocks -ftracer -fcompare-debug -c testcase.c

Tested revisions:
r155833 - crash
r155777 - crash
r154830 - crash
r153685 - crash

Output:
$ /mnt/svn/gcc-trunk/binary-155777-lto/bin/gcc -O2 -ftracer -fcompare-debug -c
testcase.c
gcc: testcase.c: -fcompare-debug failure


-- 
   Summary: "-fcompare-debug failure" with "-O2 -ftracer"
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zsojka at seznam dot cz
  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=42719

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

[jingyu at google dot com]

--- Comment #5 from jingyu at google dot com  2010-01-12 22:21 ---
Subject: Re:  problematic REG_EQUAL note added to 
SUBREG

On Tue, Jan 12, 2010 at 12:57 AM, ebotcazou at gcc dot gnu dot org
 wrote:
>
>
> --- Comment #4 from ebotcazou at gcc dot gnu dot org  2010-01-12 08:57 
> ---
>> 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);
>>     }
>
> We should try and set changed_i3_dest to 1 in this particular case as well.
>
> Where does the dest get changed exactly?
>

In our example, GCC first sets the new pattern to "newpat". "newpat"
actually points to the pattern of i2.
At line3750, gcc records i3's note into "i3notes" and propagates the
note if shared.
Then at line3775, gcc assigns newpat to i3.
At line3775 (combine.c):
INSN_CODE (i3) = insn_code_number;
PATTERN (i3) = newpat;
At line3837,  REG_NOTES (i3) = 0;
At line3879, "i3notes" is distributed back to i3.


>> 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;
>
> Too big a hammer, the dest of I3 is generally not changed.


>
>> Another option to fix this problem is not to attach REG_EQUAL note to
>> "set subreg reg" at all during forward propagation.
>
> Too big a hammer as well, the note is correct at this point.
>
>
> --
>
>
> 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 c++/40239] Aggregate initialization requires copy constructor

[bangerth at gmail dot com]

--- Comment #5 from bangerth at gmail dot com  2010-01-12 21:52 ---
(In reply to comment #4)
> I will stop adding the 'Contributed by' line from now, and will remove
> it from this patch. If you want, I can remove it from all the test cases
> I did commit.

I don't think that's necessary, I just meant to point this out. No worries.


> Thank you. Though, in all fairness, I think those thanks should be
> directed to my employer who allows me to work on those PRs.

I'm willing to extend my thanks to your employer while leaving them with you
as well :-)

W.


-- 


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

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

[dodji at seketeli dot org]

--- Comment #4 from dodji at seketeli dot org  2010-01-12 21:49 ---
Subject: Re:  Aggregate initialization requires copy
 constructor

Le mar. 12 janv. 2010 à 20:58:01 (-), bangerth at gmail dot com a écrit:
> As a matter of etiquette (I think we've had
> this conversation with others in the past already): in your patch,
> you mark the testcase as "Contributed by Dodji Seketeli", but in
> fact the testcase is identically the one posted by the reporter of
> this PR. It seems unfair that you take credit for it when it's really
> by someone else.

Oh, sorry. I didn't mean to piss people off. I thought that mentionning
the 'Origin' of the PR was the canonical way of designating where the test
case did come from, and the 'Contributed by 'would only designate the
person who committed the test case.

I will stop adding the 'Contributed by' line from now, and will remove
it from this patch. If you want, I can remove it from all the test cases
I did commit.

Sorry again.

> That said, I think all of us C++ users really appreciate the number of
> PRs you've taken care of recently!

Thank you. Though, in all fairness, I think those thanks should be
directed to my employer who allows me to work on those PRs.


-- 


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

[Bug middle-end/42718] New: FAIL: gcc.c-torture/compile/pr42559.c at -O1 and above

[danglin at gcc dot gnu dot org]

Executing on host: /mnt/gnu/gcc/objdir/gcc/xgcc -B/mnt/gnu/gcc/objdir/gcc/  
-O1
  -w -c  -o pr42559.o
/mnt/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/pr425
59.c(timeout = 300)
/mnt/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/pr42559.c: In function
'jum
pfunc':
/mnt/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/pr42559.c:5: internal
compi
ler error: Arithmetic exception

Program received signal SIGFPE, Arithmetic exception.
0x00031080 in small_divisor ()
(gdb) bt
#0  0x00031080 in small_divisor ()
#1  0x00a3410c in gen_movmemsi (operand0=0x7afaee50, operand1=0x7afaee60,
operand2=0x7af33550, operand3=0x7af332b8)
at ../../gcc/gcc/config/pa/pa.md:3554
#2  0x0038bbcc in emit_block_move_via_movmem (x=0x7afaee50, y=0x7afaee60,
size=0x7af33550, align=1, expected_align=8, expected_size=-1)
at ../../gcc/gcc/expr.c:1360
#3  0x0038b768 in emit_block_move_hints (x=0x7afaee50, y=0x7afaee60,
size=0x7af33550, method=BLOCK_OP_NORMAL, expected_align=8,
expected_size=-1) at ../../gcc/gcc/expr.c:1233
...

Problem is alignment.

I believe that this was fixed on trunk by the following change:

2009-12-17  Richard Guenther  

PR middle-end/42397
* builtins.c (get_object_alignment): Properly deal with
a CONST_DECL base.
* expr.c (emit_block_move_hints): Assert the alignment makes sense.


-- 
   Summary: FAIL: gcc.c-torture/compile/pr42559.c at -O1 and above
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
 GCC build triplet: hppa2.0w-hp-hpux11.11
  GCC host triplet: hppa2.0w-hp-hpux11.11
GCC target triplet: hppa2.0w-hp-hpux11.11


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

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

[jjcogliati-r1 at yahoo dot com]

--- Comment #12 from jjcogliati-r1 at yahoo dot com  2010-01-12 21:14 
---
(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 ...
> 
> > 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.
> 

That did the trick.  Thank you.  

Added lto-streamer-out.c:lto_output_ts_type_tree_pointers:
  else if (TREE_CODE (expr) == ARRAY_TYPE) {
+gcc_assert(TYPE_MAX_VALUE (TYPE_DOMAIN (expr) ) == NULL || 
+  TREE_CODE (TYPE_MAX_VALUE (TYPE_DOMAIN (expr) )) != ERROR_MARK
);
lto_output_tree_or_ref (ob, TYPE_DOMAIN (expr), ref_p);
  }


I can now trigger the original ice with the following valid (I think) code:
!list_use.f90
program list_use
  use list_test
  implicit none

  integer, dimension(10) :: a_list

  a_list = 1
  call loop_list(a_list)
end program list_use

!list_test.f90
module list_test
  !$ use omp_lib
  implicit none

contains

  subroutine loop_list(list)
integer, intent(in), dimension(:) :: list
integer :: ii
!$ integer :: chunk_size
!$ chunk_size = 4
!$OMP PARALLEL DO SCHEDULE(dynamic,chunk_size)
do ii=1,size(list)
   call do_things(list, ii)
end do

  end subroutine loop_list

  subroutine do_things(list, index)
integer, intent(in),dimension(:) :: list
integer, intent(in) :: index
print *,size(list),index
  end subroutine do_things

end module list_test



$ ~/gcc/old4_gcc45/bin/gfortran -Wall -o list_use -fopenmp -fwhole-program
-flto  list_test.f90 list_use.f90
lto1: internal compiler error: in iterative_hash_expr, at tree.c:6592
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper: /home/jjc/gcc/old4_gcc45/bin/gfortran returned 1 exit status
collect2: lto-wrapper returned 1 exit status


-- 


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

[Bug tree-optimization/42703] [4.5 Regression] ICE in generate_subtree_copies with out of bounds array access

[jamborm at gcc dot gnu dot org]

--- Comment #5 from jamborm at gcc dot gnu dot org  2010-01-12 21:05 ---
I would say that the dd.c[4] access into an array that is four chars
long has undefined behavior.  It is also the reason why
build_ref_for_offset cannot find a suitable array element for it,
because there is none.

Because we should not ICE anyway I guess I'll resort to pro-actively
checking that we can create an access to the original piece of the
aggregate when deciding what replacements to create.  (That is a bit
pity as the asserts nicely checked that the function worked in the
cases when it really should.)

Another option (as Andrew has just suggested on IRC) would be to turn
such things into __builtin_trap().  That would teach them not to write
code like this, .


-- 

jamborm at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jamborm at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2010-01-12 14:13:18 |2010-01-12 21:05:19
   date||


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

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

[bangerth at gmail dot com]

--- Comment #3 from bangerth at gmail dot com  2010-01-12 20:58 ---
Dodji,
thanks for the patch. As a matter of etiquette (I think we've had
this conversation with others in the past already): in your patch,
you mark the testcase as "Contributed by Dodji Seketeli", but in
fact the testcase is identically the one posted by the reporter of
this PR. It seems unfair that you take credit for it when it's really
by someone else.

That said, I think all of us C++ users really appreciate the number of
PRs you've taken care of recently!

Cheers
 W.


-- 


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

[Bug tree-optimization/42703] [4.5 Regression] ICE in generate_subtree_copies with out of bounds array access

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2010-01-12 20:48 ---
This code is undefined because out of bounds access of the array.  Also note
the use of the union is not needed here really as char is a character type
which means it can be used to access the ScmUInt64 without any aliasing issues.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
Summary|[4.5 Regression] ICE in |[4.5 Regression] ICE in
   |generate_subtree_copies, at |generate_subtree_copies with
   |tree-sra.c:2003 |out of bounds array access


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

[Bug rtl-optimization/42699] [4.3/4.4/4.5 Regression] ZERO_EXTRACT on lhs never optimized out

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2010-01-12 20:25 ---
Subject: Bug 42699

Author: jakub
Date: Tue Jan 12 20:25:10 2010
New Revision: 155844

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155844
Log:
PR rtl-optimization/42699
* cse.c (cse_insn): Optimize lhs ZERO_EXTRACT if only CONST_INTs are
involved.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/cse.c


-- 


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

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

[jason at redhat dot com]

--- Comment #18 from jason at redhat dot com  2010-01-12 19:45 ---
Subject: Re:  [4.5 Regression] ICE with pointer-to-member-function
 argument in template function

On 01/10/2010 06:42 PM, hubicka at gcc dot gnu dot org wrote:
> In general I am not sure plan of doing all
> datastructure/function call conventions changes via cloning is coolest idea.

Well, just pretending that a particular parameter never existed isn't 
acceptable from a debugging standpoint; I think we need to have a 
separate modified decl which points back to the original unmodified decl 
with DECL_ABSTRACT_ORIGIN.

Beyond that, it might be possible to avoid much copying by just moving 
the function body over from the original decl to the modified one.

Jason


-- 


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

[Bug fortran/42664] ICE on compilation of polyhedron benchmarks with -mfma4

[ubizjak at gmail dot com]

--- Comment #8 from ubizjak at gmail dot com  2010-01-12 19:04 ---
(In reply to comment #7)
> Ok to check in?

No, please follow usual procedure for submitting patches and post the patch to
gcc-patches@ first.


-- 


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

[Bug tree-optimization/42685] [4.5 Regression] "-fcompare-debug failure" with "-O1 -funroll-loops" (2)

[zsojka at seznam dot cz]

--- Comment #3 from zsojka at seznam dot cz  2010-01-12 18:08 ---
Created an attachment (id=19566)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19566&action=view)
different reduced testcase

I don't know if it's the same problem, but fails with the same flags.

$ gcc -O1 -fcompare-debug -funroll-loops -c pr42685-2.c
gcc: pr42685-2.c: -fcompare-debug failure


-- 


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

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

[paolo dot carlini at oracle dot com]

--- Comment #22 from paolo dot carlini at oracle dot com  2010-01-12 18:07 
---
Interesting... lately people (*) are apparently happy with all sorts of
regressions wrt C++98/TR1...

Anyway, then let's close it, actually I leave to you the choice between fixed,
wontfix and invalid ;)

(*) Stephan at least is also happy with std::vector & co not explicitly
instantiable anymore for non-DefaultConstructible types: if I remember all the
time I spent with Matt Austern encouragement to tweak all our containers for
that... Agreed, the new philosophy of adding requirements to the specific
members allows more flexibility together with non-moveable types, etc, but in
my opinion it really makes sense only together with Concepts where you can
elegantly make a member "disappear" depending on a Require clause... bah...


-- 


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

[Bug c/42717] New: ice: verify_ssa failed

[regehr at cs dot utah dot edu]

Seen on Ubuntu 9.10.

reg...@john-home:~/volatile/bugs/tmp253$ current-gcc -O2 small.c
small.c: In function ‘bar’:
small.c:16:1: error: definition in block 7 does not dominate use in block 2
for SSA_NAME: l_23_17 in statement:
l_23_2 = PHI 
PHI argument
l_23_17
for PHI node
l_23_2 = PHI 
small.c:16:1: internal compiler error: verify_ssa failed
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

reg...@john-home:~/volatile/bugs/tmp253$ current-gcc -v

Using built-in specs.
COLLECT_GCC=current-gcc
COLLECT_LTO_WRAPPER=/home/regehr/z/tmp/gcc-r155838-install/libexec/gcc/i686-pc-linux-gnu/4.5.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../configure --with-libelf=/usr/local --enable-lto
--prefix=/home/regehr/z/tmp/gcc-r155838-install --program-prefix=r155838-
--enable-languages=c,c++
Thread model: posix
gcc version 4.5.0 20100112 (experimental) (GCC) 

reg...@john-home:~/volatile/bugs/tmp253$ cat small.c

static signed char
foo (signed char si1, unsigned char si2)
{
  return (si1 ^ si2) & (-si2 ^ si2) ? : si1 - si2;
}

struct S0
{
};

unsigned char g_21;

struct S0 g_34;

void
bar (unsigned char p_20)
{
  unsigned char *l_22 = &g_21;
  unsigned char l_23 = 0;
  struct S0 *l = &g_34;
  goto lbl_42;
  for (; l_23; l_23 = foo (l_23, 1))
{
  for (p_20 = 0; 0; p_20 = foo (p_20, 1))
  lbl_42:;
  (l == &g_34) ? 0 : "";
lbl_85:*l_22 = p_20;
}
  goto lbl_85;
}


-- 
   Summary: ice: verify_ssa failed
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: regehr at cs dot utah dot edu
 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=42717

[Bug c/42716] New: ICE in extract_range_from_assert, at tree-vrp.c:1423

[regehr at cs dot utah dot edu]

reg...@john-home:~/volatile/bugs/tmp252$ current-gcc -O2 -c small.c
small.c: In function ‘bar’:
small.c:12:6: internal compiler error: in extract_range_from_assert, at
tree-vrp.c:1423
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

reg...@john-home:~/volatile/bugs/tmp252$ current-gcc -v

Using built-in specs.
COLLECT_GCC=current-gcc
COLLECT_LTO_WRAPPER=/home/regehr/z/tmp/gcc-r155838-install/libexec/gcc/i686-pc-linux-gnu/4.5.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../configure --with-libelf=/usr/local --enable-lto
--prefix=/home/regehr/z/tmp/gcc-r155838-install --program-prefix=r155838-
--enable-languages=c,c++
Thread model: posix
gcc version 4.5.0 20100112 (experimental) (GCC) 

reg...@john-home:~/volatile/bugs/tmp252$ cat small.c

static short foo (long long si1, short si2)
{
  return si1 > 0 && si2 > 0 && si1 > 9223372036854775807LL - si2 || si1 < 0
&& si2 < 0 && si1 < 1 - si2 ? : si1 + si2;
}

int g_13;
unsigned g_17;

int safe (int, int);

void bar (short p_51, short * p_52)
{
  int *const l_55 = &g_13;
  if (safe (*p_52, g_13 != foo (*p_52 & *l_55 == g_13 && g_17 >= 1, 0)))
{
}
}


-- 
   Summary: ICE in extract_range_from_assert, at tree-vrp.c:1423
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: regehr at cs dot utah dot edu
 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=42716

[Bug libstdc++/42712] search_n/iterator.cc times out in parallel-mode

[paolo dot carlini at oracle dot com]

--- Comment #2 from paolo dot carlini at oracle dot com  2010-01-12 18:00 
---
My impression is that for some reason it's just slow, very slow: with
TEST_DEPTH=10 it completes in a decent amount of time...


-- 


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

[Bug libstdc++/42624] libstdc++ parallel mode deadlocks in barrier

[edwintorok at gmail dot com]

--- Comment #13 from edwintorok at gmail dot com  2010-01-12 17:54 ---
(In reply to comment #12)
> Thread 1 waits for its colleagues, but where are they gone?  Is it possible
> that an exception is thrown inside find (by means of the value type or the
> predicate)?
> I don't fully trust gdb in this case, but it shows that an iterator range of
> (NULL, NULL) had to be searched.
> 

This code is compiled with -fno-exceptions, could that be a problem?


-- 


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

[Bug libstdc++/42712] search_n/iterator.cc times out in parallel-mode

[singler at kit dot edu]

--- Comment #1 from singler at kit dot edu  2010-01-12 17:43 ---
Maybe rather an endless loop.


-- 

singler at kit dot edu changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |singler at kit dot edu
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-01-12 17:43:17
   date||


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

[Bug libstdc++/42624] libstdc++ parallel mode deadlocks in barrier

[singler at kit dot edu]

--- Comment #12 from singler at kit dot edu  2010-01-12 17:42 ---
Thread 1 waits for its colleagues, but where are they gone?  Is it possible
that an exception is thrown inside find (by means of the value type or the
predicate)?
I don't fully trust gdb in this case, but it shows that an iterator range of
(NULL, NULL) had to be searched.


-- 


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

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

[jwakely dot gcc at gmail dot com]

--- Comment #21 from jwakely dot gcc at gmail dot com  2010-01-12 17:19 
---
(In reply to comment #20)
> I'd like only to make sure we don't
> forget about the issue with pointers to member functions: is there a DR open
> already? 

It's been raised on the lib reflector byme, Stephan T. Lavavej and Alisdair
Meredith.  I'm not sufficiently motivated to open an issue for it, there are
workarounds using mem_fn.

The proposed resolution for LWG 1225 reinforces my interpretation that
result_of does not support pointers-to-members.

> Maybe we could also find a way to mention it in the code, if you
> haven't done that already, didn't check.

No, I didn't mention it in the code.


-- 


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

[Bug libgcj/40859] [4.4 regression] regressions in libjava testsuite on arm-linux

[doko at gcc dot gnu dot org]

--- Comment #3 from doko at gcc dot gnu dot org  2010-01-12 17:14 ---
Subject: Bug 40859

Author: doko
Date: Tue Jan 12 17:14:15 2010
New Revision: 155840

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155840
Log:
2010-01-12  Matthias Klose  

PR libjava/40859, backported from:

2009-08-12  Andrew Haley  
* configure.host (arm*-linux*): Add -Wno-abi to cxxflags.
(testsuite/libjava.jvmti/jvmti-interp.exp): Likewise.
(testsuite/libjava.jvmti/jvmti.exp): Likewise.
(testsuite/libjava.jni/jni.exp): Likewise.

Modified:
branches/gcc-4_4-branch/libjava/ChangeLog
branches/gcc-4_4-branch/libjava/configure.host
branches/gcc-4_4-branch/libjava/testsuite/libjava.jni/jni.exp
branches/gcc-4_4-branch/libjava/testsuite/libjava.jvmti/jvmti-interp.exp
branches/gcc-4_4-branch/libjava/testsuite/libjava.jvmti/jvmti.exp


-- 


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

[Bug other/42715] [4.5 Regression] output_operand: invalid expression as operand

[doko at ubuntu dot com]

--- Comment #1 from doko at ubuntu dot com  2010-01-12 17:07 ---
Created an attachment (id=19565)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19565&action=view)
preprocessed source


-- 


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

[Bug other/42715] New: [4.5 Regression] output_operand: invalid expression as operand

[doko at ubuntu dot com]

seen with 20100107 on x86_64-linux-gnu with a biarch compiler:

works without -fPIC or with -O1

$ gcc -m32 -c -g -O2 -fPIC stabs.i 
../../../dlls/dbghelp/stabs.c:1533:1: internal compiler error: output_operand:
invalid expression as operand
Please submit a full bug report,
with preprocessed source if appropriate.


-- 
   Summary: [4.5 Regression] output_operand: invalid expression as
operand
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: doko at ubuntu dot com


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

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

[jakub at gcc dot gnu dot org]

--- Comment #13 from jakub at gcc dot gnu dot org  2010-01-12 17:00 ---
Created an attachment (id=19564)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19564&action=view)
gcc45-pr41371.patch

Patch that speeds up the qmc2main.ii testcase to bearable compile time (2m20s
on my box with -g -O2).  With -g0 -O2 it compiles in 45s, so var-tracking still
dominates the time, but it is no longer so slow.
I'll bootstrap/regtest it now.


-- 

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


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

[Bug tree-optimization/42707] [4.5 Regression] ICE - segfault in mark_operand_necessary

[doko at ubuntu dot com]

--- Comment #3 from doko at ubuntu dot com  2010-01-12 16:50 ---
configured with --enable-checking=release


-- 


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

[Bug tree-optimization/42714] [4.5 Regression] ICE in create_tmp_var, at gimplify.c:504

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2010-01-12 16:48 ---
Created an attachment (id=19563)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19563&action=view)
testcase

Reducing.


-- 


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

[Bug other/42713] [4.5 Regression] ICE - segfault in tsubst

[doko at ubuntu dot com]

--- Comment #1 from doko at ubuntu dot com  2010-01-12 16:47 ---
Created an attachment (id=19562)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19562&action=view)
preprocessed source


-- 


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

[Bug tree-optimization/42714] New: [4.5 Regression] ICE in create_tmp_var, at gimplify.c:504

[rguenth at gcc dot gnu dot org]

early IPA SRA runs into

> ./cc1plus -quiet x_20.ii -O2
/usr/src/packages/BUILD/kdebindings-4.3.90/build/smoke/qt/x_20.cpp: In function
'__smokeqt::x_QXmlStreamAttributes::x_QXmlStreamAttributes(QVectorData**)':
/usr/src/packages/BUILD/kdebindings-4.3.90/build/smoke/qt/x_20.cpp:2974:62:
internal compiler error: in create_tmp_var, at gimplify.c:504
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: [4.5 Regression] ICE in create_tmp_var, at
gimplify.c:504
   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: rguenth at gcc dot gnu dot org


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

[Bug other/42713] New: [4.5 Regression] ICE - segfault in tsubst

[doko at ubuntu dot com]

seen with trunk 20100112:

$ g++ -c ../DemonsRegistration.ii 
In file included from
/scratch/packages/tmp/rebuild/slicer-3.4.0~svn10438/Applications/CLI/DiffeomorphicDemonsRegistration/itkGridForwardWarpImageFilter.h:120:0,
 from
/scratch/packages/tmp/rebuild/slicer-3.4.0~svn10438/Applications/CLI/DiffeomorphicDemonsRegistration/DemonsRegistration.cxx:48:
/scratch/packages/tmp/rebuild/slicer-3.4.0~svn10438/Applications/CLI/DiffeomorphicDemonsRegistration/itkGridForwardWarpImageFilter.txx:
In constructor 'itk::GridForwardWarpImageFilter::GridForwardWarpImageFilter() [with TDeformationField =
itk::Image, 3u>, TOutputImage = itk::Image]':
/scratch/packages/tmp/rebuild/slicer-3.4.0~svn10438/Applications/CLI/DiffeomorphicDemonsRegistration/itkGridForwardWarpImageFilter.h:49:125:
  instantiated from 'static itk::GridForwardWarpImageFilter::Pointer itk::GridForwardWarpImageFilter::New() [with TDeformationField = itk::Image,
3u>, TOutputImage = itk::Image,
itk::GridForwardWarpImageFilter::Pointer =
itk::SmartPointer,
3u>, itk::Image > >]'
/scratch/packages/tmp/rebuild/slicer-3.4.0~svn10438/Applications/CLI/DiffeomorphicDemonsRegistration/DemonsRegistration.cxx:871:85:
  instantiated from 'void::DoDemonsRegistration(::arguments)
[with unsigned int Dimension = 3u]'
/scratch/packages/tmp/rebuild/slicer-3.4.0~svn10438/Applications/CLI/DiffeomorphicDemonsRegistration/DemonsRegistration.cxx:1018:35:
  instantiated from here
/scratch/packages/tmp/rebuild/slicer-3.4.0~svn10438/Applications/CLI/DiffeomorphicDemonsRegistration/itkGridForwardWarpImageFilter.txx:23:3:
internal compiler error: Segmentation fault
Please submit a full bug report,


Program received signal SIGSEGV, Segmentation fault.
0x004d040b in tsubst (t=0x7fffee844bd0, args=0x7fffea07e210,
complain=3, in_decl=0x7fffee347ac8) at ../../src/gcc/cp/pt.c:9870
9870if (arg && TREE_CODE (arg) == ARGUMENT_PACK_SELECT)
(gdb) p arg
$1 = (tree) 0x3
(gdb) bt
#0  0x004d040b in tsubst (t=0x7fffee844bd0, args=0x7fffea07e210,
complain=3, in_decl=0x7fffee347ac8) at ../../src/gcc/cp/pt.c:9870
#1  0x004d3fdb in tsubst_template_args (t=,
args=, complain=, 
in_decl=) at ../../src/gcc/cp/pt.c:8377
#2  0x004d0de1 in tsubst (t=0x7fffee84de70, args=0x7fffea07e210,
complain=3, in_decl=0x7fffee347ac8) at ../../src/gcc/cp/pt.c:9732
#3  0x004d046f in tsubst (t=0x7fffee84f498, args=0x7fffea07e210,
complain=3, in_decl=0x7fffee347ac8) at ../../src/gcc/cp/pt.c:10265
#4  0x004d3fdb in tsubst_template_args (t=,
args=, complain=, 
in_decl=) at ../../src/gcc/cp/pt.c:8377
#5  0x004dab8b in tsubst_aggr_type (t=0x7fffee8bd888,
args=0x7fffea07e210, complain=3, in_decl=0x7fffee347ac8, entering_scope=0)
at ../../src/gcc/cp/pt.c:8543
#6  0x004d4373 in tsubst_qualified_id (qualified_id=0x7fffee37ba80,
args=0x7fffea07e210, complain=3, in_decl=, 
done=, address_p=) at
../../src/gcc/cp/pt.c:10550
#7  0x004d2241 in tsubst_copy_and_build (t=0x7fffee37ba80,
args=0x7fffea07e210, complain=3, in_decl=0x7fffee347ac8, function_p=0 '\000', 
integral_constant_expression_p=0 '\000') at ../../src/gcc/cp/pt.c:12001
#8  0x004d234e in tsubst_copy_and_build (t=0x7fffee390040,
args=0x7fffea07e210, complain=3, in_decl=0x7fffee347ac8, function_p=0 '\000', 
integral_constant_expression_p=) at
../../src/gcc/cp/pt.c:12045
#9  0x004cd891 in tsubst_expr (t=0x7fffee390040, args=, complain=3, in_decl=0x7fffee347ac8, 
integral_constant_expression_p=) at
../../src/gcc/cp/pt.c:11747
#10 0x004ce2b2 in tsubst_expr (t=0x7fffee38c930, args=, complain=3, in_decl=0x7fffee347ac8, 
integral_constant_expression_p=) at
../../src/gcc/cp/pt.c:11346
#11 0x004ce215 in tsubst_expr (t=, args=, complain=3, in_decl=0x7fffee347ac8, 
integral_constant_expression_p=) at
../../src/gcc/cp/pt.c:11332
#12 0x004cd904 in tsubst_expr (t=0x7fffee37cac0, args=, complain=3, in_decl=0x7fffee347ac8, 
integral_constant_expression_p=) at
../../src/gcc/cp/pt.c:11488
#13 0x004ce215 in tsubst_expr (t=, args=, complain=3, in_decl=0x7fffee347ac8, 
integral_constant_expression_p=) at
../../src/gcc/cp/pt.c:11332
#14 0x004cd904 in tsubst_expr (t=0x7fffee528f40, args=, complain=3, in_decl=0x7fffee347ac8, 
integral_constant_expression_p=) at
../../src/gcc/cp/pt.c:11488
#15 0x004dbe0f in instantiate_decl (d=,
defer_ok=, expl_inst_class_mem_p=)
at ../../src/gcc/cp/pt.c:16640
#16 0x004df064 in instantiate_pending_templates (retries=) at ../../src/gcc/cp/pt.c:16737
#17 0x004f2d15 in cp_write_global_declarations () at
../../src/gcc/cp/decl2.c:3511
#18 0x0079f3a6 in compile_file (argc=12, argv=0x7fffe5f8) at
../../src/gcc/toplev.c:1065
#19 do_compile (argc=12, argv=0x7fffe5f8) at ../../src/gcc/toplev.c:2405
#20 toplev_main (argc=12, argv=0x7fffe5f8)

[Bug tree-optimization/42704] [4.5 Regression] ICE in verify_ssa after early SRA

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2010-01-12 16:43 ---
*** Bug 42707 has been marked as a duplicate of this bug. ***


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||doko at ubuntu dot com


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

[Bug tree-optimization/42707] [4.5 Regression] ICE - segfault in mark_operand_necessary

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-01-12 16:43 ---
Looks like PR42704 which is what I reproduce with the testcase in this
bug as well.  I guess you built 4.5 w/o checking.

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


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug debug/42710] [4.5 Regression] ICE in first_imm_use_stmt, at tree-flow-inline.h:1081

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2010-01-12 16:40 ---
Seems to work on current trunk (fixed between revs 155679 (failing) and
155834 (ok)).


-- 


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

[Bug debug/42710] [4.5 Regression] ICE in first_imm_use_stmt, at tree-flow-inline.h:1081

[rguenth at gcc dot gnu dot org]

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


-- 


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

[Bug libstdc++/42712] New: search_n/iterator.cc times out in parallel-mode

[paolo dot carlini at oracle dot com]

I'm consistently seeing this time out when regtesting make check-parallel. Is
it unavoidable withing the current infrastructure? Besides slowing down the
testing itself (not a very big issue, momentarily, I will commit an hack for
this), seems a quite puzzling behavior to me: if parallel-mode runs orders of
magnitude slower than serial-mode, shouldn't in principle at minimum fall back
to the latter?


-- 
   Summary: search_n/iterator.cc times out in parallel-mode
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: paolo dot carlini at oracle dot com


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

[Bug debug/42710] [4.5 Regression] ICE in first_imm_use_stmt, at tree-flow-inline.h:1081

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-01-12 16:30 ---
Also works without -g.  Reducing.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu dot
   ||org
  Component|other   |debug
   Target Milestone|--- |4.5.0


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

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

[espindola at gcc dot gnu dot org]

--- Comment #2 from espindola at gcc dot gnu dot org  2010-01-12 16:29 
---
Is the undefined reference to libgcc? Is it being linked statically? When
linking libgcc statically the driver has to pass
-plugin-opt=-pass-through=/foo/bar/libgcc.a to ld. This is done in gcc.c:

%{static|static-libgcc:-plugin-opt=-pass-through=%(lto_libgcc)} \
%{static:-plugin-opt=-pass-through=-lc} \

So, is there a better way to detect that we are linking libgcc statically?


-- 


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

[Bug fortran/42664] ICE on compilation of polyhedron benchmarks with -mfma4

[harsha dot jagasia at amd dot com]

--- Comment #7 from harsha dot jagasia at amd dot com  2010-01-12 16:26 
---
Ok to check in?


-- 


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

[Bug fortran/42664] ICE on compilation of polyhedron benchmarks with -mfma4

[harsha dot jagasia at amd dot com]

--- Comment #6 from harsha dot jagasia at amd dot com  2010-01-12 16:24 
---
Bootstrap and target tests pass with the new patch. Compilation of all
polyhedron benchmarks also passes.


-- 


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

[Bug c/11751] wrong evaluation order of an expression

[schwab at linux-m68k dot org]

--- Comment #86 from schwab at linux-m68k dot org  2010-01-12 16:24 ---
*** Bug 42711 has been marked as a duplicate of this bug. ***


-- 

schwab at linux-m68k dot org changed:

   What|Removed |Added

 CC||aonebeam at gmail dot com


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

[Bug c/42711] the increment(++) or decrement(--) operators is wrong for short index of array

[schwab at linux-m68k dot org]

--- Comment #2 from schwab at linux-m68k dot org  2010-01-12 16:24 ---


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


-- 

schwab at linux-m68k dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE
Summary|the increment(++) or|the increment(++) or
   |decrement(--) operators is  |decrement(--) operators is
   |wrong for short index of|wrong for short index of
   |array   |array


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

[Bug other/42710] [4.5 Regression] ICE in first_imm_use_stmt, at tree-flow-inline.h:1081

[doko at ubuntu dot com]

--- Comment #1 from doko at ubuntu dot com  2010-01-12 16:24 ---
Created an attachment (id=19560)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19560&action=view)
preprocessed source


-- 


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

[Bug c++/42569] [4.5 Regression] ICE in cp_parser_parenthesized_expression_list at cp/parser.c

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2010-01-12 16:23 ---
Confirmed for the unreduced testcase.

> ./cc1plus -quiet gstagev2mux.ii  -fpermissive
gstapev2mux.cc: In function 'void add_one_tag(const GstTagList*, const gchar*,
void*)':
gstapev2mux.cc:118:62: warning: cannot call constructor
'TagLib::String::String' directly
gstapev2mux.cc:118:62: note: for a function-style cast, remove the redundant
'::String'
gstapev2mux.cc:127:62: warning: cannot call constructor
'TagLib::String::String' directly
gstapev2mux.cc:127:62: note: for a function-style cast, remove the redundant
'::String'
gstapev2mux.cc:127:62: error: no matching function for call to
'TagLib::String::String(char*&, TagLib::String::Type, char*&,
TagLib::String::Type)'
/usr/include/taglib/tstring.h:164:5: note: candidates are:
TagLib::String::String(const TagLib::ByteVector&, TagLib::String::Type)
/usr/include/taglib/tstring.h:156:5: note:
TagLib::String::String(const char*, TagLib::String::Type)
/usr/include/taglib/tstring.h:147:5: note:
TagLib::String::String(wchar_t, TagLib::String::Type)
/usr/include/taglib/tstring.h:142:5: note:
TagLib::String::String(char, TagLib::String::Type)
/usr/include/taglib/tstring.h:134:5: note:
TagLib::String::Strig(const wchar_t*, TagLib::String::Type)
/usr/include/taglib/tstring.h:129:5: note:
TagLib::String::String(const TagLib::wstring&, TagLib::String::Type)
/usr/include/taglib/tstring.h:124:5: note:
TagLib::String::String(const std::string&, TagLib::String::Type)
/usr/include/taglib/tstring.h:116:5: note:
TagLib::String::String(const TagLib::String&)
/usr/include/taglib/tstring.h:109:5: note:
TagLib::String::String()
gstapev2mux.cc:136:44: internal compiler error: vector VEC(tree,base) push
domain error, in cp_parser_parenthesized_expression_list at cp/parser.c:5326
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  Known to work||4.4.2
   Last reconfirmed|-00-00 00:00:00 |2010-01-12 16:23:20
   date||
Summary|ICE in  |[4.5 Regression] ICE in
   |cp_parser_parenthesized_expr|cp_parser_parenthesized_expr
   |ession_list at cp/parser.c  |ession_list at cp/parser.c
   Target Milestone|--- |4.5.0


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

[Bug c/42711] the increment(++) or decrement(--) operators is wrong for short index of array

[aonebeam at gmail dot com]

--- Comment #1 from aonebeam at gmail dot com  2010-01-12 16:14 ---
Created an attachment (id=19559)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19559&action=view)
The source of wrong result of decrement, increment is the same

The result is wrong.


-- 


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

[Bug tree-optimization/42709] [4.5 Regression] error: type mismatch in pointer plus expression

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2010-01-12 16:12 ---
Confirmed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
 GCC target triplet||x86-64-*-*
  Known to work||4.4.2
   Last reconfirmed|-00-00 00:00:00 |2010-01-12 16:12:10
   date||
   Target Milestone|--- |4.5.0


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

[Bug tree-optimization/42709] [4.5 Regression] error: type mismatch in pointer plus expression

[rguenth at gcc dot gnu dot org]

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


-- 


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

[Bug c/42711] New: the increment(++) or decrement(--) operators is wrong for short index of array

[aonebeam at gmail dot com]

The following tests are made on solaris 5.10 platform.
This is the example of the decrement(--) for short index of array:
/*/
#include 
int main()
{
int aryHuowq[3] = {0};
short   nIndex = 2; /* nIndex is short */

aryHuowq[nIndex--] = nIndex + 1;
printf("array[%d] : %d\n", nIndex+1, aryHuowq[nIndex+1]);
return 0;
}
/*/
/* The result is "array[2] : 2", but it should be "array[2] : 3" */
/*/

If nIndex is type of int, then the result is "array[2] : 3".


-- 
   Summary: the increment(++) or decrement(--) operators is wrong
for short index of array
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aonebeam at gmail dot com


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

[Bug other/42710] New: [4.5 Regression] ICE in first_imm_use_stmt, at tree-flow-inline.h:1081

[doko at ubuntu dot com]

seen with trunk 20100107:

build succeeds with either -O2, or without the -ffast-math

$ g++ -c -g -O3 -ffast-math dcraw.ii 
dcraw.cc: In member function 'void DCRaw::convert_to_rgb()':
dcraw.cc:8096:6: internal compiler error: in first_imm_use_stmt, at
tree-flow-inline.h:1081
Please submit a full bug report,
with preprocessed source if appropriate.


-- 
   Summary: [4.5 Regression] ICE in first_imm_use_stmt, at tree-
flow-inline.h:1081
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: doko at ubuntu dot com


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

[Bug c/42708] [4.5 Regression] ICE in gimplify_expr, at gimplify.c:6993

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2010-01-12 16:08 ---
typedef long unsigned int size_t;
extern char *yytext;
typedef union YYSTYPE {
char *id;
}  YYSTYPE;
extern YYSTYPE yylval;
void yylex (int b)
{
  yylval = (YYSTYPE) (b ? 0 : (char *) malloc (4));
}


#1  0x0080f95a in gimplify_expr (expr_p=0x77ff90d0, 
pre_p=0x7fffcec8, post_p=0x7fff8a08, 
gimple_test_f=0x7c83bf , fallback=1)
at /space/rguenther/src/svn/trunk/gcc/gimplify.c:6991
6991  gcc_assert (TREE_CODE (*expr_p) == TRUTH_AND_EXPR
(gdb) p *expr_p
$1 = (tree) 0x77ff9070
(gdb) call debug_tree ( *expr_p)
 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42708

[Bug tree-optimization/42709] [4.5 Regression] error: type mismatch in pointer plus expression

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2010-01-12 15:59 ---
Created an attachment (id=19557)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19557&action=view)
testcase


-- 


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

[Bug tree-optimization/42709] New: [4.5 Regression] error: type mismatch in pointer plus expression

[rguenth at gcc dot gnu dot org]

> ./cc1 -quiet -O3 YUY2.i 
YUY2.c: In function 'dv_mb411_right_YUY2':
YUY2.c:172:1: error: type mismatch in pointer plus expression
dv_coeff_t *

dv_coeff_t *

dv_coeff_t *

vect_var_.422_459 = vect_cst_.423_156 + vect_cst_.424_119;

YUY2.c:172:1: internal compiler error: verify_stmts failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: [4.5 Regression] error: type mismatch in pointer plus
expression
   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: rguenth at gcc dot gnu dot org


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

[Bug tree-optimization/42706] [4.5 Regression] ICE in gimple_op, at gimple.h:1634, (IPA SRA)

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2010-01-12 15:55 ---
Confirmed.


-- 

rguenth 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-12 15:55:06
   date||
   Target Milestone|--- |4.5.0


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

[Bug tree-optimization/42706] [4.5 Regression] ICE in gimple_op, at gimple.h:1634, (IPA SRA)

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-01-12 15:54 ---
Created an attachment (id=19556)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19556&action=view)
reduced testcase


-- 


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

[Bug middle-end/42708] [4.5 Regression] ICE in gimplify_expr, at gimplify.c:6993

[doko at ubuntu dot com]

--- Comment #2 from doko at ubuntu dot com  2010-01-12 15:53 ---
Created an attachment (id=19555)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19555&action=view)
preprocessed source

another failure, independent of -O[0-2]


-- 


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

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

[paolo dot carlini at oracle dot com]

-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

   Severity|major   |normal


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

[Bug middle-end/42708] [4.5 Regression] ICE in gimplify_expr, at gimplify.c:6993

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2010-01-12 15:46 ---
Created an attachment (id=19554)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19554&action=view)
testcase

reducing.


-- 


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

[Bug middle-end/42708] New: [4.5 Regression] ICE in gimplify_expr, at gimplify.c:6993

[rguenth at gcc dot gnu dot org]

> ./cc1 -quiet -O0 parser_lex.i 
parser_lex.l: In function 'yylex':
parser_lex.l:185:183: internal compiler error: in gimplify_expr, at
gimplify.c:6993
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: [4.5 Regression] ICE in gimplify_expr, at
gimplify.c:6993
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org


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

[Bug tree-optimization/42707] [4.5 Regression] ICE - segfault in mark_operand_necessary

[doko at ubuntu dot com]

--- Comment #1 from doko at ubuntu dot com  2010-01-12 15:43 ---
Created an attachment (id=19553)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19553&action=view)
preprocessed source


-- 


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

[Bug tree-optimization/42707] New: [4.5 Regression] ICE - segfault in mark_operand_necessary

[doko at ubuntu dot com]

seen with trunk 20100112, not with the 4.4 branch; lowering optimization to -O1
works around the segfault.

$ g++ -c -g -O2 nsTreeRows.ii
/scratch/packages/tmp/rebuild/kompozer-0.8~b1/mozilla/content/xul/templates/src/nsTreeRows.cpp:
In member function 'void nsTreeRows::InvalidateCachedRow()':
/scratch/packages/tmp/rebuild/kompozer-0.8~b1/mozilla/content/xul/templates/src/nsTreeRows.cpp:483:1:
internal compiler error: Segmentation fault
Please submit a full bug report,


Program received signal SIGSEGV, Segmentation fault.
mark_operand_necessary (aggressive=) at
../../src/gcc/tree-ssa-dce.c:265
265 SET_BIT (bb_contains_live_stmts, gimple_bb (stmt)->index);
(gdb) bt
#0  mark_operand_necessary (aggressive=) at
../../src/gcc/tree-ssa-dce.c:265
#1  propagate_necessity (aggressive=) at
../../src/gcc/tree-ssa-dce.c:705
#2  perform_tree_ssa_dce (aggressive=) at
../../src/gcc/tree-ssa-dce.c:1389
#3  0x0070bbae in execute_one_pass (pass=0x1129080) at
../../src/gcc/passes.c:1561
#4  0x0070be15 in execute_pass_list (pass=0x1129080) at
../../src/gcc/passes.c:1616
#5  0x0070be27 in execute_pass_list (pass=0x1128a20) at
../../src/gcc/passes.c:1617
#6  0x0070b668 in do_per_function_toporder (callback=0x70be00
, data=0x1128b40) at ../../src/gcc/passes.c:1142
#7  0x0070c08a in execute_ipa_pass_list (pass=0x11289c0) at
../../src/gcc/passes.c:1800
#8  0x00908e29 in ipa_passes () at ../../src/gcc/cgraphunit.c:1768
#9  cgraph_optimize () at ../../src/gcc/cgraphunit.c:1829
#10 0x00908f85 in cgraph_finalize_compilation_unit () at
../../src/gcc/cgraphunit.c:1093
#11 0x004f349c in cp_write_global_declarations () at
../../src/gcc/cp/decl2.c:3798
#12 0x0079f3a6 in compile_file (argc=14, argv=0x7fffe5f8) at
../../src/gcc/toplev.c:1065
#13 do_compile (argc=14, argv=0x7fffe5f8) at ../../src/gcc/toplev.c:2405
#14 toplev_main (argc=14, argv=0x7fffe5f8) at ../../src/gcc/toplev.c:2447
#15 0x7616cabd in __libc_start_main () from /lib/libc.so.6
#16 0x0049f179 in _start ()


-- 
   Summary: [4.5 Regression] ICE - segfault in
mark_operand_necessary
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: doko at ubuntu dot com


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

[Bug tree-optimization/42705] [4.5 Regression] verify_flow_info failed with -O

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-01-12 15:42 ---
typedef int GLint;
typedef unsigned char GLubyte;
typedef unsigned int uint32_t;
struct radeon_bo {
void *ptr;
uint32_t flags;
};
struct radeon_renderbuffer {
struct radeon_bo *bo;
unsigned int cpp;
int has_surface;
};
static inline
GLint r600_1d_tile_helper(const struct radeon_renderbuffer * rrb,
  GLint x, GLint y, GLint is_depth, GLint is_stencil)
{
  GLint element_bytes = rrb->cpp;
  GLint num_samples = 1;
  GLint tile_width = 8;
  GLint tile_height = 8;
  GLint tile_thickness = 1;
  GLint tile_bytes;
  GLint tiles_per_row;
  GLint slice_offset;
  GLint tile_row_index;
  GLint tile_column_index;
  GLint tile_offset;
  GLint pixel_number = 0;
  GLint element_offset;
  GLint offset = 0;
  tile_bytes = tile_width * tile_height * tile_thickness
  * element_bytes * num_samples;
  tile_column_index = x / tile_width;
  tile_offset = ((tile_row_index * tiles_per_row)
 + tile_column_index) * tile_bytes;
  if (is_depth) {
  }
  else {
  GLint sample_offset;
  switch (element_bytes) {
  case 1:   pixel_number |= ((x >> 0) & 1) << 0;
  }
  element_offset = sample_offset + (pixel_number * element_bytes);
  }
  offset = slice_offset + tile_offset + element_offset;
  return offset;
}
GLubyte *r600_ptr_color(const struct radeon_renderbuffer * rrb,
GLint x, GLint y)
{
  GLubyte *ptr = rrb->bo->ptr;
  uint32_t mask = 1 | 2;
  GLint offset;
  if (rrb->has_surface || !(rrb->bo->flags & mask)) {
  offset = r600_1d_tile_helper(rrb, x, y, 0, 0);
  }
  return &ptr[offset];
}


-- 

rguenth 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-12 15:42:46
   date||
   Target Milestone|--- |4.5.0


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

[Bug tree-optimization/42706] [4,.5 Regression] ICE in gimple_op, at gimple.h:1634, (IPA SRA)

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2010-01-12 15:28 ---
Created an attachment (id=19552)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19552&action=view)
testcase

Reducing.


-- 


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

[Bug tree-optimization/42706] New: [4,.5 Regression] ICE in gimple_op, at gimple.h:1634, (IPA SRA)

[rguenth at gcc dot gnu dot org]

> ./cc1 -quiet Net.i -O2 -w
Net.c: In function 'check_netstat':
Net.c:765:1: internal compiler error: in gimple_op, at gimple.h:1634
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: [4,.5 Regression] ICE in gimple_op, at gimple.h:1634,
(IPA SRA)
   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: rguenth at gcc dot gnu dot org


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

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

[law at redhat dot com]

--- Comment #9 from law at redhat dot com  2010-01-12 15:18 ---
Subject: Re:  vectorizer created unaligned vector
 insns

On 01/12/10 01:08, irar at il dot ibm dot com wrote:
> --- Comment #8 from irar at il dot ibm dot com  2010-01-12 08:08 ---
> So, to be on the safe side, we should assume that COMPONENT_REFs are not
> naturally aligned and never use peeling for them?
>
If you can not *prove* at compile time that you're going to get the 
proper alignment, then you can't vectorize without a runtime check to 
select between a vectorized and unvectorized loop.

Proven alignement -- vectorize
Proven unaligned -- do not vectorize
Likely aligned, but not proven -- emit two loops, one vectorized, one 
not vectorized and runtime selection of the proper loop

Otherwise you run the risk of making conforming code segfault which is 
obviously unacceptable.

jeff


-- 


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

[Bug tree-optimization/42705] [4.5 Regression] verify_flow_info failed with -O

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2010-01-12 15:15 ---
Created an attachment (id=19551)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19551&action=view)
testcase

Reducing.


-- 


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

[Bug tree-optimization/42705] New: [4.5 Regression] verify_flow_info failed with -O

[rguenth at gcc dot gnu dot org]

> ./cc1 -quiet radeon_span.i -O 
radeon_span.c: In function 'r600_ptr_color':
radeon_span.c:228:17: error: label 
 in the middle of basic block 9radeon_span.c:228:17: internal compiler
error: verify_flow_info failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: [4.5 Regression] verify_flow_info failed with -O
   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: rguenth at gcc dot gnu dot org


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

[Bug tree-optimization/42704] [4.5 Regression] ICE in verify_ssa after early SRA

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2010-01-12 14:53 ---
> ./cc1plus -quiet nsTreeRows.3.ii -O2 -w
nsTreeRows.3.ii: In member function 'void nsTreeRows::InvalidateCachedRow()':
nsTreeRows.3.ii:39:1: error: missing definition
for SSA_NAME: D.2215_9 in statement:
# .MEM_16 = VDEF <.MEM_12>
this_1(D)->mLastRow.mLink[i_8].mParent = D.2215_9;
nsTreeRows.3.ii:39:1: internal compiler error: verify_ssa failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


typedef int PRInt32;
class nsTreeRows {
class Subtree { };
enum { kMaxDepth = 32 };
struct Link {
Subtree* mParent;
PRInt32 mChildIndex;
Link& operator=(const Link& aLink) {
mParent = aLink.mParent;
mChildIndex = aLink.mChildIndex;
}
};
class iterator {
PRInt32 mTop;
PRInt32 mRowIndex;
Link mLink[kMaxDepth];
public:
iterator() : mTop(-1), mRowIndex(-1) { }
iterator& operator=(const iterator& aIterator);
};
Subtree* EnsureSubtreeFor(Subtree* aParent, PRInt32 aChildIndex);
Subtree* GetSubtreeFor(const Subtree* aParent,  
PRInt32 aChildIndex,   PRInt32* aSubtreeSize = 0);
void InvalidateCachedRow() {
mLastRow = iterator();
}
iterator mLastRow;
};
nsTreeRows::Subtree* nsTreeRows::EnsureSubtreeFor(Subtree* aParent,
 PRInt32 aChildIndex) {
Subtree* subtree = GetSubtreeFor(aParent, aChildIndex);
if (! subtree) {
InvalidateCachedRow();
}
}
nsTreeRows::iterator& nsTreeRows::iterator::operator=(const iterator&
aIterator) {
mTop = aIterator.mTop;
for (PRInt32 i = mTop;
 i >= 0;
 --i) mLink[i] = aIterator.mLink[i];
}


-- 

rguenth 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-12 14:53:45
   date||


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

[Bug tree-optimization/42703] [4.5 Regression] ICE in generate_subtree_copies, at tree-sra.c:2003

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2010-01-12 14:38 ---
__extension__ typedef unsigned long long int uint64_t;
typedef uint64_t ScmUInt64;
void swapb64(ScmUInt64 *loc) 
{
union {
ScmUInt64 l;
unsigned char c[4];
} dd;
unsigned char t;
dd.l = *loc;
(t = dd.c[3], dd.c[3] = dd.c[4], dd.c[4] = t);
}

> ./cc1 -quiet uvector.3.i -O
uvector.3.i: In function 'swapb64':
uvector.3.i:12:1: internal compiler error: in generate_subtree_copies, at
tree-sra.c:2003
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 


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

[Bug tree-optimization/42704] [4.5 Regression] ICE in verify_ssa after early SRA

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-01-12 14:37 ---
Reducing.


-- 

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

[Bug tree-optimization/42704] [4.5 Regression] ICE in verify_ssa after early SRA

[rguenth at gcc dot gnu dot org]

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


-- 


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

[Bug tree-optimization/42704] New: [4.5 Regression] ICE in verify_ssa after early SRA

[rguenth at gcc dot gnu dot org]

> ./cc1plus -quiet nsTreeRows.ii -O2
/usr/src/packages/BUILD/mozilla/content/xul/templates/src/nsTreeRows.cpp: In
member function 'void nsTreeRows::InvalidateCachedRow()':
/usr/src/packages/BUILD/mozilla/content/xul/templates/src/nsTreeRows.cpp:483:1:
error: missing definition
for SSA_NAME: D.14766_10 in statement:
# .MEM_18 = VDEF <.MEM_13>
this_1(D)->mLastRow.mLink[i_9].mParent = D.14766_10;
/usr/src/packages/BUILD/mozilla/content/xul/templates/src/nsTreeRows.cpp:483:1:
internal compiler error: verify_ssa failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: [4.5 Regression] ICE in verify_ssa after early SRA
   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: rguenth at gcc dot gnu dot org


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

[Bug libstdc++/42624] libstdc++ parallel mode deadlocks in barrier

[singler at kit dot edu]

--- Comment #11 from singler at kit dot edu  2010-01-12 14:35 ---
(In reply to comment #9)
> Could this bug be related to this one:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36242#c4

This bug is invalid for GCC 4.4.

> Clamd creates threads using pthread_create, std::find is called from those
> threads. There are also threads that only poll/dispatch, and never use the STL
> (hence never uses openmp). However the gcc manual doesn't mention
> incompatibility between pthread_create and openmp (or libstdc++ parallel 
> mode).

It should work nevertheless.


-- 


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

[Bug libstdc++/42624] libstdc++ parallel mode deadlocks in barrier

[singler at kit dot edu]

--- Comment #10 from singler at kit dot edu  2010-01-12 14:35 ---
Can reproduce deadlock now.


-- 

singler at kit dot edu changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |singler at kit dot edu
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-01-12 14:35:01
   date||


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

[Bug libgcj/40859] [4.4/4.5 regression] regressions in libjava testsuite on arm-linux

[doko at ubuntu dot com]

--- Comment #2 from doko at ubuntu dot com  2010-01-12 14:33 ---
this is fixed on the trunk, preparing a backport to the branch


-- 

doko at ubuntu dot com changed:

   What|Removed |Added

 CC||doko at ubuntu dot com


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

[Bug c++/42701] [4.5 Regression] ICE on error recovery

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-01-12 14:30:35
   date||


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

[Bug c++/42701] [4.5 Regression] ICE on error recovery

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2010-01-12 14:30 ---
Created an attachment (id=19549)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19549&action=view)
reduced testcase


-- 


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

[Bug tree-optimization/42703] [4.5 Regression] ICE in generate_subtree_copies, at tree-sra.c:2003

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-01-12 14:13 ---
Reducing.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-01-12 14:13:18
   date||
   Target Milestone|--- |4.5.0


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

[Bug tree-optimization/42703] [4.5 Regression] ICE in generate_subtree_copies, at tree-sra.c:2003

[doko at ubuntu dot com]

--- Comment #1 from doko at ubuntu dot com  2010-01-12 13:58 ---
Created an attachment (id=19548)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19548&action=view)
preprocessed source


-- 


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

[Bug tree-optimization/42703] New: [4.5 Regression] ICE in generate_subtree_copies, at tree-sra.c:2003

[doko at ubuntu dot com]

seen with trunk 20100107, not with the 4.4 branch. lowering optimization to -O0
lets the build succeed.

$ gcc -c -O1 uvector.i 
uvector.c: In function 'swapb64':
uvector.c:10935:1: internal compiler error: in generate_subtree_copies, at
tree-sra.c:2003
Please submit a full bug report,
with preprocessed source if appropriate.


-- 
   Summary: [4.5 Regression] ICE in generate_subtree_copies, at
tree-sra.c:2003
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: doko at ubuntu dot com


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