[Bug fortran/46952] [OOP] Spurious "recursive call" error with type bound procedure

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||ice-on-invalid-code,
   ||rejects-valid
   Last reconfirmed||2010.12.15 08:25:18
 CC||burnus at gcc dot gnu.org,
   ||janus at gcc dot gnu.org
 Ever Confirmed|0   |1
Summary|Spurious "recursive call"   |[OOP] Spurious "recursive
   |error with type bound   |call" error with type bound
   |procedure   |procedure

--- Comment #1 from Tobias Burnus  2010-12-15 
08:25:18 UTC ---
At a glance it looks valid to me. The crucial part seems to be:

  PROCEDURE(relay_proc), DEFERRED :: TwoProc
...
  SUBROUTINE relay_proc(obj)
CALL obj%TwoProc
1
Error: SUBROUTINE 'relay_proc' at (1) cannot be called recursively, as it is
not RECURSIVE

  *  *  *

I managed to create an ICE-on-invalid-code: The following program segfaults w/o
printing any error/warning message at

==31463== Invalid read of size 1
==31463==at 0x50871E: gfc_match_varspec (primary.c:1771)
==31463==by 0x4F06A3: gfc_match_call (match.c:3442)
==31463==by 0x501622: match_word (parse.c:65)


The following program is invalid for several reasons: the ICE seems to be due
to "bar" having no dummy argument. If one adds one, one gets the bogus
"recursive" error; fixing that one gets the correct error that the argument
must be of type CLASS(t2) and not of CLASS(t).

module m
  type, abstract :: t
  contains
procedure(bar), pass, deferred :: foo
procedure(bar), pass, deferred :: bar
  end type
  type,extends(t) :: t2
  contains
procedure, pass :: bar => bar
procedure, pass :: foo => foo
  end type t2
contains
  subroutine foo(this)
class(t) :: this
  end subroutine foo
  subroutine bar()   ! pass but "this" argument is missing; no error only ICE
class(t) :: this
call this%foo()
  end subroutine
end module m

[Bug fortran/46952] [OOP] Spurious "recursive call" error with type bound procedure

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus  2010-12-15 
08:37:42 UTC ---
Reduced test case. Crucial seems to be that "inter" and "bar" call "foo" and
that foo and bar are defined via the interface "inter".

Similarly to gfortran and ifort also Crayftn rejects the following program.
However, I do no see any possibility how one could create a recursive call.
Thus, I do not see the need for a RECURSIVE attribute ("The RECURSIVE
prefix-spec shall appear if any procedure defined by the subprogram directly or
indirectly invokes itself or any other procedure defined by the subprogram.")

module m
  type, abstract :: t
  contains
procedure(inter), pass, deferred :: foo
procedure(inter), pass, deferred :: bar
  end type
  type,extends(t) :: t2
  contains
procedure, pass :: bar => bar
procedure, pass :: foo => foo
  end type t2
contains
  subroutine inter(this)
class(t) :: this
call this%foo()
  end subroutine inter
  subroutine foo(this)
class(t2) :: this
  end subroutine foo
  subroutine bar(this)
class(t2) :: this
call this%foo()
  end subroutine
end module m

[Bug testsuite/46938] FAIL: gcc.dg/pr43157.c (test for excess errors)

[davek at gcc dot gnu.org]

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

Dave Korn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2010-12/msg00917.htm
   ||l
   Keywords||patch
   Last reconfirmed||2010.12.15 09:29:22
 AssignedTo|unassigned at gcc dot   |davek at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #1 from Dave Korn  2010-12-15 09:29:22 
UTC ---
Patch got approved while I was out of town for a couple of days, will commit it
shortly.

[Bug libstdc++/46951] 30_threads/future/members/45133.cc failed

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC|jwakely.gcc at gmail dot|
   |com |
 Resolution||FIXED
   Target Milestone|--- |4.6.0

--- Comment #7 from Jonathan Wakely  2010-12-15 
09:29:38 UTC ---
fixed. thanks for your help, HJ

[Bug testsuite/46938] FAIL: gcc.dg/pr43157.c (test for excess errors)

[davek at gcc dot gnu.org]

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

--- Comment #2 from Dave Korn  2010-12-15 09:51:30 
UTC ---
Author: davek
Date: Wed Dec 15 09:51:26 2010
New Revision: 167848

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167848
Log:
PR testsuite/46938
* gcc.dg/pr43157.c: Add dg-require-linker-plugin  directive.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/pr43157.c

[Bug testsuite/46938] FAIL: gcc.dg/pr43157.c (test for excess errors)

[davek at gcc dot gnu.org]

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

Dave Korn  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #3 from Dave Korn  2010-12-15 09:53:13 
UTC ---
Should be fixed now.

[Bug debug/46893] [4.5/4.6 Regression] ICE: in trunc_int_for_mode, at explow.c:56 with -O -g

[jakub at gcc dot gnu.org]

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

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  2010-12-15 
10:17:15 UTC ---
Created attachment 22761
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22761
gcc46-pr46893.patch

Untested fix.

[Bug debug/46955] New: Missing DW_AT_const_value from DW_TAG_template_value_parameter

[dodji at gcc dot gnu.org]

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

   Summary: Missing DW_AT_const_value from
DW_TAG_template_value_parameter
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: do...@gcc.gnu.org


struct S { int f; };
template struct T { };
T<&S::f> v;

For v's type, I just see:

 <2><4f>: Abbrev Number: 6 (DW_TAG_template_value_param)
<50>   DW_AT_name: MP   
<53>   DW_AT_type: <0x58>   

That is, this parameter has no value.

This is because the DWARF emitter doesn't know how to handle the C++ specific
PTRMEM_CST node that represenst the argument &S::f at that point. That
PTRMEM_CST needs to be folded further into something low level enough for the
DWARF emitter to understand, while keeping its OFFSET_TYPE type meaning it's a
pointer-to-member constant.

This has been first reported in a comment of PR debug/41736, but I am opening
this specific bug for it as I think those two bugs are different.

[Bug c++/46956] New: [4.6 Regression] g++ PCH fails

[iains at gcc dot gnu.org]

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

   Summary: [4.6 Regression] g++ PCH fails
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ia...@gcc.gnu.org
CC: hubi...@gcc.gnu.org
  Host: *86*-apple-darwin{9,10}
Target: *86*-apple-darwin{9,10}
 Build: *86*-apple-darwin{9,10}


commit:

http://gcc.gnu.org/ml/gcc-cvs/2010-12/msg00463.html

caused (m32 & m64):

Running /GCC/gcc-4-6-reghunt/gcc/testsuite/g++.dg/pch/pch.exp ...
FAIL: g++.dg/pch/system-1.C  -g assembly comparison
FAIL: g++.dg/pch/system-1.C  -O2 -g assembly comparison
FAIL: g++.dg/pch/system-1.C  -O2 assembly comparison
FAIL: g++.dg/pch/system-2.C  -g assembly comparison
FAIL: g++.dg/pch/system-2.C  -O2 -g assembly comparison
FAIL: g++.dg/pch/system-2.C  -O2 assembly comparison

===
FAILs like:

++-v3/include/backward -I/GCC/gcc-4-6-reghunt/libstdc++-v3/testsuite/util
-fmessage-length=0  -O2 -g -I.   -S  -m32 -o system-1.s(timeout = 60)
PASS: g++.dg/pch/system-1.C  -O2 -g -I. (test for excess errors)
line #35
<
__GLOBAL__sub_I__GCC_gcc_4_6_reghunt_gcc_testsuite_g__.dg_pch_system_1.C_867072EB_51FA32F0:
> __GLOBAL__sub_I__GCC_gcc_4_6_reghunt_gcc_testsuite_g__.dg_pch_system_1.C_867072EB_B88D4144:
line #72
<   .long  
__GLOBAL__sub_I__GCC_gcc_4_6_reghunt_gcc_testsuite_g__.dg_pch_system_1.C_867072EB_51FA32F0
>   .long   
> __GLOBAL__sub_I__GCC_gcc_4_6_reghunt_gcc_testsuite_g__.dg_pch_system_1.C_867072EB_B88D4144
line #251
<
__GLOBAL__sub_I__GCC_gcc_4_6_reghunt_gcc_testsuite_g__.dg_pch_system_1.C_867072EB_51FA32F0.eh:
> __GLOBAL__sub_I__GCC_gcc_4_6_reghunt_gcc_testsuite_g__.dg_pch_system_1.C_867072EB_B88D4144.eh:
line #1373
<   .ascii
"_GLOBAL__sub_I__GCC_gcc_4_6_reghunt_gcc_testsuite_g__.dg_pch_system_1.C_867072EB_51FA32F0\0"
>   .ascii 
> "_GLOBAL__sub_I__GCC_gcc_4_6_reghunt_gcc_testsuite_g__.dg_pch_system_1.C_867072EB_B88D4144\0"
FAIL: g++.dg/pch/system-1.C  -O2 -g assembly comparison

[Bug debug/46955] Missing DW_AT_const_value from DW_TAG_template_value_parameter

[dodji at gcc dot gnu.org]

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

Dodji Seketeli  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2010.12.15 10:21:25
 AssignedTo|unassigned at gcc dot   |dodji at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

[Bug debug/41736] missing DW_TAG_template_*_ in some cases

[dodji at gcc dot gnu.org]

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

--- Comment #5 from Dodji Seketeli  2010-12-15 
10:21:41 UTC ---
(In reply to comment #3)
> The ordinary cases work fine with svn trunk gcc.
> However, member pointers still don't have all the info emitted.
> Consider this test case:
> 
> struct S { int f; };
> template struct T { };
> T<&S::f> v;
> 
> For v's type, I just see:
> 
>  <2><4f>: Abbrev Number: 6 (DW_TAG_template_value_param)
> <50>   DW_AT_name: MP   
> <53>   DW_AT_type: <0x58>   
> 
> That is, this parameter has no value.

I have opened PR debug/46955 to track this as I believe the bug you describe is
slightly different from this one, even if they fall in the same category.

[Bug middle-end/46916] gcc.dg/torture/stackalign/non-local-goto-[1,2].c ICEs compiler due to r167727

[iains at gcc dot gnu.org]

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

--- Comment #54 from Iain Sandoe  2010-12-15 10:22:27 
UTC ---
(In reply to comment #49)

 As Dominique surmised, this is a different problem:

> as per Comment #28/30:
> FAIL: g++.dg/pch/system-1.C  -g assembly comparison
> FAIL: g++.dg/pch/system-1.C  -O2 -g assembly comparison
> FAIL: g++.dg/pch/system-1.C  -O2 assembly comparison
> FAIL: g++.dg/pch/system-2.C  -g assembly comparison
> FAIL: g++.dg/pch/system-2.C  -O2 -g assembly comparison
> FAIL: g++.dg/pch/system-2.C  -O2 assembly comparison

now PR46956

[Bug libstdc++/46869] FAIL: 20_util/enable_shared_from_this/cons/constexpr.cc scan-assembler-not _ZNSt23enable_shared_from_thisIiEC2Ev

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Target|hppa2.0w-hp-hpux11.11   |hppa2.0w-hp-hpux11.11,
   ||alpha-dec-osf5.1b
 CC||ro at gcc dot gnu.org
   Host|hppa2.0w-hp-hpux11.11   |hppa2.0w-hp-hpux11.11,
   ||alpha-dec-osf5.1b
  Build|hppa2.0w-hp-hpux11.11   |hppa2.0w-hp-hpux11.11,
   ||alpha-dec-osf5.1b

--- Comment #3 from Rainer Orth  2010-12-15 10:23:25 UTC 
---
I'm seeing the same failure on Tru64 UNIX V5.1B, together with a few other
newly
failing tests:

+FAIL: 20_util/enable_shared_from_this/cons/constexpr.cc scan-assembler-not
_ZNSt23enable_shared_from_thisIiEC2Ev
+FAIL: 20_util/enable_shared_from_this/cons/constexpr.cc scan-assembler-not
_ZN7derivedC2Ev
+FAIL: 20_util/shared_ptr/cons/constexpr.cc scan-assembler-not
_ZNSt10shared_ptrIiEC2Ev
+FAIL: 20_util/shared_ptr/cons/constexpr.cc scan-assembler-not
_ZNSt10shared_ptrIiEC2EDn
+FAIL: 20_util/unique_ptr/cons/constexpr.cc scan-assembler-not
_ZNSt10unique_ptrIiSt14default_deleteIiEEC2Ev
+FAIL: 20_util/unique_ptr/cons/constexpr.cc scan-assembler-not
_ZNSt10unique_ptrIiSt14default_deleteIiEEC2EDn
+FAIL: 20_util/weak_ptr/cons/constexpr.cc scan-assembler-not
_ZNSt8weak_ptrIiEC2Ev

I can provide more details if necessary.

[Bug middle-end/46671] [4.6 Regression] ICE in default_no_named_section, at varasm .c:5994

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED

--- Comment #14 from Rainer Orth  2010-12-15 10:24:43 
UTC ---
I've just finished a full Tru64 UNIX V5.1B bootstrap with only a few unrelated
regressions, so we're fine now.

Thanks.
  Rainer

[Bug fortran/46945] [4.6 Regression] gfortran.dg/unpack_zerosize_1.f90 FAILs with -ftree-vrp -fno-tree-ccp -fno-tree-fre

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  2010-12-15 
11:15:30 UTC ---
The problem is probably that the -1 in
D.1556 = ((logical(kind=4)) __builtin_expect (() D.1555 >
-1, 0) ? 1 : 0) + D.1554;
has TREE_OVERFLOW set, D.1555 is determined by VRP to be 0 and from the
overflowed constant VRP determines that 0 > -1 (the type of both is
sizetype, i.e. unsigned, but with the weirdo semantics).
This is created in gfc_array_init_size:
4160  /* First check for overflow. Since an array of type character can
4161 have zero element_size, we must check for that before
4162 dividing.  */
4163  tmp = fold_build2_loc (input_location, TRUNC_DIV_EXPR, 
4164 sizetype, 
4165 TYPE_MAX_VALUE (sizetype), element_size);
4166  tmp = fold_build3_loc (input_location, COND_EXPR, integer_type_node,
4167 gfc_unlikely (fold_build2_loc (input_location, LT_EXPR, 
4168boolean_type_node, tmp, 
4169stride)),
4170 integer_one_node, integer_zero_node);

I'd say it is very questionable to use sizetype here.

[Bug fortran/46945] [4.6 Regression] gfortran.dg/unpack_zerosize_1.f90 FAILs with -ftree-vrp -fno-tree-ccp -fno-tree-fre

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2010.12.15 11:28:11
 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #2 from Jakub Jelinek  2010-12-15 
11:28:11 UTC ---
Created attachment 22762
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22762
gcc46-pr46945.patch

Untested fix.

[Bug middle-end/45388] [4.6 Regression] Global constructor not found

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #13 from Jakub Jelinek  2010-12-15 
11:55:07 UTC ---
Assuming this is fixed now.

[Bug c++/46956] [4.6 Regression] g++ PCH fails

[hubicka at ucw dot cz]

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

--- Comment #1 from Jan Hubicka  2010-12-15 11:55:41 UTC 
---
__GLOBAL__sub_I__GCC_gcc_4_6_reghunt_gcc_testsuite_g__.dg_pch_system_1.C_867072EB_51FA32F0:
__GLOBAL__sub_I__GCC_gcc_4_6_reghunt_gcc_testsuite_g__.dg_pch_system_1.C_867072EB_B88D4144:

Hmm, this seems like difference in random seed.  Perhaps the PCH tests ought to
be rood with -frandom-seed=1 after all?

Honza

[Bug fortran/46945] [4.6 Regression] gfortran.dg/unpack_zerosize_1.f90 FAILs with -ftree-vrp -fno-tree-ccp -fno-tree-fre

[jb at gcc dot gnu.org]

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

--- Comment #3 from Janne Blomqvist  2010-12-15 11:57:28 
UTC ---
The offending patch is most likely

http://gcc.gnu.org/ml/gcc-patches/2010-11/msg02499.html

Wrt. the recent changes in the definition of size_t, there is

http://gcc.gnu.org/ml/gcc-patches/2010-11/msg02111.html

Apart from the change suggested by Jakub in comment #2, is there anything else
suspect in those patches?

[Bug libstdc++/46869] FAIL: 20_util/enable_shared_from_this/cons/constexpr.cc scan-assembler-not _ZNSt23enable_shared_from_thisIiEC2Ev

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #4 from Paolo Carlini  2010-12-15 
12:20:12 UTC ---
Rainer, if in order to reduce the noise you want to simply xfail for now the
failing tests it's ok with me. Honestly, I don't know at the moment if we can
solve the issue in a more elegant way for 4.6.0.

[Bug ada/46939] http://blog.regehr.org/archives/320 example 6

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.12.15 12:24:34
 Ever Confirmed|0   |1

--- Comment #1 from Jan Hubicka  2010-12-15 
12:24:34 UTC ---
Predictions for bb 6
  DS theory heuristics: 4.0%
  first match heuristics (ignored): 4.0%
  combined heuristics: 4.0%
  negative return heuristics: 4.0%

So it is negative return heuristics.

Richi's profiling reorg broke statistics code, so I will need to dig into
archives before I fix it again.  But last time I updated the tables the
heuristics was 96% right on SPEC. I am not terribly oposed in making it less
reliable with a comment explaining why. In SPEC it is most surely perfoming
heuristics, we have only few of them above 60%

The heuristics makes a guess that negative return values tends to be used to
return error stages. It is not true in this case.

[Bug middle-end/46916] gcc.dg/torture/stackalign/non-local-goto-[1,2].c ICEs compiler due to r167727

[iains at gcc dot gnu.org]

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

--- Comment #55 from Iain Sandoe  2010-12-15 12:36:00 
UTC ---
this solves 

FAIL: g++.dg/other/pr22003.C (test for excess errors)

but we have total failure with "-O3 -g" for gcc.
[all fails are warning: no debug symbols in executable (-arch )]
(looking into that next)

- your patch + replacing the Darwin bits with this.

Index: gcc/config/darwin.c
===
--- gcc/config/darwin.c (revision 167849)
+++ gcc/config/darwin.c (working copy)
@@ -1145,19 +1145,6 @@ darwin_mark_decl_preserved (const char *name)
 }

 static section *
-darwin_text_section (int reloc, int weak)
-{
-  if (reloc)
-return (weak
-   ? darwin_sections[text_unlikely_coal_section]
-   : unlikely_text_section ());
-  else
-return (weak
-   ? darwin_sections[text_coal_section]
-   : text_section);
-}
-
-static section *
 darwin_rodata_section (int weak, bool zsize)
 {
   return (weak
@@ -1267,17 +1254,7 @@ machopic_select_section (tree decl,
   switch (categorize_decl_for_section (decl, reloc))
 {
 case SECCAT_TEXT:
-  {
-   struct cgraph_node *node;
-   if (decl && TREE_CODE (decl) == FUNCTION_DECL
-   && (node = cgraph_get_node (decl)) != NULL)
- base_section = darwin_function_section (decl,
- node->frequency,
- node->only_called_at_startup,
- node->only_called_at_exit);
-   if (!base_section)
-  base_section = darwin_text_section (reloc, weak);
-  }
+  gcc_unreachable ();
   break;

 case SECCAT_RODATA:
@@ -2559,17 +2536,6 @@ darwin_override_options (void)
   if (!global_options_set.x_dwarf_strict) 
 dwarf_strict = 1;

-  /* Disable -freorder-blocks-and-partition for darwin_emit_unwind_label.  */
-  if (flag_reorder_blocks_and_partition 
-  && (targetm.asm_out.emit_unwind_label == darwin_emit_unwind_label))
-{
-  inform (input_location,
-  "-freorder-blocks-and-partition does not work with exceptions "
-  "on this architecture");
-  flag_reorder_blocks_and_partition = 0;
-  flag_reorder_blocks = 1;
-}
-
   if (flag_mkernel || flag_apple_kext)
 {
   /* -mkernel implies -fapple-kext for C++ */
@@ -2969,32 +2935,42 @@ darwin_function_section (tree decl, enum node_freq
  bool startup, bool exit)
 {
   if (!flag_reorder_functions)
-return NULL;
+return (DECL_WEAK (decl))
+   ? darwin_sections[text_coal_section]
+   : text_section;
+
   /* Startup code should go to startup subsection unless it is
  unlikely executed (this happens especially with function splitting
  where we can split away unnecesary parts of static constructors.  */
   if (startup && freq != NODE_FREQUENCY_UNLIKELY_EXECUTED)
-return get_named_text_section
-(decl, "__TEXT,__startup,regular,pure_instructions", "_startup");
+return (DECL_WEAK (decl))
+   ? darwin_sections[text_startup_coal_section]
+   : darwin_sections[text_startup_section];

   /* Similarly for exit.  */
   if (exit && freq != NODE_FREQUENCY_UNLIKELY_EXECUTED)
-return get_named_text_section (decl,
-  "__TEXT,__exit,regular,pure_instructions",
-  "_exit");
+return (DECL_WEAK (decl))
+   ? darwin_sections[text_exit_coal_section]
+   : darwin_sections[text_exit_section];

   /* Group cold functions together, similarly for hot code.  */
   switch (freq)
 {
   case NODE_FREQUENCY_UNLIKELY_EXECUTED:
-   return get_named_text_section
-(decl,
- "__TEXT,__unlikely,regular,pure_instructions", "_unlikely");
+   return (DECL_WEAK (decl))
+   ? darwin_sections[text_cold_coal_section]
+   : darwin_sections[text_cold_section];
+   break;
   case NODE_FREQUENCY_HOT:
-   return get_named_text_section
-(decl, "__TEXT,__hot,regular,pure_instructions", "_hot");
+   return (DECL_WEAK (decl))
+   ? darwin_sections[text_hot_coal_section]
+   : darwin_sections[text_hot_section];
+   break;
   default:
-   return NULL;
+   return (DECL_WEAK (decl))
+   ? darwin_sections[text_coal_section]
+   : text_section;
+   break;
 }
 }

Index: gcc/config/darwin-sections.def
===
--- gcc/config/darwin-sections.def  (revision 167849)
+++ gcc/config/darwin-sections.def  (working copy)
@@ -34,6 +34,24 @@ DEF_SECTION (text_unlikely_coal_section, SECTION_C
 ".section __TEXT,__text_unlikely_coal,"
 "coalesced,pure_instructions", 0)

+DEF_SECTION (text_hot_section, SECTION_CODE,
+"

[Bug ada/46939] http://blog.regehr.org/archives/320 example 6

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #2 from Jan Hubicka  2010-12-15 
12:54:10 UTC ---
As observed by Jakub, it is actually bug in the return heuristics
implementation.  Will make patch shortly.

[Bug fortran/46838] [OOP] Wrong allocation status for polymorphic component INTENT(OUT) dummy

[sfilippone at uniroma2 dot it]

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

--- Comment #3 from Salvatore Filippone  
2010-12-15 13:08:12 UTC ---
(In reply to comment #2)
> The default initializer is obtained via expr.c's gfc_default_initializer.

The original code gives 
Overall matrix creation time :  1.69176E-01

[localhost:06639] Signal: Segmentation fault (11)
[localhost:06639] Signal code:  (128)
[localhost:06639] Failing at address: (nil)
*** glibc detected *** ./ppde: munmap_chunk(): invalid pointer:
0x0064a8e6 ***
=== Backtrace: =
/lib64/libc.so.6[0x39dc875676]
./ppde(__copy_psb_gen_block_map_mod_psb_gen_block_map_+0x143)[0x4c5f43]
./ppde(psb_cdcpy_+0x5c0)[0x4c11e0]
./ppde(psb_dcdbldext_+0x802)[0x4b3f92]
./ppde[0x419d26]
./ppde[0x41cbdd]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x39dc81ec5d]
./ppde[0x419339]

i.e. the problem surfaces in a SOURCE= allocation.

[Bug c++/46956] [4.6 Regression] g++ PCH fails

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2010.12.15 13:08:25
 Ever Confirmed|0   |1

--- Comment #2 from Jan Hubicka  2010-12-15 
13:08:25 UTC ---
Ought to be cured by http://gcc.gnu.org/ml/gcc/2010-12/msg00364.html

[Bug rtl-optimization/46649] [4.6 Regression] ICE: in move_bb_info, at sel-sched-ir.c:5080 with -fschedule-insns -fselective-scheduling

[amonakov at gcc dot gnu.org]

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

--- Comment #8 from Alexander Monakov  2010-12-15 
13:08:47 UTC ---
Author: amonakov
Date: Wed Dec 15 13:08:41 2010
New Revision: 167854

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167854
Log:
PR rtl-optimization/46649
* sel-sched-ir.c (purge_empty_blocks): Unconditionally skip the first
basic block in the region.

testsuite:
* g++.dg/opt/pr46649.C: New.


Added:
trunk/gcc/testsuite/g++.dg/opt/pr46649.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/sel-sched-ir.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/46649] [4.6 Regression] ICE: in move_bb_info, at sel-sched-ir.c:5080 with -fschedule-insns -fselective-scheduling

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #9 from Alexander Monakov  2010-12-15 
13:09:35 UTC ---
Fixed

[Bug middle-end/46916] gcc.dg/torture/stackalign/non-local-goto-[1,2].c ICEs compiler due to r167727

[hubicka at gcc dot gnu.org]

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

--- Comment #56 from Jan Hubicka  2010-12-15 
13:10:15 UTC ---
Hi,
thanks for testing.  I wonder why we need to add those +DEF_SECTION fields?
I think the infinite recursion problem should be fixed by dropping the whole
machinery on selecting sections.

With the darwin bits alone, do we get clear run except for the two partition
tests?

[Bug tree-optimization/46053] [4.6 Regression] g++.dg/torture/pr45699.C FAILs with -fno-early-inlining

[jamborm at gcc dot gnu.org]

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

--- Comment #5 from Martin Jambor  2010-12-15 
13:19:50 UTC ---
Author: jamborm
Date: Wed Dec 15 13:19:46 2010
New Revision: 167855

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167855
Log:
2010-12-15  Martin Jambor  

PR tree-optimization/46053
PR middle-end/46287
PR middle-end/46242
* cgraph.h (cgraph_indirect_call_info): New field thunk_delta.
* gimple.h (gimple_fold_obj_type_ref): Declaration removed.
(gimple_fold_call): Declare.
(gimple_adjust_this_by_delta): Likewise.
* cgraph.c (cgraph_make_edge_direct): New parameter delta.  Updated
all users.
(cgraph_clone_edge): Create a copy of indirect_info also for direct
edges.
* cgraphunit.c (cgraph_redirect_edge_call_stmt_to_callee): Adjust this
parameters.
* gimple-fold.c (gimple_fold_obj_type_ref_known_binfo): Renamed to
gimple_get_virt_mehtod_for_binfo, new parameter delta.  Do not search
through thunks, in fact bail out if we encounter one, check that
BINFO_VIRTUALS is not NULL.
(gimple_adjust_this_by_delta): New function.
(gimple_fold_obj_type_ref): Removed.
(gimple_fold_obj_type_ref_call): New function.
(fold_gimple_call): Renamed to gimple_fold_call, made external.
Updated users.  Call gimple_fold_obj_type_ref_call instead of
gimple_fold_obj_type_ref.
* ipa-cp.c (ipcp_process_devirtualization_opportunities): Process
thunk deltas.
(ipcp_discover_new_direct_edges): Likewise.
* ipa-prop.c (ipa_make_edge_direct_to_target): New parameter delta.
Updated callers.
(ipa_write_indirect_edge_info): Stream thunk_delta.
(ipa_read_indirect_edge_info): Likewise.
* tree-ssa-ccp.c (ccp_fold_stmt): Use gimple_fold_call instead of
gimple_fold_obj_type_ref.

* testsuite/g++.dg/ipa/pr46053.C: New test.
* testsuite/g++.dg/ipa/pr46287-1.C: Likewise.
* testsuite/g++.dg/ipa/pr46287-2.C: Likewise.
* testsuite/g++.dg/ipa/pr46287-3.C: Likewise.
* testsuite/g++.dg/torture/covariant-1.C: Likewise.
* testsuite/g++.dg/torture/pr46287.C: Likewise.


Added:
trunk/gcc/testsuite/g++.dg/ipa/pr46053.C
trunk/gcc/testsuite/g++.dg/ipa/pr46287-1.C
trunk/gcc/testsuite/g++.dg/ipa/pr46287-2.C
trunk/gcc/testsuite/g++.dg/ipa/pr46287-3.C
trunk/gcc/testsuite/g++.dg/torture/covariant-1.C
trunk/gcc/testsuite/g++.dg/torture/pr46287.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cgraph.c
trunk/gcc/cgraph.h
trunk/gcc/cgraphunit.c
trunk/gcc/gimple-fold.c
trunk/gcc/gimple.h
trunk/gcc/ipa-cp.c
trunk/gcc/ipa-prop.c
trunk/gcc/ipa-prop.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-ccp.c

[Bug middle-end/46287] No thunk info on call graph edges leads to miscompilations

[jamborm at gcc dot gnu.org]

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

--- Comment #4 from Martin Jambor  2010-12-15 
13:19:51 UTC ---
Author: jamborm
Date: Wed Dec 15 13:19:46 2010
New Revision: 167855

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167855
Log:
2010-12-15  Martin Jambor  

PR tree-optimization/46053
PR middle-end/46287
PR middle-end/46242
* cgraph.h (cgraph_indirect_call_info): New field thunk_delta.
* gimple.h (gimple_fold_obj_type_ref): Declaration removed.
(gimple_fold_call): Declare.
(gimple_adjust_this_by_delta): Likewise.
* cgraph.c (cgraph_make_edge_direct): New parameter delta.  Updated
all users.
(cgraph_clone_edge): Create a copy of indirect_info also for direct
edges.
* cgraphunit.c (cgraph_redirect_edge_call_stmt_to_callee): Adjust this
parameters.
* gimple-fold.c (gimple_fold_obj_type_ref_known_binfo): Renamed to
gimple_get_virt_mehtod_for_binfo, new parameter delta.  Do not search
through thunks, in fact bail out if we encounter one, check that
BINFO_VIRTUALS is not NULL.
(gimple_adjust_this_by_delta): New function.
(gimple_fold_obj_type_ref): Removed.
(gimple_fold_obj_type_ref_call): New function.
(fold_gimple_call): Renamed to gimple_fold_call, made external.
Updated users.  Call gimple_fold_obj_type_ref_call instead of
gimple_fold_obj_type_ref.
* ipa-cp.c (ipcp_process_devirtualization_opportunities): Process
thunk deltas.
(ipcp_discover_new_direct_edges): Likewise.
* ipa-prop.c (ipa_make_edge_direct_to_target): New parameter delta.
Updated callers.
(ipa_write_indirect_edge_info): Stream thunk_delta.
(ipa_read_indirect_edge_info): Likewise.
* tree-ssa-ccp.c (ccp_fold_stmt): Use gimple_fold_call instead of
gimple_fold_obj_type_ref.

* testsuite/g++.dg/ipa/pr46053.C: New test.
* testsuite/g++.dg/ipa/pr46287-1.C: Likewise.
* testsuite/g++.dg/ipa/pr46287-2.C: Likewise.
* testsuite/g++.dg/ipa/pr46287-3.C: Likewise.
* testsuite/g++.dg/torture/covariant-1.C: Likewise.
* testsuite/g++.dg/torture/pr46287.C: Likewise.


Added:
trunk/gcc/testsuite/g++.dg/ipa/pr46053.C
trunk/gcc/testsuite/g++.dg/ipa/pr46287-1.C
trunk/gcc/testsuite/g++.dg/ipa/pr46287-2.C
trunk/gcc/testsuite/g++.dg/ipa/pr46287-3.C
trunk/gcc/testsuite/g++.dg/torture/covariant-1.C
trunk/gcc/testsuite/g++.dg/torture/pr46287.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cgraph.c
trunk/gcc/cgraph.h
trunk/gcc/cgraphunit.c
trunk/gcc/gimple-fold.c
trunk/gcc/gimple.h
trunk/gcc/ipa-cp.c
trunk/gcc/ipa-prop.c
trunk/gcc/ipa-prop.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-ccp.c

[Bug middle-end/46242] Segmentation fault in ipcp_driver

[jamborm at gcc dot gnu.org]

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

--- Comment #4 from Martin Jambor  2010-12-15 
13:19:51 UTC ---
Author: jamborm
Date: Wed Dec 15 13:19:46 2010
New Revision: 167855

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167855
Log:
2010-12-15  Martin Jambor  

PR tree-optimization/46053
PR middle-end/46287
PR middle-end/46242
* cgraph.h (cgraph_indirect_call_info): New field thunk_delta.
* gimple.h (gimple_fold_obj_type_ref): Declaration removed.
(gimple_fold_call): Declare.
(gimple_adjust_this_by_delta): Likewise.
* cgraph.c (cgraph_make_edge_direct): New parameter delta.  Updated
all users.
(cgraph_clone_edge): Create a copy of indirect_info also for direct
edges.
* cgraphunit.c (cgraph_redirect_edge_call_stmt_to_callee): Adjust this
parameters.
* gimple-fold.c (gimple_fold_obj_type_ref_known_binfo): Renamed to
gimple_get_virt_mehtod_for_binfo, new parameter delta.  Do not search
through thunks, in fact bail out if we encounter one, check that
BINFO_VIRTUALS is not NULL.
(gimple_adjust_this_by_delta): New function.
(gimple_fold_obj_type_ref): Removed.
(gimple_fold_obj_type_ref_call): New function.
(fold_gimple_call): Renamed to gimple_fold_call, made external.
Updated users.  Call gimple_fold_obj_type_ref_call instead of
gimple_fold_obj_type_ref.
* ipa-cp.c (ipcp_process_devirtualization_opportunities): Process
thunk deltas.
(ipcp_discover_new_direct_edges): Likewise.
* ipa-prop.c (ipa_make_edge_direct_to_target): New parameter delta.
Updated callers.
(ipa_write_indirect_edge_info): Stream thunk_delta.
(ipa_read_indirect_edge_info): Likewise.
* tree-ssa-ccp.c (ccp_fold_stmt): Use gimple_fold_call instead of
gimple_fold_obj_type_ref.

* testsuite/g++.dg/ipa/pr46053.C: New test.
* testsuite/g++.dg/ipa/pr46287-1.C: Likewise.
* testsuite/g++.dg/ipa/pr46287-2.C: Likewise.
* testsuite/g++.dg/ipa/pr46287-3.C: Likewise.
* testsuite/g++.dg/torture/covariant-1.C: Likewise.
* testsuite/g++.dg/torture/pr46287.C: Likewise.


Added:
trunk/gcc/testsuite/g++.dg/ipa/pr46053.C
trunk/gcc/testsuite/g++.dg/ipa/pr46287-1.C
trunk/gcc/testsuite/g++.dg/ipa/pr46287-2.C
trunk/gcc/testsuite/g++.dg/ipa/pr46287-3.C
trunk/gcc/testsuite/g++.dg/torture/covariant-1.C
trunk/gcc/testsuite/g++.dg/torture/pr46287.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cgraph.c
trunk/gcc/cgraph.h
trunk/gcc/cgraphunit.c
trunk/gcc/gimple-fold.c
trunk/gcc/gimple.h
trunk/gcc/ipa-cp.c
trunk/gcc/ipa-prop.c
trunk/gcc/ipa-prop.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-ccp.c

[Bug middle-end/46916] gcc.dg/torture/stackalign/non-local-goto-[1,2].c ICEs compiler due to r167727

[iains at gcc dot gnu.org]

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

--- Comment #57 from Iain Sandoe  2010-12-15 13:25:07 
UTC ---
(In reply to comment #56)
>   I wonder why we need to add those +DEF_SECTION fields?
> I think the infinite recursion problem should be fixed by dropping the whole
> machinery on selecting sections.

nothing to do with the recursion - that's solved early in this thread --- 

-- we need a coalesced section to match each non-coalesced one.
since "darwin_function_section()" is called quite frequently, it seemed more
efficient to pre-declare the sections rather than keep finding them from
matching against a named section.

[ the key change is that there need to be coalesced sections for the DECL_WEAK
() -- I am not strongly saying the sections need to be pre-declared - if you
think that named sections would be better]

we would need :

   if (exit && freq != NODE_FREQUENCY_UNLIKELY_EXECUTED)
return (DECL_WEAK (decl))
  ? get_named_text_section (decl,

"__TEXT,__exit_coal,coalesced,pure_instructions", "_exit_coal");
  : get_named_text_section (decl,

"__TEXT,__exit,regular,pure_instructions", "_exit");

.. or some more efficient equivalent.

> With the darwin bits alone, do we get clear run except for the two partition
> tests?

tests are running ... looking OK so far,
... but we have a serious problem with dsymutil && || debug for "-O3 -g".

Still needs examining as to why...

[Bug ada/46939] http://blog.regehr.org/archives/320 example 6

[hubicka at gcc dot gnu.org]

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

--- Comment #3 from Jan Hubicka  2010-12-15 
13:28:56 UTC ---
Created attachment 22763
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22763
patch I am testing

[Bug middle-end/46916] gcc.dg/torture/stackalign/non-local-goto-[1,2].c ICEs compiler due to r167727

[hubicka at ucw dot cz]

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

--- Comment #58 from Jan Hubicka  2010-12-15 13:33:15 
UTC ---
> [ the key change is that there need to be coalesced sections for the DECL_WEAK
> () -- I am not strongly saying the sections need to be pre-declared - if you
> think that named sections would be better]

No, this seems fine.  I was just curious.
> 
> tests are running ... looking OK so far,
> ... but we have a serious problem with dsymutil && || debug for "-O3 -g".

Hmm, so it is independent of my bb-reorder patch...

[Bug c++/46956] [4.6 Regression] g++ PCH fails

[iains at gcc dot gnu.org]

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

--- Comment #3 from Iain Sandoe  2010-12-15 13:35:16 
UTC ---
(In reply to comment #2)
> Ought to be cured by http://gcc.gnu.org/ml/gcc/2010-12/msg00364.html

yes, with your patch  pch.exp=*  clean for c/c++/ObjC*.

[full regtest not done].

thanks for the patch :-)
Iain

[Bug c++/46868] [4.6 Regression] ICE: SIGSEGV splay_tree_splay (splay-tree.c:149) on invalid code

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||froydnj at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  2010-12-15 
13:38:55 UTC ---
Caused by http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166977

[Bug c++/46868] [4.6 Regression] ICE: SIGSEGV splay_tree_splay (splay-tree.c:149) on invalid code

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||gcc at abeckmann dot de

--- Comment #3 from Jakub Jelinek  2010-12-15 
13:40:21 UTC ---
*** Bug 46855 has been marked as a duplicate of this bug. ***

[Bug c++/46855] [4.6 Regression] cc1plus: internal compiler error: Segmentation fault (instead of g++-4.5's: expected unqualified-id at end of input)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  2010-12-15 
13:40:21 UTC ---
Dup of PR46868.

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

[Bug middle-end/46916] gcc.dg/torture/stackalign/non-local-goto-[1,2].c ICEs compiler due to r167727

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

  Attachment #22758|0   |1
is obsolete||

--- Comment #59 from Iain Sandoe  2010-12-15 13:41:40 
UTC ---
Created attachment 22764
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22764
Honza+Darwin mods

Honza, 
sorry, I think I misled you ... 

... I have your patch applied + the changes to Darwin I posted.

If you think I should test with just the darwin bits, OK I can do that.

[Bug middle-end/46916] gcc.dg/torture/stackalign/non-local-goto-[1,2].c ICEs compiler due to r167727

[hubicka at ucw dot cz]

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

--- Comment #60 from Jan Hubicka  2010-12-15 13:49:51 
UTC ---
Hi,
yes please try with the darwin bits alone and the hunk in opts.c enabling
function reordering when partitioning is on.

[Bug middle-end/46916] gcc.dg/torture/stackalign/non-local-goto-[1,2].c ICEs compiler due to r167727

[iains at gcc dot gnu.org]

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

--- Comment #61 from Iain Sandoe  2010-12-15 13:56:07 
UTC ---
(In reply to comment #59)
> Created attachment 22764 [details]
> Honza+Darwin mods

> If you think I should test with just the darwin bits, OK I can do that.

with *only* the darwin patch (comment #55) -- the debug problem is _not_
present.



With the total patch  [bb + darwin, comment #59]

+ every "-O3 -g" case fails 

+ gcc:

FAIL: gcc.dg/darwin-weakimport-3.c scan-assembler-not coalesced
FAIL: gcc.dg/pr25376.c scan-assembler my_named_section

g++:
+ FAIL: g++.dg/debug/dwarf2/pubnames-1.C scan-assembler-times
"main.0"[^\\n]*external name 1

[not tested yet - fortran/ObjC*/Java]

[Bug middle-end/46916] gcc.dg/torture/stackalign/non-local-goto-[1,2].c ICEs compiler due to r167727

[iains at gcc dot gnu.org]

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

--- Comment #62 from Iain Sandoe  2010-12-15 14:00:40 
UTC ---
(In reply to comment #61)
> (In reply to comment #59)
> > Created attachment 22764 [details] [details]
> > Honza+Darwin mods
> 
> > If you think I should test with just the darwin bits, OK I can do that.
> 
> with *only* the darwin patch (comment #55) -- the debug problem is _not_
> present.

adding the hunk for opts.c does _not_ appear to cause the failure either [I'll
rebuild & confirm].

[Bug middle-end/46916] gcc.dg/torture/stackalign/non-local-goto-[1,2].c ICEs compiler due to r167727

[hubicka at ucw dot cz]

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

--- Comment #63 from Jan Hubicka  2010-12-15 14:07:16 
UTC ---
OK,
if the darwin changes + opts.c change solves the problem, lets submit the patch
and I will try to re-review the bb-reorder patch and we can deal with the
problem
incrementally. Thanks!

[Bug middle-end/46242] Segmentation fault in ipcp_driver

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #5 from Martin Jambor  2010-12-15 
14:26:17 UTC ---
Fixed.

[Bug middle-end/46287] No thunk info on call graph edges leads to miscompilations

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #5 from Martin Jambor  2010-12-15 
14:32:03 UTC ---
Fixed.

[Bug tree-optimization/46053] [4.6 Regression] g++.dg/torture/pr45699.C FAILs with -fno-early-inlining

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #6 from Martin Jambor  2010-12-15 
14:33:09 UTC ---
Fixed.

[Bug middle-end/46916] gcc.dg/torture/stackalign/non-local-goto-[1,2].c ICEs compiler due to r167727

[howarth at nitro dot med.uc.edu]

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

--- Comment #64 from Jack Howarth  2010-12-15 
14:34:03 UTC ---
Iain,
My old radar bug report numbered 7289379, "linker warnings when no unwind
labels are emitted while targeting 10.6", my be have some useful information.
The report was...

08-Oct-2009 11:17 PM Jack Howarth:
When the following patch is used in FSF gcc trunk to leverage the fact that
unwind labels are no longer required when targeting 10.6...


2009-10-08  Jack Howarth  

PR c++/41313
* gcc/config/darwin.c: Suppress unwind labels when targeting 10.6 or
later.
Disable -freorder-blocks-and-partition for exception handling and when
the target requested unwind info. 


Index: gcc/config/darwin.c
===
--- gcc/config/darwin.c (revision 152583)
+++ gcc/config/darwin.c (working copy)
@@ -1454,7 +1454,8 @@
 {
   char *lab;

-  if (! for_eh)
+  /* Suppress unwind labels when targeting 10.6 or later.  */ 
+  if ((! for_eh) || (darwin_macosx_version_min &&
strverscmp(darwin_macosx_version_min, "10.6") >= 0))
 return;

   lab = concat (IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (decl)), ".eh", NULL);
@@ -1697,6 +1698,16 @@
   if (dwarf_strict < 0) 
 dwarf_strict = 1;

+  /* Disable -freorder-blocks-and-partition for exception handling or when
+ the target requested unwind info.  */
+  if (flag_reorder_blocks_and_partition && (flag_exceptions ||
flag_unwind_tables))
+{
+  inform (input_location,
+  "-freorder-blocks-and-partition does not work with exceptions on
this architecture");
+  flag_reorder_blocks_and_partition = 0;
+  flag_reorder_blocks = 1;
+}
+
   if (flag_mkernel || flag_apple_kext)
 {
   /* -mkernel implies -fapple-kext for C++ */

Two FSF gcc fail their compilation excessive errors test due to warnings of the
form...

ld: warning: can't add line info to anonymous symbol anon-func-0xF40 from
/var/tmp//ccrw73YL.o
ld: warning: can't add line info to anonymous symbol anon-func-0xF40 from
/var/tmp//ccrw73YL.o
ld: warning: can't add line info to anonymous symbol anon-func-0xF40 from
/var/tmp//ccrw73YL.o
ld: warning: can't add line info to anonymous symbol anon-func-0xF40 from
/var/tmp//ccrw73YL.o
ld: warning: can't add line info to anonymous symbol anon-func-0xF40 from
/var/tmp//ccrw73YL.o
ld: warning: can't add line info to anonymous symbol anon-func-0xF40 from
/var/tmp//ccrw73YL.o
ld: warning: can't add line info to anonymous symbol anon-func-0xF40 from
/var/tmp//ccrw73YL.o
ld: warning: can't add line info to anonymous symbol anon-func-0xF40 from
/var/tmp//ccrw73YL.o
ld: warning: can't add line info to anonymous symbol anon-func-0xF40 from
/var/tmp//ccrw73YL.o
ld: warning: can't add line info to anonymous symbol anon-func-0xF40 from
/var/tmp//ccrw73YL.o
ld: warning: can't add line info to anonymous symbol anon-func-0xF40 from
/var/tmp//ccrw73YL.o
ld: warning: can't add line info to anonymous symbol anon-func-0xF40 from
/var/tmp//ccrw73YL.o
ld: warning: can't add line info to anonymous symbol anon-func-0xF40 from
/var/tmp//ccrw73YL.o
ld: warning: can't add line info to anonymous symbol anon-func-0xF40 from
/var/tmp//ccrw73YL.o
ld: warning: can't add line info to anonymous symbol anon-func-0xF40 from
/var/tmp//ccrw73YL.o
output is:
ld: warning: can't add line info to anonymous symbol anon-func-0xF40 from
/var/tmp//ccrw73YL.o
ld: warning: can't add line info to anonymous symbol anon-func-0xF40 from
/var/tmp//ccrw73YL.o
ld: warning: can't add line info to anonymous symbol anon-func-0xF40 from
/var/tmp//ccrw73YL.o
ld: warning: can't add line info to anonymous symbol anon-func-0xF40 from
/var/tmp//ccrw73YL.o
ld: warning: can't add line info to anonymous symbol anon-func-0xF40 from
/var/tmp//ccrw73YL.o
ld: warning: can't add line info to anonymous symbol anon-func-0xF40 from
/var/tmp//ccrw73YL.o
ld: warning: can't add line info to anonymous symbol anon-func-0xF40 from
/var/tmp//ccrw73YL.o
ld: warning: can't add line info to anonymous symbol anon-func-0xF40 from
/var/tmp//ccrw73YL.o
ld: warning: can't add line info to anonymous symbol anon-func-0xF40 from
/var/tmp//ccrw73YL.o
ld: warning: can't add line info to anonymous symbol anon-func-0xF40 from
/var/tmp//ccrw73YL.o
ld: warning: can't add line info to anonymous symbol anon-func-0xF40 from
/var/tmp//ccrw73YL.o
ld: warning: can't add line info to anonymous symbol anon-func-0xF40 from
/var/tmp//ccrw73YL.o
ld: warning: can't add line info to anonymous symbol anon-func-0xF40 from
/var/tmp//ccrw73YL.o
ld: warning: can't add line info to anonymous symbol anon-func-0xF40 from
/var/tmp//ccrw73YL.o
ld: warning: can't add line info to anonymous symbol anon-func-0xF40 from
/var/tmp//ccrw73YL.o

The resulting binaries run fine however which suggest these warnings are
non-fatal. They should be suppressed if the warnings are incorrectly being
emitted by the compiler. I have attached an archive,
no_unwind_label_link_bu

[Bug tree-optimization/46957] New: http://blog.regehr.org/archives/320 Example 1

[jakub at gcc dot gnu.org]

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

   Summary: http://blog.regehr.org/archives/320 Example 1
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
CC: s...@gcc.gnu.org


void foo (void);
long a, b;
void
foo (void)
{
  int i;

  b = -1L;
  i = 0;
  while (i < 63)
{
  b *= 2L;
  i++;
}
  a = -(b + 1L);
}

doesn't have the loop optimized out, as we don't have {-1L, *, 2}_1 style
chrecs, only , +, style.  I wonder if we couldn't for << or multiplication by
power of two express {-1L, *, 2}_1 instead as -1L << ({0, +, 1}_1), or
for other multiplication, say {a, *, b}_1, as a * pow (b, {0, +, 1}_1) and use
that in compute_overall_effect_of_inner_loop etc. to sccp it.

Of course only if the resulting expression is cheap enough.

[Bug tree-optimization/46232] [4.6 regression] 64-bit gcc.dg/tree-ssa/pr14814.c FAILs on SPARC

[jamborm at gcc dot gnu.org]

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

--- Comment #6 from Martin Jambor  2010-12-15 
15:05:40 UTC ---
Well, SRA currently propagates sub-accesses across assignments only
from the RHS to the LHS.  I will have a look at how intrusive it would
be to add the other direction as well.

Nevertheless, this has been the case in 4.5 as well, how come the
testcase does not fail there?

[Bug middle-end/46916] gcc.dg/torture/stackalign/non-local-goto-[1,2].c ICEs compiler due to r167727

[howarth at nitro dot med.uc.edu]

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

--- Comment #65 from Jack Howarth  2010-12-15 
15:15:42 UTC ---
Iain, 
   Can you try labeling the unlikely sections with the function names as Apple
suggested and see if that helps with the problems with -g using honza patch?

[Bug middle-end/46916] gcc.dg/torture/stackalign/non-local-goto-[1,2].c ICEs compiler due to r167727

[iains at gcc dot gnu.org]

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

--- Comment #66 from Iain Sandoe  2010-12-15 15:17:29 
UTC ---
(In reply to comment #64)
Thanks Jack, I'll take a look at this info, if necessary. 

a couple of points;

this below has subsequently been replaced with an #undef of the target hook in
config/darwin10.h

> -  if (! for_eh)
> +  /* Suppress unwind labels when targeting 10.6 or later.  */ 
> +  if ((! for_eh) || (darwin_macosx_version_min &&
> strverscmp(darwin_macosx_version_min, "10.6") >= 0))
>  return;

this below is no longer properly functional with the new arrangement of options
processing.
(the test is now done in opts.c - if you leave this in you get a false warning
when -fno-exceptions is given on a g++ command line)

> +  /* Disable -freorder-blocks-and-partition for exception handling or when
> + the target requested unwind info.  */
> +  if (flag_reorder_blocks_and_partition && (flag_exceptions ||
> flag_unwind_tables))
> +{
> +  inform (input_location,
> +  "-freorder-blocks-and-partition does not work with exceptions 
> on
> this architecture");
> +  flag_reorder_blocks_and_partition = 0;
> +  flag_reorder_blocks = 1;
> +}

[Bug go/46958] New: Go ARM Does Not Compile

[joel at gcc dot gnu.org]

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

   Summary: Go ARM Does Not Compile
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
AssignedTo: i...@airs.com
ReportedBy: j...@gcc.gnu.org


arm-rtems4.11-gcc (GCC) 4.6.0 20101214 (experimental) [trunk revision 167806]

/users/joel/test-gcc/gcc-svn/libgo/runtime/go-caller.c: In function 'Caller':
/users/joel/test-gcc/gcc-svn/libgo/runtime/go-caller.c:34:60: error:
unsupported argument to '__builtin_return_address' [-Werror]
cc1: all warnings being treated as errors

[Bug go/46959] New: M68K Not Supported by Go

[joel at gcc dot gnu.org]

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

   Summary: M68K Not Supported by Go
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
AssignedTo: i...@airs.com
ReportedBy: j...@gcc.gnu.org


m68k-rtems4.11-gcc (GCC) 4.6.0 20101207 (experimental) [trunk revision 167563]

/users/joel/test-gcc/gcc-svn/libgo/runtime/go-go.c:40:3: error: #error must
define SAVE_REGS
/users/joel/test-gcc/gcc-svn/libgo/runtime/go-go.c: In function
'__go_run_goroutine_gc':
/users/joel/test-gcc/gcc-svn/libgo/runtime/go-go.c:348:3: error: 'SAVE_REGS'
undeclared (first use in this function)
/users/joel/test-gcc/gcc-svn/libgo/runtime/go-go.c:348:3: note: each undeclared
identifier is reported only once for each function it appears in
/users/joel/test-gcc/gcc-svn/libgo/runtime/go-go.c: In function
'__go_scanstacks':
/users/joel/test-gcc/gcc-svn/libgo/runtime/go-go.c:437:3: error: 'SAVE_REGS'
undeclared (first use in this function)
make[4]: *** [go-go.lo] Error 1

[Bug go/46960] New: MIPS Not Supported by Go

[joel at gcc dot gnu.org]

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

   Summary: MIPS Not Supported by Go
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
AssignedTo: i...@airs.com
ReportedBy: j...@gcc.gnu.org


mips-rtems4.11-gcc (GCC) 4.6.0 20101214 (experimental) [trunk revision 167806]

/users/joel/test-gcc/gcc-svn/libgo/runtime/go-go.c:40:3: error: #error must
define SAVE_REGS
/users/joel/test-gcc/gcc-svn/libgo/runtime/go-go.c: In function
'__go_run_goroutine_gc':
/users/joel/test-gcc/gcc-svn/libgo/runtime/go-go.c:347:3: error: 'SAVE_REGS'
undeclared (first use in this function)
/users/joel/test-gcc/gcc-svn/libgo/runtime/go-go.c:347:3: note: each undeclared
identifier is reported only once for each function it appears in
/users/joel/test-gcc/gcc-svn/libgo/runtime/go-go.c: In function
'__go_scanstacks':
/users/joel/test-gcc/gcc-svn/libgo/runtime/go-go.c:436:3: error: 'SAVE_REGS'
undeclared (first use in this function)

[Bug go/46961] New: PowerPC Not Supported By Go

[joel at gcc dot gnu.org]

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

   Summary: PowerPC Not Supported By Go
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
AssignedTo: i...@airs.com
ReportedBy: j...@gcc.gnu.org


powerpc-rtems4.11-gcc (GCC) 4.6.0 20101214 (experimental) [trunk revision
167806]

/users/joel/test-gcc/gcc-svn/libgo/runtime/go-go.c:40:3: error: #error must
define SAVE_REGS
/users/joel/test-gcc/gcc-svn/libgo/runtime/go-go.c: In function
'__go_run_goroutine_gc':
/users/joel/test-gcc/gcc-svn/libgo/runtime/go-go.c:347:3: error: 'SAVE_REGS'
undeclared (first use in this function)
/users/joel/test-gcc/gcc-svn/libgo/runtime/go-go.c:347:3: note: each undeclared
identifier is reported only once for each function it appears in
/users/joel/test-gcc/gcc-svn/libgo/runtime/go-go.c: In function
'__go_scanstacks':
/users/joel/test-gcc/gcc-svn/libgo/runtime/go-go.c:436:3: error: 'SAVE_REGS'
undeclared (first use in this function)

[Bug go/46962] New: SPARC Not Supported By Go

[joel at gcc dot gnu.org]

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

   Summary: SPARC Not Supported By Go
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
AssignedTo: i...@airs.com
ReportedBy: j...@gcc.gnu.org


sparc-rtems4.11-gcc (GCC) 4.6.0 20101213 (experimental) [trunk revision 167770]

/users/joel/test-gcc/gcc-svn/libgo/runtime/go-go.c: In function
'__go_run_goroutine_gc':
/users/joel/test-gcc/gcc-svn/libgo/runtime/go-go.c:348:3: error: 'SAVE_REGS'
undeclared (first use in this function)
/users/joel/test-gcc/gcc-svn/libgo/runtime/go-go.c:348:3: note: each undeclared
identifier is reported only once for each function it appears in
/users/joel/test-gcc/gcc-svn/libgo/runtime/go-go.c: In function
'__go_scanstacks':
/users/joel/test-gcc/gcc-svn/libgo/runtime/go-go.c:437:3: error: 'SAVE_REGS'
undeclared (first use in this function)

[Bug libgcj/40947] Invalid flag usage: Wl,-rpath, -Wx,-option must appear after -_SYSTYPE_SVR4

[htl10 at users dot sourceforge.net]

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

Hin-Tak Leung  changed:

   What|Removed |Added

  Known to work||
  Known to fail||

--- Comment #4 from Hin-Tak Leung  
2010-12-15 14:57:27 UTC ---
Still same problem with 4.4.5. (haven't tried 4.5.1 since it is still affected
by bug 44959).

[Bug go/46963] New: SPARC64 Not Supported by Go

[joel at gcc dot gnu.org]

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

   Summary: SPARC64 Not Supported by Go
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
AssignedTo: i...@airs.com
ReportedBy: j...@gcc.gnu.org


sparc64-rtems4.11-gcc (GCC) 4.6.0 20101213 (experimental) [trunk revision
167770]

/users/joel/test-gcc/gcc-svn/libgo/runtime/go-go.c:40:3: error: #error must
define SAVE_REGS
/users/joel/test-gcc/gcc-svn/libgo/runtime/go-go.c: In function
'__go_run_goroutine_gc':
/users/joel/test-gcc/gcc-svn/libgo/runtime/go-go.c:348:3: error: 'SAVE_REGS'
undeclared (first use in this function)
/users/joel/test-gcc/gcc-svn/libgo/runtime/go-go.c:348:3: note: each undeclared
identifier is reported only once for each function it appears in
/users/joel/test-gcc/gcc-svn/libgo/runtime/go-go.c: In function
'__go_scanstacks':
/users/joel/test-gcc/gcc-svn/libgo/runtime/go-go.c:437:3: error: 'SAVE_REGS'
undeclared (first use in this function)

[Bug middle-end/39976] [4.5/4.6 Regression] Big sixtrack degradation on powerpc 32/64 after revision r146817

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #30 from Jakub Jelinek  2010-12-15 
15:32:48 UTC ---
Is this still a problem on the current trunk?

[Bug middle-end/43548] internal compiler error: in ggc_set_mark, at ggc-page.c:1338

[alanh at fairlite dot co.uk]

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

--- Comment #4 from Alan Hourihane  2010-12-15 
16:20:56 UTC ---
Created attachment 22766
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22766
preprocessed source

[Bug middle-end/43548] internal compiler error: in ggc_set_mark, at ggc-page.c:1338

[alanh at fairlite dot co.uk]

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

Alan Hourihane  changed:

   What|Removed |Added

  Attachment #22766|0   |1
is obsolete||

--- Comment #5 from Alan Hourihane  2010-12-15 
16:22:29 UTC ---
Created attachment 22767
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22767
preprocess source

sorry the last one was the garbled binary.

[Bug go/46964] New: ARM Not Supported by Go

[joel at gcc dot gnu.org]

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

   Summary: ARM Not Supported by Go
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
AssignedTo: i...@airs.com
ReportedBy: j...@gcc.gnu.org


arm-rtems4.11-gcc (GCC) 4.6.0 20101214 (experimental) [trunk revision 167806]

does not define SAVE_REGS in gcc-go.c for ARM.  Is this correct for ARM?

#elif defined(__arm__)
 #define SAVE_REGS asm ("" : : : "r4", "r5", "r6", "r7", "r8", "r9", \
 "r10", "r11", "r12", "r13", "r14", "r15" )

>From http://en.wikipedia.org/wiki/Calling_convention, the standard ARM calling
convention allocates the 16 ARM registers as:

* r15 is the program counter.
* r14 is the link register. (The BL instruction, used in a subroutine call,
stores the return address in this register).
* r13 is the stack pointer. (The Push/Pop instructions in "Thumb" operating
mode use this register only).
* r12 is the Intra-Procedure-call scratch register.
* r4 to r11: used to hold local variables.
* r0 to r3: used to hold argument values passed to a subroutine ... and
also hold results returned from a subroutine.

[Bug middle-end/43548] internal compiler error: in ggc_set_mark, at ggc-page.c:1338

[alanh at fairlite dot co.uk]

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

--- Comment #7 from Alan Hourihane  2010-12-15 
16:30:29 UTC ---
If I disable -O2 it works.

[Bug go/46959] M68K Not Supported by Go

[joel at gcc dot gnu.org]

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

--- Comment #1 from Joel Sherrill  2010-12-15 16:03:49 
UTC ---
How does this look for m68k?  I recall d0/d1/a0/a1 are clobbered by the caller.
 a6 is a frame pointer, a7 is the stack pointer.  So is this the set that needs
to be handled for m68k?

#elif defined(__m68k__)
 #define SAVE_REGS asm ("" : : : "a2", "a3", "a4", "a5", "a6", "a7", \
 "d2", "d3", "d4", "d5", "d6", "d7" )

[Bug go/46965] New: SH Go Does not Compile (__builtin_return_address)

[joel at gcc dot gnu.org]

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

   Summary: SH Go Does not Compile (__builtin_return_address)
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
AssignedTo: i...@airs.com
ReportedBy: j...@gcc.gnu.org


sh-rtems4.11-gcc (GCC) 4.6.0 20101214 (experimental) [trunk revision 167806]

/users/joel/test-gcc/gcc-svn/libgo/runtime/go-caller.c: In function 'Caller':
/users/joel/test-gcc/gcc-svn/libgo/runtime/go-caller.c:34:60: error:
unsupported argument to '__builtin_return_address' [-Werror]
cc1: all warnings being treated as errors

[Bug tree-optimization/45791] Missed devirtualization

[jamborm at gcc dot gnu.org]

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

--- Comment #14 from Martin Jambor  2010-12-15 
16:07:31 UTC ---
(In reply to comment #9)
> OK, main() code seems to optimize out that is an imrovement. Is it optimized
> away with your patch pre-IPA too? 

Yes.  Just before IPA, in fact.

> 
> Derived() is also devirtualizable:
> 

It could be done intraprocedurally if, unlike for automatically
allocated decls, we considered all calls as potentially changing the
dynamic type in unknown ways while doing the dynamic type change
detection.  This then however becomes essentially the same thing as
devirtualization based on the constant folding, perhaps only more
complicated.

It could be optimized by IPA-CP if we can confirm that all callers are
automatically allocated (or that we generally have them under
control).  This should be relatively easy, I will have a look at that.
Mainly because we may be able to widen scope of objects under our
control later.

[Bug middle-end/46221] [4.6 Regression] huge number of c++ testsuite failures, libstdc++.so alias missing

[davek at gcc dot gnu.org]

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

Dave Korn  changed:

   What|Removed |Added

 Target|powerpc-linux, i?86-linux,  |powerpc-linux, i?86-linux,
   |alpha-linux |alpha-linux, i?86-pc-cygwin
 Status|RESOLVED|REOPENED
 CC||davek at gcc dot gnu.org
 Depends on||46674
 Resolution|FIXED   |
 AssignedTo|rguenth at gcc dot gnu.org  |davek at gcc dot gnu.org

--- Comment #26 from Dave Korn  2010-12-15 16:28:12 
UTC ---
(In reply to comment #25)
> *** Bug 46674 has been marked as a duplicate of this bug. ***

Actually, it's a genuine bug in the patch; it ends up comparing C identifiers
to actual assembler names, which works fine when there's no USER_LABEL_PREFIX
and when none of the nodes in question have __asm("..") names, but runs into
problems if/when there is/they do.

See attachment 22765 for the patch to resolve all this by always using
assembler names.  Bootstraps and testruns are under way.

[Bug go/46959] M68K Not Supported by Go

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

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

--- Comment #2 from Andreas Schwab  2010-12-15 16:40:08 
UTC ---
You cannot put reserved registers in the clobber list.

[Bug middle-end/46674] [4.6 Regression] Weak alias is mistakenly optimized away

[davek at gcc dot gnu.org]

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

--- Comment #11 from Dave Korn  2010-12-15 16:17:54 
UTC ---
Created attachment 22765
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22765
Lower all C identifiers to actual assembler symbols for comparison.

This should resolve the problem by ensuring that aliases and decls are lowered
to the canonical assembler form before doing any comparisons or testing if they
are used.

[Bug middle-end/43548] internal compiler error: in ggc_set_mark, at ggc-page.c:1338

[alanh at fairlite dot co.uk]

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

Alan Hourihane  changed:

   What|Removed |Added

 CC||alanh at fairlite dot co.uk

--- Comment #3 from Alan Hourihane  2010-12-15 
16:19:55 UTC ---
I'm bumping into this on m68k-atari-mint using libpcre-8.10. And although the
mint target support isn't in gcc (yet) I thought it might help this bug along.

m68k-atari-mint-g++ -DHAVE_CONFIG_H -I. -O2 -pipe -D_GNU_SOURCE -MT
pcrecpp_unittest.o -MD -MP -MF .deps/pcrecpp_unittest.Tpo -c -o
pcrecpp_unittest.o pcrecpp_unittest.cc

Internal compiler error: Error reporting routines re-entered.
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
{standard input}: Assembler messages:
{standard input}:4997: Warning: partial line at end of file ignored
m68k-atari-mint-g++: Internal error: Bus Error (program cc1plus)
Please submit a full bug report.
See  for instructions.

[Bug middle-end/43548] internal compiler error: in ggc_set_mark, at ggc-page.c:1338

[alanh at fairlite dot co.uk]

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

--- Comment #6 from Alan Hourihane  2010-12-15 
16:24:57 UTC ---
Ignore comment 3, wrong output. Here's the correct one.

m68k-atari-mint-g++ -DHAVE_CONFIG_H -I. -O2 -pipe -D_GNU_SOURCE -MT
pcrecpp_unittest.o -MD -MP -MF .deps/pcrecpp_unittest.Tpo -c -o
pcrecpp_unittest.o pcrecpp_unittest.cc
pcrecpp_unittest.cc: In function 'int main(int, char**)':
pcrecpp_unittest.cc:809:5: internal compiler error: in ggc_set_mark, at
ggc-page.c:1338
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug go/46964] ARM Not Supported by Go

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  2010-12-15 16:57:07 UTC ---
On Wed, 15 Dec 2010, joel at gcc dot gnu.org wrote:

> does not define SAVE_REGS in gcc-go.c for ARM.  Is this correct for ARM?
> 
> #elif defined(__arm__)
>  #define SAVE_REGS asm ("" : : : "r4", "r5", "r6", "r7", "r8", "r9", \
>  "r10", "r11", "r12", "r13", "r14", "r15" )

If this is built for each multilib then you need to allow for the 
possibility of VFP/NEON multilibs - there are call-preserved NEON 
registers as well (s16-s31/d8-d15/q4-q7, see AAPCS).  However, not all of 
the registers you list above need preserving in AAPCS.

But rather than trying to duplicate such information for all targets in 
go-go.c, wouldn't it be better just to call __builtin_unwind_init, or if 
that function doesn't have quite the right semantics then another built-in 
function defined to have the right semantics?

[Bug libstdc++/46869] FAIL: 20_util/enable_shared_from_this/cons/constexpr.cc scan-assembler-not _ZNSt23enable_shared_from_thisIiEC2Ev

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE  2010-12-15 17:08:00 UTC ---
> --- Comment #4 from Paolo Carlini  
> 2010-12-15 12:20:12 UTC ---
> Rainer, if in order to reduce the noise you want to simply xfail for now the
> failing tests it's ok with me. Honestly, I don't know at the moment if we can
> solve the issue in a more elegant way for 4.6.0.

I'll submit a patch as soon as I get to that.  It would be helpful to
keep the noise down indeed.

Thanks.
Rainer

[Bug tree-optimization/46232] [4.6 regression] 64-bit gcc.dg/tree-ssa/pr14814.c FAILs on SPARC

[ebotcazou at gcc dot gnu.org]

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

--- Comment #7 from Eric Botcazou  2010-12-15 
17:07:44 UTC ---
> Nevertheless, this has been the case in 4.5 as well, how come the
> testcase does not fail there?

The generated code is identical on mainline and 4.5 branch so there is no
actual regression.  It's simply the confusing notation

  t$e$1_10 = MEM[(struct YY *)&D.1994 + 8B]

on the mainline instead of

  t$e$1_10 = D.1994.e[1];

on the 4.5 branch that lets you think there is still an indirection.  It is
introduced during ESRA:

  D.1995 = r_2(D)->v;
  D.1994 = D.1995;
  t = D.1994;
  D.1980_4 = t.e[1];

becomes

  D.1995 = r_2(D)->v;
  D.1994 = D.1995;
  t = D.1994;
  t$e$1_10 = MEM[(struct YY *)&D.1994 + 8B];
  D.1980_4 = t$e$1_10;

instead of

  D.1995 = r_2(D)->v;
  D.1994 = D.1995;
  t = D.1994;
  t$e$1_10 = D.1994.e[1];
  D.1980_4 = t$e$1_10;

on the 4.5 branch.  This looks totally useless.

[Bug middle-end/46916] gcc.dg/torture/stackalign/non-local-goto-[1,2].c ICEs compiler due to r167727

[iains at gcc dot gnu.org]

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

--- Comment #67 from Iain Sandoe  2010-12-15 17:11:28 
UTC ---
Created attachment 22768
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22768
darwin-function-section-patch

OK - sorted out a couple of minor glitches...
...I'm going to reg-test the attached more widely (powerpc + other languages).

this does not suffer from the debug issue... but...

Honza, two points:

1a / opts.c - this should probably be placed _after_ all the tests that might
set x_flag_reorder_blocks_and_partition to 0.

1b / it should be conditional on the User _not_ having set
x_flag_reorder_functions ;)

something like --- (in the attached patch too)
  if (opts->x_flag_reorder_blocks_and_partition
  && !opts_set->x_flag_reorder_functions)
opts->x_flag_reorder_functions = 1;

===

2.  The patch attached actually clears 46904 as well,  BUT there are
several new fails

FAIL: partition{1,2}.C   * -fprofile-use
FAIL: gcc.dg/tree-prof/bb-reorg.c compilation,  -fprofile-use -D_PROFILE_USE
FAIL: gcc.dg/tree-prof/pr34999.c compilation,  -fprofile-use -D_PROFILE_USE

these are 
FATAL:Symbol _foo.eh already defined.

can you separate the portion of your patch that would resolve this - without
introducing the elements we think are responsible for the debug problem?

[Bug fortran/28105] Check for memory allocations bigger than size_t

[jb at gcc dot gnu.org]

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

--- Comment #11 from Janne Blomqvist  2010-12-15 
17:15:31 UTC ---
Author: jb
Date: Wed Dec 15 17:15:25 2010
New Revision: 167860

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167860
Log:
PR 28105 Remove size<0 checks before calling malloc/realloc

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans.c

[Bug c++/42083] [C++0x] ICE on invalid with "tree check: expected aggr_init_expr, have error_mark in build_value_init"

[paolo at gcc dot gnu.org]

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

--- Comment #5 from paolo at gcc dot gnu.org  
2010-12-15 17:35:09 UTC ---
Author: paolo
Date: Wed Dec 15 17:35:04 2010
New Revision: 167862

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167862
Log:
/cp
2010-12-15  Paolo Carlini  

PR c++/42083
* init.c (build_value_init): Check build_special_member_call return
value for error_mark_node.

/testsuite
2010-12-15  Paolo Carlini  

PR c++/42083
* g++.dg/cpp0x/lambda/lambda-ice2.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-ice2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/init.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/46404] [4.6 Regression] ICE: definition in block 5 does not dominate use in block 32 with -O -fgraphite-identity -fno-tree-scev-cprop

[spop at gcc dot gnu.org]

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

Sebastian Pop  changed:

   What|Removed |Added

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

--- Comment #2 from Sebastian Pop  2010-12-15 17:38:37 
UTC ---
I cannot reproduce this error on trunk r167844.
I am running a git bisect to identify which patch fixed this PR.

[Bug middle-end/45310] ICE: verify_stmts failed: Dead STMT in EH table with -O1 -fnon-call-exceptions

[zsojka at seznam dot cz]

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

--- Comment #3 from Zdenek Sojka  2010-12-15 17:39:39 
UTC ---
Created attachment 22769
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22769
another testcase

$ gcc -O -fnon-call-exceptions pr45310-2.C 
pr45310-2.C: In destructor 'B::~B()':
pr45310-2.C:21:8: error: dead STMT in EH table
# VUSE <.MEM_21>
D.2188_16 = *a_15;

pr45310-2.C:21:8: internal compiler error: verify_stmts failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Bugzilla search for the error message failed ("Dead" changed to "dead"), so I
am pasting current output.

[Bug tree-optimization/46232] [4.6 regression] 64-bit gcc.dg/tree-ssa/pr14814.c FAILs on SPARC

[jamborm at gcc dot gnu.org]

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

--- Comment #8 from Martin Jambor  2010-12-15 
17:40:00 UTC ---
I see.  I think this is not a P1 stuff then and should definitely not
block a release.  I'd rather not promise anything, but I'll add this
to my TODO list and hope I will try to address this for 4.7.

As far as the MEM_REF instead of ARRAY_REF awkwardness is concerned, I
don't feel like discussing merits of the former here but trust me
there are reasons for this.  If you want to have a look for yourself,
compare 4.5 and 4.6 build_ref_for_offset implementations (including
build_ref_for_model in 4.6) and especially their callers (and the
number of them).  And of course there was PR 44972.

[Bug c++/42083] [C++0x] ICE on invalid with "tree check: expected aggr_init_expr, have error_mark in build_value_init"

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #6 from Paolo Carlini  2010-12-15 
17:42:20 UTC ---
Done.

[Bug middle-end/46404] [4.6 Regression] ICE: definition in block 5 does not dominate use in block 32 with -O -fgraphite-identity -fno-tree-scev-cprop

[spop at gcc dot gnu.org]

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

--- Comment #4 from Sebastian Pop  2010-12-15 17:55:26 
UTC ---
Ok, I will have a look at that one as well.
Thanks for pointing out that this error was not fixed, but probably hidden.

[Bug debug/46815] Invalid DW_AT_location for a retval instance of a class that has a virtual function

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  2010-12-15 
17:50:40 UTC ---
Author: jakub
Date: Wed Dec 15 17:50:34 2010
New Revision: 167865

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167865
Log:
PR debug/46815
* cp-gimplify.c (cp_genericize): When changing RESULT_DECL
into invisible reference, change also DECL_VALUE_EXPR of
NRV optimized variable.

* g++.dg/guality/pr46815.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/guality/pr46815.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-gimplify.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/46232] [4.6 regression] 64-bit gcc.dg/tree-ssa/pr14814.c FAILs on SPARC

[ebotcazou at gcc dot gnu.org]

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

--- Comment #9 from Eric Botcazou  2010-12-15 
17:58:51 UTC ---
> I see.  I think this is not a P1 stuff then and should definitely not
> block a release.  I'd rather not promise anything, but I'll add this
> to my TODO list and hope I will try to address this for 4.7.

Right, I think it should be marked XFAIL on the mainline.

> As far as the MEM_REF instead of ARRAY_REF awkwardness is concerned, I
> don't feel like discussing merits of the former here but trust me
> there are reasons for this.  If you want to have a look for yourself,
> compare 4.5 and 4.6 build_ref_for_offset implementations (including
> build_ref_for_model in 4.6) and especially their callers (and the
> number of them).  And of course there was PR 44972.

Look at PR 46801 though.  Scalarization of these records in simple contexts
(i.e. no indirection in sight) worked in GCC 4.x up to very recently.  Now it
seems that MEM_REF has introduced artificial indirections all over the place,
leading to the pessimization of these cases.

[Bug middle-end/46404] [4.6 Regression] ICE: definition in block 5 does not dominate use in block 32 with -O -fgraphite-identity -fno-tree-scev-cprop

[zsojka at seznam dot cz]

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

--- Comment #3 from Zdenek Sojka  2010-12-15 17:52:09 
UTC ---
I can't reproduce it neither with the reduced testcase, but the original one
still fails (I am sorry for not mentioning it was reduced from
gcc.dg/graphite/pr42284.c):

$ gcc -O -fgraphite-identity -fno-tree-scev-cprop pr42284.i 
/mnt/svn/gcc-trunk/gcc/testsuite/gcc.dg/graphite/pr42284.c: In function
'inflate_fixed':
/mnt/svn/gcc-trunk/gcc/testsuite/gcc.dg/graphite/pr42284.c:11:1: error:
definition in block 5 does not dominate use in block 59
for SSA_NAME: i_34 in statement:
D.2738_52 = 256 - i_34;
/mnt/svn/gcc-trunk/gcc/testsuite/gcc.dg/graphite/pr42284.c:11:1: internal
compiler error: verify_ssa failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug tree-optimization/46801] [4.6 Regression] FAIL: gnat.dg/pack9.adb scan-tree-dump-not optimized "gnat_rcheck"

[jamborm at gcc dot gnu.org]

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

--- Comment #4 from Martin Jambor  2010-12-15 
18:13:27 UTC ---
(In reply to comment #2)
> http://gcc.gnu.org/ml/gcc-patches/2010-11/msg02722.html

Does this mean it also fails on i586 or is this a hppa thing?
Thanks.

[Bug tree-optimization/46801] [4.6 Regression] FAIL: gnat.dg/pack9.adb scan-tree-dump-not optimized "gnat_rcheck"

[ebotcazou at gcc dot gnu.org]

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

--- Comment #5 from Eric Botcazou  2010-12-15 
18:21:38 UTC ---
> Does this mean it also fails on i586 or is this a hppa thing?

It fails everywhere.

[Bug middle-end/46966] New: [4.6 Regression] ICE: in execute_cse_reciprocals, at tree-ssa-math-opts.c:474 with -floop-interchange -fno-tree-copy-prop -fno-tree-loop-im

[zsojka at seznam dot cz]

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

   Summary: [4.6 Regression] ICE: in execute_cse_reciprocals, at
tree-ssa-math-opts.c:474 with -floop-interchange
-fno-tree-copy-prop -fno-tree-loop-im
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
CC: s...@gcc.gnu.org
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


Created attachment 22770
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22770
reduced testcase (from graphite/interchange-0.c)

Compiler output:
$ gcc -O -floop-interchange -ffast-math -fno-tree-copy-prop -fno-tree-loop-im
pr46966.c  
pr46966.c: In function 'foo':
pr46966.c:3:6: internal compiler error: in execute_cse_reciprocals, at
tree-ssa-math-opts.c:474
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

(gdb) bt
#0  fancy_abort (file=0x117cbd0 "/mnt/svn/gcc-trunk/gcc/tree-ssa-math-opts.c",
line=474, 
function=0x117cc70 "execute_cse_reciprocals") at
/mnt/svn/gcc-trunk/gcc/diagnostic.c:892
#1  0x009b6e3e in execute_cse_reciprocals () at
/mnt/svn/gcc-trunk/gcc/tree-ssa-math-opts.c:474
#2  0x007ecabf in execute_one_pass (pass=0x1635d20) at
/mnt/svn/gcc-trunk/gcc/passes.c:1553
#3  0x007ecd85 in execute_pass_list (pass=0x1635d20) at
/mnt/svn/gcc-trunk/gcc/passes.c:1608
#4  0x007ecd97 in execute_pass_list (pass=0x1634d60) at
/mnt/svn/gcc-trunk/gcc/passes.c:1609
#5  0x0092da36 in tree_rest_of_compilation (fndecl=0x75cc4f00) at
/mnt/svn/gcc-trunk/gcc/tree-optimize.c:422
#6  0x00af32e2 in cgraph_expand_function (node=0x75ce4000) at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1508
#7  0x00af58ba in cgraph_expand_all_functions () at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1567
#8  cgraph_optimize () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1827
#9  0x00af5e3a in cgraph_finalize_compilation_unit () at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1031
#10 0x00508e0c in c_write_global_declarations () at
/mnt/svn/gcc-trunk/gcc/c-decl.c:9845
#11 0x008d7206 in compile_file (argc=17, argv=0x7fffda88) at
/mnt/svn/gcc-trunk/gcc/toplev.c:591
#12 do_compile (argc=17, argv=0x7fffda88) at
/mnt/svn/gcc-trunk/gcc/toplev.c:1874
#13 toplev_main (argc=17, argv=0x7fffda88) at
/mnt/svn/gcc-trunk/gcc/toplev.c:1937
#14 0x76586bbd in __libc_start_main () from /lib/libc.so.6
#15 0x004ef7f5 in _start ()

Tested revisions:
r167809 - crash
r167723 - crash
r165699 - OK
4.5 r166509 - OK

[Bug c++/46968] New: ICE in dependent_type_p when compiling in C++0x with g++ trunk

[gcc at jey dot kottalam.net]

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

   Summary: ICE in dependent_type_p when compiling in C++0x with
g++ trunk
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@jey.kottalam.net
  Host: x86_64-unknown-linux-gnu
Target: x86_64-unknown-linux-gnu
 Build: x86_64-unknown-linux-gnu


I'm using g++ built from r167866 from svn://gcc.gnu.org/svn/gcc/trunk on an
Intel core2.


j...@fnord:~/programming/pairrec$ g++-trunk -v -save-temps -x c++ -std=c++0x
/home/jey/programming/gcc/tbb/include/tbb/tbb_machine.h 
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/home/jey/bins/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/home/jey/bins
--program-suffix=-trunk --with-cpu=native --with-arch=native
--enable-languages=c,c++,fortran
Thread model: posix
gcc version 4.6.0 20101215 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++0x' '-shared-libgcc'  
 /home/jey/bins/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/cc1plus -E -quiet -v
-D_GNU_SOURCE /home/jey/programming/gcc/tbb/include/tbb/tbb_machine.h
-march=core2 -mcx16 -msahf --param l1-cache-size=32 --param
l1-cache-line-size=64 --param l2-cache-size=2048 -mtune=core2 -std=c++0x
-fpch-preprocess -o tbb_machine.ii
ignoring nonexistent directory
"/home/jey/bins/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../x86_64-unknown-linux-gnu/include"
ignoring duplicate directory "/opt/intel/composerxe-2011.1.107/mkl/include"
ignoring duplicate directory "/opt/intel/Compiler/11.1/073/ipp/em64t/include"
#include "..." search starts here:
#include <...> search starts here:
 /opt/intel/composerxe-2011.1.107/mkl/include
 /opt/intel/Compiler/11.1/073/ipp/em64t/include
 .

/home/jey/bins/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0

/home/jey/bins/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/x86_64-unknown-linux-gnu

/home/jey/bins/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/backward
 /home/jey/bins/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/include
 /usr/local/include
 /home/jey/bins/include
 /home/jey/bins/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++0x' '-shared-libgcc'  
 /home/jey/bins/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/cc1plus
-fpreprocessed tbb_machine.ii -march=core2 -mcx16 -msahf --param
l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=2048
-mtune=core2 -quiet -dumpbase tbb_machine.h -auxbase tbb_machine -std=c++0x
-version -o tbb_machine.s
GNU C++ (GCC) version 4.6.0 20101215 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.6.0 20101215 (experimental), GMP version
4.3.2, MPFR version 3.0.0-p3, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C++ (GCC) version 4.6.0 20101215 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.6.0 20101215 (experimental), GMP version
4.3.2, MPFR version 3.0.0-p3, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: c153ef71f7a566be2220922172ab71b0
/home/jey/programming/gcc/tbb/include/tbb/tbb_machine.h: In function ‘T
__TBB_ReverseBits(T)’:
/home/jey/programming/gcc/tbb/include/tbb/tbb_machine.h:686:66: internal
compiler error: in dependent_type_p, at cp/pt.c:17929
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

[Bug c++/46968] ICE in dependent_type_p when compiling in C++0x with g++ trunk

[gcc at jey dot kottalam.net]

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

--- Comment #1 from Jey Kottalam  2010-12-15 
19:20:34 UTC ---
Created attachment 22771
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22771
testcase

This is from Intel TBB 3.0.

[Bug c++/46968] ICE in dependent_type_p when compiling in C++0x with g++ trunk

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #2 from Jonathan Wakely  2010-12-15 
19:22:41 UTC ---
dup of PR 46670

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

[Bug c++/46670] [4.6 Regression] ICE in dependent_type_p, at cp/pt.c:17553

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||gcc at jey dot kottalam.net

--- Comment #4 from Jonathan Wakely  2010-12-15 
19:22:41 UTC ---
*** Bug 46968 has been marked as a duplicate of this bug. ***

[Bug libgcj/40947] Invalid flag usage: Wl,-rpath, -Wx,-option must appear after -_SYSTYPE_SVR4

[rwild at gcc dot gnu.org]

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

--- Comment #5 from Ralf Wildenhues  2010-12-15 
19:23:05 UTC ---
Can you attach alphaev68-dec-osf5.1a/libjava/config.log for this failure
please?
Thanks.

[Bug tree-optimization/46969] New: -O -ftree-vectorize -ftree-parallelize-loops=2 -fcompare-debug

[zsojka at seznam dot cz]

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

   Summary: -O -ftree-vectorize -ftree-parallelize-loops=2
-fcompare-debug
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
CC: aol...@gcc.gnu.org
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


Created attachment 22772
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22772
reduced testcase (from gcc.dg/vect/pr44507.c)

This problem seems to be quite fragile.

$ gcc -O -ftree-vectoriztree-parallelize-loops=2 -fcompare-debug pr46969.c 
gcc: error: pr46969.c: -fcompare-debug failure (length)

Tested revisions:
r167809 - fail
r165699 - fail
r161659 - OK
4.5 r166509 - OK

[Bug tree-optimization/46969] -fcompare-debug failure with -O -ftree-vectorize -ftree-parallelize-loops=2

[zsojka at seznam dot cz]

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

--- Comment #1 from Zdenek Sojka  2010-12-15 19:29:53 
UTC ---
Created attachment 22773
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22773
dumps - pr46969.*gkd

[Bug libgomp/46967] New: lots of testsuite failures with libgomp on hppa-hp-hpux11.31

[bugzilla-gcc at thewrittenword dot com]

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

   Summary: lots of testsuite failures with libgomp on
hppa-hp-hpux11.31
   Product: gcc
   Version: 4.4.5
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bugzilla-...@thewrittenword.com


Running /opt/build/gcc-4.4.5/libgomp/testsuite/libgomp.c/c.exp ...
FAIL: libgomp.c/copyin-1.c execution test
FAIL: libgomp.c/copyin-3.c execution test
FAIL: libgomp.c/nested-2.c execution test
FAIL: libgomp.c/pr24455.c execution test
FAIL: libgomp.c/pr29947-2.c execution test
FAIL: libgomp.c/pr42942.c execution test
Running /opt/build/gcc-4.4.5/libgomp/testsuite/libgomp.c++/c++.exp ...
Pid 23693 in trap loop, signal 11
[snip]
Pid 771 in trap loop, signal 11
FAIL: libgomp.c++/ctor-9.C  -O3 -fomit-frame-pointer -funroll-loops
execution test
FAIL: libgomp.c++/for-1.C  -O1  execution test
FAIL: libgomp.c++/for-1.C  -O2  execution test
FAIL: libgomp.c++/for-1.C  -O3 -fomit-frame-pointer  execution test
Pid 930 in trap loop, signal 11
FAIL: libgomp.c++/for-1.C  -O3 -fomit-frame-pointer -funroll-loops
execution test
[snip]
Pid 15005 in trap loop, signal 11
FAIL: libgomp.fortran/task1.f90  -O0  execution test
Pid 15641 in trap loop, signal 11
Test Run By pogma on Thu Dec  2 19:18:38 2010
Native configuration is hppa2.0-hp-hpux11.31
=== libgomp Summary ===

# of expected passes2285
# of unexpected failures173
# of unsupported tests  9


HP-UX 11.23 doesn't have any problems with the libgomp tests.

See also my email to gcc@ asking for help diagnosing this:
http://gcc.gnu.org/ml/gcc/2010-12/msg00116.html

[Bug tree-optimization/46970] New: [4.3/4.4/4.5/4.6 Regression] wrong code with -Os -ftree-loop-linear

[zsojka at seznam dot cz]

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

   Summary: [4.3/4.4/4.5/4.6 Regression] wrong code with -Os
-ftree-loop-linear
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz


Created attachment 22774
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22774
reduced testcase (from gcc.dg/pr29581-3.c)

Output:
$ gcc -Os -ftree-loop-linear pr46970.c
or
$ gcc -O -fno-tree-ch -ftree-loop-linear pr46970.c
(-Os implies -fno-tree-ch)

$ ./a.out 
Aborted

Tested versions:
r167809 - fail
4.5.1 - fail
4.4.5 - fail
4.3.5 - fail
4.2.4 - ICE
4.1.2 - ICE
4.0.4 - OK

[Bug tree-optimization/46969] [4.6 Regression] -fcompare-debug failure with -O -ftree-vectorize -ftree-parallelize-loops=2

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.12.15 20:14:58
 CC||irar at il dot ibm.com
   Target Milestone|--- |4.6.0
Summary|-fcompare-debug failure |[4.6 Regression]
   |with -O -ftree-vectorize|-fcompare-debug failure
   |-ftree-parallelize-loops=2  |with -O -ftree-vectorize
   ||-ftree-parallelize-loops=2
 Ever Confirmed|0   |1

--- Comment #2 from H.J. Lu  2010-12-15 20:14:58 
UTC ---
It is caused by revision 161797:

http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg00151.html

[Bug middle-end/46966] [4.6 Regression] ICE: in execute_cse_reciprocals, at tree-ssa-math-opts.c:474 with -floop-interchange -fno-tree-copy-prop -fno-tree-loop-im

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.12.15 20:19:00
   Target Milestone|--- |4.6.0
 Ever Confirmed|0   |1

--- Comment #1 from H.J. Lu  2010-12-15 20:19:00 
UTC ---
This is caused by revision 167348:

http://gcc.gnu.org/ml/gcc-cvs/2010-12/msg00029.html

[Bug fortran/46945] [4.6 Regression] gfortran.dg/unpack_zerosize_1.f90 FAILs with -ftree-vrp -fno-tree-ccp -fno-tree-fre

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  2010-12-15 
20:20:19 UTC ---
Author: jakub
Date: Wed Dec 15 20:20:10 2010
New Revision: 167871

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167871
Log:
PR fortran/46945
* trans-array.c (gfc_array_init_size): Perform stride overflow
checking and multiplication by element_size in size_type_node instead
of sizetype, return value with size_type_node type instead of
sometimes with sizetype and sometimes with gfc_array_index_type.

* gfortran.dg/pr46945.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr46945.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-array.c
trunk/gcc/testsuite/ChangeLog