[Bug c++/51669] [4.7 Regression] ICE verify-gimple with openmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51669 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #7 from Jakub Jelinek 2012-01-03 07:57:14 UTC --- Fixed.
[Bug c++/51669] [4.7 Regression] ICE verify-gimple with openmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51669
--- Comment #6 from Jakub Jelinek 2012-01-03
07:49:53 UTC ---
Author: jakub
Date: Tue Jan 3 07:49:48 2012
New Revision: 182828
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182828
Log:
PR c++/51669
* semantics.c (finish_omp_clauses): Call fold_build_cleanup_point_expr
on OMP_CLAUSE_{IF,FINAL,NUM_THREADS,SCHEDULE_CHUNK}_EXPR.
* g++.dg/gomp/pr51669.C: New test.
Added:
trunk/gcc/testsuite/g++.dg/gomp/pr51669.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog
[Bug c++/51731] code generation bug in negative indices in arrays on 64-bit targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51731 --- Comment #6 from M.L. Hekkelman 2012-01-03 07:44:55 UTC --- (In reply to comment #5) > (In reply to comment #4) > > Following your logic, if I rewrite the code from: > > > > return data.e[-1]; > > > > to > > > > int* ep = data.e; > > return ep[-1]; > > > > It would be valid, right? And you still believe the bug report is > > invalid? > > Of course that wouldn't be valid. > I meant that if you had say array > type e[10]; > somewhere and > type *ep = data.e + 9; > you can then access > ep[0] + ep[-1] + ep[-9] > In C++03, please read [expr.add]/5 : > "If both the pointer operand and the result point to elements of the same > array > object, or one past the last element of the array object, the evaluation shall > not produce an overflow; otherwise, the behavior is undefined." I stand corrected. Still, it would be nice if gcc would then issue a warning instead of only giving incorrect results when -O3 is specified.
[Bug c++/51722] Options "-g3" or "-ggdb3" or "-g3 -gdwarf-2" and other "-g..level3" - internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51722 --- Comment #11 from Yuriy Lalym 2012-01-03 06:17:49 UTC --- Created attachment 26227 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26227 And pch.ii
[Bug c++/51722] Options "-g3" or "-ggdb3" or "-g3 -gdwarf-2" and other "-g..level3" - internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51722
--- Comment #10 from Yuriy Lalym 2012-01-03 06:17:03
UTC ---
Created attachment 26226
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26226
only main with empty pch
main.cpp
int main()
{
return 0;
}
pch.h
// Empty
[Bug c++/51722] Options "-g3" or "-ggdb3" or "-g3 -gdwarf-2" and other "-g..level3" - internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51722 --- Comment #9 from Yuriy Lalym 2012-01-03 06:08:14 UTC --- Created attachment 26225 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26225 And pch.ii
[Bug c++/51722] Options "-g3" or "-ggdb3" or "-g3 -gdwarf-2" and other "-g..level3" - internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51722
--- Comment #8 from Yuriy Lalym 2012-01-03 06:05:23
UTC ---
Created attachment 26224
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26224
new example
main.cpp
int main()
{
return 0;
}
pch.h
#include
>> -g2
g++-4.7 -m64 -pipe -g2 -gdwarf-4 -fvar-tracking-assignments -Wall -W
-D_REENTRANT -x c++-header -c pch.h -o untitled5.gch/c++
g++-4.7 -c -include untitled5 -m64 -pipe -g2 -gdwarf-4
-fvar-tracking-assignments -Wall -W -D_REENTRANT -o main.o main.cpp
g++-4.7 -m64 -o untitled5 main.o-L/usr/lib64 -lpthread
good
>> -g3
g++-4.7 -m64 -pipe -g3 -gdwarf-4 -fvar-tracking-assignments -Wall -W
-D_REENTRANT -x c++-header -c pch.h -o untitled5.gch/c++
g++-4.7 -c -include untitled5 -m64 -pipe -g3 -gdwarf-4
-fvar-tracking-assignments -Wall -W -D_REENTRANT -o main.o main.cpp
*** glibc detected *** /usr/local/lib/gcc/x86_64-suse-linux/4.7.0/cc1plus:
munmap_chunk(): invalid pointer: 0x0010ba20 ***
[Bug middle-end/51017] GCC 4.6 performance regression (vs. 4.4/4.5)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51017 --- Comment #4 from Alexander Peslyak 2012-01-03 04:45:43 UTC --- (In reply to comment #3) > It might be interesting to get numbers for the trunk. There have been some > register allocator fixes which might have improved this. I've just tested the gcc-4.7-20111231 snapshot vs. 4.6.2 release. There's no improvement as it relates to this issue: I am getting the same poor performance (a lot worse than for 4.5). This is for generating x86-64 code with SSE2 intrinsics, benchmarking the resulting code on a Core 2'ish CPU (I used Xeon E5420 this time).
[Bug c++/51722] Options "-g3" or "-ggdb3" or "-g3 -gdwarf-2" and other "-g..level3" - internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51722 Hans-Peter Nilsson changed: What|Removed |Added CC||hp at gcc dot gnu.org --- Comment #7 from Hans-Peter Nilsson 2012-01-03 04:39:05 UTC --- (In reply to comment #6) > Created attachment 26220 [details] > For example in Comment 4 Sorry, that file contains a reference to precompiled headers: #pragma GCC pch_preprocess "./untitled5.gch/c++" so we'd need "all preprocessed headers to build the PCH" (I'm not sure how to find those from the above line). On a somewhat closer look, the precompiled header is found within the Qt-headers, so maybe you just need to rebuild *that* without precompiled headers to create a debuggable context we can use.
[Bug c++/51737] g++ crashes (internal compiler error: Segmentation fault) when compiling quickbook
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51737 --- Comment #6 from Jens Müller 2012-01-03 04:17:07 UTC --- Created attachment 26223 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26223 reduced testcase OK, I don't get it any smaller ...
[Bug c++/51738] C++11 initializer list does not work correctly with operator[]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51738 Paolo Carlini changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #1 from Paolo Carlini 2012-01-03 00:18:20 UTC --- Uhm, is it simply that cp_parser_postfix_open_square_expression doesn't handle: postfix-expression [ braced-init-list ] or I'm misreading the C++11 grammar vs our parser?
[Bug c++/51738] New: C++11 initializer list does not work correctly with operator[]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51738
Bug #: 51738
Summary: C++11 initializer list does not work correctly with
operator[]
Classification: Unclassified
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: akrze...@gmail.com
I compile the following code:
struct Index{
Index(unsigned, unsigned){}
};
struct Matrix{
void operator[](Index){}
};
int main() {
Matrix m;
m[{0,1}];
//m.operator[]({0,1}); -- this is valid
//m[Index{0,1}]; -- this is valid
}
I use the following command:
g++ main.cpp -Wall -Wextra -fno-strict-aliasing -fwrapv -std=c++0x -o brace.exe
I get the following reply:
main.cpp: In function ‘int main()’:
main.cpp:11:5: error: expected primary-expression before ‘{’ token
main.cpp:11:5: error: expected ‘]’ before ‘{’ token
main.cpp:11:5: error: expected ‘;’ before ‘{’ token
main.cpp:11:10: error: expected primary-expression before ‘]’ token
main.cpp:11:10: error: expected ‘;’ before ‘]’ token
This is a bug because my program is valid C++11 code, and if I write:
m.operator[]({0,1});
instead of
m[{0,1}];
my program compiles.
This has been already reported in bug report 39901, but 39901 has been
incorrectly put into "RESOLVED INVALID"state. Code:
m[{0,1}];
should be equivalent to:
m[Index{0,1}];
Regards,
&rzej
[Bug fortran/45521] Fortran 2008: GENERIC resolution with ALLOCATABLE/POINTER and PROCEDURE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45521 Tobias Burnus changed: What|Removed |Added CC||wangmianzhi1 at linuxmail ||dot org --- Comment #1 from Tobias Burnus 2012-01-02 22:38:29 UTC --- *** Bug 51736 has been marked as a duplicate of this bug. ***
[Bug fortran/51736] generic fortran procedures with allocatable/pointer argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51736 Tobias Burnus changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||burnus at gcc dot gnu.org Resolution||DUPLICATE --- Comment #1 from Tobias Burnus 2012-01-02 22:38:29 UTC --- (In reply to comment #0) > Will this feature be included in the later releases? Yes, it is definitely planed to support this feature, but it has not been implemented so far and won't be in GCC 4.7.0 (to be released in March?) It might get implemented for 4.8. *** This bug has been marked as a duplicate of bug 45521 ***
[Bug driver/48306] [4.4/4.5/4.6 Regression] presence of gcc subdir with . in PATH causes breakdown
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48306 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Summary|[4.4/4.5/4.6/4.7|[4.4/4.5/4.6 Regression] |Regression] presence of gcc |presence of gcc subdir with |subdir with . in PATH |. in PATH causes breakdown |causes breakdown| --- Comment #9 from Jakub Jelinek 2012-01-02 22:20:00 UTC --- Fixed on the trunk so far.
[Bug bootstrap/51725] [4.7 regression] segfault in stage 3 when compiling gcc/opts.c for sparc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51725 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #8 from Jakub Jelinek 2012-01-02 22:19:30 UTC --- Fixed.
[Bug driver/48306] [4.4/4.5/4.6/4.7 Regression] presence of gcc subdir with . in PATH causes breakdown
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48306 --- Comment #8 from Jakub Jelinek 2012-01-02 22:18:25 UTC --- Author: jakub Date: Mon Jan 2 22:18:21 2012 New Revision: 182820 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182820 Log: * make-relative-prefix.c (make_relative_prefix_1): Avoid stack overflow if PATH contains just a single entry and HOST_EXECUTABLE_SUFFIX needs to be used. PR driver/48306 * make-relative-prefix.c: Include sys/stat.h. (make_relative_prefix_1): If access succeeds, check also stat if nstore is a regular file. Modified: trunk/libiberty/ChangeLog trunk/libiberty/make-relative-prefix.c
[Bug bootstrap/51725] [4.7 regression] segfault in stage 3 when compiling gcc/opts.c for sparc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51725 --- Comment #7 from Jakub Jelinek 2012-01-02 22:17:05 UTC --- Author: jakub Date: Mon Jan 2 22:17:02 2012 New Revision: 182819 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182819 Log: PR bootstrap/51725 * cselib.c (add_mem_for_addr): Call canonical_cselib_val on mem_elt first. Modified: trunk/gcc/ChangeLog trunk/gcc/cselib.c
[Bug c++/15867] -Wredundant-decls and explicit template specialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15867 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED CC|gcc-bugs at gcc dot gnu.org | AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com Known to fail|| --- Comment #2 from Paolo Carlini 2012-01-02 21:51:11 UTC --- Seems doable.
[Bug c++/51710] decltype and SFINAE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51710 --- Comment #3 from Yuriy Solodkyy 2012-01-02 21:35:56 UTC --- Thank you, I am aware of the workaround and that is exactly what I do in my code, however I think the current behavior is counter intuitive: 1. I get error message about instantiation that I have not made myself in the code or expected to be made, but because compiler had failure during substitution in decltype. 2. The error message is missing the instantiation context as in regular cases, which made me wonder for a long time what exactly fails and why, especially since Visual C++ was doing what I expected. 3. The purpose of decltype is now less clear as for each such case I cannot just use decltype, but have to create a dedicated meta-function again, that uses the decltype inside. 4. Once the concept based overloading is there, I expect the function be thrown out of the overload set because the types don't match the concept emulated here with condition. There won't be compilation error then and with this code I am simply trying to emulate the concept-based overloading with tools i have today. Thank you, Yuriy
[Bug c++/51737] g++ crashes (internal compiler error: Segmentation fault) when compiling quickbook
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51737 --- Comment #5 from Paolo Carlini 2012-01-02 21:22:46 UTC --- Great ;) topformat is also useful, iterating between the two as explained in the wiki, that is.
[Bug c++/51737] g++ crashes (internal compiler error: Segmentation fault) when compiling quickbook
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51737 --- Comment #4 from Jens Müller 2012-01-02 21:20:48 UTC --- Thanks, delta is running. I'll send a result in a few hours :-)
[Bug c++/51737] g++ crashes (internal compiler error: Segmentation fault) when compiling quickbook
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51737 --- Comment #3 from Paolo Carlini 2012-01-02 20:40:31 UTC --- Please, do your best to reduce the testcase to a manageable size, it's normally rather doable with tools like delta: http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction
[Bug c/51676] -Wsuggest-attribute={pure,const} should give line number of declaration, not definition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51676 --- Comment #3 from Ben Longbons 2012-01-02 20:27:41 UTC --- I'm not familiar with GCC internals, but would it be as easy as adding and using a second field for "first declaration"? If the first (possibly only) declaration is the definition, then just remember it. If there are one or more declarations before the definition, then just remember the first one.
[Bug c++/51737] g++ crashes (internal compiler error: Segmentation fault) when compiling quickbook
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51737 --- Comment #2 from Jens Müller 2012-01-02 20:21:41 UTC --- Someone on IRC confirmed that 4.6.2 also crashes.
[Bug c++/51737] g++ crashes (internal compiler error: Segmentation fault) when compiling quickbook
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51737 --- Comment #1 from Jens Müller 2012-01-02 20:10:51 UTC --- Created attachment 26222 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26222 preprocessed source (bzip2'ed because of excessive size)
[Bug c++/51737] New: g++ crashes (internal compiler error: Segmentation fault) when compiling quickbook
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51737 Bug #: 51737 Summary: g++ crashes (internal compiler error: Segmentation fault) when compiling quickbook Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: b...@tessarakt.de g++ crashes when compiling quickbook from the Boost documentation. Command line and output follows, preprocessed source is attached. $ LC_ALL=C LANG=C "g++" -v -save-temps -ftemplate-depth-300 -O3 -finline-functions -Wno-inline -Wall -g0 -DBOOST_ALL_NO_LIB=1 -DBOOST_FILESYSTEM_NO_DEPRECATED -DBOOST_SYSTEM_STATIC_LINK=1 -DNDEBUG -I".." -c -o "../bin.v2/tools/quickbook/src/gcc-4.6.1/release/link-static/id_manager.o" "/home/jens/devel/boost-trunk/tools/quickbook/src/id_manager.cpp" Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6.1/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.1-9ubuntu3' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++,go --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-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.1 (Ubuntu/Linaro 4.6.1-9ubuntu3) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-ftemplate-depth=300' '-O3' '-finline-functions' '-Wno-inline' '-Wall' '-g0' '-D' 'BOOST_ALL_NO_LIB=1' '-D' 'BOOST_FILESYSTEM_NO_DEPRECATED' '-D' 'BOOST_SYSTEM_STATIC_LINK=1' '-D' 'NDEBUG' '-I' '..' '-c' '-o' '../bin.v2/tools/quickbook/src/gcc-4.6.1/release/link-static/id_manager.o' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-linux-gnu/4.6.1/cc1plus -E -quiet -v -I .. -imultilib . -imultiarch x86_64-linux-gnu -D_GNU_SOURCE -D BOOST_ALL_NO_LIB=1 -D BOOST_FILESYSTEM_NO_DEPRECATED -D BOOST_SYSTEM_STATIC_LINK=1 -D NDEBUG /home/jens/devel/boost-trunk/tools/quickbook/src/id_manager.cpp -mtune=generic -march=x86-64 -Wno-inline -Wall -ftemplate-depth=300 -finline-functions -O3 -fpch-preprocess -fstack-protector -o id_manager.ii ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu" ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../../x86_64-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: .. /usr/include/c++/4.6 /usr/include/c++/4.6/x86_64-linux-gnu/. /usr/include/c++/4.6/backward /usr/lib/gcc/x86_64-linux-gnu/4.6.1/include /usr/local/include /usr/lib/gcc/x86_64-linux-gnu/4.6.1/include-fixed /usr/include/x86_64-linux-gnu /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-ftemplate-depth=300' '-O3' '-finline-functions' '-Wno-inline' '-Wall' '-g0' '-D' 'BOOST_ALL_NO_LIB=1' '-D' 'BOOST_FILESYSTEM_NO_DEPRECATED' '-D' 'BOOST_SYSTEM_STATIC_LINK=1' '-D' 'NDEBUG' '-I' '..' '-c' '-o' '../bin.v2/tools/quickbook/src/gcc-4.6.1/release/link-static/id_manager.o' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-linux-gnu/4.6.1/cc1plus -fpreprocessed id_manager.ii -quiet -dumpbase id_manager.cpp -mtune=generic -march=x86-64 -auxbase-strip ../bin.v2/tools/quickbook/src/gcc-4.6.1/release/link-static/id_manager.o -g0 -O3 -Wno-inline -Wall -version -ftemplate-depth=300 -finline-functions -fstack-protector -o id_manager.s GNU C++ (Ubuntu/Linaro 4.6.1-9ubuntu3) version 4.6.1 (x86_64-linux-gnu) compiled by GNU C version 4.6.1, GMP version 5.0.1, MPFR version 3.0.1-p3, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C++ (Ubuntu/Linaro 4.6.1-9ubuntu3) version 4.6.1 (x86_64-linux-gnu) compiled by GNU C version 4.6.1, GMP version 5.0.1, MPFR version 3.0.1-p3, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 63a745aba0054d1605090177d8e4bbb4 In file included from ../boost/intrusive_ptr.hpp:16:0, from /home/jens/devel/boost-trunk/tools/quickbook/src/fwd.hpp:15, from /home/jens/devel/boost-trunk/tools/quickbook/src/values.hpp:20, from /home/jens/devel/boost-trunk/tools/quickbook/src/id_manager.hpp:14, from /home/jens/devel/boost-trunk/tools/quickbook/src/id_manager.cpp:9: ../boost/smart_ptr/intrusive_ptr.hpp: In destructor 'boost::intrusive_ptr::~intrusive_ptr() [with T = quickbook::file_info]': ../boost/sm
[Bug target/51681] [4.7 Regression]: ICE in gcc.dg/torture/vshuf-v2si.c on ia64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51681 Uros Bizjak changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc-p ||atches/2012-01/msg00077.htm ||l --- Comment #6 from Uros Bizjak 2012-01-02 19:48:52 UTC --- Patch at [1]. [1] http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00077.html
[Bug c++/51731] code generation bug in negative indices in arrays on 64-bit targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51731 --- Comment #5 from Jakub Jelinek 2012-01-02 19:32:08 UTC --- (In reply to comment #4) > Following your logic, if I rewrite the code from: > > return data.e[-1]; > > to > > int* ep = data.e; > return ep[-1]; > > It would be valid, right? And you still believe the bug report is > invalid? Of course that wouldn't be valid. I meant that if you had say array type e[10]; somewhere and type *ep = data.e + 9; you can then access ep[0] + ep[-1] + ep[-9] In C++03, please read [expr.add]/5 : "If both the pointer operand and the result point to elements of the same array object, or one past the last element of the array object, the evaluation shall not produce an overflow; otherwise, the behavior is undefined."
[Bug c++/51731] code generation bug in negative indices in arrays on 64-bit targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51731 --- Comment #4 from M.L. Hekkelman 2012-01-02 19:08:10 UTC --- Beste jakub, maandag 2 januari 2012, 18:10:17, schreef je: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51731 > Jakub Jelinek changed: >What|Removed |Added > > Status|UNCONFIRMED |RESOLVED > CC||jakub at gcc dot gnu.org > Resolution||INVALID > --- Comment #3 from Jakub Jelinek 2012-01-02 > 17:10:17 UTC --- > Having a zero-sized array at the end of a struct is surely a commonly used > technique, close to standard flexible array members, but that is not what you > are doing. Trying to reference data.e[-1] through data.e[-9] is of course not > valid C++ (nor C) when e is an array (it might be valid if e was a pointer and > pointed into the middle of some array). Following your logic, if I rewrite the code from: return data.e[-1]; to int* ep = data.e; return ep[-1]; It would be valid, right? And you still believe the bug report is invalid?
[Bug fortran/51736] New: generic fortran procedures with allocatable/pointer argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51736 Bug #: 51736 Summary: generic fortran procedures with allocatable/pointer argument Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: wangmianz...@linuxmail.org Created attachment 26221 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26221 a reduced example According to the f2008 standard (12.4.3.4.5), dummy arguments having allocatable attribute and pointer attribute should be distinguishable. Thus the attached reduced code should be valid. Will this feature be included in the later releases? Or could anyone provide suggestions to work around? Thank you very much for your help and the great compiler.
[Bug c++/51722] Options "-g3" or "-ggdb3" or "-g3 -gdwarf-2" and other "-g..level3" - internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51722 --- Comment #6 from Yuriy Lalym 2012-01-02 18:57:40 UTC --- Created attachment 26220 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26220 For example in Comment 4
[Bug fortran/49110] Deferred-length character result triggers (false positive) error for pure procedures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49110
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #13 from Tobias Burnus 2012-01-02
18:53:47 UTC ---
(In reply to comment #9)
> ! character, intent(in) :: s(5) ! Compiles and runs
> character, intent(in) :: s(:)! Compiles and segfaults
> character(len=:), allocatable :: a
> a = repeat('a', size(s))
For that example, try:
a = ( repeat('a', size(s)) )
Cf. PR 51055.
[Bug c++/51722] Options "-g3" or "-ggdb3" or "-g3 -gdwarf-2" and other "-g..level3" - internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51722 --- Comment #5 from Yuriy Lalym 2012-01-02 18:50:23 UTC --- gcc-4.7 -v Using built-in specs. COLLECT_GCC=gcc-4.7 COLLECT_LTO_WRAPPER=/usr/local/lib/gcc/x86_64-suse-linux/4.7.0/lto-wrapper Target: x86_64-suse-linux Configured with: ../configure --prefix=/usr/local --libdir=/usr/local/lib64 --libexecdir=/usr/local/lib64 --enable-languages=c,c++ --enable-checking=release --with-gxx-include-dir=/usr/local/include/c++/4.7 --enable-ssp --disable-libssp --disable-plugin --with-pkgversion='SUSE Linux' --disable-libgcj --with-slibdir=/lib64 --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --program-suffix=-4.7 --enable-linux-futex --without-system-libunwind --with-tune=core2 --build=x86_64-suse-linux : (reconfigured) ../configure --prefix=/usr/local --libdir=/usr/local/lib64 --libexecdir=/usr/local/lib64 --enable-languages=c,c++ --enable-checking=release --with-gxx-include-dir=/usr/local/include/c++/4.7 --enable-ssp --disable-libssp --disable-plugin --with-pkgversion='SUSE Linux' --disable-libgcj --with-slibdir=/lib64 --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --program-suffix=-4.7 --enable-linux-futex --without-system-libunwind --with-tune=core2 --build=x86_64-suse-linux Thread model: posix gcc version 4.7.0 20120102 (experimental) (SUSE Linux)
[Bug tree-optimization/51719] [4.7 Regression] ICE: verify_gimple failed: LHS in noreturn call with -fpartial-inlining -fprofile-use and exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51719 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #2 from Jakub Jelinek 2012-01-02 18:18:13 UTC --- Created attachment 26219 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26219 gcc47-pr51719.patch Untested fix.
[Bug c++/51689] GCC apparently is inconsistent with warning about invalid brace-elision use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51689 --- Comment #1 from Paolo Carlini 2012-01-02 18:01:58 UTC --- In this area we have also PR25137.
[Bug c++/51322] [C++11] wrong mangling with argument packs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51322 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-01-02 AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug libstdc++/49204] [C++0x] remaining issues in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49204 --- Comment #5 from Jonathan Wakely 2012-01-02 17:56:19 UTC --- (In reply to comment #2) > We should also make std::async check the system load when deciding whether to > run asynchronously or deferred. We should be able to reuse GNU Make's code > for > deciding whether to run a new job or not, see load_too_high() in job.c It turns out that calling get_nprocs() (via std::thread::hardware_concurrency()) and getloadavg() from several threads concurrently is a really bad idea, so I'm working on a simple implementation that just compares the number of active async jobs to the number of processors.
[Bug c++/51675] [C++11][4.7 Regression] Cannot create constexpr unions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51675 --- Comment #2 from Jason Merrill 2012-01-02 17:53:32 UTC --- Author: jason Date: Mon Jan 2 17:53:28 2012 New Revision: 182810 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182810 Log: DR 1359 PR c++/51675 * method.c (walk_field_subobs): Don't check for uninitialized fields in a union. (synthesized_method_walk): Check here. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-union2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/method.c trunk/gcc/testsuite/ChangeLog
[Bug c++/51666] NSDMI parse fails for template'd intializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51666 --- Comment #3 from Jason Merrill 2012-01-02 17:53:23 UTC --- Author: jason Date: Mon Jan 2 17:53:16 2012 New Revision: 182809 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182809 Log: DR 325 PR c++/51666 * parser.c (cp_parser_cache_defarg): Split out... (cp_parser_parameter_declaration): ...from here. (cp_parser_save_nsdmi): Use it. (cp_parser_cache_group): Remove CPP_COMMA support. Added: trunk/gcc/testsuite/g++.dg/cpp0x/nsdmi-defer5.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog
[Bug c++/47335] [C++0x] "sorry, unimplemented: mangling overload"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47335 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #5 from Paolo Carlini 2012-01-02 17:48:45 UTC --- Closing as duplicate of 48051. If I'm doing something wrong, please re-open, and sorry ;) *** This bug has been marked as a duplicate of bug 48051 ***
[Bug c++/48051] sorry, unimplemented: mangling overload
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48051 Paolo Carlini changed: What|Removed |Added CC||zeratul976 at hotmail dot ||com --- Comment #2 from Paolo Carlini 2012-01-02 17:48:45 UTC --- *** Bug 47335 has been marked as a duplicate of this bug. ***
[Bug c++/51322] [C++11] wrong mangling with argument packs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51322 Paolo Carlini changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #1 from Paolo Carlini 2012-01-02 17:46:41 UTC --- Jason, are you aware of this mangling issue? Looks like something we may want to fix rather early.
[Bug c++/49976] Cross (Linux->AIX) GCC crashes with Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49976 --- Comment #4 from Paolo Carlini 2012-01-02 17:44:09 UTC --- Thanks Iain, if you could manage to test on the branch too - when possible - it would be great. Or at some point we can as well close the issue as worksforme in mainline, 4_6-branch is getting old.
[Bug c++/51151] Invalid -Woverflow warning in C++ frontend
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51151 --- Comment #7 from Ollie Wild 2012-01-02 17:35:07 UTC --- I'm on vacation until Jan. 6. For compiler related questions, please email c-compiler-t...@google.com. If you need to contact a manager, please email lp-m...@google.com. Thanks, Ollie
[Bug c++/51151] Invalid -Woverflow warning in C++ frontend
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51151 --- Comment #6 from Paolo Carlini 2012-01-02 17:34:19 UTC --- Andreas, can we close this?
[Bug debug/49951] [4.5/4.6/4.7 Regression] Debug stepping behavior regarding g++ Class destructor has changed for the worse starting at gcc 4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49951 --- Comment #16 from Dodji Seketeli 2012-01-02 17:08:50 UTC --- Author: dodji Date: Mon Jan 2 17:08:45 2012 New Revision: 182807 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182807 Log: PR debug/49951 - jumpy stepping at end of scope in C++ gcc/cp/ PR debug/49951 * decl.c (cxx_maybe_build_cleanup): Don't set location of the call to the destructor. gcc/testsuite/ PR debug/49951 * g++.dg/gcov/gcov-2.C: Adjust. Modified: branches/gcc-4_6-branch/gcc/cp/ChangeLog branches/gcc-4_6-branch/gcc/cp/decl.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog branches/gcc-4_6-branch/gcc/testsuite/g++.dg/gcov/gcov-2.C
[Bug c++/51462] [c++0x] ICE in cx_check_missing_mem_inits
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51462 Dodji Seketeli changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #2 from Dodji Seketeli 2012-01-02 17:10:15 UTC --- Should be fixed in 4.7 (trunk)
[Bug c++/51731] code generation bug in negative indices in arrays on 64-bit targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51731 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution||INVALID --- Comment #3 from Jakub Jelinek 2012-01-02 17:10:17 UTC --- Having a zero-sized array at the end of a struct is surely a commonly used technique, close to standard flexible array members, but that is not what you are doing. Trying to reference data.e[-1] through data.e[-9] is of course not valid C++ (nor C) when e is an array (it might be valid if e was a pointer and pointed into the middle of some array).
[Bug c++/51731] code generation bug in negative indices in arrays on 64-bit targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51731
--- Comment #2 from M.L. Hekkelman 2012-01-02
17:03:46 UTC ---
Beste paolo.carlini,
maandag 2 januari 2012, 17:23:42, schreef je:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51731
> --- Comment #1 from Paolo Carlini
> 2012-01-02 16:23:42 UTC ---
> Maybe I'm just tired (sorry in case) but I really don't see how this can
> possibly work: *negative* index?!? Can you explain?
It is a technique that dates back to, who knows when. It is even
common practice to have a zero sized array in the struct, like this:
struct page
{
charkeys[1024];
int offsets[0];
};
This way you have a fixed size page you can write to disk containing
non terminated strings in keys and the direct offsets to the keys in
the offsets arrays. Fill the page until the keys and offsets would
collide with the addition of a new key.
E.g. the B-Tree implementation of the HFS file system in MacOS
Classic uses this.
I have used code like this for many years now, and this code works
with all compilers I'm aware off but not with gcc 4.5 and 4.6.
[Bug fortran/46328] [OOP] type-bound operator call with non-trivial polymorphic operand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46328 --- Comment #9 from Damian Rouson 2012-01-02 17:01:47 UTC --- Thanks for the fix! I'm very excited about the way 4.7 is shaping up. It appears this will be a very significant release for those interested in the more advanced capabilities of OOP. Damian
[Bug c++/51462] [c++0x] ICE in cx_check_missing_mem_inits
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51462 --- Comment #1 from Dodji Seketeli 2012-01-02 17:00:21 UTC --- Author: dodji Date: Mon Jan 2 17:00:13 2012 New Revision: 182806 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182806 Log: PR c++/51462 - ICE in cx_check_missing_mem_inits gcc/cp/ PR c++/51462 * semantics.c (cx_check_missing_mem_inits): Don't assert in case of error. gcc/testsuite/ PR c++/51462 * g++.dg/cpp0x/constexpr-99.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-99.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog
[Bug bootstrap/51735] [4.7 regression] stage 3 bootstrap failure compiling tree-ssa-pre.c with r182760
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51735
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek 2012-01-02
16:54:47 UTC ---
Is the segfault in the
for (;;)
{
if ((*mem_chain)->elt == v)
{
unchain_one_elt_list (mem_chain);
break;
}
mem_chain = &(*mem_chain)->next;
}
loop (or, does the #c5 patch from that PR fix it)?
[Bug debug/51650] [4.7 regression] LTO ICE in dwarf2out_finish, at dwarf2out.c:22501 while building libxul
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51650 --- Comment #22 from Markus Trippelsdorf 2012-01-02 16:52:49 UTC --- (In reply to comment #21) > (In reply to comment #20) > > > > Fortunately it seems that this bug was the last issue that needed to be > > fixed. > > Firefox now builds fine with -lto and -g. > > Can you also check the following variant? Yes. This one is also OK.
[Bug bootstrap/51735] [4.7 regression] stage 3 bootstrap failure compiling tree-ssa-pre.c with r182760
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51735 Andreas Krebbel changed: What|Removed |Added Target||s390x-ibm-linux Priority|P3 |P2 Host||s390x-ibm-linux Build||s390x-ibm-linux
[Bug bootstrap/51735] New: [4.7 regression] stage 3 bootstrap failure compiling tree-ssa-pre.c with r182760
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51735 Bug #: 51735 Summary: [4.7 regression] stage 3 bootstrap failure compiling tree-ssa-pre.c with r182760 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: kreb...@gcc.gnu.org Bootstrap started failing on s390x with r182760: /home/andreas/git/gcc-head/gcc/tree-ssa-pre.c: In function ‘bool insert_aux(basic_block)’: /home/andreas/git/gcc-head/gcc/tree-ssa-pre.c:3791:1: internal compiler error: Segmentation fault This might be a duplicate of PR51725.
[Bug c++/51669] [4.7 Regression] ICE verify-gimple with openmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51669 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #5 from Jakub Jelinek 2012-01-02 16:29:29 UTC --- Created attachment 26218 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26218 gcc47-pr51669.patch Untested fix.
[Bug c++/51731] code generation bug in negative indices in arrays on 64-bit targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51731 --- Comment #1 from Paolo Carlini 2012-01-02 16:23:42 UTC --- Maybe I'm just tired (sorry in case) but I really don't see how this can possibly work: *negative* index?!? Can you explain?
[Bug c++/20140] template function complains about "char-array initialized from wide string"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20140 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #5 from Paolo Carlini 2012-01-02 16:16:52 UTC --- Fixed for 4.7.0.
[Bug c++/20140] template function complains about "char-array initialized from wide string"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20140 --- Comment #4 from paolo at gcc dot gnu.org 2012-01-02 16:15:55 UTC --- Author: paolo Date: Mon Jan 2 16:15:49 2012 New Revision: 182805 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182805 Log: /cp 2012-01-02 Paolo Carlini PR c++/20140 * typeck2.c (digest_init_r): Use copy_init when initializing an array of chars. /testsuite 2012-01-02 Paolo Carlini PR c++/20140 * g++.dg/template/init9.C: New. Added: trunk/gcc/testsuite/g++.dg/template/init9.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck2.c trunk/gcc/testsuite/ChangeLog
[Bug debug/51650] [4.7 regression] LTO ICE in dwarf2out_finish, at dwarf2out.c:22501 while building libxul
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51650 --- Comment #21 from Richard Guenther 2012-01-02 15:52:45 UTC --- (In reply to comment #20) > > Fortunately it seems that this bug was the last issue that needed to be fixed. > Firefox now builds fine with -lto and -g. Can you also check the following variant? Index: gcc/dwarf2out.c === --- gcc/dwarf2out.c (revision 182784) +++ gcc/dwarf2out.c (working copy) @@ -22501,15 +22501,8 @@ dwarf2out_finish (const char *filename) else if (TYPE_P (node->created_for)) context = TYPE_CONTEXT (node->created_for); - gcc_assert (context - && (TREE_CODE (context) == FUNCTION_DECL - || TREE_CODE (context) == NAMESPACE_DECL)); - - origin = lookup_decl_die (context); - if (origin) - add_child_die (origin, die); - else - add_child_die (comp_unit_die (), die); + origin = get_context_die (context); + add_child_die (origin, die); } } }
[Bug c++/51669] [4.7 Regression] ICE verify-gimple with openmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51669
Jakub Jelinek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek 2012-01-02
15:29:20 UTC ---
Caused by http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181332 aka PR51060.
Slightly more reduced testcase:
template const T & min (const T &, const T &);
void
foo ()
{
#pragma omp parallel num_threads (min (4, 5))
;
}
which ICEs starting with r181332 with just -fopenmp.
struct A { A (); ~A (); };
int foo (const A &);
void
foo ()
{
#pragma omp parallel num_threads (foo (A ()))
;
}
apparently ICEd already in 4.2 though. Guess the C++ FE needs to insert some
CLEANUP_POINT_EXPRs around the omp stmts.
[Bug c++/51722] Options "-g3" or "-ggdb3" or "-g3 -gdwarf-2" and other "-g..level3" - internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51722
--- Comment #4 from Yuriy Lalym 2012-01-02 15:16:03
UTC ---
main.cpp
---
#include
int main(int argc, char *argv[])
{
QCoreApplication a(argc, argv);
return a.exec();
}
---
pch.h
---
#include
g++-4.7 -m64 -pipe -g3 -gdwarf-4 -fvar-tracking-assignments -Wall -W
-D_REENTRANT -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/default -I.
-I/usr/include/QtCore -I/usr/include -I. -x c++-header -c pch.h -o
untitled5.gch/c++
g++-4.7 -c -include untitled5 -m64 -pipe -g3 -gdwarf-4
-fvar-tracking-assignments -Wall -W -D_REENTRANT -DQT_CORE_LIB -DQT_SHARED
-I/usr/share/qt4/mkspecs/default -I. -I/usr/include/QtCore -I/usr/include -I.
-o main.o main.cpp
*** glibc detected *** /usr/local/lib/gcc/x86_64-suse-linux/4.7.0/cc1plus:
double free or corruption (out): 0x0010c180 ***
[Bug c++/51722] Options "-g3" or "-ggdb3" or "-g3 -gdwarf-2" and other "-g..level3" - internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51722 --- Comment #3 from Yuriy Lalym 2012-01-02 15:06:30 UTC --- Without PCH errors aren't present. > all preprocessed headers to build the PCH #include It is enough one header for error origin.
[Bug bootstrap/51725] [4.7 regression] segfault in stage 3 when compiling gcc/opts.c for sparc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51725 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek 2012-01-02 14:58:30 UTC --- While the http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51725#c5 change might not be a complete solution, I think it is right and desirable, because new_elt_loc_list doesn't add the MEM location to mem_elt's locs, but to its canonical_cselib_val's locs (if different from mem_elt of course), and at that point we'd be adding e.g. into addr_list as well as first_containing_mem chain something that didn't get any MEM locs.
[Bug bootstrap/51734] [4.7 Regression] Bootstrap fails in libada
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51734 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug bootstrap/51734] New: [4.7 Regression] Bootstrap fails in libada
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51734 Bug #: 51734 Summary: [4.7 Regression] Bootstrap fails in libada Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: rgue...@gcc.gnu.org Target: s390-*-linux When linking libgnat.so we fail like a-calfor.o: In function `ada__calendar__formatting__split': /home/abuild/rpmbuild/BUILD/gcc-4.7.0-20111220/obj-s390-suse-linux/gcc/ada/rts/a -calfor.adb:399:(.text+0x3aa): relocation truncated to fit: R_390_GOT12 against symbol `ada__calendar__time_error' defined in .data.rel section in a-calend.o a-calfor.o: In function `ada__calendar__formatting__split__4': /home/abuild/rpmbuild/BUILD/gcc-4.7.0-20111220/obj-s390-suse-linux/gcc/ada/rts/a -calfor.adb:444:(.text+0x7ba): relocation truncated to fit: R_390_GOT12 against symbol `ada__calendar__time_error' defined in .data.rel section in a-calend.o a-calfor.o: In function `ada__calendar__formatting__split__2': /home/abuild/rpmbuild/BUILD/gcc-4.7.0-20111220/obj-s390-suse-linux/gcc/ada/rts/a -calfor.adb:492:(.text+0x898): relocation truncated to fit: R_390_GOT12 against symbol `ada__calendar__time_error' defined in .data.rel section in a-calend.o a-calfor.o: In function `ada__calendar__formatting__split__3': /home/abuild/rpmbuild/BUILD/gcc-4.7.0-20111220/obj-s390-suse-linux/gcc/ada/rts/a -calfor.adb:540:(.text+0x97c): relocation truncated to fit: R_390_GOT12 against symbol `ada__calendar__time_error' defined in .data.rel section in a-calend.o a-calfor.o: In function `ada__calendar__formatting__time_of__2': /home/abuild/rpmbuild/BUILD/gcc-4.7.0-20111220/obj-s390-suse-linux/gcc/ada/rts/a -calfor.adb:603:(.text+0xfcc): relocation truncated to fit: R_390_GOT12 against symbol `ada__calendar__days_in_month' defined in .rodata section in a-calend.o [more similar errors in other files omitted] make[5]: *** [gnatlib-shared-default] Error 1 make[5]: Leaving directory `/home/abuild/rpmbuild/BUILD/gcc-4.7.0-20111220/obj-s 390-suse-linux/gcc/ada' GCC was configured like + CFLAGS='-fmessage-length=0 -O2 -D_FORTIFY_SOURCE=2 -funwind-tables -fasynchron ous-unwind-tables -g -U_FORTIFY_SOURCE' + CXXFLAGS='-fmessage-length=0 -O2 -D_FORTIFY_SOURCE=2 -funwind-tables -fasynchr onous-unwind-tables -g -U_FORTIFY_SOURCE' + XCFLAGS='-fmessage-length=0 -O2 -D_FORTIFY_SOURCE=2 -funwind-tables -fasynchro nous-unwind-tables -g -U_FORTIFY_SOURCE' + TCFLAGS='-fmessage-length=0 -O2 -D_FORTIFY_SOURCE=2 -funwind-tables -fasynchro nous-unwind-tables -g -U_FORTIFY_SOURCE' + GCJFLAGS='-fmessage-length=0 -O2 -D_FORTIFY_SOURCE=2 -funwind-tables -fasynchr onous-unwind-tables -g -U_FORTIFY_SOURCE' + ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man - -libdir=/usr/lib --libexecdir=/usr/lib --enable-languages=c,c++,objc,fortran,obj -c++,java,ada --enable-checking=yes --with-gxx-include-dir=/usr/include/c++/4.7 --enable-ssp --disable-libssp --disable-libitm --disable-plugin --with-bugurl=ht tp://bugs.opensuse.org/ '--with-pkgversion=SUSE Linux' --disable-libgcj --disabl e-libmudflap --with-slibdir=/lib --with-system-zlib --enable-__cxa_atexit --enab le-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-run time-libs --enable-linker-build-id --program-suffix=-4.7 --enable-linux-futex -- without-system-libunwind --with-tune=z196 --with-arch=z10 --with-long-double-128 --enable-decimal-float --build=s390-suse-linux
[Bug c/51730] [4.7 Regression] autoconf 2.60 through 2.67 stdbool.h check fails with GCC 4.7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51730
--- Comment #4 from Richard Guenther 2012-01-02
14:15:39 UTC ---
Like
Index: gcc/fold-const.c
===
--- gcc/fold-const.c(revision 182784)
+++ gcc/fold-const.c(working copy)
@@ -8886,6 +8886,13 @@ fold_comparison (location_t loc, enum tr
indirect_base0 = true;
}
offset0 = TREE_OPERAND (arg0, 1);
+ if (host_integerp (offset0, 1)
+ && (TREE_INT_CST_LOW (offset0)
+ & ((unsigned HOST_WIDE_INT)-1 << (HOST_BITS_PER_WIDE_INT -
exact_log2 (BITS_PER_UNIT == 0)
+ {
+ bitpos0 = TREE_INT_CST_LOW (offset0) * BITS_PER_UNIT;
+ offset0 = NULL_TREE;
+ }
}
base1 = arg1;
@@ -8909,6 +8916,13 @@ fold_comparison (location_t loc, enum tr
indirect_base1 = true;
}
offset1 = TREE_OPERAND (arg1, 1);
+ if (host_integerp (offset1, 1)
+ && (TREE_INT_CST_LOW (offset1)
+ & ((unsigned HOST_WIDE_INT)-1 << (HOST_BITS_PER_WIDE_INT -
exact_log2 (BITS_PER_UNIT == 0)
+ {
+ bitpos1 = TREE_INT_CST_LOW (offset1) * BITS_PER_UNIT;
+ offset1 = NULL_TREE;
+ }
}
/* A local variable can never be pointed to by
to be beautified ...
[Bug fortran/51733] [OOP] No allocate on assign for class objects with allocatable components.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51733 --- Comment #2 from Tobias Burnus 2012-01-02 14:11:03 UTC --- (Mixed up the test cases. The PR mentioned in comment 1 is the same as in comment 0 - and a good test case. I mixed it up with PR 46262 comment 3, which is a longer example which also requires allocation on assignment.)
[Bug fortran/51733] [OOP] No allocate on assign for class objects with allocatable components.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51733 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org Blocks||51634 --- Comment #1 from Tobias Burnus 2012-01-02 14:07:17 UTC --- See also the test case in PR 51634.
[Bug c/51730] [4.7 Regression] autoconf 2.60 through 2.67 stdbool.h check fails with GCC 4.7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51730 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-01-02 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #3 from Richard Guenther 2012-01-02 14:01:19 UTC --- (In reply to comment #2) > On Mon, 2 Jan 2012, jakub at gcc dot gnu.org wrote: > > > char digs[] = "0123456789"; > > int xlcbug = 1 / (&(digs + 5)[-2 + (_Bool) 1] == &digs[4] ? 1 : > > -1); > > check. Until http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172958 > > GCC has been accepting this though, and I suppose we don't want to fold > > array > > refs that way when generating code. Would it be possible to fold it that > > way > > (try harder) just when we know we are not going to generate code based on it > > (or when we know we'd error out otherwise)? I know it sounds like an ugly > > As I understand it, the point of that commit was that the conversion of > all array references to pointer arithmetic (losing all information about > signs of indices) was problematic. But it should still be valid to fold a > comparison that way: if the addresses being compared have the same base > object and all offsets are constant integers, a final byte offset for each > address can be computed mod the size of the address space and it's OK to > fold based on comparing those offsets (if the actual, signed offsets > involved overflow anywhere, that would have been execution-time undefined > behavior). That is, I think it would be better to fix this by improving > the folding of address comparisons, rather than by changing how array > references are expanded. I think what changed is that we keep &digs[4] in the IL now, rather than representing it as &digs + 4. So it seems to be some missed folding. Indeed we have (char *) &digs + 4 == &digs[4] I'll look into this.
[Bug bootstrap/51725] [4.7 regression] segfault in stage 3 when compiling gcc/opts.c for sparc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51725
--- Comment #5 from Jakub Jelinek 2012-01-02
13:52:14 UTC ---
Seems that canonical vs. non-canonical VALUEs are mixed up.
In cselib_invalidate_mem, we don't terminate the loop:
addr = cselib_lookup (XEXP (x, 0), VOIDmode, 0, GET_MODE (x));
mem_chain = &addr->addr_list;
for (;;)
{
if ((*mem_chain)->elt == v)
{
unchain_one_elt_list (mem_chain);
break;
}
mem_chain = &(*mem_chain)->next;
}
because v is here a canonical_cselib_val of (*mem_chain)->elt. We could
perhaps
compare here canonical_cselib_val ((*mem_chain)->elt) == v instead, or just
canonicalizing the mem_elt value early when inserting it into
addr_list/*_containing_mem fixes this too:
--- gcc/cselib.c.jj2012-01-01 19:54:46.0 +0100
+++ gcc/cselib.c2012-01-02 14:46:51.180804640 +0100
@@ -1264,6 +1264,8 @@ add_mem_for_addr (cselib_val *addr_elt,
{
struct elt_loc_list *l;
+ mem_elt = canonical_cselib_val (mem_elt);
+
/* Avoid duplicates. */
for (l = mem_elt->locs; l; l = l->next)
if (MEM_P (l->loc)
ALex?
[Bug bootstrap/51725] [4.7 regression] segfault in stage 3 when compiling gcc/opts.c for sparc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51725 Jakub Jelinek changed: What|Removed |Added CC||hp at gcc dot gnu.org --- Comment #4 from Jakub Jelinek 2012-01-02 13:47:46 UTC --- *** Bug 51728 has been marked as a duplicate of this bug. ***
[Bug middle-end/51728] [4.7 Regression]: libstdc++ 25_algorithms/count_if/1.cc, 25_algorithms/partition_point/1.cc, 25_algorithms/search/1.cc SEGV ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51728 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution||DUPLICATE --- Comment #1 from Jakub Jelinek 2012-01-02 13:47:46 UTC --- ICEs in exactly the same spot as PR51725 and the same fix cures it. *** This bug has been marked as a duplicate of bug 51725 ***
[Bug fortran/51733] New: [OOP] No allocate on assign for class objects with allocatable components.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51733 Bug #: 51733 Summary: [OOP] No allocate on assign for class objects with allocatable components. Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: pa...@gcc.gnu.org The testcase in PR51634 needs explicit allocations, as in the final comment. PR51634 was closed, since the nesting of typebound operators is fixed. Paul
[Bug fortran/51634] [OOP] ICE with polymorphic operators
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51634 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #1 from Paul Thomas 2012-01-02 13:28:13 UTC --- Fixed on trunk as long as explicit allocations are inserted, as below. I will raise a separate PR for the lack of automatic allocate on assign for class objects with derived type components. Thanks for the report. Paul module field_module implicit none private public :: field type :: field real, allocatable :: f(:) contains procedure :: multiply_real => multiply procedure :: copy => copy_field generic :: operator(*)=> multiply_real generic :: assignment(=) => copy end type contains subroutine copy_field (lhs, rhs) class(field), intent(inout) :: lhs class(field), intent(in) :: rhs if (allocated (lhs%f)) deallocate (lhs%f) allocate (lhs%f(size (rhs%f, 1))) lhs%f = rhs%f end subroutine function multiply(lhs,rhs) class(field) ,intent(in) :: lhs real ,intent(in) :: rhs class(field) ,allocatable :: multiply integer :: i allocate(multiply, source = field([(0.0, i = 1, size (lhs%f, 1))])) multiply%f = lhs%f * rhs end function end module field_module program main use field_module implicit none type(field) :: f, g real :: dt, half allocate (g%f(2), source = [1.0, 2.0]) dt = 7 half = 0.5 f = g * dt * half print *, f%f end program main
[Bug tree-optimization/45397] [4.5/4.6/4.7 Regression] Issues with integer narrowing conversions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45397 Kai Tietz changed: What|Removed |Added CC||ktietz at gcc dot gnu.org --- Comment #6 from Kai Tietz 2012-01-02 13:09:09 UTC --- Hmm, we could solve this via forward-propagation in gimple, too. I have a patch which does this, but not sure if it is material for current stage. The missing patterns in forward-propagation are: - X ==/!= X -> true/false, - (type) X ==/!= (type) X -> true/false - X code Y ==/!= X code Z -> Y ==/!= Z (with code +, -, or ^). - (type) X ==/!= Y & CST -> X ==/!= (type-of-X) (Y & CST) if type-of-X has smaller, or equal precision as type and is unsigned, and type-of-x and type are of integral kind, and CST fits into type-of-X. - (type) (X op CST) -> (type) X op CST' with CST' = (type) X; and type has smaller or equal precision to type-of-x and both types are of integral kind. (for op = +,-,&,|,^) - (type) ((type2) X op Y) -> X op (type) Y, if type has smaller or equal precision to type2 and type-of-x is compatible to type, all types are of integral kind, and op is a +,-,&,|,or ^ expression.
[Bug fortran/51334] [OOP] ICE with type-bound operator: tree check: expected record_type or union_type or qual_union_type, have function_type in gfc_conv_component_ref, at fortran/trans-expr.c:556
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51334 Paul Thomas changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||pault at gcc dot gnu.org Resolution||FIXED --- Comment #2 from Paul Thomas 2012-01-02 13:08:18 UTC --- Fixed on trunk by r182796. (Forgot to put this in the ChangeLogs!). Thanks for the report Paul
[Bug fortran/51529] [OOP] gfortran.dg/class_to_type_1.f03 is miscompiled: Uninitialized variable used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51529 Paul Thomas changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #7 from Paul Thomas 2012-01-02 13:04:43 UTC --- Fixed on trunk. Thanks for the reports Paul
[Bug other/51732] New: typo in man gcc: "runt-time check"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51732 Bug #: 51732 Summary: typo in man gcc: "runt-time check" Classification: Unclassified Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: martinw...@gmail.com "man gcc" says: -mno-8bit-idiv On some processors, like Intel Atom, 8bit unsigned integer divide is much faster than 32bit/64bit integer divide. This option will generate a runt-time check. If both dividend and divisor are within range of 0 to 255, 8bit unsigned integer divide will be used instead of 32bit/64bit integer divide. Can we fix "runt-time"? This is new in gcc-4.6
[Bug fortran/46262] [OOP] tree check: expected function_type or method_type, have pointer_type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46262 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #13 from Paul Thomas 2012-01-02 13:03:12 UTC --- Fixed on trunk. Thanks to everybody for the reports and testcases. Paul
[Bug c/51730] [4.7 Regression] autoconf 2.60 through 2.67 stdbool.h check fails with GCC 4.7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51730 --- Comment #2 from joseph at codesourcery dot com 2012-01-02 13:03:35 UTC --- On Mon, 2 Jan 2012, jakub at gcc dot gnu.org wrote: > char digs[] = "0123456789"; > int xlcbug = 1 / (&(digs + 5)[-2 + (_Bool) 1] == &digs[4] ? 1 : -1); > check. Until http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172958 > GCC has been accepting this though, and I suppose we don't want to fold array > refs that way when generating code. Would it be possible to fold it that way > (try harder) just when we know we are not going to generate code based on it > (or when we know we'd error out otherwise)? I know it sounds like an ugly As I understand it, the point of that commit was that the conversion of all array references to pointer arithmetic (losing all information about signs of indices) was problematic. But it should still be valid to fold a comparison that way: if the addresses being compared have the same base object and all offsets are constant integers, a final byte offset for each address can be computed mod the size of the address space and it's OK to fold based on comparing those offsets (if the actual, signed offsets involved overflow anywhere, that would have been execution-time undefined behavior). That is, I think it would be better to fix this by improving the folding of address comparisons, rather than by changing how array references are expanded.
[Bug fortran/46328] [OOP] type-bound operator call with non-trivial polymorphic operand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46328 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED CC||pault at gcc dot gnu.org Resolution||FIXED --- Comment #8 from Paul Thomas 2012-01-02 13:01:21 UTC --- Fixed on trunk. Thanks for the report Paul
[Bug fortran/51052] [OOP] Internal compiler error in gfc_conv_component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51052 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED CC||pault at gcc dot gnu.org Resolution||FIXED --- Comment #9 from Paul Thomas 2012-01-02 13:00:36 UTC --- Fixed on trunk. Thanks for the report Paul
[Bug target/51345] [avr] Devices with 8-bit SP need their own multilib(s)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51345 --- Comment #4 from Georg-Johann Lay 2012-01-02 12:52:00 UTC --- Author: gjl Date: Mon Jan 2 12:51:57 2012 New Revision: 182797 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182797 Log: contrib/ PR target/51345 * gcc_update (files_and_dependencies): Add gcc/config/avr/t-multilib, gcc/config/avr/multilib.h. libgcc/ PR target/51345 * config/avr/lib1funcs.S: Remove FIXME comments. (SPEED_DIV): Depend on __AVR_HAVE_8BIT_SP__. gcc/ PR target/51345 * config.gcc (tm_file target=avr]): Add avr/avr-multilib.h (tmake_file target=avr): Add avr/t-multilib. * config/avr/avr-c.c (avr_cpu_cpp_builtins): Use AVR_HAVE_8BIT_SP to built-in define __AVR_HAVE_8BIT_SP__, __AVR_HAVE_16BIT_SP__. * config/avr/genmultilib.awk: New file. * config/avr/t-multilib: New auto-generated file. * config/avr/multilib.h: New auto-generated file. * config/avr/t-avr (AVR_MCUS): New variable. (genopt.sh): Use it. (s-mlib): Depend on t-multilib. (t-multilib, multilib.h): New dependencies. (s-avr-mlib): New rule to build t-multilib, multilib.h from AVR_MCUS. (MULTILIB_OPTIONS): Remove. (MULTILIB_MATCHES): Remove. (MULTILIB_DIRNAMES): Remove. (MULTILIB_EXCEPTIONS): Remove: * config/avr/genopt.sh: Don't use hard coded file name; pass AVR_MCUS from t-avr instead. Added: trunk/gcc/config/avr/genmultilib.awk trunk/gcc/config/avr/multilib.h trunk/gcc/config/avr/t-multilib Modified: trunk/contrib/ChangeLog trunk/contrib/gcc_update trunk/gcc/ChangeLog trunk/gcc/config.gcc trunk/gcc/config/avr/avr-c.c trunk/gcc/config/avr/avr-mcus.def trunk/gcc/config/avr/genopt.sh trunk/gcc/config/avr/t-avr trunk/libgcc/ChangeLog trunk/libgcc/config/avr/lib1funcs.S
[Bug fortran/46328] [OOP] type-bound operator call with non-trivial polymorphic operand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46328 --- Comment #7 from Paul Thomas 2012-01-02 12:46:15 UTC --- Author: pault Date: Mon Jan 2 12:46:08 2012 New Revision: 182796 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182796 Log: 2012-01-02 Paul Thomas PR fortran/51529 * trans-array.c (gfc_array_allocate): Null allocated memory of newly allocted class arrays. PR fortran/46262 PR fortran/46328 PR fortran/51052 * interface.c(build_compcall_for_operator): Add a type to the expression. * trans-expr.c (conv_base_obj_fcn_val): New function. (gfc_conv_procedure_call): Use base_expr to detect non-variable base objects and, ensuring that there is a temporary variable, build up the typebound call using conv_base_obj_fcn_val. (gfc_trans_class_assign): Pick out class procedure pointer assignments and do the assignment with no further prcessing. (gfc_trans_class_array_init_assign, gfc_trans_class_init_assign gfc_trans_class_assign): Move to top of file. * gfortran.h : Add 'base_expr' field to gfc_expr. * resolve.c (get_declared_from_expr): Add 'types' argument to switch checking of derived types on or off. (resolve_typebound_generic_call): Set the new argument. (resolve_typebound_function, resolve_typebound_subroutine): Set 'types' argument for get_declared_from_expr appropriately. Identify base expression, if not a variable, in the argument list of class valued calls. Assign it to the 'base_expr' field of the final expression. Strip away all references after the last class reference. 2012-01-02 Paul Thomas PR fortran/46262 PR fortran/46328 PR fortran/51052 * gfortran.dg/typebound_operator_7.f03: New. * gfortran.dg/typebound_operator_8.f03: New. Added: trunk/gcc/testsuite/gfortran.dg/typebound_operator_7.f03 trunk/gcc/testsuite/gfortran.dg/typebound_operator_8.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dump-parse-tree.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/interface.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/51052] [OOP] Internal compiler error in gfc_conv_component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51052 --- Comment #8 from Paul Thomas 2012-01-02 12:46:16 UTC --- Author: pault Date: Mon Jan 2 12:46:08 2012 New Revision: 182796 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182796 Log: 2012-01-02 Paul Thomas PR fortran/51529 * trans-array.c (gfc_array_allocate): Null allocated memory of newly allocted class arrays. PR fortran/46262 PR fortran/46328 PR fortran/51052 * interface.c(build_compcall_for_operator): Add a type to the expression. * trans-expr.c (conv_base_obj_fcn_val): New function. (gfc_conv_procedure_call): Use base_expr to detect non-variable base objects and, ensuring that there is a temporary variable, build up the typebound call using conv_base_obj_fcn_val. (gfc_trans_class_assign): Pick out class procedure pointer assignments and do the assignment with no further prcessing. (gfc_trans_class_array_init_assign, gfc_trans_class_init_assign gfc_trans_class_assign): Move to top of file. * gfortran.h : Add 'base_expr' field to gfc_expr. * resolve.c (get_declared_from_expr): Add 'types' argument to switch checking of derived types on or off. (resolve_typebound_generic_call): Set the new argument. (resolve_typebound_function, resolve_typebound_subroutine): Set 'types' argument for get_declared_from_expr appropriately. Identify base expression, if not a variable, in the argument list of class valued calls. Assign it to the 'base_expr' field of the final expression. Strip away all references after the last class reference. 2012-01-02 Paul Thomas PR fortran/46262 PR fortran/46328 PR fortran/51052 * gfortran.dg/typebound_operator_7.f03: New. * gfortran.dg/typebound_operator_8.f03: New. Added: trunk/gcc/testsuite/gfortran.dg/typebound_operator_7.f03 trunk/gcc/testsuite/gfortran.dg/typebound_operator_8.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dump-parse-tree.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/interface.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/46262] [OOP] tree check: expected function_type or method_type, have pointer_type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46262 --- Comment #12 from Paul Thomas 2012-01-02 12:46:15 UTC --- Author: pault Date: Mon Jan 2 12:46:08 2012 New Revision: 182796 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182796 Log: 2012-01-02 Paul Thomas PR fortran/51529 * trans-array.c (gfc_array_allocate): Null allocated memory of newly allocted class arrays. PR fortran/46262 PR fortran/46328 PR fortran/51052 * interface.c(build_compcall_for_operator): Add a type to the expression. * trans-expr.c (conv_base_obj_fcn_val): New function. (gfc_conv_procedure_call): Use base_expr to detect non-variable base objects and, ensuring that there is a temporary variable, build up the typebound call using conv_base_obj_fcn_val. (gfc_trans_class_assign): Pick out class procedure pointer assignments and do the assignment with no further prcessing. (gfc_trans_class_array_init_assign, gfc_trans_class_init_assign gfc_trans_class_assign): Move to top of file. * gfortran.h : Add 'base_expr' field to gfc_expr. * resolve.c (get_declared_from_expr): Add 'types' argument to switch checking of derived types on or off. (resolve_typebound_generic_call): Set the new argument. (resolve_typebound_function, resolve_typebound_subroutine): Set 'types' argument for get_declared_from_expr appropriately. Identify base expression, if not a variable, in the argument list of class valued calls. Assign it to the 'base_expr' field of the final expression. Strip away all references after the last class reference. 2012-01-02 Paul Thomas PR fortran/46262 PR fortran/46328 PR fortran/51052 * gfortran.dg/typebound_operator_7.f03: New. * gfortran.dg/typebound_operator_8.f03: New. Added: trunk/gcc/testsuite/gfortran.dg/typebound_operator_7.f03 trunk/gcc/testsuite/gfortran.dg/typebound_operator_8.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dump-parse-tree.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/interface.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/51529] [OOP] gfortran.dg/class_to_type_1.f03 is miscompiled: Uninitialized variable used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51529 --- Comment #6 from Paul Thomas 2012-01-02 12:46:14 UTC --- Author: pault Date: Mon Jan 2 12:46:08 2012 New Revision: 182796 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182796 Log: 2012-01-02 Paul Thomas PR fortran/51529 * trans-array.c (gfc_array_allocate): Null allocated memory of newly allocted class arrays. PR fortran/46262 PR fortran/46328 PR fortran/51052 * interface.c(build_compcall_for_operator): Add a type to the expression. * trans-expr.c (conv_base_obj_fcn_val): New function. (gfc_conv_procedure_call): Use base_expr to detect non-variable base objects and, ensuring that there is a temporary variable, build up the typebound call using conv_base_obj_fcn_val. (gfc_trans_class_assign): Pick out class procedure pointer assignments and do the assignment with no further prcessing. (gfc_trans_class_array_init_assign, gfc_trans_class_init_assign gfc_trans_class_assign): Move to top of file. * gfortran.h : Add 'base_expr' field to gfc_expr. * resolve.c (get_declared_from_expr): Add 'types' argument to switch checking of derived types on or off. (resolve_typebound_generic_call): Set the new argument. (resolve_typebound_function, resolve_typebound_subroutine): Set 'types' argument for get_declared_from_expr appropriately. Identify base expression, if not a variable, in the argument list of class valued calls. Assign it to the 'base_expr' field of the final expression. Strip away all references after the last class reference. 2012-01-02 Paul Thomas PR fortran/46262 PR fortran/46328 PR fortran/51052 * gfortran.dg/typebound_operator_7.f03: New. * gfortran.dg/typebound_operator_8.f03: New. Added: trunk/gcc/testsuite/gfortran.dg/typebound_operator_7.f03 trunk/gcc/testsuite/gfortran.dg/typebound_operator_8.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dump-parse-tree.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/interface.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog
[Bug target/51681] [4.7 Regression]: ICE in gcc.dg/torture/vshuf-v2si.c on ia64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51681
--- Comment #5 from Uros Bizjak 2012-01-02 12:35:25
UTC ---
Patch:
--cut here--
Index: ia64.c
===
--- ia64.c (revision 182780)
+++ ia64.c (working copy)
@@ -11085,7 +11085,7 @@ static bool
expand_vec_perm_shrp (struct expand_vec_perm_d *d)
{
unsigned i, nelt = d->nelt, shift, mask;
- rtx tmp, op0, op1;;
+ rtx tmp, hi, lo;
/* ??? Don't force V2SFmode into the integer registers. */
if (d->vmode == V2SFmode)
@@ -11101,6 +11101,11 @@ expand_vec_perm_shrp (struct expand_vec_perm_d *d)
if (d->testing_p)
return true;
+ hi = shift < nelt ? d->op1 : d->op0;
+ lo = shift < nelt ? d->op0 : d->op1;
+
+ shift %= nelt;
+
shift *= GET_MODE_UNIT_SIZE (d->vmode) * BITS_PER_UNIT;
/* We've eliminated the shift 0 case via expand_vec_perm_identity. */
@@ -3,11 +8,9 @@ expand_vec_perm_shrp (struct expand_vec_perm_d *d)
shift = 64 - shift;
tmp = gen_reg_rtx (DImode);
- op0 = (shift < nelt ? d->op0 : d->op1);
- op1 = (shift < nelt ? d->op1 : d->op0);
- op0 = gen_lowpart (DImode, op0);
- op1 = gen_lowpart (DImode, op1);
- emit_insn (gen_shrp (tmp, op0, op1, GEN_INT (shift)));
+ hi = gen_lowpart (DImode, hi);
+ lo = gen_lowpart (DImode, lo);
+ emit_insn (gen_shrp (tmp, hi, lo, GEN_INT (shift)));
emit_move_insn (d->target, gen_lowpart (d->vmode, tmp));
return true;
--cut here--
Just a bunch of mix-ups; where high/low part goes, shift value is not adjusted
after operand swap, and shift value is compared in *bits* to number of
elements.
[Bug fortran/50410] [4.6/4.7 Regression] ICE in record_reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410 --- Comment #11 from Tobias Burnus 2012-01-02 12:30:42 UTC --- See also RFC patch: http://gcc.gnu.org/ml/fortran/2011-10/msg00136.html and reply: http://gcc.gnu.org/ml/fortran/2011-10/msg00138.html
[Bug target/51681] [4.7 Regression]: ICE in gcc.dg/torture/vshuf-v2si.c on ia64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51681 --- Comment #4 from Uros Bizjak 2012-01-02 12:31:24 UTC --- (In reply to comment #1) > FAIL: gcc.dg/torture/vshuf-v8qi.c -O2 execution test It is not related to original failure; following patchlet fixes the failure: --cut here-- @@ -11207,7 +11210,7 @@ expand_vec_perm_broadcast (struct expand_vec_perm_ elt *= BITS_PER_UNIT; temp = gen_reg_rtx (DImode); emit_insn (gen_extzv (temp, gen_lowpart (DImode, d->op0), - GEN_INT (elt), GEN_INT (8))); + GEN_INT (8), GEN_INT (elt))); emit_insn (gen_mux1_brcst_qi (d->target, gen_lowpart (QImode, temp))); break; --cut here--
[Bug target/51681] [4.7 Regression]: ICE in gcc.dg/torture/vshuf-v2si.c on ia64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51681 Uros Bizjak changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |ubizjak at gmail dot com |gnu.org | --- Comment #3 from Uros Bizjak 2012-01-02 12:29:05 UTC --- I am testing patches for both issues.
[Bug c++/51731] New: code generation bug in negative indices in arrays on 64-bit targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51731 Bug #: 51731 Summary: code generation bug in negative indices in arrays on 64-bit targets Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: m.hekkel...@cmbi.ru.nl Created attachment 26217 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26217 source file containing a fully self contained bug description When compiling the attached code with -O3 the generated code is incorrect as can be seen by the output of the program. The problem was introduced in gcc 4.5, earlier versions did not have this problem.
[Bug c/51730] [4.7 Regression] autoconf 2.60 through 2.67 stdbool.h check fails with GCC 4.7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51730 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |4.7.0 --- Comment #1 from Jakub Jelinek 2012-01-02 12:14:38 UTC --- Note that autoconf 2.59 and earlier didn't contain this and autoconf 2.68 removed it again, as it started failing with newer xlc version too.
[Bug c/51730] New: [4.7 Regression] autoconf 2.60 through 2.67 stdbool.h check fails with GCC 4.7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51730 Bug #: 51730 Summary: [4.7 Regression] autoconf 2.60 through 2.67 stdbool.h check fails with GCC 4.7 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: ja...@gcc.gnu.org CC: js...@gcc.gnu.org During a distro mass rebuild, I found that many packages still have configure generated with autoconf 2.60 through 2.67, and these autoconf contain a not strictly valid C: /* Catch a bug in IBM AIX xlc compiler version 6.0.0.0 reported by James Lemley on 2005-10-05; see http://lists.gnu.org/archive/html/bug-coreutils/2005-10/msg00086.html This test is not quite right, since xlc is allowed to reject this program, as the initializer for xlcbug is not one of the forms that C requires support for. However, doing the test right would require a runtime test, and that would make cross-compilation harder. Let us hope that IBM fixes the xlc bug, and also adds support for this kind of constant expression. In the meantime, this test will reject xlc, which is OK, since our stdbool.h substitute should suffice. We also test this with GCC, where it should work, to detect more quickly whether someone messes up the test in the future. */ char digs[] = "0123456789"; int xlcbug = 1 / (&(digs + 5)[-2 + (_Bool) 1] == &digs[4] ? 1 : -1); check. Until http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172958 GCC has been accepting this though, and I suppose we don't want to fold array refs that way when generating code. Would it be possible to fold it that way (try harder) just when we know we are not going to generate code based on it (or when we know we'd error out otherwise)? I know it sounds like an ugly hack, unfortunately autoconf 2.6[0-7] generated configure scripts are going to be around for many years and the stdbool.h checks would fail in hundreds of packages.
[Bug debug/49951] [4.5/4.6/4.7 Regression] Debug stepping behavior regarding g++ Class destructor has changed for the worse starting at gcc 4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49951 --- Comment #15 from dodji at seketeli dot org 2012-01-02 12:01:45 UTC --- > It would be very helpful to get this into 4.6.3 too if it's safe Sure thing. I am currently testing the patch on 4.6. Thanks for the head-up.
[Bug rtl-optimization/47477] [4.6/4.7/4.8 regression] Sub-optimal mov at end of method
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47477 Jakub Jelinek changed: What|Removed |Added AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | Target Milestone|4.7.0 |4.8.0 Summary|[4.6/4.7 regression]|[4.6/4.7/4.8 regression] |Sub-optimal mov at end of |Sub-optimal mov at end of |method |method --- Comment #9 from Jakub Jelinek 2012-01-02 11:36:32 UTC --- Postponing for 4.8, as agreed by Richard this is stage1 material and unfortunately has been forgotten during 4.7 stage1. From quick glance at it, we want to reimplement get_unwidened and the narrowing integer conversion part of convert_to_integer on GIMPLE, must likely in forwprop.
[Bug target/51729] dspr2-MULT.c and dspr2-MULTU.c fail for MIPS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51729 --- Comment #1 from rsandifo at gcc dot gnu.org 2012-01-02 11:33:39 UTC --- Author: rsandifo Date: Mon Jan 2 11:33:35 2012 New Revision: 182793 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182793 Log: gcc/testsuite/ PR target/51729 * gcc.target/mips/dspr2-MULT.c: Remove -ffixed-hi -ffixed-lo. XFAIL. * gcc.target/mips/dspr2-MULTU.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/mips/dspr2-MULT.c trunk/gcc/testsuite/gcc.target/mips/dspr2-MULTU.c
[Bug target/51729] New: dspr2-MULT.c and dspr2-MULTU.c fail for MIPS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51729 Bug #: 51729 Summary: dspr2-MULT.c and dspr2-MULTU.c fail for MIPS Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: rsand...@gcc.gnu.org dspr2-MULT.c and dspr2-MULTU.c are supposed to test that we use the DSP accumulator registers to parallelise multiplications. They don't work in 4.7, and I'm about to XFAIL them. There seem to be two main problems: * The cost of moving between DSP accumulators is greater than the cost of moving a DSP register to or from memory. When I last looked, this was enough to make the register allocator consider memory to be cheaper. This isn't a problem without -mdsp because there is then only one accumulator register, LO+HI. (Note that we no longer allow HI and LO to store independent values.) The cost of moving between accumulators is therefore ignored. On some (many?) targets, moving something out of an accumulator and back again _is_ more expensive than storing an accumulator to memory, so this isn't necessarily a bug in the backend. * Even if we massage the costs to avoid that problem, each of the pseudos that we'd like to use accumulators has one "=ka" constraint and one "d" constraint. At one point this meant that DSP_REGS and GENERAL_REGS had the same cost, and reg_alloc_order could be used to prefer accumulators: http://gcc.gnu.org/ml/gcc/2010-12/msg00471.html http://gcc.gnu.org/ml/gcc/2011-01/msg00093.html But GENERAL_REGS now seems to have a lower cost, and since GENERAL_REGS are much easier to spill than DSP_REGS, it's hard to argue with that.
