[Bug c++/101368] New: -Wlogical-op and string comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101368
Bug ID: 101368
Summary: -Wlogical-op and string comparison
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: arnaud02 at users dot sourceforge.net
Target Milestone: ---
Considering
#include
bool f(int num) {
return num != 2 || num != 3;
}
bool g(std::string_view s) {
using namespace std::literals;
return s != "AA"sv || s != "BB"sv;
}
"g++ -std=c++17 -Wlogical-op -O2" emits:
: In function 'bool f(int)':
:3:21: warning: logical 'or' of collectively exhaustive tests is always
true [-Wlogical-op]
3 | return num != 2 || num != 3;
|~^~~
g++ spots the defect in "f". It would be incredibly useful if the similar
defect was reported in "g".
In this case, the gcc x64 backend emits identical code for f and g:
f(int):
mov eax, 1
ret
g(std::basic_string_view >):
mov eax, 1
ret
[Bug libstdc++/98518] std::array not bound checked with _GLIBCXX_ASSERTIONS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98518 --- Comment #2 from Arnaud Desitter --- It is indeed fixed. Fantastic.
[Bug libstdc++/98518] New: std::array not bound checked with _GLIBCXX_ASSERTIONS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98518
Bug ID: 98518
Summary: std::array not bound checked with _GLIBCXX_ASSERTIONS
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: arnaud02 at users dot sourceforge.net
Target Milestone: ---
operator[] of std::array is not bound checked when specifying
_GLIBCXX_ASSERTIONS.
Considering:
#define _GLIBCXX_ASSERTIONS 1
#include
#include
int f(int i) {
std::array x = {1, 4};
return x[i]; // bounds are not checked
}
int main() {
volatile int i = 2;
printf("f=%d\n", f(i));
}
the array bound violation is not detected. By constrast, replacing std::array
by std::vector results in the expected assertion violation.
[Bug libstdc++/94906] New: memory corruption in std::pmr::memory_buffer_resource
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94906
Bug ID: 94906
Summary: memory corruption in std::pmr::memory_buffer_resource
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: arnaud02 at users dot sourceforge.net
Target Milestone: ---
>cat pmr1.cpp
#include
#include
#include
int main() {
const std::size_t max_size = 75'000'000;
std::pmr::monotonic_buffer_resource res;
std::pmr::unordered_map> counter{};
for (size_t i = 0; i < max_size; ++i) counter[i];
}
>g++ -Wall -std=c++17 -O2 -g pmr1.cpp && ./a.out
*** Error in `./a.out': free(): invalid pointer: 0x2b06379d000f ***
=== Backtrace: =
/lib64/libc.so.6(+0x81299)[0x2b03c8a6f299]
opt/gcc/gcc-930-rh7/lib64/libstdc++.so.6(_ZNSt3pmr25monotonic_buffer_resource18_M_release_buffersEv+0x48)[0x2b03c825fe78]
opt/gcc/gcc-930-rh7/lib64/libstdc++.so.6(_ZNSt3pmr25monotonic_buffer_resourceD2Ev+0x1e)[0x2b03c825febe]
./a.out[0x400d51]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x2b03c8a10555]
./a.out[0x400eb4]
In monotonic_buffer_resource::_Chunk::release, "__size" is not calculated
properly when _Chunk::_M_size is 32 or more. Here is a candidate patch:
--- gcc-9.3.0/libstdc++-v3/src/c++17/memory_resource.cc 2020-03-12
11:07:24.0 +
+++ gcc-9.3.0/libstdc++-v3/src/c++17/memory_resource.cc.new 2020-05-01
18:31:24.367672036 +0100
@@ -228,7 +228,7 @@
if (__ch->_M_canary != (__ch->_M_size | __ch->_M_align))
return; // buffer overflow detected!
- size_t __size = (1u << __ch->_M_size);
+ size_t __size = (1lu << __ch->_M_size);
size_t __align = (1u << __ch->_M_align);
void* __start = (char*)(__ch + 1) - __size;
__r->deallocate(__start, __size, __align);
[Bug c++/79328] Wshadow and lambda captures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79328
Arnaud Desitter changed:
What|Removed |Added
CC||arnaud02 at users dot
sourceforge.
||net
--- Comment #3 from Arnaud Desitter ---
This defect makes -Wshadow=local difficult to use with immediately invoked
lambda expressions. For instance,
gcc 9.2 compiles:
#include
auto f(int s) {
const auto v = []{
std::array v = {1, 2};
return v;
}();
return v.size();
}
with:
source>: In lambda function:
:4:25: warning: declaration of 'v' shadows a previous local [-Wshadow]
4 | std::array v = {1, 2};
| ^
:3:14: note: shadowed declaration is here
3 | const auto v = []{
| ^
[Bug libstdc++/90557] New: Incorrect std::filesystem::path::operator=(std::filesystem::path const&) in gcc 9.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90557 Bug ID: 90557 Summary: Incorrect std::filesystem::path::operator=(std::filesystem::path const&) in gcc 9.1.0 Product: gcc Version: 9.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: arnaud02 at users dot sourceforge.net Target Milestone: --- Using gcc 9.1.0, I observe some memory issues detected with valgrind when using std::filesystem:path: ==23251== Conditional jump or move depends on uninitialised value(s) ==23251==at 0x6CDD45: void std::__cxx11::basic_string, std::allocator >::_M_construct(char*, char*, std::forward_iterator_tag) (basic_string.tcc:211) ==23251==by 0xA807D5: _M_construct_aux (basic_string.h:247) ==23251==by 0xA807D5: _M_construct (basic_string.h:266) ==23251==by 0xA807D5: basic_string (basic_string.h:451) ==23251==by 0xA807D5: path (fs_path.h:175) ==23251==by 0xA807D5: _Cmpt (fs_path.h:690) ==23251==by 0xA807D5: _Construct (stl_construct.h:75) ==23251==by 0xA807D5: __uninit_copy (stl_uninitialized.h:83) ==23251==by 0xA807D5: uninitialized_copy (stl_uninitialized.h:134) ==23251==by 0xA807D5: __uninitialized_copy_n (stl_uninitialized.h:767) ==23251==by 0xA807D5: uninitialized_copy_n (stl_uninitialized.h:814) ==23251==by 0xA807D5: std::filesystem::__cxx11::path::_List::operator=(std::filesystem::__cxx11::path::_List const&) (fs_path.cc:281) ==23251==by 0xA80858: std::filesystem::__cxx11::path::operator=(std::filesystem::__cxx11::path const&) (fs_path.cc:451) I was not able to extract a small reproducer. However, the defect comes from fs_path.cc:281 std::uninitialized_copy_n(to + oldsize, newsize - oldsize, from + oldsize); should be: std::uninitialized_copy_n(from + oldsize, newsize - oldsize, to + oldsize);
[Bug middle-end/89371] missed vectorisation with "#pragma omp simd collapse(2)"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89371
--- Comment #3 from Arnaud Desitter ---
Considering:
#include
#include
#include
void ff(double* res, double const* a, double const* b, int n1, int n2)
{
#pragma omp simd collapse(2)
for(int i1=0; i1 < n1; ++i1)
{
for(int i2=0; i2 < n2; ++i2)
{
res[i1*n2+i2] = a[i1*n2+i2]-b[i1*n2+i2];
}
}
}
int main()
{
const auto repeat = 100*100;
const std::size_t n1 = 100*1000;
const std::size_t n2 = 3;
std::vector res(n1*n2), a(n1*n2), b(n1*n2);
std::iota(a.begin(), a.end(), 1.0);
std::iota(b.begin(), b.end(), -200.0);
for(int r=repeat; r>0; --r)
ff(res.data(), a.data(), b.data(), n1, n2);
std::cout << res[0] << '\n';
}
Using clang 8.0:
>clang++ -O3 main2.cpp
>/usr/bin/time ./a.out > /dev/null
2.93user 0.00system 0:02.94elapsed 99%CPU (0avgtext+0avgdata 8424maxresident)k
>clang++ -fopenmp-simd -O3 main2.cpp > /dev/null
>/usr/bin/time ./a.out > /dev/null
2.83user 0.00system 0:02.83elapsed 99%CPU (0avgtext+0avgdata 8492maxresident)k
0inputs+0outputs (0major+2215minor)pagefaults 0swaps
Using gcc 9.1.0:
>g++ -O3 main2.cpp
>/usr/bin/time ./a.out > /dev/null
3.49user 0.00system 0:03.50elapsed 99%CPU (0avgtext+0avgdata 8488maxresident)k
0inputs+0outputs (0major+2215minor)pagefaults 0swaps
>g++ -fopenmp-simd -O3 main2.cpp
>/usr/bin/time ./a.out > /dev/null
5.83user 0.00system 0:05.84elapsed 99%CPU (0avgtext+0avgdata 8492maxresident)k
0inputs+0outputs (0major+2215minor)pagefaults 0swaps
clang 8.0 is able to produce vectorised code using "#pragma omp simd
collapse(2)" whereas gcc 9.1.0 cannot.
For record, clang 7.0 produces terrible code for this example.
[Bug tree-optimization/89518] New: missed optimisation for array address calculations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89518
Bug ID: 89518
Summary: missed optimisation for array address calculations
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: arnaud02 at users dot sourceforge.net
Target Milestone: ---
Considering:
int f(int index, int stride) {
const int i1 = index / stride;
const int i2 = index % stride;
const int index2 = i1*stride+i2;
return index2; // expect: index2 = index
}
gcc 8.3 with "-O3" on x84_64 emits:
f(int, int):
mov eax, edi
cdq
idivesi
imuleax, esi
add eax, edx
ret
By contrast, clang 7 with "-O3" emits
f(int, int):
mov eax, edi
ret
MSVC 2017 with "/O2" emits:
int f(int,int)
mov eax, ecx
ret 0
Is there a way to persuade gcc to simplify this expression at compile time?
[Bug middle-end/89371] missed vectorisation with "#pragma omp simd collapse(2)"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89371 --- Comment #2 from Arnaud Desitter --- In my original report, I meant to write: "built by gcc 8.2 on x86_64 with "-std=c++14 -O3 -mavx -fopenmp-simd" results in **NO** simd instruction emitted." subroutine ff(res, a, b, ncell, neq) integer :: ncell, neq double precision, dimension(neq,ncell) :: res, a, b integer :: icell, ieq !$omp simd collapse(2) do icell=1,ncell do ieq=1, neq res(ieq,icell) = a(ieq,icell)-b(ieq,icell) enddo enddo end subroutine has the same issue (gfortran 8.2 "-O3 -mavx -fopenmp-simd"). "!$omp simd collapse(2)" produces scalar code. I agree that it is possible to flatten the loops manually. I am wondering why the clause "collapse(2)" ends up disabling the vectorisation.
[Bug middle-end/89371] New: missed vectorisation with "#pragma omp simd collapse(2)"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89371
Bug ID: 89371
Summary: missed vectorisation with "#pragma omp simd
collapse(2)"
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: arnaud02 at users dot sourceforge.net
Target Milestone: ---
void ff(double* res, double const* a, double const* b, int ncell, int neq)
{
#pragma omp simd collapse(2)
for(int icell=0; icell < ncell; ++icell)
{
for(int ieq=0; ieq
[Bug libstdc++/87846] New: std::filesystem::create_directories with a path with a trailing slash does not create any directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87846
Bug ID: 87846
Summary: std::filesystem::create_directories with a path with a
trailing slash does not create any directory
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: arnaud02 at users dot sourceforge.net
Target Milestone: ---
Calling std::filesystem::create_directories with a path with a trailing
separator (e.g. "./a/b/") does not create any directory.
VS 2017 15.8 creates the desired directories.
Is GCC incorrect?
>cat fs.cpp
//
https://developercommunity.visualstudio.com/content/problem/278829/stdfilesystemcreate-directories-returns-false-if-p.html
#include
#include
namespace fs = std::filesystem;
int main()
{
fs::path d{"./a/b/"};
// bug: d is not created due to trailing slash when built with GCC 8. Works
with VS2017.8.
fs::create_directories(d);
std::cout << std::boolalpha
<< fs::exists(d) << ' '
<< fs::is_directory(d) << '\n';
for (auto const& e : fs::recursive_directory_iterator("."))
std::cout << "In current_path: " << e.path() << '\n';
}
>g++ -std=c++17 fs.cpp -lstdc++fs
>./a.out
false false
In current_path: "./a.out"
In current_path: "./fs.cpp"
>gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/buildarea/opt/gcc/gcc-820-rh6/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /tmp/gcc8/gcc-build/srcdir/gcc-8.2.0/configure
--prefix=/buildarea/opt/gcc/gcc-820-rh6 --enable-languages=c,c++,fortran
--disable-multilib
Thread model: posix
[Bug c++/78010] --Wsuggest-override reports a redundant warning on a 'final' method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78010
--- Comment #3 from Arnaud Desitter ---
Interesting reference. Note that "virtual + final" can be useful even if the
core guidelines discourage its use.
struct A {
virtual void f() final;
};
struct B : A {
// "void f()" cannot be defined
};
[Bug c++/80518] -Wsuggest-override does not warn about missing override on destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80518 --- Comment #2 from Arnaud Desitter --- Interesting. Shame that there is no rationale. I suppose that "-Wsuggest-override=2" could warn about "override" missing for destructor.
[Bug c++/80518] New: -Wsuggest-override does not warn about missing override on destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80518
Bug ID: 80518
Summary: -Wsuggest-override does not warn about missing
override on destructor
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: arnaud02 at users dot sourceforge.net
Target Milestone: ---
Considering:
struct Base {
virtual ~Base() {}
};
struct Derived : public Base {
~Derived() {} // -Wsuggest-override does not emit a warning but could.
};
g++ -Wsuggest-override does not warn about missing override on the destructor.
Note that clang-tidy's check "modernize-use-override" adds override to
destructors as needed.
[Bug c++/78010] --Wsuggest-override reports a redundant warning on a 'final' method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78010
Arnaud Desitter changed:
What|Removed |Added
CC||arnaud02 at users dot
sourceforge.
||net
--- Comment #1 from Arnaud Desitter ---
Considering:
struct A {
virtual void f();
};
struct B : A {
void f() override final;
};
"clang-tidy -checks=-*,modernize-use-override" removes "override" but gcc's
"-Wsuggest-override" requires it. So implementing the suggestion would make the
two tools compatible.
[Bug c++/80507] [C++17] static variable definition not emitted with -std=c++1z when defined as constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80507 --- Comment #2 from Arnaud Desitter --- Could you explain why the code not valid C++ please?
[Bug c++/80507] New: [C++17] static variable definition not emitted with -std=c++1z when defined as constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80507
Bug ID: 80507
Summary: [C++17] static variable definition not emitted with
-std=c++1z when defined as constexpr
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: arnaud02 at users dot sourceforge.net
Target Milestone: ---
>g++ --version
>g++ (GCC) 7.0.1 20170420 (prerelease)
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>cat gcc7.cpp
>struct CLS1 {
int m_index;
constexpr CLS1(int index) : m_index(index) {}
};
struct CLS2 {
static const CLS1 s_IXXX;
};
constexpr_var_decld_const CLS1 CLS2::s_IXXX {-1};
># works fine in C++14 with const
>rm gcc7.o; g++ -std=c++14 -Dconstexpr_var_decld_const=const -c gcc7.cpp; nm -C
>gcc7.o
R CLS2::s_IXXX
># works fine in C++14 with constexpr
>rm gcc7.o; g++ -std=c++14 -Dconstexpr_var_decld_const=constexpr -c gcc7.cpp;
>nm -C gcc7.o
R CLS2::s_IXXX
># works fine in C++17 with const
>rm gcc7.o; g++ -std=c++1z -Dconstexpr_var_decld_const=const -c gcc7.cpp; nm -C
>gcc7.o
R CLS2::s_IXXX
># does not work in C++17 with constexpr (static object in not created)
>rm gcc7.o; g++ -std=c++1z -Dconstexpr_var_decld_const=constexpr -c gcc7.cpp;
>nm -C gcc7.o
Using constexpr for variables forward declared as const has been handled by gcc
since gcc 4.9 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59123). This does
not work reliably with "-std=c++1z". It was accepted by gcc 6.2.
Could you address it please?
[Bug fortran/61632] New: memory corruption in Fortran RTL when writing formatted data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61632 Bug ID: 61632 Summary: memory corruption in Fortran RTL when writing formatted data Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: arnaud02 at users dot sourceforge.net Problem 1: using the following program: program p call ss() call ss() end program p subroutine ss CHARACTER(3), save :: ZTYP(3) DATA ZTYP /'XXX','YYY','ZZZ'/ write(*,600,IOSTAT=iosa) 0.0,ZTYP write(*,*) 'iostat=',iosa 600 FORMAT(1PE13.5,4X,A3) end subroutine ss with gfortran 4.9.0 results in a executable that crashes: 0.0E+00XXX iostat=5006 0.0E+00XXX Program received signal SIGSEGV: Segmentation fault - invalid memory reference. A run under valgrind shows: 0.0E+00XXX iostat=5006 0.0E+00XXX ==13768== Invalid read of size 8 ==13768==at 0x414250: _gfortrani_format_error (format.c:1147) ==13768==by 0x4047D6: require_type.part.7 (transfer.c:1158) ==13768==by 0x406718: formatted_transfer (transfer.c:1150) ==13768==by 0x404AE5: _gfortran_transfer_array (transfer.c:2170) gfortran 4.7.1 is not affected but gfortran 4.8.2 and 4.9.0 are. Problem 2: using the following program: program p call ss() call ss() end program p subroutine ss CHARACTER(3), save :: ZTYP(3) DATA ZTYP /'XXX','YYY','ZZZ'/ write(*,600) 0.0,ZTYP 600 FORMAT(1PE13.5,A3) end subroutine ss with gfortran 4.9.0 results in a executable that produces: -- 0.0E+00XXX At line 8 of file io2.f (unit = 6, file = 'stdout') Fortran runtime error: Expected REAL for item 3 in formatted transfer, got CHARACTER (1PE13.5,A3) ^ -- The message is unclear as there are only 2 items. Moreover the expected type looks incorrect. gfortran 4.6.3, 4.7.2, 4.8.2 and 4.9.0 are affected.
[Bug fortran/59251] New: wrong code generation with allocatable dummy argument and INTENT(OUT)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59251 Bug ID: 59251 Summary: wrong code generation with allocatable dummy argument and INTENT(OUT) Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: arnaud02 at users dot sourceforge.net Using the following program: module branch_plot_results_mod implicit none type, public :: system_variable_type sequence integer :: index = -1 end type system_variable_type type branch_plot_results_type sequence integer :: iu_appv = 0 type(system_variable_type), allocatable :: system_variables(:) end type branch_plot_results_type contains subroutine make1 ( res) type(branch_plot_results_type), allocatable, intent(out) :: res ! intent(out) causes wrong code generation end subroutine make1 end module branch_plot_results_mod program testy use branch_plot_results_mod type(branch_plot_results_type), allocatable :: res1 call make1(res1) end program testy gfortran 4.8.2 on Linux x86_64 produces an executable that crashes due to a memory corruption. valgrind reports: ==24704== Invalid free() / delete / delete[] / realloc() ==24704==at 0x4A071A4: free (vg_replace_malloc.c:468) ==24704==by 0x401B25: __branch_plot_results_mod_MOD_make1 (b1.f90:16) ==24704==by 0x401BA3: MAIN__ (b1.f90:24) ==24704==by 0x401C21: main (b1.f90:22) ==24704== Address 0xffefffaa0 is on thread 1's stack This is related to the use of the INTENT(OUT). This report is a possible duplicate of PR56218 although the program above does not use any OOP feature.
[Bug fortran/59252] New: wrong code generation for allocatable dummy arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59252 Bug ID: 59252 Summary: wrong code generation for allocatable dummy arguments Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: arnaud02 at users dot sourceforge.net module branch_plot_results_mod implicit none type branch_plot_results_ppv_type sequence real(8) , allocatable :: v(:) integer :: handle = 0 character(256), allocatable :: label end type branch_plot_results_ppv_type type branch_plot_results_type sequence type(branch_plot_results_ppv_type), allocatable :: appv(:) integer :: end_appv = 0 end type branch_plot_results_type contains subroutine construct_branch_plot_results(res) type (branch_plot_results_type), allocatable, intent(inout) :: res if(.not.allocated(res)) allocate(res) end subroutine construct_branch_plot_results subroutine construct_branch_plot_results_appv(appv,asize) type(branch_plot_results_ppv_type), allocatable, intent(inout) :: appv(:) integer, intent(in ) :: asize if(allocated(appv)) then if(asize.ne.size(appv)) then deallocate(appv) endif endif if(.not.allocated(appv)) then allocate(appv(asize)) endif end subroutine construct_branch_plot_results_appv end module branch_plot_results_mod program testy use branch_plot_results_mod type(branch_plot_results_type), allocatable :: res call construct_branch_plot_results(res) call construct_branch_plot_results_appv(res%appv, 20) end program testy While compiling the program above, gfortran 4.8.2 on Linux x86_64 produces an executable that results in the run-time error below: Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Valgrind points to the following error: ==24773== Use of uninitialised value of size 8 ==24773==at 0x401F37: __branch_plot_results_mod_MOD_construct_branch_plot_results_appv (b2.f90:33) ==24773==by 0x40: MAIN__ (b2.f90:44) ==24773==by 0x402393: main (b2.f90:39) ==24773== I suspect that gfortran does not support allocatable dummy arguments properly in this case.
[Bug fortran/54767] New: Incorrect code generated with -O2 -fcheck=bounds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54767 Bug #: 54767 Summary: Incorrect code generated with -O2 -fcheck=bounds Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: arnau...@users.sourceforge.net Using the code attached: gfortran --version | head -2 GNU Fortran (GCC) 4.7.1 Copyright (C) 2012 Free Software Foundation, Inc. gfortran -O0 -fcheck=bounds xxx_1.f xxx_2.f /a.out 2 1 3 2 T gfortran -O2 -fcheck=bounds xxx_1.f xxx_2.f ./a.out 2 1 3 1 F The results are different and incorrect when compiling with -O2 -fcheck=bounds. They are still correct when compiling with -O1 -fcheck=bounds.
[Bug fortran/54767] Incorrect code generated with -O2 -fcheck=bounds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54767 --- Comment #1 from Arnaud Desitter arnaud02 at users dot sourceforge.net 2012-10-01 15:08:57 UTC --- Created attachment 28313 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28313 test case
[Bug fortran/53326] New: -finit-integer, -finit-real and INTENT(OUT)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53326 Bug #: 53326 Summary: -finit-integer, -finit-real and INTENT(OUT) Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: arnau...@users.sourceforge.net
[Bug fortran/53326] -finit-integer, -finit-real and INTENT(OUT)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53326 --- Comment #1 from Arnaud Desitter arnaud02 at users dot sourceforge.net 2012-05-11 17:31:12 UTC --- Consider: cat UIN15-int.f !! check whether uninitialised variables are detected !! for INTENT(OUT) arrays program uin integer x(10) x = 2 call sub2(x,size(x)) ! x undefined on return write(*,*) x(1) end subroutine sub2(x,n) integer, intent(in) :: n integer, intent(out) :: x(n) end gfortran470 -finit-integer=10 UIN15-int.f abg-ecldev01:/tmp/arnaud./a.out 2 cat UIN15-double.f !! check whether uninitialised variables are detected !! for INTENT(OUT) arrays program uin double precision x(10) x = 2 call sub2(x,size(x)) ! x undefined on return write(*,*) x(1) end subroutine sub2(x,n) integer, intent(in) :: n double precision, intent(out) :: x(n) end gfortran470 -finit-real=snan UIN15-double.f ./a.out 2. As seen above, -finit-real and -finit-integer have no effect on INTENT(OUT) variables. This would be a nice and useful improvement. Note that the NAG compiler (-nan) and the Sun compiler (-xcheck=init_local -stackvar) implement this feature. (tests UNI15 of http://ftp.aset.psu.edu/pub/ger/fortran/test/results.txt are related)
[Bug fortran/52861] New: (missed optimisation) missed transformation to memset with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52861 Bug #: 52861 Summary: (missed optimisation) missed transformation to memset with -O3 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: arnau...@users.sourceforge.net This is a minor missed-optimisation noticed as follow up to PR52835. This is not a regression. cat qq1.f SUBROUTINE QQ2( ISU, ZSPM, RSV, MS ) INTEGER :: ISU(MS) CHARACTER(8) :: ZSPM(MS) REAL :: RSV(MS) DO IS=1,MS ISU(IS)=0 ZSPM(IS)=' ' RSV(IS) =0.0 ENDDO END subroutine qq2 cat qq2.f SUBROUTINE QQ2( ISU, ZSPM, RSV, MS ) INTEGER :: ISU(MS) CHARACTER(8) :: ZSPM(MS) REAL :: RSV(MS) DO IS=1,MS ISU(IS)=0 RSV(IS) =0.0 ENDDO DO IS=1,MS ZSPM(IS)=' ' ENDDO END subroutine qq2 gfortran470 -O3 -c qq1.f ; gfortran470 -O3 -c qq2.f nm qq1.o qq2.o qq1.o: T qq2_ qq2.o: U memset T qq2_ The compiler has not be able to transform the assignments to ISU and RSV as calls to memset when the loop contains an assignment to a CHARACTER variable. This suggests that the dependency generator can be improved or that the Fortran front-end could pass a better representation to the middle-end. Additionally, it should be possible to transform DO IS=1,MS ZSPM(IS)=' ' ENDDO as a call to memset. gcc 4.7.0 cannot: cat qq3.f SUBROUTINE QQ2( ZSPM, MS ) CHARACTER(8) :: ZSPM(MS) DO IS=1,MS ZSPM(IS)=' ' ENDDO END subroutine qq2 /usr/local/gcc/gfortran470 -O3 -c qq3.f nm qq3 qq3.f qq3.o nm qq3.o T qq2_
[Bug fortran/52668] [4.7/4.8 Regression] Incorrect unused warning for USE associating variable in common block
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52668 --- Comment #2 from Arnaud Desitter arnaud02 at users dot sourceforge.net 2012-04-04 09:42:47 UTC --- The patch posted at http://gcc.gnu.org/ml/fortran/2012-03/msg00124.html fixes the problem.
[Bug fortran/52835] New: Incorrect code generated by gfortran 4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52835 Bug #: 52835 Summary: Incorrect code generated by gfortran 4.7.0 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: arnau...@users.sourceforge.net uname -sm Linux x86_64 cat qq.f SUBROUTINE QQ2( ISU, ZSPM, RSV, MS ) INTEGER :: ISU(MS) CHARACTER(8) :: ZSPM(MS) REAL :: RSV(MS) DO IS=1,MS ISU(IS)=0 ZSPM(IS)=' ' RSV(IS) =0.0 ENDDO END subroutine qq2 SUBROUTINE QQ() INTEGER, ALLOCATABLE :: ISU(:) CHARACTER(8), ALLOCATABLE :: ZSPM(:) REAL, ALLOCATABLE :: RSV(:) ALLOCATE( RSV(3) ) ALLOCATE( ISU(3) ) ALLOCATE( ZSPM(3) ) CALL QQ2( ISU, ZSPM, RSV, 3 ) write(*,*) '--',zspm(1) END subroutine qq program p1 call qq() end program p1 gfortran470 -O3 -g qq.f -static-libgfortran ; valgrind --track-origins=yes ./a.out ==18017== Memcheck, a memory error detector ==18017== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==18017== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==18017== Command: ./a.out ==18017== ==18017== Syscall param write(buf) points to uninitialised byte(s) ==18017==at 0x3541CC4150: __write_nocancel (in /lib64/libc-2.5.so) ==18017==by 0x40981C: raw_write (unix.c:308) ==18017==by 0x40F4FE: _gfortrani_fbuf_flush (unix.h:56) ==18017==by 0x405416: _gfortrani_next_record (transfer.c:3397) ==18017==by 0x405CF8: _gfortran_st_write_done (transfer.c:3592) ==18017==by 0x401C5B: qq_ (qq.f:22) ==18017==by 0x401CFC: main (qq.f:26) ==18017== Address 0x4c2fb44 is 4 bytes inside a block of size 512 alloc'd ==18017==at 0x4A0776F: malloc (vg_replace_malloc.c:263) ==18017==by 0x4037B8: _gfortrani_get_mem (memory.c:43) ==18017==by 0x40F38A: _gfortrani_fbuf_init (fbuf.c:43) ==18017==by 0x408F89: _gfortrani_init_units (unit.c:585) ==18017==by 0x403747: init (main.c:226) ==18017==by 0x4196F5: ??? (in /tmp/arnaud/a.out) ==18017==by 0x401612: ??? (in /tmp/arnaud/a.out) ==18017==by 0x9CA212C: ??? ==18017==by 0x419676: __libc_csu_init (in /tmp/arnaud/a.out) ==18017==by 0x3541C1D84D: (below main) (in /lib64/libc-2.5.so) ==18017== Uninitialised value was created by a heap allocation ==18017==at 0x4A0776F: malloc (vg_replace_malloc.c:263) ==18017==by 0x401BE0: qq_ (qq.f:20) ==18017==by 0x401CFC: main (qq.f:26) ==18017== -- ==18017== ==18017== HEAP SUMMARY: ==18017== in use at exit: 0 bytes in 0 blocks ==18017== total heap usage: 20 allocs, 20 frees, 3,878 bytes allocated ==18017== ==18017== All heap blocks were freed -- no leaks are possible ==18017== ==18017== For counts of detected and suppressed errors, rerun with: -v ==18017== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4) The test case above demonstrates the problem observed on a large production system. In qq2, zspm is not set properly to as shown by valgrind. This is taking place only when compiled with -O3. This is a regression with respect to gfortran 4.6.2.
[Bug middle-end/52835] [4.7/4.8 Regression] -O3 wrongly optimizes loop __builtin_memcpy away
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52835 --- Comment #3 from Arnaud Desitter arnaud02 at users dot sourceforge.net 2012-04-02 17:54:06 UTC --- Additionally: cat xxx.f SUBROUTINE XXX(RES,ALP,REN,NN ) DIMENSION ALP(NN),REN (NN),RES (NN) DO IP = 1,NN REN(IP) = 0.0 ALP(IP) = 0.0 CALL YYY(ALP(IP),REN(IP),RES(IP)) ENDDO END gfortran470 -c -O3 -o xxx_O3.o xxx.f ; gfortran470 -c -O2 -o xxx_O2.o xxx.f ; nm xxx*.o xxx_O2.o: T xxx_ U yyy_ xxx_O3.o: U memset T xxx_ When compiled with -O3, the call to YYY is not generated. This is a pretty serious wrong code generation.
[Bug fortran/46539] libquadmath: Add -static-libquadmath
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46539 --- Comment #4 from Arnaud Desitter arnaud02 at users dot sourceforge.net 2012-03-28 10:05:29 UTC --- Thanks for the workarounds. For information, the Intel Fortran compiler has -static-intel which links statically Intel provided libraries. Such option may be un-practical for gcc.
[Bug fortran/52751] New: private module variable are not exported as local
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52751 Bug #: 52751 Summary: private module variable are not exported as local Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: arnau...@users.sourceforge.net cat qq.f module mm integer, private :: i end module gfortran470 -c qq.f nm qq.o B __mm_MOD_i cat qq.c static int i; gcc470 -c qq.c nm qq.o b i Variables private to a module could be marked as local (b instead of B) in the same way that static variables are in C. This is related to PR40973, which is about procedures.
[Bug fortran/52668] New: Incorrect warning emitted by gfortran 4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52668 Bug #: 52668 Summary: Incorrect warning emitted by gfortran 4.7.0 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: arnau...@users.sourceforge.net cat qq.f module mm integer :: a, b common /mm1/ a, b end module mm program pp call aa() end program pp subroutine aa() use mm, only: a a = 1 end subroutine aa /usr/local/gcc/gfortran470 -Wall qq.f qq.f:9.9: use mm, only: a 1 Warning: Unused module variable 'b' which has been explicitly imported at (1) /usr/local/gcc/gfortran470 --version | head -2 GNU Fortran (GCC) 4.7.0 Copyright (C) 2012 Free Software Foundation, Inc. The warning is incorrect: in pp, b is *not* imported explicitly from mm. This is a regression with respect to gfortran 4.6.x.
[Bug fortran/52669] New: No warning in unused private variable in modules
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52669 Bug #: 52669 Summary: No warning in unused private variable in modules Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: arnau...@users.sourceforge.net cat qq2.f module mm private integer :: a, b, c public :: aa1, aa2 contains subroutine aa1 a = 1 end subroutine aa1 subroutine aa2 b = 1 end subroutine aa2 end module mm /usr/local/gcc/gfortran470 -Wall -c qq2.f /usr/local/gcc/gfortran470 --version | head -2 GNU Fortran (GCC) 4.7.0 Copyright (C) 2012 Free Software Foundation, Inc. gfortran has not detected that private variable c is unused. Private module variables that are not referenced within their module are unused.
[Bug fortran/46539] libquadmath: Add -static-libquadmath
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46539 Arnaud Desitter arnaud02 at users dot sourceforge.net changed: What|Removed |Added CC||arnaud02 at users dot ||sourceforge.net --- Comment #2 from Arnaud Desitter arnaud02 at users dot sourceforge.net 2012-03-22 16:40:41 UTC --- I hit this problem. For the application I am dealing with, I need to link statically the compiler provided libraries while linking dynamically the system ones (pthread, mpi, etc.). Linking with gfortran -static-libgfortran -static-libgcc -Wl,-Bstatic -lstdc++ -Wl,-Bdynamic solves the problem except for libquadmath.so.0. Linking with -Wl,-Bstatic -lquadmath -Wl,-Bdynamic does not help. The only workaround I found is to configure gcc with configure --disable-libquadmath-support. Could you please implement -static-libquadmath or make -Wl,-Bstatic -lquadmath -Wl,-Bdynamic work?
[Bug fortran/52673] New: implement -fheap-arrays in gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52673 Bug #: 52673 Summary: implement -fheap-arrays in gfortran Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: arnau...@users.sourceforge.net Consider p1 subroutine ss3(ia) integer :: ia(*) ia(6)=1 ! out-of-bound access end subroutine ss3 subroutine ss2(ia) integer :: ia(*) call ss3(ia) end subroutine ss2 subroutine ss1 integer :: ia(3) ! local array call ss2(ia) end subroutine ss1 program p1 call ss1 end program p1 and p2 subroutine ss3(ia) integer :: ia(*) ia(6)=1 ! out-of-bound access end subroutine ss3 subroutine ss2(ia) integer :: ia(*) call ss3(ia) end subroutine ss2 subroutine ss1 integer, allocatable :: ia(:) ! local allocatable array allocate( ia(3) ) call ss2(ia) end subroutine ss1 program p2 call ss1 end program p2 Both p1 and p2 contain an array out-of-bound access. However, valgrind will only detect the illegal in p2 as the local array on p1 is allocated on the stack. Compiling with -fstack-protector-all may occasionally help but not in this case. A useful option would be -fheap-arrays which would allocate all local arrays on the heap to make it easier to detect memory corruption using tool such as valgrind. All local arrays of constant size or unknown size (automatic arrays) should be dealt with. This is essentially the opposite of -fstack-arrays: make the program slower to detect memory problems. An possible small optimisation could be to keep the arrays not passed to other routines on the stack as local bound run-time checking (-fcheck=bounds) should be sufficient to detect problems. Note that the Intel Fortran compiler offers -heap-arrays to allocate automatic arrays on the heap. This does not do anything to local arrays of size known at compile time.
[Bug fortran/49993] arrays declared as parameter are not allocated in read-only memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49993 Arnaud Desitter arnaud02 at users dot sourceforge.net changed: What|Removed |Added Depends on||50960 --- Comment #4 from Arnaud Desitter arnaud02 at users dot sourceforge.net 2011-11-04 10:34:18 UTC --- This has probably been fixed by revision 180878 (PR fortran/50960).
[Bug fortran/50331] New: -Wuninitialized and variable passed to WRITE statements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50331 Bug #: 50331 Summary: -Wuninitialized and variable passed to WRITE statements Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: arnau...@users.sourceforge.net Considering: subroutine qq() write(*,*) aa ! aa has not been set end gfortran 4.6.1 does not emit any warning when using gfortran -O3 -Wuninitialized -c qq.f. For reference: df /c -I.. qq.f Compaq Visual Fortran Optimizing Compiler Version 6.6 (Update A) Copyright 2001 Compaq Computer Corp. All rights reserved. qq.f qq.f(2) : Warning: Variable AA is used before its value has been defined write(*,*) aa -^ I was expected that this deficiency had been fixed due the work for issue 43665 but clearly not yet.
[Bug fortran/50334] New: interaction between -Wuninitialized and -finit-real=snan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50334 Bug #: 50334 Summary: interaction between -Wuninitialized and -finit-real=snan Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: arnau...@users.sourceforge.net Considering subroutine qq(aa) aa = bb + 1 ! bb unset end subroutine gfortran461 -O3 -Wuninitialized -c qq.f qq.f: In function 'qq': qq.f:2:0: warning: 'bb' is used uninitialized in this function [-Wuninitialized] gfortran461 -O3 -Wuninitialized -finit-real=snan -c qq.f The absence of compile-time warnings in the second case surprised me for a while until I tracked it down to -finit-real=snan. -finit-real=snan is a killer feature of gfortran, badly missing in Intel Fortran for instance. It is somewhat regrettable that this option disables the compile-time warnings about uninitialized variables as snan in this case is used to find unset variables at run-time. Could you at least add a note in the description of -finit-real= explaining that -finit-real= will disable the warnings about uninitialized variables even for snan?
[Bug fortran/49993] arrays declared as parameter are not allocated in read-only memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49993
--- Comment #3 from Arnaud Desitter arnaud02 at users dot sourceforge.net
2011-08-09 20:24:59 UTC ---
static int ia[] = { 2 }; is equivalent to integer, save :: ia(1) = (/ 2 /).
Anyway, the C example was there to show that allocating a constant array in the
rodata section is possible.
[Bug fortran/49993] arrays declared as parameter are not allocated in read-only memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49993
--- Comment #1 from Arnaud Desitter arnaud02 at users dot sourceforge.net
2011-08-08 10:28:27 UTC ---
The equivalent C program results in the expected segmentation fault.
void a1(int *ia) {
*ia = 1;
}
void a2(void) {
static const int ia[] = { 2 };
a1(ia);
}
int main(void) {
a2();
return 0;
}
[Bug fortran/49993] New: arrays declared as parameter are not allocated in read-only memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49993 Summary: arrays declared as parameter are not allocated in read-only memory Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: arnau...@users.sourceforge.net Consider the following illegal program which contains an attempt to modify a scalar variable declared as parameter: subroutine a1(ia) integer :: ia ia=1 end subroutine subroutine a2() integer, parameter :: ia = 2 call a1(ia) end subroutine program m call a2() end program As ia is allocated in the rodata section, this leads sensibly to a segmentation fault. Consider now a similar program that with an array instead of a scalar: subroutine a1(ia) integer :: ia ia=1 end subroutine subroutine a2() integer, parameter :: ia(1) = (/ 2 /) call a1(ia(1)) end subroutine program m call a2() end program This time, now segmentation fault is generated because array ia is not allocated in the rodata section. Could gfortran be modified to allocate arrays declared in parameter in the rodata section? This would help detecting bugs and may even provide a slight performance and code size advantage.
