[Bug c++/53057] New: [c++0x] ICE on construction off of initializer list with overloads for constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53057
Bug #: 53057
Summary: [c++0x] ICE on construction off of initializer list
with overloads for constructor
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: cmalo...@tagged.com
The following code causes GCC 4.7.0 to fail with the message internal compiler
error: in joust, at cp/call.c:8009
#include string
#include vector
using namespace std;
struct TFoo {
TFoo(const vectorstring vs);
TFoo(const string s);
};
TFoo foo({1, 2, 3});
$ g++ overload_ice.cc -std=c++0x
overload_ice.cc:11:25: internal compiler error: in joust, at cp/call.c:8009
[Bug c++/53025] [C++11] noexcept operator depends on copy-elision
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53025 --- Comment #2 from Marc Glisse marc.glisse at normalesup dot org 2012-04-21 07:45:57 UTC --- Created attachment 27210 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27210 patch Bootstrapped and regression tested. Not posting it to gcc-patches yet, for several reasons: - I have other patches (at least 3) waiting for a review, - I am not 100% certain that this can't cause legitimate elisions to be missed (say if something is first instantiated inside the noexcept), - people may not like using globals that way, - I might prefer the old behavior... but if anyone wants to submit it, feel free.
[Bug c++/53057] [c++0x] ICE on construction off of initializer list with overloads for constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53057 Marc Glisse marc.glisse at normalesup dot org changed: What|Removed |Added CC||marc.glisse at normalesup ||dot org --- Comment #1 from Marc Glisse marc.glisse at normalesup dot org 2012-04-21 07:57:23 UTC --- This seems to have been fixed recently on trunk. Maybe related to PR c++/52905 ?
[Bug c/53058] New: Another ice in remove_range_assertions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53058 Bug #: 53058 Summary: Another ice in remove_range_assertions Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: dcb...@hotmail.com Created attachment 27211 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27211 C source code I just tried to compile the package quake3-1.36-13 on gcc-4.8 trunk dated 20120418 on an AMD x86_64 box. The compiler said code/botlib/be_ai_move.c: In function 'BotFuncBobStartEnd': code/botlib/be_ai_move.c:2227:6: internal compiler error: in remove_range_assertions, at tree-vrp.c:5937 void BotFuncBobStartEnd(aas_reachability_t *reach, vec3_t start, vec3_t end, vec3_t origin) ^ Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Preprocessed source code attached. Flag -O2 required.
[Bug bootstrap/52947] [4.7/4.8 Regression] bootstrap fails due to wrong include search path composition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52947 ralpheng...@gmail.com ralphengels at gmail dot com changed: What|Removed |Added CC||ralphengels at gmail dot ||com --- Comment #3 from ralphengels at gmail dot com ralphengels at gmail dot com 2012-04-21 09:39:19 UTC --- Just chiming in. Im also running into this problem in stage2 where it fails to find stdarg.h. As an experiment i tried reverting kai's work but it still fails to find system headers. A non bootstrap build works but im having problems with programs using libstdc++. All programs compiled that depends on libstdc++ will crash with initialization error 0xc05. My machine is Win7 64. All previous gcc versions build fine btw. And work also. I have tried with versions compiled by other parts and the problem persists.
[Bug bootstrap/53021] [4.8 Regression] bootstrap failure on Linux/ia32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53021 rsand...@gcc.gnu.org rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rsandifo at gcc dot gnu.org |gnu.org | --- Comment #5 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org 2012-04-21 10:23:10 UTC --- Looks like there's another case in store-motion.c. I'm making another pass at cleaning up this whole mess -- sorry again for making such a horlicks of it all.
[Bug c/53058] Another ice in remove_range_assertions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53058
Markus Trippelsdorf markus at trippelsdorf dot de changed:
What|Removed |Added
CC||markus at trippelsdorf dot
||de
--- Comment #1 from Markus Trippelsdorf markus at trippelsdorf dot de
2012-04-21 11:36:37 UTC ---
Reduced:
% cat test.i
int a,b,c=0;
fn1 () {
c = b 16;
if (c 32767)
c = 0;
a = b;
}
[Bug c++/52008] [C++0x] ICE when adding partial specialization for variadic-templated structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52008 --- Comment #8 from Michal Malecki ethouris at gmail dot com 2012-04-21 12:06:36 UTC --- Jason, There is no better or worse specialization - the first one is a primary template, not a specialization. The example of tuple_slice1, int, int, int will just not match the specialization with first argument 0 because, simply, here the first argument is 1. I have stated that the parameter pack is itself not a type specification, just a higher level construct that will be first resolved to the actual list of arguments and only then checked for anything else. But I'm not exactly sure of that, so maybe the argument pack specification should undergo specialization rules by itself. There are, for me, only two logical methods to solve this problem: 1. The code is accepted, even though it violates the standard a bit; pedantic flags may turn it off. In particular, the specialization is treated as really a specialization because it matches the name and all tries to instantiate the primary template can be redirected to the specialization, as long as it matches the specialized argument. Both the specialization and the primary template are considered only after the argument pack is expanded, in which case both will expand to exactly the same list of arguments - so the expanded versions will have the primary-specialization relationship. 2. The code is rejected the following way: the template specialization definition is itself rejected because due to not covered explicitly all explicit parameters (that is, all but parameter pack) this is not considered template specialization. But the template specialization can only be considered invalidly defined specialization, if template parameters that are passed to the template are incorrect according to the template parameter definition in the primary template.
[Bug c/53060] New: Typo in build_binary_op for scalar-vector ops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53060 Bug #: 53060 Summary: Typo in build_binary_op for scalar-vector ops Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: marc.gli...@normalesup.org Hello, in file c-typeck.c, function build_binary_op, for mixed scalar-vector operations, there are 2 cases: stv_firstarg and stv_secondarg. The first one has: op0 = c_wrap_maybe_const (op0, true); while the second has: op0 = c_wrap_maybe_const (op1, true); I think the second one should read op1 = ..., for symmetry. I haven't managed to come up with a testcase that runs this line of code :-(
[Bug c++/53059] New: sizeof(std::list)=12 was 8 in previous releases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53059 Bug #: 53059 Summary: sizeof(std::list)=12 was 8 in previous releases Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: ratnikov...@ya.ru
[Bug c++/53059] sizeof(std::list)=12 was 8 in previous releases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53059
--- Comment #1 from ratnikov.ev at ya dot ru 2012-04-21 12:23:36 UTC ---
g++ -v
Reading specs from /usr/lib/gcc/i486-slackware-linux/4.7.0/specs
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i486-slackware-linux/4.7.0/lto-wrapper
Target: i486-slackware-linux
Configured with: ../gcc-4.7.0/configure --prefix=/usr --libdir=/usr/lib
--mandir=/usr/man --infodir=/usr/info --enable-shared --enable-bootstrap
--enable-languages=ada,c,c++,fortran,go,java,lto,objc --enable-threads=posix
--enable-checking=release --enable-objc-gc --with-system-zlib
--with-python-dir=/lib/python2.6/site-packages --disable-libunwind-exceptions
--enable-__cxa_atexit --enable-libssp --enable-lto --with-gnu-ld --verbose
--enable-java-home --with-java-home=/usr/lib/jvm/jre
--with-jvm-root-dir=/usr/lib/jvm --with-jvm-jar-dir=/usr/lib/jvm/jvm-exports
--with-arch-directory=i386
--with-antlr-jar=/root/slackware-current/source/d/gcc/antlr-runtime-3.4.jar
--enable-java-awt=gtk --disable-gtktest --with-arch=i486
--target=i486-slackware-linux --build=i486-slackware-linux
--host=i486-slackware-linux
Thread model: posix
gcc version 4.7.0 (GCC)
cat sz.cc
#include list
#include iostream
int main(int ac, char* av[])
{
constexpr size_t list_sz(sizeof(std::listint));
static_assert(list_sz == 8, size of list changed);
return 0;
}
g++ -std=c++0x -save-temps sz.cc -o sz
sz.cc: In function ‘int main(int, char**)’:
sz.cc:7:5: error: static assertion failed: size of list changed
no *.i files were generated
[Bug c++/53061] New: [C/ObjC/C++/ObjC++] cleanup diagnostics initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53061 Bug #: 53061 Summary: [C/ObjC/C++/ObjC++] cleanup diagnostics initialization Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: m...@gcc.gnu.org Created attachment 27212 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27212 patch See http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00443.html and other emails in that thread. My latest patch is attached. Changelog is: 2012-04-09 Manuel López-Ibáñez m...@gcc.gnu.org * doc/invoke.texi (fmessage-length): Update. * pretty-print.h (getenv_columns): New. * c-objc-common.c (c_objc_common_init): Do not do diagnostics initialization here. c-family/ * c-opts.c (c_common_initialize_diagnostics): Rename as c_common_diagnostics_defaults. Set defaults here. * c-common.h (c_common_initialize_diagnostics): Likewise. cp/ * cp-objcp-common.c (cxx_initialize_diagnostics): Move from here to ... * error.c: ... here. (init_error): Delete. * cp-tree.h (init_error): Delete. * lex.c (cxx_init): Do not call init_error. * cxx-pretty-print.c (pp_cxx_pretty_printer_init): Do not set default message length here. I prefer to focus on other things, so feel free to take it and do whatever you need to get it approved.
[Bug c++/53061] [C/ObjC/C++/ObjC++] cleanup diagnostics initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53061 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||tromey at gcc dot gnu.org --- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-04-21 12:54:32 UTC --- *** Bug 32614 has been marked as a duplicate of this bug. ***
[Bug c++/32614] -fmessage-length documentation and implementation disagree
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32614 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||DUPLICATE --- Comment #4 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-04-21 12:54:32 UTC --- The patch in PR 53061 also fixes this. *** This bug has been marked as a duplicate of bug 53061 ***
[Bug c++/52008] [C++0x] ICE when adding partial specialization for variadic-templated structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52008 --- Comment #9 from Jason Merrill jason at gcc dot gnu.org 2012-04-21 13:06:10 UTC --- (In reply to comment #8) There is no better or worse specialization - the first one is a primary template, not a specialization. But if it were another partial specialization, it would not be less specialized, and I think a partial specialization must be more specialized than a hypothetical partial specialization form of the primary template. The example of tuple_slice1, int, int, int will just not match the specialization with first argument 0 because, simply, here the first argument is 1. Right, that one isn't ambiguous, but then it leads to the instantiation of tuple_slice0,int,int which is. 2. The code is rejected the following way: the template specialization definition is itself rejected because due to not covered explicitly all explicit parameters (that is, all but parameter pack) this is not considered template specialization. Right, because the partial specialization doesn't specialize the Type1 parameter, it is not more specialized than the primary template. You should rewrite your code the way I did, and then do something to address the ambiguity; possibly a third partial specialization.
[Bug libstdc++/52839] [4.7/4.8 Regression] double free or corruption running tr1/.../default_weaktoshared.exe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839 --- Comment #33 from Alan Modra amodra at gcc dot gnu.org 2012-04-21 13:28:59 UTC --- Author: amodra Date: Sat Apr 21 13:28:53 2012 New Revision: 186651 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186651 Log: PR libstdc++/52839 missed from last delta Modified: branches/gcc-4_7-branch/libstdc++-v3/configure
[Bug libstdc++/52839] [4.7/4.8 Regression] double free or corruption running tr1/.../default_weaktoshared.exe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839 --- Comment #32 from Alan Modra amodra at gcc dot gnu.org 2012-04-21 13:27:51 UTC --- Author: amodra Date: Sat Apr 21 13:27:44 2012 New Revision: 186650 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186650 Log: PR libstdc++/52839 * acinclude.m4 (_GLIBCXX_ATOMIC_BUILTINS): Do not depend on glibcxx_cv_atomic_long_long. * configure: Regenerate. Modified: branches/gcc-4_7-branch/libstdc++-v3/ChangeLog branches/gcc-4_7-branch/libstdc++-v3/acinclude.m4
[Bug libstdc++/52839] [4.7/4.8 Regression] double free or corruption running tr1/.../default_weaktoshared.exe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839 Alan Modra amodra at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #34 from Alan Modra amodra at gmail dot com 2012-04-21 13:30:38 UTC --- fixed
[Bug c/53060] Typo in build_binary_op for scalar-vector ops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53060 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org, ||rguenth at gcc dot gnu.org --- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-04-21 13:42:32 UTC --- Have you tried setting a breakpoint there when running: * gcc.c-torture/execute/scal-to-vec1.c: New test. * gcc.c-torture/execute/scal-to-vec2.c: New test. * gcc.c-torture/execute/scal-to-vec3.c: New test. * gcc.dg/scal-to-vec1.c: New test. * gcc.dg/scal-to-vec2.c: New test. But it could also happen that the code is dead. It may be that build_binary_op or its callers rearrange the operators so VECTOR*SCALAR is always handled as SCALAR*VECTOR?
[Bug middle-end/52821] [4.8 Regression] 191.fma3d in SPEC CPU 2000 failed to build with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52821 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2012-04-21 14:14:15 UTC --- Fixed as of revision 186391.
[Bug middle-end/53062] New: [4.8 Regression] 445.gobmk in SPEC CPU 2006 failed to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53062 Bug #: 53062 Summary: [4.8 Regression] 445.gobmk in SPEC CPU 2006 failed to build Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com CC: areg.melikadam...@gmail.com On Linux/x86-64, revision 186591 gave gcc -c -o engine/matchpat.o -DSPEC_CPU -DNDEBUG -DHAVE_CONFIG_H -I. -I.. -I../include -I./include -O3 -funroll-loops -ffast-math -fwhole-program -flto=jobserver -fuse-linker-plugin -DSPEC_CPU_LP64 engine/matchpat.c engine/matchpat.c: In function 'dfa_prepare_for_match': engine/matchpat.c:504:1: internal compiler error: Segmentation fault dfa_prepare_for_match(int color) ^ Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Revision 186507 is OK.
[Bug c/53063] New: encode group options in the .opt files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53063 Bug #: 53063 Summary: encode group options in the .opt files Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: m...@gcc.gnu.org Encoding group options in the .opt files will help to delete a lot of code and fix a lot of bugs in the way options enabled by other options are handled. For example, Wall C ObjC C++ ObjC++ Warning Enable most warning messages Enables(Wwhatever, Wfoo=2) EnablesIf((optimize = 2), Warray-bounds) EnablesIf((c_dialect_cxx ()), Wsign-compare, Wreorder, Wnarrowing) Suggestions on how to implement this are welcome.
[Bug c/53064] New: -Wsenquence-point behaves inconsistently
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53064
Bug #: 53064
Summary: -Wsenquence-point behaves inconsistently
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: wenbin...@gmail.com
This is my first bug report here, so please bear with me.
Compiling the following code
int f(int a)
{
return 0;
}
main()
{
int a = 0;
a + f(++a ? 0 : 0);
}
with -Wall gives
test.c:8:9: warning: operation on ‘a’ may be undefined [-Wsequence-point]
while compiling
main()
{
int a = 0;
a + (++a ? 0 : 0);
}
with -Wall produces no warning about sequence points.
I think (not sure though) both are UB.
gcc -v information:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/src/gcc-4.7-20120414/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--enable-libstdcxx-time --enable-gnu-unique-object --enable-linker-build-id
--with-ppl --enable-cloog-backend=isl --enable-lto --enable-gold
--enable-ld=default --enable-plugin --with-plugin-ld=ld.gold
--with-linker-hash-style=gnu --disable-multilib --disable-libssp
--disable-build-with-cxx --disable-build-poststage1-with-cxx
--enable-checking=release
Thread model: posix
gcc version 4.7.0 20120414 (prerelease) (GCC)
Sorry if the bug is invalid, or if my English is poor.
[Bug c/35441] [4.5/4.6/4.7/4.8 regression] Completely broken diagnostics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35441 --- Comment #8 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-04-21 14:53:25 UTC --- Author: manu Date: Sat Apr 21 14:53:21 2012 New Revision: 186652 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186652 Log: 2012-04-21 Manuel López-Ibáñez m...@gcc.gnu.org PR 35441 * c-typeck.c (inform_declaration): New. (build_function_call_vec): Do not pretty-print expressions when caret is enabled. (convert_arguments): Use inform_declaration. cp/ * typeck.c (cp_build_function_call_vec): Do not pretty-print expressions when caret is enabled. testsuite/ * c-c++-common/pr35441.C: New. Modified: trunk/gcc/ChangeLog trunk/gcc/c-typeck.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog
[Bug c/53060] Typo in build_binary_op for scalar-vector ops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53060
--- Comment #2 from Marc Glisse marc.glisse at normalesup dot org 2012-04-21
14:59:54 UTC ---
(In reply to comment #1)
* gcc.dg/scal-to-vec2.c: New test.
This one runs the problematic code, but since this is a compile-only test, it
can't detect a problem. A variant that does fail:
extern void abort (void);
int f(void) { return 2; }
unsigned intg(void) { return 5; }
unsigned inth = 1;
typedef unsigned int vec __attribute__((vector_size(16)));
vec i = { 1, 2, 3, 4};
vec fv1(void) { return i + (h ? f() : g()); }
vec fv2(void) { return (h ? f() : g()) + i; }
int main(){
vec j = fv1();
if (j[0] != 3) abort();
}
(it works ok with fv2)
[Bug c/35441] pretty-printer cannot handle some expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35441 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org Summary|[4.5/4.6/4.7/4.8|pretty-printer cannot |regression] Completely |handle some expressions |broken diagnostics | --- Comment #9 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-04-21 15:03:42 UTC --- This is fixed when using -fdiagnostics-show-caret, which is the default. However, the underlying problem is still there, so I cannot be considered fixed.
[Bug c++/53065] New: ICE replace_reg_with_saved_mem, at caller-save.c:1125
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53065 Bug #: 53065 Summary: ICE replace_reg_with_saved_mem, at caller-save.c:1125 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: web...@webbot.org.uk Created attachment 27213 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27213 Pre-processor output Environment: Windows 7 (64 bit). Compiler source v4.7.0 compiled under CygWin for avr target. avr-g++ -v -save-temps -g -Wall -Wextra -DF_CPU=800 -mmcu=atmega328p -gdwarf-2 -fpack-struct -fshort-enums -funsigned-char -funsigned-bitfields -fno-threadsafe-statics -fno-strict-aliasing -fwrapv -I../../.. -Os -c -o AHRS.o AHRS.cpp outputs Using built-in specs. COLLECT_GCC=avr-g++ Target: avr Configured with: ../configure --target=avr --prefix=/cygdrive/c/avrgcc --with-gm p-lib=/usr/local/lib --with-mpfr-lib=/usr/local/lib --with-mpc-lib=/usr/local/li b --with-dwarf2 --enable-languages=c,c++ --disable-libssp --disable-nls Thread model: single gcc version 4.7.0 (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-g' '-Wall' '-Wextra' '-D' 'F_CPU=80 0' '-mmcu=atmega328p' '-gdwarf-2' '-fpack-struct' '-fshort-enums' '-funsigned-ch ar' '-funsigned-bitfields' '-fno-threadsafe-statics' '-fno-strict-aliasing' '-fw rapv' '-I' '../../..' '-Os' '-c' '-o' 'AHRS.o' /cygdrive/c/avrgcc/libexec/gcc/avr/4.7.0/cc1plus.exe -E -quiet -v -I ../../.. - imultilib avr5 -D F_CPU=800 AHRS.cpp -mmcu=atmega328p -Wall -Wextra -fpack-s truct -fshort-enums -funsigned-char -funsigned-bitfields -fno-threadsafe-statics -fno-strict-aliasing -fwrapv -g -gdwarf-2 -fworking-directory -Os -fpch-preproc ess -fno-rtti -fno-enforce-eh-specs -fno-exceptions -o AHRS.ii ignoring nonexistent directory /cygdrive/c/avrgcc/lib/gcc/avr/4.7.0/../../../.. /avr/include/c++/4.7.0 ignoring nonexistent directory /cygdrive/c/avrgcc/lib/gcc/avr/4.7.0/../../../.. /avr/include/c++/4.7.0/avr/avr5 ignoring nonexistent directory /cygdrive/c/avrgcc/lib/gcc/avr/4.7.0/../../../.. /avr/include/c++/4.7.0/backward ignoring nonexistent directory /cygdrive/c/avrgcc/lib/gcc/avr/4.7.0/../../../.. /avr/sys-include #include ... search starts here: #include ... search starts here: ../../.. /cygdrive/c/avrgcc/lib/gcc/avr/4.7.0/include /cygdrive/c/avrgcc/lib/gcc/avr/4.7.0/include-fixed /cygdrive/c/avrgcc/lib/gcc/avr/4.7.0/../../../../avr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-g' '-Wall' '-Wextra' '-D' 'F_CPU=80 0' '-mmcu=atmega328p' '-gdwarf-2' '-fpack-struct' '-fshort-enums' '-funsigned-ch ar' '-funsigned-bitfields' '-fno-threadsafe-statics' '-fno-strict-aliasing' '-fw rapv' '-I' '../../..' '-Os' '-c' '-o' 'AHRS.o' /cygdrive/c/avrgcc/libexec/gcc/avr/4.7.0/cc1plus.exe -fpreprocessed AHRS.ii -qu iet -dumpbase AHRS.cpp -mmcu=atmega328p -auxbase-strip AHRS.o -g -gdwarf-2 -Os - Wall -Wextra -version -fpack-struct -fshort-enums -funsigned-char -funsigned-bit fields -fno-threadsafe-statics -fno-strict-aliasing -fwrapv -fno-rtti -fno-enfor ce-eh-specs -fno-exceptions -o AHRS.s GNU C++ (GCC) version 4.7.0 (avr) compiled by GNU C version 4.5.3, GMP version 5.0.4, MPFR version 3.1.0, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C++ (GCC) version 4.7.0 (avr) compiled by GNU C version 4.5.3, GMP version 5.0.4, MPFR version 3.1.0, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 318bd707d55fc0ebdb58cccdc81ea14b AHRS.cpp:75:12: warning: unused parameter 'loopStart' [-Wunused-parameter] AHRS.cpp:95:12: warning: unused parameter 'loopCount' [-Wunused-parameter] AHRS.cpp:95:12: warning: unused parameter 'loopStart' [-Wunused-parameter] AHRS.cpp: In function 'void readSensors()': AHRS.cpp:297:1: internal compiler error: in replace_reg_with_saved_mem, at calle r-save.c:1125 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. I have attached the pre-processor output file AHRS.ii It will compile ok if the optimiser is set to -O0 or -O1 .
[Bug c/53064] -Wsequence-point behaves inconsistently
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53064 Wenbin Lv wenbin816 at gmail dot com changed: What|Removed |Added Severity|minor |trivial
[Bug c/53066] New: Wshadow should not warn for shadowing an extern function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53066 Bug #: 53066 Summary: Wshadow should not warn for shadowing an extern function Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: m...@gcc.gnu.org As described by Linus here: http://lkml.indiana.edu/hypermail/linux/kernel/0611.3/1020.html This makes Wshadow useless on real code.
[Bug c/53066] Wshadow should not warn for shadowing an extern function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53066
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
Keywords||patch
--- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-04-21
16:41:42 UTC ---
Testing this patch:
--- gcc/c-decl.c(revision 186353)
+++ gcc/c-decl.c(working copy)
@@ -2570,12 +2570,19 @@ warn_if_shadowing (tree new_decl)
}
else if (TREE_CODE (old_decl) == PARM_DECL)
warning (OPT_Wshadow, declaration of %q+D shadows a parameter,
new_decl);
else if (DECL_FILE_SCOPE_P (old_decl))
- warning (OPT_Wshadow, declaration of %q+D shadows a global
- declaration, new_decl);
+ {
+ /* Do not warn for variables shadowing a function
+ declaration. */
+ if (TREE_CODE (old_decl) == FUNCTION_DECL)
+ break;
+ warning_at (DECL_SOURCE_LOCATION (new_decl), OPT_Wshadow,
+ declaration of %qD shadows a global declaration,
+ new_decl);
+ }
else if (TREE_CODE (old_decl) == FUNCTION_DECL
DECL_BUILT_IN (old_decl))
{
warning (OPT_Wshadow, declaration of %q+D shadows
a built-in function, new_decl);
[Bug middle-end/53062] [4.8 Regression] 445.gobmk in SPEC CPU 2006 failed to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53062 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2012-04-21 17:15:57 UTC --- It is caused by revision 186529: http://gcc.gnu.org/ml/gcc-cvs/2012-04/msg00480.html
[Bug c++/53059] sizeof(std::list)=12 was 8 in previous releases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53059 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-04-21 18:05:42 UTC --- Why do you think this is a bug? The C++ 2011 standard requires that std::list::size() is O(1) so a new member variable is needed to store the container's size.
[Bug c++/53059] sizeof(std::list)=12 was 8 in previous releases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53059 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2012-04-21 18:06:31 UTC --- N.B. the size is still 8 with -std=c++98
[Bug middle-end/53062] [4.8 Regression] 445.gobmk in SPEC CPU 2006 failed to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53062 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC|rguenth at gcc dot gnu.org |matz at gcc dot gnu.org --- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2012-04-21 18:09:14 UTC --- (In reply to comment #1) It is caused by revision 186529: http://gcc.gnu.org/ml/gcc-cvs/2012-04/msg00480.html Wrong revision. It is caused by revision 186530: http://gcc.gnu.org/ml/gcc-cvs/2012-04/msg00481.html
[Bug middle-end/53048] [4.8 Regression] 256.bzip2 in SPEC CPU 2000 failed to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53048 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||matz at gcc dot gnu.org --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2012-04-21 18:18:30 UTC --- It is caused by revision 186530: http://gcc.gnu.org/ml/gcc-cvs/2012-04/msg00481.html
[Bug bootstrap/53030] [4.8 Regression] LTO bootstrap failed with bootstrap-profiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53030 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2012-04-21 18:31:33 UTC --- Works as of revision 186620.
[Bug bootstrap/53021] [4.8 Regression] bootstrap failure on Linux/ia32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53021 rsand...@gcc.gnu.org rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #7 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org 2012-04-21 18:57:01 UTC --- Patch applied.
[Bug bootstrap/53021] [4.8 Regression] bootstrap failure on Linux/ia32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53021 --- Comment #6 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org 2012-04-21 18:55:22 UTC --- Author: rsandifo Date: Sat Apr 21 18:55:18 2012 New Revision: 186657 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186657 Log: gcc/ PR bootstrap/53021 * rtl.def (ADDRESS): Use i rather than w. * rtl.h (find_base_term): Delete. (may_be_sp_based_p): Declare. * rtl.c (rtx_code_size): Remove ADDRESS special case. * alias.h (UNIQUE_BASE_VALUE_SP, UNIQUE_BASE_VALUE_ARGP) (UNIQUE_BASE_VALUE_FP, UNIQUE_BASE_VALUE_HFP): Move to... * alias.c: ...here. (find_base_term): Make static. (may_be_sp_based_p): New function. * dse.c (record_store): Use it. * store-motion.c (store_killed_in_insn): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/alias.c trunk/gcc/alias.h trunk/gcc/dse.c trunk/gcc/rtl.c trunk/gcc/rtl.def trunk/gcc/rtl.h trunk/gcc/store-motion.c
[Bug middle-end/53032] [4.8 Regression] 447.dealII in SPEC CPU 2006 failed to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53032 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Component|c++ |middle-end --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2012-04-21 20:10:19 UTC --- Revision 186516 is OK. This is wrong. It is caused by revision 186488: http://gcc.gnu.org/ml/gcc-cvs/2012-04/msg00439.html
[Bug middle-end/53047] [4.8 Regression] 482.sphinx3 in SPEC CPU 2006 miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53047 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2012-04-21 21:36:35 UTC --- It is caused by revision 186566: http://gcc.gnu.org/ml/gcc-cvs/2012-04/msg00517.html
[Bug c++/53059] sizeof(std::list)=12 was 8 in previous releases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53059 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2012-04-21 22:18:25 UTC --- .
[Bug middle-end/53046] [4.8 Regression] New libstdc++ test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53046 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2012-04-21 22:42:18 UTC --- It is caused by revision 186592: http://gcc.gnu.org/ml/gcc-cvs/2012-04/msg00543.html
[Bug target/53056] bad code generated for ARM NEON with vector types in structs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53056 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-04-21 CC||rearnsha at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #3 from Richard Earnshaw rearnsha at gcc dot gnu.org 2012-04-21 23:35:27 UTC --- Try -fno-split-wide-types.
[Bug c++/53067] New: c++0x GCC 4.7.0 Regression std::ref with unordered sets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53067
Bug #: 53067
Summary: c++0x GCC 4.7.0 Regression std::ref with unordered
sets
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: cmalo...@tagged.com
Building the following code with gcc4.7 snapshot 20120421 fails, but passed
with gcc4.6.
$g++ -std=c++11
#include functional
#include unordered_set
int main(int, char**){
std::unordered_mapint Foo;
ref(Foo);
}
[Bug c++/53059] sizeof(std::list)=12 was 8 in previous releases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53059 --- Comment #5 from ratnikov.ev at ya dot ru 2012-04-22 03:26:43 UTC --- Anyway there will be no backward compability. I mean when I use a library compiled with gcc-4.7.0 + 0x with other code compiled with pervious gcc versions (and vice versa). It is real problem to use 3rd parties (gcc-4.7 + 0x) with my project (gcc-4.5).
[Bug c++/53068] New: collect2 breaks link order control
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53068 Bug #: 53068 Summary: collect2 breaks link order control Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: igod...@pacbell.net Created attachment 27214 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27214 generated linker script Not sure which heading collect2 goes under; placed in c++ heading by default. We use a linker script to control static initialization order. We manually maintain files that give intra- and inter-project dependencies from which a tool produces a partial ordering file that is added to each project library. Before linking, another tool collects the partial order files of all libraries referenced on the link command line to produce a global partial order for the program being linked. It then takes the default linker script that gcc uses and textually modifies it with linker commands that reflect the partial order. We then pass the modified script to gcc on the gcc linker command line, which invokes collect2 and the system linker in the normal way. For this to work we depend on the collect2 priority sort defaulting to the file order that the system gives it on the first link pass. That is, we depend on the sort being stable in the absence of program-specified priorities, which we do not use (priority is impractical for large developments that incorporate third-party binaries; our system uses local relative dependency rather than trying to maintain global absolute priority). This has worked for a decade, but breaks in 4.7. Because we are using the same linker I conclude that there have been changes in collect2, most likely the introduction of an unstable sort. I will attach a representative script generated by our system.
[Bug c++/53068] collect2 breaks link order control
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53068 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-04-22 03:53:53 UTC --- I don't think this is collect2 changing the order but rather .init_array which changes the order.
[Bug c++/53068] collect2 breaks link order control
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53068 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2012-04-22 03:56:07 UTC --- See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770#c76 for more info. Really any dependance on link order is invalid for C++ code.
[Bug c++/53068] collect2 breaks link order control
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53068 --- Comment #3 from Ivan Godard igodard at pacbell dot net 2012-04-22 04:49:46 UTC --- Wow - this will break a lot of big users - we are far from the only ones who find priorities unusable. BTAIM, it appears that our choice is to use an option (there is one? what?) to force 4.7 to continue to use ctors, or to use some other option (there is one? what?) to force 4.7 to process init_array in reverse order from what it does by default. Of these two, which do you recommend as a workaround? Are there any other choices?
