[Bug fortran/55469] memory leak on read with istat.ne.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55469 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added CC||Joost.VandeVondele at mat ||dot ethz.ch --- Comment #1 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-11-26 08:01:27 UTC --- BTW, would there be a simple workaround ?
[Bug c++/55468] Label value to incorrect destination
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55468 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org 2012-11-26 08:56:22 UTC --- Labels as values are only designed and will only work with computed gotos. Any other use is an undefined use of them. The actual labels are moved around just like any other label would be and will be place at random places in the code if not used with computed gotos.
[Bug tree-optimization/54471] [4.8 Regression] FAIL: gcc.dg/sms-8.c execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54471 --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-26 09:19:39 UTC --- Author: jakub Date: Mon Nov 26 09:19:30 2012 New Revision: 193806 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193806 Log: PR tree-optimization/54471 * tree-vrp.c (extract_range_from_binary_expr_1): For MULT_EXPR, don't canonicalize range if min2 is zero. * gcc.dg/tree-ssa/vrp86.c: New test. * gcc.c-torture/execute/pr54471.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr54471.c trunk/gcc/testsuite/gcc.dg/tree-ssa/vrp86.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c
[Bug tree-optimization/54471] [4.8 Regression] FAIL: gcc.dg/sms-8.c execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54471 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-26 09:26:14 UTC --- Fixed.
[Bug fortran/55469] memory leak on read with istat.ne.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55469 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 2012-11-26 09:26:46 UTC --- Untested: --- a/libgfortran/io/list_read.c +++ b/libgfortran/io/list_read.c @@ -1966,8 +1966,8 @@ list_formatted_read_scalar (st_parameter_dt *dtp, bt type, void *p, } +cleanup: if (--dtp-u.p.repeat_count = 0) free_saved (dtp); -cleanup: if (err == LIBERROR_END) hit_eof (dtp);
[Bug lto/52650] [4.8 Regression] FAIL: gcc.dg/torture/pr51106-2.c * (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52650 --- Comment #14 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-11-26 09:47:18 UTC --- A milestone of 3.0.x???
[Bug c++/55245] [4.6/4.7/4.8 Regression] Compiler segfault when compiling a small test case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55245 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-26 09:49:23 UTC --- I'd say it should be the FE's responsibility to layout all needed types, so it should be done either somewhere when the type ARRAY_REF is created or finalized, or in cp-gimplify.c at latest.
[Bug target/55428] -mms-bitfields hides -mno-align-double option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55428
--- Comment #5 from Andreas Kasberger kasberger at heidenhain dot de
2012-11-26 09:51:50 UTC ---
I found this example on
geeksforgeeks.org/forum/topic/c-structure-size-with-empty-bitfield
#define offset(a,b) (size_t)a*)(0))-b))
struct emp
{
char s:8;
char c:7;
char d:2;
int:14;
char u;
char g:2;
}e;
int l;
l = offset(struct emp,u);
printf(%d %d,sizeof(struct emp),l);
With this example it is impossible to get vsc++ /zp4 results with gcc options
without changing the souce code itself.
The ms compiler result is 12 8 on gcc I will get mostly 6 4
I'm not able to align the bitfields in the way like ms do it.
Each single bitfield is aligned at word boundary.
[Bug fortran/55469] memory leak on read with istat.ne.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55469
--- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2012-11-26
10:23:54 UTC ---
Didn't help. The following should work. The crucial part is free_line. At a
glance free_saved(dtp) (here and in comment 2) seems also to be sensible, but
one should read through the file to check that it is indeed correct - and to
find other places where free_line is missing.
--- a/libgfortran/io/list_read.c
+++ b/libgfortran/io/list_read.c
@@ -1757,8 +1757,9 @@ read_real (st_parameter_dt *dtp, void * dest, int length)
bad_real:
+ free_line (dtp);
+ free_saved (dtp);
if (nml_bad_return (dtp, c))
return;
- free_saved (dtp);
if (c == EOF)
{
[Bug c++/41233] Templated conversion operator produces symbol name that won't demangle
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41233 Marc Glisse glisse at gcc dot gnu.org changed: What|Removed |Added CC||glisse at gcc dot gnu.org --- Comment #8 from Marc Glisse glisse at gcc dot gnu.org 2012-11-26 10:24:23 UTC --- Note that such undemanglable symbols now appear in cc1 and cc1plus: _ZN5vnullcv3vecIT_T0_T1_EI10double_int7va_heap6vl_ptrEEv and 55 other variants.
[Bug fortran/54881] [4.8 Regression] [OOP] ICE in fold_convert_loc, at fold-const.c:2016
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54881 --- Comment #8 from janus at gcc dot gnu.org 2012-11-26 10:30:18 UTC --- Author: janus Date: Mon Nov 26 10:30:12 2012 New Revision: 193809 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193809 Log: 2012-11-26 Janus Weil ja...@gcc.gnu.org PR fortran/54881 * match.c (select_derived_set_tmp,select_class_set_tmp): Removed and unified into ... (select_type_set_tmp): ... this one. Set POINTER argument according to selector. * trans-intrinsic.c (gfc_conv_associated): Use 'gfc_class_data_get' instead of 'gfc_add_data_component'. 2012-11-26 Janus Weil ja...@gcc.gnu.org PR fortran/54881 * gfortran.dg/associated_6.f90: New. * gfortran.dg/select_type_30.f03: New. Added: trunk/gcc/testsuite/gfortran.dg/associated_6.f90 trunk/gcc/testsuite/gfortran.dg/select_type_30.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/match.c trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/54881] [4.8 Regression] [OOP] ICE in fold_convert_loc, at fold-const.c:2016
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54881 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #9 from janus at gcc dot gnu.org 2012-11-26 10:33:30 UTC --- r193809 fixes both problems on trunk. Closing. Thanks for the bug report!
[Bug tree-optimization/55110] [4.8 Regression] Internal compiler error in vectorizable_reduction, at tree-vect-loop.c:4633
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55110
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 2012-11-26
10:35:44 UTC ---
I'd say either we should nuke the bogus
gcc_assert (STMT_VINFO_RELATED_STMT (orig_stmt_info) == stmt);
assertion, which predates the introduction of
STMT_VINFO_PATTERN_DEF_STMT (and later STMT_VINFO_PATTERN_DEF_SEQ) - both in
4.7 cycle, or just return false; if it isn't equal.
We won't successfully vectorize this anyway, orig_code is still TRUNC_DIV_EXPR
and that is not a handled reduction (and even if we'd handled it as the signed
MULT_HIGHPART_EXPR reduction, that isn't handled either).
So, I'd propose this (if we wanted to assert something, it would need to
walk the STMT_VINFO_PATTERN_DEF_SEQ sequence and checking whether stmt isn't in
there too):
2012-11-26 Jakub Jelinek ja...@redhat.com
PR tree-optimization/55110
* tree-vect-loop.c (vectorizable_reduction): Don't assert
that STMT_VINFO_RELATED_STMT of orig_stmt is stmt.
* gcc.dg/pr55110.c: New test.
--- gcc/tree-vect-loop.c.jj2012-11-21 16:00:12.0 +0100
+++ gcc/tree-vect-loop.c2012-11-26 11:24:42.903995009 +0100
@@ -4624,7 +4624,6 @@ vectorizable_reduction (gimple stmt, gim
if (orig_stmt)
{
orig_stmt_info = vinfo_for_stmt (orig_stmt);
- gcc_assert (STMT_VINFO_RELATED_STMT (orig_stmt_info) == stmt);
gcc_assert (STMT_VINFO_IN_PATTERN_P (orig_stmt_info));
gcc_assert (!STMT_VINFO_IN_PATTERN_P (stmt_info));
}
--- gcc/testsuite/gcc.dg/pr55110.c.jj2012-11-26 11:31:32.008587313 +0100
+++ gcc/testsuite/gcc.dg/pr55110.c2012-11-26 11:31:09.0 +0100
@@ -0,0 +1,13 @@
+/* PR tree-optimization/55110 */
+/* { dg-do compile } */
+/* { dg-options -O1 -ftree-vectorize } */
+
+int
+foo (int x)
+{
+ int a, b;
+ for (b = 0; b 8; b++)
+for (a = 0; a 2; a++)
+ x /= 3;
+ return x;
+}
[Bug fortran/54997] [4.8 Regression] -Wunused-function gives false warnings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54997 --- Comment #8 from janus at gcc dot gnu.org 2012-11-26 11:16:35 UTC --- Author: janus Date: Mon Nov 26 11:16:31 2012 New Revision: 193811 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193811 Log: 2012-11-26 Janus Weil ja...@gcc.gnu.org PR fortran/54997 * decl.c (match_procedure_decl): Don't set 'referenced' attribute for PROCEDURE declarations. * parse.c (gfc_fixup_sibling_symbols,parse_contained): Don't set 'referenced' attribute for all contained procedures. * trans-decl.c (gfc_get_symbol_decl): Allow for unreferenced procedures. (build_function_decl): Set TREE_USED for referenced procedures. 2012-11-26 Janus Weil ja...@gcc.gnu.org PR fortran/54997 * gfortran.dg/warn_unused_function_2.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/warn_unused_function_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/parse.c trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/54997] [4.8 Regression] -Wunused-function gives false warnings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54997 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #9 from janus at gcc dot gnu.org 2012-11-26 11:22:59 UTC --- Fixed with r193811. Closing.
[Bug c++/51242] [C++11] Unable to use strongly typed enums as bit fields
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242 --- Comment #8 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-26 11:26:16 UTC --- The warning noticed by Jon seems a latent issue unrelated to bitfields and due to the fact to for scoped enums, the underlying type, if not explicitly specified is if fixed to int type. Thus, in finish_enum_value_list, fixed_underlying_type_p is true and the code restricting ENUM_UNDERLYING_TYPE for the benefit of diagnostics doesn't run. It seems that it should run anyway, when the underlying type is fixed but implicitly so.
[Bug c++/51242] [C++11] Unable to use strongly typed enums as bit fields
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242 --- Comment #9 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-26 11:32:15 UTC --- Or maybe it should *always* run, if the point is diagnostics: after all even if the type is fixed why not adding to its representation the information about the actual range of values of the enumerators?!?
[Bug c++/51242] [C++11] Unable to use strongly typed enums as bit fields
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
--- Comment #10 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-26
11:36:56 UTC ---
For example, consider this variant of the PR53661 situation:
enum class Code {
SUCCESS = 0
};
Code a;
short r[] = {a};
we currently produce a -Wnarrowing warning, which seems bogus to me, exactly
because we don't realize that actually the only enumerator has value zero.
[Bug c++/51242] [C++11] Unable to use strongly typed enums as bit fields
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242 --- Comment #11 from Jonathan Wakely redi at gcc dot gnu.org 2012-11-26 11:46:46 UTC --- That narrowing warning seems right to me, the enum variable could have a value out of range of short: Code a = static_castCode(SHRT_MAX+1);
[Bug c++/51242] [C++11] Unable to use strongly typed enums as bit fields
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242 --- Comment #12 from Jonathan Wakely redi at gcc dot gnu.org 2012-11-26 11:50:43 UTC --- The difference from PR 53661 is that the underlying type of a scoped enumeration is fixed, so its values are the values of (in this case) int. In PR 53661 the underlying type is not fixed.
[Bug c++/51242] [C++11] Unable to use strongly typed enums as bit fields
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
--- Comment #13 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-26
12:00:17 UTC ---
But something still seems wrong to me. Why warning depending on whether 'class'
is there for the following:
enum /*class*/ Code {
SUCCESS = 0
};
Code a;
short r[] = {a};
[Bug c++/51242] [C++11] Unable to use strongly typed enums as bit fields
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242 --- Comment #14 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-26 12:05:21 UTC --- Anyway, the latent issue is of course with fixed underlying types: if in that case we don't care about warning more, this issue is already fixed, very likely. Even better ;)
[Bug c++/51242] [C++11] Unable to use strongly typed enums as bit fields
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
CC||paolo.carlini at oracle dot
||com
--- Comment #15 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-26
12:12:12 UTC ---
To be clear, for:
enum class Code {
SUCCESS = 0
};
Code a;// = static_castCode(SHRT_MAX+1);
short r[] = {a};
we *error* out anyway, isn't that we are only emitting a warning and only when
we are assigning the SHRT_MAX + 1.
[Bug c++/51242] [C++11] Unable to use strongly typed enums as bit fields
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
--- Comment #16 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-26
12:22:49 UTC ---
And to further clarify wrt your specific Comment 11, Jon, for:
#include limits.h
enum Code {
SUCCESS = 0
};
Code a = static_castCode(SHRT_MAX + 1);
short r[] = {a};
we currently don't warn.
[Bug lto/54795] [4.8 Regression] LTO miscompiled external array access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54795
--- Comment #25 from Richard Biener rguenth at gcc dot gnu.org 2012-11-26
12:24:30 UTC ---
(In reply to comment #23)
Another problem with revision 191466 is we lost
debug info on cl_options. With revision 191465,
I got
(gdb) whatis cl_options
type = const struct cl_option [1221]
(gdb)
After revision 191466, I got
(gdb) whatis cl_option
type = cl_option
(gdb)
This means that somewhere there is a cl_option definition that may prevail
that has size 1. lto_symtab_resolve_symbols is supposed to pick the
largest one. The cl_options definition that matters is in options.c,
created
const struct cl_option cl_options[] = { ... }
maybe it's size isn't finished?
Also
|| (DECL_SIZE (prevailing-symbol.decl) == DECL_SIZE (e-symbol.decl)
is fragile - use tree_int_cst_eq. I suppose we don't have anything
like a testcase?
[Bug middle-end/52650] [4.8 Regression] FAIL: gcc.dg/torture/pr51106-2.c * (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52650 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Component|lto |middle-end Version|4.7.2 |4.8.0 Target Milestone|3.0.x |4.8.0
[Bug c++/51242] [C++11] Unable to use strongly typed enums as bit fields
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
--- Comment #17 from Jonathan Wakely redi at gcc dot gnu.org 2012-11-26
12:43:37 UTC ---
(In reply to comment #15)
we *error* out anyway, isn't that we are only emitting a warning and only when
we are assigning the SHRT_MAX + 1.
But isn't the error because there's no implicit conversion from a scoped
enunmeration type to short? That's just invalid.
And my point is that the narrowing warning is correct, because 'a' is not a
constant expression and its value could be out of the range
[SHRT_MIN,SHRT_MAX].
(In reply to comment #16)
And to further clarify wrt your specific Comment 11, Jon, for:
#include limits.h
enum Code {
SUCCESS = 0
};
Code a = static_castCode(SHRT_MAX + 1);
short r[] = {a};
we currently don't warn.
Because the values of that unscoped enum type are [0,1] which always fit in
short. With a scoped enumeration type the underlying type is fixed so the
values of the enumeration type are the values of the underlying type which are
[INT_MIN,INT_MAX]. But this seems unrelated to using scoped enums as bitfields
anyway.
[Bug lto/55466] [4.8 Regression] Revision 191466 destroyed DWARF debug info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55466 --- Comment #1 from Jan Hubicka hubicka at ucw dot cz 2012-11-26 12:45:23 UTC --- /export/project/git/gcc-regression-bootstrap/master/191466/bld/gcc/cc1...done. (gdb) whatis global_options type = data variable, no debug info (gdb) whatis cl_options type = data variable, no debug info (gdb) whatis cl_enums type = data variable, no debug info (gdb) whatis cl_enums_count type = data variable, no debug info (gdb) whatis global_options_set type = data variable, no debug info (gdb) whatis sched_max_luid type = data variable, no debug info (gdb) Hmm, I suppose this is because we no longer merge symbols that are not part of symtab, but used only for debugging Honza
[Bug c++/51242] [C++11] Unable to use strongly typed enums as bit fields
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC|paolo.carlini at oracle dot | |com | --- Comment #18 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-26 12:50:15 UTC --- What can I say, if we are happy with these warnings when the underlying type is fixed, then I think your patch is all there is to this issue, just regression test it ;) It would be nice to double check that clang also warns, tough.
[Bug c++/51242] [C++11] Unable to use strongly typed enums as bit fields
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242 --- Comment #19 from Jonathan Wakely redi at gcc dot gnu.org 2012-11-26 12:56:34 UTC --- Clang doesn't warn for the code in comment 1
[Bug c++/51242] [C++11] Unable to use strongly typed enums as bit fields
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242 --- Comment #20 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-26 13:00:08 UTC --- Well, then we should double check whether it warns at all when bitfields are not involved, because I don't see anything bitfield-specific about the warning. Maybe it just warns less for these narrowing issues with scoped and unscoped enums?
[Bug c++/51242] [C++11] Unable to use strongly typed enums as bit fields
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
--- Comment #21 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-26
13:27:45 UTC ---
Uhm, actually, when the underlying type is unscoped and we already accept the
code, we warn exactly in the same way. I'm not sure if this is already clear to
everybody, definitely wasn't clear to me, sorry if I misled you Jon or somebody
else into thinking that the possible issues having to do with -Wnarrowing were
important for this issue, I understand now they are not:
enum MyEnum { A1 = 1, A2 = 2 };
struct MyClass
{
MyEnum Field1 : 1;
};
Thus, it really seems the fix for this issue boils down to loosening the check
in grokbitfield and that's it.
[Bug lto/54795] [4.8 Regression] LTO miscompiled external array access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54795
--- Comment #26 from H.J. Lu hjl.tools at gmail dot com 2012-11-26 13:29:17
UTC ---
(In reply to comment #25)
This means that somewhere there is a cl_option definition that may prevail
that has size 1. lto_symtab_resolve_symbols is supposed to pick the
largest one. The cl_options definition that matters is in options.c,
created
const struct cl_option cl_options[] = { ... }
maybe it's size isn't finished?
Isn't just we lost debug info on arrays. We lost debug
info on all data variables. You can pick one and verify
it.
Also
|| (DECL_SIZE (prevailing-symbol.decl) == DECL_SIZE
(e-symbol.decl)
is fragile - use tree_int_cst_eq. I suppose we don't have anything
like a testcase?
I don't have a testcase, except for GCC itself.
[Bug debug/55467] Wrong value for optimized debug, variants of gcc.dg/guality/pr36728-2.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55467 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution||INVALID --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-26 13:36:26 UTC --- That is not a bug. Without volatile and nothing using the result of the asm, both the second inline asm and x[0] = 25 store are optimized away (by RTL DSE1), there is not even anything on the line 14 anymore. As it is optimized away quite late, the variable x is not optimized away, it exists, just is completely uninitialized. What you see in the debugger than is exactly what you would see before the x[0] = 25; store then.
[Bug driver/55470] New: Enable both ld and gold in gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55470 Bug #: 55470 Summary: Enable both ld and gold in gcc Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com CC: dnovi...@google.com, d...@debian.org, ni...@redhat.com This patch: http://gcc.gnu.org/ml/gcc-patches/2011-06/msg02076.html enables both ld and gold in gcc. It was suggested for trunk: http://gcc.gnu.org/ml/gcc-patches/2011-06/msg02121.html
[Bug c++/51242] [C++11] Unable to use strongly typed enums as bit fields
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242 --- Comment #22 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-26 13:39:17 UTC --- I mean, with the grokbitfield tweak we obtain a behavior for Comment #1 which in terms of warnings it's just a variant of Comment #13: if we already decided that it's fine to warn when the underlying type is fixed for Comment #13, we have in my opinion to consistently warn for Comment #1.
[Bug c++/51242] [C++11] Unable to use strongly typed enums as bit fields
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242 --- Comment #23 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-26 14:00:37 UTC --- Patchlet in Comment #6 passes testing for me. As I tried clumsily to explain, I don't think it's consistent to avoid the warning for Comment #1 if we warn for Comment #13 scoped, but it's also annoying that the too small to hold all values warning it's enable by default, thus can't be suppresed: maybe we could give it a name (if we don't want to re-open the discussion about -Wnarrowing and the range of the underlying type when the type is fixed ;)
[Bug debug/55467] Wrong value for optimized debug, variants of gcc.dg/guality/pr36728-2.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55467 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2012-11-26 Resolution|INVALID | Ever Confirmed|0 |1 --- Comment #5 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-11-26 14:13:24 UTC --- (In reply to comment #4) That is not a bug. Without volatile and nothing using the result of the asm, both the second inline asm and x[0] = 25 store are optimized away (by RTL DSE1), there is not even anything on the line 14 anymore. As it is optimized away quite late, the variable x is not optimized away, it exists, just is completely uninitialized. What you see in the debugger than is exactly what you would see before the x[0] = 25; store then. Your reply matches only for the attachment named pr55467-1.c. I'd hope to see the value being optimized out, but ok. A bit too quick on closing, methinks: see the (first) attachment, named gcc.dg/guality/pr55467-2.c, where x[0] is used at the return (after being magically changed by the asm). So, reopened.
[Bug tree-optimization/54894] [4.6/4.7 Regression] internal compiler error: in vect_get_vec_def_for_operand, at tree-vect-stmts.c:1286
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54894 --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org 2012-11-26 14:26:16 UTC --- Author: rguenth Date: Mon Nov 26 14:26:07 2012 New Revision: 193816 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193816 Log: 2012-11-26 Richard Biener rguent...@suse.de Backport from mainline 2012-10-19 Richard Biener rguent...@suse.de PR tree-optimization/54976 * tree-vect-stmts.c (get_vectype_for_scalar_type_and_size): Robustify against odd inner_mode inputs. 2012-10-12 Richard Biener rguent...@suse.de PR tree-optimization/54894 * tree-vect-stmts.c (get_vectype_for_scalar_type_and_size): Handle over-aligned scalar types properly. 2012-10-02 Richard Guenther rguent...@suse.de PR middle-end/54735 * tree-ssa-pre.c (do_pre): Make sure to update virtual SSA form before cleaning up the CFG. 2012-10-12 Richard Biener rguent...@suse.de PR tree-optimization/54894 * gcc.dg/torture/pr54894.c: New testcase. 2012-10-02 Richard Guenther rguent...@suse.de PR middle-end/54735 * g++.dg/torture/pr54735.C: New testcase. Added: branches/gcc-4_7-branch/gcc/testsuite/g++.dg/torture/pr54735.C branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr54894.c Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/gcc/tree-ssa-pre.c branches/gcc-4_7-branch/gcc/tree-vect-stmts.c
[Bug tree-optimization/54735] [4.7 Regression] Segmentation fault in walk_aliased_vdefs_1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54735 --- Comment #15 from Richard Biener rguenth at gcc dot gnu.org 2012-11-26 14:26:18 UTC --- Author: rguenth Date: Mon Nov 26 14:26:07 2012 New Revision: 193816 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193816 Log: 2012-11-26 Richard Biener rguent...@suse.de Backport from mainline 2012-10-19 Richard Biener rguent...@suse.de PR tree-optimization/54976 * tree-vect-stmts.c (get_vectype_for_scalar_type_and_size): Robustify against odd inner_mode inputs. 2012-10-12 Richard Biener rguent...@suse.de PR tree-optimization/54894 * tree-vect-stmts.c (get_vectype_for_scalar_type_and_size): Handle over-aligned scalar types properly. 2012-10-02 Richard Guenther rguent...@suse.de PR middle-end/54735 * tree-ssa-pre.c (do_pre): Make sure to update virtual SSA form before cleaning up the CFG. 2012-10-12 Richard Biener rguent...@suse.de PR tree-optimization/54894 * gcc.dg/torture/pr54894.c: New testcase. 2012-10-02 Richard Guenther rguent...@suse.de PR middle-end/54735 * g++.dg/torture/pr54735.C: New testcase. Added: branches/gcc-4_7-branch/gcc/testsuite/g++.dg/torture/pr54735.C branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr54894.c Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/gcc/tree-ssa-pre.c branches/gcc-4_7-branch/gcc/tree-vect-stmts.c
[Bug tree-optimization/54976] [4.8 Regression] FAIL: gcc.dg/torture/pr47975.c (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54976 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org 2012-11-26 14:26:16 UTC --- Author: rguenth Date: Mon Nov 26 14:26:07 2012 New Revision: 193816 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193816 Log: 2012-11-26 Richard Biener rguent...@suse.de Backport from mainline 2012-10-19 Richard Biener rguent...@suse.de PR tree-optimization/54976 * tree-vect-stmts.c (get_vectype_for_scalar_type_and_size): Robustify against odd inner_mode inputs. 2012-10-12 Richard Biener rguent...@suse.de PR tree-optimization/54894 * tree-vect-stmts.c (get_vectype_for_scalar_type_and_size): Handle over-aligned scalar types properly. 2012-10-02 Richard Guenther rguent...@suse.de PR middle-end/54735 * tree-ssa-pre.c (do_pre): Make sure to update virtual SSA form before cleaning up the CFG. 2012-10-12 Richard Biener rguent...@suse.de PR tree-optimization/54894 * gcc.dg/torture/pr54894.c: New testcase. 2012-10-02 Richard Guenther rguent...@suse.de PR middle-end/54735 * g++.dg/torture/pr54735.C: New testcase. Added: branches/gcc-4_7-branch/gcc/testsuite/g++.dg/torture/pr54735.C branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr54894.c Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/gcc/tree-ssa-pre.c branches/gcc-4_7-branch/gcc/tree-vect-stmts.c
[Bug tree-optimization/54735] [4.7 Regression] Segmentation fault in walk_aliased_vdefs_1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54735 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #16 from Richard Biener rguenth at gcc dot gnu.org 2012-11-26 14:27:09 UTC --- Fixed.
[Bug tree-optimization/54894] [4.6 Regression] internal compiler error: in vect_get_vec_def_for_operand, at tree-vect-stmts.c:1286
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54894 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||4.7.2 Summary|[4.6/4.7 Regression]|[4.6 Regression] internal |internal compiler error: in |compiler error: in |vect_get_vec_def_for_operan |vect_get_vec_def_for_operan |d, at |d, at |tree-vect-stmts.c:1286 |tree-vect-stmts.c:1286 Known to fail||4.7.1 --- Comment #9 from Richard Biener rguenth at gcc dot gnu.org 2012-11-26 14:27:23 UTC --- Fixed for 4.7 as well.
[Bug middle-end/54838] [4.8 Regression] ICE: in merge_latch_edges, at cfgloop.c:678 with -ftracer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54838 --- Comment #8 from Marek Polacek mpolacek at gcc dot gnu.org 2012-11-26 14:29:59 UTC --- Patch posted: http://gcc.gnu.org/ml/gcc-patches/2012-11/msg02095.html
[Bug debug/55467] Wrong value for optimized debug, variants of gcc.dg/guality/pr36728-2.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55467
--- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-26
14:37:48 UTC ---
I disagree. You can't see optimized out for aggregate var in memory which
actually has been allocated on the stack, VTA doesn't value track those (and
can't really), there you just have a variable with description where in memory
it is and whatever is on the stack there is what you get.
As for the other testcase, that is just a testcase problem you've introduced by
removing the volatile from the asm. Without volatile the compiler is free to
schedule the second asm before the first one (and does for e.g. -m32 -O2), but
at that point y obviously isn't initialized. If volatile can't be used there,
you'd need something like:
@@ -2,6 +2,9 @@
/* { dg-do run } */
/* { dg-options -g } */
+#include ../nop.h
+
+int a;
int __attribute__((noinline))
foo (int arg1, int arg2, int arg3, int arg4, int arg5, int arg6, int arg7)
{
@@ -9,9 +12,9 @@ foo (int arg1, int arg2, int arg3, int a
int __attribute__ ((aligned(32))) y;
y = 2;
- asm ( : =m (y) : m (y));
+ asm (NOP : =m (y), =m (a) : m (y));
x[0] = 25;
- asm ( : =m (x[0]) : m (x[0]));
+ asm (NOP : =m (x[0]) : m (x[0]), m (a));
return y + x[0];
}
plus adjust line numbers in gdb-test lines. The - NOP change is desirable
in any way, as the test wants to stop on the inline asm, if the inline asm is
empty, it stops on the following insn rather than on the inline asm.
[Bug c++/51242] [C++11] Unable to use strongly typed enums as bit fields
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242 --- Comment #24 from Jonathan Wakely redi at gcc dot gnu.org 2012-11-26 14:40:20 UTC --- I think naming the warning would make sense, so it can be disabled by people who want to use scoped enums with bit-fields
[Bug middle-end/52650] [4.8 Regression] FAIL: gcc.dg/torture/pr51106-2.c * (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52650 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1
[Bug middle-end/52650] [4.8 Regression] FAIL: gcc.dg/torture/pr51106-2.c * (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52650 --- Comment #15 from dave.anglin at bell dot net 2012-11-26 14:58:12 UTC --- On 11/26/2012 4:47 AM, gjl at gcc dot gnu.org wrote: A milestone of 3.0.x?? It seems I did this while updating the Last reconfirmed date. As I understand it, it's a Firefox feature that arises when the web page is inconsistent with cached browser page.
[Bug lto/55466] [4.8 Regression] Revision 191466 destroyed DWARF debug info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55466 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug lto/55466] [4.8 Regression] Revision 191466 destroyed DWARF debug info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55466 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org 2012-11-26 15:57:37 UTC --- (In reply to comment #1) /export/project/git/gcc-regression-bootstrap/master/191466/bld/gcc/cc1...done. (gdb) whatis global_options type = data variable, no debug info (gdb) whatis cl_options type = data variable, no debug info (gdb) whatis cl_enums type = data variable, no debug info (gdb) whatis cl_enums_count type = data variable, no debug info (gdb) whatis global_options_set type = data variable, no debug info (gdb) whatis sched_max_luid type = data variable, no debug info (gdb) Hmm, I suppose this is because we no longer merge symbols that are not part of symtab, but used only for debugging Honza global_options is certainly used. Aggressively removing unused vars is ok even if that drops debug info for them.
[Bug lto/55466] [4.8 Regression] Revision 191466 destroyed DWARF debug info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55466 --- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2012-11-26 16:36:10 UTC --- (In reply to comment #2) Hmm, I suppose this is because we no longer merge symbols that are not part of symtab, but used only for debugging Honza global_options is certainly used. Aggressively removing unused vars is ok even if that drops debug info for them. We lost debug info on most, if not all, used data variables. It seems that their type infos are also gone. We can't tell extern int *foo; from extern int foo[];
[Bug middle-end/52650] [4.8 Regression] FAIL: gcc.dg/torture/pr51106-2.c * (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52650 --- Comment #16 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-26 16:36:10 UTC --- Created attachment 28778 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28778 gcc48-pr52650.patch P1 for an error-recovery bug sounds way too high, those should be P4-ish. Anyway, sounds much easier to me to just not delete the invalid asm goto at all and instead just drop the invalid inputs (and template to avoid further warnings/failures). asm goto doesn't have outputs, and the expander should ensure all the labels are LABEL_REFs, so that part of check_asm_operands shouldn't fail.
[Bug fortran/55465] Name collision in C binding (calling C from Fortran)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55465 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org --- Comment #3 from janus at gcc dot gnu.org 2012-11-26 16:37:31 UTC --- (In reply to comment #0) Essentially I am trying to use the binding to call from Fortran the same C function in two different ways. The interface sql_set_env_attr has two implementations, one sql_set_env_attr_int where the parameter value is passed as c_int and another one sql_set_env_attr_ptr where the parameter value is passed as c_ptr. I'm not sure if this is legal. In any case, here is a reduced test case: module m_odbc_if implicit none interface sql_set_env_attr function sql_set_env_attr_int( input_handle,attribute,value,length ) result(res) bind(C,name=SQLSetEnvAttr) use, intrinsic :: iso_c_binding implicit none type(c_ptr), value :: input_handle integer(c_int), value :: attribute integer(c_int), value :: value integer(c_int), value :: length integer(c_short) :: res end function function sql_set_env_attr_ptr( input_handle,attribute,value,length ) result(res) bind(C,name=SQLSetEnvAttr) use, intrinsic :: iso_c_binding implicit none type(c_ptr), value :: input_handle integer(c_int), value :: attribute type(c_ptr), value :: value integer(c_int), value :: length integer(c_short) :: res end function end interface end module
[Bug fortran/54572] Use libbacktrace library
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54572 Janne Blomqvist jb at gcc dot gnu.org changed: What|Removed |Added CC||ian at airs dot com --- Comment #5 from Janne Blomqvist jb at gcc dot gnu.org 2012-11-26 16:43:16 UTC --- Bummer, I've hit a snag. Otherwise the patch works, but trying to do a symbolic backtrace from a signal handler fails (which was sort of the entire idea of using libbacktrace instead of forking addr2line). Ian, any idea what might go wrong? With the testcase below which is expected to fail due to a div-by-zero: module test contains subroutine c(num, denum, res) integer :: num, denum, res res = num / denum end subroutine c subroutine b(n, d, r) integer :: n, d, r call c(n, d, r) end subroutine b subroutine a(n, d, r) integer :: n, d, r call b(n, d, r) end subroutine a end module test program bt use test integer :: res call a(1, 0, res) print *, res end program bt compiled with -g the result is $ ./bt2.g Program received signal SIGFPE: Floating-point exception - erroneous arithmetic operation. Backtrace for this error: Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: Segmentation fault (core dumped) backtrace via gdb: (gdb) r Starting program: /home/janne/src/gfortran/my-patches/pr54572-libbacktrace/bt2.g Program received signal SIGFPE, Arithmetic exception. 0x0040086b in __test_MOD_c () (gdb) c Continuing. Program received signal SIGFPE: Floating-point exception - erroneous arithmetic operation. Backtrace for this error: Program received signal SIGSEGV, Segmentation fault. 0x77bb2a1c in read_uint32 () from /home/janne/src/gfortran/trunk/install/lib64/libgfortran.so.3 (gdb) bt #0 0x77bb2a1c in read_uint32 () from /home/janne/src/gfortran/trunk/install/lib64/libgfortran.so.3 #1 0x77bb53be in backtrace_dwarf_add () from /home/janne/src/gfortran/trunk/install/lib64/libgfortran.so.3 #2 0x77bb72a7 in elf_add () from /home/janne/src/gfortran/trunk/install/lib64/libgfortran.so.3 #3 0x77bb7696 in backtrace_initialize () from /home/janne/src/gfortran/trunk/install/lib64/libgfortran.so.3 #4 0x77bb630d in fileline_initialize () from /home/janne/src/gfortran/trunk/install/lib64/libgfortran.so.3 #5 0x77bb6427 in backtrace_pcinfo () from /home/janne/src/gfortran/trunk/install/lib64/libgfortran.so.3 #6 0x77bb6831 in unwind () from /home/janne/src/gfortran/trunk/install/lib64/libgfortran.so.3 #7 0x775b9ec9 in _Unwind_Backtrace () from /home/janne/src/gfortran/trunk/install/lib64/libgcc_s.so.1 #8 0x77bb6885 in backtrace_full () from /home/janne/src/gfortran/trunk/install/lib64/libgfortran.so.3 #9 0x77ad527e in _gfortrani_show_backtrace () at ../../../trunk-git/libgfortran/runtime/backtrace.c:92 #10 0x77ad5888 in _gfortrani_backtrace_handler () at ../../../trunk-git/libgfortran/runtime/compile_options.c:129 #11 signal handler called #12 0x0040086b in __test_MOD_c () #13 0x00400848 in __test_MOD_b () #14 0x0040081b in __test_MOD_a () #15 0x00400898 in MAIN__ () #16 0x00400930 in main () #17 0x76fd176d in __libc_start_main (main=0x4008fc main, argc=1, ubp_av=0x7fffd718, init=optimized out, fini=optimized out, rtld_fini=optimized out, stack_end=0x7fffd708) at libc-start.c:226 #18 0x00400709 in _start () For comparison, if I compile the testcase without -g then it works as expected: $ ./bt2 Program received signal SIGFPE: Floating-point exception - erroneous arithmetic operation. Backtrace for this error: 0x7fcf58e202a0 0x7fcf58e20887 0x7fcf5833149f 0x40086b 0x400847 0x40081a 0x400897 0x40092f 0x7fcf5831c76c 0x400708 Floating point exception (core dumped)
[Bug middle-end/52650] [4.8 Regression] FAIL: gcc.dg/torture/pr51106-2.c * (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52650 --- Comment #17 from dave.anglin at bell dot net 2012-11-26 16:43:18 UTC --- On 11/26/2012 11:36 AM, jakub at gcc dot gnu.org wrote: P1 for an error-recovery bug sounds way too high, those should be P4-ish. I just restored the previous setting. No objection to revising it downward.
[Bug fortran/54572] Use libbacktrace library
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54572 --- Comment #6 from Janne Blomqvist jb at gcc dot gnu.org 2012-11-26 16:46:08 UTC --- Created attachment 28779 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28779 Patch to use libbacktrace
[Bug fortran/55465] Name collision in C binding (calling C from Fortran)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55465 --- Comment #4 from janus at gcc dot gnu.org 2012-11-26 17:08:20 UTC --- Note: The same behavior occurs with all gfortran versions I tried (4.3, 4.6, 4.7 and trunk). The check which rejects it is in gfc_verify_binding_labels (resolve.c). It was committed with the inital ISO_C_BINDING patch: http://gcc.gnu.org/viewcvs?view=revisionrevision=126185 This commit also includes a test case which is basically equivalent to the one in comment 3 (i.e. two interfaces binding to the same label): http://gcc.gnu.org/viewcvs/trunk/gcc/testsuite/gfortran.dg/binding_label_tests_3.f03?view=markup So it seems that this error is indeed triggered on purpose and not by accident. It may well be that ifort just fails to detect this error (ifort is not exactly known for good diagnostics). Have you checked other compilers?
[Bug fortran/55465] Name collision in C binding (calling C from Fortran)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55465 --- Comment #5 from Fran Martinez Fadrique fmartinez at gmv dot com 2012-11-26 17:36:04 UTC --- I have also tried with ekopath and g95 and both take it without a diagnostic. I have been checking section 15.4 of the ISO standard and I have found nothing that forbids that two fortran procedures have the same binding label. But this is just my interpretation.
[Bug fortran/55465] Name collision in C binding (calling C from Fortran)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55465 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid CC||burnus at gcc dot gnu.org Depends on||48858 --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org 2012-11-26 17:40:49 UTC --- (In reply to comment #3) I'm not sure if this is legal. In any case, here is a reduced test case: The issue is in related to PR 48858; I think the code is valid on most 32bit (e.g. x32-gnu-linux, i386-gnu-linux) systems. I also find the standard a bit confusing, but I think it is supposed to be valid - cf. bug 48858 comment 9. Regarding the specific issue: integer(c_int), value :: value vs. type(c_ptr), value :: value On a 64 bit system it is invalid as int (integer(c_int),value) is a 32 bit value and void* (type(c_ptr),value) is a 64 bit pointer. If value is supposed to be a pointer address, it should use integer(c_intptr_t). I think that's the case as I find SQLPOINTER ValuePtr in the references to SQLSetEnvAttr.
[Bug debug/55467] Wrong value for optimized debug, variants of gcc.dg/guality/pr36728-2.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55467 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Comment #7 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-11-26 18:02:41 UTC --- (In reply to comment #6) Without volatile the compiler is free to schedule the second asm before the first one (and does for e.g. -m32 -O2), Oh, that's what's happening. Wicked. ... The - NOP change is desirable in any way, as the test wants to stop on the inline asm, if the inline asm is empty, it stops on the following insn rather than on the inline asm. Yes. That break-on-empty-asm-line bothered me a little, but I shrugged it off, thinking the author probably intended what was there. ;) Nice with the nop.h. Ok, re-closing this.
[Bug target/55277] [4.8 regression] ICE in assign_by_spills, at lra-assigns.c:1217
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55277 --- Comment #2 from Vladimir Makarov vmakarov at gcc dot gnu.org 2012-11-26 18:08:50 UTC --- Author: vmakarov Date: Mon Nov 26 18:08:44 2012 New Revision: 193824 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193824 Log: 2012-11-26 Vladimir Makarov vmaka...@redhat.com PR target/55277 * gcc.target/i386/pr55227.c: New test. 2012-11-26 Vladimir Makarov vmaka...@redhat.com PR target/55277 * lra-constraints.c (in_class_p): Check reg class contents too. Added: trunk/gcc/testsuite/gcc.target/i386/pr55277.c Modified: trunk/gcc/ChangeLog trunk/gcc/lra-constraints.c trunk/gcc/testsuite/ChangeLog
[Bug c++/55471] New: c++ mutex does not work as expected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55471
Bug #: 55471
Summary: c++ mutex does not work as expected
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gust...@atc.ugr.es
Created attachment 28780
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28780
source code with the bug
In a small test with a mutex it does not block all threads.
The bug is triggered by the place the mutex is declared:
* When the mutex is declared global it does not work.
* When it is a local variable it does work.#include iostream
#include mutex
#include thread
std::mutex m; // this program fails when m is a global variable
int main()
{
const unsigned N = 10;
// std::mutex m; // with m here everything is allright
for(unsigned i = 0; i N; ++i)
new std::thread([]()
{
while(true)
{
m.lock();
std::cout [ std::this_thread::get_id() ]: ;
for(unsigned i = 0; i 10; ++i)
std::cout i;
std::cout std::endl;
m.unlock();
}
});
std::this_thread::sleep_for(std::chrono::seconds(1));
}
[Bug c++/55245] [4.6/4.7/4.8 Regression] Compiler segfault when compiling a small test case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55245 --- Comment #7 from Diego Novillo dnovillo at gcc dot gnu.org 2012-11-26 18:35:43 UTC --- Author: dnovillo Date: Mon Nov 26 18:35:38 2012 New Revision: 193825 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193825 Log: Google ref b/7500842. 2012-11-26 Diego Novillo dnovi...@google.com * gimplify.c: Work around for PR 55245. testsuite/ChangeLog.google-integration * g++.dg/pr55245.C: New. Added: branches/google/gcc-4_7/gcc/testsuite/g++.dg/pr55245.C Modified: branches/google/gcc-4_7/gcc/ChangeLog.google-4_7 branches/google/gcc-4_7/gcc/gimplify.c branches/google/gcc-4_7/gcc/testsuite/ChangeLog.google-4_7
[Bug c++/55471] c++ mutex does not work as expected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55471 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-11-26 Ever Confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-11-26 18:38:31 UTC --- what command are you using to compile? what platform are you using? what do you mean by does not work? Please read http://gcc.gnu.org/bugs/ and provide a full bug report.
[Bug testsuite/52641] Test cases fail for 16-bit int targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52641 --- Comment #8 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-11-26 18:46:25 UTC --- Author: gjl Date: Mon Nov 26 18:46:12 2012 New Revision: 193826 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193826 Log: PR testsuite/52641 * gcc.c-torture/execute/20120919-1.x: New file (int32plus). * gcc.dg/pr54676.c: Make work for 16-bit int. Added: trunk/gcc/testsuite/gcc.c-torture/execute/20120919-1.x Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/pr54676.c
[Bug libstdc++/55471] c++ mutex does not work as expected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55471 gustavo gustavo at atc dot ugr.es changed: What|Removed |Added Host||fedora 17 --- Comment #2 from gustavo gustavo at atc dot ugr.es 2012-11-26 18:52:29 UTC --- (In reply to comment #1) what command are you using to compile? g++ -D _GLIBCXX_USE_NANOSLEEP -O3 -std=c++0x -Wall -Wl,--no-as-needed -lpthread -lrt bug.cc -o bug what platform are you using? fedora 17 what do you mean by does not work? Output must be [thread number]: 0123456789 repeated for 10 threads for a second. The bug is easily discovered using: ./bug | sort | uniq [140087293904640]: 0123456789 [140087302297344]: 0123456789 [140087310690048]: 0123456789 [140087319082752]: 0123456789 [140087327475456]: 0123456789 [140087335868160]: 0123456789 [140087344260864]: 0123456789 [140087352653568]: 0123456789 [140087361046272]: 0123456789 [140087369438976 [140087369438976]: 01234[140087369438976]: 0123456789 [140087369438976]: 0123456[140087369438976]: 0123456789 [140087369438976]: 0123456789 Clearly the output is bunch of mixed strings instead of many [thread number]: 0123456789
[Bug libstdc++/55471] c++ mutex does not work as expected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55471 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW Host|fedora 17 | --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2012-11-26 19:11:07 UTC --- Defining _GLIBCXX_USE_NANOSLEEP manually is not supported, you should build GCC with --enable-libstdcxx-time, however that's not the problem here. I'll look into what's happening.
[Bug libstdc++/55471] c++ mutex does not work as expected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55471
--- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2012-11-26
19:23:22 UTC ---
If you change the code to join the threads instead of leaving them running when
the program exits then the output is correct.
#include iostream
#include mutex
#include thread
#include atomic
std::mutex m;
int main()
{
const unsigned N = 10;
std::atomicbool run(true);
std::thread t[N];
for(unsigned i = 0; i N; ++i)
t[i] = std::thread([]()
{
while(run)
{
m.lock();
std::cout [ std::this_thread::get_id() ]: ;
for(unsigned i = 0; i 10; ++i)
std::cout i;
std::cout std::endl;
m.unlock();
}
});
std::this_thread::sleep_for(std::chrono::seconds(1));
run = false;
for(unsigned i = 0; i N; ++i)
t[i].join();
}
[Bug libstdc++/55471] c++ mutex does not work as expected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55471 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2012-11-26 19:24:38 UTC --- Almost certainly what happens is that the mutex m gets destroyed when returning from main, but there are threads still using it and so they can no longer lock it. It's undefined behaviour to lock a mutex after its destructor starts, so this is a bug in your program, not GCC.
[Bug libstdc++/55471] c++ mutex does not work as expected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55471 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org 2012-11-26 19:26:43 UTC --- See [basic.start.term] in the standard If there is a use of a standard library object or function not permitted within signal handlers (18.10) that does not happen before (1.10) completion of destruction of objects with static storage duration and execution of std::atexit registered functions (18.5), the program has undefined behavior. [Note: If there is a use of an object with static storage duration that does not happen before the object’s destruction, the program has undefined behavior. Terminating every thread before a call to std::exit or the exit from main is sufficient, but not necessary, to satisfy these requirements. These requirements permit thread managers as static-storage-duration objects. —end note ]
[Bug middle-end/32647] spill failures with hard-register variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32647 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Blocks||55277 --- Comment #3 from Uros Bizjak ubizjak at gmail dot com 2012-11-26 19:32:14 UTC --- LRA ICEs with following backtrace (-O2) on x86_64: pr32647.c: In function ‘f’: pr32647.c:6:1: internal compiler error: in assign_by_spills, at lra-assigns.c:1212 } ^ 0x7f41a1 assign_by_spills ../../gcc-svn/trunk/gcc/lra-assigns.c:1212 0x7f41a1 lra_assign() ../../gcc-svn/trunk/gcc/lra-assigns.c:1364 0x7f1626 lra(_IO_FILE*) ../../gcc-svn/trunk/gcc/lra.c:2306 0x7b9038 do_reload ../../gcc-svn/trunk/gcc/ira.c:4624 0x7b9038 rest_of_handle_reload ../../gcc-svn/trunk/gcc/ira.c:4737 The failure is similar to PR55277.
[Bug middle-end/54630] [4.8 Regression] GCC 4.8 --enable-languages=c build fails: Undefined symbols: ___cxa_guard_acquire and ___cxa_guard_release
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54630 --- Comment #19 from Larry Baker baker at usgs dot gov 2012-11-26 19:44:21 UTC --- (In reply to comment #18) Ian, You can also add linker options via the configure options --with-stage1-ldflags and --with-boot-ldflags, q.v. So, I read what the GCC configure notes had to say about --with-boot-ldflags=flags, and it sounds like exactly what Sourceery was trying to do with --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm'. That is, the default is to statically link the C and C++ run-time libraries. --with-boot-ldflags=flags This option may be used to set linker flags to be used when linking stage 2 and later when bootstrapping GCC. If neither –with-boot-libs nor –with-host-libstdcxx is set to a value, then the default is `-static-libstdc++ -static-libgcc'. Although it is not documented specifically for GCC, you can also set LDFLAGS when running make, as you can for all GNU programs. I might have already tried this and it fails. (I can't remember exactly.) Take a look at my Comment 6 from 2012-09-21 20:34:41. You'll see that the GCC build machinery overrides CFLAGS and LDFLAGS with CFLAGS_FOR_BUILD and LDFLAGS_FOR_BUILD, respectively. I think your first suggestion is definitely the best solution. The next time I work on this, I'll check the results of the link of the cross gcc to see if the default stage 2 build really does eliminate the dependencies on the shared C and C++ run-time libraries. Thanks.
[Bug c++/55472] New: Linker cannot find lambda symbol
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55472
Bug #: 55472
Summary: Linker cannot find lambda symbol
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: walker_...@yahoo.com
Created attachment 28781
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28781
Test Case
gcc -v:
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.7.2-4precise1' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs
--enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.7 --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.7
--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 --disable-werror --with-arch-32=i686
--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.7.2 (Ubuntu/Linaro 4.7.2-4precise1)
build command: g++ -Wall -Wextra -std=c++11 -o lambda lambda.cpp
linker output:
/tmp/ccbAcPGU.o: In function `Foo::Foo(std::functionvoid
())::{lambda(Foo*)#1}::operator void (*)(Foo*)() const':
lambda.cpp:(.text._ZZN3FooC1ESt8functionIFvvEEENKUlPS_E_cvPFvS3_EEv[_ZZN3FooC1ESt8functionIFvvEEENKUlPS_E_cvPFvS3_EEv]+0x9):
undefined reference to `Foo::Foo(std::functionvoid
())::{lambda(Foo*)#1}::_FUN(Foo*)'
collect2: error: ld returned 1 exit status
[Bug libstdc++/55471] c++ mutex does not work as expected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55471 gustavo gustavo at atc dot ugr.es changed: What|Removed |Added Status|RESOLVED|NEW Resolution|INVALID | --- Comment #7 from gustavo gustavo at atc dot ugr.es 2012-11-26 19:45:37 UTC --- thanks a million
[Bug c++/55472] Linker cannot find lambda symbol
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55472 --- Comment #1 from walker_643 at yahoo dot com 2012-11-26 19:48:15 UTC --- I believe the code to be valid C++11, and, indeed it does compile, link, and run on gcc 4.5 (as seen here http://ideone.com/VvFuMs ), but no GCC versions 4.7 - 4.8 are able to link properly.
[Bug fortran/55465] Name collision in C binding (calling C from Fortran)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55465 Juno Krahn juno.krahn at nih dot gov changed: What|Removed |Added CC||juno.krahn at nih dot gov --- Comment #7 from Juno Krahn juno.krahn at nih dot gov 2012-11-26 19:51:55 UTC --- IMHO, this is valid code regardless of whether the binary argument types can be seen as equivalent. The standard is quite vague, but see my comment at bug 48858 comment 13. The standard defines that the binding label itself is a unique global entity, but does not specify that the interface definition is unique.
[Bug libquadmath/55473] New: quadmath.h should have extern C for C++ users
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55473
Bug #: 55473
Summary: quadmath.h should have extern C for C++ users
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: libquadmath
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: j...@gcc.gnu.org
quadmath.h is missing something like:
#ifdef __cplusplus
extern C {
#endif
/* Content of file */
#ifdef __cplusplus
} /* End extern C. */
#endif
As it is, C++ users who wish to use libquadmath have to do this manually before
including quadmath.h. E.g.
http://gcc.gnu.org/ml/gcc-help/2011-06/msg00148.html
or for a more recent example
http://stackoverflow.com/questions/13571621/quadruple-precision-in-g-4-6-3-linux-using-quadmath
[Bug fortran/55465] Name collision in C binding (calling C from Fortran)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55465 --- Comment #8 from Juno Krahn juno.krahn at nih dot gov 2012-11-26 19:55:11 UTC --- Also, I should have mentioned that multiple interface specs used to work in Gnu Fortran, and it still works in current Intel, Sun and Open64 Fortran compilers.
[Bug fortran/55465] Name collision in C binding (calling C from Fortran)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55465 Harald Anlauf anlauf at gmx dot de changed: What|Removed |Added CC||anlauf at gmx dot de --- Comment #9 from Harald Anlauf anlauf at gmx dot de 2012-11-26 20:20:24 UTC --- (In reply to comment #7) IMHO, this is valid code regardless of whether the binary argument types can be seen as equivalent. The standard is quite vague, but see my comment at bug 48858 comment 13. The standard defines that the binding label itself is a unique global entity, but does not specify that the interface definition is unique. Well, then somebody should also complain to NAG. The code in comment #6 fails to compile. % nagfor -c -f2003 pr55465.f90 NAG Fortran Compiler Release 5.3.1(907) Error: pr55465.f90: Duplicate binding label 'SQLSetEnvAttr' for external procedure SQL_SET_ENV_ATTR_INT and external procedure SQL_SET_ENV_ATTR_PTR [NAG Fortran Compiler error termination, 1 error]
[Bug fortran/55465] Name collision in C binding (calling C from Fortran)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55465 --- Comment #10 from Harald Anlauf anlauf at gmx dot de 2012-11-26 20:24:56 UTC --- (In reply to comment #9) Well, then somebody should also complain to NAG. The code in comment #6 fails to compile. And to IBM. % xlf -qversion IBM XL Fortran for AIX, V14.1 (5765-J04, 5725-C74) Version: 14.01..0001 % xlf2008 -c pr55465.f90 -qlanglvl=2008pure pr55465.f90, line 16.4: 1516-194 (S) A binding label must not be the same as the name of a program unit, common block, external procedure, and another binding label, ignoring differences in case. pr55465.f90, 1516-036 (S) Entity sql_set_env_attr_ptr has undefined type. ** m_odbc_if === End of Compilation 1 === 1501-511 Compilation failed for file pr55465.f90.
[Bug lto/55474] New: global-buffer-overflow in lto-wrapper.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55474 Bug #: 55474 Summary: global-buffer-overflow in lto-wrapper.c Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com On Linux/x86-64, hjl/asan branch configured with --with-build-config=bootstrap-asan reports: [hjl@gnu-mic-1 gcc]$ /export/build/gnu/gcc-x32-mx32-asan/build-x86_64-linux/gcc/xgcc -B/export/build/gnu/gcc-x32-mx32-asan/build-x86_64-linux/gcc/ /export/gnu/import/git/gcc/gcc/testsuite/gcc.c-torture/execute/builtins/20010124-1.c /export/gnu/import/git/gcc/gcc/testsuite/gcc.c-torture/execute/builtins/20010124-1-lib.c /export/gnu/import/git/gcc/gcc/testsuite/gcc.c-torture/execute/builtins/lib/main.c -fno-diagnostics-show-caret -w -O2 -flto -fno-use-linker-plugin -flto-partition=none -fno-tree-loop-distribute-patterns -lm = ==22576== ERROR: AddressSanitizer: global-buffer-overflow on address 0x004d24c4 at pc 0x405ac6 bp 0xca30 sp 0xca2c READ of size 4 at 0x004d24c4 thread T0 #0 0x405ac5 (/export/build/gnu/gcc-x32-mx32-asan/build-x86_64-linux/gcc/lto-wrapper+0x405ac5) 0x004d24c4 is located 28 bytes to the left of global variable 'global_options_init (options.c)' (0x4d24e0) of size 2440 0x004d24c4 is located 24 bytes to the right of global variable 'lang_names (options.c)' (0x4d2480) of size 44 Shadow byte and word: 0x2009a498: f9 0x2009a498: f9 f9 f9 f9 More shadow bytes: 0x2009a488: 04 f9 f9 f9 0x2009a48c: f9 f9 f9 f9 0x2009a490: 00 00 00 00 0x2009a494: 00 04 f9 f9 =0x2009a498: f9 f9 f9 f9 0x2009a49c: 00 00 00 00 0x2009a4a0: 00 00 00 00 0x2009a4a4: 00 00 00 00 0x2009a4a8: 00 00 00 00 Stats: 0M malloced (0M for red zones) by 142 calls Stats: 0M realloced by 4 calls Stats: 0M freed by 44 calls Stats: 0M really freed by 0 calls Stats: 3M (898 full pages) mmaped in 7 calls mmaps by size class: 7:4095; 8:2047; 9:1023; 10:511; 11:255; 12:128; 13:64; mallocs by size class: 7:103; 8:12; 9:12; 10:8; 11:1; 12:1; 13:5; frees by size class: 7:27; 8:2; 9:6; 10:5; 11:1; 13:3; rfrees by size class: Stats: malloc large: 0 small slow: 8 ==22576== ABORTING collect2: error: lto-wrapper returned 1 exit status [hjl@gnu-mic-1 gcc]$ addr2line -e /export/build/gnu/gcc-x32-mx32-asan/build-x86_64-linux/gcc/lto-wrapper 0x405ac5 /export/gnu/import/git/gcc/gcc/lto-wrapper.c:397 [hjl@gnu-mic-1 gcc]$
[Bug fortran/55475] New: heap-buffer-overflow in fortran/error.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55475 Bug #: 55475 Summary: heap-buffer-overflow in fortran/error.c Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com [hjl@gnu-mic-1 gfortran]$ /export/build/gnu/gcc-x32-mx32-asan/build-x86_64-linux/gcc/testsuite/gfortran6/../../gfortran -B/export/build/gnu/gcc-x32-mx32-asan/build-x86_64-linux/gcc/testsuite/gfortran6/../../ -B/export/build/gnu/gcc-x32-mx32-asan/build-x86_64-linux/x86_64-unknown-linux-gnu/./libgfortran/ /export/gnu/import/git/gcc/gcc/testsuite/gfortran.dg/line_length_4.f90 -fno-diagnostics-show-caret -O -Wline-truncation -ffree-line-length-80 -S -mx32 -o line_length_4.s /export/gnu/import/git/gcc/gcc/testsuite/gfortran.dg/line_length_4.f90:8.85: 25 ), Explanation ! = ==18910== ERROR: AddressSanitizer: heap-buffer-overflow on address 0xf6820398 at pc 0x583c85 bp 0x9ed0 sp 0x9ecc READ of size 4 at 0xf6820398 thread T0 #0 0x583c84 (/export/build/gnu/gcc-x32-mx32-asan/build-x86_64-linux/gcc/f951+0x583c84) 0xf6820398 is located 0 bytes to the right of 344-byte region [0xf6820240,0xf6820398) allocated by thread T0 here: #0 0x24ae2dc (/export/build/gnu/gcc-x32-mx32-asan/build-x86_64-linux/gcc/f951+0x24ae2dc) #1 0x24a2c63 (/export/build/gnu/gcc-x32-mx32-asan/build-x86_64-linux/gcc/f951+0x24a2c63) Shadow byte and word: 0x3ed04073: fb 0x3ed04070: 00 00 00 fb More shadow bytes: 0x3ed04060: 00 00 00 00 0x3ed04064: 00 00 00 00 0x3ed04068: 00 00 00 00 0x3ed0406c: 00 00 00 00 =0x3ed04070: 00 00 00 fb 0x3ed04074: fb fb fb fb 0x3ed04078: fa fa fa fa 0x3ed0407c: fa fa fa fa 0x3ed04080: fa fa fa fa Stats: 0M malloced (0M for red zones) by 3129 calls Stats: 0M realloced by 312 calls Stats: 0M freed by 961 calls Stats: 0M really freed by 0 calls Stats: 5M (1285 full pages) mmaped in 10 calls mmaps by size class: 7:4095; 8:2047; 9:1023; 10:511; 11:255; 12:128; 13:64; 14:32; 15:16; 17:4; mallocs by size class: 7:2646; 8:171; 9:77; 10:138; 11:81; 12:4; 13:7; 14:1; 15:2; 17:2; frees by size class: 7:688; 8:62; 9:68; 10:132; 11:9; 12:1; 13:1; rfrees by size class: Stats: malloc large: 4 small slow: 30 ==18910== ABORTING[hjl@gnu-mic-1 gfortran]$ addr2line -e ../../f951 0x583c84 /export/gnu/import/git/gcc/gcc/fortran/error.c:393 [hjl@gnu-mic-1 gfortran]$
[Bug fortran/55465] Name collision in C binding (calling C from Fortran)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55465 --- Comment #11 from Harald Anlauf anlauf at gmx dot de 2012-11-26 20:57:53 UTC --- I'm also having difficulties to see how the interface definition could be standard compatible. The F2k8 draft says: 15.5.1 Definition and reference of interoperable procedures A procedure that is interoperable may be defined either by means other than Fortran or by means of a Fortran subprogram, but not both. If the procedure is defined by means other than Fortran, it shall • be describable by a C prototype that is interoperable with the interface, • have a name that has external linkage as defined by 6.2.2 of ISO/IEC 9899:1999, and • have the same binding label as the interface. Can somebody show the C prototype of the function SQLSetEnvAttr()? Note that allowed prototypes are restricted by 15.3.7 Interoperability of procedures and procedure interfaces and in particular: (4) any dummy argument with the VALUE attribute is interoperable with the corresponding formal parameter of the prototype, (6) the prototype does not have variable arguments as denoted by the ellipsis (...).
[Bug libstdc++/55471] c++ mutex does not work as expected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55471 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org 2012-11-26 21:26:15 UTC --- .
[Bug fortran/55476] New: [4.8 Regression] Bogus warning Pointer might outlive the pointer target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55476 Bug #: 55476 Summary: [4.8 Regression] Bogus warning Pointer might outlive the pointer target Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: ja...@gcc.gnu.org Consider the following test case: subroutine test integer, pointer :: p integer, target :: t p = t contains subroutine sub() if (p /= 0) return end subroutine end subroutine Compiling with gfortran trunk using -Wall yields: p = t 1 Warning: Pointer at (1) in pointer assignment might outlive the pointer target I don't see how the pointer can outlive the target here (since both have the same scope). gfortran 4.7 does not throw this warning.
[Bug c++/55472] Linker cannot find lambda symbol
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55472 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-26 Known to work||4.6.3 Version|unknown |4.7.2 Blocks||54367 Ever Confirmed|0 |1 Known to fail||4.7.2, 4.8.0
[Bug fortran/55476] [4.8 Regression] Bogus warning Pointer might outlive the pointer target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55476 janus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from janus at gcc dot gnu.org 2012-11-26 21:44:43 UTC --- This regression has certainly been introduced by the following commit: http://gcc.gnu.org/viewcvs?view=revisionrevision=190522
[Bug fortran/55475] heap-buffer-overflow in fortran/error.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55475 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-26 CC||burnus at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-11-26 21:59:32 UTC --- Draft patch: --- a/gcc/fortran/scanner.c +++ b/gcc/fortran/scanner.c @@ -1070,6 +1070,8 @@ restart: int maxlen = gfc_option.free_line_length; + gfc_char_t *current_nextc = gfc_current_locus.nextc; + gfc_current_locus.lb-truncated = 0; - gfc_current_locus.nextc += maxlen; + gfc_current_locus.nextc = gfc_current_locus.lb-line + maxlen; gfc_warning_now (Line truncated at %L, gfc_current_locus); - gfc_current_locus.nextc -= maxlen; + gfc_current_locus.nextc = current_nextc; }
[Bug middle-end/55477] New: [devirt] trunk fails inline-devirt tests #2 and and #3 whereas they pass in google/4_7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55477 Bug #: 55477 Summary: [devirt] trunk fails inline-devirt tests #2 and and #3 whereas they pass in google/4_7 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: m...@use.net Created attachment 28782 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28782 test case that fails in trunk but passes with google/gcc-4_7 When compiling Maxim's inline-devirt-2.C and inline-devirt-3.C test cases with both current trunk (r193828) and google/gcc-4_7, the Google branch correctly optimizes and trunk does not. Test cases are here: http://gcc.gnu.org/ml/gcc-patches/2011-10/msg02589.html My trunk configure line: $ ../gcc-trunk/configure --program-suffix=-4.8 --prefix=/u/mhargett --disable-bootstrap --enable-lto --with-fpmath=sse --disable-libmudflap --disable-libssp --enable-gold=yes --with-mpc=/u/mhargett --with-cloog=/u/mhargett/ --with-ppl=/u/mhargett/ --with-gmp=/u/mhargett/ --with-isl=/u/mhargett --with-mpfr=/u/mhargett/ --enable-cloog-backend=isl --enable-languages=c,c++,lto $ g++-4.8 -O2 inline-devirt-2.C trunk objdump for the second testcase: 0400630 main: 400630: 48 83 ec 28 subrsp,0x28 400634: 48 89 e7movrdi,rsp 400637: 48 c7 04 24 b0 09 40movQWORD PTR [rsp],0x4009b0 40063e: 00 40063f: 48 c7 44 24 10 f0 09movQWORD PTR [rsp+0x10],0x4009f0 400646: 40 00 400648: e8 23 01 00 00 call 400770 _ZL5printR10Calculable 40064d: 48 8d 7c 24 10 leardi,[rsp+0x10] 400652: e8 19 01 00 00 call 400770 _ZL5printR10Calculable 400657: 31 c0 xoreax,eax 400659: 48 83 c4 28 addrsp,0x28 40065d: c3 ret 40065e: 66 90 xchg ax,ax and for google/gcc-4_7: 00400630 main: 400630: 48 83 ec 08 subrsp,0x8 400634: be 01 00 00 00 movesi,0x1 400639: bf c8 08 40 00 movedi,0x4008c8 40063e: 31 c0 xoreax,eax 400640: e8 ab ff ff ff call 4005f0 printf@plt 400645: be 02 00 00 00 movesi,0x2 40064a: bf c4 08 40 00 movedi,0x4008c4 40064f: 31 c0 xoreax,eax 400651: e8 9a ff ff ff call 4005f0 printf@plt 400656: be 02 00 00 00 movesi,0x2 40065b: bf c8 08 40 00 movedi,0x4008c8 400660: 31 c0 xoreax,eax 400662: e8 89 ff ff ff call 4005f0 printf@plt 400667: be 03 00 00 00 movesi,0x3 40066c: bf c4 08 40 00 movedi,0x4008c4 400671: 31 c0 xoreax,eax 400673: e8 78 ff ff ff call 4005f0 printf@plt 400678: 31 c0 xoreax,eax 40067a: 48 83 c4 08 addrsp,0x8 40067e: c3 ret 40067f: 90 nop
[Bug fortran/55476] [4.8 Regression] Bogus warning Pointer might outlive the pointer target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55476 --- Comment #2 from janus at gcc dot gnu.org 2012-11-26 22:05:23 UTC --- The warning obviously gets triggered because the pointer has the 'host_assoc' attribute (due to its use in the contained subroutine): warn = lvalue-symtree-n.sym-attr.dummy || lvalue-symtree-n.sym-attr.result || lvalue-symtree-n.sym-attr.function || lvalue-symtree-n.sym-attr.host_assoc || lvalue-symtree-n.sym-attr.use_assoc || lvalue-symtree-n.sym-attr.in_common;
[Bug fortran/55476] Bogus warning Pointer might outlive the pointer target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55476 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-26 Summary|[4.8 Regression] Bogus |Bogus warning Pointer |warning Pointer might |might outlive the pointer |outlive the pointer target |target Ever Confirmed|0 |1 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2012-11-26 22:06:53 UTC --- Well, the warning is perfectly correct: The pointer *might* outlive the target - it doesn't say that it has to ;-) The problem is that: lvalue-symtree-n.sym-attr.host_assoc is true. Draft patch: --- a/gcc/fortran/expr.c +++ b/gcc/fortran/expr.c @@ -3695,3 +3695,5 @@ gfc_check_pointer_assign (gfc_expr *lvalue, gfc_expr *rvalue) || lvalue-symtree-n.sym-attr.function -|| lvalue-symtree-n.sym-attr.host_assoc +|| (lvalue-symtree-n.sym-attr.host_assoc + lvalue-symtree-n.sym-ns + != rvalue-symtree-n.sym-ns) || lvalue-symtree-n.sym-attr.use_assoc
[Bug middle-end/55478] New: [devirt] trunk fails inline-devirt test #4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55478 Bug #: 55478 Summary: [devirt] trunk fails inline-devirt test #4 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: m...@use.net Created attachment 28783 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28783 test case that fails in trunk but passed with Maxim's devirt patches trunk currently fails test #4 here (also attached): http://gcc.gnu.org/ml/gcc-patches/2011-10/msg02589.html $ g++-4.8 -O2 inline-devirt-4.C objdump -d -Mintel a.out | less -p main\ 00400630 main: 400630: 48 83 ec 18 subrsp,0x18 400634: 48 89 e7movrdi,rsp 400637: 48 c7 04 24 d0 09 40movQWORD PTR [rsp],0x4009d0 40063e: 00 40063f: c6 44 24 0a 00 movBYTE PTR [rsp+0xa],0x0 400644: c6 44 24 08 61 movBYTE PTR [rsp+0x8],0x61 400649: c6 44 24 09 62 movBYTE PTR [rsp+0x9],0x62 40064e: e8 2d 01 00 00 call 400780 _Z12print_lengthRK6String 400653: 31 c0 xoreax,eax 400655: 48 83 c4 18 addrsp,0x18 400659: c3 ret 40065a: 66 0f 1f 44 00 00 nopWORD PTR [rax+rax*1+0x0] It does inline the FixedString ctor, but not print_length(const String), nor does it even inline FixedString::length() into print_length(const String). I tried -O3 and -Ofast along with various inline --params, but to no avail.
[Bug middle-end/55477] [devirt] trunk fails inline-devirt tests #2 and and #3 whereas they pass in google/4_7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55477 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org, ||mjambor at suse dot cz --- Comment #1 from Jan Hubicka hubicka at gcc dot gnu.org 2012-11-26 22:39:17 UTC --- Martin, can you take a look? Matt, did you identify the patch on google branch enabling the devirtualization here?
[Bug c/7652] -Wswitch-break : Warn if a switch case falls through
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652 Arthur O'Dwyer arthur.j.odwyer at gmail dot com changed: What|Removed |Added CC||arthur.j.odwyer at gmail ||dot com --- Comment #15 from Arthur O'Dwyer arthur.j.odwyer at gmail dot com 2012-11-26 22:49:02 UTC --- TL;DR — I would like to see GCC and Clang both implement __builtin_fallthrough(). I believe Lint recognizes the magic comment /*FALLTHROUGH*/ case 1: foo(); /*FALLTHROUGH*/ case 2: as a hint to suppress the warning. I think EDG's front-end has similar logic; certainly Green Hills' compiler recognizes /*FALLTHROUGH*/. (My memory is fuzzy because I no longer work there, but I know that Green Hills recognized a couple kinds of magic comment before I got there, which would have been six years ago.) I admit that the magic comment approach has problems: for example, you can't #define a macro to expand to a comment. Also it complicates the parser. Clang currently suppresses the warning only if the C++11 attribute [[clang::fallthrough]] is applied to a null statement immediately preceding case 2:, but this doesn't work outside of C++11 mode, and it's ridiculously inappropriate as an industrywide solution (as it contains the word clang in the name of the attribute). case 1: foo(); [[clang::fallthrough]]; case 2: Alternatively, someone in this clang-dev thread has proposed adding a __builtin_fallthrough() intrinsic that would suppress the warning, which is not a bad idea at all. http://clang-developers.42468.n3.nabble.com/should-Wimplicit-fallthrough-require-C-11-td4028144.html Notice that __builtin_fallthrough() could be #defined away on compilers that don't support it, and unlike a magic comment, you can #define something to expand *to* it as well. case 1: foo(); __builtin_fallthrough(); case 2: I'd like to see __builtin_fallthrough() added to all major compilers. :)
[Bug fortran/54572] Use libbacktrace library
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54572 --- Comment #7 from Ian Lance Taylor ian at airs dot com 2012-11-26 23:02:46 UTC --- Why are there no line numbers in the backtrace from gdb? You said you compiled with -g. Are you sure that libbacktrace itself was compiled with -g?
[Bug c/7652] -Wswitch-break : Warn if a switch case falls through
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652 --- Comment #16 from Arthur O'Dwyer arthur.j.odwyer at gmail dot com 2012-11-26 23:02:52 UTC --- (Sorry for the spam.) The corresponding Clang enhancement is http://llvm.org/bugs/show_bug.cgi?id=14440
[Bug middle-end/55478] [devirt] trunk fails inline-devirt test #4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55478 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-26 CC||mjambor at suse dot cz Ever Confirmed|0 |1 --- Comment #1 from Jan Hubicka hubicka at gcc dot gnu.org 2012-11-26 23:03:25 UTC --- Hmm, for some reason inliner do not see the devirt_benefit path at all in this testcase
[Bug fortran/54572] Use libbacktrace library
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54572 --- Comment #8 from Ian Lance Taylor ian at airs dot com 2012-11-26 23:08:45 UTC --- The crash within libbacktrace is occurring as it tries to read the debug info. This is presumably a bug in libbacktrace, but I don't know what the problem is without more information. libbacktrace is pretty careful to only read memory that was explicitly read. There is presumably a bug there, but I don't know what it is. I doubt the fact that a signal occurred has anything to do with this. There seems to be something odd about the debug info, as shown both by the fact that libbacktrace crashes trying to read it and that gdb does not display file/line information.
[Bug c++/53094] vector literal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53094 Marc Glisse glisse at gcc dot gnu.org changed: What|Removed |Added CC||glisse at gcc dot gnu.org --- Comment #1 from Marc Glisse glisse at gcc dot gnu.org 2012-11-26 23:17:49 UTC --- Vectors have become literals some time ago, but most constexpr code using them fails. Turning vector CONSTRUCTOR into VECTOR_CST in fold (next to ARRAY_REF handling) looks like a good first step.
[Bug c++/55015] [4.7/4.8 Regression] Lambda functions not found at link time when declared in an inline function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55015 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Summary|Lambda functions not found |[4.7/4.8 Regression] Lambda |at link time when declared |functions not found at link |in an inline function |time when declared in an ||inline function --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-26 23:37:48 UTC --- This is a regression.
