[Bug c++/91431] New: Using class template for containers and iterators rather than defining template only for iterators caused a trouble
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91431
Bug ID: 91431
Summary: Using class template for containers and iterators
rather than defining template only for iterators
caused a trouble
Product: gcc
Version: 7.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: p.hyundeok76 at gmail dot com
Target Milestone: ---
Created attachment 46705
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46705=edit
File processed through `gcc -v -save-temps [MYFILE]`
Version: g++ (GCC) 7.4.0
System type:
Cygwin on Windows 10 Home 64 bit 1903
uname -r shows:
3.0.7(0.338/5/3)
Command used to compile the source code:
g++ bug.cpp -o bug
The compiler output:
bug.cpp: In instantiating of 'class Blob':
bug.cpp:23.19:required here
bug.cpp:11.4: Internal compiler error: in tsubst, at cp/pt.c:13675
> Blob(Iter b, Iter e) {
^~~~
Please submit a full bug report,
which preprocessed source if appropriate.
See
[Bug c++/87150] [8 Regression] move ctor wrongly chosen in return stmt (derived vs. base)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87150 --- Comment #24 from Jason Merrill --- (In reply to Marek Polacek from comment #23) > Thanks, missed that. Looks like Jason wants us to fix it retroactively, > too. I suppose we should just revert my r264172. Better to disable the section in build_over_call that implemented the check removed by this paper: /* The implicit move specified in 15.8.3/3 fails "...if the type of the first parameter of the selected constructor is not an rvalue reference to the object’s type (possibly cv-qualified)" */ I wouldn't remove it entirely until we have a better idea of what gets broken by this change.
[Bug rtl-optimization/91430] New: ICE in curr_insn_transform, at lra-constraints.c:3962
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91430
Bug ID: 91430
Summary: ICE in curr_insn_transform, at lra-constraints.c:3962
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: novalazy at gmail dot com
Target Milestone: ---
Hi, the following test case hits an ICE in gcc 9.1.0 on x86_64.
% cat test.c
register unsigned long a __asm__("r14");
register unsigned long b __asm__("r15");
void test(void)
{
b = a << 4;
}
% gcc -O1 -c test.c
test.c: In function 'test':
test.c:7:1: error: unable to generate reloads for:
7 | }
| ^
(insn 6 5 9 2 (parallel [
(set (reg/v:DI 43 r15 [ b ])
(ashift:DI (reg/v:DI 42 r14 [ a ])
(const_int 4 [0x4])))
(clobber (reg:CC 17 flags))
]) "test.c":6:11 520 {*ashldi3_1}
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
during RTL pass: reload
test.c:7:1: internal compiler error: in curr_insn_transform, at
lra-constraints.c:3962
% gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/9.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --with-system-zlib --with-isl --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--disable-libssp --enable-gnu-unique-object --enable-linker-build-id
--enable-lto --enable-plugin --enable-install-libiberty
--with-linker-hash-style=gnu --enable-gnu-indirect-function --enable-multilib
--disable-werror --enable-checking=release --enable-default-pie
--enable-default-ssp --enable-cet=auto
Thread model: posix
gcc version 9.1.0 (GCC)
[Bug tree-optimization/91425] Ordered compares aren't optimised
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91425 --- Comment #8 from joseph at codesourcery dot com --- A more general representation would facilitate implementing __builtin_iseqsig (bug 77928). (As noted in previous discussions, some processors, e.g. MIPS, actually have a general comparison operation that can represent all 32 choices of which cases the comparison is true for, and whether it raises "invalid" for quiet NaNs. So it would be good to have a clear path through from the general representation to selecting a single corresponding instruction on such processors.)
[Bug c++/87150] [8 Regression] move ctor wrongly chosen in return stmt (derived vs. base)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87150 --- Comment #23 from Marek Polacek --- Thanks, missed that. Looks like Jason wants us to fix it retroactively, too. I suppose we should just revert my r264172.
[Bug fortran/89413] [PDT] ICE in resolve_fl_derived, at fortran/resolve.c:14392
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89413 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING CC||janus at gcc dot gnu.org, ||kargl at gcc dot gnu.org --- Comment #3 from kargl at gcc dot gnu.org --- This seems to have been fixed by Janus in r269658. Perhaps, this can be closed. gfcx -c a.f90 a.f90:2:15: 2 | type :: t5 () | 1 Error: A type parameter list is required at (1)
[Bug c++/87150] [8 Regression] move ctor wrongly chosen in return stmt (derived vs. base)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87150 Richard Smith changed: What|Removed |Added CC||richard-gccbugzilla@metafoo ||.co.uk --- Comment #22 from Richard Smith --- (In reply to Marek Polacek from comment #20) > (In reply to Jason Merrill from comment #19) > > And now P1155/P1825 removes that text, so in C++20 mode the original > > testcase needs to call the move constructor again. Marek, I don't see > > P1825R0 in cxx-status.html, was there a reason not to add it? > > No, I followed clang's table but they're missing that one. I'll fix that & > open a PR for P1825R0. FYI, it is in Clang's table, but I put it in the C++11 features list since it's a DR and we're considering it to retroactively apply to C++11's addition of move semantics.
[Bug tree-optimization/91109] [10 regression][arm] gcc.c-torture/execute/20040709-1.c fails since r273135
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91109 --- Comment #13 from Bernd Edlinger --- Created attachment 46704 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46704=edit another untested patch
[Bug fortran/89647] Host associated procedure unable to be used as binding target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89647 --- Comment #3 from kargl at gcc dot gnu.org --- Patch submitted.
[Bug fortran/91359] logical function X returns .TRUE. - Warning: spaghetti code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91359 --- Comment #18 from Brian T. Carcich --- Thanks for the fix and your patience. We got gfortran with this patch to build on a box running Linux 2.6.9 ca. November 2011, and it solved the problem. Well done.
[Bug fortran/47191] Misleading error message if part-ref starts with DATA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47191 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from kargl at gcc dot gnu.org --- Seems I forgot to close this.
[Bug fortran/33056] [Meta-bug] Data - statement related bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33056 Bug 33056 depends on bug 47191, which changed state. Bug 47191 Summary: Misleading error message if part-ref starts with DATA https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47191 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/90538] [9/10 Regression] Redeclaration error when expanding parameter pack multiple times in a lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90538 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.3 --- Comment #4 from Jason Merrill --- Fixed for 9.3/10.
[Bug c++/91378] [9 regression] [C++17] ICE in type_dependent_expression_p with noexcept and deduced return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91378 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jason Merrill --- Fixed for GCC 9.3/10.
[Bug c++/87150] [8 Regression] move ctor wrongly chosen in return stmt (derived vs. base)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87150 --- Comment #21 from Jason Merrill --- (In reply to Jason Merrill from comment #19) > And now P1155/P1825 removes that text, so in C++20 mode the original > testcase needs to call the move constructor again. Actually, it's a DR, so not just C++20 mode.
[Bug c++/91429] New: Conditional explicit not respected with out-of-line definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91429
Bug ID: 91429
Summary: Conditional explicit not respected with out-of-line
definition
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: barry.revzin at gmail dot com
Target Milestone: ---
Reduced from StackOverflow (https://stackoverflow.com/q/57467490/2069064):
using size_t = decltype(sizeof(0));
struct Str {
template
explicit(N > 7) Str(char const ()[N]);
};
#ifdef OUT_OF_LINE
template
Str::Str(char const()[N]) { }
#endif
Str a = "short";
Str b = "not so short";
As-is, gcc correctly rejects the construction of b (since that constructor is
explicit). But with -DOUT_OF_LINE, gcc accepts.
[Bug testsuite/91422] Illegal Fortran in testsuite/libgomp.oacc-fortran/routine-7.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91422 --- Comment #3 from Thomas Koenig --- Author: tkoenig Date: Mon Aug 12 20:21:37 2019 New Revision: 274320 URL: https://gcc.gnu.org/viewcvs?rev=274320=gcc=rev Log: 2019-08-12 Thomas Koenig PR fortran/91424 * frontend-passes.c (do_subscript): Do not warn for an expression a second time. Do not warn about a zero-trip loop. (doloop_warn): Also look at contained namespaces. 2019-08-12 Thomas Koenig PR fortran/91424 * gfortran.dg/do_subscript_3.f90: New test. * gfortran.dg/do_subscript_4.f90: New test. * gfortran.dg/pr70754.f90: Use indices that to not overflow. 2019-08-12 Thomas Koenig PR fortran/91422 * testsuite/libgomp.oacc-fortran/routine-7.f90: Correct array dimension. Added: trunk/gcc/testsuite/gfortran.dg/do_subscript_3.f90 trunk/gcc/testsuite/gfortran.dg/do_subscript_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/frontend-passes.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/pr70754.f90 trunk/libgomp/ChangeLog trunk/libgomp/testsuite/libgomp.oacc-fortran/routine-7.f90
[Bug fortran/91424] Extend warnings about DO loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91424 --- Comment #5 from Thomas Koenig --- Author: tkoenig Date: Mon Aug 12 20:21:37 2019 New Revision: 274320 URL: https://gcc.gnu.org/viewcvs?rev=274320=gcc=rev Log: 2019-08-12 Thomas Koenig PR fortran/91424 * frontend-passes.c (do_subscript): Do not warn for an expression a second time. Do not warn about a zero-trip loop. (doloop_warn): Also look at contained namespaces. 2019-08-12 Thomas Koenig PR fortran/91424 * gfortran.dg/do_subscript_3.f90: New test. * gfortran.dg/do_subscript_4.f90: New test. * gfortran.dg/pr70754.f90: Use indices that to not overflow. 2019-08-12 Thomas Koenig PR fortran/91422 * testsuite/libgomp.oacc-fortran/routine-7.f90: Correct array dimension. Added: trunk/gcc/testsuite/gfortran.dg/do_subscript_3.f90 trunk/gcc/testsuite/gfortran.dg/do_subscript_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/frontend-passes.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/pr70754.f90 trunk/libgomp/ChangeLog trunk/libgomp/testsuite/libgomp.oacc-fortran/routine-7.f90
[Bug fortran/91359] logical function X returns .TRUE. - Warning: spaghetti code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91359 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.3 --- Comment #17 from kargl at gcc dot gnu.org --- Fixed on trunk and 9-branch. Thanks for the bug report.
[Bug fortran/91359] logical function X returns .TRUE. - Warning: spaghetti code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91359 --- Comment #16 from kargl at gcc dot gnu.org --- Author: kargl Date: Mon Aug 12 20:09:00 2019 New Revision: 274319 URL: https://gcc.gnu.org/viewcvs?rev=274319=gcc=rev Log: 2019-08-12 Steven G. Kargl PR fortran/91359 * trans-decl.c (gfc_generate_return): Ensure something is returned from a function. 2019-08-12 Steven G. Kargl PR fortran/91359 * gfortran.dg/pr91359_1.f: New test. * gfortran.dg/pr91359_2.f: Ditto. Added: branches/gcc-9-branch/gcc/testsuite/gfortran.dg/pr91359_1.f branches/gcc-9-branch/gcc/testsuite/gfortran.dg/pr91359_2.f Modified: branches/gcc-9-branch/gcc/fortran/ChangeLog branches/gcc-9-branch/gcc/fortran/trans-decl.c branches/gcc-9-branch/gcc/testsuite/ChangeLog
[Bug c++/91428] Please warn on if constexpr (std::is_constant_evaluated())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91428 --- Comment #2 from Marek Polacek --- *be
[Bug c++/91428] Please warn on if constexpr (std::is_constant_evaluated())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91428 Marek Polacek changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-08-12 CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- (In reply to Barry Revzin from comment #0) > Can you please provide a warning for this erroneous usage? Yes, I think this ought to me feasible to add to finish_if_stmt_cond.
[Bug c++/91407] Wnon-virtual-dtor should't fire for classes with operator delete=delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91407 --- Comment #4 from Aso Renji --- (In reply to Jonathan Wakely from comment #3) > But it's not enabled by -Wall7 > > Maybe QtCreator should be fixed instead. Hmm, compile output in QtCreator: g++ -c -pipe -g -Wall -W -fPIC -DQT_QML_DEBUG -I../test -I. -I/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -o main.o ../test/main.cpp I try ran this in console and don't get any warning. But Qt itself show "warning: 'Test' has virtual functions but non-virtual destructor". So, you right, this is problem in QtCreator.
[Bug fortran/42546] ALLOCATED statement typo in the docs and for scalar variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42546 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|10.0|9.3 --- Comment #8 from kargl at gcc dot gnu.org --- Fixed on 9-branch and trunk.
[Bug fortran/89078] [meta-bug] Improve the gfortran manual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89078 Bug 89078 depends on bug 42546, which changed state. Bug 42546 Summary: ALLOCATED statement typo in the docs and for scalar variables https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42546 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/42546] ALLOCATED statement typo in the docs and for scalar variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42546 --- Comment #7 from kargl at gcc dot gnu.org --- Author: kargl Date: Mon Aug 12 19:48:37 2019 New Revision: 274318 URL: https://gcc.gnu.org/viewcvs?rev=274318=gcc=rev Log: 2019-08-01 Steven G. Kargl PR fortran/42546 * check.c(gfc_check_allocated): Add comment pointing to ... * intrinsic.c(sort_actual): ... the checking done here. 2019-08-01 Steven G. Kargl PR fortran/42546 * gfortran.dg/allocated_1.f90: New test. * gfortran.dg/allocated_2.f90: Ditto. Added: branches/gcc-9-branch/gcc/testsuite/gfortran.dg/allocated_1.f90 branches/gcc-9-branch/gcc/testsuite/gfortran.dg/allocated_2.f90 Modified: branches/gcc-9-branch/gcc/fortran/ChangeLog branches/gcc-9-branch/gcc/fortran/check.c branches/gcc-9-branch/gcc/fortran/intrinsic.c branches/gcc-9-branch/gcc/testsuite/ChangeLog
[Bug c++/91428] New: Please warn on if constexpr (std::is_constant_evaluated())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91428
Bug ID: 91428
Summary: Please warn on if constexpr
(std::is_constant_evaluated())
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: barry.revzin at gmail dot com
Target Milestone: ---
A very common user error with std::is_constant_evaluated is to write this:
#include
constexpr int foo(int i) {
if constexpr (std::is_constant_evaluated()) {
return 42;
} else {
return i;
}
}
That is, check if we're in the middle of constant evaluation with "if
constexpr" instead of plain "if". This is the intuitive check to do, but
unfortunately, since the condition here is manifestly constant evaluated, the
result of check is unconditionally true. gcc implements this correctly - the
above function is exactly equivalent to "return 42;" - but that's unlikely to
be what the user intended the program to do. They likely intended to write:
constexpr int foo(int i) {
if (std::is_constant_evaluated()) {
return 42;
} else {
return i;
}
}
Can you please provide a warning for this erroneous usage?
[Bug target/90330] gcc 9.1.0 fails to install on macOS 10.14.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90330 --- Comment #31 from Iain Sandoe --- (In reply to Matt Thompson from comment #30) > (In reply to Matt Thompson from comment #28) > > (In reply to Iain Sandoe from comment #27) > > > That's fine - essentially, you're building them from source and therefore > > > don't need to worry about --with-gmp= configure options etc. > > > > > > For the record, I'm using GMP-6.1.2, MPFR-3.1.6, MPC-1.1.0 and ISL-0.20. > > > > Well, it looks like download_prerequisites might be behind the times: > > > > gmp='gmp-6.1.0.tar.bz2' > > mpfr='mpfr-3.1.4.tar.bz2' > > mpc='mpc-1.0.3.tar.gz' > > isl='isl-0.18.tar.bz2' > > > > I'm going to try and download the newest versions of all these and build > > with them. Maybe that'll help (though I don't see much/any C++ in them...). > > Yeah. Didn't help. Still, it was a fun exercise. That was a long shot to solve your problem; was mainly documenting what I've done that worked. > If GCC was on github, I'd make a pull request to update the > download_prerequisites script, though. Unless there's a good reason to use > these version? AFAIK, the pre-reqs are the minimum versions and there's nothing to sop one from deciding to use newer (keeping the minimum to the lowest practical is advantageous in compatibility). Updating any GCC dependency has wide ramifications - many folks might just use the version installed on their system (if it's Linux) - on Darwin we care somewhat less, since we have to build them anyway. I've started a 9.2 build/install/test cycle with xcode10.2 toolchain as the bootstrap - will post the results here later/tomorrow.
[Bug c++/91407] Wnon-virtual-dtor should't fire for classes with operator delete=delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91407 --- Comment #3 from Jonathan Wakely --- But it's not enabled by -Wall7 Maybe QtCreator should be fixed instead.
[Bug preprocessor/84864] Issues with large line numbers >= 2^31
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84864 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-08-12 CC||egallager at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from Eric Gallager --- ASSIGNED due to assignee
[Bug c++/49129] confusing diagnostic for missing semi-colon after member template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49129 Eric Gallager changed: What|Removed |Added Status|NEW |ASSIGNED CC||egallager at gcc dot gnu.org --- Comment #6 from Eric Gallager --- ASSIGNED due to assignee
[Bug c++/85004] ambiguous diagnostic: passing ‘const S’ as ‘this’ argument discards qualifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85004 Eric Gallager changed: What|Removed |Added Status|NEW |ASSIGNED CC||egallager at gcc dot gnu.org --- Comment #4 from Eric Gallager --- ASSIGNED since there's an assignee
[Bug target/91420] relocation truncated to fit: R_RISCV_HI20 against `.LC0' with GCC 8.2/8.3 with "-O2" on RISC-V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91420 Jim Wilson changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-08-12 CC||wilson at gcc dot gnu.org Ever confirmed|0 |1
[Bug preprocessor/77672] wrong rich location in warning: writing a terminating nul past the end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77672 Eric Gallager changed: What|Removed |Added Status|ASSIGNED|WAITING CC||egallager at gcc dot gnu.org --- Comment #8 from Eric Gallager --- (In reply to Martin Liška from comment #7) > David: Can the bug be marked as resolved? WAITING on a reply
[Bug c++/91427] Implement P1825R0, Merged wording for P0527R1 and P1155R3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91427 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-08-12 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- I'll probably work on it since it reverts my fix for bug 87150, but not assigning quite yet.
[Bug c++/91427] New: Implement P1825R0, Merged wording for P0527R1 and P1155R3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91427 Bug ID: 91427 Summary: Implement P1825R0, Merged wording for P0527R1 and P1155R3 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: mpolacek at gcc dot gnu.org Target Milestone: --- Tracker PR to implement C++20 P1825R0. Also see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87150#c19
[Bug target/90330] gcc 9.1.0 fails to install on macOS 10.14.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90330 --- Comment #30 from Matt Thompson --- (In reply to Matt Thompson from comment #28) > (In reply to Iain Sandoe from comment #27) > > That's fine - essentially, you're building them from source and therefore > > don't need to worry about --with-gmp= configure options etc. > > > > For the record, I'm using GMP-6.1.2, MPFR-3.1.6, MPC-1.1.0 and ISL-0.20. > > Well, it looks like download_prerequisites might be behind the times: > > gmp='gmp-6.1.0.tar.bz2' > mpfr='mpfr-3.1.4.tar.bz2' > mpc='mpc-1.0.3.tar.gz' > isl='isl-0.18.tar.bz2' > > I'm going to try and download the newest versions of all these and build > with them. Maybe that'll help (though I don't see much/any C++ in them...). Yeah. Didn't help. Still, it was a fun exercise. If GCC was on github, I'd make a pull request to update the download_prerequisites script, though. Unless there's a good reason to use these version?
[Bug c++/87150] [8 Regression] move ctor wrongly chosen in return stmt (derived vs. base)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87150 --- Comment #20 from Marek Polacek --- (In reply to Jason Merrill from comment #19) > And now P1155/P1825 removes that text, so in C++20 mode the original > testcase needs to call the move constructor again. Marek, I don't see > P1825R0 in cxx-status.html, was there a reason not to add it? No, I followed clang's table but they're missing that one. I'll fix that & open a PR for P1825R0.
[Bug other/61257] configure should check if sys/sdt.h is usable, not just checking the existance of the header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61257 --- Comment #6 from Tom Tromey --- (In reply to Eric Gallager from comment #4) > (In reply to Sergei Trofimovich from comment #3) > > (In reply to Sergei Trofimovich from comment #2) > > > Having explicit flags like --enable-systemtap / --disable-systemtap (glibc > > > has those) would fix the issue. > > > > Proposed upstream as: > > https://gcc.gnu.org/ml/gcc-patches/2018-05/msg00578.html > > > > To clarify: it's not a complete fix for this bug. Only a way to disable > > support manually. > > I'll take this as confirmation. Also now that I've seen the actual code in > this patch, I can say that my previous comment (comment #1) no longer > applies, since the script is just doing `test -f` instead of > AC_CHECK_HEADERS. IIRC that's because it has to check target headers, but AC_CHECK_HEADERS checks host headers. Maybe there's some other way to do it, I don't know. It's fine to really check the header, but I would say the scenario in comment #2 has to fall under "don't do this". That said, a --enable flag or whatever also seems fine to me.
[Bug c++/87150] [8 Regression] move ctor wrongly chosen in return stmt (derived vs. base)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87150 --- Comment #19 from Jason Merrill --- And now P1155/P1825 removes that text, so in C++20 mode the original testcase needs to call the move constructor again. Marek, I don't see P1825R0 in cxx-status.html, was there a reason not to add it?
[Bug c++/91407] Wnon-virtual-dtor should't fire for classes with operator delete=delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91407 --- Comment #2 from Aso Renji --- (In reply to Jonathan Wakely from comment #1) > Is there a reason you need to use -Wnon-virtual-dtor ? QtCreator with -Wall as default compile option. Yes, I can set custom compile options, or use #pragma GCC diagnostic ignored "-Wnon-virtual-dtor". But it's not very convenient.
[Bug c++/88095] class nontype template parameter UDL string literals doesn't accepts deduction placeholder
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88095 --- Comment #6 from Jason Merrill --- Author: jason Date: Mon Aug 12 17:46:37 2019 New Revision: 274317 URL: https://gcc.gnu.org/viewcvs?rev=274317=gcc=rev Log: PR c++/88095, CTAD for literal operator templates per P0732 This patch fixes PR c++/88095: class nontype template parameter UDL string literals doesn't accepts deduction placeholder It also addresses a latent issue; literal operator templates with template parameter packs of literal class type were previously accepted. The patch corrects this and adds a test (udlit-class-nttp-neg.C). This fix is needed for one of the char8_t remediation approaches documented in P1423, and may be helpful for existing code bases impacted by the char8_t changes adopted via P0482 for C++20. gcc/cp/ChangeLog: 2019-08-02 Tom Honermann * parser.c (cp_parser_template_declaration_after_parameters): Enable class template argument deduction for non-type template parameters in literal operator templates. gcc/testsuite/ChangeLog: 2019-08-02 Tom Honermann PR c++/88095 * g++.dg/cpp2a/udlit-class-nttp-ctad.C: New test. * g++.dg/cpp2a/udlit-class-nttp-ctad-neg.C: New test. * g++.dg/cpp2a/udlit-class-nttp-ctad-neg2.C: New test. * g++.dg/cpp2a/udlit-class-nttp.C: New test. * g++.dg/cpp2a/udlit-class-nttp-neg.C: New test. * g++.dg/cpp2a/udlit-class-nttp-neg2.C: New test. Added: branches/gcc-9-branch/gcc/testsuite/g++.dg/cpp2a/udlit-class-nttp-ctad-neg.C branches/gcc-9-branch/gcc/testsuite/g++.dg/cpp2a/udlit-class-nttp-ctad-neg2.C branches/gcc-9-branch/gcc/testsuite/g++.dg/cpp2a/udlit-class-nttp-ctad.C branches/gcc-9-branch/gcc/testsuite/g++.dg/cpp2a/udlit-class-nttp-neg.C branches/gcc-9-branch/gcc/testsuite/g++.dg/cpp2a/udlit-class-nttp-neg2.C branches/gcc-9-branch/gcc/testsuite/g++.dg/cpp2a/udlit-class-nttp.C Modified: branches/gcc-9-branch/gcc/cp/ChangeLog branches/gcc-9-branch/gcc/cp/parser.c branches/gcc-9-branch/gcc/testsuite/ChangeLog
[Bug c++/91378] [9 regression] [C++17] ICE in type_dependent_expression_p with noexcept and deduced return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91378 --- Comment #3 from Jason Merrill --- Author: jason Date: Mon Aug 12 17:46:32 2019 New Revision: 274316 URL: https://gcc.gnu.org/viewcvs?rev=274316=gcc=rev Log: PR c++/91378 - ICE with noexcept and auto return type. Here, since the call to g is not type-dependent, we call mark_used on it to determine its return type. This also wants to instantiate the noexcept-expression. But since nothing in maybe_instantiate_noexcept was calling push_to_top_level, we substituted b.i with processing_template_decl set, so we left it unresolved for later access checking. As a result, the type of C::g remained instantiation-dependent, leading to an ICE in type_dependent_expression_p on the assert that the type of a function template with no dependent template arguments must be non-dependent. * pt.c (maybe_instantiate_noexcept): push_to_top_level. Added: branches/gcc-9-branch/gcc/testsuite/g++.dg/cpp1y/auto-fn56.C Modified: branches/gcc-9-branch/gcc/cp/ChangeLog branches/gcc-9-branch/gcc/cp/pt.c
[Bug c++/90538] [9/10 Regression] Redeclaration error when expanding parameter pack multiple times in a lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90538 --- Comment #3 from Jason Merrill --- Author: jason Date: Mon Aug 12 17:46:25 2019 New Revision: 274315 URL: https://gcc.gnu.org/viewcvs?rev=274315=gcc=rev Log: PR c++/90538 - multiple expansions of capture packs Previously, with init-capture the type of the closure field was a DECLTYPE_TYPE of the initializer. But since each time we tsubst a lambda we get a different lambda, that meant that if the initializer is a lambda, we'd end up with different closure types in the field and initializer after substitution (PR 87322). We dealt with this by remembering the lambda instantiation within each pack expansion element, using local_specialization_stack to separate the elements. But that broke this testcase, because it lost lambda capture proxies that also use local_specializations. So, this patch removes the local_specializations changes from that patch and fixes 87322 differently, by giving init-capture fields 'auto' type and doing deduction later. There's a bit of a kludge to get the right number of fields by pretending that 'auto...' uses the parameter packs from the initializer, but it does the trick. * cp-tree.h (DECLTYPE_FOR_INIT_CAPTURE): Remove. * lambda.c (add_capture): Copy parameter packs from init. (lambda_capture_field_type): Always use auto for init-capture. * pt.c (uses_parameter_packs): Return tree. (tsubst) [DECLTYPE_TYPE]: Remove init-capture handling. (gen_elem_of_pack_expansion_instantiation): Don't push local_specialization_stack. (prepend_one_capture): New. (tsubst_lambda_expr): Use it. Don't touch local_specializations. (do_auto_deduction): Avoid redundant error. Added: branches/gcc-9-branch/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-variadic9.C Modified: branches/gcc-9-branch/gcc/cp/ChangeLog branches/gcc-9-branch/gcc/cp/cp-tree.h branches/gcc-9-branch/gcc/cp/lambda.c branches/gcc-9-branch/gcc/cp/pt.c branches/gcc-9-branch/gcc/testsuite/g++.dg/cpp0x/range-for19.C branches/gcc-9-branch/gcc/testsuite/g++.dg/cpp1y/lambda-init16.C
[Bug c++/91423] address-of-packed-member when taking packed struct member by value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91423 --- Comment #4 from Andrew Pinski --- Vec size = s.size; you are invoking the copy constructor here ... Which means you are taking the address (implicitly).
[Bug c++/91418] Nested class of templated class cannot declare parent class friend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91418 --- Comment #5 from Harald van Dijk --- (In reply to Darrell Wright from comment #4) > The weird part is, other than compilers don't agree, but the lookup finds it > if you put the template argument in The idea there seems to be that `class A;` declares a local or nested class, but `A;`, `class A;`, `class ::A;` do not, and `friend` does not change that. This is not something I can find support for in the standard though.
[Bug fortran/91424] Extend warnings about DO loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91424 --- Comment #4 from Thomas Koenig --- (In reply to Eric Gallager from comment #2) > - the "2" location marker is a different color from the "1" location marker, > if you have colorized output That is now PR 91426.
[Bug fortran/91426] New: Different colors for errors with multiple locations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91426 Bug ID: 91426 Summary: Different colors for errors with multiple locations Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: tkoenig at gcc dot gnu.org Target Milestone: --- The following program program main 10 continue 10 continue end yields label.f90:2:2: 2 | 10 continue | 1 3 | 10 continue | 2 Error: Duplicate statement label 10 at (1) and (2) as it should. However (not visible here), the first marker (1) is red, and the second one (2) is green. Expected behavior is that they should be the same color.
[Bug target/83250] _mm256_zextsi128_si256 missing for AVX2 zero extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83250 --- Comment #8 from Jakub Jelinek --- Intrinsics now implemented for GCC 10+, keeping open for some optimizations.
[Bug libstdc++/90361] [9/10 Regression] Undefined symbols in libstdc++ when building with --with-default-libstdcxx-abi=gcc4-compatible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90361 --- Comment #8 from Jonathan Wakely --- Author: redi Date: Mon Aug 12 16:41:27 2019 New Revision: 274314 URL: https://gcc.gnu.org/viewcvs?rev=274314=gcc=rev Log: PR libstdc++/90361 add missing macro definition The src/c++17/string-inst.cc file needs to override the default string ABI so that it still contains the expected symbols even when the library is configured with --with-default-libstdcxx-abi=gcc4-compatible. PR libstdc++/90361 * src/c++17/string-inst.cc: Use _GLIBCXX_USE_CXX11_ABI=1 by default. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/src/c++17/string-inst.cc
[Bug c/69558] [7/8 Regression] glib2 warning pragmas stopped working
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69558 Eric Gallager changed: What|Removed |Added Target Milestone|9.3 |8.5 --- Comment #30 from Eric Gallager --- (In reply to Bernd Edlinger from comment #29) > Hm, the target milestone is wrong. I believe this was fixed in gcc-9 changing it to something starting in 8 then
[Bug c++/77711] Add fix-it hints for missing parentheses in member function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77711 Jonathan Wakely changed: What|Removed |Added Target Milestone|9.3 |10.0
[Bug fortran/91424] Extend warnings about DO loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91424 --- Comment #3 from Thomas Koenig --- (In reply to Eric Gallager from comment #2) > Also: > - there's no option flag controlling the warning That one is by design. There is no way that this can even be valid code. > - the "2" location marker is a different color from the "1" location marker, > if you have colorized output How would I change that?
[Bug fortran/91424] Extend warnings about DO loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91424 Eric Gallager changed: What|Removed |Added Keywords||diagnostic CC||egallager at gcc dot gnu.org --- Comment #2 from Eric Gallager --- Also: - there's no option flag controlling the warning - the "2" location marker is a different color from the "1" location marker, if you have colorized output
[Bug target/90330] gcc 9.1.0 fails to install on macOS 10.14.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90330 --- Comment #29 from Matt Thompson --- Also, this did seem to build GCC: CC="/Users/mathomp4/installed/Core/gcc-gfortran/8.2.0/bin/gcc --sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk" CXX="/Users/mathomp4/installed/Core/gcc-gfortran/8.2.0/bin/g++ --sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk" ../gcc-9.2.0/configure --prefix=/Users/mathomp4/installed/Core/gcc-gfortran/9.2.0-820loaded --enable-languages=c,c++,fortran --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk |& tee configure.log So if nothing else, I have a way around the clang issue. I'll inform you on the updated prerequisites build.
[Bug target/90330] gcc 9.1.0 fails to install on macOS 10.14.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90330 --- Comment #28 from Matt Thompson --- (In reply to Iain Sandoe from comment #27) > That's fine - essentially, you're building them from source and therefore > don't need to worry about --with-gmp= configure options etc. > > For the record, I'm using GMP-6.1.2, MPFR-3.1.6, MPC-1.1.0 and ISL-0.20. Well, it looks like download_prerequisites might be behind the times: gmp='gmp-6.1.0.tar.bz2' mpfr='mpfr-3.1.4.tar.bz2' mpc='mpc-1.0.3.tar.gz' isl='isl-0.18.tar.bz2' I'm going to try and download the newest versions of all these and build with them. Maybe that'll help (though I don't see much/any C++ in them...).
[Bug target/83250] _mm256_zextsi128_si256 missing for AVX2 zero extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83250 --- Comment #7 from Jakub Jelinek --- Author: jakub Date: Mon Aug 12 15:55:56 2019 New Revision: 274313 URL: https://gcc.gnu.org/viewcvs?rev=274313=gcc=rev Log: PR target/83250 PR target/91340 * config/i386/avxintrin.h (_mm256_zextpd128_pd256, _mm256_zextps128_ps256, _mm256_zextsi128_si256): New intrinsics. * config/i386/avx512fintrin.h (_mm512_zextpd128_pd512, _mm512_zextps128_ps512, _mm512_zextsi128_si512, _mm512_zextpd256_pd512, _mm512_zextps256_ps512, _mm512_zextsi256_si512): Likewise. * gcc.target/i386/avx-typecast-1.c: New test. * gcc.target/i386/avx-typecast-2.c: New test. * gcc.target/i386/avx512f-typecast-2.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/avx-typecast-1.c trunk/gcc/testsuite/gcc.target/i386/avx-typecast-2.c trunk/gcc/testsuite/gcc.target/i386/avx512f-typecast-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/avx512fintrin.h trunk/gcc/config/i386/avxintrin.h trunk/gcc/testsuite/ChangeLog
[Bug target/91340] Missing AVX and AVX512 Intrinsics: Zero-Extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91340 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Mon Aug 12 15:55:56 2019 New Revision: 274313 URL: https://gcc.gnu.org/viewcvs?rev=274313=gcc=rev Log: PR target/83250 PR target/91340 * config/i386/avxintrin.h (_mm256_zextpd128_pd256, _mm256_zextps128_ps256, _mm256_zextsi128_si256): New intrinsics. * config/i386/avx512fintrin.h (_mm512_zextpd128_pd512, _mm512_zextps128_ps512, _mm512_zextsi128_si512, _mm512_zextpd256_pd512, _mm512_zextps256_ps512, _mm512_zextsi256_si512): Likewise. * gcc.target/i386/avx-typecast-1.c: New test. * gcc.target/i386/avx-typecast-2.c: New test. * gcc.target/i386/avx512f-typecast-2.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/avx-typecast-1.c trunk/gcc/testsuite/gcc.target/i386/avx-typecast-2.c trunk/gcc/testsuite/gcc.target/i386/avx512f-typecast-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/avx512fintrin.h trunk/gcc/config/i386/avxintrin.h trunk/gcc/testsuite/ChangeLog
[Bug c++/87108] Template partial specialization is ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87108
--- Comment #5 from Jonathan Wakely ---
Reduced:
template struct array { };
template struct A; // incomplete
template
struct A>
{
};
A> a;
91271.cc:10:13: error: aggregate ‘A > a’ has incomplete type and
cannot be defined
A> a;
^
Seems related to core issue 1647
[Bug c++/60679] class specialization not instantiated even though it is a better match than the primary template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60679 --- Comment #1 from Jonathan Wakely --- I think this is core issue 1647.
[Bug c++/91271] class template specialization on std::array failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91271
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |DUPLICATE
--- Comment #2 from Jonathan Wakely ---
Reduced:
template struct array { };
template struct A; // incomplete
template
struct A>
{
};
A> a;
91271.cc:10:13: error: aggregate ‘A > a’ has incomplete type and
cannot be defined
A> a;
^
*** This bug has been marked as a duplicate of bug 87108 ***
[Bug c++/87108] Template partial specialization is ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87108 Jonathan Wakely changed: What|Removed |Added CC||zhangbonian17 at 163 dot com --- Comment #4 from Jonathan Wakely --- *** Bug 91271 has been marked as a duplicate of this bug. ***
[Bug c++/91133] [7/8/9/10 Regression] Wrong "partial specialization is not more specialized than" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91133 Jonathan Wakely changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #1 from Jonathan Wakely --- Started to be rejected with r243868: Check that a partial specialization is more specialized. * pt.c (process_partial_specialization): Use get_partial_spec_bindings to check that the partial specialization is more specialized than the primary template.
[Bug c++/91133] [7/8/9/10 Regression] Wrong "partial specialization is not more specialized than" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91133 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-08-12 Ever confirmed|0 |1
[Bug c++/81043] [concepts] partially specializing on differing constraints gives cryptic error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81043 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-08-12 Ever confirmed|0 |1
[Bug c++/77781] [DR 1315] Some valid cases of partial specialization not accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77781 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-08-12 Ever confirmed|0 |1
[Bug target/90330] gcc 9.1.0 fails to install on macOS 10.14.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90330 --- Comment #27 from Iain Sandoe --- (In reply to Matt Thompson from comment #26) > (In reply to Iain Sandoe from comment #25) > > > > > Oh, yes. I was thinking of things we'll be building with this new GCC. I > > > just wish I could figure out the build-with-clang issue. It's like it's > > > missing some C++ library in its link line: > > > > build with clang should (does for me) work :) > > Lucky you. :) My laptop and gcc have some sort of shining thing going on. I > can't build gcc with Spack either. I will (later) repeat the exercise and paste exactly what I did - the Darwin18 machine is busy building / testing 9.2 bootstrapped with GCC .. checking for malformed PATH or things lurking in hash might spring to mind in the presence of such spooks... > > [as an aside, I do wonder where you are getting your GMP, MPFR, MPC and > > (optionally) ISL from ?] - for the record I usually build them in-tree and > > thus they are bootstrapped with the compiler. > > I get those guys by running: > > ./contrib/download_prerequisites > > when I first get the source. Maybe there's a better way? I think a recipe I > found long ago did that, so I've just done the same thing myself as it > seemed to work. That's fine - essentially, you're building them from source and therefore don't need to worry about --with-gmp= configure options etc. For the record, I'm using GMP-6.1.2, MPFR-3.1.6, MPC-1.1.0 and ISL-0.20.
[Bug c++/91407] Wnon-virtual-dtor should't fire for classes with operator delete=delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91407 Jonathan Wakely changed: What|Removed |Added Keywords||diagnostic --- Comment #1 from Jonathan Wakely --- Is there a reason you need to use -Wnon-virtual-dtor ? -Wdelete-non-virtual-dtor is generally more useful, with fewer false positives.
[Bug target/90330] gcc 9.1.0 fails to install on macOS 10.14.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90330 --- Comment #26 from Matt Thompson --- (In reply to Iain Sandoe from comment #25) > > > Thanks for the explanations. I'm trying a new build now with gcc-8.2.0 as > > the compiler passed to configure. > > > > Here's a(nother dumb) question: let's assume everything works. How exactly > > can one see what the sysroot is on a compiler? I.e., I could run "gcc-8.2.0 > > -xyz" and see it looks for /usr/include, but "gcc-9.2.0 -xyz" would show the > > /Library/Developer... > > gcc --print-sysroot > > gcc --help will show you the things that the driver can print for you and > point to other help lines that might be useful. Ah. Should have figure that out myself. :shame: > > > > Oh, yes. I was thinking of things we'll be building with this new GCC. I > > just wish I could figure out the build-with-clang issue. It's like it's > > missing some C++ library in its link line: > > build with clang should (does for me) work :) Lucky you. :) My laptop and gcc have some sort of shining thing going on. I can't build gcc with Spack either. > > > Now, I do think it's a bit odd that 'main.o' is *after* 'libbackend.a' as I > > usually put all my .o first then my .a when I build, but I think that's just > > stylistic. > > Actually, one difference from the "usual linker" rules on Darwin is that > ld64 will repeatedly re-visit presented libraries (in their presented order) > to satisfy symbols. There is no need for the dance of repeating .a files > several times. Huh. Good to know! > > > > Plus the C++ is so dense I don't know what this is looking for: > > > > std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)", > > referenced from: > > ipa_icf::sem_item_optimizer::worklist_push(ipa_icf::congruence_class*) > > in libbackend.a(ipa-icf.o) > > TBH, neither do I from that snippet - but I do think that a correctly > installed command line tools should just succeed with. > > configure --prefix=/somewhere/nice > --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk > > and use clang as the bootstrap compiler. > > [as an aside, I do wonder where you are getting your GMP, MPFR, MPC and > (optionally) ISL from ?] - for the record I usually build them in-tree and > thus they are bootstrapped with the compiler. I get those guys by running: ./contrib/download_prerequisites when I first get the source. Maybe there's a better way? I think a recipe I found long ago did that, so I've just done the same thing myself as it seemed to work.
[Bug tree-optimization/91419] [10 Regression]: gcc.dg/tree-ssa/pr91091-2.c, ssa-fre-61.c, ssa-fre-61.c with r273232
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91419
--- Comment #2 from Hans-Peter Nilsson ---
(In reply to Richard Biener from comment #1)
> Jeff also noticed this. The issue should happen on targets where
> alignof(int) != sizeof(int) since there we cannot conclude that with int *p,
> *q; the
> accesses *p and *q either overlap exactly (p == q) or they do not overlap.
Ew! I'd hope there was some language constraint forbidding such incomplete
overlap. Doesn't that mean a pointer to a structure can overlap another for
structures with piecewise similarity (for all targets)?
> Skimming through target-supports.exp I see natural_alignment_32 but that
> seems to be incomplete, not matching either of the affected targets of this
> bug:
>
> # Return 1 if types of size 32 bit or less are naturally aligned
> # (aligned to their type-size), 0 otherwise.
> #
> # This won't change for different subtargets so cache the result.
>
> proc check_effective_target_natural_alignment_32 { } {
> # FIXME: 32bit powerpc: guaranteed only if MASK_ALIGN_NATURAL/POWER.
> return [check_cached_effective_target_indexed natural_alignment_32 {
> if { ([istarget *-*-darwin*] && [is-effective-target lp64])
> || [istarget avr-*-*] } {
>return 0
> } else {
>return 1
> }
> }]
> }
>
> Thus known issue but no easy testsuite workaround sofar unless we fix the
> above. natural_alignment_32 is used in
> gcc.dg/ipa/propalign-?.c
> and some powerpc specific vector tests. Do the above also fail for you?
Yes.
At r274275 for ipa.exp:
Running /x/autotestgcc1/gcc/gcc/testsuite/gcc.dg/ipa/ipa.exp ...
FAIL: gcc.dg/ipa/pr77653.c scan-ipa-dump icf "Not unifying; alias cannot be
created; target is discardable"
FAIL: gcc.dg/ipa/propalign-1.c scan-ipa-dump cp "Adjusting align"
FAIL: gcc.dg/ipa/propalign-1.c scan-tree-dump-not optimized "fail_the_test"
FAIL: gcc.dg/ipa/propalign-2.c scan-ipa-dump cp "Adjusting align"
FAIL: gcc.dg/ipa/propalign-2.c scan-tree-dump-not optimized "fail_the_test"
FAIL: gcc.dg/ipa/propalign-5.c scan-ipa-dump cp "align: 2"
(These tests have failed at every auto-test-run, i.e. not regressions, i.e. I
haven't paid attention to them.)
> Does it make sense to have natural_alignment_16 (not sure about the targets
> you cite, but m68k would fall into this category).
For cris-elf there's byte alignment, not (u)int16_t-alignment, so I guess we'd
have to introduce another effective_target. But, I think it could better use a
compile-test and alignof as the default, rather than a target-list.
[Bug target/90330] gcc 9.1.0 fails to install on macOS 10.14.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90330 --- Comment #25 from Iain Sandoe --- (In reply to Matt Thompson from comment #24) > (In reply to Iain Sandoe from comment #23) > > --with-sysroot=/opt/iains/SDKs/darwin18-2 > > this is the sysroot that will be built into the compiler and used > > automatically when it's invoked (in this case, the one from XC10.2 tools) > > you would put /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk here. > Thanks for the explanations. I'm trying a new build now with gcc-8.2.0 as > the compiler passed to configure. > > Here's a(nother dumb) question: let's assume everything works. How exactly > can one see what the sysroot is on a compiler? I.e., I could run "gcc-8.2.0 > -xyz" and see it looks for /usr/include, but "gcc-9.2.0 -xyz" would show the > /Library/Developer... gcc --print-sysroot gcc --help will show you the things that the driver can print for you and point to other help lines that might be useful. > > --enable-version-specific-runtime-libs > > ^^^ I prefer to use this, since it ensures that libraries are installed into > > version-specific paths and thus should never clash on a rebuild/update of > > the compiler. > > Huh. I'll keep this in mind. I'm not adding it yet, but I'll put it in my > notes for this compiler build. right, it should not affect your result. > > > > > CC='gcc --sysroot=/opt/iains/SDKs/darwin18' > > CXX='g++ --sysroot=/opt/iains/SDKs/darwin18' > > > > ^^^ these are invoking a GCC-8.3 that's placed first in my PATH, but using > > an older SDK that doesn't have the "zippered" TBD files (since the ld64 on > > that GCC-8 doesn't grok those). > > > > > > > > > > > > > Note, looking at Homebrew again, I do see they also build with: > > > > > > > > > > make BOOT_LDFLAGS=-Wl,-headerpad_max_install_names > > > > > > > > That is solving a different problem - where it would seem that they > > > > intend > > > > to use install_name_tool to update the install paths and are allowing > > > > the > > > > maximum space. > > > > > > > > > would that help? > > > > > > > > very unlikely. > > > > > > Huh. This might actually be something that we've hit in CMake on other > > > codes, but if it's not needed, I won't do it for now. > > > > Perhaps, but it should not affect the compiler bootstrap or install - the > > paths for the built libraries are set to their install versions at build > > time - so they should be "long enough". > > Oh, yes. I was thinking of things we'll be building with this new GCC. I > just wish I could figure out the build-with-clang issue. It's like it's > missing some C++ library in its link line: build with clang should (does for me) work :) > Now, I do think it's a bit odd that 'main.o' is *after* 'libbackend.a' as I > usually put all my .o first then my .a when I build, but I think that's just > stylistic. Actually, one difference from the "usual linker" rules on Darwin is that ld64 will repeatedly re-visit presented libraries (in their presented order) to satisfy symbols. There is no need for the dance of repeating .a files several times. > Plus the C++ is so dense I don't know what this is looking for: > > std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)", > referenced from: > ipa_icf::sem_item_optimizer::worklist_push(ipa_icf::congruence_class*) > in libbackend.a(ipa-icf.o) TBH, neither do I from that snippet - but I do think that a correctly installed command line tools should just succeed with. configure --prefix=/somewhere/nice --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk and use clang as the bootstrap compiler. [as an aside, I do wonder where you are getting your GMP, MPFR, MPC and (optionally) ISL from ?] - for the record I usually build them in-tree and thus they are bootstrapped with the compiler.
[Bug target/90330] gcc 9.1.0 fails to install on macOS 10.14.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90330 --- Comment #24 from Matt Thompson --- (In reply to Iain Sandoe from comment #23) > --with-sysroot=/opt/iains/SDKs/darwin18-2 > this is the sysroot that will be built into the compiler and used > automatically when it's invoked (in this case, the one from XC10.2 tools) > you would put /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk here. Iain, Thanks for the explanations. I'm trying a new build now with gcc-8.2.0 as the compiler passed to configure. Here's a(nother dumb) question: let's assume everything works. How exactly can one see what the sysroot is on a compiler? I.e., I could run "gcc-8.2.0 -xyz" and see it looks for /usr/include, but "gcc-9.2.0 -xyz" would show the /Library/Developer... > --enable-version-specific-runtime-libs > ^^^ I prefer to use this, since it ensures that libraries are installed into > version-specific paths and thus should never clash on a rebuild/update of > the compiler. Huh. I'll keep this in mind. I'm not adding it yet, but I'll put it in my notes for this compiler build. > > CC='gcc --sysroot=/opt/iains/SDKs/darwin18' > CXX='g++ --sysroot=/opt/iains/SDKs/darwin18' > > ^^^ these are invoking a GCC-8.3 that's placed first in my PATH, but using > an older SDK that doesn't have the "zippered" TBD files (since the ld64 on > that GCC-8 doesn't grok those). > > > > > > > Note, looking at Homebrew again, I do see they also build with: > > > > > > > > make BOOT_LDFLAGS=-Wl,-headerpad_max_install_names > > > > > > That is solving a different problem - where it would seem that they intend > > > to use install_name_tool to update the install paths and are allowing the > > > maximum space. > > > > > > > would that help? > > > > > > very unlikely. > > > > Huh. This might actually be something that we've hit in CMake on other > > codes, but if it's not needed, I won't do it for now. > > Perhaps, but it should not affect the compiler bootstrap or install - the > paths for the built libraries are set to their install versions at build > time - so they should be "long enough". Oh, yes. I was thinking of things we'll be building with this new GCC. I just wish I could figure out the build-with-clang issue. It's like it's missing some C++ library in its link line: c-family/c-spellcheck.o i386-c.o darwin-c.o \ cc1-checksum.o libbackend.a main.o libcommon-target.a libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a ./../intl/libintl.a -liconv ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -L/Users/mathomp4/src/GCC/gcc-9.2.0-BUILD/./isl/.libs -lisl -L/Users/mathomp4/src/GCC/gcc-9.2.0-BUILD/./gmp/.libs -L/Users/mathomp4/src/GCC/gcc-9.2.0-BUILD/./mpfr/src/.libs -L/Users/mathomp4/src/GCC/gcc-9.2.0-BUILD/./mpc/src/.libs -lmpc -lmpfr -lgmp -L./../zlib -lz l Now, I do think it's a bit odd that 'main.o' is *after* 'libbackend.a' as I usually put all my .o first then my .a when I build, but I think that's just stylistic. And there's the usual autotools business of libraries repeating (libcommon, libcpp). Plus the C++ is so dense I don't know what this is looking for: std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)", referenced from: ipa_icf::sem_item_optimizer::worklist_push(ipa_icf::congruence_class*) in libbackend.a(ipa-icf.o) And my usual suggestion of "just add -lstd++ or lc++" when I see C++ link issues probably isn't right when you might be building those libraries! :)
[Bug tree-optimization/91109] [10 regression][arm] gcc.c-torture/execute/20040709-1.c fails since r273135
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91109
--- Comment #12 from Christophe Lyon ---
Indeed, although r274163 fixes the problem I reported, it also introduces a
regression when compiling the very same testcase but adding -mthumb:
FAIL: gcc.c-torture/execute/20040709-1.c -O2 (internal compiler error)
FAIL: gcc.c-torture/execute/20040709-1.c -O2 -flto -fno-use-linker-plugin
-flto-partition=none (internal compiler error)
FAIL: gcc.c-torture/execute/20040709-3.c -O2 (internal compiler error)
FAIL: gcc.c-torture/execute/20040709-3.c -O2 -flto -fno-use-linker-plugin
-flto-partition=none (internal compiler error)
FAIL: gcc.c-torture/execute/20040709-3.c -O3 -g (internal compiler error)
My gcc.log says:
/gcc/testsuite/gcc.c-torture/execute/20040709-1.c: In function 'retmeD':
/gcc/testsuite/gcc.c-torture/execute/20040709-1.c:19:10: note: parameter
passing for argument of type 'struct D' changed in GCC 9.1
/gcc/testsuite/gcc.c-torture/execute/20040709-1.c:95:64: note: in expansion of
macro 'T'
/gcc/testsuite/gcc.c-torture/execute/20040709-1.c: In function 'testI':
/gcc/testsuite/gcc.c-torture/execute/20040709-1.c:100:75: error: insn does not
satisfy its constraints:
/gcc/testsuite/gcc.c-torture/execute/20040709-1.c:55:10: note: in definition of
macro 'T'
(insn 311 122 309 8 (parallel [
(set (reg:SI 3 r3 [266])
(truncate:SI (lshiftrt:DI (mult:DI (zero_extend:DI (reg:SI 10
r10 [265]))
(zero_extend:DI (reg:SI 8 r8 [267])))
(const_int 32 [0x20]
(clobber (scratch:SI))
]) "/gcc/testsuite/gcc.c-torture/execute/20040709-1.c":100:73 70
{*umulsi3_highpart_v6}
(nil))
during RTL pass: reload
/gcc/testsuite/gcc.c-torture/execute/20040709-1.c:100:75: internal compiler
error: in extract_constrain_insn, at recog.c:2211
/gcc/testsuite/gcc.c-torture/execute/20040709-1.c:55:10: note: in definition of
macro 'T'
0x5a7d5d _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/gcc/rtl-error.c:108
0x5a7d83 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/gcc/rtl-error.c:119
0xb7b85d extract_constrain_insn(rtx_insn*)
/gcc/recog.c:2211
0xa629b7 check_rtl
/gcc/lra.c:2184
0xa67def lra(_IO_FILE*)
/gcc/lra.c:2622
0xa19f49 do_reload
/gcc/ira.c:5522
0xa19f49 execute
/gcc/ira.c:5706
[Bug target/90330] gcc 9.1.0 fails to install on macOS 10.14.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90330 --- Comment #23 from Iain Sandoe --- (In reply to Matt Thompson from comment #22) > (In reply to Iain Sandoe from comment #19) > > (In reply to Matt Thompson from comment #17) > > > > I have tried the same configure line with gcc 8.2.0 loaded, but I get: > > > > > > checking whether we are cross compiling... configure: error: in > > > `/Users/mathomp4/src/GCC/gcc-9.2.0-BUILD-820loaded': > > > configure: error: cannot run C compiled programs. > > > If you meant to cross compile, use `--host'. > > > See `config.log' for more details > > > > If you want to use GCC as the bootstrap and it was built for a system with > > /usr/include [and now that directory has been removed] then you need to > > supply it with a sysroot explicitly as I do. > > > > CC="gcc-8-x --sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk" > > CXX="g++-8.x --sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk" > > (on the configure line) > > Hmm. Okay. I'll give this a shot. I suppose I want to use clang just because > I'll have to keep bootstrapping with a previous version forever, right? I use GCC (most of the time) because (in general) I'm bootstrapping all languages including Ada (which needs an Ada compiler to bootstrap). IFF you're interest is c,c++,fortran then you can use clang or GCC as the bootstrap. > And is this done at the configure stage? Make stage? My autotools-fu is a > bit weak. see: https://gcc.gnu.org/ml/gcc-testresults/2019-08/msg00608.html as a "general" case of configuration with different sysroots for the built and bootstrap compilers. a breakdown of the configure line with some notes below .../configure --prefix=/where/you/want/it --target=x86_64-apple-darwin18 --host=x86_64-apple-darwin18 --build=x86_64-apple-darwin18 ^^^ you can drop these and it will figure out the version --with-sysroot=/opt/iains/SDKs/darwin18-2 this is the sysroot that will be built into the compiler and used automatically when it's invoked (in this case, the one from XC10.2 tools) you would put /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk here. --with-ld=/opt/iains/x86_64-apple-darwin/xtools-2-2-3/bin/ld --with-as=/opt/iains/x86_64-apple-darwin/xtools-2-2-3/bin/llas ^^^ you can ignore these, I have separate builds of ld64 and an assembler with some non-compiler bug fixes --with-cpu=corei7 --disable-nls --with-iconv-prefix=/usr ^^^ you can ignore these too --enable-languages=all ^^^ likewise --enable-version-specific-runtime-libs ^^^ I prefer to use this, since it ensures that libraries are installed into version-specific paths and thus should never clash on a rebuild/update of the compiler. CC='gcc --sysroot=/opt/iains/SDKs/darwin18' CXX='g++ --sysroot=/opt/iains/SDKs/darwin18' ^^^ these are invoking a GCC-8.3 that's placed first in my PATH, but using an older SDK that doesn't have the "zippered" TBD files (since the ld64 on that GCC-8 doesn't grok those). > > > Note, looking at Homebrew again, I do see they also build with: > > > > > > make BOOT_LDFLAGS=-Wl,-headerpad_max_install_names > > > > That is solving a different problem - where it would seem that they intend > > to use install_name_tool to update the install paths and are allowing the > > maximum space. > > > > > would that help? > > > > very unlikely. > > Huh. This might actually be something that we've hit in CMake on other > codes, but if it's not needed, I won't do it for now. Perhaps, but it should not affect the compiler bootstrap or install - the paths for the built libraries are set to their install versions at build time - so they should be "long enough".
[Bug fortran/91300] Wrong runtime error message with allocate and errmsg=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91300 Janne Blomqvist changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-08-12 CC||jb at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Janne Blomqvist --- AFAICT this is a valid bug report, albeit maybe not of the highest priority. The problem is that the code in the fortran frontend for handling this is a flaming mess. Without stat=, it properly generates a call to an error handling function in libgfortran, which examines errno and uses strerror() (or depending on what is available on the target, strerror_l() or strerror_r() ) to convert errno to a string describing the error why the allocation fails. However, if stat= and errmsg= are present, the only possible errmsg= value is a string literal with the value "Attempt to allocate an allocated object", which in this case is not correct. GFortran should do something similar to the allocate without stat= also in this case, that is, use one of the strerror() family functions to translate the errno value set by malloc() to a useful error message. (In reply to zed.three from comment #2) > The perceived wisdom is that it is best > practice to always use `stat` with `allocate`, and the addition of `errmsg` > now gives us something portable to hopefully get a sensible error message. Perceived wisdom is wrong, then, if all you do with stat= is print the errmsg= error message and stop the program, because that's what the compiler already does for you if you omit the stat= specifier (or, modulo bugs like this one, should do). allocate(stat=) is useful only if you can somehow recover usefully from failing to allocate. E.g. switch to another less memory-hungry algorithm, sparser grid, or whatever. And even so, thanks to overcommit in many operating systems such as Linux, this isn't likely to work usefully anyway. > I'm certainly not saying this is a show-stopper, but I don't think it's at > all stupid to expect useful error messages. I agree.
[Bug target/91323] LTGT rtx produces UCOMISS instead of COMISS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91323 Christophe Lyon changed: What|Removed |Added Target|x86_64-*-*, i?86-*-*|x86_64-*-*, i?86-*-*, ||aarch64-linux-gnu, ||arm*-linux-gnueabihf CC||clyon at gcc dot gnu.org --- Comment #13 from Christophe Lyon --- The new test (gcc.dg/torture/pr91323.c) fails on aarch64-linux-gnu and arm*-linux-gnueabihf
[Bug tree-optimization/91425] Ordered compares aren't optimised
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91425 --- Comment #7 from Marc Glisse --- (In reply to Segher Boessenkool from comment #6) > Maybe we should make "is this an ordered comparison" separate from the > actual comparison code. I was considering having a single .IFN_FENV_CMP (a, b, opts) where opts would have one bit to say if it is true when a and b are unordered, one for ab, one or two to know if it may (or must) trap / set exception flags, etc.
[Bug target/90330] gcc 9.1.0 fails to install on macOS 10.14.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90330 --- Comment #22 from Matt Thompson --- (In reply to Iain Sandoe from comment #19) > (In reply to Matt Thompson from comment #17) > > > > b) (remind me) what is the "--with-native-system-header-dir=/usr/include" > > > meant to provide? It seems like you are maybe mixing cross-configuration > > > options with native ones... > > > > This was my attempt to try to work around the fact that Apple no longer > > supplies a /usr/include: > > > > https://developer.apple.com/documentation/xcode_release_notes/ > > xcode_10_release_notes#3035624 > > > > Now, I'm not sure that gcc itself needs /usr/include, but many of the > > libraries and more I compile with gcc seem to assume it. And I've gotten to > > the point where I just couldn't figure out how to pass '-isysroot' down to > > code like f2py (gcc is called by f2py but f2py only passes down Fortran > > flags. And I just *cannot* get our CMake system to pass > > CFLAGS='-isysroot...' to the gcc call within f2py). > > > > So, I thought I'd look around and saw that Homebrew built a little > > differently: > > > > https://github.com/Homebrew/homebrew-core/blob/master/Formula/gcc.rb > > > > adding: > > elsif MacOS.version >= :mojave > > # System headers are no longer located in /usr/include > > args << "--with-native-system-header-dir=/usr/include" > > args << > > "--with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk" > > I don't know what they intended to achieve with this. There *is* one > gremlin with the sysroot being > /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk which is that > /usr/local/include is still a usable directory and needs to be searched > *without* prepending the sysroot. This is something I want to fix during > the next couple of months - but isn't necessary *unless* you've installed > packages into /usr/local that you want to use. > > (A workaround is to add -I... so it shouldn't be a show-stopper) Luckily (?) for me, there is nothing in my /usr/local/include save for Fuse headers. Since I can't install Homebrew in its default /usr/local (I do it in user space), it's pretty dang pure on my system! > > > > My hope was perhaps this would "embed" in gcc the fact that sysroot is not > > in /usr/include but was in > > /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include and so f2py > > would work again. > > > > Is it just the --with-sysroot that I'd need to "hardcode" a gcc with that > > sysroot? > > the --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk > should "just work" (modulo the gotcha about /usr/local mentioned) with no > need for any additional magic. Ooh. Okay. I'll give that a shot. > > > I have tried the same configure line with gcc 8.2.0 loaded, but I get: > > > > checking whether we are cross compiling... configure: error: in > > `/Users/mathomp4/src/GCC/gcc-9.2.0-BUILD-820loaded': > > configure: error: cannot run C compiled programs. > > If you meant to cross compile, use `--host'. > > See `config.log' for more details > > If you want to use GCC as the bootstrap and it was built for a system with > /usr/include [and now that directory has been removed] then you need to > supply it with a sysroot explicitly as I do. > > CC="gcc-8-x --sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk" > CXX="g++-8.x --sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk" > (on the configure line) Hmm. Okay. I'll give this a shot. I suppose I want to use clang just because I'll have to keep bootstrapping with a previous version forever, right? And is this done at the configure stage? Make stage? My autotools-fu is a bit weak. > > > > Note, looking at Homebrew again, I do see they also build with: > > > > make BOOT_LDFLAGS=-Wl,-headerpad_max_install_names > > That is solving a different problem - where it would seem that they intend > to use install_name_tool to update the install paths and are allowing the > maximum space. > > > would that help? > > very unlikely. Huh. This might actually be something that we've hit in CMake on other codes, but if it's not needed, I won't do it for now.
[Bug target/90330] gcc 9.1.0 fails to install on macOS 10.14.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90330 --- Comment #21 from Matt Thompson --- (In reply to Iain Sandoe from comment #20) > (In reply to Iain Sandoe from comment #19) > > (In reply to Matt Thompson from comment #17) > > > > > > Now, I'm not sure that gcc itself needs /usr/include, but many of the > > > libraries and more I compile with gcc seem to assume it. And I've gotten > > > to > > > the point where I just couldn't figure out how to pass '-isysroot' down to > > > code like f2py (gcc is called by f2py but f2py only passes down Fortran > > > flags. And I just *cannot* get our CMake system to pass > > > CFLAGS='-isysroot...' to the gcc call within f2py). > > Packages that assume /usr/include should "just work" with the sysrooted > compiler without any extra magic (I build LLVM and its associated things > with GCC and a sysroot all the time). cmake can take a > CMAKE_OSX_SYSROOT=/path/to/sysroot if you need to be explicit. > > otherwise, I'd expect it to honour CMAKE_CFLAGS= and CMAKE_CXXFLAGS= (but...) Iain, Oh, no, CMake is smart. It's f2py that isn't smart. It doesn't really understand its own environment. CMake is smart and sees it's on Darwin and does CMAKE_OSX_SYSROOT so it uses it in all the C code it compiles. The problem is f2py deep in its own code base is calling $CC and it is too removed from the CMake system. Running CFLAGS='-isysroot...' f2py does work, but CMake is munging the freaking call so it gets things like: CFLAGS='\-isysroot \'/Library...' and I'm not enough of a CMake guru to fix it. Luckily, my boss (who is) will be back from travel soon.
[Bug target/90330] gcc 9.1.0 fails to install on macOS 10.14.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90330 --- Comment #20 from Iain Sandoe --- (In reply to Iain Sandoe from comment #19) > (In reply to Matt Thompson from comment #17) > > > Now, I'm not sure that gcc itself needs /usr/include, but many of the > > libraries and more I compile with gcc seem to assume it. And I've gotten to > > the point where I just couldn't figure out how to pass '-isysroot' down to > > code like f2py (gcc is called by f2py but f2py only passes down Fortran > > flags. And I just *cannot* get our CMake system to pass > > CFLAGS='-isysroot...' to the gcc call within f2py). Packages that assume /usr/include should "just work" with the sysrooted compiler without any extra magic (I build LLVM and its associated things with GCC and a sysroot all the time). cmake can take a CMAKE_OSX_SYSROOT=/path/to/sysroot if you need to be explicit. otherwise, I'd expect it to honour CMAKE_CFLAGS= and CMAKE_CXXFLAGS= (but...)
[Bug target/90330] gcc 9.1.0 fails to install on macOS 10.14.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90330 --- Comment #19 from Iain Sandoe --- (In reply to Matt Thompson from comment #17) > > b) (remind me) what is the "--with-native-system-header-dir=/usr/include" > > meant to provide? It seems like you are maybe mixing cross-configuration > > options with native ones... > > This was my attempt to try to work around the fact that Apple no longer > supplies a /usr/include: > > https://developer.apple.com/documentation/xcode_release_notes/ > xcode_10_release_notes#3035624 > > Now, I'm not sure that gcc itself needs /usr/include, but many of the > libraries and more I compile with gcc seem to assume it. And I've gotten to > the point where I just couldn't figure out how to pass '-isysroot' down to > code like f2py (gcc is called by f2py but f2py only passes down Fortran > flags. And I just *cannot* get our CMake system to pass > CFLAGS='-isysroot...' to the gcc call within f2py). > > So, I thought I'd look around and saw that Homebrew built a little > differently: > > https://github.com/Homebrew/homebrew-core/blob/master/Formula/gcc.rb > > adding: > elsif MacOS.version >= :mojave > # System headers are no longer located in /usr/include > args << "--with-native-system-header-dir=/usr/include" > args << > "--with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk" I don't know what they intended to achieve with this. There *is* one gremlin with the sysroot being /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk which is that /usr/local/include is still a usable directory and needs to be searched *without* prepending the sysroot. This is something I want to fix during the next couple of months - but isn't necessary *unless* you've installed packages into /usr/local that you want to use. (A workaround is to add -I... so it shouldn't be a show-stopper) > My hope was perhaps this would "embed" in gcc the fact that sysroot is not > in /usr/include but was in > /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include and so f2py > would work again. > > Is it just the --with-sysroot that I'd need to "hardcode" a gcc with that > sysroot? the --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk should "just work" (modulo the gotcha about /usr/local mentioned) with no need for any additional magic. > I have tried the same configure line with gcc 8.2.0 loaded, but I get: > > checking whether we are cross compiling... configure: error: in > `/Users/mathomp4/src/GCC/gcc-9.2.0-BUILD-820loaded': > configure: error: cannot run C compiled programs. > If you meant to cross compile, use `--host'. > See `config.log' for more details If you want to use GCC as the bootstrap and it was built for a system with /usr/include [and now that directory has been removed] then you need to supply it with a sysroot explicitly as I do. CC="gcc-8-x --sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk" CXX="g++-8.x --sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk" (on the configure line) > Note, looking at Homebrew again, I do see they also build with: > > make BOOT_LDFLAGS=-Wl,-headerpad_max_install_names That is solving a different problem - where it would seem that they intend to use install_name_tool to update the install paths and are allowing the maximum space. > would that help? very unlikely.
[Bug target/90330] gcc 9.1.0 fails to install on macOS 10.14.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90330 --- Comment #18 from Iain Sandoe --- FWIW: this was my clang-bootstrapped test of the release candidate: https://gcc.gnu.org/ml/gcc-testresults/2019-08/msg00645.html --prefix=/opt/iains/x86_64-apple-darwin18/gcc-9-wip --with-sysroot=/opt/iains/SDKs/darwin18-2 --enable-languages=all CC='clang --sysroot=/opt/iains/SDKs/darwin18' CXX='clang++ --sysroot=/opt/iains/SDKs/darwin18' NOTE: if you have the command line tools installed you do not need to specify CC and CXX. The "--with-sysroot=/opt/iains/SDKs/darwin18-2 " is pointing to exactly the same SDK you have. i.e. I would expect --prefix=/somewhere/you/want/it --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk to be completely sufficient. (will review your comments in a moment)
[Bug target/83250] _mm256_zextsi128_si256 missing for AVX2 zero extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83250
--- Comment #6 from Jakub Jelinek ---
That said, I think we should eventually try to add some define_insn_and_split
that would help with generating better code e.g. on
#include
__m256d
foo1 (__m128d __A)
{
return _mm256_insertf128_pd (_mm256_castpd128_pd256 (__A), _mm_setzero_pd (),
1);
}
__m256d
foo2 (__m128d __A)
{
return (__m256d) __builtin_shuffle (_mm256_castpd128_pd256 (__A),
_mm256_setzero_pd (),
(__v4di) { 0, 1, 4, 5 });
}
__m256d
foo3 (__m128d __A)
{
return __extension__ (__m256d) { __A[0], __A[1], 0.0, 0.0 };
}
__m256
foo4 (__m128 __A)
{
return _mm256_insertf128_ps (_mm256_castps128_ps256 (__A), _mm_setzero_ps (),
1);
}
__m256
foo5 (__m128 __A)
{
return (__m256) __builtin_shuffle (_mm256_castps128_ps256 (__A),
_mm256_setzero_ps (),
(__v8si) { 0, 1, 2, 3, 8, 9, 10, 11 });
}
__m256
foo6 (__m128 __A)
{
return __extension__ (__m256) { __A[0], __A[1], __A[2], __A[3],
0.0f, 0.0f, 0.0f, 0.0f };
}
__m256i
foo7 (__m128i __A)
{
return _mm256_insertf128_si256 (_mm256_castsi128_si256 (__A),
_mm_setzero_si128 (),
1);
}
__m256i
foo8 (__m128i __A)
{
return (__m256i) __builtin_shuffle (_mm256_castsi128_si256 (__A),
_mm256_setzero_si256 (),
(__v4di) { 0, 1, 4, 5 });
}
__m256i
foo9 (__m128i __A)
{
return __extension__ (__m256i) { __A[0], __A[1], 0, 0 };
}
__m256d
foo10 (__m128d __A)
{
return _mm256_insertf128_pd (_mm256_setzero_pd (), __A, 0);
}
__m256
foo11 (__m128 __A)
{
return _mm256_insertf128_ps (_mm256_setzero_ps (), __A, 0);
}
__m256i
foo12 (__m128i __A)
{
return _mm256_insertf128_si256 (_mm256_setzero_si256 (), __A, 0);
}
and
#include
__m512d
foo1 (__m256d __A)
{
return _mm512_insertf64x4 (_mm512_castpd256_pd512 (__A),
_mm256_setzero_pd (), 1);
}
__m512
foo2 (__m256 __A)
{
return (__m512) _mm512_insertf64x4 (_mm512_castpd256_pd512 ((__m256d) __A),
_mm256_setzero_pd (), 1);
}
__m512i
foo3 (__m256i __A)
{
return _mm512_inserti64x4 (_mm512_castsi256_si512 (__A),
_mm256_setzero_si256 (), 1);
}
__m512d
foo4 (__m256d __A)
{
return _mm512_insertf32x4 (_mm512_castps128_ps512 ((__m256) __A),
_mm_setzero_ps (), 1);
}
__m512
foo5 (__m256 __A)
{
return (__m512) _mm512_insertf64x4 (_mm512_castpd256_pd512 ((__m256d) __A),
_mm256_setzero_pd (), 1);
}
__m512i
foo6 (__m256i __A)
{
return _mm512_inserti64x4 (_mm512_castsi256_si512 (__A),
_mm256_setzero_si256 (), 1);
}
WIP patch is:
--- gcc/config/i386/sse.md.jj 2019-08-05 12:25:34.477667658 +0200
+++ gcc/config/i386/sse.md 2019-08-12 14:06:44.748772344 +0200
@@ -20784,6 +20784,35 @@ (define_insn "vec_set_hi_v32qi"
(set_attr "prefix" "vex,evex")
(set_attr "mode" "OI")])
+(define_insn_and_split "*vec_set_hi__cast"
+ [(set (match_operand:VI8F_256 0 "register_operand" "=Yv")
+ (vec_concat:VI8F_256
+ (vec_select:
+ (unspec:VI8F_256 [(match_operand: 1
+ "register_operand" "vm")]
+UNSPEC_CAST)
+ (parallel [(const_int 0) (const_int 1)]))
+ (match_operand: 2 "const0_operand" "C")))]
+ "TARGET_AVX"
+ "#"
+ ""
+ [(set (match_dup 0) (vec_concat:VI8F_256 (match_dup 1) (match_dup 2)))])
+
+(define_insn_and_split "*vec_set_hi__cast"
+ [(set (match_operand:VI4F_256 0 "register_operand" "=Yv")
+ (vec_concat:VI4F_256
+ (vec_select:
+ (unspec:VI4F_256 [(match_operand: 1
+ "register_operand" "vm")]
+UNSPEC_CAST)
+ (parallel [(const_int 0) (const_int 1)
+ (const_int 2) (const_int 3)]))
+ (match_operand: 2 "const0_operand" "C")))]
+ "TARGET_AVX"
+ "#"
+ ""
+ [(set (match_dup 0) (vec_concat:VI4F_256 (match_dup 1) (match_dup 2)))])
+
(define_insn "_maskload"
[(set (match_operand:V48_AVX2 0 "register_operand" "=x")
(unspec:V48_AVX2
that improves foo1, foo4 and foo7 in the first testcase above.
If not anything, at least the cases with { __A[0], __A[1], __A[2], ..., 0, 0,
0, ... } should be handled as a priority, as that can happen even with
generic vector code without any intrinsics.
[Bug target/90330] gcc 9.1.0 fails to install on macOS 10.14.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90330 --- Comment #17 from Matt Thompson --- Iain, The (In reply to Iain Sandoe from comment #16) > Hi Matt, > > (In reply to Matt Thompson from comment #15) > > > I seem to still have issues. I downloaded 9.2.0 this morning and built it > > with: > > > > $ ../gcc-9.2.0/configure > > --prefix=/Users/mathomp4/installed/Core/gcc-gfortran/9.2.0 > > --enable-languages=c,c++,fortran --disable-multilib > > --with-native-system-header-dir=/usr/include > > --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk |& tee > > configure.log > > $ make -j4 |& tee make.log > > $ make install |& tee makeinstall.log > > a) --disable-multilib should no longer be needed [that PR was fixed on 9.2] Okay. I'll remove that. > > b) (remind me) what is the "--with-native-system-header-dir=/usr/include" > meant to provide? It seems like you are maybe mixing cross-configuration > options with native ones... This was my attempt to try to work around the fact that Apple no longer supplies a /usr/include: https://developer.apple.com/documentation/xcode_release_notes/xcode_10_release_notes#3035624 Now, I'm not sure that gcc itself needs /usr/include, but many of the libraries and more I compile with gcc seem to assume it. And I've gotten to the point where I just couldn't figure out how to pass '-isysroot' down to code like f2py (gcc is called by f2py but f2py only passes down Fortran flags. And I just *cannot* get our CMake system to pass CFLAGS='-isysroot...' to the gcc call within f2py). So, I thought I'd look around and saw that Homebrew built a little differently: https://github.com/Homebrew/homebrew-core/blob/master/Formula/gcc.rb adding: elsif MacOS.version >= :mojave # System headers are no longer located in /usr/include args << "--with-native-system-header-dir=/usr/include" args << "--with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk" My hope was perhaps this would "embed" in gcc the fact that sysroot is not in /usr/include but was in /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include and so f2py would work again. Is it just the --with-sysroot that I'd need to "hardcode" a gcc with that sysroot? I have tried the same configure line with gcc 8.2.0 loaded, but I get: checking whether we are cross compiling... configure: error: in `/Users/mathomp4/src/GCC/gcc-9.2.0-BUILD-820loaded': configure: error: cannot run C compiled programs. If you meant to cross compile, use `--host'. See `config.log' for more details So that's not right. Now, that said, I can run that same link step that fails with clang g++ and *explicitly* use g++-8.2.0 and it seems to work: /Users/mathomp4/installed/Core/gcc-gfortran/8.2.0/bin/g++ -std=gnu++98-g -O2 -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -o cc1plus \ cp/cp-lang.o c-family/stub-objc.o cp/call.o cp/class.o cp/constexpr.o cp/constraint.o cp/cp-gimplify.o cp/cp-objcp-common.o cp/cp-ubsan.o cp/cvt.o cp/cxx-pretty-print.o cp/decl.o cp/decl2.o cp/dump.o cp/error.o cp/except.o cp/expr.o cp/friend.o cp/init.o cp/lambda.o cp/lex.o cp/logic.o cp/mangle.o cp/method.o cp/name-lookup.o cp/optimize.o cp/parser.o cp/pt.o cp/ptree.o cp/repo.o cp/rtti.o cp/search.o cp/semantics.o cp/tree.o cp/typeck.o cp/typeck2.o cp/vtable-class-hierarchy.o attribs.o incpath.o c-family/c-common.o c-family/c-cppbuiltin.o c-family/c-dump.o c-family/c-format.o c-family/c-gimplify.o c-family/c-indentation.o c-family/c-lex.o c-family/c-omp.o c-family/c-opts.o c-family/c-pch.o c-family/c-ppoutput.o c-family/c-pragma.o c-family/c-pretty-print.o c-family/c-semantics.o c-family/c-ada-spec.o c-family/c-ubsan.o c-family/known-headers.o c-family/c-attribs.o c-family/c-warn.o c-family/c-spellcheck.o i386-c.o darwin-c.o cc1plus-checksum.o libbackend.a main.o libcommon-target.a libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a ./../intl/libintl.a -liconv ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -L/Users/mathomp4/src/GCC/gcc-9.2.0-BUILD/./isl/.libs -lisl -L/Users/mathomp4/src/GCC/gcc-9.2.0-BUILD/./gmp/.libs -L/Users/mathomp4/src/GCC/gcc-9.2.0-BUILD/./mpfr/src/.libs -L/Users/mathomp4/src/GCC/gcc-9.2.0-BUILD/./mpc/src/.libs -lmpc -lmpfr -lgmp -L./../zlib -lz After that if i unload the gcc 8.2.0 module, the make install succeeds. Note, looking at Homebrew again, I do see they also build with: make BOOT_LDFLAGS=-Wl,-headerpad_max_install_names would that help? > > > I was hoping 9.2.0 would fix this. :( > > I am very happy to try and help you fix this - and to patch trunk / 9.3 if > there's a bug - but right now the builds I've done (both with GCC as > bootstrap - for Ada and with clang
[Bug tree-optimization/91425] Ordered compares aren't optimised
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91425 --- Comment #6 from Segher Boessenkool --- Maybe we should make "is this an ordered comparison" separate from the actual comparison code. That would make things quite a bit simpler as well. Maybe we can pull that through to RTL, as well?
[Bug target/83250] _mm256_zextsi128_si256 missing for AVX2 zero extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83250 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Created attachment 46703 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46703=edit gcc10-pr83250.patch Untested patch that emits reasonable code (only small issue is that vmovaps instead of vmovapd or vice versa is emitted in one avx512f case each, as the intrinsics it would need to use are avx512dq only, even though in the end it folds eventually down to an instruction avx512f handles.
[Bug tree-optimization/91425] Ordered compares aren't optimised
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91425 --- Comment #5 from Richard Biener --- (In reply to Segher Boessenkool from comment #4) > (In reply to Richard Biener from comment #1) > > where we end up with > > > >[local count: 1073741824]: > > if (a_3(D) < b_4(D)) > > goto ; [50.00%] > > else > > goto ; [50.00%] > > > >[local count: 536870913]: > > _6 = a_3(D) > b_4(D); > > > >[local count: 1073741824]: > > # prephitmp_8 = PHI <_6(3), 1(2)> > > > > instead of != compares. > > instead of <> compares (LTGT). With -ffast-math we should get the NE as > you say, and that works fine. Ah, OK. So there it's ifcombine doing the thing thus enhancing that would work (only after it failed phiopt comes along and replaces the inner conditional with the value compute). ifcombine does use maybe_fold_and_comparisons, indeed relying on invert_tree_comparison as well.
[Bug target/90330] gcc 9.1.0 fails to install on macOS 10.14.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90330 --- Comment #16 from Iain Sandoe --- Hi Matt, (In reply to Matt Thompson from comment #15) > I seem to still have issues. I downloaded 9.2.0 this morning and built it > with: > > $ ../gcc-9.2.0/configure > --prefix=/Users/mathomp4/installed/Core/gcc-gfortran/9.2.0 > --enable-languages=c,c++,fortran --disable-multilib > --with-native-system-header-dir=/usr/include > --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk |& tee > configure.log > $ make -j4 |& tee make.log > $ make install |& tee makeinstall.log a) --disable-multilib should no longer be needed [that PR was fixed on 9.2] b) (remind me) what is the "--with-native-system-header-dir=/usr/include" meant to provide? It seems like you are maybe mixing cross-configuration options with native ones... > I was hoping 9.2.0 would fix this. :( I am very happy to try and help you fix this - and to patch trunk / 9.3 if there's a bug - but right now the builds I've done (both with GCC as bootstrap - for Ada and with clang as bootstrap) have succeeded on Darwin9..Darwin18.
[Bug driver/91130] [9 Regression] -MF clashes with -flto on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||9.2.1 Resolution|--- |FIXED Known to fail||9.2.0 --- Comment #45 from Richard Biener --- Fixed.
[Bug lto/91375] [8/9 Regression] ICE on valid code in subbinfo_with_vtable_at_offset at ipa-devirt.c:2760 since r256685
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91375 --- Comment #6 from Richard Biener --- Author: rguenth Date: Mon Aug 12 12:59:08 2019 New Revision: 274311 URL: https://gcc.gnu.org/viewcvs?rev=274311=gcc=rev Log: 2019-08-12 Richard Biener Backport from mainline 2019-08-12 Richard Biener PR lto/91375 * tree.c (free_lang_data_in_type): Do not free TYPE_BINFO dependent on flag_devirtualize. 2019-08-12 Richard Biener PR driver/91130 * lto-wrapper.c (get_options_from_collect_gcc_options): Remove lang_mask option, always use CL_DRIVER. (find_and_merge_options): Adjust. (run_gcc): Likewise. 2019-08-07 Richard Earnshaw PR driver/91130 * lto-wrapper.c (find_and_merge_options): Use CL_DRIVER when processing COLLECT_GCC_OPTIONS. (run_gcc): Likewise. Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/lto-wrapper.c branches/gcc-9-branch/gcc/tree.c
[Bug driver/91130] [9 Regression] -MF clashes with -flto on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130 --- Comment #44 from Richard Biener --- Author: rguenth Date: Mon Aug 12 12:59:08 2019 New Revision: 274311 URL: https://gcc.gnu.org/viewcvs?rev=274311=gcc=rev Log: 2019-08-12 Richard Biener Backport from mainline 2019-08-12 Richard Biener PR lto/91375 * tree.c (free_lang_data_in_type): Do not free TYPE_BINFO dependent on flag_devirtualize. 2019-08-12 Richard Biener PR driver/91130 * lto-wrapper.c (get_options_from_collect_gcc_options): Remove lang_mask option, always use CL_DRIVER. (find_and_merge_options): Adjust. (run_gcc): Likewise. 2019-08-07 Richard Earnshaw PR driver/91130 * lto-wrapper.c (find_and_merge_options): Use CL_DRIVER when processing COLLECT_GCC_OPTIONS. (run_gcc): Likewise. Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/lto-wrapper.c branches/gcc-9-branch/gcc/tree.c
[Bug target/90330] gcc 9.1.0 fails to install on macOS 10.14.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90330 --- Comment #15 from Matt Thompson --- Iain, I seem to still have issues. I downloaded 9.2.0 this morning and built it with: $ ../gcc-9.2.0/configure --prefix=/Users/mathomp4/installed/Core/gcc-gfortran/9.2.0 --enable-languages=c,c++,fortran --disable-multilib --with-native-system-header-dir=/usr/include --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk |& tee configure.log $ make -j4 |& tee make.log $ make install |& tee makeinstall.log Note I'm using a slightly different configure step as I'm trying to emulate what Homebrew does with its code as I no longer have /usr/include due to an Xcode update (and since I know Apple won't allow it soon, I'm trying to learn to work around that). But, eventually, the build fails with the *exact same error*: g++ -std=gnu++98-g -O2 -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -o cc1 c/c-lang.o c-family/stub-objc.o attribs.o c/c-errors.o c/c-decl.o c/c-typeck.o c/c-convert.o c/c-aux-info.o c/c-objc-common.o c/c-parser.o c/c-fold.o c/gimple-parser.o c-family/c-common.o c-family/c-cppbuiltin.o c-family/c-dump.o c-family/c-format.o c-family/c-gimplify.o c-family/c-indentation.o c-family/c-lex.o c-family/c-omp.o c-family/c-opts.o c-family/c-pch.o c-family/c-ppoutput.o c-family/c-pragma.o c-family/c-pretty-print.o c-family/c-semantics.o c-family/c-ada-spec.o c-family/c-ubsan.o c-family/known-headers.o c-family/c-attribs.o c-family/c-warn.o c-family/c-spellcheck.o i386-c.o darwin-c.o \ cc1-checksum.o libbackend.a main.o libcommon-target.a libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a ./../intl/libintl.a -liconv ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -L/Users/mathomp4/src/GCC/gcc-9.2.0-BUILD/./isl/.libs -lisl -L/Users/mathomp4/src/GCC/gcc-9.2.0-BUILD/./gmp/.libs -L/Users/mathomp4/src/GCC/gcc-9.2.0-BUILD/./mpfr/src/.libs -L/Users/mathomp4/src/GCC/gcc-9.2.0-BUILD/./mpc/src/.libs -lmpc -lmpfr -lgmp -L./../zlib -lz ld: warning: could not create compact unwind for __ZL18ix86_target_stringxxiiPKcS0_11fpmath_unitbb.cold: stack size is large but stack subq instruction not found ld: warning: could not create compact unwind for __ZNK9vec_usage4dumpEP12mem_locationR9mem_usage: stack subq instruction is too different from dwarf stack size ld: warning: could not create compact unwind for __ZL18cselib_record_setsP8rtx_insn.cold: stack size is large but stack subq instruction not found ld: warning: could not create compact unwind for __ZL16may_eliminate_ivP11ivopts_dataP6iv_useP7iv_candPP9tree_nodeP9tree_code: stack subq instruction is too different from dwarf stack size ld: warning: could not create compact unwind for __ZL16may_eliminate_ivP11ivopts_dataP6iv_useP7iv_candPP9tree_nodeP9tree_code.cold: stack size is large but stack subq instruction not found ld: warning: could not create compact unwind for __Z12find_reloadsP8rtx_insniiiPs: stack subq instruction is too different from dwarf stack size ld: warning: could not create compact unwind for __Z12find_reloadsP8rtx_insniiiPs.cold: stack size is large but stack subq instruction not found ld: warning: could not create compact unwind for __ZN12_GLOBAL__N_113pass_backprop7executeEP8function.cold: stack size is large but stack subq instruction not found ld: warning: could not create compact unwind for __ZL13powi_as_multsP20gimple_stmt_iteratorjP9tree_nodex: stack subq instruction is too different from dwarf stack size ld: warning: could not create compact unwind for __Z11inline_callP11cgraph_edgebP3vecIS0_7va_heap6vl_ptrEPibPb.cold: stack size is large but stack subq instruction not found ld: warning: could not create compact unwind for __ZL20process_alt_operandsi.cold: stack size is large but stack subq instruction not found Undefined symbols for architecture x86_64: "std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)", referenced from: ipa_icf::sem_item_optimizer::worklist_push(ipa_icf::congruence_class*) in libbackend.a(ipa-icf.o) ipa_icf::sem_item_optimizer::traverse_congruence_split(ipa_icf::congruence_class* const&, bitmap_head* const&, ipa_icf::traverse_split_pair*) in libbackend.a(ipa-icf.o) ipa_icf::sem_item_optimizer::subdivide_classes_by_sensitive_refs() in libbackend.a(ipa-icf.o) ipa_icf::sem_item_optimizer::process_cong_reduction() in libbackend.a(ipa-icf.o) "std::__detail::_List_node_base::_M_unhook()", referenced from: ipa_icf::sem_item_optimizer::worklist_pop() in libbackend.a(ipa-icf.o) "std::_Rb_tree_decrement(std::_Rb_tree_node_base*)", referenced from: std::pair, bool> std::_Rb_tree, std::less, std::allocator >::_M_insert_unique(basic_block_def* const&&&) in
[Bug tree-optimization/91425] Ordered compares aren't optimised
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91425 --- Comment #4 from Segher Boessenkool --- (In reply to Richard Biener from comment #1) > where we end up with > >[local count: 1073741824]: > if (a_3(D) < b_4(D)) > goto ; [50.00%] > else > goto ; [50.00%] > >[local count: 536870913]: > _6 = a_3(D) > b_4(D); > >[local count: 1073741824]: > # prephitmp_8 = PHI <_6(3), 1(2)> > > instead of != compares. instead of <> compares (LTGT). With -ffast-math we should get the NE as you say, and that works fine.
[Bug fortran/91424] Extend warnings about DO loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91424 --- Comment #1 from Thomas Koenig --- A third problem: Zero-trip do loops are warned about. program main implicit none integer :: i real :: a(2) do i=1,3,-1 a(i) = 2. end do print *,a end program main gets do_subscript_4.f90:6:7: 5 | do i=1,3,-1 | 2 6 | a(i) = 2. | 1 Warning: Array reference at (1) out of bounds (3 > 2) in loop beginning at (2)
[Bug c++/91423] address-of-packed-member when taking packed struct member by value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91423 --- Comment #3 from Anders Schau Knatten --- (In reply to Richard Biener from comment #1) > I think GCC tells you that deriving from std::array from a packed struct is > going to cause trouble because std::array expects to be naturally aligned? Do you know why std::array expect to be naturally aligned? I checked by the way, and gcc and clang both seem to naturally align base class subobjects. So in this case, the std::array subobject will be naturally aligned regardless of Vec packing: https://godbolt.org/z/9ZZ3eT In any case, if that is what it's trying to tell me, I think the warning could be improved.
[Bug tree-optimization/91425] Ordered compares aren't optimised
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91425 --- Comment #3 from Segher Boessenkool --- There are quite many different cases to test, and many *more* do not currently generate the wanted code because it isn't optimised properly on gimple level, and that makes it hard to test the RTL / target problems. That is all. After expand we still have multiple basic blocks for what should just be one comparison, and most RTL optimisations do not look in more than one BB at once.
[Bug tree-optimization/91425] Ordered compares aren't optimised
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91425 --- Comment #2 from Marc Glisse --- I think part of the problem with the current or_comparison optimization is that it relies on invert_tree_comparison in many cases, and that doesn't really work for floating point (and we handle the unsafe flags inconsistently, see for instance bug 53806).
[Bug tree-optimization/91425] Ordered compares aren't optimised
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91425
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-08-12
Component|middle-end |tree-optimization
Version|unknown |10.0
Summary|Ordered compares aren't |Ordered compares aren't
|optimised properly |optimised
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
Confirmed. No idea why improving GIMPLE is a requirement for making targets
behave better though.
Btw, on x86_64 ll and llx would have to be handled by phiopt since we have
for example
ll (double a, double b)
{
_Bool _6;
_Bool prephitmp_8;
[local count: 1073741824]:
if (a_3(D) u>= b_4(D))
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 536870913]:
_6 = a_3(D) < b_4(D);
[local count: 1073741824]:
# prephitmp_8 = PHI <_6(3), 1(2)>
return prephitmp_8;
maybe_fold_or_comparisons could be used here eventually. Btw. it's the
same missed optimization for non-ordered:
_Bool lt(double a, double b) { return a > b; }
_Bool lo(double a, double b) { return a < b; }
_Bool ll(double a, double b) { return lt(a,b) || lo(a,b); }
_Bool lx(double a, double b) { return lo(a,b) || lt(a,b); }
where we end up with
[local count: 1073741824]:
if (a_3(D) < b_4(D))
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 536870913]:
_6 = a_3(D) > b_4(D);
[local count: 1073741824]:
# prephitmp_8 = PHI <_6(3), 1(2)>
instead of != compares.
[Bug middle-end/91425] New: Ordered compares aren't optimised properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91425
Bug ID: 91425
Summary: Ordered compares aren't optimised properly
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
Take this example:
===
#include
_Bool lt(double a, double b) { return isless(a, b); }
_Bool lo(double a, double b) { return a < b; }
_Bool ll(double a, double b) { return lt(a,b) || lo(a,b); }
_Bool lx(double a, double b) { return lo(a,b) || lt(a,b); }
===
"lt" is an "unordered" comparison, that is, it does not raise an
exception if one (or both) of the inputs is a NaN, i.e. if the
comparison result is "unordered". "lo" is an "ordered" comparison,
which means it does raise an exception if one of the inputs is a
NaN.
Doing both is the same as just doing the ordered comparison and
using the result for both. "ll" should compile to the same as "lx"
does, and that should be the same as what is generated for "lo".
But it is not; not on rs6000 (with my cmpo patches), and not on x86
either: in both cases all three are different. And in fact the
gimple output for all three is different; I think we need to fix
that before making RTL and the targets behave better.
[Bug target/91386] [9 regression] open-iscsi iscsiadm miscompiled by LTO on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91386 --- Comment #22 from Wilco --- (In reply to Richard Earnshaw from comment #21) > Fixed on trunk. I ran an AArch64 bootstrap on GCC9 branch and that is fine.
