[Bug testsuite/70699] Add dot-file scan to pr70161.c test-case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70699 --- Comment #2 from vries at gcc dot gnu.org --- pinged: https://gcc.gnu.org/ml/gcc-patches/2016-04/msg00783.html
[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64883 --- Comment #40 from Iain Sandoe --- Created attachment 38295 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38295&action=edit Further tweak for Darwin10 Sorry, this one slipped thorough the cracks, and I guess we're no longer in the "apply as obvious" state. It's hardly critical (but also pretty safe). Dominique, can we double-check it works as expected?
[Bug tree-optimization/70701] New: incomplete value numbering when memcpy-ing from array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70701 Bug ID: 70701 Summary: incomplete value numbering when memcpy-ing from array Product: gcc Version: 6.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: glisse at gcc dot gnu.org Target Milestone: --- Looking at PR58483 (seems more relevant than PR62156), I tried this simple testcase: int a[]={1,2,3}; int f(){ // a[0]=42; int*b=__builtin_malloc(12); __builtin_memcpy(b,a,12); return b[0]; } Compiling with -O3 -fdisable-tree-forwprop1 -fdisable-tree-forwprop2 -fdisable-tree-forwprop3 (otherwise forwprop turns memcpy into a MEM assignment), we fail to optimize b[0] to 1. We do go through the memcpy path in vn_reference_lookup_3 and that part seems to work fine, but then that's it, we don't grab the value. If I add a statement a[0]=42; at the beginning of the function, then we do get that value in FRE1.
[Bug sanitizer/70624] [6/7 Regression] Several hundred asan failures with 6.0 on x86_64-apple-darwin10.8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70624 Iain Sandoe changed: What|Removed |Added CC||iains at gcc dot gnu.org --- Comment #9 from Iain Sandoe --- (In reply to Dominique d'Humieres from comment #8) > This is fixed on x86_64-apple-darwin10 without regression on > x86_64-apple-darwin15 by the following patch > > --- ../_clean/libsanitizer/asan/asan_mac.cc 2015-11-23 10:17:05.0 > +0100 > +++ libsanitizer/asan/asan_mac.cc 2016-04-15 13:22:01.0 +0200 > @@ -97,10 +97,14 @@ void DisableReexec() { >reexec_disabled = true; > } > > -extern "C" double dyldVersionNumber; > +extern "C" SANITIZER_WEAK_ATTRIBUTE double dyldVersionNumber; > static const double kMinDyldVersionWithAutoInterposition = 360.0; > > bool DyldNeedsEnvVariable() { > + // Although sanitizer support was added to LLVM on Darwin 10.7+, GCC users > + // still may want use them on older systems. On older Darwin platforms, > dyld > + // doesn't export dyldVersionNumber symbol and we simply can return true. > + if (!&dyldVersionNumber) return true; >// If running on OS X 10.11+ or iOS 9.0+, dyld will interpose even if >// DYLD_INSERT_LIBRARIES is not set. However, checking OS version via >// GetMacosVersion() doesn't work for the simulator. Let's instead check This looks good to (and works for) me; please can we ask for this to be committed "upstream" and then imported? BTW, there _are_ folks using both GCC and LLVM on Darwin10 for "day job" stuff, so it is still very much of interest.
[Bug fortran/65795] Segfault (invalid write) for ALLOCATE statement involving COARRAYS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65795 vehre at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #7 from vehre at gcc dot gnu.org --- No complaints so far, closing.
[Bug fortran/66911] ICE on allocate character with source as a derived type component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66911 vehre at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #10 from vehre at gcc dot gnu.org --- No complaints so far, closing.
[Bug fortran/67538] ICE with invalid source allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67538 vehre at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #7 from vehre at gcc dot gnu.org --- No complaints so far, closing.
[Bug c++/70702] New: Build failure of ARM cross compiler under Cygwin - libc_name_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70702 Bug ID: 70702 Summary: Build failure of ARM cross compiler under Cygwin - libc_name_p Product: gcc Version: 5.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: olivier at gautherot dot net Target Milestone: --- Created attachment 38296 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38296&action=edit Build script for reference I tried to build an ARM cross compiler under Cygwin64 and got an error (symbol not found) on libc_name_p. After some investigation, I tracked the root cause down to the files gcc/cp/cfns.{h,gperf}. I suggest the following fix: Replace "const char * libc_name_p (const char *, unsigned int);" with "static const char * libc_name_p (const char *, unsigned int);" By adding the "static" keyword, we ensure that the function is properly inlined. There are 3 occurrences in cfns.h and cfns.gperf. I attached my build scripts for reference. Note: The same build scripts worked fine under Linux (Ubuntu, Centos) and FreeBSD, with various versions of GCC and Clang/FreeBSD. The reason why GCC on Cygwin misbehaved is still unclear.
[Bug c++/70702] Build failure of ARM cross compiler under Cygwin - libc_name_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70702 --- Comment #1 from Olivier Gautherot --- Additional note: by adding the static keyword, I got the following error: In file included from ../../gcc/cp/except.c:1023:0: cfns.gperf: In function 'const char* libc_name_p(const char*, unsigned int)': cfns.gperf:101:1: error: 'const char* libc_name_p(const char*, unsigned int)' rdeclared inline with 'gnu_inline' attribute cfns.gperf:26:21: note: 'const char* libc_name_p(const char*, unsigned int)' prviously declared here cfns.gperf: At global scope: cfns.gperf:26:21: warning: inline function 'const char* libc_name_p(const char* unsigned int)' used but never defined Makefile:1065: recipe for target 'cp/except.o' failed make: *** [cp/except.o] Error 1 It was fixed by declaring consistently the prototype in the 3 occurences as: #ifdef __GNUC__ __inline #ifdef __GNUC_STDC_INLINE__ __attribute__ ((__gnu_inline__)) #endif #endif static const char * libc_name_p (const char *, unsigned int);
[Bug middle-end/70703] New: Regression in register usage on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70703 Bug ID: 70703 Summary: Regression in register usage on x86 Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: vda.linux at googlemail dot com Target Milestone: --- $ cat bad.c unsigned ud_x_641_mul(unsigned x) { /* optimized version of x / 641 */ return ((unsigned long long)x * 0x663d81) >> 32; } With gcc from current svn: $ gcc -m32 -fomit-frame-pointer -O2 bad.c -S && cat bad.s ... ud_x_641_mul: .cfi_startproc movl$6700417, %ecx movl%ecx, %eax mull4(%esp) movl%edx, %ecx movl%ecx, %eax ret Same result with -Os. Note two pointless mov insns. gcc 5.3.1 is "better", it adds only one unnecessary insn: ud_x_641_mul: .cfi_startproc movl$6700417, %ecx movl%ecx, %eax mull4(%esp) movl%edx, %eax ret gcc 4.4.x and 4.7.2 were generating this code, which looks optimal: ud_x_641_mul: .cfi_startproc movl$6700417, %eax mull4(%esp) movl%edx, %eax ret I did not test other versions of gcc yet.
[Bug target/30354] -Os doesn't optimize a/CONST even if it saves size.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30354 --- Comment #17 from Denis Vlasenko --- Any chance of this being finally done? I proposed a simple, working patch in 2007, it's 2016 now and all these years users of -Os suffer from slow divisions in important cases usch as "signed_int / 16" and "unsigned_int / 10". I understand your desire to do it "better", to make gcc count size of div/idiv more accurately, without having to lie to it in the insn size table. But with you guys constantly distracted by other, more important issues, what happened here is that _nothing_ was done... I retested the patch with current svn (the future 7.0.0), using test program with 15000 divisions from comment 3: Bumping division cost up to 8 is no longer enough, this only makes gcc to be better towards some (not all) 2^N divisors. Bumping div cost to 9..12 helps with most of remaining 2^N divisor cases, and for two exceptional cases of x / 641 and x / 6700417. Only bumping div cost to 13, namely, changing div costs as follows: const struct processor_costs ix86_size_cost = {/* costs for tuning for size */ ... {COSTS_N_BYTES (13), /* cost of a divide/mod for QI */ COSTS_N_BYTES (13), /* HI */ COSTS_N_BYTES (13), /* SI */ COSTS_N_BYTES (13), /* DI */ COSTS_N_BYTES (15)}, /* other */ makes it work as it used to in 4.4.x days: out of 15000 cases in t.c, 975 cases are optimized so that they don't use "div" anymore. This should have made it smaller too... but did not, because meanwhile gcc has regressed in another area. Now it inserts superfluous register moves. See bug 70703 which I just filed. Essentially, instead of movl$6700417, %eax mull4(%esp) movl%edx, %eax ret gcc generates: movl$6700417, %ecx movl%ecx, %eax mull4(%esp) movl%edx, %ecx movl%ecx, %eax ret Sizes of compiled testcases (objN denotes cost of "div", A...D correspond to costs of 10..13): textdata bss dec hex filename 242787 0 0 242787 3b463 gcc.obj3/divmod-7.0.0-Os.o 242813 0 0 242813 3b47d gcc.obj8/divmod-7.0.0-Os.o 242838 0 0 242838 3b496 gcc.obj9/divmod-7.0.0-Os.o 242844 0 0 242844 3b49c gcc.objA/divmod-7.0.0-Os.o 242844 0 0 242844 3b49c gcc.objB/divmod-7.0.0-Os.o 242844 0 0 242844 3b49c gcc.objC/divmod-7.0.0-Os.o 247573 0 0 247573 3c715 gcc.objD/divmod-7.0.0-Os.o So. Any chance of this patch being accepted sometime before 2100? ;)
[Bug target/30354] -Os doesn't optimize a/CONST even if it saves size.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30354 --- Comment #18 from Denis Vlasenko --- Created attachment 38297 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38297&action=edit Comparison of generated code with 7.0.0.svn on i86 With div cost of 3: : - 0: 8b 44 24 04 mov0x4(%esp),%eax - 4: b9 64 00 00 00 mov$0x64,%ecx - 9: 31 d2 xor%edx,%edx - b: f7 f1 div%ecx - d: c3 ret With div cost of 13: + 0: b9 1f 85 eb 51 mov$0x51eb851f,%ecx + 5: 89 c8 mov%ecx,%eax + 7: f7 64 24 04 mull 0x4(%esp) + b: 89 d1 mov%edx,%ecx + d: 89 c8 mov%ecx,%eax + f: c1 e8 05shr$0x5,%eax + 12: c3 ret
[Bug c++/70018] [4.9/5/6/7 Regression] Possible issue around IPO and C++ comdats discovered as pure/const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70018 --- Comment #15 from Jan Hubicka --- Author: hubicka Date: Sun Apr 17 16:04:05 2016 New Revision: 235081 URL: https://gcc.gnu.org/viewcvs?rev=235081&root=gcc&view=rev Log: PR ipa/70018 * cgraph.h (cgraph_node::set_const_flag, cgraph_node::set_pure_flag): Update prototype to return bool; update comment. * cgraph.c (cgraph_node::call_for_symbol_thunks_and_aliases): Thunks of interposable symbol are interposable, too. (cgraph_set_const_flag_1): Rename to ... (set_const_flag_1): ... this one; change to self recursive function instead of call_for_symbol_thunks_and_aliases. Handle correctly clearnig the flag in all variants and also virtual thunks of const functions are pure; track if any change was done. (cgraph_node::set_const_flag): Update. (struct set_pure_flag_info): New struct. (cgraph_set_pure_flag_1): Rename to ... (set_pure_flag_1): ... this one; take set_pure_flag_info parameter rather than pointer encoded flags; track if any changes was done; handle correctly clearning flag and setting flag of aliases already declared const. (cgraph_node::set_pure_flag): Update. (cgraph_node::set_nothrow_flag): Handle correctly clearning the flag. Modified: trunk/gcc/ChangeLog trunk/gcc/cgraph.c trunk/gcc/cgraph.h
[Bug bootstrap/70704] New: [6 Regressions] AIX bootstrap comparison failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70704 Bug ID: 70704 Summary: [6 Regressions] AIX bootstrap comparison failure Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: dje at gcc dot gnu.org Target Milestone: --- GCC 6.0 RC fails bootstrap on AIX due to comparison failure of all object files for --enable-checking=release. This appears to be an unstable sort issue.
[Bug bootstrap/70704] [6 Regressions] AIX bootstrap comparison failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70704 David Edelsohn changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-04-17 Ever confirmed|0 |1 --- Comment #1 from David Edelsohn --- Cnofirmed.
[Bug fortran/70705] New: Associate construct with array section causes ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70705 Bug ID: 70705 Summary: Associate construct with array section causes ICE Product: gcc Version: 5.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: townsend at astro dot wisc.edu Target Milestone: --- Created attachment 38298 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38298&action=edit Example program In the example program attached, compilation (gfortran -o ice ice.f90) causes the following ICE: ice.f90:16:0: x = 0. 1 internal compiler error: in gfc_get_element_type, at fortran/trans-types.c:1201 ice.f90:16:0: internal compiler error: Abort trap: 6 gfortran.exec: internal compiler error: Abort trap: 6 (program f951) cheers, Rich
[Bug fortran/49636] [F03] ASSOCIATE construct confused with slightly complicated case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49636 Dominique d'Humieres changed: What|Removed |Added CC||townsend at astro dot wisc.edu --- Comment #9 from Dominique d'Humieres --- *** Bug 70705 has been marked as a duplicate of this bug. ***
[Bug fortran/70705] Associate construct with array section causes ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70705 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Dominique d'Humieres --- It looks like a duplicate of pr49636. *** This bug has been marked as a duplicate of bug 49636 ***
[Bug bootstrap/70706] New: [7 Regression] r235082 caused bootstrap failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70706 Bug ID: 70706 Summary: [7 Regression] r235082 caused bootstrap failure Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: hubicka at ucw dot cz Target Milestone: --- r235082 caused: libbackend.a(graphite.o): In function `graphite_finalize(bool)': /export/gnu/import/git/gcc-test-profiled/bld/gcc/../../src-trunk/gcc/graphite.c:259: undefined reference to `tree_estimate_probability()' collect2: error: ld returned 1 exit status ../../src-trunk/gcc/lto/Make-lang.in:71: recipe for target 'lto1' failed make[6]: *** [lto1] Error 1 when GCC is configured with --prefix=/usr/7.0.0 --enable-clocale=gnu --with-system-zlib --enable-shared --with-demangler-in-ld --enable-libmpx --with-build-config=bootstrap-lto --disable-werror --with-fpmath=sse --enable-languages=c,c++,fortran,java,lto,objc and built with # make -j8 profiledbootstrap
[Bug testsuite/70150] Additonal test failures with --enable-default-pie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70150 --- Comment #16 from H.J. Lu --- (In reply to psturm from comment #15) > Tested with hjl/pr70150 branch and no unexpected errors using > --enable-default-pie. > > However, when testing the same branch with both --enable-default-pie and > --enable-default-ssp, a couple new failures did show up (in addition to the > 11 expected failures): > > FAIL: gcc.target/i386/cleanup-1.c execution test > FAIL: gcc.target/i386/cleanup-2.c execution test > > I am not sure whether this is relevant or not? Do they fail with only --enable-default-ssp?
[Bug bootstrap/70706] [7 Regression] r235082 caused bootstrap failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70706 --- Comment #1 from Jan Hubicka --- Author: hubicka Date: Sun Apr 17 18:04:51 2016 New Revision: 235085 URL: https://gcc.gnu.org/viewcvs?rev=235085&root=gcc&view=rev Log: PR bootstrap/70706 * graphite.c (graphite_finalize): Update call to tree_estimate_probability. Modified: trunk/gcc/ChangeLog trunk/gcc/graphite.c
[Bug bootstrap/70706] [7 Regression] r235082 caused bootstrap failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70706 --- Comment #2 from Jan Hubicka --- > libbackend.a(graphite.o): In function `graphite_finalize(bool)': > /export/gnu/import/git/gcc-test-profiled/bld/gcc/../../src-trunk/gcc/graphite.c:259: > undefined reference to `tree_estimate_probability()' > collect2: error: ld returned 1 exit status > ../../src-trunk/gcc/lto/Make-lang.in:71: recipe for target 'lto1' failed > make[6]: *** [lto1] Error 1 I have comitted the following as obvious. It is not clear to me what graphite is trying to reach here and it will definitly leat to random results with profile feedback (we will likely end up with guessed profile but non-zero counts) but we can deal with that incrementally. PR bootstrap/70706 * graphite.c (graphite_finalize): Update call to tree_estimate_probability. Index: graphite.c === --- graphite.c (revision 235064) +++ graphite.c (working copy) @@ -256,7 +256,7 @@ graphite_finalize (bool need_cfg_cleanup cleanup_tree_cfg (); profile_status_for_fn (cfun) = PROFILE_ABSENT; release_recorded_exits (cfun); - tree_estimate_probability (); + tree_estimate_probability (false); } free_original_copy_tables ();
[Bug bootstrap/70706] [7 Regression] r235082 caused bootstrap failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70706 --- Comment #3 from graham.stott at btinternet dot com --- still fails predict.h needs updating prototype also Original message From: "hubicka at gcc dot gnu.org" Date: 17/04/2016 19:05 (GMT+00:00) To: gcc-bugs@gcc.gnu.org Subject: [Bug bootstrap/70706] [7 Regression] r235082 caused bootstrap failure https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70706 --- Comment #1 from Jan Hubicka --- Author: hubicka Date: Sun Apr 17 18:04:51 2016 New Revision: 235085 URL: https://gcc.gnu.org/viewcvs?rev=235085&root=gcc&view=rev Log: PR bootstrap/70706 * graphite.c (graphite_finalize): Update call to tree_estimate_probability. Modified: trunk/gcc/ChangeLog trunk/gcc/graphite.c
[Bug bootstrap/70706] [7 Regression] r235082 caused bootstrap failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70706 --- Comment #4 from Jan Hubicka --- Author: hubicka Date: Sun Apr 17 18:30:21 2016 New Revision: 235086 URL: https://gcc.gnu.org/viewcvs?rev=235086&root=gcc&view=rev Log: PR bootstrap/70706 * predict.h (tree_estimate_probability): Update prototype. Modified: trunk/gcc/ChangeLog trunk/gcc/predict.h
[Bug c++/27557] OpenMP threadprivate directive does not work with non-POD types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27557 Sameer Sheorey changed: What|Removed |Added CC||ssameer at gmail dot com --- Comment #17 from Sameer Sheorey --- The second fragment still fails in gcc 5.3.1 (OpenSuse 13.2). I noticed that the C++11 version succeeds: struct A { A() {} }; thread_local A a; Is it possible to migrate this to the OpenMP implementation as well?
[Bug libgcc/68082] issue on 64 bit shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68082 --- Comment #5 from angelo --- Any news ? Trying also --with-arch=cf breaks the compilation. So i can't have in any way valid libgcc code i.e. for m5307.
[Bug libgcc/68467] libgcc, compilation for target m68k-linux breaks in linux_atomic.c, #define COMMA ,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68467 --- Comment #2 from angelo --- Well the final error is : /home/angelo/archivio/aziende/sysam/buildall/gcc-5.2.0/libgcc/config/m68k/linux-atomic.c:198:13: internal compiler error: in emit_library_call_value_1, at calls.c:4401 return (__sync_val_compare_and_swap_##WIDTH (ptr, oldval, newval) \ ^ /home/angelo/archivio/aziende/sysam/buildall/gcc-5.2.0/libgcc/config/m68k/linux-atomic.c:203:1: note: in expansion of macro 'SUBWORD_BOOL_CAS' SUBWORD_BOOL_CAS (unsigned char, 1) I tried also gcc 5.3.0, same error using --with-arch=cf. Seems like m68k branch is not considered at all.
[Bug tree-optimization/70701] incomplete value numbering when memcpy-ing from array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70701 --- Comment #1 from Marc Glisse --- Er, sorry, a "const" disappeared when I posted. const int a[]={1,2,3}; int f(){ int*b=__builtin_malloc(12); __builtin_memcpy(b,a,12); return b[0]; } this fails to optimize (without forwprop). int a[]={1,2,3}; int f(){ a[0]=42; int*b=__builtin_malloc(12); __builtin_memcpy(b,a,12); return b[0]; } this is optimized.
[Bug c++/70702] Build failure of ARM cross compiler under Cygwin - libc_name_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70702 --- Comment #2 from Olivier Gautherot --- Last correction: the build under FreeBSD uses GCC 5.3 and requires the same fix to build.
[Bug bootstrap/70704] [6 Regressions] AIX bootstrap comparison failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70704 --- Comment #3 from David Edelsohn --- Created attachment 38300 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38300&action=edit Stage3 sbitmap.s
[Bug bootstrap/70704] [6 Regressions] AIX bootstrap comparison failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70704 --- Comment #2 from David Edelsohn --- Created attachment 38299 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38299&action=edit Stage2 sbitmap.s
[Bug bootstrap/70704] [6 Regressions] AIX bootstrap comparison failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70704 --- Comment #4 from David Edelsohn --- sbitmap.s was one of the smaller files. All of the debugging information seems to be present, but emitted in a different order in the stage2 versus stage3.
[Bug c/70707] New: INT_MAX used before it is defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70707 Bug ID: 70707 Summary: INT_MAX used before it is defined Product: gcc Version: 5.3.0 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dethbomb at hotmail dot com Target Milestone: --- Im a complete newb to linux and gcc so please forgive if this is not the correct way to do things. Or if this is not actually wrong then please ignore. I saw what appeared to me to be incorrect C code while browsing "limits.h". The following 2 cpp lines. # define INT_MIN (-INT_MAX - 1) # define INT_MAX 2147483647 INT_MAX is used before it is defined. The preprocessor seems to accept this in gcc because INT_MAX is defined immediately afterwards.But if a different preprocessor would be used this could cause problems? printf("%i\n",INT_MIN); does give the correct value. But im not sure if its because it may be defined elsewhere in my source code thru some other header file. regards, Lewis
[Bug libfortran/70684] [4.9/5/6/7 Regression] incorrect reading of values from file on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70684 --- Comment #6 from Jerry DeLisle --- The regression occurred at r200238, which was a fix for PR57633. I am working on a fix.
[Bug sanitizer/70683] [7 Regression] -fcompare-debug bug with -fsanitize=address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70683 Jakub Jelinek changed: What|Removed |Added Summary|[6/7 Regression]|[7 Regression] |-fcompare-debug bug with|-fcompare-debug bug with |-fsanitize=address |-fsanitize=address --- Comment #2 from Jakub Jelinek --- In gcc 6.x this is masked off by not making the constexpr fn table deletable.
[Bug sanitizer/70683] [7 Regression] -fcompare-debug bug with -fsanitize=address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70683 Jakub Jelinek changed: What|Removed |Added Target Milestone|6.0 |7.0
[Bug bootstrap/70704] [6 Regressions] AIX bootstrap comparison failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70704 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |6.0 --- Comment #5 from Jakub Jelinek --- Strange, I thought the default bootstrap is to build stage2 without debug info, while you have stabs in both files. Have you looked at where the differences start first (build both the stage2 and stage3 with -fdump-tree-all-nouid -fdump-rtl-all-nouid --param min-nondebug-insn-uid=1 ? Are the stage2/stage3 sbitmap.c sources built with the same options? Do you know which sort is unstable, or is that just a guess?
[Bug testsuite/70150] Additonal test failures with --enable-default-pie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70150 --- Comment #17 from psturm at computervoice dot com --- Yes, they do appear when only using --enable-default-ssp, so I don't think they are relevant.
[Bug testsuite/70150] Additonal test failures with --enable-default-pie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70150 --- Comment #18 from H.J. Lu --- (In reply to psturm from comment #17) > Yes, they do appear when only using --enable-default-ssp, so I don't think > they are relevant. I suggest you open a new bug report if you haven't done so.
[Bug testsuite/70230] 11 test regressions when building GCC 6 with --enable-default-ssp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70230 --- Comment #2 from psturm at computervoice dot com --- 2 new failures appeared when testing with only --enable-default-ssp using the hjl/pr70150 branch: > FAIL: gcc.target/i386/cleanup-1.c execution test > FAIL: gcc.target/i386/cleanup-2.c execution test Are these also to be expected or is it something more?
[Bug testsuite/70150] Additonal test failures with --enable-default-pie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70150 --- Comment #19 from psturm at computervoice dot com --- H.J, Done. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70230 On a separate topic, do you know an Intel colleague named Kirill Shutemov? I am having a problem with a kernel warning about a pmd_set_huge failure and an ACPI warning on my Xeon D-1540 development system when I load the ixgbe driver. The driver guys told me to post on linux-mm and I did, but no reply just yet. It seems Kirill Shumetov is active in the kernel memory management and this is an issue manifesting on an Intel system (both CPU and 10g ethernet). If not him, do you know anyone else I can contact about this? Thanks, Paul - Original Message - From: "hjl.tools at gmail dot com" To: "psturm" Sent: Sunday, April 17, 2016 6:02:45 PM Subject: [Bug testsuite/70150] Additonal test failures with --enable-default-pie https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70150 --- Comment #18 from H.J. Lu --- (In reply to psturm from comment #17) > Yes, they do appear when only using --enable-default-ssp, so I don't think > they are relevant. I suggest you open a new bug report if you haven't done so.
[Bug c++/70708] New: Suboptimal code generated when using _mm_set_sd (X64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70708 Bug ID: 70708 Summary: Suboptimal code generated when using _mm_set_sd (X64) Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: kobalicek.petr at gmail dot com Target Milestone: --- The ABI already uses XMM registers for floating point operations. Compare the following two snippets: double MyMinV1(double a, double b) { return a < b ? a : b; } double MyMinV2(double a, double b) { __m128d x = _mm_set_sd(a); __m128d y = _mm_set_sd(b); return _mm_cvtsd_f64(_mm_min_sd(x, y)); } And the code generated: MyMinV1(double, double): minsd xmm0, xmm1 ret MyMinV2(double, double): movsd QWORD PTR [rsp-24], xmm0 movsd QWORD PTR [rsp-16], xmm1 movsd xmm0, QWORD PTR [rsp-24] movsd xmm1, QWORD PTR [rsp-16] minsd xmm0, xmm1 ret The problem is obvious, the _mm_set_sd() intrinsic really generates movsd even if the content is already in the XMM register in the right place. I checked also CLang and it generates an optimal code for both functions. You can reproduce the test-case here: https://gcc.godbolt.org/#compilers:!((compiler:g6,options:'-O2+-Wall+',source:'%23include+%3Cxmmintrin.h%3E%0A%0Adouble+MyMinV1(double+a,+double+b)+%7B%0A++return+a+%3C+b+%3F+a+:+b%3B%0A%7D%0A%0Adouble+MyMinV2(double+a,+double+b)+%7B%0A++__m128d+x+%3D+_mm_set_sd(a)%3B%0A++__m128d+y+%3D+_mm_set_sd(b)%3B%0A++return+_mm_cvtsd_f64(_mm_min_sd(x,+y))%3B%0A%7D%0A')),filterAsm:(commentOnly:!t,directives:!t,intel:!t,labels:!t),version:3 It looks like all GCC versions are affected.
[Bug c++/70709] New: gcc hangs on valid C++ code on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70709 Bug ID: 70709 Summary: gcc hangs on valid C++ code on x86_64-linux-gnu Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: su at cs dot ucdavis.edu Target Milestone: --- The following code causes an ICE when compiled with the current gcc trunk on x86_64-linux-gnu. It also affects 4.8.x and later, and is a regression from 4.7.x. $ g++-trunk -v Using built-in specs. COLLECT_GCC=g++-trunk COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto --prefix=/usr/local/gcc-trunk --disable-bootstrap Thread model: posix gcc version 7.0.0 20160417 (experimental) [trunk revision 235070] (GCC) $ $ g++-4.7 -c small.cpp $ clang++-3.8 -c small.cpp $ $ g++-trunk -c small.cpp^C $ timeout -s 9 10 g++-trunk -c small.cpp Killed $ - struct A { A (int); }; struct B { B () {} A a[0]; }; struct C { C () {} B a[0]; };
[Bug rtl-optimization/70710] New: [5/6/7 Regression] Compile time hog w/ -O -g -fpeel-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70710 Bug ID: 70710 Summary: [5/6/7 Regression] Compile time hog w/ -O -g -fpeel-loops Product: gcc Version: 5.3.0 Status: UNCONFIRMED Keywords: compile-time-hog Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- gcc 5.3.0 and later takes infinite time to compile the following reduced snippet w/ -O[123] (or -Ofast) -g -fpeel-loops on x86_64-pc-linux-gnu: long int mh = 0; int du = 0; void vg (void) { int qe; char u1; for (qe = 0; qe < 16; ++qe) { mh &= du; du &= mh; u1 = du; } mh = 0; } Several top calls brought up by perf: 48.52% cc1 [.] nonzero_bits1 17.45% cc1 [.] cached_nonzero_bits 14.68% cc1 [.] reg_nonzero_bits_for_combine 1.29% cc1 [.] bitmap_bit_p 1.12% cc1 [.] target_default_pointer_address_modes_p 0.85% cc1 [.] val_signbit_known_set_p 0.27% cc1 [.] rtx_equal_p 0.26% cc1 [.] commutative_operand_precedence 0.22% cc1 [.] simplify_binary_operation_1 0.18% cc1 [.] simplify_replace_fn_rtx 0.15% cc1 [.] volatile_insn_p 0.12% cc1 [.] simplify_binary_operation 0.12% cc1 [.] avoid_constant_pool_reference 0.11% cc1 [.] ggc_internal_alloc 0.10% cc1 [.] simplify_const_binary_operation 0.07% cc1 [.] simplify_associative_operation 0.06% cc1 [.] validate_subreg 0.05% cc1 [.] swap_commutative_operands_p 0.05% cc1 [.] copy_rtx 0.04% cc1 [.] simplify_gen_binary 0.02% cc1 [.] simplify_subreg The original code had stuck for about 14 hours in compilation before I noticed that.
[Bug libfortran/70684] [4.9/5/6/7 Regression] incorrect reading of values from file on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70684 --- Comment #7 from Jerry DeLisle --- The following patch fixes the issue. diff --git a/libgfortran/io/list_read.c b/libgfortran/io/list_read.c index e24b3922..b8e174c5 100644 --- a/libgfortran/io/list_read.c +++ b/libgfortran/io/list_read.c @@ -197,7 +197,7 @@ check_buffers (st_parameter_dt *dtp) } done: - dtp->u.p.at_eol = (c == '\n' || c == EOF); + dtp->u.p.at_eol = (c == '\n' || c == '\r' || c == EOF); return c; } Regression tested on trunk with Linux.
[Bug c++/70708] Suboptimal code generated when using _mm_set_sd (X64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70708 --- Comment #1 from Marc Glisse --- Looks complicated. _mm_set_sd(x) returns {x,0}, and I don't think the calling convention guarantees anything about the unused part of SSE registers. _mm_min_sd uses the high part of its first argument. So we need to understand things about minsd. IIRC minsd is represented internally as a vec_merge of minpd and the first argument, so a vec_select on that might notice that we are only using the minpd part of the merge, but wouldn't simplify. If we represented scalar operations as {min(x[0],y[0]),x[1]} (vec_concat), things would likely simplify, but I believe that approach was rejected by rth (it doesn't scale to avx, etc). On the other hand, IIRC he was in favor of a representation as vec_merge(vec_dup(min(x[0],y[0])),x,1), which I guess would simplify as well (it is quite possible that I am misremembering. In any case, I probably have an early prototype lying around somewhere, maybe on gcc-patches@). We could expand _mm_min_sd to {min(x[0],y[0]),x[1]} (well, some variant of min) early (in the header, or in gimple), but then we would probably fail to detect that this is a single instruction and regress elsewhere... (note that for a simple __m128d f(double x){return _mm_set_sd(x);}, gcc either goes through the stack or uses movhpd, while clang happily uses movq %xmm0, %xmm0)