[Bug d/90893] ODR violation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90893 --- Comment #3 from ibuclaw at gcc dot gnu.org --- Author: ibuclaw Date: Sat Aug 10 05:25:44 2019 New Revision: 274249 URL: https://gcc.gnu.org/viewcvs?rev=274249=gcc=rev Log: Fix ODR violation in d/runtime.cc gcc/d/ChangeLog: PR d/90893 * runtime.cc (enum libcall_type): Rename to... (enum d_libcall_type): ...this. (get_libcall_type): Use d_libcall_type. (build_libcall_decl): Likewise. Modified: trunk/gcc/d/ChangeLog trunk/gcc/d/runtime.cc
[Bug d/90893] ODR violation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90893 Iain Buclaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Iain Buclaw --- Fixed in r274249.
[Bug c/91398] Possible missed optimization: Can a pointer be passed as hidden pointer in x86-64 System V ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91398
Peter Cordes changed:
What|Removed |Added
CC||peter at cordes dot ca
--- Comment #4 from Peter Cordes ---
EAD neglected to link previous discussion about this in the initial bug report.
https://stackoverflow.com/a/57377890/224132 points out that the SysV ABI
wording is
> If the type has class MEMORY, then **the caller provides space** for the
> return value and passes the address of this storage in %rdi
We can argue semantics, but in my answer on the same question, I argued that
the implication is that that space won't alias any other space. (Because the
return-value object exists in the C abstract machine, so the default assumption
should be that it exists for real in the calling convention.)
Whether it's practical to look for this optimization or not, I'm still curious
about the point that @M.M made about the semantics of restrict
https://stackoverflow.com/questions/57377314/what-prevents-the-usage-of-a-function-argument-as-hidden-pointer/57436765#comment101288442_57403379
Does the callee do_something() reading a global count as happening inside the
block scope of use(Vec3 *restrict out) { ... }? The ISO C standard wording
talks about reaching the end of a block, which hasn't happened even though
`out` is not in scope inside the other function.
If so, then calling use() creates UB when *out = do_something();
executes because it writes the pointed-to memory via a restrict-pointer in the
same block where it reads it from a pointer that's not derived from out.
If so, restrict would make this optimization safe if we can prove that
do_something is "noexcept" and doesn't longjmp.
[Bug fortran/88072] gfortran crashes with an internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88072 --- Comment #2 from kargl at gcc dot gnu.org --- Patch submitted.
[Bug fortran/88072] gfortran crashes with an internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88072 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 CC||kargl at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org
[Bug other/91396] Link error when I use -fvtable-verify=std and -static
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91396 ctice at gcc dot gnu.org changed: What|Removed |Added CC||ctice at gcc dot gnu.org --- Comment #4 from ctice at gcc dot gnu.org --- I would prefer that we make it condition on !static, rather than removing it. I will work on a patch for that.
[Bug c++/91122] alignas gives up evaluating a constant expression in template context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91122 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED --- Comment #1 from Marek Polacek --- Yes. This was fixed by r272217 (trunk) and backported to gcc-9: r272219. It is PR 90736.
[Bug c++/50184] Segmentation fault. Copy Constructor.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50184 Marek Polacek changed: What|Removed |Added Status|NEW |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED --- Comment #6 from Marek Polacek --- I can't reproduce the crash anymore, assuming fixed.
[Bug c++/71369] Compile failure about template function call operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71369 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- It compiles if I use functor.template operator()();
[Bug c++/71790] C++ attributes on expression statements result in compile error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71790 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED --- Comment #1 from Marek Polacek --- G++ 9+ now gives: 71790.C: In function ‘int main(int, char**)’: 71790.C:3:3: warning: attributes at the beginning of statement are ignored [-Wattributes] 3 | [[arbitrary_attribute]] | ^~~
[Bug c++/83798] Enhancement to Wmain warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83798 Marek Polacek changed: What|Removed |Added Status|NEW |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #2 from Marek Polacek --- No feedback, so closing as a dup. *** This bug has been marked as a duplicate of bug 83797 ***
[Bug c++/83797] Inconsistent error messages for main
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83797 --- Comment #6 from Marek Polacek --- *** Bug 83798 has been marked as a duplicate of this bug. ***
[Bug c++/83003] Using the detection idiom and void_t causes an error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83003 Marek Polacek changed: What|Removed |Added Status|NEW |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED --- Comment #4 from Marek Polacek --- This is now rejected: $ xg++ -c 83003.C 83003.C: In substitution of ‘template using Zod_t = typename Zod::type [with T = int]’: 83003.C:15:10: required from here 83003.C:10:26: error: no type named ‘type’ in ‘struct Zod’ 10 | template using Zod_t = typename Zod::type; | ^ So fixed in r270433.
[Bug c++/59681] SVN 197248 adding N3582 support broke Boost.Regex with -std=c++1y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59681 Marek Polacek changed: What|Removed |Added Status|NEW |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED --- Comment #5 from Marek Polacek --- $ xg++ -c 59681.C -std=c++1y # nothing so assuming fixed.
[Bug c++/59570] Warning for semicolon trailing closing curly brackets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59570
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC||mpolacek at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #2 from Marek Polacek ---
GCC already warns with -Wpedantic:
void f()
{
};
59570.C:3:2: warning: extra ‘;’ [-Wpedantic]
3 | };
| ^
[Bug go/86535] FreeBSD/PowerPC64 - Building Go Frontend support for gcc 7.3.0 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535 --- Comment #25 from Ian Lance Taylor --- The code in os_freebsd.go is written for the gc toolchain. You'll need to look at it and see whether it makes sense for gccgo. That said, that call to sysctl does seem to make sense. You'll need to add something like this to os_freebsd.go: //go:noescape //extern sysctl func sysctl(*uint32, uint32, *byte, *uintptr, unsafe.Pointer, uintptr) int32
[Bug c++/91412] New: Unexpectedly correct raw string literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91412
Bug ID: 91412
Summary: Unexpectedly correct raw string literal
Product: gcc
Version: 9.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: alisdairm at me dot com
Target Milestone: ---
Per several existing bug reports (e.g.,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38433) in phase one of
translation, when mapping source character set to basic character set, a '\'
character followed by trailing whitespace until the newline is mapped to a
single '\' character and the newline. Therefore, comments with what the author
believes to be significant trailing whitespace (e.g., to preserve ASCII art in
documentation) is mapped into a line-continuation in a comment, potentially
swallowing code in the following line.
So far, so good.
However, the following program does not follow that same mapping:
#include
int main() {
std::cout << R"(Hello\
World!)";
}
(note that there are 3 space characters after the '\' that may get swallowed by
HTML/bugzilla)
In this case, the line-splice for '\' occurs in phase 2 of translation, and
then gets undone in phase 7. However, this does not undo the source-to-basic
character mapping in phase 1, only the splicing of a '\' immediately followed
by a newline, so there should be no whitespace following 'Hello' in the emitted
output. Yet when the program is compiled and run, three space characters are
indeed present.
Either the source-to-basic-character set mapping needs updating to further
special case trailing whitespace in what will later be determined to be a raw
string literal, or the raw literal should not contain the three spaces.
[Bug go/86535] FreeBSD/PowerPC64 - Building Go Frontend support for gcc 7.3.0 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535 --- Comment #24 from Curtis Hamilton --- Okay, I modified the code and got pass that issue. But have run into another issue that has me stumped. I'm getting the below error: /usr/ports/lang/gcc9/work/gcc-9-20190217/libgo/go/runtime/os_freebsd.go:22:9: error: reference to undefined name 'sysctl' 22 | ret := sysctl([0], 2, (*byte)(unsafe.Pointer()), , nil, 0) | ^
[Bug c/91398] Possible missed optimization: Can a pointer be passed as hidden pointer in x86-64 System V ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91398 --- Comment #3 from ead --- Thank you for the expanations and your time!
[Bug target/48595] score-elf fails to build with --enable-werror-always
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48595 Eric Gallager changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #4 from Eric Gallager --- (In reply to jos...@codesourcery.com from comment #3) > The score port was removed in 2014. All open bugs for it should have been > closed at that time. ah ok; closing this one now then.
[Bug bootstrap/44756] [meta-bug] --enable-werror-always issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44756 Bug 44756 depends on bug 48595, which changed state. Bug 48595 Summary: score-elf fails to build with --enable-werror-always https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48595 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug target/48595] score-elf fails to build with --enable-werror-always
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48595 --- Comment #3 from joseph at codesourcery dot com --- The score port was removed in 2014. All open bugs for it should have been closed at that time.
[Bug middle-end/90693] Missing popcount simplifications
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90693 Wilco changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-08-09 Assignee|unassigned at gcc dot gnu.org |wilco at gcc dot gnu.org Ever confirmed|0 |1
[Bug tree-optimization/90879] fold zero-equality of strcmp between a longer string and a smaller array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90879 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #2 from Martin Sebor --- Patch: https://gcc.gnu.org/ml/gcc-patches/2019-08/msg00640.html
[Bug target/91386] open-iscsi iscsiadm miscompiled by LTO on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91386 Richard Earnshaw changed: What|Removed |Added Known to fail|10.0| --- Comment #21 from Richard Earnshaw --- Fixed on trunk.
[Bug target/91386] open-iscsi iscsiadm miscompiled by LTO on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91386 --- Comment #20 from Richard Earnshaw --- Author: rearnsha Date: Fri Aug 9 16:14:59 2019 New Revision: 274238 URL: https://gcc.gnu.org/viewcvs?rev=274238=gcc=rev Log: [aarch64] PR target/91386 Use copy_rtx to avoid modifying original insns in peep2 pattern PR target/91386 is a situation where a peephole2 pattern substitution is discarded late because the selected instructions contain frame-related notes that we cannot redistribute (because the pattern has more than one insn in the output). Unfortunately, the original insns were being modified during the generation, so after the undo we are left with corrupt RTL. We avoid this by ensuring that the modifications are always made on a copy, so that the original insns are never changed. PR target/91386 * config/aarch64/aarch64.c (aarch64_gen_adjusted_ldpstp): Use copy_rtx to preserve the contents of the original insns. Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/aarch64.c
[Bug debug/91411] New: Extraneous size & location attributes for members in DWARF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91411
Bug ID: 91411
Summary: Extraneous size & location attributes for members in
DWARF
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: tromey at gcc dot gnu.org
Target Milestone: ---
Consider this test case:
struct x
{
int a : 5;
int b : 2;
};
struct x x;
Compile with -g -c and then examine the DWARF.
For x::a, I get:
<2><28>: Abbrev Number: 3 (DW_TAG_member)
<29> DW_AT_name: a
<2b> DW_AT_decl_file : 1
<2c> DW_AT_decl_line : 3
<2d> DW_AT_decl_column : 7
<2e> DW_AT_type: <0x45>
<32> DW_AT_byte_size : 4
<33> DW_AT_bit_size: 5
<34> DW_AT_bit_offset : 27
<35> DW_AT_data_member_location: 0
This has two minor bugs.
First, DWARF 5 section 5.7.6 ("Data Member Entries") says:
The member entry corresponding to a data member that is defined in a structure,
union or class may have either a DW_AT_data_member_location attribute or a
DW_AT_data_bit_offset attribute.
I think that is an exclusive "or", meaning that having both attributes
is incorrect.
Second, the same section says:
If the size of a data member is not the same as the size of the type given for
the
data member, the data member has either a DW_AT_byte_size or a
DW_AT_bit_size attribute whose integer constant value (see Section 2.19 on
page 55) is the amount of storage needed to hold the value of the data member.
Again, to me this indicates that GCC should only emit one of the two
attributes.
[Bug plugins/90924] lto-plugin/lto-plugin.c heap memory corruption due to insufficient sanitization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90924 Nick Clifton changed: What|Removed |Added CC||nickc at gcc dot gnu.org --- Comment #12 from Nick Clifton --- Hi Tanaya, (In reply to Tanaya Patil from comment #11) > May I know if Binutils-2.31 is also affected and requires this fix? Any > heads up will be appreciated. Yes it is. As is 2.32 as well. I have however updated the binutils mainline sources so version 2.33, which is due out soon, will contain the fix. Cheers Nick
[Bug fortran/91410] New: OpenMP error message when compiling OpenACC code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91410 Bug ID: 91410 Summary: OpenMP error message when compiling OpenACC code Product: gcc Version: 9.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: judicael.grasset at stfc dot ac.uk Target Milestone: --- Hello, When compiling the code below, the compiler generates error messages about OpenMP syntax errors, but the code only uses OpenACC pragmas. Also I think the code should compile and work fine. I'm using GCC 9.1 with Power8 CPU main.f: program main type t integer, allocatable :: inside(:) end type t type(t) :: my_t integer :: i allocate(my_t%inside(100)) !$acc enter data copyin(my_t, my_t%inside) !$acc parallel loop present(my_t, my_t%inside) do i=1,100 my_t%inside(i) = i end do !$acc exit data copyout(my_t%inside, my_t) write(*,*)my_t%inside end program main Compiling with: gfortran main.f -Wall -Wextra -fopenacc Error messages: main.f:9:34: 9 | !$acc enter data copyin(my_t, my_t%inside) | 1 Error: Syntax error in OpenMP variable list at (1) main.f:10:38: 10 | !$acc parallel loop present(my_t, my_t%inside) | 1 Error: Syntax error in OpenMP variable list at (1) main.f:14:28: 14 | !$acc exit data copyout(my_t%inside, my_t) |1 Error: Syntax error in OpenMP variable list at (1) $gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/gpfs/paragon/local/HCRI016/dre03/jxg58-dre03/softs/gcc-9.1/libexec/gcc/powerpc64le-unknown-linux-gnu/9.1.0/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none Target: powerpc64le-unknown-linux-gnu Configured with: /gpfs/paragon/local/HCRI016/dre03/jxg58-dre03/gcc-9.1.0/configure --enable-offload-targets=nvptx-none --with-cuda-driver-include=/gpfs/paragon/local/apps/cuda/9.2//include --with-cuda-driver-lib=/gpfs/paragon/local/apps/cuda/9.2//lib64 --disable-bootstrap --disable-multilib --enable-languages=c,c++,fortran,lto --with-cpu-64=power8 --with-tune-64=power8 --prefix=/gpfs/paragon/local/HCRI016/dre03/jxg58-dre03/softs/gcc-9.1 Thread model: posix gcc version 9.1.0 (GCC)
[Bug tree-optimization/90838] Detect table-based ctz implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90838 Wilco changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-08-09 Assignee|unassigned at gcc dot gnu.org |wilco at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #7 from Wilco --- I'll have a look at this, I think it could easily be done in match.pd if we add support for matching array references.
[Bug middle-end/64501] Unreachable catch BB for try blocks that cannot create an exception of specific type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64501 Martin Liška changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|marxin at gcc dot gnu.org |unassigned at gcc dot gnu.org
[Bug ipa/91404] [10 Regression] ICE in gt_ggc_mx_symtab_node at gcc/gtype-desc.c:1302
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91404 Martin Liška changed: What|Removed |Added Keywords||patch --- Comment #5 from Martin Liška --- Patch candidate: https://gcc.gnu.org/ml/gcc-patches/2019-08/msg00628.html
[Bug lto/91393] [10 Regression] lto1: internal compiler error: decompressed stream: Destination buffer is too small
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91393 --- Comment #9 from Martin Liška --- I've got a patch candidate for it.
[Bug lto/88220] LTO ICE with GNU inline and alias's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88220 Martin Liška changed: What|Removed |Added Assignee|hubicka at gcc dot gnu.org |marxin at gcc dot gnu.org --- Comment #4 from Martin Liška --- Good, I've got a patch for it.
[Bug target/91409] Missed optimization on `labels as values` expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91409
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Target||x86_64-*-*, i?86-*-*
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-08-09
Component|tree-optimization |target
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
I think the issue is that & - & is not treated as a constant expression
and thus is expanded as
(insn 8 6 9 2 (set (reg:DI 86)
(label_ref:DI [4 deleted])) "t.i":5:13 -1
(insn_list:REG_LABEL_OPERAND 4 (nil)))
(insn 9 8 10 2 (parallel [
(set (reg:DI 85)
(minus:DI (reg:DI 86)
(label_ref:DI [6 deleted])))
(clobber (reg:CC 17 flags))
]) "t.i":5:13 -1
(insn_list:REG_LABEL_OPERAND 6 (nil)))
that might be ultimatively a target issue (the actual difference is to be
resolved by the assembler of course). Simple testcase:
int foo()
{
L1:
L2:
return & - &
}
[Bug tree-optimization/91409] New: Missed optimization on `labels as values` expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91409 Bug ID: 91409 Summary: Missed optimization on `labels as values` expression Product: gcc Version: 9.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: mserdarsanli at gmail dot com Target Milestone: --- I recently posted about this on SO, but it did not gain much traction: https://stackoverflow.com/questions/55987401/gcc-clang-labels-as-values-computing-offsets-at-runtime The missed optimization is when using `labels as values` feature and computing address difference. The expression `& - &` generates code that does the subtraction on runtime, while it might be possible to compute it on compile time. Godbolt link: https://godbolt.org/z/zZdFYo
[Bug rtl-optimization/91154] [10 Regression] 456.hmmer regression on Haswell caused by r272922
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91154 --- Comment #20 from rguenther at suse dot de --- On Wed, 7 Aug 2019, segher at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91154 > > Segher Boessenkool changed: > >What|Removed |Added > > CC||segher at gcc dot gnu.org > > --- Comment #19 from Segher Boessenkool --- > So how does this cause 12% degradation (20% by some other measurements) > on power9? Pretty much everything is the *opposite* way around for us: > we do have cheap conditional moves, we do prefer integer registers. Might be that speculating the jump (which is very very well predicted) is still a lot faster than the conditional move.
[Bug ipa/91404] [10 Regression] ICE in gt_ggc_mx_symtab_node at gcc/gtype-desc.c:1302
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91404 --- Comment #4 from Martin Liška --- I've got a patch candidate..
[Bug c++/90313] [7/8/9 Regression] Is an assignment elided with gcc7.3 -O2?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90313 rsandifo at gcc dot gnu.org changed: What|Removed |Added Summary|[7/8/9/10 Regression] Is an |[7/8/9 Regression] Is an |assignment elided with |assignment elided with |gcc7.3 -O2? |gcc7.3 -O2? --- Comment #5 from rsandifo at gcc dot gnu.org --- Fixed on trunk so far. Will backport in a week or so if there are no problems.
[Bug c++/90313] [7/8/9/10 Regression] Is an assignment elided with gcc7.3 -O2?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90313 --- Comment #4 from rsandifo at gcc dot gnu.org --- Author: rsandifo Date: Fri Aug 9 09:37:55 2019 New Revision: 274234 URL: https://gcc.gnu.org/viewcvs?rev=274234=gcc=rev Log: Reject tail calls that read from an escaped RESULT_DECL (PR90313) In this PR we have two return paths from a function "map". The common code sets to the value returned by one path, while the other path does: = map (&, ...); We treated this call as tail recursion, losing the copy semantics on the value returned by the recursive call. We'd correctly reject the same thing for variables: local = map (, ...); The problem is that RESULT_DECLs didn't get the same treatment. 2019-08-09 Richard Sandiford gcc/ PR middle-end/90313 * tree-tailcall.c (find_tail_calls): Reject calls that might read from an escaped RESULT_DECL. gcc/testsuite/ PR middle-end/90313 * g++.dg/torture/pr90313.cc: New test. Added: trunk/gcc/testsuite/g++.dg/torture/pr90313.cc Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-tailcall.c
[Bug lto/91393] [10 Regression] lto1: internal compiler error: decompressed stream: Destination buffer is too small
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91393
Martin Liška changed:
What|Removed |Added
Status|WAITING |ASSIGNED
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=88220
--- Comment #8 from Martin Liška ---
Thank you David, now I can see it:
$ cat pr91393.i
void __open_alias(int, ...) __asm__("open");
void __open_alias(int flags, ...) {}
extern __inline __attribute__((__gnu_inline__)) int open() {}
struct {
void *func;
} a = {open};
$ gcc -flto -O pr91393.i
lto1: internal compiler error: decompressed stream: Destination buffer is too
small
0xb3d04b lto_uncompression_zstd
/home/marxin/Programming/gcc/gcc/lto-compress.c:170
0xb3d7ce lto_end_uncompression(lto_compression_stream*, lto_compression)
/home/marxin/Programming/gcc/gcc/lto-compress.c:408
0xb3b66c lto_get_section_data(lto_file_decl_data*, lto_section_type, char
const*, unsigned long*, bool)
/home/marxin/Programming/gcc/gcc/lto-section-in.c:164
0x86ec4c cgraph_node::get_untransformed_body()
/home/marxin/Programming/gcc/gcc/cgraph.c:3578
0x87b36e cgraph_node::expand()
/home/marxin/Programming/gcc/gcc/cgraphunit.c:2164
0x87c3db expand_all_functions
/home/marxin/Programming/gcc/gcc/cgraphunit.c:2332
0x87c3db symbol_table::compile()
/home/marxin/Programming/gcc/gcc/cgraphunit.c:2688
0x7da5f1 lto_main()
/home/marxin/Programming/gcc/gcc/lto/lto.c:644
Looks to me very similar to PR88220.
[Bug plugins/90924] lto-plugin/lto-plugin.c heap memory corruption due to insufficient sanitization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90924 Tanaya Patil changed: What|Removed |Added CC||tanaya_patil at persistent dot com --- Comment #11 from Tanaya Patil --- Hello, May I know if Binutils-2.31 is also affected and requires this fix? Any heads up will be appreciated. Thank you in advance. Best Regards,
[Bug ipa/91404] [10 Regression] ICE in gt_ggc_mx_symtab_node at gcc/gtype-desc.c:1302
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91404 --- Comment #3 from Martin Liška --- Good, now I can reproduce it. I was wrongly building xalancbmk from SPEC2017.
[Bug lto/91393] [10 Regression] lto1: internal compiler error: decompressed stream: Destination buffer is too small
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91393 --- Comment #7 from David Binderman --- Created attachment 46697 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46697=edit preprocessed C source code Preprocessed source code for open.c (aka /tmp/q.i in previous comment)
[Bug lto/91393] [10 Regression] lto1: internal compiler error: decompressed stream: Destination buffer is too small
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91393 --- Comment #6 from David Binderman --- Command line seems to be /home/dcb/gcc/results.274150/bin/gcc -O3 -flto -g -pipe -Wall -Werror=format-se curity -fexceptions -fstack-protector-strong -grecord-gcc-switches -fasynchr onous-unwind-tables -fstack-clash-protection -c -fPIC /tmp/q.i
[Bug lto/91376] g++.dg/lto/pr90990 FAILs with gld 2.32.51
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91376 --- Comment #12 from Martin Liška --- (In reply to r...@cebitec.uni-bielefeld.de from comment #11) > > --- Comment #9 from Martin Liška --- > > (In reply to r...@cebitec.uni-bielefeld.de from comment #8) > [...] > >> I don't see how nm would come into play here. > > > > I thought you see the failure for all tests. Then one could use nm to > > identify > > if LTO plugin is properly loaded. > > Ok, I see. > > >> $ gld.cmd > >> ../../lto-wrapper -fresolution=cp_lto_pr90990_0.res -flinker-output=rel > >> cp_lto_pr90990_0.o > >> /vol/gcc/bin/gld-2.32.51: /var/tmp//ccKkavFd.lto.o: plugin needed to handle > >> lto object > >> [Leaving g++-dg-lto-pr90990-01.exe.lto_wrapper_args] > >> [Leaving /var/tmp//ccKkavFd.lto.o] > > > > Can you please send me the *.o files so that I can investigate them? > > Sure, attached. When using current binutils master I see: $ ~/bin/binutils/bin/nm --version GNU nm (GNU Binutils) 2.32.51.20190809 $ ~/bin/binutils/bin/nm --plugin /dev/shm/objdir/lto-plugin/.libs/liblto_plugin.so.0.0.0 ccKkavFd.lto.o U __gxx_personality_v0 W _ZN1AC1Ev W _ZN1AC2Ev U _ZN1BixEi W _ZN1CclE1A U _ZN1D5m_fn1Ev T _ZN1FC1ER1DRK1A T _ZN1FC2ER1DRK1A $ ~/bin/binutils/bin/nm ccKkavFd.lto.o /home/marxin/bin/binutils/bin/nm: ccKkavFd.lto.o: plugin needed to handle lto object 0001 C __gnu_lto_slim So as seen, if the plugin is loaded, then I can't see the error message. > > >> There's no nm anywhere in sight. Besides, I find it very strange that > >> out of hundreds if not thousends of LTO tests during this bootstrap, > >> only a single one shows this error. If there were a fundamental > >> problem, I'd expect a way larger number here. > > > > That's strange! The test-case is not special to me. > > So one would think. However, the fact that I'm not the only one seeing > this particular failure suggests otherwise... Can you please send me links to the test-suite reports?
[Bug ipa/91404] [10 Regression] ICE in gt_ggc_mx_symtab_node at gcc/gtype-desc.c:1302
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91404 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Perhaps try -fdirectives-only preprocessing?
[Bug lto/91393] [10 Regression] lto1: internal compiler error: decompressed stream: Destination buffer is too small
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91393 Martin Liška changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #5 from Martin Liška --- Where the problematic section is: $ readelf -S -W .libs/open.o There are 27 section headers, starting at offset 0x3048: Section Headers: [Nr] Name TypeAddress OffSize ES Flg Lk Inf Al ... [15] .gnu.lto_open.e5c71689fb58e64f PROGBITS 000954 000a9d 00 E 0 0 1 ... @David: Can you please create a pro-processed file for open.o and the full command line that was used to create the object?
[Bug lto/91376] g++.dg/lto/pr90990 FAILs with gld 2.32.51
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91376 --- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #9 from Martin Liška --- > (In reply to r...@cebitec.uni-bielefeld.de from comment #8) [...] >> I don't see how nm would come into play here. > > I thought you see the failure for all tests. Then one could use nm to identify > if LTO plugin is properly loaded. Ok, I see. >> $ gld.cmd >> ../../lto-wrapper -fresolution=cp_lto_pr90990_0.res -flinker-output=rel >> cp_lto_pr90990_0.o >> /vol/gcc/bin/gld-2.32.51: /var/tmp//ccKkavFd.lto.o: plugin needed to handle >> lto object >> [Leaving g++-dg-lto-pr90990-01.exe.lto_wrapper_args] >> [Leaving /var/tmp//ccKkavFd.lto.o] > > Can you please send me the *.o files so that I can investigate them? Sure, attached. >> There's no nm anywhere in sight. Besides, I find it very strange that >> out of hundreds if not thousends of LTO tests during this bootstrap, >> only a single one shows this error. If there were a fundamental >> problem, I'd expect a way larger number here. > > That's strange! The test-case is not special to me. So one would think. However, the fact that I'm not the only one seeing this particular failure suggests otherwise...
[Bug lto/91393] [10 Regression] lto1: internal compiler error: decompressed stream: Destination buffer is too small
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91393 Martin Liška changed: What|Removed |Added Status|WAITING |ASSIGNED --- Comment #4 from Martin Liška --- I can reproduce that now with: $ gcc .libs/open.o lto1: internal compiler error: decompressed stream: Destination buffer is too small 0xb3d04b lto_uncompression_zstd /home/marxin/Programming/gcc/gcc/lto-compress.c:170 0xb3d7ce lto_end_uncompression(lto_compression_stream*, lto_compression) /home/marxin/Programming/gcc/gcc/lto-compress.c:408 0xb3b66c lto_get_section_data(lto_file_decl_data*, lto_section_type, char const*, unsigned long*, bool) /home/marxin/Programming/gcc/gcc/lto-section-in.c:164 0x86ec4c cgraph_node::get_untransformed_body() /home/marxin/Programming/gcc/gcc/cgraph.c:3578 0x87b36e cgraph_node::expand() /home/marxin/Programming/gcc/gcc/cgraphunit.c:2164 0x87c3db expand_all_functions /home/marxin/Programming/gcc/gcc/cgraphunit.c:2332 0x87c3db symbol_table::compile() /home/marxin/Programming/gcc/gcc/cgraphunit.c:2688 0x7da5f1 lto_main() /home/marxin/Programming/gcc/gcc/lto/lto.c:644
[Bug lto/91376] g++.dg/lto/pr90990 FAILs with gld 2.32.51
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91376 --- Comment #10 from Rainer Orth --- Created attachment 46696 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46696=edit i386-pc-solaris2.11 input objects
[Bug lto/91393] [10 Regression] lto1: internal compiler error: decompressed stream: Destination buffer is too small
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91393 --- Comment #3 from David Binderman --- Created attachment 46695 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46695=edit xz compressed tar file cat bug2.txz | xz -d | tar xvf - should do it. First attachment contains object files [_a-m]* and second has [n-z]*. I used recent trunk compiler. x86_64, if that makes any difference.
[Bug lto/91393] [10 Regression] lto1: internal compiler error: decompressed stream: Destination buffer is too small
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91393 --- Comment #2 from David Binderman --- Created attachment 46694 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46694=edit xz compressed tar file cat bug1.txz | xz -d | tar xvf - should do it.
[Bug target/91408] [10 Regression] ICE in extract_insn, at recog.c:2310 since r273981
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91408 --- Comment #3 from Jakub Jelinek --- Created attachment 46693 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46693=edit gcc10-pr91408.patch Full untested patch.
[Bug target/91408] [10 Regression] ICE in extract_insn, at recog.c:2310 since r273981
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91408 --- Comment #2 from Jakub Jelinek --- Yeah, that is what I'm testing. Both instructions use register_mmxmem_operand which is for mmx with sse actually a register_operand.
[Bug driver/91406] gcc -Q -v lies about what flags are enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91406 --- Comment #1 from Richard Biener --- -Q -v is only a wild guess given whether options are enabled or disabled may depend on the function context. There's really no way to implement it accurately (this -1 trick for "auto-detection" could eventually be handled in some generic way, saying not enabled/disabled but "" or "")
[Bug target/91408] [10 Regression] ICE in extract_insn, at recog.c:2310 since r273981
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91408 --- Comment #1 from Uroš Bizjak --- Just change vector_operand predicates in usadv8qi to register_operand.
[Bug target/91408] [10 Regression] ICE in extract_insn, at recog.c:2310 since r273981
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91408 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED CC||jakub at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
[Bug ipa/91404] [10 Regression] ICE in gt_ggc_mx_symtab_node at gcc/gtype-desc.c:1302
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91404 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.0
[Bug target/91400] __builtin_cpu_supports conjunction is optimized poorly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91400 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Target||x86_64-*-*, i?86-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2019-08-09 Component|tree-optimization |target Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed. The issue is that the target builds a new(!) VAR_DECL for __cpu_mode for _each_(!) invocation of __builtin_cpu_supports so the GIMPLE level optimizers have no chance to CSE the loads. The two VAR_DECLs for this testcase are public static external weak preserve BLK (null):0:0 size unit-size align:32 warn_if_not_align:0> public static external weak preserve BLK (null):0:0 size unit-size align:32 warn_if_not_align:0> so you can see that we even re-build the RECORD_TYPE from scratch... :/
[Bug c/91398] Possible missed optimization: Can a pointer be passed as hidden pointer in x86-64 System V ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91398 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- On GIMPLE we see stores to the RESULT_DECL where accesses to that are not expected to trap, this means on GIMPLE nothing prevents hoisting before EH handling for example. There probably isn't any incentive for a pass to do that but nothing prevents it. So I'd argue such ABI restriction cannot be implemented unless the caller caters for it by using a temporary like we do in the "unwanted unoptimized" code example. I think also that C++ language semantics require that if a function F throws an assignment as part of the function call is not carried out, so it isn't an ABI issue alone. (and for C we support -fexceptions as well). For EH we'd have stmt_could_throw_p () but I don't think we have anything that tells us a callee does not return via longjmp. Thus I don't see how to implement this correctly.
[Bug other/91396] Link error when I use -fvtable-verify=std and -static
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91396
Richard Biener changed:
What|Removed |Added
Component|driver |other
--- Comment #3 from Richard Biener ---
Likely
#define GNU_USER_TARGET_STARTFILE_SPEC \
...
%{fvtable-verify=none:%s; \
fvtable-verify=preinit:vtv_start_preinit.o%s; \
fvtable-verify=std:vtv_start.o%s} " \
should either be conditional on !static or indeed the copy removed from the
static libvtv.
[Bug lto/91393] [10 Regression] lto1: internal compiler error: decompressed stream: Destination buffer is too small
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91393 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.0 Summary|lto1: internal compiler |[10 Regression] lto1: |error: decompressed stream: |internal compiler error: |Destination buffer is too |decompressed stream: |small |Destination buffer is too ||small
[Bug c/91401] schedule + dist_schedule clauses rejected on distribute parallel for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91401 --- Comment #1 from Jakub Jelinek --- Author: jakub Date: Fri Aug 9 07:23:03 2019 New Revision: 274226 URL: https://gcc.gnu.org/viewcvs?rev=274226=gcc=rev Log: PR c/91401 c/ * c-parser.c (c_parser_omp_clause_dist_schedule): Fix up typos in the check_no_duplicate_clause call. Comment it out, instead emit a warning for duplicate dist_schedule clauses. cp/ * parser.c (cp_parser_omp_clause_dist_schedule): Comment out the check_no_duplicate_clause call, instead emit a warning for duplicate dist_schedule clauses. testsuite/ * c-c++-common/gomp/pr91401-1.c: New test. * c-c++-common/gomp/pr91401-2.c: New test. Added: trunk/gcc/testsuite/c-c++-common/gomp/pr91401-1.c trunk/gcc/testsuite/c-c++-common/gomp/pr91401-2.c Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-parser.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog
[Bug target/91408] New: [10 Regression] ICE in extract_insn, at recog.c:2310 since r273981
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91408
Bug ID: 91408
Summary: [10 Regression] ICE in extract_insn, at recog.c:2310
since r273981
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: uros at gcc dot gnu.org
Target Milestone: ---
Starting from the revision, I see ICE for:
$ cat ice.i
long long a;
unsigned char b;
short *c;
int d;
void fn1(long long *p1) {
unsigned char *e = (char *)p1;
int f, g;
d = 0;
for (; d < 8; d++) {
f = b - e[d];
if (f < 0)
f = -f;
g += f;
}
c[0] = g;
}
void fn2() { fn1(); }
$ gcc -O2 -ftree-loop-vectorize -O2 -fno-tree-forwprop ice.i -c
ice.i: In function ‘fn2’:
ice.i:17:1: error: unrecognizable insn:
17 | void fn2() { fn1(); }
| ^~~~
(insn 13 12 14 2 (set (reg:V1DI 99)
(unspec:V1DI [
(reg:V8QI 93)
(mem/c:V8QI (reg/f:DI 97) [0 MEM
[(unsigned char *)]+0 S8 A64])
] UNSPEC_PSADBW)) -1
(nil))
during RTL pass: vregs
ice.i:17:1: internal compiler error: in extract_insn, at recog.c:2310
0x6a4bb7 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/marxin/Programming/gcc/gcc/rtl-error.c:108
0x6a4bd3 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/marxin/Programming/gcc/gcc/rtl-error.c:116
0x6a2d47 extract_insn(rtx_insn*)
/home/marxin/Programming/gcc/gcc/recog.c:2310
0xab4f63 instantiate_virtual_regs_in_insn
/home/marxin/Programming/gcc/gcc/function.c:1606
0xab4f63 instantiate_virtual_regs
/home/marxin/Programming/gcc/gcc/function.c:1976
0xab4f63 execute
/home/marxin/Programming/gcc/gcc/function.c:2025
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug target/91408] [10 Regression] ICE in extract_insn, at recog.c:2310 since r273981
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91408 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-08-09 Known to work||9.1.0 Target Milestone|--- |10.0 Ever confirmed|0 |1 Known to fail||10.0
[Bug c++/91407] New: Wnon-virtual-dtor should't fire for classes with operator delete=delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91407
Bug ID: 91407
Summary: Wnon-virtual-dtor should't fire for classes with
operator delete=delete
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: asorenji at gmail dot com
Target Milestone: ---
Okay, attempt of delete polymorphic class without virtual destructor, lead to
UB. But, I want trivially destructible class with virtual functions. So, I just
mark operator delete as delete. No delete expression - no problem. But gcc
still show me a warning.
gcc (Debian 8.3.0-6) 8.3.0
Command line:
gcc main.cpp -Wnon-virtual-dtor
Source:
class Test
{
public:
virtual void foo(){}
void operator delete(void*)=delete;
};
int main()
{
return 0;
}
Yes, yes, although "delete pointer" don't work, "::delete pointer" still
worked. But it's just a shoot in the foot.
[Bug tree-optimization/91403] GCC fails with ICE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91403 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-08-09 Version|tree-ssa|10.0 Ever confirmed|0 |1 --- Comment #3 from Richard Biener --- Yeah, I know. I tried to fix this for PR91178 but needed to revert. The vectorizer issue uncovers places where we run into compile-time issues with these large increment chains and I've fixed some but in the end a vectorizer fix is required. My mind tells me that at some point we limited the group gap but I didn't find records of that. In the end it should be "easy" to avoid the bad codegen, but vectorizable_load is kind-of a mess and hairy to adjust ... I'll give it another try.
[Bug ipa/91404] [10 Regression] internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91404 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-08-09 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Ok, I'm trying to reproduce that.
[Bug lto/91376] g++.dg/lto/pr90990 FAILs with gld 2.32.51
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91376
--- Comment #9 from Martin Liška ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #8)
> > --- Comment #7 from Martin Liška ---
> > (In reply to Martin Liška from comment #6)
> >> Good, then let me take a look.
> >
> > So I've just tested current master of binutils and I can see:
> >
> > marxin@marxinbox:/tmp> gcc --version
> > gcc (GCC) 10.0.0 20190806 (experimental)
> > Copyright (C) 2019 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.
> >
> > marxin@marxinbox:/tmp> gcc -c -flto main.c
> >
> > $ nm main.o
> > nm: main.o: plugin needed to handle lto object
> > 0001 C __gnu_lto_slim
> >
> > The issue here is that the installed nm can't load plugin from bfd-plugins:
> >
> > $ strace -f -s512 nm main.o 2>&1 | grep plugin
> > openat(AT_FDCWD, "/home/marxin/bin/binutils/bin/../bin/../lib/bfd-plugins",
> > O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 4
> > stat("/home/marxin/bin/binutils/bin/../bin/../lib/bfd-plugins/..",
> > {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> > stat("/home/marxin/bin/binutils/bin/../bin/../lib/bfd-plugins/.",
> > {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> > write(2, "main.o: plugin needed to handle lto object", 42main.o: plugin
> > needed
> > to handle lto object) = 42
> >
> > $ nm --plugin /dev/shm/objdir/lto-plugin/.libs/liblto_plugin.so.0.0.0 main.o
> > T main
> >
> > So the question is if you have a LTO plugin accessible for the built gold or
> > nm?
>
> I don't see how nm would come into play here.
I thought you see the failure for all tests. Then one could use nm to identify
if LTO plugin is properly loaded.
> For one, I've only
> installed gas and gld from binutils trunk under non-standard names
> (gas-2.32.51 and gld-2.32.51) and use them via --with-as and --with-ld.
>
> The failing testcases boils down to (run in gcc/testsuite/g++):
>
> #!/bin/sh
>
> COLLECT_GCC=../../xg++ \
> COLLECT_GCC_OPTIONS= \
> COLLECT_LTO_WRAPPER=../../lto-wrapper \
> COMPILER_PATH=../.. \
> \
> /vol/gcc/bin/gld-2.32.51 \
> -plugin ../../liblto_plugin.so \
> -plugin-opt=../../lto-wrapper \
> -plugin-opt=-fresolution=cp_lto_pr90990_0.res \
> -plugin-opt=-v \
> -plugin-opt=-save-temps \
> -o g++-dg-lto-pr90990-01.exe -r cp_lto_pr90990_0.o
>
> $ gld.cmd
> ../../lto-wrapper -fresolution=cp_lto_pr90990_0.res -flinker-output=rel
> cp_lto_pr90990_0.o
> /vol/gcc/bin/gld-2.32.51: /var/tmp//ccKkavFd.lto.o: plugin needed to handle
> lto object
> [Leaving g++-dg-lto-pr90990-01.exe.lto_wrapper_args]
> [Leaving /var/tmp//ccKkavFd.lto.o]
Can you please send me the *.o files so that I can investigate them?
>
> When I run this under truss (Solaris equivalent of strace), I find just
> the following calls to execve:
>
> 12815:execve("../../lto-wrapper", 0xFEFFD6F4, 0xFEFFD844) argc = 2
> 12815: argv: ../../lto-wrapper
> 12815: @g++-dg-lto-pr90990-01.exe.lto_wrapper_args
>
> 12817:execve("../../xg++", 0xFEFFD5A4, 0xFEFFD990) argc = 2
> 12817: argv: ../../xg++ @/var/tmp//ccxh7UCb
>
> 12819:execve("../../lto1", 0x08189FD0, 0x08187784) argc = 19
> 12819: argv: ../../lto1 -quiet -dumpbase cp_lto_pr90990_0.o
> 12819: -mtune=generic -march=pentium4 -auxbase-strip
> 12819: /var/tmp//ccKkavFd.lto.o -O0 -fno-openmp -fno-openacc
> 12819: -fno-pie -fno-diagnostics-show-caret
> 12819: -fno-diagnostics-show-line-numbers
> 12819: -fresolution=cp_lto_pr90990_0.res -flinker-output=rel
> 12819: @/var/tmp//ccsvXE.b -o /var/tmp//ccM632hc.s
>
> 12821:execve("/vol/gcc/bin/gas-2.32.51", 0x08189FD0, 0x08187784)
> argc = 7
> 12821: argv: /vol/gcc/bin/gas-2.32.51 -Qy -s --32 -o
> 12821: /var/tmp//ccKkavFd.lto.o /var/tmp//ccM632hc.s
>
> There's no nm anywhere in sight. Besides, I find it very strange that
> out of hundreds if not thousends of LTO tests during this bootstrap,
> only a single one shows this error. If there were a fundamental
> problem, I'd expect a way larger number here.
That's strange! The test-case is not special to me.
[Bug c++/91377] [8/9/10 Regression] ICE with non-static block scope constexpr, captured in lambda, used as template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91377 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #3 from Martin Liška --- Created attachment 46692 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46692=edit Reduced test-case
