[Bug c/53083] gcc bug in moving from the SSE registers back onto the heap.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53083 --- Comment #10 from Uros Bizjak 2012-05-16 06:36:27 UTC --- Youo can start from [1], you have a failing output there, just provide some reference input to failing function. [1] https://bugs.freedesktop.org/show_bug.cgi?id=47559#c8
[Bug c/53083] gcc bug in moving from the SSE registers back onto the heap.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53083 --- Comment #9 from Uros Bizjak 2012-05-16 06:33:35 UTC --- (In reply to comment #8) > > I've tried to take the source-file in question (miarc.c) and make something > > self-contained, but I was unable to make it work due to this being an > > internal > > xorg-file, apparently using and depending on internal headers. If you have > > any > > pointers on how to tackle such a situation to convert it to something > > selfcontained I'd be happy to try it out. > > First, prepare some test input and call failing function. Compare its result > with some reference result and abort () if the result is not expected. The > preprocessed file is self-contained, so you could just compile it and link > into > executable. You can obtain reference result by running the function, compiled with non-failing compile flags.
[Bug c/53083] gcc bug in moving from the SSE registers back onto the heap.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53083 --- Comment #8 from Uros Bizjak 2012-05-16 06:30:58 UTC --- (In reply to comment #6) > I've tried to take the source-file in question (miarc.c) and make something > self-contained, but I was unable to make it work due to this being an internal > xorg-file, apparently using and depending on internal headers. If you have any > pointers on how to tackle such a situation to convert it to something > selfcontained I'd be happy to try it out. First, prepare some test input and call failing function. Compare its result with some reference result and abort () if the result is not expected. The preprocessed file is self-contained, so you could just compile it and link into executable. Starting from here, you remove portions of the function that are not needed (i.e. unreachable if branches, switch cases, etc...) for test input. Maybe you could ask Gentoo compiler maintainer for help...
[Bug target/53362] gcc 4.7 generates invalid code with -O3 and -mtune=bdver2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53362 --- Comment #5 from Uros Bizjak 2012-05-16 06:13:53 UTC --- (In reply to comment #4) > Is this enough for you to work with? No, please follow the instructions in [1]. Also, since this is a runtime problem, we will need (preferrably minimized) source that can be compiled to an executable that fails. [1] http://gcc.gnu.org/bugs/#report
[Bug target/53372] [avr] Section attribute ignored with address space
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53372 Georg-Johann Lay changed: What|Removed |Added Priority|P3 |P5 Status|UNCONFIRMED |NEW Last reconfirmed||2012-05-16 Target Milestone|--- |4.7.1 Ever Confirmed|0 |1
[Bug target/53372] New: [avr] Section attribute ignored with address space
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53372
Bug #: 53372
Summary: [avr] Section attribute ignored with address space
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@gcc.gnu.org
Target: avr
In the following code the section attribute is ignored
const __memx int __attribute__((section(".rodata"))) a = 1;
because the address space __memx overrides the section no matter what:
.globala
.section.progmem.data,"a",@progbits
.typea, @object
.sizea, 2
a:
.word1
[Bug tree-optimization/53366] wrong code generation by tree vectorizer using AVX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53366 H.J. Lu changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org --- Comment #1 from H.J. Lu 2012-05-16 04:53:46 UTC --- It is caused by revision 172817: http://gcc.gnu.org/ml/gcc-cvs/2011-04/msg01013.html
[Bug c++/53364] [4.7/4.8 Regression] Wrong code generation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53364 --- Comment #3 from foom at fuhm dot net 2012-05-16 04:28:21 UTC --- > Does -fno-tree-vrp fix the issue? Nope, "g++ -O2 -fno-tree-vrp -c test.cpp" is no different than without.
[Bug c++/53364] [4.7/4.8 Regression] Wrong code generation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53364 --- Comment #2 from Andrew Pinski 2012-05-16 04:13:07 UTC --- Does -fno-tree-vrp fix the issue?
[Bug c++/53364] [4.7/4.8 Regression] Wrong code generation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53364
--- Comment #1 from foom at fuhm dot net 2012-05-16 04:10:59 UTC ---
Asm generated. Note that at no point is anything ever actually written to the
stack, only read from it:
:
0:83 3d 00 00 00 00 09 cmpl $0x9,0x0(%rip)# 7
7:48 8d 44 24 e8 lea-0x18(%rsp),%rax
c:48 8d 54 24 d8 lea-0x28(%rsp),%rdx
11:48 0f 4f c2 cmovg %rdx,%rax
15:8b 00mov(%rax),%eax
17:c3 retq
Making what ought to be a no-op change to the program, using class "A" instead
of "B", thus:
int main() {
A a = A(10);
a = std::min(a, A(data));
return int(a);
}
causes the following, correctly working, asm to be generated. This is the same
output generated by adding "-fno-strict-aliasing" to the compile line for the
original program. See that it now does write values onto the stack locations
being read from.
(It also seems rather crazy to me that gcc doesn't optimize such a simple
program to use purely registers and no stack addresses, but I suppose that's a
different bug.)
:
0:8b 15 00 00 00 00mov0x0(%rip),%edx# 6
6:48 8d 44 24 e8 lea-0x18(%rsp),%rax
b:48 8d 4c 24 d8 lea-0x28(%rsp),%rcx
10:c7 44 24 d8 0a 00 00 movl $0xa,-0x28(%rsp)
17:00
18:83 fa 09 cmp$0x9,%edx
1b:89 54 24 e8 mov%edx,-0x18(%rsp)
1f:48 0f 4f c1 cmovg %rcx,%rax
23:8b 00mov(%rax),%eax
25:c3 retq
[Bug c++/53371] rvalue reference type as exception-declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53371 --- Comment #1 from Jeroen Habraken 2012-05-16 03:30:16 UTC --- Created attachment 27416 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27416 minimal example
[Bug c++/53371] New: rvalue reference type as exception-declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53371
Bug #: 53371
Summary: rvalue reference type as exception-declaration
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vexoc...@gmail.com
Using built-in specs.
COLLECT_GCC=g++-mp-4.7
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin10/4.7.0/lto-wrapper
Target: x86_64-apple-darwin10
Configured with: ../gcc-4.7.0/configure --prefix=/opt/local
--build=x86_64-apple-darwin10
--enable-languages=c,c++,objc,obj-c++,lto,fortran,java
--libdir=/opt/local/lib/gcc47 --includedir=/opt/local/include/gcc47
--infodir=/opt/local/share/info --mandir=/opt/local/share/man
--datarootdir=/opt/local/share/gcc-4.7 --with-libiconv-prefix=/opt/local
--with-local-prefix=/opt/local --with-system-zlib --disable-nls
--program-suffix=-mp-4.7 --with-gxx-include-dir=/opt/local/include/gcc47/c++/
--with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local
--with-ppl=/opt/local --with-cloog=/opt/local --enable-cloog-backend=isl
--enable-stage1-checking --disable-multilib --enable-lto
--with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld
--with-ar=/opt/local/bin/ar --with-bugurl=https://trac.macports.org/newticket
--with-pkgversion='MacPorts gcc47 4.7.0_3'
Thread model: posix
gcc version 4.7.0 (MacPorts gcc47 4.7.0_3)
g++-mp-4.7 foo.cpp -o foo -std=c++11
The C++11 standard states "The exception-declaration shall not denote an
incomplete type, an abstract class type, or an rvalue reference type." in
section 15.3, however the attached code compiles.
clang++-mp-3.0 foo.cpp -o foo -std=c++11 gives
foo.cpp:8:19: error: cannot catch exceptions by rvalue reference
} catch (A && a) {
^
[Bug c++/52841] [4.7/4.8 Regression] error: type 'Solvable' is not a base type for type 'Resolvable'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52841 --- Comment #14 from H.J. Lu 2012-05-16 03:22:36 UTC --- This is triggered by revision 181118: http://gcc.gnu.org/ml/gcc-cvs/2011-11/msg00406.html
[Bug c++/53368] [4.7/4.8 regression] c++11 reject-valid-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53368 --- Comment #3 from H.J. Lu 2012-05-16 03:19:27 UTC --- This is triggered by revision 181118: http://gcc.gnu.org/ml/gcc-cvs/2011-11/msg00406.html
[Bug c++/53368] [4.7/4.8 regression] c++11 reject-valid-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53368 Paul Pluzhnikov changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #2 from Paul Pluzhnikov 2012-05-16 03:09:56 UTC --- Yes, looks like a dup of 52841. *** This bug has been marked as a duplicate of bug 52841 ***
[Bug c++/52841] [4.7/4.8 Regression] error: type 'Solvable' is not a base type for type 'Resolvable'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52841 Paul Pluzhnikov changed: What|Removed |Added CC||ppluzhnikov at google dot ||com --- Comment #13 from Paul Pluzhnikov 2012-05-16 03:09:56 UTC --- *** Bug 53368 has been marked as a duplicate of this bug. ***
[Bug bootstrap/53238] Bootstrap failure: error: 'pthread_mutex_timedlock' was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53238 --- Comment #12 from Jonathan Wakely 2012-05-16 03:05:51 UTC --- IIRC that should already be instantiated
[Bug c++/53370] New: Unbalanced parenthesis when using __attribute__
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53370
Bug #: 53370
Summary: Unbalanced parenthesis when using __attribute__
Classification: Unclassified
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: matias.fontan...@gmail.com
When using __attribute__((packed(N))), an unbalanced amount of parenthesis can
be used and no compilation error is detected. The documentation states:
"Note that __attribute__ spelled with two underscores before and two after, and
there are always two sets of parentheses surrounding the contents."
So this looks like a bug. To reproduce this error, compile this:
int main() {
__attribute__((aligned(16)) char arr[5];
}
Which contains three '(' and two ')' and still compiles. Note that gcc does
detect this error, g++ does not.
[Bug libstdc++/53339] unordered_map::iterator requires Value to be complete type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53339 --- Comment #20 from Jonathan Wakely 2012-05-16 02:52:26 UTC --- So please feel free to share ideas. A patch is not an idea though, it's an implementation. In any case last time I checked the law is not based just on what you believe ;) Please don't take my comment the wrong way, I'm grateful for your report and help fixing it (and I'm sure others are too) but if you don't want to do the work (which is fine) then don't do it, share the results, then say you won't do the (admittedly complicated) paperwork needed to make that work usable - it's easier all round just to suggest an idea not provide an unusable implementation. If you do want to complete the copyright assignment paperwork then the situation wouldn't arise anyway :)
[Bug bootstrap/53238] Bootstrap failure: error: 'pthread_mutex_timedlock' was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53238
--- Comment #11 from Daniel Richard G. 2012-05-16
02:51:24 UTC ---
Okay, the bootstrap gets further this time. A couple of unrelated issues came
up which I was able to work around, but then I encountered this:
[...]
/tmp/gcc-build/./prev-gcc/g++ -B/tmp/gcc-build/./prev-gcc/
-B/opt/tg/powerpc-ibm-aix4.3.2.0/bin/ -nostdinc++
-B/tmp/gcc-build/prev-powerpc-ibm-aix4.3.2.0/libstdc++-v3/src/.libs
-B/tmp/gcc-build/prev-powerpc-ibm-aix4.3.2.0/libstdc++-v3/libsupc++/.libs
-I/tmp/gcc-build/prev-powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/powerpc-ibm-aix4.3.2.0
-I/tmp/gcc-build/prev-powerpc-ibm-aix4.3.2.0/libstdc++-v3/include
-I/home/src/gcc-4.7.0/libstdc++-v3/libsupc++
-L/tmp/gcc-build/prev-powerpc-ibm-aix4.3.2.0/libstdc++-v3/src/.libs
-L/tmp/gcc-build/prev-powerpc-ibm-aix4.3.2.0/libstdc++-v3/libsupc++/.libs -g
-O2 -DIN_GCC -fno-exceptions -fno-rtti -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H
-static-libstdc++ -static-libgcc -Wl,-bbigtoc -Wl,-bmaxdata:0x4000 -o cc1
c-lang.o c-family/stub-objc.o attribs.o c-errors.o c-decl.o c-typeck.o
c-convert.o c-aux-info.o c-objc-common.o c-parser.o tree-mudflap.o
c-family/c-common.o c-family/c-cppbuiltin.o c-family/c-dump.o
c-family/c-format.o c-family/c-gimplify.o c-family/c-lex.o c-family/c-omp.o
c-family/c-opts.o c-family/c-pch.o c-family/c-ppoutput.o c-family/c-pragma.o
c-family/c-pretty-print.o c-family/c-semantics.o c-family/c-ada-spec.o
default-c.o rs6000-c.o \
cc1-checksum.o main.o libbackend.a libcommon-target.a libcommon.a
../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a
../libcpp/libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a
-L/tg/freeport/arch/aix32/lib -L/tg/freeport/arch/aix32/lib
-L/tg/freeport/arch/aix32/lib -lmpc -lmpfr -lgmp -L../zlib -lz
ld: 0711-317 ERROR: Undefined symbol: vtable for std::ctype
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
collect2: error: ld returned 8 exit status
gmake[3]: *** [cc1] Error 1
gmake[3]: Leaving directory `/tmp/gcc-build/gcc'
gmake[2]: *** [all-stage2-gcc] Error 2
gmake[2]: Leaving directory `/tmp/gcc-build'
gmake[1]: *** [stage2-bubble] Error 2
gmake[1]: Leaving directory `/tmp/gcc-build'
gmake: *** [bootstrap-lean] Error 2
If I add -Wl,-bnoquiet to that, I get
[...]
ld: 0711-318 ERROR: Undefined symbols were found.
The following symbols are in error:
SymbolInpndx TY CL Source-File(Object-File) OR
Import-File{Shared-object}
RLD: Address Section Rld-type Referencing
Symbol
--
vtable for std::ctype [16]ER PR
ctype_configure_char.cc(/tmp/gcc-build/prev-powerpc-ibm-aix4.3.2.0/libstdc++-v3/src/.libs/libstdc++.a[ctype_configure_char.o])
08a4 .dataR_POS[775]
<_ZTVSt5ctypeIcE.P8>
ER: The return code is 8.
ld: 0711-317 ERROR: Undefined symbol: vtable for std::ctype
collect2: error: ld returned 8 exit status
Seems like another issue in the vein of bug 52887. I can't make heads or tails
of C++ at this level; would another instantiation do the trick here?
[Bug libstdc++/53339] unordered_map::iterator requires Value to be complete type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53339 --- Comment #19 from Eugene Toder 2012-05-16 02:21:07 UTC --- Fair point, noted. I believe ideas are not copyrightable, though.
[Bug c++/53368] [4.7/4.8 regression] c++11 reject-valid-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53368 Jonathan Wakely changed: What|Removed |Added CC||fabien at gcc dot gnu.org --- Comment #1 from Jonathan Wakely 2012-05-16 02:14:20 UTC --- are you sure this isn't just another dup of PR 52841 ?
[Bug libstdc++/53339] unordered_map::iterator requires Value to be complete type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53339 --- Comment #18 from Jonathan Wakely 2012-05-16 02:12:31 UTC --- (In reply to comment #16) > I was hoping to avoid copyright assignment by having someone else > do the work :) That's OK, but in that case I think (and this is just IMHO) it's better if you don't post a series of patches. Ideally we'd like you to sign a copyright assignment and contribute, but if you won't or can't contribute your code then IMHO you shouldn't offer it in the form of patches, because if we can't accept it then even reviewing your patch might make it tricky for us to implement the suggestion in a similar way (did we use your code? copy your idea? do we need to get a lawyer to decide if a change we make is based on your non-assigned work? ... I don't want to have to even ask those questions, let alone answer them!)
[Bug libitm/53008] abort in _ITM_getTMCloneSafe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53008 --- Comment #6 from Dave Boutcher 2012-05-16 01:43:51 UTC --- Thanks for the testcase Patrick. Let me dig into the pr51516.C failure before I resubmit the patch with the testcase. Torvald, as Patrick said, this seems to be purely a gcc issue...no libtm problems I can see
[Bug rtl-optimization/53180] [4.8 Regression] Revision 186378 generates incorrect code for cpu2006 416.gamess
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53180 Bernd Schmidt changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #3 from Bernd Schmidt 2012-05-16 01:38:55 UTC --- Fixed (r187495)
[Bug c/53369] Integral promotion with ~ operator - Different behavior for signed and unsigned char.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53369
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
--- Comment #3 from Andrew Pinski 2012-05-16
00:11:53 UTC ---
signed char a = 1 << 7;
unsigned char b = 1 << 7;
printf("%hd %hu\n", ~a, ~b);
let's see ~a is really ~(int)a. Likewise ~b is really ~(int)b.
#define printf __builtin_printf
int main(void)
{
signed char a = 1 << 7;
unsigned char b = 1 << 7;
printf("%x %x\n", ~a, ~b);
}
--- CUT
7f ff7f
This is the correct behavior. As (int)(unsigned char)a does a zero extend as
the unsigned char fits directly in an int.
Think of this way. The value from unsigned char and signed char are unchanged
when promoted into int. So with the first one you get -128 and the second case
you get 128.
and then you take the ~ and you get 127 and (~(1<<7)) .
[Bug c/53369] Integral promotion with ~ operator - Different behavior for signed and unsigned char.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53369 Rahul Ramachandran changed: What|Removed |Added Attachment #27414|0 |1 is obsolete|| --- Comment #2 from Rahul Ramachandran 2012-05-16 00:05:02 UTC --- Created attachment 27415 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27415 The assemply file
[Bug c/53369] Integral promotion with ~ operator - Different behavior for signed and unsigned char.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53369 --- Comment #1 from Rahul Ramachandran 2012-05-16 00:03:58 UTC --- Created attachment 27414 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27414 The assemply file
[Bug c/53369] New: Integral promotion with ~ operator - Different behavior for signed and unsigned char.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53369
Bug #: 53369
Summary: Integral promotion with ~ operator - Different
behavior for signed and unsigned char.
Classification: Unclassified
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rahulnitk2...@gmail.com
Created attachment 27413
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27413
The preprocessed file
I face a problem when i use bitwise ~ operator on signed char. With unsigned
char, it works as per the K&R ANSI C specification.
Here is the code snippet.
signed char a = 1 << 7;
unsigned char b = 1 << 7;
printf("%hd %hu\n", ~a, ~b);
Output for the program is shown as: 127 65407.
As per the integral promotion concept, a char variable whether signed or
unsigned will be converted to int before performing an operation on it.
So before performing (~a), a will be converted to int and will have 32 bits
(In my machine int is 32 bit). So ~a should result in 0XFF7F. So when i
print ~a it should result in 0XFF7F as format specifier is "%hd". Instead it is
only 127(0X7F).
Similarly for unsigned char b, ~b should result in 0XFF7F and output should
be 65407(0XFF7F) as i used "%hu" as format specifier. That is printed
correctly.
I am using GCC version 4.5.2 on Ubuntu.
Any suggestions?
Thanks
Rahul
---
Code:
#include
#include
int main(void)
{
signed char a = 1 << 7;
unsigned char b = 1 << 7;
printf("%hd %hu\n", ~a, ~b);
return(EXIT_SUCCESS);
}
Compilation command used: gcc -Wall test.c (No warnings).
Output: 127 65407
--
Other Deatils:
--
rahul@ubuntu:~/sample$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.5.2-8ubuntu4' --with-bugurl=file:///usr/share/doc/gcc-4.5/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.5 --enable-shared --enable-multiarch
--with-multiarch-defaults=x86_64-linux-gnu --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib/x86_64-linux-gnu
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.5 --libdir=/usr/lib/x86_64-linux-gnu
--enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-plugin --enable-gold --enable-ld=default
--with-plugin-ld=ld.gold --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.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu4)
--
rahul@ubuntu:~/sample$ gcc -v -save-temps -Wall test.c
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.5.2-8ubuntu4' --with-bugurl=file:///usr/share/doc/gcc-4.5/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.5 --enable-shared --enable-multiarch
--with-multiarch-defaults=x86_64-linux-gnu --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib/x86_64-linux-gnu
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.5 --libdir=/usr/lib/x86_64-linux-gnu
--enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-plugin --enable-gold --enable-ld=default
--with-plugin-ld=ld.gold --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.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu4)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-mtune=generic' '-march=x86-64'
/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2/cc1 -E -quiet -v test.c
-D_FORTIFY_SOURCE=2 -mtune=generic -march=x86-64 -Wall -fpch-preprocess
-fstack-protector -o test.i
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2/../../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2/include
/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gn
[Bug ada/52494] s-taprop-dummy.adb does not define subpackage Specific used in s-tpoaal.sdb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52494 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.7.1 --- Comment #6 from Eric Botcazou 2012-05-15 22:38:45 UTC --- Patch applied.
[Bug ada/52494] s-taprop-dummy.adb does not define subpackage Specific used in s-tpoaal.sdb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52494 --- Comment #5 from Eric Botcazou 2012-05-15 22:35:38 UTC --- Author: ebotcazou Date: Tue May 15 22:35:33 2012 New Revision: 187564 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187564 Log: PR ada/52494 * s-taprop-dummy.adb (Specific): New package. Modified: branches/gcc-4_7-branch/gcc/ada/ChangeLog branches/gcc-4_7-branch/gcc/ada/s-taprop-dummy.adb
[Bug ada/52494] s-taprop-dummy.adb does not define subpackage Specific used in s-tpoaal.sdb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52494 --- Comment #4 from Eric Botcazou 2012-05-15 22:34:11 UTC --- Author: ebotcazou Date: Tue May 15 22:33:58 2012 New Revision: 187562 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187562 Log: PR ada/52494 * s-taprop-dummy.adb (Specific): New package. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/s-taprop-dummy.adb
[Bug c++/53368] New: [4.7/4.8 regression] c++11 reject-valid-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53368
Bug #: 53368
Summary: [4.7/4.8 regression] c++11 reject-valid-code
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ppluzhni...@google.com
We've noticed this using 4.7 branch, confirmed exists in current trunk,
does not appear to exist in 4.6.
/// --- cut ---
// g++ -c -std=c++11 t.cc
// Fails: g++ (GCC) 4.8.0 20120515 (experimental)
class Message; // comment out -> works
namespace proto {
struct Message {
virtual void Copy(const Message&);
};
}
struct MessageSet: public proto::Message {
// using Message::Copy; // this works
using proto::Message::Copy;
};
/// --- cut ---
$ g++ -c t.cc
$ g++ -c t.cc -std=c++11
t.cc:15:25: error: type 'Message' is not a base type for type 'MessageSet'
using proto::Message::Copy;
^
[Bug libitm/53008] abort in _ITM_getTMCloneSafe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53008 --- Comment #5 from Patrick Marlier 2012-05-15 22:23:54 UTC --- Created attachment 27412 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27412 testcase for gcc testsuite The problem is not into libitm. Attached a testcase for testsuite (gcc/testsuite/gcc.dg/tm/indirect-3.c). Note that with your patch, the tm testsuite fails. pr51516.C fails because the original function is output and not only the clone (only the clone is required). I am not sure the way to properly fix it. Thanks for having a look at the problem! -- Patrick Marlier
[Bug target/53362] gcc 4.7 generates invalid code with -O3 and -mtune=bdver2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53362
--- Comment #4 from Valerio Aimale 2012-05-15
22:15:19 UTC ---
On 5/15/12 11:43 AM, pinskia at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53362
>
> Andrew Pinski changed:
>
> What|Removed |Added
>
> Status|UNCONFIRMED |WAITING
> Last reconfirmed||2012-05-15
>Component|c |target
> Ever Confirmed|0 |1
> Severity|major |normal
>
> --- Comment #1 from Andrew Pinski 2012-05-15
> 17:43:29 UTC ---
> Can you attach a testcase that can compile and run?
>
Andrew,
I have been unable to come up with a test case, but I dug up more
information. R has a "just in time" compiler that compiles R code to a
virtual machine (a la java like). The SIGSEGV, which happens when
optimizing with -O3 -march=bdver1, happens in the JIT intepreter.
The assembler code I pointed to in the original bug-report is not where
the SIGSEGV happens.
Here's the code, I had to do some major digging with gdb to find the
problem.
the JIT essential has a switch { case OPERAND 1: ; case OPERAND 2: ... }
with a program counter called pc
This snippet
---
BEGIN_MACHINE {
OP(BCMISMATCH, 0): error(_("byte code version mismatch"));
OP(RETURN, 0): value = GETSTACK(-1); goto done;
OP(GOTO, 1):
{
int label = GETOP();
BC_CHECK_SIGINT();
pc = codebase + label;
NEXT();
}
---
which, when preprocessed, translates to:
--
(__extension__ ({goto *(*pc++).v;})); init: { loop: switch(which++) {
case BCMISMATCH_OP: opinfo[BCMISMATCH_OP].addr = (__extension__
&&op_BCMISMATCH); opinfo[BCMISMATCH_OP].argc = (0); goto loop;
op_BCMISMATCH: Rf_error(dcgettext (((void *)0), "byte code version
mismatch", __LC_MESSAGES));
case RETURN_OP: opinfo[RETURN_OP].addr = (__extension__
&&op_RETURN); opinfo[RETURN_OP].argc = (0); goto loop; op_RETURN: value
= (*(R_BCNodeStackTop + (-1))); goto done;
case GOTO_OP: opinfo[GOTO_OP].addr = (__extension__ &&op_GOTO);
opinfo[GOTO_OP].argc = (1); goto loop; op_GOTO:
{
int label = (*pc++).i;
do { if (++evalcount > 1000) { R_CheckUserInterrupt(); evalcount = 0;
} } while (0);
pc = codebase + label;
(__extension__ ({goto *(*pc++).v;}));
}
case BRIFNOT_OP: opinfo[BRIFNOT_OP].addr = (__extension__
&&op_BRIFNOT); opinfo[BRIFNOT_OP].argc = (2); goto loop; op_BRIFNOT:
{
int callidx = (*pc++).i;
int label = (*pc++).i;
-
now the line
goto *(*pc++).v;
when compiled as -O3 -march=bdver1
translates to
0x7786bb4e <+366>:lea0x38(%r15),%rbp
0x7786bb52 <+370>:data32 data32 data32 data32 nopw
%cs:0x0(%rax,%rax,1)
0x7786bb60 <+384>:jmpq *%rax
0x7786bb62 <+386>:nopw 0x0(%rax,%rax,1)
I believe that the goto becomes jmpq *%rax, with nopw before and
after being just fillers for 64bit alignment (not sure though I don't
understand those nopw)
When executing, the code had to run some bytecode; before executing
0x7786bb60 the return rip correctly contains 0x7787ad4d
(gdb) stepi
0x7786bb604033 BEGIN_MACHINE {
(gdb) info frame 0
Stack frame at 0x7ffeff20:
rip = 0x7786bb60 in bcEval (eval.c:4033); saved rip 0x7787ad4d
called by frame at 0x7fff0110
source language c.
Arglist at 0x7ffef978, args: body=body@entry=0x153ecb0,
rho=rho@entry=0x1540150, useCache=TRUE
Locals at 0x7ffef978, Previous frame's sp is 0x7ffeff20
Saved registers:
rbx at 0x7ffefee8, rbp at 0x7ffefef0, r12 at 0x7ffefef8,
r13 at 0x7ffeff00, r14 at 0x7ffeff08, r15 at 0x7ffeff10, rip
at 0x7ffeff18
(gdb) info program
Using the running image of child Thread 0x77fde780 (LWP 25913).
Program stopped at 0x7786bb60.
once i execute 0x7786bb60
(gdb) stepi
bcEval (useCache=FALSE, rho=0x0, body=0x0) at eval.c:4217
4217OP(GETFUN, 1):
(gdb) info frame 0
Stack frame at 0x7ffefe90:
rip = 0x77890f97 in bcEval (eval.c:4217); saved rip 0x7ffeff30
called by frame at 0x7ffefe98
source language c.
Arglist at 0x7ffef978, args: useCache=FALSE, rho=0x0, body=0x0
Locals at 0x7ffef978, Previous frame's sp is 0x7ffefe90
Saved registers:
rbx at 0x7ffefe58, rbp at 0x7ffefe60, r12 at 0x7ffefe68,
r13 at 0x7ffefe70, r14 at 0x7ffefe78, r15 at 0x7ffefe80, rip
at 0x7ffefe88
the return rip is 0x7ffeff30, which is outside the program virtual
address space and gives the SIGSEGV when the next retq is executed.
When, instead, I compile with "-O -march=bdver1"
that line, goto *(*pc++).v; , compiles to
209d: 48 83 c3
[Bug target/53362] gcc 4.7 generates invalid code with -O3 and -mtune=bdver2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53362
--- Comment #3 from Valerio Aimale 2012-05-15
22:13:47 UTC ---
First of all, I made a mistake. The FX-8150 (which is family 14h) requires
-march=bdver1 not bdver2. The SIGSEGV, however, happens even with bdver1
To reproduce, compile R with
CC=gcc-4.7\
CXX=g++-4.7 \
OBJC=gcc-4.7 \
FC=gfortran-4.7 \
F77=gfortran-4.7 \
CFLAGS="-g -O3 -march=bdver1"\
CXXFLAGS="-g -O3 -march=bdver1" \
OBJCFLAGS="-g -O3 -march=bdver1" \
FCFLAGS="-g -O3 -march=bdver1" \
FFLAGS="-g -O3 -march=bdver1"\
./configure \
--enable-R-shlib \
--enable-threads=posix\
--with-readline \
--with-system-pcre\
--prefix=/usr/local/pkg/R-2.15.0-k15 \
--with-x \
--with-system-zlib\
--with-cairo \
--with-jpeglib\
--with-blas \
--with-lapack \
--with-tcltk \
--with-libpng
Second, the SIGSEGV actually happens inside eval.c at bcEval(). Here's a more
detailed description:
R has a "just in time" compiler that compiles R code to a virtual machine (a la
java like). The SIGSEGV, which happens when optimizing with -O3 -march=bdver1,
happens in the JIT intepreter.
The JIT essential has a switch { case OPERAND 1: ; case OPERAND 2: ... } with a
program counter called pc
This snippet
---
BEGIN_MACHINE {
OP(BCMISMATCH, 0): error(_("byte code version mismatch"));
OP(RETURN, 0): value = GETSTACK(-1); goto done;
OP(GOTO, 1):
{
int label = GETOP();
BC_CHECK_SIGINT();
pc = codebase + label;
NEXT();
}
---
which, when preprocessed, translates to:
--
(__extension__ ({goto *(*pc++).v;})); init: { loop: switch(which++) {
case BCMISMATCH_OP: opinfo[BCMISMATCH_OP].addr = (__extension__
&&op_BCMISMATCH); opinfo[BCMISMATCH_OP].argc = (0); goto loop; op_BCMISMATCH:
Rf_error(dcgettext (((void *)0), "byte code version mismatch", __LC_MESSAGES));
case RETURN_OP: opinfo[RETURN_OP].addr = (__extension__ &&op_RETURN);
opinfo[RETURN_OP].argc = (0); goto loop; op_RETURN: value = (*(R_BCNodeStackTop
+ (-1))); goto done;
case GOTO_OP: opinfo[GOTO_OP].addr = (__extension__ &&op_GOTO);
opinfo[GOTO_OP].argc = (1); goto loop; op_GOTO:
{
int label = (*pc++).i;
do { if (++evalcount > 1000) { R_CheckUserInterrupt(); evalcount = 0; } }
while (0);
pc = codebase + label;
(__extension__ ({goto *(*pc++).v;}));
}
case BRIFNOT_OP: opinfo[BRIFNOT_OP].addr = (__extension__ &&op_BRIFNOT);
opinfo[BRIFNOT_OP].argc = (2); goto loop; op_BRIFNOT:
{
int callidx = (*pc++).i;
int label = (*pc++).i;
-
now the line
goto *(*pc++).v;
when compiled as -O3 -march=bdver1
translates to
0x7786bb4e <+366>:lea0x38(%r15),%rbp
0x7786bb52 <+370>:data32 data32 data32 data32 nopw
%cs:0x0(%rax,%rax,1)
0x7786bb60 <+384>:jmpq *%rax
0x7786bb62 <+386>:nopw 0x0(%rax,%rax,1)
I believe that the goto becomes jmpq *%rax, with nopw before and after being
just fillers for 64bit alignment (not sure though I don't understand those
nopw)
When executing, the code had to run some bytecode; before executing
0x7786bb60 the return rip correctly contains 0x7787ad4d
(gdb) stepi
0x7786bb604033 BEGIN_MACHINE {
(gdb) info frame 0
Stack frame at 0x7ffeff20:
rip = 0x7786bb60 in bcEval (eval.c:4033); saved rip 0x7787ad4d
called by frame at 0x7fff0110
source language c.
Arglist at 0x7ffef978, args: body=body@entry=0x153ecb0,
rho=rho@entry=0x1540150, useCache=TRUE
Locals at 0x7ffef978, Previous frame's sp is 0x7ffeff20
Saved registers:
rbx at 0x7ffefee8, rbp at 0x7ffefef0, r12 at 0x7ffefef8, r13 at
0x7ffeff00, r14 at 0x7ffeff08, r15 at 0x7ffeff10, rip at
0x7ffeff18
(gdb) info program
Using the running image of child Thread 0x77fde780 (LWP 25913).
Program stopped at 0x7786bb60.
once i execute 0x7786bb60
(gdb) stepi
bcEval (useCache=FALSE, rho=0x0, body=0x0) at eval.c:4217
4217OP(GETFUN, 1):
(gdb) info frame 0
Stack frame at 0x7ffefe90:
rip = 0x77890f97 in bcEval (eval.c:4217); saved rip 0x7ffeff30
called by frame at 0x7ffefe98
source language c.
Arglist at 0x7ffef978, args: useCache=FALSE, rho=0x0, body=0x0
Locals at 0x7ffef978, Previous frame's sp is 0x7ffefe90
Saved registers:
rbx at 0x7ffefe58, rbp at 0x7ffefe60, r12 at 0x7ffefe68, r13 at
0x7ffefe70, r14 at 0x7ffefe78, r15 at 0x7ffefe80, rip at
0x7ffefe88
the return rip is 0x7ffeff30, which is outside the program virtual address
space and gives the SIGSEGV when the next retq is executed.
When, instead, I compile with "-O -march=bdver1"
that line, goto *(*pc++).v; , compile
[Bug libstdc++/53367] FMOD Standar C++ library
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53367 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||MOVED --- Comment #1 from Andrew Pinski 2012-05-15 22:07:22 UTC --- This calls directly fmodl which is not part of either libstdc++ or GCC. Please report it to glibc since you are using glibc as your libc.
[Bug libstdc++/53367] New: FMOD Standar C++ library
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53367
Bug #: 53367
Summary: FMOD Standar C++ library
Classification: Unclassified
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: joaquinmonl...@gmail.com
Created attachment 27411
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27411
the preprocessed file (*.i*) that triggers the bug???
/*
Exact version of GCC: gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5)
System Type: 32BITS --target=i486-linux-gnu.
Options given when GCC was configured/build:
The complete command line that triggers the bug: "g++ -lm fmod.cpp -o fmod"
The compiler output (error messages, warnings, etc.): None.
the preprocessed file (*.i*) that triggers the bug, generated by adding
-save-temps to the complete compilation command: As attachment
http://en.tiraecol.net/modules/comic/cache/images/tiraecol_en-5.png
*/
#include
#include
using namespace std;
const long double _1PI2 = 1.5707963267948966193L; // PI/2
const long double _3PI2 = 4.712388980384689858L; // 3*PI/2
long double my_fmod(long double numerator, long double denominator){
return numerator-((int)(numerator/denominator))*denominator;
}
int main(){
// GCC Standard Library fmod
cout << fmod(_3PI2,_1PI2) << endl;
// RETURNS 1.0842e-19 !!BUG BUG BUG!!
// my_fmod
cout << my_fmod(_3PI2,_1PI2) << endl;
// RETURNS 0
}
[Bug tree-optimization/53366] New: wrong code generation by tree vectorizer using AVX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53366 Bug #: 53366 Summary: wrong code generation by tree vectorizer using AVX Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: mar...@mpa-garching.mpg.de Created attachment 27410 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27410 Testcase demonstrating the problem The attached code is the reduction of a numerical library. It should print "2.816937e+08" if executed correctly. Using the current head of the 4.7 branch and trunk, and compiling on an Intel Core i3-2120 using gcc testcase.c -std=c99 -g -O3 -march=native -fno-tree-vectorize everything works as expected. When omitting the "-fno-tree-vectorize", random results are printed, and a different number is generated for every run. The testcase is the result of several hours' reduction. Currently I don't have time to reduce it further.
[Bug testsuite/53365] New: gcc.target/i386/pr53249.c FAILs for -m64 on Solaris 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53365 Bug #: 53365 Summary: gcc.target/i386/pr53249.c FAILs for -m64 on Solaris 10 Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassig...@gcc.gnu.org ReportedBy: gsean...@gmail.com See test results for build of trunk revision 187423 @ http://gcc.gnu.org/ml/gcc-testresults/2012-05/msg01505.html
[Bug c++/53364] New: [4.7/4.8 Regression] Wrong code generation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53364
Bug #: 53364
Summary: [4.7/4.8 Regression] Wrong code generation
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: f...@fuhm.net
On the following code, minimized from a much larger program:
test.cpp
=
#include
struct A
{
int m_x;
explicit A(int x) : m_x(x) {}
operator int() const { return m_x; }
};
struct B : public A
{
public:
explicit B(int x)
: A(x) {}
};
int data = 1;
int main() {
B b = B(10);
b = std::min(b, B(data));
return int(b);
}
=
Running: g++ -O2 -c test.cpp
With gcc version: g++ (Debian 4.7.0-8) 4.7.0
(which says it's built from r187339 on the gcc 4.7 branch).
On architecture: x86-64
The program ought to return 1, but instead, it returns randomness. Running
valgrind confirms that this program is using uninitialized values.
Testing with the debian gcc-snapshot package (trunk rev 187013) shows the same
bug.
Testing with the debian gcc 4.6.3 package does not show the bug.
Using -O1 does not show the bug.
Using -O1 -fstrict-aliasing shows the bug.
[Bug web/51195] upgrade request for viewvc to version 1.1.13
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51195 Sean McGovern changed: What|Removed |Added Summary|viewcvs can't display |upgrade request for viewvc |gcc/testsuite/gcc.dg/ |to version 1.1.13 Severity|normal |enhancement
[Bug debug/53363] g++.dg/debug/dwarf2/thunk1.C FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53363 --- Comment #1 from Jason Merrill 2012-05-15 19:09:37 UTC --- Yes, the test should only run in 32-bit mode. For me, on i686-unknown-linux-gnu the test passes. What are the uses of LFB3 on Solaris for?
[Bug bootstrap/53348] Conflicting fast-integer types on AIX: vs. gcc/config/rs6000/aix-stdint.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53348 --- Comment #6 from Daniel Richard G. 2012-05-15 19:01:45 UTC --- My first thought had been to put in AIX-version-dependent cpp conditionals in aix-stdint.h, but admittedly, that would have been an ugly way to go. I have an AIX 5.3 system here as well. There is no sys/inttypes.h, but [u]int_fastNN_t is defined in sys/stdint.h, and all the types are the same size as [u]intNN_t. This is presumably the case for newer AIXes as well. Fixincluding sys/inttypes.h should be safe IMO, and any bad fallout from that should be limited to AIX releases that still have this header, and use the unequal-sized-types, and somehow depend on those types. I'll double-check that this isn't the case for 4.3.
[Bug target/53362] gcc 4.7 generates invalid code with -O3 and -mtune=bdver2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53362 --- Comment #2 from Valerio Aimale 2012-05-15 18:07:01 UTC --- Andrew, thank you for your email. I'll extract some code from the R code base and generate a test case. Valerio On 5/15/12 11:43 AM, pinskia at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53362 > > Andrew Pinski changed: > > What|Removed |Added > > Status|UNCONFIRMED |WAITING > Last reconfirmed||2012-05-15 >Component|c |target > Ever Confirmed|0 |1 > Severity|major |normal > > --- Comment #1 from Andrew Pinski 2012-05-15 > 17:43:29 UTC --- > Can you attach a testcase that can compile and run? >
[Bug bootstrap/53348] Conflicting fast-integer types on AIX: vs. gcc/config/rs6000/aix-stdint.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53348 David Edelsohn changed: What|Removed |Added Status|RESOLVED|WAITING Last reconfirmed||2012-05-15 Resolution|WONTFIX | Ever Confirmed|0 |1 --- Comment #5 from David Edelsohn 2012-05-15 17:53:00 UTC --- I am willing to review patches, although I do not have access to AIX 4.3 systems to test. More recent versions of AIX define inttypes that correspond to the current definition in GCC. The 4.3.2 definitions are not invalid, but probably are not the best choices or consistent with current definitions. Changing AIX headers with fixincludes may introduce inconsistencies. This could be fixed in aix-stdint.h, but I am concerned about complicating that file to support current GCC on a 15 year old system that few people are interested in. This isn't zero cost for future maintenance. You can change aix-stdint.h yourself and continue to apply the patches if you care about building GCC 4.8 and later.
[Bug c++/53361] Could not convert ‘{0, 0, 0}’ from ‘’ to ‘std::array’
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53361 --- Comment #1 from Andrew Pinski 2012-05-15 17:48:58 UTC --- Works on the trunk for me ...
[Bug target/53362] gcc 4.7 generates invalid code with -O3 and -mtune=bdver2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53362 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-05-15 Component|c |target Ever Confirmed|0 |1 Severity|major |normal --- Comment #1 from Andrew Pinski 2012-05-15 17:43:29 UTC --- Can you attach a testcase that can compile and run?
[Bug target/53359] [4.8 regression] undefined reference to `__gnu_cxx::__numeric_traits_integer::__min'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53359 Andreas Schwab changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #1 from Andreas Schwab 2012-05-15 17:40:50 UTC --- ff2a5adaa72fef87cac689a40c23258a30b304c8 is the first bad commit commit ff2a5adaa72fef87cac689a40c23258a30b304c8 Author: hubicka Date: Sun Apr 22 21:28:07 2012 + * lto-symtab.c (lto_varpool_replace_node): Do not merge needed flags. * cgraphbuild.c (record_reference, record_type_list, mark_address, mark_load, mark_store): Do not mark varpool nodes as needed. * cgraph.c (cgraph_new_nodes): Remove. ... git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@186687 138bc75d-0d04-0410-961f-82ee72b054a4
[Bug bootstrap/53348] Conflicting fast-integer types on AIX: vs. gcc/config/rs6000/aix-stdint.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53348 --- Comment #4 from Daniel Richard G. 2012-05-15 17:35:20 UTC --- (In reply to comment #3) > AIX 4.3.2 was announced in 1998 and end of service in 2003. The AIX header is > wrong and was fixed in later versions. You have a work-around. I am not aware > of anyone else trying to use recent versions of GCC on ancient versions of > AIX. > Customers who continue to use an old version generally freeze all software on > the system. Patches are welcome. So if I understand correctly: GCC may still nominally support AIX 4.3, but no one here really wants to spend time dealing with it. If that's the case, could you set these PRs to WAITING/IN_PROGRESS, and assign them to me? I'll gladly try my hand at some patches, as long as someone here is willing to review them and get them in if they're good. I was under the impression that fast-integer types could be N bits or more in size, so e.g. "typedef int32_t int_fast16_t" would be valid (and may make sense for the architecture). So you're saying that's not it, and sys/inttypes.h needs fixincluding?
[Bug c++/53322] Wunused-local-typedefs is not enabled by Wall or Wunused
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53322 Dodji Seketeli changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-05-15 AssignedTo|unassigned at gcc dot |dodji at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug middle-end/38219] gcc.dg/tree-ssa/vrp47.c fails on powerpc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38219 Sean McGovern changed: What|Removed |Added CC|gseanmcg at gmail dot com | --- Comment #15 from Sean McGovern 2012-05-15 17:00:25 UTC --- As of 186222, no longer seems to fail on i386-pc-solaris2.10
[Bug target/53358] [4.7/4.8 Regression] ICE due to TARGET_READ_MODIFY_WRITE peephole2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53358 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Jakub Jelinek 2012-05-15 16:49:59 UTC --- Fixed.
[Bug libitm/53008] abort in _ITM_getTMCloneSafe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53008 torvald at gcc dot gnu.org changed: What|Removed |Added CC||torvald at gcc dot gnu.org --- Comment #4 from torvald at gcc dot gnu.org 2012-05-15 16:18:00 UTC --- So, is there still a libitm issue even with your GCC patch?
[Bug middle-end/32911] Function __attribute__ ((idempotent))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32911 Jan Hubicka changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #4 from Jan Hubicka 2012-05-15 15:59:40 UTC --- Also note that internally we have looping const/looping pure that can be optimized in this manner, so to large degree this is just matter of exporting this out to user attributes + declaring sane behaviour on functions returning void.
[Bug middle-end/32911] Function __attribute__ ((idempotent))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32911 --- Comment #3 from Jan Hubicka 2012-05-15 15:57:29 UTC --- Note that I was thinking of similar attribute for C++ iostream initialization code. Currently every unit including iostream gets a call to the iostream constructor. With LTO we merge the constructors together and get _alot_ of redundant calls to the construction code. Declaring that only first call is needed would save some (quite minor) startup overehead. (overhead of iostream startup is large, but after inlning all together it boils down to cca 7000 redundant calls in Mozilla startup that executes quite quickly)
Re: [Bug middle-end/32911] Function __attribute__ ((idempotent))
Note that I was thinking of similar attribute for C++ iostream initialization code. Currently every unit including iostream gets a call to the iostream constructor. With LTO we merge the constructors together and get _alot_ of redundant calls to the construction code. Declaring that only first call is needed would save some (quite minor) startup overehead. (overhead of iostream startup is large, but after inlning all together it boils down to cca 7000 redundant calls in Mozilla startup that executes quite quickly)
[Bug middle-end/32911] Function __attribute__ ((idempotent))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32911 Colin Walters changed: What|Removed |Added CC||walters at verbum dot org --- Comment #2 from Colin Walters 2012-05-15 15:51:13 UTC --- More information about GObject requirements here: https://bugzilla.gnome.org/show_bug.cgi?id=64994
[Bug debug/53363] New: g++.dg/debug/dwarf2/thunk1.C FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53363 Bug #: 53363 Summary: g++.dg/debug/dwarf2/thunk1.C FAILs Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org CC: ja...@gcc.gnu.org Host: i386-pc-solaris2.*, i686-unknown-linux-gnu, i386-apple-darwin11.3.0 Target: i386-pc-solaris2.*, i686-unknown-linux-gnu, i386-apple-darwin11.3.0 Build: i386-pc-solaris2.*, i686-unknown-linux-gnu, i386-apple-darwin11.3.0 The new g++.dg/debug/dwarf2/thunk1.C test FAILs in various configurations, e.g. i386-pc-solaris2.*: FAIL: g++.dg/debug/dwarf2/thunk1.C scan-assembler-times LFB3 1 FAIL: g++.dg/debug/dwarf2/thunk1.C scan-assembler-times LFB3 1 both for 32 and 64-bit tests. i686-unknown-linux-gnu: 64-bit test only. In the 32-bit Solaris/x86 case, LFB3 occurs 5 times: .LFB3: .long .LFB3 .long .LFE3-.LFB3 .long .LFB3@GOTOFF .long .LFE3-.LFB3 In the 64-bit case, it doesn't occur at all. I cannot tell for sure what the intent is: should this test only run for 32-bit? Rainer
[Bug c/53362] New: gcc 4.7 generates invalid code with -O3 and -mtune=bdver2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53362
Bug #: 53362
Summary: gcc 4.7 generates invalid code with -O3 and
-mtune=bdver2
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vale...@aimale.com
Hello,
I'm compiling R 2.15.0 on an AMD FX-8150, trying to take advantage of the
bdver2 platform.
The function jumpfun() in src/main/context.c is
/* jumpfun - jump to the named context */
===
static void jumpfun(RCNTXT * cptr, int mask, SEXP val)
{
Rboolean savevis = R_Visible;
/* run onexit/cend code for all contexts down to but not including
the jump target */
PROTECT(val);
R_run_onexits(cptr);
UNPROTECT(1);
R_Visible = savevis;
R_ReturnedValue = val;
R_GlobalContext = cptr; /* this used to be set to
cptr->nextcontext for non-toplevel
jumps (with the context set back at the
SETJMP for restarts). Changing this to
always using cptr as the new global
context should simplify some code and
perhaps allow loops to be handled with
fewer SETJMP's. LT */
R_restore_globals(R_GlobalContext);
LONGJMP(cptr->cjmpbuf, mask);
}
with LONGJMP being
# define LONGJMP(x,i) siglongjmp(x,i)
With -O3 -mtune=bdver2 jumpfun() is compiled to:
0360 :
360: 41 56 push %r14
362: 41 55 push %r13
364: 41 89 f5mov%esi,%r13d
367: 41 54 push %r12
369: 49 89 d4mov%rdx,%r12
36c: 55 push %rbp
36d: 48 8b 2d 00 00 00 00mov0x0(%rip),%rbp# 374
374: 53 push %rbx
375: 48 89 fbmov%rdi,%rbx
378: 48 89 d7mov%rdx,%rdi
37b: 44 8b 75 00 mov0x0(%rbp),%r14d
37f: e8 00 00 00 00 callq 384
384: 48 89 dfmov%rbx,%rdi
387: e8 00 00 00 00 callq 38c
38c: bf 01 00 00 00 mov$0x1,%edi
391: e8 00 00 00 00 callq 396
396: 48 8b 05 00 00 00 00mov0x0(%rip),%rax# 39d
39d: 48 89 dfmov%rbx,%rdi
3a0: 44 89 75 00 mov%r14d,0x0(%rbp)
3a4: 4c 89 20mov%r12,(%rax)
3a7: 48 8b 05 00 00 00 00mov0x0(%rip),%rax# 3ae
3ae: 48 89 18mov%rbx,(%rax)
3b1: e8 00 00 00 00 callq 3b6
3b6: 48 8d 7b 10 lea0x10(%rbx),%rdi
3ba: 44 89 eemov%r13d,%esi
3bd: e8 00 00 00 00 callq 3c2
3c2: 66 66 66 66 66 66 2edata32 data32 data32 data32 data32 nopw
%cs:0x0(%rax,%rax,1)
3c9: 0f 1f 84 00 00 00 00
3d0: 00
3d1: 66 66 66 66 66 66 2edata32 data32 data32 data32 data32 nopw
%cs:0x0(%rax,%rax,1)
3d8: 0f 1f 84 00 00 00 00
3df: 00
with a SIGSEGV on 0x32c, while with -O -mtune=bdver2 compiles correctly to
228 :
228: 41 56 push %r14
22a: 41 55 push %r13
22c: 41 54 push %r12
22e: 55 push %rbp
22f: 53 push %rbx
230: 48 89 fbmov%rdi,%rbx
233: 41 89 f5mov%esi,%r13d
236: 48 89 d5mov%rdx,%rbp
239: 4c 8b 25 00 00 00 00mov0x0(%rip),%r12# 240
240: 45 8b 34 24 mov(%r12),%r14d
244: 48 89 d7mov%rdx,%rdi
247: e8 00 00 00 00 callq 24c
24c: 48 89 dfmov%rbx,%rdi
24f: e8 00 00 00 00 callq 254
254: bf 01 00 00 00 mov$0x1,%edi
259: e8 00 00 00 00 callq 25e
25e: 45 89 34 24 mov%r14d,(%r12)
262: 48 8b 05 00 00 00 00mov0x0(%rip),%rax# 269
269: 48 89 28mov%rbp,(%rax)
26c: 48 8b 05 00 00 00 00mov0x0(%rip),%rax# 273
273: 48 89 18mov%rbx,(%rax)
276: 48 89 dfmov%rbx,%rdi
279: e8 00 00 00 00 callq 27e
27e:
[Bug c/11586] after call sigaction, system() return wrong status
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11586 Paolo Carlini changed: What|Removed |Added CC|gcc-bugs at gcc dot gnu.org | --- Comment #3 from Paolo Carlini 2012-05-15 15:21:19 UTC --- Sorry typoed PR # (meant to be 11856),
[Bug target/53358] [4.7/4.8 Regression] ICE due to TARGET_READ_MODIFY_WRITE peephole2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53358 --- Comment #3 from Jakub Jelinek 2012-05-15 15:21:47 UTC --- Author: jakub Date: Tue May 15 15:21:38 2012 New Revision: 187545 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187545 Log: PR target/53358 * config/i386/i386.md (*addqi_2 peephole with QImode addition): Check that operands[2] is either immediate, or q_regs_operand. * gcc.dg/pr53358.c: New test. Added: branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/pr53358.c Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/config/i386/i386.md branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug c++/11856] unsigned warning in template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11856 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #34 from Paolo Carlini 2012-05-15 15:20:28 UTC --- This is fixed in mainline in Rev. 187542 with this commit: /cp 2012-05-15 Paolo Carlini PR c++/11856 * pt.c (tsubst_copy_and_build): Increase / decrease c_inhibit_evaluation_warnings around build_x_binary_op call. /c-family 2012-05-15 Paolo Carlini PR c++/11856 * c-common.c (shorten_compare): Check c_inhibit_evaluation_warnings. /testsuite 2012-05-15 Paolo Carlini PR c++/11856 * g++.dg/warn/Wtype-limits.C: Don't warn in templates. * g++.dg/warn/Wtype-limits-Wextra.C: Likewise.
[Bug target/53358] [4.7/4.8 Regression] ICE due to TARGET_READ_MODIFY_WRITE peephole2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53358 --- Comment #2 from Jakub Jelinek 2012-05-15 15:19:22 UTC --- Author: jakub Date: Tue May 15 15:19:10 2012 New Revision: 187544 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187544 Log: PR target/53358 * config/i386/i386.md (*addqi_2 peephole with QImode addition): Check that operands[2] is either immediate, or q_regs_operand. * gcc.dg/pr53358.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr53358.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md trunk/gcc/testsuite/ChangeLog
[Bug c/11586] after call sigaction, system() return wrong status
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11586 --- Comment #2 from paolo at gcc dot gnu.org 2012-05-15 15:14:59 UTC --- Author: paolo Date: Tue May 15 15:14:49 2012 New Revision: 187542 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187542 Log: /cp 2012-05-15 Paolo Carlini PR c++/11586 * pt.c (tsubst_copy_and_build): Increase / decrease c_inhibit_evaluation_warnings around build_x_binary_op call. /c-family 2012-05-15 Paolo Carlini PR c++/11586 * c-common.c (shorten_compare): Check c_inhibit_evaluation_warnings. /testsuite 2012-05-15 Paolo Carlini PR c++/11586 * g++.dg/warn/Wtype-limits.C: Don't warn in templates. * g++.dg/warn/Wtype-limits-Wextra.C: Likewise. Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/warn/Wtype-limits-Wextra.C trunk/gcc/testsuite/g++.dg/warn/Wtype-limits.C
[Bug c++/53360] Problems with -std=gnu++0x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53360 --- Comment #1 from Marc Glisse 2012-05-15 15:00:58 UTC --- clang and gcc reject it, but intel and oracle accept it.
[Bug c++/53361] New: Could not convert ‘{0, 0, 0}’ from ‘’ to ‘std::array’
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53361
Bug #: 53361
Summary: Could not convert ‘{0, 0, 0}’ from ‘’ to ‘std::array’
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: roucaries.bastien+b...@gmail.com
Fail to compile:
#include
void function(std::array a)
{
}
int main()
{
// ok
std::array vec {0, 0, 0};
// error: could not convert '{"hello", "world", "test"}' to
'std::vector...'
function({0,0,0});
}
8.5/14,16:
The initialization that occurs in the form
T x = a;
as well as in argument passing, function return, throwing an exception
(15.1), handling an exception (15.3), and aggregate member initialization
(8.5.1) is called copy-initialization.
.
.
The semantics of initializers are as follows[...]: If the initializer is a
braced-init-list, the object is list-initialized (8.5.4).
So it seems a bug.
bastien
[Bug c++/53350] Internal compiler error when compiling boost/smart_ptr/intrusive_ptr.hpp 1.49
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53350 --- Comment #5 from Marc Glisse 2012-05-15 14:50:42 UTC --- You may first want to check whether you still get the bug with a more recent gcc version.
[Bug bootstrap/53351] Missing integer types when bootstrapping on AIX 4.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53351 David Edelsohn changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX --- Comment #2 from David Edelsohn 2012-05-15 13:48:03 UTC --- Patches welcome.
[Bug bootstrap/53348] Conflicting fast-integer types on AIX: vs. gcc/config/rs6000/aix-stdint.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53348 David Edelsohn changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX --- Comment #3 from David Edelsohn 2012-05-15 13:45:38 UTC --- AIX 4.3.2 was announced in 1998 and end of service in 2003. The AIX header is wrong and was fixed in later versions. You have a work-around. I am not aware of anyone else trying to use recent versions of GCC on ancient versions of AIX. Customers who continue to use an old version generally freeze all software on the system. Patches are welcome.
[Bug tree-optimization/53355] Autovectorization of a simple loop could be improved.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53355 --- Comment #3 from Richard Guenther 2012-05-15 13:19:06 UTC --- With the patch we now emit foo: .LFB0: .cfi_startproc movq%rdi, %rax salq$60, %rax sarq$63, %rax movq%rax, %rdx andl$1, %edx testl %edx, %edx je .L7 movsd .LC0(%rip), %xmm0 movl$9, %r10d movl$1, %r11d addsd (%rdi), %xmm0 movsd %xmm0, (%rdi) .L2: movl$10, %r8d andl$1, %eax subl%edx, %r8d movapd .LC1(%rip), %xmm1 movl%r8d, %esi leaq(%rdi,%rax,8), %rcx xorl%edx, %edx shrl%esi xorl%eax, %eax leal(%rsi,%rsi), %r9d .p2align 4,,10 .p2align 3 .L6: movapd (%rcx,%rax), %xmm0 addl$1, %edx addpd %xmm1, %xmm0 movapd %xmm0, (%rcx,%rax) addq$16, %rax cmpl%esi, %edx jb .L6 subl%r9d, %r10d cmpl%r9d, %r8d leal(%r11,%r9), %edx je .L1 leal-1(%r10), %ecx movslq %edx, %rdx leaq0(,%rdx,8), %rax movsd .LC0(%rip), %xmm1 leaq1(%rdx,%rcx), %rdx salq$3, %rdx .p2align 4,,10 .p2align 3 .L5: movsd (%rdi,%rax), %xmm0 addsd %xmm1, %xmm0 movsd %xmm0, (%rdi,%rax) addq$8, %rax cmpq%rdx, %rax jne .L5 .L1: rep ret .L7: movl$10, %r10d xorl%r11d, %r11d jmp .L2
[Bug tree-optimization/53355] Autovectorization of a simple loop could be improved.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53355 --- Comment #2 from Richard Guenther 2012-05-15 13:18:42 UTC --- Author: rguenth Date: Tue May 15 13:18:32 2012 New Revision: 187535 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187535 Log: 2012-05-15 Richard Guenther PR tree-optimization/53355 * tree-vrp.c (extract_range_from_binary_expr_1): Handle LSHIFT_EXPRs by constants. * gcc.dg/tree-ssa/vrp67.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/vrp67.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c
[Bug fortran/52370] Spurious "may be used uninitialized" warning for check of optional argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52370 --- Comment #3 from Tobias Burnus 2012-05-15 13:15:49 UTC --- See also http://gcc.gnu.org/ml/fortran/2012-05/msg00066.html
[Bug libstdc++/53339] unordered_map::iterator requires Value to be complete type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53339 --- Comment #17 from Paolo Carlini 2012-05-15 13:11:55 UTC --- Still, if you mean to contribute, something else maybe, just let use (me) know: it's just matter of filling a form and waiting a bit. You do it once and then you are set forever.
[Bug c++/53360] New: Problems with -std=gnu++0x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53360
Bug #: 53360
Summary: Problems with -std=gnu++0x
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: andi...@mail.ru
I have such code:
template
struct make_literal;
template<>
struct make_literal {
typedef int type;
};
template
struct make_expression {
typedef typename make_literal::type type;
};
struct column {
template
typename make_expression::type operator= (const T& t) const {
return typename make_expression::type(t);
}
};
struct expression : column
{
expression() { }
using column::operator =;
};
int main()
{
expression ex;
ex = 2;
return 0;
}
which failed to compile with such command line:
c++ -std=gnu++0x file.cpp
Compiler produces such error:
bug.cpp: In instantiation of ‘make_expression’:
bug.cpp:31:10: instantiated from here
bug.cpp:12:42: error: invalid use of incomplete type ‘struct
make_literal’
bug.cpp:3:8: error: declaration of ‘struct make_literal’
[Bug fortran/45170] [F2003] allocatable character lengths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 --- Comment #34 from Tobias Burnus 2012-05-15 12:54:36 UTC --- (In reply to comment #24) > call hello(ceiling(11*rnd),string) That should be floor or "10" - otherwise, it can give "11" which is too large. (Or and better: Change the "10" to "11" below then "hello worl(d)" fits into the string.) > integer,intent(in)::n > character(10)::helloworld="hello world" > string=helloworld(:n) ! Does not work. Interestingly, it works if one does not use "n" as argument but sets it in the procedure. One then gets code like: *string = ... __builtin_malloc ( ... MAX_EXPR ) However, if "n" is passed as dummy argument, one has: integer(kind=4) D.1865; *string = ... __builtin_malloc ( ... MAX_EXPR ) D.1865 = *; Or in other words: The order is wrong.
[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 #2 from Dominique d'Humieres 2012-05-15 12:39:50 UTC --- > Do you possibly have a testcase? I am not sure to understand what you ask for. The source for cptrf2.f90 has been attached to pr53340. I can provide a version of rnflow without the proc cptrf2 or an archive with the rnflow.f90 source split to one file per proc. If you ask for a reduced test, it is much more difficult: (1) the code is not mine and I don't know it well, (2) optimizations may change for tiny details of the source layout.
[Bug libstdc++/53339] unordered_map::iterator requires Value to be complete type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53339 --- Comment #16 from Eugene Toder 2012-05-15 12:30:55 UTC --- Makes sense. I was hoping to avoid copyright assignment by having someone else do the work :) Thank you.
[Bug c++/50134] -Wmissing-prototypes doesn't work for C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50134
--- Comment #10 from Manuel López-Ibáñez 2012-05-15
12:23:50 UTC ---
Nonetheless, this is a patch that explains the current situation:
--- gcc/doc/invoke.texi (revision 187462)
+++ gcc/doc/invoke.texi (working copy)
@@ -4413,21 +4413,26 @@ This warning is also enabled by @option{
@item -Wmissing-prototypes @r{(C and Objective-C only)}
@opindex Wmissing-prototypes
@opindex Wno-missing-prototypes
Warn if a global function is defined without a previous prototype
declaration. This warning is issued even if the definition itself
-provides a prototype. The aim is to detect global functions that
-are not declared in header files.
+provides a prototype. The aim is to detect global functions that are
+not declared in header files, independently of whether the declaration
+is a prototype. This option does not apply to C++ because there is no
+concept of prototype. Use @option{-Wmissing-declarations} to detect
+missing declarations in C++.
@item -Wmissing-declarations
@opindex Wmissing-declarations
@opindex Wno-missing-declarations
Warn if a global function is defined without a previous declaration.
-Do so even if the definition itself provides a prototype.
-Use this option to detect global functions that are not declared in
-header files. In C++, no warnings are issued for function templates,
-or for inline functions, or for functions in anonymous namespaces.
+Do so even if the definition itself provides a prototype. Use this
+option to detect global functions that are not declared in header
+files. In C, this option does not warn if there is a previous
+non-prototype declaration; use @option{-Wmissing-prototype} to detect
+those. In C++, no warnings are issued for function templates, or for
+inline functions, or for functions in anonymous namespaces.
[Bug c++/50134] -Wmissing-prototypes doesn't work for C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50134
--- Comment #9 from Manuel López-Ibáñez 2012-05-15
12:21:36 UTC ---
(In reply to comment #6)
>
> int f();
> int f(void) { return 0; }
>
> gets a warning with -Wmissing-prototypes but not -Wmissing-declarations,
> because "int f();" is a non-prototype declaration in C.
Honestly, I don't see the purpose of this distinction in modern C. I would
rather have -Wmissing-declarations be an alias of -Wmissing-prototypes in C,
and simplify both GCC and the life of users.
[Bug bootstrap/53343] [4.8 regression] options.c:9944:1: error: no previous prototype for 'common_handle_option_auto' breaks bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53343 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #2 from Manuel López-Ibáñez 2012-05-15 12:05:16 UTC --- This is the successful compilation line in x86_64-unknown-linux-gnu: /home/manuel/test2/187462M/build/./prev-gcc/g++ -B/home/manuel/test2/187462M/build/./prev-gcc/ -B/home/manuel/test2/./187462M/install/x86_64-unknown-linux-gnu/bin/ -nostdinc++ -B/home/manuel/test2/187462M/build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/home/manuel/test2/187462M/build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -I/home/manuel/test2/187462M/build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/home/manuel/test2/187462M/build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include -I/home/manuel/test2/src/libstdc++-v3/libsupc++ -L/home/manuel/test2/187462M/build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/home/manuel/test2/187462M/build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -c -g -O2 -gtoggle -DIN_GCC -fno-exceptions -fno-rtti -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I/home/manuel/test2/src/gcc -I/home/manuel/test2/src/gcc/. -I/home/manuel/test2/src/gcc/../include -I/home/manuel/test2/src/gcc/../libcpp/include -I/opt/cfarm/mpfr-2.4.1//include -I/opt/cfarm/mpc-0.8/include -I/home/manuel/test2/src/gcc/../libdecnumber -I/home/manuel/test2/src/gcc/../libdecnumber/bid -I../libdecnumberoptions.c -o options.o So g++ is missing -Wmissing-prototypes (actually, -Wmissing-declarations). see PR 50134. Not sure what is the best way to fix this. Declare also the functions in options.c? Including options.h in options.c is maybe problematic.
[Bug c++/50134] -Wmissing-prototypes doesn't work for C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50134 Manuel López-Ibáñez changed: What|Removed |Added Status|RESOLVED|ASSIGNED Last reconfirmed||2012-05-15 Resolution|INVALID | Ever Confirmed|0 |1 --- Comment #8 from Manuel López-Ibáñez 2012-05-15 12:03:57 UTC --- I will update invoke.texi to make this clear. I see a lot of confusion among users: http://stackoverflow.com/questions/2389169/how-do-i-get-missing-prototype-warnings-from-g and GCC developers.
[Bug pch/15316] Precompiled headers fail on Cygwin due to mmap() behavior
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15316 --- Comment #5 from Blogspot 2012-05-15 11:47:05 UTC --- and finally a link about the most beautiful women in the world, and talk about women who model, this is a excellent blog that features fashion models, fitness models, and all kinds of information about modelling the model women blogspot website http://model-woman.blogspot.com/
[Bug pch/15316] Precompiled headers fail on Cygwin due to mmap() behavior
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15316 Blogspot changed: What|Removed |Added CC||youtubevideos2012 at ||hotmail dot co.uk --- Comment #3 from Blogspot 2012-05-15 11:42:47 UTC --- seen as this post is not needed for bug reports i will list a couple of blogspot links that might be of interest to users this is a online games blog about mmorpg games and various online computer games that are worth playing online http://free-online-games-mmorpg.blogspot.com/
[Bug preprocessor/53229] Fix diagnostics location when pasting tokens
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53229 --- Comment #1 from Dodji Seketeli 2012-05-15 11:19:12 UTC --- A patch for this has been proposed at http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01004.html
[Bug c++/53349] Internal compiler error with constexpr and recursive data type.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53349
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler at
||googlemail dot com
--- Comment #1 from Daniel Krügler
2012-05-15 10:53:22 UTC ---
I can confirm this for gcc 4.8.0 20120513 (experimental).
A current workaround is to replace the member declaration
constexpr Foo(const Foo a) : m_a(a) {}
by
constexpr Foo(const Foo& a) : m_a(a) {}
The following is a simplified form of the problem:
template
struct Foo {
constexpr Foo(const Foo a) : m_a(a) {} // Line 3
constexpr Foo(const Foo &a) : m_a(a.m_a) {}
Foo m_a;
};
template <> struct Foo<0> {};
constexpr auto res = Foo<2>(Foo<1>(Foo<0>())); // Line 10
10| in constexpr expansion of 'Foo<2>(Foo<1>((*(const Foo<1>*)(&
Foo<1>((Foo<0>((* & Foo<0>())), Foo<0>()))'|
3| in constexpr expansion of '((Foo<2>*)this)->Foo<2>::m_a.Foo::Foo<1>((* &
a))'|
10|internal compiler error: in cxx_eval_indirect_ref, at cp/semantics.c:7408|
[Bug lto/53337] 4.7.1 lto produces warning: relocation refers to discarded section in linker (gold, binutil 2.22)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53337 --- Comment #4 from vincenzo Innocente 2012-05-15 10:19:29 UTC --- tested with latest binutil no change (but nicer error message) GNU gold (GNU Binutils 2.22.52.20120515) 1.11 /tmp/innocent/ccIKFOKY.ltrans1.ltrans.o:ccIKFOKY.ltrans1.o:function vtable for boost::exception_detail::clone_impl > [clone .local.234]: warning: relocation refers to discarded section /tmp/innocent/ccIKFOKY.ltrans1.ltrans.o:ccIKFOKY.ltrans1.o:function vtable for boost::exception_detail::clone_impl > [clone .local.234]: warning: relocation refers to discarded section ….
[Bug target/53358] [4.7/4.8 Regression] ICE due to TARGET_READ_MODIFY_WRITE peephole2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53358 --- Comment #1 from Jakub Jelinek 2012-05-15 10:13:52 UTC --- Created attachment 27409 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27409 gcc47-pr53358.patch Untested fix.
[Bug target/53358] [4.7/4.8 Regression] ICE due to TARGET_READ_MODIFY_WRITE peephole2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53358 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-05-15 Target Milestone|--- |4.7.1 Ever Confirmed|0 |1
[Bug libstdc++/53339] unordered_map::iterator requires Value to be complete type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53339 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #15 from Paolo Carlini 2012-05-15 10:06:24 UTC --- Fixed for 4.8.0.
[Bug libstdc++/53339] unordered_map::iterator requires Value to be complete type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53339 --- Comment #14 from paolo at gcc dot gnu.org 2012-05-15 10:00:28 UTC --- Author: paolo Date: Tue May 15 10:00:19 2012 New Revision: 187515 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187515 Log: 2012-05-15 Paolo Carlini PR libstdc++/53339 * include/bits/hashtable_policy.h (__detail::_Identity, __detail::_Select1st): Add. (_Map_base, _Hashtable_base): Use the latter, adjust parameters. * include/bits/hashtable.h (_Hashtable::__key_extract): Adjust. * include/bits/unordered_set.h (__uset_hashtable, __umset_hashtable): Likewise. * include/bits/unordered_map.h (__umap_hashtable, __ummap_hashtable): Likewise. * include/bits/stl_function.h (_Identity, _Select1st, _Select2nd) Unconditionally derive from unary_function. * include/ext/functional (identity, select1st, select2nd): Remove #ifdef __GXX_EXPERIMENTAL_CXX0X__ bits. * testsuite/23_containers/unordered_map/requirements/53339.cc: New. * testsuite/23_containers/unordered_multimap/requirements/ 53339.cc: Likewise. Added: trunk/libstdc++-v3/testsuite/23_containers/unordered_map/requirements/53339.cc trunk/libstdc++-v3/testsuite/23_containers/unordered_multimap/requirements/53339.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/hashtable.h trunk/libstdc++-v3/include/bits/hashtable_policy.h trunk/libstdc++-v3/include/bits/stl_function.h trunk/libstdc++-v3/include/bits/unordered_map.h trunk/libstdc++-v3/include/bits/unordered_set.h trunk/libstdc++-v3/include/ext/functional trunk/libstdc++-v3/testsuite/20_util/ratio/cons/cons_overflow_neg.cc
[Bug middle-end/53347] Duplicated redundant condition in compare-elim.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53347 --- Comment #1 from Paolo Bonzini 2012-05-15 09:56:59 UTC --- The code in conforming_compare matches this comment with or without the duplicate test: (1) All comparison patterns are represented as [(set (reg:CC) (compare:CC (reg) (immediate)))] so it looks like it could be removed.
[Bug target/53358] New: [4.7/4.8 Regression] ICE due to TARGET_READ_MODIFY_WRITE peephole2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53358
Bug #: 53358
Summary: [4.7/4.8 Regression] ICE due to
TARGET_READ_MODIFY_WRITE peephole2
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
AssignedTo: ja...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
Target: i?86-*
/* { dg-do compile } */
/* { dg-options "-O2" } */
/* { dg-additional-options "-fpic" { target fpic } } */
/* { dg-additional-options "-mtune=pentium4" { target { { i?86-*-* x86_64-*-* }
&& ia32 } } } */
struct S { unsigned char s, t[17]; };
int bar (void);
void
foo (struct S *x)
{
unsigned char i, z;
if (bar ())
{
z = bar ();
bar ();
x->s += z;
for (i = 0; i < x->s; i++)
x->t[i] = bar ();
}
}
ICEs with:
rh821223.i: In function 'foo':
rh821223.i:21:1: error: insn does not satisfy its constraints:
(insn 77 22 27 3 (parallel [
(set (reg:CCZ 17 flags)
(compare:CCZ (plus:QI (mem:QI (reg/v/f:SI 4 si [orig:72 x ]
[72]) [0 x_5(D)->s+0 S1 A8])
(reg:QI 5 di [orig:63 D.1372 ] [63]))
(const_int 0 [0])))
(set (mem:QI (reg/v/f:SI 4 si [orig:72 x ] [72]) [0 x_5(D)->s+0 S1
A8])
(plus:QI (mem:QI (reg/v/f:SI 4 si [orig:72 x ] [72]) [0
x_5(D)->s+0 S1 A8])
(reg:QI 5 di [orig:63 D.1372 ] [63])))
]) rh821223.i:18 259 {*addqi_2}
(nil))
rh821223.i:21:1: internal compiler error: in copyprop_hardreg_forward_1, at
regcprop.c:767
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
The problem is that addqi_1 pattern before the peephole2 in some alternatives
allows "r" registers rather than "q" and emits addl instead of addq in that
case, and the peepholes I've added for 4.7+ didn't think about such a
possibility.
[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 Keywords||missed-optimization Target Milestone|--- |4.8.0 --- Comment #1 from Richard Guenther 2012-05-15 09:43:31 UTC --- Do you possibly have a testcase?
[Bug tree-optimization/53355] Autovectorization of a simple loop could be improved.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53355 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-05-15 Component|middle-end |tree-optimization AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther 2012-05-15 09:40:45 UTC --- Confirmed. Btw, it does not check for misalignment again but for whether there is a remaining scalar iteration to be done. On trunk (for GCC 4.8) we already improve somewhat - but the odd induction variable choices remain. foo: .LFB0: .cfi_startproc movq%rdi, %rax salq$60, %rax shrq$63, %rax testl %eax, %eax je .L2 movsd (%rdi), %xmm0 movl$10, %r8d movsd .LC0(%rip), %xmm1 subl%eax, %r8d movl%r8d, %esi movl$9, %r11d addsd %xmm1, %xmm0 shrl%esi movl%esi, %r9d addl%r9d, %r9d movsd %xmm0, (%rdi) je .L9 movl$1, %r10d .L8: movapd .LC1(%rip), %xmm1 leaq(%rdi,%rax,8), %rcx xorl%edx, %edx xorl%eax, %eax .p2align 4,,10 .p2align 3 .L7: movapd (%rcx,%rax), %xmm0 addl$1, %edx addpd %xmm1, %xmm0 movapd %xmm0, (%rcx,%rax) addq$16, %rax cmpl%esi, %edx jb .L7 subl%r9d, %r11d cmpl%r9d, %r8d leal(%r10,%r9), %edx je .L1 movsd .LC0(%rip), %xmm1 .L3: leal-1(%r11), %ecx movslq %edx, %rdx leaq0(,%rdx,8), %rax leaq1(%rdx,%rcx), %rdx salq$3, %rdx .p2align 4,,10 .p2align 3 .L6: movsd (%rdi,%rax), %xmm0 addsd %xmm1, %xmm0 movsd %xmm0, (%rdi,%rax) addq$8, %rax cmpq%rdx, %rax jne .L6 rep ret .L1: ret .L2: movl$10, %r8d movl$5, %esi movl$10, %r9d movl$10, %r11d xorl%r10d, %r10d jmp .L8 .L9: movl$1, %edx jmp .L3 what we also fail to optimize are the entry checks of the vectorized loops after the prologue loop: # BLOCK 2 loop_depth:0 freq:100 # PRED: ENTRY [100.0%] (fallthru,exec) D.1738_23 = (unsigned long) x_2(D); D.1739_24 = D.1738_23 & 15; D.1740_25 = D.1739_24 >> 3; D.1741_26 = -D.1740_25; D.1742_27 = (unsigned int) D.1741_26; D.1802_18 = D.1741_26 & 1; prolog_loop_niters.16_28 = (unsigned int) D.1802_18; if (prolog_loop_niters.16_28 == 0) goto ; else goto ; # SUCC: 3 [100.0%] (false,exec) 12 (true,exec) # BLOCK 3 loop_depth:0 freq:100 # PRED: 2 [100.0%] (false,exec) x_65 = x_2(D); D.1718_37 = MEM[base: x_65, offset: 0B]; D.1719_38 = D.1718_37 + 2.0e+0; MEM[base: x_65, offset: 0B] = D.1719_38; prolog_loop_adjusted_niters.18_52 = D.1741_26 & 1; niters.19_53 = 10 - prolog_loop_niters.16_28; bnd.20_54 = niters.19_53 >> 1; ratio_mult_vf.21_55 = bnd.20_54 << 1; if (ratio_mult_vf.21_55 == 0) goto ; else goto ; # SUCC: 4 [100.0%] (false,exec) 7 (true,exec) we fail to see that ratio_mult_vf.21_55 is never zero. Of course that is because of the awkward representation of the checks. I will look into this.
[Bug fortran/53357] New: Add -fcheck=bounds for character type-spec in ALLOCATE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53357 Bug #: 53357 Summary: Add -fcheck=bounds for character type-spec in ALLOCATE Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org Example: The following is invalid as the length does not match: integer :: i i = 5 block character(len=i), allocatable :: str allocate (character(len=3) :: str) end block end * * * That's already correctly detected for compile-time constants: character(len=5), allocatable :: str allocate (character(len=3) :: str) end Error: Allocating str at (1) with type-spec requires the same character-length parameter as in the declaration However, the compile-time version could also print the bounds.
[Bug c++/53356] [4.7/4.8 Regression] ICE in verify_gimple_stmt, at tree-cfg.c:4258
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53356 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-05-15 Summary|ICE in verify_gimple_stmt, |[4.7/4.8 Regression] ICE in |at tree-cfg.c:4258 |verify_gimple_stmt, at ||tree-cfg.c:4258 Ever Confirmed|0 |1 --- Comment #1 from Paolo Carlini 2012-05-15 09:29:00 UTC --- Confirmed.
[Bug libstdc++/53339] unordered_map::iterator requires Value to be complete type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53339 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-05-15 AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com Target Milestone|--- |4.8.0 Ever Confirmed|0 |1 --- Comment #13 from Paolo Carlini 2012-05-15 09:25:47 UTC --- May be a good idea. But at this point I think you want to send further improvements beyond the PR proper to the mailing list for large exposure. And of course beyond a few lines, if you are interested in contributing (which would be great!) you should do the Copyright assignment paperwork, I have to tell you.
[Bug bootstrap/53343] [4.8 regression] options.c:9944:1: error: no previous prototype for 'common_handle_option_auto' broke bootstrap on sparc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53343 --- Comment #1 from Mikael Pettersson 2012-05-15 09:14:40 UTC --- Also occurs on powerpc64 and arm, so not specific to sparc64.
[Bug rtl-optimization/52804] IRA/RELOAD allocate wrong register on ARM for cortex-m0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52804 Ramana Radhakrishnan changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.7.1 --- Comment #7 from Ramana Radhakrishnan 2012-05-15 08:43:27 UTC --- Fixed then .
