[Bug tree-optimization/39207] [4.4 Regression] Strict aliasing warnings in libstdc++ headers

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2009-02-17 07:14 ---
The reason it got reported to me is package(s) failing to build with -Werror,
nothing wrong in the application code (the bug is supposedly either in the
aliasing code, FE or libstdc++-v3 headers) and no obvious way to work around
the warning. 


-- 


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

[Bug middle-end/39210] g++ 4.3 takes hours to compile greycstoration

[steven at gcc dot gnu dot org]

--- Comment #4 from steven at gcc dot gnu dot org  2009-02-17 06:31 ---
Investigating...


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |steven at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-02-17 06:31:17
   date||


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

[Bug libgcj/39161] gcc 4.4.0 20090210 - The 'copy-vmresources.sh' script can't find the 'mkinstalldirs' script.

[rob1weld at aol dot com]

--- Comment #1 from rob1weld at aol dot com  2009-02-17 05:11 ---
This does not occur with:

# gcc/xgcc -v
Using built-in specs.
Target: i386-pc-solaris2.11
Configured with: ../gcc_trunk/configure --build=i386-pc-solaris2.11
--enable-languages=ada,c,c++,fortran,java,objc,obj-c++ --enable-shared
--disable-static --enable-multilib --enable-decimal-float
--with-long-double-128 --with-included-gettext --enable-stage1-checking
--enable-checking=release --with-tune=k8 --with-cpu=k8 --with-arch=k8
--with-gnu-as --with-as=/usr/local/bin/as --without-gnu-ld
--with-ld=/usr/bin/amd64/ld --with-gmp=/usr/local --with-mpfr=/usr/local
--without-ppl
Thread model: posix
gcc version 4.4.0 20090216 (experimental) [trunk revision 144203] (GCC) 

Rob


-- 


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

[Bug target/39212] ice for AVR target: unable to find a register to spill in class 'POINTER_REGS'

[eric dot weddington at atmel dot com]

--- Comment #3 from eric dot weddington at atmel dot com  2009-02-17 05:09 
---
Fails on 4.3.2 with -O[123s] -fno-inline-small-functions.
Success on 4.3.2 with -O0 -fno-inline-small-functions.


-- 


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

[Bug target/39212] ice for AVR target: unable to find a register to spill in class 'POINTER_REGS'

[eric dot weddington at atmel dot com]

--- Comment #2 from eric dot weddington at atmel dot com  2009-02-17 05:02 
---
Success on 4.3.2 with -O1 -finline-small-functions.
Fails on 4.3.2 with -O1 -fno-inline-small-functions.


-- 


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

[Bug fortran/32317] [bounds checking] No warning on bad arguments with explicit interface

[terry at chem dot gu dot se]

--- Comment #8 from terry at chem dot gu dot se  2009-02-17 04:51 ---
It's not as frivolous as it sounds.  ;-)

If it is indeed illegal not to obey an explicit interface (and though I can't
see anywhere in the standard that says this, the standard is pretty stupid if
it's not) then this changes from a bound-check-related enhancement to an
accepts-invalid error.


-- 

terry at chem dot gu dot se changed:

   What|Removed |Added

Version|4.2.0   |4.3.3


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

[Bug c/39212] ice for AVR target: unable to find a register to spill in class 'POINTER_REGS'

[eric dot weddington at atmel dot com]

--- Comment #1 from eric dot weddington at atmel dot com  2009-02-17 04:43 
---
Fails on 4.3.2 with -O1, successful with -O[023s].


-- 

eric dot weddington at atmel dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  Known to fail||4.3.3 4.3.2
   Last reconfirmed|-00-00 00:00:00 |2009-02-17 04:43:39
   date||
Version|unknown |4.3.3


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

[Bug preprocessor/39213] New: [4.4 Regression] Preprocessor ICE with -m64 and --traditional-cpp

[rob1weld at aol dot com]

+++ This bug was initially created as a clone of 
Bug #15913 "[4.0 Regression] Preprocessor dies 
on // comment if --traditional-cpp is specified" +++

The example in Bug #15913 compiles correctly with trunk revision 144203
but the Testsuite ../gcc_trunk/gcc/testsuite/gcc.dg/cpp/trad/include.c
does not. It compile without an ICE using gcc 3.4.3 so this is a 
Regression on the Trunk.


Works (gcc "3.4.3 (csl-sol210-3_4-branch+sol_rpath)") :

# /usr/sfw/bin/gcc -v
Reading specs from /usr/sfw/lib/gcc/i386-pc-solaris2.10/3.4.3/specs
Configured with: /builds/sfw10-gate/usr/src/cmd/gcc/gcc-3.4.3/configure
--prefix=/usr/sfw --with-as=/usr/sfw/bin/gas --with-gnu-as
--with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++
--enable-shared
Thread model: posix
gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath)

#/usr/sfw/bin/gcc -m64 -E --traditional-cpp
../gcc_trunk/gcc/testsuite/gcc.dg/cpp/trad/include.c -o delete-include.i
# (no error messages)


Works (Without "--traditional-cpp") :

# /usr/local/bin/gcc -m64 -E
/usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/cpp/trad/include.c -o
delete-include.i
/usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/cpp/trad/include.c:10:1: warning:
"__STDC__" redefined
# (no error messages)


Works (Without "-m64") :

# /usr/local/bin/gcc -E --traditional-cpp
/usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/cpp/trad/include.c -o
delete-include.i
# (no error messages)



ICE (use both "-m64" and "--traditional-cpp"):

# /usr/local/bin/gcc -v
Using built-in specs.
Target: i386-pc-solaris2.11
Configured with: ../gcc_trunk/configure --build=i386-pc-solaris2.11
--enable-languages=ada,c,c++,fortran,java,objc,obj-c++ --enable-shared
--disable-static --enable-multilib --enable-decimal-float
--with-long-double-128 --with-included-gettext --enable-stage1-checking
--enable-checking=release --with-tune=k8 --with-cpu=k8 --with-arch=k8
--with-gnu-as --with-as=/usr/local/bin/as --without-gnu-ld
--with-ld=/usr/bin/amd64/ld --with-gmp=/usr/local --with-mpfr=/usr/local
--without-ppl
Thread model: posix
gcc version 4.4.0 20090216 (experimental) [trunk revision 144203] (GCC) 

# /usr/local/bin/gcc -m64 -E --traditional-cpp
/usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/cpp/trad/include.c -o
delete-include.i
:0: internal compiler error: Abort
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.


Thanks,
Rob


-- 
   Summary: [4.4 Regression] Preprocessor ICE with -m64 and --
traditional-cpp
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rob1weld at aol dot com
 GCC build triplet: i386-pc-solaris2.11
  GCC host triplet: i386-pc-solaris2.11
GCC target triplet: i386-pc-solaris2.11


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

[Bug c++/39211] Function pass by reference problem, accepts parameters (int, int) to an (int*, int*) function.

[eakrohn at cs dot uiowa dot edu]

--- Comment #2 from eakrohn at cs dot uiowa dot edu  2009-02-17 04:00 
---
Problem fixed, didn't realize there was a built in swap that was getting
called.  My mistake.


-- 

eakrohn at cs dot uiowa dot edu changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c++/39211] Function pass by reference problem, accepts parameters (int, int) to an (int*, int*) function.

[eakrohn at cs dot uiowa dot edu]

--- Comment #1 from eakrohn at cs dot uiowa dot edu  2009-02-17 03:53 
---
My concern is this function

swap(int *x, int *y){ ... }

with this function call

int x = 5, y = 7;
swap(x,y);

compiles and works just fine.  But this function

swap(int *x){ ... }

with this function call

int x;
swap(x); 

is a compile error.  It's not consistent.


-- 


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

[Bug c/39212] New: ice for AVR target: unable to find a register to spill in class 'POINTER_REGS'

[regehr at cs dot utah dot edu]

This bug is seen using the avr-gcc that gets built by the script that comes
with FemtoOS 0.88.

reg...@john-home:~/volatile/tmp140$ avr-gcc -O1 small.c
small.c: In function 'uint32func':
small.c:22: error: unable to find a register to spill in class 'POINTER_REGS'
small.c:22: error: this is the insn:
(insn 61 59 141 4 small.c:20 (set (reg:SI 24 r24 [55])
(ashiftrt:SI (subreg:SI (reg/v:DI 46 [ p_48 ]) 0)
(const_int 31 [0x1f]))) 60 {ashrsi3} (nil))
small.c:22: confused by earlier errors, bailing out

reg...@john-home:~/volatile/tmp140$ avr-gcc -v 

Using built-in specs.
Target: avr
Configured with: ../gcc-4.3.3/configure --prefix=/home/regehr/avr-gcc-test
--target=avr --with-gnu-ld --with-gnu-as --enable-languages=c,c++ --disable-nls
--disable-libssp --with-dwarf2
Thread model: single
gcc version 4.3.3 (GCC) 

reg...@john-home:~/volatile/tmp140$ cat small.c

typedef int uint64_t __attribute__ ((__mode__ (__DI__)));

static long int safe_mod_func_int32_t_s_s (long int _si1, long int _si2)
{
  return -1 ? _si1 : 1;
}

uint64_t safe_sub_func_uint64_t_u_u (uint64_t _ui1, uint64_t _ui2)
{
  return 0;
}

int foo (int,int,int);
int bar (int);

long int g_14; 

int uint32func (uint64_t p_48)
{
  return foo (safe_mod_func_int32_t_s_s (p_48, 0) ==
   safe_sub_func_uint64_t_u_u (g_14, 1), bar (g_14 == 1), 1);
}


-- 
   Summary: ice for AVR target: unable to find a register to spill
in class 'POINTER_REGS'
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: regehr at cs dot utah dot edu
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: avr


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

[Bug c++/39211] New: Function pass by reference problem, accepts parameters (int, int) to an (int*, int*) function.

[eakrohn at cs dot uiowa dot edu]

The following code works and it shouldn't.  It only works with passing 2
parameters from what I tested.  If I try swap(int *x) or swap(int *x, int *y,
int *z), it gives an error as expected.  But with 2 parameters it compiles and
runs.  

void swap(int *x, int *y)
{
int temp;
temp = *x;
*x = *y;
*y = temp;
}

int main()
{
int x = 10;
int y = 20;
std::cout << x << " " << y << endl;
swap(x,y);  //this compiles, runs and swaps...  it shouldn't
std::cout << x << " " << y << endl;
}


-- 
   Summary: Function pass by reference problem, accepts parameters
(int, int) to an (int*, int*) function.
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eakrohn at cs dot uiowa dot edu


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

Pass by reference problem

[e211]

//The following code works and there is no way it should.  Seems like a bug
someone put in on purpose

#include 
using namespace std;

void swap(int *x, int *y)
{
int temp;
temp = *x;
*x = *y;
*y = temp;
}

int main()
{
int x = 10;
int y = 20;
cout << x << " " << y << endl;
swap(x,y);  //how does this work, there is no way this should compile 
and
run and actually work
cout << x << " " << y << endl;
}

-- 
View this message in context: 
http://www.nabble.com/Pass-by-reference-problem-tp22049211p22049211.html
Sent from the gcc - bugs mailing list archive at Nabble.com.

[Bug tree-optimization/39204] [4.4 Regression] ICE in compute_attic

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P1


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

[Bug tree-optimization/39202] [4.4 Regression] internal compiler error: in collapse_rest_of_var, at tree-ssa-structalias.c:3296

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P1


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

[Bug tree-optimization/39207] [4.4 Regression] Strict aliasing warnings in libstdc++ headers

[mmitchel at gcc dot gnu dot org]

--- Comment #4 from mmitchel at gcc dot gnu dot org  2009-02-17 02:53 
---
The key question is whether the bogus warning could indicate a potential for
miscompilation.  If it's "just" a bogus warning, then it's going to annoy and
confuse people, but not result in too much damage.  But, if this means that
we're likely to miscompile things, then we have a worse problem.  Of course,
until someone demonstrates an actual miscompilation, that's perhaps something
of a theoretical problem.

I'll leave this as P3 until we know more. 


-- 


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

[Bug c++/39209] Code generated for calling pointer-to-member segfaults when address of p-t-m is not 16-bit aligned

[hjl dot tools at gmail dot com]

--- Comment #1 from hjl dot tools at gmail dot com  2009-02-17 02:28 ---
Please provide a reproducible testcase. It could be related to
PR 36159.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||hjl dot tools at gmail dot
   ||com


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

[Bug target/34587] gcc.dg/initpri1.c fails on *-apple-darwin

[danglin at gcc dot gnu dot org]

--- Comment #11 from danglin at gcc dot gnu dot org  2009-02-17 01:37 
---
It is a limitation of the Apple assembler and linker.  From the Apple assembler
manual:

.mod_init_func
This is equivalent to .section __DATA, __mod_init_func, mod_init_funcs
This section is of type mod_init_funcs and has no attributes. The C++ compiler
places a pointer to a
function in this section for each function it creates to call the constructors
(if the module has them).

.mod_term_func
This is equivalent to .section __DATA, __mod_term_func, mod_term_funcs
This section is of type mod_term_funcs and has no attributes. The C++ compiler
places a pointer to a
function in this section for each function it creates to call the destructors
(if the module has them).

These directives don't allow for a priority.

It might be possible to sort constructors/destructors with collect2, but for
now it as if something like the following

/* The Apple linker does not support constructor priorities.  */
#undef SUPPORTS_INIT_PRIORITY
#define SUPPORTS_INIT_PRIORITY 0

should be added to darwin.h.


-- 

danglin at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||danglin at gcc dot gnu dot
   ||org


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

[Bug middle-end/39210] g++ 4.3 takes hours to compile greycstoration

[kurt at garloff dot de]

--- Comment #3 from kurt at garloff dot de  2009-02-16 23:37 ---
garl...@core2:/usr/src/image/GREYCstoration-2.9-src/src [130]$ g++ -o
greycstoration  greycstoration.cpp -Wall -W -ansi -pedantic -lm -lpthread -O3
-fno-math-errno -ftree-vectorize -momit-leaf-frame-pointer -funroll-loops
-march=native -mtune=native -O3 -fno-math-errno -ftree-vectorize
-momit-leaf-frame-pointer -funroll-loops -march=native -mtune=native
-I/usr/X11R6/include -L/usr/X11R6/lib -lX11 -Dcimg_use_xshm -lXext
-Dcimg_use_xrandr -lXrandr -Dcimg_use_tiff -ltiff -Dcimg_use_png -lpng -lz
-Dcimg_use_jpeg -ljpeg -I. -v
Using built-in specs.
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.3
--enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/
--with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap
--with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --program-suffix=-4.3
--enable-linux-futex --without-system-libunwind --with-cpu=generic
--build=x86_64-suse-linux
Thread model: posix
gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux) 
COLLECT_GCC_OPTIONS='-o' 'greycstoration' '-Wall' '-W' '-ansi' '-pedantic'
'-O3'   '-O3' '-fno-math-errno' '-ftree-vectorize' '-momit-leaf-frame-pointer'
'-funroll-loops'   '-I/usr/X11R6/include' '-L/usr/X11R6/lib' '-Dcimg_use_xshm'
'-Dcimg_use_xrandr' '-Dcimg_use_tiff' '-Dcimg_use_png' '-Dcimg_use_jpeg' '-I.'
'-v' '-shared-libgcc'
 /usr/lib64/gcc/x86_64-suse-linux/4.3/cc1plus -quiet -v -I/usr/X11R6/include
-I. -D_GNU_SOURCE -Dcimg_use_xshm -Dcimg_use_xrandr -Dcimg_use_tiff
-Dcimg_use_png -Dcimg_use_jpeg greycstoration.cpp -march=core2 -mcx16 -msahf
--param l1-cache-size=32 --param l1-cache-line-size=64 -mtune=core2 -quiet
-dumpbase greycstoration.cpp -momit-leaf-frame-pointer -ansi -auxbase
greycstoration -O3 -O3 -Wall -W -pedantic -ansi -version -fno-math-errno
-ftree-vectorize -funroll-loops -o /tmp/cc1M80Tb.s
ignoring nonexistent directory "/usr/X11R6/include"
#include "..." search starts here:
#include <...> search starts here:
 .
 /usr/include/c++/4.3
 /usr/include/c++/4.3/x86_64-suse-linux
 /usr/include/c++/4.3/backward
 /usr/local/include
 /usr/lib64/gcc/x86_64-suse-linux/4.3/include
 /usr/lib64/gcc/x86_64-suse-linux/4.3/include-fixed
 /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/include
 /usr/include
End of search list.
GNU C++ (SUSE Linux) version 4.3.2 [gcc-4_3-branch revision 141291]
(x86_64-suse-linux)
compiled by GNU C version 4.3.2 [gcc-4_3-branch revision 141291], GMP
version 4.2.3, MPFR version 2.3.2.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 1154f1a0780ba72bfdd3c84ed8291208
In file included from greycstoration.cpp:70:
../CImg.h: In member function ‘cimg_library::CImgDisplay&
cimg_library::CImgDisplay::assign()’:
../CImg.h:7446: warning: suggest parentheses around assignment used as truth
value
../CImg.h: In member function ‘cimg_library::CImgList&
cimg_library::CImgList::load_ffmpeg(const char*, unsigned int, unsigned int,
unsigned int, bool, bool) [with T = float]’:
../CImg.h:27199:   instantiated from ‘static cimg_library::CImg
cimg_library::CImg::get_load_ffmpeg(const char*, unsigned int, unsigned int,
unsigned int, bool, bool, char, char) [with T = float]’
../CImg.h:27206:   instantiated from ‘cimg_library::CImg&
cimg_library::CImg::load_ffmpeg(const char*, unsigned int, unsigned int,
unsigned int, bool, bool, char, char) [with T = float]’
../CImg.h:25270:   instantiated from ‘cimg_library::CImg&
cimg_library::CImg::load(const char*) [with T = float]’
greycstoration.cpp:193:   instantiated from ‘void greycstoration(int,
char**, T) [with T = float]’
greycstoration.cpp:552:   instantiated from here
../CImg.h:30701: warning: suggest parentheses around && within ||
../CImg.h: In member function ‘cimg_library::CImgList&
cimg_library::CImgList::load_ffmpeg(const char*, unsigned int, unsigned int,
unsigned int, bool, bool) [with T = unsigned char]’:
../CImg.h:27199:   instantiated from ‘static cimg_library::CImg
cimg_library::CImg::get_load_ffmpeg(const char*, unsigned int, unsigned int,
unsigned int, bool, bool, char, char) [with T = unsigned char]’
../CImg.h:27206:   instantiated from ‘cimg_library::CImg&
cimg_library::CImg::load_ffmpeg(const char*, unsigned int, unsigned int,
unsigned int, bool, bool, char, char) [with T = unsigned char]’
../CImg.h:25270:   instantiated from ‘cimg_library::CImg&
cimg_library::CImg::load(const char*) [with T = unsigned char]’
greycstoration.cpp:240:   instantiated from ‘void greycstoration(int,
char**, T) [with T = float]’
greycstoration.cpp:552:   instantiated from here
../CImg.h

[Bug middle-end/39210] g++ 4.3 takes hours to compile greycstoration

[kurt at garloff dot de]

--- Comment #2 from kurt at garloff dot de  2009-02-16 23:34 ---
Created an attachment (id=17308)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17308&action=view)
greycstoration.ii.bz2

Preprocessed file, as desired. (bzip2ed, as it's too large otherwise.)


-- 


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

[Bug middle-end/39210] g++ 4.3 takes hours to compile greycstoration

[steven at gcc dot gnu dot org]

--- Comment #1 from steven at gcc dot gnu dot org  2009-02-16 23:13 ---
Hours is excessive alright.

Unfortunately, there are a couple of things missing to reproduce your problem. 
There has to be at least a test case (preprocessed source), and the output of
gcc when you compile the test case with the extra option "-v" (verbose).

On http://gcc.gnu.org/bugs.html you can find instructions about what inputs are
needed by GCC developers to reproduce your problem, and what you need to do to
provide that input.


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug c/35446] [4.2/4.3/4.4 regression] ICE with invalid array initializer

[jsm28 at gcc dot gnu dot org]

--- Comment #3 from jsm28 at gcc dot gnu dot org  2009-02-16 22:56 ---
Subject: Bug 35446

Author: jsm28
Date: Mon Feb 16 22:55:56 2009
New Revision: 144216

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144216
Log:
PR c/35446
* c-parser.c (c_parser_braced_init): Call pop_init_level when
skipping until next close brace.

testsuite:
* gcc.dg/noncompile/init-5.c: New test.
* gcc.dg/init-bad-4.c: Adjust expected errors.

Added:
trunk/gcc/testsuite/gcc.dg/noncompile/init-5.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-parser.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/init-bad-4.c


-- 


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

[Bug middle-end/39210] New: g++ 4.3 takes hours to compile greycstoration

[kurt at garloff dot de]

http://cimg.sourceforge.net/greycstoration/

g++ -I.. -I./plugins -o greycstoration4gimp greycstoration4gimp.cpp
`gimptool-2.0 --cflags` `gimptool-2.0 --libs` -lpthread -O3 -fno-math-errno
-ftree-vectorize -momit-leaf-frame-pointer -funroll-loops -march=native
-mtune=native
takes several hours CPU time on my 2.4GHz Core2.

Using -O0 gets it down to 3s, just using -O2 still results in a number of
hours.

This seems excessive to me.


-- 
   Summary: g++ 4.3 takes hours to compile greycstoration
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kurt at garloff dot de


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

[Bug target/37049] Unaligned move used on aligned destination of push insn

[hjl dot tools at gmail dot com]

--- Comment #5 from hjl dot tools at gmail dot com  2009-02-16 22:49 ---
Fixed.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug c++/39209] New: Code generated for calling pointer-to-member segfaults when address of p-t-m is not 16-bit aligned

[james at jamesmolloy dot co dot uk]

(Please note that in all the following code no standard libaries are linked -
this is for a bare-metal kernel project.)

The following code (full header/assembly attached below):

Iterator &operator ++ ()
{
  m_Node = (m_Node->*FunctionNext)();
  return *this;
}

When instantiated as:

template
struct _ListNode_t
{
  /** Get the next data structure in the list
   *\return pointer to the next data structure in the list */
  _ListNode_t *next()
{return m_Next;}
  /** Get the previous data structure in the list
   *\return pointer to the previous data structure in the list */
  _ListNode_t *previous()
{return m_Previous;}

  /** Pointer to the next node */
  _ListNode_t *m_Next;
  /** Pointer to the previous node */
  _ListNode_t *m_Previous;
  /** The value of the node */
  T value;
};

** List template specialisation for void*
 *\brief List template specialisation for void* */
template<>
class List
{
  /** The data structure of the list's nodes */
  typedef _ListNode_t node_t;
  public:
/** Type of the bidirectional iterator */
typedef ::Iterator Iterator;
  ...

Produces the following (dis)assembly:


<_ZN8IteratorIPv11_ListNode_tIS0_EXadL_ZNS2_8previousEvEEXadL_ZNS2_4nextEvEES0_EppEv>:
   0:   55  push   %ebp
   1:   89 e5   mov%esp,%ebp
   3:   83 ec 08sub$0x8,%esp
   6:   b8 00 00 00 00  mov$0x0,%eax
7: R_386_32 _ZN11_ListNode_tIPvE4nextEv
   b:   83 e0 01and$0x1,%eax
   e:   84 c0   test   %al,%al
  10:   74 16   je 28
<_ZN8IteratorIPv11_ListNode_tIS0_EXadL_ZNS2_8previousEvEEXadL_ZNS2_4nextEvEES0_EppEv+0x28>
  12:   8b 45 08mov0x8(%ebp),%eax
  15:   8b 00   mov(%eax),%eax
  17:   8b 10   mov(%eax),%edx
  19:   b8 ff ff ff ff  mov$0x,%eax
1a: R_386_32_ZN11_ListNode_tIPvE4nextEv
  1e:   8d 04 02lea(%edx,%eax,1),%eax
  21:   8b 00   mov(%eax),%eax
  23:   89 45 fcmov%eax,-0x4(%ebp)
  26:   eb 07   jmp2f
<_ZN8IteratorIPv11_ListNode_tIS0_EXadL_ZNS2_8previousEvEEXadL_ZNS2_4nextEvEES0_EppEv+0x2f>
  28:   c7 45 fc 00 00 00 00movl   $0x0,-0x4(%ebp)
2b: R_386_32_ZN11_ListNode_tIPvE4nextEv
  2f:   8b 45 08mov0x8(%ebp),%eax
  32:   8b 00   mov(%eax),%eax
  34:   83 ec 0csub$0xc,%esp
  37:   50  push   %eax
  38:   ff 55 fccall   *-0x4(%ebp)
  3b:   83 c4 10add$0x10,%esp
  3e:   89 c2   mov%eax,%edx
  40:   8b 45 08mov0x8(%ebp),%eax
  43:   89 10   mov%edx,(%eax)
  45:   8b 45 08mov0x8(%ebp),%eax
  48:   c9  leave
  49:   c3  ret

Notice that the AND instruction tests the least significant bit of the address
of ListNode::next(). The code path changes depending on this - if it is zero,
that is the address is 16-bit aligned, the second code path is taken which
works fine.

If the address is not 16-bit aligned, the first path is taken, and it is on
taking that path that a segfault (well, actually page fault for me as I'm on
bare metal) occurs, on the dereference in the MOV after the LEA.

At the point of the LEA, %eax contains the address of ListNode::next(), and
%edx contains what appears to be a valid address on my kernel heap. This is
seemingly being used as an offset, but with bad consequences. The code fails
here.

I can only get the code to fail when ListNode::next() is not 16-bit aligned.
This code worked perfectly in GCC 4.3.0, and in that version of the compiler
the AND/JE pair was not generated - the only code path is the second one.

Is this deliberate? Is it a regression?

Thanks,

James Molloy

--



/*
 * Copyright (c) 2008 James Molloy, Jörg Pfähler, Matthew Iselin
 *
 * Permission to use, copy, modify, and distribute this software for any
 * purpose with or without fee is hereby granted, provided that the above
 * copyright notice and this permission notice appear in all copies.
 *
 * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
 * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
 * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
 * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
 * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
 * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
 * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
 */

#ifndef KERNEL_UTILITIES_ITERATOR_H
#define KERNEL_UTILITIES_ITERATOR_H

#include 

/** @addtogroup kernelutilities
 * @{ 

[Bug c++/39208] Incorrect mangled name for function as template argument

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2009-02-16 22:41 ---
to close as dup of PR16240.

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


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/16240] [3.4/3.5 ABI Regression] g++ generates incorrect mangled name

[jakub at gcc dot gnu dot org]

--- Comment #20 from jakub at gcc dot gnu dot org  2009-02-16 22:41 ---
*** Bug 39208 has been marked as a duplicate of this bug. ***


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dgregor at gcc dot gnu dot
   ||org


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

[Bug c++/39208] Incorrect mangled name for function as template argument

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2009-02-16 22:40 ---
Reopening...


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug c++/39208] Incorrect mangled name for function as template argument

[dgregor at gcc dot gnu dot org]

--- Comment #2 from dgregor at gcc dot gnu dot org  2009-02-16 22:37 ---
You're right: it works with -fabi-version is 0. Closing as invalid.


-- 

dgregor at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c++/39208] Incorrect mangled name for function as template argument

[pinskia at gmail dot com]

--- Comment #1 from pinskia at gmail dot com  2009-02-16 22:28 ---
Subject: Re:   New: Incorrect mangled name for function as template argument

Yes this known I forgot the bug number but try with -fabi-version=0.

Sent from my iPhone

On Feb 16, 2009, at 2:07 PM, "dgregor at gcc dot gnu dot org"
 wrote:

> Given the following code:
>
>  template struct X { };
>  int f(int, int) { }
>  void g(X) { }
>
> GCC produces the mangled name:
>
>  _Z1g1XILZ1fiiEE
>
> for the function 'g'. However, the correct mangled name is:
>
>  _Z1g1XIL_Z1fiiEE
>
> GCC is missing the '_' prior to the 'Z' in the mangled name of the  
> template
> argument 'f'.
>
>
> -- 
>   Summary: Incorrect mangled name for function as template  
> argument
>   Product: gcc
>   Version: 4.3.3
>Status: UNCONFIRMED
>  Severity: normal
>  Priority: P3
> Component: c++
>AssignedTo: unassigned at gcc dot gnu dot org
>ReportedBy: dgregor at gcc dot gnu dot org
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39208
>


-- 


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

Re: [Bug c++/39208] New: Incorrect mangled name for function as template argument

[Andrew Thomas Pinski]

Yes this known I forgot the bug number but try with -fabi-version=0.

Sent from my iPhone

On Feb 16, 2009, at 2:07 PM, "dgregor at gcc dot gnu dot org" > wrote:



Given the following code:

 template struct X { };
 int f(int, int) { }
 void g(X) { }

GCC produces the mangled name:

 _Z1g1XILZ1fiiEE

for the function 'g'. However, the correct mangled name is:

 _Z1g1XIL_Z1fiiEE

GCC is missing the '_' prior to the 'Z' in the mangled name of the  
template

argument 'f'.


--
  Summary: Incorrect mangled name for function as template  
argument

  Product: gcc
  Version: 4.3.3
   Status: UNCONFIRMED
 Severity: normal
 Priority: P3
Component: c++
   AssignedTo: unassigned at gcc dot gnu dot org
   ReportedBy: dgregor at gcc dot gnu dot org


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

[Bug c++/39208] New: Incorrect mangled name for function as template argument

[dgregor at gcc dot gnu dot org]

Given the following code:

  template struct X { };
  int f(int, int) { }
  void g(X) { }

GCC produces the mangled name:

  _Z1g1XILZ1fiiEE

for the function 'g'. However, the correct mangled name is:

  _Z1g1XIL_Z1fiiEE

GCC is missing the '_' prior to the 'Z' in the mangled name of the template
argument 'f'.


-- 
   Summary: Incorrect mangled name for function as template argument
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dgregor at gcc dot gnu dot org


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

[Bug tree-optimization/39207] [4.4 Regression] Strict aliasing warnings in libstdc++ headers

[paolo dot carlini at oracle dot com]

--- Comment #3 from paolo dot carlini at oracle dot com  2009-02-16 21:53 
---
We have been through this already and I'm really surprised the spurious
warnings are still there. See middle-end/38477 and middle-end/38937.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org


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

[Bug tree-optimization/39207] [4.4 Regression] Strict aliasing warnings in libstdc++ headers

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2009-02-16 21:05 ---
I believe all 3 are the same issue.
static const_reference _S_value (_Const_Base_ptr __x)
{
  return static_cast < _Const_Link_type > (__x)->_M_value_field;
}

casts pointer to _Rb_tree_node_base to pointer to pointer to _Rb_tree_node
<_Val> and then dereferences it.
Given that:
template < typename _Val > struct _Rb_tree_node:public _Rb_tree_node_base
{ ... };
at least the initial portion of the structs is the same.
_S_value is called by _S_key with the same argument, which is called from
_M_lower_bound template (_Link_Type aka. _Rb_tree_node_base isn't const in that
pointer anymore).


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||bkoz at gcc dot gnu dot org


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

[Bug target/37049] Unaligned move used on aligned destination of push insn

[hjl at gcc dot gnu dot org]

--- Comment #4 from hjl at gcc dot gnu dot org  2009-02-16 20:38 ---
Subject: Bug 37049

Author: hjl
Date: Mon Feb 16 20:37:49 2009
New Revision: 144209

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

2009-02-16  H.J. Lu  

PR target/37049
* config/i386/i386.c (ix86_expand_push): Set memory alignment
to function argument boundary.

gcc/testsuite/

2009-02-16  H.J. Lu  

PR target/37049
* gcc.target/i386/push-1.c: New.

Added:
trunk/gcc/testsuite/gcc.target/i386/push-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug target/37049] Unaligned move used on aligned destination of push insn

[ubizjak at gmail dot com]

--- Comment #3 from ubizjak at gmail dot com  2009-02-16 20:20 ---
(In reply to comment #1)
> A patch is posted at
> 
> http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00204.html

Although not a regression I think this patch is safe for mainline.

BTW: _If_ it happens that we segfault using movaps, this would mean we
uncovered bigger problems with alignment elsewhere.

BTW2: I wonder why this patch slipped through the cracks...


-- 


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

[Bug tree-optimization/39204] [4.4 Regression] ICE in compute_attic

[hjl dot tools at gmail dot com]

--- Comment #5 from hjl dot tools at gmail dot com  2009-02-16 19:33 ---
Do we get overflow with 32-bit HWI in this testcase?


-- 


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

[Bug tree-optimization/39207] [4.4 Regression] Strict aliasing warnings in libstdc++ headers

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.4.0


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

[Bug tree-optimization/39207] [4.4 Regression] Strict aliasing warnings in libstdc++ headers

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2009-02-16 19:30 ---
Created an attachment (id=17307)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17307&action=view)
ai.C

LC_ALL=C ./cc1plus -O2 -Wall -quiet /tmp/ai.C
/tmp/ai.C: In function 'void foo()':
/tmp/ai.C:2615: warning: dereferencing pointer '__x.15' does break
strict-aliasing rules
/tmp/ai.C:2479: note: initialized from here
/tmp/ai.C:2653: warning: dereferencing pointer '' does break
strict-aliasing rules
/tmp/ai.C:2342: note: initialized from here
/tmp/ai.C:2615: warning: dereferencing pointer '' does break
strict-aliasing rules
/tmp/ai.C:2281: note: initialized from here

Not sure if these are bugs in the aliasing code or libstdc++ headers.


-- 


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

[Bug tree-optimization/39207] New: [4.4 Regression] Strict aliasing warnings in libstdc++ headers

[jakub at gcc dot gnu dot org]

#include 
#include 

const std::string &usage ();

void
foo ()
{ 
  std::map < std::string, int >best_scores;
  const std::map < std::string, int >::const_iterator current_best =
best_scores.find (usage ());
  if (0 < current_best->second) best_scores[usage ()] = 0;
}

yields:
LC_ALL=C g++ -S -O2 -Wall ai.C
ai.C: In function 'void foo()':
ai.C:11: warning: dereferencing pointer '' does break
strict-aliasing rules
/usr/lib/gcc/i386-redhat-linux/4.4.0/../../../../include/c++/4.4.0/bits/stl_tree.h:259:
note: initialized from here

I'll attach another testcase which doesn't include any headers and triggers 3
warnings.


-- 
   Summary: [4.4 Regression] Strict aliasing warnings in libstdc++
headers
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
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=39207

[Bug tree-optimization/39204] [4.4 Regression] ICE in compute_attic

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2009-02-16 19:12 ---
This testcase is so sensitive to any uid changes (just removing unused u_long
typedef makes the bug go away), so I think doing a binary search is useless
here.


-- 


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

[Bug target/37049] Unaligned move used on aligned destination of push insn

[hjl dot tools at gmail dot com]

-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

   Target Milestone|--- |4.4.0
Version|unknown |4.4.0


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

[Bug target/37049] Unaligned move used on aligned destination of push insn

[hjl at gcc dot gnu dot org]

--- Comment #2 from hjl at gcc dot gnu dot org  2009-02-16 19:00 ---
Subject: Bug 37049

Author: hjl
Date: Mon Feb 16 19:00:39 2009
New Revision: 144207

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144207
Log:
Mention PR target/37049 in ChangeLog entries.

Modified:
branches/stack/gcc/ChangeLog.stackalign
branches/stack/gcc/testsuite/ChangeLog.stackalign


-- 


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

[Bug tree-optimization/39204] [4.4 Regression] ICE in compute_attic

[hjl dot tools at gmail dot com]

--- Comment #3 from hjl dot tools at gmail dot com  2009-02-16 18:57 ---
This is caused by revision 142617:

http://gcc.gnu.org/ml/gcc-cvs/2008-12/msg00315.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-02-16 18:57:12
   date||


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

[Bug c/35446] [4.2/4.3/4.4 regression] ICE with invalid array initializer

[jsm28 at gcc dot gnu dot org]

--- Comment #2 from jsm28 at gcc dot gnu dot org  2009-02-16 18:11 ---
Testing a patch.


-- 

jsm28 at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jsm28 at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-03-15 19:02:02 |2009-02-16 18:11:25
   date||


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

[Bug c++/39206] New: gcc fails to create precompiled header-file

[jd at ts dot ray dot fi]

(cross)gcc fails to create precompiled header-file, because for some
reason (v.pch_init != &pch_init)

first time this failure occures when libstdc++/configure
tests whether to generate pch/gch-files or not.
Error message is:
  conftest.cc:1:22: error: conftest.h.gch: had text segment at different
address


---

Using built-in specs.
Target: i686-unknown-linux-gnu
Configured with:
/tmp/makedir/gcc-crosstoolng-1.2.4/targets/src/gcc-4.2.4/configure
--build=x86_64-pc-linux-gnu --target=i686-unknown-linux-gnu
--host=x86_64-pc-linux-gnu
--prefix=/apkgs/crossgcc/42/i686-unknown-linux-gnu/gcc424-b218-c261-k2626
--with-sysroot=/apkgs/crossgcc/42/i686-unknown-linux-gnu/gcc424-b218-c261-k2626/i686-unknown-linux-gnu/sys-root
--enable-languages=c,c++ --disable-multilib --with-arch=i686 --with-cpu=i686
--with-tune=i686 --enable-__cxa_atexit
--with-local-prefix=/apkgs/crossgcc/42/i686-unknown-linux-gnu/gcc424-b218-c261-k2626/i686-unknown-linux-gnu/sys-root
--disable-nls --enable-threads=posix --enable-symvers=gnu --enable-c99
--enable-long-long --enable-target-optspace
Thread model: posix
gcc version 4.2.4

-
OS: Gentoo Base System release 1.12.9 (2006.1) with kernel 2.6.27.1

   another machine with same gentoo, but different kernel 2.6.22 works ok.


-- 
   Summary:  gcc fails to create precompiled header-file
   Product: gcc
   Version: 4.2.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jd at ts dot ray dot fi
 GCC build triplet: x86_64-pc-linux-gnu
  GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: i686-unknown-linux-gnu


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

[Bug c++/39205] New: Warning when object syntax is used to call a static member function

[pgrealis at yahoo-inc dot com]

I can't think of a scenario where one would want to write x.f() over X::f()
when f() is static.  I'd like a warning for this so I can catch with -Werror.

% g++ --version
g++ (GCC) 3.4.5 20051201 (Red Hat 3.4.5-2)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

% uname -a
Linux norway.corp.ukl.yahoo.com 2.6.9-34.ELsmp #1 SMP Fri Feb 24 16:56:28 EST
2006 x86_64 x86_64 x86_64 GNU/Linux


cat t1.cpp
struct X
{
void foo() {}
static void bar() {}
};

int main()
{
  X x;
  x.foo();
  X::bar();
  x.bar(); // *** I'd like a warning for this ***
}

g++ t1.cpp


-- 
   Summary: Warning when object syntax is used to call a static
member function
   Product: gcc
   Version: 3.4.5
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pgrealis at yahoo-inc dot com


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

[Bug libstdc++/21321] [4.2/4.3/4.4 regression] mmix-knuth-mmixware 27_io/basic_filebuf/seekpos/12790-3.cc execution test

[hp at gcc dot gnu dot org]

--- Comment #10 from hp at gcc dot gnu dot org  2009-02-16 17:03 ---
(In reply to comment #9)
> The assertion at that revision as showed by libstdc++.log

Same at r144193; same log messages.
Result report at .


-- 


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

[Bug tree-optimization/39202] [4.4 Regression] internal compiler error: in collapse_rest_of_var, at tree-ssa-structalias.c:3296

[hjl dot tools at gmail dot com]

--- Comment #2 from hjl dot tools at gmail dot com  2009-02-16 16:49 ---
This is caused by revision 137530:

http://gcc.gnu.org/ml/gcc-cvs/2008-07/msg00237.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||rguenther at suse dot de


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

[Bug tree-optimization/39204] [4.4 Regression] ICE in compute_attic

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.4.0


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

[Bug tree-optimization/39204] [4.4 Regression] ICE in compute_attic

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2009-02-16 16:40 ---
./cc1 -O2 -m32 rh485708.i triggers this in 32-bit HWI build (but both in stage1
built by 4.3.x and later stages), in x86_64 gcc it isn't reproduceable with -O2
-m32.


-- 


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

[Bug tree-optimization/39204] [4.4 Regression] ICE in compute_attic

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2009-02-16 16:38 ---
Created an attachment (id=17306)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17306&action=view)
rh485708.i


-- 


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

[Bug tree-optimization/39204] New: [4.4 Regression] ICE in compute_attic

[jakub at gcc dot gnu dot org]

The testcase I'm going to attach ICEs in compute_attic, with checking enabled
num_iterations reaches 500, without checking enabled it is OOM killed after it
eats lots of memory.  The .i file is from delta, so ignore the warnings, they
weren't in the original source.


-- 
   Summary: [4.4 Regression] ICE in compute_attic
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
GCC target triplet: i386-linux


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

[Bug tree-optimization/39202] [4.4 Regression] internal compiler error: in collapse_rest_of_var, at tree-ssa-structalias.c:3296

[hjl dot tools at gmail dot com]

-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-02-16 15:49:32
   date||
Summary|internal compiler error: in |[4.4 Regression] internal
   |collapse_rest_of_var, at|compiler error: in
   |tree-ssa-structalias.c:3296 |collapse_rest_of_var, at
   ||tree-ssa-structalias.c:3296
   Target Milestone|--- |4.4.0


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

[Bug tree-optimization/39202] internal compiler error: in collapse_rest_of_var, at tree-ssa-structalias.c:3296

[dominiq at lps dot ens dot fr]

--- Comment #1 from dominiq at lps dot ens dot fr  2009-02-16 15:39 ---
Confirmed on i686-apple-darwin9 with '-m64 -O2', works with '-m32 -O2' or '-m64
-O1'. This is a regression as the code compiles with 4.2.3 or 4.3.3 and '-m64
-O2'.


-- 


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

[Bug tree-optimization/39203] New: LTO and -fwhole-program do not play along well

[rguenth at gcc dot gnu dot org]

There needs to be a convenient way to specify that at link time the whole
program
is seen, or rather, that -fwhole-program -flto during compile-time doesn't have
-fwhole-program effects.

Building SPEC int 2000 with -flto -fwhole-program otherwise (obviously) results
in undefined symbols, like forOutput from make 'specmake -j2 build 2> make.err
| tee make.out':
/gcc/spec/sb-haydn-df-64/x86_64/install-200902142206/bin/gcc -c -o bzip2.o 
-O3 -ffast-math -flto -fwhole-program  bzip2.c
/gcc/spec/sb-haydn-df-64/x86_64/install-200902142206/bin/gcc -c -o spec.o  
   -O3 -ffast-math -flto -fwhole-program  spec.c
/gcc/spec/sb-haydn-df-64/x86_64/install-200902142206/bin/gcc   -O3
-ffast-math -flto -fwhole-program  bzip2.o spec.o -o bzip2
Error from make 'specmake -j2 build 2> make.err | tee make.out':
spec.o: In function `main':
spec.c:(.text+0x207): undefined reference to `smallMode'
spec.c:(.text+0x20e): undefined reference to `verbosity'
spec.c:(.text+0x218): undefined reference to `blockSize100k'
spec.c:(.text+0x222): undefined reference to `bsStream'
spec.c:(.text+0x22c): undefined reference to `workFactor'
spec.c:(.text+0x235): undefined reference to `allocateCompressStructures'
spec.c:(.text+0x252): undefined reference to `blockSize100k'
spec.c:(.text+0x257): undefined reference to `compressStream'
spec.c:(.text+0x2b3): undefined reference to `blockSize100k'
spec.c:(.text+0x2bc): undefined reference to `uncompressStream'
collect2: ld returned 1 exit status
specmake: *** [bzip2] Error 1
 bzip2:


-- 
   Summary: LTO and -fwhole-program do not play along well
   Product: gcc
   Version: lto
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org


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

[Bug tree-optimization/39202] New: internal compiler error: in collapse_rest_of_var, at tree-ssa-structalias.c:3296

[holger dot hopp at sap dot com]

testcase produces
internal compiler error: in collapse_rest_of_var, at
tree-ssa-structalias.c:3296

Version: trunk rev. 144201.
Reproduce: gcc-4.4 -O2 -c tst.c


typedef struct
{
  union
  {
int * aaa;
  } u;
} t_a;

typedef struct
{
  unsigned bbb : 1;
} t_b;

typedef struct
{
  int ccc;
  t_a ddd;
  t_b eee;
  int fff;
} t_c;

typedef struct t_d
{
  t_c f1;
  t_c f2;
} t_d;

void foo (void)
{
  t_d ggg;
  ggg.f1 = ggg.f2;
}


-- 
   Summary: internal compiler error: in collapse_rest_of_var, at
tree-ssa-structalias.c:3296
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: holger dot hopp at sap dot com
 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=39202

[Bug target/39186] Configury incorrect for 64-bit Targets on Solaris

[rob1weld at aol dot com]

--- Comment #11 from rob1weld at aol dot com  2009-02-16 13:12 ---
Results for 4.4.0 20090215 (experimental) [trunk revision 144190] (GCC)
testsuite on x86_64-pc-solaris2.11
http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg01526.html

Rob


-- 


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

[Bug bootstrap/39150] Configure scripts have no 64-Bit Solaris defined (only i386-solaris*).

[rob1weld at aol dot com]

--- Comment #5 from rob1weld at aol dot com  2009-02-16 13:11 ---
Results for 4.4.0 20090215 (experimental) [trunk revision 144190] (GCC)
testsuite on x86_64-pc-solaris2.11
http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg01526.html

Rob


-- 


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

[Bug target/34163] [4.3/4.4 Regression] 10% performance regression since Nov 1 on Polyhedron's "NF" on AMD64

[bonzini at gnu dot org]

--- Comment #13 from bonzini at gnu dot org  2009-02-16 10:23 ---
Predictive commoning does exactly what you want.


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

 CC||bonzini at gnu dot org


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

[Bug tree-optimization/39201] [meta-bug] ivopts metabug

[bonzini at gnu dot org]

--- Comment #3 from bonzini at gnu dot org  2009-02-16 09:56 ---
Subject: Re:  [meta-bug] ivopts metabug

> I'm adding PR 34163 in the hope that ivopts pass will someday know how to
> handle x[n] = f (x[n-1]) from "... very tight loops that calculate x[n] from
> the value x[n-1], where x[n-1] is the result of a previous step."
>
> This is especially important for unrolled loops, see PR 34163, comment #8

Isn't what you want simply load PRE?  That looks like a pass ordering
problem...


-- 


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

[Bug tree-optimization/39201] [meta-bug] ivopts metabug

[ubizjak at gmail dot com]

--- Comment #2 from ubizjak at gmail dot com  2009-02-16 09:44 ---
I'm adding PR 34163 in the hope that ivopts pass will someday know how to
handle x[n] = f (x[n-1]) from "... very tight loops that calculate x[n] from
the value x[n-1], where x[n-1] is the result of a previous step."

This is especially important for unrolled loops, see PR 34163, comment #8.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

  BugsThisDependsOn||34163


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

[Bug libgcj/19740] [meta-bug] Yarrr (compile time/runtime) issues tracker with GCJ

[bonzini at gnu dot org]

--- Comment #1 from bonzini at gnu dot org  2009-02-16 09:29 ---
No commit there for 3 years, can be closed.


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug java/22377] BC compilation fails to detect abstract instantiation

[bonzini at gnu dot org]

--- Comment #5 from bonzini at gnu dot org  2009-02-16 09:23 ---
Just came here by chance :-)

You can check "if (this.class == ...)" in the constructor.  It will slow down
constructors for subclasses though.


-- 


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

[Bug target/38824] [4.4 Regression] performance regression of sse code from 4.2/4.3

[bonzini at gnu dot org]

--- Comment #27 from bonzini at gnu dot org  2009-02-16 09:14 ---
Added bugs corresponding to the patch fallout in case distros want to backport
it (it gave quite a nice boost and probably fixed PR21676 too)


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

  BugsThisDependsOn||39152, 39196
OtherBugsDependingO||21676
  nThis||
Bug 38824 depends on bug 39152, which changed state.

Bug 39152 Summary: [4.4 regression] Revision 144098 breaks 416.gamess in SPEC 
CPU 2006
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39152

   What|Old Value   |New Value

 Status|REOPENED|RESOLVED
 Resolution||FIXED

Bug 38824 depends on bug 39196, which changed state.

Bug 39196 Summary: [4.4 Regression] ICE in copyprop_hardreg_forward_1, at 
regrename.c:1603 during libjava compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39196

   What|Old Value   |New Value

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

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

[Bug rtl-optimization/37490] [4.4 Regression] IRA causes FP code to have more spills

[bonzini at gnu dot org]

--- Comment #5 from bonzini at gnu dot org  2009-02-16 09:12 ---
This looks target-dependent, isn't it?


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

 CC||bonzini at gnu dot org


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

[Bug tree-optimization/39201] ivopts metabug

[bonzini at gnu dot org]

--- Comment #1 from bonzini at gnu dot org  2009-02-16 09:11 ---
I'm adding the regressions for now.  Anyone can feel free to add more. :-)


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

  BugsThisDependsOn||18219, 21676, 27440, 31849,
   ||32283, 36905
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-02-16 09:11:03
   date||


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

[Bug target/39085] Floating point errors on Arm9 processor

[mp2 at ladybridge dot com]

--- Comment #4 from mp2 at ladybridge dot com  2009-02-16 09:10 ---
(In reply to comment #3)
> I would generate the assembly by using a local function name rather than
> using main().
The original problem was deep in a complex program. I was trying to bring it
down to the shortest program that demonstrated the issue.

> From what I'm seeing, I don't know if it might be a typecasting issue
>did you try something like this? " (float)out = sqrt((float)in); "

Tried this and it still fails.

Also, the problem affects many mathematical functions, not just sqrt(). I first
saw it with sin().

Thanks for your help.


-- 


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

[Bug tree-optimization/39201] New: ivopts metabug

[bonzini at gnu dot org]

Metabug for ivopts issues


-- 
   Summary: ivopts metabug
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: missed-optimization, meta-bug
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org


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

[Bug tree-optimization/39200] New: ivopts slows down SciMark sparse matrix benchmark

[bonzini at gnu dot org]

Split off from PR21676, which is no longer a regression but where "-O2
-fno-ivopts" is still much faster than "-O2".

For the testcase, see that PR.


-- 
   Summary: ivopts slows down SciMark sparse matrix benchmark
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
GCC target triplet: i686-pc-linux-gnu
OtherBugsDependingO 21676
 nThis:


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

[Bug tree-optimization/21676] [4.2/4.3 Regression] Optimizer regression: SciMark sparse matrix benchmark

[bonzini at gnu dot org]

--- Comment #18 from bonzini at gnu dot org  2009-02-16 09:04 ---
For whatever reason, we're now faster than GCC 3.3.

-O2 -fno-ivopts is still faster than -O2, will open an enhancement request for
that.


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

  Known to work||4.4.0
Summary|[4.2/4.3/4.4 Regression]|[4.2/4.3 Regression]
   |Optimizer regression:   |Optimizer regression:
   |SciMark sparse matrix   |SciMark sparse matrix
   |benchmark   |benchmark


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

[Bug tree-optimization/21485] [4.2/4.3/4.4 Regression] missed load PRE, PRE makes i?86 suck

[bonzini at gnu dot org]

--- Comment #38 from bonzini at gnu dot org  2009-02-16 09:01 ---
Outlandish statement: maybe no-condexec if conversion should be moved to the
tree-level?!?  Doing this kind of hoisting at the same time as if conversion is
simpler on GIMPLE...


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

 CC||bonzini at gnu dot org


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

[Bug target/39146] Unnecessary stack alignment

[Joey dot ye at intel dot com]

--- Comment #12 from Joey dot ye at intel dot com  2009-02-16 08:49 ---
Created an attachment (id=17305)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17305&action=view)
New patch attached

Test finished. No regression with emx_avx_sim. Wait to checkin to 4.5


-- 

Joey dot ye at intel dot com changed:

   What|Removed |Added

  Attachment #17283|0   |1
is obsolete||


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

[Bug target/39199] [4.3 Regression] internal compiler error, unrecognizable insn

[ubizjak at gmail dot com]

--- Comment #3 from ubizjak at gmail dot com  2009-02-16 08:45 ---
This will be fixed by backport of [1] to 4.3 branch.

[1] http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00059.html


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


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


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

[Bug inline-asm/39058] [4.3 regression] ICE with double in inline-asm

[ubizjak at gmail dot com]

--- Comment #5 from ubizjak at gmail dot com  2009-02-16 08:45 ---
*** Bug 39199 has been marked as a duplicate of this bug. ***


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 CC||mike at ducky dot net


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

[Bug target/39199] [4.3 Regression] internal compiler error, unrecognizable insn

[ubizjak at gmail dot com]

--- Comment #2 from ubizjak at gmail dot com  2009-02-16 08:12 ---
Works OK with latest trunk:
version 4.4.0 20090216 (experimental) [trunk revision 144197]


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

  Known to work||4.4.0
Summary|[4.3/4.4 Regression]|[4.3 Regression] internal
   |internal compiler error,|compiler error,
   |unrecognizable insn |unrecognizable insn


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