[Bug bootstrap/96378] segfault during bootstrap with --disable-checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96378 Eric Botcazou changed: What|Removed |Added Status|WAITING |NEW Summary|ICE: Solaris/SPARCv9|segfault during bootstrap |bootstrap stage2 segfault |with --disable-checking |compiling | |stdc++.h.gch/O2ggnu++0x.gch | --- Comment #6 from Eric Botcazou --- > Thanks! configuring with --enable-checking=release allowed it to compile. You're welcome. We strongly discourage to configure with --disable-checking because the compiler will generally not stop in cases where it is confused. The build should not segfault with it though, so keeping the PR open.
[Bug libstdc++/98389] [11 regression] libstdc++-abi/abi_check fails after r11-6249 on powerpc64 big endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98389 --- Comment #1 from Andreas Schwab --- The list just needs to be updated.
[Bug c++/98383] internal compiler error: in make_decl_rtl, at varasm.c:1342
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98383
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
Reduced testcase:
int bar (const int &);
void
foo ()
{
#pragma omp simd
for (int i = 0; i < bar (8); ++i)
;
}
[Bug libgcc/98390] New: AIX: exceptions in threads: IOT/Abort trap(coredump)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98390
Bug ID: 98390
Summary: AIX: exceptions in threads: IOT/Abort trap(coredump)
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: stefan at bytereef dot org
Target Milestone: ---
The following test case is extracted from a larger program. When repeated
often enough, it terminates with: IOT/Abort trap(coredump)
Confirmed with g++ (GCC) 7.2.0 and g++ (GCC) 10.2.0 on gcc119.fsffrance.org.
test.cc:
#include
#include
#include
class suntime_error : public std::runtime_error {
using std::runtime_error::runtime_error;
};
static void
doit()
{
try {
throw suntime_error("this is an error");
}
catch (const suntime_error& err) {
(void)err;
}
}
static void
do_threads()
{
const size_t n = 100;
std::vector t(n);
for (size_t k = 0; k < n; k++) {
t[k] = std::thread(doit);
}
for (size_t k = 0; k < n; k++) {
t[k].join();
}
}
int
main()
{
do_threads();
return 0;
}
doit.sh:
#!/bin/sh
while ./test; do
:
done
$ g++ -pthread -Wall -Wextra -std=gnu++11 -pedantic -O0 -g -o test test.cc
$ ./doit.sh
./doit.sh[3]: 14484092 IOT/Abort trap(coredump)
$ gdb ./test core
[...]
Program terminated with signal SIGABRT, Aborted.
#0 0xd058f3ec in pthread_kill () from /usr/lib/libpthreads.a(shr_xpg5.o)
(gdb) bt
#0 0xd058f3ec in pthread_kill () from /usr/lib/libpthreads.a(shr_xpg5.o)
#1 0xd058e7cc in _p_raise () from /usr/lib/libpthreads.a(shr_xpg5.o)
#2 0xd0123608 in raise () from /usr/lib/libc.a(shr.o)
#3 0xd0189ebc in abort () from /usr/lib/libc.a(shr.o)
#4 0xd08741a4 in uw_init_context_1 () from
/opt/freeware/lib/gcc/powerpc-ibm-aix7.2.0.0/7.2.0/pthread/libgcc_s.a(shr.o)
#5 0xd0874e50 in _Unwind_RaiseException () from
/opt/freeware/lib/gcc/powerpc-ibm-aix7.2.0.0/7.2.0/pthread/libgcc_s.a(shr.o)
#6 0xd17cd2cc in __cxa_throw () from
/opt/freeware/lib/gcc/powerpc-ibm-aix7.2.0.0/7.2.0/pthread/libstdc++.a(libstdc++.so.6)
#7 0x16dc in doit () at test.cc:14
#8 0x100021fc in void std::__invoke_impl(std::__invoke_other, void (*&&)()) (__f=)
#9 0x100020c4 in std::__invoke_result::type std::__invoke(void (*&&)()) (__fn=)
#10 0x10002cd4 in decltype (__invoke((_S_declval<0ul>)()))
std::thread::_Invoker
>::_M_invoke<0ul>(std::_Index_tuple<0ul>) (this=)
#11 0x10002c2c in std::thread::_Invoker >::operator()
(this=)
#12 0x10002b8c in
std::thread::_State_impl >
>::_M_run (this=)
#13 0xd18964d8 in execute_native_thread_routine () from
/opt/freeware/lib/gcc/powerpc-ibm-aix7.2.0.0/7.2.0/pthread/libstdc++.a(libstdc++.so.6)
#14 0xd0572f68 in _pthread_body () from /usr/lib/libpthreads.a(shr_xpg5.o)
#15 0x in ?? ()
[Bug c++/98348] GCC 10.2 AVX512 Mask regression from GCC 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98348
--- Comment #6 from Jakub Jelinek ---
In the light of the recent discussions I've been wondering about doing it as
combine splitters only, like roughly:
--- sse.md.jj 2020-12-03 10:04:35.862093285 +0100
+++ sse.md 2020-12-19 11:00:14.272140859 +0100
@@ -2965,6 +2965,40 @@
(set_attr "prefix" "vex")
(set_attr "mode" "")])
+(define_split
+ [(set (match_operand 0 "register_operand")
+ (vec_merge
+ (match_operand 1 "vector_all_ones_operand")
+ (match_operand 2 "const0_operand")
+ (unspec
+ [(match_operand 3 "register_operand")
+(match_operand 4 "nonimmediate_operand")
+(match_operand:SI 5 "const_0_to_31_operand")]
+UNSPEC_PCMP)))]
+ "TARGET_AVX512VL
+ && GET_MODE_CLASS (GET_MODE (operands[0])) == MODE_VECTOR_INT
+ && (GET_MODE_SIZE (GET_MODE (operands[1])) == 16
+ || GET_MODE_SIZE (GET_MODE (operands[1])) == 32)
+ && GET_MODE (operands[1]) == GET_MODE (operands[0])
+ && GET_MODE (operands[2]) == GET_MODE (operands[0])
+ && GET_MODE_CLASS (GET_MODE (operands[3])) == MODE_VECTOR_FLOAT
+ && (GET_MODE_SIZE (GET_MODE (operands[3]))
+ == GET_MODE_SIZE (GET_MODE (operands[0])))
+ && (GET_MODE_UNIT_SIZE (GET_MODE (operands[3]))
+ == GET_MODE_UNIT_SIZE (GET_MODE (operands[0])))
+ && GET_MODE (operands[4]) == GET_MODE (operands[3])"
+ [(set (match_dup 6) (match_dup 7))
+ (set (match_dup 0) (match_dup 8))]
+{
+ operands[6] = gen_reg_rtx (GET_MODE (operands[3]));
+ operands[7]
+= gen_rtx_UNSPEC (GET_MODE (operands[3]),
+ gen_rtvec (3, operands[3], operands[4], operands[5]),
+ UNSPEC_PCMP);
+ operands[8] = lowpart_subreg (GET_MODE (operands[0]), operands[6],
+ GET_MODE (operands[3]));
+})
+
(define_insn "avx_vmcmp3"
[(set (match_operand:VF_128 0 "register_operand" "=x")
(vec_merge:VF_128
The advantage is that one pattern can then handle in theory all (or half) of
the floating point comparison cases.
One problem is that combiner still doesn't even try the splitting if only
combining two insns.
Also, but I think that is in your patch too, vector_all_ones_operand will match
only integral all ones vectors, I think we want another predicate that will
match even MEMs with the floating point version thereof (a NaN kind with all
bits set). And, we should have splitters for not just the -1 0 order in
VEC_MERGE, but also the 0 -1 order by inverting the comparison carefully.
[Bug c++/98348] GCC 10.2 AVX512 Mask regression from GCC 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98348 --- Comment #7 from Jakub Jelinek --- Seems the adjustment for last UNSPEC_PCMP operand between all_ones, const0 and const0, all_ones is GEN_INT (INTVAL (operands[3]) ^ 4).
[Bug c++/98348] GCC 10.2 AVX512 Mask regression from GCC 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98348
--- Comment #8 from Jakub Jelinek ---
Created attachment 49806
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49806&action=edit
gcc11-pr98348.patch
So, if we go for GCC11 the way of pre-reload define_insn_and_split, this is
some incremental untested progress on your patch (just the sse.md part of it).
Changes:
1) it is undesirable to put SUBREGs on the SET_DEST side, as it prevents other
optimizations later on
2) I don't see the point on the TARGET_AVX512BW ||, the insn in the end is
plain AVX or AVX2 or SSE4* etc. one
3) handles also the const0 vector_all_ones order
4) for commutative cases allows any operand order, for others ensures the right
one of the operands is register
5) handles also the LE case by swapping the comparison operands
The patch doesn't handle the cases where based on the comparison one sets up
floating vectors, as can be seen e.g. in:
typedef float V128 __attribute__ ((vector_size(16)));
typedef float V256 __attribute__ ((vector_size(32)));
typedef float V512 __attribute__ ((vector_size(64)));
V128
foo (V128 x)
{
const union U { unsigned u; float f; } u = { -1U };
return x > 0.0f ? u.f : 0.0f;
}
V256
bar (V256 x)
{
const union U { unsigned u; float f; } u = { -1U };
return x > 0.0f ? u.f : 0.0f;
}
[Bug tree-optimization/98378] new valgrind error for ./gcc.c-torture/execute/pr60960.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98378 --- Comment #7 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:9032d2b2414ed22e53a9980a51b835d3caf83c48 commit r11-6269-g9032d2b2414ed22e53a9980a51b835d3caf83c48 Author: Jakub Jelinek Date: Sat Dec 19 12:46:40 2020 +0100 bswap: Fix up a thinko with empty CONSTRUCTORs [PR98378] The code I've added recently in find_bswap_or_nop for VECTOR CONSTRUCTORs is missing punt on an important case - namely empty CONSTRUCTORs, because in that case the loop will not initialize *n and the code after the loop will then use the uninitialized structure. 2020-12-19 Jakub Jelinek PR tree-optimization/98378 * gimple-ssa-store-merging.c (find_bswap_or_nop): Punt if CONSTRUCTOR has no elements.
[Bug libgomp/95150] Some offloaded programs crash with openmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95150 Chinoune changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WONTFIX |--- --- Comment #9 from Chinoune --- I get it with more examples.
[Bug libgomp/98391] New: Wrong results with small matrix size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98391 Bug ID: 98391 Summary: Wrong results with small matrix size Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: mehdi.chinoune at hotmail dot com CC: jakub at gcc dot gnu.org Target Milestone: --- $ cat matmul.f90 program main implicit none integer, parameter :: sp = selected_real_kind(6,37) integer :: i, j, k integer :: n character(len=5) :: var real(sp), allocatable :: a(:,:), b(:,:), c(:,:), cc(:,:) integer :: t1, t2, t3 real(sp) :: tic ! call get_command_argument( 1, var ) read( var, '(i5.3)') n print*, n ! allocate( a(n,n), b(n,n), c(n,n), cc(n,n) ) call random_number(a) call random_number(b) c = 0._sp ! call system_clock(t1, tic) cc = 0._sp do j = 1, n do k = 1, n do i = 1, n cc(i,j) = a(i,k)*b(k,j) + cc(i,j) end do end do end do call system_clock( t2 ) print*, "T1 = ", (t2-t1)/tic !$acc parallel loop collapse(3) copyin(a,b) copy(c) !$omp target teams distribute parallel do collapse(3) map( to:a,b) map( tofrom:c ) do j = 1, n do k = 1, n do i = 1, n c(i,j) = a(i,k)*b(k,j) + c(i,j) end do end do end do call system_clock(t3) print*, "T2 = ", (t3-t2)/tic ! print*, "Max(|C2-C1|) = ", maxval( abs(cc-c) ) print '(8(f8.6,x))', abs(cc-c) ! end program main $ gfortran-10 -fopenmp -foffload=nvptx-none matmul.f90 -o matmul.x $ ./matmul.x 16 16 T1 =0. T2 = 0.12995 Max(|C2-C1|) =1.94201875 1.431175 1.329625 0.592309 1.422428 0.535594 0.723758 0.365623 0.492199 0.108950 0.489844 1.100990 0.736585 1.182946 0.372061 0.185741 1.237249 0.629846 0.706569 0.913222 1.189827 0.617232 0.973922 0.290312 0.755902 0.886491 0.874653 1.642155 1.499317 1.506070 1.541327 1.228426 1.011003 0.967729 0.587790 0.353565 0.241555 0.283207 0.498868 0.628635 0.259884 0.469164 0.637377 0.428355 0.807801 0.409959 0.630940 0.384264 0.590675 0.805984 1.565366 0.850695 1.189638 1.602054 0.152907 0.648516 0.345356 0.261692 0.754292 0.995521 1.108027 0.837113 0.498883 1.011412 0.765647 0.741106 0.335977 0.721143 0.176006 0.169367 0.256758 0.311771 0.158323 0.401097 0.566629 0.787195 0.316571 0.179871 0.129046 0.326540 0.400939 1.898347 0.547532 1.015191 0.659491 0.223342 1.052599 1.158586 0.745466 0.491430 0.677603 0.854077 0.635704 0.475488 0.692096 0.749846 1.144690 0.712732 0.894958 0.874708 0.775818 0.674985 1.034302 1.350598 0.503635 0.082981 0.620052 0.888901 1.243073 1.147498 0.785260 0.260857 0.790078 0.571918 0.326864 0.090428 0.353512 0.167201 0.553904 0.378190 0.368513 0.238174 0.247996 0.038351 0.118958 0.041398 0.009377 0.049255 0.042368 1.942019 0.577147 1.252101 1.314539 0.845633 0.898366 1.743726 0.886740 0.674877 0.428364 0.431692 0.143040 0.551206 0.222548 0.058435 0.401517 0.172672 0.128829 0.063327 0.320080 0.120494 0.111500 0.341694 0.348082 0.408216 0.414768 0.706280 0.923327 0.265845 0.318310 0.082875 0.091210 1.165700 1.020596 0.282284 0.086616 0.350870 0.860692 0.299911 0.278247 0.756335 0.357223 0.633629 1.136913 0.815934 0.602087 0.790322 0.821650 1.006154 1.494015 0.950610 1.597616 0.962432 0.411526 1.268245 1.035166 0.755580 0.614513 1.165176 0.863545 0.478808 1.186599 1.245776 1.010780 1.108782 0.462348 0.980049 0.717201 1.594621 1.345250 1.080317 1.295755 0.406487 0.916595 1.325978 1.354560 1.209628 0.775334 1.611006 0.734939 0.604795 0.831590 0.316839 0.720204 0.739102 0.406983 0.807365 0.439079 0.654506 0.749812 1.219932 1.221502 0.534549 0.366653 0.989139 1.047143 0.643886 0.319602 0.621458 0.171583 0.052870 0.410973 0.266432 0.346806 0.124081 0.744631 0.876374 0.983852 1.121478 0.226588 0.390455 0.458977 0.646022 0.169284 0.593737 0.848242 1.612478 1.024757 1.028395 1.715509 1.202510 1.336850 1.219257 0.633523 0.988450 1.170813 0.852149 0.870198 It happens with both OpenACC and OpenMP.
[Bug tree-optimization/98378] new valgrind error for ./gcc.c-torture/execute/pr60960.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98378 --- Comment #8 from David Binderman --- I can provide, if requested, a list of other testsuite files that fail in the same way. This might be a good sanity check for Jakub's fix. Otherwise, I suggest that this bug could be marked as fixed.
[Bug tree-optimization/98378] new valgrind error for ./gcc.c-torture/execute/pr60960.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98378 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #9 from Jakub Jelinek --- .
[Bug libstdc++/98392] New: Parallel algorithms fail to enforce Mandates: requirements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98392
Bug ID: 98392
Summary: Parallel algorithms fail to enforce Mandates:
requirements
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
For example:
Mandates: All of
— binary_op(init, init),
— binary_op(init, unary_op(*first)),
— binary_op(unary_op(*first), init), and
— binary_op(unary_op(*first), unary_op(*first))
are convertible to T.
This was stated with "Requires:" in C++17, but in C++20 violating the
requirement must be diagnosed.
Example:
#include
#include
int main() {
int a[]{ 1 };
auto r = std::transform_reduce(
std::execution::seq, a, a+1, 0,
[](int& a, int b) {
return a + b;
},
[](int i) { return i; });
}
This compiles without error.
[Bug libstdc++/98389] [11 regression] libstdc++-abi/abi_check fails after r11-6249 on powerpc64 big endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98389
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed||2020-12-19
--- Comment #2 from Jonathan Wakely ---
(In reply to Andreas Schwab from comment #1)
> The list just needs to be updated.
No, those have version GLIBCXX_3.4.29 which is the current version, so new
symbols are allowed there.
The problem is this check in testsuite/util/testsuite_abi.cc:
// Check that long double compatibility symbols demangled as
// __float128 and regular __float128 symbols are put into some _LDBL_
// or _FLOAT128 version name.
if (added && test.demangled_name.find("__float128") != std::string::npos
&& test.demangled_name.find("std::__cxx11::") != 0)
I need to think about what the right fix is here (to change the test, or the
symbol versions of those symbols). That's unlikely to happen until January.
[Bug tree-optimization/98381] [11 Regression] Wrong code with -O3 -march=skylake-avx512 by r11-3072
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98381 H.J. Lu changed: What|Removed |Added CC||rguenther at suse dot de Last reconfirmed||2020-12-19 Summary|Wrong code with -O3 |[11 Regression] Wrong code |-march=skylake-avx512 |with -O3 ||-march=skylake-avx512 by ||r11-3072 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Target Milestone|--- |11.0 --- Comment #1 from H.J. Lu --- It is caused by r11-3072.
[Bug target/98387] GCC >= 6 cannot inline _mm_cmp_ps on SSE targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98387 H.J. Lu changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #2 from H.J. Lu --- _mm_cmp_ps is an AVX intrinsic.
[Bug target/98387] GCC >= 6 cannot inline _mm_cmp_ps on SSE targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98387 --- Comment #3 from Daniel Han-Chen --- (In reply to H.J. Lu from comment #2) > _mm_cmp_ps is an AVX intrinsic. Yep noticed _mm_cmp_ps is only in AVX. The weird part is it actually causes no errors when used on SSE only targets [ie Nehalem], and GCC continues compiling. Is this supposed to be normal behaivor?
[Bug c++/88413] g++ mangles names involving unresolved names in function argument template parameters differently from the ABI standard.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88413 Jason Merrill changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #11 from Jason Merrill --- Same issue. *** This bug has been marked as a duplicate of bug 67343 ***
[Bug c++/67343] C++ mangler does not follow ABI for local names in expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67343 Jason Merrill changed: What|Removed |Added CC||brennan at umanwizard dot com --- Comment #4 from Jason Merrill --- *** Bug 88413 has been marked as a duplicate of this bug. ***
[Bug c++/89818] possibly invalid name mangling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89818 Jason Merrill changed: What|Removed |Added Resolution|--- |DUPLICATE Status|ASSIGNED|RESOLVED --- Comment #3 from Jason Merrill --- Same issue. *** This bug has been marked as a duplicate of bug 67343 ***
[Bug c++/67343] C++ mangler does not follow ABI for local names in expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67343 Jason Merrill changed: What|Removed |Added CC||tromey at gcc dot gnu.org --- Comment #5 from Jason Merrill --- *** Bug 89818 has been marked as a duplicate of this bug. ***
[Bug c++/85648] Name mangling using decltype omits namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85648 Jason Merrill changed: What|Removed |Added Last reconfirmed||2020-12-19 Resolution|DUPLICATE |--- Ever confirmed|0 |1 Status|RESOLVED|ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org --- Comment #2 from Jason Merrill --- Actually a related issue, but not the same.
[Bug c/98393] New: new valgrind error for ./gcc.target/m68k/pr52573.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98393 Bug ID: 98393 Summary: new valgrind error for ./gcc.target/m68k/pr52573.c Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- A valgrind version of gcc trunk dated 20201206, with hash 8c23434fdadcf4ca, compiles testsuite file ./gcc.target/m68k/pr52573.c fine with compiler flag -O3 on x86_64. A week later, gcc trunk dated 20201211, with hash 97b56dece7413839, does this: ==11710== Conditional jump or move depends on uninitialised value(s) ==11710==at 0xE9DC54: vect_build_slp_instance(vec_info*, slp_instance_kind, vec<_stmt_vec_info*, va_heap, vl_p tr>&, _stmt_vec_info*, unsigned int, unsigned int*, hash_map, _slp_tree*, simple_has hmap_traits >*, _stmt_vec_info*) (tree-vect-slp.c:2396) The problem remains a week later in gcc trunk dated 20201218. I will have a look with git bisect.
[Bug target/98382] [m68k] ICE: in output_move_qimode, at config/m68k/m68k.c:3284 when building webkit2gtk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98382 Mikael Pettersson changed: What|Removed |Added CC||mikpelinux at gmail dot com --- Comment #2 from Mikael Pettersson --- Are you sure about the "recently"? I get ICEs with crosses based on gcc-11-20201213, gcc-10.2.0, gcc-10.1.0, and gcc-9-20201218 (so pre-CC0 conversion). A reduced test case would help.
[Bug c/98393] new valgrind error for ./gcc.target/m68k/pr52573.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98393 --- Comment #1 from David Binderman --- Trying hash f6e8e2797ebae21e.
[Bug target/98387] GCC >= 6 cannot inline _mm_cmp_ps on SSE targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98387 --- Comment #4 from H.J. Lu --- (In reply to Daniel Han-Chen from comment #3) > (In reply to H.J. Lu from comment #2) > > _mm_cmp_ps is an AVX intrinsic. > > Yep noticed _mm_cmp_ps is only in AVX. The weird part is it actually causes > no errors when used on SSE only targets [ie Nehalem], and GCC continues > compiling. > > Is this supposed to be normal behaivor? GCC treats it like an undefined function.
[Bug c++/98394] New: Concept with auto... template parameter pack in if-statement causes compilation error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98394
Bug ID: 98394
Summary: Concept with auto... template parameter pack in
if-statement causes compilation error
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ngmr80 at web dot de
Target Milestone: ---
Created attachment 49807
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49807&action=edit
Preprocessed source
In C++20, when using a concept 'C' with an auto... template parameter pack in
an if-statement, the compiler reports the error "'C' does not constrain a
type.". The same concept, however, _is_ usable in other contexts.
Example:
template
concept C = true;
int main()
{
auto b = C<1, 2>; // ok
if (C<1, 2>); // error
}
--
Output of g++-10 -v -save-temps -std=c++20 main.cpp
Using built-in specs.
COLLECT_GCC=g++-10
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/10/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
10.1.0-2ubuntu1~18.04' --with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-10
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-10-eDoCEC/gcc-10-10.1.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-10-eDoCEC/gcc-10-10.1.0/debian/tmp-gcn/usr,hsa
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.1.0 (Ubuntu 10.1.0-2ubuntu1~18.04)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++2a' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-linux-gnu/10/cc1plus -E -quiet -v -imultiarch
x86_64-linux-gnu -D_GNU_SOURCE main.cpp -mtune=generic -march=x86-64 -std=c++2a
-fpch-preprocess -fasynchronous-unwind-tables -fstack-protector-strong -Wformat
-Wformat-security -o main.ii
ignoring duplicate directory "/usr/include/x86_64-linux-gnu/c++/10"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/10/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/10/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/include/c++/10
/usr/include/x86_64-linux-gnu/c++/10
/usr/include/c++/10/backward
/usr/lib/gcc/x86_64-linux-gnu/10/include
/usr/local/include
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++2a' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-linux-gnu/10/cc1plus -fpreprocessed main.ii -quiet
-dumpbase main.cpp -mtune=generic -march=x86-64 -auxbase main -std=c++2a
-version -fasynchronous-unwind-tables -fstack-protector-strong -Wformat
-Wformat-security -o main.s
GNU C++17 (Ubuntu 10.1.0-2ubuntu1~18.04) version 10.1.0 (x86_64-linux-gnu)
compiled by GNU C version 10.1.0, GMP version 6.1.2, MPFR version
4.0.1, MPC version 1.1.0, isl version isl-0.19-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++17 (Ubuntu 10.1.0-2ubuntu1~18.04) version 10.1.0 (x86_64-linux-gnu)
compiled by GNU C version 10.1.0, GMP version 6.1.2, MPFR version
4.0.1, MPC version 1.1.0, isl version isl-0.19-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 435c9a72f92ce04eba08a47828fa63c4
main.cpp: In function ‘int main()’:
main.cpp:7:9: error: ‘C’ does not constrain a type
7 | if (C<1, 2>); // error
| ^~~
main.cpp:2:9: note: concept defined here
2 | concept C = true;
| ^
[Bug target/98382] [m68k] ICE: in output_move_qimode, at config/m68k/m68k.c:3284 when building webkit2gtk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98382 --- Comment #3 from John Paul Adrian Glaubitz --- (In reply to Mikael Pettersson from comment #2) > Are you sure about the "recently"? I get ICEs with crosses based on > gcc-11-20201213, gcc-10.2.0, gcc-10.1.0, and gcc-9-20201218 (so pre-CC0 > conversion). webkit2gtk buildt fine with gcc-10_10.2.0 on Debian: > https://buildd.debian.org/status/fetch.php?pkg=webkit2gtk&arch=m68k&ver=2.28.4-1&stamp=1597349482&raw=0 > A reduced test case would help. I have been asked to do that for another PR as well but I haven't done this before so it'll take some time until I will be able to provide reduced testcases.
[Bug libgcc/98395] New: libgcc_s.so.1 almost 10x bigger in gcc-10.2 than gcc-9.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98395 Bug ID: 98395 Summary: libgcc_s.so.1 almost 10x bigger in gcc-10.2 than gcc-9.2 Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: john.frankish at outlook dot com Target Milestone: --- The libgcc_s.so.1 library built with gcc-10.2 is 580kb, whereas the same library built with gcc-9.2 is 75kb. Both were built on an x86_64 system with: CC="gcc -mtune=generic -Os -pipe" CXX="g++ -mtune=generic -Os -pipe" ../configure --prefix=/usr/local --enable-languages=c,c++ --disable-multilib --disable-bootstrap --with-system-zlib --libexecdir=/usr/local/lib The almost ten-fold increase in size would seem to indicate something is wrong, but what?
[Bug fortran/98307] Dependency check fails when using "allocatable" instead of "pointer" (forall_3.f90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98307 --- Comment #5 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:4e9563cda3f841f26f2ad1d9961dd6ffc9f39146 commit r10-9160-g4e9563cda3f841f26f2ad1d9961dd6ffc9f39146 Author: Harald Anlauf Date: Thu Dec 17 10:31:55 2020 +0100 PR fortran/98307 - Dependency check fails when using "allocatable" The dependency check for FORALL constructs already handled pointer components to derived types, but missed allocatables. Fix that. gcc/fortran/ChangeLog: PR fortran/98307 * trans-stmt.c (check_forall_dependencies): Extend dependency check to allocatable components of derived types. gcc/testsuite/ChangeLog: PR fortran/98307 * gfortran.dg/forall_19.f90: New test. (cherry picked from commit c09deceb534b82ce144af3a345dcb06ab5e49ba4)
[Bug libgcc/98395] libgcc_s.so.1 almost 10x bigger in gcc-10.2 than gcc-9.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98395 --- Comment #1 from Andreas Schwab --- What does size tell?
[Bug libgcc/98395] libgcc_s.so.1 almost 10x bigger in gcc-10.2 than gcc-9.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98395 --- Comment #2 from john.frankish at outlook dot com --- Something significant must have changed, or be wrong, for such a big increase in size
[Bug d/98067] [11 Regression] d: ICE in in force_decl_die, at dwarf2out.c:26197 with -gdwarf-2 -gstrict-dwarf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98067 --- Comment #10 from CVS Commits --- The master branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:e9e4ddfc5abbf9ee5e657d626264cef89f10b4c3 commit r11-6270-ge9e4ddfc5abbf9ee5e657d626264cef89f10b4c3 Author: Iain Buclaw Date: Wed Dec 16 00:17:40 2020 +0100 d: Fix ICE in in force_decl_die, at dwarf2out.c with -gdwarf-2 -gstrict-dwarf [PR98067] Manifest constants in D are represented as CONST_DECLs, which can be imported from one module to another. However, when compiling on strict dwarf2 targets such as *-*-darwin10, importing CONST_DECLs cannot be represented in debug as D did not exist as an AT_language until dwarf3, and the only available fallback being DW_LANG_C. As CONST_DECLs are treated as enumerators in C, and not outputted individually in gen_decl_die, this causes an internal error in force_decl_die to occur. To handle this, similar to other places in dwarf2out, if a CONST_DECL is seen in dwarf2out_imported_module_or_decl_1, then we simply return early if the language is not one of Ada, D, or Fortran. gcc/ChangeLog: PR d/98067 * dwarf2out.c (dwarf2out_imported_module_or_decl_1): Handle CONST_DECL only if is_fortran, is_ada, or is_dlang. gcc/testsuite/ChangeLog: PR d/98067 * gdc.dg/debug/debug.exp: New test. * gdc.dg/debug/dwarf2/dwarf2.exp: New test. * gdc.dg/debug/dwarf2/imports/pr98067.d: New test. * gdc.dg/debug/dwarf2/langdw2.d: New test. * gdc.dg/debug/dwarf2/langdw3.d: New test. * gdc.dg/debug/dwarf2/pr98067.d: New test. * gdc.dg/debug/trivial.d: New test.
[Bug libgcc/98395] libgcc_s.so.1 almost 10x bigger in gcc-10.2 than gcc-9.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98395 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Most likely one is stripped and the other is not. I didn't build with -Os, but the 9.x to 10.x difference is fairly small: gcc 9 libgcc]$ size libgcc_s.so.1 textdata bss dec hex filename 90562 992 688 92242 16852 libgcc_s.so.1 gcc 10 libgcc]$ size libgcc_s.so.1 textdata bss dec hex filename 92530 992 680 94202 16ffa libgcc_s.so.1
[Bug d/98058] libphobos: Support building on *-*-darwin*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98058 Bug 98058 depends on bug 98067, which changed state. Bug 98067 Summary: [11 Regression] d: ICE in in force_decl_die, at dwarf2out.c:26197 with -gdwarf-2 -gstrict-dwarf https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98067 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug d/98067] [11 Regression] d: ICE in in force_decl_die, at dwarf2out.c:26197 with -gdwarf-2 -gstrict-dwarf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98067 Iain Buclaw changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Iain Buclaw --- Fix committed.
[Bug c/98396] New: gcc wrongly assumes that free preserves errno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98396 Bug ID: 98396 Summary: gcc wrongly assumes that free preserves errno Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: bruno at clisp dot org Target Milestone: --- Created attachment 49808 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49808&action=edit Test case On POSIX systems, free() can clobber the value of errno. This is implied by 1) https://pubs.opengroup.org/onlinepubs/9699919799/functions/errno.html which says: "The setting of errno after a successful call to a function is unspecified unless the description of that function specifies that errno shall not be modified." and 2) https://pubs.opengroup.org/onlinepubs/9699919799/functions/free.html which does not mention errno. A future version of POSIX will specify that a valid call to free() preserves errno: https://www.austingroupbugs.net/view.php?id=385 . But this is not yet standard. In particular, on Linux/glibc systems, the glibc bug https://sourceware.org/bugzilla/show_bug.cgi?id=17924 is still open, because glibc does not guarantee that free() preserves errno — neither through the code nor through the documentation. This glibc bug even has a test case of a successful free() that sets errno to ENOMEM (via a call to munmap). But GCC, when optimizing, eliminates tests of errno or assignments to errno after 'free (ptr);' where ptr was the result of a malloc(...) call in the same function. How to reproduce: $ gcc -O2 -S foo.c Inspect the resulting foo.s. You see that - In function 'check_errno_unmodified', GCC has eliminated the lines if (errno != 1789) abort (); - In function 'ensure_errno_unmodified', GCC has eliminated the lines int saved_errno = errno; and errno = saved_errno; So, while the programmer knew that free() can clobber errno and added statements to ensure that errno gets preserved, GCC optimized these statements away!
[Bug c/98396] gcc wrongly assumes that free preserves errno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98396 Bruno Haible changed: What|Removed |Added Known to work||4.0.4, 4.1.2, 4.2.4, 4.3.6, ||4.4.7, 4.5.4, 4.6.4, 4.7.3, ||4.8.5 Known to fail||10.2.0, 4.9.4, 5.5.0, ||6.5.0, 7.5.0, 8.4.0, 9.3.0 Target||x86_64-pc-linux-gnu Build||x86_64-pc-linux-gnu Host||x86_64-pc-linux-gnu --- Comment #1 from Bruno Haible --- Related: bug 88576, bug 98070.
[Bug middle-end/98366] [11 Regression] wrong-code with memcmp and -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98366 --- Comment #7 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:69165332a914f1167c3077fa1f57afc64fd8a667 commit r11-6271-g69165332a914f1167c3077fa1f57afc64fd8a667 Author: Jakub Jelinek Date: Sat Dec 19 22:24:10 2020 +0100 expr: Fix up constant_byte_string bitfield handling [PR98366] constant_byte_string now uses a convert_to_bytes function, which doesn't handle bitfields at all (don't punt on them, just puts them into wrong bits or bytes). Furthermore, I don't see a reason why that function should exist at all, it duplicates native_encode_initializer functionality. Except that native_encode_initializer punted on flexible array members and 2 tests in the testsuite relied on constant_byte_string handling those. So, this patch throws away convert_to_bytes, uses native_encode_initializer instead, but teaches it to handle flexible array members (only in the non-mask mode with off == -1 for now), furthermore, it adds various corner case checks that the old implementation was missing (like that STRING_CSTs use int as length and therefore we shouldn't try to build larger than that strings, or that native_encode*/native_interpret* APIs require sane host and target bytes (8-bit on both). 2020-12-19 Jakub Jelinek PR middle-end/98366 * fold-const.c (native_encode_initializer): Don't try to memset more than total_bytes with off == -1 even if len is large. Handle flexible array member initializers if off == -1 and mask is NULL. * expr.c (convert_to_bytes): Remove. (constant_byte_string): Use native_encode_initializer instead of convert_to_bytes. Remove extraneous semicolon. Punt on various corner-cases the APIs don't handle, like sizes > INT_MAX, BITS_PER_UNIT != 8, CHAR_BIT != 8. * gcc.c-torture/execute/pr98366.c: New test.
[Bug middle-end/98366] [11 Regression] wrong-code with memcmp and -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98366 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Jakub Jelinek --- Fixed.
[Bug libgcc/98395] libgcc_s.so.1 almost 10x bigger in gcc-10.2 than gcc-9.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98395 --- Comment #4 from john.frankish at outlook dot com --- Both are stripped and all the other gcc libs are of comparable size between gcc-9.2 and gcc-10.2. I'll compile with -O2 instead of -Os in the next couple of days to see if that makes a difference.
[Bug c/98393] new valgrind error for ./gcc.target/m68k/pr52573.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98393 --- Comment #2 from David Binderman --- Seems good, so range reduces to f6e8e2797ebae21e..97b56dece7413839 Trying 4cf70c20cb10acd6
[Bug fortran/93685] [9/10/11 Regression] ICE in gfc_constructor_append_expr, at fortran/constructor.c:135
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93685 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code CC||anlauf at gcc dot gnu.org --- Comment #3 from anlauf at gcc dot gnu.org --- (In reply to markeggleston from comment #1) > I think the issues of error messages and -std can be postponed until the > next release. The current status is that program p type u integer, pointer :: i end type u type(u) :: y integer , target :: i = 10 data y%i /i/ print *, y%i end works with current master, while the (valid) code program p type t character, pointer :: a end type t type(t) :: x character, target :: c = 'c' data x%a /c/ print *, x%a end still ICEs the same as the (invalid) testcase in comment#0.
[Bug c++/93480] Defaulted <=> doesn't expand array elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93480
--- Comment #2 from Will Wray ---
For reference, here's a macro-free workaround to provide portable
operator<=> for templated classes with array members, defaulting
where possible (current Clang and MSVC) otherwise dispatching to
a user-defined implementation (current gcc)
https://godbolt.org/z/qbEfh7
First, a trait to check default 3-way array compare:
inline constexpr bool has_default_array_compare = [] {
struct C {
char c[1];
auto operator<=>(C const&) const = default;
};
return std::three_way_comparable;
}();
Then constrain the operator<=> definitions
template struct array
{
T data[N];
friend auto operator<=>(array const&, array const&)
requires has_default_array_compare = default;
friend constexpr auto operator<=>(array const& l,
array const& r)
requires (!has_default_array_compare)
{
return compare_three_way{}(l.data,r.data);
}
};
However, this only works for templated classes
as it is not (yet) allowed to constrain non-template functions.
[Bug fortran/92065] [8/9/10/11 Regression] internal compiler error: in expand_expr_real_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065 Gabor changed: What|Removed |Added CC||gtoth at umich dot edu --- Comment #6 from Gabor --- I have the same problem with gfortran 9 and gfortran 10. After 17 years of Fortran 2003, one would hope to be able to use it.
[Bug c/98393] new valgrind error for ./gcc.target/m68k/pr52573.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98393 --- Comment #3 from David Binderman --- Seems ok, so range reduces to 4cf70c20cb10acd6..97b56dece7413839 Trying 7f359556a772e26e
[Bug c/98393] new valgrind error for ./gcc.target/m68k/pr52573.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98393 --- Comment #4 from David Binderman --- Seems good, so range reduces to 7f359556a772e26e..97b56dece7413839 Trying 1423318fa7786493
[Bug c/98393] new valgrind error for ./gcc.target/m68k/pr52573.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98393 --- Comment #5 from David Binderman --- Range so far seems to be 7f359556a772e26e..1423318fa7786493 Trying fa4a8b6463e0dbc2
[Bug c/98393] new valgrind error for ./gcc.target/m68k/pr52573.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98393 David Binderman changed: What|Removed |Added CC||rguenther at suse dot de --- Comment #6 from David Binderman --- So commit fc7b4248172561a9ee310e2d43d8a485a5c9e108 appears to be the culprit. May I ask Richard to confirm my git bisect analysis ?
[Bug c/98397] New: C2X: pointers to arrays with qualifiers are now pointers to qualified types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98397
Bug ID: 98397
Summary: C2X: pointers to arrays with qualifiers are now
pointers to qualified types
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: muecker at gwdg dot de
Target Milestone: ---
C2X mostly adopted the rules already implemented in GCC as an extension.
Still, there are two issues:
1. Some pedantic warning should not appear anymore in C2X.
2. The qualifier of a void pointer returned by the tertiary
operator changes in C2X when the one of the pointers points
to an array with qualified type. (This is then also consistent
with C++ and clang)
The following code should compile:
void foo(void)
{
const int (*u)[1];
void *v;
extern const void *vc;
extern typeof(1 ? u : v) vc;
extern typeof(1 ? v : u) vc;
}
I have a patch for this in preparation.
[Bug fortran/92065] [8/9/10/11 Regression] internal compiler error: in expand_expr_real_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #7 from kargl at gcc dot gnu.org --- (In reply to Gabor from comment #6) > I have the same problem with gfortran 9 and gfortran 10. After 17 years of > Fortran 2003, one would hope to be able to use it. You forgot to attach your patch that fixes this issue. gfortran is mostly maintained and written by a dwindling number of volunteers. Comments like your second sentence above is not exactly motivating. HTH
[Bug fortran/92065] [8/9/10/11 Regression] internal compiler error: in expand_expr_real_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065 --- Comment #8 from Gabor --- Dear HTH, Apparently this bug was reported years ago, and it was not fixed. There was no suggestion on how to avoid it either. I am not sure why gfortran is not supported by GNU, as it is used heavily in the computational physics community and gfortran is one of the compilers (the other is ifort) installed on supercomputers around the world. There are millions and millions of lines of code depending on Fortran and there are 10s of thousands of scientists and students using these codes. The only hope to adopt new (meaning beyond F77 and F90) features of Fortran by the community is to have compilers that can handle these new features. Why am I wasting time to write a nice piece of code (in this case a general interpolation routine that can handle any type of numbers) if in the end I get a compiler internal error. nagfor can handle it, ifort can handle it, gfortran cannot. And gfortran is one of the MAIN fortran compilers. So now I have to dumb down my code to the usual cut-and-paste style, repetition and so on, because I cannot use class(*). So I am frustrated. And maybe my frustration will motivate you to fix the problem. Thank you, Gabor > On Dec 19, 2020, at 6:17 PM, kargl at gcc dot gnu.org > wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065 > > kargl at gcc dot gnu.org changed: > > What|Removed |Added > > CC||kargl at gcc dot gnu.org > > --- Comment #7 from kargl at gcc dot gnu.org --- > (In reply to Gabor from comment #6) >> I have the same problem with gfortran 9 and gfortran 10. After 17 years of >> Fortran 2003, one would hope to be able to use it. > > You forgot to attach your patch that fixes this issue. > > gfortran is mostly maintained and written by a dwindling number > of volunteers. Comments like your second sentence above is not > exactly motivating. > > HTH > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug fortran/92065] [8/9/10/11 Regression] internal compiler error: in expand_expr_real_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065 --- Comment #9 from Steve Kargl --- On Sat, Dec 19, 2020 at 11:35:24PM +, gtoth at umich dot edu wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065 > > > Apparently this bug was reported years ago, and it was not fixed. There was no > suggestion on how to avoid it either. > > I am not sure why gfortran is not supported by GNU, as it is used heavily in > the computational physics community and gfortran is one of the compilers (the > other is ifort) installed on supercomputers around the world. There are > millions and millions of lines of code depending on Fortran and there are 10s > of thousands of scientists and students using these codes. The only hope to > adopt new (meaning beyond F77 and F90) features of Fortran by the community is > to have compilers that can handle these new features. Why am I wasting time to > write a nice piece of code (in this case a general interpolation routine that > can handle any type of numbers) if in the end I get a compiler internal error. > nagfor can handle it, ifort can handle it, gfortran cannot. And gfortran is > one > of the MAIN fortran compilers. So now I have to dumb down my code to the usual > cut-and-paste style, repetition and so on, because I cannot use class(*). > > So I am frustrated. And maybe my frustration will motivate you to fix the > problem. > Apparently, you missed the word "volunteer". How much did you (and others) pay in ifort and nagfor licenses and support contracts? No one is willing to pay for general maintianence of gfortran. At best, you may find someone willing to pay for a specific feature (e.g., ORNL's support for work on openacc). I've fixed 100s of bugs and implemented some new features for gfortran. Many of my fixes are for bugs that affected my own Fortran code. Some are for bugs in areas of the compiler I know well. I've also reviewed 100s of patches by others. I do not use the OOP features of Fortran, so I have very little knowledge about its implementation details. So, your SOL if you're waiting for me to fix this bug. Rants, like yours here, are one of two reasons why I've stopped contributing to gfortran. I will no longer review patches, and if I submit a patch, it will be to fix a bug affecting my code.
[Bug demangler/98398] New: demangler fails on function parameter from enclosing parameter-type-list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98398
Bug ID: 98398
Summary: demangler fails on function parameter from enclosing
parameter-type-list
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: demangler
Assignee: unassigned at gcc dot gnu.org
Reporter: jason at gcc dot gnu.org
Target Milestone: ---
A subset of g++.dg/abi/mangle45.C:
template void f(T p, decltype(p)) { }
int main()
{
f (1,0);
}
This produces the symbol
_Z1fIiEvT_DtfL0p_E
wher fL0p_ means the first function parameter from the first enclosing
parameter-type-list. The demangler doesn't currently handle the fLp form at
all; it tries to demangle it as a binary left fold expression, which also uses
fL, but not followed by a digit.
[Bug target/98387] GCC >= 6 cannot inline _mm_cmp_ps on SSE targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98387 --- Comment #5 from Daniel Han-Chen --- (In reply to H.J. Lu from comment #4) > (In reply to Daniel Han-Chen from comment #3) > > (In reply to H.J. Lu from comment #2) > > > _mm_cmp_ps is an AVX intrinsic. > > > > Yep noticed _mm_cmp_ps is only in AVX. The weird part is it actually causes > > no errors when used on SSE only targets [ie Nehalem], and GCC continues > > compiling. > > > > Is this supposed to be normal behaivor? > > GCC treats it like an undefined function. Thanks! Sorry I probably might have asked some really dumb questions. But also thanks for taking your time in answering them! :) Appreciate it!
[Bug fortran/92065] [8/9/10/11 Regression] internal compiler error: in expand_expr_real_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065 --- Comment #10 from Gabor --- Good to know that gfortran has come to an end. It means, for example, that i will not rely on the openacc implementation either. Or openmp5. I develop software as part of my work, and when someone reports a bug, my reaction is to try to fix it, not giving a lecture to the user. I am not a compiler developer. I have interacted with various compiler developer groups, including Intel, nag and pgi. Not all of them are equally good or competent or quick, but at least they don't try to push the blame on the user. If you haven't fixed a bug for years, why do you respond to a complaint about it the same day? Gábor On Sat, Dec 19, 2020, 7:02 PM sgk at troutmask dot apl.washington.edu < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065 > > --- Comment #9 from Steve Kargl > --- > On Sat, Dec 19, 2020 at 11:35:24PM +, gtoth at umich dot edu wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065 > > > > > > Apparently this bug was reported years ago, and it was not fixed. There > was no > > suggestion on how to avoid it either. > > > > I am not sure why gfortran is not supported by GNU, as it is used > heavily in > > the computational physics community and gfortran is one of the compilers > (the > > other is ifort) installed on supercomputers around the world. There are > > millions and millions of lines of code depending on Fortran and there > are 10s > > of thousands of scientists and students using these codes. The only hope > to > > adopt new (meaning beyond F77 and F90) features of Fortran by the > community is > > to have compilers that can handle these new features. Why am I wasting > time to > > write a nice piece of code (in this case a general interpolation routine > that > > can handle any type of numbers) if in the end I get a compiler internal > error. > > nagfor can handle it, ifort can handle it, gfortran cannot. And gfortran > is one > > of the MAIN fortran compilers. So now I have to dumb down my code to the > usual > > cut-and-paste style, repetition and so on, because I cannot use > class(*). > > > > So I am frustrated. And maybe my frustration will motivate you to fix the > > problem. > > > > Apparently, you missed the word "volunteer". How much did you > (and others) pay in ifort and nagfor licenses and support > contracts? No one is willing to pay for general maintianence > of gfortran. At best, you may find someone willing to pay for > a specific feature (e.g., ORNL's support for work on openacc). > I've fixed 100s of bugs and implemented some new features for > gfortran. Many of my fixes are for bugs that affected my own > Fortran code. Some are for bugs in areas of the compiler I > know well. I've also reviewed 100s of patches by others. > I do not use the OOP features of Fortran, so I have very little > knowledge about its implementation details. So, your SOL > if you're waiting for me to fix this bug. > > Rants, like yours here, are one of two reasons why I've > stopped contributing to gfortran. I will no longer review > patches, and if I submit a patch, it will be to fix a bug > affecting my code. > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug fortran/92065] [8/9/10/11 Regression] internal compiler error: in expand_expr_real_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065 --- Comment #11 from Steve Kargl --- On Sun, Dec 20, 2020 at 05:24:53AM +, gtoth at umich dot edu wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065 > > --- Comment #10 from Gabor --- > Good to know that gfortran has come to an end. It means, for example, that > i will not rely on the openacc implementation either. Or openmp5. Seems you have reading comprehension problems. I never stated that gfortran is coming to an end. I stated that I will no longer submit patches or review patches, because of the abuse spewed by users. Almost all individuals that maintain gfortran are VOLUNTEERS. Abuse from users is causing volunteers to find others things to do with their FREE TIME. > I develop software as part of my work, and when someone reports a bug, my > reaction is to try to fix it, not giving a lecture to the user. I am not a > compiler developer. I am not a compiler developer either. I was a volunteer who gave back his patches to the community. 22% of gfortran/libgfortran bugs fixed in 2019 were by me. Snide, backhanded, comments such as After 17 years of Fortran 2003, one would hope to be able to use it. simply do not motivate a volunteer to work on a bug that does not affect him. > I have interacted with various compiler developer > groups, including Intel, nag and pgi. Not all of them are equally good or > competent or quick, but at least they don't try to push the blame on the > user. No one is blaming you for a bug or reporting a bug. I am reacting to your passive aggressive comment. Yeah, we all would like to "After 17 years of Fortran 2003, ... use it." Guess what? Volunteers fix bugs and implement the features in the Fortran standards in their FREE TIME. Instead of harping on those that give you a gift, get involved and fix a bug in the compiler or pay someone to do it for you. > If you haven't fixed a bug for years, why do you respond to a > complaint about it the same day? PR 92065 was reported on 2019-10-11. That's a little over a year ago. Not sure where you got "years".
