[Bug tree-optimization/94779] Bad optimization of simple switch

[gabravier at gmail dot com]

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

--- Comment #5 from Gabriel Ravier  ---
Going to take a quick look at how it gets optimized in the tree passes.

This is the first case :

int f1(unsigned x)
{
if (x >= 2)
__builtin_unreachable();

switch (x)
{
case 0:
return 1;
case 1:
return 2;
}
}

This is the case which properly compiles down to `return x + 1;`, and should be
equivalent to the other code.

The ssa tree pass ends up, early in optimization, combining some expressions
into `# _1 = PHI <_4(5), _3(6)>`
Then, phiopt1 optimizes it to `_3 = x_2(D) + 1;`, at which point the
optimization we're talking about has been made

This is the second case : 

int f1(unsigned x)
{
switch (x)
{
case 0:
return 1;
case 1:
return 2;
}
}

The ssa tree pass still combines some expressions into `# _1 = PHI <1(2),
2(3)>`
However, phiopt1 doesn't optimize into `x + 1`.

For me, this seems to be because in the first case, the tree is then this : 

f1 (unsigned int x)
{
  int _1;

   :
  if (x_2(D) > 1)
goto ; [INV]
  else
goto ; [INV]

   :
  __builtin_unreachable ();

   :
  if (x_2(D) == 1)
goto ; [INV]
  else
goto ; [INV]

   :
:

   :
  # _1 = PHI <1(4), 2(5)>
:
  return _1;

}

And in the second case, it is instead this : 

f1 (unsigned int x)
{
  int _1;

   :
  switch (x_2(D))  [INV], case 0:  [INV], case 1:  [INV]>

   :
:
  goto ; [INV]

   :
:
  __builtin_unreachable ();

   :
  # _1 = PHI <1(2), 2(3)>
:
  return _1;

}

I believe phiopt1 is unable to optimize the PHI into `x + 1` in the second case
because the `switch` hasn't been optimized away into an if yet
It eventually gets optimized by switchlower1
phiopt4 is then, again, unable to optimize the PHI into `x + 1`. The tree is
then as such : 

f1 (unsigned int x)
{
  int _1;

   [local count: 1073741824]:
  if (x_2(D) == 0)
goto ; [65.00%]
  else
goto ; [35.00%]

   [local count: 1073741824]:
  if (x_2(D) == 1)
goto ; [100.00%]
  else
goto ; [0.00%]

   [count: 0]:
:
  __builtin_unreachable ();

   [local count: 1073741824]:
  # _1 = PHI <2(3), 1(2)>
:
  return _1;

}

And then there are no further tree passes that look like they should be
relevant to this

Assuming my analysis is correct (though considering I have little to no
experience with gcc's tree system, there is a pretty big chance that my
analysis is completely wrong), I believe that to solve this, there are two
possibilities : 
- Either there is a missing tree pass that would make phiopt4 capable of
optimizing the PHI into `x_2(D) + 1`
- Or there should there be some extra code added to phiopt4 to recognise the
idiom in this case

[Bug c++/94781] version 9.3 g++ compilation time is slower by 20% or much more (closer to 50 % sometimes) in comparison to v7.

[ishikawa at yk dot rim.or.jp]

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

--- Comment #3 from ishikawa,chiaki  ---
https://send.firefox.com/download/bdf77223953903fa/#WMrJbMYdsL7AXf2vXYm82g

I uploaded the file, UnifiedBindings23-v7.cpp, to the link above.

It is huge as I explained. Approximately 28MB. 

The compiler options I used for each version of the g++ compiler is in 
the attachment: https://gcc.gnu.org/bugzilla/attachment.cgi?id=48380
 -ftime-print log for V9, V8 and V7 g++ compiler compiling preprocessed
UnifiedBindings23.cpp 

Since the file was already preprocessed, -I options won't have any meaning, but
I simply copied from the original build command.

Thank you again for your attention on this matter.

[Bug lto/94659] [8/9 Regression] Missing symbol with LTO and target_clones since r8-1461-g871cc215f7507cbe

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #7 from Martin Liška  ---
GCC 10 will be released soon, I'm not planning to do a backport.

[Bug lto/94659] [8/9 Regression] Missing symbol with LTO and target_clones since r8-1461-g871cc215f7507cbe

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Known to work||10.0
Summary|[8/9/10 Regression] Missing |[8/9 Regression] Missing
   |symbol with LTO and |symbol with LTO and
   |target_clones since |target_clones since
   |r8-1461-g871cc215f7507cbe   |r8-1461-g871cc215f7507cbe

--- Comment #6 from Martin Liška  ---
Fixed on master.

[Bug tree-optimization/94779] Bad optimization of simple switch

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|RESOLVED|REOPENED
 Resolution|INVALID |---
 Ever confirmed|0   |1
   Last reconfirmed||2020-04-27

--- Comment #4 from Martin Liška  ---
Then it's a missed optimization.

[Bug lto/94659] [8/9/10 Regression] Missing symbol with LTO and target_clones since r8-1461-g871cc215f7507cbe

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Martin Liska :

https://gcc.gnu.org/g:b9dbb436b70938ca2b1ddf0cf2d5ffe2e5725dea

commit r10-7982-gb9dbb436b70938ca2b1ddf0cf2d5ffe2e5725dea
Author: Martin Liska 
Date:   Mon Apr 27 06:44:29 2020 +0200

Do not remove ifunc_resolver in LTO.

PR lto/94659
* cgraph.h (cgraph_node::can_remove_if_no_direct_calls_and_refs_p):
Do not remove ifunc_resolvers in remove unreachable nodes in LTO.

[Bug tree-optimization/94779] Bad optimization of simple switch

[gabravier at gmail dot com]

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

--- Comment #3 from Gabriel Ravier  ---
Just fyi : When I said "gcc fails to optimize this to `return x + 1`, instead
opting for some rather weird code generation (involving `sbb` on x86)" the
"weird code generation" I was referring to is the exact one you sent and called
"fully optimized". I highly doubt this is optimal code generation over simply
adding 1 to x and returning that.

[Bug tree-optimization/94779] Bad optimization of simple switch

[gabravier at gmail dot com]

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

--- Comment #2 from Gabriel Ravier  ---
It's fully optimized ? I don't see how. This is exactly what I was complaining
about : It could be further optimized to 

leal1(%rdi), %eax
ret

but it isn't

[Bug tree-optimization/94775] [8/9/10 Regression] ICE in strip_typedefs, at cp/tree.c:1734 since r8-4668-g8a5ee94a082b3d48

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Keywords||ice-on-valid-code
   Last reconfirmed||2020-04-27
 CC||marxin at gcc dot gnu.org,
   ||msebor at gcc dot gnu.org
  Known to work||7.4.0
   Target Milestone|--- |8.5
 Status|UNCONFIRMED |NEW
  Known to fail||10.0, 8.3.0, 9.2.0
Summary|[8/9/10 Regression] ICE in  |[8/9/10 Regression] ICE in
   |strip_typedefs, at  |strip_typedefs, at
   |cp/tree.c:1734  |cp/tree.c:1734 since
   ||r8-4668-g8a5ee94a082b3d48

--- Comment #2 from Martin Liška  ---
Confirmed, started with r8-4668-g8a5ee94a082b3d48.

[Bug tree-optimization/94779] Bad optimization of simple switch

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 CC||marxin at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Martin Liška  ---
Note that each switch contains an implicit default label which is missing in
your code. So your function invokes an undefined behavior (when you use the
return value of the function) for values different from 0 and 1.
I recommend:

int f1(unsigned x)
{
switch (x)
{
case 0:
return 1;
case 1:
return 2;
default:
__builtin_unreachable ();
}
}

which is fully optimized to:

cmpl$1, %edi
movl$1, %eax
sbbl$-1, %eax
ret

[Bug c/94780] [8/9/10 Regression] ICE in walk_body at gcc/tree-nested.c:713 since r6-3632-gf6f69fb09c5f81df

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
Confirmed, started with r6-3632-gf6f69fb09c5f81df.

[Bug c/94780] [8/9/10 Regression] ICE in walk_body at gcc/tree-nested.c:713 since r6-3632-gf6f69fb09c5f81df

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Keywords||ice-on-valid-code
 Ever confirmed|0   |1
Summary|[9/10] internal compiler|[8/9/10 Regression] ICE in
   |error: Segmentation fault   |walk_body at
   ||gcc/tree-nested.c:713 since
   ||r6-3632-gf6f69fb09c5f81df
  Known to work||5.4.0
  Known to fail||10.0, 6.4.0
   Last reconfirmed||2020-04-27

[Bug c++/94781] version 9.3 g++ compilation time is slower by 20% or much more (closer to 50 % sometimes) in comparison to v7.

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||compile-time-hog
 Ever confirmed|0   |1
   Last reconfirmed||2020-04-27
 CC||marxin at gcc dot gnu.org
 Status|UNCONFIRMED |WAITING

--- Comment #2 from Martin Liška  ---
Thank you for the report. Please send the file via e.g.
https://send.firefox.com/ and we'll analyze that.

[Bug tree-optimization/94783] New: Abs-equivalent pattern is not recognized as abs

[gabravier at gmail dot com]

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

Bug ID: 94783
   Summary: Abs-equivalent pattern is not recognized as abs
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

unsigned r(int v)
{
const int mask = v >> (sizeof(int) * CHAR_BIT - 1);
return (v + mask) ^ mask;
}

This can be optimized to `return abs(v)`. This transformation is done by LLVM,
not by GCC.

Comparison here : https://godbolt.org/z/4rduiJ

[Bug ipa/94762] [8/9/10 Regression] ICE: Segmentation fault (in is_tm_irrevocable) since r7-1710-g849a76a5a20db383

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||jakub at gcc dot gnu.org
Summary|ICE: Segmentation fault (in |[8/9/10 Regression] ICE:
   |is_tm_irrevocable)  |Segmentation fault (in
   ||is_tm_irrevocable) since
   ||r7-1710-g849a76a5a20db383
   Last reconfirmed||2020-04-27
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Started to ICE with r7-1710-g849a76a5a20db383. Before that it was rejected
with:

pr94762.c:4:10: error: unsafe function call ‘__atomic_compare_exchange_4’
within ‘transaction_safe’ function
   return __atomic_compare_exchange_n (, , 0, 0, 0, 0);
  ^~

[Bug tree-optimization/94782] New: Simple multiplication-related arithmetic not optimized to direct multiplication

[gabravier at gmail dot com]

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

Bug ID: 94782
   Summary: Simple multiplication-related arithmetic not optimized
to direct multiplication
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

int f(int a, int b)
{
return (int)((a - 1U) * b) + b;
}

Can be optimized to `a * b`. LLVM does this transformation, GCC does not.

Comparison here : https://godbolt.org/z/LFJwFJ

[Bug c++/94781] version 9.3 g++ compilation time is slower by 20% or much more (closer to 50 % sometimes) in comparison to v7.

[ishikawa at yk dot rim.or.jp]

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

--- Comment #1 from ishikawa,chiaki  ---
BTW, UnifiedBindings23.cpp is huge. It is about 28MB and more than 3MB
compressed (by gzip). I can send the compressed file by e-mail to anyone
interested in this issue.

As the name suggests, the source file is a clever concatenation of source files
to avoid the duplicated processing of include files in each source file by
lumping them together and run the compiler once.

I don't know if there is a time consumer that takes non-linear time of its
input source file size in g++, but there may be...
OTOH, the "phase last asm" elapsed time may explain the most of the elapsed
time slow down, and so it should be the first target of investigation.

[Bug target/91518] [9/10 Regression] segfault when run CPU2006 465.tonto since r263875

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 from CVS Commits  ---
The master branch has been updated by Xiong Hu Luo :

https://gcc.gnu.org/g:f6955089db6c3aa63c276704159ffad1ef15d256

commit r10-7981-gf6955089db6c3aa63c276704159ffad1ef15d256
Author: Xionghu Luo 
Date:   Sun Apr 26 20:37:27 2020 -0500

rs6000: Don't use HARD_FRAME_POINTER_REGNUM if it's not live in
pro_and_epilogue (PR91518)

This bug is exposed by FRE refactor of r263875.  Comparing the fre
dump file shows no obvious change of the segment fault function proves
it to be a target issue.
frame_pointer_needed is set to true in reload pass setup_can_eliminate,
but regs_ever_live[31] is false, pro_and_epilogue uses it without live
check causing CPU2006 465.tonto segment fault of loading from invalid
addresses due to r31 not saved/restored.  Thus, add
HARD_FRAME_POINTER_REGNUM
live check with frame_pointer_needed_indeed when generating
pro_and_epilogue
instructions.

gcc/ChangeLog

2020-04-27  Xiong Hu Luo  

PR target/91518
* config/rs6000/rs6000-logue.c (frame_pointer_needed_indeed):
New variable.
(rs6000_emit_prologue_components):
Check with frame_pointer_needed_indeed.
(rs6000_emit_epilogue_components): Likewise.
(rs6000_emit_prologue): Likewise.
(rs6000_emit_epilogue): Set frame_pointer_needed_indeed.

[Bug c++/94781] New: version 9.3 g++ compilation time is slower by 20% or much more (closer to 50 % sometimes) in comparison to v7.

[ishikawa at yk dot rim.or.jp]

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

Bug ID: 94781
   Summary: version 9.3 g++ compilation time is slower by 20% or
much more (closer to 50 % sometimes)  in comparison to
v7.
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ishikawa at yk dot rim.or.jp
  Target Milestone: ---

Created attachment 48380
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48380=edit
-ftime-print log for V9, V8 and V7 g++ compiler compiling preprocessed
UnifiedBindings23.cpp

Thank you for maintaining the great package. I use GCC for PC and embedded
systems development.

I compile mozilla Thunderbird mail client source files using GCC to create
patches to fix the bugs of the mail client.

Lately, when I switched from GCC V7 to GCC v9, I noticed a great slowdown of
compilation time. I was hampered with other bugs which I sorted out and then 
the slow compilation time became very apparent.

I created a small awk script to check the compilation time of thunderbird
source files.
The following is what I found.

top 20  in terms of elapsed time for g++-7 compilation time.
 165.097862 :   UnifiedBindings23.cpp
 102.842003 :   UnifiedBindings1.cpp
 102.387905 :   Unified_cpp_dom_base2.cpp
 79.692992  :   Unified_cpp_layout_generic2.cpp
 78.299717  :   UnifiedBindings4.cpp
 78.239538  :   Unified_cpp_dom_ipc0.cpp
 77.236254  :   Unified_cpp_src_peerconnection0.cpp
 75.737330  :   UnifiedBindings12.cpp
 72.586055  :   Unified_cpp_dom_canvas0.cpp
 72.564836  :   UnifiedBindings10.cpp
 72.556511  :   UnifiedProtocols12.cpp
 71.924969  :   Unified_cpp_layout_painting0.cpp
 70.908968  :  
/NEW-SSD/NREF-COMM-CENTRAL/mozilla/dom/indexedDB/ActorsParent.cpp
 70.167488  :   UnifiedBindings3.cpp
 69.194670  :   UnifiedBindings22.cpp
 68.657080  :   UnifiedBindings21.cpp
 68.106164  :   Unified_cpp_docshell_base0.cpp
 67.494041  :   Unified_cpp_layout_base1.cpp
 65.638745  :   Unified_cpp_dom_canvas4.cpp

top 20  in terms of elapsed time for g++-9 compilation time.

Elapsed time 259.956334  :  UnifiedBindings23.cpp
Elapsed time 149.609287  :  UnifiedBindings1.cpp
Elapsed time 132.656618  :  Unified_cpp_layout_generic2.cpp
Elapsed time 125.823251  :  Unified_cpp_dom_base2.cpp
Elapsed time 113.072732  :  UnifiedBindings4.cpp
Elapsed time 107.252363  :  Unified_cpp_layout_painting0.cpp
Elapsed time 100.176409  : 
/NEW-SSD/NREF-COMM-CENTRAL/mozilla/dom/indexedDB/ActorsParent.cpp
Elapsed time 99.760067   :  UnifiedProtocols12.cpp
Elapsed time 99.549702   :  Unified_cpp_dom_canvas0.cpp
Elapsed time 99.372578   :  Unified_cpp_dom_ipc0.cpp
Elapsed time 97.947955   :  Unified_cpp_image_test_gtest0.cpp
Elapsed time 97.134518   :  UnifiedBindings21.cpp
Elapsed time 95.530481   :  UnifiedBindings3.cpp
Elapsed time 94.182883   :  UnifiedBindings12.cpp
Elapsed time 92.836375   :  Unified_cpp_src_peerconnection0.cpp
Elapsed time 92.755637   :  Unified_cpp_editor_libeditor1.cpp
Elapsed time 91.168096   :  UnifiedBindings7.cpp
Elapsed time 90.080235   :  UnifiedBindings10.cpp
Elapsed time 89.838960   :  Unified_cpp_layout_base1.cpp

You can see that the compilation time slows down by about 20 % most of the time
and 30, 50% slow down can be observed for the top two files.

I am going to show the -ftime-print output for the compilation of V9, V8, V7
g++ compiler of the same file in the attachment.
But do note that mozilla Thunderbird configure script is very clever and try to
add as many options as supported to each version of the compiler and thus,
obviously v9 compiler may be doing a bit more than other version.

Oh, yes, the slowdown has happened in v8 already (!)

In the attachment, you can see that v8 and v9 are equally slow in terms of
elapsed time.
I can see that "phase last asm" has large elapsed time for v8 and v9 in
comparison to v7. Otherwise, I could not see a clear smoking gun.

The elapsed time of v7 and V9 arey  133 and  159sec for UnifiedBindings23.cpp
(prepressed). But this difference is obviously inflated in real world workload
when the compilation is run in parallel with "make -j6" in a 7 hypercore
VirtualBox image.

In any case, a single thread run has about 26 second difference which is about
20% slower already. Any possible hint or fix for speedup is appreciated.
The compilation time slowdown hurts.: now building thunderbird in my spare time
is a one night job after modifying a few source file. I used to check the
behavior of modified binary before going to bed at least shortly and let a test
suite run.  I can't do that any more. Any checking needs to be done the next
day...

[Bug c/94780] New: [9/10] internal compiler error: Segmentation fault

[anbu1024.me at gmail dot com]

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

Bug ID: 94780
   Summary: [9/10] internal compiler error: Segmentation fault
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anbu1024.me at gmail dot com
  Target Milestone: ---

$ cat reduced.c 

_Atomic double x ;

void foo ( void ) 
{ 

x = 1 ; 

for ( int i = 0 ; i < 1 ; i ++ ) 
{ 
double y = x /= 3 ; 
unsigned int bar (int s) { return  s;}
}
}



$ gcc-10 --version
gcc (GCC) 10.0.1 20200419 (experimental)
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.



$ gcc-10 reduced.c 
reduced.c: In function ‘foo’:
reduced.c:5:6: internal compiler error: Segmentation fault
5 | void foo ( void )
  |  ^~~
0xdab3ef crash_signal
../../gcc-10-20200419/gcc/toplev.c:328
0x7f6b59 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc-10-20200419/gcc/tree.h:3400
0xe4eb96 convert_nonlocal_reference_op
../../gcc-10-20200419/gcc/tree-nested.c:1065
0x1069c5a walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
../../gcc-10-20200419/gcc/tree.c:11996
0xae7c94 walk_gimple_op(gimple*, tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc-10-20200419/gcc/gimple-walk.c:268
0xae7d6c walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc-10-20200419/gcc/gimple-walk.c:596
0xae7f00 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc-10-20200419/gcc/gimple-walk.c:51
0xae7df1 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc-10-20200419/gcc/gimple-walk.c:686
0xae7f00 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc-10-20200419/gcc/gimple-walk.c:51
0xae7df1 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc-10-20200419/gcc/gimple-walk.c:686
0xae7f00 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc-10-20200419/gcc/gimple-walk.c:51
0xae7df1 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc-10-20200419/gcc/gimple-walk.c:686
0xae7f00 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc-10-20200419/gcc/gimple-walk.c:51
0xe4a324 walk_body
../../gcc-10-20200419/gcc/tree-nested.c:713
0xe4a324 walk_function
../../gcc-10-20200419/gcc/tree-nested.c:724
0xe4a324 walk_all_functions
../../gcc-10-20200419/gcc/tree-nested.c:789
0xe50788 lower_nested_functions(tree_node*)
../../gcc-10-20200419/gcc/tree-nested.c:3551
0x96060c cgraph_node::analyze()
../../gcc-10-20200419/gcc/cgraphunit.c:676
0x9633f7 analyze_functions
../../gcc-10-20200419/gcc/cgraphunit.c:1227
0x963fc2 symbol_table::finalize_compilation_unit()
../../gcc-10-20200419/gcc/cgraphunit.c:2974
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.



$ gcc-9 --version
gcc (GCC) 9.2.1 20191102
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.



$ gcc-9 reduced.c 
reduced.c: In function ‘foo’:
reduced.c:5:6: internal compiler error: Segmentation fault
5 | void foo ( void )
  

[Bug c++/90320] [8/9 Regression] Explicit constructor called implicitly

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

Summary|[8/9/10 Regression] |[8/9 Regression] Explicit
   |Explicit constructor called |constructor called
   |implicitly  |implicitly

--- Comment #7 from Marek Polacek  ---
Fixed on trunk so far.  I'm considering backporting the fix to 9 too.

[Bug c++/90320] [8/9/10 Regression] Explicit constructor called implicitly

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Marek Polacek :

https://gcc.gnu.org/g:feb801f62239528bca2cfb6c3abd70d434b69c0a

commit r10-7979-gfeb801f62239528bca2cfb6c3abd70d434b69c0a
Author: Marek Polacek 
Date:   Wed Apr 22 20:12:47 2020 -0400

c++: Explicit constructor called in copy-initialization [PR90320]

This test is rejected with a bogus "use of deleted function" error
starting with r225705 whereby convert_like_real/ck_base no longer
sets LOOKUP_ONLYCONVERTING for user_conv_p conversions.  This does
not seem to be always correct.  To recap, when we have something like
T t = x where T is a class type and the type of x is not T or derived
from T, we perform copy-initialization, something like:
  1. choose a user-defined conversion to convert x to T, the result is
 a prvalue,
  2. use this prvalue to direct-initialize t.

In the second step, explicit constructors should be considered, since
we're direct-initializing.  This is what r225705 fixed.

In this PR we are dealing with the first step, I think, where explicit
constructors should be skipped.  [over.match.copy] says "The converting
constructors of T are candidate functions" which clearly eliminates
explicit constructors.  But we also have to copy-initialize the argument
we are passing to such a converting constructor, and here we should
disregard explicit constructors too.

In this testcase we have

  V v = m;

and we choose V::V(M) to convert m to V.  But we wrongly choose
the explicit M::M(M&) to copy-initialize the argument; it's
a better match for a non-const lvalue than the implicit M::M(const M&)
but because it's explicit, we shouldn't use it.

When convert_like is processing the ck_user conversion -- the convfn is
V::V(M) -- it can see that cand->flags contains LOOKUP_ONLYCONVERTING,
but then when we're in build_over_call for this convfn, we have no way
to pass the flag to convert_like for the argument 'm', because convert_like
doesn't take flags.  Fixed by creating a new conversion flag, copy_init_p,
set in ck_base/ck_rvalue to signal that explicit constructors should be
skipped.

LOOKUP_COPY_PARM looks relevant, but again, it's a LOOKUP_* flag, so
can't pass it to convert_like.  DR 899 also seemed related, but that
deals with direct-init contexts only.

PR c++/90320
* call.c (struct conversion): Add copy_init_p.
(standard_conversion): Set copy_init_p in ck_base and ck_rvalue
if FLAGS demands LOOKUP_ONLYCONVERTING.
(convert_like_real) : If copy_init_p is set, or
LOOKUP_ONLYCONVERTING into FLAGS.

* g++.dg/cpp0x/explicit13.C: New test.
* g++.dg/cpp0x/explicit14.C: New test.

[Bug d/89418] D test cases fail on powerpc64le

[ibuclaw at gdcproject dot org]

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

--- Comment #5 from Iain Buclaw  ---
For now, I've the tests will return UNSUPPORTED, as they depend on full
libphobos support that powerpc* targets simply don't have (because of
incomplete or lacking any support in std.math and std.internal.gammafunctions).

[Bug d/94777] internal compiler error: in assign_temp, at function.c:984

[ibuclaw at gdcproject dot org]

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

Iain Buclaw  changed:

   What|Removed |Added

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

--- Comment #2 from Iain Buclaw  ---
Fixed on master.

[Bug d/94777] internal compiler error: in assign_temp, at function.c:984

[cvs-commit at gcc dot gnu.org]

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Iain Buclaw :

https://gcc.gnu.org/g:2370bdbb0b29b14401d8508d846c0e01c64d82fc

commit r10-7975-g2370bdbb0b29b14401d8508d846c0e01c64d82fc
Author: Iain Buclaw 
Date:   Sun Apr 26 23:39:32 2020 +0200

d: Fix ICE in assign_temp, at function.c:984 (PR94777)

Named arguments were being passed around by invisible reference, just
not variadic arguments.  There is a need to de-duplicate the routines
that handle declaration/parameter promotion and reference checking.
However for now, the parameter helper functions have just been renamed
to parameter_reference_p and parameter_type, to make it more clear that
it is the Parameter equivalent to declaration_reference_p and
declaration_type.

On writing the tests, a forward-reference bug was discovered on x86_64
during va_list type semantic.  This was due to fields not having their
parent set-up correctly.

gcc/d/ChangeLog:

PR d/94777
* d-builtins.cc (build_frontend_type): Set parent for generated
fields of built-in types.
* d-codegen.cc (argument_reference_p): Rename to ...
(parameter_reference_p): ... this.
(type_passed_as): Rename to ...
(parameter_type): ... this.  Make TREE_ADDRESSABLE types restrict.
(d_build_call): Move handling of non-POD types here from ...
* d-convert.cc (convert_for_argument): ... here.
* d-tree.h (argument_reference_p): Rename declaration to ...
(parameter_reference_p): ... this.
(type_passed_as): Rename declaration to ...
(parameter_type): ... this.
* types.cc (TypeVisitor::visit (TypeFunction *)): Update caller.

gcc/testsuite/ChangeLog:

PR d/94777
* gdc.dg/pr94777a.d: New test.
* gdc.dg/pr94777b.d: New test.

[Bug d/89418] D test cases fail on powerpc64le

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Iain Buclaw :

https://gcc.gnu.org/g:873b5de87c3186d85bb497b0f9c13b8c5e425712

commit r10-7976-g873b5de87c3186d85bb497b0f9c13b8c5e425712
Author: Iain Buclaw 
Date:   Mon Apr 27 01:43:34 2020 +0200

d: Merge upstream dmd f8a1a5153, druntime 2b5c0b27

Adds a new test directive COMPILABLE_MATH_TEST, and support has been
added for it in gdc-convert-test so that they are skipped if phobos is
not present on the target.

Only change in D runtime is a small documentation fix.

Reviewed-on: https://github.com/dlang/druntime/pull/3067
 https://github.com/dlang/dmd/pull/11060

gcc/testsuite/ChangeLog:

PR d/89418
* lib/gdc-utils.exp (gdc-convert-test): Add dg-skip-if for
compilable
tests that depend on the phobos standard library.

[Bug tree-optimization/94779] New: Bad optimization of simple switch

[gabravier at gmail dot com]

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

Bug ID: 94779
   Summary: Bad optimization of simple switch
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

int f1(unsigned x)
{
switch (x)
{
case 0:
return 1;
case 1:
return 2;
}
}

gcc fails to optimize this to `return x + 1`, instead opting for some rather
weird code generation (involving `sbb` on x86). However, adding this :

 if (x >= 2)
__builtin_unreachable();

at the beginning of the function makes it be optimized properly. Maybe this is
a sign of the `x >= 2` condition being always false (due to it leading to UB)
being found too late ?

[Bug target/94770] class with empty base passed incorrectly with -std=c++17 on mingw

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
(In reply to Bence Szabó from comment #4)
> As a remark for 'same code with -std=c++14 and -std=c++17 here', I can
> confirm, the example you provided also produces same assembly for me in
> c++14 and c++17.
> Also compiling t032 with only c++14 or only c++17 still results in a failing
> test case (30.71) and then a crash. Maybe this is not the same abi problem?

Ah, then it is not c++14 vs. c++17 ABI incompatibility, but some bug in va_arg
passing of such classes for mingw.

[Bug c/94773] Unhelpful warning "right shift count >= width of type [-Wshift-count-overflow]" on unreachable code.

[nisse at lysator dot liu.se]

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

Niels Möller  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Niels Möller  ---
(In reply to Vincent Lefèvre from comment #1)
> Dup of PR4210?

Yes, it seems to be the same problem.

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

[Bug middle-end/4210] should not warning with dead code

[nisse at lysator dot liu.se]

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

Niels Möller  changed:

   What|Removed |Added

 CC||nisse at lysator dot liu.se

--- Comment #31 from Niels Möller  ---
*** Bug 94773 has been marked as a duplicate of this bug. ***

[Bug target/94770] class with empty base passed incorrectly with -std=c++17 on mingw

[sbence92 at gmail dot com]

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

--- Comment #4 from Bence Szabó  ---
As a remark for 'same code with -std=c++14 and -std=c++17 here', I can confirm,
the example you provided also produces same assembly for me in c++14 and c++17.
Also compiling t032 with only c++14 or only c++17 still results in a failing
test case (30.71) and then a crash. Maybe this is not the same abi problem?

[Bug target/94770] class with empty base passed incorrectly with -std=c++17 on mingw

[sbence92 at gmail dot com]

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

--- Comment #3 from Bence Szabó  ---
Created attachment 48379
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48379=edit
t032

[Bug target/94770] class with empty base passed incorrectly with -std=c++17 on mingw

[sbence92 at gmail dot com]

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

--- Comment #2 from Bence Szabó  ---
Yes there's a T(30,struct{}a[1];,) in t032.
Indeed the fail happens on a variadic function (void check30va(int i, ...)).

I dig in some more and it turns out all the tests listed crash. I've attached
the formated preprocessed source for t032.

[Bug fortran/91862] [9/10 Regression] ICE in fold_convert_loc, at fold-const.c:2394

[anlauf at gcc dot gnu.org]

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

--- Comment #4 from anlauf at gcc dot gnu.org ---
Replacing

  character(3) :: a(3) = 'abc'

by

  character(3), parameter :: a(3) = 'abc' ! No ICE

also avoids the ICE.

[Bug fortran/93794] [8/9/10 Regression] ICE in gfc_conv_component_ref, at fortran/trans-expr.c:2497

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #4 from anlauf at gcc dot gnu.org ---
(In reply to Paul Thomas from comment #2)
> Created attachment 47944 [details]
> Patch for the PR
> 
> The test below does the right thing and the code is as expected.
> 
> Paul
> 
> program p
>type t
>   character(:), pointer :: a
>end type
>type(t) :: z
>character(4), target :: c = 'abcd'
>z%a => c
>associate (y => z%a)
>   print *, y
>end associate
> end

Paul,

are you still working on this?

[Bug fortran/93340] [8/9/10 Regression] ICE in check_constant_initializer, at fortran/trans-decl.c:5450

[anlauf at gcc dot gnu.org]

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

--- Comment #4 from anlauf at gcc dot gnu.org ---
AFAICS the code in comment#0 is non-standard:

% gfc-trunk foo.f90 -std=f2018
z1.f90:2:20:

2 |character c(2) /'a', 'b'(1:1)/
  |1
Error: GNU Extension: Old-style initialization at (1)
z1.f90:3:20:

3 |character d(2) /'a', 'bc'(1:1)/
  |1
Error: GNU Extension: Old-style initialization at (1)

[Bug fortran/93834] [8/9/10 Regression] ICE in trans_caf_is_present, at fortran/trans-intrinsic.c:8469

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code

--- Comment #3 from anlauf at gcc dot gnu.org ---
AFAICT this is invalid code.

[Bug c++/94772] [10 Regression] constructing constexpr variables fail with delegated constexpr constructors

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #2 from Patrick Palka  ---
Created attachment 48378
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48378=edit
patch in testing

I am testing the attached patch.

[Bug jit/94778] New: All jit tests failed with multilib

[hjl.tools at gmail dot com]

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

Bug ID: 94778
   Summary: All jit tests failed with multilib
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: jit
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

On Linux/x86-64, all jit tests failed with

$ make check RUNTESTFLAGS="--target_board='unix{-m32,}'"
...
spawn -ignore SIGHUP
/export/users/hjl/build/gnu/tools-build/gcc-x32-d-gitlab/build-x86_64-linux/gcc/xgcc
-B/export/users/hjl/build/gnu/tools-build/gcc-x32-d-gitlab/build-x86_64-linux/gcc/
/export/gnu/import/git/gitlab/x86-gcc/gcc/testsuite/jit.dg/test-error-get-type-bad-enum.c
-m32 -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never
-I/export/gnu/import/git/gitlab/x86-gcc/gcc/testsuite/../jit -lgccjit -g -Wall
-Werror -Wl,--export-dynamic -fgnu89-inline -lm -o
test-error-get-type-bad-enum.c.exe
/usr/local/bin/ld: skipping incompatible
/export/users/hjl/build/gnu/tools-build/gcc-x32-d-gitlab/build-x86_64-linux/gcc/libgccjit.so
when searching for -lgccjit
/usr/local/bin/ld: cannot find -lgccjit
/usr/local/bin/ld: skipping incompatible
/export/users/hjl/build/gnu/tools-build/gcc-x32-d-gitlab/build-x86_64-linux/gcc/libgccjit.so
when searching for -lgccjit
collect2: error: ld returned 1 exit status
compiler exited with status 1
FAIL: jit.dg/test-error-get-type-bad-enum.c, initial compilation

[Bug c/94773] Unhelpful warning "right shift count >= width of type [-Wshift-count-overflow]" on unreachable code.

[vincent-gcc at vinc17 dot net]

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

Vincent Lefèvre  changed:

   What|Removed |Added

 CC||vincent-gcc at vinc17 dot net

--- Comment #1 from Vincent Lefèvre  ---
Dup of PR4210?

[Bug tree-optimization/94775] [8/9/10 Regression] ICE in strip_typedefs, at cp/tree.c:1734

[zhroma at gcc dot gnu.org]

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

--- Comment #1 from Roman Zhuykov  ---
Additionally checked that vanilla gcc-9.3.0 version is also affected.

[Bug c++/94752] [coroutines] compiler ICE with coroutine with unnamed parameter

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Iain D Sandoe :

https://gcc.gnu.org/g:29f55115583a0dab6cbac749c4f0804fd88e9536

commit r10-7973-g29f55115583a0dab6cbac749c4f0804fd88e9536
Author: Iain Sandoe 
Date:   Sun Apr 26 19:34:50 2020 +0100

coroutines: Do not assume parms are named [PR94752].

Parameters to user-defined coroutines might be unnamed.
In that case, we must synthesize a name for the coroutine
frame copy.

gcc/cp/ChangeLog:

2020-04-26  Iain Sandoe  

PR c++/94752
* coroutines.cc (morph_fn_to_coro): Ensure that
unnamed function params have a usable and distinct
frame field name.

gcc/testsuite/ChangeLog:

2020-04-26  Iain Sandoe  

PR c++/94752
* g++.dg/coroutines/pr94752.C: New test.

[Bug fortran/94769] Possible use of uninitialized variable num

[sch...@linux-m68k.org]

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

--- Comment #2 from Andreas Schwab  ---
compare_to_allowed_values doesn't set *num most of the time even when returning
non-zero, especially if warn is true.

[Bug fortran/94769] Possible use of uninitialized variable num

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
Looks like a false positive.  As you observe, num is set
in a previous line code.  You can set it to any value you
want.  A better option would be to have the option, which
causes the false positive, fixed or removed from the
command line.

[Bug d/94777] New: internal compiler error: in assign_temp, at function.c:984

[ibuclaw at gdcproject dot org]

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

Bug ID: 94777
   Summary: internal compiler error: in assign_temp, at
function.c:984
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ibuclaw at gdcproject dot org
  Target Milestone: ---

Non-POD structs passed as variadic arguments are not passed by reference as
they should be.

0x685f5f assign_temp(tree_node*, int, int)
../../gcc/function.c:984
0x9cc77a initialize_argument_information
../../gcc/calls.c:2416
0x9cc77a expand_call(tree_node*, rtx_def*, int)
../../gcc/calls.c:3958
0xaff55b expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.c:11135
0x9df308 expand_expr
../../gcc/expr.h:282
0x9df308 expand_call_stmt
../../gcc/cfgexpand.c:2703
0x9df308 expand_gimple_stmt_1
../../gcc/cfgexpand.c:3682
0x9df308 expand_gimple_stmt
../../gcc/cfgexpand.c:3847
0x9e38ea expand_gimple_basic_block
../../gcc/cfgexpand.c:5887
0x9e5a87 execute
../../gcc/cfgexpand.c:6542
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug lto/94776] New: lto1: internal compiler error: in add_symbol_to_partition_1, at lto/lto-partition.c:153

[michal314314 at gmail dot com]

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

Bug ID: 94776
   Summary: lto1: internal compiler error: in
add_symbol_to_partition_1, at lto/lto-partition.c:153
   Product: gcc
   Version: lto
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: michal314314 at gmail dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

The setup and projects being compiled are the same as in bug 94156 (just newer
commits), however this time instead of getting linker symbol-related errors the
linker crashes.

link command:
C:\mingw64\mingw64\bin\gcc-ar.exe cr CMakeFiles\filter_spirit_gui.dir/objects.a
CMakeFiles/filter_spirit_gui.dir/main.cpp.obj
C:\mingw64\mingw64\bin\g++.exe -O3 -DNDEBUG -flto -fno-fat-lto-objects  
-Wl,--whole-archive CMakeFiles\filter_spirit_gui.dir/objects.a
-Wl,--no-whole-archive  -o ..\..\bin\filter_spirit_gui.exe
-Wl,--out-implib,..\..\bin\libfilter_spirit_gui.dll.a
-Wl,--major-image-version,0,--minor-image-version,0 -LC:/usr/include/../bin 
../../bin/libfilter_spirit.dll.a ../../bin/libelements.a
C:/mingw64/mingw64/lib/libssl.dll.a 
C:/mingw64/mingw64/lib/libboost_filesystem-mt.dll.a -lcurl -latomic
C:/usr/lib/libcairo.dll.a C:/usr/lib/libfontconfig.dll.a
C:/usr/lib/libfreetype.dll.a C:/usr/lib/libpng16.dll.a
C:/mingw64/mingw64/lib/libz.dll.a C:/mingw64/mingw64/lib/libbz2.dll.a -lpthread
-lws2_32 -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32
-luuid -lcomdlg32 -ladvapi32


Full output:
lto1.exe: internal compiler error: in add_symbol_to_partition_1, at
lto/lto-partition.c:153
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


My toolchain:
$ g++ -v
Using built-in specs.
COLLECT_GCC=C:\mingw64\mingw64\bin\g++.exe
COLLECT_LTO_WRAPPER=C:/mingw64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.1/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-git/configure --prefix=/mingw64
--with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32
--host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32
--with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include
--libexecdir=/mingw64/lib --enable-bootstrap --with-arch=x86-64
--with-tune=nocona --enable-languages=c,lto,c++ --enable-shared --enable-static
--enable-threads=mcf --enable-graphite --enable-fully-dynamic-string
--enable-libstdcxx-time=yes --disable-libstdcxx-pch --disable-libstdcxx-debug
--enable-libstdcxx-filesystem-ts=yes --disable-isl-version-check --enable-lto
--enable-libgomp --disable-multilib --enable-checking=release --disable-rpath
--disable-win32-registry --enable-nls --disable-werror --disable-symvers
--with-libiconv --with-system-zlib --with-gmp=/mingw64 --with-mpfr=/mingw64
--with-mpc=/mingw64 --with-isl=/mingw64 --with-pkgversion='GCC with MCF thread
model, built by LH_Mouse.' --with-bugurl=https://gcc-mcf.lhmouse.com/
--with-gnu-as --with-gnu-ld --disable-tls --enable-plugin
Thread model: mcf
gcc version 9.2.1 20200225 (GCC with MCF thread model, built by LH_Mouse.)
$ ld --version
GNU ld (GNU Binutils) 2.33.1
$ cmake --version
cmake version 3.16.4

I have successfuly used -save-temps option but unfortunately both created
temporary files are huge (main.s is 1.5MB, main.ii is 7.2MB) which is beyond
allowed attachment size.

This issue is hard to reproduce on different commits (probably due to all
optimizations taking place) and only appears when link time optimization is
used. Please guide me if I can help in any way with reproducing this problem.
Right now it happens on a small hello world main.cpp that uses 2 libraries, but
unfortunately both use a ton of boost which significantly increases the amount
of actual code in the compiled translation unit.

[Bug tree-optimization/94775] New: [8/9/10 Regression] ICE in strip_typedefs, at cp/tree.c:1734

[zhroma at gcc dot gnu.org]

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

Bug ID: 94775
   Summary: [8/9/10 Regression] ICE in strip_typedefs, at
cp/tree.c:1734
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhroma at gcc dot gnu.org
  Target Milestone: ---

At least ubuntu v8.3.0 and trunk v10.0.1 (20200402) ICE on Linux x86-64 with
the following reduced testcase while emitting diagnostic:

$ cat bug.ii
template  using a = int;
template  using b = int;
typedef char d;
template  using e = int;
template  struct h { using i = b>, e>; };
template  using j = typename h::i;
long ab, k, aj;
const d l[]{};
class m {
public:
  m(int);
};
class n {
  m ad() const;
  template  void o(long) const {
using c __attribute__((aligned(1))) = const ae;
  }
  long p;
  template 
  auto s(unsigned long, unsigned long, unsigned long, unsigned long) const;
  template  auto q(unsigned long, unsigned long) const;
};
template 
auto n::s(unsigned long, unsigned long, unsigned long, unsigned long t) const {
  o(p);
  return t;
}
template  auto n::q(unsigned long p1, unsigned long p2) const {
  using r = j<4, false>;
  using ai = j<4, g>;
  return s(ab, k, p1, p2);
}
m n::ad() const {
  long f(l[aj]);
  m(q(8, f));
}

$ g++ -std=c++17 -Wall -O2 -c -fsanitize=address bug.ii
bug.ii: In member function 'void n::o(long int) const':
bug.ii:16:11: warning: typedef 'using c = const ae' locally defined but not
used [-Wunused-local-typedefs]
   16 | using c __attribute__((aligned(1))) = const ae;
  |   ^
bug.ii: In member function 'm n::ad() const':
bug.ii:36:1: warning: no return statement in function returning non-void
[-Wreturn-type]
   36 | }
  | ^
'
during GIMPLE pass: vrp
in strip_typedefs, at cp/tree.c:1734
   33 | m n::ad() const {
  |   ^
0x9b4eeb strip_typedefs(tree_node*, bool*, unsigned int)
...

7.5.0 seems to work fine.

[Bug target/94770] class with empty base passed incorrectly with -std=c++17 on mingw

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Does
gcc/testsuite/g++/g++.dg-struct-layout-1/t032_test.h
in build directory contain
T(30,struct{}a[1];,)
?  Failure 71 suggests different parameter passing on something like:
void foo (int, ...);
struct empty_base {};
struct S : public empty_base { struct{}a[1]; };
S s, a[5];

void
bar ()
{
  foo (1, 1.0, s, 2LL, a[2], a[2]);
}
but my cross-compiler generates the same code with -std=c++14 and -std=c++17
here.

[Bug middle-end/94774] New: Uninitialized variable retval in function try_substitute_return_value

[stefansf at linux dot ibm.com]

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

Bug ID: 94774
   Summary: Uninitialized variable retval in function
try_substitute_return_value
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stefansf at linux dot ibm.com
  Target Milestone: ---

Created attachment 48377
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48377=edit
If SAFE then retval was initialised

While bootstrapping GCC on S/390 the following warning/error gets thrown:

gcc/gimple-ssa-sprintf.c: In function 'bool
handle_printf_call(gimple_stmt_iterator*, const vr_values*)':   
gcc/gimple-ssa-sprintf.c:4184:8: error: '*((void*)& retval +8)' may be used
uninitialized in this function [-Werror=maybe-uninitialized]
 4183 |&& (retval[0] < target_int_max ()
  |   ~~
 4184 |&& retval[1] < target_int_max ()))
  |^
gcc/gimple-ssa-sprintf.c:4123:26: note: '*((void*)& retval +8)' was declared
here
 4123 |   unsigned HOST_WIDE_INT retval[2];
  |  ^~
gcc/gimple-ssa-sprintf.c:4214:14: error: 'retval' may be used uninitialized in
this function [-Werror=maybe-uninitialized]
 4214 |  fprintf (dump_file, "  %s %s-bounds return value "
  |  ^~
 4215 |HOST_WIDE_INT_PRINT_UNSIGNED ".\n",
  |~~~
 4216 |what, inbounds, retval[0]);
  |~~
gcc/gimple-ssa-sprintf.c:4123:26: note: 'retval' was declared here
 4123 |   unsigned HOST_WIDE_INT retval[2];
  |  ^~

The attached patch fixes this for me. Otherwise, one could also just initialize
array retval which may be more appropriate?

[Bug c/94773] New: Unhelpful warning "right shift count >= width of type [-Wshift-count-overflow]" on unreachable code.

[nisse at lysator dot liu.se]

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

Bug ID: 94773
   Summary: Unhelpful warning "right shift count >= width of type
[-Wshift-count-overflow]" on unreachable code.
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nisse at lysator dot liu.se
  Target Milestone: ---

Consider the following program:

---8<--
/* To avoid including limits.h */
#define CHAR_BIT 8 

unsigned 
shift(unsigned x)
{
  if (sizeof(unsigned) * CHAR_BIT > 32)
return x >> 32;
  else
return x >> 1;
}
---8<---

I compile this on a debian gnu/linux machine, x86_64, where char is 8 bits and
int is 32 bits, and hence the if condition is false. I think the function shift
above is well defined C, even if it has a peculiar dependency on the
architecture's word size.

When compiled with -Wall, I get a warning message on the shift which is in an
unreachable branch of the code: 

$ gcc-10 --version
gcc-10 (Debian 10-20200418-1) 10.0.1 20200418 (experimental) [master revision
27c171775ab:4c277008be0:c5bac7d127f288fd2f8a1f15c3f30da5903141c6]
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ gcc-10 -O -Wall -c rshift-warning.c 
rshift-warning.c: In function ‘shift’:
rshift-warning.c:8:14: warning: right shift count >= width of type
[-Wshift-count-overflow]
8 | return x >> 32;
  |  ^~

I get the same warning (just different formatting) with gcc-8.3.0.

I consider the warning unhelpful, since the code is unreachable precisely
because the outer if statement determines that the shift isn't valid. I mean,
if I did 

  if (CHAR_BIT != 8) return x / (CHAR_BIT - 8);

I wouldn't want to get a warning that the division by the constant zero is
invalid. I agree the minimal example is a bit silly, so I can't argue strongly
that the warning is unhelpful based on just this example. 

The actual code where I encountered the problem was the umul_ppmm macro in
mini-gmp. It's defined at
https://gmplib.org/repo/gmp/file/f4c89b9840ba/mini-gmp/mini-gmp.c#l132 and the
first few lines look like this:

#define gmp_umul_ppmm(w1, w0, u, v) \
  do {  \
int LOCAL_GMP_LIMB_BITS = GMP_LIMB_BITS;\
if (sizeof(unsigned int) * CHAR_BIT >= 2 * GMP_LIMB_BITS)   \
  { \
unsigned int __ww = (unsigned int) (u) * (v);   \
w0 = (mp_limb_t) __ww;  \
w1 = (mp_limb_t) (__ww >> LOCAL_GMP_LIMB_BITS); \
  } \

Gcc doesn't warn for this, but that's because there's a workaround, the
LOCAL_GMP_LIMB_BITS variable. For some reason that suppresses the warning. But
if I try to simplify this by deleting LOCAL_GMP_LIMB_BITS and instead use
GMP_LIMB_BITS in the shift expression, I get the same warning as in the minimal
example above, for every expansion of the macro. In my environment,
sizeof(unsigned int) == 4, CHAR_BIT == 8, GMP_LIMB_BITS == 64, and mp_limb_t is
an alias for unsigned long.

For context, it's possible to make this code reachable by changing the way
mini-gmp is compiled, e.g., making mp_limb_t an alias for unsigned char, and
defining GMP_LIMB_BITS == 8. The purpose of the if statement is to use portable
C to determine, at compile time, if unsigned int is large enough to be used to
temporarily hold a number of bit size 2*GMP_LIMB_BITS, in which case the
following code block is correct.

BTW, if the example is written using a conditional expression instead of a
conditional statement,

  unsigned 
  shift(unsigned x)
  {
return (sizeof(unsigned) * CHAR_BIT > 32? x >> 32 : x >> 1);
  }

it does *not* trigger a warning (gcc-8.3 and gcc-10 behave the same). But that
kind of rewrite is not an option for the code I'm really interested in.

[Bug c++/94772] [10 Regression] constructing constexpr variables fail with delegated constexpr constructors

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Last reconfirmed||2020-04-26
 Status|UNCONFIRMED |NEW
   Target Milestone|--- |10.0
 Ever confirmed|0   |1
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Started with r10-7490-g76f09260b7eccd6c3cfa3dcf3c22897fe12a8065

[Bug fortran/94737] BIND(C) names are not always treated as case sensitive.

[tkoenig at gcc dot gnu.org]

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

--- Comment #8 from Thomas Koenig  ---
So, test case committed.

Thanks for the bug report!  Even though it turned out to be invalid,
it still ended up making the compiler better.

[Bug fortran/94737] BIND(C) names are not always treated as case sensitive.

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Thomas Kथà¤nig :

https://gcc.gnu.org/g:870923cd48e1e715120ff68425437e5b346283a1

commit r10-7972-g870923cd48e1e715120ff68425437e5b346283a1
Author: Thomas Koenig 
Date:   Sun Apr 26 14:57:16 2020 +0200

Added test case from PR 94737.

2020-04-26  Thomas Koenig  

PR fortran/94737
* gfortran.dg/binding_label_tests_34.f90: New test case.

[Bug fortran/93956] Wrong array creation with p => array_dt(1:n)%component

[cvs-commit at gcc dot gnu.org]

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

--- Comment #13 from CVS Commits  ---
The master branch has been updated by Thomas Kथà¤nig :

https://gcc.gnu.org/g:2bf7698e0d2312410e7aaab5ee8447e25d8bf8a6

commit r10-7971-g2bf7698e0d2312410e7aaab5ee8447e25d8bf8a6
Author: Thomas Koenig 
Date:   Sun Apr 26 14:51:01 2020 +0200

Add ChangeLog changes from previous commit, r10-7920.

PR fortran/93956

[Bug fortran/94737] BIND(C) names are not always treated as case sensitive.

[tkoenig at gcc dot gnu.org]

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

--- Comment #6 from Thomas Koenig  ---
(In reply to Lee Busby from comment #4)
> (In reply to kargl from comment #3)
> > (In reply to Thomas Koenig from comment #2)
> > > Correction, this is not a regression.
> > > 
> > > F2018 has, in 19.2, paragraph 2
> > > 
> > > # The global identifier of an entity shall not be the same as the global
> > > # identifier of any other entity. Furthermore, a binding label shall not
> > > # be the same as the global identifier of any other global entity,
> > > # ignoring differences in case.
> > > 
> > > So, the error message is correct, and you need to change your
> > > program accordingly.
> > 
> > Good catch, Thomas!
> > 
> > In hindsight, the restriction makes prefect sense given 
> > Fortran is a case insensitive language.
> 
> I don't have any particular problem using 19.2 to make this a feature, not a
> bug.  Clarity is always better. I wonder how does 19.2 square with 8.5.5,
> lines 13-14:
> 
>   # If the value of the [NAME=scalar-character-constant] is [...] nonzero,
>   # it shall be valid as an identifier on the companion processor.
> 
> If you ignore the case of an identifier in the C language (the "companion
> processor"?), I suppose it is still "valid".

That's not what is happening.

According to the Fortran standard, we ignore the case when determining
if there is a duplicate global symbol, which we then reject.

You can use a C symbol with whatever case mix you want.  Take, for
example

module foo

interface
function func1(ii) result (k) bind(c, name="C_fUnC")
  integer :: ii
  integer :: k
end function func1
end interface

contains

function func2(ii) result (k) 
  integer :: ii
  integer :: k
  k = func1(ii)
end function func2
end module foo
$ gfortran -c a.f90 
$ nm a.o
 U C_fUnC
 T __foo_MOD_func2

where you see an identifier "C_fUnC" (your external C function)
as an undefined symbol, so you can link it against an object
file containing that function, and all will be fine.

Regarding extensions: We have quite a few (maybe too many...)
for old features, for code that was written before modern
Fortran arrived.  People need them, so we usually accept
patches for this kind of thing.

If there is a prohibition against the user doing something
in the standard, like in this case (marked by "shall" or
"shall not"), we usually try to identify the error to help
the user correct his code.

Hmm... I just checked, and found that, while we get this right,
there is no test case to make sure we don't regress.  I will
add that shortly.

[Bug c++/94772] New: [10 Regression] constructing constexpr variables fail with delegated constexpr constructors

[gcc-bugs at marehr dot dialup.fu-berlin.de]

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

Bug ID: 94772
   Summary: [10 Regression] constructing constexpr variables fail
with delegated constexpr constructors
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc-bugs at marehr dot dialup.fu-berlin.de
  Target Milestone: ---

Hi gcc!

The following code does not compile with gcc10 anymore:

```c++
struct foo
{
constexpr foo() noexcept = default;

// fails with gcc10; commenting : foo{} out works with gcc10
constexpr foo(int a, int b) : foo{} 
{
bar += a + b;
}
int bar{}; 
};

int main()
{
constexpr foo bar{1, 2};
}
```
https://godbolt.org/z/brsFdo

All major compilers and gcc < 10 do support this, so I think this is a
regression.

```
> g++-git -std=c++2a

: In function 'int main()':
:15:27:   in 'constexpr' expansion of 'foo(1, 2)'
:8:13: error: modifying a const object '((foo*)this)->foo::bar' is not
allowed in a constant expression
8 | bar += a + b;
  | ^~~~
:15:19: note: originally declared 'const' here
   15 | constexpr foo bar{1, 2};
  |   
```

Thank you!

[Bug c++/94771] New: g++.dg/concepts/diagnostic10.C fails on mingw

[sbence92 at gmail dot com]

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

Bug ID: 94771
   Summary: g++.dg/concepts/diagnostic10.C fails on mingw
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbence92 at gmail dot com
  Target Milestone: ---

g++.dg/concepts/diagnostic10.C fails with gcc 10 (ead1c27a530) on mingw target
and host.

Instead of 
diagnostic10.C:6:31: error: invalid use of non-static member function 'int
S::f()'
we get
diagnostic10.C:6:31: error: statement cannot resolve address of overloaded
function.

Seems like the fix for Bug 52597 (typeck.c invalid_nonstatic_memfn_p) went with
a special case for -fms-extensions which is a default for mingw.

Compiling with -fno-ms-extensions provides the correct diagnostic.

[Bug c++/43943] "warning: no return statement in function returning non-void" should be an error

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #7 from Jonathan Wakely  ---
*** Bug 94768 has been marked as a duplicate of this bug. ***

[Bug c++/94768] Wreturn-type should be error, not warning

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=55189
 Resolution|INVALID |DUPLICATE

--- Comment #7 from Jonathan Wakely  ---
Dup of PR 43943 (and others)

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

[Bug c++/11474] -Wreturn-type should default to on when compiling C++

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=55189

--- Comment #10 from Jonathan Wakely  ---
PR 55189 made it on by default for GCC 8.

[Bug c++/94768] Wreturn-type should be error, not warning

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
(In reply to David Binderman from comment #3)
> Most of the time, it is in its own GNU mode and so could do a more
> useful job here rather than IMHO blindly following non-useful standards.

Nobody is "blindly following" anything. It's been discussed in detail by people
who know what they're talking about, over many years (including again when
-Wreturn-type was enabled by default for C++). Rejecting valid C++ code by
default is not OK.

[Bug target/94770] New: class with empty base passed incorrectly with -std=c++17 on mingw

[sbence92 at gmail dot com]

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

Bug ID: 94770
   Summary: class with empty base passed incorrectly with
-std=c++17 on mingw
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbence92 at gmail dot com
  Target Milestone: ---

Created attachment 48376
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48376=edit
preprocessed failing tests

Similar to Bug #94383, Bug #94704 and Bug #94706 the below tests fail with gcc
10 (ead1c27a530) with mingw host and target (also with gcc 9.3 taken from
msys2).

FAIL: tmpdir-g++.dg-struct-layout-1/t032 cp_compat_x_tst.o-cp_compat_y_tst.o
execute
FAIL: tmpdir-g++.dg-struct-layout-1/t033 cp_compat_x_tst.o-cp_compat_y_tst.o
execute
FAIL: tmpdir-g++.dg-struct-layout-1/t034 cp_compat_x_tst.o-cp_compat_y_tst.o
execute
FAIL: tmpdir-g++.dg-struct-layout-1/t051 cp_compat_x_tst.o-cp_compat_y_tst.o
execute
FAIL: tmpdir-g++.dg-struct-layout-1/t055 cp_compat_x_tst.o-cp_compat_y_tst.o
execute
FAIL: tmpdir-g++.dg-struct-layout-1/t056 cp_compat_x_tst.o-cp_compat_y_tst.o
execute
FAIL: tmpdir-g++.dg-struct-layout-1/t058 cp_compat_x_tst.o-cp_compat_y_tst.o
execute
FAIL: tmpdir-g++.dg-struct-layout-1/t059 cp_compat_x_tst.o-cp_compat_y_tst.o
execute


tmpdir-g++-dg-struct-layout-1-t032-01.exe
fail 30.71

tmpdir-g++-dg-struct-layout-1-t033-01.exe
fail 385.71

tmpdir-g++-dg-struct-layout-1-t034-01.exe
fail 798.71

tmpdir-g++-dg-struct-layout-1-t051-01.exe
fail 1817.71

tmpdir-g++-dg-struct-layout-1-t055-01.exe
fail 2002.71

tmpdir-g++-dg-struct-layout-1-t056-01.exe
fail 2200.71

tmpdir-g++-dg-struct-layout-1-t058-01.exe
fail 2604.71

tmpdir-g++-dg-struct-layout-1-t059-01.exe
fail 2828.71

[Bug testsuite/94763] UNRESOLVED scan assembler tests on arm-none-eabi

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #1 from Christophe Lyon  ---
How do you configure GCC, and what flags to you use to run the tests?
They work for me, on several configuration of arm-non-eabi-gcc as
cross-compiler.

[Bug c++/94767] (unsigned bitfield) + (int) operation results in int, not unsigned int.

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
I think this has been fixed on the trunk.

[Bug c++/94768] Wreturn-type should be error, not warning

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  ---
(In reply to David Binderman from comment #3)
> I checked the source code of the popular Fedora Linux distribution.
> There are 32 examples of this problem in the C++ code, so they will
> need fixing.
> 
> Interestingly, there are a whopping 258 examples in the C code, but that's a
> separate issue.

Note C and C++ have slightly different notice about "no return statement in
function returning non-void"; In C it is only undefined if the return value is
used while in C++ it is undefined the moment that the end of the function
happens.

[Bug c++/94768] Wreturn-type should be error, not warning

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to David Binderman from comment #0)
> > IMHO, for a C++ function returning non-void, a complete absence of any
> > return statement in the function really should produce an error.
> 
> This is a valid C++ program and it would be non-conforming to reject it. The
> compiler can't even assume the program has undefined behaviour, because
> g(int) could throw an exception, or do something that terminates, or simply
> never return (e.g. go into an infinite loops with side effects like I/O).

Just to expand on this.  undefined at runtime behavior is not supposed to stop
compilation of a translation unit.

[Bug fortran/94769] New: Possible use of uninitialized variable num

[stefansf at linux dot ibm.com]

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

Bug ID: 94769
   Summary: Possible use of uninitialized variable num
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stefansf at linux dot ibm.com
  Target Milestone: ---

In function check_io_constraints local variable num is supposed to be
initialized by function compare_to_allowed_values. While bootstrapping GCC on
S/390 I get the following warning/error:

gcc/fortran/io.c: In function 'bool gfc_resolve_dt(gfc_code*, gfc_dt*,
locus*)':
gcc/fortran/io.c:3857:7: error: 'num' may be used uninitialized in this
function [-Werror=maybe-uninitialized]
 3857 |   if (num == 0)
  |   ^~   
gcc/fortran/io.c:3843:11: note: 'num' was declared here
 3843 |   int num;

I'm not sure whether a sensible default value for num should be 0 or 1.

[Bug bootstrap/78251] config/gettext.m4 and config/iconv.m4 contaminate CPPFLAGS (can lead to build failures when libunwind-headers from MacPorts is active)

[michael+gcc at stapelberg dot ch]

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

--- Comment #12 from Michael Stapelberg  ---
I’m also running into this bug: I have recently started linking strace against
libunwind (for its handy --stack-traces option), and like having strace
available in my package build dependencies to debug build failures
interactively.

I’m using gcc 9.3.0 and libunwind 1.4.0. The first build failure message I’m
encountering is (I attached the full build log to this bug, too):

libtool: compile:  /usr/src/gcc-amd64-9.3.0-4/build/./gcc/xgcc -shared-libgcc
-B/usr/src/gcc-amd64-9.3.0-4/build/./gcc -nostdinc++
-L/usr/src/gcc-amd64-9.3.0-4/build/x86_64-pc-linux-gnu/libstdc++-v3/src
-L/usr/src/gcc-amd64-9.3.0-4/build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L/usr/src/gcc-amd64-9.3.0-4/build/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/ro/gcc-amd64-9.3.0-4/out/x86_64-pc-linux-gnu/bin/
-B/ro/gcc-amd64-9.3.0-4/out/x86_64-pc-linux-gnu/lib/ -isystem
/ro/gcc-amd64-9.3.0-4/out/x86_64-pc-linux-gnu/include -isystem
/ro/gcc-amd64-9.3.0-4/out/x86_64-pc-linux-gnu/sys-include -fno-checking
-I/usr/src/gcc-amd64-9.3.0-4/libstdc++-v3/../libgcc
-I/usr/src/gcc-amd64-9.3.0-4/build/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu
-I/usr/src/gcc-amd64-9.3.0-4/build/x86_64-pc-linux-gnu/libstdc++-v3/include
-I/usr/src/gcc-amd64-9.3.0-4/libstdc++-v3/libsupc++ -D_GLIBCXX_SHARED
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections
-frandom-seed=eh_ptr.lo -g -O2 -D_GNU_SOURCE -c
/usr/src/gcc-amd64-9.3.0-4/libstdc++-v3/libsupc++/eh_ptr.cc  -fPIC -DPIC
-D_GLIBCXX_SHARED -o eh_ptr.o
libtool: compile:  /usr/src/gcc-amd64-9.3.0-4/build/./gcc/xgcc -shared-libgcc
-B/usr/src/gcc-amd64-9.3.0-4/build/./gcc -nostdinc++
-L/usr/src/gcc-amd64-9.3.0-4/build/x86_64-pc-linux-gnu/libstdc++-v3/src
-L/usr/src/gcc-amd64-9.3.0-4/build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L/usr/src/gcc-amd64-9.3.0-4/build/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/ro/gcc-amd64-9.3.0-4/out/x86_64-pc-linux-gnu/bin/
-B/ro/gcc-amd64-9.3.0-4/out/x86_64-pc-linux-gnu/lib/ -isystem
/ro/gcc-amd64-9.3.0-4/out/x86_64-pc-linux-gnu/include -isystem
/ro/gcc-amd64-9.3.0-4/out/x86_64-pc-linux-gnu/sys-include -fno-checking
-I/usr/src/gcc-amd64-9.3.0-4/libstdc++-v3/../libgcc
-I/usr/src/gcc-amd64-9.3.0-4/build/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu
-I/usr/src/gcc-amd64-9.3.0-4/build/x86_64-pc-linux-gnu/libstdc++-v3/include
-I/usr/src/gcc-amd64-9.3.0-4/libstdc++-v3/libsupc++ -D_GLIBCXX_SHARED
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections
-frandom-seed=eh_personality.lo -g -O2 -D_GNU_SOURCE -c
/usr/src/gcc-amd64-9.3.0-4/libstdc++-v3/libsupc++/eh_personality.cc  -fPIC
-DPIC -D_GLIBCXX_SHARED -o eh_personality.o
In file included from
/usr/src/gcc-amd64-9.3.0-4/libstdc++-v3/libsupc++/eh_call.cc:28:
/usr/src/gcc-amd64-9.3.0-4/libstdc++-v3/libsupc++/unwind-cxx.h:92:3: error:
'_Unwind_Ptr' does not name a type; did you mean '_Unwind_SetIP'?
   92 |   _Unwind_Ptr catchTemp;
  |   ^~~
  |   _Unwind_SetIP
/usr/src/gcc-amd64-9.3.0-4/libstdc++-v3/libsupc++/unwind-cxx.h:146:3: error:
'_Unwind_Ptr' does not name a type; did you mean '_Unwind_SetIP'?
  146 |   _Unwind_Ptr catchTemp;
  |   ^~~
  |   _Unwind_SetIP

[Bug bootstrap/78251] config/gettext.m4 and config/iconv.m4 contaminate CPPFLAGS (can lead to build failures when libunwind-headers from MacPorts is active)

[michael+gcc at stapelberg dot ch]

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

Michael Stapelberg  changed:

   What|Removed |Added

 CC||michael+gcc at stapelberg dot 
ch

--- Comment #11 from Michael Stapelberg  ---
Created attachment 48375
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48375=edit
full build log for failing build

[Bug middle-end/89428] missing -Wstringop-overflow on a PHI with variable offset

[xerofoify at gmail dot com]

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

Nicholas Krause  changed:

   What|Removed |Added

 CC||xerofoify at gmail dot com

--- Comment #2 from Nicholas Krause  ---
Changing i equal to 1 in the second function gives the warning and gets similar
GIMPLE like this to the first function:

 [local count: 1073741824]:
  i_3 = MAX_EXPR ;
  _1 =  + i_3;   
  __builtin_memset (_1, 0, 99); [tail call]
  return;  

Are we assuming somewhere that zero size offsets should for the first argument
of __builtin_memset to be forgotten about? Because I tried it with multiple
numbers other than zero and they all worked to get GIMPLE similar to the above.

[Bug c++/94768] Wreturn-type should be error, not warning

[dcb314 at hotmail dot com]

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

--- Comment #3 from David Binderman  ---
(In reply to Jonathan Wakely from comment #1)
> This is a valid C++ program and it would be non-conforming to reject it.

Surprising. The standard looks broken to me. Standards conformance
only really matters if GNU C++ is in standards conformance mode.

Most of the time, it is in its own GNU mode and so could do a more
useful job here rather than IMHO blindly following non-useful standards.

I checked the source code of the popular Fedora Linux distribution.
There are 32 examples of this problem in the C++ code, so they will
need fixing.

Interestingly, there are a whopping 258 examples in the C code, but that's a
separate issue.

[Bug c++/94768] Wreturn-type should be error, not warning

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #1)
> This is a valid C++ program

s/program/translation unit/

[Bug c++/94768] Wreturn-type should be error, not warning

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Jonathan Wakely  ---
(In reply to David Binderman from comment #0)
> IMHO, for a C++ function returning non-void, a complete absence of any
> return statement in the function really should produce an error.

This is a valid C++ program and it would be non-conforming to reject it. The
compiler can't even assume the program has undefined behaviour, because g(int)
could throw an exception, or do something that terminates, or simply never
return (e.g. go into an infinite loops with side effects like I/O).

[Bug c++/94768] New: Wreturn-type should be error, not warning

[dcb314 at hotmail dot com]

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

Bug ID: 94768
   Summary: Wreturn-type should be error, not warning
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

For this C++ code:

void g( int);

struct S
{
int a;
int b;

S & operator = ( const S & that)
{
g( that.a);
}
};

G++ produces only a warning, although it does give us a clue
what it is expecting:

$ /home/dcb/gcc/results/bin/gcc -c -g -O2 -Wall apr26d.cc
apr26d.cc: In member function ‘S& S::operator=(const S&)’:
apr26d.cc:12:2: warning: no return statement in function returning non-void
[-Wreturn-type]
   11 |   g( that.a);
  +++ |+  return *this;
   12 |  }
  |  ^
$ 

I have to add -Werror=return-type to get compilation to stop.

$ /home/dcb/gcc/results/bin/gcc -c -Werror=return-type apr26d.cc
apr26d.cc: In member function ‘S& S::operator=(const S&)’:
apr26d.cc:12:2: error: no return statement in function returning non-void
[-Werror=return-type]
   11 |   g( that.a);
  +++ |+  return *this;
   12 |  }
  |  ^
cc1plus: some warnings being treated as errors
$ 

I'll have a look at switching on Werror=return-type permanently locally.

IMHO, for a C++ function returning non-void, a complete absence of any return
statement in the function really should produce an error.

Yes a warning is a diagnostic and so conforms with ISO C++ rules,
but finding obvious bugs at compile time is preferable to runtime.

[Bug fortran/94737] BIND(C) names are not always treated as case sensitive.

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #5 from Steve Kargl  ---
On Sun, Apr 26, 2020 at 02:39:37AM +, busby1 at llnl dot gov wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94737
> 
> --- Comment #4 from Lee Busby  ---
> (In reply to kargl from comment #3)
> > (In reply to Thomas Koenig from comment #2)
> > > Correction, this is not a regression.
> > > 
> > > F2018 has, in 19.2, paragraph 2
> > > 
> > > # The global identifier of an entity shall not be the same as the global
> > > # identifier of any other entity. Furthermore, a binding label shall not
> > > # be the same as the global identifier of any other global entity,
> > > # ignoring differences in case.
> > > 
> > > So, the error message is correct, and you need to change your
> > > program accordingly.
> > 
> > Good catch, Thomas!
> > 
> > In hindsight, the restriction makes prefect sense given 
> > Fortran is a case insensitive language.
> 
> I don't have any particular problem using 19.2 to make this a feature, not a
> bug.  Clarity is always better. I wonder how does 19.2 square with 8.5.5, 
> lines
> 13-14:
> 
>   # If the value of the [NAME=scalar-character-constant] is [...] nonzero,
>   # it shall be valid as an identifier on the companion processor.
> 
> If you ignore the case of an identifier in the C language (the "companion
> processor"?), I suppose it is still "valid".  But it's the wrong one.  Oh,
> well, above my pay grade.  Thank you for your investigation, and ongoing work
> on gfortran.
> 

I suppose I don't quite follow you.  gfortran flagged an
error in your code.  Thomas took the time to locate the
passage in the Fortran standard that confirms you have
an error in your code.  You would rather ask the diminishing
number of volunteers to add an extension to gfortran to
to compile your nonconforming code than fix the code.
Seems reasonable.