[Bug c/38470] value range propagation (VRP) would improve -Wsign-compare
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38470
David Stone DeusExSophismata at gmail dot com changed:
What|Removed |Added
CC||DeusExSophismata at gmail
||dot com
--- Comment #10 from David Stone DeusExSophismata at gmail dot com 2012-03-24
06:52:04 UTC ---
Simple self-contained test case:
unsigned f (int x) {
return (x = 0) ? x : -x;
}
int main () {
return 0;
}
It seems like we could at least add a simple improvement that just checks for
simple comparisons to 0. That probably catches most code (I often do one set of
calculations for non-negative values, and another set for negative values) and
avoids a lot of problems of trying to track complex calculations for the
signedness of the result. I wouldn't be perfect, but it would be better than it
currently is.
Being able to detect cases like this is also an optimization opportunity,
because division with positive integers is simpler than division with negative
integers, for example. We could reuse code that detects that optimization
opportunity for this warning.
[Bug c++/52699] New: infinite loop generated with -O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52699 Bug #: 52699 Summary: infinite loop generated with -O0 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: jarr...@cse.unsw.edu.au
[Bug c++/52699] infinite loop generated with -O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52699
Jarryd Beck jarrydb at cse dot unsw.edu.au changed:
What|Removed |Added
Target||i686-pc-linux-gnu
Host||i686-pc-linux-gnu
Build||i686-pc-linux-gnu
--- Comment #1 from Jarryd Beck jarrydb at cse dot unsw.edu.au 2012-03-24
07:54:23 UTC ---
When the attached file is compiled with no optimisation, the resulting program
never terminates.
g++ -std=gnu++11 random.cpp
If I compile it with:
g++ -std=gnu++11 random.cpp -O1
then it works.
The program is as follows, fully preprocessed sources are attached.
#include random
typedef std::mt19937::result_type unit_type;
typedef std::independent_bits_engine
std::mt19937,
sizeof(unit_type)*8,
unit_type
full_bits_generator;
int main()
{
full_bits_generator gen;
gen();
return 0;
}
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/jarryd/local/gcc-4.8/libexec/gcc/i686-pc-linux-gnu/4.8.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: /home/jarryd/git/gcc-git/configure
--prefix=/home/jarryd/local/gcc-4.8 --disable-multilib --enable-languages=c,c++
Thread model: posix
gcc version 4.8.0 20120323 (experimental) (GCC)
[Bug c++/52699] infinite loop generated with -O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52699 --- Comment #2 from Jarryd Beck jarrydb at cse dot unsw.edu.au 2012-03-24 07:55:16 UTC --- Created attachment 26972 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26972 this file never terminates with -O0
[Bug c++/52699] infinite loop generated with -O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52699 --- Comment #3 from Jarryd Beck jarrydb at cse dot unsw.edu.au 2012-03-24 07:56:15 UTC --- Created attachment 26973 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26973 The preprocessed version
[Bug c++/52699] infinite loop generated with -O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52699 --- Comment #4 from Jarryd Beck jarrydb at cse dot unsw.edu.au 2012-03-24 07:57:20 UTC --- Note that this appears to happen only on 32 bit.
[Bug libstdc++/52699] infinite loop generated with -O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52699 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Component|target |libstdc++ --- Comment #5 from Andrew Pinski pinskia at gcc dot gnu.org 2012-03-24 08:06:58 UTC --- From the looks of it, it looks more like a source (library) issue rather than a compiler one. Though I don't know enough of this code to say that. We are stuck in the following loop: 754 result_type __u; 755 do 756__u = _M_b() - _M_b.min(); 757 while (__u = __y0); __y0 is 0 which means the loop is always true.
[Bug target/52698] -maddress-mode=long doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52698 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Target|x86-64 |x32 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-03-24 AssignedTo|unassigned at gcc dot |ubizjak at gmail dot com |gnu.org | Target Milestone|--- |4.8.0 Ever Confirmed|0 |1 --- Comment #1 from Uros Bizjak ubizjak at gmail dot com 2012-03-24 08:42:04 UTC --- Too many PLUS RTXes in address.
[Bug c++/52697] -Wsign-conversion warns for obviously correct code with implicit promotion to int
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52697 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||manu at gcc dot gnu.org Resolution||DUPLICATE --- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-03-24 09:54:22 UTC --- Despite the testcase is different and the warning/option are also different, this is the same as 51294. unsafe_conversion_p should recurse for the ternary operator. *** This bug has been marked as a duplicate of bug 51294 ***
[Bug c/51294] spurious warning from -Wconversion in C and C++ in conditional expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51294 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||DeusExSophismata at gmail ||dot com --- Comment #7 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-03-24 09:54:22 UTC --- *** Bug 52697 has been marked as a duplicate of this bug. ***
[Bug libitm/52695] libitm/config/x86/cacheline.h: '__m64' does not name a type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52695 --- Comment #4 from ncahill_alt at yahoo dot com 2012-03-24 10:18:15 UTC --- (In reply to comment #3) --enable-bootstrap \ Can you try without that? I get the same error and the same workaround allows the build to complete.
[Bug bootstrap/52700] New: libjava configure fails on --enable-symvers=gnu-versioned-namespace.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52700 Bug #: 52700 Summary: libjava configure fails on --enable-symvers=gnu-versioned-namespace. Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: pl...@agmk.net Host: x86_64-gnu-linux Target: x86_64-gnu-linux Build: x86_64-gnu-linux the 4.7.1 boostrap fails inside libjava on --enable-symvers=gnu-versioned-namespace option. (...) checking whether ld supports anonymous version scripts... configure: error: Unknown argument to enable/disable symvers make[1]: *** [configure-target-libjava] Error 1 afaics it accepts only yes/no values: # See if linker supports anonymous version scripts. AC_CACHE_CHECK([whether ld supports anonymous version scripts], [libjava_cv_anon_version_script], [AC_ARG_ENABLE(symvers, AS_HELP_STRING([--disable-symvers], [disable symbol versioning for libjava]), [case $enableval in yes) libjava_cv_anon_version_script=yes ;; no) libjava_cv_anon_version_script=no ;; *) AC_MSG_ERROR([Unknown argument to enable/disable symvers]);; esac], [libjava_cv_anon_version_script=yes] )
[Bug libitm/52695] libitm/config/x86/cacheline.h: '__m64' does not name a type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52695 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||torvald at gcc dot gnu.org --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2012-03-24 10:57:29 UTC --- Looks like a bug in libitm/config/x86/target.h: // We'll be using some of the cpu builtins, and their associated types. #ifndef __cplusplus /* ??? It's broken for C++. */ #include x86intrin.h #else # ifdef __SSE2__ # include emmintrin.h # elif defined(__SSE__) # include xmmintrin.h # endif # ifdef __AVX__ # include immintrin.h # endif #endif No idea what brokeness the above talks about, it works just fine for me in C++, so IMHO it just should always include x86intrin.h, but certainly if __MMX__ is defined, but no __SSE__, the above won't include in C++ any header which would define __m64.
[Bug regression/52696] [4.6 Regression]: g++.dg/tree-ssa/pr44706.C scan-tree-dump-not fnsplit Splitting function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52696 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se 2012-03-24 13:32:47 UTC --- This regression also occurs for the i686-linux target.
[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 #11 from Steven Bosscher steven at gcc dot gnu.org 2012-03-24 13:46:42 UTC --- Author: steven Date: Sat Mar 24 13:46:33 2012 New Revision: 185757 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=185757 Log: gcc/ PR middle-end/52640 * varasm.c: Include pointer-set.h. (pending_assemble_externals_set): New pointer set. (process_pending_assemble_externals): Destroy the pointer set. (assemble_external): See if decl is in pending_assemble_externals_set, and add it to pending_assemble_externals if necessary. (init_varasm_once): Allocate pending_assemble_externals_set. testsuite/ PR middle-end/52640 * gcc.c-torture/compile/limits-externdecl.c: New test. Added: branches/gcc-4_5-branch/gcc/testsuite/gcc.c-torture/compile/limits-externdecl.c Modified: branches/gcc-4_5-branch/gcc/varasm.c
[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 #12 from Steven Bosscher steven at gcc dot gnu.org 2012-03-24 13:47:51 UTC --- Author: steven Date: Sat Mar 24 13:47:46 2012 New Revision: 185758 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=185758 Log: gcc/ PR middle-end/52640 * varasm.c: Include pointer-set.h. (pending_assemble_externals_set): New pointer set. (process_pending_assemble_externals): Destroy the pointer set. (assemble_external): See if decl is in pending_assemble_externals_set, and add it to pending_assemble_externals if necessary. (init_varasm_once): Allocate pending_assemble_externals_set. testsuite/ PR middle-end/52640 * gcc.c-torture/compile/limits-externdecl.c: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/gcc.c-torture/compile/limits-externdecl.c Modified: branches/gcc-4_6-branch/gcc/varasm.c
[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 #13 from Steven Bosscher steven at gcc dot gnu.org 2012-03-24 13:48:51 UTC --- Author: steven Date: Sat Mar 24 13:48:35 2012 New Revision: 185759 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=185759 Log: gcc/ PR middle-end/52640 * varasm.c: Include pointer-set.h. (pending_assemble_externals_set): New pointer set. (process_pending_assemble_externals): Destroy the pointer set. (assemble_external): See if decl is in pending_assemble_externals_set, and add it to pending_assemble_externals if necessary. (init_varasm_once): Allocate pending_assemble_externals_set. testsuite/ PR middle-end/52640 * gcc.c-torture/compile/limits-externdecl.c: New test. Added: branches/gcc-4_7-branch/gcc/testsuite/gcc.c-torture/compile/limits-externdecl.c Modified: branches/gcc-4_7-branch/gcc/varasm.c
[Bug middle-end/52640] [4.8 Regression] performance bottleneck: gcc/tree.c;value_member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52640 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Known to work||4.5.5, 4.6.4, 4.7.1 Target Milestone|--- |4.5.4 Summary|[4.5/4.6/4.7/4.8|[4.8 Regression] |Regression] performance |performance bottleneck: |bottleneck: |gcc/tree.c;value_member |gcc/tree.c;value_member | Known to fail||4.8.0 --- Comment #14 from Steven Bosscher steven at gcc dot gnu.org 2012-03-24 13:52:21 UTC --- Fixed on release branches.
[Bug fortran/52701] New: [4.8 Regression] 416.gamess in SPEC CPU 2006 failed to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52701 Bug #: 52701 Summary: [4.8 Regression] 416.gamess in SPEC CPU 2006 failed to build Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com CC: areg.melikadam...@gmail.com On Linux/x86-64, revision 185738 gave gfortran -c -o mp2ddi.fppized.o -O3 -funroll-loops -ffast-math -ffixed-form mp2ddi.fppized.f ... Warning: Type mismatch in argument 'ix' at (1); passed REAL(8) to INTEGER(4) mp2grd.fppized.f:5241.47: CALL TRFRD(NFT15,XINB(1,NMU,MI),NX,PHFA,NIX,NBF2) 1 Warning: Type mismatch in argument 'ix' at (1); passed REAL(8) to INTEGER(4) mp2ddi.fppized.f: In function 'wp': mp2ddi.fppized.f:2597:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Revision 185629 is OK.
[Bug c++/52688] static local variable can accessed from local class of function template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52688 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID Severity|major |normal --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-03-24 15:06:27 UTC --- http://gcc.gnu.org/wiki/VerboseDiagnostics#missing_static_const_definition
[Bug target/52698] -maddress-mode=long doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52698
--- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2012-03-24 15:20:06
UTC ---
Created attachment 26974
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26974
A patch
I am testing this patch with
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index a21f2da..586be4b 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -3181,7 +3181,7 @@ ix86_option_override_internal (bool main_args_p)
TARGET_64BIT ? 64 : 32);
}
else
-ix86_pmode = TARGET_LP64 ? PMODE_DI : PMODE_SI;
+ix86_pmode = TARGET_64BIT ? PMODE_DI : PMODE_SI;
if (!global_options_set.x_ix86_abi)
ix86_abi = DEFAULT_ABI;
I will run GCC testsuite as well as glibc build/test. As I
indicated before, we can use
mov{l}\t{%%fs:0, %k0|%k0, DWORD PTR fs:0}
to load thread pointer, which is an unsigned integral value
with range from 0 to 0x into both SImode and DImode
register. There is no need for zero-extend.
[Bug c++/52688] static local variable can accessed from local class of function template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52688 --- Comment #3 from Sarfaraz Nawaz sir_nawaz959 at yahoo dot com 2012-03-24 15:25:22 UTC --- (In reply to comment #2) http://gcc.gnu.org/wiki/VerboseDiagnostics#missing_static_const_definition Jonathan, that is a different case. A static (const or otherwise) member of a class needs a definition in order to take its address, but the bug I reported is not about static member of a class, rather it is about a static variable local to a function template. Interestingly as I said, this code compiles fine in gcc-4.5.1, but not in gcc-4.6.1. Also, if I do the same in a non-template function, it works fine, as expected.
[Bug c++/49152] Unhelpful diagnostic for iterator dereference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #21 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-03-24 16:32:07 UTC --- Jason, do you have an opinion on this?
[Bug target/52698] -maddress-mode=long doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52698 --- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2012-03-24 16:59:17 UTC --- (In reply to comment #2) Created attachment 26974 [details] A patch I am testing this patch with This patch passes GCC testsuite as well as glibc build/test with both -maddress-mode=long and -maddress-mode=short.
[Bug libstdc++/52702] New: [C++11] std::is_trivially_destructible is missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52702
Bug #: 52702
Summary: [C++11] std::is_trivially_destructible is missing
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.krueg...@googlemail.com
gcc 4.8.0 20120318 (experimental) in C++11 mode rejects the following code:
//-
#include type_traits
struct pod {};
struct non_pod { ~non_pod(); };
static_assert(std::is_trivially_destructiblepod::value, );
static_assert(std::is_trivially_destructibleint::value, );
static_assert(!std::is_trivially_destructiblenon_pod::value, );
//-
due to the missing definition of the is_trivially_destructible type trait.
This should not be much work, because the TR1 trait has_trivial_destructor does
exist and uses the __has_trivial_destructor intrinsic and is_destructible is
also provided.
[Bug c++/52703] New: -Wsign-conversion warns for unsigned short promoted to int and assigned to unsigned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52703
Bug #: 52703
Summary: -Wsign-conversion warns for unsigned short promoted to
int and assigned to unsigned
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: deusexsophism...@gmail.com
$ g++ test.cpp -Wsign-conversion
test.cpp: In function ‘int main()’:
test.cpp:7:19: warning: conversion to ‘unsigned int’ from ‘int’ may change the
sign of the result [-Wsign-conversion]
test.cpp:8:10: warning: conversion to ‘unsigned int’ from ‘int’ may change the
sign of the result [-Wsign-conversion]
unsigned f (unsigned x) {
return x;
}
int main () {
unsigned short a = 0;
unsigned b = a + 1;
f (a + 1);
return 0;
}
The implicit conversion to int from unsigned short causes gcc to think that the
result of a + 1 could theoretically be a negative value (since it's an int).
However, it cannot be no matter what value a has (since we know it's unsigned).
signed overflow is undefined, so we don't have to worry about a + (integral
constant expression) INT_MAX.
Note that the bug does not trigger if + 1 is replaced with + 0. My guess is
that the removal of addition by 0 happens before this warning is checked. It
also does not trigger if a is declared `unsigned short const` instead of just
`unsigned short`.
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.6.2/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin
--enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-ppl --with-cloog --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.6.2 20111027 (Red Hat 4.6.2-1) (GCC)
[Bug fortran/52701] [4.8 Regression] 416.gamess in SPEC CPU 2006 failed to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52701 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-03-24 CC||tkoenig at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-03-24 17:56:33 UTC --- I don't have access to the SPEC sources. Do you have a reduced test case?
[Bug fortran/52668] [4.7/4.8 Regression] Incorrect unused warning for USE associating variable in common block
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52668 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |tkoenig at gcc dot gnu.org |gnu.org | --- Comment #1 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-03-24 17:57:18 UTC --- I have a patch.
[Bug middle-end/52656] [4.8 regression] gcc.target/sparc/fpmul-2.c FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52656 --- Comment #2 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-03-24 18:42:29 UTC --- Author: ebotcazou Date: Sat Mar 24 18:42:24 2012 New Revision: 185764 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=185764 Log: PR target/52656 * config/sparc/sparc.c (sparc_handle_vis_mul8x16): Fix pasto. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sparc/sparc.c
[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 ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-03-24 18:44:16 UTC --- Thanks for reporting the problem.
[Bug target/52610] mpfr fails to compile when specifying CFLAGS=-O3 -mcpu=leon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52610 --- Comment #3 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-03-24 18:47:43 UTC --- Author: ebotcazou Date: Sat Mar 24 18:47:38 2012 New Revision: 185765 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=185765 Log: PR target/52610 * config/sparc/sparc.h (ASM_CPU_SPEC): Pass -Av8 if -mcpu=leon. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sparc/sparc.h
[Bug target/52610] mpfr fails to compile when specifying CFLAGS=-O3 -mcpu=leon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52610 --- Comment #4 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-03-24 18:48:00 UTC --- Author: ebotcazou Date: Sat Mar 24 18:47:55 2012 New Revision: 185766 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=185766 Log: PR target/52610 * config/sparc/sparc.h (ASM_CPU_SPEC): Pass -Av8 if -mcpu=leon. Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/config/sparc/sparc.h
[Bug target/52610] mpfr fails to compile when specifying CFLAGS=-O3 -mcpu=leon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52610 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.7.1 --- Comment #5 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-03-24 18:49:38 UTC --- In the next 4.7.x release. Thanks for reporting the problem.
[Bug c/48956] -Wconversion should warn when a complex value is assigned to a real result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48956 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||bratsinot at gmail dot com --- Comment #8 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-03-24 19:14:49 UTC --- *** Bug 50992 has been marked as a duplicate of this bug. ***
[Bug c/50992] Wconversion does not handle complex type conversions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50992 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #7 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-03-24 19:14:49 UTC --- It seems someone did a patch in a different bug report, but didn't submit it for approval. *** This bug has been marked as a duplicate of bug 48956 ***
[Bug c++/52703] -Wsign-conversion warns for unsigned short promoted to int and assigned to unsigned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52703 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||manu at gcc dot gnu.org Resolution||DUPLICATE --- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-03-24 19:27:54 UTC --- Strangely, I cannot reproduce this with g++ 4.7.0, but I can with gcc. In any case, the warning code does not look into the operands of operators. I did a patch to do this, and it was rejected. Feel free to take it and improve it and get it accepted. *** This bug has been marked as a duplicate of bug 40752 ***
[Bug c++/40752] -Wconversion generates false warnings for operands not larger than target type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40752 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||DeusExSophismata at gmail ||dot com --- Comment #20 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-03-24 19:27:54 UTC --- *** Bug 52703 has been marked as a duplicate of this bug. ***
[Bug libstdc++/52689] static linking with libstdc++ fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52689 --- Comment #5 from Markus Trippelsdorf markus at trippelsdorf dot de 2012-03-24 20:20:54 UTC --- It looks like a linker bug. I was able to reproduce the issue with Fedora17. $ ld -v GNU ld version 2.22.52.0.1-10.fc17 20120131 $ g++ x.cc -static-libstdc++ /usr/bin/ld: a.out: No symbol version section for versioned symbol `_ZSt15future_category@@GLIBCXX_3.4.14' /usr/bin/ld: final link failed: Nonrepresentable section on output collect2: error: ld returned 1 exit status Gold is fine: $ sudo ln -f /bin/ld.gold /bin/ld $ g++ x.cc -static-libstdc++ $
[Bug target/52610] mpfr fails to compile when specifying CFLAGS=-O3 -mcpu=leon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52610 --- Comment #6 from Matt Hargett matt at use dot net 2012-03-24 20:20:42 UTC --- Great. I verified the fix yesterday. Thanks!
[Bug middle-end/52704] New: thunk referenced in discarded section when combining -flto -ftree-vectorize -fipa-cp-clone on Debian/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52704 Bug #: 52704 Summary: thunk referenced in discarded section when combining -flto -ftree-vectorize -fipa-cp-clone on Debian/SPARC Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: m...@use.net To reproduce from scratch with 4.7.0 and sambe-3.6.3 (reduced case below/attached): debian-sparc:~/src/samba-3.6.3/source3# CFLAGS=-O2 -flto -mtune=leon -floop-block -floop-interchange -floop-strip-mine -ftree-loop-distribution -ftree-loop-distribute-patterns -ftree-loop-im -ftree-loop-ivcanon -fivopts -fpredictive-commoning -fipa-cp-clone -ftree-vectorize -ffast-math -fgcse-after-reload -fgcse-sm -fgcse-las LDFLAGS=-flto -O2 ./configure --prefix=/opt/samba-3.6.4 --exec-prefix=/opt/samba-3.6.4 --sysconfdir=/opt/samba-3.6.4/etc --with-configdir=/opt/samba-3.6.4/etc --with-quotas --with-pam --with-pam_smbpass --build=sparc-linux --with-logfilebase=/opt/samba-3.6.4/var/log --with-piddir=/opt/samba-3.6.4/var/run --with-lockdir=/opt/samba-3.6.4/var/lock debian-sparc:~/src/samba-3.6.3/source3# make [...] Linking shared library bin/libtdb.so.1 gcc -I../lib/zlib -O2 -flto -mtune=leon -floop-block -floop-interchange -floop-strip-mine -ftree-loop-distribution -ftree-loop-distribute-patterns -ftree-loop-im -ftree-loop-ivcanon -fivopts -fpredictive-commoning -fipa-cp-clone -ftree-vectorize -ffast-math -fgcse-after-reload -fgcse-sm -fgcse-las -I. -I/root/src/samba-3.6.3/source3 -I/root/src/samba-3.6.3/source3/../lib/iniparser/src -Iinclude -I./include -I. -I. -I./../lib/replace -I./../lib/tevent -I./librpc -I./.. -I./../lib/talloc -I../lib/tdb/include -DHAVE_CONFIG_H -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -Iinclude -I./include -I. -I. -I./../lib/replace -I./../lib/tevent -I./librpc -I./.. -I./../lib/popt -DLDAP_DEPRECATED -I/root/src/samba-3.6.3/source3/lib -I.. -D_SAMBA_BUILD_=3 -D_SAMBA_BUILD_=3 -fPIC -shared -Wl,-Bsymbolic -Wl,-z,relro -flto -O2 -L./bin -lc -Wl,-z,defs -Wl,--version-script,/root/src/samba-3.6.3/source3/exports/`basename bin/libtdb.so.1 | sed 's:\.so[\.0-9]*$:.syms:'` -o bin/libtdb.so.1 ../lib/tdb/common/tdb.o ../lib/tdb/common/dump.o ../lib/tdb/common/transaction.o ../lib/tdb/common/error.o ../lib/tdb/common/traverse.o ../lib/tdb/common/freelist.o ../lib/tdb/common/freelistcheck.o ../lib/tdb/common/io.o ../lib/tdb/common/lock.o ../lib/tdb/common/open.o ../lib/tdb/common/check.o ../lib/tdb/common/hash.o ../lib/tdb/common/summary.o ./../lib/replace/replace.o ./../lib/replace/snprintf.o ./../lib/replace/getpass.o\ -Wl,-soname=`basename bin/libtdb.so.1` `__sparc_get_pc_thunk.l7' referenced in section `.text' of /tmp/ccUwrHhg.ltrans2.ltrans.o: defined in discarded section `.text.__sparc_get_pc_thunk.l7.2305[__sparc_get_pc_thunk.l7.2305]' of /tmp/ccUwrHhg.ltrans2.ltrans.o collect2: error: ld returned 1 exit status I reduced it to an interaction between tree-vectorize and ipa-cp-clone with inline-functions is *not* present. when using -O3, or adding inline-functions along with those two options, the problem goes away: gcc -I../lib/zlib -O0 -flto -ftree-vectorize -fipa-cp-clone -I. -I/root/src/samba-3.6.3/source3 -I/root/src/samba-3.6.3/source3/../lib/iniparser/src -Iinclude -I./include -I. -I. -I./../lib/replace -I./../lib/tevent -I./librpc -I./.. -I./../lib/talloc -I../lib/tdb/include -DHAVE_CONFIG_H -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -Iinclude -I./include -I. -I. -I./../lib/replace -I./../lib/tevent -I./librpc -I./.. -I./../lib/popt -DLDAP_DEPRECATED -I/root/src/samba-3.6.3/source3/lib -I.. -D_SAMBA_BUILD_=3 -D_SAMBA_BUILD_=3 -fPIC -shared -Wl,-Bsymbolic -Wl,-z,relro -flto -O2 -L./bin -lc -Wl,-z,defs -Wl,--version-script,/root/src/samba-3.6.3/source3/exports/`basename bin/libtdb.so.1 | sed 's:\.so[\.0-9]*$:.syms:'` -o bin/libtdb.so.1 ../lib/tdb/common/tdb.o ../lib/tdb/common/dump.o ../lib/tdb/common/transaction.o ../lib/tdb/common/error.o ../lib/tdb/common/traverse.o ../lib/tdb/common/freelist.o ../lib/tdb/common/freelistcheck.o ../lib/tdb/common/io.o ../lib/tdb/common/lock.o ../lib/tdb/common/open.o ../lib/tdb/common/check.o ../lib/tdb/common/hash.o ../lib/tdb/common/summary.o ./../lib/replace/replace.o ./../lib/replace/snprintf.o ./../lib/replace/getpass.o -Wl,-soname=`basename bin/libtdb.so.1` `__sparc_get_pc_thunk.l7' referenced in section `.text' of libtdb.so.1.ltrans2.ltrans.o: defined in discarded section `.text.__sparc_get_pc_thunk.l7.2305[__sparc_get_pc_thunk.l7.2305]' of libtdb.so.1.ltrans2.ltrans.o Attached are the save-temps outputs and (hopefully) enough of the original source dir to reproduce otherwise.
[Bug lto/51663] LTO does not reclaim comdat-local statics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51663 --- Comment #4 from Jan Hubicka hubicka at gcc dot gnu.org 2012-03-24 20:59:38 UTC --- Works for me: jh@evans:/abuild/jh/trunk-3/build-inst7 /abuild/jh/trunk-install/bin/g++ -O2 t.C -flto -c jh@evans:/abuild/jh/trunk-3/build-inst7 /abuild/jh/trunk-install/bin/g++ -O2 t.o -flto --save-temps [Leaving LTRANS /tmp/ccy4OrZL.args] [Leaving LTRANS /tmp/ccFrEQBZ.ltrans.out] [Leaving LTRANS /tmp/ccMy8uNk.args] [Leaving LTRANS /tmp/ccFrEQBZ.ltrans0.o] jh@evans:/abuild/jh/trunk-3/build-inst7 more *ltrans*s .file ccFrEQBZ.ltrans0.o .section.text.startup,ax,@progbits .p2align 4,,15 .globl main .type main, @function main: .LFB0: .cfi_startproc xorl%eax, %eax ret .cfi_endproc .LFE0: .size main, .-main .ident GCC: (GNU) 4.8.0 20120324 (experimental) .section.note.GNU-stack,,@progbits So this is all about -O0? At -O0 I get: .local _ZZN1C1mEvE1d.local.1.2356 .comm _ZZN1C1mEvE1d.local.1.2356,8,8
[Bug target/51345] [avr] Devices with 8-bit SP need their own multilib(s)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51345 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | Target Milestone|4.7.0 |4.7.1 --- Comment #6 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-03-24 21:06:42 UTC --- Reopened: The current (4.7.0) behaviour is: -mtiny-stack acts as multilib-option for 16-bit SP targets in avr2 and avr25, i.e. with that switch will trigger multi-lib from ./tiny-stack resp. ./avr25/tiny-stack The problem is that the tiny-stack multilibs mix 16-bit SP targets that are treated as 8-bit SP, and targets with 8-bit SP. The currect implementation assumes SP.H = 0 in tiny-stack mlibs in order to properly initialize the frame pointer, e.g. in __prologue_saves. This is no good for 16-bit SP targets. Solution: Restore the behaviour for the 16-bit SP targets as was, i.e. -mtiny-stack does not affect multilib selection for these targets, but if specified on the command line, the resulting code will only change SP.L and assume SP.H never changes. For the 8-bit SP targets, -mtiny-stack should remain as in 4.7.0, i.e. used internally to trigger tiny-stack multilibs. Specifying -mtiny-stack on the command line will be redundant for these targets and have no effect.
[Bug lto/51663] LTO does not reclaim comdat-local statics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51663 --- Comment #5 from Jan Hubicka hubicka at gcc dot gnu.org 2012-03-24 21:07:34 UTC --- The resolution info seems to be right, unlike the aforementioned comment. d: availability:overwritable (asm: _ZZN1C1mEvE1d) needed analyzed finalized externally_visible prevailing_def_ironly The reason why it stays in the code is again the logic of promoting it to static var and consequentely not removing the variable at -O0. I wonder what policy we want here. I think some folks still rely on static vars not being removed at -O0. We probably could remove local statics of functions that has been removed, but that is an odd rule. Perhaps we may want to set flag forcing static vars in the code at -O0 instead of testing the flag late. (effectively making -O0 to drop implicit used flag on everything). This way the behaviour will be consistet over -fwhole-program and not.
[Bug middle-end/52704] thunk referenced in discarded section when combining -flto -ftree-vectorize -fipa-cp-clone on Debian/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52704 --- Comment #1 from Matt Hargett matt at use dot net 2012-03-24 21:12:21 UTC --- Created attachment 26975 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26975 save-temps output from /tmp and linking dir
[Bug c++/40752] -Wconversion generates false warnings for operands not larger than target type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40752 --- Comment #21 from David Stone DeusExSophismata at gmail dot com 2012-03-24 21:25:08 UTC --- Why was this patch rejected, and is there a way to improve it so that obviously safe cases (such as PR52703) are not warned about without having to specify a '-Wno-' option? Yes, according to the standard (C++03 5/9), calculations done on variables smaller than int are first promoted to int, then the calculation is done, then the value is converted back to the target size. However, C++03 1.8/3, the as-if rule, states that it the program can't tell the difference, you can do whatever you want (see my answer to a similar question on Stack Overflow here: http://stackoverflow.com/questions/5563000/implicit-type-conversion-rules-in-c-operators/8935697#8935697). The C++ standard does not require a diagnostic for this, and the apparent behavior is identical. Therefore, there can be no appeals to the C++ standard on the behavior of the warning. Because this is a purely option warning for which gcc defines the rules, we should define it to be useful. If gcc can prove that all of the values are greater than 0 (for instance, if all of the values are unsigned prior to implicit promotion or are positive integral constant expressions), then there is no possibility of having a negative value. Thanks to signed integer overflow being undefined, there is no risk of creating a negative value that way, either. Therefore, we should not warn. Having to manually say Turn off stuff that no one could ever possibly want to see seems like a sure way to make this warning useless.
[Bug lto/51663] LTO does not reclaim comdat-local statics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51663
--- Comment #6 from Jan Hubicka hubicka at gcc dot gnu.org 2012-03-24
21:39:16 UTC ---
OK,
this should regularize the situation somewhat. We handle the
-O0/-fno-toplevel-reorder semantics early at finalization time and thus we
don't care about effect of -fwhole-program and friends.
* varpool.c (varpool_finalize_decl): Handle toplevel_reorder here.
(decide_is_variable_needed): Do not handle toplevel reorder here.
* cgraph.h (varpool_can_remove_if_no_refs): Likewise.
Index: varpool.c
===
--- varpool.c (revision 183666)
+++ varpool.c (working copy)
@@ -334,10 +334,6 @@ decide_is_variable_needed (struct varpoo
!DECL_EXTERNAL (decl))
return true;
- /* When not reordering top level variables, we have to assume that
- we are going to keep everything. */
- if (!flag_toplevel_reorder)
-return true;
return false;
}
@@ -405,7 +401,11 @@ varpool_finalize_decl (tree decl)
if (node-needed)
varpool_enqueue_needed_node (node);
node-finalized = true;
- if (TREE_THIS_VOLATILE (decl) || DECL_PRESERVE_P (decl))
+ if (TREE_THIS_VOLATILE (decl) || DECL_PRESERVE_P (decl)
+ /* Traditionally we do not eliminate static variables when not
+optimizing and when not doing toplevel reoder. */
+ || (!flag_toplevel_reorder !DECL_COMDAT (node-decl)
+ !DECL_ARTIFICIAL (node-decl)))
node-force_output = true;
if (decide_is_variable_needed (node, decl))
Index: cgraph.h
===
--- cgraph.h(revision 183666)
+++ cgraph.h(working copy)
@@ -947,8 +947,6 @@ static inline bool
varpool_can_remove_if_no_refs (struct varpool_node *node)
{
return (!node-force_output !node-used_from_other_partition
- (flag_toplevel_reorder || DECL_COMDAT (node-decl)
- || DECL_ARTIFICIAL (node-decl))
(DECL_COMDAT (node-decl) || !node-externally_visible));
}
[Bug c/28744] externally_visible attribute not effective with prior declaration of symbol.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28744 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #17 from Jan Hubicka hubicka at gcc dot gnu.org 2012-03-24 22:07:55 UTC --- I believe this is fully solved now with late processing of externally_visible and removal of --combine
[Bug tree-optimization/47237] [4.5 Regression] builtin_apply_args broken WRT local ABI changes.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47237 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|NEW AssignedTo|hubicka at gcc dot gnu.org |unassigned at gcc dot ||gnu.org --- Comment #11 from Jan Hubicka hubicka at gcc dot gnu.org 2012-03-24 22:10:10 UTC --- I have no plans on backport at the moment.
[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 #8 from dave.anglin at bell dot net 2012-03-24 23:40:03 UTC --- On 21-Mar-12, at 11:04 AM, ro at CeBiTec dot Uni-Bielefeld.DE wrote: Ok, but at least struct sockaddr_in6 is present in/from netinet/ in.h, otherwise the HAVE_INET6 configure test would fail? HAVE_INET6 is undefined in include/config.h and classpath/include/ config.h. Dave -- John David Anglindave.ang...@bell.net
[Bug tree-optimization/50021] -Wsuggest-attribute=pure makes obviously-incorrect suggestion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50021 bruno at clisp dot org changed: What|Removed |Added CC||bruno at clisp dot org --- Comment #4 from bruno at clisp dot org 2012-03-25 01:06:41 UTC --- Apparently fixed in GCC 4.7.0.gcc -Wsuggest-attribute=pure -O2 -S v.i
[Bug c++/52688] static local variable can accessed from local class of function template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52688 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2012-03-25 02:56:09 UTC --- Sorry, I didn't read the report carefully enough and was too hasty closing it.
[Bug tree-optimization/52705] New: Loop optimization failure with -O2 versus -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52705
Bug #: 52705
Summary: Loop optimization failure with -O2 versus -O1
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: veio...@gmail.com
Created attachment 26976
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26976
Intermediate of bug.c
When I compile with these different optimization levels, I get different
output. This isn't confusion over floats or uninitialized variables, as far as
I can tell. It appears to relate to casted memory accesses.
First of all, this relates to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49938, which _might_ solve the
problem (but I don't know, because I'm unable to upgrade from 4.6.1 under
MinGW). So please try the latest GCC before you try to debug this.
Here's the command line:
gcc -save-temps -O2 -obug.exe bug.c
This bug is very easy to reproduce. Here's the entire source of bug.c:
#include stdint.h
#include stdio.h
void
func(uint32_t a[8],uint32_t b[8]){
uint32_t i;
uint32_t c;
int64_t d;
for(i=0;i=1;i++){
((uint64_t *)(b))[0]=((uint64_t *)(a))[0];
((uint64_t *)(b))[1]=((uint64_t *)(a))[0];
((uint64_t *)(b))[2]=((uint64_t *)(a))[0];
((uint64_t *)(b))[3]=((uint64_t *)(a))[0];
c=1;
d=b[0];
d-=c;
b[0]=d;
c=b[0];
d=b[1];
d-=c1;
b[1]=d;
}
return;
}
int
main(int argc, char *argv[]){
uint32_t a[8]={1,0,0,0,0,0,0,0};
uint32_t b[8];
func(a,b);
printf(%08X%08X%08X%08X%08X%08X%08X%08X\n,b[0],b[1],b[2],b[3],b[4],b[5],b[6],b[7]);
return 0;
}
As you will see, you get different outputs depending on whether you use -O1 or
-O2.
The relation to Bug 49930 is this:
Look at the above code. If you change:
d=b[1];
d-=c1;
b[1]=d;
to:
d=b[0];
d-=c1;
b[0]=d;
Then you will see bug 49930.
Note that b[] appears to be only half-initialized because I only write to
subscripts 0 through 3. But that's not the case, because I've casted 8 32-bit
integers to 4 64-bit integers.
I notice that when I change the lines involving (uint64_t *) casts to normal
(uint32_t *) memory accesses, i.e. when I get rid of the casts, it seems to
work better (but didn't investigate at length). But I don't want to do that for
performance reasons. (bug.c is just an adaptation that's filtered from a real
function where performance matters.)
[Bug tree-optimization/52705] Loop optimization failure with -O2 versus -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52705
--- Comment #1 from pinskia at gmail dot com pinskia at gmail dot com
2012-03-25 05:12:44 UTC ---
You are volating c/c++ aliasing rules. Use memcpy or -fno-strict-aliasing .
Sent from my Palm Pre on ATamp;T
On Mar 24, 2012 21:27, veiokej at gmail dot com
lt;gcc-bugzi...@gcc.gnu.orggt; wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52705
Bug #: 52705
Summary: Loop optimization failure with -O2 versus -O1
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: veio...@gmail.com
Created attachment 26976
--gt; http://gcc.gnu.org/bugzilla/attachment.cgi?id=26976
Intermediate of bug.c
When I compile with these different optimization levels, I get different
output. This isn't confusion over floats or uninitialized variables, as far as
I can tell. It appears to relate to casted memory accesses.
First of all, this relates to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49938, which _might_ solve the
problem (but I don't know, because I'm unable to upgrade from 4.6.1 under
MinGW). So please try the latest GCC before you try to debug this.
Here's the command line:
gcc -save-temps -O2 -obug.exe bug.c
This bug is very easy to reproduce. Here's the entire source of bug.c:
#include lt;stdint.hgt;
#include lt;stdio.hgt;
void
func(uint32_t a[8],uint32_t b[8]){
uint32_t i;
uint32_t c;
int64_t d;
for(i=0;ilt;=1;i++){
((uint64_t *)(b))[0]=((uint64_t *)(a))[0];
((uint64_t *)(b))[1]=((uint64_t *)(a))[0];
((uint64_t *)(b))[2]=((uint64_t *)(a))[0];
((uint64_t *)(b))[3]=((uint64_t *)(a))[0];
c=1;
d=b[0];
d-=c;
b[0]=d;
c=b[0];
d=b[1];
d-=clt;lt;1;
b[1]=d;
}
return;
}
int
main(int argc, char *argv[]){
uint32_t a[8]={1,0,0,0,0,0,0,0};
uint32_t b[8];
func(a,b);
printf(%08X%08X%08X%08X%08X%08X%08X%08X\n,b[0],b[1],b[2],b[3],b[4],b[5],b[6],b[7]);
return 0;
}
As you will see, you get different outputs depending on whether you use -O1 or
-O2.
The relation to Bug 49930 is this:
Look at the above code. If you change:
d=b[1];
d-=clt;lt;1;
b[1]=d;
to:
d=b[0];
d-=clt;lt;1;
b[0]=d;
Then you will see bug 49930.
Note that b[] appears to be only half-initialized because I only write to
subscripts 0 through 3. But that's not the case, because I've casted 8 32-bit
integers to 4 64-bit integers.
I notice that when I change the lines involving (uint64_t *) casts to normal
(uint32_t *) memory accesses, i.e. when I get rid of the casts, it seems to
work better (but didn't investigate at length). But I don't want to do that for
performance reasons. (bug.c is just an adaptation that's filtered from a real
function where performance matters.)
[Bug c++/41933] [c++0x] lambdas and variadic templates don't work together
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41933 --- Comment #7 from Jeremy W jeremy at quiescent dot us 2012-03-25 05:48:29 UTC --- Created attachment 26978 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26978 delegate implementation not using a lambda. This does compile.
[Bug c++/41933] [c++0x] lambdas and variadic templates don't work together
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41933 --- Comment #6 from Jeremy W jeremy at quiescent dot us 2012-03-25 05:47:37 UTC --- Created attachment 26977 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26977 delegate implementation using a lambda. This doesn't compile.
