[Bug middle-end/51994] [4.6/4.7 Regression] git-1.7.8.3 miscompiled due to negative bitpos from get_inner_reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51994 --- Comment #17 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-26 08:02:50 UTC --- Doing it in get_inner_reference sounds like a risky change though. E.g. Richard's PR51750 change would need to be adjusted to match it.
[Bug middle-end/51994] [4.6/4.7 Regression] git-1.7.8.3 miscompiled due to negative bitpos from get_inner_reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51994 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #18 from Uros Bizjak ubizjak at gmail dot com 2012-01-26 08:20:27 UTC --- Adding richi to CC.
[Bug target/52006] New: [4.7 Regression] ARM ICE on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52006
Bug #: 52006
Summary: [4.7 Regression] ARM ICE on
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
AssignedTo: ja...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
CC: ram...@gcc.gnu.org
Target: arm*-linux-gnueabi
/* { dg-do compile } */
/* { dg-options -march=armv7-a -mfloat-abi=hard -O2 -fPIC } */
unsigned long a;
static int b;
void
foo (void)
{
asm volatile ( : =r (b));
}
void
bar (float f)
{
if (f b / 100.0)
a = 1;
}
ICEs on arm with:
error: insn does not satisfy its constraints:
(insn 69 64 10 2 (set (reg:SI 77 s14 [orig:143 b ] [143])
(mem:SI (unspec:SI [
(reg/f:SI 2 r2 [141])
(const_int 8 [0x8])
(const_int 1 [0x1])
] UNSPEC_PIC_BASE) [0 S4 A32])) rh784748.i:17 188
{tls_load_dot_plus_eight}
(nil))
rh784748.i:19:1: internal compiler error: in copyprop_hardreg_forward_1, at
regcprop.c:767
[Bug target/52006] [4.7 Regression] ARM ICE with incorrectly peepholed tls_load_dot_plus_eight
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52006 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-01-26 Summary|[4.7 Regression] ARM ICE on |[4.7 Regression] ARM ICE ||with incorrectly peepholed ||tls_load_dot_plus_eight Ever Confirmed|0 |1
[Bug target/52006] [4.7 Regression] ARM ICE with incorrectly peepholed tls_load_dot_plus_eight
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52006 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Known to work||4.6.3 Target Milestone|--- |4.7.0 Known to fail||4.7.0
[Bug target/52006] [4.7 Regression] ARM ICE with incorrectly peepholed tls_load_dot_plus_eight
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52006 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-26 09:35:30 UTC --- Created attachment 26471 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26471 gcc47-pr52006.patch Untested fix.
[Bug middle-end/51994] [4.6/4.7 Regression] git-1.7.8.3 miscompiled due to negative bitpos from get_inner_reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51994
--- Comment #19 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-26
10:01:23 UTC ---
I agree, all callers of get_inner_reference need to cope with a negative
bitpos. Those that forward it unchecked to functions that expect an
unsigned bitpos are broken.
Thus I think fixing the prototypes is correct. If that exposes other
issues we have to fix them. The issue in extract_split_bit_field
is obviously the same - unsigned prototype and unsigned offset in
while (bitsdone bitsize)
{
unsigned HOST_WIDE_INT thissize;
rtx part, word;
unsigned HOST_WIDE_INT thispos;
unsigned HOST_WIDE_INT offset;
offset = (bitpos + bitsdone) / unit;
also
thispos = (bitpos + bitsdone) % unit;
might not be correct with a negative (bitpos + bitsdone).
extract_fixed_bit_field has the same prototype issue, so eventually we
want to simply account for them in the callers (if there are less).
Only memory operands may have a negative bitpos and those we should be
able to adjust via adjust_address (but by what amount?) to make bitpos
positive.
So you could say already the routines called from the get_inner_reference
callers should do that.
Eric, you should know this area the best - what do you recommend here?
[we could assert in the unsigned bitpos taking functions that the MSB
is not set on bitpos]
[Bug c/52007] New: configure: error: installation or configuration problem: C compiler cannot create executables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52007 Bug #: 52007 Summary: configure: error: installation or configuration problem: C compiler cannot create executables Classification: Unclassified Product: gcc Version: 4.2.4 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: chilakaraviku...@yahoo.co.in While installing gcc on a IA64 rhel5 box, I am facing the below problem. /root/gcc/gcc-4.2.4 [root@colt102d gcc-4.2.4]# CC=gcc [root@colt102d gcc-4.2.4]# export CC [root@colt102d gcc-4.2.4]# ./configure loading cache ./config.cache checking host system type... ia64-unknown-linux-gnu checking target system type... ia64-unknown-linux-gnu checking build system type... ia64-unknown-linux-gnu checking for a BSD compatible install... /usr/bin/install -c checking whether ln works... yes checking whether ln -s works... yes checking for gcc... gcc checking whether the C compiler (gcc ) works... no configure: error: installation or configuration problem: C compiler cannot create executables. [root@colt102d gcc-4.2.4]# uname -m ia64 [root@colt102d gcc-4.2.4]# uname -a Linux colt102d.fchst.usa.hp.com 2.6.18-274.el5 #1 SMP Fri Jul 8 17:41:07 EDT 2011 ia64 ia64 ia64 GNU/Linux Thanks Ravi
[Bug bootstrap/52007] configure: error: installation or configuration problem: C compiler cannot create executables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52007 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-01-26 Component|c |bootstrap Ever Confirmed|0 |1 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-01-26 10:24:37 UTC --- You should look into config.log to find out why it fails. Also don't build in the source directory. I bet you don't have all the right packages installed to use gcc.
[Bug bootstrap/52007] configure: error: installation or configuration problem: C compiler cannot create executables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52007 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Severity|critical|normal
[Bug bootstrap/52007] configure: error: installation or configuration problem: C compiler cannot create executables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52007 --- Comment #2 from chilaka chilakaravikumar at yahoo dot co.in 2012-01-26 10:28:52 UTC --- (In reply to comment #1) You should look into config.log to find out why it fails. Also don't build in the source directory. I bet you don't have all the right packages installed to use gcc. config.log content configure:630: checking host system type configure:651: checking target system type configure:669: checking build system type configure:724: checking for a BSD compatible install configure:777: checking whether ln works configure:801: checking whether ln -s works configure:1866: checking for gcc configure:1979: checking whether the C compiler (gcc ) works configure:1995: gcc -o conftestconftest.c 15 ./configure: line 1994: gcc: command not found configure: failed program was: #line 1990 configure #include confdefs.h
[Bug c++/52008] New: [C++0x] ICE when adding partial specialization for variadic-templated structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52008
Bug #: 52008
Summary: [C++0x] ICE when adding partial specialization for
variadic-templated structure
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ethou...@gmail.com
I found this with the following code:
template size_t B, typename Type1, typename... Types
struct tuple_sliced
{
typedef typename tuple_slicedB-1, Types...::type type;
};
templatetypename... Types
struct tuple_sliced0, Types... // -- line 18
{
typedef tupleTypes... type;
};
gcc 4.6 says that it's not implemented to expand Types... in the first
structure. With gcc 4.7 I got a message:
tuple.cc:18:8: internal compiler error: in process_partial_specialization, at
cp/pt.c:4398
The master declaration of tuple_sliced passes correctly - however any use of it
will result in infinite recursion when there's no terminal version.
[Bug bootstrap/52007] configure: error: installation or configuration problem: C compiler cannot create executables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52007
--- Comment #3 from chilaka chilakaravikumar at yahoo dot co.in 2012-01-26
10:39:37 UTC ---
(In reply to comment #2)
(In reply to comment #1)
You should look into config.log to find out why it fails. Also don't build
in
the source directory. I bet you don't have all the right packages
installed to
use gcc.
config.log content
configure:630: checking host system type
configure:651: checking target system type
configure:669: checking build system type
configure:724: checking for a BSD compatible install
configure:777: checking whether ln works
configure:801: checking whether ln -s works
configure:1866: checking for gcc
configure:1979: checking whether the C compiler (gcc ) works
configure:1995: gcc -o conftestconftest.c 15
./configure: line 1994: gcc: command not found
configure: failed program was:
#line 1990 configure
#include confdefs.h
Now I have ran autoconf and then ./configure. Here is content of config.log
#/usr/local/bin/autoconf -v
# ./configure
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.
It was created by configure, which was
generated by GNU Autoconf 2.59. Invocation command line was
$ ./configure
## - ##
## Platform. ##
## - ##
hostname = colt102d.fchst.usa.hp.com
uname -m = ia64
uname -r = 2.6.18-274.el5
uname -s = Linux
uname -v = #1 SMP Fri Jul 8 17:41:07 EDT 2011
/usr/bin/uname -p = unknown
/bin/uname -X = unknown
/bin/arch = ia64
/usr/bin/arch -k = unknown
/usr/convex/getsysinfo = unknown
hostinfo = unknown
/bin/machine = unknown
/usr/bin/oslevel = unknown
/bin/universe = unknown
PATH: /usr/kerberos/sbin
PATH: /usr/kerberos/bin
PATH: /usr/local/sbin
PATH: /usr/local/bin
PATH: /sbin
PATH: /bin
PATH: /usr/sbin
PATH: /usr/bin
PATH: /root/bin
## --- ##
## Core tests. ##
## --- ##
configure:1330: checking build system type
configure:1348: result: ia64-unknown-linux-gnu
configure:1356: checking host system type
configure:1370: result: ia64-unknown-linux-gnu
configure:1378: checking target system type
configure:1392: result: ia64-unknown-linux-gnu
configure:1434: checking for a BSD-compatible install
configure:1489: result: /usr/bin/install -c
configure:1500: checking whether ln works
configure:1522: result: yes
configure:1526: checking whether ln -s works
configure:1530: result: yes
configure:2623: checking for gcc
configure:2649: result: gcc
configure:2893: checking for C compiler version
configure:2896: gcc --version /dev/null 5
./configure: line 2897: gcc: command not found
configure:2899: $? = 127
configure:2901: gcc -v /dev/null 5
./configure: line 2902: gcc: command not found
configure:2904: $? = 127
configure:2906: gcc -V /dev/null 5
./configure: line 2907: gcc: command not found
configure:2909: $? = 127
configure:2932: checking for C compiler default output file name
configure:2935: gccconftest.c 5
./configure: line 2936: gcc: command not found
configure:2938: $? = 127
configure: failed program was:
| /* confdefs.h. */
|
| #define PACKAGE_NAME
| #define PACKAGE_TARNAME
| #define PACKAGE_VERSION
| #define PACKAGE_STRING
| #define PACKAGE_BUGREPORT
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:2977: error: C compiler cannot create executables
See `config.log' for more details.
## ##
## Cache variables. ##
## ##
ac_cv_build=ia64-unknown-linux-gnu
ac_cv_build_alias=ia64-unknown-linux-gnu
ac_cv_env_CC_set=set
ac_cv_env_CC_value=gcc
ac_cv_env_CFLAGS_set=
ac_cv_env_CFLAGS_value=
ac_cv_env_CPPFLAGS_set=
ac_cv_env_CPPFLAGS_value=
ac_cv_env_LDFLAGS_set=
ac_cv_env_LDFLAGS_value=
ac_cv_env_build_alias_set=
ac_cv_env_build_alias_value=
ac_cv_env_host_alias_set=
ac_cv_env_host_alias_value=
ac_cv_env_target_alias_set=
ac_cv_env_target_alias_value=
ac_cv_host=ia64-unknown-linux-gnu
ac_cv_host_alias=ia64-unknown-linux-gnu
ac_cv_path_install='/usr/bin/install -c'
ac_cv_prog_ac_ct_CC=gcc
ac_cv_target=ia64-unknown-linux-gnu
ac_cv_target_alias=ia64-unknown-linux-gnu
acx_cv_prog_LN=ln
## - ##
## Output variables. ##
## - ##
AR=''
AR_FOR_TARGET=''
AS=''
AS_FOR_TARGET=''
BISON=''
CC='gcc'
CC_FOR_BUILD='$(CC)'
CC_FOR_TARGET=''
CFLAGS=''
CFLAGS_FOR_BUILD=''
COMPILER_AS_FOR_TARGET=''
COMPILER_LD_FOR_TARGET=''
COMPILER_NM_FOR_TARGET=''
CONFIGURE_GDB_TK=''
CPPFLAGS=''
CXX=''
CXXFLAGS=''
CXX_FOR_TARGET=''
DEFS=''
DLLTOOL=''
DLLTOOL_FOR_TARGET=''
ECHO_C=''
ECHO_N='-n'
ECHO_T=''
EXEEXT=''
EXPECT=''
FLAGS_FOR_TARGET=''
FLEX=''
GCC_FOR_TARGET=''
GCJ_FOR_TARGET=''
GDB_TK=''
GFORTRAN_FOR_TARGET=''
GNATBIND=''
INSTALL_DATA='${INSTALL} -m 644'
INSTALL_GDB_TK=''
INSTALL_PROGRAM='${INSTALL}'
INSTALL_SCRIPT='${INSTALL}'
LD=''
LDFLAGS=''
LD_FOR_TARGET=''
LEX=''
LIBOBJS=''
LIBS=''
LIPO=''
LIPO_FOR_TARGET=''
LN='ln'
LN_S='ln -s'
[Bug bootstrap/52007] configure: error: installation or configuration problem: C compiler cannot create executables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52007 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED CC||jakub at gcc dot gnu.org Resolution||INVALID --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-26 10:40:52 UTC --- gcc: command not found is a user error, if you don't have a compiler installed, obviously you can't compile anything. yum install gcc should cure it (but to build gcc you'll need some other packages too, like gmp-devel, mpfr-devel etc.).
[Bug bootstrap/52007] configure: error: installation or configuration problem: C compiler cannot create executables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52007 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2012-01-26 10:41:20 UTC --- The problem you're facing is that you didn't read the documentation on installing GCC, starting at http://gcc.gnu.org/install/ and summarised at http://gcc.gnu.org/wiki/InstallingGCC We can't really help you if you don't read the documentation. The first prerequisite for compiling GCC is a working compiler. You've told configure to use CC=gcc but apparently you don't have gcc installed. That's not going to work. If it's a rhel5 box then install the gcc rpm.
[Bug bootstrap/51985] [4.7 Regression] Bootstrap failure due to revision 183457
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51985 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added CC||ramana at gcc dot gnu.org --- Comment #9 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-01-26 10:42:30 UTC --- (In reply to comment #5) Created attachment 26460 [details] gcc47-pr51985.patch Untested fix. The problem was I think that $(inst_sources) was included there twice, once in libc__98convenience_la_SOURCES = $(sources) $(inst_sources) (and for libc__98_la_SOURCES too), and once as part of $(host_sources_extra), which is included in $(sources). This occurred even on x86_64-linux, but wasn't fatal there, libstdc++.a was just much larger than it would have to be (contained additional lt*-*.o objects) and libstdc++.so.6, while it had the same list of exported symbols, was much larger too. bootstrap on arm-linux-gnueabi succeeded. Tests are still running. Ramana
[Bug bootstrap/52007] configure: error: installation or configuration problem: C compiler cannot create executables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52007 --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org 2012-01-26 10:44:35 UTC --- (In reply to comment #3) Now I have ran autoconf and then ./configure. Here is content of config.log #/usr/local/bin/autoconf -v # ./configure Why have you done that? Where in the GCC installation docs does it say to run autoconf? It doesn't, and it explicitly tells you not to run ./configure, and Andrew also told you not to build in the source directory. Read the docs. Building a compiler is not like building other software, don't assume you know how to do it.
[Bug bootstrap/52007] configure: error: installation or configuration problem: C compiler cannot create executables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52007 --- Comment #7 from chilaka chilakaravikumar at yahoo dot co.in 2012-01-26 10:49:12 UTC --- Thanks for the inputs.
[Bug bootstrap/51985] [4.7 Regression] Bootstrap failure due to revision 183457
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51985 --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-26 10:55:20 UTC --- Author: jakub Date: Thu Jan 26 10:55:12 2012 New Revision: 183556 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183556 Log: PR bootstrap/51985 * src/c++98/Makefile.am (libc__98_la_SOURCES, libc__98convenience_la_SOURCES): Remove $(inst_sources). * src/c++98/Makefile.in: Regenerated. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/src/c++98/Makefile.am trunk/libstdc++-v3/src/c++98/Makefile.in
[Bug bootstrap/51985] [4.7 Regression] Bootstrap failure due to revision 183457
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51985 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-26 10:57:23 UTC --- Fixed.
[Bug middle-end/51994] [4.6/4.7 Regression] git-1.7.8.3 miscompiled due to negative bitpos from get_inner_reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51994 --- Comment #20 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-01-26 11:00:33 UTC --- Eric, you should know this area the best - what do you recommend here? [we could assert in the unsigned bitpos taking functions that the MSB is not set on bitpos] I agree that making get_inner_reference artificially return a non-zero poffset would most certainly be problematic as this would change the semantics. But it's also clear that the lower level bit-field manipulation routines aren't really prepared to deal with negative stuff. So I think that we shouldn't change the prototypes of these routines, but instead patch up callers that forward the values returned by get_inner_reference to these routines. Adding assertions in these routines could indeed help.
[Bug c++/52008] [C++0x] ICE when adding partial specialization for variadic-templated structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52008 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-01-26 Ever Confirmed|0 |1 Known to fail||4.7.0 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-26 11:14:14 UTC --- Confirmed.
[Bug c++/52003] warning about (un)existing return statement in the main function declared 'noreturn'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52003 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-01-26 Ever Confirmed|0 |1 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-26 11:19:02 UTC --- (In reply to comment #2) main has an implicit return 0 if it follows through to the end according to the C++ standard IIRC. Indeed it does. GCC simply tells you that putting 'noreturn' on main is not good. If we don't want this warning maybe the C++ FE should mark that return stmt with TREE_NO_WARNING and we should honor that flag.
[Bug rtl-optimization/52000] cross-jumping drops MEM attributes even when it makes no changes to the code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52000 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-26 11:21:33 UTC --- It also calls merge_notes (so I suppose might drop REG_EQUAL notes). Both should be delayed to commit time.
[Bug c++/51641] Lookup finds enclosing class member instead of template parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51641 --- Comment #1 from Dodji Seketeli dodji at gcc dot gnu.org 2012-01-26 12:36:25 UTC --- I candidate patch was sent to http://gcc.gnu.org/ml/gcc-patches/2012-01/msg01371.html
[Bug libstdc++/51798] [4.7 regression] libstdc++ atomicity performance regression due to __sync_fetch_and_add
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51798 --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-26 13:01:58 UTC --- What about the other files that use __sync_* in libstdc++? include/tr1/shared_ptr.h, include/bits/shared_ptr_base.h, include/profile/impl/profiler_state.h, libsupc++/guard.cc and parts of include/parallel/compatibility.h use __sync_*compare_and_swap or __sync_lock_test_and_set, so I assume that we have the same code for those on ppc* as before, but in include/parallel/compatibility.h, libsupc++/eh_tm.cc, libsupc++/eh_ptr.cc and libsupc++/eh_throw.cc __sync_*fetch* is used. Should we change all those to use acq_rel semantics __atomic* counterparts in addition to include/ext/atomicity.h and config/cpu/generic/atomicity_builtins/atomicity.h?
[Bug tree-optimization/52009] New: Another missed tail merging opportunity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52009
Bug #: 52009
Summary: Another missed tail merging opportunity
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vr...@gcc.gnu.org
test-case pr51879-7.c:
...
int bar (int);
void baz (int);
int z;
void
foo (int y)
{
int a;
if (y == 6)
{
z = 5;
a = bar (7);
}
else
{
z = 5;
a = bar (7);
}
baz (a);
}
...
compile:
...
$ gcc -O2 -fdump-tree-all-all pr51879-7.c -S
...
representation at pr51879-7.c.094t.pre:
...
# BLOCK 3 freq:1991
# PRED: 2 [19.9%] (true,exec)
# .MEMD.1717_7 = VDEF .MEMD.1717_6(D)
zD.1708 = 5;
# .MEMD.1717_8 = VDEF .MEMD.1717_7
# USE = nonlocal
# CLB = nonlocal
aD.1712_3 = barD.1703 (7);
goto bb 5;
# SUCC: 5 [100.0%] (fallthru,exec)
# BLOCK 4 freq:8009
# PRED: 2 [80.1%] (false,exec)
# .MEMD.1717_9 = VDEF .MEMD.1717_6(D)
zD.1708 = 5;
# .MEMD.1717_10 = VDEF .MEMD.1717_9
# USE = nonlocal
# CLB = nonlocal
aD.1712_4 = barD.1703 (7);
# SUCC: 5 [100.0%] (fallthru,exec)
# BLOCK 5 freq:1
# PRED: 3 [100.0%] (fallthru,exec) 4 [100.0%] (fallthru,exec)
# aD.1712_1 = PHI aD.1712_3(3), aD.1712_4(4)
# .MEMD.1717_5 = PHI .MEMD.1717_8(3), .MEMD.1717_10(4)
# .MEMD.1717_11 = VDEF .MEMD.1717_5
# USE = nonlocal
# CLB = nonlocal
bazD.1705 (aD.1712_1);
# VUSE .MEMD.1717_11
return;
...
Blocks 3 and 4 are not merged, because .MEMD.1717_7 and .MEMD.1717_9 are not
value numbered the same:
...
SCC consists of: .MEM_7
Value numbering .MEM_7 stmt = z = 5;
RHS 5 simplified to 5
No store match
Value numbering store z to 5
Setting value number of .MEM_7 to .MEM_7 (changed)
...
SCC consists of: .MEM_9
Value numbering .MEM_9 stmt = z = 5;
RHS 5 simplified to 5
No store match
Value numbering store z to 5
Setting value number of .MEM_9 to .MEM_9 (changed)
...
[Bug tree-optimization/48794] [4.7 Regression] ICE: SIGSEGV in remap_eh_region_nr (tree-inline.c:1194) with -Os -fopenmp -fexceptions -fno-tree-ccp -fno-tree-copy-prop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48794 --- Comment #9 from Michael Matz matz at gcc dot gnu.org 2012-01-26 13:25:06 UTC --- Author: matz Date: Thu Jan 26 13:24:58 2012 New Revision: 183559 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183559 Log: PR tree-optimization/48794 * tree-eh.c (remove_unreachable_handlers_no_lp): Don't remove regions referenced from RESX/EH_DISPATCH. testsuite/ * gfortran.dg/gomp/pr48794-2.f90: New testcase. Added: trunk/gcc/testsuite/gfortran.dg/gomp/pr48794-2.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-eh.c
[Bug middle-end/51959] [4.7 Regression] ICE in set_mem_alias_set, at emit-rtl.c:1884
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51959 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Component|target |middle-end --- Comment #5 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-01-26 13:30:43 UTC --- Recategorizing.
[Bug tree-optimization/48794] [4.7 Regression] ICE: SIGSEGV in remap_eh_region_nr (tree-inline.c:1194) with -Os -fopenmp -fexceptions -fno-tree-ccp -fno-tree-copy-prop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48794 Michael Matz matz at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #10 from Michael Matz matz at gcc dot gnu.org 2012-01-26 13:52:15 UTC --- Fixed some more.
[Bug libstdc++/51798] [4.7 regression] libstdc++ atomicity performance regression due to __sync_fetch_and_add
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51798 --- Comment #12 from Andrew Macleod amacleod at redhat dot com 2012-01-26 13:57:56 UTC --- (In reply to comment #11) What about the other files that use __sync_* in libstdc++? I would change the bare minimum... Every change is a risk of some sort this late n the game. The only reason to consider this change was the unacceptable performance regression on power which was reported. If it hasn't been reported, I'd leave it alone personally :-) I hope to replace *all* __sync calls everywhere in the toolchain with __atomic for 4.8. That way there is also time to evaluate the proper model for each one and test it.
[Bug middle-end/51895] [4.7 Regression] ICE in simplify_subreg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51895 --- Comment #18 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-26 14:09:34 UTC --- Author: jakub Date: Thu Jan 26 14:09:29 2012 New Revision: 183560 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183560 Log: PR middle-end/51895 * expr.c (expand_expr_real_1): Handle BLKmode MEM_REF of non-addressable non-BLKmode base correctly. * g++.dg/opt/pr51895.C: New test. Added: trunk/gcc/testsuite/g++.dg/opt/pr51895.C Modified: trunk/gcc/ChangeLog trunk/gcc/expr.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/51895] [4.7 Regression] ICE in simplify_subreg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51895 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #19 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-26 14:11:24 UTC --- Fixed.
[Bug middle-end/51998] compiler hangs on self-recursive alias attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51998 --- Comment #5 from Jan Hubicka hubicka at ucw dot cz 2012-01-26 14:23:21 UTC --- I think remove_attribute would be desirable too. But I wonder if it can't be detected earlier than here. In any case, I'd like to hear Honza on this. I was under impression that varasm code on aliases should already detect cycles. I guess best time to detect cycle is when alias node is created, I will prepare patch for this. Honza
[Bug bootstrap/44173] configure -disable-fixincludes doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44173 Ariel Burton ariel.burton at roguewave dot com changed: What|Removed |Added CC||ariel.burton at roguewave ||dot com --- Comment #2 from Ariel Burton ariel.burton at roguewave dot com 2012-01-26 14:37:51 UTC --- Isn't -disable-fixincludes desirable if you want gcc to always use the system files on the platform on which it is running, rather than that on which it was compiled?
[Bug bootstrap/51999] gcc-4.7-20120114 v. AIX 6.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51999 --- Comment #2 from David Edelsohn dje at gcc dot gnu.org 2012-01-26 14:58:09 UTC --- You seem to have applied a lot of random changes to your system and then reported a GCC bootstrap bug. Do not use GNU Binutils on AIX 6.1.
[Bug libstdc++/51798] [4.7 regression] libstdc++ atomicity performance regression due to __sync_fetch_and_add
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51798 --- Comment #13 from David Edelsohn dje at gcc dot gnu.org 2012-01-26 15:02:14 UTC --- If libstdc++-v3 does not consistently use its own atomicity.h everywhere, then it is even more broken. Any code that explicitly calls __sync_* in libstdc++-v3 has introduced a performance regression.
[Bug target/51974] [4.7 Regression] GCC fails to bootstrap with --enable-checking=release on opensuse
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51974 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-26 15:14:23 UTC --- I can reproduce random comparison failures as well, even with checking enabled, on openSUSE Factory x86_64. I wasn't yet able to reproduce them locally though. I'm trying again.
[Bug libstdc++/51798] [4.7 regression] libstdc++ atomicity performance regression due to __sync_fetch_and_add
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51798 --- Comment #14 from Jonathan Wakely redi at gcc dot gnu.org 2012-01-26 15:25:11 UTC --- (In reply to comment #13) If libstdc++-v3 does not consistently use its own atomicity.h everywhere, then it is even more broken. calm down, a few places in libstdc++ use __sync_compare_and_swap directly because there is no CAS in atomicity.h
[Bug fortran/52010] New: Intrinsic assignment involving CLASS/TYPE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52010 Bug #: 52010 Summary: Intrinsic assignment involving CLASS/TYPE Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: fmarti...@gmv.com The attached examle generates a compiler error about not being able to convert from CLASS to TYPE being the object of the same declared type. Reported bug 41719 addresses partially this issue although looking at the standard (7.4.1) I cannot really see that this assignment is incorrect. The Intel compiler does not complain about this even with the stardard 2003 flags activated.
[Bug debug/52001] [4.7 Regression] Huge compile-time regression with var-tracking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52001 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-26 15:50:20 UTC --- Created attachment 26472 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26472 gcc47-pr52001.patch Untested fix. It doesn't make any sense to insert any reverse ops when V is already known to have a location which is certainly simpler than that and permanently available through the entire function.
[Bug tree-optimization/46590] [4.5/4.6/4.7 Regression] long compile time with -O2 and many loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46590 --- Comment #20 from Michael Matz matz at gcc dot gnu.org 2012-01-26 15:50:43 UTC --- Author: matz Date: Thu Jan 26 15:50:33 2012 New Revision: 183566 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183566 Log: PR tree-optimization/46590 * cfgexpand.c: Revert last change (r183305). * gimplify.c (gimplify_bind_expr): Add clobbers for all non-gimple regs. * tree-eh.c (cleanup_empty_eh): Try to optimize clobbers before checking for emptiness. Modified: trunk/gcc/ChangeLog trunk/gcc/cfgexpand.c trunk/gcc/gimplify.c trunk/gcc/tree-eh.c
[Bug rtl-optimization/51978] ext-elim-1.c ICE on powerpc64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51978 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-26 15:53:03 UTC --- Author: jakub Date: Thu Jan 26 15:52:55 2012 New Revision: 183567 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183567 Log: PR rtl-optimization/51978 * ree.c (make_defs_and_copies_lists): Change set_pat type to const_rtx. (combine_reaching_defs): Likewise. (struct re_info): Remove. (add_removable_extension): Remove x and data arguments, add insn, insn_list and def_map. Use the arguments directly instead of using struct re_info. (find_removable_extensions): Don't call add_removable_extension through note_stores, instead just call it with single_set result if non-NULL. (find_and_remove_re): Pass curr_cand-expr instead of PATTERN (curr_cand-insn) as set_pat argument to combine_reaching_defs. Modified: trunk/gcc/ChangeLog trunk/gcc/ree.c
[Bug rtl-optimization/51978] ext-elim-1.c ICE on powerpc64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51978 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-26 15:54:47 UTC --- Fixed.
[Bug fortran/50981] [4.4/4.5/4.6 Regression] Wrong-code for scalarizing ELEMENTAL call with absent OPTIONAL argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50981 --- Comment #30 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-01-26 16:12:13 UTC --- (In reply to comment #28) Created attachment 26468 [details] better patch This one should work. It does;-) I have applied the patch on revision 183541 on top of the Paul's patch at http://gcc.gnu.org/ml/fortran/2012-01/msg00214.html (pr51870) and Tobias' ones for pr51970 and pr51434 comment #12. It regtested without regression and all the failures reported in comments #25 and #26 are gone. It passes the full comment #13 test fixed as in comment #22 (I blindly trust that it is the right thing to do) and it fixes pr51514 and the test in pr41587 comment #1 (at least part of it: it now prints 0 0 42 while I'ld expect 42 42 42(?); without the patch I get an ICE pr41587_db.f90:10:0: internal compiler error: in gfc_conv_descriptor_data_get, at fortran/trans-array.c:147). The test in comment #23 gives an ICE with/without the patch: pr50981_4.f90: In function 'MAIN__': pr50981_4.f90:16:0: internal compiler error: in fold_convert_loc, at fold-const.c:2016 i.e., the same ICE as for pr51977 (I did not tested the patchlet in comment #27). Thanks for the work!
[Bug fortran/52010] Intrinsic assignment involving CLASS/TYPE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52010 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-01-26 16:22:51 UTC --- The attached examle generates a compiler error about not being able to convert from CLASS to TYPE being the object of the same declared type. There is no attachment!-(
[Bug fortran/52010] Intrinsic assignment involving CLASS/TYPE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52010 --- Comment #2 from Fran Martinez Fadrique fmartinez at gmv dot com 2012-01-26 16:25:41 UTC --- Created attachment 26473 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26473 Test sample
[Bug testsuite/52011] New: FAIL: gcc.dg/lto/trans-mem-* c_lto_trans-mem-*.o assemble, -flto -fgnu-tm in 32 bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52011 Bug #: 52011 Summary: FAIL: gcc.dg/lto/trans-mem-* c_lto_trans-mem-*.o assemble, -flto -fgnu-tm in 32 bit mode Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: al...@gcc.gnu.org, hjl.to...@gmail.com The following tests fail in 32 bit mode FAIL: gcc.dg/lto/trans-mem-1 c_lto_trans-mem-1_1.o assemble, -flto -fgnu-tm FAIL: gcc.dg/lto/trans-mem-2 c_lto_trans-mem-2_0.o assemble, -flto -fgnu-tm FAIL: gcc.dg/lto/trans-mem-3 c_lto_trans-mem-3_1.o assemble, -flto FAIL: gcc.dg/lto/trans-mem-4 c_lto_trans-mem-4_1.o assemble, -flto -fgnu-tm FAIL: gcc.dg/lto/trans-mem-4 c_lto_trans-mem-4_0.o-c_lto_trans-mem-4_1.o link, -flto -fgnu-tm UNRESOLVED: gcc.dg/lto/trans-mem-4 c_lto_trans-mem-4_0.o-c_lto_trans-mem-4_1.o execute -flto -fgnu-tm (see http://gcc.gnu.org/ml/gcc-testresults/2012-01/msg02599.html through the guality mess). The errors are (from http://glutton.geoffk.org/HEAD/native-logsum/gcc/testsuite/gcc/gcc.log.gzip ) Executing on host: /home/regress/tbox/native/build/gcc/xgcc -B/home/regress/tbox/native/build/gcc/ -flto -fgnu-tm -c -o c_lto_trans-mem-1_0.o /home/regress/tbox/svn-gcc/gcc/testsuite/gcc.dg/lto/trans-mem-1_0.c(timeout = 300) PASS: gcc.dg/lto/trans-mem-1 c_lto_trans-mem-1_0.o assemble, -flto -fgnu-tm Executing on host: /home/regress/tbox/native/build/gcc/xgcc -B/home/regress/tbox/native/build/gcc/ -flto -fgnu-tm -c -o c_lto_trans-mem-1_1.o /home/regress/tbox/svn-gcc/gcc/testsuite/gcc.dg/lto/trans-mem-1_1.c(timeout = 300) /home/regress/tbox/svn-gcc/gcc/testsuite/gcc.dg/lto/trans-mem-1_1.c:5:19: warning: conflicting types for built-in function '_ITM_beginTransaction' [enabled by default] /home/regress/tbox/svn-gcc/gcc/testsuite/gcc.dg/lto/trans-mem-1_1.c:6:15: warning: conflicting types for built-in function '_ITM_commitTransaction' [enabled by default] /home/regress/tbox/svn-gcc/gcc/testsuite/gcc.dg/lto/trans-mem-1_1.c:7:15: warning: conflicting types for built-in function '_ITM_WU4' [enabled by default] /home/regress/tbox/svn-gcc/gcc/testsuite/gcc.dg/lto/trans-mem-1_1.c:8:15: warning: conflicting types for built-in function '_ITM_WU8' [enabled by default] output is: /home/regress/tbox/svn-gcc/gcc/testsuite/gcc.dg/lto/trans-mem-1_1.c:5:19: warning: conflicting types for built-in function '_ITM_beginTransaction' [enabled by default] /home/regress/tbox/svn-gcc/gcc/testsuite/gcc.dg/lto/trans-mem-1_1.c:6:15: warning: conflicting types for built-in function '_ITM_commitTransaction' [enabled by default] /home/regress/tbox/svn-gcc/gcc/testsuite/gcc.dg/lto/trans-mem-1_1.c:7:15: warning: conflicting types for built-in function '_ITM_WU4' [enabled by default] /home/regress/tbox/svn-gcc/gcc/testsuite/gcc.dg/lto/trans-mem-1_1.c:8:15: warning: conflicting types for built-in function '_ITM_WU8' [enabled by default] FAIL: gcc.dg/lto/trans-mem-1 c_lto_trans-mem-1_1.o assemble, -flto -fgnu-tm Executing on host: /home/regress/tbox/native/build/gcc/xgcc -B/home/regress/tbox/native/build/gcc/ c_lto_trans-mem-1_0.o c_lto_trans-mem-1_1.o -flto -fgnu-tm -o gcc-dg-lto-trans-mem-1-01.exe (timeout = 300) PASS: gcc.dg/lto/trans-mem-1 c_lto_trans-mem-1_0.o-c_lto_trans-mem-1_1.o link, -flto -fgnu-tm Executing on host: /home/regress/tbox/native/build/gcc/xgcc -B/home/regress/tbox/native/build/gcc/ -flto -fgnu-tm -c -o c_lto_trans-mem-2_0.o /home/regress/tbox/svn-gcc/gcc/testsuite/gcc.dg/lto/trans-mem-2_0.c(timeout = 300) /home/regress/tbox/svn-gcc/gcc/testsuite/gcc.dg/lto/trans-mem-2_0.c:11:19: warning: conflicting types for built-in function '_ITM_beginTransaction' [enabled by default] /home/regress/tbox/svn-gcc/gcc/testsuite/gcc.dg/lto/trans-mem-2_0.c:12:15: warning: conflicting types for built-in function '_ITM_commitTransaction' [enabled by default] /home/regress/tbox/svn-gcc/gcc/testsuite/gcc.dg/lto/trans-mem-2_0.c:13:15: warning: conflicting types for built-in function '_ITM_WU4' [enabled by default] /home/regress/tbox/svn-gcc/gcc/testsuite/gcc.dg/lto/trans-mem-2_0.c:14:15: warning: conflicting types for built-in function '_ITM_WU8' [enabled by default] output is: /home/regress/tbox/svn-gcc/gcc/testsuite/gcc.dg/lto/trans-mem-2_0.c:11:19: warning: conflicting types for built-in function '_ITM_beginTransaction' [enabled by default] /home/regress/tbox/svn-gcc/gcc/testsuite/gcc.dg/lto/trans-mem-2_0.c:12:15: warning: conflicting types for built-in function '_ITM_commitTransaction' [enabled by default] /home/regress/tbox/svn-gcc/gcc/testsuite/gcc.dg/lto/trans-mem-2_0.c:13:15: warning: conflicting types for built-in function '_ITM_WU4' [enabled by default] /home/regress/tbox/svn-gcc/gcc/testsuite/gcc.dg/lto/trans-mem-2_0.c:14:15: warning: conflicting types
[Bug bootstrap/49829] [4.7 Regression] --disable-static --enable-shared regression: cannot find -lstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49829 Benjamin Kosnik bkoz at gcc dot gnu.org changed: What|Removed |Added AssignedTo|unassigned at gcc dot |bkoz at gcc dot gnu.org |gnu.org | --- Comment #24 from Benjamin Kosnik bkoz at gcc dot gnu.org 2012-01-26 16:42:14 UTC --- Mine. Still remaining are 1) update libstdc++ maintainer docs 2) --enable-debug fix
[Bug middle-end/51994] [4.6/4.7 Regression] git-1.7.8.3 miscompiled due to negative bitpos from get_inner_reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51994
Uros Bizjak ubizjak at gmail dot com changed:
What|Removed |Added
Attachment #26466|0 |1
is obsolete||
--- Comment #21 from Uros Bizjak ubizjak at gmail dot com 2012-01-26 18:40:24
UTC ---
Created attachment 26474
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26474
Patch that adds asserts to {extract,store}_bit_field
This patch regressed following tests on x86_64-linux (gcc-46):
FAIL: gcc.dg/pr48335-8.c (internal compiler error)
FAIL: gcc.dg/pr48335-8.c (test for excess errors)
This shows that x86_64 is also not immune to negative bitpos problem.
[Bug middle-end/51994] [4.6/4.7 Regression] git-1.7.8.3 miscompiled due to negative bitpos from get_inner_reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51994 --- Comment #22 from Uros Bizjak ubizjak at gmail dot com 2012-01-26 18:41:57 UTC --- (In reply to comment #20) I agree that making get_inner_reference artificially return a non-zero poffset would most certainly be problematic as this would change the semantics. But it's also clear that the lower level bit-field manipulation routines aren't really prepared to deal with negative stuff. So I think that we shouldn't change the prototypes of these routines, but instead patch up callers that forward the values returned by get_inner_reference to these routines. Adding assertions in these routines could indeed help. I have added these. But.. could you please take the fix to this problem further?
[Bug middle-end/51994] [4.6/4.7 Regression] git-1.7.8.3 miscompiled due to negative bitpos from get_inner_reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51994 --- Comment #23 from Uros Bizjak ubizjak at gmail dot com 2012-01-26 18:51:00 UTC --- With a crosscompiler to alpha-linux-gnu, we can trigger both problems, one with preprocessed source, another with the testcase in latest attached patch: [uros@localhost testalpha]$ ~/gcc-build-alpha-46/gcc/cc1 -O2 -quiet pr51994.c pr51994.c: In function ‘test’: pr51994.c:17:3: internal compiler error: in extract_bit_field, at expmed.c:1701 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. [uros@localhost testalpha]$ ~/gcc-build-alpha-46/gcc/cc1 -O2 -quiet config.i config.c: In function ‘git_config_rename_section’: config.c:1533:16: internal compiler error: in store_bit_field, at expmed.c:839 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug c++/51199] [C++11][DR 547] gcc forms impossible types derived from function types with cv-qualifier-seq
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51199 --- Comment #1 from Daniel Krügler daniel.kruegler at googlemail dot com 2012-01-26 19:32:03 UTC --- Related to this bug: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1417
[Bug libstdc++/51798] [4.7 regression] libstdc++ atomicity performance regression due to __sync_fetch_and_add
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51798 --- Comment #15 from David Edelsohn dje at gcc dot gnu.org 2012-01-26 19:42:47 UTC --- calm down, a few places in libstdc++ use __sync_compare_and_swap directly because there is no CAS in atomicity.h Jonathan, I do not know what you are reading into my comment. This has nothing to do with calmness, it is a statement of fact. If more places in libstdc++ use __sync intrinsics directly, then more places have regressed. It is unfortunate that the current implementation of libstdc++ did not localize the use of those intrinsics.
[Bug libstdc++/51798] [4.7 regression] libstdc++ atomicity performance regression due to __sync_fetch_and_add
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51798 --- Comment #16 from Jonathan Wakely redi at gcc dot gnu.org 2012-01-26 20:39:40 UTC --- Apologies for my phrasing. What I meant is that it's not a matter of consistency. Localising all uses of __sync_bool_compare_and_swap by adding an unnecessary additional layer of indirection in atomicity.h would not have been appropriate. GCC already abstracts the required CAS operation with __sync_bool_compare_and_swap, so that is used directly when needed. One of the main reasons for the wrappers in atomicity.h is to fall back to non-atomic ops in non-threaded code, rather than just to localize the use of intrinisics. Having a fall back for non-threaded code isn't necessary for the places where __sync_bool_compare_and_swap is used in shared_ptr and parallel mode. Our shared_ptr has a partial specialization for the non-threaded case, which doesn't use CAS, and using parallel mode in non-threaded code doesn't make sense. So __sync_bool_compare_and_swap is used directly. It's own atomicity.h doesn't include a CAS operation, and I see no benefit to adding CAS to that file.
[Bug middle-end/51994] [4.6/4.7 Regression] git-1.7.8.3 miscompiled due to negative bitpos from get_inner_reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51994 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |ebotcazou at gcc dot |gnu.org |gnu.org --- Comment #24 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-01-26 21:01:12 UTC --- Investigating.
[Bug c++/51852] [regression] [c++11] tree check: expected tree_list, have HßèMÕþÿøtxøtsø
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51852 --- Comment #11 from Nathan Ridge zeratul976 at hotmail dot com 2012-01-26 21:48:09 UTC --- I bisected the SVN history between the snapshot that worked and the snapshot that gave the error - it appears at r182668.
[Bug fortran/52012] New: [4.6/4.7 Regression] Wrong-code with RESHAPE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52012 Bug #: 52012 Summary: [4.6/4.7 Regression] Wrong-code with RESHAPE Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: wrong-code Severity: critical Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org CC: pa...@gcc.gnu.org The following program prints with GCC 4.6 and 4.7: 0. 0. 1. 0. 0. 0. 0. 0. Expected: The following result - as with GCC 4.5: 0. 0. 1. 0. 0. 0. 0. 1. Doing a simple print '(10f3.0)', a shows the correct result. Thus, depending how one accesses an array element, the result is correct or wrong. The issue was reported by Reinhold Bader; I added the abort checks (both fail). program gf implicit none real, allocatable :: a(:,:,:) ! real :: a(5,4,3) real :: b(3,4,5) = 0.0 b(1,2,3) = 1.0 allocate(a(size(b,3),size(b,2),size(b,1))) a = reshape(b,shape(a),order=[3,2,1]) write(*,*) a(:,2,1) ! the following line prints an incorrect value of a(3,2,1) ! even though the above one works correctly write(*,*) a(1,2,1), a(2,2,1), a(3,2,1) if (a(3,2,1) /= 1) call abort() if (sum(abs(a)) /= 1.0) call abort() end program
[Bug tree-optimization/52005] tree-ssa-combineif does not work with some cfgs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52005
--- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2012-01-26
22:08:05 UTC ---
Here is another testcase:
int f(int x, int a, int b)
{
int t = 0;
int c = 1 a;
if (!(x 1))
t = 0;
else
if (x (1 2))
t = g();
else
t = 0;
return t;
}
The original testcase is not currently optimized with current patch but the
above one is. I am still on the case of the original testcase.
[Bug c++/51908] [C++11] ICE in cp_parser_abort_tentative_parse with decltype and variable template arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51908 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org Summary|ICE in |[C++11] ICE in |cp_parser_abort_tentative_p |cp_parser_abort_tentative_p |arse, |arse with decltype and ||variable template arguments --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2012-01-26 22:27:42 UTC --- This still fails on the trunk: GNU C++ (GCC) version 4.7.0 20120126 (experimental) [trunk revision 183553] (mips64-linux-gnu) compiled by GNU C version 4.7.0 20120126 (experimental) [trunk revision 183553], GMP version 4.3.2, MPFR version 3.0.0, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 56535e31bb34ae0381b37def6782a84b t.cc:4:54: internal compiler error: in cp_parser_abort_tentative_parse, at cp/parser.c:22867 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug target/42240] [4.3/4.4 Regression] wrong epilogue on naked function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42240 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Target Milestone|4.3.6 |4.5.3
[Bug fortran/52012] [4.6/4.7 Regression] Wrong-code with RESHAPE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52012 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org Known to work||4.5.4 Target Milestone|--- |4.7.0 Known to fail||4.6.3, 4.7.0 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-01-26 23:14:42 UTC --- Works: 4.6.0 2010-09-28 rev. 164677 (trunk) Fails: 4.6.0 2010-12-31 rev. 168366 (trunk)
[Bug fortran/52013] New: [OOP] Polymorphism and coarrays: Support as class container
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52013 Bug #: 52013 Summary: [OOP] Polymorphism and coarrays: Support as class container Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: accepts-invalid Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org Currently, the codimension is ignored in the class container. Result: accepts-invalid, wrong-code, and ICE. Example for the former; using coarray dummies in elemental procs is invalid: type t end type t contains elemental subroutine f(x) class(t), intent(inout) :: x ! Valid end subroutine elemental subroutine g(y) class(t), intent(inout) :: y[*] ! Invalid, but not diagnosed end subroutine end
[Bug fortran/52012] [4.6/4.7 Regression] Wrong-code with RESHAPE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52012 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-01-26 Ever Confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-01-26 23:34:05 UTC --- Reduced range Works: 4.6.0 2010-11-26 rev. 167173 (trunk) Fails: 4.6.0 2010-12-02 rev. 167380 (trunk)
[Bug fortran/52012] [4.6/4.7 Regression] Wrong-code with realloc on assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52012 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Summary|[4.6/4.7 Regression]|[4.6/4.7 Regression] |Wrong-code with RESHAPE |Wrong-code with realloc on ||assignment --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2012-01-26 23:43:35 UTC --- Workaround: -fno-realloc-lhs Thus, I assume that the culprit is Paul's patch for PR 35810 (Rev. 167220, 2010-11-28). http://gcc.gnu.org/viewcvs?view=revisionrevision=167220
[Bug c++/51370] [4.6/4.7 Regression] ICE with invalid template parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51370 --- Comment #4 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2012-01-27 00:12:48 UTC --- Author: paolo Date: Fri Jan 27 00:12:41 2012 New Revision: 183593 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183593 Log: /cp 2012-01-26 Paolo Carlini paolo.carl...@oracle.com PR c++/51370 * error.c (dump_decl, [TEMPLATE_ID_EXPR]): Handle error_mark_node as TREE_OPERAND (t, 1). /testsuite 2012-01-26 Paolo Carlini paolo.carl...@oracle.com PR c++/51370 * g++.dg/template/crash112.C: New. Added: trunk/gcc/testsuite/g++.dg/template/crash112.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/error.c trunk/gcc/testsuite/ChangeLog
[Bug c++/51370] [4.6/4.7 Regression] ICE with invalid template parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51370 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|4.6.3 |4.7.0 --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2012-01-27 00:13:58 UTC --- Fixed for 4.7.0.
[Bug c++/51852] [regression] [c++11] tree check: expected tree_list, have HßèMÕþÿøtxøtsø
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51852 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #12 from Jonathan Wakely redi at gcc dot gnu.org 2012-01-27 00:21:43 UTC --- Jason, the fix for PR 51507 might have caused a memory corruption problem, although there's no testcase to reproduce it
[Bug c++/51852] [regression] [c++11] tree check: expected tree_list, have HßèMÕþÿøtxøtsø
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51852 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Keywords||GC --- Comment #13 from Andrew Pinski pinskia at gcc dot gnu.org 2012-01-27 00:25:54 UTC --- One thing to do is to use --param ggc-min-expand=1 --param ggc-min-heapsize=1 and try to reduce it from there. And then when you get down use 0's instead of 1. That should help with GC issues.
[Bug c++/52003] warning about (un)existing return statement in the main function declared 'noreturn'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52003 --- Comment #4 from mauro gnumaurorusso at gmail dot com 2012-01-27 00:27:43 UTC --- (In reply to comment #2) main has an implicit return 0 if it follows through to the end according to the C++ standard IIRC. Ok, I thought it was something like that. Thanks for answer.
[Bug libstdc++/51795] linear_congruential_engine doesn't work correctly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51795
--- Comment #1 from Ed Smith-Rowland 3dw4rd at verizon dot net 2012-01-27
04:48:39 UTC ---
I random.tcc in _Mod
__x = 1103527590
__m = 2147483648
__a = 1103515245
__c = 12345
static const _Tp __q = __m / __a; // 1
static const _Tp __r = __m % __a; // 1043968403
_Tp __t1 = __a * (__x % __q); // 0
_Tp __t2 = __r * (__x / __q); // 1152047935798738770
if (__t1 = __t2)
__x = __t1 - __t2; //
else
__x = __m - __t2 + __t1;// 17294696140058296494 !!!
if (__c != 0)
{
const _Tp __d = __m - __x;// 1152047935798738770
if (__d __c)
__x += __c; // 17294696140058308839
else
__x = __c - __d;
}
[Bug c++/51852] [regression] [c++11] tree check: expected tree_list, have HßèMÕþÿøtxøtsø
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51852 --- Comment #14 from Nathan Ridge zeratul976 at hotmail dot com 2012-01-27 05:37:21 UTC --- (In reply to comment #13) One thing to do is to use --param ggc-min-expand=1 --param ggc-min-heapsize=1 and try to reduce it from there. And then when you get down use 0's instead of 1. That should help with GC issues. The error goes away when I add those options! Is that expected?
[Bug c++/51852] [regression] [c++11] tree check: expected tree_list, have HßèMÕþÿøtxøtsø
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51852 --- Comment #15 from Nathan Ridge zeratul976 at hotmail dot com 2012-01-27 06:29:07 UTC --- (In reply to comment #14) (In reply to comment #13) One thing to do is to use --param ggc-min-expand=1 --param ggc-min-heapsize=1 and try to reduce it from there. And then when you get down use 0's instead of 1. That should help with GC issues. The error goes away when I add those options! Is that expected? On the other hand, if I add only --param gcc-min-expand=1, there error is still there, and it seems to be much more stable now with respect to small changes in the code. There may be hope for a reduction after all...
[Bug c++/51852] [regression] [c++11] tree check: expected tree_list, have HßèMÕþÿøtxøtsø
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51852 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW --- Comment #16 from Jason Merrill jason at gcc dot gnu.org 2012-01-27 06:43:06 UTC --- make check-g++-strict-gc finds failures on several variadic template tests, including variadic99.C, so I don't think reducing your testcase is necessary.
[Bug c++/52014] New: [c++0x] g++: Segfault When `decltype` Used in Nested Lambda Function Defined in Class Member Function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52014 Bug #: 52014 Summary: [c++0x] g++: Segfault When `decltype` Used in Nested Lambda Function Defined in Class Member Function Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: chees...@gmail.com Created attachment 26475 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26475 File containing code sample with offending bug. Hello everyone, When I try to compile the attached C++ file using the following command, g++ undergoes an internal segmentation fault. $ g++ -Wall -std=c++0x nested_lambda.cpp nested_lambda.cpp: In lambda function: nested_lambda.cpp:42:56: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.6/README.Bugs for instructions. Preprocessed source stored into /tmp/ccqYohFA.out file, please attach this to your bugreport. I'm using g++ version 4.6.1, running on Linux Mint 12 64-bit, obtained from the Ubuntu repository.
[Bug c++/52014] [c++0x] g++: Segfault When `decltype` Used in Nested Lambda Function Defined in Class Member Function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52014 --- Comment #1 from cheesear at gmail dot com 2012-01-27 07:05:26 UTC --- Sorry, accidentally hit return before I was ready. The code sample fails to compile because of the use of decltype in the parameter-list of the nested lambda function defined in bar.test(). Using a typedef in advance will circumvent this issue.
[Bug c++/51852] [regression] [c++11] tree check: expected tree_list, have HßèMÕþÿøtxøtsø
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51852
--- Comment #17 from Nathan Ridge zeratul976 at hotmail dot com 2012-01-27
07:30:00 UTC ---
(In reply to comment #16)
make check-g++-strict-gc finds failures on several variadic template tests,
including variadic99.C, so I don't think reducing your testcase is necessary.
Already reduced it :)
It was quite straightforward after using --param gcc-min-heapsize=0 - thanks
Andrew!
Testcase:
template typename, typename
class transformed {};
template class R, class F
transformedF, R transform(R r, F f);
template typename, typename
class joined {};
template typename T, typename U
joinedT, U join(T t, U u);
template typename T, typename U, typename V, typename... Rest
auto join(T t, U u, V v, Rest... rest) - decltype(join(join(t, u), v,
rest...));
template typename F, typename... Rs
auto polymorphic_transform(F f, Rs... rs) - decltype(join((transform(rs,
f))...));
int main()
{
polymorphic_transform(0, 0, 0);
}
Compile with:
g++ -c --std=c++0x --param ggc-min-heapsize=0 test.cpp
Output:
'
tree check: expected tree_list, have Hßfè÷þÿø
ÐÝÿÿ¸l in eq_local_specializations, at cp/pt.c:1687
