[Bug target/89822] self mov on x86_64 and not optimized-out sub on ARM/ARM64 in a jump table switch

[ubizjak at gmail dot com]

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

--- Comment #1 from Uroš Bizjak  ---
(In reply to Nikita Kniazev from comment #0)
> 8.1  jump to ret removed, but self mov is still there
It's not a self move, but zero extend.

movl%edi, %edi  # 6 [c=1 l=2]  *zero_extendsidi2/3

[Bug tree-optimization/89809] movzwl is not utilized when uint16_t is loaded with bit-shifts (while memcpy does)

[JunMa at linux dot alibaba.com]

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

--- Comment #3 from JunMa  ---
the stmt generated by fe has some issue, in 004t.original dump file:
return  = (uint16_t) ((signed short) *p | (signed short) ((int) *(p +
1) << 8));

However, the return stmt should be:

return  = (uint16_t) (((int)(uint16_t) *p) | ((int)(uint16_t) *(p + 1)
<< 8));

then gcc will optimize it.

[Bug c++/89796] Incorrect warning generated with OpenMP atomic capture

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Tue Mar 26 07:54:02 2019
New Revision: 269933

URL: https://gcc.gnu.org/viewcvs?rev=269933&root=gcc&view=rev
Log:
PR c++/89796
* semantics.c (finish_omp_atomic): Add warning_sentinel for
-Wunused-value around finish_expr_stmt call.

* g++.dg/gomp/pr89796.C: New test.
* gcc.dg/gomp/pr89796.c: New test.

Added:
trunk/gcc/testsuite/g++.dg/gomp/pr89796.C
trunk/gcc/testsuite/gcc.dg/gomp/pr89796.c
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/89821] Get a SIGFPE on a simple test of a kind=real128 variable with -ffpe-trap=invalid switch

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
The invalid exception is raised here:

Program received signal SIGFPE, Arithmetic exception.
0x00400cde in demo_nan () at t.f90:17
17 if ( (r32<=0.0_real32) .or. (r32>=0.0_real32) )then

   0x00400cd2 <+416>:   movss  -0x134(%rbp),%xmm1
   0x00400cda <+424>:   pxor   %xmm0,%xmm0
=> 0x00400cde <+428>:   comiss %xmm1,%xmm0

where %xmm1 is NaN.

(gdb) p $xmm1
$2 = ( v4_float = (nan(0x40), 0, 0, 0),

so not sure what you are expecting?  Is Fortran supposed to use the
C equivalent of isgreaterequal (aka comparisons that do not raise
exceptions?)

[Bug libstdc++/89819] [9 Regression] std::variant operators regressed since GCC 8.3

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug tree-optimization/54779] split FRAME variables back into pieces

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

  Attachment #42158|0   |1
is obsolete||

--- Comment #10 from Eric Botcazou  ---
Created attachment 46021
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46021&action=edit
Updated implementation

For a 8-based compiler.

[Bug tree-optimization/54779] split FRAME variables back into pieces

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #11 from Jakub Jelinek  ---
Do you have a GCC10 implementation that could be submitted in stage1, or has
this been reviewed already earlier?

[Bug c++/62181] [C/C++] Expected new warning: "adding 'char' to a string does not append to the string" [-Wstring-plus-int]

[lopezibanez at gmail dot com]

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

--- Comment #18 from Manuel López-Ibáñez  ---
A large patch will often get lost in comments and revisions unless the
submitter is very insistent and committed. If you want to get this moving,
my advice would be to split out the smallest piece possible (string + char
literal) and just submit that for review. Once that is committed, then look
for the next smallest step and repeat.

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

[dongjianqiang2 at huawei dot com]

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

--- Comment #58 from John Dong  ---
Created attachment 46022
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46022&action=edit
fix the union bug on 7.3.0

[Bug tree-optimization/54779] split FRAME variables back into pieces

[ebotcazou at gcc dot gnu.org]

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

--- Comment #12 from Eric Botcazou  ---
> Do you have a GCC10 implementation that could be submitted in stage1, or has
> this been reviewed already earlier?

I should have one in a few weeks, but this indeed was reviewed and rejected
earlier.  The rationale given was that this should be done during the SRA pass
instead, but I disagree because I don't want it to be subject to the (complex)
heuristics used by the SRA pass.

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

[dongjianqiang2 at huawei dot com]

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

--- Comment #59 from John Dong  ---
(In reply to John Dong from comment #58)
> Created attachment 46022 [details]
> fix the union bug on 7.3.0

hi, I tried to fix the bug when expanding. is it OK?

[Bug d/89823] New: Composed message only partially translatable

[goeran at uddeborg dot se]

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

Bug ID: 89823
   Summary: Composed message only partially translatable
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: goeran at uddeborg dot se
  Target Milestone: ---

In d/dmd/expressionsem.c there is this piece of code:

> const char *s = exp->op == TOKplusplus ? "increment" : "decrement";
> exp->error("cannot post-%s array slice '%s', use pre-%s instead", s, 
> exp->e1->toChars(), s);

The string "cannot post-%s …" will be extracted for translation, but the
inserted words, "increment" and "decrement", will not.

At a minimum, these words need to be marked for translation too.  Better is
probably to make it two complete messages.  For Swedish it would work to
compose the sentence this way, but I suspect there are languages further
removed from English where it would be hard.

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

[rguenther at suse dot de]

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

--- Comment #60 from rguenther at suse dot de  ---
On Tue, 26 Mar 2019, dongjianqiang2 at huawei dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
> 
> --- Comment #59 from John Dong  ---
> (In reply to John Dong from comment #58)
> > Created attachment 46022 [details]
> > fix the union bug on 7.3.0
> 
> hi, I tried to fix the bug when expanding. is it OK?

No, the fix is going to be backported soon.

[Bug d/89823] Composed message only partially translatable

[ibuclaw at gdcproject dot org]

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

--- Comment #1 from Iain Buclaw  ---
(In reply to Göran Uddeborg from comment #0)
> In d/dmd/expressionsem.c there is this piece of code:
> 
> > const char *s = exp->op == TOKplusplus ? "increment" : "decrement";
> > exp->error("cannot post-%s array slice '%s', use pre-%s instead", s, 
> > exp->e1->toChars(), s);
> 
> The string "cannot post-%s …" will be extracted for translation, but the
> inserted words, "increment" and "decrement", will not.
> 
> At a minimum, these words need to be marked for translation too.  Better is
> probably to make it two complete messages.  For Swedish it would work to
> compose the sentence this way, but I suspect there are languages further
> removed from English where it would be hard.

The dmd sources should all be in the EXCLUDES file, I must have missed one when
grepping for the sources that have may emit an error.

[Bug c++/84598] [8/9 Regression] internal compiler error: Segmentation fault (cp_default_conversion())

[paolo at gcc dot gnu.org]

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

--- Comment #5 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Tue Mar 26 10:16:13 2019
New Revision: 269936

URL: https://gcc.gnu.org/viewcvs?rev=269936&root=gcc&view=rev
Log:
2019-03-26  Paolo Carlini  

PR c++/84598
* g++.dg/ext/pr84598.C: New.

Added:
trunk/gcc/testsuite/g++.dg/ext/pr84598.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/89824] New: Variant jump table reserves space for __variant_cookie twice

[antoshkka at gmail dot com]

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

Bug ID: 89824
   Summary: Variant jump table reserves space for __variant_cookie
twice
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antoshkka at gmail dot com
  Target Milestone: ---

Space for the `__variant_cookie` state is already reserved in _Multi_array
`_Multi_array<_Tp, __rest...> _M_arr[__first + __do_cookie];`.

Additionally reserving it inside the `__gen_vtable` produces jump table with
gaps https://godbolt.org/z/Vx_wEU.


Fix: remove the `+ (is_same_v<_Result_type, __variant_cookie> ? 1 : 0)` from
`__gen_vtable`.


This removes zeros from jump table and slightly reduces the binary size
https://godbolt.org/z/gyo0-j

[Bug c++/84598] [8 Regression] internal compiler error: Segmentation fault (cp_default_conversion())

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC|vegard.nossum at gmail dot com |
Summary|[8/9 Regression] internal   |[8 Regression] internal
   |compiler error: |compiler error:
   |Segmentation fault  |Segmentation fault
   |(cp_default_conversion())   |(cp_default_conversion())

--- Comment #6 from Paolo Carlini  ---
This is fixed in trunk. I added the testcase and removing the regression
marker. Note: there are duplicate diagnostics issues, but are well known.

[Bug rtl-optimization/89676] [7/8 Regression] Redundant moves for long long shift on 32bit x86

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |vmakarov at gcc dot 
gnu.org
Summary|[7/8/9 Regression]  |[7/8 Regression] Redundant
   |Redundant moves for long|moves for long long shift
   |long shift on 32bit x86 |on 32bit x86

--- Comment #10 from Jakub Jelinek  ---
Fixed on the trunk.

[Bug libstdc++/89824] Variant jump table reserves space for __variant_cookie twice

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-26
 Ever confirmed|0   |1

[Bug libstdc++/89825] New: Jump table for variant visitation could be shortened for never empty variants

[antoshkka at gmail dot com]

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

Bug ID: 89825
   Summary: Jump table for variant visitation could be shortened
for never empty variants
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antoshkka at gmail dot com
  Target Milestone: ---

The `__do_cookie` computation in `_Multi_array` seems suboptimal. There are
variant types that are never empty, so they never need the cookie value at all.
`_Variant_storage::_M_valid()` already use that knowledge to
always return `true`. The same logic could be used for the `__do_cookie`.

Pseudo-code:

+  template
+  struct _Never_empty;

+  template
+  struct _Never_empty>
+  {
+static constexpr bool _S_value = (is_trivially_copyable_v<_Types> && ...);
+  };

  template
struct _Multi_array<_Ret(*)(_Visitor, _Variants...), __first, __rest...>
{
+  static constexpr size_t __index = sizeof...(_Variants) -
sizeof...(__rest) - 1;
+  using _Variant_current = __remove_cvref_t::type>;
  static constexpr int __do_cookie =
-   is_same_v<_Ret, __variant_cookie> ? 1 : 0;
+   is_same_v<_Ret, __variant_cookie> &&
_Never_empty<_Variant_current>::_S_value ? 1 : 0;
  using _Tp = _Ret(*)(_Visitor, _Variants...);
  template
constexpr const _Tp&
_M_access(size_t __first_index, _Args... __rest_indices) const
{ return _M_arr[__first_index +
__do_cookie]._M_access(__rest_indices...); }

  _Multi_array<_Tp, __rest...> _M_arr[__first + __do_cookie];
  };


  template
static constexpr void
_S_apply_all_alts(_Array_type& __vtable,
  std::index_sequence<__var_indices...>)
{
- if constexpr (is_same_v<_Result_type, __variant_cookie>)
+ if constexpr (is_same_v<_Result_type, __variant_cookie>
+   && !_Never_empty>::_S_value)
(_S_apply_single_alt(
  __vtable._M_arr[__var_indices + 1],
  &(__vtable._M_arr[0])), ...);
  else
(_S_apply_single_alt(
  __vtable._M_arr[__var_indices]), ...);
}



The above patch reduces jump table size on up to 2*sizeof...(_Types) for binary
visitations.

[Bug libstdc++/89825] Jump table for variant visitation could be shortened for never empty variants

[antoshkka at gmail dot com]

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

--- Comment #1 from Antony Polukhin  ---
There's a typo in proposed solution: it should be `&& !_Never_empty` in
`_Multi_array`.

[Bug tree-optimization/81740] [7/8 Regression] wrong code at -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||9.0
Summary|[7/8/9 Regression] wrong|[7/8 Regression] wrong code
   |code at -O3 in both 32-bit  |at -O3 in both 32-bit and
   |and 64-bit modes on |64-bit modes on
   |x86_64-linux-gnu|x86_64-linux-gnu
  Known to fail||8.3.0

--- Comment #8 from Richard Biener  ---
Fixed on trunk sofar.

[Bug tree-optimization/81740] [7/8 Regression] wrong code at -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
Author: rguenth
Date: Tue Mar 26 11:12:37 2019
New Revision: 269938

URL: https://gcc.gnu.org/viewcvs?rev=269938&root=gcc&view=rev
Log:
2019-03-26  Bin Cheng  

PR tree-optimization/81740
* tree-vect-data-refs.c (vect_analyze_data_ref_dependence):
In case of outer loop vectorization, check for backward dependence
at the inner loop if outer loop dependence is reversed.

* gcc.dg/vect/pr81740-1.c: New testcase.
* gcc.dg/vect/pr81740-2.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/vect/pr81740-1.c
trunk/gcc/testsuite/gcc.dg/vect/pr81740-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-data-refs.c

[Bug tree-optimization/81740] [7/8 Regression] wrong code at -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #10 from Richard Biener  ---
Mine for backporting.

[Bug tree-optimization/88105] [7 Regression] Possibly infinite loop in pass_dominator::execute

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||7.4.1
 Resolution|--- |FIXED
  Known to fail|7.3.0   |7.4.0

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

[Bug tree-optimization/88105] [7 Regression] Possibly infinite loop in pass_dominator::execute

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Tue Mar 26 11:18:26 2019
New Revision: 269939

URL: https://gcc.gnu.org/viewcvs?rev=269939&root=gcc&view=rev
Log:
2019-03-26  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.

2018-11-20  Richard Biener  

PR tree-optimization/88105
* tree-ssa-dom.c (pass_dominator::execute): Do not walk
backedges.

* gcc.dg/gomp/pr88105.c: New testcase.

2018-03-08  Richard Biener  

PR middle-end/84552
* tree-scalar-evolution.c: Include tree-into-ssa.h.
(follow_copies_to_constant): Do not follow SSA names registered
for update.

* gcc.dg/graphite/pr84552.c: New testcase.

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.dg/gomp/pr88105.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/graphite/pr84552.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr86554-1.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr86554-2.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/tree-scalar-evolution.c
branches/gcc-7-branch/gcc/tree-ssa-dom.c
branches/gcc-7-branch/gcc/tree-ssa-sccvn.c

[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 #12 from Richard Biener  ---
Author: rguenth
Date: Tue Mar 26 11:18:26 2019
New Revision: 269939

URL: https://gcc.gnu.org/viewcvs?rev=269939&root=gcc&view=rev
Log:
2019-03-26  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.

2018-11-20  Richard Biener  

PR tree-optimization/88105
* tree-ssa-dom.c (pass_dominator::execute): Do not walk
backedges.

* gcc.dg/gomp/pr88105.c: New testcase.

2018-03-08  Richard Biener  

PR middle-end/84552
* tree-scalar-evolution.c: Include tree-into-ssa.h.
(follow_copies_to_constant): Do not follow SSA names registered
for update.

* gcc.dg/graphite/pr84552.c: New testcase.

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.dg/gomp/pr88105.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/graphite/pr84552.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr86554-1.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr86554-2.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/tree-scalar-evolution.c
branches/gcc-7-branch/gcc/tree-ssa-dom.c
branches/gcc-7-branch/gcc/tree-ssa-sccvn.c

[Bug tree-optimization/88240] Potential optimization bug: invalid pre-load of floating-point value could cause SIGFPE-underflow if value is integer

[rguenth at gcc dot gnu.org]

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

Bug 86554 Summary: [7 Regression] Incorrect code generation with 
signed/unsigned comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86554

   What|Removed |Added

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

[Bug tree-optimization/84552] [7 Regression] Compile time hog w/ -O2 -floop-nest-optimize -fno-tree-copy-prop -fno-tree-fre -fno-tree-loop-ivcanon

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Author: rguenth
Date: Tue Mar 26 11:18:26 2019
New Revision: 269939

URL: https://gcc.gnu.org/viewcvs?rev=269939&root=gcc&view=rev
Log:
2019-03-26  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.

2018-11-20  Richard Biener  

PR tree-optimization/88105
* tree-ssa-dom.c (pass_dominator::execute): Do not walk
backedges.

* gcc.dg/gomp/pr88105.c: New testcase.

2018-03-08  Richard Biener  

PR middle-end/84552
* tree-scalar-evolution.c: Include tree-into-ssa.h.
(follow_copies_to_constant): Do not follow SSA names registered
for update.

* gcc.dg/graphite/pr84552.c: New testcase.

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.dg/gomp/pr88105.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/graphite/pr84552.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr86554-1.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr86554-2.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/tree-scalar-evolution.c
branches/gcc-7-branch/gcc/tree-ssa-dom.c
branches/gcc-7-branch/gcc/tree-ssa-sccvn.c

[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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||7.4.1
 Resolution|--- |FIXED
  Known to fail||7.4.0

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

[Bug tree-optimization/84552] [7 Regression] Compile time hog w/ -O2 -floop-nest-optimize -fno-tree-copy-prop -fno-tree-fre -fno-tree-loop-ivcanon

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||7.4.1
 Resolution|--- |FIXED
  Known to fail||7.4.0

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

[Bug target/84201] 549.fotonik3d_r from SPEC2017 fails verification with recent Intel and AMD CPUs

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #8 from Martin Liška  ---
For some reason, I can't reproduce that now on Haswell with both GCC 8 and 9.
I'll retry with a Zen machine.

[Bug bootstrap/61448] ice on profiledbootstrap with -O2 -flto -fuse-linker-plugin

[belyshev at depni dot sinp.msu.ru]

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

Serge Belyshev  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||belyshev at depni dot 
sinp.msu.ru
 Resolution|--- |WORKSFORME

--- Comment #1 from Serge Belyshev  ---
This bug was never confirmed, but the similar configuration
(--enable-checking=release --with-arch=native --with-build-config=bootstrap-lto
 profiledbootstrap) works for me with current trunk on intel x86-64.  So this
bug was probably fixed at some point (long time ago).

Moreover, neither 4.8 nor 4.9 are supported anymore.

Closing as worksforme, please re-open if needed.

[Bug sanitizer/82501] AddressSanitizer does not handle negative offset for first global variable

[jakub at gcc dot gnu.org]

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

--- Comment #30 from Jakub Jelinek  ---
(In reply to Andrey Drobyshev from comment #26)
> > I would like to ask, has the idea of adding an artificial object linked with
> > -fsanitize=address early on the link line which would register artificial
> > dummy variables in at least the most common data sections been considered
> > and rejected?
> > I mean, it should at least for large libraries mean significantly fewer
> > dummy variables, on the other side, when mixing sanitized and non-sanitized
> > objects within one binary/library (having sanitized ones first and then say
> > linking a static library non-sanitized would be fine) would mean catching up
> > fewer issues.
> 
> Could you describe how you imagine this solution in more details? Wouldn't
> it require us to patch the linker along with compiler?

Exactly like we are doing it already in other cases, look at libgcc/crtstuff.c
which e.g. adds (or depending on configuration used to add) snippets of various
sections early when compiled as crtbegin.o or crtbeginS.o etc. and snippets of
various sections late when compiled as crtend.o etc.
So, it would be a matter of adding another object like asan_preinit.o, that
would contain registered empty globals in a couple of most common data
sections, be compiled with -fpic and link it in in LIBASAN_EARLY_SPEC, unlike
libasan_preinit regardless of -shared or not.

[Bug libstdc++/89816] [9 Regression] std::variant move construction regressed since GCC 8.3

[ville at gcc dot gnu.org]

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

--- Comment #11 from ville at gcc dot gnu.org ---
Author: ville
Date: Tue Mar 26 12:07:26 2019
New Revision: 269940

URL: https://gcc.gnu.org/viewcvs?rev=269940&root=gcc&view=rev
Log:
PR libstdc++/89816

Fix based on a suggestion by Antony Polukhin.
* include/std/variant (__variant_construct): Capture a pointer
to the storage and visit just one variant.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/variant

[Bug rtl-optimization/89826] New: [9 Regression] wrong code at -O1

[zsojka at seznam dot cz]

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

Bug ID: 89826
   Summary: [9 Regression] wrong code at -O1
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: armv7a-hardfloat-linux-gnueabi

Created attachment 46023
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46023&action=edit
reduced testcase

This seems to be a recent regression.

Output:
$ armv7a-hardfloat-linux-gnueabi-gcc -O testcase.c -static
$ ./a.out
qemu: uncaught target signal 6 (Aborted) - core dumped
Aborted

The upper 32 bits seem to be garbage - r1 is used uninitialized.

@@ -29,6 +29,7 @@
ldr ip, [r3, #4]
cmp r0, #0
mov r3, #0
+   mov r1, r3
mvneq   r3, r2
mvneq   r1, ip
subsr4, r2, r3

should fix the assembly.


$ armv7a-hardfloat-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-armv7a-hardfloat/bin/armv7a-hardfloat-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-269932-checking-yes-rtl-df-extra-armv7a-hardfloat/bin/../libexec/gcc/armv7a-hardfloat-linux-gnueabi/9.0.1/lto-wrapper
Target: armv7a-hardfloat-linux-gnueabi
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --with-float=hard --with-fpu=vfpv4
--with-arch=armv7-a --with-sysroot=/usr/armv7a-hardfloat-linux-gnueabi
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=armv7a-hardfloat-linux-gnueabi
--with-ld=/usr/bin/armv7a-hardfloat-linux-gnueabi-ld
--with-as=/usr/bin/armv7a-hardfloat-linux-gnueabi-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-269932-checking-yes-rtl-df-extra-armv7a-hardfloat
Thread model: posix
gcc version 9.0.1 20190326 (experimental) (GCC)

[Bug libstdc++/89825] Jump table for variant visitation could be shortened for never empty variants

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-26
 Ever confirmed|0   |1

--- Comment #2 from Jonathan Wakely  ---
N.B. we can't use this patch without a copyright assignment for GCC:
https://gcc.gnu.org/contribute.html

Posting patches we can't use is actually more harmful than helpful, because to
ensure we don't infringe your copyright we either have to avoid even reading
the patch, or try to solve the problem differently. Describing a suggeasted
solution without an actual patch is fine.

Would you be willing to complete a copyright assignment for contributions to
GCC?

[Bug target/89827] New: [8/9 Regression] ICE: in convert_op, at config/i386/i386.c:2098 with -Os -maes

[zsojka at seznam dot cz]

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

Bug ID: 89827
   Summary: [8/9 Regression] ICE: in convert_op, at
config/i386/i386.c:2098 with -Os -maes
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: i686-pc-linux-gnu

Created attachment 46024
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46024&action=edit
reduced testcase

Compiler output:
$ i686-pc-linux-gnu-gcc -Os -maes testcase.c 
during RTL pass: stv
testcase.c: In function 'foo':
testcase.c:7:1: internal compiler error: in convert_op, at
config/i386/i386.c:2098
7 | }
  | ^
0x7303d3 dimode_scalar_chain::convert_op(rtx_def**, rtx_insn*)
/repo/gcc-trunk/gcc/config/i386/i386.c:2098
0x1198987 dimode_scalar_chain::convert_insn(rtx_insn*)
/repo/gcc-trunk/gcc/config/i386/i386.c:2168
0x1198da4 scalar_chain::convert()
/repo/gcc-trunk/gcc/config/i386/i386.c:2408
0x1198da4 scalar_chain::convert()
/repo/gcc-trunk/gcc/config/i386/i386.c:2392
0x119985c convert_scalars_to_vector
/repo/gcc-trunk/gcc/config/i386/i386.c:2474
0x119985c execute
/repo/gcc-trunk/gcc/config/i386/i386.c:2592
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ i686-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-i686/bin/i686-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-269932-checking-yes-rtl-df-extra-i686/bin/../libexec/gcc/i686-pc-linux-gnu/9.0.1/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --with-sysroot=/usr/i686-pc-linux-gnu
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=i686-pc-linux-gnu --with-ld=/usr/bin/i686-pc-linux-gnu-ld
--with-as=/usr/bin/i686-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-269932-checking-yes-rtl-df-extra-i686
Thread model: posix
gcc version 9.0.1 20190326 (experimental) (GCC)

[Bug libstdc++/89825] Jump table for variant visitation could be shortened for never empty variants

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #2)
> Would you be willing to complete a copyright assignment for contributions to
> GCC?

And then ideally, make lots more contributions :-)

[Bug libstdc++/89825] Jump table for variant visitation could be shortened for never empty variants

[antoshkka at gmail dot com]

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

--- Comment #4 from Antony Polukhin  ---
> Would you be willing to complete a copyright assignment for contributions to
> GCC?

Yes, I can do that. Please send the instructions to my email.

[Bug libstdc++/89824] Variant jump table reserves space for __variant_cookie twice

[ville at gcc dot gnu.org]

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

--- Comment #1 from ville at gcc dot gnu.org ---
Author: ville
Date: Tue Mar 26 12:41:59 2019
New Revision: 269941

URL: https://gcc.gnu.org/viewcvs?rev=269941&root=gcc&view=rev
Log:
PR libstdc++/89824

Fix based on a suggestion by Antony Polukhin.
* include/std/variant (__gen_vtable): Don't reserve an
additional table slot, _Multi_array already does that.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/variant

[Bug target/89827] [8/9 Regression] ICE: in convert_op, at config/i386/i386.c:2098 with -Os -maes

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-26
 CC||hjl.tools at gmail dot com
 Ever confirmed|0   |1

--- Comment #1 from Uroš Bizjak  ---
Actually a STV problem, needs "-O2 -msse2 -mstv".

CC added.

[Bug bootstrap/59528] Profiledbootstrap should use stage1 compiler during stagefeedback

[belyshev at depni dot sinp.msu.ru]

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

Serge Belyshev  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||belyshev at depni dot 
sinp.msu.ru
 Resolution|--- |FIXED
   Target Milestone|--- |8.0

--- Comment #4 from Serge Belyshev  ---
(In reply to Richard Biener from comment #1)
> Can you point to a version where we did that?

Before r101263, I think.

Anyhow, this is fixed since introduction of 4-stage profiledbootstrap
(r249366), because final stagefeedback binary is built by stagetrain.

Closing as fixed.

[Bug c/89812] [9 Regression] incorrect maximum in error: requested alignment ‘536870912’ exceeds maximum 2147483648

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #5 from Christophe Lyon  ---
The new test fails on arm with these additional error message:
testsuite/gcc.dg/attr-aligned-3.c:6:47: error: ISO C90 does not support 'long
long' [-Wlong-long]

[Bug c/89828] New: Inernal compiler error on -fno-omit-frame-pointer

[ysato at users dot sourceforge.jp]

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

Bug ID: 89828
   Summary: Inernal compiler error on -fno-omit-frame-pointer
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ysato at users dot sourceforge.jp
  Target Milestone: ---

Created attachment 46025
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46025&action=edit
problem happened source code

I got following errors.
$ rx-elf-gcc -c -O2 -g -fno-omit-frame-pointer core.c
during RTL pass: dwarf2
kernel/sched/core.c: In function '__schedule_bug':
kernel/sched/core.c:3277:1: internal compiler error: in
dwarf2out_frame_debug_adjust_cfa, at dwarf2cfi.c:1183
 3277 | }
  | ^
0x75efc9 dwarf2out_frame_debug_adjust_cfa
../../gcc/dwarf2cfi.c:1183
0x75efc9 dwarf2out_frame_debug
../../gcc/dwarf2cfi.c:2079
0x75efc9 scan_insn_after
../../gcc/dwarf2cfi.c:2511
0x75f188 scan_trace
../../gcc/dwarf2cfi.c:2678
0x75fdca create_cfi_notes
../../gcc/dwarf2cfi.c:2722
0x75fdca execute_dwarf2_frame
../../gcc/dwarf2cfi.c:3086
0x75fdca execute
../../gcc/dwarf2cfi.c:3574
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

rx-elf-gcc -c -O2 -g -fomit-frame-pointer core.c
works fine.

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

[rguenth at gcc dot gnu.org]

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

--- Comment #61 from Richard Biener  ---
Author: rguenth
Date: Tue Mar 26 13:18:23 2019
New Revision: 269942

URL: https://gcc.gnu.org/viewcvs?rev=269942&root=gcc&view=rev
Log:
2019-02-26  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-7-branch/gcc/testsuite/gcc.c-torture/execute/pr88739.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr89223.c
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr89253.f
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/tree-data-ref.c
branches/gcc-7-branch/gcc/tree-ssa-loop-split.c
branches/gcc-7-branch/gcc/tree-ssa-sccvn.c

[Bug tree-optimization/89223] [7 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 #13 from Richard Biener  ---
Author: rguenth
Date: Tue Mar 26 13:18:23 2019
New Revision: 269942

URL: https://gcc.gnu.org/viewcvs?rev=269942&root=gcc&view=rev
Log:
2019-02-26  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-7-branch/gcc/testsuite/gcc.c-torture/execute/pr88739.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr89223.c
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr89253.f
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/tree-data-ref.c
branches/gcc-7-branch/gcc/tree-ssa-loop-split.c
branches/gcc-7-branch/gcc/tree-ssa-sccvn.c

[Bug regression/89733] [7/8/9 Regression] False positive -Wuninitialized in C++14+ mode

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
I'm certainly seeing the uninitialized loads in the IL though.

typename Lexer::iterator_type iter = lex.begin(first, last);
in tokenize_and_parse calls
template 
iterator_type begin(Iterator& first, Iterator const& last
, char_type const* initial_state = 0) const
{ return this->lexer_type::begin(first, last, initial_state); }
which calls
template 
iterator(IteratorData const& iterdata_, base_iterator_type& first
  , base_iterator_type const& last, char_type const* state = 0)
  : base_type(functor_type(unique_functor_type()
  , shared_functor_type(iterdata_, first, last)))
{
set_state(map_state(state));
}
which calls:
  template()
 && _PCCP::template
  _ImplicitlyMoveConvertiblePair<_U1, _U2>(),
 bool>::type=true>
 constexpr pair(_U1&& __x, _U2&& __y)
 : first(std::forward<_U1>(__x)), second(std::forward<_U2>(__y)) { }
which calls:
template 
class data
  : public data
{
's defaulted copy constructor, which would like to copy end_ among other
non-static data members, but that is uninitialized.
It can be seen after the inlining already:
  [./boost/spirit/home/lex/lexer/lexertl/functor_data.hpp:300:13] MEM[(struct 
&)[./boost/spirit/home/lex/lexer/lexertl/iterator.hpp:85:61] &D.5608
49] ={v} {CLOBBER};
  [./boost/spirit/home/lex/lexer/lexertl/functor_data.hpp:221:13] MEM[(struct 
&)[./boost/spirit/home/lex/lexer/lexertl/iterator.hpp:85:61] &D.5608
49] ={v} {CLOBBER};
  [./boost/spirit/home/lex/lexer/lexertl/functor_data.hpp:57:13] MEM[(struct 
&)[./boost/spirit/home/lex/lexer/lexertl/iterator.hpp:85:61] &D.56084
9] ={v} {CLOBBER};
  [./boost/spirit/home/lex/lexer/lexertl/functor_data.hpp:61:69]
[./boost/spirit/home/lex/lexer/lexertl/functor_data.hpp:61:69] MEM[(struct data
*)
[./boost/spirit/home/lex/lexer/lexertl/iterator.hpp:85:61] &D.560849].first_ =
first_3(D);
  [./boost/spirit/home/lex/lexer/lexertl/functor_data.hpp:61:69] _87 =
last_407(D);
  [./boost/spirit/home/lex/lexer/lexertl/functor_data.hpp:61:69]
[./boost/spirit/home/lex/lexer/lexertl/functor_data.hpp:61:69] MEM[(struct data
*)
[./boost/spirit/home/lex/lexer/lexertl/iterator.hpp:85:61] &D.560849].last_ =
_87;
  [./boost/spirit/home/lex/lexer/lexertl/functor_data.hpp:59:38] _88 =
[./boost/spirit/home/lex/lexer/lexertl/functor_data.hpp:59:38] MEM[(const st
ruct iterator_data_type
&)[./boost/spirit/home/lex/lexer/lexertl/lexer.hpp:205:34]
&iterator_data].state_machine_;
  [./boost/spirit/home/lex/lexer/lexertl/functor_data.hpp:61:69]
[./boost/spirit/home/lex/lexer/lexertl/functor_data.hpp:61:69] MEM[(struct data
*)
[./boost/spirit/home/lex/lexer/lexertl/iterator.hpp:85:61]
&D.560849].state_machine_ = _88;
  [./boost/spirit/home/lex/lexer/lexertl/functor_data.hpp:60:30] _89 =
[./boost/spirit/home/lex/lexer/lexertl/functor_data.hpp:60:30] MEM[(const st
ruct iterator_data_type
&)[./boost/spirit/home/lex/lexer/lexertl/lexer.hpp:205:34]
&iterator_data].rules_;
  [./boost/spirit/home/lex/lexer/lexertl/functor_data.hpp:61:69]
[./boost/spirit/home/lex/lexer/lexertl/functor_data.hpp:61:69] MEM[(struct data
*)
[./boost/spirit/home/lex/lexer/lexertl/iterator.hpp:85:61] &D.560849].rules_ =
_89;
  [./boost/spirit/home/lex/lexer/lexertl/functor_data.hpp:61:50] _90 =
[./boost/spirit/home/lex/lexer/lexertl/functor_data.hpp:61:50] MEM[(const
struct internals &)_88]._seen_BOL_assertion;
  [./boost/spirit/home/lex/lexer/lexertl/functor_data.hpp:61:69]
[./boost/spirit/home/lex/lexer/lexertl/functor_data.hpp:61:69] MEM[(struct data
*)[./boost/spirit/home/lex/lexer/lexertl/iterator.hpp:85:61] &D.560849].bol_ =
_90;
  [./boost/spirit/home/lex/lexer/lexertl/functor_data.hpp:223:25]
[./boost/spirit/home/lex/lexer/lexertl/functor_data.hpp:223:25] MEM[(struct
data *)[./boost/spirit/home/lex/lexer/lexertl/iterator.hpp:85:61]
&D.560849].state_ = 0;
  [./boost/spirit/home/lex/lexer/lexertl/functor_data.hpp:302:32] _91 =
[./boost/spirit/home/lex/lexer/lexertl/functor_data.hpp:302:32] MEM[(const
struct iterator_data_type
&)[./boost/spirit/home/lex/lexer/lexertl/lexer.hpp:205:34]
&iterator_data].actions_;
  [./boost/spirit/home/lex/lexer/lexertl/functor_data.hpp:304:51]
[./boost/spirit/home/lex/lexer/lexertl/functor_data.hpp:304:51] MEM[(struct
data *)[./boost/spirit/home/lex/lexer/lexertl/iterator.hpp:85:61]
&D.560849].actions_ = _91;
  [./boost/spirit/home/lex/lexer/lexertl/functor_data.hpp:304:51]
[./boost/spirit/home/lex/lexer/lexertl/functor_data.hpp:304:51] MEM[(struct
data *)[./boost/spirit/home/lex/lexer/lexertl/iterator.hpp:85:61]
&D.560849].hold_ = 0B;
  [./boo

[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 #5 from Richard Biener  ---
Author: rguenth
Date: Tue Mar 26 13:18:23 2019
New Revision: 269942

URL: https://gcc.gnu.org/viewcvs?rev=269942&root=gcc&view=rev
Log:
2019-02-26  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-7-branch/gcc/testsuite/gcc.c-torture/execute/pr88739.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr89223.c
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr89253.f
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/tree-data-ref.c
branches/gcc-7-branch/gcc/tree-ssa-loop-split.c
branches/gcc-7-branch/gcc/tree-ssa-sccvn.c

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||7.4.1
 Resolution|--- |FIXED
  Known to fail||7.4.0

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

[Bug tree-optimization/89223] [7 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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||7.4.1
 Resolution|--- |FIXED
  Known to fail||7.4.0

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

[Bug lto/88386] LTRANS DWO files are not removed when using LTO + Split Dwarf

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |DUPLICATE

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

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

[Bug debug/88389] -flto -g -gsplit-dwarf is broken

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||antonio.di.monaco at sap dot 
com

--- Comment #7 from Richard Biener  ---
*** Bug 88386 has been marked as a duplicate of this bug. ***

[Bug target/84201] 549.fotonik3d_r from SPEC2017 fails verification with recent Intel and AMD CPUs

[marxin at gcc dot gnu.org]

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

--- Comment #9 from Martin Liška  ---
(In reply to Martin Liška from comment #8)
> For some reason, I can't reproduce that now on Haswell with both GCC 8 and
> 9. I'll retry with a Zen machine.

The reason is that I had adjusted tolerance for the test from 1e-10 to 1e-9.

[Bug target/89827] [8/9 Regression] ICE: in convert_op, at config/i386/i386.c:2098 with -Os -maes

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|--- |8.4

[Bug rtl-optimization/89826] [9 Regression] wrong code at -O1

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org
   Target Milestone|--- |9.0

--- Comment #1 from Richard Biener  ---
regcprop changes maybe

[Bug target/89827] [8/9 Regression] ICE: in convert_op, at config/i386/i386.c:2098 with -Os -maes

[ubizjak at gmail dot com]

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

--- Comment #2 from Uroš Bizjak  ---
We need something like this patch:

--cut here--
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index b5f20f1597ed..3ea545732dfd 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -2040,6 +2040,7 @@ dimode_scalar_chain::convert_reg (unsigned regno)

emit_insn_before (seq, insn);

+   XEXP (src, 0) = replace_with_subreg (XEXP (src, 0), reg, reg);
XEXP (src, 1) = gen_rtx_SUBREG (DImode, tmp2, 0);
  }
else if (!MEM_P (dst) || !REG_P (src))
--cut here--

[Bug libstdc++/89825] Jump table for variant visitation could be shortened for never empty variants

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||ville.voutilainen at gmail dot 
com
   Assignee|unassigned at gcc dot gnu.org  |ville.voutilainen at 
gmail dot com

[Bug other/89829] New: incorrect profile data is used during profiledbootstrap

[belyshev at depni dot sinp.msu.ru]

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

Bug ID: 89829
   Summary: incorrect profile data is used during
profiledbootstrap
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: belyshev at depni dot sinp.msu.ru
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Looking at the *.gcda timestamps, I noticed that incorrect data (the one from
stageprofile libgcc build) is used, and correct one (from stagetrain) is
discarded.

The fix is just to revert r254150 which effectively undid 4-stage
profiledbootstrap to a previous status quo where only libgcc training data was
used.

Also note that the r254150 confusion probably stems from the fact that there
are two stagefeedback-start:: rules in the Makefile.tpl, where the first one is
generated from stage[+id+]-start:: template.  The corresponding recipes are
executed both, and they are not independent as the first one renames directory
structure by doing 'make stage'.  This (ab)use of double-colon rules is not
recommended by the GNU make documentation, see
https://www.gnu.org/software/make/manual/html_node/Double_002dColon.html#Double_002dColon
.

[Bug c++/81757] function reference on nonnull and noexcept

[patrick.a.moran at gmail dot com]

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

Patrick Moran  changed:

   What|Removed |Added

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

--- Comment #1 from Patrick Moran  ---
I returned to check on this bug and it appears this no longer occurs in either
the 7.2.0 release nor in 8.3.0. Closing this since it was fixed.

[Bug regression/89733] [7/8/9 Regression] False positive -Wuninitialized in C++14+ mode

[nok.raven at gmail dot com]

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

--- Comment #4 from Nikita Kniazev  ---
So the warning triggers intentionally in copy/move even if the value actually
not read anywhere in the user code?

[Bug libstdc++/89825] Jump table for variant visitation could be shortened for never empty variants

[ville at gcc dot gnu.org]

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

--- Comment #5 from ville at gcc dot gnu.org ---
Author: ville
Date: Tue Mar 26 15:00:05 2019
New Revision: 269947

URL: https://gcc.gnu.org/viewcvs?rev=269947&root=gcc&view=rev
Log:
PR libstdc++/89825

Fix based on a suggestion by Antony Polukhin.
* include/std/variant (_Extra_visit_slot_needed): New.
(_Multi_array): Use it.
(_S_apply_all_alts): Likewise.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/variant

[Bug regression/89733] [7/8/9 Regression] False positive -Wuninitialized in C++14+ mode

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
The warning triggers when the warning pass sees uninitialized uses in the IL
(and quite complex code doesn't prove that it is not actually impossible at
runtime (predicate aware analysis).
You are using -O1, so fewer optimizations happen, haven't tried if it goes away
with -O2.

[Bug rtl-optimization/89826] [9 Regression] wrong code at -O1

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-26
 CC||law at redhat dot com
   Assignee|unassigned at gcc dot gnu.org  |law at redhat dot com
 Ever confirmed|0   |1

[Bug rtl-optimization/89826] [9 Regression] wrong code at -O1

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Yes, started with r269896:
+deferring deletion of insn with uid = 50.
+deferring rescan insn with uid = 54.
 insn 55: replaced reg 3 with 0
+deferring rescan insn with uid = 55.
+deferring rescan insn with uid = 55.
+starting the processing of deferred insns
+verify found no changes in insn with uid = 54.
 rescanning insn with uid = 55.
+ending the processing of deferred insns
+df_analyze called
+df_worklist_dataflow_doublequeue: n_basic_blocks 3 n_edges 2 count 3 (1)
+deferring deletion of insn with uid = 54.
+starting the processing of deferred insns
+ending the processing of deferred insns
+df_analyze called
+df_worklist_dataflow_doublequeue: n_basic_blocks 3 n_edges 2 count 3 (1)

-(insn 49 9 50 2 (set (reg:SI 3 r3 [orig:126 iftmp.1_5 ] [126])
+(insn 49 9 12 2 (set (reg:SI 3 r3 [orig:126 iftmp.1_5 ] [126])
 (const_int 0 [0])) "pr89826.c":9:14 181 {*arm_movsi_insn}
  (nil))
-(insn 50 49 12 2 (set (reg:SI 1 r1 [orig:127 iftmp.1_5+4 ] [127])
-(reg:SI 3 r3 [orig:126 iftmp.1_5 ] [126])) "pr89826.c":9:14 181
{*arm_movsi_insn}
- (expr_list:REG_DEAD (reg:SI 3 r3 [orig:126 iftmp.1_5 ] [126])
-(expr_list:REG_UNUSED (reg:SI 1 r1 [orig:127 iftmp.1_5+4 ] [127])
-(nil
-(insn 12 50 13 2 (cond_exec (eq (reg:CC 100 cc)
+(insn 12 49 13 2 (cond_exec (eq (reg:CC 100 cc)
 (const_int 0 [0]))
 (set (reg:SI 3 r3 [orig:126 iftmp.1_5 ] [126])
 (not:SI (reg:SI 2 r2 [orig:124 a.0_1 ] [124] "pr89826.c":9:14
3805 {*p *arm_one_cmplsi2}
  (nil))
 (insn 13 12 39 2 (cond_exec (eq (reg:CC 100 cc)
 (const_int 0 [0]))
 (set (reg:SI 1 r1 [orig:127 iftmp.1_5+4 ] [127])
 (not:SI (reg:SI 12 ip [orig:125 a.0_1+4 ] [125]
"pr89826.c":9:14 3805 {*p *arm_one_cmplsi2}
- (nil))
+ (expr_list:REG_DEAD (reg:CC 100 cc)
+(nil)))
 (insn 39 13 40 2 (parallel [
 (set (reg:CC 100 cc)
 (compare:CC (reg:SI 2 r2 [orig:124 a.0_1 ] [124])
 (reg:SI 3 r3 [orig:126 iftmp.1_5 ] [126])))
 (set (reg:SI 4 r4 [orig:111 _2 ] [111])
 (minus:SI (reg:SI 2 r2 [orig:124 a.0_1 ] [124])
 (reg:SI 3 r3 [orig:126 iftmp.1_5 ] [126])))
 ]) "pr89826.c":9:5 28 {subsi3_compare1}
  (expr_list:REG_DEAD (reg:SI 3 r3 [orig:126 iftmp.1_5 ] [126])
 (expr_list:REG_DEAD (reg:SI 2 r2 [orig:124 a.0_1 ] [124])
 (nil

[Bug rtl-optimization/89826] [9 Regression] wrong code at -O1

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
That REG_UNUSED note on r1 looks weird.
In postreload_jump we have:
(insn 49 11 50 3 (set (reg:SI 3 r3 [orig:126 iftmp.1_5 ] [126])
(const_int 0 [0])) "pr89826.c":9:14 181 {*arm_movsi_insn}
 (expr_list:REG_EQUAL (const_int 0 [0])
(nil)))
(insn 50 49 12 3 (set (reg:SI 1 r1 [orig:127 iftmp.1_5+4 ] [127])
(const_int 0 [0])) "pr89826.c":9:14 181 {*arm_movsi_insn}
 (expr_list:REG_EQUAL (const_int 0 [0])
(nil)))
(insn 12 50 13 3 (set (reg:SI 3 r3 [orig:126 iftmp.1_5 ] [126])
(not:SI (reg:SI 2 r2 [orig:124 a.0_1 ] [124]))) "pr89826.c":9:14 156
{*arm_one_cmplsi2}
 (nil))
(insn 13 12 37 3 (set (reg:SI 1 r1 [orig:127 iftmp.1_5+4 ] [127])
(not:SI (reg:SI 12 ip [orig:125 a.0_1+4 ] [125]))) "pr89826.c":9:14 156
{*arm_one_cmplsi2}
 (nil))
which looks normal, but contains non-DCEd code (that was there since subreg
pass
that lowered:
(insn 35 11 12 3 (set (reg:DI 114 [ iftmp.1_5 ])
(const_int 0 [0])) "pr89826.c":9:14 -1
 (nil))
(insn 12 35 13 3 (set (subreg:SI (reg:DI 114 [ iftmp.1_5 ]) 0)
(not:SI (subreg:SI (reg:DI 110 [ a.0_1 ]) 0))) "pr89826.c":9:14 156
{*arm_one_cmplsi2}
 (nil))
(insn 13 12 37 3 (set (subreg:SI (reg:DI 114 [ iftmp.1_5 ]) 4)
(not:SI (subreg:SI (reg:DI 110 [ a.0_1 ]) 4))) "pr89826.c":9:14 156
{*arm_one_cmplsi2}
 (nil))
).
In jump2 we have:
(insn 50 49 12 3 (set (reg:SI 1 r1 [orig:127 iftmp.1_5+4 ] [127])
(reg:SI 3 r3 [orig:126 iftmp.1_5 ] [126])) "pr89826.c":9:14 181
{*arm_movsi_insn}
 (expr_list:REG_DEAD (reg:SI 3 r3 [orig:126 iftmp.1_5 ] [126])
(expr_list:REG_UNUSED (reg:SI 1 r1 [orig:127 iftmp.1_5+4 ] [127])
(expr_list:REG_EQUAL (const_int 0 [0])
(nil)
(insn 12 50 13 3 (set (reg:SI 3 r3 [orig:126 iftmp.1_5 ] [126])
(not:SI (reg:SI 2 r2 [orig:124 a.0_1 ] [124]))) "pr89826.c":9:14 156
{*arm_one_cmplsi2}
 (nil))
(insn 13 12 37 3 (set (reg:SI 1 r1 [orig:127 iftmp.1_5+4 ] [127])
(not:SI (reg:SI 12 ip [orig:125 a.0_1+4 ] [125]))) "pr89826.c":9:14 156
{*arm_one_cmplsi2}
 (nil))
that still has the dead code in there and makes through REG_UNUSED clear it is
unused.
But then ce3 turns it into:
(insn 49 9 50 2 (set (reg:SI 3 r3 [orig:126 iftmp.1_5 ] [126])
(const_int 0 [0])) "pr89826.c":9:14 181 {*arm_movsi_insn}
 (nil))
(insn 50 49 12 2 (set (reg:SI 1 r1 [orig:127 iftmp.1_5+4 ] [127])
(reg:SI 3 r3 [orig:126 iftmp.1_5 ] [126])) "pr89826.c":9:14 181
{*arm_movsi_insn}
 (expr_list:REG_DEAD (reg:SI 3 r3 [orig:126 iftmp.1_5 ] [126])
(expr_list:REG_UNUSED (reg:SI 1 r1 [orig:127 iftmp.1_5+4 ] [127])
(nil
(insn 12 50 13 2 (cond_exec (eq (reg:CC 100 cc)
(const_int 0 [0]))
(set (reg:SI 3 r3 [orig:126 iftmp.1_5 ] [126])
(not:SI (reg:SI 2 r2 [orig:124 a.0_1 ] [124] "pr89826.c":9:14
3805 {*p *arm_one_cmplsi2}
 (nil))
(insn 13 12 39 2 (cond_exec (eq (reg:CC 100 cc)
(const_int 0 [0]))
(set (reg:SI 1 r1 [orig:127 iftmp.1_5+4 ] [127])
(not:SI (reg:SI 12 ip [orig:125 a.0_1+4 ] [125]
"pr89826.c":9:14 3805 {*p *arm_one_cmplsi2}
 (nil))
So, if the problem is using REG_UNUSED note, something forgot to recompute the
notes problem (regcprop?).

[Bug bootstrap/89829] incorrect profile data is used during profiledbootstrap

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-03-26
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Let me take a look.

[Bug regression/89733] [7/8/9 Regression] False positive -Wuninitialized in C++14+ mode

[nok.raven at gmail dot com]

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

--- Comment #6 from Nikita Kniazev  ---
I understand. I though that -Wuninitialized should not produce false positives
and that's a main difference between it and -Wno-maybe-uninitialized.

The warning does not go away and does not change to -Wno-maybe-uninitialized on
higher optimization levels. https://wandbox.org/permlink/xsdWxIEfAHDRcAyl

Also the warning message could be better, currently it's not clear that it
comes from the implicit constructor.

I am fine with fixing my code and closing this issue if you think that there is
no problem in GCC. Thanks for spending your time on this.

[Bug c/89812] [9 Regression] incorrect maximum in error: requested alignment ‘536870912’ exceeds maximum 2147483648

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
The test is broken in multiple ways.  The long long diagnostics can be fixed
e.g. through adding { dg-options "" }, but there is more serious problem that
the test hardcodes the 1 << 28 MAX_OFILE_ALIGNMENT, which is only one of many
possible values:
defaults.h:#ifndef MAX_OFILE_ALIGNMENT
defaults.h:#define MAX_OFILE_ALIGNMENT BIGGEST_ALIGNMENT
config/alpha/vms.h:#define MAX_OFILE_ALIGNMENT 524288  /* 8 x 2^16 by DEC Ada
Test CD40VRA */
config/microblaze/microblaze.h:#define MAX_OFILE_ALIGNMENT 
(32768*8)
config/avr/elf.h:#define MAX_OFILE_ALIGNMENT (32768 * 8)
config/i386/xm-djgpp.h:#define MAX_OFILE_ALIGNMENT 128
config/i386/cygming.h:#define MAX_OFILE_ALIGNMENT (8192 * 8)
config/ia64/vms.h:#define MAX_OFILE_ALIGNMENT 524288  /* 8 x 2^16 by DEC Ada
Test CD40VRA */
config/pa/elf.h:#define MAX_OFILE_ALIGNMENT (32768 * 8)
config/pa/som.h:#define MAX_OFILE_ALIGNMENT 32768
config/pa/pa64-hpux.h:#define MAX_OFILE_ALIGNMENT 32768
config/darwin.h:#define MAX_OFILE_ALIGNMENT (0x8000 * 8)
config/nvptx/nvptx.h:#define MAX_OFILE_ALIGNMENT (32768 * 8)
config/mmix/mmix.h:#define MAX_OFILE_ALIGNMENT (32768 * 8)
config/elfos.h:#define MAX_OFILE_ALIGNMENT (((unsigned int) 1 << 28) * 8)
config/rs6000/xcoff.h:#define MAX_OFILE_ALIGNMENT 32768

We don't have an ELF effective target but I think even all ELF targets don't
actually use the 1 << 28 even when ignoring the above clearly visible AVR case
- any ELF target that doesn't use elfos.h and rolls stuff on its own and not
listed above will use BIGGEST_ALIGNMENT, which is most likely not 1 << 28.

So, I think we just need to limit the test to a couple of most common targets
with 1 << 28 max ofile alignment.

[Bug libstdc++/85965] [8/9 Regression] G++ gives cryptic error instead of incomplete type

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Author: redi
Date: Tue Mar 26 15:28:48 2019
New Revision: 269949

URL: https://gcc.gnu.org/viewcvs?rev=269949&root=gcc&view=rev
Log:
PR libstdc++/85965 delay static assertions until types are complete

The static assertions added for PR libstdc++/48101 were at class scope
and so were evaluated too eagerly, when it might not be possible to
determine whether the function objects are invocable with the key types.
The problematic cases are where the key type is not known to be
convertible to the argument type(s) of the function object until later,
after a type has been completed. Specifically, if the key type is a
pointer to a derived class and the function object's argument type is a
pointer to a base class, then the derived-to-base conversion is only
valid once the derived type is complete.

By moving the static assertions to the destructor they will only be
evaluated when the destructor is instantiated, at which point whether
the key type can be passed to the function object should be knowable.
The ideal place to do the checks would be only when the function objects
are actually invoked, but that would mean adding the checks in numerous
places, so the destructor is used instead.

The tests need to be adjusted because the "required from here" line is
now the location of the destructor, not the point of instantiation in
the test file. For the map and multimap tests which check two
specializations, the dg-error matching the assertion text matches both
cases. Also check the diagnostic output for the template arguments, to
ensure both specializations trigger the assertion.

PR libstdc++/85965
* include/bits/hashtable.h (_Hashtable): Move static assertions to
destructor so they are not evaluated until the _Key type is complete.
* include/bits/stl_tree.h (_Rb_tree): Likewise.
* testsuite/23_containers/set/85965.cc: New test.
* testsuite/23_containers/unordered_set/85965.cc: New test.
* testsuite/23_containers/map/48101_neg.cc: Replace "here" errors
with regexp matching the corresponding _Rb_tree specialization.
* testsuite/23_containers/multimap/48101_neg.cc: Likewise.
* testsuite/23_containers/multiset/48101_neg.cc: Remove "here" error.
* testsuite/23_containers/set/48101_neg.cc: Likewise.
* testsuite/23_containers/unordered_map/48101_neg.cc: Likewise.
* testsuite/23_containers/unordered_multimap/48101_neg.cc: Likewise.
* testsuite/23_containers/unordered_multiset/48101_neg.cc: Likewise.
* testsuite/23_containers/unordered_set/48101_neg.cc: Likewise.

Added:
trunk/libstdc++-v3/testsuite/23_containers/set/85965.cc
  - copied, changed from r269947,
trunk/libstdc++-v3/testsuite/23_containers/map/48101_neg.cc
trunk/libstdc++-v3/testsuite/23_containers/unordered_set/85965.cc
  - copied, changed from r269947,
trunk/libstdc++-v3/testsuite/23_containers/map/48101_neg.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/hashtable.h
trunk/libstdc++-v3/include/bits/stl_tree.h
trunk/libstdc++-v3/testsuite/23_containers/map/48101_neg.cc
trunk/libstdc++-v3/testsuite/23_containers/multimap/48101_neg.cc
trunk/libstdc++-v3/testsuite/23_containers/multiset/48101_neg.cc
trunk/libstdc++-v3/testsuite/23_containers/set/48101_neg.cc
trunk/libstdc++-v3/testsuite/23_containers/unordered_map/48101_neg.cc
trunk/libstdc++-v3/testsuite/23_containers/unordered_multimap/48101_neg.cc
trunk/libstdc++-v3/testsuite/23_containers/unordered_multiset/48101_neg.cc
trunk/libstdc++-v3/testsuite/23_containers/unordered_set/48101_neg.cc

[Bug libstdc++/48101] obscure error message with std::set

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  ---
Author: redi
Date: Tue Mar 26 15:28:48 2019
New Revision: 269949

URL: https://gcc.gnu.org/viewcvs?rev=269949&root=gcc&view=rev
Log:
PR libstdc++/85965 delay static assertions until types are complete

The static assertions added for PR libstdc++/48101 were at class scope
and so were evaluated too eagerly, when it might not be possible to
determine whether the function objects are invocable with the key types.
The problematic cases are where the key type is not known to be
convertible to the argument type(s) of the function object until later,
after a type has been completed. Specifically, if the key type is a
pointer to a derived class and the function object's argument type is a
pointer to a base class, then the derived-to-base conversion is only
valid once the derived type is complete.

By moving the static assertions to the destructor they will only be
evaluated when the destructor is instantiated, at which point whether
the key type can be passed to the function object should be knowable.
The ideal place to do the checks would be only when the function objects
are actually invoked, but that would mean adding the checks in numerous
places, so the destructor is used instead.

The tests need to be adjusted because the "required from here" line is
now the location of the destructor, not the point of instantiation in
the test file. For the map and multimap tests which check two
specializations, the dg-error matching the assertion text matches both
cases. Also check the diagnostic output for the template arguments, to
ensure both specializations trigger the assertion.

PR libstdc++/85965
* include/bits/hashtable.h (_Hashtable): Move static assertions to
destructor so they are not evaluated until the _Key type is complete.
* include/bits/stl_tree.h (_Rb_tree): Likewise.
* testsuite/23_containers/set/85965.cc: New test.
* testsuite/23_containers/unordered_set/85965.cc: New test.
* testsuite/23_containers/map/48101_neg.cc: Replace "here" errors
with regexp matching the corresponding _Rb_tree specialization.
* testsuite/23_containers/multimap/48101_neg.cc: Likewise.
* testsuite/23_containers/multiset/48101_neg.cc: Remove "here" error.
* testsuite/23_containers/set/48101_neg.cc: Likewise.
* testsuite/23_containers/unordered_map/48101_neg.cc: Likewise.
* testsuite/23_containers/unordered_multimap/48101_neg.cc: Likewise.
* testsuite/23_containers/unordered_multiset/48101_neg.cc: Likewise.
* testsuite/23_containers/unordered_set/48101_neg.cc: Likewise.

Added:
trunk/libstdc++-v3/testsuite/23_containers/set/85965.cc
  - copied, changed from r269947,
trunk/libstdc++-v3/testsuite/23_containers/map/48101_neg.cc
trunk/libstdc++-v3/testsuite/23_containers/unordered_set/85965.cc
  - copied, changed from r269947,
trunk/libstdc++-v3/testsuite/23_containers/map/48101_neg.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/hashtable.h
trunk/libstdc++-v3/include/bits/stl_tree.h
trunk/libstdc++-v3/testsuite/23_containers/map/48101_neg.cc
trunk/libstdc++-v3/testsuite/23_containers/multimap/48101_neg.cc
trunk/libstdc++-v3/testsuite/23_containers/multiset/48101_neg.cc
trunk/libstdc++-v3/testsuite/23_containers/set/48101_neg.cc
trunk/libstdc++-v3/testsuite/23_containers/unordered_map/48101_neg.cc
trunk/libstdc++-v3/testsuite/23_containers/unordered_multimap/48101_neg.cc
trunk/libstdc++-v3/testsuite/23_containers/unordered_multiset/48101_neg.cc
trunk/libstdc++-v3/testsuite/23_containers/unordered_set/48101_neg.cc

[Bug fortran/89830] New: intrinsic repeat() is completely broken

[zbeekman at gmail dot com]

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

Bug ID: 89830
   Summary: intrinsic repeat() is completely broken
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zbeekman at gmail dot com
  Target Milestone: ---

Created attachment 46026
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46026&action=edit
Broken repeat example

The non-elemental intrinsic string function REPEAT() is completely broken. With
GFortran 8.3.0 installed via macOS Homebrew the following program fails to
compile:

```Fortran
program repeat
  implicit none
  write(*,*) repeat('a',5)
end program
```

It was compiled with:

```
gfortran -o repeat repeat_deterministic.f90
```

and produces the following error message:

```
repeat_deterministic.f90:3:19:

   write(*,*) repeat('a',5)
   1
Error: Symbol at (1) is not appropriate for an expression
```

Furthermore, there is an error message embedded in the `REPEAT()` function
which breaks deterministic builds! It is unclear to me why the following
example compiles while the one above does not:

```Fortran
  subroutine co_broadcast_c_char(a,source_image,stat,errmsg)
character(kind=c_char,len=*), intent(inout), volatile, target :: a
integer(c_int), intent(in), optional :: source_image
integer(c_int), intent(out), optional:: stat
character(kind=1,len=*), intent(out), optional :: errmsg
! Local variables and constants:
integer(c_int), allocatable :: a_cast_to_integer_array(:)

! Convert "a" to an integer(c_int) array where each 32-bit integer element
holds four 1-byte characters
a_cast_to_integer_array = transfer(a,[0_c_int])
! Broadcast the integer(c_int) array
call co_broadcast_c_int(a_cast_to_integer_array,source_image, stat, errmsg)
! Recover the characters from the broadcasted integer(c_int) array
a = transfer(a_cast_to_integer_array,repeat(' ',len(a)))

  end subroutine
```

(This example is from OpenCoarrays 2.6.1, or you can find it at
https://github.com/sourceryinstitute/OpenCoarrays/blob/8ceb2ce8912f4f0d5317a6cce248d042b3942280/src/extensions/opencoarrays.F90#L590)

When compiled, even with the `-fno-working-directory` flag, the object file
still contains references to the full path to the source file:

```
$ strings
src/mpi/CMakeFiles/opencoarrays_mod.dir/__/extensions/opencoarrays.F90.o

Argument NCOPIES of REPEAT intrinsic is negative (its value is %ld)
At line 590 of file
/Users/ibeekman/Sandbox/OpenCoarrays/src/extensions/opencoarrays.F90
```

[Bug c++/86429] [8/9 Regression] lambda capture breaks constexpr-ness

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  ---
Author: jason
Date: Tue Mar 26 16:02:19 2019
New Revision: 269951

URL: https://gcc.gnu.org/viewcvs?rev=269951&root=gcc&view=rev
Log:
PR c++/86429 - constexpr variable in lambda.

When we refer to a captured variable from a constant-expression context
inside a lambda, the closure (like any function parameter) is not constant
because we aren't in a call, so we don't have an argument.  So the capture
is non-constant.  But if the captured variable is constant, we might be able
to use it directly in constexpr evaluation.

PR c++/82643
PR c++/87327
* constexpr.c (cxx_eval_constant_expression): In a lambda function,
try evaluating the captured variable directly.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-const10.C
trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-const9.C
trunk/gcc/testsuite/g++.dg/cpp1z/constexpr-lambda24.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c

[Bug c++/82643] lambda capture breaks constexpr-ness of non-static const constexpr member call on non-constexpr value/variable

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Tue Mar 26 16:02:19 2019
New Revision: 269951

URL: https://gcc.gnu.org/viewcvs?rev=269951&root=gcc&view=rev
Log:
PR c++/86429 - constexpr variable in lambda.

When we refer to a captured variable from a constant-expression context
inside a lambda, the closure (like any function parameter) is not constant
because we aren't in a call, so we don't have an argument.  So the capture
is non-constant.  But if the captured variable is constant, we might be able
to use it directly in constexpr evaluation.

PR c++/82643
PR c++/87327
* constexpr.c (cxx_eval_constant_expression): In a lambda function,
try evaluating the captured variable directly.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-const10.C
trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-const9.C
trunk/gcc/testsuite/g++.dg/cpp1z/constexpr-lambda24.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c

[Bug c++/87327] [8/9 Regression] Calling member functions on captured constexpr variables "is not a constant expression"

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Tue Mar 26 16:02:19 2019
New Revision: 269951

URL: https://gcc.gnu.org/viewcvs?rev=269951&root=gcc&view=rev
Log:
PR c++/86429 - constexpr variable in lambda.

When we refer to a captured variable from a constant-expression context
inside a lambda, the closure (like any function parameter) is not constant
because we aren't in a call, so we don't have an argument.  So the capture
is non-constant.  But if the captured variable is constant, we might be able
to use it directly in constexpr evaluation.

PR c++/82643
PR c++/87327
* constexpr.c (cxx_eval_constant_expression): In a lambda function,
try evaluating the captured variable directly.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-const10.C
trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-const9.C
trunk/gcc/testsuite/g++.dg/cpp1z/constexpr-lambda24.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c

[Bug c++/86429] [8 Regression] lambda capture breaks constexpr-ness

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

Summary|[8/9 Regression] lambda |[8 Regression] lambda
   |capture breaks  |capture breaks
   |constexpr-ness  |constexpr-ness

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

[Bug c++/87327] [8 Regression] Calling member functions on captured constexpr variables "is not a constant expression"

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

Summary|[8/9 Regression] Calling|[8 Regression] Calling
   |member functions on |member functions on
   |captured constexpr  |captured constexpr
   |variables "is not a |variables "is not a
   |constant expression"|constant expression"

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

[Bug c++/82643] lambda capture breaks constexpr-ness of non-static const constexpr member call on non-constexpr value/variable

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |9.0

--- Comment #6 from Jason Merrill  ---
Fixed for GCC 9.

[Bug c++/54367] [meta-bug] lambda expressions

[jason at gcc dot gnu.org]

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

Bug 82643 Summary: lambda capture breaks constexpr-ness of non-static const 
constexpr member call on non-constexpr value/variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82643

   What|Removed |Added

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

[Bug c++/86932] [8/9 Regression] Empty non-type template parameter pack not considered for SFINAE.

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug target/38177] Internal compiler error during gcc build with -march=amdfam10

[belyshev at depni dot sinp.msu.ru]

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

Serge Belyshev  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||belyshev at depni dot 
sinp.msu.ru
  Known to work||
 Resolution|--- |WORKSFORME

--- Comment #8 from Serge Belyshev  ---
This report is bitrotten by now, 4.3 is no longer maintained.

[Bug c++/89831] New: passing 'const ...' as 'this' argument discards qualifiers

[lumosimann at gmail dot com]

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

Bug ID: 89831
   Summary: passing 'const ...' as 'this' argument discards
qualifiers
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lumosimann at gmail dot com
  Target Milestone: ---

Starting from GCC 8.1, the following code does not compile anymore:

```
struct Q { 
int operator[](int i) { return 0; }
int operator[](int i) const { return 0; }
};

struct Base {
Q x;
};
struct X : public Base {
template 
void f(T) const {
auto q = Base::x[0];
}   
};
int main() { X{}.f(3); }
```

https://godbolt.org/z/UefNCx

- using `operator()` instead of `operator[]` fixes the problem
- using `x[0]` instead of `Base::x[0]` fixes the problem
- removing the template from `X::f` fixes the problem


In older versions and with clang, compilation is okay.

[Bug tree-optimization/89499] [7/8/9 Regression] ICE in expand_UNIQUE, at internal-fn.c:2605

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-26
 CC||cesar at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
With __attribute__((always_inline)) static inline at the start of 2nd line
this ICEs even with -O0, it is clearly related to inlining.

Thomas, can you or somebody else from the OpenACC folks have a look?

Either the .UNIQUE calls are uninlinable, then they should be marked that way,
or they need some adjustments during inlining, and again, the inliner would
need to do that.

The testcase ICEs without any offloading configured, dunno if it is specific to
fallback only or not.

[Bug fortran/89830] intrinsic repeat() is completely broken

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to Zaak from comment #0)
> Created attachment 46026 [details]
> Broken repeat example
> 
> The non-elemental intrinsic string function REPEAT() is completely broken.
> With GFortran 8.3.0 installed via macOS Homebrew the following program fails
> to compile:
> 
> ```Fortran
> program repeat
>   implicit none
>   write(*,*) repeat('a',5)
> end program
> ```
> 
> It was compiled with:
> 
> ```
> gfortran -o repeat repeat_deterministic.f90
> ```
> 
> and produces the following error message:
> 
> ```
> repeat_deterministic.f90:3:19:
> 
>write(*,*) repeat('a',5)
>1
> Error: Symbol at (1) is not appropriate for an expression
> ```

Yes, it should produce an error.
 program repeat
 ^^
The above symbol

>   implicit none
>   write(*,*) repeat('a',5)
   ^^
conflicts with this symbol

> end program

[Bug target/30810] top-level BOOT_CFLAGS not being used for bootstrapping

[belyshev at depni dot sinp.msu.ru]

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

Serge Belyshev  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||belyshev at depni dot 
sinp.msu.ru
 Resolution|--- |WORKSFORME

--- Comment #8 from Serge Belyshev  ---
Works as documented in https://gcc.gnu.org/install/build.html .  Although
documentation could be improved and various *FLAGS should be consolidated.

[Bug fortran/89830] intrinsic repeat() is completely broken

[kargl at gcc dot gnu.org]

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

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to Zaak from comment #0)


> When compiled, even with the `-fno-working-directory` flag, the object file
> still contains references to the full path to the source file:
> 
> ```
> $ strings
> src/mpi/CMakeFiles/opencoarrays_mod.dir/__/extensions/opencoarrays.F90.o
> 
> Argument NCOPIES of REPEAT intrinsic is negative (its value is %ld)
> At line 590 of file
> /Users/ibeekman/Sandbox/OpenCoarrays/src/extensions/opencoarrays.F90

Not sure about the above.

I doubt -fno-working-directory works with gfortran, and I doubt
if anyone can or has the time to fix it.  Do note that this option
is pre-processor option.  gfortran runs the processor in traditional
mode, so the option may be a nop.

[Bug c++/89831] [8/9 Regression] passing 'const ...' as 'this' argument discards qualifiers

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-26
 CC||jakub at gcc dot gnu.org,
   ||nathan at gcc dot gnu.org
   Target Milestone|--- |8.4
Summary|passing 'const ...' as  |[8/9 Regression] passing
   |'this' argument discards|'const ...' as 'this'
   |qualifiers  |argument discards
   ||qualifiers
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r255605.

[Bug sanitizer/89832] New: confusing error message when there is a problem with ASAN_OPTIONS "ERROR: expected '='"

[diane2332 at gmail dot com]

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

Bug ID: 89832
   Summary: confusing error message when there is a problem with
ASAN_OPTIONS "ERROR: expected '='"
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: diane2332 at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

When using AddressSanitizer on a very large software system involving multiple
binaries, libraries, etc., it is very difficult to know where an error message
is coming from when all I get is:

ERROR: expected '='

I eventually traced this to libasan.so.

It would have been so much easier if perhaps the message was:

AddressSanitizer: ERROR: expected '=' in ASAN_OPTIONS

Example follows.

hello.c:
#include 
int main()
{
   printf("Hello world\n");
   return 0;
}

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

gcc -g -fsanitize=address hello.c
./a.out
Hello world
setenv ASAN_OPTIONS bad_stuff
./a.out
ERROR: expected '='

[Bug c++/89785] Incorrect "not a constant expression" error with switch statement that returns

[jason at gcc dot gnu.org]

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

--- Comment #8 from Jason Merrill  ---
(In reply to Jakub Jelinek from comment #6)
> Another option, slightly more involved, is say cp_walk_tree on
> SWITCH_STMT_BODY, looking for any RETURN_EXPRs or CONTINUE_STMTs (the latter
> only when not nested inside of a FOR_STMT, DO_STMT, WHILE_STMT and
> RANGE_FOR_STMT) and if we find a RETURN_EXPR, set jump_target to that, if we
> don't, but find a CONTINUE_STMT not nested in further looping constructs,
> set *jump_target to that CONTINUE_STMT, otherwise keep it unchanged.  To me
> this looks like the best approach for now.

I agree.

[Bug fortran/89830] intrinsic repeat() is completely broken

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #3 from Thomas Koenig  ---
(In reply to Zaak from comment #0)

> Furthermore, there is an error message embedded in the `REPEAT()` function

I doubt that. REPEAT() is an intrinsic, there are no embedded
error messages in there.

> which breaks deterministic builds! It is unclear to me why the following
> example compiles while the one above does not:
> 
> ```Fortran
>   subroutine co_broadcast_c_char(a,source_image,stat,errmsg)
> character(kind=c_char,len=*), intent(inout), volatile, target :: a
> integer(c_int), intent(in), optional :: source_image
> integer(c_int), intent(out), optional:: stat
> character(kind=1,len=*), intent(out), optional :: errmsg
> ! Local variables and constants:
> integer(c_int), allocatable :: a_cast_to_integer_array(:)
> 
> ! Convert "a" to an integer(c_int) array where each 32-bit integer
> element holds four 1-byte characters
> a_cast_to_integer_array = transfer(a,[0_c_int])
> ! Broadcast the integer(c_int) array
> call co_broadcast_c_int(a_cast_to_integer_array,source_image, stat,
> errmsg)
> ! Recover the characters from the broadcasted integer(c_int) array
> a = transfer(a_cast_to_integer_array,repeat(' ',len(a)))
> 
>   end subroutine
> ```

This does not compile.

Can you specify a complete, self-contained example?

[Bug c++/89833] New: [9 Regression] sorry, unimplemented: string literal in function template signature

[redi at gcc dot gnu.org]

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

Bug ID: 89833
   Summary: [9 Regression] sorry, unimplemented: string literal in
function template signature
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: FIXME, rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
CC: msebor at gcc dot gnu.org
  Target Milestone: ---

When compiled with -std=c++2a this started to fail with r269814:

using size_t = decltype(sizeof(0));
template struct array { T data[N]; };
template struct index_sequence { };
template struct make_index_sequence;
template<> struct make_index_sequence<6> : index_sequence<0, 1, 2, 3, 4, 5> {
};

template 
struct mystring : array {
template 
constexpr mystring(const char (&str)[N], index_sequence)
: array{str[Idx]...} {}

constexpr mystring(const char (&str)[N]) : mystring(str,
make_index_sequence{}) {}
};

template 
mystring(const char (&str)[N]) -> mystring;

template 
struct S {};

S<"Hello"> s;


reg.cc: In instantiation of ‘struct S{array{"Hello"}}>’:
reg.cc:24:12:   required from here
reg.cc:22:10: sorry, unimplemented: string literal in function template
signature
   22 | struct S {};
  |  ^
reg.cc:22:10: sorry, unimplemented: string literal in function template
signature
reg.cc:22:10: sorry, unimplemented: string literal in function template
signature

[Bug fortran/89830] intrinsic repeat() is completely broken

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #4 from Steve Kargl  ---
On Tue, Mar 26, 2019 at 05:59:08PM +, tkoenig at gcc dot gnu.org wrote:
> 
> --- Comment #3 from Thomas Koenig  ---
> (In reply to Zaak from comment #0)
> 
> > Furthermore, there is an error message embedded in the `REPEAT()` function
> 
> I doubt that. REPEAT() is an intrinsic, there are no embedded
> error messages in there.
> 

There's error messages.

% cat tmp/a.F90
subroutine foo(s,n)
  implicit none
  character(len=1), intent(in) :: s
  integer, intent(in) :: n
  write(*,*) repeat(s,n)
end subroutine
% gfcx -c tmp/a.F90
% strings a.o | head -9
ATSH
[A\]
tmp/a.F90
Argument NCOPIES of REPEAT intrinsic is negative (its value is %ld)
At line 5 of file tmp/a.F90
Argument NCOPIES of REPEAT intrinsic is too large
GCC: (GNU) 9.0.1 20190325 (experimental)
a.F90

Zaak wants -fno-working-directory to strip the "tmp/" from
"At line 5 of file tmp/a.F90".  The option applies to pre-processing
and has no impact on gfortran's error mechanism.

[Bug c++/89833] [9 Regression] sorry, unimplemented: string literal in function template signature

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-26
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Right:
https://gcc.gnu.org/ml/gcc-patches/2019-03/msg01064.html

[Bug c++/89421] [9 Regression] ICE with lambda in template parameter list

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
(In reply to Marek Polacek from comment #4)
> Jason, should we also return NULL_TREE for lambdas inside template parameter
> list (in retrieve_specialization)?

That's not sufficient, even if it probably makes some sense.

(This likely should be P2 instead of P1, as it's previously invalid code.)

[Bug fortran/89830] intrinsic repeat() is completely broken

[zbeekman at gmail dot com]

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

--- Comment #5 from Zaak  ---
Sorry about the bad reproducer code (name conflict).

To create reproducible builds one must be able to strip or at least map source
file references from the source/build directory to something more generic or
universal.

For example, I usually create a build subdirectory of my source tree and
compile in there. Being able to omit directories in filenames is a critical
part of this.

In this particular example, I suppose that I can likely pass a relative path to
the compiler rather than the full path to the source file.

But, it would be nice if there were a mechanism to strip paths from
warning/error messages like this.

I have tried:

 -fno-working-directory
 -ffile-prefix-map=OLD=NEW
 -fdebug-prefix-map=OLD=NEW
 -fmacro-prefix-map=OLD=NEW

and the error message from `repeat()` stubbornly persists.

Also, given that my reproducer code was dumb, should we close this an open a
new issue to track the paths getting embedded? Or should this issue stay open
to discuss/resolve the paths? Personally I think it would be clearer if I
closed this as invalid and submitted a new issue demonstrating the path issue.

[Bug fortran/89821] Get a SIGFPE on a simple test of a kind=real128 variable with -ffpe-trap=invalid switch

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to Richard Biener from comment #1)
> The invalid exception is raised here:
> 
> Program received signal SIGFPE, Arithmetic exception.
> 0x00400cde in demo_nan () at t.f90:17
> 17 if ( (r32<=0.0_real32) .or. (r32>=0.0_real32) )then
> 
>0x00400cd2 <+416>:   movss  -0x134(%rbp),%xmm1
>0x00400cda <+424>:   pxor   %xmm0,%xmm0
> => 0x00400cde <+428>:   comiss %xmm1,%xmm0
> 
> where %xmm1 is NaN.
> 
> (gdb) p $xmm1
> $2 = ( v4_float = (nan(0x40), 0, 0, 0),
> 
> so not sure what you are expecting?  Is Fortran supposed to use the
> C equivalent of isgreaterequal (aka comparisons that do not raise
> exceptions?)

The Fortran standard says nothing about the option -ffpe-trap=invalid.
If one uses an option requesting a trap, then one might anticipate
that it cause a SIGFPE when an NaN is used in an expression.

This reduced testcase fails with 8-branch and trunk when compiled
with -ffpe-trap=invalid.

program demo_nan
   use,intrinsic :: iso_fortran_env, only: real32
   implicit none
   character(len=3),save :: STRING='NaN'
   real(kind=real32)  :: r32
   character(len=256) :: message
   integer:: ios
   read(STRING,*)r32
   ! an option to terminate a program when a NaN is encountered
   ! (if X is NaN the comparison with 0. is always false.)
   if ( (r32<=0.0_real32) .or. (r32>=0.0_real32) )then
  write(*,*)'did not produce a nan_real32'
   else
  write(*,*)'found a nan_real32. Handle it.'
   endif
   ! list directed format
   write(*,*,iomsg=message,iostat=ios)r32
   if(ios.ne.0)write(*,*)trim(message)
   ! hexadecimal format to show different kinds
   write(*,'(z0)',iomsg=message,iostat=ios)r32
end program demo_nan

The above compiles with both 6-branch and an old 7-branch
(need to update 7 to test).

There are two ways in which I can avoid the SIGFPE and
still use an NaN.  First, one can use the intrinsic
function isnan() to change the conditional to

   if (.not.isnan(r32))then
  write(*,*)'did not produce a nan_real32'
   else
  write(*,*)'found a nan_real32. Handle it.'
   endif

The second, and likely preferred method, is to use the IEEE_ARITHMETIC
module that is provided by the Fortran Standard.

[Bug fortran/89821] Get a SIGFPE on a simple test of a kind=real128 variable with -ffpe-trap=invalid switch

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug target/89827] [8/9 Regression] ICE: in convert_op, at config/i386/i386.c:2098 with -Os -maes

[uros at gcc dot gnu.org]

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

--- Comment #3 from uros at gcc dot gnu.org ---
Author: uros
Date: Tue Mar 26 18:59:14 2019
New Revision: 269953

URL: https://gcc.gnu.org/viewcvs?rev=269953&root=gcc&view=rev
Log:
PR target/89827
* config/i386/i386.c (dimode_scalar_chain::convert_reg):
Also process XEXP (src, 0) of a shift insn.

testsuite/ChangeLog:

PR target/89827
* gcc.target/i386/pr89827.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr89827.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug testsuite/89834] New: New test case gcc.dg/vect/pr81740-2.c introduced in r269938 fails on power 7

[seurer at gcc dot gnu.org]

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

Bug ID: 89834
   Summary: New test case gcc.dg/vect/pr81740-2.c introduced in
r269938 fails on power 7
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

This only fails on power 7 BE; it works find on power 8 BE.

On power 7 the compilation options include "-mvsx -mno-allow-movmisalign" while
on power 8 that is replaced with "-mpower8-vector".  So perhaps the expected
vectorization only occurs on power 8 and later?

Executing on host: /home/seurer/gcc/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test/gcc/
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/vect/pr81740-2.c   
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never   -maltivec -mvsx -mno-allow-movmisalign
-ftree-vectorize -fno-vect-cost-model -fno-common -O2 -fdump-tree-vect-details 
-lm  -o ./pr81740-2.exe(timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test/gcc/
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/vect/pr81740-2.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -maltivec -mvsx -mno-allow-movmisalign
-ftree-vectorize -fno-vect-cost-model -fno-common -O2 -fdump-tree-vect-details
-lm -o ./pr81740-2.exe
PASS: gcc.dg/vect/pr81740-2.c (test for excess errors)
Setting LD_LIBRARY_PATH to
:/home/seurer/gcc/build/gcc-test/gcc::/home/seurer/gcc/build/gcc-test/gcc:/home/seurer/gcc/build/gcc-test/./gmp/.libs:/home/seurer/gcc/build/gcc-test/./prev-gmp/.libs:/home/seurer/gcc/build/gcc-test/./mpfr/src/.libs:/home/seurer/gcc/build/gcc-test/./prev-mpfr/src/.libs:/home/seurer/gcc/build/gcc-test/./mpc/src/.libs:/home/seurer/gcc/build/gcc-test/./prev-mpc/src/.libs:/home/seurer/gcc/build/gcc-test/./isl/.libs:/home/seurer/gcc/build/gcc-test/./prev-isl/.libs
Execution timeout is: 300
spawn [open ...]
PASS: gcc.dg/vect/pr81740-2.c execution test
FAIL: gcc.dg/vect/pr81740-2.c scan-tree-dump vect "OUTER LOOP VECTORIZED"
Executing on host: /home/seurer/gcc/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test/gcc/
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/vect/pr81740-2.c   
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never  -flto -ffat-lto-objects -maltivec -mvsx
-mno-allow-movmisalign -ftree-vectorize -fno-vect-cost-model -fno-common -O2
-fdump-tree-vect-details  -lm  -o ./pr81740-2.exe(timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test/gcc/
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/vect/pr81740-2.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -flto -ffat-lto-objects -maltivec -mvsx
-mno-allow-movmisalign -ftree-vectorize -fno-vect-cost-model -fno-common -O2
-fdump-tree-vect-details -lm -o ./pr81740-2.exe
PASS: gcc.dg/vect/pr81740-2.c -flto -ffat-lto-objects (test for excess errors)
Setting LD_LIBRARY_PATH to
:/home/seurer/gcc/build/gcc-test/gcc::/home/seurer/gcc/build/gcc-test/gcc:/home/seurer/gcc/build/gcc-test/./gmp/.libs:/home/seurer/gcc/build/gcc-test/./prev-gmp/.libs:/home/seurer/gcc/build/gcc-test/./mpfr/src/.libs:/home/seurer/gcc/build/gcc-test/./prev-mpfr/src/.libs:/home/seurer/gcc/build/gcc-test/./mpc/src/.libs:/home/seurer/gcc/build/gcc-test/./prev-mpc/src/.libs:/home/seurer/gcc/build/gcc-test/./isl/.libs:/home/seurer/gcc/build/gcc-test/./prev-isl/.libs
Execution timeout is: 300
spawn [open ...]
PASS: gcc.dg/vect/pr81740-2.c -flto -ffat-lto-objects execution test
FAIL: gcc.dg/vect/pr81740-2.c -flto -ffat-lto-objects  scan-tree-dump vect
"OUTER LOOP VECTORIZED"
testcase /home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/vect/vect.exp completed
in 3 seconds

=== gcc Summary ===

# of expected passes4
# of unexpected failures2

[Bug bootstrap/89829] incorrect profile data is used during profiledbootstrap

[belyshev at depni dot sinp.msu.ru]

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

--- Comment #2 from Serge Belyshev  ---
On the other hand, benchmarking shows that better training brings no advantage.
Or rather, slight measurable regression is apparent:

option|  training  dataset| benchmark | compiler binary
  |   |  time, s  |size, MB
---
bootstrap |  N/A  |   11.203  |  32.2
profiledbootstrap |  none |   11.518  |  38.0
profiledbootstrap |  libgcc   |   10.091  |  30.1
profiledbootstrap |  stagetrain   |   10.130  |  30.8
profiledbootstrap |  libgcc+stagetrain|   10.116  |  30.9
profiledbootstrap |  as above + combined tree |   10.128  |  30.9


Thus, some tuning is needed, I guess.

Notes: BOOT_CFLAGS=-Ofast was used for the above.  Benchmark is cc1files from
gcc 3.4, compiled by compiler under test with -Ofast.  Time values are averages
of 100 runs, standard error of mean is about 0.001 s, sample standard deviaton
is 0.011 s.