[Bug debug/48459] [4.6/4.7 Regression] avr: Assertion failure with -gdwarf-2

[anitha.boyapati at atmel dot com]

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

--- Comment #30 from Anitha Boyapati  
2011-06-17 07:07:34 UTC ---
Created attachment 24552
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24552
Make log for gcc-4_6-branch for comment 28

(In reply to comment #29)
> Works For Me.
> 
> [rth@anchor bld-avr-46]$ size avr/avr25/libgcc/_lshrdi3.o
>text   databssdechexfilename
> 244  0  0244 f4   
> avr/avr25/libgcc/_lshrdi3.o


I have clean built multiple times now and it fails all the times with the same
message. I have got atleast one response in avr-gcc-list reporting the same
error. Also attached the log. Can you double check if dwarf2 is enabled?

svn entries file -

dir
175135
http://gcc.gnu.org/svn/gcc/branches/gcc-4_6-branch
http://gcc.gnu.org/svn/gcc

---
http://lists.gnu.org/archive/html/avr-gcc-list/2011-06/msg00034.html

[Bug libmudflap/49449] New: -fmudflapth -lmudflapth problems with -fvisibility=hidden, missing posix_memalign wrapper and pointers in varargs

[pcpa at mandriva dot com.br]

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

   Summary: -fmudflapth -lmudflapth problems with
-fvisibility=hidden, missing posix_memalign wrapper
and pointers in varargs
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: libmudflap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: p...@mandriva.com.br


These are just issues I found when attempting
to use mudflap:
o Mudflap fails to find symbol main in a test
  application due to propagating -fvisibility=hidden
  in CFLAGS.
o The code also uses posix_memalign to allocate
  memory on 16 bytes boundaries, what causes a
  massive amount of violation warnings.
o It tells about faults when receiving pointers as
  arguments to a varargs function.

  Overall I adapted the code I did want to test,
so this is just a suggestion for enhancement. At
least adding a posix_memalign wrapper should be
trivial, but not sure about the others. Tested
on x86_64 gcc version 4.6.0 20110610.

[Bug other/49448] gcc configure script wrongly detect TARGET_BIG_ENDIAN_DEFAULT

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

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

--- Comment #1 from Andreas Schwab  2011-06-17 07:26:12 
UTC ---
It should use $target_cpu.

[Bug tree-optimization/49442] [4.5/4.6/4.7 Regression] Misaligned store support pessimization

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  2011-06-17 
08:15:38 UTC ---
ICC apparently has __assume_aligned (ptr, align) for this, and also
#pragma vector {aligned,unaligned,always,nontemporal}.
For alignment, I'd say having both hard alignment and likely alignment hints
somewhere in the code would be better than ptr_align attribute on the
arguments,
so something like
__builtin_assume_aligned (ptr, align[, misalign])
and
__builtin_likely_aligned (ptr, align[, misalign]);
would be helpful.  The question is if they shouldn't return the pointer again,
and let the user write it in the form
ptr = __builtin_assume_aligned (ptr, 16);
which would be optimized away when we compute the alignment.

[Bug rtl-optimization/44194] struct returned by value generates useless stores

[rguenther at suse dot de]

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

--- Comment #28 from rguenther at suse dot de  
2011-06-17 08:21:30 UTC ---
On Thu, 16 Jun 2011, eraman at google dot com wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
> 
> --- Comment #27 from Easwaran Raman  2011-06-16 
> 17:14:38 UTC ---
> (In reply to comment #26)
> > On Wed, 15 Jun 2011, xinliangli at gmail dot com wrote:
> > 
> > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
> > > 
> > > davidxl  changed:
> > > 
> > >What|Removed |Added
> > > 
> > >  CC||xinliangli at gmail dot 
> > > com
> > > 
> > > --- Comment #23 from davidxl  2011-06-15 
> > > 23:14:50 UTC ---
> > > (In reply to comment #22)
> > > > > The DSE patch still leaves 2 redundant stores.
> > > > 
> > > > OK, I missed this, reopening...
> > > > 
> > > > > The following patch will enable DSE to remove those two stores. Does 
> > > > > this
> > > > > look ok?
> > > > 
> > > > Calling into the gimplifier from the RTL expander doesn't look 
> > > > appropriate.
> > 
> > It also should use create_tmp_var, not create_tmp_reg.  But I wonder why
> > memory allocated via assign_temp isn't marked in a way to let dse
> > do its job (I guess dse thinks that memory escapes?).
> If the mem rtx doesn't have a tree_expression associated with it, DSE assumes
> the memory escapes.

Hmm, ok.  I guess it can't really do better.

> > > > More fundamentally, it's a little unfortunate to spill to memory a value
> > > > returned in registers.  Can we try to use emit_group_move_into_temps 
> > > > here
> > > > instead (under the appropriate circumstances)?
> > > 
> > > It would be nice if the expander does not spill the return into memory in 
> > > the
> > > first place if possible.  On other hand tagging compiler created memory
> > > location with temp decls so that aliaser has the symbolic information 
> > > seems a
> > > useful mechanism. 
> > 
> > Sure - but I wonder why assign_temp doesn't do something equivalent
> > that doesn't require a automatic VAR_DECL to be created.
> > 
> > Where does the aliaser catch things with the VAR_DECL around that
> > it doesn't without it?
> 
> Is it just that when I create a VAR_DECL, TREE_ADDRESSABLE is false and
> may_be_aliased returns true?

false, yes.

Richard.

[Bug libgcj/49315] Throw_2 SEGVs on Tru64 UNIX

[ro at gcc dot gnu.org]

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

--- Comment #1 from Rainer Orth  2011-06-17 08:33:17 UTC 
---
Author: ro
Date: Fri Jun 17 08:33:13 2011
New Revision: 175138

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175138
Log:
PR libgcj/49315
* include/solaris-signal.h: Rename to ...
* include/posix-signal.h: ... this.
(SA_FLAGS): Define.
(SIGNAL_HANDLER): Handle non-SA_SIGINFO case.
(sa_signal_handler): Define.
(_INIT_SIG_HANDLER): New macro.
(INIT_SEGV, INIT_FPE): Use it.
* configure.ac (SIGNAL_HANDLER): Use it on alpha*-dec-osf*,
mips-sgi-irix*, *-*-solaris2*
* configure: Regenerate.
* include/aix-signal.h: Refer to AIX.
* configure.host (alpha*-dec-osf*): Enable can_unwind_signal.
(mips-sgi-irix6*): Likewise.

Added:
trunk/libjava/include/posix-signal.h
  - copied, changed from r175137, trunk/libjava/include/solaris-signal.h
Removed:
trunk/libjava/include/solaris-signal.h
Modified:
trunk/libjava/ChangeLog
trunk/libjava/configure
trunk/libjava/configure.ac
trunk/libjava/configure.host
trunk/libjava/include/aix-signal.h

[Bug libgcj/49315] Throw_2 SEGVs on Tru64 UNIX

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Target|alpha-dec-osf5.1b   |alpha-dec-osf5.1b
   ||mips-sgi-irix6.5
 Status|UNCONFIRMED |RESOLVED
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2011-06/msg01239.htm
   ||l
   Host|alpha-dec-osf5.1b   |alpha-dec-osf5.1b,
   ||mips-sgi-irix6.5
 AssignedTo|unassigned at gcc dot   |ro at gcc dot gnu.org
   |gnu.org |
 Resolution||FIXED
   Target Milestone|--- |4.7.0
  Build|alpha-dec-osf5.1b   |alpha-dec-osf5.1b
   ||mips-sgi-irix6.5

--- Comment #2 from Rainer Orth  2011-06-17 08:36:17 UTC 
---
Fixed for 4.7.0, also fixes the same problem on IRIX 6.5.

[Bug fortran/47516] testsuite failure: realloc_on_assign_2.f03 (with --disable-bootstrap)

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED

--- Comment #6 from Tobias Burnus  2011-06-17 
08:59:44 UTC ---
Close as fixed as a patch has been committed. I assume, no one can reproduce it
any more?

[Bug libmudflap/49449] -fmudflapth -lmudflapth problems with -fvisibility=hidden, missing posix_memalign wrapper and pointers in varargs

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 CC||fche at redhat dot com

--- Comment #1 from Richard Guenther  2011-06-17 
09:03:13 UTC ---
The mudflap code is unfortunately completely unmaintained.

[Bug libstdc++/49445] Undefined reference to std::atomic "operator float"

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2011.06.17 09:04:32
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2011-06-17 
09:04:32 UTC ---
Testcase?

[Bug tree-optimization/49444] IV-OPTs changes an unaligned loads into aligned loads incorrectly

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Guenther  2011-06-17 
09:06:22 UTC ---
(In reply to comment #3)
> Something like this:
> Index: tree-ssa-loop-ivopts.c
> ===
> --- tree-ssa-loop-ivopts.c(revision 61384)
> +++ tree-ssa-loop-ivopts.c(working copy)
> @@ -6066,6 +6066,8 @@ rewrite_use_address (struct ivopts_data
>tree base_hint = NULL_TREE;
>tree ref, iv;
>bool ok;
> +  unsigned align;
> +  tree type;
> 
>adjust_iv_update_pos (cand, use);
>ok = get_computation_aff (data->current_loop, use, cand, use->stmt, &aff);
> @@ -6087,7 +6089,10 @@ rewrite_use_address (struct ivopts_data
>  base_hint = var_at_stmt (data->current_loop, cand, use->stmt);
> 
>iv = var_at_stmt (data->current_loop, cand, use->stmt);
> -  ref = create_mem_ref (&bsi, TREE_TYPE (*use->op_p), &aff,
> +  align = get_object_alignment (*use->op_p, BIGGEST_ALIGNMENT);
> +  type = TREE_TYPE (*use->op_p);
> +  type = build_aligned_type (type, align);
> +  ref = create_mem_ref (&bsi, type, &aff,
>  reference_alias_ptr_type (*use->op_p),
>  iv, base_hint, data->speed);
>copy_ref_info (ref, *use->op_p);

Well, that will then still run into the indirect-ref issue as
the expansion for target-mem-refs and mem-refs works the same way.
Only targets that support movmisalign will generate unaligned
loads (which targets currently only define for vector modes I think).

[Bug tree-optimization/49361] [4.7 Regression] Huge 470.lbm regression

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #5 from Richard Guenther  2011-06-17 
09:11:27 UTC ---
Fixed.

[Bug libstdc++/49445] Undefined reference to std::atomic "operator float"

[raskolnikov at gnu dot org]

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

--- Comment #2 from Juan Pedro Bolívar Puente  
2011-06-17 09:35:29 UTC ---
Created attachment 24553
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24553
Test case for the "undefined reference" on atom bug

raskolnikov@nexus9:~$ make CXXFLAGS=-std=c++0x test_atom
g++ -std=c++0xtest_atom.cpp   -o test_atom
/tmp/ccS68VP3.o: In function `main':
test_atom.cpp:(.text+0x18): undefined reference to
`std::atomic::operator float() const'
collect2: ld returned 1 exit status
make: *** [test_atom] Error 1

[Bug libgcj/49314] md5test, shatest output FAILs on Tru64 UNIX

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE  2011-06-17 09:56:50 UTC ---
As a quick hack, I've just removed the definition of HAVE_ICONV and
rebuilt libgcj.so.  This way, testsuite results are clean.

I'll have to further investigate (preferably with a small C program)
what's going on here.

Rainer

[Bug ada/48835] Porting GNAT to GNU/Linux/m68k

[mikpe at it dot uu.se]

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

--- Comment #14 from Mikael Pettersson  2011-06-17 
10:02:21 UTC ---
Partial success: I've just managed to bootstrap gcc-4.1.2 w/ gnat on
m68k-linux.  Lots of patches applied though.

[Bug c++/49450] New: not possible to call explicit destructor of std::string

[jwillemsen at remedy dot nl]

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

   Summary: not possible to call explicit destructor of
std::string
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jwillem...@remedy.nl


We want to use C++0x unions with a std::string as member (see for example
http://www2.research.att.com/~bs/C++0xFAQ.html#unions). At the moment we want
to call the ~string we get an error.

Reproducer:

#include 

int main ()
{
std::string s;
s.~string();
return 0;
}

message

g++-4.6 -c t.cpp
t.cpp: In function ‘int main()’:
t.cpp:6:11: error: expected class-name before ‘(’ token

[Bug rtl-optimization/48542] mmix code which calls setjmp/longjmp may not work.

[hp at gcc dot gnu.org]

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

--- Comment #10 from Hans-Peter Nilsson  2011-06-17 
11:13:42 UTC ---
Author: hp
Date: Fri Jun 17 11:13:38 2011
New Revision: 175139

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175139
Log:
PR rtl-optimization/48542
* reload.c (find_equiv_reg): Stop looking when finding a
setjmp-type call.
* reload1.c (reload_as_needed): Invalidate all reload
registers when crossing a setjmp-type call.

Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/reload.c
branches/gcc-4_6-branch/gcc/reload1.c

[Bug rtl-optimization/48542] mmix code which calls setjmp/longjmp may not work.

[hp at gcc dot gnu.org]

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

--- Comment #11 from Hans-Peter Nilsson  2011-06-17 
11:15:39 UTC ---
Author: hp
Date: Fri Jun 17 11:15:35 2011
New Revision: 175140

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175140
Log:
PR rtl-optimization/48542
* gcc.dg/torture/pr48542.c: New test.

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

[Bug rtl-optimization/48542] mmix code which calls setjmp/longjmp may not work.

[hp at gcc dot gnu.org]

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

--- Comment #12 from Hans-Peter Nilsson  2011-06-17 
11:17:37 UTC ---
Author: hp
Date: Fri Jun 17 11:17:34 2011
New Revision: 175141

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175141
Log:
PR rtl-optimization/48542
* reload.c (find_equiv_reg): Stop looking when finding a
setjmp-type call.
* reload1.c (reload_as_needed): Invalidate all reload
registers when crossing a setjmp-type call.

Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/reload.c
branches/gcc-4_5-branch/gcc/reload1.c

[Bug rtl-optimization/48542] mmix code which calls setjmp/longjmp may not work.

[hp at gcc dot gnu.org]

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

--- Comment #13 from Hans-Peter Nilsson  2011-06-17 
11:18:39 UTC ---
Author: hp
Date: Fri Jun 17 11:18:37 2011
New Revision: 175142

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175142
Log:
PR rtl-optimization/48542
* gcc.dg/torture/pr48542.c: New test.

Added:
branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/torture/pr48542.c
Modified:
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/48542] mmix code which calls setjmp/longjmp may not work.

[hp at gcc dot gnu.org]

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

--- Comment #14 from Hans-Peter Nilsson  2011-06-17 
11:20:05 UTC ---
Author: hp
Date: Fri Jun 17 11:20:01 2011
New Revision: 175144

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175144
Log:
PR rtl-optimization/48542
* reload.c (find_equiv_reg): Stop looking when finding a
setjmp-type call.
* reload1.c (reload_as_needed): Invalidate all reload
registers when crossing a setjmp-type call.

Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/reload.c
branches/gcc-4_4-branch/gcc/reload1.c

[Bug rtl-optimization/48542] mmix code which calls setjmp/longjmp may not work.

[hp at gcc dot gnu.org]

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

--- Comment #15 from Hans-Peter Nilsson  2011-06-17 
11:20:41 UTC ---
Author: hp
Date: Fri Jun 17 11:20:38 2011
New Revision: 175145

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175145
Log:
PR rtl-optimization/48542
* gcc.dg/torture/pr48542.c: New test.

Added:
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/torture/pr48542.c
Modified:
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog

[Bug target/43603] gcc-4.4.3 ICE on ia64 with -O3

[devurandom at gmx dot net]

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

--- Comment #22 from devurandom at gmx dot net 2011-06-17 11:21:02 UTC ---
(In reply to comment #20)
> Created attachment 24112 [details]
> backported patch
> 
> Good.  Then attached is the initial backport, I have just verified that it
> passes the testcase.  It would be great if the Gentoo folks could test it in
> their setup, too.  If all goes well, I will apply it to 4_4-branch at the
> beginning of May.
Is this applied to any branch yet?

[Bug rtl-optimization/48542] mmix code which calls setjmp/longjmp may not work.

[hp at gcc dot gnu.org]

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

--- Comment #16 from Hans-Peter Nilsson  2011-06-17 
11:24:57 UTC ---
Author: hp
Date: Fri Jun 17 11:24:55 2011
New Revision: 175146

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175146
Log:
PR rtl-optimization/48542
* reload.c (find_equiv_reg): Stop looking when finding a
setjmp-type call.
* reload1.c (reload_as_needed): Invalidate all reload
registers when crossing a setjmp-type call.

Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/reload.c
branches/gcc-4_3-branch/gcc/reload1.c

[Bug rtl-optimization/48542] mmix code which calls setjmp/longjmp may not work.

[hp at gcc dot gnu.org]

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

--- Comment #17 from Hans-Peter Nilsson  2011-06-17 
11:25:56 UTC ---
Author: hp
Date: Fri Jun 17 11:25:53 2011
New Revision: 175147

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175147
Log:
PR rtl-optimization/48542
* gcc.dg/torture/pr48542.c: New test.

Added:
branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/torture/pr48542.c
Modified:
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/49115] [4.5/4.6 Regression] invalid return value optimization (?) when exception is thrown and caught

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Guenther  2011-06-17 
11:27:41 UTC ---
Author: rguenth
Date: Fri Jun 17 11:27:37 2011
New Revision: 175148

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175148
Log:
2011-06-17  Richard Guenther  

Backport from mainline
2011-05-23  Richard Guenther  

PR tree-optimization/49115
* tree-ssa-alias.c (stmt_kills_ref_p_1): If the assignment
is not necessarily carried out, do not claim it kills the ref.
* tree-ssa-dce.c (mark_aliased_reaching_defs_necessary_1): Likewise.

* g++.dg/torture/pr49115.C: New testcase.

Added:
branches/gcc-4_6-branch/gcc/testsuite/g++.dg/torture/pr49115.C
Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
branches/gcc-4_6-branch/gcc/tree-ssa-alias.c
branches/gcc-4_6-branch/gcc/tree-ssa-dce.c

[Bug c++/49450] not possible to call explicit destructor of std::string

[jwillemsen at remedy dot nl]

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

--- Comment #1 from Johnny Willemsen  2011-06-17 
11:32:51 UTC ---
g++-4.6 (SUSE Linux) 4.6.0 20110505 [gcc-4_6-branch revision 173419]
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug rtl-optimization/48542] unchanged variables in code which calls setjmp may be clobbered (including the return-address)

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|4.7.0   |4.3.6
Summary|mmix code which calls   |unchanged variables in code
   |setjmp/longjmp may not  |which calls setjmp may be
   |work.   |clobbered (including the
   ||return-address)

--- Comment #18 from Hans-Peter Nilsson  2011-06-17 
11:38:05 UTC ---
Fixed on all open branches. Plus title change to reflect the general nature of
the bug. Actually s/variables/registers/ but let's keep it user-friendly when
we can.

[Bug libstdc++/49445] Undefined reference to std::atomic "operator float"

[marc.glisse at normalesup dot org]

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

Marc Glisse  changed:

   What|Removed |Added

 CC||marc.glisse at normalesup
   ||dot org

--- Comment #3 from Marc Glisse  2011-06-17 
11:43:16 UTC ---
It looks like C++11 only defines atomic and atomic, so a
link-time error on atomic seems ok, no?

[Bug libgcj/49451] New: FileHandleGcTest FAILS on IRIX

[ro at gcc dot gnu.org]

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

   Summary: FileHandleGcTest FAILS on IRIX
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcj
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
CC: tro...@gcc.gnu.org, a...@gcc.gnu.org, hans.bo...@hp.com
  Host: mips-sgi-irix6.5
Target: mips-sgi-irix6.5
 Build: mips-sgi-irix6.5


The FileHandleGcTest FAILS on IRIX 6.5 (both N32 and N64 ABIs):

FAIL: FileHandleGcTest execution - source compiled test
FAIL: FileHandleGcTest -findirect-dispatch execution - source compiled test
FAIL: FileHandleGcTest -O3 execution - source compiled test
FAIL: FileHandleGcTest -O3 -findirect-dispatch execution - source compiled test

In the log, I find:

/proc open failed

This message is ultimately from boehm-gc/dyn_load.c
(GC_register_dynamic_libraries) or boehm-gc/os_dep.c (GC_dirty_init).  I had to
add a discriminator to the message to find it's the former.  Running the test
under par, I find

 1061mS[  3]FileHandleGcTest(69051502): open("/dev/null", O_RDONLY, 0666) =
1023
 1062mS[  3]FileHandleGcTest(69051502): open("/dev/null", O_RDONLY, 0666) errno 
= 24 (Too many open files)
 1063mS[  3]FileHandleGcTest(69051502): open("/proc/69051502", O_RDONLY, 0)
errn
o = 24 (Too many open files)
 1063mS[  3]FileHandleGcTest(69051502): write(2, "/proc open failed\n", 18) =
18
open 1056  0.07 72.78

When in gnu/java/nio/channels/natFileChannelPosix.cc (FileChannelImpl::open) an
open call fails, the code runs

  ::java::lang::System::gc ();
  ::java::lang::System::runFinalization ();

to try and free fds.  Unfortunately, in boehm-gc
(GC_register_dynamic_libraries)
an attempt is made to open /proc/, which of course fails and calls
abort().

This doesn't happen on either Solaris or Tru64 UNIX because those use their
own implementations of GC_register_dynamic_libraries which don't need
additional file descriptors.

I guess something similar can be implemented on IRIX, using __rld_obj_head 
described in rld(5).  I''ll probably give it a try.

[Bug tree-optimization/49452] New: New testsuite failures with arm-linux-gnueabi comp-goto failing with

[ramana at gcc dot gnu.org]

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

   Summary: New testsuite failures with arm-linux-gnueabi
comp-goto failing with
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ram...@gcc.gnu.org
  Host: i686-linux-gnu
Target: arm-linux-gnueabi


These failures have shown up in the last few days with arm-linux-gnueabi 

FAIL: gcc.c-torture/execute/comp-goto-2.c execution,  -O2 
FAIL: gcc.c-torture/execute/comp-goto-2.c execution,  -O3 -fomit-frame-pointer 
FAIL: gcc.c-torture/execute/comp-goto-2.c execution,  -O3 -g 
FAIL: gcc.c-torture/execute/comp-goto-2.c execution,  -Os 
FAIL: gcc.c-torture/execute/comp-goto-2.c execution,  -O2 -flto
-flto-partition=none 
FAIL: gcc.c-torture/execute/comp-goto-2.c execution,  -O2 -flto 


I haven't looked at in great detail yet to analyse what causes this problem but
it appears to have appeared in the last week or so.



GCC was configured as : 

--target=arm-none-linux-gnueabi --enable-languages=c,c++,fortran
--with-cpu=cortex-a9 --with-fpu=neon --with-float=softfp


cheers
Ramana

[Bug tree-optimization/49452] New testsuite failures with arm-linux-gnueabi comp-goto failing with

[ramana at gcc dot gnu.org]

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

--- Comment #1 from Ramana Radhakrishnan  2011-06-17 
12:02:10 UTC ---
One of the differences I must say I noticed is that at O2 - the call to y has a
NORETURN attribute marked to it but there's no reason why this should be marked
as NORETURN - surely there is a flow of control that allows control to go out
of the function. 


x(a)
{
  __label__ xlab;
  void y(a)
{
  void *x = &&llab;
  if (a==-1)
 goto *x;
  if (a==0)
 goto xlab;
llab:
  y (a-1);
}
  y (a);
 xlab:;
  return a;
}




(call_insn/c/i 11 10 12 3 (parallel [
(call (mem:SI (symbol_ref:SI ("y.2104") [flags 0x3]  ) [0 y S4 A32])
(const_int 0 [0]))
(use (const_int 0 [0]))
(clobber (reg:SI 14 lr))
])
/home/ramrad01/sources/fsf/trunk/gcc/testsuite/gcc.c-torture/execute/comp-goto-2.c:23
-1
 (expr_list:REG_NORETURN (const_int 0 [0])
(expr_list:REG_EH_REGION (const_int 0 [0])
(nil)))
(expr_list:REG_DEP_TRUE (use (reg:SI 0 r0))
(expr_list:REG_DEP_TRUE (use (reg:SI 12 ip))
(nil

[Bug libstdc++/49445] Undefined reference to std::atomic "operator float"

[marc.glisse at normalesup dot org]

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

--- Comment #4 from Marc Glisse  2011-06-17 
12:07:53 UTC ---
(In reply to comment #3)
> It looks like C++11 only defines atomic and atomic, so a
> link-time error on atomic seems ok, no?

Sorry, please ignore the above comment, I should have read the standard
properly before posting.

[Bug java/49441] @LDLIBICONV@ lost from installed libgcj.spec

[howarth at nitro dot med.uc.edu]

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

--- Comment #3 from Jack Howarth  2011-06-17 
12:50:52 UTC ---
How is gcj supposed to properly find its linkage libraries on x86_64 linux when
using -m32? Since only a single copy of libgcj.spec is installed and used for
both the default -m64 and -m32, this seems impossible to handle both via that
mechanism (ie passing -L/usr/lib64 -liconv for -m64  and -L/usr/lib -liconv for
-m32). It seems much better to simply drop @LDLIBICONV@ entirely from
libgcj,spec.in and move @LDLIBICONV@ onto the linkage of libgcj itself (since
it seems to be the only place were the iconv symbols are generated or used).

[Bug libgcj/49314] md5test, shatest output FAILs on Tru64 UNIX

[dominiq at lps dot ens.fr]

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

--- Comment #7 from Dominique d'Humieres  2011-06-17 
13:04:17 UTC ---
Could this pr be related to pr49441?

[Bug java/49441] @LDLIBICONV@ lost from installed libgcj.spec

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  2011-06-17 
13:05:33 UTC ---
PR49314 reports also problems with iconv and java.

[Bug libgcj/49314] md5test, shatest output FAILs on Tru64 UNIX

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE  2011-06-17 13:09:06 UTC ---
> --- Comment #7 from Dominique d'Humieres  
> 2011-06-17 13:04:17 UTC ---
> Could this pr be related to pr49441?

No: the iconv functions only live in libiconv (no stubs in libc), and
that is present in libgcj.spec and linked into the test programs.

Rainer

[Bug c++/49453] New: Accepts invalid syntax for partial specialization of class template where the specialization is a class template

[Nimantha.Siriwardana at googlemail dot com]

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

   Summary: Accepts invalid syntax for partial specialization of
class template where the specialization is a class
template
   Product: gcc
   Version: 4.3.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nimantha.siriward...@googlemail.com


Example:

#include 
template 
struct foo{
  typedef F value_type;
};

template 
struct bar{};

//template<>  <- works if commented out or not
template 
struct bar >
{
  typename foo::value_type val;
};

int main(void)
{
  typedef foo F;
  typedef bar B;
  B b;
  b.val = 10;
  std::cout << b.val << std::endl;
  return 0;
};

I have been led to believe that this is incorrect behaviour, have tested on
4.4.4 and 4.5.1 and this appears to be the same.

[Bug libfortran/48787] Invalid UP/DOWN rounding with F editing

[thenlich at users dot sourceforge.net]

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

--- Comment #22 from Thomas Henlich  
2011-06-17 13:22:42 UTC ---
This is kind of bad:

print "(RU,F7.0)", 7500.0 ! 8. expected 7500.
print "(RD,F7.0)", -7500.0 ! -8. expected -7500.

[Bug libobjc/36610] objc_msg_sendv is broken for targets which pass argument via registers

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #24 from ro at CeBiTec dot Uni-Bielefeld.DE  2011-06-17 13:23:39 UTC ---
> --- Comment #23 from Nicola Pero  2011-06-14 
> 18:26:40 UTC ---
[...]
> Summarizing, I would close the bug, or leave it open but just to remind me/us
> to:
>
>  * remove the existing forwarding code from libobjc;
>
>  * remove the forward-1.m testcase;

Since the test now seems to pass everywhere, we could just remove the
xfail instead.

>  * add new testcases for the libobjc forwarding hooks.  As these are the
> official
> ways to use forwarding (and the only ones available), we should have 
> testcases.

Agreed, but that's orthogonal to the issue at hand.

Whatever is done, we should soon remove the annoying XFAILs of
objc.dg/torture/forward-1.m.

Thanks.
Rainer

[Bug libobjc/36610] objc_msg_sendv is broken for targets which pass argument via registers

[dominiq at lps dot ens.fr]

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

--- Comment #25 from Dominique d'Humieres  
2011-06-17 13:29:33 UTC ---
I have the following patch in my working tree without regression

--- /opt/gcc/_clean/gcc/testsuite/objc.dg/torture/forward-1.m2011-06-07
16:48:47.0 +0200
+++ /opt/gcc/work/gcc/testsuite/objc.dg/torture/forward-1.m2011-06-07
17:10:00.0 +0200
@@ -1,7 +1,5 @@
 /* { dg-do run } */
 /* See if -forward:: is able to work. */
-/* { dg-xfail-run-if "PR36610" { ! { { i?86-*-* x86_64-*-* } && ilp32 } } {
"-fgnu-runtime" } { "" } } */
-/* { dg-skip-if "Needs OBJC2 Implementation" { *-*-darwin* && { lp64 } } {
"-fnext-runtime" } { "" } } */

 #include 
 #include 

[Bug libfortran/48787] Invalid UP/DOWN rounding with F editing

[dominiq at lps dot ens.fr]

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

--- Comment #23 from Dominique d'Humieres  
2011-06-17 13:32:33 UTC ---
For 'gcc version 4.6.0 20110313 (experimental) [trunk revision 170921p5] (GCC)'
I get

  7501.
 -7501.

[Bug c++/49450] not possible to call explicit destructor of std::string

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler at
   ||googlemail dot com

--- Comment #2 from Daniel Krügler  
2011-06-17 13:32:44 UTC ---
(In reply to comment #0)
> We want to use C++0x unions with a std::string as member (see for example
> http://www2.research.att.com/~bs/C++0xFAQ.html#unions). At the moment we want
> to call the ~string we get an error.

Your program is not conforming according to the standard. You need to write

s.std::string::~string();

instead.

[Bug c++/49450] not possible to call explicit destructor of std::string

[jwillemsen at remedy dot nl]

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

Johnny Willemsen  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #3 from Johnny Willemsen  2011-06-17 
13:34:58 UTC ---
user error

[Bug bootstrap/49383] [4.7 regression] powerpc64-linux bootstrap failure due to ice in cgraph_only_called_directly_p

[wschmidt at gcc dot gnu.org]

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

William J. Schmidt  changed:

   What|Removed |Added

 CC||wschmidt at gcc dot gnu.org

--- Comment #1 from William J. Schmidt  2011-06-17 
13:37:45 UTC ---
Here's a backtrace:

#0  fancy_abort (file=0x10d1b918
"/home/wschmidt/gcc/gcc-mainline-pr49383/gcc/cgraph.c", line=3012,
function=0x10d1b870 "cgraph_only_called_directly_p") at
/home/wschmidt/gcc/gcc-mainline-pr49383/gcc/diagnostic.c:893
#1  0x103db28c in cgraph_only_called_directly_p (node=Unhandled dwarf
expression opcode 0xf3
) at /home/wschmidt/gcc/gcc-mainline-pr49383/gcc/cgraph.c:3012
#2  0x10991bbc in call_ABI_of_interest (fndecl=Unhandled dwarf
expression opcode 0xf3
) at /home/wschmidt/gcc/gcc-mainline-pr49383/gcc/config/rs6000/rs6000.c:7422
#3  0x109a4848 in init_cumulative_args (cum=0xfffd4d0,
fntype=0xfffb6ff9108, libname=Unhandled dwarf expression opcode 0xf3
) at /home/wschmidt/gcc/gcc-mainline-pr49383/gcc/config/rs6000/rs6000.c:7485
#4  0x1039ed88 in expand_call (exp=0xfffb6f6fa00, target=0x0,
ignore=Unhandled dwarf expression opcode 0xf3
) at /home/wschmidt/gcc/gcc-mainline-pr49383/gcc/calls.c:2248
#5  0x1049c724 in expand_expr_real_1 (exp=0xfffb6f6fa00, target=, tmode=Unhandled dwarf expression opcode 0xf3
) at /home/wschmidt/gcc/gcc-mainline-pr49383/gcc/expr.c:9351
#6  0x103aff98 in expand_call_stmt (stmt=0xfffb7034c80) at
/home/wschmidt/gcc/gcc-mainline-pr49383/gcc/cfgexpand.c:1870
#7  expand_gimple_stmt_1 (stmt=0xfffb7034c80) at
/home/wschmidt/gcc/gcc-mainline-pr49383/gcc/cfgexpand.c:1907
#8  expand_gimple_stmt (stmt=0xfffb7034c80) at
/home/wschmidt/gcc/gcc-mainline-pr49383/gcc/cfgexpand.c:2054
#9  0x103b1434 in expand_gimple_basic_block (bb=0xfffb6ea96b8) at
/home/wschmidt/gcc/gcc-mainline-pr49383/gcc/cfgexpand.c:3637
#10 0x103b7d24 in gimple_expand_cfg () at
/home/wschmidt/gcc/gcc-mainline-pr49383/gcc/cfgexpand.c:4120
#11 0x10670860 in execute_one_pass (pass=0x10fd0a28) at
/home/wschmidt/gcc/gcc-mainline-pr49383/gcc/passes.c:2023
#12 0x10670c50 in execute_pass_list (pass=0x10fd0a28) at
/home/wschmidt/gcc/gcc-mainline-pr49383/gcc/passes.c:2078
#13 0x107b2cc0 in tree_rest_of_compilation (fndecl=0xfffb6f8c900) at
/home/wschmidt/gcc/gcc-mainline-pr49383/gcc/tree-optimize.c:416
#14 0x103e1d20 in cgraph_expand_function (node=0xfffb6fc9240) at
/home/wschmidt/gcc/gcc-mainline-pr49383/gcc/cgraphunit.c:1768
#15 0x103e41a8 in cgraph_expand_all_functions () at
/home/wschmidt/gcc/gcc-mainline-pr49383/gcc/cgraphunit.c:1827
#16 cgraph_optimize () at
/home/wschmidt/gcc/gcc-mainline-pr49383/gcc/cgraphunit.c:2090
#17 0x103e49c8 in cgraph_finalize_compilation_unit () at
/home/wschmidt/gcc/gcc-mainline-pr49383/gcc/cgraphunit.c:1269
#18 0x101b5d54 in cp_write_global_declarations () at
/home/wschmidt/gcc/gcc-mainline-pr49383/gcc/cp/decl2.c:4006
#19 0x1073bbf8 in compile_file () at
/home/wschmidt/gcc/gcc-mainline-pr49383/gcc/toplev.c:587
#20 do_compile () at /home/wschmidt/gcc/gcc-mainline-pr49383/gcc/toplev.c:1924
#21 toplev_main () at /home/wschmidt/gcc/gcc-mainline-pr49383/gcc/toplev.c:1996
#22 0x100b3f34 in main (argc=, argv=) at /home/wschmidt/gcc/gcc-mainline-pr49383/gcc/main.c:36

[Bug c++/49450] not possible to call explicit destructor of std::string

[jwillemsen at remedy dot nl]

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

Johnny Willemsen  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

--- Comment #4 from Johnny Willemsen  2011-06-17 
13:39:20 UTC ---
correct status

[Bug target/49454] New: [4.7 Regression] /usr/include/libio.h:336:3: internal compiler error: Segmentation fault

[danglin at gcc dot gnu.org]

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

   Summary: [4.7 Regression] /usr/include/libio.h:336:3: internal
compiler error: Segmentation fault
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dang...@gcc.gnu.org
  Host: hppa*-*-* (32-bit)
Target: hppa*-*-* (32-bit)
 Build: hppa*-*-* (32-bit)


/home/dave/gnu/gcc/objdir/./gcc/xgcc -B/home/dave/gnu/gcc/objdir/./gcc/
-B/home/
dave/opt/gnu/gcc/gcc-4.5/hppa-linux/bin/
-B/home/dave/opt/gnu/gcc/gcc-4.5/hppa-l
inux/lib/ -isystem /home/dave/opt/gnu/gcc/gcc-4.5/hppa-linux/include -isystem
/h
ome/dave/opt/gnu/gcc/gcc-4.5/hppa-linux/sys-include-g -O2 -O2  -g -O2
-DIN_G
CC   -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes
-Wmissing-prototyp
es -Wold-style-definition  -isystem ./include  -fPIC -DELF=1 -DLINUX=1 -g
-DHAVE
_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -fbuilding-libgcc
-fno-stack
-protector   -I. -I. -I../.././gcc -I../../../gcc/libgcc
-I../../../gcc/libgcc/.
 -I../../../gcc/libgcc/../gcc -I../../../gcc/libgcc/../include-o _negdi2.o
-
MT _negdi2.o -MD -MP -MF _negdi2.dep -DL_negdi2 -c
../../../gcc/libgcc/../gcc/li
bgcc2.c \
  -fvisibility=hidden -DHIDE_EXPORTS
In file included from /usr/include/stdio.h:75:0,
 from ../../../gcc/libgcc/../gcc/tsystem.h:87,
 from ../../../gcc/libgcc/../gcc/libgcc2.c:29:
/usr/include/libio.h:336:3: internal compiler error: Segmentation fault

This is in stage2.

First seen in revision 175083.  175007 was ok.

[Bug libgcj/49455] New: Thread_Interrupt Looper subtest FAILs on IRIX

[ro at gcc dot gnu.org]

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

   Summary: Thread_Interrupt Looper subtest FAILs on IRIX
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcj
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
CC: tro...@gcc.gnu.org, a...@gcc.gnu.org
  Host: mips-sgi-irix6.5
Target: mips-sgi-irix6.5
 Build: mips-sgi-irix6.5


The Looper subtest of Thread_Interrupt FAILs on IRIX 6.5, as can be seen in
the following diff between expected and found outputs:

---
/vol/gcc/src/hg/trunk/local/libjava/testsuite/libjava.lang/Thread_Interrupt.out
Mon Mar  1 20:33:06 2010
+++ Thread_Interrupt.outFri Jun 10 17:14:23 2011
@@ -3,6 +3,6 @@
 sleep()
 interrupted - ok
 Busy waiting
-interrupted - ok
+Error: Busy wait was not interrupted.
 join()
 interrupted - ok

Unfortunately, if running the test under gdb, it just hangs in the first
subtest,
so the only hope was adding debug printfs.  Strangely, when I added
fprintf (stderr, ": \n") calls to all functions in posix-threads.cc,
the test suddenly passes when ignoring the debug output.

I'm somewhat at at loss how to further debug this.

[Bug libgcj/49314] md5test, shatest output FAILs on Tru64 UNIX

[howarth at nitro dot med.uc.edu]

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

Jack Howarth  changed:

   What|Removed |Added

 CC||howarth at nitro dot
   ||med.uc.edu

--- Comment #9 from Jack Howarth  2011-06-17 
14:01:23 UTC ---
(In reply to comment #8)
> > --- Comment #7 from Dominique d'Humieres  
> > 2011-06-17 13:04:17 UTC ---
> > Could this pr be related to pr49441?
> 
> No: the iconv functions only live in libiconv (no stubs in libc), and
> that is present in libgcj.spec and linked into the test programs.
> 
> Rainer

 pr49441 is a totally different issue. That bug manifests itself as a runtime
error with unresolved symbols from libiconv. I still don't understand why we
just don't link libgcj directly against libiconv to avoid needing libgcj.spec
to pass anything for libiconv.

[Bug libgcj/49456] New: getstacktrace and getallthreads tests timeout on IRIX

[ro at gcc dot gnu.org]

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

   Summary: getstacktrace and getallthreads tests timeout on IRIX
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcj
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
CC: tro...@gcc.gnu.org, a...@gcc.gnu.org
  Host: mips-sgi-irix6.5
Target: mips-sgi-irix6.5
 Build: mips-sgi-irix6.5


The last two failing libjava tests on IRIX 6.5 are getstacktrace and
getallthreads,
both of which timeout.  At first I thought this might be related to PR
libgcj/49455,
but unlike that case the present tests also hang if running with a
debug-enabled
libgcj.so.

[Bug target/43603] gcc-4.4.3 ICE on ia64 with -O3

[devurandom at gmx dot net]

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

--- Comment #23 from devurandom at gmx dot net 2011-06-17 14:04:50 UTC ---
(In reply to comment #22)
> (In reply to comment #20)
> > Created attachment 24112 [details]
> > backported patch
> > 
> > Good.  Then attached is the initial backport, I have just verified that it
> > passes the testcase.  It would be great if the Gentoo folks could test it in
> > their setup, too.  If all goes well, I will apply it to 4_4-branch at the
> > beginning of May.
> Is this applied to any branch yet?
Confirming that the attached patch allows compilation of Erlang 14B03 when
applied to GCC 4.4.5.

[Bug libgcj/49314] md5test, shatest output FAILs on Tru64 UNIX

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE  2011-06-17 14:06:12 UTC ---
>  pr49441 is a totally different issue. That bug manifests itself as a runtime
> error with unresolved symbols from libiconv. I still don't understand why we
> just don't link libgcj directly against libiconv to avoid needing libgcj.spec
> to pass anything for libiconv.

Fully agreed: the gcc runtime libraries should just be self-contained.

Rainer

[Bug libstdc++/49445] Undefined reference to std::atomic "operator float"

[raskolnikov at gnu dot org]

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

--- Comment #5 from Juan Pedro Bolívar Puente  
2011-06-17 14:41:03 UTC ---
You are right, I thought it worked for all fundamental types but reviewing the
proposal [1] makes me realise I was wrong. It remains unclear wether user
defined enums should work ...

Thanks a lot for the fast reply and sorry for the mistake.

[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2427.html

[Bug target/43603] gcc-4.4.3 ICE on ia64 with -O3

[abel at gcc dot gnu.org]

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

--- Comment #24 from Andrey Belevantsev  2011-06-17 
15:08:55 UTC ---
Thanks for reminder, I've started bootstap and test on ia64 and x86-64.

[Bug debug/48459] [4.6/4.7 Regression] avr: Assertion failure with -gdwarf-2

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |

--- Comment #31 from Richard Henderson  2011-06-17 
15:50:27 UTC ---
You're right.  And now I remember the other patch to dwarf2out.c
that went along with fixing up the errors in avr.c wrt dwarf2.
I must backport them both.

[Bug bootstrap/49383] [4.7 regression] powerpc64-linux bootstrap failure due to ice in cgraph_only_called_directly_p

[bergner at gcc dot gnu.org]

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

--- Comment #2 from Peter Bergner  2011-06-17 
15:53:39 UTC ---
We die on this assert:

  gcc_assert (cgraph_function_or_thunk_node (node, NULL) == node);

Here's a couple of dumps of the two decls if that helps.

(gdb) frame 1

(gdb) ptree node->decl
 >
SI
size 
unit size 
align 32 symtab 0 alias set -1 canonical type 0xfffb6fe9108 method
basetype 
arg-types 
chain >>
pointer_to_this >
addressable used public static decl_5 SI file
/home/bergner/gcc/gcc-mainline-20110614/libstdc++-v3/libsupc++/array_type_info.cc
line 29 col 1 align 32 context 
initial  abstract_origin 
arguments 
readonly unsigned SI size  unit size

align 32 symtab 4095 alias set -1 canonical type 0xfffb6fe8fb8>
readonly used unsigned SI file
/home/bergner/gcc/gcc-mainline-20110614/libstdc++-v3/libsupc++/array_type_info.cc
line 30 col 21 size  unit size 
align 32 context 
abstract_origin  arg-type >
result 
ignored VOID file
/home/bergner/gcc/gcc-mainline-20110614/libstdc++-v3/libsupc++/array_type_info.cc
line 31 col 2
align 8 context >
full-name "__cxxabiv1::__array_type_info::~__array_type_info()"
pending-inline-info 0xfffb6d25c50
(mem:SI (symbol_ref:SI ("_ZN10__cxxabiv117__array_type_infoD1Ev") [flags
0x1] ) [0 S4 A32])
struct-function 0xfffb6e08890 chain >

(gdb) p cgraph_function_or_thunk_node (node, NULL)
$9 = (struct cgraph_node *) 0xfffb6fb9000

(gdb) ptree $9->decl
 >
SI
size 
unit size 
align 32 symtab 0 alias set -1 canonical type 0xfffb6fe9108 method
basetype 
arg-types 
chain >>
pointer_to_this >
asm_written public static decl_5 SI file
/home/bergner/gcc/gcc-mainline-20110614/libstdc++-v3/libsupc++/array_type_info.cc
line 29 col 1 align 32 context 
initial  abstract_origin 
arguments 
readonly unsigned SI size  unit size

align 32 symtab 4095 alias set -1 canonical type 0xfffb6fe8fb8>
readonly used unsigned SI file
/home/bergner/gcc/gcc-mainline-20110614/libstdc++-v3/libsupc++/array_type_info.cc
line 30 col 21 size  unit size 
align 32 context 
abstract_origin 
(mem/f/c/i:SI (plus:SI (reg/f:SI 113 sfp)
(const_int 8 [0x8])) [0 this+0 S4 A32]) arg-type 
incoming-rtl (reg:SI 3 3 [ this ])>
result 
ignored VOID file
/home/bergner/gcc/gcc-mainline-20110614/libstdc++-v3/libsupc++/array_type_info.cc
line 31 col 2
align 8 context >
full-name "__cxxabiv1::__array_type_info::~__array_type_info()"
pending-inline-info 0xfffb6d25b70
(mem:SI (symbol_ref:SI ("_ZN10__cxxabiv117__array_type_infoD2Ev") [flags
0x1] ) [0 S4 A32]) chain
>

[Bug c++/47606] [trans-mem] internal compiler error in expand_block_tm with O2

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #8 from Richard Henderson  2011-06-17 
16:03:03 UTC ---
Fixed with:

2011-06-17  Richard Henderson  

Backport from mainline
2011-03-22  Richard Henderson  

* dwarf2out.c (dwarf2out_frame_debug_expr) [rule 11]: Handle post_dec.

[Bug c++/47606] [trans-mem] internal compiler error in expand_block_tm with O2

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |

--- Comment #9 from Richard Henderson  2011-06-17 
16:03:54 UTC ---
Gah.  Wrong PR.

[Bug debug/48459] [4.6/4.7 Regression] avr: Assertion failure with -gdwarf-2

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED

--- Comment #32 from Richard Henderson  2011-06-17 
16:04:43 UTC ---
Fixed with:

2011-06-17  Richard Henderson  

Backport from mainline
2011-03-22  Richard Henderson  

* dwarf2out.c (dwarf2out_frame_debug_expr) [rule 11]: Handle post_dec.

[Bug libgcj/49314] md5test, shatest output FAILs on Tru64 UNIX

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE  2011-06-17 16:15:55 UTC ---
Further investigation revealed part of what's going on: the test in
gnu::gcj::convert::IOConverter::iconv_init fails with EINVAL on Tru64
UNIX, but the byte swapping is still needed.  If I hack the function to
return true, both the testcase and md5test/shatest succeed.

The question now is what's a clean fix for this issue, rather than
hardcoding the result?

Rainer

[Bug tree-optimization/49444] IV-OPTs changes an unaligned loads into aligned loads incorrectly

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  2011-06-17 
16:25:04 UTC ---
(In reply to comment #4)
> 
> Well, that will then still run into the indirect-ref issue as
> the expansion for target-mem-refs and mem-refs works the same way.
> Only targets that support movmisalign will generate unaligned
> loads (which targets currently only define for vector modes I think).

It works in the case which I reported because the mode is BLKmode.  I tried to
get a testcase that would still fail after this but I could not find one as
IV-OPTs would use a->b for that still.

Thanks,
Andrew Pinski

[Bug tree-optimization/49452] comp-goto-2.c regresses in testing

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #2 from Eric Botcazou  2011-06-17 
16:51:41 UTC ---
> NORETURN attribute marked to it but there's no reason why this should be 
> marked
> as NORETURN - surely there is a flow of control that allows control to go out
> of the function. 
> 
> 
> x(a)
> {
>   __label__ xlab;
>   void y(a)
> {
>   void *x = &&llab;
>   if (a==-1)
>  goto *x;
>   if (a==0)
>  goto xlab;
> llab:
>   y (a-1);
> }
>   y (a);
>  xlab:;
>   return a;
> }

Yes, but this isn't a return, this is a non-local goto so NORETURN is correct.

[Bug tree-optimization/49452] comp-goto-2.c regresses in testing

[ebotcazou at gcc dot gnu.org]

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

--- Comment #3 from Eric Botcazou  2011-06-17 
16:55:48 UTC ---
> I haven't looked at in great detail yet to analyse what causes this problem 
> but
> it appears to have appeared in the last week or so.

Maybe r175063 (significant dse.c change).

[Bug tree-optimization/49457] New: integer comparison does not vectorize

[vincenzo.innocente at cern dot ch]

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

   Summary: integer comparison does not vectorize
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vincenzo.innoce...@cern.ch


float __attribute__ ((aligned(16))) a[1024];
float __attribute__ ((aligned(16))) b[1024];

// does not vectorize
void tVi() {
  for (int i=0; i!=1024; ++i) {
int j = a[i];
b[i] = (j==0) ?  a[i] : - a[i];
  }
}

// nicely vectorize...
void tVf() {
  for (int i=0; i!=1024; ++i) {
int j = a[i];
float z = j;
b[i] = (z==0) ?  a[i] : - a[i];
  }
}


c++ -Ofast -c testVectCond.cpp -msse4.2

 otool -V -t testVectCond.o | c++filt
testVectCond.o:
(__TEXT,__text) section
tVi():
xorl%eax,%eax
0002movss0x0096(%rip),%xmm2
000aleaq_a(%rip),%rcx
0011nopltVi()(%rax)
0018nopltVi()(%rax,%rax)
0020movss(%rcx,%rax),%xmm0
0025cvttss2si%xmm0,%edx
0029movaps%xmm0,%xmm1
002cxorps%xmm2,%xmm1
002ftestl%edx,%edx
0031je0x0036
0033movaps%xmm1,%xmm0
0036leaq_b(%rip),%rdx
003dmovss%xmm0,(%rdx,%rax)
0042addq$0x04,%rax
0046cmpq$0x1000,%eax
004cjne0x0020
004erepz/ret
tVf():
0050movaps0x0059(%rip),%xmm4
0057xorl%eax,%eax
0059xorps%xmm3,%xmm3
005cleaq_a(%rip),%rcx
0063leaq_b(%rip),%rdx
006anopwtVi()(%rax,%rax)
0070movaps(%rcx,%rax),%xmm2
0074cvttps2dq%xmm2,%xmm0
0078cvtdq2ps%xmm0,%xmm0
007bcmpps$0x4,%xmm3,%xmm0
007fmovaps%xmm2,%xmm1
0082xorps%xmm4,%xmm1
0085andps%xmm0,%xmm1
0088andnps%xmm2,%xmm0
008borps%xmm1,%xmm0
008emovaps%xmm0,(%rdx,%rax)
0092addq$0x10,%rax
0096cmpq$0x1000,%eax
009cjne0x0070
009erepz/ret

I'm using
g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-apple-darwin10.7.0/4.7.0/lto-wrapper
Target: x86_64-apple-darwin10.7.0
Configured with: ./configure --enable-languages=c,c++,fortran --enable-lto
--with-build-config=bootstrap-lto CFLAGS='-O2 -ftree-vectorize -fPIC'
CXXFLAGS='-O2 -fPIC -ftree-vectorize -fvisibility-inlines-hidden'
Thread model: posix
gcc version 4.7.0 20110528 (experimental) (GCC)

[Bug gcov-profile/7970] Arc profiling doesn't work reliably on global destructors

[dhammen at odysseysr dot com]

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

David Hammen  changed:

   What|Removed |Added

 CC||dhammen at odysseysr dot
   ||com

--- Comment #5 from David Hammen  2011-06-17 
17:45:30 UTC ---
This bug *still* exists as of i686-apple-darwin10-g++-4.2.1. The problem is
apparently the collision of two at_exit() handlers, with C++'s global
destructor coming in last.

[Bug c++/49458] New: [C++0x] Obvious candidate for conversion to function lvalue rejected

[hstong at ca dot ibm.com]

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

   Summary: [C++0x] Obvious candidate for conversion to function
lvalue rejected
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hst...@ca.ibm.com
CC: micha...@ca.ibm.com
  Host: powerpc64-unknown-linux-gnu
Target: powerpc64-unknown-linux-gnu


According to the 2011 FCD, subclause 13.3.1.6 [over.match.ref] paragraph 1:
>>>
The conversion functions of S and its base classes are considered, except that
for copy-initialization, only the non-explicit conversion functions are
considered. Those that are not hidden within S and yield type "lvalue reference
to cv2 T2" (when 8.5.3 requires an lvalue result) or "cv2 T2" or
"rvalue reference to cv2 T2" (when 8.5.3 requires an rvalue result), where
"cv1 T" is reference-compatible (8.5.3) with "cv2 T2", are candidate functions.
<<<

Both lvalue references and rvalue references to function types require binding
to function lvalues. The following test case is expected to compile clean.

GCC still does not compile if #1 is commented out.

GCC will compile if #2 is commented out, but that behaviour is unsupported by
the referenced wording.

In particular, #2 should be a candidate and (from the wording) #1 is not for
conversion to a function lvalue.


### Self-contained source (a.cpp):> cat a.cpp
typedef void ftype();
void foo() { }

struct A {
   operator ftype&&(void);  // #1
   operator ftype&(void) { return foo; }  // #2
};

ftype &&frvref = A();


### Compiler invocation:
g++-4.6.0 -std=c++0x -o a.o -c a.cpp


### Compiler output:
a.cpp:9:20: error: invalid initialization of reference of type ‘void (&&)()’
from expression of type ‘A’


### g++ -v output:> g++-4.6.0 -v
Using built-in specs.
COLLECT_GCC=g++-4.6.0
COLLECT_LTO_WRAPPER=/data/gcc/libexec/gcc/powerpc64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: powerpc64-unknown-linux-gnu
Configured with: ./configure --prefix=/data/gcc --program-suffix=-4.6.0
--disable-libssp --disable-libgcj --enable-version-specific-runtime-libs
--with-cpu=default32 --enable-secureplt --with-long-double-128 --enable-shared
--enable-__cxa_atexit --enable-threads=posix --enable-languages=c,c++,fortran
--with-gmp=/usr/local
Thread model: posix
gcc version 4.6.0 (GCC)

[Bug c/49459] New: attribute((mode(byte))) in a typedef produces wrong debug information

[pkoning at gcc dot gnu.org]

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

   Summary: attribute((mode(byte))) in a typedef produces wrong
debug information
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pkon...@gcc.gnu.org


Created attachment 24554
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24554
Test case

The attached test case shows attribute((mode(byte))) used to produce enums that
are one byte long rather than the usual 4.  

The compiler actually sees the correct value of sizeof() but GDB (7.2) does
not.  This can be seen by compiling the test case;  gdb shows the value of s1
as 1, but sizeof(foo) as 4.

When compiled with GCC 3.3.3, s1 and sizeof(foo) both show up as 1, as
expected.

[Bug target/49454] [4.7 Regression] /usr/include/libio.h:336:3: internal compiler error: Segmentation fault

[sje at cup dot hp.com]

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

Steve Ellcey  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.06.17 18:30:10
 CC||sje at cup dot hp.com
 Depends on||49429
 Ever Confirmed|0   |1

--- Comment #1 from Steve Ellcey  2011-06-17 18:30:10 
UTC ---
This is caused by r175063, the same change that caused pr49429.

[Bug debug/49459] attribute((mode(byte))) in a typedef produces wrong debug information

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||wrong-debug
   Last reconfirmed||2011.06.17 18:56:47
  Component|c   |debug
 CC||rth at gcc dot gnu.org
 Ever Confirmed|0   |1
  Known to fail||4.5.1, 4.6.0

--- Comment #1 from Richard Henderson  2011-06-17 
18:56:47 UTC ---
Confirmed.

 <1><5e>: Abbrev Number: 5 (DW_TAG_variable)
<5f>   DW_AT_name: foo  
<63>   DW_AT_decl_file   : 1
<64>   DW_AT_decl_line   : 4
<65>   DW_AT_type: <0x32>   
<69>   DW_AT_external: 1
<6a>   DW_AT_declaration : 1
 <1><32>: Abbrev Number: 4 (DW_TAG_typedef)
<33>   DW_AT_name: e1   
<36>   DW_AT_decl_file   : 1
<37>   DW_AT_decl_line   : 1
<38>   DW_AT_type: <0x1d>   
 <1><1d>: Abbrev Number: 2 (DW_TAG_enumeration_type)
<1e>   DW_AT_byte_size   : 4
<1f>   DW_AT_decl_file   : 1
<20>   DW_AT_decl_line   : 1
<21>   DW_AT_sibling : <0x32>   

Note that DW_AT_byte_size == 4.  We never change the size
of the type based on the attribute attached to the typedef.

[Bug libfortran/49296] [4.6/4.7 Regression] Wrong END OF FILE error for list-directed I/O with strings

[jb at gcc dot gnu.org]

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

Janne Blomqvist  changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2011-06/msg00896.htm
   ||l

--- Comment #9 from Janne Blomqvist  2011-06-17 19:10:43 
UTC ---
Patch: http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00896.html

Simplified testcase: http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01355.html

[Bug c++/49460] New: g++: Internal error: Segmentation fault (program cc1plus) using -O2 or -O3

[rjarrett at mathworks dot com]

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

   Summary: g++: Internal error: Segmentation fault (program
cc1plus) using  -O2 or -O3
   Product: gcc
   Version: 4.5.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rjarr...@mathworks.com


using GCC 4.5.3 one (and only one) file from our code base caused the compiler
to Segfault.
Set severity to normal because this only occurred in 1 file out of 10k+ and
workaround is available.
Workaround compile with -O1 or -O0


This issue does not occur when compiling with GCC4.4.5 or GCC 4.3.4


Version information:
GNU C++ (GCC) version 4.5.3 (i686-pc-linux-gnu)
compiled by GNU C version 4.5.3, GMP version 4.3.2, MPFR version 2.4.2,
MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (GCC) version 4.5.3 (i686-pc-linux-gnu)
compiled by GNU C version 4.5.3, GMP version 4.3.2, MPFR version 2.4.2,
MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: caed1e0856fbbe32553e2b8828f0c55c
g++: Internal error: Segmentation fault (program cc1plus)

System type:
Debian Linux 6.01 (glnx86 and glnxa64)

GCC build/configuration options:  (glnx86 build shown)
 gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/mathworks/hub/3rdparty/internal/290712/glnx86/gcc-4.5.3/bin/../libexec/gcc/i686-pc-linux-gnu/4.5.3/lto-wrapper
Target: i686-pc-linux-gnu
Configured with:
/mathworks/devel/sandbox/greg/Amake.3p1/3p/sources/gcc-4.5/configure
--prefix=/hub/3rdparty/internal/290712/glnx86/gcc-4.5.3
--with-gmp=/mathworks/devel/sandbox/greg/Amake.3p1/3p/derived/glnx86/gcc-4.5/gmp
--with-mpfr=/mathworks/devel/sandbox/greg/Amake.3p1/3p/derived/glnx86/gcc-4.5/mpfr
--with-mpc=/mathworks/devel/sandbox/greg/Amake.3p1/3p/derived/glnx86/gcc-4.5/mpc
--enable-languages=c,c++,fortran
--with-as=/hub/3rdparty/internal/290712/glnx86/gcc-4.5.3/bin/as
--with-ld=/hub/3rdparty/internal/290712/glnx86/gcc-4.5.3/bin/ld
Thread model: posix
gcc version 4.5.3 (GCC) 

gcc version 4.4.5 (Debian 4.4.5-8) 


Compile line options/command line:
COLLECT_GCC_OPTIONS='-c' '-o' '/tmp/SM.o' '-I../../src/cgir_xform/include'
'-I../../src/include' '-I../../derived/glnx86/src/include'
'-I../../src/cgir_xform' '-I../include' '-I../../include'
'-I//mathworks/hub/3rdparty/R2012a/293758/glnx86/boost/include'
'-I//mathworks/hub/3rdparty/R2012a/287824/glnx86/unique_ptr'
'-I//mathworks/hub/3rdparty/R2012a/289443/glnx86/gmp/include'
'-I//mathworks/hub/3rdparty/R2012a/288615/glnx86/mpfr/include'
'-DMAKEHEADER_KEYWORDS' '-DMAKEHEADER_KEYWORDS'
'-DNEEDS_MX_ERRWARN_MSG_ID_AND_TXT' '-DSL_INTERNAL'
'-DCGIR_HANDWRITTEN_HEADERS' '-I../../simulink/include' '-DMODULE_CGIR'
'-DBUILDING_CGIR_XFORM' '-O2' '-D_POSIX_C_SOURCE=199506L' '-D_LARGEFILE_SOURCE'
'-D_FILE_OFFSET_BITS=64' '-v' '-save-temps' '-shared-libgcc' '-mtune=generic'
'-march=pentiumpro'

/mathworks/hub/3rdparty/internal/290712/glnx86/gcc-4.5.3/bin/../libexec/gcc/i686-pc-linux-gnu/4.5.3/cc1plus
-fpreprocessed SmartInliner.ii -quiet -dumpbase SmartInliner.cpp -mtune=generic
-march=pentiumpro -auxbase-strip /tmp/SM.o -O2 -version -o SmartInliner.s

---
SmartInliner.ii has attached to this file

[Bug c++/49460] g++: Internal error: Segmentation fault (program cc1plus) using -O2 or -O3

[rjarrett at mathworks dot com]

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

--- Comment #1 from Roger Jarrett  2011-06-17 
19:41:29 UTC ---
Created attachment 24555
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24555
preprocessed source file SmartInliner.ii (gzipped)

preprocessed file gzipped to allow upload

[Bug fortran/48699] [4.6/4.7 Regression] [OOP] MOVE_ALLOC inside SELECT TYPE

[janus at gcc dot gnu.org]

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

--- Comment #18 from janus at gcc dot gnu.org 2011-06-17 20:03:07 UTC ---
Author: janus
Date: Fri Jun 17 20:03:04 2011
New Revision: 175151

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175151
Log:
2011-06-17  Janus Weil  

PR fortran/48699
* check.c (gfc_check_move_alloc): If 'TO' argument is polymorphic,
make sure the vtab is present.

2011-06-17  Janus Weil  

PR fortran/48699
* gfortran.dg/move_alloc_5.f90: New.

Added:
trunk/gcc/testsuite/gfortran.dg/move_alloc_5.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/check.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/43912] [C++0x] lambda debug info does not describe captured variables

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  2011-06-17 
20:08:06 UTC ---
Author: jason
Date: Fri Jun 17 20:08:01 2011
New Revision: 175158

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175158
Log:
PR c++/43912
Generate proxy VAR_DECLs for better lambda debug info.
* cp-tree.h (FUNCTION_NEEDS_BODY_BLOCK): Add lambda operator().
(LAMBDA_EXPR_PENDING_PROXIES): New.
(struct tree_lambda_expr): Add pending_proxies.
* name-lookup.c (pushdecl_maybe_friend_1): Handle capture shadowing.
(qualify_lookup): Use is_lambda_ignored_entity.
* parser.c (cp_parser_lambda_expression): Don't adjust field names.
Call insert_pending_capture_proxies.
(cp_parser_lambda_introducer): Use this_identifier.
(cp_parser_lambda_declarator_opt): Call the object parameter
of the op() "__closure" instead of "this".
(cp_parser_lambda_body): Call build_capture_proxy.
* semantics.c (build_capture_proxy, is_lambda_ignored_entity): New.
(insert_pending_capture_proxies, insert_capture_proxy): New.
(is_normal_capture_proxy, is_capture_proxy): New.
(add_capture): Add __ to field names here, return capture proxy.
(add_default_capture): Use this_identifier, adjust to expect
add_capture to return a capture proxy.
(outer_lambda_capture_p, thisify_lambda_field): Remove.
(finish_id_expression, lambda_expr_this_capture): Adjust.
(build_lambda_expr): Initialize LAMBDA_EXPR_PENDING_PROXIES.
* pt.c (tsubst_copy_and_build): Check that LAMBDA_EXPR_PENDING_PROXIES
is null.

Added:
trunk/gcc/testsuite/g++.dg/debug/dwarf2/lambda1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.def
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/decl.c
trunk/gcc/cp/name-lookup.c
trunk/gcc/cp/parser.c
trunk/gcc/cp/pt.c
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/warn/Wshadow-6.C

[Bug c++/43912] [C++0x] lambda debug info does not describe captured variables

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #4 from Jason Merrill  2011-06-17 
20:13:24 UTC ---
Fixed for 4.7.0.

[Bug rtl-optimization/49429] [4.7 Regression] dse.c changes to fix PR44194 (r175063) cause execution failures

[eraman at google dot com]

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

--- Comment #9 from Easwaran Raman  2011-06-17 
20:43:04 UTC ---
(In reply to comment #8)
> Compiling x.c with a ia64-unknown-linux cross compiler, setting a breakpoint 
> in
> can_escape(), I see that,
> 
> 
> (gdb) p debug_rtx (body)
> (set (mem/s/c:DI (reg/f:DI 341) [2 s1+0 S8 A64])
> (reg:DI 112 in0))
> 
> This is part of an instruction that gets removed:
> (insn 4 3 6 2 (set (mem/s/c:DI (reg/f:DI 341) [2 s1+0 S8 A64])
> (reg:DI 112 in0)) y.c:23 5 {movdi_internal}
>  (expr_list:REG_DEAD (reg:DI 112 in0)
> (nil)))
> 
> (gdb) p expr->base.code 
> $24 = PARM_DECL
> (gdb) p may_be_aliased (expr)
> $23 = 0 '\000'
> 
> So can_escape() returns false. But later on, in the same BB, I see:
> 
> 
> (insn 36 30 37 2 (set (reg:DI 120 out0)
> (reg/f:DI 357)) 5 {movdi_internal}
>  (expr_list:REG_EQUAL (plus:DI (reg/f:DI 328 sfp)
> (const_int 62 [0x3e]))
> (nil)))
> (insn 37 36 38 2 (set (reg:DI 121 out1)
> (reg/f:DI 341)) 5 {movdi_internal}
>  (expr_list:REG_DEAD (reg/f:DI 341)
> (expr_list:REG_EQUAL (plus:DI (reg/f:DI 328 sfp)
> (const_int 96 [0x60]))
> (nil
> (insn 38 37 39 2 (set (reg:DI 122 out2)
> (const_int 31 [0x1f])) 5 {movdi_internal}
>  (nil))
> (call_insn 39 38 42 2 (parallel [
> (set (reg:DI 8 r8)
> (call (mem:DI (symbol_ref:DI ("memcpy") [flags 0x41] 
> ) [0 memcpy S8 A64])
> (const_int 1 [0x1])))
> (clobber (reg:DI 320 b0))
> (clobber (scratch:DI))
> (clobber (scratch:DI))
> ]) 332 {call_value_gp}
>  (expr_list:REG_DEAD (reg:DI 122 out2)
> (expr_list:REG_DEAD (reg:DI 121 out1)
> (expr_list:REG_DEAD (reg:DI 120 out0)
> (expr_list:REG_UNUSED (reg:DI 8 r8)
> (expr_list:REG_EH_REGION (const_int 0 [0])
> (nil))
> (expr_list:REG_DEP_TRUE (use (reg:DI 1 r1))
> (expr_list:REG_DEP_TRUE (use (reg:DI 122 out2))
> (expr_list:REG_DEP_TRUE (use (reg:DI 121 out1))
> (expr_list:REG_DEP_TRUE (use (reg:DI 120 out0))
> (nil))
> 
> reg 341 is passed as source argument of a memcpy. Why does the expression
> return 0 for may_be_aliased()?

Could someone tell why may_be_aliased returns false in this case? I would
expect TREE_ADDRESSABLE to be true, but that's not the case. It seems to me
some other bug is exposed by the DSE patch.

[Bug c++/49458] [C++0x] Obvious candidate for conversion to function lvalue rejected

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.06.17 20:44:28
 CC||jason at gcc dot gnu.org
 AssignedTo|unassigned at gcc dot   |jason at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #1 from Jason Merrill  2011-06-17 
20:44:28 UTC ---
I agree that #2 should be a candidate, since it returns a function lvalue, and
frvref can bind to a function lvalue.  That is a bug.

I also agree with your interpretation of the standard on the other points, but
that seems unintentional, so I'm going to raise the issue with the committee.

[Bug rtl-optimization/49429] [4.7 Regression] dse.c changes to fix PR44194 (r175063) cause execution failures

[sje at cup dot hp.com]

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

--- Comment #10 from Steve Ellcey  2011-06-17 20:49:22 
UTC ---
With regards to the question in comment #9, you would probably do better asking
it on the gcc-patches mailing list then in the comment of this bug report since
more people would see it on the mailing list.

[Bug fortran/49400] Proc-pointer declaration in BLOCK construct

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.06.17 20:54:14
 AssignedTo|unassigned at gcc dot   |janus at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #1 from janus at gcc dot gnu.org 2011-06-17 20:54:14 UTC ---
(In reply to comment #0)
> Currently, one gets:
> 
> test.f90:8.8:
> 
> Procedure(Real),Pointer :: p
> 1
> Error: Unclassifiable statement at (1)


Fixing this is trivial:


Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c(revision 175150)
+++ gcc/fortran/decl.c(working copy)
@@ -4970,6 +4970,7 @@ gfc_match_procedure (void)
 case COMP_MODULE:
 case COMP_SUBROUTINE:
 case COMP_FUNCTION:
+case COMP_BLOCK:
   m = match_procedure_decl ();
   break;
 case COMP_INTERFACE:

[Bug target/33049] [avr] bit extraction non optimal, inversing logic solves problem

[gcc at emailgo dot de]

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

HotHead  changed:

   What|Removed |Added

 CC||gcc at emailgo dot de

--- Comment #15 from HotHead  2011-06-17 21:38:20 UTC ---
*** Bug 49446 has been marked as a duplicate of this bug. ***

[Bug target/49446] avr-g++ does not optimize when using bitshift in inlined function

[gcc at emailgo dot de]

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

HotHead  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #1 from HotHead  2011-06-17 21:38:20 UTC ---
duplicate of 33049

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

[Bug target/49446] avr-g++ does not optimize when using bitshift in inlined function

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Target||avr
 CC||gjl at gcc dot gnu.org

--- Comment #2 from Georg-Johann Lay  2011-06-17 
21:58:20 UTC ---
Not very helpful without source to reproduce, see 
http://gcc.gnu.org/bugs/#need

[Bug target/49461] New: boehm-gc and gcj incompatible with pie

[howarth at nitro dot med.uc.edu]

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

   Summary: boehm-gc and gcj incompatible with pie
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: howa...@nitro.med.uc.edu


When built with -pie linkage on intel darwin, the boehm-gc test suite fails the
tests...

FAIL: boehm-gc.c/gctest.c -O2 execution test
FAIL: boehm-gc.c/leak_test.c -O2 execution test
FAIL: boehm-gc.c/thread_leak_test.c -O2 execution test
FAIL: boehm-gc.lib/staticrootstest.c -O2 execution test

at both -m32 and -m64. Likewise gcj crashes when ecj1 is built with -pie
linkage. This crash appears as...

[MacPro:~] howarth% gcj-fsf-4.7 --main=testme -O testme.java -pie -v
Using built-in specs.
Reading specs from
/sw/lib/gcc4.7/lib/gcc/x86_64-apple-darwin11.0.0/4.7.0/../../../libgcj.spec
rename spec startfile to startfileorig
rename spec lib to liborig
COLLECT_GCC=gcj-fsf-4.7
COLLECT_LTO_WRAPPER=/sw/lib/gcc4.7/libexec/gcc/x86_64-apple-darwin11.0.0/4.7.0/lto-wrapper
Target: x86_64-apple-darwin11.0.0
Configured with: ../gcc-4.7-20110617/configure --prefix=/sw
--prefix=/sw/lib/gcc4.7 --mandir=/sw/share/man --infodir=/sw/lib/gcc4.7/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.7 --enable-checking=yes --enable-cloog-backend=isl
Thread model: posix
gcc version 4.7.0 20110617 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-fsaw-java-file' '-mmacosx-version-min=10.7.0' '-O' '-pie'
'-v' '-fbootclasspath=./:/sw/lib/gcc4.7/share/java/libgcj-4.7.0.jar'
'-shared-libgcc' '-mtune=core2'
 /sw/lib/gcc4.7/libexec/gcc/x86_64-apple-darwin11.0.0/4.7.0/ecj1 testme.java
-fbootclasspath=./:/sw/lib/gcc4.7/share/java/libgcj-4.7.0.jar -fsource=1.5
-ftarget=1.5 -fzip-dependency
/var/folders/1l/n78sywl52lz6kkys6nv7mnphgp/T//ccxj1zOQ.zip -fzip-target
/var/folders/1l/n78sywl52lz6kkys6nv7mnphgp/T//ccXXudTY.jar
Exception in thread "main" java.lang.ClassFormatError:
org.eclipse.jdt.internal.compiler.Compiler (erroneous exception handler info)
   at java.lang.VMClassLoader.defineClass(libgcj.12.dylib)
   at java.lang.ClassLoader.defineClass(libgcj.12.dylib)
   at java.security.SecureClassLoader.defineClass(libgcj.12.dylib)
   at java.net.URLClassLoader.findClass(libgcj.12.dylib)
   at java.lang.ClassLoader.loadClass(libgcj.12.dylib)
   at java.lang.ClassLoader.loadClass(libgcj.12.dylib)
   at
org.eclipse.jdt.internal.compiler.impl.CompilerOptions.resetDefaults(CompilerOptions.java:963)
   at
org.eclipse.jdt.internal.compiler.impl.CompilerOptions.(CompilerOptions.java:371)
   at
org.eclipse.jdt.internal.compiler.impl.CompilerOptions.(CompilerOptions.java:363)
   at org.eclipse.jdt.internal.compiler.batch.Main.initialize(Main.java:3548)
   at org.eclipse.jdt.internal.compiler.batch.Main.(Main.java:1435)
   at org.eclipse.jdt.internal.compiler.batch.Main.(Main.java:1423)
   at org.eclipse.jdt.internal.compiler.batch.GCCMain.(GCCMain.java:62)
   at org.eclipse.jdt.internal.compiler.batch.GCCMain.main(GCCMain.java:498)

The problems with gcj can be avoided by passing -no_pie via SYSTEMSPEC in
gcj.spec.in. The test suite results for libjava are reasonable with that
change

http://gcc.gnu.org/ml/gcc-testresults/2011-06/msg01853.html

[Bug c++/49462] New: comparison of const bool and pointer does not yield an error

[frederic.bron at m4x dot org]

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

   Summary: comparison of const bool and pointer does not yield an
error
   Product: gcc
   Version: 4.5.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: frederic.b...@m4x.org


The following code should produce the error "ISO C++ forbids comparison between
pointer and integer" when compiled with g++ -std=c++98 -pedantic-errors.
When the bool is not const or volatile of const volatile, the error is
produced. Only when bool is "only" const, the error is not produced.
Same problem with all comparison operators ==, !=, <, <=, >, >=.

int * pi=0;
bool const b=0;
pi==b;
b==pi;

[Bug libgcj/49314] md5test, shatest output FAILs on Tru64 UNIX

[howarth at nitro dot med.uc.edu]

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

--- Comment #12 from Jack Howarth  2011-06-18 
05:54:49 UTC ---
(In reply to comment #11)
> Further investigation revealed part of what's going on: the test in
> gnu::gcj::convert::IOConverter::iconv_init fails with EINVAL on Tru64
> UNIX, but the byte swapping is still needed.  If I hack the function to
> return true, both the testcase and md5test/shatest succeed.
> 
> The question now is what's a clean fix for this issue, rather than
> hardcoding the result?
> 
> Rainer

Does http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01375.html have any impact on
this bug?

[Bug c++/49458] [C++0x] Obvious candidate for conversion to function lvalue rejected

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  2011-06-18 
05:58:42 UTC ---
Author: jason
Date: Sat Jun 18 05:58:38 2011
New Revision: 175164

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175164
Log:
PR c++/49458
* call.c (convert_class_to_reference_1): Allow binding function
lvalue to rvalue reference.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/rv-func2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/testsuite/ChangeLog

[Bug target/49411] [4.6/4.7] ICE: unrecognizable insn with -mxop in _mm_roti_epi8 with negative number

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  2011-06-18 
06:43:41 UTC ---
Author: jakub
Date: Sat Jun 18 06:43:38 2011
New Revision: 175165

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175165
Log:
PR target/49411
* config/i386/i386.c (ix86_expand_multi_arg_builtins): If
last_arg_constant and last argument doesn't match its predicate,
for xop_vpermil23 error out and for xop_rotl3
if it is CONST_INT, mask it, otherwise expand using rotl3.
(ix86_expand_sse_pcmpestr, ix86_expand_sse_pcmpistr): Fix
spelling of error message.
* config/i386/sse.md (sse4a_extrqi, sse4a_insertqi,
vcvtps2ph, *vcvtps2ph, *vcvtps2ph_store, vcvtps2ph256): Use
const_0_to_255_operand instead of const_int_operand.

Revert:
2011-05-09  Uros Bizjak  

* config/i386/sse.md (blendbits): Remove mode attribute.
(_blend): Use const_int_operand
instead of const_0_to__operand for operand 3 predicate.
Check integer value of operand 3 in insn constraint.

* gcc.target/i386/testimm-1.c: New test.
* gcc.target/i386/testimm-2.c: New test.
* gcc.target/i386/testimm-3.c: New test.
* gcc.target/i386/testimm-4.c: New test.
* gcc.target/i386/testimm-5.c: New test.
* gcc.target/i386/testimm-6.c: New test.
* gcc.target/i386/testimm-7.c: New test.
* gcc.target/i386/testimm-8.c: New test.
* gcc.target/i386/xop-vpermil2px-2.c: New test.
* gcc.target/i386/xop-rotate1-int.c: New test.
* gcc.target/i386/xop-rotate2-int.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/testimm-1.c
trunk/gcc/testsuite/gcc.target/i386/testimm-2.c
trunk/gcc/testsuite/gcc.target/i386/testimm-3.c
trunk/gcc/testsuite/gcc.target/i386/testimm-4.c
trunk/gcc/testsuite/gcc.target/i386/testimm-5.c
trunk/gcc/testsuite/gcc.target/i386/testimm-6.c
trunk/gcc/testsuite/gcc.target/i386/testimm-7.c
trunk/gcc/testsuite/gcc.target/i386/testimm-8.c
trunk/gcc/testsuite/gcc.target/i386/xop-rotate1-int.c
trunk/gcc/testsuite/gcc.target/i386/xop-rotate2-int.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/sse.md
trunk/gcc/testsuite/ChangeLog