[Bug middle-end/90478] [10 Regression] ICE in emit_case_dispatch_table at gcc/stmt.c:796
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90478 --- Comment #11 from Martin Liška --- Author: marxin Date: Fri May 17 07:21:46 2019 New Revision: 271311 URL: https://gcc.gnu.org/viewcvs?rev=271311&root=gcc&view=rev Log: Remove a test-case that leads to a huge stack (and file) allocation (PR middle-end/90478). 2019-05-17 Martin Liska PR middle-end/90478 * gcc.dg/tree-ssa/pr90478-2.c: Remove. Removed: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr90478-2.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug middle-end/90478] [10 Regression] ICE in emit_case_dispatch_table at gcc/stmt.c:796
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90478 Martin Liška changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Martin Liška --- Fixed now.
[Bug c++/90495] Incorrect parsing of a()->b construction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90495 --- Comment #2 from Martin Liška --- Author: marxin Date: Fri May 17 07:22:00 2019 New Revision: 271312 URL: https://gcc.gnu.org/viewcvs?rev=271312&root=gcc&view=rev Log: Handle a location with NULL as a file (PR driver/90495) 2019-05-17 Martin Liska PR driver/90495 * toplev.c (output_stack_usage): With LTO and sanitizer it happens that a global ctor (_GLOBAL__sub_I_00099_0_main) has no file location. Modified: trunk/gcc/ChangeLog trunk/gcc/toplev.c
[Bug c++/90495] Incorrect parsing of a()->b construction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90495 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #3 from Martin Liška --- (In reply to Martin Liška from comment #2) > Author: marxin > Date: Fri May 17 07:22:00 2019 > New Revision: 271312 > > URL: https://gcc.gnu.org/viewcvs?rev=271312&root=gcc&view=rev > Log: > Handle a location with NULL as a file (PR driver/90495) > > 2019-05-17 Martin Liska > > PR driver/90495 > * toplev.c (output_stack_usage): With LTO and sanitizer it > happens that a global ctor (_GLOBAL__sub_I_00099_0_main) > has no file location. > > Modified: > trunk/gcc/ChangeLog > trunk/gcc/toplev.c ^--- Sorry, a wrong bug reference.
[Bug driver/90496] ICE in RTL pass pro_and_epilogue when all of `-flto -fsanitize=address -fstack-usage` are used on trivial source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90496 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Martin Liška --- Fixed.
[Bug driver/90496] ICE in RTL pass pro_and_epilogue when all of `-flto -fsanitize=address -fstack-usage` are used on trivial source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90496 --- Comment #7 from Martin Liška --- Author: marxin Date: Fri May 17 07:24:28 2019 New Revision: 271313 URL: https://gcc.gnu.org/viewcvs?rev=271313&root=gcc&view=rev Log: Handle a location with NULL as a file (PR driver/90496) 2019-05-17 Martin Liska PR driver/90496 * toplev.c (output_stack_usage): With LTO and sanitizer it happens that a global ctor (_GLOBAL__sub_I_00099_0_main) has no file location. Modified: trunk/gcc/ChangeLog
[Bug middle-end/90514] Issue about enum type in gcc tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90514 --- Comment #1 from Andrew Pinski --- Are you saying the precision should be 1? If so then no, that would be invalid as in C, enum have the full range of the underlying type and is well defined to have values of 3 or higher in the enum variable.
[Bug c++/90484] [9/10 Regression] ICE in equal_mem_array_ref_p at gcc/tree-ssa-scopedtables.c:550 since r270433 on i586
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90484 --- Comment #6 from Martin Liška --- (In reply to Jakub Jelinek from comment #5) > Author: jakub > Date: Thu May 16 21:45:34 2019 > New Revision: 271299 > > URL: https://gcc.gnu.org/viewcvs?rev=271299&root=gcc&view=rev > Log: > PR c++/90484 > * tree-ssa-scopedtables.c (equal_mem_array_ref_p): Don't assert that > sz0 is equal to sz1, instead return false in that case. > > Modified: > trunk/gcc/ChangeLog > trunk/gcc/tree-ssa-scopedtables.c Thanks Jakub for the patch. Are you planning to backport that to GCC-9 branch soon?
[Bug target/90513] Pwerplcelfv2 :R2 is not updated to the TOC base .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90513 --- Comment #2 from Umesh Kalappa --- Created attachment 46369 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46369&action=edit testcase
[Bug middle-end/90478] [10 Regression] ICE in emit_case_dispatch_table at gcc/stmt.c:796
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90478 David Binderman changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #13 from David Binderman --- >The test-case does not makes sense The test case is accepted fine by previous versions of gcc and current version of clang. It looks like good code to me. >I'm going to remove the test-case. I'd be happier if the test case were re-instated and gcc trunk was improved to accept the test case. If not, then going back to previous behaviour would be ok too. At least gcc accepted the code then.
[Bug target/90513] powerpcelfv2 :R2 is not updated to the TOC base .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90513 --- Comment #3 from Umesh Kalappa --- options used : -mcpu=e6500 -mno-altivec -mabi=no-altivec -mabi=elfv2 -mcmodel=medium -mhard-float -m64
[Bug middle-end/90478] [10 Regression] ICE in emit_case_dispatch_table at gcc/stmt.c:796
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90478 --- Comment #14 from Martin Liška --- (In reply to David Binderman from comment #13) > >The test-case does not makes sense > > The test case is accepted fine by previous versions of gcc > and current version of clang. It looks like good code to me. Yes, the test-case gcc/testsuite/gcc.dg/tree-ssa/pr90478-2.c was a copy of ./gcc/testsuite/gcc.c-torture/compile/pr42347.c with a huge param value of jump-table-max-growth-ratio-for-size=2147483647. That does not make sense to test. Your original test-case is in trunk: ./gcc/testsuite/gcc.dg/tree-ssa/pr90478.c > > >I'm going to remove the test-case. > > I'd be happier if the test case were re-instated and > gcc trunk was improved to accept the test case. > > If not, then going back to previous behaviour would be ok too. > At least gcc accepted the code then.
[Bug middle-end/90478] [10 Regression] ICE in emit_case_dispatch_table at gcc/stmt.c:796
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90478 Martin Liška changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #15 from Martin Liška --- Closing again.
[Bug c++/88752] [8 Regression] ICE in enclosing_instantiation_of, at cp/pt.c:13328
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88752 Matthias Kretz changed: What|Removed |Added Known to work||7.4.0, 9.1.0 Known to fail||8.3.0 --- Comment #11 from Matthias Kretz --- The following link contains a minor modification of the testcase to really make the code valid again: https://godbolt.org/z/FTe8Ax At this point, this PR has low priority for me (since GCC 9 is out).
[Bug c++/90484] [9 Regression] ICE in equal_mem_array_ref_p at gcc/tree-ssa-scopedtables.c:550 since r270433 on i586
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90484 Jakub Jelinek changed: What|Removed |Added Known to work||10.0 Summary|[9/10 Regression] ICE in|[9 Regression] ICE in |equal_mem_array_ref_p at|equal_mem_array_ref_p at |gcc/tree-ssa-scopedtables.c |gcc/tree-ssa-scopedtables.c |:550 since r270433 on i586 |:550 since r270433 on i586 Known to fail|10.0| --- Comment #7 from Jakub Jelinek --- Yes.
[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 --- Comment #39 from Richard Biener --- Author: rguenth Date: Fri May 17 08:10:58 2019 New Revision: 271314 URL: https://gcc.gnu.org/viewcvs?rev=271314&root=gcc&view=rev Log: 2019-05-17 Richard Biener Backport from mainline 2019-05-07 Richard Biener PR tree-optimization/90316 * tree-ssa-alias.h (get_continuation_for_phi): Take walking limit by reference. (walk_non_aliased_vuses): Take walking limit argument. * tree-ssa-alias.c (maybe_skip_until): Take limit and abort walking if it is reached instead of just counting. (get_continuation_for_phi): Likewise. (walk_non_aliased_vuses): Likewise, instead of leaving counter limiting to the callback. * tree-ssa-sccvn.c (vn_reference_lookup_2): Adjust. (vn_reference_lookup_3): Likewise. (vn_reference_lookup_pieces): Likewise. (vn_reference_lookup): Likewise. * tree-ssa-pre.c (translate_vuse_through_block): Limit walking. * tree-ssa-scopedtables.c (vuse_eq): Adjust. (avail_exprs_stack::lookup_avail_expr): Likewise. 2019-05-06 Richard Biener PR tree-optimization/90316 * tree-ssa-alias.c (maybe_skip_until): Pass in target BB, compute target on demand. (get_continuation_for_phi): Remove code walking stmts to get to a target virtual operand which could end up being quadratic. Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/tree-ssa-alias.c branches/gcc-9-branch/gcc/tree-ssa-alias.h branches/gcc-9-branch/gcc/tree-ssa-pre.c branches/gcc-9-branch/gcc/tree-ssa-sccvn.c branches/gcc-9-branch/gcc/tree-ssa-scopedtables.c
[Bug c++/89576] [8 Regression] constexpr not working if implicitly captured in a lambda in a function template (gcc 8.3+)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89576 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #5 from Martin Liška --- @Jason: Can the bug be marked as resolved?
[Bug target/90513] powerpcelfv2 :R2 is not updated to the TOC base .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90513 --- Comment #4 from Richard Biener --- *** Bug 90512 has been marked as a duplicate of this bug. ***
[Bug target/90512] Pwerplcelfv2 :R2 is not updated to the TOC base .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90512 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Richard Biener --- dup has further comments. *** This bug has been marked as a duplicate of bug 90513 ***
[Bug lto/90500] ICE error in copy_forbiden
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90500 --- Comment #10 from Martin Liška --- (In reply to Guobing from comment #8) > Hi, I am the original reporter of this bug. This problem seems not happen on > GCC8 while do on GCC9. We try to use FMV (target_clone) for some of the > GlibC libm functions which leads us to this issue. From the Patch below, > seems this fix the GCC9 crash issue but still not allow target_clone to be > used together with alias. But this is allowed in GCC8 as we can compile and > run well under GCC8. So could you help to make the behavior the same as GCC8 > or tell us a way to walkaround it? Well, maybe that was allowed in GCC8, but it was not intentional. Please describe me your use case and we can come up to a solution that will use target_clone (or target attribute)?
[Bug tree-optimization/90510] [10 Regression] Unnecessary permutation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90510
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Target Milestone|--- |10.0
--- Comment #1 from Richard Biener ---
I will have a look.
Before the rev. we expanded from
[local count: 1073741825]:
_1 = BIT_FIELD_REF ;
_2 = BIT_FIELD_REF ;
_3 = _1 + _2;
_4 = BIT_FIELD_REF ;
z_6 = {_3, _4};
while after we do
[local count: 1073741824]:
_1 = BIT_FIELD_REF ;
_2 = BIT_FIELD_REF ;
_3 = _1 + _2;
_7 = {_3, _3};
z_6 = VEC_PERM_EXPR ;
Testcase with the same behavior before and after the rev which we should
improve together with fixing the regression:
typedef double __v2df __attribute__ ((__vector_size__ (16)));
typedef long __v2di __attribute__ ((__vector_size__ (16)));
__v2df
_mm_add_sd (__v2df x, __v2df y)
{
double tem = x[0] + y[0];
return __builtin_shuffle ( x, (__v2df) { tem, tem }, (__v2di) { 2, 1 } );
}
[Bug tree-optimization/88440] size optimization of memcpy-like code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88440 --- Comment #9 from Martin Liška --- So comparison all files in wrf, I've got: ╔═╤╤╤═╗ ║ Filename│ Before │ After │ Change ║ ╠═╪╪╪═╣ ║ module_configure.fppized.f90│ 127.81 │ 163.39 │ 127.84% ║ ║ d1fgkb.fppized.f90 │ 0.21 │ 0.23 │ 109.52% ║ ║ solve_interface.fppized.f90 │ 0.35 │ 0.38 │ 108.57% ║ ║ module_ltng_crmpr92.fppized.f90 │ 0.28 │ 0.3│ 107.14% ║ ║ module_cu_kf.fppized.f90│ 1.42 │ 1.51 │ 106.34% ║ ║ mradbg.fppized.f90 │ 0.32 │ 0.34 │ 106.25% ║ ║ module_sf_pxlsm.fppized.f90 │ 0.55 │ 0.58 │ 105.45% ║ ║ module_domain_type.fppized.f90 │ 0.19 │ 0.2│ 105.26% ║ ║ module_shallowcu_driver.fppized.f90 │ 0.19 │ 0.2│ 105.26% ║ ║ module_bl_gfs.fppized.f90 │ 0.78 │ 0.82 │ 105.13% ║ ║ module_bl_myjurb.fppized.f90│ 0.78 │ 0.82 │ 105.13% ║ ║ Meat.fppized.f90│ 0.39 │ 0.41 │ 105.13% ║ ... So the only significant offender is module_configure.fppized.f90 file. Let me profile it.
[Bug target/90513] asm thunks do not work on PowerPC64/VxWorks (kernel mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90513 Eric Botcazou changed: What|Removed |Added Target|powerpc64le-*-* |powerpc64-wrs-vxworks Status|UNCONFIRMED |NEW Last reconfirmed||2019-05-17 Summary|powerpcelfv2 :R2 is not |asm thunks do not work on |updated to the TOC base . |PowerPC64/VxWorks (kernel ||mode) Ever confirmed|0 |1
[Bug tree-optimization/90510] [10 Regression] Unnecessary permutation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90510
--- Comment #2 from Richard Biener ---
So we have
(insn 10 9 11 2 (set (reg:V2DF 92)
(vec_duplicate:V2DF (reg/v:DF 84 [ tem ]))) "t.c":8:42 2984
{vec_dupv2df}
(expr_list:REG_DEAD (reg/v:DF 84 [ tem ])
(nil)))
(insn 11 10 16 2 (set (reg:V2DF 91)
(vec_merge:V2DF (reg:V2DF 92)
(reg/v:V2DF 87 [ x ])
(const_int 1 [0x1]))) "t.c":8:10 2983 {sse2_movsd}
(expr_list:REG_DEAD (reg:V2DF 92)
(expr_list:REG_DEAD (reg/v:V2DF 87 [ x ])
(nil
and nothing figures out insn 10 is unnecessary because the upper half of 92
is dead. I somehow expected combine/simplify-rtx to merge these but I
guess without target support it is hard to see that sse2_movsd can handle
sth like a paradoxical vector subreg of the scalar:
(insn 11 10 16 2 (set (reg:V2DF 91)
(vec_merge:V2DF (subreg:V2DF (reg:DF 84) 0)
(reg/v:V2DF 87 [ x ])
(const_int 1 [0x1]))) "t.c":8:10 2983 {sse2_movsd}
(expr_list:REG_DEAD (reg:V2DF 92)
(expr_list:REG_DEAD (reg/v:V2DF 87 [ x ])
(nil
Now we can pattern-match both
_4 = BIT_FIELD_REF ;
z_6 = {_3, _4};
and
_7 = {_3, _3};
z_6 = VEC_PERM_EXPR ;
to
z_6 = BIT_INSERT_EXPR
which we can hope to be expanded better.
[Bug tree-optimization/88440] size optimization of memcpy-like code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88440 --- Comment #10 from Martin Liška --- > So the only significant offender is module_configure.fppized.f90 file. Let > me profile it. Time profile before/after: ╔══╤╤╤═╗ ║ PASS │ Before │ After │ Change ║ ╠══╪╪╪═╣ ║ backwards jump threading │ 6.29 │ 6.16 │ 97.93% ║ ║ integrated RA│ 6.76 │ 6.41 │ 94.82% ║ ║ tree SSA incremental │ 9.01 │ 11.16 │ 123.86% ║ ║ LRA create live ranges │ 15.68 │ 40.02 │ 255.23% ║ ║ PRE │ 23.24 │ 32.32 │ 139.07% ║ ║ alias stmt walking │ 27.69 │ 28.75 │ 103.83% ║ ║ phase opt and generate │ 124.13 │ 163.95 │ 132.08% ║ ║ TOTAL│ 125.39 │ 165.17 │ 131.73% ║ ╚══╧╧╧═╝ Richi, do you want a perf report or do you come up with a patch that will introduce the aforementioned params?
[Bug lto/90500] ICE error in copy_forbiden
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90500
--- Comment #11 from Guobing ---
(In reply to Martin Liška from comment #10)
> (In reply to Guobing from comment #8)
> > Hi, I am the original reporter of this bug. This problem seems not happen on
> > GCC8 while do on GCC9. We try to use FMV (target_clone) for some of the
> > GlibC libm functions which leads us to this issue. From the Patch below,
> > seems this fix the GCC9 crash issue but still not allow target_clone to be
> > used together with alias. But this is allowed in GCC8 as we can compile and
> > run well under GCC8. So could you help to make the behavior the same as GCC8
> > or tell us a way to walkaround it?
>
> Well, maybe that was allowed in GCC8, but it was not intentional. Please
> describe me your use case and we can come up to a solution that will use
> target_clone (or target attribute)?
The background is that, we want to try optimize libm with avx2/avx512, and
found that not all the libm math functions will have benefit when we generally
use 'arch=haswell' or 'arch=skylake-avx512' to compile libm. So we picked those
'good' libm math functions to add FMV attribute like target_clone("default",
"arch=haswell", "arch=skylake-avx512") to get performance benefit. The alias is
used in libm code by default. I have no idea why these two are conflicting that
not allowed by GCC9.
[Bug lto/90500] ICE error in copy_forbiden
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90500
--- Comment #12 from Martin Liška ---
> The background is that, we want to try optimize libm with avx2/avx512, and
> found that not all the libm math functions will have benefit when we
> generally use 'arch=haswell' or 'arch=skylake-avx512' to compile libm. So we
> picked those 'good' libm math functions to add FMV attribute like
> target_clone("default", "arch=haswell", "arch=skylake-avx512") to get
> performance benefit. The alias is used in libm code by default. I have no
> idea why these two are conflicting that not allowed by GCC9.
That makes sense. Based on the test-case you provided, you just want:
__attribute__((target_clones("default", "arch=haswell",
"arch=skylake-avx512")))
double
__tanh (double x)
{
double t, z;
int32_t jx, ix, lx;
do { ieee_double_shape_type ew_u; ew_u.value = (x); (jx) = ew_u.parts.msw;
(lx) = ew_u.parts.lsw; } while (0);
ix = jx & 0x7fff;
...
}
extern __typeof (__tanh) tanh __attribute__ ((weak, alias ("__tanh"))); //
__attribute__ ((__copy__ (__tanh)));
You don't want to use __copy__ attribute because it's responsible for copying
of target_clone attribute to the alias.
And it does not make sense to create clones of an alias.
[Bug tree-optimization/88440] size optimization of memcpy-like code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88440 --- Comment #11 from rguenther at suse dot de --- On Fri, 17 May 2019, marxin at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88440 > > --- Comment #10 from Martin Liška --- > > So the only significant offender is module_configure.fppized.f90 file. Let > > me profile it. > > Time profile before/after: > > ╔══╤╤╤═╗ > ║ PASS │ Before │ After │ Change ║ > ╠══╪╪╪═╣ > ║ backwards jump threading │ 6.29 │ 6.16 │ 97.93% ║ > ║ integrated RA│ 6.76 │ 6.41 │ 94.82% ║ > ║ tree SSA incremental │ 9.01 │ 11.16 │ 123.86% ║ > ║ LRA create live ranges │ 15.68 │ 40.02 │ 255.23% ║ > ║ PRE │ 23.24 │ 32.32 │ 139.07% ║ > ║ alias stmt walking │ 27.69 │ 28.75 │ 103.83% ║ > ║ phase opt and generate │ 124.13 │ 163.95 │ 132.08% ║ > ║ TOTAL│ 125.39 │ 165.17 │ 131.73% ║ > ╚══╧╧╧═╝ > > Richi, do you want a perf report or do you come up with a patch that will > introduce the aforementioned params? Can you share -fopt-report-loop differences? From the above I would guess we split a lot of loops, meaning the memcpy/memmove/memset calls are in the "middle" and we have to split loops (how many calls are detected here?). If that's true another way would be to only allow calls at head or tail position, thus a single non-builtin partition.
[Bug tree-optimization/88440] size optimization of memcpy-like code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88440 --- Comment #12 from Martin Liška --- > > Can you share -fopt-report-loop differences? From the above I would > guess we split a lot of loops, meaning the memcpy/memmove/memset > calls are in the "middle" and we have to split loops (how many > calls are detected here?). If that's true another way would be > to only allow calls at head or tail position, thus a single > non-builtin partition. I newly see ~1400 lines: module_configure.fppized.f90:7993:0: optimized: Loop 10 distributed: split to 0 loops and 1 library calls. module_configure.fppized.f90:7995:0: optimized: Loop 11 distributed: split to 0 loops and 1 library calls. module_configure.fppized.f90:8000:0: optimized: Loop 15 distributed: split to 0 loops and 1 library calls. module_configure.fppized.f90:8381:0: optimized: Loop 77 distributed: split to 0 loops and 1 library calls. module_configure.fppized.f90:8383:0: optimized: Loop 78 distributed: split to 0 loops and 1 library calls. module_configure.fppized.f90:8498:0: optimized: Loop 105 distributed: split to 0 loops and 1 library calls. module_configure.fppized.f90:9742:0: optimized: Loop 169 distributed: split to 0 loops and 1 library calls. module_configure.fppized.f90:9978:0: optimized: Loop 207 distributed: split to 0 loops and 1 library calls. module_configure.fppized.f90:9979:0: optimized: Loop 208 distributed: split to 0 loops and 1 library calls. module_configure.fppized.f90:9980:0: optimized: Loop 209 distributed: split to 0 loops and 1 library calls. module_configure.fppized.f90:9981:0: optimized: Loop 210 distributed: split to 0 loops and 1 library calls. ...
[Bug go/90482] [10 regression] Many 32-bit Solaris/SPARC tests FAIL with SIGBUS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90482 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-05-17 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Eric Botcazou --- I have them too.
[Bug middle-end/90514] Issue about enum type in gcc tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90514 --- Comment #2 from JunMa --- (In reply to Andrew Pinski from comment #1) > Are you saying the precision should be 1? If so then no, that would be > invalid as in C, enum have the full range of the underlying type and is well > defined to have values of 3 or higher in the enum variable. Thanks for explain. I had got confused by the comments in vrp pass. the condition if ((kind != ENUM1) && (kind != ENUM2)) is not always false, and cannot be folded to if (0). Also the code deals with pr23046 is out of data, and should be removed.
[Bug go/90482] [10 regression] Many 32-bit Solaris/SPARC tests FAIL with SIGBUS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90482 --- Comment #3 from Eric Botcazou --- It's not obvious to me why this would have anything to do with the calling convention on SPARC 32-bit, which is very reasonable. For example, it's not like M68k where pointers and integers are passed differently.
[Bug tree-optimization/90106] builtin sqrt() ignoring libm's sqrt call result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90106 --- Comment #11 from junma at gcc dot gnu.org --- Author: junma Date: Fri May 17 10:13:29 2019 New Revision: 271319 URL: https://gcc.gnu.org/viewcvs?rev=271319&root=gcc&view=rev Log: PR tree-optimization/90106 * gcc.dg/cdce3.c: New test. Added: trunk/gcc/testsuite/gcc.dg/cdce3.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug target/90513] asm thunks do not work on PowerPC64/VxWorks (kernel mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90513 --- Comment #5 from Eric Botcazou --- Created attachment 46370 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46370&action=edit Fix or workaound Tested on various PowerPC ports.
[Bug c++/90516] New: Strange behaviour of code if function no return value and code embraced by try..catch with opt flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90516
Bug ID: 90516
Summary: Strange behaviour of code if function no return value
and code embraced by try..catch with opt flags
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: matszpk at interia dot pl
Target Milestone: ---
Created attachment 46371
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46371&action=edit
sample program preprocessed file
OS: Arch Linux 2019 (updated in 2019-05-12).
gcc -v output:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/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
--enable-cet=auto
Thread model: posix
gcc version 8.3.0 (GCC)
I encountered that bug when I trying to test some program that have bug: a
missing return in loading file function that code was embraced by try...catch.
Due to this bug and enabled optimization's flags program aborts due to double
free of the memory and it was strange behaviour of this function.
Later, I wrote sample program that load some string from file and doing nothing
this same bug (missing return) with code embraced by try..catch. If program was
compiled with optimizations flags (-O3) then and if file was exist and then
program print out exception in by statement in catch clause (just run clause)
with like: 'Exception at loading: basic_ios::clear: iostream error'.
In attachment are sample program code the preprocessed file of this sample
program.
program has been compiled following gcc command:
g++ -Wall -std=c++11 -O3 -o fstream-inc-beh fstream-inc-beh.cpp
Sample program:
---
#include
#include
#include
bool loadFile(const char* fileName)
{
try
{
std::ifstream ifs(fileName);
std::string s;
ifs >> s;
}
catch(const std::exception& ex)
{
std::cout << "Exception at loading: " << ex.what() << std::endl;
return false;
}
}
int main(int argc, const char** argv)
{
if (argc < 2)
{
std::cout << "PROGRAM file" << std::endl;
return 0;
}
if (loadFile(argv[1]))
std::cout << "OK. Loaded" << std::endl;
else
std::cout << "ERROR: Not loaded!" << std::endl;
return 0;
}
--
end of program.
warnings while compiling this program:
-
fstream-inc-beh.cpp: In function ‘bool loadFile(const char*)’:
fstream-inc-beh.cpp:18:1: warning: control reaches end of non-void function
[-Wreturn-type]
}
^
---
[Bug c++/88256] [7/8/9/10 Regression] ICE: Segmentation fault (in make_ssa_name_fn) with VLA cast, C++ FE missing DECL_EXPRs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88256 Nathan Sidwell changed: What|Removed |Added CC||nathan at gcc dot gnu.org --- Comment #9 from Nathan Sidwell --- *** Bug 90494 has been marked as a duplicate of this bug. ***
[Bug c++/90494] [7/8/9/10 Regression] ICE using a released ssaname
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90494 Nathan Sidwell changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Nathan Sidwell --- duplicate *** This bug has been marked as a duplicate of bug 88256 ***
[Bug tree-optimization/88440] size optimization of memcpy-like code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88440 --- Comment #13 from rguenther at suse dot de --- On Fri, 17 May 2019, marxin at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88440 > > --- Comment #12 from Martin Liška --- > > > > Can you share -fopt-report-loop differences? From the above I would > > guess we split a lot of loops, meaning the memcpy/memmove/memset > > calls are in the "middle" and we have to split loops (how many > > calls are detected here?). If that's true another way would be > > to only allow calls at head or tail position, thus a single > > non-builtin partition. > > I newly see ~1400 lines: > > module_configure.fppized.f90:7993:0: optimized: Loop 10 distributed: split to > 0 > loops and 1 library calls. > module_configure.fppized.f90:7995:0: optimized: Loop 11 distributed: split to > 0 > loops and 1 library calls. > module_configure.fppized.f90:8000:0: optimized: Loop 15 distributed: split to > 0 > loops and 1 library calls. > module_configure.fppized.f90:8381:0: optimized: Loop 77 distributed: split to > 0 > loops and 1 library calls. > module_configure.fppized.f90:8383:0: optimized: Loop 78 distributed: split to > 0 > loops and 1 library calls. > module_configure.fppized.f90:8498:0: optimized: Loop 105 distributed: split to > 0 loops and 1 library calls. > module_configure.fppized.f90:9742:0: optimized: Loop 169 distributed: split to > 0 loops and 1 library calls. > module_configure.fppized.f90:9978:0: optimized: Loop 207 distributed: split to > 0 loops and 1 library calls. > module_configure.fppized.f90:9979:0: optimized: Loop 208 distributed: split to > 0 loops and 1 library calls. > module_configure.fppized.f90:9980:0: optimized: Loop 209 distributed: split to > 0 loops and 1 library calls. > module_configure.fppized.f90:9981:0: optimized: Loop 210 distributed: split to > 0 loops and 1 library calls. > ... All with "0 loops"? That disputes my theory :/
[Bug c++/90516] Strange behaviour of code if function no return value and code embraced by try..catch with opt flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90516 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jonathan Wakely --- (In reply to matszpk from comment #0) > I encountered that bug when I trying to test some program that have bug: a > missing return in loading file function that code was embraced by > try...catch. Due to this bug and enabled optimization's flags program aborts > due to double free of the memory and it was strange behaviour of this > function. Because the program has a bug and its behaviour is undefined. > Later, I wrote sample program that load some string from file and doing > nothing this same bug (missing return) with code embraced by try..catch. If > program was compiled with optimizations flags (-O3) then and if file was > exist and then program print out exception in by statement in catch clause > (just run clause) with like: 'Exception at loading: basic_ios::clear: > iostream error'. The program has undefined behaviour. The only return statement in the function is the one in the catch block, so it looks like GCC is deciding to run that code unconditionally, because there's no other valid way to return from the function. You should pay attention to the warning and fix the code.
[Bug c++/88256] [7/8/9/10 Regression] ICE: Segmentation fault (in make_ssa_name_fn) with VLA cast, C++ FE missing DECL_EXPRs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88256 --- Comment #10 from Nathan Sidwell --- digging into the C++ FE's grokdeclarator shows this to be trickier than C. C has a global variable of the expression component currently being built. it hooks a COMPOUND_EXPR into there, in its own binding layer, when the grokking context is TYPENAME. C++ does not have such a mechanism. We cant just push the typedecl into the current statement list for three reasons 1) if we're in an initializer of a var decl, we'll push the typedecl /after/ the expression to which it refers. 2) if we're in a conditionally reached subexpression, we'll push the typedecl into an unconditional region of code. thing = cond ? (VLA_TYPE)expr : NULL; 3) if a components of the VLA is modified by an earlier piece of the current expression (i.e. comma operator), we'll push the typedecl before that modification. thing = (X++, (VLA_TYPE[X])expr); I also noticed that strip_typedefs reconstructs the outer array type in 90494, but because the original isn't in the canonical hash, these get different canonical_types. That seems wrong. I suspect we need to do something like: (a) create the typedecls in grokdeclarator (b) insert the decl_exprs during the gimplify walk that'll also handle the non function-scope cases, which we completely ignore right now.
[Bug tree-optimization/88440] size optimization of memcpy-like code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88440 --- Comment #14 from Martin Liška --- (In reply to rguent...@suse.de from comment #13) > On Fri, 17 May 2019, marxin at gcc dot gnu.org wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88440 > > > > --- Comment #12 from Martin Liška --- > > > > > > Can you share -fopt-report-loop differences? From the above I would > > > guess we split a lot of loops, meaning the memcpy/memmove/memset > > > calls are in the "middle" and we have to split loops (how many > > > calls are detected here?). If that's true another way would be > > > to only allow calls at head or tail position, thus a single > > > non-builtin partition. > > > > I newly see ~1400 lines: > > > > module_configure.fppized.f90:7993:0: optimized: Loop 10 distributed: split > > to 0 > > loops and 1 library calls. > > module_configure.fppized.f90:7995:0: optimized: Loop 11 distributed: split > > to 0 > > loops and 1 library calls. > > module_configure.fppized.f90:8000:0: optimized: Loop 15 distributed: split > > to 0 > > loops and 1 library calls. > > module_configure.fppized.f90:8381:0: optimized: Loop 77 distributed: split > > to 0 > > loops and 1 library calls. > > module_configure.fppized.f90:8383:0: optimized: Loop 78 distributed: split > > to 0 > > loops and 1 library calls. > > module_configure.fppized.f90:8498:0: optimized: Loop 105 distributed: split > > to > > 0 loops and 1 library calls. > > module_configure.fppized.f90:9742:0: optimized: Loop 169 distributed: split > > to > > 0 loops and 1 library calls. > > module_configure.fppized.f90:9978:0: optimized: Loop 207 distributed: split > > to > > 0 loops and 1 library calls. > > module_configure.fppized.f90:9979:0: optimized: Loop 208 distributed: split > > to > > 0 loops and 1 library calls. > > module_configure.fppized.f90:9980:0: optimized: Loop 209 distributed: split > > to > > 0 loops and 1 library calls. > > module_configure.fppized.f90:9981:0: optimized: Loop 210 distributed: split > > to > > 0 loops and 1 library calls. > > ... > > All with "0 loops"? That disputes my theory :/ Yep. All these are in a form of: [local count: 118163158]: # S.1565_41079 = PHI <1(2028), S.1565_32687(3351)> # ivtmp_38850 = PHI <11(2028), ivtmp_38848(3351)> _3211 = S.1565_41079 + -1; _3212 = fire_ignition_start_y1[_3211]; MEM[(real(kind=4)[11] *)&model_config_rec + 101040B][_3211] = _3212; S.1565_32687 = S.1565_41079 + 1; ivtmp_38848 = ivtmp_38850 - 1; if (ivtmp_38848 == 0) goto ; [9.09%] else goto ; [90.91%] [local count: 107425740]: goto ; [100.00%] [local count: 10737418]: [local count: 118163158]: # S.1566_41080 = PHI <1(2027), S.1566_32689(3350)> # ivtmp_38856 = PHI <11(2027), ivtmp_38854(3350)> _3213 = S.1566_41080 + -1; _3214 = fire_ignition_end_x1[_3213]; MEM[(real(kind=4)[11] *)&model_config_rec + 101084B][_3213] = _3214; S.1566_32689 = S.1566_41080 + 1; ivtmp_38854 = ivtmp_38856 - 1; if (ivtmp_38854 == 0) goto ; [9.09%] else goto ; [90.91%] [local count: 107425740]: goto ; [100.00%] [local count: 10737418]: [local count: 118163158]: # S.1567_41081 = PHI <1(2026), S.1567_32691(3349)> # ivtmp_38860 = PHI <11(2026), ivtmp_38858(3349)> _3215 = S.1567_41081 + -1; _3216 = fire_ignition_end_y1[_3215]; MEM[(real(kind=4)[11] *)&model_config_rec + 101128B][_3215] = _3216; S.1567_32691 = S.1567_41081 + 1; ivtmp_38858 = ivtmp_38860 - 1; if (ivtmp_38858 == 0) goto ; [9.09%] else goto ; [90.91%] [local count: 107425740]: goto ; [100.00%] [local count: 10737418]: ... It's a configure module, so that it probably contains so many loops for various configs.
[Bug fortran/90498] [8/9/10 Regression] ICE with select type/associate and derived type argument containing class(*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90498 Dominique d'Humieres changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2019-05-17 CC||pault at gcc dot gnu.org Known to work||7.4.0 Ever confirmed|0 |1 Known to fail||10.0, 8.3.0, 9.1.0 --- Comment #1 from Dominique d'Humieres --- Caused by revision r257065.
[Bug libfortran/90038] execute_command_line should not use fork()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90038 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-05-17 Ever confirmed|0 |1
[Bug fortran/90506] rejects-valid: function with polymorphic return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90506 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2019-05-17 Target Milestone|--- |7.5 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed from GCC7 up to trunk (10.0). Assignment to an allocatable polymorphic variable is not supported on earlier versions. as suggested at https://groups.google.com/forum/#!topic/comp.lang.fortran/Phl5wkOoW3Q the test compiles with the following changes --- pr90506.f90 2019-05-17 13:47:48.0 +0200 +++ pr90506_db.f90 2019-05-17 13:58:43.0 +0200 @@ -17,24 +17,24 @@ contains subroutine do_stuff (f_maker) interface - function f_maker () result (f) + subroutine f_maker (f) import f_t class(f_t), allocatable :: f - end function f_maker + end subroutine f_maker end interface class(f_t), allocatable :: f -f = f_maker() +call f_maker (f) !<--- end subroutine do_stuff - function g_maker () result (g) + subroutine g_maker (g) class(f_t), allocatable :: g -g = g_t(a=1.,b=1.) +allocate( g, source= g_t( a=1.0, b=1.0 ) ) !<--- [B] no error - end function g_maker + end subroutine g_maker end program test_poly
[Bug tree-optimization/88440] size optimization of memcpy-like code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88440 --- Comment #15 from rguenther at suse dot de --- On Fri, 17 May 2019, marxin at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88440 > > --- Comment #14 from Martin Liška --- > (In reply to rguent...@suse.de from comment #13) > > On Fri, 17 May 2019, marxin at gcc dot gnu.org wrote: > > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88440 > > > > > > --- Comment #12 from Martin Liška --- > > > > > > > > Can you share -fopt-report-loop differences? From the above I would > > > > guess we split a lot of loops, meaning the memcpy/memmove/memset > > > > calls are in the "middle" and we have to split loops (how many > > > > calls are detected here?). If that's true another way would be > > > > to only allow calls at head or tail position, thus a single > > > > non-builtin partition. > > > > > > I newly see ~1400 lines: > > > > > > module_configure.fppized.f90:7993:0: optimized: Loop 10 distributed: > > > split to 0 > > > loops and 1 library calls. > > > module_configure.fppized.f90:7995:0: optimized: Loop 11 distributed: > > > split to 0 > > > loops and 1 library calls. > > > module_configure.fppized.f90:8000:0: optimized: Loop 15 distributed: > > > split to 0 > > > loops and 1 library calls. > > > module_configure.fppized.f90:8381:0: optimized: Loop 77 distributed: > > > split to 0 > > > loops and 1 library calls. > > > module_configure.fppized.f90:8383:0: optimized: Loop 78 distributed: > > > split to 0 > > > loops and 1 library calls. > > > module_configure.fppized.f90:8498:0: optimized: Loop 105 distributed: > > > split to > > > 0 loops and 1 library calls. > > > module_configure.fppized.f90:9742:0: optimized: Loop 169 distributed: > > > split to > > > 0 loops and 1 library calls. > > > module_configure.fppized.f90:9978:0: optimized: Loop 207 distributed: > > > split to > > > 0 loops and 1 library calls. > > > module_configure.fppized.f90:9979:0: optimized: Loop 208 distributed: > > > split to > > > 0 loops and 1 library calls. > > > module_configure.fppized.f90:9980:0: optimized: Loop 209 distributed: > > > split to > > > 0 loops and 1 library calls. > > > module_configure.fppized.f90:9981:0: optimized: Loop 210 distributed: > > > split to > > > 0 loops and 1 library calls. > > > ... > > > > All with "0 loops"? That disputes my theory :/ > > Yep. All these are in a form of: > >[local count: 118163158]: > # S.1565_41079 = PHI <1(2028), S.1565_32687(3351)> > # ivtmp_38850 = PHI <11(2028), ivtmp_38848(3351)> > _3211 = S.1565_41079 + -1; > _3212 = fire_ignition_start_y1[_3211]; > MEM[(real(kind=4)[11] *)&model_config_rec + 101040B][_3211] = _3212; > S.1565_32687 = S.1565_41079 + 1; > ivtmp_38848 = ivtmp_38850 - 1; > if (ivtmp_38848 == 0) > goto ; [9.09%] > else > goto ; [90.91%] > >[local count: 107425740]: > goto ; [100.00%] > >[local count: 10737418]: > >[local count: 118163158]: > # S.1566_41080 = PHI <1(2027), S.1566_32689(3350)> > # ivtmp_38856 = PHI <11(2027), ivtmp_38854(3350)> > _3213 = S.1566_41080 + -1; > _3214 = fire_ignition_end_x1[_3213]; > MEM[(real(kind=4)[11] *)&model_config_rec + 101084B][_3213] = _3214; > S.1566_32689 = S.1566_41080 + 1; > ivtmp_38854 = ivtmp_38856 - 1; > if (ivtmp_38854 == 0) > goto ; [9.09%] > else > goto ; [90.91%] > >[local count: 107425740]: > goto ; [100.00%] > >[local count: 10737418]: > >[local count: 118163158]: > # S.1567_41081 = PHI <1(2026), S.1567_32691(3349)> > # ivtmp_38860 = PHI <11(2026), ivtmp_38858(3349)> > _3215 = S.1567_41081 + -1; > _3216 = fire_ignition_end_y1[_3215]; > MEM[(real(kind=4)[11] *)&model_config_rec + 101128B][_3215] = _3216; > S.1567_32691 = S.1567_41081 + 1; > ivtmp_38858 = ivtmp_38860 - 1; > if (ivtmp_38858 == 0) > goto ; [9.09%] > else > goto ; [90.91%] > >[local count: 107425740]: > goto ; [100.00%] > >[local count: 10737418]: > ... > > > It's a configure module, so that it probably contains so many loops for > various > configs. Hmm, so then it might be we run into some CFG complexity cut-off before for PRE and RA but not after since the CFG should simplify a lot if we make memcpy from all of the above loops...
[Bug driver/90392] [9/10 Regression] Assertion failure in ldlang.c:6868 when compiling with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90392 --- Comment #6 from ohaiziejohwahkeezuoz at xff dot cz --- The ldlang.c:6868 assertion bug was fixed in binutils. That leaves the -save-temps/gcc driver issue.
[Bug lto/90500] ICE error in copy_forbiden
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90500
--- Comment #13 from Guobing ---
(In reply to Martin Liška from comment #12)
> > The background is that, we want to try optimize libm with avx2/avx512, and
> > found that not all the libm math functions will have benefit when we
> > generally use 'arch=haswell' or 'arch=skylake-avx512' to compile libm. So we
> > picked those 'good' libm math functions to add FMV attribute like
> > target_clone("default", "arch=haswell", "arch=skylake-avx512") to get
> > performance benefit. The alias is used in libm code by default. I have no
> > idea why these two are conflicting that not allowed by GCC9.
>
> That makes sense. Based on the test-case you provided, you just want:
>
> __attribute__((target_clones("default", "arch=haswell",
> "arch=skylake-avx512")))
> double
> __tanh (double x)
> {
> double t, z;
> int32_t jx, ix, lx;
>
>
> do { ieee_double_shape_type ew_u; ew_u.value = (x); (jx) = ew_u.parts.msw;
> (lx) = ew_u.parts.lsw; } while (0);
> ix = jx & 0x7fff;
> ...
> }
>
> extern __typeof (__tanh) tanh __attribute__ ((weak, alias ("__tanh"))); //
> __attribute__ ((__copy__ (__tanh)));
>
> You don't want to use __copy__ attribute because it's responsible for
> copying of target_clone attribute to the alias.
> And it does not make sense to create clones of an alias.
The copy is from alias used by libm by default (Below I paste the src code), I
cannot remove this copy seems. How can I then to use FMV for this function?
__attribute__((target_clones("default", "arch=haswell", "arch=broadwell"
,"arch=skylake", "arch=skylake-avx512")))
double
__tanh (double x)
{
double t, z;
int32_t jx, ix, lx;
/* High word of |x|. */
EXTRACT_WORDS (jx, lx, x);
ix = jx & 0x7fff;
/* x is INF or NaN */
if (ix >= 0x7ff0)
{
if (jx >= 0)
return one / x + one; /* tanh(+-inf)=+-1 */
else
return one / x - one; /* tanh(NaN) = NaN */
}
/* |x| < 22 */
if (ix < 0x4036) /* |x|<22 */
{
if ((ix | lx) == 0)
return x; /* x == +-0 */
if (ix < 0x3c80) /* |x|<2**-55 */
{
math_check_force_underflow (x);
return x * (one + x); /* tanh(small) = small */
}
if (ix >= 0x3ff0) /* |x|>=1 */
{
t = __expm1 (two * fabs (x));
z = one - two / (t + two);
}
else
{
t = __expm1 (-two * fabs (x));
z = -t / (t + two);
}
/* |x| > 22, return +-1 */
}
else
{
z = one - tiny; /* raised inexact flag */
}
return (jx >= 0) ? z : -z;
}
libm_alias_double (__tanh, tanh)
[Bug lto/90500] ICE error in copy_forbiden
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90500
--- Comment #14 from Martin Liška ---
(In reply to Guobing Chen from comment #13)
> (In reply to Martin Liška from comment #12)
> > > The background is that, we want to try optimize libm with avx2/avx512, and
> > > found that not all the libm math functions will have benefit when we
> > > generally use 'arch=haswell' or 'arch=skylake-avx512' to compile libm. So
> > > we
> > > picked those 'good' libm math functions to add FMV attribute like
> > > target_clone("default", "arch=haswell", "arch=skylake-avx512") to get
> > > performance benefit. The alias is used in libm code by default. I have no
> > > idea why these two are conflicting that not allowed by GCC9.
> >
> > That makes sense. Based on the test-case you provided, you just want:
> >
> > __attribute__((target_clones("default", "arch=haswell",
> > "arch=skylake-avx512")))
> > double
> > __tanh (double x)
> > {
> > double t, z;
> > int32_t jx, ix, lx;
> >
> >
> > do { ieee_double_shape_type ew_u; ew_u.value = (x); (jx) = ew_u.parts.msw;
> > (lx) = ew_u.parts.lsw; } while (0);
> > ix = jx & 0x7fff;
> > ...
> > }
> >
> > extern __typeof (__tanh) tanh __attribute__ ((weak, alias ("__tanh"))); //
> > __attribute__ ((__copy__ (__tanh)));
> >
> > You don't want to use __copy__ attribute because it's responsible for
> > copying of target_clone attribute to the alias.
> > And it does not make sense to create clones of an alias.
>
> The copy is from alias used by libm by default (Below I paste the src code),
> I cannot remove this copy seems. How can I then to use FMV for this function?
>
Then you'll have to make one libm_alias_double_no_copy that will do the same
except setting the copy attribute.
[Bug lto/90500] ICE error in copy_forbiden
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90500
--- Comment #15 from Guobing Chen ---
(In reply to Martin Liška from comment #14)
> (In reply to Guobing Chen from comment #13)
> > (In reply to Martin Liška from comment #12)
> > > > The background is that, we want to try optimize libm with avx2/avx512,
> > > > and
> > > > found that not all the libm math functions will have benefit when we
> > > > generally use 'arch=haswell' or 'arch=skylake-avx512' to compile libm.
> > > > So we
> > > > picked those 'good' libm math functions to add FMV attribute like
> > > > target_clone("default", "arch=haswell", "arch=skylake-avx512") to get
> > > > performance benefit. The alias is used in libm code by default. I have
> > > > no
> > > > idea why these two are conflicting that not allowed by GCC9.
> > >
> > > That makes sense. Based on the test-case you provided, you just want:
> > >
> > > __attribute__((target_clones("default", "arch=haswell",
> > > "arch=skylake-avx512")))
> > > double
> > > __tanh (double x)
> > > {
> > > double t, z;
> > > int32_t jx, ix, lx;
> > >
> > >
> > > do { ieee_double_shape_type ew_u; ew_u.value = (x); (jx) =
> > > ew_u.parts.msw;
> > > (lx) = ew_u.parts.lsw; } while (0);
> > > ix = jx & 0x7fff;
> > > ...
> > > }
> > >
> > > extern __typeof (__tanh) tanh __attribute__ ((weak, alias ("__tanh"))); //
> > > __attribute__ ((__copy__ (__tanh)));
> > >
> > > You don't want to use __copy__ attribute because it's responsible for
> > > copying of target_clone attribute to the alias.
> > > And it does not make sense to create clones of an alias.
> >
> > The copy is from alias used by libm by default (Below I paste the src code),
> > I cannot remove this copy seems. How can I then to use FMV for this
> > function?
> >
>
> Then you'll have to make one libm_alias_double_no_copy that will do the same
> except setting the copy attribute.
I am not quite familiar with libm, will this change the its bevhavior or other
side effect?
[Bug lto/90500] ICE error in copy_forbiden
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90500 --- Comment #16 from Martin Liška --- > I am not quite familiar with libm, will this change the its bevhavior or > other side effect? No. You have to tweak the macro definition, sorry.
[Bug go/90482] [10 regression] Many 32-bit Solaris/SPARC tests FAIL with SIGBUS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90482
--- Comment #4 from Ian Lance Taylor ---
What is different about 32-bit SPARC is not that it treats pointers and
integers differently, but that
struct { void *p; }
and
void *p;
are passed as arguments in two different ways. The former is passed by
invisible reference and the latter is passed directly. On many platforms they
are passed as arguments in exactly the same way.
[Bug tree-optimization/90510] [10 Regression] Unnecessary permutation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90510 Richard Biener changed: What|Removed |Added Keywords||patch Target||x86_64-*-* i?86-*-* URL||https://gcc.gnu.org/ml/gcc- ||patches/2019-05/msg01073.ht ||ml --- Comment #3 from Richard Biener --- Patch posted.
[Bug testsuite/90517] New: [10 regression] test case gcc.dg/cdce1.c fails starting with r271281
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90517 Bug ID: 90517 Summary: [10 regression] test case gcc.dg/cdce1.c fails starting with r271281 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- The new test added in the test case doesn't appear to be set up correctly. Executing on host: /home/seurer/gcc/build/gcc-test2/gcc/xgcc -B/home/seurer/gcc/build/gcc-test2/gcc/ /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/cdce1.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -O2 -fmath-errno -fdump-tree-cdce-details -lm -ffat-lto-objects -fno-ident -lm -o ./cdce1.exe(timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc -B/home/seurer/gcc/build/gcc-test2/gcc/ /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/cdce1.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -O2 -fmath-errno -fdump-tree-cdce-details -lm -ffat-lto-objects -fno-ident -lm -o ./cdce1.exe PASS: gcc.dg/cdce1.c (test for excess errors) Setting LD_LIBRARY_PATH to :/home/seurer/gcc/build/gcc-test2/gcc::/home/seurer/gcc/build/gcc-test2/gcc:/home/seurer/gcc/build/gcc-test2/./gmp/.libs:/home/seurer/gcc/build/gcc-test2/./prev-gmp/.libs:/home/seurer/gcc/build/gcc-test2/./mpfr/src/.libs:/home/seurer/gcc/build/gcc-test2/./prev-mpfr/src/.libs:/home/seurer/gcc/build/gcc-test2/./mpc/src/.libs:/home/seurer/gcc/build/gcc-test2/./prev-mpc/src/.libs:/home/seurer/gcc/build/gcc-test2/./isl/.libs:/home/seurer/gcc/build/gcc-test2/./prev-isl/.libs:/home/seurer/gcc/install/gcc-7.4.0/lib64 Execution timeout is: 300 spawn [open ...] PASS: gcc.dg/cdce1.c execution test PASS: gcc.dg/cdce1.c scan-tree-dump cdce "cdce1.c:17: .* function call is shrink-wrapped into error conditions." gcc.dg/cdce1.c: output file does not exist UNRESOLVED: gcc.dg/cdce1.c scan-assembler jmp pow testcase /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/dg.exp completed in 1 seconds === gcc Summary === # of expected passes3 # of unresolved testcases 1 r271281 | junma | 2019-05-16 03:21:17 -0500 (Thu, 16 May 2019) | 12 lines PR tree-optimization/90106 * tree-call-cdce.c (shrink_wrap_one_built_in_call_with_conds): Add new parameter as new internal function call, also move it to new basic block. (use_internal_fn): Pass internal function call to shrink_wrap_one_built_in_call_with_conds. gcc/testsuite * gcc.dg/cdce1.c: Check tailcall code generation after cdce pass. * gcc.dg/cdce2.c: Likewise.
[Bug middle-end/90518] New: ICE: in emit_move_insn, at expr.c:3745 in gcc.dg/gimplefe-40.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90518 Bug ID: 90518 Summary: ICE: in emit_move_insn, at expr.c:3745 in gcc.dg/gimplefe-40.c Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: rguenth at gcc dot gnu.org Target Milestone: --- Target: sparc-sun-solaris2.11, mips64el-unknown-linux-gnu, s390x-ibm-linux-gnu, ia64-suse-linux-gnu Between 20190515 (r271254) and 20190516 (r271294), gcc.dg/gimplefe-40.c began to ICE on 64-bit Solaris/SPARC: +FAIL: gcc.dg/gimplefe-40.c (internal compiler error) +FAIL: gcc.dg/gimplefe-40.c (test for excess errors) There are also reports for a couple more targets. during RTL pass: expand /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/gimplefe-40.c: In function 'load': /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/gimplefe-40.c:6:1: internal compiler error: in emit_move_insn, at expr.c:3745 0x6fdf57 emit_move_insn(rtx_def*, rtx_def*) /vol/gcc/src/hg/trunk/local/gcc/expr.c:3745 0x71131f expand_expr_real_2(separate_ops*, rtx_def*, machine_mode, expand_modifier) /vol/gcc/src/hg/trunk/local/gcc/expr.c:9721 0x5a1037 expand_gimple_stmt_1 /vol/gcc/src/hg/trunk/local/gcc/cfgexpand.c:3798 0x5a1037 expand_gimple_stmt /vol/gcc/src/hg/trunk/local/gcc/cfgexpand.c:3859 0x5a810b expand_gimple_basic_block /vol/gcc/src/hg/trunk/local/gcc/cfgexpand.c:5895 0x5aa9ab execute /vol/gcc/src/hg/trunk/local/gcc/cfgexpand.c:6518
[Bug middle-end/90518] ICE: in emit_move_insn, at expr.c:3745 in gcc.dg/gimplefe-40.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90518 Rainer Orth changed: What|Removed |Added Target Milestone|--- |10.0
[Bug libstdc++/85965] [8/9/10 Regression] G++ gives cryptic error instead of incomplete type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85965 --- Comment #16 from Jonathan Wakely --- Author: redi Date: Fri May 17 14:13:32 2019 New Revision: 271323 URL: https://gcc.gnu.org/viewcvs?rev=271323&root=gcc&view=rev Log: PR libstdc++/85965 move is_invocable assertions again This is another attempt to reduce how often the assertions are evaluated, so that code which doesn't try to use the function objects doesn't need them to be invocable. For _Rb_tree we access the _M_key_compare object directly, so can't put the assertions in an accessor function for it. However, every invocation of _M_key_compare is accompanied by a use of _S_key, so the assertions can be put in there. For _Hashtable there are member functions that are consistently used to obtain a hash code or test for equality, so the assertions can go in those members. PR libstdc++/85965 * include/bits/hashtable.h (_Hashtable::~_Hashtable()): Remove static assertions from the destructor. * include/bits/hashtable_policy.h (_Hash_code_base::_M_hash_code): Move static_assert for hash function to here. (_Hash_table_base::_M_equals): Move static_assert for equality predicate to here. * include/bits/stl_tree.h (_Rb_tree::_S_value(_Const_Link_type)): Remove. (_Rb_tree::_S_key(_Const_Link_type)): Move assertions here. Access the value directly instead of calling _S_value. (_Rb_tree::_S_value(_Const_Base_ptr)): Remove. (_Rb_tree::_S_key(_Const_Base_ptr)): Do downcast and forward to _S_key(_Const_Link_type). * testsuite/23_containers/set/85965.cc: Check construction, destruction, assignment and size() do not trigger the assertions. * testsuite/23_containers/unordered_set/85965.cc: Likewise. * testsuite/23_containers/map/48101_neg.cc: Call find and adjust expected errors. * testsuite/23_containers/multimap/48101_neg.cc: Likewise. * testsuite/23_containers/multiset/48101_neg.cc: Likewise. * testsuite/23_containers/set/48101_neg.cc: Likewise. * testsuite/23_containers/unordered_map/48101_neg.cc: Likewise. * testsuite/23_containers/unordered_multimap/48101_neg.cc: Likewise. * testsuite/23_containers/unordered_multiset/48101_neg.cc: Likewise. * testsuite/23_containers/unordered_set/48101_neg.cc: Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/hashtable.h trunk/libstdc++-v3/include/bits/hashtable_policy.h trunk/libstdc++-v3/include/bits/stl_tree.h trunk/libstdc++-v3/testsuite/23_containers/map/48101_neg.cc trunk/libstdc++-v3/testsuite/23_containers/multimap/48101_neg.cc trunk/libstdc++-v3/testsuite/23_containers/multiset/48101_neg.cc trunk/libstdc++-v3/testsuite/23_containers/set/48101_neg.cc trunk/libstdc++-v3/testsuite/23_containers/set/85965.cc trunk/libstdc++-v3/testsuite/23_containers/unordered_map/48101_neg.cc trunk/libstdc++-v3/testsuite/23_containers/unordered_multimap/48101_neg.cc trunk/libstdc++-v3/testsuite/23_containers/unordered_multiset/48101_neg.cc trunk/libstdc++-v3/testsuite/23_containers/unordered_set/48101_neg.cc trunk/libstdc++-v3/testsuite/23_containers/unordered_set/85965.cc
[Bug libstdc++/90246] std::bad_variant_access messages are not useful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90246 --- Comment #4 from Jonathan Wakely --- Author: redi Date: Fri May 17 14:36:37 2019 New Revision: 271326 URL: https://gcc.gnu.org/viewcvs?rev=271326&root=gcc&view=rev Log: PR libstdc++/90246 Improve text of std::variant exceptions and assertions PR libstdc++/90246 * include/std/variant (holds_alternative, get, get_if): Improve static assertion messages. (bad_variant_access::bad_variant_access()): Change default message. (__throw_bad_variant_access(bool)): New overload. (get): Use new overload. (visit, visit): Improve exception message. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/std/variant
[Bug libstdc++/90246] std::bad_variant_access messages are not useful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90246 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|9.2 |10.0 --- Comment #5 from Jonathan Wakely --- Fixed on trunk.
[Bug bootstrap/90497] [10 Regression] Broken bootstrap on i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90497 --- Comment #7 from hjl at gcc dot gnu.org --- Author: hjl Date: Fri May 17 14:48:37 2019 New Revision: 271328 URL: https://gcc.gnu.org/viewcvs?rev=271328&root=gcc&view=rev Log: i386: Enable MMX intrinsics without SSE/SSE2/SSSE3 Since MMX intrinsics are marked with SSE/SSE2/SSSE3 for SSE emulation, enable them without SSE/SSE2/SSSE3 if MMX is enabled. Restore TARGET_3DNOW check, which was changed to TARGET_3DNOW_A by revision 271235. gcc/ PR target/90497 * config/i386/i386-expand.c (ix86_expand_builtin): Enable MMX intrinsics without SSE/SSE2/SSSE3. * config/i386/mmx.md (mmx_uavgv8qi3): Restore TARGET_3DNOW check. (*mmx_uavgv8qi3): Likewise. gcc/testsuite/ PR target/90497 * gcc.target/i386/pr90497-1.c: New test. * gcc.target/i386/pr90497-2.c: Likewise. Added: trunk/gcc/testsuite/gcc.target/i386/pr90497-1.c trunk/gcc/testsuite/gcc.target/i386/pr90497-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386-expand.c trunk/gcc/config/i386/mmx.md trunk/gcc/testsuite/ChangeLog
[Bug c++/89576] [8 Regression] constexpr not working if implicitly captured in a lambda in a function template (gcc 8.3+)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89576 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED --- Comment #6 from Marek Polacek --- Assuming fixed.
[Bug go/90482] [10 regression] Many 32-bit Solaris/SPARC tests FAIL with SIGBUS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90482
--- Comment #5 from Eric Botcazou ---
> What is different about 32-bit SPARC is not that it treats pointers and
> integers differently, but that
>
> struct { void *p; }
>
> and
>
> void *p;
>
> are passed as arguments in two different ways. The former is passed by
> invisible reference and the latter is passed directly. On many platforms
> they are passed as arguments in exactly the same way.
Thanks. I'm a little skeptical about the "many" here, although that's probably
true for modern architectures. In any case, assuming that scalar and structure
types are passed the same way is clearly an unwarranted assumption overall.
[Bug testsuite/90517] [10 regression] test case gcc.dg/cdce1.c fails (unresolved) starting with r271281
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90517 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- See http://gcc.gnu.org/ml/gcc-patches/2019-05/msg01024.html Waiting for review on that.
[Bug bootstrap/90497] [10 Regression] Broken bootstrap on i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90497 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Jakub Jelinek --- Fixed.
[Bug fortran/90519] New: ICE (segfault) on derived type which has a recursive allocatable component of the same type, and a static component of another type which has a "final" attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90519 Bug ID: 90519 Summary: ICE (segfault) on derived type which has a recursive allocatable component of the same type, and a static component of another type which has a "final" attribute Product: gcc Version: 7.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: perini at wisc dot edu Target Milestone: --- Created attachment 46372 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46372&action=edit sample program which reproduces the issue I'm having an internal compiler error when I try to create a type which includes: - a recursive allocatable component of the same type, AND - at least one NON-allocatable component of another derived type which has a finalization routine defined by the "final" attribute. I have tested this on both gfortran 7.1.0 and 7.4.0 and it produces internal compiler error in both cases: internal compiler error: Segmentation fault 0xa8e83f crash_signal ../../gcc-7.1.0/gcc/toplev.c:337 0x810e3a expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) ../../gcc-7.1.0/gcc/expr.c:8065 0x72c446 expand_expr ../../gcc-7.1.0/gcc/expr.h:276 0x72c446 expand_call_stmt ../../gcc-7.1.0/gcc/cfgexpand.c:2658 0x72c446 expand_gimple_stmt_1 ../../gcc-7.1.0/gcc/cfgexpand.c:3571 0x72c446 expand_gimple_stmt ../../gcc-7.1.0/gcc/cfgexpand.c:3737 0x72d32f expand_gimple_basic_block ../../gcc-7.1.0/gcc/cfgexpand.c:5744 0x732496 execute ../../gcc-7.1.0/gcc/cfgexpand.c:6357 I have attached a sample program which reproduces the error. A few notes about it (please refer to the commented numbered items in the attached code): - type(t) is what causes the compiler to crash. If I define the recursive component (2) as an allocatable one, the compiler will crash. If I define it as a pointer (3), it won't. That is a workaround, but I would like to stick to allocatables, if possible. I don't think I'm violating any standards, am I? - If I remove the finalization routine (1) from type(t1), which is a static component of type(t), NOT allocatable, the compiler is able to compile the code correctly! - If the finalization routine is inside another allocatable component, like (4), that does not matter, the compiler always works. Thanks! Federico
[Bug middle-end/90518] ICE: in emit_move_insn, at expr.c:3745 in gcc.dg/gimplefe-40.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90518 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-05-17 CC||law at redhat dot com Ever confirmed|0 |1
[Bug middle-end/90518] ICE: in emit_move_insn, at expr.c:3745 in gcc.dg/gimplefe-40.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90518 --- Comment #1 from Jeffrey A. Law --- It looks like BIT_INSERT_EXPR is being expanded as a simple move even though its got BLKmode operands. That's a no-no. We have go use the mem* routines rather than a simple move insn.
[Bug testsuite/90520] New: [10 regression] libstdc++-xmethods/unique_ptr.cc triggers python failure starting with r271158
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90520 Bug ID: 90520 Summary: [10 regression] libstdc++-xmethods/unique_ptr.cc triggers python failure starting with r271158 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- Python Exception 'NoneType' object has no attribute 'dereference': unique_ptr.gdb:10: Error in sourced command file: Error while executing Python code. FAIL: libstdc++-xmethods/unique_ptr.cc Note: this system has Python 2.7.12 installed. It also fails on another system with 2.7.15. r271158 | redi | 2019-05-14 06:17:11 -0500 (Tue, 14 May 2019) | 17 lines LWG 2899 - Make is_move_constructible correct for unique_ptr * include/bits/unique_ptr.h (__uniq_ptr_impl): Add move constructor, move assignment operator. (__uniq_ptr_impl::release(), __uniq_ptr_impl::reset(pointer)): Add. (__uniq_ptr_data): New class template with conditionally deleted special members. (unique_ptr, unique_ptr): Change type of data member from __uniq_ptr_impl to __uniq_ptr_data. Define move constructor and move assignment operator as defaulted. (unique_ptr::release(), unique_ptr::release()): Forward to __uniq_ptr_impl::release(). (unique_ptr::reset(pointer), unique_ptr::reset(U)): Forward to __uniq_ptr_impl::reset(pointer). * python/libstdcxx/v6/printers.py (UniquePointerPrinter.__init__): Check for new __uniq_ptr_data type. * testsuite/20_util/unique_ptr/dr2899.cc: New test. Executing on host: /home/seurer/gcc/build/gcc-trunk/./gcc/xg++ -shared-libgcc -B/home/seurer/gcc/build/gcc-trunk/./gcc -nostdinc++ -L/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/libstdc++-v3/src -L/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs -L/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -B/home/seurer/gcc/install/gcc-trunk/powerpc64le-unknown-linux-gnu/bin/ -B/home/seurer/gcc/install/gcc-trunk/powerpc64le-unknown-linux-gnu/lib/ -isystem /home/seurer/gcc/install/gcc-trunk/powerpc64le-unknown-linux-gnu/include -isystem /home/seurer/gcc/install/gcc-trunk/powerpc64le-unknown-linux-gnu/sys-include -B/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs -fmessage-length=0 -fno-show-column -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -DLOCALEDIR="." -nostdinc++ -I/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu -I/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/libstdc++-v3/include -I/home/seurer/gcc/gcc-trunk/libstdc++-v3/libsupc++ -I/home/seurer/gcc/gcc-trunk/libstdc++-v3/include/backward -I/home/seurer/gcc/gcc-trunk/libstdc++-v3/testsuite/util /home/seurer/gcc/gcc-trunk/libstdc++-v3/testsuite/libstdc++-xmethods/unique_ptr.cc -g -O0 -fno-diagnostics-show-caret -fdiagnostics-color=never ./libtestc++.a -Wl,--gc-sections -L/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/libstdc++-v3/src/filesystem/.libs -lm -o ./unique_ptr.exe(timeout = 600) spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-trunk/./gcc/xg++ -shared-libgcc -B/home/seurer/gcc/build/gcc-trunk/./gcc -nostdinc++ -L/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/libstdc++-v3/src -L/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs -L/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -B/home/seurer/gcc/install/gcc-trunk/powerpc64le-unknown-linux-gnu/bin/ -B/home/seurer/gcc/install/gcc-trunk/powerpc64le-unknown-linux-gnu/lib/ -isystem /home/seurer/gcc/install/gcc-trunk/powerpc64le-unknown-linux-gnu/include -isystem /home/seurer/gcc/install/gcc-trunk/powerpc64le-unknown-linux-gnu/sys-include -B/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs -fmessage-length=0 -fno-show-column -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -DLOCALEDIR="." -nostdinc++ -I/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu -I/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/libstdc++-v3/include -I/home/seurer/gcc/gcc-trunk/libstdc++-v3/libsupc++ -I/home/seurer/gcc/gcc-trunk/libstdc++-v3/include/backward -I/home/seurer/gcc/gcc-trunk/libstdc++-v3/testsuite/util /home/seurer/gcc/gcc-trunk/libstdc++-v3/testsuite/libstdc++-xmethods/unique_ptr.cc -g -O0 -fno-diagnostics-show-caret -fdiagnostics-color=never ./libtestc++.a -Wl,--gc-sections -L/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-
[Bug c++/90521] New: error: names the constructor, not the type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90521 Bug ID: 90521 Summary: error: names the constructor, not the type Product: gcc Version: 7.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: colton.wernet at linquest dot com Target Milestone: --- Created attachment 46373 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46373&action=edit Here is a snapshot of the terminal after calling make Error building gdal third party library on Ubuntu 18.04. This build works without error on windows 10. When make is called the error: "names the constructor, not the type" is thrown in several places preventing the build. Here is one of the lines causing the error: std::string::basic_string& assign(const std::string::basic_string& _str ); All the other lines causing the error have the basic_string type. It has been noted that the error is coming from the basic_string type, when ::basic_string is removed form the line above, there is no longer an error but this later on causes problems when the class is being used elsewhere. Considering this problem does not occur on windows I am reporting this as a bug within gcc.
[Bug testsuite/90520] [10 regression] libstdc++-xmethods/unique_ptr.cc triggers python failure starting with r271158
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90520 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-05-17 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Target Milestone|--- |10.0 Ever confirmed|0 |1
[Bug rtl-optimization/90522] New: unrecognizable insn (V8SF)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90522 Bug ID: 90522 Summary: unrecognizable insn (V8SF) Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: leonardo.sandoval.gonzalez at linux dot intel.com Target Milestone: --- Created attachment 46374 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46374&action=edit sample C file that computes the square root of an array of floats I am attaching a C file with a single function that computes the square root of an array of floats. When compiling with gcc -Ofast -Wall -Wextra -S y.i it gives the following error cc -Ofast -Wall -Wextra -S y.i y.i: In function ‘rsqrt’: y.i:8:1: error: unrecognizable insn: 8 | } | ^ (insn 14 13 15 2 (set (reg:V8SF 91) (mult:V8SF (reg:V8SF 89) (const_vector:V8SF [ (const_double:SF -5.0e-1 [-0x0.8p+0]) repeated x8 ]))) "y.i":6:16 -1 (nil)) during RTL pass: vregs y.i:8:1: internal compiler error: in extract_insn, at recog.c:2310 0x670576 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*) /home/lsandov1/repos/gcc/gcc/rtl-error.c:108 0x670592 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*) /home/lsandov1/repos/gcc/gcc/rtl-error.c:116 0x66e779 extract_insn(rtx_insn*) /home/lsandov1/repos/gcc/gcc/recog.c:2310 0xa73973 instantiate_virtual_regs_in_insn /home/lsandov1/repos/gcc/gcc/function.c:1605 0xa73973 instantiate_virtual_regs /home/lsandov1/repos/gcc/gcc/function.c:1975 0xa73973 execute /home/lsandov1/repos/gcc/gcc/function.c:2024 Please submit a full bug report, with preprocessed source if appropriate.
[Bug lto/90523] New: lto1 segfault in arm_parse_cpu_option_name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90523 Bug ID: 90523 Summary: lto1 segfault in arm_parse_cpu_option_name Product: gcc Version: 9.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: hoganmeier at gmail dot com CC: marxin at gcc dot gnu.org Target Milestone: --- Built a bleeding-edge arm-gcc toolchain. It works fine but when I tried newlib built with -flto I got a crash in lto1. $ arm-none-eabi-g++ -o main.elf -Wl,--relax -mthumb -mcpu=cortex-m4 -O3 during IPA pass: icf In function '__retarget_lock_acquire_recursive': lto1: internal compiler error: Segmentation fault #0 __strchr_avx2 () at ../sysdeps/x86_64/multiarch/strchr-avx2.S:57 #1 0x014de71a in strchr (__c=43, __s=0x0) at /usr/include/string.h:220 #2 arm_parse_cpu_option_name (list=0x1ab3400 , optname=optname@entry=0x18704ba "-mcpu", target=0x0, complain=complain@entry=true) at gcc-10-20190512/gcc/common/config/arm/arm-common.c:349 #3 0x00f8545d in arm_configure_build_target (target=0x1e7b500 , opts=0x7f3e2a00, opts_set=0x1e81100 , warn_compatible=) at gcc-10-20190512/gcc/config/arm/arm.c:3147 #4 0x00fa5b68 in arm_set_current_function (fndecl=) at gcc-10-20190512/gcc/tree.h:3186 #5 0x0097da22 in invoke_set_current_function_hook (fndecl=0x7f402400) at gcc-10-20190512/gcc/function.c:4629 #6 0x00984a48 in invoke_set_current_function_hook (fndecl=0x7f402400) at gcc-10-20190512/gcc/function.c:4788 #7 allocate_struct_function (fndecl=0x7f402400, abstract_p=) at gcc-10-20190512/gcc/function.c:4742 #8 0x00afc5ed in input_function (ib_cfg=0x7ffed9c0, ib=0x7ffed9a0, data_in=0x1f8c510, fn_decl=0x7f402400) at gcc-10-20190512/gcc/lto-streamer-in.c:1066 #9 lto_read_body_or_constructor (file_data=0x7f3ec960, data=, node=, section_type=LTO_section_function_body) at gcc-10-20190512/gcc/lto-streamer-in.c:1296 #10 0x0083d38b in cgraph_node::get_untransformed_body (this=0x7f418708) at gcc-10-20190512/gcc/cgraph.c:3570 #11 0x0144762f in ipa_icf::sem_function::init (this=0x1f61230) at gcc-10-20190512/gcc/cgraph.h:2008 #12 0x01441d12 in ipa_icf::sem_item_optimizer::parse_nonsingleton_classes (this=this@entry=0x1eca870) at gcc-10-20190512/gcc/ipa-icf.c:2776 #13 0x0144d730 in ipa_icf::sem_item_optimizer::execute (this=0x1eca870) at gcc-10-20190512/gcc/ipa-icf.c:2577 #14 0x0144e9b7 in ipa_icf::ipa_icf_driver () at gcc-10-20190512/gcc/ipa-icf.c:3698 #15 ipa_icf::pass_ipa_icf::execute (this=) at gcc-10-20190512/gcc/ipa-icf.c:3745 #16 0x00b777ea in execute_one_pass (pass=0x1ec0940) at gcc-10-20190512/gcc/passes.c:2473 #17 0x00b78517 in execute_ipa_pass_list (pass=0x1ec0940) at gcc-10-20190512/gcc/passes.c:2913 #18 0x007ab461 in do_whole_program_analysis () at gcc-10-20190512/gcc/context.h:48 #19 lto_main () at gcc-10-20190512/gcc/lto/lto.c:628 #20 0x00c472af in compile_file () at gcc-10-20190512/gcc/toplev.c:456 #21 0x0077b1e6 in do_compile () at gcc-10-20190512/gcc/toplev.c:2205 #22 toplev::main (this=this@entry=0x7ffedd86, argc=, argc@entry=24, argv=, argv@entry=0x7ffede88) at gcc-10-20190512/gcc/toplev.c:2340 #23 0x0077d9dc in main (argc=24, argv=0x7ffede88) at gcc-10-20190512/gcc/main.c:39 I'm not sure how to reduce this.
[Bug rtl-optimization/90522] unrecognizable insn (V8SF)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90522 --- Comment #1 from Leo Sandoval --- I just confirmed: without -Ofast, issue is not observed, thus the latter optimization flag is triggering the issue
[Bug lto/90523] lto1 segfault in arm_parse_cpu_option_name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90523 --- Comment #1 from krux --- So this one must be null: https://github.com/gcc-mirror/gcc/blob/65af043/gcc/config/arm/arm.c#L3148
[Bug middle-end/90518] ICE: in emit_move_insn, at expr.c:3745 in gcc.dg/gimplefe-40.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90518 --- Comment #2 from rguenther at suse dot de --- On May 17, 2019 5:49:21 PM GMT+02:00, law at redhat dot com wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90518 > >--- Comment #1 from Jeffrey A. Law --- >It looks like BIT_INSERT_EXPR is being expanded as a simple move even >though >its got BLKmode operands. That's a no-no. We have go use the mem* >routines >rather than a simple move insn. The testcase needs to be restricted to targets that have those vector modes supported.
[Bug lto/90523] lto1 segfault in arm_parse_cpu_option_name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90523 --- Comment #2 from Alexander Monakov --- See also PR 87076, which has a reduced testcase and some root-cause analysis (likely a duplicate).
[Bug fortran/54613] [F08] Add FINDLOC plus support MAXLOC/MINLOC with KIND=/BACK=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54613
--- Comment #21 from Jakub Jelinek ---
Author: jakub
Date: Fri May 17 17:23:30 2019
New Revision: 271334
URL: https://gcc.gnu.org/viewcvs?rev=271334&root=gcc&view=rev
Log:
PR fortran/54613
* gfortran.map (GFORTRAN_9.2): New symbol version, export
_gfortran_{,m,s}findloc0_i2 in it.
Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/gfortran.map
[Bug fortran/54613] [F08] Add FINDLOC plus support MAXLOC/MINLOC with KIND=/BACK=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54613
--- Comment #22 from Jakub Jelinek ---
Author: jakub
Date: Fri May 17 17:24:27 2019
New Revision: 271335
URL: https://gcc.gnu.org/viewcvs?rev=271335&root=gcc&view=rev
Log:
PR fortran/54613
* gfortran.map (GFORTRAN_9.2): Export _gfortran_{,m,s}findloc{0,1}_r10.
* Makefile.am (i_findloc0_c): Add $(srcdir)/generated/findloc0_r10.c.
(i_findloc1_c): Add $(srcdir)/generated/findloc1_r10.c.
* Makefile.in: Regenerated.
* generated/findloc0_r10.c: Generated.
* generated/findloc1_r10.c: Generated.
Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/Makefile.am
trunk/libgfortran/Makefile.in
trunk/libgfortran/gfortran.map
[Bug lto/90523] lto1 segfault in arm_parse_cpu_option_name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90523 --- Comment #3 from krux --- Possible, gcc was built with --disable-multilib --with-arch=armv7e-m --with-mode=thumb --with-float=soft. And if I replace -mcpu=cortex-m4 with -march=armv7e-m in my test command there's no crash.
[Bug fortran/54613] [F08] Add FINDLOC plus support MAXLOC/MINLOC with KIND=/BACK=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54613
--- Comment #23 from Jakub Jelinek ---
Author: jakub
Date: Fri May 17 17:50:55 2019
New Revision: 271336
URL: https://gcc.gnu.org/viewcvs?rev=271336&root=gcc&view=rev
Log:
PR fortran/54613
* gfortran.map (GFORTRAN_9.2): Export _gfortran_{,m,s}findloc{0,1}_r10.
* Makefile.am (i_findloc0_c): Add $(srcdir)/generated/findloc0_r10.c.
(i_findloc1_c): Add $(srcdir)/generated/findloc1_r10.c.
* Makefile.in: Regenerated.
* generated/findloc0_r10.c: Generated.
* generated/findloc1_r10.c: Generated.
Added:
trunk/libgfortran/generated/findloc0_r10.c
trunk/libgfortran/generated/findloc1_r10.c
[Bug fortran/90498] [8/9/10 Regression] ICE with select type/associate and derived type argument containing class(*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90498 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #2 from Paul Thomas --- Created attachment 46375 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46375&action=edit Patch for the problem I very much doubt that this was revision r257065. The problem looks to have Andre's signature on it. Nevertheless, I have the fix attached and have taken it. type field_names_a class(*), pointer :: var(:) =>null() end type type(field_names_a),pointer :: a(:) allocate (a(1)) allocate (a(1)%var(2), source = ["hello"," baby"]) call s(a) deallocate (a(1)%var) deallocate (a) contains subroutine s(a) type(field_names_a) :: a(:) select type (var => a(1)%var) type is (character(*)) print *, var class default stop end select associate (var => a(i)%var) select type (var2 => a(1)%var) type is (character(*)) print *, var2 class default stop end select end associate end end Does the right thing mostly but sometimes, after recompilation, segfaults at runtime - I will check out why before submitting. Paul
[Bug libfortran/90038] execute_command_line should not use fork()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90038 --- Comment #2 from Janne Blomqvist --- Author: jb Date: Fri May 17 18:18:04 2019 New Revision: 271340 URL: https://gcc.gnu.org/viewcvs?rev=271340&root=gcc&view=rev Log: libfortran/90038: Use posix_spawn instead of fork fork() semantics can be problematic. Most unix style OS'es have posix_spawn which can be used to replace fork + exec in many cases. For more information see e.g. https://www.microsoft.com/en-us/research/uploads/prod/2019/04/fork-hotos19.pdf This replaces the one use of fork in libgfortran with posix_spawn. 2019-05-17 Janne Blomqvist PR libfortran/90038 * configure.ac (AC_CHECK_FUNCS_ONCE): Check for posix_spawn. * intrinsics/execute_command_line (execute_command_line): Use posix_spawn. * Makefile.in: Regenerated. * config.h.in: Regenerated. * configure: Regenerated. Regtested on x86_64-pc-linux-gnu. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/Makefile.in trunk/libgfortran/config.h.in trunk/libgfortran/configure trunk/libgfortran/configure.ac trunk/libgfortran/intrinsics/execute_command_line.c
[Bug c++/90521] error: names the constructor, not the type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90521 --- Comment #1 from Marc Glisse --- And what do you expect std::string::basic_string means?
[Bug target/90513] asm thunks do not work on PowerPC64/VxWorks (kernel mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90513 --- Comment #6 from Segher Boessenkool --- Confirmed. We have for the thunk .set.LTHUNK0,_ZN12Intermediate1vEv .align 2 .p2align 4,,15 .globl _ZThn8_N12Intermediate1vEv .type _ZThn8_N12Intermediate1vEv, @function _ZThn8_N12Intermediate1vEv: .LFB27: .cfi_startproc .LCF2: 0: addis 2,12,.TOC.-.LCF2@ha addi 2,2,.TOC.-.LCF2@l .localentry _ZThn8_N12Intermediate1vEv,.-_ZThn8_N12Intermediate1vEv addi 3,3,-8 b .LTHUNK0 .cfi_endproc .LFE27: .size _ZThn8_N12Intermediate1vEv,.-_ZThn8_N12Intermediate1vEv so this will not work unless the jump is optimised by the loader to jump to the local entry point. The compiler should not require the loader to do this.
[Bug c++/90521] error: names the constructor, not the type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90521 --- Comment #2 from colton.wernet at linquest dot com --- (In reply to Marc Glisse from comment #1) > And what do you expect std::string::basic_string means? I agree it is redundant because it just means std::string::string. I am not certain why this choice was made in the gdal library. Since posting this I noticed a few things in the header: /* Avoid C2614 errors */ #ifdef MSVC_OLD_STUPID_BEHAVIOUR using std::string; # define gdal_std_string string #else # define gdal_std_string std::string #endif /* Remove annoying warnings in Microsoft eVC++ and Microsoft Visual C++ */ #if defined(WIN32CE) # pragma warning(disable:4251 4275 4786) #endif //! Convenient string class based on std::string. // This class was modified from deriving from std::string to having a string as a member. When linking against this library, linker errors would be thrown because // basic_string was already defined. It looks like this has more to do with mitigating the old microsoft tool chain than it does gcc. I apologize if this is the case. I would still greatly appreciate your input on the comments above. Thank you for your time.
[Bug c/89433] Repeated use of the OpenACC 'routine' directive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89433 --- Comment #3 from Thomas Schwinge --- Author: tschwinge Date: Fri May 17 19:13:04 2019 New Revision: 271343 URL: https://gcc.gnu.org/viewcvs?rev=271343&root=gcc&view=rev Log: [PR89433] Refer to OpenACC 'routine' clauses from "omp declare target" attribute gcc/c-family/ PR c/89433 * c-attribs.c (c_common_attribute_table): Set min_len to -1 for "omp declare target". gcc/c/ PR c/89433 * c-parser.c (c_finish_oacc_routine): Refer to OpenACC 'routine' clauses from "omp declare target" attribute. gcc/cp/ PR c++/89433 * parser.c (cp_finalize_oacc_routine): Refer to OpenACC 'routine' clauses from "omp declare target" attribute. gcc/fortran/ PR fortran/89433 * f95-lang.c (gfc_attribute_table): Set min_len to -1 for "omp declare target". * trans-decl.c (add_attributes_to_decl): Refer to OpenACC 'routine' clauses from "omp declare target" attribute. gcc/testsuite/ PR testsuite/89433 * c-c++-common/goacc/classify-routine.c: Update. * gfortran.dg/goacc/classify-routine.f95: Likewise. Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-attribs.c trunk/gcc/c/ChangeLog trunk/gcc/c/c-parser.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/f95-lang.c trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/goacc/classify-routine.c trunk/gcc/testsuite/gfortran.dg/goacc/classify-routine.f95
[Bug c/89433] Repeated use of the OpenACC 'routine' directive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89433 --- Comment #4 from Thomas Schwinge --- Author: tschwinge Date: Fri May 17 19:13:15 2019 New Revision: 271344 URL: https://gcc.gnu.org/viewcvs?rev=271344&root=gcc&view=rev Log: [PR89433] Use 'oacc_verify_routine_clauses' for C/C++ OpenACC 'routine' directives gcc/ PR middle-end/89433 * omp-general.c (oacc_build_routine_dims): Move some of its processing into... (oacc_verify_routine_clauses): ... this new function. * omp-general.h (oacc_verify_routine_clauses): New prototype. gcc/c/ PR c/89433 * c-parser.c (c_parser_oacc_routine): Normalize order of clauses. (c_finish_oacc_routine): Call oacc_verify_routine_clauses. gcc/cp/ PR c++/89433 * parser.c (cp_parser_oacc_routine) (cp_parser_late_parsing_oacc_routine): Normalize order of clauses. (cp_finalize_oacc_routine): Call oacc_verify_routine_clauses. gcc/testsuite/ PR testsuite/89433 * c-c++-common/goacc/routine-2.c: Update, and move some test into... * c-c++-common/goacc/routine-level-of-parallelism-1.c: ... this new file. Added: trunk/gcc/testsuite/c-c++-common/goacc/routine-level-of-parallelism-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/c/ChangeLog trunk/gcc/c/c-parser.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/omp-general.c trunk/gcc/omp-general.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/goacc/routine-2.c
[Bug c/89433] Repeated use of the OpenACC 'routine' directive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89433 --- Comment #5 from Thomas Schwinge --- Author: tschwinge Date: Fri May 17 19:13:26 2019 New Revision: 271345 URL: https://gcc.gnu.org/viewcvs?rev=271345&root=gcc&view=rev Log: [PR89433] Repeated use of the C/C++ OpenACC 'routine' directive gcc/ PR middle-end/89433 * omp-general.c (oacc_verify_routine_clauses): Change formal parameters. Add checking if already marked with an OpenACC 'routine' directive. Adjust all users. gcc/c/ PR c/89433 * c-parser.c (c_finish_oacc_routine): Rework checking if already marked with an OpenACC 'routine' directive. gcc/cp/ PR c++/89433 * parser.c (cp_finalize_oacc_routine): Rework checking if already marked with an OpenACC 'routine' directive. gcc/testsuite/ PR testsuite/89433 * c-c++-common/goacc/routine-5.c: Update. * c-c++-common/goacc/routine-level-of-parallelism-1.c: Likewise. * c-c++-common/goacc/routine-level-of-parallelism-2.c: New file. Added: trunk/gcc/testsuite/c-c++-common/goacc/routine-level-of-parallelism-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/c/ChangeLog trunk/gcc/c/c-parser.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/omp-general.c trunk/gcc/omp-general.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/goacc/routine-5.c trunk/gcc/testsuite/c-c++-common/goacc/routine-level-of-parallelism-1.c trunk/gcc/testsuite/gfortran.dg/goacc/routine-level-of-parallelism-1.f90
[Bug libfortran/90038] execute_command_line should not use fork()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90038
--- Comment #3 from Janne Blomqvist ---
Further testing revealed that it leaves zombie processes around as the child is
never wait()'ed for. E.g.
program cmd
implicit none
call execute_command_line("echo hi", wait=.FALSE.)
call sleep(30)
end program cmd
[Bug target/90524] New: attribute name and argument mixed up in an error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90524
Bug ID: 90524
Summary: attribute name and argument mixed up in an error
message
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The first message below is backwards: the name of the argument is 'target' and
the argument to it is "foobar":
$ cat x.c && gcc -O2 -S -Wall x.c
__attribute__ ((target ("foobar"))) void foo () { }
__attribute__ ((foobar ("target"))) void bar () { }
x.c:1:42: error: attribute ‘foobar’ argument ‘target’ is unknown
1 | __attribute__ ((target ("foobar"))) void foo () { }
| ^~~
x.c:3:1: warning: ‘foobar’ attribute directive ignored [-Wattributes]
3 | __attribute__ ((foobar ("target"))) void bar () { }
| ^
Contrast that to Clang:
$ clang -S -Wall x.c
x.c:1:25: warning: unsupported 'foobar' in the 'target' attribute string;
'target' attribute ignored [-Wignored-attributes]
__attribute__ ((target ("foobar"))) void foo () { }
^
x.c:3:17: warning: unknown attribute 'foobar' ignored [-Wunknown-attributes]
__attribute__ ((foobar ("target"))) void bar () { }
^
2 warnings generated.
[Bug target/90524] attribute name and argument mixed up in an error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90524 Martin Sebor changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-05-17 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Sebor --- Let me fix it.
[Bug go/90482] [10 regression] Many 32-bit Solaris/SPARC tests FAIL with SIGBUS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90482 Ian Lance Taylor changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Ian Lance Taylor --- I verified that tests now passed on 32-bit SPARC.
[Bug libfortran/90038] execute_command_line should not use fork()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90038
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 Janne Blomqvist from comment #3)
> Further testing revealed that it leaves zombie processes around as the child
> is never wait()'ed for. E.g.
>
> program cmd
> implicit none
> call execute_command_line("echo hi", wait=.FALSE.)
> call sleep(30)
> end program cmd
What does 'it' refer to? fork() is leaving a zombie?
posix_spawn() is leaving a zombie?
[Bug libfortran/90038] execute_command_line should not use fork()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90038 --- Comment #5 from Janne Blomqvist --- (In reply to kargl from comment #4) > What does 'it' refer to? fork() is leaving a zombie? > posix_spawn() is leaving a zombie? posix_spawn. Though I guess the old fork() code suffers from the same issue as well, though I don't think anything is using that anymore.
[Bug libfortran/90038] execute_command_line should not use fork()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90038 --- Comment #6 from Steve Kargl --- On Fri, May 17, 2019 at 07:35:46PM +, jb at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90038 > > --- Comment #5 from Janne Blomqvist --- > (In reply to kargl from comment #4) > > What does 'it' refer to? fork() is leaving a zombie? > > posix_spawn() is leaving a zombie? > > posix_spawn. Though I guess the old fork() code suffers from the same issue as > well, though I don't think anything is using that anymore. > I haven't used posxi_spawn, and it's been awhile since I used fork+execve in some code. A quick look at the posix_spwan manpage suggests we can use a combination of POSIX_SPAWN_SETSIGMASK and POSIX_SPAWN_SETSIGDEF to set up signal handlers to hopefully reap zombies.
[Bug debug/90197] [8/9/10 Regression] Cannot step through simple loop at -O -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90197 --- Comment #10 from Jakub Jelinek --- Author: jakub Date: Fri May 17 19:47:18 2019 New Revision: 271348 URL: https://gcc.gnu.org/viewcvs?rev=271348&root=gcc&view=rev Log: Backported from mainline 2019-04-26 Jakub Jelinek PR debug/90197 * c-tree.h (c_finish_loop): Add 2 further location_t arguments. * c-parser.c (c_parser_while_statement): Adjust c_finish_loop caller. (c_parser_do_statement): Likewise. (c_parser_for_statement): Likewise. Formatting fixes. * c-typeck.c (c_finish_loop): Add COND_LOCUS and INCR_LOCUS arguments, emit DEBUG_BEGIN_STMTs if needed. Modified: branches/gcc-9-branch/gcc/c/ChangeLog branches/gcc-9-branch/gcc/c/c-parser.c branches/gcc-9-branch/gcc/c/c-tree.h branches/gcc-9-branch/gcc/c/c-typeck.c
[Bug tree-optimization/90303] [9 Regression] ICE in hash_odr_name with fastcall attribute starting with r267359
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90303 --- Comment #8 from Jakub Jelinek --- Author: jakub Date: Fri May 17 19:48:25 2019 New Revision: 271349 URL: https://gcc.gnu.org/viewcvs?rev=271349&root=gcc&view=rev Log: Backported from mainline 2019-05-03 Jakub Jelinek PR tree-optimization/90303 * ipa-devirt.c (obj_type_ref_class, get_odr_type): Don't use TYPE_CANONICAL for TYPE_STRUCTURAL_EQUALITY_P types in !in_lto_p mode. * g++.target/i386/pr90303.C: New test. Added: branches/gcc-9-branch/gcc/testsuite/g++.target/i386/pr90303.C Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/ipa-devirt.c branches/gcc-9-branch/gcc/testsuite/ChangeLog
[Bug pch/90326] Using any precompiled header breaks definition of FLT_MAX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90326 --- Comment #7 from Jakub Jelinek --- Author: jakub Date: Fri May 17 19:49:54 2019 New Revision: 271350 URL: https://gcc.gnu.org/viewcvs?rev=271350&root=gcc&view=rev Log: Backported from mainline 2019-05-10 Jakub Jelinek PR pch/90326 cp/ * config-lang.in (gtfiles): Remove c-family/c-lex.c, add c-family/c-cppbuiltin.c. objc/ * config-lang.in (gtfiles): Add c-family/c-format.c. objcp/ * config-lang.in (gtfiles): Don't add c-family/c-cppbuiltin.c. testsuite/ * g++.dg/pch/pr90326.C: New test. * g++.dg/pch/pr90326.Hs: New file. Added: branches/gcc-9-branch/gcc/testsuite/g++.dg/pch/pr90326.C branches/gcc-9-branch/gcc/testsuite/g++.dg/pch/pr90326.Hs Modified: branches/gcc-9-branch/gcc/cp/ChangeLog branches/gcc-9-branch/gcc/cp/config-lang.in branches/gcc-9-branch/gcc/objc/ChangeLog branches/gcc-9-branch/gcc/objc/config-lang.in branches/gcc-9-branch/gcc/objcp/ChangeLog branches/gcc-9-branch/gcc/objcp/config-lang.in branches/gcc-9-branch/gcc/testsuite/ChangeLog
[Bug c++/90383] [9 Regression] GCC generates invalid constexpr copy/move assignment operators for types with trailing padding. (Again)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90383 --- Comment #7 from Jakub Jelinek --- Author: jakub Date: Fri May 17 19:50:52 2019 New Revision: 271351 URL: https://gcc.gnu.org/viewcvs?rev=271351&root=gcc&view=rev Log: Backported from mainline 2019-05-10 Jakub Jelinek PR c++/90383 * tree-inline.h (struct copy_body_data): Add do_not_fold member. * tree-inline.c (remap_gimple_op_r): Avoid folding expressions if id->do_not_fold. (copy_tree_body_r): Likewise. (copy_fn): Set id.do_not_fold to true. * g++.dg/cpp1y/constexpr-90383-1.C: New test. * g++.dg/cpp1y/constexpr-90383-2.C: New test. Added: branches/gcc-9-branch/gcc/testsuite/g++.dg/cpp1y/constexpr-90383-1.C branches/gcc-9-branch/gcc/testsuite/g++.dg/cpp1y/constexpr-90383-2.C Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/testsuite/ChangeLog branches/gcc-9-branch/gcc/tree-inline.c branches/gcc-9-branch/gcc/tree-inline.h
[Bug tree-optimization/90385] [9 Regression] ICE: tree check: expected ssa_name, have real_cst in transform_to_exit_first_loop_alt, at tree-parloops.c:1772
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90385 --- Comment #5 from Jakub Jelinek --- Author: jakub Date: Fri May 17 19:51:32 2019 New Revision: 271352 URL: https://gcc.gnu.org/viewcvs?rev=271352&root=gcc&view=rev Log: Backported from mainline 2019-05-10 Jakub Jelinek PR tree-optimization/90385 * tree-parloops.c (try_create_reduction_list): Punt on non-SSA_NAME arguments of the exit phis. * gfortran.dg/pr90385.f90: New test. Added: branches/gcc-9-branch/gcc/testsuite/gfortran.dg/pr90385.f90 Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/testsuite/ChangeLog branches/gcc-9-branch/gcc/tree-parloops.c
[Bug debug/90197] [8/9/10 Regression] Cannot step through simple loop at -O -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90197 --- Comment #11 from Jakub Jelinek --- Author: jakub Date: Fri May 17 19:52:06 2019 New Revision: 271353 URL: https://gcc.gnu.org/viewcvs?rev=271353&root=gcc&view=rev Log: Backported from mainline 2019-05-15 Jakub Jelinek PR debug/90197 * cp-gimplify.c (genericize_cp_loop): Emit a DEBUG_BEGIN_STMT before the condition (or if missing or constant non-zero at the end of the loop. Emit a DEBUG_BEGIN_STMT before the increment expression if any. Don't call protected_set_expr_location on incr if it already has a location. Modified: branches/gcc-9-branch/gcc/cp/ChangeLog branches/gcc-9-branch/gcc/cp/cp-gimplify.c
