[Bug c/81117] Improve buffer overflow checking in strncpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81117 --- Comment #22 from Bernd Edlinger --- (In reply to Martin Sebor from comment #21) > I believe the bug you are pointing out was reported in > https://sourceware.org/bugzilla/show_bug.cgi?id=22442 and fixed in Glibc > 2.27. Please see the discussion at > https://sourceware.org/ml/libc-alpha/2017-11/msg00336.html for the > background. Ok, I see, thanks. Maybe an info in this warning message pointing out the other possibility (using __attribute__ ((__nonstring__))) to resolve the other use case would be helpful ?
[Bug fortran/83230] [8 regression] segmentation fault in bind C C/C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83230 --- Comment #6 from Jürgen Reuter --- So shall I commit this as an independent C/C++ bug?
[Bug ipa/83125] [8 regression] ICE in edge_badness, at ipa-inline.c:1025
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83125
--- Comment #3 from Dmitry G. Dyachenko ---
in r255225 stack differ
during IPA pass: inline
x.ii:43:10: internal compiler error: in edge_badness, at ipa-inline.c:993
t::~t() {}
^
0x9c13cf edge_badness
/home/dimhen/src/gcc_current/gcc/ipa-inline.c:992
0x18e7c09 update_edge_key
/home/dimhen/src/gcc_current/gcc/ipa-inline.c:1191
0x18e8148 update_caller_keys
/home/dimhen/src/gcc_current/gcc/ipa-inline.c:1313
0x18e808b update_caller_keys
/home/dimhen/src/gcc_current/gcc/ipa-inline.c:1302
0x18e9cae inline_small_functions
/home/dimhen/src/gcc_current/gcc/ipa-inline.c:2013
0x18eab3f ipa_inline
/home/dimhen/src/gcc_current/gcc/ipa-inline.c:2402
0x18eab3f execute
/home/dimhen/src/gcc_current/gcc/ipa-inline.c:2809
Please submit a full bug report,
[Bug tree-optimization/83262] New: SELECT CASE slower than IF/ELSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83262 Bug ID: 83262 Summary: SELECT CASE slower than IF/ELSE Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: tkoenig at gcc dot gnu.org Target Milestone: --- Created attachment 42781 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42781&action=edit Test case with timings The following test case by Tran Quoc Viet from comp.lang.fortran run with the arguments $ ./a.out 1 2 3 compiled with -O3 shows that the Fortran's select case statement is slower by a factor of 1.33 vs. an if/else form. Number of input arguments:3 GOTO: n =1, ss =-0.1480800E+10, time =0.347 (s) SELECT CASE: n =1, ss =-0.1480800E+10, time =0.199 (s) IF-Goto: n =1, ss =-0.1480800E+10, time =0.151 (s) IF-noGoto: n =1, ss =-0.1480800E+10, time =0.151 (s) IF-ELSE: n =1, ss =-0.1480800E+10, time =0.151 (s) GOTO: n =2, ss =-0.2961600E+10, time =0.702 (s) SELECT CASE: n =2, ss =-0.2961600E+10, time =0.401 (s) IF-Goto: n =2, ss =-0.2961600E+10, time =0.301 (s) IF-noGoto: n =2, ss =-0.2961600E+10, time =0.301 (s) IF-ELSE: n =2, ss =-0.2961600E+10, time =0.301 (s) GOTO: n =3, ss =-0.4442400E+10, time =1.054 (s) SELECT CASE: n =3, ss =-0.4442400E+10, time =0.602 (s) IF-Goto: n =3, ss =-0.4442400E+10, time =0.451 (s) IF-noGoto: n =3, ss =-0.4442400E+10, time =0.452 (s) IF-ELSE: n =3, ss =-0.4442400E+10, time =0.451 (s) GOTO costs totally 2.103 (s) SELECT CASE costs totally 1.202 (s) IF-Goto costs totally 0.903 (s) IF-noGoto costs totally 0.903 (s) IF-ELSE costs totally 0.903 (s) The Fortran FE translates the SELECT CASE into a switch.
[Bug target/70216] [SH] Implement __builtin_trap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70216 --- Comment #11 from John Paul Adrian Glaubitz --- (In reply to Oleg Endo from comment #10) > > FYI this issue is currently a regression that prevents building Linux with > > gcc7, since gcc7 introduced an optimization that transforms x/0 to > > __builtin_trap() rather than calling the libgcc div function. > > It's OK to add __builtin_trap to GCC 7. > Could you have a look and try the patch in Comment 6? I don't have so much > time for SH stuff these days... I will test the patch. Will it be enough to just add the patch, rebuild gcc-7 and then use this version of gcc-7 to rebuild the kernel? Or do we need to pass extra options during the kernel build?
[Bug target/70216] [SH] Implement __builtin_trap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70216 --- Comment #12 from Oleg Endo --- (In reply to John Paul Adrian Glaubitz from comment #11) > > > > It's OK to add __builtin_trap to GCC 7. > > Could you have a look and try the patch in Comment 6? I don't have so much > > time for SH stuff these days... > > I will test the patch. > > Will it be enough to just add the patch, rebuild gcc-7 and then use this > version of gcc-7 to rebuild the kernel? Or do we need to pass extra options > during the kernel build? I don't think the patch will be immediately useful for a linux config. It will require more work.
[Bug target/70216] [SH] Implement __builtin_trap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70216 --- Comment #13 from John Paul Adrian Glaubitz --- (In reply to Oleg Endo from comment #12) > I don't think the patch will be immediately useful for a linux config. It > will require more work. What about glibc which originally resulted in this bug report?
[Bug target/70216] [SH] Implement __builtin_trap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70216 --- Comment #14 from Oleg Endo --- (In reply to John Paul Adrian Glaubitz from comment #13) > > What about glibc which originally resulted in this bug report? I have no idea about it.
[Bug tree-optimization/83262] SELECT CASE slower than IF/ELSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83262 --- Comment #1 from Marc Glisse --- What version of gcc, and what platform? With gcc-8 on x86_64 (skylake), I get GOTO costs totally 0.904 (s) SELECT CASE costs totally 0.704 (s) IF-Goto costs totally 0.706 (s) IF-noGoto costs totally 0.705 (s) IF-ELSE costs totally 0.706 (s)
[Bug target/70216] [SH] Implement __builtin_trap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70216 --- Comment #15 from John Paul Adrian Glaubitz --- (In reply to Oleg Endo from comment #14) > (In reply to John Paul Adrian Glaubitz from comment #13) > > > > What about glibc which originally resulted in this bug report? > > I have no idea about it. I'll just give it a try then now.
[Bug target/83252] Wrong code with "-march=skylake-avx512 -O3"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83252 --- Comment #3 from Jakub Jelinek --- With newer SDE bisected fix to r255258. I'll commit the testcase and mark as fixed.
[Bug target/83252] Wrong code with "-march=skylake-avx512 -O3"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83252
--- Comment #4 from Jakub Jelinek ---
Started r249450, was likely latent before that.
Slightly adjusted testcase (needs C++ though, for some reason with C it doesn't
FAIL). The difference between r255257 and r255258 is:
--- pr83252.s.r255257 2017-12-03 06:47:40.0 -0500
+++ pr83252.s.r255258 2017-12-03 06:47:52.0 -0500
@@ -114,7 +114,8 @@ _Z3foov:
testl %ecx, %ecx
jne .L12
.L11:
- imull $1511624318, %esi, %eax
+ movl-28(%rsp), %eax
+ cmpq$1, t(%rip)
sbbl$-1, %eax
.L12:
movl-8(%rsp), %edx
// PR target/83252
// { dg-do run { target lp64 } }
// { dg-options "-O3" }
// { dg-additional-options "-mbmi2 -mtune=intel" { target bmi2 } }
long long int h = 8707493562598231894LL;
long long int i = 2720142332956971588LL;
long long int j = 5337614525613944604LL;
unsigned int k = 1092738485U;
long long int l = -2228108721620697360LL;
unsigned int m = 3060393125U;
long long int n = -5267148545474741934LL;
long long int o = 628644587444781171LL;
long long int p = -1929881923114969467LL;
unsigned int q = 342358347U;
unsigned int r = 4141428744U;
unsigned int s = 3147872734U;
long long int t = 2249711228974996732LL;
unsigned int u = 4012608111U;
unsigned int v = 664122423U;
unsigned int w = 795984700U;
unsigned int x = 751359462U;
unsigned int *y = &x;
unsigned int z = 274677517U;
unsigned long long int z1 = 14738459288714673932ULL;
unsigned int *z2 = &z;
unsigned int *z3 = &v;
unsigned long long int *z4 = &z1;
long long int z5;
unsigned int z6;
long long int *z7 = &z5;
unsigned int *z8 = &z6;
unsigned long long int z9 = 5759377091529791657ULL;
unsigned long long int x7 = 15085582420970487994ULL;
unsigned long long int y2 = 13537462614340337437ULL;
unsigned int y3 = 3159284560U;
long long int y4 = -5592336281551563373LL;
unsigned int y5 = 916868838U;
unsigned long long int y6 = 122846687590239390ULL;
unsigned long long int y7 = 15084731736992858763ULL;
unsigned int y8 = 1383085329U;
long long int y9 = 676559977929482050LL;
unsigned int x1 = 1321771489U;
unsigned int x2 = 2438389883U;
long long int x3 = 2997174617692616057LL;
unsigned long long int x4 = 4431338120255382076ULL;
unsigned long long int x5 = 11272010769831539270ULL;
unsigned int x6 = 2906827848U;
void
foo (void)
{
if ((-2783342978U * (int) l || z) && z2 && h && z1 && (z9 & ~-(8 ?
-2783342978U * (int) l : 0)))
{
i = m < n;
y7 = o >> *y - 751359400;
*z3 = x7;
long a = (o >> *y - 751359400 >> ~-(8 ? -2783342978U * (int) l : 0) -
88480234)
- (808 ? 8 ? -2783342978U * (int) l : 0 : 0) ? y2 : ~-(8 ?
-2783342978U * (int) l : 0) - 88480234;
y6 = a;
if (~0 % *z4 % 5)
y8 = -3 * ((8 ? l : 0) - 4 ? : 407228174574);
if (y3 < (0 || ~0))
{
long long *b = &y9;
z3 = 0;
int c = *z2;
*z7 = 0;
x1 = ~(808 ? -(8 ? (unsigned) (-2783342978U * l) : 0) : 0);
p = *b & j;
x2 = c;
}
else
{
j = 0;
int d, e = !0 % (q % *z4);
r = ((s || !k) && t) - -(8 ? -2783342978U * (int) l : d);
x3 = o >> *y - 751359400;
y9 = z9;
long f = o >> *y - 751359400 >> ~-(8 ? -2783342978U * (int) l : 0) -
88480234;
x4 = z1;
u = n * f * e * y4;
}
if (8ULL * -(808 ? -(8 ? -2783342978U * (int) l : 0) : 0))
;
else
{
*z3 = 0;
int g = 3 & y5;
x5 = (unsigned) (~o + 9223372036854775807 >> (8 ? l : 0));
*z8 = g + y9;
v = j || ~0 + 9223372036854775807 >> ~-(8 ? -2783342978U * (int) l :
0);
x6 = o >> (8 ? 8 * l : 0);
w = *y ? -2783342978U * l : 0;
}
}
}
int
main ()
{
foo ();
if (r != 88480289)
__builtin_abort ();
return 0;
}
[Bug tree-optimization/83262] SELECT CASE slower than IF/ELSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83262 --- Comment #2 from Thomas Koenig --- ig25@linux-d6cw:~> gfortran -v Es werden eingebaute Spezifikationen verwendet. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/home/ig25/lib/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper Ziel: x86_64-pc-linux-gnu Konfiguriert mit: ../trunk/configure --prefix=/home/ig25 --enable-maintainer-mode --enable-languages=c,c++,fortran --disable-multilib Thread-Modell: posix gcc-Version 8.0.0 20171127 (experimental) (GCC) ig25@linux-d6cw:~> cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Core(TM)2 Quad CPU Q8200 @ 2.33GHz stepping: 7 microcode : 0x70a cpu MHz : 1998.000 cache size : 2048 KB Using PowerPC, I get [tkoenig@gcc1-power7 ~]$ ./a.out 1 2 3000 Number of input arguments:3 GOTO: n =1, ss =-0.1480800E+10, time =0.441 (s) SELECT CASE: n =1, ss =-0.1480800E+10, time =0.412 (s) IF-Goto: n =1, ss =-0.1480800E+10, time =0.318 (s) IF-noGoto: n =1, ss =-0.1480800E+10, time =0.176 (s) IF-ELSE: n =1, ss =-0.1480800E+10, time =1.358 (s) GOTO: n =2, ss =-0.2961600E+10, time =1.372 (s) SELECT CASE: n =2, ss =-0.2961600E+10, time =0.647 (s) IF-Goto: n =2, ss =-0.2961600E+10, time =0.382 (s) IF-noGoto: n =2, ss =-0.2961600E+10, time =0.338 (s) IF-ELSE: n =2, ss =-0.2961600E+10, time =0.392 (s) GOTO: n = 3000, ss =-0.4442400E+09, time =0.108 (s) SELECT CASE: n = 3000, ss =-0.4442400E+09, time =0.092 (s) IF-Goto: n = 3000, ss =-0.4442400E+09, time =0.051 (s) IF-noGoto: n = 3000, ss =-0.4442400E+09, time =0.051 (s) IF-ELSE: n = 3000, ss =-0.4442400E+09, time =0.054 (s) GOTO costs totally 1.920 (s) SELECT CASE costs totally 1.151 (s) IF-Goto costs totally 0.752 (s) IF-noGoto costs totally 0.564 (s) IF-ELSE costs totally 1.804 (s) Total time:6.191 (s) with [tkoenig@gcc1-power7 ~]$ gfortran -v Es werden eingebaute Spezifikationen verwendet. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/home/tkoenig/libexec/gcc/powerpc64-unknown-linux-gnu/8.0.0/lto-wrapper Ziel: powerpc64-unknown-linux-gnu Konfiguriert mit: ../trunk/configure --prefix=/home/tkoenig --enable-languages=fortran,c,c++ --disable-multilib --enable-maintainer-mode Thread-Modell: posix gcc-Version 8.0.0 20171108 (experimental) (GCC)
[Bug fortran/83225] [8.0 regression] runtime error in transfer.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83225 --- Comment #6 from Jürgen Reuter --- Thanks for the very quick fix. This solves the problems in our code, and we also don't see any new regressions. Fine from our side.
[Bug tree-optimization/83262] SELECT CASE slower than IF/ELSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83262 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-12-03 Ever confirmed|0 |1 --- Comment #3 from Dominique d'Humieres --- I suspect that the code is not testing what it is expected to test. IMO the lines key = mod(n,10) + 1 should be replaced with key = mod(i,10) + 1 With the change I get GOTO costs totally 3.377 (s) SELECT CASE costs totally 4.455 (s) IF-Goto costs totally 1.553 (s) IF-noGoto costs totally 1.572 (s) IF-ELSE costs totally 1.547 (s) GCC 4.8.5 is significantly slower GOTO costs totally 6.594 (s) SELECT CASE costs totally 7.215 (s) IF-Goto costs totally 4.512 (s) IF-noGoto costs totally 4.601 (s) IF-ELSE costs totally 4.581 (s)
[Bug libstdc++/83263] New: [8.0 regression] segmentation fault in alloc_traits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83263 Bug ID: 83263 Summary: [8.0 regression] segmentation fault in alloc_traits Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: juergen.reuter at desy dot de Target Milestone: --- Created attachment 42782 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42782&action=edit reproducer The following code is a simple XDR reader which produces the following segmentation violations when run on a simple XDR file (attached). The latest version which did not show the problems was r253161, the first where I observed the issue r254916. The reproducer tarball contains the header files, the C++ files, the Makefile and the XDR example file stdhep_4_p.hep to be read in by the produced executable. This is the compilation chain: g++ -c WOXDR.cpp g++ -c WOStdHep.cpp g++ -c WOStdHepRdr.cpp g++ WOXDR.o WOStdHep.o WOStdHepRdr.o -ldl -lstdc++ -o stdhep_rd StdHepRdr.cpp This is the backtrace: Program received signal SIGSEGV, Segmentation fault. __GI___libc_free (mem=0x6530302e30202c30) at malloc.c:2931 2931malloc.c: No such file or directory. (gdb) bt #0 __GI___libc_free (mem=0x6530302e30202c30) at malloc.c:2931 #1 0x77963c06 in deallocate (this=0x7fffda60, __p=) at /home/reuter/sandbox_gcc8/packages/gcc_trunk/_build/x86_64-pc-linux-gnu/libstdc++-v3/include/ext/new_allocator.h:125 #2 deallocate (__a=..., __n=, __p=) at /home/reuter/sandbox_gcc8/packages/gcc_trunk/_build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/alloc_traits.h:462 #3 _M_destroy (__size=, this=0x7fffda60) at /home/reuter/sandbox_gcc8/packages/gcc_trunk/_build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:226 #4 _M_dispose (this=0x7fffda60) at /home/reuter/sandbox_gcc8/packages/gcc_trunk/_build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:221 #5 ~basic_string (this=0x7fffda60, __in_chrg=) at /home/reuter/sandbox_gcc8/packages/gcc_trunk/_build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:647 #6 ~basic_stringbuf (this=0x7fffda18, __in_chrg=) at /home/reuter/sandbox_gcc8/packages/gcc_trunk/_build/x86_64-pc-linux-gnu/libstdc++-v3/include/sstream:65 #7 std::__cxx11::basic_stringstream, std::allocator >::~basic_stringstream (this=0x7fffda00, __in_chrg=, __vtt_parm=) at /home/reuter/sandbox_gcc8/packages/gcc_trunk/_build/x86_64-pc-linux-gnu/libstdc++-v3/include/sstream:732 #8 0x00407cb7 in WOUTIL::WOStdHepRdr::readEvent(std::ostream&, int) () #9 0x00408854 in main () Originally I believed this to be a problem in the bind(C) implementation but apparently it seemed to appear also for standalone C++ code. Here is the Fortran bind(C) example: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83230 The expected output of the XDR reader is the following: WHIZARD StdHep Reader : opened file : stdhep_4_p.hep == File Header === total blocks: 847 version: 2.01 title: WHIZARD 2.6.2 comment: No comment date: Sun Dec 3 13:52:19 2017 closing date: Sun Dec 3 13:52:19 2017 expected events: 3 events: 5 firstTable: -1 dimTable: 100 nNTuples: 0 nBlocks: 8 block names: : Standard HEP COMMON block, see STDHEP Product : Standard HEP COMMON block with multiple interaction, see STDHEP Product : Stdhep begin run record, see STDHEP Product : Stdhep end run record, see STDHEP Product : Standard HEP COMMON block with Les Houches, see STDHEP Product : Standard HEP COMMON block with Les Houches and multiple interaction : Les Houches HEPEUP common block : Les Houches HEPRUP common block = Event #0 [ id ]index| PDG |q(el)|px, py,pz| energy | mass |sta| vertex x, y , z | spin | colorflow | [daughters] []0|11|-1.00| 0.00e+00, 0.00e+00, 2.50e+02| 2.50e+02| 5.11e-04| 2 | 0.00e+00, 0.00e+00, 0.00e+00| 0.00e+00, 0.00e+00, 0.00e+00| (0, 0) | [ 2, 3 ] [0001]1| -11| 1.00| 0.00e+00, 0.00e+00, -2.50e+02| 2.50e+02| 5.11e-04| 2 | 0.00e+00, 0.00e+00, 0.00e+00| 0.00e+00, 0.00e+00, 0.00e+00| (0, 0) | [ 2, 3 ] [0002]2|15|-1.00| 1.42e+02, 1.99e+02, -5.22e+01| 2.50e+02| 1.78e+00| 1 | 0.00e+00, 0.00e+00, 0.00e+00| 0.00e+00, 0.00e+00, 0.00e+00| (0, 0) | [ 0, 0 ] [0003]3| -15| 1.00|-1.42e+02,-1.99e+02, 5.22e+01| 2.50e+02| 1.78e+00| 1 | 0.00e+00, 0.00e+00, 0.00e+00| 0.00e+00, 0.00e+00, 0.00e+00| (0, 0) | [ 0, 0 ] converted 1 events - written to stdout ==
[Bug c/81117] Improve buffer overflow checking in strncpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81117 Martin Sebor changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=82945 --- Comment #23 from Martin Sebor --- I agree that mentioning the attribute in the documentation of the -Wstringop-truncation option would be helpful. Let me submit a patch with that change. I considered having GCC issue a note suggesting the attribute but decided that using it was sufficiently rare and specialized that it would be a distraction in most situations. Of the warnings the option found in GCC, GDB, and Glibc, using the attribute was a solution in just three instances so far, all in Glibc: https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=commit;h=7532837d7b03b3ca5b9a63d77a5bd81dd23f3d9c Using attribute nonstring inappropriately could also lead to more warnings because it triggers its own checks that aren't suitable for nul-terminated strings -- see pr82945.
[Bug fortran/83225] [8.0 regression] runtime error in transfer.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83225 Jerry DeLisle changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jerry DeLisle --- (In reply to Jürgen Reuter from comment #6) > Thanks for the very quick fix. This solves the problems in our code, and we > also don't see any new regressions. Fine from our side. Thanks for quick check, I will close this PR. Cheers
[Bug tree-optimization/83262] SELECT CASE slower than IF/ELSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83262 --- Comment #4 from Dominique d'Humieres --- The speed depends on the optimization level, SELECT CASE being the fastest with -O1 -O0 GOTO costs totally 4.667 (s) SELECT CASE costs totally 4.578 (s) IF-Goto costs totally 4.986 (s) IF-noGoto costs totally 5.734 (s) IF-ELSE costs totally 5.731 (s) -O1 GOTO costs totally 1.231 (s) SELECT CASE costs totally 1.181 (s) IF-Goto costs totally 1.826 (s) IF-noGoto costs totally 1.738 (s) IF-ELSE costs totally 1.668 (s) -O2 GOTO costs totally 3.721 (s) SELECT CASE costs totally 4.274 (s) IF-Goto costs totally 1.517 (s) IF-noGoto costs totally 1.482 (s) IF-ELSE costs totally 1.525 (s) -O3 GOTO costs totally 3.755 (s) SELECT CASE costs totally 4.234 (s) IF-Goto costs totally 1.497 (s) IF-noGoto costs totally 1.522 (s) IF-ELSE costs totally 1.537 (s) -Ofast GOTO costs totally 3.280 (s) SELECT CASE costs totally 4.324 (s) IF-Goto costs totally 1.526 (s) IF-noGoto costs totally 1.534 (s) IF-ELSE costs totally 1.513 (s)
[Bug fortran/83191] [7/8 Regression] Writing a namelist with repeated complex numbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83191 --- Comment #6 from Jerry DeLisle --- Author: jvdelisle Date: Sun Dec 3 16:47:12 2017 New Revision: 255365 URL: https://gcc.gnu.org/viewcvs?rev=255365&root=gcc&view=rev Log: 2017-12-03 Jerry DeLisle Dominique d'Humieres PR libgfortran/83191 * io/transfer.c (list_formatted_read_scalar): Do not set namelist_mode bit here. (namelist_read): Likewise. (data_transfer_init): Clear the mode bit here. (finalize_transfer): Do set the mode bit just before any calls to namelist_read or namelist_write. It can now be referred to in complex_write. ^ io/write.c (write_complex): Suppress the leading blanks when namelist_mode bit is not set to 1. * gfortran.dg/namelist_95.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/namelist_95.f90 Modified: trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/io/list_read.c trunk/libgfortran/io/transfer.c trunk/libgfortran/io/write.c
[Bug target/70216] [SH] Implement __builtin_trap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70216 --- Comment #16 from Rich Felker --- The kernel build regression is just a gratuitous unresolved symbol; the code path where is happens should not be reachable or the kernel would crash. So I think the patch as-is is fine for fixing that issue. The need for an instruction that generates SIGILL is just for ensuring that apps that reach __builtin_trap() or equivalent actually trap rather than doing something wrong/random. I think -mbuiltin-trap=insn-FFFD and making it default for Linux (and possibly other hosted targets? NetBSD?) would fully solve that problem.
[Bug libstdc++/69331] FAIL: 20_util/shared_ptr/thread/default_weaktoshared.cc execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69331 --- Comment #19 from John David Anglin --- On hppa64-hp-hpux11.11, the tests currently fail on gcc-8 trunk with a link error: spawn /test/gnu/gcc/objdir/./gcc/xg++ -shared-libgcc -B/test/gnu/gcc/objdir/./gc c -nostdinc++ -L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/src -L/tes t/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/src/.libs -L/test/gnu/gcc/objd ir/hppa64-hp-hpux11.11/libstdc++-v3/libsupc++/.libs -B/opt/gnu64/gcc/gcc-8/hppa6 4-hp-hpux11.11/bin/ -B/opt/gnu64/gcc/gcc-8/hppa64-hp-hpux11.11/lib/ -isystem /op t/gnu64/gcc/gcc-8/hppa64-hp-hpux11.11/include -isystem /opt/gnu64/gcc/gcc-8/hppa 64-hp-hpux11.11/sys-include -B/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libstdc ++-v3/src/.libs -fmessage-length=0 -fno-show-column -ffunction-sections -fdata-sections -g -O2 -DLOCALEDIR="." -nostdinc++ -I/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/hppa64-hp-hpux11.11 -I/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include -I/test/gnu/gcc/gcc/libstdc++-v3/libsupc++ -I/test/gnu/gcc/gcc/libstdc++-v3/include/backward -I/test/gnu/gcc/gcc/libstdc++-v3/testsuite/util /test/gnu/gcc/gcc/libstdc++-v3/testsuite/20_util/shared_ptr/thread/default_weaktoshared.cc -pthread -fno-diagnostics-show-caret -fdiagnostics-color=never ./libtestc++.a -L/test/gnu/gcc/objdir/hppa64hp-hpux11.11/libstdc++-v3/src /filesystem/.libs -lm -o ./default_weaktoshared.exeld: Unsatisfied symbol "__atomic_fetch_add_4" in file /var/tmp//ccfRrRyB.old: Unsatisfied symbol "__atomic_fetch_sub_4" in file /var/tmp//ccfRrRyB.o We need to link with "-latomic".
[Bug fortran/36313] [F03] {MIN,MAX}{LOC,VAL} should accept character arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36313 --- Comment #14 from Thomas Koenig --- Author: tkoenig Date: Sun Dec 3 20:14:05 2017 New Revision: 255367 URL: https://gcc.gnu.org/viewcvs?rev=255367&root=gcc&view=rev Log: 2017-12-03 Thomas Koenig PR fortran/36313 * check.c (gfc_check_minval_maxval): Use int_orLreal_or_char_check_f2003 for array argument. * iresolve.c (gfc_resolve_maxval): Insert number in function name for character arguments. (gfc_resolve_minval): Likewise. * trans-intrinsic.c (gfc_conv_intrinsic_minmaxloc): Fix comment. (gfc_conv_intrinsic_minmaxval): Resort arguments and call library function if dealing with a character function. 2017-12-03 Thomas Koenig PR fortran/36313 * Makefile.am: Add new files for character-valued maxval and minval. * Makefile.in: Regenerated. * gfortran.map: Add new functions. * m4/iforeach-s2.m4: New file. * m4/ifunction-s2.m4: New file. * m4/iparm.m4: Add intitval for minval and maxval. * m4/maxval0s.m4: New file. * m4/maxval1s.m4: New file. * m4/minval0s.m4: New file. * m4/minval1s.m4: New file. * generated/maxval0_s1.c: New file. * generated/maxval0_s4.c: New file. * generated/maxval1_s1.c: New file. * generated/maxval1_s4.c: New file. * generated/minval0_s1.c: New file. * generated/minval0_s4.c: New file. * generated/minval1_s1.c: New file. * generated/minval1_s4.c: New file. 2017-12-03 Thomas Koenig PR fortran/36313 * gfortran.dg/maxval_char_1.f90: New test. * gfortran.dg/maxval_char_2.f90: New test. * gfortran.dg/maxval_char_3.f90: New test. * gfortran.dg/maxval_char_4.f90: New test. * gfortran.dg/minval_char_1.f90: New test. * gfortran.dg/minval_char_2.f90: New test. * gfortran.dg/minval_char_3.f90: New test. * gfortran.dg/minval_char_4.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/maxval_char_1.f90 trunk/gcc/testsuite/gfortran.dg/maxval_char_2.f90 trunk/gcc/testsuite/gfortran.dg/maxval_char_3.f90 trunk/gcc/testsuite/gfortran.dg/maxval_char_4.f90 trunk/gcc/testsuite/gfortran.dg/minval_char_1.f90 trunk/gcc/testsuite/gfortran.dg/minval_char_2.f90 trunk/gcc/testsuite/gfortran.dg/minval_char_3.f90 trunk/gcc/testsuite/gfortran.dg/minval_char_4.f90 trunk/libgfortran/generated/maxval0_s1.c trunk/libgfortran/generated/maxval0_s4.c trunk/libgfortran/generated/maxval1_s1.c trunk/libgfortran/generated/maxval1_s4.c trunk/libgfortran/generated/minval0_s1.c trunk/libgfortran/generated/minval0_s4.c trunk/libgfortran/generated/minval1_s1.c trunk/libgfortran/generated/minval1_s4.c trunk/libgfortran/m4/iforeach-s2.m4 trunk/libgfortran/m4/ifunction-s2.m4 trunk/libgfortran/m4/maxval0s.m4 trunk/libgfortran/m4/maxval1s.m4 trunk/libgfortran/m4/minval0s.m4 trunk/libgfortran/m4/minval1s.m4 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/fortran/iresolve.c trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/Makefile.am trunk/libgfortran/Makefile.in trunk/libgfortran/gfortran.map trunk/libgfortran/m4/iparm.m4
[Bug target/70216] [SH] Implement __builtin_trap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70216 --- Comment #17 from John Paul Adrian Glaubitz --- (In reply to Rich Felker from comment #16) > The kernel build regression is just a gratuitous unresolved symbol; the code > path where is happens should not be reachable or the kernel would crash. So > I think the patch as-is is fine for fixing that issue. I'm testing the patch right now. Already rebuild gcc with the patch and I'm now building the kernel with that gcc.
[Bug c++/83264] New: std::initializer_list with a single element selects the wrong overload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83264
Bug ID: 83264
Summary: std::initializer_list with a single element selects
the wrong overload
Product: gcc
Version: 7.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rustamabd at gmail dot com
Target Milestone: ---
Consider the following:
#include
#include
using namespace std;
template
struct A {
A(int) {
cout << "A(int)\n";
}
A(std::initializer_list) {
cout << "A(initializer_list)\n";
}
};
struct UdfInt {
UdfInt(int) {}
};
int main() {
A obj({ 10 });
return 0;
}
GCC (any version) prints "A(initializer_list)". Other compilers (clang, MSVC)
print "A(int)".
According to [dcl.init.list]/3.9, a single-element braced-init-list should be
unwrapped which means the A(int) overload is the best viable alternative since
the other one needs a user-defined conversion.
[Bug bootstrap/83265] New: [8 Regression] Bootstrap failure on powerpc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83265 Bug ID: 83265 Summary: [8 Regression] Bootstrap failure on powerpc64 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: tkoenig at gcc dot gnu.org Target Milestone: --- Configure with ../trunk/configure --prefix=$HOME --enable-languages=c,c++,fortran --disable-multilib leads to /home/tkoenig/trunk-bin/./gcc/xgcc -B/home/tkoenig/trunk-bin/./gcc/ -xc -nostdinc /dev/null -S -o /dev/null -fself-test=../../trunk/gcc/testsuite/selftests cc1: interner Compiler-Fehler: in rs6000_option_override_internal, bei config/rs6000/rs6000.c:4187 0x1133b8e3 rs6000_option_override_internal ../../trunk/gcc/config/rs6000/rs6000.c:4187 0x1133fba7 rs6000_option_override ../../trunk/gcc/config/rs6000/rs6000.c:5300 0x10d91f3b process_options ../../trunk/gcc/toplev.c:1234 0x10d93cd7 do_compile ../../trunk/gcc/toplev.c:2015 for current trunk (as of a few hours ago). This is for powerpc64-unknown-linux-gnu.
[Bug fortran/83191] [7/8 Regression] Writing a namelist with repeated complex numbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83191 --- Comment #7 from Jerry DeLisle --- Author: jvdelisle Date: Sun Dec 3 20:43:59 2017 New Revision: 255368 URL: https://gcc.gnu.org/viewcvs?rev=255368&root=gcc&view=rev Log: 2017-12-03 Jerry DeLisle Dominique d'Humieres Backport from trunk PR libgfortran/83191 * io/transfer.c (list_formatted_read_scalar): Do not set namelist_mode bit here. (namelist_read): Likewise. (data_transfer_init): Clear the mode bit here. (finalize_transfer): Do set the mode bit just before any calls to namelist_read or namelist_write. It can now be referred to in complex_write. * io/write.c (write_complex): Suppress the leading blanks when namelist_mode bit is not set to 1. * gfortran.dg/namelist_95.f90: New test. Added: branches/gcc-7-branch/gcc/testsuite/gfortran.dg/namelist_95.f90 Modified: branches/gcc-7-branch/gcc/testsuite/ChangeLog branches/gcc-7-branch/libgfortran/ChangeLog branches/gcc-7-branch/libgfortran/io/list_read.c branches/gcc-7-branch/libgfortran/io/transfer.c branches/gcc-7-branch/libgfortran/io/write.c
[Bug bootstrap/83265] [8 Regression] Bootstrap failure on powerpc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83265 Thomas Koenig changed: What|Removed |Added CC||segher at gcc dot gnu.org Target Milestone|--- |8.0
[Bug fortran/83191] [7/8 Regression] Writing a namelist with repeated complex numbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83191 Jerry DeLisle changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Jerry DeLisle --- Fixed on trunk and on 7. Closing
[Bug libfortran/83168] FAIL: gfortran.dg/fmt_f0_2.f90 with a sanitized libgfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83168 --- Comment #7 from Jerry DeLisle --- Should this be backported?
[Bug bootstrap/83265] [8 Regression] Bootstrap failure on powerpc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83265 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-12-03 Assignee|unassigned at gcc dot gnu.org |segher at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Segher Boessenkool --- Mine.
[Bug fortran/36313] [F03] {MIN,MAX}{LOC,VAL} should accept character arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36313 --- Comment #15 from Thomas Koenig --- Fixed on trunk, closing.
[Bug fortran/20585] [meta-bug] Fortran 2003 support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20585
Bug 20585 depends on bug 36313, which changed state.
Bug 36313 Summary: [F03] {MIN,MAX}{LOC,VAL} should accept character arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36313
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|--- |FIXED
[Bug fortran/36313] [F03] {MIN,MAX}{LOC,VAL} should accept character arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36313 Thomas Koenig changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #16 from Thomas Koenig --- Really closing.
[Bug libfortran/83168] FAIL: gfortran.dg/fmt_f0_2.f90 with a sanitized libgfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83168 --- Comment #8 from Dominique d'Humieres --- > Should this be backported? No strong opinion, but it fixes a latent bug.
[Bug target/83252] Wrong code with "-march=skylake-avx512 -O3"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83252 --- Comment #5 from Dmitry Babokin --- The original test case is also fixed. Thanks for investigation.
[Bug target/83252] Wrong code with "-march=skylake-avx512 -O3"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83252 --- Comment #6 from Dmitry Babokin --- (In reply to Jakub Jelinek from comment #1) > Option bisection is rarely useful for GCC, debugging issues with -Ox -fthat > -fno-this -fwhatever is usually not beneficial over just -Ox or whatever > minimal options you need it. Bisecting to what GCC version introduced the > bug or changed behavior is usually much better. Bisecting optimizations is orthogonal to bisecting of revision the bug started with. In my experience it's extremely useful (with icc and clang) for understanding the root cause of the bug (just compare two assemblers or IRs with and without the guilty optimization). It's also very useful for distinguishing bugs in automatic way - in case of multiple failing test cases I can sort them in different buckets corresponding to guilty optmizations. This analysis is not 100% accurate, but is very useful. And the third useful feature of such bisection - finding an optimization for initial bug assignment. I'm not insisting on such functionality, as my bugs were always analysed and fixed in timely manner (unlike with other compilers). But I still think gcc would benefit from such mechanism a lot.
[Bug target/70216] [SH] Implement __builtin_trap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70216 --- Comment #18 from John Paul Adrian Glaubitz --- (In reply to John Paul Adrian Glaubitz from comment #17) > I'm testing the patch right now. Already rebuild gcc with the patch and I'm > now building the kernel with that gcc. I can confirm that the patch from comment #6 resolves the problem for me. Can we get it merged in one form or another? I'll file a bug report against the gcc-7 package in Debian so the patch gets added in Debian already.
[Bug fortran/83076] [8 Regression] ICE in gfc_deallocate_scalar_with_status, at fortran/trans.c:1598
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83076 --- Comment #7 from Dominique d'Humieres --- With the patch at https://gcc.gnu.org/ml/fortran/2017-11/msg00171.html the number of internal compiler error: in fold_convert_loc, at fold-const.c:2368 in my test suite went from 5 without the patch up to 54 with it and the number of internal compiler error: in gfc_add_modify_loc, at fortran/trans.c:159 from 2 to 29. A prototype of the new errors of the first kind is the test in the first attachment to pr64757 compiled with -fcoarray=lib. A prototype for errors of the second kind is the test in pr58793 comment 0 also compiled with -fcoarray=lib. Yes, I know that these tests does not need -fcoarray=lib, but they should not give an ICE with it. I can provide a larger set of other tests ICEing if needed.
[Bug tree-optimization/83262] SELECT CASE slower than IF/ELSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83262 --- Comment #5 from Dominique d'Humieres --- Compiling the test with '-O3 -fno-align-jumps' gives GOTO costs totally 1.242 (s) SELECT CASE costs totally 1.253 (s) IF-Goto costs totally 1.507 (s) IF-noGoto costs totally 1.518 (s) IF-ELSE costs totally 1.514 (s) comparable with the timing for '-O1' (comment 4).
[Bug gcov-profile/83266] New: [GCOV] A True if statement is wrongly marked as not executed in gcov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83266
Bug ID: 83266
Summary: [GCOV] A True if statement is wrongly marked as not
executed in gcov
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: yangyibiao at nju dot edu.cn
CC: marxin at gcc dot gnu.org
Target Milestone: ---
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 7.2.0-8ubuntu3'
--with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-7
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 7.2.0 (Ubuntu 7.2.0-8ubuntu3)
$ cat small.c
int main()
{
int i = 1;
if (i > 0) {
i++;
}
if (1 > 0) {
i++;
}
}
$ gcc -fprofile-arcs -ftes-coverage small.c; ./a.out; gcov small.c; cat
small.c.gcov
File 'small.c'
Lines executed:100.00% of 5
Creating 'small.c.gcov'
File ''
No executable lines
Removing '.gcov'
-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
-:0:Programs:1
1:1:int main()
-:2:{
1:3:int i = 1;
1:4:if (i > 0) {
1:5:i++;
-:6:}
-:7:
-:8:if (1 > 0) {
1:9:i++;
-: 10:}
-: 11:}
As we can find that Line #4 is marked as executed and Line #8 is marked as not
executed.
[Bug gcov-profile/83266] [GCOV] A True if statement is wrongly marked as not executed in gcov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83266
--- Comment #1 from Yibiao Yang ---
I am not very sure whether this is a bug or it is only the default behavior in
gcov.
(In reply to Yibiao Yang from comment #0)
> $ gcc -v
> Using built-in specs.
> COLLECT_GCC=gcc
> COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
> OFFLOAD_TARGET_NAMES=nvptx-none
> OFFLOAD_TARGET_DEFAULT=1
> Target: x86_64-linux-gnu
> Configured with: ../src/configure -v --with-pkgversion='Ubuntu
> 7.2.0-8ubuntu3' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
> --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
> --with-gcc-major-version-only --program-suffix=-7
> --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
> --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
> --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
> --enable-libstdcxx-debug --enable-libstdcxx-time=yes
> --with-default-libstdcxx-abi=new --enable-gnu-unique-object
> --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
> --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
> --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
> --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
> --enable-offload-targets=nvptx-none --without-cuda-driver
> --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
> --target=x86_64-linux-gnu
> Thread model: posix
> gcc version 7.2.0 (Ubuntu 7.2.0-8ubuntu3)
>
> $ cat small.c
> int main()
> {
> int i = 1;
> if (i > 0) {
> i++;
> }
>
> if (1 > 0) {
> i++;
> }
> }
>
> $ gcc -fprofile-arcs -ftes-coverage small.c; ./a.out; gcov small.c; cat
> small.c.gcov
> File 'small.c'
> Lines executed:100.00% of 5
> Creating 'small.c.gcov'
>
> File ''
> No executable lines
> Removing '.gcov'
>
> -:0:Source:small.c
> -:0:Graph:small.gcno
> -:0:Data:small.gcda
> -:0:Runs:1
> -:0:Programs:1
> 1:1:int main()
> -:2:{
> 1:3:int i = 1;
> 1:4:if (i > 0) {
> 1:5:i++;
> -:6:}
> -:7:
> -:8:if (1 > 0) {
> 1:9:i++;
> -: 10:}
> -: 11:}
>
> As we can find that Line #4 is marked as executed and Line #8 is marked as
> not executed.
[Bug libfortran/83168] FAIL: gfortran.dg/fmt_f0_2.f90 with a sanitized libgfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83168 --- Comment #9 from Jerry DeLisle --- Author: jvdelisle Date: Mon Dec 4 03:51:28 2017 New Revision: 255373 URL: https://gcc.gnu.org/viewcvs?rev=255373&root=gcc&view=rev Log: 2017-12-03 Jerry DeLisle Backport from trunk PR libgfortran/83168 * io/write.c (select_string): Bump size by one to avoid overrun. Modified: branches/gcc-7-branch/libgfortran/ChangeLog branches/gcc-7-branch/libgfortran/io/write.c
[Bug libfortran/83168] FAIL: gfortran.dg/fmt_f0_2.f90 with a sanitized libgfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83168 Jerry DeLisle changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Jerry DeLisle --- Fixed on 7 and closing.
[Bug tree-optimization/83262] SELECT CASE slower than IF/ELSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83262 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #6 from kargl at gcc dot gnu.org --- (In reply to Thomas Koenig from comment #0) > >GOTO costs totally 2.103 (s) > SELECT CASE costs totally 1.202 (s) > IF-Goto costs totally 0.903 (s) > IF-noGoto costs totally 0.903 (s) > IF-ELSE costs totally 0.903 (s) > > The Fortran FE translates the SELECT CASE into a switch. Dick Henderson in clf claims that there is a bug in the code. You're comparing apples and oranges. Mike Metcalf ran the code with Dick's suggested change. There is no statistically significant difference in timings.
[Bug driver/83206] -mfpu=auto does not work on ARM (armv7l-unknown-linux-gnueabihf)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83206 --- Comment #5 from Andrew Roberts --- It looks like I was right about this all along, its just that armv6l isn't working. armv7l seems ok: On RaspberryPi B - ARM1176 rev 7 (0x4100b760) cat /proc/cpuinfo processor : 0 model name : ARMv6-compatible processor rev 7 (v6l) BogoMIPS: 697.95 Features: half thumb fastmult vfp edsp java tls CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part: 0xb76 CPU revision: 7 /usr/local/gcc/bin/gcc -v Using built-in specs. COLLECT_GCC=/usr/local/gcc/bin/gcc COLLECT_LTO_WRAPPER=/usr/local/gcc-8.0.0/libexec/gcc/armv6l-unknown-linux-gnueabihf/8.0.0/lto-wrapper Target: armv6l-unknown-linux-gnueabihf Configured with: ../gcc-8.0.0/configure --prefix=/usr/local/gcc-8.0.0 --program-suffix= --disable-werror --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-plugin --enable-gnu-indirect-function --enable-lto --with-isl --enable-languages=c,c++,fortran,lto --disable-libgcj --enable-clocale=gnu --disable-libstdcxx-pch --enable-install-libiberty --disable-multilib --disable-libssp --enable-default-pie --enable-default-ssp --host=armv6l-unknown-linux-gnueabihf --build=armv6l-unknown-linux-gnueabihf --with-arch=armv6 --with-float=hard --with-fpu=vfp --disable-bootstrap Thread model: posix gcc version 8.0.0 20171126 (experimental) (GCC) /usr/local/gcc/bin/gcc -march=native -mcpu=native -mtune=native -Q --target-help | grep "march=\|mtune=\|mcpu=\|mfpu=" -march= armv6zk+fp -mcpu=arm1176jz-s -mfpu=vfp -mtune= arm1176jz-s /usr/local/gcc/bin/gcc -o matrix-v6 -march=native -mcpu=native -mtune=native -mfpu=auto -O3 matrix.c cc1: error: -mfloat-abi=hard: selected processor lacks an FPU whereas: /usr/local/gcc/bin/gcc -o matrix-v6 -march=native -mcpu=native -mtune=native -mfpu=vfp -O3 matrix.c is fine. -mfpu=auto works on Raspberry Pi 3B - 4 x Cortex-A53 rev 4 (0x4100d030) and ODROID-XU4 - 4 x Cortex-A15 rev 3 (0x4100c0f0)/4 x Cortex-A7 rev 3 (0x4100c070) On aarch64 -mfpu=auto gives: gcc: error: unrecognized command line option ‘-mfpu=auto’ which is correct, but would it be better to silently accept it for compatibility with ARM 32 bit
[Bug c++/82751] g++ 8 is breaking assert_lt (gtest) called from a lambda function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82751 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Markus Trippelsdorf --- dup. *** This bug has been marked as a duplicate of bug 83160 ***
[Bug c++/83160] [8 regression] lvalue required as unary ‘&’ operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83160 Markus Trippelsdorf changed: What|Removed |Added CC||sylvestre at debian dot org --- Comment #3 from Markus Trippelsdorf --- *** Bug 82751 has been marked as a duplicate of this bug. ***
[Bug c++/83160] [8 regression] lvalue required as unary ‘&’ operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83160
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2017-12-04
CC||trippels at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #4 from Markus Trippelsdorf ---
markus@x4 /tmp % cat foo.ii
template void CmpHelperLT(T &);
void TestBody() {
const int a = 0;
[&a] { CmpHelperLT(a); };
}
markus@x4 /tmp % clang++ -w -c foo.ii
markus@x4 /tmp % icpc -c foo.ii
markus@x4 /tmp % g++ -c foo.ii
foo.ii: In lambda function:
foo.ii:4:23: error: lvalue required as unary ‘&’ operand
[&a] { CmpHelperLT(a); };
^
[Bug sanitizer/81697] Incorrect ASan global variables alignment on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81697 --- Comment #5 from Maxim Ostapenko --- Fixed on trunk.
[Bug target/83252] Wrong code with "-march=skylake-avx512 -O3"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83252 Andrew Pinski changed: What|Removed |Added Keywords||wrong-code --- Comment #7 from Andrew Pinski --- (In reply to Dmitry Babokin from comment #6) > I'm not insisting on such functionality, as my bugs were always analysed and > fixed in timely manner (unlike with other compilers). But I still think gcc > would benefit from such mechanism a lot. The problem with GCC (and sometimes other compilers) is latent bugs in passes after where the change happened. A lot of the time for GCC, this has been true. Especially when we are talking about GCC's RTL passes; some of which date from the mid to late 1990s (e.g. combine). And even some of the RTL passes don't have an option flag to enable/disable (e.g. combine). Also there are other things like disabling the late VRP or another pass which uses the VRP data that was not updated which causes the bug to show up. Just a few examples of why this functionality is not very useful in GCC and also it gets abused by some users of it to workaround a bug in one specific version of GCC rather than reporting the bug :).
