[Bug driver/55884] [4.8 Regression] FAIL: libgomp.fortran/omp_parse3.f90 -O0 (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55884
--- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-08
08:13:02 UTC ---
On HP-UX or Linux? The test is guarded with
! { dg-require-effective-target tls_runtime }
does the OS have assembly/linker and runtime TLS support?
Can you attach libgomp.log ?
[Bug sanitizer/55844] -fsanitize=address -Os -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -m64 doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55844 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-08 08:14:12 UTC --- Author: jakub Date: Tue Jan 8 08:14:04 2013 New Revision: 195005 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195005 Log: PR sanitizer/55844 * c-c++-common/asan/null-deref-1.c: Add -fno-shrink-wrap to dg-options. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/asan/null-deref-1.c
[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 #10 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-08 08:32:21 UTC --- Author: jakub Date: Tue Jan 8 08:32:12 2013 New Revision: 195006 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195006 Log: PR middle-end/55851 * fold-const.c (int_binop_types_match_p): Allow all INTEGRAL_TYPE_P types instead of just INTEGER_TYPE types. * gcc.c-torture/compile/pr55851.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr55851.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/54120] [4.8 Regression] FAIL: gfortran.fortran-torture/execute/random_2.f90 execution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54120 --- Comment #14 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-08 08:33:50 UTC --- Author: jakub Date: Tue Jan 8 08:33:43 2013 New Revision: 195007 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195007 Log: PR tree-optimization/54120 * tree-vrp.c (range_fits_type_p): Don't allow src_precision precision from signed vr to unsigned_p if vr-min or vr-max is negative. (simplify_float_conversion_using_ranges): Test can_float_p against CODE_FOR_nothing. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vrp.c
[Bug tree-optimization/55890] [4.7 Regression] calling a builtin func through a cast triggers an ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55890 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-08 08:38:58 UTC --- Author: jakub Date: Tue Jan 8 08:38:50 2013 New Revision: 195008 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195008 Log: PR middle-end/55890 * tree-ssa-ccp.c (evaluate_stmt): Use gimple_call_builtin_p. * gcc.dg/torture/pr55890-3.c: New test. Added: trunk/gcc/testsuite/gcc.dg/torture/pr55890-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-ccp.c
[Bug sanitizer/55844] -fsanitize=address -Os -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -m64 doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55844 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-08 08:44:44 UTC --- Worked around, likely going to be fixed with switch to unwind based backtrace for fatal backtraces.
[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 jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-08 08:45:27 UTC --- Fixed.
[Bug middle-end/54120] [4.8 Regression] FAIL: gfortran.fortran-torture/execute/random_2.f90 execution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54120 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #15 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-08 09:08:58 UTC --- Fixed.
[Bug fortran/55868] [4.8 Regression] gfortran generates for CLASS(*) __m_MOD___vtab__$tar on NO_DOLLAR_IN_LABEL systems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55868 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-08 09:13:12 UTC --- I'd say GFC_PREFIX wouldn't improve this, I'd keep using $ unless NO_DOLLAR_IN_LABEL, otherwise fallback to . if NO_DOT_IN_LABEL and as last fallback use _ in this case.
[Bug sanitizer/55561] TSAN: Fortran/OMP yields false positives
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 --- Comment #33 from Dmitry Vyukov dvyukov at google dot com 2013-01-08 09:17:31 UTC --- (In reply to comment #32) (In reply to comment #30) The formatting in the patch is wrong (multiple issues). I've tried to fix them in the version below. It would be really cool to have -fopenmp -fsanitize=thread to work out-of-the-box with gcc. Agree. Can you sent it to review? You can also mention that it fixes issue 40362.
[Bug fortran/55868] [4.8 Regression] gfortran generates for CLASS(*) __m_MOD___vtab__$tar on NO_DOLLAR_IN_LABEL systems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55868 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2013-01-08 09:37:00 UTC --- (In reply to comment #2) I'd say GFC_PREFIX wouldn't improve this, I'd keep using $ unless NO_DOLLAR_IN_LABEL, otherwise fallback to . if NO_DOT_IN_LABEL and as last fallback use _ in this case. I actually wonder whether the $ or . is really needed. The leading __ puts it firmly into the realm of the compiler and to avoid clashes with user-defined types, using upper case is enough as all user-defined type names are converted into lower case. Hence, the following untested patch should be enough. Another question is whether we want change at some point (e.g. ABI breaking due to the new array descriptor?) the __vtab mangling to contains a . (if available) to reduce the chance of name clashes even further. --- a/gcc/fortran/class.c +++ b/gcc/fortran/class.c @@ -464 +464 @@ get_unique_type_string (char *string, gfc_symbol *derived) -sprintf (dt_name, %s, $tar); +sprintf (dt_name, %s, STAR); diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c index 3a36cad..fef44d5 100644 --- a/gcc/fortran/decl.c +++ b/gcc/fortran/decl.c @@ -2769 +2769 @@ gfc_match_decl_type_spec (gfc_typespec *ts, int implicit_flag) - gfc_find_symbol ($tar, gfc_current_ns, 1, upe); + gfc_find_symbol (STAR, gfc_current_ns, 1, upe); @@ -2772,2 +2772,2 @@ gfc_match_decl_type_spec (gfc_typespec *ts, int - upe = gfc_new_symbol ($tar, gfc_current_ns); - st = gfc_new_symtree (gfc_current_ns-sym_root, $tar); + upe = gfc_new_symbol (STAR, gfc_current_ns); + st = gfc_new_symtree (gfc_current_ns-sym_root, STAR); @@ -2788 +2788 @@ gfc_match_decl_type_spec (gfc_typespec *ts, int implicit_flag) - st = gfc_find_symtree (gfc_current_ns-sym_root, $tar); + st = gfc_find_symtree (gfc_current_ns-sym_root, STAR); @@ -2790 +2790 @@ gfc_match_decl_type_spec (gfc_typespec *ts, int implicit_flag) - st = gfc_new_symtree (gfc_current_ns-sym_root, $tar); + st = gfc_new_symtree (gfc_current_ns-sym_root, STAR);
[Bug c++/49122] [C++0x] initializer_list is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49122 Joyabrata Ghosh joy.career at gmail dot com changed: What|Removed |Added CC||joy.career at gmail dot com --- Comment #3 from Joyabrata Ghosh joy.career at gmail dot com 2013-01-08 09:38:51 UTC --- Hi All, Would anyone from GCC team please confirm, when the broken initializer_list feature will be fixed: I tried with gcc 4.6.3 and it appears to be broken today. Results: Behaviour is persistent and data returning from caller constructor were garbage values. $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/4.6/lto-wrapper Target: i686-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --enable-targets=all --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu Thread model: posix gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
[Bug fortran/55868] [4.8 Regression] gfortran generates for CLASS(*) __m_MOD___vtab__$tar on NO_DOLLAR_IN_LABEL systems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55868 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-08 09:41:29 UTC --- Fine with me. Just a note, sprintf (dt_name, %s, STAR); would be better written as strcpy (dt_name, STAR);
[Bug bootstrap/50148] GCC fails to bootstrap with -O3 due to may be used uninitialized errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50148 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org 2013-01-08 09:45:22 UTC --- Fixed thus. (Note that on release branches we do not enable -Werror by default so it's a non-issue there and also in general IMHO, for the false positives at least)
[Bug fortran/54195] [4.8 Regression][OOP] IMPORT fails with GENERIC TBP: is already present in the interface
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54195
--- Comment #10 from janus at gcc dot gnu.org 2013-01-08 09:47:17 UTC ---
For comment #8, resolve_typebound_intrinsic_op is called twice: Once for the
base type 'nc', and once for the extended type 'ncb'.
A crude way to avoid this is the following:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c(revision 194927)
+++ gcc/fortran/resolve.c(working copy)
@@ -12315,15 +12315,10 @@ static gfc_try
resolve_typebound_procedures (gfc_symbol* derived)
{
int op;
- gfc_symbol* super_type;
if (!derived-f2k_derived || !derived-f2k_derived-tb_sym_root)
return SUCCESS;
- super_type = gfc_get_derived_super_type (derived);
- if (super_type)
-resolve_typebound_procedures (super_type);
-
resolve_bindings_derived = derived;
resolve_bindings_result = SUCCESS;
This fails on:
FAIL: gfortran.dg/abstract_type_6.f03 -O (test for excess errors)
FAIL: gfortran.dg/typebound_operator_14.f90 -O (internal compiler error)
[Bug libstdc++/55594] [4.8 Regression] -Wa,-nH incorrectly added to compile line of all targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55594 --- Comment #9 from Rainer Orth ro at gcc dot gnu.org 2013-01-08 09:48:02 UTC --- Author: ro Date: Tue Jan 8 09:47:55 2013 New Revision: 195009 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195009 Log: Restrict -Wa,-nH use to Solaris (PR libstdc++/55594) PR libstdc++/55594 * acinclude.m4 (GLIBCXX_CHECK_ASSEMBLER_HWCAP): Restrict test to Solaris targets. * configure: Regenerate. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/acinclude.m4 trunk/libstdc++-v3/configure
[Bug lto/55902] lto1 SIGSEGV
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55902 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-01-08 Ever Confirmed|0 |1 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org 2013-01-08 09:48:55 UTC --- I stronly suggest you try GCC 4.7.2 (that is, the latest available release) when you run into LTO issues as well as recent binutils releases (what's your binutils version? do you use gold?). Does it only reproduce with -flto-partition=none? Can you try to reduce the set of input source files by using partial linking (-r -nostdlib)? Usually this reduces the set of input sources to two. The google doc is not accessible for me.
[Bug libstdc++/55594] [4.8 Regression] -Wa,-nH incorrectly added to compile line of all targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55594 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #10 from Rainer Orth ro at gcc dot gnu.org 2013-01-08 09:49:17 UTC --- Fixed for 4.8.0.
[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 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-08 09:58:05 UTC --- Created attachment 29103 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29103 gcc48-pr55829.patch Yeah, comparing the vec_dupv2df and *vec_concatv2df patterns shows that for the former we accept for sse3 but not avx x - 0, x - x and x - m, while for the latter only x - 0, x and x - m, 1 and not x - x, 1, when movddup has 2 different register arguments. With this change it doesn't ICE anymore, even when it actually doesn't emit that form of movddup (the vec_concat of 2x (reg:DF 62) pseudo where (reg:DF 62) is assigned r12 (it is used in the following loop which contains calls), it is LRA reloaded into two stores of r12 into mem, once loaded into xmm1 and used from mem, i.e. for whatever reason the x - 0, m alternative is chosen, but postreload then turns it into movddup with both arguments xmm1 (x - 0, 0). I think this patch can be useful and does give the RA more freedom, but it is unclear whether it doesn't make some LRA bug latent. Vlad?
[Bug bootstrap/55790] Build Failure on Head Targeting x86_64 Linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55790 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-01-08 Ever Confirmed|0 |1 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org 2013-01-08 09:58:26 UTC --- ASM_BYTE is supposed to be included from config/i386/att.h via the generated file tm.h. You should look at preprocessed source with -dD to see why it is missing for you.
[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 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||uros at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-08 10:02:16 UTC --- BTW, there is a slight inconsistency between the two patterns, the first pattern uses sselog1 type for both the unpckldp %0, %0 and %vmovddup %1, %0 and V2DFmode mode attribute, while the second pattern uses sselog type for both of those and DFmode mode attribute for the movddup case.
[Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792
--- Comment #15 from Richard Biener rguenth at gcc dot gnu.org 2013-01-08
10:17:16 UTC ---
(In reply to comment #11)
(In reply to comment #9)
Eh. Diego, how does GTY((user)) work here? It smells like a bug in vec.h
to me.
/* Garbage collection support for vecT, A, vl_embed. */
templatetypename T
void
gt_ggc_mx (vecT, va_gc *v)
{
extern void gt_ggc_mx (T );
for (unsigned i = 0; i v-length (); i++)
gt_ggc_mx ((*v)[i]);
}
doesn't it need to mark the vec itself? Maybe automatic registration of
roots (this is a GC root) does not work with GTY((user))?
No. The root is/should be marked by the code calling gt_ggc_mx. gengtype
will
generate code like:
if (ggc_test_and_set_mark (x))
{
gt_ggc_mx (x);
}
ggc_test_and_set_mark() is the one that marks the root. Has gengtype
generated
a function for this global? It should be something like this
void
gt_ggc_mx_vec_mangled_type_name (void *x_p)
{
vectype_name,va_gc * const x = (vectype_name,va_gc *)x_p;
if (ggc_test_and_set_mark (x))
{
gt_ggc_mx (x);
}
}
There is
EXPORTED_CONST struct ggc_root_tab gt_ggc_r_gtype_desc_c[] = {
...
{
lto_global_var_decls,
1,
sizeof (lto_global_var_decls),
gt_ggc_mx_vec_tree_va_gc_,
gt_pch_nx_vec_tree_va_gc_
},
in gtype-desc.c, which looks like
void
gt_ggc_mx_vec_tree_va_gc_ (void *x_p)
{
vectree,va_gc * const x = (vectree,va_gc *)x_p;
if (ggc_test_and_set_mark (x))
{
gt_ggc_mx (x);
}
}
with
/* If EXPR is not NULL and previously unmarked, mark it and evaluate
to true. Otherwise evaluate to false. */
#define ggc_test_and_set_mark(EXPR) \
((EXPR) != NULL ((void *) (EXPR)) != (void *) 1 ! ggc_set_mark (EXPR))
this indeed looks correct to me given vec.h's
templatetypename T
void
gt_ggc_mx (vecT, va_gc *v)
{
extern void gt_ggc_mx (T );
for (unsigned i = 0; i v-length (); i++)
gt_ggc_mx ((*v)[i]);
}
and the generated(?)
void
gt_ggc_mx (union tree_node * x)
{
if (x)
gt_ggc_mx_lang_tree_node ((void *) x);
}
So I'm still not sure what HJ means with it's collected. GC roots are
never collected. HJ, should your patch fix anything? What do you think
the bug is?
[Bug c++/55801] ICE with thread_local after ill-formed forward declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55801 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2013-01-08 10:22:30 UTC --- On it.
[Bug c++/49122] [C++0x] initializer_list is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49122 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2013-01-08 10:27:55 UTC --- This is not a bug in GCC, there's nothing to fix.
[Bug c++/55801] ICE with thread_local after ill-formed forward declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55801 --- Comment #2 from vlukas at gmx dot de 2013-01-08 10:46:55 UTC --- Thank you for working on this. Strangely, I just tested this again and could remove one line from my testcase: class C; thread_local C O, O2 = O; -- The two lines above produce an ICE too. The line class ::C; was removed, it is not necessary for the ICE to occur. I thought I had tested this back in december already. This means that the title of this PR should get changed, otherwise it is misleading.
[Bug c++/49122] [C++0x] initializer_list is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49122 --- Comment #5 from Joyabrata Ghosh joy.career at gmail dot com 2013-01-08 10:48:36 UTC --- Hi Jonathan Wakely, Just wanted to confirm the doubt: Do you wanted to mean that, the initializer_listT behaviour is exactly like this(work for local stack members) and there nothing work around possible to avoid this observation ? Thanks in advance, Joyabrata Ghosh
[Bug other/53489] suggest a feature for gcc.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53489 --- Comment #2 from Tal tal.regev at gmail dot com 2013-01-08 10:58:57 UTC --- Please add a C# front end to gcc: there two open source for this, you can continue / add / migrate / use them http://www.mono-project.com/Main_Page http://www.gnu.org/software/dotgnu/ thanks, Tal (In reply to comment #1) (In reply to comment #0) It will be nice if it can add in a website like in sourceforge or google code, they have a nice table for bugs and features. GCC already has a website and a bug database (you used it to submit this request!) What do you mean? I see GCC is support a Java language and it combine with GCJ http://gcc.gnu.org/java/ why not to do the same with C#? What do you mean by the same? If the mono team wanted to contribute their compiler to GCC they would do. You'll need to be clearer what you are suggesting, as noone is going to work on a vague suggestion that they can't understand. If you can't even be bothered to escribe your idea properly why should anyone be bothered to work on it?
[Bug pch/54117] [4.8 Regression] FAIL: ./decl-3.h -O0 -g (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54117 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||steven at gcc dot gnu.org --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-08 11:03:50 UTC --- Broken by Steven's PCH changes. http://gcc.gnu.org/viewcvs?root=gccview=revrev=188856 http://gcc.gnu.org/viewcvs?root=gccview=revrev=189482 (from r188856 to r189481 this ICEd, afterwards it just results in assembly comparison differences. Can be reproduced even on x86_64-linux, e.g. with make check-gcc RUNTESTFLAGS='--target_board=unix/-m32/-gstabs pch.exp=decl-3*' The saving/restoring of assembly directives has been there clearly for a reason, so needs to be replaced or the changes reverted. Not sure if stabs + PCH warrants a P1 regression though.
[Bug c++/55881] #pragma GCC diagnostic ignored ignored when inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55881 --- Comment #5 from Manuel López-Ibáñez manu at gcc dot gnu.org 2013-01-08 11:14:49 UTC --- (In reply to comment #4) (In reply to comment #2) Well - confirmed. Unlikely to be fixed. That's _very_ unfortunate. It makes the pragma almost useless in practice. The pragma can only work if it somehow knows that location 5:19 is expanded (inlined) from the location of return i.foo(n) since the code checks that the location included in the warning is within the range of the pragma and 5:19 is clearly not. This could be implement in the same way as we currently handle macro expansions, however, it won't be a trivial amount of work, and it is quite unlikely that any current developer has the free time and the interest necessary to do it themselves. If you really want this feature, you have to either try to implement it yourself or convince someone to do it for you. Or you may do n = n and silence the warning.
[Bug pch/54117] [4.8 Regression] FAIL: ./decl-3.h -O0 -g (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54117 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-08 11:27:12 UTC --- The problem is that dbxout.c (unlike dwarf2out.c; not sure about other debug backends) emits assembly immediately into asm_out_file, pretty much everywhere, instead of creating data structures from it and emitting everything only during the finish debughook. So, if you'd like to avoid reversion of the patch, I'm afraid you'd pretty much need to implement the same thing, at least for dbxout (that, in between pch_init (but not earlier, you don't want to duplicate the stabs created before that) and pch_write the stabs will be say queued into some GC memory block and that GC memory block will be printed into assembly upon reading of pch or so. I doubt fmemopen or similar is portable enough, so you'd need to rewrite all the dbxout.c code that right now uses fwrite/fputc/putc etc. to use some other interfaces and conditionally either append to the GC string, or write into asm_out_file. Or rewrite dbxout.c to queue up everything, not sure if it wouldn't break anything if emitted at the end of assembly though.
[Bug pch/54117] [4.8 Regression] FAIL: ./decl-3.h -O0 -g (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54117 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target|hppa2.0w-hp-hpux11.11 |stabs Host|hppa2.0w-hp-hpux11.11 | Build|hppa2.0w-hp-hpux11.11 | --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org 2013-01-08 11:49:32 UTC --- Thanks for analyzing this. I think reverting would be backward - we should clearly move forward. One way forward is to simply declare PCH unsupported with stabs. The issue can be reproduced on x86_64 with -gstabs btw: make check-gcc RUNTESTFLAGS=--target_board=unix/-gstabs pch.exp Running /space/rguenther/src/svn/trunk/gcc/testsuite/gcc.dg/pch/pch.exp ... FAIL: gcc.dg/pch/decl-3.c -O0 -g assembly comparison FAIL: gcc.dg/pch/decl-3.c -O0 assembly comparison FAIL: gcc.dg/pch/decl-3.c -O1 assembly comparison FAIL: gcc.dg/pch/decl-3.c -O2 assembly comparison FAIL: gcc.dg/pch/decl-3.c -O3 -fomit-frame-pointer assembly comparison FAIL: gcc.dg/pch/decl-3.c -O3 -g assembly comparison FAIL: gcc.dg/pch/decl-3.c -Os assembly comparison FAIL: gcc.dg/pch/decl-4.c -O0 -g assembly comparison FAIL: gcc.dg/pch/decl-4.c -O0 assembly comparison ... Another hack would be to s/asm_out_file/dbx_out_file/ in dbxout.c and switch it to a temporary file during PCH generation, in the handle_pch hook then read its contents and store it into the PCH.
[Bug middle-end/55889] [4.8 Regression] ICE: in move_op_ascend, at sel-sched.c:6153 with -fschedule-insns -fselective-scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55889 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-08 12:19:16 UTC --- Can't reproduce (with a cross). Is this when compiling 32-bit or 64-bit? What kind of CPU tuning by default?
[Bug fortran/44672] [F2008] ALLOCATE with SOURCE and no array-spec
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44672 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-08 Ever Confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2013-01-08 12:33:36 UTC --- Duplicate of pr45440?
[Bug fortran/45440] [F03] ALLOCATE with SOURCE gives an ICE (segfault)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45440 --- Comment #9 from Dominique d'Humieres dominiq at lps dot ens.fr 2013-01-08 12:34:01 UTC --- It looks like a duplicate of pr44672.
[Bug fortran/55824] [OOP] ICE with ALLOCATE and SOURCE= TRANSPOSE/RESHAPE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55824 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-08 Ever Confirmed|0 |1 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr 2013-01-08 12:37:05 UTC --- Confirmed.
[Bug c++/49122] [C++0x] initializer_list is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49122 --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org 2013-01-08 12:39:26 UTC --- (In reply to comment #5) Hi Jonathan Wakely, Just wanted to confirm the doubt: That's not a doubt it's a question. Do you wanted to mean that, the initializer_listT behaviour is exactly like this(work for local stack members) and there nothing work around possible to avoid this observation ? Yes. If you want to pass data out of a function use a container or a tuple or something that *copies* the data. An std::initializer_list is not a container, it does not own or copy its elements. The workaround is don't misuse initializer_list for something it isn't designed to do.
[Bug pch/54117] [4.8 Regression] FAIL: ./decl-3.h -O0 -g (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54117 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-08 12:42:06 UTC --- dbxout.c already defines a handle_pch hook, so it is apparently told when pch_init and write_pch are called, so in theory this could be handled in dbxout.c only (still, the question is if other debug backends don't have similar issue).
[Bug fortran/55086] ICE with FORALL in allocate_temp_for_forall_nest_1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55086 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-08 Ever Confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2013-01-08 12:45:27 UTC --- Confirmed on 4.4, 4.5, 4.6, 4.7, and trunk.
[Bug c++/55908] New: Problem binding a const member function to a const object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55908
Bug #: 55908
Summary: Problem binding a const member function to a const
object
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: s...@s-e-f-i.de
The following code fails to compile:
#include functional
typedef std::functionvoid (int) func;
struct foo
{
void f(int) const
{
}
void g() const
{
func(std::bind(foo::f, this, std::placeholders::_1));
}
};
int main()
{
}
g++-4.8.0-alpha20130106 -std=c++11 test.cpp
test.cpp: In member function 'void foo::g() const':
test.cpp:14:55: error: no matching function for call to
'std::functionvoid(int)::function(std::_Bind_helperfalse, void
(foo::*)(int)const, const foo* const, const std::_Placeholder1::type)'
func(std::bind(foo::f, this, std::placeholders::_1));
^
test.cpp:14:55: note: candidates are:
In file included from test.cpp:1:0:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0-alpha20130106/include/g++-v4/functional:2252:2:
note: templateclass _Functor, class std::function_Res(_ArgTypes
...)::function(_Functor)
function(_Functor);
^
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0-alpha20130106/include/g++-v4/functional:2252:2:
note: template argument deduction/substitution failed:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0-alpha20130106/include/g++-v4/functional:2227:7:
note: std::function_Res(_ArgTypes ...)::function(std::function_Res(_ArgTypes
...)) [with _Res = void; _ArgTypes = {int}]
function(function __x) : _Function_base()
^
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0-alpha20130106/include/g++-v4/functional:2227:7:
note: no known conversion for argument 1 from 'std::_Bind_helperfalse, void
(foo::*)(int)const, const foo* const, const std::_Placeholder1::type {aka
std::_Bindstd::_Mem_fnvoid (foo::*)(int)const(const foo*,
std::_Placeholder1)}' to 'std::functionvoid(int)'
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0-alpha20130106/include/g++-v4/functional:2430:5:
note: std::function_Res(_ArgTypes ...)::function(const
std::function_Res(_ArgTypes ...)) [with _Res = void; _ArgTypes = {int}]
function_Res(_ArgTypes...)::
^
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0-alpha20130106/include/g++-v4/functional:2430:5:
note: no known conversion for argument 1 from 'std::_Bind_helperfalse, void
(foo::*)(int)const, const foo* const, const std::_Placeholder1::type {aka
std::_Bindstd::_Mem_fnvoid (foo::*)(int)const(const foo*,
std::_Placeholder1)}' to 'const std::functionvoid(int)'
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0-alpha20130106/include/g++-v4/functional:2207:7:
note: std::function_Res(_ArgTypes ...)::function(std::nullptr_t) [with _Res =
void; _ArgTypes = {int}; std::nullptr_t = std::nullptr_t]
function(nullptr_t) noexcept
^
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0-alpha20130106/include/g++-v4/functional:2207:7:
note: no known conversion for argument 1 from 'std::_Bind_helperfalse, void
(foo::*)(int)const, const foo* const, const std::_Placeholder1::type {aka
std::_Bindstd::_Mem_fnvoid (foo::*)(int)const(const foo*,
std::_Placeholder1)}' to 'std::nullptr_t'
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0-alpha20130106/include/g++-v4/functional:2200:7:
note: std::function_Res(_ArgTypes ...)::function() [with _Res = void;
_ArgTypes = {int}]
function() noexcept
^
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0-alpha20130106/include/g++-v4/functional:2200:7:
note: candidate expects 0 arguments, 1 provided
The problem goes away if the int parameter is taken out, or if g() is not
const.
gcc-4.7.2 accepts the test case.
[Bug pch/54117] [4.8 Regression] FAIL: ./decl-3.h -O0 -g (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54117 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-08 13:28:56 UTC --- Note this isn't limited to dbxout.c, pretty much all *out.c debug backends but dwarf2out.c suffer from these issues, they all emit assembly immediately, only dwarf2out.c just creates data structures to be used later on.
[Bug c++/55908] Problem binding a const member function to a const object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55908
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2013-01-08
AssignedTo|unassigned at gcc dot |redi at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2013-01-08
13:33:56 UTC ---
Reduced:
#include functional
struct foo
{
void f(int) const
{
}
void g() const
{
auto mf = std::mem_fn(foo::f);
mf(this, 1);
}
};
[Bug c++/55908] [4.8 Regression] Problem binding a const member function to a const object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55908 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Known to work||4.7.3 Target Milestone|--- |4.8.0 Summary|Problem binding a const |[4.8 Regression] Problem |member function to a const |binding a const member |object |function to a const object --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2013-01-08 13:35:18 UTC --- Will fix it later today.
[Bug c++/55893] [4.7/4.8 Regression][C++11] runtime segfault with static const object with virtual destructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55893 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-08 13:42:30 UTC --- Caused by http://gcc.gnu.org/PR49673 I believe. Perhaps instead of testing whether TYPE_NEEDS_CONSTRUCTING we need to check if the type has non-trivial destructor (is a user destructor on const qualified vars allowed to store into the var anywhere?) or just a special case virtual dtors that do change the vtable pointer?
[Bug middle-end/55797] [4.8 Regression] ICE: verify_cgraph_node failed: edge has no corresponding call_stmt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55797
--- Comment #3 from Richard Biener rguenth at gcc dot gnu.org 2013-01-08
13:50:58 UTC ---
Eh, we do totally crazy (recursive) inlining here ...
struct section_info
{
intrusive_ptr section_info parent;
};
struct file_info
{
intrusive_ptr file_info parent;
intrusive_ptr section_info switched_section;
};
so the simple
void
start_file (void)
{
intrusive_ptr file_info parent;
}
creates and destroys the graph of file_info / section_info nodes
with the edges represented by intrusive_ptr's.
void start_file() ()
{
...
bb 2:
_5 = parent.px;
if (_5 != 0B)
goto bb 3;
else
goto bb 1041 (L3);
bb 3:
_6 = _5-switched_section;
_7 = _6-px;
if (_7 != 0B)
goto bb 4;
else
goto bb 6 (L1);
bb 4:
section_info::~section_info (_7);
bb 5:
operator delete (_7);
...
and 1000 calls follow.
I wonder why we need such high early-inlin-insns number and for lower we hit:
else if ((n = num_calls (callee)) != 0
growth * (n + 1) PARAM_VALUE (PARAM_EARLY_INLINING_INSNS))
{
if (dump_file)
fprintf (dump_file, will not early inline: %s/%i-%s/%i,
growth %i exceeds --param early-inlining-insns
divided by number of calls\n,
xstrdup (cgraph_node_name (e-caller)), e-caller-uid,
xstrdup (cgraph_node_name (callee)), callee-uid,
growth);
want_inline = false;
}
of which I cannot make very much sense. Why should the number of calls
in callee(!) times the growth matter? Shouldn't this be the number
of times the caller calls callee? And why even that? We've gone completely
away from the consider only if all calls can be inlined way of early
inline operation!
[Bug debug/55579] SRA doesn't create debug stmts when they would be useful
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55579 --- Comment #7 from Martin Jambor jamborm at gcc dot gnu.org 2013-01-08 14:10:52 UTC --- Author: jamborm Date: Tue Jan 8 14:10:44 2013 New Revision: 195015 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195015 Log: 2013-01-08 Martin Jambor mjam...@suse.cz PR debug/55579 * tree-sra.c (analyze_access_subtree): Return true also after potentially creating a debug-only replacement. testsuite/ * gcc.dg/tree-ssa/pr55579.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr55579.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-sra.c
[Bug debug/55579] SRA doesn't create debug stmts when they would be useful
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55579 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #8 from Martin Jambor jamborm at gcc dot gnu.org 2013-01-08 14:14:49 UTC --- Patch committed
[Bug middle-end/55797] [4.8 Regression] ICE: verify_cgraph_node failed: edge has no corresponding call_stmt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55797
--- Comment #4 from Richard Biener rguenth at gcc dot gnu.org 2013-01-08
14:24:59 UTC ---
Solution to put off recursive inlining through iteration:
Index: ipa-inline.c
===
--- ipa-inline.c(revision 195014)
+++ ipa-inline.c(working copy)
@@ -1951,7 +1951,9 @@ early_inline_small_functions (struct cgr
if (!can_early_inline_edge_p (e))
continue;
- if (cgraph_edge_recursive_p (e))
+ if (cgraph_edge_recursive_p (e)
+ || !DECL_STRUCT_FUNCTION
+ (callee-symbol.decl)-always_inline_functions_inlined)
{
if (dump_file)
fprintf (dump_file, Not inlining: recursive call.\n);
as we process functions in DFS order any not already processed function
is in a callgraph cycle. This doesn't fix the overzealeous inlining via
the iteration for the testcase though as we still grow in calls quadratically
(we never hit a direct recursive call when inlining the recursive
sub-callgraph).
That is, early inlining completely misses the graph topology hints
(never inline a SCC entry edge, etc.)
[Bug c/48418] [4.6/4.7/4.8 Regression] Bit shift operator =
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48418 --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-08 14:44:51 UTC --- Created attachment 29104 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29104 gcc48-pr48418.patch Untested fix. To avoid warning twice, this warns in c_fully_fold_internal only if orig_op1 isn't INTEGER_CST, but op1 is. And on the testcase I found that in 4.8 my SIZEOF_EXPR C++ changes regressed the testcase too.
[Bug lto/55902] lto1 SIGSEGV
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55902 --- Comment #4 from Václav Zeman vhaisman at gmail dot com 2013-01-08 15:00:09 UTC --- I have fixed the Google doc sharing. It should be accessible now. I am not sure if I can check GCC 4.7.2, I am using what Ubuntu provides as package. I believe that MinGW cross compiler suite does not use the gold linker. As for the source reduction and flags, I will try those.
[Bug tree-optimization/48189] [4.6/4.7/4.8 Regression] ICE: SIGFPE (division by zero) in in predict_loops () at predict.c:991 with --param max-predicted-iterations=0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48189 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-08 15:02:52 UTC --- Created attachment 29105 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29105 gcc48-pr48189.patch I'd say this isn't difficult to solve enough to warrant having it open for years.
[Bug c/55882] unaligned load/store : incorrect struct offset
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55882 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org 2013-01-08 15:07:16 UTC --- (In reply to comment #3) testfunction: testfunction: ... 20: 03c21021 adduv0,s8,v0 20: 03c21021 adduv0,s8,v0 24: 8c44000c lw a0,12(v0) | 24: 8c44000a lw a0,10(v0) 28: 3c03000f lui v1,0xf| 28: 3c03 lui v1,0x 2c: 3463 ori v1,v1,0x | 2c: 3463000f ori v1,v1,0xf 30: 00831824 and v1,a0,v1 30: 00831824 and v1,a0,v1 34: ac43000c sw v1,12(v0) | 34: ac43000a sw v1,10(v0) 38: 03c0e82d movesp,s8 38: 03c0e82d movesp,s8 3c: 8fbe03ec lw s8,1004(sp) 3c: 8fbe03ec lw s8,1004(sp) 40: 27bd03f0 addiu sp,sp,100840: 27bd03f0 addiu sp,sp,1008 44: 03e8 jr ra44: 03e8 jr ra 48: nop 48: nop I believe the right side is correct. use_alt_rd_dqs is at offset 10 (enable_monitor at 0, step_out_pointer at 2, hold_out_pointer at 4, etc.). Depending on enum behavior on mips (-fshort-enums?) mystruct is aligned to two bytes. Can you post -v output of the compile? I'm trying to reproduce with a cross to mips-elf now.
[Bug rtl-optimization/48181] [4.6/4.7/4.8 Regression] wrong code with -O -fgcse --param ira-max-conflict-table-size=0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48181 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-08 15:16:52 UTC --- But then, won't the exact same issues potentially happen in very large functions where ira_conflicts_p isn't also true, because the conflict table would be too big? I'd say zero MB conflict table is reasonable parameter value, it says don't use the conflict table. If table larger than the param would be needed, no table is created at all.
[Bug c/55882] unaligned load/store : incorrect struct offset
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55882
--- Comment #6 from Richard Biener rguenth at gcc dot gnu.org 2013-01-08
15:25:46 UTC ---
GCC clealy thinks that
(insn 21 20 0 2 (set (mem/j:SI (plus:SI (reg/f:SI 195)
(const_int 10 [0xa])) [0+-2 S4 A32])
(reg:SI 201)) t.i:85 -1
is 4-byte aligned (but it _does_ have this strange MEM_OFFSET setting ...
which should be useless without a MEM_EXPR).
Does
unsigned short
testfunction(void)
{
mystruct dmfe[8];
unsigned i = 0;
dmfe[0].use_alt_rd_dqs = 1;
dmfe[i].use_alt_rd_dqs = 0;
return dmfe[0].use_alt_rd_dqs;
}
extern void abort (void);
int main () { if (testfunction() != 0) abort (); }
abort for you?
[Bug tree-optimization/55760] scalar code non using rsqrtss and rcpss
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55760
--- Comment #5 from vincenzo Innocente vincenzo.innocente at cern dot ch
2013-01-08 15:29:18 UTC ---
we just got hit by this great type of code (copysign is unknown to
scientists)
most probably gcc could optimize it for -Ofast to return copysignf(1.f,x); (x/x
is optimized in 1)
cat one.cc;c++ -Ofast -mrecip -S one.cc; cat one.s
#includecmath
int one(float x) {
return x/std::abs(x);
}
.text
.align 4,0x90
.globl __Z3onef
__Z3onef:
LFB86:
movssLC0(%rip), %xmm2
andps%xmm0, %xmm2
rcpss%xmm2, %xmm1
mulss%xmm1, %xmm2
mulss%xmm1, %xmm2
addss%xmm1, %xmm1
subss%xmm2, %xmm1
mulss%xmm0, %xmm1
cvttss2si%xmm1, %eax
ret
[Bug driver/55884] [4.8 Regression] FAIL: libgomp.fortran/omp_parse3.f90 -O0 (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55884
--- Comment #7 from dave.anglin at bell dot net 2013-01-08 15:29:49 UTC ---
On 1/8/2013 3:13 AM, jakub at gcc dot gnu.org wrote:
On HP-UX or Linux? The test is guarded with
! { dg-require-effective-target tls_runtime }
does the OS have assembly/linker and runtime TLS support?
HP-UX. HP-UX uses emutls. Ii looks to me as this should provide
runtime support but there are some regressions in TLS support at the
moment (PR 54908). Thought this was specific to C++ but maybe
it affects check_effective_target_tls_runtime.
Test is ok on Linux.
Can you attach libgomp.log ?
Have to do another build...
[Bug fortran/51961] [OOP] ALLOCATE with MOLD= rejects if source-expr has a different rank
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51961 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-08 Ever Confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2013-01-08 15:37:02 UTC --- What is allocate supposed to do if the array and the mold are not conformable? From the 2008 draft: Data usage and computation: A structure constructor can omit the value for an allocatable component. SOURCE= in an ALLOCATE statement can give an array variable the bounds as well as the value of an expression. MOLD= in an ALLOCATE statement can give a polymorphic variable the shape, ^ type,and type parameters of an expression without copying the value. The real and imaginary parts of a complex entity can be accessed independently with a component-like syntax. Intrinsic assignment to an allocatable polymorphic variable is allowed. A pointer function reference can denote a variable in any variable definition context. Some restrictions on the use of dummy arguments in elemental subprograms have been removed.
[Bug c/55882] unaligned load/store : incorrect struct offset
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55882
--- Comment #7 from Richard Biener rguenth at gcc dot gnu.org 2013-01-08
15:47:10 UTC ---
Ok with respect to alignment the issue is that when we expand_assignment
for to == dmfe[i_1].use_alt_rd_dqs we fall into the old trap for
STRICT_ALIGNMENT targets to use the mode alignment. That's because
we fall into
misalignp = false;
to_rtx = expand_expr (tem, NULL_RTX, VOIDmode, EXPAND_WRITE);
which creates
(mem/c:BLK (plus:SI (reg/f:SI 189 virtual-stack-vars)
(const_int 4 [0x4])) [0 dmfe+0 S992 A32])
as dmfe is 4-byte aligned. With offset = (sizetype) i_1 * 124 + 2
and bitregion_start = 0, bitregion_end = 63, bitpos = 48 and after
adjusting the offset we feed
(mem/c:BLK (plus:SI (reg/f:SI 206)
(const_int 6 [0x6])) [0 dmfe A16])
into set_mem_attributes_minus_bitpos (with bitpos == 48) and
get_object_alignment returns 32. But we fail to consider bitpos
when using that alignment.
So ... does the following patch fix it for you?
Index: gcc/emit-rtl.c
===
--- gcc/emit-rtl.c (revision 195014)
+++ gcc/emit-rtl.c (working copy)
@@ -1839,7 +1839,13 @@ set_mem_attributes_minus_bitpos (rtx ref
if (!align_computed)
{
- unsigned int obj_align = get_object_alignment (t);
+ unsigned int obj_align;
+ unsigned HOST_WIDE_INT obj_bitpos;
+ get_object_alignment_1 (t, obj_align, obj_bitpos);
+ if (apply_bitpos)
+ obj_bitpos += apply_bitpos;
+ if (obj_bitpos != 0)
+ obj_align = (obj_bitpos -obj_bitpos);
attrs.align = MAX (attrs.align, obj_align);
}
}
[Bug c/55882] unaligned load/store : incorrect struct offset
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55882
--- Comment #8 from Richard Biener rguenth at gcc dot gnu.org 2013-01-08
15:54:46 UTC ---
Or more correct
Index: gcc/emit-rtl.c
===
--- gcc/emit-rtl.c (revision 195014)
+++ gcc/emit-rtl.c (working copy)
@@ -1839,7 +1839,12 @@ set_mem_attributes_minus_bitpos (rtx ref
if (!align_computed)
{
- unsigned int obj_align = get_object_alignment (t);
+ unsigned int obj_align;
+ unsigned HOST_WIDE_INT obj_bitpos;
+ get_object_alignment_1 (t, obj_align, obj_bitpos);
+ obj_bitpos = (obj_bitpos + apply_bitpos) (obj_align - 1);
+ if (obj_bitpos != 0)
+ obj_align = (obj_bitpos -obj_bitpos);
attrs.align = MAX (attrs.align, obj_align);
}
}
[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 Vladimir Makarov vmakarov at redhat dot com changed: What|Removed |Added CC||vmakarov at redhat dot com --- Comment #4 from Vladimir Makarov vmakarov at redhat dot com 2013-01-08 16:09:58 UTC --- (In reply to comment #2) I think this patch can be useful and does give the RA more freedom, but it is unclear whether it doesn't make some LRA bug latent. Vlad? I am working on it on LRA side. I hope the patch will be ready today.
[Bug tree-optimization/55875] [4.8 Regression] IVopts caused miscompilation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55875 --- Comment #7 from Jan Hubicka hubicka at gcc dot gnu.org 2013-01-08 16:12:25 UTC --- Created attachment 29106 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29106 patch in testing.
[Bug libgcj/55637] FAIL: sourcelocation output - source compiled test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55637 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Target|hppa2.0w-hp-hpux11.11 |hppa2.0w-hp-hpux11.11 ||*-*-solaris2*, ||x86_64-unknown-linux-gnu Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-08 CC||ro at gcc dot gnu.org Host|hppa2.0w-hp-hpux11.11 |hppa2.0w-hp-hpux11.11, ||*-*-solaris2*, ||x86_64-unknown-linux-gnu Ever Confirmed|0 |1 Build|hppa2.0w-hp-hpux11.11 |hppa2.0w-hp-hpux11.11 ||*-*-solaris2*, ||x86_64-unknown-linux-gnu --- Comment #1 from Rainer Orth ro at gcc dot gnu.org 2013-01-08 16:15:58 UTC --- I'm also seeing this on *-*-solaris2* and x86_64-unknown-linux-gnu; I suppose it happens everywhere.
[Bug fortran/49592] [OOP] Non-polymorphic ALLOCATE with polymorphic SOURCE= rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49592 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-08 Ever Confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2013-01-08 16:17:09 UTC --- Any progress here?
[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 --- Comment #5 from Uros Bizjak ubizjak at gmail dot com 2013-01-08 16:27:23 UTC --- (In reply to comment #3) BTW, there is a slight inconsistency between the two patterns, the first pattern uses sselog1 type for both the unpckldp %0, %0 and %vmovddup %1, %0 and V2DFmode mode attribute, while the second pattern uses sselog type for both of those and DFmode mode attribute for the movddup case. I will look at these once LRA fix is committed.
[Bug target/42661] Documented -mmad option not accepted.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42661 Steve Ellcey sje at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||sje at gcc dot gnu.org Known to work||4.8.0 Resolution||FIXED --- Comment #3 from Steve Ellcey sje at gcc dot gnu.org 2013-01-08 16:37:05 UTC --- Fixed on ToT for 4.8 release.
[Bug fortran/55852] [4.6/4.7/4.8 regression] internal compiler error: in gfc_build_intrinsic_call, at fortran/expr.c:4647
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55852 --- Comment #10 from Andreas Schwab sch...@linux-m68k.org 2013-01-08 16:55:58 UTC --- The test case fails because the match is too strict. $ grep iszs intrinsic_size_3.f90.003t.original integer(kind=2) iszs; iszs = (integer(kind=2)) MAX_EXPR (D.854-dim[0].ubound - D.854-dim[0].lbound) + 1, 0;
[Bug fortran/55341] address-sanitizer and Fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341 --- Comment #48 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-08 17:02:13 UTC --- Author: jakub Date: Tue Jan 8 17:01:58 2013 New Revision: 195025 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195025 Log: PR fortran/55341 * asan.c (asan_clear_shadow): New function. (asan_emit_stack_protection): Use it. Modified: trunk/gcc/ChangeLog trunk/gcc/asan.c
[Bug libstdc++/55909] New: libtool test exposes what I think is some alignment issue in libstd++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55909
Bug #: 55909
Summary: libtool test exposes what I think is some alignment
issue in libstd++
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: philip.copel...@oracle.com
Created attachment 29107
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29107
Original libtool cpp file
While debugging libtool breakage on sparc64 (64bit Big Endian)
gcc-4.7.2-8.fc18.sparc64
glibc-2.16-28.fc18.sparc64
[mockbuild@localhost 104]$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/sparc64-redhat-linux/4.7.2/lto-wrapper
Target: sparc64-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 --disable-build-with-cxx
--disable-build-poststage1-with-cxx --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu
--enable-languages=c,c++,objc,obj-c++,java,fortran,lto --enable-plugin
--enable-initfini-array --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 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--disable-libjava-multilib --with-ppl --with-cloog --with-long-double-128
--with-cpu=ultrasparc --disable-multilib --build=sparc64-redhat-linux
Thread model: posix
gcc version 4.7.2 20121109 (Red Hat 4.7.2-8) (GCC)
---
++ at_fn_check_prepare_dynamic 'if /builddir/build/BUILD/libtool-2.4.2/libtool
--mode=execute -dlopen m/module.la ./main ; then :; else lt_status=0;
test Xsparc64-redhat-linux-gnu != Xsparc64-redhat-linux-gnu test -x
./main exit 77; exit ; fi' exceptions.at:385
++ case $1 in
++ at_fn_check_prepare_trace exceptions.at:385
++ printf '%s\n' exceptions.at:385
++ at_check_trace=:
++ at_check_filter=:
++ :
++ :
++ at_status=139
++ at_failed=false
++ :
++ echo stderr:
stderr:
++ cat
/builddir/build/BUILD/libtool-2.4.2/tests/testsuite.dir/at-groups/104/stderr
++ :
++ /builddir/build/BUILD/libtool-2.4.2/libtool --mode=execute -dlopen
m/module.la ./main
exceptions_in_prog
/builddir/build/BUILD/libtool-2.4.2/tests/testsuite.dir/at-groups/104/test-source:
line 565: 61893 Segmentation fault (core dumped) $LIBTOOL --mode=execute
-dlopen m/module.la $lt_exe
++ lt_status=139
--
This eventually boils down to
[mockbuild@localhost 104]$ /builddir/build/BUILD/libtool-2.4.2/libtool
--verbose --mode=execute -dlopen m/module.la ./.libs/lt-main
exceptions_in_prog
Segmentation fault (core dumped)
[mockbuild@localhost 104]$ gdb ./.libs/lt-main
(gdb) set environment LD_LIBRARY_PATH=m
(gdb) run
exceptions_in_prog
Program received signal SIGSEGV, Segmentation fault.
0xf8010061a558 in __frame_dummy_init_array_entry () from
/lib64/libstdc++.so.6
(gdb) where
#0 0xf8010061a558 in __frame_dummy_init_array_entry () from
/lib64/libstdc++.so.6
#1 0xf80100490988 in __cxxabiv1::__cxa_get_globals ()
at ../../../../libstdc++-v3/libsupc++/eh_globals.cc:63
#2 0xf801004907cc in std::uncaught_exception ()
at ../../../../libstdc++-v3/libsupc++/eh_catch.cc:136
#3 0xf801004ccbe4 in ~sentry (this=0x7fef1b0, __in_chrg=optimized
out)
at
/usr/src/debug/gcc-4.7.2-20121109/obj-sparc64-redhat-linux/sparc64-redhat-linux/libstdc++-v3/include/ostream:429
#4 std::__ostream_insertchar, std::char_traitschar (__out=...,
__s=optimized out,
__n=optimized out)
at
/usr/src/debug/gcc-4.7.2-20121109/obj-sparc64-redhat-linux/sparc64-redhat-linux/libstdc++-v3/include/bits/ostream_insert.h:112
#5 0x0010321c in operator std::char_traitschar (
__s=0x1085f8 exceptions_in_prog\n, __out=...)
at
/usr/lib/gcc/sparc64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/ostream:533
#6 exceptions_in_prog () at main.cpp:30
#7 0x00102e78 in main () at main.cpp:120
---
Lets read that in order with some program text around it that might make some
better sense:
#7 0x00102e78 in main () at main.cpp:120
(gdb) list
115 int main (void)
116 {
117
118 LTDL_SET_PRELOADED_SYMBOLS();
119
120 if (exceptions_in_prog ())
121 return 1;
122 if (exceptions_in_lib ())
123 return 1;
124 if (exceptions_in_module ())
[Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792 --- Comment #16 from H.J. Lu hjl.tools at gmail dot com 2013-01-08 17:12:57 UTC --- (In reply to comment #15) So I'm still not sure what HJ means with it's collected. GC roots are never collected. HJ, should your patch fix anything? What do you think the bug is? My patch is an optimization, not a fix.
[Bug fortran/55341] address-sanitizer and Fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #49 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-08 17:17:26 UTC --- Fixed.
[Bug libstdc++/55909] libtool test exposes what I think is some alignment issue in libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55909 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-01-08 Summary|libtool test exposes what I |libtool test exposes what I |think is some alignment |think is some alignment |issue in libstd++ |issue in libstdc++ Ever Confirmed|0 |1 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2013-01-08 17:23:34 UTC --- Whatever it is, I don't think it's a libstdc++ issue: for example, very, very little happens in terms of alignment vs exceptions in libsupc++. Maybe libgcc? As far as you can see, is there something wrong in crtstuff.c in terms of alignments of the various static arrays? Endianness too should not be an issue... In any case, we also need a self contained *.ii file to proceed, per the Bug Reporting instructions.
[Bug fortran/55341] address-sanitizer and Fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341 --- Comment #50 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2013-01-08 17:26:19 UTC --- (In reply to comment #49) Fixed. Thanks, for fixing this issue. Shouldn't the PR be kept open to look into what I'm rather sure is a miscompilation as discussed in comment #44 to #47 ?
[Bug pch/54117] [4.8 Regression] FAIL: ./decl-3.h -O0 -g (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54117 --- Comment #9 from stevenb.gcc at gmail dot com stevenb.gcc at gmail dot com 2013-01-08 17:39:23 UTC --- I think reverting would be backward - we should clearly move forward. One way forward is to simply declare PCH unsupported with stabs. This is what I think we should do about this bug. The problem isn't limited to PCH, it also happens with other delayed outputs. For instance, there's stabs info for symbols not emitted at all by cgraphunit, and debug info isn't emitted at all with LTO. The DWARF-to-*out debug translator should be the way forward IMHO. It'd simplify many things in GCC internals. I might give it a stab (no pun...) for GCC 4.9, but for GCC 4.8 I really don't see any way to fix this issue.
[Bug c++/55910] New: One of instances generated for a method with -O3 uses incorrect parameter cleanup size with 'ret'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55910
Bug #: 55910
Summary: One of instances generated for a method with -O3 uses
incorrect parameter cleanup size with 'ret'
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: o...@eleks.lviv.ua
Created attachment 29108
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29108
Method source and two its instances disassembled.
The bug was initially reported by me for MinGW x86, however they told me there
to fill it for GCC.
After upgrading to GCC 4.7.2 I'having an issue that release build of my DLL
crashes. Debugging shows that this is due to bad code generated by GCC, Alas I
can't provide small test case but here is the faulting function fragment
itself.
---
int CProfileGenerator::CalcAccProfile(
pos_type p0,
vel_type v0,
acc_type a0,
jerk_type j,
vel_type vel,
acc_type acc,
CProfile ret_profile
) const {
time_type t0 = 0.0;
ret_profile.clear(); ret_profile.reserve(10);
vel_type dv = vel-v0;
if (ABS(dv) m_epsilon_v ABS(a0) m_epsilon_a) {
if (dv == 0.0) {
ret_profile.push_back(CProfileStep(0.0, p0, v0, a0, 0.0));
VALIDATEPROFILE(ret_profile);
} else {
acc_type a0 = (dv0.0)?-1.0:1.0;
time_type dt = ABS(dv);
pos_type p1 = p0 + v0*dt + 0.5*dv*dv;
ret_profile.push_back(CProfileStep(0.0, p0, v0, a0, 0.0));
VALIDATEPROFILE(ret_profile);
ret_profile.push_back(CProfileStep(dt, p1, vel, 0.0, 0.0));
VALIDATEPROFILE(ret_profile);
}
G_BLOG_4(acc profile calc skiped );
return ret_profile.size();
}
if (v0 vel) {
acc = ABS(acc);
} else if (v0 == vel) {
acc = -SIGN(a0)*ABS(acc);
} else {
acc = -ABS(acc);
}
if (j == 0.0) {
return InternalAccCalc(t0, p0, v0, 0.0, 0.0, true, true, vel, acc, true,
ret_profile);
// -- FAULTS DUE TO RETURNING TO ADDRESS
0x HERE
}
...
---
Here all the *_type typedefs are doubles and CProfile is std::vector of
CProfileStep structure.
I've built library with -fno-inline to be able to see function calls more
clearly and here is the problem is assembler code.
---
Dump of assembler code for function CProfileGenerator::CalcAccProfile(double,
double, double, double, double, double, CP
rofileGenerator::CProfile) const:
0x100622e0 +0: push %ebp
0x100622e1 +1: mov %ecx,%ebp
0x100622e3 +3: push %edi
0x100622e4 +4: push %esi
0x100622e5 +5: push %ebx
0x100622e6 +6: sub $0x14c,%esp
; Initial stack preparation ends here
0x100622ec +12: mov 0x160(%esp),%eax
0x100622f3 +19: mov 0x190(%esp),%ebx
0x100622fa +26: fldl 0x188(%esp)
0x10062301 +33: fstpl 0x98(%esp)
...
...
...
0x1006254a +618: jbe 0x10062920 CProfileGenerator::CalcAccProfile(double,
double, double, double, double, dou
ble, CProfileGenerator::CProfile) const+1600
0x10062550 +624: fldl 0x98(%esp)
0x10062557 +631: fstpl (%esp)
0x1006255a +634: call 0x1005f2e0 ABSdouble(double const)
0x1006255f +639: fldl 0xb0(%esp)
0x10062566 +646: fldz
0x10062568 +648: fld %st(0)
0x1006256a +650: fxch %st(2)
0x1006256c +652: fucomi %st(2),%st
0x1006256e +654: fstp %st(2)
0x10062570 +656: jnp 0x10062b00 CProfileGenerator::CalcAccProfile(double,
double, double, double, double, dou
ble, CProfileGenerator::CProfile) const+2080
...
...
...
0x10062b00 +2080: jne 0x10062580 CProfileGenerator::CalcAccProfile(double,
double, double, double, double, dou
ble, CProfileGenerator::CProfile) const+672
0x10062b06 +2086: fstp %st(1)
0x10062b08 +2088: fxch %st(1)
0x10062b0a +2090: fstpl 0x30(%esp)
0x10062b0e +2094: mov %ebx,%ecx
0x10062b10 +2096: fldl 0x90(%esp)
0x10062b17 +2103: mov $0x1,%edx
0x10062b1c +2108: mov $0x1,%eax
0x10062b21 +2113: fstpl 0x28(%esp)
0x10062b25 +2117: fstl 0x20(%esp)
0x10062b29 +2121: fstl 0x18(%esp)
0x10062b2d +2125: fldl 0x88(%esp)
0x10062b34 +2132: fstpl 0x10(%esp)
0x10062b38 +2136: fldl 0xc8(%esp)
0x10062b3f +2143: fstpl 0x8(%esp)
0x10062b43 +2147: fstpl (%esp)
0x10062b46 +2150: call 0x10061890
CProfileGenerator::InternalAccCalc(double, double, double, double, double, bo
ol, bool, double, double, bool, CProfileGenerator::CProfile) const
0x10062b4b +2155: sub $0x38,%esp -
THIS COMMAND CORRUPTS STACK POINTER WHICH OTHERWISE WOULD BE VALID
0x10062b4e +2158: add $0x14c,%esp
0x10062b54 +2164: pop %ebx
0x10062b55 +2165: pop %esi
0x10062b56 +2166: pop %edi
0x10062b57 +2167: pop %ebp
0x10062b58 +2168: ret $0x34
---
It looks like you reuse the same stack area for all the calls and just
re-adjust stack pointer back to compensate ret N
[Bug c++/55910] One of instances generated for a method with -O3 uses incorrect parameter cleanup size with 'ret'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55910 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||ktietz at gcc dot gnu.org --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2013-01-08 17:45:53 UTC --- CC-ing Kai.
[Bug c++/55910] One of instances generated for a method with -O3 uses incorrect parameter cleanup size with 'ret'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55910 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-01-08 Ever Confirmed|0 |1 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2013-01-08 17:47:04 UTC --- Note, a self-contained testcase is mandatory per the Bug Reporting instructions.
[Bug pch/54117] [4.8 Regression] FAIL: ./decl-3.h -O0 -g (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54117 --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-08 17:51:10 UTC --- All that to avoid one #include output.h in one file? That doesn't seem appropriate to me. I'm not questioning it is a desirable change, but I'd reapply it only when all the *out.c backends are converted to emit delayed info, or when (if ever) a dwarf2 - something else converters are written.
[Bug c++/55910] One of instances generated for a method with -O3 uses incorrect parameter cleanup size with 'ret'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55910 --- Comment #3 from Oleh Derevenko oder at eleks dot lviv.ua 2013-01-08 17:51:59 UTC --- Well, this is an optimizer issue which goes away with -O2. And optimizer is something that is hard to predict and reproduce, when you run over an issue in complex code with lots of dependencies and inlined methods.
[Bug tree-optimization/55875] [4.8 Regression] IVopts caused miscompilation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55875 --- Comment #8 from Jan Hubicka hubicka at gcc dot gnu.org 2013-01-08 17:55:42 UTC --- Created attachment 29109 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29109 updated patch There is another bug triggered by this testcase. Some of the bounds, like those derrived by if (iv_var == constant) can not be used when they are not executed every iteration. This patch prevents them from being recorded as bounds.
[Bug c++/55910] One of instances generated for a method with -O3 uses incorrect parameter cleanup size with 'ret'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55910 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2013-01-08 17:57:28 UTC --- Indeed, and that's exactly why we need a precise, specific testcase, no hand waving.
[Bug libstdc++/55909] libtool test exposes what I think is some alignment issue in libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55909 --- Comment #2 from philip.copeland at oracle dot com 2013-01-08 17:59:14 UTC --- Created attachment 29110 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29110 compressed tarball of .ii files Adding .ii files as a compressed tarball [mockbuild@localhost 104]$ ls -l *.ii -rw-rw-r--. 1 mockbuild mockbuild 277580 Jan 8 12:48 common.ii -rw-rw-r--. 1 mockbuild mockbuild 475863 Jan 8 12:48 lib.ii -rw-rw-r--. 1 mockbuild mockbuild 515859 Jan 8 12:48 main.ii -rw-rw-r--. 1 mockbuild mockbuild 475991 Jan 8 12:48 module.ii
[Bug rtl-optimization/55845] [4.8 Regression] 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 #11 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-08 18:00:30 UTC --- Author: jakub Date: Tue Jan 8 18:00:10 2013 New Revision: 195028 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195028 Log: PR rtl-optimization/55845 * df-problems.c (can_move_insns_across): Stop scanning at volatile_insn_p source instruction or give up if across_from .. across_to range contains any volatile_insn_p instructions. * gcc.target/i386/pr55845.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr55845.c Modified: trunk/gcc/ChangeLog trunk/gcc/df-problems.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/55845] [4.8 Regression] 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 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||jakub at gcc dot gnu.org Resolution||FIXED --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-08 18:03:48 UTC --- Fixed.
[Bug pch/54117] [4.8 Regression] FAIL: ./decl-3.h -O0 -g (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54117 --- Comment #11 from stevenb.gcc at gmail dot com stevenb.gcc at gmail dot com 2013-01-08 18:04:09 UTC --- All that to avoid one #include output.h in one file? Is that one little thing really the only change you see? I see a different picture. The change is a major step in the direction of making a clear cut between the middle/back end and the front ends. A front end should not output assembly, period, if we want the front ends to become separate libraries, in the long run, that can be used by external tools (static checkers, IDEs, etc.) like clang. For the long term, this is IMHO the only viable solution for keeping the GCC front ends relevant. The change also allows the compiler to open the assembler file in write-only mode and to open it only after the front end is done. My plan is to postponed it even further: for GCC 4.9 I'd like to work on streaming slim LTO objects directly to a .o file, without going through an assembler file at all (this is relatively simple for ELF targets). Finally, the change also simplifies the PCH mechanism further. If we're ever going to replace PCH-as-a-memory-dump with something streamed, we'll have to make an effort at only streaming IR objects, not assembler output. Had I known this change would break stabs like this, I'd obviously have tried to solve that problem first. But to back out the change now would be a mistake. Nobody is going to fix those *out.c back ends, as you very well know.
[Bug c++/55910] One of instances generated for a method with -O3 uses incorrect parameter cleanup size with 'ret'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55910 --- Comment #5 from Oleh Derevenko oder at eleks dot lviv.ua 2013-01-08 18:11:42 UTC --- IMHO, I've localized the issue clearly enough. The code that generates instances for methods may sometimes consider some of those instances as having no parameters in method instance itself and as having some nonzero size of parameters (namely 0x38) in caller that re-adjusts stack after method instance has cleared the parameters. If those numbers would be taken from single variable that kind of bug would be impossible. So please examine the code and see where do you get total parameter size for 'ret' instruction from and where do you get total parameter size for stack re-adjustment from. And then please try to realize why those locations could possibly have different numbers in them.
[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 #6 from Martin Jambor jamborm at gcc dot gnu.org 2013-01-08 18:16:24 UTC --- Created attachment 29111 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29111 Untested fix I'm currently bootstrapping and testing this patch to fix the issue on trunk.
[Bug tree-optimization/43716] [4.6/4.7/4.8 Regression] Revision 158105 miscompiles doduc.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME --- Comment #46 from Dominique d'Humieres dominiq at lps dot ens.fr 2013-01-08 18:25:29 UTC --- Let me close this PR as WORKSFORME. If the problem resurface, please open a new PR.
[Bug lto/55902] lto1 SIGSEGV
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55902 --- Comment #5 from Václav Zeman vhaisman at gmail dot com 2013-01-08 18:26:47 UTC --- (In reply to comment #3) Does it only reproduce with -flto-partition=none? Yes. Changing either the LTO partitioning algorithm or adding -r or -nostdlib makes the error go away.
[Bug tree-optimization/55875] [4.8 Regression] IVopts caused miscompilation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55875 --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-08 18:27:44 UTC --- FYI, the execute/pr55875.c with -O1 started failing with http://gcc.gnu.org/viewcvs?root=gccview=revrev=138207 aka tuples merge.
[Bug libstdc++/55909] libtool test exposes what I think is some alignment issue in libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55909 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2013-01-08 18:45:14 UTC --- Per the bug submitting instructions we need a *single* self-contained *.ii
[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 jason at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #13 from Jason Merrill jason at gcc dot gnu.org 2013-01-08 18:56:58 UTC --- Bug #2 fixed.
[Bug libstdc++/55909] libtool test exposes what I think is some alignment issue in libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55909 philip.copeland at oracle dot com changed: What|Removed |Added Attachment #29110|0 |1 is obsolete|| --- Comment #4 from philip.copeland at oracle dot com 2013-01-08 19:00:54 UTC --- Created attachment 29112 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29112 main.ii SINGLE .ii I originally provided all the .ii's produced by the libtool compilation as I thought it may have been relevant
[Bug tree-optimization/43716] [4.6/4.7/4.8 Regression] Revision 158105 miscompiles doduc.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716 --- Comment #47 from Uros Bizjak ubizjak at gmail dot com 2013-01-08 19:23:41 UTC --- (In reply to comment #44) Can't reproduce on x86_64-linux with current trunk at -O3 -g -ffast-math, both with LRA and when LRA is disabled. From what I understood, this bug used to be present on darwin, but went away two years ago, then it got reopened for x86_64-linux in July and apparently doesn't reproduce anymore either. So, is this broken anywhere now? Sorry for late answer, the NaN is still generated with current mainline, as can be proved with: -g -O3 -ffast-math -ffpe-trap=invalid $ ./a.out MAIN : FIN S2 MAIN : FIN S1 MAIN : FIN S00011 MAIN : FIN S00022 Program received signal SIGFPE: Floating-point exception - erroneous arithmetic operation. Backtrace for this error: #0 0x7F9A9AF66FD7 #1 0x7F9A9AF675A4 #2 0x346B2359AF #3 0x40AAA6 in s00017_ at doduc.f90:1852 #4 0x41B9E9 in MAIN__ at doduc.f90:186 Floating point exception *However*, --ffast-math implies -fno-signaling-nans, and this contradicts with -ffpe-trap=invalid. Going a bit further: -g -O3 -ffast-math -fsignaling-nans -ffpe-trap=invalid works as expected, without FP exceptions. So, as far as I'm concerned, --fast-math -ffpe-trap=invalid combination of options (and the whole issue with NaNs on x86_64 as dubiously raised in comment #34) is invalid.
[Bug c++/55879] [C++11] nested constexpr Initialisation raises internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55879 --- Comment #2 from npl at chello dot at 2013-01-08 19:30:29 UTC --- (In reply to comment #1) The problem also occurs for gcc 4.8.0 20121209 (experimental). Let me remark that according to C++11 the variable s_Memmap could not be used in constant expressions, because it contains an (effective) reinterpret_cast, which is not allowed in this context. If I understand you right, then you mean that the s_Memmap is not an constexpr array. As far as I understand this is not an issue that schould prevent compiling - I believe constexpr arrays are valid and different to const arrays? The former should not compile with this initializer. Also this variable is an linkervariable in my project, and I dont think gcc could constexpr it... even if I might be able to do away with the cast with something like extern C const unsigned _lnkDDRRAM[]; btw here is my error output for 4.7.2: nestedconstexpr.cpp:35:1: in constexpr expansion of ‘CNested(CAddress(1107296256u))’ nestedconstexpr.cpp:22:26: in constexpr expansion of ‘((CNested*)this)-CNested::m_PrimaryBlock.CAddress::CAddress((* primary))’ nestedconstexpr.cpp:35:1: internal compiler error: in cxx_eval_indirect_ref, at cp/semantics.c:7435
[Bug c++/55893] [4.7/4.8 Regression][C++11] runtime segfault with static const object with virtual destructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55893 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org |
[Bug fortran/45836] [OOP] Type Bound Procedure Error - Type Mismatch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45836 --- Comment #4 from Mikael Morin mikael at gcc dot gnu.org 2013-01-08 19:42:49 UTC --- Author: mikael Date: Tue Jan 8 19:42:38 2013 New Revision: 195031 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195031 Log: PR fortran/42769 PR fortran/45836 PR fortran/45900 * module.c (read_module): Don't reuse local symtree if the associated symbol isn't exactly the one wanted. Don't reuse local symtree if it is ambiguous. * resolve.c (resolve_call): Use symtree's name instead of symbol's to lookup the symtree. PR fortran/42769 PR fortran/45836 PR fortran/45900 * gfortran.dg/use_23.f90: New test. * gfortran.dg/use_24.f90: New test. * gfortran.dg/use_25.f90: New test. * gfortran.dg/use_26.f90: New test. * gfortran.dg/use_27.f90: New test. Added: branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/use_23.f90 branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/use_24.f90 branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/use_25.f90 branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/use_26.f90 branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/use_27.f90 Modified: branches/gcc-4_7-branch/gcc/fortran/ChangeLog branches/gcc-4_7-branch/gcc/fortran/module.c branches/gcc-4_7-branch/gcc/fortran/resolve.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug fortran/45900] [OOP] Static TBP resolved incorrectly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45900 --- Comment #5 from Mikael Morin mikael at gcc dot gnu.org 2013-01-08 19:42:50 UTC --- Author: mikael Date: Tue Jan 8 19:42:38 2013 New Revision: 195031 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195031 Log: PR fortran/42769 PR fortran/45836 PR fortran/45900 * module.c (read_module): Don't reuse local symtree if the associated symbol isn't exactly the one wanted. Don't reuse local symtree if it is ambiguous. * resolve.c (resolve_call): Use symtree's name instead of symbol's to lookup the symtree. PR fortran/42769 PR fortran/45836 PR fortran/45900 * gfortran.dg/use_23.f90: New test. * gfortran.dg/use_24.f90: New test. * gfortran.dg/use_25.f90: New test. * gfortran.dg/use_26.f90: New test. * gfortran.dg/use_27.f90: New test. Added: branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/use_23.f90 branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/use_24.f90 branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/use_25.f90 branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/use_26.f90 branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/use_27.f90 Modified: branches/gcc-4_7-branch/gcc/fortran/ChangeLog branches/gcc-4_7-branch/gcc/fortran/module.c branches/gcc-4_7-branch/gcc/fortran/resolve.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug fortran/42769] [OOP] ICE in resolve_typebound_procedure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769 --- Comment #37 from Mikael Morin mikael at gcc dot gnu.org 2013-01-08 19:42:47 UTC --- Author: mikael Date: Tue Jan 8 19:42:38 2013 New Revision: 195031 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195031 Log: PR fortran/42769 PR fortran/45836 PR fortran/45900 * module.c (read_module): Don't reuse local symtree if the associated symbol isn't exactly the one wanted. Don't reuse local symtree if it is ambiguous. * resolve.c (resolve_call): Use symtree's name instead of symbol's to lookup the symtree. PR fortran/42769 PR fortran/45836 PR fortran/45900 * gfortran.dg/use_23.f90: New test. * gfortran.dg/use_24.f90: New test. * gfortran.dg/use_25.f90: New test. * gfortran.dg/use_26.f90: New test. * gfortran.dg/use_27.f90: New test. Added: branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/use_23.f90 branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/use_24.f90 branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/use_25.f90 branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/use_26.f90 branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/use_27.f90 Modified: branches/gcc-4_7-branch/gcc/fortran/ChangeLog branches/gcc-4_7-branch/gcc/fortran/module.c branches/gcc-4_7-branch/gcc/fortran/resolve.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/43716] [4.6/4.7/4.8 Regression] Revision 158105 miscompiles doduc.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716 --- Comment #48 from Dominique d'Humieres dominiq at lps dot ens.fr 2013-01-08 19:52:39 UTC --- From comment #40: with -ffast-math, so for example if (x != 0) tem = y / x; else tem = 0.; ... do sth with tem ... will execute y / x unconditionally based on the fact that it cannot trap. This optimization generates an exception trapped when using -ffpe-trap=invalid along with -ffast-math. This unfortunately prevents any debugging based -ffpe-trap=invalid for miscompilations occurring with -ffast-math. One thing I hope, though I am not sure about it, is that the above block is still compiled as tem=y/x if (x==0) tem=0. My original report was for '-O3 -funsafe-math-optimizations -ffinite-math-only' without -ffpe-trap=invalid. The segmentation fault resulted from the fact that some variables were used to access a table and were out of bound when the miscompilation generated some NAN (see comment #13).
[Bug fortran/45900] [OOP] Static TBP resolved incorrectly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45900 --- Comment #6 from Mikael Morin mikael at gcc dot gnu.org 2013-01-08 20:01:59 UTC --- Author: mikael Date: Tue Jan 8 20:01:49 2013 New Revision: 195032 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195032 Log: PR fortran/42769 PR fortran/45836 PR fortran/45900 * module.c (read_module): Don't reuse local symtree if the associated symbol isn't exactly the one wanted. Don't reuse local symtree if it is ambiguous. * resolve.c (resolve_call): Use symtree's name instead of symbol's to lookup the symtree. PR fortran/42769 PR fortran/45836 PR fortran/45900 * gfortran.dg/use_23.f90: New test. * gfortran.dg/use_24.f90: New test. * gfortran.dg/use_25.f90: New test. * gfortran.dg/use_26.f90: New test. * gfortran.dg/use_27.f90: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/use_23.f90 branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/use_24.f90 branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/use_25.f90 branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/use_26.f90 branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/use_27.f90 Modified: branches/gcc-4_6-branch/gcc/fortran/ChangeLog branches/gcc-4_6-branch/gcc/fortran/module.c branches/gcc-4_6-branch/gcc/fortran/resolve.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug fortran/45836] [OOP] Type Bound Procedure Error - Type Mismatch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45836 --- Comment #5 from Mikael Morin mikael at gcc dot gnu.org 2013-01-08 20:02:01 UTC --- Author: mikael Date: Tue Jan 8 20:01:49 2013 New Revision: 195032 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195032 Log: PR fortran/42769 PR fortran/45836 PR fortran/45900 * module.c (read_module): Don't reuse local symtree if the associated symbol isn't exactly the one wanted. Don't reuse local symtree if it is ambiguous. * resolve.c (resolve_call): Use symtree's name instead of symbol's to lookup the symtree. PR fortran/42769 PR fortran/45836 PR fortran/45900 * gfortran.dg/use_23.f90: New test. * gfortran.dg/use_24.f90: New test. * gfortran.dg/use_25.f90: New test. * gfortran.dg/use_26.f90: New test. * gfortran.dg/use_27.f90: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/use_23.f90 branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/use_24.f90 branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/use_25.f90 branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/use_26.f90 branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/use_27.f90 Modified: branches/gcc-4_6-branch/gcc/fortran/ChangeLog branches/gcc-4_6-branch/gcc/fortran/module.c branches/gcc-4_6-branch/gcc/fortran/resolve.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
