[Bug debug/90716] New: gcc generates wrong debug information at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90716
Bug ID: 90716
Summary: gcc generates wrong debug information at -O2
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: qrzhang at gatech dot edu
Target Milestone: ---
This is a recent regression. Gcc-8 works fine. Bisect points to r271553.
The expected value of "j" should be 8. With optimization, it prints "0".
$ gcc-trunk -v
gcc version 10.0.0 20190602 (experimental) [trunk revision 271843] (GCC)
$ gdb -v
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
#Correct output#
$ gcc-trunk -g abc.c outer.c
$ gdb -x cmds -batch a.out
Breakpoint 1 at 0x40049d: file abc.c, line 10.
Breakpoint 1, main () at abc.c:10
10optimize_me_not();
$1 = 8
#Wrong output at O2#
$ gcc-trunk -g abc.c outer.c -O2
$ gdb -x cmds -batch a.out
Breakpoint 1 at 0x400396: file abc.c, line 10.
Breakpoint 1, main () at abc.c:10
10optimize_me_not();
$1 = 0
$ cat abc.c
int a[7][8];
int main() {
int b, j;
b = 0;
for (; b < 7; b++) {
j = 0;
for (; j < 8; j++)
a[b][j] = 0;
}
optimize_me_not();
}
$ cat cmds
b 10
r
p j
kill
q
$ cat outer.c
void optimize_me_not() {}
[Bug tree-optimization/90715] New: ICE: tree check: expected private or shared or firstprivate or lastprivate or reduction or task_reduction or in_reduction or copyin or copyprivate or linear, have gt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90715 Bug ID: 90715 Summary: ICE: tree check: expected private or shared or firstprivate or lastprivate or reduction or task_reduction or in_reduction or copyin or copyprivate or linear, have gt_expr in cxx_omp_clause_default_ctor, at cp/cp-gimplify.c:1935 Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: ice-on-valid-code, openmp Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- g++-10.0.0-alpha20190602 snapshot (r271848) ICEs when compiling gcc/testsuite/gcc.dg/vect/vect-simd-[67].c w/ -fopenmp: % g++-10.0.0-alpha20190602 -fopenmp -c gcc/testsuite/gcc.dg/vect/vect-simd-6.c during GIMPLE pass: omplower gcc/testsuite/gcc.dg/vect/vect-simd-6.c: In function 'int foo(int*)': gcc/testsuite/gcc.dg/vect/vect-simd-6.c:12:11: internal compiler error: tree check: expected private or shared or firstprivate or lastprivate or reduction or task_reduction or in_reduction or copyin or copyprivate or linear, have bit_ior_expr in cxx_omp_clause_default_ctor, at cp/cp-gimplify.c:1935 12 | #pragma omp simd lastprivate (conditional: x) | ^~~ 0x7c2b37 omp_clause_range_check_failed(tree_node const*, char const*, int, char const*, omp_clause_code, omp_clause_code) /var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190602/work/gcc-10-20190602/gcc/tree.c:10042 0x5cbd64 omp_clause_range_check(tree_node*, omp_clause_code, omp_clause_code, char const*, int, char const*) /var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190602/work/gcc-10-20190602/gcc/tree.h:3352 0x5cbd64 cxx_omp_clause_default_ctor(tree_node*, tree_node*, tree_node*) /var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190602/work/gcc-10-20190602/gcc/cp/cp-gimplify.c:1935 0xe4a8ca lower_rec_input_clauses /var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190602/work/gcc-10-20190602/gcc/omp-low.c:4770 0xe52fbb lower_omp_for /var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190602/work/gcc-10-20190602/gcc/omp-low.c:8588 0xe43f9b lower_omp_1 /var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190602/work/gcc-10-20190602/gcc/omp-low.c:10684 0xe43f9b lower_omp /var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190602/work/gcc-10-20190602/gcc/omp-low.c:10859 0xe43f41 lower_omp_1 /var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190602/work/gcc-10-20190602/gcc/omp-low.c:10668 0xe43f41 lower_omp /var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190602/work/gcc-10-20190602/gcc/omp-low.c:10859 0xe43f41 lower_omp_1 /var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190602/work/gcc-10-20190602/gcc/omp-low.c:10668 0xe43f41 lower_omp /var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190602/work/gcc-10-20190602/gcc/omp-low.c:10859 0xe48fcb execute_lower_omp /var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190602/work/gcc-10-20190602/gcc/omp-low.c:10901 0xe48fcb execute /var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190602/work/gcc-10-20190602/gcc/omp-low.c:10948
[Bug ipa/24729] function calls created by builtins do not make use of inline definitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24729 Eric Gallager changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=17402 --- Comment #10 from Eric Gallager --- (In reply to Kaveh Ghazi from comment #2) > I'm not convinced it's the same issue. With regard to 17402, comment #6 by > Joseph there refers specifically to static inlines in that builtins > shouldn't generate calls to "file-scope statics". However in my case glibc > is instantiating *extern inlines* and it seems legitimate that gcc could > (should) generate calls which take advantage of them. (Plus they're much > much faster!) While they may be different, it still seems related enough to go under "See Also"
[Bug middle-end/32503] __builtin_powi - optimize for other exponents besides 2 and 0.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32503 --- Comment #4 from Eric Gallager --- (In reply to Richard Biener from comment #2) > Confirmed. I had done tree-level expansion of powi into add/mul sequences at > one time. But this had been rejected for some reason I cannot remember > right now. Do you at least remember when that time was, so we can know where to go looking in the archives?
[Bug c++/26989] C++ front-end (and others parts of GCC) use the wrong check to see if hidden visibility is there
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26989 Eric Gallager changed: What|Removed |Added CC||dje at gcc dot gnu.org --- Comment #6 from Eric Gallager --- (In reply to Andrew Pinski from comment #0) > As reported over here: > http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01428.html cc-ing David Edelsohn from that thread
[Bug target/89750] Wrong code for _mm_comi_round_ss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89750 --- Comment #3 from liuhongt at gcc dot gnu.org --- Author: liuhongt Date: Mon Jun 3 02:20:33 2019 New Revision: 271853 URL: https://gcc.gnu.org/viewcvs?rev=271853=gcc=rev Log: 2019-05-06 H.J. Lu Hongtao Liu PR target/89750 PR target/86444 * config/i386/i386-expand.c (ix86_expand_sse_comi_round): Modified, original implementation isn't correct. 2019-05-06 H.J. Lu Hongtao Liu PR target/89750 PR target/86444 * gcc.target/i386/avx512f-vcomisd-2.c: New. * gcc.target/i386/avx512f-vcomisd-2.c: Likewise. Added: trunk/gcc/testsuite/gcc.target/i386/avx512f-vcomisd-2.c trunk/gcc/testsuite/gcc.target/i386/avx512f-vcomiss-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386-expand.c trunk/gcc/testsuite/ChangeLog
[Bug target/86444] [X86] Implementation of SSE comi/ucomi intrinsics does not match recent versions of icc, clang, or MSVC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86444 --- Comment #2 from liuhongt at gcc dot gnu.org --- Author: liuhongt Date: Mon Jun 3 02:20:33 2019 New Revision: 271853 URL: https://gcc.gnu.org/viewcvs?rev=271853=gcc=rev Log: 2019-05-06 H.J. Lu Hongtao Liu PR target/89750 PR target/86444 * config/i386/i386-expand.c (ix86_expand_sse_comi_round): Modified, original implementation isn't correct. 2019-05-06 H.J. Lu Hongtao Liu PR target/89750 PR target/86444 * gcc.target/i386/avx512f-vcomisd-2.c: New. * gcc.target/i386/avx512f-vcomisd-2.c: Likewise. Added: trunk/gcc/testsuite/gcc.target/i386/avx512f-vcomisd-2.c trunk/gcc/testsuite/gcc.target/i386/avx512f-vcomiss-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386-expand.c trunk/gcc/testsuite/ChangeLog
[Bug libgcc/90714] New: ia64: relocation truncated to fit: GPREL22
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90714 Bug ID: 90714 Summary: ia64: relocation truncated to fit: GPREL22 Product: gcc Version: 8.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: jason.duerstock at gmail dot com Target Milestone: --- From https://buildd.debian.org/status/fetch.php?pkg=libphonenumber=ia64=7.1.0-5=1558366217=0 [ 94%] Linking CXX shared library libgeocoding.so /usr/bin/ld: CMakeFiles/geocoding-shared.dir/src/phonenumbers/geocoding/area_code_map.cc.o: in function `__static_initialization_and_destruction_0(int, int)': area_code_map.cc:(.text+0xdc1): relocation truncated to fit: GPREL22 against symbol `__dso_handle' defined in .data section in /usr/lib/gcc/ia64-linux-gnu/8/crtbeginS.o /usr/bin/ld: final link failed: symbol needs debug section which does not exist collect2: error: ld returned 1 exit status A proposed patch was posted to gcc-patches: https://gcc.gnu.org/ml/gcc-patches/2019-06/msg00021.html
[Bug target/52731] internal compiler error: in ia64_st_address_bypass_p, at config/ia64/ia64.c:9357
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52731 Jason Duerstock changed: What|Removed |Added CC||jason.duerstock at gmail dot com --- Comment #2 from Jason Duerstock --- I just tested this against 8.3.0 and it does not occur.
[Bug bootstrap/90653] --with-build-sysroot= not honored for ./configure C compiler checks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90653 Alexander von Gluck changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #7 from Alexander von Gluck --- This one is 100% on us. Pretty much we have a variable which gets potentially injected into library search paths (secondary architectures) It's templated out in makefile.in as @SECONDARY_ARCH@. Well, lo-and-behold, we forgot to update configure.ac with the code which templates it out when porting our patches to gcc 8. Thus SECONDARY_ARCH = "@SECONDARY_ARCH@" is defined and gets injected into our library search paths as literally /boot/system/develop/lib/@SECONDARY_ARCH@/... Doh! It was pretty hard to spot since it didn't show up in the specs until I was playing around with injecting the STANDARD_STARTFILE_PREFIX_1 into specs. Sorry for the spam. I wish we could get this stuff upstream to avoid silly issues like that, but we don't have the man-power to write tests at the moment.
[Bug libfortran/77278] Use LTO for libgfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
--- Comment #6 from Thomas Koenig ---
So, I played around with this a little. By putting in
-flto and -ffat-lto-binaries into CFLAGS, FFLAGS and LDFLAGS
into the Makefile in the libgfortran build directory, it is
possible to build an LTO-enabled libgfortran.
For the first test (write.f90 from comment#1 below), a small
patch
Index: io/open.c
===
--- io/open.c (Revision 271843)
+++ io/open.c (Arbeitskopie)
@@ -740,6 +740,7 @@ st_open (st_parameter_open *opp)
GFC_INTEGER_4 cf = opp->common.flags;
unit_convert conv;
+ memset (, 0, sizeof(flags));
library_start (>common);
/* Decode options. */
led to a lot of conditional code not being pulled into the
main program. So far, so good - constant folding for open
was good.
The main function then became (in the optimized tree dump)
[local count: 10737418]:
open_parm.0.common.filename = &"write.f90"[1]{lb: 1 sz: 1};
open_parm.0.common.line = 5;
open_parm.0.file = &"foo.bar"[1]{lb: 1 sz: 1};
open_parm.0.file_len = 7;
open_parm.0.readonly = 0;
MEM[(int *)_parm.0] = 42966450432;
st_open.constprop (_parm.0);
open_parm.0 ={v} {CLOBBER};
# DEBUG i => 1
[local count: 1063004407]:
# ivtmp_27 = PHI <1000(2), ivtmp_1(3)>
# DEBUG i => NULL
_gfortran_random_r8 ();
dt_parm.1.common.filename = &"write.f90"[1]{lb: 1 sz: 1};
dt_parm.1.common.line = 8;
dt_parm.1.advance = &"NO"[1]{lb: 1 sz: 1};
dt_parm.1.format = &"(E17.8,\" \")"[1]{lb: 1 sz: 1};
MEM[(long int *)_parm.1 + 88B] = { 11, 2 };
MEM[(int *)_parm.1] = 42949685248;
st_write.constprop (_parm.1);
transfer_real_write.constprop (_parm.1, );
st_write_done (_parm.1);
dt_parm.1 ={v} {CLOBBER};
# DEBUG i => NULL
ivtmp_1 = ivtmp_27 + 4294967295;
if (ivtmp_1 == 0)
goto ; [1.01%]
else
goto ; [98.99%]
[local count: 10737418]:
a ={v} {CLOBBER};
return;
}
So, dt_parm_1 is still filled with information in the tight loop
(which the library does not change), and the call to
transfer_real_write.constprop does not do a lot of the things
that could be done in theory, for example keeping the unit
number cached, take a note that this is not asynchronous,
that we always use "NO" on advance in the loop, etc.
So, is it realistic to expect that LTO could do this kind
of thing with the very complex structure that libgfortran?
[Bug middle-end/90713] New: [10 regression] FAIL: gcc.dg/gimplefe-40.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90713 Bug ID: 90713 Summary: [10 regression] FAIL: gcc.dg/gimplefe-40.c (internal compiler error) Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: sch...@linux-m68k.org CC: rguenth at gcc dot gnu.org Target Milestone: --- Target: powerpc64-*-* Configured with: ../configure --prefix=/usr --build=powerpc64-suse-linux --enable-checking=release --enable-shared --with-system-zlib CFLAGS='-O2 -g' CXXFLAGS='-O2 -g' --with-cpu-64=power4 --enable-secureplt --with-long-double-128 /daten/gcc/gcc-20190601/Build/gcc/xgcc -B/daten/gcc/gcc-20190601/Build/gcc/ /daten/gcc/gcc-20190601/gcc/testsuite/gcc.dg/gimplefe-40.c -m64 -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fgimple -Wno-psabi -w -S -o gimplefe-40.s during RTL pass: expand /daten/gcc/gcc-20190601/gcc/testsuite/gcc.dg/gimplefe-40.c: In function 'load': /daten/gcc/gcc-20190601/gcc/testsuite/gcc.dg/gimplefe-40.c:6:1: internal compiler error: in emit_move_insn, at expr.c:3756 0x103fe1c7 emit_move_insn(rtx_def*, rtx_def*) ../../gcc/expr.c:3756 0x1040df4f expand_expr_real_2(separate_ops*, rtx_def*, machine_mode, expand_modifier) ../../gcc/expr.c:9732 0x102ab537 expand_gimple_stmt_1 ../../gcc/cfgexpand.c:3802 0x102ab537 expand_gimple_stmt ../../gcc/cfgexpand.c:3863 0x102b1547 expand_gimple_basic_block ../../gcc/cfgexpand.c:5899 0x102b3e87 execute ../../gcc/cfgexpand.c:6522
[Bug target/90712] New: [10 regression] gcc.dg/rtl/aarch64/subs_adds_sp.c fails with ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90712 Bug ID: 90712 Summary: [10 regression] gcc.dg/rtl/aarch64/subs_adds_sp.c fails with ICE Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- Hi, Somewhere between r271733 and r271780, the test gcc.dg/rtl/aarch64/subs_adds_sp.c started to fail with an ICE: /gcc/testsuite/gcc.dg/rtl/aarch64/subs_adds_sp.c: In function 'adds': /gcc/testsuite/gcc.dg/rtl/aarch64/subs_adds_sp.c:36:1: internal compiler error: in aarch64_return_address_signing_enabled, at config/aarch64/aarch64.c:4865 0xfc24d3 aarch64_return_address_signing_enabled() /gcc/config/aarch64/aarch64.c:4865 0xfc2500 aarch64_post_cfi_startproc(_IO_FILE*, tree_node*) /gcc/config/aarch64/aarch64.c:15373 0x81d338 dwarf2out_do_cfi_startproc /gcc/dwarf2out.c:972 0x83a00e dwarf2out_begin_prologue(unsigned int, unsigned int, char const*) /gcc/dwarf2out.c:1106 0x8d6c6f final_start_function_1 /gcc/final.c:1738 0x8d732b rest_of_handle_final /gcc/final.c:4658 0x8d732b execute /gcc/final.c:4737 Please submit a full bug report, r271735 was causing the GCC builds to fail, and was fixed as r271780, so this regression was hidden in-between.
[Bug middle-end/82853] Optimize x % 3 == 0 without modulo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82853 --- Comment #35 from Orr Shalom Dvory --- Hi, thanks for your respond. can someone mark this bug as need to be improved? Does anyone agree/disagree with my new proposed method?
[Bug tree-optimization/90710] Bogus Wmaybe-uninitialized caused by __builtin_expect when compiled with -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90710 --- Comment #2 from sagebar at web dot de --- (In reply to Jeffrey A. Law from comment #1) > We focus most of our effort on avoiding false positives with -O2 > optimization levels. As you lower the optimization level (-Og) you will > almost certainly run into these kinds of issues. > > Elimination of false positive uninitialized warnings is highly dependent > upon what we call "jump threading". The purpose of jump threading is to > realize that certain paths through the CFG are not possible and to use block > copying to isolate and remove those paths. At lower optimization levels the > compiler does not aggressively thread jumps and thus can leave unexecutable > paths in the CFG which leads to the false positive warning. > > The use of builtin_expect can have these effects too as it impacts the cost > analysis done during jump threading to determine the cost/benefit of block > copying to isolate the path. > > > So confirmed, but not likely something we'll fix in the near future. Thanks for taking the time to explain the what-s and why-s. Dealing with a long-time -O3-compiled codebase (always having optimizations at max prevents nasty surprises later), I was originally trying to use -Og to improve the quality of .debug_info for gdb (I read somewhere that that -Og's supposed to be used for), but for anyone else that has the same Problem and finds this, I managed to get it to work well enough by simply not passing any -O* flags for the time being.
[Bug libfortran/77278] Use LTO for libgfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
--- Comment #5 from Thomas Koenig ---
One thing we would also have to tackle is GFC_LOGICAL arguments.
C only has one bool type, which is (for gcc) equivalent to
logical(kind=1). We might just get by with
typedef enum { _zero=1, _one=1 } GFC_LOGICAL_4;
but what about arguments with other logical types?
We might actually need a C extension there, or disable
aliasing-based optimization.
[Bug tree-optimization/90710] Bogus Wmaybe-uninitialized caused by __builtin_expect when compiled with -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90710 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-06-02 CC||law at redhat dot com Ever confirmed|0 |1 --- Comment #1 from Jeffrey A. Law --- We focus most of our effort on avoiding false positives with -O2 optimization levels. As you lower the optimization level (-Og) you will almost certainly run into these kinds of issues. Elimination of false positive uninitialized warnings is highly dependent upon what we call "jump threading". The purpose of jump threading is to realize that certain paths through the CFG are not possible and to use block copying to isolate and remove those paths. At lower optimization levels the compiler does not aggressively thread jumps and thus can leave unexecutable paths in the CFG which leads to the false positive warning. The use of builtin_expect can have these effects too as it impacts the cost analysis done during jump threading to determine the cost/benefit of block copying to isolate the path. So confirmed, but not likely something we'll fix in the near future.
[Bug c++/90711] Failing SFINAE from unrelated struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90711
--- Comment #1 from David Hunt ---
Self-contained :
---
namespace test {
void EXISTS(int);
}
template
struct stub_void {
typedef void type;
};
template
using stub_void_t = typename stub_void::type;
#if !defined(SUPPRESS)
template
struct has_to_string {
static constexpr bool value = false;
};
template
struct has_to_string> {
static constexpr bool value = true;
};
#endif
template
struct has_std_to_string {
static constexpr bool value = false;
};
template
struct has_std_to_string> {
static constexpr bool value = true;
};
int main(int argc, char *argv[]) {
return has_std_to_string::value;
}
---
[Bug c++/90711] New: Failing SFINAE from unrelated struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90711
Bug ID: 90711
Summary: Failing SFINAE from unrelated struct
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: da_cra_hunt at yahoo dot com
Target Milestone: ---
Created attachment 46443
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46443=edit
Temporary from error case
I've run into a strange situation where a nominally unrelated type using
detection with void_t causes a change in the behavior of a second type :
---
dhunt@eoan-vm:/tmp$ cat lk.cpp
#include
#include
#include
#if !defined(SUPPRESS)
template
struct has_to_string : public std::false_type {};
template
struct has_to_string()))>> : public std::true_type {};
#endif
template
struct has_std_to_string : public std::false_type {};
template
struct has_std_to_string()))>> : public std::true_type {};
int main(int argc, char *argv[]) {
#if 0
to_string(90);
std::to_string(90);
#endif
std::cout << "int : " << has_std_to_string::value << std::endl;
}
dhunt@eoan-vm:/tmp$ g++-9 -std=c++17 -DSUPPRESS ./lk.cpp ; ./a.out
int : 1
dhunt@eoan-vm:/tmp$ g++-9 -std=c++17 ./lk.cpp ; ./a.out
int : 0
dhunt@eoan-vm:/tmp$ g++-9 -v
Using built-in specs.
COLLECT_GCC=g++-9
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 9.1.0-2ubuntu2'
--with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-9
--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 --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--with-target-system-zlib=auto --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 9.1.0 (Ubuntu 9.1.0-2ubuntu2)
---
The above OS is a VirtualBox VM running the Ubuntu Nightly Server from
2019-05-25. I'm not making any claims that the above is the right way to
implement; it is simply meant to illustrate the behavior.
ALSO PRODUCES "int : 0": godbolt gcc trunk (20190601), gobolt gcc 9.1
PRODUCES "int : 1": Ubuntu Bionic gcc 7.4, godbolt gcc 8.3, godblot clang
trunk, godbolt clang 8.0.0, godbolt clang 7.0.0
[Bug tree-optimization/90710] New: Bogus Wmaybe-uninitialized caused by __builtin_expect when compiled with -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90710
Bug ID: 90710
Summary: Bogus Wmaybe-uninitialized caused by __builtin_expect
when compiled with -Og
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: sagebar at web dot de
Target Milestone: ---
Created attachment 46442
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46442=edit
Copy of the code already contained in the description
Use of `__builtin_expect()` within `testFunction()` below causes a warning to
be falsely emit when compiled as `gcc -Og -Wall test.c':
```
test.c: In function 'testfunction':
test.c:22:3: warning: 'value' may be used uninitialized in this function
[-Wmaybe-uninitialized]
22 | printf("My if() causes -Wmaybe-uninitialized for my use of `value':
%d\n",value);
|
^~~~
/
```
Code (`test.c`):
```
#include
/* A simple store-value-in-pointer-or-return-error function */
static __inline__ __attribute__((__always_inline__))
unsigned int getValueIfNotZero(unsigned int value, unsigned int *result) {
if (value == 0)
goto err;
*result = value;
return 1;
err:
return 0;
}
__attribute__((__noinline__)) void
testFunction(void) {
volatile unsigned int x = 1;
unsigned int value;
int was_ok = getValueIfNotZero(x, );
if (was_ok)
printf("My if() compiles fine: %d\n",value);
if (__builtin_expect(was_ok, 1))
printf("My if() causes -Wmaybe-uninitialized for my use of
`value': %d\n",value);
}
```
This problem seems to be related to the `-Og` flag, as I was unable to
reproduce it with `-O[0-4]`
I can personally confirm this warning being emit the same way with:
- i686-pc-cygwin-gcc.exe (gcc version 6.4.0)
- i686-elf-gcc.exe(gcc version 9.1.0)
I can only assume that this also affects all versions between these two
My host is a windows 10 machine and I'm using cygwin to run GCC
[Bug fortran/90539] [10 Regression] 481.wrf slowdown by 25% on Intel Kaby with -Ofast -march=native starting with r271377
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539 --- Comment #50 from Thomas Koenig --- Author: tkoenig Date: Sun Jun 2 15:18:22 2019 New Revision: 271844 URL: https://gcc.gnu.org/viewcvs?rev=271844=gcc=rev Log: 2019-06-02 Thomas Koenig PR fortran/90539 * trans-expr.c (gfc_conv_subref_array_arg): If the size of the expression can be determined to be one, treat it as contiguous. Set likelyhood of presence of an actual argument according to PRED_FORTRAN_ABSENT_DUMMY and likelyhood of being contiguous according to PRED_FORTRAN_CONTIGUOUS. 2019-06-02 Thomas Koenig PR fortran/90539 * predict.def (PRED_FORTRAN_CONTIGUOUS): New predictor. 2019-06-02 Thomas Koenig PR fortran/90539 * gfortran.dg/internal_pack_24.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/internal_pack_24.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/predict.def trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/90704] filesystem::path overloads for file streams are not conforming
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90704 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-06-02 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Target Milestone|--- |10.0 Ever confirmed|0 |1
