[Bug c/103104] New: missing warning about superfluous forward declaration -Wsuperfluous-forward-declaration

[aldot at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 103104
   Summary: missing warning about superfluous forward declaration
-Wsuperfluous-forward-declaration
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aldot at gcc dot gnu.org
  Target Milestone: ---

It would be nice to have a -Wextra to warn about superfluous forward
declarations.

Random example from gcc/incpath.c
static void add_env_var_paths (const char *, incpath_kind);
static void add_standard_paths (const char *, const char *, const char *, int);
static void free_path (struct cpp_dir *, int);
static void merge_include_chains (const char *, cpp_reader *, int);
static void add_sysroot_to_chain (const char *, int);
static struct cpp_dir *remove_duplicates (cpp_reader *, struct cpp_dir *,
  struct cpp_dir *, struct cpp_dir *,
--
static void
free_path (struct cpp_dir *path, int reason)
--
static void
add_env_var_paths (const char *env_var, incpath_kind chain)
--
static void
add_standard_paths (const char *sysroot, const char *iprefix,
--
static struct cpp_dir *
remove_duplicates (cpp_reader *pfile, struct cpp_dir *head,
--
...
All definitions are in topologically correct order, i.e. defined before used,
each and every forward declaration is redundant and error prone.

Maybe there is an existing plugin to that effect?

[Bug fortran/103112] New: ICE in gfc_get_descriptor_field for gfortran.dg/coarray_alloc_comp_4.f08 caf single

[aldot at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 103112
   Summary: ICE in gfc_get_descriptor_field for
gfortran.dg/coarray_alloc_comp_4.f08 caf single
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aldot at gcc dot gnu.org
  Target Milestone: ---

gfortran.dg/coarray_alloc_comp_4.f08 compiles fine with -fcoarray=lib
but ICEs with -fcoarray=single in pristine trunk


$ gfortran -O2 -fcoarray=single -g -g3 -ggdb3 -fdump-tree-original
-fdump-tree-optimized coarray_alloc_comp_4.f08 -c; echo $?
coarray_alloc_comp_4.f08:38:22:

   38 |   deallocate(obj%link)
  |  1
internal compiler error: in gfc_get_descriptor_field, at
fortran/trans-array.c:245
0x67b8e8 gfc_get_descriptor_field
../../../src/gcc-12.orig/gcc/fortran/trans-array.c:245
0x97d53a gfc_conv_descriptor_data_get(tree_node*)
../../../src/gcc-12.orig/gcc/fortran/trans-array.c:264
0x97aa64 gfc_deallocate_with_status(tree_node*, tree_node*, tree_node*,
tree_node*, tree_node*, bool, gfc_expr*, int, tree_node*, tree_node*)
../../../src/gcc-12.orig/gcc/fortran/trans.c:1427
0x98e539 structure_alloc_comps
../../../src/gcc-12.orig/gcc/fortran/trans-array.c:9291
0x9904da gfc_deallocate_alloc_comp(gfc_symbol*, tree_node*, int, int)
../../../src/gcc-12.orig/gcc/fortran/trans-array.c:10081
0x97b196 gfc_deallocate_scalar_with_status(tree_node*, tree_node*, tree_node*,
bool, gfc_expr*, gfc_typespec, bool)
../../../src/gcc-12.orig/gcc/fortran/trans.c:1646
0xa1189d gfc_trans_deallocate(gfc_code*)
../../../src/gcc-12.orig/gcc/fortran/trans-stmt.c:7380
0x977597 trans_code
../../../src/gcc-12.orig/gcc/fortran/trans.c:2092
0x9a9c2f gfc_generate_function_code(gfc_namespace*)
../../../src/gcc-12.orig/gcc/fortran/trans-decl.c:7666
0x9220ee translate_all_program_units
../../../src/gcc-12.orig/gcc/fortran/parse.c:6629
0x9220ee gfc_parse_file()
../../../src/gcc-12.orig/gcc/fortran/parse.c:6916
0x97434f gfc_be_parse_file
../../../src/gcc-12.orig/gcc/fortran/f95-lang.c:216
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
1
$ gfortran --version
GNU Fortran (GCC) 12.0.0 20211105 (experimental) [master r12-4967-gbcf3728abe8]

[Bug middle-end/103102] [12 Regression] pr81175.f fails since r12-4946-ga79fe53d6ce6074d083e925b6b19773e45817405

[aldot at gcc dot gnu.org via Gcc-bugs]

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

Bernhard Reutner-Fischer  changed:

   What|Removed |Added

 CC||aldot at gcc dot gnu.org

--- Comment #1 from Bernhard Reutner-Fischer  ---
maybe related:
polyhedron capacita with pristine r12-4967 on 86_64 skylake

$ gfortran -march=native -ffast-math -ftree-vectorize -funroll-loops -O3
capacita.f90 -o capacita.exe
during RTL pass: expand
capacita.f90:609:21:

  609 |   Grid(i,j)=0
  | ^
internal compiler error: in maybe_gen_insn, at optabs.c:7871
0x72b7a6 maybe_gen_insn(insn_code, unsigned int, expand_operand*)
../../../src/gcc-12.orig/gcc/optabs.c:7871
0xe1d738 maybe_expand_insn(insn_code, unsigned int, expand_operand*)
../../../src/gcc-12.orig/gcc/optabs.c:7915
0xe1d738 expand_insn(insn_code, unsigned int, expand_operand*)
../../../src/gcc-12.orig/gcc/optabs.c:7946
0xcb3bcf expand_partial_store_optab_fn
../../../src/gcc-12.orig/gcc/internal-fn.c:2773
0xa6f487 expand_call_stmt
../../../src/gcc-12.orig/gcc/cfgexpand.c:2749
0xa6f487 expand_gimple_stmt_1
../../../src/gcc-12.orig/gcc/cfgexpand.c:3876
0xa6f487 expand_gimple_stmt
../../../src/gcc-12.orig/gcc/cfgexpand.c:4040
0xa7536f expand_gimple_basic_block
../../../src/gcc-12.orig/gcc/cfgexpand.c:6085
0xa76df6 execute
../../../src/gcc-12.orig/gcc/cfgexpand.c:6811
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug middle-end/103102] [12 Regression] pr81175.f fails since r12-4946-ga79fe53d6ce6074d083e925b6b19773e45817405

[aldot at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Bernhard Reutner-Fischer  ---
gfortran.dg/pr101267.f90 ICEs similar to gfortran.dg/pr81175.f

[Bug fortran/68800] Fortran FE produces many memory leaks

[aldot at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from Bernhard Reutner-Fischer  ---
at least a few down with r12-5073:

 == LEAK SUMMARY:
-==definitely lost: 9,471 bytes in 14 blocks
-==indirectly lost: 18,267 bytes in 364 blocks
+==definitely lost: 6,472 bytes in 8 blocks
+==indirectly lost: 15,683 bytes in 346 blocks
 ==  possibly lost: 0 bytes in 0 blocks
 ==still reachable: 1,442,175 bytes in 1,244 blocks
 == suppressed: 0 bytes in 0 blocks
 == 
 == For lists of detected and suppressed errors, rerun with: -s
-== ERROR SUMMARY: 13 errors from 13 contexts (suppressed: 0 from 0)
+== ERROR SUMMARY: 7 errors from 7 contexts (suppressed: 0 from 0)

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

[aldot at gcc dot gnu.org via Gcc-bugs]

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

Bernhard Reutner-Fischer  changed:

   What|Removed |Added

 CC||aldot at gcc dot gnu.org

--- Comment #3 from Bernhard Reutner-Fischer  ---
if c does not contain trailing blank characters then
len_trim(c) can return up to 100, yes.
So the warning would be correct in this case as it would read beyond c (at
least in C).

Coding error?

if (c(1:12) == 'Accumulated ') c = c(13:len_trim(c))
should maybe subtract about 13 from the upper bound of the right hand side?

[Bug fortran/102043] Wrong array types used for negative stride accesses

[aldot at gcc dot gnu.org via Gcc-bugs]

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

Bernhard Reutner-Fischer  changed:

   What|Removed |Added

 CC||aldot at gcc dot gnu.org

--- Comment #9 from Bernhard Reutner-Fischer  ---
yes i've been looking into that too and it seems rather involved to switch the
addressing away from array_ref.

[Bug fortran/83646] (PDT) Use statement with PDTs excludes the specific instances.

[aldot at gcc dot gnu.org via Gcc-bugs]

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

Bernhard Reutner-Fischer  changed:

   What|Removed |Added

 CC||aldot at gcc dot gnu.org

--- Comment #2 from Bernhard Reutner-Fischer  ---
Seems to compile with 10.3.0 and 11.2.0

$ gfortran-10 -c /tmp/pr83646.f90 -o /tmp/pr.o -W -Wall -Wextra
-fdump-tree-original && gfortran-10 --version | head -n1
/tmp/pr.f90:10:20:

   10 |subroutine sub( a )
  |1
Warning: Unused dummy argument ‘a’ at (1) [-Wunused-dummy-argument]
GNU Fortran (Debian 10.3.0-11) 10.3.0

[Bug fortran/102043] Wrong array types used for negative stride accesses

[aldot at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #16 from Bernhard Reutner-Fischer  ---
In addition to comment #1
here's an excerpt of an existing test with just one dimension:

$ cat f_pr86389.f90
! PR 19239.  Check for various kinds of vector subscript.  In this test,
! all vector subscripts are indexing single-dimensional arrays.
! { dg-do run }
program main
  implicit none
  integer, parameter :: n = 10
  integer :: i
  integer, dimension (n) :: a, b, idx, id

  idx = (/ 3, 1, 5, 2, 4, 10, 8, 7, 6, 9 /)
  id = (/ (i, i = 1, n) /)
  b = (/ (i * 100, i = 1, n) /)

  a = 0
  a (idx (10:6:-2)) = b (idx (1:7:3))
write(*,*) "#i   =", id
write(*,*) "idx  =", idx
write(*,*) "now a=", a
write(*,*) "now b=", b
write(*,*) "a idx(10:6:-2)=", idx (10:6:-2)
write(*,*) "b idx(1:7:3)  =", idx (1:7:3)
  call test (idx (10:6:-2), idx (1:7:3))

contains
  subroutine test (lhs, rhs)
integer, dimension (:) :: lhs, rhs
integer :: i
!!!if (size (lhs, 1) .ne. size (rhs, 1)) STOP 11
!do i = 1, size (lhs, 1)
do i = 1, 3 ! spare us the code for size(), fixed const
  if (a (lhs (i)) .ne. b (rhs (i))) STOP 12
end do
!a = 0
  end subroutine test
end program main

[Bug fortran/102043] Wrong array types used for negative stride accesses

[aldot at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #17 from Bernhard Reutner-Fischer  ---
Do we want to address arrays always at position 0 (maybe to help graphite ?) or
would it be sufficient to just not dereference the array "before" the first
position like Mikael suggests in comment #14?

gfc_conv_expr_descriptor has this
  if (se->data_not_needed)
gfc_conv_descriptor_data_set (&loop.pre, parm,
  gfc_index_zero_node);
  else
/* Point the data pointer at the 1st element in the section.  */
gfc_get_dataptr_offset (&loop.pre, parm, desc, base,
subref_array_target, expr);

  gfc_conv_descriptor_offset_set (&loop.pre, parm, offset);

where base is (for "section"-addressing) 9 for the testcase in comment #16 as
can be seen in Richard's initial report.

[Bug fortran/47720] problems with makefile dependency generation using -M

[aldot at gcc dot gnu.org via Gcc-bugs]

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

Bernhard Reutner-Fischer  changed:

   What|Removed |Added

 CC||aldot at gcc dot gnu.org

--- Comment #9 from Bernhard Reutner-Fischer  ---
To avoid the duplicate module names, we would have to remember which modules we
emitted already (or maybe deps_add_ not when opening and reading the module but
way later).

But, as said, is this really a problem?

As to the fact that -M... requires cpp, we could enable cpp when seeing -M,
yes.
I'm not sure about the implications this has on the source we're reading
though. Maybe none.

[Bug middle-end/102519] [12 Regression] VRP Jump threader memory explosion

[aldot at gcc dot gnu.org via Gcc-bugs]

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

Bernhard Reutner-Fischer  changed:

   What|Removed |Added

 CC||aldot at gcc dot gnu.org

--- Comment #19 from Bernhard Reutner-Fischer  ---
so as asked in
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/580485.html what about
dominance_info?

[Bug fortran/102973] New: possible inconsistency in procptr_assignment handling when matching ASSOCIATE

[aldot at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 102973
   Summary: possible inconsistency in procptr_assignment handling
when matching ASSOCIATE
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aldot at gcc dot gnu.org
  Target Milestone: ---

As noted in https://gcc.gnu.org/pipermail/fortran/2018-September/050809.html

i spotted one
(pre-existing) possible inconsistency that i did overlook back then:

gfc_match_associate () reads
...
  if (gfc_match (" %e", &newAssoc->target) != MATCH_YES)
{
  /* Have another go, allowing for procedure pointer selectors.  */
  gfc_matching_procptr_assignment = 1;
  if (gfc_match (" %e", &newAssoc->target) != MATCH_YES)
{
  gfc_error ("Invalid association target at %C");
  goto assocListError;
}
  gfc_matching_procptr_assignment = 0;
}

i.e. we retry a match, but in the second attempt we turn on procptr
assignment matching and if that works, we turn procptr assignment
matching off again.
But if we fail that retry, we forget to turn it off again.
I suppose we should:

$ svn diff -x -p gcc/fortran/match.c
Index: gcc/fortran/match.c
===
--- gcc/fortran/match.c (revision 264040)
+++ gcc/fortran/match.c (working copy)
@@ -1898,13 +1898,16 @@ gfc_match_associate (void)
   if (gfc_match (" %e", &newAssoc->target) != MATCH_YES)
  {
/* Have another go, allowing for procedure pointer selectors.  */
+   match m;
+
gfc_matching_procptr_assignment = 1;
-   if (gfc_match (" %e", &newAssoc->target) != MATCH_YES)
+   m = gfc_match (" %e", &newAssoc->target);
+   gfc_matching_procptr_assignment = 0;
+   if (m != MATCH_YES)
  {
gfc_error ("Invalid association target at %C");
goto assocListError;
  }
-   gfc_matching_procptr_assignment = 0;
  }
   newAssoc->where = gfc_current_locus;


Untested. Maybe someone wants to give it a whirl...
If it wrecks havoc then leaving it set deliberately deserves at least a
comment.

PS: It would be nice to get rid of gfc_matching_procptr_assignment,
gfc_matching_ptr_assignment, gfc_matching_prefix, FWIW.

[Bug fortran/103001] New: missing simplify of (CAF) get_team

[aldot at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 103001
   Summary: missing simplify of (CAF) get_team
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aldot at gcc dot gnu.org
  Target Milestone: ---

As noted here:
https://gcc.gnu.org/pipermail/fortran/2021-October/056793.html
---8<---
- delete unused gfc_simplify_get_team or wire it up in intrinsics,
  get_team handling (instead of the NULL..)

Anyone who does coarrays might want to fill in the missing get_team()
simplify and add an appropriate test. 
---8<---
E.g. omp team is named properly.
It would have been nice if caf would have used a _caf part for it's functions
internally throughout too.

[Bug fortran/98426] find_symbol in module.c traverses O(N) part of a search tree

[aldot at gcc dot gnu.org via Gcc-bugs]

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

Bernhard Reutner-Fischer  changed:

   What|Removed |Added

 CC||aldot at gcc dot gnu.org

--- Comment #4 from Bernhard Reutner-Fischer  ---
I'm thinking about switching all these symbol lookups/symtree traversals (i.e.
the whole fortran frontend) to pointer comparison which should _greatly_
speedup any symbol lookup, fyi.

[Bug fortran/99884] Double spaces in warning message

[aldot at gcc dot gnu.org via Gcc-bugs]

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

Bernhard Reutner-Fischer  changed:

   What|Removed |Added

   Keywords||patch
 Ever confirmed|0   |1
   Last reconfirmed||2021-10-31
 CC||aldot at gcc dot gnu.org
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2021-October
   ||/582974.html
 Status|UNCONFIRMED |NEW

--- Comment #1 from Bernhard Reutner-Fischer  ---
Confirmed.

[Bug fortran/100972] Missing error with "implicit none (external)"

[aldot at gcc dot gnu.org via Gcc-bugs]

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

Bernhard Reutner-Fischer  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Keywords||patch
   Last reconfirmed||2021-10-31
 CC||aldot at gcc dot gnu.org
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2021-October
   ||/582979.html

--- Comment #2 from Bernhard Reutner-Fischer  ---
Confirmed

[Bug fortran/100991] [OpenMP] firstprivate for optional arguments is mishandled

[aldot at gcc dot gnu.org via Gcc-bugs]

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

Bernhard Reutner-Fischer  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||aldot at gcc dot gnu.org
   Last reconfirmed||2021-10-31

[Bug fortran/101337] gfortran doesn't diagnose all operands with constraint violations

[aldot at gcc dot gnu.org via Gcc-bugs]

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

Bernhard Reutner-Fischer  changed:

   What|Removed |Added

   Keywords||patch
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2021-October
   ||/582983.html
 CC||aldot at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2021-10-31

--- Comment #2 from Bernhard Reutner-Fischer  ---
confirmed

[Bug fortran/100972] Missing error with "implicit none (external)"

[aldot at gcc dot gnu.org via Gcc-bugs]

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

Bernhard Reutner-Fischer  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
  Known to work||12.1.0

--- Comment #4 from Bernhard Reutner-Fischer  ---
Fixed for 12.1.0 onwards.

[Bug bootstrap/107739] New: --enable-languages= duplicates yield odd error

[aldot at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 107739
   Summary: --enable-languages= duplicates yield odd error
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aldot at gcc dot gnu.org
  Target Milestone: ---

Mere cosmetics, but the error is contradicting it's own hint in a confusing
way.

$ ../../src/gcc-13.mine/configure --enable-languages=c++,lto,lto
configure: error: 
The following requested languages could not be built: lto
Supported languages are: c,c,c++,fortran,go,lto,objc,obj-c++

or other dups like
$ ../../src/gcc-13.mine/configure --enable-languages=c++,c++,lto
configure: error: 
The following requested languages could not be built: c++
Supported languages are: c,c,c++,fortran,go,lto,objc,obj-c++

I'm not sure why duplicates are not ignored silently.

[Bug middle-end/107743] New: expmed: extract_bit_field_1: maybe-uninitialized warning

[aldot at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 107743
   Summary: expmed: extract_bit_field_1: maybe-uninitialized
warning
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aldot at gcc dot gnu.org
  Target Milestone: ---

current trunk around r13-4134

/scratch/obj.x86_64/gcc-13.mine/./prev-gcc/xg++
-B/scratch/obj.x86_64/gcc-13.mine/./prev-gcc/
-B/opt/x86_64/gcc-13.mine/x86_64-pc-linux-gnu/bin/ -nostdinc++
-B/scratch/obj.x86_64/gcc-13.mine/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-B/scratch/obj.x86_64/gcc-13.mine/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/scratch/obj.x86_64/gcc-13.mine/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu

-I/scratch/obj.x86_64/gcc-13.mine/prev-x86_64-pc-linux-gnu/libstdc++-v3/include
 -I/scratch/src/gcc-13.mine/libstdc++-v3/libsupc++
-L/scratch/obj.x86_64/gcc-13.mine/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L/scratch/obj.x86_64/gcc-13.mine/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
 -fno-PIE -c   -O2 -g3 -ggdb3 -gdwarf-5 -pipe -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 -fno-common  -DHAVE_CONFIG_H -I. -I.
-I../../../src/gcc-13.mine/gcc -I../../../src/gcc-13.mine/gcc/.
-I../../../src/gcc-13.mine/gcc/../include
-I../../../src/gcc-13.mine/gcc/../libcpp/include
-I../../../src/gcc-13.mine/gcc/../libcody 
-I../../../src/gcc-13.mine/gcc/../libdecnumber
-I../../../src/gcc-13.mine/gcc/../libdecnumber/bid -I../libdecnumber
-I../../../src/gcc-13.mine/gcc/../libbacktrace   -o expmed.o -MT expmed.o -MMD
-MP -MF ./.deps/expmed.TPo ../../../src/gcc-13.mine/gcc/expmed.cc

../../../src/gcc-13.mine/gcc/expmed.cc: In function 'rtx_def*
extract_bit_field_1(rtx, poly_uint64, poly_uint64, int, rtx, machine_mode,
machine_mode, bool, bool, rtx_def**)':
../../../src/gcc-13.mine/gcc/expmed.cc:1838:45: warning: '*(unsigned
int*)((char*)&imode + offsetof(scalar_int_mode, scalar_int_mode::m_mode))' may
be used uninitialized [-Wmaybe-uninitialized]
 1838 |   rtx sub = extract_bit_field_as_subreg (mode1, op0, imode,
  | ^~~
 1839 |  bitsize, bitnum);
  |  
../../../src/gcc-13.mine/gcc/expmed.cc:1798:19: note: '*(unsigned
int*)((char*)&imode + offsetof(scalar_int_mode, scalar_int_mode::m_mode))' was
declared here
 1798 |   scalar_int_mode imode;
  |   ^

[Bug middle-end/107743] expmed: extract_bit_field_1: maybe-uninitialized warning

[aldot at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Bernhard Reutner-Fischer  ---
--disable-werror --enable-checking=yes --enable-debug --enable-multilib
--disable-libstdcxx-pch --enable-bootstrap

[Bug c++/105656] New: remove BROKEN_VALUE_INITIALIZATION workaround

[aldot at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 105656
   Summary: remove BROKEN_VALUE_INITIALIZATION workaround
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aldot at gcc dot gnu.org
  Target Milestone: ---

BROKEN_VALUE_INITIALIZATION was added for PR89494, a bootstrap failure of
gcc-10 with a gcc-4.2 system compiler.

Since at least gcc-13, maybe gcc-12, we require a stage1 c++ compiler >=
gcc-4.8, hence the BROKEN_VALUE_INITIALIZATION seems to be dead code for it
guards against GCC_VERSION > 0 && GCC_VERSION < 4004

[Bug c++/105656] remove BROKEN_VALUE_INITIALIZATION workaround

[aldot at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Bernhard Reutner-Fischer  ---
Yes, i've seen your bigger patch to remove all of these version conditionals.

But please note that this BROKEN_VALUE_INITIALIZATION was explicitly taylored
to catch aforementioned GCC versions, and really GCC itself. It even explicitly
excluded clang as that announces itself as 4.2.

/* GCC older than 4.4 have broken C++ value initialization handling, see
   PR11309, PR30111, PR33916, PR82939 and PR84405 for more details.  */
#if GCC_VERSION > 0 && GCC_VERSION < 4004 && !defined(__clang__)
# define BROKEN_VALUE_INITIALIZATION
#endif

Your big patch could maybe be refined a bit. For example, i think newer GCC do
recognize popcount patterns, so i assume that the conditions in
bitmap_count_bits_in_word should no longer be needed; Also, i assume that any
compiler that is used to build gcc will have to implement builtins like
__builtin_popcount{,l,ll} anyway. Same should hold true for ctz, clz, ffs.
I'm not sure what the standard has to say about unknown pragmas, but i'd assume
that a compiler should silently ignore "#pragma GCC whatever" if it doesn't
feel responsible for that identifier. If so, then using the GCC pragmas
unconditionally should be fine.
Maybe we should have an ATTRIBUTE_FORMAT macro to handle all of these
occurrences.
All in all, i think now that we require c++, and c++11 even, most of these
guards should probably key off plain __GNUC__, as Richard said.

[Bug other/111460] New: -fdiagnostics-generate-patch=/out.diff to specify patch output destination file

[aldot at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 111460
   Summary: -fdiagnostics-generate-patch=/out.diff to specify
patch output destination file
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aldot at gcc dot gnu.org
CC: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

It would be handy if one could specify a file where the patch(es) generated by
-fdiagnostics-generate-patch could be written/appended to.

[Bug fortran/103931] Type name "c_ptr" is ambiguous when iso_c_binding is imported both directly and indirectly

[aldot at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #10 from Bernhard Reutner-Fischer  ---
(In reply to anlauf from comment #9)
> The reduced testcase compiles for me with today's 13-trunk, but not
> 12-branch.
> However, the full original testcase fails with varying errors depending on
> the
> gfortran version.

Does the full testcase compile on trunk, with d7caf313525a, i assume?

[Bug fortran/109003] memory leak in module loading (mio_formal_arglist)

[aldot at gcc dot gnu.org via Gcc-bugs]

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

Bernhard Reutner-Fischer  changed:

   What|Removed |Added

 CC||aldot at gcc dot gnu.org

--- Comment #1 from Bernhard Reutner-Fischer  ---
Sounds familiar, i thought i've fixed this already some time ago?

[Bug jit/66054] bootstrap comparison failure with --enable-host-shared

[aldot at gcc dot gnu.org via Gcc-bugs]

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

Bernhard Reutner-Fischer  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #4 from Bernhard Reutner-Fischer  ---
This issue was fixed some time ago, closing.

[Bug sanitizer/56781] boostrap-asan failure: fixincl fails to link (missing -lasan)

[aldot at gcc dot gnu.org via Gcc-bugs]

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

Bernhard Reutner-Fischer  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Bernhard Reutner-Fischer  ---
Fixed.

[Bug libfortran/109373] New: remove --enable-intermodule from libgfortran configure

[aldot at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 109373
   Summary: remove --enable-intermodule from libgfortran configure
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aldot at gcc dot gnu.org
  Target Milestone: ---

r0-103106-gde6ba7aee152a0 removed --enable-intermodule (in favour of LTO) but 
libgfortran still has it.

[Bug fortran/103931] Type name "c_ptr" is ambiguous when iso_c_binding is imported both directly and indirectly

[aldot at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #11 from Bernhard Reutner-Fischer  ---
(In reply to Bernhard Reutner-Fischer from comment #10)
> (In reply to anlauf from comment #9)
> > The reduced testcase compiles for me with today's 13-trunk, but not
> > 12-branch.
> > However, the full original testcase fails with varying errors depending on
> > the
> > gfortran version.
> 
> Does the full testcase compile on trunk, with d7caf313525a, i assume?

Both the original testcase as well as the reduced testcase from comment #2
compile fine for me with trunk from earlier today at r13-6974-g802ab7d0db5b5a

[Bug fortran/103931] Type name "c_ptr" is ambiguous when iso_c_binding is imported both directly and indirectly

[aldot at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #13 from Bernhard Reutner-Fischer  ---
(In reply to anlauf from comment #12)

> Consider the original testcase.  Module CModule has no public symbols.
> Technically, the "use CModule" in module DModule should not have any effect.
> (Confirmed by other brands).  However, commenting the "use CModule"
> reproduces
> the original error message.

Ok, i see. Thanks for the enlightenment :)

First and foremost, re-instating the class finalization memory leak cited in
comment #8 does not help, as expected.
At first i thought that we might look in the wrong namespace, but that does not
seem the case.

I'm testing a patch.

> 
> This PR may be a duplicate of others that describe gfortran's confusion
> when using (intrinsic) modules along a module chain like here.

There are 50 bugs with "module" in the description, i should go through them to
see if there are similar cases. Or do you by chance remember a specific one in
that area?

[Bug fortran/103931] Type name "c_ptr" is ambiguous when iso_c_binding is imported both directly and indirectly

[aldot at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #15 from Bernhard Reutner-Fischer  ---
(In reply to Bernhard Reutner-Fischer from comment #13)

> I'm testing a patch.

I have to admit that this is a mess.

It's even more frustrating now as i did some preparatory cleanup for at least
some of the inconveniences in that area a while ago but never got to apply
these. Anyway.

Not sure if the following would be correct:

Under the assumption that we have a generic "c_ptr" in a module, we know (?)
that "c_ptr" is not ambiguous.

Is that right?

>From what i see from a quick glance, we seem to write more symbols to the
module files than strictly needed, and that does not really help the case.

Short of a broader fix, a quick-hack to avoid the error about ambiguous
intrinsic built-in symbols might be to (*cough*):

--- a/gcc/fortran/module.cc
+++ b/gcc/fortran/module.cc
@@ -5320,6 +5322,11 @@ check_for_ambiguous (gfc_symtree *st, pointer_info
*info)
return false;
 }

+  /* A symbol from an intrinsic module is not ambiguous.  */
+  /* This should not be necessary, at least not in this form!  */
+  if (st_sym->from_intmod != INTMOD_NONE)
+return false;
+
   return true;
 }


This works as expected, fixes this specific PR and tests cleanly.
Should i propose this workaround as a patch or is it a bit too gross?
WDYT?

[Bug fortran/103931] Type name "c_ptr" is ambiguous when iso_c_binding is imported both directly and indirectly

[aldot at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #16 from Bernhard Reutner-Fischer  ---
> Under the assumption that we have a generic "c_ptr" in a module, we know (?) 
> that "c_ptr" is not ambiguous.
> 
> Is that right?

When we look at gmodule (when compiled when DModule has a commented-out "use
CModule"), we have:

GFORTRAN module version '15' created from pr103931.F90
(() () () () () () () () () () () () () () () () () () () () () () () ()
() () ()) // oper interfaces

() // user oper

(('c_funptr' '__iso_c_binding' 2) ('c_ptr' '__iso_c_binding' 3)) // generic
interfaces
() // blank commons, common
() // equiv
() // omp_udr
// now first symbols w/ generic interfaces, flavour PROCEDURE but not sub nor
function
(2 'C_funptr' '__iso_c_binding' '' 1 ((DERIVED UNKNOWN-INTENT
UNKNOWN-PROC UNKNOWN UNKNOWN 0 0 IS_BIND_C IS_C_INTEROP PRIVATE_COMP) (
(4 'c_address' (INTEGER 8 0 1 0 INTEGER ()) () () () (UNKNOWN-FL
UNKNOWN-INTENT UNKNOWN-PROC UNKNOWN UNKNOWN 0 0) PRIVATE ())) PRIVATE (
DERIVED 2 0 1 1 VOID ()) 0 0 () () 0 () () () 2 44 0)
3 'C_ptr' '__iso_c_binding' '' 1 ((DERIVED UNKNOWN-INTENT UNKNOWN-PROC
UNKNOWN UNKNOWN 0 0 IS_BIND_C IS_C_INTEROP PRIVATE_COMP) ((5 'c_address'
(INTEGER 8 0 1 0 INTEGER ()) () () () (UNKNOWN-FL UNKNOWN-INTENT
UNKNOWN-PROC UNKNOWN UNKNOWN 0 0) PRIVATE ())) PRIVATE (DERIVED 3 0 1 1
VOID ()) 0 0 () () 0 () () () 2 42 0)
[snip]
// second, symbols rest

So, the ambiguous error comes from seeing C_ptr with id 3, loading that. Then
we check if it _has_ the GENERIC attr set, but it has not, since (i think) this
very symbol is *used* to describe the type of the generic interface. I do not
quite see why we check_for_ambiguous for these generic interface types in the
first place, i think that they are just not ambiguous, at least as far as i can
see in the aforementioned gmodule.mod.

I'm testing a more elaborate test which keeps check_for_ambiguous in the same
spot as before, but in that check, looks if the symtree (C_ptr in this case,
number 3) is listed in the generic interfaces after the existing check that
looks if the symbol itself is GENERIC.

I did not really look at the standard, so i wonder if that makes sense to
somebody more familiar with that area?

[Bug fortran/103931] Type name "c_ptr" is ambiguous when iso_c_binding is imported both directly and indirectly

[aldot at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #17 from Bernhard Reutner-Fischer  ---
(In reply to Bernhard Reutner-Fischer from comment #16)

> I'm testing a more elaborate test which keeps check_for_ambiguous in the
> same spot as before, but in that check, looks if the symtree (C_ptr in this
> case, number 3) is listed in the generic interfaces after the existing check
> that looks if the symbol itself is GENERIC.

This highlights cases like in use_24.f90 and use_27.f90 and requires follow-up
changes that i'm not entirely comfortable with.

> 
> I did not really look at the standard, so i wonder if that makes sense to
> somebody more familiar with that area?

[Bug fortran/103931] Type name "c_ptr" is ambiguous when iso_c_binding is imported both directly and indirectly

[aldot at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #18 from Bernhard Reutner-Fischer  ---
(In reply to Bernhard Reutner-Fischer from comment #17)
> (In reply to Bernhard Reutner-Fischer from comment #16)
> 
> > I'm testing a more elaborate test which keeps check_for_ambiguous in the
> > same spot as before, but in that check, looks if the symtree (C_ptr in this
> > case, number 3) is listed in the generic interfaces after the existing check
> > that looks if the symbol itself is GENERIC.
> 
> This highlights cases like in use_24.f90 and use_27.f90 and requires
> follow-up changes that i'm not entirely comfortable with.

We can just mark the dt symbol (which is used to describe the generic
interface) as attr.generic = 1

This regtests cleanly and fixes the reported bug.


diff --git a/gcc/fortran/symbol.cc b/gcc/fortran/symbol.cc
index 221165d6dac..28ed1a32b9e 100644
--- a/gcc/fortran/symbol.cc
+++ b/gcc/fortran/symbol.cc
@@ -4977,6 +4986,10 @@ generate_isocbinding_symbol (const char *mod_name,
iso_c_binding_symbol s,
  if (!tmp_sym->attr.function
  && !gfc_add_function (&tmp_sym->attr, tmp_sym->name, NULL))
return NULL;
+
+ /* Mark the derived-type symbol in the generic interface
+as generic.  */
+ dt_sym->attr.generic = 1;
}

  /* Say what module this symbol belongs to.  */


i.e. it marks the dt as GENERIC, so the gmodule contents from comment #16
become
...
(('c_funptr' '__iso_c_binding' 2) ('c_ptr' '__iso_c_binding' 3)) // generic
interfaces
...
(2 'C_funptr' '__iso_c_binding' '' 1 ((DERIVED UNKNOWN-INTENT
UNKNOWN-PROC UNKNOWN UNKNOWN 0 0 GENERIC IS_BIND_C IS_C_INTEROP
PRIVATE_COMP) ((4 'c_address' (INTEGER 8 0 1 0 INTEGER ()) () () () (
UNKNOWN-FL UNKNOWN-INTENT UNKNOWN-PROC UNKNOWN UNKNOWN 0 0) PRIVATE ()))
PRIVATE (DERIVED 2 0 1 1 VOID ()) 0 0 () () 0 () () () 2 44 0)
3 'C_ptr' '__iso_c_binding' '' 1 ((DERIVED UNKNOWN-INTENT UNKNOWN-PROC
UNKNOWN UNKNOWN 0 0 GENERIC IS_BIND_C IS_C_INTEROP PRIVATE_COMP) ((5
'c_address' (INTEGER 8 0 1 0 INTEGER ()) () () () (UNKNOWN-FL
UNKNOWN-INTENT UNKNOWN-PROC UNKNOWN UNKNOWN 0 0) PRIVATE ())) PRIVATE (
DERIVED 3 0 1 1 VOID ()) 0 0 () () 0 () () () 2 42 0)

[Bug fortran/109624] New: dump-parse-tree prints attributes with unbalanced braces

[aldot at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 109624
   Summary: dump-parse-tree prints attributes with unbalanced
braces
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: internal-improvement
  Severity: trivial
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aldot at gcc dot gnu.org
  Target Milestone: ---

(gdb) call debug(gfc_current_ns)

Namespace: A-H: (REAL 4) I-N: (INTEGER 4) O-Z: (REAL 4)
procedure name = fmodule
  symtree: 'C_ptr'   || symbol: 'c_ptr'
type spec : (UNKNOWN 0)
attributes: )
  symtree: '__def_init___iso_c_binding_C_ptr'|| symbol:
'__def_init___iso_c_binding_C_ptr' 
type spec : (UNKNOWN 0)
attributes: )
...

There is an open brace missing after "attributes: "

diff --git a/gcc/fortran/dump-parse-tree.cc b/gcc/fortran/dump-parse-tree.cc
index 1fc1f311e84..2380fa04796 100644
--- a/gcc/fortran/dump-parse-tree.cc
+++ b/gcc/fortran/dump-parse-tree.cc
@@ -125,6 +125,16 @@ void debug (gfc_ref *p)
   dumpfile = tmp;
 }

+void
+debug (gfc_namespace *ns)
+{
+  FILE *tmp = dumpfile;
+  dumpfile = stderr;
+  show_namespace (ns);
+  fputc ('\n', dumpfile);
+  dumpfile = tmp;
+}
+
 void
 gfc_debug_expr (gfc_expr *e)
 {
@@ -136,7 +146,6 @@ gfc_debug_expr (gfc_expr *e)
 }

 /* Allow for dumping of a piece of code in the debugger.  */
-void gfc_debug_code (gfc_code *c);

 void
 gfc_debug_code (gfc_code *c)
@@ -758,12 +767,13 @@ show_expr (gfc_expr *p)
 static void
 show_attr (symbol_attribute *attr, const char * module)
 {
+  fputc ('(', dumpfile);
   if (attr->flavor != FL_UNKNOWN)
 {
   if (attr->flavor == FL_DERIVED && attr->pdt_template)
-   fputs (" (PDT-TEMPLATE", dumpfile);
+   fputs ("PDT-TEMPLATE ", dumpfile);
   else
-fprintf (dumpfile, "(%s ", gfc_code2string (flavors, attr->flavor));
+   fprintf (dumpfile, "%s ", gfc_code2string (flavors, attr->flavor));
 }
   if (attr->access != ACCESS_UNKNOWN)
 fprintf (dumpfile, "%s ", gfc_code2string (access_types, attr->access));

[Bug fortran/103931] Type name "c_ptr" is ambiguous when iso_c_binding is imported both directly and indirectly

[aldot at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #21 from Bernhard Reutner-Fischer  ---
(In reply to anlauf from comment #19)

> C_PTR is an intrinsic DT and not a procedure;
> so we should not mark it as "generic".

Ok, that makes sense indeed.

> 
> As long as a symbol from an *intrinsic module* is use-associated - either
> directly or indirectly - the conflict check could trace it down to its
> origin (in case it is renamed), and we would resolve this explicitly.

I think renaming works. Let's concentrate on a case without renaming first.
I'll have another look now.

Btw, there is also module == "(intrinsic)" which we might want to reconsider
nowadays, but that is for another day.

[Bug middle-end/110052] New: useless local variable not optimized away

[aldot at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 110052
   Summary: useless local variable not optimized away
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aldot at gcc dot gnu.org
  Target Milestone: ---

Created attachment 55221
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55221&action=edit
reduced test, v1

A superfluous local variable is not optimized away.

Consider:
$ cat localvar.c ; echo EOF
#include 
// original flags: gcc-12 -std=gnu99 -malign-data=abi -finline-limit=0
-fno-builtin-strlen -fomit-frame-pointer -ffunction-sections -fdata-sections
-fno-guess-branch-probability -funsigned-char -falign-functions=1
-falign-jumps=1 -falign-labels=1 -falign-loops=1 -fno-unwind-tables
-fno-asynchronous-unwind-tables -fno-builtin-printf -Oz
extern void *realloc(void *ptr, size_t size);
static char * __attribute__((noipa))
myrealloc(void *ptr, int n, int *size)
{
  if (!ptr || n >= *size) {
*size = n + (n >> 1) + 80;
ptr = realloc (ptr, *size);
if (ptr == NULL) /* mimic xrealloc */
  __builtin_abort();
  }
  return ptr;
}
typedef struct foo_s {
  int fd;
  char *buffer;
  int adv;
  int size;
  int pos;
  signed char boo;
} foo_t;

void bloat(foo_t *);
void bloat(foo_t *foo) {
  char *m = foo->buffer;
  /* This is the original code, the local variable is superfluous */
  int size = foo->size;
  if (!m)
m = myrealloc(m, 256, &size);
  foo->size = size;
}

void ok(foo_t *);
void ok(foo_t *foo) {
  char *m = foo->buffer;
  if (!m)
m = myrealloc(m, 256, &foo->size);
}
EOF


$ readelf -s localvar.o | grep "FUNC *GLOBAL"
13: 52 FUNCGLOBAL DEFAULT6 bloat
14: 24 FUNCGLOBAL DEFAULT8 ok
$ strip -R .comment localvar.o
$ objdump -D localvar.o

localvar.o: file format elf64-x86-64


Disassembly of section .text.myrealloc:

 <.text.myrealloc>:
   0:   48 89 f8mov%rdi,%rax
   3:   48 85 fftest   %rdi,%rdi
   6:   74 04   je 0xc
   8:   39 32   cmp%esi,(%rdx)
   a:   7f 21   jg 0x2d
   c:   51  push   %rcx
   d:   89 f1   mov%esi,%ecx
   f:   48 97   xchg   %rax,%rdi
  11:   d1 f9   sar%ecx
  13:   8d 74 0e 50 lea0x50(%rsi,%rcx,1),%esi
  17:   89 32   mov%esi,(%rdx)
  19:   48 63 f6movslq %esi,%rsi
  1c:   e8 00 00 00 00  callq  0x21
  21:   48 85 c0test   %rax,%rax
  24:   75 05   jne0x2b
  26:   e8 00 00 00 00  callq  0x2b
  2b:   5a  pop%rdx
  2c:   c3  retq   
  2d:   c3  retq   

Disassembly of section .text.bloat:

 <.text.bloat>:
   0:   53  push   %rbx
   1:   48 89 fbmov%rdi,%rbx
   4:   48 83 ec 10 sub$0x10,%rsp
   8:   8b 47 14mov0x14(%rdi),%eax
   b:   48 83 7f 08 00  cmpq   $0x0,0x8(%rdi)
  10:   89 44 24 0c mov%eax,0xc(%rsp)
  14:   75 11   jne0x27
  16:   48 8d 54 24 0c  lea0xc(%rsp),%rdx
  1b:   be 00 01 00 00  mov$0x100,%esi
  20:   31 ff   xor%edi,%edi
  22:   e8 00 00 00 00  callq  0x27
  27:   8b 44 24 0c mov0xc(%rsp),%eax
  2b:   89 43 14mov%eax,0x14(%rbx)
  2e:   48 83 c4 10 add$0x10,%rsp
  32:   5b  pop%rbx
  33:   c3  retq   

Disassembly of section .text.ok:

 <.text.ok>:
   0:   48 83 7f 08 00  cmpq   $0x0,0x8(%rdi)
   5:   75 10   jne0x17
   7:   48 8d 57 14 lea0x14(%rdi),%rdx
   b:   be 00 01 00 00  mov$0x100,%esi
  10:   31 ff   xor%edi,%edi
  12:   e9 00 00 00 00  jmpq   0x17
  17:   c3  retq   

object size with each myrealloc and either bloat or ok:
$ size localvar-*.o
   textdata bss dec hex filename
 70   0   0  70  46 localvar-ok.o
 98   0   0  98  62 localvar-bloat.o

[Bug middle-end/110052] useless local variable not optimized away

[aldot at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Bernhard Reutner-Fischer  ---
Note that in this particular case myrealloc() is static, maybe i should have
omitted the noipa attribute for it was only meant to simplify analysis and
there is no such attribute in the original code.
Furthermore, i would have hoped that given the placement of the definition of
myrealloc() before the typedef foo_t, it should be unlikely that the usage of
*foo would invalidate such an optimisation _in this particular case_. While the
original code unfortunately does not mark *foo as restrict, adding restrict
would hopefully make it clear that myrealloc() has no business in comparing
foo's struct members, i'd hope?

When i drop the noipa attribute in the v1 testcase to make it similar to the
motivating case, i get:
9: 44 FUNCGLOBAL DEFAULT4 bloat
   12: 38 FUNCGLOBAL DEFAULT6 ok


 :
   0:   53  push   %rbx
   1:   48 83 7f 08 00  cmpq   $0x0,0x8(%rdi)
   6:   48 89 fbmov%rdi,%rbx
   9:   8b 47 14mov0x14(%rdi),%eax
   c:   75 19   jne27 
   e:   bf d0 01 00 00  mov$0x1d0,%edi
  13:   e8 00 00 00 00  callq  18 
  18:   48 85 c0test   %rax,%rax
  1b:   75 05   jne22 
  1d:   e8 00 00 00 00  callq  22 
  22:   b8 d0 01 00 00  mov$0x1d0,%eax
  27:   89 43 14mov%eax,0x14(%rbx)
  2a:   5b  pop%rbx
  2b:   c3  retq   

Disassembly of section .text.ok:

 :
   0:   48 83 7f 08 00  cmpq   $0x0,0x8(%rdi)
   5:   75 1e   jne25 
   7:   52  push   %rdx
   8:   c7 47 14 d0 01 00 00movl   $0x1d0,0x14(%rdi)
   f:   bf d0 01 00 00  mov$0x1d0,%edi
  14:   e8 00 00 00 00  callq  19 
  19:   48 85 c0test   %rax,%rax
  1c:   75 05   jne23 
  1e:   e8 00 00 00 00  callq  23 
  23:   58  pop%rax
  24:   c3  retq   
  25:   c3  retq

[Bug middle-end/110052] useless local variable not optimized away

[aldot at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Bernhard Reutner-Fischer  ---
(In reply to Bernhard Reutner-Fischer from comment #3)
> Note that in this particular case myrealloc() is static, maybe i should have
> omitted the noipa attribute for it was only meant to simplify analysis and
> there is no such attribute in the original code.
> Furthermore, i would have hoped that given the placement of the definition
> of myrealloc() before the typedef foo_t, it should be unlikely that the
> usage of *foo would invalidate such an optimisation _in this particular
> case_. While the original code unfortunately does not mark *foo as restrict,
> adding restrict would hopefully make it clear that myrealloc() has no
> business in comparing foo's struct members, i'd hope?
> 
> When i drop the noipa attribute in the v1 testcase to make it similar to the
> motivating case, i get:

Correction: When i replace noipa with noinline,noclone (and drop
-ffunction-sections -fdata-sections to improve readability), i get:
10: 003052 FUNCGLOBAL DEFAULT1 bloat
10: 003021 FUNCGLOBAL DEFAULT1 ok

0030 :
  30:   53  push   %rbx
  31:   48 89 fbmov%rdi,%rbx
  34:   48 83 ec 10 sub$0x10,%rsp
  38:   8b 47 14mov0x14(%rdi),%eax
  3b:   48 83 7f 08 00  cmpq   $0x0,0x8(%rdi)
  40:   89 44 24 0c mov%eax,0xc(%rsp)
  44:   75 11   jne57 
  46:   48 8d 54 24 0c  lea0xc(%rsp),%rdx
  4b:   be 00 01 00 00  mov$0x100,%esi
  50:   31 ff   xor%edi,%edi
  52:   e8 a9 ff ff ff  callq  0 
  57:   8b 44 24 0c mov0xc(%rsp),%eax
  5b:   89 43 14mov%eax,0x14(%rbx)
  5e:   48 83 c4 10 add$0x10,%rsp
  62:   5b  pop%rbx
  63:   c3  retq   

0030 :
  30:   48 83 7f 08 00  cmpq   $0x0,0x8(%rdi)
  35:   75 0d   jne44 
  37:   48 8d 57 14 lea0x14(%rdi),%rdx
  3b:   be 00 01 00 00  mov$0x100,%esi
  40:   31 ff   xor%edi,%edi
  42:   eb bc   jmp0 
  44:   c3  retq

[Bug fortran/78798] [cleanup] some int-valued functions should be bool

[aldot at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #14 from Bernhard Reutner-Fischer  ---
Not yet fixed completely, Mikael correctly noted:

> Why not change the associated subfunctions 
> (gfc_check_argument_dependency, gfc_check_argument_var_dependency) as well ?

[Bug analyzer/113277] New: RFE: analyzer diagnose allocation error leading to pass NULL to snprintf

[aldot at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 113277
   Summary: RFE: analyzer diagnose allocation error leading to
pass NULL to snprintf
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: aldot at gcc dot gnu.org
  Target Milestone: ---

Currently the analyzer does not diagnose passing in NULL as first argument to
snprintf when NULL might stem from an unchecked allocation error.
See the undiagnosed occurrence in nak() here:

$ cat ~/gcc-alloc-vs-snprintf.c; echo EOF
#include 
#include 
#if 0
//snprintf first argument can be NULL according to POSIX, so we cannot
extern int snprintf (char *__restrict __s, size_t __maxlen,
const char *__restrict __format, ...)
  __THROWNL __attribute__ ((__format__ (__printf__, 3, 4),__nonnull__ ((1;
#endif

/* pass NULL as first arg to snprintf */
int by_arg (void) {
  int ret = snprintf (NULL, 42, "%d%s", 1234, "mystring");
  if (ret != 12) {
__builtin_abort ();
  }
  return 0;
}


/* pass NULL via variable as first arg to snprintf */
int by_var (void) {
  char *chp = NULL;
  int ret = snprintf (chp, 42, "%d%s", 1234, "mystring");
  if (ret != 12) {
__builtin_abort ();
  }
  return 0;
}

/* pass NULL on allocation failure as first arg to snprintf */
int nak (void) {
  char *chp = calloc (42, sizeof(unsigned char));
  // chp != NULL not checked here
  int ret = snprintf (chp, 42, "%d%s", 1234, "mystring");
  if (ret != 12) {
__builtin_abort ();
  }
  return 0;
}
EOF

Gives:
$ gcc -std=c11 -W -Wall -Wextra -pedantic -O2 -fanalyzer -c -o /tmp/foo.o
gcc-alloc-vs-snprintf.c
gcc-alloc-vs-snprintf.c: In function ‘by_arg’:
gcc-alloc-vs-snprintf.c:12:13: warning: null destination pointer
[-Wformat-truncation=]
   12 |   int ret = snprintf (NULL, 42, "%d%s", 1234, "mystring");
  | ^
gcc-alloc-vs-snprintf.c: In function ‘by_var’:
gcc-alloc-vs-snprintf.c:12:13: warning: null destination pointer
[-Wformat-truncation=]
   12 |   int ret = snprintf (NULL, 42, "%d%s", 1234, "mystring");
  | ^

I would have hoped that in nak() it is noted that the return value of calloc()
was not checked before being passed to snprintf and hence might be NULL (even
though the size argument was non-zero).