[Bug objc/18255] [GNU runtime] Protocols are not initialized correctly

[tilo at pruetz dot net]

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

--- Comment #13 from Tilo Prütz  2010-10-18 08:21:31 
UTC ---
Thank you very much!

[Bug middle-end/46019] [4.3/4.4/4.5/4.6 Regression] x / (0x200000000ULL << y) miscompilation with 32-bit HWI

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  2010-10-18 
08:26:09 UTC ---
Author: jakub
Date: Mon Oct 18 08:26:06 2010
New Revision: 165610

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165610
Log:
PR middle-end/46019
* fold-const.c (fold_binary_loc): If integer_pow2p has
TREE_INT_CST_LOW zero, look at TREE_INT_CST_HIGH.

* gcc.c-torture/execute/pr46019.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr46019.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog

[Bug gcov-profile/39669] gcov --preserve-paths causes mangled filenames on windows

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2010.10.18 08:31:44
 CC||ktietz at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #3 from Kai Tietz  2010-10-18 08:31:44 
UTC ---
On trunk there was a patch for gcov and DOS paths (see at revision 165596).
Could you please verify if this problem was solved by it?

Thanks in advance,
Kai

[Bug other/43448] gccbug should be removed

[ak at gcc dot gnu.org]

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

--- Comment #1 from ak at gcc dot gnu.org 2010-10-18 09:39:19 UTC ---
Author: ak
Date: Mon Oct 18 09:39:15 2010
New Revision: 165613

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165613
Log:
Remove gccbug

gcc/

2010-10-18  Andi Kleen  

PR other/43448
* gccbug.in: Remove.
* Makefile.in (GCCBUG_INSTALL_NAME, gccbug): Remove
(doc, distclean, install-common): Remove reference to gccbug.
* configure: Regenerate.
* configure.ac (all_outputs): Remove gccbug.
* doc/configfiles.texi: Remove references to gccbug.
* doc/sourcebuild.texi: Dito.

contrib/

2010-10-18  Andi Kleen  

* gccbug.el: Remove.

Removed:
trunk/contrib/gccbug.el
trunk/gcc/gccbug.in
Modified:
trunk/contrib/ChangeLog
trunk/gcc/ChangeLog
trunk/gcc/Makefile.in
trunk/gcc/configure
trunk/gcc/configure.ac
trunk/gcc/doc/configfiles.texi
trunk/gcc/doc/sourcebuild.texi

[Bug fortran/46060] gfortran crash when referencing procedure pointer

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.10.18 09:48:42
 Ever Confirmed|0   |1

--- Comment #3 from janus at gcc dot gnu.org 2010-10-18 09:48:42 UTC ---
Confirmed. Here is a slightly reduced test case:

implicit none

abstract interface
  function name_func (ivar) result (res)
integer, intent(in) :: ivar
character(len=8) :: res
  end function name_func
end interface

type var_type
  procedure(name_func), nopass, pointer :: name
end type var_type

type(var_type) :: vars
character(len=8) name

name = vars%name   ! invalid !!!

end


This, like the original code, is invalid and gives an ICE. Changing the invalid
line to something like

name = vars%name(3)

makes the ICE go away.

[Bug bootstrap/46055] [4.6 Regression] -fwhopr failed configure test

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.10.18 09:55:04
 Ever Confirmed|0   |1

--- Comment #7 from Richard Guenther  2010-10-18 
09:55:04 UTC ---
autoconf should disable optimization for all this kind of tests (thus,
append -O0 to CFLAGS).  The issue is caused by -fwhole-program btw, not
by -fwhopr.  If it happens with -fwhopr only then sth is wrong in GCC.

[Bug middle-end/46019] [4.3/4.4/4.5/4.6 Regression] x / (0x200000000ULL << y) miscompilation with 32-bit HWI

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  2010-10-18 
09:57:05 UTC ---
Author: jakub
Date: Mon Oct 18 09:57:02 2010
New Revision: 165617

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165617
Log:
PR middle-end/46019
* fold-const.c (fold_binary_loc): If integer_pow2p has
TREE_INT_CST_LOW zero, look at TREE_INT_CST_HIGH.

* gcc.c-torture/execute/pr46019.c: New test.

Added:
branches/gcc-4_5-branch/gcc/testsuite/gcc.c-torture/execute/pr46019.c
Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/fold-const.c
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog

[Bug bootstrap/46055] [4.6 Regression] -fwhopr failed configure test

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Guenther  2010-10-18 
09:58:41 UTC ---
Hmm, does -fuse-linker-plugin have the same side-effects as -fwhole-program?
That will break symbol use by dlopened objects and we have to avoid that.

Honza?

[Bug middle-end/46019] [4.3/4.4/4.5/4.6 Regression] x / (0x200000000ULL << y) miscompilation with 32-bit HWI

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  2010-10-18 
10:08:52 UTC ---
Author: jakub
Date: Mon Oct 18 10:08:47 2010
New Revision: 165621

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165621
Log:
PR middle-end/46019
* fold-const.c (fold_binary_loc): If integer_pow2p has
TREE_INT_CST_LOW zero, look at TREE_INT_CST_HIGH.

* gcc.c-torture/execute/pr46019.c: New test.

Added:
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr46019.c
Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/fold-const.c
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog

[Bug lto/44950] ICE in dwarf2out_finish, at dwarf2out.c:22271

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Guenther  2010-10-18 
10:54:21 UTC ---
Author: rguenth
Date: Mon Oct 18 10:54:18 2010
New Revision: 165629

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165629
Log:
2010-10-18  Richard Guenther  

PR lto/44950
* tree.c (free_lang_data_in_decl): As we clear TYPE_METHODS
also clear references to entries of it.

* g++.dg/lto/20101015-2_0.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/lto/20101015-2_0.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree.c

[Bug lto/44950] ICE in dwarf2out_finish, at dwarf2out.c:22271

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

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

--- Comment #11 from Richard Guenther  2010-10-18 
10:54:46 UTC ---
Fixed.  After much pain.

[Bug rtl-optimization/45472] [4.5/4.6 Regression] ICE: in move_op_ascend, at sel-sched.c:6124 with -fselective-scheduling2

[abel at gcc dot gnu.org]

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

--- Comment #6 from Andrey Belevantsev  2010-10-18 
10:57:23 UTC ---
Anybody familiar with the expand/tree level can take a look on this?  I can
spare some time later this week if folks are busy.

[Bug middle-end/46019] [4.3 Regression] x / (0x200000000ULL << y) miscompilation with 32-bit HWI

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 AssignedTo|jakub at gcc dot gnu.org|unassigned at gcc dot
   ||gnu.org
Summary|[4.3/4.4/4.5/4.6|[4.3 Regression] x /
   |Regression] x / |(0x2ULL << y)
   |(0x2ULL << y)   |miscompilation with 32-bit
   |miscompilation with 32-bit  |HWI
   |HWI |

--- Comment #4 from Jakub Jelinek  2010-10-18 
11:08:12 UTC ---
Fixed for 4.4/4.5/4.6 so far.

[Bug c/45834] Redundant inter-loop edges in DDG

[bmei at broadcom dot com]

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

Bingfeng Mei  changed:

   What|Removed |Added

 CC||richard.guenther at gmail
   ||dot com

--- Comment #1 from Bingfeng Mei  2010-10-18 11:33:23 
UTC ---
Before using rtx_refs_may_alias_p in may_alias_p, following statement is
executed. 


  /* We cannot use aliases_everything_p to test MEM, since we must look
 at MEM_ADDR, rather than XEXP (mem, 0).  */
  if (GET_MODE (mem) == QImode || GET_CODE (mem_addr) == AND)
return 1;

Basically, it means that the memory access of a QImode always aliases
everything else. That explains why char data type doesn't work here. The code
in may_alias_p is mostly copied from true_dependence_1. The comment is not very
clear to me. Richard, could you cast a light on this? Why do we need to treat
QImode differently?

[Bug c/45834] Redundant inter-loop edges in DDG

[richard.guenther at gmail dot com]

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

--- Comment #2 from richard.guenther at gmail dot com  2010-10-18 11:38:03 UTC ---
On Mon, Oct 18, 2010 at 1:33 PM, bmei at broadcom dot com
 wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45834
>
> Bingfeng Mei  changed:
>
>           What    |Removed                     |Added
> 
>                 CC|                            |richard.guenther at gmail
>                   |                            |dot com
>
> --- Comment #1 from Bingfeng Mei  2010-10-18 
> 11:33:23 UTC ---
> Before using rtx_refs_may_alias_p in may_alias_p, following statement is
> executed.
>
>
>  /* We cannot use aliases_everything_p to test MEM, since we must look
>     at MEM_ADDR, rather than XEXP (mem, 0).  */
>  if (GET_MODE (mem) == QImode || GET_CODE (mem_addr) == AND)
>    return 1;
>
> Basically, it means that the memory access of a QImode always aliases
> everything else. That explains why char data type doesn't work here. The code
> in may_alias_p is mostly copied from true_dependence_1. The comment is not 
> very
> clear to me. Richard, could you cast a light on this? Why do we need to treat
> QImode differently?

I think it tries to work around bugs (it looks like char accesses or
maybe memcpy/string inline expansion).  You can try searching
the history for this code, but I wouldn't be surprised if it pre-dates
the use of even CVS ;)

Richard.

> --
> 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 fortran/46060] [F03] procedure pointer component referenced without argument list

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

Summary|gfortran crash when |[F03] procedure pointer
   |referencing procedure   |component referenced
   |pointer |without argument list

--- Comment #4 from janus at gcc dot gnu.org 2010-10-18 11:44:40 UTC ---
Here is another variation which causes a different ICE:


implicit none

type var_type
  procedure(integer), nopass, pointer :: ppc
end type var_type

type(var_type) :: vars
integer :: i

i = vars%ppc

end



internal compiler error: in fold_convert_loc, at fold-const.c:1899

[Bug rtl-optimization/45472] [4.5/4.6 Regression] ICE: in move_op_ascend, at sel-sched.c:6124 with -fselective-scheduling2

[matz at gcc dot gnu.org]

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

Michael Matz  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org,
   ||jsm28 at gcc dot gnu.org

--- Comment #7 from Michael Matz  2010-10-18 11:46:57 
UTC ---
Well, the problem is not only in expand.  As you say we start with this
code:

...
  vv1 = vv2;
...

That is already a non-volatile statement on the gimple level.  Making the
whole vv1/vv2 object volatile at the top-level of course changes this
into a volatile statement:

...
  vv1 ={v} vv2;
...

The problem with this is that at the gimple level the volatility is not
represented, and hence could already result in invalid transformations.
This extends into expand, so in a way the wrong MEM expressions are
a result of that.

Assuming we'd extend expand to expand such block moves, where parts of the
block are volatile into a series of volatile accesses, we could fix the bug
at hand.  That would still leave the problem of non-volatility on the gimple
level.

This all points to a deeper problem IMO, one we need to decide how to solve
before tackling the details of this bug, namely: how are non-volatile objects
containing volatile subobjects handled?  I don't know if the language
standard says anything about this.

We have several possibilities:
1) make all objects containing volatile subobjects volatile itself
2) make instructions touching such objects volatile
3) make instructions touching the volatile components volatile

The first has the problem that volatile objects with aggregate type
implicitely contain only volatile subobjects, that is for such object:
  struct {int a; volatile int b;} half_volatile;
with solution (1) this would be equivalent to
  volatile struct {int a; volatile int b;} half_volatile;
and hence halt_volatile.a would be volatile too, probably unlike the author
intended.

The other two solutions are more work, especially because the half-volatility
wouldn't be reflected in the objects type.

Independend of what we decide for the middle-end, I'd like to hear the opinion
of the C frontend people about this issue.

[Bug c++/46061] [C++0x] Variadic Template Templates: not expandable into fixed-size argument list, Implementation Gap.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #1 from Jonathan Wakely  2010-10-18 
12:06:55 UTC ---
dup

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

[Bug c++/39653] [C++0x] error referencing a more specialized variadic template from primary

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||andreas.milton.m at gmail
   ||dot com

--- Comment #2 from Jonathan Wakely  2010-10-18 
12:06:55 UTC ---
*** Bug 46061 has been marked as a duplicate of this bug. ***

[Bug web/46064] New: have to enter a comment to resolve a bug as a duplicate

[redi at gcc dot gnu.org]

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

   Summary: have to enter a comment to resolve a bug as a
duplicate
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: web
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org


Since the upgrade bugzilla requires a comment when resolving a bug as a
duplicate.

Requiring me to type "dup" is pointless, the automatically-inserted "this bug
has been marked as a duplicate..." is self-explanatory

[Bug c/45834] Redundant inter-loop edges in DDG

[bmei at broadcom dot com]

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

--- Comment #3 from Bingfeng Mei  2010-10-18 12:16:59 
UTC ---
I think that standard specifies that char * may refer to an alias of any
object, that's why QImode is different here. But I am not sure whether a
restrict qualifier will override that rule.

[Bug rtl-optimization/45472] [4.5/4.6 Regression] ICE: in move_op_ascend, at sel-sched.c:6124 with -fselective-scheduling2

[bonzini at gnu dot org]

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

--- Comment #8 from Paolo Bonzini  2010-10-18 12:20:39 
UTC ---
Would it make sense to make the statement volatile even if only some
subcomponents (or all subcomponents) are volatile?

I like (2); if I understand it correctly, in this case vv1 and vv2 would not be
volatile, but you'd still have

   vv1 ={v} vv2;

in the GIMPLE source.  It should be possible to use a bit on
{ARRAY,RECORD,UNION,QUAL_UNION}_TYPE to cache this, e.g.

#define TYPE_HAS_VOLATILE_PARTS(T) \
   (AGGREGATE_TYPE_P (T) \
? TYPE_UNSIGNED (T) \
: TYPE_VOLATILE (T))

#define AGGREGATE_TYPE_CHECK(T) \
   TREE_CHECK4(T, ARRAY_TYPE, RECORD_TYPE, UNION_TYPE, QUAL_UNION_TYPE)

#define SET_TYPE_HAS_VOLATILE_PARTS(T, V) \
   (TYPE_UNSIGNED (AGGREGATE_TYPE_CHECK (T)) = (V))

Separately, expand would of course need to be taught about expanding accesses
to volatile subcomponents as mem/v.  If this approach was feasible, it would
have the advantage of splitting the task in two parts, one for GIMPLE
(including possibly the verifier) and one for expand.

[Bug bootstrap/46055] [4.6 Regression] -fwhopr failed configure test

[hjl.tools at gmail dot com]

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

--- Comment #9 from H.J. Lu  2010-10-18 12:23:36 
UTC ---
(In reply to comment #8)
> Hmm, does -fuse-linker-plugin have the same side-effects as -fwhole-program?
> That will break symbol use by dlopened objects and we have to avoid that.
> 

[...@gnu-6 pr46055]$ make
/export/build/gnu/gcc/build-x86_64-linux/prev-gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/prev-gcc/ -O2 -fuse-linker-plugin
-fwhopr -o foo foo.i
ld.gold: /tmp/ccIRVeGM.ltrans0.ltrans.o: in function
main:ccIRVeGM.ltrans0.o(.text+0x3): error: undefined reference to
'pstat_getstatic'
collect2: ld returned 1 exit status
make: *** [foo] Error 1
[...@gnu-6 pr46055]$ /export/build/gnu/gcc/build-x86_64-linux/prev-gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/prev-gcc/ -O2 -fwhopr -o foo foo.i
/tmp/cczPtxXa.o: In function `main':
foo.i:(.text+0x3): undefined reference to `pstat_getstatic'
collect2: ld returned 1 exit status
[...@gnu-6 pr46055]$ /export/build/gnu/gcc/build-x86_64-linux/prev-gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/prev-gcc/ -O2 -fwhole-program -o foo
foo.i
/tmp/ccB81NJo.o: In function `main':
foo.i:(.text+0x3): undefined reference to `pstat_getstatic'
collect2: ld returned 1 exit status
[...@gnu-6 pr46055]$ /export/build/gnu/gcc/build-x86_64-linux/prev-gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/prev-gcc/ -O2 -fwhole-program -o foo
foo.i -fuse-linker-plugin
ld.gold: /tmp/cc4NeRs5.o: in function main:foo.i(.text+0x3): error: undefined
reference to 'pstat_getstatic'
collect2: ld returned 1 exit status
[...@gnu-6 pr46055]$ 

It only happens with "-fuse-linker-plugin -fwhopr".

[Bug c++/46065] New: [4.6 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'tree_list' in poplevel_named_label_1, at cp/decl.c:477

[zsojka at seznam dot cz]

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

   Summary: [4.6 Regression] ICE: tree check: expected tree that
contains 'decl minimal' structure, have 'tree_list' in
poplevel_named_label_1, at cp/decl.c:477
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz


Created attachment 22075
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22075
reduced testcase

Compiler output:
$ g++ pr46065.C
pr46065.C: In function 'void foo()':
pr46065.C:7:7: internal compiler error: tree check: expected tree that contains
'decl minimal' structure, have 'tree_list' in poplevel_named_label_1, at
cp/decl.c:477
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Tested revisions:
r165629 - crash
r163636 - crash
r161659 - OK

Might be another fallout of r162223 (
http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg00577.html )

[Bug c/45834] Redundant inter-loop edges in DDG

[richard.guenther at gmail dot com]

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

--- Comment #4 from richard.guenther at gmail dot com  2010-10-18 13:42:33 UTC ---
On Mon, Oct 18, 2010 at 2:17 PM, bmei at broadcom dot com
 wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45834
>
> --- Comment #3 from Bingfeng Mei  2010-10-18 
> 12:16:59 UTC ---
> I think that standard specifies that char * may refer to an alias of any
> object, that's why QImode is different here.

Sure, but we have other means of dealing with that (MEM_ALIAS_SET == 0).

> But I am not sure whether a
> restrict qualifier will override that rule.

restrict is a different concept from type-based aliasing.

> --
> 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 c/45834] Redundant inter-loop edges in DDG

[bmei at broadcom dot com]

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

--- Comment #5 from Bingfeng Mei  2010-10-18 13:53:37 
UTC ---
> 
> Sure, but we have other means of dealing with that (MEM_ALIAS_SET == 0).

Do you mean this check is redundant here ? I dig out the ancient code (from
1997)

  /* If both references are struct references, or both are not, nothing
 is known about aliasing.

 If either reference is QImode or BLKmode, ANSI C permits aliasing.

 If both addresses are constant, or both are not, nothing is known
 about aliasing.  */
  if (MEM_IN_STRUCT_P (x) == MEM_IN_STRUCT_P (mem)
  || mem_mode == QImode || mem_mode == BLKmode
  || GET_MODE (x) == QImode || GET_MODE (mem) == BLKmode
  || varies (x_addr) == varies (mem_addr))
return 1;

The comment indicates that the check for QImode is for meeting aliasing rule of
char type.

> 
> > But I am not sure whether a
> > restrict qualifier will override that rule.
> 
> restrict is a different concept from type-based aliasing.
> 
Sure, but in this example, on one hand, char type pointer is supposed to alias
any other data type, on the other hand, all the char pointers have restrict
qualifiers. What is correct behaviour, alias or not?

[Bug lto/42987] Testcases local1-a.cc and local1.C cause ICE when compiled with -flto -g

[zsojka at seznam dot cz]

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

Zdenek Sojka  changed:

   What|Removed |Added

 CC||zsojka at seznam dot cz

--- Comment #4 from Zdenek Sojka  2010-10-18 13:54:04 
UTC ---
Seems to have disappeared between r165540 (crash) and r165629 (OK).
(x64_64-linux)
(maybe fixed by http://gcc.gnu.org/viewcvs?view=revision&revision=165629 )

r165540:
$ g++ local1.C local1-a.cc -flto -g
lto1: internal compiler error: in dwarf2out_finish, at dwarf2out.c:22860

r165629:
$ g++ local1.C local1-a.cc -flto -g

[Bug c/45834] Redundant inter-loop edges in DDG

[richard.guenther at gmail dot com]

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

--- Comment #6 from richard.guenther at gmail dot com  2010-10-18 13:57:19 UTC ---
On Mon, Oct 18, 2010 at 3:53 PM, bmei at broadcom dot com
 wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45834
>
> --- Comment #5 from Bingfeng Mei  2010-10-18 
> 13:53:37 UTC ---
>>
>> Sure, but we have other means of dealing with that (MEM_ALIAS_SET == 0).
>
> Do you mean this check is redundant here ? I dig out the ancient code (from
> 1997)
>
>  /* If both references are struct references, or both are not, nothing
>     is known about aliasing.
>
>     If either reference is QImode or BLKmode, ANSI C permits aliasing.
>
>     If both addresses are constant, or both are not, nothing is known
>     about aliasing.  */
>  if (MEM_IN_STRUCT_P (x) == MEM_IN_STRUCT_P (mem)
>      || mem_mode == QImode || mem_mode == BLKmode
>      || GET_MODE (x) == QImode || GET_MODE (mem) == BLKmode
>      || varies (x_addr) == varies (mem_addr))
>    return 1;
>
> The comment indicates that the check for QImode is for meeting aliasing rule 
> of
> char type.

I just say that we have other means to test for "char", the check for QImode
is bogus.  But it might well be that removing it exposes bugs.

>>
>> > But I am not sure whether a
>> > restrict qualifier will override that rule.
>>
>> restrict is a different concept from type-based aliasing.
>>
> Sure, but in this example, on one hand, char type pointer is supposed to alias
> any other data type, on the other hand, all the char pointers have restrict
> qualifiers. What is correct behaviour, alias or not?

char aliases all types.  accesses through two different restrict qualified
pointers do not alias.

I don't see any conflict here.

> --
> 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 tree-optimization/46066] New: [4.6 Regression] ICE: in create_parallel_loop, at tree-parloops.c:1455 with -ftree-parallelize-loops -g

[zsojka at seznam dot cz]

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

   Summary: [4.6 Regression] ICE: in create_parallel_loop, at
tree-parloops.c:1455 with -ftree-parallelize-loops -g
   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 22076
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22076
reduced testcase (almost the same as gcc.dg/autopar/outer-2.c)

Compiler output:
$ gcc -O -ftree-parallelize-loops=4 -g pr46066.c 
pr46066.c: In function 'parloop':
pr46066.c:2:1: internal compiler error: in create_parallel_loop, at
tree-parloops.c:1455
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

fails with -ftree-parallelize-loops=[234]

Tested revisions:
r165629 - crash
r161659 - crash
r159696 - OK
4.5 r163761 - OK

[Bug fortran/46067] New: hang or spurious compiler message using procedure pointer with pass

[sjbespa at comcast dot net]

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

   Summary: hang or spurious compiler message using procedure
pointer with pass
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sjbe...@comcast.net


Created attachment 22077
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22077
code demonstrating bug referenced in report

Compiling the attached module, with gfortran 4.6 trunk results in the following
error message:

==
gfortran test_2.f90
test_2.f90:6.52:

  procedure(fun_interface), pointer, pass :: fun_ptr
1
Error: Non-polymorphic passed-object dummy argument of 'fun_ptr' at (1)

==

potential problem 1 : the error message appears incorrect because the target of
the passed-object dummy argument isn't polymorphic.

potential problem 2: if the error message is correct and if the type of the
passed-object dummy argument in the sample code is changed from a declaration
of "type" to "class", the module compiles but hangs when the passed-object
dummy argument is referenced. 

The relevant statements are labeled in the attached file.




et:blotII2 sjbespa$ /volumes/dev/gfortran-4.6-trunk/bin/gfortran -v
Using built-in specs.
COLLECT_GCC=/volumes/dev/gfortran-4.6-trunk/bin/gfortran
COLLECT_LTO_WRAPPER=/Volumes/dev/gfortran-4.6-trunk/bin/../libexec/gcc/x86_64-apple-darwin10/4.6.0/lto-wrapper
Target: x86_64-apple-darwin10
Configured with: ../gfortran-4.6-src/configure
--prefix=/volumes/dev/gfortran-4.6-trunk --enable-languages=fortran
--host=x86_64-apple-darwin10 --build=x86_64-apple-darwin10
--target=x86_64-apple-darwin10
Thread model: posix
gcc version 4.6.0 20101013 (experimental) (GCC)

[Bug tree-optimization/46068] New: [4.6 Regression] ICE: in consider_split, at ipa-split.c:313 with -flto/-fwhopr and asm goto

[zsojka at seznam dot cz]

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

   Summary: [4.6 Regression] ICE: in consider_split, at
ipa-split.c:313 with -flto/-fwhopr and asm goto
   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 22078
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22078
reduced testcase

Compiler output:
$ gcc -O2 -flto pr46067.c
testcase.c: In function 'foo':
testcase.c:6:1: internal compiler error: in consider_split, at ipa-split.c:313
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Tested revisions:
r165629 - crash
r165540 - crash
r163636 - crash
r161659 - crash
r159696 - OK
4.5 r163761 - OK

[Bug bootstrap/46018] [4.6 Regression] Bootstrap fails on i386-pc-solaris2.10

[ahaas at airmail dot net]

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

--- Comment #7 from Art Haas  2010-10-18 15:03:56 UTC 
---
My bootstrap build succeeded for the this morning again, so I suggest closing
this ticket.

[Bug bootstrap/46055] [4.6 Regression] -fwhopr failed configure test

[hubicka at ucw dot cz]

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

--- Comment #10 from Jan Hubicka  2010-10-18 15:11:52 
UTC ---
Hi,
I found what is causing the problem.  I accidentally comitted also the
following cleanup of visibility code.  The difference is that we now trust
linker's LDPR_PREVAILING_DEF_IRONLY and bring symbols local when they are
declared so even without default visibility.

Linker should not declare symbols that can be bound by dynamic linker
as LDPR_PREVAILING_DEF_IRONLY (according to my earlier conversation about
COMDATs).  I am looking into it and will either revert the patch today or
add missing changelog (and post to ML).
Sorry for that.

Honza

Index: ipa.c
===
*** ipa.c(revision 165562)
--- ipa.c(working copy)
*** cgraph_externally_visible_p (struct cgra
*** 595,600 
--- 608,630 
/* If linker counts on us, we must preserve the function.  */
if (cgraph_used_from_object_file_p (node))
  return true;
+   if (DECL_PRESERVE_P (node->decl))
+ return true;
+   if (lookup_attribute ("externally_visible", DECL_ATTRIBUTES (node->decl)))
+ return true;
+ 
+   /* See if we have linker information about symbol not being used or
+  if we need to make guess based on the declaration.
+ 
+  Even if the linker clams the symbol is unused, never bring internal
+  symbols that are declared by user as used or externally visible.
+  This is needed for i.e. references from asm statements.   */
+   for (alias = node->same_body; alias; alias = alias->next)
+ if (alias->resolution != LDPR_PREVAILING_DEF_IRONLY)
+   break;
+   if (!alias && node->resolution == LDPR_PREVAILING_DEF_IRONLY)
+ return false;
+ 
/* When doing link time optimizations, hidden symbols become local.  */
if (in_lto_p
&& (DECL_VISIBILITY (node->decl) == VISIBILITY_HIDDEN
*** cgraph_externally_visible_p (struct cgra
*** 626,636 
return true;
  }
  }
!   if (DECL_PRESERVE_P (node->decl))
! return true;
if (MAIN_NAME_P (DECL_NAME (node->decl)))
  return true;
!   if (lookup_attribute ("externally_visible", DECL_ATTRIBUTES (node->decl)))
  return true;
return false;
  }
--- 656,725 
return true;
  }
  }
! 
if (MAIN_NAME_P (DECL_NAME (node->decl)))
  return true;
! 
!   return false;
! }
! 
! /* Return true when variable VNODE should be considered externally visible. 
*/
! 
! static bool
! varpool_externally_visible_p (struct varpool_node *vnode, bool aliased)
! {
!   struct varpool_node *alias;
!   if (!DECL_COMDAT (vnode->decl) && !TREE_PUBLIC (vnode->decl))
! return false;
! 
!   /* Do not even try to be smart about aliased nodes.  Until we properly
!  represent everything by same body alias, these are just evil.  */
!   if (aliased)
! return true;
! 
!   /* If linker counts on us, we must preserve the function.  */
!   if (varpool_used_from_object_file_p (vnode))
! return true;
! 
!   if (DECL_PRESERVE_P (vnode->decl))
! return true;
!   if (lookup_attribute ("externally_visible",
! DECL_ATTRIBUTES (vnode->decl)))
! return true;
! 
!   /* See if we have linker information about symbol not being used or
!  if we need to make guess based on the declaration.
! 
!  Even if the linker clams the symbol is unused, never bring internal
!  symbols that are declared by user as used or externally visible.
!  This is needed for i.e. references from asm statements.   */
!   if (varpool_used_from_object_file_p (vnode))
! return true;
!   for (alias = vnode->extra_name; alias; alias = alias->next)
! if (alias->resolution != LDPR_PREVAILING_DEF_IRONLY)
!   break;
!   if (!alias && vnode->resolution == LDPR_PREVAILING_DEF_IRONLY)
! return false;
! 
!   /* When doing link time optimizations, hidden symbols become local.  */
!   if (in_lto_p
!   && (DECL_VISIBILITY (vnode->decl) == VISIBILITY_HIDDEN
!   || DECL_VISIBILITY (vnode->decl) == VISIBILITY_INTERNAL)
!   /* Be sure that node is defined in IR file, not in other object
!  file.  In that case we don't set used_from_other_object_file.  */
!   && vnode->finalized)
! ;
!   else if (!flag_whole_program)
! return true;
! 
!   /* Do not attempt to privatize COMDATS by default.
!  This would break linking with C++ libraries sharing
!  inline definitions.
! 
!  FIXME: We can do so for readonly vars with no address taken and
!  possibly also for vtables since no direct pointer comparsion is done.
!  It might be interesting to do so to reduce linking overhead.  */
!   if (DECL_COMDAT (vnode->decl) || DECL_WEAK (vnode->decl))
  return true;
return false;
  }
*** function_and_variable_visibility (bool w
*** 786,812 
if (!vnode->finalized)
  continue;
if (vnode->needed
!   && (DECL_COMDAT (vnode->decl) || TREE_PUBLIC (vn

[Bug c/46041] __FP_FAST_FMA not defined with -E

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2010.10.18 15:11:54
 Ever Confirmed|0   |1

[Bug lto/45638] No rule to make target `check-lto', needed by `check'. Stop.

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  2010-10-18 
15:16:11 UTC ---
Author: jakub
Date: Mon Oct 18 15:16:07 2010
New Revision: 165638

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165638
Log:
PR lto/45638
* Make-lang.in (check-lto): New dummy target.

Modified:
trunk/gcc/lto/ChangeLog
trunk/gcc/lto/Make-lang.in

[Bug c/46041] __FP_FAST_FMA not defined with -E

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

   Last reconfirmed|2010-10-18 15:11:54 |
 AssignedTo|unassigned at gcc dot   |meissner at gcc dot gnu.org
   |gnu.org |

--- Comment #5 from Michael Meissner  2010-10-18 
15:26:13 UTC ---
Yes, -save-temps would be broken.  I noticed this after submitting the bug when
I tried to patch glibc's math.h and I happened to use -save-temps, and it
didn't seem to work, and I was just about to investigate it when I needed to go
home.

The suggestion to use HAVE_fma4 instead of the check on the builtin array
will probably work for normal -save-temps.  However, for target specific
functions, we may need to go to using a conditional macro for these.

However, Richard Guenther has a point, that it really doesn't work too well
when you consider target specific attributes.  Frankly, I hadn't thought about
-save-temps when I first contemplated target attributes in the first place
(even though I originally added -save-temps many years ago).  The -save-temps
switch doesn't work in general when functions have different target attributes
that will change the macros being defined.  I would imagine -E would have the
same problem.  The only way I can see to do this 'right' is to move -save-temps
into the cpp handling in the compiler proper, rather than doing two passes like
we do now. In the old days, we had to do two passes, because cpp was a separate
process.

While this might fix -save-temps, I'm still not sure what we can do about -E.

[Bug rtl-optimization/45967] [4.5/4.6 Regression] gcc-4.5.x optimizes code with side-effects away

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther  2010-10-18 
15:32:03 UTC ---
Author: rguenth
Date: Mon Oct 18 15:32:00 2010
New Revision: 165641

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165641
Log:
2010-10-18  Richard Guenther  

PR tree-optimization/45967
* tree-ssa-structalias.c (type_could_have_pointers): Remove.
(could_have_pointers): Likewise.
(handle_rhs_call, handle_const_call, handle_pure_call,
find_func_aliases, intra_create_variable_infos): Remove calls to them.
(struct fieldoff): Add must_have_pointers field.
(type_must_have_pointers): New function.
(field_must_have_pointers): Likewise.
(push_fields_onto_fieldstack): Remove must_have_pointers_p argument.
Adjust field merging.
(create_function_info_for): May-have-pointers of varinfo is
almost always true.
(create_variable_info_for_1): Likewise.

* gcc.dg/torture/pr45967.c: New testcase.
* gcc.dg/ipa/ipa-pta-10.c: Adjust.
* gcc.dg/ipa/ipa-pta-13.c: Likewise
* gcc.dg/torture/pr39074-2.c: Likewise
* gcc.dg/torture/pta-escape-1.c: Likewise
* gcc.dg/torture/pta-ptrarith-1.c: Likewise
* gcc.dg/tree-ssa/pta-callused.c: Likewise
* gcc.dg/tree-ssa/pta-escape-1.c: Likewise
* gcc.dg/tree-ssa/pta-escape-2.c: Likewise
* gcc.dg/tree-ssa/pta-escape-3.c: Likewise
* gcc.dg/tree-ssa/ssa-pre-21.c: Likewise

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr45967.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/ipa/ipa-pta-10.c
trunk/gcc/testsuite/gcc.dg/ipa/ipa-pta-13.c
trunk/gcc/testsuite/gcc.dg/torture/pr39074-2.c
trunk/gcc/testsuite/gcc.dg/torture/pta-escape-1.c
trunk/gcc/testsuite/gcc.dg/torture/pta-ptrarith-1.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pta-callused.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pta-escape-1.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pta-escape-2.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pta-escape-3.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-pre-21.c
trunk/gcc/tree-ssa-structalias.c

[Bug rtl-optimization/45967] [4.5 Regression] gcc-4.5.x optimizes code with side-effects away

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||alias, wrong-code
  Known to work||4.6.0
Summary|[4.5/4.6 Regression]|[4.5 Regression] gcc-4.5.x
   |gcc-4.5.x optimizes code|optimizes code with
   |with side-effects away  |side-effects away
  Known to fail||4.4.3

--- Comment #4 from Richard Guenther  2010-10-18 
15:33:38 UTC ---
Fixed for trunk sofar.  Let's see if there is any fallout.

[Bug bootstrap/46018] [4.6 Regression] Bootstrap fails on i386-pc-solaris2.10

[joseph at codesourcery dot com]

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

--- Comment #8 from joseph at codesourcery dot com  2010-10-18 15:37:04 UTC ---
On Sun, 17 Oct 2010, ahaas at airmail dot net wrote:

> Running 'git bisect' but interpreting a failed build as 'good' and a 
> successful
> build as 'bad' leads to this commit which restored the build:
> 
> 7332acfcfbd1a9c70674c62419096022f72bd201 is the first bad commit
> commit 7332acfcfbd1a9c70674c62419096022f72bd201
> Author: jsm28 
> Date:   Sat Oct 16 12:12:24 2010 +
> 
> * config/arm/arm.c (arm_option_optimization): Set
> flag_section_anchors to 1 not 2.
> * config/i386/i386.c (ix86_option_override_internal): Check
> global_options_set.x_flag_zee and
> global_options_set.x_flag_omit_frame_pointer.
> (ix86_option_optimization): Don't set flag_omit_frame_pointer and
> flag_zee to 2.
> * config/i386/sol2-10.h (SUBTARGET_OVERRIDE_OPTIONS): Check
> global_options_set.x_flag_omit_frame_pointer.

This certainly wasn't meant to change the behavior of the compiler at all.  
I'll test a patch to restore the original intended behavior (and so the 
build failure for this target).

[Bug c++/46065] [4.6 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'tree_list' in poplevel_named_label_1, at cp/decl.c:477

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0

[Bug tree-optimization/46066] [4.6 Regression] ICE: in create_parallel_loop, at tree-parloops.c:1455 with -ftree-parallelize-loops -g

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0

[Bug tree-optimization/46068] [4.6 Regression] ICE: in consider_split, at ipa-split.c:313 with -flto/-fwhopr and asm goto

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0

[Bug rtl-optimization/45472] [4.5/4.6 Regression] ICE: in move_op_ascend, at sel-sched.c:6124 with -fselective-scheduling2

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Guenther  2010-10-18 
15:42:44 UTC ---
(In reply to comment #8)
> Would it make sense to make the statement volatile even if only some
> subcomponents (or all subcomponents) are volatile?
> 
> I like (2); if I understand it correctly, in this case vv1 and vv2 would not 
> be
> volatile, but you'd still have
> 
>vv1 ={v} vv2;
> 
> in the GIMPLE source.  It should be possible to use a bit on
> {ARRAY,RECORD,UNION,QUAL_UNION}_TYPE to cache this, e.g.
> 
> #define TYPE_HAS_VOLATILE_PARTS(T) \
>(AGGREGATE_TYPE_P (T) \
> ? TYPE_UNSIGNED (T) \
> : TYPE_VOLATILE (T))
> 
> #define AGGREGATE_TYPE_CHECK(T) \
>TREE_CHECK4(T, ARRAY_TYPE, RECORD_TYPE, UNION_TYPE, QUAL_UNION_TYPE)
> 
> #define SET_TYPE_HAS_VOLATILE_PARTS(T, V) \
>(TYPE_UNSIGNED (AGGREGATE_TYPE_CHECK (T)) = (V))
> 
> Separately, expand would of course need to be taught about expanding accesses
> to volatile subcomponents as mem/v.  If this approach was feasible, it would
> have the advantage of splitting the task in two parts, one for GIMPLE
> (including possibly the verifier) and one for expand.

If we want to treat vv1 = vv2 as volatile then the frontends can now simply
emit MEM_REF <&vv1> = MEM_REF <&vv2> with TREE_THIS_VOLATILE set and things
should work.  That leaves it up to the frontend on how to deal with this.

The much harder question is how to expand vv1 = vv2 "correctly".  Thus,
we need to define what happens and document it.

Also consider memcpy (&vv1, &vv2) and eventually the compiler optimizing
that to vv1 = vv2 (note the lack of {v} here).

[Bug c++/45983] [4.5 Regression] ICE: tree code 'template_parm_index' is not supported in gimple streams with -lto

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

Summary|[4.5/4.6 Regression] ICE:   |[4.5 Regression] ICE: tree
   |tree code   |code 'template_parm_index'
   |'template_parm_index' is|is not supported in gimple
   |not supported in gimple |streams with -lto
   |streams with -lto   |
  Known to fail||4.6.0

--- Comment #15 from Richard Guenther  2010-10-18 
15:45:04 UTC ---
Fixed for 4.6.

[Bug bootstrap/46055] [4.6 Regression] -fwhopr failed configure test

[hubicka at ucw dot cz]

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

--- Comment #11 from Jan Hubicka  2010-10-18 15:47:24 
UTC ---
Hi,
the plugin seems to give bit funny resolutions in side cases, so I will revert
the accident commit now, will commit the cleanup part of change incrementally
and then we can hopefully discuss how the gold should behave and work around
the bugs, if any.

I seem to agree with H.J. that the simple linking test should suffice here.
Can we get libiberty configury fixed?  It is needed anyway for -fwhole-program
as well as for static linking targets.

Honza

[Bug fortran/42169] [4.4/4.5/4.6 Regression] gfortran.dg/pr41928.f90:47: internal compiler error: in store_can_be_removed_p, at ira-emit.c:371

[sje at cup dot hp.com]

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

--- Comment #17 from Steve Ellcey  2010-10-18 15:51:52 
UTC ---
(In reply to comment #16)
> Based on my posted test results for hppa2.0-hp-hpux11.11, this PR was
> fixed on the trunk between r163182 and r163254.
> 
> Need to find the change.

My nightly testing shows it fixed by r163218, I'll see if I can find the
exact version number.

[Bug web/45785] Bugzilla search sometimes fails with an internal error

[zsojka at seznam dot cz]

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

--- Comment #4 from Zdenek Sojka  2010-10-18 15:54:45 
UTC ---
http://gcc.gnu.org/bugzilla/buglist.cgi?cf_known_to_fail_type=allwords&cf_known_to_work_type=allwords&query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&longdesc=lto_symtab_merge_decls_1&longdesc_type=allwordssubstr

still fails (search isn't done after several minutes)

It is a search with only "A Comment:" filled, within all bugs ("Status:
RESOLVED" seems to be enough). It used to work in the past

[Bug c/46015] [4.6 Regression] -Wunused-but-set-variable warns for arrays used in gotos

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  2010-10-18 
15:55:31 UTC ---
Author: jakub
Date: Mon Oct 18 15:55:25 2010
New Revision: 165643

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165643
Log:
PR c/46015
* c-parser.c (c_parser_statement_after_labels): Call mark_exp_read
on computed goto argument.

* semantics.c (finish_goto_stmt): Call mark_rvalue_use on computed
goto destination.

* c-c++-common/Wunused-var-13.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/Wunused-var-13.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-parser.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog

[Bug web/46064] have to enter a comment to resolve a bug as a duplicate

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  2010-10-18 
15:56:11 UTC ---
I think this is the right thing to do.  when bugs are marked as dups the
majority of the time, we want an explication.  Because if there was none; the
reporter might open it back up  (even then some of them do but that is a
different issue all together).  I think we should error on the side of cation
here rather than have almost no feedback to the user of GCC.

[Bug rtl-optimization/45472] [4.5/4.6 Regression] ICE: in move_op_ascend, at sel-sched.c:6124 with -fselective-scheduling2

[matz at gcc dot gnu.org]

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

--- Comment #10 from Michael Matz  2010-10-18 15:58:26 
UTC ---
One idea we had was that this is all frontends business anyway, and hence
it should (if it so desires) simply create volatile MEM_REFs for references
to half-volatile objects.  That alone would result in the copy statement
being marked volatile, and would also (I guess, haven't checked) do the right
thing in expand.

So, if we (the frontend) decide that accesses to objects containing volatile
subobjects should itself be regarded as volatile, then generating the right
kind of MEM_REF would already provide that.

[Bug web/46064] have to enter a comment to resolve a bug as a duplicate

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #2 from Jonathan Wakely  2010-10-18 
16:04:21 UTC ---
fair enough

[Bug c/46041] __FP_FAST_FMA not defined with -E

[rth at gcc dot gnu.org]

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

--- Comment #6 from Richard Henderson  2010-10-18 
16:12:21 UTC ---
Does anyone honestly expect a pre-processor macro to change due to
attributes on a function?  I sure don't -- that would seem to be a
clear translation phase ordering violation.

Setting __FP_FAST_FMA based on the command-line compiler options
only would seem to be to be Good Enough.

[Bug target/43804] [4.5/4.6 regression] ICE in reload_cse_simplify_operands

[tg at mirbsd dot org]

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

Thorsten Glaser  changed:

   What|Removed |Added

 CC||tg at mirbsd dot org

--- Comment #18 from Thorsten Glaser  2010-10-18 16:14:04 
UTC ---
I just added your patch (Attachment #20541) to my Debian source package
gcc-4.4_4.4.5-3+m68k.1 – Finn Thain says it fixes that problem for him,
and it does occur in compiling the debugging libstdc++ after bootstrap,
so I will be able to report success (I hope) soonish. Except genattrtab
takes 3.5 hours in 4.4 instead of less than half an hour in 4.3… so, it
will be some days.

[Bug c/46015] [4.6 Regression] -Wunused-but-set-variable warns for arrays used in gotos

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #2 from Jakub Jelinek  2010-10-18 
16:15:55 UTC ---
Fixed.

[Bug c/46041] __FP_FAST_FMA not defined with -E

[meissner at gcc dot gnu.org]

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

--- Comment #7 from Michael Meissner  2010-10-18 
16:21:31 UTC ---
Yes, though the issue originally came up in terms of the pragma and not the
attribute, because people wanted to include the various include files that had
#ifdef's to guard against builtin functions if the target switches weren't
used.

[Bug libstdc++/45866] [C++0x] std::ratio_add, ratio_sub, ratio_multiply, ratio_divide do not have num and den members.

[paolo.carlini at oracle dot com]

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

--- Comment #3 from Paolo Carlini  2010-10-18 
16:35:45 UTC ---
I don't see c++/45114 resolved very soon, thus, for 4.6.0, let's provide anyway
those constants, seems simple.

[Bug libstdc++/45866] [C++0x] std::ratio_add, ratio_sub, ratio_multiply, ratio_divide do not have num and den members.

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |paolo.carlini at oracle dot
   |gnu.org |com

[Bug rtl-optimization/45472] [4.5/4.6 Regression] ICE: in move_op_ascend, at sel-sched.c:6124 with -fselective-scheduling2

[joseph at codesourcery dot com]

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

--- Comment #11 from joseph at codesourcery dot com  2010-10-18 16:41:03 UTC ---
On Mon, 18 Oct 2010, rguenth at gcc dot gnu.org wrote:

> Also consider memcpy (&vv1, &vv2) and eventually the compiler optimizing
> that to vv1 = vv2 (note the lack of {v} here).

Using memcpy when any part of the source or destination is an object 
defined with volatile type has undefined behavior (at runtime).

[Bug fortran/42169] [4.4/4.5/4.6 Regression] gfortran.dg/pr41928.f90:47: internal compiler error: in store_can_be_removed_p, at ira-emit.c:371

[sje at cup dot hp.com]

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

--- Comment #18 from Steve Ellcey  2010-10-18 16:55:32 
UTC ---
It looks like this was fixed (for hppa at least) in r163190.

2010-08-12  Richard Guenther  

PR tree-optimization/45232
* tree-ssa-reassoc.c (can_reassociate_p): Disable re-association
for types with undefined overflow.
(reassociate_bb): Allow re-associating of bit and min/max
operations for types with undefined overflow.
* tree-ssa-forwprop.c (associate_plusminus): New function.
(tree_ssa_forward_propagate_single_use_vars): Call it.

[Bug tree-optimization/44776] FAIL: gcc.dg/matrix/transpose-3.c execution, -fprofile-use -fipa-matrix-reorg -fdump-ipa-matrix-reorg -O3 -fwhole-program

[davek at gcc dot gnu.org]

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

Dave Korn  changed:

   What|Removed |Added

 CC||davek at gcc dot gnu.org

--- Comment #10 from Dave Korn  2010-10-18 17:06:11 
UTC ---
Also fails on i686-pc-cygwin since at least r.161958 (still fails at r.165450)

FAIL: gcc.dg/matrix/transpose-3.c execution,-fprofile-use
-fipa-matrix-reorg
 -fdump-ipa-matrix-reorg -O3 -fwhole-program


In this case, it turns out to be a double free:

$ /gnu/gcc/obj-lto/gcc/xgcc -B/gnu/gcc/obj-lto/gcc/ /gnu/gcc/gcc/gcc/testsuite/
gcc.dg/matrix/transpose-3.c -fprofile-use -fipa-matrix-reorg -fdump-ipa-matrix-
reorg -O3  -fwhole-program -o ./transpose-3.x02
/gnu/gcc/gcc/gcc/testsuite/gcc.dg/matrix/transpose-3.c: In function 'mem_init':
/gnu/gcc/gcc/gcc/testsuite/gcc.dg/matrix/transpose-3.c:96:1: note: file
/gnu/gcc
/obj-lto/gcc/testsuite/transpose-3.gcda not found, execution counts estimated

$ gdb ./transpose-3.x02
GNU gdb 6.8.0.20080328-cvs (cygwin-special)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-cygwin"...
(gdb) b main
Breakpoint 1 at 0x401176
(gdb) r
Starting program: /gnu/gcc/obj-lto/gcc/testsuite/transpose-3.x02
[New thread 2236.0x184]
[New thread 2236.0xc6c]

Breakpoint 1, 0x00401176 in main ()
(gdb) b free
Breakpoint 2 at 0x610725e0: file
/gnu/winsup/src.clean/winsup/cygwin/malloc_wrap
per.cc, line 41.
(gdb) c
Continuing.
acc to dim2 acc to dim2 acc to dim2 acc to dim2 acc to dim2 acc to dim2 acc to
d
im2 acc to dim2 acc to dim2 acc to dim2 acc to dim2 acc to dim2 acc to dim2 acc
to dim2 acc to dim2 acc to dim2 acc to dim2 acc to dim2 acc to dim2 acc to dim2
acc to dim2 acc to dim2 acc to dim2 acc to dim2
[0][0][0]=0 [0][0][1]=12
[1][0][0]=4 [1][0][1]=16
[2][0][0]=8 [2][0][1]=20

[0][1][0]=1 [0][1][1]=13
[1][1][0]=5 [1][1][1]=17
[2][1][0]=9 [2][1][1]=21

[0][2][0]=2 [0][2][1]=14
[1][2][0]=6 [1][2][1]=18
[2][2][0]=10 [2][2][1]=22

[0][3][0]=3 [0][3][1]=15
[1][3][0]=7 [1][3][1]=19
[2][3][0]=11 [2][3][1]=23


Breakpoint 2, free (p=0x45a080)
at /gnu/winsup/src.clean/winsup/cygwin/malloc_wrapper.cc:41
41  free (void *p)
Current language:  auto; currently c++
(gdb) c
Continuing.

Breakpoint 2, free (p=0x45a080)
at /gnu/winsup/src.clean/winsup/cygwin/malloc_wrapper.cc:41
41  free (void *p)
(gdb) c
Continuing.

Program received signal SIGABRT, Aborted.
0x77f88f13 in ?? ()
(gdb)

[Bug rtl-optimization/45472] [4.5/4.6 Regression] ICE: in move_op_ascend, at sel-sched.c:6124 with -fselective-scheduling2

[bonzini at gnu dot org]

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

--- Comment #12 from Paolo Bonzini  2010-10-18 17:12:59 
UTC ---
It would be nice if for

struct a {
char a,b,c,d;
volatile int e;
};

struct a v1, v2;
...
v1 = v2;

the compiler emitted only _two_ memory accesses, one for a/b/c/d and one for e.
 I'm not sure a MEM_REF(&vv1) = MEM_REF(&vv2) with volatile arguments would
achieve this.

So, even though it's just an optimization, it would be better if the IR was
designed to allow it.  Would this be the case if the front-end emitted a
volatile MODIFY_EXPR?

[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap

[bonzini at gnu dot org]

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

Paolo Bonzini  changed:

   What|Removed |Added

  Attachment #21699|0   |1
is obsolete||

--- Comment #85 from Paolo Bonzini  2010-10-18 17:20:05 
UTC ---
Created attachment 22079
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22079
patch

I haven't yet tested this on a cross-compiler, but it bootstrapped and
regtested fine on x86_64-pc-linux-gnu.

[Bug fortran/42169] [4.4/4.5/4.6 Regression] gfortran.dg/pr41928.f90:47: internal compiler error: in store_can_be_removed_p, at ira-emit.c:371

[dave at hiauly1 dot hia.nrc.ca]

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

--- Comment #19 from dave at hiauly1 dot hia.nrc.ca 2010-10-18 17:27:04 UTC ---
> It looks like this was fixed (for hppa at least) in r163190.
> 
> 2010-08-12  Richard Guenther  
> 
> PR tree-optimization/45232
> * tree-ssa-reassoc.c (can_reassociate_p): Disable re-association
> for types with undefined overflow.
> (reassociate_bb): Allow re-associating of bit and min/max
> operations for types with undefined overflow.
> * tree-ssa-forwprop.c (associate_plusminus): New function.
> (tree_ssa_forward_propagate_single_use_vars): Call it.

Is it easy to backport?

Dave

[Bug libstdc++/45866] [C++0x] std::ratio_add, ratio_sub, ratio_multiply, ratio_divide do not have num and den members.

[paolo at gcc dot gnu.org]

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

--- Comment #4 from paolo at gcc dot gnu.org  
2010-10-18 17:28:21 UTC ---
Author: paolo
Date: Mon Oct 18 17:28:15 2010
New Revision: 165649

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165649
Log:
2010-10-18  Paolo Carlini  

PR libstdc++/45866
* include/std/ratio (ratio<>::type): Add.
(ratio_add<>::num, ratio_add<>::den,
ratio_subtract<>::num, ratio_subtract<>::den,
ratio_multiply<>::num, ratio_multiply<>::den,
ratio_divide<>::num, ratio_divide<>::den): Likewise.
* testsuite/20_util/ratio/operations/45866.cc: New.


Added:
trunk/libstdc++-v3/testsuite/20_util/ratio/operations/45866.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/ratio

[Bug libstdc++/45866] [C++0x] std::ratio_add, ratio_sub, ratio_multiply, ratio_divide do not have num and den members.

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #5 from Paolo Carlini  2010-10-18 
17:30:05 UTC ---
Done.

[Bug fortran/46067] hang or spurious compiler message using procedure pointer with pass

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||janus at gcc dot gnu.org

--- Comment #1 from janus at gcc dot gnu.org 2010-10-18 17:39:30 UTC ---
(In reply to comment #0)
> Compiling the attached module, with gfortran 4.6 trunk results in the 
> following
> error message:
> 
> ==
> gfortran test_2.f90
> test_2.f90:6.52:
> 
>   procedure(fun_interface), pointer, pass :: fun_ptr
> 1
> Error: Non-polymorphic passed-object dummy argument of 'fun_ptr' at (1)
> 
> ==
> 
> potential problem 1 : the error message appears incorrect because the target 
> of
> the passed-object dummy argument isn't polymorphic.

No, the error message is perfectly fine. The Fortran 2008 standard clearly
demands:

C456 The passed-object dummy argument shall be a scalar, nonpointer,
nonallocatable dummy data object with the same declared type as the type being
defined; all of its length type parameters shall be assumed; it shall be
polymorphic (4.3.1.3) if and only if the type being defined is extensible
(4.5.7). It shall not have the VALUE attribute.


> potential problem 2: if the error message is correct and if the type of the
> passed-object dummy argument in the sample code is changed from a declaration
> of "type" to "class", the module compiles but hangs when the passed-object
> dummy argument is referenced. 

After changing the PASS arg from TYPE to CLASS, the module compiles fine for me
without any hanging (on x86_64-unknown-linux-gnu at r165600).

[Bug fortran/42169] [4.4/4.5/4.6 Regression] gfortran.dg/pr41928.f90:47: internal compiler error: in store_can_be_removed_p, at ira-emit.c:371

[sje at cup dot hp.com]

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

--- Comment #20 from Steve Ellcey  2010-10-18 17:54:42 
UTC ---
Not really, there are about 300 lines of new code (mostly in a new routine).
It might be that only the change in can_reassociate_p is needed to fix this
bug.
That would be a pretty easy backport and I verified that it fixes the testcase,
I haven't done a complete run with the change though.

[Bug c++/46071] New: ill-formed use of decltype and auto (c++0x) causes segfault

[enniobarbaro at alice dot it]

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

   Summary: ill-formed use of decltype and auto (c++0x) causes
segfault
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: enniobarb...@alice.it


Created attachment 22080
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22080
preprocessed code

Hi all,

The attached code causes a segfault in gcc 4.5.1 (Debian 4.5.1-9), maybe an
infinite recursion of decltype?

my system is a debian testing (kernel 2-6.32-5-amd64)

gcc configuration options:

Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.5.1-9'
--with-bugurl=file:///usr/share/doc/gcc-4.5/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.5 --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.5 --libdir=/usr/lib --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--enable-plugin --enable-gold --with-plugin-ld=ld.gold --enable-objc-gc
--with-arch-32=i586 --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.5.1 (Debian 4.5.1-9)   

command line and output:
gcc-4.5 -std=c++0x bug.cpp  
gcc-4.5: Internal error: Segmentation fault (program cc1plus)   
Please submit a full bug report.
See  for instructions.

Ennio

[Bug c++/46071] [C++0x] ill-formed use of decltype and auto causes segfault

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.10.18 18:23:23
 Ever Confirmed|0   |1
  Known to fail||4.4.4, 4.5.2, 4.6.0

[Bug target/46040] crtstuff.c:308:26: error: '__DTOR_LIST__' undeclared

[dave at hiauly1 dot hia.nrc.ca]

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

--- Comment #3 from dave at hiauly1 dot hia.nrc.ca 2010-10-18 18:28:07 UTC ---
On Fri, 15 Oct 2010, pinskia at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46040
> 
> --- Comment #1 from Andrew Pinski  2010-10-15 
> 22:07:38 UTC ---
> According to PR 21751, the issue was at least at one point was the glibc
> version that was being used did not have eabi support.

Attached change fixes the compile error.  Doing a full bootstrap
and check.

Dave

[Bug tree-optimization/46068] [4.6 Regression] ICE: in consider_split, at ipa-split.c:313 with asm goto and __builtin_unreachable ()

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords|lto |
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.10.18 18:34:22
 CC||jakub at gcc dot gnu.org
Summary|[4.6 Regression] ICE: in|[4.6 Regression] ICE: in
   |consider_split, at  |consider_split, at
   |ipa-split.c:313 with|ipa-split.c:313 with asm
   |-flto/-fwhopr and asm goto  |goto and
   ||__builtin_unreachable ()
 Ever Confirmed|0   |1

--- Comment #1 from Jakub Jelinek  2010-10-18 
18:34:22 UTC ---
void
foo ()
{
  asm goto (""l1);
  __builtin_unreachable ();
  l1:;
}

void
bar ()
{
  foo ();
  foo ();
}

ICEs at -O2 even without -flto.

[Bug debug/46072] New: AIX linker chokes on debug info for uninitialized static variables

[skunk at iskunk dot org]

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

   Summary: AIX linker chokes on debug info for uninitialized
static variables
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sk...@iskunk.org
  Host: powerpc-ibm-aix5.3.0.0
Target: powerpc-ibm-aix5.3.0.0
 Build: powerpc-ibm-aix5.3.0.0


Created attachment 22082
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22082
Tarball containing a minimal test case

GCC 4.5.1 has worked fine on this AIX 5.3 system for some time. The system had
not been kept up-to-date with IBM system patches, however one day we found
these to be needed (to allow a 64-bit Java install), and so installed about
three years' worth of updates over the course of a few days.

After the first couple of updates, we noticed that debug-enabled builds of our
C software began to fail with this error message:

ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 12) in object foo.o:
The symbol refers to a csect with symbol number 0, which was not
found. The new symbol cannot be associated with a csect and
is being ignored.
collect2: ld returned 12 exit status

I've dug into this, and believe I have found what's going on. Attached is a
tarball containing a minimal test case.

The minimal test case has a target which triggers the bug (try-1), a target
which does not (try-2), a target to compile to assembly, and a "clean" target.
Note that it was written on a 64-bit AIX system, hence the use of -maix64, but
the bug also seems to occur in 32-bit mode.

The problem is triggered when debugging information is generated for a variable
declared as "static" (whether inside or outside a function). Here is an excerpt
from the assembly produced by the minimal test case:

FE..main:
.bs _foo.bss_
.stabx  "my_uninit:S-1",my_uninit,133,0
.es
.bs _foo.rw_[RW]
.stabx  "my_init:S-1",my_init,133,0
.es

(my_init is a static variable initialized with a value; my_uninit is
uninitialized.)

My understanding is that .bs is a C_BSTAT declaration, which indicates the
section in which the following variable resides. The section that it references
must be declared by a .csect directive. If we do some grepping, something
interesting comes out:

$ fgrep -n _foo.rw_ foo.s
2:  .csect _foo.rw_[RW],4
43: .bs _foo.rw_[RW]

$ fgrep -n _foo.bss_ foo.s
6:  .lcomm my_uninit,16,_foo.bss_
7:  .lcomm my_init,16,_foo.bss_
40: .bs _foo.bss_

_foo.bss_ has no .csect declaration, and this is presumably what the linker is
complaining about. The same assembly was accepted before, so I'm guessing the
system updates brought with it stricter linking semantics.

Incidentally, this system also has an older version of GCC (2.9-aix51-020209),
and it yields the same error from the minimal test case.

[Bug tree-optimization/46068] [4.6 Regression] ICE: in consider_split, at ipa-split.c:313 with asm goto and __builtin_unreachable ()

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  2010-10-18 
18:55:18 UTC ---
The testcase has 3 basic blocks, one contains the asm goto (for which
estimate_num_insns returns 0 because the string is empty), another one is
__builtin_unreachable () (obviously it doesn't require code) and the last one
is GIMPLE_RETURN (with no return value, again, no code).
So overall_size is 0.  I'd say either we should not call find_split_points at
all if overall_size is 0, or we should nuke that gcc_unreachable () on which it
ICEs in consider_split.

[Bug c/46073] New: __builtin_choose_expr outputs warnings for unused expression

[kevin.waugh at gmail dot com]

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

   Summary: __builtin_choose_expr outputs warnings for unused
expression
   Product: gcc
   Version: 4.0.1
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kevin.wa...@gmail.com


$ gcc -std=c99 -Wall -x c - << EOF
void A(int * p) {}
void B(double * p) {}
int main() {
  int * p = 0;
  __builtin_choose_expr(__builtin_types_compatible_p(__typeof__(p), int *),
A(p), B(p));
  return 0;
}
EOF
: In function ‘main’:
:5: warning: passing argument 1 of ‘B’ from incompatible pointer type

$ gcc -v
Using built-in specs.
Target: i686-apple-darwin9
Configured with: /var/tmp/gcc/gcc-5493~1/src/configure --disable-checking
-enable-werror --prefix=/usr --mandir=/share/man
--enable-languages=c,objc,c++,obj-c++
--program-transform-name=/^[cg][^.-]*$/s/$/-4.0/
--with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib
--build=i686-apple-darwin9 --with-arch=apple --with-tune=generic
--host=i686-apple-darwin9 --target=i686-apple-darwin9
Thread model: posix
gcc version 4.0.1 (Apple Inc. build 5493)

[Bug c/46073] __builtin_choose_expr outputs warnings for unused expression

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  2010-10-18 
19:00:51 UTC ---
I think this is correct as  __builtin_choose_expr still does semantically
checking on the two arguments.  Not to mention  __builtin_choose_expr was added
only to support Altivec intrinsics and that has since been moved away from
that.

[Bug libstdc++/45999] runtime error in std::vector python pretty printer.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||4.6.0
 Resolution||FIXED
   Target Milestone|--- |4.5.2

--- Comment #3 from Jonathan Wakely  2010-10-18 
19:16:03 UTC ---
I've backported the fix:
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165658

Thanks for trying the printers and submitting bug reports, Pawel

[Bug c/46073] __builtin_choose_expr outputs warnings for unused expression

[kevin.waugh at gmail dot com]

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

--- Comment #2 from kevin.waugh at gmail dot com 2010-10-18 19:17:17 UTC ---
(In reply to comment #1)
> I think this is correct as  __builtin_choose_expr still does semantically
> checking on the two arguments.  Not to mention  __builtin_choose_expr was 
> added
> only to support Altivec intrinsics and that has since been moved away from
> that.

>From the documentation:
Note: This construct is only available for C. Furthermore, the unused
expression (exp1 or exp2 depending on the value of const_exp) may still
generate syntax errors. This may change in future revisions.

What are the chances of getting this changed, or having an option to suppress
warnings on the unevaluated argument?  The implementation of tgmath.h is
essentially using __builtin_choose_expr for the same purpose, but it appers to
avoid any warnings/errors because of implicit casts.

[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap

[sje at cup dot hp.com]

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

--- Comment #86 from Steve Ellcey  2010-10-18 19:52:39 
UTC ---
I was able to bootstrap the 32 bit PA compiler using the latest patch. I
haven't done a full test run yet but I will do that overnight.

[Bug c/46073] __builtin_choose_expr outputs warnings for unused expression

[joseph at codesourcery dot com]

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

--- Comment #3 from joseph at codesourcery dot com  2010-10-18 19:55:25 UTC ---
On Mon, 18 Oct 2010, pinskia at gcc dot gnu.org wrote:

> checking on the two arguments.  Not to mention  __builtin_choose_expr was 
> added
> only to support Altivec intrinsics and that has since been moved away from
> that.

When C1X _Generic is implemented that will have similar issues.

[Bug c/46041] __FP_FAST_FMA not defined with -E

[meissner at gcc dot gnu.org]

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

--- Comment #8 from Michael Meissner  2010-10-18 
20:01:24 UTC ---
Created attachment 22083
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22083
Patch that redefines mode_has_fma so that it works with -save-temps

[Bug fortran/46067] [F03] invalid procedure pointer assignment not detected

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||accepts-invalid
Summary|hang or spurious compiler   |[F03] invalid procedure
   |message using procedure |pointer assignment not
   |pointer with pass   |detected

--- Comment #2 from janus at gcc dot gnu.org 2010-10-18 20:08:52 UTC ---
(In reply to comment #1)
> > potential problem 2: if the error message is correct and if the type of the
> > passed-object dummy argument in the sample code is changed from a 
> > declaration
> > of "type" to "class", the module compiles but hangs when the passed-object
> > dummy argument is referenced. 
> 
> After changing the PASS arg from TYPE to CLASS, the module compiles fine for 
> me
> without any hanging (on x86_64-unknown-linux-gnu at r165600).

Ok, one has to be a little careful at this point: When changing both TYPE
declarations into CLASS (inside 'fun_interface' and 'fun1'), the program
compiles ok and apparently gives the correct output (assuming that the
undefined variable 'pi' is zero, contrary to its suggestive name):

  fun1(pi)   id =1
   1.000 

However, when changing only the TYPE declaration in 'fun_interface', but not
the one in 'fun1', the program compiles but gives bogus results:

  fun1(pi)   id =  6295264
   1.000

This is due to the fact that the resulting program is invalid, which gfortran
currently fails to detect.

In summary: The only bug that gfortran exhibits in the context of this PR is
the fact that it does not reject the invalid procedure pointer assignment in
the following program:


  implicit none

  type test_type
integer :: id
procedure(fun_interface), pointer, pass :: fun_ptr
  end type test_type

  abstract interface
function fun_interface(t,x) result(res)
  import :: test_type
  real, intent(in) :: x
  class(test_type) :: t
  real :: res
end function fun_interface
  end interface  

  type(test_type),dimension(1) :: funs

  funs(1)%id = 1
  funs(1)%fun_ptr => fun1!!! invalid !!!
  print *, " fun1(pi) ",funs(1)%fun_ptr(0.)

contains

  function fun1 (t,x) result (res)
real, intent(in) :: x
type(test_type) :: t
real :: res
print *," id = ", t%id
   res=cos(x)
  end function fun1

end

[Bug c++/46075] New: g++ wrongly lookups builtin types in ADL (compiles wrong code)

[slyfox at inbox dot ru]

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

   Summary: g++ wrongly lookups builtin types in ADL (compiles
wrong code)
   Product: gcc
   Version: 4.4.5
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sly...@inbox.ru


clang++ and comeau don't compile following code:

inst.cc:17:9: error: use of undeclared identifier 'my_foo'
my_foo ((const T *)0);
^
inst.cc:36:7: note: in instantiation of member function 'my_T::my_T'
requested here
User::User() { }
  ^
1 error generated.

// -- inst.cc -

// http://blog.llvm.org/2009/12/dreaded-two-phase-name-lookup.html

// should fail

// 23:01:10 < dgregor> slyfox_: Clang is correct
// 23:01:39 < slyfox_> dgregor: how can i make this code compile with clang w/o
moving declaration upper?
// 23:02:49 < dgregor> you'll need to move the declaration up, or instantiate
my_T with a non-builtin type (so that 
// argument-dependent lookup can find my_foo in the
namespace of that type)
// 23:03:27 < slyfox_> so builtin types are special
// 23:04:02 < dgregor> not special, really; they have no "associated
namespaces", i.e., there's nowhere for the compiler to l
ook 
// at instantiation time

template struct my_T {
my_T()
{
// this one explicitely mentions 'T' as one of params
my_foo ((const T *)0);

// this one would be 'T' independent, and gcc will report
// an error it i'll try to use this one instead.
//my_foo((const T *)0);
}
};

struct User {
User(); // explicit c-tor
my_T t;
};

// we specialize my_foo for 'const char *'
static void my_foo (const char *) {}

// To be checked. Should work too
//static void my_foo(const void *) {}

User::User() { }

int main()
{
User u;
return 0;
}

[Bug c++/46075] g++ wrongly lookups builtin types in ADL (compiles wrong code)

[slyfox at inbox dot ru]

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

--- Comment #1 from Sergei Trofimovich  2010-10-18 
20:23:10 UTC ---
Created attachment 22084
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22084
test example. compilation should fail

[Bug c++/46075] g++ wrongly lookups builtin types in ADL (compiles wrong code)

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  2010-10-18 
20:24:25 UTC ---
Actually there is an open question if clang or gcc is correct according to the
C++ standards committee.  There is a defect report about foundational types.

[Bug c++/46075] g++ wrongly lookups builtin types in ADL (compiles wrong code)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #3 from Andrew Pinski  2010-10-18 
20:27:20 UTC ---
I wish clang folks stop spreading FUD about GCC here.

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

[Bug c++/29131] [DR 225] Bad name lookup for templates due to fundamental types namespace for ADL.

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||slyfox at inbox dot ru

--- Comment #14 from Andrew Pinski  2010-10-18 
20:27:20 UTC ---
*** Bug 46075 has been marked as a duplicate of this bug. ***

[Bug c++/225] using declaration doesn't take into account member overloading

[antony.king at st dot com]

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

--- Comment #4 from Antony King  2010-10-18 20:29:01 
UTC ---
I am out of the office until 25th October 2010 and am unable to respond to your
email until then. If you have any enquiries concerning the ST40 Micro Toolset
then please send them to st40.supp...@st.com.

[Bug c++/46075] g++ wrongly lookups builtin types in ADL (compiles wrong code)

[slyfox at inbox dot ru]

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

--- Comment #4 from Sergei Trofimovich  2010-10-18 
20:43:24 UTC ---
(In reply to comment #2)
> Actually there is an open question if clang or gcc is correct according to the
> C++ standards committee.  There is a defect report about foundational types.

Sorry, I'm far from standards writers. I just want software to be bug free.

You mean "standard is buggy and gcc refuses to implement ill behaviour", right?
Or behaviour is not specified by standard in such case?

g++ might issue a warning about silly program(mer) then.

[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

Summary|[meta-bug] Mozilla does not |[meta-bug] Issues with
   |build with LTO  |building Mozilla with LTO

--- Comment #9 from Jan Hubicka  2010-10-18 
20:48:03 UTC ---
Updated summary, Mozilla now builds with unpatched mainline (with checking
disabled)

[Bug fortran/46060] [F03] procedure pointer component referenced without argument list

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from janus at gcc dot gnu.org 2010-10-18 20:48:26 UTC ---
Here is a preliminary patch:


Index: gcc/fortran/primary.c
===
--- gcc/fortran/primary.c   (revision 165600)
+++ gcc/fortran/primary.c   (working copy)
@@ -1883,13 +1883,20 @@ gfc_match_varspec (gfc_expr *primary, int equiv_fl
   if (component->attr.proc_pointer && ppc_arg
  && !gfc_matching_procptr_assignment)
{
+ /* Procedure pointer component call: Look for argument list.  */
  m = gfc_match_actual_arglist (sub_flag,
&primary->value.compcall.actual);
  if (m == MATCH_ERROR)
return MATCH_ERROR;
- if (m == MATCH_YES)
-   primary->expr_type = EXPR_PPC;

+ if (m == MATCH_NO)
+   {
+ gfc_error ("Procedure pointer component '%s' requires an "
+"argument list at %C", component->name);
+ return MATCH_ERROR;
+   }
+
+ primary->expr_type = EXPR_PPC;
   break;
}


It rejects the test cases in comment #0, #3 and #4 with the proper error
message, but is otherwise untested.

[Bug c++/46075] g++ wrongly lookups builtin types in ADL (compiles wrong code)

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  2010-10-18 
20:49:03 UTC ---
(In reply to comment #4)
> (In reply to comment #2)
> You mean "standard is buggy and gcc refuses to implement ill behaviour", 
> right?
> Or behaviour is not specified by standard in such case?

The standard is buggy here and what GCC does is correct in one reading of the
standard but incorrect in another reading.  This is what a defect report is
about.

[Bug middle-end/46076] New: [4.6 regression] constant propogation and compile-time math no longer happening versus 4.4 and 4.5

[matt at use dot net]

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

   Summary: [4.6 regression] constant propogation and compile-time
math no longer happening versus 4.4 and 4.5
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@use.net


For the following code:


#include 

typedef unsigned char(*Calculable)(void);

static unsigned char one() { return 1; }
static unsigned char two() { return 2; }

static void print(Calculable calculate)
{
printf("%d\n", calculate());
printf("+1: %d\n", calculate() + 1);
}

int main()
{
print(one);
print(two);

return 0;
}


GCC 4.4 (Ubuntu/Linaro 4.4.4-14ubuntu5) and 4.5(Ubuntu/Linaro 4.5.1-7ubuntu2),
when using -O3 on amd64 using Ubuntu 10.10's packages, produce the following
code:


004005a0 :
  4005a0:   48 83 ec 08 subrsp,0x8
  4005a4:   ba 01 00 00 00  movedx,0x1
  4005a9:   be 00 07 40 00  movesi,0x400700
  4005ae:   bf 01 00 00 00  movedi,0x1
  4005b3:   31 c0   xoreax,eax
  4005b5:   e8 ae fe ff ff  call   400468 <__printf_...@plt>
  4005ba:   ba 02 00 00 00  movedx,0x2
  4005bf:   be fc 06 40 00  movesi,0x4006fc
  4005c4:   bf 01 00 00 00  movedi,0x1
  4005c9:   31 c0   xoreax,eax
  4005cb:   e8 98 fe ff ff  call   400468 <__printf_...@plt>
  4005d0:   ba 02 00 00 00  movedx,0x2
  4005d5:   be 00 07 40 00  movesi,0x400700
  4005da:   bf 01 00 00 00  movedi,0x1
  4005df:   31 c0   xoreax,eax
  4005e1:   e8 82 fe ff ff  call   400468 <__printf_...@plt>
  4005e6:   ba 03 00 00 00  movedx,0x3
  4005eb:   be fc 06 40 00  movesi,0x4006fc
  4005f0:   bf 01 00 00 00  movedi,0x1
  4005f5:   31 c0   xoreax,eax
  4005f7:   e8 6c fe ff ff  call   400468 <__printf_...@plt>
  4005fc:   31 c0   xoreax,eax
  4005fe:   48 83 c4 08 addrsp,0x8
  400602:   c3  ret

where the constants are correctly propogated and the compile-time math occurs.

With Ubuntu 10.10's gcc-snapshot of 4.6 (Ubuntu 20101004-0ubuntu1) or an
alternate 4.6 version (Sourcery G++ 2010.09-31), neither of these things
happens, even with -fwhole-program:

00400510 <_ZL3onev>:
  400510:   b8 01 00 00 00  moveax,0x1
  400515:   c3  ret
  400516:   eb 08   jmp400520 <_ZL3twov>
  400518:   90  nop
  400519:   90  nop
  40051a:   90  nop
  40051b:   90  nop
  40051c:   90  nop
  40051d:   90  nop
  40051e:   90  nop
  40051f:   90  nop

00400520 <_ZL3twov>:
  400520:   b8 02 00 00 00  moveax,0x2
  400525:   c3  ret
  400526:   eb 08   jmp400530 <_ZL5printPFhvE>
  400528:   90  nop
  400529:   90  nop
  40052a:   90  nop
  40052b:   90  nop
  40052c:   90  nop
  40052d:   90  nop
  40052e:   90  nop
  40052f:   90  nop

00400530 <_ZL5printPFhvE>:
  400530:   53  push   rbx
  400531:   48 89 fbmovrbx,rdi
  400534:   ff d7   call   rdi
  400536:   bf 74 06 40 00  movedi,0x400674
  40053b:   0f b6 f0movzx  esi,al
  40053e:   31 c0   xoreax,eax
  400540:   e8 b3 fe ff ff  call   4003f8 
  400545:   ff d3   call   rbx
  400547:   5b  poprbx
  400548:   0f b6 f0movzx  esi,al
  40054b:   bf 70 06 40 00  movedi,0x400670
  400550:   31 c0   xoreax,eax
  400552:   83 c6 01addesi,0x1
  400555:   e9 9e fe ff ff  jmp4003f8 
  40055a:   eb 04   jmp400560 
  40055c:   90  nop
  40055d:   90  nop
  40055e:   90  nop
  40055f:   90  nop

00400560 :
  400560:   48 83 ec 08 subrsp,0x8
  400564:   bf 10 05 40 00  movedi,0x400510
  400569:   e8 c2 ff ff ff  call   400530 <_ZL5printPFhvE>
  40056e:   bf 20 05 40 00

[Bug middle-end/46076] [4.6 regression] constant propogation and compile-time math no longer happening versus 4.4 and 4.5

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  2010-10-18 
21:15:16 UTC ---
This is a micro benchmark really; we would inline it as far as I can tell if we
have other things going on.

[Bug bootstrap/46018] [4.6 Regression] Bootstrap fails on i386-pc-solaris2.10

[ahaas at airmail dot net]

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

--- Comment #9 from Art Haas  2010-10-18 21:27:59 UTC 
---
Once the patch discussed in the following mail was applied:

http://gcc.gnu.org/ml/gcc-patches/2010-10/msg01538.html

I can confirm that the bootstrap failure I've been seeing has returned:

/home/ahaas/gnu/gcc.git/gcc/lto/lto-lang.c: In function 'lto_type_for_mode':
/home/ahaas/gnu/gcc.git/gcc/lto/lto-lang.c:951:1: internal compiler error: in
dwarf2out_frame_debug_adjust_cfa, at dwarf2out.c:1881

I successfully bootstrapped the compiler when the latest revision in my repo
was the one immediately before the frame-pointer patch was applied:

commit a1176db975a2a05d65e0277dd812d4e6844814b2
Author: nicola 
Date:   Mon Oct 18 18:54:01 2010 +

In gcc/objc/:
{ ... snip ... }

[Bug fortran/46067] [F03] invalid procedure pointer assignment not detected

[janus at gcc dot gnu.org]

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

--- Comment #3 from janus at gcc dot gnu.org 2010-10-18 21:29:31 UTC ---
(In reply to comment #1)
> > potential problem 2: if the error message is correct and if the type of the
> > passed-object dummy argument in the sample code is changed from a 
> > declaration
> > of "type" to "class", the module compiles but hangs when the passed-object
> > dummy argument is referenced. 
> 
> After changing the PASS arg from TYPE to CLASS, the module compiles fine for 
> me
> without any hanging (on x86_64-unknown-linux-gnu at r165600).

I can confirm the runtime hanging on Mac OS. It happens for the original test
case as well as for this reduction:


  implicit none

  type test_type
procedure(fun1), pointer, pass :: fun_ptr
  end type test_type

  type(test_type) :: funs

  funs%fun_ptr => fun1
  print *, " fun1(pi) ",funs%fun_ptr(0.)

contains

  real function fun1 (t,x)
real, intent(in) :: x
class(test_type) :: t
print *," in fun1 "
fun1 = cos(x)
  end function fun1

end


The reason seems to be the "recursive I/O" in the program, i.e. the fact that
the call to 'fun_ptr'/'fun1' happens inside a PRINT statement, but 'fun1'
itself contains another PRINT statement. I think I've seen this kind of
behavior before on Darwin, though I'm not sure if the Fortran standard allows
it or whether gfortran should actually reject it.

[Bug fortran/46067] [F03] invalid procedure pointer assignment not detected

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  2010-10-18 
21:31:54 UTC ---
Beware the INVALID recursive IOs: they hang on darwin!-(see pr 30617).

[Bug middle-end/43760] [4.6 regression] New test failures

[sje at gcc dot gnu.org]

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

--- Comment #8 from Steve Ellcey  2010-10-18 21:34:51 
UTC ---
Author: sje
Date: Mon Oct 18 21:34:46 2010
New Revision: 165664

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165664
Log:
2010-10-18  Steve Ellcey  

PR target/36898
PR middle-end/43760
* config/ia64/ia64.c (rws_access_regno): Remove predicate check.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/ia64/ia64.c

[Bug target/36898] Insufficient qp-mutex declarations

[sje at gcc dot gnu.org]

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

--- Comment #3 from Steve Ellcey  2010-10-18 21:34:51 
UTC ---
Author: sje
Date: Mon Oct 18 21:34:46 2010
New Revision: 165664

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165664
Log:
2010-10-18  Steve Ellcey  

PR target/36898
PR middle-end/43760
* config/ia64/ia64.c (rws_access_regno): Remove predicate check.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/ia64/ia64.c

[Bug middle-end/46076] [4.6 regression] constant propogation and compile-time math no longer happening versus 4.4 and 4.5

[matt at use dot net]

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

--- Comment #2 from Matt Hargett  2010-10-18 21:36:23 UTC 
---
This is a reduction from proprietary (and complex) code, and the optimization
has regressed there as well. Any diagnosis on why it would have regressed and
not triggered a testsuite failure?

[Bug middle-end/43760] [4.6 regression] New test failures

[sje at cup dot hp.com]

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

Steve Ellcey  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED

--- Comment #9 from Steve Ellcey  2010-10-18 21:48:17 
UTC ---
Resolved by making IA64 more conservative in its bundling and not putting
multiple (predicated) instructions in one bundle if they read/write the same
register.