[Bug middle-end/47127] gcc.dg/graphite/id-14.c ICEs with cloog-parma

[howarth at nitro dot med.uc.edu]

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

--- Comment #4 from Jack Howarth  2010-12-30 
03:44:51 UTC ---
Also...

FAIL: libgomp.graphite/force-parallel-3.c (internal compiler error)
FAIL: libgomp.graphite/force-parallel-4.c (internal compiler error)
FAIL: libgomp.graphite/force-parallel-5.c (internal compiler error)
FAIL: libgomp.graphite/force-parallel-7.c (internal compiler error)
FAIL: libgomp.graphite/force-parallel-9.c (internal compiler error)

[Bug fortran/47051] [4.6 Regression] wrong reallocate

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot
   ||gnu.org

--- Comment #7 from Jerry DeLisle  2010-12-30 
03:19:55 UTC ---
Whys is this a regression? When did it work last?

[Bug fortran/37744] ICE-on-invalid with ISO_C_BINDING

[dfranke at gcc dot gnu.org]

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

Daniel Franke  changed:

   What|Removed |Added

  Known to fail||

--- Comment #14 from Daniel Franke  2010-12-30 
03:07:14 UTC ---
(In reply to comment #12)
> I might take a look someday.
> It seems a namespace is freed to soon. -fwhole-file works as it retains
> namespaces till the end.

You may also want to have a look at PR41093.

[Bug fortran/43179] ICE invalid if accessing array member of non-array

[dfranke at gcc dot gnu.org]

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

--- Comment #8 from Daniel Franke  2010-12-30 
02:39:58 UTC ---
(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #2)
> > > > OK for trunk with the usual embellishments of ChangeLogs and testcase?
> > > 
> > > Yes, if you have an example for EXPR_FUNCTION - otherwise I would claim 
> > > that
> > > EXPR_VARIABLE is enough.
> > 
> > Paul, any plans to wrap this up? :)
> 
> Another one for Sunday, or thereabouts.

Ping?

[Bug target/47129] ia64-hp-vms: ia64.o: dwarf2out_vms_debug_main_pointer undeclared

[amylaar at gcc dot gnu.org]

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

Jorn Wolfgang Rennecke  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #2 from Jorn Wolfgang Rennecke  
2010-12-30 02:03:35 UTC ---
Patch has been applied to trunk.

[Bug target/47129] ia64-hp-vms: ia64.o: dwarf2out_vms_debug_main_pointer undeclared

[amylaar at gcc dot gnu.org]

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

--- Comment #1 from Jorn Wolfgang Rennecke  
2010-12-30 01:58:14 UTC ---
Author: amylaar
Date: Thu Dec 30 01:58:10 2010
New Revision: 168332

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168332
Log:
PR target/47129
* config/ia64/ia64.c: Include "dwarf2out.h" .

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

[Bug target/47129] New: ia64-hp-vms: ia64.o: dwarf2out_vms_debug_main_pointer undeclared

[amylaar at gcc dot gnu.org]

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

   Summary: ia64-hp-vms: ia64.o: dwarf2out_vms_debug_main_pointer
undeclared
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: amyl...@gcc.gnu.org
Blocks: 44756
  Host: x86_64-pc-linux-gnu
Target: ia64-hp-vms


../../gcc/gcc/config/ia64/ia64.c: In function ‘ia64_start_function’:
../../gcc/gcc/config/ia64/ia64.c:3593:7: error: implicit declaration of
function ‘dwarf2out_vms_debug_main_pointer’
[-Werror=implicit-function-declaration]
cc1: all warnings being treated as errors

make[1]: *** [ia64.o] Error 1

[Bug target/47101] ia64-hp-vms: main_input_filename clash

[amylaar at gcc dot gnu.org]

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

Jorn Wolfgang Rennecke  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #1 from Jorn Wolfgang Rennecke  
2010-12-30 01:40:07 UTC ---
I have posted a patch here:

http://gcc.gnu.org/ml/gcc-patches/2010-12/msg01960.html

[Bug target/47063] ada fails to build for alpha64-dec-vms

[amylaar at gcc dot gnu.org]

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

Jorn Wolfgang Rennecke  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #3 from Jorn Wolfgang Rennecke  
2010-12-30 01:31:56 UTC ---
(In reply to comment #2)
> I suppose it was meant to be MALLOC_ABI_ALIGNMENT?

I have posted a patch for this:

http://gcc.gnu.org/ml/gcc-patches/2010-12/msg01959.html

[Bug libstdc++/42679] RTLD_DEEPBIND dlopen option for shared library that uses libstdc++ std::ostream crashes

[redi at gcc dot gnu.org]

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

--- Comment #19 from Jonathan Wakely  2010-12-29 
23:50:51 UTC ---
(In reply to comment #16)
> I am using "-fpic/-fPIC" and in fact am using:
> // g++ -g -O0 main.cpp -ldl
> // g++ -g -O0 -rdynamic -c -fPIC -o library.o library1.cpp
> // g++ -shared -Wl,-export-dynamic -o library.so library.o

What if you use -fPIC for the last step?  (The manual does say it's necessary
for predictable results when using -shared)


(In reply to comment #17)
> This is with using gcc for linking instead of g++.

The main difference is that g++ automatically links to libstdc++, but if you
use gcc and link to libstdc++ then you still get the same effect.

[Bug middle-end/47127] gcc.dg/graphite/id-14.c ICEs with cloog-parma

[howarth at nitro dot med.uc.edu]

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

--- Comment #3 from Jack Howarth  2010-12-29 
23:35:54 UTC ---
Also...

FAIL: gfortran.dg/graphite/id-12.f  -O  (internal compiler error)
FAIL: gfortran.dg/graphite/id-14.f  -O  (internal compiler error)
FAIL: gfortran.dg/graphite/id-21.f  -O  (internal compiler error)
FAIL: gfortran.dg/graphite/id-9.f  -O  (internal compiler error)
FAIL: gfortran.dg/graphite/id-pr45370.f90  -O  (internal compiler error)
FAIL: gfortran.dg/graphite/run-id-2.f90  -O  (internal compiler error)
FAIL: gfortran.dg/graphite/pr42732.f  -O  (internal compiler error)

[Bug ada/47063] ada fails to build for alpha64-dec-vms

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther  2010-12-29 
23:05:08 UTC ---
I suppose it was meant to be MALLOC_ABI_ALIGNMENT?

[Bug ada/47063] ada fails to build for alpha64-dec-vms

[amylaar at gcc dot gnu.org]

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

Jorn Wolfgang Rennecke  changed:

   What|Removed |Added

 CC||gingold at adacore dot com,
   ||rth at gcc dot gnu.org,
   ||rupp at gnat dot com

--- Comment #1 from Jorn Wolfgang Rennecke  
2010-12-29 22:58:46 UTC ---
As far as I can tell, the definition of MALLOC_ALIGNMENT in config/alpha/vms.h
serves no purpose.  The only file that both includes tm.h and references
MALLOC_ALIGNMENT is the one that breaks, ada/gcc-interface/targtyps.c .

When the definition was added, in:
http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00476.html ,
there was no such reference in the entire gcc tree.

[Bug fortran/45338] Failure on interfacing a function passed as an argument as a custom operator

[tkoenig at gcc dot gnu.org]

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

--- Comment #2 from Thomas Koenig  2010-12-29 
22:56:32 UTC ---
Created attachment 22868
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22868
Tentative patch

Sounds like the referenced attribute isn't set correctly.

We could try setting it during resolution, like this.

[Bug fortran/47085] [OOP] Problem in allocate( SOURCE=) for polymorphic component

[janus at gcc dot gnu.org]

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

--- Comment #2 from janus at gcc dot gnu.org 2010-12-29 22:44:26 UTC ---
While reducing the test case I noticed that the following invalid code triggers
an ICE:


  type :: t0
  end type
  class(t0) :: x
  allocate(x)
  end


Backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x00520e06 in gfc_match_varspec (primary=0x1939130, equiv_flag=0,
sub_flag=0 '\000', ppc_arg=0 '\000') at
/home/jweil/gcc46/trunk/gcc/fortran/primary.c:1777
1777  || (sym->ts.type == BT_CLASS && CLASS_DATA
(sym)->attr.dimension))
(gdb) bt
#0  0x00520e06 in gfc_match_varspec (primary=0x1939130, equiv_flag=0,
sub_flag=0 '\000', ppc_arg=0 '\000') at
/home/jweil/gcc46/trunk/gcc/fortran/primary.c:1777
#1  0x00523b56 in match_variable (result=0x192eb80, equiv_flag=0,
host_flag=1) at /home/jweil/gcc46/trunk/gcc/fortran/primary.c:3104
#2  0x00523bac in gfc_match_variable (result=0x192eb80, equiv_flag=0)
at /home/jweil/gcc46/trunk/gcc/fortran/primary.c:3119
#3  0x00503697 in gfc_match_allocate () at
/home/jweil/gcc46/trunk/gcc/fortran/match.c:2908

[Bug fortran/47085] [OOP] Problem in allocate( SOURCE=) for polymorphic component

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.12.29 22:39:46
 Ever Confirmed|0   |1

--- Comment #1 from janus at gcc dot gnu.org 2010-12-29 22:39:46 UTC ---
I have reduced the test case quite a bit, while maintaining the valgrind error:


program ppde
  implicit none

  type :: t0
  end type

  type, extends(t0) :: t1
integer, allocatable :: c(:)
  end type

  class(t0), allocatable :: x, y

  allocate(t1 :: x)
  allocate(y, source=x) 

end


When compiling this with -g and running under valgrind, I get:

==26472== Conditional jump or move depends on uninitialised value(s)
==26472==at 0x4009B7: __copy_ppde_t1.1550 (ppde.f90:1)
==26472==by 0x400AD1: MAIN__ (ppde.f90:16)
==26472==by 0x400B74: main (ppde.f90:16)

This means the error happens inside the copying routine of the extended type,
and seems to be related to the allocatable component. In the original test case
the error message appeared in a triple, because three allocatable components
were involved. This is the same issue as described in PR 46408.

[Bug fortran/44735] ICE on FORALL with character array pointer

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org,
   ||tkoenig at gcc dot gnu.org
  Known to fail||

--- Comment #3 from Thomas Koenig  2010-12-29 
22:18:34 UTC ---
Hi Paul,

The problem may well be where Joe pointed it out.

In

  if (expr1->ts.type == BT_CHARACTER && expr1->ts.u.cl->length)
{
  if (!expr1->ts.u.cl->backend_decl)
{
  gfc_se tse;
  gfc_init_se (&tse, NULL);
  gfc_conv_expr (&tse, expr1->ts.u.cl->length);
  expr1->ts.u.cl->backend_decl = tse.expr;
}
  type = gfc_get_character_type_len (gfc_default_character_kind,
 expr1->ts.u.cl->backend_decl);
}

the fact that expr1 has a substring reference is not taken into account,
so it might be necessary to calculate the length of the string
from expr1->ref->u.ss.end - expr1->ref.u.ss.start + 1.  You may have
to take care not to calculate any functions twice, though.

Hope this helps a little bit.

[Bug middle-end/47127] gcc.dg/graphite/id-14.c ICEs with cloog-parma

[howarth at nitro dot med.uc.edu]

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

--- Comment #2 from Jack Howarth  2010-12-29 
22:10:05 UTC ---
Also...

FAIL: g++.dg/graphite/id-1.C (internal compiler error)

at -m32 but not -m64.

[Bug middle-end/47128] New: gcc.dg/graphite/pr43012.c ICEs with cloog-parma

[howarth at nitro dot med.uc.edu]

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

   Summary: gcc.dg/graphite/pr43012.c ICEs with cloog-parma
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: howa...@nitro.med.uc.edu


The gcc.dg/graphite/pr43012.c test case ICEs when gcc trunk is built against
the pre-release cloog-parma 0.16.0 at both -m32 and -m64 The failure appears
as...

/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/
/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20101229/gcc/testsuite/gcc.dg/graphite/pr43012.c
-O2 -floop-strip-mine -lm -m32 -o ./pr43012.exe
/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20101229/gcc/testsuite/gcc.dg/graphite/pr43012.c:
In function 'pre_init_tokenizer':
/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20101229/gcc/testsuite/gcc.dg/graphite/pr43012.c:21:1:
internal compiler error: in translate_clast, at graphite-clast-to-gimple.c:1123

and backtraces as...

Breakpoint 1, fancy_abort (file=0x100993870
"../../gcc-4.6-20101229/gcc/graphite-clast-to-gimple.c", line=1123,
function=0x100a4e3b0 "translate_clast") at
../../gcc-4.6-20101229/gcc/diagnostic.c:893
893  internal_error ("in %s, at %s:%d", function, trim_filename (file),
line);
(gdb) bt
#0  fancy_abort (file=0x100993870
"../../gcc-4.6-20101229/gcc/graphite-clast-to-gimple.c", line=1123,
function=0x100a4e3b0 "translate_clast") at
../../gcc-4.6-20101229/gcc/diagnostic.c:893
#1  0x0001004e9175 in translate_clast (region=, context_loop=0x142f0aaa0, stmt=, next_e=0x1448782c0,
newivs=0x7fff5fbfe9d8, newivs_index=0x142d2d2b0, bb_pbb_mapping=0x142d1e510,
level=1, params_index=0x142d390d0) at
../../gcc-4.6-20101229/gcc/graphite-clast-to-gimple.c:1123
Previous frame inner to this frame (gdb could not unwind past this frame)

Using built-in specs.
COLLECT_GCC=gcc-4
COLLECT_LTO_WRAPPER=/sw/lib/gcc4.6/libexec/gcc/x86_64-apple-darwin10.5.0/4.6.0/lto-wrapper
Target: x86_64-apple-darwin10.5.0
Configured with: ../gcc-4.6-20101229/configure --prefix=/sw
--prefix=/sw/lib/gcc4.6 --mandir=/sw/share/man --infodir=/sw/lib/gcc4.6/info
--enable-languages=c,c++,fortran,objc,obj-c++,java --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
--program-suffix=-fsf-4.6 --enable-checking=yes --enable-cloog-backend=ppl
Thread model: posix
gcc version 4.6.0 20101229 (experimental) (GCC)

[Bug fortran/45777] Alias analysis broken for arrays where LHS or RHS is a component ref

[tkoenig at gcc dot gnu.org]

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

--- Comment #7 from Thomas Koenig  2010-12-29 
22:03:47 UTC ---
I think we should be doing the checking against the
typespec of the component.  The component looks reasonable:

p *(rref->u.c.component)
$19 = {name = 0x75d11fa8 "data", ts = {type = BT_INTEGER, kind = 4, u =
{derived = 0x0, cl = 0x0,
  pad = 0},

but the sym just has

(gdb) p *(rref->u.c.sym)
$20 = {name = 0x75d11f98 "t1", module = 0x75d11f88 "m1", declared_at =
{nextc = 0x148a8e0,
lb = 0x148a8a0}, ts = {type = BT_UNKNOWN, kind = 0, u = {derived = 0x0, cl
= 0x0, pad = 0},
interface = 0x0, is_c_interop = 0, is_iso_c = 0, f90_type = BT_UNKNOWN,
deferred = 0 '\000'}, attr = {
allocatable = 0, dimension = 0, codimension = 0, external = 0, intrinsic =
0, optional = 0,

[Bug middle-end/47127] gcc.dg/graphite/id-14.c ICEs with cloog-parma

[howarth at nitro dot med.uc.edu]

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

--- Comment #1 from Jack Howarth  2010-12-29 
21:57:03 UTC ---
This same failure also occurs in the test cases...

FAIL: gcc.dg/graphite/id-pr45230-1.c (internal compiler error)
FAIL: gcc.dg/graphite/id-pr45230.c (internal compiler error)
FAIL: gcc.dg/graphite/run-id-5.c (internal compiler error)
FAIL: gcc.dg/graphite/run-id-6.c (internal compiler error)
FAIL: gcc.dg/graphite/interchange-10.c (internal compiler error)
FAIL: gcc.dg/graphite/interchange-4.c (internal compiler error)
FAIL: gcc.dg/graphite/block-1.c (internal compiler error)
FAIL: gcc.dg/graphite/block-3.c (internal compiler error)
FAIL: gcc.dg/graphite/block-5.c (internal compiler error)
FAIL: gcc.dg/graphite/pr41888.c (internal compiler error)
FAIL: gcc.dg/graphite/pr42284.c (internal compiler error)
FAIL: gcc.dg/graphite/pr42521.c (internal compiler error)
FAIL: gcc.dg/graphite/pr42771.c (internal compiler error)
FAIL: gcc.dg/graphite/pr46185.c (internal compiler error)
FAIL: gcc.dg/graphite/pr46404-1.c (internal compiler error)
FAIL: gcc.dg/graphite/pr46404.c (internal compiler error)
FAIL: gcc.dg/graphite/pr46761.c (internal compiler error)

[Bug objc/47118] ICE on incorrect parameter to @synchronized()

[nicola at gcc dot gnu.org]

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

--- Comment #2 from Nicola Pero  2010-12-29 21:52:03 
UTC ---
Author: nicola
Date: Wed Dec 29 21:52:00 2010
New Revision: 168326

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168326
Log:
In gcc/objc/:
2010-12-29  Nicola Pero  

PR objc/47118
* objc-act.c (objc_build_synchronized): Check the argument of
@synchronized and emit an appropriate error if it is not a valid
Objective-C object.  Deal gracefully with that case.  Updated
comments and variable names.

In gcc/testsuite/:
2010-12-29  Nicola Pero  

PR objc/47118
* objc.dg/sync-3.m: New.
* obj-c++.dg/sync-3.mm: New.


Added:
trunk/gcc/testsuite/obj-c++.dg/sync-3.mm
trunk/gcc/testsuite/objc.dg/sync-3.m
Modified:
trunk/gcc/objc/ChangeLog
trunk/gcc/objc/objc-act.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/47074] [4.6 Regression] tree check fail in create_access_replacement

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  2010-12-29 
21:49:40 UTC ---
Author: jakub
Date: Wed Dec 29 21:49:37 2010
New Revision: 168325

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168325
Log:
PR tree-optimization/47074
* gimple-fold.c (gimplify_and_update_call_from_tree): Call
pop_gimplify_context if returning early.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-fold.c

[Bug middle-end/47127] New: gcc.dg/graphite/id-14.c ICEs with cloog-parma

[howarth at nitro dot med.uc.edu]

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

   Summary: gcc.dg/graphite/id-14.c ICEs with cloog-parma
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: howa...@nitro.med.uc.edu


Currently the gcc.dg/graphite/id-14.c test case causes an ICE when gcc trunk is
built against ppl 0.11 and the pre-release cloog-parma 0.16 at both -m32 and
-m64. This crash is of the form...

/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/
/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20101229/gcc/testsuite/gcc.dg/graphite/id-14.c
  -O2 -fgraphite-identity -ffast-math -S  -m32 -o id-14.s
/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20101229/gcc/testsuite/gcc.dg/graphite/id-14.c:
In function 'foo':
/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20101229/gcc/testsuite/gcc.dg/graphite/id-14.c:7:1:
internal compiler error: Segmentation fault

and backtraces as...

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x
Parma_Polyhedra_Library::Constraint_System::insert (this=0x7fff5fbfe720,
c...@0x0) at ../../src/Constraint_System.cc:243
243  if (topology() == c.topology())
(gdb) bt
#0  Parma_Polyhedra_Library::Constraint_System::insert (this=0x7fff5fbfe720,
c...@0x0) at ../../src/Constraint_System.cc:243
#1  0x00014185dcb6 in Parma_Polyhedra_Library::Polyhedron::Polyhedron
(this=0x7fff5fbfe720, topol=Parma_Polyhedra_Library::NECESSARILY_CLOSED,
num_dimensions=1, kind=)
at Constraint_System.inlines.hh:183
#2  0x00014145ce88 in Determinate [inlined] () at ppl.hh:37971
#3  Determinate [inlined] () at
/sw/src/fink.build/ppl9-0.11-2/ppl-0.11/build/src/ppl.hh:77017
#4  0x00014145ce88 in
Parma_Polyhedra_Library::Pointset_Powerset::Pointset_Powerset
(this=0x141b33ed0, num_dimensions=1, kind=) at ppl.hh:80008
#5  0x000141452d2f in
ppl_new_Pointset_Powerset_C_Polyhedron_from_space_dimension (pph=0x141b2e850,
d=1, empty=0) at ppl_c_Pointset_Powerset_C_Polyhedron.cc:75
#6  0x00010050c122 in build_poly_scop (scop=0x141b2e820) at
../../gcc-4.6-20101229/gcc/graphite-sese-to-poly.c:913
Current language:  auto; currently c++

Using built-in specs.
COLLECT_GCC=gcc-4
COLLECT_LTO_WRAPPER=/sw/lib/gcc4.6/libexec/gcc/x86_64-apple-darwin10.5.0/4.6.0/lto-wrapper
Target: x86_64-apple-darwin10.5.0
Configured with: ../gcc-4.6-20101229/configure --prefix=/sw
--prefix=/sw/lib/gcc4.6 --mandir=/sw/share/man --infodir=/sw/lib/gcc4.6/info
--enable-languages=c,c++,fortran,objc,obj-c++,java --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
--program-suffix=-fsf-4.6 --enable-checking=yes --enable-cloog-backend=ppl
Thread model: posix
gcc version 4.6.0 20101229 (experimental) (GCC)

[Bug c/47126] frontend bug

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #1 from Andrew Pinski  2010-12-29 
21:15:46 UTC ---
Both values are correct.  

b++ +  inc() ;

can be evulated as:
tmp = b;
tmp + inc();
tmp = tmp + 1;
b = tmp;

Since there is no sequence point between the modifying of b and calling of inc.

[Bug c++/47125] [4.5/4.6 Regression] ICE occurs in combination with partial specialization and invalid template function.

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.12.29 21:13:38
 CC||jason at redhat dot com
   Target Milestone|--- |4.5.3
Summary|ICE occurs in combination   |[4.5/4.6 Regression] ICE
   |with partial specialization |occurs in combination with
   |and invalid template|partial specialization and
   |function.   |invalid template function.
 Ever Confirmed|0   |1

--- Comment #2 from H.J. Lu  2010-12-29 21:13:38 
UTC ---
It is caused by revision 145476:

http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg00097.html

[Bug c/47126] New: frontend bug

[aturjan at yahoo dot com]

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

   Summary: frontend bug
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: atur...@yahoo.com


Im compiling the code bellow (present also in the attachment) for x86 with gcc
4.4.3 and 4.5. Is it correct that at the end of main the value of variable b
should have been 4? When executing I get value 3. 

#include "stdio.h"
int *ptr;

int inc(void){
(*ptr)++;
return 1;
}

int main (void){
int a, b = 2;
ptr = &b;
b++ +  inc() ;

if(b==4)
printf("correct\n");
else
printf("incorrect %d\n",b);
return 1;
}

[Bug c++/47125] ICE occurs in combination with partial specialization and invalid template function.

[flast at flast dot jp]

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

--- Comment #1 from Kohei Takahashi  2010-12-29 19:51:04 
UTC ---
Created attachment 22867
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22867
test code

[Bug c++/47125] New: ICE occurs in combination with partial specialization and invalid template function.

[flast at flast dot jp]

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

   Summary: ICE occurs in combination with partial specialization
and invalid template function.
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: fl...@flast.jp


compiler output:
$ g++-4.5 testcase.cpp
testcase.cpp: In function 'void g()':
testcase.cpp:17:17: error: 'class enable_if::type' resolves to
'enable_if::type', which is is not a class type
testcase.cpp:17:17: error: 'class enable_if::type' resolves to
'enable_if::type', which is is not a class type
testcase.cpp:12:1: error: 'class enable_if::type' resolves to
'enable_if::type', which is is not a class type

Internal compiler error: Error reporting routines re-entered.
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

tested version:
4.4.4-14ubuntu5 - OK
4.5.1 - Crash
4.5.2 - Crash
4.6.0 r168322 - Crash

[Bug c++/47108] enum won't use long long as underlying type

[flo.ruijt at hotmail dot com]

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

--- Comment #5 from Floris Ruijter  2010-12-29 
18:37:57 UTC ---
On Wed, 2010-12-29 at 18:29 +, pinskia at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47108
> 
> --- Comment #4 from Andrew Pinski  2010-12-29 
> 18:29:07 UTC ---
> (In reply to comment #3)
> > indeed it works then. i find the behaviour pretty obscure though, why is
> > it that way?
> 
> Because 1 is of type int and doing a shift on it does not change its type and
> it is undefined what happens when the shiftor is greater than the size of the
> type.  So starting with 1LL and doing the shift will get you a value that is
> correct.
> 
ok, well i knéw C/C++ was obscure:p

[Bug tree-optimization/47074] [4.6 Regression] tree check fail in create_access_replacement

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Guenther  2010-12-29 
18:32:57 UTC ---
Looks obviously ok to me.

[Bug c++/47108] enum won't use long long as underlying type

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  2010-12-29 
18:29:07 UTC ---
(In reply to comment #3)
> indeed it works then. i find the behaviour pretty obscure though, why is
> it that way?

Because 1 is of type int and doing a shift on it does not change its type and
it is undefined what happens when the shiftor is greater than the size of the
type.  So starting with 1LL and doing the shift will get you a value that is
correct.

[Bug target/47124] New: *solaris2 configurations configure, but don't build

[amylaar at gcc dot gnu.org]

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

   Summary: *solaris2 configurations configure, but don't build
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: amyl...@gcc.gnu.org
Blocks: 47093
  Host: x86_64-pc-linux-gnu
Target: *solaris2


Solaris2 configurations without a minor OS version number, e.g.
sparc-sun-solaris2 --enable-threads=solaris,
configure, but fail to build because LIB_THREAD_LDFLAGS_SPEC is not defined:

../../../gcc/gcc/gcc.c:684:31: error: expected ‘,’ or ‘;’ before
‘LIB_THREAD_LDFLAGS_SPEC’
make[2]: *** [gcc.o] Error 1

If this configuration is not supposed to work, it would be preferable to
reject it at configure time.

[Bug target/47123] New: *freebsd cofigurations configure, but don't build

[amylaar at gcc dot gnu.org]

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

   Summary: *freebsd cofigurations configure, but don't build
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: amyl...@gcc.gnu.org
Blocks: 47093
  Host: x86_64-pc-linux-gnu
Target: *freebsd


Freebsd configurations without a major OS version number, e.g. alpha-freebsd,
configure, but fail to build because FBSD_MAJOR is not defined:

In file included from ./tm.h:20:0,
 from ../../../gcc/gcc/genflags.c:27:
../../../gcc/gcc/config/freebsd-spec.h:109:16: error: operator '<' has no left
operand
../../../gcc/gcc/config/freebsd-spec.h:128:16: error: operator '<' has no left
operand
make[1]: *** [build/genflags.o] Error 1
make[1]: Leaving directory
`/home/amylaar/pr46489/dec25/multi-mk2/alpha-freebsd/gcc'

If this configuration is not supposed to work, it would be preferable to
reject it at configure time.

[Bug tree-optimization/47074] [4.6 Regression] tree check fail in create_access_replacement

[dcb314 at hotmail dot com]

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

--- Comment #4 from dcb  2010-12-29 17:43:29 UTC ---
(In reply to comment #3)
> Created attachment 22865 [details]
> gcc46-pr47074.patch
> 
> This fixes the ICE for me, can you see if it fixes it for you too?

I can confirm that the ice seems to have gone away for this 
test case only.

You'd have to check the entire gcc test suite to be sure, however.

[Bug target/47091] non-elf arm targets fail to build

[amylaar at gcc dot gnu.org]

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

--- Comment #5 from Jorn Wolfgang Rennecke  
2010-12-29 17:34:21 UTC ---
(In reply to comment #3)
> Joern, can you create a meta-bug to track the various non-building target
> configurations?  It would be nice to have a single place for an overview
> (and a possible list of targets to deprecate).

I've created PR47093 for that.
When the build merely hit a -werror-always issue, I made the PR block 44756,
and PR 44756 blocks PR47093.
Of course, a --enable-werror-always issue might mask a hard failure later on.

[Bug fortran/46838] [OOP] Initialization of polymorphic allocatable components

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #9 from janus at gcc dot gnu.org 2010-12-29 17:04:02 UTC ---
(In reply to comment #8)
> ToDo: The array version (cf. comment #1) still ICEs:

This is now being tracked by PR 43969, therefore I'm closing this one.

[Bug fortran/43969] [OOP] ALLOCATED() with polymorphic arrays

[janus at gcc dot gnu.org]

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

--- Comment #9 from janus at gcc dot gnu.org 2010-12-29 17:02:24 UTC ---
Here is another test case from PR46838 comment #8:

  implicit none

  type indx_map
  end type

  type desc_type
class(indx_map), allocatable :: indxmap(:)
  end type

  type(desc_type)  :: desc
  if (allocated(desc%indxmap)) call abort()

end

[Bug ada/46704] [4.6 Regression] Ada compiler fails to build itself

[laurent at guerby dot net]

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

--- Comment #4 from Laurent GUERBY  2010-12-29 
16:51:43 UTC ---
Look like .Ldebug_info0 symbol handling changed recently:

2010-11-13  Iain Sandoe  

* dwarf2out.c (macinfo_entry): New struct.
(output_comp_unit): Emit the section start label here and flag that we
will emit an info section.
(dwarf2out_start_source_file): Save data in a macinfo entry rather than
emitting directly.
(dwarf2out_end_source_file): Likewise.
(dwarf2out_define): Likewise.
(dwarf2out_undef): Likewise.
(output_macinfo): New.
(dwarf2out_init): Do not emit debug section switches here, allocate a
vec for macinfo, when required.
(dwarf2out_finish): First switch to debug_abbrev_section here.
debug_line_section,  debug_macinfo_section, Likewise.
Check that the pubtypes table has at least one unpruned entry before
trying to emit it.

[Bug target/47122] New: vax-*-openbsd* configuration purports to require openbsd-pthread.h

[amylaar at gcc dot gnu.org]

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

   Summary: vax-*-openbsd* configuration purports to require
openbsd-pthread.h
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: amyl...@gcc.gnu.org
Blocks: 47093
  Host: x86_64-pc-linux-gnu
Target: vax-openbsd


make[2]: *** No rule to make target
`../../../gcc/gcc/config/openbsd-pthread.h', needed by `c-lang.o'.  Stop.

The vax-*-openbsd*) case in config.gcc refers to openbsd-pthread.h;
for all I know, that might be what the file is called, but its name is
openbsd-libpthread.h .  (To continue with the "HADDOCKS' EYES" analogy,
that name is called a basename; the file has also the name
$(srcdir)/config/openbsd-libpthread.h, which is called a pathname,
and the file is just a few comments and a #define .)

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

[ebotcazou at gcc dot gnu.org]

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

--- Comment #8 from Eric Botcazou  2010-12-29 
16:40:47 UTC ---
> Proposed fix posted to the mailing list:
> 
> http://gcc.gnu.org/ml/gcc-patches/2010-12/msg01912.html

Thanks a lot!

[Bug fortran/44232] function result with pointer to strided component of argument

[dfranke at gcc dot gnu.org]

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

Daniel Franke  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||WORKSFORME

[Bug ada/46704] [4.6 Regression] Ada compiler fails to build itself

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2010.12.29 16:35:46
 AssignedTo|unassigned at gcc dot   |ebotcazou at gcc dot
   |gnu.org |gnu.org
 Ever Confirmed|0   |1

--- Comment #3 from Eric Botcazou  2010-12-29 
16:35:46 UTC ---
Investigating.

[Bug ada/46704] [4.6 Regression] Ada compiler fails to build itself

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||laurent at guerby dot net

--- Comment #2 from Eric Botcazou  2010-12-29 
16:34:30 UTC ---
*** Bug 47121 has been marked as a duplicate of this bug. ***

[Bug ada/47121] [4.6 Regression] [Ada] c,ada compiler unable to rebootstrap itself once installed due to missing .Ldebug_info0 symbol at link of stage1 gnat1

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #2 from Eric Botcazou  2010-12-29 
16:34:30 UTC ---
Already reported.

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

[Bug ada/46704] [4.6 Regression] Ada compiler fails to build itself

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||amylaar at gcc dot gnu.org

--- Comment #1 from Eric Botcazou  2010-12-29 
16:34:01 UTC ---
*** Bug 46741 has been marked as a duplicate of this bug. ***

[Bug ada/46741] bootstrap with bootstrapped compiler fails

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #1 from Eric Botcazou  2010-12-29 
16:34:01 UTC ---
Already reported.

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

[Bug ada/46704] [4.6 Regression] Ada compiler fails to build itself

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

   Keywords||link-failure
 Target|arm-linux-gnueabi   |
 CC||ebotcazou at gcc dot
   ||gnu.org
   Target Milestone|--- |4.6.0
Summary|ada bootstrap failure on|[4.6 Regression] Ada
   |arm-linux-gnueabi   |compiler fails to build
   ||itself

[Bug fortran/46838] [OOP] Initialization of polymorphic allocatable components

[janus at gcc dot gnu.org]

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

--- Comment #8 from janus at gcc dot gnu.org 2010-12-29 16:30:47 UTC ---
r168322 fixes the original test case as well as the reduction in comment #1.

ToDo: The array version (cf. comment #1) still ICEs:


  implicit none

  type indx_map
  end type

  type desc_type
class(indx_map), allocatable :: indxmap(:)
  end type

  type(desc_type)  :: desc
  if (allocated(desc%indxmap)) call abort()

end



internal compiler error: in gfc_conv_descriptor_data_get, at
fortran/trans-array.c:144

[Bug fortran/44232] function result with pointer to strided component of argument

[Thomas.L.Clune at nasa dot gov]

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

--- Comment #14 from tlcclt  2010-12-29 
16:30:31 UTC ---
Sorry - yes.  This bug report can be closed.I did eventually  
install a more recent version of the compiler and verified that the  
problem was not present.   Had long forgotten about this ticket though.



On Dec 28, 2010, at 12:55 PM, dfranke at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44232
>
> Daniel Franke  changed:
>
>   What|Removed |Added
> 
> Status|UNCONFIRMED |WAITING
>   Last reconfirmed||2010.12.28 17:55:10
> CC||dfranke at gcc dot  
> gnu.org
> Ever Confirmed|0   |1
>
> --- Comment #13 from Daniel Franke   
> 2010-12-28 17:55:10 UTC ---
> Anything new here or can this report be closed?
>
> -- 
> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
> --- You are receiving this mail because: ---
> You reported the bug.

Thomas Clune
Software Integration and Visualization Office
NASA GSFC (610.3)
301-286-4635 (W)301-286-1775 (F)

[Bug c++/47108] enum won't use long long as underlying type

[flo.ruijt at hotmail dot com]

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

--- Comment #3 from Floris Ruijter  2010-12-29 
16:24:54 UTC ---
On Wed, 2010-12-29 at 13:18 +, pinskia at gmail dot com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47108
> 
> --- Comment #1 from pinskia at gmail dot com  
> 2010-12-29 13:18:40 UTC ---
> enum {  a=1<<33 }blaf; 
> That is still an int as 1 is of type int. Try 1ll<<33.
> 
can your please send plaintext mail.
indeed it works then. i find the behaviour pretty obscure though, why is
it that way?

Floris

[Bug ada/47005] [4.6 Regression] ACATS c62002a is miscompiled at -O2

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #3 from Eric Botcazou  2010-12-29 
16:22:50 UTC ---
Investigating.

[Bug ada/47121] [4.6 Regression] [Ada] c,ada compiler unable to rebootstrap itself once installed due to missing .Ldebug_info0 symbol at link of stage1 gnat1

[laurent at guerby dot net]

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

--- Comment #1 from Laurent GUERBY  2010-12-29 
16:21:04 UTC ---
Note: c only bootstrap succeeds when following the same protocol.

[Bug ada/47121] New: [4.6 Regression] [Ada] c,ada compiler unable to rebootstrap itself once installed due to missing .Ldebug_info0 symbol at link of stage1 gnat1

[laurent at guerby dot net]

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

   Summary: [4.6 Regression] [Ada] c,ada compiler unable to
rebootstrap itself once installed due to missing
.Ldebug_info0 symbol at link of stage1 gnat1
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: link-failure
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: laur...@guerby.net
CC: ebotca...@gcc.gnu.org


First bootstrap trunk r168316 with c,ada using system gcc 4.3 as bootstrap
compiler, then install r168316, then put in PATH the newly installed compiler
then redo a bootstrap of trunk r168316 with c,ada in a clean directory (and a
different --prefix).

The second bootstrap fails in stage1 on missing symbols:

gcc -static-libgcc  -o gnat1 ada/b_gnat1.o ada/adadecode.o ada/adaint.o
ada/cstreams.o ada/cio.o ada/targtyps.o ada/decl.o ada/misc.o ada/utils.o
ada/utils2.o ada/trans.o ada/cuintp.o ada/argv.o ada/raise.o ada/init.o
ada/tracebak.o ada/initialize.o ada/env.o ada/a-charac.o ada/a-chlat1.o
ada/a-elchha.o ada/a-except.o ada/a-ioexce.o ada/ada.o ada/ali.o ada/alloc.o
ada/aspects.o ada/atree.o ada/butil.o ada/casing.o ada/checks.o ada/comperr.o
ada/csets.o ada/cstand.o ada/debug.o ada/debug_a.o ada/einfo.o ada/elists.o
ada/err_vars.o ada/errout.o ada/erroutc.o ada/eval_fat.o ada/exp_aggr.o
ada/exp_atag.o ada/exp_attr.o ada/exp_cg.o ada/exp_ch11.o ada/exp_ch12.o
ada/exp_ch13.o ada/exp_ch2.o ada/exp_ch3.o ada/exp_ch4.o ada/exp_ch5.o
ada/exp_ch6.o ada/exp_ch7.o ada/exp_ch8.o ada/exp_ch9.o ada/exp_code.o
ada/exp_dbug.o ada/exp_disp.o ada/exp_dist.o ada/exp_fixd.o ada/exp_imgv.o
ada/exp_intr.o ada/exp_pakd.o ada/exp_prag.o ada/exp_sel.o ada/exp_smem.o
ada/exp_strm.o ada/exp_tss.o ada/exp_util.o ada/exp_vfpt.o ada/expander.o
ada/fmap.o ada/fname-uf.o ada/fname.o ada/freeze.o ada/frontend.o
ada/g-byorma.o ada/g-hesora.o ada/g-htable.o ada/g-spchge.o ada/g-speche.o
ada/g-u3spch.o ada/get_scos.o ada/get_targ.o ada/gnat.o ada/gnatvsn.o ada/hlo.o
ada/hostparm.o ada/impunit.o ada/inline.o ada/interfac.o ada/itypes.o
ada/krunch.o ada/layout.o ada/lib-load.o ada/lib-util.o ada/lib-writ.o
ada/lib-xref.o ada/lib.o ada/live.o ada/namet-sp.o ada/namet.o ada/nlists.o
ada/nmake.o ada/opt.o ada/osint-c.o ada/osint.o ada/output.o ada/par.o
ada/par_sco.o ada/prep.o ada/prepcomp.o ada/put_scos.o ada/repinfo.o
ada/restrict.o ada/rident.o ada/rtsfind.o ada/s-addope.o ada/s-assert.o
ada/s-bitops.o ada/s-carun8.o ada/s-casuti.o ada/s-conca2.o ada/s-conca3.o
ada/s-conca4.o ada/s-conca5.o ada/s-conca6.o ada/s-conca7.o ada/s-conca8.o
ada/s-conca9.o ada/s-crc32.o ada/s-crtl.o ada/s-except.o ada/s-exctab.o
ada/s-htable.o ada/s-imenne.o ada/s-imgenu.o ada/s-mastop.o ada/s-memory.o
ada/s-os_lib.o ada/s-parame.o ada/s-purexc.o ada/s-restri.o ada/s-secsta.o
ada/s-soflin.o ada/s-sopco3.o ada/s-sopco4.o ada/s-sopco5.o ada/s-stache.o
ada/s-stalib.o ada/s-stoele.o ada/s-strcom.o ada/s-strhas.o ada/s-string.o
ada/s-strops.o ada/s-traceb.o ada/s-traent.o ada/s-unstyp.o ada/s-utf_32.o
ada/s-wchcnv.o ada/s-wchcon.o ada/s-wchjis.o ada/scans.o ada/scil_ll.o
ada/scn.o ada/scng.o ada/scos.o ada/sdefault.o ada/seh_init.o ada/sem.o
ada/sem_aggr.o ada/sem_attr.o ada/sem_aux.o ada/sem_case.o ada/sem_cat.o
ada/sem_ch10.o ada/sem_ch11.o ada/sem_ch12.o ada/sem_ch13.o ada/sem_ch2.o
ada/sem_ch3.o ada/sem_ch4.o ada/sem_ch5.o ada/sem_ch6.o ada/sem_ch7.o
ada/sem_ch8.o ada/sem_ch9.o ada/sem_disp.o ada/sem_dist.o ada/sem_elab.o
ada/sem_elim.o ada/sem_eval.o ada/sem_intr.o ada/sem_mech.o ada/sem_prag.o
ada/sem_res.o ada/sem_scil.o ada/sem_smem.o ada/sem_type.o ada/sem_util.o
ada/sem_vfpt.o ada/sem_warn.o ada/sinfo-cn.o ada/sinfo.o ada/sinput-d.o
ada/sinput-l.o ada/sinput.o ada/snames.o ada/sprint.o ada/stand.o ada/stringt.o
ada/style.o ada/styleg.o ada/stylesw.o ada/switch-c.o ada/switch.o ada/system.o
ada/table.o ada/targext.o ada/targparm.o ada/tbuild.o ada/tree_gen.o
ada/tree_in.o ada/tree_io.o ada/treepr.o ada/treeprs.o ada/ttypes.o ada/types.o
ada/uintp.o ada/uname.o ada/urealp.o ada/usage.o ada/validsw.o ada/widechar.o
ada/back_end.o ada/gnat1drv.o prefix.o main.o tree-browser.o libbackend.a
../libcpp/libcpp.a ../libdecnumber/libdecnumber.a attribs.o ../libcpp/libcpp.a 
 ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a
-L/opt/cfarm/gmp-4.2.4/lib -L/opt/cfarm/mpfr-2.4.1/lib -L/opt/cfarm/mpc-0.8/lib
-lmpc -lmpfr -lgmp -rdynamic -ldl  -L../zlib -lz -g -fkeep-inline-functions
ada/a-charac.o:(.debug_aranges+0x6): undefined reference to `.Ldebug_info0'
ada/ada.o:(.debug_aranges+0x6): undefined reference to `.Ldebug_info0'
ada/alloc.o:(.debug_aranges+0x6): undefined reference to `.Ldebug_info0'
ada/g-htable.o:(.debug_aranges+0x6): undefined reference to `.Ldebug_info0'
ada/g-spchge.o:(.debug_aranges+0x6): undefined reference to `.Ldebug_info0'
ada/get_scos.o:(.debug_aranges+0x6): more undefined refere

[Bug middle-end/47092] [4.6 Regression] gfortran.fortran-torture/execute/forall_4.f90 is VERY slow with -fgraphite-identity

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Target Milestone|--- |4.6.0

[Bug fortran/46838] [OOP] Initialization of polymorphic allocatable components

[janus at gcc dot gnu.org]

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

--- Comment #7 from janus at gcc dot gnu.org 2010-12-29 16:14:20 UTC ---
Author: janus
Date: Wed Dec 29 16:14:11 2010
New Revision: 168322

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168322
Log:
2010-12-29  Janus Weil  

PR fortran/46838
* expr.c (gfc_default_initializer): Handle allocatable CLASS components.


2010-12-29  Janus Weil  

PR fortran/46838
* gfortran.dg/alloc_comp_class_2.f90: New.

Added:
trunk/gcc/testsuite/gfortran.dg/alloc_comp_class_2.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/expr.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/47033] loop distribution has problems on sane testcases

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.12.29 16:12:57
 Ever Confirmed|0   |1

--- Comment #3 from Richard Guenther  2010-12-29 
16:12:57 UTC ---
Loop distribution shouldn't fail if loop header copying was applied and it
would
be nice to know why it does.

[Bug target/47091] non-elf arm targets fail to build

[joseph at codesourcery dot com]

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

--- Comment #4 from joseph at codesourcery dot com  2010-12-29 16:11:10 UTC ---
On Wed, 29 Dec 2010, rguenth at gcc dot gnu.org wrote:

> (and a possible list of targets to deprecate).

I gave my own suggestions for deprecations in 
 - there are some 
overlaps with the non-building targets (Interix, some a.out BSD, crosses 
to alpha*-dec-osf5.1* without GNU as don't build).

[Bug libobjc/47031] libobjc uses mutexes for properties

[nicola at gcc dot gnu.org]

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

--- Comment #2 from Nicola Pero  2010-12-29 16:10:51 
UTC ---
I'm actually not very convinced by this any more; we probably need some
benchmarks. ;-)

The problem is that property accessors are basically general purpose routines
that may be used in the most varied situations.

So, we have very little control or knowledge over when and how they are used --

 * we don't know how many CPUs or cores the user has

 * we don't know how many threads the user is starting

 * we don't know how many threads are sharing a CPU or core

 * we don't know how intensively the user is using the property accessors

Spinlocks are appropriate when certain conditions are met; but in this case,
it seems impossible to be confident that these are met.  A user may write a
program with 3 or 4 threads running on his 1 CPU/core machine, which constantly
read/write an atomic synthesized property to synchronize between themselves. 
Why not; but then, spinlocks would actually degrade performance instead of
improving it.

Traditional locks may be slower if you a low contention case, but work
consistently OK in all conditions.

For me, the key problem is that:

 * spinlocks are better/faster if there is low contention and very little
chance that two threads enter the critical region (inside the accessors) at the
same time.

 * the difference in performance between mutexes and spinlocks only matters in
the program performance if the accessors are called very often.

But these two things conflict with each other ;-)

For example, if a spinlock makes the accessor 2x as fast as with a mutex, but
the program only spends 0.1% of its time calling the accessors, then the
difference in performance on the whole program would be of the order of 0.05%;
then, we prefer a mutex since the performance is more consistent and it has no
"worst-case" scenarios.

If the program spends more (say, 10%) of its time calling the accessors, then
the difference in performance would matter (it would be something like 5%), but
because the program is spending so much time in accessors, if the program is
multi-threaded there is high contention, and spinlocks don't perform well any
more - in fact, the worst-case scenarios (where lots of CPU is wasted spinning
and making no progress) may appear. (keep in mind that as we're sharing locks
across different objects/properties, even if the different threads are calling
accessors of different objects/properties, the locks would still be contended).

The only case where spinlocks really help is if the program spends lots of time
calling accessors, and is not multi-threaded.  In which case, the programmer
could get a huge speed-up by simply declaring the properties non-atomic.

So, I'm not sure there is a good case for spinlocks.

It may be good to try some benchmarks to get a feeling for the difference in
performance between mutexes and spinlocks.  Would using spinlocks make
accessors 2x faster ? 10x faster ? 10% faster ?

Thanks

[Bug target/47120] -malign-double does not align doubles in function calls

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Target||i?86-*-*
 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX

--- Comment #1 from Richard Guenther  2010-12-29 
16:06:54 UTC ---
We can't change this now.

frontend bug?

[Alex Turjan]

Hi all,
Im compiling the code bellow for x86 with gcc 4.4.3 and 4.5. Is it correct
that at the end of main the value of variable b should have been 4? When 
executing I get value 3. 

#include "stdio.h"
int *ptr;

int inc(void){
(*ptr)++;
return 1;
}

int main (void){
int a, b = 2;
ptr = &b;
b++ +  inc() ;

if(b==4)
printf("correct\n");
else
printf("incorrect %d\n",b);
return 1;
}



  

[Bug target/47091] non-elf arm targets fail to build

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther  2010-12-29 
16:02:12 UTC ---
Joern, can you create a meta-bug to track the various non-building target
configurations?  It would be nice to have a single place for an overview
(and a possible list of targets to deprecate).

[Bug fortran/47082] [OOP] ICE in gfc_conv_component_ref

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.12.29 15:58:51
 Ever Confirmed|0   |1

--- Comment #2 from janus at gcc dot gnu.org 2010-12-29 15:58:51 UTC ---
I have stared at this problem for a while now, but I'm still puzzled about its
origin. All I could come up with is this ad-hoc patch:

Index: gcc/fortran/trans-expr.c
===
--- gcc/fortran/trans-expr.c(revision 168301)
+++ gcc/fortran/trans-expr.c(working copy)
@@ -6085,6 +6085,7 @@ gfc_trans_class_init_assign (gfc_code *code)

   rhs = gfc_copy_expr (code->expr1);
   gfc_add_vptr_component (rhs);
+  gfc_get_derived_type (rhs->ts.u.derived);
   gfc_add_def_init_component (rhs);

   sz = gfc_copy_expr (code->expr1);


This does not solve the problem fully, but it reduces it to PR46448:

/tmp/cc9UG1CN.s: Assembler messages:
/tmp/cc9UG1CN.s:65: Error: symbol `__copy_m0_t0_' is already defined

[Bug ada/47005] [4.6 Regression] ACATS c62002a is miscompiled at -O2

[laurent at guerby dot net]

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

--- Comment #2 from Laurent GUERBY  2010-12-29 
15:56:24 UTC ---
As of r168294 C62002A:

-O0: PASS 
-O1: PASS
-O2: FAIL
-O3: FAIL

On gcc56 PATH=/home/guerby/install-trunk-168294/bin:$PATH
if you want access to a compiler, the test is gnatchopped in /home/guerby/tmp.

[Bug target/47120] New: -malign-double does not align doubles in function calls

[pip88nl at gmail dot com]

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

   Summary: -malign-double does not align doubles in function
calls
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pip8...@gmail.com


According to the gcc manual, -malign-double creates object code with an ABI
that is incompatible to code that was not compiled with that switch. With this
switch, structs containing doubles are aligned correctly (according to double's
alignment requirements) but doubles passed to functions are not. E.g.:

  void foo (int i, double d);
  int main () {
foo (1, 2);
return 0;
  }

On x86, this will emit code storing the double value of 2.0 to a word-aligned
stack location, not a double-word aligned location, as the manual implies.

I suppose the reason for not aligning doubles on a two word boundary in this
instance is that it would, in addition to the struct ABI, break the x86 calling
convention. However, not aligning the double correctly will make code fail that
requires aligned access.

[Bug ada/47005] [4.6 Regression] ACATS c62002a is miscompiled at -O2

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.12.29 15:45:07
 CC||ebotcazou at gcc dot
   ||gnu.org
Summary|[4.6 Regression] ACATS  |[4.6 Regression] ACATS
   |c62002a wrong code on   |c62002a is miscompiled at
   |arm-linux   |-O2
 Ever Confirmed|0   |1

--- Comment #1 from Eric Botcazou  2010-12-29 
15:45:07 UTC ---
Does it also fail at lower optimization levels?

[Bug objc/47075] Missed deprecation warnings for @property when using getter/setter directly

[nicola at gcc dot gnu.org]

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

Nicola Pero  changed:

   What|Removed |Added

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

--- Comment #3 from Nicola Pero  2010-12-29 15:32:59 
UTC ---
Fixed in trunk.

Thanks

[Bug objc/47076] Protocol referenced in @interface declarations should be defined

[nicola at gcc dot gnu.org]

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

Nicola Pero  changed:

   What|Removed |Added

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

--- Comment #3 from Nicola Pero  2010-12-29 15:32:10 
UTC ---
Fixed in trunk.

Thanks

[Bug target/47119] New: sh-symbianelf: symbian-base.o won't build

[amylaar at gcc dot gnu.org]

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

   Summary: sh-symbianelf: symbian-base.o won't build
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: amyl...@gcc.gnu.org
Blocks: 47093
  Host: x86_64-pc-linux-gnu
Target: sh-symbianelf


gcc -c  -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -g -O2 -DIN_GCC
-DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wwrite-strings -Wcast-qual
-Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror
-Wold-style-definition -Wc++-compat -fno-common  -DHAVE_CONFIG_H -I. -I.
-I../../../gcc/gcc -I../../../gcc/gcc/. -I../../../gcc/gcc/../include
-I../../../gcc/gcc/../libcpp/include -I/opt/cfarm/mpc/include 
-I../../../gcc/gcc/../libdecnumber -I../../../gcc/gcc/../libdecnumber/dpd
-I../libdecnumber-I. -I. -I../../../gcc/gcc -I../../../gcc/gcc/.
-I../../../gcc/gcc/../include -I../../../gcc/gcc/../libcpp/include
-I/opt/cfarm/mpc/include  -I../../../gcc/gcc/../libdecnumber
-I../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber  
../../../gcc/gcc/config/sh/symbian-base.c
In file included from ../../../gcc/gcc/config/sh/symbian-base.c:27:0:
../../../gcc/gcc/rtl.h:22:9: error: attempt to use poisoned "GCC_RTL_H"
In file included from ../../../gcc/gcc/config/sh/symbian-base.c:28:0:
../../../gcc/gcc/output.h:588:50: error: ISO C forbids forward references to
‘enum’ types [-Werror=edantic]
../../../gcc/gcc/output.h:590:10: error: ‘enum machine_mode’ declared inside
parameter list [-Werror]
../../../gcc/gcc/output.h:590:10: error: its scope is only this definition or
declaration, which is probably not what you want [-Werror]
../../../gcc/gcc/output.h:627:50: error: ISO C forbids forward references to
‘enum’ types [-Werror=edantic]
../../../gcc/gcc/output.h:628:10: error: ‘enum machine_mode’ declared inside
parameter list [-Werror]
../../../gcc/gcc/output.h:629:54: error: ISO C forbids forward references to
‘enum’ types [-Werror=edantic]
../../../gcc/gcc/output.h:630:7: error: ‘enum machine_mode’ declared inside
parameter list [-Werror]
In file included from ../../../gcc/gcc/config/sh/symbian-base.c:31:0:
../../../gcc/gcc/expr.h:22:9: error: attempt to use poisoned "GCC_EXPR_H"
../../../gcc/gcc/config/sh/symbian-base.c: In function
‘sh_symbian_is_dllexported’:
../../../gcc/gcc/config/sh/symbian-base.c:70:12: error: identifier ‘class’
conflicts with C++ keyword [-Werror=c++-compat]
../../../gcc/gcc/config/sh/symbian-base.c:72:11: error: identifier ‘class’
conflicts with C++ keyword [-Werror=c++-compat]
../../../gcc/gcc/config/sh/symbian-base.c: In function
‘sh_symbian_mark_dllimport’:
../../../gcc/gcc/config/sh/symbian-base.c:104:3: error: implicit declaration of
function ‘XEXP’ [-Werror=implicit-function-declaration]
../../../gcc/gcc/config/sh/symbian-base.c:104:11: error: assignment makes
pointer from integer without a cast [-Werror]
../../../gcc/gcc/config/sh/symbian-base.c:105:3: error: implicit declaration of
function ‘MEM_P’ [-Werror=implicit-function-declaration]
../../../gcc/gcc/config/sh/symbian-base.c:106:13: error: assignment makes
pointer from integer without a cast [-Werror]
../../../gcc/gcc/config/sh/symbian-base.c:107:3: error: implicit declaration of
function ‘GET_CODE’ [-Werror=implicit-function-declaration]
../../../gcc/gcc/config/sh/symbian-base.c:107:3: error: ‘SYMBOL_REF’ undeclared
(first use in this function)
../../../gcc/gcc/config/sh/symbian-base.c:107:3: note: each undeclared
identifier is reported only once for each function it appears in
../../../gcc/gcc/config/sh/symbian-base.c:108:3: error: implicit declaration of
function ‘XSTR’ [-Werror=implicit-function-declaration]
../../../gcc/gcc/config/sh/symbian-base.c:108:11: error: assignment makes
pointer from integer without a cast [-Werror]
../../../gcc/gcc/config/sh/symbian-base.c:132:7: error: implicit declaration of
function ‘gen_rtx_SYMBOL_REF’ [-Werror=implicit-function-declaration]
../../../gcc/gcc/config/sh/symbian-base.c:132:14: error: assignment makes
pointer from integer without a cast [-Werror]
../../../gcc/gcc/config/sh/symbian-base.c:133:13: error: lvalue required as
left operand of assignment
../../../gcc/gcc/config/sh/symbian-base.c: In function
‘sh_symbian_mark_dllexport’:
../../../gcc/gcc/config/sh/symbian-base.c:148:11: error: assignment makes
pointer from integer without a cast [-Werror]
../../../gcc/gcc/config/sh/symbian-base.c:150:13: error: assignment makes
pointer from integer without a cast [-Werror]
../../../gcc/gcc/config/sh/symbian-base.c:151:3: error: ‘SYMBOL_REF’ undeclared
(first use in this function)
../../../gcc/gcc/config/sh/symbian-base.c:152:11: error: assignment makes
pointer from integer without a cast [-Werror]
../../../gcc/gcc/config/sh/symbian-base.c:179:32: 

[Bug fortran/31059] Detect nonconforming assignment of allocatable arrays

[dfranke at gcc dot gnu.org]

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

--- Comment #6 from Daniel Franke  2010-12-29 
15:22:47 UTC ---
*** Bug 34741 has been marked as a duplicate of this bug. ***

[Bug fortran/34741] Bounds-check of array-pointer == [ constructor ]

[dfranke at gcc dot gnu.org]

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

Daniel Franke  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dfranke at gcc dot gnu.org
 Resolution||DUPLICATE

--- Comment #2 from Daniel Franke  2010-12-29 
15:22:47 UTC ---
Same as the other.

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

[Bug fortran/31059] Detect nonconforming assignment of allocatable arrays

[dfranke at gcc dot gnu.org]

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

--- Comment #5 from Daniel Franke  2010-12-29 
15:22:44 UTC ---
*** Bug 32454 has been marked as a duplicate of this bug. ***

[Bug fortran/32454] Bounds-check misses overflow of lhs array

[dfranke at gcc dot gnu.org]

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

Daniel Franke  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dfranke at gcc dot gnu.org
 Resolution||DUPLICATE

--- Comment #4 from Daniel Franke  2010-12-29 
15:22:44 UTC ---
Same as the other.

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

[Bug objc/47118] ICE on incorrect parameter to @synchronized()

[nicola at gcc dot gnu.org]

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

Nicola Pero  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.12.29 15:21:12
 Ever Confirmed|0   |1

--- Comment #1 from Nicola Pero  2010-12-29 15:21:12 
UTC ---
Confirmed on trunk, 29 December 2010.

Thanks

[Bug objc/47118] New: ICE on incorrect parameter to @synchronized()

[nicola at gcc dot gnu.org]

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

   Summary: ICE on incorrect parameter to @synchronized()
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: objc
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nic...@gcc.gnu.org


Here is a testcase that crashes GCC 4.6 --

typedef struct { float x; float y; } point;

int test (id object)
{
  point x;
  @synchronized (x)
{
  return 1;
}
}

The compiler is not checking the type of the argument of @synchronized() and is
not dealing with unexpected types correctly.

Thanks

[Bug fortran/45619] intent(out) dummy arguements in specification statements

[dfranke at gcc dot gnu.org]

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

Daniel Franke  changed:

   What|Removed |Added

 CC||dfranke at gcc dot gnu.org

--- Comment #1 from Daniel Franke  2010-12-29 
14:53:07 UTC ---
See also: PR28004.

[Bug fortran/28004] Warn if intent(out) dummy variable is used before being defined

[dfranke at gcc dot gnu.org]

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

--- Comment #11 from Daniel Franke  2010-12-29 
14:52:48 UTC ---
Also related: PR45619.

[Bug target/47117] New: unfulfillable case in config.gcc

[amylaar at gcc dot gnu.org]

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

   Summary: unfulfillable case in config.gcc 
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: amyl...@gcc.gnu.org
Blocks: 47093


The config.gcc target case label list:

sh-*-elf* | sh[12346l]*-*-elf* | \
sh-*-symbianelf* | sh[12346l]*-*-symbianelf* | \
  sh-*-linux* | sh[2346lbe]*-*-linux* | \
  sh-*-netbsdelf* | shl*-*-netbsdelf* | sh5-*-netbsd* | sh5l*-*-netbsd* | \
   sh64-*-netbsd* | sh64l*-*-netbsd*)

has a subcase:

case ${target} in
sh5*-*-netbsd*)
# SHmedia, 32-bit ABI
tmake_file="${tmake_file} sh/t-sh64 sh/t-netbsd"
;;
sh64*-netbsd*)
# SHmedia, 64-bit ABI
tmake_file="${tmake_file} sh/t-sh64 sh/t-netbsd
sh/t-netbsd-sh5-64"
;;
*-*-netbsd)
tmake_file="${tmake_file} sh/t-netbsd"
;;
...
The latter case label is never reached, because all netbsd configurations
either
start with sh5 or sh64, or end with netbsdelf.

[Bug c++/47116] Linking error: multiple definition of `non-virtual thunk to ...'

[silver24k at gmail dot com]

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

--- Comment #1 from Yu Simin  2010-12-29 14:35:31 
UTC ---
Created attachment 22866
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22866
sources

[Bug c++/47116] New: Linking error: multiple definition of `non-virtual thunk to ...'

[silver24k at gmail dot com]

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

   Summary: Linking error: multiple definition of `non-virtual
thunk to ...'
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: silver...@gmail.com


When compiling attached sources, I get:
$ g++ -O2 -c test0.cpp
$ g++ -O2 -c test1.cpp
$ g++ -o test.exe test0.o test1.o
test1.o:test1.cpp:(.text+0x0): multiple definition of `non-virtual thunk to
FooBase::Bar()'
test0.o:test0.cpp:(.text+0x0): first defined here
collect2: ld returned 1 exit status

Changing -O2 to -O0 or -O1 does not help.

Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=c:/snowfishroot/mingw/bin/../libexec/gcc/mingw32/4.6.0/lto-wrapper.exe
Target: mingw32
Configured with: ../../../gcc_trunk/configure --build=x86_64-unknown-linux-gnu
--host=mingw32 --target=mingw32 --prefix=/mingw --disable-win32-registry
--enable-shared --enable-static --enable-libgomp
--enable-version-specific-runtime-libs --with-gmp=/mingw --with-mpfr=/mingw
--with-ppl=/mingw --with-cloog=/mingw --enable-libstdcxx-debug
--with-build-time-tools=/platform/cross-on-linux/mingw --disable-nls
--with-mpc=/mingw --enable-languages=c,c++ --enable-lto --disable-plugin
--enable-checking=release --enable-sjlj-exceptions
Thread model: win32
gcc version 4.6.0 20101228 (experimental)
COMPILER_PATH=c:/snowfishroot/mingw/bin/../libexec/gcc/mingw32/4.6.0/;c:/snowfishroot/mingw/bin/../libexec/gcc/;c:/snowfishroot/mingw/bin/../lib/gcc/mingw32/4.6.0/../../../../mingw32/bin/
LIBRARY_PATH=c:/snowfishroot/mingw/bin/../lib/gcc/mingw32/4.6.0/;c:/snowfishroot/mingw/bin/../lib/gcc/;c:/snowfishroot/mingw/bin/../lib/gcc/mingw32/4.6.0/../../../../mingw32/lib/;c:/snowfishroot/mingw/bin/../lib/gcc/mingw32/4.6.0/../../../
COLLECT_GCC_OPTIONS='-v' '-o' 'test.exe' '-shared-libgcc' '-mtune=generic'
'-march=pentiumpro'
 c:/snowfishroot/mingw/bin/../libexec/gcc/mingw32/4.6.0/collect2.exe -Bdynamic
-o test.exe c:/snowfishroot/mingw/bin/../lib/gcc/mingw32/4.6.0/../../../crt2.o
c:/snowfishroot/mingw/bin/../lib/gcc/mingw32/4.6.0/crtbegin.o
-Lc:/snowfishroot/mingw/bin/../lib/gcc/mingw32/4.6.0
-Lc:/snowfishroot/mingw/bin/../lib/gcc
-Lc:/snowfishroot/mingw/bin/../lib/gcc/mingw32/4.6.0/../../../../mingw32/lib
-Lc:/snowfishroot/mingw/bin/../lib/gcc/mingw32/4.6.0/../../.. test0.o test1.o
-lstdc++ -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt -ladvapi32
-lshell32 -luser32 -lkernel32 -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex
-lmsvcrt c:/snowfishroot/mingw/bin/../lib/gcc/mingw32/4.6.0/crtend.o
test1.o:test1.cpp:(.text+0x0): multiple definition of `non-virtual thunk to
FooBase::Bar()'
test0.o:test0.cpp:(.text+0x0): first defined here
collect2: ld returned 1 exit status

[Bug fortran/47051] [4.6 Regression] wrong reallocate

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||jakub at gcc dot gnu.org

[Bug target/47115] New: aix52.h,aix53.h,aix61.h declare host functions

[amylaar at gcc dot gnu.org]

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

   Summary: aix52.h,aix53.h,aix61.h declare host functions
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: amyl...@gcc.gnu.org
Blocks: 47093
  Host: x86_64-pc-linux-gnu
Target: rs6000-ibm-aix5.2.0, rs6000-ibm-aix5.3.0,
rs6000-ibm-aix6.0


In file included from ./tm.h:17:0,
 from ../../../gcc/gcc/target.h:52,
 from ../../../gcc/gcc/go/gofrontend/export.cc:17:
../../../gcc/gcc/config/rs6000/aix52.h:188:43: error: declaration of ‘long long
int atoll(const char*)’ has a different exception specifier
/usr/include/stdlib.h:298:1: error: from previous declaration ‘long long int
atoll(const char*) throw ()’
make[2]: *** [go/export.o] Error 1

[Bug target/47107] ix86-netware is recognized by config.guess, but has no valid basic_machine set

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  2010-12-29 14:07:50 UTC ---
This is a bug in config.gcc; it should just accept i[34567]86 like other 
x86 targets, not ix86.

[Bug c++/47108] enum won't use long long as underlying type

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  2010-12-29 
13:53:56 UTC ---
Yeah, invalid.

[Bug tree-optimization/47074] [4.6 Regression] tree check fail in create_access_replacement

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2010.12.29 13:51:25
 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #3 from Jakub Jelinek  2010-12-29 
13:51:25 UTC ---
Created attachment 22865
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22865
gcc46-pr47074.patch

This fixes the ICE for me, can you see if it fixes it for you too?

[Bug target/47114] New: powerpc-wrs-vxworks: rs6000_elf_asm_out_{con,de}structor defined but not used

[amylaar at gcc dot gnu.org]

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

   Summary: powerpc-wrs-vxworks:
rs6000_elf_asm_out_{con,de}structor defined but not
used
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: amyl...@gcc.gnu.org
Blocks: 44756
  Host: x86_64-pc-linux-gnu
Target: powerpc-wrs-vxworks


../../../gcc/gcc/config/rs6000/rs6000.c:25576:1: error:
‘rs6000_elf_asm_out_constructor’ defined but not used [-Werror=unused-function]
../../../gcc/gcc/config/rs6000/rs6000.c:25605:1: error:
‘rs6000_elf_asm_out_destructor’ defined but not used [-Werror=unused-function]
cc1: all warnings being treated as errors

make[2]: *** [rs6000.o] Error 1

[Bug target/17994] avr-gcc does not output a dwarf2 .debug_frame section

[anitha.boyapati at atmel dot com]

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

--- Comment #6 from Anitha Boyapati  
2010-12-29 13:35:34 UTC ---
(In reply to comment #4)

> Looks like to get call-stack debug info, all we require to do is define
> INCOMING_RETURN_ADDR_RTX. In AVR, since the return address is pushed onto the
> stack for every call instruction, the above hook is defined to
> avr_incoming_return_addr_rtx() of dwarf2out.c:
> 
> rtx
> avr_incoming_return_addr_rtx(void) {
> 
> return gen_rtx_MEM (HImode, stack_pointer_rtx);
> }
> 
> And this gives an ICE in dwarf2out_frame_debug_expr(). Modifying the above
> function to pre decrement the stack pointer gives an ICE in
> initial_return_save()
> 

The reason for ICE is that POST_DEC is not handled in
dwarf2out_frame_debug_expr(). Fixing that issue will enable the compiler to
generate the call-stack debug info.

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

#simple testcase:
void foo(){ return ;}
int main() { foo(); return 1; }


The output of .debug_frame section for the above testcase(just assembled):

 0010  CIE
  Version:   1
  Augmentation:  ""
  Code alignment factor: 1
  Data alignment factor: -1
  Return address column: 36

  DW_CFA_def_cfa: r32 ofs 2
  DW_CFA_offset: r36 at cfa+0
  DW_CFA_nop
  DW_CFA_nop

0014 0014  FDE cie= pc=..000e
  DW_CFA_advance_loc: 4 to 0004
  DW_CFA_offset: r28 at cfa+0
  DW_CFA_advance_loc: 4 to 0008
  DW_CFA_def_cfa_register: r28
  DW_CFA_nop
  DW_CFA_nop

002c 0014  FDE cie= pc=000e..0022
  DW_CFA_advance_loc: 4 to 0012
  DW_CFA_offset: r28 at cfa+0
  DW_CFA_advance_loc: 4 to 0016
  DW_CFA_def_cfa_register: r28
  DW_CFA_nop
  DW_CFA_nop

Comments on correctness appreciated :)

[Bug c++/47108] enum won't use long long as underlying type

[pinskia at gmail dot com]

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

--- Comment #1 from pinskia at gmail dot com  
2010-12-29 13:18:40 UTC ---
enum {  a=1<<33 }blaf; 
That is still an int as 1 is of type int. Try 1ll<<33.

[Bug go/47113] New: go_field_alignment: field set but not used

[amylaar at gcc dot gnu.org]

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

   Summary: go_field_alignment: field set but not used
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: go
AssignedTo: i...@airs.com
ReportedBy: amyl...@gcc.gnu.org
Blocks: 44756
  Host: x86_64-pc-linux-gnu
Target: powerpc64-darwin


../../../gcc/gcc/go/go-backend.c: In function ‘go_field_alignment’:
../../../gcc/gcc/go/go-backend.c:56:10: error: variable ‘field’ set but not
used [-Werror=unused-but-set-variable]
cc1: all warnings being treated as errors

[Bug target/47112] New: mipstx39-elf

[amylaar at gcc dot gnu.org]

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

   Summary: mipstx39-elf
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: amyl...@gcc.gnu.org
Blocks: 44756
  Host: x86_64-pc-linux-gnu
Target: mipstx39-*-elf*: Redefined target macros


In file included from ./tm.h:18:0,
 from ../../../gcc/gcc/gensupport.c:24:
../../../gcc/gcc/config/mips/r3900.h:24:0: error: "MIPS_CPU_STRING_DEFAULT"
redefined [-Werror]
../../../gcc/gcc/config/mips/mips.h:583:0: note: this is the location of the
previous definition
../../../gcc/gcc/config/mips/r3900.h:27:0: error: "MULTILIB_DEFAULTS" redefined
[-Werror]
../../../gcc/gcc/config/mips/mips.h:681:0: note: this is the location of the
previous definition
../../../gcc/gcc/config/mips/r3900.h:30:0: error: "MIPS_ABI_DEFAULT" redefined
[-Werror]
../../../gcc/gcc/config/mips/mips.h:655:0: note: this is the location of the
previous definition
../../../gcc/gcc/config/mips/r3900.h:33:0: error: "SUBTARGET_CC1_SPEC"
redefined [-Werror]
../../../gcc/gcc/config/mips/mips.h:1164:0: note: this is the location of the
previous definition
cc1: all warnings being treated as errors

make[2]: *** [build/gensupport.o] Error 1

[Bug target/47111] New: mips-rtems: redefinition of NO_IMPLICIT_EXTERN_C

[amylaar at gcc dot gnu.org]

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

   Summary: mips-rtems: redefinition of NO_IMPLICIT_EXTERN_C
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: amyl...@gcc.gnu.org
Blocks: 44756
  Host: x86_64-pc-linux-gnu
Target: mips-rtems


In file included from ./tm.h:20:0,
 from ../../../gcc/gcc/gensupport.c:24:
../../../gcc/gcc/config/rtems.h:21:0: error: "NO_IMPLICIT_EXTERN_C" redefined
[-Werror]
../../../gcc/gcc/config/mips/elf.h:51:0: note: this is the location of the
previous definition
cc1: all warnings being treated as errors

make[2]: *** [build/gensupport.o] Error 1

[Bug target/47110] New: mips-openbsd mips.o build fails for lack of ASM_OUTPUT_DEF definition

[amylaar at gcc dot gnu.org]

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

   Summary: mips-openbsd mips.o build fails for lack of
ASM_OUTPUT_DEF definition
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: amyl...@gcc.gnu.org
Blocks: 47093
  Host: x86_64-pc-linux-gnu
Target: mips-openbsd


../../../gcc/gcc/config/mips/mips.c: In function ‘mips16_build_function_stub’:
../../../gcc/gcc/config/mips/mips.c:6097:3: error: implicit declaration of
function ‘ASM_OUTPUT_DEF’ [-Werror=implicit-function-declaration]
cc1: all warnings being treated as errors

make[2]: *** [mips.o] Error 1

[Bug target/47109] New: m68k-netbsdelf: collect2 build fails with undefined reference to m68k_cpu_flags

[amylaar at gcc dot gnu.org]

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

   Summary: m68k-netbsdelf: collect2 build fails with undefined
reference to m68k_cpu_flags
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: amyl...@gcc.gnu.org
Blocks: 47093
  Host: x86_64-pc-linux-gnu
Target: m68k-netbsdelf


collect2.o: In function `main':
/home/amylaar/pr46489/branch8/multi-mk7/m68k-netbsdelf/gcc/../../../gcc/gcc/collect2.c:1687:
undefined reference to `m68k_cpu_flags'
collect2: ld returned 1 exit status
make[2]: *** [collect2] Error 1

[Bug objc/47075] Missed deprecation warnings for @property when using getter/setter directly

[nicola at gcc dot gnu.org]

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

--- Comment #2 from Nicola Pero  2010-12-29 12:22:13 
UTC ---
Author: nicola
Date: Wed Dec 29 12:22:09 2010
New Revision: 168315

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168315
Log:
In gcc/c-family/:
2010-12-29  Nicola Pero  

PR objc/47075
* c-objc.h (objc_finish_message_expr): Added argument to
prototype.

In gcc/objc/:
2010-12-29  Nicola Pero  

PR objc/47075
* objc-act.h (PROPERTY_REF_DEPRECATED_GETTER): New.
* objc-tree.def (PROPERTY_REF): Increased the number of operands
from 3 to 4.
* objc-act.c (objc_finish_message_expr): Added optional argument
allowing to return the deprecated method prototype for deprecated
methods, instead of immediately emitting the deprecation warning.
(objc_maybe_build_component_ref): Do not warn for a deprecated
property.  When building the getter call, get the deprecated
method prototype from objc_finish_message_expr() and put it into
the PROPERTY_REF.
(objc_build_class_component_ref): Same change.
(finish_class): Mark the getter and setter as deprecated if they
are generated from a deprecated property.
(objc_gimplify_property_ref): If the getter is deprecated, emit a
deprecation warning.
(objc_build_setter_call, objc_build_message_expr,
objc_finish_foreach_loop): Updated call to
objc_finish_message_expr.

In gcc/objcp/:
2010-12-29  Nicola Pero  

* objcp-lang.c (objcp_tsubst_copy_and_build): Update call to
objc_finish_message_expr.

In gcc/testsuite/:
2010-12-29  Nicola Pero  

PR objc/47075
* objc.dg/property/at-property-deprecated-1.m: Updated.
* objc.dg/property/at-property-deprecated-2.m: New.
* objc.dg/property/dotsyntax-deprecated-1.m: New.
* obj-c++.dg/property/at-property-deprecated-1.mm: Updated.
* obj-c++.dg/property/at-property-deprecated-2.mm: New.
* obj-c++.dg/property/dotsyntax-deprecated-1.mm: New.

Added:
trunk/gcc/testsuite/obj-c++.dg/property/at-property-deprecated-2.mm
trunk/gcc/testsuite/obj-c++.dg/property/dotsyntax-deprecated-1.mm
trunk/gcc/testsuite/objc.dg/property/at-property-deprecated-2.m
trunk/gcc/testsuite/objc.dg/property/dotsyntax-deprecated-1.m
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-objc.h
trunk/gcc/objc/ChangeLog
trunk/gcc/objc/objc-act.c
trunk/gcc/objc/objc-act.h
trunk/gcc/objc/objc-tree.def
trunk/gcc/objcp/ChangeLog
trunk/gcc/objcp/objcp-lang.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/obj-c++.dg/property/at-property-deprecated-1.mm
trunk/gcc/testsuite/objc.dg/property/at-property-deprecated-1.m

[Bug c++/47108] New: enum won't use long long as underlying type

[flo.ruijt at hotmail dot com]

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

   Summary: enum won't use long long as underlying type
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: flo.ru...@hotmail.com


c++0x introduce long long, which should be used as the base type for enum if on
of the enumerators doesn't fit in int, 7.2.6:

  For an enumeration whose underlying type is not fixed, the underlying type is
an integral type that can
6
  represent all the enumerator values defined in the enumeration. If no
integral type can represent all the
  enumerator values, the enumeration is ill-formed. It is
implementation-defined which integral type is used
  as the underlying type except that the underlying type shall not be larger
than int unless the value of an
  enumerator cannot fit in an int or unsigned int. If the enumerator-list is
empty, the underlying type is
  as if the enumeration had a single enumerator with value 0.

the folowing program demonstrates the bug, note that gcc does give a warning:

#include 
int main(){
enum{ waf=1<<33 }blaf;
std::cout<

[Bug target/47107] New: ix86-netware is recognized by config.guess, but has no valid basic_machine set

[amylaar at gcc dot gnu.org]

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

   Summary: ix86-netware is recognized by config.guess, but has no
valid basic_machine set
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: amyl...@gcc.gnu.org
Blocks: 47093
  Host: x86_64-pc-linux-gnu
Target: ix86-netware


gawk -f ../../../gcc/gcc/opt-gather.awk
../../../gcc/gcc/ada/gcc-interface/lang.opt ../../../gcc/gcc/fortran/lang.opt
../../../gcc/gcc/go/lang.opt ../../../gcc/gcc/java/lang.opt
../../../gcc/gcc/lto/lang.opt ../../../gcc/gcc/c-family/c.opt
../../../gcc/gcc/common.opt  > tmp-optionlist
make[2]: *** No rule to make target `../../../gcc/gcc/config/ix86/ix86.h',
needed by `c-lang.o'.  Stop.
make[2]: *** Waiting for unfinished jobs

[Bug c/47102] error message "duplicate member" in error ?

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #2 from Joseph S. Myers  2010-12-29 
11:44:07 UTC ---
Not a bug.

[Bug c/47102] error message "duplicate member" in error ?

[jsm28 at gcc dot gnu.org]

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

--- Comment #1 from Joseph S. Myers  2010-12-29 
11:43:20 UTC ---
The diagnostic is correct; the code is invalid; C1X requires this to be
diagnosed; it is ambiguous whether "page" refers to an element directly in the
struct or one accessed via the anonymous union therein.  See bug 4784.

[Bug debug/47106] New: -fcompare-debug failure (length) with -fpartial-inlining -flto -fconserve-stack

[zsojka at seznam dot cz]

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

   Summary: -fcompare-debug failure (length) with
-fpartial-inlining -flto -fconserve-stack
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
CC: aol...@gcc.gnu.org
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


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

Compiler output:
$ gcc -O -fpartial-inlining -flto -fconserve-stack -fcompare-debug pr47106.C 
gcc: error: pr47106.C: -fcompare-debug failure (length)

Different code is generated with and without -g.

Tested revisions:
r168296 - fail

[Bug target/47103] i386 options have multi-line descriptions

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  2010-12-29 11:26:09 UTC ---
On Wed, 29 Dec 2010, goeran at uddeborg dot se wrote:

> In gcc/config/i386/i386.opt there are multi-line descriptions of the options
> mvzeroupper and mdispatch-scheduler.  Only the first line is picked up fro
> translation, and according to bug 34352, comment 1, it is a bug for those 
> files
> to have multi-line descriptions.

Multi-line descriptions don't appear to be mentioned in doc/options.texi, 
but if they are to be considered invalid then the opt*.awk code really 
ought to reject them rather than combining the lines (and if they are 
valid, they should be documented and po/exgettext should support them).