[Bug fortran/55574] [4.8 Regression] C binding access to c_ptr type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55574 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Tobias Burnus burnus at gcc dot gnu.org --- As the current patch is rather intrusive and as the issue is fixed in the released compiler 4.9.0, it is unlikely that the fix is backported to GCC 4.8. Hence: - WON'T FIX for GCC 4.8. - FIXED for GCC 4.9/4.10. Thanks for the report, the patience and sorry that it won't get fixed in GCC 4.7/4.8 any more.
[Bug fortran/56079] [4.8 Regression] ICE with C_PTR renaming and TRANSFER
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56079 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Tobias Burnus burnus at gcc dot gnu.org --- As the current patch is rather intrusive and as the issue is fixed in the released compiler 4.9.0, it is unlikely that the fix is backported to GCC 4.8. Hence: - WON'T FIX for GCC 4.8. - FIXED for GCC 4.9/4.10. Thanks for the report, the patience and sorry that it won't get fixed in GCC 4.7/4.8 any more.
[Bug fortran/56378] [4.8 Regression] ICE with C_LOC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56378 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #14 from Tobias Burnus burnus at gcc dot gnu.org --- As the current patch is rather intrusive and as the issue is fixed in the released compiler 4.9.0, it is unlikely that the fix is backported to GCC 4.8. Hence: - WON'T FIX for GCC 4.8. - FIXED for GCC 4.9/4.10. Thanks for the report, the patience and sorry that it won't get fixed in GCC 4.7/4.8 any more.
[Bug target/56858] alpha looks for NOTE_INSN_EH_REGION notes that cannot exist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56858 --- Comment #16 from uros at gcc dot gnu.org --- Author: uros Date: Fri Jul 11 07:42:50 2014 New Revision: 212449 URL: https://gcc.gnu.org/viewcvs?rev=212449root=gccview=rev Log: PR target/56858 * config/alpha/alpha.c: Include tree-pass.h, context.h and pass_manager.h. (pass_data_handle_trap_shadows): New pass. (pass_handle_trap_shadows::gate): New pass gate function. (make_pass_handle_trap_shadows): New function. (rest_of_handle_trap_shadows): Ditto. (alpha_align_insns_1): Rename from alpha_align_insns. (pass_data_align_insns): New pass. (pass_align_insns::gate): New pass gate function. (make_pass_aling_insns): New function. (rest_of_align_insns): Ditto. (alpha_align_insns): Ditto. (alpha_option_override): Declare handle_trap_shadows info and align_insns_info. Register handle_trap_shadows and align_insns passes here. (alpha_reorg): Do not call alpha_trap_shadows and alpha_align_insn from here. (alpha_pad_function_end): Do not skip BARRIERs. Modified: trunk/gcc/ChangeLog trunk/gcc/config/alpha/alpha.c
[Bug middle-end/61776] [4.9/4.10 Regression] ICE: verify_flow_info failed: control flow in the middle of basic block with -fprofile-generate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61776
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Keywords||ice-checking
Last reconfirmed||2014-07-11
Component|tree-optimization |middle-end
CC||hubicka at gcc dot gnu.org
Ever confirmed|0 |1
Summary|ICE: verify_flow_info |[4.9/4.10 Regression] ICE:
|failed: control flow in the |verify_flow_info failed:
|middle of basic block with |control flow in the middle
|-fprofile-generate |of basic block with
||-fprofile-generate
Target Milestone|--- |4.9.1
--- Comment #1 from Richard Biener rguenth at gcc dot gnu.org ---
There are several possibilities:
- don't instrument pure/const functions
- do not reset the pure/const flag (I see no reason to - the compiler might
not insert side-effects and we can consider the counter updates as
non-side-effect)
That is, I wonder why we do
/* Drop pure/const flags from instrumented functions. */
FOR_EACH_DEFINED_FUNCTION (node)
{
if (!gimple_has_body_p (node-decl)
|| !(!node-clone_of
|| node-decl != node-clone_of-decl))
continue;
/* Don't profile functions produced for builtin stuff. */
if (DECL_SOURCE_LOCATION (node-decl) == BUILTINS_LOCATION)
continue;
cgraph_set_const_flag (node, false, false);
cgraph_set_pure_flag (node, false, false);
}
but don't then call execute_fixup_cfg () again (but it doesn't yet deal
with a const/pure function becoming non-pure/const and thus a bb-ending
stmt).
Btw, this is yet another case where transitioning to call flags instead
of decl flags would save us - definitely even the instrumented call cannot
return abnormally.
Dropping the clearing of const/pure fixes the bug. Honza? I only can think
of the case where we have
for (..)
{
const ();
const ();
}
and inline only one of the calls where after that loop store-motion might
apply store-motion to the counter updates of the inline clone, overwriting
the updates from the non-inline call. But do we really care?
Anyway, confirmed. Btw, goo() should be leaf but it seems we don't
auto-compute 'leaf' yet?
[Bug target/61561] arm gcc internal error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61561 --- Comment #4 from mzakirov at gcc dot gnu.org --- Author: mzakirov Date: Fri Jul 11 09:02:39 2014 New Revision: 212450 URL: https://gcc.gnu.org/viewcvs?rev=212450root=gccview=rev Log: gcc/ 2014-07-11 Marat Zakirov m.zaki...@samsung.com PR target/61561 * config/arm/arm.md (*movhi_insn_arch4): Handle stack pointer. (*movhi_bytes): Likewise. (*arm_movqi_insn): Likewise. gcc/testsuite/ 2014-07-11 Marat Zakirov m.zaki...@samsung.com PR target/61561 * gcc.dg/pr61561.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr61561.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.md trunk/gcc/testsuite/ChangeLog
[Bug c++/61288] valgrind finds problem in build_conditional_expr_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61288 Kostya Serebryany kcc at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-07-11 CC||kcc at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Kostya Serebryany kcc at gcc dot gnu.org --- I see this bug as well while running asan-ified or msan-ified gcc r212448 Besides just being a bug it also prevents me from testing gcc with asan and msan Minimized reproducer coming soon. ==6753==ERROR: AddressSanitizer: heap-use-after-free on address 0x6210001c49a8 at pc 0x5df403 bp 0x7fff67fe9a70 sp 0x7fff67fe9a68 READ of size 1 at 0x6210001c49a8 thread T0 #0 0x5df402 in build_conditional_expr_1 gcc/cp/call.c:4842:11 #1 0x5db148 in build_conditional_expr gcc/cp/call.c:5089:9 #2 0x965849 in build_x_conditional_expr gcc/cp/typeck.c:6073:10 #3 0x88f88d in cp_parser_question_colon_clause gcc/cp/parser.c:8146:10 #4 0x88f88d in cp_parser_assignment_expression gcc/cp/parser.c:8185 0x6210001c49a8 is located 168 bytes inside of 4064-byte region [0x6210001c4900,0x6210001c58e0) freed by thread T0 here: #0 0x5a3871 in free #1 0x7fa9dca702a7 in obstack_free #2 0x5dcf0a in build_conditional_expr_1 gcc/cp/call.c:4822:7 #3 0x5db148 in build_conditional_expr gcc/cp/call.c:5089:9 #4 0x965849 in build_x_conditional_expr gcc/cp/typeck.c:6073:10 #5 0x88f88d in cp_parser_question_colon_clause gcc/cp/parser.c:8146:10 #6 0x88f88d in cp_parser_assignment_expression gcc/cp/parser.c:8185 previously allocated by thread T0 here: #0 0x5a3b49 in __interceptor_malloc #1 0x2907384 in xmalloc #2 0x7fa9dca701c5 in _obstack_newchunk /build/buildd/eglibc-2.15/malloc/obstack.c:271 #3 0x5ce9c6 in conversion_obstack_alloc gcc/cp/call.c:615:7 #4 0x5c7029 in alloc_conversion gcc/cp/call.c:724:22 #5 0x5c7029 in build_identity_conv gcc/cp/call.c:1049 #6 0x5c7029 in build_user_type_conversion_1 gcc/cp/call.c:3620 #7 0x5d0297 in implicit_conversion gcc/cp/call.c:1820:14 #8 0x5dbf3f in build_conditional_expr_1 gcc/cp/call.c:4769:15 #9 0x5db148 in build_conditional_expr gcc/cp/call.c:5089:9 #10 0x965849 in build_x_conditional_expr gcc/cp/typeck.c:6073:10 #11 0x88f88d in cp_parser_question_colon_clause gcc/cp/parser.c:8146:10 #12 0x88f88d in cp_parser_assignment_expression gcc/cp/parser.c:8185
[Bug target/61561] arm gcc internal error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61561 Marat Zakirov m.zakirov at samsung dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Marat Zakirov m.zakirov at samsung dot com --- fixed
[Bug c++/61288] valgrind finds problem in build_conditional_expr_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61288 --- Comment #2 from Kostya Serebryany kcc at gcc dot gnu.org --- Created attachment 33107 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33107action=edit 61288.cc Somewhat minimized reproducer: cc1plus -mtune=generic -march=x86-64 -std=gnu++11 61288.cc
[Bug c++/61288] valgrind finds problem in build_conditional_expr_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61288 Kostya Serebryany kcc at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org --- Comment #3 from Kostya Serebryany kcc at gcc dot gnu.org --- Seems to have appeared after r210281
[Bug lto/41606] Not all types are fixed up
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41606 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Fixed in 4.9 with SCC merging.
[Bug target/61778] New: inaccurate conversion of floating constants with the IBM long double format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61778
Bug ID: 61778
Summary: inaccurate conversion of floating constants with the
IBM long double format
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
On PowerPC, which uses the IBM long double format (double-double arithmetic),
the conversion of floating constants of long double type is inaccurate, as
shown by the following code:
#include stdio.h
#define STRINGIFY(S) #S
#define MAKE_STR(S) STRINGIFY(S)
#define CAT1(X) 1 ## X
#define CAT2(X) CAT1(X)
#define LD0 .0001L
#define LD1 CAT2(LD0)
int main (void)
{
long double x = 1.0L + LD0, y = LD1;
if (x 1.0L y == 1.0L)
{
printf (Bad conversion of MAKE_STR(LD1) \n);
printf (Got 1 instead of about 1 + %La\n, x - 1.0L);
return 1;
}
return 0;
}
On gcc110.fsffrance.org:
$ gcc ldtest.c -o ldtest
$ ./ldtest
Bad conversion of 1.0001L
Got 1 instead of about 1 + 0x1.54484932d2e72p-120
The compiler on this machine is:
gcc (GCC) 4.7.2 20121109 (Red Hat 4.7.2-8)
[Bug tree-optimization/61757] [4.10 Regression] genmodes failure with enable-checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #11 from Richard Biener rguenth at gcc dot gnu.org --- Still reproduces on x86_64 with --enable-checking=release. stage1 gcc miscompiles stage2 tree-vrp.c which then miscompiles stage3 genmodes. Now on to figure how we miscompile tree-vrp.c ... ... probably not before next week though.
[Bug middle-end/61473] register sized memmove not inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61473 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Fri Jul 11 13:42:55 2014 New Revision: 212452 URL: https://gcc.gnu.org/viewcvs?rev=212452root=gccview=rev Log: 2014-07-11 Richard Biener rguent...@suse.de PR middle-end/61473 * builtins.c (fold_builtin_memory_op): Inline memory moves that can be implemented with a single load followed by a single store. (c_strlen): Only warn when only_value is not 2. * gcc.dg/memmove-4.c: New testcase. * gcc.dg/strlenopt-8.c: XFAIL. * gfortran.dg/coarray_lib_realloc_1.f90: Adjust. Added: trunk/gcc/testsuite/gcc.dg/memmove-4.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/strlenopt-8.c trunk/gcc/testsuite/gfortran.dg/coarray_lib_realloc_1.f90
[Bug libstdc++/58962] Pretty printers use obsolete Python syntax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58962 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Fri Jul 11 13:43:07 2014 New Revision: 212453 URL: https://gcc.gnu.org/viewcvs?rev=212453root=gccview=rev Log: 2014-07-11 Samuel Bronson naes...@gmail.com Matthias Klose d...@ubuntu.com PR libstdc++/58962 * python/libstdcxx/v6/printers.py: Port to Python 2+3 (imap): New compat function. (izip): Likewise. (Iterator): New mixin to allow writing iterators in Python 3 style regardless of which version we're running on. [Python3] (long) New compat alias for int. * testsuite/lib/gdb-test.exp: Port to Python 2+3 (print syntax) Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/python/libstdcxx/v6/printers.py trunk/libstdc++-v3/testsuite/lib/gdb-test.exp
[Bug tree-optimization/59611] std::copy performs worse than naive implementation when copying a single known byte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59611 Bug 59611 depends on bug 61473, which changed state. Bug 61473 Summary: register sized memmove not inlined https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61473 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug middle-end/61473] register sized memmove not inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61473 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/61619] Benefits from -ftree-vectorize lost easily when changing unrelated code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61619 Bug 61619 depends on bug 61473, which changed state. Bug 61473 Summary: register sized memmove not inlined https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61473 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/61757] [4.10 Regression] genmodes failure with enable-checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757 --- Comment #12 from Dominique d'Humieres dominiq at lps dot ens.fr --- For the record: Using built-in specs. COLLECT_GCC=gfcp COLLECT_LTO_WRAPPER=/opt/gcc/gcc4.10p-212433/libexec/gcc/x86_64-apple-darwin13.3.0/4.10.0/lto-wrapper Target: x86_64-apple-darwin13.3.0 Configured with: ../p_work/configure --prefix=/opt/gcc/gcc4.10p-212433 --enable-languages=c,c++,lto,fortran,ada,objc,obj-c++ --with-gmp=/opt/mp --with-system-zlib --enable-checking=release --with-isl=/opt/mp --enable-lto --enable-plugin --with-arch=core2 --with-cpu=core2 Thread model: posix gcc version 4.10.0 20140710 (experimental) [trunk revision 212433] (GCC)
[Bug tree-optimization/61757] [4.10 Regression] genmodes failure with enable-checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Target|aarch64-linux, x86, ia64|aarch64-linux, x86, ia64, ||sparc CC||ro at gcc dot gnu.org --- Comment #13 from Rainer Orth ro at gcc dot gnu.org --- Still breaks sparc-sun-solaris2.11 bootstrap, even after Richards patch.
[Bug libstdc++/58962] Pretty printers use obsolete Python syntax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58962 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.10.0 --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org --- The trunk version of the printers should now work with both Python 2 and 3
[Bug tree-optimization/61757] [4.10 Regression] genmodes failure with enable-checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757 --- Comment #14 from Andreas Schwab sch...@linux-m68k.org --- Perhaps the m68k test failure can still provide an easier hint.
[Bug target/61561] arm gcc internal error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61561 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.10.0
[Bug preprocessor/61389] libcpp diagnostics shouldn't talk about ISO C99 for C++ input files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61389 --- Comment #10 from Andreas Schwab schwab at gcc dot gnu.org --- Author: schwab Date: Fri Jul 11 14:49:27 2014 New Revision: 212457 URL: https://gcc.gnu.org/viewcvs?rev=212457root=gccview=rev Log: PR preprocessor/61389 * gcc.dg/cpp/macsyntx.c: Update expected warnings. * gcc.dg/cpp/sysmac1.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/cpp/macsyntx.c trunk/gcc/testsuite/gcc.dg/cpp/sysmac1.c trunk/libcpp/ChangeLog
[Bug tree-optimization/61757] [4.10 Regression] genmodes failure with enable-checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757 Pat Haugen pthaugen at gcc dot gnu.org changed: What|Removed |Added CC||pthaugen at gcc dot gnu.org --- Comment #15 from Pat Haugen pthaugen at gcc dot gnu.org --- CPU2000 benchmark 176.gcc started miscomparing on PowerPC(-m64 only) starting with r212352. Currently trying to narrow down the problem...
[Bug c/61779] New: gcc -Og fails with impossible constraint on legal C code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61779
Bug ID: 61779
Summary: gcc -Og fails with impossible constraint on legal C
code
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zeccav at gmail dot com
Created attachment 33108
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33108action=edit
Same code as in the bug Description
The following code compiles fine without the -Og option.
Compiled with -Og gcc fails.
/* gcc -Og error: impossible constraint in ‘asm’ */
extern unsigned long long __sdt_unsp;
void
f(void)
{
for (;;)
__asm__ (.pushsection .note.stapsdt , \?\ , \note\ \n .4byte
992f-991f , 994f-993f , 3 \n .asciz \%n[_SDT_S1]@%[_SDT_A1]\
\n :: [_SDT_S1] n (((!__extension__ (__builtin_constant_p unsigned long
long) (__typeof (__builtin_choose_expr (((__builtin_classify_type (0) + 3)
-4) == 4, (0), 0U))) __sdt_unsp) ) == 0) )) ? 1 : -1) ), [_SDT_A1] nor
((0)));
}
[Bug c/61779] gcc -Og fails with impossible constraint on legal C code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61779 --- Comment #1 from Vittorio Zecca zeccav at gmail dot com --- I forgot to say that gcc 4.9.0 fails but compiles correctly on gcc 4.8.3.
[Bug fortran/61780] New: [4.8/4.9/4.10 Regression] Wrong code when shifting elements of a multidimensional array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61780 Bug ID: 61780 Summary: [4.8/4.9/4.10 Regression] Wrong code when shifting elements of a multidimensional array Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr CC: pault at gcc dot gnu.org, tkoenig at gcc dot gnu.org From https://groups.google.com/forum/#!topic/comp.lang.fortran/mfS-BB2X-90, the following code gives a wrong result at run time program prgm3 implicit none integer, parameter :: n = 10, k = 3 integer :: i, j integer, dimension(n,n) :: y integer :: res1(n), res2(n) 1 format(10i5) !initialize do i=1,n do j=1,n y(i,j) = n*i + j end do end do res2 = y(k,:) !shift right y(k,4:n) = y(k,3:n-1) y(k,3) = 0 res1 = y(k,:) y(k,:) = res2 y(k,n:4:-1) = y(k,n-1:3:-1) y(k,3) = 0 res2 = y(k,:) print *, res1 print *, res2 if (any(res1 /= res2)) call abort () end program prgm3 Revision r174295 (2011-05-26) is OK, r174338 (2011-05-27) is not, likely r174302 (pr48955).
[Bug fortran/61780] [4.8/4.9/4.10 Regression] Wrong code when shifting elements of a multidimensional array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61780 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2014-07-11 Known to work||4.6.0 Ever confirmed|0 |1 Known to fail||4.10.0, 4.8.3, 4.9.0
[Bug middle-end/61781] New: Overflow of signed integer causing incorrect execution of a program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61781
Bug ID: 61781
Summary: Overflow of signed integer causing incorrect execution
of a program
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: geir at cray dot com
User identified a test case that may indicate an over aggressive optimizer. In
the following test case, compiler with '-O1' will result in correct execution,
while compiling with '-O2' and above results in incorrect behavior.
Here is the short version of the test case. Duplicated bug with 4.8.[012] and
4.9.0 compilers:
$ cat simple.c
#include stdio.h
#include stdlib.h
long myrand( long x )
{
long c = 6824061905351802757L; // prime
long d = 5001297291839117257L; // prime, p - 1 divisible by 4
x = d*x + c;
return( x );
}
int main( int argc, char *argv[] ) {
long x, len;
long count = 0;
x = 1;
len = 1e2;
if( argc 1 ) {
len = atof( argv[1] ) + 0.5;
}
if( argc 2 ) {
x = strtol( argv[2], 0, 0 );
}
printf(len = %ld, seed = 0x%016lx\n, len, x);
for( long i=0; ilen; i++ ) {
x = myrand( i ); // this version breaks gcc
printf(%4ld: 0x%016lx\n, i, x);
count++;
}
printf(Count is %ld\n, count);
return( 0 );
}
$ gcc --version
gcc (GCC) 4.9.0 20140422 (Cray Inc.)
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$
-- Compiling with -O1 works --
$ gcc -O1 -std=c99 simple.c
$ ./a.out | tail
91: 0x0abc128a0365f3f8
92: 0x50243fed93978bc1
93: 0x958c6d5123c9238a
94: 0xdaf49ab4b3fabb53
95: 0x205cc818442c531c
96: 0x65c4f57bd45deae5
97: 0xab2d22df648f82ae
98: 0xf0955042f4c11a77
99: 0x35fd7da684f2b240
Count is 100
$
-- Compiling with -O2 fails --
$ gcc -O2 -std=c99 simple.c
$ ./a.out
len = 100, seed = 0x0001
0: 0x5eb3f025c1c4ff85
Count is 0
$
[Bug middle-end/61781] Overflow of signed integer causing incorrect execution of a program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61781 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Signed integer overflow is an undefined behavior; after that happens, all bets are off. Use -fsanitize=undefined to check your code.
[Bug middle-end/61781] Overflow of signed integer causing incorrect execution of a program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61781
--- Comment #2 from Geir Johansen geir at cray dot com ---
Longer version of the test case, along with notes from the original user. T
I believe you have an overaggressive optimizer. Which I have turned into the
following somewhat block of code (simple-instrumented.c):
/**
Demo for a gcc 4.8.1 bug
Built with: gcc -O3 -std=c99 simple-instrumented.c
*/
#include stdio.h
#include stdlib.h
#ifdef myrand_unsigned
unsigned long myrand (unsigned long x)
#else
long myrand( long x )
#endif
{
#ifdef myrand_constants_ul
unsigned long c = 6824061905351802757UL; // prime
unsigned long d = 5001297291839117257UL; // prime, p - 1 divisible by 4
#else
long c = 6824061905351802757L; // prime
long d = 5001297291839117257L; // prime, p - 1 divisible by 4
#endif
#ifdef printf_sub_start
printf( x-ss: 0x%016ld\n, x);
#endif
#ifdef simpler
x = d*x;
#else
x = d*x + c;
#endif
#ifdef printf_sub_end
printf( x-se: 0x%016ld\n, x);
#endif
return( x );
}
int main( int argc, char *argv[] ) {
#ifdef unsigned_loop
unsigned long x;
#else
long x;
#endif
long len;
long count = 0;
x = 1;
len = 1e2;
if( argc 1 ) {
len = atof( argv[1] ) + 0.5;
}
if( argc 2 ) {
x = strtol( argv[2], 0, 0 );
}
printf(len = %ld, seed = 0x%016lx\n, len, x);
#ifdef unsigned_loop
for(unsigned long i=0; ilen; i++ ) {
#else
for( long i=0; ilen; i++ ) {
#endif
#ifdef myrand_x
x = myrand( x ); // this version seems okay
#else
x = myrand( i ); // this version breaks gcc
#endif
printf(%4ld: 0x%016lx\n, i, x);
count++;
}
printf(Count is %ld\n, count);
return( 0 );
}
And I've been using the following block of code to exercise the
instrumented version of this code (do-it.bash):
#!/bin/bash
gcc -v
opt_gcc=(-fwrapv -fstrict-overflow -Wstrict-overflow=5 -Wall)
opt_code=(simpler myrand_unsigned myrand_constants_ul
printf_sub_start printf_sub_end unsigned_loop myrand_x)
echo gcc options -fwrapv -fstrict-overflow -Wstrict-overflow=5 -Wall
echo code options simpler myrand_unsigned myrand_constants_ul
printf_sub_start printf_sub_end unsigned_loop myrand_x
for ((j=0; j16; j++))
do
optionsx=
if ((j1)); then optionsx=$optionsx ${opt_gcc[0]}; fi
if ((j2)); then optionsx=$optionsx ${opt_gcc[1]}; fi
if ((j4)); then optionsx=$optionsx ${opt_gcc[2]}; fi
if ((j8)); then optionsx=$optionsx ${opt_gcc[3]}; fi
for ((i=0; i128; i++))
do
options=$optionsx
if ((i 1)); then options=$options -D ${opt_code[0]}; fi
if ((i 2)); then options=$options -D ${opt_code[1]}; fi
if ((i 4)); then options=$options -D ${opt_code[2]}; fi
if ((i 8)); then options=$options -D ${opt_code[3]}; fi
if ((i16)); then options=$options -D ${opt_code[4]}; fi
if ((i32)); then options=$options -D ${opt_code[5]}; fi
if ((i64)); then options=$options -D ${opt_code[6]}; fi
printf -v outfile s-i-cc-%02d-%03d-d $j $i
time gcc -O3 -std=c99 $options simple-instrumented.c -o ${outfile}
echo
echo $outfile $options
./$outfile 3 | head -40
done
done
I believe the 'bug' in the code is that the multiply in myrand uses a
signed integer, and when it overflows, it causes all sorts of fun things
to happen in the backend optimizer.
How odd that I can 'fix' that problem, occasionally, by adding a printf
between the entry to the subroutine and multiply. (It does not seem to
matter when it's a 'multiply add'. Apparently, the more complex
operation keeps the optimizer confused, and one printf anywhere causes
it to fall out of that optimization pass.)
I similarly seem to be able to 'defeat' the bug by adding two printf
statements
s-i-cc-00-000
s-i-cc-00-016 -D printf_sub_end
s-i-cc-00-048 -D printf_sub_end -D unsigned_loop
s-i-cc-00-032 -D unsigned_loop
s-i-cc-00-008 -D printf_sub_start
s-i-cc-00-024 -D printf_sub_start -D printf_sub_end
s-i-cc-00-001 -D simpler
s-i-cc-00-017 -D simpler -D printf_sub_end
(It doesn't seem to matter which options are set for flags --- if
-fwrapv is set, then the code runs correctly; if it is not, then the
rest of the options don't seem to do anything different in terms of
making it run or fail.)
... some observations:
... if an unsigned int is passed in, and the variable is printed
before it is used, the bug is averted.
... just passing in an unsigned int value does not 'fix' the
iteration counter.
... the code likes to run more cleanly if I ask to see the variable
with printf before it is used.
and I guess I'm not clear on what the type rules are if I pass in an
unsigned int to
[Bug tree-optimization/61757] [4.10 Regression] genmodes failure with enable-checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757 Michael Matz matz at gcc dot gnu.org changed: What|Removed |Added CC||matz at gcc dot gnu.org --- Comment #16 from Michael Matz matz at gcc dot gnu.org --- At least the miscompilation of tree-vrp.c on x86-64 --enable-checking=release bootstrap is due to the change in copy_prop_visit_phi_node(). The only remaining one (in init_copy_prop) is harmless. The dumps aren't that trivial to compare (many changes downstream the copyprop passes), the diff of the disassembled tree-vrp is shorter, but also unwieldy. So I hope Pat finds something from 176.gcc.
[Bug libfortran/59513] [4.8/4.9/4.10 Regression] Fortran runtime error: Sequential READ or WRITE not allowed after EOF marker, possibly use REWIND or BACKSPACE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59513 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Summary|[4.8/4.9 Regression]|[4.8/4.9/4.10 Regression] |Fortran runtime error: |Fortran runtime error: |Sequential READ or WRITE|Sequential READ or WRITE |not allowed after EOF |not allowed after EOF |marker, possibly use REWIND |marker, possibly use REWIND |or BACKSPACE|or BACKSPACE --- Comment #14 from Dominique d'Humieres dominiq at lps dot ens.fr --- Still present at r212457, updating the summary.
[Bug tree-optimization/61757] [4.10 Regression] genmodes failure with enable-checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757 --- Comment #17 from Michael Matz matz at gcc dot gnu.org --- The testsuite failure on m68k is indeed caused by r212352. In particular this hunk: @@ -1641,8 +1609,7 @@ record_equality (tree x, tree y) long as we canonicalize on one value. */ if (is_gimple_min_invariant (y)) ; - else if (is_gimple_min_invariant (x) - || (loop_depth_of_name (x) = loop_depth_of_name (y))) + else if (is_gimple_min_invariant (x)) prev_x = x, x = y, y = prev_x, prev_x = prev_y; else if (prev_x is_gimple_min_invariant (prev_x)) x = y, y = prev_x, prev_x = prev_y; The test is =, so without loops (both SSA names being at 'depth' 0) the check succeeds always and hence will canonicalize on x (i.e. record x as value of y). The testcase is written so that this is the expected order for the third if to be found trivial. The problem doesn't happen on x86-64 because with -O1 the condition is rewritten into arithmetic on '', so even though the wanted transformation doesn't happen there are only two 'if ' statements, which is what is searched for. Unfortunately this is all harmless and not causing the miscompilations, it's only a missed optimization. FWIW, I think the canonicalization that DOM wants here should be retained in some form (canonicalize to the value that covers a larger area). Possibly by checking if one definition dominates the other
[Bug web/61782] New: always_inline incorrectly documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61782 Bug ID: 61782 Summary: always_inline incorrectly documented Product: gcc Version: 4.8.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: daniel.santos at pobox dot com The current behavior of __attribute__((always_inline)) is to not only inline in -O0, but also to force inlining even when -finline-limit is exceeded. However, the documentation states that it will only cause inlining w/o optimizations: https://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html#index-g_t_0040code_007balways_005finline_007d-function-attribute-2864 We had some discussion about this in LKML some time back and I meant to file a bug report back then, but just remembered. This should be updated to reflect the current behavior of always_inline.
[Bug tree-optimization/61783] New: [4.10 regression] FAIL: gcc.dg/tree-ssa/20030922-2.c scan-tree-dump-times dom1 if 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61783 Bug ID: 61783 Summary: [4.10 regression] FAIL: gcc.dg/tree-ssa/20030922-2.c scan-tree-dump-times dom1 if 2 Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: sch...@linux-m68k.org CC: rguenther at suse dot de Target: m68k-*-* From https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757#17: --- Comment #17 from Michael Matz matz at gcc dot gnu.org --- The testsuite failure on m68k is indeed caused by r212352. In particular this hunk: @@ -1641,8 +1609,7 @@ record_equality (tree x, tree y) long as we canonicalize on one value. */ if (is_gimple_min_invariant (y)) ; - else if (is_gimple_min_invariant (x) - || (loop_depth_of_name (x) = loop_depth_of_name (y))) + else if (is_gimple_min_invariant (x)) prev_x = x, x = y, y = prev_x, prev_x = prev_y; else if (prev_x is_gimple_min_invariant (prev_x)) x = y, y = prev_x, prev_x = prev_y; The test is =, so without loops (both SSA names being at 'depth' 0) the check succeeds always and hence will canonicalize on x (i.e. record x as value of y). The testcase is written so that this is the expected order for the third if to be found trivial. The problem doesn't happen on x86-64 because with -O1 the condition is rewritten into arithmetic on '', so even though the wanted transformation doesn't happen there are only two 'if ' statements, which is what is searched for. Unfortunately this is all harmless and not causing the miscompilations, it's only a missed optimization. FWIW, I think the canonicalization that DOM wants here should be retained in some form (canonicalize to the value that covers a larger area). Possibly by checking if one definition dominates the other
[Bug tree-optimization/61757] [4.10 Regression] genmodes failure with enable-checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757 --- Comment #18 from Andreas Schwab sch...@linux-m68k.org --- The testsuite failure is now bug 61783.
[Bug target/61784] New: Little endian PowerPC does aborts if you use long double constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61784
Bug ID: 61784
Summary: Little endian PowerPC does aborts if you use long
double constants
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: meissner at gcc dot gnu.org
Host: powerpc64le-linux
Target: powerpc64le-linux
Build: powerpc64le-linux
If you use a long double constant in PowerPC little endian, the compiler will
issue a segmentation violation.
-genoa- ./cc1 -O2 -quiet foo.c
foo.c: In function 'add1':
foo.c:1:43: internal compiler error: Segmentation fault
long double add1 (long double a) { return a + 1.0L; }
^
0x10a1c40b crash_signal
/home/meissner/fsf-src/ieee/gcc/toplev.c:337
0x10ec5000 rs6000_emit_move(rtx_def*, rtx_def*, machine_mode)
/home/meissner/fsf-src/ieee/gcc/config/rs6000/rs6000.c:8269
0x10ec5a8f rs6000_emit_move(rtx_def*, rtx_def*, machine_mode)
/home/meissner/fsf-src/ieee/gcc/config/rs6000/rs6000.c:8332
0x10ffd477 gen_movtf(rtx_def*, rtx_def*)
/home/meissner/fsf-src/ieee/gcc/config/rs6000/rs6000.md:9035
0x10400bd7 insn_gen_fn::operator()(rtx_def*, rtx_def*) const
/home/meissner/fsf-src/ieee/gcc/recog.h:308
0x1052db5f emit_move_insn_1(rtx_def*, rtx_def*)
/home/meissner/fsf-src/ieee/gcc/expr.c:3521
0x1052e237 emit_move_insn(rtx_def*, rtx_def*)
/home/meissner/fsf-src/ieee/gcc/expr.c:3615
0x1037f64b emit_library_call_value_1
/home/meissner/fsf-src/ieee/gcc/calls.c:4087
0x103804af emit_library_call_value(rtx_def*, rtx_def*, libcall_type,
machine_mode, int, ...)
/home/meissner/fsf-src/ieee/gcc/calls.c:4348
0x1087a0d3 expand_binop(machine_mode, optab_tag, rtx_def*, rtx_def*, rtx_def*,
int, optab_methods)
/home/meissner/fsf-src/ieee/gcc/optabs.c:2172
0x1054739f expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
/home/meissner/fsf-src/ieee/gcc/expr.c:9215
0x105483ff expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/home/meissner/fsf-src/ieee/gcc/expr.c:9403
0x10540937 expand_expr_real(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/home/meissner/fsf-src/ieee/gcc/expr.c:7922
0x1038a59b expand_expr
/home/meissner/fsf-src/ieee/gcc/expr.h:451
0x1039c8ff expand_return
/home/meissner/fsf-src/ieee/gcc/cfgexpand.c:3157
0x1039cc0b expand_gimple_stmt_1
/home/meissner/fsf-src/ieee/gcc/cfgexpand.c:3232
0x1039d303 expand_gimple_stmt
/home/meissner/fsf-src/ieee/gcc/cfgexpand.c:3354
0x103a5873 expand_gimple_basic_block
/home/meissner/fsf-src/ieee/gcc/cfgexpand.c:5192
0x103a7bdf execute
/home/meissner/fsf-src/ieee/gcc/cfgexpand.c:5799
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.
[Bug c/61739] __builtin_printf optimization conflicts with POSIX semantics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61739 --- Comment #5 from Rich Felker bugdal at aerifal dot cx --- I reopened this, but now that I'm reporting a new symptom that's independent of the original symptom, I'm wondering whether I should file a separate bug report for it, or continue the issue under this original report. Which way is best? Both have the same fix (removing the invalid optimization or replacing it with a valid one), but the user-visible erroneous behaviors are distinct.
[Bug target/61784] Little endian PowerPC does aborts if you use long double constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61784 Michael Meissner meissner at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-07-11 Ever confirmed|0 |1
[Bug target/61784] Little endian PowerPC aborts if you use long double constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61784 Michael Meissner meissner at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |INVALID --- Comment #1 from Michael Meissner meissner at gcc dot gnu.org --- This is not a bug in the trunk. It is a bug only in my IEEE 128-bit branch. Sorry about that.
[Bug c++/59760] use_thunk internal error on default destructor declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59760 --- Comment #5 from gaba gaba at freemail dot hu --- This bug fixed in gcc 4.8.3, please close it.
[Bug fortran/61775] Allocatable array initialized by implied-do loop array constructor gives invalid memory reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61775 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #4 from Mikael Morin mikael at gcc dot gnu.org --- This seems to fix it here (not heavily tested): Index: trans-expr.c === --- trans-expr.c(révision 209169) +++ trans-expr.c(copie de travail) @@ -7932,9 +7932,7 @@ gfc_trans_assignment_1 (gfc_expr * expr1, gfc_expr /* Walk the lhs. */ lss = gfc_walk_expr (expr1); - if (gfc_is_reallocatable_lhs (expr1) - !(expr2-expr_type == EXPR_FUNCTION - expr2-value.function.isym != NULL)) + if (gfc_is_reallocatable_lhs (expr1)) lss-is_alloc_lhs = 1; rss = NULL; if (lss != gfc_ss_terminator)
[Bug c++/61288] valgrind finds problem in build_conditional_expr_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61288 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug c++/53159] Missing narrowing check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53159 --- Comment #6 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Fri Jul 11 21:53:59 2014 New Revision: 212469 URL: https://gcc.gnu.org/viewcvs?rev=212469root=gccview=rev Log: /cp 2014-07-11 Paolo Carlini paolo.carl...@oracle.com PR c++/53159 * call.c (build_user_type_conversion_1): Copy LOOKUP_NO_NARROWING into convflags. * decl.c (check_initializer): Don't call check_narrowing here, set LOOKUP_NO_NARROWING. * typeck2.c (digest_init_r): Likewise. /testsuite 2014-07-11 Paolo Carlini paolo.carl...@oracle.com PR c++/53159 * g++.dg/cpp0x/Wnarrowing1.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/Wnarrowing1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/decl.c trunk/gcc/cp/typeck2.c trunk/gcc/testsuite/ChangeLog
[Bug c++/53159] Missing narrowing check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53159 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot gnu.org Target Milestone|4.9.1 |4.10.0 --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed for 4.10.
[Bug c++/61785] New: Sigsegv with enabled optimize -Os , -O2 in sample_format_size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61785 Bug ID: 61785 Summary: Sigsegv with enabled optimize -Os , -O2 in sample_format_size Product: gcc Version: 4.8.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dirkneukirchen at web dot de Created attachment 33109 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33109action=edit i486-openwrt-linux-g++ -v output I get a SIGSEGV when running the binary compiled with default switches (containing -Os) in qemu. If I compile with -O0 the program is working. GCC 4.6.4 is generating working code with -Os 4.8.0, 4.8.3, 4.9.0 do not work with -Os ; -O0 binaries work Source is from mpd 0.18.11 gcc is used in OpenWrt buildroot to compile it for target arch (x86) I opened a ticket on mpd bugtracker, provided gdb output and was told it's a compiler bug - thats why I opened a ticket here. the mpd bugtracker ticket is: http://bugs.musicpd.org/view.php?id=4024 First time reporter.
[Bug c++/61785] Sigsegv with enabled optimize -Os , -O2 in sample_format_size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61785 --- Comment #1 from dirkneukirchen at web dot de --- Created attachment 33110 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33110action=edit preprocessed file that triggers the bug
[Bug c++/61785] Sigsegv with enabled optimize -Os , -O2 in sample_format_size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61785 --- Comment #2 from dirkneukirchen at web dot de --- an automatic compile log for the whole mpd was generated with additional -v -save-temps options but is quite large (6mb) and probably contains many unneeded information a package buildlog with an additional -g3 options is available at: http://bugs.musicpd.org/file_download.php?file_id=1204type=bug Is the following the needed compiler command lines helpful? : i486-openwrt-linux-uclibc-g++ -DHAVE_CONFIG_H -I. -I./src -pthread -isystem /home/tenchi/prog/git/upstream/openwrt/staging_dir/target-i386_i486_uClibc-0.9.33.2/usr/include/glib-2.0 -isystem /home/tenchi/prog/git/upstream/openwrt/staging_dir/target-i386_i486_uClibc-0.9.33.2/usr/lib/glib-2.0/include -DSYSTEM_CONFIG_FILE_LOCATION='/etc/mpd.conf' -I/home/tenchi/prog/git/upstream/openwrt/staging_dir/target-i386_i486_uClibc-0.9.33.2/usr/include -I/home/tenchi/prog/git/upstream/openwrt/staging_dir/target-i386_i486_uClibc-0.9.33.2/usr/include -I/home/tenchi/prog/git/upstream/openwrt/staging_dir/target-i386_i486_uClibc-0.9.33.2/include -I/home/tenchi/prog/git/upstream/openwrt/staging_dir/toolchain-i386_i486_gcc-4.8.3_uClibc-0.9.33.2/usr/include -I/home/tenchi/prog/git/upstream/openwrt/staging_dir/toolchain-i386_i486_gcc-4.8.3_uClibc-0.9.33.2/include -I/home/tenchi/prog/git/upstream/openwrt/staging_dir/target-i386_i486_uClibc-0.9.33.2/usr/lib/libiconv-stub/include -I/home/tenchi/prog/git/upstream/openwrt/staging_dir/target-i386_i486_uClibc-0.9.33.2/usr/lib/libintl-stub/include -std=gnu++0x -Os -pipe -march=i486 -fno-caller-saves -fhonour-copts -Wno-error=unused-but-set-variable -I/home/tenchi/prog/git/upstream/openwrt/staging_dir/target-i386_i486_uClibc-0.9.33.2/usr/lib/libiconv-stub/include -I/home/tenchi/prog/git/upstream/openwrt/staging_dir/target-i386_i486_uClibc-0.9.33.2/usr/lib/libintl-stub/include -v -save-temps -fvisibility=hidden -fno-threadsafe-statics -fmerge-all-constants -fno-exceptions -fno-rtti -ffast-math -ftree-vectorize -Wall -Wextra -Wmissing-declarations -Wshadow -Wpointer-arith -Wcast-qual -Wwrite-strings -Wsign-compare -MT src/src_mpd-AudioFormat.o -MD -MP -MF src/.deps/src_mpd-AudioFormat.Tpo -c -o src/src_mpd-AudioFormat.o `test -f 'src/AudioFormat.cxx' || echo './'`src/AudioFormat.cxx i486-openwrt-linux-uclibc-g++: warning: -pipe ignored because -save-temps specified Reading specs from /home/tenchi/prog/git/upstream/openwrt/staging_dir/toolchain-i386_i486_gcc-4.8.3_uClibc-0.9.33.2/lib/gcc/i486-openwrt-linux-uclibc/4.8.3/specs COLLECT_GCC=i486-openwrt-linux-uclibc-g++ Target: i486-openwrt-linux-uclibc Configured with: /home/tenchi/prog/git/upstream/openwrt/build_dir/toolchain-i386_i486_gcc-4.8.3_uClibc-0.9.33.2/gcc-4.8.3/configure --with-bugurl=https://dev.openwrt.org/ --with-pkgversion='OpenWrt GCC 4.8.3 r41581' --prefix=/home/tenchi/prog/git/upstream/openwrt/staging_dir/toolchain-i386_i486_gcc-4.8.3_uClibc-0.9.33.2 --build=i586-linux-gnu --host=i586-linux-gnu --target=i486-openwrt-linux-uclibc --with-gnu-ld --enable-target-optspace --disable-libgomp --disable-libmudflap --disable-multilib --disable-nls --with-host-libstdcxx=-lstdc++ --with-gmp=/home/tenchi/prog/git/upstream/openwrt/staging_dir/host --with-mpfr=/home/tenchi/prog/git/upstream/openwrt/staging_dir/host --disable-decimal-float --with-mpc=/home/tenchi/prog/git/upstream/openwrt/staging_dir/host --disable-libssp --disable-__cxa_atexit --with-headers=/home/tenchi/prog/git/upstream/openwrt/staging_dir/toolchain-i386_i486_gcc-4.8.3_uClibc-0.9.33.2/include --enable-languages=c,c++ --enable-shared --enable-threads --with-slibdir=/home/tenchi/prog/git/upstream/openwrt/staging_dir/toolchain-i386_i486_gcc-4.8.3_uClibc-0.9.33.2/lib Thread model: posix gcc version 4.8.3 (OpenWrt GCC 4.8.3 r41581) COLLECT_GCC_OPTIONS='-D' 'HAVE_CONFIG_H' '-I' '.' '-I' './src' '-pthread' '-isystem' '/home/tenchi/prog/git/upstream/openwrt/staging_dir/target-i386_i486_uClibc-0.9.33.2/usr/include/glib-2.0' '-isystem' '/home/tenchi/prog/git/upstream/openwrt/staging_dir/target-i386_i486_uClibc-0.9.33.2/usr/lib/glib-2.0/include' '-D' 'SYSTEM_CONFIG_FILE_LOCATION=/etc/mpd.conf' '-I' '/home/tenchi/prog/git/upstream/openwrt/staging_dir/target-i386_i486_uClibc-0.9.33.2/usr/include' '-I' '/home/tenchi/prog/git/upstream/openwrt/staging_dir/target-i386_i486_uClibc-0.9.33.2/usr/include' '-I' '/home/tenchi/prog/git/upstream/openwrt/staging_dir/target-i386_i486_uClibc-0.9.33.2/include' '-I' '/home/tenchi/prog/git/upstream/openwrt/staging_dir/toolchain-i386_i486_gcc-4.8.3_uClibc-0.9.33.2/usr/include' '-I' '/home/tenchi/prog/git/upstream/openwrt/staging_dir/toolchain-i386_i486_gcc-4.8.3_uClibc-0.9.33.2/include' '-I' '/home/tenchi/prog/git/upstream/openwrt/staging_dir/target-i386_i486_uClibc-0.9.33.2/usr/lib/libiconv-stub/include' '-I' '/home/tenchi/prog/git/upstream/openwrt/staging_dir/target-i386_i486_uClibc-0.9.33.2/usr/lib/libintl-stub/include' '-std=gnu++11' '-Os' '-pipe' '-march=i486' '-fno-caller-saves'
[Bug tree-optimization/61757] [4.10 Regression] genmodes failure with enable-checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757
--- Comment #19 from Pat Haugen pthaugen at gcc dot gnu.org ---
Tracked down the problem in 176.gcc to a difference in the generated code for
benchmark source toplev.c:exact_log2_wide(). Following compiled with -O3
-mcpu=power7.
int exact_log2_wide (unsigned int x)
{
register int log = 0;
if (x == 0 || x != (x -x))
return -1;
while ((x = 1) != 0)
log++;
return log;
}
r212351:
neg 9,3
and 9,9,3
cmplw 7,9,3
bne 7,.L5
rldicl. 9,9,63,33
li 3,0
beq 0,.L6
r212352:
neg 10,3
and 10,10,3
cmplw 7,10,3
bne 7,.L5
srdi. 9,3,1
li 3,0
beq 0,.L6
r212351 is clearing the high word of the 64-bit register on the initial shift
right of 'x', whereas r212352 just starts shifting the whole 64-bit reg. The
reason this causes problems is that the callers are calling with an integer
arg:
#define exact_log2(N) exact_log2_wide ((HOST_WIDE_INT) (N))
So in the case where MIN_INT32 is passed (sign extended), the upper 32 bits are
'1' so r212352 returns a value of 63 whereas prior revisions returned a value
of 31.
Not sure if this is more of a benchmark source error, but figured I'd post my
findings in case it helps with the general problem.
[Bug c++/57644] [C++1y] Cannot bind bitfield to lvalue reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57644 --- Comment #4 from emsr at gcc dot gnu.org --- Author: emsr Date: Sat Jul 12 01:41:30 2014 New Revision: 212477 URL: https://gcc.gnu.org/viewcvs?rev=212477root=gccview=rev Log: 2014-07-11 Edward Smith-Rowland 3dw...@verizon.net PR c++/57644 - [C++1y] Cannot bind bitfield to lvalue reference g++.dg/cpp0x/pr57644.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp1y/pr57644.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/57644] [C++1y] Cannot bind bitfield to lvalue reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57644 emsr at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||emsr at gcc dot gnu.org Resolution|--- |FIXED --- Comment #5 from emsr at gcc dot gnu.org --- Fixed on trunk...
[Bug c++/20416] Incorrect lifetime for temporary with static const reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20416
shri314 at yahoo dot com shri314 at yahoo dot com changed:
What|Removed |Added
CC||shri314 at yahoo dot com
--- Comment #7 from shri314 at yahoo dot com shri314 at yahoo dot com ---
Issue exists in 4.1.2 as well. And it can cause heap corruption from seemingly
mundane and regular pieces of code:
snip
#include string
std::string::size_type foo() {
const static std::string bad = r=;
return bad.size();
}
int main() {
foo();
foo();
}
/snip
valgrind shows invalid free
-
ERROR SUMMARY: 5 errors from 3 contexts (suppressed: 18 from 9)
1 errors in context 1 of 3:
Invalid free() / delete / delete[]
at 0x40054B4: operator delete(void*) (vg_replace_malloc.c:346)
by 0x4095C9C: std::string::_Rep::_M_destroy(std::allocatorchar const)
(in /usr/lib/libstdc++.so.6.0.8)
by 0x804871B: foo() (basic_string.h:233)
by 0x804875A: main (A.cpp:13)
Address 0x410e028 is 0 bytes inside a block of size 15 free'd
at 0x40054B4: operator delete(void*) (vg_replace_malloc.c:346)
by 0x4095C9C: std::string::_Rep::_M_destroy(std::allocatorchar const)
(in /usr/lib/libstdc++.so.6.0.8)
by 0x804871B: foo() (basic_string.h:233)
[Bug lto/61786] New: wrong code by LTO on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61786
Bug ID: 61786
Summary: wrong code by LTO on x86_64-linux-gnu
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The current gcc trunk miscompiles the following code when using LTO on
x86_64-linux-gnu in both 32-bit and 64-bit modes.
This is a regression from 4.9.x.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.10.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 4.10.0 20140711 (experimental) [trunk revision 212447] (GCC)
$
$ gcc-trunk -O0 -c fn1.c
$ gcc-trunk -O0 -c main.c
$ gcc-trunk -O1 fn1.o main.o
$ a.out
$
$ gcc-4.9 -flto -O0 -c fn1.c
$ gcc-4.9 -flto -O0 -c main.c
$ gcc-4.9 -flto -O1 fn1.o main.o
$ a.out
$
$ gcc-trunk -flto -O0 -c fn1.c
$ gcc-trunk -flto -O0 -c main.c
$ gcc-trunk -flto -O1 fn1.o main.o
$ a.out
^C
$
$ cat fn1.c
int a, *c = a, d;
char b = 1;
void
fn1 (void)
{
d = 1;
lbl:
if (b == d)
{
d = *c;
if (b)
goto lbl;
}
}
int
fn2 (void)
{
fn1 ();
return 0;
}
$ cat main.c
extern int fn2 (void);
int
main ()
{
fn2 ();
return 0;
}
$
[Bug lto/61786] wrong code by LTO on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61786
--- Comment #1 from Zhendong Su su at cs dot ucdavis.edu ---
Not sure whether it is due to the same root cause, but the combined code is
also miscompiled at (only) -O2 by the current trunk.
Interestingly, -flto seems to make the miscompilation disappear.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.10.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 4.10.0 20140711 (experimental) [trunk revision 212447] (GCC)
$
$ gcc-trunk -Os small.c; a.out
$ gcc-trunk -O3 small.c; a.out
$ gcc-4.9 -O2 small.c; a.out
$ gcc-trunk -flto -O2 small.c; a.out
$
$ gcc-trunk -O2 small.c
$ a.out
^C
$
$
-
int a, *c = a, d;
char b = 1;
void
fn1 ()
{
d = 1;
lbl:
if (b == d)
{
d = *c;
if (b)
goto lbl;
}
}
int
fn2 ()
{
fn1 ();
return 0;
}
int
main ()
{
fn2 ();
return 0;
}
[Bug tree-optimization/61787] New: wrong code at -Os on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61787
Bug ID: 61787
Summary: wrong code at -Os on x86_64-linux-gnu
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The current gcc trunk miscompiles the following code on x86_64-linux at (only)
-Os in both 32-bit and 64-bit modes.
This is a regression from 4.9.x.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.10.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 4.10.0 20140711 (experimental) [trunk revision 212447] (GCC)
$
$ gcc-trunk -O1 small.c; a.out
$ gcc-trunk -O2 small.c; a.out
$ gcc-4.9 -Os small.c; a.out
$
$ gcc-trunk -Os small.c; a.out
Aborted (core dumped)
$
-
unsigned int a = 1;
int
fn1 ()
{
char b;
for (;;)
{
for (b = 0; b 5; b++)
if (!a - (unsigned int) b)
return 0;
a = 0;
}
}
int
main ()
{
fn1 ();
if (a != 1)
__builtin_abort ();
return 0;
}
[Bug middle-end/61558] [4.10 Regression] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61558 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Priority|P3 |P1
