[Bug c++/80469] Undefined symbol for abstract class impl with -fvisibility=hidden
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80469 Ubikovich changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #7 from Ubikovich --- OK
[Bug other/80492] Wrong code when unrolling a loop with inline asm and local regs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80492
--- Comment #1 from Georg-Johann Lay ---
Created attachment 41249
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41249&action=edit
loopasm.s: Generated assembly
Assembler output as generated with
$ avr-gcc loopasm.c -O2 -dp -S -std=gnu99
The source code issues two "syscalls" arranged in a loop:
static __inline__ __attribute__((__always_inline__))
void syscall_7 (int v1, int v2)
{
register int r20 __asm ("20") = v1;
register int r24 __asm ("24") = v2;
__asm __volatile__ ("/* SYSCALL_7 %0 %1 */" :: "r" (r20), "r" (r24));
}
void do_syscalls (void)
{
for (int s = 0; s < 2; s++)
{
syscall_7 (0, 8);
syscall_7 (1, 9);
}
}
The generated assembler misses some of the arguments; the asm reads:
do_syscalls:
ldi r20,0; 5 *movhi/2[length = 2]
ldi r21,0
ldi r24,lo8(8) ; 6 *movhi/5[length = 2]
ldi r25,0
/* SYSCALL_7 r20 r24 */
ldi r20,lo8(1) ; 8 *movhi/5[length = 2]
ldi r21,0
ldi r24,lo8(9) ; 9 *movhi/5[length = 2]
ldi r25,0
/* SYSCALL_7 r20 r24 */
/* SYSCALL_7 r20 r24 */
/* SYSCALL_7 r20 r24 */
ret ; 18 return [length = 1]
The 1st syscall_7 is expanded correctly: insns 5/6 load 0/8 to specified regs,
then follows SYSCALL_7.
The 2st syscall_7 is expanded correctly: insns 8/9 load 1/9 to specified regs,
then follows SYSCALL_7.
The 3rd and 4th syscall_7 are expanded incorrect: Inline asm SYSCALL_7 is
performed without setting the specified regs to their values.
== configure ==
Configured with: ../../gcc.gnu.org/gcc-6-branch/configure --target=avr
--prefix=/local/gnu/install/gcc-6-avr-mingw32 --host=i386-mingw32
--build=x86_64-linux-gnu --enable-languages=c,c++ --disable-nls
--disable-shared --enable-lto --with-dwarf2 --with-gnu-ld --with-gnu-as
Thread model: single
gcc version 6.3.1 20161222 [gcc-6-branch revision 243886] (GCC)
[Bug other/80492] Wrong code when unrolling a loop with inline asm and local regs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80492
--- Comment #2 from Georg-Johann Lay ---
FYI, if the code is not executed in a loop but instead
void do_syscalls_noloop (void)
{
syscall_7 (0, 8);
syscall_7 (1, 9);
syscall_7 (0, 8);
syscall_7 (1, 9);
}
then the generated code is as expected:
do_syscalls_noloop:
ldi r20,0; 5 *movhi/2[length = 2]
ldi r21,0
ldi r24,lo8(8) ; 6 *movhi/5[length = 2]
ldi r25,0
/* #APP */
/* SYSCALL_7 r20 r24 */
/* #NOAPP */
ldi r20,lo8(1) ; 8 *movhi/5[length = 2]
ldi r21,0
ldi r24,lo8(9) ; 9 *movhi/5[length = 2]
ldi r25,0
/* #APP */
/* SYSCALL_7 r20 r24 */
/* #NOAPP */
ldi r20,0; 11 *movhi/2[length = 2]
ldi r21,0
ldi r24,lo8(8) ; 12 *movhi/5[length = 2]
ldi r25,0
/* #APP */
/* SYSCALL_7 r20 r24 */
/* #NOAPP */
ldi r20,lo8(1) ; 14 *movhi/5[length = 2]
ldi r21,0
ldi r24,lo8(9) ; 15 *movhi/5[length = 2]
ldi r25,0
/* #APP */
/* SYSCALL_7 r20 r24 */
/* #NOAPP */
ret ; 22 return [length = 1]
[Bug target/70799] STV pass does not convert DImode shifts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70799 --- Comment #9 from uros at gcc dot gnu.org --- Author: uros Date: Sun Apr 23 07:25:30 2017 New Revision: 247082 URL: https://gcc.gnu.org/viewcvs?rev=247082&root=gcc&view=rev Log: PR target/70799 * config/i386/i386.c (dimode_scalar_to_vector_candidate_p) : Also consider variable shifts. Check "XEXP (src, 1)" operand here. : Check "XEXP (src, 1)" operand here. (dimode_scalar_chain::make_vector_copies): Detect count register of a shift instruction. Zero extend count register from QImode to DImode to satisfy vector shift pattern count operand predicate. Substitute vector shift count operand with a DImode copy. (dimode_scalar_chain::convert_reg): Ditto, zero-extend from vector register. testsuite/ChangeLog: PR target/70799 * gcc.target/i186/pr70799-4.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr70799-4.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
[Bug other/80492] [5/6 Regression] Wrong code when unrolling a loop with inline asm and local regs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80492 Georg-Johann Lay changed: What|Removed |Added Summary|Wrong code when unrolling a |[5/6 Regression] Wrong code |loop with inline asm and|when unrolling a loop with |local regs |inline asm and local regs --- Comment #3 from Georg-Johann Lay --- This worked in v4.3 but regresses with all current versions (v5, v6 and v7).
[Bug fortran/80121] Memory leak with derived-type intent(out) argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80121 --- Comment #10 from janus at gcc dot gnu.org --- Author: janus Date: Sun Apr 23 08:26:50 2017 New Revision: 247083 URL: https://gcc.gnu.org/viewcvs?rev=247083&root=gcc&view=rev Log: 2017-04-22 Janus Weil PR fortran/80121 * trans-types.c (gfc_conv_procedure_call): Deallocate the components of allocatable intent(out) arguments. 2017-04-22 Janus Weil PR fortran/80121 * gfortran.dg/intent_out_9.f90: New test case. Added: trunk/gcc/testsuite/gfortran.dg/intent_out_9.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/80493] New: std::experimental::optional::swap is ill formed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80493
Bug ID: 80493
Summary: std::experimental::optional::swap is ill formed
Product: gcc
Version: 6.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: a...@cloudius-systems.com
Target Milestone: ---
From std::experimental::optional:
void
swap(optional& __other)
noexcept(is_nothrow_move_constructible<_Tp>()
&& noexcept(swap(declval<_Tp&>(), declval<_Tp&>(
{
The operand to the noexcept operator calls swap(T&, T&); but that is hidden by
optional::swap(optional&). Clang correctly rejects this code, but g++ accepts
it.
[Bug fortran/80494] New: [8.0 regression] ICE on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80494 Bug ID: 80494 Summary: [8.0 regression] ICE on valid code Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: juergen.reuter at desy dot de Target Milestone: --- The following code ICEs with -O2 (-O0 and -O1) is ok. r246952 (in the 7.0.1) still worked fine, r247067 fails. subroutine CalcCgr(C,rmax,ordgr_max) integer, intent(in) :: rmax,ordgr_max double complex :: Zadj(2,2), Zadj2(2,2) double complex, intent(out) :: C(0:rmax,0:rmax,0:rmax) double complex, allocatable :: Cexpgr(:,:,:,:) double complex :: Caux integer :: rmaxB,rmaxExp,r,n0,n1,n2,k,l,i,j,m,n,nn rmaxB = 2*rmax rmaxExp = rmaxB allocate(Cexpgr(0:rmaxExp/2,0:rmaxExp,0:rmaxExp,0:ordgr_max)) rloop: do r=0,rmaxExp/2 do n0=r,1,-1 do nn=r-n0,0,-1 do i=1,2 Caux = Caux - Zadj(i,l) end do Cexpgr(n0,0,0,0) = Caux/(2*(nn+1)) end do end do do n1=0,r n2 = r-n1 if (r.le.rmax) then C(0,n1,n2) = Cexpgr(0,n1,n2,0) end if end do end do rloop end subroutine CalcCgr
[Bug fortran/80494] [8.0 regression] ICE in wide_int_to_tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80494 Jürgen Reuter changed: What|Removed |Added Summary|[8.0 regression] ICE on |[8.0 regression] ICE in |valid code |wide_int_to_tree --- Comment #1 from Jürgen Reuter --- Sorry, forgot: internal compiler error: in wide_int_to_tree, at tree.c:1489
[Bug fortran/63473] Memory leak with ALLOCATABLE, INTENT(OUT) dummy arguments.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63473 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE Target Milestone|--- |8.0 --- Comment #8 from janus at gcc dot gnu.org --- The problem is fixed by r247083 (cf. PR 80121). *** This bug has been marked as a duplicate of bug 80121 ***
[Bug fortran/68800] Fortran FE produces many memory leaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68800 Bug 68800 depends on bug 63473, which changed state. Bug 63473 Summary: Memory leak with ALLOCATABLE, INTENT(OUT) dummy arguments. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63473 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug fortran/80121] Memory leak with derived-type intent(out) argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80121 janus at gcc dot gnu.org changed: What|Removed |Added CC||paul.vandelst at noaa dot gov --- Comment #11 from janus at gcc dot gnu.org --- *** Bug 63473 has been marked as a duplicate of this bug. ***
[Bug fortran/80121] Memory leak with derived-type intent(out) argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80121 janus at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |8.0 --- Comment #12 from janus at gcc dot gnu.org --- The problem is fixed on 8-trunk with r247083. As suggested by Thomas, I also plan to backport it to the 7-branch soon.
[Bug fortran/80494] [8 Regression] ICE in wide_int_to_tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80494 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||7.0.1 Keywords||ice-on-valid-code Last reconfirmed||2017-04-23 CC||marxin at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Ever confirmed|0 |1 Summary|[8.0 regression] ICE in |[8 Regression] ICE in |wide_int_to_tree|wide_int_to_tree Target Milestone|--- |8.0 Known to fail||8.0 --- Comment #2 from Martin Liška --- Confirmed, started with Richi's r247048.
[Bug c++/80495] New: attribute [[noreturn]] is accepted in function pointer declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80495
Bug ID: 80495
Summary: attribute [[noreturn]] is accepted in function pointer
declarations
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bruno at clisp dot org
Target Milestone: ---
g++ does not flag an error for use of attribute [[noreturn]] on a function
pointer declaration.
C++11 [dcl.attr.noreturn] says "The attribute may be applied to a declarator-id
in a function declaration."
$ cat noreturn1.cc
void func1 (void) { for (;;); }
[[ noreturn ]] void func2 (void) { for (;;); }
__attribute__ ((__noreturn__)) void func3 (void) { for (;;); }
void (*fptr11) (void) = func1;
void (*fptr12) (void) = func2;
void (*fptr13) (void) = func3;
[[ noreturn ]] void (*fptr21) (void) = func1; /* expected: error */
[[ noreturn ]] void (*fptr22) (void) = func2; /* expected: error */
[[ noreturn ]] void (*fptr23) (void) = func3; /* expected: error */
$ g++ --version | head -n 1
g++ (GCC) 6.3.0
$ g++ -std=c++11 -pedantic -c noreturn1.cc
[Bug c++/80496] New: missing diagnostic regarding noreturn mismatch in function pointer initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80496
Bug ID: 80496
Summary: missing diagnostic regarding noreturn mismatch in
function pointer initialization
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bruno at clisp dot org
Target Milestone: ---
A mismatch regarding __attribute__((__noreturn__)) in a function pointer
initialization generates a warning in C mode, but not in C++ mode.
$ cat noreturn2.cc
void func1 (void) { for (;;); }
[[ noreturn ]] void func2 (void) { for (;;); }
__attribute__ ((__noreturn__)) void func3 (void) { for (;;); }
void (*fptr11) (void) = func1;
void (*fptr12) (void) = func2;
void (*fptr13) (void) = func3;
__attribute__ ((__noreturn__)) void (*fptr31) (void) = func1; /* expected:
warning */
__attribute__ ((__noreturn__)) void (*fptr32) (void) = func2;
__attribute__ ((__noreturn__)) void (*fptr33) (void) = func3;
$ g++ --version | head -n 1
g++ (GCC) 6.3.0
$ g++ -std=c++11 -Wall -c noreturn2.cc
I would have expected a warning in the declaration of fptr31.
[Bug fortran/80477] [OOP] Polymorphic function result generates memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80477
janus at gcc dot gnu.org changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
--- Comment #9 from janus at gcc dot gnu.org ---
Anyway, getting back to the discussion of the actual bug ...
(In reply to janus from comment #4)
> When changing the function result from CLASS to TYPE, this deallocation
> seems to be done properly (valgrind shows no leak), and the dump looks like
> this:
>
> [...]
Based on this observation, I cooked up a draft patch that tries to modify the
code which does the freeing for TYPEs and make it work for CLASSes:
Index: gcc/fortran/trans-expr.c
===
--- gcc/fortran/trans-expr.c(revision 247083)
+++ gcc/fortran/trans-expr.c(working copy)
@@ -6131,15 +6131,26 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol *
/* Allocatable scalar function results must be freed and nullified
after use. This necessitates the creation of a temporary to
hold the result to prevent duplicate calls. */
- if (!byref && sym->ts.type != BT_CHARACTER
- && sym->attr.allocatable && !sym->attr.dimension)
+ if (!byref && sym->ts.type != BT_CHARACTER)
{
- tmp = gfc_create_var (TREE_TYPE (se->expr), NULL);
- gfc_add_modify (&se->pre, tmp, se->expr);
- se->expr = tmp;
- tmp = gfc_call_free (tmp);
- gfc_add_expr_to_block (&post, tmp);
- gfc_add_modify (&post, se->expr, build_int_cst (TREE_TYPE (se->expr),
0));
+ if (sym->attr.allocatable && !sym->attr.dimension)
+ {
+ tmp = gfc_create_var (TREE_TYPE (se->expr), NULL);
+ gfc_add_modify (&se->pre, tmp, se->expr);
+ se->expr = tmp;
+ gfc_add_expr_to_block (&post, gfc_call_free (tmp));
+ gfc_add_modify (&post, tmp, build_int_cst (TREE_TYPE (tmp), 0));
+ }
+ else if (sym->ts.type == BT_CLASS && CLASS_DATA (sym)->attr.allocatable
+ && !CLASS_DATA (sym)->attr.dimension)
+ {
+ tmp = gfc_create_var (TREE_TYPE (se->expr), NULL);
+ gfc_add_modify (&se->pre, tmp, se->expr);
+ se->expr = tmp;
+ tmp = gfc_class_data_get (tmp);
+ gfc_add_expr_to_block (&post, gfc_call_free (tmp));
+ gfc_add_modify (&post, tmp, build_int_cst (TREE_TYPE (tmp), 0));
+ }
}
/* If we have a pointer function, but we don't want a pointer, e.g.
Unfortunately it does not work, because it only creates a copy of the class
container, but frees up the class data too early:
polymorphic_operators_memory_leaks ()
{
static struct a_type_t a = {.x=1.0e+0};
static struct a_type_t b = {.x=2.0e+0};
{
struct __class_a_type_m_A_type_t_a D.3528;
struct __class_a_type_m_A_type_t_a D.3529;
D.3528 = add_a_type (&a, &b);
D.3529 = D.3528;
__builtin_free ((void *) D.3528._data);
D.3528._data = 0B;
assign_a_type (&a, D.3529._data);
}
}
I guess I could use some help here (I always tend to get a bit lost in the
trans-stage). Paul, do you by chance have any idea how to handle this properly?
[Bug target/79430] [7/8 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 Thomas Koenig changed: What|Removed |Added Status|WAITING |NEW Component|fortran |target --- Comment #69 from Thomas Koenig --- The problem is in gcc/reg-stack.c. Doing "svn up -r 244920 reg-stack.c" fixes the regression, based on trunk as of a few days ago. I'll do some more digging to try to narrow this down further to a specific commit. Jakub, can you work with that or do you need more info?
[Bug fortran/80484] Three syntax errors involving derived-type I/O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80484 --- Comment #13 from Jerry DeLisle --- Author: jvdelisle Date: Sun Apr 23 15:49:16 2017 New Revision: 247084 URL: https://gcc.gnu.org/viewcvs?rev=247084&root=gcc&view=rev Log: 2017-04-23 Jerry DeLisle PR fortran/80484 * io.c (format_lex): Check for '/' and set token to FMT_SLASH. (check_format): Move FMT_DT checking code to data_desc section. * module.c (gfc_match_use): Include the case of INTERFACE_DTIO. PR fortran/80484 * gfortran.dg/dtio_29.f03: New test. Added: trunk/gcc/testsuite/gfortran.dg/dtio_29.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/io.c trunk/gcc/fortran/module.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/80484] Three syntax errors involving derived-type I/O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80484 --- Comment #14 from Jerry DeLisle --- Fixed on trunk, will backport to 7 as soon as permitted.
[Bug fortran/71729] -Wl,-z,noexecstack Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71729 Zaak changed: What|Removed |Added CC||zbeekman at gmail dot com --- Comment #3 from Zaak --- > It means i have to submit the bug to mpich developers that add this flag in > the alias mpif90 ? Well I'm guessing that it's the fedora package system that's adding the -Wl,-z,noexecstack to the mpich wrapper... but I could be wrong, it could be MPICH itself. But either way, the bug is with MPICH or the fedora package of MPICH.
[Bug target/79430] [7/8 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 Thomas Koenig changed: What|Removed |Added Target Milestone|7.0 |7.2 --- Comment #70 from Thomas Koenig --- r244920 works, r244921 fails, so this must be it.
[Bug tree-optimization/80497] New: gcc ICE at -O1 and above on valid code on x86_64-linux-gnu in "tree_to_uhwi"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80497
Bug ID: 80497
Summary: gcc ICE at -O1 and above on valid code on
x86_64-linux-gnu in "tree_to_uhwi"
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: helloqirun at gmail dot com
Target Milestone: ---
The following valid code causes an ICE when compiled with the current gcc trunk
at -O1 and above on x86_64-linux-gnu in 64-bit mode
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/home/absozero/trunk/root-gcc/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/absozero/trunk/root-gcc
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 8.0.0 20170423 (experimental) [trunk revision 247083] (GCC)
$ gcc-trunk -O1 abc.c
abc.c: In function ‘fn1’:
abc.c:5:6: internal compiler error: in tree_to_uhwi, at tree.c:7346
void fn1() {
^~~
0xe336c7 tree_to_uhwi(tree_node const*)
../../gcc/gcc/tree.c:7346
0x12af2ac get_int_range
../../gcc/gcc/gimple-ssa-sprintf.c:956
0x12b039d set_width
../../gcc/gcc/gimple-ssa-sprintf.c:676
0x12b039d parse_directive
../../gcc/gcc/gimple-ssa-sprintf.c:3146
0x12b039d compute_format_length
../../gcc/gcc/gimple-ssa-sprintf.c:3256
0x12b4655 handle_gimple_call
../../gcc/gcc/gimple-ssa-sprintf.c:3688
0x12b5427 execute
../../gcc/gcc/gimple-ssa-sprintf.c:3716
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$ cat abc.c
extern char buf[];
#define T(fmt, ...) __builtin_sprintf(buf, fmt, __VA_ARGS__);
const __int128_t sint128_max = (__int128_t)1
<< sizeof sint128_max * __CHAR_BIT__ - 2;
void fn1() {
__int128_t si128 = sint128_max;
T("%*i", si128)
}
[Bug c++/80265] __builtin_{memcmp,memchr,strlen} are not usable in constexpr functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265 --- Comment #18 from Pedro Alves --- I sent a patch using the __builtin_constant_p idea: https://gcc.gnu.org/ml/gcc-patches/2017-04/msg00983.html
[Bug sanitizer/80498] New: Simple program with address sanitizer and regex hangs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80498
Bug ID: 80498
Summary: Simple program with address sanitizer and regex hangs
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc at zutt dot org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
Target Milestone: ---
If I compile the below two files with "g++-6 -fsanitize=address a.cpp m.cpp"
and then run "./a.out", the program hangs forever, while without sanitize flag
it works as expected.
If I comment out the regex var 're' in m.cpp, the problem also disappears.
Is there some incompatibility with the regex library, and can that be solved or
can the library be excluded from checks?
I'm on macOS Sierra version 10.12.4 with g++-6 (Homebrew GCC 6.3.0_1) 6.3.0.
Thanks!
===
#include
#include
#include
using namespace std;
void a(const std::string &s)
{
regex re_a("foo (.+)");
smatch pieces;
if (regex_match(s, pieces, re_a))
{
cout << "foo with " << pieces[1].str() << endl;
}
}
// m.cpp
#include
#include
void a(const std::string &s);
int main(int argc, char** argv)
{
std::regex re("123");
a("foo test 123");
}
[Bug rtl-optimization/80499] New: gcc ICE on RTL code on x86_64-linux-gnu in "extract_insn"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80499
Bug ID: 80499
Summary: gcc ICE on RTL code on x86_64-linux-gnu in
"extract_insn"
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: helloqirun at gmail dot com
Target Milestone: ---
The following valid RTL fragment causes an ICE when compiled with the current
gcc trunk on x86_64-linux-gnu in 32-bit mode. The 64-bit mode works fine.
$ gcc-trunk --version
gcc-trunk (GCC) 8.0.0 20170423 (experimental) [trunk revision 247083]
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ gcc-trunk -m32 abc1.c
abc1.c: In function ‘test_1’:
abc1.c:20:1: error: unrecognizable insn:
}
^
(insn 2 6 7 2 (set (mem:DI (pre_dec (reg/f:SI 7 sp)) [0 S8 A8])
(reg/f:SI 6 bp)) -1
(nil))
abc1.c:20:1: internal compiler error: in extract_insn, at recog.c:2311
0xb19d38 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/gcc/rtl-error.c:108
0xb19d69 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc/gcc/rtl-error.c:116
0xae7a6f extract_insn(rtx_insn*)
../../gcc/gcc/recog.c:2311
0xae7ac1 extract_insn_cached(rtx_insn*)
../../gcc/gcc/recog.c:2201
0x86a3a7 cleanup_subreg_operands(rtx_insn*)
../../gcc/gcc/final.c:3152
0x86c551 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
../../gcc/gcc/final.c:2948
0x86da21 final(rtx_insn*, _IO_FILE*, int)
../../gcc/gcc/final.c:2051
0x86df09 rest_of_handle_final
../../gcc/gcc/final.c:4489
0x86df09 execute
../../gcc/gcc/final.c:4562
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$ cat abc1.c
int __RTL (startwith ("final")) test_1 ()
{
(function ""
(insn-chain
(block 2
(edge-from entry )
(cnote 6 [bb 2] NOTE_INSN_BASIC_BLOCK)
(cinsn 2 (set (mem:DI (pre_dec(reg sp)) [0 ])
(reg bp)) )
) (block 3
(cinsn 3 (parallel [
(set (reg ax )
(plus(reg ax )
(const_int 4)))
]) )
) (block 4
(edge-from 2)
(cnote 7 [bb 4] NOTE_INSN_BASIC_BLOCK)
) (cbarrier 0) ) )
}
[Bug rtl-optimization/80500] New: [7/8 Regression] ICE: internal consistency failure (error: invalid rtl sharing found in the insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80500
Bug ID: 80500
Summary: [7/8 Regression] ICE: internal consistency failure
(error: invalid rtl sharing found in the insn)
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: x86_64-pc-linux-gnu
gcc-7.0.0-alpha20170416 and gcc-8.0.0-alpha20170423 snapshots ICE when
compiling the following snippet w/ -O2 -funroll-loops -ftree-loop-if-convert
-fvariable-expansion-in-unroller:
char ja;
void
hd (int ut)
{
while (ut != 0)
{
ja = (ut >= 0) + 1;
++ut;
}
}
% x86_64-pc-linux-gnu-gcc-7.0.0-alpha20170416 -O2 -funroll-loops
-ftree-loop-if-convert -fvariable-expansion-in-unroller -c exs8cfjp.c
exs8cfjp.c: In function 'hd':
exs8cfjp.c:11:1: error: invalid rtl sharing found in the insn
}
^
(insn 216 34 33 8 (parallel [
(set (subreg:QI (reg:SI 92) 0)
(plus:QI (subreg:QI (reg:SI 92) 0)
(reg:QI 97)))
(clobber (reg:CC 17 flags))
]) -1
(nil))
exs8cfjp.c:11:1: error: shared rtx
(subreg:QI (reg:SI 92) 0)
exs8cfjp.c:11:1: internal compiler error: internal consistency failure
[Bug target/80501] New: [6/7/8 Regression] Wrong code w/ a signed char, a shift, and a conversion to int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80501
Bug ID: 80501
Summary: [6/7/8 Regression] Wrong code w/ a signed char, a
shift, and a conversion to int
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: x86_64-pc-linux-gnu
gcc starting from 6 apparently miscompiles the following snippet at -O1, -O2,
-Os, -O3, or -Ofast:
signed char tb = 0;
static signed char
um (int ov, int rc)
{
return ov << rc;
}
int
main (void)
{
return um(tb >= 0, 7) >= 1;
}
% gcc-5.4.0 -O0 henaauhf.c && ./a.out
% gcc-5.4.0 -O1 henaauhf.c && ./a.out
% x86_64-pc-linux-gnu-gcc-7.0.0-alpha20170416 -O0 henaauhf.c && ./a.out
% x86_64-pc-linux-gnu-gcc-7.0.0-alpha20170416 -O1 henaauhf.c && ./a.out
zsh: exit 1 ./a.out
[Bug c/80502] New: Provide macro to indicate OpenMP SIMD support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80502 Bug ID: 80502 Summary: Provide macro to indicate OpenMP SIMD support Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: e...@coeus-group.com Target Milestone: --- Created attachment 41250 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41250&action=edit define _OPENMP_SIMD when -fopenmp-simd or -fopenmp is passed _OPENMP is (correctly) only defined for full OpenMP; when only -fopenmp-simd is used there doesn't seem to be any way to detect in the preprocessor that the compiler supports OpenMP SIMD pragmas. It would be nice if there were a macro to determine whether they are supported so we could do something like #if (defined(_OPENMP) && (_OPENMP >= 201307L)) || \ (defined(_OPENMP_SIMD) && (_OPENMP_SIMD >= 201307L)) #pragma omp simd #endif AFAIK ICC is the only compiler with a feature like -fopenmp-simd (they call it -openmp-simd), and they don't define anything either. I've reported the issue to them, but in the meantime it seems GCC can choose whatever it wants without creating any compatibility issues. Defining _OPENMP_SIMD to the version of OpenMP supported (just like _OPENMP does) seems logicial to me. I've attached a fairly trivial patch.
[Bug fortran/80477] [OOP] Polymorphic function result generates memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80477 --- Comment #10 from Stefano Zaghi --- Dear all, here https://github.com/szaghi/leaks_hunter you can find my report. Into the report I shown all the test I have done, I provide the sources and the scripts I used to generate them. As FortranFan and Francesco Salvadore pointed out, it seems that a simple workaround exists: add an allocatable into types which have only static components and have polymorphic result-functions. I'll try this workaround into the real program after 25 April. I hope this report you for your patch. My best regards.
