https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117661
--- Comment #1 from Rimvydas (RJ) ---
On a side note, similar issue happens with MPI commons.
.comm mpi_fortran_argv_null_,1,16
.comm mpi_fortran_argvs_null_,1,16
.comm mpi_fortran_bottom_,4,16
.comm mpi_f
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: rimvydas.jas at gmail dot com
Target Milestone: ---
$ cat foo.f90
module goo
use, intrinsic :: ieee_arithmetic, only : ieee_is_nan
include 'mpif.h'
integer :: k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117474
--- Comment #7 from Rimvydas (RJ) ---
(In reply to anlauf from comment #6)
>
> OK, this is really a memory hog.
>
> Replacing the many "use phys_base_mod, only : phys_base" by a simple
>
> import
>
> in the interfaces after putting
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117474
--- Comment #4 from Rimvydas (RJ) ---
Created attachment 59594
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59594&action=edit
module import tester inside interface blocks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117474
--- Comment #5 from Rimvydas (RJ) ---
Added initial hand-reduced reproducer. It took quite a few iterations to
carefully cut out many small parts of original case while trying to preserve
original observed behavior of memory and walltime usage.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117474
--- Comment #3 from Rimvydas (RJ) ---
Created attachment 59593
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59593&action=edit
reproducer
Just module files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117474
--- Comment #1 from Rimvydas (RJ) ---
It seams there are no major memory leaks.
$ valgrind --leak-check=full /usr/lib64/gcc/x86_64-suse-linux/14/f951 -I.
test.f90
...
==118405== 1,234,200 bytes in 4,675 blocks are definitely lost in loss record
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: rimvydas.jas at gmail dot com
Target Milestone: ---
After addition of init() methods it was noticed that certain
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
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=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
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=111906
Rimvydas (RJ) changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111218
Rimvydas (RJ) changed:
What|Removed |Added
CC||rimvydas.jas at gmail dot com
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=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
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:
: 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=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
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: rimvydas.jas at gmail dot com
Target Milestone: ---
$ cat test_iargc.f90
program foo
implicit none
integer :: iargc
integer :: z
associate(x=>z)
associate(y=>z)
if(iargc().lt.5) stop 5
end associat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109948
--- Comment #5 from Rimvydas (RJ) ---
(In reply to anlauf from comment #4)
> Can you check if this works for you?
This patch allows to avoid issue on all other associate use cases (tried on
gcc-13 branch).
However it is a bit suspicious that u
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
: 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=108705
Rimvydas (RJ) changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAITING
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
--- 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 #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 #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 -
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 #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
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
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: 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 foo.f90
program foo
end program
module buffer
integer,allocatable :: mpi_ids(:)
contains
subroutine method(ids
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
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=81615
Rimvydas (RJ) changed:
What|Removed |Added
CC||rimvydas.jas at gmail dot com
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=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=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=104134
Rimvydas (RJ) changed:
What|Removed |Added
CC||rimvydas.jas at gmail dot com
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=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?
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
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
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
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=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
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=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
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 #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=101918
Rimvydas (RJ) changed:
What|Removed |Added
Attachment #51398|0 |1
is obsolete|
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=102145
Rimvydas (RJ) changed:
What|Removed |Added
CC||rimvydas.jas at gmail dot com
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=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 #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 #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 #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 #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 #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 #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 #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 #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=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 #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=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=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
: 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
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
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
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
: 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
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
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
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
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
Rimvydas (RJ) changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #10 from Rimvydas (RJ)
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
--- 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
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?
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=96504
Rimvydas (RJ) changed:
What|Removed |Added
CC||rimvydas.jas at gmail dot com
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=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
: 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=96817
Rimvydas (RJ) changed:
What|Removed |Added
CC||rimvydas.jas at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88707
Rimvydas (RJ) changed:
What|Removed |Added
CC||rimvydas.jas at gmail dot com
: 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=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
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 #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.
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
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
: 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: ---
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: ---
Created attachment 43199
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43199&action=edit
testcase
Attached testcase on openS
1 - 100 of 110 matches
Mail list logo
