[Bug libfortran/95293] Fortran not passing array by reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95293 --- Comment #5 from Steve Kargl --- On Sun, May 24, 2020 at 06:47:18AM +, tkoenig at gcc dot gnu.org wrote: > > and the effective argument has the TARGET attribute > > That I will have to look up; if a has the TARGET attribute, > does a%b have it as well? > You're looking for If an object has the TARGET attribute, then all of its nonpointer subobjects also have the TARGET attribute. I believe it does not matter. The effective argument is s1%cc%cbar. The subroutine sub2() accesses s1%cc(2)%cbar via host association. I've quoted the relevant part of the standard that says an effective should be accessed via the dummy argument. You basically have an aliasing problem where something is known by a dummy argument and by host association. It's a rather questionable programming idiom. Consider, program foo real x x = 42 call bar(x) print *, x contains subroutine bar(a) real, intent(inout) :: a a = 12 x = 0 end subroutine bar end program foo Should this print 12 or 0? When bar returns 'a' has a value of 12, should this value be transferred to 'x' before the print statement is executed?
[Bug c++/95301] New: excessive error messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95301
Bug ID: 95301
Summary: excessive error messages
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: wouter at voti dot nl
Target Milestone: ---
This code emits an excessive amount of error messages, which seem to repeat.
Detected on windows using 10.0.1, but compiler exporer gives the same effect
with 10.1
https://godbolt.org/z/AY5m-b
template< typename T = int_fast64_t, T zero = 0 >
class xy final { };
template< typename T, T v >
class range {
xy< T, v > start;
xy< T, v > limit;
public:
range( xy< T, v > limit ):
start( limit::zero, limit( limit ) // wovo missing ) after zero
{}
};
template<>
struct box_root< bool > : _box_root< bool > {};
template< typename T >
struct _no_inline_box_init : T {};
template< typename T >
struct _no_inline_box_write : T {};
template< typename T >
struct _no_inline_box_read : T {};
template< typename T >
struct _no_inline_box_direction : T {};
template< typename T >
using no_inline =
_no_inline_box_init<
_no_inline_box_write<
_no_inline_box_read<
_no_inline_box_direction< T > > > >;
[Bug libstdc++/95079] unorderd_map::insert_or_assign and try_emplace should only hash and mod once unless there is a rehash.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95079 François Dumont changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |fdumont at gcc dot gnu.org Status|NEW |ASSIGNED CC||fdumont at gcc dot gnu.org --- Comment #2 from François Dumont --- I'd like to take this one and already started working on it. I've already many patches awaiting for the hashtable implementation but none fixing this problem. I also don't get the point about std::unordered_map performance issue on 64-bits platform. Maybe you should elaborate as part of another bug report.
[Bug c++/95302] New: function attributed to be deprecated cannot include a typedef/using
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95302
Bug ID: 95302
Summary: function attributed to be deprecated cannot include a
typedef/using
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: shyou...@ruby-lang.org
Target Milestone: ---
https://gcc.godbolt.org/z/iH643m
Is this intentional? No other compiler that I know warns this code.
% cat tmp.cc
[[deprecated(">>>GCC BUG<<<")]]
void func(void)
{
typedef int type;
type(var);
}
% g++-10 -v -c tmp.cc
Using built-in specs.
COLLECT_GCC=g++-10
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' '-c' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-linux-gnu/10/cc1plus -quiet -v -imultiarch
x86_64-linux-gnu -D_GNU_SOURCE tmp.cc -quiet -dumpbase tmp.cc -mtune=generic
-march=x86-64 -auxbase tmp -version -fasynchronous-unwind-tables
-fstack-protector-strong -Wformat -Wformat-security -o /tmp/ccz4O9iB.s
GNU C++14 (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
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.
GNU C++14 (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
tmp.cc: In function 'void func()':
tmp.cc:5:13: warning: 'void func()' is deprecated: >>>GCC BUG<<<
[-Wdeprecated-declarations]
5 | type(var);
| ^
tmp.cc:2:6: note: declared here
2 | void func(void)
| ^~~~
COLLECT_GCC_OPTIONS='-v' '-c' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
as -v --64 -o tmp.o /tmp/ccz4O9iB.s
GNU assembler version 2.30 (x86_64-linux-gnu) using BFD version (GNU Binutils
for Ubuntu) 2.30
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/10/:/usr/lib/gcc/x86_64-linux-gnu/10/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/10/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/10/:/usr/lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/10/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/10/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-c' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
[Bug c++/95303] New: Member type of class template is incorrectly printed in diagnostics when it fails to satisfy a concept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95303
Bug ID: 95303
Summary: Member type of class template is incorrectly printed
in diagnostics when it fails to satisfy a concept
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ensadc at mailnesia dot com
CC: asutton at gcc dot gnu.org
Target Milestone: ---
https://godbolt.org/z/F5Hj38
template
struct A {
struct B {};
};
template
concept C = requires (T&& t) {
t.a;
};
static_assert(C::B>);
:11:15: error: static assertion failed
11 | static_assert(C::B>);
| ^~~~
:11:15: note: constraints not satisfied
:7:9: required by the constraints of 'template concept C'
:7:13: in requirements with 'T&& t' [with T = A::B]
:8:7: note: the required expression 't.a' is invalid
8 | t.a;
| ~~^
cc1plus: note: set '-fconcepts-diagnostics-depth=' to at least 2 for more
detail
Note '[with T = A::B]'. It should be '[with T = A::B]', without
the second ``.
[Bug target/95258] -march=native doesn't handle -mavx512vpopcntdq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95258 --- Comment #3 from CVS Commits --- The releases/gcc-10 branch has been updated by H.J. Lu : https://gcc.gnu.org/g:af216f799553b9306cb662fc303412a244215ec5 commit r10-8176-gaf216f799553b9306cb662fc303412a244215ec5 Author: H.J. Lu Date: Fri May 22 04:18:34 2020 -0700 x86: Handle -mavx512vpopcntdq for -march=native Add -mavx512vpopcntdq for -march=native if AVX512VPOPCNTDQ is available. PR target/95258 * config/i386/driver-i386.c (host_detect_local_cpu): Detect AVX512VPOPCNTDQ. (cherry picked from commit 808b611bfb4b05703ea174e50874c711dca44c98)
[Bug target/95258] -march=native doesn't handle -mavx512vpopcntdq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95258 --- Comment #4 from CVS Commits --- The releases/gcc-9 branch has been updated by H.J. Lu : https://gcc.gnu.org/g:81e65b210d33bad3e9263cd74fd8eca775df6ff9 commit r9-8618-g81e65b210d33bad3e9263cd74fd8eca775df6ff9 Author: H.J. Lu Date: Fri May 22 04:18:34 2020 -0700 x86: Handle -mavx512vpopcntdq for -march=native Add -mavx512vpopcntdq for -march=native if AVX512VPOPCNTDQ is available. PR target/95258 * config/i386/driver-i386.c (host_detect_local_cpu): Detect AVX512VPOPCNTDQ. (cherry picked from commit 808b611bfb4b05703ea174e50874c711dca44c98)
[Bug target/95258] -march=native doesn't handle -mavx512vpopcntdq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95258 --- Comment #5 from CVS Commits --- The releases/gcc-8 branch has been updated by H.J. Lu : https://gcc.gnu.org/g:0055fa9a7b7239c50e6067724f28e64eceadd0fe commit r8-10270-g0055fa9a7b7239c50e6067724f28e64eceadd0fe Author: H.J. Lu Date: Fri May 22 04:18:34 2020 -0700 x86: Handle -mavx512vpopcntdq for -march=native Add -mavx512vpopcntdq for -march=native if AVX512VPOPCNTDQ is available. PR target/95258 * config/i386/driver-i386.c (host_detect_local_cpu): Detect AVX512VPOPCNTDQ. (cherry picked from commit 808b611bfb4b05703ea174e50874c711dca44c98)
[Bug target/95259] Duplicated codes in libgcc, driver-i386.c and i386-builtins.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95259 Bug 95259 depends on bug 95258, which changed state. Bug 95258 Summary: -march=native doesn't handle -mavx512vpopcntdq https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95258 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug target/95258] -march=native doesn't handle -mavx512vpopcntdq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95258 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Target Milestone|--- |8.5 Resolution|--- |FIXED --- Comment #6 from H.J. Lu --- Fixed for GCC 11, GCC 10.2, GCC 9.4 and GCC 8.5.
[Bug fortran/95304] New: Clean up some code for finalization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95304 Bug ID: 95304 Summary: Clean up some code for finalization Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: tkoenig at gcc dot gnu.org Target Milestone: --- Just looked at the output of gfortran -fdump-fortran-original finalize_28.f90 which has symtree: 'idx2'|| symbol: 'idx2' type spec : (INTEGER 8) attributes: (VARIABLE ARTIFICIAL) symtree: 'ignore' || symbol: 'ignore' type spec : (INTEGER 4) attributes: (VARIABLE ARTIFICIAL) symtree: 'is_contiguous'|| symbol: 'is_contiguous' type spec : (LOGICAL 4) attributes: (VARIABLE ARTIFICIAL) symtree: 'nelem' || symbol: 'nelem' [...] DO __final_coo_graphs_Coo_graph:idx=1_8 __convert_i4_i8[[((_F.rank[[((__final_coo_graphs_Coo_graph:array(FULL)))]]))]] 1_8 ASSIGN __final_coo_graphs_Coo_graph:strides(__final_coo_graphs_Coo_graph:idx) _F.stride[[((__final_coo_graphs_Coo_graph:array(FULL)) (__final_coo_graphs_Coo_graph:idx))]] ASSIGN __final_coo_graphs_Coo_graph:sizes(__final_coo_graphs_Coo_graph:idx) (* __final_coo_graphs_Coo_graph:sizes((- __final_coo_graphs_Coo_graph:idx 1_8)) _F.size[[((__final_coo_graphs_Coo_graph:array(FULL)) (__final_coo_graphs_Coo_graph:idx) (8_8))]]) IF (/= __final_coo_graphs_Coo_graph:strides(__final_coo_graphs_Coo_graph:idx) __final_coo_graphs_Coo_graph:sizes((- __final_coo_graphs_Coo_graph:idx 1_8))) ASSIGN __final_coo_graphs_Coo_graph:is_contiguous .false. ENDIF END DO We should be able to use the is_contiguous intrinsic and also use variable names which are prefixed with __ so we can not collide with user variables under any circumstances.
[Bug fortran/95304] Clean up some code for finalization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95304 Thomas Koenig changed: What|Removed |Added Severity|normal |enhancement
[Bug fortran/94361] [8/9/10/11 Regression] Memory leak in nested types with final
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94361 Thomas Koenig changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org
[Bug jit/95296] Segfault when trying to return a void value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95296 David Malcolm changed: What|Removed |Added Last reconfirmed||2020-05-24 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from David Malcolm --- Thanks for filing this. It looks like calls to (at least): gcc_jit_function_new_local gcc_jit_context_new_global should gracefully fail with an error if the client code attempts to create a variable of void type. Similarly we may need additional checking throughout for uses of rvalues of void type (but I need to check this).
[Bug c++/95305] New: Same code takes ~1/10 time to compile under clang++.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95305 Bug ID: 95305 Summary: Same code takes ~1/10 time to compile under clang++. Product: gcc Version: 9.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: gcc-bugs at hussar dot me.uk Target Milestone: --- Created attachment 48590 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48590&action=edit Time taken to compile same code.
[Bug c++/95305] Same code takes ~1/10 time to compile under clang++.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95305 --- Comment #1 from Jason --- Created attachment 48591 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48591&action=edit Bar-graph of time taken to compile same code.
[Bug c++/95305] Same code takes ~1/10 time to compile under clang++.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95305 --- Comment #2 from Jason --- Overview: = This performance difference appears to affect many versions of g++: my testing indicates since g++ v7.3.0. The performance difference appears to be a 4-7x difference in the time taken to compile the example code. I have presented this a number of times and on a number of occasions I have had reports of similar differences, so this may not be unique to me. Steps to create: 1. Download source tarball from libjmmcg.sf.net or checkout the repo. 2. In the expanded source directory create the directory "build". 3. "cd build" then "cmake .. -DBUILD_TYPE=Release -DBUILD_CHANGELOG=Off -DJMMCG_PERFORMANCE_TESTS=On" 4. "cd release/isimud/tests/" 5. Run "time make -j3 test_mit_exchanges_performance". Details: - The code is heavily templated, with a lot of template meta-programming. I believe that the ~2x increase in time taken to build the code between g++ v8.1.0 & v8.2.0 & the clang versions is more related to a move from using "boost::mpl::vector" to varadic templates. I hypothesise that this code-change triggered different paths in the compiler that caused the increase. - All tests were carried out on the same physical hardware, a rather aged dual processor AMD Opteron 4180 with 32Gb or RAM running Gentoo/Linux. The computer was quiescent for the duration of each test. - Qualitatively, a number of other of my test cases appear to show this compilation-time difference. (Most likely due to the shared code.)
[Bug libfortran/95293] Fortran not passing array by reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95293 --- Comment #6 from David Sagan --- > program foo >real x >x = 42 >call bar(x) >print *, x >contains > subroutine bar(a) > real, intent(inout) :: a > a = 12 > x = 0 > end subroutine bar > end program foo > > Should this print 12 or 0? When bar returns 'a' has a value of > 12, should this value be transferred to 'x' before the print > statement is executed? 'a' is passed by reference. Therefore, when the statement 'x = 0' is executed, the value of 'a' immediately changes to 0. So '0' will be printed.
[Bug jit/95306] New: Getting __builtin_saddl_overflow gives the error "unimplemented primitive type for builtin: 42"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95306 Bug ID: 95306 Summary: Getting __builtin_saddl_overflow gives the error "unimplemented primitive type for builtin: 42" Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: bouanto at zoho dot com Target Milestone: --- Created attachment 48592 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48592&action=edit Complete example reproducing this issue Hi. Getting the builtin __builtin_sadd_overflow like this: gcc_jit_function *sadd = gcc_jit_context_get_builtin_function(ctxt, "__builtin_sadd_overflow"); prints the following error at runtime: unimplemented primitive type for builtin: 42 Other builtins like __builtin_saddl_overflow works fine. Thanks to fix this issue.
[Bug target/95255] [10/11 Regression] ICE in gen_roundevendf2, at config/i386/i386.md:16328 since r10-2809-gd3b92f35d84f44a8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95255 --- Comment #5 from CVS Commits --- The releases/gcc-10 branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:217a22416575c638940b25ea5937ff09d40cf808 commit r10-8178-g217a22416575c638940b25ea5937ff09d40cf808 Author: Uros Bizjak Date: Sun May 24 18:01:08 2020 +0200 i386: Fix 2 expander [PR95255] 2020-05-24 Uroš Bizjak gcc/ChangeLog: PR target/95255 * config/i386/i386.md (2): Do not try to expand non-sse4 ROUND_ROUNDEVEN rounding via SSE support routines. gcc/testsuite/ChangeLog: PR target/95255 * gcc.target/i386/pr95255.c: New test.
[Bug c++/95307] New: Compiler accepts reinterpret_cast in constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95307
Bug ID: 95307
Summary: Compiler accepts reinterpret_cast in constexpr
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent.hamp at higaski dot at
Target Milestone: ---
The following snippet allows using reinterpret_casts inside a constexpr.
#include
uint64_t v;
constexpr auto p{reinterpret_cast(&v) - 1u};
Compiled with GCC 10.1 and 9.3 with -std=c++2a
Interestingly subtracting 0u results in an error.
[Bug libfortran/95293] Fortran not passing array by reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95293 --- Comment #7 from Steve Kargl --- On Sun, May 24, 2020 at 02:45:32PM +, david.sagan at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95293 > > --- Comment #6 from David Sagan --- > > program foo > >real x > >x = 42 > >call bar(x) > >print *, x > >contains > > subroutine bar(a) > > real, intent(inout) :: a > > a = 12 > > x = 0 > > end subroutine bar > > end program foo > > > > Should this print 12 or 0? When bar returns 'a' has a value of > > 12, should this value be transferred to 'x' before the print > > statement is executed? > > 'a' is passed by reference. Therefore, when the statement 'x = 0' is executed, > the value of 'a' immediately changes to 0. So '0' will be printed. > The code, like your original example, is invalid. As this is not a numbered constraint, a Fortran processor is not required to tell a programmer that the program violated the standard. 15.5.2.13 Restrictions on entities associated with dummy arguments While an entity is associated with a dummy argument, the following restrictions hold. (1) Does not apply (2) Does not apply (3) Action that affects the value of the entity or any subobject of it shall be taken only through the dummy argument unless (a) Does not apply (b) Does not apply (c) Does not apply (d) Does not apply
[Bug target/95255] [10/11 Regression] ICE in gen_roundevendf2, at config/i386/i386.md:16328 since r10-2809-gd3b92f35d84f44a8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95255 Uroš Bizjak changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Uroš Bizjak --- Fixed for gcc-10.2+.
[Bug c++/95028] ICE in g++ (Arch Linux 9.3.0-1) 9.3.0 with captured OMP reduce clause in lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95028 --- Comment #1 from fytch --- Seems to be fixed in GCC g++ 10.1.0
[Bug c++/95307] Compiler accepts reinterpret_cast in constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95307
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
||com
--- Comment #1 from Daniel Krügler ---
(In reply to Vincent Hamp from comment #0)
> The following snippet allows using reinterpret_casts inside a constexpr.
>
> #include
> uint64_t v;
> constexpr auto p{reinterpret_cast(&v) - 1u};
>
> Compiled with GCC 10.1 and 9.3 with -std=c++2a
>
>
> Interestingly subtracting 0u results in an error.
Here a library-free variant of the code including the compiler flags used:
-Wall -Wextra -std=gnu++2a -pedantic
tested using gcc 11.0.0 20200522 (experimental):
//<
using uint64_t = unsigned long;
static_assert(sizeof(uint64_t) * 8 == 64);
uint64_t v;
constexpr auto p{reinterpret_cast(&v) - 1u};
int main()
{
}
//>>>
The essential part of the reproducer is the fact that we have a variable of
static storage duration involved. Using a local variable in main() does make
the compiler reject the code.
[Bug fortran/95106] Bogus warning from module with long name and an equivalence
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95106 --- Comment #4 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:d176184d98a00ab379ae5959aed1908a79995e6b commit r11-594-gd176184d98a00ab379ae5959aed1908a79995e6b Author: Harald Anlauf Date: Sun May 24 21:35:04 2020 +0200 PR fortran/95106 - truncation of long symbol names with EQUIVALENCE For long module names, the generated name-mangled symbol was truncated, leading to bogus warnings about COMMON block mismatches. Provide sufficiently large temporaries. gcc/fortran/ 2020-05-24 Harald Anlauf PR fortran/95106 * trans-common.c (gfc_sym_mangled_common_id): Enlarge temporaries for name-mangling. gcc/testsuite/ 2020-05-24 Harald Anlauf PR fortran/95106 * gfortran.dg/equiv_11.f90: New test.
[Bug fortran/95106] Bogus warning from module with long name and an equivalence
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95106 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from anlauf at gcc dot gnu.org --- Should be fixed, closing. The test case assumes name mangling for equivalences as on Linux/x86. If some platform has different conventions, I can add an appropriate restriction. Thanks for the report!
[Bug libfortran/95195] gfortran poorly handles a program error of writing a namelist to an unformatted file.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95195 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from anlauf at gcc dot gnu.org --- Slightly adjusted patch, posted for review: https://gcc.gnu.org/pipermail/fortran/2020-May/054380.html
[Bug middle-end/95189] [10/11 Regression] memcmp being wrongly stripped like strcmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95189 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED CC||msebor at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org --- Comment #4 from Martin Sebor --- Isn't the problem that c_getstr(arg2, &len2) sets len2 to 1 instead of 4 (i.e, sizeof (x)) as the function comment suggests should happen? /* Return a pointer P to a NUL-terminated string representing the sequence of constant characters referred to by SRC (or a subsequence of such characters within it if SRC is a reference to a string plus some constant offset). If STRLEN is non-null, store the number of bytes in the string constant including the terminating NUL char. *STRLEN is typically strlen(P) + 1 in the absence of embedded NUL characters. */ const char * c_getstr (tree src, unsigned HOST_WIDE_INT *strlen /* = NULL */) If that's what the function is supposed to do (and even if it isn't), using the name STRLEN for anything that's not actually the result of strlen() is terribly misleading, practically begging to be misused. In fact, going back in time, it looks like starting with r262522 the function did take two pointers: STRLEN for the string length (i.e., the result of strlen) and STRSIZE for the size, until r264301 when it was changed to the current form.
[Bug target/95253] [10/11 Regression] Build failure on MSys. Wrong dependency file escaping on Windows.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95253
--- Comment #2 from Daniel Starke ---
Minimal test case on MSys/MinGW:
echo '#include ' | gcc -MD -MF - -fsyntax-only -x c -
Result with gcc 9.3.0:
-: \
e:\msys\mingw64_9.3.0\lib\gcc\x86_64-w64-mingw32\9.3.0\include\stddef.h \
[...]
Result with gcc 10.1.0 (':' in path was quoted):
-: E\:/msys/mingw64/mingw/include/stddef.h \
[...]
[Bug tree-optimization/95308] New: ICE: in maybe_canonicalize_mem_ref_addr with -O3 -march=skylake-avx512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95308
Bug ID: 95308
Summary: ICE: in maybe_canonicalize_mem_ref_addr with -O3
-march=skylake-avx512
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vsevolod.livinskij at frtk dot ru
Target Milestone: ---
Error:
>$ g++ -O3 -march=skylake-avx512 -c func.cpp
during GIMPLE pass: forwprop
func.cpp: In function ‘void i(char, long int (*)[100][100][100])’:
func.cpp:5:6: internal compiler error: in maybe_canonicalize_mem_ref_addr, at
gimple-fold.c:4912
5 | void i(char f, long g[][100][100][100]) {
| ^
0x76db2a maybe_canonicalize_mem_ref_addr
gcc_src/gcc/gimple-fold.c:4912
0xdfdd97 fold_stmt_1
gcc_src/gcc/gimple-fold.c:5014
0x1226b41 execute
gcc_src/gcc/tree-ssa-forwprop.c:3095
Reproducer:
extern int a[][18];
extern short b[], c[];
extern char d[][18];
int e;
void i(char f, long g[][100][100][100]) {
for (int h = 0;; h += 2)
for (char j = 0; j < 17; j++) {
if (e ? f : 0) {
a[h][j] = 5;
for (int k = 0; k < 12; k += 4)
for (short l = 0; l < 015; l += 2)
b[k * 3 + l] = bool(g[2][j][k][l]);
} else
d[h][j] = 0;
c[j] = 3;
}
}
GCC version:
11.0.0 (a57aa11191617754c8d43b3eb6a2576e970a0668)
[Bug tree-optimization/95308] ICE: in maybe_canonicalize_mem_ref_addr with -O3 -march=skylake-avx512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95308 --- Comment #1 from Vsevolod Livinskiy --- bug 94216 might be related to this one
[Bug middle-end/95276] [10/11 Regression] Amusing stringpop-overflow message building libgfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95276
--- Comment #7 from Martin Sebor ---
There are some uninitialized local variables in the reduced test case but with
those made extern I was able to reproduce the warning. But unless the test
case was reduced too far or the reduction introduced bugs (or I unless missed
something) I think the warning justified. ztoa_big() is being called with len
> 16 and a buffer of size 33. The loop in the function iterates 2 * len times,
storing into successive elements of the 33-byte itoa_buf, and then appending
'\0'. So with len == 17 it writes 35 bytes into the 33-bute itoa_buf.
Here's a much smaller test case that I ultimately reduced it to that shows the
bug (I shrank the buffer while still keeping the size ratios). The offset of
zero doesn't seem right but that's a side issue.
$ cat pr95276.c && gcc -O2 -S pr95276.c
char a[4];
void f (char *s, int n)
{
if (n <= 2)
return;
char *d = a;
for (int i = 0; i < n; i++)
{
extern volatile unsigned char h, l;
*d++ = s[h];
*d++ = s[l];
}
*d = '\0';
}
pr95276.c: In function ‘f’:
pr95276.c:18:6: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
18 | *d = '\0';
| ~~~^~
pr95276.c:1:6: note: at offset 0 to object ‘a’ with size 4 declared here
1 | char a[4];
| ^
[Bug middle-end/95276] [10/11 Regression] Amusing stringpop-overflow message building libgfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95276 --- Comment #8 from Thomas Koenig --- Looks like a faithful reduction that you made, it also still shows the locale dependency from comment #4: $ LANG="" gcc -O2 -S a.c a.c: In function 'f': a.c:18:6: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=] 18 | *d = '\0'; | ~~~^~ a.c:1:6: note: at offset 0 to object 'a' with size 4 declared here 1 | char a[4]; | ^ $ LANG=de_DE.UTF-8 gcc -O2 -S a.c a.c: In Funktion »f«: a.c:18:6: Warnung: Schreiben von 140075679154576 Byte in eine Region der Größe 1 [-Wstringop-overflow=] 18 | *d = '\0'; | ~~~^~ a.c:1:6: Anmerkung: bei Offset 0 zum Objekt »a« mit Größe 4 wurde hier deklariert 1 | char a[4]; | ^
[Bug target/95095] Feature request: support -fno-unique-section-names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95095
--- Comment #1 from Fangrui Song ---
I just learned that `int main() {}` compiles to .text.startup in -O2 or -Os
It seems that .text.startup. may be better to not accidentally move a C
function named `startup` (`startup.` is not a valid C identifier)
[Bug tree-optimization/95187] Failure to optimize bool check into consecutive literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95187 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from Andrew Pinski --- (In reply to Richard Biener from comment #1) > Sth for phiopt. Or expand phiopt to use match and simplify and then it is a job for match.pd. I have a patch which does both really.
[Bug libstdc++/94268] std::filebuf is extremely (at least 10x) slow on windows compared to Linux. Even much slower MSVC STL with terrible ABI.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94268 --- Comment #10 from fdlbxtqi --- What about adding another check when BUFSIZ is smaller than 4KB? If it is smaller than 4kb, adjust the filebuf size to 4kb at least.
[Bug target/95125] Unoptimal code for vectorized conversions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95125 --- Comment #9 from CVS Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:94c0409717bf8bf783963c1d50bb8f4a4732dce7 commit r11-596-g94c0409717bf8bf783963c1d50bb8f4a4732dce7 Author: liuhongt Date: Sat May 23 15:30:58 2020 +0800 Add missing expander for vector float_extend and float_truncate. 2020-05-25 Hongtao Liu gcc/ChangeLog PR target/95125 * config/i386/sse.md (sf2dfmode_lower): New mode attribute. (trunc2) New expander. (extend2): Ditto. gcc/testsuite/ChangeLog * gcc.target/i386/pr95125-avx.c: New test. * gcc.target/i386/pr95125-avx512f.c: Ditto.
[Bug tree-optimization/94919] Failure to recognize max pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94919 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-05-25 Ever confirmed|0 |1 Severity|normal |enhancement Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org --- Comment #3 from Andrew Pinski --- The transformation we should do is: ((x ^ y) & -(Z)) ^ y Where Z has the range of [0...1] (bool). To: Z ? x : y I will look into adding this to match.pd and all.
[Bug middle-end/95309] New: [11 Regression] Many targets failing ssa-dom-cse-2.c after vectorizer changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95309
Bug ID: 95309
Summary: [11 Regression] Many targets failing ssa-dom-cse-2.c
after vectorizer changes
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: law at redhat dot com
Target Milestone: ---
Various ports have regressed the tree-ssa/ssa-dom-cse-2.c after this change:
commit a4b48fc47c3406b6f41be093c4615879b7006710
Author: Richard Biener
Date: Mon May 18 16:05:00 2020 +0200
cost invariant nodes from vect_slp_analyze_node_operations SLP walk
2020-05-19 Richard Biener
* tree-vectorizer.h (_slp_tree::vectype): Add field.
(SLP_TREE_VECTYPE): New.
* tree-vect-slp.c (vect_create_new_slp_node): Initialize
SLP_TREE_VECTYPE.
(vect_create_new_slp_node): Likewise.
(vect_prologue_cost_for_slp): Move here from tree-vect-stmts.c
and simplify.
(vect_slp_analyze_node_operations): Walk nodes children for
invariant costing.
(vect_get_constant_vectors): Use local scope op variable.
* tree-vect-stmts.c (vect_prologue_cost_for_slp_op): Remove here.
(vect_model_simple_cost): Adjust.
(vect_model_store_cost): Likewise.
(vectorizable_store): Likewise.
You should be able to see this on the iq2000-elf port (and many others).
I believe the test is supposed to verify that we're able to determine the
return
value statically after unrolling the loop. It's unclear if the stores get in
the
way of cse-ing the assignment to _22 and _29 in the dump or if there's
something
else going on:
MEM[(int *)&a] = { 0 };
MEM[(int *)&a + 4B] = { 1 };
MEM[(int *)&a + 8B] = { 2 };
MEM[(int *)&a + 12B] = { 3 };
MEM[(int *)&a + 16B] = { 4 };
MEM[(int *)&a + 20B] = { 5 };
MEM[(int *)&a + 24B] = { 6 };
MEM[(int *)&a + 28B] = { 7 };
_22 = a[0];
_29 = a[1];
sum_30 = _22 + _29;
_36 = a[2];
sum_37 = sum_30 + _36;
_43 = a[3];
sum_44 = sum_37 + _43;
_50 = a[4];
sum_51 = sum_44 + _50;
_57 = a[5];
sum_58 = sum_51 + _57;
_64 = a[6];
sum_65 = sum_58 + _64;
_1 = a[7];
sum_16 = _1 + sum_65;
a ={v} {CLOBBER};
return sum_16;
[Bug tree-optimization/95271] ice in vect_get_constant_vectors, at tree-vect-slp.c:3638
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95271 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Version|unknown |11.0 Last reconfirmed||2020-05-25 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Mine.
[Bug tree-optimization/95272] ice in vectorizable_reduction, at tree-vect-loop.c:6197
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95272 Richard Biener changed: What|Removed |Added Component|c++ |tree-optimization Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-05-25 Ever confirmed|0 |1 Version|unknown |11.0 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #1 from Richard Biener --- Mine.
