[Bug c++/52649] New: internal compiler error: in predict_paths_for_bb, at predict.c:1812
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52649 Bug #: 52649 Summary: internal compiler error: in predict_paths_for_bb, at predict.c:1812 Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: deepu.sarmat...@gmail.com Created attachment 26939 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26939 Preprocessed source containing *.i* and *.s While trying to build my project with 4.6.2 at -O2 /bin/sh ./libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../core_cnl121352/3pp_socketcc_cal1151350/socketcc/src -I../core_cnl121352/core_cal1151070/common/src -I../core_cnl121352/core_cal1151070/transport/src -I../core_cnl121352/core_cal1151070/monitor/src -I../core_cnl121352/core_cal1151070/statistics/src -I../core_cnl121352/core_cal1151070/log/src -I../core_cnl121352/core_cal1151070/factory/src -I../core_cnl121352/core_cal1151070/watchdog/src -I../core_cnl121352/core_cal1151070/accelerator/src -I../core_cnl121352/core_cal1151070/resource_manager/src -I../core_cnl121352/core_cal1151070/config_and_control/src -I../core_cnl121352/3pp_newran_cal1151351/newran/src -I../media_cnl121354/format_handler_cal1151073/profile_handler/src -I../media_cnl121354/format_handler_cal1151073/codec_handler/src -I../rtp_cnl121353/rtp_handler_cal1151071/rtp_statistics/src -I../rtp_cnl121353/rtp_handler_cal1151071/rtp_factory/src -I../rtp_cnl121353/rtp_handler_cal1151071/rtp_packet_filter/src -I../rtp_cnl121353/rtp_handler_cal1151071/rtp_transport/src -I../rtp_cnl121353/rtp_handler_cal1151071/srtp/src -I../rtp_cnl121353/3pp_rtpe_cal1151352/ccrtp/src -I../rtp_cnl121353/3pp_rtpe_cal1151352/ccrtp/src/ccrtp -I../rtp_cnl121353/3pp_rtpe_cal1151352/ccrtp/src/ccrtp/crypto -I../rtp_cnl121353/3pp_rtpe_cal1151352/ccrtp/src/ccrtp/crypto/openssl -I../rtp_cnl121353/3pp_rtpe_cal1151352/ccrtp/src/ccrtp/crypto/gcrypt -I../tcp_cnl121350/ftp_handler_cal1151348/ftp_factory/src -I../tcp_cnl121350/ftp_handler_cal1151348/ftp_transport/src -I../tcp_cnl121350/http_handler_cal1151347/http_factory/src -I../tcp_cnl121350/http_handler_cal1151347/http_transport/src -I../tcp_cnl121350/tcp_handler_cal1151346/tcp_statistics/src -I../tcp_cnl121350/tcp_handler_cal1151346/tcp_transport/src -I../tcp_cnl121350/tcp_handler_cal1151346/tcp_factory/src -I../tcp_cnl121350/telnet_handler_cal1151444/cli/src -I../tcp_cnl121350/telnet_handler_cal1151444/telnet_server/src -I../udp_cnl121351/udp_handler_cal1151349/udp_access_point/src -I../domain_cnl121339/cn_cal1151345/common/src -I../domain_cnl121339/cn_cal1151345/sw_goe/test_tool/src -I../domain_cnl121339/cn_cal1151345/sw_goe/src -I../domain_cnl121339/cn_cal1151345/sw_goe_if/src -I../domain_cnl121339/tft_cal1151415/tft/src -I../core_cnl121352/core_cal1151070/api/include -I../rtmp_cnl121444/src -DMLSIM_ID_STRING="\"MLSim R10A02\"" -DLOCALSTATEDIR="\"/opt/MLSim/var/mlsim\"" -DSYSCONFDIR="\"/opt/MLSim/etc\"" -DBINDIR="\"/opt/MLSim/bin\"" -DPLATFORM_linux -g -O2 -DHAVE_NEXTGEN -D_GNU_SOURCE -I/opt/MLSim/include -MT libmlsim_la-MLSim_sAcceleratorInterface.lo -MD -MP -MF .deps/libmlsim_la-MLSim_sAcceleratorInterface.Tpo -c -o libmlsim_la-MLSim_sAcceleratorInterface.lo `test -f '../core_cnl121352/core_cal1151070/accelerator/src/MLSim_sAcceleratorInterface.cpp' || echo './'`../core_cnl121352/core_cal1151070/accelerator/src/MLSim_sAcceleratorInterface.cpp libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../core_cnl121352/3pp_socketcc_cal1151350/socketcc/src -I../core_cnl121352/core_cal1151070/common/src -I../core_cnl121352/core_cal1151070/transport/src -I../core_cnl121352/core_cal1151070/monitor/src -I../core_cnl121352/core_cal1151070/statistics/src -I../core_cnl121352/core_cal1151070/log/src -I../core_cnl121352/core_cal1151070/factory/src -I../core_cnl121352/core_cal1151070/watchdog/src -I../core_cnl121352/core_cal1151070/accelerator/src -I../core_cnl121352/core_cal1151070/resource_manager/src -I../core_cnl121352/core_cal1151070/config_and_control/src -I../core_cnl121352/3pp_newran_cal1151351/newran/src -I../media_cnl121354/format_handler_cal1151073/profile_handler/src -I../media_cnl121354/format_handler_cal1151073/codec_handler/src -I../rtp_cnl121353/rtp_handler_cal1151071/rtp_statistics/src -I../rtp_cnl121353/rtp_handler_cal1151071/rtp_factory/src -I../rtp_cnl121353/rtp_handler_cal1151071/rtp_packet_filter/src -I../rtp_cnl121353/rtp_handler_cal1151071/rtp_transport/src -I../rtp_cnl121353/rtp_handler_cal1151071/srtp/src -I../rtp_cnl121353/3pp_rtpe_cal1151352/ccrtp/src -I../rtp_cnl121353/3pp_rtpe_cal1151352/ccrtp/src/ccrtp -I../rtp_cnl121353/3pp_rtpe_cal1151352/ccrtp/src/ccrtp/crypto -I../rtp_cnl121353/3pp_rtpe_cal1151352/ccrtp/src/ccrtp/crypto/openssl -I../rtp_cnl121353/3pp_rtpe_cal1151352/ccrtp/src/ccrtp/crypto/gcrypt -I../tcp_cnl121350/ftp_handler_cal1151348/ftp_factory/src -I../tcp_
[Bug middle-end/52649] internal compiler error: in predict_paths_for_bb, at predict.c:1812
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52649 Andrew Pinski changed: What|Removed |Added Component|c++ |middle-end Severity|major |normal
[Bug middle-end/52650] New: [4.8 Regression] FAIL: gcc.dg/torture/pr51106-2.c * (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52650 Bug #: 52650 Summary: [4.8 Regression] FAIL: gcc.dg/torture/pr51106-2.c * (internal compiler error) Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: hjl.to...@gmail.com, rgue...@gcc.gnu.org Between revisions 185561 vs revision 185565 (see http://gcc.gnu.org/ml/gcc-regression/2012-03/msg00223.html ) compiling gcc.dg/torture/pr51106-2.c has started to give an ICE: FAIL: gcc.dg/torture/pr51106-2.c -O0 (internal compiler error) FAIL: gcc.dg/torture/pr51106-2.c -O0 (test for excess errors) FAIL: gcc.dg/torture/pr51106-2.c -O1 (internal compiler error) FAIL: gcc.dg/torture/pr51106-2.c -O1 (test for excess errors) FAIL: gcc.dg/torture/pr51106-2.c -O2 (internal compiler error) FAIL: gcc.dg/torture/pr51106-2.c -O2 (test for excess errors) FAIL: gcc.dg/torture/pr51106-2.c -O3 -fomit-frame-pointer (internal compiler error) FAIL: gcc.dg/torture/pr51106-2.c -O3 -fomit-frame-pointer (test for excess errors) FAIL: gcc.dg/torture/pr51106-2.c -O3 -g (internal compiler error) FAIL: gcc.dg/torture/pr51106-2.c -O3 -g (test for excess errors) FAIL: gcc.dg/torture/pr51106-2.c -Os (internal compiler error) FAIL: gcc.dg/torture/pr51106-2.c -Os (test for excess errors) FAIL: gcc.dg/torture/pr51106-2.c -O2 -flto -flto-partition=none (internal compiler error) FAIL: gcc.dg/torture/pr51106-2.c -O2 -flto -flto-partition=none (test for excess errors) FAIL: gcc.dg/torture/pr51106-2.c -O2 -flto (internal compiler error) FAIL: gcc.dg/torture/pr51106-2.c -O2 -flto (test for excess errors) The ICE is /opt/gcc/work/gcc/testsuite/gcc.dg/torture/pr51106-2.c: In function 'bar': /opt/gcc/work/gcc/testsuite/gcc.dg/torture/pr51106-2.c:8:3: warning: asm operand 0 probably doesn't match constraints [enabled by default] /opt/gcc/work/gcc/testsuite/gcc.dg/torture/pr51106-2.c:8:3: error: impossible constraint in 'asm' /opt/gcc/work/gcc/testsuite/gcc.dg/torture/pr51106-2.c:12:1: internal compiler error: in purge_dead_edges, at cfgrtl.c:2462
[Bug tree-optimization/52636] [4.8 Regression] ICE: tree check: expected integer_cst, have string_cst in tree_to_double_int, at tree.h:4324
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52636 --- Comment #4 from Dominique d'Humieres 2012-03-21 07:48:02 UTC --- Regstrapped with the patch in comment #2 without regression (but for pr52650;-).
[Bug c/52632] GCC compfail on O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52632 Igor Zamyatin changed: What|Removed |Added CC||izamyatin at gmail dot com --- Comment #6 from Igor Zamyatin 2012-03-21 07:52:46 UTC --- So is it ok that compiler behaves differently with and without optimizations?
[Bug tree-optimization/52636] [4.8 Regression] ICE: tree check: expected integer_cst, have string_cst in tree_to_double_int, at tree.h:4324
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52636 --- Comment #5 from Richard Guenther 2012-03-21 08:05:56 UTC --- Author: rguenth Date: Wed Mar 21 08:05:51 2012 New Revision: 185599 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185599 Log: 2012-03-21 Richard Guenther PR tree-optimizer/52636 * tree-vect-slp.c (vect_get_constant_vectors): Convert constants to the appropriate type. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vect-slp.c
[Bug tree-optimization/52636] [4.8 Regression] ICE: tree check: expected integer_cst, have string_cst in tree_to_double_int, at tree.h:4324
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52636 Richard Guenther changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Richard Guenther 2012-03-21 08:07:48 UTC --- Fixed.
[Bug middle-end/52650] [4.8 Regression] FAIL: gcc.dg/torture/pr51106-2.c * (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52650 Richard Guenther changed: What|Removed |Added Keywords||error-recovery, ||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2012-03-21 Target Milestone|--- |4.8.0 Ever Confirmed|0 |1
[Bug c/52632] GCC compfail on O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52632
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #7 from Jakub Jelinek 2012-03-21
08:27:13 UTC ---
Yes. Actually, with __builtin_constant_p, it does so pretty often.
Starting from trivial int foo () { int a; a = 1; return __builtin_constant_p
(a); }
or when __builtin_constant_p is used in an inline function on its arguments or
expressions involving those arguments (then it even depends on whether the
compiler decides to inline or clone the function or not).
BTW, for GCC 4.3+ kernel.h could very well use the __attribute__((error
("message"))).
[Bug fortran/52651] New: Fortran testsuite ICEs with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52651 Bug #: 52651 Summary: Fortran testsuite ICEs with -flto Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: ice-on-valid-code, wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org CC: pa...@gcc.gnu.org Depends on: 45586 Blocks: 51765 For another gfortran LTO failure, see 4.8 pseudo-regression PR fortran/45586 comment 63 (alias PR 52516). That failure is related to TYPE_CANONICAL and "restrict" vs. not "restrict". As pointed out in PR 51765, there are the following failures when running the testsuite with LTO: make check-gfortran RUNTESTFLAGS="--target_board=unix/-flto" Note: To see the ICEs, one has to have a build with checking enabled. (That's the default on the trunk, while release branches [and some GFortranBinaries trunk builds] use --enable-checking=release. There is no ICE with --enable-checking=release, but as the bug might cause alias-analysis issues, it could lead to wrong code on the branches.) FAIL: gfortran.dg/alloc_comp_assign_2.f90 -O0 (internal compiler error) FAIL: gfortran.dg/alloc_comp_assign_3.f90 -O0 (internal compiler error) FAIL: gfortran.dg/alloc_comp_assign_4.f90 -O0 (internal compiler error) FAIL: gfortran.dg/alloc_comp_auto_array_2.f90 -O0 (internal compiler error) FAIL: gfortran.dg/alloc_comp_bounds_1.f90 -O0 (internal compiler error) FAIL: gfortran.dg/alloc_comp_constructor_1.f90 -O0 (internal compiler error) FAIL: gfortran.dg/alloc_comp_constructor_2.f90 -O0 (internal compiler error) FAIL: gfortran.dg/alloc_comp_constructor_3.f90 -O0 (internal compiler error) FAIL: gfortran.dg/alloc_comp_constructor_4.f90 -O0 (internal compiler error) FAIL: gfortran.dg/class_array_7.f03 -O0 (internal compiler error) FAIL: gfortran.dg/class_to_type_1.f03 -O0 (internal compiler error) FAIL: gfortran.dg/extends_4.f03 -O0 (internal compiler error) FAIL: gfortran.dg/pr43808.f90 -O0 (internal compiler error) FAIL: gfortran.dg/type_to_class_1.f03 -O0 (internal compiler error)
[Bug tree-optimization/52638] [4.8 Regression] ice in build_vector_from_val
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52638 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-03-21 Component|c++ |tree-optimization AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.8.0 Summary|ice in |[4.8 Regression] ice in |build_vector_from_val |build_vector_from_val Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther 2012-03-21 08:50:10 UTC --- I have a patch.
[Bug fortran/52606] Confusing diagnostics for long identifiers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52606 --- Comment #7 from Janne Blomqvist 2012-03-21 08:48:38 UTC --- (In reply to comment #6) > (In reply to comment #5) > > What was the motivation for this hashing scheme, BTW? Linkers already > > support > > 1) long symbol names (I read somewhere that OpenOffice has symbols up to > > 4000 > > (!!!) characters long) 2) various symbol hashing schemes (see e.g. > > DT_GNU_HASH). > > I think the idea was to have legible dumps (i.e. avoid hashing everything) but > also to fit them into the various name[GFC_MAX_SYMBOL_LEN] variables which > simply do not take longer names. > > If you think one can/should improve the scheme, feel free to propose something > better. Well, the obvious fix would be to not try cramming mangled identifiers into buffers which are statically sized only to hold unqualified identifiers, no? Essentially, Steven B's proposal in #c1 would fix this as a side-effect. Adding insult to injury, a workaround for this design mistake is enshrined in our ABI.. *sigh*. Grepping for GFC_MAX_SYMBOL_LEN shows 118 occurences, so it would be quite a large patch, but probably quite mechanical for the most part. Steven, are you planning to fix this?
[Bug middle-end/52650] [4.8 Regression] FAIL: gcc.dg/torture/pr51106-2.c * (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52650 Andreas Krebbel changed: What|Removed |Added CC||krebbel at gcc dot gnu.org --- Comment #1 from Andreas Krebbel 2012-03-21 09:05:57 UTC --- I see the same on s390x. The culprit appears to be revision 185564.
[Bug middle-end/52649] internal compiler error: in predict_paths_for_bb, at predict.c:1812
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52649 --- Comment #1 from deepu.sarmatian at gmail dot com 2012-03-21 09:37:00 UTC --- Hi, Please delete the attachment. Though the bug is in the compiler, it seems it violates the security protocol of my concern.
[Bug bootstrap/52623] 4.7.0-RC-20120314: bootstrap failure on AIX due to multilib and using C++ in post-stage1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52623 --- Comment #3 from Michael Haubenwallner 2012-03-21 09:38:00 UTC --- (In reply to comment #2) > We should disable libquadmath on AIX. It is not needed or useful there. > > Have you tried adding --disable-libquadmath when configuring GCC? For --enable-languages=c,c++ only, I can bootstrap using --disable-libquadmath. Haven't tried other languages needing their own target libraries. But the problem isn't with libquadmath itself, but with config-ml.in setting LD_LIBRARY_PATH to find the multilib-wise libstdc++.a, and (interesting enough) the AIX 7.1 loader listening to LD_LIBRARY_PATH now. Consider these simple commands to trigger the configure-error in ppc64/libquadmath: $ ./gcc/xgcc xgcc: fatal error: no input files compilation terminated. $ LD_LIBRARY_PATH=`pwd`/powerpc-ibm-aix7.1.0.0/ppc64/libstdc++-v3/src/.libs ./gcc/xgcc exec(): 0509-036 Cannot load program ./gcc/xgcc because of the following errors: 0509-150 Dependent module /big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/build/powerpc-ibm-aix7.1.0.0/ppc64/libstdc++-v3/src/.libs/libstdc++.a(libstdc++.so.6) could not be loaded. 0509-103 The module has an invalid magic number. Unfortunately, the AIX loader stops searching at the first matching archive filename found, even if it doesn't contain a matching shared object. However, ldd shipped with AIX 7.1 still ignores LD_LIBRARY_PATH: $ ldd ./gcc/xgcc ./gcc/xgcc needs: /usr/lib/libc.a(shr.o) /usr/lib/libiconv.a(shr4.o) /big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/build/prev-powerpc-ibm-aix7.1.0.0/libstdc++-v3/src/.libs/libstdc++.a(libstdc++.so.6) /unix /usr/lib/libcrypt.a(shr.o) /big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/build/./prev-gcc/libgcc_s.a(shr.o) $ LD_LIBRARY_PATH=`pwd`/powerpc-ibm-aix7.1.0.0/ppc64/libstdc++-v3/src/.libs ldd ./gcc/xgcc ./gcc/xgcc needs: /usr/lib/libc.a(shr.o) /usr/lib/libiconv.a(shr4.o) /big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/build/prev-powerpc-ibm-aix7.1.0.0/libstdc++-v3/src/.libs/libstdc++.a(libstdc++.so.6) /unix /usr/lib/libcrypt.a(shr.o) /big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/build/./prev-gcc/libgcc_s.a(shr.o)
[Bug middle-end/52649] internal compiler error: in predict_paths_for_bb, at predict.c:1812
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52649 --- Comment #2 from deepu.sarmatian at gmail dot com 2012-03-21 09:43:45 UTC --- (In reply to comment #1) > Hi, > Please delete the attachment. Though the bug is in the compiler, it seems it > violates the security protocol of my concern. Also please confirm once you are done.
[Bug fortran/52652] New: call to gfc_match_asynchronous for allocatable at parse.c line 164
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52652
Bug #: 52652
Summary: call to gfc_match_asynchronous for allocatable at
parse.c line 164
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bugzillam...@ameshymn.org
parse.c line 164:
Is:
match ("allocatable", gfc_match_asynchronous, ST_ATTR_DECL);
Should be?
match ("allocatable", gfc_match_allocatable, ST_ATTR_DECL);
[Bug c++/40058] C++ FE generates struct assignments with mismatched sizes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40058 --- Comment #3 from Martin Jambor 2012-03-21 10:05:24 UTC --- If this ever gets fixed, we can remove a test in SRA as in: http://gcc.gnu.org/ml/gcc-patches/2012-03/msg01356.html
[Bug c/52653] New: GCC 4.6.* bug on i386 Linux and mingw platforms
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52653
Bug #: 52653
Summary: GCC 4.6.* bug on i386 Linux and mingw platforms
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: borut.ra...@gmail.com
The following code hangs the gcc 4.6.* compiler on i386 Linux and mingw
platforms.
Content of t.c:
8<
#define double2ul(val) (((val) < 0) ? (((val) < -2147483647.0) ? 0x8000UL
: (unsigned long) -((long) -(val))) : (unsigned long) (val))
extern double bar ();
/* This seems to be a GCC 4.6.[012] bug on i386 Linux and mingw platforms
*/
void
foo (void)
{
int x = 10 >> double2ul (bar ());
}
>8
Command:
gcc -c t.c
Compiler hangs on OS version:
$ uname -srvmpo
Linux 2.6.32-5-686 #1 SMP Wed Jan 11 12:29:30 UTC 2012 i686 unknown GNU/Linux
Compiler version:
$ gcc --version
gcc (GCC) 4.6.1
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
It compiles correctly on OS version:
$ uname -srvmpo
Linux 3.0.0-16-generic #29-Ubuntu SMP Tue Feb 14 12:48:51 UTC 2012 x86_64
x86_64 GNU/Linux
Compiler version$ gcc --version
gcc (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Borut
[Bug tree-optimization/52459] PRE performs stupid inserts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52459 Richard Guenther changed: What|Removed |Added CC||matz at gcc dot gnu.org Summary|PPRE performs stupid|PRE performs stupid inserts |inserts | --- Comment #4 from Richard Guenther 2012-03-21 10:41:04 UTC --- I have a patch. The issue is we inhibit PHI insertion for the builtin call at -O3 (when -ftree-vectorize is on), not partial-PRE. The stupid inserts are really caused because of the inhibited PRE insertion will cause only part of the dependent expressions to be available but some uses get eliminated so the still inserted PHI node is not removed ... which means that limiting 'PHI insertion' is bougs - we should really limit what we PHI translate, to not cause dependent expressions to be partially available. Not sure if we know at that point whether we'd need a PHI node, but at least the edges we want to eventually restrict translation are easy to spot - the latch edges.
[Bug c++/52654] New: [C++11] Warn on overflow in user-defined literals
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52654
Bug #: 52654
Summary: [C++11] Warn on overflow in user-defined literals
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: marc.gli...@normalesup.org
Hello,
should there be a warning for this kind of overflow? (-Wall -Wextra is
currently silent)
int operator"" _w(unsigned long long){return 0;}
int main(){
return 12345678901234567890123456789012345678901234567890_w;
}
[Bug testsuite/52641] Test cases fail for 16-bit int targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52641 --- Comment #2 from Georg-Johann Lay 2012-03-21 10:48:13 UTC --- Author: gjl Date: Wed Mar 21 10:48:08 2012 New Revision: 185602 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185602 Log: PR testsuite/52641 * gcc.dg/misaligned-expand-1.c (cst): Cast to int. * gcc.dg/misaligned-expand-2.c (cst): Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/misaligned-expand-1.c trunk/gcc/testsuite/gcc.dg/misaligned-expand-2.c
[Bug c/52653] GCC 4.6.* bug on i386 Linux and mingw platforms
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52653 Mikael Pettersson changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #1 from Mikael Pettersson 2012-03-21 10:50:31 UTC --- I can reproduce the gcc hang on i686-linux with 4.6.3. 4.5.3 and older don't hang.
[Bug c/52655] New: right shit in switch: gcc compiles with error: label at end of compound statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52655
Bug #: 52655
Summary: right shit in switch: gcc compiles with error: label
at end of compound statement
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: borut.ra...@gmail.com
The following code compiles with error: label at end of compound statement with
the gcc 4.6.1 compiler.
Content of t.c:
8<
void
foo (int op)
{
int x = 10 >> 3; /* OK */
switch (op)
{
case 0:
x = 10 >> 3; /* t.c:12:5: error: label at end of compound
statement */
break;
default:
}
}
>8
Command:
gcc -c t.c
Reproduced on OS version:
$ uname -srvmpo
Linux 2.6.32-5-686 #1 SMP Wed Jan 11 12:29:30 UTC 2012 i686 unknown GNU/Linux
and
Linux 3.0.0-16-generic #29-Ubuntu SMP Tue Feb 14 12:48:51 UTC 2012 x86_64
x86_64 GNU/Linux
Compiler version:
$ gcc --version
gcc (GCC) 4.6.1
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
and
$ gcc --version
gcc (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Borut
[Bug c/52655] right shit in switch: gcc compiles with error: label at end of compound statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52655
--- Comment #1 from Mikael Pettersson 2012-03-21
11:29:40 UTC ---
(In reply to comment #0)
> The following code compiles with error: label at end of compound statement
> with
> the gcc 4.6.1 compiler.
>
> Content of t.c:
> 8<
> void
> foo (int op)
> {
> int x = 10 >> 3; /* OK */
>
> switch (op)
> {
> case 0:
> x = 10 >> 3; /* t.c:12:5: error: label at end of compound
> statement */
> break;
>
> default:
The "default:" acts as a label, and it needs a statement after it. Just add
";" after it, or delete it. The shift has nothing to do with this issue.
[Bug tree-optimization/52548] missed PRE optimization when function call follows to-be hoisted variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52548 --- Comment #4 from Richard Guenther 2012-03-21 11:33:25 UTC --- Created attachment 26940 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26940 patch Patch. Not sure what to do about PA_IN - can we even end up with any invalid expressions in it, given we have a "clean" ANTIC_IN already? Well, I guess I have to understand what partial-antic computes ;)
[Bug tree-optimization/52548] missed PRE optimization when function call follows to-be hoisted variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52548 --- Comment #5 from Richard Guenther 2012-03-21 11:40:49 UTC --- Ah, indeed we can. But we should be able to prune from PA_OUT.
[Bug middle-end/52653] GCC 4.6.* bug on i386 Linux and mingw platforms
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52653 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-03-21 Component|c |middle-end Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther 2012-03-21 11:50:52 UTC --- We iterate endlessly between lshift_double and rshift_double if -count == count.
[Bug c/52655] right shit in switch: gcc compiles with error: label at end of compound statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52655 Richard Guenther changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2012-03-21 Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther 2012-03-21 11:53:26 UTC --- Confirmed as weak diagnostic.
[Bug c++/24985] caret diagnostics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985 Manuel López-Ibáñez changed: What|Removed |Added CC||borut.razem at gmail dot ||com --- Comment #15 from Manuel López-Ibáñez 2012-03-21 12:05:08 UTC --- *** Bug 52655 has been marked as a duplicate of this bug. ***
[Bug c/52655] confusing "error: label at end of compound statement" for default without statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52655 Manuel López-Ibáñez changed: What|Removed |Added Status|NEW |RESOLVED CC||manu at gcc dot gnu.org Resolution||DUPLICATE Summary|right shit in switch: gcc |confusing "error: label at |compiles with error: label |end of compound statement" |at end of compound |for default without |statement |statement --- Comment #3 from Manuel López-Ibáñez 2012-03-21 12:05:07 UTC --- The location is correct (line 12, where the default is), but GCC doesn't have caret info, so the user probably got confused. Clang gives: /tmp/webcompile/_24877_0.c:12:13: error: label at end of compound statement: expected statement default: ^ 1 error generated. which is the same message and the same location but the caret clarifies everything. I really don't see how the diagnostics could be improved short of implementing caret diagnostics, which is already opened in another PR24985. *** This bug has been marked as a duplicate of bug 24985 ***
[Bug fortran/52621] ICE when compiling Fortran77 code with optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52621 --- Comment #3 from Jan Lachnitt 2012-03-21 12:18:59 UTC --- Thanks for testing and for the link to GFortranBinaries. I have just installed the very recent unofficial build of gfortran: Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=c:/program files/gfortran/bin/../libexec/gcc/i586-pc-mingw32 /4.8.0/lto-wrapper.exe Target: i586-pc-mingw32 Configured with: ../gcc-trunk/configure --prefix=/mingw --enable-languages=c,for tran --with-gmp=/home/brad/gfortran/dependencies --disable-werror --enable-threa ds --disable-nls --build=i586-pc-mingw32 --enable-libgomp --enable-shared --disa ble-win32-registry --with-dwarf2 --disable-sjlj-exceptions --enable-lto Thread model: win32 gcc version 4.8.0 20120319 (experimental) [trunk revision 185521] (GCC) The result is that the ICE is still there. There are just two changes. First, there are some more warnings, and second, the ICE is reported with a different line number within GCC source: tree-data-ref.c:1964.
[Bug c/52655] confusing "error: label at end of compound statement" for default without statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52655 --- Comment #4 from Borut Ražem 2012-03-21 12:44:34 UTC --- What a shame :-( Sorry for the false alarm. Borut
[Bug middle-end/52653] GCC 4.6.* bug on i386 Linux and mingw platforms
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52653 --- Comment #3 from Mikael Pettersson 2012-03-21 12:55:55 UTC --- It's caused by r158372, but silent with 4.7.0 on i686. Duplicate of PR50708.
[Bug testsuite/52614] [4.8 Regression] Test failures in gcc.dg/vect: vectorizing unaligned access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52614 --- Comment #7 from Dominique d'Humieres 2012-03-21 12:57:54 UTC --- I have posted the results for powerpc-apple-darwin9 with the patch in comment #0 at http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02399.html . It shows some remaining failures FAIL: gcc.dg/vect/costmodel/ppc/costmodel-vect-outer-fir.c scan-tree-dump-times vect "OUTER LOOP VECTORIZED" 2 FAIL: gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a.c scan-tree-dump-times slp "basic block vectorized using SLP" 1 They are fixed with the following patch --- /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/costmodel/ppc/ppc-costmodel-vect.exp 2011-01-05 08:39:45.0 +0100 +++ /opt/gcc/work/gcc/testsuite/gcc.dg/vect/costmodel/ppc/ppc-costmodel-vect.exp 2012-03-21 10:55:27.0 +0100 @@ -34,7 +34,7 @@ if ![is-effective-target powerpc_altivec set DEFAULT_VECTCFLAGS "" # These flags are used for all targets. -lappend DEFAULT_VECTCFLAGS "-O2" "-ftree-vectorize" "-fvect-cost-model" +lappend DEFAULT_VECTCFLAGS "-O2" "-ftree-vectorize" "-fvect-cost-model" "-fno-common" # If the target system supports vector instructions, the default action # for a test is 'run', otherwise it's 'compile'. Save current default. Note that I don't have write access to SVN, so someone will have to commit the patches when approved. Now I wonder if '-fno-common' should not be the default when '-ftree-vectorize' is used on the affected targets?
[Bug c/52640] performance bottleneck: gcc/tree.c;value_member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52640 --- Comment #4 from Steven Bosscher 2012-03-21 13:01:07 UTC --- Created attachment 26941 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26941 Needs an ASM_OUTPUT_EXTERNAL platform for testing
[Bug c/52640] performance bottleneck: gcc/tree.c;value_member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52640 Steven Bosscher changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #3 from Steven Bosscher 2012-03-21 13:00:33 UTC --- Can you please add the output of "gcc --version" and add "-v" to your compiler invocation and report the output?
[Bug middle-end/52650] [4.8 Regression] FAIL: gcc.dg/torture/pr51106-2.c * (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52650 Rainer Orth changed: What|Removed |Added CC||ro at gcc dot gnu.org --- Comment #2 from Rainer Orth 2012-03-21 13:00:23 UTC --- Same on sparc, where a couple of new executions failures appeared between 20120316 (r185470) and 20120320 (r185573), both 32 and 64-bit: FAIL: gcc.dg/torture/20090618-1.c -O1 execution test FAIL: gcc.dg/torture/pr39074-3.c -O1 execution test FAIL: gcc.dg/torture/pr39074-3.c -O2 execution test FAIL: gcc.dg/torture/pr39074-3.c -O3 -fomit-frame-pointer execution test FAIL: gcc.dg/torture/pr39074-3.c -O3 -g execution test FAIL: gcc.dg/torture/pr39074-3.c -Os execution test FAIL: gcc.dg/torture/pr39074-3.c -O2 -flto -flto-partition=none execution test FAIL: gcc.dg/torture/pr39074-3.c -O2 -flto execution test FAIL: gcc.dg/torture/pr45967-3.c -O2 execution test FAIL: gcc.dg/torture/pr45967-3.c -O3 -fomit-frame-pointer execution test FAIL: gcc.dg/torture/pr45967-3.c -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gcc.dg/torture/pr45967-3.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gcc.dg/torture/pr45967-3.c -O3 -g execution test FAIL: gcc.dg/torture/pr45967-3.c -O2 -flto -flto-partition=none execution test FAIL: gcc.dg/torture/pr45967-3.c -O2 -flto execution test FAIL: gcc.dg/torture/pta-ptrarith-2.c -O1 execution test I don't yet know if they are related. Rainer
[Bug c/52640] performance bottleneck: gcc/tree.c;value_member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52640 --- Comment #5 from Steven Bosscher 2012-03-21 13:03:57 UTC --- Ah, and obviously there should be a pointer_set_insert before VEC_safe_push...
[Bug libgcj/52645] gnu/java/net/natPlainDatagramSocketImpl.cc:660:14: error: 'IPPROTO_IPV6' was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52645 --- Comment #1 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-03-21 13:09:44 UTC --- This is from my Tru64 UNIX removal patch. Could you please check if IPPROTO_IPV6 and/or IPV6_MULTICAST_IF are defined in any system header or if this another case of partial IPv6 support? Thanks. Rainer
[Bug fortran/52621] ICE when compiling Fortran77 code with optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52621 --- Comment #4 from Dominique d'Humieres 2012-03-21 13:12:51 UTC --- On x86_64-apple-darwin10, the code compiles with the options in comment #0 (with a lot of warnings) for 4.4.6, 4.5.3, 4.6.3, 4.7.0RC2, and trunk (with -m32 or -m64). So the problem looks mingw32 specific.
[Bug c++/25362] pretty printing of expression fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25362 Manuel López-Ibáñez changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #5 from Manuel López-Ibáñez 2012-03-21 13:21:53 UTC --- Duplicated. The other bug has a better discussion. *** This bug has been marked as a duplicate of bug 49152 ***
[Bug target/52461] [avr] XMEGA+EBI: RAMPZ clobbered while reading from flash
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52461 --- Comment #9 from Georg-Johann Lay 2012-03-21 13:20:25 UTC --- Author: gjl Date: Wed Mar 21 13:20:20 2012 New Revision: 185605 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185605 Log: PR rtl-optimization/52543 PR target/52461 * config/avr/avr-protos.h (avr_load_lpm): New prototype. * config/avr/avr.c (avr_mode_dependent_address_p): New function. (TARGET_MODE_DEPENDENT_ADDRESS_P): New define. (avr_load_libgcc_p): Restrict to __flash loads. (avr_out_lpm): Only handle 1-byte loads from __flash. (avr_load_lpm): New function. (avr_find_unused_d_reg): Remove. (avr_out_lpm_no_lpmx): Remove. (adjust_insn_length): Handle ADJUST_LEN_LOAD_LPM. * config/avr/avr.md (unspec): Add UNSPEC_LPM. (load__libgcc): Use UNSPEC_LPM instead of MEM. (load_, load__clobber): New insns. (mov): For multi-byte move from non-generic 16-bit address spaces: Expand to load_ resp. load__clobber. (load_libgcc): Remove expander. (split-lpmx): Remove split. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr-protos.h trunk/gcc/config/avr/avr.c trunk/gcc/config/avr/avr.md
[Bug fortran/52652] call to gfc_match_asynchronous for allocatable at parse.c line 164
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52652
Tobias Burnus changed:
What|Removed |Added
Keywords||rejects-valid
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-03-21
CC||burnus at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #1 from Tobias Burnus 2012-03-21
13:21:35 UTC ---
Confirmed - and well spotted. Thanks for the bug report!
* * *
The code has been added for PR 25829 comment 16 (Rev. 155732), however, it
wasn't working before either - thus, it is not a regression. (I had an example
to test the parsing in the patch submittal - but as I didn't use "allocate()"
it "successfully" compiled.)
* * *
Test case: It's valid, but rejected with
Error: Allocate-object at (1) is not a nonprocedure pointer
or an allocatable variable
module m
type t
end type t
end module m
type(t) function bar()
use m
allocatable :: bar
allocate (bar)
end
Untested patch:
--- a/gcc/fortran/match.c
+++ b/gcc/fortran/match.c
@@ -3574,4 +3574,4 @@ gfc_match_allocate (void)
{
- gfc_error ("Allocate-object at %L is not a nonprocedure pointer "
-"or an allocatable variable", &tail->expr->where);
+ gfc_error ("Allocate-object at %L is neither a nonprocedure pointer "
+"nor an allocatable variable", &tail->expr->where);
goto cleanup;
--- a/gcc/fortran/parse.c
+++ b/gcc/fortran/parse.c
@@ -163,3 +163,3 @@ decode_specification_statement (void)
ST_INTERFACE);
- match ("allocatable", gfc_match_asynchronous, ST_ATTR_DECL);
+ match ("allocatable", gfc_match_allocatable, ST_ATTR_DECL);
match ("asynchronous", gfc_match_asynchronous, ST_ATTR_DECL);
--- a/gcc/testsuite/gfortran.dg/allocate_alloc_opt_1.f90
+++ b/gcc/testsuite/gfortran.dg/allocate_alloc_opt_1.f90
@@ -27 +27 @@ program a
- allocate(err) ! { dg-error "nonprocedure pointer or an allocatable" }
+ allocate(err) ! { dg-error "neither a nonprocedure pointer nor an
allocatable" }
--- a/gcc/testsuite/gfortran.dg/allocate_class_1.f90
+++ b/gcc/testsuite/gfortran.dg/allocate_class_1.f90
@@ -10 +10 @@
- allocate(x) ! { dg-error "is not a nonprocedure pointer or an allocatable
variable" }
+ allocate(x) ! { dg-error "is neither a nonprocedure pointer nor an
allocatable variable" }
--- a/gcc/testsuite/gfortran.dg/allocate_with_typespec_4.f90
+++ b/gcc/testsuite/gfortran.dg/allocate_with_typespec_4.f90
@@ -24 +24 @@ subroutine not_an_f03_intrinsic
- allocate(double complex :: d1) ! { dg-error "not a nonprocedure pointer or
an allocatable" }
+ allocate(double complex :: d1) ! { dg-error "neither a nonprocedure pointer
nor an allocatable" }
--- a/gcc/testsuite/gfortran.dg/deallocate_alloc_opt_1.f90
+++ b/gcc/testsuite/gfortran.dg/deallocate_alloc_opt_1.f90
@@ -27 +27 @@ program a
- deallocate(err) ! { dg-error "nonprocedure pointer or an allocatable" }
+ deallocate(err) ! { dg-error "nonprocedure pointer nor an allocatable" }
[Bug c++/49152] Unhelpful diagnostic for iterator dereference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152 Manuel López-Ibáñez changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-03-21 Ever Confirmed|0 |1 --- Comment #9 from Manuel López-Ibáñez 2012-03-21 13:21:12 UTC --- I think this is confirmed. I agree with the suggestion in comment #6.
[Bug rtl-optimization/52543] lower-subreg.c: code bloat of 300%-400% for multi-word memory splits
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52543 --- Comment #4 from Georg-Johann Lay 2012-03-21 13:20:25 UTC --- Author: gjl Date: Wed Mar 21 13:20:20 2012 New Revision: 185605 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185605 Log: PR rtl-optimization/52543 PR target/52461 * config/avr/avr-protos.h (avr_load_lpm): New prototype. * config/avr/avr.c (avr_mode_dependent_address_p): New function. (TARGET_MODE_DEPENDENT_ADDRESS_P): New define. (avr_load_libgcc_p): Restrict to __flash loads. (avr_out_lpm): Only handle 1-byte loads from __flash. (avr_load_lpm): New function. (avr_find_unused_d_reg): Remove. (avr_out_lpm_no_lpmx): Remove. (adjust_insn_length): Handle ADJUST_LEN_LOAD_LPM. * config/avr/avr.md (unspec): Add UNSPEC_LPM. (load__libgcc): Use UNSPEC_LPM instead of MEM. (load_, load__clobber): New insns. (mov): For multi-byte move from non-generic 16-bit address spaces: Expand to load_ resp. load__clobber. (load_libgcc): Remove expander. (split-lpmx): Remove split. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr-protos.h trunk/gcc/config/avr/avr.c trunk/gcc/config/avr/avr.md
[Bug c++/49152] Unhelpful diagnostic for iterator dereference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152 Manuel López-Ibáñez changed: What|Removed |Added CC||suckfish at ihug dot co.nz --- Comment #10 from Manuel López-Ibáñez 2012-03-21 13:21:53 UTC --- *** Bug 25362 has been marked as a duplicate of this bug. ***
[Bug middle-end/52621] ICE with -O3 -march=opteron in initialize_matrix_A, at tree-data-ref.c:1964
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52621 Tobias Burnus changed: What|Removed |Added Keywords||ice-on-valid-code Component|fortran |middle-end Summary|ICE when compiling |ICE with -O3 -march=opteron |Fortran77 code with |in initialize_matrix_A, at |optimization|tree-data-ref.c:1964 Known to fail||4.6.1, 4.8.0 --- Comment #5 from Tobias Burnus 2012-03-21 13:29:44 UTC --- I can reproduce it on x86-64-gnu-linux with: gfortran -march=opteron -O3 -w -c file.f The crucial flag is the "opteron" - it works with "core2".
[Bug middle-end/52650] [4.8 Regression] FAIL: gcc.dg/torture/pr51106-2.c * (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52650 --- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-03-21 13:32:31 UTC --- > I don't yet know if they are related. Now I do: I've just built a 32-bit C-only compiler on sparc-sun-solaris2.11 at r185563 (i.e. immediately before the culprit patch), and both the ICE in gcc.dg/torture/pr51106-2.c and the other execution failures reported are gone. Rainer
[Bug middle-end/52650] [4.8 Regression] FAIL: gcc.dg/torture/pr51106-2.c * (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52650 --- Comment #4 from rguenther at suse dot de 2012-03-21 13:38:28 UTC --- On Wed, 21 Mar 2012, ro at CeBiTec dot Uni-Bielefeld.DE wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52650 > > --- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> 2012-03-21 13:32:31 UTC --- > > I don't yet know if they are related. > > Now I do: I've just built a 32-bit C-only compiler on > sparc-sun-solaris2.11 at r185563 (i.e. immediately before the culprit > patch), and both the ICE in gcc.dg/torture/pr51106-2.c and the other > execution failures reported are gone. If they are related (which I doubt), removing the call to cleanup_cfg in cfgexpand.c should fix them. That's the only real change in this patch - previously the cleanup_cfg call was conditional on a present EH region tree (thus, all of these issues are latent and just require a slightly different testcase)
[Bug middle-end/52621] [4.6/4.7/4.8 Regression] ICE with -O3 -march=opteron in initialize_matrix_A, at tree-data-ref.c:1964
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52621 Dominique d'Humieres changed: What|Removed |Added Known to work||4.4.6, 4.5.3 Summary|ICE with -O3 -march=opteron |[4.6/4.7/4.8 Regression] |in initialize_matrix_A, at |ICE with -O3 -march=opteron |tree-data-ref.c:1964|in initialize_matrix_A, at ||tree-data-ref.c:1964 --- Comment #6 from Dominique d'Humieres 2012-03-21 13:50:34 UTC --- > I can reproduce it on x86-64-gnu-linux with: > gfortran -march=opteron -O3 -w -c file.f > > The crucial flag is the "opteron" - it works with "core2". Confirmed. AFAICT the code compiles with 4.4.6 and 4.5.3 (so marked as a regression) and on trunk when compiled with '-march=opteron -O2 -ftree-vectorize'.
[Bug middle-end/52650] [4.8 Regression] FAIL: gcc.dg/torture/pr51106-2.c * (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52650 --- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-03-21 13:51:46 UTC --- > --- Comment #4 from rguenther at suse dot de > 2012-03-21 13:38:28 UTC --- [...] > If they are related (which I doubt), removing the call to cleanup_cfg > in cfgexpand.c should fix them. That's the only real change in > this patch - previously the cleanup_cfg call was conditional on a > present EH region tree (thus, all of these issues are latent and > just require a slightly different testcase) Indeed: with your patch applied and the call #if 0'd, the tests still pass. Rainer
[Bug middle-end/52650] [4.8 Regression] FAIL: gcc.dg/torture/pr51106-2.c * (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52650 --- Comment #6 from rguenther at suse dot de 2012-03-21 13:57:34 UTC --- On Wed, 21 Mar 2012, ro at CeBiTec dot Uni-Bielefeld.DE wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52650 > > --- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> 2012-03-21 13:51:46 UTC --- > > --- Comment #4 from rguenther at suse dot de > > 2012-03-21 13:38:28 UTC --- > [...] > > If they are related (which I doubt), removing the call to cleanup_cfg > > in cfgexpand.c should fix them. That's the only real change in > > this patch - previously the cleanup_cfg call was conditional on a > > present EH region tree (thus, all of these issues are latent and > > just require a slightly different testcase) > > Indeed: with your patch applied and the call #if 0'd, the tests still pass. and with #if 1 they fail? As they are wrong-code regressions on an architecture I have no access to, can you see what is the issue here? Thanks. Richard.
[Bug middle-end/52621] [4.6/4.7/4.8 Regression] ICE with -O3 -march=opteron in initialize_matrix_A, at tree-data-ref.c:1964
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52621 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-03-21 Ever Confirmed|0 |1 --- Comment #7 from Dominique d'Humieres 2012-03-21 13:59:09 UTC --- r162456 is OK r163718 gives the ICE. The usual '-fno-whole-file -fno-realloc-lhs' trick does not fix the problem.
[Bug bootstrap/47923] Errors when installing GCC 4.5.2 on AIX 6.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47923 Michael Haubenwallner changed: What|Removed |Added CC||michael.haubenwallner at ||salomon dot at --- Comment #9 from Michael Haubenwallner 2012-03-21 14:20:42 UTC --- Do you have most recent TechLevel and/or ServicePack installed? AIX 6.1 is known to break with any ServicePack since 2011 calendarweek 12 (1112) and before 2011 calendarweek 40 (1140).
[Bug middle-end/52621] [4.6/4.7/4.8 Regression] ICE with -O3 -march=opteron in initialize_matrix_A, at tree-data-ref.c:1964
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52621 --- Comment #8 from Dominique d'Humieres 2012-03-21 14:22:49 UTC --- Reduced test SUBROUTINE GHDSYM(IZ,IS,LMMAX,S,LMS,Y,L2M,DRL,NLAY2,K0,DCUT)!, ! COMPLEX Y(L2M,L2M),H(33),S(LMS) COMPLEX RU,CI,CZ,K0,FF,Z,Z1,Z2,Z3,ST ! DO 140 KK=1,4 DO 130 L=1,L2M L1=L*L-L DO 120 M=1,L IPM=L1+M IMM=L1-M+2 S(IPM)=S(IPM)+Z3*Y(L,M) IF (M.NE.1) S(IMM)=S(IMM)+Z3*Y(M-1,L)*CSGN 120CONTINUE 130 CONTINUE 140 CONTINUE END
[Bug bootstrap/52623] 4.7.0-RC-20120314: bootstrap failure on AIX due to multilib and using C++ in post-stage1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52623 --- Comment #4 from Michael Haubenwallner 2012-03-21 14:27:06 UTC --- (In reply to comment #3) > But the problem isn't with libquadmath itself, but with config-ml.in setting > LD_LIBRARY_PATH to find the multilib-wise libstdc++.a, and (interesting > enough) > the AIX 7.1 loader listening to LD_LIBRARY_PATH now. This is bug#46981 actually.
[Bug libgcj/52645] gnu/java/net/natPlainDatagramSocketImpl.cc:660:14: error: 'IPPROTO_IPV6' was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52645 --- Comment #2 from dave.anglin at bell dot net 2012-03-21 14:43:57 UTC --- On 3/21/2012 9:09 AM, ro at CeBiTec dot Uni-Bielefeld.DE wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52645 > > --- Comment #1 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> 2012-03-21 13:09:44 UTC --- > This is from my Tru64 UNIX removal patch. Could you please check if > IPPROTO_IPV6 and/or IPV6_MULTICAST_IF are defined in any system header > or if this another case of partial IPv6 support? IPPROTO_IPV6 and IPV6_MULTICAST_IF are not defined in any system header on HP-UX 11.00. As far as I can tell, there is no IPv6 support. On HP-UX 11.11, the defines are in netinet/in6.h. Dave
[Bug libgcj/52645] gnu/java/net/natPlainDatagramSocketImpl.cc:660:14: error: 'IPPROTO_IPV6' was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52645 --- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-03-21 15:04:51 UTC --- > IPPROTO_IPV6 and IPV6_MULTICAST_IF are not defined in any system header > on HP-UX 11.00. As far as I can tell, there is no IPv6 support. Ok, but at least struct sockaddr_in6 is present in/from , otherwise the HAVE_INET6 configure test would fail? > On HP-UX 11.11, the defines are in netinet/in6.h. Ok, thanks. Rainer
[Bug middle-end/52656] New: [4.8 regression] gcc.target/sparc/fpmul-2.c FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52656
Bug #: 52656
Summary: [4.8 regression] gcc.target/sparc/fpmul-2.c FAILs
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
CC: ebotca...@gcc.gnu.org, rgue...@gcc.gnu.org
Host: sparc-sun-solaris2*
Target: sparc-sun-solaris2*
Build: sparc-sun-solaris2*
As initially mentioned in PR testsuite/52614, gcc.target/sparc/fpmul-2.c has
recently started to fail:
FAIL: gcc.target/sparc/fpmul-2.c scan-tree-dump optimized "{ 2, 4, 6, 8 }"
It turned out that the failure is unrelated to the other ones, and a reghunt
revealed the culprit patch:
2012-03-16 Richard Guenther
* tree.h (TREE_VECTOR_CST_ELTS): Remove.
(VECTOR_CST_NELTS, VECTOR_CST_ELTS, VECTOR_CST_ELT): New defines.
(struct tree_vector): Remove elements member, add variable size
elts array member.
(build_vector_stat): Declare.
(build_vector): Define in terms of build_vector_stat.
[...]
* config/sparc/sparc.c (sparc_handle_vis_mul8x16): Adjust interface
and implementation.
(sparc_fold_builtin): Adjust.
Here's the change in the optimized dumps:
> diff -u 23[45]/gcc/fpmul-2.c*|more
--- 234/gcc/fpmul-2.c.149t.optimized2012-03-21 14:58:58.358234100 +0100
+++ 235/gcc/fpmul-2.c.149t.optimized2012-03-21 16:18:28.973592400 +0100
@@ -48,7 +48,7 @@
foo3 ()
{
:
- return { 2, 4, 6, 8 };
+ return { 1, 2, 3, 4 };
}
Rainer
[Bug middle-end/52656] [4.8 regression] gcc.target/sparc/fpmul-2.c FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52656 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-03-21 CC|ebotcazou at gcc dot| |gnu.org | AssignedTo|unassigned at gcc dot |ebotcazou at gcc dot |gnu.org |gnu.org Ever Confirmed|0 |1 --- Comment #1 from Eric Botcazou 2012-03-21 15:49:46 UTC --- Glad to see the code is properly covered by the testsuite. Fixing...
[Bug middle-end/52650] [4.8 Regression] FAIL: gcc.dg/torture/pr51106-2.c * (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52650
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-03-21 15:51:23 UTC ---
> and with #if 1 they fail? As they are wrong-code regressions on
> an architecture I have no access to, can you see what is the issue here?
Right. I've compared assembler output for
FAIL: gcc.dg/torture/20090618-1.c -O1 execution test
which aborts with the #if 1 code:
> diff -u 285{,.orig}/gcc/testsuite/gcc/20090618-1.s
--- 285/gcc/testsuite/gcc/20090618-1.s 2012-03-21 16:38:25.780827400 +0100
+++ 285.orig/gcc/testsuite/gcc/20090618-1.s 2012-03-21 16:38:13.525278500
+0100
@@ -6,10 +6,7 @@
.proc 04
foo:
add %sp, -96, %sp
- st %g0, [%sp+92]
- mov 1, %g1
- st %g1, [%sp+88]
- mov 1, %o0
+ ld [%sp+88], %o0
jmp %o7+8
sub%sp, -96, %sp
.size foo, .-foo
As you can see, the i = 0, j = 1 initializations are lost completely,
and the ld insn reads from an uninitialized stack slot.
Rainer
[Bug c/52640] performance bottleneck: gcc/tree.c;value_member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52640 --- Comment #6 from Jan Smets 2012-03-21 15:51:22 UTC --- Comment on attachment 26941 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26941 Needs an ASM_OUTPUT_EXTERNAL platform for testing Where does deferred_global_decls come from? Can this be modified to apply to 4.6.3 ? Target is i686-wrs-vxworks / mips-wrs-vxworks
[Bug fortran/52622] ICE in gfortran 4.6.3, x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52622 --- Comment #3 from Dominique d'Humieres 2012-03-21 15:56:46 UTC --- On x86_64-apple-darwin10, compiling the test with 4.6.3, 4.7.0RC2, or trunk gives the follwoing errors pr52622.f90:130.2: function passeverywherefcomplex_impl(self, c1, c2, c3, exception) result( & 1 Error: Unclassifiable statement at (1) pr52622.f90:103.8: if (b1) then 1 Error: IF clause at (1) requires a scalar LOGICAL expression pr52622.f90:99.8: if (b) then 1 Error: IF clause at (1) requires a scalar LOGICAL expression but no ICE (w/wo -w). Fixing the errors with --- pr52622.f902012-03-19 17:58:14.0 +0100 +++ pr52622_db.f902012-03-19 18:07:37.0 +0100 @@ -96,10 +96,12 @@ module Args_Basic_Impl end type Args_Basic_impl_t contains function passinbool_impl(self, b, exception) result(retval) +logical :: b if (b) then endif end function passinbool_impl function passeverywherebool_impl(self, b1, b2, b3, exception) result(retval) +logical :: b1 if (b1) then endif end function passeverywherebool_impl @@ -128,7 +130,10 @@ contains retval) end function passeverywheredouble_impl function passeverywherefcomplex_impl(self, c1, c2, c3, exception) result( & +retval) complex (kind=sidl_fcomplex), intent(in) :: c1 + end function passeverywherefcomplex_impl function passindcomplex_impl(self, c, exception) result(retval) end function passindcomplex_impl end module Args_Basic_Impl +end the code is compiled without error.
[Bug middle-end/52650] [4.8 Regression] FAIL: gcc.dg/torture/pr51106-2.c * (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52650 Hans-Peter Nilsson changed: What|Removed |Added CC||hp at gcc dot gnu.org --- Comment #8 from Hans-Peter Nilsson 2012-03-21 15:58:25 UTC --- Yeah, cris-elf too, 185561:185571 exactly the same.
[Bug target/52624] Missing __builtin_bswap16
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52624 Eric Botcazou changed: What|Removed |Added Status|RESOLVED|NEW Last reconfirmed||2012-03-21 CC||ebotcazou at gcc dot ||gnu.org Resolution|INVALID | Ever Confirmed|0 |1 Severity|normal |enhancement --- Comment #2 from Eric Botcazou 2012-03-21 16:09:40 UTC --- This is IMO a valid request given that PowerPC has it (and x86 has rolw/xchg).
[Bug c/52640] performance bottleneck: gcc/tree.c;value_member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52640 Steven Bosscher changed: What|Removed |Added Attachment #26941|0 |1 is obsolete|| --- Comment #7 from Steven Bosscher 2012-03-21 16:17:24 UTC --- Created attachment 26942 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26942 Fixed patch Previous patch was obviously not yet tested, this one at least compiles.
[Bug rtl-optimization/52629] global buffer overflow in gcc/reload1.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52629 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-03-21 CC||ebotcazou at gcc dot ||gnu.org AssignedTo|unassigned at gcc dot |ebotcazou at gcc dot |gnu.org |gnu.org Ever Confirmed|0 |1 --- Comment #1 from Eric Botcazou 2012-03-21 16:21:21 UTC --- Ugh. count_pseudo has the correct implementation.
[Bug libgcj/52645] gnu/java/net/natPlainDatagramSocketImpl.cc:660:14: error: 'IPPROTO_IPV6' was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52645 --- Comment #4 from dave.anglin at bell dot net 2012-03-21 16:22:38 UTC --- On 3/21/2012 11:04 AM, ro at CeBiTec dot Uni-Bielefeld.DE wrote: > Ok, but at least struct sockaddr_in6 is present in/from, > otherwise the HAVE_INET6 configure test would fail? Not that I see. Dave
[Bug target/52630] [4.7 regression] ICE when compiling ppl-0.12 testsuite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52630 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-03-21 CC||ebotcazou at gcc dot ||gnu.org AssignedTo|unassigned at gcc dot |ebotcazou at gcc dot |gnu.org |gnu.org Ever Confirmed|0 |1
[Bug libgcj/52645] gnu/java/net/natPlainDatagramSocketImpl.cc:660:14: error: 'IPPROTO_IPV6' was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52645 --- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-03-21 16:31:41 UTC --- > --- Comment #4 from dave.anglin at bell dot net 2012-03-21 16:22:38 UTC --- > On 3/21/2012 11:04 AM, ro at CeBiTec dot Uni-Bielefeld.DE wrote: >> Ok, but at least struct sockaddr_in6 is present in/from, >> otherwise the HAVE_INET6 configure test would fail? > > Not that I see. I see now what's wrong: I'm an idiot and removed the HAVE_INET6 check together with defined (IPV6_MULTICAST_IF). The former is clearly necessary, the latter probably not. Will fix. Rainer
[Bug other/52626] make check fixinclude test FAILURES
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52626 Rainer Orth changed: What|Removed |Added Target|x86_64-unknown-linux-gnu| Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-03-21 AssignedTo|unassigned at gcc dot |ro at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.8.0 Ever Confirmed|0 |1 --- Comment #1 from Rainer Orth 2012-03-21 16:33:00 UTC --- My fault, patch submitted. Sorry. Rainer
[Bug libgcj/52645] gnu/java/net/natPlainDatagramSocketImpl.cc:660:14: error: 'IPPROTO_IPV6' was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52645 Rainer Orth changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-03-21 AssignedTo|unassigned at gcc dot |ro at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.8.0 Ever Confirmed|0 |1 --- Comment #6 from Rainer Orth 2012-03-21 16:45:25 UTC --- Mine, could you please try the attached (untested except by visual inspection) patch? Rainer
[Bug libgcj/52645] gnu/java/net/natPlainDatagramSocketImpl.cc:660:14: error: 'IPPROTO_IPV6' was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52645 --- Comment #7 from Rainer Orth 2012-03-21 16:46:21 UTC --- Created attachment 26943 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26943 proposed patch
[Bug rtl-optimization/52657] New: [4.7/4.8 regression] error on asm during GMP build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52657
Bug #: 52657
Summary: [4.7/4.8 regression] error on asm during GMP build
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ebotca...@gcc.gnu.org
Target: ia64-*-linux
Created attachment 26944
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26944
Reduced testcase
GMP cannot be compiled anymore on IA-64/Linux, the error being:
gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I..
-DOPERATION_redc_2 -O2 -pedantic -c
redc_2.c -o redc_2.o
redc_2.c: In function '__gmpn_redc_2':
redc_2.c:87:7: error: 'asm' operand requires impossible reload
redc_2.c:87:7: error: 'asm' operand requires impossible reload
redc_2.c:87:7: error: 'asm' operand requires impossible reload
redc_2.c:87:7: error: 'asm' operand requires impossible reload
make[2]: *** [redc_2.lo] Error 1
The error is issued by this very old piece of code in reload_as_needed:
/* If this was an ASM, make sure that all the reload insns
we have generated are valid. If not, give an error
and delete them. */
if (asm_noperands (PATTERN (insn)) >= 0)
for (p = NEXT_INSN (prev); p != next; p = NEXT_INSN (p))
if (p != insn && INSN_P (p)
&& GET_CODE (PATTERN (p)) != USE
&& (recog_memoized (p) < 0
|| (extract_insn (p), ! constrain_operands (1
{
error_for_asm (insn,
"% operand requires "
"impossible reload");
delete_insn (p);
}
Now it seems to overlook the case where the reload insns contain pseudos that
didn't get hard regs and thus have equivalent memory references. They will be
replaced by these memory references only _after_ reload_as_needed has run.
Commenting out the piece code generates correct assembly AFAICS and the GMP
testsuite is clean. But it seems quite astonishing that this issue has never
surfaced until now (the code was added by Richard Kenner almost 20 years ago).
[Bug rtl-optimization/52657] [4.7/4.8 regression] error on asm during GMP build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52657 --- Comment #1 from Uros Bizjak 2012-03-21 17:00:22 UTC --- Dup of 48496.
[Bug rtl-optimization/52657] [4.7/4.8 regression] error on asm during GMP build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52657 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #2 from Eric Botcazou 2012-03-21 17:08:55 UTC --- Indeed, too bad the bug wasn't fixed. *** This bug has been marked as a duplicate of bug 48496 ***
[Bug rtl-optimization/48496] [4.7/4.8 Regression] 'asm' operand requires impossible reload in libffi/src/ia64/ffi.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48496 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot ||gnu.org --- Comment #13 from Eric Botcazou 2012-03-21 17:08:55 UTC --- *** Bug 52657 has been marked as a duplicate of this bug. ***
[Bug testsuite/52641] Test cases fail for 16-bit int targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52641 Hans-Peter Nilsson changed: What|Removed |Added CC||hp at gcc dot gnu.org --- Comment #3 from Hans-Peter Nilsson 2012-03-21 17:46:17 UTC --- FWIW, m68k if only for its option -mshort; by default that port has 32-bit integers.
[Bug c/52640] performance bottleneck: gcc/tree.c;value_member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52640 --- Comment #8 from ncahill_alt at yahoo dot com 2012-03-21 17:47:21 UTC --- Created attachment 26945 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26945 gcc -version && output with -v added
[Bug middle-end/52640] [4.5/4.6/4.7/4.8 Regression] performance bottleneck: gcc/tree.c;value_member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52640 Steven Bosscher changed: What|Removed |Added Keywords||compile-time-hog Status|WAITING |ASSIGNED Component|c |middle-end Summary|performance bottleneck: |[4.5/4.6/4.7/4.8 |gcc/tree.c;value_member |Regression] performance ||bottleneck: ||gcc/tree.c;value_member --- Comment #9 from Steven Bosscher 2012-03-21 18:35:10 UTC --- Regression w.r.t. GCC3 on all active release branches.
[Bug testsuite/52614] [4.8 Regression] Test failures in gcc.dg/vect: vectorizing unaligned access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52614 --- Comment #8 from William J. Schmidt 2012-03-21 18:34:55 UTC --- I would be willing to commit the patches once they're approved. Let me know.
[Bug middle-end/52450] FAIL: gcc.dg/torture/pr52402.c at -O1 and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52450 --- Comment #12 from John David Anglin 2012-03-21 19:39:23 UTC --- Seems fixed on trunk: http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02426.html Started working on movmisalign but implementation is a bit tricky.
[Bug middle-end/52640] [4.5/4.6/4.7/4.8 Regression] performance bottleneck: gcc/tree.c;value_member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52640 --- Comment #10 from Jan Smets 2012-03-21 19:46:31 UTC --- Works. ~13 sec for 243k entries. Still slower than GCC 3.4 but at least better than 80+ seconds.
[Bug target/52479] SH Target: SH4A DFmode fsca tests failing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52479 --- Comment #4 from Oleg Endo 2012-03-21 20:24:59 UTC --- Author: olegendo Date: Wed Mar 21 20:24:41 2012 New Revision: 185617 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185617 Log: PR target/52479 * config/sh/sh-protos.h (sh_fsca_df2int): Remove. * config/sh/sh.c (sh_fsca_df2int_rtx, sh_fsca_df2int): Remove. * config/sh/sh.md (sindf2, cosdf2): Remove. * gcc.target/sh/sh4a-cos.c: Remove. * gcc.target/sh/sh4a-sin.c: Remove. * gcc.target/sh/sh4a-sincos.c: Remove. Removed: trunk/gcc/testsuite/gcc.target/sh/sh4a-cos.c trunk/gcc/testsuite/gcc.target/sh/sh4a-sin.c trunk/gcc/testsuite/gcc.target/sh/sh4a-sincos.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh-protos.h trunk/gcc/config/sh/sh.c trunk/gcc/config/sh/sh.md trunk/gcc/testsuite/ChangeLog
[Bug target/50751] SH Target: Displacement addressing does not work for QImode and HImode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50751 --- Comment #23 from Oleg Endo 2012-03-21 20:27:59 UTC --- Author: olegendo Date: Wed Mar 21 20:27:50 2012 New Revision: 185619 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185619 Log: PR target/50751 * gcc/target/sh/pr50751-1.c: New. * gcc/target/sh/pr50751-2.c: New. * gcc/target/sh/pr50751-3.c: New. Added: trunk/gcc/testsuite/gcc.target/sh/pr50751-1.c trunk/gcc/testsuite/gcc.target/sh/pr50751-2.c trunk/gcc/testsuite/gcc.target/sh/pr50751-3.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug debug/52658] New: RECORD_TYPE in generic tree dump file with non-complete FIELD_DECL tree node
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52658
Bug #: 52658
Summary: RECORD_TYPE in generic tree dump file with
non-complete FIELD_DECL tree node
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: saturn...@163.com
When dumping tree with parameter -ftree-dump-original-raw. class type with
RECORD_TYPE tree node. I just can't find all FIELD_DECL of all its members.
to fix this problem is quite easy
add one line to tree-dump.c just below line number 535
just add "dump_child ("chan",TREE_CHAIN(t));"
now this problem goes away. :-)
[Bug debug/52658] RECORD_TYPE in generic tree dump file with non-complete FIELD_DECL tree node
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52658 --- Comment #1 from saturnman 2012-03-21 20:40:09 UTC --- can any one add this FIX to code base. I just don't has an account, thx.
[Bug target/52642] SH Target: libstdc++ failures due to call insn swapped before prologue frame insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52642 --- Comment #1 from Oleg Endo 2012-03-21 21:12:08 UTC --- Just for the record... I've committed the patch as rev 185616, but also messed up the ChangeLog / commit message header, so it doesn't show up here. (The ChangeLog entry is now fixed)
[Bug c++/52659] New: GCC fails to reject a deleted function definition which is not the first declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52659
Bug #: 52659
Summary: GCC fails to reject a deleted function definition
which is not the first declaration
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: illiss...@gmail.com
C++11 8.4.3.4:
"A deleted definition of a function shall be the first declaration of the
function or, for an explicit specialization of a function template, the first
declaration of that specialization. [ Example:
struct sometype {
sometype();
};
sometype::sometype() = delete; // ill-formed; not first declaration
— end example ]"
$ cat bug.cpp
struct sometype {
sometype();
};
sometype::sometype() = delete;
$ g++ bug.cpp -std=c++11 -c
$ g++ --version
g++ (GCC) 4.7.0 20120314 (prerelease)
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug c++/52659] GCC fails to reject a deleted function definition which is not the first declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52659 Jonathan Wakely changed: What|Removed |Added Keywords||accepts-invalid Status|UNCONFIRMED |NEW Last reconfirmed||2012-03-21 CC||jason at gcc dot gnu.org Ever Confirmed|0 |1
[Bug target/52624] Missing __builtin_bswap16
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52624 --- Comment #3 from Uros Bizjak 2012-03-21 23:25:37 UTC --- Created attachment 26946 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26946 Patch that implements __builtin_bswap16 Untested patch.
[Bug c++/49152] Unhelpful diagnostic for iterator dereference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com Target Milestone|--- |4.8.0 --- Comment #11 from Paolo Carlini 2012-03-22 00:00:20 UTC --- On it.
[Bug c++/52660] New: internal compiler error: in cxx_expand_expr, at cp/expr.c:114
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52660 Bug #: 52660 Summary: internal compiler error: in cxx_expand_expr, at cp/expr.c:114 Classification: Unclassified Product: gcc Version: 3.4.5 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: shang_tao_...@163.com The output of gcc -v -save-temps options source-file is: Reading specs from /usr/local-ae32000/bin/../lib/gcc/ae32000-elf/3.4.5/specs Configured with: ../EISC_gcc-3.4.5/configure --target=ae32000-elf --prefix=/usr/local --enable-languages=c,c++ --with-gnu-as --with-gnu-ld --with-headers=/home/kkh/src/ae32000_v265/newlib-1.14.0/newlib/libc/include --with-newlib --enable-shared Thread model: single gcc version 3.4.5 (AE32000 Compiler v2.6.5 | binutils-2.14 | gdb_insight-6.8) (LDI Code motion / Seperated GCCLIB / mulsi3 / Mem index / Floating-point optimized again / Double precision BUG Fixed) /usr/local-ae32000/bin/../libexec/gcc/ae32000-elf/3.4.5/cc1plus.exe -E -quiet -v -I../../header/include -iprefix /usr/local-ae32000/bin/../lib/gcc/ae32000-elf/3.4.5/ -MMD obj/rwflash.d -MFobj/rwflash.d -MP -MTobj/rwflash.d -MQ obj/rwflash.o rwflash.cpp -Wextra -Wall -fmessage-length=0 -o rwflash.ii ignoring nonexistent directory "/usr/local/include/c++/3.4.5" ignoring nonexistent directory "/usr/local/include/c++/3.4.5/ae32000-elf" ignoring nonexistent directory "/usr/local/include/c++/3.4.5/backward" ignoring nonexistent directory "/usr/local/lib/gcc/ae32000-elf/3.4.5/include" ignoring nonexistent directory "/usr/local/ae32000-elf/sys-include" ignoring nonexistent directory "/usr/local/ae32000-elf/include" #include "..." search starts here: #include <...> search starts here: ../../header/include /usr/local-ae32000/bin/../lib/gcc/ae32000-elf/3.4.5/../../../../include/c++/3.4.5 /usr/local-ae32000/bin/../lib/gcc/ae32000-elf/3.4.5/../../../../include/c++/3.4.5/ae32000-elf /usr/local-ae32000/bin/../lib/gcc/ae32000-elf/3.4.5/../../../../include/c++/3.4.5/backward /usr/local-ae32000/bin/../lib/gcc/ae32000-elf/3.4.5/include /usr/local-ae32000/bin/../lib/gcc/ae32000-elf/3.4.5/../../../../ae32000-elf/sys-include /usr/local-ae32000/bin/../lib/gcc/ae32000-elf/3.4.5/../../../../ae32000-elf/include End of search list. /usr/local-ae32000/bin/../libexec/gcc/ae32000-elf/3.4.5/cc1plus.exe -fpreprocessed rwflash.ii -quiet -dumpbase rwflash.cpp -auxbase-strip obj/rwflash.o -Wextra -Wall -version -fmessage-length=0 -o rwflash.s GNU C++ version 3.4.5 (ae32000-elf) compiled by GNU C version 4.3.4 20090804 (release) 1. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 rwflash.cpp: In member function `void C_FLASH::dosort()': rwflash.cpp:206: internal compiler error: in cxx_expand_expr, at cp/expr.c:114 I think these statement cause this ICE: typedef bool (C_FLASH::*PMF)(PLO,PLO); if(mPLO.empty()) return; PMF pmf = &C_FLASH::ComparePLO; sort(mPLO.begin(),mPLO.end(),this->*pmf);//this is line 206 of rwflash.cpp PLO is a struct,mPLO is std::vector.
[Bug c++/52660] internal compiler error: in cxx_expand_expr, at cp/expr.c:114
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52660 Andrew Pinski changed: What|Removed |Added Target||ae32000-elf Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Andrew Pinski 2012-03-22 02:04:13 UTC --- Two things: 1) 3.4.5 is no longer supported, try a newer version of GCC. 2) ae32000-elf was never supported in any released version of GCC. So please report this bug to where you received GCC from since we don't support it.
[Bug c++/52660] internal compiler error: in cxx_expand_expr, at cp/expr.c:114
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52660 --- Comment #2 from TaoShang 2012-03-22 02:08:03 UTC --- Created attachment 26947 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26947 preprocessed source file
[Bug bootstrap/46981] multilib LD_LIBRARY_PATH prevents configuration of target libraries
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46981 David Edelsohn changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-03-22 CC||dje at gcc dot gnu.org Ever Confirmed|0 |1
[Bug bootstrap/52623] 4.7.0-RC-20120314: bootstrap failure on AIX due to multilib and using C++ in post-stage1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52623 --- Comment #5 from David Edelsohn 2012-03-22 03:00:40 UTC --- AIX fundamentally wants to handle shared objects differently than SVR4/Solaris/Linux. AIX wants to package shared objects in an archive, like normal object files. And AIX library versioning happens within an archive -- all but the newest shared object are marked LOADONLY using the AIX "strip -e" command. Similarly an archive can contain both 32 bit and 64 bit objects. That design does not match multiple shared objects in a directory and separate directories for 32 bit and 64 bit. It also leads to an algorithm design that stops at the first archive found, which conflicts with GCC trying to accommodate Linux's SVR4 design.
[Bug c/52661] New: negative maxint for long long gives warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52661
Bug #: 52661
Summary: negative maxint for long long gives warning
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jmich...@yahoo.com
Created attachment 26948
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26948
maxint64-bug.cpp, the code which causes the warning
I have tried outputting with and I get correct output.
but I get a compiler warning if I use the following constant:
-9223372036854775808LL
//maxint64-bug.cpp
//#include
int main(void) {
long long ll=-9223372036854775808LL;
//std::cout"errmaxint64-bug"
Wed 03/21/2012 22:19:26.01|C:\prj\test\mingw-w64\maxint64-bug|>type
"errmaxint64-bug"
maxint64-bug.cpp:3:19: warning: integer constant is so large that it is
unsigned [enabled by default]
this bug is in 4.6.2 as well as 4.7.0
this number is a valid integer within the long long range. but it is on the
boundary.
the valid range of a long long is -9223372036854775808LL..9223372036854775807LL
or -(2^(64-1))..(2^(64-1)-1)
you can verify this with ttcalc. you can do this with 32-bit and 16-bit and
8-bit signed integers, for instance,
int or long: -(2^(32-1))..(2^(32-1)-1)
short: -(2^(16-1))..(2^(16-1)-1)
char: -(2^(8-1))..(2^(8-1)-1)
THOSE RANGES WORK. this particular constant does NOT.
*/
[Bug c/52661] negative maxint for long long gives warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52661 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Andrew Pinski 2012-03-22 05:58:48 UTC --- -9223372036854775808LL is two tokens - and 9223372036854775808LL which means the warning is correct. If you want -9223372036854775808LL without a warning use: -9223372036854775801LL -1 or better yet just use LONG_LONG_MIN .
