[Bug target/58426] vax fails to compile gcov.c in stage1

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou ebotcazou at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #4 from Eric Botcazou ebotcazou at gcc dot gnu.org ---
Use p debug_rtx(...) from within GDB instead of raw dumping RTXes...

[Bug c++/58430] New: GCC hangs with 100% cpu core utilization during template compilation

[apiro...@manage-it.ru]

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

Bug ID: 58430
   Summary: GCC hangs with 100% cpu core utilization during
template compilation
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: apiro...@manage-it.ru

The next code leads hanging up of the compiler:

templateunsigned I1, unsigned I2
void test()
{
testI1 + ((I2 - I1) / 2) + 1, I2();
testI1, I1 + ((I2 - I1) / 2) ();
};

int main() 
{
test0, 0();
return 0;
}

[Bug fortran/57697] [OOP] Segfault with defined assignment for components during intrinsic assignment

[burnus at gcc dot gnu.org]

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

--- Comment #8 from Tobias Burnus burnus at gcc dot gnu.org ---
Author: burnus
Date: Mon Sep 16 06:42:02 2013
New Revision: 202609

URL: http://gcc.gnu.org/viewcvs?rev=202609root=gccview=rev
Log:
2013-09-16  Tobias Burnus  bur...@net-b.de

PR fortran/57697
* resolve.c (generate_component_assignments): Correctly handle
* the
case that the LHS is not allocated.

2013-09-16  Tobias Burnus  bur...@net-b.de

PR fortran/57697
* gfortran.dg/defined_assignment_10.f90: Comment print
* statement.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/defined_assignment_10.f90

[Bug tree-optimization/58431] New: wrong code at -O3 on x86_64-linux-gnu (in 32-bit mode)

[su at cs dot ucdavis.edu]

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

Bug ID: 58431
   Summary: wrong code at -O3 on x86_64-linux-gnu (in 32-bit mode)
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu

The current gcc trunk mis-compiles the following code on x86_64-linux at -O3 in
32-bit mode. 

This is a regression from 4.8.x. 


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure
--enable-languages=c,c++,objc,obj-c++,fortran,lto
--with-gmp=/usr/local/gcc-trunk --with-mpfr=/usr/local/gcc-trunk
--with-mpc=/usr/local/gcc-trunk --with-cloog=/usr/local/gcc-trunk
--prefix=/usr/local/gcc-trunk
Thread model: posix
gcc version 4.9.0 20130915 (experimental) [trunk revision 202599] (GCC) 
$ gcc-trunk -m32 -O2 small.c
$ a.out
$ gcc-4.8 -m32 -O3 small.c
$ a.out
$ gcc-trunk -m32 -O3 small.c
$ a.out
Aborted (core dumped)
$ 


---


char a, h;
int b, d, e, g, j, k;
volatile int c;
short i;

int
main ()
{
  int m = i ^= 1;
  for (b = 0; b  1; b++)
{
  char o = m;
  g = k;
  j = j || c;
  if (a != o)
for (; d  1; d++)
  ;
  else
{
  char *p = h;
  *p = 1;
  for (; e; e++)
;
}
}

  if (h != 0)
__builtin_abort(); 

  return 0;
}

[Bug tree-optimization/58431] [4.9 Regression] wrong code at -O3 on x86_64-linux-gnu (in 32-bit mode)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-09-16
 CC||jakub at gcc dot gnu.org,
   ||law at gcc dot gnu.org
   Target Milestone|--- |4.9.0
Summary|wrong code at -O3 on|[4.9 Regression] wrong code
   |x86_64-linux-gnu (in 32-bit |at -O3 on x86_64-linux-gnu
   |mode)   |(in 32-bit mode)
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org ---
Started with r202489.

[Bug target/58426] vax fails to compile gcov.c in stage1

[martin at netbsd dot org]

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

Martin Husemann martin at netbsd dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Martin Husemann martin at netbsd dot org ---
 As you seem to use 4.8.1, your GCC is older than my commit, so I think
 backporting this patch would probably cure your problem. Give it a try!

Yes, I was using stock 4.8.1.
And indeed this change seems to fix it. Thanks!

[Bug c++/58430] GCC hangs with 100% cpu core utilization during template compilation

[rguenth at gcc dot gnu.org]

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

Richard Biener rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Richard Biener rguenth at gcc dot gnu.org ---
You are instantitating 2^900 templates which will take quite some time.
Lower -ftemplate-depth to something reasonable (the default is 900) to
get an error:

 g++-4.7 -S t.C -ftemplate-depth=3
t.C:4:3: error: template instantiation depth exceeds maximum of 3 (use
-ftemplate-depth= to increase the maximum) substituting 'templateunsigned int
I1, unsigned int I2 void test() [with unsigned int I1 = 3221225473u; unsigned
int I2 = 0u]'
t.C:4:3:   recursively required from 'void test() [with unsigned int I1 = 1u;
unsigned int I2 = 0u]'
t.C:4:3:   required from 'void test() [with unsigned int I1 = 0u; unsigned int
I2 = 0u]'
t.C:10:14:   required from here

Or limit instantiation by providing a terminating specialization.

[Bug c/58256] gcc for h8300 internal compiler error: in maybe_record_trace_start

[gang.chen at asianux dot com]

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

--- Comment #10 from Chen Gang gang.chen at asianux dot com ---
Created attachment 30826
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30826action=edit
(sorry, it is cc1 issue) It is the related command line for cc1 and the summary
work flow for gcc-4.8.0 and gcc-4.9.0

Oh, sorry, the comments #9 is obsoleted, it is not caused by xgcc (although
their work flow are different with each other), our issue is cc1 issue.

The attachment is the related command line for cc1 and the summary call flow
for gcc-4.8.0 and gcc-4.9.0.

I will continue to analyze the first different between them.

Welcome any suggestions and completions, thanks.

[Bug bootstrap/58368] [4.9 regression] bootstrap comparison failure in expr.o and i386.o on x86_64-linux

[mikpe at it dot uu.se]

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

Mikael Pettersson mikpe at it dot uu.se changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Mikael Pettersson mikpe at it dot uu.se ---
This bootstrap failure is gone as of gcc-4.9-20130915 aka rev 202605.

[Bug bootstrap/58368] [4.9 regression] bootstrap comparison failure in expr.o and i386.o on x86_64-linux

[sch...@linux-m68k.org]

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

--- Comment #4 from Andreas Schwab sch...@linux-m68k.org ---
r202345 has been reverted.

[Bug fortran/58355] [F03] ICE with TYPE, EXTENDS before parent TYPE defined

[janus at gcc dot gnu.org]

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

--- Comment #3 from janus at gcc dot gnu.org ---
(In reply to janus from comment #2)
 Draft patch:

... regtests cleanly.

[Bug target/58421] [4.9 regression] FAIL: gcc.c-torture/compile/20051216-1.c -O3 -fomit-frame-pointer (internal compiler error)

[rguenth at gcc dot gnu.org]

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

Richard Biener rguenth at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-09-16
 CC|rguenther at suse dot de   |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener rguenth at gcc dot gnu.org ---
Confirmed with a cross from x86_64 and -O3.

#1  0x007c857e in add_insn_before_nobb (insn=0x76ed9b40, 
before=0x76e8c708)
at /space/rguenther/src/svn/trunk/gcc/emit-rtl.c:3836
3836  gcc_assert (!optimize || !INSN_DELETED_P (before));
(gdb) call debug_rtx (before)
(insn/v 361 1077 638 69 (set (reg/f:DI 37 r38 [orig:463 new_vp.2 ] [463])
(unspec:DI [
(mem/f/c:DI (reg/f:DI 47 r48 [760]) [6 new_vp+0 S8 A64])
] UNSPEC_LDS)) 20051216-1.c:103 23 {movdi_speculative}
 (nil))

#7  0x00adaba2 in get_nop_from_pool (insn=0x76e8c708)
at /space/rguenther/src/svn/trunk/gcc/sel-sched-ir.c:1048
1048  nop = emit_insn_before (nop, insn);

some unsharing is maybe missing?  Looks like a backend or scheduling bug
anyway.

[Bug tree-optimization/58417] Incorrect optimization in SCEV const-prop

[rguenth at gcc dot gnu.org]

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

Richard Biener rguenth at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||wrong-code
Summary|Incorrect optimization  |Incorrect optimization in
   ||SCEV const-prop
  Known to fail||4.4.7, 4.5.4, 4.6.4, 4.7.3,
   ||4.8.1, 4.9.0

--- Comment #2 from Richard Biener rguenth at gcc dot gnu.org ---
C testcase that fails everywhere:

/* { dg-do run } */

long long arr[6] = {0, 1, 2, 3, 4, 5};
extern  void abort (void);
void __attribute__((noinline,noclone))
foo (long long sum)
{
  asm ();
}
int main()
{
  int i, n = 5;
  long long sum = 0, prevsum = 0;

  for(i = 1; i = n; i++)
{
  foo (sum);
  sum = (i - 1) * arr[i] - prevsum;
  prevsum += arr[i];
}

  if (sum != 10)
abort ();
  return 0;
}

[Bug tree-optimization/58417] Incorrect optimization in SCEV const-prop

[rguenth at gcc dot gnu.org]

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

Richard Biener rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #3 from Richard Biener rguenth at gcc dot gnu.org ---
I will have a look.

[Bug c++/41933] [c++0x] lambdas and variadic templates don't work together

[paolo.carlini at oracle dot com]

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

Paolo Carlini paolo.carlini at oracle dot com changed:

   What|Removed |Added

 CC|gcc-bugs at gcc dot gnu.org|

--- Comment #13 from Paolo Carlini paolo.carlini at oracle dot com ---
Thanks Jason. I'm having a quick look: is PR47226 actually the same as comment
#9 here? In that case we could probably keep only one.

[Bug target/58416] Incorrect x87-based union copying code

[rguenth at gcc dot gnu.org]

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

Richard Biener rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Target||i?86-*-*

--- Comment #2 from Richard Biener rguenth at gcc dot gnu.org ---
It is SRA that transforms

  MCOp.DoubleVal = 0.0;
  MCOp.IntVal = Val_3(D);
  *dest_5(D) = MCOp;

into

  MCOp$DoubleVal_7 = 0.0;
  _8 = VIEW_CONVERT_EXPRdouble(Val_3(D));
  MCOp$DoubleVal_4 = _8;
  MEM[(union MyClass *)dest_5(D)] = MCOp$DoubleVal_4;

simplifying into

  _6 = VIEW_CONVERT_EXPRdouble(Val_3(D));
  MEM[(union MyClass *)dest_4(D)] = _6;

and

(insn 7 6 0 (set (mem:DF (reg/v/f:SI 60 [ dest ]) [0 MEM[(union MyClass
*)dest_4(D)]+0 S8 A32])
(subreg:DF (reg/v:DI 61 [ Val ]) 0)) t.C:15 -1
 (nil))

causes a reload:

(insn 7 11 12 2 (set (reg:DF 8 st [62])
(mem/c:DF (plus:SI (reg/f:SI 7 sp)
(const_int 8 [0x8])) [0 Val+0 S8 A32])) t.C:15 134
{*movdf_internal}
 (nil))
(insn 12 7 0 2 (set (mem:DF (reg/v/f:SI 0 ax [orig:60 dest ] [60]) [0
MEM[(union MyClass *)dest_4(D)]+0 S8 A32])
(reg:DF 8 st [62])) t.C:15 134 {*movdf_internal}
 (expr_list:REG_DEAD (reg:DF 8 st [62])
(expr_list:REG_DEAD (reg/v/f:SI 0 ax [orig:60 dest ] [60])
(nil

where *movdf_internal simply doesn't properly preserve sNaN.

It looks wrong for DFmode move instructions to not preserve a IEEE defined
flag.  I suppose it would be also wrong to not preserve the exact bit pattern
(think of canonicalizing NaNs).

[Bug tree-optimization/58432] New: [4.9 Regression] ICE: in insert_value_copy_on_edge, at tree-outof-ssa.c:233

[markus at trippelsdorf dot de]

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

Bug ID: 58432
   Summary: [4.9 Regression]  ICE: in insert_value_copy_on_edge,
at tree-outof-ssa.c:233
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: markus at trippelsdorf dot de

During profiled bootstrap:
/var/tmp/gcc_build_dir/./prev-gcc/xg++ -B/var/tmp/gcc_build_dir/./prev-gcc/
-B/usr/x86_64-pc-linux-gnu/bin/ -nostdinc++
-B/var/tmp/gcc_build_dir/prev-x86_64-p
c-linux-gnu/libstdc++-v3/src/.libs
-B/var/tmp/gcc_build_dir/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-I/var/tmp/gcc_build_dir/prev-x86_64-pc-linux-gnu/libstdc++-
v3/include/x86_64-pc-linux-gnu
-I/var/tmp/gcc_build_dir/prev-x86_64-pc-linux-gnu/libstdc++-v3/include
-I/var/tmp/gcc/libstdc++-v3/libsupc++ -L/var/tmp/gcc_build_dir/prev-x86_
64-pc-linux-gnu/libstdc++-v3/src/.libs
-L/var/tmp/gcc_build_dir/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-c   -march=native -O3 -pipe -fuse-linker-plugin -flto=j
observer -fno-fat-lto-objects -frandom-seed=1 -fprofile-generate -fno-lto
-DIN_GCC   -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall
-Wno-narrowing -Wwrite-st
rings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H -I. -I.
-I../../gcc/gcc -I../../gcc/gcc/.
 -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include 
-I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/bid
-I../libdecnumber -I../../gcc/gcc/../libbac
ktrace../../gcc/gcc/dwarf2out.c -o dwarf2out.o
../../gcc/gcc/dwarf2out.c: In function ‘void output_file_names()’:
../../gcc/gcc/dwarf2out.c:9577:1: internal compiler error: in
insert_value_copy_on_edge, at tree-outof-ssa.c:233

Reducing...

[Bug tree-optimization/58432] [4.9 Regression] ICE: in insert_value_copy_on_edge, at tree-outof-ssa.c:233

[markus at trippelsdorf dot de]

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

--- Comment #1 from Markus Trippelsdorf markus at trippelsdorf dot de ---
markus@x4 gcc % cat test.ii
struct {
  int prefix;
  int dir_idx;
} *a;
int b;
void fn1() {
  int *c, *d;
  for (; b; b++)
if (d[b]) {
  c[b] = d[b];
  a[0].dir_idx = 0;
}
}

markus@x4 gcc % /var/tmp/gcc_build_dir/./prev-gcc/xg++
-B/var/tmp/gcc_build_dir/./prev-gcc/ -c -O3 -fprofile-generate test.ii
test.ii:4:4: warning: anonymous type with no linkage used to declare variable
‘anonymous struct* a’ with linkage [enabled by default]
 } *a;
^
test.ii: In function ‘void fn1()’:
test.ii:6:6: internal compiler error: in insert_value_copy_on_edge, at
tree-outof-ssa.c:233
 void fn1() {
  ^

[Bug tree-optimization/58432] [4.9 Regression] ICE: in insert_value_copy_on_edge, at tree-outof-ssa.c:233

[mpolacek at gcc dot gnu.org]

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

Marek Polacek mpolacek at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-09-16
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |4.9.0
 Ever confirmed|0   |1

--- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org ---
I see
t.c: In function ‘fn1’:
t.c:6:6: error: invalid PHI argument
 void fn1() {
  ^
.MEM_26
t.c:6:6: error: incompatible types in PHI argument 0
long int

void

__gcov0.fn1_I_lsm.8_42 = PHI .MEM_26(6)
t.c:6:6: internal compiler error: verify_gimple failed
0xb0aca4 verify_gimple_in_cfg(function*)
/home/marek/src/gcc/gcc/tree-cfg.c:4819
0x9e25df execute_function_todo
/home/marek/src/gcc/gcc/passes.c:1833
0x9e18db do_per_function
/home/marek/src/gcc/gcc/passes.c:1563
0x9e2703 execute_todo
/home/marek/src/gcc/gcc/passes.c:1866
Please submit a full bug report,
with preprocessed source if appropriate.

Bisecting...

[Bug target/58405] Unoptimal code generated for computed goto

[semicontinuity at yandex dot ru]

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

--- Comment #2 from semicontinuity at yandex dot ru ---
Now I cannot reproduce that as well..
It seems that I've compiled it with -ffixed-r30 -ffixed-r31 (different from
original intention) - in this case it produces this kind of assembly .

Still, the code could be more optimal, without rjmp, push/pop - just with ijmp
replaced by 2 pushes + ret.

Thanks.

[Bug c/58256] gcc for h8300 internal compiler error: in maybe_record_trace_start

[gang.chen at asianux dot com]

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

--- Comment #11 from Chen Gang gang.chen at asianux dot com ---
It seems, I am really really a newbie !!

1. after append -gstabs+, can let gdb work well.

2. can use the internal dump_file (dump_start/dump_end) to analyze all
information (although I still don't know how to use it now).

3. that means: what I have done above is almost all 'spam'.  :-(


I will continue trying tomorrow.

[Bug tree-optimization/58417] Incorrect optimization in SCEV const-prop

[rguenth at gcc dot gnu.org]

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

Richard Biener rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sebpop at gmail dot com

--- Comment #4 from Richard Biener rguenth at gcc dot gnu.org ---
SCCP does constant propagation each SSA name at the beginning which is where
it replaces sum_23 with 0.  It ends up there through interpret_condition_phi
with respect to loop 0 which analyzes the scalar evolution of
sum_11 in loop 1 to 0 because it simply passes down the loop

#2  0x00c417c2 in interpret_condition_phi (loop=0x76d13320, 
condition_phi=gimple_phi 0x76e48200)
at /space/rguenther/src/svn/trunk/gcc/tree-scalar-evolution.c:1585
1585(loop, PHI_ARG_DEF (condition_phi, i));
(gdb) l
1580  res = chrec_dont_know;
1581  break;
1582}
1583
1584  branch_chrec = analyze_scalar_evolution
1585(loop, PHI_ARG_DEF (condition_phi, i));
1586
1587  res = chrec_merge (res, branch_chrec);
1588}

that is, this is a loop-closed PHI node, not a condition PHI.  The
SSA edge following code seems to have the same issues.

That is, if an edge into a PHI is coming from an inner loop then we need
to compute the evolution of the PHI arg with respect to that (the definition
loop) and compute the overall effects for that inner loop before using
the result.

Hm, but analyzing sum_11 in loop1 results in

_10 = {0, +, _9}_1
prevsum_21 = {0, +, _9}_1

and thus sum_11 = _10 - prevsum_21 = 0.

Hmm.  I don't think that's a valid CHREC (_9 is defined in loop 1).  And
indeed resolve_mixers will drop those to scev_not_known.  But it doesn't
get to that as we first cancel the thing by doing the minus ...

So,

Index: tree-scalar-evolution.c
===
--- tree-scalar-evolution.c (revision 202619)
+++ tree-scalar-evolution.c (working copy)
@@ -1699,6 +1699,8 @@ interpret_rhs_expr (struct loop *loop, g
   chrec2 = analyze_scalar_evolution (loop, rhs2);
   chrec1 = chrec_convert (type, chrec1, at_stmt);
   chrec2 = chrec_convert (type, chrec2, at_stmt);
+  chrec1 = resolve_mixers (loop, chrec1);
+  chrec2 = resolve_mixers (loop, chrec2);
   res = chrec_fold_minus (type, chrec1, chrec2);
   break;

fixes this, but ... I suppose we need to do that for each binary/ternary
op and chrec (or just those that call chrec_fold_{plus,minus}).
That said, we cannot hope on such SSA names canceling themselves out
as they may not refer to the same actual value.

[Bug ipa/58398] [4.9 Regression] gcc.dg/attr-ifunc-4.c runfail regression after r202111

[bernd.edlinger at hotmail dot de]

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

Bernd Edlinger bernd.edlinger at hotmail dot de changed:

   What|Removed |Added

 CC||bernd.edlinger at hotmail dot 
de

--- Comment #3 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
a possible fix:
what do you think of it?

--- cgraph.c.jj2013-09-12 15:03:18.0 +0200
+++ cgraph.c2013-09-16 13:37:16.453710206 +0200
@@ -2048,6 +2048,8 @@ cgraph_function_body_availability (struc
 avail = AVAIL_LOCAL;
   else if (node-symbol.alias  node-symbol.weakref)
 cgraph_function_or_thunk_node (node, avail);
+  else if (lookup_attribute (ifunc, DECL_ATTRIBUTES (node-symbol.decl)))
+avail = AVAIL_NOT_AVAILABLE;
   else if (!node-symbol.externally_visible)
 avail = AVAIL_AVAILABLE;
   /* Inline functions are safe to be analyzed even if their symbol can

[Bug tree-optimization/58417] Incorrect optimization in SCEV const-prop

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener rguenth at gcc dot gnu.org ---
But that eventually causes infinite recursions through instantiate_scev.

[Bug tree-optimization/58432] [4.9 Regression] ICE: in insert_value_copy_on_edge, at tree-outof-ssa.c:233

[mpolacek at gcc dot gnu.org]

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

Marek Polacek mpolacek at gcc dot gnu.org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org ---
Started with r202619.

[Bug ipa/58398] [4.9 Regression] gcc.dg/attr-ifunc-4.c runfail regression after r202111

[hubicka at gcc dot gnu.org]

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

--- Comment #4 from Jan Hubicka hubicka at gcc dot gnu.org ---
Yes, this seems OK.  We probably do not want to be too ken about optimizing
around ifuncs.

[Bug ipa/58398] [4.9 Regression] gcc.dg/attr-ifunc-4.c runfail regression after r202111

[bernd.edlinger at hotmail dot de]

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

--- Comment #5 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
(In reply to Jan Hubicka from comment #4)
 Yes, this seems OK.  We probably do not want to be too ken about optimizing
 around ifuncs.

Yes, the problem is that the resolver function just looks
like an alias, but it actually is not. the syntax in the
assembler must look like this:

.type   magic, @gnu_indirect_function
.setmagic,resolver
.globl  main
.type   main, @function

main:
callmagic


but it is all linker-magic. if you disassemle that
at runtime it looks like

main:
  call implementation


I am not sure, maybe returning AVAIL_OVERWRITABLE
would be more conservative. it seems to work too.

[Bug tree-optimization/58432] [4.9 Regression] ICE: in insert_value_copy_on_edge, at tree-outof-ssa.c:233

[rguenth at gcc dot gnu.org]

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

Richard Biener rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #4 from Richard Biener rguenth at gcc dot gnu.org ---
Mine then.

[Bug fortran/58433] New: FINAL memory leaks

[valeryweber at hotmail dot com]

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

Bug ID: 58433
   Summary: FINAL memory leaks
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: valeryweber at hotmail dot com

Dear All

I get memory leaks with the FINAL for the following code and
gcc version 4.9.0 20130916 (experimental) (GCC).
Is that a bug?
V


cat tmp.f90
module mod
  type t
 integer,allocatable,dimension(:)::i
   contains
 final :: t_final
  end type t
contains
  subroutine t_final(a)
type(t) :: a
deallocate(a%i)
  end subroutine t_final
end module mod
program main
  use mod
  type(t) :: a
  allocate(a%i(1))
end program main
gfortran-trunk -g tmp.f90
valgrind ./a.out 
==13378== Memcheck, a memory error detector
==13378== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==13378== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==13378== Command: ./a.out
==13378== 
==13378== 
==13378== HEAP SUMMARY:
==13378== in use at exit: 40,000 bytes in 1 blocks
==13378==   total heap usage: 18 allocs, 17 frees, 43,688 bytes allocated
==13378== 
==13378== LEAK SUMMARY:
==13378==definitely lost: 0 bytes in 0 blocks
==13378==indirectly lost: 0 bytes in 0 blocks
==13378==  possibly lost: 0 bytes in 0 blocks
==13378==still reachable: 40,000 bytes in 1 blocks
==13378== suppressed: 0 bytes in 0 blocks
==13378== Rerun with --leak-check=full to see details of leaked memory
==13378== 
==13378== For counts of detected and suppressed errors, rerun with: -v
==13378== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)

[Bug middle-end/57134] [4.9 Regression] ICE with -mstrict-align and inline assembly on ppc64

[jamborm at gcc dot gnu.org]

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

--- Comment #4 from Martin Jambor jamborm at gcc dot gnu.org ---
I suppose this has been fixed by r200086 ?

[Bug target/58416] Incorrect x87-based union copying code

[ubizjak at gmail dot com]

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

--- Comment #3 from Uroš Bizjak ubizjak at gmail dot com ---
(In reply to Richard Biener from comment #2)

 where *movdf_internal simply doesn't properly preserve sNaN.
 
 It looks wrong for DFmode move instructions to not preserve a IEEE defined
 flag.  I suppose it would be also wrong to not preserve the exact bit pattern
 (think of canonicalizing NaNs).

As said in PR57484, comment 11:

On an x86 target using the legacy x87 instructions and the 80-bit registers, a
load of a 64-bit or 32-bit value in memory into the 80-bit registers counts as
a format conversion and an signaling NaN input will turn into a quiet NaN in
the register format.

[Bug fortran/58434] New: no automatic deallocation with trunk

[valeryweber at hotmail dot com]

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

Bug ID: 58434
   Summary: no automatic deallocation with trunk
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: valeryweber at hotmail dot com

Dear All
I noticed a changed of behavior between 4.8.1 and trunk.
While the following code produde no memory leaks with 4.8.1 it does with
the trunk. Is that a bug?
v


cat tmp.f90
module mod
  type t
 integer,allocatable,dimension(:)::i
  end type t
end module mod
program main
  use mod
  type(t) :: a
  allocate(a%i(1))
end program main
gfortran-trunk -g tmp.f90
valgrind ./a.out 
==13501== Memcheck, a memory error detector
==13501== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==13501== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==13501== Command: ./a.out
==13501== 
==13501== 
==13501== HEAP SUMMARY:
==13501== in use at exit: 40,000 bytes in 1 blocks
==13501==   total heap usage: 18 allocs, 17 frees, 43,688 bytes allocated
==13501== 
==13501== LEAK SUMMARY:
==13501==definitely lost: 0 bytes in 0 blocks
==13501==indirectly lost: 0 bytes in 0 blocks
==13501==  possibly lost: 0 bytes in 0 blocks
==13501==still reachable: 40,000 bytes in 1 blocks
==13501== suppressed: 0 bytes in 0 blocks
==13501== Rerun with --leak-check=full to see details of leaked memory
==13501== 
==13501== For counts of detected and suppressed errors, rerun with: -v
==13501== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)
gfortran-4.8.1 -g tmp.f90
valgrind ./a.out 
==13508== Memcheck, a memory error detector
==13508== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==13508== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==13508== Command: ./a.out
==13508== 
==13508== 
==13508== HEAP SUMMARY:
==13508== in use at exit: 0 bytes in 0 blocks
==13508==   total heap usage: 18 allocs, 18 frees, 43,664 bytes allocated
==13508== 
==13508== All heap blocks were freed -- no leaks are possible
==13508== 
==13508== For counts of detected and suppressed errors, rerun with: -v
==13508== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)

[Bug middle-end/57134] [4.9 Regression] ICE with -mstrict-align and inline assembly on ppc64

[amodra at gmail dot com]

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

--- Comment #5 from Alan Modra amodra at gmail dot com ---
r200086 fixed Anton's first testcase but then he found another one.  See
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00983.html

[Bug c++/58406] ICE when compiling Vegastrike svn trunk

[vincent.legoll at gmail dot com]

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

--- Comment #9 from vincent.legoll at gmail dot com ---
OK I reproduced it again, and it is a duplicatre from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58006

I verified that by just recompilking the offending file without the
-ftree-parallelize-loops=2 and it worked fine

[Bug c++/58435] New: Applying a type transformation to a list: const ignored

[iavr at image dot ntua.gr]

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

Bug ID: 58435
   Summary: Applying a type transformation to a list: const
ignored
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iavr at image dot ntua.gr

The following applies a type transformation F to a list L of types T..., in
particular for a transformation that adds const:



   template template typename... class F, typename P struct apply;

   template 
   template typename... class F,
   template typename... class L, typename... T
struct apply F, L T...  { typedef L F T... type; };

   template typename T using map = const T;
   template typename struct A { };
   template typename void dummy();

   int main() { dummy apply map, A int ::type(); }



It fails to link because of

   undefined reference to `void dummyAint ()'

instead of the expected

  undefined reference to `void dummyAconst int ()'

i.e., const is ignored. It works for any other transformation I have tried.

[Bug c++/50370] [C++0x] Multiple declarations with default template arguments accepted

[jwillemsen at remedy dot nl]

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

Johnny Willemsen jwillemsen at remedy dot nl changed:

   What|Removed |Added

 CC||jwillemsen at remedy dot nl

--- Comment #2 from Johnny Willemsen jwillemsen at remedy dot nl ---
Also reproduced with GCC 4.8.1

[Bug target/48097] new Throw_2 failures in libjava under Xcode 4.0

[howarth at nitro dot med.uc.edu]

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

--- Comment #11 from Jack Howarth howarth at nitro dot med.uc.edu ---
(In reply to Iain Sandoe from comment #10)
 
 what's the expectation/status here?
 
 I see that these test-cases still fail on x86_64-darwin12, with the latest
 XCode tools.

These failures are still present in darwin13. Also, I see these failures are
also present in current gcc trunk on x86_64-unknown-freebsd8.4 and
i386-unknown-freebsd10.0. It might be interesting to find out why these fail on
freebsd.

[Bug middle-end/58418] [4.9 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu (in 32-bit mode)

[vmakarov at gcc dot gnu.org]

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

--- Comment #2 from Vladimir Makarov vmakarov at gcc dot gnu.org ---
Author: vmakarov
Date: Mon Sep 16 15:12:22 2013
New Revision: 202630

URL: http://gcc.gnu.org/viewcvs?rev=202630root=gccview=rev
Log:
2013-09-16  Vladimir Makarov  vmaka...@redhat.com

PR middle-end/58418
* lra-constraints.c (undo_optional_reloads): Consider all optional
reload even if it did not get a hard reg.

2013-09-16  Vladimir Makarov  vmaka...@redhat.com

* gcc.target/i386/pr58418.c: New.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr58418.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-constraints.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/58419] [4.9 Regression] wrong code at -O3 on x86_64-linux-gnu in 32-bit mode

[vmakarov at redhat dot com]

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

--- Comment #3 from Vladimir Makarov vmakarov at redhat dot com ---
(In reply to Zhendong Su from comment #2)
 (In reply to H.J. Lu from comment #1)
  It is caused by r202468.
 
 So it may have been a dup of 58418?

Yes, it is a duplication.

[Bug sanitizer/58420] internal compiler error: in ubsan_type_descriptor, at ubsan.c:280

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org ---
The ubsan vla-bound patch contains a thinko, it should be fixed by this patch
(forgot to check for TYPE_NAME != NULL):
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg01209.html

[Bug target/58416] Incorrect x87-based union copying code

[joseph at codesourcery dot com]

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

--- Comment #4 from joseph at codesourcery dot com joseph at codesourcery dot 
com ---
On Mon, 16 Sep 2013, rguenth at gcc dot gnu.org wrote:

 It looks wrong for DFmode move instructions to not preserve a IEEE defined
 flag.  I suppose it would be also wrong to not preserve the exact bit pattern
 (think of canonicalizing NaNs).

I think of the move problem for signaling NaNs as being bug 56831 - except 
that as expressed there it's only a bug for -fsignaling-nans, whereas the 
present bug is clearly a bug with or without -fsignaling-nans (the program 
makes no explicit use of signaling NaNs at all).

In the absence of -fexcess-precision=standard, I suppose the move patterns 
do need to represent how to move DFmove values into x87 registers from 
memory (despite the lack of proper bit-pattern-preserving loads on the 
processor), but any move instruction that extends SFmode or DFmode 
implicitly to XFmode should be avoided except where actually needed for 
floating-point arithmetic to be carried out or because the ABI requires 
the value in an x87 register.

[Bug target/58405] Unoptimal code generated for computed goto

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay gjl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #3 from Georg-Johann Lay gjl at gcc dot gnu.org ---
(In reply to semicontinuity from comment #2)
 Now I cannot reproduce that as well..
 It seems that I've compiled it with -ffixed-r30 -ffixed-r31 (different from
 original intention) - in this case it produces this kind of assembly .

I can reproduce it with -ffixed-r30 -ffixed-r31.  But as I already wrote above,
without Z (R30/R31) you cannot no more write sensible programs -- except
completely trivial ones. I don't think it makes sense to put effort into
optimizing useless programs or for programs that very likely will break by
occupying Z.

 Still, the code could be more optimal, without rjmp, push/pop - just with
 ijmp replaced by 2 pushes + ret.

Without -ffixed*, the code /does/ use IJMP.  If you take away Z, it's not
possible to use IJMP, of course.

[Bug c++/54367] [meta-bug] lambda expressions

[jason at gcc dot gnu.org]

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

Bug 54367 depends on bug 41933, which changed state.

Bug 41933 Summary: [c++0x] lambdas and variadic templates don't work together
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41933

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug c++/41933] [c++0x] lambdas and variadic templates don't work together

[jason at gcc dot gnu.org]

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

Jason Merrill jason at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #14 from Jason Merrill jason at gcc dot gnu.org ---
Yes, thanks for finding the existing PR for that case.

[Bug c++/58435] Applying a type transformation to a list: const ignored

[d.frey at gmx dot de]

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

Daniel Frey d.frey at gmx dot de changed:

   What|Removed |Added

 CC||d.frey at gmx dot de

--- Comment #1 from Daniel Frey d.frey at gmx dot de ---
Note that it is triggered by the 'using', if you replace the mapping by

   template typename T struct map { typedef const T type; };

and adapt 'apply' like this:

   template 
   template typename... class F,
   template typename... class L, typename... T
struct apply F, L T...  { typedef L typename F T::type... type; };

the result changes to the expected:

  undefined reference to `void dummyAint const ()'

[Bug c++/58273] [4.7/4.8/4.9 Regression] Segmentation fault with C++11

[Woebbeking at web dot de]

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

--- Comment #7 from André Wöbbeking Woebbeking at web dot de ---
Thanks!

[Bug fortran/58434] no automatic deallocation with trunk

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||janus at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #1 from janus at gcc dot gnu.org ---
(In reply to Valery Weber from comment #0)
 I noticed a changed of behavior between 4.8.1 and trunk.
 While the following code produde no memory leaks with 4.8.1 it does with
 the trunk. Is that a bug?

The same comment applies here as in PR 58433: This change is not a bug, but was
done intentionally to comply with the Fortran standard.

A possible workaround to accomplish finalization in the main program is to use
a BLOCK ... END BLOCK statement.

[Bug fortran/58436] [4.9 Regression][OOP] ICE (segfault) in generate_finalization_wrapper for CLASS(*)

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres dominiq at lps dot ens.fr changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-09-16
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr ---
Confirmed.

[Bug fortran/58436] New: [4.9 Regression][OOP] ICE (segfault) in generate_finalization_wrapper for CLASS(*)

[burnus at gcc dot gnu.org]

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

Bug ID: 58436
   Summary: [4.9 Regression][OOP] ICE (segfault) in
generate_finalization_wrapper for CLASS(*)
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org

The following code leads to an ICE; while finalization is a new 4.9 feature,
the code doesn't require it (and works with GCC 4.8). Hence, I labelled it as
regression.


class(*), allocatable :: var
end


Crashes the compiler with a segfault at

0x572cbf generate_finalization_wrapper
../../gcc/fortran/class.c:1518
0x572cbf gfc_find_derived_vtab(gfc_symbol*)
../../gcc/fortran/class.c:2317
0x5757cd gfc_build_class_symbol(gfc_typespec*, symbol_attribute*,
gfc_array_spec**, bool)
../../gcc/fortran/class.c:652

[Bug fortran/58356] ICE with finalization and type extension

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org ---
Author: burnus
Date: Mon Sep 16 18:01:59 2013
New Revision: 202633

URL: http://gcc.gnu.org/viewcvs?rev=202633root=gccview=rev
Log:
2013-09-16  Tobias Burnus  bur...@net-b.de

PR fortran/58356
* class.c (generate_finalization_wrapper): Init proc_tree if
not yet resolved.

2013-09-16  Tobias Burnus  bur...@net-b.de

PR fortran/58356
* gfortran.dg/finalize_19.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/finalize_19.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/class.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/58433] FINAL memory leaks

[valeryweber at hotmail dot com]

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

--- Comment #2 from Valery Weber valeryweber at hotmail dot com ---
But the std says:



4.5.6.3 When finalization occurs
...
2 A nonpointer, nonallocatable object that is not a dummy argument or function
result is finalized immediately before it would become undefined due to
execution of a RETURN or END statement (16.6.6, item (3)).


and


1.3.66
END statement
end-block-data-stmt, end-function-stmt, end-module-stmt,
end-mp-subprogram-stmt, end-program-stmt, end-submodule-stmt, or
end-subroutine-stmt


so does the code fulfilling the finalization requirement (nonpointer/nonalloc
object + end-program-stmt)?

v

[Bug fortran/58434] no automatic deallocation with trunk

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

[Bug fortran/58356] ICE with finalization and type extension

[abensonca at gmail dot com]

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

--- Comment #5 from Andrew Benson abensonca at gmail dot com ---
Thanks for fixing!

[Bug fortran/58356] ICE with finalization and type extension

[burnus at gcc dot gnu.org]

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

Tobias Burnus burnus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org ---
FIXED on the trunk (4.9) [no branch affected].

Thanks for the report!

[Bug tree-optimization/58431] [4.9 Regression] wrong code at -O3 on x86_64-linux-gnu (in 32-bit mode)

[law at redhat dot com]

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

Jeffrey A. Law law at redhat dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #4 from Jeffrey A. Law law at redhat dot com ---
Verified as a duplicate.

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

[Bug bootstrap/58340] [4.9 regression] gcc/cp/pt.c:7064:1: internal compiler error: in propagate_threaded_block_debug_into, at tree-ssa-threadedge.c:623

[law at redhat dot com]

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

Jeffrey A. Law law at redhat dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #25 from Jeffrey A. Law law at redhat dot com ---
Closing this as resolved via the reversion.

[Bug tree-optimization/58431] [4.9 Regression] wrong code at -O3 on x86_64-linux-gnu (in 32-bit mode)

[glisse at gcc dot gnu.org]

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

--- Comment #3 from Marc Glisse glisse at gcc dot gnu.org ---
-fdisable-tree-phicprop2 lets it pass (the dumps appear identical before and
after this pass, but with verbose dumps we see some memory PHIs disappear)
-fdisable-tree-cddce2 also lets it pass, with larger differences in the dumps.

[Bug fortran/58433] FINAL memory leaks

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||janus at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #1 from janus at gcc dot gnu.org ---
(In reply to Valery Weber from comment #0)
 I get memory leaks with the FINAL for the following code and
 gcc version 4.9.0 20130916 (experimental) (GCC).
 Is that a bug?

No, in fact this is not a bug. According to the Fortran standard, variables in
the main program are not subject to automatic deallocation or finalization, cf.
also PR 55207.

If you put the variable 'a' inside a FUNCTION, SUBROUTINE or BLOCK, it will be
finalized, but not in the main program.

[Bug c++/58435] Applying a type transformation to a list: const ignored

[redi at gcc dot gnu.org]

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

Jonathan Wakely redi at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-09-16
 Ever confirmed|0   |1

[Bug c++/58435] Applying a type transformation to a list: const ignored

[paolo.carlini at oracle dot com]

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

--- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com ---
Reduced:

templatetypename T, typename U
struct same { static const bool value = false; };

templatetypename T
struct sameT, T { static const bool value = true; };

template template typename class F, typename T struct apply
{ typedef FT type; };

template typename T using map = const T;

static_assert(sameapplymap, int::type, const int::value, );

[Bug tree-optimization/58342] ICE in propagate_threaded_block_debug_into, at tree-ssa-threadedge.c:623

[law at redhat dot com]

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

Bug 58342 depends on bug 58340, which changed state.

Bug 58340 Summary: [4.9 regression] gcc/cp/pt.c:7064:1: internal compiler 
error: in propagate_threaded_block_debug_into, at tree-ssa-threadedge.c:623
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58340

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

[Bug middle-end/58418] [4.9 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu (in 32-bit mode)

[law at redhat dot com]

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

--- Comment #3 from Jeffrey A. Law law at redhat dot com ---
*** Bug 58431 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/58431] [4.9 Regression] wrong code at -O3 on x86_64-linux-gnu (in 32-bit mode)

[law at redhat dot com]

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

--- Comment #2 from Jeffrey A. Law law at redhat dot com ---
Jakub,

That doesn't make *any* sense.  r202489 simply *avoids* doing any jump
threading in certain cases.  If that change is indeed the trigger, then the
root cause is going to be a latent bug elsewhere.

[Bug c++/58435] Applying a type transformation to a list: const ignored

[paolo.carlini at oracle dot com]

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

Paolo Carlini paolo.carlini at oracle dot com changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com
   Target Milestone|--- |4.9.0

--- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com ---
Mine.

[Bug c++/58437] New: Sorting value in reverse order is much slower compare to gcc44

[tammy at Cadence dot COM]

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

Bug ID: 58437
   Summary: Sorting value in reverse order is much slower compare
to gcc44
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tammy at Cadence dot COM

For the following testcase:

===
#include algorithm
#include vector

using namespace std;

int main()
{
const size_t num = 1000;
vectorint v(num);

generate(v.begin(), v.end(), rand);
sort(v.begin(), v.end());
sort(v.rbegin(), v.rend());
}
==

If we compile it with g++ -O3, it takes 1 sec to sort random
values with either gcc445 or gcc481. Gcc445 takes 0.33 sec to sort
value in reverse order, but gcc 4.7/4.8 takes 2 secs.

Is there any way to improve the run-time performance?

[Bug fortran/58433] FINAL memory leaks

[janus at gcc dot gnu.org]

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

--- Comment #3 from janus at gcc dot gnu.org ---
(In reply to Valery Weber from comment #2)
 But the std says:
 
 
 
 4.5.6.3 When finalization occurs
 ...
 2 A nonpointer, nonallocatable object that is not a dummy argument or
 function result is finalized immediately before it would become undefined
 due to execution of a RETURN or END statement (16.6.6, item (3)).

That's right.

However, 16.6.6 (3) says:

(3) When execution of an instance of a subprogram completes,
(a) its unsaved local variables become undefined

So, firstly, this only talks about 'subprograms' and, secondly, about *unsaved*
local variables. At least in F08, variables in the main program implicitly get
the SAVE attribute.

More importantly, note that 4.5.6.4 explicitly states that entities are not
finalized on an end-program-stmt!


We had quite some discussions about this already last year, both on c.l.f. (see
https://groups.google.com/forum/?fromgroups=#!topic/comp.lang.fortran/mhQLZOmVQ8Q)
and the gfortran mailing list (see e.g.
http://gcc.gnu.org/ml/fortran/2012-10/msg00136.html and other posts in this
thread).

[Bug c++/58437] Sorting value in reverse order is much slower compare to gcc44

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse glisse at gcc dot gnu.org ---
Ah forget my last message, I understand now you are really interested in how
long it takes to reverse-sort an already sorted vector. Indeed it does take
much longer with 4.6+ than with 4.4.

[Bug target/56875] vax target miscompiles short negative constants for 64bit values

[jbg...@lug-owl.de]

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

--- Comment #1 from Jan-Benedict Glaw jbg...@lug-owl.de ---
The `gas' bug seems to only show up on 32bit host platform. Creating a
cross-gas on a amd64 systems seems to always result in correct VAX binary
output, even for old 2.21 releases. (Will further check this.)

I tend to not fix GCC in this regard. Its output is correct, though doing hex
output instead of negative decimals would work-around gas's bug. However, I
think we'd better fix gas and possibly add a version check to gcc?

[Bug c++/58437] Sorting value in reverse order is much slower compare to gcc44

[glisse at gcc dot gnu.org]

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

--- Comment #3 from Marc Glisse glisse at gcc dot gnu.org ---
Less confusing testcase:

#include algorithm
#include vector

using namespace std;

int main()
{
  const int num = 1000;
  vectorint v; v.reserve(num);
  for(int i=0;i!=num;++i) v.push_back(-i);
  sort(v.begin(), v.end());
}

[Bug sanitizer/58413] ubsan constant folding

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org ---
A patch with the testcase for the bit-field issue has been posted:
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg01212.html

[Bug c++/58437] Sorting value in reverse order is much slower compare to gcc44

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse glisse at gcc dot gnu.org ---
I can't reproduce this. I tried compiling with -O3 (with 4.4, 4.7 and 4.8)
after commenting out either of the 2 sort lines, and I see roughly the same
execution times (maybe a few % difference, but nowhere near the factor 6 you
mention, which seems quite suspicious to me).

You need to at least describe your platform more in details...

[Bug rtl-optimization/58438] [4.9 Regression] ICE: in check_rtl, at lra.c:2036

[markus at trippelsdorf dot de]

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

--- Comment #2 from Markus Trippelsdorf markus at trippelsdorf dot de ---
markus@x4 gcc % cat test.ii
enum gimple_code {};
struct A {
  gimple_code code;
};
struct B {
  A gsbase;
};
int **a;
int b, d, e, f, g, h, i, j, k, l, m, n, o;
gimple_code c, p;
class C {
  virtual unsigned m_fn1();
};
B q;
static int fn1() {
  int r;
  if (k)
i = 0;
  for (; i; j++) {
b = c = 0;
if (b)
  n = *a[0];
b = p  c;
if (b)
  r = *a[0];
b = q.gsbase.code  c;
if (b)
  o = *a[0];
m = o;
if (e || 1  r || d || l)
  return 0;
  }
}

class D : C {
  unsigned m_fn1() {
fn1();
for (; h; g++)
  for (;; f++)
;
  }
};
void fn2() { new D; }

markus@x4 gcc % g++ -c -march=amdfam10 -O3 -fprofile-generate test.ii
test.ii: In member function ‘virtual unsigned int D::m_fn1()’:
test.ii:41:3: internal compiler error: in check_rtl, at lra.c:2036

[Bug rtl-optimization/58438] [4.9 Regression] ICE: in check_rtl, at lra.c:2036

[markus at trippelsdorf dot de]

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

--- Comment #1 from Markus Trippelsdorf markus at trippelsdorf dot de ---
During profiled bootstrap:
/var/tmp/gcc_build_dir/./prev-gcc/xg++ -B/var/tmp/gcc_build_dir/./prev-gcc/
-B/usr/x86_64-pc-linux-gnu/bin/ -nostdinc++
-B/var/tmp/gcc_build_dir/prev-x86_64-pc-linux-gnu/libs
tdc++-v3/src/.libs
-B/var/tmp/gcc_build_dir/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-I/var/tmp/gcc_build_dir/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_6
4-pc-linux-gnu
-I/var/tmp/gcc_build_dir/prev-x86_64-pc-linux-gnu/libstdc++-v3/include
-I/var/tmp/gcc/libstdc++-v3/libsupc++
-L/var/tmp/gcc_build_dir/prev-x86_64-pc-linux-gnu/
libstdc++-v3/src/.libs
-L/var/tmp/gcc_build_dir/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-c   -march=native -O3 -pipe -fuse-linker-plugin -flto=jobserver -fno-fa
t-lto-objects -frandom-seed=1 -fprofile-generate -fno-lto -DIN_GCC  
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qua
l -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings   -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc
-I../../gcc/gcc/. -I../../gcc/gcc
/../include -I../../gcc/gcc/../libcpp/include  -I../../gcc/gcc/../libdecnumber
-I../../gcc/gcc/../libdecnumber/bid -I../libdecnumber
-I../../gcc/gcc/../libbacktrace../../
gcc/gcc/tree-ssa-uninit.c -o tree-ssa-uninit.o
../../gcc/gcc/tree-ssa-uninit.c: In function ‘bool
is_use_properly_guarded(gimple, basic_block, gimple, unsigned int,
pointer_set_t*)’:
../../gcc/gcc/tree-ssa-uninit.c:1845:1: internal compiler error: in check_rtl,
at lra.c:2036

Reducing...

[Bug rtl-optimization/58438] New: [4.9 Regression ICE: in check_rtl, at lra.c:2036

[markus at trippelsdorf dot de]

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

Bug ID: 58438
   Summary: [4.9 Regression ICE: in check_rtl, at lra.c:2036
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: markus at trippelsdorf dot de

[Bug target/58208] dequestd::string 32-bit -O3 bug

[tammy at Cadence dot COM]

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

--- Comment #13 from Tammy Hsu tammy at Cadence dot COM ---
Hi Mikael,

My last comment probably is not clear enough. The import (testcase) I built on
RHEL 5.5 crashes on RHEL 5.5, but if I ran it on Fedora 19, it works.

So if you take the import you built on CentOS 5.8 (crashes on CentOS 5.8) to
the Fedora 17 system, I think it will run fine.

May be the above information will give you some hint regarding what's the cause
of this issue?

Thanks, Tammy

[Bug other/58439] New: ICE verify_cgraph_node failed

[jan.sm...@alcatel-lucent.com]

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

Bug ID: 58439
   Summary: ICE verify_cgraph_node failed
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jan.sm...@alcatel-lucent.com

Created attachment 30827
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30827action=edit
verify_cgraph_node failed

file.c:3290:1: error: inlined_to pointer is set but no predecessors found
 }
 ^
GetCoreNum/204 (GetCoreNum) @0x7f61060995f0
  Type: function definition analyzed
  Visibility: artificial
  next sharing asm name: 202
  References:
  Referring:
  Function GetCoreNum/204 is inline copy in taskLock/60
  Availability: local
  Function flags: body local
  Called by:
  Calls:
file.c:3290:1: internal compiler error: verify_cgraph_node failed
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.


gcc version 4.9.0 20130908 (experimental) 
mips-wrs-vxworks

testcase attached

[Bug other/58439] ICE verify_cgraph_node failed

[jan.sm...@alcatel-lucent.com]

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

--- Comment #1 from Jan Smets jan.sm...@alcatel-lucent.com ---
Oh, and compile with -O2

[Bug c++/58437] Sorting value in reverse order is much slower compare to gcc44

[paolo.carlini at oracle dot com]

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

Paolo Carlini paolo.carlini at oracle dot com changed:

   What|Removed |Added

 CC||chris at bubblescope dot net

--- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com ---
Eh, it's *a lot* of time! I guess we have ask again Chris' help, because I
don't think much happened after the move semantics work.

[Bug libstdc++/58440] New: There seems to be a major performance regression in std::sort performance

[jmbnyc at gmail dot com]

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

Bug ID: 58440
   Summary: There seems to be a major performance regression in
std::sort performance
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jmbnyc at gmail dot com

Created attachment 30828
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30828action=edit
cpp file the illustrates bug

The attached simple program illustrates a major performance degradation. I
first noticed this in gcc 4.7.2. I tried to figure out if the was the compiler
or the std library and was able to get 2 systems with same CPU but different
gcc versions to illustrate the problem also exists in 4.6. It might exist in
4.5 but I could not test that combination.

Here are my results:

Intel(R) Xeon(R) CPU   X5680  @ 3.33GHz

GCC 4.4.3
-bash-3.2$ g++ -O3 bug.cpp -o sort
-bash-3.2$ ./sort
elapsed: 12.970126

GCC 4.6.2
-bash-3.2$ g++ -O3 bug.cpp -o sort
-bash-3.2$ ./sort
elapsed: 77.040297

[Bug c++/58437] Sorting value in reverse order is much slower compare to gcc44

[paolo.carlini at oracle dot com]

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

Paolo Carlini paolo.carlini at oracle dot com changed:

   What|Removed |Added

 CC||jmbnyc at gmail dot com

--- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com ---
*** Bug 58440 has been marked as a duplicate of this bug. ***

[Bug libstdc++/58440] There seems to be a major performance regression in std::sort performance

[paolo.carlini at oracle dot com]

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

Paolo Carlini paolo.carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com ---
Dup.

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

[Bug target/56875] vax target miscompiles short negative constants for 64bit values

[jbg...@lug-owl.de]

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

--- Comment #2 from Jan-Benedict Glaw jbg...@lug-owl.de ---
This is gas's tc-vax.c:

3158   if ((is_absolute)  (expP-X_op != O_big))
3159 {
3160   /* If nbytes  4, then we are scrod. We
3161  don't know if the high order bytes
3162  are to be 0xFF or 0x00.  BSD4.2  RMS
3163  say use 0x00. OK --- but this
3164  assembler needs ANOTHER rewrite to
3165  cope properly with this bug.  */
3166   md_number_to_chars (p + 1, this_add_number,
3167   min (sizeof (valueT),
3168(size_t) nbytes));
3169   if ((size_t) nbytes  sizeof (valueT))
3170 memset (p + 1 + sizeof (valueT),
3171 '\0', nbytes - sizeof (valueT));
3172 }
[...]

This is for small values (ie. -1 fitting in a 32bit valueT) and it doesn't
properly sign-extend in this case. Taking into account the next couple lines
(not shown here), this part of the code needs to rethought.

A workaround would be to actually place an all-hex value (through GCC) here,
but that wouldn't fix gas for any hand-written assembler.

[Bug libstdc++/58437] [4.7/4.7/4.9 Regression] Sorting value in reverse order is much slower compare to gcc44

[paolo.carlini at oracle dot com]

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

Paolo Carlini paolo.carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-09-17
Summary|Sorting value in reverse|[4.7/4.7/4.9 Regression]
   |order is much slower|Sorting value in reverse
   |compare to gcc44|order is much slower
   ||compare to gcc44
 Ever confirmed|0   |1

[Bug libstdc++/58440] There seems to be a major performance regression in std::sort performance

[jmbnyc at gmail dot com]

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

--- Comment #2 from Jeffrey M. Birnbaum jmbnyc at gmail dot com ---
(In reply to Paolo Carlini from comment #1)
 Dup.
 
 *** This bug has been marked as a duplicate of bug 58437 ***

Cool, I actually did a search before submitting the bug but I did not find
anything and now I see why. The prior bug description does not mention
std::sort.

BTW, in my case, std::sort is just slower regardless of what is sorted. the
data can either be in sort order or be in reverse sort order. In either case,
the mentioned versions are slower.

[Bug libstdc++/58437] [4.7/4.7/4.9 Regression] Sorting value in reverse order is much slower compare to gcc44

[paolo.carlini at oracle dot com]

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

--- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com ---
In particular I'm thinking this change:

  http://gcc.gnu.org/ml/libstdc++/2009-08/msg00073.html

[Bug target/57589] Linux powerpc -mcpu=native returns pointer to variable on stack in driver-rs6000.c

[amodra at gcc dot gnu.org]

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

--- Comment #5 from Alan Modra amodra at gcc dot gnu.org ---
Author: amodra
Date: Tue Sep 17 02:04:49 2013
New Revision: 202642

URL: http://gcc.gnu.org/viewcvs?rev=202642root=gccview=rev
Log:
PR target/57589
* config/rs6000/driver-rs6000.c (elf_platform): Revert 2013-06-11 patch.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/driver-rs6000.c

[Bug target/57589] Linux powerpc -mcpu=native returns pointer to variable on stack in driver-rs6000.c

[amodra at gmail dot com]

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

Alan Modra amodra at gmail dot com changed:

   What|Removed |Added

 CC||amodra at gmail dot com
 Resolution|FIXED   |INVALID

[Bug target/58423] [ARM]ICE with shrink-wrap-sibcall.c on a15/neon/hard

[zhenqiang.chen at linaro dot org]

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

zhenqiang.chen at linaro dot org changed:

   What|Removed |Added

 CC||zhenqiang.chen at linaro dot 
org

--- Comment #1 from zhenqiang.chen at linaro dot org ---
Root cause:
RTX_FRAME_RELATED_P is not correctly set in function arm_emit_ldrd_pop.

I will create a patch to fix it.

[Bug ipa/58332] error: inlined_to pointer is set but no predecessors found

[mpolacek at gcc dot gnu.org]

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

Marek Polacek mpolacek at gcc dot gnu.org changed:

   What|Removed |Added

 CC||jan.sm...@alcatel-lucent.co
   ||m

--- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org ---
*** Bug 58439 has been marked as a duplicate of this bug. ***

[Bug other/58439] ICE verify_cgraph_node failed

[mpolacek at gcc dot gnu.org]

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

Marek Polacek mpolacek at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org ---
Dup.

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

[Bug rtl-optimization/58438] [4.9 Regression] ICE: in check_rtl, at lra.c:2036

[mpolacek at gcc dot gnu.org]

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

Marek Polacek mpolacek at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-09-17
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |4.9.0
 Ever confirmed|0   |1

--- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org ---
Confirmed.

[Bug rtl-optimization/58438] [4.9 Regression] ICE: in check_rtl, at lra.c:2036

[mpolacek at gcc dot gnu.org]

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

Marek Polacek mpolacek at gcc dot gnu.org changed:

   What|Removed |Added

 CC||vmakarov at gcc dot gnu.org

--- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org ---
Started with r202630.