[Bug target/53325] arm-rtems switch default target to EABI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53325 --- Comment #5 from Sebastian Huber sebastian.hu...@embedded-brains.de 2012-11-28 08:09:47 UTC --- It is fixed on GCC 4.8. GCC 4.6 and 4.7 are still open. http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00939.html
[Bug sanitizer/55502] gcc.c-torture/execute/builtins/memcpy-chk.c execution failures with -fsanitize=address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55502 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE Target Milestone|--- |4.8.0 --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-28 08:11:16 UTC --- No need to attach hundreds of outputs. All this is because asan doesn't support __builtin_longjmp right now, which these tests use (see testsuite/gcc.c-torture/execute/builtins/lib/chk.c). *** This bug has been marked as a duplicate of bug 55485 ***
[Bug sanitizer/55485] probable false positive on __builtin_setjmp/__builtin_longjmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55485 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||howarth at nitro dot ||med.uc.edu --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-28 08:11:16 UTC --- *** Bug 55502 has been marked as a duplicate of this bug. ***
[Bug target/54721] Generate arm/thumb interwork veneers at compile time?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54721 --- Comment #4 from George Spelvin linux at horizon dot com 2012-11-28 08:37:50 UTC --- I wouldn't expect this to be something of high priority currently. I know the benefit is low; I had just hoped that it would be a fairly small and simple change and thus the cost/benefit ratio would be reasonable. The comments so far seem to implicitly agree that it would be a useful feature, if only a magical fairy would appear and implement it. If anyone would be willing to say so explicitly, and suggest a name (__attribute__((interwork)) comes to mind, but the floor is open for suggestions), it would perhaps embolden some future ARM hacker looking for a small project.
[Bug sanitizer/55508] many test cases fail using -fsanitize=address with internal compiler error: in expand_call_tm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55508 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||aldyh at gcc dot gnu.org, ||torvald at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-28 08:44:46 UTC --- This is because the calls (with my pending patch builtins, but that hasn't been reviewed yet) are added in between lower_tm? pass and the final tm transformation pass, and there is /* We can have a nodeless call here if some pass after IPA-tm added uninstrumented calls. For example, loop distribution can transform certain loop constructs into __builtin_mem* calls. In this case, see if we have a suitable TM replacement and fill in the gaps. */ gcc_assert (DECL_BUILT_IN_CLASS (fn_decl) == BUILT_IN_NORMAL); enum built_in_function code = DECL_FUNCTION_CODE (fn_decl); gcc_assert (code == BUILT_IN_MEMCPY || code == BUILT_IN_MEMMOVE || code == BUILT_IN_MEMSET); The question is what to do with the asan/tsan library calls in transactions. The asan report calls are just verification functions, which for normal programs shouldn't have any visible effect, so perhaps we could lie about them and say that they are transaction_safe (or transaction_callable?, dunno which) and create cgraph nodes for them and clear node-local.tm_may_enter_irr, basically pretend they aren't there. For tsan the question is whether even that is useful at all when tsan doesn't wrap begin/end/abort transaction library calls and doesn't take transactions into account at all.
[Bug testsuite/55429] new UNRESOLVED: 20_util/enable_shared_from_this/cons/constexpr.cc scan-assembler on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55429
Dominique d'Humieres dominiq at lps dot ens.fr changed:
What|Removed |Added
CC||jwakely.gcc at gmail dot
||com, paolo.carlini at
||oracle dot com
--- Comment #8 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-11-28
08:50:55 UTC ---
The following patch (borrowed from gcc/testsuite/lib/gcc-dg.exp) fixes the on
x86_64-apple-darwin10:
--- ../_clean/libstdc++-v3/testsuite/lib/libstdc++.exp2012-11-24
01:46:03.0 +0100
+++ libstdc++-v3/testsuite/lib/libstdc++.exp2012-11-27 22:35:33.0
+0100
@@ -389,14 +389,21 @@ if { [info procs saved-dg-test] == [list
proc dg-test { args } {
global additional_prunes
global errorInfo
+global testname_with_flags
if { [ catch { eval saved-dg-test $args } errmsg ] } {
set saved_info $errorInfo
set additional_prunes
+if [info exists testname_with_flags] {
+unset testname_with_flags
+}
unset_timeout_vars
error $errmsg $saved_info
}
set additional_prunes
+if [info exists testname_with_flags] {
+unset testname_with_flags
+}
unset_timeout_vars
}
}
Notes:
(1) I don't understand why this triggered on darwin only;
(2) the option -save-temps is not necessary in
libstdc++-v3/testsuite/20_util/enable_shared_from_this/cons/constexpr.cc
libstdc++-v3/testsuite/20_util/shared_ptr/cons/constexpr.cc
libstdc++-v3/testsuite/20_util/unique_ptr/cons/constexpr.cc
libstdc++-v3/testsuite/20_util/weak_ptr/cons/constexpr.cc
libstdc++-v3/testsuite/30_threads/future/cons/constexpr.cc
libstdc++-v3/testsuite/30_threads/shared_future/cons/constexpr.cc
see http://gcc.gnu.org/ml/libstdc++/2012-11/msg00148.html .
[Bug other/55358] Valgrind errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55358 --- Comment #6 from Markus Trippelsdorf markus at trippelsdorf dot de 2012-11-28 08:51:26 UTC --- Created attachment 28818 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28818 stl benchmark The last issue can be reproduced with an old C++ STL benchmark from Stepanov and Stroustrup (attached): markus@x4 ~ % /var/tmp/gcc_valgrind/usr/local/bin/g++ -O2 -fprofile-generate bench.cpp markus@x4 ~ % ./a.out sizearray vector with pointersvector with iterators deque listset multiset 10 0.180.180.190.44 1.080.671.08 ... markus@x4 ~ % /var/tmp/gcc_valgrind/usr/local/bin/g++ -O2 -fprofile-use -flto bench.cpp ==22679== Invalid write of size 8 ==22679==at 0x68007D: iterative_hash_canonical_type(tree_node*, unsigned int) (gimple.c:3170) ==22679==by 0xD611C0: htab_find_slot (hashtab.c:712) ==22679==by 0x68A918: gimple_register_canonical_type(tree_node*) (gimple.c:3438) ==22679==by 0x4D093B: lto_file_read(lto_file_struct*, _IO_FILE*, int*) (lto.c:2050) ==22679==by 0x4D25EA: lto_main() (lto.c:2966) ==22679==by 0x82A5B5: compile_file() (toplev.c:545) ==22679==by 0x82C4D9: toplev_main(int, char**) (toplev.c:1884) ==22679==by 0x4ECD884: (below main) (libc-start.c:258) ==22679== Address 0x4031e98 is not stack'd, malloc'd or (recently) free'd ==22679==
[Bug fortran/55501] [F03] ICE using MERGE in constant expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55501 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-28 CC||janus at gcc dot gnu.org Summary|ICE using MERGE in constant |[F03] ICE using MERGE in |expr|constant expr Ever Confirmed|0 |1 --- Comment #2 from janus at gcc dot gnu.org 2012-11-28 09:16:13 UTC --- I can confirm this error. It occurs with all gfortran versions I tried (starting from 4.3 up to the current trunk). Slightly compactified test case: module test type MPI_Datatype integer :: mpi_val end type type(MPI_Datatype) :: MPI_INTEGER = merge(MPI_Datatype(4), MPI_Datatype(8), .false.) end module Apparently the declaration needs to be in a module for the error to occur, and also derived types need to be involved. Using -std=f95, the test case is correctly rejected (without ICE): type(MPI_Datatype) :: MPI_INTEGER = merge(MPI_Datatype(4), MPI_Datatype(8), . 1 Error: Fortran 2003: Elemental function as initialization expression with non-integer/non-character arguments at (1)
[Bug rtl-optimization/55512] New: [4.8 Regression] Various LRA ICEs with inline-asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55512
Bug #: 55512
Summary: [4.8 Regression] Various LRA ICEs with inline-asm
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Keywords: error-recovery
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
CC: vmaka...@gcc.gnu.org
#ifndef TEST
#define TEST 0
#endif
#if (TEST 1)
#define __builtin_unreachable() do { } while (0)
#endif
#if (TEST 2) == 0
int
foo (int x)
{
asm goto ( : : r (x), r (x + 1), r (x + 2), r (x + 3),
r (x + 4), r (x + 5), r (x + 6), r (x + 7),
r (x + 8), r (x + 9), r (x + 10), r (x + 11),
r (x + 12), r (x + 13), r (x + 14), r (x + 15) : : lab);
__builtin_unreachable ();
lab:
return 0;
}
#endif
#if (TEST 2)
int
bar (int x)
{
asm goto ( : : r (x), r (x + 1), r (x + 2), r (x + 3),
r (x + 4), r (x + 5), r (x + 6), r (x + 7),
r (x + 8), r (x + 9), r (x + 10), r (x + 11),
r (x + 12), r (x + 13), r (x + 14), r (x + 15),
r (x + 16) : : lab);
__builtin_unreachable ();
lab:
return 0;
}
#endif
shows 3 different ICEs on x86_64-linux with -O3. In 4.7 I get:
for i in `seq 0 3`; do echo ===$i===; LC_ALL=C gcc -S -O2 -DTEST=$i
pr51106-3.c; done
===0===
pr51106-3.c: In function 'foo':
pr51106-3.c:13:3: error: can't find a register in class 'GENERAL_REGS' while
reloading 'asm'
pr51106-3.c:13:3: error: 'asm' operand has impossible constraints
===1===
pr51106-3.c: In function 'foo':
pr51106-3.c:13:3: error: can't find a register in class 'GENERAL_REGS' while
reloading 'asm'
pr51106-3.c:13:3: error: 'asm' operand has impossible constraints
===2===
pr51106-3.c: In function 'bar':
pr51106-3.c:27:3: error: can't find a register in class 'GENERAL_REGS' while
reloading 'asm'
pr51106-3.c:27:3: error: 'asm' operand has impossible constraints
===3===
pr51106-3.c: In function 'bar':
pr51106-3.c:27:3: error: can't find a register in class 'GENERAL_REGS' while
reloading 'asm'
pr51106-3.c:27:3: error: 'asm' operand has impossible constraints
but with the trunk:
for i in `seq 0 3`; do echo ===$i===; LC_ALL=C ./xgcc -B ./ -S -O2 -DTEST=$i
pr51106-3.c; done
===0===
pr51106-3.c: In function 'foo':
pr51106-3.c:20:1: internal compiler error: Maximum number of LRA constraint
passes is achieved (15)
}
^
0x8fd167 lra_constraints(bool)
../../gcc/lra-constraints.c:3315
0x8eda2e lra(_IO_FILE*)
../../gcc/lra.c:2277
0x8a33e4 do_reload
../../gcc/ira.c:4624
0x8a35f2 rest_of_handle_reload
../../gcc/ira.c:4737
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
===1===
pr51106-3.c: In function 'foo':
pr51106-3.c:20:1: internal compiler error: Maximum number of LRA constraint
passes is achieved (15)
}
^
0x8fd167 lra_constraints(bool)
../../gcc/lra-constraints.c:3315
0x8eda2e lra(_IO_FILE*)
../../gcc/lra.c:2277
0x8a33e4 do_reload
../../gcc/ira.c:4624
0x8a35f2 rest_of_handle_reload
../../gcc/ira.c:4737
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
===2===
pr51106-3.c: In function 'bar':
pr51106-3.c:27:3: error: 'asm' operand has impossible constraints
asm goto ( : : r (x), r (x + 1), r (x + 2), r (x + 3),
^
pr51106-3.c:35:1: error: unrecognizable insn:
}
^
(jump_insn 22 74 37 2 (use (const_int 0 [0])) pr51106-3.c:27 -1
(nil)
- 25)
pr51106-3.c:35:1: internal compiler error: in insn_default_length, at
config/i386/i386.md:1037
0x9d5ed3 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/rtl-error.c:110
0x9d5f14 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc/rtl-error.c:118
0xd4887f insn_default_length(rtx_def*)
../../gcc/config/i386/i386.md:1037
0x767c92 get_attr_length_1
../../gcc/final.c:405
0x767dae get_attr_length(rtx_def*)
../../gcc/final.c:437
0xd363d8 min_insn_size
../../gcc/config/i386/i386.c:35044
0xd3661c ix86_avoid_jump_mispredicts
../../gcc/config/i386/i386.c:35140
0xd36eba ix86_reorg
../../gcc/config/i386/i386.c:35367
0x9d5bc5 rest_of_handle_machine_reorg
../../gcc/reorg.c:3944
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
===3===
pr51106-3.c: In function 'bar':
pr51106-3.c:27:3: error: 'asm' operand has impossible constraints
asm goto ( : : r (x), r (x + 1), r (x + 2), r (x + 3),
^
pr51106-3.c:35:1: internal compiler error: in fixup_reorder_chain, at
cfgrtl.c:3334
[Bug rtl-optimization/55512] [4.8 Regression] Various LRA ICEs with inline-asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55512 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug c/35634] [4.6/4.7/4.8 Regression] operand of pre-/postin-/decrement not promoted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35634 --- Comment #37 from Richard Biener rguenth at gcc dot gnu.org 2012-11-28 09:27:14 UTC --- Author: rguenth Date: Wed Nov 28 09:27:10 2012 New Revision: 193882 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193882 Log: 2012-11-28 Richard Biener rguent...@suse.de PR c/35634 * gimple.h (gimplify_self_mod_expr): Declare. * gimplify.c (gimplify_self_mod_expr): Export. Take a different type for performing the arithmetic in. (gimplify_expr): Adjust. * tree-vect-loop-manip.c (vect_can_advance_ivs_p): Strip sign conversions we can re-apply after adjusting the IV. c-family/ * c-gimplify.c (c_gimplify_expr): Gimplify self-modify expressions here and use a type with proper overflow behavior for types that would need to be promoted for the arithmetic. * gcc.dg/torture/pr35634.c: New testcase. * g++.dg/torture/pr35634.C: Likewise. * gcc.dg/vect/pr18536.c: Mark worker function noinline. Added: trunk/gcc/testsuite/g++.dg/torture/pr35634.C trunk/gcc/testsuite/gcc.dg/torture/pr35634.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-gimplify.c trunk/gcc/gimple.h trunk/gcc/gimplify.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/pr18536.c trunk/gcc/tree-vect-loop-manip.c
[Bug c/35634] [4.6/4.7 Regression] operand of pre-/postin-/decrement not promoted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35634 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||4.8.0 Summary|[4.6/4.7/4.8 Regression]|[4.6/4.7 Regression] |operand of |operand of |pre-/postin-/decrement not |pre-/postin-/decrement not |promoted|promoted Known to fail||4.6.3, 4.7.2 --- Comment #38 from Richard Biener rguenth at gcc dot gnu.org 2012-11-28 09:28:17 UTC --- Fixed for 4.8.0. Unlikely going to be backported.
[Bug rtl-optimization/55489] [4.7/4.8 regression] insane PRE memory usage with PIE (translate.i)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55489 Paolo Bonzini bonzini at gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Paolo Bonzini bonzini at gnu dot org 2012-11-28 09:29:50 UTC --- fixed in 4.7 and 4.8 - present in other branches, but nowhere as bad as in 4.7 and newer.
[Bug middle-end/52996] [4.8 Regression] ice in verify_loop_structure, at cfgloop.c:1567
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52996 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org AssignedTo|rguenth at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org 2012-11-28 09:30:09 UTC --- Reassigning.
[Bug regression/55327] [4.8 regression] FAIL: gcc.dg/vect/slp-perm-8.c scan-tree-dump-times vect vectorized 1 loops 2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55327 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org 2012-11-28 09:32:35 UTC --- Author: rguenth Date: Wed Nov 28 09:32:30 2012 New Revision: 193883 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193883 Log: 2012-11-28 Richard Biener rguent...@suse.de PR testsuite/55327 * gcc.dg/vect/slp-perm-8.c: Mark worker as noinline. * gcc.dg/vect/slp-perm-9.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/slp-perm-8.c trunk/gcc/testsuite/gcc.dg/vect/slp-perm-9.c
[Bug testsuite/55327] [4.8 regression] FAIL: gcc.dg/vect/slp-perm-8.c scan-tree-dump-times vect vectorized 1 loops 2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55327 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Component|regression |testsuite Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org 2012-11-28 09:33:12 UTC --- Fixed (hopefully).
[Bug rtl-optimization/55512] [4.8 Regression] Various LRA ICEs with inline-asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55512 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-11-28 09:33:32 UTC --- I thought this was fixed with: http://gcc.gnu.org/ml/gcc-patches/2012-11/msg02271.html
[Bug rtl-optimization/55512] [4.8 Regression] Various LRA ICEs with inline-asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55512 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-28 Ever Confirmed|0 |1 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2012-11-28 09:35:02 UTC --- (In reply to comment #1) I thought this was fixed with: http://gcc.gnu.org/ml/gcc-patches/2012-11/msg02271.html Or rather only partly. The unrecognizable insn part was introduced by that change.
[Bug fortran/55501] [F03] ICE using MERGE in constant expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55501 --- Comment #3 from janus at gcc dot gnu.org 2012-11-28 09:40:33 UTC --- The backtrace one gets on trunk is: 0x669272 gfc_conv_structure(gfc_se*, gfc_expr*, int) /home/jweil/gcc48/trunk/gcc/fortran/trans-expr.c:5971 0x667dbb gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool, bool) /home/jweil/gcc48/trunk/gcc/fortran/trans-expr.c:5550 0x648799 gfc_get_symbol_decl(gfc_symbol*) /home/jweil/gcc48/trunk/gcc/fortran/trans-decl.c:1480 That line (trans-expr.c:5971) is the following assert: gcc_assert (expr-expr_type == EXPR_STRUCTURE); which fails because we have an EXPR_FUNCTION.
[Bug tree-optimization/54547] [4.8 regression] FAIL: gcc.dg/tree-ssa/pr37508.c scan-tree-dump-times vrp1 Folding 3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54547
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org
|gnu.org |
Target Milestone|--- |4.8.0
--- Comment #1 from Richard Biener rguenth at gcc dot gnu.org 2012-11-28
09:52:42 UTC ---
I seem to remember the test is quite fragile even on x86 (though it passes
there at the moment). It depends on whether fold converted some of the
memory accesses to BIT_FIELD_REFs or not.
For x86 we see:
test1 (struct foo1 * x)
{
int _1;
unsigned char _4;
unsigned char _5;
unsigned char _6;
bb 2:
_4 = BIT_FIELD_REF *x_3(D), 8, 0;
_5 = _4 1;
if (_5 == 0)
goto bb 5;
else
goto bb 3;
bb 3:
_6 = ASSERT_EXPR _5, _5 != 0;
but for arm:
test1 (struct foo1 * x)
{
int _1;
unnamed-signed:1 _4;
unnamed-signed:1 _5;
bb 2:
_4 = x_3(D)-i;
if (_4 != 0)
goto bb 3;
else
goto bb 5;
bb 3:
_5 = ASSERT_EXPR _4, _4 != 0;
if (_5 == -1)
and for x86 we get then
Found new range for _6: [1, 1]
while arm has
Found new range for _5: ~[0, +INF]
(it prefers ~[0,0] over [-1,-1], but doesn't know to simplify
~[0,0] == -1 for 1-bit ranges). I'll try to fix that.
[Bug c++/55513] New: Incorrect snprintf folding when building with -std=c++0x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55513
Bug #: 55513
Summary: Incorrect snprintf folding when building with
-std=c++0x
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gno...@hotmail.com
Using the following program:
#include cstdio
#include iostream
int main() {
char str[10];
const int strLength = snprintf(str, sizeof(str), Hello);
std::cout strLength ':' str std::endl;
return 0;
}
When built with the following command:
g++ test_snprintf.cc -O0 -g3 -std=c++0x
The output of running it is:
5:
instead of:
5: Hello
The program will work fine if either of the following changes are made
1. -std=c++0x is removed from the build command line.
2. The const is removed from the definition of the variable strLength
Here's a disassembly of main() up until the call to ostream::operator, when
built with -std=c++0x:
0x00400a6c +0: push %rbp
0x00400a6d +1: mov%rsp,%rbp
0x00400a70 +4: sub$0x30,%rsp
0x00400a74 +8: mov%fs:0x28,%rax
0x00400a7d +17:mov%rax,-0x8(%rbp)
0x00400a81 +21:xor%eax,%eax
0x00400a83 +23:movl $0x5,-0x24(%rbp)
0x00400a8a +30:mov$0x5,%esi
0x00400a8f +35:mov$0x6010a0,%edi
0x00400a94 +40:callq 0x4008a0 _ZNSolsEi@plt
0x00400a99 +45:mov$0x3a,%esi
0x00400a9e +50:mov%rax,%rdi
0x00400aa1 +53:callq 0x4008e0
_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_c@plt
Here's a disassembly of main() up until the call to ostream::operator, when
built without -std=c++0x _or_ when the const is removed (same result):
0x00400a6c +0: push %rbp
0x00400a6d +1: mov%rsp,%rbp
0x00400a70 +4: sub$0x30,%rsp
0x00400a74 +8: mov%fs:0x28,%rax
0x00400a7d +17:mov%rax,-0x8(%rbp)
0x00400a81 +21:xor%eax,%eax
0x00400a83 +23:lea-0x20(%rbp),%rax
0x00400a87 +27:movl $0x6c6c6548,(%rax)
0x00400a8d +33:movw $0x6f,0x4(%rax)
0x00400a93 +39:movl $0x5,-0x24(%rbp)
0x00400a9a +46:mov-0x24(%rbp),%eax
0x00400a9d +49:mov%eax,%esi
0x00400a9f +51:mov$0x6010a0,%edi
0x00400aa4 +56:callq 0x4008a0 _ZNSolsEi@plt
0x00400aa9 +61:mov$0x3a,%esi
0x00400aae +66:mov%rax,%rdi
0x00400ab1 +69:callq 0x4008e0
_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_c@plt
OS Version: Ubuntu 12.10
uname -a output:
Linux desktop 3.5.0-18-generic #29-Ubuntu SMP Fri Oct 19 10:26:51 UTC 2012
x86_64 x86_64 x86_64 GNU/Linux
gcc --version output:
gcc (Ubuntu/Linaro 4.7.2-2ubuntu1) 4.7.2
[Bug c++/55513] Incorrect snprintf folding when building with -std=c++0x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55513 --- Comment #1 from Amit Schreiber gnobal at hotmail dot com 2012-11-28 10:05:16 UTC --- Created attachment 28819 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28819 The program
[Bug fortran/55501] [F03] ICE using MERGE in constant expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55501 --- Comment #4 from janus at gcc dot gnu.org 2012-11-28 10:10:40 UTC --- For a case like this: module test integer :: MPI_INTEGER = merge(4, 8, .false.) end module we do not get an EXPR_FUNCTION in gfc_conv_initializer, but it is simplified to EXPR_CONSTANT before. It seems that this does not work for derived types.
[Bug middle-end/55266] vector expansion: 36 movs for 4 adds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55266 --- Comment #2 from Marc Glisse glisse at gcc dot gnu.org 2012-11-28 10:11:31 UTC --- Author: glisse Date: Wed Nov 28 10:11:27 2012 New Revision: 193884 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193884 Log: 2012-11-28 Marc Glisse marc.gli...@inria.fr PR middle-end/55266 * fold-const.c (fold_ternary_loc) [BIT_FIELD_REF]: Handle CONSTRUCTOR with vector elements. * tree-ssa-propagate.c (valid_gimple_rhs_p): Handle CONSTRUCTOR and BIT_FIELD_REF. Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/tree-ssa-propagate.c
[Bug c++/55513] [4.7 Regression] Incorrect snprintf folding when building with -std=c++0x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55513 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-28 Known to work||4.6.3, 4.8.0 Summary|Incorrect snprintf folding |[4.7 Regression] Incorrect |when building with |snprintf folding when |-std=c++0x |building with -std=c++0x Ever Confirmed|0 |1 Known to fail||4.7.1, 4.7.2 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-11-28 10:18:57 UTC --- Confirmed. -fno-builtin fixes it too.
[Bug target/55491] Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55491 --- Comment #7 from tom.day at amlin dot co.uk 2012-11-28 10:29:51 UTC --- Sorry Mikael, I'm with you now. I also don't get this error message when targeting i686-w64-mingw32 when hosted on i686-linux-gnu.
[Bug bootstrap/55511] r193802 caused s390x bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55511 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-11-28 Ever Confirmed|0 |1 --- Comment #1 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-11-28 10:30:42 UTC --- Thanks. Is this with the first build of libgcc? I.e. is it likely that I'll see this with just a cross-build? Also, can you please check whether the patch in http://gcc.gnu.org/ml/gcc-patches/2012-11/msg02188.html solves the problem, as it does for alpha-linux?
[Bug fortran/55501] [F03] ICE using MERGE in constant expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55501
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org
|gnu.org |
--- Comment #5 from janus at gcc dot gnu.org 2012-11-28 10:35:54 UTC ---
The following patch fixes it:
Index: gcc/fortran/simplify.c
===
--- gcc/fortran/simplify.c(revision 193810)
+++ gcc/fortran/simplify.c(working copy)
@@ -3973,8 +3973,10 @@ gfc_simplify_maskl (gfc_expr *i, gfc_expr *kind_ar
gfc_expr *
gfc_simplify_merge (gfc_expr *tsource, gfc_expr *fsource, gfc_expr *mask)
{
- if (tsource-expr_type != EXPR_CONSTANT
- || fsource-expr_type != EXPR_CONSTANT
+ if ((tsource-expr_type != EXPR_CONSTANT
+tsource-expr_type != EXPR_STRUCTURE)
+ || (fsource-expr_type != EXPR_CONSTANT
+ fsource-expr_type != EXPR_STRUCTURE)
|| mask-expr_type != EXPR_CONSTANT)
return NULL;
[Bug target/55514] New: PowerPC EABI: Warning: setting incorrect section attributes for .sdata2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55514
Bug #: 55514
Summary: PowerPC EABI: Warning: setting incorrect section
attributes for .sdata2
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rdiezmail-...@yahoo.de
I am compiling with -meabi -msdata=eabi, and I am getting this compilation
warning every now and then:
Warning: setting incorrect section attributes for .sdata2
This line of code triggers it:
const uint8_t utf8TestStringKanji[] = { 0xE6, 0xBC, 0xA2, 0xE5, 0xAD, 0x97,
0x00 };
This is the assembler output for those 7 bytes of data:
11768 .section.sdata2,aw,@progbits
11769 .align 2
11770 .LC1:
11771 E6 .byte-26
11772 0001 BC .byte-68
11773 0002 A2 .byte-94
11774 0003 E5 .byte-27
11775 0004 AD .byte-83
11776 0005 97 .byte-105
11777 0006 00 .byte0
The 'w' in the aw means writable, which is wrong in this case.
I replaced that line of code with the following, which is more or less the same
for my purposes:
const char * const utf8TestStringKanji = \xE6\xBC\xA2\xE5\xAD\x97\x00;
And that compiles fine (no warnings).
[Bug fortran/55501] [F03] ICE using MERGE in constant expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55501 --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org 2012-11-28 10:48:58 UTC --- (In reply to comment #2) type(MPI_Datatype) :: MPI_INTEGER = merge(MPI_Datatype(4), MPI_Datatype(8), .false.) The problem is related to having array PARAMETERs. For normal parameters, simply their value is stored in the .mod file and always inserted when used. For array parameters, a static array in read-only memory is created, which can then be accessed at run time. That avoids replicating the information several times. In addition, the expression is also stored in the .mod file. Especially if constructors are involved, the current compile-time simplification doesn't work that well. Additionally, the question is also whether it always makes sense to expand constructors if one wants to simplify code. In any case, there is room for improvement. See also PR 44856 and PR 51260. * * * In gfc_simplify_merge, the compiler gives up when the type is not an EXPR_CONSTANT: 3976 if (tsource-expr_type != EXPR_CONSTANT 3977 || fsource-expr_type != EXPR_CONSTANT 3978 || mask-expr_type != EXPR_CONSTANT) 3979return NULL; For the test case of this PR, one has an EXPR_STRUCTURE. Maybe replacing the check by calls to gfc_is_constant_expr() is sufficient.
[Bug c++/55497] Local array (char[]) initialized with a size taken from a static variable creates an ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55497 --- Comment #6 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2012-11-28 10:49:44 UTC --- Author: paolo Date: Wed Nov 28 10:49:39 2012 New Revision: 193885 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193885 Log: 2012-11-28 Paolo Carlini paolo.carl...@oracle.com PR c++/55497 * g++.dg/init/pr55497.C: New. Added: trunk/gcc/testsuite/g++.dg/init/pr55497.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug fortran/55501] [F03] ICE using MERGE in constant expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55501
--- Comment #7 from janus at gcc dot gnu.org 2012-11-28 10:50:28 UTC ---
I think the following variant makes even more sense:
Index: gcc/fortran/simplify.c
===
--- gcc/fortran/simplify.c(revision 193810)
+++ gcc/fortran/simplify.c(working copy)
@@ -3973,9 +3973,7 @@ gfc_simplify_maskl (gfc_expr *i, gfc_expr *kind_ar
gfc_expr *
gfc_simplify_merge (gfc_expr *tsource, gfc_expr *fsource, gfc_expr *mask)
{
- if (tsource-expr_type != EXPR_CONSTANT
- || fsource-expr_type != EXPR_CONSTANT
- || mask-expr_type != EXPR_CONSTANT)
+ if (mask-expr_type != EXPR_CONSTANT)
return NULL;
return gfc_copy_expr (mask-value.logical ? tsource : fsource);
In order to simplify a MERGE expression, we don't need to rely on the TSOURCE
and FSOURCE arguments being constant. It's sufficient that the MASK is.
[Bug c++/55497] Local array (char[]) initialized with a size taken from a static variable creates an ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55497 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.7.3, 4.8.0 Resolution||FIXED Target Milestone|--- |4.7.3 Severity|major |normal --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-28 10:51:02 UTC --- Done.
[Bug fortran/55501] [F03] ICE using MERGE in constant expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55501 --- Comment #8 from Tobias Burnus burnus at gcc dot gnu.org 2012-11-28 10:54:56 UTC --- (In reply to comment #5) +tsource-expr_type != EXPR_STRUCTURE) That's not okay: If you have integer, allocatable :: a(:), b(:) one has an EXPR_STRUCTURE for [a,b] but not a constant expression. One has to do a deep check. Well, gfc_is_constant_expr() is supposed to do this. (Or should gfc_check_init_expr be used? I always confuse the two. For F90/F95 it makes a difference, for F200x it doesn't, and gfortran's usage is a mess.)
[Bug fortran/55501] [F03] ICE using MERGE in constant expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55501 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #9 from Tobias Burnus burnus at gcc dot gnu.org 2012-11-28 11:03:34 UTC --- (In reply to comment #7) - if (tsource-expr_type != EXPR_CONSTANT - || fsource-expr_type != EXPR_CONSTANT - || mask-expr_type != EXPR_CONSTANT) + if (mask-expr_type != EXPR_CONSTANT) return NULL; That makes sense: If mask is a constant scalar, tsource or fsource can be used. That patch is pre-approved. However, at some point one has also to simplify: MERGE([1,2],[11,22], [.true.,.false.]) and for that case, all arguments have to be gfc_is_constant_expr(). At least Fortran 2008 requires that the processor can do such a simplification. (One could also handle the special case that mask is an array of only .true. or only .false.)
[Bug target/55515] New: PowerPC EABI: Create a predefined symbol for -mdata=xxx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55515 Bug #: 55515 Summary: PowerPC EABI: Create a predefined symbol for -mdata=xxx Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: rdiezmail-...@yahoo.de I am investigating this issue: http://sourceware.org/ml/newlib/2011/msg00295.html If that link does not work, search the mailing list for PowerPC EABI issues with newlib. During the investigation, I have missed a way to tell which -mdata=xxx option is being used at the moment. That is, I need a predefined symbol like _PPC_MSDATA=EABI, _PPC_MSDATA_EABI or similar. With such a symbol, it would be easy to #error if the user has specified the wrong compiler flags. Info about where to look in GCC's source code is here: http://gcc.gnu.org/ml/gcc-help/2011-07/msg00079.html If that link does not work, search the mailing list for How to check at compilation time whether -msdata is set to eabi for PowerPC embedded targets.
[Bug regression/55516] New: strict volatile bitfields are broken on ARM.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55516 Bug #: 55516 Summary: strict volatile bitfields are broken on ARM. Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: regression AssignedTo: unassig...@gcc.gnu.org ReportedBy: ram...@gcc.gnu.org Broken with commits between rev 193600 and 193606. Suggestion from Richi is to rewrite strict volatile bitfields to use DECL_BIT_FIELD_REPRESENTATIVE .
[Bug fortran/55501] [F03] ICE using MERGE in constant expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55501 --- Comment #10 from janus at gcc dot gnu.org 2012-11-28 12:16:59 UTC --- (In reply to comment #9) (In reply to comment #7) - if (tsource-expr_type != EXPR_CONSTANT - || fsource-expr_type != EXPR_CONSTANT - || mask-expr_type != EXPR_CONSTANT) + if (mask-expr_type != EXPR_CONSTANT) return NULL; That makes sense: If mask is a constant scalar, tsource or fsource can be used. That patch is pre-approved. Unfortunately, it triggers a couple of testsuite regressions: FAIL: gfortran.dg/bound_2.f90 -O0 execution test FAIL: gfortran.dg/bound_7.f90 -O0 execution test FAIL: gfortran.dg/char_cast_1.f90 -O scan-tree-dump-times original 6\\]\\[1\\] 2 FAIL: gfortran.dg/merge_char_3.f90 -O0 execution test The last one is understandable: It is supposed to check for different char lengths beings passed to MERGE at runtime, but the call to MERGE is simplified away (which is good!). The third one is a tree-dump failure, where apparently the dump is different because MERGE is simplified away now. The first two are runtime checks, which are basically identical. Here is a reduced test case for these: implicit none integer :: i(-1:1) = 0 print *, lbound(merge(i,i,.true.)) print *, ubound(merge(i,i,.true.)) end Without the patch, this prints: 1 3 And with the patch: -1 1 The output with the patch does look more reasonable to me. Or is there any reason why the standard would demand the MERGE expression to have bounds of 1:3 instead of -1:1 ?
[Bug tree-optimization/54547] [4.8 regression] FAIL: gcc.dg/tree-ssa/pr37508.c scan-tree-dump-times vrp1 Folding 3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54547 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org 2012-11-28 12:18:47 UTC --- Author: rguenth Date: Wed Nov 28 12:18:39 2012 New Revision: 193888 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193888 Log: 2012-11-28 Richard Biener rguent...@suse.de PR tree-optimization/54547 * tree-vrp.c (set_and_canonicalize_value_range): Handle 1-bit anti-ranges explicitely. (extract_range_from_assert): Properly canonicalize all built anti-ranges. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vrp.c
[Bug tree-optimization/54547] [4.8 regression] FAIL: gcc.dg/tree-ssa/pr37508.c scan-tree-dump-times vrp1 Folding 3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54547 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org 2012-11-28 12:19:11 UTC --- Fixed.
[Bug fortran/55501] [F03] ICE using MERGE in constant expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55501
--- Comment #11 from janus at gcc dot gnu.org 2012-11-28 12:22:02 UTC ---
(In reply to comment #10)
The first two are runtime checks, which are basically identical. Here is a
reduced test case for these:
implicit none
integer :: i(-1:1) = 0
print *, lbound(merge(i,i,.true.))
print *, ubound(merge(i,i,.true.))
end
Without the patch, this prints:
1
3
And with the patch:
-1
1
The output with the patch does look more reasonable to me. Or is there any
reason why the standard would demand the MERGE expression to have bounds of
1:3
instead of -1:1 ?
At least all of ifort, sunf95 and g95 agree with the first variant (1:3).
[Btw, the bound_{2,7} test cases come from PR 29391.]
[Bug other/55517] New: [ASAN] ASAN doesn't work with (soft) ulimit on virtual memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55517 Bug #: 55517 Summary: [ASAN] ASAN doesn't work with (soft) ulimit on virtual memory Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: rgue...@gcc.gnu.org The asan runtime should raise any soft limit on virtual memory by the amount of shadow virtual mappings it creates. Those are not accounted for in any limit calculation. If a hard limit is present it should probably report that instead of failing with a cryptic message that it cannot allocate memory: ==10720== ERROR: Failed to allocate 0x2001000 (2199023259648) bytes at address 0x0000 (12)
[Bug c++/55513] [4.7 Regression] Incorrect snprintf folding when building with -std=c++0x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55513 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.3 Known to fail||4.7.0 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org 2012-11-28 12:35:16 UTC --- Seems to be simply folded away.
[Bug bootstrap/55511] [4.8 Regression] r193802 caused s390x bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55511 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0 Summary|r193802 caused s390x|[4.8 Regression] r193802 |bootstrap failure |caused s390x bootstrap ||failure
[Bug middle-end/55507] [4.8 Regression] ICE in vt_expand_var_loc_chain, at var-tracking.c:8020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55507 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug c++/55494] ICE for char array or int in variadic template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55494 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Target Milestone|4.8.0 |---
[Bug lto/55493] [4.8 Regression] LTO always ICEs on i686-w64-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55493 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug other/55517] [ASAN] ASAN doesn't work with (soft) ulimit on virtual memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55517 Konstantin Serebryany konstantin.s.serebryany at gmail dot com changed: What|Removed |Added CC||konstantin.s.serebryany at ||gmail dot com --- Comment #1 from Konstantin Serebryany konstantin.s.serebryany at gmail dot com 2012-11-28 12:43:32 UTC --- I am quite sure that asan should not mess with the limits itself. It gets too messy too soon. (e.g. in tsan we try to reexec if the stack is unlimited, but it's not reliable). I agree, the messages could be less cryptic.
[Bug other/55517] [ASAN] ASAN doesn't work with (soft) ulimit on virtual memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55517 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org 2012-11-28 12:48:56 UTC --- (In reply to comment #1) I am quite sure that asan should not mess with the limits itself. It gets too messy too soon. (e.g. in tsan we try to reexec if the stack is unlimited, but it's not reliable). Well, raising a soft virtual limit should be straight-forward if you create such large mappings. SLES ships with a default soft virtual limit, and only asan knows how much extra shadow memory it needs. I agree, the messages could be less cryptic. It btw causes c-c++-common/asan/memcmp-1.c to FAIL in all my tests which is quite annoying because the addresses printed in the message vary and thus testresults are not comparable.
[Bug other/55517] [ASAN] ASAN doesn't work with (soft) ulimit on virtual memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55517 --- Comment #3 from Konstantin Serebryany konstantin.s.serebryany at gmail dot com 2012-11-28 12:50:09 UTC --- [The component for such bugs should be 'sanitizer' but for some reason I can't change it]
[Bug sanitizer/55517] [ASAN] ASAN doesn't work with (soft) ulimit on virtual memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55517 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added 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 Component|other |sanitizer --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org 2012-11-28 12:52:55 UTC --- (In reply to comment #3) [The component for such bugs should be 'sanitizer' but for some reason I can't change it] Ah, I searched for libasan and didn't find it. You can manage bugs if you login with your gcc.gnu.org account (or in the first place create one with your gcc.gnu.org e-mail address).
[Bug sanitizer/55517] [ASAN] ASAN doesn't work with (soft) ulimit on virtual memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55517 --- Comment #5 from Konstantin Serebryany konstantin.s.serebryany at gmail dot com 2012-11-28 12:56:53 UTC --- We try to minimize the number of syscalls we make in asan run-time. One reason for that is that asan may run in a sanbox which disallows some of them. (Another is just the code bloat) Why simply removing all the limits before running asan doesn't work? Better warning messages will make it move obvious.
[Bug sanitizer/55517] [ASAN] ASAN doesn't work with (soft) ulimit on virtual memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55517 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-28 13:00:27 UTC --- I think raising soft limit is a standard approach done in multiple places, even gcc itself does that, and is far better than just crashing. Unlike RLIMIT_STACK, it doesn't cause significant problems if you enlarge RLIMIT_AS during the runtime of a program as opposed to making sure it is big enough already at process start. You don't need to call getrlimit unconditionally, all you can do is upon mmap MAP_FAILED on these 3 large mmap calls you try to do getrlimit and if hard limit is bigger than what is needed and soft limit smaller, increase, setrlimit and retry the mmap.
[Bug sanitizer/55517] [ASAN] ASAN doesn't work with (soft) ulimit on virtual memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55517 --- Comment #7 from kcc at gcc dot gnu.org 2012-11-28 13:17:21 UTC --- BTW, the messages are actually quite nice: ==22487== ERROR: Failed to allocate 0x2001000 (2199023259648) bytes at address 0x0000 (12) ==22487== ReserveShadowMemoryRange failed while trying to map 0x2001000 bytes. Perhaps you're using ulimit -v
[Bug other/55358] Valgrind errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55358
--- Comment #7 from Markus Trippelsdorf markus at trippelsdorf dot de
2012-11-28 13:20:54 UTC ---
The fix for:
==23637== Invalid write of size 8
==23637==at 0xCF9951: rest_of_handle_dse() (dse.c:2874)
...
seems to be simple. Because of delete_dead_store_insn (ptr);
s_info-redundant_reason may point into lala land:
(gdb) p *s_info
$3 = {is_set = false, is_large = false, group_id = 0, cse_base =
0xafafafafafafafaf, mem = 0xafafafafafafafaf, mem_addr = 0xafafafafafafafaf,
alias_set = -1347440721, begin = -5787213827046133841, end =
-5787213827046133841, positions_needed = {small_bitmask = 12659530246663417775,
large = {bmap = 0xafafafafafafafaf, count = -1347440721}}, next =
0xafafafafafafafaf, rhs = 0xafafafafafafafaf, const_rhs = 0xafafafafafafafaf,
redundant_reason = 0xafafafafafafafaf}
(gdb) p *ptr
$8 = {cannot_delete = true, wild_read = false, non_frame_wild_read = false,
frame_read = false, stack_pointer_based = false, contains_cselib_groups =
false, insn = 0x0, store_rec = 0x0, read_rec = 0x0, fixed_regs_live =
0x5e34f30, prev_insn = 0x54e9da0, next_local_store = 0x54e9da0}
diff --git a/gcc/dse.c b/gcc/dse.c
index f879adb..8d12e8d 100644
--- a/gcc/dse.c
+++ b/gcc/dse.c
@@ -2869,7 +2869,7 @@ dse_step1 (void)
INSN_UID (s_info-redundant_reason-insn));
delete_dead_store_insn (ptr);
}
- if (s_info)
+ if (ptr-store_rec s_info)
s_info-redundant_reason = NULL;
free_store_info (ptr);
}
[Bug bootstrap/55511] [4.8 Regression] r193802 caused s390x bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55511 --- Comment #2 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-11-28 13:36:08 UTC --- (In reply to comment #1) Is this with the first build of libgcc? I.e. is it likely that I'll see this with just a cross-build? Also, can you please check whether the patch in http://gcc.gnu.org/ml/gcc-patches/2012-11/msg02188.html solves the problem, as it does for alpha-linux? I'll reply myself: apparently-yes, yes and yes; cross from x86_86-linux. And need to add -fpreprocessed to the cc1 command-line above or there's an unhelpful preprocessor error. So, once Jakub has committed that patch, please verify that this is sufficient (besides required). Thanks.
[Bug sanitizer/55485] probable false positive on __builtin_setjmp/__builtin_longjmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55485 --- Comment #7 from Kostya Serebryany kcc at gcc dot gnu.org 2012-11-28 13:37:02 UTC --- Note that the LLVM implementation inserts a call to __asan_handle_no_return before every no-return call instruction.
[Bug sanitizer/55485] probable false positive on __builtin_setjmp/__builtin_longjmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55485 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-28 13:47:41 UTC --- If I understand it right, that clears all shadow memory corresponding to current thread's stack, rather than trying to figure out into which function it longjmps and clearing only everything up to that frame, right? Might then lead to not reporting failures afterwards. But sure, we could do that (but I'd prefer to do it only after the asan/tsan builtins patch is reviewed). Do you do that just for noreturn calls? What about say __builtin_trap () or __builtin_unreachable ()? Though in the asan pass they are likely still represented as noreturn calls and can be handled the same way.
[Bug target/54791] AIX-only: Constructors are not called in main program.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54791 --- Comment #29 from Adi adivilceanu at yahoo dot com 2012-11-28 14:00:55 UTC --- Ok... if you are so kind please tell me exactly 1) how did you install the gcc(you said it works on your aix) ? I mean what mpfr,gmp, libmpc did you use and how did you install them? 2) How did you configure gcc before makeing? (the exact command line) 3) what aix do you you use(oslevel -s) ? and any other pre-requisites that I should put in order for me to have my gcc built.(environment vars... etc)
[Bug sanitizer/55485] probable false positive on __builtin_setjmp/__builtin_longjmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55485 --- Comment #9 from Kostya Serebryany kcc at gcc dot gnu.org 2012-11-28 14:00:53 UTC --- Correct. __asan_handle_no_return may loose some of the stack-buffer overflows. It is also used to handle clone case, where the entire stack should be unpoisoned. http://code.google.com/p/address-sanitizer/issues/detail?id=37can=1q=clone rather than trying to figure out into which function it longjmps and clearing only everything up to that frame, right I am not sure how to do it w/o going too deep inside the longjmp implementation. The code we care about almost never uses longjmp (and C++ exceptions) so we didn't bother. But yes, we have this case of false negative. Do you do that just for noreturn calls? Yes, we just rely on LLVM telling us that a call is noreturn. (haha, there is actually a minor problem in our LLVM pass. http://code.google.com/p/address-sanitizer/issues/detail?id=129 ) What about say __builtin_trap () or __builtin_unreachable ()? __builtin_trap is not asan-hostile in this manner. Today we don't prepend it with __asan_handle_no_return
[Bug bootstrap/55511] [4.8 Regression] r193802 caused s390x bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55511 --- Comment #3 from Andreas Krebbel krebbel at gcc dot gnu.org 2012-11-28 14:10:24 UTC --- (In reply to comment #2) (In reply to comment #1) Is this with the first build of libgcc? I.e. is it likely that I'll see this with just a cross-build? Also, can you please check whether the patch in http://gcc.gnu.org/ml/gcc-patches/2012-11/msg02188.html solves the problem, as it does for alpha-linux? I'll reply myself: apparently-yes, yes and yes; cross from x86_86-linux. And need to add -fpreprocessed to the cc1 command-line above or there's an unhelpful preprocessor error. So, once Jakub has committed that patch, please verify that this is sufficient (besides required). Thanks. Native build is finished as well. Jakub's patch fixes the issue.
[Bug tree-optimization/55264] [4.6/4.7/4.8 Regression] ICE: in ipa_make_edge_direct_to_target, at ipa-prop.c:2141 with -O2 -fno-early-inlining -fno-weak
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55264 Aldy Hernandez aldyh at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org, ||mjambor at suse dot cz --- Comment #4 from Aldy Hernandez aldyh at gcc dot gnu.org 2012-11-28 14:15:59 UTC --- Honza/Martin. Would you mind taking a look at this, or at least provide some guidance? A similar ICE to this one starts appearing around rev@159507 for the provided testcase: 2010-05-17 Martin Jambor mjam...@suse.cz * cgraph.h (cgraph_indirect_call_info): New fields anc_offset, otr_token and polymorphic. * cgraph.c (cgraph_create_indirect_edge): Inilialize the above fields. (cgraph_clone_edge): Copy the above fields. * tree.c (get_binfo_at_offset): New function. * tree.h (get_binfo_at_offset): Declare. * ipa-prop.h (enum jump_func_type): Added known_type jump function ... ... There is also a set of related patches to ipa*/cgraph* around this time frame by both of you. Thanks.
[Bug c++/55513] [4.7/4.8 Regression] Incorrect snprintf folding when building with -std=c++0x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55513 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org Summary|[4.7 Regression] Incorrect |[4.7/4.8 Regression] |snprintf folding when |Incorrect snprintf folding |building with -std=c++0x|when building with ||-std=c++0x --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-28 14:25:44 UTC --- With const int strLength = snprintf(str, 10, Hello); instead it fails also on the trunk, with sizeof(str) it has been fixed by my http://gcc.gnu.org/viewcvs?root=gccview=revrev=192141 changes.
[Bug sanitizer/48076] Unsafe double checked locking in __emutls_get_address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48076 --- Comment #7 from torvald at gcc dot gnu.org 2012-11-28 14:29:47 UTC --- (In reply to comment #6) There seems to be a similar bug in code generated for function static variables. The fast-path load is a plain load rather than atomic acquire load. Haven't looked at the details, but this indeed looks similar.
[Bug lto/55474] global-buffer-overflow in lto-wrapper.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55474 --- Comment #2 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2012-11-28 14:38:50 UTC --- Author: hjl Date: Wed Nov 28 14:38:40 2012 New Revision: 193893 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193893 Log: Handle OPT_SPECIAL_XXX in LTO Backported from mainline PR lto/54795 * lto-opts.c (lto_write_options): Also handle OPT_SPECIAL_unknown, OPT_SPECIAL_ignore and OPT_SPECIAL_program_name. PR lto/55474 * lto-wrapper.c (merge_and_complain): Handle OPT_SPECIAL_unknown, OPT_SPECIAL_ignore, OPT_SPECIAL_program_name and OPT_SPECIAL_input_file. Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/lto-opts.c branches/gcc-4_7-branch/gcc/lto-wrapper.c
[Bug lto/54795] global-buffer-overflow in lto_write_options
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54795 --- Comment #28 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2012-11-28 14:38:50 UTC --- Author: hjl Date: Wed Nov 28 14:38:40 2012 New Revision: 193893 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193893 Log: Handle OPT_SPECIAL_XXX in LTO Backported from mainline PR lto/54795 * lto-opts.c (lto_write_options): Also handle OPT_SPECIAL_unknown, OPT_SPECIAL_ignore and OPT_SPECIAL_program_name. PR lto/55474 * lto-wrapper.c (merge_and_complain): Handle OPT_SPECIAL_unknown, OPT_SPECIAL_ignore, OPT_SPECIAL_program_name and OPT_SPECIAL_input_file. Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/lto-opts.c branches/gcc-4_7-branch/gcc/lto-wrapper.c
[Bug lto/54795] global-buffer-overflow in lto_write_options
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54795 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Version|4.8.0 |4.7.3 Resolution||FIXED --- Comment #29 from H.J. Lu hjl.tools at gmail dot com 2012-11-28 14:40:09 UTC --- Fixed for 4.7.3 and 4.8.
[Bug lto/55474] global-buffer-overflow in lto-wrapper.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55474 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.7.3 --- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2012-11-28 14:41:23 UTC --- Fixed for 4.7.3 and 4.8.
[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 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added CC||jamborm at gcc dot gnu.org --- Comment #5 from Martin Jambor jamborm at gcc dot gnu.org 2012-11-28 14:43:20 UTC --- (In reply to comment #4) I'll add a loop to the test that hopefully triggers the inlining (and does the unrolling). Unrolling? Adding both variants (renamed main and with loop) to the test suite would be fantastic. Does this mean you are going to do it or is it a request? FWIW, I think that having just one variant is sufficient.
[Bug other/55358] Valgrind errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55358 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-28 Ever Confirmed|0 |1 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-28 14:47:33 UTC --- (In reply to comment #7) diff --git a/gcc/dse.c b/gcc/dse.c index f879adb..8d12e8d 100644 --- a/gcc/dse.c +++ b/gcc/dse.c @@ -2869,7 +2869,7 @@ dse_step1 (void) INSN_UID (s_info-redundant_reason-insn)); delete_dead_store_insn (ptr); } - if (s_info) + if (ptr-store_rec s_info) s_info-redundant_reason = NULL; free_store_info (ptr); } Actually, I fail to see what is that if (s_info) s_info-redundant_reason = NULL; good for, the following free_store_info (ptr) should pool_free s_info if delete_dead_store_insn hasn't already called free_store_info. And it doesn't seem that pool_alloced store info recs would rely on the field being cleared, it seems we initialize it always: store_info-redundant_reason = redundant_reason; Thus, my preference would be just drop the two lines instead.
[Bug fortran/55501] [F03] ICE using MERGE in constant expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55501 --- Comment #12 from Tobias Burnus burnus at gcc dot gnu.org 2012-11-28 14:54:33 UTC --- (In reply to comment #10) integer :: i(-1:1) = 0 print *, lbound(merge(i,i,.true.)) Without the patch, this prints: 1 And with the patch: -1 Makes perfectly sense: For lbound(array,dim): If ARRAY is a whole array and either ARRAY is an assumed-size array of rank DIM or dimension DIM of ARRAY has nonzero extent, LBOUND (ARRAY, DIM) has a value equal to the lower bound for subscript DIM of ARRAY. Otherwise the result value is 1. With whole array array component or array name without further quali cation (6.5.2) Thus lbound(i) is a whole-array, lbound(i(:)) or lbound(merge(i,i,.true)) is not. I think the simplest it to replace lbound (merge(i,i,.true.) by lbound( (i) ) [e-expr_type = EXPR_OP e-value.op.op == INTRINSIC_PARENTHESES]. Possibly only if expr_type == EXPR_VARIABLE as otherwise the INTRINSIC_PARENTHESES will hamper further optimization (unless -fno-protect-parens).
[Bug fortran/55469] memory leak on read with istat.ne.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55469 Matthias Krack matthias.krack at gmail dot com changed: What|Removed |Added CC||matthias.krack at gmail dot ||com --- Comment #4 from Matthias Krack matthias.krack at gmail dot com 2012-11-28 14:58:23 UTC --- Thanks Tobias, the fix you propose in comment 3 seems indeed to solve the problem for the test case of Joost as well as for the valgrind based regtest of the current CP2K development version in which this memory leak originally showed up.
[Bug sanitizer/55518] New: boehm-gc, libatomic, libffi and libgomp testsuite can't find path to libasan for make check with -fsanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55518
Bug #: 55518
Summary: boehm-gc, libatomic, libffi and libgomp testsuite
can't find path to libasan for make check with
-fsanitizer
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: howa...@nitro.med.uc.edu
CC: do...@gcc.gnu.org, dvyu...@gcc.gnu.org,
ja...@gcc.gnu.org, k...@gcc.gnu.org
While using...
make -k check RUNTESTFLAGS=--target_board=unix'{-fsanitize=address}'
is sufficient for the testsuite residing in the gcc subdirectory to find
the built libasan for linkage, the libffi testsuite fails in its entirety
with errors...
ld: library not found for -lasan^M
collect2: error: ld returned 1 exit status^M
compiler exited with status 1
output is:
ld: library not found for -lasan^M
collect2: error: ld returned 1 exit status^M
The same issue exists in the libgomp, boehm-gc and libatomic testsuites.
Interestingly, the libstdc++-v3 manages to find the path to libasan without any
additional options being passed on --target_board=unix than -fsanitize=address.
[Bug fortran/52161] Internal compiler errors with -fcheck=bounds in coarray tests
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52161 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-11-28 15:12:52 UTC --- Still there at revision 193884.
[Bug middle-end/55481] [4.8 regression] -O2 generates a wrong-code infinite loop in C++Benchmark's simple_types_constant_folding int8 xor test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55481
--- Comment #9 from Richard Biener rguenth at gcc dot gnu.org 2012-11-28
15:14:20 UTC ---
Testcase that fails (infinite loop) with both the C and the C++ frontend at
-O2:
int main()
{
signed char result = 0;
int n;
for (n = 0; n 13; ++n)
{
int tem = result;
tem = tem + 31;
result = tem;
}
if (result != -109)
__builtin_abort ();
return 0;
}
[Bug c++/55513] [4.7/4.8 Regression] Incorrect snprintf folding when building with -std=c++0x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55513 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-28 15:15:11 UTC --- In cp_parser_constant_expression when we call cp_parser_assignment_expression on the initializer, it returns ((char *) __builtin_memcpy ((char *) str, (const char *) Hello, 6);, 5) As this is C++11, we call potential_rvalue_constant_expression which returns true (the call in the COMPOUND_EXPR is builtin, and all its arguments are pontential_rvalue_constant_expression arguments). I bet somewhere later on we see that it is const and ignore the TREE_SIDE_EFFECTS initializer.
[Bug middle-end/55481] [4.8 regression] -O2 generates a wrong-code infinite loop in C++Benchmark's simple_types_constant_folding int8 xor test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55481 --- Comment #10 from Richard Biener rguenth at gcc dot gnu.org 2012-11-28 15:16:00 UTC --- Caused by 2012-06-27 Richard Guenther rguent...@suse.de PR middle-end/53676 * tree-chrec.c (chrec_convert_1): Represent truncation to a type with undefined overflow as truncation to an unsigned type converted to the type with undefined overflow. * tree-scalar-evolution.c (interpret_rhs_expr): For computing the scalar evolution of a truncated widened operation avoid looking at the non-existing evolution of the widened operation result.
[Bug middle-end/55481] [4.8 regression] -O2 generates a wrong-code infinite loop in C++Benchmark's simple_types_constant_folding int8 xor test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55481 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | --- Comment #11 from Richard Biener rguenth at gcc dot gnu.org 2012-11-28 15:16:51 UTC --- Mine.
[Bug middle-end/55481] [4.8 regression] -O2 generates a wrong-code infinite loop in C++Benchmark's simple_types_constant_folding int8 xor test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55481
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
CC||rakdver at gcc dot gnu.org
--- Comment #12 from Richard Biener rguenth at gcc dot gnu.org 2012-11-28
15:38:46 UTC ---
We have
@@ -15,22 +15,11 @@
(scalar = result_11)
(get_scalar_evolution
(scalar = result_11)
- (scalar_evolution = result_11))
+ (scalar_evolution = (signed char) {0, +, 31}_1))
that isn't wrong. But IVOPTs happily uses STRIP_NOPs which also strips
sign-conversions. simple_iv returns true for result_11 in
signed char result;
bb 3:
# result_11 = PHI result_5(4), 0(2)
# ivtmp_10 = PHI ivtmp_9(4), 13(2)
tem_3 = (int) result_11;
tem_4 = tem_3 + 31;
result_5 = (signed char) tem_4;
ivtmp_9 = ivtmp_10 - 1;
if (ivtmp_9 != 0)
goto bb 4;
else
goto bb 5;
bb 4:
goto bb 3;
now, but iv-no_overflow is false (and IVOPTs nowhere uses that flag ...).
I can fix this for example with
Index: tree-ssa-loop-ivopts.c
===
--- tree-ssa-loop-ivopts.c (revision 193887)
+++ tree-ssa-loop-ivopts.c (working copy)
@@ -982,6 +982,9 @@ determine_biv_step (gimple phi)
if (!simple_iv (loop, loop, name, iv, true))
return NULL_TREE;
+ if (!iv.no_overflow)
+return NULL_TREE;
+
return integer_zerop (iv.step) ? NULL_TREE : iv.step;
}
but I'm not sure what invariants should hold for BIVs and if the overflow
check should happen in a different place instead. Zdenek?
[Bug sanitizer/55518] boehm-gc, libatomic, libffi and libgomp testsuite can't find path to libasan for make check with -fsanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55518 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-28 15:45:30 UTC --- That is not a bug, you've requested to add that flag, therefore you are responsible to make sure gcc finds it at link time and runtime (e.g. by installing it temporarily into a system directory where it is found by default, into sysroot, or using env var options to point it there. That is the same thing as if you tried to use -fopenmp or -fgnu-tm options by default.
[Bug c++/55513] [4.7/4.8 Regression] Incorrect snprintf folding when building with -std=c++0x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55513
--- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-28
15:51:21 UTC ---
Reduced testcase:
void
f1 ()
{
char s[10];
const int t = __builtin_snprintf (s, 10, Hello);
__builtin_printf (%d %s\n, t, s);
}
void
f2 ()
{
char s[10];
const int t = (__builtin_memcpy (s, Hello, 6), 5);
__builtin_printf (%d %s\n, t, s);
}
int
main ()
{
f1 ();
f2 ();
}
Even f2 fails to call memcpy, so it isn't related to folding the snprintf into
what it folds to, but about handling COMPOUND_EXPRs with side-effects on the
LHS where the only side-effects are builtin calls. If the LHS of the
COMPOUND_EXPR is a non-builtin, potential_rvalue_constant_expression returns
false and it is handled correctly, but even if it is say __builtin_exit (0) or
similar, it is optimized away.
[Bug fortran/52161] Internal compiler errors with -fcheck=bounds in coarray tests
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52161 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-28 16:03:46 UTC --- Untested patch: --- a/gcc/fortran/trans-stmt.c +++ b/gcc/fortran/trans-stmt.c @@ -797,3 +797,3 @@ gfc_trans_sync (gfc_code *code, gfc_exec_op type) %d in SYNC IMAGES, - fold_convert (integer_type_node, se.expr)); + fold_convert (integer_type_node, images)); }
[Bug middle-end/55481] [4.8 regression] -O2 generates a wrong-code infinite loop in C++Benchmark's simple_types_constant_folding int8 xor test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55481 --- Comment #13 from rakdver at iuuk dot mff.cuni.cz 2012-11-28 16:19:11 UTC --- now, but iv-no_overflow is false (and IVOPTs nowhere uses that flag ...). I can fix this for example with Index: tree-ssa-loop-ivopts.c === --- tree-ssa-loop-ivopts.c (revision 193887) +++ tree-ssa-loop-ivopts.c (working copy) @@ -982,6 +982,9 @@ determine_biv_step (gimple phi) if (!simple_iv (loop, loop, name, iv, true)) return NULL_TREE; + if (!iv.no_overflow) +return NULL_TREE; + return integer_zerop (iv.step) ? NULL_TREE : iv.step; } but I'm not sure what invariants should hold for BIVs and if the overflow check should happen in a different place instead. Zdenek? Ivopts transformations are intended to work even with wrapping induction variables; so this does not seem to be the right place to fix the problem. I will have to have a closer look to see what goes wrong.
[Bug testsuite/55504] gcc.c-torture/execute/20071018-1.c execution failures with -fsanitize=address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55504 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-28 16:28:19 UTC --- Author: jakub Date: Wed Nov 28 16:28:06 2012 New Revision: 193898 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193898 Log: PR testsuite/55504 * gcc.c-torture/execute/20071018-1.c (foo): Add noinline/noclone attributes. Avoid clobbering memory before malloced chunk. (main): Pass 1 instead of 0 as argument. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.c-torture/execute/20071018-1.c
[Bug testsuite/55505] gcc.c-torture/execute/921202-1.c execution failures with -fsanitize=address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55505 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-28 16:29:13 UTC --- Author: jakub Date: Wed Nov 28 16:28:57 2012 New Revision: 193899 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193899 Log: PR testsuite/55505 * gcc.c-torture/execute/921202-1.c: Increase size of dx and dy arrays. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.c-torture/execute/921202-1.c
[Bug testsuite/55504] gcc.c-torture/execute/20071018-1.c execution failures with -fsanitize=address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55504 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-28 16:32:43 UTC --- Fixed.
[Bug testsuite/55505] gcc.c-torture/execute/921202-1.c execution failures with -fsanitize=address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55505 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-28 16:39:29 UTC --- Fixed.
[Bug sanitizer/55518] boehm-gc, libatomic, libffi and libgomp testsuite can't find path to libasan for make check with -fsanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55518
--- Comment #2 from Jack Howarth howarth at nitro dot med.uc.edu 2012-11-28
16:48:55 UTC ---
This seems to be sufficient for libstc++-v3...
Index: libstdc++-v3/testsuite/lib/libstdc++.exp
===
--- libstdc++-v3/testsuite/lib/libstdc++.exp(revision 193849)
+++ libstdc++-v3/testsuite/lib/libstdc++.exp(working copy)
@@ -84,7 +84,7 @@
# Called once, during runtest.exp setup.
proc libstdc++_init { testfile } {
global env
-global v3-sharedlib v3-libgomp
+global v3-sharedlib v3-libgomp v3-libasan
global srcdir blddir objdir tool_root_dir
global cc cxx cxxflags cxxpchflags cxxldflags
global includes
@@ -159,6 +159,18 @@
}
v3track libgompdir 3
+# Locate libasan. This is only required for parallel mode.
+set v3-libasan 0
+set libasandir [lookfor_file $blddir/../libsanitizer/asan
.libs/libasan.$shlib_ext]
+if {$libasandir != } {
+set v3-libasan 1
+set libasandir [file dirname $libasandir]
+append ld_library_path_tmp :${libasandir}
+verbose -log libasan support detected
+}
+v3track libasandir 3
+
+
# Locate libstdc++ shared library. (ie libstdc++.so.)
set v3-sharedlib 0
set sharedlibdir [lookfor_file $blddir src/.libs/libstdc++.$shlib_ext]
[Bug other/55358] Valgrind errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55358 --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-28 16:49:49 UTC --- Author: jakub Date: Wed Nov 28 16:49:35 2012 New Revision: 193900 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193900 Log: PR other/55358 * dse.c (rest_of_handle_dse): Remove superfluous clearing. Modified: trunk/gcc/ChangeLog trunk/gcc/dse.c
[Bug sanitizer/55518] boehm-gc, libatomic, libffi and libgomp testsuite can't find path to libasan for make check with -fsanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55518 Jack Howarth howarth at nitro dot med.uc.edu changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | Severity|normal |enhancement --- Comment #3 from Jack Howarth howarth at nitro dot med.uc.edu 2012-11-28 17:17:33 UTC --- Switching to an enhancement of the testsuite coverage.
[Bug sanitizer/55518] boehm-gc, libatomic, libffi and libgomp testsuite can't find path to libasan for make check with -fsanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55518 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-28 17:23:32 UTC --- I still think it is a very bad idea. As I said earlier, there are lots of similar compiler options that require their corresponding runtime libraries, and adding lots of junk to each *.exp just because user might use those options in RUNTESTFLAGS is overkill.
[Bug c++/53094] vector literal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53094 --- Comment #2 from Marc Glisse glisse at gcc dot gnu.org 2012-11-28 17:25:51 UTC --- Created attachment 28820 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28820 Incomplete patch Slightly ridiculous: with this patch, v+v still fails because we don't manage to fold a NOP_EXPR that casts a VECTOR_CST from V2DI to const V2DI...
[Bug c++/52844] ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52844 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||jondreads at gmail dot com --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-28 17:39:32 UTC --- *** Bug 55494 has been marked as a duplicate of this bug. ***
[Bug c++/55494] ICE for char array or int in variadic template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55494 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-28 17:39:32 UTC --- This is invalid and essentially equivalent to PR52844: operator takes as m a Foo which is a (variadic) type template, but the Foo we are defining is a non-type template. Note that when there are no variadic templates around these testcases are simply rejected. *** This bug has been marked as a duplicate of bug 52844 ***
[Bug rtl-optimization/55512] [4.8 Regression] Various LRA ICEs with inline-asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55512 --- Comment #3 from Vladimir Makarov vmakarov at gcc dot gnu.org 2012-11-28 17:42:50 UTC --- Author: vmakarov Date: Wed Nov 28 17:42:39 2012 New Revision: 193901 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193901 Log: 2012-11-28 Vladimir Makarov vmaka...@redhat.com PR rtl-optimization/55512 * lra-assigns.c (assign_by_spills): Assigned arbitrary hard regs to failed reload pseudos instead of changing asm pattern. * lra-constraints.c (MAX_CONSTRAINT_ITERATION_NUMBER): Increase value. 2012-11-28 Vladimir Makarov vmaka...@redhat.com PR rtl-optimization/55512 * gcc.target/i386/pr55512-[1234].c: New tests. Added: trunk/gcc/testsuite/gcc.target/i386/pr55512-1.c trunk/gcc/testsuite/gcc.target/i386/pr55512-2.c trunk/gcc/testsuite/gcc.target/i386/pr55512-3.c trunk/gcc/testsuite/gcc.target/i386/pr55512-4.c Modified: trunk/gcc/ChangeLog trunk/gcc/lra-assigns.c trunk/gcc/lra-constraints.c trunk/gcc/testsuite/ChangeLog
[Bug sanitizer/55518] boehm-gc, libatomic, libffi and libgomp testsuite can't find path to libasan for make check with -fsanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55518 --- Comment #5 from Jack Howarth howarth at nitro dot med.uc.edu 2012-11-28 18:23:45 UTC --- Considering that H.J. is working towards a --with-build-config=bootstrap-asan option, it would seem wise to allow for testing the existing FSF gcc testsuite against libasan without folks having to really hack up their source tree to do so. Wasn't libsanitizer added to vet the code generation of FSF gcc? That would place it in a slightly different category than say --fopenmp or -fgnu-tm.
[Bug middle-end/55507] [4.8 Regression] ICE in vt_expand_var_loc_chain, at var-tracking.c:8020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55507 --- Comment #1 from Richard Henderson rth at gcc dot gnu.org 2012-11-28 18:25:03 UTC --- Created attachment 28821 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28821 preprocessed alpha source Looks like the same problem for alpha, occurring elsewhere in the build. Since this is _powtf2, you probably need --enable-long-double-128 in the configure line when cross-compiling.
[Bug middle-end/55507] [4.8 Regression] ICE in vt_expand_var_loc_chain, at var-tracking.c:8020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55507 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Keywords||patch --- Comment #2 from Uros Bizjak ubizjak at gmail dot com 2012-11-28 18:36:04 UTC --- (In reply to comment #1) Created attachment 28821 [details] preprocessed alpha source Looks like the same problem for alpha, occurring elsewhere in the build. This is fixed by Jakub's patch at [1]. [1] http://gcc.gnu.org/ml/gcc-patches/2012-11/msg02188.html
[Bug middle-end/55507] [4.8 Regression] ICE in vt_expand_var_loc_chain, at var-tracking.c:8020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55507 --- Comment #3 from dave.anglin at bell dot net 2012-11-28 18:50:26 UTC --- On 11/28/2012 1:25 PM, rth at gcc dot gnu.org wrote: Since this is _powtf2, you probably need --enable-long-double-128 in the configure line when cross-compiling. Actually, it's 64 bits on hppa-linux. Has the long double default changed?
[Bug sanitizer/55508] many test cases fail using -fsanitize=address with internal compiler error: in expand_call_tm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55508 --- Comment #3 from Jack Howarth howarth at nitro dot med.uc.edu 2012-11-28 18:57:10 UTC --- This failure in expand_call_tm, at trans-mem.c:2273 is also seen in the libitm testsuite for... FAIL: libitm.c/dropref-2.c (internal compiler error) FAIL: libitm.c/dropref-2.c (test for excess errors) FAIL: libitm.c/stackundo.c (internal compiler error) FAIL: libitm.c/stackundo.c (test for excess errors)
