[Bug tree-optimization/86991] [8 Regression] ICE in vectorizable_reduction, at tree-vect-loop.c:6919

[konstantin.vladimirov at gmail dot com]

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

--- Comment #9 from Tilir  ---
One more test case:

int b[11], e[11], c, d;
void f() {
  unsigned g, h;
  for (; g < 11; g += 2) {
c = 2;
for (; c; c += 3) {
  h = 1;
  for (; h < 11; h++)
e[h] = e[h] + d - b[g];
}
  }
}

[Bug fortran/87689] PowerPC64 ELFv2 function parameter passing violation

[rguenther at suse dot de]

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

--- Comment #18 from rguenther at suse dot de  ---
On February 13, 2019 6:56:15 AM GMT+01:00, amodra at gmail dot com
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87689
>
>--- Comment #17 from Alan Modra  ---
>> On platforms where varargs have a different calling
>> signature from normal functions, this would be an ABI change.
>
>True, but in C terms, gfortran is currently doing this:
>void f (char *res, int reslen);
>..
>  f (res, 20, , , , , , , );
>That's why I said we have "lying prototypes".
>
>The patch in comment #12 changes things to
>void f (char *res, int reslen, ...);
>..
>  f (res, 20, , , , , , , );
>
>Which at least makes the prototype and call compatible in that
>translation
>unit.  

Both indeed look wrong. Afaics if Fortran doesn't require a visible function
definition or declaration it indeed has to build one from the actual call. In
theory it could use a unprototyped function declaration void f() and then use
only a
CALL_EXPR_FNTYPE function type matching the call signature (and hope backends
will be happy with that). That has the advantage of not needing to deal with
mismatches from multiple calls
(multiple decls would be even worse I think) 

We have ABI violations in both cases as neither prototype
>matches the
>actual function definition.  Yes, my patch is just a hack, but..
>
>> It would probably make more sense to build the decl from the call
>> itself.
>This would require major surgery, I think.  Another option would be to
>pass
>info to the backend that the call is really not prototyped despite the
>presence
>of those "hidden" args.
>
>For now, I'm going to post a backend patch for this problem, in
>rs6000_function_parms_need_stack:
>
>  /* FIXME: Fortran arg lists can contain hidden parms, fooling
> prototype_p into saying the function is prototyped when in fact
> the number and type of args is unknown.  See PR 87689.  */
>  if (!incoming && (strcmp (lang_hooks.name, "GNU F77") == 0
>|| lang_GNU_Fortran ()))
>return true;

[Bug middle-end/89328] New: static chain made mandatory

[mpoulhies at kalray dot eu]

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

Bug ID: 89328
   Summary: static chain made mandatory
   Product: gcc
   Version: 7.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpoulhies at kalray dot eu
  Target Milestone: ---

Since r217769, a target without support for static chain will not work.

Previous this change, the message
```
nested functions not supported on this target
```

was displayed only when trying to build something using nested functions.
After this patch, the error is raised for all inputs. I guess because the
following test has been removed:

```
 rtx
-default_static_chain (const_tree fndecl, bool incoming_p)
+default_static_chain (const_tree ARG_UNUSED (fndecl_or_type), bool incoming_p)
 {
-  if (!DECL_STATIC_CHAIN (fndecl))
-return NULL;
-
   if (incoming_p)
 {
```

I guess this was not spotted as it looks like all targets in gcc tree have
static chain support.
This has been a problem while updating a private port from gcc 4.9 to gcc 7. I
could not verify the issue is still in trunk but a quick look at the code let
me think it still is.

[Bug target/89324] [9 Regression] ICE in extract_constrain_insn, at recog.c:2211 on aarch64

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||matmal01 at gcc dot gnu.org

--- Comment #2 from ktkachov at gcc dot gnu.org ---
The sub3_compare1_imm pattern was introduced for GCC 9. It's probably
something going wrong with the constraints. Matthew, could you take a look
please?

[Bug tree-optimization/89223] [7/8 Regression] internal compiler error: in int_cst_value, at tree.c:11226

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Biener  ---
Author: rguenth
Date: Wed Feb 13 10:02:47 2019
New Revision: 268838

URL: https://gcc.gnu.org/viewcvs?rev=268838=gcc=rev
Log:
2019-02-13  Richard Biener  

Backport from mainline
2019-02-12  Richard Biener  

PR tree-optimization/89253
* tree-ssa-loop-split.c (tree_ssa_split_loops): Check we can
duplicate the loop.

* gfortran.dg/pr89253.f: New testcase.

2019-02-08  Richard Biener  

PR middle-end/89223
* tree-data-ref.c (initialize_matrix_A): Fail if constant
doesn't fit in HWI.
(analyze_subscript_affine_affine): Handle failure from
initialize_matrix_A.

* gcc.dg/torture/pr89223.c: New testcase.

2019-01-28  Richard Biener  

PR tree-optimization/88739
* tree-ssa-sccvn.c (vn_reference_lookup_3): Avoid generating
BIT_FIELD_REFs of non-mode-precision integral operands.

* gcc.c-torture/execute/pr88739.c: New test.

Added:
branches/gcc-8-branch/gcc/testsuite/gcc.c-torture/execute/pr88739.c
branches/gcc-8-branch/gcc/testsuite/gcc.dg/torture/pr89223.c
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pr89253.f
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/gcc/tree-data-ref.c
branches/gcc-8-branch/gcc/tree-ssa-loop-split.c
branches/gcc-8-branch/gcc/tree-ssa-sccvn.c

[Bug tree-optimization/88739] [7/8 Regression] Big-endian union bug

[rguenth at gcc dot gnu.org]

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

--- Comment #57 from Richard Biener  ---
Author: rguenth
Date: Wed Feb 13 10:02:47 2019
New Revision: 268838

URL: https://gcc.gnu.org/viewcvs?rev=268838=gcc=rev
Log:
2019-02-13  Richard Biener  

Backport from mainline
2019-02-12  Richard Biener  

PR tree-optimization/89253
* tree-ssa-loop-split.c (tree_ssa_split_loops): Check we can
duplicate the loop.

* gfortran.dg/pr89253.f: New testcase.

2019-02-08  Richard Biener  

PR middle-end/89223
* tree-data-ref.c (initialize_matrix_A): Fail if constant
doesn't fit in HWI.
(analyze_subscript_affine_affine): Handle failure from
initialize_matrix_A.

* gcc.dg/torture/pr89223.c: New testcase.

2019-01-28  Richard Biener  

PR tree-optimization/88739
* tree-ssa-sccvn.c (vn_reference_lookup_3): Avoid generating
BIT_FIELD_REFs of non-mode-precision integral operands.

* gcc.c-torture/execute/pr88739.c: New test.

Added:
branches/gcc-8-branch/gcc/testsuite/gcc.c-torture/execute/pr88739.c
branches/gcc-8-branch/gcc/testsuite/gcc.dg/torture/pr89223.c
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pr89253.f
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/gcc/tree-data-ref.c
branches/gcc-8-branch/gcc/tree-ssa-loop-split.c
branches/gcc-8-branch/gcc/tree-ssa-sccvn.c

[Bug tree-optimization/89253] [8 Regression] ICE in split_loop, at tree-ssa-loop-split.c:566

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Wed Feb 13 10:02:47 2019
New Revision: 268838

URL: https://gcc.gnu.org/viewcvs?rev=268838=gcc=rev
Log:
2019-02-13  Richard Biener  

Backport from mainline
2019-02-12  Richard Biener  

PR tree-optimization/89253
* tree-ssa-loop-split.c (tree_ssa_split_loops): Check we can
duplicate the loop.

* gfortran.dg/pr89253.f: New testcase.

2019-02-08  Richard Biener  

PR middle-end/89223
* tree-data-ref.c (initialize_matrix_A): Fail if constant
doesn't fit in HWI.
(analyze_subscript_affine_affine): Handle failure from
initialize_matrix_A.

* gcc.dg/torture/pr89223.c: New testcase.

2019-01-28  Richard Biener  

PR tree-optimization/88739
* tree-ssa-sccvn.c (vn_reference_lookup_3): Avoid generating
BIT_FIELD_REFs of non-mode-precision integral operands.

* gcc.c-torture/execute/pr88739.c: New test.

Added:
branches/gcc-8-branch/gcc/testsuite/gcc.c-torture/execute/pr88739.c
branches/gcc-8-branch/gcc/testsuite/gcc.dg/torture/pr89223.c
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pr89253.f
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/gcc/tree-data-ref.c
branches/gcc-8-branch/gcc/tree-ssa-loop-split.c
branches/gcc-8-branch/gcc/tree-ssa-sccvn.c

[Bug tree-optimization/89253] [8 Regression] ICE in split_loop, at tree-ssa-loop-split.c:566

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||8.2.1
 Resolution|--- |FIXED

--- Comment #4 from Richard Biener  ---
Fixed.

[Bug c++/89299] __attribute__ cleanup does not accept template function

[paradox_ptr at protonmail dot ch]

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

--- Comment #6 from paradox_ptr at protonmail dot ch ---
(In reply to Martin Sebor from comment #4)
> I'm curious about the use case: can you describe what you are using
> the attribute for in C++?

I don't have a meaningful use case for you.

Was merging old C program into C++ codebase, and was very surprised when this
part did not compile.

[Bug other/89327] New: Joined options without RejectsNegative

[jakub at gcc dot gnu.org]

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

Bug ID: 89327
   Summary: Joined options without RejectsNegative
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

While for some Joined options starting with m, W or f the negative options make
perfect sense, e.g. -fno-builtin-malloc,
-fno-sanitize-recover=signed-integer-overflow etc., for the following ones I
wonder if it isn't just an omission.

Thoughts on this?

./config/riscv/riscv.opt:msmall-data-limit=
./config/riscv/riscv.opt:Target Joined Separate UInteger Var(g_switch_value)
Init(8)
./config/darwin.opt:mmacosx-version-min=
./config/darwin.opt:Target Joined Report Var(darwin_macosx_version_min)
Init(DEF_MIN_OSX_VERSION)
./go/lang.opt:fgo-optimize-
./go/lang.opt:Go Joined
./go/lang.opt:fgo-debug-escape
./go/lang.opt:Go Joined UInteger Var(go_debug_escape_level) Init(0)
./common.opt:fhelp=
./common.opt:Common Driver Joined Alias(-help=)
./common.opt:fdiagnostics-minimum-margin-width=
./common.opt:Common Joined UInteger Var(diagnostics_minimum_margin_width)
Init(6)
./common.opt:foffload=
./common.opt:Common Driver Joined MissingArgError(options or targets missing
after %qs)
./common.opt:fpatchable-function-entry=
./common.opt:Common Joined Optimization
./common.opt:fself-test=
./common.opt:Common Undocumented Joined Var(flag_self_test)
./c-family/c.opt:Walloc-size-larger-than=
./c-family/c.opt:C ObjC C++ LTO ObjC++ Var(warn_alloc_size_limit) Joined
Host_Wide_Int ByteSize Warning Init(HOST_WIDE_INT_MAX)
./c-family/c.opt:Walloca-larger-than=
./c-family/c.opt:C ObjC C++ LTO ObjC++ Var(warn_alloca_limit) Warning Joined
Host_Wide_Int ByteSize Init(HOST_WIDE_INT_MAX)
./c-family/c.opt:Wvla-larger-than=
./c-family/c.opt:C ObjC C++ LTO ObjC++ Var(warn_vla_limit) Warning Joined
Host_Wide_Int ByteSize Init(HOST_WIDE_INT_MAX)
./c-family/c.opt:fconstant-string-class=
./c-family/c.opt:ObjC ObjC++ Joined MissingArgError(no class name specified
with %qs)
./c-family/c.opt:fname-mangling-version-
./c-family/c.opt:C++ ObjC++ Joined Deprecated
./c-family/c.opt:fopenacc-dim=
./c-family/c.opt:C ObjC C++ ObjC++ LTO Joined Var(flag_openacc_dims)
./c-family/c.opt:femit-struct-debug-detailed=
./c-family/c.opt:C ObjC C++ ObjC++ Joined
./fortran/lang.opt:fopenacc-dim=
./fortran/lang.opt:Fortran LTO Joined Var(flag_openacc_dims)
./lto/lang.opt:fltrans-output-list=
./lto/lang.opt:LTO Joined Var(ltrans_output_list)
./lto/lang.opt:fresolution=
./lto/lang.opt:LTO Joined

[Bug fortran/78983] [7/8/9 Regression] ICE with CAF-DT with allocatable member

[damian at sourceryinstitute dot org]

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

--- Comment #10 from Damian Rouson  ---
I see no ICE in testing the code from Comment 3 using fortran 7.3.0, 8.2.0, and
9.0.1.  I believe this can be closed.

[Bug target/89290] [8/9 Regression] ICE in change_address_1, at emit-rtl.c:2286

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Wed Feb 13 08:45:37 2019
New Revision: 268837

URL: https://gcc.gnu.org/viewcvs?rev=268837=gcc=rev
Log:
PR target/89290
* config/i386/predicates.md (x86_64_immediate_operand): Allow
TLS UNSPECs offsetted by signed 32-bit CONST_INT even with
-mcmodel=large.

* gcc.target/i386/pr89290.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr89290.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/predicates.md
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/89328] static chain made mandatory

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Fixed in GCC 8.0.  See bug 83423.

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

[Bug middle-end/83423] default_static_chain is sorry for non-nested functions

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||mpoulhies at kalray dot eu

--- Comment #8 from Andrew Pinski  ---
*** Bug 89328 has been marked as a duplicate of this bug. ***

[Bug ipa/89306] [8/9 regression] Hash based IPA summaries are too slow and consume up to 80% of IPA optimization time.

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Known to work||8.2.0, 9.0
   Target Milestone|--- |9.0

[Bug c++/89326] [RFE] Highlight `required from here` in compile-error output

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug c++/89326] [RFE] Highlight `required from here` in compile-error output

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-02-13
 CC||dmalcolm at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
I like this idea.

[Bug tree-optimization/89329] "-O2" optimization causes a infinite loop

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Component|c   |tree-optimization
 Resolution|--- |INVALID

--- Comment #1 from Andrew Pinski  ---
> If the value of 'i' is over ARR_MAX before the second loop, there is no
> condition to exit the loop.

Yes because i cannot be over ARR_MAX as that would have involved undefined
behavior while accessing pStruct->array2.

[Bug target/89324] [9 Regression] ICE in extract_constrain_insn, at recog.c:2211 on aarch64

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||8.2.1
Summary|ICE in  |[9 Regression] ICE in
   |extract_constrain_insn, at  |extract_constrain_insn, at
   |recog.c:2211 on aarch64 |recog.c:2211 on aarch64
 Ever confirmed|0   |1
  Known to fail||9.0

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed.

[Bug middle-end/89303] [8 Regression] memory leak with shared_ptr and enable_shared_from_this

[redi at gcc dot gnu.org]

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

--- Comment #17 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #13)
> So if the two bugs have the same root cause, it seems to be a problem in
> __weak_count::_M_assign, failing to set _M_pi here:
> 
>   __weak_count&
>   operator=(const __shared_count<_Lp>& __r) noexcept
>   {
> _Sp_counted_base<_Lp>* __tmp = __r._M_pi;
> if (__tmp != nullptr)
>   __tmp->_M_weak_add_ref();
> if (_M_pi != nullptr)
>   _M_pi->_M_weak_release();
> _M_pi = __tmp;
> return *this;
>   }

This ends up inlined into:
std::__shared_ptr::__shared_ptr > (struct
__shared_ptr * const this, struct _Sp_alloc_shared_tag __tag)

and the GIMPLE dumps for -O1 -fno-tree-pta and -O1 do look significantly
different, explaining why _M_weak_this._M_refcount._M_pi doesn't get set.

[Bug c/89329] New: "-O2" optimization causes a infinite loop

[jungmin.song at nuance dot com]

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

Bug ID: 89329
   Summary: "-O2" optimization causes a infinite loop
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jungmin.song at nuance dot com
  Target Milestone: ---

Created attachment 45688
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45688=edit
Sample code generating this issue

With O2 optimization, an infinite loop is generated from the attached code.

for (i = 0; i < pStruct->count1; ++i) {
unsigned short pWord = pStruct->array2[i];
CheckArray1_ext(pWord);
}

for (; i < ARR_MAX; ++i) {
pStruct->array1[i] = i;
}

The generated code with "arm-none-eabi-gcc.exe -S -O2 compileOptimizationErr.c
-o compileOptimizationErr.c.O2.s" checks only if it is equal with ARR_MAX for
the second loop. If the value of 'i' is over ARR_MAX before the second loop,
there is no condition to exit the loop.

[Bug middle-end/89303] [8 Regression] memory leak with shared_ptr and enable_shared_from_this

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #16 from Jakub Jelinek  ---
Looking at this now.

[Bug ipa/89330] New: IPA inliner touches released cgraph_edges

[marxin at gcc dot gnu.org]

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

Bug ID: 89330
   Summary: IPA inliner touches released cgraph_edges
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 45689
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45689=edit
Sanity check

Using the sanity check one can see following ICE:

$ g++ 1.ii 2.ii -shared -O2 -flto=8 -Wno-odr
removing edge: 0x77884420
removing edge: 0x778843c0
removing edge: 0x77884360
removing edge: 0x77884300
removing edge: 0x77884420
removing edge: 0x778843c0
removing edge: 0x77884360
removing edge: 0x77884420
removing edge: 0x778843c0
removing edge: 0x77884360
removing edge: 0x77884300
removing edge: 0x77884300
removing edge: 0x77525480
removing edge: 0x77525480
add_new_edges_to_heap: 0x77525480
during IPA pass: inline
lto1: internal compiler error: in add_new_edges_to_heap, at ipa-inline.c:1631
0x748286 add_new_edges_to_heap
../../gcc/ipa-inline.c:1631
0x1493d48 inline_small_functions
../../gcc/ipa-inline.c:2075
0x1493d48 ipa_inline
../../gcc/ipa-inline.c:2535
0x1493d48 execute
../../gcc/ipa-inline.c:2943

[Bug ipa/89330] IPA inliner touches released cgraph_edges

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
Created attachment 45690
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45690=edit
test-case

[Bug ipa/89330] IPA inliner touches released cgraph_edges

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Created attachment 45691
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45691=edit
test-case

[Bug middle-end/89303] [7/8/9 Regression] memory leak with shared_ptr and enable_shared_from_this

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P1  |P2
Summary|[8/9 Regression] memory |[7/8/9 Regression] memory
   |leak with shared_ptr and|leak with shared_ptr and
   |enable_shared_from_this |enable_shared_from_this

[Bug target/89222] [7/8/9 regression] ARM thumb-2 misoptimisation of func ptr call with -O2 or -Os

[wilco at gcc dot gnu.org]

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

--- Comment #8 from Wilco  ---
(In reply to Wilco from comment #7)
> Patch: https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00780.html

Updated patch: https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00947.html

[Bug c++/89331] [8/9 Regression] internal compiler error: in build_simple_base_path, at cp/class.c:589

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-02-13
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
   Target Milestone|--- |8.3
Summary|internal compiler error: in |[8/9 Regression] internal
   |build_simple_base_path, at  |compiler error: in
   |cp/class.c:589  |build_simple_base_path, at
   ||cp/class.c:589
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
This used to be rejected (on the trunk until r260782, where it started ICEing,
on 8.x branch without giving any errors first, on the trunk as error recovery
ICE with
pr89331.C:2:71: error: cannot convert from ‘B’ to base class ‘A’ because ‘B’ is
incomplete
2 | struct B : public A { static constexpr int b = __builtin_offsetof (B, a);
};
  |   ^
pr89331.C:2:71: internal compiler error: in build_class_member_access_expr, at
cp/typeck.c:2480
0xb108bc build_class_member_access_expr(cp_expr, tree_node*, tree_node*, bool,
int)
../../gcc/cp/typeck.c:2480
0xb128cc finish_class_member_access_expr(cp_expr, tree_node*, bool, int)
../../gcc/cp/typeck.c:3001

Simplified testcase:
struct A { char a; };
struct B : public A { static constexpr int b = __builtin_offsetof (B, a); };

clang rejects this too, not really sure if it is valid or not.

[Bug fortran/89100] Default widths for i, f and g format specifiers in format strings

[mark.eggleston at codethink dot com]

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

MarkEggleston  changed:

   What|Removed |Added

  Attachment #45548|0   |1
is obsolete||

--- Comment #8 from MarkEggleston  ---
Created attachment 45694
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45694=edit
Patch to support default widths for f, g and i

Patch updated to incorporate documentation changes.

[Bug fortran/88649] runtime error: load of value 137971008, which is not a valid value for type 'gfc_intrinsic_op'

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
Author: marxin
Date: Wed Feb 13 13:04:56 2019
New Revision: 268842

URL: https://gcc.gnu.org/viewcvs?rev=268842=gcc=rev
Log:
Fix -fdec simplification (PR fortran/88649).

2019-02-13  Martin Liska  

PR fortran/88649
* resolve.c (resolve_operator): Initialize 't' right
after function entry.  Skip switch (e->value.op.op)
for -fdec operands that become function calls.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c

[Bug sanitizer/89323] Asan memory leak detection on x86 platform

[ganeshemb at gmail dot com]

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

--- Comment #4 from Ganesh Babu  ---
(In reply to Martin Liška from comment #2)
> I can confirm that LSAN does not work for -m32 on current trunk. It was
> enabled in:
> 
> commit 1e39eaad45fc92b49e189badf0a5a675fbfb4ad0
> Author: Francis Ricci 
> Date:   Tue Mar 28 21:56:44 2017 +
> 
> Enable i386 builds for darwin lsan
> 
> Summary:
> Now that __thread is no longer used for lsan on darwin, i386 builds
> can be enabled.
> 
> Reviewers: kcc, kubamracek
> 
> Subscribers: danalbert, srhines, mgorny, llvm-commits
> 
> Differential Revision: https://reviews.llvm.org/D29995
> 
> git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@298946
> 91177308-0d34-0410-b5e6-96231b3b80d8

Hi,

[Bug fortran/89100] Default widths for i, f and g format specifiers in format strings

[mark.eggleston at codethink dot com]

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

--- Comment #10 from MarkEggleston  ---
Created attachment 45696
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45696=edit
Change Log for gcc/testsuite for patch

Replace -fdec-format-defaults with PR fortran/89100.

[Bug fortran/89100] Default widths for i, f and g format specifiers in format strings

[mark.eggleston at codethink dot com]

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

MarkEggleston  changed:

   What|Removed |Added

  Attachment #45550|0   |1
is obsolete||

--- Comment #11 from MarkEggleston  ---
Created attachment 45697
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45697=edit
Change Log for libgfortran for patch

Add PR fortran/89100 to log.

[Bug c++/88986] [7/8/9 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'error_mark' in member_vec_binary_search, at cp/name-lookup.c:1136

[paolo at gcc dot gnu.org]

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

--- Comment #4 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Wed Feb 13 10:34:49 2019
New Revision: 268839

URL: https://gcc.gnu.org/viewcvs?rev=268839=gcc=rev
Log:
/cp
2019-02-13  Paolo Carlini  

PR c++/88986
* decl.c (make_typename_type): Allow for TYPE_PACK_EXPANSION as
context (the first argument).
* pt.c (tsubst, case TYPENAME_TYPE): Handle TYPE_PACK_EXPANSION
as context.

/testsuite
2019-02-13  Paolo Carlini  

PR c++/88986
* g++.dg/cpp1z/using4.C: New.
* g++.dg/cpp1z/using5.C: Likewise.
* g++.dg/cpp1z/using6.C: Likewise.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/using4.C
trunk/gcc/testsuite/g++.dg/cpp1z/using5.C
trunk/gcc/testsuite/g++.dg/cpp1z/using6.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/87113] ICE in adjust_temp_type at cp/constexpr.c:1205

[svenja.mehringer at gmail dot com]

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

--- Comment #4 from smehringer  ---
Thanks for the fix! 

Is the fix included only in GCC 9 or also in GCC 7 and 8?

[Bug middle-end/89303] [8 Regression] memory leak with shared_ptr and enable_shared_from_this

[jakub at gcc dot gnu.org]

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

--- Comment #18 from Jakub Jelinek  ---
Before fre3 we have:
  _24 = malloc (40);
...
  MEM[(struct __allocated_ptr *)&__guard clique 9 base 1]._M_ptr = _24;
  _15 = __guard._M_ptr;
...
  _16 = [(struct __aligned_buffer *)_15 + 16B]._M_storage;
...
  MEM[(struct __weak_count *)_15 + 24B clique 8 base 1]._M_pi = 0B;
...
  MEM[(struct __shared_count *)this_6(D) + 8B clique 2 base 1]._M_pi = _15;
  MEM[(struct blob * &)this_6(D) clique 2 base 0] = _16;
...
  _3 = MEM[(struct __shared_ptr *)this_6(D) clique 1 base 1]._M_ptr;
...
  __tmp_25 = MEM[(const struct __shared_count &)this_6(D) + 8 clique 10 base
1]._M_pi;
...
  MEM[(struct __weak_count *)_3 + 8B clique 10 base 0]._M_pi = __tmp_25;
fre3 makes:
  _24 = malloc (40);
...
  _16 = [(struct __aligned_buffer *)_24 + 16B]._M_storage;
...
  MEM[(struct __weak_count *)_24 + 24B clique 8 base 1]._M_pi = 0B;
...
  MEM[(struct __shared_count *)this_6(D) + 8B clique 2 base 1]._M_pi = _24;
  MEM[(struct blob * &)this_6(D) clique 2 base 0] = _16;
...
  _19 = MEM[(struct __weak_count *)_24 + 24B clique 6 base 1]._M_pi;
...
  MEM[(struct __weak_count *)_16 + 8B clique 10 base 0]._M_pi = _24;
out of this and finally dce2 deletes that last store:
Eliminating unnecessary statements:
Deleting : MEM[(struct __weak_count *)_16 + 8B]._M_pi = _24;

With -O1 -fno-tree-dce -fno-tree-dse there are no leaks.

[Bug rtl-optimization/49054] useless cmp+jmp generated for switch when "default:" is unreachable

[adl at gnu dot org]

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

--- Comment #6 from Alexandre Duret-Lutz  ---
I revisited this with GCC 8.2.1 (or more precisely the version called
gcc-8.2.0-20 in Debian).

The original code I gave now generate a jump table with no extra comparison:

 :
   0:   48 8d 15 00 00 00 00lea0x0(%rip),%rdx# 7 
   7:   89 ff   mov%edi,%edi
   9:   48 63 04 ba movslq (%rdx,%rdi,4),%rax
   d:   48 01 d0add%rdx,%rax
  10:   ff e0   jmpq   *%rax
  12:   66 0f 1f 44 00 00   nopw   0x0(%rax,%rax,1)
  18:   e9 00 00 00 00  jmpq   1d 
  1d:   0f 1f 00nopl   (%rax)
  20:   e9 00 00 00 00  jmpq   25 
  25:   0f 1f 00nopl   (%rax)
  28:   e9 00 00 00 00  jmpq   2d 
  2d:   0f 1f 00nopl   (%rax)
  30:   e9 00 00 00 00  jmpq   35 
  35:   0f 1f 00nopl   (%rax)
  38:   e9 00 00 00 00  jmpq   3d 


However if I change the code to:

unsigned f(void);
unsigned g(void);
unsigned h(void);
unsigned i(void);
unsigned j(void);

unsigned int baz(unsigned int id)
{
  switch (id)
{
case 0:
  return f();
case 1:
  return g();
case 23456:  // <- changed
  return h();
case 3:
  return i();
case 4:
  return j();
default:
  __builtin_unreachable();
}
}

Then a non-optimal decision tree is generated:

 :
   0:   83 ff 03cmp$0x3,%edi
   3:   74 3b   je 40 
   5:   77 09   ja 10 
   7:   85 ff   test   %edi,%edi
   9:   75 15   jne20 
   b:   e9 00 00 00 00  jmpq   10 
  10:   83 ff 04cmp$0x4,%edi
  13:   75 1b   jne30 
  15:   e9 00 00 00 00  jmpq   1a 
  1a:   66 0f 1f 44 00 00   nopw   0x0(%rax,%rax,1)
  20:   83 ff 01cmp$0x1,%edi
  23:   75 20   jne45 
  25:   e9 00 00 00 00  jmpq   2a 
  2a:   66 0f 1f 44 00 00   nopw   0x0(%rax,%rax,1)
  30:   81 ff a0 5b 00 00   cmp$0x5ba0,%edi
  36:   75 0d   jne45 
  38:   e9 00 00 00 00  jmpq   3d 
  3d:   0f 1f 00nopl   (%rax)
  40:   e9 00 00 00 00  jmpq   45 


When we reach line 0x20, we know that 0<%edi<3 so the comparison against 1 is
unnecessary.  Similarly, the comparison on line 0x30 is unnecessary as %edi
must be equal to 23456 at this point.

I'd expect the effect of __builtin_unreachable() to cause lines
0x20,0x23,0x30,0x36 to be removed from that output.

It looks like that when building a decision tree over a switch, the presence of
an unreachable default would allow to get rid of a comparison for all leaves of
the tree.

[Bug lto/89260] ICE in read_cgraph_and_symbols, at lto/lto.c:2800 while compiling harfbuzz

[marxin at gcc dot gnu.org]

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

--- Comment #13 from Martin Liška  ---
Author: marxin
Date: Wed Feb 13 11:24:28 2019
New Revision: 268840

URL: https://gcc.gnu.org/viewcvs?rev=268840=gcc=rev
Log:
Bump LTO_minor_version on GCC-8 branch (PR lto/89260).

2019-02-13  Martin Liska  

PR lto/89260
* lto-streamer.h (LTO_minor_version): Bump version due
to r268698.

Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/lto-streamer.h

[Bug c++/89331] New: internal compiler error: in build_simple_base_path, at cp/class.c:589

[stsp at users dot sourceforge.net]

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

Bug ID: 89331
   Summary: internal compiler error: in build_simple_base_path, at
cp/class.c:589
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stsp at users dot sourceforge.net
  Target Milestone: ---

#include 

class A {
public:
char a;
};

class B : public A {
public:
static constexpr size_t b = offsetof(B, a);
};


$ c++ -Wall -c overl.cpp 
In file included from /usr/include/c++/8/cstddef:50,
 from overl.cpp:1:
overl.cpp:10:41: internal compiler error: in build_simple_base_path, at
cp/class.c:589
 static constexpr size_t b = offsetof(B, a);
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug rtl-optimization/89295] [9 regression] compilation of gcc.dg-struct-layout-1/t001_x.c takes 30 times as long after r268404

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

 CC||amodra at gmail dot com

--- Comment #1 from Alan Modra  ---
Did the pr89225 fix make a difference here?

[Bug middle-end/89303] [7/8/9 Regression] memory leak with shared_ptr and enable_shared_from_this

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Assignee|rguenth at gcc dot gnu.org |jakub at gcc dot gnu.org

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

Full untested fix.

[Bug go/89193] "make distclean" leaves stuff in gotools/

[segher at gcc dot gnu.org]

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

--- Comment #3 from Segher Boessenkool  ---
Thank you!

[Bug middle-end/89281] [9 Regression] gcc/optabs.c:3901:30: runtime error: shift exponent 32 is too large for 32-bit type 'int'

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Wed Feb 13 12:12:09 2019
New Revision: 268841

URL: https://gcc.gnu.org/viewcvs?rev=268841=gcc=rev
Log:
PR middle-end/89281
* optabs.c (prepare_cmp_insn): Use UINTVAL (size) instead of
INTVAL (size), compare it to GET_MODE_MASK instead of
1 << GET_MODE_BITSIZE.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/optabs.c

[Bug fortran/89100] Default widths for i, f and g format specifiers in format strings

[mark.eggleston at codethink dot com]

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

--- Comment #7 from MarkEggleston  ---
Created attachment 45693
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45693=edit
Update to option and Extension documentation

Documentation changes in their own difference file so that they can be checked
independently of the patch.

Patch will be update to incorporate the changes.

[Bug target/89324] [9 Regression] ICE in extract_constrain_insn, at recog.c:2211 on aarch64

[matmal01 at gcc dot gnu.org]

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

--- Comment #3 from Matthew Malcomson  ---
(In reply to ktkachov from comment #2)
> The sub3_compare1_imm pattern was introduced for GCC 9. It's probably
> something going wrong with the constraints. Matthew, could you take a look
> please?

On first blush it looks like the define_peephole2 generating this instruction
allows the stack pointer while the 'r' constraint in the pattern doesn't accept
it.

A quick check of only allowing GENERAL_REGS registers in the peephole indeed
stops the generation of this instruction and hence avoids the bug.

I haven't yet checked whether the pattern should allow the stack pointer or
not.

[Bug c++/88986] [7/8 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'error_mark' in member_vec_binary_search, at cp/name-lookup.c:1136

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

Summary|[7/8/9 Regression] ICE: |[7/8 Regression] ICE: tree
   |tree check: expected tree   |check: expected tree that
   |that contains 'decl |contains 'decl minimal'
   |minimal' structure, have|structure, have
   |'error_mark' in |'error_mark' in
   |member_vec_binary_search,   |member_vec_binary_search,
   |at cp/name-lookup.c:1136|at cp/name-lookup.c:1136

--- Comment #5 from Paolo Carlini  ---
Fixed in trunk.

[Bug middle-end/89303] [8 Regression] memory leak with shared_ptr and enable_shared_from_this

[jakub at gcc dot gnu.org]

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

--- Comment #20 from Jakub Jelinek  ---
On:
# .MEM_64 = VDEF <.MEM_63>
MEM[(struct __weak_ptr *)_16]._M_ptr = _16;
stmt_may_clobber_global_p (stmt) returns false.
(gdb) p pt_solution_includes_global
(>gimple_df->ssa_names->m_vecdata[16]->ssa_name.info.ptr_info->pt)
$99 = false
(gdb) p pt_solution_includes_global
(>gimple_df->ssa_names->m_vecdata[24]->ssa_name.info.ptr_info->pt)
$100 = true

This makes no sense to me, when _16 is [(struct __aligned_buffer *)_24 +
16B]._M_storage, thus effectively just POINTER_PLUS_EXPR from _24, it could
have different alignment, but how it can have different points-to info?

(gdb) p debug_tree (cfun->gimple_df->ssa_names->m_vecdata[16])
 >
public unsigned type_6 DI
size 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffea81c000
pointer_to_this >
visited
def_stmt _16 = [(struct __aligned_buffer *)_24 + 16B]._M_storage;
version:16
ptr-info 0x7fffea39a288>
(gdb) p debug_tree (cfun->gimple_df->ssa_names->m_vecdata[24])
 
unit-size 
user align:64 warn_if_not_align:0 symtab:0 alias-set -1
canonical-type 0x7fffea5e9348 fields 
context 
full-name "class std::_Sp_counted_ptr_inplace, 0>"
needs-constructor needs-destructor X(constX&) this=(X&) n_parents=1
use_template=1 interface-unknown
pointer_to_this  chain >
sizes-gimplified public unsigned type_6 DI
size 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set 16 canonical-type
0x7fffea5f3a80>
visited
def_stmt _24 = malloc (40);
version:24
ptr-info 0x7fffea39a138>

[Bug middle-end/89303] [7/8/9 Regression] memory leak with shared_ptr and enable_shared_from_this

[jakub at gcc dot gnu.org]

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

--- Comment #22 from Jakub Jelinek  ---
--- gcc/tree-ssa-structalias.c.jj   2019-01-01 12:37:18.738949011 +0100
+++ gcc/tree-ssa-structalias.c  2019-02-13 12:28:54.592256591 +0100
@@ -6412,7 +6412,7 @@ set_uids_in_ptset (bitmap into, bitmap f
  && bitmap_bit_p (escaped_vi->solution, i)))
{
  pt->vars_contains_escaped = true;
- pt->vars_contains_escaped_heap = vi->is_heap_var;
+ pt->vars_contains_escaped_heap |= vi->is_heap_var;
}

   if (vi->is_restrict_var)

fixes this for me (though, no idea what is that other variable in the points-to
set of _16).

[Bug tree-optimization/89332] New: Missed detection of dead stores to array in a loop

[prathamesh3492 at gcc dot gnu.org]

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

Bug ID: 89332
   Summary: Missed detection of dead stores to array in a loop
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: prathamesh3492 at gcc dot gnu.org
  Target Milestone: ---

Hi,
For the following test-case:

#define ARR_MAX 6

__attribute__((const)) int f(int);

int foo()
{
  int arr[ARR_MAX];

  for (int i = 0; i < ARR_MAX; i++)
arr[i] = f(i);

  return arr[0];
}

With -O3, gcc generates call to f(i) and store to arr[i] on every iteration,
while clang detects the stores to arr are dead (except for arr[0]), removes the
loop and emits a tail-call to f(0).

aarch64-linux-gnu-gcc -O3:
foo:
.LFB0:
.cfi_startproc
stp x29, x30, [sp, -64]!
.cfi_def_cfa_offset 64
.cfi_offset 29, -64
.cfi_offset 30, -56
mov x29, sp
stp x19, x20, [sp, 16]
.cfi_offset 19, -48
.cfi_offset 20, -40
add x20, sp, 40
mov w19, 0
.p2align 3,,7
.L2:
mov w0, w19
bl  f
str w0, [x20], 4
add w19, w19, 1
cmp w19, 6
bne .L2
ldr w0, [sp, 40]
ldp x19, x20, [sp, 16]
ldp x29, x30, [sp], 64
.cfi_restore 30
.cfi_restore 29
.cfi_restore 19
.cfi_restore 20
.cfi_def_cfa_offset 0
ret


clang -O3 --target=aarch64-linux-gnu:
foo:// @foo
// %bb.0:
mov w0, wzr
b   f

It seems, clang takes advantage of loop unrolling for the above-case,
while gcc doesn't seem to. After increasing ARR_MAX from 6 to 512, clang
generates same/similar code as gcc.

I doubt tho if such code is written in practice or can result due to
abstraction lowering ? It was just a contrived test-case I made up.

Thanks,
Prathamesh

[Bug fortran/83700] [Meta-bug] Fortran Coarray issues

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83700
Bug 83700 depends on bug 78983, which changed state.

Bug 78983 Summary: [7/8/9 Regression] ICE with CAF-DT with allocatable member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78983

   What|Removed |Added

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

[Bug fortran/78983] [7/8/9 Regression] ICE with CAF-DT with allocatable member

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #11 from Dominique d'Humieres  ---
> I see no ICE in testing the code from Comment 3 using fortran 7.3.0,
> 8.2.0, and 9.0.1. 

Confirmed.

> I believe this can be closed.

Closing.

[Bug fortran/89291] internal compiler error: in gfc_trans_use_stmts

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
> Installed gcc-5.5.0 and built the identical WRF version.
>
> No ICE encountered with 5.5.0. 

Then if you get an ICE with 7.4, it a regression. Did you try 8.2 or trunk.

> Contacted NCAR, the providers of the source code.

Did you give them the URL to this PR?

It would be nice if they can attach a reproducer.

[Bug fortran/89100] Default widths for i, f and g format specifiers in format strings

[mark.eggleston at codethink dot com]

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

MarkEggleston  changed:

   What|Removed |Added

  Attachment #45603|0   |1
is obsolete||

--- Comment #9 from MarkEggleston  ---
Created attachment 45695
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45695=edit
Change log for gcc/fortran for patch

Updated to include changes in documentation

[Bug sanitizer/89323] Asan memory leak detection on x86 platform

[ganeshemb at gmail dot com]

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

--- Comment #5 from Ganesh Babu  ---
(In reply to Martin Liška from comment #3)
> > works for current clang:
> > 
> > clang-6.0 -g -fsanitize=address -fno-omit-frame-pointer -m32  asantest.c  &&
> > ./a.out 
> > 
> > AddressSanitizer:DEADLYSIGNAL
> > =
> > ==6318==ERROR: AddressSanitizer: SEGV on unknown address 0x (pc
> > 0xf74f2a66 bp 0xfff26cb8 sp 0xfff26854 T0)
> > 
> > 
> 
> No, you forgot to provide ./a.out argument. That's why you see a SEGV.
> Please try latest clang release (7) and test it. If it's failing, please
> report upstream bug https://github.com/google/sanitizers/issues.

i have raised a request at https://github.com/google/sanitizers/issues/1049

[Bug middle-end/89303] [8 Regression] memory leak with shared_ptr and enable_shared_from_this

[jakub at gcc dot gnu.org]

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

--- Comment #19 from Jakub Jelinek  ---
Those DCE or DSE removals of the store look weird.  In the alias info we have:
  # PT = null { D.5120 } (escaped, escaped heap)
  # ALIGN = 8, MISALIGN = 0
  # USE = nonlocal null { D.4247 D.5109 D.5120 D.5121 } (nonlocal, escaped,
escaped heap, interposable)
  # CLB = nonlocal null { D.4247 D.5109 D.5120 D.5121 } (nonlocal, escaped,
escaped heap, interposable)
  _24 = malloc (40);
...
  # PT = null { D.5109 D.5120 } (escaped)
  _16 = [(struct __aligned_buffer *)_24 + 16B]._M_storage;
...
   [local count: 488552530]:
  MEM[(struct __weak_count *)_16 + 8B clique 10 base 0]._M_pi = _24;

   [local count: 1073741824]:
  return;
When the pointer is escaped, how can it DCE a store to it?

[Bug middle-end/89303] [7/8/9 Regression] memory leak with shared_ptr and enable_shared_from_this

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #21 from Richard Biener  ---
Thanks for the analysis (where I agree with the P2), I'll have a look.

[Bug lto/89260] ICE in read_cgraph_and_symbols, at lto/lto.c:2800 while compiling harfbuzz

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #14 from Martin Liška  ---
Fixed on affected GCC-8 branch.

[Bug fortran/88649] runtime error: load of value 137971008, which is not a valid value for type 'gfc_intrinsic_op'

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Liška  ---
Fixed on trunk.

[Bug other/63426] [meta-bug] Issues found with -fsanitize=undefined

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426
Bug 63426 depends on bug 88649, which changed state.

Bug 88649 Summary: runtime error: load of value 137971008, which is not a valid 
value for type 'gfc_intrinsic_op'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88649

   What|Removed |Added

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

[Bug middle-end/89303] [7/8/9 Regression] memory leak with shared_ptr and enable_shared_from_this

[jakub at gcc dot gnu.org]

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

--- Comment #24 from Jakub Jelinek  ---
Author: jakub
Date: Wed Feb 13 13:32:00 2019
New Revision: 268843

URL: https://gcc.gnu.org/viewcvs?rev=268843=gcc=rev
Log:
2019-02-13  Jakub Jelinek  

PR middle-end/89303
* tree-ssa-structalias.c (set_uids_in_ptset): Or in vi->is_heap_var
into pt->vars_contains_escaped_heap instead of setting
pt->vars_contains_escaped_heap to it.

2019-02-13  Jonathan Wakely  
Jakub Jelinek  

PR middle-end/89303
* g++.dg/torture/pr89303.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr89303.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-structalias.c

[Bug fortran/89286] Intrinsic sign and GNU Extension

[mark.eggleston at codethink dot com]

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

MarkEggleston  changed:

   What|Removed |Added

  Attachment #45658|0   |1
is obsolete||

--- Comment #10 from MarkEggleston  ---
Created attachment 45699
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45699=edit
Change log for gcc/fortran for patch

Update log to include change to intrinsic.h.

[Bug inline-asm/89334] New: unsupported size for integer register

[stsp at users dot sourceforge.net]

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

Bug ID: 89334
   Summary: unsupported size for integer register
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: inline-asm
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stsp at users dot sourceforge.net
  Target Milestone: ---

Created attachment 45700
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45700=edit
test case

The following seemingly valid test-case can
be compiled with clang, but fails with gcc with -O2:

$ gcc -Wall -m32 -O2 -S -o foo.s foo.c 
foo.c: In function ‘do_work’:
foo.c:60:1: error: unsupported size for integer register

[Bug ada/89333] [9 Regression] FAIL: gnat.dg/vect*.adb on darwin

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-02-13
 Ever confirmed|0   |1
  Known to fail||9.0

--- Comment #1 from Dominique d'Humieres  ---
> Between revisions and the following ADA tests have started to fail:

I was supposed to post: Between revisions r268704 and r268809.

[Bug driver/89249] mingw, paths with spaces, LTO -> collect2.exe: fatal error: CreateProcess: No such file or directory

[ilg at livius dot net]

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

--- Comment #4 from Liviu Ionescu  ---
I added a printf() in pex_win32_exec_child() to see why the lto invocation
fails, and here is the result:


>>>>> pex_win32_exec_child (executable='c:/users/ilg/desktop/8.2.1 
>>>>> 1.4-20190213-0923/bin/../libexec/gcc/arm-none-eabi/8.2.1/collect2.exe') 
>>>>> <<<<<
>>>>> pex_win32_exec_child (executable='c:/users/ilg/desktop/8.2.1 
>>>>> 1.4-20190213-0923/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe')
>>>>>  <<<<<
>>>>> pex_win32_exec_child (executable='c:/users/ilg/desktop/8.2.1 
>>>>> 1.4-20190213-0923/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/nm.exe')
>>>>>  <<<<<
>>>>> pex_win32_exec_child (executable='c:/users/ilg/desktop/8.2.1 
>>>>> 1.4-20190213-0923/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/nm.exe')
>>>>>  <<<<<
>>>>> pex_win32_exec_child (executable='c:/users/ilg/desktop/8.2.1 
>>>>> 1.4-20190213-0923/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/nm.exe')
>>>>>  <<<<<
>>>>> pex_win32_exec_child (executable='c:/users/ilg/desktop/8.2.1 
>>>>> 1.4-20190213-0923/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/nm.exe')
>>>>>  <<<<<
>>>>> pex_win32_exec_child (executable='c:/users/ilg/desktop/8.2.1 
>>>>> 1.4-20190213-0923/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/nm.exe')
>>>>>  <<<<<
>>>>> pex_win32_exec_child (executable='c:/users/ilg/desktop/8.2.1 
>>>>> 1.4-20190213-0923/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/nm.exe')
>>>>>  <<<<<
>>>>> pex_win32_exec_child (executable='c:/users/ilg/desktop/8.2.1\ \ \ \ \ 
>>>>> 1.4-20190213-0923/bin/../libexec/gcc/arm-none-eabi/8.2.1/lto-wrapper.exe')
>>>>>  <<<<<
collect2.exe: fatal error: CreateProcess: No such file or directory
compilation terminated.

C:\Users\ilg\tmp\lto>



it looks like the win32 api is not happy with the escaped spaces in the
lto-wrapper path.


I conditionally removed the white space conversion in gcc.c (around line 7741)
and the problem was fixed:


#if defined (__MINGW32__)
  // Win32 fails to CreateProcess if spaces are escaped.
  lto_wrapper_spec = lto_wrapper_file;
#else
  lto_wrapper_file = convert_white_space (lto_wrapper_file);
#endif


I did the same for the second reference to convert_white_space(), while
processing the linker_plugin_file_spec, but I do not have a clear reason why
this is needed, since aparently the name of the temporary files used for the
specs file is generate by win32 in the 8.3 format, and has no spaces.


I tried to remove the conversion entirely, but then ld fails to load the
plugin:


/home/ilg/Desktop/8.2.1   
1.4-20190213-1020/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld:
/home/ilg/Desktop/8.2.1: error loading plugin: /home/ilg/Desktop/8.2.1: cannot
open shared object file: No such file or directory
collect2: error: ld returned 1 exit status
ilg@ilg-ud18lts64-gme:~/tmp/lto$ 



I'll apply a patch to build my distribution, but I think a more elaborate
solution is needed.


Although not related to this issue, another curious thing was the sequence of 6
calls to nm shown by the trace. Are they expected?

[Bug ipa/89330] IPA inliner touches released cgraph_edges

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

[Bug c++/89326] [RFE] Highlight `required from here` in compile-error output

[Hi-Angel at yandex dot ru]

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

--- Comment #2 from Konstantin Kharlamov  ---
Btw, I just occasionally noted: godbolt site adds their own highlight to GCC
output, in particular they highlight the whole line with "required from here"
with blue. Maybe something can be borrowed from them :)

https://godbolt.org/z/dK0CzG

[Bug lto/89335] New: [9 Regression] ICE with LTO -Wsuggest-final-methods: ICE during IPA pass devirt in types_same_for_odr, at ipa-devirt.c:391

[burnus at gcc dot gnu.org]

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

Bug ID: 89335
   Summary: [9 Regression] ICE with LTO -Wsuggest-final-methods:
ICE during IPA pass devirt in types_same_for_odr, at
ipa-devirt.c:391
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 45702
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45702=edit
9 Line test case:  g++ -O2 -flto -Wsuggest-final-methods input.ii

$ g++ -O2 -flto -Wsuggest-final-methods input.ii

during IPA pass: devirt
lto1: internal compiler error: in types_same_for_odr, at ipa-devirt.c:391
0x638062 types_same_for_odr(tree_node const*, tree_node const*)
../../gcc/ipa-devirt.c:391
0xa7c1a3 possible_polymorphic_call_targets(tree_node*, long,
ipa_polymorphic_call_context, bool*, void**, bool)
../../gcc/ipa-devirt.c:3390
0xa7d315 possible_polymorphic_call_targets(cgraph_edge*, bool*, void**, bool)
../../gcc/ipa-utils.h:118
0xa7d315 ipa_devirt
../../gcc/ipa-devirt.c:3781
0xa7d315 execute
../../gcc/ipa-devirt.c:4094
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
lto-wrapper: fatal error: g++ returned 1 exit status
compilation terminated.
/data/local/gdb/gdb-inst/bin/ld: error: lto-wrapper failed

[Bug middle-end/86554] [7 Regression] Incorrect code generation with signed/unsigned comparison

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener  ---
Author: rguenth
Date: Wed Feb 13 14:22:06 2019
New Revision: 268846

URL: https://gcc.gnu.org/viewcvs?rev=268846=gcc=rev
Log:
2019-02-13  Richard Biener  

Backport from mainline
2019-01-08  Richard Biener  

PR tree-optimization/86554
* tree-ssa-sccvn.c (visit_nary_op): When value-numbering to
expressions with different overflow behavior make sure there's an
available expression on the path.

* gcc.dg/torture/pr86554-1.c: New testcase.
* gcc.dg/torture/pr86554-2.c: Likewise.

Added:
branches/gcc-8-branch/gcc/testsuite/gcc.dg/torture/pr86554-1.c
branches/gcc-8-branch/gcc/testsuite/gcc.dg/torture/pr86554-2.c
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/gcc/tree-ssa-sccvn.c

[Bug lto/89335] [9 Regression] ICE with LTO -Wsuggest-final-methods: ICE during IPA pass devirt in types_same_for_odr, at ipa-devirt.c:391

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-02-13
  Known to work||8.2.0
   Assignee|unassigned at gcc dot gnu.org  |hubicka at gcc dot 
gnu.org
   Target Milestone|--- |9.0
 Ever confirmed|0   |1
  Known to fail||9.0

--- Comment #1 from Martin Liška  ---
Confirmed, started with r263697.

[Bug target/89316] ICE in gen_reg_rtx, at emit-rtl.c:1155

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||ak at gcc dot gnu.org,
   ||ian at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org,
   ||uros at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
Guess this is similar to the TLS ICE with -mforce-indirect-call.  In this case,
I think we need to figure out into which register could we load the address. 
Unfortunately, %rax or %eax isn't available for that, at least not always, e.g.
for -m64 it can hold the saved static chain, the existence of
__morestack_large_model shows that, but -m32 doesn't have anything like that.
So, in theory for -fsplit-stack -mforce-indirect-call -m64 we could call
__morestack_large_model even in non-large model compilations, just load the
address of that function differently.  For -m32, I'm out of ideas.

[Bug target/89316] ICE in gen_reg_rtx, at emit-rtl.c:1155

[ubizjak at gmail dot com]

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

--- Comment #8 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #7)
> Guess this is similar to the TLS ICE with -mforce-indirect-call.  In this
> case, I think we need to figure out into which register could we load the
> address.  Unfortunately, %rax or %eax isn't available for that, at least not
> always, e.g. for -m64 it can hold the saved static chain, the existence of
> __morestack_large_model shows that, but -m32 doesn't have anything like that.
> So, in theory for -fsplit-stack -mforce-indirect-call -m64 we could call
> __morestack_large_model even in non-large model compilations, just load the
> address of that function differently.  For -m32, I'm out of ideas.

We may use a temporary regno as returned from
split_stack_prologue_scratch_regno, perhaps in some generalized form here.

[Bug tree-optimization/89280] [7/8/9 Regression] ICE: Segmentation fault (in is_gimple_reg_type)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |7.5

[Bug target/89316] ICE in gen_reg_rtx, at emit-rtl.c:1155

[ubizjak at gmail dot com]

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

--- Comment #9 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #8)
> (In reply to Jakub Jelinek from comment #7)
> > Guess this is similar to the TLS ICE with -mforce-indirect-call.  In this
> > case, I think we need to figure out into which register could we load the
> > address.  Unfortunately, %rax or %eax isn't available for that, at least not
> > always, e.g. for -m64 it can hold the saved static chain, the existence of
> > __morestack_large_model shows that, but -m32 doesn't have anything like 
> > that.
> > So, in theory for -fsplit-stack -mforce-indirect-call -m64 we could call
> > __morestack_large_model even in non-large model compilations, just load the
> > address of that function differently.  For -m32, I'm out of ideas.
> 
> We may use a temporary regno as returned from
> split_stack_prologue_scratch_regno, perhaps in some generalized form here.

Bah, get_scratch_register_on_entry, not split_stack_prologue_scratch_regno.

[Bug middle-end/89303] [7/8 Regression] memory leak with shared_ptr and enable_shared_from_this

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[7/8/9 Regression] memory   |[7/8 Regression] memory
   |leak with shared_ptr and|leak with shared_ptr and
   |enable_shared_from_this |enable_shared_from_this

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

[Bug target/88847] gcc.target/aarch64/sve/struct_move_1.c ICE with -fstack-protector-strong

[tnfchris at gcc dot gnu.org]

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

Tamar Christina  changed:

   What|Removed |Added

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

--- Comment #5 from Tamar Christina  ---
Resolved in r268845.s

[Bug c++/89331] [8/9 Regression] internal compiler error: in build_simple_base_path, at cp/class.c:589

[stsp at users dot sourceforge.net]

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

--- Comment #2 from Stas Sergeev  ---
(In reply to Jakub Jelinek from comment #1)
> Simplified testcase:
> struct A { char a; };
> struct B : public A { static constexpr int b = __builtin_offsetof (B, a); };
> 
> clang rejects this too, not really sure if it is valid or not.

Thanks for taking a look!
A slight off-topic: any idea why even this rejects:
struct A {
char a;
static constexpr int b = __builtin_offsetof (A, a);
};

and is there any work-around when I want to
pass offsetof value into a template non-type,
which also rejects:
struct A {
char a;
B<__builtin_offsetof(A, a)> b;
};

Does the standard explicitly forbids that, of just gcc?

[Bug target/89290] [8 Regression] ICE in change_address_1, at emit-rtl.c:2286

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[8/9 Regression] ICE in |[8 Regression] ICE in
   |change_address_1, at|change_address_1, at
   |emit-rtl.c:2286 |emit-rtl.c:2286

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

[Bug c++/89326] [RFE] Highlight `required from here` in compile-error output

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
I think it highlights all lines where the location is the main source file, so
they stand out from anything with a location in a header.

[Bug ipa/89330] IPA inliner touches released cgraph_edges

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||mjambor at suse dot cz

--- Comment #3 from Jan Hubicka  ---
We may have more instances of this - I think I got rid of most of that code but
once upon of time it was common in GCC to walk removed instructions and edges
knowing they are in freelist.

This code is originally Martin's. I will try to take a look how complex the
interaction beween creation and removal is these days. One way is to teach
inliner cache to maintain the list of new edges transparently without having to
have extra vector.

[Bug gcov-profile/89307] -fprofile-generate binary may be too slow in multithreaded environment due to cache-line conflicts on counters

[hubicka at gcc dot gnu.org]

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

--- Comment #2 from Jan Hubicka  ---
Created attachment 45703
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45703=edit
patch for tls counters (incomplete - no runtime bits)

Also I think google's code to reduce cacheline conflicts is
https://gcc.gnu.org/ml/gcc-patches/2012-05/msg00959.html

[Bug bootstrap/84554] make check: FAIL: tversion: ERROR! The versions of gmp.h (5.0.5) and libgmp (4.3.1) do not match.

[bennet at umich dot edu]

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

Bennet Fauber  changed:

   What|Removed |Added

 CC||bennet at umich dot edu

--- Comment #8 from Bennet Fauber  ---
I believe the problem related below is related to this issue.

I am building GCC 8.2.0 on CentOS 7.5 which comes with GCC 4.8.5 and GMP 6.0.0.
 I used download_prerequisites to download GMP, et al.

When I run make check from the GCC build directory, it issues the FAIL message
for mismatched library and header version information for GMP.

When GCC runs make check, it uses this command to compile the test.

$ /tmp/bennet/build/gcc-8.2.0-build/./prev-gcc/xgcc
-B/tmp/bennet/build/gcc-8.2.0-build/./prev-gcc/
-B/tmp/local/x86_64-pc-linux-gnu/bin/ -B/tmp/local/x86_64-pc-linux-gnu/bin/
-B/tmp/local/x86_64-pc-linux-gnu/lib/ -isystem
/tmp/local/x86_64-pc-linux-gnu/include -isystem
/tmp/local/x86_64-pc-linux-gnu/sys-include -DNO_ASM -g -O2 -static-libstdc++
-static-libgcc -o tversion tversion.o  -L../src/.libs ./.libs/libfrtests.a -lm
../src/.libs/libmpfr.a -lgmp

which results in this binary

$ ldd tversion
linux-vdso.so.1 =>  (0x7fffd9d67000)
libm.so.6 => /lib64/libm.so.6 (0x2afc45e2a000)
libgmp.so.10 => /lib64/libgmp.so.10 (0x2afc4612c000)
libc.so.6 => /lib64/libc.so.6 (0x2afc463a4000)
/lib64/ld-linux-x86-64.so.2 (0x2afc45c06000)

and that most definitely will fail the test because of the reference to
/lib64/libgmp.so.10.

If I change to the mpfr/tests directory and remove tversion, then run make from
there, mpfr's Makefile compiles it this way

$ make tversion
/bin/sh ../libtool  --tag=CC   --mode=link
/tmp/bennet/build/gcc-8.2.0-build/./prev-gcc/xgcc
-B/tmp/bennet/build/gcc-8.2.0-build/./prev-gcc/
-B/tmp/local/x86_64-pc-linux-gnu/bin/ -B/tmp/local/x86_64-pc-linux-gnu/bin/
-B/tmp/local/x86_64-pc-linux-gnu/lib/ -isystem
/tmp/local/x86_64-pc-linux-gnu/include -isystem
/tmp/local/x86_64-pc-linux-gnu/sys-include -g -O2 -no-install
-L../src/.libs -static-libstdc++ -static-libgcc 
-L/tmp/bennet/build/gcc-8.2.0-build/gmp/.libs -o tversion tversion.o
libfrtests.la -lm ../src/libmpfr.la -lgmp 
libtool: link: /tmp/bennet/build/gcc-8.2.0-build/./prev-gcc/xgcc
-B/tmp/bennet/build/gcc-8.2.0-build/./prev-gcc/
-B/tmp/local/x86_64-pc-linux-gnu/bin/ -B/tmp/local/x86_64-pc-linux-gnu/bin/
-B/tmp/local/x86_64-pc-linux-gnu/lib/ -isystem
/tmp/local/x86_64-pc-linux-gnu/include -isystem
/tmp/local/x86_64-pc-linux-gnu/sys-include -g -O2 -static-libstdc++
-static-libgcc -o tversion tversion.o  -L../src/.libs
-L/tmp/bennet/build/gcc-8.2.0-build/gmp/.libs ./.libs/libfrtests.a -lm
../src/.libs/libmpfr.a /tmp/bennet/build/gcc-8.2.0-build/gmp/.libs/libgmp.a

which results in this binary

$ ldd tversion
linux-vdso.so.1 =>  (0x7ffc899c)
libm.so.6 => /lib64/libm.so.6 (0x2b39a664f000)
libc.so.6 => /lib64/libc.so.6 (0x2b39a6951000)
/lib64/ld-linux-x86-64.so.2 (0x2b39a642b000)

and the test passes,

$ ./tversion 
[tversion] MPFR 3.1.4
[tversion] Compiler: GCC 8.2.0
[tversion] GMP: header 6.1.0, library 6.1.0
[tversion] TLS = yes, decimal = no, GMP internals = no
[tversion] intmax_t = yes, printf = yes
[tversion] gmp_printf: hhd = yes, lld = yes, jd = yes, td = yes, Ld = yes
[tversion] MPFR tuning parameters from default

I think this suggests that the problem is in the way the GCC make test is
building the tests.

I am using

$ ../gcc-8.2.0/configure --enable-languages=c,c++,fortran \
--prefix=/tmp/local --disable-multilibq

Platform is x86_64.

[Bug fortran/89286] Intrinsic sign and GNU Extension

[mark.eggleston at codethink dot com]

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

--- Comment #9 from MarkEggleston  ---
Created attachment 45698
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45698=edit
GNU extension to intrinsic SIGN

Remove declaration of gfc_check_sign from intrinsic.h has it has been deleted.

[Bug ada/89333] New: [9 Regression] FAIL: gnat.dg/vect*.adb on darwin

[dominiq at lps dot ens.fr]

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

Bug ID: 89333
   Summary: [9 Regression] FAIL: gnat.dg/vect*.adb on darwin
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
CC: ebotcazou at gcc dot gnu.org, iains at gcc dot gnu.org
  Target Milestone: ---

Between revisions and the following ADA tests have started to fail:

FAIL: gnat.dg/vect1.adb 3 blank line(s) in output
FAIL: gnat.dg/vect1.adb (test for excess errors)
FAIL: gnat.dg/vect2.adb 3 blank line(s) in output
FAIL: gnat.dg/vect2.adb (test for excess errors)
FAIL: gnat.dg/vect3.adb 3 blank line(s) in output
FAIL: gnat.dg/vect3.adb (test for excess errors)
FAIL: gnat.dg/vect4.adb 3 blank line(s) in output
FAIL: gnat.dg/vect4.adb (test for excess errors)
FAIL: gnat.dg/vect5.adb 3 blank line(s) in output
FAIL: gnat.dg/vect5.adb (test for excess errors)
FAIL: gnat.dg/vect6.adb 3 blank line(s) in output
FAIL: gnat.dg/vect6.adb (test for excess errors)

The failure for vect1.adb is

spawn -ignore SIGHUP /opt/gcc/build_w/gcc/gnatmake
--GCC=/opt/gcc/build_w/gcc/xgcc --GNATBIND=/opt/gcc/build_w/gcc/gnatbind
--GNATLINK=/opt/gcc/build_w/gcc/gnatlink -cargs -B/opt/gcc/build_w/gcc -largs
--GCC=/opt/gcc/build_w/gcc/xgcc -B/opt/gcc/build_w/gcc  -m32 -margs
--RTS=/opt/gcc/build_w/x86_64-apple-darwin18.2.0/i386/libada -q -f
/opt/gcc/work/gcc/testsuite/gnat.dg/vect1.adb -m32 -fno-diagnostics-show-caret
-fno-diagnostics-show-line-numbers -fdiagnostics-color=never -O3 -msse2
-fno-vect-cost-model -fdump-tree-vect-details -c -u -S -o vect1.s
+===GNAT BUG DETECTED==+
| 9.0.1 20190212 (experimental) [trunk revision 268809p12]
(x86_64-apple-darwin18.2.0) GCC error:|
| tree check: expected class 'constant', have 'binary' (mult_expr) in  |
| valid_constant_size_p, at tree.c:7524|
| Error detected at vect1.ads:24:41|
| Please submit a bug report; see https://gcc.gnu.org/bugs/ .  |
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact command that you entered.  |
| Also include sources listed below.   |
+==+

[Bug driver/89249] mingw, paths with spaces, LTO -> collect2.exe: fatal error: CreateProcess: No such file or directory

[ilg at livius dot net]

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

--- Comment #5 from Liviu Ionescu  ---
The patch is wrong, it should read:

#if defined (__MINGW32__)
  // Win32 fails to CreateProcess if spaces are escaped.
#else
  lto_wrapper_file = convert_white_space (lto_wrapper_file);
#endif

[Bug target/88847] gcc.target/aarch64/sve/struct_move_1.c ICE with -fstack-protector-strong

[tnfchris at gcc dot gnu.org]

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

--- Comment #4 from Tamar Christina  ---
Author: tnfchris
Date: Wed Feb 13 14:04:41 2019
New Revision: 268845

URL: https://gcc.gnu.org/viewcvs?rev=268845=gcc=rev
Log:
AArch64: Allow any offset for SVE addressing modes before reload.

On AArch64 aarch64_classify_address has a case for when it's non-strict
that will allow it to accept any byte offset from a reg when validating
an address in a given addressing mode.

This because reload would later make the address valid. SVE however requires
the address always be valid, but currently allows any address when a MEM +
offset is used.  This causes an ICE as nothing later forces the address to be
legitimate.

The patch forces aarch64_emit_sve_pred_move via expand_insn to ensure that
the addressing mode is valid for any loads/stores it creates, which follows
the SVE way of handling address classifications.

gcc/ChangeLog:

PR target/88847
* config/aarch64/aarch64-sve.md (*pred_mov, pred_mov):
Expose as @aarch64_pred_mov.
* config/aarch64/aarch64.c (aarch64_classify_address):
Use expand_insn which legitimizes operands.

gcc/testsuite/ChangeLog:

PR target/88847
* gcc.target/aarch64/sve/pr88847.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/aarch64/sve/pr88847.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64-sve.md
trunk/gcc/config/aarch64/aarch64.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/89284] gcc -fsanitize=undefined inhibits -Wuninitialized

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

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

We could swap the early uninit warning pass with ubsan pass, the former
shouldn't change the IL (except for TREE_NO_WARNING/gimple_no_warning), while
the ubsan pass can make it harder to diagnose something e.g. because of the
enum/bool loads checking.

[Bug c++/89036] [8/9 Regression] ICE if destructor has a requires

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #4 from Marek Polacek  ---
David, can you please ping your patch?
https://gcc.gnu.org/ml/gcc-patches/2019-01/msg01529.html

[Bug middle-end/89281] [9 Regression] gcc/optabs.c:3901:30: runtime error: shift exponent 32 is too large for 32-bit type 'int'

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[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 #3 from Jakub Jelinek  ---
r[i + 'a'] = i + 10;
r[i + 'A'] = i + 10;
or
r[i + 'a'] = i + 10;
r[i + 'A'] = r[i + 'a'];
doesn't ICE.

[Bug target/87532] bad results from vec_extract(unsigned char, foo) dependent upon function inline

[kelvin at gcc dot gnu.org]

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

--- Comment #12 from kelvin at gcc dot gnu.org ---
After further digging, I have uncovered some additional clues:

after initial gimple expansion (i.e. the 005t.gimple trace file):

  vec_extract (vi, 3) is represented by __builtin_vec_ext_v4si (vi, 3)

But vec_extract (vi, 10) is represented by __BIT_FIELD_REF 

Apparently, the difference in handling of these two cases is that the selector
argument of the latter is known to be a constant greater than the number of
elements in the vector.

However, when the same code is expanded after in-lining the doextractbybuiltin
function of comment #4, the two expressions expand into

  __builtin_vec_ext_v4si (vi, 3) and
  __builtin_vec_ext_v4si (vi, 10) respectively.

This behavior is first manifest in the .047t.local-fnsummary2 trace file.

Later, when we "process" __builtin_vec_ext_v4si with a constant selector whose
value exceeds the vector length, we issue the erroneous error message.  With
non-constant selector values for __builtin_vec_ext_v4si, we do not issue the
error message.

I think the place to fix this is in the processing of the
__builtin_vec_ext_v4si function (and all of its lookalikes).  Rather than issue
the error message, we may have to emit slightly different implementations of
the code or maybe not even that.  Maybe i can just remove the error message.  I
need to study this a little more.

At the same time, I'm wondering if the "real problem" is in the
local-fnsummary2 pass.  During in-lining, it could be argued that it should
have produced the same intermediate form as the original gimple expansion:
BIT_FIELD_REF instead of __builtin_vec_ext_v4si.

Does anyone have further suggestions before I begin implementing a "solution"?

Thanks.

[Bug bootstrap/78251] config/gettext.m4 and config/iconv.m4 contaminate CPPFLAGS

[egallager at gcc dot gnu.org]

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

--- Comment #9 from Eric Gallager  ---
(In reply to Eric Gallager from comment #8)
> r265896 might have affected this

Update: apparently not; I still had to deactivate libunwind-headers again on my
latest build of gcc

[Bug target/89190] [8/9 regression][ARM] armv8-m.base invalid ldm ICE

[wilco at gcc dot gnu.org]

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

--- Comment #2 from Wilco  ---
Author: wilco
Date: Wed Feb 13 16:22:25 2019
New Revision: 268848

URL: https://gcc.gnu.org/viewcvs?rev=268848=gcc=rev
Log:
[ARM] Fix Thumb-1 ldm (PR89190)

This patch fixes an ICE in the Thumb-1 LDM peepholer.  Thumb-1 LDMs
always update the base register except if the base is loaded.
The current implementation rejects LDMs where the base is not dead,
however this doesn't exclude the case where the base is loaded as
well as dead.  Fix this by explicitly checking whether the base is
loaded.  Also enable LDMs which load the first register.

gcc/
PR target/89190
* config/arm/arm.c (ldm_stm_operation_p) Set
addr_reg_in_reglist correctly for first register.
(load_multiple_sequence): Remove dead base check.
(gen_ldm_seq): Correctly set write_back for Thumb-1.

testsuite/
PR target/89190
* gcc.target/arm/pr89190.c: New test.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.c
trunk/gcc/testsuite/ChangeLog

[Bug inline-asm/89334] unsupported size for integer register

[stsp at users dot sourceforge.net]

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

--- Comment #4 from Stas Sergeev  ---
Would it be possible to at least show the
correct line number where the register allocation
actually failed? gcc points to a rather "random"
line, and it required many hours of an engineer
work to find the problematic spot in a large project.
It really is not the good handling of this problem.

And I don't understand why it is impossible to add
error or warning if gcc emits 8bit reference for "r"
and knows it is not supposed to work.

[Bug target/89229] Unnecessary ZMM in movoi_internal_avx/movti_internal

[hjl.tools at gmail dot com]

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

--- Comment #19 from H.J. Lu  ---
sse.md has

(define_insn "mov_internal"
  [(set (match_operand:VMOVE 0 "nonimmediate_operand"
 "=v,v ,v ,m")
(match_operand:VMOVE 1 "nonimmediate_or_sse_const_operand"
 " C,BC,vm,v"))]

  /* There is no evex-encoded vmov* for sizes smaller than 64-bytes
 in avx512f, so we need to use workarounds, to access sse registers
 16-31, which are evex-only. In avx512vl we don't need workarounds.  */
  if (TARGET_AVX512F &&  < 64 && !TARGET_AVX512VL
  && (EXT_REX_SSE_REG_P (operands[0])
  || EXT_REX_SSE_REG_P (operands[1])))
{
  if (memory_operand (operands[0], mode))
{
  if ( == 32)
return "vextract64x4\t{$0x0, %g1, %0|%0, %g1,
0x0}";
  else if ( == 16)
return "vextract32x4\t{$0x0, %g1, %0|%0, %g1,
0x0}";
  else
gcc_unreachable ();
}
...

However, ix86_hard_regno_mode_ok has

 /* TODO check for QI/HI scalars.  */
  /* AVX512VL allows sse regs16+ for 128/256 bit modes.  */
  if (TARGET_AVX512VL
  && (mode == OImode
  || mode == TImode
  || VALID_AVX256_REG_MODE (mode)
  || VALID_AVX512VL_128_REG_MODE (mode)))
return true;

  /* xmm16-xmm31 are only available for AVX-512.  */
  if (EXT_REX_SSE_REGNO_P (regno))
return false;

  if (TARGET_AVX512F &&  < 64 && !TARGET_AVX512VL
  && (EXT_REX_SSE_REG_P (operands[0])
  || EXT_REX_SSE_REG_P (operands[1])))

is a dead code:

[hjl@gnu-4 gcc]$ cat /tmp/z.c 
#include 

extern __m128 i;

__m128
foo1 (void)
{
  register __m128 xmm16 __asm ("xmm16") = i;
  asm volatile ("" : "+v" (xmm16));
  register __m128 xmm17 __asm ("xmm17") = xmm16;
  asm volatile ("" : "+v" (xmm17));
  return xmm17;
}
[hjl@gnu-4 gcc]$ /usr/gcc-5.4.1-x32/bin/gcc  -S -O2 -march=knl /tmp/z.c 
/tmp/z.c: In function ‘foo1’:
/tmp/z.c:8:19: error: register specified for ‘xmm16’ isn’t suitable for data
type
   register __m128 xmm16 __asm ("xmm16") = i;
   ^
/tmp/z.c:10:19: error: register specified for ‘xmm17’ isn’t suitable for data
type
   register __m128 xmm17 __asm ("xmm17") = xmm16;
   ^
[hjl@gnu-4 gcc]$

[Bug c++/77304] ICE on C++ code with invalid template parameter: in gimplify_expr, at gimplify.c:11260

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Author: mpolacek
Date: Wed Feb 13 16:35:44 2019
New Revision: 268849

URL: https://gcc.gnu.org/viewcvs?rev=268849=gcc=rev
Log:
PR c++/77304
* g++.dg/cpp2a/nontype-class13.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp2a/nontype-class13.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c++/77304] ICE on C++ code with invalid template parameter: in gimplify_expr, at gimplify.c:11260

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Done.

[Bug rtl-optimization/89275] [9 Regression] Slowdown in mcperf on POWER

[wschmidt at gcc dot gnu.org]

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

--- Comment #2 from Bill Schmidt  ---
I asked our performance team to root-cause this when the report came out.  If
they can reproduce we can try to bisect it.

[Bug c++/89297] [9 Regression] ICE: unexpected expression 'id' of kind overload

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #2 from Marek Polacek  ---
https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00919.html

[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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Reduced testcase:
template  struct A {
  T a[N];
  constexpr T [] (int x) { return a[x]; }
};

constexpr A
foo ()
{
  A r{};
  for (int i = 0; i < 6; ++i)
r[i + 8] = r[i] = i;
  return r;
}

auto x = foo ();

Started to ICE with r217670, before that it has been accepted for a couple of
revisions and before that rejected.

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

[segher at gcc dot gnu.org]

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

--- Comment #2 from Segher Boessenkool  ---
Thanks for the analysis!

(In reply to Vladimir Makarov from comment #1)
> The very first ira-costs pass runs in sched1 and it generates the following
> costs
>   r125 costs: BASE_REGS:1 GENERAL_REGS:1 LINK_REGS:2
> CTR_REGS:2 LINK_OR_CTR_REGS:2 SPEC_OR_GEN_REGS:2 MEM:8000

> Why does IRA calculate such costs?  We have 2 insns involving p125
>15: r125:DI=%3:DI
>  REG_DEAD %3:DI
> 7: {r123:SI=asm_operands/*r125 with constraint 'v'*/;clobber ca:SI;}
> 
> Cost of moving r3 into p125 is 2 for base regs and 4 for memory
> Cost of moving p125 into a v reg is 8 for base regs and 4 for memory

Ah, so we we need to improve that.

This is power8, where mtvsr insns are still a bit expensive, but not more
expensive than memory.

> Therefore cost of p125 is 10 for base reg and 8 for memory (multiplied by BB
> frequency 1).
> 
> Therefore IRA chooses memory for p125.
> 
> In this particular case insn 15 can go away when we assign r3 to p125.  It
> means the cost for base reg could be 8 as for memory but IRA can not say in
> general case that it can assign r3 to p125.
> 
> I think increasing memory move cost at least to 5 could solve the problem. 
> But probably it needs benchmarking SPEC, besides running GCC testsuite, to
> see that the performance is not worse after such change.

Agreed.