[Bug debug/94283] [8/9 Regression] gcc: error: gcc/testsuite/gcc.dg/fold-bopcond-1.c: ‘-fcompare-debug’ failure since r7-4804-gb54819879e0518b3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94283
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:c2133167ad58d15c2c2df0cb4fa3a3757603144e
commit r10-7365-gc2133167ad58d15c2c2df0cb4fa3a3757603144e
Author: Jakub Jelinek
Date: Wed Mar 25 08:08:04 2020 +0100
if-conv: Delete dead stmts backwards in ifcvt_local_dce [PR94283]
> > This patch caused:
> >
> > gcc
/home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/990625-2.c -O3
-g -fno-tree-dce -c
> > during GIMPLE pass: ifcvt
> >
/home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/990625-2.c: In
function âbroken030599â:
> >
/home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/990625-2.c:2:1:
internal compiler error: Segmentation fault
>
> Likely
>
> /* Delete dead statements. */
> gsi = gsi_start_bb (bb);
> while (!gsi_end_p (gsi))
> {
>
> needs to instead work back-to-front for debug stmt adjustment to work
Indeed, that seems to work.
2020-03-25 Richard Biener
Jakub Jelinek
PR debug/94283
* tree-if-conv.c (ifcvt_local_dce): Delete dead statements
backwards.
* gcc.dg/pr94283.c: New test.
Co-authored-by: Richard Biener
[Bug target/94317] New: gcc/config/arm/arm_mve.h:13907: strange assignment ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94317
Bug ID: 94317
Summary: gcc/config/arm/arm_mve.h:13907: strange assignment ?
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
>From static analyzer cppcheck:
gcc/config/arm/arm_mve.h:13907:3: warning: Assignment of function parameter has
no effect outside the function. Did you forget dereferencing it?
[uselessAssignmentPtrArg]
Source code is
__extension__ extern __inline int64x2_t
__attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
__arm_vldrdq_gather_base_wb_s64 (uint64x2_t * __addr, const int __offset)
{
int64x2_t
result = __builtin_mve_vldrdq_gather_base_wb_sv2di (*__addr, __offset);
__addr += __offset;
return result;
}
Maybe better code:
__extension__ extern __inline int64x2_t
__attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
__arm_vldrdq_gather_base_wb_s64 (uint64x2_t * __addr, const int __offset)
{
int64x2_t
result = __builtin_mve_vldrdq_gather_base_wb_sv2di (*__addr, __offset);
*__addr += __offset; // here
return result;
}
There seem to be a few duplicates:
> trunk.git/gcc/config/arm/arm_mve.h:13917:3: warning: Assignment of function
> parameter has no effect outside the function. Did you forget dereferencing
> it? [uselessAssignmentPtrArg]
> trunk.git/gcc/config/arm/arm_mve.h:13927:3: warning: Assignment of function
> parameter has no effect outside the function. Did you forget dereferencing
> it? [uselessAssignmentPtrArg]
> trunk.git/gcc/config/arm/arm_mve.h:13937:3: warning: Assignment of function
> parameter has no effect outside the function. Did you forget dereferencing
> it? [uselessAssignmentPtrArg]
> trunk.git/gcc/config/arm/arm_mve.h:13947:3: warning: Assignment of function
> parameter has no effect outside the function. Did you forget dereferencing
> it? [uselessAssignmentPtrArg]
> trunk.git/gcc/config/arm/arm_mve.h:13957:3: warning: Assignment of function
> parameter has no effect outside the function. Did you forget dereferencing
> it? [uselessAssignmentPtrArg]
> trunk.git/gcc/config/arm/arm_mve.h:13967:3: warning: Assignment of function
> parameter has no effect outside the function. Did you forget dereferencing
> it? [uselessAssignmentPtrArg]
> trunk.git/gcc/config/arm/arm_mve.h:13977:3: warning: Assignment of function
> parameter has no effect outside the function. Did you forget dereferencing
> it? [uselessAssignmentPtrArg]
[Bug tree-optimization/93946] Bogus redundant store removal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93946
--- Comment #10 from Richard Biener ---
(In reply to sandra from comment #9)
> Both the new test cases are failing on nios2 at -Os, -O2, and -O3. I've
> done some analysis, but I'm not sure exactly where the problem lies, and
> whether this is a problem in the nios2 back end or somewhere else.
>
> long __attribute__((noipa))
> foo (struct bb *bv, void *ptr)
> {
> struct aa *a = ptr;
> struct bb *b = ptr;
> bv->b.u.f = 1;
> a->a.u.i = 0;
> b->b.u.f = 0;
> return bv->b.u.f;
> }
>
> is compiling to
>
> foo:
> movir2, 1
> stw r2, 0(r4)
> ldw r2, 0(r4)
> stw zero, 0(r5)
> stw zero, 4(r5)
> ret
>
> What's going on here is that load instructions have 3-cycle latency on
> nios2, so the sched2 pass is moving the "ldw r2, 0(r4)" to load the return
> value 2 instructions earlier ahead of the store instruction to the same
> location via the aliased pointer. :-(
>
> I'm not an expert on the instruction scheduler, and it seems like the target
> hooks and machine description syntax are all focused on modelling pipeline
> costs in order to minimize stalls, not telling the scheduler that certain
> instructions cannot be correctly reordered at all. Should some other pass
> be inserting optimization barriers, or something like that? I feel like I'm
> missing some big-picture expertise of where this needs to be fixed, so any
> suggestions to point me in the right direction would be appreciated.
The instruction scheduler needs to check dependences which should correctly
model the constraints here already. So you need to start looking at the
RTL before sched2 to see if that's sane (compare to say x86 RTL and look
for obvious signs of errors - some target expanders made errors here in the
past). Then debug sched2 as to what true/anti/output_dependence tests it
performs and why those tell sched2 moving is OK.
As you can see the fix involved touching many passes so no doubt there can
be more issues elsewhere ...
[Bug target/94123] [10 regression] r10-1734, SVN r273240, causes gcc.target/powerpc/pr87507.c to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94123 Richard Biener changed: What|Removed |Added Priority|P1 |P2 --- Comment #9 from Richard Biener --- OK, please make sure to fix the FAIL for the release in some way (add -fno-split-wide-types-early?)
[Bug target/94308] [10 Regression] ICE in final_scan_insn_1 with vzeroupper since r10-6451
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94308 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug sanitizer/94307] Provide a way to declare the *SAN exception handler -fsanitize-undefined-trap-on-error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94307 Richard Biener changed: What|Removed |Added Severity|normal |enhancement --- Comment #1 from Richard Biener --- But isn't the default without -fsanitize-undefined-trap-on-error already calling a library routine that the kernel could override?
[Bug lto/94311] LTO produces line info entries with invalid line numbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94311 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #1 from Richard Biener --- Err, but isn't this interpreting the dwarf from 'date'? So doesn't this mean that valgrind is "miscompiled" with --enable-lto rather than wrong debug?
[Bug c++/94316] An error occurs when a globally defined array of classes is initialized with values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94316 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Jonathan Wakely --- Somebody else already reported this. *** This bug has been marked as a duplicate of bug 94303 ***
[Bug middle-end/94303] [8/9/10 Regression] Program result error When using global object array (partially initialized with a special constructor, and the rest with the default constructor)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94303 Jonathan Wakely changed: What|Removed |Added CC||rookiezjz at gmail dot com --- Comment #5 from Jonathan Wakely --- *** Bug 94316 has been marked as a duplicate of this bug. ***
[Bug target/94317] gcc/config/arm/arm_mve.h:13907: strange assignment ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94317 David Binderman changed: What|Removed |Added CC||srinath.parvathaneni at arm dot co ||m --- Comment #1 from David Binderman --- git blame says: 41e1a7ffae9e (Srinath Parvathaneni 2020-03-20 12:06:26 + 13907) __addr += __offset; Adding author.
[Bug middle-end/94313] stores into string literals sometimes silently eliminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94313
--- Comment #1 from Richard Biener ---
This is likely because points-to computes the result of the string functions,
for example in g1 it computes
s_5 = { NULL STRING }
and somehow ref_maybe_used_by_stmt_p computes false for *s and f(s).
That's from
if (pt_solutions_intersect (gimple_call_use_set (call), &pi->pt))
return true;
where the points-to set for s_5 demotes to
$8 = {anything = 0, nonlocal = 0, escaped = 0, ipa_escaped = 0, null = 1,
vars_contains_nonlocal = 0, vars_contains_escaped = 0,
vars_contains_escaped_heap = 0, vars_contains_restrict = 0,
vars_contains_interposable = 0, vars = 0x76d7c520}
so we dropped STRING which we do as follows:
else if (vi->id == string_id)
/* Nobody cares - STRING_CSTs are read-only entities. */
;
which is of course true, since nothing can modify STRING_CSTs we can
technically ignore uses of appearant modifications.
Now the inconsistency is that we treat
MEM[(char *)"abc"] = 120;
f ("abc"); [tail call]
differently - a missed optimization(?). Note that before one of my
recent fixes we didn't even treat such stmts as stores (now we do).
So I see nothing inherently wrong here.
[Bug c++/94314] [10 Regression] Optimizing mismatched new/delete pairs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94314 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Target Milestone|--- |10.0 --- Comment #2 from Richard Biener --- Uh. The frontend would need to help us here, no?
[Bug d/94315] [10 regression] new tests gdc.dg/pr93038.d and gdc.dg/pr93038b.d in r10-7320 fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94315 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.0
[Bug tree-optimization/94300] [10 Regression] memcpy vector load miscompiled during const-prop since r10-6809-g7f5617b00445dcc8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94300 --- Comment #3 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:f1154b4d3c54e83d493cc66d1a30c410b9b3108a commit r10-7366-gf1154b4d3c54e83d493cc66d1a30c410b9b3108a Author: Jakub Jelinek Date: Wed Mar 25 09:17:01 2020 +0100 sccvn: Fix buffer overflow in push_partial_def [PR94300] The following testcase is miscompiled, because there is a buffer overflow in push_partial_def in the little-endian case when working 64-byte vectors. The code computes the number of bytes we need in the BUFFER: NEEDED_LEN, which is rounded up number of bits we need. Then the code native_encode_expr each (partially overlapping) pd into THIS_BUFFER. If pd.offset < 0, i.e. the pd.rhs store starts at some bits before the window we are interested in, we pass -pd.offset to native_encode_expr and shrink the size already earlier: HOST_WIDE_INT size = pd.size; if (pd.offset < 0) size -= ROUND_DOWN (-pd.offset, BITS_PER_UNIT); On this testcase, the problem is with a store with pd.offset > 0, in particular pd.offset 256, pd.size 512, i.e. a 64-byte store which doesn't fit into entirely into BUFFER. We have just: size = MIN (size, (HOST_WIDE_INT) needed_len * BITS_PER_UNIT); in this case for little-endian, which isn't sufficient, because needed_len is 64, the entire BUFFER (except of the last extra byte used for shifting). native_encode_expr fills the whole THIS_BUFFER (again, except the last extra byte), and the code then performs memcpy (BUFFER + 32, THIS_BUFFER, 64); which overflows BUFFER and as THIS_BUFFER is usually laid out after it, overflows it into THIS_BUFFER. The following patch fixes it by for pd.offset > 0 making sure size is reduced too. For big-endian the code does things differently and already handles this right. 2020-03-25 Jakub Jelinek PR tree-optimization/94300 * tree-ssa-sccvn.c (vn_walk_cb_data::push_partial_def): If pd.offset is positive, make sure that off + size isn't larger than needed_len. * gcc.target/i386/avx512f-pr94300.c: New test.
[Bug c++/94223] [10 Regression] -fcompare-debug -O0 failure on cpp1z/init-statement6.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94223 --- Comment #6 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:158cccea0d097d9f181bf4e35fdeb97865c960f7 commit r10-7367-g158cccea0d097d9f181bf4e35fdeb97865c960f7 Author: Jakub Jelinek Date: Wed Mar 25 09:18:33 2020 +0100 middle-end: Avoid using DECL_UID in ASM_FORMAT_PRIVATE_NAME [PR94223] As mentioned in the PR, we don't guarantee DECL_UID to be the same between corresponding decls in -g and -g0 builds, -g can create more decls and all that is guaranteed is that the DECL_UIDs of the corresponding decls compare the same. The following testcase gets a -fcompare-debug failure because these functions use DECL_UID as the number in ASM_FORMAT_PRIVATE_NAME. The patch fixes it by using just a sequential number there instead. I don't think this can be called during PCH writing, this only happens for non-public decls and the C/C++ FEs shouldn't mangling those at that point (furthermore C++ FE uses a different set_decl_assembler_name hook and this one is something only the gimplifier calls on C. temporaries. 2020-03-25 Jakub Jelinek PR c++/94223 * langhooks.c (lhd_set_decl_assembler_name): Use a static ulong counter instead of DECL_UID. * lto-lang.c (lto_set_decl_assembler_name): Use a static ulong counter instead of DECL_UID. * g++.dg/opt/pr94223.C: New test.
[Bug middle-end/94303] [8/9/10 Regression] Program result error When using global object array (partially initialized with a special constructor, and the rest with the default constructor)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94303
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:5f18995e23edc944af3a401d9d9d3320a9362652
commit r10-7368-g5f18995e23edc944af3a401d9d9d3320a9362652
Author: Jakub Jelinek
Date: Wed Mar 25 09:21:05 2020 +0100
varasm: Fix output_constructor where a RANGE_EXPR index needs to skip some
elts [PR94303]
The following testcase is miscompiled, because output_constructor doesn't
output the initializer correctly. The FE creates {[1...2] = 9} in this
case, and we emit .long 9; long 9; .zero 8 instead of the expected
.zero 8; .long 9; .long 9. If the CONSTRUCTOR is {[1] = 9, [2] = 9},
output_constructor_regular_field has code to notice that the current
location (local->total_bytes) is smaller than the location we want to write
to (1*sizeof(elt)) and will call assemble_zeros to skip those. But
RANGE_EXPRs are handled by a different function which didn't do this,
so for RANGE_EXPRs we emitted them properly only if local->total_bytes
was always equal to the location where the RANGE_EXPR needs to start.
2020-03-25 Jakub Jelinek
PR middle-end/94303
* varasm.c (output_constructor_array_range): If local->index
RANGE_EXPR doesn't start at the current location in the
constructor,
skip needed number of bytes using assemble_zeros or assert we don't
go backwards.
PR middle-end/94303
* g++.dg/torture/pr94303.C: New test.
[Bug tree-optimization/94300] [10 Regression] memcpy vector load miscompiled during const-prop since r10-6809-g7f5617b00445dcc8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94300 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Jakub Jelinek --- Fixed.
[Bug c++/94223] [10 Regression] -fcompare-debug -O0 failure on cpp1z/init-statement6.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94223 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #7 from Jakub Jelinek --- Fixed.
[Bug middle-end/94303] [8/9 Regression] Program result error When using global object array (partially initialized with a special constructor, and the rest with the default constructor)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94303 Jakub Jelinek changed: What|Removed |Added Summary|[8/9/10 Regression] Program |[8/9 Regression] Program |result error When using |result error When using |global object array |global object array |(partially initialized with |(partially initialized with |a special constructor, and |a special constructor, and |the rest with the default |the rest with the default |constructor)|constructor) Known to work||10.0 Known to fail|10.0| --- Comment #7 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug fortran/93484] [8/9/10 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1120 since r7-4028-g87c9fca50cbe7ca9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93484 --- Comment #4 from CVS Commits --- The master branch has been updated by Mark Eggleston : https://gcc.gnu.org/g:c38daa7976886a59a3cd496b5c776d75f3cdb056 commit r10-7369-gc38daa7976886a59a3cd496b5c776d75f3cdb056 Author: Mark Eggleston Date: Wed Mar 25 08:33:03 2020 + fortran: ICE using undeclared symbol in array constructor PR93484 Using undeclared symbol k in an expression in the following array constructor results in an ICE: print *, [real(x(k))] If the call to the intrinsic is not in a constructor a no IMPLICIT type error is reported and the ICE does not occur. Matching on an expression instead of an initialisation express an and not converting a MATCH_ERROR return value into MATCH_NO results in the no IMPLICIT error and no ICE. Note: Steven G. Kargl is the author of the changes except for the test cases. gcc/fortran/ChangeLog: PR fortran/93484 * match.c (gfc_match_type_spec): Replace gfc_match_init_expr with gfc_match_expr. Return m if m is MATCH_NO or MATCH_ERROR. gcc/testsuite PR fortran/93484 * gfortran.dg/pr93484_1.f90: New test. * gfortran.dg/pr93484_2.f90: New test.
[Bug target/81594] Optimize PowerPC vector set and store
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81594 --- Comment #5 from Segher Boessenkool --- Hi Mike, Please explain (in the code!) why we need a peephole here, why we cannot generate the faster code earlier? Or why we choose not to? Etc.
[Bug debug/94296] [10 Regression] gcc: error: gcc/testsuite/gcc.dg/cleanup-13.c: ‘-fcompare-debug’ failure (length) since r10-4482-gaea86742ce396375
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94296 --- Comment #2 from Jakub Jelinek --- Though, the testcase doesn't fail even with -fno-asynchronous-unwind-tables -fcompare-debug -fexceptions, , so I don't see how one can reproduce it in make check, even make check-gcc RUNTESTFLAGS='--target_board=unix/-fcompare-debug/-fno-asynchronous-unwind-tables/-fno-exceptions dg.exp=cleanup-13.c' is fine. So, I think this test isn't even a candidate for dg-skip-if, perhaps just a comment that the test isn't -fcompare-debug compatible with those and those options because...
[Bug c++/94288] co_await in while loop crashes g++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94288
--- Comment #6 from Martin Liška ---
(In reply to Iain Sandoe from comment #5)
> (In reply to Martin Liška from comment #4)
> > (In reply to Iain Sandoe from comment #3)
> > > thanks for the report. The reduced testcase at c#2 doesn't fire for me
> > > once
> > > pending updates are applied. However, the attached case preprocessed code
> > > does; I think we will be able to make suitable test-cases, once the
> > > analysis
> > > is done.
> >
> > If you point me to the pending patches, I can make reduction based on that?
>
> (the reduction is not urgent, I've an idea about the problem, hopefully have
> a few cycles on it tomorrow)
>
> unreviewed:
> https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542407.html
> review-in-progress:
> https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542411.html
>
> (but thanks for the offer!)
I've just applied both patches and I can still confirm that I see the failure:
$ g++ -c pr94288-reduced.cc -fcoroutines -std=c++20
pr94288-reduced.cc: In function ‘void _Z3foov.actor(foo()::_Z3foov.frame*)’:
pr94288-reduced.cc:34:3: internal compiler error: in fold_convert_loc, at
fold-const.c:2435
34 | D foo() { co_await foo(); }
| ^~~
0x747db2 fold_convert_loc(unsigned int, tree_node*, tree_node*)
../../gcc/fold-const.c:2435
0xdecd37 gimple_boolify(tree_node*)
../../gcc/gimplify.c:3960
0xdf52c8 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:13632
0xdf2d07 gimplify_modify_expr
../../gcc/gimplify.c:5766
0xdf4eb8 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:13602
0xdf8996 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6823
0xdf5f39 gimplify_cleanup_point_expr
../../gcc/gimplify.c:6565
0xdf5f39 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:13994
0xdfc41d gimplify_cond_expr
../../gcc/gimplify.c:4177
0xdf5260 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:13559
0xdf8996 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6823
0xdf6ab3 gimplify_statement_list
../../gcc/gimplify.c:1869
0xdf6ab3 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:14046
0xdf8996 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6823
0xdf6ab3 gimplify_statement_list
../../gcc/gimplify.c:1869
0xdf6ab3 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:14046
0xdf8996 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6823
0xdf4f1c gimplify_and_add(tree_node*, gimple**)
../../gcc/gimplify.c:486
0xdf4f1c gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:13953
0xdf8996 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6823
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug sanitizer/94307] Provide a way to declare the *SAN exception handler -fsanitize-undefined-trap-on-error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94307 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2020-03-25 Target Milestone|--- |11.0 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- (In reply to Kees Cook from comment #0) > Instead of unconditionally calling __builtin_trap() for > -fsanitize-undefined-trap-on-error it would help the Linux kernel's use of > UBSAN to have a way to specify the trap function. With that, Linux can use > its own internal exception handling routines and avoid various confused > states: Sure, that's definitely possible. > > https://lore.kernel.org/linux-next/20200324164433.qusyu5h7ykx3f2bu@treble/ > > For example something like -fsanitize-undefined-trap-function=__ubsan_trap > and "__ubsan_trap" can then be defined by the kernel itself. Using the > standard handler routines (__ubsan_handle_*) are too heavy duty for some > builds, so a regular trap is needed for the kernel, but this allows us to > provide a "continue anyway" option as well. I would rather add something like -fsanitize-undefined-handler=[runtime,trap,handler] where - runtime would call current __ubsan_handle_* - trap would result in ud2 - handler - can be call to __ubsan_trap Where I can imagine it will call 2 versions (__ubsan_trap and __ubsan_trap_no_return). That will depend on -fsanitize-recovery=.. I can do a patch for GCC 11.
[Bug sanitizer/94307] Provide a way to declare the *SAN exception handler -fsanitize-undefined-trap-on-error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94307 --- Comment #3 from Martin Liška --- (In reply to Richard Biener from comment #1) > But isn't the default without -fsanitize-undefined-trap-on-error already > calling > a library routine that the kernel could override? They don't want to implement all the: call__ubsan_handle_add_overflow call__ubsan_handle_divrem_overflow call__ubsan_handle_dynamic_type_cache_miss call__ubsan_handle_invalid_builtin call__ubsan_handle_load_invalid_value call__ubsan_handle_mul_overflow call__ubsan_handle_negate_overflow call__ubsan_handle_nonnull_arg call__ubsan_handle_out_of_bounds call__ubsan_handle_pointer_overflow call__ubsan_handle_shift_out_of_bounds call__ubsan_handle_sub_overflow call__ubsan_handle_type_mismatch_v1 ... run-time entry points.
[Bug sanitizer/94307] Provide a way to declare the *SAN exception handler -fsanitize-undefined-trap-on-error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94307 --- Comment #4 from Jakub Jelinek --- Well, they could just make them alias of each other, that is not the big deal, I guess they don't want to waste .rodata space on the data that provides the details to those functions and waste .text on passing the addresses of such data to the handlers. Of course, it would be much harder to understand what is going on when the functions don't tell you what exactly went wrong (but that is the same with -fsanitize-undefined-trap-on-error).
[Bug tree-optimization/94274] fold phi whose incoming args are defined from binary operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94274 --- Comment #4 from z.zhanghaijian at huawei dot com --- (In reply to Richard Biener from comment #2) > Note that with binary operations you are eventually increasing register > pressure up to a point where we need to spill so IMHO this should be only > done if both > blocks become empty after the transform. I can try to add some constraints to only do the fold when both blocks become empty after the transform. Even with this constraints, the improvements of spec2017 mentioned above can also be done, but do you think need to add a option to control this constraint to let users choose? Because the register pressure problem we worry about does not exist in most cases.
[Bug debug/94280] error: gcc/testsuite/gfortran.dg/iso_c_binding_compiler_1.f90: ‘-fcompare-debug’ failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94280 --- Comment #2 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:c8504ebef1d6a799600b8e5d255c704b7b3aa19c commit r10-7370-gc8504ebef1d6a799600b8e5d255c704b7b3aa19c Author: Jakub Jelinek Date: Wed Mar 25 10:48:27 2020 +0100 testsuite: Fix up FAILs in gfortran testsuite with -fcompare-debug [PR94280] These 3 tests use compiler_options() function, which is inherently incompatible with -fcompare-debug compilation, as it emits into a string literal in the assembly the exact f951 command line options, which differs between the two compilations with -fcompare-debug, where one has -gtoggle and -fcompare-debug-second options added and different -fdump-final-insns= option argument. The following patch adds dg-skip-if directives, so that these tests are ignored during make check-gfortran RUNTESTFLAGS='--target_board=unix/-fcompare-debug' 2020-03-25 Jakub Jelinek PR debug/94280 * gfortran.dg/iso_c_binding_compiler_1.f90: Add dg-skip-if for -fcompare-debug. * gfortran.dg/iso_c_binding_compiler_3.f90: Likewise. * gfortran.dg/unlimited_polymorphic_31.f03: Likewise.
[Bug debug/94280] error: gcc/testsuite/gfortran.dg/iso_c_binding_compiler_1.f90: ‘-fcompare-debug’ failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94280 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Jakub Jelinek --- Tests adjusted.
[Bug lto/94259] --without-zstd seems to have no effect and links libzstd if available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94259
--- Comment #6 from CVS Commits ---
The master branch has been updated by Martin Liska :
https://gcc.gnu.org/g:0fb0240a051df91d3c24385d1d3c17548b266544
commit r10-7371-g0fb0240a051df91d3c24385d1d3c17548b266544
Author: Martin Liska
Date: Wed Mar 25 11:01:43 2020 +0100
Fix handling of --with{,out}-zstd option.
PR lto/94259
* configure.ac: Respect --without-zstd and report
error when we can't find header file with --with-zstd.
* configure: Regenerate.
[Bug ipa/94271] [8/9 Regression] lto1: error: two or more sections for .gnu.lto_fast_clamp.default.9.564bf999b130b5e since r8-1461-g871cc215f7507cbe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94271 Martin Liška changed: What|Removed |Added Summary|[8/9/10 Regression] lto1: |[8/9 Regression] lto1: |error: two or more sections |error: two or more sections |for |for |.gnu.lto_fast_clamp.default |.gnu.lto_fast_clamp.default |.9.564bf999b130b5e since|.9.564bf999b130b5e since |r8-1461-g871cc215f7507cbe |r8-1461-g871cc215f7507cbe Known to work||10.0 Known to fail|10.0| --- Comment #4 from Martin Liška --- Fixed on master.
[Bug ipa/94271] [8/9/10 Regression] lto1: error: two or more sections for .gnu.lto_fast_clamp.default.9.564bf999b130b5e since r8-1461-g871cc215f7507cbe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94271 --- Comment #3 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:724ec02c2c6d1b79788be77f68ebb6ca7b5b6acd commit r10-7372-g724ec02c2c6d1b79788be77f68ebb6ca7b5b6acd Author: Martin Liska Date: Wed Mar 25 11:03:39 2020 +0100 Make target_clones resolver fn static if possible. PR target/93274 PR ipa/94271 * config/i386/i386-features.c (make_resolver_func): Drop public flag for resolver. * config/rs6000/rs6000.c (make_resolver_func): Add comdat group for resolver and drop public flag if possible. * multiple_target.c (create_dispatcher_calls): Drop unique_name and resolution as we want to enable LTO privatization of the default symbol. PR target/93274 PR ipa/94271 * gcc.target/i386/pr81213-2.c: New test. * gcc.target/i386/pr81213.c: Add additional source. * gcc.dg/lto/pr94271_0.c: New test. * gcc.dg/lto/pr94271_1.c: New test.
[Bug target/93274] target_clones produces symbols with random digits with -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93274 --- Comment #8 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:724ec02c2c6d1b79788be77f68ebb6ca7b5b6acd commit r10-7372-g724ec02c2c6d1b79788be77f68ebb6ca7b5b6acd Author: Martin Liska Date: Wed Mar 25 11:03:39 2020 +0100 Make target_clones resolver fn static if possible. PR target/93274 PR ipa/94271 * config/i386/i386-features.c (make_resolver_func): Drop public flag for resolver. * config/rs6000/rs6000.c (make_resolver_func): Add comdat group for resolver and drop public flag if possible. * multiple_target.c (create_dispatcher_calls): Drop unique_name and resolution as we want to enable LTO privatization of the default symbol. PR target/93274 PR ipa/94271 * gcc.target/i386/pr81213-2.c: New test. * gcc.target/i386/pr81213.c: Add additional source. * gcc.dg/lto/pr94271_0.c: New test. * gcc.dg/lto/pr94271_1.c: New test.
[Bug lto/94259] --without-zstd seems to have no effect and links libzstd if available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94259 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Martin Liška --- Fixed.
[Bug c++/94314] [10 Regression] Optimizing mismatched new/delete pairs since r10-2106-g6343b6bf3bb83c87
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94314 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Summary|[10 Regression] Optimizing |[10 Regression] Optimizing |mismatched new/delete pairs |mismatched new/delete pairs ||since ||r10-2106-g6343b6bf3bb83c87 CC||redi at gcc dot gnu.org Known to work||9.3.0 Last reconfirmed||2020-03-25 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Known to fail||10.0 --- Comment #3 from Martin Liška --- Yes, I remember we discussed the topic about the user-provided new/delete implementations. Can please Jason or Jonathan comment about the test-case?
[Bug d/94315] [10 regression] new tests gdc.dg/pr93038.d and gdc.dg/pr93038b.d in r10-7320 fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94315 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-03-25 Ever confirmed|0 |1 CC||marxin at gcc dot gnu.org
[Bug target/94317] gcc/config/arm/arm_mve.h:13907: strange assignment ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94317 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Last reconfirmed||2020-03-25 Target Milestone|--- |10.0 Known to fail||10.0 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Known to work||9.3.0 --- Comment #2 from Martin Liška --- The report seems to me valid, thanks for the report.
[Bug bootstrap/94318] New: [10 Regression] endless loop building _sd_to_si.o on powerpc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94318 Bug ID: 94318 Summary: [10 Regression] endless loop building _sd_to_si.o on powerpc-linux-gnu Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: doko at debian dot org Target Milestone: --- seen with trunk 20200324, trying to build a cross compiler on x86_64-linux-gnu: /packages/cross/10/u/gcc-10-cross-5ubuntu1/gcc/build/./gcc/xgcc -B/packages/cross/10/u/gcc-10-cross-5ubuntu1/gcc/build/./gcc/ -B/usr/powerpc-linux-gnu/bin/ -B/usr/powerpc-linux-gnu/lib/ -isystem /usr/powerpc-linux-gnu/include -isystem /usr/powerpc-linux-gnu/sys-include -isystem /packages/cross/10/u/gcc-10-cross-5ubuntu1/gcc/build/sys-include-g -O2 -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wstrict-prototypes -Wmissing-prototypes -Wno-error=format-diag -Wold-style-definition -isystem ./include -fPIC -mlong-double-128 -mno-minimal-toc -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fPIC -mlong-double-128 -mno-minimal-toc -I. -I. -I../.././gcc -I../../../src/libgcc -I../../../src/libgcc/. -I../../../src/libgcc/../gcc -I../../../src/libgcc/../include -I../../../src/libgcc/../libdecnumber/dpd -I../../../src/libgcc/../libdecnumber -DHAVE_CC_TLS -o _sd_to_si.o -MT _sd_to_si.o -MD -MP -MF _sd_to_si.dep -DFINE_GRAINED_LIBRARIES -DL_sd_to_si -DWIDTH=32 -c ../../../src/libgcc/dfp-bit.c $ find build/ -name _sd_to_si* build/powerpc-linux-gnu/64/libgcc/_sd_to_si.dep build/powerpc-linux-gnu/64/libgcc/_sd_to_si.o looks like the 64bit multilib build is built correctly. Program received signal SIGINT, Interrupt. update_pseudo_point (regno=12183, point=24121, type=USE_POINT) at ../../src/gcc/lra-lives.c:245 245 update_pseudo_point (int regno, int point, enum point_type type) (gdb) bt #0 update_pseudo_point (regno=12183, point=24121, type=USE_POINT) at ../../src/gcc/lra-lives.c:245 #1 0x00967380 in process_bb_lives (dead_insn_p=false, curr_point=@0x7fffd1dc: 24121, bb=0x771b61a0) at ../../src/gcc/lra-lives.c:846 #2 lra_create_live_ranges_1 (all_p=, dead_insn_p=false) at ../../src/gcc/lra-lives.c:1388 #3 0x0094cc38 in lra (f=) at ../../src/gcc/lra.c:2476 #4 0x0090989a in do_reload () at ../../src/gcc/ira.c:5523 #5 (anonymous namespace)::pass_reload::execute (this=) at ../../src/gcc/ira.c:5709 #6 0x00a092b8 in execute_one_pass (pass=0x1b20120) at ../../src/gcc/passes.c:2502 #7 0x00a09bf0 in execute_pass_list_1 (pass=0x1b20120) at ../../src/gcc/passes.c:2590 #8 0x00a09c02 in execute_pass_list_1 (pass=0x1b1ef20) at ../../src/gcc/passes.c:2591 #9 0x00a09c2d in execute_pass_list (fn=0x77294630, pass=) at ../../src/gcc/passes.c:2601 #10 0x006f124e in cgraph_node::expand (this=0x7718a9d8) at ../../src/gcc/context.h:48 #11 0x006f22c0 in expand_all_functions () at ../../src/gcc/cgraphunit.c:2471 #12 symbol_table::compile (this=0x7746f000) at ../../src/gcc/cgraphunit.c:2821 #13 0x006f436d in symbol_table::compile (this=0x7746f000) at ../../src/gcc/cgraphunit.c:3001 #14 symbol_table::finalize_compilation_unit (this=0x7746f000) at ../../src/gcc/cgraphunit.c:3001 #15 0x00acab3d in compile_file () at ../../src/gcc/toplev.c:483 #16 0x0059b0c6 in do_compile () at ../../src/gcc/toplev.c:2273 #17 toplev::main (this=this@entry=0x7fffd616, argc=, argc@entry=35, argv=, argv@entry=0x7fffd728) at ../../src/gcc/toplev.c:2412 #18 0x0059d900 in main (argc=35, argv=0x7fffd728) at ../../src/gcc/main.c:39 Configured with: -v --enable-languages=c,c++,go,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-10 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm --disable-libquadmath --disable-libquadmath-support --enable-plugin --with-system-zlib --disable-libphobos --enable-secureplt --disable-softfloat --with-cpu=default32 --disable-softfloat --enable-targets=powerpc-linux,powerpc64-linux --enable-multiarch --disable-werror --with-long-double-128 --enable-multilib --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target
[Bug d/94305] libphobos: Add configure flag to build phobos in non-release mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94305 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2020-03-25 CC||marxin at gcc dot gnu.org
[Bug d/94304] libphobos: Add --with-libdruntime-only configure option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94304 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-03-25 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1
[Bug bootstrap/94318] [10 Regression] endless loop building _sd_to_si.o on powerpc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94318 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- Isn't that dup of PR94072?
[Bug bootstrap/94318] [10 Regression] endless loop building _sd_to_si.o on powerpc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94318 --- Comment #2 from Martin Liška --- (In reply to Martin Liška from comment #1) > Isn't that dup of PR94072? Sorry, this one PR94042.
[Bug bootstrap/94318] [10 Regression] endless loop building _sd_to_si.o on powerpc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94318 --- Comment #3 from Martin Liška --- (In reply to Martin Liška from comment #2) > (In reply to Martin Liška from comment #1) > > Isn't that dup of PR94072? > > Sorry, this one PR94042. I don't have a good day. This link should be what I'm looking for: PR94254
[Bug bootstrap/94318] [10 Regression] endless loop building _sd_to_si.o on powerpc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94318 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.0
[Bug target/94308] [10 Regression] ICE in final_scan_insn_1 with vzeroupper since r10-6451
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94308 --- Comment #3 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:d5ad8ee04a78b576867fd78b2f25201ea6b4aae1 commit r10-7373-gd5ad8ee04a78b576867fd78b2f25201ea6b4aae1 Author: Jakub Jelinek Date: Wed Mar 25 11:40:00 2020 +0100 i386: Fix ix86_add_reg_usage_to_vzeroupper [PR94308] The following patch ICEs due to my recent change r10-6451-gb7b3378f91c. Since that patch, for explicit vzeroupper in the sources (when an intrinsic is used), we start with the *avx_vzeroupper_1 pattern which contains just the UNSPECV_VZEROUPPER and no sets/clobbers. The vzeroupper pass then adds some sets to those, but doesn't add clobbers and finally there is an && epilogue_completed splitter that splits this into the *avx_vzeroupper pattern which has the right number of sets/clobbers (16 on 64-bit, 8 on 32-bit) + the UNSPECV_VZEROUPPER first. The problem with this testcase on !TARGET_64BIT is that the vzeroupper pass adds 8 sets to the pattern, i.e. the maximum number, but INSN_CODE stays to be the one of the *avx_vzeroupper_1 pattern. The splitter doesn't do anything here, because it sees the number of rtxes in the PARALLEL already the right count, but during final we see that the *avx_vzeroupper_1 pattern has "#" output template and ICE that we forgot to split it. The following patch fixes it by forcing re-recognition of the insn after we make the changes to it in ix86_add_reg_usage_to_vzeroupper. Anything that will call recog_memoized later on will recog it and find out it is in this case already *avx_vzeroupper rather than *avx_vzeroupper_1. 2020-03-25 Jakub Jelinek PR target/94308 * config/i386/i386-features.c (ix86_add_reg_usage_to_vzeroupper): Set INSN_CODE (insn) to -1 when changing the pattern. * gcc.target/i386/pr94308.c: New test.
[Bug debug/94296] [10 Regression] gcc: error: gcc/testsuite/gcc.dg/cleanup-13.c: ‘-fcompare-debug’ failure (length) since r10-4482-gaea86742ce396375
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94296 --- Comment #3 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:780f1cfd8eef90f6f5ea84cf58aa97e07c0c2aa1 commit r10-7374-g780f1cfd8eef90f6f5ea84cf58aa97e07c0c2aa1 Author: Jakub Jelinek Date: Wed Mar 25 11:41:17 2020 +0100 testsuite: Mention cleanup-13.c test is incompatible with -fcompare-debug [PR94296] As this test produces different code depending on whether __GCC_HAVE_DWARF2_CFI_ASM macro is defined or not, it is inherently incompatible with -fcompare-debug, as with -fcompare-debug -fno-asynchronous-unwind-tables -fno-exceptions the macro is defined only in the -g case and not otherwise. The purpose of the macro is to tell when the compiler is emitting .cfi* directives itself and thus it is desirable that user code uses them in inline asm as well, so I think it is fine the way it is. As -fexceptions makes the test pass even in that case because it emits .cfi* directives, the test actually doesn't FAIL even with make check-gcc RUNTESTFLAGS='--target_board=unix/-fcompare-debug/-fno-asynchronous-unwind-tables/-fno-exceptions dg.exp=cleanup-13.c' so the intent of this patch is help Martin and others who do run gcc tests out of the testsuite with random compiler flags to find out that this is a known issue. 2020-03-25 Jakub Jelinek PR debug/94296 * gcc.dg/cleanup-13.c: Add a comment that the test is not -fcompare-debug compatible with certain other options.
[Bug debug/94296] [10 Regression] gcc: error: gcc/testsuite/gcc.dg/cleanup-13.c: ‘-fcompare-debug’ failure (length) since r10-4482-gaea86742ce396375
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94296 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Added comment to testcase.
[Bug target/94308] [10 Regression] ICE in final_scan_insn_1 with vzeroupper since r10-6451
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94308 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Jakub Jelinek --- Fixed.
[Bug c++/94314] [10 Regression] Optimizing mismatched new/delete pairs since r10-2106-g6343b6bf3bb83c87
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94314 --- Comment #4 from Richard Biener --- (In reply to Martin Liška from comment #3) > Yes, I remember we discussed the topic about the user-provided new/delete > implementations. Can please Jason or Jonathan comment about the test-case? The testcase is certainly valid. The issue is we're matching new/delete pairs by means of dataflow (the new resulting pointer is fed to the delete) and identify new/delete by the decls flag. But that doesn't catch the case in this PR where there is a mismatch between the new/delete calls. Now - the question is if whether class-specific operator new/delete even have to "match" in this sense or how it's possible to "match" at all. I think the frontend has to provide some "link" between the new/delete decls to make this work (which is then quite heavy - an extra pointer in function decls) :/
[Bug lto/94311] LTO produces line info entries with invalid line numbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94311 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Last reconfirmed||2020-03-25 --- Comment #2 from Martin Liška --- I've just tested GCC 9 and current master and it works for me: $ ./install/bin/valgrind -q ~/bin/gcc/bin/gcc --version gcc (GCC) 10.0.1 20200320 (experimental) Copyright (C) 2020 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ /install/bin/valgrind -q date Wed 25 Mar 2020 11:43:10 AM CET $ ./install/bin/valgrind /tmp/a.out ==32006== Memcheck, a memory error detector ==32006== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==32006== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info ==32006== Command: /tmp/a.out ==32006== ==32006== ==32006== Process terminating with default action of signal 6 (SIGABRT): dumping core ==32006==at 0x48BEEA1: raise (raise.c:51) ==32006==by 0x48A853C: abort (abort.c:79) ==32006==by 0x40112D: main (foo.c:6) Here you can see that foo.c:6 is properly read from debuginfo. Note that one can remove -flto-partition=one from CFLAGS. That rapidly speeds up the build.
[Bug target/94254] [10 regression] r10-7312 causes compiler hangs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94254 Matthias Klose changed: What|Removed |Added CC||doko at debian dot org --- Comment #17 from Matthias Klose --- *** Bug 94318 has been marked as a duplicate of this bug. ***
[Bug bootstrap/94318] [10 Regression] endless loop building _sd_to_si.o on powerpc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94318 Matthias Klose changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Matthias Klose --- yes, and the patch seems to fix it *** This bug has been marked as a duplicate of bug 94254 ***
[Bug c++/94319] New: gcc/cp/coroutines.cc:2654: strange assignment ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94319 Bug ID: 94319 Summary: gcc/cp/coroutines.cc:2654: strange assignment ? Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- >From static analyser cppcheck: gcc/cp/coroutines.cc:2654:3: warning: Assignment of function parameter has no effect outside the function. Did you forget dereferencing it? [uselessAs signmentPtrArg] Source code is /* As far as it's necessary, we've walked the subtrees of the call expr. */ do_subtree = 0; return NULL_TREE; } Following on from code in the same routine, maybe better code might be /* As far as it's necessary, we've walked the subtrees of the call expr. */ *do_subtree = 0; return NULL_TREE; }
[Bug c++/94319] gcc/cp/coroutines.cc:2654: strange assignment ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94319 David Binderman changed: What|Removed |Added CC||iains at gcc dot gnu.org --- Comment #1 from David Binderman --- git blame says: 49789fd08378 (Iain Sandoe 2020-01-18 11:54:46 + 2654) do_subtree = 0; Adding author.
[Bug c++/94314] [10 Regression] Optimizing mismatched new/delete pairs since r10-2106-g6343b6bf3bb83c87
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94314 --- Comment #5 from Marc Glisse --- I don't think we need heavy machinery linking new and delete (and if we did I'd be tempted to store it in some global table rather than in the nodes). The most important case is the global replacable functions, for which we have a finite list, and for those a few checks like not matching array with non-array versions should do. For user overloads with attribute malloc (a gcc extension), I would go with heuristics like both/neither being class members, being members of the same class, etc. Although I am not quite sure how doable that is from the middle-end, how much of that information is still available (I think it is available in the mangled name, but demangling doesn't seem like a great idea).
[Bug lto/94320] New: [OpenMP][Offloading] lto1 ICE during IPA pass: inline – offline_size at gcc/ipa-inline-analysis.c:453
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94320
Bug ID: 94320
Summary: [OpenMP][Offloading] lto1 ICE during IPA pass: inline
– offline_size at gcc/ipa-inline-analysis.c:453
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, openmp
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
May or may not be related to PR 92029
Still reducing the test case. When compiling with "-fopenmp -O0" it works, but
with "-fopenmp -O1" the offloading-compiler (AMDGCN or – has here – nvptx) ICEs
with:
during IPA pass: inline
lto1: internal compiler error: Segmentation fault
0xbdb6ff crash_signal
/net/build5-trusty-cs/scratch/tburnus/openacc.x86_64-linux-gnu-openacc-mainline/src/gcc-mainline/gcc/toplev.c:328
0x98074f offline_size
/net/build5-trusty-cs/scratch/tburnus/openacc.x86_64-linux-gnu-openacc-mainline/src/gcc-mainline/gcc/ipa-inline-analysis.c:453
0x980b58 growth_positive_p(cgraph_node*, cgraph_edge*, int)
/net/build5-trusty-cs/scratch/tburnus/openacc.x86_64-linux-gnu-openacc-mainline/src/gcc-mainline/gcc/ipa-inline-analysis.c:549
0x138610f want_inline_function_to_all_callers_p
/net/build5-trusty-cs/scratch/tburnus/openacc.x86_64-linux-gnu-openacc-mainline/src/gcc-mainline/gcc/ipa-inline.c:1088
0x138c37f ipa_inline
/net/build5-trusty-cs/scratch/tburnus/openacc.x86_64-linux-gnu-openacc-mainline/src/gcc-mainline/gcc/ipa-inline.c:2752
0x138d099 execute
/net/build5-trusty-cs/scratch/tburnus/openacc.x86_64-linux-gnu-openacc-mainline/src/gcc-mainline/gcc/ipa-inline.c:3091
It fails in ipa-inline-analysis.c's:
offline_size (struct cgraph_node *node, ipa_size_summary *info)
{
if (!DECL_EXTERNAL (node->decl))
{
if (node->will_be_removed_from_program_if_no_direct_calls_p ())
return info->size;
as info == NULL and decl is " get (node);
And ->get returns:
369 return exists (node) ? (*m_vector)[node->get_summary_id ()] : NULL;
[Bug lto/94320] [OpenMP][Offloading] lto1 ICE during IPA pass: inline – offline_size at gcc/ipa-inline-analysis.c:453
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94320 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Perhaps related to PR92357? I'm stuck there, tried 2020-02-07 Jakub Jelinek PR ipa/92357 * symtab.c (symtab_node::get_partitioning_class): Don't return SYMBOL_DUPLICATE for DECL_ONE_ONLY symbols if lto_stream_offload_p. --- gcc/symtab.c.jj 2020-01-15 11:05:19.589136168 +0100 +++ gcc/symtab.c2020-02-07 19:57:55.625108414 +0100 @@ -2003,6 +2003,7 @@ symtab_node::get_partitioning_class (voi if (DECL_ONE_ONLY (decl) && !force_output && !forced_by_abi + && !lto_stream_offload_p && !used_from_object_file_p ()) return SYMBOL_DUPLICATE; but it didn't work out. I'm afraid we need to actually implement properly the OpenMP 5.0 automatic omp declare target discovery and before IPA run perhaps another iteration of that and make sure that if we offload something, we either offload everything it refers to too (unless DECL_EXTERNAL), or diagnose it.
[Bug c++/94319] gcc/cp/coroutines.cc:2654: strange assignment ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94319 --- Comment #2 from Iain Sandoe --- (In reply to David Binderman from comment #1) > git blame says: > > 49789fd08378 (Iain Sandoe 2020-01-18 11:54:46 + 2654) do_subtree = 0; > > Adding author. indeed looks like a typo. thanks
[Bug lto/91027] [10 regression] SEGV in hash_table::find_slot_with_hash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91027 Rainer Orth changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #14 from Rainer Orth --- Unfortunately, the bug is not fixed: while the original SEGV doesn't happen any longer, I now see the ICE originally reported in Comment #6 on both i386-pc-solaris2.11 and sparc-sun-solaris2.11: FAIL: gdc.dg/lto/ltotests d_lto_ltotests_0.o-d_lto_ltotests_1.o link, -O0 -flto -flto-partition=none (internal compiler error) during IPA pass: pure-const^M lto1: internal compiler error: in get_odr_type, at ipa-devirt.c:1936^M 0x7c4dfb get_odr_type(tree_node*, bool)^M /vol/gcc/src/hg/master/local/gcc/ipa-devirt.c:1936^M 0x7cba63 build_type_inheritance_graph()^M /vol/gcc/src/hg/master/local/gcc/ipa-devirt.c:2283^M 0x822f83 symbol_table::remove_unreachable_nodes(__FILE*)^M /vol/gcc/src/hg/master/local/gcc/ipa.c:320^M 0x476fd7 read_cgraph_and_symbols(unsigned int, char const**)^M /vol/gcc/src/hg/master/local/gcc/lto/lto-common.c:2915^M 0x459043 lto_main()^M /vol/gcc/src/hg/master/local/gcc/lto/lto.c:625^M
[Bug d/94321] New: gdc.dg/pr92216.d FAILs on 32-bit targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94321 Bug ID: 94321 Summary: gdc.dg/pr92216.d FAILs on 32-bit targets Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: ro at gcc dot gnu.org Target Milestone: --- Target: i386-pc-solaris2.11, sparc-sun-solaris2.11 As originally reported in https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542177.html [which didn't get Cc'ed to you due to the abominable header rewriting]: The new gdc.dg/pr92216.d testcase FAILs on 32-bit Solaris/SPARC and x86 (and, I suppose, on every non-64-bit target): +FAIL: gdc.dg/pr92216.d -O0 scan-assembler _DT16_D7imports7pr922161B8__mixin24getSMFZPv[: \\t\\n] +FAIL: gdc.dg/pr92216.d -O0 -frelease scan-assembler _DT16_D7imports7pr922161B8__mixin24getSMFZPv[: \\t\\n] +FAIL: gdc.dg/pr92216.d -O0 -frelease -g scan-assembler _DT16_D7imports7pr922161B8__mixin24getSMFZPv[: \\t\\n] +FAIL: gdc.dg/pr92216.d -O0 -g scan-assembler _DT16_D7imports7pr922161B8__mixin24getSMFZPv[: \\t\\n] Same at -O[1-3s]. While the 64-bit version contains the expected _DT16_D7imports7pr922161B8__mixin24getSMFZPv the 32-bit one has _DT8_D7imports7pr922161B8__mixin24getSMFZPv I can't tell for certain if it's enough to allow for those two variants or if more is needed. Btw., I noticed that binutils 2.34 c++filt -s dlang cannot demangle those symbols. Is this expected?
[Bug lto/94311] LTO produces line info entries with invalid line numbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94311 --- Comment #3 from Mark Wielaard --- (In reply to Richard Biener from comment #1) > Err, but isn't this interpreting the dwarf from 'date'? So doesn't this > mean that valgrind is "miscompiled" with --enable-lto rather than wrong > debug? The error message isn't very clear, but valgrind also reads its own code/binary (which is inserted into the process), which is build with LTO. It is that library that has the wrong line numbers. Which can also be seen in gdb: ./install/bin/valgrind -q date ==48528== warning: Can't handle line info entry with line number 177277754 greater than 1048575 ==48528== (Nb: this message is only shown once) ==48528== warning: Can't handle inlined call info entry with line number 177277750 greater than 1048575 ==48528== (Nb: this message is only shown once) Double check that valgrind debug info reader is correct: gdb ./.in_place/memcheck-amd64-linux Reading symbols from ./.in_place/memcheck-amd64-linux... (gdb) info line guest_amd64_toIR.c:177277754 Line number 177277754 is out of range for "priv/guest_amd64_toIR.c". Line 177277754 of "priv/guest_amd64_toIR.c" starts at address 0x58069001 and ends at 0x58069005 . (gdb) You can also try: (gdb) disass /s dis_ESC_0F__SSE4 and you zillions of useless lines. If needed, you can ask valgrind to show more info about what it is doing/reading by doing e.g. ./install/bin/valgrind -v -v -v -v -d -d -d -d --debug-dump=line date |& tee d.out
[Bug d/94321] gdc.dg/pr92216.d FAILs on 32-bit targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94321 Rainer Orth changed: What|Removed |Added Target Milestone|--- |10.0
[Bug c/94322] New: Detected memory leaks while using clang AddressSanitizer to build GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94322 Bug ID: 94322 Summary: Detected memory leaks while using clang AddressSanitizer to build GCC Product: gcc Version: 8.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: haoxintu at gmail dot com Target Milestone: --- Hi, I use clang with AddressSanitizer and detected memory leaks while building GCC. The SUMMARY are: = ==7174==ERROR: LeakSanitizer: detected memory leaks Direct leak of 112 byte(s) in 1 object(s) allocated from: #0 0x4debb0 (/home/haoxin/corpus-compilers/clang-build-gcc8/build/gcc/build/genhooks+0x4debb0) #1 0x521a45 (/home/haoxin/corpus-compilers/clang-build-gcc8/build/gcc/build/genhooks+0x521a45) #2 0x51e2a9 (/home/haoxin/corpus-compilers/clang-build-gcc8/build/gcc/build/genhooks+0x51e2a9) #3 0x51a8e5 (/home/haoxin/corpus-compilers/clang-build-gcc8/build/gcc/build/genhooks+0x51a8e5) #4 0x7f20623dc82f (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) Direct leak of 23 byte(s) in 1 object(s) allocated from: #0 0x4de998 (/home/haoxin/corpus-compilers/clang-build-gcc8/build/gcc/build/genhooks+0x4de998) #1 0x5219c1 (/home/haoxin/corpus-compilers/clang-build-gcc8/build/gcc/build/genhooks+0x5219c1) #2 0x521b7d (/home/haoxin/corpus-compilers/clang-build-gcc8/build/gcc/build/genhooks+0x521b7d) #3 0x51bb89 (/home/haoxin/corpus-compilers/clang-build-gcc8/build/gcc/build/genhooks+0x51bb89) #4 0x7f20623dc82f (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) Indirect leak of 13368 byte(s) in 456 object(s) allocated from: #0 0x4de998 (/home/haoxin/corpus-compilers/clang-build-gcc8/build/gcc/build/genhooks+0x4de998) #1 0x5219c1 (/home/haoxin/corpus-compilers/clang-build-gcc8/build/gcc/build/genhooks+0x5219c1) #2 0x521b7d (/home/haoxin/corpus-compilers/clang-build-gcc8/build/gcc/build/genhooks+0x521b7d) #3 0x51a9f0 (/home/haoxin/corpus-compilers/clang-build-gcc8/build/gcc/build/genhooks+0x51a9f0) #4 0x7f20623dc82f (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) Indirect leak of 8168 byte(s) in 1 object(s) allocated from: #0 0x4debb0 (/home/haoxin/corpus-compilers/clang-build-gcc8/build/gcc/build/genhooks+0x4debb0) #1 0x521a45 (/home/haoxin/corpus-compilers/clang-build-gcc8/build/gcc/build/genhooks+0x521a45) #2 0x520384 (/home/haoxin/corpus-compilers/clang-build-gcc8/build/gcc/build/genhooks+0x520384) #3 0x51f5af (/home/haoxin/corpus-compilers/clang-build-gcc8/build/gcc/build/genhooks+0x51f5af) #4 0x51ab44 (/home/haoxin/corpus-compilers/clang-build-gcc8/build/gcc/build/genhooks+0x51ab44) #5 0x7f20623dc82f (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) Indirect leak of 7296 byte(s) in 456 object(s) allocated from: #0 0x4de998 (/home/haoxin/corpus-compilers/clang-build-gcc8/build/gcc/build/genhooks+0x4de998) #1 0x5219c1 (/home/haoxin/corpus-compilers/clang-build-gcc8/build/gcc/build/genhooks+0x5219c1) #2 0x51a9e5 (/home/haoxin/corpus-compilers/clang-build-gcc8/build/gcc/build/genhooks+0x51a9e5) #3 0x7f20623dc82f (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) SUMMARY: AddressSanitizer: 28967 byte(s) leaked in 915 allocation(s). Makefile:2504: recipe for target 's-tm-texi' failed make[3]: *** [s-tm-texi] Error 1 make[3]: *** Waiting for unfinished jobs 31 warnings generated. 19 warnings generated. rm fsf-funding.pod gcov.pod gpl.pod cpp.pod gcc.pod make[3]: Leaving directory '/home/haoxin/corpus-compilers/clang-build-gcc8/build/gcc' Makefile:4617: recipe for target 'all-stage1-gcc' failed make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory '/home/haoxin/corpus-compilers/clang-build-gcc8/build' Makefile:24352: recipe for target 'stage1-bubble' failed make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory '/home/haoxin/corpus-compilers/clang-build-gcc8/build' Makefile:944: recipe for target 'all' failed Here are my instructions: $export FUZZ_FLAGS="-O2 -fno-omit-frame-pointer -g -fsanitize=address -fsanitize-coverage=edge,trace-pc-guard,indirect-calls,trace-cmp,trace-div,trace-gep" $CC="clang $FUZZ_FLAGS" CXX="clang++ $FUZZ_FLAGS" ../configure $make -j4 Without FUZZ_FLAGS, clang can build GCC well. I used GCC-8.1.0, clang-6.0, and Ubuntu16.04.
[Bug c/94322] Detected memory leaks while using clang AddressSanitizer to build GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94322 --- Comment #1 from Richard Biener --- We're quite lazy in freeing all memory from generator tools (genhooks as you report) but there are also known leaks in the driver when it comes to command-line processing. That is, not all memory leaks are considered equal.
[Bug fortran/94289] Assumed-rank array bounds resuscitate on the second call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94289 --- Comment #1 from José Rui Faustino de Sousa --- Hi all! My first comment is not very clear so to elaborate a bit. For assumed-rank arrays no temporary array descriptor with the correct bounds is created like it is for assumed-shape arrays. So although the array bounds are correctly reported by the lbound, ubound and shape intrinsics the underlying array descriptor is still the original one. And since it is the original array descriptor, not a temporary with correct array bounds, that is passed down the call chain subsequent procedures will get a descriptor with the wrong bounds. This will probably imply adding assumed-rank arrays to the deferred initialization list, which is already done (I guess accidentally) for bind(c) procedures. I guess by removing the condition on the first if clause in gfc_build_dummy_array_decl and, hopefully, then in the "type_of_array" switch in gfc_trans_deferred_vars. This will imply also solving PR93957. Best regards, José Rui
[Bug lto/94259] --without-zstd seems to have no effect and links libzstd if available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94259 --- Comment #8 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:68c4570a4dea8ed6fefaea50943fb74ea8f78319 commit r10-7375-g68c4570a4dea8ed6fefaea50943fb74ea8f78319 Author: Martin Liska Date: Wed Mar 25 13:34:53 2020 +0100 Do not error about missing zstd unless --with-zstd. PR lto/94259 * configure.ac: Report error only when --with-zstd is used. * configure: Regenerate.
[Bug c/94322] Detected memory leaks while using clang AddressSanitizer to build GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94322 Martin Liška changed: What|Removed |Added Priority|P3 |P5 CC||marxin at gcc dot gnu.org Blocks||86656 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86656 [Bug 86656] [meta-bug] Issues found with -fsanitize=address
[Bug debug/94323] New: [10 Regression] g++: error: x.cpp: ‘-fcompare-debug’ failure since r10-7359-g6e771c087b10d5b730240ea35478eab8694c9c5d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94323
Bug ID: 94323
Summary: [10 Regression] g++: error: x.cpp: ‘-fcompare-debug’
failure since
r10-7359-g6e771c087b10d5b730240ea35478eab8694c9c5d
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: jakub at gcc dot gnu.org, jason at gcc dot gnu.org
Target Milestone: ---
Since the revision I see:
$ cat x.cpp
volatile int a;
void fn1() {
({ a; });
}
$ g++ x.cpp -O2 -fcompare-debug -c
g++: error: x.cpp: ‘-fcompare-debug’ failure
[Bug debug/94323] [10 Regression] g++: error: x.cpp: ‘-fcompare-debug’ failure since r10-7359-g6e771c087b10d5b730240ea35478eab8694c9c5d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94323 Martin Liška changed: What|Removed |Added Known to fail||10.0 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Known to work||9.3.0 Target Milestone|--- |10.0 Last reconfirmed||2020-03-25
[Bug fortran/94324] [10 regression] gfortran.dg/default_format_1.f90 etc. FAIL on 32-bit Solaris/x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94324 Rainer Orth changed: What|Removed |Added Target Milestone|--- |10.0
[Bug fortran/94324] New: [10 regression] gfortran.dg/default_format_1.f90 etc. FAIL on 32-bit Solaris/x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94324 Bug ID: 94324 Summary: [10 regression] gfortran.dg/default_format_1.f90 etc. FAIL on 32-bit Solaris/x86 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org Target Milestone: --- Target: i386-pc-solaris2.11 I just remembered that between 20191031 (r277679) and 20191101 (r277705) a couple of Fortran tests regressed on 32-bit Solaris/x86: +FAIL: gfortran.dg/default_format_1.f90 -O0 execution test +FAIL: gfortran.dg/default_format_1.f90 -O1 execution test +FAIL: gfortran.dg/default_format_1.f90 -O2 execution test +FAIL: gfortran.dg/default_format_1.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test +FAIL: gfortran.dg/default_format_1.f90 -O3 -g execution test +FAIL: gfortran.dg/default_format_1.f90 -Os execution test Note: The following floating-point exceptions are signalling: IEEE_UNDERFLOW_FLAG STOP 6 #2 0x08051851 in MAIN__ () at /vol/gcc/src/hg/master/local/gcc/testsuite/gfortran.dg/default_format_1.f90:20 20if (test (1.0_8, 0) /= 0) STOP 6 +FAIL: gfortran.dg/fmt_g0_1.f08 -O0 execution test +FAIL: gfortran.dg/fmt_g0_1.f08 -O1 execution test +FAIL: gfortran.dg/fmt_g0_1.f08 -O2 execution test +FAIL: gfortran.dg/fmt_g0_1.f08 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test +FAIL: gfortran.dg/fmt_g0_1.f08 -O3 -g execution test +FAIL: gfortran.dg/fmt_g0_1.f08 -Os execution test STOP 3 #2 0x0805143d in MAIN__ () at /vol/gcc/src/hg/master/local/gcc/testsuite/gfortran.dg/fmt_g0_1.f08:11 11 if (buffer.ne.":0.1:") STOP 3 (gdb) p buffer $1 = ':0.', '3' , '2:', ' ' +FAIL: gfortran.dg/round_4.f90 -O0 execution test +FAIL: gfortran.dg/round_4.f90 -O1 execution test +FAIL: gfortran.dg/round_4.f90 -O2 execution test +FAIL: gfortran.dg/round_4.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test +FAIL: gfortran.dg/round_4.f90 -O3 -g execution test +FAIL: gfortran.dg/round_4.f90 -Os execution test STOP 15 #2 0x08051f41 in MAIN__ () at /vol/gcc/src/hg/master/local/gcc/testsuite/gfortran.dg/round_4.f90:100 100 if (rnd10 .and. (r10p /= ref10u .or. r10m /= -ref10u)) STOP 15 (gdb) p rnd10 $1 = .TRUE. (gdb) p r10p $2 = 0.15551 (gdb) p ref10u $3 = 0.10001 (gdb) p r10m $4 = -0.15551 (gdb) p ref10u $5 = 0.10001 Since I found nothing in the above revision range that might have caused this and the failures only occur on Solaris 11.5 Beta, but not on Solaris 11.4, I suspect that the cause of the failure lies somewhere with the OS (libc or libm). However, given that I know nothing about fortran, it would be very helpful to have some guidance on where to look.
[Bug c++/94325] New: [UBSAN] "invalid vptr" false positive for virtual inheritance with -fno-sanitize-recover=all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94325 Bug ID: 94325 Summary: [UBSAN] "invalid vptr" false positive for virtual inheritance with -fno-sanitize-recover=all Product: gcc Version: 9.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jaroslaw.melzer.gcc at gmail dot com Target Milestone: --- Created attachment 48111 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48111&action=edit reproducer code See attached: ubsan-gcc.ii Program ubsan-gcc compiled with options: g++ -fsanitize=undefined -fno-sanitize-recover=all ubsan-gcc.ii exits with following false positive: ubsan-gcc.cpp:12:7: runtime error: member call on address 0x7ffcdd8c9800 which does not point to an object of type 'DE' 0x7ffcdd8c9800: note: object has invalid vptr 17 56 00 00 00 00 00 00 00 00 00 00 00 76 43 93 7b 4b c2 bf 30 71 eb 2f 17 56 00 00 e3 41 18 cc ^~~ invalid vptr May be related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87095 This error doesn't manifest without -fno-sanitize-recover=all gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none:hsa OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 9.2.1-9ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-9 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none,hsa --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 9.2.1 20191008 (Ubuntu 9.2.1-9ubuntu2)
[Bug target/94317] gcc/config/arm/arm_mve.h:13907: strange assignment ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94317 --- Comment #3 from Srinath Parvathaneni --- Thanks David for reporting this issue, I'm working on it. Could someone assign this to me, I could not do it myself. Regards, SRI.
[Bug lto/94311] LTO produces line info entries with invalid line numbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94311 --- Comment #4 from Richard Biener --- (In reply to Mark Wielaard from comment #3) > (In reply to Richard Biener from comment #1) > > Err, but isn't this interpreting the dwarf from 'date'? So doesn't this > > mean that valgrind is "miscompiled" with --enable-lto rather than wrong > > debug? > > The error message isn't very clear, but valgrind also reads its own > code/binary (which is inserted into the process), which is build with LTO. > It is that library that has the wrong line numbers. Which can also be seen > in gdb: > > ./install/bin/valgrind -q date ==48528== warning: Can't handle line > info entry with line number 177277754 greater than 1048575 ==48528== (Nb: > this message is only shown once) ==48528== warning: Can't handle inlined > call info entry with line number 177277750 greater than 1048575 ==48528== > (Nb: this message is only shown once) > > Double check that valgrind debug info reader is correct: > gdb ./.in_place/memcheck-amd64-linux > Reading symbols from ./.in_place/memcheck-amd64-linux... > (gdb) info line guest_amd64_toIR.c:177277754 Line number 177277754 is > out of range for "priv/guest_amd64_toIR.c". > Line 177277754 of "priv/guest_amd64_toIR.c" starts at address > 0x58069001 and ends at 0x58069005 > . > (gdb) > You can also try: > (gdb) disass /s dis_ESC_0F__SSE4 > and you zillions of useless lines. > > If needed, you can ask valgrind to show more info about what it is > doing/reading by doing e.g. > ./install/bin/valgrind -v -v -v -v -d -d -d -d --debug-dump=line date > |& tee d.out So the error must be visible with readelf as well. Can you upload the valgrind binary somewhere (does the issue only reproduce with separate debug and/or dwz?)? It's also a quite odd error unless the whole .debug_line section looks garbled.
[Bug target/94317] gcc/config/arm/arm_mve.h:13907: strange assignment ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94317 Martin Liška changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |srinath.parvathaneni at arm dot co ||m --- Comment #4 from Martin Liška --- Please create a bugzilla account with @gcc.gnu.org domain.
[Bug target/94317] gcc/config/arm/arm_mve.h:13907: strange assignment ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94317 Martin Liška changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug debug/94326] New: g++: error: pack.ii: ‘-fcompare-debug’ failure (length)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94326
Bug ID: 94326
Summary: g++: error: pack.ii: ‘-fcompare-debug’ failure
(length)
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
This one is very old (at least GCC 4.8.0):
$ cat pack.ii
template class A {
const int &m_fn1() { return 0; }
public:
template void m_fn2(_Kt) { m_fn1(); }
};
class B {
A<> _M_t;
public:
template auto m_fn3(_Kt p1) -> decltype(_M_t.m_fn2(p1)) {
_M_t.m_fn2(p1);
}
};
struct C {};
void operator<(C, int) {
B a;
a.m_fn3(C{});
}
$ g++ pack.ii -c -fcompare-debug -std=c++11
pack.ii: In instantiation of ‘const int& A< >::m_fn1()
[with = int]’:
pack.ii:5:45: required from ‘void A< >::m_fn2(_Kt)
[with _Kt = C; = int]’
pack.ii:12:15: required from ‘decltype
(((B*)this)->B::_M_t.A<>::m_fn2<_Kt>(p1)) B::m_fn3(_Kt) [with _Kt = C; decltype
(((B*)this)->B::_M_t.A<>::m_fn2<_Kt>(p1)) = void]’
pack.ii:18:14: required from here
pack.ii:2:31: warning: returning reference to temporary [-Wreturn-local-addr]
2 | const int &m_fn1() { return 0; }
| ^
g++: error: pack.ii: ‘-fcompare-debug’ failure (length)
[Bug debug/94326] g++: error: pack.ii: ‘-fcompare-debug’ failure (length)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94326 Martin Liška changed: What|Removed |Added Priority|P3 |P2
[Bug sanitizer/94325] [UBSAN] "invalid vptr" false positive for virtual inheritance with -fno-sanitize-recover=all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94325 Martin Liška changed: What|Removed |Added Known to fail||10.0, 9.3.0 Known to work||7.4.0 Ever confirmed|0 |1 Keywords||needs-bisection Last reconfirmed||2020-03-25 Status|UNCONFIRMED |NEW --- Comment #1 from Martin Liška --- Confirmed, I'm bisecting that.
[Bug fortran/94327] New: Bind(c) argument attributes are incorrectly set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94327 Bug ID: 94327 Summary: Bind(c) argument attributes are incorrectly set Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gmail dot com Target Milestone: --- Created attachment 48112 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48112&action=edit Fortran code demonstrating problems. Hi all! Argument attributes should match the dummy argument attribute not the effective argument's. Found in both: GNU Fortran (GCC) 9.3.1 20200324 and GNU Fortran (GCC) 10.0.1 20200324 (experimental) Thank you very much. Best regards, José Rui
[Bug c++/94319] gcc/cp/coroutines.cc:2654: strange assignment ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94319 --- Comment #3 from CVS Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:83dfa06cb5cff143113cb7d632c90a40edefade8 commit r10-7376-g83dfa06cb5cff143113cb7d632c90a40edefade8 Author: Iain Sandoe Date: Wed Mar 25 12:04:58 2020 + coroutines: Fix missing dereference (PR94319). Fix a typo. gcc/cp/ChangeLog: 2020-03-25 Iain Sandoe PR c++/94319 * coroutines.cc (captures_temporary): Fix a missing dereference.
[Bug fortran/94327] Bind(c) argument attributes are incorrectly set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94327 --- Comment #1 from José Rui Faustino de Sousa --- Created attachment 48113 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48113&action=edit C code demonstrating problems.
[Bug c++/94319] gcc/cp/coroutines.cc:2654: strange assignment ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94319 Iain Sandoe changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #4 from Iain Sandoe --- so fixed
[Bug fortran/93484] [8/9/10 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1120 since r7-4028-g87c9fca50cbe7ca9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93484 --- Comment #5 from CVS Commits --- The releases/gcc-9 branch has been updated by Mark Eggleston : https://gcc.gnu.org/g:dff885cdc00bbdccb5bb6277e4711093e3bbad1e commit r9-8416-gdff885cdc00bbdccb5bb6277e4711093e3bbad1e Author: Mark Eggleston Date: Wed Mar 25 13:43:23 2020 + fortran: ICE using undeclared symbol in array constructor PR93484 Using undeclared symbol k in an expression in the following array constructor results in an ICE: print *, [real(x(k))] If the call to the intrinsic is not in a constructor a no IMPLICIT type error is reported and the ICE does not occur. Matching on an expression instead of an initialisation express an and not converting a MATCH_ERROR return value into MATCH_NO results in the no IMPLICIT error and no ICE. Note: Steven G. Kargl is the author of the changes except for the test cases. gcc/fortran/ChangeLog: Backport from master 2020-03-25 Mark Eggleston PR fortran/93484 * match.c (gfc_match_type_spec): Replace gfc_match_init_expr with gfc_match_expr. Return m if m is MATCH_NO or MATCH_ERROR. gcc/testsuite Backport from master 2020-03-25 Mark Eggleston PR fortran/93484 * gfortran.dg/pr93484_1.f90: New test. * gfortran.dg/pr93484_2.f90: New test.
[Bug sanitizer/94328] New: Logging of defects to file does not work with Asan and Ubsan combined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94328 Bug ID: 94328 Summary: Logging of defects to file does not work with Asan and Ubsan combined Product: gcc Version: 6.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: gmc at synopsys dot com CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: --- Created attachment 48114 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48114&action=edit Source code for testcase Compile only with the Address Sanitizer, and the resulting exe can log its defects to file via the log_path setting in ASAN_OPTIONS Ditto for only the Undefined Sanitizer, and using the log_path in UBSAN_OPTIONS Combine the 2 though (the only 2 sanitizers that do seem to be allowed to coexist) and the logging does not seem to work correctly : ASAN_OPTIONS seems to be ignored altogether - and when I set UBSAN_OPTIONS the designated log_path is used ONLY for the Address Sanitizer (incl LeakSanitizer) defects - the Undefined Behavior defects go only to stderr, not to the log file. See attached files : "test.cx" is the source, "make all" builds 3 exes, "run" runs each, with log_path being set via the *_OPTIONS settings Thanks for any help in addressing this. Gordon
[Bug sanitizer/94328] Logging of defects to file does not work with Asan and Ubsan combined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94328 --- Comment #1 from Gordon Mc --- Created attachment 48115 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48115&action=edit Makefile
[Bug sanitizer/94328] Logging of defects to file does not work with Asan and Ubsan combined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94328 --- Comment #2 from Gordon Mc --- Created attachment 48116 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48116&action=edit Script to run the testcase
[Bug debug/94281] [8/9/10 Regression] g++: error: hash.cpp: ‘-fcompare-debug’ failure (length) since r8-5241-g8697bf9f46f36168
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94281 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from Jakub Jelinek --- Created attachment 48117 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48117&action=edit gcc10-pr94281.patch Untested fix.
[Bug debug/94329] gcc-9: error: use_only.f90: ‘-fcompare-debug’ failure (length)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94329 Martin Liška changed: What|Removed |Added Priority|P3 |P2 Last reconfirmed||2020-03-25 Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug debug/94329] New: gcc-9: error: use_only.f90: ‘-fcompare-debug’ failure (length)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94329 Bug ID: 94329 Summary: gcc-9: error: use_only.f90: ‘-fcompare-debug’ failure (length) Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: jakub at gcc dot gnu.org Target Milestone: --- Fails since GCC 4.9.0: $ cat use_only.f90 SUBROUTINE r_to_s1b ( s, hinv ) REAL hinv(:,:) DO I=1,3 DO J=1,3 S = hinv(i,j) END DO END DO END $ gcc -Werror -fcompare-debug -O1 -fno-tree-loop-optimize -fwrapv -c use_only.f90 gcc: error: use_only.f90: ‘-fcompare-debug’ failure (length)
[Bug sanitizer/94325] [8/9/10 Regression] UBSAN: "invalid vptr" false positive for virtual inheritance with -fno-sanitize-recover=all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94325 Martin Liška changed: What|Removed |Added CC||jason at gcc dot gnu.org, ||nathan at gcc dot gnu.org Keywords|needs-bisection | Summary|[UBSAN] "invalid vptr" |[8/9/10 Regression] UBSAN: |false positive for virtual |"invalid vptr" false |inheritance with|positive for virtual |-fno-sanitize-recover=all |inheritance with ||-fno-sanitize-recover=all Known to fail||8.4.0 --- Comment #2 from Martin Liška --- Started with my r8-4602-g896f6b3dfa6fb337109f97bed8d74c1e030c965e. Anyway, a help from C++ maintainer is more than welcomed.
[Bug sanitizer/94328] Logging of defects to file does not work with Asan and Ubsan combined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94328 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2020-03-25 Ever confirmed|0 |1 --- Comment #3 from Martin Liška --- Can you please test if clang suffers from the same problem? If so, please create a bug to upstream library: https://github.com/google/sanitizers/issues
[Bug sanitizer/94328] Logging of defects to file does not work with Asan and Ubsan combined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94328 --- Comment #4 from Gordon Mc --- This seems to be specific to GCC - I just tested with clang 7.1.0, and it behaves as I would expect it to (both Asan and Ubsan content went to the UABSAN log file - none went to stderr)
[Bug sanitizer/94328] Logging of defects to file does not work with Asan and Ubsan combined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94328 Gordon Mc changed: What|Removed |Added Known to fail||9.2.0 --- Comment #5 from Gordon Mc --- Also just tested with newer GCC 9.2.0 - behavior there is the same as 6.2 and 7.3, in that the ubsan logging goes to stderr instead of the log file, in the combined sanitizer build.
[Bug sanitizer/94328] Logging of defects to file does not work with Asan and Ubsan combined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94328 --- Comment #6 from Martin Liška --- Ok, let me take a look.
[Bug target/94317] gcc/config/arm/arm_mve.h:13907: strange assignment ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94317 --- Comment #5 from David Binderman --- I am not sure how much testing this code got before it was put into git. Can the author please indicate where the test cases for this code are in the gcc trunk testsuite. I'll give them some exercise. In the somewhat worrying event that there are no test cases, then perhaps it might be wise to add some to aid future developers.
[Bug sanitizer/94328] Logging of defects to file does not work with Asan and Ubsan combined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94328 Martin Liška changed: What|Removed |Added Status|WAITING |NEW --- Comment #7 from Martin Liška --- I can confirm that. It's related to fact that clang links sanitizer library statically, while GCC dynamically. $ ldd a.out | grep san libasan.so.6 => /home/marxin/bin/gcc2/lib64/libasan.so.6 (0x77601000) libubsan.so.1 => /home/marxin/bin/gcc2/lib64/libubsan.so.1 (0x7693e000) And there's some clashing of common_flags()->log_path. @Jakub: I remember we had one similar problem..
[Bug debug/94281] [8/9/10 Regression] g++: error: hash.cpp: ‘-fcompare-debug’ failure (length) since r8-5241-g8697bf9f46f36168
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94281 Jakub Jelinek changed: What|Removed |Added Attachment #48117|0 |1 is obsolete|| --- Comment #4 from Jakub Jelinek --- Created attachment 48118 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48118&action=edit gcc10-pr94281.patch While trying to simulate all the cases that the patch is meant to handle in the debugger (i.e. also outer_stmt being a GIMPLE_BIND and some debug stmts before and/or after that), I've discovered a bug in gimple_seq_last_nondebug_stmt where it would return NULL on a gimple_seq containing the GIMPLE_BIND followed by a DEBUG_BEGIN_STMT, while obviously it should return that GIMPLE_BIND instead. THis updated patch should fix that too.
[Bug c/94253] FAIL: gfortran.dg/bind_c_coms.f90 -O0 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94253 --- Comment #3 from John David Anglin --- Okay, the problem is the test lacks a '-fcommon' option. The default was changed here: 2019-11-20 Wilco Dijkstra PR85678 * common.opt (fcommon): Change init to 1. * doc/invoke.texi (-fcommon): Update documentation. This means almost all the places in the testsuite where we add '-fno-common' are unnecessary...
[Bug target/94317] gcc/config/arm/arm_mve.h:13907: strange assignment ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94317 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #6 from Christophe Lyon --- There are lots of tests under gcc.target/arm/mve, but I think all them just check that the generated code contains the instruction we expect to generate from the intrinsic. (All of them have dg-do compile) In the past I contributed Neon intrinsics executable tests (see gcc.target/aarch64/advsimd-intrinsics) which caught several corner-case bugs. It would probably be good to have similar things for MVE, but that's a huge task.
