[Bug tree-optimization/88934] [9 Regression] ICE: verify_gimple failed (Error: mismatching comparison operand types)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-21
 CC||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
  Component|middle-end  |tree-optimization
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, there's a minimal test-case:

$ cat matmul.f90
integer, parameter :: a=3
  integer , dimension(a,a) :: b 
  logical, dimension(a,a) :: c 

  do i=0,1
 b = ltoi(c)
 do j=0,if
if (anymatmul(b) /= 0) then
end if
 end do
  end do
contains
  elemental function ltoi(d)

logical, intent(in) :: d
if (d) then
   ltoi = 1
else
   ltoi = 0
end if
  end  
end 

$ ./xgcc -B. -c -mvsx -O1 -ftree-vectorize matmul.f90
matmul.f90:5:0:

5 |   do i=0,1
  | 
Error: mismatching comparison operand types
vector(4) unsigned int
vector(4) 
vect_patt_43.17_16 = VEC_COND_EXPR ;
matmul.f90:5:0: Error: mismatching comparison operand types
vector(4) unsigned int
vector(4) 
vect_patt_43.17_34 = VEC_COND_EXPR ;
during GIMPLE pass: slp
matmul.f90:5:0: internal compiler error: verify_gimple failed
0xd73ba7 verify_gimple_in_cfg(function*, bool)
../../gcc/tree-cfg.c:5422
0xc5b6df execute_function_todo
../../gcc/passes.c:1977
0xc5c60e execute_todo
../../gcc/passes.c:2031
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

$ ./xgcc -v
Using built-in specs.
COLLECT_GCC=./xgcc
Target: powerpc-linux-gnu
Configured with: ../configure --enable-languages=c,c++,fortran
--disable-multilib --prefix=/home/marxin/bin/gcc2 --disable-bootstrap
--disable-libsanitizer --target=powerpc-linux-gnu
--with-as=/usr/bin/powerpc-suse-linux-as
Thread model: posix
gcc version 9.0.0 20190121 (experimental) (GCC) 

Richi can you please take a look?

[Bug fortran/88908] [9 Regression] ICE in tree check: expected tree that contains ‘decl common’ structure, have ‘indirect_ref’ in gfc_conv_gfc_desc_to_cfi_desc, at fortran/trans-expr.c:4927

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Great, thanks for the fix.

[Bug ipa/88933] ICE: verify_cgraph_node failed (Error: caller edge count does not match BB count)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-01-21
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, let me take the PR.

[Bug target/88877] rs6000 emits signed extension for unsigned int type(__floatunsidf).

[umesh.kalappa0 at gmail dot com]

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

--- Comment #15 from Umesh Kalappa  ---
like jakub recommended in the other mail thread ,

All the callers of emit_library_call* would need to be changed to pass
triplets rtx, machine_mode, int/bool /*unsignedp*/, instead of just
rtx_mode_t pair or add a new set of emit_library_call* APIs that would take
those triplets.

we feel thats clean fix ,but needs exhaust testing here (impact on other
targets).

[Bug fortran/88912] Fortran compiler segfaults when pre-include file is not found

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
No, you should add a proper error for that case.

[Bug fortran/88912] Fortran compiler segfaults when pre-include file is not found

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
May I close the issue as invalid? As noted by Jakub, the option should not be
used by users directly and is not documented right now.

[Bug middle-end/88897] Bogus maybe-uninitialized warning on class field

[rafael at espindo dot la]

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

Rafael Avila de Espindola  changed:

   What|Removed |Added

  Attachment #45452|0   |1
is obsolete||
  Attachment #45453|0   |1
is obsolete||

--- Comment #4 from Rafael Avila de Espindola  ---
Created attachment 45475
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45475&action=edit
testcase

Now that I know what to look for I reduced the testcase again trying to make
sure to not introduce uninitialized uses in the process.

As far as I can tell the warning in the attached testcase is wrong.

First an optional is constructed, but _M_engaged is false since it doesn't hold
a value.

It is then moved, but move constructor checks __other._M_engaged, so the
temporary_buffer move constructor should never be called.

[Bug libstdc++/88935] std::random_shuffle does not work if the sequence is longer than RAND_MAX elements

[giovannibajo at gmail dot com]

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

--- Comment #6 from Giovanni Bajo  ---
A patch has been posted here:
https://gcc.gnu.org/ml/libstdc++/2018-12/msg00038.html

[Bug libstdc++/88935] std::random_shuffle does not work if the sequence is longer than RAND_MAX elements

[giovannibajo at gmail dot com]

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

--- Comment #5 from Giovanni Bajo  ---
Created attachment 45474
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45474&action=edit
Chart generated by chart.cpp that highlights broken distribution

[Bug libstdc++/88935] std::random_shuffle does not work if the sequence is longer than RAND_MAX elements

[giovannibajo at gmail dot com]

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

--- Comment #4 from Giovanni Bajo  ---
Created attachment 45473
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45473&action=edit
What test.cpp actually does output with std::random_shuffle

[Bug libstdc++/88935] std::random_shuffle does not work if the sequence is longer than RAND_MAX elements

[giovannibajo at gmail dot com]

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

--- Comment #3 from Giovanni Bajo  ---
Created attachment 45472
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45472&action=edit
What test.cpp should output if random_shuffle worked

[Bug libstdc++/88935] std::random_shuffle does not work if the sequence is longer than RAND_MAX elements

[giovannibajo at gmail dot com]

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

--- Comment #2 from Giovanni Bajo  ---
Created attachment 45471
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45471&action=edit
Test code to draw a chart of distributions

[Bug libstdc++/88935] std::random_shuffle does not work if the sequence is longer than RAND_MAX elements

[giovannibajo at gmail dot com]

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

--- Comment #1 from Giovanni Bajo  ---
Created attachment 45470
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45470&action=edit
Test code to reproduce bug

[Bug libstdc++/88935] New: std::random_shuffle does not work if the sequence is longer than RAND_MAX elements

[giovannibajo at gmail dot com]

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

Bug ID: 88935
   Summary: std::random_shuffle does not work if the sequence is
longer than RAND_MAX elements
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: giovannibajo at gmail dot com
  Target Milestone: ---

The problem we faced is an heavy non-uniform distribution of probabilities
with the result of std::random_shuffle when the number of elements in the
sequence is big compared to RAND_MAX.

In the specific the problem become appearent after investigating the bad
performance of an algorithm that was discovered being originated by a bad
shuffling of the pixel positions of an image.

To clearly see the problem of the skewed distribution consider the following
code:

#include 
#include 
#include 

int main(int argc, const char *argv[]) {
int w = 512, h = 512;

// all pixels black at start
std::vector img(w*h);

// Create a list of all pixels
std::vector pixels(w*h);
for (int i=0; i RAND_MAX and in this case the
ratio is infinite (some numbers have zero probability because "x"s
are not enough!).

When using random_shuffle this is not very evident at a first sight
on a single shuffle unless N is much bigger than RAND_MAX (what
happened to us) but plotting a chart of the average value of x[i]
after a shuffle operation makes the problem evident even when the
value is smaller but not much smaller.

chart.png shows the average of x[i] on 1 random shuffle operations
performed simulating a RAND_MAX of 32767 with an array of 24576
elements (3/4 of RAND_MAX). Of course the "correct" plot for an
equidistributed random_shuffle should be a flat horizontal line.

chart.cpp code used to produce the data for charts is

#include 
#include 
#include 
#include 

int main(int argc, const char *argv[]) {
int N = argc > 1 ? atoi(argv[1]) : 32768;
std::vector data(N), total(N);

for (int i=0; i<1; i++) {
for (int j=0; j

[Bug middle-end/88934] New: [9 Regression] ICE: verify_gimple failed (Error: mismatching comparison operand types)

[asolokha at gmx dot com]

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

Bug ID: 88934
   Summary: [9 Regression] ICE: verify_gimple failed (Error:
mismatching comparison operand types)
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-checking, ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: powerpc-e300c3-linux-gnu

gfortran-9.0.0-alpha20190113 snapshot (r267906) ICEs when compiling
gcc/testsuite/gfortran.dg/matmul_6.f90 w/ -mvsx -O1 (-O2, -Os) -ftree-vectorize
(maybe -m32 is also needed):

% powerpc-e300c3-linux-gnu-gfortran-9.0.0-alpha20190113 -mvsx -O1
-ftree-vectorize -c gcc/testsuite/gfortran.dg/matmul_6.f90
gcc/testsuite/gfortran.dg/matmul_6.f90:7:0:

7 | program main
  | 
Error: mismatching comparison operand types
vector(4) unsigned int
vector(4) 
vect_patt_410.97_511 = VEC_COND_EXPR ;
gcc/testsuite/gfortran.dg/matmul_6.f90:7:0: Error: mismatching comparison
operand types
vector(4) unsigned int
vector(4) 
vect_patt_410.97_521 = VEC_COND_EXPR ;
gcc/testsuite/gfortran.dg/matmul_6.f90:7:0: Error: mismatching comparison
operand types
vector(4) unsigned int
vector(4) 
vect_patt_540.105_142 = VEC_COND_EXPR ;
gcc/testsuite/gfortran.dg/matmul_6.f90:7:0: Error: mismatching comparison
operand types
vector(4) unsigned int
vector(4) 
vect_patt_540.105_361 = VEC_COND_EXPR ;
during GIMPLE pass: slp
gcc/testsuite/gfortran.dg/matmul_6.f90:7:0: internal compiler error:
verify_gimple failed
0xdeb409 verify_gimple_in_cfg(function*, bool)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190113/work/gcc-9-20190113/gcc/tree-cfg.c:5422
0xcc176e execute_function_todo
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190113/work/gcc-9-20190113/gcc/passes.c:1977
0xcc210a execute_todo
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190113/work/gcc-9-20190113/gcc/passes.c:2031

[Bug ipa/88933] New: ICE: verify_cgraph_node failed (Error: caller edge count does not match BB count)

[asolokha at gmx dot com]

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

Bug ID: 88933
   Summary: ICE: verify_cgraph_node failed (Error: caller edge
count does not match BB count)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ice-checking, ice-on-valid-code, openmp
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

gfortran-9.0.0-alpha20190113 snapshot (r267906) ICEs when compiling
libgomp/testsuite/libgomp.fortran/task2.f90 at any optimization level (except
-Ofast) and w/ -fexceptions -fipa-cp -fnon-call-exceptions -fopenmp
-fno-inline-functions-called-once:

% powerpc-e300c3-linux-gnu-gfortran-9.0.0-alpha20190113 -std=legacy -O1
-fexceptions -fipa-cp -fnon-call-exceptions -fopenmp
-fno-inline-functions-called-once -c
libgomp/testsuite/libgomp.fortran/task2.f90
libgomp/testsuite/libgomp.fortran/task2.f90:18:0:

   18 |   subroutine foo (c, d, e, f, g, h, i, j, k, n)
  | 
Error: caller edge count does not match BB count
edge count: 748404 (estimated locally)
 bb count: 1804253 (estimated locally)
libgomp/testsuite/libgomp.fortran/task2.f90:18:0: Error: caller edge count does
not match BB count
edge count: 30269084 (estimated locally)
 bb count: 72972719 (estimated locally)
foo.2124.constprop.0/27 (foo.constprop) @0x7fb992431b40
  Type: function definition analyzed
  Visibility: artificial
  References: 
  Referring: 
  Availability: local
  Function flags: count:1804252 (estimated locally) body local
  Called by: test/0 (6137140 (estimated locally),1.00 per call) (can throw
external) 
  Calls: __builtin_stack_save/20 (1804252 (estimated locally),1.00 per call)
__builtin_alloca_with_align/21 (1804252 (estimated locally),1.00 per call)
__builtin_malloc/22 (1804252 (estimated locally),1.00 per call)
__builtin_malloc/22 (1804252 (estimated locally),1.00 per call)
__builtin_malloc/22 (1804252 (estimated locally),1.00 per call)
__builtin_memcpy/14 (532254 (estimated locally),0.29 per call)
__builtin_memset/23 (532254 (estimated locally),0.29 per call)
__builtin_memcpy/14 (532254 (estimated locally),0.29 per call)
__builtin_memcpy/14 (6649989 (estimated locally),3.69 per call)
__builtin_memset/23 (6649989 (estimated locally),3.69 per call)
__builtin_memcpy/14 (6649989 (estimated locally),3.69 per call)
__builtin_memcpy/14 (6649989 (estimated locally),3.69 per call)
__builtin_memset/23 (6649989 (estimated locally),3.69 per call)
__builtin_memcpy/14 (6649989 (estimated locally),3.69 per call)
__builtin_GOMP_task/24 (1804253 (estimated locally),1.00 per call)
__builtin_memset/23 (748404 (estimated locally),0.41 per call)
__builtin_memset/23 (748404 (estimated locally),0.41 per call)
__builtin_memset/23 (30269084 (estimated locally),16.78 per call)
__builtin_memset/23 (30269087 (estimated locally),16.78 per call)
__builtin_memset/23 (748405 (estimated locally),0.41 per call)
__builtin_free/25 (1804255 (estimated locally),1.00 per call) __builtin_free/25
(1804255 (estimated locally),1.00 per call) __builtin_free/25 (1804255
(estimated locally),1.00 per call) __builtin_stack_restore/26 (1804255
(estimated locally),1.00 per call) __builtin_free/25 (0 (precise),0.00 per
call) __builtin_free/25 (0 (precise),0.00 per call) __builtin_free/25 (0
(precise),0.00 per call) 
during IPA pass: inline
libgomp/testsuite/libgomp.fortran/task2.f90:18:0: internal compiler error:
verify_cgraph_node failed
0x97940f cgraph_node::verify_node()
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190113/work/gcc-9-20190113/gcc/cgraph.c:3430
0x96d134 symtab_node::verify()
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190113/work/gcc-9-20190113/gcc/symtab.c:1218
0xe288f9 optimize_inline_calls(tree_node*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190113/work/gcc-9-20190113/gcc/tree-inline.c:5060
0x15347d4 inline_transform(cgraph_node*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190113/work/gcc-9-20190113/gcc/ipa-inline-transform.c:682
0xcc4454 execute_one_ipa_transform_pass
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190113/work/gcc-9-20190113/gcc/passes.c:2225
0xcc4454 execute_all_ipa_transforms()
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190113/work/gcc-9-20190113/gcc/passes.c:2264
0x98053c cgraph_node::expand()
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190113/work/gcc-9-20190113/gcc/cgraphunit.c:2189
0x981a0d expand_all_functions
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190113/work/gcc-9-20190113/gcc/cgraphunit.c:2334
0x981a0d symbol_table::compile()
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190113/work/gcc-9-20190113/

[Bug tree-optimization/88932] New: [8/9 Regression] ICE: verify_ssa failed (Error: definition in block 29 does not dominate use in block 25)

[asolokha at gmx dot com]

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

Bug ID: 88932
   Summary: [8/9 Regression] ICE: verify_ssa failed (Error:
definition in block 29 does not dominate use in block
25)
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-checking, ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gfortran-9.0.0-alpha20190113 snapshot (r267906) ICEs when compiling
gcc/testsuite/gfortran.dg/assumed_rank_1.f90 w/ -fpredictive-commoning
-fno-tree-ch -fno-tree-dominator-opts -fno-tree-fre:

% powerpc-e300c3-linux-gnu-gfortran-9.0.0-alpha20190113 -O1
-fpredictive-commoning -fno-tree-ch -fno-tree-dominator-opts -fno-tree-fre -c
gcc/testsuite/gfortran.dg/assumed_rank_1.f90
gcc/testsuite/gfortran.dg/assumed_rank_1.f90:96:0:

   96 |   subroutine foo2(a, rnk, low, high, val)
  | 
Error: definition in block 29 does not dominate use in block 25
for SSA_NAME: D_lsm0.181_140 in statement:
_68 = D_lsm0.181_140;
during GIMPLE pass: pcom
gcc/testsuite/gfortran.dg/assumed_rank_1.f90:96:0: internal compiler error:
verify_ssa failed
0xfbf4e6 verify_ssa(bool, bool)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190113/work/gcc-9-20190113/gcc/tree-ssa.c:1188
0xcc1870 execute_function_todo
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190113/work/gcc-9-20190113/gcc/passes.c:1984
0xcc210a execute_todo
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190113/work/gcc-9-20190113/gcc/passes.c:2031

(While my target here is powerpc, the ICE not target-specific.)

[Bug rtl-optimization/88423] [9 Regression] ICE in begin_move_insn, at sched-ebb.c:175

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #6 from Segher Boessenkool  ---
Is this a dup of PR88347?

[Bug fortran/34392] BOZ diagnost invalid Fortran 2003 use with -std=f2003 warnings

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #4 from kargl at gcc dot gnu.org ---
(In reply to Jürgen Reuter from comment #3)
> Looks like one needs to come up with a list of possible cases to find one
> that is not yet covered.

BOZ handling needs to be rewritten.  I'll get to it one day.

[Bug fortran/34663] Specification expression is defined by dummy variables of different entry points

[juergen.reuter at desy dot de]

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

Jürgen Reuter  changed:

   What|Removed |Added

 CC||juergen.reuter at desy dot de

--- Comment #3 from Jürgen Reuter  ---
Entry is now a F2008 obsolescent feature. Neither nagfor nor PGI catch this.

[Bug fortran/34528] Document internal structure of arrays

[juergen.reuter at desy dot de]

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

Jürgen Reuter  changed:

   What|Removed |Added

 CC||juergen.reuter at desy dot de

--- Comment #2 from Jürgen Reuter  ---
Is this still the same interface nowadays then it was back then? And is a
possible new one now maybe documented?

[Bug fortran/34392] BOZ diagnost invalid Fortran 2003 use with -std=f2003 warnings

[juergen.reuter at desy dot de]

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

Jürgen Reuter  changed:

   What|Removed |Added

 CC||juergen.reuter at desy dot de

--- Comment #3 from Jürgen Reuter  ---
Looks like one needs to come up with a list of possible cases to find one that
is not yet covered.

[Bug fortran/33097] Function decl trees without proper argument list

[juergen.reuter at desy dot de]

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

Jürgen Reuter  changed:

   What|Removed |Added

 CC||juergen.reuter at desy dot de

--- Comment #20 from Jürgen Reuter  ---
Dominique, you announced almost 10 months ago that you would close this one in
case of no feedback. Closing?

[Bug middle-end/88175] Showing header file instead of source code line for uninitialized variable

[jg at jguk dot org]

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

--- Comment #15 from Jonny Grant  ---
Does the implicitly created copy-constructor get saved to a file at all? Or can
it be saved to a file like -save-temps does?

[Bug fortran/32986] Improve diagnostic message for COMMON with automatic object

[juergen.reuter at desy dot de]

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

Jürgen Reuter  changed:

   What|Removed |Added

 CC||juergen.reuter at desy dot de

--- Comment #3 from Jürgen Reuter  ---
Indeed, ifort is more informative, though nagfor also just tells em
"N is not permitted in a constant expression".

[Bug fortran/32515] [F03] Reject COMMON block names if local symbol already exists

[juergen.reuter at desy dot de]

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

Jürgen Reuter  changed:

   What|Removed |Added

 CC||juergen.reuter at desy dot de

--- Comment #4 from Jürgen Reuter  ---
I think Mikael Morin is incorrect here. nagfor and ifort reject the test case,
e.g. 
ifort:
A name that identifies a global entity is used to identify another global
entity in the same program.
nagfor:
Error: pr_32515.f90, line 31: COMMON block BAR is also a global procedure
So I think this should be closed.

[Bug fortran/32512] efficiency of RESHAPE and SPREAD

[juergen.reuter at desy dot de]

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

Jürgen Reuter  changed:

   What|Removed |Added

 CC||juergen.reuter at desy dot de

--- Comment #8 from Jürgen Reuter  ---
Is this still an actual feature request? or have things changed in the past 7
years?

[Bug fortran/88579] Calculating power of powers of two

[anlauf at gmx dot de]

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

--- Comment #4 from Harald Anlauf  ---
Patch submitted here:

https://gcc.gnu.org/ml/fortran/2019-01/msg00163.html

[Bug target/88906] wrong code with -march=k6 -minline-all-stringops -minline-stringops-dynamically -mmemcpy-strategy=libcall:-1:align and vector argument

[ubizjak at gmail dot com]

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

--- Comment #3 from Uroš Bizjak  ---
Before dse1 pass, we have:

5: {r90:SI=frame:SI-0x20;clobber flags:CC;}
  REG_UNUSED flags:CC
6: r91:SI=0
7: r92:SI=0x4
8: {r92:SI=0;r90:SI=r92:SI<<0x2+r90:SI;[r90:SI]=0;use r91:SI;use r92:SI;}
  REG_DEAD r91:SI
  REG_UNUSED r92:SI
  REG_UNUSED r90:SI
9: [frame:SI-0x20]=0x
   10: [frame:SI-0x20]=0
   13: {r95:SI=frame:SI-0x10;clobber flags:CC;}
  REG_UNUSED flags:CC
   14: {r96:SI=frame:SI-0x20;clobber flags:CC;}
  REG_UNUSED flags:CC
   16: {sp:SI=sp:SI-0x4;clobber flags:CC;}
  REG_UNUSED flags:CC
  REG_ARGS_SIZE 0x4
   17: [--sp:SI]=0x10
  REG_ARGS_SIZE 0x8
   18: [--sp:SI]=r96:SI
  REG_DEAD r96:SI
  REG_ARGS_SIZE 0xc
   19: [--sp:SI]=r95:SI
  REG_DEAD r95:SI
  REG_ARGS_SIZE 0x10
   20: ax:SI=call [`memcpy'] argc:0x10
  REG_UNUSED ax:SI
  REG_EH_REGION 0

with (insn 8), (insn 9) and (insn 10) initializing area, beginning at
frame-0x20. The next insns set up arguments of the call to memcpy, where
frame-0x20 is referred as source. However, when memcpy is emitted, nothing
marks its source region as used, so dse1 pass simply removes seemingly unused
initializations, leaving:

5: {r90:SI=frame:SI-0x20;clobber flags:CC;}
  REG_UNUSED flags:CC
6: r91:SI=0
7: r92:SI=0x4
   13: {r95:SI=frame:SI-0x10;clobber flags:CC;}
  REG_UNUSED flags:CC
   14: {r96:SI=frame:SI-0x20;clobber flags:CC;}
  REG_UNUSED flags:CC
   16: {sp:SI=sp:SI-0x4;clobber flags:CC;}
  REG_UNUSED flags:CC
  REG_ARGS_SIZE 0x4
   17: [--sp:SI]=0x10
  REG_ARGS_SIZE 0x8
   18: [--sp:SI]=r96:SI
  REG_DEAD r96:SI
  REG_ARGS_SIZE 0xc
   19: [--sp:SI]=r95:SI
  REG_DEAD r95:SI
  REG_ARGS_SIZE 0x10
   20: ax:SI=call [`memcpy'] argc:0x10
  REG_UNUSED ax:SI
  REG_EH_REGION 0

[Bug ipa/87615] Possible excessive compile time with -O2

[jamborm at gcc dot gnu.org]

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

--- Comment #13 from Martin Jambor  ---
Author: jamborm
Date: Sun Jan 20 20:17:02 2019
New Revision: 268107

URL: https://gcc.gnu.org/viewcvs?rev=268107&root=gcc&view=rev
Log:
Limit AA walking in IPA summary generation

2019-01-20  Martin Jambor  

PR ipa/87615
* ipa-prop.h (struct ipa_func_body_info): Replaced field aa_walked
with aa_walk_budget.
* cgraph.h (ipa_polymorphic_call_context::get_dynamic_type): Add
aa_walk_budget_p parameter.
* ipa-fnsummary.c (unmodified_parm_1): New parameter fbi.  Limit AA
walk.  Updated all callers.
(unmodified_parm): New parameter fbi, pass it to unmodified_parm_1.
(eliminated_by_inlining_prob): New parameter fbi, pass it on to
unmodified_parm.
(will_be_nonconstant_expr_predicate): New parameter fbi, removed
parameter info.  Extract info from fbi.  Pass fbi to recursive calls
and to unmodified_parm.
(phi_result_unknown_predicate): New parameter fbi, removed parameter
info, updated call to will_be_nonconstant_expr_predicate.
(param_change_prob): New parameter fbi, limit AA walking.
(analyze_function_body): Initialize aa_walk_budget in fbi.  Update
calls to various above functions.
* ipa-polymorphic-call.c (get_dynamic_type): Add aa_walk_budget_p
parameter.  Use it to limit AA walking.
* ipa-prop.c (detect_type_change_from_memory_writes): New parameter
fbi, limit AA walk.
(detect_type_change): New parameter fbi, pass it on to
detect_type_change_from_memory_writes.
(detect_type_change_ssa): Likewise.
(aa_overwalked): Removed.
(parm_preserved_before_stmt_p): Assume fbi is never NULL, stream line
accordingly, adjust to the neew AA limiting scheme.
(parm_ref_data_preserved_p): Likewise.
(ipa_compute_jump_functions_for_edge): Adjust call to
get_dynamic_type.
(ipa_analyze_call_uses): Likewise.
(ipa_analyze_virtual_call_uses): Pass fbi to detect_type_change_ssa.
(ipa_analyze_node): Initialize aa_walk_budget.
(ipcp_transform_function): Likewise.
* tree-ssa-sccvn.c (eliminate_dom_walker::eliminate_stmt): Update call
to get_dynamic_type.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/cgraph.h
trunk/gcc/ipa-fnsummary.c
trunk/gcc/ipa-polymorphic-call.c
trunk/gcc/ipa-prop.c
trunk/gcc/ipa-prop.h
trunk/gcc/tree-ssa-sccvn.c

[Bug fortran/65438] Unnecessary ptr check

[dominiq at lps dot ens.fr]

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

--- Comment #7 from Dominique d'Humieres  ---
The code removed by the patch in comment 4 is still there.

[Bug libgcc/88931] Failed to convert int128 to float/double with round=FE_UPWARD/FE_TOWARDZERO

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  ---
(In reply to Andrew Pinski from comment #1)
> You also need -frounding-math.

 The default is '-fno-rounding-math'.

 This option is experimental and does not currently guarantee to
 disable all GCC optimizations that are affected by rounding mode.
 Future versions of GCC may provide finer control of this setting
 using C99's 'FENV_ACCESS' pragma.  This command-line option will be
 used to specify the default state for 'FENV_ACCESS'.

Should "#pragma STDC FENV_ACCESS ON" enable -frounding-math?

[Bug libgcc/88931] Failed to convert int128 to float/double with round=FE_UPWARD/FE_TOWARDZERO

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
You also need -frounding-math .

[Bug c++/88501] Improve suggested alternative to be closer to typo

[jg at jguk dot org]

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

--- Comment #8 from Jonny Grant  ---


Another example - would be good if it could suggest 

$ gcc -o undef undef.c
undef.c: In function ‘main’:
undef.c:4:5: error: unknown type name ‘bool’; did you mean ‘_Bool’?
 bool a;
 ^~~~
 _Bool




int main ()
{
bool a;
a = 98;
return 0;
}

[Bug fortran/88821] Inline packing of non-contiguous arguments

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |tkoenig at gcc dot 
gnu.org

[Bug tree-optimization/88926] ivopts with some NOP conversions

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
With similar changes, I analyzed gcc.dg/vect/pr25413a.c (which we then fail to
vectorize). I expect the issue is similar. In scalar evolution, we get a
polynomial_chrec of type unsigned long wrapped in a NOP_EXPR of type long and
chrec_fold_multiply turns that into chrec_dont_know. It does print a few lines
of "Analyzing # of iterations of loop" but eventually "failed: evolution of
base is not affine". resolve_mixers has a promising comment above about not
caring about overflows, but it doesn't actually redo the analysis (the
recursion with analyze_scalar_evolution_1, interpret_gimple_assign,
interpret_rhs_expr, and most importantly the chrec_convert and
chrec_fold_multiply). Paradoxically, -fwrapv lets us vectorize... However,
-fwrapv does not help for the testcase in this PR, so maybe the 2 are different
after all.

[Bug libgcc/88931] New: Failed to convert int128 to float/double with round=FE_UPWARD/FE_TOWARDZERO

[hjl.tools at gmail dot com]

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

Bug ID: 88931
   Summary: Failed to convert int128 to float/double with
round=FE_UPWARD/FE_TOWARDZERO
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

[hjl@gnu-cfl-1 float128-5]$ cat x.c
#include 
#include 
#include 

#pragma STDC FENV_ACCESS ON
#define ROUNDING(r) { r, #r }

int
main (void)
{
  char buf[128];
  union
{
  long long ll[2];
  __int128 q;
} u = { 0xdLL, 0x8000LL };
  int i;
  struct
{
  int r;
  const char *s;
} round[] =
  {
ROUNDING (FE_DOWNWARD),
ROUNDING (FE_UPWARD),
ROUNDING (FE_TOWARDZERO),
ROUNDING (FE_TONEAREST)
  };
  for (i = 0; i < sizeof (round) / sizeof (round[0]); i++) {
fesetround(round[i].r);
float f = (float) u.q;
double d = (double) u.q;
__float128 q = (__float128) u.q;
printf("fegetround=%d: %d, %s\n",
   fegetround(), round[i].r, round[i].s);
printf("f=%f\t%x\n", f, *(int*)&f);
printf("d=%lf\t%llx\n", d,  *(long long*)&d);
quadmath_snprintf(buf, 128, "%Qf", 100, q);
printf("q=%s\t%016llx%016llx\n",
   buf, *((long long *)&q + 1), *(long long *)&q);
  }
  return 0;
}
[hjl@gnu-cfl-1 float128-5]$ make
gcc -std=c99 -fno-strict-aliasing -g-c -o x.o x.c
gcc -o x x.o -lm -lquadmath
./x
fegetround=1024: 1024, FE_DOWNWARD
f=-170141183460469231731687303715884105728.00   ff00
d=-170141183460469231731687303715884105728.00   c7e0
q=-170141183460469231731687303715884105728.00  
c07e
fegetround=2048: 2048, FE_UPWARD
f=-170141183460469231731687303715884105728.00   ff00
d=-170141183460469231731687303715884105728.00   c7e0
q=-170141183460469231731687303715884089344.00  
c07d
fegetround=3072: 3072, FE_TOWARDZERO
f=-170141183460469231731687303715884105728.00   ff00
d=-170141183460469231731687303715884105728.00   c7e0
q=-170141183460469231731687303715884089344.00  
c07d
fegetround=0: 0, FE_TONEAREST
f=-170141183460469231731687303715884105728.00   ff00
d=-170141183460469231731687303715884105728.00   c7e0
q=-170141183460469231731687303715884105728.00  
c07e
[hjl@gnu-cfl-1 float128-5]$ 

For FE_UPWARD and FE_TOWARDZERO, float should be feff and double
should be c7df.

[Bug c/88928] [9 Regression] ICE segfault in check_address_or_pointer_of_packed_member since r268075

[bernd.edlinger at hotmail dot de]

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

Bernd Edlinger  changed:

   What|Removed |Added

 CC||bernd.edlinger at hotmail dot 
de

--- Comment #2 from Bernd Edlinger  ---
(In reply to H.J. Lu from comment #1)
> We should warn:
> 
> ---
> struct a { int i; } __attribute__((__packed__));
> void c (struct a **);
> void d (const struct a *b) { c ((struct a **) b); }
> --
> 
> But should we warn 
> 
> --
> struct a { } __attribute__((__packed__));
> void c (struct a **);
> void d (const struct a *b) { c ((struct a **) b); }
> --
> 
> in C? Since "struct a" is empty, can we ever generate unaligned access
> to an empty structure?

I think we should warn, because b is aligned(1)
and the code in question passes it to struct a **, which is aligned(8)
which can get an alignment trap.

[Bug gcov-profile/88930] New: [GCOV] Wrong frequences when a if statement is after a ?: statement in gcov

[yangyibiao at nju dot edu.cn]

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

Bug ID: 88930
   Summary: [GCOV] Wrong frequences when a if statement is after a
 ?: statement in gcov
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yangyibiao at nju dot edu.cn
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
8.2.0-1ubuntu2~18.04' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 8.2.0 (Ubuntu 8.2.0-1ubuntu2~18.04)

$ cat small.c
void foo(long dx, long dy, int xi, int yi)
{
  int hints = 0;
  if (dy != 0 && (dx <= 1155)) {
hints = dy > 0 ? 2 : 1;
if (xi) {
  hints = 1;
}
  } else if (dx != 0 && (dy <= 0)) {
hints = 2;
  } else {
hints = 3;
  }
}
void main()
{
  foo(0, 18481, 1, 0);
}

$ gcc --coverage small.c; ./a.out; gcov small.c; cat small.c.gcov
File 'small.c'
Lines executed:76.92% of 13
Creating 'small.c.gcov'

-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
-:0:Programs:1
1:1:void foo(long dx, long dy, int xi, int yi)
-:2:{
1:3:  int hints = 0;
1:4:  if (dy != 0 && (dx <= 1155)) {
   1*:5:hints = dy > 0 ? 2 : 1;
2:6:if (xi) {
1:7:  hints = 1;
-:8:}
#:9:  } else if (dx != 0 && (dy <= 0)) {
#:   10:hints = 2;
-:   11:  } else {
#:   12:hints = 3;
-:   13:  }
1:   14:}
1:   15:void main()
-:   16:{
1:   17:  foo(0, 18481, 1, 0);
1:   18:}

Line #6 is wrongly marked as executed twice. However, the foo  function is call
only once and there is no loop in function foo.

[Bug c/88928] [9 Regression] ICE segfault in check_address_or_pointer_of_packed_member since r268075

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-20
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
We should warn:

---
struct a { int i; } __attribute__((__packed__));
void c (struct a **);
void d (const struct a *b) { c ((struct a **) b); }
--

But should we warn 

--
struct a { } __attribute__((__packed__));
void c (struct a **);
void d (const struct a *b) { c ((struct a **) b); }
--

in C? Since "struct a" is empty, can we ever generate unaligned access
to an empty structure?

[Bug fortran/65438] Unnecessary ptr check

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING
 CC||tkoenig at gcc dot gnu.org

--- Comment #6 from Thomas Koenig  ---
Is this still valid?

If not, maybe we can unclutter the bug database a bit.

[Bug fortran/82215] Feature request to better support two pass compiling with gfortran

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #9 from Thomas Koenig  ---
Patch can be found here:

https://gcc.gnu.org/ml/fortran/2019-01/msg00102.html

[Bug fortran/68546] passing non-contiguous associated array section garbles results

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #5 from Thomas Koenig  ---
Fixed, presumably by r268096.

[Bug fortran/34740] -fbounds-check with TRANSFER misses out of bounds in array assignment

[juergen.reuter at desy dot de]

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

Jürgen Reuter  changed:

   What|Removed |Added

 CC||juergen.reuter at desy dot de

--- Comment #2 from Jürgen Reuter  ---
Still not caught in trunk. nagfor and ifort do catch this one.

[Bug go/88927] [9 Regression] Bootstrap failure on arm in libgo starting with r268084

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Oops, ignore the cpu_no_init.go related comments, I was looking at my trunk
checkout apparently before r268084, while the failed build was with that change
which added +build !arm in there.  That explains it.

[Bug c++/88501] Improve suggested alternative to be closer to typo

[jg at jguk dot org]

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

--- Comment #7 from Jonny Grant  ---
Here is anotehr example.

I expected  to be suggested, as that contains exact match strerror()


Current G++ trunk output

: In function 'int main()':

:14:33: error: 'errno' was not declared in this scope

   14 | printf("%s\n", strerror(errno));

  | ^

:4:1: note: 'errno' is defined in header ''; did you forget to
'#include '?

3 | #include 

  +++ |+#include 

4 | int main()

:14:24: error: 'strerror' was not declared in this scope; did you mean
'perror'?

   14 | printf("%s\n", strerror(errno));

  |^~~~

  |perror

Compiler returned: 1




example
// gcc -o glibc_realpath glibc_realpath.c
#include 
#include 
int main()
{
const char * path = "/usr/bin/../include/myheader.h";

//errno = 0;
char * result = realpath(path, NULL);
printf("result: [%s]\n", result);

if(NULL == result)
{
printf("%s\n", strerror(errno));
}

return 0;
}

[Bug fortran/31009] Generate conditional code to assign arrays, depending on their stride

[juergen.reuter at desy dot de]

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

--- Comment #7 from Jürgen Reuter  ---
Seems also to me that this should be reconsidered whether there is still need
for optimization for the case of arrays not declared as contiguous.

[Bug fortran/30733] VOLATILE: Missed optimization - attribute not restricted to scope

[juergen.reuter at desy dot de]

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

Jürgen Reuter  changed:

   What|Removed |Added

 CC||juergen.reuter at desy dot de

--- Comment #3 from Jürgen Reuter  ---
There were some changes with the optimization and the volatile attribute with
release 7.0. Maybe check if this issue is still present?

[Bug fortran/30438] Set but never used variable should raise warning

[juergen.reuter at desy dot de]

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

Jürgen Reuter  changed:

   What|Removed |Added

 CC||juergen.reuter at desy dot de

--- Comment #10 from Jürgen Reuter  ---
nagfor does this warning, ifort and PGI fortran doesn't.

[Bug fortran/88929] ICE on building MPICH 3.2 with GCC 9 with ISO_Fortran_binding

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
There is a partially reduced test in pr88908 (TODO reduce the modules).

[Bug fortran/88908] [9 Regression] ICE in tree check: expected tree that contains ‘decl common’ structure, have ‘indirect_ref’ in gfc_conv_gfc_desc_to_cfi_desc, at fortran/trans-expr.c:4927

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Dominique d'Humieres  ---
The ICE is fixed by the patch for pr88929. Closing as duplicate.

*** This bug has been marked as a duplicate of bug 88929 ***

[Bug fortran/88929] ICE on building MPICH 3.2 with GCC 9 with ISO_Fortran_binding

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #3 from Dominique d'Humieres  ---
*** Bug 88908 has been marked as a duplicate of this bug. ***

[Bug fortran/30123] Document INQUIRE, especially UNFORMATTED and FORMATTED

[juergen.reuter at desy dot de]

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

Jürgen Reuter  changed:

   What|Removed |Added

 CC||juergen.reuter at desy dot de

--- Comment #4 from Jürgen Reuter  ---
This seems like one of these documentation tasks which is in principle very
easy to do but nobody is motivated to do.^^

[Bug fortran/88908] [9 Regression] ICE in tree check: expected tree that contains ‘decl common’ structure, have ‘indirect_ref’ in gfc_conv_gfc_desc_to_cfi_desc, at fortran/trans-expr.c:4927

[dominiq at lps dot ens.fr]

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

--- Comment #1 from Dominique d'Humieres  ---
This looks like a duplicate of pr88929 where a patch has been proposed.

[Bug fortran/88929] ICE on building MPICH 3.2 with GCC 9 with ISO_Fortran_binding

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #2 from Dominique d'Humieres  ---
This looks like a duplicate of pr88908.

[Bug fortran/88929] ICE on building MPICH 3.2 with GCC 9 with ISO_Fortran_binding

[pault at gcc dot gnu.org]

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

--- Comment #1 from Paul Thomas  ---
Created attachment 45469
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45469&action=edit
A proposed patch for the PR.

Handling of fortran dummy arguments was not implemented in the recent
ISO_Fortran_binding patch. The attached rectifies that omission.

Paul

[Bug fortran/88929] ICE on building MPICH 3.2 with GCC 9 with ISO_Fortran_binding

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-20
 CC||damian at sourceryinstitute 
dot or
   ||g
 Ever confirmed|0   |1

[Bug fortran/88929] New: ICE on building MPICH 3.2 with GCC 9 with ISO_Fortran_binding

[pault at gcc dot gnu.org]

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

Bug ID: 88929
   Summary: ICE on building MPICH 3.2 with GCC 9 with
ISO_Fortran_binding
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: pault at gcc dot gnu.org
  Reporter: pault at gcc dot gnu.org
  Target Milestone: ---

Reported by Damian ROuson.

During the MPICH3.2 build:

  FC   src/binding/fortran/use_mpi_f08/wrappers_f/add_error_class_f08ts.lo
/home/rouson/Builds/opencoarrays/prerequisites/downloads/mpich-3.2/src/binding/fortran/use_mpi_f08/wrappers_f/accumulate_f08ts.f90:39:0:

   39 | target_disp, target_count,
target_datatype%MPI_VAL, op%MPI_VAL, win%MPI_VAL)
  |
internal compiler error: tree check: expected tree that contains ‘decl
common’ structure, have ‘indirect_ref’ in
gfc_conv_gfc_desc_to_cfi_desc, at fortran/trans-expr.c:4927
  FC   src/binding/fortran/use_mpi_f08/wrappers_f/add_error_code_f08ts.lo
0x605269 tree_contains_struct_check_failed(tree_node const*,
tree_node_structure_enum, char const*, int, char const*)
/home/rouson/Builds/opencoarrays/prerequisites/downloads/trunk/gcc/tree.c:9983
0x75bf29 contains_struct_check(tree_node*, tree_node_structure_enum,
char const*, int, char const*)
/home/rouson/Builds/opencoarrays/prerequisites/downloads/trunk/gcc/tree.h:3290
0x75bf29 gfc_conv_gfc_desc_to_cfi_desc
/home/rouson/Builds/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans-expr.c:4927
0x755c92 gfc_conv_procedure_call(gfc_se*, gfc_symbol*,
gfc_actual_arglist*, gfc_expr*, vec*)
/home/rouson/Builds/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans-expr.c:5785
0x758d5a gfc_conv_expr(gfc_se*, gfc_expr*)
/home/rouson/Builds/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans-expr.c:8228
0x763dc1 gfc_trans_assignment_1
/home/rouson/Builds/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans-expr.c:10437
0x712047 trans_code
/home/rouson/Builds/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans.c:1822
0x7a0d83 gfc_trans_if_1
/home/rouson/Builds/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans-stmt.c:1448
0x7aac5a gfc_trans_if(gfc_code*)
/home/rouson/Builds/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans-stmt.c:1479
0x711ea7 trans_code
/home/rouson/Builds/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans.c:1910
0x74868d gfc_generate_function_code(gfc_namespace*)
/home/rouson/Builds/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans-decl.c:6526
0x6c29a6 translate_all_program_units
/home/rouson/Builds/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/parse.c:6134
0x6c29a6 gfc_parse_file()
/home/rouson/Builds/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/parse.c:6337
0x70e10f gfc_be_parse_file
/home/rouson/Builds/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/f95-lang.c:204
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[2]: *** [src/binding/fortran/use_mpi_f08/wrappers_f/accumulate_f08ts.lo]
Error 1
Makefile:38450: recipe for target
'src/binding/fortran/use_mpi_f08/wrappers_f/accumulate_f08ts.lo'
failed
make[2]: *** Waiting for unfinished jobs
make[2]: Leaving directory
'/home/rouson/Desktop/Builds/opencoarrays/prerequisites/builds/mpich-3.2'
make[1]: *** [all-recursive] Error 1
Makefile:38662: recipe for target 'all-recursive' failed
make[1]: Leaving directory
'/home/rouson/Desktop/Builds/opencoarrays/prerequisites/builds/mpich-3.2'
make: *** [all] Error 2
Makefile:10307: recipe for target 'all' failed

[Bug c/88928] New: [9 Regression] ICE segfault in check_address_or_pointer_of_packed_member since r268075

[belyshev at depni dot sinp.msu.ru]

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

Bug ID: 88928
   Summary: [9 Regression] ICE segfault in
check_address_or_pointer_of_packed_member since
r268075
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: belyshev at depni dot sinp.msu.ru
CC: hjl.tools at gmail dot com
  Target Milestone: ---

// bug.c
struct a { } __attribute__((__packed__));
void c (struct a **);
void d (const struct a *b) { c ((struct a **) b); }


$ ./cc1 -quiet bug.c 
bug.c: In function 'd':
bug.c:3:41: warning: converting a packed 'const struct a *' pointer (alignment
1) to 'struct a *' (alignment 8) may result in an unaligned pointer value
[-Waddress-of-packed-member]
3 | void d (const struct a *b) { c ((struct a **) b); }
  | ^
bug.c:3:41: internal compiler error: Segmentation fault
0x1120e22 crash_signal
../../gcc/gcc/toplev.c:326
0x7f35308e88df ???
   
/build/glibc-T8GPG6/glibc-2.28/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x81a107 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc/gcc/tree.h:3289
0x993f6f check_address_or_pointer_of_packed_member
../../gcc/gcc/c-family/c-warn.c:2762
0x9941e4 check_and_warn_address_or_pointer_of_packed_member
../../gcc/gcc/c-family/c-warn.c:2838
...