[Bug tree-optimization/98813] loop is sub-optimized if index is unsigned int with offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98813
--- Comment #2 from Jiu Fu Guo ---
For code:
for (unsigned int k = 0; k < BS; k++)
{
s += A[k] * B[k];
}
PR48052 handles this, and for this code, the additional runtime check seems not
required.
If there is offset in code:
for (unsigned int k = 0; k < BS; k++)
{
s += A[k+3] * B[k+3];
}
This code is not vectorized then.
[Bug bootstrap/98616] Compile gcc 10.2.0 error for loongson 2f CPU use MIPS n32 ABI on Gentoo OS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98616 Paul Hua changed: What|Removed |Added CC||paul.hua.gm at gmail dot com --- Comment #2 from Paul Hua --- Hi, The error message show: - configure: error: in `/var/tmp/portage/sys-devel/gcc-10.2.0-r5/work/build/mips64el-unknown-linux-gnu/libgcc': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details make[2]: *** [Makefile:16845: configure-stage1-target-libgcc] Error 1 --- please see config.log for more details.
[Bug tree-optimization/98813] loop is sub-optimized if index is unsigned int with offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98813 --- Comment #1 from Jiu Fu Guo --- Since there are additional costs for the run-time check, we can see the benefit if upbound `m` is large; if upbound is small (e.g. < 12), the vectorized code (from clang) is worse than un-vectorized binary.
[Bug tree-optimization/98813] New: loop is sub-optimized if index is unsigned int with offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98813
Bug ID: 98813
Summary: loop is sub-optimized if index is unsigned int with
offset
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: guojiufu at gcc dot gnu.org
Target Milestone: ---
For the below code:
---t.c
void
foo (const double* __restrict__ A, const double* __restrict__ B, double*
__restrict__ C,
int n, int k, int m)
{
for (unsigned int l_m = 0; l_m < m; l_m++)
C[n + l_m] += A[k + l_m] * B[k];
}
--
compile with `gcc -O3 -S t.c -fopt-info`, we can see the loop was not
vectorized because it may not safe to directly optimize with potential
overflow.
clang could vectorize this code, while there are run-time instructions to check
if it is safe to do the optimization.
```
%1 = add nsw i64 %wide.trip.count, -1 = cnt-1
%2 = trunc i64 %1 to i32 = (int)(cnt-1)
%3 = xor i32 %n, -1 = n xor -1
%4 = icmp ult i32 %3, %2 = (n xor -1) < (int)(cnt-1)
%5 = icmp ugt i64 %1, 4294967295 = cnt > 4294967295 (overflow?)
%6 = or i1 %4, %5
```
[Bug debug/98811] [11 regression] All Go tests FAIL with abbrev offset out of range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98811 --- Comment #3 from Mark Wielaard --- (In reply to r...@cebitec.uni-bielefeld.de from comment #2) > If the DWARF-5 support depends on specific binutils versions/patches to > work, this should both be documented and detected at configure time. > Having users run into such complete failure as in the Go case is a very > bad user experience IMO. I believe it already does. There are some known issues with debug_line generation that gcc configure should detect and disable if a bad/old binutils is detected. But given your experience there might be other bugs, but I don't which they are. If you know which binutils patch fixes it then we might be able to create a configure test for it.
[Bug c++/98805] exception abort on mac os 11 (big sur)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98805 Iain Sandoe changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |10.3 Status|NEW |RESOLVED --- Comment #8 from Iain Sandoe --- (In reply to Iain Sandoe from comment #6) > thanks FX.. > > That single patch is definitely "necessary, but not sufficient". > > .. AFAIK, the critical patches have been already applied to the 10.x branch > (there were several) - but I'll run a check on macOS 11 with the current > branch - and then short-list what you need to fix it... current 10.x branch "works for me" ... homebrew might want to consider these: c85bc938ccf Darwin : Update libtool and dependencies for Darwin20 [PR97865] 7b19b6b1536 Darwin, libsanitizer : Support libsanitizer for x86_64-darwin20. 82abd13fb66 Darwin : Adjust handling of MACOSX_DEPLOYMENT_TARGET for macOS 11. f5ee16a0d8e Darwin : Update the kernel version to macOS version mapping. 24957662c67 Darwin: Darwin 20 is to be macOS 11 (Big Sur). d0bae0b218d Darwin: Adjust the PCH area to allow for 16384byte page size. (optional) e731714eb2b libobjc, Darwin : Fix powerpc encoding regression. (optional) c1d7709ec68 Darwin, libgfortran : Do not use environ directly from the library. This is fixed for the next release (we discussed making a special, but I'd say the effort of a darwin-specific release now probably doesn't warrant it - 10.3 is probably a month or so away). Better just to update the band-aid (and note that it's also needed for any other 10.x back ports).
[Bug debug/98811] [11 regression] All Go tests FAIL with abbrev offset out of range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98811 --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #1 from Mark Wielaard --- > (In reply to Rainer Orth from comment #0) >> However, when I switched to >> the freshly released GNU as 2.36 today, the error vanished everywhere. > > Which GNU as were you using before? There were some bug fixes for 2.35 which > never made it into a released version: > https://sourceware.org/pipermail/binutils/2020-November/114152.html The unmodified 2.35 release. I stick with self-compiled versions to avoid depending on distributions making their own set of changes. If the DWARF-5 support depends on specific binutils versions/patches to work, this should both be documented and detected at configure time. Having users run into such complete failure as in the Go case is a very bad user experience IMO.
[Bug c++/98805] exception abort on mac os 11 (big sur)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98805 awsteiner at utk dot edu changed: What|Removed |Added CC||awsteiner at utk dot edu --- Comment #7 from awsteiner at utk dot edu --- *** Bug 98812 has been marked as a duplicate of this bug. ***
[Bug c++/98812] Abort trap: 6 on MacOS with homebrew gcc when exceptions are thrown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98812 awsteiner at utk dot edu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from awsteiner at utk dot edu --- Sorry my bad! Duplicate. Thank you for your patience. *** This bug has been marked as a duplicate of bug 98805 ***
[Bug c++/98812] New: Abort trap: 6 on MacOS with homebrew gcc when exceptions are thrown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98812 Bug ID: 98812 Summary: Abort trap: 6 on MacOS with homebrew gcc when exceptions are thrown Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: awsteiner at utk dot edu Target Milestone: --- I'm using gcc 10.2.0_2 on homebrew on MacOS Big Sur 11.1 (see below). I have a standard homebrew installation of gcc and 'brew doctor' doesn't report any unexpected issues. My problem is that throwing an exception causes "abort trap: 6", even trivial examples like the code at the top of https://www.cplusplus.com/doc/tutorial/exceptions/ cause the same issue. Everything else seems to run fine. I'm not using any flags to compile, as with examples this simple they aren't necessary. Any ideas? Thank you, Andrew gcc-10 -v: Using built-in specs. COLLECT_GCC=gcc-10 COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc/10.2.0_2/libexec/gcc/x86_64-apple-darwin20/10.2.0/lto-wrapper Target: x86_64-apple-darwin20 Configured with: ../configure --build=x86_64-apple-darwin20 --prefix=/usr/local/Cellar/gcc/10.2.0_2 --libdir=/usr/local/Cellar/gcc/10.2.0_2/lib/gcc/10 --disable-nls --enable-checking=release --enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-10 --with-gmp=/usr/local/opt/gmp --with-mpfr=/usr/local/opt/mpfr --with-mpc=/usr/local/opt/libmpc --with-isl=/usr/local/opt/isl --with-system-zlib --with-pkgversion='Homebrew GCC 10.2.0_2' --with-bugurl=https://github.com/Homebrew/homebrew-core/issues --disable-multilib --with-native-system-header-dir=/usr/include --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk SED=/usr/bin/sed Thread model: posix Supported LTO compression algorithms: zlib gcc version 10.2.0 (Homebrew GCC 10.2.0_2)
[Bug debug/98811] [11 regression] All Go tests FAIL with abbrev offset out of range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98811 --- Comment #1 from Mark Wielaard --- (In reply to Rainer Orth from comment #0) > However, when I switched to > the freshly released GNU as 2.36 today, the error vanished everywhere. Which GNU as were you using before? There were some bug fixes for 2.35 which never made it into a released version: https://sourceware.org/pipermail/binutils/2020-November/114152.html
[Bug debug/98811] [11 regression] All Go tests FAIL with abbrev offset out of range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98811 Rainer Orth changed: What|Removed |Added Target Milestone|--- |11.0
[Bug debug/98811] New: [11 regression] All Go tests FAIL with abbrev offset out of range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98811 Bug ID: 98811 Summary: [11 regression] All Go tests FAIL with abbrev offset out of range Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: ian at airs dot com, mark at gcc dot gnu.org Target Milestone: --- Target: *-*-solaris2.11, i686-pc-linux-gnu, x86_64-pc-linux-gnu Since the switch to DWARF-5, all Go execution tests started to FAIL in the same way: fatal error: abbrev offset out of range goroutine 1 [running, locked to thread]: fatal error: abbrev offset out of range panic during panic goroutine 1 [running, locked to thread]: fatal error: abbrev offset out of range stack trace unavailable I'm seeing this on both Solaris and Linux, 32 and 64-bit. However, this does not happen when Solaris as is in use, only with GNU as 2.35 (irrespective of linker: Solaris ld and GNU ld show the same behaviour). However, when I switched to the freshly released GNU as 2.36 today, the error vanished everywhere.
[Bug fortran/70070] ICE on initializing character data beyond min/max bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70070 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org Keywords||ice-on-invalid-code --- Comment #13 from anlauf at gcc dot gnu.org --- Patch: https://gcc.gnu.org/pipermail/fortran/2021-January/055628.html
[Bug c++/98804] GCC misparses template in pack expansion as comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98804
--- Comment #1 from Richard Smith ---
Somewhat more reduced:
struct X { constexpr X(int&) {} };
template struct Y {};
int a;
auto h(int b) -> Y; // #1
auto h(int b) -> Y; // #2
GCC accepts #1, but for #2 it produces seven (!) error messages:
:6:21: error: template argument 1 is invalid
6 | auto h(int b) -> Y;
| ^
:6:21: error: template argument 1 is invalid
:6:21: error: template argument 1 is invalid
:6:21: error: template argument 1 is invalid
:6:18: error: invalid template-id
6 | auto h(int b) -> Y;
| ^
:6:21: error: use of parameter outside function body before '>' token
6 | auto h(int b) -> Y;
| ^
:6:6: error: deduced class type 'Y' in function return type
6 | auto h(int b) -> Y;
| ^
:2:20: note: 'template > struct Y' declared here
2 | template struct Y {};
|^
As far as I'm aware, both #1 and #2 are valid. (I think the "use of parameter
outside function body" restriction is referring to [dcl.fct.default]/9, but
that refers only to uses of parameters within default arguments, not uses in
other contexts in the function declaration.)
[Bug c++/98810] New: [C++20] ICE in tsubst_copy, at cp/pt.c:16771
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98810
Bug ID: 98810
Summary: [C++20] ICE in tsubst_copy, at cp/pt.c:16771
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dimitri.gorokhovik at free dot fr
Target Milestone: ---
The code:
template struct a {};
template s = a {}> using b = a ;
template constexpr auto g (const b &) { return true; };
compiled with 'g++ -std=c++20 -c bug-13.cpp' (g++ (GCC) 11.0.0 20210123
(experimental)), produces:
ug-13.cpp: In substitution of ‘template s> using b = a<((const
a)s)> [with int i = i; a s = a{}]’:
bug-13.cpp:4:46: required from here
bug-13.cpp:3:57: internal compiler error: in tsubst_copy, at cp/pt.c:16771
3 | template s = a {}> using b = a ;
| ^
0x6cb940 tsubst_copy
../../src/gcc/cp/pt.c:16771
0xac3c42 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../src/gcc/cp/pt.c:20766
0xacee68 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../src/gcc/cp/pt.c:19019
0xae1a4e tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
../../src/gcc/cp/pt.c:13322
0xaecf83 tsubst_aggr_type
../../src/gcc/cp/pt.c:13525
0xacbed0 tsubst_decl
../../src/gcc/cp/pt.c:14763
0xade475 instantiate_template_1
../../src/gcc/cp/pt.c:21016
0xadf76f instantiate_template(tree_node*, tree_node*, int)
../../src/gcc/cp/pt.c:21075
0xadf76f instantiate_alias_template
../../src/gcc/cp/pt.c:21113
0xadf76f tsubst(tree_node*, tree_node*, int, tree_node*)
../../src/gcc/cp/pt.c:15394
0xaeb4ff lookup_template_class_1
../../src/gcc/cp/pt.c:9937
0xaec8dc lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../../src/gcc/cp/pt.c:10226
0xb1431b finish_template_type(tree_node*, tree_node*, int)
../../src/gcc/cp/semantics.c:3464
0xa87531 cp_parser_template_id
../../src/gcc/cp/parser.c:17406
0xa8771b cp_parser_class_name
../../src/gcc/cp/parser.c:24631
0xa7ecba cp_parser_qualifying_entity
../../src/gcc/cp/parser.c:6994
0xa7ecba cp_parser_nested_name_specifier_opt
../../src/gcc/cp/parser.c:6676
0xa94234 cp_parser_simple_type_specifier
../../src/gcc/cp/parser.c:18799
0xa7332d cp_parser_type_specifier
../../src/gcc/cp/parser.c:18457
0xa74329 cp_parser_decl_specifier_seq
../../src/gcc/cp/parser.c:15003
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug plugins/65817] libcc1: ICE: SEGV: c_incomplete_type_error()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65817 Tom Tromey changed: What|Removed |Added CC||tromey at gcc dot gnu.org --- Comment #3 from Tom Tromey --- I think this was fixed by commit 8db29d88f3e8d5fc43b25d9e0049c25f6bfb74d1 Author: Alexandre Oliva Date: Tue Jan 31 01:02:03 2017 + Introduce C++ support in libcc1 in particular the code now does tree node = make_node (code); tree type_decl = build_decl (input_location, TYPE_DECL, NULL_TREE, node); TYPE_NAME (node) = type_decl;
[Bug libstdc++/98723] On Windows with CP936 encoding, regex compiles very slow.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98723 cqwrteur changed: What|Removed |Added CC||unlvsur at live dot com --- Comment #3 from cqwrteur --- This should be reported as a CVE.
[Bug target/98807] [11 Regression] wrong code with -O2 -mno-sse2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98807 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |11.0 Last reconfirmed||2021-01-24 CC||jakub at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r11-6468-g01da03c915f086fb9aa36b809c1a06a9f661533b
[Bug fortran/48786] [OOP] Generic ambiguity check too strict for polymorphic dummies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48786 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org Status|NEW |WAITING --- Comment #15 from Thomas Koenig --- nagfor rejects the original example program with Error: 48786.f90, line 56: Ambiguous specific type-bound procedures ADD_VECTOR_3DVERSION and ADD_VECTOR for type-bound generic OPERATOR(+) in type POINT2D Errors in declarations, no further processing for POINTS2D3D xlf also rejects this, with another error message: "48786.f90", line 19.51: 1514-699 (S) Procedure "add_vector_3d" must have a nonoptional dummy argument that corresponds by position in the argument list to a dummy argument not present in procedure "add_vector_2d", present and type incompatible, present with different kind type parameters, or present with a different rank. So, is the test case really valid?
[Bug fortran/68241] [meta-bug] [F03] Deferred-length character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68241 Bug 68241 depends on bug 66910, which changed state. Bug 66910 Summary: allocatable character in derived type gives segfault https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66910 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID
[Bug fortran/66910] allocatable character in derived type gives segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66910 Thomas Koenig changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #3 from Thomas Koenig --- nagfor complains: 1 Runtime Error: 66910.f90, line 13: ALLOCATABLE ENVIRONMENT_TABLE is not currently allocated Program terminated by fatal error Abgebrochen (Speicherabzug geschrieben) And it is indeed correct. When entering the subroutine env_table_add, the line type(t_env_table), dimension(size(environment_table)) :: temp is indeed incorrect - variables which are not allocated have no valid size.
[Bug c++/98805] exception abort on mac os 11 (big sur)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98805 --- Comment #6 from Iain Sandoe --- thanks FX.. That single patch is definitely "necessary, but not sufficient". .. AFAIK, the critical patches have been already applied to the 10.x branch (there were several) - but I'll run a check on macOS 11 with the current branch - and then short-list what you need to fix it...
[Bug c++/98805] exception abort on mac os 11 (big sur)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98805 --- Comment #5 from Francois-Xavier Coudert --- Here is what g++-10 -v gives during compilation: rmeur /tmp $ g++-10 a.cpp -v Using built-in specs. COLLECT_GCC=g++-10 COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc/10.2.0_2/libexec/gcc/x86_64-apple-darwin20/10.2.0/lto-wrapper Target: x86_64-apple-darwin20 Configured with: ../configure --build=x86_64-apple-darwin20 --prefix=/usr/local/Cellar/gcc/10.2.0_2 --libdir=/usr/local/Cellar/gcc/10.2.0_2/lib/gcc/10 --disable-nls --enable-checking=release --enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-10 --with-gmp=/usr/local/opt/gmp --with-mpfr=/usr/local/opt/mpfr --with-mpc=/usr/local/opt/libmpc --with-isl=/usr/local/opt/isl --with-system-zlib --with-pkgversion='Homebrew GCC 10.2.0_2' --with-bugurl=https://github.com/Homebrew/homebrew-core/issues --disable-multilib --with-native-system-header-dir=/usr/include --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk SED=/usr/bin/sed Thread model: posix Supported LTO compression algorithms: zlib gcc version 10.2.0 (Homebrew GCC 10.2.0_2) COLLECT_GCC_OPTIONS='-v' '-mmacosx-version-min=11.0.0' '-asm_macosx_version_min=11.0' '-shared-libgcc' '-mtune=core2' /usr/local/Cellar/gcc/10.2.0_2/libexec/gcc/x86_64-apple-darwin20/10.2.0/cc1plus -quiet -v -D__DYNAMIC__ a.cpp -fPIC -quiet -dumpbase a.cpp -mmacosx-version-min=11.0.0 -mtune=core2 -auxbase a -version -o /var/folders/h8/9hx_fyj91053ksgdzb2w03vwgp/T//ccf7qnt5.s GNU C++14 (Homebrew GCC 10.2.0_2) version 10.2.0 (x86_64-apple-darwin20) compiled by GNU C version 10.2.0, GMP version 6.2.1, MPFR version 4.1.0, MPC version 1.2.1, isl version isl-0.23-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring nonexistent directory "/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/local/include" ignoring nonexistent directory "/usr/local/Cellar/gcc/10.2.0_2/lib/gcc/10/gcc/x86_64-apple-darwin20/10.2.0/../../../../../../x86_64-apple-darwin20/include" ignoring nonexistent directory "/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/Library/Frameworks" #include "..." search starts here: #include <...> search starts here: /usr/local/Cellar/gcc/10.2.0_2/lib/gcc/10/gcc/x86_64-apple-darwin20/10.2.0/../../../../../../include/c++/10.2.0 /usr/local/Cellar/gcc/10.2.0_2/lib/gcc/10/gcc/x86_64-apple-darwin20/10.2.0/../../../../../../include/c++/10.2.0/x86_64-apple-darwin20 /usr/local/Cellar/gcc/10.2.0_2/lib/gcc/10/gcc/x86_64-apple-darwin20/10.2.0/../../../../../../include/c++/10.2.0/backward /usr/local/Cellar/gcc/10.2.0_2/lib/gcc/10/gcc/x86_64-apple-darwin20/10.2.0/include /usr/local/Cellar/gcc/10.2.0_2/lib/gcc/10/gcc/x86_64-apple-darwin20/10.2.0/include-fixed /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks End of search list. GNU C++14 (Homebrew GCC 10.2.0_2) version 10.2.0 (x86_64-apple-darwin20) compiled by GNU C version 10.2.0, GMP version 6.2.1, MPFR version 4.1.0, MPC version 1.2.1, isl version isl-0.23-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 226b82c9217faee57636048830034c6a COLLECT_GCC_OPTIONS='-v' '-mmacosx-version-min=11.0.0' '-shared-libgcc' '-mtune=core2' as -arch x86_64 -v -force_cpusubtype_ALL -mmacosx-version-min=11.0 -o /var/folders/h8/9hx_fyj91053ksgdzb2w03vwgp/T//cclYOyAu.o /var/folders/h8/9hx_fyj91053ksgdzb2w03vwgp/T//ccf7qnt5.s Apple clang version 12.0.0 (clang-1200.0.32.28) Target: x86_64-apple-darwin20.2.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang" -cc1as -triple x86_64-apple-macosx11.0.0 -filetype obj -main-file-name ccf7qnt5.s -target-cpu penryn -fdebug-compilation-dir /tmp -dwarf-debug-producer "Apple clang version 12.0.0 (clang-1200.0.32.28)" -dwarf-version=4 -mrelocation-model pic -o /var/folders/h8/9hx_fyj91053ksgdzb2w03vwgp/T//cclYOyAu.o /var/folders/h8/9hx_fyj91053ksgdzb2w03vwgp/T//ccf7qnt5.s COMPILER_PATH=/usr/local/Cellar/gcc/10.2.0_2/libexec/gcc/x86_64-apple-darwin20/10.2.0/:/usr/local/Cellar/gcc/10.2.0_2/libexec/gcc/x86_64-apple-darwin20/10.2.0/:/usr/local/Cellar/gcc/10.2.0_2/libexec/gcc/x86_64-apple-darwin20/:/usr/local/Cellar/gcc/10.2.0_2/lib/gcc/10/gcc/x86_64-apple-darwin20/10.2.0/:/usr/local/Cellar/gcc/10.2.0_2/lib/gcc/10/gcc/x86_64-apple-darwin20/ LIBRARY_PATH=/usr/local/Cellar/gcc/10.2.0_2/lib/gcc/10/gcc/x86_64-apple-darwin20/10.2.0/:/usr/local/Cellar/gcc/10.2.0_2/lib/gcc/10/gcc/x86_64-apple-darwin20/10.2.0/../../../ COLLECT_GCC_OPTIONS='-v' '-mmacosx-version-min=11.0.0' '-shared-libgcc' '-mtune=core2' /usr/local/Cellar/gcc/10.2.0_2/libexec/gcc/x86_64-apple-darwin20/10.2.0/collect2 -syslibroot /Library/Developer/CommandLineTools/S
[Bug c++/98805] exception abort on mac os 11 (big sur)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98805 Francois-Xavier Coudert changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-01-24 Status|UNCONFIRMED |NEW --- Comment #4 from Francois-Xavier Coudert --- And I can confirm the crash on my own system, with the same stack backtrace.
[Bug c++/98805] exception abort on mac os 11 (big sur)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98805 Francois-Xavier Coudert changed: What|Removed |Added CC||fxcoudert at gcc dot gnu.org --- Comment #3 from Francois-Xavier Coudert --- On macOS Big Sur Intel, Homebrew builds gcc-10 from the 10.2 release sources (https://ftp.gnu.org/gnu/gcc/gcc-10.2.0/gcc-10.2.0.tar.xz) with one extra patch at https://raw.githubusercontent.com/Homebrew/formula-patches/7baf6e2f/gcc/bigsur.diff (which is basically Iain's commit at https://github.com/iains/gcc-darwin-arm64/commit/556ab512) The compiler is build with: ``` ../configure --build=x86_64-apple-darwin20 --prefix=/usr/local/Cellar/gcc/10.2.0_2 --libdir=/usr/local/Cellar/gcc/10.2.0_2/lib/gcc/10 --disable-nls --enable-checking=release --enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-10 --with-gmp=/usr/local/opt/gmp --with-mpfr=/usr/local/opt/mpfr --with-mpc=/usr/local/opt/libmpc --with-isl=/usr/local/opt/isl --with-system-zlib --with-pkgversion='Homebrew GCC 10.2.0_2' --with-bugurl=https://github.com/Homebrew/homebrew-core/issues --disable-multilib --with-native-system-header-dir=/usr/include --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk SED=/usr/bin/sed ``` We've always done it that way, the only recent change to that is pretty much that we use the unversioned symlink /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk instead of the versioned directory (/Library/Developer/CommandLineTools/SDKs/MacOSX11.1.sdk) because since Big Sur, Apple is labelling their SDK with minor version numbers and that breaks for people who don't have the same exact version of the command-line developer tools.
[Bug c++/98805] exception abort on mac os 11 (big sur)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98805 --- Comment #2 from Iain Sandoe --- Hi Hana .. There are some changes needed on the 10.x branch to cater for macOS 11. Trying to ensure that we get them in before 10.3 is released. In the meantime, I'll discuss with the home-brew folks about other strategies. Failing that I can push my work in progress for the branch somewhere and you can build that. Iain
[Bug bootstrap/98809] New: sem_util.adb:885:30: "T" conflicts with declaration at line 881
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98809 Bug ID: 98809 Summary: sem_util.adb:885:30: "T" conflicts with declaration at line 881 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Target Milestone: --- Host: hppa*-*-hpux11.11 Target: hppa*-*-hpux11.11 Build: hppa*-*-hpux11.11 At commit 7944753fad501194eb8a828d6b74270e79d14a4d: /test/gnu/gcc/objdir/./prev-gcc/xgcc -B/test/gnu/gcc/objdir/./prev-gcc/ -B/opt/g nu/gcc/gcc-11/hppa2.0w-hp-hpux11.11/bin/ -B/opt/gnu/gcc/gcc-11/hppa2.0w-hp-hpux1 1.11/bin/ -B/opt/gnu/gcc/gcc-11/hppa2.0w-hp-hpux11.11/lib/ -isystem /opt/gnu/gcc /gcc-11/hppa2.0w-hp-hpux11.11/include -isystem /opt/gnu/gcc/gcc-11/hppa2.0w-hp-h pux11.11/sys-include -fchecking=1 -c -g -O2 -fchecking=1 -mdisable-indexing -g natpg -gnata -W -Wall -nostdinc -I- -I. -Iada/generated -Iada -Iada/gcc-interfac e -I../../gcc/gcc/ada -I../../gcc/gcc/ada/gcc-interface -Iada/libgnat -I../../gc c/gcc/ada/libgnat ../../gcc/gcc/ada/sem_util.adb -o ada/sem_util.o sem_util.adb:885:30: "T" conflicts with declaration at line 881 make[3]: *** [../../gcc/gcc/ada/gcc-interface/Make-lang.in:139: ada/sem_util.o] Error 1 make[3]: *** Waiting for unfinished jobs rm gcov.pod fsf-funding.pod gpl.pod gfdl.pod gfortran.pod gcc.pod gcov-dump.pod gcov-tool.pod cpp.pod make[3]: Leaving directory '/test/gnu/gcc/objdir/gcc' make[2]: *** [Makefile:4861: all-stage3-gcc] Error 2 make[2]: Leaving directory '/test/gnu/gcc/objdir' make[1]: *** [Makefile:24868: stage3-bubble] Error 2 make[1]: Leaving directory '/test/gnu/gcc/objdir' make: *** [Makefile:24932: bootstrap] Error 2 Fri Jan 22 23:29:40 EST 2021
[Bug libgomp/98738] task-detach-6.f90 hangs intermittently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98738 Dominique d'Humieres changed: What|Removed |Added CC||seurer at gcc dot gnu.org --- Comment #11 from Dominique d'Humieres --- *** Bug 98808 has been marked as a duplicate of this bug. ***
[Bug libgomp/98808] [11 regression] test case libgomp.c-c++-common/task-detach-6.c hangs after r11-6752
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98808 Dominique d'Humieres changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Dominique d'Humieres --- Dup. *** This bug has been marked as a duplicate of bug 98738 ***
[Bug libgomp/98808] New: [11 regression] test case libgomp.c-c++-common/task-detach-6.c hangs after r11-6752
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98808 Bug ID: 98808 Summary: [11 regression] test case libgomp.c-c++-common/task-detach-6.c hangs after r11-6752 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org CC: jakub at gcc dot gnu.org Target Milestone: --- g:a6d22fb21c6f1ad7e8b6b722bfc0e7e11f50cb92, r11-6752 make -k check-target-libgomp RUNTESTFLAGS="c.exp=libgomp.c/../libgomp.c-c++-common/task-detach-6.c" The test case task-detach-6 started hanging with this revision though quite infrequently (averaging one hang in every thousand runs or so). It hangs on powerpc64 both LE and BE though it seems to happen more frequently on BE. Here's an example of one that was hung for over 7 minutes. I first noticed when our auto tester had hung for several days. seurer@hogun:~/gcc/git/build/gcc-test$ date; ps -eo pid,lstart,stat,cmd | grep task-detach-6 Sun Jan 24 09:10:05 CST 2021 39672 Sun Jan 24 09:02:53 2021 Sl+ ./task-detach-6.exe The process state codes are: Sinterruptible sleep (waiting for an event to complete) lis multi-threaded (using CLONE_THREAD, like NPTL +is in the foreground process group commit a6d22fb21c6f1ad7e8b6b722bfc0e7e11f50cb92 (HEAD) Author: Kwok Cheung Yeung Date: Sat Jan 16 12:58:13 2021 -0800 openmp: Add support for the OpenMP 5.0 task detach clause
[Bug target/98807] New: [11 Regression] wrong code with -O2 -mno-sse2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98807 Bug ID: 98807 Summary: [11 Regression] wrong code with -O2 -mno-sse2 Product: gcc Version: 11.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 50044 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50044&action=edit reduced testcase Output: $ x86_64-pc-linux-gnu-gcc -O2 testcase.c && ./a.out $ x86_64-pc-linux-gnu-gcc -O2 testcase.c -mno-sse2 && ./a.out Aborted $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r11-6878-20210123002417-ga8cef3cba69-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r11-6878-20210123002417-ga8cef3cba69-checking-yes-rtl-df-extra-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 11.0.0 20210123 (experimental) (GCC)
[Bug testsuite/98771] [10/11 regression] gcc.dg/strcmpopt_8.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98771 --- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #5 from Jakub Jelinek --- > Created attachment 50028 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50028&action=edit > gcc11-pr98771.patch > > Untested fix. I've now managed to test the patch on i386-pc-solaris2.11, sparc-sun-solaris2.11 and (for good measure) amd64-pc-solaris2.11, sparcv9-sun-solaris2.11. The failures are gone. Thanks.
[Bug fortran/70949] Invalid aggregate against pointer comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70949 Dominique d'Humieres changed: What|Removed |Added Status|NEW |WAITING --- Comment #4 from Dominique d'Humieres --- This PR appears to have been fixed between r11-6743 and r11-6879.
[Bug target/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787 --- Comment #19 from Xi Ruoyao --- gas has added a workaround. I'll test it tomorrow.
[Bug c++/98805] exception abort on mac os 11 (big sur)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98805 --- Comment #1 from Hana Dusíková --- I found out that build done on Catalina generates correct binary, which is able to run on Big Sur without any problem.
[Bug target/98784] [8/9/10/11 Regression] problematic build of uClibc with -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98784 --- Comment #8 from Eric Botcazou --- > OK, this makes sense now and this looks like a bootstrap problem, e.g. the > code setting up _GLOBAL_OFFSET_TABLE_ in the libc might be trying to access > it or something along this line. I misremembered: the code loading the GOT register is eliminated if not used in the end, but it can block the leaf register optimization, i.e. a register window is allocated although it is not needed. So does uClibc depend on the fact that a register window is not allocated in some specific spot?
