[Bug bootstrap/40696] New: Make bootstrap fail

[Chaipzor at hotmail dot com]

Im trying to install GCC 4.4.0 (i tried also with: gcc-4.3.3) my configure is:
../gcc-4.4.0/configure --enable-shared --enable-threads=gnat
--enable-__cxa_atexit --enable-clocale=gnu --enable-languages=c,ada
--prefix=/opt/gnu-gcc/gcc-4.4.0 --with-gmp=/usr --with-mpfr=/usr/local
--enable-libada --with-gmp-lib=/usr/lib --with-mpfr-lib=/usr/lib
--enable-multilib --with-gnu-as

it configured without problems, then i 'make bootstrap' and after about 10
hours, my GCC is wrong comparing stages with thess lines:

Comparing stages 2 and 3
Bootstrap comparison failure!
./ada/bldtools/nmake_b/xnmake.o differs
./ada/bldtools/nmake_s/xnmake.o differs
./ada/bldtools/treeprs/xtreeprs.o differs
./ada/bldtools/sinfo/xsinfo.o differs
./ada/bldtools/einfo/xeinfo.o differs
./ada/doctools/xgnatugn.o differs
make[2]: *** [compare] Error 1
make[2]: Leaving directory `/opt/gnu-gcc/gcc-comp_4.4.0'
make[1]: *** [stage3-bubble] Error 2
make[1]: Leaving directory `/opt/gnu-gcc/gcc-comp_4.4.0'
make: *** [bootstrap] Error 2

i've installed other version of gcc: 3.4.3

im having this trouble since 1 month ago, i hope you can help me.
Thank you, and tell me if you need something more, i think i dont forgot
anything.


-- 
   Summary: Make bootstrap fail
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Chaipzor at hotmail dot com
  GCC host triplet: Sparc-Sun Solaris 10 (Sun blade 100)


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

[Bug target/40693] atomic built-ins malfunction with 64-bit signed ptrs and negative constants

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2009-07-09 05:54 ---
Can't reproduce.


-- 


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

[Bug lto/39317] [lto] - cannot compute suffix of object files - cannot represent relocation type BFD_RELOC_64

[bje at gcc dot gnu dot org]

--- Comment #10 from bje at gcc dot gnu dot org  2009-07-09 05:52 ---
(In reply to comment #8)

> I tried with the 'trunk' (instead of 'lto') and found the same issue.

I really don't think this is a bug with the lto branch.  If you still think
it's a problem on trunk, then please re-open this bug as being against the
trunk compiler.  Thanks.


-- 

bje at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug lto/40409] [LTO] ICE in expand_shift, at expmed.c:2263

[bje at gcc dot gnu dot org]

--- Comment #4 from bje at gcc dot gnu dot org  2009-07-09 05:39 ---
The original ICE has now been replaced with:

$ ./xgcc -B. -flto -shared acosh.o acosl.o
lto1: internal compiler error: in lto_read_file_options, at lto-opts.c:348
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

(lto revision 149400)


-- 

bje at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-07-09 05:39:56
   date||


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

[Bug lto/40410] [LTO] ICE verify_stmts failed

[bje at gcc dot gnu dot org]

--- Comment #3 from bje at gcc dot gnu dot org  2009-07-09 05:38 ---
On powerpc-linux, the original ICE has been replaced with:

$ ./xgcc -B. -flto -shared ctanf.o ctanhl.o ctanh.o
lto1: internal compiler error: in lto_read_file_options, at lto-opts.c:348
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

(lto revision 149400)


-- 

bje at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-07-09 05:38:27
   date||


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

[Bug bootstrap/39025] ICE in start_function, at c-decl.c:6225 while configuring libgcc

[bje at gcc dot gnu dot org]

--- Comment #2 from bje at gcc dot gnu dot org  2009-07-09 05:10 ---
Rainer, can you please re-check this against the tip of the lto branch and
report back?  Thanks.


-- 


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

[Bug bootstrap/39019] Solaris and IRIX libelf cause trouble for build

[bje at gcc dot gnu dot org]

--- Comment #5 from bje at gcc dot gnu dot org  2009-07-09 05:09 ---
Building with --with-libelf is the right approach.  I don't think it works 100%
correctly, though, so I will take this bug and investigate.


-- 

bje at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|dnovillo at gcc dot gnu dot |bje at gcc dot gnu dot org
   |org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-07-09 05:09:13
   date||


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

[Bug bootstrap/39024] static libelf needs to be built PIC

[bje at gcc dot gnu dot org]

-- 

bje at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-07-09 05:07:07
   date||


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

[Bug lto/40681] [ICE] expand_expr_real_1, at expr.c:7382

[bje at gcc dot gnu dot org]

--- Comment #2 from bje at gcc dot gnu dot org  2009-07-09 04:47 ---
Confirmed in lto revision 149393.


-- 

bje at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-07-09 04:47:29
   date||


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

[Bug lto/40392] ICE in lto_end_uncompression, at lto-compress.c:282

[bje at gcc dot gnu dot org]

--- Comment #1 from bje at gcc dot gnu dot org  2009-07-09 04:43 ---
Confirmed in lto revision 149393.


-- 

bje at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-07-09 04:43:56
   date||


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

[Bug c++/40695] bogus "may be used uninitialized in this function" warning

[shane dot beasley at aleri dot com]

--- Comment #1 from shane dot beasley at aleri dot com  2009-07-09 02:55 
---
I should add that I boiled this down from a much larger specimen that had all
the copy constructors and assignment operators. Here, I'm just using the
default ones. The problem exists in both cases.


-- 


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

[Bug c++/40695] New: bogus "may be used uninitialized in this function" warning

[shane dot beasley at aleri dot com]

Apologies if this is a duplicate, but I can't find another quite like this...


struct Class
{
// undefined
void Method();
};

template < typename w_type >
struct NoPtr
{
// inline
NoPtr( bool = false ) : m_ptr( 0 ) { }

// inline; calls a method
~NoPtr() { if ( m_ptr ) m_ptr->Method(); }

// undefined
w_type *Get();

w_type *m_ptr;
};

void f()
{
bool cond = true;

// a named NoPtr< Class > initialized from a ternary expression
// with an if-expr that refers to any named object,
// plus a then-expr that contains an rvalue of type NoPtr< Class >
NoPtr< Class > named(
cond
? NoPtr< Class >().Get()
: 0
);
}


$ /usr/bin/g++-4.2 -c -o/dev/null -xc++ -Wuninitialized -O file.cpp
$ /usr/bin/g++-4.2 -dumpversion
4.2.4

$ g++-4 -c -o/dev/null -xc++ -Wuninitialized -O file.cpp
file.cpp: In function 'void f()':
file.cpp:14: warning: 'named.NoPtr::m_ptr' may be used uninitialized in
this function
file.cpp:30: note: 'named.NoPtr::m_ptr' was declared here
$ g++-4 -dumpversion
4.3.2

$ /usr/bin/g++-4.3 -c -o/dev/null -xc++ -Wuninitialized -O file.cpp
file.cpp: In function 'void f()':
file.cpp:14: warning: 'named.NoPtr::m_ptr' may be used uninitialized in
this function
file.cpp:30: note: 'named.NoPtr::m_ptr' was declared here
$ /usr/bin/g++-4.3 -dumpversion
4.3.3

$ /usr/bin/g++-4.4 -c -o/dev/null -xc++ -Wuninitialized -O file.cpp
file.cpp: In function 'void f()':
file.cpp:14: warning: 'named.NoPtr::m_ptr' may be used uninitialized in
this function
file.cpp:30: note: 'named.NoPtr::m_ptr' was declared here
$ /usr/bin/g++-4.4 -dumpversion
4.4.0

If it helps, that's 4.2.4 on Debian; 4.3.2 on Cygwin; 4.3.3 and 4.4.0 on both
Solaris and Debian.


-- 
   Summary: bogus "may be used uninitialized in this function"
warning
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: shane dot beasley at aleri dot com


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

[Bug fortran/40508] memory leak in internal write of gfortran

[jvdelisle at gcc dot gnu dot org]

--- Comment #9 from jvdelisle at gcc dot gnu dot org  2009-07-09 02:02 
---
Fixed.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/40662] gfortran 4.5 segfaults when specific FORMAT is invoked twice

[jvdelisle at gcc dot gnu dot org]

--- Comment #6 from jvdelisle at gcc dot gnu dot org  2009-07-09 02:01 
---
Fixed on trunk.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug libfortran/40330] [4.5 Regression] incorrect IO

[jvdelisle at gcc dot gnu dot org]

--- Comment #36 from jvdelisle at gcc dot gnu dot org  2009-07-09 01:59 
---
Fixed on trunk.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/40662] gfortran 4.5 segfaults when specific FORMAT is invoked twice

[jvdelisle at gcc dot gnu dot org]

--- Comment #5 from jvdelisle at gcc dot gnu dot org  2009-07-09 01:55 
---
Subject: Bug 40662

Author: jvdelisle
Date: Thu Jul  9 01:54:47 2009
New Revision: 149399

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149399
Log:
2009-07-08  Jerry DeLisle  

PR libfortran/40330
PR libfortran/40662
* gfortran.dg/fmt_cache_1.f: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/fmt_cache_1.f
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug libfortran/40330] [4.5 Regression] incorrect IO

[jvdelisle at gcc dot gnu dot org]

--- Comment #35 from jvdelisle at gcc dot gnu dot org  2009-07-09 01:55 
---
Subject: Bug 40330

Author: jvdelisle
Date: Thu Jul  9 01:54:47 2009
New Revision: 149399

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149399
Log:
2009-07-08  Jerry DeLisle  

PR libfortran/40330
PR libfortran/40662
* gfortran.dg/fmt_cache_1.f: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/fmt_cache_1.f
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/40662] gfortran 4.5 segfaults when specific FORMAT is invoked twice

[jvdelisle at gcc dot gnu dot org]

--- Comment #4 from jvdelisle at gcc dot gnu dot org  2009-07-09 01:20 
---
Subject: Bug 40662

Author: jvdelisle
Date: Thu Jul  9 01:20:23 2009
New Revision: 149398

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149398
Log:
2009-07-08  Jerry DeLisle  

PR libfortran/40330
PR libfortran/40662
* io/io.h (st_parameter_dt): Define format_not_saved bit used to signal
whether the parsed format data was previously saved. Used to determine
if the current format data should be freed or not.
* io/transfer.c (st_read_done): Use the format_not_saved bit.
(st_write_done): Likewise.
* io/format.c (parse_format_list): Add boolean pointer to arg list.
This
pointer is used to return status to the caller regarding whether it is
safe to cache the parsed format data.  Currently, if a FMT_STRING token
is encounetered, it is not safe to cache. Also, added a local boolean
variable to hold this information as recursive calls to
parse_format_list are made.  Remove previous save_format logic.
(parse_format): Do not use the format caching facility if the current
unit is an internal unit or if it is not safe to save parsed format
data.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/format.c
trunk/libgfortran/io/io.h
trunk/libgfortran/io/transfer.c


-- 


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

[Bug libfortran/40330] [4.5 Regression] incorrect IO

[jvdelisle at gcc dot gnu dot org]

--- Comment #34 from jvdelisle at gcc dot gnu dot org  2009-07-09 01:20 
---
Subject: Bug 40330

Author: jvdelisle
Date: Thu Jul  9 01:20:23 2009
New Revision: 149398

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149398
Log:
2009-07-08  Jerry DeLisle  

PR libfortran/40330
PR libfortran/40662
* io/io.h (st_parameter_dt): Define format_not_saved bit used to signal
whether the parsed format data was previously saved. Used to determine
if the current format data should be freed or not.
* io/transfer.c (st_read_done): Use the format_not_saved bit.
(st_write_done): Likewise.
* io/format.c (parse_format_list): Add boolean pointer to arg list.
This
pointer is used to return status to the caller regarding whether it is
safe to cache the parsed format data.  Currently, if a FMT_STRING token
is encounetered, it is not safe to cache. Also, added a local boolean
variable to hold this information as recursive calls to
parse_format_list are made.  Remove previous save_format logic.
(parse_format): Do not use the format caching facility if the current
unit is an internal unit or if it is not safe to save parsed format
data.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/format.c
trunk/libgfortran/io/io.h
trunk/libgfortran/io/transfer.c


-- 


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

[Bug c++/40694] ICE while building clang

[jyasskin at gmail dot com]

--- Comment #3 from jyasskin at gmail dot com  2009-07-09 00:57 ---
It does not reproduce with Ubuntu gcc-4.3. I didn't try 4.4. If anyone cares, I
submitted a workaround at
http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/Support/IRBuilder.h?r1=75084&r2=75083&pathrev=75084
which may point to the underlying problem.


-- 

jyasskin at gmail dot com changed:

   What|Removed |Added

 CC||jyasskin at gmail dot com


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

[Bug c++/40694] ICE while building clang

[paolo dot carlini at oracle dot com]

--- Comment #2 from paolo dot carlini at oracle dot com  2009-07-09 00:38 
---
Before anything else, please make sure you can reproduce the issue with 4.3.x
or 4.4.x, because 4.2.x is not maintained anymore. Preferably, use an official
FSF release for that.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug c++/40689] [C++0x]: error with initializer list in N2672

[paolo dot carlini at oracle dot com]

--- Comment #5 from paolo dot carlini at oracle dot com  2009-07-09 00:36 
---
And again...


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||jason at gcc dot gnu dot org


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

[Bug c++/40688] [C++0x]: error with auto direct and copy initalization

[paolo dot carlini at oracle dot com]

--- Comment #2 from paolo dot carlini at oracle dot com  2009-07-09 00:35 
---
To be sure, let's CC Jason about these auto issues...


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||jason at gcc dot gnu dot org


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

[Bug c++/40687] [C++0x]: error with auto and 7.1.6.4/7 in N2914

[paolo dot carlini at oracle dot com]

--- Comment #2 from paolo dot carlini at oracle dot com  2009-07-09 00:35 
---
To be sure, let's CC Jason about these auto issues...


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||jason at gcc dot gnu dot org


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

[Bug bootstrap/39108] LTO fails to bootstrap on Alpha

[bje at gcc dot gnu dot org]

--- Comment #1 from bje at gcc dot gnu dot org  2009-07-09 00:15 ---
Falk, can you please check again with the tip of the lto branch?  I don't have
access to an Alpha system to check for myself.  Thanks.


-- 


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

[Bug lto/39279] [lto] - Werror in ../lto_trunk/gcc/lto/lto.c

[bje at gcc dot gnu dot org]

--- Comment #2 from bje at gcc dot gnu dot org  2009-07-09 00:14 ---
Confirmed.  The proposed fix is not correct, though, as the type of the first
argument to munmap _is_ void* according to POSIX.


-- 

bje at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |bje at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-07-09 00:14:25
   date||


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

[Bug lto/39276] [lto] - Testsuite gcc.log shows many "getconf: Invalid argument (_NPROCESSORS_ONLN)"

[bje at gcc dot gnu dot org]

--- Comment #6 from bje at gcc dot gnu dot org  2009-07-09 00:10 ---
Confirmed.


-- 

bje at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |bje at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-07-09 00:10:48
   date||


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

[Bug c/40693] atomic built-ins malfunction with 64-bit and optimization

[m dot rosellini at f5 dot com]

--- Comment #1 from m dot rosellini at f5 dot com  2009-07-09 00:10 ---
I forgot to add: You need to compile this with -O2 and -march=pentium.

The way that negative constants are handled in the code emitted for
__sync_blah_and_blah is incorrect when the pointer type is 64-bits and the
platform is 32-bit x86.  That's the real issue.  Calling
__sync_blah_and_blah(ptr, -1) is sufficient (where ptr is a pointer to a 64-bit
signed type).  Then you do not need to turn on optimization.

This doesn't really have anything to do with optimization... it's just that
there is a strange interplay with optimization whereby the function has the bad
behavior exhibited with constants even when it doesn't look like one is passing
a constant (such as when calling this through an inline function).


-- 

m dot rosellini at f5 dot com changed:

   What|Removed |Added

 CC||m dot rosellini at f5 dot
   ||com


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

[Bug target/30210] [4.5 Regression] Altivec builtins have inaccurate return types

[meissner at linux dot vnet dot ibm dot com]

--- Comment #17 from meissner at linux dot vnet dot ibm dot com  2009-07-08 
23:42 ---
Subject: Re:  [4.5 Regression] Altivec builtins have inaccurate return types

On Wed, Jul 08, 2009 at 09:04:03PM -, rguenth at gcc dot gnu dot org wrote:
> 
> 
> --- Comment #16 from rguenth at gcc dot gnu dot org  2009-07-08 21:04 
> ---
> Mike - you said you have patches for this?
> 
> 
> -- 
> 
> rguenth at gcc dot gnu dot org changed:
> 
>What|Removed |Added
> 
>  CC||meissner at gcc dot gnu dot
>||org
> 
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30210
> 
> --- You are receiving this mail because: ---
> You are on the CC list for the bug, or are watching someone who is.

Yes, it should be in the next power7 patch.  I hope to send out the patch for
review shortly, but I have a few regressions in my code.


-- 


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

[Bug c++/40694] ICE while building clang

[reid dot kleckner at gmail dot com]

--- Comment #1 from reid dot kleckner at gmail dot com  2009-07-08 23:14 
---
I tried to create an attachment, but it won't take files over 1MB so I uploaded
the two files here:
http://web.mit.edu/rnk/www/buggycppfile.cpp
http://web.mit.edu/rnk/www/buggycppfile.ii


-- 

reid dot kleckner at gmail dot com changed:

   What|Removed |Added

 CC||reid dot kleckner at gmail
   ||dot com


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

[Bug c++/40694] New: ICE while building clang

[reid dot kleckner at gmail dot com]

I was compiling LLVM and Clang when I ran into this ICE.  I found the failing
compile job and ran it again with -E to produce buggycppfile.cpp which fails to
compile.  I then did the following as instructed in the bug reporting
instructions:

[...@knuckles CodeGen]$ g++ buggycppfile.cpp -o buggycppfile.o -save-temps -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.2.4 (Ubuntu 4.2.4-1ubuntu3)
 /usr/lib/gcc/x86_64-linux-gnu/4.2.4/cc1plus -E -quiet -v -D_GNU_SOURCE
buggycppfile.cpp -mtune=generic -fpch-preprocess -o buggycppfile.ii
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/4.2.4/../../../../x86_64-linux-gnu/include"
ignoring nonexistent directory "/usr/include/x86_64-linux-gnu"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/4.2
 /usr/include/c++/4.2/x86_64-linux-gnu
 /usr/include/c++/4.2/backward
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/4.2.4/include
 /usr/include
End of search list.
 /usr/lib/gcc/x86_64-linux-gnu/4.2.4/cc1plus -fpreprocessed buggycppfile.ii
-quiet -dumpbase buggycppfile.cpp -mtune=generic -auxbase buggycppfile -version
-fstack-protector -fstack-protector -o buggycppfile.s
GNU C++ version 4.2.4 (Ubuntu 4.2.4-1ubuntu3) (x86_64-linux-gnu)
compiled by GNU C version 4.2.4 (Ubuntu 4.2.4-1ubuntu3).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 2328a9860f8ee3842b3eeb9e852e4412
In file included from CGBuilder.h:15,
 from CGBlocks.h:31,
 from CodeGenFunction.h:27,
 from CGBlocks.cpp:16:
/home/rnk/llvm-globals/include/llvm/Support/IRBuilder.h: In member function
'llvm::Value* llvm::IRBuilder::CreateGlobalString(const
char*, const char*)':
/home/rnk/llvm-globals/include/llvm/Support/IRBuilder.h:412: internal compiler
error: in stabilize_expr, at cp/tree.c:2273
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see .


-- 
   Summary: ICE while building clang
   Product: gcc
   Version: 4.2.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reid dot kleckner at gmail dot com


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

[Bug c/40693] New: atomic built-ins malfunction with 64-bit and optimization

[m dot rosellini at f5 dot com]

#include 
#include 

int
main(int ac, char *av[])
{
int64_t x;
int64_t like_a_constant = -1;
int64_t unlike_a_constant = -1;

if (ac == 0) unlike_a_constant = 5;

x = 0;
__sync_add_and_fetch(&x, like_a_constant);
printf("%016llx\n", x);

x = 0;
__sync_add_and_fetch(&x, unlike_a_constant);
printf("%016llx\n", x);
}

Expected result:



Actual result:




-- 
   Summary: atomic built-ins malfunction with 64-bit and
optimization
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: m dot rosellini at f5 dot com


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

[Bug middle-end/40692] [4.5 Regression] Endless recursion between fold_ternary and fold_cond_expr_with_comparison

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2009-07-08 23:09 ---
Caused by r149060.  Will debug tomorrow.
Alternative testcase that doesn't warn about VLA at file scope:
#define M1(x) (((x) & 0x0002) ? 0x2 : ((x) & 0x1))
#define M2(x) (((x) & 0x000c) ? M1 ((x) >> 2) << 2 : M1 (x))
struct A { char f[1]; };
int foo (void)
{
  return M2 (4096UL - (long)&((struct A *) 16UL)->f);
}


-- 


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

[Bug libstdc++/40691] bug in logical not operator for valarray used with slice

[janis at gcc dot gnu dot org]

--- Comment #1 from janis at gcc dot gnu dot org  2009-07-08 22:27 ---
Subject: Bug 40691

Author: janis
Date: Wed Jul  8 22:26:50 2009
New Revision: 149393

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149393
Log:
PR libstdc++/40691
* include/bugs/valarray-after.h (_Expr::operator!): Fix return type.
* testsuite/26_numerics/valarray/40691.cc: New test.

Added:
trunk/libstdc++-v3/testsuite/26_numerics/valarray/40691.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/valarray_after.h


-- 


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

[Bug middle-end/40692] New: [4.5 Regression] Endless recursion between fold_ternary and fold_cond_expr_with_comparison

[jakub at gcc dot gnu dot org]

Linux kernel, in particularly xen-blkfront.c, doesn't compile with GCC trunk.
4.5.0 20090625 was still fine, 4.5.0 20090630 is already wrong.

Simplified testcase:

#define M1(x) (((x) & 0x0002) ? 0x2 : ((x) & 0x1))
#define M2(x) (((x) & 0x000c) ? M1 ((x) >> 2) << 2 : M1 (x))
struct A { char f[1]; };
char a[M2 (4096UL - (long)&((struct A *) 16)->f)];


-- 
   Summary: [4.5 Regression] Endless recursion between fold_ternary
and fold_cond_expr_with_comparison
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: jakub at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org


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

[Bug c++/8045] Missing "unused variable" warning

[manu at gcc dot gnu dot org]

--- Comment #5 from manu at gcc dot gnu dot org  2009-07-08 22:08 ---
Are there some cases where a declaration such T x = y can be considered an use
of 'x' by itself?

The following patch warns for this, but it also produces warnings for some
testcases in the testsuite.

Index: gcc/cp/init.c
===
--- gcc/cp/init.c   (revision 149319)
+++ gcc/cp/init.c   (working copy)
@@ -1261,11 +1261,11 @@ build_aggr_init (tree exp, tree init, in
   if (init)
TREE_TYPE (init) = itype;
   return stmt_expr;
 }

-  if (TREE_CODE (exp) == VAR_DECL || TREE_CODE (exp) == PARM_DECL)
+  if (TREE_CODE (exp) == PARM_DECL)
 /* Just know that we've seen something for this node.  */
 TREE_USED (exp) = 1;

   is_global = begin_init_stmts (&stmt_expr, &compound_stmt);
   destroy_temps = stmts_are_full_exprs_p ();


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail||4.4.0
   Last reconfirmed|2005-12-11 23:03:44 |2009-07-08 22:08:57
   date||


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

[Bug middle-end/39976] [4.5 Regression] Big sixtrack degradation on powerpc 32/64 after revision r146817

[pthaugen at gcc dot gnu dot org]

--- Comment #20 from pthaugen at gcc dot gnu dot org  2009-07-08 21:53 
---
Created an attachment (id=18165)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18165&action=view)
Reduced testcase

The attatched testcase exhibits the problem with the load-hit-store. It's
resulting from choosing a bad register class (GENERAL_REGS) for a pseudo that
should get assigned to FLOAT_REGS. Since there is no FPR -> GPR move for
-mcpu=power6 the copy must go through memory.  I compiled the testcase with
-m64 -O3 -mcpu=power6 using trunk revision 149376.  The pseudo in question is
361.

Following are the 3 insns referencing reg 361 in the sched1 dump (before ira):

(insn 51 238 241 8 thin6d_reduced.f:178 (set (reg:DF 361 [ prephitmp.35 ])
(reg:DF 358 [ prephitmp.35 ])) 351 {*movdf_hardfloat64} (nil))
...
(insn 47 46 231 9 thin6d_reduced.f:178 (set (reg:DF 361 [ prephitmp.35 ])
(reg:DF 179 [ prephitmp.35 ])) 351 {*movdf_hardfloat64} (nil))
...
(insn 196 194 198 11 thin6d_reduced.f:169 (set (mem/c/i:DF (plus:DI (reg/f:DI
477)
(const_int 56 [0x38])) [2 crkve+0 S8 A64])
(reg:DF 361 [ prephitmp.35 ])) 351 {*movdf_hardfloat64}
(expr_list:REG_DEAD (reg:DF 361 [ prephitmp.35 ])
(nil)))


And from the ira dump:

Pass1 cost computation:
a71 (r361,l1) best GENERAL_REGS, cover GENERAL_REGS
a3 (r361,l0) best GENERAL_REGS, cover GENERAL_REGS
  a3(r361,l0) costs: BASE_REGS:0,0 GENERAL_REGS:0,0 FLOAT_REGS:0,0
LINK_REGS:156,1836 CTR_REGS:156,1836 SPECIAL_REGS:156,1836 MEM:156
  a71(r361,l1) costs: BASE_REGS:0,0 GENERAL_REGS:0,0 FLOAT_REGS:0,0
LINK_REGS:1680,1680 CTR_REGS:1680,1680 SPECIAL_REGS:1680,1680 MEM:1120


Pass 2 cost computation:
r361: preferred GENERAL_REGS, alternative NO_REGS
  a3(r361,l0) costs: BASE_REGS:0,2240 GENERAL_REGS:0,2240 FLOAT_REGS:312,2552
LINK_REGS:234,4154 CTR_REGS:234,4154 SPECIAL_REGS:234,4154 MEM:156
  a71(r361,l1) costs: BASE_REGS:2240,2240 GENERAL_REGS:2240,2240
FLOAT_REGS:2240,2240 LINK_REGS:3920,3920 CTR_REGS:3920,3920
SPECIAL_REGS:3920,3920 MEM:3360

Not sure what's causing the FLOAT cost to be higher than the GENERAL cost yet.


-- 


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

[Bug c/37231] GCC does not compile code with label statements that are followed by a declaration

[manu at gcc dot gnu dot org]

--- Comment #5 from manu at gcc dot gnu dot org  2009-07-08 21:34 ---
(In reply to comment #4)
> (In reply to comment #3)
> > Above code doesn't compile:
> 
> Yes it should not be compile.  The error message has been improved to tell you
> what the problem is (that is what Manu was saying in his comment #2).

Indeed.

Aapo, what is difficult to understand from the the current error message? I
would like to improve it as much as possible.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||aapo dot rantalainen at
   ||gmail dot com


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

[Bug tree-optimization/39960] [4.5 Regression] struct-reorg is broken

[janis at gcc dot gnu dot org]

--- Comment #3 from janis at gcc dot gnu dot org  2009-07-08 21:29 ---
The test started failing with the patch reported in comment #2 because it
enabled type checking; sorry for the noise.


-- 


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

[Bug c/39959] [4.5 Regression] IMA is broken

[janis at gcc dot gnu dot org]

--- Comment #5 from janis at gcc dot gnu dot org  2009-07-08 21:28 ---
The test started failing with the patch reported in comment #8 because it
enabled type checking; sorry for the noise.


-- 


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

[Bug c++/40689] [C++0x]: error with initializer list in N2672

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2009-07-08 21:05 ---
I don't think so.  Likely nobody bothered to update that document recently.


-- 


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

[Bug target/30210] [4.5 Regression] Altivec builtins have inaccurate return types

[rguenth at gcc dot gnu dot org]

--- Comment #16 from rguenth at gcc dot gnu dot org  2009-07-08 21:04 
---
Mike - you said you have patches for this?


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||meissner at gcc dot gnu dot
   ||org


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

[Bug fortran/40675] Support -fnosign-zero for SIGN intrinsic for Fortran 77 compatibility

[gdsjaar at sandia dot gov]

--- Comment #17 from gdsjaar at sandia dot gov  2009-07-08 21:03 ---
Subject: Re:  Support -fnosign-zero for SIGN
 intrinsic for Fortran 77 compatibility

Thanks for the quick response.  I agree that the ultimate fix is to 
remove that idiom from the code; however, when dealing with decades old 
fortran code, we don't always have the time or resources to do it 
right.   I will try to write a better test code next time that isn't 
buggy...

--Greg

burnus at gcc dot gnu dot org wrote:
> --- Comment #16 from burnus at gcc dot gnu dot org  2009-07-08 20:55 
> ---
> Close as FIXED (on the trunk [= 4.5]).
>
> Greg, thanks for the report. Using a 4.5/trunk build (e.g. one of the nightly
> builds) gfortran will offer the option -fno-sign-zero  which allows your
> program to work.
>
> However, I still would like to suggest to change the program such that it will
> work also the default options. The problem will presumably also appear with
> other compilers - for instance if they change their default.
>
>
>   


-- 


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

[Bug target/30210] [4.5 Regression] Altivec builtins have inaccurate return types

[rguenth at gcc dot gnu dot org]

--- Comment #15 from rguenth at gcc dot gnu dot org  2009-07-08 21:03 
---
*** Bug 40690 has been marked as a duplicate of this bug. ***


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||janis at gcc dot gnu dot org


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

[Bug tree-optimization/40690] invalid conversion in gimple call for vect tests

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-07-08 21:03 ---
It is.

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


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug libstdc++/40691] New: bug in logical not operator for valarray used with slice

[janis at gcc dot gnu dot org]

Use of operator! (logical not) from valarray with slice fails.  For example,

--
#include 

void test01()
{
  const std::valarray vi(12);
  std::valarray vb1(12);
  std::valarray vb2(3);
  std::slice s(0,3,4);

  vb1 = !vi; // ok
  vb2 = !(std::valarray)vi[s];  // ok
  vb2 = !vi[s];  // fails
}
--

fails with:

elm3b187% /opt/gcc-nightly/trunk/bin/g++ -c valarray-bug.cc
In file included from
/opt/gcc-nightly/trunk-20090706/lib/gcc/powerpc64-linux/4.5.0/../../../../include/c++/4.5.0/valarray:562:0,
 from valarray-bug.cc:1:
/opt/gcc-nightly/trunk-20090706/lib/gcc/powerpc64-linux/4.5.0/../../../../include/c++/4.5.0/bits/valarray_after.h:
In member function ‘std::_Expr, bool> std::_Expr<_Clos, _Tp>::operator!() const [with _Clos =
std::_SClos, _Tp = int]’:
valarray-bug.cc:12:14:   instantiated from here
/opt/gcc-nightly/trunk-20090706/lib/gcc/powerpc64-linux/4.5.0/../../../../include/c++/4.5.0/bits/valarray_after.h:318:61:
error: conversion from ‘std::_Expr >, int>’ to non-scalar type
‘std::_Expr >, bool>’ requested

That's std::_Expr,int>
to std::_expr,bool>

I'm about to submit a proposed patch but would like a PR to keep track of this.


-- 
   Summary: bug in logical not operator for valarray used with slice
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janis at gcc dot gnu dot org


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

[Bug c++/40689] [C++0x]: error with initializer list in N2672

[bernhard dot merkle at googlemail dot com]

--- Comment #3 from bernhard dot merkle at googlemail dot com  2009-07-08 
20:56 ---
makes sense, thanks for the hint.

is there doc to which N papers the 4.5 trunk relates ?
e.g. like http://gcc.gnu.org/projects/cxx0x.html


-- 


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

[Bug fortran/40675] Support -fnosign-zero for SIGN intrinsic for Fortran 77 compatibility

[burnus at gcc dot gnu dot org]

--- Comment #16 from burnus at gcc dot gnu dot org  2009-07-08 20:55 ---
Close as FIXED (on the trunk [= 4.5]).

Greg, thanks for the report. Using a 4.5/trunk build (e.g. one of the nightly
builds) gfortran will offer the option -fno-sign-zero  which allows your
program to work.

However, I still would like to suggest to change the program such that it will
work also the default options. The problem will presumably also appear with
other compilers - for instance if they change their default.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/40690] invalid conversion in gimple call for vect tests

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-07-08 20:49 ---
I think this is really PR 30210.


-- 


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

[Bug tree-optimization/39960] [4.5 Regression] struct-reorg is broken

[janis at gcc dot gnu dot org]

--- Comment #2 from janis at gcc dot gnu dot org  2009-07-08 20:46 ---
On powerpc*-linux the test begins to fail in the same way with this patch:

http://gcc.gnu.org/viewcvs?view=rev&rev=146831

r146831 | rguenth | 2009-04-27 11:18:38 + (Mon, 27 Apr 2009)


-- 


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

[Bug c/39959] [4.5 Regression] IMA is broken

[janis at gcc dot gnu dot org]

--- Comment #4 from janis at gcc dot gnu dot org  2009-07-08 20:46 ---
On powerpc*-linux this test begins failing in the same way with this patch:

http://gcc.gnu.org/viewcvs?view=rev&rev=146831

r146831 | rguenth | 2009-04-27 11:18:38 + (Mon, 27 Apr 2009)


-- 


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

[Bug tree-optimization/40690] New: invalid conversion in gimple call for vect tests

[janis at gcc dot gnu dot org]

On powerpc*-unknown-linux-gnu several vectorization tests ICE in verify_stmts
after the error message "invalid conversion in gimple call":

gcc.dg/vect/no-scevccp-outer-7.c
gcc.dg/vect/no-scevccp-outer-13.c
gcc.dg/vect/slp-perm-1.c
gcc.dg/vect/slp-perm-2.c
gcc.dg/vect/slp-perm-3.c
gcc.dg/vect/slp-perm-8.c
gcc.dg/vect/vect-reduc-dot-u8b.c

The failures begin with this patch:

http://gcc.gnu.org/viewcvs?view=rev&rev=146831

r146831 | rguenth | 2009-04-27 11:18:38 + (Mon, 27 Apr 2009)

Here's a minimized testcase usable with a powerpc-linux cross compiler:

---
extern unsigned char X[64] __attribute__ ((__aligned__(32)));
extern unsigned char Y[64] __attribute__ ((__aligned__(32)));

unsigned short
foo (int len) {
  int i;
  unsigned short result = 0;

  for (i=0; ihttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=40690

[Bug c++/40689] [C++0x]: error with initializer list in N2672

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-07-08 20:38 ---
Before filing more bugs please verify the bugs exist on a recent version
of the development trunk for GCC 4.5.  C++0x is considered incomplete
technology preview only.


-- 


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

[Bug c++/40689] [C++0x]: error with initializer list in N2672

[bernhard dot merkle at googlemail dot com]

--- Comment #1 from bernhard dot merkle at googlemail dot com  2009-07-08 
20:29 ---
Created an attachment (id=18164)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18164&action=view)
program which should compile


-- 


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

[Bug c++/40689] New: [C++0x]: error with initializer list in N2672

[bernhard dot merkle at googlemail dot com]

Hi, 

I think there is a bug in g++ 4.4 concerning the implementation of initializer
list. N2672

The following program does not compiles, but it should be accepted by g++.

// /opt/gcc-4.4/bin/g++ --std=c++0x -Wall
int main() 
{

class X 
{
 public:
  X(): data {1,2,3,4,5} {}
 private:
  const short data[5];
};
const float * pData = new const float[4] { 1.5, 2.5, 3.5, 4.5 };

return 0;
}

$ /opt/gcc-4.4/bin/g++ -v
Using built-in specs.
Target: i686-pc-cygwin
Configured with: ./configure --prefix=/opt/gcc-4.4
Thread model: single
gcc version 4.4.0 (GCC)

$ /opt/gcc-4.4/bin/g++ --std=c++0x -Wall g++4.4BugN2672.cpp
g++4.4BugN2672.cpp: In constructor 'main()::X::X()':
g++4.4BugN2672.cpp:8: error: conversion from '' to non-scalar type 'const short int [5]
' requested
g++4.4BugN2672.cpp: In function 'int main()':
g++4.4BugN2672.cpp:12: error: ISO C++ forbids initialization in array new
g++4.4BugN2672.cpp:12: warning: unused variable 'pData'


-- 
   Summary: [C++0x]: error with initializer list in N2672
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bernhard dot merkle at googlemail dot com


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

[Bug c++/40688] [C++0x]: error with auto direct and copy initalization

[bernhard dot merkle at googlemail dot com]

--- Comment #1 from bernhard dot merkle at googlemail dot com  2009-07-08 
20:16 ---
Created an attachment (id=18163)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18163&action=view)
program which should compile


-- 


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

[Bug c++/40688] New: [C++0x]: error with auto direct and copy initalization

[bernhard dot merkle at googlemail dot com]

Hi, 

I think there is another bug in g++ 4.4 concerning the implementation of auto
with direct and copy initialization 7.1.6.4/3 in N2914

The following program should compile, but is rejected by g++.

int main() 
{
auto v1 = 1; // copy initialization syntax
auto v2(2); // direct initialization syntax

return 0;
}

$ /opt/gcc-4.4/bin/g++ -v
Using built-in specs.
Target: i686-pc-cygwin
Configured with: ./configure --prefix=/opt/gcc-4.4
Thread model: single
gcc version 4.4.0 (GCC)

$ /opt/gcc-4.4/bin/g++ --std=c++0x -Wall g++4.4Bug2AutoN2914.cpp
g++4.4Bug2AutoN2914.cpp: In function 'int main()':
g++4.4Bug2AutoN2914.cpp:5: error: 'v2' has incomplete type
g++4.4Bug2AutoN2914.cpp:4: warning: unused variable 'v1'
g++4.4Bug2AutoN2914.cpp:5: warning: unused variable 'v2'


-- 
   Summary: [C++0x]: error with auto direct and copy initalization
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bernhard dot merkle at googlemail dot com


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

[Bug c++/40684] ICE in tsubst

[dodji at gcc dot gnu dot org]

--- Comment #1 from dodji at gcc dot gnu dot org  2009-07-08 20:11 ---
I could reproduce on trunk.

I am testing the patchlet below:

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index b4bd465..d042f98 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -12949,8 +12949,9 @@ type_unification_real (tree tparms,
 to explicitly check cxx_dialect here.  */
   if (TREE_PURPOSE (TREE_VEC_ELT (tparms, i)))
 {
-  tree arg = tsubst (TREE_PURPOSE (TREE_VEC_ELT (tparms, i)), 
- targs, tf_none, NULL_TREE);
+  tree arg = tsubst_template_arg
+   (TREE_PURPOSE (TREE_VEC_ELT (tparms, i)),
+targs, tf_none, NULL_TREE);
   if (arg == error_mark_node)
 return 1;
   else


-- 

dodji at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dodji at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-07-08 20:11:16
   date||


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

[Bug c++/40687] [C++0x]: error with auto and 7.1.6.4/7 in N2914

[bernhard dot merkle at googlemail dot com]

--- Comment #1 from bernhard dot merkle at googlemail dot com  2009-07-08 
20:07 ---
Created an attachment (id=18162)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18162&action=view)
program which should not compile


-- 


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

[Bug c++/40687] New: [C++0x]: error with auto and 7.1.6.4/7 in N2914

[bernhard dot merkle at googlemail dot com]

Hi, 

I think there is a bug in g++ 4.4 concerning the implementation of auto.
7.1.6.4/7 in N2914

The following program compiles, but it should be rejected by g++.

int main() 
{
auto i = 10, d = 5.0; // error! shall not compile in C++0x

return 0;
}

$ /opt/gcc-4.4/bin/g++ -v
Using built-in specs.
Target: i686-pc-cygwin
Configured with: ./configure --prefix=/opt/gcc-4.4
Thread model: single
gcc version 4.4.0 (GCC)

$ /opt/gcc-4.4/bin/g++ --std=c++0x -Wall g++4.4BugAutoN2914.cpp
g++4.4BugAutoN2914.cpp: In function 'int main()':
g++4.4BugAutoN2914.cpp:4: warning: unused variable 'i'
g++4.4BugAutoN2914.cpp:4: warning: unused variable 'd'


-- 
   Summary: [C++0x]: error with auto and 7.1.6.4/7 in N2914
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bernhard dot merkle at googlemail dot com


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

[Bug tree-optimization/34437] several test failures for gcc.dg/vect/no-scevccp-*

[janis at gcc dot gnu dot org]

--- Comment #8 from janis at gcc dot gnu dot org  2009-07-08 19:48 ---
Fixed awhile ago by changing -mabi=altivec to the default for powerpc*-linux.


-- 

janis at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug c/37231] GCC does not compile code with label statements that are followed by a declaration

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2009-07-08 19:42 ---
(In reply to comment #3)
> Above code doesn't compile:

Yes it should not be compile.  The error message has been improved to tell you
what the problem is (that is what Manu was saying in his comment #2).


-- 


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

[Bug c/37231] GCC does not compile code with label statements that are followed by a declaration

[aapo dot rantalainen at gmail dot com]

--- Comment #3 from aapo dot rantalainen at gmail dot com  2009-07-08 19:36 
---
Above code doesn't compile:
int main(int argc, char *argv[])
{
  int a=1;
  switch (a)
{
case 1:
int b=2;
break;
}
return 0;
}

Error "a label can only be part of a statement and a declaration is not a
statement"

Same workaround:  add ; before int b=2;

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


-- 


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

[Bug fortran/40675] Support -fnosign-zero for SIGN intrinsic for Fortran 77 compatibility

[burnus at gcc dot gnu dot org]

--- Comment #15 from burnus at gcc dot gnu dot org  2009-07-08 19:35 ---
Subject: Bug 40675

Author: burnus
Date: Wed Jul  8 19:34:49 2009
New Revision: 149390

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149390
Log:
2009-07-08  Tobias Burnus  

PR fortran/40675
* simplify.c (gfc_simplify_sign): Handle signed zero correctly.
* trans-intrinsic.c (gfc_conv_intrinsic_sign): Support
-fno-sign-zero.
* invoke.texi (-fno-sign-zero): Add text regarding SIGN
* intrinsic.

2009-07-08  Tobias Burnus  

PR fortran/40675
* gfortran.dg/nosigned_zero_1.f90: New test.
* gfortran.dg/nosigned_zero_2.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/nosigned_zero_1.f90
trunk/gcc/testsuite/gfortran.dg/nosigned_zero_2.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/invoke.texi
trunk/gcc/fortran/simplify.c
trunk/gcc/fortran/trans-intrinsic.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/40629] Host association problem

[pault at gcc dot gnu dot org]

--- Comment #4 from pault at gcc dot gnu dot org  2009-07-08 19:05 ---
(In reply to comment #3)
> Created an attachment (id=18157)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18157&action=view) [edit]
> Fix for bug - not regtested yet
> 
> This handles host_assoc_function_*.f90 correctly but is not yet regtested.
> 
> The testcase will be something like:
> 
> ! { dg-do run }
> ! Tests the fix for the bug PR40629, in which the reference to 'x'
> ! in 'upper' wrongly host-associated with the symbol 'x' at module
> ! leve rather than the function.
> !
> ! Contributed by Philippe Marguinaud  
> !
> MODULE m
>   REAL :: x = 0
> CONTAINS
>   
>  
>   
>  
>   
>  
>   
>  
>   
>  
>  
> SUBROUTINE s
>   call upper
>   call lower
>   CONTAINS
> SUBROUTINE upper
>  y = x(3,1)
>  if (int(y) .ne. 3) call abort
> END SUBROUTINE
> FUNCTION x(n, m)
>x = m*n
> END FUNCTION
> SUBROUTINE lower
>  y = x(2,1)
>  if (int(y) .ne. 3) call abort
> END SUBROUTINE
>   END SUBROUTINE
> END MODULE
> 
>   use m
>   call s
> end
> ! { dg-final { cleanup-modules "m" } }
> 
> 
> Paul
> 

The last abort should happen on a value of 2, of course.

Paul


-- 


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

[Bug fortran/40683] gfortran.dg/proc_ptr_21.f90 doesn't work for 32bit

[pault at gcc dot gnu dot org]

--- Comment #3 from pault at gcc dot gnu dot org  2009-07-08 19:00 ---
Subject: Bug 40683

Author: pault
Date: Wed Jul  8 19:00:17 2009
New Revision: 149383

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149383
Log:
2008-07-08  Paul Thomas  

PR fortran/40683
* gfortran.dg/proc_ptr_21.f90: Initialize 'i'.


Modified:
trunk/gcc/testsuite/gfortran.dg/proc_ptr_21.f90


-- 


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

[Bug c/21920] aliasing violations

[pinskia at gcc dot gnu dot org]

--- Comment #142 from pinskia at gcc dot gnu dot org  2009-07-08 18:22 
---
*** Bug 40686 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||songyulu at hdfgroup dot org


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

[Bug c/40686] Optimization Problem With Data Conversion

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-07-08 18:22 ---
You are violating C/C++ aliasing rules:
  d = (uint8_t*)&aligned; 

  /* This line causes the trouble. */
  *((int*)d) = (int)(*((short*)s));

You are writing into a long long via an int which causes undefined behavior.

There are more aliasing problems in this file too with the loop at:
printf("before conversion:\n");
And
printf("after conversion:\n");

As those are accessing an char via a short or an int.

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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug debug/40659] A simple struct member offset doesn't need a full dwarf location expression

[mark at gcc dot gnu dot org]

--- Comment #2 from mark at gcc dot gnu dot org  2009-07-08 18:21 ---
Patch pushed.


-- 

mark at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug c/40686] New: Optimization Problem With Data Conversion

[songyulu at hdfgroup dot org]

Our HDF5 software has been having some data conversion problem with GCC's
optimization for a few years.  One example is to convert data from short to
int.  You can find the program at

 ftp://ftp.hdfgroup.uiuc.edu/pub/outgoing/slu/tmp/ctest.c

When I use "gcc -O2" or "gcc -O3" to compile it, I get wrong values after the
conversion.  When I use "gcc -O0" or "gcc -O1", the values are correct.

I'll greatly appreciate your help if you can have a look at it.


-- 
   Summary: Optimization Problem With Data Conversion
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: songyulu at hdfgroup dot org


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

[Bug debug/40659] A simple struct member offset doesn't need a full dwarf location expression

[mark at gcc dot gnu dot org]

--- Comment #1 from mark at gcc dot gnu dot org  2009-07-08 18:08 ---
Subject: Bug 40659

Author: mark
Date: Wed Jul  8 18:07:47 2009
New Revision: 149377

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149377
Log:
2009-07-08  Mark Wielaard  

PR debug/40659
* dwarf2out.c (add_data_member_location_attribute): When we have
only a constant offset don't emit a new location description using
DW_OP_plus_uconst, but just add the constant with add_AT_int, when
dwarf_version > 2.

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


-- 


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

[Bug testsuite/40625] [4.5 Regression] Errors in "make -k check-gcc RUNTESTFLAGS=plugin.exp"

[tjruwase at google dot com]

--- Comment #4 from tjruwase at google dot com  2009-07-08 17:59 ---
Subject: Re:  [4.5 Regression] Errors in "make -k 
check-gcc RUNTESTFLAGS=plugin.exp"

Your fix works for me.


-- 


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

[Bug target/40668] 64-bit sparc miscompiles memcpy of argument inside switch

[blp at cs dot stanford dot edu]

--- Comment #8 from blp at cs dot stanford dot edu  2009-07-08 17:30 ---
Wow, that's amazingly fast turnaround.  Thanks so much guys!


-- 


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

[Bug testsuite/40625] [4.5 Regression] Errors in "make -k check-gcc RUNTESTFLAGS=plugin.exp"

[janis at gcc dot gnu dot org]

--- Comment #3 from janis at gcc dot gnu dot org  2009-07-08 17:08 ---
I can reproduce the error with plugin.exp not struct-layout-1.exp.  This fixes
it for me, does it for you guys?

Index: gcc/testsuite/lib/gcc.exp
===
--- gcc/testsuite/lib/gcc.exp   (revision 149287)
+++ gcc/testsuite/lib/gcc.exp   (working copy)
@@ -96,6 +96,7 @@ proc gcc_init { args } {
 global TOOL_EXECUTABLE
 global gcc_warning_prefix
 global gcc_error_prefix
+global ld_library_path

 if { $gcc_initialized == 1 } { return; }

@@ -113,6 +114,7 @@ proc gcc_init { args } {

 set gcc_warning_prefix "warning:"
 set gcc_error_prefix "error:"
+set ld_library_path ""

 gcc_maybe_build_wrapper "${tmpdir}/gcc-testglue.o"
 }


-- 


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

[Bug target/38900] ICE: unable to find a register to spill

[rth at gcc dot gnu dot org]

--- Comment #18 from rth at gcc dot gnu dot org  2009-07-08 17:03 ---
Fixed.


-- 

rth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug target/38900] ICE: unable to find a register to spill

[rth at gcc dot gnu dot org]

--- Comment #17 from rth at gcc dot gnu dot org  2009-07-08 16:59 ---
Subject: Bug 38900

Author: rth
Date: Wed Jul  8 16:59:15 2009
New Revision: 149374

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149374
Log:
PR target/38900
* config/i386/i386.h (CONDITIONAL_REGISTER_USAGE): Move to i386.c.
(enum reg_class): Add CLOBBERED_REGS.
(REG_CLASS_NAMES, REG_CLASS_CONTENTS): Likewise.
* config/i386/i386.c (ix86_conditional_register_usage): Moved
from CONDITIONAL_REGISTER_USAGE; build CLOBBERED_REGS for 64-bit.
(ix86_function_ok_for_sibcall): Tidy.  Disallow MS->SYSV sibcalls.
(ix86_expand_call): Use sibcall_insn_operand when needed.  Don't
force 64-bit sibcalls into R11.
* config/i386/constraints.md (U): New constraint.
* config/i386/i386.md (sibcall_1, sibcall_value_1): Use it.
(sibcall_1_rex64, sibcall_value_1_rex64): Likewise.
(sibcall_1_rex64_v, sibcall_value_1_rex64_v): Remove.

Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/config/i386/constraints.md
branches/gcc-4_4-branch/gcc/config/i386/i386-protos.h
branches/gcc-4_4-branch/gcc/config/i386/i386.c
branches/gcc-4_4-branch/gcc/config/i386/i386.h
branches/gcc-4_4-branch/gcc/config/i386/i386.md


-- 


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

[Bug fortran/40675] Support -fnosign-zero for SIGN intrinsic for Fortran 77 compatibility

[kargl at gcc dot gnu dot org]

--- Comment #14 from kargl at gcc dot gnu dot org  2009-07-08 16:56 ---
(In reply to comment #11)
> Created an attachment (id=18158)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18158&action=view) [edit]
> Patch - lightly tested
> 
> Attached patch fixes the problem [independent of
> "-f(no-)signed-zeros"/-ffast-math].
> 
> The crucial option is "-fno-sign-zero" (which shall not be confused with
> -f(no-)signed-zeros):
> 
> $ gfortran -O3 -fno-sign-zero ahfj.f90 && ./a.out
>  With val =0.000  test =0.000
>  pass
> 

I've tested the patch and the -ftree-dump-original output
looks correct.  I've also attached two testcase for the
testsuite.  I do note that this option is activated by
-std=legacy.  Perhaps, it should be.

Patch is okay.


-- 


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

[Bug fortran/40675] Support -fnosign-zero for SIGN intrinsic for Fortran 77 compatibility

[kargl at gcc dot gnu dot org]

--- Comment #13 from kargl at gcc dot gnu dot org  2009-07-08 16:50 ---
Created an attachment (id=18161)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18161&action=view)
dejagnu test case

Test case for sign(x,+-0) when the new -fno-sign-zero option is used.


-- 


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

[Bug fortran/40675] Support -fnosign-zero for SIGN intrinsic for Fortran 77 compatibility

[kargl at gcc dot gnu dot org]

--- Comment #12 from kargl at gcc dot gnu dot org  2009-07-08 16:49 ---
Created an attachment (id=18160)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18160&action=view)
dejagnu testr case

Test that sign(x, +-0) conforms to F95.


-- 


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

[Bug target/40668] 64-bit sparc miscompiles memcpy of argument inside switch

[mikpe at it dot uu dot se]

--- Comment #7 from mikpe at it dot uu dot se  2009-07-08 16:43 ---
4.4-20090630 plus this fix bootstrapped fine, fixed the test case, built a
working 2.6.31-rc2 Linux kernel, and built a working Erlang VM.


-- 


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

[Bug target/38900] ICE: unable to find a register to spill

[rth at gcc dot gnu dot org]

--- Comment #16 from rth at gcc dot gnu dot org  2009-07-08 16:41 ---
Subject: Bug 38900

Author: rth
Date: Wed Jul  8 16:41:23 2009
New Revision: 149373

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149373
Log:
PR target/38900
* config/i386/i386.h (CONDITIONAL_REGISTER_USAGE): Move to i386.c.
(enum reg_class): Add CLOBBERED_REGS.
(REG_CLASS_NAMES, REG_CLASS_CONTENTS): Likewise.
* config/i386/i386.c (ix86_conditional_register_usage): Moved
from CONDITIONAL_REGISTER_USAGE; build CLOBBERED_REGS for 64-bit.
(ix86_function_ok_for_sibcall): Tidy.  Disallow MS->SYSV sibcalls.
(ix86_expand_call): Use sibcall_insn_operand when needed.  Don't
force 64-bit sibcalls into R11.
* config/i386/constraints.md (U): New constraint.
* config/i386/i386.md (sibcall_1, sibcall_value_1): Use it.
(sibcall_1_rex64, sibcall_value_1_rex64): Likewise.
(sibcall_1_rex64_v, sibcall_value_1_rex64_v): Remove.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/constraints.md
trunk/gcc/config/i386/i386-protos.h
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/i386.h
trunk/gcc/config/i386/i386.md


-- 


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

[Bug c++/40685] New: explicit constructor is used where only implicit ctors are allowed

[kretz at kde dot org]

The following testcase fails on g++ 4.4.0 and 4.3.2:

#include 

enum Enum {
Foo
};

class A
{
public:
A(int y) : x(y) {}
explicit A(Enum) : x(1) {}

int x;
};

static void fun(A a = Foo)
{
if (a.x != static_cast(Foo)) {
abort();
}
}

int main()
{
fun();
return 0;
}

If the A(int) ctor is removed the program does not compile, as is expected. If
the line "A a = Foo" appears inside the function instead of the parameter list
then g++ correctly uses the A(int) ctor.

While on that topic: The code above was meant to use the Enum ctor, it would be
nice if g++ emits a warning about the emitted code probably using the wrong
ctor.


-- 
   Summary: explicit constructor is used where only implicit ctors
are allowed
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kretz at kde dot org
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug c++/40684] New: ICE in tsubst

[jakub at gcc dot gnu dot org]

// { dg-options "-std=c++0x" }

struct A
{
};

template 
typename S::A
foo (S c, T t, U u)
{
}

struct B
{
  struct C
  {
template 
C (U t)
{
  A a;
  A b = foo (this, a, t);
}
  } c;
  B () : c (A ())
  {
  }
};

int
main ()
{
  B f;
}

ICEs in tsubst (seeing ADDR_EXPR there).  This is likely invalid testcase,
though the ICE is the only diagnostics issued, whether the original
testcase from http://bugzilla.redhat.com/509596 is valid or not is unclear.


-- 
   Summary: ICE in tsubst
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org


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

[Bug target/40677] flag -mmultiple is ignored

[edmar at freescale dot com]

--- Comment #4 from edmar at freescale dot com  2009-07-08 15:06 ---
I did not run any test suite, nor prepared any test case suitable for inclusion
in dejagnu suite.
I opened a bug hopping the information I gave would help resolve the issue
faster.


-- 


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

[Bug fortran/40675] Support -fnosign-zero for SIGN intrinsic for Fortran 77 compatibility

[burnus at gcc dot gnu dot org]

--- Comment #11 from burnus at gcc dot gnu dot org  2009-07-08 14:55 ---
Created an attachment (id=18158)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18158&action=view)
Patch - lightly tested

Attached patch fixes the problem [independent of
"-f(no-)signed-zeros"/-ffast-math].

The crucial option is "-fno-sign-zero" (which shall not be confused with
-f(no-)signed-zeros):

$ gfortran -O3 -fno-sign-zero ahfj.f90 && ./a.out
 With val =0.000  test =0.000
 pass


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |burnus at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED


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

[Bug c++/40557] [4.5 Regression] ICE with template union

[hjl at gcc dot gnu dot org]

--- Comment #4 from hjl at gcc dot gnu dot org  2009-07-08 14:30 ---
Subject: Bug 40557

Author: hjl
Date: Wed Jul  8 14:30:12 2009
New Revision: 149371

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149371
Log:
2009-07-08  H.J. Lu  

Backport from mainline:
2009-07-06  Simon Martin  

PR c++/40557
* g++.dg/template/union2.C: New test.

Added:
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/union2.C
  - copied unchanged from r149370,
trunk/gcc/testsuite/g++.dg/template/union2.C
Modified:
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/40591] Procedure(interface): Rejected if interface is indirectly hostassociated

[dominiq at lps dot ens dot fr]

--- Comment #7 from dominiq at lps dot ens dot fr  2009-07-08 13:31 ---
pr40683 is a duplicate.


-- 


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

[Bug fortran/40683] gfortran.dg/proc_ptr_21.f90 doesn't work for 32bit

[pault at gcc dot gnu dot org]

--- Comment #2 from pault at gcc dot gnu dot org  2009-07-08 13:29 ---
(In reply to comment #1)
> See pr40591 comments #4 and #5.
> 
 Indeed! I'll fix it tonight.

Thanks, HJ

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pault at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-07-08 13:29:18
   date||


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

[Bug fortran/40591] Procedure(interface): Rejected if interface is indirectly hostassociated

[pault at gcc dot gnu dot org]

--- Comment #6 from pault at gcc dot gnu dot org  2009-07-08 13:28 ---
(In reply to comment #5)

> That is solved by adding:
>i = 0
> to subroutine test (while any other number causes the abortion).
> 

Indeed - that was in the test originally; I do not know what happened to it.
I'll put it right tonight.

Thanks

Paul


-- 


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

[Bug middle-end/40156] [4.4 Regression] Possible bogus warning in libstdc++ headers

[manu at gcc dot gnu dot org]

--- Comment #8 from manu at gcc dot gnu dot org  2009-07-08 13:28 ---
I am going to close this as FIXED, since it cannot be reproduced anymore. If
anyone manages to reproduce it in GCC 4.5, please reopen.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug fortran/40683] gfortran.dg/proc_ptr_21.f90 doesn't work for 32bit

[dominiq at lps dot ens dot fr]

--- Comment #1 from dominiq at lps dot ens dot fr  2009-07-08 13:28 ---
See pr40591 comments #4 and #5.


-- 


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

[Bug middle-end/39891] Bogus location given for warning, no warning at real location: dereferencing pointer �� does break strict-aliasing rules

[manu at gcc dot gnu dot org]

--- Comment #5 from manu at gcc dot gnu dot org  2009-07-08 13:25 ---
(In reply to comment #3)
> 
> Note that getInt is completely inlined and there is no location involving
> that function available anymore :/  The difficulties of C++ and late
> diagnostics ...

Don't we keep abstract_origin somewhere? I have seen in the middle-end that
sometimes we test whether something is an inline variable or not.


-- 


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

[Bug fortran/40629] Host association problem

[pault at gcc dot gnu dot org]

--- Comment #3 from pault at gcc dot gnu dot org  2009-07-08 13:22 ---
Created an attachment (id=18157)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18157&action=view)
Fix for bug - not regtested yet

This handles host_assoc_function_*.f90 correctly but is not yet regtested.

The testcase will be something like:

! { dg-do run }
! Tests the fix for the bug PR40629, in which the reference to 'x'
! in 'upper' wrongly host-associated with the symbol 'x' at module
! leve rather than the function.
!
! Contributed by Philippe Marguinaud  
!
MODULE m
  REAL :: x = 0
CONTAINS
   
   
   
   
   
 
SUBROUTINE s
  call upper
  call lower
  CONTAINS
SUBROUTINE upper
 y = x(3,1)
 if (int(y) .ne. 3) call abort
END SUBROUTINE
FUNCTION x(n, m)
   x = m*n
END FUNCTION
SUBROUTINE lower
 y = x(2,1)
 if (int(y) .ne. 3) call abort
END SUBROUTINE
  END SUBROUTINE
END MODULE

  use m
  call s
end
! { dg-final { cleanup-modules "m" } }


Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pault at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED


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

[Bug fortran/40683] New: gfortran.dg/proc_ptr_21.f90 doesn't work for 32bit

[hjl dot tools at gmail dot com]

On Linux/ia32, revision 149362 gave

FAIL: gfortran.dg/proc_ptr_21.f90  -O1  execution test
FAIL: gfortran.dg/proc_ptr_21.f90  -O2  execution test
FAIL: gfortran.dg/proc_ptr_21.f90  -O3 -fomit-frame-pointer  execution test
FAIL: gfortran.dg/proc_ptr_21.f90  -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  execution test
FAIL: gfortran.dg/proc_ptr_21.f90  -O3 -fomit-frame-pointer -funroll-loops 
execution test
FAIL: gfortran.dg/proc_ptr_21.f90  -O3 -g  execution test
FAIL: gfortran.dg/proc_ptr_21.f90  -Os  execution test

I got the same result with gcc -m32 on Linux/x86-64.


-- 
   Summary: gfortran.dg/proc_ptr_21.f90 doesn't work for 32bit
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com


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

[Bug tree-optimization/40679] Optimizer handles loops with volatiles and post-incr. wrong

[rguenth at gcc dot gnu dot org]

--- Comment #9 from rguenth at gcc dot gnu dot org  2009-07-08 13:11 ---
induction variable optimization is different w/o volatile.


-- 


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

[Bug tree-optimization/40679] Optimizer handles loops with volatiles and post-incr. wrong

[bastian dot schick at sciopta dot com]

--- Comment #8 from bastian dot schick at sciopta dot com  2009-07-08 13:06 
---
(In reply to comment #6)
> (In reply to comment #2)
> > Replacing *tbl++ by tbl[i] gives this ARM code:
> > .L2:
> > mov r3, #10
> > str r3, [r2], #4
> > cmp r2, #0
> > bne .L2
> > bx  lr
> > 
> > See, gcc knows about the wrapping but still the *tbl++ version misses the
> > end-condition which is the bug.
> 
> The difference is that in the tbl[i] version there will not be a wraparound at
> runtime because &tbl[i] for i == 64 is never computed, while in the *tbl++
> version the iteration with i == 63 will do tbl++ moving tbl from -4U to 0
> before the loop termination test, which triggers undefined behaviour.

Ok fine, but why does it generate correct code if not using volatile for the
pointer ?!
mvn r2, #251
.L2:
mov r3, #10
str r3, [r2, #-4]
add r2, r2, #4
cmp r2, #4
bne .L2
bx  lr
Strange, no post-increment code is generated.
The 68k version still uses post-increment and voilà, endless-loop.

Also see the code for the tbl[i] version, the pointer still wraps.

I suspect following: The test for 0 is removed maybe because the post-increment
is defined to change flags( which it isn't). Since there is no test, the next
optimization changes a "jump not zero" to an "jump always".


-- 


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

[Bug c++/40682] [C++0x] Require direct binding of short-lived references to rvalues

[paolo dot carlini at oracle dot com]

--- Comment #3 from paolo dot carlini at oracle dot com  2009-07-08 12:47 
---
To be clear, I'm not telling you anything specific about the development
process. Actually, that's exactly the point, this is ongoing development of
experimental features, no guarantees, no guarantees of perfect adherence to the
last public draft, etc.


-- 


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

[Bug c++/40682] [C++0x] Require direct binding of short-lived references to rvalues

[dragan at plusplus dot co dot yu]

--- Comment #2 from dragan at plusplus dot co dot yu  2009-07-08 12:38 
---
Although this is a feature request in the context that the old behavior
was correctly implemented and it will be different in C++0x, it still presents
a bug in the current C++0x implementation. It creates copies of
objects that are returned by a rvalue reference, which would be wrong.
I wasn't _really_ trying to request a new functionality, although
I understand your concern.

However, IMHO in this particular case we are talking about one of
the most fundamental features (binding a reference). This change
could also expose possible bugs in the (user and library) code that
relies on creation of a temporary, which even in C++03 is not
considered a portable code. Don't tell me you'd rather deal with
the issue after all the other C++0x stuff gets implemented...

Anyway, my motive was to help the development of GCC. Personally,
I didn't and will not rely on either of the two behaviors, but
will try to write code that works in both situations.


-- 


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

[Bug fortran/40591] Procedure(interface): Rejected if interface is indirectly hostassociated

[burnus at gcc dot gnu dot org]

--- Comment #5 from burnus at gcc dot gnu dot org  2009-07-08 12:37 ---
(In reply to comment #4)
> It seems that gfortran.dg/proc_ptr_21.f90 is failing on i686-pc-linux-gnu and
> Intel64(?), see

I can - somewhat - reproduce it. It does not fail but valgrind shows
(x86-64-linux and i686-linux):

==32231== Conditional jump or move depends on uninitialised value(s)
==32231==at 0x80485A2: test.1513 (proc_ptr_21.f90:26)
==32231==by 0x8048548: MAIN__ (proc_ptr_21.f90:8)
==32231==by 0x80485F4: main (proc_ptr_21.f90:8)

That is solved by adding:
   i = 0
to subroutine test (while any other number causes the abortion).


-- 


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

[Bug rtl-optimization/30807] postreload bug (might be generic in trunk)

[kkojima at gcc dot gnu dot org]

--- Comment #10 from kkojima at gcc dot gnu dot org  2009-07-08 11:54 
---
I don't think this is a regression, unfortunately.


-- 


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