[Bug libstdc++/89641] New: std::atomic no longer works
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89641
Bug ID: 89641
Summary: std::atomic no longer works
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: d25fe0be at outlook dot com
Target Milestone: ---
Live example: https://wandbox.org/permlink/j7rBCbdmy9sUBRZQ
Compiling the following snippet ...
```cpp
#include
std::atomic x;
int main() {
++x;
}
```
... fails with:
```
/opt/wandbox/gcc-head/include/c++/9.0.1/bits/atomic_base.h:319:45: error:
cannot convert 'const std::memory_order' to 'int'
319 | { return __atomic_add_fetch(&_M_i, 1, memory_order_seq_cst); }
| ^~~~
| |
| const std::memory_order
: note: initializing argument 3 of 'unsigned int
__atomic_add_fetch_4(volatile void*, unsigned int, int)'
```
I guess that this is related to implementing P0439R0 (Make std::memory_order a
scoped enumeration)?
[Bug rtl-optimization/89634] gmp-ecm miscompilation on s390x with -march=zEC12 -m64 -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89634 --- Comment #2 from Jakub Jelinek --- Author: jakub Date: Sat Mar 9 08:25:48 2019 New Revision: 269522 URL: https://gcc.gnu.org/viewcvs?rev=269522&root=gcc&view=rev Log: PR rtl-optimization/89634 * cfgcleanup.c (thread_jump): Punt if registers mentioned in cond1 are modified in BB_END (e->src) instruction. * gcc.c-torture/execute/pr89634.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr89634.c Modified: trunk/gcc/ChangeLog trunk/gcc/cfgcleanup.c trunk/gcc/testsuite/ChangeLog
[Bug target/79645] missing period in microblaze.opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79645 --- Comment #1 from Jakub Jelinek --- Author: jakub Date: Sat Mar 9 09:28:04 2019 New Revision: 269523 URL: https://gcc.gnu.org/viewcvs?rev=269523&root=gcc&view=rev Log: PR target/79645 * common.opt (fdiagnostics-show-labels, fdiagnostics-show-line-numbers, fdiagnostics-format=, fdiagnostics-minimum-margin-width=, fgnat-encodings=, gas-loc-support, gas-locview-support, ginline-points, ginternal-reset-location-views): Terminate description text with a dot. * config/microblaze/microblaze.opt (mxl-prefetch): Likewise. * config/mcore/mcore.opt (m210, m340): Likewise. * config/epiphany/epiphany.opt (mprefer-short-insn-regs, mcmove, mnops=): Start description text with a capital letter. * config/arc/arc.opt (msize-level=): Likewise. * config/sh/sh.opt (minline-ic_invalidate): Likewise. * config/rs6000/sysv4.opt (mno-toc, mtoc, mno-traceback, mshlib, mnewlib): Likewise. * config/ft32/ft32.opt (msim): Likewise. (mft32b, mcompress): Likewise. Terminate description text with a dot. (mnodiv, mnopm): Terminate description text with a dot. * config/c6x/c6x.opt (c6x_sdata): Terminate Enum description with a colon. * config/i386/i386.opt (prefer_vector_width, instrument_return): Likewise. * config/rx/rx.opt (nofpu): Remove trailing spaces from description text. lto/ * lang.opt: Terminate description text with a dot. Modified: trunk/gcc/ChangeLog trunk/gcc/common.opt trunk/gcc/config/arc/arc.opt trunk/gcc/config/c6x/c6x.opt trunk/gcc/config/epiphany/epiphany.opt trunk/gcc/config/ft32/ft32.opt trunk/gcc/config/i386/i386.opt trunk/gcc/config/mcore/mcore.opt trunk/gcc/config/microblaze/microblaze.opt trunk/gcc/config/rs6000/sysv4.opt trunk/gcc/config/rx/rx.opt trunk/gcc/config/sh/sh.opt trunk/gcc/lto/ChangeLog trunk/gcc/lto/lang.opt
[Bug rtl-optimization/89634] gmp-ecm miscompilation on s390x with -march=zEC12 -m64 -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89634 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jakub Jelinek --- Fixed.
[Bug target/79645] missing period in microblaze.opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79645 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from Jakub Jelinek --- Fixed.
[Bug target/79926] i386: untranslated placeholder "exception/interrupt" in diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79926 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Fixed.
[Bug translation/40883] [meta-bug] Translation breakage with trivial fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40883 Bug 40883 depends on bug 79645, which changed state. Bug 79645 Summary: missing period in microblaze.opt https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79645 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug translation/40883] [meta-bug] Translation breakage with trivial fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40883 Bug 40883 depends on bug 79926, which changed state. Bug 79926 Summary: i386: untranslated placeholder "exception/interrupt" in diagnostic https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79926 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug fortran/89621] [7/8/9 Regression] ICE with allocatable character and openmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89621 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-03-09 CC||janus at gcc dot gnu.org Summary|Internal Compiler Error |[7/8/9 Regression] ICE with |with allocatable character |allocatable character and |and openmp |openmp Ever confirmed|0 |1 --- Comment #1 from janus at gcc dot gnu.org --- I can confirm the ICE with versions 6.5.0, 7.3.0, 8.2.0 and trunk. However, I don't see an ICE with 5.5.0, which makes this a regression.
[Bug ipa/89341] [7/8/9 Regression] ICE in get, at cgraph.h:1332
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89341 --- Comment #8 from Martin Liška --- (In reply to David Malcolm from comment #7) > (In reply to Martin Liška from comment #6) > > David: Are you planning to send for it? > I'm not sure what you mean by this, sorry. I'm sorry for bad formulation. I was asking whether you're planning to send a patch candidate that you presented in #c4?
[Bug fortran/84504] [F03] procedure pointer variables cannot be initialized with functions returning pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84504 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid Status|WAITING |ASSIGNED CC||janus at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |janus at gcc dot gnu.org Summary|procedure pointer variables |[F03] procedure pointer |cannot be initialized with |variables cannot be |functions returning |initialized with functions |pointers|returning pointers --- Comment #5 from janus at gcc dot gnu.org --- (In reply to Sriram Swaminarayan from comment #4) > This compile error has to do with not being able to deal with a specific > return type for a function (i.e. those functions that return pointers). The > return type of a function should have no bearing on whether or not the > initialization should succeed. I agree here and I think your code is valid.
[Bug fortran/84504] [F08] procedure pointer variables cannot be initialized with functions returning pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84504 janus at gcc dot gnu.org changed: What|Removed |Added Summary|[F03] procedure pointer |[F08] procedure pointer |variables cannot be |variables cannot be |initialized with functions |initialized with functions |returning pointers |returning pointers --- Comment #6 from janus at gcc dot gnu.org --- Note that non-NULL pointer initialization is a Fortran 2008 feature (not permitted in the 2003 standard).
[Bug c/88568] [7/8/9 Regression] 'dllimport' no longer implies 'extern' in C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88568 --- Comment #22 from jon_y <10walls at gmail dot com> --- Bootstrapped sucessfully on x86_64-pc-cygwin, test compiles and has the data member dllimported. Patch looks good.
[Bug fortran/84504] [F08] procedure pointer variables cannot be initialized with functions returning pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84504
--- Comment #7 from janus at gcc dot gnu.org ---
The following patch fixes the problem and shows no regressions on
x86_64-linux-gnu:
diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c
index 51552a79cde..4e95f243661 100644
--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -4321,7 +4321,7 @@ gfc_check_assign_symbol (gfc_symbol *sym, gfc_component
*comp, gfc_expr *rvalue)
if (!r)
return r;
- if (pointer && rvalue->expr_type != EXPR_NULL)
+ if (pointer && rvalue->expr_type != EXPR_NULL && !proc_pointer)
{
/* F08:C461. Additional checks for pointer initialization. */
symbol_attribute attr;
[Bug fortran/84504] [F08] procedure pointer variables cannot be initialized with functions returning pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84504
--- Comment #8 from nmsriram at gmail dot com ---
Thank you!
I had given up on this.
:-)
Sriram
On Sat, Mar 9, 2019 at 7:48 PM janus at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84504
>
> --- Comment #7 from janus at gcc dot gnu.org ---
> The following patch fixes the problem and shows no regressions on
> x86_64-linux-gnu:
>
> diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c
> index 51552a79cde..4e95f243661 100644
> --- a/gcc/fortran/expr.c
> +++ b/gcc/fortran/expr.c
> @@ -4321,7 +4321,7 @@ gfc_check_assign_symbol (gfc_symbol *sym,
> gfc_component
> *comp, gfc_expr *rvalue)
>if (!r)
> return r;
>
> - if (pointer && rvalue->expr_type != EXPR_NULL)
> + if (pointer && rvalue->expr_type != EXPR_NULL && !proc_pointer)
> {
>/* F08:C461. Additional checks for pointer initialization. */
>symbol_attribute attr;
>
> --
> You are receiving this mail because:
> You reported the bug.
[Bug c/88568] [7/8/9 Regression] 'dllimport' no longer implies 'extern' in C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88568 --- Comment #23 from Jakub Jelinek --- Author: jakub Date: Sat Mar 9 12:08:23 2019 New Revision: 269525 URL: https://gcc.gnu.org/viewcvs?rev=269525&root=gcc&view=rev Log: PR c/88568 * attribs.c (handle_dll_attribute): Don't clear TREE_STATIC for dllimport on VAR_DECLs with RECORD_TYPE or UNION_TYPE DECL_CONTEXT. * g++.dg/other/pr88568.C: New test. Added: trunk/gcc/testsuite/g++.dg/other/pr88568.C Modified: trunk/gcc/ChangeLog trunk/gcc/attribs.c trunk/gcc/testsuite/ChangeLog
[Bug c/88568] [7/8 Regression] 'dllimport' no longer implies 'extern' in C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88568 Jakub Jelinek changed: What|Removed |Added Summary|[7/8/9 Regression] |[7/8 Regression] |'dllimport' no longer |'dllimport' no longer |implies 'extern' in C |implies 'extern' in C --- Comment #24 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug debug/86582] [debug] vla size reported as 0 at Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86582 Allan Jensen changed: What|Removed |Added CC||linux at carewolf dot com --- Comment #3 from Allan Jensen --- Wouldn't this be solved by disable -ftree-dse for -Og where as bug 78685 is more complicated?
[Bug debug/68836] GCC can't properly emit debug info for function arguments in a back-trace when using -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68836 Allan Jensen changed: What|Removed |Added CC||linux at carewolf dot com --- Comment #8 from Allan Jensen --- Duplicate of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78685
[Bug fortran/71203] ICE in add_init_expr_to_sym, at fortran/decl.c:1512 and :1564
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71203 --- Comment #17 from Thomas Koenig --- Author: tkoenig Date: Sat Mar 9 14:10:17 2019 New Revision: 269526 URL: https://gcc.gnu.org/viewcvs?rev=269526&root=gcc&view=rev Log: 2019-03-09 Thomas König PR fortran/71203 * decl.c (add_init_expr_to_sym): Add shape if init has none. Add assert that it has to be an EXPR_ARRAY in this case. 2019-03-09 Thomas König PR fortran/71203 * gfortran.dg/array_simplify_3.f90: New test case. Added: trunk/gcc/testsuite/gfortran.dg/array_simplify_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/71203] ICE in add_init_expr_to_sym, at fortran/decl.c:1512 and :1564
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71203 Thomas Koenig changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #18 from Thomas Koenig --- The last test case is fixed. Not a regression, so I don't plan on backporting. Closing.
[Bug other/89635] More ANSI SGR codes in diagnostics?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89635 --- Comment #2 from David Malcolm --- evaned posted this mockup of how it could look: https://imgur.com/tNg6qfh
[Bug fortran/89639] FAIL: gfortran.dg/ieee/ieee_9.f90 -O0 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89639 --- Comment #2 from dave.anglin at bell dot net --- On 2019-03-08 8:26 p.m., kargl at gcc dot gnu.org wrote: > Just XFAIL the testcase. I'm going to skip test as it still fails when XFAIL'd as on arm. The test fails due to compile error.
[Bug fortran/87838] Segmentation fault with function pointer to contained function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87838 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org --- Comment #3 from janus at gcc dot gnu.org --- (In reply to menospaamthereaper from comment #2) > Thank you Dominique for testing this on a Mac. So perhaps the problem is > specific to Linux. I just compiled the test case on Ubuntu 18.04 with gfortran versions 5, 6, 7, 8 and trunk. I don't see a segfault with any of these. Also gdb and valgrind don't show any kind of problem. > Additional information that might help with debugging the segmentation fault: > > 1) Compiling this code with > > gfortran -ffree-form -std=f2003 test.f > > gives the error > > test.f:12:13: > > f_ptr => f1 > 1 > Error: Fortran 2008: Internal procedure ‘f1’ is invalid in procedure pointer > assignment at (1) This error is correct. That's just not allowed in Fortran 2003. All fine. > 2) However, > > gfortran -ffree-form -std=f2008 test.f > > compiles successfully but gives a segmentation fault. > > ./a.out > > Program received signal SIGSEGV: Segmentation fault - invalid memory > reference. > > Backtrace for this error: > #0 0x7fe7aae3b31a > #1 0x7fe7aae3a503 > #2 0x7fe7aaa5ef1f > #3 0x7fffed8fe6c0 > Segmentation fault (core dumped) Could you please compile with the -g flag, in order to get a more meaningful backtrace? Alternatively try running the executable via gdb or valgrind for further debugging.
[Bug libstdc++/77691] [7/8/9 regression] experimental/memory_resource/resource_adaptor.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691 --- Comment #29 from John David Anglin --- /test/gnu/gcc/gcc/libstdc++-v3/testsuite/experimental/memory_resource/resource_adaptor.cc:136: void test05(): Assertion 'aligned(p)' failed. FAIL: experimental/memory_resource/resource_adaptor.cc execution test
[Bug fortran/89639] FAIL: gfortran.dg/ieee/ieee_9.f90 -O0 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89639 --- Comment #3 from John David Anglin --- Author: danglin Date: Sat Mar 9 16:31:46 2019 New Revision: 269527 URL: https://gcc.gnu.org/viewcvs?rev=269527&root=gcc&view=rev Log: PR fortran/89639 * gfortran.dg/ieee/ieee_9.f90: Skip on hppa*-*-linux*. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/ieee/ieee_9.f90
[Bug fortran/70739] VALUE attribute interpretation in a non-interoperable procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70739 janus at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED CC||janus at gcc dot gnu.org Resolution|--- |INVALID --- Comment #3 from janus at gcc dot gnu.org --- (In reply to zmi from comment #0) > I see difference between ifort and gfortran interpretation of a > non-interoperable procedure (without BIND(C)) with VALUE attribute in dummy > argument. IMHO using a non-interoperable procedure to interface with C code is basically a user error. You can do it, but the result will be highly compiler-dependent (as you saw). If you want mixed C/Fortran code to be compiler-independent, just use BIND(C)! I'll close this PR as invalid.
[Bug fortran/89639] FAIL: gfortran.dg/ieee/ieee_9.f90 -O0 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89639 --- Comment #4 from Steve Kargl --- On Sat, Mar 09, 2019 at 04:12:23PM +, dave.anglin at bell dot net wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89639 > > --- Comment #2 from dave.anglin at bell dot net --- > On 2019-03-08 8:26 p.m., kargl at gcc dot gnu.org wrote: > > Just XFAIL the testcase. > I'm going to skip test as it still fails when XFAIL'd as on arm. The test > fails > due to compile error. > Thanks. When I wrote the test, I tried to skip the REAL128 case with the "if (real128 >) then" ... blocks, and completely overlooked that real128 is a named constant. This means the conversion functions real(..., real128) will try ti real128 = -1, which of fails.
[Bug fortran/89639] FAIL: gfortran.dg/ieee/ieee_9.f90 -O0 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89639 --- Comment #5 from dave.anglin at bell dot net --- On 2019-03-09 12:43 p.m., sgk at troutmask dot apl.washington.edu wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89639 > > --- Comment #4 from Steve Kargl --- > On Sat, Mar 09, 2019 at 04:12:23PM +, dave.anglin at bell dot net wrote: >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89639 >> >> --- Comment #2 from dave.anglin at bell dot net --- >> On 2019-03-08 8:26 p.m., kargl at gcc dot gnu.org wrote: >>> Just XFAIL the testcase. >> I'm going to skip test as it still fails when XFAIL'd as on arm. The test >> fails >> due to compile error. >> > Thanks. When I wrote the test, I tried to skip the > REAL128 case with the "if (real128 >) then" ... > blocks, and completely overlooked that real128 is > a named constant. This means the conversion functions > real(..., real128) will try ti real128 = -1, which > of fails. Now I understand why this just fails on hppa-linux. hppa-hpux has REAL128. I probably should change skip reason to "No REAL128". Dave
[Bug c++/89642] New: gcc rejects valid implicit typename context in cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89642
Bug ID: 89642
Summary: gcc rejects valid implicit typename context in cast
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: blitzrakete at gmail dot com
Target Milestone: ---
template
void f(T t) {
static_cast(t); // gcc rejects, but this is well-formed
}
gcc rejects the above with:
: In function 'void f(T)':
:3:18: error: expected '>' before '(' token
3 | static_cast(t);
| ^
But the code is well-formed, since the smallest enclosing type-id of
`int(T::type)` is the type-id of the static_cast, which is a valid type-id-only
context as per [temp.res]p5.
[Bug fortran/84504] [F08] procedure pointer variables cannot be initialized with functions returning pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84504 --- Comment #9 from janus at gcc dot gnu.org --- Author: janus Date: Sat Mar 9 18:25:39 2019 New Revision: 269529 URL: https://gcc.gnu.org/viewcvs?rev=269529&root=gcc&view=rev Log: fix PR 84504 2019-03-09 Janus Weil PR fortran/84504 * expr.c (gfc_check_assign_symbol): Deal with procedure pointers to pointer-valued functions. 2019-03-09 Janus Weil PR fortran/84504 * gfortran.dg/pointer_init_10.f90: New test case. Added: trunk/gcc/testsuite/gfortran.dg/pointer_init_10.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/84504] [F08] procedure pointer variables cannot be initialized with functions returning pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84504 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from janus at gcc dot gnu.org --- Fixed on 9-trunk with r269529. Closing.
[Bug fortran/89639] FAIL: gfortran.dg/ieee/ieee_9.f90 -O0 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89639 --- Comment #6 from Steve Kargl --- On Sat, Mar 09, 2019 at 05:50:43PM +, dave.anglin at bell dot net wrote: > >> > > Thanks. When I wrote the test, I tried to skip the > > REAL128 case with the "if (real128 >) then" ... > > blocks, and completely overlooked that real128 is > > a named constant. This means the conversion functions > > real(..., real128) will try ti real128 = -1, which s/will try ti/will try to use > > of fails. > Now I understand why this just fails on hppa-linux.i > hppa-hpux has REAL128. I probably should change skip > reason to "No REAL128". > I added predefine macros for cpp. I'll someday move this testcase to ieee_9.F90, and use #if __GFC_REAL16__ to guard againt the issue. "Someday" may not be too soon.
[Bug fortran/71544] gfortran compiler optimization bug when dealing with c-style pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71544 --- Comment #14 from Thomas Koenig --- Author: tkoenig Date: Sat Mar 9 19:21:24 2019 New Revision: 269532 URL: https://gcc.gnu.org/viewcvs?rev=269532&root=gcc&view=rev Log: 2019-03-09 Thomas Koenig PR fortran/71544 * trans-types.c (gfc_typenode_for_spec) Set ts->is_c_interop of C_PTR and C_FUNPTR. (create_fn_spec): Mark argument as escaping if ts->is_c_interop is set. 2019-03-09 Thomas Koenig PR fortran/71544 * gfortran.dg/c_ptr_tests_19.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/c_ptr_tests_19.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-types.c trunk/gcc/testsuite/ChangeLog
[Bug d/89041] ICE in get_frame_for_symbol, at d/d-codegen.cc:2175
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89041 --- Comment #1 from ibuclaw at gcc dot gnu.org --- Author: ibuclaw Date: Sat Mar 9 19:29:29 2019 New Revision: 269533 URL: https://gcc.gnu.org/viewcvs?rev=269533&root=gcc&view=rev Log: d: Fix ICE in get_frame_for_symbol When generating code for a non-nested delegate literal, there is no context pointer required to pass to the function. 2019-03-09 Iain Buclaw gcc/d/ PR d/89041 * d-codegen.cc (get_frame_for_symbol): Delegate literals defined in global scope don't have a frame pointer. gcc/testsuite/ PR d/89041 * gdc.dg/pr89041.d: New test. Added: trunk/gcc/testsuite/gdc.dg/pr89041.d Modified: trunk/gcc/d/ChangeLog trunk/gcc/d/d-codegen.cc trunk/gcc/testsuite/ChangeLog
[Bug d/89041] ICE in get_frame_for_symbol, at d/d-codegen.cc:2175
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89041 Iain Buclaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Iain Buclaw --- Fixed in r269533.
[Bug inline-asm/87010] FAIL: gcc.dg/torture/20180712-1.c -O1 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87010 --- Comment #3 from John David Anglin --- Author: danglin Date: Sat Mar 9 19:56:06 2019 New Revision: 269535 URL: https://gcc.gnu.org/viewcvs?rev=269535&root=gcc&view=rev Log: PR inline-asm/87010 * gcc.dg/torture/20180712-1.c: Skip on hppa*-*-*. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/torture/20180712-1.c
[Bug fortran/87673] Errors caused by using function for character length in allocate with typespec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87673 Thomas Koenig changed: What|Removed |Added Status|RESOLVED|NEW Last reconfirmed||2019-03-09 CC||tkoenig at gcc dot gnu.org Resolution|DUPLICATE |--- Ever confirmed|0 |1 --- Comment #3 from Thomas Koenig --- The patch at https://gcc.gnu.org/ml/gcc-patches/2019-03/msg00432.html for PR87734 does not fix this bug (well, not all of it): big.f90:46:24: 46 | ALLOCATE( CHARACTER(get_char_result_length(len(string%chars), length)) :: & |1 Error: Reference to impure function '_def_init' at (1) within a PURE procedure
[Bug fortran/87673] [7/8/9 Regression] Errors caused by using function for character length in allocate with typespec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87673 Thomas Koenig changed: What|Removed |Added Target Milestone|--- |7.5 Summary|Errors caused by using |[7/8/9 Regression] Errors |function for character |caused by using function |length in allocate with |for character length in |typespec|allocate with typespec
[Bug rtl-optimization/89588] [8/9 Regression] ICE in unroll_loop_constant_iterations, at loop-unroll.c:498
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89588 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #5 from Eric Botcazou --- Reluctantly investigating.
[Bug c++/87750] [8/9 Regression] Failed compilation / parsing of template member call after 'using' declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87750 --- Comment #13 from paolo at gcc dot gnu.org --- Author: paolo Date: Sat Mar 9 21:49:41 2019 New Revision: 269539 URL: https://gcc.gnu.org/viewcvs?rev=269539&root=gcc&view=rev Log: 2019-03-09 Paolo Carlini PR c++/87750 * g++.dg/cpp0x/pr87750.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/pr87750.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/87750] [8/9 Regression] Failed compilation / parsing of template member call after 'using' declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87750 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|8.4 |8.3 --- Comment #14 from Paolo Carlini --- Fixed trunk and 8.3.0 by the second patch for PR87531.
[Bug testsuite/89472] FAIL: gcc.dg/debug/dwarf2/inline5.c scan-assembler-times DW_TAG_lexical_block\\)[^#/!@;\\|]*[#/!@;\\|]+ +[^#/!@\\|]*\\(DIE \\(0x[0-9a-f]*\\) DW_TAG_variable 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89472 --- Comment #2 from John David Anglin --- Author: danglin Date: Sat Mar 9 22:13:01 2019 New Revision: 269540 URL: https://gcc.gnu.org/viewcvs?rev=269540&root=gcc&view=rev Log: PR testsuite/89472 * gcc.dg/debug/dwarf2/inline5.c: XFAIL one scan-assembler-times check. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/debug/dwarf2/inline5.c
[Bug testsuite/89472] FAIL: gcc.dg/debug/dwarf2/inline5.c scan-assembler-times DW_TAG_lexical_block\\)[^#/!@;\\|]*[#/!@;\\|]+ +[^#/!@\\|]*\\(DIE \\(0x[0-9a-f]*\\) DW_TAG_variable 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89472 John David Anglin changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from John David Anglin --- Fixed.
[Bug middle-end/68733] [7/8/9 Regression] FAIL: libgomp.c/target-29.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68733 --- Comment #20 from John David Anglin --- Author: danglin Date: Sat Mar 9 22:32:30 2019 New Revision: 269541 URL: https://gcc.gnu.org/viewcvs?rev=269541&root=gcc&view=rev Log: PR middle-end/68733 * c-c++-common/gomp/clauses-2.c: Skip on 32-bit hppa*-*-hpux*. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/gomp/clauses-2.c
[Bug ada/89609] bug box caused by access to function as a record component via a limited with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89609 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-03-09 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou --- Still happens on mainline.
[Bug c++/89643] New: constexpr capture not working inside expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89643
Bug ID: 89643
Summary: constexpr capture not working inside expression
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rcc.dark at gmail dot com
Target Milestone: ---
Created attachment 45928
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45928&action=edit
Source code that triggers the bug
Hi all, this code does not compile ("closure not a constant expression") in GCC
8.3 and Trunk (from https://godbolt.org/).
---
#include
constexpr int f(const int& n, const int& m) {
return n + m;
}
int main( ) {
constexpr int N = 1;
auto lambda = [&] {
std::array arr;
};
}
---
The code compiles in ICC and Clang.
How to make this compile in GCC:
- Make f take parameters by value
OR
- Declare N inside the lambda.
OR
- Remove [&] capture.
PS. Sorry if duplicate bug, couldn't find earlier reports.
[Bug c++/70349] FAIL: g++.dg/abi/abi-tag18a.C -std=gnu++98 scan-assembler _ZZ1fB7__test1vEN1T1gB7__test2Ev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70349 --- Comment #1 from John David Anglin --- Author: danglin Date: Sat Mar 9 22:58:24 2019 New Revision: 269542 URL: https://gcc.gnu.org/viewcvs?rev=269542&root=gcc&view=rev Log: PR c++/70349 * g++.dg/abi/abi-tag18a.C: Skip on 32-bit hppa*-*-hpux*. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/abi/abi-tag18a.C
[Bug tree-optimization/89644] New: False-positive -Warray-bounds diagnostic on strncpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89644
Bug ID: 89644
Summary: False-positive -Warray-bounds diagnostic on strncpy
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: samuel at sholland dot org
Target Milestone: ---
GCC 8.3.0 warns for some calls to strncpy where n == sizeof(dest). It appears
to only happen if src is anything more complex than a char*, such as an array
or structure member. The warning claims an access to the character at n+1,
which is past the limit given to strncpy, so cannot happen.
In this example, "foo" and "bar" warn, but "ok1" and "ok2" do not:
# cat test.c
typedef __SIZE_TYPE__ size_t;
char *strncpy(char *restrict dest, const char *restrict src, size_t n);
struct simple {
char *s;
};
char foo(char *input[])
{
char buffer[6] __attribute__ ((nonstring)) = {' ',' ',' ',' ',' ',' '};
if (input && input[0])
strncpy(buffer, input[0], sizeof(buffer));
return buffer[2];
}
char bar(struct simple *input)
{
char buffer[6] __attribute__ ((nonstring)) = {' ',' ',' ',' ',' ',' '};
if (input && input->s)
strncpy(buffer, input->s, sizeof(buffer));
return buffer[2];
}
char ok1(struct simple *input)
{
char buffer[6] __attribute__ ((nonstring)) = {' ',' ',' ',' ',' ',' '};
if (input) {
char *local = input->s;
if (local)
strncpy(buffer, local, sizeof(buffer));
}
return buffer[2];
}
char ok2(char *input)
{
char buffer[6] __attribute__ ((nonstring)) = {' ',' ',' ',' ',' ',' '};
if (input)
strncpy(buffer, input, sizeof(buffer));
return buffer[2];
}
# gcc -c -O2 -Wall test.c
test.c: In function 'foo':
test.c:12:9: warning: 'strncpy' forming offset 7 is out of the bounds [0, 6] of
object 'buffer' with type 'char[6]' [-Warray-bounds]
strncpy(buffer, input[0], sizeof(buffer));
^
test.c:10:10: note: 'buffer' declared here
char buffer[6] __attribute__ ((nonstring)) = {' ',' ',' ',' ',' ',' '};
^~
test.c: In function 'bar':
test.c:20:9: warning: 'strncpy' forming offset 7 is out of the bounds [0, 6] of
object 'buffer' with type 'char[6]' [-Warray-bounds]
strncpy(buffer, input->s, sizeof(buffer));
^
test.c:18:10: note: 'buffer' declared here
char buffer[6] __attribute__ ((nonstring)) = {' ',' ',' ',' ',' ',' '};
^~
[Bug fortran/64678] [F03] Expected association error on dependent associate statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64678 Ian Harvey changed: What|Removed |Added CC||ian_harvey at bigpond dot com --- Comment #6 from Ian Harvey --- This comes up from time to time in various places... F2003/F2008 and F2018 all include words in the section on the scope of statement and construct entities (F2018 19.4) that the "associate names of an ASSOCIATE construct have the scope of the block", where "the block" is the chunk of source that is in between the ASSOCIATE and END ASSOCIATE statements, excluding those delimiting statements (see F2018 R1102). The original code is non-conforming - the associate name A is not in scope within the associate statement (versus "the block"), so `A` in the second association is an implicitly declared variable of type REAL, and a REAL variable does not have a component or type parameter named `map`. Current trunk rejects the code with an appropriate error message.
[Bug fortran/64678] [F03] Expected association error on dependent associate statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64678 Dominique d'Humieres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #7 from Dominique d'Humieres --- > Current trunk rejects the code with an appropriate error message. Then closing as INVALID.
[Bug fortran/87477] [meta-bug] [F03] issues concerning the ASSOCIATE statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87477 Bug 87477 depends on bug 64678, which changed state. Bug 64678 Summary: [F03] Expected association error on dependent associate statements https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64678 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID
[Bug fortran/89645] New: No IMPLICIT type error with: ASSOCIATE( X => function() )
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89645 Bug ID: 89645 Summary: No IMPLICIT type error with: ASSOCIATE( X => function() ) Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: ian_harvey at bigpond dot com Target Milestone: --- The module: MODULE m IMPLICIT NONE TYPE :: t INTEGER :: comp END TYPE t CONTAINS SUBROUTINE s ASSOCIATE(b => fun()) PRINT *, b%comp END ASSOCIATE END SUBROUTINE s FUNCTION fun() RESULT(r) TYPE(t) :: r r = t(1) END FUNCTION fun END MODULE m when compiled with recent trunk (r269545) gives: 9 | PRINT *, b%comp | 1 Error: Symbol ‘b’ at (1) has no IMPLICIT type F2003 rules (8.1.4.2) and subsequent standards state for the associate statement that the entity identified by the associate name assumes the declared type of the selector. (This has some similarity to pr60483, which related to structure constructors.)
[Bug fortran/89646] New: Spurious actual argument might interfere warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89646 Bug ID: 89646 Summary: Spurious actual argument might interfere warning Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: ian_harvey at bigpond dot com Target Milestone: --- The following: MODULE m IMPLICIT NONE TYPE :: t END TYPE t CONTAINS SUBROUTINE s ! To reproduce, both actual arguments must be TARGET, ! both arguments must be of derived type. TYPE(t), TARGET :: a(5) TYPE(t), TARGET :: b(5) CALL move(a, b) END SUBROUTINE s ! To reproduce, called procedure must be elemental. ELEMENTAL SUBROUTINE move(from, to) TYPE(t), INTENT(INOUT) :: from TYPE(t), INTENT(OUT) :: to END SUBROUTINE move END MODULE m when compiled with recent trunk (r26545) gives the following spurious warnings: argument-interfereb.f90:12:14-17: 12 | CALL move(a, b) | 1 2 Warning: INTENT(INOUT) actual argument at (1) might interfere with actual argument at (2). argument-interfereb.f90:12:14-17: 12 | CALL move(a, b) | 2 1 Warning: INTENT(OUT) actual argument at (1) might interfere with actual argument at (2). I suspect that the compiler is trying to warn me about potential aliasing given the TARGET attribute on the actual arguments, but there is no such aliasing in this example, and the details required to trigger the warning (arguments must be derived type, procedure must be elemental) are too specific for this warning to be useful or intended.
[Bug c++/89585] GCC 8.3: asm volatile no longer accepted at file scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89585 --- Comment #34 from Matthias Klose --- Author: doko Date: Sun Mar 10 07:25:13 2019 New Revision: 269546 URL: https://gcc.gnu.org/viewcvs?rev=269546&root=gcc&view=rev Log: gcc/cp/ 2019-04-10 Matthias Klose Backport from the gcc-8 branch 2019-03-07 Jakub Jelinek PR c++/89585 * parser.c (cp_parser_asm_definition): Parse asm qualifiers even at toplevel, but diagnose them. gcc/testsuite/ 2019-04-10 Matthias Klose Backport from the gcc-8 branch 2019-03-07 Jakub Jelinek PR c++/89585 * g++.dg/asm-qual-3.C: Adjust expected diagnostics. Modified: branches/gcc-7-branch/gcc/cp/ChangeLog branches/gcc-7-branch/gcc/cp/parser.c branches/gcc-7-branch/gcc/testsuite/ChangeLog branches/gcc-7-branch/gcc/testsuite/g++.dg/asm-qual-3.C
