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
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
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
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
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=edit
possible fix
With this patch an extra register is freed and compiler produces expected code
on x86_64:
movsd
: 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 =
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
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
: 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!
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
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=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
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
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: Variable
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=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*
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:
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=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=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=edit
xfails
Testsuite on x86_64-*-dragonfly gi
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=edit
simple fix
Testsuite on x86_64-*-dragonfly gives:
$ gmake check-gcc-c -k RUNTESTFL
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
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=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
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
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
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.
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=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=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=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=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=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
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
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
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,
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
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
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:
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
: 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 program
$ gfortran -Wall
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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98318
Rimvydas (RJ) changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #10 from Rimvydas
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
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=edit
possible fix
Since the introduction of libcody, gcc bootstrap is broken on DragonFly
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*)':
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
: 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=edit
reduced testcase
Attached is very reduced case from autogenera
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
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=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=edit
testcase
Wouldn't -Wignored-attribu
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=edit
testcase
Attached testcase on openSUSE and Dragon
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
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
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=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++
: 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=edit
bare minimum testcase, to s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77473
Rimvydas (RJ) changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
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
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=edit
possible variant to use libc internal status variable
On DragonFly libpthread always brings libc so __isthreaded is
1 - 100 of 102 matches
Mail list logo
