[Bug analyzer/112378] Missing -fanalizer diagnostics with glibc under _GNU_SOURCE

[rimvydas.jas at gmail dot com via Gcc-bugs]

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 sockaddr; struct sockaddr_x25;

#if defined __cplusplus || !defined _GNU_SOURCE
# define __CONST_SOCKADDR_ARG   const struct sockaddr *
#else
typedef union {
  const struct sockaddr * __sockaddr__; /* ... */
  const struct sockaddr_x25 * __sockaddr_x25__;
  } __CONST_SOCKADDR_ARG __attribute__ ((__transparent_union__));
#endif

extern int connect (int __fd, __CONST_SOCKADDR_ARG __addr, unsigned int __len);
extern void __analyzer_eval (int);

void test_null_connect (int fd)
{ __analyzer_eval (connect (fd, 0, 0) == -1); } /* { dg-warning "TRUE" } */

$ ./gcc/xgcc -Bgcc/ -fdiagnostics-plain-output -fanalyzer -c test_sockaddr.c
test_sockaddr.c: In function 'test_null_connect':
test_sockaddr.c:16:3: warning: TRUE
$ ./gcc/xgcc -Bgcc/ -fdiagnostics-plain-output -fanalyzer -c test_sockaddr.c
-D_GNU_SOURCE
test_sockaddr.c: In function 'test_null_connect':
test_sockaddr.c:16:3: warning: UNKNOWN

[Bug analyzer/112378] New: Missing -fanalizer diagnostics with glibc under _GNU_SOURCE

[rimvydas.jas at gmail dot com via Gcc-bugs]

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
  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=unix/-D_GNU_SOURCE
analyzer.exp"

Running target unix/-D_GNU_SOURCE
FAIL: gcc.dg/analyzer/fd-accept.c  (test for warnings, line 17)
FAIL: gcc.dg/analyzer/fd-accept.c  (test for warnings, line 22)
FAIL: gcc.dg/analyzer/fd-accept.c  (test for warnings, line 23)
FAIL: gcc.dg/analyzer/fd-accept.c  (test for warnings, line 34)
FAIL: gcc.dg/analyzer/fd-accept.c warning (test for warnings, line 57)
FAIL: gcc.dg/analyzer/fd-accept.c final event at line 58 (test for warnings,
line 57)
FAIL: gcc.dg/analyzer/fd-accept.c warning (test for warnings, line 68)
FAIL: gcc.dg/analyzer/fd-accept.c final event at line 69 (test for warnings,
line 68)
FAIL: gcc.dg/analyzer/fd-bind.c  (test for warnings, line 27)
FAIL: gcc.dg/analyzer/fd-bind.c  (test for warnings, line 28)
FAIL: gcc.dg/analyzer/fd-bind.c warning (test for warnings, line 38)
FAIL: gcc.dg/analyzer/fd-bind.c final event at line 39 (test for warnings, line
38)
FAIL: gcc.dg/analyzer/fd-bind.c warning (test for warnings, line 74)
FAIL: gcc.dg/analyzer/fd-bind.c final event at line 75 (test for warnings, line
74)
FAIL: gcc.dg/analyzer/fd-bind.c (test for excess errors)
FAIL: gcc.dg/analyzer/fd-connect.c  (test for warnings, line 20)
FAIL: gcc.dg/analyzer/fd-connect.c  (test for warnings, line 21)
FAIL: gcc.dg/analyzer/fd-connect.c  (test for warnings, line 35)
FAIL: gcc.dg/analyzer/fd-connect.c warning (test for warnings, line 45)
FAIL: gcc.dg/analyzer/fd-connect.c final event at line 46 (test for warnings,
line 45)
FAIL: gcc.dg/analyzer/fd-connect.c (test for excess errors)
FAIL: gcc.dg/analyzer/fd-datagram-socket.c  (test for warnings, line 61)
FAIL: gcc.dg/analyzer/fd-datagram-socket.c  (test for warnings, line 65)
FAIL: gcc.dg/analyzer/fd-datagram-socket.c  (test for warnings, line 72)
FAIL: gcc.dg/analyzer/fd-datagram-socket.c  (test for warnings, line 78)
FAIL: gcc.dg/analyzer/fd-datagram-socket.c  (test for warnings, line 94)
FAIL: gcc.dg/analyzer/fd-datagram-socket.c warning (test for warnings, line
109)
FAIL: gcc.dg/analyzer/fd-datagram-socket.c final event at line 110 (test for
warnings, line 109)
FAIL: gcc.dg/analyzer/fd-listen.c  (test for warnings, line 26)
FAIL: gcc.dg/analyzer/fd-listen.c warning (test for warnings, line 33)
FAIL: gcc.dg/analyzer/fd-listen.c final event at line 34 (test for warnings,
line 33)
FAIL: gcc.dg/analyzer/fd-listen.c  (test for warnings, line 43)
FAIL: gcc.dg/analyzer/fd-listen.c warning (test for warnings, line 44)
FAIL: gcc.dg/analyzer/fd-listen.c final event at line 45 (test for warnings,
line 44)
FAIL: gcc.dg/analyzer/fd-listen.c warning (test for warnings, line 64)
FAIL: gcc.dg/analyzer/fd-listen.c final event at line 65 (test for warnings,
line 64)
FAIL: gcc.dg/analyzer/fd-socket-misuse.c warning (test for warnings, line 56)
FAIL: gcc.dg/analyzer/fd-socket-misuse.c final event at line 57 (test for
warnings, line 56)
FAIL: gcc.dg/analyzer/fd-socket-misuse.c  (test for warnings, line 58)
FAIL: gcc.dg/analyzer/fd-socket-misuse.c warning (test for warnings, line 66)
FAIL: gcc.dg/analyzer/fd-socket-misuse.c final event at line 67 (test for
warnings, line 66)
FAIL: gcc.dg/analyzer/fd-socket-misuse.c warning (test for warnings, line 86)
FAIL: gcc.dg/analyzer/fd-socket-misuse.c final event at line 87 (test for
warnings, line 86)
FAIL: gcc.dg/analyzer/fd-socket-misuse.c  (test for warnings, line 93)
FAIL: gcc.dg/analyzer/fd-socket-misuse.c warning (test for warnings, line 100)
FAIL: gcc.dg/analyzer/fd-socket-misuse.c final event at line 101 (test for
warnings, line 100)
FAIL: gcc.dg/analyzer/fd-socket-misuse.c (test for excess errors)
FAIL: gcc.dg/analyzer/fd-stream-socket-active-open.c  (test for warnings, line
32)
FAIL: gcc.dg/analyzer/fd-stream-socket-active-open.c  (test for warnings, line
33)
FAIL: gcc.dg/analyzer/fd-stream-socket-active-open.c  (test for warnings, line
39)
FAIL: gcc.dg/analyzer/fd-stream-socket-active-open.c  (test for warnings, line
40)
FAIL: gcc.dg/analyzer/fd-stream-socket-active-open.c  (test for warnings, line
62)
FAIL: gcc.dg/analyzer/fd-stream-socket-active-open.c  (test for warnings, line
63)
FAIL: gcc.dg/analyzer/fd-stream-socket-active-open.c  (test for warnings, line
69)
FAIL: gcc.dg/analyzer/fd-stream-socket-active-open.c  (test for warnings, line
70)
FAIL: gcc.dg/analyzer/fd-stream-socket-active-open.c  (test for warnings, line
71)
FAIL: gcc.dg/analyzer/fd-stream-socket-active-open.c  (test for warnings, line
77)

[Bug libbacktrace/111315] libstdc++ stacktrace testsuite failures with --enable-default-pie

[rimvydas.jas at gmail dot com via Gcc-bugs]

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 testcases (for both -std=gnu++23 and -std=gnu++26) now able to pass
execution tests when gcc is built with ./configure --enable-bootstrap
--enable-default-pie

--- libstdc++-v3/src/libbacktrace/Makefile.orig
+++ libstdc++-v3/src/libbacktrace/Makefile
@@ -232,3 +232,3 @@
 AWK = gawk
-BACKTRACE_CPPFLAGS =  -DHAVE_ATOMIC_FUNCTIONS=1 -DHAVE_SYNC_FUNCTIONS=1
-DHAVE_FCNTL=1 -DBACKTRACE_ELF_SIZE=64
+BACKTRACE_CPPFLAGS = -D_GNU_SOURCE -DHAVE_ATOMIC_FUNCTIONS=1
-DHAVE_SYNC_FUNCTIONS=1 -DHAVE_DL_ITERATE_PHDR=1 -DHAVE_FCNTL=1
-DBACKTRACE_ELF_SIZE=64
 BACKTRACE_SUPPORTED = 1

[Bug tree-optimization/111906] ICE: segfault during GIMPLE pass: dom in gsi_prev() testsuite torture/bitint-39.c with -O1 (expensive tests)

[rimvydas.jas at gmail dot com via Gcc-bugs]

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.

[Bug tree-optimization/111906] ICE: segfault during GIMPLE pass: dom in gsi_prev() testsuite torture/bitint-39.c with -O1 (expensive tests)

[rimvydas.jas at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111906

Rimvydas (RJ)  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #1 from Rimvydas (RJ)  ---
No longer reproducible after g:28d8c680aaea46137170fef2bd1c6a98301518dc +
g:cbf6da166ea7993e166dcb121fc7b9ef4ec87c89 that look to be a no-op for
x86_64-linux.

[Bug tree-optimization/111906] New: ICE: segfault during GIMPLE pass: dom in gsi_prev() testsuite torture/bitint-39.c with -O1 (expensive tests)

[rimvydas.jas at gmail dot com via Gcc-bugs]

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
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 "-O1 -save-temps",
testcase does not reduce.

$ GCC_TEST_RUN_EXPENSIVE=yes make -k check-gcc-c
RUNTESTFLAGS="dg-torture.exp=bitint-39.c"
Running /data/gcc_trunk/gcc/testsuite/gcc.dg/torture/dg-torture.exp ...
FAIL: gcc.dg/torture/bitint-39.c   -O1  (internal compiler error: Segmentation
fault)
FAIL: gcc.dg/torture/bitint-39.c   -O1  (test for excess errors)

=== gcc Summary ===

# of expected passes12
# of unexpected failures2
# of unresolved testcases   1
/tmp/build/gcc/xgcc  version 14.0.0 20231021 (experimental) [master
r14-4812-g66c26e5cfdf] (GCC)

$ valgrind --track-origins=yes ./gcc/cc1
/data/gcc_trunk/gcc/testsuite/gcc.dg/torture/bitint-39.c
-fdiagnostics-plain-output -O1
 bar t115_1add t115_2add t115_3add t115_4add t115_5add t115add t116_1add
t116_2add t116_3add t116_4add t116_5add t116add t117_1add t117_2add t117_3add
t117_4add t117_5add t117add t118_1add t118_2add t118_3add t118_4add t118_5add
t118add t119_1add t119_2add t119_3add t119_4add t119_5add t119add t120_1add
t120_2add t120_3add t120_4add t120_5add t120add t121_1add t121_2add t121_3add
t121_4add t121_5add t121add t122_1add t122_2add t122_3add t122_4add t122_5add
t122add t123_1add t123_2add t123_3add t123_4add t123_5add t123add t124_1add
t124_2add t124_3add t124_4add t124_5add t124add t100_1add t100_2add t100_3add
t100_4add t100_5add t100add t101_1add t101_2add t101_3add t101_4add t101_5add
t101add t102_1sub t102_2sub t102_3sub t102_4sub t102_5sub t102sub t103_1sub
t103_2sub t103_3sub t103_4sub t103_5sub t103sub t104_1mul t104_2mul t104_3mul
t104_4mul t104_5mul t104mul t105_1mul t105_2mul t105_3mul t105_4mul t105_5mul
t105mul t106_1mul t106_2mul t106_3mul t106_4mul t106_5mul t106mul t107_1add
t107_2add t107_3add t107_4add t107_5add t107add t108_1add t108_2add t108_3add
t108_4add t108_5add t108add t109_1add t109_2add t109_3add t109_4add t109_5add
t109add t110_1sub t110_2sub t110_3sub t110_4sub t110_5sub t110sub t111_1add
t111_2add t111_3add t111_4add t111_5add t111add t112_1add t112_2add t112_3add
t112_4add t112_5add t112add t113_1add t113_2add t113_3add t113_4add t113_5add
t113add t114_1add t114_2add t114_3add t114_4add t114_5add t114add main
Analyzing compilation unit
Performing interprocedural optimizations
 <*free_lang_data> {heap 0 }  {heap 0 }  {heap 0
}  {heap 0 }  {heap 0 }  {heap 0
}  {heap 0 }Streaming LTO
  {heap 0 }  {heap 0 }  {heap 0 }
 {heap 0 }  {heap 0 }  {heap 0 } 
{heap 0 }  {heap 0 }  {heap 0 }  {heap 0
}Assembling functions:
  {heap 0 } bar t115_1add t115_2add t115_3add t115_4add t115_5add
t115add t116_1add t116_2add t116_3add t116_4add t116_5add t116add t117_1add {GC
released 1080k} {GC 5369k -> 3189k} t117_2add t117_3add t117_4add t117_5add
t117add t118_1add t118_2add t118_3add t118_4add t118_5add t118add t119_1add
t119_2add t119_3add t119_4add t119_5add t119add t120_1add t120_2add {GC
released 1932k madv_dontneed 64k} {GC 5354k -> 3100k} t120_3add t120_4add
t120_5add t120add t121_1add t121_2add t121_3add t121_4add t121_5add t121add
t122_1add t122_2add t122_3add t122_4add t122_5add t122add t123_1add t123_2add
{GC released 2044k} {GC 5347k -> 2993k} t123_3add t123_4add t123_5add t123add
t124_1add t124_2add t124_3add t124_4add t124_5add t124add t100_1add t100_2add
t100_3add t100_4add t100_5add t100add t101_1add t101_2add t101_3add t101_4add
t101_5add t101add t102_1sub t102_2sub t102_3sub t102_4sub t102_5sub t102sub
t103_1sub t103_2sub t103_3sub t103_4sub t103_5sub t103sub t104_1mul t104_2mul
t104_3mul t104_4mul t104_5mul {GC released 1988k} {GC 5325k -> 2670k}==82656==
Invalid read of size 8
==82656==at 0x11568B4: gsi_prev (gimple-iterator.h:202)
==82656==by 0x11568B4:
dom_opt_dom_walker::before_dom_children(basic_block_def*)
(tree-ssa-dom.cc:1764)
==82656==by 0x1E2B86E: dom_walker::walk(basic_block_def*) (domwalk.cc:311)
==82656==by 0x1157278: (anonymous
namespace)::pass_dominator::execute(function*) (tree-ssa-dom.cc:939)
==82656==by 0xEF2628: execute_one_pass(opt_pass*) (passes.cc:2641)
==82656==by 0xEF2EAF: execute_pass_list_1(opt_pass*) (passes.cc:2750)
==82656==by 0xEF2EC1: execute_pass_list_1(opt_pass*) (passes.cc:2751)
==82656==by 0xEF2EE8: execute_pass_list(function*, opt_pass*)
(passes.cc:2761)
==82656==by 0xB1F345: expand (cgraphunit.cc:1841)
==82656==by 0xB1F345: cgraph_node::expand() (cgraphunit.cc:1794)
==82656==by 0xB2111A: 

[Bug libstdc++/111315] New: libstdc++ stacktrace testsuite failures with --enable-default-pie

[rimvydas.jas at gmail dot com via Gcc-bugs]

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
  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: 19_diagnostics/stacktrace/entry.cc execution test
FAIL: 19_diagnostics/stacktrace/stacktrace.cc execution test

libstdc++-v3/testsuite/19_diagnostics/stacktrace/entry.cc:39: void
test_members(): Assertion 'e1.source_line() == (__LINE__ - 5)' failed.
libstdc++-v3/testsuite/19_diagnostics/stacktrace/stacktrace.cc:132: void
test_assign(): Assertion 's0.at(0).source_line() == (__LINE__ - 4)' failed.

In both cases source_line() methods return 0.

Also, the -fno-pie option cannot be used when linking these tescases:
/usr/bin/ld: /tmp/ccv2BTff.o: relocation R_X86_64_32 against symbol
`_ZNSt16stacktrace_entry14_S_err_handlerEPvPKci' can not be used when making a
PIE object; recompile with -fPIE

[Bug fortran/111218] Conflict in BIND(C) INTERFACEs in two Modules leads to ICE.

[rimvydas.jas at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111218

Rimvydas (RJ)  changed:

   What|Removed |Added

 CC||rimvydas.jas at gmail dot com

--- Comment #4 from Rimvydas (RJ)  ---
Another testcase resulting in identical ICE.

$ cat test.f90
module foo1
  interface !bail ! generic works ok
subroutine bail() bind(c,name="bail_")
end subroutine
  end interface
end

module foo2
  interface !bail
subroutine sfx_bail(k)
  integer :: k
end subroutine
  end interface
end

module foo
  use foo1
  use foo2 , bail => sfx_bail
end

subroutine unice_dummy ! avoid ice
end

$ ./gcc/f951 test.f90
test.f90:21:22:

   21 | subroutine unice_dummy
  |  1
Error: Name 'bail' at (1) is an ambiguous reference to 'bail' from module
'foo1'

Using extra dummy unit at the end of file helps to avoid the ICE (avoids ICE on
original case too), but notice the wrong locus.  Issue here happens because
ambiguous_symbol() is called after parsing was already done, resulting in
nullification of gfc_current_locus global in gfc_advance_line () at
gcc/fortran/scanner.cc:651
651   gfc_current_locus.nextc = NULL;
So the "%C" cannot be used in gcc/fortran/symbol.cc:3167
  gfc_error ("Name %qs at %C is an ambiguous reference to %qs "
Note: there is an assertion in gcc/fortran/error.cc:1078
  gcc_assert (loc->nextc - loc->lb->line >= 0);


Question is weather bind(c) rename attribute should somehow affect interface
generic status in any way?
Testcase does pass with bind(c) commented out or with explicitly marked
interface as generic in foo1.

[Bug fortran/110993] New: Possibly bogus diagnostic on renamed interface import

[rimvydas.jas at gmail dot com via Gcc-bugs]

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
 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="bar_") ! does not warn
!subroutine bar(x) bind(c, name="bar") ! Error: More actual than formal
arguments in procedure call
subroutine bar(x) ! Warning: Shape mismatch in argument 'x'
  use iso_c_binding, only : c_float
  implicit none
  real(c_float) :: x(45)
end subroutine
  end interface
end module

subroutine foo(x)
  use intfb_pack, notthisone => bar
  implicit none
  real :: x(3)
  call bar(x)
end subroutine

$ gfortran -c foo.f90
foo.f90:17:13:

   14 |   use intfb_pack, notthisone => bar
  |  2
..
   17 |   call bar(x)
  | 1
Warning: Shape mismatch in argument 'x' between (1) and (2)

The diagnostic is a bit surprising given that selective import with "use
intfb_pack, only:" does not emit diagnostics.  Moreover, the "bind(c,
name="bar")" case hard error seems very wrong.

[Bug fortran/110888] Missing optimization for trivial MATMUL cases, requires -fno-signed-zeros

[rimvydas.jas at gmail dot com via Gcc-bugs]

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 -Wall -Wextra -c foo.c -S -fdump-tree-optimized
   [local count: 536870913]:
  __builtin_memset (z_9(D), 0, 8);
  _17 = *x_11(D);
  _18 = *y_12(D);
  _19 = _17 * _18;
  _20 = _19 + 0.0;
  *z_9(D) = _20;
  return;

It would be beneficial for all frontends if the use of __builtin_memset() to
zero out accumulators would be be considered as !HONOR_SIGNED_ZEROS at least
during PRE pass in the middle-end.  If that would complicate things, then
easier solution is to add special case in gfortran frontend-passes that simply
transforms expression to drop accumulator: z[0] = x[0] * y[0];

* side note, in C the redundant __builtin_memset() does not get optimized out,
unlike in gfortran "zero" expr version.  Might be middle-end optimization
passes ordering issue.  At least PRE pass does take accumulator zeroing into
account.

[Bug fortran/110888] Missing optimization for trivial MATMUL cases, requires -fno-signed-zeros

[rimvydas.jas at gmail dot com via Gcc-bugs]

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   (%rdi), %xmm0
mulsd   (%rsi), %xmm0
movsd   %xmm0, (%rdx)
ret

Patch could be expanded to consider inlining trivial matmul cases even for
known arrays of size 1 with rank > 2.

[Bug fortran/110888] New: Missing optimization for trivial MATMUL cases, requires -fno-signed-zeros

[rimvydas.jas at gmail dot com via Gcc-bugs]

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: 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 = matmul(x,y)
end subroutine

$ gfortran -c -S -Wall -Wextra -O2 -fdump-tree-optimized foo.f90

The do loop get reduced in matmul intrinsic implementation, however redundant
accumulator store is not optimized out during PRE if
-ffast-math(-fno-signed-zeros) is not used:
[local count: 536870912]:
   __builtin_memset (z_11(D), 0, 8);
-  _18 = (*z_11(D))[0];
   _19 = (*x_13(D))[0];
   _20 = (*y_14(D))[0];
   _21 = _19 * _20;
-  _22 = _18 + _21;
+  _22 = _21 + 0.0;
   (*z_11(D))[0] = _22;
   return;

Not sure if it is possible to mark accumulator expr as artificial so that
optimizers could ignore side effects by default, but luckily it is easily
avoidable in frontend itself.

[Bug fortran/101919] Inconsistent -Wstringop-overread warning with -flto

[rimvydas.jas at gmail dot com via Gcc-bugs]

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_trim(f)
#else
# ifdef V2
  character(len=80),parameter :: f='longname_patterns.xml'
# else
  character(len=80) :: f='longname_patterns.xml'
# endif
  integer :: k
  k = len_trim(f)
#endif
  base = f(10:k-4)
  print *, base, '@'
end subroutine bar

$ gfortran -DV1 -flto -O0 -Wall -Wextra -c bar.F90
$ gcc -shared bar.o -o libbar.so -fdump-tree-optimized
$ gfortran -DV2 -flto -O1 -Wall -Wextra -c bar.F90
$ gcc -shared bar.o -o libbar.so -fdump-tree-optimized
$ gfortran -DV2 -flto -O0 -Wall -Wextra -c bar.F90
$ gcc -shared bar.o -o libbar.so -fdump-tree-optimized
bar.F90: In function ‘bar’:
bar.F90:16:18: warning: ‘__builtin_memmove’ reading 80 bytes from a region of
size 71 [-Wstringop-overread]
   16 |   base = f(10:k-4)
  |  ^
$ gfortran -flto -O3 -Wall -Wextra -c bar.F90
$ gcc -shared bar.o -o libbar.so -fdump-tree-optimized
bar.F90: In function ‘bar’:
bar.F90:16:18: warning: ‘__builtin_memcpy’ reading 80 bytes from a region of
size 71 [-Wstringop-overread]
   16 |   base = f(10:k-4)
  |  ^
bar.F90:11:24: note: at offset 9 into source object ‘f’ of size 80
   11 |   character(len=80) :: f='longname_patterns.xml'
  |

V1 -O0 has:
  __builtin_memcpy (, &"longname_patterns.xml 
 "[10]{lb: 1 sz: 1}, 8);
  _1 =  + 8;
  __builtin_memset (_1, 32, 72);

V2 -O0 has:
  unsigned char base[1:80];
  k_10 = 21;
  _1 = k_10 + -4;
  _11 = (long int) _1;
  _2 = _11 + -9;
  _12 = MAX_EXPR <_2, 0>;< --- discarded ?
  _3 = _11 + -9;
  _13 = MAX_EXPR <_3, 0>;
  _14 = 
  _15 = &"longname_patterns.xml
  "[10]{lb: 1 sz: 1};
  if (_13 <= 79) < --- will always be false
goto ; [INV]
  else
goto ; [INV]
   :
  _4 = (long unsigned int) _13;
  __builtin_memmove (_14, _15, _4);
  _5 = 80 - _13;
  _6 = (long unsigned int) _5;
  _7 = (sizetype) _13;
  _8 = _14 + _7;
  __builtin_memset (_8, 32, _6);
  goto ; [INV]
   :
  __builtin_memmove (_14, _15, 80);


V3 -O3 has:
  static unsigned char f[1:80] = <<< error >>>;
  _1 = _gfortran_string_len_trim (80, );
  k_10 = (int) _1;
  _2 = k_10 + -4;
  if (_2 <= 88) < --- no lower bound and redundant
goto ; [50.00%]
  else
goto ; [50.00%]
   [local count: 536870913]:
  _11 = (long int) _2;
  _3 = _11 + -9;
  _12 = MAX_EXPR <_3, 0>;
  _4 = (long unsigned int) _12;
  __builtin_memcpy (, [10]{lb: 1 sz: 1}, _4);
  _5 = 80 - _12;
  _6 = (long unsigned int) _5;
  _7 =  + _4;
  __builtin_memset (_7, 32, _6);
  goto ; [100.00%]
   [local count: 536870913]:
  __builtin_memcpy (, [10]{lb: 1 sz: 1}, 80)

[Bug fortran/110350] New: Intrinsic handling inside nested associate blocks

[rimvydas.jas at gmail dot com via Gcc-bugs]

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: 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 associate
 end associate
end program
$ gfortran -Wall -Wextra test_iargc.f90 
test_iargc.f90:8:6:

8 |if(iargc().lt.5) stop 5
  |  1
Error: 'iargc' at (1) is not a function

Seems behavior almost the same down to gfortran-4.8
Removing single nested unrelated associate block results in undefined reference
to iargc_()
Removing optional 'integer :: iargc' kind declaration works.

[Bug fortran/109948] [13/14 Regression] ICE(segfault) in gfc_expression_rank() from gfc_op_rank_conformable()

[rimvydas.jas at gmail dot com via Gcc-bugs]

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 using variable name abbreviations (to dig
out arrays from deeply nested types) is enough to change how the internal
gfc_array_ref is populated.  ICE was triggered only on patterns involving first
using abbreviated name indexed access (like k(1)) followed by any operation
involving whole array.

[Bug fortran/109948] ICE(segfault) in gfc_expression_rank() from gfc_op_rank_conformable()

[rimvydas.jas at gmail dot com via Gcc-bugs]

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%k_2d)
i = k(1)
if (any(k==1)) i = 1
end associate
end subroutine foo

[Bug fortran/109948] New: ICE(segfault) in gfc_expression_rank() from gfc_op_rank_conformable()

[rimvydas.jas at gmail dot com via Gcc-bugs]

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
  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 none
type tlap
  real,allocatable :: z(:)
end type tlap
type(tlap) :: y
real :: x(:)
associate(z=>y%z)

if (getpid() == 1) then
  where ( z < 0.0 ) x(:) = z(:)
else
  where ( z < 0.0 ) x(:) = z(:)
endif

end associate
end subroutine foo

$ gfortran -O1 -c test_associate.f90
f951: internal compiler error: Segmentation fault
0xd362af crash_signal
/data/g13/gcc/toplev.cc:314
0x2abfcecf ???
   
/tmp/glibc-2.37/signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x7ca895 gfc_expression_rank(gfc_expr*)
/data/g13/gcc/fortran/resolve.cc:5643
0x7caa44 gfc_op_rank_conformable(gfc_expr*, gfc_expr*)
/data/g13/gcc/fortran/resolve.cc:5676
0x71228c eval_intrinsic
/data/g13/gcc/fortran/arith.cc:1669
0x789edc match_level_4
/data/g13/gcc/fortran/matchexp.cc:646
0x789edc match_and_operand
/data/g13/gcc/fortran/matchexp.cc:693
0x789f66 match_or_operand
/data/g13/gcc/fortran/matchexp.cc:722
0x78a076 match_equiv_operand
/data/g13/gcc/fortran/matchexp.cc:765
0x78a188 match_level_5gfc_op_rank_conformable(
/data/g13/gcc/fortran/matchexp.cc:811
0x7892e4 gfc_match_expr(gfc_expr**)
/data/g13/gcc/fortran/matchexp.cc:870
0x7bf2e0 match_actual_arg
/data/g13/gcc/fortran/primary.cc:1688
0x7c0c88 gfc_match_actual_arglist(int, gfc_actual_arglist**, bool)
/data/g13/gcc/fortran/primary.cc:1953
0x7c3455 gfc_match_rvalue(gfc_expr**)
/data/g13/gcc/fortran/primary.cc:3695
0x7894fe match_primary
/data/g13/gcc/fortran/matchexp.cc:157
0x7894fe match_level_1
/data/g13/gcc/fortran/matchexp.cc:211
0x7894fe match_mult_operand
/data/g13/gcc/fortran/matchexp.cc:267
0x7897c8 match_add_operand
/data/g13/gcc/fortran/matchexp.cc:356
0x789a9c match_level_2
/data/g13/gcc/fortran/matchexp.cc:480
0x789c56 match_level_3
/data/g13/gcc/fortran/matchexp.cc:551
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/108705] [13 Regression] Unexpected CPU time usage with LTO in ranger propagation

[rimvydas.jas at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108705

Rimvydas (RJ)  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|WAITING |RESOLVED

--- Comment #10 from Rimvydas (RJ)  ---
Fixed by g:6493b7af37e473a89c67afab474330f931dd8447 no more issues in ltrans
partitions

[Bug tree-optimization/108705] [13 Regression] Unexpected CPU time usage with LTO in ranger propagation

[rimvydas.jas at gmail dot com via Gcc-bugs]

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!  Will have to check original cases still, but for testcase variants
even bumping calls count from 16 to 222 now takes only:
 assumed size:   ~6s dominator optimization 4.97 ( 85%)
 assumed shape: ~20s callgraph functions expansion 16.47 ( 79%)
  mainly callgraph ipa passes (22%)+alias stmt walk (11%)+tree ssa inc (14%)

[Bug tree-optimization/108705] [13 Regression] Unexpected CPU time usage with LTO in ranger propagation

[rimvydas.jas at gmail dot com via Gcc-bugs]

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 cases.
I think I found a workaround after investigating f951 internals to add support
for NOINLINE attribute in form of:
!GCC$ ATTRIBUTES noinline :: foo
It works with LTO and might be useful for other issues.  I'll post a patch with
feature request in gfortran mailing list after some testing.

If the pr is not reproducible it can be closed as INVALID, since it might be a
host software configuration specific issue.

[Bug tree-optimization/108705] [13 Regression] Unexpected CPU time usage with LTO in ranger propagation

[rimvydas.jas at gmail dot com via Gcc-bugs]

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

[Bug tree-optimization/108705] [13 Regression] Unexpected CPU time usage with LTO in ranger propagation

[rimvydas.jas at gmail dot com via Gcc-bugs]

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 -Bgcc/ -v -O2 -ftime-report -c hog.f90
Reading specs from gcc/specs
COLLECT_GCC=./gcc/gfortran
Target: x86_64-pc-linux-gnu
Configured with: /zzz/gg/configure --disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.1 20230209 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-B' 'gcc/' '-v' '-O2' '-ftime-report' '-c'
'-mtune=generic' '-march=x86-64'
 gcc/f951 hog.f90 -quiet -dumpbase hog.f90 -dumpbase-ext .f90 -mtune=generic
-march=x86-64 -O2 -version -ftime-report -fintrinsic-modules-path finclude
-fpre-include=/usr/include/finclude/math-vector-fortran.h -o /tmp/ccnSnvQ4.s
GNU Fortran (GCC) version 13.0.1 20230209 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 13.0.1 20230209 (experimental), GMP version
6.2.1, MPFR version 4.2.0, MPC version 1.3.1, isl version isl-0.24-GMP

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096

Time variable   usr   sys  wall
  GGC
 phase parsing  :   0.01 (  0%)   0.00 (  0%)   0.01 (  0%)
 1884k ( 55%)
 phase opt and generate :2039.11 (100%)   0.02 (100%)2039.15 (100%)
 1319k ( 39%)
 callgraph functions expansion  :2039.11 (100%)   0.01 ( 50%)2039.13 (100%)
 1145k ( 34%)
 callgraph ipa passes   :   0.00 (  0%)   0.01 ( 50%)   0.02 (  0%)
  151k (  4%)
 df live regs   :   0.00 (  0%)   0.00 (  0%)   0.01 (  0%)
0  (  0%)
 parser (global):   0.01 (  0%)   0.00 (  0%)   0.01 (  0%)
 1884k ( 55%)
 integration:   0.00 (  0%)   0.01 ( 50%)   0.00 (  0%)
  124k (  4%)
 tree VRP   :   6.88 (  0%)   0.00 (  0%)   6.88 (  0%)
   78k (  2%)
 tree SSA rewrite   :   0.00 (  0%)   0.00 (  0%)   0.01 (  0%)
 4488  (  0%)
 tree SSA incremental   :   0.00 (  0%)   0.00 (  0%)   0.01 (  0%)
   26k (  1%)
 dominator optimization :2032.19 (100%)   0.00 (  0%)2032.20 (100%)
   16k (  0%)
 tree PRE   :   0.00 (  0%)   0.00 (  0%)   0.01 (  0%)
   16k (  0%)
 tree conservative DCE  :   0.01 (  0%)   0.00 (  0%)   0.00 (  0%)
 2360  (  0%)
 tree SSA verifier  :   0.00 (  0%)   0.00 (  0%)   0.01 (  0%)
0  (  0%)
 tree modref:   0.00 (  0%)   0.01 ( 50%)   0.00 (  0%)
 6056  (  0%)
 out of ssa :   0.01 (  0%)   0.00 (  0%)   0.00 (  0%)
0  (  0%)
 CSE 2  :   0.01 (  0%)   0.00 (  0%)   0.00 (  0%)
   48  (  0%)
 initialize rtl :   0.01 (  0%)   0.00 (  0%)   0.00 (  0%)
   12k (  0%)
 rest of compilation:   0.00 (  0%)   0.00 (  0%)   0.02 (  0%)
   14k (  0%)
 TOTAL  :2039.12  0.02   2039.16   
 3404k
Extra diagnostic checks enabled; compiler may run slowly.
Configure with --enable-checking=release to disable checks.
COLLECT_GCC_OPTIONS='-B' 'gcc/' '-v' '-O2' '-ftime-report' '-c'
'-mtune=generic' '-march=x86-64'
 gcc/as -v --64 -o hog.o /tmp/ccnSnvQ4.s
GNU assembler version 2.40 (x86_64-pc-linux-gnu) using BFD version (GNU
Binutils) 2.40
COMPILER_PATH=gcc/
LIBRARY_PATH=gcc/:/lib/../lib64/:/usr/lib/../lib64/:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-B' 'gcc/' '-v' '-O2' '-ftime-report' '-c'
'-mtune=generic' '-march=x86-64'

[Bug fortran/108735] New: Wrong line reported on -Wmaybe-uninitialized false positive at -O2 and missing optimizations

[rimvydas.jas at gmail dot com via Gcc-bugs]

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
  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 :: p,r,z,w
i = 1
lev = max(min(abs(lev),99),2) ! [2,99]
do j=i, lev, +1
  if (j==i) then
w = 2
  else
r = w
  endif
  w = r + 1
enddo
do j=lev, i, -1
  if (j==lev) then
z = 2
  else
p = z
  endif
  z = p + 1 ! this is comment
enddo
if (loc(p)>loc(r)) continue ! suppress unused
if (loc(z)>loc(w)) continue ! suppress unused
end subroutine

$ gfortran -Wall -Wextra -O2 -c ilev.f90
ilev.f90:21:29:

   21 |   z = p + 1 ! this is comment
  | ^
Warning: 'z' may be used uninitialized [-Wmaybe-uninitialized]
ilev.f90:4:16:

4 | integer :: p,r,z,w
  |^
note: 'z' was declared here
$ gfortran -Wall -Wextra -O1 -c ilev.f90
ilev.f90:19:9:

   19 | p = z
  | ^
Warning: 'z' may be used uninitialized [-Wmaybe-uninitialized]
ilev.f90:4:16:

4 | integer :: p,r,z,w
  |^
note: 'z' was declared here

The -O2 and above points to wrong line (also end of the comment).

Comparison of -fdump-tree-optimized of first do loop shows that second loop
gets pessimized, the "if (j==lev) then" branch in first iteration is not
considered in initialization analysis while still being store optimized out.

Changing (j==lev) to (j==lev-1) does not promote diagnostic to -Wuninitialized.

Moreover both do loops could be fully optimized down to:
 lev = max(min(abs(lev),99),2)
 r = r + 1*lev - 1
 p = p + 1*lev - 1

[Bug tree-optimization/108705] [13 Regression] Unexpected CPU time usage with LTO in ranger propagation

[rimvydas.jas at gmail dot com via Gcc-bugs]

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 declarations.  Original code trips on
both variants in different ltrans partitions during LTO link.

[Bug tree-optimization/108705] New: Unexpected CPU time usage with LTO in ranger propagation

[rimvydas.jas at gmail dot com via Gcc-bugs]

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
  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 bar() are in separate units in original case
subroutine bar(n,m,p,s) ! in bar.f90
implicit none
integer :: n,m
real,intent(inout) :: p(n),s(*)
!real,intent(inout) :: p(:),s(:) ! gives slower growth
call foo(n,m,p,s)
call foo(n,m,p,s)
call foo(n,m,p,s)
call foo(n,m,p,s)
call foo(n,m,p,s)
call foo(n,m,p,s)
call foo(n,m,p,s)
call foo(n,m,p,s)
call foo(n,m,p,s)
call foo(n,m,p,s)
call foo(n,m,p,s)
call foo(n,m,p,s)
call foo(n,m,p,s)
call foo(n,m,p,s)
call foo(n,m,p,s)
! ...
!call foo(n,m,p,s)
end subroutine bar

subroutine foo(n,m,p,b) ! in foo.f90
implicit none
integer :: n,m,j
real,intent(inout) :: p(n),b(*)
do j=1,n
  b(m+j-1)=p(j)
enddo
m=m+n ! < problematic part
end subroutine foo

$ gfortran -Wall -Wextra -O2 -flto -c hog.f90 # mimic ccBemfcW.ltrans23.o
$ lto1 -ftime-report -fchecking=0 hog.o # -fltrans /tmp/ccBemfcW.ltrans23.o
Reading object files: hog.o {GC 2518k}  {heap 1028k}
Reading the symbol table:
Merging declarations: {GC 2520k}  {heap 1028k}
Reading summaries:  {GC 2520k}  {heap 1028k}  {GC 2520k}
 {heap 1028k}  {GC 2520k}  {heap 1028k}  {GC 2530k}  {heap
1168k}  {GC 2530k}  {heap 1168k}  {GC 2532k}  {heap 1168k}
{GC 2532k} 
Merging symbols: {heap 1168k}Reading function bodies:
Performing interprocedural optimizations
  {heap 1168k}  {heap 1168k}  {heap
1168k}  {heap 1360k}  {heap 1360k}  {heap 1360k}  {heap
1360k}  {heap 1360k}  {heap 1360k}  {heap 1360k}
 {heap 1360k}  {heap 1360k}  {heap 1360k}
 {heap 1360k}  {heap 1360k}Assembling functions:
  {heap 1360k} foo in:foo_ bar in:bar_
Time variable   usr   sys  wall
  GGC
 phase setup:   0.00 (  0%)   0.00 (  0%)   0.00 (  0%)
 2583k ( 67%)
 phase opt and generate :1490.95 (100%)   0.00 (  0%)1491.02 (100%)
 1230k ( 32%)
 callgraph functions expansion  :1490.95 (100%)   0.00 (  0%)1491.02 (100%)
 1201k ( 31%)
 tree VRP   :   5.08 (  0%)   0.00 (  0%)   5.07 (  0%)
   84k (  2%)
 dominator optimization :1485.85 (100%)   0.00 (  0%)1485.92 (100%)
   16k (  0%)
 tree canonical iv  :   0.01 (  0%)   0.00 (  0%)   0.00 (  0%)
   71k (  2%)
 tree loop distribution :   0.00 (  0%)   0.00 (  0%)   0.01 (  0%)
  115k (  3%)
 dead store elim1   :   0.00 (  0%)   0.00 (  0%)   0.01 (  0%)
 2304  (  0%)
 combiner   :   0.01 (  0%)   0.00 (  0%)   0.00 (  0%)
   42k (  1%)
 initialize rtl :   0.00 (  0%)   0.00 (  0%)   0.01 (  0%)
   12k (  0%)
 TOTAL  :1490.95  0.00   1491.02   
 3846k

For 10+ calls adding extra new call adds to total time: 0.21, 1.07, 6.29,
38.74, 238.24, 1490.95, 9424.12, ... seconds of CPU time.

This is not a problem for non-LTO builds since objects need to be compiled only
once for all executables in the project.  However with LTO it means that for
any executable having problematic subroutines in call graph *and* having such
unit pairs in the same ltrans partition would need to be compiled from scratch
over and over.  In original case final LTO link of a first executable with
-flto=20 was still compiling last 3 ltrans partitions after 25h+ (gcc-12 is
fine).

It is quite hard to say where lto1 gets "stuck" (as in infinite loop, no new
output gets added to assembly outputs either).  One has to ps(1) the full
command line, grab /tmp/ccBemfcW.ltrans23.o and manually invoke lto1 to see
where problematic code units could be.  Also there are no support for
attributes to deal with such problems e.g.:
!GCC$ ATTRIBUTES noclone,noinline :: foo
while LTO is getting better at detecting "strategically placed debug write()
statements".

[Bug fortran/108686] New: Spurious -Wc-binding-type diagnostics when including omp_lib.h

[rimvydas.jas at gmail dot com via Gcc-bugs]

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
  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 'depobj_list' at (1) is a dummy argument of the BIND(C)
procedure 'omp_target_memcpy_async' but may not be C interoperable
[-Wc-binding-type]
omp_lib.h:429:58:

Warning: Variable 'depobj_list' at (1) is a dummy argument of the BIND(C)
procedure 'omp_target_memcpy_rect_async' but may not be C interoperable
[-Wc-binding-type]

[Bug fortran/108592] New: In IF statements -Winteger-division is repeated 4 times

[rimvydas.jas at gmail dot com via Gcc-bugs]

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
  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 < (20/9)) stop 8
  |   1
Warning: Integer division truncated to constant ‘2’ at (1) [-Winteger-division]
intdiv.f90:2:11:

2 | if (8 < (20/9)) stop 8
  |   1
Warning: Integer division truncated to constant ‘2’ at (1) [-Winteger-division]
intdiv.f90:2:11:

2 | if (8 < (20/9)) stop 8
  |   1
Warning: Integer division truncated to constant ‘2’ at (1) [-Winteger-division]
intdiv.f90:2:11:

2 | if (8 < (20/9)) stop 8
  |   1
Warning: Integer division truncated to constant ‘2’ at (1) [-Winteger-division]

Diagnostic is given only twice for if/then/endif form:
if (8 < (20/9)) then ; endif

[Bug fortran/108349] New: LTO mismatch for __builtin_realloc between glibc and gfortran frontend

[rimvydas.jas at gmail dot com via Gcc-bugs]

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
  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)
  integer,intent(in) :: ids(:)
  mpi_ids=ids
 end subroutine
end module

$ cat bar.c
#include "stdlib.h"
void bar(void *ptr){ptr = realloc(ptr,6);}

$ gfortran -flto foo.f90 bar.c # no warning given
$ gfortran -flto bar.c foo.f90
: warning: type of ‘__builtin_realloc’ does not match original
declaration [-Wlto-type-mismatch]
/usr/include/stdlib.h:564:14: note: type mismatch in parameter 1
  564 | extern void *realloc (void *__ptr, size_t __size)
  |  ^
/usr/include/stdlib.h:564:14: note: ‘realloc’ was previously declared here
/usr/include/stdlib.h:564:14: note: code may be misoptimized unless
‘-fno-strict-aliasing’ is used

Why diagnostic is given depending on sources (or objects) order?

No diagnostic is provided if type arguments are swapped in
gcc/fortran/f95-lang.cc:996

[Bug fortran/107397] [10/11/12/13 Regression] ICE in gfc_arith_plus, at fortran/arith.cc:654

[rimvydas.jas at gmail dot com via Gcc-bugs]

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

[Bug fortran/107397] [10/11/12/13 Regression] ICE in gfc_arith_plus, at fortran/arith.cc:654

[rimvydas.jas at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107397

Rimvydas (RJ)  changed:

   What|Removed |Added

 CC||rimvydas.jas at gmail dot com

--- Comment #9 from Rimvydas (RJ)  ---
Newly added testcase has few typos in dg-error directives and results in
testsuite failures (fixes are trivial):

Running target unix
FAIL: gfortran.dg/pr107397.f90   -O   (test for errors, line 7)
FAIL: gfortran.dg/pr107397.f90   -O  (test for excess errors)

[Bug fortran/81615] save-temps and gfortran produces *.f90 files instead of *.i or *i90 files

[rimvydas.jas at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81615

Rimvydas (RJ)  changed:

   What|Removed |Added

 CC||rimvydas.jas at gmail dot com

--- Comment #16 from Rimvydas (RJ)  ---
Created attachment 54063
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54063=edit
rename intermediate extensions to .fi or .fii

Emitting intermediate files using plain foo.f90 form is a very annoying issue
when trying to modernize archaic codebases to be used in current projects and
it really helps when intermediate files could be saved without disturbing used
native build system habitat.  Consider the following:
$ cat bar.F
       SUBROUTINEABINIT PART 2( ARGU
     x                          MENT)
       E N D S   U   B   R   O   U   T   I   N  E
$ gfortran --save-temps -c bar.F
$ gfortran -c bar.s
$ gfortran -c bar.f90
bar.F:1:8:

    1 |        SUBROUTINEABINIT PART 2( ARGU
      |        1
Error: Unclassifiable statement at (1)

This shows that intermediate Fortran source produced cannot be used again
because of fixed/free form differences while assembly file is fine.  There are
N+K build system variants that do crazy and wonderful things like
filtering/substituting flags, redirecting STDERR/STDOUT for cleaner warning
messages, silently moving sources and objects with strange rules, hiding
compilation lines in python scripts, substituting symbol names in assembly
files and even substituting names in source code on the fly to solve symbol
conflicts between contrib codebases using sed(1) or heavy cpp(1).  So sometimes
it is simply easier to modify the compiler and recompile (after all it does not
take long for gcc).
Attached is a simple diff variant that uses F77/F90+ to emit .fi/.fii
intermediate source files accordingly (inspired by what ObjC/ObjC++ do with
intermediates .mi/.mii files).  Such small change really helped to
double/triple crosscheck very complicated project with mixed F77/F90 using
sometimes crazy cpp(1) macros for the "hooks".  Using .fii extension for all
sources of .F90/.F95/.F03/.F08/.Fyz seems like a logical solution.

[Bug libfortran/108056] backward compatibility issue between 11 and 12

[rimvydas.jas at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108056

Rimvydas (RJ)  changed:

   What|Removed |Added

 CC||rimvydas.jas at gmail dot com

--- Comment #4 from Rimvydas (RJ)  ---
$ gfortran11 -g -fno-backtrace pr108056.f90
$ ./a.out && echo works
works
<--copy executable to system with gcc-13 trunk-->
$ ./a.out 
Internal Error: Invalid type in descriptor
$ gdb ./a.out
(gdb) b _gfortrani_internal_error
(gdb) b ISO_Fortran_binding.c:219
(gdb) r
_gfortran_gfc_desc_to_cfi_desc(d_ptr=0x7fffe948, s=0x7fffe970) at
/gcc_trunk/libgfortran/runtime/ISO_Fortran_binding.c:219
219   internal_error (NULL, "Invalid type in descriptor");
(gdb) where
#0  _gfortran_gfc_desc_to_cfi_desc (d_ptr=0x7fffe948, s=0x7fffe970) at
/gcc_trunk/libgfortran/runtime/ISO_Fortran_binding.c:219
#1  0x524b in pub_f08ts (a=, b=) at pr108056.f90:29
#2  0x51f0 in bugsub (a=1, b=-3.08878791e-13) at pr108056.f90:35
#3  0x5313 in bug () at pr108056.f90:43
(gdb) p d->type
$1 = 11
(gdb) p type
$2 = 11 '\v'
(gdb) p *s
$3 = {base_addr = 0x7fffe9ec, offset = 0, dtype = {elem_len = 4, version =
0, rank = 0 '\000', type = 11 '\v', attribute = 2}, span = 4, dim =
0x7fffe998}
(gdb) p/d BT_ASSUMED
$4 = 11

/* NOTE: Since GCC 12, the FE generates code to do the conversion
   directly without calling this function.  */
void
gfc_desc_to_cfi_desc (CFI_cdesc_t **d_ptr, const gfc_array_void *s)
{

Looks to be backwards compatibility issue, BT_ASSUMED not handled?

[Bug libstdc++/104019] Testsuite 17_intro/headers/c++2020/stdc++_multiple_inclusion.cc failures

[rimvydas.jas at gmail dot com via Gcc-bugs]

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-extensions/-Wno-volatile/-Wno-deprecated-declarations/-Wno-pedantic"

FAIL: 17_intro/headers/c++2011/all_no_exceptions.cc (test for excess errors)
Excess errors:
/tmp/trunk/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/istream.tcc:50:
warning: this 'if' clause does not guard... [-Wmisleading-indentation]
This one is suspicious.

[Bug libstdc++/104019] Testsuite 17_intro/headers/c++2020/stdc++_multiple_inclusion.cc failures

[rimvydas.jas at gmail dot com via Gcc-bugs]

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: 17_intro/headers/c++2011/stdc++.cc (test for excess errors)
PASS: 17_intro/headers/c++2011/stdc++_multiple_inclusion.cc (test for excess
errors)
PASS: 17_intro/headers/c++2014/stdc++.cc (test for excess errors)
PASS: 17_intro/headers/c++2014/stdc++_multiple_inclusion.cc (test for excess
errors)
PASS: 17_intro/headers/c++2017/stdc++.cc (test for excess errors)
PASS: 17_intro/headers/c++2017/stdc++_multiple_inclusion.cc (test for excess
errors)

FAIL: 17_intro/headers/c++2020/stdc++.cc (test for excess errors)
FAIL: 17_intro/headers/c++2020/stdc++_multiple_inclusion.cc (test for excess
errors)
In file included from
/build/trunk/x86_64-unknown-dragonfly6.3/libstdc++-v3/include/bits/shared_ptr.h:53,
                 from
/build/trunk/x86_64-unknown-dragonfly6.3/libstdc++-v3/include/memory:77,
                 from
/build/trunk/x86_64-unknown-dragonfly6.3/libstdc++-v3/include/x86_64-unknown-dragonfly6.3/bits/stdc++.h:82,
                 from
/data/gg/libstdc++-v3/testsuite/17_intro/headers/c++2020/stdc++.cc:25:
/build/trunk/x86_64-unknown-dragonfly6.3/libstdc++-v3/include/bits/shared_ptr_base.h:
In member function 'void std::_Sp_counted_array_base<_Alloc>::_M_init(typename
std::allocator_traits<_Alloc>::value_type*, _Init)':
/build/trunk/x86_64-unknown-dragonfly6.3/libstdc++-v3/include/bits/shared_ptr_base.h:767:
warning: typedef 'using value_type = using _Up = typename
std::allocator_traits<_Alloc>::value_type' locally defined but not used
[-Wunused-local-typedefs]
/build/trunk/x86_64-unknown-dragonfly6.3/libstdc++-v3/include/bits/shared_ptr_base.h:768:
warning: typedef 'using difference_type = std::ptrdiff_t' locally defined but
not used [-Wunused-local-typedefs]
/build/trunk/x86_64-unknown-dragonfly6.3/libstdc++-v3/include/bits/shared_ptr_base.h:771:
warning: typedef 'using iterator_category = struct std::forward_iterator_tag'
locally defined but not used [-Wunused-local-typedefs]
In file included from
/build/trunk/x86_64-unknown-dragonfly6.3/libstdc++-v3/include/x86_64-unknown-dragonfly6.3/bits/stdc++.h:144:
/build/trunk/x86_64-unknown-dragonfly6.3/libstdc++-v3/include/latch: In member
function 'void std::latch::count_down(std::ptrdiff_t)':
/build/trunk/x86_64-unknown-dragonfly6.3/libstdc++-v3/include/latch:65:
warning: comparison of integer expressions of different signedness: 'const long
unsigned int' and 'std::ptrdiff_t' {aka 'long int'} [-Wsign-compare]
FAIL: 17_intro/headers/c++2020/stdc++.cc (test for excess errors)
Excess errors:
/build/trunk/x86_64-unknown-dragonfly6.3/libstdc++-v3/include/bits/shared_ptr_base.h:767:
warning: typedef 'using value_type = using _Up = typename
std::allocator_traits<_Alloc>::value_type' locally defined but not used
[-Wunused-local-typedefs]
/build/trunk/x86_64-unknown-dragonfly6.3/libstdc++-v3/include/bits/shared_ptr_base.h:768:
warning: typedef 'using difference_type = std::ptrdiff_t' locally defined but
not used [-Wunused-local-typedefs]
/build/trunk/x86_64-unknown-dragonfly6.3/libstdc++-v3/include/bits/shared_ptr_base.h:771:
warning: typedef 'using iterator_category = struct std::forward_iterator_tag'
locally defined but not used [-Wunused-local-typedefs]
/build/trunk/x86_64-unknown-dragonfly6.3/libstdc++-v3/include/latch:65:
warning: comparison of integer expressions of different signedness: 'const long
unsigned int' and 'std::ptrdiff_t' {aka 'long int'} [-Wsign-compare]

The -Wunused-local-typedefs warnings seem to have been recently introduced in
g:9a0b518a82db68c5cbd9ea8ccc47c2ff45182519 commit.
Same c++2020 warnings are reproducible on GLIBC targets when running:
$ make check-target-libstdc++-v3 -k RUNTESTFLAGS="conformance.exp=stdc\+\+*.cc
--target_board=unix/-Wall/-Wsystem-headers/"

[Bug c++/104134] Bootstrap on FreeBSD files compiling gcc/cp/error.cc

[rimvydas.jas at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104134

Rimvydas (RJ)  changed:

   What|Removed |Added

 CC||rimvydas.jas at gmail dot com

--- Comment #13 from Rimvydas (RJ)  ---
Error is triggered on Linux (LFS-next testing) builds too, but only when
configured as:
../configure --enable-bootstrap --disable-nls --disable-multilib

Host compiler is GCC v12 few commits before the
g:34ba4275dcf5162efb9b634e4665734766faf4e3 (already had this warning).

Happens only during stage2 (and stage3) build, when executing:
/tmp/build/./prev-gcc/xg++ -B/tmp/build/./prev-gcc/ [...] -fno-PIE -c
-DIN_GCC_FRONTEND -g -O2 -fno-checking -gtoggle -DIN_GCC -fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common
-DHAVE_CONFIG_H -I. [...] -o cp/error.o -MT cp/error.o -MMD -MP -MF
cp/.deps/error.TPo /root/gcc_master/gcc/cp/error.cc

[Bug testsuite/104021] gcc.dg/vect/tsvc tests failures

[rimvydas.jas at gmail dot com via Gcc-bugs]

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

[Bug testsuite/104022] g++.dg/gcov/pr16855.C does not precleanup upon failures

[rimvydas.jas at gmail dot com via Gcc-bugs]

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?

[Bug testsuite/104022] New: g++.dg/gcov/pr16855.C does not precleanup upon failures

[rimvydas.jas at gmail dot com via Gcc-bugs]

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
  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 gives:

$ gmake check-gcc-c++ -k RUNTESTFLAGS="gcov.exp=pr16855*"
FAIL: g++.dg/gcov/pr16855-priority.C  -std=gnu++98  line 14: is 5:should be 1
FAIL: g++.dg/gcov/pr16855-priority.C  -std=gnu++98  line 21: is 5:should be 1
FAIL: g++.dg/gcov/pr16855-priority.C  -std=gnu++98  line 22: is #:should be
1
FAIL: g++.dg/gcov/pr16855-priority.C  -std=gnu++98  line 35: is 5:should be 1
FAIL: g++.dg/gcov/pr16855-priority.C  -std=gnu++98  line 41: is 5:should be 1
FAIL: g++.dg/gcov/pr16855-priority.C  -std=gnu++98  line 46: is 5:should be 1
FAIL: g++.dg/gcov/pr16855-priority.C  -std=gnu++98  line 51: is 5:should be 1
FAIL: g++.dg/gcov/pr16855-priority.C  -std=gnu++98  line 56: is 5:should be 1
FAIL: g++.dg/gcov/pr16855-priority.C  -std=gnu++98  line 61: is 5:should be 1
FAIL: g++.dg/gcov/pr16855-priority.C  -std=gnu++98  line 66: is 5:should be 1
FAIL: g++.dg/gcov/pr16855-priority.C  -std=gnu++98  line 71: is 5:should be 1
FAIL: g++.dg/gcov/pr16855-priority.C  -std=gnu++98  line 76: is 5:should be 1
FAIL: g++.dg/gcov/pr16855-priority.C  -std=gnu++98  gcov: 12 failures in line
counts, 0 in branch percentages, 0 in return percentages, 0 in intermediate
format
[SNIP]
FAIL: g++.dg/gcov/pr16855.C  -std=gnu++98  line 15: is 5:should be 1
FAIL: g++.dg/gcov/pr16855.C  -std=gnu++98  line 22: is 5:should be 1
FAIL: g++.dg/gcov/pr16855.C  -std=gnu++98  line 24: is #:should be 1
FAIL: g++.dg/gcov/pr16855.C  -std=gnu++98  line 38: is 5:should be 1
FAIL: g++.dg/gcov/pr16855.C  -std=gnu++98  line 44: is 5:should be 1
FAIL: g++.dg/gcov/pr16855.C  -std=gnu++98  line 49: is 5:should be 1
FAIL: g++.dg/gcov/pr16855.C  -std=gnu++98  gcov: 6 failures in line counts, 0
in branch percentages, 0 in return percentages, 0 in intermediate format
FAIL: g++.dg/gcov/pr16855.C  -std=gnu++14  line 15: is 6:should be 1
FAIL: g++.dg/gcov/pr16855.C  -std=gnu++14  line 22: is 6:should be 1
FAIL: g++.dg/gcov/pr16855.C  -std=gnu++14  line 24: is #:should be 1
FAIL: g++.dg/gcov/pr16855.C  -std=gnu++14  line 38: is 6:should be 1
FAIL: g++.dg/gcov/pr16855.C  -std=gnu++14  line 44: is 6:should be 1
FAIL: g++.dg/gcov/pr16855.C  -std=gnu++14  line 49: is 6:should be 1
FAIL: g++.dg/gcov/pr16855.C  -std=gnu++14  gcov: 6 failures in line counts, 0
in branch percentages, 0 in return percentages, 0 in intermediate format
FAIL: g++.dg/gcov/pr16855.C  -std=gnu++17  line 15: is 7:should be 1
FAIL: g++.dg/gcov/pr16855.C  -std=gnu++17  line 22: is 7:should be 1
FAIL: g++.dg/gcov/pr16855.C  -std=gnu++17  line 24: is #:should be 1
FAIL: g++.dg/gcov/pr16855.C  -std=gnu++17  line 38: is 7:should be 1
FAIL: g++.dg/gcov/pr16855.C  -std=gnu++17  line 44: is 7:should be 1
FAIL: g++.dg/gcov/pr16855.C  -std=gnu++17  line 49: is 7:should be 1
FAIL: g++.dg/gcov/pr16855.C  -std=gnu++17  gcov: 6 failures in line counts, 0
in branch percentages, 0 in return percentages, 0 in intermediate format
FAIL: g++.dg/gcov/pr16855.C  -std=gnu++2a  line 15: is 8:should be 1
FAIL: g++.dg/gcov/pr16855.C  -std=gnu++2a  line 22: is 8:should be 1
FAIL: g++.dg/gcov/pr16855.C  -std=gnu++2a  line 24: is #:should be 1
FAIL: g++.dg/gcov/pr16855.C  -std=gnu++2a  line 38: is 8:should be 1
FAIL: g++.dg/gcov/pr16855.C  -std=gnu++2a  line 44: is 8:should be 1
FAIL: g++.dg/gcov/pr16855.C  -std=gnu++2a  line 49: is 8:should be 1
FAIL: g++.dg/gcov/pr16855.C  -std=gnu++2a  gcov: 6 failures in line counts, 0
in branch percentages, 0 in return percentages, 0 in intermediate format

=== g++ Summary ===

# of expected passes24
# of unexpected failures80
/build/trunk/gcc/xg++  version 12.0.0 20220114 (experimental)
[remotes/origin/master -gb31cec9c22b] (GCC)

Line counts are incrementing with every check command invoke. Adding missing
xfails avoids the issue.
$ gmake check-gcc-c++ -k RUNTESTFLAGS="gcov.exp=pr16855*"
=== g++ Summary ===

# of expected passes88
# of expected failures  16

The "line 24: is #:should be 1" is a known issue on DragonFly BSD, the
dynamic linker on dso stops profiling before destructor is executed.
Alternatively adding "/* { dg-additional-options "-static" { target
*-*-dragonfly* } } */" directives to both tests allows them to pass fully.
# of expected passes104

[Bug testsuite/104021] New: gcc.dg/vect/tsvc tests failures

[rimvydas.jas at gmail dot com via Gcc-bugs]

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
  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 RUNTESTFLAGS="vect.exp=vect-tsvc*"
Running /zzz/gg/gcc/testsuite/gcc.dg/vect/vect.exp ...
FAIL: gcc.dg/vect/tsvc/vect-tsvc-s000.c (test for excess errors)
FAIL: gcc.dg/vect/tsvc/vect-tsvc-s111.c (test for excess errors)
[SNIP]
FAIL: gcc.dg/vect/tsvc/vect-tsvc-vtv.c -flto -ffat-lto-objects (test for excess
errors)
FAIL: gcc.dg/vect/tsvc/vect-tsvc-vtvtv.c -flto -ffat-lto-objects (test for
excess errors)
Excess errors:
/data/gg/gcc/testsuite/gcc.dg/vect/tsvc/tsvc.h:15:10: fatal error: malloc.h: No
such file or directory

=== gcc Summary ===

# of unexpected failures302
# of unresolved testcases   604
/build/trunk/gcc/xgcc  version 12.0.0 20220114 (experimental)
[remotes/origin/master -gb31cec9c22b] (GCC)

The DragonFly BSD does not have  nor memalign(3), but
posix_memalign(3) is available.
With patch applied:
$ gmake check-gcc-c -k RUNTESTFLAGS="vect.exp=vect-tsvc*"
=== gcc Summary ===

# of expected passes736
# of expected failures  170

[Bug libstdc++/104019] New: Testsuite 17_intro/headers/c++2020/stdc++_multiple_inclusion.cc failures

[rimvydas.jas at gmail dot com via Gcc-bugs]

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
  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++.cc (test for excess errors)
FAIL: 17_intro/headers/c++1998/stdc++_multiple_inclusion.cc (test for excess
errors)
FAIL: 17_intro/headers/c++2011/stdc++.cc (test for excess errors)
FAIL: 17_intro/headers/c++2011/stdc++_multiple_inclusion.cc (test for excess
errors)
FAIL: 17_intro/headers/c++2014/stdc++.cc (test for excess errors)
FAIL: 17_intro/headers/c++2014/stdc++_multiple_inclusion.cc (test for excess
errors)
FAIL: 17_intro/headers/c++2017/stdc++.cc (test for excess errors)
FAIL: 17_intro/headers/c++2017/stdc++_multiple_inclusion.cc (test for excess
errors)
Excess errors:
/build/trunk/x86_64-unknown-dragonfly6.3/libstdc++-v3/include/bits/shared_ptr_base.h:340:
warning: dereferencing type-punned pointer will break strict-aliasing rules
[-Wstrict-aliasing]

FAIL: 17_intro/headers/c++2020/stdc++.cc (test for excess errors)
spawn -ignore SIGHUP /build/trunk/./gcc/xg++ -shared-libgcc
-B/build/trunk/./gcc -nostdinc++
-L/build/trunk/x86_64-unknown-dragonfly6.3/libstdc++-v3/src
-L/build/trunk/x86_64-unknown-dragonfly6.3/libstdc++-v3/src/.libs
-L/build/trunk/x86_64-unknown-dragonfly6.3/libstdc++-v3/libsupc++/.libs
-B/opt/gcctrunk/x86_64-unknown-dragonfly6.3/bin/
-B/opt/gcctrunk/x86_64-unknown-dragonfly6.3/lib/ -isystem
/opt/gcctrunk/x86_64-unknown-dragonfly6.3/include -isystem
/opt/gcctrunk/x86_64-unknown-dragonfly6.3/sys-include -fchecking=1
-B/build/trunk/x86_64-unknown-dragonfly6.3/./libstdc++-v3/src/.libs
-fmessage-length=0 -fno-show-column -ffunction-sections -fdata-sections -g -O2
-DLOCALEDIR="." -nostdinc++
-I/build/trunk/x86_64-unknown-dragonfly6.3/libstdc++-v3/include/x86_64-unknown-dragonfly6.3
-I/build/trunk/x86_64-unknown-dragonfly6.3/libstdc++-v3/include
-I/data/gg/libstdc++-v3/libsupc++ -I/data/gg/libstdc++-v3/include/backward
-I/data/gg/libstdc++-v3/testsuite/util
/data/gg/libstdc++-v3/testsuite/17_intro/headers/c++2020/stdc++_multiple_inclusion.cc
-std=gnu++2a -Wall -Wsystem-headers -fdiagnostics-plain-output -S -o
stdc++_multiple_inclusion.s
In file included from
/build/trunk/x86_64-unknown-dragonfly6.3/libstdc++-v3/include/x86_64-unknown-dragonfly6.3/bits/stdc++.h:152,
 from
/data/gg/libstdc++-v3/testsuite/17_intro/headers/c++2020/stdc++_multiple_inclusion.cc:25:
/build/trunk/x86_64-unknown-dragonfly6.3/libstdc++-v3/include/version:81:
warning: "__cpp_lib_exchange_function" redefined
In file included from
/build/trunk/x86_64-unknown-dragonfly6.3/libstdc++-v3/include/x86_64-unknown-dragonfly6.3/bits/stdc++.h:94,
 from
/data/gg/libstdc++-v3/testsuite/17_intro/headers/c++2020/stdc++_multiple_inclusion.cc:25:
/build/trunk/x86_64-unknown-dragonfly6.3/libstdc++-v3/include/utility:87: note:
this is the location of the previous definition
In file included from
/build/trunk/x86_64-unknown-dragonfly6.3/libstdc++-v3/include/x86_64-unknown-dragonfly6.3/bits/stdc++.h:152,
 from
/data/gg/libstdc++-v3/testsuite/17_intro/headers/c++2020/stdc++_multiple_inclusion.cc:25:
/build/trunk/x86_64-unknown-dragonfly6.3/libstdc++-v3/include/version:83:
warning: "__cpp_lib_integer_sequence" redefined
In file included from
/build/trunk/x86_64-unknown-dragonfly6.3/libstdc++-v3/include/bits/stl_pair.h:62,
 from
/build/trunk/x86_64-unknown-dragonfly6.3/libstdc++-v3/include/bits/stl_algobase.h:64,
 from
/build/trunk/x86_64-unknown-dragonfly6.3/libstdc++-v3/include/bits/specfun.h:45,
 from
/build/trunk/x86_64-unknown-dragonfly6.3/libstdc++-v3/include/cmath:1935,
 from
/build/trunk/x86_64-unknown-dragonfly6.3/libstdc++-v3/include/x86_64-unknown-dragonfly6.3/bits/stdc++.h:41,
 from
/data/gg/libstdc++-v3/testsuite/17_intro/headers/c++2020/stdc++_multiple_inclusion.cc:25:
/build/trunk/x86_64-unknown-dragonfly6.3/libstdc++-v3/include/bits/utility.h:160:
note: this is the location of the previous definition
In file included from
/build/trunk/x86_64-unknown-dragonfly6.3/libstdc++-v3/include/x86_64-unknown-dragonfly6.3/bits/stdc++.h:152,
 from
/data/gg/libstdc++-v3/testsuite/17_intro/headers/c++2020/stdc++_multiple_inclusion.cc:25:
/build/trunk/x86_64-unknown-dragonfly6.3/libstdc++-v3/include/version:128:
warning: "__cpp_lib_as_const" redefined
In file included from
/build/trunk/x86_64-unknown-dragonfly6.3/libstdc++-v3/include/x86_64-unknown-dragonfly6.3/bits/stdc++.h:94,
 from

[Bug testsuite/102394] Gfortran testsuite could avoid target specific tests

[rimvydas.jas at gmail dot com via Gcc-bugs]

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 explicitly is more
reproducible, STOP 1, irnk == -1000:
make -j20  check-gcc-fortran RUNTESTFLAGS=dg.exp=PR93963.f90

FAIL: gfortran.dg/PR93963.f90   -O1  execution test
=== gfortran Summary ===
# of expected passes11
# of unexpected failures1

[Bug testsuite/102394] Gfortran testsuite could avoid target specific tests

[rimvydas.jas at gmail dot com via Gcc-bugs]

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 expected passes   60602
 # of expected failures 507
 # of unresolved testcases  30
-# of unsupported tests 82
+# of unsupported tests 1
 /build/trunk/gcc/gfortran  version 12.0.0 20210918 (experimental) [master
r12-3643-g18b57c1d4a8] (GCC)

UNSUPPORTED: gfortran.dg/prof/dynamic_dispatch_6.f03 -fauto-profile
that requires perf(1) and autofdo.

[Bug testsuite/102394] New: Gfortran testsuite could avoid target specific tests

[rimvydas.jas at gmail dot com via Gcc-bugs]

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
 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 skipped tests. This could avoid a need to add gcc/testsuite/gfortran.target/
in the future.  Currently there are over 80 UNSUPPORTED tests on
x86_64-unknown-linux-gnu.  Most of them are trivial to make generic, including
winapi.f90.

[Bug fortran/102145] TKR mismatches with -pedantic: -fallow-argument-mismatch does not degrade errors to warnings

[rimvydas.jas at gmail dot com via Gcc-bugs]

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 acknowledging that a user is
> throwing potential garbage at it.  [snip]
> If -pedantic or -pedantic-error 
> turns the warning back into an error, so what?  The user can
> remove the idiotic option.  Telling gfortran you want -std=legacy
> and -pedantic is an oxymoron.
Nobody would complain if compiler acted consistently and error would happen
only with -pedantic-errors.  See gcc/testsuite/gfortran.dg/hollerith8.f90 how
it is affected by -std=legacy vs -std=legacy -pedantic vs -std=f2008,
specifically the part:
 call wrtout (9hHELLO YOU, 9)
Warning: Legacy Extension: Hollerith constant at (1)
Users would be satisfied with:
Warning: Legacy extension: Invalid argument mismatch at (1).
It not so hard to acknowledge that consistency was broken and it is still
easily fixable.  There is nothing oxy about -pedantic not giving hard error
when there is -pedantic-errors for this.

> The Fortran standard for more that 55 years has said argument 
> mismatch is invalid Fortran.  In the old days, Fortran processors
> lacked the ability to diagnose the problem.  gfortran can, under
> some circumstance, diagnose the issue and should tell the user
> via an error message that the Fortran code is invalid.
Still there is no good reason to break older codebases that were accepted 3
years ago with -std=legacy or -std=gnu -fallow-argument-mismatch if -std=f2008
strictly rejects them.

> I'll also point out that you stated some projects have started to
> remove -pedantic because -fallow-argument-mismatch is throwing
> an error.  Why are these projects using -pedantic if the projects
> are not actively fixing the reported warnings.  It seems the 
> issue with -fallow-argument-mismatch is doing what it ought to
> do.  That is, encourage user to FIX THEIR INVALID FORTRAN CODE.
Previously -pedantic was used in makefile recipes to check (usually in a
separate compilation) for new warnings differences between compiler releases
about new legacy or deleted features, because it is easier way than diff
standard texts or code changes in compiler frontend.  Sadly these recipes are
being removed now.  As for fixing part, consider:
program test
 stop 1
contains
 subroutine todo1
 call mpi_send(1)
 end subroutine
 subroutine todo2
 call mpi_send(1.)
 end subroutine
end program

Hard diagnostic is now issued even for unreachable code parts and this forces
users to simply move out code parts giving hard errors to separate fortran
sources by use of wrappers without interfaces (often with real bugs when code
changes getting merged from different development branches).  Not only this
forces anyone debugging such changes to rely on LTO alone, but encourages
avoiding use of -Werror or -Werror=foo to prevent issues in future compiler
releases because compiler has growing inconsistency reputation.

> I don't care what other Fortran vendors do.  Other Fortran vendors
> have a monetary reason to bend to the purses of users.
MPI issue is not what other Fortran vendors are doing.  The given MPI
implementation (possibly MPI vendor optimized or debugging one) needs to
provide mpi.mod or mpi_f08.mod modules for every gfortran major version just to
import information about MPI interfaces.  This is why f77 mpif.h (usually
without explicit interfaces or use of "!gcc$ attributes no_arg_check :: arg")
include way is still preferred.  As for last bit, it is quite surprising and
really unnecessary in modern times.  If you need to know, then all depends on
the given friend and how consistent he/she is. :)

[Bug fortran/102145] TKR mismatches with -pedantic: -fallow-argument-mismatch does not degrade errors to warnings

[rimvydas.jas at gmail dot com via Gcc-bugs]

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 interpretation vs expectation.

> -fallow-argument-mismatch was added to allow users,
> who refuse to fix their code, the ability to downgrade the error
> to a warning.  If -pedantic changes -fallow-argument-mismatch
> back to an error, then don't use -pedantic.
The -std=legacy already implies -fallow-argument-mismatch and wrongfully warns
by default.  Consider gfortran -std=legacy -Wpedantic -Wno-error=pedantic -c.

> And, no, the code was not "carefully crafted".  Code, which exploits
> argument mismatch, has always been invalid Fortran.  It is time that
> those codes are fixed.
Until every compiler vendor agree on universal module format for things like
"USE MPI" or "USE MPI_F08", the HPC applications will continue to use F77
"mpif.h" include, unless "buffer" type would get standardized.  Many projects
already split things like:
 call mpi_foo(1, MPI_INTEGER, N); . ; call mpi_foo(1., MPI_REAL, N) into
separate compilable sources and in the end such compiler behavior change solved
nothing other than creating lots unnecessary work for users and package
maintainers for every different OS.  It will become more evident when more HPC
systems get replaced from older LTS having older versions of gfortran.

[Bug fortran/102145] TKR mismatches with -pedantic: -fallow-argument-mismatch does not degrade errors to warnings

[rimvydas.jas at gmail dot com via Gcc-bugs]

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 it an error to support *any* extension then.

> > Without going into unrelated and even mildly disheartening long paragraphs
> > without useful information, most of this started with removal of
> > -Wargument-mismatch option.
> 
> No, it started when gfortran grew the ability to diagnosis the
> the problem.  It is an error.  gfortran is telling the user
> it is an error.  
Gfortran was able to diagnose most of these before under -Wargument-mismatch.

> No, it is not.  The -fallow-argument-match option was given to
> user to allow them to compile their broken code.  It was decided
> to degrade a error into a warning with this option.  If you then
> use an option that wants to PEDANTIC with respect to the requirements
> of the Fortran 66, 77, 90, 95, 2003, 2008, and 2018 standard, then
> you're going to get an error.
Nobody said -fallow-argument-mismatch should work under say -std=f2008 (and it
is OK if it doesn't).  Users complain about -std=legacy or -std=gnu behavior
and -pedantic acting like -pedantic-errors when it shouldn't.  All this done
was force users to make haste changes to keep code compiling while disturbing
sometimes carefully crafted codes or simply splitting units into separate
fortran souces so that compiler "does not see" this information.

[Bug fortran/101918] LTO type mismatches for runtime library functions in mixed -fdefault-real-8 projects

[rimvydas.jas at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101918

Rimvydas (RJ)  changed:

   What|Removed |Added

  Attachment #51398|0   |1
is obsolete||
  Attachment #51399|0   |1
is obsolete||
  Attachment #51400|0   |1
is obsolete||
  Attachment #51401|0   |1
is obsolete||

--- Comment #26 from Rimvydas (RJ)  ---
Created attachment 51442
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51442=edit
proper patch with more fixes and tests

see short summary above the patch

[Bug fortran/102145] TKR mismatches with -pedantic: -fallow-argument-mismatch does not degrade errors to warnings

[rimvydas.jas at gmail dot com via Gcc-bugs]

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

[Bug fortran/102145] TKR mismatches with -pedantic: -fallow-argument-mismatch does not degrade errors to warnings

[rimvydas.jas at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102145

Rimvydas (RJ)  changed:

   What|Removed |Added

 CC||rimvydas.jas at gmail dot com

--- Comment #4 from Rimvydas (RJ)  ---
(In reply to ripero84 from comment #0)
> In the presence of -pedantic, -fallow-argument-mismatch fails to degrade the
> mismatch errors to warnings:
> 
> This is:
> - undocumented; and
> - unexpected, since it effectively means that by adding -pedantic to a
> compilation line that already contains -fallow-argument-mismatch, mismatch
> warnings are upgraded to errors, despite -pedantic is only supposed to issue
> warnings.

This made many projects just simply remove -pedantic[-errors] and -Werror[=foo]
from building recipes for newer gfortran versions until behavior changes.  Any
software that includes hdf.inc, netcdf.inc and especially mpif.h is simply not
suitable for checking if actually deprecated and/or deleted features are being
used in the user when code compilation aborts on first file with argument
mismatch even for -std=legacy -pedantic.  Without going into unrelated and even
mildly disheartening long paragraphs without useful information, most of this
started with removal of -Wargument-mismatch option.
While it is understandable why it was done like this from compiler developer
perspective, it is a major breakage for what user expects or expected
previously from the compiler.  The -std=legacy already implies
-fallow-argument-mismatch, so why even warn about mismatches by default?  Same
for -std=gnu -fallow-argument-mismatch, user already supplied option to
specifically enable the extension, because code needs it.  It used to be that
-pedantic (or -Wpedantic) was safe to use to check if some unintended deleted
language features are present in the codebase.  Now with -pedantic acting like
-pedantic-errors and without any support to -Wno-0 or -Wno-error=0 (yes,
anything opt==0 "enabled by default") it is very complicated.

If you have checking scripts or tools that rely on previous behavior and you
are willing to compile separate gfortran version, you could use my old WIP that
almost work as expected or at least provide a way to -Wno-error=pedantic on
these.  Helped me a lot until we phased out those tools.

[Bug fortran/101918] LTO type mismatches for runtime library functions in mixed -fdefault-real-8 projects

[rimvydas.jas at gmail dot com via Gcc-bugs]

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

[Bug fortran/101918] LTO type mismatches for runtime library functions in mixed -fdefault-real-8 projects

[rimvydas.jas at gmail dot com via Gcc-bugs]

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

[Bug fortran/101918] LTO type mismatches for runtime library functions in mixed -fdefault-real-8 projects

[rimvydas.jas at gmail dot com via Gcc-bugs]

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

[Bug fortran/101918] LTO type mismatches for runtime library functions in mixed -fdefault-real-8 projects

[rimvydas.jas at gmail dot com via Gcc-bugs]

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

[Bug fortran/101918] LTO type mismatches for runtime library functions in mixed -fdefault-real-8 projects

[rimvydas.jas at gmail dot com via Gcc-bugs]

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.off_align
== 1 vs 2.  This looks suspicious since these are in call to already type/rank
specific runtime library function _gfortran_reshape_r8().  Sadly the
lto-dump(1) tool is unable to dump type information about called functions
arguments.

Looking at gcc/fortran/intrinsic.c it is seen that -fdefault-real-*
-fdefault-integer-* options have same effect as -freal-M-real-N or
-finteger-M-integer-N options.  This does not look intentional as this breaks
use of certain (more archaic forms) intrinsics with variables and numeric
constants that have explicit kinds.

[Bug fortran/101918] LTO type mismatches for runtime library functions in mixed -fdefault-real-8 projects

[rimvydas.jas at gmail dot com via Gcc-bugs]

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 array02_real(kind=8) parm.0;
struct array01_real(kind=8) parm.1;
struct array01_real(kind=8) * D.3962;
static integer(kind=8) A.2[2] = {2, 2};
struct array01_integer(kind=8) parm.3;
struct array01_integer(kind=8) * D.3971;

parm.0.span = 8;
parm.0.dtype = {.elem_len=8, .rank=2, .type=3};
parm.0.dim[0].lbound = 1;
parm.0.dim[0].ubound = 2;
parm.0.dim[0].stride = 1;
parm.0.dim[1].lbound = 1;
parm.0.dim[1].ubound = 2;
parm.0.dim[1].stride = 2;
parm.0.data = (void *) [0];
parm.0.offset = -3;
parm.1.span = 8;
parm.1.dtype = {.elem_len=8, .rank=1, .type=3};
parm.1.dim[0].lbound = 1;
parm.1.dim[0].ubound = 4;
parm.1.dim[0].stride = 1;
parm.1.data = (void *) [0];
parm.1.offset = -1;
D.3962 = 
parm.3.span = 8;
parm.3.dtype = {.elem_len=8, .rank=1, .type=1};
parm.3.dim[0].lbound = 1;
parm.3.dim[0].ubound = 2;
parm.3.dim[0].stride = 1;
parm.3.data = (void *) [0];
parm.3.offset = -1;
D.3971 = 
_gfortran_reshape_r8 (, D.3962, D.3971, 0B, 0B);
  }
  bar ();
}


__attribute__((externally_visible))
integer(kind=4) main (integer(kind=4) argc, character(kind=1) * * argv)
{
  static integer(kind=4) options.4[7] = {2116, 4095, 0, 1, 1, 0, 31};

  _gfortran_set_args (argc, argv);
  _gfortran_set_options (7, [0]);
  foo ();
  return 0;
}

[Bug fortran/101918] LTO type mismatches for runtime library functions in mixed -fdefault-real-8 projects

[rimvydas.jas at gmail dot com via Gcc-bugs]

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 -fdefault-*
> or -freal-* family options remains to be seen.
Someone in this same PR previously recommended that only -freal-*-real-*
options should be used.  Now even those are getting flagged as being broken.

> REAL(c_float) should map to
> C's float.  Fortunately, -fdefault-real-8 does not
> promote REAL(c_float) (aka REAL(4)) to REAL(8); OTOH
> -freal-4-real-8 will do the promotion.
This is observed behavior and a main reason why -freal-*-real-* options
(including integer ones) are virtually unusable in any bigger project that
interfaces to C or even Rust modules.

> The IEEE ARITHMETIC module is partially built on-the-fly
> when compiling code with some information coming from files
> in gcc/libgfortran/ieee.  Those files are compiled when
> gfortran is built. I don't know if anyone has extensively
> tried these options with IEEE modules.
We have used IEEE_ARITHMETIC and IEEE_EXCEPTIONS modules, seem to be performing
OK, except for handling inexact exceptions, but it is a minor issue.

> COMMON, EQUIVALENCE, BOZ, external subprogram, etc are related
> because these are affected by mucking around with storage
> association and the ABI.
These are not an issue if one is using modern portable Fortran code where
system and sometimes vendor specific tuning/optimizations/hacks can be more
easily implemented in pure C using interface safety provided by ISO_C_BINDING
intrinsic module, thus keeping Fortran part of the project portable.

However, none of these actually help to get closer to the actual issue in this
PR.  There are many things that could go wrong in the world, but this PR is
about trying to get the bottom of this single issue.

The -ftree-dump-original from Comment #8 in bar.f90.005t.original:
__attribute__((fn spec (". ")))
void bar ()
{
  static real(kind=8) b[4] = {[0 ... 3]=1.0e+0};
  real(kind=8) h[4];

  {
struct array02_real(kind=8) parm.0;
struct array01_real(kind=8) parm.1;
struct array01_real(kind=8) * D.3962;
static integer(kind=8) A.2[2] = {2, 2};
struct array01_integer(kind=8) parm.3;
struct array01_integer(kind=8) * D.3971;

parm.0.span = 8;
parm.0.dtype = {.elem_len=8, .rank=2, .type=3};
parm.0.dim[0].lbound = 1;
parm.0.dim[0].ubound = 2;
parm.0.dim[0].stride = 1;
parm.0.dim[1].lbound = 1;
parm.0.dim[1].ubound = 2;
parm.0.dim[1].stride = 2;
parm.0.data = (void *) [0];
parm.0.offset = -3;
parm.1.span = 8;
parm.1.dtype = {.elem_len=8, .rank=1, .type=3};
parm.1.dim[0].lbound = 1;
parm.1.dim[0].ubound = 4;
parm.1.dim[0].stride = 1;
parm.1.data = (void *) [0];
parm.1.offset = -1;
D.3962 = 
parm.3.span = 8;
parm.3.dtype = {.elem_len=8, .rank=1, .type=1};
parm.3.dim[0].lbound = 1;
parm.3.dim[0].ubound = 2;
parm.3.dim[0].stride = 1;
parm.3.data = (void *) [0];
parm.3.offset = -1;
D.3971 = 
_gfortran_reshape_r8 (, D.3962, D.3971, 0B, 0B);
  }
}

The tree dump for foo.f90 is identical + call to bar() and main() ofc.  The
most puzzling bit is why LTO sees a different information for
_gfortran_reshape_r8() runtime intrinsic function?

[Bug fortran/101918] LTO type mismatches for runtime library functions in mixed -fdefault-real-8 projects

[rimvydas.jas at gmail dot com via Gcc-bugs]

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 are re-discovering.
> The words of caution for -freal-* and family of options also
> applies to the -fdefault-* options.  I suspect much of work
> done on the intrinsics modules is done independently and
> obliviously to these options.
Statement like this implies that gfortran does *not* properly support variables
using explicit kinds like selected_real_kind(13,300) or real(kind=8) or
real(kind=16) or ISO_C_BINDING ones other than default plain REAL.  From
-ftree-dump-original dumps it is seen that even plain REAL or DOUBLE PRECISION
are assigned REAL(KIND=N) for all types, like
static real(kind=8) b[4] = {[0 ... 3]=1.0e+0};

> COMMON, EQUIVALENCE, and BOZ are not legacy features.
> These are full fledged features of modern Fortran. 
Some people still prefer to use Hollerith constants, implicit types, statement
functions, arithmetic if's, shared do terminations, fixed source form, even
PAUSE and there is nothing wrong with it.  Still, these are not related to this
PR.

> The original problem is simply another manifestation of 
> why these options should be avoided, if not removed from
> gfortran.  In your original example, you have changed the
> ABI between foo.o and bar.o, which now confuses lto.
ABI in this case can not be broken because no data is exchange between foo()
and bar(), nor libgfortran.so.5.0.0 is being recompiled.  Only thing that might
affect the runtime is:
  static integer(kind=4) options.4[7] = {2116, 4095, 0, 1, 1, 0, 31};
  _gfortran_set_options (7, [0]);
and based on
https://gcc.gnu.org/onlinedocs/gfortran/_005fgfortran_005fset_005foptions.html
these should not influence how runtime library should handle default
integer/real/logical/character types without explicit kind.

Again question is what is getting broken and what is the scope of this?  Is it
limited to LTO compilation only?  Any help to understand the actual problem
would very likely lead to a simple one line fix in the source code.

[Bug fortran/101918] LTO type mismatches for runtime library functions in mixed -fdefault-real-8 projects

[rimvydas.jas at gmail dot com via Gcc-bugs]

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, EQUIVALENCE, maybe the TRANSFER
> intrinsic, BOZ conversion, calling external routines, etc.
Actually the
https://gcc.gnu.org/onlinedocs/gfortran/Fortran-Dialect-Options.html and
gfortran.1 manpage list this definition for -freal-*-real-* options, while:

-fdefault-real-8
Set the default real type to an 8 byte wide type. This option also affects
the kind of non-double real constants like 1.0. This option promotes the
default width of DOUBLE PRECISION and double real constants like 1.d0 to 16
bytes if possible. If -fdefault-double-8 is given along with fdefault-real-8,
DOUBLE PRECISION and double real constants are not promoted. Unlike
-freal-4-real-8, fdefault-real-8 does not promote variables with explicit kind
declarations.

> And, no, I'm not wasting my time contriving examples to prove
> that these options should be avoided.
Fair enough, but these Fortran legacy features like COMMON, EQUIVALENCE, BOZ
and calling external user routines without interface have nothing in common
with original PR report or more trivial _gfortran_reshape_r8 example in Comment
#8

I tried to get more information with lto-dump(1) tool, however
lto-dump -dump-body=foo foo.o
lto-dump -dump-body=bar bar.o
outputs do not indicate any tree differences either.  Is there a way to get
more LTO information to understand the issue at hand?

[Bug fortran/101918] LTO type mismatches for runtime library functions in mixed -fdefault-real-8 projects

[rimvydas.jas at gmail dot com via Gcc-bugs]

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 chancing numerical precision issues.
$ cat foo.f90 
program foo
   implicit none
   real(kind=4) :: a, b
   real :: x, y
   x = 1.
   y = 3.14159
   a = 1._4
   b = 3.14159_4
   print *, a / b
   print *, x/ y
end program foo
$ gfortran foo.f90 && ./a.out
  0.318310142
  0.318310142
$ gfortran foo.f90 -fdefault-real-8 && ./a.out
  0.318310142
  0.31831015504887655 
$ gfortran foo.f90 -freal-4-real-8 && ./a.out
  0.31831015504887655 
  0.31831015504887655

Looks pretty consistent for me if proper types are used to match the kinds used
in constants like 3.14159_4. The same would apply for plain DOUBLE PRECISION
and 3.14159D numerical constants. Is this the only catch for -fdefault-* family
of options?

> You need to use -fdefault-real-8 -fdefault-double-8 when compiling both
> files.  How is the 2nd invocation of gfortran to know that your first
> invocation of gfortran used incompatible options?
Incompatible how?  As far as executable linking is concerned the final link
could be performed by plain ld(1) on both foo.o and bar.o (or foo.o libbar.a)
provided that user links in the libgfortran.so too.  The -fdump-tree-original
-c outputs on both sources indicate that dump trees are identical (including
calls to _gfortran_reshape_r8() in libgfortran.so).

[Bug fortran/97571] long parsing phase for simple array constructor

[rimvydas.jas at gmail dot com via Gcc-bugs]

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.  From user perspective
user requested to create consecutive integer array constructor that should be
called to ACOS() intrinsic and not vise versa create real (possibly double or
even quad precision) array constructor containing acos() values.

Something like a runtime limit variable to prevent compile time hogging would
be acceptable provided if user would get warned under say -Wsurprising that
intrinsic evaluation on array constructor was skipped due to excessive use of
MPFR library function calls or was considered not beneficial.

[Bug fortran/101918] LTO type mismatches for runtime library functions in mixed -fdefault-real-8 projects

[rimvydas.jas at gmail dot com via Gcc-bugs]

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 providing correct information
for LTO.  Somewhat more trivial example for different intrinsic runtime call:
$ cat foo.f90
program foo
implicit none
double precision, dimension (1:4) :: b = 1
double precision, dimension (1:2, 1:2) :: h
h = reshape( b, (/ 2, 2 /))
call bar()
end program

$ cat bar.f90
subroutine bar
implicit none
real, dimension (1:4) :: b = 1
real, dimension (1:2, 1:2) :: h
h = reshape( b, (/ 2, 2 /))
end subroutine

$ gfortran -Wall -Wextra -flto -fdefault-real-8 -fdefault-double-8 -c bar.f90
$ gfortran -Wall -Wextra -flto foo.f90 bar.o
bar.f90:5:27: warning: type of '_gfortran_reshape_r8' does not match original
declaration [-Wlto-type-mismatch]
5 | h = reshape( b, (/ 2, 2 /))
  |   ^
foo.f90:5:27: note: '_gfortran_reshape_r8' was previously declared here
5 | h = reshape( b, (/ 2, 2 /))
  |   ^
foo.f90:5:27: note: code may be misoptimized unless '-fno-strict-aliasing' is
used

The -fdump-tree-original match exactly and both report: _gfortran_reshape_r8/4
function body not available.  The same happens even when bar.f90 is using
real(c_double) from ISO_C_BINDINGS.
Maybe it would be possible to provide interfaces for calls to intrinsics in the
runtime library, even if that would require use of "!GCC$ ATTRIBUTES
NO_ARG_CHECK :: VARIABLE" like it is already done for "USE MPI" bindings?

[Bug fortran/101918] LTO type mismatches for runtime library functions in mixed -fdefault-real-8 projects

[rimvydas.jas at gmail dot com via Gcc-bugs]

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: promoting only default types
where no explicit kind is provided.  Often coupling interfaces between
different climate modeling software libraries are already using explicit kinds
for correct data passing, while types in intermediate internal computations are
left at compiler default types.  This allows the use of narrower types for
operational climate simulations (when quicker model execution time is
necessary) and use wider types for more precise calculations in offline runs,
without extensive use of C preprocessor that is not a standard Fortran feature.
 Note, there is no option to silence warnings about numerical constants (not
using explicit kinds) when constants can be converted without loss of precision
including for powers of 2 in floating types.

It is puzzling that some of gfortran developers often are advocating the use of
options like -freal-4-real-8 or -freal-8-real-4 instead.  These options are as
useful as -finteger-4-integer-8 for anything but simple single source programs.
 Consider the following with -O0 -finteger-4-integer-8 -fdump-tree-original -c:

program foo
integer :: t
call bar(t)
end program

subroutine bar(n) ! C callable
use iso_c_binding,only: c_int
implicit none
character(len=4) :: mode = 'test'
integer(kind=c_int) :: n
n = -floor(6.)
call c_func(n, mode)
end subroutine

might as well promote integer types in main() too.  It is nearly impossible to
use -freal-* -finteger-* options when code needs to link with libraries like
BLAS/LAPACK or optimized variants like OpenBLAS, especially when these options
prevents *any* use of the given type kind and even break fundamental feature
like ISO_C_BINDING without giving some indication that frontend is doing this. 
In many bigger climate packages it is common to use different kinds for IO,
computation, coupling etc:
ones based on defaults for given architecture/ABI:
  logical
  integer
  real
  double precision
  quad precision (when it becomes part of the standard, since hardware is
becoming available for scientific computations)
ones based on minimal precision required:
  real, parameter :: jprf = selected_real_kind(6,37)
  real, parameter :: jprd = selected_real_kind(13,300)
  integer, parameter :: jpii = selected_int_kind(9)
  integer, parameter :: jpil = selected_int_kind(13)
ones based on Fortran internal storage (a.k.a "works on compilers tested"):
  real, parameter :: jpr4 = 4
  real, parameter :: jpr8 = 8
  integer, parameter :: jpi4 = 4
  integer, parameter :: jpi8 = 8
ones based on C/Fortran bindings through iso_c_binding
  integer(kind=c_int)
  integer(kind=c_long)
  real(kind=c_float)
  real(kind=c_double)

Users usually do not expect numeric kinds to match between all these groups for
all architectures/ABIs, but it is expected that the compiler should convert
variable types (including numeric constants) with different kinds or give a
diagnostic when it is not possible, otherwise whole use of different explicit
kinds is redundant if those internally map to the same kind that can be
overridden silently by a single option.  If it is indeed just an LTO
implementation limitation, then users need to be careful when checking what
dynamic or static different climate libraries (possibly using -flto) are being
used when linking final executables.
Even added diagnostics when the user makes a typo like:
  integer(kind=selected_real_kind(13,300)) :: i
would help a lot.  At least some common examples of what to look for in
documentation about "gfortran -fdefault-real-8 -fdefault-double-8" limitations
(if these options are really that broken) would be very appreciated by the
software porters :)

[Bug fortran/102079] Misleading -Wlto-type-mismatch warning on wrong float type to C function

[rimvydas.jas at gmail dot com via Gcc-bugs]

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 reference. Could gfortran
frontend emit to use 'size_t' or even __SIZE_TYPE__ internal type so to avoid
inclusion of  ?

[Bug fortran/102079] New: Misleading -Wlto-type-mismatch warning on wrong float type to C function

[rimvydas.jas at gmail dot com via Gcc-bugs]

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: 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 cdfile_len) { };

$ cat foo.f90
program test
call foo('start','loo',13.)
end program

subroutine foo(cdname,cdfile,pkey)
implicit none
character(len=*) :: cdname,cdfile
real :: pkey
call bar(cdname,pkey,cdfile)
end subroutine

$ gcc -flto -c bar.c
$ gfortran -Wall -Wextra -flto foo.f90 bar.o
foo.f90:9:28: warning: type of 'bar' does not match original declaration
[-Wlto-type-mismatch]
9 | call bar(cdname,pkey,cdfile)
  |^
bar.c:2:6: note: type mismatch in parameter 4
2 | void bar_ (char *cdname, /*float*/ double *pkey, char *cdfile, size_t
cdname_len, size_t cdfile_len) { };
  |  ^
bar.c:2:6: note: type 'size_t' should match type 'long int'
bar.c:2:6: note: 'bar_' was previously declared here
bar.c:2:6: note: code may be misoptimized unless '-fno-strict-aliasing' is used

Actual hard error is typo in bar.c for "float *pkey" 2nd argument and not a
first hidden argument for first character array length.

[Bug fortran/101919] New: Inconsistent -Wstringop-overread warning with -flto

[rimvydas.jas at gmail dot com via Gcc-bugs]

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
 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 -Wextra gl_test.f90
$ gfortran -Wall -Wextra -flto gl_test.f90
gl_test.f90: In function 'foo':
gl_test.f90:4:52: warning: '__builtin_memmove' reading 100 bytes from a region
of size 88 [-Wstringop-overread]
4 | if (c(1:12) == 'Accumulated ') c = c(13:len_trim(c))
  |^
gl_test.f90:3:23: note: at offset 12 into source object 'c' of size 100
3 | character(len=100) :: c =' '
  |   ^

[Bug fortran/101918] LTO type mismatches for runtime library functions in mixed -fdefault-real-8 projects

[rimvydas.jas at gmail dot com via Gcc-bugs]

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 parameter 1
  550 | extern void *realloc (void *__ptr, size_t __size)
  |  ^
/opt/nwp/gcc11/include/stdlib.h:550:14: note: 'realloc' was previously declared
here
/opt/nwp/gcc11/include/stdlib.h:550:14: note: code may be misoptimized unless
'-fno-strict-aliasing' is used

that seem to go away if arguments are swapped at gcc/fortran/f95-lang.c:982
  ftype = build_function_type_list (pvoid_type_node,
size_type_node, pvoid_type_node, <---
NULL_TREE);

So far could not extract reasonably sized test-case.

[Bug fortran/101918] New: LTO type mismatches for runtime library functions in mixed -fdefault-real-8 projects

[rimvydas.jas at gmail dot com via Gcc-bugs]

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
  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(2)
double precision :: ad(2,3), vd(2)
ai = 0
ai(1,1:2) = (/ 1, 2 /)
ar = ai
ad = ai
mask = ai .ne. 0
vi = PACK(ai, ai .gt. 0, vector=(/1,2,3,4,5/))
vd = PACK(ad, mask)
vr = PACK(ar, mask)
call foo()
end program

$ cat foo.f90
subroutine foo
implicit none
real :: ar(2,3), v(1)
ar = 0.
ar(1,1) = 1.
v = PACK(ar, ar > 0.)
end subroutine

$ gfortran -Wall -Wextra -flto -fdefault-real-8 -c foo.f90
$ gfortran -flto -Wall -Wextra foo.o bar.f90
bar.f90:14:19: warning: type of '_gfortran_pack' does not match original
declaration [-Wlto-type-mismatch]
   14 | vr = PACK(ar, mask)
  |   ^
bar.f90:13:19: warning: type of '_gfortran_pack' does not match original
declaration [-Wlto-type-mismatch]
   13 | vd = PACK(ad, mask)
  |   ^
bar.f90:12:46: warning: type of '_gfortran_pack' does not match original
declaration [-Wlto-type-mismatch]
   12 | vi = PACK(ai, ai .gt. 0, vector=(/1,2,3,4,5/))
  |  ^
foo.f90:6:21: note: '_gfortran_pack' was previously declared here
6 | v = PACK(ar, ar > 0.)
  | ^
foo.f90:6:21: note: code may be misoptimized unless '-fno-strict-aliasing' is
used

In medium sized mixed C/Fortran codebase there are more instances for:
 _gfortran_matmul_r8
 _gfortran_pack
 _gfortran_reshape_r8
 _gfortran_set_convert
 _gfortran_shape_4
 _gfortran_unpack0
 _gfortran_unpack1

Does this mean -flto cannot be used in mixed -fdefault-real-8 and usual modes?

[Bug fortran/101917] New: Spurious -Wstringop-overread with -flto when passing zero sized arrays

[rimvydas.jas at gmail dot com via Gcc-bugs]

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: 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(idummy, 0)
end program

$ gcc -flto -c bar.c
$ gfortran -Wall -Wextra -flto -c foo.f90
$ gfortran -Wall -Wextra -flto foo.o bar.o
foo.f90: In function 'foo':
foo.f90:3:19: warning: 'bar_' reading 4 bytes from a region of size 0
[-Wstringop-overread]
3 | call bar(idummy, 0)
  |   ^
foo.f90:3:19: note: referencing argument 1 of type 'const int *'
bar.c:1:6: note: in a call to function 'bar_'
1 | void bar_(const int flag[], const int *num) { }
  |  ^

[Bug libstdc++/99270] New: Testsuite 27_io/headers/cstdio/types_std.cc failure on DragonFly

[rimvydas.jas at gmail dot com via Gcc-bugs]

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
  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)

spawn -ignore SIGHUP /build/trunk/./gcc/xg++ -shared-libgcc
-B/build/trunk/./gcc -nostdinc++
-L/build/trunk/x86_64-unknown-dragonfly5.9/libstdc++-v3/src
-L/build/trunk/x86_64-unknown-dragonfly5.9/libstdc++-v3/src/.libs
-L/build/trunk/x86_64-unknown-dragonfly5.9/libstdc++-v3/libsupc++/.libs
-B/opt/gcc11f/x86_64-unknown-dragonfly5.9/bin/
-B/opt/gcc11f/x86_64-unknown-dragonfly5.9/lib/ -isystem
/opt/gcc11f/x86_64-unknown-dragonfly5.9/include -isystem
/opt/gcc11f/x86_64-unknown-dragonfly5.9/sys-include -fchecking=1
-B/build/trunk/x86_64-unknown-dragonfly5.9/./libstdc++-v3/src/.libs
-fmessage-length=0 -fno-show-column -ffunction-sections -fdata-sections -g -O2
-DLOCALEDIR="." -nostdinc++
-I/build/trunk/x86_64-unknown-dragonfly5.9/libstdc++-v3/include/x86_64-unknown-dragonfly5.9
-I/build/trunk/x86_64-unknown-dragonfly5.9/libstdc++-v3/include
-I/data/gg/libstdc++-v3/libsupc++ -I/data/gg/libstdc++-v3/include/backward
-I/data/gg/libstdc++-v3/testsuite/util
/data/gg/libstdc++-v3/testsuite/27_io/headers/cstdio/types_std.cc
-fdiagnostics-plain-output -S -o types_std.s
/data/gg/libstdc++-v3/testsuite/27_io/headers/cstdio/types_std.cc:25: error:
aggregate 'FILE gnu::f' has incomplete type and cannot be defined
compiler exited with status 1
FAIL: 27_io/headers/cstdio/types_std.cc (test for excess errors)
Excess errors:
/data/gg/libstdc++-v3/testsuite/27_io/headers/cstdio/types_std.cc:25: error:
aggregate 'FILE gnu::f' has incomplete type and cannot be defined

extra_tool_flags are:

On DragonFly the FILE type is declared as opaque struct and its internals are
never exposed on purpose:
typedef struct __FILE FILE;

Even cppreference mentions that std::FILE may be semantically non-copyable.
Could "std::FILE f;" test be excluded by #if !defined(__DragonFly__) or simply
changed to a more usual use case of "std::FILE *fp;" ?

[Bug libstdc++/99265] New: Testsuite 17_intro/headers/c++2020/stdc++.cc failure after std::chrono changes

[rimvydas.jas at gmail dot com via Gcc-bugs]

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: 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 excess errors)
FAIL: 17_intro/headers/c++2020/stdc++_multiple_inclusion.cc (test for excess
errors)

In file included from
/build/trunk/x86_64-unknown-dragonfly5.9/libstdc++-v3/include/x86_64-unknown-dragonfly5.9/bits/stdc++.h:101,^M
 from
/data/gg/libstdc++-v3/testsuite/17_intro/headers/c++2020/stdc++.cc:25:^M
/build/trunk/x86_64-unknown-dragonfly5.9/libstdc++-v3/include/chrono: In static
member function 'static constexpr std::chrono::year_month_day
std::chrono::year_month_day::_S_from_days(const days&)':^M
/build/trunk/x86_64-unknown-dragonfly5.9/libstdc++-v3/include/chrono:2484:
warning: narrowing conversion of '(((long int)__y1) + ((long int)((unsigned
int)__z2)))' from 'long int' to 'int' [-Wnarrowing]^M
trunk/x86_64-unknown-dragonfly5.9/libstdc++-v3/include/chrono:2484: warning:
narrowing conversion of '(((long int)__y1) + ((long int)((unsigned int)__z2)))'
from 'long int' to 'int' [-Wnarrowing]

extra_tool_flags are:
 -std=gnu++2a -Wall -Wsystem-headers

[Bug bootstrap/98318] [11 Regression] libcody breaks DragonFly bootstrap

[rimvydas.jas at gmail dot com via Gcc-bugs]

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 will remain possible without need for
a functional (non blocked/filtered) network stack?

Also, two possible typos in:
gcc/cp/mapper-client.cc#L252 should be "= -1"? This avoids timeouts in the
testsuite.
int fd = 01;
#if CODY_NETWORKING
fd = Cody::OpenInet6 (, name.c_str (), port);
#endif

gcc/cp/module.cc:#if NETWORKING vs
c++tools/server.cc:#ifdef NETWORKING

[Bug bootstrap/98318] libcody breaks DragonFly bootstrap

[rimvydas.jas at gmail dot com via Gcc-bugs]

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/libbacktrace'
gmake[2]: Entering directory '/zzz/build/trunk/libcpp'
gmake[2]: Nothing to be done for 'check'.
gmake[2]: Leaving directory '/zzz/build/trunk/libcpp'
gmake[2]: Entering directory '/zzz/build/trunk/libcody'
No ZSH, maybe flakey
echo '# Automatically generated by Make' >tests/cody.defs
echo 'testdir=/data/gg/libcody/tests' >>tests/cody.defs
echo 'timelimit=60' >>tests/cody.defs
echo 'memlimit=1' >>tests/cody.defs
echo 'cpulimit=60' >>tests/cody.defs
echo 'filelimit=1' >>tests/cody.defs
echo 'SHELL=/bin/sh' >>tests/cody.defs
/zzz/build/trunk/./prev-gcc/xg++ -B/zzz/build/trunk/./prev-gcc/
-B/opt/gcc11f/x86_64-unknown-dragonfly5.9/bin/ -nostdinc++
-B/zzz/build/trunk/prev-x86_64-unknown-dragonfly5.9/libstdc++-v3/src/.libs
-B/zzz/build/trunk/prev-x86_64-unknown-dragonfly5.9/libstdc++-v3/libsupc++/.libs

-I/zzz/build/trunk/prev-x86_64-unknown-dragonfly5.9/libstdc++-v3/include/x86_64-unknown-dragonfly5.9
 -I/zzz/build/trunk/prev-x86_64-unknown-dragonfly5.9/libstdc++-v3/include 
-I/data/gg/libstdc++-v3/libsupc++
-L/zzz/build/trunk/prev-x86_64-unknown-dragonfly5.9/libstdc++-v3/src/.libs
-L/zzz/build/trunk/prev-x86_64-unknown-dragonfly5.9/libstdc++-v3/libsupc++/.libs
-g -O2 -include config.h -I/data/gg/libcody
-I/zzz/build/trunk/prev-x86_64-unknown-dragonfly5.9/libstdc++-v3/include/x86_64-unknown-dragonfly5.9
-I/zzz/build/trunk/prev-x86_64-unknown-dragonfly5.9/libstdc++-v3/include
-I/data/gg/libstdc++-v3/libsupc++ \
  -MMD -MP -MF tests/01-serialize/connect.d -c -o tests/01-serialize/connect.o
/data/gg/libcody/tests/01-serialize/connect.cc
/zzz/build/trunk/./prev-gcc/xg++ -B/zzz/build/trunk/./prev-gcc/
-B/opt/gcc11f/x86_64-unknown-dragonfly5.9/bin/ -nostdinc++
-B/zzz/build/trunk/prev-x86_64-unknown-dragonfly5.9/libstdc++-v3/src/.libs
-B/zzz/build/trunk/prev-x86_64-unknown-dragonfly5.9/libstdc++-v3/libsupc++/.libs

-I/zzz/build/trunk/prev-x86_64-unknown-dragonfly5.9/libstdc++-v3/include/x86_64-unknown-dragonfly5.9
 -I/zzz/build/trunk/prev-x86_64-unknown-dragonfly5.9/libstdc++-v3/include 
-I/data/gg/libstdc++-v3/libsupc++
-L/zzz/build/trunk/prev-x86_64-unknown-dragonfly5.9/libstdc++-v3/src/.libs
-L/zzz/build/trunk/prev-x86_64-unknown-dragonfly5.9/libstdc++-v3/libsupc++/.libs
-static-libstdc++ -static-libgcc  tests/01-serialize/connect.o -lcody  -o
tests/01-serialize/connect
/usr/libexec/binutils234/elf/ld.gold: error: cannot find -lcody
/data/gg/libcody/cody.hh:288: error: undefined reference to
'Cody::Packet::Destroy()'
/data/gg/libcody/tests/01-serialize/connect.cc:24: error: undefined reference
to 'Cody::Client::~Client()

The make -k check issue in libcody directory is reproducible on Linux box too.

[Bug bootstrap/98318] libcody breaks DragonFly bootstrap

[rimvydas.jas at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98318

Rimvydas (RJ)  changed:

   What|Removed |Added

 Resolution|INVALID |FIXED

--- Comment #10 from Rimvydas (RJ)  ---
With commits:
g:6d972f5183d8d476cfb008b85e224aa9b90e628d
g:31705b068fa5d6cbd04aa4ac5f5275bad37d
g:cf22f78ff6ead2b1f022d7e7367daedf459aa355
gcc11 now can successfully bootstrap on DragonFly BSD.
Marking as fixed.

[Bug libstdc++/98344] New: Testsuite 17_intro/headers/c++2020/stdc++.cc failure

[rimvydas.jas at gmail dot com via Gcc-bugs]

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
 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++_multiple_inclusion.cc (test for excess
errors)

spawn -ignore SIGHUP /build/trunk/./gcc/xg++ -shared-libgcc
-B/build/trunk/./gcc -nostdinc++
-L/build/trunk/x86_64-unknown-dragonfly5.9/libstdc++-v3/src
-L/build/trunk/x86_64-unknown-dragonfly5.9/libstdc++-v3/src/.libs
-L/build/trunk/x86_64-unknown-dragonfly5.9/libstdc++-v3/libsupc++/.libs
-B/opt/gcc11f/x86_64-unknown-dragonfly5.9/bin/
-B/opt/gcc11f/x86_64-unknown-dragonfly5.9/lib/ -isystem
/opt/gcc11f/x86_64-unknown-dragonfly5.9/include -isystem
/opt/gcc11f/x86_64-unknown-dragonfly5.9/sys-include -fchecking=1
-B/build/trunk/x86_64-unknown-dragonfly5.9/./libstdc++-v3/src/.libs
-fmessage-length=0 -fno-show-column -ffunction-sections -fdata-sections -g -O2
-DLOCALEDIR="." -nostdinc++
-I/build/trunk/x86_64-unknown-dragonfly5.9/libstdc++-v3/include/x86_64-unknown-dragonfly5.9
-I/build/trunk/x86_64-unknown-dragonfly5.9/libstdc++-v3/include
-I/data/gg/libstdc++-v3/libsupc++ -I/data/gg/libstdc++-v3/include/backward
-I/data/gg/libstdc++-v3/testsuite/util
/data/gg/libstdc++-v3/testsuite/17_intro/headers/c++2020/stdc++.cc -std=gnu++2a
-Wall -Wsystem-headers -fdiagnostics-plain-output -S -o stdc++.s
In file included from
/build/trunk/x86_64-unknown-dragonfly5.9/libstdc++-v3/include/semaphore:35,
 from
/build/trunk/x86_64-unknown-dragonfly5.9/libstdc++-v3/include/stop_token:37,
 from
/build/trunk/x86_64-unknown-dragonfly5.9/libstdc++-v3/include/condition_variable:47,
 from
/build/trunk/x86_64-unknown-dragonfly5.9/libstdc++-v3/include/x86_64-unknown-dragonfly5.9/bits/stdc++.h:103,
 from
/data/gg/libstdc++-v3/testsuite/17_intro/headers/c++2020/stdc++.cc:25:
/build/trunk/x86_64-unknown-dragonfly5.9/libstdc++-v3/include/bits/semaphore_base.h:279:
warning: extra tokens at end of #ifdef directive
FAIL: 17_intro/headers/c++2020/stdc++.cc (test for excess errors)
Excess errors:
/build/trunk/x86_64-unknown-dragonfly5.9/libstdc++-v3/include/bits/semaphore_base.h:279:
warning: extra tokens at end of #ifdef directive

extra_tool_flags are:
 -std=gnu++2a -Wall -Wsystem-headers

The libstdc++-v3/include/bits/semaphore_base.h:279 looks to be a typo:
// Note: the _GLIBCXX_REQUIRE_POSIX_SEMAPHORE macro can be used to force the
// use of Posix semaphores (sem_t). Doing so however, alters the ABI.
#ifdef _GLIBCXX_HAVE_LINUX_FUTEX && !_GLIBCXX_REQUIRE_POSIX_SEMAPHORE
  // Use futex if available and didn't force use of POSIX

[Bug bootstrap/98318] libcody breaks DragonFly bootstrap

[rimvydas.jas at gmail dot com via Gcc-bugs]

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-threadsafe-statics -fno-exceptions -fno-rtti
-fdebug-prefix-map=/data/gg/libcody/= -W -Wall -include config.h
-I/data/gg/libcody \
  -MMD -MP -MF netclient.d -c -o netclient.o /data/gg/libcody/netclient.cc
/data/gg/libcody/netclient.cc: In function 'int Cody::OpenInet6(const char**,
const char*, int)':
/data/gg/libcody/netclient.cc:114:3: error: 'sockaddr_in6' was not declared in
this scope
   sockaddr_in6 addr;
   ^~~~
/data/gg/libcody/netclient.cc:114:3: note: suggested alternative: 'sockaddr_un'
   sockaddr_in6 addr;
   ^~~~
   sockaddr_un
/data/gg/libcody/netclient.cc:115:12: error: 'addr' was not declared in this
scope
   memset (, 0, sizeof (addr));

[Bug bootstrap/98318] libcody breaks DragonFly bootstrap

[rimvydas.jas at gmail dot com via Gcc-bugs]

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?

[Bug bootstrap/98318] New: libcody breaks DragonFly bootstrap

[rimvydas.jas at gmail dot com via Gcc-bugs]

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
  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 BSD:

gmake[3]: Leaving directory '/build/trunk/libcpp'
Configuring stage 1 in ./libcody
configure: creating cache ./config.cache
checking build system type... x86_64-unknown-dragonfly5.9
checking host system type... x86_64-unknown-dragonfly5.9
checking number of CPUs... unknown
checking maintainer-mode...
checking whether the C++ compiler works... yes
checking for C++ compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether g++ -std=c++11 accepts -g... yes
checking whether g++ -std=c++11 is for C++11... yes
checking adding -Wl,--no-undefined to linker... ok
/data/gg/libcody/configure: CONFIG_FILES+= ./Makesub: not found
/data/gg/libcody/configure: CONFIG_FILES+= ./tests/Makesub: not found
checking bugurl... github.com/urnathan/libcody
checking checking... yes
checking exceptions... no
...
ar rc libcommon.a diagnostic.o diagnostic-color.o diagnostic-show-locus.o
diagnostic-format-json.o json.o edit-context.o pretty-print.o intl.o sbitmap.o
vec.o input.o version.o hash-table.o ggc-none.o memory-block.o selftest.o
selftest-diagnostic.o sort.o
ranlib  libcommon.a
gmake[3]: *** No rule to make target '../libcody/libcody.a', needed by
'cc1-checksum.c'.  Stop.
gmake[3]: Leaving directory '/build/trunk/gcc'
gmake[2]: *** [Makefile:4781: all-stage1-gcc] Error 2
gmake[2]: Leaving directory '/build/trunk'
gmake[1]: *** [Makefile:27488: stage1-bubble] Error 2
gmake[1]: Leaving directory '/build/trunk'
gmake: *** [Makefile:1004: all] Error 2

The /bin/sh is almquist shell and do not take VAR+= style appends.

Another issue missing  for sockaddr_in6 in netclient.cc and
netserver.cc.

Attached diff allows to bootstrap gcc11 once again.

[Bug c++/96504] [coroutines] test failures with glibc-2.32

[rimvydas.jas at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96504

Rimvydas (RJ)  changed:

   What|Removed |Added

 CC||rimvydas.jas at gmail dot com

--- Comment #1 from Rimvydas (RJ)  ---
With glibc-2.32 and gcc version 11.0.0 20201029 (experimental) [master revision
c6bfc4eb3:6ba997f13:0162d00d12be24ee3f02ce876adafeaa91c6f7f9] (GCC) I only see

FAIL: g++.dg/coroutines/torture/pr95519-05-gro.C execution test
FAIL: g++.dg/coroutines/torture/pr95519-05-gro.C   -O0  execution test
FAIL: g++.dg/coroutines/torture/pr95519-05-gro.C   -O1  execution test
FAIL: g++.dg/coroutines/torture/pr95519-05-gro.C   -O2  execution test
FAIL: g++.dg/coroutines/torture/pr95519-05-gro.C   -O3 -g  execution test
FAIL: g++.dg/coroutines/torture/pr95519-05-gro.C   -Os  execution test
FAIL: g++.dg/coroutines/torture/pr95519-05-gro.C   -O2 -flto
-fno-use-linker-plugin -flto-partition=none  execution test
FAIL: g++.dg/coroutines/torture/pr95519-05-gro.C   -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects  execution test

[Bug libstdc++/70940] pmr::resource_adaptor requires optional allocator requirements and incorrectly aligns returned pointers.

[rimvydas.jas at gmail dot com via Gcc-bugs]

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_resource/new_delete_resource.cc:62:
error: 'uintptr_t' in namespace 'std' does not name a type
compiler exited with status 1
FAIL: experimental/memory_resource/new_delete_resource.cc (test for excess
errors)
Excess errors:
/z/gg/libstdc++-v3/testsuite/experimental/memory_resource/new_delete_resource.cc:62:
error: 'uintptr_t' in namespace 'std' does not name a type

UNRESOLVED: experimental/memory_resource/new_delete_resource.cc compilation
failed to produce executable

[Bug rtl-optimization/97554] ICE: during RTL pass: cprop /segfault in sbitmap

[rimvydas.jas at gmail dot com via Gcc-bugs]

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 10.3 release?

[Bug fortran/97571] New: long parsing phase for simple array constructor

[rimvydas.jas at gmail dot com via Gcc-bugs]

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: 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
subroutine bpr_init
implicit none
integer :: i
real :: tacos2( 0:35250)
tacos2 = acos( (/ (i, i=64000,99250) /) / 10.0)
end subroutine bpr_init

$ gfortran -O1 -Wall -Wextra -c init.f90 -ftime-report
init.f90:4:24:

4 | real :: tacos2( 0:35250)
  |1
Warning: Array 'tacos2' at (1) is larger than limit set by
'-fmax-stack-var-size=', moved from stack to static storage. This makes the
procedure unsafe when called recursively, or concurrently from multiple
threads. Consider using '-frecursive', or increase the '-fmax-stack-var-size='
limit, or change the code to use an ALLOCATABLE array. [-Wsurprising]

Time variable   usr   sys  wall
  GGC
 phase parsing  :1923.03 (100%)   0.21 (100%)1923.67 (100%)
 7500k ( 97%)
 phase opt and generate :   0.01 (  0%)   0.00 (  0%)   0.02 (  0%)
   69k (  1%)
 callgraph functions expansion  :   0.01 (  0%)   0.00 (  0%)   0.01 (  0%)
   48k (  1%)
 parser (global):1923.02 (100%)   0.21 (100%)1923.67 (100%)
 7500k ( 97%)
 tree gimplify  :   0.00 (  0%)   0.00 (  0%)   0.01 (  0%)
 1752  (  0%)
 tree STMT verifier :   0.00 (  0%)   0.00 (  0%)   0.01 (  0%)
0  (  0%)
 varconst   :   0.01 (  0%)   0.00 (  0%)   0.00 (  0%)
0  (  0%)
 initialize rtl :   0.01 (  0%)   0.00 (  0%)   0.00 (  0%)
   12k (  0%)
 TOTAL  :1923.04  0.21   1923.69   
 7756k
Extra diagnostic checks enabled; compiler may run slowly.
Configure with --enable-checking=release to disable checks.

Configuring with checking=release or different -O levels have no impact on time
taken, previous gfortran 10.2 did not exhibit such long parsing times.

[Bug libstdc++/96817] __cxa_guard_acquire unsafe against dynamically loaded pthread

[rimvydas.jas at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96817

Rimvydas (RJ)  changed:

   What|Removed |Added

 CC||rimvydas.jas at gmail dot com

--- Comment #18 from Rimvydas (RJ)  ---
When libstdc++ is configured with --disable-linux-futex for use in valgrind,
the g:e6923541fae5081b646f240d54de2a32e17a0382 on x86_64-linux gives

WARNING: 18_support/96817.cc execution test program timed out.
FAIL: 18_support/96817.cc execution test

Also, disabling linux-futex fails libstdc++-abi/abi_check for symbols?
std::__atomic_futex_unsigned_base::_M_futex_wait_until()
std::__atomic_futex_unsigned_base::_M_futex_notify_all()

[Bug libgomp/88707] Random failures of libgomp.c++/task-reduction-(8|10|11|13).C

[rimvydas.jas at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88707

Rimvydas (RJ)  changed:

   What|Removed |Added

 CC||rimvydas.jas at gmail dot com

--- Comment #5 from Rimvydas (RJ)  ---
Reproducible on x86_64-linux when configured with --disable-linux-futex

WARNING: program timed out.
FAIL: libgomp.c++/task-reduction-10.C execution test
WARNING: program timed out.
FAIL: libgomp.c++/task-reduction-11.C execution test
WARNING: program timed out.
FAIL: libgomp.c++/task-reduction-13.C execution test
WARNING: program timed out.
FAIL: libgomp.c++/task-reduction-8.C execution test

Disabling use of futexes is needed to avoid lots of false positives in valgrind
for obvious reasons.

[Bug rtl-optimization/97554] New: ICE: during RTL pass: cprop /segfault in sbitmap

[rimvydas.jas at gmail dot com via Gcc-bugs]

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: 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 autogenerated verifier of observations, that
is now failing to compile after including newest meteorological data.
gcc version 11.0.0 20201023 (experimental) linux x86_64

$ gcc -Wall -Wextra -O2 -c nwp_test.c
during RTL pass: cprop
nwp_test.c: In function 'obs_verif_body_entry':
nwp_test.c:14043:13: internal compiler error: Segmentation fault
14043 |   return RC;}
  | ^
0xdef4ef crash_signal
/z/gg/gcc/toplev.c:330
0x7fffed80b81f ???
/z/glibc-2.32/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x1909e50 sbitmap_vector_alloc(unsigned int, unsigned int)
/z/gg/gcc/sbitmap.c:171
0x1719767 alloc_cprop_mem
/z/gg/gcc/cprop.c:557
0x1719767 one_cprop_pass
/z/gg/gcc/cprop.c:1817
0x1719767 execute_rtl_cprop
/z/gg/gcc/cprop.c:1931
0x1719767 execute
/z/gg/gcc/cprop.c:1969
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Works with: 4.8.5 5.3 6.2 7.3 8.2
Fails with: 9.3  10.2 11-master

$ gcc-9 -O2 -c nwp_test.c
gcc-9: fatal error: Killed signal terminated program cc1

Able to compile with (time and memory usage is an issue):
gcc-9 -O2 -fno-ree
gcc-10 -O2 -fno-gcse -fno-ree
gcc-11 -O2 -fno-gcse