[Bug tree-optimization/55022] [4.8 Regression] air.f90 is miscompliled with -m64 -O2 -fgraphite-identity after revision 190619
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55022 --- Comment #4 from Dominique d'Humieres 2013-01-04 07:29:09 UTC --- > Does this work now? Nope! -(r194872).
[Bug rtl-optimization/55845] 454.calculix miscompares with -march=btver2 -O3 -ffastmath -fschedule-insns -mvzeroupper for test data run
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55845
--- Comment #3 from Vladimir Yakovlev 2013-01-04
06:40:44 UTC ---
The test fails corei7-avx also. I build a simple reproducer.
-
#include
#define N 100
double
foo (
int size,
double y[],
double x[]
)
{
double sum = 0.0 ;
int i ;
for (i = 0, sum = 0. ; i < size ; i++)
sum += y[i] * x[i] ;
return(sum);
}
int main ()
{
double x[N];
double y[N];
double s;
int i;
for (i = 0; i < N; i++)
{
x[i] = i;
y[i] = i;
}
s = foo (N, y, x);
printf("%s\n", s == 328350 ? "pass" : "fail");
}
--
$ gcc -mavx -g -static -o t -O3 -ffast-math -march=corei7 t.c -fno-inline &&
./t
pass
$ gcc -fschedule-insns -mavx -g -static -o t -O3 -ffast-math -march=corei7
t.c -fno-inline && ./t
fail
Responsible phase is jump2. To switch off the phase I did changes
diff --git a/gcc/cfgcleanup.c b/gcc/cfgcleanup.c
index 5d142e9..be04c5d 100644
--- a/gcc/cfgcleanup.c
+++ b/gcc/cfgcleanup.c
@@ -3070,6 +3070,7 @@ struct rtl_opt_pass pass_jump =
static unsigned int
execute_jump2 (void)
{
+ if (!getenv("NOJMP2"))
cleanup_cfg (flag_crossjumping ? CLEANUP_CROSSJUMP : 0);
return 0;
}
env NOJMP2=1 gcc -fschedule-insns -mavx -g -static -o t -O3 -ffast-math
-march=corei7 t.c -fno-inline && ./t
pass
I used compiler
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure CFLAGS='-O0 -g3' CXXFLAGS='-O0 -g3'
--prefix=/gnumnt/msticlxl16_users/vbyakovl/workspaces/gcc/install
--enable-clocale=gnu --disable-bootstrap --with-system-zlib --enable-shared
--with-demangler-in-ld --with-fpmath=sse --with-arch=corei7-avx
--with-cpu=corei7-avx --enable-languages=c,c++,fortran,java,lto,objc
--no-create --no-recursion
[Bug target/53789] ICE in gen_reg_rtx, at emit-rtl.c:864/865 when compiling GNU MPFR on parisc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53789 --- Comment #16 from John David Anglin 2013-01-04 04:03:30 UTC --- Author: danglin Date: Fri Jan 4 04:03:18 2013 New Revision: 194880 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194880 Log: PR target/53789 * config/pa/pa.md (movsi): Revert previous change. * config/pa/pa.c (pa_legitimate_constant_p): Reject all TLS symbol references. Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/config/pa/pa.c branches/gcc-4_7-branch/gcc/config/pa/pa.md
[Bug target/53789] ICE in gen_reg_rtx, at emit-rtl.c:864/865 when compiling GNU MPFR on parisc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53789 --- Comment #15 from John David Anglin 2013-01-04 03:55:47 UTC --- Author: danglin Date: Fri Jan 4 03:55:43 2013 New Revision: 194879 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194879 Log: PR target/53789 * config/pa/pa.md (movsi): Revert previous change. * pa.c (pa_legitimate_constant_p): Reject all TLS symbol references. Modified: trunk/gcc/ChangeLog trunk/gcc/config/pa/pa.c trunk/gcc/config/pa/pa.md
[Bug rtl-optimization/55829] [4.8 Regression] ICE: in curr_insn_transform, at lra-constraints.c:3069 with -msse3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55829
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2013-01-04
Ever Confirmed|0 |1
--- Comment #1 from Andrew Pinski 2013-01-04
03:38:40 UTC ---
Confirmed here is a more reduced testcase:
extern double p2[];
extern double ck[];
int chk_pd(void);
int sse3_test (void)
{
int i = 0;
int fail = 0;
__m128d t1 = (__m128d){*p2, 0};
__m128d t2 = __builtin_ia32_shufpd (t1, t1, 0);
double p10 = p2[0];
for (; i < 80; i += 1)
{
ck[0] = p10;
__builtin_ia32_storeupd (p2, t2);
fail += chk_pd ();
}
}
--- CUT ---
Note the first difference with -fno-expensive-optimizations is the ira dump.
Also note if we change t1/t2 into:
__m128d t2 = (__m128d){*p2, *p2};
It works. The difference between those two are:
(insn 17 13 7 2 (set (reg/v:V2DF 65 [ t2 ])
(vec_concat:V2DF (reg:DF 80 [ D.1764 ])
(reg:DF 80 [ D.1764 ]))) t6.c:11 1467 {*vec_concatv2df}
(nil))
(insn 10 9 5 2 (set (reg/v:V2DF 63 [ t2 ])
(vec_duplicate:V2DF (reg:DF 62 [ D.1756 ]))) t6.c:9 1466 {vec_dupv2df}
(nil))
Note both of those two RTL are the exactly the same, maybe we should convert
the vec_concat of the same value into vec_duplicate but that is a different
issue all together and would make this ICE latent.
[Bug tree-optimization/55022] [4.8 Regression] air.f90 is miscompliled with -m64 -O2 -fgraphite-identity after revision 190619
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55022 Andrew Pinski changed: What|Removed |Added Target||x86_64-*-* --- Comment #3 from Andrew Pinski 2013-01-04 03:10:36 UTC --- Does this work now?
[Bug target/52555] [4.6/4.7/4.8 Regression] ICE unrecognizable insn with -ffast-math and __attribute__((optimize(xx)))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52555 Andrew Pinski changed: What|Removed |Added Target||i?86-*-* x86_64-linux-gnu Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-04 Ever Confirmed|0 |1 --- Comment #6 from Andrew Pinski 2013-01-04 03:09:43 UTC --- Confirmed.
[Bug fortran/55117] Programs fails to read namelist (contains derived types objects)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55117 Walter Spector changed: What|Removed |Added CC||w6ws at earthlink dot net --- Comment #5 from Walter Spector 2013-01-04 02:54:05 UTC --- Adding myself to the CC list. Walter Spector
[Bug middle-end/55859] Mention -Og/-Ofast in "error: argument to '-O' should be a non-negative integer"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55859 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED CC||mpolacek at gcc dot gnu.org AssignedTo|unassigned at gcc dot |mpolacek at gcc dot gnu.org |gnu.org | --- Comment #2 from Marek Polacek 2013-01-04 01:43:08 UTC --- I have a patch.
[Bug fortran/55763] Issues with some simpler CLASS(*) programs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55763
--- Comment #16 from Tobias Burnus 2013-01-03
23:51:11 UTC ---
(In reply to comment #12)
The patch has been submitted:
http://gcc.gnu.org/ml/fortran/2013-01/msg00017.html
(In reply to comment #13)
> C512 (R506) The function-reference shall be a reference to the intrinsic
> function NULL with no arguments.
The patch has been submitted:
http://gcc.gnu.org/ml/fortran/2013-01/msg00020.html
> The following valid code gives an ICE:
> class(*), pointer :: ptr2 => x
Patch for the checking part below. TODO: Fixing the ICE for both CLASS(t) and
CLASS(*).
--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -3765 +3765,4 @@ gfc_check_assign_symbol (gfc_symbol *sym,
- if (sym->attr.pointer && rvalue->expr_type != EXPR_NULL)
+ if ((sym->attr.pointer
+ || (sym->ts.type == BT_CLASS && CLASS_DATA (sym)
+ && CLASS_DATA (sym)->attr.class_pointer))
+ && rvalue->expr_type != EXPR_NULL)
@@ -3772,2 +3775,2 @@ gfc_check_assign_symbol (gfc_symbol *sym, gfc_expr
- gfc_error ("Pointer initialization target at %C "
-"must not be ALLOCATABLE ");
+ gfc_error ("Pointer initialization target at %L "
+"must not be ALLOCATABLE", &rvalue->where);
@@ -3778,2 +3781,2 @@ gfc_check_assign_symbol (gfc_symbol *sym, gfc_expr
- gfc_error ("Pointer initialization target at %C "
-"must have the TARGET attribute");
+ gfc_error ("Pointer initialization target at %L "
+"must have the TARGET attribute", &rvalue->where);
@@ -3781,0 +3785,9 @@ gfc_check_assign_symbol (gfc_symbol *sym, gfc_expr
+
+ if (!attr.save && rvalue->expr_type == EXPR_VARIABLE
+ && rvalue->symtree->n.sym->ns->proc_name
+ && rvalue->symtree->n.sym->ns->proc_name->attr.is_main_program)
+ {
+ rvalue->symtree->n.sym->ns->proc_name->attr.save = SAVE_IMPLICIT;
+ attr.save = SAVE_IMPLICIT;
+ }
+
@@ -3784,2 +3796,2 @@ gfc_check_assign_symbol (gfc_symbol *sym, gfc_expr
- gfc_error ("Pointer initialization target at %C "
-"must have the SAVE attribute");
+ gfc_error ("Pointer initialization target at %L "
+"must have the SAVE attribute", &rvalue->where);
[Bug testsuite/55780] effective targets arm_arch_v*_multilib are not strict enough
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55780 --- Comment #2 from Janis Johnson 2013-01-03 22:52:03 UTC --- Here's the configuration for the FSF mainline compiler I'm using: Target: arm-none-eabi Configured with: /scratch/janisjo/build6/fsf-arm-eabi/src/gcc-mainline/configure --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=arm-none-eabi --enable-threads --disable-libmudflap --disable-libssp --disable-libstdcxx-pch --with-gnu-as --with-gnu-ld --enable-languages=c,c++ --disable-shared --enable-lto --with-newlib --disable-nls --prefix=/opt/codesourcery --with-headers=yes --with-sysroot=/opt/codesourcery/arm-none-eabi --with-build-sysroot=/scratch/janisjo/build6/fsf-arm-eabi/install/arm-none-eabi --disable-libgomp --disable-libitm Thread model: single gcc version 4.8.0 20130103 (experimental) (GCC) For this compiler, none of the links fail for the arm_arch_v*_multilib checks. Some of those checks fail at runtime, causing ftest-*.c tests to be UNSUPPORTED. In more cases, the simulator passes when running the arm_arch_v*_multilib check and then fails when running the test, causing it to FAIL instead of being UNSUPPORTED. It should be easy enough to add a check_link procedure, similar to check_compile or check_runtime, but from I've seen that would pass with all of these checks for my configuration. I suspect that a more robust link check would need target-specific code requiring calls to target-specific runtime libraries. A separate issue is that these checks are being used to determine whether or not to skip "dg-do run" tests, and that those tests can be rewritten to check the tested functionality at compile-time instead of run time; see <http://gcc.gnu.org/ml/gcc-patches/2012-12/msg01339.html>.
[Bug target/52061] compiler internal error in extract_insn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52061 --- Comment #2 from Jean-Pierre Flori 2013-01-03 22:50:50 UTC --- This is fixed with FSF GCC 4.7.2.
[Bug c++/55870] New: Compiler crash when template includes sizeof of something that shouldn't be dereferenced
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55870 Bug #: 55870 Summary: Compiler crash when template includes sizeof of something that shouldn't be dereferenced Classification: Unclassified Product: gcc Version: 4.3.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: dspe...@gmail.com Created attachment 29079 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29079 Preprocessed Source Code The compiler said "internal compiler error: Segmentation fault. Please submit a full bug report" so I am. I realize there are few safe things to do with a dereferenced null pointer, but usually sizeof is one of them. Source code is attached. I think the critical line is: template static void* val(silliness(NULL)->s1)>*) which was supposed to specialize if and only if b::s1 existed. As you may have guessed, this was an attempt to figure out why saner sfinae mechanisms weren't working. Here's the compiler output: g++ -v --save-temps -o sfinae sfinae.cc Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.3.3-5ubuntu4' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-targets=all --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'sfinae' '-shared-libgcc' '-mtune=generic' /usr/lib/gcc/i486-linux-gnu/4.3.3/cc1plus -E -quiet -v -D_GNU_SOURCE sfinae.cc -D_FORTIFY_SOURCE=2 -mtune=generic -fpch-preprocess -o sfinae.ii ignoring nonexistent directory "/usr/local/include/i486-linux-gnu" ignoring nonexistent directory "/usr/lib/gcc/i486-linux-gnu/4.3.3/../../../../i486-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /usr/include/c++/4.3 /usr/include/c++/4.3/i486-linux-gnu /usr/include/c++/4.3/backward /usr/local/include /usr/lib/gcc/i486-linux-gnu/4.3.3/include /usr/lib/gcc/i486-linux-gnu/4.3.3/include-fixed /usr/include/i486-linux-gnu /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'sfinae' '-shared-libgcc' '-mtune=generic' /usr/lib/gcc/i486-linux-gnu/4.3.3/cc1plus -fpreprocessed sfinae.ii -quiet -dumpbase sfinae.cc -mtune=generic -auxbase sfinae -version -fstack-protector -o sfinae.s GNU C++ (Ubuntu 4.3.3-5ubuntu4) version 4.3.3 (i486-linux-gnu) compiled by GNU C version 4.3.3, GMP version 4.2.4, MPFR version 2.4.0. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: e2b5a0303075a65d33d75f9466062812 sfinae.cc:28: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions.
[Bug c++/55842] [4.7/4.8 Regression] C++11 ICE with boost multi-precision and boost variant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55842 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #7 from Jason Merrill 2013-01-03 20:43:06 UTC --- Fixed.
[Bug c++/55753] [C++11][4.7/4.8 Regression] ICE constexpr ctor, tsubst_copy_and_build, at cp/pt.c:14336
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55753 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | --- Comment #7 from Jason Merrill 2013-01-03 20:43:03 UTC --- Fixed.
[Bug c++/55753] [C++11][4.7/4.8 Regression] ICE constexpr ctor, tsubst_copy_and_build, at cp/pt.c:14336
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55753 --- Comment #6 from Jason Merrill 2013-01-03 20:37:49 UTC --- Author: jason Date: Thu Jan 3 20:37:28 2013 New Revision: 194872 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194872 Log: PR c++/55419 PR c++/55753 * pt.c (tsubst_copy_and_build) [TARGET_EXPR]: Don't touch TREE_CONSTANT. Added: branches/gcc-4_7-branch/gcc/testsuite/g++.dg/cpp0x/constexpr-ctor12.C Modified: branches/gcc-4_7-branch/gcc/cp/ChangeLog branches/gcc-4_7-branch/gcc/cp/pt.c
[Bug c++/55419] [4.7/4.8 Regression] ICE in gimplify_init_ctor_preeval, at gimplify.c:3587
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55419 --- Comment #8 from Jason Merrill 2013-01-03 20:37:50 UTC --- Author: jason Date: Thu Jan 3 20:37:28 2013 New Revision: 194872 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194872 Log: PR c++/55419 PR c++/55753 * pt.c (tsubst_copy_and_build) [TARGET_EXPR]: Don't touch TREE_CONSTANT. Added: branches/gcc-4_7-branch/gcc/testsuite/g++.dg/cpp0x/constexpr-ctor12.C Modified: branches/gcc-4_7-branch/gcc/cp/ChangeLog branches/gcc-4_7-branch/gcc/cp/pt.c
[Bug c++/55842] [4.7/4.8 Regression] C++11 ICE with boost multi-precision and boost variant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55842 --- Comment #6 from Jason Merrill 2013-01-03 20:37:31 UTC --- Author: jason Date: Thu Jan 3 20:37:10 2013 New Revision: 194871 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194871 Log: PR c++/55842 * semantics.c (trait_expr_value): Call maybe_instantiate_noexcept. Added: branches/gcc-4_7-branch/gcc/testsuite/g++.dg/ext/has_nothrow_constructor-2.C Modified: branches/gcc-4_7-branch/gcc/cp/ChangeLog branches/gcc-4_7-branch/gcc/cp/semantics.c
[Bug c++/55753] [C++11][4.7/4.8 Regression] ICE constexpr ctor, tsubst_copy_and_build, at cp/pt.c:14336
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55753 --- Comment #5 from Jason Merrill 2013-01-03 20:37:08 UTC --- Author: jason Date: Thu Jan 3 20:36:49 2013 New Revision: 194870 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194870 Log: PR c++/55419 PR c++/55753 * pt.c (tsubst_copy_and_build) [TARGET_EXPR]: Don't touch TREE_CONSTANT. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-ctor12.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug c++/55419] [4.7/4.8 Regression] ICE in gimplify_init_ctor_preeval, at gimplify.c:3587
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55419 --- Comment #7 from Jason Merrill 2013-01-03 20:37:04 UTC --- Author: jason Date: Thu Jan 3 20:36:49 2013 New Revision: 194870 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194870 Log: PR c++/55419 PR c++/55753 * pt.c (tsubst_copy_and_build) [TARGET_EXPR]: Don't touch TREE_CONSTANT. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-ctor12.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug c++/55842] [4.7/4.8 Regression] C++11 ICE with boost multi-precision and boost variant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55842 --- Comment #5 from Jason Merrill 2013-01-03 20:36:32 UTC --- Author: jason Date: Thu Jan 3 20:36:14 2013 New Revision: 194869 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194869 Log: PR c++/55842 * semantics.c (trait_expr_value): Call maybe_instantiate_noexcept. Added: trunk/gcc/testsuite/g++.dg/ext/has_nothrow_constructor-2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c
[Bug tree-optimization/55869] different bit shift/or optimization.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55869 --- Comment #1 from Andrew Pinski 2013-01-03 20:25:27 UTC --- The question I think comes down to this is shifting faster than testb/cmove ?
[Bug fortran/55855] [OOP] incorrect warning with procedure pointer component on pointer-valued base object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55855 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #7 from janus at gcc dot gnu.org 2013-01-03 20:17:59 UTC --- (In reply to comment #5) > (In reply to comment #3) > > In any case, the patch (I just had tested an identical patch) fixes the > > issue > > and also works with pointer-returning functions and TBP. > > If you have more complete testcases, they are pre-approved to go together with > Janus' patch. I guess the one test case we have should be enough (the patch should fix all variants). r194857 fixes the bug on 4.8 trunk. Closing. Thanks to Andrew for the report!
[Bug bootstrap/50177] libcpp reallocator a C or C++ function?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50177 Marc Glisse changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||glisse at gcc dot gnu.org Resolution||FIXED --- Comment #2 from Marc Glisse 2013-01-03 20:13:50 UTC --- Closing. It isn't properly fixed, just hacked around, but if we ever cleanup extern "C" versus extern "C++" function types in GCC, this will just be a small part of it.
[Bug tree-optimization/55869] New: different bit shift/or optimization.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55869
Bug #: 55869
Summary: different bit shift/or optimization.
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pl...@agmk.net
here're equvialent functions:
$ cat u.cpp
unsigned long long convert_1( bool flag )
{
return (unsigned long long)(flag ? 1ull : 0ull) << 57;
}
unsigned long long convert_2( bool flag )
{
return (unsigned long long)flag << 57;
}
current 4.7/4.8 gcc emits following different machine code:
_Z9convert_1b:
testb %dil, %dil # 29*cmpqi_ccno_1/1 [length = 3]
movl$0, %edx# 32*movdi_internal_rex64/1 [length = 5]
movabsq $144115188075855872, %rax # 28*movdi_internal_rex64/3
[length = 10]
cmove %rdx, %rax # 31*movdicc_noc/1 [length = 4]
ret # 39simple_return_internal [length = 1]
_Z9convert_2b:
movq%rdi, %rax # 19*movdi_internal_rex64/2 [length = 3]
salq$57, %rax # 8 *ashldi3_1/1[length = 4]
ret # 27simple_return_internal [length = 1]
while clang/llvm emits equivalent machine code for both functions:
_Z9convert_1b: # @_Z9convert_1b
movzbl %dil, %eax
shlq$57, %rax
ret
_Z9convert_2b: # @_Z9convert_2b
movzbl %dil, %eax
shlq$57, %rax
ret
[Bug bootstrap/50167] gmp memory functions are extern "C" (graphite)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50167 Marc Glisse changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Marc Glisse 2013-01-03 20:11:00 UTC --- .
[Bug bootstrap/50167] gmp memory functions are extern "C" (graphite)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50167 --- Comment #3 from Marc Glisse 2013-01-03 20:06:56 UTC --- Author: glisse Date: Thu Jan 3 20:06:49 2013 New Revision: 194868 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194868 Log: 2013-01-03 Marc Glisse PR bootstrap/50167 gcc/ * graphite-interchange.c (pdr_stride_in_loop): Use gmp_fprintf. * graphite-poly.c (debug_gmp_value): Likewise. PR bootstrap/50177 libcpp/ * line-map.c (get_combined_adhoc_loc): Cast from extern "C" type. (new_linemap): Likewise. (linemap_enter_macro): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/graphite-interchange.c trunk/gcc/graphite-poly.c trunk/libcpp/ChangeLog trunk/libcpp/line-map.c
[Bug bootstrap/50177] libcpp reallocator a C or C++ function?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50177 --- Comment #1 from Marc Glisse 2013-01-03 20:06:57 UTC --- Author: glisse Date: Thu Jan 3 20:06:49 2013 New Revision: 194868 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194868 Log: 2013-01-03 Marc Glisse PR bootstrap/50167 gcc/ * graphite-interchange.c (pdr_stride_in_loop): Use gmp_fprintf. * graphite-poly.c (debug_gmp_value): Likewise. PR bootstrap/50177 libcpp/ * line-map.c (get_combined_adhoc_loc): Cast from extern "C" type. (new_linemap): Likewise. (linemap_enter_macro): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/graphite-interchange.c trunk/gcc/graphite-poly.c trunk/libcpp/ChangeLog trunk/libcpp/line-map.c
[Bug c++/55842] [4.7/4.8 Regression] C++11 ICE with boost multi-precision and boost variant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55842 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org |
[Bug preprocessor/54694] internal compiler error: in dwarf2out_frame_debug_expr, at dwarf2out.c:2387
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54694 --- Comment #6 from Toralf Förster 2013-01-03 19:35:16 UTC --- As long as no fixed gcc version is released - in Gentoo land we do have this work around for now : https://bugs.gentoo.org/show_bug.cgi?id=434908#c11 (Workaround: Append -mno-avx to CFLAGS.)
[Bug debug/55059] [4.8 Regression] DWARF missing concrete class definition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55059 --- Comment #3 from Tom Tromey 2013-01-03 19:29:28 UTC --- (In reply to comment #2) > So, where do we stand with this? Can GDB be changed to cope with this, or do > you think it isn't valid DWARF? It seems strange at least. I don't have chapter and verse against it though. If we change gdb to cope with this, I think the effect will be to undo what the patches here were attempting to accomplish. That would be fine by me -- but in that case, why not just revert gcc to the status quo ante, preserving compatibility with existing versions of gdb?
[Bug fortran/55854] ICE on intent(out) dummy argument with unlimited polymorphic component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55854 --- Comment #6 from Damian Rouson 2013-01-03 19:12:09 UTC --- Awesome -- thanks! Please let me know once this hits the trunk so I can request an update of the macports build and try it out. Damian (In reply to comment #5) > (In reply to comment #4) > > Apparently an ICE also occurs if the argument intent is removed but "type" > > is > > replaced by "class." See below. Is this fixed by the patch in comment 3? > > Seems to be fixed by the patch, which has been submitted at > http://gcc.gnu.org/ml/fortran/2013-01/msg00017.html
[Bug libstdc++/55728] std::bad_function_call has misleading what() result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55728 Paolo Carlini changed: What|Removed |Added CC|paolo.carlini at oracle dot | |com, redi at gcc dot| |gnu.org | --- Comment #6 from Paolo Carlini 2013-01-03 19:04:23 UTC --- Ah, thanks!
[Bug bootstrap/55792] Bad memory access with profiledbootstrap and LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792 --- Comment #3 from H.J. Lu 2013-01-03 19:03:25 UTC --- I got ==23584== ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7f03d1089238 at pc 0xb9284a bp 0x7fffbd507b60 sp 0x7fffbd507b58 READ of size 1 at 0x7f03d1089238 thread T0 #0 0xb92849 (/export/build/gnu/gcc-lto-fdo-asan/build-x86_64-linux/prev-gcc/lto1+0xb92849) 0x7f03d1089238 is located 504 bytes inside of 4072-byte region [0x7f03d1089040,0x7f03d108a028) freed by thread T0 here: #0 0x3afde5e (/export/build/gnu/gcc-lto-fdo-asan/build-x86_64-linux/prev-gcc/lto1+0x3afde5e) #1 0x3aebcfc (/export/build/gnu/gcc-lto-fdo-asan/build-x86_64-linux/prev-gcc/lto1+0x3aebcfc) previously allocated by thread T0 here: #0 0x3afdfd4 (/export/build/gnu/gcc-lto-fdo-asan/build-x86_64-linux/prev-gcc/lto1+0x3afdfd4) #1 0x3af6b1e (/export/build/gnu/gcc-lto-fdo-asan/build-x86_64-linux/prev-gcc/lto1+0x3af6b1e) Shadow byte and word: 0x1fe07a211247: fa 0x1fe07a211240: fa fa fa fa fa fa fa fa More shadow bytes: 0x1fe07a211220: fa fa fa fa fa fa fa fa 0x1fe07a211228: fa fa fa fa fa fa fa fa 0x1fe07a211230: fa fa fa fa fa fa fa fa 0x1fe07a211238: fa fa fa fa fa fa fa fa =>0x1fe07a211240: fa fa fa fa fa fa fa fa 0x1fe07a211248: fa fa fa fa fa fa fa fa 0x1fe07a211250: fa fa fa fa fa fa fa fa 0x1fe07a211258: fa fa fa fa fa fa fa fa 0x1fe07a211260: fa fa fa fa fa fa fa fa [hjl@gnu-mic-2 prev-gcc]$ addr2line -e lto1 0xb92849 /export/gnu/import/git/gcc-misc/gcc/dwarf2out.c:22425 [hjl@gnu-mic-2 prev-gcc]$ addr2line -e lto1 0x3afde5e /export/gnu/import/git/gcc-misc/libsanitizer/asan/asan_malloc_linux.cc:60 [hjl@gnu-mic-2 prev-gcc]$ addr2line -e lto1 0x3aebcfc /export/gnu/import/git/gcc-misc/libiberty/hashtab.c:584 [hjl@gnu-mic-2 prev-gcc]$ addr2line -e lto1 0x3afdfd4 /export/gnu/import/git/gcc-misc/libsanitizer/asan/asan_malloc_linux.cc:86 [hjl@gnu-mic-2 prev-gcc]$ addr2line -e lto1 0x3af6b1e /export/gnu/import/git/gcc-misc/libiberty/xmalloc.c:162 [hjl@gnu-mic-2 prev-gcc]$
[Bug fortran/55854] ICE on intent(out) dummy argument with unlimited polymorphic component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55854 Tobias Burnus changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |burnus at gcc dot gnu.org |gnu.org | --- Comment #5 from Tobias Burnus 2013-01-03 18:55:16 UTC --- (In reply to comment #4) > Apparently an ICE also occurs if the argument intent is removed but "type" is > replaced by "class." See below. Is this fixed by the patch in comment 3? Seems to be fixed by the patch, which has been submitted at http://gcc.gnu.org/ml/fortran/2013-01/msg00017.html
[Bug libstdc++/55847] mistake bad_weak_ptr::what() message
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55847 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-01-03 AssignedTo|unassigned at gcc dot |redi at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.8.0 Ever Confirmed|0 |1
[Bug libstdc++/55728] std::bad_function_call has misleading what() result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55728 Jonathan Wakely changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |redi at gcc dot gnu.org |gnu.org | --- Comment #5 from Jonathan Wakely 2013-01-03 18:42:10 UTC --- Sure, I think I've already done the work in a git branch so I'll revisit it asap.
[Bug c++/55856] [4.7/4.8 Regression] ICE on tuple with rvalue ref member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55856 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Jason Merrill 2013-01-03 18:40:19 UTC --- Fixed.
[Bug c++/55856] [4.7/4.8 Regression] ICE on tuple with rvalue ref member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55856 --- Comment #4 from Jason Merrill 2013-01-03 18:34:55 UTC --- Author: jason Date: Thu Jan 3 18:34:48 2013 New Revision: 194866 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194866 Log: PR c++/55856 * g++.dg/init/array34.C: Check gimple dump, not assembler. Modified: trunk/gcc/testsuite/g++.dg/init/array34.C
[Bug c++/55856] [4.7/4.8 Regression] ICE on tuple with rvalue ref member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55856 --- Comment #3 from Jason Merrill 2013-01-03 18:31:29 UTC --- Author: jason Date: Thu Jan 3 18:31:23 2013 New Revision: 194865 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194865 Log: PR c++/55856 * semantics.c (build_data_member_initialization): Handle DECL_EXPR. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-ctor11.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c
[Bug c++/55856] [4.7/4.8 Regression] ICE on tuple with rvalue ref member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55856 --- Comment #2 from Jason Merrill 2013-01-03 18:31:07 UTC --- Author: jason Date: Thu Jan 3 18:30:58 2013 New Revision: 194864 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194864 Log: PR c++/55856 * semantics.c (build_data_member_initialization): Handle DECL_EXPR. Added: branches/gcc-4_7-branch/gcc/testsuite/g++.dg/cpp0x/constexpr-ctor11.C Modified: branches/gcc-4_7-branch/gcc/cp/ChangeLog branches/gcc-4_7-branch/gcc/cp/semantics.c
[Bug fortran/55854] ICE on intent(out) dummy argument with unlimited polymorphic component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55854 --- Comment #4 from Damian Rouson 2013-01-03 18:11:56 UTC --- Apparently an ICE also occurs if the argument intent is removed but "type" is replaced by "class." See below. Is this fixed by the patch in comment 3? Damian $ cat ice_on_class_dummy_with_unlimited.f90 implicit none type foo class(*), allocatable :: bar end type contains integer function foobar(this) class(foo) :: this end function end $ gfortran ice_on_class_dummy_with_unlimited.f90 ice_on_class_dummy_with_unlimited.f90: In function 'MAIN__': ice_on_class_dummy_with_unlimited.f90:8:0: internal compiler error: Segmentation fault: 11 end function ^ ice_on_class_dummy_with_unlimited.f90:8:0: internal compiler error: Abort trap: 6 gfortran: internal compiler error: Abort trap: 6 (program f951) Abort trap: 6 $ gfortran --version GNU Fortran (MacPorts gcc48 4.8-20121223_0) 4.8.0 20121223 (experimental)
[Bug fortran/55867] Segmentation fault on DEALLOCATION of type with ALLOCATABLE components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55867 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-01-03 CC||kargl at gcc dot gnu.org Known to work||4.7.2, 4.8.0 Ever Confirmed|0 |1 Known to fail||4.6.4 --- Comment #1 from kargl at gcc dot gnu.org 2013-01-03 17:43:44 UTC --- Can you upgrade to latest release on the 4.7 branch or the development branch for 4.8? valgrind shows that 4.6 has issues while the newer branches appear to be fine. The 4.7 and 4.8 branches give troutmask:sgk[221] gfc4x -o z foo.f90 && valgrind ./z ==25491== Memcheck, a memory error detector ==25491== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==25491== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==25491== Command: ./z ==25491== ## 1 ## ## 2 ## ## 3 ## ==25491== ==25491== HEAP SUMMARY: ==25491== in use at exit: 0 bytes in 0 blocks ==25491== total heap usage: 17 allocs, 17 frees, 3,607 bytes allocated ==25491== ==25491== All heap blocks were freed -- no leaks are possible ==25491== ==25491== For counts of detected and suppressed errors, rerun with: -v ==25491== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 5 from 1) while the 4.6 branch gives troutmask:sgk[222] gfc46 -o z foo.f90 && valgrind ./z ==25502== Memcheck, a memory error detector ==25502== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==25502== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==25502== Command: ./z ==25502== ## 1 ## ## 2 ## ==25502== Invalid read of size 8 ==25502==at 0x400D66: MAIN__ (in /usr/home/sgk/tmp/z) ==25502==by 0x4010BA: main (in /usr/home/sgk/tmp/z) ==25502== Address 0x1efd340 is 0 bytes after a block of size 80 alloc'd ==25502==at 0x100539B: malloc (in /usr/local/lib/valgrind/vgpreload_memcheck-amd64-freebsd.so) ==25502==by 0x400BCE: MAIN__ (in /usr/home/sgk/tmp/z) ==25502==by 0x4010BA: main (in /usr/home/sgk/tmp/z) ==25502== ==25502== Invalid write of size 8 ==25502==at 0x400D91: MAIN__ (in /usr/home/sgk/tmp/z) ==25502==by 0x4010BA: main (in /usr/home/sgk/tmp/z) ==25502== Address 0x1efd340 is 0 bytes after a block of size 80 alloc'd ==25502==at 0x100539B: malloc (in /usr/local/lib/valgrind/vgpreload_memcheck-amd64-freebsd.so) ==25502==by 0x400BCE: MAIN__ (in /usr/home/sgk/tmp/z) ==25502==by 0x4010BA: main (in /usr/home/sgk/tmp/z) ==25502== ==25502== Invalid read of size 8 ==25502==at 0x400D7A: MAIN__ (in /usr/home/sgk/tmp/z) ==25502==by 0x4010BA: main (in /usr/home/sgk/tmp/z) ==25502== Address 0x1efd358 is not stack'd, malloc'd or (recently) free'd ==25502== ==25502== Invalid free() / delete / delete[] / realloc() ==25502==at 0x100516E: free (in /usr/local/lib/valgrind/vgpreload_memcheck-amd64-freebsd.so) ==25502==by 0x400D85: MAIN__ (in /usr/home/sgk/tmp/z) ==25502==by 0x4010BA: main (in /usr/home/sgk/tmp/z) ==25502== Address 0x90 is not stack'd, malloc'd or (recently) free'd ==25502== ## 3 ## ==25502== ==25502== HEAP SUMMARY: ==25502== in use at exit: 0 bytes in 0 blocks ==25502== total heap usage: 17 allocs, 20 frees, 3,751 bytes allocated ==25502== ==25502== All heap blocks were freed -- no leaks are possible ==25502== ==25502== For counts of detected and suppressed errors, rerun with: -v ==25502== ERROR SUMMARY: 18 errors from 4 contexts (suppressed: 5 from 1) It is likely that this will not be fixed as there are too few developers and too many issues on the newer branches.
[Bug fortran/55868] New: gfortran generates for CLASS(*) __m_MOD___vtab__$tar on NO_DOLLAR_IN_LABEL systems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55868 Bug #: 55868 Summary: gfortran generates for CLASS(*) __m_MOD___vtab__$tar on NO_DOLLAR_IN_LABEL systems Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org CC: pa...@gcc.gnu.org The program below yields the following symbols, the first one is invalid if NO_DOLLAR_IN_LABEL is defined for the target R __m_MOD___vtab__$tar D __m_MOD_x module m class(*), pointer :: x => null() end module m Consider using GFC_PREFIX instead or ensure otherwise that the symbol does not appear in the object file. (Names with $ are fine if they only appear as local variables.)
[Bug target/55712] cpuinfo.c doesn't compile for x86-64 with medium memory model
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55712 --- Comment #8 from uros at gcc dot gnu.org 2013-01-03 17:16:30 UTC --- Author: uros Date: Thu Jan 3 17:16:08 2013 New Revision: 194862 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194862 Log: PR target/55712 * config/i386/i386-c.c (ix86_target_macros_internal): Depending on selected code model, define __code_mode_small__, __code_model_medium__, __code_model_large__, __code_model_32__ or __code_model_kernel__. * config/i386/cpuid.h (__cpuid, __cpuid_count) [__i386__]: Prefix xchg temporary register with %k. Declare temporary register as early clobbered. [__x86_64__]: For medium and large code models, preserve %rbx register. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/cpuid.h trunk/gcc/config/i386/i386-c.c
[Bug libstdc++/55866] [4.8 Regression] #include in C++11 mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55866 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #3 from Jakub Jelinek 2013-01-03 17:10:07 UTC --- I have no problem with that, just noticed this during mass rebuild with gcc 4.8 and wanted to double check where the bug is.
[Bug fortran/55867] New: Segmentation fault on DEALLOCATION of type with ALLOCATABLE components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55867 Bug #: 55867 Summary: Segmentation fault on DEALLOCATION of type with ALLOCATABLE components Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: gilbert.sc...@easynet.co.uk $ uname -a Linux localhost.localdomain 3.1.0-7.fc16.i686.PAE #1 SMP Tue Nov 1 20:53:45 UTC 2011 i686 i686 i386 GNU/Linux $ gfortran --version GNU Fortran (GCC) 4.6.2 20111027 (Red Hat 4.6.2-1) $ cat testprog.f95 MODULE M IMPLICIT NONE TYPE T1 REAL (KIND=8), ALLOCATABLE :: A(:) REAL (KIND=8), ALLOCATABLE :: B(:) END TYPE T1 TYPE T2 TYPE(T1), ALLOCATABLE :: S1 END TYPE T2 TYPE T3 TYPE(T2), ALLOCATABLE :: S2(:) END TYPE T3 END MODULE M PROGRAM TEST USE M IMPLICIT NONE TYPE(T3) :: S3 WRITE (0,*) '## 1 ##' ALLOCATE ( S3%S2(10) ) WRITE (0,*) '## 2 ##' DEALLOCATE ( S3%S2 ) WRITE (0,*) '## 3 ##' END PROGRAM TEST $ gfortran -Wall testprog.f95 -o testprog $ ./testprog ## 1 ## ## 2 ## Segmentation fault (core dumped) ?? The WRITE statements show that the SIGSEGV occurs on the DEALLOCATE statement. Why? It seems to be something to do with the heirarchy of types with allocatable components. If this is made simpler, then the problem goes away !?!
[Bug libstdc++/55866] [4.8 Regression] #include in C++11 mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55866
--- Comment #2 from Jonathan Wakely 2013-01-03
17:01:12 UTC ---
The header even says so, and has done so for years:
/** @file backward/auto_ptr.h
* This is an internal header file, included by other library headers.
* Do not attempt to use it directly. @headername{memory}
*/
The change was an important one that allows us to use unique_ptr and shared_ptr
internally in the library (e.g. in ) without depending on the whole of
and without pulling in the deprecated auto_ptr definition, as
discussed in the thread beginning at
http://gcc.gnu.org/ml/libstdc++/2012-06/msg00078.html
I don't want to revert it, and it would contradict how the entire library is
structured to make pull in all its needed headers. If you
#include it works perfectly, anything else is unsupported.
[Bug c++/55856] [4.7/4.8 Regression] ICE on tuple with rvalue ref member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55856 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org |
[Bug libstdc++/55728] std::bad_function_call has misleading what() result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55728 --- Comment #4 from Paolo Carlini 2013-01-03 16:59:38 UTC --- Eh, eh, indeed. Are you willing to take care of it over the next couple of weeks? Otherwise let me know, I can, but not now, I'm trying to catch up about too many things at once.
[Bug libstdc++/55866] [4.8 Regression] #include in C++11 mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55866 --- Comment #1 from Jonathan Wakely 2013-01-03 16:55:04 UTC --- It's an error in the package and only worked "by accident" because $PREFIX/include/c++/4.x.y/backward is in the include path, to allow to be found. The only supported way to use std::auto_ptr is #include
[Bug lto/55466] [4.8 Regression] Revision 191466 destroyed DWARF debug info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55466 --- Comment #13 from hjl at gcc dot gnu.org 2013-01-03 16:54:07 UTC --- Author: hjl Date: Thu Jan 3 16:53:54 2013 New Revision: 194861 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194861 Log: Fix ChangeLog entry for PR lto/55466 Modified: trunk/gcc/ChangeLog-2012 trunk/gcc/lto/ChangeLog
[Bug fortran/55763] Issues with some simpler CLASS(*) programs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55763 --- Comment #15 from Tobias Burnus 2013-01-03 16:54:03 UTC --- (In reply to comment #14) > type(t), target :: x > class(*), pointer :: ptr2 => x TODO: Check whether that would be also valid if "x" is not SAVE (here it is as "x" is in the main program) and whether one should reject a pointer as data-target. (Cf. also PR51076, PR45290 and PR50410 comment 9.) (In reply to comment #14) > The following (currently used in gfortran.dg/unlimited_polymorphic_3.f03) is > invalid: > class(*), pointer :: ptr2 => null(x) Note that ptr => null(x) is valid. In any case same_type_as (ptr,x) will be .false. as "ptr" has the declared type (which doesn't exist) and "x" has a declared type. Presumably, even same_type_as(ptr,ptr) would be false?!?
[Bug c++/53650] [4.7 Regression] large array causes huge memory use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53650 Jason Merrill changed: What|Removed |Added Summary|[4.7/4.8 Regression] large |[4.7 Regression] large |array causes huge memory|array causes huge memory |use |use --- Comment #8 from Jason Merrill 2013-01-03 16:53:36 UTC --- Fixed for 4.8 so far. Waiting a bit before applying the fix to 4.7.
[Bug c++/53650] [4.7/4.8 Regression] large array causes huge memory use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53650 --- Comment #7 from Jason Merrill 2013-01-03 16:51:51 UTC --- Author: jason Date: Thu Jan 3 16:51:41 2013 New Revision: 194860 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194860 Log: PR c++/53650 * call.c (type_has_extended_temps): New. * cp-tree.h: Declare it. * decl.c (check_initializer): Use build_aggr_init for arrays if it is false. * init.c (build_vec_init): Avoid mixed signed/unsigned arithmetic. Added: trunk/gcc/testsuite/g++.dg/init/array34.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl.c trunk/gcc/cp/init.c
[Bug bootstrap/55707] [4.7 Regression] bootstrap fails in gcc/graphite-dependences.c error cast loses precision
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55707 Kai Tietz changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Kai Tietz 2013-01-03 16:50:37 UTC --- Fixed on 4.7.x branch. As this issue doesn't exist on trunk, I close this bug as fixed.
[Bug bootstrap/55707] [4.7 Regression] bootstrap fails in gcc/graphite-dependences.c error cast loses precision
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55707 --- Comment #4 from Kai Tietz 2013-01-03 16:47:48 UTC --- Author: ktietz Date: Thu Jan 3 16:47:37 2013 New Revision: 194859 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194859 Log: 2013-01-02 Rainer Emrich PR bootstrap/55707 * graphite-dependences.c (hash_poly_ddr_p): Cast from pointer via intptr_t. Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/graphite-dependences.c
[Bug lto/48065] LTO: assertion failed in optimize_inline_calls, at tree-inline.c:4246
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48065 --- Comment #7 from Richard Biener 2013-01-03 16:40:48 UTC --- We definitely should be able to make it work. We can simply inline abort () ;)
[Bug libstdc++/55866] New: [4.8 Regression] #include in C++11 mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55866 Bug #: 55866 Summary: [4.8 Regression] #include in C++11 mode Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: ja...@gcc.gnu.org echo '#include ' | g++ -std=gnu++0x -S -o /tmp/a.s -xc++ - worked in 4.7, but doesn't work any longer in 4.8. Apparently the snapper package does this in one of the translation units (no idea why). Is that an error in the package and it isn't supposed to include that header, or is that something to fix on the libstdc++ side? The problem started with http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190109 where auto_ptr.h relies on a couple of headers it doesn't include itself (so _Lock_policy, __shared_count etc. aren't defined).
[Bug lto/48065] LTO: assertion failed in optimize_inline_calls, at tree-inline.c:4246
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48065 --- Comment #6 from Jan Hubicka 2013-01-03 16:37:00 UTC --- Hmm, rejecting inlines late at ltrans stage really is problem as discussed earlier - we make assumptions on the optimizations of constant parameters and we won't export offline copy in partitioning so it may lead to undefined reference. How do you expect this to work? Where we do the refusal? I do not see any code there. I would really preffer inlining to work (and produce wrong code in undefined cases perhaps with warning) rather than giving up on the inline plan. If this is not possible to implement, we can materialize a clone with the expected constant propagated and redirect call there, but it is tricky to implement, too.
[Bug libstdc++/55728] std::bad_function_call has misleading what() result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55728 --- Comment #3 from Jonathan Wakely 2013-01-03 16:35:46 UTC --- Yes, I would have done it already but was taking a break from writing any code over xmas! This one needs a new export from the lib, but that's OK, I bumped the version to 6.0.18 recently anyway.
[Bug lto/48065] LTO: assertion failed in optimize_inline_calls, at tree-inline.c:4246
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48065 --- Comment #5 from Jan Hubicka 2013-01-03 16:33:29 UTC --- Hmm, rejecting inlines late at ltrans stage really is problem as discussed earlier - we make assumptions on the optimizations of constant parameters and we won't export offline function
[Bug inline-asm/55864] Optimization cause asm code to wrong behaviour
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55864
--- Comment #3 from beldmit at nm dot ru 2013-01-03 16:33:02 UTC ---
If this case is better to reproduce the problem or I completely do not
understand the asm usage?
The mmx registers and operations are used to speedup the 64-bit xor.
void _xor64_asm(const unsigned char * arg1, const unsigned char * arg2,
unsigned char* out)
{
__asm__(
"movq (%1), %%mm0;"
"movq (%2), %%mm1;"
"pxor %%mm0, %%mm1;"
"movl %0, %%ecx;"
"movq %%mm1, (%%ecx);"
"emms"
: "=ym"(out)
: "r"(arg1), "r"(arg2)
: "mm1", "mm2", "ecx");
}
[Bug middle-end/55851] [4.8 Regression] ICE in size_binop_loc, at fold-const.c:1385
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55851 --- Comment #9 from Richard Biener 2013-01-03 16:32:04 UTC --- Ehm. (In reply to comment #8) > Created attachment 29078 [details] > gcc48-pr55851.patch > > Untested patch (which I don't like very much, but we can't even use something > like get_initialized_tmp_var which would strip the cast as useless too). Ugh. Now that sizetypes are no longer "special" we can also decide to allow ENUMERAL_TYPE in size positions (and adjust int_binop_types_match_p). But I'm not sure if we really want non-literal-sizetype sizes in type trees (they will easily appear in the extra operands of ARRAY_REF and COMPONENT_REF though, so maybe it's really the right thing to do). Otherwise using a get_initialized_tmp_var-like mechanism should be ok as long as you explicitely create the temporary variable with sizetype (I don't see that it strips the cast before getting at the type to create the temporary?)
[Bug tree-optimization/55264] [4.6/4.7/4.8 Regression] ICE: in ipa_make_edge_direct_to_target, at ipa-prop.c:2141 with -O2 -fno-early-inlining -fno-weak
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55264 --- Comment #5 from Jan Hubicka 2013-01-03 16:29:49 UTC --- Martin, I guess this is "yours". I have no idea here ;)
[Bug libstdc++/55728] std::bad_function_call has misleading what() result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55728 Paolo Carlini changed: What|Removed |Added CC||paolo.carlini at oracle dot ||com, redi at gcc dot ||gnu.org --- Comment #2 from Paolo Carlini 2013-01-03 16:29:06 UTC --- Jon, these two issues seem both straightforward to fix, right?
[Bug tree-optimization/55823] [4.8 Regression] ice in inline_call, at ipa-inline-transform.c:270
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55823
--- Comment #7 from Jan Hubicka 2013-01-03
16:26:16 UTC ---
The following patch to devirtualize before updating jump functions solves the
testcase but I am not at all sure it is correct.
Index: ipa-prop.c
===
--- ipa-prop.c (revision 194770)
+++ ipa-prop.c (working copy)
@@ -2264,8 +2264,19 @@ update_indirect_edges_after_inlining (st
param_index = ici->param_index;
jfunc = ipa_get_ith_jump_func (top, param_index);
- if (jfunc->type == IPA_JF_PASS_THROUGH
- && ipa_get_jf_pass_through_operation (jfunc) == NOP_EXPR)
+
+ if (!flag_indirect_inlining)
+ ;
+ else if (ici->polymorphic)
+ new_direct_edge = try_make_edge_direct_virtual_call (ie, jfunc,
+new_root_info);
+ else
+ new_direct_edge = try_make_edge_direct_simple_call (ie, jfunc,
+ new_root_info);
+ if (new_direct_edge)
+ ;
+ else if (jfunc->type == IPA_JF_PASS_THROUGH
+ && ipa_get_jf_pass_through_operation (jfunc) == NOP_EXPR)
{
if (ici->agg_contents
&& !ipa_get_jf_pass_through_agg_preserved (jfunc))
@@ -2291,13 +2302,6 @@ update_indirect_edges_after_inlining (st
if (!flag_indirect_inlining)
continue;
- if (ici->polymorphic)
- new_direct_edge = try_make_edge_direct_virtual_call (ie, jfunc,
-new_root_info);
- else
- new_direct_edge = try_make_edge_direct_simple_call (ie, jfunc,
- new_root_info);
-
if (new_direct_edge)
{
new_direct_edge->indirect_inlining_edge = 1;
[Bug c++/55856] [4.7/4.8 Regression] ICE on tuple with rvalue ref member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55856 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-03 Summary|ICE on tuple with rvalue|[4.7/4.8 Regression] ICE on |ref member |tuple with rvalue ref ||member Ever Confirmed|0 |1 --- Comment #1 from Paolo Carlini 2013-01-03 16:26:05 UTC --- This is confirmed, and it seems a regression. But we badly need a reduced testcase not including anything, because since 4.6 likely some library details changed.
[Bug tree-optimization/55823] [4.8 Regression] ice in inline_call, at ipa-inline-transform.c:270
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55823
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #6 from Jan Hubicka 2013-01-03
16:22:43 UTC ---
Hi,
the problem is that at the time ipa_get_indirect_edge_target is called from
devirt_benefit on _ZN12wxBufferedDC10InitCommonEP8wxDCBase.constprop.1/33 being
inlined it is seeing following info:
(gdb) p debug_tree (binfo)
unit size
align 64 symtab 0 alias set 5 canonical type 0x76dca348
fields
ignored decl_6 BLK file /home/jan/t.C line 8 col 8 size
unit size
align 64 offset_align 128
offset
bit offset context
chain > context
full-name "struct wxWindowDC"
needs-constructor X() X(constX&) this=(X&) n_parents=1 use_template=0
interface-unknown
pointer_to_this reference_to_this
chain >
private tree_2>
(gdb) p debug_tree (otr_type)
constant 64>
unit size constant 8>
align 64 symtab 0 alias set 2 canonical type 0x76db9690
fields
sizes-gimplified public unsigned DI size unit size
align 64 symtab 0 alias set 3 canonical type 0x76db01f8>
unsigned virtual DI file /home/jan/t.C line 2 col 8 size unit size
align 64 offset_align 128
offset
bit offset context
chain
used nonlocal decl_4 VOID file /home/jan/t.C line 3 col 1
align 1 context result
>> context
full-name "struct wxDCBase"
needs-constructor X() X(constX&) this=(X&) n_parents=0 use_template=0
interface-unknown
pointer_to_this reference_to_this
chain >
(gdb) p anc_offset
$33 = 0
This leads to devirtualization. It is because the info is known from function
itself. As noted earlier ipa-cp missed it for no valid reasons.
Now we inline and go to:
0x00a9ce3b in update_indirect_edges_after_inlining (cs=0x76de62d8,
node=0x76dd3378, new_edges=0x7fffda20) at ../../gcc/ipa-prop.c:2284
0x00a9ce3b in update_indirect_edges_after_inlining (cs=0x76de62d8,
node=0x76dd3378, new_edges=0x7fffda20) at ../../gcc/ipa-prop.c:2284
2284 ici->offset += ipa_get_jf_ancestor_offset (jfunc);
(gdb) l
2279 && !ipa_get_jf_ancestor_agg_preserved (jfunc))
2280ici->param_index = -1;
2281 else
2282{
2283 ici->param_index = ipa_get_jf_ancestor_formal_id (jfunc);
2284 ici->offset += ipa_get_jf_ancestor_offset (jfunc);
2285}
2286}
at this time the jump functions are updated for inlining into
_ZN17wxBufferedPaintDCC2Ev.constprop.0.
This time we cast to ancestor (if I get everything right) and the offset is
updated to 64.
Now try_make_edge_direct_virtual_call is called and it sees ANCESTOR jfunc and
at
2211 binfo = get_binfo_at_offset (binfo, ie->indirect_info->offset,
2212 ie->indirect_info->otr_type);
it passes the same binfo
unit size
align 64 symtab 0 alias set 5 canonical type 0x76dca348
fields
ignored decl_6 BLK file /home/jan/t.C line 8 col 8 size
unit size
align 64 offset_align 128
offset
bit offset context
chain > context
full-name "struct wxWindowDC"
needs-constructor X() X(constX&) this=(X&) n_parents=1 use_template=0
interface-unknown
pointer_to_this reference_to_this
chain >
private tree_2>
but already combined offset 64. This leads to nothing.
How this is supposed to work?
It is using jump functions of the call site we are seeing.
I am confused. I do not see how devirtualization/indirect call code can work
after we update jump functions to new context. In partiuclar what happens when
the parameter is constant? It seems that the following code:
if (jfunc->type == IPA_JF_PASS_THROUGH
&& ipa_get_jf_pass_through_operation (jfunc) == NOP_EXPR)
{
if (ici->agg_contents
&& !ipa_get_jf_pass_through_agg_preserved (jfunc))
ici->param_index = -1;
else
ici->param_index = ipa_get_jf_pass_through_formal_id (jfunc);
}
else if (jfunc->type == IPA_JF_ANCESTOR)
{
if (ici->agg_contents
&& !ipa_get_jf_ancestor_agg_preserved (jfunc))
ici->param_index = -1;
else
{
ici->param_index = ipa_get_jf_ancestor_formal_id (jfunc);
ici->offset += ipa_get_jf_ancestor_offset (jfunc);
}
}
else
/* Either we can find a destin
[Bug middle-end/55348] Problem in tree-ssa-pre.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55348 Richard Biener changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME --- Comment #3 from Richard Biener 2013-01-03 16:21:52 UTC --- Works for me.
[Bug c++/53137] [4.7/4.8 Regression] g++ segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53137 Paolo Carlini changed: What|Removed |Added CC||kyle.t.konrad at gmail dot ||com --- Comment #20 from Paolo Carlini 2013-01-03 16:21:31 UTC --- *** Bug 55853 has been marked as a duplicate of this bug. ***
[Bug c++/55853] [C++11] ICE calling member function of templated class in lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55853 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||paolo.carlini at oracle dot ||com Resolution||DUPLICATE --- Comment #3 from Paolo Carlini 2013-01-03 16:21:31 UTC --- Dup. *** This bug has been marked as a duplicate of bug 53137 ***
[Bug tree-optimization/55862] [4.8 Regression] ICE in compute_antic, at tree-ssa-pre.c:2495
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55862 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-01-03 Known to work||4.7.3 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.8.0 Summary|ICE in compute_antic, at|[4.8 Regression] ICE in |tree-ssa-pre.c:2495 |compute_antic, at ||tree-ssa-pre.c:2495 Ever Confirmed|0 |1 --- Comment #1 from Richard Biener 2013-01-03 16:19:41 UTC --- Mine.
[Bug target/43961] [4.6/4.7/4.8 Regression] [ARM thumb] "branch out of range" with thumb1_output_casesi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43961 Joseph S. Myers changed: What|Removed |Added Summary|[ARM thumb] "branch out of |[4.6/4.7/4.8 Regression] |range" with |[ARM thumb] "branch out of |thumb1_output_casesi|range" with ||thumb1_output_casesi --- Comment #10 from Joseph S. Myers 2013-01-03 16:19:42 UTC --- If the patch works for mainline, please do send it to gcc-patches as usual.
[Bug tree-optimization/55860] Turn segmented iteration into nested loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55860 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-03 CC||law at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Richard Biener 2013-01-03 16:17:17 UTC --- Hmm, jump threading should notice this. But it is confused by loop header copying which made the header test 0 < n instead. There is also the complication that this threading would create a loop with multiple latches which isn't generally desirable even though we can disambiguate those into a loop nest. But it doesn't seem to register any of the jump threading opportunities in the first place (DOM, that is). Jeff - maybe something for you to look at.
[Bug fortran/55855] [OOP] incorrect warning with procedure pointer component on pointer-valued base object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55855 --- Comment #6 from janus at gcc dot gnu.org 2013-01-03 16:15:07 UTC --- Author: janus Date: Thu Jan 3 16:14:54 2013 New Revision: 194857 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194857 Log: 2013-01-03 Janus Weil PR fortran/55855 * expr.c (gfc_check_assign): Use 'gfc_expr_attr' to evaluate attributes of rvalue. Correct hyphenation in error message. 2013-01-03 Janus Weil PR fortran/55855 * gfortran.dg/assignment_1.f90: Modified. * gfortran.dg/assignment_4.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/assignment_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/assignment_1.f90
[Bug fortran/55855] [OOP] incorrect warning with procedure pointer component on pointer-valued base object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55855 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #5 from Mikael Morin 2013-01-03 16:10:57 UTC --- (In reply to comment #3) > In any case, the patch (I just had tested an identical patch) fixes the issue > and also works with pointer-returning functions and TBP. If you have more complete testcases, they are pre-approved to go together with Janus' patch.
[Bug tree-optimization/55865] [4.8 Regression] vect-outer-fir-big-array.c vectorizer failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55865 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Richard Biener 2013-01-03 16:09:35 UTC --- I have reverted the offending changes.
[Bug tree-optimization/55857] [4.8 Regression] ICE: verify_ssa failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55857 --- Comment #5 from Richard Biener 2013-01-03 15:57:25 UTC --- Author: rguenth Date: Thu Jan 3 15:57:15 2013 New Revision: 194856 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194856 Log: 2013-01-03 Richard Biener Revert 2013-01-03 Richard Biener PR tree-optimization/55857 * tree-vect-stmts.c (vectorizable_load): Do not setup re-alignment for invariant loads. 2013-01-02 Richard Biener * tree-vect-stmts.c (vectorizable_load): When vectorizing an invariant load do not generate a vector load from the scalar location. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vect-stmts.c
[Bug fortran/55763] Issues with some simpler CLASS(*) programs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55763 --- Comment #14 from Tobias Burnus 2013-01-03 15:44:24 UTC --- (In reply to comment #12) > + c->ts.type = ts->type = BT_VOID; Ups. The "ts->type =" has to be deleted to fix the failure of comment 13. * * * The following valid code gives an ICE: type t end type t type(t), target :: x class(*), pointer :: ptr2 => x if (same_type_as (ptr2, x) .neqv. .TRUE.) call abort() end * * * The following (currently used in gfortran.dg/unlimited_polymorphic_3.f03) is invalid: class(*), pointer :: ptr2 => null(x) C512 (R506) The function-reference shall be a reference to the intrinsic function NULL with no arguments.
[Bug tree-optimization/55865] [4.8 Regression] vect-outer-fir-big-array.c vectorizer failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55865 David Edelsohn changed: What|Removed |Added Target||powerpc*-*-* Status|UNCONFIRMED |NEW Keywords||ice-checking Last reconfirmed||2013-01-03 CC||rguenth at gcc dot gnu.org Ever Confirmed|0 |1 Target Milestone|--- |4.8.0
[Bug tree-optimization/55865] New: [4.8 Regression] vect-outer-fir-big-array.c vectorizer failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55865 Bug #: 55865 Summary: [4.8 Regression] vect-outer-fir-big-array.c vectorizer failure Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: d...@gcc.gnu.org After the recent vectorizer changes, vect-outer-fir-big-array.c now fails on PowerPC. /nasfarm/dje/src/src/gcc/testsuite/gcc.dg/vect/vect-outer-fir-big-array.c: In function 'foo': /nasfarm/dje/src/src/gcc/testsuite/gcc.dg/vect/vect-outer-fir-big-array.c:15:6: error: missing PHI def vect_var_.31_56 = PHI <(6), vect_var_.25_58(10)> /nasfarm/dje/src/src/gcc/testsuite/gcc.dg/vect/vect-outer-fir-big-array.c:15:6: internal compiler error: verify_gimple failed
[Bug fortran/55855] [OOP] incorrect warning with procedure pointer component on pointer-valued base object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55855
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org
|gnu.org |
--- Comment #4 from janus at gcc dot gnu.org 2013-01-03 15:33:38 UTC ---
(In reply to comment #3)
> (In reply to comment #1)
> > The following draft patch seems to be sufficient to fix it:
> > + && rvalue->expr_type == EXPR_FUNCTION
> > + && gfc_expr_attr (rvalue).pointer)
>
> The patch is OK (obvious) with a test case.
Thanks. I just checked that it is free of regressions, apart from a failure in
assignment_1.f90, due to the changed error message (which I modified for
orthographical reasons):
Index: gcc/testsuite/gfortran.dg/assignment_1.f90
===
--- gcc/testsuite/gfortran.dg/assignment_1.f90(revision 194763)
+++ gcc/testsuite/gfortran.dg/assignment_1.f90(working copy)
@@ -12,7 +12,7 @@ integer, target :: t, s
t = 1
p => s
! We didn't dereference the pointer in the following line.
-p = f() ! { dg-warning "POINTER valued function" "" }
+p = f() ! { dg-warning "POINTER-valued function" "" }
p = p+1
if (p.ne.2) call abort()
if (p.ne.s) call abort()
Will commit soon.
[Bug middle-end/55851] [4.8 Regression] ICE in size_binop_loc, at fold-const.c:1385
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55851 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #8 from Jakub Jelinek 2013-01-03 15:32:16 UTC --- Created attachment 29078 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29078 gcc48-pr55851.patch Untested patch (which I don't like very much, but we can't even use something like get_initialized_tmp_var which would strip the cast as useless too).
[Bug inline-asm/55864] Optimization cause asm code to wrong behaviour
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55864 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution||INVALID --- Comment #2 from Jakub Jelinek 2013-01-03 15:29:27 UTC --- The testcase is buggy. You aren't telling the compiler you are modifying the %mm0 and %mm1 registers (why you do anything with MMX at this point BTW? that is simply a very bad idea), and even if you did, you can't expect the registers to keep their values in between the different inline asm statements, you aren't using the required emms for MMX (and not telling the compiler that you are invalidating the whole i387 register state), and the operands of the second inline asm are completely bogus.
[Bug inline-asm/55864] Optimization cause asm code to wrong behaviour
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55864 --- Comment #1 from beldmit at nm dot ru 2013-01-03 15:10:07 UTC --- Created attachment 29077 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29077 The bug representation code
[Bug inline-asm/55864] New: Optimization cause asm code to wrong behaviour
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55864
Bug #: 55864
Summary: Optimization cause asm code to wrong behaviour
Classification: Unclassified
Product: gcc
Version: 4.4.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: beld...@nm.ru
The code behaves differently with -O1 and without optimization.
void _xor64_asm(const unsigned char * arg1, const unsigned char * arg2,
unsigned char* out)
{
__asm__(
"movq (%1), %%mm0;"
"movq (%2), %%mm1;"
"pxor %%mm0, %%mm1;"
: "=ym"(out)
: "r"(arg1), "r"(arg2)
: "memory");
__asm__(
"movl %0, %%ecx;"
"movq %%mm1, (%%ecx);"
: "=ym"(out)
:
: "memory"
);
}
beldmit@manul2$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.5-8'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.4 --enable-shared --enable-multiarch
--enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
--enable-targets=all --with-arch-32=i586 --with-tune=generic
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu
Thread model: posix
gcc version 4.4.5 (Debian 4.4.5-8)
The code is compiled as
gcc xor.c -o xor -msse2 -O1 -std=c99
[Bug middle-end/55851] [4.8 Regression] ICE in size_binop_loc, at fold-const.c:1385
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55851 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Component|c |middle-end --- Comment #7 from Jakub Jelinek 2013-01-03 14:47:37 UTC --- The C FE is innocent, it has TYPE_SIZE_UNIT >. The problem is in the gimplifier, gimplify_one_sizepos, because sizetype is types_compatible_p with the ENUMERAL_TYPE (with -m32), replaces the sizetype typed TYPE_SIZE_UNIT with the enumeral one. So, either we'd need to special case this in gimplify_one_sizepos or so and if it turns an INTEGER_TYPE expr into something with different type TREE_CODE, do something (what exactly? If we turn it into a NOP_EXPR of the VAR_DECL, it will not satisfy is_gimple_sizepos and we'll try to regimplify it again and again, or shall we adjust is_gimple_sizepos too to allow that special case of a NOP_EXPR of is_gimple_sizepos if the types are compatible?). Or adjust whatever code is assuming that TYPE_SIZE_UNIT must be INTEGER_TYPE.
[Bug fortran/55854] ICE on intent(out) dummy argument with unlimited polymorphic component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55854 --- Comment #3 from Tobias Burnus 2013-01-03 14:46:54 UTC --- The problem seems to be the "gfc_class_null_initializer", where "ts" is unlimited polymorphic and "init_expr" is of type "__class__$tar_a" (and EXPR_NULL). The latter leads to the generation of __vtab_CLASS_0_ with the associated _copy function. Besides the wrong type, the generation _copy is triggered very late, namely in gfc_trans_deferred_vars-> gfc_trans_structure_assign. That's the reason for using the wrong scope and - hence - for the ICE. Patch: --- a/gcc/fortran/class.c +++ b/gcc/fortran/class.c @@ -414,7 +414,7 @@ gfc_class_null_initializer (gfc_typespec *ts, gfc_expr *init_expr) && ts->u.derived->components->ts.u.derived->attr.unlimited_polymorphic; if (is_unlimited_polymorphic && init_expr) -vtab = gfc_find_intrinsic_vtab (&(init_expr->ts)); +vtab = gfc_find_intrinsic_vtab (&ts->u.derived->components->ts); else vtab = gfc_find_derived_vtab (ts->u.derived);
[Bug middle-end/55863] Fails to fold (i + 2) - (i + 1) to 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55863 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-01-03 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Richard Biener 2013-01-03 14:29:25 UTC --- I have a patch.
[Bug middle-end/55863] New: Fails to fold (i + 2) - (i + 1) to 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55863
Bug #: 55863
Summary: Fails to fold (i + 2) - (i + 1) to 1
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org
For
(analyze_overlapping_iterations
(chrec_a = {pretmp_1529 + 1, +, 1}_20)
(chrec_b = {pretmp_1529 + 2, +, 1}_20)
The SIV test currently fails because when computing the difference
between the CHRECs we compute pretmp_1529 + 2 + ~pretmp15_29. This
is because when computing A - B we check if B is easy to negate - which
X + 1 is - and compute it as A + ~X which association then fails to
optimize.
This makes dependence tests of this kind fail.
[Bug libstdc++/55861] [C++11] `std::shared_future::get' is not const-qualified
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55861 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-01-03 AssignedTo|unassigned at gcc dot |redi at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.8.0 Ever Confirmed|0 |1 --- Comment #1 from Jonathan Wakely 2013-01-03 14:22:05 UTC --- The fix should be as simple as adding "const" to __basic_future::_M_get_result and the three shared_future::get() functions.
[Bug tree-optimization/55862] New: ICE in compute_antic, at tree-ssa-pre.c:2495
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55862
Bug #: 55862
Summary: ICE in compute_antic, at tree-ssa-pre.c:2495
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: antoine.balest...@gmail.com
Hi ! The following testcase makes GCC 4.8.0 as of 20130103 crash at -O2.
It may be related to PR55348 (which was probably a dup anyway).
$ cat antic.c
int g, a, *b;
void f(void)
{
int *p;
if(g)
{
int **k = &p;
if(0)
{
while(g++)
for(*b = 0; *b; b++)
label1:
;
}
for(; g; p++)
for(a = 0; a < 1; a++)
{
int *c = p;
label2:
if(a < 1)
*c = 0;
}
goto label1;
}
goto label2;
}
$ xgcc -O2 -w antic.c
antic.c: In function ‘f’:
antic.c:3:6: internal compiler error: in compute_antic, at tree-ssa-pre.c:2495
void f(void)
^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
[Bug libstdc++/55861] New: [C++11] `std::shared_future::get' is not const-qualified
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55861
Bug #: 55861
Summary: [C++11] `std::shared_future::get' is not
const-qualified
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ai.az...@gmail.com
`std::shared_future::get' member function is specified as const-qualified in
[futures.shared_future]. However, libstdc++'s implementation is not. A testcase
would be as follows;
//--
#include
int f()
{
return 42;
}
int main()
{
std::shared_future const ftr(std::async(&f));
ftr.get(); // Line 11
}
//--
For the above testcase, GCC 4.8.0 20121230 complains as follows;
main.cpp: In function 'int main()':
main.cpp:11:11: error: passing 'const std::shared_future' as 'this'
argument of 'const _Res& std::shared_future<_Res>::get() [with _Res = int]'
discards qualifiers [-fpermissive]
ftr.get();
^
[Bug tree-optimization/55860] New: Turn segmented iteration into nested loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55860
Bug #: 55860
Summary: Turn segmented iteration into nested loops
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gli...@gcc.gnu.org
Hello,
in the code below (compiled with g++ -O3), replacing L2 with L1 in the goto
lets gcc generate much better code (the loop on iii never tests jkl), whereas
with L2 it performs the redundant test every time. I have no idea how hard it
would be to teach gcc to notice that. This kind of code appears in C++ when we
define an iterator that iterates over the elements of several containers
successively.
void f(int,int);
void g(int n,int m){
int iii=0;
int jkl=0;
while(jkl
[Bug ada/52123] [4.7/4.8 Regression] gcc bootstrap with ada fails on mingw target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52123 --- Comment #7 from Rainer Emrich 2013-01-03 13:28:51 UTC --- Patch posted to the ML http://gcc.gnu.org/ml/gcc-patches/2013-01/msg00114.html
[Bug fortran/55854] ICE on intent(out) dummy argument with unlimited polymorphic component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55854 --- Comment #2 from Tobias Burnus 2013-01-03 13:03:49 UTC --- (In reply to comment #1) > I think it's the same as PR55763 comment 10. Seemingly not - at least with the patch from PR55763 comment 12, this example crashes in: #0 build_function_decl (sym=0x1658420, global=) at ../../gcc/fortran/trans-decl.c:1852 #1 0x00613e37 in gfc_get_symbol_decl (sym=0x1658420) at ../../gcc/fortran/trans-decl.c:1370 The following assert fails for sym == "__copy_CLASS_0_": 1848 /* Allow only one nesting level. Allow public declarations. */ 1849 gcc_assert (current_function_decl == NULL_TREE 1850 || DECL_FILE_SCOPE_P (current_function_decl) 1851 || (TREE_CODE (DECL_CONTEXT (current_function_decl)) 1852 == NAMESPACE_DECL)); Here, "current_function_decl" is "function_decl bar.
[Bug fortran/55763] Issues with some simpler CLASS(*) programs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55763 --- Comment #13 from Tobias Burnus 2013-01-03 13:03:24 UTC --- (In reply to comment #12) > Proposed patch: Which fails with gfc_typename(): Undefined type for contains subroutine foo type t end type t class(*), allocatable :: x integer, target :: y x => y end subroutine foo end
[Bug fortran/55763] Issues with some simpler CLASS(*) programs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55763 --- Comment #12 from Tobias Burnus 2013-01-03 12:55:23 UTC --- For another failure, see PR 55854. (In reply to comment #10) > I have a simple case where CLASS(*) leads to an ICE. > If it doesn't fit here, please feel free to move it elsewhere. Proposed patch: --- a/gcc/fortran/class.c +++ b/gcc/fortran/class.c @@ -2227,3 +2227 @@ gfc_find_intrinsic_vtab (gfc_typespec *ts) - /* Avoid segfaults because due to character length. */ - c->ts.type = ts->type == BT_CHARACTER ? BT_VOID : ts->type; - c->ts.kind = ts->kind; + c->ts.type = BT_VOID; @@ -2237,3 +2235 @@ gfc_find_intrinsic_vtab (gfc_typespec *ts) - /* Avoid segfaults due to missing character length. */ - c->ts.type = ts->type == BT_CHARACTER ? BT_VOID : ts->type; - c->ts.kind = ts->kind; + c->ts.type = ts->type = BT_VOID;
[Bug middle-end/55859] Mention -Og/-Ofast in "error: argument to '-O' should be a non-negative integer"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55859 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-03 Ever Confirmed|0 |1 --- Comment #1 from Richard Biener 2013-01-03 12:42:41 UTC --- Or 's' ...
