[Bug libstdc++/86292] Missing exception safety when constructing vector from input iterator pair
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86292 Jonathan Wakely changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2018-06-24 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- Ouch. We use push_back in a loop, but because we're still in the constructor if an exception occurs we don't run the destructor.
[Bug c++/86256] Lambda will not add ref count for class intelligent pointer member when capture 'this' or & as argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86256 Jonathan Wakely changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #3 from Jonathan Wakely --- But this is true for any lambda that captured 'this' or captures by reference. It doesn't make sense to warn for every use of that language feature, just in case it's used incorrectly.
[Bug fortran/82009] [F08] ICE with block construct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82009
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Comment #5 from Jerry DeLisle ---
This seems on the verge of silly. The ICE is at an assert:
assert (saved_local_decls == NULL_TREE);
When the function gfc_process_block_locals concludes it does
saved_local_decls = NULL_TREE;
So as I looked at this I thought it is expected to be already set at NULL_TREE
and it leaves it that way. Why not just set it instead of doing the assert.
So I did this:
diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
index 254768c5828..08c1ebd2d4b 100644
--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -6751,7 +6751,7 @@ gfc_process_block_locals (gfc_namespace* ns)
{
tree decl;
- gcc_assert (saved_local_decls == NULL_TREE);
+ saved_local_decls = NULL_TREE;
has_coarray_vars = false;
generate_local_vars (ns);
The problem goes away and it regression tests fine.
saved_local_decls is used only in one other place where it is set in
add_decl_as_local(). It is not reset anywhere else. So I think the pacth above
is likely correct.
[Bug fortran/85983] ICE in check_dtio_interface1, at fortran/interface.c:4748
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85983 Jerry DeLisle changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jerry DeLisle --- Fixed on trunk.
[Bug fortran/85983] ICE in check_dtio_interface1, at fortran/interface.c:4748
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85983 --- Comment #3 from Jerry DeLisle --- Author: jvdelisle Date: Sun Jun 24 04:09:20 2018 New Revision: 261994 URL: https://gcc.gnu.org/viewcvs?rev=261994&root=gcc&view=rev Log: 2018-06-23 Jerry DeLisle PR fortran/85983 * interface.c (check_dtio_interface1): Delete assert. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/interface.c
[Bug c++/86256] Lambda will not add ref count for class intelligent pointer member when capture 'this' or & as argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86256 --- Comment #2 from kangchuanbo at 126 dot com --- Once Lamdba capture this ( one class instance which have std::shared_ptr<> member), the std::shared_ptr member will not increase ref count inside Lambda body, this is dangerous, once this member has been freed, the Lambda body will access null pointer. At 2018-06-21 19:47:22, "redi at gcc dot gnu.org" wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86256 > >Jonathan Wakely changed: > > What|Removed |Added > > Status|UNCONFIRMED |WAITING > Last reconfirmed||2018-06-21 > Ever confirmed|0 |1 > >--- Comment #1 from Jonathan Wakely --- >N.B. GCC 5.4 is no longer supported or maintained. > >I don't understand your bug report, GCC is compiling the code correctly. > >What do you think should happen? > >-- >You are receiving this mail because: >You reported the bug.
[Bug fortran/78718] ICE in gfc_get_symbol_decl, at fortran/trans-decl.c:1427
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78718 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #4 from kargl at gcc dot gnu.org --- (In reply to Jim MacArthur from comment #1) > Confirmed on latest trunk (x8664). Looks like it has the wrong namespace > when trying to find 'z'. I'm looking into it. I haven't looked at gdb output or namespaces, yet. Do note that the 'z' in the program unit 'p' is a distinct entity from the 'z' that appears in the RESULT clause in the function declaration. Adding IMPLICIT NONE to the program 'p' gives a.f90:6:28: function f() result(z) 1 Error: Function result 'z' at (1) has no IMPLICIT type or locally declaring 'z' in function 'f' allows the code to compile. In short, the local 'z' should block the host association of the 'z' from 'p'.
[Bug fortran/82009] [F08] ICE with block construct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82009 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 --- Comment #4 from kargl at gcc dot gnu.org --- (In reply to Valery Weber from comment #0) > hi all > > the following code is ICEing with gcc 7.2.0 > > thanks > > v > > cat sparse_matrix_csx_benchmark_utils.F90 > MODULE sparse_matrix_csx_benchmark_utils > IMPLICIT NONE > CONTAINS > SUBROUTINE sparse_matrix_csr_benchmark ( ) > WRITE(*,*) 'At*x: t' > block > integer, dimension(1), parameter :: idxs=[1] > integer :: i, idx > do i = 1, size(idxs) > idx = idxs(i) > enddo > end block > END SUBROUTINE sparse_matrix_csr_benchmark > SUBROUTINE sparse_matrix_csc_benchmark ( ) > WRITE(*,*) 'An*x: t' > block > integer, dimension(1), parameter :: idxs=[1] > integer :: i, idx > do i = 1, size(idxs) > idx = idxs(i) > enddo > end block > END SUBROUTINE sparse_matrix_csc_benchmark > END MODULE sparse_matrix_csx_benchmark_utils This one is weird. If I move the 2nd WRITE in sparse_matrix_csr_benchmark to after the BLOCK constructor, the code compiles. If I leave the 2nd WRITE in its current location, and comment out the 1st WRITE statement in sparse_matrix_csr_benchmark, I still get the ICE. I'm perplexed!
[Bug fortran/82009] [F08] ICE with block construct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82009 --- Comment #3 from kargl at gcc dot gnu.org --- (In reply to kargl from comment #2) > (In reply to janus from comment #1) > > Confirmed. ICEs with every gfortran version I tried, from 4.7 up to trunk. > > > > Slight reduction: > > > > MODULE csx > > IMPLICIT NONE > > CONTAINS > > SUBROUTINE csr > > block > > end block > > END > > SUBROUTINE csc > > WRITE(*,*) 'An*x: t' > > block > > integer, dimension(1), parameter :: idxs=[1] > > print *, idxs(1) > > end block > > END > > END > > The above code compiles for me on trunk (gcc version 9.0.0 20180609) Original testcase still causes an ICE.
[Bug fortran/82009] [F08] ICE with block construct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82009 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #2 from kargl at gcc dot gnu.org --- (In reply to janus from comment #1) > Confirmed. ICEs with every gfortran version I tried, from 4.7 up to trunk. > > Slight reduction: > > MODULE csx > IMPLICIT NONE > CONTAINS > SUBROUTINE csr > block > end block > END > SUBROUTINE csc > WRITE(*,*) 'An*x: t' > block > integer, dimension(1), parameter :: idxs=[1] > print *, idxs(1) > end block > END > END The above code compiles for me on trunk (gcc version 9.0.0 20180609)
[Bug fortran/82313] Rejects-valid for sum(minloc(...))) as array dimension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82313 kargl at gcc dot gnu.org changed: What|Removed |Added Keywords|rejects-valid | Priority|P3 |P4 Status|NEW |WAITING Severity|normal |minor --- Comment #3 from kargl at gcc dot gnu.org --- Removed rejects-valid. The code is invalid. 1 2 34 5 5 4 3 2 integer y( ( sum ( minloc ( (/1/) ) ) ) end
[Bug fortran/82313] Rejects-valid for sum(minloc(...))) as array dimension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82313 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #2 from kargl at gcc dot gnu.org --- (In reply to Thomas Koenig from comment #0) > This is a spin-off from PR 54633. > > integer y((sum(minloc((/1/ > end > > is rejected with the (IMHO misleading) error message > >integer y((sum(minloc((/1/ > 1 > Error: Expected another dimension in array declaration at (1) Why do you think it is misleading? You have essentially integer y(1 gfortran cannot tell if you meant y(1) or y(1,2) or y(1,2,3) or etc. I suppose one could change the error message to Error: Expected another dimension or right parenthesis in array declaration at 1 There are two locations where this error message can orginate. Feel free to adopt my proposed message, commit a 'fix', and close the PR.
[Bug libitm/86294] New: comparison is always true due to limited range of data type [-Werror=type-limits]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86294
Bug ID: 86294
Summary: comparison is always true due to limited range of data
type [-Werror=type-limits]
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libitm
Assignee: unassigned at gcc dot gnu.org
Reporter: um at mutluit dot com
Target Milestone: ---
If warnings are treated as error (I think that's the default, or gets
implicitly activated if -Wall -Wextra has been given), then if
-Wno-error=type-limits has not been defined, then the following error gets
reported and the build aborts:
../../../gcc_trunk/libitm/method-ml.cc: In member function 'virtual bool
{anonymous}::ml_wt_dispatch::supports(unsigned int)':
../../../gcc_trunk/libitm/method-ml.cc:650:35: error: comparison is always true
due to limited range of data type [-Werror=type-limits]
return (number_of_threads * 2 <= ml_mg::OVERFLOW_RESERVE);
~~^~~~
[Bug libitm/86293] New: unused variable left over (used in assert) when building with -g0 -DNDEBUG [-Werror=unused-variable]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86293 Bug ID: 86293 Summary: unused variable left over (used in assert) when building with -g0 -DNDEBUG [-Werror=unused-variable] Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libitm Assignee: unassigned at gcc dot gnu.org Reporter: um at mutluit dot com Target Milestone: --- when building the languages=c,c++ with "-g0 -DNDEBUG", then the following error happens: ../../../gcc_trunk/libitm/method-serial.cc: In member function 'void GTM::gtm_thread::serialirr_mode()': ../../../gcc_trunk/libitm/method-serial.cc:309:12: error: unused variable 'ok' [-Werror=unused-variable] bool ok = disp->trycommit (priv_time); ^~ Of course one can get rid of it by giving also -Wno-error=unused-variable. Hints for fixing: As the variable gets used only in an assert statement, then the variable definition should have "__attribute__((unused))" added: bool ok __attribute__((unused)) = disp->trycommit (priv_time);
[Bug libstdc++/86292] New: Missing exception safety when constructing vector from input iterator pair
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86292 Bug ID: 86292 Summary: Missing exception safety when constructing vector from input iterator pair Product: gcc Version: 8.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: kristian.spangsege at gmail dot com Target Milestone: --- Created attachment 44316 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44316&action=edit Code to trigger the bug When constructing a `std::vector` from a pair of input iterators (`std::input_iterator_tag`), and the copy constructor for the value type throws, already constructed copies will never be destroyed. I.e., the mentioned vector constructor is not exception safe under these circumstances. See the attached code for a way to trigger and reveal the problem. The expectation is that it should output `0` (no instances of `X` remain at exit), but it outputs `1`, meaning that one `X` object was leaked. I tried this with GCC version 8.0.1 and 5.5.0 on Linux Mint 18.1.
[Bug fortran/71565] INTENT(IN) polymorphic argument with pointer components - reject valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71565 --- Comment #3 from Jürgen Reuter --- Sorry, in ifort this got fixed in the meanwhile. Only gfortran rejects this code still.
[Bug fortran/71565] INTENT(IN) polymorphic argument with pointer components - reject valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71565 Jürgen Reuter changed: What|Removed |Added CC||juergen.reuter at desy dot de --- Comment #2 from Jürgen Reuter --- This is still present in the actual trunk, and also still present in the ifort compiler. The NAG compiler compiles the example without problem.
[Bug tree-optimization/84841] [7 Regression] ICE: tree check: expected ssa_name, have real_cst in rewrite_expr_tree_parallel, at tree-ssa-reassoc.c:4624
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84841 Arseny Solokha changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Arseny Solokha --- Fix committed by Jakub to all affected branches.
[Bug middle-end/85989] [6 Regression] Incorrect result for example involving unary minus in a loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85989 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from rsandifo at gcc dot gnu.org --- Now fixed on all active branches. Thanks for reporting the bug.
[Bug middle-end/85989] [6 Regression] Incorrect result for example involving unary minus in a loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85989 --- Comment #8 from rsandifo at gcc dot gnu.org --- Author: rsandifo Date: Sat Jun 23 16:18:36 2018 New Revision: 261985 URL: https://gcc.gnu.org/viewcvs?rev=261985&root=gcc&view=rev Log: Fix phi backedge detection in backprop (PR85989) Backport trunk r261064. 2018-06-23 Richard Sandiford gcc/ PR tree-optimization/85989 * gimple-ssa-backprop.c (backprop::m_visited_phis): New member variable. (backprop::backprop): Initialize it. (backprop::~backprop): Free it. (backprop::intersect_uses): Check it when deciding whether this is a backedge reference. (backprop::process_block): Add each phi to m_visited_phis after visiting it, then clear it at the end. gcc/testsuite/ PR tree-optimization/85989 * gcc.dg/torture/pr85989.c: New test. Added: branches/gcc-6-branch/gcc/testsuite/gcc.dg/torture/pr85989.c Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/gimple-ssa-backprop.c branches/gcc-6-branch/gcc/testsuite/ChangeLog
[Bug libgomp/86291] New: OpenMP incorrect for-loop collapsing with iterators and at least 5 nested loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86291 Bug ID: 86291 Summary: OpenMP incorrect for-loop collapsing with iterators and at least 5 nested loops Product: gcc Version: 8.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: bonjour at matteodelabre dot me CC: jakub at gcc dot gnu.org Target Milestone: --- Created attachment 44315 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44315&action=edit Preprocessor output When collapsing at least 5 nested for loops with the collapse() clause in a `for` pragma, the body of the loop never executes. In the testcase, 5 for loops on trivial iterators are nested. These iterators only yield one value, such that the innermost statement should execute exactly once. When compiled without the -fopenmp flag, the program exhibits correct behaviour and we see one line printed on standard output. When compiled with the -fopenmp flag, the body of the loop never executes and the output stays blank. This only happens when all of the loop variables are iterators and there is at least 5 levels of nesting. If any of the loops is changed to operate on non-iterator values (such as plain integers) or if the nesting is reduced below 5 levels, the statement executes. g++ -v info: Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/8.1.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --enable-libmpx --with-system-zlib --with-isl --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --enable-gnu-indirect-function --enable-multilib --disable-werror --enable-checking=release --enable-default-pie --enable-default-ssp Thread model: posix gcc version 8.1.1 20180531 (GCC)
[Bug fortran/86281] [9 regression] SEGV in fortran/resolve.c:resolve_function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86281 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #8 from Jerry DeLisle --- (In reply to Paul Thomas from comment #6) > Hi Rainer and Steve, > > I don't know how this got past my regtesting... > We have all done this. I do know that with a bit more git savvy it is possible to manage these multiple changes without doing things like save the diff, clear it off, etc, etc. I dont have that degree of savvy yet myself, but I have used git stash which allows you to "push" changes to a "stack" and pop them back off. etc etc etc. Cheers.
[Bug other/63630] ICE: in spill_failure, at reload1.c:2122. unable to find a register to spill in class 'POINTER_REGS'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63630 Eric Gallager changed: What|Removed |Added Summary|[5.0 Regression] ICE: in|ICE: in spill_failure, at |spill_failure, at |reload1.c:2122. unable to |reload1.c:2122. unable to |find a register to spill in |find a register to spill in |class 'POINTER_REGS' |class 'POINTER_REGS'| --- Comment #9 from Eric Gallager --- (In reply to Georg-Johann Lay from comment #7) > (In reply to Eric Gallager from comment #6) > > gcc-5 branch is closed; is this bug still valid for newer branches? > > Reload flaws are usually very "instable" w.r.t. to the test case(s) that > thrigger them. I really can't tell whether the artefact is still present on > source level or has already been fixed or been supersed by re-design. > > For a definite answer, one would have to analyse the issue with a gcc > version + test case that triggers the bug and then track the respective > source and how it changed in the remainder... (In reply to Georg-Johann Lay from comment #8) > (In reply to Eric Gallager from comment #6) > > gcc-5 branch is closed; is this bug still valid for newer branches? > > ...and for such "spill fails" it's impossible to tell, at least for me, > whether they are distinct issues or duplictes of each other. > > Even with newer versions of the compiler, some optimization issues might be > caused by too much spilling. At least that's what I'd infer from reading > .reload dumps. So there is still issues with spilling in newer versions, > even if they are no ICEs. > > Moreover, register selection if often not optimal. The old lreg / greg was > much smarter in that regard. OK, so I guess I'll leave this open and just remove the [5.0 regression] marker from the title then
[Bug fortran/71412] [F03] iso_c_bindings and optimization interaction bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71412 --- Comment #14 from relliott at umn dot edu --- It is great to see some life on this bug report. This is still an important issue for our project! Is there any chance of reviving the discussion and coming to a resolution?
[Bug c/86287] AddressSanitizer: heap-use-after-free on bootstrap with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86287
--- Comment #2 from David Binderman ---
Reduced C code is this:
typedef struct {
long a;
long b;
long c
} d;
typedef struct {
int dtype;
d dim[]
} e;
e f;
g;
h() {
for (; g; ++g)
f.dim[g].b = f.dim[g].c = f.dim[g].a = 1;
}
Command line is
$ /home/dcb/gcc/results/bin/gcc -c -O3 -w -B/home/dcb/gcc/working/./gcc/
-std=gnu11 bug448.c
==27410==ERROR: AddressSanitizer: heap-use-after-free on address 0x61122094
at pc 0x02920418 bp 0x7fff6e82be60 sp 0x7fff6e82be58
READ of size 4 at 0x61122094 thread T0
#0 0x2920417 in vect_transform_loop_stmt
../../trunk/gcc/tree-vect-loop.c:83
32
#1 0x2963d8c in vect_transform_loop(_loop_vec_info*)
../../trunk/gcc/tree-ve
ct-loop.c:8567
[Bug c/86287] AddressSanitizer: heap-use-after-free on bootstrap with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86287 --- Comment #1 from David Binderman --- Created attachment 44314 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44314&action=edit C source code The attached C code, when compiled with flag -O3, on a recent asan version of trunk seems to cause the problem.
[Bug c++/86190] [6/7/8/9 Regression] -Wsign-conversion ignores explicit conversion in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86190
Tony E Lewis changed:
What|Removed |Added
CC||TonyELewis at hotmail dot com
--- Comment #7 from Tony E Lewis ---
I just hit this one yesterday (and am now disappointed to have missed being
able to contribute a new valid bug report by just 5 days :) ).
Thanks for the work that's already gone into addressing this.
The repro can be reduced slightly further by removing the struct:
typedef unsigned long sz_t;
sz_t s();
void f(int i) { s() < static_cast( i ); }
[Bug middle-end/85989] [6/7 Regression] Incorrect result for example involving unary minus in a loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85989 --- Comment #7 from rsandifo at gcc dot gnu.org --- Author: rsandifo Date: Sat Jun 23 12:21:18 2018 New Revision: 261984 URL: https://gcc.gnu.org/viewcvs?rev=261984&root=gcc&view=rev Log: Fix phi backedge detection in backprop (PR85989) Backport trunk r261064. 2018-06-23 Richard Sandiford gcc/ PR tree-optimization/85989 * gimple-ssa-backprop.c (backprop::m_visited_phis): New member variable. (backprop::intersect_uses): Check it when deciding whether this is a backedge reference. (backprop::process_block): Add each phi to m_visited_phis after visiting it, then clear it at the end. gcc/testsuite/ PR tree-optimization/85989 * gcc.dg/torture/pr85989.c: New test. Added: branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr85989.c Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/gimple-ssa-backprop.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug middle-end/86284] Insert trap instruction in place of missing return statement on dodgy code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86284 --- Comment #1 from Marc Glisse --- -fsanitize=return ?
[Bug fortran/71412] [F03] iso_c_bindings and optimization interaction bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71412 Jürgen Reuter changed: What|Removed |Added CC||juergen.reuter at desy dot de --- Comment #13 from Jürgen Reuter --- Indeed I think that is a duplicate of pr71544. This here is definitely from the discussion on c.l.f. starting on June 6, 2016 under the title "Possible gfortran compiler optimization bug when dealing with c-style pointers", and the code in pr71544 is identical to the one posted there. The upshot of the discussion to me looks like that there was disagreement between Steve Kargl and Richard Maine whether the code is standard-conforming or not. I think, this is still not resolved.
[Bug libgcc/86290] New: Go cross build fails, "with libgcc_s.so.1 [...] not found"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86290 Bug ID: 86290 Summary: Go cross build fails, "with libgcc_s.so.1 [...] not found" Product: gcc Version: 7.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: daniel.santos at pobox dot com Target Milestone: --- Host: x86_64-pc-linux-gnu Target: mipsel-unknown-linux-gnu Created attachment 44313 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44313&action=edit full build log I actually need Go on a MIPS32 machine so I'm building a toolchain with Gentoo's crossdev (had to baby it some) and I ran into this error. I built it with gcc-5.4.0 because I forgot to switch out my system compiler, but we're past that at this point anyway. /tmp/portage/cross-mipsel-unknown-linux-gnu/gcc-7.3.0-r3/work/build/./gcc/gccgo -B/tmp/portage/cross-mipsel-unknown-linux-gnu/gcc-7.3.0-r3/work/build/./gcc/ -B/usr/mipsel-unknown-linux-gnu/bin/ -B/usr/mipsel-unknown-linux-gnu/lib/ -isystem /usr/mipsel-unknown-linux-gnu/include -isystem /usr/mipsel-unknown-linux-gnu/sys-include -g -O2 -minterlink-mips16 -static-libstdc++ -static-libgcc -Wl,-O1 -Wl,--as-needed -L ../mipsel-unknown-linux-gnu/libgo -L ../mipsel-unknown-linux-gnu/libgo/.libs -L ../mipsel-unknown-linux-gnu/libgcc -o cgo /tmp/portage/cross-mipsel-unknown-linux-gnu/gcc-7.3.0-r3/work/gcc-7.3.0/gotools/../libgo/go/cmd/cgo/ast.go /tmp/portage/cross-mipsel-unknown-linux-gnu/gcc-7.3.0-r3/work/gcc-7.3.0/gotools/../libgo/go/cmd/cgo/doc.go /tmp/portage/cross-mipsel-unknown-linux-gnu/gcc-7.3.0-r3/work/gcc-7.3.0/gotools/../libgo/go/cmd/cgo/gcc.go /tmp/portage/cross-mipsel-unknown-linux-gnu/gcc-7.3.0-r3/work/gcc-7.3.0/gotools/../libgo/go/cmd/cgo/godefs.go /tmp/portage/cross-mipsel-unknown-linux-gnu/gcc-7.3.0-r3/work/gcc-7.3.0/gotools/../libgo/go/cmd/cgo/main.go /tmp/portage/cross-mipsel-unknown-linux-gnu/gcc-7.3.0-r3/work/gcc-7.3.0/gotools/../libgo/go/cmd/cgo/out.go /tmp/portage/cross-mipsel-unknown-linux-gnu/gcc-7.3.0-r3/work/gcc-7.3.0/gotools/../libgo/go/cmd/cgo/util.go zdefaultcc.go /usr/libexec/gcc/mipsel-unknown-linux-gnu/ld: warning: libgcc_s.so.1, needed by ../mipsel-unknown-linux-gnu/libgo/.libs/libgo.so, not found (try using -rpath or -rpath-link) ../mipsel-unknown-linux-gnu/libgo/.libs/libgo.so: undefined reference to `_Unwind_RaiseException@GCC_3.0' ../mipsel-unknown-linux-gnu/libgo/.libs/libgo.so: undefined reference to `_Unwind_GetIPInfo@GCC_4.2.0' ../mipsel-unknown-linux-gnu/libgo/.libs/libgo.so: undefined reference to `_Unwind_GetTextRelBase@GCC_3.0' ../mipsel-unknown-linux-gnu/libgo/.libs/libgo.so: undefined reference to `_Unwind_Resume_or_Rethrow@GCC_3.3' ../mipsel-unknown-linux-gnu/libgo/.libs/libgo.so: undefined reference to `_Unwind_Resume@GCC_3.0' ../mipsel-unknown-linux-gnu/libgo/.libs/libgo.so: undefined reference to `_Unwind_SetGR@GCC_3.0' ../mipsel-unknown-linux-gnu/libgo/.libs/libgo.so: undefined reference to `_Unwind_SetIP@GCC_3.0' ../mipsel-unknown-linux-gnu/libgo/.libs/libgo.so: undefined reference to `_Unwind_GetRegionStart@GCC_3.0' ../mipsel-unknown-linux-gnu/libgo/.libs/libgo.so: undefined reference to `_Unwind_GetLanguageSpecificData@GCC_3.0' ../mipsel-unknown-linux-gnu/libgo/.libs/libgo.so: undefined reference to `_Unwind_GetDataRelBase@GCC_3.0' ../mipsel-unknown-linux-gnu/libgo/.libs/libgo.so: undefined reference to `_Unwind_Backtrace@GCC_3.3' collect2: error: ld returned 1 exit status The link succeeds if I pass -lgcc_s. So should libgcc/config/t-slibgcc-libgcc use be writing -lgcc_s for this arch or is something else just looking for libgcc.so.1 instead of libgcc_s.so.1 and then lying about it?
[Bug middle-end/85989] [6/7/8 Regression] Incorrect result for example involving unary minus in a loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85989 --- Comment #6 from rsandifo at gcc dot gnu.org --- Author: rsandifo Date: Sat Jun 23 08:07:31 2018 New Revision: 261983 URL: https://gcc.gnu.org/viewcvs?rev=261983&root=gcc&view=rev Log: Fix phi backedge detection in backprop (PR85989) Backport trunk r261064. 2018-06-23 Richard Sandiford gcc/ PR tree-optimization/85989 * gimple-ssa-backprop.c (backprop::m_visited_phis): New member variable. (backprop::intersect_uses): Check it when deciding whether this is a backedge reference. (backprop::process_block): Add each phi to m_visited_phis after visiting it, then clear it at the end. gcc/testsuite/ PR tree-optimization/85989 * gcc.dg/torture/pr85989.c: New test. Added: branches/gcc-8-branch/gcc/testsuite/gcc.dg/torture/pr85989.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/gimple-ssa-backprop.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug go/86289] Cgo integer constant overflow for 64 bits (unsigned) int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86289 Stephen Kim changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Stephen Kim --- I haven't check for a couple of weeks. I think this seems to have been fixed in the upstream
[Bug go/86289] New: Cgo integer constant overflow for 64 bits (unsigned) int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86289
Bug ID: 86289
Summary: Cgo integer constant overflow for 64 bits (unsigned)
int
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: stephen.kim at oracle dot com
CC: cmang at google dot com
Target Milestone: ---
I think the bug report is not the best format for this issue but that's the
only I have. Let me start with the bug. The bug seems a regression that I have
found in building docker with gccgo for aarch64. Here is, however, the reduced
test case:
$ cat ~/ce.go
package main
import "fmt"
/*
const unsigned long long int neg = (const unsigned long long) -1;
*/
import "C"
func main() {
var i int64
i = int64(C.neg)
fmt.Println(C.neg)
fmt.Println(i)
}
$ go build -x ~/ce.go
(omitted some logs)
../../../ce.go:14:6: error: integer constant overflow
i = int64(C.neg)
^
The problem is, cgo invokes gcc as just "gcc." Gcc 8.x started to accept the
following C code:
const unsigned long long int neg = (const unsigned long long) -1;
#line 1 "not-num-const"
void __cgo_f_1_4(void) { static const double __cgo_undefined__4 = (neg); }
The code above is generated by cgo; cgo tries to understand "neg" by generating
the code and giving it to gcc. Gcc 7.3 said "That's a compile error." while gcc
8.x and 9.0 silently accept it.
Once the code is accepted by, say, gcc 9, cgo type-casts the value as double.
It is very clear that a 64 bit double cannot accommodate all 64 bits integer
values. -1 is one of the corner cases.
As "neg" is "not-int-const," if gcc says it does not fall into "not-num-const,"
cgo thinks "neg" is an fconst. That is destined to be type-casted to a double:
#line 1 "cgo-generated-wrapper"
#line 1 "cgo-dwarf-inference"
__typeof__(neg) *__cgo__0;
long long __cgodebug_ints[] = {
0,
1
};
double __cgodebug_floats[] = {
neg,
1
};
Cgo generates the code above to get some debugging information gcc generated,
and use the value there to initialize C.neg in the Go code.
I believe that is not correct.
Firstly, this bug would be a regression as gcc 7.3 did say the following is a
compile error:
const unsigned long long int neg = (const unsigned long long) -1;
#line 1 "not-num-const"
void __cgo_f_1_4(void) { static const double __cgo_undefined__4 = (neg); }
Then, should the bug be filed against gcc?
However, I am also wondering. Even if everything were fine, I still think that
my "neg" variable perhaps should not fall into "not-int-const." It should be
int-const.
Personally, regarding my work with my employer, I have worked on this issue. I
would like to proceed to provide a fix for the issue if someone confirms I am
on the right track.
Thank you!
