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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117661
Bug ID: 117661
Summary: Possible inconsistency with ns traversals in
type-bound procedures
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
Severity: normal
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117474
Bug ID: 117474
Summary: Excessive memory usage during parser stage in
interface blocks with types having type-bound
procedures
Product: gcc
Version: 14.2.1
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112378
Bug ID: 112378
Summary: Missing -fanalizer diagnostics with glibc
under _GNU_SOURCE
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
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|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111906
Bug ID: 111906
Summary: ICE: segfault during GIMPLE pass: dom in gsi_prev()
testsuite torture/bitint-39.c with -O1 (expensive
tests)
Product: gcc
Version: 14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111315
Bug ID: 111315
Summary: libstdc++ stacktrace testsuite failures with
--enable-default-pie
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111218
Rimvydas (RJ) changed:
What|Removed |Added
CC||rimvydas.jas at gmail dot com
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110993
Bug ID: 110993
Summary: Possibly bogus diagnostic on renamed interface import
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
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:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110888
Bug ID: 110888
Summary: Missing optimization for trivial MATMUL cases,
requires -fno-signed-zeros
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: norm
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110350
Bug ID: 110350
Summary: Intrinsic handling inside nested associate blocks
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109948
Bug ID: 109948
Summary: ICE(segfault) in gfc_expression_rank() from
gfc_op_rank_conformable()
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
Severity: normal
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 -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108735
Bug ID: 108735
Summary: Wrong line reported on -Wmaybe-uninitialized false
positive at -O2 and missing optimizations
Product: gcc
Version: 13.0
Status: UNCONFIRMED
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108705
Bug ID: 108705
Summary: Unexpected CPU time usage with LTO in ranger
propagation
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108686
Bug ID: 108686
Summary: Spurious -Wc-binding-type diagnostics when including
omp_lib.h
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108592
Bug ID: 108592
Summary: In IF statements -Winteger-division is repeated 4
times
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108349
Bug ID: 108349
Summary: LTO mismatch for __builtin_realloc between glibc and
gfortran frontend
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
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
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81615
Rimvydas (RJ) changed:
What|Removed |Added
CC||rimvydas.jas at gmail dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108056
Rimvydas (RJ) changed:
What|Removed |Added
CC||rimvydas.jas at gmail dot com
--- Comme
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
--- Comme
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?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104022
Bug ID: 104022
Summary: g++.dg/gcov/pr16855.C does not precleanup upon
failures
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104021
Bug ID: 104021
Summary: gcc.dg/vect/tsvc tests failures
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104019
Bug ID: 104019
Summary: Testsuite
17_intro/headers/c++2020/stdc++_multiple_inclusion.cc
failures
Product: gcc
Version: 12.0
Status: UNCONFIRMED
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102394
Bug ID: 102394
Summary: Gfortran testsuite could avoid target specific tests
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
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
--- Comme
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102079
Bug ID: 102079
Summary: Misleading -Wlto-type-mismatch warning on wrong float
type to C function
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: nor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101919
Bug ID: 101919
Summary: Inconsistent -Wstringop-overread warning with -flto
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101918
Bug ID: 101918
Summary: LTO type mismatches for runtime library functions in
mixed -fdefault-real-8 projects
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101917
Bug ID: 101917
Summary: Spurious -Wstringop-overread with -flto when passing
zero sized arrays
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99270
Bug ID: 99270
Summary: Testsuite 27_io/headers/cstdio/types_std.cc failure on
DragonFly
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99265
Bug ID: 99265
Summary: Testsuite 17_intro/headers/c++2020/stdc++.cc failure
after std::chrono changes
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity
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)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98344
Bug ID: 98344
Summary: Testsuite 17_intro/headers/c++2020/stdc++.cc failure
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
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?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98318
Bug ID: 98318
Summary: libcody breaks DragonFly bootstrap
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96504
Rimvydas (RJ) changed:
What|Removed |Added
CC||rimvydas.jas at gmail dot com
--- Commen
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97571
Bug ID: 97571
Summary: long parsing phase for simple array constructor
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96817
Rimvydas (RJ) changed:
What|Removed |Added
CC||rimvydas.jas at gmail dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88707
Rimvydas (RJ) changed:
What|Removed |Added
CC||rimvydas.jas at gmail dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97554
Bug ID: 97554
Summary: ICE: during RTL pass: cprop /segfault in sbitmap
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: r
92 matches
Mail list logo
