[Bug middle-end/61010] ICE in gcc.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61010 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Seems to have started with r187280.
[Bug c/60351] Incorrect column number for warning on right shift count is negative
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60351 --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Wed Apr 30 06:08:17 2014 New Revision: 209925 URL: http://gcc.gnu.org/viewcvs?rev=209925root=gccview=rev Log: PR c/60351 * c-typeck.c (build_binary_op): Use location when warning about shift count. * gcc.dg/pr60351.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr60351.c Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-typeck.c trunk/gcc/testsuite/ChangeLog
[Bug c/60351] Incorrect column number for warning on right shift count is negative
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60351 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- Fixed.
[Bug c/60139] Imprecise column number for -pedantic on non-computable initializer element
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60139 --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Wed Apr 30 06:14:39 2014 New Revision: 209926 URL: http://gcc.gnu.org/viewcvs?rev=209926root=gccview=rev Log: PR c/60139 * c-typeck.c (output_init_element): Pass OPT_Wpedantic to pedwarn and pedwarn_init. Use loc insted of input_location. * gcc.dg/pr60139.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr60139.c Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-typeck.c trunk/gcc/testsuite/ChangeLog
[Bug c/60139] Imprecise column number for -pedantic on non-computable initializer element
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60139 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- Fixed.
[Bug c/60915] confusing diagnostic from attribute on function definition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60915 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-04-30 Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |4.10.0 Ever confirmed|0 |1 --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- So mine.
[Bug c/59169] TLS definition in xxxtal.so section .tbss mismatches non-TLS definition in libclntsh.so .bss section
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59169 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- Feedback not coming.
[Bug c/48546] lto-wrapper returned 1 exit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48546 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |INVALID --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- Nothing to do.
[Bug c/43488] Get compiler internal error with DFP expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43488 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED Known to fail|| --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org --- This seems to work fine with 4.7 and newer.
[Bug c++/61004] [4.10 Regression] Spurious warning: dereferencing type-punned pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61004 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Huh. I'll have a look - nice to have a testcase.
[Bug ipa/60965] [4.10 Regression] IPA: Devirtualization versus placement new
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60965 --- Comment #5 from Andrew Haley aph at gcc dot gnu.org --- Jan, can we please have an ETA to fix this? It is a very importantant problem for Java because it breaks OpenJDK.
[Bug middle-end/61010] ICE in gcc.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61010 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org --- Comment #3 from ktkachov at gcc dot gnu.org --- Looks like a manifestation of PR 58088
[Bug middle-end/61010] ICE in gcc.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61010
--- Comment #4 from ktkachov at gcc dot gnu.org ---
Hmmm...
int main (void)
{
int a = 0;
unsigned b = (a * 64 192) | 63;
return 0;
}
works (i.e. 63 without the U).
I suspect there's something dodgy with the implementation of
mask_with_tz (tree type, double_int x, double_int y) in fold-const.c that I
added with r202652.
Interestingly, the wide-int branch that rewrites that function to use the new
wide-int interface makes this ICE go away.
[Bug middle-end/61010] [4.8/4.9/4.10 Regression] Infinite recursion in fold
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61010 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||4.7.3 Target Milestone|--- |4.8.3 Summary|ICE in gcc.c|[4.8/4.9/4.10 Regression] ||Infinite recursion in fold
[Bug libgcc/61003] [4.9/4.10 Regression] Segfault in __deregister_frame_info_bases when exiting, on i686-mingw32 with dw2 unwinding
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61003 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.1 Summary|[4.9 Regression] Segfault |[4.9/4.10 Regression] |in |Segfault in |__deregister_frame_info_bas |__deregister_frame_info_bas |es when exiting, on |es when exiting, on |i686-mingw32 with dw2 |i686-mingw32 with dw2 |unwinding |unwinding
[Bug tree-optimization/48329] Missed vectorization of reduction due to PRE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48329 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- This seems to have been fixed during the 4.7 revisions: I see the problem with 4.6.4, but not with 4.7.3 or higher.
[Bug c++/61004] [4.10 Regression] Spurious warning: dereferencing type-punned pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61004 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- B doesn't have a FIELD_DECL for its base A, not sure why. If we make A non-empty we get f ((const struct A ) (const struct A *) b.D.2231) with empty A (and no field for it) we get f ((const struct A ) (const struct A *) b) I suppose this is to avoid having two fields at the same offset if we make B not empty. Now, that we don't record the alias-set of A as subset of that of B isn't a problem in practice but for the (IMHO completely bogus) implementation of our strict-aliasing warnings.
[Bug target/42159] unwinding issues on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42159 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|NEW |WAITING --- Comment #24 from Dominique d'Humieres dominiq at lps dot ens.fr --- Is this PR still present?
[Bug c++/61004] [4.10 Regression] Spurious warning: dereferencing type-punned pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61004 --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org --- Created attachment 32713 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32713action=edit untested patch
[Bug lto/60964] boost = 1.54 failes to compile with LTO enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60964 Steffen Hau steffen at hauihau dot de changed: What|Removed |Added URL||https://svn.boost.org/trac/ ||boost/ticket/9766 --- Comment #3 from Steffen Hau steffen at hauihau dot de --- I can confirm that replaceing -march=native with -march=corei7-avx solves the issue and boost compiles fine afterwards. Is a testcase still needed? I have no idea how to strip down the affected boost module to reproduce the issue. The developer is not able to reproduce the but he had another idea with adding target attributes to some functions to give gcc some hints. I'll try to compile boost with his patch and march=native to see if that helps. I've added the boost bug as reference.
[Bug middle-end/61010] [4.8/4.9/4.10 Regression] Infinite recursion in fold
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61010 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Indeed we iterate in /* Canonicalize (X C1) | C2. */ because we fold (unsigned int) (a * 64) 255 to (unsigned int) (a * 64) 192 in /* Fold (X * CST1) CST2 to zero if we can, or drop known zero bits from CST2. */ The iterating input is ((unsigned int) (a * 64) 192) | 63 where it seems to fail to Minimize the number of bits set in C1 because it hits the unless case. One option is to apply the same unless case to the drop known zero bits BIT_AND_EXPR folding.
[Bug lto/60964] boost = 1.54 failes to compile with LTO enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60964 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to Steffen Hau from comment #3) I can confirm that replaceing -march=native with -march=corei7-avx solves the issue and boost compiles fine afterwards. Is a testcase still needed? I have no idea how to strip down the affected boost module to reproduce the issue. The developer is not able to reproduce the but he had another idea with adding target attributes to some functions to give gcc some hints. I'll try to compile boost with his patch and march=native to see if that helps. I've added the boost bug as reference. Lets assume that it is a dup. *** This bug has been marked as a duplicate of bug 60607 ***
[Bug target/60607] -march=native command line option handling breaks LTO option machinery
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60607 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added CC||steffen at hauihau dot de --- Comment #3 from Markus Trippelsdorf trippels at gcc dot gnu.org --- *** Bug 60964 has been marked as a duplicate of this bug. ***
[Bug middle-end/61010] [4.8/4.9/4.10 Regression] Infinite recursion in fold
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61010 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org --- /* If X is a tree of the form (Y * K1) K2, this might conflict with that optimization from the BIT_AND_EXPR optimizations. This could end up in an infinite recursion. */ doesn't trigger because we have an intermediate cast to unsigned (which is dropped) around the multiplication. rev. 130635 which introduced that limitation on reducing the number of bits suggests that we want to apply the same heuristic to the BIT_AND_EXPR folding. Jakub, any opinion?
[Bug libstdc++/61011] New: libstdc++-v3 should be target-libstdc++-v3 in top level configure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61011
Bug ID: 61011
Summary: libstdc++-v3 should be target-libstdc++-v3 in top
level configure
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: pierre.labastie at neuf dot fr
When passing --disable-libstdcxx to top level configure the following code is
executed:
if test ${ENABLE_LIBSTDCXX} = no ; then
noconfigdirs=$noconfigdirs libstdc++-v3
fi
This does not have the desired effect, since make still tries to build the
target libstdc++.
The above code should be changed to:
if test ${ENABLE_LIBSTDCXX} = no ; then
noconfigdirs=$noconfigdirs target-libstdc++-v3
fi
Thanks
[Bug middle-end/61010] [4.8/4.9/4.10 Regression] Infinite recursion in fold
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61010 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org --- Mine.
[Bug middle-end/61010] [4.8/4.9/4.10 Regression] Infinite recursion in fold
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61010
--- Comment #7 from Richard Biener rguenth at gcc dot gnu.org ---
Like
Index: gcc/fold-const.c
===
--- gcc/fold-const.c(revision 209928)
+++ gcc/fold-const.c(working copy)
@@ -11426,7 +11426,6 @@ fold_binary_loc (location_t loc,
{
double_int c1, c2, c3, msk;
int width = TYPE_PRECISION (type), w;
- bool try_simplify = true;
c1 = tree_to_double_int (TREE_OPERAND (arg0, 1));
c2 = tree_to_double_int (arg1);
@@ -11463,20 +11462,7 @@ fold_binary_loc (location_t loc,
}
}
- /* If X is a tree of the form (Y * K1) K2, this might conflict
-with that optimization from the BIT_AND_EXPR optimizations.
-This could end up in an infinite recursion. */
- if (TREE_CODE (TREE_OPERAND (arg0, 0)) == MULT_EXPR
- TREE_CODE (TREE_OPERAND (TREE_OPERAND (arg0, 0), 1))
- == INTEGER_CST)
- {
- tree t = TREE_OPERAND (TREE_OPERAND (arg0, 0), 1);
- double_int masked = mask_with_tz (type, c3, tree_to_double_int
(t));
-
- try_simplify = (masked != c1);
- }
-
- if (try_simplify c3 != c1)
+ if (c3 != c1)
return fold_build2_loc (loc, BIT_IOR_EXPR, type,
fold_build2_loc (loc, BIT_AND_EXPR, type,
TREE_OPERAND (arg0, 0),
@@ -11866,16 +11852,25 @@ fold_binary_loc (location_t loc,
TREE_CODE (arg0) == MULT_EXPR
TREE_CODE (TREE_OPERAND (arg0, 1)) == INTEGER_CST)
{
+ double_int darg1 = tree_to_double_int (arg1);
double_int masked
- = mask_with_tz (type, tree_to_double_int (arg1),
+ = mask_with_tz (type, darg1,
tree_to_double_int (TREE_OPERAND (arg0, 1)));
if (masked.is_zero ())
return omit_two_operands_loc (loc, type, build_zero_cst (type),
arg0, arg1);
- else if (masked != tree_to_double_int (arg1))
- return fold_build2_loc (loc, code, type, op0,
- double_int_to_tree (type, masked));
+ else if (masked != darg1)
+ {
+ /* Avoid the transform if arg1 is a mask of some
+mode which allows further optimizations. */
+ int pop = darg1.popcount ();
+ if (!(pop = BITS_PER_UNIT
+ exact_log2 (pop) != -1
+ double_int::mask (pop) == darg1))
+ return fold_build2_loc (loc, code, type, op0,
+ double_int_to_tree (type, masked));
+ }
}
/* For constants M and N, if M == (1LL cst) - 1 (N M) == M,
[Bug tree-optimization/61000] No loop interchange for inner loop along the slow index
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61000 --- Comment #2 from Mircea Namolaru mircea.namolaru at inria dot fr --- Again, the problem is due to representation of arrays in Fortran as array with a single dimnesion (for similar code in C profitability check work as expected). It is a recurring problem that may lead to compilation time increase (sometimes dramatically) or missed opportunities optimizations due to too conservative dependence analysis or as on this case the profitability check failure. The solution is to de-liniarize array accesses in Fortran as in C.
[Bug tree-optimization/61000] No loop interchange for inner loop along the slow index
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61000 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to Mircea Namolaru from comment #2) Again, the problem is due to representation of arrays in Fortran as array with a single dimnesion (for similar code in C profitability check work as expected). It is a recurring problem that may lead to compilation time increase (sometimes dramatically) or missed opportunities optimizations due to too conservative dependence analysis or as on this case the profitability check failure. The solution is to de-liniarize array accesses in Fortran as in C. Note that C doesn't always have de-linearized arrays (once you access the array via a pointer). For Fortran de-linearizing is easy via simple casting to a multi-dimensional (variable-bounds) array type. For the middle-end side, that is.
[Bug c++/61012] New: lto1: errors during merging of translation units (error: variable ‘link’ redeclared as function)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61012
Bug ID: 61012
Summary: lto1: errors during merging of translation units
(error: variable ‘link’ redeclared as function)
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mliska at suse dot cz
$ cat a.c
struct s
{
int a;
int b;
};
static struct s link = { 1, 2 };
int foo()
{
return link.a;
}
$ cat b.c
#include unistd.h
int main()
{
int r = link(aaa, bbb);
return foo();
}
$ gcc a.c b.c -flto -O2
/usr/include/unistd.h:812:12: error: variable ‘link’ redeclared as function
extern int link (const char *__from, const char *__to)
^
a.c:7:17: note: previously declared here
static struct s link = { 1, 2 };
^
lto1: fatal error: errors during merging of translation units
compilation terminated.
lto-wrapper: gcc returned 1 exit status
/home/marxin/Programming/bin/gcc2/lib64/gcc/x86_64-unknown-linux-gnu/4.10.0/../../../../x86_64-unknown-linux-gnu/bin/ld:
fatal error: lto-wrapper failed
collect2: error: ld returned 1 exit status
[Bug tree-optimization/61000] No loop interchange for inner loop along the slow index
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61000 --- Comment #4 from Mircea Namolaru mircea.namolaru at inria dot fr --- Right, C arrays expressed as pointers suffers from the same problem. But for C at least there is a way to avoid this. Many thanks for your suggestion of how to de-linearize arrays in middle-end, it seems that may be simpler then I've thought. Hope to find time and wrote a patch based on your idea for GCC 4.10. Mircea - Original Message - From: rguenth at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org To: mircea namolaru mircea.namol...@inria.fr Sent: Wednesday, April 30, 2014 1:02:10 PM Subject: [Bug tree-optimization/61000] No loop interchange for inner loop along the slow index http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61000 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to Mircea Namolaru from comment #2) Again, the problem is due to representation of arrays in Fortran as array with a single dimnesion (for similar code in C profitability check work as expected). It is a recurring problem that may lead to compilation time increase (sometimes dramatically) or missed opportunities optimizations due to too conservative dependence analysis or as on this case the profitability check failure. The solution is to de-liniarize array accesses in Fortran as in C. Note that C doesn't always have de-linearized arrays (once you access the array via a pointer). For Fortran de-linearizing is easy via simple casting to a multi-dimensional (variable-bounds) array type. For the middle-end side, that is. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debug/61013] New: Option parsing difference between 4.9 and 4.9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61013 Bug ID: 61013 Summary: Option parsing difference between 4.9 and 4.9 Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: andres at anarazel dot de In gcc 4.8 a binary compiled with gcc -g3 ... -g would include the extended debug information (e.g. macros), while in gcc 4.9 the second -g seems to lower the debug level. That's obviously not a critical issue, but it's annoying enough because several buildsystems add -g internally, often after the user supplied CFLAGS, making it harder to build with a sufficient amount of debuginfo.
[Bug tree-optimization/48329] Missed vectorization of reduction due to PRE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48329 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.7.0 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Indeed.
[Bug c++/61004] [4.10 Regression] Spurious warning: dereferencing type-punned pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61004 --- Comment #7 from Lars Gullik Bjønnes larsbj at gullik dot net --- (In reply to Richard Biener from comment #6) Created attachment 32713 [details] untested patch This fixes the problem for me, in my application.
[Bug tree-optimization/48329] Missed vectorization of reduction due to PRE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48329 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Wed Apr 30 11:43:41 2014 New Revision: 209930 URL: http://gcc.gnu.org/viewcvs?rev=209930root=gccview=rev Log: 2014-04-30 Richard Biener rguent...@suse.de PR tree-optimization/48329 * gfortran.dg/vect/pr48329.f90: New testcase. Added: trunk/gcc/testsuite/gfortran.dg/vect/pr48329.f90 Modified: trunk/gcc/testsuite/ChangeLog
[Bug lto/61012] [4.9/4.10 Regression] lto1: errors during merging of translation units (error: variable ‘link’ redeclared as function)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61012 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||lto, rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2014-04-30 Component|c++ |lto Target Milestone|--- |4.9.1 Summary|lto1: errors during merging |[4.9/4.10 Regression] lto1: |of translation units|errors during merging of |(error: variable ‘link’ |translation units (error: |redeclared as function) |variable ‘link’ redeclared ||as function) Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed. Probably caused by the delayed symbol renaming.
[Bug lto/61012] [4.9/4.10 Regression] lto1: errors during merging of translation units (error: variable ‘link’ redeclared as function)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61012
--- Comment #2 from Richard Biener rguenth at gcc dot gnu.org ---
Reduced b.c:
extern int link (const char *, const char *);
int main()
{
return foo() + link(foo, bar);
}
[Bug fortran/61014] New: [4.6/4.7/4.8/4.9 Regression] gdb can't find symbol of derived data type array in nested subroutine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61014 Bug ID: 61014 Summary: [4.6/4.7/4.8/4.9 Regression] gdb can't find symbol of derived data type array in nested subroutine Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: sven.buijssen at math dot uni-dortmund.de (I am not exactly sure whether gfortran or gdb are to blame for this issue, but I tend towards the former.) The following causes gdb 7.4 to report missing symbols in current context when compiled with recent gfortran versions: $ cat EOF debug.f90 program debug use module implicit none type(myint), dimension(1) :: bar call foo(bar) end program debug EOF $ cat EOF module.f90 module module implicit none type myint integer :: i = -1 end type myint contains subroutine foo(bar) type(myint), dimension(:) :: bar call subfoo() contains subroutine subfoo() bar(1)%i = 1 print *, bar(1)%i end subroutine subfoo end subroutine foo end module module EOF $ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/local/gcc/4.9.0/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.9.0/configure --prefix=/usr/local/gcc/4.9.0 --enable-languages=c,c++,fortran --disable-multilib Thread model: posix gcc version 4.9.0 (GCC) $ gfortran -O0 -g -fno-inline -Wall -Wextra -c module.f90 $ gfortran -O0 -g -fno-inline -Wall -Wextra -fno-lto debug.f90 module.o $ gdb --version GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04 Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-linux-gnu. For bug reporting instructions, please see: http://bugs.launchpad.net/gdb-linaro/. $ gdb a.out (gdb) break module.f90:10 Breakpoint 1 at 0x4007a0: file module.f90, line 10. (gdb) break module.f90:14 Breakpoint 2 at 0x400703: file module.f90, line 14. (gdb) run Starting program: /tmp/a.out Breakpoint 1, 0x004007a0 in __module_MOD_foo () (gdb) print bar(1)%i No symbol bar in current context. (gdb) cont Continuing. Breakpoint 2, 0x00400703 in subfoo.2335 () (gdb) print bar(1)%i No symbol bar in current context. # Dito with GCC 4.8.2. # With GCC 4.6.3 and 4.7.3 the respective results of the two print commands in gdb are: $1 = -1 value has been optimized out # Whereas with GCC 4.4.7 and GCC 4.5.4 the very same version of gdb is able to show the (expected) value of component i of the first entry of array bar at both breakpoints: $1 = -1 $2 = -1 $ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/local/gcc/4.5.4/libexec/gcc/x86_64-unknown-linux-gnu/4.5.4/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../configure --prefix=/usr/local/gcc/4.5.4 --enable-languages=c,c++,fortran --disable-multilib Thread model: posix gcc version 4.5.4 (GCC) ### With Intel Fortran 14.0.1.106 (aka XE 2013 SP1 Update 1) and its accompanying debugger one can query the value always: $ ifort -O0 -g -Warn all -c module.f90 $ ifort -O0 -g -Warn all -c debug.f90 $ ifort -O0 -g -Warn all debug.o module.o $ idbc a.out Intel(R) Debugger for applications running on Intel(R) 64, Version 13.0, Build [80.483.23] -- object file name: a.out Reading symbols from /tmp/a.out...done. (idb) break module.f90:10 Breakpoint 1 at 0x402ca5: file /tmp/module.f90, line 10. (idb) break module.f90:14 Breakpoint 2 at 0x402ce8: file /tmp/module.f90, line 14. (idb) run Starting program: /tmp/a.out [New Thread 23410 (LWP 23410)] Breakpoint 1, MODULE::foo (bar=(...)) at /tmp/module.f90:10 10 call subfoo() (idb) print bar(1)%i $1 = -1 (idb) cont Continuing. Breakpoint 2, subfoo () at /tmp/module.f90:14 14bar(1)%i = 1 (idb) print bar(1)%i $2 = -1 (idb) next 15print *, bar(1)%i (idb) print bar(1)%i $3 = 1
[Bug debug/61014] [4.7/4.8/4.9/4.10 Regression] gdb can't find symbol of derived data type array in nested subroutine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61014 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-04-30 Component|fortran |debug Known to work||4.5.4 Summary|[4.6/4.7/4.8/4.9|[4.7/4.8/4.9/4.10 |Regression] gdb can't find |Regression] gdb can't find |symbol of derived data type |symbol of derived data type |array in nested subroutine |array in nested subroutine Ever confirmed|0 |1 Known to fail||4.8.2 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- I get (gdb 7.7): Breakpoint 1, module::foo (bar=...) at module.f90:10 10 call subfoo() (gdb) p bar $1 = (( -1 )) (gdb) p bar(1)%i $2 = -1 (gdb) s module::subfoo () at module.f90:14 14bar(1)%i = 1 (gdb) p bar(1)%i value being subranged must be in memory (gdb) p bar $3 = optimized out seems that nested function lowering and debugging don't play well together. Confirmed that it works well with 4.5.x.
[Bug debug/61014] [4.7/4.8/4.9/4.10 Regression] gdb can't find symbol of derived data type array in nested subroutine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61014 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.4
[Bug c++/60081] Internal compiler error: Error reporting routines re-entered.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60081
--- Comment #4 from Stan Manilov stanislav.manilov at gmail dot com ---
Here is a simple way to reproduce the bug:
==
#include vector
#include memory
int main() {
std::vectorstd::unique_ptrint v;
std::unique_ptrint px(new int (1));
v.push_back(px);
}
==
There is a bug in the code: push_back tries to copy the given element by
default. This should return an error along the lines of Call to deleted copy
constructor of std::unique_ptr. Instead it gives ICE.
A solution to the bug in the code is to explicitly call std::move like so:
==
#include vector
#include memory
int main() {
std::vectorstd::unique_ptrint v;
std::unique_ptrint px(new int (1));
v.push_back(std::move(px));
}
==
[Bug fortran/43996] ICE in gfc_conv_array_initializer due to incomplete simplification of init expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43996 --- Comment #16 from Dominique d'Humieres dominiq at lps dot ens.fr --- The following patch fixes the ICE without reverting the fix for pr40472: --- ../_clean/gcc/fortran/simplify.c2014-04-27 12:52:10.0 +0200 +++ gcc/fortran/simplify.c2014-04-30 14:23:46.0 +0200 @@ -5939,7 +6021,8 @@ gfc_simplify_spread (gfc_expr *source, g else mpz_init_set_ui (size, 1); - if (mpz_get_si (size)*ncopies gfc_option.flag_max_array_constructor) + if (!gfc_init_expr_flag + mpz_get_si (size)*ncopies gfc_option.flag_max_array_constructor) return NULL; if (source-expr_type == EXPR_CONSTANT) Indeed compiling the test in comment 8 gives Error: The number of elements in the array constructor at (1) requires an increase of the allowed 65535 upper limit. See -fmax-array-constructor option even if , PARAMETER is removed in the line INTEGER, PARAMETER :: C(N, N) = MATMUL(A, B) IMO the fix for SPREAD should be extended to all the intrinsics allowed for initialization.
[Bug target/42159] unwinding issues on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42159 --- Comment #25 from Mike Jarvis michael at jarvis dot net --- The bug does not seem to be present with g++ 4.8.2 on OSX 10.9.2. I no longer have access to a 10.6 machine, so I cannot confirm whether it is fixed with 4.8 on that system.
[Bug target/42159] unwinding issues on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42159 --- Comment #26 from simon at pushface dot org --- (In reply to Dominique d'Humieres from comment #24) Is this PR still present? Not with g++ (or Ada) in 4.9.0 on Max OS X 10.9.2 (darwin13.1.0).
[Bug target/42159] unwinding issues on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42159 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #27 from Dominique d'Humieres dominiq at lps dot ens.fr --- The bug does not seem to be present with g++ 4.8.2 on OSX 10.9.2. I no longer have access to a 10.6 machine, so I cannot confirm whether it is fixed with 4.8 on that system. For the test in comment 0, I get CAUGHT on x86_64-apple-darwin10 down to 4.5.4 (with 4.4.7 the test aborts) and on powerpc-apple-darwin9 down to 4.4.7 (fink builds). So I am closing this PR as FIXED.
[Bug debug/61014] [4.7/4.8/4.9/4.10 Regression] gdb can't find symbol of derived data type array in nested subroutine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61014 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org --- (In reply to Sven Buijssen from comment #0) (I am not exactly sure whether gfortran or gdb are to blame for this issue, but I tend towards the former.) $ gfortran -O0 -g -fno-inline -Wall -Wextra -fno-lto debug.f90 module.o $ gdb --version $ ifort -O0 -g -Warn all debug.o module.o $ idbc a.out As you also have idb at hand: You could cross check whether the GCC/gfortran binary works with idbc - and the ifort binary with gdb. They both use the same debugging format (which can differ slightly between versions). subroutine foo(bar) type(myint), dimension(:) :: bar This line implies that gfortran uses array descriptors; those are not yet supported in GDB - except that some vendor's versions (e.g. Red Hat/Fedora and (open)SUSE have some basic support. There is an on-going effort to add arrays-descriptor support to GDB; the first step, the support of C99's varying-length arrays has been added a few weeks ago to the GDB trunk. The Fortran support is supposed to come next, but it still will take a couple of weeks. See also: https://github.com/intel-gdb/vla/branches - but the Fortran branch there is a bit outdated. However, ... (In reply to Richard Biener from comment #1) I get (gdb 7.7): ... seems that nested function lowering and debugging don't play well together. Confirmed that it works well with 4.5.x. The combination that it works with 4.5 and that also a SUSE-build of gdb shows the problem, makes it more likely that the problem lies elsewhere. (It might be still a combination of changed dwarf generation in GCC and incomplete GDB support.)
[Bug debug/61014] [4.7/4.8/4.9/4.10 Regression] gdb can't find symbol of derived data type array in nested subroutine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61014
--- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org ---
(In reply to Tobias Burnus from comment #2)
As you also have idb at hand
I now did it myself with gcc 4.10 and idbc 13.0. (I don't have ifort.)
Result:
In line 10, I get:
(idb) p bar
$3 = {i = -1}
but in line 14, I get:
`module::foo::subfoo () at /dev/shm/h4j.f90:14
14bar(1)%i = 1
(idb) p bar
Info: symbol bar is defined but not allocated (optimized away)
Thus, as Richard wrote:
seems that nested function lowering and debugging don't play well together.
[Bug libgcc/61003] [4.9/4.10 Regression] Segfault in __deregister_frame_info_bases when exiting, on i686-mingw32 with dw2 unwinding
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61003 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||ktietz at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Isn't this a dup of PR60830 and thus a binutils bug?
[Bug c++/60980] [4.9/4.10 Regression] ICE in build_special_member_call, at cp/call.c:7447
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60980 --- Comment #6 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Wed Apr 30 14:23:18 2014 New Revision: 209934 URL: http://gcc.gnu.org/viewcvs?rev=209934root=gccview=rev Log: PR c++/60980 * init.c (build_value_init): Don't try to call an array constructor. Added: trunk/gcc/testsuite/g++.dg/cpp0x/defaulted49.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/init.c
[Bug c++/60951] [4.9/4.10 Regression][C++11] ICE with braced-init-list assignment and constexpr constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60951 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Wed Apr 30 14:23:27 2014 New Revision: 209935 URL: http://gcc.gnu.org/viewcvs?rev=209935root=gccview=rev Log: PR c++/60951 * typeck2.c (massage_init_elt): Use maybe_constant_init. Added: branches/gcc-4_9-branch/gcc/testsuite/g++.dg/cpp0x/constexpr-aggr1.C Modified: branches/gcc-4_9-branch/gcc/cp/ChangeLog branches/gcc-4_9-branch/gcc/cp/typeck2.c
[Bug c++/60951] [4.9/4.10 Regression][C++11] ICE with braced-init-list assignment and constexpr constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60951 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Wed Apr 30 14:23:11 2014 New Revision: 209933 URL: http://gcc.gnu.org/viewcvs?rev=209933root=gccview=rev Log: PR c++/60951 * typeck2.c (massage_init_elt): Use maybe_constant_init. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-aggr1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck2.c
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added CC||fanael4 at gmail dot com --- Comment #47 from Kai Tietz ktietz at gcc dot gnu.org --- *** Bug 61003 has been marked as a duplicate of this bug. ***
[Bug libgcc/61003] [4.9/4.10 Regression] Segfault in __deregister_frame_info_bases when exiting, on i686-mingw32 with dw2 unwinding
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61003 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Kai Tietz ktietz at gcc dot gnu.org --- It is a duplicate of PR60830. It is a pe-coff bug concerning weak-definitions. *** This bug has been marked as a duplicate of bug 60830 ***
[Bug c++/60951] [4.9/4.10 Regression][C++11] ICE with braced-init-list assignment and constexpr constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60951 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jason Merrill jason at gcc dot gnu.org --- Fixed for 4.9.1.
[Bug other/61016] New: use of uninitialized memory in gcc/config/i386/i386.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61016
Bug ID: 61016
Summary: use of uninitialized memory in gcc/config/i386/i386.c
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: kcc at gcc dot gnu.org
CC: eugeni.stepanov at gmail dot com
Created attachment 32715
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32715action=edit
z.cc
This is revision 209930 on x86_64 Linux.
% valgrind --track-origins=yes gcc/cc1plus -quiet z.cc-O2 -o /dev/null
==12029== Conditional jump or move depends on uninitialised value(s)
==12029==at 0xDBEF66: classify_argument(machine_mode, tree_node const*,
x86_64_reg_class*, int) (gcc/config/i386/i386.c:6361)
==12029==by 0xDBF2D4: classify_argument(machine_mode, tree_node const*,
x86_64_reg_class*, int) (gcc/config/i386/i386.c:6501)
==12029==by 0xDBA097: ix86_function_arg_advance(cumulative_args_t,
machine_mode, tree_node const*, bool) (gcc/config/i386/i386.c:6818)
==12029==by 0x92B40A: gimplify_parameters() (gcc/function.c:3624)
==12029==by 0x978AEA: gimplify_body(tree_node*, bool) (gcc/gimplify.c:8620)
==12029==by 0x9794AC: gimplify_function_tree(tree_node*)
(gcc/gimplify.c:8777)
==12029==by 0x7EBC14: analyze_function(cgraph_node*) (gcc/cgraphunit.c:649)
==12029==by 0x7EECD2: analyze_functions() (gcc/cgraphunit.c:1017)
==12029==by 0x7EEACB: finalize_compilation_unit() (gcc/cgraphunit.c:2320)
==12029==by 0x5E67D3: cp_write_global_declarations() (gcc/cp/decl2.c:4619)
==12029==by 0xB19A20: compile_file() (gcc/toplev.c:562)
==12029==by 0xB197D7: toplev_main(int, char**) (gcc/toplev.c:1914)
==12029== Uninitialised value was created by a stack allocation
==12029==at 0xDBE920: classify_argument(machine_mode, tree_node const*,
x86_64_reg_class*, int) (gcc/config/i386/i386.c:6412)
The bug was initially detected by MemorySanitizer (which is a bit trickier to
use with gcc at the moment)
==5348== WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0x7f265400f64d in merge_classes(x86_64_reg_class, x86_64_reg_class)
gcc/config/i386/i386.c:6361
#1 0x7f265400f64d in classify_argument(machine_mode, tree_node const*,
x86_64_reg_class*, int) gcc/config/i386/i386.c:6557
#2 0x7f265400dbfa in classify_argument(machine_mode, tree_node const*,
x86_64_reg_class*, int) gcc/config/i386/i386.c:6501
#3 0x7f2653fef8fc in examine_argument(machine_mode, tree_node const*, int,
int*, int*) gcc/config/i386/i386.c:6817
#4 0x7f2653fef8fc in function_arg_advance_64(ix86_args*, machine_mode,
tree_node const*, long, bool) gcc/config/i386/i386.c:7199
#5 0x7f2653fef8fc in ix86_function_arg_advance(cumulative_args_t,
machine_mode, tree_node const*, bool) gcc/config/i386/i386.c:7253
#6 0x7f26523a1ae1 in gimplify_parameters() gcc/function.c:3624
#7 0x7f2652594737 in gimplify_body(tree_node*, bool) gcc/gimplify.c:8620
#8 0x7f2652598479 in gimplify_function_tree(tree_node*) gcc/gimplify.c:8777
#9 0x7f2651bee7db in analyze_function(cgraph_node*) gcc/cgraphunit.c:649
#10 0x7f2651c01aa1 in analyze_functions() gcc/cgraphunit.c:1017
#11 0x7f2651c01088 in finalize_compilation_unit() gcc/cgraphunit.c:2320
#12 0x7f2650f8da6e in cp_write_global_declarations() gcc/cp/decl2.c:4619
#13 0x7f2652fa249d in compile_file() gcc/toplev.c:562
#14 0x7f2652fa06ff in do_compile() gcc/toplev.c:1914
#15 0x7f2652fa06ff in toplev_main(int, char**) gcc/toplev.c:1990
#16 0x7f26552563b3 in main gcc/main.c:36
#17 0x7f264f30276c in __libc_start_main
/build/buildd/eglibc-2.15/csu/libc-start.c:226
#18 0x7f26509f8960 in _start
(/usr/local/google/ssd/msan-gcc/inst/libexec/gcc/x86_64-unknown-linux-gnu/4.10.0/cc1plus+0x2f4960)
Uninitialized value was created by an allocation of 'subclasses' in the stack
frame of function 'classify_argument(machine_mode, tree_node const*,
x86_64_reg_class*, int)'
#0 0x7f265400a310 in classify_argument(machine_mode, tree_node const*,
x86_64_reg_class*, int) gcc/config/i386/i386.c:6412
Confirmed by printf:
Index: gcc/config/i386/i386.c
===
--- gcc/config/i386/i386.c (revision 209930)
+++ gcc/config/i386/i386.c (working copy)
@@ -6428,6 +6428,7 @@
int i;
tree field;
enum x86_64_reg_class subclasses[MAX_CLASSES];
+ subclasses[1] = (enum x86_64_reg_class)0xab;
/* On x86-64 we pass structures larger than 64 bytes on the stack. */
if (bytes 64)
@@ -6553,8 +6554,10 @@
bit_offset);
if (!num)
return 0;
- for (i = 0; i num; i++)
+ for (i = 0; i num; i++) {
+fprintf(stderr, ZZZ[%d] %x\n, i, classes[i]);
[Bug c++/60980] [4.9/4.10 Regression] ICE in build_special_member_call, at cp/call.c:7447
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60980 --- Comment #7 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Wed Apr 30 14:23:34 2014 New Revision: 209936 URL: http://gcc.gnu.org/viewcvs?rev=209936root=gccview=rev Log: PR c++/60980 * init.c (build_value_init): Don't try to call an array constructor. Added: branches/gcc-4_9-branch/gcc/testsuite/g++.dg/cpp0x/defaulted49.C Modified: branches/gcc-4_9-branch/gcc/cp/ChangeLog branches/gcc-4_9-branch/gcc/cp/init.c
[Bug c++/60980] [4.9/4.10 Regression] ICE in build_special_member_call, at cp/call.c:7447
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60980 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Jason Merrill jason at gcc dot gnu.org --- Fixed for 4.9.1.
[Bug debug/61013] Option parsing difference between 4.9 and 4.9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61013 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- -g is the same as -g2 and the later option is supposed to override the first one. Jus like how -O is handled.
[Bug debug/61013] Option parsing difference between 4.9 and 4.9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61013 --- Comment #2 from Andres Freund andres at anarazel dot de --- Hi, On 2014-04-30 14:54:20 +, pinskia at gcc dot gnu.org wrote: -g is the same as -g2 and the later option is supposed to override the first one. Jus like how -O is handled. The point is that this has changed between 4.8 and 4.9... And I don't see anything relevant in http://gcc.gnu.org/gcc-4.9/changes.html Greetings, Andres Freund
[Bug debug/61013] [4.9/4.10 Regression] Option parsing difference between 4.9 and 4.9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61013 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2014-04-30 CC||ccoutant at gcc dot gnu.org, ||jakub at gcc dot gnu.org Resolution|INVALID |--- Summary|Option parsing difference |[4.9/4.10 Regression] |between 4.9 and 4.9 |Option parsing difference ||between 4.9 and 4.9 Ever confirmed|0 |1 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- It has changed with r205235, and I think that part of the change is undesirable, -g never stood for -g2 before, it stood for enable debug info, at whatever level is default or has been previously selected.
[Bug c/7652] -Wswitch-break : Warn if a switch case falls through
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652 Michael Chapman michael.chapman at cortus dot com changed: What|Removed |Added CC||michael.chapman at cortus dot com --- Comment #21 from Michael Chapman michael.chapman at cortus dot com --- Created attachment 32716 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32716action=edit Proposed patch Patch to enable warnings (-Wswitch-fallthrough) when a switch case falls through. Enabled by -Wall.
[Bug debug/61013] [4.9/4.10 Regression] Option parsing difference between 4.9 and 4.9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61013 --- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org --- It was not on accident, see http://gcc.gnu.org/ml/gcc-patches/2013-02/msg00260.html and http://gcc.gnu.org/ml/gcc-patches/2011-04/msg02077.html And even where I said http://gcc.gnu.org/ml/gcc-patches/2011-04/msg02078.html This was all discussed on the list and there was no objections.
[Bug debug/61013] [4.9/4.10 Regression] Option parsing difference between 4.9 and 4.9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61013 --- Comment #5 from Andres Freund andres at anarazel dot de --- Hi, On 2014-04-30 15:48:33 +, pinskia at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61013 --- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org --- It was not on accident, see http://gcc.gnu.org/ml/gcc-patches/2013-02/msg00260.html and http://gcc.gnu.org/ml/gcc-patches/2011-04/msg02077.html And even where I said http://gcc.gnu.org/ml/gcc-patches/2011-04/msg02078.html This was all discussed on the list and there was no objections. Meh. At the very least you should document such changes in the release notes. I'd be surprised if I am the only one that wasted time on debugging this change. Greetings, Andres Freund
[Bug debug/61013] [4.9/4.10 Regression] Option parsing difference between 4.9 and 4.9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61013 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- I certainly haven't noticed that discussion, if I did, I would object already by that time.
[Bug c/7652] -Wswitch-break : Warn if a switch case falls through
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652
--- Comment #22 from Matthew Woehlke mw_triad at users dot sourceforge.net ---
Thanks for the patch. However, one thing I am not seeing is an easy way to
suppress the warning for a specific occurrence (a la [[clang:fallthrough]]).
Can that be added also? (Or is it there and I miss something?)
Ideally this would work like:
switch (expr)
{
case A:
// empty body, no warning
case B:
...
[[gcc:fallthrough]] // suppress warning for fall-through to 'case C'
case C:
...
break;
case D:
...
// will warn here
default:
...
break;
}
[Bug c/7652] -Wswitch-break : Warn if a switch case falls through
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652
--- Comment #23 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to Michael Chapman from comment #21)
Created attachment 32716 [details]
Proposed patch
Patch to enable warnings (-Wswitch-fallthrough) when a switch case falls
through. Enabled by -Wall.
Thanks! Patches need to be submitted to gcc-patc...@gcc.gnu.org with a
Changelog after bootstrapping and regression testing. The patch is missing a
testcase for the regression testsuite showing in which cases it should warn and
in which cases it should not. First of all, you need to have a copyright
assignment in place with the FSF. This is slightly annoying to do the first
time, but you only have to do it once for all GNU projects. See:
http://gcc.gnu.org/contribute.html
About the patch:
+int
+c_stmt_ends_with_goto (tree t)
This should return 'bool'
+{
+ if (TREE_CODE (t) == GOTO_EXPR)
+return TRUE;
+ if (TREE_CODE (t) == BIND_EXPR)
+return c_stmt_ends_with_goto (tsi_stmt (tsi_last (BIND_EXPR_BODY (t;
+ return FALSE;
+}
You can use 'true' and 'false'
+
+/* Handle -Wswitch-fallthrough */
+void
+c_do_switch_fallthru_warnings (tree body)
+{
+ tree_stmt_iterator i;
+ tree previous_stmt = NULL;
+ tree previous_label = NULL;
+ tree stmts = BIND_EXPR_BODY (body);
I think it would be worthwhile to add:
if (!warn_switch_fallthrough)
return;
to avoid going through the loop if we are not going to warn anyway.
+Wswitch-fallthrough
+C ObjC C++ ObjC++ Var(warn_switch_fallthrough) Warning LangEnabledBy(C ObjC
C++ ObjC++,Wall)
+Warn about switch cases which fall through to the next case
+
This says that the warning is available in C++, but I don't see any code in
your patch that calls the new function from the C++ FE.
It would be nice to have the same warning in C++. This will allow testing how
noisy it is in GCC itself, for instance. But you (or someone else) could do
that as a follow-up.
[Bug c/7652] -Wswitch-break : Warn if a switch case falls through
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652 --- Comment #24 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Matthew Woehlke from comment #22) [[gcc:fallthrough]] // suppress warning for fall-through to 'case C' N.B. the attribute-namespace for GNU extensions is gnu I agree that the attribute is essential before such warning could be enabled by -Wall
[Bug c/7652] -Wswitch-break : Warn if a switch case falls through
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652 --- Comment #25 from Florian Weimer fweimer at redhat dot com --- (In reply to Matthew Woehlke from comment #22) case B: ... [[gcc:fallthrough]] // suppress warning for fall-through to 'case C' Do we have such attributes in the C compiler? I contemplated using any comment whatsoever as an indicator that fall-through is expected. In the end, need general (syntax-based) unreachable-code detection, so that return statements and no-return functions suppress the warning as well, and so on. At least if this will be part of -Wall.
[Bug c/7652] -Wswitch-break : Warn if a switch case falls through
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #26 from Marek Polacek mpolacek at gcc dot gnu.org --- (In reply to Florian Weimer from comment #25) Do we have such attributes in the C compiler? No, AFAICS. Perhaps we could invent __builtin_fallthrough or some such.
[Bug rtl-optimization/61017] New: lra aborts on optional match_scratch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61017
Bug ID: 61017
Summary: lra aborts on optional match_scratch
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: amylaar at gcc dot gnu.org
CC: vmakarov at gcc dot gnu.org
lra is still not able to compile libgcc2 for ARC:
./cc1 libgcc2.i -O2 -mlra
../../../../unisrc-209293-arc/libgcc/libgcc2.c:2105:1: internal compiler error:
in curr_insn_transform, at lra-constraints.c:3492
The abort happens for the doloop_end_i pattern.
It contains
(clobber (match_scratch:SI 3 =X,X,r))
and for that, a register is allocated in advance without regard to need:
lra.c:remove_scratches 1992ff
if (GET_CODE (*id-operand_loc[i]) == SCRATCH
GET_MODE (*id-operand_loc[i]) != VOIDmode)
{
insn_changed_p = true;
*id-operand_loc[i] = reg
= lra_create_new_reg (static_id-operand[i].mode,
*id-operand_loc[i], ALL_REGS, NULL);
As process_alr_operands find that no the alternative uses X for that operand,
it set this alternative to NO_REGS:
lra-constraints.c:process_alt_operands 1608ff
if (curr_static_id-operand_alternative[opalt_num].anything_ok)
{
/* Fast track for no constraints at all. */
curr_alt[nop] = NO_REGS;
CLEAR_HARD_REG_SET (curr_alt_set[nop]);
curr_alt_win[nop] = true;
curr_alt_match_win[nop] = false;
curr_alt_offmemok[nop] = false;
curr_alt_matches[nop] = -1;
continue;
}
which causes an abort later:
lra-constraints.c:curr_insn_transform 3486ff
if (REG_P (reg) (regno = REGNO (reg)) = FIRST_PSEUDO_REGISTER)
{
bool ok_p = in_class_p (reg, goal_alt[i], new_class);
if (new_class != NO_REGS get_reg_class (regno) != new_class)
{
lra_assert (ok_p);
lra_change_class (regno, new_class, Change to, true);
}
}
[Bug c++/61018] New: -Wvarargs does not print warning for memer functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61018
Bug ID: 61018
Summary: -Wvarargs does not print warning for memer functions
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bilbotheelffriend at gmail dot com
Hi,
It appears to me that, g++ does not warn for -Wvarargs for member
functions.
For the following test-case:
#include cstdarg
struct f
{
void foo(int x, int y, ...)
{
va_list ap;
va_start (ap, x);
}
};
I compiled it with g++ -Wvarargs, and it only printed the warning:
wa.cpp:4:6: warning: unused parameter ‘y’ [-Wunused-parameter]
void foo(int x, int y, ...)
Test-case for non-member function:
#include cstdarg
void foo(int x, int y, ...)
{
va_list ap;
va_start (ap, x);
}
Compiling with g++ -Wvarargs additionally prints:
foo.cpp: In function ‘void foo(int, int, ...)’:
foo.cpp:6:19: warning: second parameter of ‘va_start’ not last
named argument [-Wvarargs]
va_start (ap, x);
g++ -v:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
4.8.2-19ubuntu1'
--with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--enable-gnu-unique-object --disable-libmudflap --enable-plugin
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre
--enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1)
Thanks and Regards,
Prathamesh
[Bug c/7652] -Wswitch-break : Warn if a switch case falls through
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652 --- Comment #27 from Matthew Woehlke mw_triad at users dot sourceforge.net --- (In reply to Marek Polacek from comment #26) Perhaps we could invent __builtin_fallthrough or some such. Yes, I was expecting there would be some alternate spelling for cases where C++11 attributes are not available, e.g. using __attribute__ or __builtin_fallthrough or some such. Please support [[gnu:fallthrough]] also, though, for consistency with clang (and it gives more weight to eventually making [[fallthrough]] standardized).
[Bug c/7652] -Wswitch-break : Warn if a switch case falls through
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652
--- Comment #28 from Alexander Kornienko alexfh at google dot com ---
(In reply to Jonathan Wakely from comment #24)
(In reply to Matthew Woehlke from comment #22)
[[gcc:fallthrough]] // suppress warning for fall-through to 'case C'
N.B. the attribute-namespace for GNU extensions is gnu
And also the attribute must be attached to a declaration or a statement. In
Clang, the [[clang::fallthrough]] attribute is attached to an empty statement
';', so the syntax actually is:
switch (x) {
case 1:
...
[[clang::fallthrough]]; // - note the semicolon
case 2:
...
[Bug rtl-optimization/61017] lra aborts on optional match_scratch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61017 --- Comment #1 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org --- Created attachment 32717 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32717action=edit preprocessed libgcc file
[Bug c/7652] -Wswitch-break : Warn if a switch case falls through
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652 --- Comment #29 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Marek Polacek from comment #26) (In reply to Florian Weimer from comment #25) Do we have such attributes in the C compiler? No, AFAICS. Perhaps we could invent __builtin_fallthrough or some such. I like the previous suggestion of using goto LABEL;. In fact, the warning message could explicitly say use %goto %D;% to silence this warning. (In reply to Florian Weimer from comment #25) In the end, need general (syntax-based) unreachable-code detection, so that return statements and no-return functions suppress the warning as well, and so on. At least if this will be part of -Wall. For trivial cases, it should be just a matter of checking the type of the previous statement in c_stmt_ends_with_goto.
[Bug c/7652] -Wswitch-break : Warn if a switch case falls through
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652 --- Comment #30 from Florian Weimer fweimer at redhat dot com --- (In reply to Manuel López-Ibáñez from comment #29) I like the previous suggestion of using goto LABEL;. In fact, the warning message could explicitly say use %goto %D;% to silence this warning. Does this mean that you propose a GCC extension which allows to write this? goto 5; case 5: I'm not sure if the extension is worth it, and it creates another source of errors/unclarities if another switch branch is inserted before case 5:. It looks like fall-through, but it isn't one because the case labels aren't aligned.
[Bug c/7652] -Wswitch-break : Warn if a switch case falls through
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652 --- Comment #31 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Florian Weimer from comment #30) (In reply to Manuel López-Ibáñez from comment #29) I like the previous suggestion of using goto LABEL;. In fact, the warning message could explicitly say use %goto %D;% to silence this warning. Does this mean that you propose a GCC extension which allows to write this? goto 5; case 5: Sorry, ignore my comment. I am not sure what I was thinking __builtin_fallthrough() seems fine enough. It could be mentioned by the warning message. But as you said, it would be better to detect as many false positives as possible to avoid forcing people to use the __builtin work-around.
[Bug c++/60992] [4.9/4.10 Regression] ICE in tsubst_copy, at cp/pt.c:12637
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60992 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c/7652] -Wswitch-break : Warn if a switch case falls through
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652 --- Comment #32 from Matthew Woehlke mw_triad at users dot sourceforge.net --- (In reply to Florian Weimer from comment #30) Does this mean that you propose a GCC extension which allows to write this? goto 5; case 5: While I personally detest this syntax :-), I feel that I should note that there is a proposal to add e.g. 'goto case 5' to C++17. (Note that I'm not sure if it's even an official proposal yet, though, just that it's been brought up on std-proposals.) (*I* much prefer __builting_fallthrough() or some such...)
[Bug c++/61019] New: ICE: incomplete type of class template as pseudo-destructor-name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61019
Bug ID: 61019
Summary: ICE: incomplete type of class template as
pseudo-destructor-name
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: frankhb1989 at gmail dot com
Case:
templateclass
struct S
{
static_assert(((S*)0)-~S(), );
};
Sint b;
Result:
T:\D:\MinGW\bin\g++.exe a.cc -std=c++11
a.cc: In instantiation of 'struct Sint':
a.cc:7:8: required from here
a.cc:3:1: internal compiler error: Segmentation fault
{
^
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See http://sourceforge.net/projects/mingw-w64 for instructions.
Envrionment:
Win2012r2 x64 with i686-w64-mingw32-g++ 4.9.0.
T:\D:\MinGW\bin\g++.exe -v
Using built-in specs.
COLLECT_GCC=D:\MinGW\bin\g++.exe
COLLECT_LTO_WRAPPER=D:/MinGW/bin/../libexec/gcc/i686-w64-mingw32/4.9.0/lto-wrapper.exe
Target: i686-w64-mingw32
Configured with: ../../../src/gcc-4.9.0/configure --host=i686-w64-mingw32
--build=i686-w64-mingw32 --target=i686-w64-mingw32 --prefix=/mingw32
--with-sysroot=/c/mingw490/i686-490-posix-dwarf-rt_v3-rev
1/mingw32 --with-gxx-include-dir=/mingw32/i686-w64-mingw32/include/c++
--enable-shared --enable-static --disable-multilib
--enable-languages=ada,c,c++,fortran,objc,obj-c++,lto --enable-libstdcxx-time=
yes --enable-threads=posix --enable-libgomp --enable-libatomic --enable-lto
--enable-graphite --enable-checking=release --enable-fully-dynamic-string
--enable-version-specific-runtime-libs --disable-s
jlj-exceptions --with-dwarf2 --disable-isl-version-check
--disable-cloog-version-check --disable-libstdcxx-pch --disable-libstdcxx-debug
--enable-bootstrap --disable-rpath --disable-win32-registry --d
isable-nls --disable-werror --disable-symvers --with-gnu-as --with-gnu-ld
--with-arch=i686 --with-tune=generic --with-libiconv --with-system-zlib
--with-gmp=/c/mingw490/prerequisites/i686-w64-mingw32-
static --with-mpfr=/c/mingw490/prerequisites/i686-w64-mingw32-static
--with-mpc=/c/mingw490/prerequisites/i686-w64-mingw32-static
--with-isl=/c/mingw490/prerequisites/i686-w64-mingw32-static --with-cl
oog=/c/mingw490/prerequisites/i686-w64-mingw32-static
--enable-cloog-backend=isl --with-pkgversion='i686-posix-dwarf-rev1, Built by
MinGW-W64 project' --with-bugurl=http://sourceforge.net/projects/min
gw-w64 CFLAGS='-O2 -pipe
-I/c/mingw490/i686-490-posix-dwarf-rt_v3-rev1/mingw32/opt/include
-I/c/mingw490/prerequisites/i686-zlib-static/include
-I/c/mingw490/prerequisites/i686-w64-mingw32-static/incl
ude' CXXFLAGS='-O2 -pipe
-I/c/mingw490/i686-490-posix-dwarf-rt_v3-rev1/mingw32/opt/include
-I/c/mingw490/prerequisites/i686-zlib-static/include
-I/c/mingw490/prerequisites/i686-w64-mingw32-static/incl
ude' CPPFLAGS= LDFLAGS='-pipe
-L/c/mingw490/i686-490-posix-dwarf-rt_v3-rev1/mingw32/opt/lib
-L/c/mingw490/prerequisites/i686-zlib-static/lib
-L/c/mingw490/prerequisites/i686-w64-mingw32-static/lib'
Thread model: posix
gcc version 4.9.0 (i686-posix-dwarf-rev1, Built by MinGW-W64 project)
[Bug c++/61019] ICE: incomplete type of class template as pseudo-destructor-name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61019 frankhb1989 at gmail dot com changed: What|Removed |Added Known to fail||4.8.2, 4.9.0 --- Comment #1 from frankhb1989 at gmail dot com --- GCC 4.8.2 (Rev7, Built by MSYS2 project) also fails.
[Bug debug/61013] [4.9/4.10 Regression] Option parsing difference between 4.9 and 4.9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61013 --- Comment #7 from Cary Coutant ccoutant at gcc dot gnu.org --- (In reply to Andres Freund from comment #2) The point is that this has changed between 4.8 and 4.9... And I don't see anything relevant in http://gcc.gnu.org/gcc-4.9/changes.html Yes, you're right. This change should have been documented there. Sorry! I did ask twice for consensus, and got no objections either time. Our build system adds -g1 to the compile options, before user-supplied options, and if a user adds -g, it's surprising to only get -g1. I wonder if it would be reasonable for -g to set the debug level to max(2, previous level)? I still think the simplicity of -g === -g2 is much better, and it's also much better to be consistent with the -O option. What should the following combinations do? -g1 -g -g1 -g0 -g -g3 -g -g3 -g0 -g -cary
[Bug c/7652] -Wswitch-break : Warn if a switch case falls through
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652 --- Comment #33 from Michael Chapman michael.chapman at cortus dot com --- (In reply to Florian Weimer from comment #30) (In reply to Manuel López-Ibáñez from comment #29) I like the previous suggestion of using goto LABEL;. In fact, the warning message could explicitly say use %goto %D;% to silence this warning. Does this mean that you propose a GCC extension which allows to write this? goto 5; case 5: I'm not sure if the extension is worth it, and it creates another source of errors/unclarities if another switch branch is inserted before case 5:. It looks like fall-through, but it isn't one because the case labels aren't aligned. Why an extension? What is wrong with:- goto case_5; case 5: case_5:
[Bug c++/61020] New: [4.9/4.10 Regression] typeid(typeid(X)) produces 'ud2'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61020
Bug ID: 61020
Summary: [4.9/4.10 Regression] typeid(typeid(X)) produces 'ud2'
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
The test case:
#include typeinfo
struct Base {
virtual ~Base() { }
};
struct Derived : public Base {
};
int compare(const Base base)
{
return typeid(base) == typeid(typeid(Derived));
}
int main()
{
Base base;
Derived derived;
if (compare(base)) return 1;
if (compare(derived)) return 2;
return 0;
}
Using trunk @ r209848
g++ -g t.cc ./a.out echo OK
OK
g++ -g t.cc -O2 ./a.out
Segmentation fault (core dumped)
(gdb) disas main
Dump of assembler code for function main():
0x004004c0 +0: mov0x8,%rax
0x004004c8 +8: ud2
End of assembler dump.
It appears that GCC believes the test to invoke undefined behavior.
However, I don't see anything in the standard to support this.
P.S. Same result in C++98 and C++11
P.P.S. In the original code, the double application of typeid() was a bug.
[Bug tree-optimization/60971] [4.9/4.10 Regression] Wrong code when coercing unsigned char to bool
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60971 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Jeffrey A. Law law at redhat dot com --- Fixed on trunk and 4.9 branch.
[Bug c++/61020] [4.9/4.10 Regression] typeid(typeid(X)) produces 'ud2'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61020 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-04-30 Known to work||4.8.2 Ever confirmed|0 |1
[Bug libstdc++/61011] libstdc++-v3 should be target-libstdc++-v3 in top level configure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61011 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-04-30 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- I wonder if --disable-libstdcxx should also imply --disable-libsanitizer and --disable-libcilkrts, which depend on libstdc++
[Bug tree-optimization/61009] Incorrect jump threading in dom
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61009 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-04-30 Ever confirmed|0 |1
[Bug c++/61020] [4.9/4.10 Regression] typeid(typeid(X)) produces 'ud2'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61020 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- _ZTI7Derived.0_1 = _ZTI7Derived; _3 = MEM[(const struct type_info *)_ZTI7Derived.0_1]._vptr.type_info; _4 = _3 + 18446744073709551608; _5 = *_4; Is being optimized to be 0 for some reason. Looks like _ZTVN10__cxxabiv120__si_class_type_infoE (vtable for __cxxabiv1::__si_class_type_info) is not being recorded correctly inside GCC.
[Bug debug/61013] [4.9/4.10 Regression] Option parsing difference between 4.9 and 4.9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61013
--- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org ---
I don't see why there should be any consistency with -O, it is a very different
option, with a very different usage and history.
The 4.8 behavior was that -g set debug level to 2 if the debug level was 0, so
-g1 -g used to be the same as -g1
-g1 -g0 -g used to be the same as -g2
-g3 -g used to be the same as -g3
-g3 -g0 -g used to be the same as -g2
Now, if you want to change a default for your builds, I'd say you'd just tweak
specs so that -g1 is provided if no -g appears on the command line; either
that can be done by changing the default specs, or you simply add a short specs
file which will do that and change say CC to gcc -specs=whatever.
E.g. in Fedora we use:
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
and the specs file ensures that -fPIE is supplied by default if no other option
is used on the command line:
*cc1_options:
+ %{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fPIE}
So, my preference would be to revert to the 4.8 and older behavior, or if there
really is consensus that -g1 -g should mean -g2 rather than -g1, at least
change
it so that -g3 -g means -g3 (so revert your change and for *arg == '\0' instead
of the 4.8:
if (!opts-x_debug_info_level)
opts-x_debug_info_level = DINFO_LEVEL_NORMAL;
do:
if (opts-x_debug_info_level DINFO_LEVEL_NORMAL)
opts-x_debug_info_level = DINFO_LEVEL_NORMAL;
What I'd say would be helpful would be add support for inline specs overrides
which you could specify on the command line rather than having to resort to
loading a file. So -specsinline='*cc1_options:\n+
%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fPIE}' or so.
[Bug debug/61013] [4.9/4.10 Regression] Option parsing difference between 4.9 and 4.9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61013 Richard Henderson rth at gcc dot gnu.org changed: What|Removed |Added CC||rth at gcc dot gnu.org --- Comment #9 from Richard Henderson rth at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #8) So, my preference would be to revert to the 4.8 and older behavior, or if there really is consensus that -g1 -g should mean -g2 rather than -g1, at least change it so that -g3 -g means -g3 (so revert your change and for *arg == '\0' instead of the 4.8: if (!opts-x_debug_info_level) opts-x_debug_info_level = DINFO_LEVEL_NORMAL; do: if (opts-x_debug_info_level DINFO_LEVEL_NORMAL) opts-x_debug_info_level = DINFO_LEVEL_NORMAL; I agree on both points.
[Bug c++/61020] [4.9/4.10 Regression] typeid(typeid(X)) produces 'ud2'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61020 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org, ||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Target Milestone|--- |4.9.1 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r200211.
[Bug tree-optimization/61009] Incorrect jump threading in dom
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61009 --- Comment #7 from Jeffrey A. Law law at redhat dot com --- I see what's happening here... I need to think about how best to handle this situation. Oh how threading across loop backedges perilous.
[Bug target/60847] [4.9/4.10 Regression] x86 BMI intrinsics not recognized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60847 --- Comment #8 from Sanjay Patel spatel at rotateright dot com --- Thanks, Jakub. I see that the fix duplicates all of the intrinsics with a double-leading-underscore variant. Why do we need that? AFAIK, no other x86 intrinsics have this kind of duplication.
[Bug target/60847] [4.9/4.10 Regression] x86 BMI intrinsics not recognized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60847 --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org --- (In reply to Sanjay Patel from comment #8) Thanks, Jakub. I see that the fix duplicates all of the intrinsics with a double-leading-underscore variant. Why do we need that? AFAIK, no other x86 intrinsics have this kind of duplication. That is because one kind of these intrinsics originates from AMD (support for AMD BMI is what went into GCC first) and the other from ICC which chose to provide different names. So, for backwards compatibility we need both sets.
[Bug target/60847] [4.9/4.10 Regression] x86 BMI intrinsics not recognized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60847 --- Comment #10 from Sanjay Patel spatel at rotateright dot com --- Ah - thank you for the explanation! I found the original checkin from AMD: http://gcc.gnu.org/ml/gcc-patches/2010-10/msg01356.html Strangely, I can't find any documentation for those double-underscores from AMD though.
[Bug debug/61013] [4.9/4.10 Regression] Option parsing difference between 4.9 and 4.9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61013 --- Comment #10 from ccoutant at google dot com --- So, my preference would be to revert to the 4.8 and older behavior, or if there really is consensus that -g1 -g should mean -g2 rather than -g1, at least change it so that -g3 -g means -g3 (so revert your change and for *arg == '\0' instead of the 4.8: if (!opts-x_debug_info_level) opts-x_debug_info_level = DINFO_LEVEL_NORMAL; do: if (opts-x_debug_info_level DINFO_LEVEL_NORMAL) opts-x_debug_info_level = DINFO_LEVEL_NORMAL; I agree on both points. Sorry, I'm not sure what both points are. Does that mean that you would support changing -g so that -g1 -g means -g2, but -g3 -g means -g3? (I.e., -g will raise the level to 2 but will not lower it.) That seems reasonable to me, and it would support both build scenarios mentioned above (Andres' and mine). It'll leave the meaning of -g3 -g the same as 4.8, but change the meaning of -g1 -g (which shouldn't be much of a problem since everyone here seemed to think that -g1 usage was rare). -cary
[Bug sanitizer/61021] New: [4.9 regression] libsanitizer fails to build with old glibc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61021 Bug ID: 61021 Summary: [4.9 regression] libsanitizer fails to build with old glibc Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: sandra at codesourcery dot com CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org Host: i686-pc-linux-gnu Target: i686-pc-linux-gnu Build: i686-pc-linux-gnu Created attachment 32718 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32718action=edit patch to conditionalize references We build a native i686-pc-linux-gnu toolchain against a relatively ancient sysroot (glibc 2.4) so that the resulting binaries will work on a variety of older GNU/Linux distros. GCC 4.9 is now failing to build this configuration due to references to undefined symbols PTRACE_GETSIGINFO and PTRACE_SETSIGINFO in libsanitizer. I see that in other issues the maintainers have suggested disabling libsanitizer in cases where the kernel/glibc version is too old for it to build, but this looks like a regression to me: it used to work in GCC 4.8. The attached patch is sufficient to get it to at least build again, and it's consistent with the way PTRACE_GETREGSET and PTRACE_SETREGSET are being handled. libsanitizer/README.gcc says Trivial and urgent fixes (portability, build fixes, etc.) may go directly to the GCC tree. Does this one qualify under that policy? If not, I'll have to echo what has already been suggested elsewhere: the minimum kernel/glibc requirements for libsanitizer need to be documented and enforced by the configure scripts if possible.
[Bug other/60843] Documentation: 4.5 Integers/C99 6.3.1.3 (reduce modulo 2^N)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60843 --- Comment #3 from joseph at codesourcery dot com joseph at codesourcery dot com --- On Wed, 30 Apr 2014, kdevel at vogtner dot de wrote: The problem is the erroneous wording reduction modulo 2^N. *Reduction* by definition results in the least *nonnegative* number out of the list of congruent numbers, cf. http://www.youtube.com/watch?v=SO6l6sDwEFgt=5m50s It's perfectly normal English usage for X with qualifier to be outside what would be understood by X without the qualifier. I think the use in the GCC manual is a perfectly ordinary and well-understood use of the term. The GCC manual is not trying to refer to any particular set of definitions as normative references, and it's not trying to give formal definitions. If anything, I'd say strictly reduction modulo 2^N is a map from Z to Z / 2^N Z, i.e. producing an equivalence class of integers rather than a single integer (and for modulo arithmetic, integer types are interpreted as having values that are such equivalence classes).
[Bug c++/61022] New: [C++11] Bogus error: parameter packs not expanded with '...'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61022
Bug ID: 61022
Summary: [C++11] Bogus error: parameter packs not expanded
with '...'
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
Google ref: b/14441040
// --- cut ---
template typename T struct Template {};
template typename O struct TemplateAliasStruct {
template typename T using TemplateAlias = TemplateT;
};
template template typename class... T struct Templates {};
// Using this alternate definition of Templates compiles:
// template template typename class... W void Templates() {}
template typename... W
void DoTest() {
TemplatesTemplateAliasStructW::template TemplateAlias...();
}
int main(int argc, char* argv[]) {
DoTestint, int();
return 0;
}
// --- cut ---
Using trunk @r209848:
g++ -c -std=c++11 t.cc
t.cc: In function 'void DoTest()':
t.cc:14:65: error: parameter packs not expanded with '...':
TemplatesTemplateAliasStructW::template TemplateAlias...();
^
t.cc:14:65: note: 'W'
The test compiles cleanly with Clang.
