[Bug libstdc++/49559] New: stable_sort calls self-move-assignment operator

[joerg.rich...@pdv-fs.de]

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

   Summary: stable_sort calls self-move-assignment operator
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: joerg.rich...@pdv-fs.de


$ cat t.cc
#include 
#include 
#include 

struct MyMoveClass
{
int val_;

explicit MyMoveClass( int val = 0 )
  : val_( val )
{
  std::cout << "ctr this=" << this << std::endl;
}

MyMoveClass( MyMoveClass const& rhs )
  : val_( rhs.val_ )
{
  std::cout << "ctr copy this=" << this << " rhs=" << &rhs << std::endl;
}

MyMoveClass( MyMoveClass && rhs )
  : val_( rhs.val_ )
{
  std::cout << "ctr move this=" << this << " rhs=" << &rhs << std::endl;
  rhs.val_ = 0;
}

MyMoveClass& operator=( MyMoveClass && rhs )
{
  std::cout << "assign move this=" << this << " rhs=" << &rhs << std::endl;
  assert( this != &rhs );
  val_ = rhs.val_;
  rhs.val_ = 0;
  return *this;
}

MyMoveClass& operator=( MyMoveClass const& rhs )
{
  std::cout << "assign copy this=" << this << " rhs=" << &rhs << std::endl;
  val_ = rhs.val_;
  return *this;
}

~MyMoveClass()
{
  std::cout << "dtr this=" << this << std::endl;
}

bool operator<( MyMoveClass const& rhs ) const
{
  return val_ < rhs.val_;
}
};

int main()
{
  MyMoveClass v(5);
  std::stable_sort( &v, &v+1 );
  return 0;
}


$ g++ -std=gnu++0x -o t t.cc

$ ./t
ctr this=0xbfe1730c
ctr move this=0x8afd008 rhs=0xbfe1730c
assign move this=0xbfe1730c rhs=0x8afd008
assign move this=0xbfe1730c rhs=0xbfe1730c
template: template.cc:31: MyMoveClass& MyMoveClass::operator=(MyMoveClass&&):
Assertion `this != &rhs' failed.


>From DR 1204: "Additionally this clarifies that move assignment operators need
not perform the traditional if (this != &rhs) test commonly found (and needed)
in copy assignment operators."

Note that std::sort() calls no copy constructor or assignment operator at all. 
Seems sensible when there is only one element.

[Bug c++/49558] New: Compiling gcc-3.4.5 source code on MAC OS X 10.6.3 gives an error.

[birender.cdac at gmail dot com]

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

   Summary: Compiling gcc-3.4.5 source code on MAC OS X 10.6.3
gives an error.
   Product: gcc
   Version: 3.4.5
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: birender.c...@gmail.com


While compiling gcc-3.4.5 source code on MAC OS X 10.6.3[which has gcc and cc
with version i686-apple-darwin10-gcc-4.2.1] gives an error mentioned below.


.
.
.
.
rm -f include/limits.h
cp xlimits.h include/limits.h
chmod a+r include/limits.h
rm -f include/README
cp ./README-fixinc include/README
chmod a+r include/README
echo timestamp > stmp-int-hdrs
/els/install/Rohit/gcc-3.4.5/gcc/xgcc -B/els/install/Rohit/gcc-3.4.5/gcc/
-B/usr/local/i686-apple-darwin10.3.0/bin/
-B/usr/local/i686-apple-darwin10.3.0/lib/ -isystem
/usr/local/i686-apple-darwin10.3.0/include -isystem
/usr/local/i686-apple-darwin10.3.0/sys-include -DIN_GCC-W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
 -isystem ./include  -I. -I. -I. -I./. -I./../include -I../intl  \
  -c ./config/darwin-crt2.c -o crt2.o
./config/darwin-crt2.c: In function `__darwin_gcc3_preregister_frame_info':
./config/darwin-crt2.c:151: error: unrecognizable insn:
(insn 11 9 12 0 (set (reg/f:SI 58)
(plus:SI (reg:SI 3 bx)
(const:SI (minus:SI (symbol_ref:SI
("&L___keymgr_global$non_lazy_ptr"))
(symbol_ref:SI ("")) -1 (nil)
(nil))
./config/darwin-crt2.c:151: internal compiler error: in extract_insn, at
recog.c:2083
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
make[1]: *** [crt2.o] Error 1
make: *** [install-gcc] Error 2
ssdarwinb1:gcc-3.4.5 root#

[Bug ada/49557] New: Building the GCC compiler suite fails on a Makefile concerning Ada

[arjen.markus895 at gmail dot com]

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

   Summary: Building the GCC compiler suite fails on a Makefile
concerning Ada
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: arjen.markus...@gmail.com


I can not build the GCC compiler suite (as contained in the sources from
2011-06-20, release candidate for GCC 4.6.1). It fails with the following
message:

make[4]: Entering directory
`/d/gcc4.6.1.src/gcc-4.6.1-RC-20110620/host-i686-pc-mingw32/prev-gcc'
../.././gcc/ada/gcc-interface/Make-lang.in:615: *** multiple target
patterns.  Stop.
make[4]: Leaving directory
`/d/gcc4.6.1.src/gcc-4.6.1-RC-20110620/host-i686-pc-mingw32/prev-gcc'
make[3]: *** [stmp-fixinc] Error 2
make[3]: Leaving directory
`/d/gcc4.6.1.src/gcc-4.6.1-RC-20110620/host-i686-pc-mingw32/gcc'
make[2]: *** [all-stage2-gcc] Error 2
make[2]: Leaving directory `/d/gcc4.6.1.src/gcc-4.6.1-RC-20110620'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/d/gcc4.6.1.src/gcc-4.6.1-RC-20110620'
make: *** [all] Error 2

Even when I attempt to reduce the set of languages to C and Fortran, the
error message keeps appearing.

The full configure command that I use is (the build directory is parallel
to the source directory): 

../gcc-4.6.1-RC-20110620/configure --with-gmp-include=d:/gcc4.6.1.src/gmp-5.0.2
--with-gmp-lib=d:/gcc4.6.1.src/gmp-5.0.2/.libs
--with-mpfr-include=d:/gcc4.6.1.src/mpfr-3.0.1
--with-mpfr-lib=d:/gcc4.6.1.src/mpfr-3.0.1/.libs
--with-mpc-include=d:/gcc4.6.1.src/mpc-0.9/src
--with-mpc-lib=d:/gcc4.6.1.src/mpc-0.9/src/.libs --prefix=d:/gcc4.6.1
--enable-languages=c,fortran

The compiler that is used (within the MSYS environment) is:

Using built-in specs.
COLLECT_GCC=d:\MinGW2010\bin\gfortran.exe
COLLECT_LTO_WRAPPER=d:/mingw2010/bin/../libexec/gcc/mingw32/4.5.0/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.5.0/configure
--enable-languages=c,c++,ada,fortran,objc,obj-c++ --disable-sjlj-exceptions
--with-dwarf2 --enable-shared --enable-libgomp --disable-win32-registry
--enable-libstdcxx-debug --enable-version-specific-runtime-libs
--disable-werror --build=mingw32 --prefix=/mingw
Thread model: win32
gcc version 4.5.0 (GCC) 

For completeness, here is the screen output from configure:

checking build system type... i686-pc-mingw32
checking host system type... i686-pc-mingw32
checking target system type... i686-pc-mingw32
checking for a BSD-compatible install... /bin/install -c
checking whether ln works... yes
checking whether ln -s works... no, using cp -p
checking for a sed that does not truncate output... /bin/sed
checking for gawk... gawk
checking for gcc... gcc
checking for C compiler default output file name... a.exe
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... .exe
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking for gnatbind... gnatbind
checking for gnatmake... gnatmake
checking whether compiler driver understands Ada... yes
checking how to compare bootstrapped objects... cmp --ignore-initial=16 $$f1
$$f2
checking for objdir... .libs
checking for the correct version of gmp.h... yes
checking for the correct version of mpfr.h... yes
checking for the correct version of mpc.h... yes
checking for the correct version of the gmp/mpfr/mpc libraries... yes
checking for PWL_handle_timeout in -lpwl... no
checking for version 0.11 (revision 0 or later) of PPL... no
*** This configuration is not supported in the following subdirectories:
 target-libmudflap target-libgomp target-libffi target-zlib target-libjava
gnattools target-libada target-libstdc++-v3 target-libgo target-libobjc
target-boehm-gc
(Any other directories should still work fine.)
checking for default BUILD_CONFIG... bootstrap-debug
checking for bison... bison -y
checking for bison... bison
checking for gm4... no
checking for gnum4... no
checking for m4... m4
checking for flex... flex
checking for flex... flex
checking for makeinfo... makeinfo
checking for expect... no
checking for runtest... no
checking for ar... ar
checking for as... as
checking for dlltool... dlltool
checking for ld... (cached)
d:/mingw2010/bin/../lib/gcc/mingw32/4.5.0/../../../../mingw32/bin/ld.exe
checking for lipo... no
checking for nm... nm
checking for ranlib... ranlib
checking for strip... strip
checking for windres... windres
checking for windmc... windmc
checking for objcopy... objcopy
checking for objdump... objdump
checking for cc... no
checking for gcc... gcc
checking for c++... c++
checking for gcc... gcc
checking for gcj... 

[Bug middle-end/49545] [4.7 Regression] New C++ test failures

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #3 from Jason Merrill  2011-06-28 
06:31:11 UTC ---
constexpr-ptrmem.C is now failing because the C++ ABI uses the low bit of the
function pointer field in a pointer-to-member function to indicate whether that
field is actually a function pointer or a vtable index, and constexpr-ptrmem.C
relies on being able to fold (&fn) & 1 to 0.

I assume that the ARM C++ ABI variant uses a different representation.

[Bug target/46261] avr-gcc: Segfaults when compiled with the -mint8 option

[j at uriah dot heep.sax.de]

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

--- Comment #16 from Joerg Wunsch  2011-06-28 
06:30:42 UTC ---
Created attachment 24611
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24611
Fixed the filenames in the patch header.

Fixed the filenames in the patch header (there have been two .orig too many).

I can confirm the patch fixes the issue in question on GCC trunk.

[Bug target/46261] avr-gcc: Segfaults when compiled with the -mint8 option

[j at uriah dot heep.sax.de]

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

--- Comment #15 from Joerg Wunsch  2011-06-28 
06:27:17 UTC ---
(In reply to comment #14)

> > . Regardless of whether someone votes to remove an option, a segfault
> >   should always be analyzed.

> Except that this is a segfault on a compiler switch that is unmaintained,

Did you analyze it to make sure there is no chance for this to happen
also without -mint8?

OK, I did, and it's indeed the case.

"unmaintained" — by the original maintainers.  The people contributing
(patches!) to this bug report demonstrate there actually *is* some
effort to still maintain it — by the users.

Why ignore this effort, and do it away as "we don't want to maintain
that anymore"?

The only drawback I could see with that patch is that it introduces a
couple of #ifdefs outside of the AVR code path in the compiler, to
give the AVR backend an override option for the type sizes.

> and
> there are little to no user complaints about it.

That's simply because all the compiler versions that are "out in the
field" (4.3.x, 4.4.x) still have a working (within their known
limitations, of course) -mint8 option.

Be assured, we will get complaints about it if you release another
WinAVR with a non-working -mint8 option, or with the option dropped.

> Actually it does. The attiny10 series (attiny10/4/5/9/20/40) is still what I
> would call "experimental", in that they are only in distros and not upstream,
> and you know as well as I do that there is a serious wrong-code bug with them
> anyway.

That doesn't matter much.  The wrong-code bug can (probably) be fixed,
but the integer promotion issues won't be affected by that fix.

If you don't like the reference to ATtiny10 (&Co.), just keep the
ATtiny13 (and probably also ATtiny2313, ATtiny25, ATtiny45) in your
mind by now.

> As to the other small device users,
> those devices still use avr-libc

They *can* use it.  We've always told them however, that using -mint8
and avr-libc doesn't mix.  Nevertheless, it appears to be useful
enough to some users to decide pro -mint8 (and thus against using the
library).  (It isn't even entirely true that both don't mix: a lot of
the library stuff just comes as inline functions and macros within the
header files, and this part is likely working to a large degree even
with -mint8.)

> We all know that the ideal solution is to fix the avr backend regarding
> optimizing (removing) unnecessary promotion. We can start by biting the bullet
> and removing -mint8.

I'd do it the other way around: fix the optimization issues, until the
users don't benefit from the -mint8 hack anymore.  By that time, it can
be removed without anyone complaining.

You cannot impose any pressure to the *developers* (to fix the
optimization issues) by removing the option now, but you'll cause some
impact for users of that option — users who can't do anything about it
other than voicing their complaints in public that more recent
versions of GCC get worse and worse in their usability.  I'd like to
avoid this situation.

[Bug libmudflap/38738] libmudflap could be enabled for Solaris when using GNU ld

[rob1weld at aol dot com]

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

--- Comment #8 from Rob  2011-06-28 06:18:04 UTC ---
Thanks for FIXing, every little bit helps.
Rob

[Bug java/49556] The import A cannot be resolved，But the A is placed at the current dir.

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|blocker |normal

--- Comment #1 from Andrew Pinski  2011-06-28 
06:09:20 UTC ---
I think this is correct as classes in the same packages don't cannot be
imported.

[Bug java/49556] New: The import A cannot be resolved，But the A is placed at the current dir.

[licheng.1212 at gmail dot com]

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

   Summary: The import A cannot be resolved，But the A is placed at
the current dir.
   Product: gcc
   Version: 4.4.2
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: java
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: licheng.1...@gmail.com


there is a test case:

[lee@localhost test]$ pwd
/home/lee/project/test
[lee@localhost test]$ ls
A.java  Main.java
[lee@localhost test]$ cat A.java 
public final class A {
public void a()
{
System.out.println("A print");
}
}
[lee@localhost test]$ cat Main.java 
import A;
class Main{
public static void main(String args[])
{
A a=new A();
a.a();
}
}
[lee@localhost test]$ gcj --classpath=./ -c Main.java 
Main.java:1: error: The import A cannot be resolved
import A;
   ^
1 problem (1 error)
[lee@localhost test]$ 

But when I change the A to a package,then it's OK

[lee@localhost test]$ tree
.
|-- Main.java
`-- pakfile
`-- A.java

1 directory, 2 files
[lee@localhost test]$ cat pakfile/A.java 
package pakfile;
public final class A {
public void a()
{
System.out.println("A print");
}
}
[lee@localhost test]$ cat Main.java 
import pakfile.A;
class Main{
public static void main(String args[])
{
A a=new A();
a.a();
}
}
[lee@localhost test]$ gcj --classpath=./ -c Main.java 
[lee@localhost test]$

[Bug bootstrap/49555] libjava fails to configure if --enable-symvers=gnu or --enable-symvers=sun

[bryanhundven at gmail dot com]

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

--- Comment #1 from Bryan Hundven  2011-06-28 
00:09:28 UTC ---
Meant to say libjava/configure in the previous comment.

[Bug bootstrap/49555] New: libjava fails to configure if --enable-symvers=gnu or --enable-symvers=sun

[bryanhundven at gmail dot com]

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

   Summary: libjava fails to configure if --enable-symvers=gnu or
--enable-symvers=sun
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bryanhund...@gmail.com


Other components check for --enable-symvers=gnu or --enable-symvers=sun, as
well as just yes or no.

libgcc/configure{.ac} checks only for yes or no, and if gnu or sun it fails:

configure:24535: checking whether ld supports anonymous version scripts
configure:24545: error: Unknown argument to enable/disable symvers

Code was originally added in PR bootstrap/48135

[Bug c++/49554] [4.7 Regression] [C++0x] lambda capture causes "cannot call member function ... without object"

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  2011-06-27 
23:44:05 UTC ---
No error for this version:

Base_iterator b;
b = Base::begin();

[b](int i) { return i; };

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

[jvdelisle at gcc dot gnu.org]

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

--- Comment #27 from Jerry DeLisle  2011-06-27 
23:27:23 UTC ---
Status: I have not disappeared.  I have a couple of other small projects to get
out of the way.  I did find a bit of a conflict in our code.  Two snippets that
were canceling each other out.  I have that fixed so this one is narrowing down
I think.

[Bug c++/49554] [4.7 Regression] [C++0x] lambda capture causes "cannot call member function ... without object"

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  2011-06-27 
23:26:44 UTC ---
also, if 'b' is initialized like this it works:
Base_iterator b = this->begin();

[Bug c++/49554] New: [4.7 Regression] [C++0x] lambda capture causes "cannot call member function ... without object"

[redi at gcc dot gnu.org]

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

   Summary: [4.7 Regression] [C++0x] lambda capture causes "cannot
call member function ... without object"
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
CC: ja...@gcc.gnu.org


template
  struct base
  {
struct iterator { };

iterator begin();
  };

template
class flist : public base
{
  typedef base Base;

  typedef typename Base::iterator Base_iterator;
public:

  void
  resize()
  {
Base_iterator b = Base::begin();

[b](int i) { return i; };
  }
};

void test01()
{
  flist fl;
  fl.resize();
}


objexpr.ii: In lambda function:
objexpr.ii:22:6:   required from ‘struct flist::resize() [with T =
int]::’
objexpr.ii:22:5:   required from ‘void flist::resize() [with T = int]’
objexpr.ii:29:13:   required from here
objexpr.ii:20:19: error: cannot call member function ‘base::iterator
base::begin() [with T = int]’ without object

If 'b' is not captured there's no error

This breaks  in libstdc++

[Bug ada/49539] [4.7 regression] ICE building gnattools

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #5 from Eric Botcazou  2011-06-27 
23:24:20 UTC ---
Thanks.  Investigating.

[Bug target/47315] ICE: in extract_insn, at recog.c:2109 (unrecognizable insn) with -mvzeroupper and __attribute__((target("avx")))

[hjl.tools at gmail dot com]

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

--- Comment #5 from H.J. Lu  2011-06-27 23:01:16 
UTC ---
(In reply to comment #4)
> (In reply to comment #2)
> > A patch is posted at
> > 
> > http://gcc.gnu.org/ml/gcc-patches/2011-05/msg01649.html
> 
> H.J., Since this bug shows up in gcc 4.6, could you backport to gcc 4.6
> branch? Thanks,
> 

I have no plan to backport. Please feel free to backport.

[Bug target/47315] ICE: in extract_insn, at recog.c:2109 (unrecognizable insn) with -mvzeroupper and __attribute__((target("avx")))

[changpeng.fang at amd dot com]

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

Changpeng Fang  changed:

   What|Removed |Added

 CC||changpeng.fang at amd dot
   ||com

--- Comment #4 from Changpeng Fang  2011-06-27 
22:54:47 UTC ---
(In reply to comment #2)
> A patch is posted at
> 
> http://gcc.gnu.org/ml/gcc-patches/2011-05/msg01649.html

H.J., Since this bug shows up in gcc 4.6, could you backport to gcc 4.6
branch? Thanks,

Changpeng

[Bug target/49526] extra move instruction for smmul

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.06.27 21:59:03
 CC||rearnsha at gcc dot gnu.org
 Ever Confirmed|0   |1

[Bug target/49526] extra move instruction for smmul

[rearnsha at gcc dot gnu.org]

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

--- Comment #2 from Richard Earnshaw  2011-06-27 
21:58:26 UTC ---
Confirmed.  Also need patterns for the accumulate and subtract variants, plus
rounding variants.

[Bug libstdc++/49553] mt19937 number generator is broken on 64bit systems

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX

--- Comment #2 from Paolo Carlini  2011-06-27 
21:54:09 UTC ---
No, the problem isn't in that typedef, which must be like that, per TR1. The
problem is a limitation of the tr1::uniform_int which doesn't work for an
UniformRandomNumberGenerator which generates numbers in a range smaller than
the required uniform_int output range (see the XXX comment). Fixing that was
not trivial, but it is now fixed in the C++0x uniform_int, whereas the TR1 code
ad this time is frozen, I'm sorry, if you still want to use it, please work
around the limitation (there are many ways).

[Bug target/46261] avr-gcc: Segfaults when compiled with the -mint8 option

[eric.weddington at atmel dot com]

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

--- Comment #14 from Eric Weddington  
2011-06-27 21:49:18 UTC ---
> 
> Two things to consider:
> 
> . Regardless of whether someone votes to remove an option, a segfault
>   should always be analyzed.  It's easy enough to otherwise just hide
>   an error that will only reappear later on.

Except that this is a segfault on a compiler switch that is unmaintained, and
there are little to no user complaints about it. I would say remove the
offending item and then fix anything if needed.


> . As long as the AVR backend has a substantial number of PRs open about
>   "missed optimization", related to [u]int8_t -> int promotions, the
>   -mint8 option should stay, 

There are PRs open regarding missed optimization in this category. I'm not sure
what is required to meet "substantial".

> as it appears to be useful in particular
>   to people using very small controllers (ATtiny13, also think about
>   the new ATtiny4/5/6/9 series).  Non-applicability of this option to
>   avr-libc is not a serious issue for those targets anyway, so this
>   (counter-)argument doesn't count here.

Actually it does. The attiny10 series (attiny10/4/5/9/20/40) is still what I
would call "experimental", in that they are only in distros and not upstream,
and you know as well as I do that there is a serious wrong-code bug with them
anyway. So those users don't even count. As to the other small device users,
those devices still use avr-libc and there has been opportunity for users to
complain through various channels (gcc, avr-gcc-list, avr-libc-dev) that -mint8
doesn't work. While we have had some complaints in the past, there haven't been
much recently. You and I have also been telling users that -mint8 doesn't work
with avr-libc and that it is unmaintained.

We all know that the ideal solution is to fix the avr backend regarding
optimizing (removing) unnecessary promotion. We can start by biting the bullet
and removing -mint8.

Eric

[Bug target/25343] [4.4/4.5/4.6/4.7 regression] [m68k] testsuite failures

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

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

Andreas Schwab  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED
   Target Milestone|4.4.7   |4.4.0

--- Comment #17 from Andreas Schwab  2011-06-27 21:47:56 
UTC ---
Already fixed in 4.4.0.

[Bug libstdc++/49553] mt19937 number generator is broken on 64bit systems

[boris at dolgov dot name]

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

--- Comment #1 from Boris Dolgov  2011-06-27 21:40:09 
UTC ---
Created attachment 24610
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24610
Replace magic numbers to __WORDSIZE and __WORDSIZE-1

The attached patch solves the problem for me.

[Bug libstdc++/49553] New: mt19937 number generator is broken on 64bit systems

[boris at dolgov dot name]

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

   Summary: mt19937 number generator is broken on 64bit systems
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bo...@dolgov.name


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

Hello!

On 64bit-platforms std::tr1::uniform_int with use of mt19937 gives absolutely
not uniform distribution. I have attached a testcase to reproduce the bug.

The expected behaviour:
[boris@vaioz gcc-bug]$ ./test-case 
Got upperbound: 18445007523721859962
Expected upperbound: 18446744073709551615

Actual behaviour:
[boris@vaioz gcc-bug]$ ./test-case 
Got upperbound: 4294964877
Expected upperbound: 18446744073709551615

My system is Fedora 15.
gcc -v:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.6.0/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin
--enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-ppl --with-cloog --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.6.0 20110530 (Red Hat 4.6.0-9) (GCC) 

uname -a:
[boris@vaioz gcc-bug]$ uname -a
Linux vaioz 2.6.39-1.fc15.x86_64 #1 SMP Fri May 27 18:02:25 MSD 2011 x86_64
x86_64 x86_64 GNU/Linux

compile command:
g++ -o test-case test-case.cpp


As far as I understand, this happens because of passing an incorrect state_size
parameter to mersenne_twister template.

[Bug target/48637] %c in ARM inline asm leads to ICE (in arm_print_operand)

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Earnshaw  2011-06-27 
21:12:03 UTC ---
Fixed on trunk

[Bug target/48637] %c in ARM inline asm leads to ICE (in arm_print_operand)

[rearnsha at gcc dot gnu.org]

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

--- Comment #3 from Richard Earnshaw  2011-06-27 
21:09:32 UTC ---
Author: rearnsha
Date: Mon Jun 27 21:09:25 2011
New Revision: 175565

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175565
Log:
PR target/48637
* arm.c (arm_print_operand): Allow sym+offset.  Don't abort on invalid
asm operands.

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

[Bug other/47733] psignal (int, const? char*) in libiberty/strsignal.h

[hp at gcc dot gnu.org]

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

--- Comment #5 from Hans-Peter Nilsson  2011-06-27 
21:03:00 UTC ---
Author: hp
Date: Mon Jun 27 21:02:53 2011
New Revision: 175564

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175564
Log:
PR regression/47836
PR bootstrap/23656
PR other/47733
PR bootstrap/49247
PR c/48825
* configure.ac (target_libraries): Remove target-libiberty.
Remove all target-specific settings adding target-libiberty to
skipdirs and noconfigdirs.  Remove checking target_configdirs
and removing target-libiberty but keeping target-libgcc if
otherwise empty.
* Makefile.def (target_modules): Don't add libiberty.
(dependencies): Remove all traces of target-libiberty.
* configure, Makefile.in: Regenerate.

Modified:
branches/gcc-4_5-branch/ChangeLog
branches/gcc-4_5-branch/Makefile.def
branches/gcc-4_5-branch/Makefile.in
branches/gcc-4_5-branch/configure
branches/gcc-4_5-branch/configure.ac

[Bug c/48825] libiberty "psignal" lacks const modifier, failing to compile when HAVE_PSIGNAL is undefined

[hp at gcc dot gnu.org]

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

--- Comment #9 from Hans-Peter Nilsson  2011-06-27 
21:03:01 UTC ---
Author: hp
Date: Mon Jun 27 21:02:53 2011
New Revision: 175564

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175564
Log:
PR regression/47836
PR bootstrap/23656
PR other/47733
PR bootstrap/49247
PR c/48825
* configure.ac (target_libraries): Remove target-libiberty.
Remove all target-specific settings adding target-libiberty to
skipdirs and noconfigdirs.  Remove checking target_configdirs
and removing target-libiberty but keeping target-libgcc if
otherwise empty.
* Makefile.def (target_modules): Don't add libiberty.
(dependencies): Remove all traces of target-libiberty.
* configure, Makefile.in: Regenerate.

Modified:
branches/gcc-4_5-branch/ChangeLog
branches/gcc-4_5-branch/Makefile.def
branches/gcc-4_5-branch/Makefile.in
branches/gcc-4_5-branch/configure
branches/gcc-4_5-branch/configure.ac

[Bug bootstrap/49247] libiberty configure assumes newlib does not supply psignal

[hp at gcc dot gnu.org]

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

--- Comment #4 from Hans-Peter Nilsson  2011-06-27 
21:03:00 UTC ---
Author: hp
Date: Mon Jun 27 21:02:53 2011
New Revision: 175564

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175564
Log:
PR regression/47836
PR bootstrap/23656
PR other/47733
PR bootstrap/49247
PR c/48825
* configure.ac (target_libraries): Remove target-libiberty.
Remove all target-specific settings adding target-libiberty to
skipdirs and noconfigdirs.  Remove checking target_configdirs
and removing target-libiberty but keeping target-libgcc if
otherwise empty.
* Makefile.def (target_modules): Don't add libiberty.
(dependencies): Remove all traces of target-libiberty.
* configure, Makefile.in: Regenerate.

Modified:
branches/gcc-4_5-branch/ChangeLog
branches/gcc-4_5-branch/Makefile.def
branches/gcc-4_5-branch/Makefile.in
branches/gcc-4_5-branch/configure
branches/gcc-4_5-branch/configure.ac

[Bug regression/47836] Some Cross Compiler can't build target-libiberty or target-zlib

[hp at gcc dot gnu.org]

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

--- Comment #17 from Hans-Peter Nilsson  2011-06-27 
21:02:59 UTC ---
Author: hp
Date: Mon Jun 27 21:02:53 2011
New Revision: 175564

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175564
Log:
PR regression/47836
PR bootstrap/23656
PR other/47733
PR bootstrap/49247
PR c/48825
* configure.ac (target_libraries): Remove target-libiberty.
Remove all target-specific settings adding target-libiberty to
skipdirs and noconfigdirs.  Remove checking target_configdirs
and removing target-libiberty but keeping target-libgcc if
otherwise empty.
* Makefile.def (target_modules): Don't add libiberty.
(dependencies): Remove all traces of target-libiberty.
* configure, Makefile.in: Regenerate.

Modified:
branches/gcc-4_5-branch/ChangeLog
branches/gcc-4_5-branch/Makefile.def
branches/gcc-4_5-branch/Makefile.in
branches/gcc-4_5-branch/configure
branches/gcc-4_5-branch/configure.ac

[Bug bootstrap/23656] Cross-compilation with newlib fails in libiberty

[hp at gcc dot gnu.org]

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

--- Comment #5 from Hans-Peter Nilsson  2011-06-27 
21:02:58 UTC ---
Author: hp
Date: Mon Jun 27 21:02:53 2011
New Revision: 175564

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175564
Log:
PR regression/47836
PR bootstrap/23656
PR other/47733
PR bootstrap/49247
PR c/48825
* configure.ac (target_libraries): Remove target-libiberty.
Remove all target-specific settings adding target-libiberty to
skipdirs and noconfigdirs.  Remove checking target_configdirs
and removing target-libiberty but keeping target-libgcc if
otherwise empty.
* Makefile.def (target_modules): Don't add libiberty.
(dependencies): Remove all traces of target-libiberty.
* configure, Makefile.in: Regenerate.

Modified:
branches/gcc-4_5-branch/ChangeLog
branches/gcc-4_5-branch/Makefile.def
branches/gcc-4_5-branch/Makefile.in
branches/gcc-4_5-branch/configure
branches/gcc-4_5-branch/configure.ac

[Bug fortran/49466] [4.6/4.7 Regression] Memory leak with assignment of extended derived types

[janus at gcc dot gnu.org]

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

--- Comment #9 from janus at gcc dot gnu.org 2011-06-27 20:59:16 UTC ---
Author: janus
Date: Mon Jun 27 20:59:12 2011
New Revision: 175563

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

PR fortran/49466
* trans-array.c (structure_alloc_comps): Make sure sub-components
and extended types are correctly deallocated.


2011-06-27  Janus Weil  

PR fortran/49466
* gfortran.dg/allocatable_scalar_9.f90: Modified.
* gfortran.dg/extends_14.f03: Modified.

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

[Bug regression/47836] Some Cross Compiler can't build target-libiberty or target-zlib

[hp at gcc dot gnu.org]

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

--- Comment #16 from Hans-Peter Nilsson  2011-06-27 
20:55:03 UTC ---
Author: hp
Date: Mon Jun 27 20:54:59 2011
New Revision: 175560

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175560
Log:
PR regression/47836
PR bootstrap/23656
PR other/47733
PR bootstrap/49247
PR c/48825
* configure.ac (target_libraries): Remove target-libiberty.
Remove all target-specific settings adding target-libiberty to
skipdirs and noconfigdirs.  Remove checking target_configdirs
and removing target-libiberty but keeping target-libgcc if
otherwise empty.
* Makefile.def (target_modules): Don't add libiberty.
(dependencies): Remove all traces of target-libiberty.
* configure, Makefile.in: Regenerate.

Modified:
branches/gcc-4_6-branch/ChangeLog
branches/gcc-4_6-branch/Makefile.def
branches/gcc-4_6-branch/Makefile.in
branches/gcc-4_6-branch/configure
branches/gcc-4_6-branch/configure.ac

[Bug other/47733] psignal (int, const? char*) in libiberty/strsignal.h

[hp at gcc dot gnu.org]

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

--- Comment #4 from Hans-Peter Nilsson  2011-06-27 
20:55:04 UTC ---
Author: hp
Date: Mon Jun 27 20:54:59 2011
New Revision: 175560

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175560
Log:
PR regression/47836
PR bootstrap/23656
PR other/47733
PR bootstrap/49247
PR c/48825
* configure.ac (target_libraries): Remove target-libiberty.
Remove all target-specific settings adding target-libiberty to
skipdirs and noconfigdirs.  Remove checking target_configdirs
and removing target-libiberty but keeping target-libgcc if
otherwise empty.
* Makefile.def (target_modules): Don't add libiberty.
(dependencies): Remove all traces of target-libiberty.
* configure, Makefile.in: Regenerate.

Modified:
branches/gcc-4_6-branch/ChangeLog
branches/gcc-4_6-branch/Makefile.def
branches/gcc-4_6-branch/Makefile.in
branches/gcc-4_6-branch/configure
branches/gcc-4_6-branch/configure.ac

[Bug c/48825] libiberty "psignal" lacks const modifier, failing to compile when HAVE_PSIGNAL is undefined

[hp at gcc dot gnu.org]

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

--- Comment #8 from Hans-Peter Nilsson  2011-06-27 
20:55:04 UTC ---
Author: hp
Date: Mon Jun 27 20:54:59 2011
New Revision: 175560

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175560
Log:
PR regression/47836
PR bootstrap/23656
PR other/47733
PR bootstrap/49247
PR c/48825
* configure.ac (target_libraries): Remove target-libiberty.
Remove all target-specific settings adding target-libiberty to
skipdirs and noconfigdirs.  Remove checking target_configdirs
and removing target-libiberty but keeping target-libgcc if
otherwise empty.
* Makefile.def (target_modules): Don't add libiberty.
(dependencies): Remove all traces of target-libiberty.
* configure, Makefile.in: Regenerate.

Modified:
branches/gcc-4_6-branch/ChangeLog
branches/gcc-4_6-branch/Makefile.def
branches/gcc-4_6-branch/Makefile.in
branches/gcc-4_6-branch/configure
branches/gcc-4_6-branch/configure.ac

[Bug bootstrap/49247] libiberty configure assumes newlib does not supply psignal

[hp at gcc dot gnu.org]

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

--- Comment #3 from Hans-Peter Nilsson  2011-06-27 
20:55:04 UTC ---
Author: hp
Date: Mon Jun 27 20:54:59 2011
New Revision: 175560

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175560
Log:
PR regression/47836
PR bootstrap/23656
PR other/47733
PR bootstrap/49247
PR c/48825
* configure.ac (target_libraries): Remove target-libiberty.
Remove all target-specific settings adding target-libiberty to
skipdirs and noconfigdirs.  Remove checking target_configdirs
and removing target-libiberty but keeping target-libgcc if
otherwise empty.
* Makefile.def (target_modules): Don't add libiberty.
(dependencies): Remove all traces of target-libiberty.
* configure, Makefile.in: Regenerate.

Modified:
branches/gcc-4_6-branch/ChangeLog
branches/gcc-4_6-branch/Makefile.def
branches/gcc-4_6-branch/Makefile.in
branches/gcc-4_6-branch/configure
branches/gcc-4_6-branch/configure.ac

[Bug bootstrap/23656] Cross-compilation with newlib fails in libiberty

[hp at gcc dot gnu.org]

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

--- Comment #4 from Hans-Peter Nilsson  2011-06-27 
20:55:02 UTC ---
Author: hp
Date: Mon Jun 27 20:54:59 2011
New Revision: 175560

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175560
Log:
PR regression/47836
PR bootstrap/23656
PR other/47733
PR bootstrap/49247
PR c/48825
* configure.ac (target_libraries): Remove target-libiberty.
Remove all target-specific settings adding target-libiberty to
skipdirs and noconfigdirs.  Remove checking target_configdirs
and removing target-libiberty but keeping target-libgcc if
otherwise empty.
* Makefile.def (target_modules): Don't add libiberty.
(dependencies): Remove all traces of target-libiberty.
* configure, Makefile.in: Regenerate.

Modified:
branches/gcc-4_6-branch/ChangeLog
branches/gcc-4_6-branch/Makefile.def
branches/gcc-4_6-branch/Makefile.in
branches/gcc-4_6-branch/configure
branches/gcc-4_6-branch/configure.ac

[Bug c/49551] common variables and -fdata-sections cause ICE in C front-end.

[dougkwan at google dot com]

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

--- Comment #1 from Doug Kwan  2011-06-27 20:47:59 
UTC ---
The variable x in the test case is should not be a common variable but the
DECL_COMMON is set after merging the first and the second declarations.  That
ultimately leads to an ICE.

[Bug middle-end/35561] Promote written once local aggregates to static

[xinliangli at gmail dot com]

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

--- Comment #10 from davidxl  2011-06-27 20:44:56 
UTC ---
Agree. Such optimization should not be done in gimplication, Nor should the
const keyword be looked at.  It should be done in middle end where local
aggregate are analyzed:

1) the aggregate is only written once with constant initializer -- this
implies that address of such aggregate is not escaped
2) all uses of the aggregate are dominated by the initialization statement
3) address of aggregate is not used comparison.

David


On Thu, Jun 23, 2011 at 6:31 AM, jakub at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35561
>
> Jakub Jelinek  changed:
>
>   What|Removed |Added
>
> 
> CC||jakub at gcc dot gnu.org
>
> --- Comment #9 from Jakub Jelinek  2011-06-23
> 13:31:01 UTC ---
> Well, we could still optimize it e.g. in leaf functions or in functions
> that
> only call leaf functions (__attribute__((leaf))).  But we do this
> transformation during gimplification, so either we'd need to add an
> optimization that would turn an automatic aggregate into static aggregate
> if
> possible and useful later on (in particular, if it is determined to be
> never
> written into and its value doesn't escape current function or current
> function
> is leaf or only calls leaf functions and doesn't tail recurse), or we'd
> need to
> do some analysis right before gimplification starts to find out if a
> function
> must be leaf or only call leaf functions.
>
> --
> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
> --- You are receiving this mail because: ---
> You reported the bug.
>

[Bug c++/36435] Partial ordering of explicit specialization should include return type

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #3 from Jason Merrill  2011-06-27 
20:20:31 UTC ---
fixed for 4.7.

[Bug c++/49528] [4.6 regression] g++ fails to destroy temporary object when subobject is used to initialize a reference

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #6 from Jason Merrill  2011-06-27 
20:19:23 UTC ---
Fixed for 4.6.2.

[Bug c++/49440] [4.6 regression] Invalid dynamic_cast for unnamed namespace

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #7 from Jason Merrill  2011-06-27 
20:18:40 UTC ---
Fixed for 4.5.4 and 4.6.2.

[Bug c++/49418] [4.6 regression] G++ discards cv-quals from template parameter types

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #11 from Jason Merrill  2011-06-27 
20:18:04 UTC ---
Fixed for 4.6.2.

[Bug c++/49528] [4.6 regression] g++ fails to destroy temporary object when subobject is used to initialize a reference

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  2011-06-27 
20:16:21 UTC ---
Author: jason
Date: Mon Jun 27 20:16:14 2011
New Revision: 175559

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175559
Log:
PR c++/49528
* semantics.c (potential_constant_expression_1): A TARGET_EXPR
of non-literal type isn't constant.
(cxx_eval_constant_expression): Likewise.
* init.c (expand_default_init): Use maybe_constant_init.

Added:
branches/gcc-4_6-branch/gcc/testsuite/g++.dg/cpp0x/constexpr-cleanup.C
branches/gcc-4_6-branch/gcc/testsuite/g++.dg/init/ref19.C
Modified:
branches/gcc-4_6-branch/gcc/cp/ChangeLog
branches/gcc-4_6-branch/gcc/cp/init.c
branches/gcc-4_6-branch/gcc/cp/semantics.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug c++/49440] [4.6 regression] Invalid dynamic_cast for unnamed namespace

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  2011-06-27 
20:16:08 UTC ---
Author: jason
Date: Mon Jun 27 20:16:02 2011
New Revision: 175558

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175558
Log:
PR c++/49440
* class.c (set_linkage_according_to_type): Hand off to
determine_visibility.

Added:
branches/gcc-4_6-branch/gcc/testsuite/g++.dg/rtti/anon-ns1.C
Modified:
branches/gcc-4_6-branch/gcc/cp/ChangeLog
branches/gcc-4_6-branch/gcc/cp/class.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug c++/49418] [4.6 regression] G++ discards cv-quals from template parameter types

[jason at gcc dot gnu.org]

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

--- Comment #10 from Jason Merrill  2011-06-27 
20:15:56 UTC ---
Author: jason
Date: Mon Jun 27 20:15:49 2011
New Revision: 175557

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175557
Log:
PR c++/49418
* call.c (cxx_type_promotes_to): Don't strip cv-quals.
* semantics.c (lambda_return_type): Strip them here.

Added:
branches/gcc-4_6-branch/gcc/testsuite/g++.dg/template/param3.C
Modified:
branches/gcc-4_6-branch/gcc/cp/ChangeLog
branches/gcc-4_6-branch/gcc/cp/call.c
branches/gcc-4_6-branch/gcc/cp/semantics.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug middle-end/49543] Cast move causes incorrect code and numerical results

[acarmeli at mathworks dot com]

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

--- Comment #5 from Alexander Carmeli  
2011-06-27 20:15:37 UTC ---
That's a good point. I removed the const and g++ fails as well.

Therefore, the bug is in the C++ compiler too.

Consts can be promoted as well. Why promote the non-const expression and not
promote the const expression? The const expression is constant-folded as a
32-bit subtraction. Therefore, so should the non-const expression. Otherwise,
numerical results depend on the arguments being const or not, and that's
problematic.

My claims still hold: 
- Expression folding should not change numerical results compared to
  unfolded expressions.
- It is not okay to promote to 64 bit. The value is undefined. The size is.
- If -pedantic compiles, it should generate he same results as without
  -pedantic.

[Bug ada/42554] Can't build GNAT tools

[gcc at microbizz dot nl]

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

Adriaan van Os  changed:

   What|Removed |Added

 CC||gcc at microbizz dot nl

--- Comment #15 from Adriaan van Os  2011-06-27 
20:13:45 UTC ---
The patch is incomplete. The same logic must be applied to gcc/configure.ac and
gcc/configure too.

[Bug middle-end/49543] Cast move causes incorrect code and numerical results

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  2011-06-27 
19:25:37 UTC ---
Well C++ is not C, that is Data is a constant expression in C++ but not in C.

[Bug c++/34772] [4.4/4.5/4.6 Regression] self-initialisation does not silence uninitialised warnings (-Winit-self ignored)

[davi.arnaut at oracle dot com]

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

--- Comment #22 from Davi Arnaut  2011-06-27 
19:15:45 UTC ---
(In reply to comment #21)
>> Actually, we would really like it. Currently, we have to disable it because
>> most of the warnings are bogus. New _valid_ warnings are welcome.
>
> If you think most -Winit-self warnings are bogus, this fix cannot help you.

Sorry, I wasn't talking about -Winit-self warnings. I meant that most
uninitialised warnings in C++ are bogus [1]. Hence, we have to work around this
by actually initializing certain variables. By initializing the variable we
lose coverage by tools such as valgrind,. The self-initialization trick allow
us to avoid this problem.

Also, we even had a runtime "performance issue" associated with it in debug
builds. A large structure (containing floats, etc) needed to be partially
initialized to silence the warnings, but it caused a penalty since it was
located in a hot function (ended up slowing our test suite).

Anyway, point is, it would be nice to have this fixed in the early 4.x
branches.

1. I believe there is a bug report about this.

[Bug fortran/49479] [4.6/4.7 Regression] reshape / optionals / zero sized arrays

[tkoenig at gcc dot gnu.org]

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

--- Comment #6 from Thomas Koenig  2011-06-27 
19:02:12 UTC ---
A patch suggested by comment #4 fixes the failure.

Regression-testing.

[Bug tree-optimization/49552] New: missed optimization: test for zero remainder after division by a constant.

[wouter.vermaelen at scarlet dot be]

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

   Summary: missed optimization: test for zero remainder after
division by a constant.
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: wouter.vermae...@scarlet.be


Just like there are tricks to transform a division by a constant into a
multiplication and some shifts, there are also tricks to test if the remainder
of some division by a constant will be equal to zero.

Some examples:

bool is_mod3_zero(unsigned x)
{
// equivalent to: return (x % 3) == 0;
return (x * 0xaaab) <= (0x / 3);
}

bool is_mod28_zero(unsigned x)
{
// equivalent to: return (x % 28) == 0;
// return !(x & 3) && ((x * 0xb6db6db7) <= (0x / 7));
return rotateRight(x * 0xb6db6db7, 2) <= (0x / 28);
}

bool is_signed_mod28_zero(int x)
{
// equivalent to: return (x % 28) == 0;
const unsigned c = (0x7fff / 7) & -(1 << 2);
unsigned q = rotateRight((x * 0xb6db6db7) + c, 2);
return q <= (c >> (2 - 1));
}


I found this trick in the book "Hacker's delight", chapter 10-16 "Test for Zero
Remainder after Division by a Constant". The book also explains the theory
behind this transformation.

It would be nice if gcc could automatically perform this optimization.



Bonus:

bool is_mod3_one(unsigned x)
{
// equivalent to: return (x % 3) == 1;
// only correct if 'x + 2' does not overflow
//(sometimes this can be derived from VRP)
return ((x + (3 - 1)) * 0xaaab) <= (0x / 3);
}

[Bug middle-end/49543] Cast move causes incorrect code and numerical results

[acarmeli at mathworks dot com]

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

--- Comment #3 from Alexander Carmeli  
2011-06-27 18:40:25 UTC ---
Andrew,

You are correct about the standard not defining the result.

Similar behavior was fixed before (see bug 36300
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36300)

I think this is still a bug, for 3 reasons:

1. the standard also defines the subtraction operation and its result to be
32-bit. The compiler is not free to up-cast it prematurely to a bigger size for
optimization purposes. This was the same in 36300.

2. Relying on overflow behavior of 2's complement machines is extremely
popular. Having the same expression behave differently in folded and unfolded
expressions can lead to many unexpected behaviors. In addition:
2.1. Unoptimized code misbehaves, optimized code is well behaved - this is
unexpected.
2.2. The C++ compiler does generate the expected numerical behavior under all
conditions, without -fwrapv.

3. In my opinion, -pedantic should not affect compiler semantics. It should
only control warning messages (correct me if I got this wrong).


As for the result being undefined (value, not size), the standard primarily
keeps the options open for non-2's complement machines and machines with
non-traditional logic.

[Bug c/49551] New: common variables and -fdata-sections cause ICE in C front-end.

[dougkwan at google dot com]

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

   Summary: common variables and -fdata-sections cause ICE in C
front-end.
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dougk...@google.com


The following 2 line cause both gcc-4.6.0 and trunk to crash:

---bug.c---
int x = 1;
int x;
---
$ arm-unknown-linux-gnueabi-gcc -O -fdata-sections bug.c
bug.c:2:1: internal compiler error: in get_variable_section, at varasm.c:1004
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
$ arm-unknown-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=install/bin/arm-unknown-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/usr/local/google2/home/dougkwan/gcc-trunk-1/install/bin/../libexec/gcc/arm-unknown-linux-gnueabi/4.7.0/lto-wrapper
Target: arm-unknown-linux-gnueabi
Configured with: ../gcc/configure --target=arm-unknown-linux-gnueabi
--disable-bootstrap --enable-languages=c --with-gmp=/home/dougkwan/gcc-lib
--with-sysroot=/home/dougkwan/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root
Thread model: posix
gcc version 4.7.0 20110607 (experimental) (GCC)

[Bug middle-end/49191] gcc.dg/memcpy-3.c FAILs on SPARC

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.6.2

--- Comment #15 from Eric Botcazou  2011-06-27 
18:07:07 UTC ---
Thanks for the fix.

[Bug c++/18016] Warn about member variables initialized with itself

[ejb at ql dot org]

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

--- Comment #14 from ejb at ql dot org 2011-06-27 18:06:15 UTC ---
Very nice to see this bug fixed. :-)

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

[janis at gcc dot gnu.org]

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

--- Comment #11 from Janis Johnson  2011-06-27 
18:05:41 UTC ---
I have confirmed that the -Os failures began with r175063 and that the tests
pass for several revision before that and pass for several after, so it's
unlikely to be an intermittent failure.  If it would help I can send dump files
for r175063 and the one just before that.

[Bug c++/34772] [4.4/4.5/4.6 Regression] self-initialisation does not silence uninitialised warnings (-Winit-self ignored)

[manu at gcc dot gnu.org]

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

--- Comment #21 from Manuel López-Ibáñez  2011-06-27 
18:01:40 UTC ---
(In reply to comment #20)
> Actually, we would really like it. Currently, we have to disable it because
> most of the warnings are bogus. New _valid_ warnings are welcome.

If you think most -Winit-self warnings are bogus, this fix cannot help you.

[Bug middle-end/49191] gcc.dg/memcpy-3.c FAILs on SPARC

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  2011-06-27 
17:55:40 UTC ---
Author: jakub
Date: Mon Jun 27 17:55:35 2011
New Revision: 175544

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175544
Log:
Backported from mainline
2011-06-26  Jakub Jelinek  

PR tree-optimization/48377
* gcc.dg/vect/pr48377.c: Add dg-require-effective-target
non_strict_align.

2011-06-26  Steve Ellcey  

PR middle-end/49191
* lib/target-supports.exp (check_effective_target_non_strict_align):
New.

Modified:
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/vect/pr48377.c
branches/gcc-4_6-branch/gcc/testsuite/lib/target-supports.exp

[Bug tree-optimization/48377] [4.6/4.7 regression] miscompilation at -O3

[jakub at gcc dot gnu.org]

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

--- Comment #47 from Jakub Jelinek  2011-06-27 
17:55:40 UTC ---
Author: jakub
Date: Mon Jun 27 17:55:35 2011
New Revision: 175544

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175544
Log:
Backported from mainline
2011-06-26  Jakub Jelinek  

PR tree-optimization/48377
* gcc.dg/vect/pr48377.c: Add dg-require-effective-target
non_strict_align.

2011-06-26  Steve Ellcey  

PR middle-end/49191
* lib/target-supports.exp (check_effective_target_non_strict_align):
New.

Modified:
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/vect/pr48377.c
branches/gcc-4_6-branch/gcc/testsuite/lib/target-supports.exp

[Bug libmudflap/49550] Many libmudflap tests fail on Solaris 11/x86

[ro at gcc dot gnu.org]

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

--- Comment #1 from Rainer Orth  2011-06-27 17:47:20 UTC 
---
Created attachment 24608
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24608
Solaris 11/x86 testsuite log (both multilibs) with Sun ld

[Bug libmudflap/49550] New: Many libmudflap tests fail on Solaris 11/x86

[ro at gcc dot gnu.org]

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

   Summary: Many libmudflap tests fail on Solaris 11/x86
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libmudflap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
CC: f...@redhat.com
  Host: i386-pc-solaris2.11
Target: i386-pc-solaris2.11
 Build: i386-pc-solaris2.11


Many libmudflap tests currently fail on Solaris 11/x86 with Sun ld (GNU ld
is similar).  Since I cannot yet reliably group them (I strongly suppose there
are a few common root causes), I'm attaching the full testsuite log.

I'd be grateful if Frank could have a look and point me at possible issues to
investigate.

Thanks.
  Rainer

[Bug fortran/49112] [4.6/4.7 Regression] [OOP] Missing type-bound procedure, "duplicate save" warnings and internal compiler error

[janus at gcc dot gnu.org]

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

--- Comment #16 from janus at gcc dot gnu.org 2011-06-27 17:45:29 UTC ---
(In reply to comment #14)
> The "duplicate save" regression is fixed on trunk and 4.6. Remaining problems:
> 
> 1) The structure constructor regression in comment #6.
> 2) The ICE in comment #7.

The latter is tracked by the related PR49430, so for this PR only the
regression in comment #6 is left to fix.

[Bug middle-end/49543] Cast move causes incorrect code and numerical results

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  2011-06-27 
17:40:01 UTC ---
/* Data - 1 overflows */

Yes that would mean it is undefined code.  Try -fwrapv.

[Bug libmudflap/49549] New: Use of --noinhibit-exec is unportable

[ro at gcc dot gnu.org]

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

   Summary: Use of --noinhibit-exec is unportable
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libmudflap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
CC: f...@redhat.com
  Host: i386-pc-solaris2.11
Target: i386-pc-solaris2.11
 Build: i386-pc-solaris2.11


Use of -Wl,--noinhibit-exec in the libmudflap testsuite
(libmudflap.cth/cthfrags.exp) is unportable.  The Solaris linker doesn't
understand it, causing all affected testcases to fail:

spawn /var/gcc/gcc-4.7.0-20110617/11-gcc/gcc/xgcc
-B/var/gcc/gcc-4.7.0-20110617/11-gcc/gcc/ -ggdb3 -DDEBUG_ASSERT
-I/vol/gcc/src/hg/trunk/solaris/libmudflap/testsuite
-I/vol/gcc/src/hg/trunk/solaris/libmudflap/testsuite/.. -I..
-L/var/gcc/gcc-4.7.0-20110617/11-gcc/i386-pc-solaris2.11/./libmudflap/.libs
/vol/gcc/src/hg/trunk/solaris/libmudflap/testsuite/libmudflap.cth/pass37-frag.c
-fmudflapth -lmudflapth -lpthread -Wl,--noinhibit-exec
-L/var/gcc/gcc-4.7.0-20110617/11-gcc/i386-pc-solaris2.11/./libmudflap/testsuite
-lsocket -ldl -lm -o ./pass37-frag.exe

ld: fatal: unrecognized option '--'

ld: fatal: use the -z help option for usage information

collect2: error: ld returned 1 exit status

compiler exited with status 1

[Bug fortran/49466] [4.6/4.7 Regression] Memory leak with assignment of extended derived types

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #8 from janus at gcc dot gnu.org 2011-06-27 17:33:19 UTC ---
(In reply to comment #7)
> This is due to revision 165973:


... and fixed by a partial revert of this commit (see below), which is free of
testsuite regressions. Will commit as obvious soon (unfortunately too late for
the 4.6.1 release).


Index: gcc/testsuite/gfortran.dg/allocatable_scalar_9.f90
===
--- gcc/testsuite/gfortran.dg/allocatable_scalar_9.f90(revision 175536)
+++ gcc/testsuite/gfortran.dg/allocatable_scalar_9.f90(working copy)
@@ -49,7 +49,7 @@ if(allocated(na3%b3)) call abort()
 if(allocated(na4%b4)) call abort()
 end

-! { dg-final { scan-tree-dump-times "__builtin_free" 32 "original" } }
+! { dg-final { scan-tree-dump-times "__builtin_free" 38 "original" } }
 ! { dg-final { cleanup-tree-dump "original" } }

 ! { dg-final { cleanup-modules "m" } }
Index: gcc/fortran/trans-array.c
===
--- gcc/fortran/trans-array.c(revision 175536)
+++ gcc/fortran/trans-array.c(working copy)
@@ -6682,18 +6682,22 @@ structure_alloc_comps (gfc_symbol * der_type, tree
   switch (purpose)
 {
 case DEALLOCATE_ALLOC_COMP:
+  if (cmp_has_alloc_comps && !c->attr.pointer)
+{
+  /* Do not deallocate the components of ultimate pointer
+ components.  */
+  comp = fold_build3_loc (input_location, COMPONENT_REF, ctype,
+  decl, cdecl, NULL_TREE);
+  rank = c->as ? c->as->rank : 0;
+  tmp = structure_alloc_comps (c->ts.u.derived, comp, NULL_TREE,
+   rank, purpose);
+  gfc_add_expr_to_block (&fnblock, tmp);
+}
+
   if (c->attr.allocatable && c->attr.dimension)
 {
   comp = fold_build3_loc (input_location, COMPONENT_REF, ctype,
   decl, cdecl, NULL_TREE);
-  if (cmp_has_alloc_comps && !c->attr.pointer)
-{
-  /* Do not deallocate the components of ultimate pointer
- components.  */
-  tmp = structure_alloc_comps (c->ts.u.derived, comp, NULL_TREE,
-   c->as->rank, purpose);
-  gfc_add_expr_to_block (&fnblock, tmp);
-}
   tmp = gfc_trans_dealloc_allocated (comp);
   gfc_add_expr_to_block (&fnblock, tmp);
 }

[Bug debug/49544] [4.7 Regression] ICE in new_elt_loc_list

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #2 from Jakub Jelinek  2011-06-27 
17:32:00 UTC ---
Fixed.

[Bug fortran/49540] [4.6/4.7 Regression] Memory-hog with large DATA stmt

[burnus at gcc dot gnu.org]

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

--- Comment #7 from Tobias Burnus  2011-06-27 
17:22:15 UTC ---
(In reply to comment #6)
> (In reply to comment #2)
> > Thus, in some way, the repeat count must come back. One possibility is to
> > handle the special case /*/, which is equivalent to
> > a scalar initialization. I think that should cover the most common case.
> 
> IIRC, as implemented the array constructor is completely unrolled, for each
> element an entry in the splay tree is generated.

Yes - at least since dropping the repeat count, which your patch did.

> One could apply the -fmax-array-constructor= restrictions used e.g. for
> PARAMETER arrays and do not unroll arrays of size larger than  but do 
> it
> on runtime.

As written, I think it should be sufficient to support the initialization via a
scalar. In terms of the trans*.c files that already works:
  real :: a(3) = 0
thus, there is no reason why one should be able to set sym->value also for
  real a(3)
  data a/3*0/

That is: If - and only if - one has  == size(array), i.e. a
whole-array initialization, one changes the initialization from:
  sym->value  =  [ ( , i = 1, ) ]
to
  sym->value  =  

That should require some reshoveling in the code, but sounds much cleaner as
-fmax-array-constructor= tweaking. Additionally, it will generate much faster
code for "data a/1000*0.0/" as it gets translated into "static real a =
{}".

[Bug debug/49546] class DW_AT_name does not match method's linkage name prefix

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.06.27 17:21:32
 CC||jason at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from Jason Merrill  2011-06-27 
17:21:32 UTC ---
Agreed, DW_AT_name should be K<&S::m>.

[Bug ada/49511] [4.6 Regression] acats test setup fails on HP-UX using posix shell

[dave at hiauly1 dot hia.nrc.ca]

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

--- Comment #2 from dave at hiauly1 dot hia.nrc.ca 2011-06-27 17:15:23 UTC ---
> could you please run the exact commands used in the run_acats which
> function and report the results:
> 
> type -p gnatmake 2>/dev/null
> echo $?
> 
> type gnatmake 2>/dev/null
> echo $?
> 
> whence gnatmake 2>/dev/null
> echo $?

505 (hiauly1)dave> /bin/sh
$ type -p gnatmake 2>/dev/null
gnatmake is /opt/gnu/gcc/gcc-3.3.4/bin/gnatmake
$ echo $?
0
$
$ type gnatmake 2>/dev/null
gnatmake is /opt/gnu/gcc/gcc-3.3.4/bin/gnatmake
$ echo $?
0
$
$ whence gnatmake 2>/dev/null
/opt/gnu/gcc/gcc-3.3.4/bin/gnatmake
$ echo $?
0

522 (hiauly1)dave> echo $SHELL
/usr/local/bin/bash
523 (hiauly1)dave> type -p gnatmake 2>/dev/null
/opt/gnu/gcc/gcc-3.3.4/bin/gnatmake
524 (hiauly1)dave> echo $?
0
525 (hiauly1)dave> type gnatmake 2>/dev/null
gnatmake is hashed (/opt/gnu/gcc/gcc-3.3.4/bin/gnatmake)
526 (hiauly1)dave> echo $?
0
527 (hiauly1)dave> whence gnatmake 2>/dev/null
528 (hiauly1)dave> echo $?
127

`which' is available on HP-UX in both standard POSIX shell and bash:

529 (hiauly1)dave> /bin/sh
$ which gnatmake 2>/dev/null
/opt/gnu/gcc/gcc-3.3.4/bin/gnatmake
$ echo $?
0
$
530 (hiauly1)dave> echo $SHELL
/usr/local/bin/bash
531 (hiauly1)dave> which gnatmake 2>/dev/null
/opt/gnu/gcc/gcc-3.3.4/bin/gnatmake
532 (hiauly1)dave> echo $?
0

Dave

[Bug debug/49537] cross-check DW_AT_name vs. demangling of linkage names

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.06.27 17:09:28
 CC||jason at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from Jason Merrill  2011-06-27 
17:09:28 UTC ---
That would mean linking cp-demangle.c into cc1plus, but seems plausible.

[Bug ada/49539] [4.7 regression] ICE building gnattools

[mikpe at it dot uu.se]

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

--- Comment #4 from Mikael Pettersson  2011-06-27 
16:51:46 UTC ---
4.7-20110618 failed to bootstrap with the same error.

[Bug ada/49511] [4.6 Regression] acats test setup fails on HP-UX using posix shell

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #1 from ro at CeBiTec dot Uni-Bielefeld.DE  2011-06-27 16:43:12 UTC ---
Dave,

> The problem is type invokes the sh-posix shell and it aliases type
> to 'whence -v'.
>
> 599 (hiauly1)dave> /bin/sh
> $ whence -v gnatmake
> gnatmake is /opt/gnu/gcc/gcc-4.5/bin/gnatmake
> $ whence gnatmake
> /opt/gnu/gcc/gcc-4.5/bin/gnatmake

could you please run the exact commands used in the run_acats which
function and report the results:

type -p gnatmake 2>/dev/null
echo $?

type gnatmake 2>/dev/null
echo $?

whence gnatmake 2>/dev/null
echo $?

Thanks.
Rainer

[Bug fortran/49540] [4.6/4.7 Regression] Memory-hog with large DATA stmt

[burnus at gcc dot gnu.org]

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

--- Comment #5 from Tobias Burnus  2011-06-27 
15:28:31 UTC ---
(In reply to comment #2)
> Thus, in some way, the repeat count must come back. One possibility is to
> handle the special case /*/, which is equivalent to a 
> scalar
> initialization. I think that should cover the most common case.

Vaguely related to the latter: PR 49278, which is about mixing (default)
initialization of DT with DATA initialization.

[Bug middle-end/49536] latent bug with creation of vector of arrays

[howarth at nitro dot med.uc.edu]

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

--- Comment #7 from Jack Howarth  2011-06-27 
16:46:17 UTC ---
I can confirm that the adjusted backport of...

Index: gcc/tree-vect-stmts.c
===
--- gcc/tree-vect-stmts.c(revision 175535)
+++ gcc/tree-vect-stmts.c(working copy)
@@ -4660,6 +4660,15 @@ get_vectype_for_scalar_type (tree scalar
   && GET_MODE_BITSIZE (inner_mode) != TYPE_PRECISION (scalar_type))
 return NULL_TREE;

+  /* We shouldn't end up building VECTOR_TYPEs of non-scalar components.
+ When the component mode passes the above test simply use a type
+ corresponding to that mode.  The theory is that any use that
+ would cause problems with this will disable vectorization anyway.  */
+  if (!SCALAR_FLOAT_TYPE_P (scalar_type)
+  && !INTEGRAL_TYPE_P (scalar_type)
+  && !POINTER_TYPE_P (scalar_type))
+scalar_type = lang_hooks.types.type_for_mode (inner_mode, 1);
+
   /* FORNOW: Only a single vector size per mode (UNITS_PER_SIMD_WORD)
  is expected.  */
   nunits = UNITS_PER_SIMD_WORD (inner_mode) / nbytes;

on current gcc-4_5-branch solves the ICE under dragonegg in the original
testcase from  http://llvm.org/bugs/show_bug.cgi?id=10042.

[Bug debug/49544] [4.7 Regression] ICE in new_elt_loc_list

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  2011-06-27 
16:45:54 UTC ---
Author: jakub
Date: Mon Jun 27 16:45:49 2011
New Revision: 175540

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175540
Log:
PR debug/49544
* cselib.c (promote_debug_loc): If cselib_preserve_constants
and l has two DEBUG_INSN owned locs instead of just one, adjust
the second location's setting_insn too.

* gcc.dg/pr49544.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr49544.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cselib.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/24526] renamed variables from modules not visible in gdb

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #9 from Tobias Burnus  2011-06-27 
16:54:03 UTC ---
(In reply to comment #7)
> My impression is that this is a bug in GDB and not in GCC

Thus, the original problem has been fixed at some point. (I think it was
Jakub's 
2008-08-29 commit.)

Any recent FSF gdb should should be able to print module variables using the
:: syntax - or directly the variable if one uses use-association.
I am not sure whether 7.2 handles it already or whether the 7.3 (branched, to
be released soon) is required. (Maybe 7.1 already did?)

Regarding the rename issue of comment 6: As written in comment 7/comment 8:
That's a GDB issue for which a patch exists (to be committed in the next
hours).

Thus, I close the PR now as FIXED. Please reopen - or fill a new PR with CCing
me - if a related/new issue pops up.

[Bug debug/38896] [4.3 Regression] building libstdc++ stumbles on "invalid bignum", 0x8000000000000000

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

 Resolution|INVALID |WONTFIX

--- Comment #11 from Hans-Peter Nilsson  2011-06-27 
16:11:18 UTC ---
Recategorizing, if only just for the record.

[Bug fortran/49430] [F03] ICE with allocatable length character in interface block

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

Summary|ICE with allocatable length |[F03] ICE with allocatable
   |character in interface  |length character in
   |block   |interface block

--- Comment #6 from janus at gcc dot gnu.org 2011-06-27 15:07:15 UTC ---
The combined patches of comment #3 and #5 regtest cleanly, but do not fully fix
the original test case, cf. comment #3.

[Bug debug/49544] New: [4.7 Regression] ICE in new_elt_loc_list

[jakub at gcc dot gnu.org]

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

   Summary: [4.7 Regression] ICE in new_elt_loc_list
   Product: gcc
   Version: 4.7.0
   URL: https://bugzilla.redhat.com/716837
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: ja...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
Target: s390x-linux


int baz (int, int, void *);

static inline __attribute__ ((always_inline)) long
foo (int x, int y, void *z)
{
  if (y < 0)
return baz (x, y, z);
  return 0;
}

long
bar (long x, long y, long z)
{
  return foo (x, y, (void *) z);
}

ICEs on the trunk on s390x-linux at -g -O2.  The bug has been introduced by my
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=174508
patch.

[Bug debug/49546] New: class DW_AT_name does not match method's linkage name prefix

[jan.kratochvil at redhat dot com]

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

   Summary: class DW_AT_name does not match method's linkage name
prefix
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jan.kratoch...@redhat.com
CC: do...@gcc.gnu.org
Target: x86_64-unknown-linux-gnu


--
struct S {
  static void m (int x) {}
};
template
// or: template
struct K {
  void f () { T (0); }
};
int main () {
  K<&S::m> k;
// or: K k;
  k.f ();
}
--

< c>   DW_AT_producer: GNU C++ 4.7.0 20110627 (experimental)   
 <1><54>: Abbrev Number: 6 (DW_TAG_structure_type)
<55>   DW_AT_name: K 
 <2><60>: Abbrev Number: 7 (DW_TAG_subprogram)
<66>   DW_AT_MIPS_linkage_name: _ZN1KIXadL_ZN1S1mEiEEE1fEv

With the demangler fix PR debug/49408 it now demanges to: K<&S::m>::f()
But therefore K does not match K<&S::m>.

DWARF is exactly the for all the four combination of alternative lines.

As both K<&S::m>::f() functions have exactly the same mangled name
_ZN1KIXadL_ZN1S1mEiEEE1fEv , the demangled names should match the source form
and in the example below it is the only allowed form of the source the
function should demangled to K<&S::m>::f().

But it also cannot always match the source form when multiple source notations
compile into exactly the same output.

source referenced in the text above:
--
struct S {
  void m (int x) {}
};
template
struct K {
  void f () { S s; (s.*F) (5); }
};
int main () {
  K<&S::m> k;
  k.f ();
}
--

FYI:
_ZN1KIXadL_ZN1S1mEiEEE1fEv
typed name
  qualified name
template
  name 'K'
  template argument list
unary operator
  operator &
  typed name
qualified name
  name 'S'
  name 'm'
function type
  argument list
builtin type int
name 'f'
  function type
argument list

[Bug middle-end/49545] [4.7 Regression] New C++ test failures

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.06.27 13:22:25
   Target Milestone|--- |4.7.0
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2011-06-27 
13:22:25 UTC ---
Ugh, I think at least g++.dg/tree-ssa/fwprop-align.C is bogus when it tries
to use alignment to compute whether a indicator bit is set ...

Anyway, confirmed.

[Bug fortran/18918] Eventually support Fortran 2008's coarrays [co-arrays]

[burnus at gcc dot gnu.org]

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

--- Comment #63 from Tobias Burnus  2011-06-27 
14:05:12 UTC ---
(In reply to comment #62)

I have a draft patch, which still fails to diagnose some issues; and I got
stuck with understanding C1302. Thus, I asked at J3:
http://j3-fortran.org/pipermail/j3/2011-June/004483.html

[Bug ada/40986] [4.4 regression] Assert_Failure sinfo.adb:360, error detected at a-unccon.ads:23:27

[Markus.Schoepflin at comsoft dot aero]

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

--- Comment #5 from Markus.Schoepflin at comsoft dot aero 2011-06-27 15:07:52 
UTC ---
Zur Zeit bin ich nicht im Büro. Sie erreichen mich wieder ab dem 11.07.2011.

I am currently not in the office. You can reach me again as of 11.JUL.2011.

[Bug c++/34772] [4.4/4.5/4.6 Regression] self-initialisation does not silence uninitialised warnings (-Winit-self ignored)

[davi.arnaut at oracle dot com]

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

--- Comment #20 from Davi Arnaut  2011-06-27 
16:40:52 UTC ---
Actually, we would really like it. Currently, we have to disable it because
most of the warnings are bogus. New _valid_ warnings are welcome.

[Bug libmudflap/38738] libmudflap could be enabled for Solaris when using GNU ld

[ro at gcc dot gnu.org]

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

--- Comment #7 from Rainer Orth  2011-06-27 16:21:02 UTC 
---
Author: ro
Date: Mon Jun 27 16:20:47 2011
New Revision: 175537

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175537
Log:
gcc:
PR libmudflap/38738
* config/sol2.h [!USE_GLD] (MFLIB_SPEC): Define.

libmudflap:
PR libmudflap/38738
* configure.ac: Check for sys/mnttab.h.
Check for library containing connect.
* configure: Regenerate.
* config.h.in: Regenerate.
* mf-hooks2.c [HAVE_SYS_MNTTAB_H]: Include .
* testsuite/libmudflap.c/pass-stratcliff.c (main) [__sun__ &&
__svr4__]: Disable rawmemchr, stpcpy, mempcpy tests.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sol2.h
trunk/libmudflap/ChangeLog
trunk/libmudflap/config.h.in
trunk/libmudflap/configure
trunk/libmudflap/configure.ac
trunk/libmudflap/mf-hooks2.c
trunk/libmudflap/testsuite/libmudflap.c/pass-stratcliff.c

[Bug target/44241] vms-crtl.h, vms-crtl-64.h need many more symbols

[gingold at gcc dot gnu.org]

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

ging...@gcc.gnu.org  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||gingold at gcc dot gnu.org
 Resolution||FIXED
 AssignedTo|unassigned at gcc dot   |gingold at adacore dot com
   |gnu.org |

--- Comment #4 from gingold at gcc dot gnu.org  
2011-06-27 12:57:55 UTC ---
No custom list yet, but the list is now in one text file.

[Bug target/49547] LZCNT should be enabled only if ABM or LZCNT bits are set

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.06.27 16:10:24
   Target Milestone|--- |4.6.2
 Ever Confirmed|0   |1

--- Comment #1 from H.J. Lu  2011-06-27 16:10:24 
UTC ---
Assembler takes lzcnt only if ABM or LCNT is enabled.
It has nothing to do with BMI.  AMD spec is incorrect.

[Bug c++/49538] Revision 175341 causes segfaults

[markus at trippelsdorf dot de]

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

--- Comment #1 from Markus Trippelsdorf  
2011-06-27 16:12:04 UTC ---
ld.bfd links libkonsoleprivate.so without errors, gold however fails:

Linking CXX shared library ../../lib/libkonsoleprivate.so
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld:
error: CMakeFiles/konsoleprivate.dir/ColorScheme.o: requires dynamic R
_X86_64_PC32 reloc against 'QList::~QList()' which may overflow at
runtime; recompile with -fPIC
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld:
error: CMakeFiles/konsoleprivate.dir/EditProfileDialog.o: requires dyn
amic R_X86_64_PC32 reloc against 'QList::~QList()' which may overflow
at runtime; recompile with -fPIC
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld:
error: CMakeFiles/konsoleprivate.dir/KeyboardTranslator.o: requires dy
namic R_X86_64_PC32 reloc against 'QList::~QList()' which may overflow
at runtime; recompile with -fPIC
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld:
error: CMakeFiles/konsoleprivate.dir/ProcessInfo.o: requires dynamic R
_X86_64_PC32 reloc against 'QList::~QList()' which may overflow at
runtime; recompile with -fPIC
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld:
error: CMakeFiles/konsoleprivate.dir/Profile.o: requires dynamic R_X86
_64_PC32 reloc against 'QList::~QList()' which may overflow at
runtime; recompile with -fPIC
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld:
error: CMakeFiles/konsoleprivate.dir/Pty.o: requires dynamic R_X86_64_
PC32 reloc against 'QList::~QList()' which may overflow at runtime;
recompile with -fPIC
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld:
error: CMakeFiles/konsoleprivate.dir/Pty.o: requires dynamic R_X86_64_
PC32 reloc against 'QList::~QList()' which may overflow at runtime;
recompile with -fPIC
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld:
error: CMakeFiles/konsoleprivate.dir/SessionManager.o: requires dynami
c R_X86_64_PC32 reloc against 'QList::~QList()' which may overflow at
runtime; recompile with -fPIC
CMakeFiles/konsoleprivate.dir/ColorScheme.o:ColorScheme.cpp:function
Konsole::ColorSchemeManager::loadAllColorSchemes(): warning: relocation refers
t
o discarded section
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld:
error: hidden symbol 'QList::~QList()' is not defined locally
CMakeFiles/konsoleprivate.dir/ColorScheme.o:ColorScheme.cpp:function
Konsole::ColorSchemeManager::loadAllColorSchemes(): warning: relocation refers
t
o discarded section
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld:
error: hidden symbol 'QList::~QList()' is not defined locally
CMakeFiles/konsoleprivate.dir/ColorScheme.o:ColorScheme.cpp:function
Konsole::ColorSchemeManager::loadAllColorSchemes(): warning: relocation refers
t
o discarded section
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld:
error: hidden symbol 'QList::~QList()' is not defined locally
CMakeFiles/konsoleprivate.dir/ColorScheme.o:ColorScheme.cpp:function
Konsole::ColorSchemeManager::loadAllColorSchemes(): warning: relocation refers
t
o discarded section
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld:
error: hidden symbol 'QList::~QList()' is not defined locally
CMakeFiles/konsoleprivate.dir/EditProfileDialog.o:EditProfileDialog.cpp:function
Konsole::EditProfileDialog::updateKeyBindingsList(bool): warning: re
location refers to discarded section
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld:
error: hidden symbol 'QList::~QList()' is not defined locally
CMakeFiles/konsoleprivate.dir/EditProfileDialog.o:EditProfileDialog.cpp:function
Konsole::EditProfileDialog::updateKeyBindingsList(bool): warning: re
location refers to discarded section
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld:
error: hidden symbol 'QList::~QList()' is not defined locally
CMakeFiles/konsoleprivate.dir/KeyboardTranslator.o:KeyboardTranslator.cpp:function
Konsole::KeyboardTranslatorManager::findTranslators(): warning: re
location refers to discarded section
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld:
error: hidden symbol 'QList::~QList()' is not defined locally
CMakeFiles/konsoleprivate.dir/ProcessInfo.o:ProcessInfo.cpp:function
Konsole::ProcessInfo::formatCommand(QString const&, QVector const&,
Kon
sole::ProcessInfo::CommandFormat) const: warning: relocation refers to
discarded section
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld:
error: hidden symbol 'QList::~QList()' is not defined locally
CMakeFiles/konsoleprivate.dir/ProcessInfo.o:ProcessInfo.cpp:function
Konsole::ProcessInfo::formatShortDir(QString const&) const: warning: relocation 
refers to discarded section

[Bug target/49547] New: LZCNT should be enabled only if ABM or LZCNT bits are set

[kirill.yukhin at intel dot com]

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

   Summary: LZCNT should be enabled only if ABM or LZCNT bits are
set
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kirill.yuk...@intel.com


Hi,
according to freshest Specs, we need to enable LZCNT only when ABM or LZCNT
bits of CPUID (leaf 8000_0001h) is set.
However config/i386/i386.md has:

(define_insn "clz2_abm"
  [(set (match_operand:SWI248 0 "register_operand" "=r")
(clz:SWI248 (match_operand:SWI248 1 "nonimmediate_operand" "rm")))
   (clobber (reg:CC FLAGS_REG))]
  "TARGET_ABM || TARGET_BMI"
  "lzcnt{}\t{%1, %0|%0, %1}"
  [(set_attr "prefix_rep" "1")
   (set_attr "type" "bitmanip")
   (set_attr "mode" "")])

There is no connection to BMI anymore.

[Bug target/25343] [4.4/4.5/4.6/4.7 regression] [m68k] testsuite failures

[mikpe at it dot uu.se]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpe at it dot uu.se

--- Comment #16 from Mikael Pettersson  2011-06-27 
14:42:11 UTC ---
All of the test suite failures listed in #c1 are gone in the 4.4/4.5/4.6/4.7
test suite results for m68k-linux I've been posting for the last 6 months or
so.  (The tests aren't disabled, they do run and PASS.)

Can this be closed now?

(While some test suite failures remain, a few of them are already tracked via
other PRs, and many of the rest are known to be caused by FP emulation bugs in
the ARAnym m68k emulator.)

[Bug middle-end/49394] [4.7 Regression] libstdc++-v3/testsuite/30_threads/lock_guard/cons/1.cc FAILs with -fipa-pta -fnon-call-exceptions

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther  2011-06-27 
14:32:04 UTC ---
Author: rguenth
Date: Mon Jun 27 14:32:00 2011
New Revision: 175532

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

PR tree-optimization/49394
* passes.c (execute_one_pass): Restore current_pass after
applying IPA transforms.

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

Added:
trunk/gcc/testsuite/g++.dg/torture/pr49394.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/passes.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/49394] [4.7 Regression] libstdc++-v3/testsuite/30_threads/lock_guard/cons/1.cc FAILs with -fipa-pta -fnon-call-exceptions

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #3 from Richard Guenther  2011-06-27 
14:32:23 UTC ---
Fixed.

[Bug lto/48492] [4.7 Regression] LTO bootstrap failure in copy_constant

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED

--- Comment #11 from Eric Botcazou  2011-06-27 
14:37:00 UTC ---
Or rather worked around.

[Bug c++/34772] [4.4/4.5/4.6 Regression] self-initialisation does not silence uninitialised warnings (-Winit-self ignored)

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #19 from Manuel López-Ibáñez  2011-06-27 
13:10:08 UTC ---
I think no one is going to backport this, specially because it produces new
warnings, and users wouldn't like that in a minor version. Let's close it.

[Bug lto/48492] [4.7 Regression] LTO bootstrap failure in copy_constant

[ebotcazou at gcc dot gnu.org]

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

--- Comment #10 from Eric Botcazou  2011-06-27 
14:34:08 UTC ---
Author: ebotcazou
Date: Mon Jun 27 14:34:05 2011
New Revision: 175533

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175533
Log:
PR lto/48492
* dwarf2out.c (dwarf2out_finish): Do not attach a DIE on the limbo list
to a NULL parent.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c

[Bug target/40959] [4.4/4.5/4.6/4.7 regression] FreeBSD/ia64 build fails: No rule to make target `/usr/ports/lang/gcc43/work/build/ia64-portbld-freebsd8.0/libgcc/crtfastmath.o', needed by `T_TARGET'.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|4.6.1   |4.6.2

--- Comment #28 from Jakub Jelinek  2011-06-27 
12:32:39 UTC ---
GCC 4.6.1 is being released.

[Bug tree-optimization/18501] [4.4/4.5/4.6/4.7 Regression] Missing 'used uninitialized' warning (CCP)

[manu at gcc dot gnu.org]

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

--- Comment #53 from Manuel López-Ibáñez  2011-06-27 
13:06:09 UTC ---
(In reply to comment #52)
> 4.3 branch is being closed, moving to 4.4.7 target.

Richard, I would suggest to remove the regression markers. This is a regression
since 4.0 that it is unlikely to be fixed in the near future. Hence, not really
worth to track as a regression. One less bug to handle by the release managers.

[Bug middle-end/49545] [4.7 Regression] New C++ test failures

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther  2011-06-27 
13:36:03 UTC ---
An anyway useful transform would be to hoist the call in

  iftmp.0_15 = *D.2099_14;

:
  # iftmp.0_1 = PHI 
  iftmp.0_1 (&a);

based on the fact that on the edge 2->4 it will be a direct call.