[Bug target/48723] ICE in ix86_expand_prologue() with -fstack-check + function returning struct, on corei7-avx

[ubizjak at gmail dot com]

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

Uros Bizjak  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||ubizjak at gmail dot com
 Resolution|FIXED   |
 AssignedTo|ubizjak at gmail dot com|unassigned at gcc dot
   ||gnu.org

--- Comment #10 from Uros Bizjak  2011-04-26 07:27:17 
UTC ---
.

[Bug tree-optimization/48734] [4.6/4.7 Regression] ICE in eliminate_redundant_comparison, at tree-ssa-reassoc.c:1321

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |

--- Comment #3 from Jakub Jelinek  2011-04-26 
07:37:58 UTC ---
Created attachment 24099
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24099
gcc46-pr48734.patch

Untested fix.

[Bug c/44828] [4.3/4.4 Regression] possible integer wrong code bug

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jakub at gcc dot gnu.org
  Known to work||
 Resolution||FIXED
   Target Milestone|4.3.6   |4.5.1
  Known to fail||

--- Comment #14 from Jakub Jelinek  2011-04-26 
07:40:15 UTC ---
Fixed for 4.5.1+.

[Bug tree-optimization/43781] [4.6 Regression] ice: verify_ssa failed

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  2011-04-26 
08:11:42 UTC ---
This has been fixed or made latent by
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159100

[Bug rtl-optimization/48757] internal compiler error: in compensate_edge, at reg-stack.c:2788

[ubizjak at gmail dot com]

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

Uros Bizjak  changed:

   What|Removed |Added

 Target||i686-pc-linux-gnu
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.04.26 08:13:21
 CC||ubizjak at gmail dot com
 Ever Confirmed|0   |1
  Known to fail||4.5.3, 4.6.1, 4.7.0

--- Comment #1 from Uros Bizjak  2011-04-26 08:13:21 
UTC ---
Confirmed with current mainline (-O2 -m32), we ICE in reg-stack.c,
compensate_edge:

  /* We don't support abnormal edges.  Global takes care to
 avoid any live register across them, so we should never
 have to insert instructions on such edges.  */
  gcc_assert (! (e->flags & EDGE_ABNORMAL));

Where _.f.210r.stack shows that we want to compensate abnormal edges from bb 8:

Edge 8->13: no changes needed
Edge 8->9: correcting stack to empty
Edge 8->12: correcting stack to empty
Edge 8->11: correcting stack to empty

...

;; End of basic block 8 -> ( 13 9 12 11)
;; lr  out  7 [sp] 10 [st(2)] 11 [st(3)]
;; live  out  7 [sp] 10 [st(2)] 11 [st(3)]


;; Succ edge  13 [25.0%]  (ab,loop_exit)
;; Succ edge  9 [25.0%]  (ab,loop_exit)
;; Succ edge  12 [25.0%]  (ab,loop_exit)
;; Succ edge  11 [25.0%]  (ab)

Apparently, global does not work as expected.

[Bug rtl-optimization/48757] [4.5/4.6/4.7 Regression] internal compiler error: in compensate_edge, at reg-stack.c:2788

[ubizjak at gmail dot com]

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

Uros Bizjak  changed:

   What|Removed |Added

   Target Milestone|--- |4.5.3

[Bug tree-optimization/48768] [4.6/4.7 Regression] ICE in get_expr_operands()

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.04.26 08:35:09
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |4.6.1
Summary|ICE in get_expr_operands()  |[4.6/4.7 Regression] ICE in
   ||get_expr_operands()
 Ever Confirmed|0   |1

--- Comment #1 from Jakub Jelinek  2011-04-26 
08:35:09 UTC ---
Smaller testcase for -O -g:

int a, b;

int
bar (void)
{
  int i, j = 1;
  for (i = 0; i != 10; i++)
{
lab:
  if (i)
{
  int *k = &j;
}
  else if (j)
goto lab;
}
  return 1;
}

inline int
foo (int x)
{
  unsigned int c = x;
  int d = x;
  if (bar ())
for (; c; c++)
  while (x >= 0)
if (foo (d) >= 0)
  {
d = bar ();
a = b ? b : 1;
  }
  return 0;
}

Started with http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160124

[Bug rtl-optimization/48757] [4.5/4.6/4.7 Regression] internal compiler error: in compensate_edge, at reg-stack.c:2788

[ubizjak at gmail dot com]

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

Uros Bizjak  changed:

   What|Removed |Added

  Known to work||4.4.7
Summary|internal compiler error: in |[4.5/4.6/4.7 Regression]
   |compensate_edge, at |internal compiler error: in
   |reg-stack.c:2788|compensate_edge, at
   ||reg-stack.c:2788

--- Comment #2 from Uros Bizjak  2011-04-26 08:33:43 
UTC ---
Regression from 4.4.

[Bug libstdc++/48760] [4.6 / 4.7 Regression (?)] std::complex constructor buggy in the face of NaN's

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Guenther  2011-04-26 
08:44:18 UTC ---
(In reply to comment #9)
> I guess, in the 4.6.1 time frame we can only workaround the issue in C++03 
> mode
> by doing the piecewise work in the body. I can maybe help for the compiler 
> work
> too but I need more guidance: is there an agreement about the C1X inspired
> builtin suggested by Joseph? In case, can I have a more specific reference?
> 
> I'm adding in CC Richi too, in case he has additional tips and/or hints about
> the builtin work..

A __builtin_complex builtin should be almost trivial.  It would be purely
frontend sugar for frontends that lack a way to specify a complex value
component-wise.  The frontend would be resposible for lowering it to
a COMPLEX_EXPR.  I don't think the middle-end wants to deal with
__builtin_complex as it already has a perfect matching tree code.

Now I understand C++0x might have a proper syntax already, so I'm not sure
how it relates to this (C++) bug.

What changed in 4.6 is that we put complex values in registers even at -O0.
You should be able to reproduce any issue in this bug in older releases
with optimization turned on (given that the library implementation didn't
change).

[Bug fortran/48588] [4.6/4.7 Regression] ICE (segfault) in gfc_get_nodesc_array_type

[burnus at gcc dot gnu.org]

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

--- Comment #10 from Tobias Burnus  2011-04-26 
08:41:38 UTC ---
Author: burnus
Date: Tue Apr 26 08:41:31 2011
New Revision: 172953

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172953
Log:
2011-04-26  Tobias Burnus  

PR fortran/48588
* parse.c (resolve_all_program_units): Skip modules.
(translate_all_program_units): Handle modules.
(gfc_parse_file): Defer code generation for modules.
* module.c (fix_mio_expr): Commit created symbol.

2011-04-26  Tobias Burnus  

PR fortran/48588
* gfortran.dg/whole_file_33.f90: New.


Added:
branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/whole_file_33.f90
Modified:
branches/gcc-4_6-branch/gcc/fortran/ChangeLog
branches/gcc-4_6-branch/gcc/fortran/module.c
branches/gcc-4_6-branch/gcc/fortran/parse.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug fortran/48588] [4.6/4.7 Regression] ICE (segfault) in gfc_get_nodesc_array_type

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #11 from Tobias Burnus  2011-04-26 
08:42:48 UTC ---
FIXED on the trunk (4.7) and on the 4.6 branch (for 4.6.1).

Thanks for the report Andres!

[Bug lto/48683] [4.7 Regression] 252.eon in SPEC CPU 2000 failed to build

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE

--- Comment #4 from Martin Jambor  2011-04-26 
08:48:25 UTC ---
Looking at our periodic tester results, it seems that it builds now and it
started building at the same time 483.xalancbmk did.  So I believe it indeed
was a duplicate of PR 48585.

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

[Bug tree-optimization/43781] [4.6 Regression] ice: verify_ssa failed

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Guenther  2011-04-26 
08:47:22 UTC ---
I'd say made latent.

[Bug middle-end/48585] [4.7 Regression] 483.xalancbmk in SPEC CPU 2006 failed to build

[jamborm at gcc dot gnu.org]

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

--- Comment #17 from Martin Jambor  2011-04-26 
08:48:25 UTC ---
*** Bug 48683 has been marked as a duplicate of this bug. ***

[Bug debug/48768] [4.6/4.7 Regression] ICE in get_expr_operands()

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |

--- Comment #2 from Jakub Jelinek  2011-04-26 
09:01:42 UTC ---
Created attachment 24100
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24100
gcc46-pr48768.patch

Untested fix.

[Bug tree-optimization/48714] gcc -O hangs gobbling memory, while gcc -O -fno-tree-fre finishes quickly

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||DUPLICATE

--- Comment #3 from Richard Guenther  2011-04-26 
09:20:14 UTC ---
Dup.

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

[Bug tree-optimization/48694] [4.7 Regression] possible memory hog bug

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Guenther  2011-04-26 
09:20:14 UTC ---
*** Bug 48714 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/48694] [4.7 Regression] possible memory hog bug

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Guenther  2011-04-26 
09:21:47 UTC ---
Author: rguenth
Date: Tue Apr 26 09:21:44 2011
New Revision: 172954

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172954
Log:
2011-04-26  Richard Guenther  

PR middle-end/48694
* tree.h (OEP_CONSTANT_ADDRESS_OF): New operand_equal_flag.
* fold-const.c (operand_equal_p): For TREE_CONSTANT ADDR_EXPRs
compare the operands with OEP_CONSTANT_ADDRESS_OF.  Treat
trees with TREE_SIDE_EFFECTS equal when OEP_CONSTANT_ADDRESS_OF
is set.

* gcc.dg/torture/pr48694-1.c: New testcase.
* gcc.dg/torture/pr48694-2.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr48694-1.c
trunk/gcc/testsuite/gcc.dg/torture/pr48694-2.c
Modified:
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree.h

[Bug fortran/48112] [4.6/4.7 Regression] generic interface to external function in module

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus  2011-04-26 
09:18:31 UTC ---
Seems as if the regression has been introduced in by one of the 16 commits
between:
  Working: 2010-05-13-r159362
  Failing: 2010-05-18-r159523

Janus, I have the feeling that it is caused either by Rev. 159506 or by Rev.
159476 (PR 44044); both are your commits. I quickly scanned the commits (all
16) but nothing looked suspicious.

I think, one should start a regression hunt to narrow it down to a single
commit.

[Bug tree-optimization/48694] [4.7 Regression] possible memory hog bug

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #8 from Richard Guenther  2011-04-26 
09:22:01 UTC ---
Fixed.

[Bug target/48767] compiler error: Segmentation fault with set void in va_arg

[kkojima at gcc dot gnu.org]

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

Kazumoto Kojima  changed:

   What|Removed |Added

 Target|sh4-linux-gnu   |sh*-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.04.26 09:26:30
  Component|c   |target
   Host|sh4-linux-gnu   |
 Ever Confirmed|0   |1
  Build|sh4-linux-gnu   |

--- Comment #1 from Kazumoto Kojima  2011-04-26 
09:26:30 UTC ---
This is a target problem.  The patch below will fix it.
BTW, I'm not sure that it's an invalid use of void or not in C,
though g++ treats it as invalid.

   * config/sh/sh.c (sh_gimplify_va_arg_expr): Don't call
   targetm.calls.must_pass_in_stack for void type.

--- ORIG/trunk/gcc/config/sh/sh.c2011-04-23 09:43:19.0 +0900
+++ trunk/gcc/config/sh/sh.c2011-04-26 10:40:25.0 +0900
@@ -8062,9 +8062,14 @@ sh_gimplify_va_arg_expr (tree valist, tr
   HOST_WIDE_INT size, rsize;
   tree tmp, pptr_type_node;
   tree addr, lab_over = NULL, result = NULL;
-  int pass_by_ref = targetm.calls.must_pass_in_stack (TYPE_MODE (type), type);
+  bool pass_by_ref;
   tree eff_type;

+  if (!VOID_TYPE_P (type))
+pass_by_ref = targetm.calls.must_pass_in_stack (TYPE_MODE (type), type);
+  else
+pass_by_ref = false;
+
   if (pass_by_ref)
 type = build_pointer_type (type);

[Bug c/48742] [4.5/4.6/4.7 Regression] Internal error in glimplify_expr

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.04.26 09:39:19
 Ever Confirmed|0   |1

[Bug middle-end/48752] [4.7 Regression] ICE in evaulate_conditions_for_edge at ipa-inline-analysis.c:466

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0

[Bug c++/48749] [4.7 Regression] internal compiler error: tree check: expected field_decl

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

Version|unknown |4.7.0
   Target Milestone|--- |4.7.0

[Bug c/48742] [4.5/4.6/4.7 Regression] Internal error in glimplify_expr

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

  Known to work||4.4.4
   Target Milestone|--- |4.5.4
Summary|Internal error in   |[4.5/4.6/4.7 Regression]
   |glimplify_expr  |Internal error in
   ||glimplify_expr

[Bug rtl-optimization/48757] [4.5/4.6/4.7 Regression] internal compiler error: in compensate_edge, at reg-stack.c:2788

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  2011-04-26 
09:54:14 UTC ---
Started with http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152448

[Bug testsuite/48753] [4.7 Regression] FAIL: gcc.dg/tree-prof/val-prof-2.c

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther  2011-04-26 
10:03:14 UTC ---
Author: rguenth
Date: Tue Apr 26 10:03:12 2011
New Revision: 172955

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172955
Log:
2011-04-26  Richard Guenther  

PR testsuite/48753
* gcc.dg/tree-prof/val-prof-2.c: Adjust.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-prof/val-prof-2.c

[Bug testsuite/48753] [4.7 Regression] FAIL: gcc.dg/tree-prof/val-prof-2.c

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #4 from Richard Guenther  2011-04-26 
10:03:27 UTC ---
Fixed.

[Bug middle-end/48761] Indirect inlining needs to perform type checking

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.04.26 10:05:37
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2011-04-26 
10:05:37 UTC ---
We need to delay this checking to expand_call_inline ().

[Bug preprocessor/48740] Raw C++0x strings and trigraphs mix badly

[jakub at gcc dot gnu.org]

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

--- Comment #16 from Jakub Jelinek  2011-04-26 
10:04:22 UTC ---
Author: jakub
Date: Tue Apr 26 10:04:18 2011
New Revision: 172956

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172956
Log:
2011-04-26  Jakub Jelinek  

Backported from mainline
2011-04-24  Jakub Jelinek  

PR preprocessor/48740
* lex.c (lex_raw_string): When raw string ends with
??) followed by raw prefix and ", ensure it is preprocessed
with ??) rather than ??].

* c-c++-common/raw-string-11.c: New test.

Added:
branches/gcc-4_5-branch/gcc/testsuite/c-c++-common/raw-string-11.c
Modified:
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
branches/gcc-4_5-branch/libcpp/ChangeLog
branches/gcc-4_5-branch/libcpp/lex.c

[Bug libstdc++/48760] [4.6 / 4.7 Regression (?)] std::complex constructor buggy in the face of NaN's

[paolo.carlini at oracle dot com]

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

--- Comment #13 from Paolo Carlini  2011-04-26 
10:03:41 UTC ---
Thanks. Thus, since the original issue boils down to a C++ front-end issue
only, I guess we have to wait for Jason' opinion whether we can avoid adding a
builtin and go the way proposed by Gaby or not. I would really like to see this
fixed for 4.6.1 too, I hope we can figure out something suited, minimally
invasive and/or restricted to the C++0x codepath...

[Bug lto/48763] Inliner type ICE

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.04.26 10:09:29
 Ever Confirmed|0   |1

--- Comment #3 from Richard Guenther  2011-04-26 
10:09:29 UTC ---
Well.  That specific place isn't proper now that the decls can be compatible
but the call stmt can use a different type for calling.

Any checking should extend/factor gimple_check_call_matching_types.

[Bug lto/48763] Inliner type ICE

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther  2011-04-26 
10:08:55 UTC ---
*** Bug 48761 has been marked as a duplicate of this bug. ***

[Bug middle-end/48761] Indirect inlining needs to perform type checking

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE

--- Comment #2 from Richard Guenther  2011-04-26 
10:08:55 UTC ---
dup

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

[Bug tree-optimization/48694] [4.7 Regression] possible memory hog bug

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Guenther  2011-04-26 
10:12:18 UTC ---
Author: rguenth
Date: Tue Apr 26 10:12:14 2011
New Revision: 172957

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172957
Log:
2011-04-26  Richard Guenther  

PR middle-end/48694
* tree.h (OEP_CONSTANT_ADDRESS_OF): New operand_equal_flag.
* fold-const.c (operand_equal_p): For TREE_CONSTANT ADDR_EXPRs
compare the operands with OEP_CONSTANT_ADDRESS_OF.  Treat
trees with TREE_SIDE_EFFECTS equal when OEP_CONSTANT_ADDRESS_OF
is set.

* gcc.dg/torture/pr48694-1.c: New testcase.
* gcc.dg/torture/pr48694-2.c: Likewise.

Modified:
trunk/gcc/ChangeLog

[Bug preprocessor/48248] [4.5 Regression] Wrong error message location when compiling preprocessed code

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Guenther  2011-04-26 
10:14:37 UTC ---
Author: rguenth
Date: Tue Apr 26 10:14:34 2011
New Revision: 172959

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172959
Log:
2011-04-26  Richard Guenther  

PR preprocessor/48248
* c-ppoutput.c (maybe_print_line): Always optimize newlines
for output size with -P.

Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-ppoutput.c

[Bug fortran/48112] [4.6/4.7 Regression] generic interface to external function in module

[burnus at gcc dot gnu.org]

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

--- Comment #4 from Tobias Burnus  2011-04-26 
10:18:23 UTC ---
Rev. 159475 works, Rev. 159476 fails, which is the following commit:

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159476
Log:
2010-05-17  Janus Weil  

PR fortran/44044
* resolve.c (resolve_fl_var_and_proc): Move error messages here from ...
(resolve_fl_variable_derived): ... this place.
(resolve_symbol): Make sure function symbols (and their result
variables) are not resolved twice.


The crucial part of the patch is:

+  /* Avoid double resolution of function result symbols.  */
+  if ((sym->result || sym->attr.result) && (sym->ns != gfc_current_ns))
+return;

 * * *

If one places a break point, one sees first:

(gdb) p sym->name
$5 = 0x2ab40ea8 "test1"
(gdb) p sym->ns->sym_root->name
$8 = 0x2ab40ea8 "test1"
(gdb) p ((sym->result || sym->attr.result) && (sym->ns != gfc_current_ns))
$10 = 0

and then next:

(gdb) p sym->name
$14 = 0x2ab40ea0 "test"
(gdb) p sym->ns->sym_root->name
$15 = 0x2ab40ea0 "test"
(gdb) p gfc_current_ns->sym_root->name
$16 = 0x2ab40ea8 "test1"
And hence:
(gdb) p ((sym->result || sym->attr.result) && (sym->ns != gfc_current_ns))
$17 = 1

and finally:

(gdb) p sym->name
$26 = 0x2ab40ea8 "test1"
(gdb) p sym->ns->sym_root->name
$27 = 0x2ab40ea8 "test1"
(gdb) p gfc_current_ns->sym_root->name
$28 = 0x2ab40ea0 "test"
(gdb) p ((sym->result || sym->attr.result) && (sym->ns != gfc_current_ns))
$25 = 1


Seemingly, the ICE occurs unless both resolutions happen.


(I wonder whether one could use {sym->ns,gfc_current_namespace}->resolved to
decide whether one should continue or not; currently, one finds the values "-1"
and "0".)

[Bug middle-end/48770] New: [4.7 Regression] wrong code with -O -fprofile-arcs -fPIC -fno-dce -fno-forward-propagate -fno-tree-forwprop

[zsojka at seznam dot cz]

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

   Summary: [4.7 Regression] wrong code with -O -fprofile-arcs
-fPIC -fno-dce -fno-forward-propagate
-fno-tree-forwprop
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


Created attachment 24101
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24101
reduced testcase (from g++.dg/bprob/g++-bprob-1.C)

Compiler output:
$ rm *.gcda
$ g++ -O -fprofile-arcs -fPIC -fno-dce -fno-forward-propagate
-fno-tree-forwprop testcase.C
$ valgrind -q ./a.out
==5350== Invalid read of size 8
==5350==at 0x400D51: test_goto2(int) (testcase.C:10)
==5350==by 0x400D7E: main (testcase.C:14)
==5350==  Address 0x8 is not stack'd, malloc'd or (recently) free'd
Segmentation fault

Fails only when compiled as C++ code.

Tested revisions:
r172940 - fail
4.6 r172337 - OK

[Bug preprocessor/48740] Raw C++0x strings and trigraphs mix badly

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #17 from Jakub Jelinek  2011-04-26 
10:39:43 UTC ---
Fixed.

[Bug tree-optimization/48764] [4.5/4.6/4.7 Regression] wrong-code bug in gcc-4.5.x, related to __restrict

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
  Known to work||4.4.4, 4.6.0
   Keywords||wrong-code
   Last reconfirmed||2011.04.26 10:43:12
 Ever Confirmed|0   |1
Summary|wrong-code bug in   |[4.5/4.6/4.7 Regression]
   |gcc-4.5.x, related to   |wrong-code bug in
   |__restrict  |gcc-4.5.x, related to
   ||__restrict
   Target Milestone|--- |4.5.4
  Known to fail||4.5.2

--- Comment #1 from Richard Guenther  2011-04-26 
10:43:12 UTC ---
The bug is that we somehow think after inlining

void FooBar::load(Loader&) (struct FooBar * const this, struct Loader & l)
{
...
:
  D.3062_2 = &this_1(D)->c1;
  D.3079_9 = &l_3(D)->buffer;
  this_11 = (struct Buffer * const restrict) D.3079_9;
  D.3083_12 = this_11->p;
  memcpy (D.3062_2, D.3083_12, 1);
  D.3083_13 = this_11->p;
  D.3082_14 = D.3083_13 + 1;
  this_11->p = D.3082_14;
  D.3063_4 = &this_1(D)->c2;
  D.3064_5 = &l_3(D)->D.2415;
  self_15 = (struct Loader &) D.3064_5;
  D.3087_16 = &self_15->buffer;
  this_17 = (struct Buffer * const restrict) D.3087_16;
  D.3091_18 = this_17->p;
  memcpy (D.3063_4, D.3091_18, 1);
  D.3091_19 = this_17->p;
  D.3090_20 = D.3091_19 + 1;
  this_17->p = D.3090_20;
  return;

this_11 and this_17 only point to (different) objects.  The restrict
machinery should be robust against inlining effects because it should
inherhit the arguments points-to set as well.  In this case we have

l_3(D), points-to non-local, points-to vars: { }
self_15, points-to non-local, points-to vars: { }

though, and we explicitly ignore those:

  /* If both pointers are restrict-qualified try to disambiguate
 with restrict information.  */
  if (TYPE_RESTRICT (TREE_TYPE (ptr1))
  && TYPE_RESTRICT (TREE_TYPE (ptr2))
  && !pt_solutions_same_restrict_base (&pi1->pt, &pi2->pt))
return false;


/* Return true if both points-to solutions PT1 and PT2 for two restrict
   qualified pointers are possibly based on the same pointer.  */

bool
pt_solutions_same_restrict_base (struct pt_solution *pt1,
 struct pt_solution *pt2)
{
  /* If we deal with points-to solutions of two restrict qualified
 pointers solely rely on the pointed-to variable bitmap intersection.
 For two pointers that are based on each other the bitmaps will
 intersect.  */
  if (pt1->vars_contains_restrict
  && pt2->vars_contains_restrict)
{
  gcc_assert (pt1->vars && pt2->vars);
  return bitmap_intersect_p (pt1->vars, pt2->vars);
}

  return true;
}

because all incoming restrict qualified pointers also point to NONLOCAL
(so restrict would be useless if we don't ignore that fact).

4.4 handles restrict in a completely different way.

4.6 and 4.7 manage to make more must-aliasing appearant which avoids
this issue to manifest in a miscompilation, but the issue itself is
latent.

[Bug c/48742] [4.5/4.6/4.7 Regression] Internal error in glimplify_expr

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  2011-04-26 
11:03:50 UTC ---
Shorter testcase:

int
foo (void)
{
  return 1 / 0 > 0;
}

Started with http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145254
C_MAYBE_CONST_EXPR leaking to gimplification.

[Bug tree-optimization/48764] [4.5/4.6/4.7 Regression] wrong-code bug in gcc-4.5.x, related to __restrict

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther  2011-04-26 
11:17:59 UTC ---
The following fixes it (partially, global vars need similar treatment) at the
cost of extra decls and points-to bits.
We have to give what we point to a name, not only rely in the nonlocal glob.

Index: gcc/tree-ssa-structalias.c
===
--- gcc/tree-ssa-structalias.c  (revision 172817)
+++ gcc/tree-ssa-structalias.c  (working copy)
@@ -4727,8 +4727,27 @@ intra_create_variable_infos (void)
}

   for (p = get_vi_for_tree (t); p; p = p->next)
-   if (p->may_have_pointers)
- make_constraint_from (p, nonlocal_id);
+   {
+ if (p->may_have_pointers)
+   {
+ struct constraint_expr lhsc, rhsc;
+ tree heapvar;
+ heapvar = create_tmp_var_raw (TREE_TYPE (TREE_TYPE (t)),
+   "PARM_PT");
+ DECL_EXTERNAL (heapvar) = 1;
+ get_var_ann (heapvar)->is_heapvar = 1;
+ add_referenced_var (heapvar);
+ lhsc.var = p->id;
+ lhsc.type = SCALAR;
+ lhsc.offset = 0;
+ rhsc.var = get_vi_for_tree (heapvar)->id;
+ rhsc.type = ADDRESSOF;
+ rhsc.offset = 0;
+ process_constraint (new_constraint (lhsc, rhsc));
+
+ make_constraint_from (p, nonlocal_id);
+   }
+   }
   if (POINTER_TYPE_P (TREE_TYPE (t))
  && TYPE_RESTRICT (TREE_TYPE (t)))
make_constraint_from_restrict (get_vi_for_tree (t), "PARM_RESTRICT");

it would be nice if we could avoid allocating decls for such things
(in principle we could simply allocate a DECL_UID only).

[Bug c/48742] [4.5/4.6/4.7 Regression] Internal error in glimplify_expr

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jsm28 at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  2011-04-26 
11:27:10 UTC ---
The problem is that first build_binary_op wraps 1 / 0 into C_MAYBE_CONST_EXPR,
  if (!in_late_binary_op)
{
  if (!op0_maybe_const || TREE_CODE (op0) != INTEGER_CST)
op0 = c_wrap_maybe_const (op0, !op0_maybe_const);
  if (!op1_maybe_const || TREE_CODE (op1) != INTEGER_CST)
op1 = c_wrap_maybe_const (op1, !op1_maybe_const);
}
and later on the whole GT_EXPR with C_MAYBE_CONST_EXPR op0 and INTEGER_CST op1
is wrapped in yet another C_MAYBE_CONST_EXPR:
  else if (TREE_CODE (ret) != INTEGER_CST && int_operands
   && !in_late_binary_op)
ret = note_integer_operands (ret);
Apparently, c_fully_fold_internal doesn't handle nested C_MAYBE_CONST_EXPRs
though, if it finds one, it doesn't recurse on the content and just returns it.

Joseph?

[Bug tree-optimization/48766] [4.3/4.4/4.5/4.6/4.7 Regression] Infinite recursion in fold_binary_loc()

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||4.1.2
   Keywords||ice-on-valid-code
   Last reconfirmed||2011.04.26 11:29:36
 Ever Confirmed|0   |1
Summary|Infinite recursion in   |[4.3/4.4/4.5/4.6/4.7
   |fold_binary_loc()   |Regression] Infinite
   ||recursion in
   ||fold_binary_loc()
   Target Milestone|--- |4.3.6
  Known to fail||4.3.4

--- Comment #1 from Richard Guenther  2011-04-26 
11:29:36 UTC ---
Confirmed.

[Bug target/42210] avr: optimizing assignment to a bit field

[gjl at gcc dot gnu.org]

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

--- Comment #2 from Georg-Johann Lay  2011-04-26 
11:35:23 UTC ---
Created attachment 24102
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24102
extended testcase

Added testcase with some more variations of "setting bits in I/O" theme.

[Bug debug/48768] [4.6/4.7 Regression] ICE in get_expr_operands()

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther  2011-04-26 
11:35:01 UTC ---
Ugh.  Well, ok I suppose.

[Bug target/48769] [4.7 Regression] Multiple failures in libjava for -m64 on powerpc-apple-darwin9

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0

[Bug tree-optimization/48732] Nested loops with small iteration count gobble time in "tree reassociation"

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther  2011-04-26 
12:13:50 UTC ---
With -O1 we do not perform expensive control-dependend DCE and thus do not
end up removing the empty loops.  We do however remove the dead store in
the innermost loop which then causes us to compute that completely unrolling
all loops is profitable (we basically see it's all dead code that will be
produced).  Now, unfortunately before removing all that dead code we perform
re-association on the induction variable increment chains ... of which there
are a lot (8 ^ n ones and more, actually).

We've known for quite some time that not doing constant propagation and
dead code elimination on the unrolled loop bodies isn't the best idea
(induction variable analysis is also pessimized by not doing CSE on those).

The only CCP-like pass after loop opts is VRP which does not run at -O2,
or DOM and both runs after re-assoc (though I don't see a particularly good
reason for that fact).

Scheduling DOM right after loop opts "fixes" this.  But a more proper fix
would be to do cleanups closer to unrolling.

[Bug tree-optimization/48734] [4.6/4.7 Regression] ICE in eliminate_redundant_comparison, at tree-ssa-reassoc.c:1321

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Guenther  2011-04-26 
12:15:13 UTC ---
Looks good to me.

[Bug middle-end/48770] [4.7 Regression] wrong code with -O -fprofile-arcs -fPIC -fno-dce -fno-forward-propagate -fno-tree-forwprop

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0

[Bug lto/48763] Inliner type ICE

[hubicka at gcc dot gnu.org]

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

--- Comment #4 from Jan Hubicka  2011-04-26 
12:56:30 UTC ---
I would say that PR48761 testcase is not 100% dup of this one.  One tests that
cgraph merging check type compatibility of direct call edges, the second tests
that ipa-prop does type compatibility check when turing indirect edge to
direct.

I guess only way to go is to stomp call expression types to the callgraph
edges. Doable, but ugly since it will add need to store types into callgraph
sections that are currently simple blocks. Or to make inliner and ipa-prop to
handle all cases, even those not type compatible, right?

This is not really my area, so I would hope someone to beat me on this problem
:))

[Bug c/48731] regression: __attribute__((flatten)) produces error with function calling variadic functions

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther  2011-04-26 
12:59:33 UTC ---
Author: rguenth
Date: Tue Apr 26 12:59:22 2011
New Revision: 172963

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172963
Log:
2011-04-26  Richard Guenther  

PR tree-optimization/48731
* ipa-inline.c (cgraph_flatten): Test if function is inlinable.

* gcc.dg/torture/pr48731.c: New testcase.

Added:
branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/torture/pr48731.c
Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/ipa-inline.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug c/48731] regression: __attribute__((flatten)) produces error with function calling variadic functions

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther  2011-04-26 
13:00:58 UTC ---
Author: rguenth
Date: Tue Apr 26 13:00:53 2011
New Revision: 172964

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172964
Log:
2011-04-26  Richard Guenther  

PR tree-optimization/48731
* gcc.dg/torture/pr48731.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr48731.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/48752] [4.7 Regression] ICE in evaulate_conditions_for_edge at ipa-inline-analysis.c:466

[hubicka at ucw dot cz]

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

--- Comment #9 from Jan Hubicka  2011-04-26 13:06:08 UTC 
---
> Looks like the issue is somehow caused by caller being a global
> constructor.

Hmm, yes, it is entirely possible - when new functions are added, we need to
analyze them.
I tought it is happening now, but it is not.  I will check it.

Honza

[Bug lto/48763] Inliner type ICE

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Guenther  2011-04-26 
13:05:32 UTC ---
(In reply to comment #4)
> I would say that PR48761 testcase is not 100% dup of this one.  One tests that
> cgraph merging check type compatibility of direct call edges, the second tests
> that ipa-prop does type compatibility check when turing indirect edge to
> direct.

The issue is the same, it will manifest in all IPA passes, with and without
LTO now that we happily create direct calls from originally mismatching
indirect
calls.

> I guess only way to go is to stomp call expression types to the callgraph
> edges. Doable, but ugly since it will add need to store types into callgraph
> sections that are currently simple blocks. Or to make inliner and ipa-prop to
> handle all cases, even those not type compatible, right?
> 
> This is not really my area, so I would hope someone to beat me on this problem
> :))

We should defer detection of incompatibilities to when we see the call stmt,
thus expand_call_inline.  We shouldn't worry about this disturbing inliner
heuristics too much.  IPA optimizations should do propagation as-if things
match, deal with missing arguments (or missing arg slots) properly by
giving up and do the same checking when applying a transform.

I don't think trying to move more information to WPA stages on the edges
is the way to go.

[Bug c/48731] regression: __attribute__((flatten)) produces error with function calling variadic functions

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Guenther  2011-04-26 
13:01:55 UTC ---
Fixed.

[Bug testsuite/48753] [4.7 Regression] FAIL: gcc.dg/tree-prof/val-prof-2.c

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |

--- Comment #5 from H.J. Lu  2011-04-26 13:17:23 
UTC ---
On Linux/ia32, revision 172962 gave

FAIL: gcc.dg/tree-prof/val-prof-2.c scan-tree-dump optimized "n_[0-9]* \+
4294967295"

[Bug lto/48763] Inliner type ICE

[hubicka at ucw dot cz]

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

--- Comment #6 from Jan Hubicka  2011-04-26 13:20:24 UTC 
---
> We should defer detection of incompatibilities to when we see the call stmt,
> thus expand_call_inline.  We shouldn't worry about this disturbing inliner

Undoing the inliner decisions at expand_call_inline is not trivial.

1) We would have to turn inline clone back to offline copy of the
function if one doesn't exist.
2) Doing so would resoult in duplicated offline copies of function when such
copy really exist but WPA made it static and put into a different partition.
3) With the inliner analysis being able to figure out what references and
calls will be optimized out in particular inline clone based on knowledge of
its argument, there is no way to output those references (they might refer
things not exported from different WPA partitions).
So the offline clone would have to be clone with the constants figured out by
the inliner propagated in.

I am not sure if those are all problems, but I guess we can go this way,
but it is remarkably ugly.

Also we need smilar kind of validation for ipa-prop.  Jump functions will
get confused on calls with mismatching types. This would mean that the constant
propagation trick above might fail making things even more messy (ie.
propagating
constant into a structure argument or so).

Honza

[Bug tree-optimization/48766] [4.3/4.4/4.5/4.6/4.7 Regression] Infinite recursion in fold_binary_loc()

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||iant at google dot com

--- Comment #2 from H.J. Lu  2011-04-26 13:26:19 
UTC ---
It is caused by revision 121254:

http://gcc.gnu.org/ml/gcc-cvs/2007-01/msg00960.html

which adds -fstrict-overflow.

[Bug testsuite/48753] [4.7 Regression] FAIL: gcc.dg/tree-prof/val-prof-2.c

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  2011-04-26 
13:31:21 UTC ---
Author: jakub
Date: Tue Apr 26 13:31:17 2011
New Revision: 172966

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172966
Log:
PR testsuite/48753
* gcc.dg/tree-prof/val-prof-2.c: Adjust for 32-bit HWI.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-prof/val-prof-2.c

[Bug debug/48768] [4.6/4.7 Regression] ICE in get_expr_operands()

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  2011-04-26 
13:35:24 UTC ---
Author: jakub
Date: Tue Apr 26 13:35:21 2011
New Revision: 172968

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172968
Log:
PR debug/48768
* tree-ssa.c (insert_debug_temp_for_var_def): If degenerate_phi_result
is error_mark_node, set value to NULL.

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

Added:
trunk/gcc/testsuite/gcc.dg/pr48768.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa.c

[Bug fortran/48279] [4.6/4.7 Regression] segfault in gfc_check_vardef_context

[burnus at gcc dot gnu.org]

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

--- Comment #9 from Tobias Burnus  2011-04-26 
13:36:50 UTC ---
Works with: 2010-09-28-r164677

[Bug tree-optimization/48734] [4.6/4.7 Regression] ICE in eliminate_redundant_comparison, at tree-ssa-reassoc.c:1321

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  2011-04-26 
13:33:55 UTC ---
Author: jakub
Date: Tue Apr 26 13:33:49 2011
New Revision: 172967

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172967
Log:
PR tree-optimization/48734
* tree-ssa-reassoc.c (eliminate_redundant_comparison): Give up
if return value from maybe_fold_*_comparsions isn't something
the code is prepared to handle.

* gcc.c-torture/compile/pr48734.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr48734.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-reassoc.c

[Bug testsuite/48753] [4.7 Regression] FAIL: gcc.dg/tree-prof/val-prof-2.c

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution||FIXED

--- Comment #7 from Jakub Jelinek  2011-04-26 
13:40:05 UTC ---
Fixed.

[Bug tree-optimization/48734] [4.6/4.7 Regression] ICE in eliminate_redundant_comparison, at tree-ssa-reassoc.c:1321

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  2011-04-26 
13:44:54 UTC ---
Author: jakub
Date: Tue Apr 26 13:44:51 2011
New Revision: 172969

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172969
Log:
PR tree-optimization/48734
* tree-ssa-reassoc.c (eliminate_redundant_comparison): Give up
if return value from maybe_fold_*_comparsions isn't something
the code is prepared to handle.

* gcc.c-torture/compile/pr48734.c: New test.

Added:
branches/gcc-4_6-branch/gcc/testsuite/gcc.c-torture/compile/pr48734.c
Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
branches/gcc-4_6-branch/gcc/tree-ssa-reassoc.c

[Bug debug/48768] [4.6/4.7 Regression] ICE in get_expr_operands()

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #6 from Jakub Jelinek  2011-04-26 
13:48:46 UTC ---
Fixed.

[Bug tree-optimization/48734] [4.6/4.7 Regression] ICE in eliminate_redundant_comparison, at tree-ssa-reassoc.c:1321

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #7 from Jakub Jelinek  2011-04-26 
13:48:10 UTC ---
Fixed.

[Bug libstdc++/48771] New: [C++0x] is_literal_type incorrect for references to non-literal types

[daniel.kruegler at googlemail dot com]

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

   Summary: [C++0x] is_literal_type incorrect for references to
non-literal types
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.krueg...@googlemail.com


gcc 4.7.0 20110423 (experimental) in C++0x mode rejects the following code:

//---
#include 

struct NonLiteral {
  NonLiteral();
  ~NonLiteral();
};

static_assert(std::is_literal_type::value, "Error"); // #1
static_assert(std::is_literal_type::value, "Error"); // #2
//---

because both assertions fire. This code should be accepted, because as of the
FDIS all reference types are literal types (similar to pointers).

[Bug fortran/48112] [4.6/4.7 Regression] generic interface to external function in module

[burnus at gcc dot gnu.org]

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

--- Comment #5 from Tobias Burnus  2011-04-26 
13:50:53 UTC ---
(In reply to comment #4)
> The crucial part of the patch is:
> +  /* Avoid double resolution of function result symbols.  */
> +  if ((sym->result || sym->attr.result) && (sym->ns != gfc_current_ns))
> +return;

If one backs out that part, one gets the diagnostic messages twice for
class_20.f03 - which was a general issue, unrelated to BT_CLASS.

 * * *

A variant combining both issues (this PR and class_20.f03) is:

module module_m
  type t
  end type t
  interface test
 function test1( )  result( test )
   import
   class(t) ::  test
 end function test1
  end interface test
end module module_m

For that program, only one error should be printed - and no ICE in module
writing ...

 * * *

Draft patch; note that resolve_fl_var_and_proc is *only* about diagnostics:

--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -9888,0 +9889,5 @@ resolve_fl_var_and_proc (gfc_symbol *sym, int mp_flag)
+  /* Avoid double diagnostics of function result symbols.  */
+  if ((sym->result || sym->attr.result) && !sym->attr.dummy
+  && (sym->ns != gfc_current_ns))
+return SUCCESS;
+
@@ -11977,5 +11981,0 @@ resolve_symbol (gfc_symbol *sym)
-  /* Avoid double resolution of function result symbols.  */
-  if ((sym->result || sym->attr.result) && !sym->attr.dummy
-  && (sym->ns != gfc_current_ns))
-return;

[Bug debug/48768] [4.6/4.7 Regression] ICE in get_expr_operands()

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  2011-04-26 
13:47:17 UTC ---
Author: jakub
Date: Tue Apr 26 13:47:13 2011
New Revision: 172970

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172970
Log:
PR debug/48768
* tree-ssa.c (insert_debug_temp_for_var_def): If degenerate_phi_result
is error_mark_node, set value to NULL.

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

Added:
branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/pr48768.c
Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
branches/gcc-4_6-branch/gcc/tree-ssa.c

[Bug fortran/45586] [4.6/4.7 Regression] ICE non-trivial conversion at assignment

[burnus at gcc dot gnu.org]

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

--- Comment #54 from Tobias Burnus  2011-04-26 
14:07:03 UTC ---
(In reply to comment #53)
> reduced testcase for 4.7

Does not fail here - can you still reproduce it? (It might have been fixed by
the patch for PR 48588. If it still occurs, I will try harder.)

[Bug c++/48771] [C++0x] is_literal_type incorrect for references to non-literal types

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.04.26 14:10:31
 CC||jason at gcc dot gnu.org
  Component|libstdc++   |c++
 Ever Confirmed|0   |1

--- Comment #1 from Paolo Carlini  2011-04-26 
14:10:31 UTC ---
This is really a C++ front-end issue, not a library issue, because it just
boils down to __is_literal_type and in turn to the internal literal_type_p,
which apparently should be updated to reflect the FDIS concept.

[Bug libstdc++/48760] [4.6 / 4.7 Regression (?)] std::complex constructor buggy in the face of NaN's

[gdr at gcc dot gnu.org]

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

--- Comment #14 from Gabriel Dos Reis  2011-04-26 
14:12:35 UTC ---
(In reply to comment #12)
> (In reply to comment #9)
> > I guess, in the 4.6.1 time frame we can only workaround the issue in C++03 
> > mode
> > by doing the piecewise work in the body. I can maybe help for the compiler 
> > work
> > too but I need more guidance: is there an agreement about the C1X inspired
> > builtin suggested by Joseph? In case, can I have a more specific reference?
> > 
> > I'm adding in CC Richi too, in case he has additional tips and/or hints 
> > about
> > the builtin work..
> 
> A __builtin_complex builtin should be almost trivial.  It would be purely
> frontend sugar for frontends that lack a way to specify a complex value
> component-wise.  The frontend would be resposible for lowering it to
> a COMPLEX_EXPR.  I don't think the middle-end wants to deal with
> __builtin_complex as it already has a perfect matching tree code.

Agreed -- except since __builtin_complex is already a perfect match, 
the front-end should just accept either

 _M_value{r,i}

or

_M_value(r,i)

if it wanted to be C++03 compatible too.  Either way, you say, there
is no need to involve the middle end.


> 
> Now I understand C++0x might have a proper syntax already, so I'm not sure
> how it relates to this (C++) bug.
> 
> What changed in 4.6 is that we put complex values in registers even at -O0.

that is fine (and appreciated!).  It is unrelated to the bug though.

> You should be able to reproduce any issue in this bug in older releases
> with optimization turned on (given that the library implementation didn't
> change).

The bug is a source-level bug; the source code is written that way because
we don't have yet a good way to initialize at once GCC builtin COMPLEX_EXPR.

-- Gaby

[Bug libstdc++/48760] [4.6 / 4.7 Regression (?)] std::complex constructor buggy in the face of NaN's

[joseph at codesourcery dot com]

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

--- Comment #15 from joseph at codesourcery dot com  2011-04-26 14:30:50 UTC ---
On Mon, 25 Apr 2011, john at johnmaddock dot co.uk wrote:

> Sorry to be dumb, but doesn't the result of the C code violate section G.5.2 
> in
> C99 - which is to say that no matter what the value of the imaginary part of 
> an
> expression, it never changes the real part - even if that is a NaN?

I can't make any sense of that sentence - what is the "it" you are saying 
is changing a real part but shouldn't be?

In NaN * 1.0fi, the first operand is real and the second is complex (*not* 
imaginary, GCC doesn't have imaginary types), so the real part of the 
result is NaN*0 which is NaN and the imaginary part is NaN*1 which is also 
NaN.  Adding 0 then results in a real part of 0+NaN, which is NaN, and an 
imaginary part of NaN.  This is in accordance with how mixed real/complex 
arithmetic works in C99 - implemented for C in 4.5 and I think for C++ in 
4.6 (with associated removal of bogus optimizations that tried to treat 
values of complex type as being real or imaginary values if one part was 
zero).

The built-in function semantics would be those of CMPLXF, CMPLX and CMPLXL 
in 7.3.9.3 in the C1X DIS (N1569).

[Bug c++/48771] [C++0x] is_literal_type incorrect for references to non-literal types

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||paolo.carlini at oracle dot
   ||com

--- Comment #2 from Paolo Carlini  2011-04-26 
14:39:36 UTC ---
The below patchlet fixes the problem and passes the testsuite.

Jason, let me know if you consider it safe, for 4_6-branch too, in case.

Paolo.

//

Index: testsuite/g++.dg/ext/is_literal_type1.C
===
--- testsuite/g++.dg/ext/is_literal_type1.C(revision 0)
+++ testsuite/g++.dg/ext/is_literal_type1.C(revision 0)
@@ -0,0 +1,11 @@
+// PR c++/48771
+// { dg-do compile }
+// { dg-options "-std=c++0x" }
+
+struct NonLiteral {
+  NonLiteral();
+  ~NonLiteral();
+};
+
+static_assert(__is_literal_type(NonLiteral&), "Error");
+static_assert(__is_literal_type(NonLiteral&&), "Error");
Index: cp/semantics.c
===
--- cp/semantics.c(revision 172961)
+++ cp/semantics.c(working copy)
@@ -5331,7 +5331,8 @@ float_const_decimal64_p (void)
 bool
 literal_type_p (tree t)
 {
-  if (SCALAR_TYPE_P (t))
+  if (SCALAR_TYPE_P (t)
+  || TREE_CODE (t) == REFERENCE_TYPE)
 return true;
   if (CLASS_TYPE_P (t))
 return CLASSTYPE_LITERAL_P (t);

[Bug tree-optimization/48772] New: [4.7 Regression] ICE: SIGSEGV in walk_non_aliased_vuses (gimple.h:1100) with -O -fnon-call-exceptions -fno-tree-ccp -fno-tree-dce

[zsojka at seznam dot cz]

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

   Summary: [4.7 Regression] ICE: SIGSEGV in
walk_non_aliased_vuses (gimple.h:1100) with -O
-fnon-call-exceptions -fno-tree-ccp -fno-tree-dce
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


Created attachment 24103
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24103
reduced testcase (from g++.dg/torture/pr44535.C)

Compiler output:
$ gcc -O -fnon-call-exceptions -fno-tree-ccp -fno-tree-dce testcase.C
==25341== Invalid read of size 1
==25341==at 0xB0BE03: walk_non_aliased_vuses (gimple.h:1100)
==25341==by 0xB80E8C: vn_reference_lookup (tree-ssa-sccvn.c:1697)
==25341==by 0xB6DD99: eliminate (tree-ssa-pre.c:4341)
==25341==by 0xB7103D: execute_pre (tree-ssa-pre.c:4921)
==25341==by 0x984C55: execute_one_pass (passes.c:1555)
==25341==by 0x984F34: execute_pass_list (passes.c:1610)
==25341==by 0x984F46: execute_pass_list (passes.c:1611)
==25341==by 0xACCBAA: tree_rest_of_compilation (tree-optimize.c:423)
==25341==by 0xCAFB42: cgraph_expand_function (cgraphunit.c:1576)
==25341==by 0xCB205B: cgraph_optimize (cgraphunit.c:1635)
==25341==by 0xCB25E9: cgraph_finalize_compilation_unit (cgraphunit.c:1096)
==25341==by 0x5BD42D: cp_write_global_declarations (decl2.c:4002)
==25341==by 0xA71A87: toplev_main (toplev.c:591)
==25341==by 0x644AB6C: (below main) (in /lib64/libc-2.11.3.so)
==25341==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==25341== 
testcase.C: In function 'int main()':
testcase.C:26:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug c/48742] [4.5/4.6/4.7 Regression] Internal error in glimplify_expr

[joseph at codesourcery dot com]

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

--- Comment #3 from joseph at codesourcery dot com  2011-04-26 14:50:47 UTC ---
There shouldn't be nested C_MAYBE_CONST_EXPR.  The code you quote

>   if (!in_late_binary_op)
> {
>   if (!op0_maybe_const || TREE_CODE (op0) != INTEGER_CST)
> op0 = c_wrap_maybe_const (op0, !op0_maybe_const);
>   if (!op1_maybe_const || TREE_CODE (op1) != INTEGER_CST)
> op1 = c_wrap_maybe_const (op1, !op1_maybe_const);
> }

is to avoid the result of folding getting folded again and to track how 
constant that result is.  But if int_operands I don't think this wrapping 
of the operands is needed because the code after return_build_binary_op: 
will deal with wrapping the result.

[Bug libstdc++/48760] [4.6 / 4.7 Regression (?)] std::complex constructor buggy in the face of NaN's

[paolo.carlini at oracle dot com]

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

--- Comment #16 from Paolo Carlini  2011-04-26 
14:54:12 UTC ---
Thanks Joseph for the explanation and the references. Now maybe I'm digressing
in terms of the C++ issue we are facing, but I'm wondering: at some point, even
for C99, shouldn't we support imaginary types?

[Bug middle-end/48770] [4.7 Regression] wrong code with -O -fprofile-arcs -fPIC -fno-dce -fno-forward-propagate -fno-tree-forwprop

[zsojka at seznam dot cz]

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

--- Comment #1 from Zdenek Sojka  2011-04-26 14:57:08 
UTC ---
(gdb) disassemble
...
   0x00400d06 <+18>:addq   $0x1,(%rax)
   0x00400d0a <+22>:mov$0x8,%eax
   0x00400d0f <+27>:test   %edi,%edi
   0x00400d11 <+29>:jne0x400d51 
...
   0x00400d50 <+92>:retq   
=> 0x00400d51 <+93>:mov(%rax),%rcx
   0x00400d54 <+96>:add$0x1,%rcx
   0x00400d58 <+100>:   mov0x202461(%rip),%rdx# 0x6031c0
   0x00400d5f <+107>:   mov$0x1,%eax
   0x00400d64 <+112>:   jmp0x400d15 

In the asm output, the problem is apparent (comparing trunk and 4.6 output) -
the only difference is:
73,75c73,76
<   mov rcx, QWORD PTR [rax]# *.LPBX1_I_lsm.7, *.LPBX1
<   add rcx, 1  # *.LPBX1_I_lsm.7,
<   mov rdx, QWORD PTR .LPBX1[rip+32]   # *.LPBX1_I_lsm.6, *.LPBX1
---
>   lea rax, .LPBX1[rip+24] # tmp113,
>   mov rcx, QWORD PTR [rax]# *.LPBX1, *.LPBX1
>   add rcx, 1  # *.LPBX1_I_lsm.4,
>   mov rdx, QWORD PTR .LPBX1[rip+32]   # *.LPBX1_I_lsm.3, *.LPBX1

Instruction "lea" is missing, and rax contains value 8.

[Bug rtl-optimization/48773] New: Dataflow and REG_DEAD notes

[mfortune at gmail dot com]

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

   Summary: Dataflow and REG_DEAD notes
   Product: gcc
   Version: 4.3.5
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mfort...@gmail.com


Hello all,

I have recently been updating an out of tree target from GCC 4.2.4 to GCC 4.3.5
and have noticed that REG_DEAD notes can get out of sync at the end of multiple
passes. (i.e. be attached to instructions where the register does not die)

The first pass that appears to get REG_DEAD notes out of sync is GCSE. This
gets fixed and broken multiple times as some of the later passes solve the DF
note problem via df_analyze, some delete all notes and some get the notes out
of sync again. When the second schedule pass (sched2) runs the DF note problem
is solved at the start but then instructions can be re-ordered and notes are
once again left out of sync. In my case this causes (an admittedly old)
peephole to be applied incorrectly and bad code is generated. 

It seems to be that each pass, which may get notes out of sync, should run the
note problem before finishing.

With some experimentation I have seen that running df_analyze to solve the note
problem at the end of some passes leads to an apparent improvement in the code.
 It would therefore seem that some passes use REG_DEAD information without
first solving the REG_DEAD problem. This sounds reasonable as I would expect
each pass to end leaving notes valid.

Is the behaviour I have described here intentional? If so, could someone
explain the rationale? I can't see any changes in this area (up to trunk) and I
have seen REG_DEAD notes get out of sync with at least one in-tree target for
which I could provide a testcase if that is useful (GCC 4.5.1). This issue is
quite general though so I believe a large amount of code should trigger the
notes to get out of sync. This clearly does not lead to actual bugs in most
cases otherwise it would have already been reported.

regards,
Matthew

[Bug libstdc++/48760] [4.6 / 4.7 Regression (?)] std::complex constructor buggy in the face of NaN's

[joseph at codesourcery dot com]

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

--- Comment #17 from joseph at codesourcery dot com  2011-04-26 15:03:49 UTC ---
As far as I can see, the main (only?) use of imaginary types is for this 
issue of constructing complex values.  In addition, you need to define for 
each target the ABI for argument passing and return of imaginary types 
(and in particular how _Imaginary float is passed in variable arguments - 
it is *not* promoted to _Imaginary double, whereas float is promoted to 
double in variable arguments at the C language level before the ABI comes 
into play, so whereas targets don't need to allow for unpromoted float in 
variable arguments they do need to allow for unpromoted _Imaginary float).  
But, given that, it would indeed be nice to support imaginary types.

[Bug tree-optimization/48772] [4.7 Regression] ICE: SIGSEGV in walk_non_aliased_vuses (gimple.h:1100) with -O -fnon-call-exceptions -fno-tree-ccp -fno-tree-dce

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.04.26 15:09:22
 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org
   |gnu.org |
   Target Milestone|--- |4.7.0
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2011-04-26 
15:09:22 UTC ---
Mine.

We are destroying the virtual operand web as it was present during
value-numbering
by updating stmts during elimination.  In this case by updating a call stmt
that was promoted from an indirect virtual call to a direct call.

[Bug rtl-optimization/38644] [4.3/4.4/4.5/4.6/4.7 Regression] Optimization flag -O1 -fschedule-insns2 causes wrong code

[jiangning.liu at arm dot com]

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

Jiangning Liu  changed:

   What|Removed |Added

 CC||jiangning.liu at arm dot
   ||com

--- Comment #35 from Jiangning Liu  2011-04-26 
15:13:41 UTC ---
I verified that two patches in #38644 (back end) and #30282 (middle end) both
work for attached cases. Here comes my two cents,

1) The concept of red zone is to control whether instructions can write memory
below current stack frame or not, and it is only being supported by ABIs for
some particular ISAs, so it shouldn't be enabled in middle end by default for
all targets. At this point, middle end should be fixed to avoid doing things
unwanted in general for all targets.

2) Red zone is an orthogonal concept to prologue/epilogue, so it is not good to
fix this issue in prologue/epilogue back end code. At this point, we shouldn't
simply fix it in back end by adding barrier to implicitly disable red zone.
Instead, some hooks should be abstracted in middle end to support it in
scheduling dependence (middle end code). Back end like X86-64 should enable it
through hooks by itself. 

The key here is red zone should be a clean feature to be supported in middle
end. Exposing this kind of stuff to back end through hooks can improve code
quality for middle end and avoid bringing the bugs to back-end. 

This bug has long history, and it is being now or has ever been exposed on ARM,
POWER and X86(with some options combination). Fixing it in middle end is not
only a bug fix, but a simple infrastructure improvement. Due to the long
duration and the extensive impact for different targets, I don't see good
reason of not fixing it in mainline ASAP.

[Bug c/48742] [4.5/4.6/4.7 Regression] Internal error in glimplify_expr

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  2011-04-26 
15:16:05 UTC ---
Created attachment 24104
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24104
gcc46-pr48742.patch

So do you mean something like this?  Haven't bootstrapped/regtested it yet...

[Bug libstdc++/48750] for_each_template_random_access_ed has unbalanced new/delete[]

[paolo.carlini at oracle dot com]

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

--- Comment #9 from Paolo Carlini  2011-04-26 
15:19:12 UTC ---
Seth, Tom, if you get a chance to test the changes I propose in Comment 7
(suitably, trivially tweaked for 4.4.x), please let me know as soon as
possible.

If Johannes cannot provide feedback on this issue over the next few days I mean
to go ahead with my patch, likely for 4.6.x too, and work on a other similar
tweaks in the same spirit elsewhere in the parallel code (luckily we have only
an handful of operator new / operator delete pairs needing attention).

[Bug c/48742] [4.5/4.6/4.7 Regression] Internal error in gimplify_expr

[joseph at codesourcery dot com]

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

--- Comment #5 from joseph at codesourcery dot com  2011-04-26 15:24:13 UTC ---
On Tue, 26 Apr 2011, jakub at gcc dot gnu.org wrote:

> Created attachment 24104
>   --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24104
> gcc46-pr48742.patch
> 
> So do you mean something like this?  Haven't bootstrapped/regtested it yet...

Yes, that patch looks right.

[Bug rtl-optimization/48774] New: gcc-4.6.0 optimization regression on x86_64-unknown-linux-gnu

[mariah.lenox at gmail dot com]

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

   Summary: gcc-4.6.0 optimization regression on
x86_64-unknown-linux-gnu
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mariah.le...@gmail.com


/* gcc-4.6.0 optimization regression on x86_64-unknown-linux-gnu:

% gcc  -O1  -funroll-loops -o foo foo.c
foo
order= 11
%
% gcc  -O2  -funroll-loops -o foo foo.c
foo  # hangs
make: *** [bad] Interrupt
%
% gcc-4.5.1 -O2  -funroll-loops -o foo foo.c
foo
order=11
%
% gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc-4.6.0/x86_64-Linux-core2-fc/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /usr/local/gcc-4.6.0/src/gcc-4.6.0/configure
--enable-languages=c,c++,fortran --with-gnu-as
--with-gnu-as=/usr/local/binutils-2.21/x86_64-Linux-core2-fc-gcc-4.5.1-rh/bin/as
--with-gnu-ld
--with-ld=/usr/local/binutils-2.21/x86_64-Linux-core2-fc-gcc-4.5.1-rh/bin/ld
--with-gmp=/usr/local/mpir-2.3.0/x86_64-Linux-core2-fc-gcc-4.5.1-rh
--with-mpfr=/usr/local/mpfr-3.0.0/x86_64-Linux-core2-fc-mpir-2.3.0-gcc-4.5.1-rh
--with-mpc=/usr/local/mpc-0.9/x86_64-Linux-core2-fc-mpir-2.3.0-mpfr-3.0.0-gcc-4.5.1-rh
--prefix=/usr/local/gcc-4.6.0/x86_64-Linux-core2-fc
Thread model: posix
gcc version 4.6.0 (GCC) 
%

Apologies that this code is so long, but I can not find any way
to shorten it further and still demonstrate the bug.
*/
#include 
#include 
#include 

#define SIZE 12

unsigned long int ss[SIZE][2];

#define SET_BIT_MASK(x) ((unsigned long)1<<(x))

#define SET_ELEMENT_CONTAINS(e,v)   ((e)&SET_BIT_MASK(v))

#define SET_CONTAINS_FAST(s,a) (SET_ELEMENT_CONTAINS((s)[0], (a)))

#define SET_CONTAINS(s,a) (((a)edges[(0)]))[-1])?SET_CONTAINS_FAST((g)->edges[(i)],j):0)
/*
  SET_CONTAINS((g)->edges[(i)], (j))
*/

int bar(graph_t *g) {
  int i,j,v;
  int tmp_used[SIZE];
  int degree[SIZE];
  int order[SIZE];
  int maxdegree,maxvertex=0;
  int samecolor;

  for (i = 0; i < SIZE; i++) {
order[i] = 0;
degree[i] = 0;
  }

  for (i=0; i < g->n; i++) {
for (j=0; j < g->n; j++) {
  if ((i==j) && GRAPH_IS_EDGE(g,i,j)) {
exit(0);;
  } 
  if (GRAPH_IS_EDGE(g,i,j)) degree[i]++;
}
  }

  v=0;
  while (v < SIZE) {
memset(tmp_used,0,SIZE * sizeof(int));

do {
  maxdegree=0;
  samecolor=0;
  for (i=0; i < SIZE; i++) {
if (!tmp_used[i] && degree[i] >= maxdegree) {
  maxvertex=i;
  maxdegree=degree[i];
  samecolor=1;
}
  }
  if (samecolor) {
order[v]=maxvertex;
degree[maxvertex]=-1;
v++;
for (i=0; i < SIZE; i++) {
  if (GRAPH_IS_EDGE(g,maxvertex,i)) {
tmp_used[i]=1;
degree[i]--;
  }
}
  }
} while (samecolor);
  }

  return order[0];
}


graph_t *make_graph() {
  graph_t *g;
  int i;

  for (i=0; i < SIZE; i++) {
ss[i][0] = SIZE;
  }
  ss[0][1] = 2114;
  ss[1][1] = 37;
  ss[2][1] = 1034;
  ss[3][1] = 532;
  ss[4][1] = 296;
  ss[5][1] = 82;
  ss[6][1] = 161;
  ss[7][1] = 2368;
  ss[8][1] = 656;
  ss[9][1] = 1288;
  ss[10][1] = 2564;
  ss[11][1] = 1153;

  g = ≫
  g->n=SIZE;
  for (i=0; i < SIZE; i++) {
g->edges[i]=&(ss[i][1]);
  }

  return g;
}



int main(int argc, char **argv) {

  graph_t *g;
  int order;

  g = make_graph();
  order = bar(g);
  printf("order= %d\n", order);

  return 0;
}

[Bug target/48754] FAIL: gcc.dg/binop-xor(1|3).c scan-tree-dump-times optimized "]*>" *

[ro at gcc dot gnu.org]

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

--- Comment #3 from Rainer Orth  2011-04-26 16:25:49 UTC 
---
Created attachment 24105
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24105
-fdump-tree-optimized for mips-sgi-irix6.5, N32 ABI

[Bug target/48754] FAIL: gcc.dg/binop-xor(1|3).c scan-tree-dump-times optimized "]*>" *

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Target|powerpc*-*-*|powerpc*-*-*, mips*-*-*
 CC||ro at gcc dot gnu.org

--- Comment #2 from Rainer Orth  2011-04-26 16:24:41 UTC 
---
All five tests also fail on IRIX 6.5, both N32 and N64 ABIs:

FAIL: gcc.dg/binop-xor1.c scan-tree-dump-times optimized "]*>" 5
FAIL: gcc.dg/binop-xor1.c scan-tree-dump-times optimized "\\^" 1
FAIL: gcc.dg/binop-xor2.c scan-tree-dump-times optimized "\\^" 1
FAIL: gcc.dg/binop-xor3.c scan-tree-dump-times optimized "]*>" 1
FAIL: gcc.dg/binop-xor3.c scan-tree-dump-times optimized "\\^" 1
FAIL: gcc.dg/binop-xor4.c scan-tree-dump-times optimized "\\^" 1
FAIL: gcc.dg/binop-xor5.c scan-tree-dump-times optimized "\\^" 1
FAIL: gcc.dg/binop-xor5.c scan-tree-dump-times optimized "&" 1

I'm attaching the corresponding dumps.

[Bug middle-end/48663] [4.7 regression] final.c:dump_basic_block_info breaks several Tru64 UNIX tests

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #3 from Rainer Orth  2011-04-26 16:29:40 UTC 
---
Indeed, the error is gone as of r172821.

[Bug tree-optimization/48775] New: gcc.dg/pr48616.c FAILs on Tru64 UNIX

[ro at gcc dot gnu.org]

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

   Summary: gcc.dg/pr48616.c FAILs on Tru64 UNIX
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
CC: ja...@gcc.gnu.org
  Host: alpha-dec-osf5.1b
Target: alpha-dec-osf5.1b
 Build: alpha-dec-osf5.1b


The new gcc.dg/pr48616.c tests fails on Tru64 UNIX:

FAIL: gcc.dg/pr48616.c (test for excess errors)
Excess errors:
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/pr48616.c:10:5: warning:
requested alignment for 'e' is greater than implemented alignment of 16
[enabled by default]
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/pr48616.c:9:5: warning:
requested alignment for 'd' is greater than implemented alignment of 16
[enabled by default]
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/pr48616.c:8:5: warning:
requested alignment for 'c' is greater than implemented alignment of 16
[enabled by default]
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/pr48616.c:7:5: warning:
requested alignment for 'b' is greater than implemented alignment of 16
[enabled by default]
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/pr48616.c:6:5: warning:
requested alignment for 'a' is greater than implemented alignment of 16
[enabled by default]

[Bug fortran/48279] [4.6/4.7 Regression] segfault in gfc_check_vardef_context

[burnus at gcc dot gnu.org]

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

--- Comment #10 from Tobias Burnus  2011-04-26 
17:06:03 UTC ---
   Works: 2010-10-15-r165507 (a5b23678e24cec2da289a54ae62f98f7b1301c36)
   Fails: 2010-10-23-r165882 (2dfbcd30bb4e761a9c5144a0656b8dfc6336ed37)

[Bug target/48604] [4.5/4.6/4.7 regression] wrong code with -frename-registers

[edmar at freescale dot com]

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

Edmar Wienskoski  changed:

   What|Removed |Added

 CC||edmar at freescale dot com

--- Comment #4 from Edmar Wienskoski  2011-04-26 
17:31:38 UTC ---
You may want to take a look at:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44618

[Bug fortran/48438] Several gfortran tests FAIL on Tru64 UNIX

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE  2011-04-26 17:36:51 UTC ---
> - large_real_kind_2.F90
>   Fails for CTEST_POWER(0.0, 5.4), which is:
> abs(0.0**5.4 - 0.0**5.4)/(0.0**5.4) > eps
>       
>   where "x" is complex(kind=16) ("selected_real_kind (precision (0.0_8) + 1)")
>   and "8" is complex(8).
>   The numeric expression gives 0.0/0.0 = NaN - and "NaN > eps" gives
>   here FALSE - but on Tru64 seemingly SIGABRT? 

No, the SIGFPE already happens in the cpow (0.0, 0.0, 5.4, 0.0) call.
If I compile with -mieee instead, I get SIGFPE for

75   CTEST_POWER (0.0,1.0)

complex(3) states:

  cpow(), cpowf()   sqrt(a**2 + b**2) >   overflow
max_float
  cpow(), cpowf()   c/2 * ln(a**2 + b**2) >   overflow
max_float
  cpow(), cpowf()   c/2 * ln(a**2 + b**2) -   overflow
(d * atan2(b,c)) >
max_float
  

  __
  Value Name   Data Type   Hexadecimal Value   Decimal Value
  __
  max_floatF_FLOAT 7FFF1.701411e38
   G_FLOAT 7   8.988465674311579e307
   S_FLOAT 7F7F3.402823e38
   T_FLOAT 7FEF

F_FLOAT and G_FLOAT is the VAX single resp. double format, while S_FLOAT
and T_FLOAT are IEEE single and double.

Rainer

[Bug target/48258] Add VSX support for float/double vector reductions & improve float insert/extract

[meissner at gcc dot gnu.org]

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

--- Comment #2 from Michael Meissner  2011-04-26 
17:48:34 UTC ---
Author: meissner
Date: Tue Apr 26 17:48:29 2011
New Revision: 172981

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172981
Log:
PR target/48258, improve vector reduction on power7

Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr48258-1.c
trunk/gcc/testsuite/gcc.target/powerpc/pr48258-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/config/rs6000/vector.md
trunk/gcc/config/rs6000/vsx.md
trunk/gcc/testsuite/ChangeLog

[Bug fortran/48279] [4.6/4.7 Regression] segfault in gfc_check_vardef_context

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  2011-04-26 
17:54:11 UTC ---
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165749

[Bug middle-end/38277] gcc.c-torture/execute/20010910-1.c wrong code generation by loop distribution enabled

[zsojka at seznam dot cz]

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

Zdenek Sojka  changed:

   What|Removed |Added

 CC||zsojka at seznam dot cz

--- Comment #1 from Zdenek Sojka  2011-04-26 17:52:49 
UTC ---
I can't reproduce this with neither current trunk nor recent 4.6, 4.5 and 4.4
checkouts.

$ gcc -v
Using built-in specs.
COLLECT_GCC=/mnt/svn/gcc-trunk/binary-latest/bin/gcc
COLLECT_LTO_WRAPPER=/mnt/svn/gcc-trunk/binary-172960-lto-fortran-checking-yes-rtl-df/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /mnt/svn/gcc-trunk//configure --enable-checking=yes,rtl,df
--enable-languages=c,c++,lto,fortran
--prefix=/mnt/svn/gcc-trunk/binary-172960-lto-fortran-checking-yes-rtl-df/
--with-cloog --with-ppl --with-cloog-include=/usr/include/cloog-ppl/
--disable-ppl-version-check
Thread model: posix
gcc version 4.7.0 20110426 (experimental) (GCC) 

$ gcc gcc.c-torture/execute/20010910-1.c -O3 -fomit-frame-pointer
-ftree-loop-distribution
$ valgrind -q ./a.out

(no output)


(however, there seems to be miscompilation caused by -ftree-loop-distribution,
but the testcase I am reducing - examples/array.cpp from blitz - has currently
over 40k lines)

[Bug middle-end/48752] [4.7 Regression] ICE in evaulate_conditions_for_edge at ipa-inline-analysis.c:466

[hubicka at gcc dot gnu.org]

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

--- Comment #10 from Jan Hubicka  2011-04-26 
17:59:49 UTC ---
Hi,
the testcase doesn't seem to work for me.  I get
In file included from
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/cctype:43:0,
 from
/test/gnu/gcc/gcc/libstdc++-v3/include/precompiled/stdc++.h:36:
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/hppa2.0w-hp-hpux11.11/bits/c++config.h:159:20:
error: typedef 'std::decltype' is initialized (use decltype instead)
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/hppa2.0w-hp-hpux11.11/bits/c++config.h:159:20:
error: 'nullptr' was not declared in this scope
In file included from
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/cmath:44:0,
 from
/test/gnu/gcc/gcc/libstdc++-v3/include/precompiled/stdc++.h:42:
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/bits/cpp_type_traits.h:185:25:
error: 'char16_t' was not declared in this scope
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/bits/cpp_type_traits.h:185:33:
error: template argument 1 is invalid
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/bits/cpp_type_traits.h:192:25:
error: 'char32_t' was not declared in this scope
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/bits/cpp_type_traits.h:192:33:
error: template argument 1 is invalid
In file included from
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/iosfwd:41:0,
 from
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/ios:39,
 from
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/istream:40,
 from
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/sstream:39,
 from
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/complex:47,
 from
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/ccomplex:42,
 from
/test/gnu/gcc/gcc/libstdc++-v3/include/precompiled/stdc++.h:53:
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/bits/stringfwd.h:76:33:
error: 'char16_t' was not declared in this scope
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/bits/stringfwd.h:76:41:
error: template argument 1 is invalid
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/bits/stringfwd.h:77:33:
error: 'char32_t' was not declared in this scope
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/bits/stringfwd.h:77:41:
error: template argument 1 is invalid
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/bits/stringfwd.h:79:24:
error: 'char16_t' was not declared in this scope
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/bits/stringfwd.h:79:32:
error: template argument 1 is invalid
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/bits/stringfwd.h:79:32:
error: template argument 2 is invalid
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/bits/stringfwd.h:79:32:
error: template argument 3 is invalid
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/bits/stringfwd.h:79:43:
error: invalid type in declaration before ';' token
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/bits/stringfwd.h:80:24:
error: 'char32_t' was not declared in this scope
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/bits/stringfwd.h:80:32:
error: template argument 1 is invalid
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/bits/stringfwd.h:80:32:
error: template argument 2 is invalid
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/bits/stringfwd.h:80:32:
error: template argument 3 is invalid
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/bits/stringfwd.h:80:43:
error: invalid type in declaration before ';' token
and more...
on comipler configure as:
configure --target=hppa2.0w-hp-hpux11.11 --enable-languages=c,c++
--disable-bootstrap

Any clue what is wrong?
After dinner I will try to look into the add_new_function path and figure out
why summaries are not computed as they should.

[Bug libstdc++/48750] for_each_template_random_access_ed has unbalanced new/delete[]

[t.h.shorrock at gmail dot com]

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

--- Comment #10 from Tom  2011-04-26 18:09:05 
UTC ---
Hi Paulo,

Yes, this certainly fixes my segfault.

Valgrind complains a little - although I am not sure if this is important (I
am very new to the helgrind tool).  In case it is useful, I attach the
output I get,

So the line numbers are meaningful, I include my modified par_loop.h and my
test file.


Here is my g++ -v

Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.4.4-14ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.4 --enable-shared --enable-multiarch
--enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --disable-werror --with-arch-32=i686 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu5)

running on Ubuntu 10-10


Many thanks for your assistance with this. My gratitude to the FSF grows
daily.

Tom



On 26 April 2011 16:20, paolo.carlini at oracle dot com <
gcc-bugzi...@gcc.gnu.org> wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48750
>
> --- Comment #9 from Paolo Carlini 
> 2011-04-26 15:19:12 UTC ---
> Seth, Tom, if you get a chance to test the changes I propose in Comment 7
> (suitably, trivially tweaked for 4.4.x), please let me know as soon as
> possible.
>
> If Johannes cannot provide feedback on this issue over the next few days I
> mean
> to go ahead with my patch, likely for 4.6.x too, and work on a other
> similar
> tweaks in the same spirit elsewhere in the parallel code (luckily we have
> only
> an handful of operator new / operator delete pairs needing attention).
>
> --
> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
> --- You are receiving this mail because: ---
> You are on the CC list for the bug.
>

[Bug middle-end/48752] [4.7 Regression] ICE in evaulate_conditions_for_edge at ipa-inline-analysis.c:466

[dave at hiauly1 dot hia.nrc.ca]

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

--- Comment #11 from dave at hiauly1 dot hia.nrc.ca 2011-04-26 18:11:43 UTC ---
> Any clue what is wrong?
> After dinner I will try to look into the add_new_function path and figure out
> why summaries are not computed as they should.

These are the args I used in debugging cc1plus with the testcase: 

-fpreprocessed stdc++.ii -quiet -dumpbase stdc++.h -auxbase stdc++ -g -g -O2
-O2 -std=gnu++0x -version -o stdc++.s --output-pch=
hppa2.0w-hp-hpux11.11/bits/stdc++.h.gch/O2ggnu++0x.gch

Does that help?

Dave