[committed] libstdc++: Move unix.org reference to https
commit f58541b2a42002c23267ce872b63d71e275e545d Author: Gerald Pfeifer Date: Mon May 3 02:00:07 2021 +0200 libstdc++: Move unix.org reference to https libstdc++-v3/ChangeLog: * doc/xml/manual/ctype.xml: Move unix.org reference to https. * doc/html/manual/facets.html: Regenerate. diff --git a/libstdc++-v3/doc/html/manual/facets.html b/libstdc++-v3/doc/html/manual/facets.html index 828b52f49bb..90f2e26e990 100644 --- a/libstdc++-v3/doc/html/manual/facets.html +++ b/libstdc++-v3/doc/html/manual/facets.html @@ -62,7 +62,7 @@ characters. . Copyright ?? 1998 ISO. ISO/IEC 9899:1999 Programming languages - C . Copyright ?? 1999 ISO. - http://www.unix.org/version3/ieee_std.html; target="_top"> + https://www.unix.org/version3/ieee_std.html; target="_top"> The Open Group Base Specifications, Issue 6 (IEEE Std. 1003.1-2004) . Copyright ?? 1999 @@ -748,4 +748,4 @@ java.util.Locale, java.util.ResourceBundle ??Home??Chapter??9.?? Containers - \ No newline at end of file + diff --git a/libstdc++-v3/doc/xml/manual/ctype.xml b/libstdc++-v3/doc/xml/manual/ctype.xml index 55930c1751f..a1c580f94ad 100644 --- a/libstdc++-v3/doc/xml/manual/ctype.xml +++ b/libstdc++-v3/doc/xml/manual/ctype.xml @@ -168,7 +168,7 @@ characters. http://www.w3.org/1999/xlink; - xlink:href="http://www.unix.org/version3/ieee_std.html;> + xlink:href="https://www.unix.org/version3/ieee_std.html;> The Open Group Base Specifications, Issue 6 (IEEE Std. 1003.1-2004)
[committed] wwwdocs: Remove link to Intel AVX-512{VL, BW, DQ} Programming Reference
Links like this to intel.com keep breaking or redirecting to generic
pages, so simply remove this now.
Pushed.
Gerald
---
htdocs/git.html | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/htdocs/git.html b/htdocs/git.html
index 50fdd56a..8edde126 100644
--- a/htdocs/git.html
+++ b/htdocs/git.html
@@ -326,8 +326,7 @@ in Git.
avx-512vlbwdq
The goal of this branch is to implement the Intel AVX-512{VL,BW,DQ}
- Programming Reference
- (https://software.intel.com/sites/default/files/managed/39/c5/325462-sdm-vol-1-2abcd-3abcd.pdf;>link).
+ Programming Reference.
The branch is maintained by Yukhin Kirill mailto:kirill.yuk...@intel.com;>kirill.yuk...@intel.com.
Patches should be marked with the tag [AVX512] wwwdocs: in the
subject
--
2.31.1
[committed] wwwdocs: Update link to Fedora rebuild gcc-4.3.0
This moved from www.redhat.com to listman.redhat.com. Pushed. Gerald --- htdocs/gcc-4.3/porting_to.html | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/htdocs/gcc-4.3/porting_to.html b/htdocs/gcc-4.3/porting_to.html index 5777519a..630290ce 100644 --- a/htdocs/gcc-4.3/porting_to.html +++ b/htdocs/gcc-4.3/porting_to.html @@ -526,7 +526,9 @@ svn diff -r529854:529855 http://svn.apache.org/repos/asf/ant/core/trunk/src/main Links -Jakub Jelinek, https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00128.html;>Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220 +Jakub Jelinek, +https://listman.redhat.com/archives/fedora-devel-list/2008-January/msg00128.html;> +Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220 -- 2.31.1
gcc-12-20210502 is now available
Snapshot gcc-12-20210502 is now available on https://gcc.gnu.org/pub/gcc/snapshots/12-20210502/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 12 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch master revision 92f59e47f5a468b96b12b15233a6729904b1a1ee You'll find: gcc-12-20210502.tar.xz Complete GCC SHA256=9c420a8c79049796d6bc600bdae8a3bcc06793cac1413fb832b6219dec80356b SHA1=40dc29baaee85b669f8ed029a41d8ea1f5a41441 Diffs from 12-20210426 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-12 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
[Bug go/100389] New: "invalid type conversion" error for string-based error type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100389
Bug ID: 100389
Summary: "invalid type conversion" error for string-based error
type
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: ben.hutchings at essensium dot com
CC: cmang at google dot com
Target Milestone: ---
Given the following source files:
$ cat main.go
package main
import (
"foo"
"os"
)
func main() {
if !foo.IsInUse(foo.Remove()) {
os.Exit(1)
}
}
$ cat src/foo/foo.go
package foo
const (
errVolumeInUse conflictError = "volume is in use"
)
type conflictError string
func (e conflictError) Error() string {
return string(e)
}
func IsInUse(err error) bool {
return isErr(err, errVolumeInUse)
}
func isErr(err error, expected error) bool {
return err == expected
}
func Remove() error {
return errVolumeInUse
}
gccgo (from Debian package version 10.2.1-6) reports:
$ GOPATH=$PWD go build .
# _/home/bwh/tmp/gotest
./src/foo/foo.go:22: error: invalid type conversion (type has no methods)
./src/foo/foo.go:14: error: invalid type conversion (type has no methods)
Whereas gc (from Debian package version 1.15.9-1) builds these successfully.
[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729
--- Comment #57 from abebeos at lazaridis dot com ---
Just fascinating!
Bountysource violated its own processes, and payed out the bounty without
waiting for the votes.
See, even without a dispute, there is a 2 week voting period ("The bounty will
be paid out if all backers accept your claim or if no backers reject your claim
by May 15, 2021 4:41 PM (GMT)")
But it looks like some "manual intervention" just skipped the process, without
waiting for the votes of the main backers:
Microchip $5,000
nseidle $500
per1234 $300
And i was mostly interested in what those 3 had to say.
GCC, Bountysource, just be aware that there is one word for this:
Cheating.
Please fix this, if its just one of the bountysource-bugs.
The voice of the major backers needs to count.
[Bug go/100388] New: import seems to define identifiers in package block not file block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100388
Bug ID: 100388
Summary: import seems to define identifiers in package block
not file block
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: ben.hutchings at essensium dot com
CC: cmang at google dot com
Target Milestone: ---
Given a package made of these two files:
$ cat a.go
package main
import (
copy "golang.org/x/sys/unix"
)
func Getuid() int {
return copy.Getuid()
}
$ cat b.go
package main
func main() {
foo := make([]string, 1)
bar := make([]string, 1)
copy(bar, foo)
}
gccgo seems to treat the imported "copy" as defined at package scope, shadowing
the global "copy":
$ go build .
# _/home/bwh/tmp/gotest
./b.go:6:2: error: ‘copy’ defined as both imported name and global name
6 | copy(bar, foo)
| ^
./a.go:4:2: note: ‘copy’ imported here
4 | copy "golang.org/x/sys/unix"
| ^
I'm seeing this with the Debian package of gccgo, version 10.2.1-6.
gc (again from a Debian package, version 1.15.9-1) does not report an error.
The Go Programming Language spec says that import declares names in the "file
block" which seems to mean it should not affect any other source file. But I am
a Go novice, so I might be misinterpreting this.
[Bug testsuite/100169] Test gcc.dg/sms-10.c fails on power10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100169 --- Comment #1 from Segher Boessenkool --- The SMS pass is notorious for slight changes making its cost model decide too do things the other way around. Is that what is happening here? Was SMS' decision a good decision (or at least reasonable)? If so, we just should disable the test for p10.
[Bug c++/100386] Not all constant brace-init-lists receive symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100386 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Local labels in assembly code does not get exported to object files. There is no reason for all constants/labels to have an entry in the object file. Yes there is a consistency issue here but it depends on which pass which makes the constant object.
[Bug tree-optimization/100382] [12 Regression] go.test/test/fixedbugs/issue16095.go hang since r12-248
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100382 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2021-05-02 --- Comment #1 from Jakub Jelinek --- Created attachment 50736 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50736=edit gcc12-pr100382.patch So perhaps this untested fix?
[Bug libstdc++/100387] ranges::minmax compares moved-out value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100387 --- Comment #1 from 康桓瑋 --- Also, in std::shift_right: std::move(std::move(__first), std::move(__dest_head), std::move(__result)); return __result; we return the moved-out __result.
[Bug fortran/99819] [9/10/11/12 Regression] ICE in gfc_defer_symbol_init, at fortran/trans-decl.c:841
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99819 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #2 from Paul Thomas --- Created attachment 50735 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50735=edit Experimenta "fix" for the PR The problem lies in class.c(gfc_build_class_symbol). The attachment contains two different experiments to test the hypothesis that the array_spec for 'y' is applied to the _data field of the derived type, which is then promoted to the main namespace. Subsequently, it is picked up in the declaration of 'z', which cause the problem. The first chunk, used by itself, turns the array_spec into a deferred array. The extent information is lost but the testcase now compiles and runs (incorrectly!). The second chunk, again by itself, puts the derived type representation in the function namespace. This now runs the testcase correctly and does the right thing. However, it can only encompass one such dummy. I'm onto it:-) Paul program p type t integer :: i end type class(t), allocatable :: dum1(:), dum2(:) allocate (t :: dum1(3), dum2(10)) dum2%i = [1,2,3,4,5,6,7,8,9,10] print *, f(dum1, dum2), g(dum1) contains function g(z) class(*) :: z(:) type(t) :: u(size(z)) g = 0 end function f(x, y) class(t) :: x(:) class(*) :: y(size(x)) print *, size(y) select type (y) type is (t) f = 1 if (any (y%i .ne. [1,2,3])) print *, size(y%i) class default f = 0 end select end end
[Bug libstdc++/100387] New: ranges::minmax compares moved-out value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100387 Bug ID: 100387 Summary: ranges::minmax compares moved-out value Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- In ranges_algo.h#L3301: if (std::__invoke(__comp, std::__invoke(__proj, __tmp), std::__invoke(__proj, __result.min))) __result.min = std::move(__tmp); if (!(bool)std::__invoke(__comp, std::__invoke(__proj, __tmp), std::__invoke(__proj, __result.max))) __result.max = std::move(__tmp); we compare the moved-out __tmp in the second if statement. test: https://godbolt.org/z/W6WTG6sdG
[Bug c++/100386] New: Not all constant brace-init-lists receive symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100386
Bug ID: 100386
Summary: Not all constant brace-init-lists receive symbols
Product: gcc
Version: 10.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jengelh at inai dot de
Target Milestone: ---
Input:
```
#include
#include
void f(int x) { printf("%d", x); }
void foo(const std::initializer_list ) { for (auto y : x) f(y); }
int main()
{
for (auto x : {1,2,3,4,5,6,7,8,9,10,11,12,13,14,15})
f(x);
foo({
1,2,3,4,5,6,7,8,9,2,1,3,4,5,6,7,8,9,3,2,1,4,5,6,7,8,9,5,4,3,
1,2,3,4,5,6,7,8,9,2,1,3,4,5,6,7,8,9,3,2,1,4,5,6,7,8,9,5,4,3,
1,2,3,4,5,6,7,8,9,2,1,3,4,5,6,7,8,9,3,2,1,4,5,6,7,8,9,5,4,3,
});
}
```
Build and objdump:
```
$ gcc -v -O2 -g x.cpp
Target: x86_64-suse-linux
…
gcc version 10.3.0 (SUSE Linux/Tumbleweed)
$ objdump -d a.out
…
00401040 :
401040: 53 push rbx
401041: be 01 00 00 00 movesi,0x1
401046: bb a0 21 40 00 movebx,0x4021a0
40104b: 48 81 ec 80 01 00 00subrsp,0x180
401052: eb 06 jmp40105a
401054: 0f 1f 40 00 nopDWORD PTR [rax+0x0]
401058: 8b 33 movesi,DWORD PTR [rbx]
40105a: bf 04 20 40 00 movedi,0x402004
40105f: 31 c0 xoreax,eax
401061: 48 83 c3 04 addrbx,0x4
401065: e8 c6 ff ff ff call 401030
40106a: 48 81 fb dc 21 40 00cmprbx,0x4021dc
401071: 75 e5 jne401058
401073: 48 8d 44 24 10 learax,[rsp+0x10]
401078: 48 8d 7c 24 10 leardi,[rsp+0x10]
40107d: be 20 20 40 00 movesi,0x402020
401082: b9 2d 00 00 00 movecx,0x2d
401087: f3 48 a5rep movs QWORD PTR es:[rdi],QWORD PTR
ds:[rsi]
…
```
Observed output:
```
$ nm a.out | sort
…
00402000 R _IO_stdin_used
004021a0 r C.0.0
…
```
Expected output:
```
$ nm a.out
…
00402000 R _IO_stdin_used
00402020 r C.something.something
004021a0 r C.0.0
…
```
[Bug c++/100385] New: overload resolution for function call expression on object selects `operator auto` conversion candidate.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100385
Bug ID: 100385
Summary: overload resolution for function call expression on
object selects `operator auto` conversion candidate.
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mizvekov at gmail dot com
Target Milestone: ---
The following program compiles successfully, but should be rejected:
```
template struct constant {
constexpr operator auto () const noexcept { return V; }
};
void myfree(void*);
void test() {
constant{}(nullptr);
}
```
According to `[over.call.object]/2`:
```
..., and where conversion-type-id denotes the type “pointer to function of
(P1,…,Pn) returning R”, or the type “reference to pointer to function of
(P1,…,Pn) returning R”, or the type “reference to function of (P1,…,Pn)
returning R”, a surrogate call function with the unique name call-function and
having the form
R call-function ( conversion-type-id F, P1 a1, …, Pn an) { return F (a1, …,
an); }
is also considered as a candidate function.
...
```
But here `auto` is neither pointer, reference, nor reference to pointer to
function. So I think the GCC behavior here is non-conformant, though it does
look useful to accept it.
Here is a workspace showing that Clang and MSVC reject this:
https://godbolt.org/z/aT6TrPz1h
The above workspace also is a double whammy in that it shows that libstdc++'s
unique_ptr implementation somehow hides this problem from Clang.
[Bug libgomp/100352] [11/12 Regression] libgomp.fortran/async_io_1.f90 -O0 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100352 --- Comment #7 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:a13a50047ef1814a7bda2392f728bf28f81b17ce commit r12-344-ga13a50047ef1814a7bda2392f728bf28f81b17ce Author: Tobias Burnus Date: Sun May 2 18:16:17 2021 +0200 Fortran: Async I/O - avoid unlocked unlocking [PR100352] Follow up to PR100352, which moved unit unlocking to st_*_done_worker to avoid lock order reversal; however, as async_io uses a different lock, the (unlocked locked) unit lock shall not be unlocked there. libgfortran/ChangeLog: PR libgomp/100352 * io/transfer.c (st_read_done_worker, st_write_done_worker): Add new arg whether to unlock unit. (st_read_done, st_write_done): Call it with true. * io/async.c (async_io): Call it with false. * io/io.h (st_write_done_worker, st_read_done_worker): Update prototype.
[Bug c++/100384] Compiling in c++17 mode breaks compilation of functions named visit()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100384 --- Comment #1 from Albert Astals Cid --- Created attachment 50734 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50734=edit error log
[Bug c++/100384] New: Compiling in c++17 mode breaks compilation of functions named visit()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100384 Bug ID: 100384 Summary: Compiling in c++17 mode breaks compilation of functions named visit() Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: aacid at kde dot org Target Milestone: --- Created attachment 50733 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50733=edit main.cpp The attached code fails to compile with g++ --std=c++17 main.cpp I've tried with gcc 11.1 too and it fails too. To me it seems a bug in the implementation in which std::visit is leaking into the non std:: namespace, but maybe it's a bug in C++ specification?
[Bug target/100152] [10/11/12 Regression] used caller-saved register not preserved across a call.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152
--- Comment #45 from Iain Sandoe ---
the i386 backend code already sets :
TARGET_CALL_FUSAGE_CONTAINS_NON_CALLEE_CLOBBERS to true unconditionally.
So, it seems that it might be necessary to find some way to adjust
CALL_INSN_FUNCTION_USAGE.
because...
===
Simply setting an override to PIC or (PIC && !PIE) results
* in a large number of testsuite regressions
* and doesn't seem to match the behaviour of the system compiler (a.k.a.
clang).
Noting that x86_64 Darwin is _always_ PIC.
clang does not discriminate between PIC and PIE code in the compiler, the
driver maps both to -mrelocation-model pic 2 (and that's the default anyway).
The static linker does act upon PIE - to the extent that it defaults to PIE for
executables, although that can be overridden with -Wl,-no_pie (which we use to
allow PCH to work in GCC).
it seems [from looking at clang's output ] that we want this to be the
behaviour in a dylib:
.. foo () { ... }
.. bar () { ... foo () ... }
When we have a sufficient optimisation level to allow inlining - then we want
foo to be inlined into bar (for the default case of PIC).
When the static linker acts - it will make both foo and bar available publicly
- and an external caller to those will use lazy symbol resolution.
If foo is not suitable for inlining then the call to it from bar() will be
indirected through the lazy symbol binder if the dylib is built with
-flat_namespace, (which was the case in the gambit scenario here, I think).
I suppose the argument is that if we call a specific implementation of bar(),
we expect the complete implementation (including *that* library's version of
foo() and not some mixture of that and some interposed one) and therefore it's
logical to allow the inlining.
If one wants to guarantee that foo can be interposed [including in any case
like bar()], then either one needs to build -fno-inline or mark foo as
__attribute__((__noinline__)) [or weak]
TBH this seems quite fragile to me - but OTOH people interposing libraries
better know what they are doing - going to ask the Apple ABI folks to confirm
my hypothesis.
=
Anyway .. we can't fix the problem quickly by applying PIC && !PIE - because
that is too big a hammer for Darwin.
I think what will be needed is to append r10 and r11 to the Call clobbered
registers .. but I've not figured out exactly where to do this yet. [ setting
CALL_INSN_FUNCTION_USAGE somewhere, or so ]
It doesn't seem that i386 has this problem (but needs double-checking).
[Bug bootstrap/100373] [12 Regression] Darwin, Compare-debug fail after r12-248-gb58dc0b803057
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100373 --- Comment #1 from Iain Sandoe --- this happens with mpfr-4.x sources and not with mpfr-3.1.6.
[Bug debug/100383] New: cfi sections directive detection fails with binutils 2.36
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100383 Bug ID: 100383 Summary: cfi sections directive detection fails with binutils 2.36 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: ssbssa at yahoo dot de Target Milestone: --- Since binutils 2.36 [1], the objdump output [2] of the cfi sections directive detection command (objdump -j .debug_frame -r conftest.o) changed from: conftest.o: file format pe-x86-64 RELOCATION RECORDS FOR [.debug_frame]: OFFSET TYPE VALUE 001c secrel32 .debug_frame 0020 R_X86_64_64 .text to: conftest.o: file format pe-x86-64 RELOCATION RECORDS FOR [.debug_frame]: OFFSET TYPE VALUE 001c IMAGE_REL_AMD64_SECREL .debug_frame 0020 IMAGE_REL_AMD64_ADDR64 .text So because it's now uppercase SECREL, the `grep secrel` fails. I haven't finished my build yet, but it should work like this: --- a/gcc/configure.ac +++ b/gcc/configure.ac @@ -3115,7 +3115,7 @@ gcc_GAS_CHECK_FEATURE([cfi sections directive], gcc_cv_as_cfi_sections_directive=no if test "x$gcc_cv_objdump" != x; then if $gcc_cv_objdump -j .debug_frame -r conftest.o 2>/dev/null | \ - grep secrel > /dev/null; then + grep -i secrel > /dev/null; then gcc_cv_as_cfi_sections_directive=yes fi fi [1] https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=ec6653d824fef41298fdb384ba74bcbc7be0dc22 [2] https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/configure.ac;h=84dceb8074ab4615316e09f1f339ed93eca6d6e9;hb=refs/heads/releases/gcc-10#l3117
[Bug tree-optimization/100382] [12 Regression] go.test/test/fixedbugs/issue16095.go hang since r12-248
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100382 Jakub Jelinek changed: What|Removed |Added CC||ian at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Target Milestone|--- |12.0
[Bug tree-optimization/100382] New: [12 Regression] go.test/test/fixedbugs/issue16095.go hang since r12-248
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100382 Bug ID: 100382 Summary: [12 Regression] go.test/test/fixedbugs/issue16095.go hang since r12-248 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: jakub at gcc dot gnu.org Target Milestone: --- Since r12-248-gb58dc0b803057c0e6032e0d9bd92cd834f72c75c the go.test/test/fixedbugs/issue16095.go test hangs. To reproduce e.g.: ../configure --enable-languages=c,c++,go --disable-bootstrap make -j32 cd gcc make -j32 check-go The first difference (good to bad) is in the dse2 dump: @@ -889,7 +889,6 @@ void main.main () uint8[20] * _69; uint32 _72; uint64 GOTMP.131_73; - int _74; bool GOTMP.132_75; bool GOTMP.132_77; int GOTMP.16_155; @@ -1190,7 +1189,6 @@ void main.main () goto ; [100.00%] [count: 0]: - _74 = MEM[(int *)0B]; goto ; [100.00%] [count: 0]: @@ -1217,7 +1215,7 @@ void main.main () goto ; [100.00%] [count: 0]: - # x_76 = PHI + # x_76 = PHI : # DEBUG x => x_76 runtime.checkdefer ();
[Bug c++/100381] New: new static_assert((std::__is_complete_or_unbounded(...)) failure from g++ 11.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100381
Bug ID: 100381
Summary: new
static_assert((std::__is_complete_or_unbounded(...))
failure from g++ 11.1.0
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gilles.gouaillardet at gmail dot com
Target Milestone: ---
Created attachment 50732
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50732=edit
a reproducer that fails from g++ 11.1.0
g++ 11.1.0 is no more able to compile GROMACS, as reported at
https://gitlab.com/gromacs/gromacs/-/issues/4039
I trimmed the offending code into the attached and self-contained reproducer,
that fails to build with the following error:
$ g++ -c reproducer.cpp
In file included from
/home/users/gilles/local/gcc-11.1.0/include/c++/11.1.0/bits/move.h:57,
from
/home/users/gilles/local/gcc-11.1.0/include/c++/11.1.0/bits/stl_function.h:60,
from
/home/users/gilles/local/gcc-11.1.0/include/c++/11.1.0/functional:49,
from reproducer.cpp:1:
/home/users/gilles/local/gcc-11.1.0/include/c++/11.1.0/type_traits: In
instantiation of 'struct std::is_invocable_r&, IndexGroupsAndNames>':
/home/users/gilles/local/gcc-11.1.0/include/c++/11.1.0/type_traits:3011:46:
required from 'constexpr const bool std::is_invocable_r_v&, IndexGroupsAndNames>'
/home/users/gilles/local/gcc-11.1.0/include/c++/11.1.0/bits/invoke.h:103:27:
required by substitution of 'template constexpr std::enable_if_t,
_Res> std::__invoke_r(_Callable&&, _Args&& ...) [with _Res = void; _Callable =
{anonymous}::DensityFitting::subscribeToPreProcessingNotifications(MdModulesNotifier*)::&; _Args = {IndexGroupsAndNames}]'
/home/users/gilles/local/gcc-11.1.0/include/c++/11.1.0/bits/std_function.h:291:30:
required from 'static _Res std::_Function_handler<_Res(_ArgTypes ...),
_Functor>::_M_invoke(const std::_Any_data&, _ArgTypes&& ...) [with _Res = void;
_Functor =
{anonymous}::DensityFitting::subscribeToPreProcessingNotifications(MdModulesNotifier*)::; _ArgTypes = {IndexGroupsAndNames}]'
/home/users/gilles/local/gcc-11.1.0/include/c++/11.1.0/bits/std_function.h:422:21:
required from 'std::function<_Res(_ArgTypes ...)>::function(_Functor) [with
_Functor =
{anonymous}::DensityFitting::subscribeToPreProcessingNotifications(MdModulesNotifier*)::; = void;
= void; _Res = void; _ArgTypes =
{IndexGroupsAndNames}]'
reproducer.cpp:55:56: required from here
/home/users/gilles/local/gcc-11.1.0/include/c++/11.1.0/type_traits:2954:7:
error: static assertion failed: each argument type must be a complete class or
an unbounded array
2954 | static_assert((std::__is_complete_or_unbounded(
| ^
/home/users/gilles/local/gcc-11.1.0/include/c++/11.1.0/type_traits:2954:7:
note:
'std::__is_complete_or_unbounded
>((std::__type_identity{},
std::__type_identity()))' evaluates to false
/home/users/gilles/local/gcc-11.1.0/include/c++/11.1.0/type_traits: In
instantiation of 'struct std::is_nothrow_invocable_r&, IndexGroupsAndNames>':
/home/users/gilles/local/gcc-11.1.0/include/c++/11.1.0/type_traits:3016:54:
required from 'constexpr const bool std::is_nothrow_invocable_r_v&, IndexGroupsAndNames>'
/home/users/gilles/local/gcc-11.1.0/include/c++/11.1.0/bits/invoke.h:105:14:
required from 'constexpr std::enable_if_t, _Res> std::__invoke_r(_Callable&&, _Args&& ...) [with _Res = void;
_Callable =
{anonymous}::DensityFitting::subscribeToPreProcessingNotifications(MdModulesNotifier*)::&; _Args = {IndexGroupsAndNames};
std::enable_if_t, _Res> = void]'
/home/users/gilles/local/gcc-11.1.0/include/c++/11.1.0/bits/std_function.h:291:30:
required from 'static _Res std::_Function_handler<_Res(_ArgTypes ...),
_Functor>::_M_invoke(const std::_Any_data&, _ArgTypes&& ...) [with _Res = void;
_Functor =
{anonymous}::DensityFitting::subscribeToPreProcessingNotifications(MdModulesNotifier*)::; _ArgTypes = {IndexGroupsAndNames}]'
/home/users/gilles/local/gcc-11.1.0/include/c++/11.1.0/bits/std_function.h:422:21:
required from 'std::function<_Res(_ArgTypes ...)>::function(_Functor) [with
_Functor =
{anonymous}::DensityFitting::subscribeToPreProcessingNotifications(MdModulesNotifier*)::; = void;
= void; _Res = void; _ArgTypes =
{IndexGroupsAndNames}]'
reproducer.cpp:55:56: required from here
/home/users/gilles/local/gcc-11.1.0/include/c++/11.1.0/type_traits:2992:7:
error: static assertion failed: each argument type must be a complete class or
an unbounded array
2992 | static_assert((std::__is_complete_or_unbounded(
| ^
/home/users/gilles/local/gcc-11.1.0/include/c++/11.1.0/type_traits:2992:7:
note:
'std::__is_complete_or_unbounded
>((std::__type_identity{},
std::__type_identity()))' evaluates to false
The same code can be compiled with previous g++ versions
[Bug rtl-optimization/100377] needless stack adjustment when passing struct in register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100377 --- Comment #3 from Luc Van Oostenryck --- > I thought there was one which I filed which is much older than those but I > can't find it. Probably also related to PR36409 and PR49157
PING^1 [PATCH 1/2] GCC_CET_HOST_FLAGS: Check if host supports multi-byte NOPs
On Tue, Mar 23, 2021 at 3:39 PM H.J. Lu wrote:
>
> Check if host supports multi-byte NOPs before enabling CET on host.
>
> config/
>
> PR binutils/27397
> * cet.m4 (GCC_CET_HOST_FLAGS): Check if host supports multi-byte
> NOPs.
>
> libiberty/
>
> PR binutils/27397
> * configure: Regenerated.
> ---
> config/cet.m4 | 19 ---
> libiberty/configure | 29 +
> 2 files changed, 45 insertions(+), 3 deletions(-)
>
> diff --git a/config/cet.m4 b/config/cet.m4
> index c67fb4f35b6..7718be1afe8 100644
> --- a/config/cet.m4
> +++ b/config/cet.m4
> @@ -130,6 +130,18 @@ fi
> if test x$may_have_cet = xyes; then
>if test x$cross_compiling = xno; then
> AC_TRY_RUN([
> +int
> +main ()
> +{
> + asm ("endbr32");
> + return 0;
> +}
> +],
> +[have_multi_byte_nop=yes],
> +[have_multi_byte_nop=no])
> +have_cet=no
> +if test x$have_multi_byte_nop = xyes; then
> + AC_TRY_RUN([
> static void
> foo (void)
> {
> @@ -155,9 +167,10 @@ main ()
>bar ();
>return 0;
> }
> -],
> -[have_cet=no],
> -[have_cet=yes])
> + ],
> + [have_cet=no],
> + [have_cet=yes])
> +fi
> if test x$enable_cet = xno -a x$have_cet = xyes; then
>AC_MSG_ERROR([Intel CET must be enabled on Intel CET enabled host])
> fi
> diff --git a/libiberty/configure b/libiberty/configure
> index 2ea7c119809..fc0c953dd1a 100755
> --- a/libiberty/configure
> +++ b/libiberty/configure
> @@ -5396,6 +5396,34 @@ else
>cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> /* end confdefs.h. */
>
> +int
> +main ()
> +{
> + asm ("endbr32");
> + return 0;
> +}
> +
> +_ACEOF
> +if ac_fn_c_try_run "$LINENO"; then :
> + have_multi_byte_nop=yes
> +else
> + have_multi_byte_nop=no
> +fi
> +rm -f core *.core core.conftest.* gmon.out bb.out conftest$ac_exeext \
> + conftest.$ac_objext conftest.beam conftest.$ac_ext
> +fi
> +
> +have_cet=no
> +if test x$have_multi_byte_nop = xyes; then
> + if test "$cross_compiling" = yes; then :
> + { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
> +$as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
> +as_fn_error $? "cannot run test program while cross compiling
> +See \`config.log' for more details" "$LINENO" 5; }
> +else
> + cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> +/* end confdefs.h. */
> +
> static void
> foo (void)
> {
> @@ -5432,6 +5460,7 @@ rm -f core *.core core.conftest.* gmon.out bb.out
> conftest$ac_exeext \
>conftest.$ac_objext conftest.beam conftest.$ac_ext
> fi
>
> +fi
> if test x$enable_cet = xno -a x$have_cet = xyes; then
>as_fn_error $? "Intel CET must be enabled on Intel CET enabled host"
> "$LINENO" 5
> fi
> --
> 2.30.2
>
This patch has been checked into binutils, which also fixes:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99703
Any objections to sync cet.m4 with binutils next week?
--
H.J.
[Bug target/100375] [12 Regression] trunk 20210501 ftbfs for nvptx-none
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100375 --- Comment #5 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:7911a905276781c20f704f5a91b5125e0184d072 commit r12-343-g7911a905276781c20f704f5a91b5125e0184d072 Author: Jakub Jelinek Date: Sun May 2 14:17:23 2021 +0200 nvptx: Fix up nvptx build against latest libstdc++ [PR100375] The r12-220-gd96db15967e78d7cecea3b1cf3169ceb924678ac change deprecated some non-standard std::pair constructors and that apparently broke nvptx.c build, where pseudo_node_t is std::pair and so nullptr (or NULL) needs to be used for the first argument of the ctors instead of 0. 2021-05-02 Jakub Jelinek PR target/100375 * config/nvptx/nvptx.c (nvptx_sese_pseudo): Use nullptr instead of 0 as first argument of pseudo_node_t constructors.
C language extension - Automatically cast
In desperation made by programming in GTK+ I realized, some of object languages could been implemented in C, but only these not require to made changes in programs in runtime (compiler output). One of items is automatically cast. For example I declared variable called Button of GtkButton and pass it to function requires GtkWidget. Why do not automatically cast to GtkWidget (like in class hierarchy or conversion operator in C++ or some extra constructors)? But .. it's rather conversion operator. It could looks like: __gcc_parent_type GtkWidget __gcc_parent_type_for GtkButton, GtkLabel, GtkTextView __gcc_parent_type GtkBin __gcc_parent_type_for GtkWindow, GtkBox What do you think? It makes sense, because in this case there's no way to made mistake by avoiding extra conversion. Function expected any of GtkWidget (for example), so passing GtkButton is good. Code would be cleaner, hands will be in better shape and we save programmers time.
Re: [PATCH] nvptx: Fix up nvptx build against latest libstdc++ [PR100375]
On 2021-05-02 10:52, Jakub Jelinek wrote:
Hi!
The r12-220-gd96db15967e78d7cecea3b1cf3169ceb924678ac change
deprecated some non-standard std::pair constructors and that apparently
broke nvptx.c build, where pseudo_node_t is std::pair
and so nullptr (or NULL) needs to be used for the first argument of the
ctors instead of 0.
Tested in x86_64-linux -> nvptx-none cross with CC/CXX latest trunk
gcc,
ok for trunk?
Hi Jakub,
thanks for taking care of this, LGTM, please apply.
Thanks,
- Tom
2021-05-02 Jakub Jelinek
PR target/100375
* config/nvptx/nvptx.c (nvptx_sese_pseudo): Use nullptr instead of 0
as first argument of pseudo_node_t constructors.
--- gcc/config/nvptx/nvptx.c.jj 2021-02-10 23:08:50.487460416 +0100
+++ gcc/config/nvptx/nvptx.c2021-05-02 10:39:45.803670287 +0200
@@ -3682,9 +3682,9 @@ nvptx_sese_pseudo (basic_block me, bb_se
edge e;
edge_iterator ei;
int hi_back = depth;
- pseudo_node_t node_back (0, depth);
+ pseudo_node_t node_back (nullptr, depth);
int hi_child = depth;
- pseudo_node_t node_child (0, depth);
+ pseudo_node_t node_child (nullptr, depth);
basic_block child = NULL;
unsigned num_children = 0;
int usd = -dir * sese->dir;
@@ -3751,7 +3751,7 @@ nvptx_sese_pseudo (basic_block me, bb_se
else
{ /* Fallen off graph, backlink to entry node. */
hi_back = 0;
- node_back = pseudo_node_t (0, 0);
+ node_back = pseudo_node_t (nullptr, 0);
}
}
@@ -3772,7 +3772,7 @@ nvptx_sese_pseudo (basic_block me, bb_se
else
{
/* back edge to entry node */
- sese->push (pseudo_node_t (0, 0));
+ sese->push (pseudo_node_t (nullptr, 0));
}
}
@@ -3781,7 +3781,7 @@ nvptx_sese_pseudo (basic_block me, bb_se
if (!sese->brackets.length () || !edges || !edges->length ())
{
hi_back = 0;
- node_back = pseudo_node_t (0, 0);
+ node_back = pseudo_node_t (nullptr, 0);
sese->push (node_back);
}
Jakub
[Bug tree-optimization/100366] spurious warning - std::vector::clear followed by std::vector::insert(vec.end(), ...) with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100366
Marc Glisse changed:
What|Removed |Added
Last reconfirmed||2021-05-02
Ever confirmed|0 |1
Component|c++ |tree-optimization
Keywords||diagnostic,
||missed-optimization
Status|UNCONFIRMED |NEW
--- Comment #1 from Marc Glisse ---
Assuming the warning happens during the strlen pass, we are still missing a lot
of optimizations at that point
if (_6 != _7)
goto ; [70.00%]
else
goto ; [30.00%]
[local count: 322122544]:
_158 = _7 - _6;
once VRP2 (2 passes after strlen) replaces _158 with 0 and propagates it, maybe
the code becomes nice enough to avoid confusing this fragile warning (I didn't
check).
Before FRE3, we have
_6 = vec_2(D)->D.33506._M_impl.D.32819._M_start;
_7 = vec_2(D)->D.33506._M_impl.D.32819._M_finish;
if (_6 != _7)
goto ; [70.00%]
else
goto ; [30.00%]
[local count: 1073741824]:
_5 = MEM[(char * const &)vec_2(D) + 8];
MEM[(struct __normal_iterator *)] ={v} {CLOBBER};
MEM[(struct __normal_iterator *)]._M_current = _5;
__position = D.33862;
_12 = MEM[(const char * const &)vec_2(D)];
_13 = MEM[(const char * const &)&__position];
_14 = _13 - _12;
and after FRE3
[local count: 1073741824]:
_5 = MEM[(char * const &)vec_2(D) + 8];
MEM[(struct __normal_iterator *)] ={v} {CLOBBER};
MEM[(struct __normal_iterator *)]._M_current = _5;
__position = D.33862;
_14 = _5 - _6;
Only PRE manages to notice that _5 is the same as _7, which is already late.
And it then takes until VRP2 to realize that _7 - _6 must be 0 in the else
branch of _6 != _7.
* I am not sure why FRE manages to optimize _12 and not _5, that seems like the
first thing to check (maybe the +8 means it is obviously "partial")
* I don't know if some other pass than VRP could learn that b-a is 0 if not
a!=b.
[Bug target/93808] [9/10/11/12 Regression] [SH] Ruby crashes with 'Illegal Instruction' with -fcrossjumping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93808 --- Comment #32 from John Paul Adrian Glaubitz --- (In reply to John Paul Adrian Glaubitz from comment #31) > Ah, I forgot to add -O1 and -fno-cross-jumping to CFLAGS. > > Are the builtin_traps() optimized out for -O2? > > I'm building with the correct flags now. Traps also didn't trigger with -O1 and -fno-cross-jumping.
Re: compiler
On Sat, May 01, 2021 at 09:51:00PM -0700, Jaime Guzman Gaytan via Gcc wrote:
> How can I get the compiler if I don't have internet in my apartment?
Depending on what platform you're on, there should be a package (deb, rpm, etc)
which you can download at i.e. work or a local library or university. Put that
on a USB stick and take it home, then use your package manager to install it.
--
>>= %frosku = { os => 'gnu+linux', editor => 'emacs', coffee => 1 } =<<
[Bug target/98341] [11/12 Regression] Ada bootstrap fails with erroneous memory access on m68k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98341 Eric Botcazou changed: What|Removed |Added Summary|[11/12 Regression] Ada |[11/12 Regression] Ada |bootstrap fails with|bootstrap fails with |Storage_Error stack |erroneous memory access on |overflow or erroneous |m68k |memory access on m68k | Last reconfirmed||2021-05-02 Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 --- Comment #14 from Eric Botcazou --- We need at least a backtrace.
[Bug target/98341] [11/12 Regression] Ada bootstrap fails with Storage_Error stack overflow or erroneous memory access on m68k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98341 --- Comment #13 from Eric Botcazou --- > Note sure if this is related, but the 32bit Windows build of 11.1.0 fails in > a similar way: Not all build failures are similar because they affect the Ada compiler! Please open a separate TN for your problem, this one is for m68k. Thanks in advance.
[Bug target/93808] [9/10/11/12 Regression] [SH] Ruby crashes with 'Illegal Instruction' with -fcrossjumping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93808 --- Comment #31 from John Paul Adrian Glaubitz --- (In reply to John Paul Adrian Glaubitz from comment #30) > Created attachment 50717 [details] > Build log for ruby 2.5 with Oleg's patch applied Ah, I forgot to add -O1 and -fno-cross-jumping to CFLAGS. Are the builtin_traps() optimized out for -O2? I'm building with the correct flags now.
[Bug target/98341] [11/12 Regression] Ada bootstrap fails with Storage_Error stack overflow or erroneous memory access on m68k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98341 Christoph Reiter changed: What|Removed |Added CC||reiter.christoph at gmail dot com --- Comment #12 from Christoph Reiter --- Note sure if this is related, but the 32bit Windows build of 11.1.0 fails in a similar way: gnat1.exe: warning: command-line option '-Wno-pedantic-ms-format' is valid for C/C++/ObjC/ObjC++ but not for Ada make[3]: *** [../../gcc-11.1.0/gcc/ada/gcc-interface/Make-lang.in:1052: ada/libgnat/a-except.o] Error 1 make[3]: *** Waiting for unfinished jobs rm gcc.pod gfortran.pod make[3]: Leaving directory '/C/_/mingw-w64-gcc/src/build-i686-w64-mingw32/gcc' make[2]: *** [Makefile:4833: all-stage2-gcc] Error 2 make[2]: Leaving directory '/C/_/mingw-w64-gcc/src/build-i686-w64-mingw32' make[1]: *** [Makefile:26006: stage2-bubble] Error 2 make[1]: Leaving directory '/C/_/mingw-w64-gcc/src/build-i686-w64-mingw32' make: *** [Makefile:1013: all] Error 2
[PATCH] nvptx: Fix up nvptx build against latest libstdc++ [PR100375]
Hi!
The r12-220-gd96db15967e78d7cecea3b1cf3169ceb924678ac change
deprecated some non-standard std::pair constructors and that apparently
broke nvptx.c build, where pseudo_node_t is std::pair
and so nullptr (or NULL) needs to be used for the first argument of the
ctors instead of 0.
Tested in x86_64-linux -> nvptx-none cross with CC/CXX latest trunk gcc,
ok for trunk?
2021-05-02 Jakub Jelinek
PR target/100375
* config/nvptx/nvptx.c (nvptx_sese_pseudo): Use nullptr instead of 0
as first argument of pseudo_node_t constructors.
--- gcc/config/nvptx/nvptx.c.jj 2021-02-10 23:08:50.487460416 +0100
+++ gcc/config/nvptx/nvptx.c2021-05-02 10:39:45.803670287 +0200
@@ -3682,9 +3682,9 @@ nvptx_sese_pseudo (basic_block me, bb_se
edge e;
edge_iterator ei;
int hi_back = depth;
- pseudo_node_t node_back (0, depth);
+ pseudo_node_t node_back (nullptr, depth);
int hi_child = depth;
- pseudo_node_t node_child (0, depth);
+ pseudo_node_t node_child (nullptr, depth);
basic_block child = NULL;
unsigned num_children = 0;
int usd = -dir * sese->dir;
@@ -3751,7 +3751,7 @@ nvptx_sese_pseudo (basic_block me, bb_se
else
{ /* Fallen off graph, backlink to entry node. */
hi_back = 0;
- node_back = pseudo_node_t (0, 0);
+ node_back = pseudo_node_t (nullptr, 0);
}
}
@@ -3772,7 +3772,7 @@ nvptx_sese_pseudo (basic_block me, bb_se
else
{
/* back edge to entry node */
- sese->push (pseudo_node_t (0, 0));
+ sese->push (pseudo_node_t (nullptr, 0));
}
}
@@ -3781,7 +3781,7 @@ nvptx_sese_pseudo (basic_block me, bb_se
if (!sese->brackets.length () || !edges || !edges->length ())
{
hi_back = 0;
- node_back = pseudo_node_t (0, 0);
+ node_back = pseudo_node_t (nullptr, 0);
sese->push (node_back);
}
Jakub
[Bug target/100336] file trunk/gcc/config/i386/i386-isa.def doesn't get installed ok ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100336 --- Comment #2 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:6e1ecc984ef71fc80d0fb7e91ac38af16ccb1943 commit r12-342-g6e1ecc984ef71fc80d0fb7e91ac38af16ccb1943 Author: Jakub Jelinek Date: Sun May 2 10:28:11 2021 +0200 i386: Fix up plugin header install on x86 [PR100336] The recent addition of i386-isa.def which is included from i386.h results in failures to build gcc plugins, the i386.h header is installed, but i386-isa.def is not. 2021-05-02 Jakub Jelinek PR target/100336 * config/i386/t-i386 (TM_H): Add $(srcdir)/config/i386/i386-isa.def.
Re: [PATCH] i386: Fix up plugin header install on x86 [PR100336]
On Sat, May 1, 2021 at 9:54 PM Jakub Jelinek wrote: > > Hi! > > The recent addition of i386-isa.def which is included from i386.h results > in failures to build gcc plugins, the i386.h header is installed, but > i386-isa.def is not. > > Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux and > tested with make install, ok for trunk? > > 2021-05-01 Jakub Jelinek > > PR target/100336 > * config/i386/t-i386 (TM_H): Add $(srcdir)/config/i386/i386-isa.def. OK. Thanks, Uros. > --- gcc/config/i386/t-i386.jj 2021-01-04 10:25:45.428159147 +0100 > +++ gcc/config/i386/t-i386 2021-04-30 11:06:30.176266111 +0200 > @@ -18,7 +18,8 @@ > > OPTIONS_H_EXTRA += $(srcdir)/config/i386/stringop.def > TM_H += $(srcdir)/config/i386/x86-tune.def \ > - $(srcdir)/common/config/i386/i386-cpuinfo.h > + $(srcdir)/common/config/i386/i386-cpuinfo.h \ > + $(srcdir)/config/i386/i386-isa.def > PASSES_EXTRA += $(srcdir)/config/i386/i386-passes.def > > i386-c.o: $(srcdir)/config/i386/i386-c.c > > Jakub >
