[Bug middle-end/52584] Fails to constant fold vector upper/lower half BIT_FIELD_REFs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52584 --- Comment #4 from davem at gcc dot gnu.org 2012-05-19 06:19:16 UTC --- Author: davem Date: Sat May 19 06:19:10 2012 New Revision: 187675 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187675 Log: Fix VIS3 vector shift wrong code generation on sparc. Backport r185385 from mainline. 2012-03-14 Richard Guenther PR middle-end/52584 * tree-vect-generic.c (type_for_widest_vector_mode): Take element type instead of mode, use build_vector_type_for_mode instead of the langhook, build a vector of proper signedness. (expand_vector_operations_1): Adjust. Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/tree-vect-generic.c
[Bug libstdc++/53270] Error when bootstrapping gcc on hppa2.0-unknown-linux-gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53270 --- Comment #27 from Jonathan Wakely 2012-05-18 23:27:19 UTC --- Try adding _GTHREAD_USE_COND_INIT_FUNC too
[Bug c++/53415] New: problematic error message for ambiguity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53415
Bug #: 53415
Summary: problematic error message for ambiguity
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zeratul...@hotmail.com
Consider the following code:
struct string
{
string(char*);
};
template
void operator+(const string&, const T&);
template
struct S {};
template
struct T
{
enum {value = 0};
};
template
S<0 + T::value> foo(X);
int main()
{
foo(1);
}
Trunk gives the following error message:
test.cpp: In function 'int main()':
test.cpp:23:10: error: no matching function for call to 'foo(int)'
foo(1);
^
test.cpp:23:10: note: candidate is:
test.cpp:19:20: note: template S<(0 + T<
>::value)> foo(X)
S<0 + T::value> foo(X);
^
test.cpp:19:20: note: template argument deduction/substitution failed:
test.cpp: In substitution of 'template S<(0 + T<
>::value)> foo(X) [with X = int]':
test.cpp:23:10: required from here
test.cpp:19:20: warning: ISO C++ says that these are ambiguous, even though the
worst conversion for the first is better than the worst conversion for the
second: [enabled by default]
test.cpp:19:20: note: candidate 1: operator+(int, int)
test.cpp:7:6: note: candidate 2: void operator+(const string&, const T&) [with
T = T::]
void operator+(const string&, const T&);
^
I think there are several problems with this error message:
1. Template argument deduction/substitution is failing because of a *warning*?
The following reduced example:
struct string
{
string(char*);
};
template
void operator+(const string&, const T&);
struct T
{
enum {value = 0};
};
int main()
{
return 0 + T::value;
}
gives a similar warning but no errors. It is inconsistent for an ambiguity to
cause just a warning in one case, and failure of template argument
deduction/substitution in another.
2. There is no caret diagnostic associated with the "ISO C++ says that these
are ambiguous" warning, so it's difficult to tell what "these" are. (We can
infer from the candidates being operator+, but there could have been many uses
of operator+ in that expression, and only one of them ambiguous, so it would be
nice to have a caret pointing to that one).
3. GCC 4.7 compiles the original example fine. Assuming this change in
behaviour is intentional, it should be documented on the 4.8 changes page
because it breaks existing code.
[Bug c++/53403] Function template friend denied access to private types of granting template class.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53403 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2012-05-18 Ever Confirmed|0 |1 --- Comment #2 from Jonathan Wakely 2012-05-18 23:23:50 UTC --- Confirmed, this possibly got broken when Jason implemented the C++11 friend rules
[Bug c++/53412] Error recovery for class types is poor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53412 Andrew Pinski changed: What|Removed |Added Keywords||diagnostic Version|4.7.0 |4.8.0 Severity|normal |enhancement
[Bug gcov-profile/53414] New: gcov does not generate 'Lines' record for final block of functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53414
Bug #: 53414
Summary: gcov does not generate 'Lines' record for final block
of functions
Classification: Unclassified
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: gcov-profile
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: myron.wal...@gmail.com
GCC does not add a Lines record for the final line of code in functions with a
return with if statements having multiple branches. Examples
This code has a lines marking the end of the function:
01: int global_value = 0;
02:
03: void graph_simplebranch(int taken)
04: {
05: if(taken > 0)
06: {
07: global_value = global_value + 1;
08: }
09: }
This code does not get a lines record generated for the block that is the end
of the function.
01: int global_value = 0;
02:
03: void graph_multiplebranches(int pathSelect)
04: {
05: if(pathSelect == 0)
06: {
07: global_value = global_value + 1;
08: }
09: else if(pathSelect == 1)
10: {
11: global_value = global_value + 2;
12: }
13: else
14: {
15: global_value = global_value + 3;
16: }
17:
18: return;
19: }
[Bug other/53413] New: md5_process_block() produces incorrect result with large block sizes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53413 Bug #: 53413 Summary: md5_process_block() produces incorrect result with large block sizes Classification: Unclassified Product: gcc Version: 4.7.0 URL: http://sourceware.org/bugzilla/show_bug.cgi?id=14090 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: belys...@depni.sinp.msu.ru libiberty/md5.c contains [buggy] code copied from glibc, so please take a look at http://sourceware.org/bugzilla/show_bug.cgi?id=14090 for the description of the bug and proposed patch.
[Bug c++/53412] New: Error recovery for class types is poor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53412
Bug #: 53412
Summary: Error recovery for class types is poor
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pins...@gcc.gnu.org
Take:
#include
std::vector a;
void f(int*b)
{
a.pushback(b);
}
--- CUT---
On the trunk we get the following error messages:
t344.cc:3:13: error: ‘i’ was not declared in this scope
std::vector a;
^
t344.cc:3:15: error: template argument 1 is invalid
std::vector a;
^
t344.cc:3:15: error: template argument 2 is invalid
std::vector a;
^
t344.cc:3:18: error: invalid type in declaration before ‘;’ token
std::vector a;
^
t344.cc: In function ‘void f(int*)’:
t344.cc:7:3: error: request for member ‘pushback’ in ‘a’, which is of non-class
type ‘int’
a.pushback(b);
^
--- CUT ---
The last one seems just plain wrong. Why did the C++ front-end record a as
type int rather than using error_mark_node?
Also the fourth error message seems wrong too as we already have an error that
the type was invalid.
The second and third ones are not really needed for default template arguments
if we already have an error out about the non defaulted ones.
[Bug c/53411] New: segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53411
Bug #: 53411
Summary: segfault
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reg...@cs.utah.edu
CC: cheny...@cs.utah.edu
[regehr@dyson r49]$ current-gcc -v
Using built-in specs.
COLLECT_GCC=current-gcc
COLLECT_LTO_WRAPPER=/uusoc/exports/scratch/regehr/z/compiler-install/gcc-r187663-install/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --with-libelf=/usr/local --enable-lto
--prefix=/home/regehr/z/compiler-install/gcc-r187663-install
--program-prefix=r187663- --enable-languages=c,c++
Thread model: posix
gcc version 4.8.0 20120518 (experimental) (GCC)
[regehr@dyson r49]$ current-gcc -O3 small.c -c
small.c: In function 'fn4':
small.c:28:1: internal compiler error: Segmentation fault
}
^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
[regehr@dyson r49]$ cat small.c
int a, b, c, d, e, f, g, h;
void fn1 ();
int fn2 ();
int
fn3 (p1)
{
return a ? 0 : p1;
}
void
fn4 (char p1)
{
int i, j, k;
for (; e; e++)
if (fn2 ())
{
f = 1;
k = 0;
for (; k <= 1; k++)
{
j = ~p1;
i = f * j;
h = (fn3 (i | 0 <= c ^ 9L) != b | d) & 8;
g = p1 | 1;
fn1 ();
}
}
c = p1;
}
[Bug c++/53405] Enum-dependent class template instantiations not recognized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53405 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #1 from Daniel Krügler 2012-05-18 18:29:28 UTC --- gcc 4.8.0 HEAD also accepts the code
[Bug c/53410] New: ICE in build_int_cst_wide, at tree.c:1219
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53410
Bug #: 53410
Summary: ICE in build_int_cst_wide, at tree.c:1219
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reg...@cs.utah.edu
CC: cheny...@cs.utah.edu
[regehr@dyson r51]$ current-gcc -v
Using built-in specs.
COLLECT_GCC=current-gcc
COLLECT_LTO_WRAPPER=/uusoc/exports/scratch/regehr/z/compiler-install/gcc-r187663-install/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --with-libelf=/usr/local --enable-lto
--prefix=/home/regehr/z/compiler-install/gcc-r187663-install
--program-prefix=r187663- --enable-languages=c,c++
Thread model: posix
gcc version 4.8.0 20120518 (experimental) (GCC)
[regehr@dyson r51]$ current-gcc -c -O3 small.c
small.c: In function 'fn1':
small.c:4:1: internal compiler error: in build_int_cst_wide, at tree.c:1219
fn1 ()
^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
[regehr@dyson r51]$ cat small.c
int *a;
int b, c, d;
void
fn1 ()
{
for (; d <= 0; d++)
b &= ((a || d) ^ c) == 1;
}
[Bug c/53408] New: ICE in get_initial_def_for_induction, at tree-vect-loop.c:3222
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53408
Bug #: 53408
Summary: ICE in get_initial_def_for_induction, at
tree-vect-loop.c:3222
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reg...@cs.utah.edu
CC: cheny...@cs.utah.edu
[regehr@dyson r48]$ current-gcc -v
Using built-in specs.
COLLECT_GCC=current-gcc
COLLECT_LTO_WRAPPER=/uusoc/exports/scratch/regehr/z/compiler-install/gcc-r187663-install/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --with-libelf=/usr/local --enable-lto
--prefix=/home/regehr/z/compiler-install/gcc-r187663-install
--program-prefix=r187663- --enable-languages=c,c++
Thread model: posix
gcc version 4.8.0 20120518 (experimental) (GCC)
[regehr@dyson r48]$ current-gcc -c -O3 small.c
small.c: In function 'fn1':
small.c:3:1: internal compiler error: in get_initial_def_for_induction, at
tree-vect-loop.c:3222
fn1 ()
^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
[regehr@dyson r48]$ cat small.c
int a, b, c, d, e;
void
fn1 ()
{
int f, g;
char h = 0;
b = 0;
for (; b < 32; b++)
{
g = h > e ? h : h << 1;
f = g && a ? 0 : 1;
h = 1;
for (; h > 0; h = h + 1)
c = 0 < h | f;
}
if (h)
d = 0;
}
[Bug c/53409] New: ICE: vector VEC(vec_void_p,base) index domain error, in vinfo_for_stmt at tree-vectorizer.h:630
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53409
Bug #: 53409
Summary: ICE: vector VEC(vec_void_p,base) index domain error,
in vinfo_for_stmt at tree-vectorizer.h:630
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reg...@cs.utah.edu
CC: cheny...@cs.utah.edu
[regehr@dyson r50]$ current-gcc -v
Using built-in specs.
COLLECT_GCC=current-gcc
COLLECT_LTO_WRAPPER=/uusoc/exports/scratch/regehr/z/compiler-install/gcc-r187663-install/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --with-libelf=/usr/local --enable-lto
--prefix=/home/regehr/z/compiler-install/gcc-r187663-install
--program-prefix=r187663- --enable-languages=c,c++
Thread model: posix
gcc version 4.8.0 20120518 (experimental) (GCC)
[regehr@dyson r50]$ current-gcc -Wall -O3 small.c
small.c: In function 'main':
small.c:4:1: internal compiler error: vector VEC(vec_void_p,base) index domain
error, in vinfo_for_stmt at tree-vectorizer.h:630
main ()
^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
[regehr@dyson r50]$ cat small.c
int a, c, d, e, f;
int b[0];
int
main ()
{
if (f)
e = 0;
int g = d;
c = 0;
for (; c <= 1; c++)
{
a = 0;
for (; a <= 1; a = (char) a + 1)
b[c] = g;
a = 0;
}
return 0;
}
[Bug tree-optimization/53346] [4.6/4.7/4.8 Regression] Bad vectorization in the proc cptrf2 of rnflow.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53346 --- Comment #18 from Dominique d'Humieres 2012-05-18 18:29:06 UTC --- > Are conditional moves that bad on x86? The change which uses them more for > COND_EXPR was mine but really I think this was a latent bug or a way to say > chose conditional move over jumps for some targets. As said in comment #0 the first regression appeared between revisions 162456 (2010-07-23) and 164728 (2010-09-29), so the problem is fairly old [macbook] test/dbg_rnflow% /opt/gcc/gcc4.6p-162456/bin/gfortran -c -O3 cptrf2.f90 [macbook] test/dbg_rnflow% makeo ; time a.out > /dev/null 20.904u 0.345s 0:21.26 99.9%0+0k 0+0io 0pf+0w [macbook] test/dbg_rnflow% /opt/gcc/gcc4.6p-162456/bin/gfortran -c -O3 -fno-tree-loop-if-convert cptrf2.f90 [macbook] test/dbg_rnflow% makeo ; time a.out > /dev/null 20.898u 0.341s 0:21.24 99.9%0+0k 0+0io 0pf+0w [macbook] test/dbg_rnflow% /opt/gcc/gcc4.6p-164728/bin/gfortran -c -O3 cptrf2.f90 [macbook] test/dbg_rnflow% makeo ; time a.out > /dev/null 28.607u 0.346s 0:28.96 99.9%0+0k 0+0io 0pf+0w [macbook] test/dbg_rnflow% /opt/gcc/gcc4.6p-164728/bin/gfortran -c -O3 -fno-tree-loop-if-convert cptrf2.f90 [macbook] test/dbg_rnflow% makeo ; time a.out > /dev/null 21.153u 0.342s 0:21.50 99.9%0+0k 0+0io 0pf+0w
[Bug c++/53403] Function template friend denied access to private types of granting template class.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53403 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #1 from Daniel Krügler 2012-05-18 18:27:16 UTC --- The problem also exists for gcc 4.8.0 20120513 (experimental) with or without activating C++11 support. Further, if the reference to the type in template f is a dependent form, like typedef typename Foo::type type; the error does not occur. This looks like a compiler-defect to me.
[Bug tree-optimization/53346] [4.6/4.7/4.8 Regression] Bad vectorization in the proc cptrf2 of rnflow.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53346 --- Comment #17 from H.J. Lu 2012-05-18 18:27:21 UTC --- I was told that cmov wins if branch is mispredicted, otherwise cmov loses. We will investigate if we can improve cmov in GCC.
[Bug c/53391] Slightly misleading warning on printf format mismatch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53391
--- Comment #2 from Keith Thompson
2012-05-18 18:26:31 UTC ---
The cleverness I was referring to was having diagnostics refer to an
appropriate typedef rather than to the original type (e.g., "size_t" rather
than "unsigned int"). I find this clever in a *good* way.
The conversion is a no-op if my_long happens to be the same type as long, as it
is in this example -- but it's very useful from the programmer's point of view
if my_long (or something with a more meaningful name) *could* be either long or
int.
I suppose solving this would require saving some information about the cast so
that the name of the type of the expression ("my_long" rather than "long") can
be referred to in diagnostic messages.
I should note that this is not production code. The original program was
intended to use "%ld" and convert the argument to long; I ran into the
misleading warning due to a logic error.
[Bug tree-optimization/53346] [4.6/4.7/4.8 Regression] Bad vectorization in the proc cptrf2 of rnflow.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53346 --- Comment #16 from Uros Bizjak 2012-05-18 18:24:43 UTC --- Perf confirms this findings, the first loop: 0.02 : 401e10: movslq %edx,%rbx 5.04 : 401e13: movss -0x4(%rdi,%rbx,4),%xmm0 24.97 : 401e19: ucomiss (%r9),%xmm0 14.66 : 401e1d: cmova %ecx,%edx 15.37 : 401e20: sub$0x1,%ecx 0.00 : 401e23: sub$0x4,%r9 0.00 : 401e27: cmp%r10d,%ecx 0.00 : 401e2a: jne401e10 the second: 0.00 : 401e60: movslq %ecx,%r10 1.69 : 401e63: movss -0x4(%rdi,%r10,4),%xmm0 7.78 : 401e6a: ucomiss (%r9),%xmm0 4.75 : 401e6e: cmova %r11d,%ecx 4.52 : 401e72: sub$0x1,%r11d 0.00 : 401e76: sub$0x4,%r9 0.05 : 401e7a: cmp%eax,%r11d 0.00 : 401e7d: jne401e60 the third: 0.00 : 401ff8: movslq %edx,%r10 0.78 : 401ffb: movss -0x4(%rdi,%r10,4),%xmm0 3.14 : 402002: ucomiss (%r9),%xmm0 2.04 : 402006: cmova %ecx,%edx 1.89 : 402009: sub$0x4,%r9 0.00 : 40200d: sub$0x1,%ecx 0.00 : 402010: jne401ff8
[Bug lto/53407] New: ICE compiling pcre-8.21 in function_and_variable_visibility, at ipa.c:1002
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53407 Bug #: 53407 Summary: ICE compiling pcre-8.21 in function_and_variable_visibility, at ipa.c:1002 Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: rainer-gccb...@7val.com g++ throws an ICE when linking pcre-8.21 with -flto, it works with -O3. Since the bug is in the linker phase, I don't have any preprocessed files I could attach. The pcre source code is available at ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/ If required, I can supply the entire source directory, including the object files used in the link line below, or any subset thereof. The GCC used is the default Version included in Ubuntu 12.04 x86_64. $ g++ -v -save-temps -fPIC -DPIC -shared -nostdlib Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i686 --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.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.6/:/usr/lib/gcc/x86_64-linux-gnu/4.6/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.6/:/usr/lib/gcc/x86_64-linux-gnu/ LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.6/:/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-save-temps' '-fPIC' '-D' 'PIC' '-shared' '-nostdlib' '-LDEST/lib' '-L/usr/lib/gcc/x86_64-linux-gnu/4.6' '-L/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu' '-L/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib' '-L/lib/x86_64-linux-gnu' '-L/lib/../lib' '-L/usr/lib/x86_64-linux-gnu' '-L/usr/lib/../lib' '-L/usr/lib/gcc/x86_64-linux-gnu/4.6/../../..' '-O3' '-mtune=core2' '-march=core2' '-flto' '-o' '.libs/libpcrecpp.so.0.0.0' '-shared-libgcc' /usr/lib/gcc/x86_64-linux-gnu/4.6/collect2 -plugin /usr/lib/gcc/x86_64-linux-gnu/4.6/liblto_plugin.so -plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/4.6/lto-wrapper -plugin-opt=-fresolution=libpcrecpp.so.res -flto --sysroot=/ --build-id --no-add-needed --as-needed --eh-frame-hdr -m elf_x86_64 --hash-style=gnu -shared -z relro -o .libs/libpcrecpp.so.0.0.0 -LDEST/lib -L/usr/lib/gcc/x86_64-linux-gnu/4.6 -L/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.6/../../.. -L/usr/lib/gcc/x86_64-linux-gnu/4.6 -L/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.6/../../.. /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/4.6/crtbeginS.o .libs/pcrecpp.o .libs/pcre_scanner.o .libs/pcre_stringpiece.o -rpath /home/build/fit3/build/src/external/pcre-8.21_/.libs -rpath /tmp/pcre/lib ./.libs/libpcre.so -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/x86_64-linux-gnu/4.6/crtendS.o /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/crtn.o -soname libpcrecpp.so.0 g++ @/tmp/ccQdRwkk.args Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --disable-werror -
[Bug gcov-profile/53406] Unit Record not present in header files or in GCOV output
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53406 Myron Walker changed: What|Removed |Added Version|4.6.1 |4.2.0 --- Comment #4 from Myron Walker 2012-05-18 18:01:42 UTC --- The GCDA and GCNO files were produced by GCC version 4.2 but the issues with the header files, like the missing tag, are present in later versions.
[Bug gcov-profile/53406] Unit Record not present in header files or in GCOV output
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53406 --- Comment #3 from Myron Walker 2012-05-18 17:54:49 UTC --- Added example GCDA and GCNO files
[Bug tree-optimization/53346] [4.6/4.7/4.8 Regression] Bad vectorization in the proc cptrf2 of rnflow.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53346 --- Comment #15 from Andrew Pinski 2012-05-18 17:54:16 UTC --- (In reply to comment #14) > Compile and execute slow assembly: > real0m18.170s > user0m17.907s > sys 0m0.223s > > WTF happened here?! Are conditional moves that bad on x86? The change which uses them more for COND_EXPR was mine but really I think this was a latent bug or a way to say chose conditional move over jumps for some targets.
[Bug gcov-profile/53406] Unit Record not present in header files or in GCOV output
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53406 --- Comment #2 from Myron Walker 2012-05-18 17:54:12 UTC --- Created attachment 27439 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27439 Sample GCNO file
[Bug gcov-profile/53406] Unit Record not present in header files or in GCOV output
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53406 --- Comment #1 from Myron Walker 2012-05-18 17:53:18 UTC --- Created attachment 27438 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27438 Sample GCDA file
[Bug gcov-profile/53406] New: Unit Record not present in header files or in GCOV output
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53406 Bug #: 53406 Summary: Unit Record not present in header files or in GCOV output Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile AssignedTo: unassig...@gcc.gnu.org ReportedBy: myron.wal...@gmail.com The GCOV file format detailed in the gcov-io.h header file describe unit record in the .gcno files like so: unit: header int32:checksum string:source and in the .gcda files like so: unit: header int32:checksum When I use the code coverage tools on Ubuntu 11.10 that uses GCC 4.6.1. The .gcno and .gcda files that are produced do not contain this record. Also when you look at the TAG definitions in the header file there isn't a tag declared for this record type. see below: /* The record tags. Values [1..3f] are for tags which may be in either file. Values [41..9f] for those in the note file and [a1..ff] for the data file. The tag value zero is used as an explicit end of file marker -- it is not required to be present. */ #define GCOV_TAG_FUNCTION ((gcov_unsigned_t)0x0100) #define GCOV_TAG_FUNCTION_LENGTH (2) #define GCOV_TAG_BLOCKS ((gcov_unsigned_t)0x0141) #define GCOV_TAG_BLOCKS_LENGTH(NUM) (NUM) #define GCOV_TAG_BLOCKS_NUM(LENGTH) (LENGTH) #define GCOV_TAG_ARCS ((gcov_unsigned_t)0x0143) #define GCOV_TAG_ARCS_LENGTH(NUM) (1 + (NUM) * 2) #define GCOV_TAG_ARCS_NUM(LENGTH) (((LENGTH) - 1) / 2) #define GCOV_TAG_LINES ((gcov_unsigned_t)0x0145) #define GCOV_TAG_COUNTER_BASE ((gcov_unsigned_t)0x01a1) #define GCOV_TAG_COUNTER_LENGTH(NUM) ((NUM) * 2) #define GCOV_TAG_COUNTER_NUM(LENGTH) ((LENGTH) / 2) #define GCOV_TAG_OBJECT_SUMMARY ((gcov_unsigned_t)0xa100) #define GCOV_TAG_PROGRAM_SUMMARY ((gcov_unsigned_t)0xa300) #define GCOV_TAG_SUMMARY_LENGTH \ (1 + GCOV_COUNTERS_SUMMABLE * (2 + 3 * 2))
[Bug tree-optimization/53395] [4.8 Regression] The LAPACK functions i(d|s)amax are more than two times slower after revision 187183
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53395 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-05-18 Ever Confirmed|0 |1 --- Comment #3 from Andrew Pinski 2012-05-18 15:32:04 UTC --- This was mentioned on http://gcc.gnu.org/ml/gcc/2011-10/msg00422.html . So there are two ways of fixing this bug. Way #1: Fix ifcvt on the tree level to produce MAX_EXPR instead of the COND_EXPR. Way #2: Simplify COND_EXPR to MAX_EXPR during expanding or some other time. I want to say way #1 is the correct fix.
[Bug tree-optimization/53346] [4.6/4.7/4.8 Regression] Bad vectorization in the proc cptrf2 of rnflow.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53346 --- Comment #13 from Uros Bizjak 2012-05-18 17:08:08 UTC --- Created attachment 27435 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27435 slow x86_64 assembly, obtained with -O2 -ftree-loop-if-convert This is the slow assembly, stay tuned for the WTF part.
[Bug c++/53402] New: [C++11] non-inline namespace can be wrongly re-opened as inline
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53402
Bug #: 53402
Summary: [C++11] non-inline namespace can be wrongly re-opened
as inline
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ai.az...@gmail.com
C++11 7.3.1/7 says,
"If the optional initial inline keyword appears in a namespace-definition for a
particular namespace, that namespace is declared to be an inline namespace. The
inline keyword may be used on an extension-namespace-definition only if it was
previously used on the original-namespace-definition for that namespace."
I understand that this paragraph prohibits "retroactive inlining" of
namespaces, like the following code;
/
namespace NS{}
inline namespace NS{}
/
However, GCC 4.8.0 20120513 (experimental) with -std=c++11, -Wall and
-Wpedantic accepts the above code without any warning.
In addition, the document that explains the implementation of libstdc++ debug
mode
http://gcc.gnu.org/onlinedocs/libstdc++/manual/bk01pt03ch17s04.html#debug_mode.design.methods.coexistence
includes an example code using retroactive inlining. It may mislead some
readers to think that this is standard-conforming. Therefore, even if the
current implementation of libstdc++ debug mode uses retroactive inlining, it's
better to avoid this style in the document.
[Bug c++/53403] New: Function template friend denied access to private types of granting template class.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53403
Bug #: 53403
Summary: Function template friend denied access to private
types of granting template class.
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ib...@qult.net
The following code compiles with GCC 4.4 but not since 4.5, until at least
4.7.0.
template
class Foo {
typedef voidtype;
template friend void f();
public:
Foo() {}
};
template class Foo;
template
void f()
{
typedef Foo::typetype;
}
int main()
{
f();
}
If the function template is declared before the definition of the class
template, or if the Foo class is instantiated after f's definition, the
code compiles. The error appears only with private types, not other private
members.
Easy to work around, but still... :/
[Bug tree-optimization/53346] [4.6/4.7/4.8 Regression] Bad vectorization in the proc cptrf2 of rnflow.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53346 Uros Bizjak changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #14 from Uros Bizjak 2012-05-18 17:17:45 UTC --- Compile and execute slow assembly: gfortran rnflow.s && time ./a.out real0m24.454s user0m24.167s sys 0m0.231s Apply following patch that changes cmove in very fast loops (cptrf2) to jumps: --cut here-- --- rnflow.s2012-05-18 19:00:22.314102061 +0200 +++ rnflow1.s 2012-05-18 19:10:59.363428625 +0200 @@ -1305,7 +1305,9 @@ movslq %edx, %rbx movss -4(%rdi,%rbx,4), %xmm0 ucomiss (%r9), %xmm0 - cmova %ecx, %edx + jbe .L183x + movl%ecx, %edx +.L183x: subl$1, %ecx subq$4, %r9 cmpl%r10d, %ecx @@ -1329,7 +1331,9 @@ movslq %ecx, %r10 movss -4(%rdi,%r10,4), %xmm0 ucomiss (%r9), %xmm0 - cmova %r11d, %ecx + jbe .L192x + movl%r11d, %ecx +.L192x: subl$1, %r11d subq$4, %r9 cmpl%eax, %r11d @@ -1485,7 +1489,9 @@ movslq %edx, %r10 movss -4(%rdi,%r10,4), %xmm0 ucomiss (%r9), %xmm0 - cmova %ecx, %edx + jbe .L179x + movl%ecx, %edx +.L179x: subq$4, %r9 subl$1, %ecx jne .L179 --cut here-- gfortran rnflow.s && time ./a.out real0m18.170s user0m17.907s sys 0m0.223s WTF happened here?! Relevant part of my /proc/cpuinfo: vendor_id : GenuineIntel cpu family : 6 model : 42 Adding CC.
[Bug tree-optimization/53395] [4.8 Regression] The LAPACK functions i(d|s)amax are more than two times slower after revision 187183
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53395 --- Comment #6 from Dominique d'Humieres 2012-05-18 17:41:21 UTC --- > This should fix tree-if-conv.c: It does. Thanks.
[Bug fortran/53389] [4.6/4.7/4.8 Regression] -frealloc-lhs: memory leak when assigning array function result to allocatable array, where one of its supplied arguments is itself an array function resul
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53389
--- Comment #3 from Tobias Burnus 2012-05-18
17:05:57 UTC ---
(In reply to comment #0)
> x=filler(filler(y, real(2*i)), real(i))
That line should call "filler" twice, however, it is called trice! There are
two "atmps" - on the second is properly freed. If one does a backtrace in
gfc_trans_create_temp_array, one sees:
#0gfc_trans_create_temp_array at trans-array.c:986
#1 0x005f009f in gfc_conv_procedure_call at trans-expr.c:4326 <<<
...
#8 0x005f0dce in gfc_conv_function_expr at trans-expr.c:4885
#9 0x005d0999 in gfc_add_loop_ss_codeat trans-array.c:2514
#10 0x005d1626 in gfc_conv_loop_setup at trans-array.c:4542
#11 0x005f671b in realloc_lhs_loop_for_fcn_call at trans-expr.c:6342
#12 gfc_trans_arrayfunc_assign at trans-expr.c:6522
<<<
#0gfc_trans_create_temp_array at trans-array.c:986
#1 0x005f009f in gfc_conv_procedure_call at trans-expr.c:4326
<<<
...
#8 0x005f0dce in gfc_conv_function_expr at trans-expr.c:4885
#9 0x005f61fd in gfc_trans_arrayfunc_assign at trans-expr.c:6532 <<<
trans-expr.c has in gfc_trans_arrayfunc_assign the following, which looks fine:
6517 {
6518realloc_lhs_warning (expr1->ts.type, true, &expr1->where);
6519
6520if (!expr2->value.function.isym)
6521 {
6522realloc_lhs_loop_for_fcn_call (&se, &expr1->where, &ss,
&loop);
6523ss->is_alloc_lhs = 1;
6524 }
6525else
6526 fcncall_realloc_result (&se, expr1->rank);
6527 }
6528
6529gfc_conv_function_expr (&se, expr2);
6530gfc_add_block_to_block (&se.pre, &se.post);
6531
6532return gfc_finish_block (&se.pre);
6533 }
However, in gfc_conv_procedure_call the "if" should evaluate true for the
second call - but it does not! Thus, another temporary array is generated and a
second call is inserted.
4312if (gfc_option.flag_realloc_lhs
4313 && se->ss && se->ss->is_alloc_lhs)
4314 {
4315gfc_free_interface_mapping (&mapping);
4316return has_alternate_specifier;
4317 }
4318
4319/* Create a temporary to store the result. In case the
function
4320 returns a pointer, the temporary will be a shallow copy
and
4321 mustn't be deallocated. */
4322callee_alloc = sym->attr.allocatable || sym->attr.pointer;
4323gfc_trans_create_temp_array (&se->pre, &se->post, se->ss,
4324 tmp, NULL_TREE, false,
4325 !sym->attr.pointer,
callee_alloc,
4326 &se->ss->info->expr->where);
[Bug target/53385] [4.8 Regression] "Error: operand out of range" after changes for LSHIFT_EXPR in vrp.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53385 William J. Schmidt changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #13 from William J. Schmidt 2012-05-18 16:06:16 UTC --- Fixed by r187657.
[Bug c/53404] New: warning column reported on comment in warning during bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53404 Bug #: 53404 Summary: warning column reported on comment in warning during bootstrap Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: andi-...@firstfloor.org Looking through the warnings on a bootstrap I see the following columns incorrectly reported by the "^" feature. gengtype-lex.c:1888:27: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] YY_INPUT( (&YY_CURRENT_BUFFER_LVALUE->yy_ch_buf[number_to_move]), ^ gengtype-lex.c:1096:20: note: in expansion of macro 'YY_INPUT' int n; \ ^ gengtype-lex.c:1887:3: note: expanded from here /* Read in more data. */ ^ Obviously the comment is not to blame
[Bug libstdc++/53270] Error when bootstrapping gcc on hppa2.0-unknown-linux-gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53270 --- Comment #24 from jimis 2012-05-18 17:16:08 UTC --- Thanks, I'll leave that to you then since it's no big priority for me. FYI defining _GTHREAD_USE_RECURSIVE_MUTEX_INIT_FUNC brought other problems. I'm attaching related info for the sake of completeness.
[Bug preprocessor/53404] warning column reported on comment in warning during bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53404 Andi Kleen changed: What|Removed |Added Component|c |preprocessor --- Comment #1 from Andi Kleen 2012-05-18 16:52:59 UTC --- Probably more a preprocessor problem
[Bug libstdc++/53270] Error when bootstrapping gcc on hppa2.0-unknown-linux-gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53270 --- Comment #26 from jimis 2012-05-18 17:17:53 UTC --- Created attachment 27437 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27437 preprocessed source
[Bug tree-optimization/53395] [4.8 Regression] The LAPACK functions i(d|s)amax are more than two times slower after revision 187183
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53395 --- Comment #4 from Andrew Pinski 2012-05-18 16:03:46 UTC --- This should fix tree-if-conv.c: Index: tree-if-conv.c === --- tree-if-conv.c(revision 187647) +++ tree-if-conv.c(working copy) @@ -1313,8 +1313,8 @@ predicate_scalar_phi (gimple phi, tree c || bb_postdominates_preds (bb)); /* Build new RHS using selected condition and arguments. */ - rhs = build3 (COND_EXPR, TREE_TYPE (res), -unshare_expr (cond), arg_0, arg_1); + rhs = fold_build3 (COND_EXPR, TREE_TYPE (res), + unshare_expr (cond), arg_0, arg_1); } new_stmt = gimple_build_assign (res, rhs);
[Bug libstdc++/53270] Error when bootstrapping gcc on hppa2.0-unknown-linux-gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53270 --- Comment #22 from Jonathan Wakely 2012-05-18 16:30:54 UTC --- The new error is in the recursive mutex definition. You also need to define _GTHREAD_USE_RECURSIVE_MUTEX_INIT_FUNC
[Bug libstdc++/53270] Error when bootstrapping gcc on hppa2.0-unknown-linux-gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53270 --- Comment #25 from jimis 2012-05-18 17:17:13 UTC --- Created attachment 27436 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27436 log
[Bug c++/53403] Function template friend denied access to private types of granting template class.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53403 Ignacy Gawedzki changed: What|Removed |Added Severity|normal |minor
[Bug target/53386] Bad assembly code produced for m68000
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53386 --- Comment #13 from Luis Alves 2012-05-18 17:00:11 UTC --- I've built gcc with the m68k/linux.h patched for the 68000 but it's not working as expected. As test I've used linux kernel 3.3 Results are compared to the use of gcc-4.2.4 vs gcc-4.6.3 (gcc-4.7.0 doesn't even build itself because of an ICE). (Using the same kernel configuration, only changed gcc version) Kernel Size: 4.2.4: 2158592 bytes 4.6.3: 2244608 bytes (around 4% increase) Using 4.2.4 kernel boots as expected and everything works fine. With 4.6.3 the kernel boots and after a few seconds starts a non-stop SPAM of BUGs: [...] BUG: scheduling while atomic: ksoftirqd/0/3/0x [...] BUG: scheduling while atomic: kthreadd/2/0x [...] BUG: scheduling while atomic: kworker/0:0/4/0x0402 [...] Until eventually panics. Anyway, building gcc for target "m68k-uclinuxoldabi" is a bit awkward. I've tried to build and the message I got is that target will be removed soon. Also it would give a lot of work to integrate it with the existing tools because of the resulting prefix (binutils, elf2flt, ...). As of "gcc -m68000" not generating correct code for the 68000 I would still say that IT IS a gcc bug...
[Bug c++/53405] New: Enum-dependent class template instantiations not recognized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53405
Bug #: 53405
Summary: Enum-dependent class template instantiations not
recognized
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ib...@qult.net
The following code compiles with GCC 4.4.6, doesn't with GCC 4.5.4 and 4.6.0,
but does again with 4.7.0. I'm reporting this just in case the maintainers
aren't aware of it.
enum Tags { some_tag };
template struct BoolValue {};
template
struct Foo {
BoolValue meth();
};
template
BoolValue Foo::meth() {}
The compiler complains about the return type of the method's definition being
BoolValue<(T == (Tags)0u)>
and not
BoolValue<(T == some_tag)>
which is clearly nonsense.
[Bug fortran/53389] [4.6/4.7/4.8 Regression] -frealloc-lhs: memory leak when assigning array function result to allocatable array, where one of its supplied arguments is itself an array function resul
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53389 --- Comment #2 from Stephan Kramer 2012-05-18 15:27:54 UTC --- (In reply to comment #1) > Confirmed. > > Workaround is to use -fno-realloc-lhs Excellent. Thanks for the suggested workaround. That'll save us a lot of unnecessary refactoring.
[Bug tree-optimization/53395] [4.8 Regression] The LAPACK functions i(d|s)amax are more than two times slower after revision 187183
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53395 Andrew Pinski changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |pinskia at gcc dot gnu.org |gnu.org | --- Comment #5 from Andrew Pinski 2012-05-18 16:13:59 UTC --- I have a patch.
[Bug tree-optimization/53346] [4.6/4.7/4.8 Regression] Bad vectorization in the proc cptrf2 of rnflow.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53346 --- Comment #12 from Uros Bizjak 2012-05-18 16:07:45 UTC --- (In reply to comment #11) > You are right. -ftree-vectorize implies -ftree-loop-if-convert and this option > makes all the difference! > > -O2 -ftree-vectorize: > > real0m24.061s > user0m23.789s > sys 0m0.225s > > -O2 -ftree-vectorize -fno-tree-loop-if-convert > > real0m18.029s > user0m17.761s > sys 0m0.220s -O2 -ftree-loop-if-convert: real0m24.034s user0m23.770s sys 0m0.218s -O2 real0m18.163s user0m17.892s sys 0m0.233s
[Bug libstdc++/53270] Error when bootstrapping gcc on hppa2.0-unknown-linux-gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53270 --- Comment #23 from Jonathan Wakely 2012-05-18 16:31:58 UTC --- (I'll be back from holiday on tuesday and able to work on this properly then, including adding a configure check to define the macros automatically when required)
[Bug tree-optimization/53346] [4.6/4.7/4.8 Regression] Bad vectorization in the proc cptrf2 of rnflow.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53346 --- Comment #11 from Uros Bizjak 2012-05-18 16:04:46 UTC --- (In reply to comment #9) > Uneducated guess: is it possible that failed attempts to vectorize may mess up > further optimizations? You are right. -ftree-vectorize implies -ftree-loop-if-convert and this option makes all the difference! -O2 -ftree-vectorize: real0m24.061s user0m23.789s sys 0m0.225s -O2 -ftree-vectorize -fno-tree-loop-if-convert real0m18.029s user0m17.761s sys 0m0.220s We were barking up to the wrong tree. ;)
[Bug c++/53401] New: internal compiler error: Segmentation fault on infinite argument deduction of constexpr templates
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53401
Bug #: 53401
Summary: internal compiler error: Segmentation fault on
infinite argument deduction of constexpr templates
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ai.az...@gmail.com
Created attachment 27434
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27434
Outputs from -v option (repeated error messages are snipped) and preprocessed
source.
The following invalid code causes an ICE with GCC 4.8.0 20120513 (experimental)
and -std=c++11.
/
template
struct index
{};
constexpr int recursive_impl(index<0u>)
{
return 0;
}
template
constexpr auto recursive_impl(index) // Line 11
-> decltype(recursive_impl(index()))
{
return recursive_impl(index());
}
template
constexpr auto recursive()
-> decltype(recursive_impl(index()))
{
return recursive_impl(index());
}
void f(int i)
{
recursive<1>();
}
/
g++: internal compiler error: Segmentation fault (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
The above-mentioned code is invalid because there isn't anything to prevent the
compiler from trying infinite template argument deduction in the second
overload of `recursive_impl' (Line 11). So, I expect error messages like
"template instantiation depth exceeds maximum...". However, the compiler dies
in segmentation fault.
`constexpr' is necessary to reproduce the ICE. Otherwise, the compiler outputs
ordinary error messages as expected.
4.6.4 20120511 (prerelease) and 4.7.1 20120512 (prerelease) also cause the same
problem, too.
[Bug target/53383] Allow -mpreferred-stack-boundary=3 on x86-64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53383 --- Comment #7 from H. Peter Anvin 2012-05-18 15:23:05 UTC --- We can't use the SSE parts of the ABI anyway in the kernel, and I sure hope that -mno-sse (or perhaps -mcmodel=kernel, but that would be ugly) prevents those from being generated. Yes, it's an ABI violation, but it's a very necessary one...
[Bug tree-optimization/53395] [4.8 Regression] The LAPACK functions i(d|s)amax are more than two times slower after revision 187183
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53395 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Component|middle-end |tree-optimization --- Comment #2 from Andrew Pinski 2012-05-18 15:25:13 UTC --- dmax_12 = ABS_EXPR ; dmax_2 = dmax_1 >= dmax_12 ? dmax_1 : dmax_12; __result_idamax_21 = dmax_1 >= dmax_12 ? __result_idamax_22 : i_3; Hmm, dmax_2 should have been MAX_EXPR.
[Bug bootstrap/53394] Stage2 does not pass CFLAGS or LDFLAGS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53394 --- Comment #1 from Andrew Pinski 2012-05-18 15:13:05 UTC --- Use BOOT_CFLAGS and BOOT_LDFLAGS. And Maybe even BOOT_CXXFLAGS and CXXFLAGS.
[Bug tree-optimization/53346] [4.6/4.7/4.8 Regression] Bad vectorization in the proc cptrf2 of rnflow.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53346 --- Comment #10 from Uros Bizjak 2012-05-18 15:11:53 UTC --- (In reply to comment #8) > (In reply to comment #7) > > Fixed. > > Unfortunately, the loop in original rnflow test still gets vectorized, with no > change in the runtime: With -O2 -ftree-loop-distribute-patterns -ftree-vectorize, the runtime is still the same: Each sample counts as 0.01 seconds. % cumulative self self total time seconds secondscalls s/call s/call name 43.76 9.70 9.70 64 0.15 0.15 cptrf2_ 40.69 18.72 9.02 6685 0.00 0.00 trs2a2.2054 7.35 20.35 1.63 64 0.03 0.03 gentrs_ 2.21 20.84 0.49 64 0.01 0.01 cptrf1_ 1.44 21.16 0.321 0.3212.32 matsim_ 1.17 21.42 0.26 6685 0.00 0.00 invima.2045 0.81 21.60 0.18 64 0.00 0.00 cmpcpt_ 0.54 21.72 0.121 0.12 9.85 evlrnf_
[Bug bootstrap/53384] checksum (comparison) differs wrongly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53384 --- Comment #4 from John T 2012-05-18 15:07:48 UTC --- This bug was actually two bugs, the checksum error and the erroneous handling of the gcc used in fixincludes/config.cache I found another way to trip the error involving config.cache. After a successful bootstrap build of gcc 4.6.3, I did a "make distclean" before re-running configure to try building java. On re-running configure, I got the message that CC changed from the value listed in fixincludes/config.cache. "Make distclean" should have cleared all data from the previous build that would interfere with a clean build.
[Bug middle-end/51071] [4.7 Regression] ICE in gimple_has_side_effects, at gimple.c:2513
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51071 pageexec at freemail dot hu changed: What|Removed |Added CC||pageexec at freemail dot hu --- Comment #4 from pageexec at freemail dot hu 2012-05-18 15:02:57 UTC --- this bug affects the 4.6 branch as well (e.g., on linux-3.3.6/drivers/staging/sbe-2t3e3/netdev.c), so it should be backported there too if possible.
[Bug fortran/53379] [4.7/4.8 Regression] No backtrace generated for array bounds violation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53379 --- Comment #5 from Harald Anlauf 2012-05-18 15:02:07 UTC --- (In reply to comment #3) > (In reply to comment #2) > > FWIW, if it is decided to change this, one could also consider changing > > runtime_error() and internal_error() in the same way, though one would need > > to > > audit the usage in libgfortran so that we don't generate a backtrace for a > > "file not found" or similar "benign" error. > > I agree that, at least by default, "file not found" shouldn't print a > backtrace > - though one could still think of it with some aggressive backtrace > flag/environment variable. One option is too add a runtime_fatal() that gets called by those checks that are considered non-recoverable and deserve a backtrace if backtrace is requested. Examples are array-bounds violations, invalid pointers, etc. However, this requires an audit of the frontend.
[Bug java/53400] New: java build failure with NullPointerException
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53400 Bug #: 53400 Summary: java build failure with NullPointerException Classification: Unclassified Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassig...@gcc.gnu.org ReportedBy: j...@worldlinc.net Compiler: gcc-4.6.1, building gcc-4.6.3 java with options /usr/local/gcc-4.6.3/configure --prefix=/usr --enable-languages=java --disable-bootstrap (I used gcc 4.6.1 to build and test gcc 4.6.3 just recently. disable-bootstrap was used to save time, not going to waste time rebuilding gcc three times just to have java crash. That's the reason why I didn't build gcc-4.6.1 with java. java crashes and the build doesn't finish) Original system java: gcj -v Using built-in specs. Reading specs from /usr/lib/gcc/i586-manbo-linux-gnu/4.4.1/libgcj.spec rename spec startfile to startfileorig rename spec lib to liborig Target: i586-manbo-linux-gnu Configured with: ../configure --prefix=/usr --libexecdir=/usr/lib --with-slibdir=/lib --with-bugurl=https://qa.mandriva.com/ --mandir=/usr/share/man --infodir=/usr/share/info --enable-checking=release --enable-languages=c,c++,ada,fortran,objc,obj-c++,java --build=i586-manbo-linux-gnu --host=i586-manbo-linux-gnu --with-cpu=generic --with-system-zlib --enable-threads=posix --enable-shared --enable-objc-gc --enable-long-long --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --enable-java-awt=gtk --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-gtk-cairo --disable-libjava-multilib --enable-ssp --disable-libssp --disable-werror --with-ppl --with-cloog --with-python-dir=/lib/python2.6/site-packages Thread model: posix gcc version 4.4.1 (GCC) System: i686-pc-linux-gnu Options: Using built-in specs. COLLECT_GCC=/usr/bin/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i686-pc-linux-gnu/4.6.1/lto-wrapper Target: i686-pc-linux-gnu Configured with: /usr/local/gcc-4.6.1/configure --prefix=/usr --enable-languages=c,c++,fortran,lto,objc,ada Thread model: posix gcc version 4.6.1 (GCC) compiler/build messages: libtool: compile: /home/dilbert/bld463/./gcc/xgcc -shared-libgcc -B/home/dilbert/bld463/./gcc -nostdinc++ -L/home/dilbert/bld463/i686-pc-linux-gnu/libstdc++-v3/src -L/home/dilbert/bld463/i686-pc-linux-gnu/libstdc++-v3/src/.libs -B/usr/i686-pc-linux-gnu/bin/ -B/usr/i686-pc-linux-gnu/lib/ -isystem /usr/i686-pc-linux-gnu/include -isystem /usr/i686-pc-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I/usr/local/gcc-4.6.3/libjava -I./include -I./gcj -I/usr/local/gcc-4.6.3/libjava -Iinclude -I/usr/local/gcc-4.6.3/libjava/include -I/usr/local/gcc-4.6.3/libjava/classpath/include -Iclasspath/include -I/usr/local/gcc-4.6.3/libjava/classpath/native/fdlibm -I/usr/local/gcc-4.6.3/libjava/../boehm-gc/include -I../boehm-gc/include -I/usr/local/gcc-4.6.3/libjava/libltdl -I/usr/local/gcc-4.6.3/libjava/libltdl -I/usr/local/gcc-4.6.3/libjava/.././libjava/../gcc -I/usr/local/gcc-4.6.3/libjava/../zlib -I/usr/local/gcc-4.6.3/libjava/../libffi/include -I../libffi/include -fno-rtti -fnon-call-exceptions -fdollars-in-identifiers -Wswitch-enum -D_FILE_OFFSET_BITS=64 -ffloat-store -fomit-frame-pointer -Usun -Wextra -Wall -D_GNU_SOURCE -DPREFIX=\"/usr\" -DTOOLEXECLIBDIR=\"/usr/lib\" -DJAVA_HOME=\"/usr\" -DBOOT_CLASS_PATH=\"/usr/share/java/libgcj-4.6.3.jar\" -DJAVA_EXT_DIRS=\"/usr/share/java/ext\" -DGCJ_ENDORSED_DIRS=\"/usr/share/java/gcj-endorsed\" -DGCJ_VERSIONED_LIBDIR=\"/usr/lib/gcj-4.6.3-12\" -DPATH_SEPARATOR=\":\" -DECJ_JAR_FILE=\"\" -DLIBGCJ_DEFAULT_DATABASE=\"/usr/lib/gcj-4.6.3-12/classmap.db\" -DLIBGCJ_DEFAULT_DATABASE_PATH_TAIL=\"gcj-4.6.3-12/classmap.db\" -g -O2 -D_GNU_SOURCE -MT posix-threads.lo -MD -MP -MF .deps/posix-threads.Tpo -c /usr/local/gcc-4.6.3/libjava/posix-threads.cc -o posix-threads.o >/dev/null 2>&1 here=`pwd`; cd /usr/local/gcc-4.6.3/libjava/classpath/lib; \ find gnu java javax org sun -name .svn -prune -o -name '*.class' -print | \ gjar -cfM@ $here/libgcj-4.6.3.jar jar: internal error: java.lang.NullPointerException at gnu.classpath.tools.jar.Creator.writeCommandLineEntries(libgcj-tools.so.10) at gnu.classpath.tools.jar.Creator.run(libgcj-tools.so.10) at gnu.classpath.tools.jar.Main.run(libgcj-tools.so.10) at gnu.classpath.tools.jar.Main.main(libgcj-tools.so.10) make[3]: *** [libgcj-4.6.3.jar] Error 1 make[3]: Leaving directory `/home/dilbert/bld463/i686-pc-linux-gnu/libjava' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/dilbert/bld463/i686-pc-linux-gnu/libjava' make[1]: *** [all-target-libjava] Error 2 make[1]: Leaving directory `/home/dilbert/bld463' make: *** [all] Error 2 The above error message has been given for trying to build java 4.6.1, 4.6.3, and possibly 4.4.x.
[Bug tree-optimization/53346] [4.6/4.7/4.8 Regression] Bad vectorization in the proc cptrf2 of rnflow.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53346 --- Comment #9 from Dominique d'Humieres 2012-05-18 14:49:22 UTC --- > Unfortunately, the loop in original rnflow test still gets vectorized, with no > change in the runtime: Confirmed, at revision 187655 I still get -O2 21.8 -O2 -ftree-vectorize 27.9 -O3 25.2 -O3 -fno-tree-vectorize 21.4 Uneducated guess: is it possible that failed attempts to vectorize may mess up further optimizations?
[Bug tree-optimization/53346] [4.6/4.7/4.8 Regression] Bad vectorization in the proc cptrf2 of rnflow.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53346 Uros Bizjak changed: What|Removed |Added Status|RESOLVED|NEW Resolution|FIXED | --- Comment #8 from Uros Bizjak 2012-05-18 14:46:01 UTC --- (In reply to comment #7) > Fixed. Unfortunately, the loop in original rnflow test still gets vectorized, with no change in the runtime: Each sample counts as 0.01 seconds. % cumulative self self total time seconds secondscalls s/call s/call name 43.46 9.69 9.69 64 0.15 0.15 cptrf2_ 40.63 18.75 9.06 6685 0.00 0.00 trs2a2.2054 7.89 20.51 1.76 64 0.03 0.03 gentrs_ 2.02 20.96 0.45 6685 0.00 0.00 invima.2045 1.93 21.39 0.43 64 0.01 0.01 cptrf1_ 1.17 21.65 0.261 0.2612.36 matsim_ 0.99 21.87 0.22 64 0.00 0.00 cmpcpt_ GNU Fortran (GCC) version 4.8.0 20120518 (experimental) [trunk revision 187655]
[Bug fortran/53379] [4.7/4.8 Regression] No backtrace generated for array bounds violation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53379 --- Comment #4 from Janne Blomqvist 2012-05-18 14:32:54 UTC --- (In reply to comment #3) > (In reply to comment #2) > > AFAICS, this is an intentional change in behavior. When I proposed making > > backtracing enabled by default, there was some objections to the initial > > patch > > on the grounds that the backtracing was too aggressive. > > I wonder whether one should add a more aggressive version of backtrace (which > could be internally pass backtrace == 2), which covers this case. Ditto for > some environment flag. Well yes, but IMHO the best option would be to do the right thing by default, making an option unnecessary. If anything, a bewildering array of options is an usability issue. For instance... > I have to admit that the description of > http://gcc.gnu.org/onlinedocs/gfortran/GFORTRAN_005fERROR_005fBACKTRACE.html > is > misleading. And the meaning and relation of it to > http://gcc.gnu.org/onlinedocs/gfortran/GFORTRAN_005fSHOW_005fLOCUS.html is > also > unclear. one wonders what is the purpose of GFORTRAN_SHOW_LOCUS. What value do we provide by providing a means to NOT print out the filename/line information? I think the answer is "none" and thus we should get rid of it, simplifying the code and manual a tidy bit.
[Bug target/53399] "*ffs" pattern generates wrong code with BMI enabled (for corner cases)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53399 --- Comment #3 from Uros Bizjak 2012-05-18 14:31:47 UTC --- (In reply to comment #0) > It also seems to fail gcc.c-torture/execute/builtin-bitops-1.c Can you please isolate failing test?
[Bug tree-optimization/53346] [4.6/4.7/4.8 Regression] Bad vectorization in the proc cptrf2 of rnflow.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53346 --- Comment #6 from Richard Guenther 2012-05-18 13:10:11 UTC --- Author: rguenth Date: Fri May 18 13:10:01 2012 New Revision: 187655 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187655 Log: 2012-05-18 Richard Guenther PR tree-optimization/53346 * tree-loop-distribution.c (ldist_gen): Make sure to apply builtin transform even when only a single partition with all reads/writes exists. * gcc.dg/tree-ssa/ldist-18.c: New testcase. * gcc.target/i386/incoming-10.c: Adjust. * gcc.target/i386/incoming-11.c: Likewise. * gcc.target/i386/pr46295.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/ldist-18.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/incoming-10.c trunk/gcc/testsuite/gcc.target/i386/incoming-11.c trunk/gcc/testsuite/gcc.target/i386/pr46295.c trunk/gcc/tree-loop-distribution.c
[Bug target/53399] "*ffs" pattern generates wrong code with BMI enabled (for corner cases)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53399 --- Comment #2 from H.J. Lu 2012-05-18 14:28:40 UTC --- This should be ok since the 0 input operand is ignored. If not, please find out why.
[Bug rtl-optimization/53352] Incorrect CSE optimization on RTL expressions with a paradoxical subreg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53352 --- Comment #10 from H.J. Lu 2012-05-18 14:16:46 UTC --- The test fails on Linux/x86 and Linux/x86-64.
[Bug libstdc++/53270] Error when bootstrapping gcc on hppa2.0-unknown-linux-gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53270 --- Comment #20 from jimis 2012-05-18 12:48:05 UTC --- Created attachment 27431 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27431 guard.cc error after defining _GTHREAD_USE_MUTEX_INIT_FUNC
[Bug c++/53398] New: feature request: option for overloaded methods order in vtable compatibility with msc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53398
Bug #: 53398
Summary: feature request: option for overloaded methods order
in vtable compatibility with msc
Classification: Unclassified
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sweetrom...@gmail.com
The target of this topic is about mingw and ms compiler incompatibility.
GCC places overloaded virtual functions in order they appear in class
declaration.
In opposite msc reverts them.
Assuming we have a dll compiled in msc and such header for using the dll:
class A {
virutal void overl(void) = 0;
virutal void fun1(void) = 0;
virutal void overl(int i) = 0;
virutal void overl(double d) = 0;
virutal void fun2(void) = 0;
virutal void overl(char *c) = 0;
};
to use it with mingw compiler we need to change it to
class A {
virutal void overl(char *c) = 0;
virutal void fun1(void) = 0;
virutal void overl(double d) = 0;
virutal void overl(int i) = 0;
virutal void fun2(void) = 0;
virutal void overl(void) = 0;
};
or to portable version, which removes overloading (behave gcc ordering)
class A {
virutal void overlC(char *c) = 0;
virutal void fun1(void) = 0;
virutal void overlD(double d) = 0;
virutal void overlI(int i) = 0;
virutal void fun2(void) = 0;
virutal void overlV(void) = 0;
};
It would be nice to have some option to just say the compiler to use different
order.
We could have an option added to a compiler like -fvisibility-ms-compat or
-fabi-version=n.
Or maybe better by something like pragma pack push, so we can do:
#pragma vtorder(push, reverted)
#include "dll_header.h"
#pragma vtorder(pop)
[Bug tree-optimization/53346] [4.6/4.7/4.8 Regression] Bad vectorization in the proc cptrf2 of rnflow.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53346 Richard Guenther changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #7 from Richard Guenther 2012-05-18 13:10:28 UTC --- Fixed.
[Bug target/53385] [4.8 Regression] "Error: operand out of range" after changes for LSHIFT_EXPR in vrp.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53385 --- Comment #12 from William J. Schmidt 2012-05-18 14:05:06 UTC --- Created attachment 27433 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27433 Tentative patch Tentative patch following Jakub's suggestion. This fixes bootstrap. Pending approval.
[Bug rtl-optimization/53373] [4.8 regression] ICE on valid code with -march-native
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53373 --- Comment #5 from Stupachenko Evgeny 2012-05-18 13:56:56 UTC --- 14 spec2006 tests also fail after the commit 187459, (compiled with -O2 -march=corei7 -mtune=corei7 -mavx -m64) However without -mavx they pass.
[Bug libstdc++/53270] Error when bootstrapping gcc on hppa2.0-unknown-linux-gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53270 --- Comment #21 from jimis 2012-05-18 12:48:53 UTC --- Created attachment 27432 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27432 preprocessed source after defining _GTHREAD_USE_MUTEX_INIT_FUNC
[Bug bootstrap/53396] [4.8 Regression] revision 187631 breaks bootstrap on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53396 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED --- Comment #2 from Dominique d'Humieres 2012-05-18 14:21:43 UTC --- Bootstrap just finished at revision 187651, so closing as fixed. Thanks for the patch.
[Bug libstdc++/53270] Error when bootstrapping gcc on hppa2.0-unknown-linux-gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53270 --- Comment #19 from jimis 2012-05-18 12:46:43 UTC --- Defining _GTHREAD_USE_MUTEX_INIT_FUNC in os/gnu-linx/os_defines.h didn't help. See attached files for new error message and preprocessed source. Also keep in mind that gcc61 shows some strange message in its dmesg. Though unlikely, it might be that some kernel or hardware bug is involved...
[Bug target/53399] "*ffs" pattern generates wrong code with BMI enabled (for corner cases)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53399 --- Comment #1 from Yukhin Kirill 2012-05-18 13:58:22 UTC --- (In reply to comment #0) > It also seems to fail gcc.c-torture/execute/builtin-bitops-1.c It fails on BMI-capable CPU
[Bug target/53399] New: "*ffs" pattern generates wrong code with BMI enabled (for corner cases)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53399
Bug #: 53399
Summary: "*ffs" pattern generates wrong code with BMI enabled
(for corner cases)
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kirill.yuk...@intel.com
We have in GCC int. (__ffs description):
These functions return the index of the least significant 1-bit in a, or the
value zero if a is zero.
and in i386.md:
(define_insn "*ffs_1"
[(set (reg:CCZ FLAGS_REG)
(compare:CCZ (match_operand:SWI48 1 "nonimmediate_operand" "rm")
(const_int 0)))
(set (match_operand:SWI48 0 "register_operand" "=r")
(ctz:SWI48 (match_dup 1)))]
""
{
if (TARGET_BMI)
return "tzcnt{}\t{%1, %0|%0, %1}";
else
This pattern works fine for bsf insn (although the result with zero input is
undefined)
But for tzcnt with 0 as input we have (operand_size+1) as output.
That contradicts with GCC int, right?
It also seems to fail gcc.c-torture/execute/builtin-bitops-1.c
[Bug tree-optimization/53355] Autovectorization of a simple loop could be improved.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53355
--- Comment #5 from Richard Guenther 2012-05-18
12:32:11 UTC ---
The following testcase (extracted from PR53346, which stores zero though) shows
another case of slowness
void foo (int *p, int n)
{
int i;
for (i = 0; i < n; ++i)
p[i] = 1;
}
[Bug target/53378] gcc/regs.h hides system header regs.h on vxWorks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53378 --- Comment #4 from rbmj at verizon dot net 2012-05-18 12:16:29 UTC --- The issue is that this is affecting a system header (ioLib.h) which is included from other, standard header files.
[Bug tree-optimization/53397] Scimark performance drops by 10x times when compiled -O3 -march=amdfam10 due to generation more prefecthes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53397 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-05-18 Version|tree-ssa|4.7.1 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther 2012-05-18 12:11:07 UTC --- Confirmed.
[Bug tree-optimization/53390] [4.8 Regression] ICE: tree check: expected integer_cst, have nop_expr in vect_compute_data_ref_alignmen on 32-bit x86 host
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53390 Richard Guenther changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Richard Guenther 2012-05-18 12:10:12 UTC --- Fixed.
[Bug tree-optimization/53390] [4.8 Regression] ICE: tree check: expected integer_cst, have nop_expr in vect_compute_data_ref_alignmen on 32-bit x86 host
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53390 --- Comment #5 from Richard Guenther 2012-05-18 12:09:55 UTC --- Author: rguenth Date: Fri May 18 12:09:49 2012 New Revision: 187653 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187653 Log: 2012-05-18 Richard Guenther PR tree-optimization/53390 * tree-vect-data-refs.c (vect_compute_data_ref_alignment): Ignore strided loads. * gcc.dg/torture/pr53390.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr53390.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-data-refs.c
[Bug tree-optimization/53397] Scimark performance drops by 10x times when compiled -O3 -march=amdfam10 due to generation more prefecthes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53397 Venkataramanan changed: What|Removed |Added Target||x86_64-unknown-linux-gnu CC||rguenth at gcc dot gnu.org Host||x86_64-unknown-linux-gnu Build||x86_64-unknown-linux-gnu Severity|normal |major
[Bug tree-optimization/53397] New: Scimark performance drops by 10x times when compiled -O3 -march=amdfam10 due to generation more prefecthes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53397 Bug #: 53397 Summary: Scimark performance drops by 10x times when compiled -O3 -march=amdfam10 due to generation more prefecthes Classification: Unclassified Product: gcc Version: tree-ssa Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: venkataramanan.ku...@amd.com With GCC4.7 the benchmark score drops from ~400 Mflops to ~40 mflops. Almost 10 folds. Prefecth instructions introduced in the innermost loops of "FFT_transform_internal" ( FFT.c ) in GCC4.7 but not in GCC4.6 which is causing the slow down. Compiling this function alone as a separate test case with -fno-prefetch-loop-arrays brings back the original score. The problem is exposed http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175474 With GCC r175473 -- gcc -O3 -march=amdfam10 *.c -o Scimark175473 -lm vekumar@pcedinar5:/local/home/vekumar/SciMark2_bench/SciMark2> ./Scimark175473 ** ** ** SciMark2 Numeric Benchmark, see http://math.nist.gov/scimark ** ** for details. (Results can be submitted to p...@nist.gov) ** ** ** Using 2.00 seconds min time per kenel. Composite Score: 99.67 FFT Mflops: 498.35(N=1024) With GCC r175474 - gcc -O3 -march=amdfam10 *.c -o Scimark175474 -lm vekumar@pcedinar5:/local/home/vekumar/SciMark2_bench/SciMark2> ./Scimark175474 ** ** ** SciMark2 Numeric Benchmark, see http://math.nist.gov/scimark ** ** for details. (Results can be submitted to p...@nist.gov) ** ** ** Using 2.00 seconds min time per kenel. Composite Score:7.73 FFT Mflops:38.66(N=1024)
[Bug target/53383] Allow -mpreferred-stack-boundary=3 on x86-64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53383 Jan Hubicka changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #6 from Jan Hubicka 2012-05-18 11:54:03 UTC --- The reason why -mpreferred-stack-boundary=3 is not allowed is that the va-args sequences generated are not safe in the case frame is misaligned and values with higher intended alignment are passed. In that case the caller would be required to do dynamic stack alignment. Otherwise the value might end up misaligned on the stack and va-arg sequence will do alignment using & operation resulting in fetching wrong value from memory. Since we have dynamic stack alignment now, we could allow that and explicitely document that as ABI breaking (like we have the double alignment and other kludges on x86) Honza
[Bug tree-optimization/53395] [4.8 Regression] The LAPACK functions i(d|s)amax are more than two times slower after revision 187183
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53395 --- Comment #1 from Dominique d'Humieres 2012-05-18 11:24:06 UTC --- The assembly code for -O3 is almost the same for revisions 187182 and 187183. However with '-O3 -ffast-math', revision 187182 gives for the loop L12: movapd%xmm2, %xmm1 L9: movsd8(%rsi), %xmm0 andpd%xmm3, %xmm0 comisd%xmm0, %xmm1 movapd%xmm0, %xmm2 maxsd%xmm1, %xmm2 cmovb%edx, %eax addl$1, %edx addq$8, %rsi cmpl%ecx, %edx jneL12 while revision 187183 gives L6: movapd%xmm2, %xmm1 L3: movsd8(%rsi), %xmm0 movapd%xmm1, %xmm3 andpd%xmm4, %xmm0 comisd%xmm0, %xmm1 movapd%xmm0, %xmm2 cmplesd%xmm1, %xmm2 cmovb%edx, %eax addl$1, %edx addq$8, %rsi cmpl%ecx, %edx andpd%xmm2, %xmm3 andnpd%xmm0, %xmm2 orpd%xmm3, %xmm2 jneL6 (for the later -ffast-math only change ucomisd to comisd).
[Bug bootstrap/53396] [4.8 Regression] revision 187631 breaks bootstrap on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53396 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug rtl-optimization/53373] [4.8 regression] ICE on valid code with -march-native
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53373 Richard Guenther changed: What|Removed |Added CC||vincenzo.innocente at cern ||dot ch --- Comment #3 from Richard Guenther 2012-05-18 10:51:20 UTC --- *** Bug 53393 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/53346] [4.6/4.7/4.8 Regression] Bad vectorization in the proc cptrf2 of rnflow.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53346 Richard Guenther changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | --- Comment #5 from Richard Guenther 2012-05-18 11:02:53 UTC --- Yeah, this is sort-of related to what is observed in PR53355. I suppose at runtime nxtr is comparatively small. Reduced testcase: subroutine cptrf2 (nxtr, ixtrt) integer, dimension (1:nxtr), intent (out) :: ixtrt ixtrt = 0 end subroutine we peel the loop to possibly align the stores, and we peel the loop to possibly take care of a remaining store at the end of the array. And of course we compute that we need at least 6 scalar iterations to make executing the vectorized loop profitable. And apart from all that we should have recognized the loop as memset. Mine.
[Bug bootstrap/53396] [4.8 Regression] revision 187631 breaks bootstrap on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53396 Jan Hubicka changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-05-18 AssignedTo|unassigned at gcc dot |hubicka at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Jan Hubicka 2012-05-18 11:48:00 UTC --- This bug should be solved by the following patch: * cgraphunit.c (varpool_finalize_decl): Allow external decls. (mark_functions_to_output): Fix sanity check. * ipa.c (function_and_variable_visibility): Remove TREE_STATIC check. Can you, please, confirm that the bootstrap is working now? Honza
[Bug tree-optimization/53366] wrong code generation by tree vectorizer using AVX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53366
--- Comment #8 from Richard Guenther 2012-05-18
10:36:04 UTC ---
(In reply to comment #7)
> Indeed,
>
> --- gcc/tree-vect-slp.c.jj2012-04-19 11:09:13.0 +0200
> +++ gcc/tree-vect-slp.c2012-05-17 10:47:30.124290361 +0200
> @@ -1199,7 +1199,8 @@ vect_supported_load_permutation_p (slp_i
>
>/* We checked that this case ok, so there is no need to proceed with
> permutation tests. */
> - if (complex_numbers == 2)
> + if (complex_numbers == 2
> + && VEC_length (slp_tree, SLP_INSTANCE_LOADS (slp_instn)) == 2)
> {
>VEC_free (slp_tree, heap, SLP_INSTANCE_LOADS (slp_instn));
>VEC_free (int, heap, SLP_INSTANCE_LOAD_PERMUTATION (slp_instn));
>
> alone fixes this as the further load permutation checks fail. Whether this is
> the right fix and whether it is sufficient, no idea unfortunately, not
> familiar
> enough with the interleaving code. Richard or Michael, any thoughts?
I'm not very familiar with the code, but the above looks sensible and safe
at least.
[Bug middle-end/53395] [4.8 Regression] The LAPACK functions i(d|s)amax are more than two times slower after revision 187183
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53395 Richard Guenther changed: What|Removed |Added Component|tree-optimization |middle-end Target Milestone|--- |4.8.0
[Bug rtl-optimization/53373] [4.8 regression] ICE on valid code with -march-native
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53373 Richard Guenther changed: What|Removed |Added CC||danglin at gcc dot gnu.org --- Comment #4 from Richard Guenther 2012-05-18 10:52:03 UTC --- *** Bug 53381 has been marked as a duplicate of this bug. ***
[Bug middle-end/53393] [4.8] ICE in building gcc ( in in save_call_clobbered_regs () at ../../gcc-trunk/gcc/caller-save.c:876)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53393 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Richard Guenther 2012-05-18 10:51:19 UTC --- dup *** This bug has been marked as a duplicate of bug 53373 ***
[Bug middle-end/53381] [4.8 Regression] Bootstrap fails building stage1 libgcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53381 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug tree-optimization/53395] New: [4.8 Regression] The LAPACK functions i(d|s)amax are more than two times slower after revision 187183
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53395 Bug #: 53395 Summary: [4.8 Regression] The LAPACK functions i(d|s)amax are more than two times slower after revision 187183 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: pins...@gcc.gnu.org As noted in pr53346, the LAPACK functions i(d|s)amax compiled with '-O3 -ffast-math -funroll-loops' are more than two times slower after revision 187183 on x86_64-apple-darwin10, as shown by the following results for a reduced version of idamax (increment one only) [macbook] test/dbg_rnflow% cat idamax_red.f90 integer function idamax(n,dx) ! double precision dx(*),dmax integer i,n ! idamax = 1 20 dmax = dabs(dx(1)) do 30 i = 2,n if(dabs(dx(i)).le.dmax) go to 30 idamax = i dmax = dabs(dx(i)) 30 continue return end [macbook] test/dbg_rnflow% cat tst_idamax_red.f90 implicit none integer, parameter :: n = 4 integer :: i, j, res(n+1) integer :: idamax external idamax real(8) :: x, dx, a(n+1) dx = 2.0/real(n, kind=8) do i = 0, n x = dx*real(i, kind=8) - 1.0 a(i+1) = 1-2.0*(1-2.0*x**2)**2-0.1_8*x end do res = 0 do i = 0, n j = idamax(n+1, a) res(i+1) = j a(i+1) = a(i+1) + 0.1_8 end do print *, sum(res) end [macbook] test/dbg_rnflow% /opt/gcc/gcc4.8p-187182/bin/gfortran -c -O3 -ffast-math -funroll-loops idamax_red.f90 [macbook] test/dbg_rnflow% gfc tst_idamax_red.f90 idamax_red.o [macbook] test/dbg_rnflow% time a.out 386062110 2.474u 0.002s 0:02.47 100.0%0+0k 0+0io 0pf+0w [macbook] test/dbg_rnflow% /opt/gcc/gcc4.8p-187183/bin/gfortran -c -O3 -ffast-math -funroll-loops idamax_red.f90 [macbook] test/dbg_rnflow% gfc tst_idamax_red.f90 idamax_red.o [macbook] test/dbg_rnflow% time a.out 386062110 5.561u 0.004s 0:05.56 100.0%0+0k 0+0io 0pf+0w
[Bug tree-optimization/53390] [4.8 Regression] ICE: tree check: expected integer_cst, have nop_expr in vect_compute_data_ref_alignmen on 32-bit x86 host
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53390 Richard Guenther changed: What|Removed |Added Target|x86-32 |i?86-*-* Status|NEW |ASSIGNED Host|CentOS 6 x86-32 | AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Summary|ICE: tree check: expected |[4.8 Regression] ICE: tree |integer_cst, have nop_expr |check: expected |in |integer_cst, have nop_expr |vect_compute_data_ref_align |in |men on 32-bit x86 host |vect_compute_data_ref_align ||men on 32-bit x86 host --- Comment #4 from Richard Guenther 2012-05-18 10:47:10 UTC --- Mine. Index: gcc/tree-vect-data-refs.c === --- gcc/tree-vect-data-refs.c (revision 187650) +++ gcc/tree-vect-data-refs.c (working copy) @@ -824,6 +824,11 @@ vect_compute_data_ref_alignment (struct /* Initialize misalignment to unknown. */ SET_DR_MISALIGNMENT (dr, -1); + /* Strided loads perform only component accesses, misalignment information + is irrelevant for them. */ + if (STMT_VINFO_STRIDE_LOAD_P (stmt_info)) +return true; + misalign = DR_INIT (dr); aligned_to = DR_ALIGNED_TO (dr); base_addr = DR_BASE_ADDRESS (dr);
[Bug middle-end/53381] [4.8 Regression] Bootstrap fails building stage1 libgcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53381 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #11 from Richard Guenther 2012-05-18 10:52:03 UTC --- duplicate btw. *** This bug has been marked as a duplicate of bug 53373 ***
[Bug bootstrap/53396] New: [4.8 Regression] revision 187631 breaks bootstrap on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53396 Bug #: 53396 Summary: [4.8 Regression] revision 187631 breaks bootstrap on x86_64-apple-darwin10 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: hubi...@gcc.gnu.org On x86_64-apple-darwin10 bootstrap is broken by revision 187631 (a clean bootstrap of r187630 did succeed): /bin/sh ../../libtool --tag CXX --tag disable-shared --mode=compile /opt/gcc/build_w/./gcc/xgcc -shared-libgcc -B/opt/gcc/build_w/./gcc -nostdinc++ -L/opt/gcc/build_w/x86_64-apple-darwin10.8.0/libstdc++-v3/src -L/opt/gcc/build_w/x86_64-apple-darwin10.8.0/libstdc++-v3/src/.libs -B/opt/gcc/gcc4.8w/x86_64-apple-darwin10.8.0/bin/ -B/opt/gcc/gcc4.8w/x86_64-apple-darwin10.8.0/lib/ -isystem /opt/gcc/gcc4.8w/x86_64-apple-darwin10.8.0/include -isystem /opt/gcc/gcc4.8w/x86_64-apple-darwin10.8.0/sys-include -I/opt/gcc/_clean/libstdc++-v3/../libgcc -I/opt/gcc/build_w/x86_64-apple-darwin10.8.0/libstdc++-v3/include/x86_64-apple-darwin10.8.0 -I/opt/gcc/build_w/x86_64-apple-darwin10.8.0/libstdc++-v3/include -I/opt/gcc/_clean/libstdc++-v3/libsupc++ -prefer-pic -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once -fvisibility-inlines-hidden -ffunction-sections -fdata-sections -frandom-seed=ios_init.lo -g -O2 -c -o ios_init.lo ../../../../../_clean/libstdc++-v3/src/c++98/ios_init.cc libtool: compile: /opt/gcc/build_w/./gcc/xgcc -shared-libgcc -B/opt/gcc/build_w/./gcc -nostdinc++ -L/opt/gcc/build_w/x86_64-apple-darwin10.8.0/libstdc++-v3/src -L/opt/gcc/build_w/x86_64-apple-darwin10.8.0/libstdc++-v3/src/.libs -B/opt/gcc/gcc4.8w/x86_64-apple-darwin10.8.0/bin/ -B/opt/gcc/gcc4.8w/x86_64-apple-darwin10.8.0/lib/ -isystem /opt/gcc/gcc4.8w/x86_64-apple-darwin10.8.0/include -isystem /opt/gcc/gcc4.8w/x86_64-apple-darwin10.8.0/sys-include -I/opt/gcc/_clean/libstdc++-v3/../libgcc -I/opt/gcc/build_w/x86_64-apple-darwin10.8.0/libstdc++-v3/include/x86_64-apple-darwin10.8.0 -I/opt/gcc/build_w/x86_64-apple-darwin10.8.0/libstdc++-v3/include -I/opt/gcc/_clean/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once -fvisibility-inlines-hidden -ffunction-sections -fdata-sections -frandom-seed=ios_init.lo -g -O2 -c ../../../../../_clean/libstdc++-v3/src/c++98/ios_init.cc -fno-common -DPIC -o ios_init.o _ZN9__gnu_cxx18stdio_sync_filebufIwSt11char_traitsIwEED1Ev/366 (virtual __gnu_cxx::stdio_sync_filebuf::~stdio_sync_filebuf()) @0x1027ac270 Type: function Visibility: public weak comdat comdat_group:_ZN9__gnu_cxx18stdio_sync_filebufIwSt11char_traitsIwEED1Ev one_only visibility_specified virtual artificial Address is taken. References: Referring: _ZTVN9__gnu_cxx18stdio_sync_filebufIwSt11char_traitsIwEEE/323 (addr) Availability: not_available Function flags: body finalized Called by: Calls: In file included from ../../../../../_clean/libstdc++-v3/src/c++98/ios_init.cc:36:0: /opt/gcc/build_w/x86_64-apple-darwin10.8.0/libstdc++-v3/include/ext/stdio_sync_filebuf.h:57:11: internal compiler error: failed to reclaim unneeded function class stdio_sync_filebuf : public std::basic_streambuf<_CharT, _Traits> ^ Note that this pr may be a duplicate of pr53393.
[Bug target/53383] Allow -mpreferred-stack-boundary=3 on x86-64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53383 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-05-18 Ever Confirmed|0 |1
[Bug bootstrap/53394] New: Stage2 does not pass CFLAGS or LDFLAGS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53394 Bug #: 53394 Summary: Stage2 does not pass CFLAGS or LDFLAGS Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: keith_o...@hotmail.com
[Bug target/53385] [4.8 Regression] "Error: operand out of range" after changes for LSHIFT_EXPR in vrp.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53385 Richard Guenther changed: What|Removed |Added Component|tree-optimization |target --- Comment #11 from Richard Guenther 2012-05-18 09:45:31 UTC --- Target issue.
[Bug tree-optimization/49616] REGRESSION vectorization fails in case of runtime dimensioned vector
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49616 vincenzo Innocente changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from vincenzo Innocente 2012-05-18 09:39:24 UTC --- now ok in gcc version 4.7.1 20120517 (prerelease) [gcc-4_7-branch revision 187624] (GCC) and gcc version 4.8.0 20120509 (experimental) [trunk revision 187326] (GCC)
