: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: rimvydas.jas at gmail dot com
Sometimes tedious to detect, happens only on continued part of line.
Look like incorrect detection of strings
Not part of std, but depends on placement.
Sample:
$ cat def_test.F90
program
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: rimvydas.jas at gmail dot com
Target Milestone: ---
Created attachment 43199
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43199&action=edit
testcase
Attached testcase on openS
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: rimvydas.jas at gmail dot com
Target Milestone: ---
Created attachment 43253
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43253&action=edit
testcase
Wouldn't -Wignore
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rimvydas.jas at gmail dot com
Target Milestone: ---
Using gcc-8 branch c++17 three different(?) ICEs with -fchecking while
compiling boost:
$ /opt/gcc8/bin/g++ --version # on DragonFlyBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89766
--- Comment #4 from Rimvydas (RJ) ---
@Martin: Yes, ICE happens for valid code too only if -fchecking=1. Reduced
cases are invalid and rejected by 9.0.1 20190319 and 8.2.1 20181127.
However 8.3.1 20190319 accepts them even for -fchecking=0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89766
--- Comment #8 from Rimvydas (RJ) ---
Created attachment 45995
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45995&action=edit
Compressed original case (3.3M).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89766
--- Comment #10 from Rimvydas (RJ) ---
Using 9.0.1 20190319 as reference several ICE cases reduce down to the same
snippet (regression on trunk)?
$ cat trunk_accepts_invalid.ii
class a {
constexpr a();
};
template struct b { static constexpr a
: 8.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rimvydas.jas at gmail dot com
Target Milestone: ---
Trunk on openSUSE and DragonFly on x86_64. Reduced testcase
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rimvydas.jas at gmail dot com
Target Milestone: ---
Recent regression.
$ cat citra.cpp
#include
struct Part {
Part(const std::int32_t& value) : value{std::to_string(v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81938
Rimvydas (RJ) changed:
What|Removed |Added
CC||rimvydas.jas at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81938
--- Comment #3 from Rimvydas (RJ) ---
fmt_cache_1.f in valgrind is reproducible on aarch64-suse-linux
One scientific package has a tendency to crash in similar place.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x40003b9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81938
--- Comment #6 from Rimvydas (RJ) ---
(In reply to Dominique d'Humieres from comment #4)
> Thanks for working on this issue.
>
> The patch in comment 2 fixes this PR along with the failures for
> gfortran.dg/fmt_cache_1.f and gfortran.dg/fmt_cac
: libfortran
Assignee: unassigned at gcc dot gnu.org
Reporter: rimvydas.jas at gmail dot com
Target Milestone: ---
Created attachment 39550
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39550&action=edit
changes to tests
Native configuration is x86_64-unknown-drago
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77473
--- Comment #3 from Rimvydas (RJ) ---
Created attachment 39730
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39730&action=edit
possible variant to use libc internal status variable
On DragonFly libpthread always brings libc so __isthreade
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77473
--- Comment #4 from Rimvydas (RJ) ---
Yes it is an issue in gthr-posix.h how presence of pthread is checked on
DragonFly.
libc contains pthread_cancel() stub and it is strange why we detected failures
only now on testsuite after new PRNG in libgf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77473
Rimvydas (RJ) changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rimvydas.jas at gmail dot com
Target Milestone: ---
Created attachment 39972
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39972&action=edit
bare minimum t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78224
--- Comment #1 from Rimvydas (RJ) ---
Same ICE+segv is triggered at -O2 on:
gcc version 4.9.2 (Debian 4.9.2-10)
gcc version 4.8.5 (SUSE Linux)
Works fine at -O3 on:
$ CCVER=gcc47 g++ -v
Using built-in specs.
COLLECT_GCC=/usr/libexec/gcc47/g++
Ta
: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rimvydas.jas at gmail dot com
Target Milestone: ---
Created attachment 49435
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49435&action=edit
reduced testcase
Attached is very reduced ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88707
Rimvydas (RJ) changed:
What|Removed |Added
CC||rimvydas.jas at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96817
Rimvydas (RJ) changed:
What|Removed |Added
CC||rimvydas.jas at gmail dot com
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: rimvydas.jas at gmail dot com
Target Milestone: ---
gcc version 11.0.0 20201025 (experimental) [master revision
d7ddd287c:9f8172cd7:47d13acbda9a5d8eb57ff169ba74857cd54108e4] (GCC)
x86_64-unknown-linux
$ cat init.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97554
--- Comment #3 from Rimvydas (RJ) ---
The g:50f9e1f4d458e36d306b2449c689e45492847f68 applied on top of gcc-10.2
release tarball also allows to compile without segfault in reasonable amount of
time. Could this fix be added to gcc-10 branch for gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70940
--- Comment #12 from Rimvydas (RJ) ---
Missing #include in testsuite gives
/z/gg/libstdc++-v3/testsuite/experimental/memory_resource/new_delete_resource.cc:
In function 'bool aligned(void*)':
/z/gg/libstdc++-v3/testsuite/experimental/memory_res
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96504
Rimvydas (RJ) changed:
What|Removed |Added
CC||rimvydas.jas at gmail dot com
Assignee: unassigned at gcc dot gnu.org
Reporter: rimvydas.jas at gmail dot com
Target Milestone: ---
Created attachment 49776
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49776&action=edit
possible fix
Since the introduction of libcody, gcc bootstrap is br
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98318
--- Comment #1 from Rimvydas (RJ) ---
Could there be added configure option to disable use of libcody functionality
globally like "./configure --disable-cody" or --disable-libstdcxx-modules?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98318
--- Comment #2 from Rimvydas (RJ) ---
With configure fixed in g:6d972f5183d8d476cfb008b85e224aa9b90e628d
only missing header issue remains in netclient.cc and
netserver.cc:
g++ -std=c++11 -g -fno-enforce-eh-specs -fno-stack-protector
-fno-thread
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: rimvydas.jas at gmail dot com
Target Milestone: ---
Testsuite on x86_64-*-dragonfly gives:
Running target unix
FAIL: 17_intro/headers/c++2020/stdc++.cc (test for excess errors)
FAIL: 17_intro/headers/c++2020/stdc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98318
Rimvydas (RJ) changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #10 from Rimvydas (RJ)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98318
--- Comment #11 from Rimvydas (RJ) ---
Nathan,
there seem to be another issue for 'make check' invoke in top level dir:
configure --enable-bootstrap ...
gmake -j128 && gmake -j1 -k check
gmake[2]: Leaving directory '/zzz/build/trunk/libbacktrac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98318
--- Comment #14 from Rimvydas (RJ) ---
Nathan,
It has come to our attention that some of c++ modules tests are failing if the
kernel has IPV6 support disabled as per bootstrap tools policies. Are there
guarantees that local two stage bootstrap
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: rimvydas.jas at gmail dot com
Target Milestone: ---
Testsuite on x86_64-*-dragonfly gives:
Running target unix
FAIL: 17_intro/headers/c++2020/stdc++.cc (test for
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: rimvydas.jas at gmail dot com
Target Milestone: ---
Testsuite on x86_64-*-dragonfly gives:
Running target unix
FAIL: 27_io/headers/cstdio/types_std.cc (test for excess errors
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: rimvydas.jas at gmail dot com
Target Milestone: ---
$ cat foo.f90
program foo
end program
module buffer
integer,allocatable :: mpi_ids(:)
contains
subroutine method(ids
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: rimvydas.jas at gmail dot com
Target Milestone: ---
$ cat intdiv.f90
program foo
if (8 < (20/9)) stop 8
end program
$ gfortran -Wall intdiv.f90
intdiv.f90:2:11:
2 | if (8 <
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: rimvydas.jas at gmail dot com
Target Milestone: ---
$ cat test.f90
subroutine foo
include 'omp_lib.h'
end subroutine
$ gfortran -Wall -c test.f90
omp_lib.h:389:47:
Warning
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rimvydas.jas at gmail dot com
Target Milestone: ---
Very trivialized reduced testcase that still works with
--enable-checking=release configured trunk.
$ cat hog.f90 # foo() and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108705
--- Comment #1 from Rimvydas (RJ) ---
Using assumed shape arrays "p(:),s(:)" in bar() requires longer chain of calls
to foo() and all time spent moves to "tree VRP", but produced assembly is more
cluttered than with assumed size array declaratio
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: rimvydas.jas at gmail dot com
Target Milestone: ---
Reduced testcase:
$ cat ilev.f90
subroutine foo(lev,p,r)
implicit none
integer :: lev,i,j
integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108705
--- Comment #4 from Rimvydas (RJ) ---
Interesting. I see failure even on online godbolt compiler x86-64 gfortran
(trunk) with -O2: "Killed - processing time exceeded"
Just rechecked on fresh arch linux with gcc 12.2.1 host:
$ ./gcc/gfortran -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108705
--- Comment #6 from Rimvydas (RJ) ---
Created attachment 54442
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54442&action=edit
compressed output of gprof lto1 gmon.out
profiled lto1 backend took 3829s to optimize 16 foo_() calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108705
--- Comment #7 from Rimvydas (RJ) ---
The original cases have over 65 long call cascades that take different small
arrays to be packed. Because of geometric time growth for every next repeated
call, the -flto -O2 is unusable in these specific c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108705
--- Comment #9 from Rimvydas (RJ) ---
(In reply to Andrew Macleod from comment #8)
> This fix I just checked in for 108687 exhibited similar performance
> characteristics, also in the same pass.. Perhaps it will fix your problem.
Thank you! Wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108705
Rimvydas (RJ) changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAITING
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: rimvydas.jas at gmail dot com
Target Milestone: ---
Testsuite on x86_64-*-dragonfly gives:
Running target unix
FAIL: 17_intro/headers/c++1998/stdc
Assignee: unassigned at gcc dot gnu.org
Reporter: rimvydas.jas at gmail dot com
Target Milestone: ---
Created attachment 52185
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52185&action=edit
simple fix
Testsuite on x86_64-*-dragonfly gives:
$ gmake check-g
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: rimvydas.jas at gmail dot com
Target Milestone: ---
Created attachment 52186
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52186&action=edit
xfails
Testsuite on x86_64-*-dr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104022
--- Comment #2 from Rimvydas (RJ) ---
Created attachment 52224
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52224&action=edit
proposed patch
I do not have write access. Would Signed-off-by version be OK?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104021
--- Comment #2 from Rimvydas (RJ) ---
Created attachment 52225
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52225&action=edit
Signed-off-by version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104134
Rimvydas (RJ) changed:
What|Removed |Added
CC||rimvydas.jas at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104019
--- Comment #8 from Rimvydas (RJ) ---
Thank you for the patches. Testsuite now gives:
PASS: 17_intro/headers/c++1998/stdc++.cc (test for excess errors)PASS:
17_intro/headers/c++1998/stdc++_multiple_inclusion.cc (test for excess errors)
PASS: 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104019
--- Comment #9 from Rimvydas (RJ) ---
Also there are more possible teststuite failures when running with:
$ make check-target-libstdc++-v3 -k RUNTESTFLAGS="conformance.exp=17_intro*
--target_board=unix/-Wall/-Wsystem-headers/-Wno-c++11-extensio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101918
--- Comment #7 from Rimvydas (RJ) ---
The suggested removal of -fdefault-real-8 -fdefault-double-8 options would be
very problematic for many climate modeling libraries where similar '-r8' option
works as users expect in different compilers: pro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101918
--- Comment #8 from Rimvydas (RJ) ---
If we can agree that use of -fdefault-real-8 -fdefault-double-8 with -flto does
not magically recompile intrinsic subroutines in runtime libgfortran.so
library, it looks like it is a frontend issue not provi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97571
--- Comment #13 from Rimvydas (RJ) ---
I agree that it is preferred to rewrite such look up table initialization,
however it is not always possible due to licensing restrictions preventing
making local modifications to the source code provided.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101918
--- Comment #12 from Rimvydas (RJ) ---
(In reply to kargl from comment #11)
> One of these is no like the others. Yes, the behavior is documented,
> and the unlike other result is likely the result that is no desired
> unless the user enjoys cha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101918
--- Comment #14 from Rimvydas (RJ) ---
(In reply to Steve Kargl from comment #13)
> The -fdefault-* options change the storage association rules
> in a way that breaks Fortran. Places of concern include, but
> are not limited, to COMMON, EQUIVA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101918
--- Comment #16 from Rimvydas (RJ) ---
(In reply to Steve Kargl from comment #15)
> I'm also the person that made these options work
> for some definition of "work", and I have always considered
> these options to be broken because of what you a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101918
--- Comment #18 from Rimvydas (RJ) ---
(In reply to Steve Kargl from comment #17)
> There is Fortran code in libgfortran that is compiled
> by gfortran when the compiler is built. Whether that
> code works as intended when someone uses -fdefaul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101918
--- Comment #20 from Rimvydas (RJ) ---
Full -fdump-tree-original foo.f90.005t.original from Comment #8 example:
__attribute__((fn spec (". ")))
void foo ()
{
static real(kind=8) b[4] = {[0 ... 3]=1.0e+0};
real(kind=8) h[4];
{
struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101918
--- Comment #21 from Rimvydas (RJ) ---
After long poking with gdb the tree t1 and t2 structures in
lto-symtab.c:warn_type_compatibility_p() just before "lev |5" is returned, it
looks like trees are are almost identical except for t1->decl_common
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101918
--- Comment #22 from Rimvydas (RJ) ---
Created attachment 51398
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51398&action=edit
proposed patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101918
--- Comment #23 from Rimvydas (RJ) ---
Created attachment 51399
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51399&action=edit
additional patch, for previous behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101918
--- Comment #24 from Rimvydas (RJ) ---
Created attachment 51400
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51400&action=edit
alog() intrinsic testcases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101918
--- Comment #25 from Rimvydas (RJ) ---
Created attachment 51401
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51401&action=edit
testcase with ice deep in rtl code for sign extend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102145
Rimvydas (RJ) changed:
What|Removed |Added
CC||rimvydas.jas at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102145
--- Comment #5 from Rimvydas (RJ) ---
Created attachment 51441
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51441&action=edit
old WIP for arg mismatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101918
Rimvydas (RJ) changed:
What|Removed |Added
Attachment #51398|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102145
--- Comment #7 from Rimvydas (RJ) ---
(In reply to kargl from comment #6)
> Well, that's what it should do! Argument mismatch has never
> been permitted by any Fortran standard. So, PEDANTICALLY
> speaking it is an error to allow.
Pedantically
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102145
--- Comment #9 from Rimvydas (RJ) ---
(In reply to Steve Kargl from comment #8)
> Yes, it should behave like -pedantic-errors.
Actually no, -pedantic is equivalent to -Wpedantic, while -pedantic-errors is
-Werror=pedantic. Rest is interpretatio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102145
--- Comment #11 from Rimvydas (RJ) ---
(In reply to Steve Kargl from comment #10)
> Yes, I know -std=legacy implies -fallow-argument-mismatch. The
> option degrades an ERROR to a WARNING. That is all it does.
> With -std=legacy, gfortran is a
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: rimvydas.jas at gmail dot com
Target Milestone: ---
Given latest gcc/testsuite/gfortran.dg/c-interop/ failures it might be a good
time generalize most of gcc/testsuite/gfortran.dg/ tests for easier detection
of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102394
--- Comment #1 from Rimvydas (RJ) ---
Created attachment 51475
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51475&action=edit
possible generalizations
=== gfortran Summary ===
-# of expected passes 60534
+# of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102394
--- Comment #2 from Rimvydas (RJ) ---
Also with updated toolchain to glibc-2.34 (still not sure if this was not
happening before) noticed that very rarely one test in particular sometimes
fail during parallel check-gcc-fortran. Running explicitl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108056
Rimvydas (RJ) changed:
What|Removed |Added
CC||rimvydas.jas at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81615
Rimvydas (RJ) changed:
What|Removed |Added
CC||rimvydas.jas at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107397
Rimvydas (RJ) changed:
What|Removed |Added
CC||rimvydas.jas at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107397
--- Comment #10 from Rimvydas (RJ) ---
Created attachment 54121
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54121&action=edit
testcase fix
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: rimvydas.jas at gmail dot com
Target Milestone: ---
$ cat bar.c
void bar_(const int flag[], const int *num) { }
$ cat foo.f90
program foo
integer :: idummy(0)
call bar
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: rimvydas.jas at gmail dot com
Target Milestone: ---
$ cat bar.f90
program bar
implicit none
logical :: mask(2,3)
integer :: ai(2,3), vi(5)
real :: ar(2,3), vr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101918
--- Comment #1 from Rimvydas (RJ) ---
Also several programs report spurious warnings:
: warning: type of '__builtin_realloc' does not match original
declaration [-Wlto-type-mismatch]
/opt/nwp/gcc11/include/stdlib.h:550:14: note: type mismatch in
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: rimvydas.jas at gmail dot com
Target Milestone: ---
$ cat gl_test.f90
program foo
implicit none
character(len=100) :: c =' '
if (c(1:12) == 'Accumulated ') c = c(13:len_trim(c))
end progr
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: rimvydas.jas at gmail dot com
Target Milestone: ---
$ cat bar.c
#include
void bar_ (char *cdname, /*float*/ double *pkey, char *cdfile, size_t
cdname_len, size_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102079
--- Comment #1 from Rimvydas (RJ) ---
On side note the gfortran -fc-prototypes-external do suggest (as documentation
for gfortran v8 and newer) to use size_t type for hidden character array
lengths that are passed by value instead of usual by re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101919
--- Comment #6 from Rimvydas (RJ) ---
Additional reduced testcase.
$ cat bar.F90
subroutine bar()
implicit none
character(len=80) :: base
#ifdef V1
character(len=80),parameter :: f='longname_patterns.xml'
integer,parameter :: k = len_tr
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: rimvydas.jas at gmail dot com
Target Milestone: ---
$ cat foo.f90
subroutine foo(x,y,z)
implicit none
real(kind=selected_real_kind(9,99)) :: x(1), y(1,1), z(1)
z
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110888
--- Comment #1 from Rimvydas (RJ) ---
Created attachment 55680
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55680&action=edit
possible fix
With this patch an extra register is freed and compiler produces expected code
on x86_64:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110888
--- Comment #5 from Rimvydas (RJ) ---
It is more like this problem:
$ cat foo.c
void foo_(double *x, double *y, double *z)
{
int i;
__builtin_memset(z, 0, 8); /* z[0] = 0.0; */
for (i=0; i<1 ; i++)
z[0] += x[0] * y[0];
}
$ gcc -O2 -Wa
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: rimvydas.jas at gmail dot com
Target Milestone: ---
Spotted while checking why someone was manually mangling names with bind(c).
$ cat foo.f90
module intfb_pack
interface
!subroutine bar(x) bind(c, name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111218
Rimvydas (RJ) changed:
What|Removed |Added
CC||rimvydas.jas at gmail dot com
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: rimvydas.jas at gmail dot com
Target Milestone: ---
The GCC configured with --enable-default-pie gives:
=== libstdc++ tests ===
Running target unix
FAIL
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rimvydas.jas at gmail dot com
Target Milestone: ---
Strange ICE does not happen with -O{0,2,3,s,g} or with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111906
Rimvydas (RJ) changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111906
--- Comment #5 from Rimvydas (RJ) ---
ICE reproducible again outside check-gcc-c testing with gcc-14-4902 build:
However it still passes with "-O1 -std=gnu2x" this time.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111315
--- Comment #6 from Rimvydas (RJ) ---
(In reply to Xi Ruoyao from comment #5)
> Maybe related to PR112263 but I'm not sure.
Can confirm that with patch posted at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112263#c7 the stacktrace.cc
testsuite
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: rimvydas.jas at gmail dot com
Target Milestone: ---
Same vanishing diagnostics can be reproduced by running testsuite with:
$ make check-gcc-c -k RUNTESTFLAGS="--target_board
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112378
--- Comment #1 from Rimvydas (RJ) ---
The -fanalyzer does not seem to handle glibc __CONST_SOCKADDR_ARG definitions
with transparent_unions that are used under -D_GNU_SOURCE (__USE_GNU).
Minimal reduced testcase:
$ cat test_sockaddr.c
struct so
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: rimvydas.jas at gmail dot com
Target Milestone: ---
Bisected down to recent g:611be07e48956c8b7371eb580eef124990114fd3
$ cat test_associate.f90
subroutine foo(y, x)
implicit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109948
--- Comment #1 from Rimvydas (RJ) ---
More trivial testcase resulting in similar ICE.
$ cat test_associate2.f90
subroutine foo(grib)
implicit none
type b
integer, allocatable :: k_2d(:)
end type
type(b) :: grib
integer :: i
associate(k=>grib
1 - 100 of 110 matches
Mail list logo
