[Bug c++/89405] [8 Regression] ICE in import_export_decl, at cp/decl2.c:2959

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[8/9 Regression] ICE in |[8 Regression] ICE in
   |import_export_decl, at  |import_export_decl, at
   |cp/decl2.c:2959 |cp/decl2.c:2959

--- Comment #6 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug c++/89403] [7/8 Regression] ICE in maybe_clone_body, at cp/optimize.c:693

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[7/8/9 Regression] ICE in   |[7/8 Regression] ICE in
   |maybe_clone_body, at|maybe_clone_body, at
   |cp/optimize.c:693   |cp/optimize.c:693

--- Comment #5 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug fortran/80408] Problems with SIGNAL, pthread and print together

[raphael.monod at wanadoo dot fr]

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

--- Comment #6 from Raphael Monod  ---
Thank you very much for your explanations. Now I understand why I was wrong. I
will try to change my code to take into account your suggestions.
Once more, thank you very much.

[Bug c++/88690] [7/8/9 Regression] c++17 internal compiler error: in output_constructor_regular_field, at varasm.c:5031

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug target/89271] [9 Regression] gcc.target/powerpc/vsx-simode2.c stopped working in GCC 9

[vmakarov at gcc dot gnu.org]

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

--- Comment #11 from Vladimir Makarov  ---
(In reply to Alan Modra from comment #5)
> Created attachment 45760 [details]
> Current set of patches
> 
> It turns out there is a lot more than just wrong register_move_cost.  This
> patchset does fix the PR without introducing too many regressions, but it is
> a work in progress.
> 
> I have some questions about union register classes:
> 1) What should register_move_cost return for a union class like
> GEN_OR_VSX_REGS and some other class?  Worst case, best case, or doesn't it
> matter?
> 2) What should preferred_reload_class return for union classes?
> Looking at other ports doesn't shed much light..

 IRA uses practically the same algorithm as the old RA. Only instead of
pseudos, pseudo ranges (allocnos) are used.
 It is hard to describe the algorithm briefly. It has a few drawbacks.
 Roughly speaking it does not take into account that, when we calculate the
costs, different pseudo operands should be on the same insn alternative.
Choosing the classes implicitly affects on a final choice of insn alternative.
 For some time I worked on different approach which is based on choosing insn
alternatives first and then calculating the costs.  The code for this is
currently on branch ira-select.
 As for register move costs inside an union class, for better RA results I
think we should not take costs of moves between different subclasses into
account. So it should be a minimal costs of moves only inside subclasses.
 For example, if we have GENERAL_FLOATING_REGS class the cost for moves inside
the class (from GENERAL_FLOATING_REGS to GENERAL_FLOATING_REGS) should be not
cost of move from GENERAL to FLOAT class but minimal cost of move only inside
GENERAL class and only inside FLOAT class.  Analogously, for moves between two 
different classes (when one or both classes are an union classes), we should
use minimal cost of moves from subclasses of the two classes.  
  The most common case when the algorithm chooses union classes is one when we
use a pseudo to implement memory-memory move.  For example, moving memory
through general or float registers has the same cost.  If we use maximal cost
for moves between regs of GENERAL_FLOATING_REGS, the algorithm decreases the
number of registers which can be used for such moves by using only general or
only float regs.
  That is how I see the right approach but I never benchmarked different
approaches, for example, on SPEC. So the approach I propose here has not been
checked on practice.

[Bug rtl-optimization/89313] [9 Regression] ICE in process_alt_operands, at lra-constraints.c:2962

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

   Keywords|ice-on-invalid-code |ice-on-valid-code
 Target|x86_64-pc-linux-gnu |x86_64-pc-linux-gnu,
   ||powerpc*-linux
URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2019-02/msg01728.ht
   ||ml

--- Comment #6 from Peter Bergner  ---
As part of some offline discussions, it was determined that the asm usage is
valid and should be handled, so I changed the keywords to ice-on-valid-code.

Patch submitted that fixes the asmcons pass to handle this scenario.

[Bug c++/87921] [7/8 Regression] Incorrect error "storage size of [array] isn't known (when it is)

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

Summary|[7/8/9 Regression]  |[7/8 Regression] Incorrect
   |Incorrect error "storage|error "storage size of
   |size of [array] isn't known |[array] isn't known (when
   |(when it is)|it is)

--- Comment #4 from Jason Merrill  ---
Fixed on trunk so far.

[Bug c++/87921] [7/8/9 Regression] Incorrect error "storage size of [array] isn't known (when it is)

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Thu Feb 21 02:24:40 2019
New Revision: 269064

URL: https://gcc.gnu.org/viewcvs?rev=269064=gcc=rev
Log:
PR c++/87921 - wrong error with inline static data member.

c_parse_final_cleanups checks DECL_IN_AGGR_P to avoid trying to emit a
static data member that has not been defined.  The inline variable patch
changed that to exempt inline variables.  But in this case we haven't
instantiated the variable yet, so we really don't have a definition.  This
patch changes inline variable handling such that DECL_IN_AGGR_P is not set
for a defined inline variable, so we can remove all the checks of
DECL_INLINE_VAR_P after DECL_IN_AGGR_P.

With that change we were failing on a static data member that had been
instantiated due to a use before we got around to processing it in
instantiate_class_template; we should detect that and avoid all the
finish_static_data_member_decl processing, which assumes that it is the
first time we're seeing the variable.

* decl2.c (finish_static_data_member_decl): Don't set DECL_IN_AGGR_P
for a non-template inline variable.  Do nothing for an
already-instantiated variable.
(c_parse_final_cleanups): Check DECL_IN_AGGR_P without
DECL_INLINE_VAR_P.
* decl.c (check_initializer): Likewise.
(make_rtl_for_nonlocal_decl): Likewise.
* pt.c (instantiate_decl): Likewise.
* typeck2.c (store_init_value): Likewise.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/inline-var6.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/decl.c
trunk/gcc/cp/decl2.c
trunk/gcc/cp/pt.c
trunk/gcc/cp/typeck2.c

[Bug c++/52130] missing check for matching underlying type during instantiation of enum member of class template

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
The relevant text in the standard is:

"A scoped enumeration shall not be later redeclared as unscoped or with a
different underlying type. An unscoped enumeration shall not be later
redeclared as scoped and each redeclaration shall include an enum-base
specifying the same underlying type as in the original declaration."


A suitable diagnostic would be:

enumeration type redeclared with different underlying type

[Bug c++/52320] missing destructor call after thrown exception in initializer

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||wrong-code
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=57510

--- Comment #5 from Jonathan Wakely  ---
Related to PR 57510

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

[msebor at gcc dot gnu.org]

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

Bug ID: 89428
   Summary: missing -Wstringop-overflow on a PHI with variable
offset
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

GCC diagnoses the 1-byte overflow in the call to memset in f() but fails to
diagnose the much bigger overflow in g().  The problem is the PHI that the
compute_objsize() function doesn't handle.

$ cat t.c && gcc -O2 -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout t.c
char a[7];

void f (__SIZE_TYPE__ i)
{
  if (i < 1 || 2 < i) i = 1;

  __builtin_memset (a + i, 0, 7);   // warning (good)
}

void g (__SIZE_TYPE__ i)
{
  if (2 < i) i = 0;

  __builtin_memset (a + i, 0, 99);   // missing warning (bug)
}

;; Function f (f, funcdef_no=0, decl_uid=1907, cgraph_uid=1, symbol_order=1)

Removing basic block 3
f (long unsigned int i)
{
  long unsigned int _1;
  void * _2;

   [local count: 1073741824]:
  _1 = i_4(D) + 18446744073709551615;
  if (_1 > 1)
goto ; [59.00%]
  else
goto ; [41.00%]

   [local count: 633507680]:

   [local count: 1073741824]:
  # i_3 = PHI 
  _2 =  + i_3;
  __builtin_memset (_2, 0, 7); [tail call]
  return;

}


t.c: In function ‘f’:
t.c:7:3: warning: ‘__builtin_memset’ writing 7 bytes into a region of size 6
overflows the destination [-Wstringop-overflow=]
7 |   __builtin_memset (a + i, 0, 7);   // warning (good)
  |   ^~

;; Function g (g, funcdef_no=1, decl_uid=1910, cgraph_uid=2, symbol_order=2)

Removing basic block 5
g (long unsigned int i)
{
  char[7] * _6;
  char[7] * prephitmp_7;

   [local count: 1073741824]:
  if (i_3(D) > 2)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 536870912]:
  _6 =  + i_3(D);

   [local count: 1073741824]:
  # prephitmp_7 = PHI <_6(3), (2)>
  __builtin_memset (prephitmp_7, 0, 99); [tail call]
  return;

}

[Bug go/89407] [9 Regression] go bootstrap failure on s390x starting with r268941

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #2 from Ian Lance Taylor  ---
Fixed, I hope.

[Bug go/89407] [9 Regression] go bootstrap failure on s390x starting with r268941

[ian at gcc dot gnu.org]

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

--- Comment #1 from ian at gcc dot gnu.org  ---
Author: ian
Date: Thu Feb 21 01:06:01 2019
New Revision: 269063

URL: https://gcc.gnu.org/viewcvs?rev=269063=gcc=rev
Log:
PR go/89407
internal/cpu: use #ifdef __s390x__ in C code

Patch by Jakub Jelinek.

Fixes https://gcc.gnu.org/PR89407

Reviewed-on: https://go-review.googlesource.com/c/163297

Modified:
trunk/gcc/go/gofrontend/MERGE
trunk/libgo/go/internal/cpu/cpu_gccgo.c

[Bug libstdc++/89416] [9 regression] std::vector::push_back no longer builds.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-02-21
  Known to work||8.2.1
Version|unknown |9.0
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
Summary|[regression]|[9 regression]
   |std::vector::push_bac |custom_allocator>::push_bac
   |k no longer builds. |k no longer builds.
 Ever confirmed|0   |1
  Known to fail||9.0

[Bug c++/88826] ICE (segfault) when compiling invalid C++ code with -std=c++2a

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com

--- Comment #2 from Paolo Carlini  ---
Mine.

[Bug c++/89403] [7/8/9 Regression] ICE in maybe_clone_body, at cp/optimize.c:693

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Thu Feb 21 00:09:47 2019
New Revision: 269059

URL: https://gcc.gnu.org/viewcvs?rev=269059=gcc=rev
Log:
PR c++/89403
* decl2.c (c_parse_final_cleanups): Move TREE_ASM_WRITTEN setting
for flag_syntax_only from here...
* semantics.c (expand_or_defer_fn_1): ... here.

* g++.dg/cpp0x/pr89403.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr89403.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl2.c
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/89405] [8/9 Regression] ICE in import_export_decl, at cp/decl2.c:2959

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Thu Feb 21 00:08:59 2019
New Revision: 269058

URL: https://gcc.gnu.org/viewcvs?rev=269058=gcc=rev
Log:
PR c++/89405
* decl.c (maybe_commonize_var): When clearing TREE_PUBLIC and
DECL_COMMON, set DECL_INTERFACE_KNOWN.

* g++.dg/cpp1z/inline-var5.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/inline-var5.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/89427] missing -Warray-bounds on a MEM_REF of array plus offset

[msebor at gcc dot gnu.org]

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

--- Comment #1 from Martin Sebor  ---
The equivalent code using memcpy (or even strcpy) is diagnosed:

$ cat u.c && gcc -O2 -S -Wall u.c
char a[8];

void f (int i)
{
  char *p = a + sizeof a;
  if (i < 5)
i = 5;
  __builtin_memcpy (p + i, "", 1);
}
u.c: In function ‘f’:
u.c:8:3: warning: ‘__builtin_memcpy’ offset [13, 2147483655] is out of the
bounds [0, 8] of object ‘a’ with type ‘char[8]’ [-Warray-bounds]
8 |   __builtin_memcpy (p + i, "", 1);
  |   ^~~
u.c:1:6: note: ‘a’ declared here
1 | char a[8];
  |  ^


Likewise for memset (by -Wstringop-overflow=):

$ cat u.c && gcc -O2 -S -Wall u.c
char a[8];

void f (int i)
{
  char *p = a + sizeof a;
  if (i < 5)
i = 5;
  __builtin_memset (p + i, 0, 1);
}
u.c: In function ‘f’:
u.c:8:3: warning: ‘__builtin_memset’ writing 1 byte into a region of size 0
overflows the destination [-Wstringop-overflow=]
8 |   __builtin_memset (p + i, 0, 1);
  |   ^~

[Bug tree-optimization/89427] New: missing -Warray-bounds on a MEM_REF of array plus offset

[msebor at gcc dot gnu.org]

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

Bug ID: 89427
   Summary: missing -Warray-bounds on a MEM_REF of array plus
offset
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The out-of-bounds access below is not diagnosed even though it could be.  The
vrp_pro::check_mem_ref function gives up too soon.  It's passed as an argument
MEM_REF (_2, 0) where _2 = [(void *) + 8B] + _1.  It extracts the _2 but
bails when that's not an ADDR_EXPR of either a STRING_CST or VAR_DECL.  It
should also look the argument of the inner MEM_REF and consider its size and
offset if it's a VAR_DECL.

$ cat u.c && gcc -O2 -S -Wall -Wextra -Warray-bounds=2 u.c
char a[8];

void f (int i)
{
  char *p = a + sizeof a;
  if (i < 5)
i = 5;
  p[i] = 0;   // missing -Warray-bounds
}

[Bug sanitizer/89409] [9 Regression] FAIL: c-c++-common/ubsan/div-by-zero-[67].c

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
Fixed.

[Bug middle-end/89412] [7/8 Regression] gcc ICE in simplify_subreg, at simplify-rtx.c:6273 on i686-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Known to work||9.0
Summary|[7/8/9 Regression] gcc ICE  |[7/8 Regression] gcc ICE in
   |in simplify_subreg, at  |simplify_subreg, at
   |simplify-rtx.c:6273 on  |simplify-rtx.c:6273 on
   |i686-linux-gnu  |i686-linux-gnu

--- Comment #8 from Jakub Jelinek  ---
Fixed for 9+ so far.

[Bug middle-end/89412] [7/8/9 Regression] gcc ICE in simplify_subreg, at simplify-rtx.c:6273 on i686-linux-gnu

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Wed Feb 20 23:02:29 2019
New Revision: 269057

URL: https://gcc.gnu.org/viewcvs?rev=269057=gcc=rev
Log:
PR middle-end/89412
* expr.c (expand_assignment): If result is a MEM, use change_address
instead of simplify_gen_subreg.

* gcc.c-torture/compile/pr89412.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr89412.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/expr.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/89091] ICE: Segmentation fault (in tree_class_check)

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Fixed for 9+ so far.

[Bug middle-end/89091] ICE: Segmentation fault (in tree_class_check)

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Author: jakub
Date: Wed Feb 20 23:01:41 2019
New Revision: 269056

URL: https://gcc.gnu.org/viewcvs?rev=269056=gcc=rev
Log:
PR middle-end/89091
* fold-const.c (decode_field_reference): Return NULL_TREE if
lang_hooks.types.type_for_size returns NULL.  Check it before
overwriting *exp_.  Use return NULL_TREE instead of return 0.

* gcc.dg/torture/pr89091.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr89091.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/89415] [9 Regression] gcc.dg/sinatan-1.c FAILs

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
Should be fixed now.

[Bug middle-end/89415] [9 Regression] gcc.dg/sinatan-1.c FAILs

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Wed Feb 20 22:41:26 2019
New Revision: 269055

URL: https://gcc.gnu.org/viewcvs?rev=269055=gcc=rev
Log:
PR middle-end/88074
PR middle-end/89415
* toplev.c (do_compile): Double the emin/emax exponents to workaround
buggy mpc_norm.

* gcc.dg/pr88074-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr88074-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/toplev.c

[Bug tree-optimization/88074] [7/8 Regression] g++ hangs on math expression

[jakub at gcc dot gnu.org]

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

--- Comment #32 from Jakub Jelinek  ---
Author: jakub
Date: Wed Feb 20 22:41:26 2019
New Revision: 269055

URL: https://gcc.gnu.org/viewcvs?rev=269055=gcc=rev
Log:
PR middle-end/88074
PR middle-end/89415
* toplev.c (do_compile): Double the emin/emax exponents to workaround
buggy mpc_norm.

* gcc.dg/pr88074-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr88074-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/toplev.c

[Bug fortran/83057] OPEN without a filename and without STATUS='SCRATCH' could produce a warning

[anlauf at gmx dot de]

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

--- Comment #5 from Harald Anlauf  ---
Patch submitted:

https://gcc.gnu.org/ml/fortran/2019-02/msg00176.html

[Bug target/89426] New: -mfpmath=sse isn't preserved

[hjl.tools at gmail dot com]

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

Bug ID: 89426
   Summary: -mfpmath=sse isn't preserved
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---
Target: i386

[hjl@gnu-cfl-1 gcc]$ cat x.i
float
__attribute__((target("arch=haswell")))
foo (float x, float y)
{
  return x * y;
}
[hjl@gnu-cfl-1 gcc]$ gcc -S -m32 -march=i686 -mfpmath=sse x.i -O2
cc1: warning: SSE instruction set disabled, using 387 arithmetics
[hjl@gnu-cfl-1 gcc]$ cat x.s
.file   "x.i"
.text
.p2align 4,,15
.globl  foo
.type   foo, @function
foo:
.LFB0:
.cfi_startproc
flds4(%esp)
fmuls   8(%esp)
ret
.cfi_endproc
.LFE0:
.size   foo, .-foo

I am expecting SSE FP math in foo.

[Bug tree-optimization/86367] FRE1 tree pass deletes code in gcc.target/powerpc/nan128-1.c when long double is IEEE 128

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |segher at gcc dot 
gnu.org

--- Comment #12 from Segher Boessenkool  ---
So yes what Joseph says in #c7 seems to be what is going on.

[Bug tree-optimization/86367] FRE1 tree pass deletes code in gcc.target/powerpc/nan128-1.c when long double is IEEE 128

[segher at gcc dot gnu.org]

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

--- Comment #11 from Segher Boessenkool  ---
If you use -fsignaling-nans everything works as expected.

[Bug c/89425] -Wabsolute-value warns in dead code

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic
 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=68193

--- Comment #1 from Eric Gallager  ---
(In reply to Joseph S. Myers from comment #0)
> (I'm not sure that will actually be sufficient to be able to use this
> warning when building glibc, because _Generic and __builtin_choose_expr
> don't look like they set c_inhibit_evaluation_warnings, but it's certainly a
> desirable improvement to this warning.)

I think the part about _Generic is bug 68193

[Bug middle-end/89415] [9 Regression] gcc.dg/sinatan-1.c FAILs

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #3 from Jakub Jelinek  ---
> See https://gcc.gnu.org/ml/gcc-patches/2019-02/msg01650.html

I've now included the patch in a sparc-sun-solaris2.11 bootstrap and the
sinatan-1.c failures are gone.

Thanks.
Rainer

[Bug target/89397] [7/8 Regression] ICE in build_call_expr_loc_array at gcc/tree.c:11563 since r229082

[uros at gcc dot gnu.org]

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

--- Comment #7 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed Feb 20 21:58:45 2019
New Revision: 269054

URL: https://gcc.gnu.org/viewcvs?rev=269054=gcc=rev
Log:
PR target/89397
* config/i386/i386.c (ix86_atomic_assign_expand_fenv): Check
TARGET_SSE in addition to TARGET_SSE_MATH.

(ix86_excess_precision): Ditto.
(ix86_float_exceptions_rounding_supported_p): Ditto.
(use_rsqrt_p): Ditto.
* config/i386/sse.md (rsqrt2): Ditto.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/sse.md

[Bug c/89425] New: -Wabsolute-value warns in dead code

[jsm28 at gcc dot gnu.org]

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

Bug ID: 89425
   Summary: -Wabsolute-value warns in dead code
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
CC: jamborm at gcc dot gnu.org
  Target Milestone: ---

Trying building glibc with -Wextra with GCC mainline shows up warnings from
-Wabsolute-value illustrated by the following test:

double f (double x) { return sizeof (x) == sizeof (float) ? __builtin_fabsf (x)
: __builtin_fabs (x); }

t.c: In function 'f':
t.c:1:61: warning: absolute value function '__builtin_fabsf' given an argument
of type 'double' but has parameter of type 'float' which may cause truncation
of value [-Wabsolute-value]
1 | double f (double x) { return sizeof (x) == sizeof (float) ?
__builtin_fabsf (x) : __builtin_fabs (x); }
  |
^~~

As with a range of other warnings in the C front end, this one should not apply
if c_inhibit_evaluation_warnings, to avoid such useless warnings.  (I'm not
sure that will actually be sufficient to be able to use this warning when
building glibc, because _Generic and __builtin_choose_expr don't look like they
set c_inhibit_evaluation_warnings, but it's certainly a desirable improvement
to this warning.)

[Bug fortran/83057] OPEN without a filename and without STATUS='SCRATCH' could produce a warning

[anlauf at gmx dot de]

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

Harald Anlauf  changed:

   What|Removed |Added

 CC||anlauf at gmx dot de

--- Comment #4 from Harald Anlauf  ---
The following obvious patch to the logic fixes the NEWUNIT issue:

Index: gcc/fortran/io.c
===
--- gcc/fortran/io.c(revision 269028)
+++ gcc/fortran/io.c(working copy)
@@ -2504,16 +2504,15 @@
  goto cleanup;
}

-  if (!open->file && open->status)
-{
- if (open->status->expr_type == EXPR_CONSTANT
+  if (!open->file &&
+ (!open->status ||
+  (open->status->expr_type == EXPR_CONSTANT
 && gfc_wide_strncasecmp (open->status->value.character.string,
-  "scratch", 7) != 0)
-  {
+ "scratch", 7) != 0)))
+   {
 gfc_error ("NEWUNIT specifier must have FILE= "
"or STATUS='scratch' at %C");
 goto cleanup;
-  }
}
 }
   else if (!open->unit)

I do not think we need to handle the other case,
as many people expect the file fort.20 to be created.
(At least I do.)

[Bug c++/89336] internal compiler error when compiling a constexpr function

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Author: jakub
Date: Wed Feb 20 21:16:27 2019
New Revision: 269052

URL: https://gcc.gnu.org/viewcvs?rev=269052=gcc=rev
Log:
PR c++/89336
* constexpr.c (cxx_eval_store_expression): Diagnose changing of active
union member for -std=c++17 and earlier.

* g++.dg/cpp1y/constexpr-89336-3.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-89336-3.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/testsuite/ChangeLog

[Bug target/89424] New: __builtin_vec_ext_v1ti (v, i) results in ICE with variable i (RS6000)

[kelvin at gcc dot gnu.org]

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

Bug ID: 89424
   Summary: __builtin_vec_ext_v1ti (v, i) results in ICE with
variable i (RS6000)
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kelvin at gcc dot gnu.org
  Target Milestone: ---
Target: rs6000
 Build: 9.0.1

Created attachment 45781
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45781=edit
preprocessed source code for reproducer

The __builtin_vec_ext_v1ti (v, i) function should work with both constant and
variable values of int i.

With current trunk

  $GCC_BUILD/GCC/xgcc -B$gcc_build/GCC/ -maltivec -mvsx -O1 -o problem.exe
problem.c

ends with an internal cmopiler error:
during RTL pass: expand
prX-0.c: In function ‘ei’:
prX-0.c:25:10: internal compiler error: in rs6000_expand_vector_extract, at
config/rs6000/rs6000.c:6970
   25 |   return __builtin_vec_ext_v1ti (v, i);
  |  ^
0x10faeabf rs6000_expand_vector_extract(rtx_def*, rtx_def*, rtx_def*)
/home/kelvin/gcc-root/gcc-trunk2/gcc/config/rs6000/rs6000.c:6970
0x10feeeaf altivec_expand_vec_ext_builtin
/home/kelvin/gcc-root/gcc-trunk2/gcc/config/rs6000/rs6000.c:14736
0x10feeeaf altivec_expand_builtin
/home/kelvin/gcc-root/gcc-trunk2/gcc/config/rs6000/rs6000.c:14969
0x10ff1def rs6000_expand_builtin
/home/kelvin/gcc-root/gcc-trunk2/gcc/config/rs6000/rs6000.c:16530
0x1034702b expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
/home/kelvin/gcc-root/gcc-trunk2/gcc/builtins.c:7226
0x10557feb expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/home/kelvin/gcc-root/gcc-trunk2/gcc/expr.c:11025
0x1056d8f3 store_expr(tree_node*, rtx_def*, int, bool, bool)
/home/kelvin/gcc-root/gcc-trunk2/gcc/expr.c:5669
0x10571463 expand_assignment(tree_node*, tree_node*, bool)
/home/kelvin/gcc-root/gcc-trunk2/gcc/expr.c:5432
0x10571463 expand_assignment(tree_node*, tree_node*, bool)
/home/kelvin/gcc-root/gcc-trunk2/gcc/expr.c:4978
0x1038082b expand_call_stmt
/home/kelvin/gcc-root/gcc-trunk2/gcc/cfgexpand.c:2722
0x1038082b expand_gimple_stmt_1
/home/kelvin/gcc-root/gcc-trunk2/gcc/cfgexpand.c:3691
0x1038082b expand_gimple_stmt
/home/kelvin/gcc-root/gcc-trunk2/gcc/cfgexpand.c:3850
0x1038959f expand_gimple_basic_block
/home/kelvin/gcc-root/gcc-trunk2/gcc/cfgexpand.c:5886
0x1038be27 execute
/home/kelvin/gcc-root/gcc-trunk2/gcc/cfgexpand.c:6509
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
Makefile:26: recipe for target 'prX-0.exe' failed
make: *** [prX-0.exe] Error 1
kelvin@genoa:~/gcc-root/tests$

[Bug fortran/80408] Problems with SIGNAL, pthread and print together

[jb at gcc dot gnu.org]

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

--- Comment #5 from Janne Blomqvist  ---
(In reply to Raphael Monod from comment #4)
> Thank you for your answer. But I don't understand why adding -lpthread
> option change the behavior if I do not use any thread.

In libgfortran, if a thread library is not linked in, thread-related stuff such
as mutexes are stubbed out in order to improve performance. With -lpthread it's
thus more likely that the code deadlocks. Note that there's no guarantee it
works without -lpthread either, it's just an accident.

> Moreover, if I refer
> to this page (
> https://docs.oracle.com/cd/E19455-01/806-5257/gen-26/index.html ) write
> statement seems to be async-signal safe ? Where am I wrong ?
> Finaly, what can I do if I want to print a message in my trap function ?
> Thank you for your interest to my problem.

That link refers to the POSIX write() function, which is a much lower level
interface than the Fortran write statement. POSIX write() is async-signal-safe,
but Fortran write has no such guarantees.

As the things you can do in a signal handler is extremely limited, one way to
handle it is to just set a flag variable, and then in the normal code you
regularly check that flag variable, and print messages or whatever.

Another way is the so-called self-pipe trick, where you create a pipe, and the
signal handler can then write to the pipe. A thread in your program can then
poll on the other end of the pipe. Handling pipes, and the need to use POSIX
write/read rather than Fortran READ/WRITE probably means you'll have to
implement that part of the program in C.

[Bug other/84889] Ideas on revamping how we format diagnostics

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED
   Target Milestone|9.0 |10.0

--- Comment #16 from David Malcolm  ---
(In reply to Martin Liška from comment #14)
> David: Can the bug be marked as resolved?

Much of this is implemented for gcc 9.

I want to keep this open, to revisit it in gcc 10.  I think the main pending
items are:

(In reply to David Malcolm from comment #0)
[...]
> * the diagnostic and the followup notes are grouped, so it's easier to pick
> out what messages relate to what
[...]
> IIRC, clang does something where the left-hand column is only non-empty for
> the start of a diagnostic; followup lines (e.g. due to line wrapping) are
> indented by 1 char, so that the "wall of text" is broken up somewhat
[...]

[Bug c++/87513] [8 Regression] ICE in write_expression, at cp/mangle.c:3050

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

Summary|[8/9 Regression] ICE in |[8 Regression] ICE in
   |write_expression, at|write_expression, at
   |cp/mangle.c:3050|cp/mangle.c:3050

--- Comment #11 from Jason Merrill  ---
Fixed on trunk so far.

[Bug ipa/86395] add support of -fopt-info-inline in inliner

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #8 from David Malcolm  ---
Oops, sorry.  Marking as resolved.

[Bug fortran/86248] [7/8/9 Regression] LEN_TRIM in specification expression causes link failure

[anlauf at gmx dot de]

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

--- Comment #4 from Harald Anlauf  ---
Some digging shows that the name mangling is done in trans-decl.c,
gfc_sym_mangled_identifier.  Strangely, the funny name mangling comes
from the component fn_result_spec being set in resolve.c, flag_fn_result_spec,
but only when darray_fixed is a PARAMETER.

The code in question was added by pault in rev. 243478:

243478  pault   if (!s->fn_result_spec
243478  pault && s->attr.flavor == FL_PARAMETER)
243478  pault   {
243478  pault /* Function contained in a module */
243478  pault if (ns->proc_name && ns->proc_name->attr.flavor ==
FL_MODULE)
243478  pault   {
243478  pault gfc_symtree *st;
243478  pault s->fn_result_spec = 1;

Maybe he can shine some light on this.

[Bug c/89410] [7/8 Regression] ICE in calculate_line_spans, at diagnostic-show-locus.c:1237 after #line

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

Summary|[7/8/9 Regression] ICE in   |[7/8 Regression] ICE in
   |calculate_line_spans, at|calculate_line_spans, at
   |diagnostic-show-locus.c:123 |diagnostic-show-locus.c:123
   |7 after #line   |7 after #line

--- Comment #14 from David Malcolm  ---
r269050 should fix the ICE on trunk; removing the "9" part of the Regression
from the Summary.

[Bug c/89410] [7/8/9 Regression] ICE in calculate_line_spans, at diagnostic-show-locus.c:1237 after #line

[dmalcolm at gcc dot gnu.org]

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

--- Comment #13 from David Malcolm  ---
Author: dmalcolm
Date: Wed Feb 20 20:07:20 2019
New Revision: 269050

URL: https://gcc.gnu.org/viewcvs?rev=269050=gcc=rev
Log:
Fix ICE with #line directive (PR c/89410)

PR c/89410 reports various issues with #line directives with very
large numbers; one of them is an ICE inside diagnostic-show-locus.c
when emitting a diagnostic at line 0x.

The issue is that the arithmetic in layout::calculate_line_spans to
determine if two line spans are sufficiently close to consolidate
was using the unsigned 32-bit linenum_type, which was overflowing
when comparing the line for the expanded location with those of
the location range (all on line 0x), leading to it
erroneously adding two spans for the same line, leading to an
assertion failure.

This patch fixes the ICE by generalizing the use of long long in
line-map.h's comparison function for linenum_type into a new
linenum_arith_t typedef, and using it here.

Doing so uncovered a second problem: the loop to print the lines
within the line_span for this case is infinite: looping from
0xfff upwards, overflowing to 0, and then never becoming
greater than 0xfff.  The patch fixes this by using linenum_arith_t
there also.

gcc/ChangeLog:
PR c/89410
* diagnostic-show-locus.c (layout::calculate_line_spans): Use
linenum_arith_t when determining if two adjacent line spans are
close enough to merge.
(diagnostic_show_locus): Use linenum_arith_t when iterating over
lines within each line_span.

gcc/testsuite/ChangeLog:
PR c/89410
* gcc.dg/pr89410-1.c: New test.
* gcc.dg/pr89410-2.c: New test.

libcpp/ChangeLog:
PR c/89410
* include/line-map.h (linenum_arith_t): New typedef.
(compare): Use it.


Added:
trunk/gcc/testsuite/gcc.dg/pr89410-1.c
trunk/gcc/testsuite/gcc.dg/pr89410-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/diagnostic-show-locus.c
trunk/gcc/testsuite/ChangeLog
trunk/libcpp/ChangeLog
trunk/libcpp/include/line-map.h

[Bug d/89177] unaligned memory access in libphobos

[bernd.edlinger at hotmail dot de]

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

--- Comment #4 from Bernd Edlinger  ---
(In reply to Johannes Pfau from comment #2)
> Thanks for the bug report & patch. It seems upstream phobos has already
> fixed this in a different way:
> 
> https://github.com/dlang/phobos/commit/
> d5f710c57e717ef470d093c1739156dcb2f2d469#diff-
> 2f532fcf37a0e29f7683a930ad9915ae
> 
> Could you please try whether simply replacing the murmurhash.d file with
> this latest upstream version works?
> https://raw.githubusercontent.com/dlang/phobos/master/std/digest/murmurhash.d
> 

Confirmed, this works for me, no regressions in arm-Linux-gnueabihf.

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

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
Funny.  real.mant_dig == 106 means 128bit IBM long double (or as some call it,
double-double as the error message suggest).  

The error message is incorrect in both cases too:
"Only 64-bit, 80-bit, and 128-bit reals"~
  " are supported for LittleEndian CPUs"

Should really be:
"Only IEEE 64-bit, IEEE 80-bit, and IEEE 128-bit reals"~
  " are supported for LittleEndian CPUs"

And:
"Only IEEE 64-bit and IEEE 128-bit reals are supported for BigEndian CPUs."~
" double-double reals have partial support"

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

[seurer at gcc dot gnu.org]

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

--- Comment #2 from seurer at gcc dot gnu.org ---
real.mant_dig is 106 on powerpc64le

[Bug c/89410] [7/8/9 Regression] ICE in calculate_line_spans, at diagnostic-show-locus.c:1237 after #line

[jg at jguk dot org]

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

--- Comment #12 from Jonny Grant  ---
Just to add

C spec says UB.

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf

"The #line preprocessing directive that results after expansion does not match
one of
the two well-defined forms, or its digit sequence specifies zero or a number
greater
than 2147483647 (6.10.4)."

As I understand it, it is #line 
So if it is #line 1, the following line (actual line 2) will be counted as line
1.

#line 0, means that the actual 2nd line in a file is treated as 0.

[Bug c++/87513] [8/9 Regression] ICE in write_expression, at cp/mangle.c:3050

[jason at gcc dot gnu.org]

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

--- Comment #10 from Jason Merrill  ---
Author: jason
Date: Wed Feb 20 18:59:18 2019
New Revision: 269048

URL: https://gcc.gnu.org/viewcvs?rev=269048=gcc=rev
Log:
PR c++/87513 - 'sorry' mangling PMF template-id.

Here build_offset_ref calls build_qualified_name to make a SCOPE_REF because
the dependent template arguments make type_dependent_expression_p (member)
true.  We could probably work hard to prevent this, but it doesn't seem
necessary, and it's easy to fix write_expression to handle the result.

* mangle.c (write_expression): Handle SCOPE_REF to BASELINK.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/decltype-tid1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/mangle.c

[Bug c++/88380] [7/8/9 Regression] Sequence of not-explicitly initialised, initialised, variable length generates no initialiser

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Wed Feb 20 18:54:45 2019
New Revision: 269046

URL: https://gcc.gnu.org/viewcvs?rev=269046=gcc=rev
Log:
PR c++/88380 - wrong-code with flexible array and NSDMI.

Here 'skipped' was set to -1 to force an explicit initializer for 'uninit'
before the initializer for 'initialized', and so we also tried to emit an
explicit initializer for the flexible array, for which build_zero_init
returns error_mark_node.  We should ignore flexarrays even when
skipped < 0.

* typeck2.c (process_init_constructor_record): Skip flexarrays.

Added:
trunk/gcc/testsuite/g++.dg/ext/flexary33.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck2.c

[Bug c++/88572] error: braces around scalar initializer - should be a warning

[jason at gcc dot gnu.org]

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

--- Comment #17 from Jason Merrill  ---
Author: jason
Date: Wed Feb 20 18:50:32 2019
New Revision: 269045

URL: https://gcc.gnu.org/viewcvs?rev=269045=gcc=rev
Log:
PR c++/88572 - wrong handling of braces on scalar init.

* decl.c (reshape_init_r): Allow braces around scalar initializer
within aggregate init.  Reject double braced-init of scalar
variable.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/g++.dg/cpp0x/initlist69.C
trunk/gcc/testsuite/g++.dg/cpp1z/direct-enum-init1.C
trunk/gcc/testsuite/g++.dg/init/brace1.C
trunk/gcc/testsuite/g++.dg/init/brace2.C
trunk/gcc/testsuite/g++.dg/init/union2.C
trunk/gcc/testsuite/g++.dg/warn/Wbraces2.C

[Bug target/84530] -mfunction-return=thunk does not work for simple_return_pop_internal insn

[drikosev at gmail dot com]

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

Ev Drikos  changed:

   What|Removed |Added

 CC||drikosev at gmail dot com

--- Comment #7 from Ev Drikos  ---
Hello,

There is perhaps a Darwin specific problem reproduced in various versions, ie
8.2:

Not really sure if the problem I face is indeed related to this PR.

$ gcc8 -mfunction-return=thunk gcc/testsuite/gcc.target/i386/ret-thunk-26.c
-arch i386
Undefined symbols for architecture i386:
  "__x86_return_thunk", referenced from:
  _foo in ccQ3DlYI.o
  _bar in ccQ3DlYI.o
  _main in ccQ3DlYI.o
 (maybe you meant: ___x86_return_thunk)
ld: symbol(s) not found for architecture i386
collect2: error: ld returned 1 exit status
$
$ gcc8 -v
Using built-in specs.
COLLECT_GCC=gcc8
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin17.5.0/8.2.0/lto-wrapper
Target: x86_64-apple-darwin17.5.0
Configured with: ../gcc-8.2.0/configure --prefix=/opt/local --program-suffix=8
--enable-languages=c,c++,fortran --enable-checking=release --disable-nls
--with-system-zlib
Thread model: posix
gcc version 8.2.0 (GCC) 
$

[Bug c/89410] [7/8/9 Regression] ICE in calculate_line_spans, at diagnostic-show-locus.c:1237 after #line

[segher at gcc dot gnu.org]

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

--- Comment #11 from Segher Boessenkool  ---
(In reply to Jonny Grant from comment #9)
> Maybe zero could be disallowed too.

Yes, but maybe we need that for historical reasons.

> Not sure what is best here, I'm not knowledgeable of GCC, but maybe setting
> it to -1 if it goes above, and then never increment again if(-1 == line) ...

The testcase will still ICE then...  The assert is

  /* The spans must be ordered.  */
  gcc_assert (prev->m_first_line < next->m_first_line);

[Bug target/89400] [7/8/9 Regression] ICE: output_operand: invalid %-code with -march=armv6kz -mthumb -munaligned-access

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||ramana at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
All the "unaligned_access" instructions use %? in the patterns (except the last
one) where %? is TARGET_32BIT specific.
If the unaligned loads/stores don't really work for thumb1, then

  if (! opts_set->x_unaligned_access)
{
  opts->x_unaligned_access = (TARGET_32BIT_P (opts->x_target_flags)
  && arm_arch6 && (arm_arch_notm || arm_arch7));
}
  else if (opts->x_unaligned_access == 1
   && !(arm_arch6 && (arm_arch_notm || arm_arch7)))
{
  warning (0, "target CPU does not support unaligned accesses");
 opts->x_unaligned_access = 0;
}
should be changed to:
  else if (opts->x_unaligned_access == 1
   && (!(arm_arch6 && (arm_arch_notm || arm_arch7))
   || !TARGET_32BIT_P (opts->x_target_flags)))
If the unaligned_access instructions are also for thumb1, then perhaps they
need to set predicable to no for !TARGET_32BIT e.g. based on isa attribute and
avoid using %? in the thumb1 alternative patterns.

[Bug c++/89421] [9 Regression] ICE in retrieve_specialization, at cp/pt.c:1245

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-02-20
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
r266056.

[Bug target/89400] [7/8/9 Regression] ICE: output_operand: invalid %-code with -march=armv6kz -mthumb -munaligned-access

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |7.5

--- Comment #1 from Jakub Jelinek  ---
r228540 compiled this fine with these options, r228940 already ICEs, though
with
pr89400.c: In function ‘foo’:
pr89400.c:7:1: error: unrecognizable insn:
 }
 ^
(insn 9 8 10 2 (set (reg:SI 116)
(zero_extend:SI (unspec:HI [
(mem:HI (reg/f:SI 111 [ b.1_3 ]) [0 MEM[(char *
{ref-all})b.1_3]+0 S2 A8])
] UNSPEC_UNALIGNED_LOAD))) pr89400.c:6 -1
 (nil))
Maybe started with r228643?
The invalid %-code appeared in between r230540 and r231340, maybe r231114 or
r230664 or r230663.

[Bug fortran/80408] Problems with SIGNAL, pthread and print together

[raphael.monod at wanadoo dot fr]

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

--- Comment #4 from Raphael Monod  ---
Thank you for your answer. But I don't understand why adding -lpthread option
change the behavior if I do not use any thread. Moreover, if I refer to this
page ( https://docs.oracle.com/cd/E19455-01/806-5257/gen-26/index.html ) write
statement seems to be async-signal safe ? Where am I wrong ?
Finaly, what can I do if I want to print a message in my trap function ?
Thank you for your interest to my problem.

[Bug middle-end/89423] -fvtable-verify does not work properly with -flto

[ctice at gcc dot gnu.org]

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

ctice at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-02-20
   Assignee|unassigned at gcc dot gnu.org  |ctice at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug middle-end/89423] New: -fvtable-verify does not work properly with -flto

[ctice at gcc dot gnu.org]

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

Bug ID: 89423
   Summary: -fvtable-verify does not work properly with -flto
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ctice at gcc dot gnu.org
  Target Milestone: ---

When compiled with '-flto' the extra internal functions that VTV generates,and
which are necessary for it to work correctly, do not get propagated into the
final binary.  You can see this compiling the bb_tests.cc test case in the
libvtv testsuite, and grepping for 'GLOBAL' in the final output:

$ /usr/local/google3/cmtice/gcc-fsf.root/usr/local/bin/g++ -o bb_tests
bb_tests.cc -O1 -fvtable-verify=std  // Compile without flto
$ nm bb_tests | grep GLOBAL
00601000 d _GLOBAL_OFFSET_TABLE_
00400930 t _GLOBAL__sub_I.00099__Z14get_cond_value

$ /usr/local/google3/cmtice/gcc-fsf.root/usr/local/bin/g++ -o
bb_tests_flto bb_tests.cc -O1 -flto -fvtable-verify=std   // Compile
with flto
$ nm bb_tests_flto | grep GLOBAL
00601000 d _GLOBAL_OFFSET_TABLE_

[Bug libfortran/78314] [aarch64] ieee_support_halting does not report unsupported fpu traps correctly

[wilco at gcc dot gnu.org]

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

--- Comment #25 from Wilco  ---
(In reply to Steve Ellcey from comment #24)
> See email strings at:
> 
> https://gcc.gnu.org/ml/fortran/2019-01/msg00276.html
> https://gcc.gnu.org/ml/fortran/2019-02/msg00057.html
> 
> For more discussion.

Sure, it looks like we simply need to reinstate Szabolc's patch with a #ifdef
arm/aarch64 around it. I need to find out whether a feclearexcept
(FE_ALL_EXCEPT) is necessary on Arm targets which can trap (very few exist
IIRC).

[Bug c++/89403] [7/8/9 Regression] ICE in maybe_clone_body, at cp/optimize.c:693

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 45780
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45780=edit
gcc9-pr89403.patch

Untested fix.  The problem is that maybe_clone_body really doesn't expect to be
called multiple times on the same function.

[Bug c++/89422] New: [8/9 Regression] ICE in field_byte_offset, at dwarf2out.c:19086

[gs...@t-online.de]

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

Bug ID: 89422
   Summary: [8/9 Regression] ICE in field_byte_offset, at
dwarf2out.c:19086
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started with gcc-8 and option -g :


$ cat z1.cc
template  struct S
{
  friend void foo (int a = []{ return 0; }()) {}
  int b;
};
S<0> t;



$ g++-9-20190217 -c z1.cc
$
$ g++-9-20190217 -c z1.cc -g
z1.cc: In instantiation of 'struct S<0>':
z1.cc:6:6:   required from here
z1.cc:3:28: internal compiler error: Segmentation fault
3 |   friend void foo (int a = []{ return 0; }()) {}
  |^~~
0xba166f crash_signal
../../gcc/toplev.c:326
0x8ac58e field_byte_offset
../../gcc/dwarf2out.c:19086
0x8ad27d add_data_member_location_attribute
../../gcc/dwarf2out.c:19365
0x8adb96 gen_field_die
../../gcc/dwarf2out.c:24290
0x898b5f gen_field_die
../../gcc/dwarf2out.c:24266
0x898b5f gen_decl_die
../../gcc/dwarf2out.c:26419
0x89a6a7 gen_member_die
../../gcc/dwarf2out.c:25169
0x89a6a7 gen_struct_or_union_type_die
../../gcc/dwarf2out.c:25265
0x89a6a7 gen_tagged_type_die
../../gcc/dwarf2out.c:25466
0x89b1ac gen_type_die_with_usage
../../gcc/dwarf2out.c:25661
0x89a2b7 gen_tagged_type_die
../../gcc/dwarf2out.c:25435
0x89b1ac gen_type_die_with_usage
../../gcc/dwarf2out.c:25661
0x89ba66 gen_type_die
../../gcc/dwarf2out.c:25715
0x8988ce gen_decl_die
../../gcc/dwarf2out.c:26347
0x899376 dwarf2out_decl
../../gcc/dwarf2out.c:26892
0x89963c dwarf2out_type_decl
../../gcc/dwarf2out.c:26619
0xadd0c2 rest_of_type_compilation(tree_node*, int)
../../gcc/passes.c:339
0x615b4d finish_struct_1(tree_node*)
../../gcc/cp/class.c:7068
0x616f74 finish_struct(tree_node*, tree_node*)
../../gcc/cp/class.c:7212
0x6f97e6 tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.c:18126

[Bug c++/89420] [9 Regression] ICE: unexpected expression 'int()' of kind cast_expr

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-02-20
 CC||mpolacek at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
r265641

[Bug c++/89420] [9 Regression] ICE: unexpected expression 'int()' of kind cast_expr

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c++/89421] New: [9 Regression] ICE in retrieve_specialization, at cp/pt.c:1245

[gs...@t-online.de]

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

Bug ID: 89421
   Summary: [9 Regression] ICE in retrieve_specialization, at
cp/pt.c:1245
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed between 2018 and 20181118 :


$ cat z1.cc
template < //>
auto c = []{ return []{}; }();


$ g++-9-20190217 -c z1.cc
z1.cc:2:29: internal compiler error: Segmentation fault
2 | auto c = []{ return []{}; }();
  | ^
0xe32b7f crash_signal
../../gcc/toplev.c:326
0x7c6c75 tree_check(tree_node*, char const*, int, char const*, tree_code)
../../gcc/tree.h:3175
0x7c6c75 retrieve_specialization
../../gcc/cp/pt.c:1245
0x815564 instantiate_decl(tree_node*, bool, bool)
../../gcc/cp/pt.c:24335
0x6ef537 maybe_instantiate_decl
../../gcc/cp/decl2.c:5281
0x6f221c mark_used(tree_node*, int)
../../gcc/cp/decl2.c:5437
0x627aba build_over_call
../../gcc/cp/call.c:7945
0x63b0a8 build_op_call_1
../../gcc/cp/call.c:4671
0x63b0a8 build_op_call(tree_node*, vec**, int)
../../gcc/cp/call.c:4700
0x83c0b3 finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../gcc/cp/semantics.c:2586
0x78cad6 cp_parser_postfix_expression
../../gcc/cp/parser.c:7373
0x79bc95 cp_parser_unary_expression
../../gcc/cp/parser.c:8459
0x77347f cp_parser_cast_expression
../../gcc/cp/parser.c:9345
0x773c92 cp_parser_binary_expression
../../gcc/cp/parser.c:9446
0x774da9 cp_parser_assignment_expression
../../gcc/cp/parser.c:9742
0x774705 cp_parser_constant_expression
../../gcc/cp/parser.c:10026
0x774d51 cp_parser_initializer_clause
../../gcc/cp/parser.c:22702
0x779737 cp_parser_initializer
../../gcc/cp/parser.c:22642
0x79e683 cp_parser_default_argument
../../gcc/cp/parser.c:22537
0x79e683 cp_parser_parameter_declaration
../../gcc/cp/parser.c:22430

[Bug c++/89420] New: [9 Regression] ICE: unexpected expression 'int()' of kind cast_expr

[gs...@t-online.de]

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

Bug ID: 89420
   Summary: [9 Regression] ICE: unexpected expression 'int()' of
kind cast_expr
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed between 20181028 and 20181104 (with any -std) :

$ cat z1.cc
template 


$ g++-9-20190217 -c z1.cc
z1.cc:1:11: warning: 'explicit(bool)' only available with -std=c++2a or
-std=gnu++2a
1 | template 
  |   ^~~~
z1.cc:1:26: internal compiler error: unexpected expression 'int()' of kind
cast_expr
1 | template 
  |  ^
0x620880 cxx_eval_constant_expression
../../gcc/cp/constexpr.c:5001
0x622104 cxx_eval_outermost_constant_expr
../../gcc/cp/constexpr.c:5115
0x6243d0 maybe_constant_value(tree_node*, tree_node*, bool)
../../gcc/cp/constexpr.c:5347
0x74ade7 check_narrowing(tree_node*, tree_node*, int, bool)
../../gcc/cp/typeck2.c:931
0x5f95b0 convert_like_real
../../gcc/cp/call.c:7366
0x603692 build_converted_constant_expr(tree_node*, tree_node*, int)
../../gcc/cp/call.c:4215
0x6466d2 build_explicit_specifier(tree_node*, int)
../../gcc/cp/decl.c:16687
0x6ab02c cp_parser_function_specifier_opt
../../gcc/cp/parser.c:14236
0x6b6be0 cp_parser_decl_specifier_seq
../../gcc/cp/parser.c:13945
0x6ce143 cp_parser_parameter_declaration
../../gcc/cp/parser.c:22266
0x6cf003 cp_parser_template_parameter
../../gcc/cp/parser.c:15979
0x6cf003 cp_parser_template_parameter_list
../../gcc/cp/parser.c:15562
0x6d457d cp_parser_explicit_template_declaration
../../gcc/cp/parser.c:27955
0x6d457d cp_parser_template_declaration_after_export
../../gcc/cp/parser.c:27989
0x6d7119 cp_parser_declaration
../../gcc/cp/parser.c:13122
0x6d775e cp_parser_translation_unit
../../gcc/cp/parser.c:4698
0x6d775e c_parse_file()
../../gcc/cp/parser.c:41039
0x7962a0 c_common_parse_file()
../../gcc/c-family/c-opts.c:1155

[Bug c++/89419] [8/9 Regression] ICE in is_normal_capture_proxy starting with r253601

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-02-20
 CC||jason at gcc dot gnu.org
   Target Milestone|--- |8.3
 Ever confirmed|0   |1

[Bug c++/89419] New: [8/9 Regression] ICE in is_normal_capture_proxy starting with r253601

[jakub at gcc dot gnu.org]

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

Bug ID: 89419
   Summary: [8/9 Regression] ICE in is_normal_capture_proxy
starting with r253601
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

The following testcase started to ICE with -std=c++17 in r253601:
struct A;
struct B {
  struct C { C (); C (C &); } b;
};
struct D { A operator* (); };
struct A {
  template  void foo (T x) { x (this); }
};
struct E {
  auto bar () { return e; }
  D e;
};
struct F { B f; int g; };

int
main ()
{
  E e;
  auto f = *e.bar ();
  auto i = [&] { F g; g.g = 1; auto h = [&](auto) { g.g = 0; }; f.foo (h);
return g; };
}

[Bug fortran/89385] Incorrect members of C descriptor for an allocatable object

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org

--- Comment #3 from Paul Thomas  ---
Created attachment 45779
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45779=edit
Draft patch

One typo, one stupid error and a couple of misunderstood bits in the standard
led to this.

The testcase provided runs OK and the patch bootstraps and regtests.

I will go through the other PRs that you provided and will see what further
fixes are required.

Thanks

Paul

[Bug c++/88572] error: braces around scalar initializer - should be a warning

[wjwray at gmail dot com]

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

Will Wray  changed:

   What|Removed |Added

  Attachment #45683|0   |1
is obsolete||

--- Comment #16 from Will Wray  ---
Created attachment 45778
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45778=edit
Updated patch addressing review comments

(Updated Change Log entry for decl.c)

Log:
PR c++/88572
* decl.c (reshape_init_r): Remove condition that was incorrectly
rejecting braces around scalar initializer within aggregate init. 
Produce no warning. Add a conditional block rejecting braced-init
of scalar variable, including empty-brace value-initialization
that was being incorrectly accepted.

[Bug c/89410] [7/8/9 Regression] ICE in calculate_line_spans, at diagnostic-show-locus.c:1237 after #line

[dmalcolm at gcc dot gnu.org]

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

--- Comment #10 from David Malcolm  ---
(In reply to Jonny Grant from comment #4)
> There's another related issue, can it be covered on this ticket?
> 
> GCC does not show the part of the output below I marked with after
> commenting out line 4 <-
> 
> #1 with x86-64 gcc (trunk)
> : In function 'main':
> :6:7: warning: line number out of range
> 6 | #line 9223372036854775807<-
>   |   ^~~
> 
> 
> 
> 
> int main(void)
> {
> // Note: Comment back in the next line to reproduce
> //#line 12147483647
> 
> #line 9223372036854775807
> }

What's happening is that GCC is honoring the earlier #line directive, and it
attempts to load the source for that line; there aren't that many lines in the
file, so it doesn't print anything.

[Bug c/89410] [7/8/9 Regression] ICE in calculate_line_spans, at diagnostic-show-locus.c:1237 after #line

[jg at jguk dot org]

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

--- Comment #9 from Jonny Grant  ---
(In reply to Segher Boessenkool from comment #8)
> The C standard does not allow the line number (in a #line directive) to be
> smaller than 1 or bigger than 0x7fff.  It says nothing about actually
> having this many lines, or overflowing the line number with following lines,
> but I suppose we could disallow that as well.

int main(void)
{
#line 0
}

#1 with x86-64 gcc (trunk)
Compiler returned: 0

Maybe zero could be disallowed too.



> As the ICEs show many parts of GCC assume line numbers increase, so the
> wrap-around signed integer is a problem (it is anyway, it's UB in the
> compiler
> itself).  We could make the line number saturate, but this particular ICE
> won't
> go away unless line numbers are strictly increasing (or the code is changed).
> Changing the type to 64 bit won't help at all either, of course (we never
> actually see source files of 2G lines, already).

Not sure what is best here, I'm not knowledgeable of GCC, but maybe setting it
to -1 if it goes above, and then never increment again if(-1 == line) ...

[Bug c++/89357] alignas for automatic variables with alignment greater than 16 fails

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords|accepts-invalid |rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-02-20
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||8.2.0, 9.0

--- Comment #3 from Martin Sebor  ---
Confirmed.

The reason why the __attribute__ is accepted is because it's not considered a
C++ 11 form of specifying alignment and so it's subject to less checking (done
by the check_cxx_fundamental_alignment_constraints function).

The alignas form is considered a C++ form (has ATTR_FLAG_CXX11 bit set in flags
below) and so makes it pass the first test. The cxx_fundamental_alignment_p()
test also fails (the fundamental alignment on aarch64 is 16).  The third if
statement is entered, followed by the else block of the inner if.  There,
MAX_STACK_ALIGNMENT is used as the upper bound.  On aarch64,
MAX_STACK_ALIGNMENT is defined to STACK_BOUNDARY which is 16, and that is why
alignas(128) is considered invalid.  In contrast, on x86_64,
MAX_STACK_ALIGNMENT is defined to MAX_OFILE_ALIGNMENT, both of which are
2147483648.

So either MAX_STACK_ALIGNMENT on aarch64 is wrong or the test in
check_cxx_fundamental_alignment_constraint is wrong.

MAX_STACK_ALIGNMENT is defined in section 18.5 Storage Layout of the internals
manual as:

  Biggest stack alignment guaranteed by the backend. Use this macro to specify
the maximum alignment of a variable on stack.

and with the following (far more descriptive) comment in gcc/defaults.h:

/* MAX_STACK_ALIGNMENT is the maximum stack alignment guaranteed by
   the backend.  MAX_SUPPORTED_STACK_ALIGNMENT is the maximum best
   effort stack alignment supported by the backend.  If the backend
   supports stack alignment, MAX_SUPPORTED_STACK_ALIGNMENT and
   MAX_STACK_ALIGNMENT are the same.  Otherwise, the incoming stack
   boundary will limit the maximum guaranteed stack alignment.  */

It's a little ambiguous but my guess is that MAX_STACK_ALIGNMENT is meant to be
the maximum alignment the back-end will maintain for the stack pointer in
general, independent of any overaligned variables, and isn't intended as
constraint on the alignment of explicitly overaligned stack variables.  (I can
think of no reason why the back-end would impose any such constraint on the
stack.)  If that's correct the test for MAX_STACK_ALIGNMENT is the bug.  The
test was introduced with the implementation of the alignas specifier in
r192199.

check_cxx_fundamental_alignment_constraints (tree node,
 unsigned align_log,
 int flags)
{
  bool alignment_too_large_p = false;
  unsigned requested_alignment = (1U << align_log) * BITS_PER_UNIT;
  unsigned max_align = 0;

  if ((!(flags & ATTR_FLAG_CXX11) && !warn_cxx_compat)
  || (node == NULL_TREE || node == error_mark_node))
return true;

  if (cxx_fundamental_alignment_p (requested_alignment))
return true;

  if (VAR_P (node))
{
  if (TREE_STATIC (node) || DECL_EXTERNAL (node))
/* For file scope variables and static members, the target supports
   alignments that are at most MAX_OFILE_ALIGNMENT.  */
max_align = MAX_OFILE_ALIGNMENT;
  else
/* For stack variables, the target supports at most
   MAX_STACK_ALIGNMENT.  */
max_align = MAX_STACK_ALIGNMENT;
  if (requested_alignment > max_align)
alignment_too_large_p = true;
}

[Bug c++/88294] [9 Regression] ICE on (invalid) C++11 code: in tsubst_copy, at cp/pt.c:15391

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek  ---
A similar test crashes:

bool b;

template struct A
{
  void g () noexcept (b) { }
};

int main ()
{
  A a;
  a.g ();
}

but that's PR88987.

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

[seurer at gcc dot gnu.org]

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

 Target||powerpc64le-unknown-linux-g
   ||nu
   Host||powerpc64le-unknown-linux-g
   ||nu
  Build||powerpc64le-unknown-linux-g
   ||nu

--- Comment #1 from seurer at gcc dot gnu.org ---
Note that these error messages only occur on powerpc64le.  BE seems to work OK.

[Bug target/80204] macosx-version-min wrong for macOS Sierra 10.12.3

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #7 from Eric Gallager  ---
(In reply to simon from comment #6)
> Selected output from "gcc empty.c -v -Wl,-v" on macOS 10.14.1 (darwin
> 18.2.0), 
> with gcc 9.0.0 20181103 built on x86_64-apple-darwin15, correctly showing 
> -mmacosx-version-min=10.14.0 & equivalents throughout.
> 
> Equivalent success with 8.1.0.
> 
> 
> 
> Target: x86_64-apple-darwin15
> Configured with: /Volumes/Miscellaneous/tmp/gcc/configure
>  --prefix=/Volumes/Miscellaneous/tmp/opt/gcc-9.0.0 
>  --without-libiconv-prefix --disable-libmudflap --disable-libstdcxx-pch 
>  --disable-libsanitizer --disable-libcc1 --disable-libcilkrts 
>  --disable-multilib --disable-nls --enable-languages=c,c++,ada 
>  --disable-bootstrap --host=x86_64-apple-darwin15 
>  --target=x86_64-apple-darwin15 --build=x86_64-apple-darwin15 
>  --with-boot-ldflags='-static-libstdc++ -static-libgcc
> -Wl,-headerpad_max_install_names'
> Thread model: posix
> gcc version 9.0.0 20181103 (experimental) (GCC) 
> COLLECT_GCC_OPTIONS='-v' '-mmacosx-version-min=10.14.0' 
>  '-asm_macosx_version_min=10.14' '-mtune=core2'
>  /opt/gcc-9.0.0/bin/../libexec/gcc/x86_64-apple-darwin15/9.0.0/cc1
>  -quiet -v -iprefix
> /opt/gcc-9.0.0/bin/../lib/gcc/x86_64-apple-darwin15/9.0.0/
>  -D__DYNAMIC__ empty.c -fPIC -quiet -dumpbase empty.c
>  -mmacosx-version-min=10.14.0 -mtune=core2 -auxbase empty -version
>  -o /var/folders/_q/fvnxz46903z9hjh38fz0lyhmgs/T//cc2Zzpgh.s
> 
> 
> 
>  as -arch x86_64 -v -force_cpusubtype_ALL -mmacosx-version-min=10.14
>  -o /var/folders/_q/fvnxz46903z9hjh38fz0lyhmgs/T//cc9YzAyh.o
>  /var/folders/_q/fvnxz46903z9hjh38fz0lyhmgs/T//cc2Zzpgh.s
> Apple LLVM version 10.0.0 (clang-1000.10.44.4)
> Target: x86_64-apple-darwin18.2.0
> Thread model: posix
> InstalledDir: /Library/Developer/CommandLineTools/usr/bin
>  "/Library/Developer/CommandLineTools/usr/bin/clang" -cc1as
>  -triple x86_64-apple-macosx10.14.0 -filetype obj
>  -main-file-name cc2Zzpgh.s -target-cpu penryn -fdebug-compilation-dir
>  /Users/simon/tmp -dwarf-debug-producer Apple LLVM version 10.0.0
> (clang-1000.10.44.4) -dwarf-version=4 -mrelocation-model pic -o
> /var/folders/_q/fvnxz46903z9hjh38fz0lyhmgs/T//cc9YzAyh.o
> /var/folders/_q/fvnxz46903z9hjh38fz0lyhmgs/T//cc2Zzpgh.s
> 
> 
> 
> /usr/bin/ld -dynamic -arch x86_64 -macosx_version_min 10.14.0
>  -weak_reference_mismatches non-weak -o a.out
>  -L/opt/gcc-9.0.0/bin/../lib/gcc/x86_64-apple-darwin15/9.0.0
>  -L/opt/gcc-9.0.0/bin/../lib/gcc
>  -L/opt/gcc-9.0.0/bin/../lib/gcc/x86_64-apple-darwin15/9.0.0/../../..
>  -v /var/folders/_q/fvnxz46903z9hjh38fz0lyhmgs/T//cc9YzAyh.o
>  -no_compact_unwind -lSystem -lgcc_ext.10.5 -lgcc -lSystem -v

So, that sounds like a "yes, this can be closed"

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

[seurer at gcc dot gnu.org]

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

Bug ID: 89418
   Summary: D test cases fail on powerpc64le
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

FAIL: gdc.test/compilable/ctfe_math.d -O2output-exists ctfe_math.o
FAIL: gdc.test/compilable/ctfe_math.d -O2 -freleaseoutput-exists
ctfe_math.o
FAIL: gdc.test/compilable/ctfe_math.d -freleaseoutput-exists ctfe_math.o
FAIL: gdc.test/compilable/ctfe_math.d -goutput-exists ctfe_math.o
FAIL: gdc.test/compilable/ctfe_math.d -g -O2output-exists ctfe_math.o
FAIL: gdc.test/compilable/ctfe_math.d -g -O2 -freleaseoutput-exists
ctfe_math.o
FAIL: gdc.test/compilable/ctfe_math.d -g -freleaseoutput-exists ctfe_math.o
FAIL: gdc.test/compilable/test5227.d   output-exists test5227.o

spawn -ignore SIGHUP
/home/seurer/gcc/build/gcc-test/gcc/testsuite/gdc8/../../gdc
-B/home/seurer/gcc/build/gcc-test/gcc/testsuite/gdc8/../../
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never
-I/home/seurer/gcc/gcc-test/gcc/testsuite/../../libphobos/libdruntime
-I/home/seurer/gcc/gcc-test/gcc/testsuite/../../libphobos/src
-I/home/seurer/gcc/gcc-test/gcc/testsuite/../../libstdc++-v3/libsupc++ -g
-I/home/seurer/gcc/gcc-test/gcc/testsuite/gdc.test/compilable -c -o ctfe_math.o
compilable/ctfe_math.d
/home/seurer/gcc/gcc-test/libphobos/src/std/math.d:244:5: error: static assert 
"Only 64-bit, 80-bit, and 128-bit reals are supported for LittleEndian CPUs"
compiler exited with status 1

package:
// The following IEEE 'real' formats are currently supported.
version (LittleEndian)
{
static assert(real.mant_dig == 53 || real.mant_dig == 64
   || real.mant_dig == 113,
  "Only 64-bit, 80-bit, and 128-bit reals"~
  " are supported for LittleEndian CPUs");
}
else
{
static assert(real.mant_dig == 53 || real.mant_dig == 106
   || real.mant_dig == 113,
"Only 64-bit and 128-bit reals are supported for BigEndian CPUs."~
" double-double reals have partial support");
}


I don't really know enough about D to diagnose this much further.

[Bug c/53063] encode group options in the .opt files

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #12 from Eric Gallager  ---
(In reply to Martin Liška from comment #11)
> Can the bug be marked as resolved?

WAITING on a reply

[Bug other/84889] Ideas on revamping how we format diagnostics

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

--- Comment #15 from Eric Gallager  ---
(In reply to Martin Liška from comment #14)
> David: Can the bug be marked as resolved?

WAITING on a reply

[Bug ipa/86395] add support of -fopt-info-inline in inliner

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

--- Comment #7 from Eric Gallager  ---
(In reply to Martin Liška from comment #6)
> David: Can the bug be marked as resolved?

WAITING on a reply

[Bug c/89410] [7/8/9 Regression] ICE in calculate_line_spans, at diagnostic-show-locus.c:1237 after #line

[segher at gcc dot gnu.org]

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

--- Comment #8 from Segher Boessenkool  ---
The C standard does not allow the line number (in a #line directive) to be
smaller than 1 or bigger than 0x7fff.  It says nothing about actually
having this many lines, or overflowing the line number with following lines,
but I suppose we could disallow that as well.

As the ICEs show many parts of GCC assume line numbers increase, so the
wrap-around signed integer is a problem (it is anyway, it's UB in the compiler
itself).  We could make the line number saturate, but this particular ICE won't
go away unless line numbers are strictly increasing (or the code is changed).
Changing the type to 64 bit won't help at all either, of course (we never
actually see source files of 2G lines, already).

[Bug c/35592] Want attribute to enable precision loss warning

[egallager at gcc dot gnu.org]

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

--- Comment #8 from Eric Gallager  ---
Created attachment 45777
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45777=edit
testcase

(In reply to felix-gcc from comment #6)
> Sure. For example:
> 
>   char* c=malloc(lseek(somefd,0,SEEK_END);
> 
> on a platform where off_t is 64-bit, but where size_t is 32-bit.  For
> example: i686-linux with #define _FILE_OFFSET_BITS 64.
> 
> Now that I'm thinking about it, would it be possible to have a generic
> overflow warning in that context?  For example,
> 
>   malloc(p->len+1)
> 
> So that gcc sees I'm adding something there, and if the range is not clamped
> down before that gives an error?

I combined those into a testcase which is attached. I thought the new
-Walloc-size-larger-than= warning that (I think it was) Martin added would
catch it, but apparently not?

[Bug libgcc/89417] New: helgrind detects a lock order violation inside std::scoped_lock

[federico.kircheis at gmail dot com]

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

Bug ID: 89417
   Summary: helgrind detects a lock order violation inside
std::scoped_lock
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: federico.kircheis at gmail dot com
  Target Milestone: ---

Created attachment 45776
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45776=edit
helgrind log output

Hello,

Im unsure if this is a bug or feature request, depending on who is "wrong"
(g++/valgrind)

I'm using g++ (Debian 8.2.0-14) 8.2.0, and the program is compiled with
following flags: "-std=c++17 -lpthread"

Consider following snippet of code:


int main(){
std::mutex m1;
std::mutex m2;
int data1{};
int data2{};
auto f1 = std::async(std::launch::async, [&](){
std::scoped_lock sl{m1, m2};
++data1;
++data2;
return data1;
});
auto f2 = std::async(std::launch::async, [&](){
std::scoped_lock sl{m2, m1};
++data1;
++data2;
return data2;
});
return f1.get() + f2.get(); // result should be 3
}


helgrind (valgrind-3.14.0) reports that the lock order is violated: error
message attached)


it prints exactly the same error for


int main(){
std::mutex m1;
std::mutex m2;
int data1{};
int data2{};
auto f1 = std::async(std::launch::async, [&](){
std::lock_guard lg1{m1};std::lock_guard lg2{m2};
++data1;
++data2;
return data1;
});
auto f2 = std::async(std::launch::async, [&](){
std::lock_guard lg1{m1};std::lock_guard lg2{m2};
++data1;
++data2;
return data2;
});
return f1.get() + f2.get(); // result should be 3
}


In case helgrind is correct, it seems that there are some issues behind
std::scoped_lock, since it was explicitly designed for solving issues with lock
order.

In case helgrind (and possibly for the same reason other tools) is wrong, this
is would be a feature request.


A possible fix (or improvement) would be for `std::scoped_lock` to sort its
arguments by address (since std::mutex are not copyable or movable, and thus
their address should remain constant):


auto make_lock(std::mutex& m1_, std::mutex& m2_) {
const auto mless = std::less{};
return std::scoped_lock{*std::min(_, _, mless), *std::max(_,
_, mless)}; 
}

int main(){
std::mutex m1;
std::mutex m2;
int data1{};
int data2{};
auto f1 = std::async(std::launch::async, [&](){
auto sl = make_lock(m1,m2);
++data1;
++data2;
return data1;
});
auto f2 = std::async(std::launch::async, [&](){
auto sl = make_lock(m2,m1);
++data1;
++data2;
return data2;
});
return f1.get() + f2.get(); // result should be 3
}


in this case, helgrind does not generate any warning.
I do not know the internal algorithm of `std::scoped_lock`, so it might be
completely wrong, but sorting by address might also avoid possible live-lock
issues.

[Bug sanitizer/89308] [8 only] The sanitizers do no longer work on GCC 8 with newer kernels

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|NEW |SUSPENDED

--- Comment #9 from Segher Boessenkool  ---
We do not currently see problems in practice.  Suspending.

[Bug sanitizer/89409] [9 Regression] FAIL: c-c++-common/ubsan/div-by-zero-[67].c

[hjl at gcc dot gnu.org]

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

--- Comment #5 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Wed Feb 20 16:20:50 2019
New Revision: 269042

URL: https://gcc.gnu.org/viewcvs?rev=269042=gcc=rev
Log:
libsanitizer: Restore internal_readlink for x32

Cherry-pick compiler-rt revision 354451:

r316591 has

@@ -389,13 +383,11 @@ uptr internal_dup2(int oldfd, int newfd) {
 }

 uptr internal_readlink(const char *path, char *buf, uptr bufsize) {
-#if SANITIZER_NETBSD
-  return internal_syscall_ptr(SYSCALL(readlink), path, buf, bufsize);
-#elif SANITIZER_USES_CANONICAL_LINUX_SYSCALLS
+#if SANITIZER_USES_CANONICAL_LINUX_SYSCALLS
   return internal_syscall(SYSCALL(readlinkat), AT_FDCWD,
   (uptr)path, (uptr)buf, bufsize);
 #else
-  return internal_syscall(SYSCALL(readlink), (uptr)path, (uptr)buf, bufsize);
+  return internal_syscall_ptr(SYSCALL(readlink), path, buf, bufsize);
 #endif
 }

which dropped the (uptr) cast and broke x32.  This patch puts back the
(uptr) cast to restore x32 and fixes:

https://bugs.llvm.org/show_bug.cgi?id=40783

Differential Revision: https://reviews.llvm.org/D58413

PR sanitizer/89409
* sanitizer_common/sanitizer_linux.cc (internal_readlink):
Cherry-pick compiler-rt r354451.

Modified:
trunk/libsanitizer/ChangeLog
trunk/libsanitizer/sanitizer_common/sanitizer_linux.cc

[Bug middle-end/89270] [9 regression] AVR ICE: verify_gimple failed

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||jakub at gcc dot gnu.org

[Bug c++/52130] missing check for matching underlying type during instantiation of enum member of class template

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||redi at gcc dot gnu.org

--- Comment #4 from Eric Gallager  ---
What should the correct diagnostic message for it say instead then?

[Bug tree-optimization/88973] [8/9 Regression] New -Wrestrict warning since r268048

[msebor at gcc dot gnu.org]

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

--- Comment #8 from Martin Sebor  ---
The Asan warning is much clearer because it's based on actually observed
values.  This instance of the -Wrestrict warning is based on a heuristic: "we
think the copy may overlap because it is within the same object and we can't
prove that the offsets and the size assure it doesn't happen."

There may be a way to reword the warning to make things a little bit clearer
but I don't think we can match the Asan form.  When the offsets and the size
are completely unbounded we could just avoid printing them altogether.  That
would make it:

  'strcpy' accessing the same array may overlap [-Werror=restrict]

When the size is known it would give us:

  'strcpy' accessing N bytes of the same array may overlap [-Werror=restrict]

and when the offsets are known but the size isn't:

  'strcpy' accessing the same array at offsets [O1, O2] and [O3, O4] may
overlap [-Werror=restrict]

and so on.

There are many forms of the -Wrestrict warning already: singular size (1 byte)
vs plural size (bytes) vs closed range (between X and Y bytes) vs open range (X
or more bytes), constant offsets vs closed ranges ([X, Y]), definitely overlaps
vs may overlap, and others, and because of internationalization most have to be
hardcoded and can't be easily parameterized, so adding a new form into the mix
isn't completely straightforward.

[Bug target/80505] FAIL: gcc.dg/ipa/iinline-attr.c scan-ipa-dump inline "hooray[^\\n]*inline copy in test"

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #6 from Segher Boessenkool  ---
This all works now.  Please reopen if you still see FAILs.

[Bug c/89410] [7/8/9 Regression] ICE in calculate_line_spans, at diagnostic-show-locus.c:1237 after #line

[jg at jguk dot org]

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

--- Comment #7 from Jonny Grant  ---
(In reply to Jonny Grant from comment #6)
> Could this show the offending number in the "line number out of range"
> message? And even the origin of the LINE1 macro too?

clang shows the origin of the offending LINE1 macro

#1 with x86-64 clang (trunk)
:4:7: error: #line directive requires a positive integer argument
#line LINE1
  ^
:1:15: note: expanded from macro 'LINE1'
#define LINE1 112147483647
  ^
1 error generated.
Compiler returned: 1

[Bug target/88055] ICE in extract_insn, at recog.c:2305 on ppc64le

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c/89410] [7/8/9 Regression] ICE in calculate_line_spans, at diagnostic-show-locus.c:1237 after #line

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

[Bug target/89397] [7/8 Regression] ICE in build_call_expr_loc_array at gcc/tree.c:11563 since r229082

[ubizjak at gmail dot com]

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

--- Comment #6 from Uroš Bizjak  ---
Index: config/i386/i386.c
===
--- config/i386/i386.c  (revision 269040)
+++ config/i386/i386.c  (working copy)
@@ -50689,7 +50689,7 @@
 static void
 ix86_atomic_assign_expand_fenv (tree *hold, tree *clear, tree *update)
 {
-  if (!TARGET_80387 && !TARGET_SSE_MATH)
+  if (!TARGET_80387 && !(TARGET_SSE && TARGET_SSE_MATH))
 return;
   tree exceptions_var = create_tmp_var_raw (integer_type_node);
   if (TARGET_80387)
@@ -50724,7 +50724,7 @@
   tree update_fldenv = build_call_expr (fldenv, 1, fenv_addr);
   *update = build2 (COMPOUND_EXPR, void_type_node, *update,
update_fldenv);
 }
-  if (TARGET_SSE_MATH)
+  if (TARGET_SSE && TARGET_SSE_MATH)
 {
   tree mxcsr_orig_var = create_tmp_var_raw (unsigned_type_node);
   tree mxcsr_mod_var = create_tmp_var_raw (unsigned_type_node);

[Bug middle-end/89412] [7/8/9 Regression] gcc ICE in simplify_subreg, at simplify-rtx.c:6273 on i686-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
Created attachment 45775
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45775=edit
gcc9-pr89412.patch

Untested fix.

[Bug middle-end/89091] ICE: Segmentation fault (in tree_class_check)

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Comment on attachment 45774
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45774
Patch

Well, for the decode_field_reference, I think it is essential not to change
*exp_ if returning NULL, because the caller uses lr_arg/rr_arg without checking
whether it returned NULL or not.  The c_common_type_for_size change is
independent of the rest, I'd find it too risky for GCC9, but could be posted
for GCC10.

Sorry for looking on this, I saw you have it ASSIGNED but didn't see any patch
on gcc-patches nor recent progress in the PR and thought some input might help.

[Bug c++/87844] ICE in tsubst_copy using non-constant expression as a non-type template argument

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug rtl-optimization/88347] 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=88347

Segher Boessenkool  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug fortran/89366] Fails to compile BIND(C) interface with assumed-length character argument

[Bader at lrz dot de]

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

--- Comment #5 from Bader at lrz dot de  ---
No. The dummy argument of the procedure process_string is declared

character(kind=c_char,len=*), intent(in) :: this

there is no POINTER or ALLOCATABLE attribute there. 

Regards
Reinhold

[Bug c/89410] [7/8/9 Regression] ICE in calculate_line_spans, at diagnostic-show-locus.c:1237 after #line

[jg at jguk dot org]

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

--- Comment #6 from Jonny Grant  ---
Could this show the offending number in the "line number out of range" message?
And even the origin of the LINE1 macro too?

Actual:
#1 with x86-64 gcc (trunk)
: In function 'main':
:4:7: warning: line number out of range
4 | #line LINE1
  |   ^
Compiler returned: 0


Expected eg:
#1 with x86-64 gcc (trunk)
: In function 'main':
:4:7: warning: line number 112147483647 out of range
4 | #line LINE1
  |   ^

 LINE1 was defined in header.h:10

Compiler returned: 0



#define LINE1 112147483647
int main(void)
{
#line LINE1
}