[Bug bootstrap/45514] [4.6 Regression] Bootstrap broken on arm-linux in locate_neon_builtin_icode

[ramana at gcc dot gnu dot org]

--- Comment #1 from ramana at gcc dot gnu dot org  2010-09-03 07:19 ---


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


-- 

ramana at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug bootstrap/45444] [4.6 regression] ARM bootstrap failure: uninitialized const member in 'neon_builtin_datum' is invalid in C++ [-Werror=c++-compat]

[ramana at gcc dot gnu dot org]

--- Comment #6 from ramana at gcc dot gnu dot org  2010-09-03 07:19 ---
*** Bug 45514 has been marked as a duplicate of this bug. ***


-- 

ramana at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||laurent at guerby dot net


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

[Bug ada/45499] Ada bootstrap broken

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2010-09-03 07:30 ---
I think for -D and -U at least the canonicalization should be joined instead of
separate, because that's how people are used to write these options (which
doesn't mean the tools the driver invokes shouldn't be changed to handle both).
And for -I- similarly.


-- 


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

[Bug c++/45515] New: Unable to find base class constructor of templated base class

[andareed at gmail dot com]

The following code fails to compile:

template 
class Foo {
 public:
  Foo(int i, int j) {}
};

class Bar : public Foo {
  Bar() : Foo(0, 0) {}
};

This produces the following output:

foo.cc: In constructor ?Bar::Bar()?:
foo.cc:8: error: class ?Bar? does not have any field named ?Foo?
foo.cc:8: error: no matching function for call to ?Foo::Foo()?
foo.cc:4: note: candidates are: Foo::Foo(int, int) [with T = int]
foo.cc:2: note: Foo::Foo(const Foo&)

If I change line 8 to "Bar() : Foo(0, 0) {}" it compiles fine. The
original code also compiles fine with clang and comeau. Tested with head gcc,
4.3, and 4.4.


-- 
   Summary: Unable to find base class constructor of templated base
class
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andareed at gmail dot com
 GCC build triplet: x86_64-linux-gnu
  GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu


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

[Bug fortran/44602] [F2008] EXIT: Jump to end of construct

[domob at gcc dot gnu dot org]

--- Comment #6 from domob at gcc dot gnu dot org  2010-09-03 08:02 ---
Subject: Bug 44602

Author: domob
Date: Fri Sep  3 08:01:51 2010
New Revision: 163798

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163798
Log:
2010-09-03  Daniel Kraft  

PR fortran/44602
* gfortran.h (struct gfc_code): Renamed `whichloop' to
`which_construct' as this is no longer restricted to loops.
* parse.h (struct gfc_state_data): New field `construct'.
* match.c (match_exit_cycle): Handle EXIT from non-loops.
* parse.c (push_state): Set `construct' field.
* resolve.c (resolve_select_type): Extend comment.
* trans-stmt.c (gfc_trans_if): Add exit label.
(gfc_trans_block_construct), (gfc_trans_select): Ditto.
(gfc_trans_simple_do): Store exit/cycle labels on the gfc_code itself.
(gfc_trans_do), (gfc_trans_do_while): Ditto.
(gfc_trans_exit): Use new name `which_construct' instead of
`whichloop'.
(gfc_trans_cycle): Ditto.
(gfc_trans_if_1): Use fold_build3_loc instead of fold_build3.

2010-09-03  Daniel Kraft  

PR fortran/44602
* gfortran.dg/exit_2.f08; Adapt error messages.
* gfortran.dg/exit_3.f08: New test.
* gfortran.dg/exit_4.f08: New test.
* gfortran.dg/exit_5.f03: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/exit_3.f08
trunk/gcc/testsuite/gfortran.dg/exit_4.f08
trunk/gcc/testsuite/gfortran.dg/exit_5.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/match.c
trunk/gcc/fortran/parse.c
trunk/gcc/fortran/parse.h
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/trans-stmt.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/exit_2.f08


-- 


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

[Bug fortran/44602] [F2008] EXIT: Jump to end of construct

[domob at gcc dot gnu dot org]

--- Comment #7 from domob at gcc dot gnu dot org  2010-09-03 08:04 ---
Fixed.


-- 

domob at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/34162] F2008: Allow internal procedures as actual argument

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2010-09-03 08:39 ---
Asked at gcc-patches/fortran for suggestions how to implement this:
http://gcc.gnu.org/ml/gcc-patches/2010-09/msg00211.html


-- 


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

[Bug c++/45515] Unable to find base class constructor of templated base class

[andareed at gmail dot com]

--- Comment #1 from andareed at gmail dot com  2010-09-03 08:41 ---
Never mind, it compiles with head gcc.


-- 

andareed at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

build gcc (c,c++,ada) for ia64-hp-hpux11.23 fails

[hobi69]

I need an native gcc (c,c++,ada) for TARGET=ia64-hp-hpux11.23.
Because to build and gcc (with ada) you already need a gcc (with ada),
so I try to reach this by cross compiling from a linux platform (SLES11.1
with gcc 4.5.0).
(I have already done this for hppa2.0w-hp-hpux11.11 , which works fine)

When I start to build the cross compiler the bootstrap fails:
(it fails in gcc-4.5.1/gcc/ada/gcc-interface/Makefile::2444:gnatlib:
../stamp-gnatlib-$(RTSDIR) ../stamp-gnatlib2-$(RTSDIR))


$ ../gcc-4.5.0/configure --prefix=/cross/ia/C1 --enable-languages=c,c++,ada
--with-gnu-as --with-sysroot=/cross/iaroot --enable-threads --disable-nls
--disable-shared --disable-bootstrap --target=ia64-hp-hpux11.23

...
make[3]: Entering directory `/cross/build/objgccC1/gcc/ada'
rm -f rts/s-*.ali
rm -f rts/s-*.o
rm -f rts/a-*.ali
rm -f rts/a-*.o
rm -f rts/*.ali
rm -f rts/*.o
rm -f rts/*.a
rm -f rts/*.sl
touch ../stamp-gnatlib2-rts
rm -f ../stamp-gnatlib-rts
rm -rf rts
mkdir -p rts
chmod u+w rts
ln -s /cross/build/gcc-4.5.0/gcc/ada/ada.ads rts ;  ln -s
/cross/build/gcc-4.5.0/gcc/ada/calendar.ads rts ;  ln -s
/cross/build/gcc-4.5.0/gcc/ada/directio.ads rts ;  ln -s
/cross/build/gcc-4.5.0/gcc/ada/gnat.ads rts ;  ln -s
/cross/build/gcc-4.5.0/gcc/ada/interfac.ads rts ;  ln -s
/cross/build/gcc-4.5.0/gcc/ada/ioexcept.ads rts ;  ln -s
/cross/build/gcc-4.5.0/gcc/ada/machcode.ads rts ;  ln -s
/cross/build/gcc-4.5.0/gcc/ada/text_io.ads rts ;  ln -s
/cross/build/gcc-4.5.0/gcc/ada/unchconv.ads rts ;  ln -s
/cross/build/gcc-4.5.0/gcc/ada/unchdeal.ads rts ;  ln -s
/cross/build/gcc-4.5.0/gcc/ada/sequenio.ads rts ;  ln -s
/cross/build/gcc-4.5.0/gcc/ada/system.ads rts ;  ln -s
/cross/build/gcc-4.5.0/gcc/ada/memtrack.adb rts ;  ln -s
/cross/build/gcc-4.5.0/gcc/ada/a-[a-o]*.adb rts ;  ln -s
/cross/build/gcc-4.5.0/gcc/ada/a-[p-z]*.adb rts ;  ln -s
/cross/build/gcc-4.5.0/gcc/ada/a-[a-o]*.ads rts ;  ln -s
/cross/build/gcc-4.5.0/gcc/ada/a-[p-z]*.ads rts ;  ln -s
/cross/build/gcc-4.5.0/gcc/ada/g-*.ad? rts ;  ln -s
/cross/build/gcc-4.5.0/gcc/ada/i-*.ad? rts ;  ln -s
/cross/build/gcc-4.5.0/gcc/ada/s-[a-o]*.adb rts ;  ln -s
/cross/build/gcc-4.5.0/gcc/ada/s-[p-z]*.adb rts ;  ln -s
/cross/build/gcc-4.5.0/gcc/ada/s-[a-o]*.ads rts ;  ln -s
/cross/build/gcc-4.5.0/gcc/ada/s-[p-z]*.ads rts ;  ln -s
/cross/build/gcc-4.5.0/gcc/ada/adadecode.c rts ;  ln -s
/cross/build/gcc-4.5.0/gcc/ada/adadecode.h rts ;  ln -s
/cross/build/gcc-4.5.0/gcc/ada/adaint.c rts ;  ln -s
/cross/build/gcc-4.5.0/gcc/ada/adaint.h rts ;  ln -s
/cross/build/gcc-4.5.0/gcc/ada/argv.c rts ;  ln -s
/cross/build/gcc-4.5.0/gcc/ada/cio.c rts ;  ln -s
/cross/build/gcc-4.5.0/gcc/ada/cstreams.c rts ;  ln -s
/cross/build/gcc-4.5.0/gcc/ada/errno.c rts ;  ln -s
/cross/build/gcc-4.5.0/gcc/ada/exit.c rts ;  ln -s
/cross/build/gcc-4.5.0/gcc/ada/cal.c rts ;  ln -s
/cross/build/gcc-4.5.0/gcc/ada/ctrl_c.c rts ;  ln -s
/cross/build/gcc-4.5.0/gcc/ada/env.c rts ;  ln -s
/cross/build/gcc-4.5.0/gcc/ada/env.h rts ;  ln -s
/cross/build/gcc-4.5.0/gcc/ada/arit64.c rts ;  ln -s
/cross/build/gcc-4.5.0/gcc/ada/raise.h rts ;  ln -s
/cross/build/gcc-4.5.0/gcc/ada/raise.c rts ;  ln -s
/cross/build/gcc-4.5.0/gcc/ada/sysdep.c rts ;  ln -s
/cross/build/gcc-4.5.0/gcc/ada/aux-io.c rts ;  ln -s
/cross/build/gcc-4.5.0/gcc/ada/init.c rts ;  ln -s
/cross/build/gcc-4.5.0/gcc/ada/initialize.c rts ;  ln -s
/cross/build/gcc-4.5.0/gcc/ada/seh_init.c rts ;  ln -s
/cross/build/gcc-4.5.0/gcc/ada/final.c rts ;  ln -s
/cross/build/gcc-4.5.0/gcc/ada/tracebak.c rts ;  ln -s
/cross/build/gcc-4.5.0/gcc/ada/tb-alvms.c rts ;  ln -s
/cross/build/gcc-4.5.0/gcc/ada/tb-alvxw.c rts ;  ln -s
/cross/build/gcc-4.5.0/gcc/ada/tb-gcc.c rts ;  ln -s
/cross/build/gcc-4.5.0/gcc/ada/expect.c rts ;  ln -s
/cross/build/gcc-4.5.0/gcc/ada/mkdir.c rts ;  ln -s
/cross/build/gcc-4.5.0/gcc/ada/socket.c rts ;  ln -s
/cross/build/gcc-4.5.0/gcc/ada/gsocket.h rts ;  ln -s
/cross/build/gcc-4.5.0/gcc/ada/targext.c rts ; true
rm -f  rts/a-intnam.ads  rts/s-inmaop.adb  rts/s-intman.adb 
rts/s-osinte.adb  rts/s-osinte.ads  rts/s-osprim.adb  rts/s-taprop.adb 
rts/s-taspri.ads  rts/s-tpopsp.adb  rts/system.ads  rts/a-except.ads 
rts/a-except.adb
rm -f rts/*-*-*.ads rts/*-*-*.adb
ln -s /cross/build/gcc-4.5.0/gcc/ada/a-intnam-hpux.ads rts/a-intnam.ads;  ln
-s /cross/build/gcc-4.5.0/gcc/ada/s-inmaop-posix.adb rts/s-inmaop.adb;  ln
-s /cross/build/gcc-4.5.0/gcc/ada/s-intman-posix.adb rts/s-intman.adb;  ln
-s /cross/build/gcc-4.5.0/gcc/ada/s-osinte-posix.adb rts/s-osinte.adb;  ln
-s /cross/build/gcc-4.5.0/gcc/ada/s-osinte-hpux.ads rts/s-osinte.ads;  ln -s
/cross/build/gcc-4.5.0/gcc/ada/s-osprim-posix.adb rts/s-osprim.adb;  ln -s
/cross/build/gcc-4.5.0/gcc/ada/s-taprop-posix.adb rts/s-taprop.adb;  ln -s
/cross/build/gcc-4.5.0/gcc/ada/s-taspri-posix-noaltstack.ads
rts/s-taspri.ads;  ln -s
/cross/build/gcc-4.5.0/gcc/ada/s-tpopsp-posix-foreign.adb rts/s-tpopsp.adb; 
ln -s /cross/build/gcc-4.5.0/gcc/ada/system-hpux-ia64.ads rts/system.ads; 
ln -s /cross/build/gcc-4.5.0/gcc/ada/a-except-2005.ads r

[Bug debug/45419] -fcompare-debug failure at -O3

[aoliva at gcc dot gnu dot org]

--- Comment #13 from aoliva at gcc dot gnu dot org  2010-09-03 08:59 ---
The different types arise when, say, we copyprop a const-unqualified variable
into a MEM_REF that used to reference a const-qualified temp.  The top-level
const qualifications are irrelevant at that point, for we're dealing with
rvalues of pointer types.  I'm experimenting with simply dropping the
TYPE_QUALS test from tree-pretty-print.  This fixed the pt.c -fcompare-debug
problem.  Richard, is there any reason for top-level qualifiers to be relevant
in MEM_REF operands?


-- 


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

[Bug debug/45419] -fcompare-debug failure at -O3

[rguenther at suse dot de]

--- Comment #14 from rguenther at suse dot de  2010-09-03 09:06 ---
Subject: Re:  -fcompare-debug failure at -O3

On Fri, 3 Sep 2010, aoliva at gcc dot gnu dot org wrote:

> --- Comment #13 from aoliva at gcc dot gnu dot org  2010-09-03 08:59 
> ---
> The different types arise when, say, we copyprop a const-unqualified variable
> into a MEM_REF that used to reference a const-qualified temp.  The top-level
> const qualifications are irrelevant at that point, for we're dealing with
> rvalues of pointer types.  I'm experimenting with simply dropping the
> TYPE_QUALS test from tree-pretty-print.  This fixed the pt.c -fcompare-debug
> problem.  Richard, is there any reason for top-level qualifiers to be relevant
> in MEM_REF operands?

Hmm, not really.  But in the end at some point I want to drop the
fancy printing of MEM_REFs.

What you can do is instead of

dump_generic_node (buffer, TREE_TYPE (TREE_OPERAND (node, 1)),
   spc, flags | TDF_SLIM, false);

do

dump_generic_node (buffer, TYPE_MAIN_VARIANT (TREE_TYPE 
(TREE_OPERAND (node, 1))),
   spc, flags | TDF_SLIM, false);

as that is what matters.  Or even better, see if the issue goes away
when you change the gimplifier to use the main variant in the first
place.  That's sth I would prefer - not sure why I missed that.

Richard.


-- 


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

[Bug c++/45501] Compiler does not find template function if member is addressed with "this"

[paolo dot carlini at oracle dot com]

--- Comment #4 from paolo dot carlini at oracle dot com  2010-09-03 09:09 
---
Ah, ok, thanks Jason.


-- 


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

[Bug tree-optimization/45085] [4.6 Regression] incorrect -Wuninitialized warning

[jakub at gcc dot gnu dot org]

--- Comment #8 from jakub at gcc dot gnu dot org  2010-09-03 09:10 ---
Seems http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162842
has been committed, just Honza forgot to mention the PR in the ChangeLog,
testcase and commit message.
I certainly can't reproduce this bug with 20100811 gcc and later, while I can
with 20100730.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/45506] [4.6 Regression] tree_mem_ref_addr, at tree-ssa-address.c:278

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2010-09-03 09:28 ---
Mine.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2010-09-02 19:49:24 |2010-09-03 09:28:41
   date||
Summary|tree_mem_ref_addr, at tree- |[4.6 Regression]
   |ssa-address.c:278   |tree_mem_ref_addr, at tree-
   ||ssa-address.c:278


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

[Bug fortran/45505] [4.6 Regression] gfortran.dg/pr25923.f90

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0


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

[Bug c/45502] Passing multi-dimensional array to function using C99 VLA function parameter format fails if function is inlined

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2010-09-03 09:39 ---
I can reproduce it with the SUSE release, it seems to be one of the backported
alias fixes that causes this (and it vanishes with -fno-strict-aliasing).

Works for all FSF releases I tried.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME


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

[Bug middle-end/45496] Static members of templates cause LTO to omit required code

[rguenth at gcc dot gnu dot org]

--- Comment #24 from rguenth at gcc dot gnu dot org  2010-09-03 09:47 
---
Fixed for 4.5.2.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug middle-end/45496] Static members of templates cause LTO to omit required code

[rguenth at gcc dot gnu dot org]

--- Comment #25 from rguenth at gcc dot gnu dot org  2010-09-03 09:48 
---
Subject: Bug 45496

Author: rguenth
Date: Fri Sep  3 09:47:09 2010
New Revision: 163801

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163801
Log:
2010-09-03  Richard Guenther  

* lto-elf.c (validate_file): Always error if validation fails.

2010-09-03  Richard Guenther  

PR lto/45496
Backport from mainline
2010-07-07  Jakub Jelinek  

* lto-elf.c (ELFOSABI_NONE, ELFOSABI_LINUX): Define if not defined.
(validate_file): Allow merging of ELFOSABI_NONE with ELFOSABI_LINUX
objects.

Modified:
branches/gcc-4_5-branch/gcc/lto/ChangeLog
branches/gcc-4_5-branch/gcc/lto/lto-elf.c


-- 


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

[Bug tree-optimization/45506] [4.6 Regression] tree_mem_ref_addr, at tree-ssa-address.c:278

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2010-09-03 09:51 ---
Fixed by rev. 163802.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug debug/45500] ICE: in rtl_for_decl_init, at dwarf2out.c:16307 with -g -msse and using v16qi

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2010-09-03 09:54 ---
Subject: Bug 45500

Author: jakub
Date: Fri Sep  3 09:53:44 2010
New Revision: 163803

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163803
Log:
PR debug/45500
* dwarf2out.c (rtl_for_decl_init): Give up for all generic vectors,
not just generic vectors with BLKmode.

* gcc.target/i386/pr45500.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr45500.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c/45512] null pointer dereference in gcc

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2010-09-03 09:56 ---
Can't reproduce this.  Can you re-check with a more recent version?


-- 


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

[Bug fortran/45516] New: [F08] allocatable compontents of recursive type

[janus at gcc dot gnu dot org]

John Reid, The new features of Fortran 2008, chapter 5.3:

A recursive type is permitted to be based on allocatable components. Here is a
simple example of a type that holds a stack:

type entry
  real :: value
  integer :: index
  type(entry), allocatable :: next
end type entry

[...]

For this gfortran currently gives:

  type(entry), allocatable :: next
  1
Error: Component at (1) must have the POINTER attribute


-- 
   Summary: [F08] allocatable compontents of recursive type
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janus at gcc dot gnu dot org
OtherBugsDependingO 39627
 nThis:


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

[Bug fortran/45516] [F08] allocatable compontents of recursive type

[janus at gcc dot gnu dot org]

--- Comment #1 from janus at gcc dot gnu dot org  2010-09-03 09:59 ---
Here is a patch to accept the type declaration in comment #0:

Index: decl.c
===
--- decl.c  (revision 163798)
+++ decl.c  (working copy)
@@ -1494,11 +1494,11 @@ build_struct (const char *name, gfc_charlen *cl, g
   gfc_component *c;
   gfc_try t = SUCCESS;

-  /* F03:C438/C439. If the current symbol is of the same derived type that
we're
- constructing, it must have the pointer attribute.  */
+  /* F08:C440. If the current symbol is of the same derived type that we're
+ constructing, it must be POINTER or ALLOCATABLE.  */
   if ((current_ts.type == BT_DERIVED || current_ts.type == BT_CLASS)
   && current_ts.u.derived == gfc_current_block ()
-  && current_attr.pointer == 0)
+  && !current_attr.pointer && !current_attr.allocatable)
 {
   gfc_error ("Component at %C must have the POINTER attribute");
   return FAILURE;


-- 


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

[Bug debug/45500] ICE: in rtl_for_decl_init, at dwarf2out.c:16307 with -g -msse and using v16qi

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2010-09-03 10:15 ---
Subject: Bug 45500

Author: jakub
Date: Fri Sep  3 10:14:43 2010
New Revision: 163807

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163807
Log:
PR debug/45500
* dwarf2out.c (rtl_for_decl_init): Give up for all generic vectors,
not just generic vectors with BLKmode.

* gcc.target/i386/pr45500.c: New test.

Added:
branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/pr45500.c
Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/dwarf2out.c
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/45507] [4.6 Regression] Bogus Error: Can't convert TYPE(c_ptr) to INTEGER(4)

[janus at gcc dot gnu dot org]

--- Comment #4 from janus at gcc dot gnu dot org  2010-09-03 10:29 ---
Mine.


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |janus at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2010-09-02 19:45:28 |2010-09-03 10:29:14
   date||


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

[Bug target/45511] ICE in neon_valid_immediate, at config/arm/arm.c:8294

[ramana at gcc dot gnu dot org]

--- Comment #2 from ramana at gcc dot gnu dot org  2010-09-03 10:43 ---
I don't see this with an arm-linux-gnu toolchain for r163798.


-- 

ramana at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug c++/45510] Bug with anonymous unions and bit-fields

[paolo dot carlini at oracle dot com]

--- Comment #8 from paolo dot carlini at oracle dot com  2010-09-03 10:46 
---
If you look at the actual Standard, both alignment and allocation of bit-fields
are implementation defined. Thus, as far as I can see, at best we are talking
about non-portable implementation defined behavior. If you want my advice, try
to stay away from those tricks, with and without anonymous struct.


-- 


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

[Bug debug/45500] ICE: in rtl_for_decl_init, at dwarf2out.c:16307 with -g -msse and using v16qi

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2010-09-03 10:50 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug debug/45517] New: ICE in output_die

[jakub at gcc dot gnu dot org]

GCC 4.[1234] ICE in output_die on:
// { dg-do compile }
// { dg-options "-g" }

struct S
{
  virtual ~S () {}
};

void
foo ()
{
  struct T
  {
T () {}
void bar ()
{
  struct U : public S
  {
T t;
U () : t () {}
  };
}
  } t;
}

4.5/trunk works.


-- 
   Summary: ICE in output_die
   Product: gcc
   Version: 4.4.4
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org


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

[Bug ada/45499] Ada bootstrap broken

[joseph at codesourcery dot com]

--- Comment #6 from joseph at codesourcery dot com  2010-09-03 11:17 ---
Subject: Re:  Ada bootstrap broken

On Fri, 3 Sep 2010, hjl dot tools at gmail dot com wrote:

> (In reply to comment #3)
> > Subject: Re:  Ada bootstrap broken
> > 
> > I don't see where a -Y option would come from or what would accept it.
> 
> Y can be any letter from A to Z and a to z. See PR 45504 for an example.

But the changes to canonical options (to preferentially use separate 
arguments) only affect options marked with both Joined and Separate in a 
.opt file.

My understanding is that cc1_options is not used for Ada and so the only 
specs relevant to passing things to gnat1 are those in 
gcc-interface/lang-specs.h so this should only ever affect -I.


-- 


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

[Bug tree-optimization/45427] Number of iteration analysis bogus

[rguenth at gcc dot gnu dot org]

--- Comment #15 from rguenth at gcc dot gnu dot org  2010-09-03 11:32 
---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug ada/45499] Ada bootstrap broken

[joseph at codesourcery dot com]

--- Comment #7 from joseph at codesourcery dot com  2010-09-03 11:38 ---
Subject: Re:  Ada bootstrap broken

On Fri, 3 Sep 2010, jakub at gcc dot gnu dot org wrote:

> I think for -D and -U at least the canonicalization should be joined instead 
> of
> separate, because that's how people are used to write these options (which
> doesn't mean the tools the driver invokes shouldn't be changed to handle 
> both).
> And for -I- similarly.

The canonicalization is an internal convention, except where GCC is 
passing options directly to tools not included in GCC such as the linker.  
I chose separate as the preferred canonicalization on the basis of POSIX 
generally only having the separate forms of operands.

It looks like the issue is not in fact how the driver passes -I options to 
gnat1 but how gnat1 internally reconstitutes an argv array from decoded 
options for use by the Ada parts of gnat1 that expect such an array.  So 
I'm testing a patch local to the ada/gcc-interface code that only adjusts 
that reconstitution, only for -I.


-- 


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

[Bug fortran/45516] [F08] allocatable compontents of recursive type

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2010-09-03 12:12 ---
(In reply to comment #1)
> Here is a patch to accept the type declaration in comment #0:

Well, you at least need to use gfc_notify_std(GFC_STD_F2008, ... And one should
make sure that the allocation/clean up works as expected.

 * * *

As follow up to the initial implementation, one should implement at some point
the following, which does not do a deep copy but simply appends the old data.
(Example from the mentioned article.)

type entry
  real :: value
  integer :: index
  type(entry), allocatable :: next
end type entry

type (entry), allocatable :: top
top = entry ( new_value, new_index, top )

(The last line assume reallocate on assignment; I think it already works for
derived types with structure constructor; I know that it does not yet work for
intrinsic types - not does it work on other assignment than structure
constructors.)

The classical way to append a new item is the following, which should avoid a
deep copy (check!):

  type (entry), allocatable :: top, temp
  temp = entry ( new_value, new_index, temp )
  call move_alloc(top,temp%next)
  call move_alloc(temp,top)


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||domob at gcc dot gnu dot
   ||org, burnus at gcc dot gnu
   ||dot org


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

[Bug lto/44812] m32 lto produces non-relocatable subtraction expression errors

[hubicka at gcc dot gnu dot org]

--- Comment #32 from hubicka at gcc dot gnu dot org  2010-09-03 12:26 
---
Subject: Bug 44812

Author: hubicka
Date: Fri Sep  3 12:26:24 2010
New Revision: 163811

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

PR lto/44812
* lto-cgraph.c (intput_node, input_varpool_node): Set DECL_EXTERNAL
on functions/variables in other partition.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/lto-cgraph.c


-- 


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

[Bug c/45502] Passing multi-dimensional array to function using C99 VLA function parameter format fails if function is inlined

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2010-09-03 12:55 ---
A fix will appear in the repositories beyond
http://download.opensuse.org/repositories/devel:/gcc/


-- 


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

[Bug target/45511] ICE in neon_valid_immediate, at config/arm/arm.c:8294

[rmansfield at qnx dot com]

--- Comment #3 from rmansfield at qnx dot com  2010-09-03 13:02 ---
I can still reproduce it with r163811.


-- 


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

[Bug bootstrap/45518] New: [4.6 regression] bootstrap failure on sparc64-unknown-linux-gnu

[froydnj at gcc dot gnu dot org]

I'm seeing a bootstrap failure on the compile farm's gcc63 machine.  I realize
there've been several logs submitted to gcc-testresults from Laurent's
autotesters, but those testers configured with somewhat different options than
I did.  I'm configuring with:

--disable-lib{ssp,mudflap,gomp} --enable-languages=c --disable-nls
--enable-threads=posix

whereas Laurent passes --with-cpu=v8 and --disable-multilib.

Bootstrapping fails starting at r163383, Bernd's 4-insn combine change, when
configuring support libraries (libiberty, zlib, libdecnumber) for stage3.  I
double-checked subsequent revisions that fix other PRs from r163383 (e.g.
r163546) and those did not help either.  I tried --disable-multilib and/or
--with-cpu=niagara and that did not help.

I'm unsure of what other information to provide, but can provide more
information on request.


-- 
   Summary: [4.6 regression] bootstrap failure on sparc64-unknown-
linux-gnu
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: froydnj at gcc dot gnu dot org
 GCC build triplet: sparc64-unknown-linux-gnu
  GCC host triplet: sparc64-unknown-linux-gnu
GCC target triplet: sparc64-unknown-linux-gnu


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

[Bug c/42884] GCC (v4.3.3) fails to detect uninitialized variable

[thutt at vmware dot com]

--- Comment #21 from thutt at vmware dot com  2010-09-03 13:07 ---
(In reply to comment #8)
> Is 'coverity' a compiler? I don't think so.
> 

Coverity is not a tool that generates code, but it does perform
all the syntactic & semantic analysis that a code-generating compiler will.
Then, it goes beyond that with further static analysis.

> Do you have actual examples of
> *compilers* which, everything taken into account, decided to make sure this
> case is worth warning?

That's the worst argument I've read in a long time.
Do we need proof that another compiler does something before the gcc 
team will take it up now?


-- 


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

[Bug fortran/34162] F2008: Allow internal procedures as actual argument

[domob at gcc dot gnu dot org]

--- Comment #3 from domob at gcc dot gnu dot org  2010-09-03 13:11 ---
Subject: Bug 34162

Author: domob
Date: Fri Sep  3 13:10:40 2010
New Revision: 163813

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163813
Log:
2010-09-03  Daniel Kraft  

PR fortran/34162
* resolve.c (resolve_actual_arglist): Allow internal procedure
as actual argument with Fortran 2008.

2010-09-03  Daniel Kraft  

PR fortran/34162
* gfortran.dg/internal_dummy_1.f90: Add -std=f2003.
* gfortran.dg/internal_dummy_2.f08: New test.
* gfortran.dg/internal_dummy_3.f08: New test.
* gfortran.dg/internal_dummy_4.f08: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/internal_dummy_2.f08
trunk/gcc/testsuite/gfortran.dg/internal_dummy_3.f08
trunk/gcc/testsuite/gfortran.dg/internal_dummy_4.f08
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/internal_dummy_1.f90


-- 


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

[Bug fortran/34162] F2008: Allow internal procedures as actual argument

[domob at gcc dot gnu dot org]

--- Comment #4 from domob at gcc dot gnu dot org  2010-09-03 13:11 ---
Fixed.


-- 

domob at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug java/45504] [4.6 Regression] Failed to bootstrap

[hjl at gcc dot gnu dot org]

--- Comment #6 from hjl at gcc dot gnu dot org  2010-09-03 13:13 ---
Subject: Bug 45504

Author: hjl
Date: Fri Sep  3 13:13:10 2010
New Revision: 163814

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163814
Log:
Check "-D XXX=YYY".

2010-09-03  H.J. Lu  

PR java/45504
* jvgenmain.c (main): Check "-D XXX=YYY".

Modified:
trunk/gcc/java/ChangeLog
trunk/gcc/java/jvgenmain.c


-- 


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

[Bug ada/45499] Ada bootstrap broken

[jsm28 at gcc dot gnu dot org]

--- Comment #8 from jsm28 at gcc dot gnu dot org  2010-09-03 13:18 ---
Subject: Bug 45499

Author: jsm28
Date: Fri Sep  3 13:17:46 2010
New Revision: 163817

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163817
Log:
PR ada/45499
* gcc-interface/misc.c (gnat_init_options): Allow options with
empty canonical form.  Generate a single save_argv element from -I
options.

Modified:
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/gcc-interface/misc.c


-- 


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

[Bug bootstrap/45519] New: [4.6 regression] Failed to bootstrap

[hjl dot tools at gmail dot com]

On Linux/x86, revision 163804 gave:

/home/regress/tbox/svn-gcc/libgcc/../gcc/unwind-dw2-fde-glibc.c: In function
'_Unwind_IteratePhdrCallback':
/home/regress/tbox/svn-gcc/libgcc/../gcc/unwind-dw2-fde-glibc.c:134:1: error:
Invalid first operand of MEM_REF.
D.10501_117
/home/regress/tbox/svn-gcc/libgcc/../gcc/unwind-dw2-fde-glibc.c:134:1: note: in
statement
D.11538_238 = &MEM[(struct Elf32_Dyn *)D.10501_117 + 8B];

/home/regress/tbox/svn-gcc/libgcc/../gcc/unwind-dw2-fde-glibc.c:134:1: internal
compiler error: verify_stmts failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[3]: *** [unwind-dw2-fde-glibc.o] Error 1
make[3]: *** Waiting for unfinished jobs
make[3]: Leaving directory
`/home/regress/tbox/native/build/i686-pc-linux-gnu/libgcc'
make[2]: *** [all-stage1-target-libgcc] Error 2
make[2]: Leaving directory `/home/regress/tbox/native/build'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/home/regress/tbox/native/build'
make: *** [bootstrap] Error 2

Revision 163799 is OK. It may be caused by revision 163802:

http://gcc.gnu.org/ml/gcc-cvs/2010-09/msg00093.html


-- 
   Summary: [4.6 regression] Failed to bootstrap
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com


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

[Bug bootstrap/45519] [4.6 regression] Failed to bootstrap

[hjl dot tools at gmail dot com]

-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0


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

[Bug ada/45499] Ada bootstrap broken

[jsm28 at gcc dot gnu dot org]

--- Comment #9 from jsm28 at gcc dot gnu dot org  2010-09-03 13:21 ---
Fixed for 4.6.


-- 

jsm28 at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug bootstrap/45519] [4.6 regression] Failed to bootstrap

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2010-09-03 13:22 ---
Can you attach preprocessed source that allows reproducing on x86_64?  Thx.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-09-03 13:22:15
   date||


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

[Bug bootstrap/45518] [4.6 regression] bootstrap failure on sparc64-unknown-linux-gnu

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2010-09-03 13:27 ---
How does it fail?


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0


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

[Bug bootstrap/45519] [4.6 regression] Failed to bootstrap

[hjl dot tools at gmail dot com]

--- Comment #2 from hjl dot tools at gmail dot com  2010-09-03 13:31 ---
[...@gnu-1 gcc]$ ./xgcc -B./ -m32 -O2 -S /tmp/pr45519.i
../../../src-trunk/libgcc/../gcc/unwind-dw2-fde-glibc.c: In function
\u2018_Unwind_IteratePhdrCallback\u2019:
../../../src-trunk/libgcc/../gcc/unwind-dw2-fde-glibc.c:134:1: error: Invalid
first operand of MEM_REF.
D.11075_117
../../../src-trunk/libgcc/../gcc/unwind-dw2-fde-glibc.c:134:1: note: in
statement
D.12093_230 = &MEM[(struct Elf32_Dyn *)D.11075_117 + 8B];

../../../src-trunk/libgcc/../gcc/unwind-dw2-fde-glibc.c:134:1: internal
compiler error: verify_stmts failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 


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

[Bug bootstrap/45519] [4.6 regression] Failed to bootstrap

[hjl dot tools at gmail dot com]

--- Comment #3 from hjl dot tools at gmail dot com  2010-09-03 13:32 ---
Created an attachment (id=21682)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21682&action=view)
A testcase

[...@gnu-1 gcc]$ ./xgcc -B./ -m32 -O2 -S /tmp/pr45519.i
../../../src-trunk/libgcc/../gcc/unwind-dw2-fde-glibc.c: In function
\u2018_Unwind_IteratePhdrCallback\u2019:
../../../src-trunk/libgcc/../gcc/unwind-dw2-fde-glibc.c:134:1: error: Invalid
first operand of MEM_REF.
D.11075_117
../../../src-trunk/libgcc/../gcc/unwind-dw2-fde-glibc.c:134:1: note: in
statement
D.12093_230 = &MEM[(struct Elf32_Dyn *)D.11075_117 + 8B];

../../../src-trunk/libgcc/../gcc/unwind-dw2-fde-glibc.c:134:1: internal
compiler error: verify_stmts failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 


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

[Bug bootstrap/45518] [4.6 regression] bootstrap failure on sparc64-unknown-linux-gnu

[froydnj at codesourcery dot com]

--- Comment #2 from froydnj at codesourcery dot com  2010-09-03 13:34 
---
Subject: Re:  [4.6 regression] bootstrap failure on
sparc64-unknown-linux-gnu

configure says:

checking for C compiler default output file name... a.out
checking whether the C compiler works... configure: error: in
home/froydnj/build-mainline/intl':
configure: error: cannot run C compiled programs.

The compiled program for:

int
main (void)
{
  return 0;
}

segfaults.  gdb says:

(gdb) run
Starting program: /home/froydnj/build-mainline/intl/a.out 

Program received signal SIGSEGV, Segmentation fault.
0x0010059c in __do_global_ctors_aux ()
Current language:  auto
The current source language is "auto; currently asm".
(gdb) where
#0  0x0010059c in __do_global_ctors_aux ()
#1  0x001003b0 in _init ()
#2  0x00100518 in __libc_csu_init ()
#3  0xf80100157fd0 in __libc_start_main () from /lib64/libc.so.6
#4  0x001003f4 in _start ()
(gdb)


-- 


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

[Bug bootstrap/45519] [4.6 regression] Failed to bootstrap

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2010-09-03 13:43 ---
Reduced testcase:

typedef struct { unsigned int p_vaddr; } Elf32_Phdr;
typedef struct { int d_tag; } Elf32_Dyn;
typedef unsigned _Unwind_Ptr __attribute__((__mode__(__pointer__)));
int
_Unwind_IteratePhdrCallback (const Elf32_Phdr *p_dynamic,
 _Unwind_Ptr load_base)
{
  Elf32_Dyn *dyn = (Elf32_Dyn *)  ((p_dynamic->p_vaddr) + (load_base));
  for (; dyn->d_tag != 0 ; dyn++)  
if (dyn->d_tag == 3)
  return 0;
  return 1;
}
pr45519.3.i: In function '_Unwind_IteratePhdrCallback':
pr45519.3.i:11:1: error: Invalid first operand of MEM_REF.
D.2729_7
pr45519.3.i:11:1: note: in statement
D.2745_1 = &MEM[(struct Elf32_Dyn *)D.2729_7 + 4B];

pr45519.3.i:11:1: internal compiler error: verify_stmts failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


Other reduced testcase:

typedef struct { unsigned int p_vaddr; } Elf32_Phdr;
typedef struct { int d_tag; } Elf32_Dyn;
int
_Unwind_IteratePhdrCallback (const Elf32_Phdr *p_dynamic,
 unsigned int load_base)
{
  Elf32_Dyn *dyn = (Elf32_Dyn *)  ((p_dynamic->p_vaddr) + (load_base));
  for (; dyn->d_tag != 0 ; dyn++)  
if (dyn->d_tag == 3)
  return 0;
  return 1;
}
pr45519.3.i:4:1: internal compiler error: in build2_stat, at tree.c:3724
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 


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

[Bug c/42884] GCC (v4.3.3) fails to detect uninitialized variable

[manu at gcc dot gnu dot org]

--- Comment #22 from manu at gcc dot gnu dot org  2010-09-03 14:06 ---
(In reply to comment #21)
> (In reply to comment #8)
> > Is 'coverity' a compiler? I don't think so.
> > 
> 
> Coverity is not a tool that generates code, but it does perform
> all the syntactic & semantic analysis that a code-generating compiler will.
> Then, it goes beyond that with further static analysis.

GCC is not designed to be used as a static analysis tool. This doesn't mean it
wouldn't be interesting to be able to reuse GCC analysis modules for doing
that. Other compilers have shown that it is possible and a desirable feature
[*]. However, GCC is not designed to be reusable, there is none working on a
similar thing for GCC, and no sign that any existing GCC developer will start
working on it in the near future. Unless someone new starts working on this,
don't expect anything similar from GCC.

[*] http://clang-analyzer.llvm.org/

> > Do you have actual examples of
> > *compilers* which, everything taken into account, decided to make sure this
> > case is worth warning?
> 
> That's the worst argument I've read in a long time.
> Do we need proof that another compiler does something before the gcc 
> team will take it up now?

There is more work to do in GCC than people willing (or being paid) to do it,
so if there is some indication that some feature may be impossible or too
expensive to implement, existing GCC developers will probably focus their
efforts on something else more feasible. If you can show that another compiler
is able to do it in an efficient way, that shows that it is feasible. As far as
I know, GCC has always been a very conservative compiler in terms of features,
not a source of innovation. So yes, showing a working implementation seems to
be a necessary condition (but not a sufficient one).

In fact, it is common practice to check what other compilers do in order to
verify a bug, and it is useful information in bug reports.

I am sorry for this flamewar. I hope I clarified all the issues and the wiki
[**] contains a more detailed discussion about the technical issues related to
uninitialized warnings in case anyone is willing to help to solve them.

[**] http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings


-- 


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

[Bug c/45512] null pointer dereference in gcc

[regehr at cs dot utah dot edu]

--- Comment #2 from regehr at cs dot utah dot edu  2010-09-03 14:20 ---
No crash from r163817, thanks!


-- 

regehr at cs dot utah dot edu changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME


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

[Bug bootstrap/45519] [4.6 regression] Failed to bootstrap

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2010-09-03 14:21 ---
Hmhm, IVOPTs expands crap into arguments.

Index: gcc/tree-ssa-loop-ivopts.c
===
--- gcc/tree-ssa-loop-ivopts.c  (revision 163817)
+++ gcc/tree-ssa-loop-ivopts.c  (working copy)
@@ -1023,6 +1023,11 @@ find_bivs (struct ivopts_data *data)

   type = TREE_TYPE (PHI_RESULT (phi));
   base = fold_convert (type, base);
+  STRIP_USELESS_TYPE_CONVERSION (base);
+  if (CONVERT_EXPR_P (base)
+ && (POINTER_TYPE_P (TREE_TYPE (base))
+ != POINTER_TYPE_P (TREE_OPERAND (base, 0
+   continue;
   if (step)
{
  if (POINTER_TYPE_P (type))


fixes the testcase, I am bootstrapping and testing this on x86_64 as a
short-term fix but have to think about it some more.

Can you check if 32bit bootstrap succeeds with that?


-- 


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

[Bug target/45476] libgcc should contain TCmode functions

[uros at gcc dot gnu dot org]

--- Comment #9 from uros at gcc dot gnu dot org  2010-09-03 14:23 ---
Subject: Bug 45476

Author: uros
Date: Fri Sep  3 14:23:05 2010
New Revision: 163819

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163819
Log:
libgcc/ChangeLog:

PR target/45476
* Makefile.in (sifuncs, difuncs, tifuncs): Filter out
LIB2FUNCS_EXCLUDE functions.

gcc/ChangeLog:

PR target/45476
* config/i386/t-darwin (LIB2FUNCS_EXCLUDE): New.
* config/i386/darwin.h (LIBGCC2_HAS_TF_MODE,
LIBGCC2_TF_CEXT, TF_SIZE): New defines.

gcc/testsuite/ChangeLog:

PR target/45476
* gcc.target/i386/float128-1.c: Enable for all x86 targets.
* gcc.target/i386/float128-2.c: Ditto.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/darwin.h
trunk/gcc/config/i386/t-darwin
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/float128-1.c
trunk/gcc/testsuite/gcc.target/i386/float128-2.c
trunk/libgcc/ChangeLog
trunk/libgcc/Makefile.in


-- 


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

[Bug bootstrap/45519] [4.6 regression] Failed to bootstrap

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2010-09-03 14:33 ---
Created an attachment (id=21683)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21683&action=view)
alternate fix


-- 


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

[Bug tree-optimization/45506] [4.6 Regression] tree_mem_ref_addr, at tree-ssa-address.c:278

[hjl at gcc dot gnu dot org]

--- Comment #5 from hjl at gcc dot gnu dot org  2010-09-03 14:41 ---
Subject: Bug 45506

Author: hjl
Date: Fri Sep  3 14:40:36 2010
New Revision: 163821

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163821
Log:
Add gcc.dg/pr45506.c.

2010-09-03  H.J. Lu  

PR tree-optimization/45506
* gcc.dg/pr45506.c: New.

Added:
trunk/gcc/testsuite/gcc.dg/pr45506.c
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/45520] New: Regression: compiler segmentation fault on decltype from a dereferenced map iterator

[qduaty at gmail dot com]

The compiler says: main.cc:7:35: internal compiler error: Segmentation fault
The map must be a class member to reproduce the bug. 
If the decltype is not in a lambda, but a method argument, a different message
appears:
main.cc:6:32: internal compiler error: in tree_low_cst, at tree.c:6328
This code compiled correctly with g++ 4.5.0.

File content:
#include 

struct S {
std::map < void*, int> Map;

void f() {
auto lambda=[&](decltype(*Map.begin()) & i) { };
}

};


-- 
   Summary: Regression: compiler segmentation fault on decltype from
a dereferenced map iterator
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: qduaty at gmail dot com
  GCC host triplet: i686-pc-linux-gnu


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

[Bug middle-end/45415] [4.6 Regression] ICE in partition_view_bitmap, at tree-ssa-live.c:334

[matz at gcc dot gnu dot org]

--- Comment #4 from matz at gcc dot gnu dot org  2010-09-03 14:43 ---
Subject: Bug 45415

Author: matz
Date: Fri Sep  3 14:42:46 2010
New Revision: 163822

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163822
Log:
PR middle-end/45415
* tree-sra.c (sra_modify_assign): If we modify the statement,
say so.

* tree-ssa.c (verify_ssa): Check number of operands and links
per statement to agree.

testsuite/
PR middle-end/45415
* gcc.dg/pr45415.c: New test.

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


-- 


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

[Bug c++/45520] [C++0x] Regression: compiler segmentation fault on decltype from a dereferenced map iterator

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2010-09-03 14:44 
---
Let's ask Jason to have a look.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||jason at gcc dot gnu dot org
Summary|Regression: compiler|[C++0x] Regression: compiler
   |segmentation fault on   |segmentation fault on
   |decltype from a dereferenced|decltype from a dereferenced
   |map iterator|map iterator


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

[Bug c++/45510] Bug with anonymous unions and bit-fields

[runipg at broadcom dot com]

--- Comment #9 from runipg at broadcom dot com  2010-09-03 14:45 ---
Subject: Re:  Bug with anonymous unions and bit-fields

Thank you so much. You can close this bug if you wish.


-Runip

On 03-Sep-2010, at 3:47 AM, paolo dot carlini at oracle dot com
 wrote:

> 
> 
> --- Comment #8 from paolo dot carlini at oracle dot com  2010-09-03 10:46 
> ---
> If you look at the actual Standard, both alignment and allocation of 
> bit-fields
> are implementation defined. Thus, as far as I can see, at best we are talking
> about non-portable implementation defined behavior. If you want my advice, try
> to stay away from those tricks, with and without anonymous struct.
> 
> 
> -- 
> 
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45510
> 
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter.
> 


-- 


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

[Bug middle-end/45415] [4.6 Regression] ICE in partition_view_bitmap, at tree-ssa-live.c:334

[matz at gcc dot gnu dot org]

--- Comment #5 from matz at gcc dot gnu dot org  2010-09-03 14:46 ---
Fixed.


-- 

matz at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/45484] Invalid memory access in gcc.c-torture/execute/builtins/sprintf-chk.c

[jakub at gcc dot gnu dot org]

--- Comment #23 from jakub at gcc dot gnu dot org  2010-09-03 14:47 ---
Subject: Bug 45484

Author: jakub
Date: Fri Sep  3 14:46:39 2010
New Revision: 163823

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163823
Log:
PR middle-end/45484
* dwarf2out.c (flush_queued_reg_saves): Rename to...
(dwarf2out_flush_queued_reg_saves): ... this.  No longer static.
(dwarf2out_frame_debug_expr, dwarf2out_frame_debug): Adjust callers.
* dwarf2out.h (dwarf2out_flush_queued_reg_saves): New prototype.
* config/i386/i386.c (output_set_got): Call it.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/dwarf2out.c
trunk/gcc/dwarf2out.h


-- 


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

[Bug middle-end/45484] Invalid memory access in gcc.c-torture/execute/builtins/sprintf-chk.c

[jakub at gcc dot gnu dot org]

--- Comment #24 from jakub at gcc dot gnu dot org  2010-09-03 14:50 ---
Subject: Bug 45484

Author: jakub
Date: Fri Sep  3 14:50:20 2010
New Revision: 163824

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163824
Log:
PR middle-end/45484
* dwarf2out.c (flush_queued_reg_saves): Rename to...
(dwarf2out_flush_queued_reg_saves): ... this.  No longer static.
(dwarf2out_frame_debug): Adjust callers.
* dwarf2out.h (dwarf2out_flush_queued_reg_saves): New prototype.
* config/i386/i386.c (output_set_got): Call it.

Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/config/i386/i386.c
branches/gcc-4_5-branch/gcc/dwarf2out.c
branches/gcc-4_5-branch/gcc/dwarf2out.h


-- 


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

[Bug bootstrap/45519] [4.6 regression] Failed to bootstrap

[hjl dot tools at gmail dot com]

--- Comment #7 from hjl dot tools at gmail dot com  2010-09-03 14:52 ---
(In reply to comment #6)
> Created an attachment (id=21683)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21683&action=view) [edit]
> alternate fix
> 

Doesn't work on Linux/x86. I got

/export/gnu/import/git/gcc/libgcc/../gcc/libgcov.c: In function
\u2018__gcov_merge_single\u2019:
/export/gnu/import/git/gcc/libgcc/../gcc/libgcov.c:636:1: internal compiler
error: in fold_binary_loc, at fold-const.c:9411
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[4]: *** [_gcov_merge_single.o] Error 1


-- 


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

[Bug fortran/45521] New: Fortran 2008: GENERIC resolution with ALLOCATABLE/POINTER and PROCEDURE

[burnus at gcc dot gnu dot org]

As the introduction of Fortran 2008 mentions:
- ALLOCATABLE and POINTER attributes are used in generic resolution.
- Procedureness of a dummy argument is used in generic resolution.

Or as "The new features of Fortran 2008" puts it:
"A pair of specific procedures in a generic interface are permitted to be
distinguishable by virtue of a pointer argument without intent in of one
corresponding to an allocatable argument of the other or a data argument of one
corresponding to a procedure argument of the other."


Fortran 2008's "12.4.3.4.5 Restrictions on generic declarations" has"

"Two dummy arguments are distinguishable if
- one is a procedure and the other is a data object,
- they are both data objects or known to be functions, and neither is TKR
compatible with the other,
- one has the ALLOCATABLE attribute and the other has the POINTER attribute, or
- one is a function with nonzero rank and the other is not known to be a
function."

Interpretation request F08/0001 / 10-145 changes this ("EDITS to 10-007")"

'[286:4] In 12.4.3.4.5p3, after "the other has the POINTER attribute",
Insert "and not the INTENT(IN) attribute".'
Cf. http://j3-fortran.org/doc/meeting/193/10-199.txt

Fortran 2003 just had ("16.2.3 Restrictions on generic declarations"):

"Two dummy arguments are distinguishable if neither is a subroutine and neither
is TKR compatible (5.1.1.2) with the other."


-- 
   Summary: Fortran 2008: GENERIC resolution with
ALLOCATABLE/POINTER and PROCEDURE
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
OtherBugsDependingO 39627
 nThis:


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

[Bug libstdc++/45347] concurrence.h: In constructor '__gnu_cxx::__cond::__cond()': /home/jayk/obj/gcc451/alphaev67-dec-osf5.1/libstdc++-v3/include/ext/concurrence.h:276:29: warning: missing initialize

[paolo dot carlini at oracle dot com]

--- Comment #4 from paolo dot carlini at oracle dot com  2010-09-03 15:05 
---
Thus, Jon, are we just missing a #pragma GCC system_header at the beginning of
that file? In case, just add it and close the PR?


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||jwakely dot gcc at gmail dot
   ||com


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

[Bug bootstrap/45519] [4.6 regression] Failed to bootstrap

[hjl dot tools at gmail dot com]

--- Comment #8 from hjl dot tools at gmail dot com  2010-09-03 15:37 ---
(In reply to comment #5)
> Hmhm, IVOPTs expands crap into arguments.
> 
> Index: gcc/tree-ssa-loop-ivopts.c
> ===
> --- gcc/tree-ssa-loop-ivopts.c  (revision 163817)
> +++ gcc/tree-ssa-loop-ivopts.c  (working copy)
> @@ -1023,6 +1023,11 @@ find_bivs (struct ivopts_data *data)
> 
>type = TREE_TYPE (PHI_RESULT (phi));
>base = fold_convert (type, base);
> +  STRIP_USELESS_TYPE_CONVERSION (base);
> +  if (CONVERT_EXPR_P (base)
> + && (POINTER_TYPE_P (TREE_TYPE (base))
> + != POINTER_TYPE_P (TREE_OPERAND (base, 0
> +   continue;
>if (step)
> {
>   if (POINTER_TYPE_P (type))
> 
> 
> fixes the testcase, I am bootstrapping and testing this on x86_64 as a
> short-term fix but have to think about it some more.
> 
> Can you check if 32bit bootstrap succeeds with that?
> 

I can bootstrap C with this one on Linux/x86.


-- 


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

[Bug debug/41063] ICE in output_die

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2010-09-03 15:44 ---
*** Bug 45517 has been marked as a duplicate of this bug. ***


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu dot org


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

[Bug debug/45517] ICE in output_die

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2010-09-03 15:44 ---


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


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug tree-optimization/45522] New: VRP misses oppurtunity for statement folding.

[hubicka at gcc dot gnu dot org]

Hi,
compiling the attached testcase (reduced from tree.c) with -O2 leads to vrp
folding:
  if (D.2762_2 == 6)
goto ;
  else
goto ;

:
  D.2766_5 = (int) D.2762_2;
  D.2767_6 = tree_code_type[D.2766_5];

into
  D.2762_2 = type_1(D)->base.code;
  if (D.2762_2 == 6)
goto ;
  else
goto ;

:
  D.2766_5 = 6;
  D.2767_6 = tree_code_type[6];

this is good transform, however tree_code_type is constant initialized array
and we miss possibility to fold it into constant until expansion triggering
code in expr.c I would like to retire.

We can fold tree_code_type[6], so apparently just no one calls fold_gimple_stmt
on it?


-- 
   Summary: VRP misses oppurtunity for statement folding.
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hubicka at gcc dot gnu dot org


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

[Bug tree-optimization/45522] VRP misses oppurtunity for statement folding.

[hubicka at gcc dot gnu dot org]

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


-- 


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

[Bug testsuite/42843] --enable-build-with-cxx plugin tests fail

[ro at gcc dot gnu dot org]

--- Comment #24 from ro at gcc dot gnu dot org  2010-09-03 16:03 ---
Subject: Bug 42843

Author: ro
Date: Fri Sep  3 16:02:37 2010
New Revision: 163833

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163833
Log:
PR testsuite/42843
* Makefile.in (PLUGINCC): Define in terms of @CC@ / @CXX@
(PLUGINCFLAGS): Define in terms of @CFLAGS@ / @CXXFLAGS@

Modified:
trunk/gcc/ChangeLog
trunk/gcc/Makefile.in


-- 


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

[Bug fortran/45159] Unnecessary temporaries

[tkoenig at gcc dot gnu dot org]

--- Comment #21 from tkoenig at gcc dot gnu dot org  2010-09-03 16:17 
---
Subject: Bug 45159

Author: tkoenig
Date: Fri Sep  3 16:16:34 2010
New Revision: 163834

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163834
Log:
2010-09-03  Thomas Koenig  

PR fortran/45159
* dependency.c (gfc_deb_compare_expr):  Compare equal for equal
arglists for pure user functions, or for those intrinsic
functions which are also pure.
* intrinsics.c (add_conv):  Mark conversion functions as pure.
(add_char_conversions):  Likewise.

2010-09-03  Thomas Koenig  

PR fortran/45159
* gfortran.dg/dependency_34.f90:  New test.


Added:
trunk/gcc/testsuite/gfortran.dg/dependency_34.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/dependency.c
trunk/gcc/fortran/intrinsic.c
trunk/gcc/testsuite/ChangeLog


-- 


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

inlining bug gcc

[Pierre Innocent]

Bug Report:

Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.4-6' 
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs 
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared 
--enable-multiarch --enable-linker-build-id --with-system-zlib 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr 
--enable-targets=all --with-tune=generic --enable-checking=release 
--build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.3.4 (Debian 4.3.4-6) 


IInlining bug :

The value set within one inline function is reset to another value.
The value is checked by using another inline function within the set function

iinline void setFD(int32_t fd) {
                _fd = fd;
COUT_2 << "DescrInfo::setIntDescr IO=" << this << " FD=[ " << fd << ", " << _fd 
<< " ]\n";
COUT_2.flush();
                DescrInfo::fd();
// The value of _fd when accessed within fd() is equal to 0; it is correct 
within this inline function.
        }


Regards,
Pierre Innocent
babel...@yahoo.com
d...@tsert.com

[Bug tree-optimization/45522] VRP misses oppurtunity for statement folding.

[hubicka at gcc dot gnu dot org]

--- Comment #2 from hubicka at gcc dot gnu dot org  2010-09-03 16:33 ---
OK, the problem seems to be that fold_stmt seems to make no serious attempt to
fold constant references.  There is some code in maybe_fold_reference that
seems to partly duplicate fold_const_aggregate_ref however.  What is reason for
that?

The following patch solves the problem, I am looking what other testcases I can
find.


-- 


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

[Bug tree-optimization/45522] VRP misses oppurtunity for statement folding.

[hubicka at gcc dot gnu dot org]

--- Comment #3 from hubicka at gcc dot gnu dot org  2010-09-03 16:34 ---
Created an attachment (id=21685)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21685&action=view)
patch for better folding


-- 


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

[Bug bootstrap/45519] [4.6 regression] Failed to bootstrap

[hjl dot tools at gmail dot com]

--- Comment #9 from hjl dot tools at gmail dot com  2010-09-03 16:48 ---
It also failed on Linux/ia64 with similar error.


-- 


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

[Bug c++/45523] New: Failure to bind auto variable to function template instance

[jewillco at osl dot iu dot edu]

The following code:

template  void foo();
void f() {auto g = foo;}

fails to compile in GCC 4.5.0's C++0x mode with the following error:

foo.cpp: In function ‘void f()’:
foo.cpp:2:20: error: ‘g’ has incomplete type

Trying different variants of this code, it appears that GCC believes that
foo is an ambiguous overloaded function, while there is only one matching
function.


-- 
   Summary: Failure to bind auto variable to function template
instance
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jewillco at osl dot iu dot edu
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug c++/45523] Failure to bind auto variable to function template instance

[jewillco at osl dot iu dot edu]

--- Comment #1 from jewillco at osl dot iu dot edu  2010-09-03 17:08 ---
Created an attachment (id=21686)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21686&action=view)
File containing test case in error report


-- 


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

[Bug bootstrap/45519] [4.6 regression] Failed to bootstrap

[hjl dot tools at gmail dot com]

--- Comment #10 from hjl dot tools at gmail dot com  2010-09-03 17:09 
---
(In reply to comment #8)
> (In reply to comment #5)
> > Hmhm, IVOPTs expands crap into arguments.
> > 
> > Index: gcc/tree-ssa-loop-ivopts.c
> > ===
> > --- gcc/tree-ssa-loop-ivopts.c  (revision 163817)
> > +++ gcc/tree-ssa-loop-ivopts.c  (working copy)
> > @@ -1023,6 +1023,11 @@ find_bivs (struct ivopts_data *data)
> > 
> >type = TREE_TYPE (PHI_RESULT (phi));
> >base = fold_convert (type, base);
> > +  STRIP_USELESS_TYPE_CONVERSION (base);
> > +  if (CONVERT_EXPR_P (base)
> > + && (POINTER_TYPE_P (TREE_TYPE (base))
> > + != POINTER_TYPE_P (TREE_OPERAND (base, 0
> > +   continue;
> >if (step)
> > {
> >   if (POINTER_TYPE_P (type))
> > 
> > 
> > fixes the testcase, I am bootstrapping and testing this on x86_64 as a
> > short-term fix but have to think about it some more.
> > 
> > Can you check if 32bit bootstrap succeeds with that?
> > 
> 
> I can bootstrap C with this one on Linux/x86.
> 

With default languages, I got one regression:

Executing on host: /export/build/gnu/gcc-32bit/build-i686-linux/gcc/xgcc
-B/export/build/gnu/gcc-32bit/build-i686-linux/gcc/
/net/gnu-6/export/gnu/import/git/gcc/gcc/testsuite/gcc.target/i386/pr38240.c   
-ansi -pedantic-errors -S  -o pr38240.s(timeout = 300)
/net/gnu-6/export/gnu/import/git/gcc/gcc/testsuite/gcc.target/i386/pr38240.c:
In function 'g':^M
/net/gnu-6/export/gnu/import/git/gcc/gcc/testsuite/gcc.target/i386/pr38240.c:8:21:
internal compiler error: in convert_move, at expr.c:326^M
Please submit a full bug report,^M 
with preprocessed source if appropriate.^M
See  for instructions.^M
compiler exited with status 1

with revision 163817 plus the fix.


-- 


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

[Bug c++/45523] [C++0x] Failure to bind auto variable to function template instance

[paolo dot carlini at oracle dot com]

--- Comment #2 from paolo dot carlini at oracle dot com  2010-09-03 17:10 
---
Let's add Jason in CC about this one too.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||jason at gcc dot gnu dot org
Summary|Failure to bind auto|[C++0x] Failure to bind auto
   |variable to function|variable to function
   |template instance   |template instance


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

[Bug tree-optimization/45421] [4.6 regression] Ada bootstrap failure on IRIX 6.5: SIGBUS in sem_aggr.sort_case_table

[ro at CeBiTec dot Uni-Bielefeld dot DE]

--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld dot DE  2010-09-03 
17:23 ---
Subject: Re:  [4.6 regression] Ada bootstrap failure on IRIX 6.5: SIGBUS in
sem_aggr.sort_case_table

I'm now running an mips-sgi-irix6.5 bootstrap with Ada included with
this patch.

Thanks.
Rainer


-- 


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

[Bug target/45524] New: r163815/r163816 produces new regressions on x86_64-apple-darwin10

[howarth at nitro dot med dot uc dot edu]

The new commits...


Author: krebbel
Date: Fri Sep  3 13:14:14 2010
New Revision: 163815

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

2010-09-03  Andreas Krebbel  

* configure.ac: Use the GCC_AC_ENABLE_DECIMAL_FLOAT macro.
* Makefile.in: Add aclocal.m4 dependency to dfp.m4.
* configure: Regenerate.
* aclocal.m4: Regenerate.

config/

2010-09-03  Andreas Krebbel  

* dfp.m4: New file.

libdecnumber/

2010-09-03  Andreas Krebbel  

* configure.ac: Use the GCC_AC_ENABLE_DECIMAL_FLOAT macro.
* Makefile.in: Add aclocal.m4 dependency to dfp.m4.
* configure: Regenerate.
* aclocal.m4: Regenerate.

libgcc/

2010-09-03  Andreas Krebbel  

* configure.ac: Use the GCC_AC_ENABLE_DECIMAL_FLOAT macro.
Include dfp.m4.
* configure: Regenerate.

Author: krebbel
Date: Fri Sep  3 13:16:24 2010
New Revision: 163816

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

2010-09-03  Andreas Krebbel  

* configure: Regenerate.
* aclocal.m4: Regenerate.

libdecnumber/

2010-09-03  Andreas Krebbel  

* configure: Regenerate.
* aclocal.m4: Regenerate.

libgcc/

2010-09-03  Andreas Krebbel  

* configure: Regenerate.

produce new regressions at -m32/-m64 on x86_64-apple-darwin10 of...


FAIL: c-c++-common/dfp/func-vararg-mixed-2.c (test for excess errors)
WARNING: c-c++-common/dfp/func-vararg-mixed-2.c compilation failed to produce
executable
FAIL: c-c++-common/dfp/pr36800.c (test for excess errors)
WARNING: c-c++-common/dfp/pr36800.c compilation failed to produce executable
FAIL: c-c++-common/dfp/pr39034.c (test for excess errors)
WARNING: c-c++-common/dfp/pr39034.c compilation failed to produce executable
FAIL: c-c++-common/dfp/pr39035.c (test for excess errors)
WARNING: c-c++-common/dfp/pr39035.c compilation failed to produce executable
FAIL: gcc.target/i386/pr32065-2.c (test for excess errors)
WARNING: gcc.target/i386/pr32065-2.c compilation failed to produce executable

These are of the form...


Executing on host: /Users/howarth/darwin_objdir/gcc/xgcc
-B/Users/howarth/darwin_objdir/gcc/
/Users/howarth/gcc/gcc/testsuite/c-c++-common/dfp/func-vararg-mixed-2.c  
-mpreferred-stack-boundary=2  -lm   -m32 -o ./func-vararg-mixed-2.exe   
(timeout = 300)
Undefined symbols:
  "___dpd_truncddsd2", referenced from:
  _vararg_d64 in ccSemHJT.o
  "___dpd_nesd2", referenced from:
  _main in ccSemHJT.o
  "___dpd_nedd2", referenced from:
  _main in ccSemHJT.o
  "___dpd_netd2", referenced from:
  _main in ccSemHJT.o
  "___dpd_extendsddd2", referenced from:
  _main in ccSemHJT.o
ld: symbol(s) not found


-- 
   Summary: r163815/r163816 produces new regressions on x86_64-
apple-darwin10
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: howarth at nitro dot med dot uc dot edu
 GCC build triplet: x86_64-apple-darwin10
  GCC host triplet: x86_64-apple-darwin10
GCC target triplet: x86_64-apple-darwin10


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

[Bug fortran/45525] New: gfortran.dg/dummy_procedure_1.f90 failed

[hjl dot tools at gmail dot com]

On Linux/x86-64, I got

/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gfortran.dg/dummy_procedure_1.f90:39.10:^M
^M
  call s1(i) ! { dg-error "Expected a procedure for argument" }^M
  1^M
Error: Expected a procedure for argument 'f' at (1)^M
/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gfortran.dg/dummy_procedure_1.f90:43.10:^M
^M
  call s1(z) ! { dg-error "Expected a procedure for argument" }^M
  1^M
Error: Expected a procedure for argument 'f' at (1)^M
/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gfortran.dg/dummy_procedure_1.f90:44.10:^M
^M
  call s2(x) ! { dg-error "Invalid procedure argument" }^M
  1^M
Error: Invalid procedure argument at (1)^M

PASS: gfortran.dg/dummy_procedure_1.f90  -O   (test for errors, line 39)
FAIL: gfortran.dg/dummy_procedure_1.f90  -O   (test for errors, line 40)


-- 
   Summary: gfortran.dg/dummy_procedure_1.f90 failed
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com


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

[Bug fortran/45525] [4.6 Regression] gfortran.dg/dummy_procedure_1.f90 failed

[hjl dot tools at gmail dot com]

--- Comment #1 from hjl dot tools at gmail dot com  2010-09-03 18:09 ---
It failed with revision 163827 and worked with 163811.
It may be caused by revision163813 :

http://gcc.gnu.org/ml/gcc-cvs/2010-09/msg00104.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC|kargl at gcc dot gnu dot org|d at domob dot eu
Summary|gfortran.dg/dummy_procedure_|[4.6 Regression]
   |1.f90 failed|gfortran.dg/dummy_procedure_
   ||1.f90 failed


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

[Bug fortran/45525] [4.6 Regression] gfortran.dg/dummy_procedure_1.f90 failed

[domob at gcc dot gnu dot org]

--- Comment #2 from domob at gcc dot gnu dot org  2010-09-03 18:24 ---
Created an attachment (id=21687)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21687&action=view)
Proposed patch

Patch to fix this.  I wonder why it did not show up for me before, but I'm
taking this and will regtest/submit this nearly obvious patch now.


-- 

domob at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |domob at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED


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

[Bug middle-end/45312] [4.4 Regression] GCC 4.4.4 miscompiles the Linux kernel

[uweigand at gcc dot gnu dot org]

--- Comment #14 from uweigand at gcc dot gnu dot org  2010-09-03 18:30 
---
(In reply to comment #12)
> Yes, it would but I think the reload should still generate the right code in
> this particular order of insns.  IMHO, fixing the order of insn is not the
> right thing to do because there might be situation of cycle (e.g. value of 
> p600
> is inherited from 2 but should be reloaded into 3 and p356 is inherited from 3
> and should be reloaded into 2). 
> 
> The problem is definitely in reload inheritance.  Reg_last_reload_reg is not
> invalidated by insn #1407 which is generated by another reload of insn #675.

Actually, I think this really is a reload insn ordering problem. Note that
reload inheritance tracking via reg_last_reload_reg works on the whole reloaded
insn including all the generated reload insns as a whole. Conflicts between
different reloads of the same original insn should be treated specially, taking
into account reload insn ordering (this is done in free_for_value_p).

In this particular case, what happens is this.  After initial reload register
selection, we have this set of reloads:

Reload 0: reload_in (SI) = (reg/v/f:SI 132 [ kpte ])
GENERAL_REGS, RELOAD_FOR_OPERAND_ADDRESS (opnum = 0)
reload_in_reg: (reg/v/f:SI 132 [ kpte ])
reload_reg_rtx: (reg:SI 5 di)
Reload 1: reload_in (SI) = (reg/v/f:SI 132 [ kpte ])
DIREG, RELOAD_FOR_INPUT (opnum = 1)
reload_in_reg: (reg/v/f:SI 132 [ kpte ])
reload_reg_rtx: (reg:SI 5 di)
Reload 2: reload_in (SI) = (reg:SI 588 [ D.29684 ])
BREG, RELOAD_FOR_INPUT (opnum = 2)
reload_in_reg: (reg:SI 588 [ D.29684 ])
reload_reg_rtx: (reg:SI 3 bx)
Reload 3: reload_in (SI) = (reg:SI 356)
CREG, RELOAD_FOR_INPUT (opnum = 3)
reload_in_reg: (reg:SI 356)
reload_reg_rtx: (reg:SI 2 cx)

Reload inheritance notes that reload_in of reload 2 (reg:SI 588) is already
available in CX at this point.  While this cannot be used as reload register
due to the BREG class, it is chosen as "override input", i.e. reload_in is set
to (reg:SI 2 cx) instead of of (reg:SI 588).

Code near the end of choose_reload_regs then verifies whether this causes any
problems due to re-use of the CX register, and comes to the (correct) decision
that it does not, since it knows the reload insn for reload 3 (a
RELOAD_FOR_INPUT for operand 3) which clobbers CX will certainly be generated
*after* the override-input reload insn for reload 2 (a RELOAD_FOR_INPUT for
operand 2).

Unfortunately, some time *after* this decision has been made, the when_needed
field of reload 3 is changed from RELOAD_FOR_INPUT to RELOAD_OTHER.  This
causes the sequence of generated reload insns to change (RELOAD_OTHER reloads
are emitted before RELOAD_FOR_INPUT reloads) -- this breaks the assumptions the
reload inheritance code made, and causes wrong code to be generated.

Now the question is, why does this change to RELOAD_OTHER happen.  This is done
in merge_assigned_reloads, which is called because i386 is a target with
SMALL_REGISTER_CLASSES.  This routine notices that reloads 0 and 1 share a
reload register DI, and decides to merge them, making reload 0 a RELOAD_OTHER
reload (and cancelling reload 1).  It then goes through all other reloads:

  /* If this is now RELOAD_OTHER, look for any reloads that
 load parts of this operand and set them to
 RELOAD_FOR_OTHER_ADDRESS if they were for inputs,
 RELOAD_OTHER for outputs.  Note that this test is
 equivalent to looking for reloads for this operand
 number.

This loop now appears to detect reload 3 as a reload that "loads part of" the
operand 0.  This happens because 
   reg_overlap_mentioned_for_reload_p (rld[j].in,
   rld[i].in))
returns true since both reload-in values are stack slots, and
reg_overlap_mentioned_for_reload_p conservatively assumes that all memory
accesses conflict.

Therefore, when_needed for reload 3 is also set to RELOAD_OTHER.  This is not
only unnecessary, but in turn causes the breakage.

Now in this particular case, it might be possible to fix the problem by using a
better detection of which additional reloads need to be modified.  (The comment
says, "Note that this test is equivalent to looking for reloads for this
operand number." -- which is not true, but could be implemented instead ...)

However, the problem seems to be more fundamental.  If *any* change, even
necessary changes, to when_needed flags are made at this point, *any* decision
on reload inheritance or input overrides that was based on reload insn ordering
may now be incorrect.

I guess a conservative fix could be to check whether any reload inheritance was
indeed or input override was indeed performed on this insn, and if so, refuse
to perform the merge ...


-- 


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

[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10

[howarth at nitro dot med dot uc dot edu]

--- Comment #1 from howarth at nitro dot med dot uc dot edu  2010-09-03 
18:53 ---
Created an attachment (id=21688)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21688&action=view)
gcc/config.log from x86_64-apple-darwin10


-- 


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

[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10

[howarth at nitro dot med dot uc dot edu]

--- Comment #2 from howarth at nitro dot med dot uc dot edu  2010-09-03 
18:54 ---
Created an attachment (id=21689)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21689&action=view)
gcc/autohost.h from x86_64-apple-darwin10


-- 


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

[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10

[howarth at nitro dot med dot uc dot edu]

--- Comment #3 from howarth at nitro dot med dot uc dot edu  2010-09-03 
18:56 ---
Added gcc/config.log and gcc/autohost.h files from a build on
x86_64-apple-darwin10 configured with...

../gcc/configure --prefix=/Users/howarth/dist --with-gmp=/sw
--with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-mpc=/sw
--with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
--enable-checking=yes --enable-languages=c --enable-lto


-- 


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

Re: [Bug c++/45523] New: Failure to bind auto variable to function template instance

[Andrew Pinski]

I think there is a dup of this bug without auto. Not to mention it was  
defect report against the standard.


On Sep 3, 2010, at 10:07 AM, "jewillco at osl dot iu dot edu" > wrote:



The following code:

template  void foo();
void f() {auto g = foo;}

fails to compile in GCC 4.5.0's C++0x mode with the following error:

foo.cpp: In function ‘void f()’:
foo.cpp:2:20: error: ‘g’ has incomplete type

Trying different variants of this code, it appears that GCC believes  
that
foo is an ambiguous overloaded function, while there is only  
one matching

function.


--
  Summary: Failure to bind auto variable to function template
   instance
  Product: gcc
  Version: 4.5.0
   Status: UNCONFIRMED
 Severity: normal
 Priority: P3
Component: c++
   AssignedTo: unassigned at gcc dot gnu dot org
   ReportedBy: jewillco at osl dot iu dot edu
GCC build triplet: x86_64-unknown-linux-gnu
 GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug c++/45523] [C++0x] Failure to bind auto variable to function template instance

[pinskia at gmail dot com]

--- Comment #3 from pinskia at gmail dot com  2010-09-03 19:02 ---
Subject: Re:   New: Failure to bind auto variable to function template instance

I think there is a dup of this bug without auto. Not to mention it was  
defect report against the standard.

On Sep 3, 2010, at 10:07 AM, "jewillco at osl dot iu dot edu"
 wrote:

> The following code:
>
> template  void foo();
> void f() {auto g = foo;}
>
> fails to compile in GCC 4.5.0's C++0x mode with the following error:
>
> foo.cpp: In function ‘void f()’:
> foo.cpp:2:20: error: ‘g’ has incomplete type
>
> Trying different variants of this code, it appears that GCC believes  
> that
> foo is an ambiguous overloaded function, while there is only  
> one matching
> function.
>
>
> -- 
>   Summary: Failure to bind auto variable to function template
>instance
>   Product: gcc
>   Version: 4.5.0
>Status: UNCONFIRMED
>  Severity: normal
>  Priority: P3
> Component: c++
>AssignedTo: unassigned at gcc dot gnu dot org
>ReportedBy: jewillco at osl dot iu dot edu
> GCC build triplet: x86_64-unknown-linux-gnu
>  GCC host triplet: x86_64-unknown-linux-gnu
> GCC target triplet: x86_64-unknown-linux-gnu
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45523
>


-- 


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

[Bug c++/45510] Bug with anonymous unions and bit-fields

[runipg at broadcom dot com]

--- Comment #10 from runipg at broadcom dot com  2010-09-03 19:19 ---
Subject: Re:  Bug with anonymous unions and bit-fields

Your suggestion works:

struct bfc {
  union {
struct {
  unsigned int a : 1,
 b : 4;
};
unsigned int data;
  };
};

void
testc()
{
   cout << __func__ << endl;

   bfc bf0;
   bf0.data = 0;

   cout << "bf0.data=" << hex << bf0.data << endl;
   cout << "bf0.a=" << bf0.a << endl;
   cout << "bf0.b=" << bf0.b << endl;

   bf0.a = 1;

   cout << "bf0.data=" << hex << bf0.data << endl;
   cout << "bf0.a=" << bf0.a << endl;
   cout << "bf0.b=" << hex << bf0.b << endl;

   bf0.b = 1;

   cout << "bf0.data=" << hex << bf0.data << endl;
   cout << "bf0.a=" << bf0.a << endl;
   cout << "bf0.b=" << hex << bf0.b << endl;
}

Output is 

testc
bf0.data=0
bf0.a=0
bf0.b=0
bf0.data=1
bf0.a=1
bf0.b=0
bf0.data=3
bf0.a=1
bf0.b=1
---

I guess the fundamental issue which confused me was:

struct bfa {
  union {
unsigned int a : 1,
   b : 4;
unsigned int data;
  };
};

that it appeared to be a union of 2 integers (one bit-field) rather than 
the implementation version where the union is of 3 integers 
(two-bitfields).  If the standard does not say anything specific about 
it, then I guess the compiler is free to do whatever it wants.

In fact, I tried a slight variation on bfa, where I tried to force 
alignment on the first integer packing.

struct bfd {
  union {
unsigned int a : 1,
   b : 4,
   : 0;   //force alignment
unsigned int data;
  };
};

However this gives the same result as bfa.

So I guess semantically it is very confusing to a user. Perhaps this 
part of the language should be tightened.

Thanks Paolo!

-Runip

paolo dot carlini at oracle dot com wrote:
> --- Comment #8 from paolo dot carlini at oracle dot com  2010-09-03 10:46 
> ---
> If you look at the actual Standard, both alignment and allocation of 
> bit-fields
> are implementation defined. Thus, as far as I can see, at best we are talking
> about non-portable implementation defined behavior. If you want my advice, try
> to stay away from those tricks, with and without anonymous struct.
>
>
>   


-- 


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

[Bug c++/45523] [C++0x] Failure to bind auto variable to function template instance

[jewillco at osl dot iu dot edu]

--- Comment #4 from jewillco at osl dot iu dot edu  2010-09-03 19:29 ---
One thing that I forgot to mention -- the Comeau online compiler accepts this
code without any errors (just a warning about "g" being unused).


-- 


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

[Bug fortran/45186] [4.6 Regression] Gfortran 4.5.0 emits wrong linenumbers

[burnus at gcc dot gnu dot org]

--- Comment #13 from burnus at gcc dot gnu dot org  2010-09-03 19:41 ---
Subject: Bug 45186

Author: burnus
Date: Fri Sep  3 19:41:11 2010
New Revision: 163838

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163838
Log:
2010-09-03  Tobias Burnus  

PR fortran/45186
* trans-intrinsic.c (gfc_conv_intrinsic_sign,
gfc_conv_intrinsic_leadz): Use build_call_expr_loc instead
of build_call_expr.
* trans-expr.c (gfc_conv_expr_present, gfc_conv_missing_dummy,
gfc_conv_string_length, gfc_conv_substring,
gfc_conv_component_ref, gfc_conv_unary_op, gfc_conv_powi,
gfc_conv_cst_int_power, gfc_conv_string_tmp, gfc_conv_concat_op,
gfc_conv_expr_op, gfc_build_compare_string,
gfc_set_interface_mapping_bounds, gfc_conv_subref_array_arg,
gfc_conv_derived_to_class, conv_isocbinding_procedure,
gfc_conv_procedure_call, fill_with_spaces,
gfc_trans_string_copy, gfc_trans_alloc_subarray_assign,
gfc_trans_structure_assign, gfc_trans_pointer_assignment,
gfc_trans_scalar_assign, gfc_trans_zero_assign,
gfc_trans_array_copy, gfc_trans_array_constructor_copy): Change
fold_build[0-9] to fold_build[0-9]_loc.
* trans-io.c (set_parameter_const, set_parameter_value,
set_parameter_ref, gfc_convert_array_to_string, set_string,
set_internal_unit, io_result, set_error_locus,
nml_get_addr_expr, build_dt): Ditto.
* trans-openmp.c (gfc_omp_clause_default_ctor,
gfc_omp_clause_copy_ctor, gfc_omp_clause_assign_op,
gfc_trans_omp_array_reduction, gfc_trans_omp_atomic,
gfc_trans_omp_do): Ditto.
* trans.c (gfc_add_modify, gfc_build_addr_expr,
gfc_build_array_ref, gfc_trans_runtime_error_vararg,
gfc_trans_runtime_check, gfc_call_malloc,
gfc_allocate_with_status, gfc_allocate_array_with_status,
gfc_call_free, gfc_deallocate_with_status,
gfc_call_realloc): Ditto.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-expr.c
trunk/gcc/fortran/trans-intrinsic.c
trunk/gcc/fortran/trans-io.c
trunk/gcc/fortran/trans-openmp.c
trunk/gcc/fortran/trans.c


-- 


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

[Bug fortran/45525] [4.6 Regression] gfortran.dg/dummy_procedure_1.f90 failed

[mikael at gcc dot gnu dot org]

--- Comment #3 from mikael at gcc dot gnu dot org  2010-09-03 19:45 ---
(In reply to comment #2)
> Created an attachment (id=21687)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21687&action=view) [edit]
> Proposed patch
> 
> Patch to fix this.  I wonder why it did not show up for me before, but I'm
> taking this and will regtest/submit this nearly obvious patch now.
> 

It is indeed obvious ; I pre-approve it and you don't even need to regtest, as
your patch isn't changing any code. 


-- 


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

[Bug fortran/45525] [4.6 Regression] gfortran.dg/dummy_procedure_1.f90 failed

[domob at gcc dot gnu dot org]

--- Comment #4 from domob at gcc dot gnu dot org  2010-09-03 19:51 ---
Subject: Bug 45525

Author: domob
Date: Fri Sep  3 19:50:44 2010
New Revision: 163840

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163840
Log:
2010-09-03  Daniel Kraft  

PR fortran/45525
* gfortran.dg/dummy_procedure_1.f90: Add -std=f2003 and adapt error.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/dummy_procedure_1.f90


-- 


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

[Bug target/45476] libgcc should contain TCmode functions

[ubizjak at gmail dot com]

--- Comment #10 from ubizjak at gmail dot com  2010-09-03 19:58 ---
Fixed for all targets that support __float128.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 GCC target triplet|*86*-apple-darwin10 |x86
 Resolution||FIXED
   Target Milestone|--- |4.6.0


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

[Bug tree-optimization/45522] VRP misses oppurtunity for statement folding.

[hubicka at gcc dot gnu dot org]

--- Comment #4 from hubicka at gcc dot gnu dot org  2010-09-03 20:04 ---
A related testcase where we fail to fold fundamentals[0]
typedef union tree_node *tree;
enum tree_code
{
  OFFSET_TYPE, ENUMERAL_TYPE, BOOLEAN_TYPE, POINTER_TYPE, FIXED_POINT_TYPE,
};
struct tree_base
{
  unsigned public_flag:1;
};
struct tree_decl_with_vis
{
  unsigned comdat_flag:1;
};
union tree_node
{
  struct tree_base base;
  struct tree_decl_with_vis decl_with_vis;
};
enum tree_index
{
TI_LONG_DOUBLE_PTR_TYPE, TI_INTEGER_PTR_TYPE, TI_VOID_TYPE, TI_PTR_TYPE,
TI_VA_LIST_FPR_COUNTER_FIELD, TI_BOOLEAN_TYPE, TI_FILEPTR_TYPE,
TI_CURRENT_TARGET_PRAGMA, TI_CURRENT_OPTIMIZE_PRAGMA, TI_MAX
};
extern tree global_trees[TI_MAX];
emit_support_tinfos (void)
{
  static tree *const fundamentals[] = {
&global_trees[TI_VOID_TYPE], &global_trees[TI_BOOLEAN_TYPE],
  };
  int ix;
  for (ix = 0; fundamentals[ix]; ix++)
{
{
  tree tinfo;
{
  ((void) (!(((tinfo)->base.public_flag) && !(__extension__ (
  {
 
__typeof
 
(tinfo)
  __t
  =
 
(tinfo);
  __t;}
  )->decl_with_vis.
  comdat_flag)) ?
   fancy_abort ("../../gcc/cp/rtti.c", 1529,
__FUNCTION__), 0 : 0));
}
}
}
}


-- 


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