[Bug target/89784] Missing AVX512 intrinsics

[crazylht at gmail dot com]

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

--- Comment #3 from Hongtao.liu  ---
and 

VFMADDxxxSS __m128 _mm_mask_fmadd_ss(__m128 a, __mmask8 k, __m128 b, __m128 c);
VFMADDxxxSS __m128 _mm_maskz_fmadd_ss(__mmask8 k, __m128 a, __m128 b, __m128
c);
VFMADDxxxSS __m128 _mm_mask3_fmadd_ss(__m128 a, __m128 b, __m128 c, __mmask8
k);
VFMADDxxxSS __m128 _mm_mask_fmadd_round_ss(__m128 a, __mmask8 k, __m128 b,
__m128 c, int r);
VFMADDxxxSS __m128 _mm_maskz_fmadd_round_ss(__mmask8 k, __m128 a, __m128 b,
__m128 c, int r);
VFMADDxxxSS __m128 _mm_mask3_fmadd_round_ss(__m128 a, __m128 b, __m128 c,
__mmask8 k, int r);
VFNMADDxxxSS __m128 _mm_mask_fnmadd_ss(__m128 a, __mmask8 k, __m128 b, __m128
c);
VFNMADDxxxSS __m128 _mm_maskz_fnmadd_ss(__mmask8 k, __m128 a, __m128 b, __m128
c);
VFNMADDxxxSS __m128 _mm_mask3_fnmadd_ss(__m128 a, __m128 b, __m128 c, __mmask8
k);
VFNMADDxxxSS __m128 _mm_mask_fnmadd_round_ss(__m128 a, __mmask8 k, __m128 b,
__m128 c, int r);
VFNMADDxxxSS __m128 _mm_maskz_fnmadd_round_ss(__mmask8 k, __m128 a, __m128 b,
__m128 c, int r);
VFNMADDxxxSS __m128 _mm_mask3_fnmadd_round_ss(__m128 a, __m128 b, __m128 c,
__mmask8 k, int r);
VFNMADDxxxSD __m128d _mm_mask_fnmadd_sd(__m128d a, __mmask8 k, __m128d b,
__m128d c);
VFNMADDxxxSD __m128d _mm_maskz_fnmadd_sd(__mmask8 k, __m128d a, __m128d b,
__m128d c);
VFNMADDxxxSD __m128d _mm_mask3_fnmadd_sd(__m128d a, __m128d b, __m128d c,
__mmask8 k);
VFNMADDxxxSD __m128d _mm_mask_fnmadd_round_sd(__m128d a, __mmask8 k, __m128d b,
__m128d c, int r);
VFNMADDxxxSD __m128d _mm_maskz_fnmadd_round_sd(__mmask8 k, __m128d a, __m128d
b, __m128d c, int r);
VFNMADDxxxSD __m128d _mm_mask3_fnmadd_round_sd(__m128d a, __m128d b, __m128d c,
__mmask8 k, int r);
VFMADDxxxSD __m128d _mm_mask_fmadd_sd(__m128d a, __mmask8 k, __m128d b, __m128d
c);
VFMADDxxxSD __m128d _mm_maskz_fmadd_sd(__mmask8 k, __m128d a, __m128d b,
__m128d c);
VFMADDxxxSD __m128d _mm_mask3_fmadd_sd(__m128d a, __m128d b, __m128d c,
__mmask8 k);
VFMADDxxxSD __m128d _mm_mask_fmadd_round_sd(__m128d a, __mmask8 k, __m128d b,
__m128d c, int r);
VFMADDxxxSD __m128d _mm_maskz_fmadd_round_sd(__mmask8 k, __m128d a, __m128d b,
__m128d c, int r);
VFMADDxxxSD __m128d _mm_mask3_fmadd_round_sd(__m128d a, __m128d b, __m128d c,
__mmask8 k, int r);

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

[antoshkka at gmail dot com]

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

Bug ID: 89785
   Summary: Incorrect "not a constant expression" error with
switch statement that returns
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antoshkka at gmail dot com
  Target Milestone: ---

The following code fails to compile:

constexpr int Addrlen(int domain) {
switch (domain) {
  case 0:
return 0;
  case 2:
return 42;
}
throw 42;
}

Error message is following:

: In function 'constexpr int Addrlen(int)':
:8:11: error: expression '' is not a constant
expression
8 | throw 42;
  |   ^~

[Bug fortran/89783] Can do an internal READ of a character array when it is a parameter, but not a scalar character parameter

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
Duplicate.

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

[Bug fortran/89782] Can do an internal READ of a character array when it is a parameter, but not a scalar character parameter

[dominiq at lps dot ens.fr]

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

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

[Bug fortran/89782] Can do an internal READ of a character array when it is a parameter, but not a scalar character parameter

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #2 from Dominique d'Humieres  ---
Confirmed from at least 4.3.1 up to trunk (9.0).

[Bug rtl-optimization/85412] [8/9 Regression] ICE in put_TImodes, at sel-sched.c:7191

[abel at gcc dot gnu.org]

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

--- Comment #8 from Andrey Belevantsev  ---
Sigh.  We set reset_sched_cycles_p to pipelining_p after the conditional, but
we have missed that in sel_sched_region_1 pipelining_p will be set to false. 
So that initial patch should have the following hunk instead:

diff --git a/gcc/sel-sched.c b/gcc/sel-sched.c
index 315f2c0c0ab..29d9abd7200 100644
--- a/gcc/sel-sched.c
+++ b/gcc/sel-sched.c
@@ -7648,11 +7648,11 @@ sel_sched_region (int rgn)
   /* Schedule always selecting the next insn to make the correct data
 for bundling or other later passes.  */
   pipelining_p = false;
+  reset_sched_cycles_p = false;
   force_next_insn = 1;
   sel_sched_region_1 ();
   force_next_insn = 0;
 }
-  reset_sched_cycles_p = pipelining_p;
   sel_region_finish (reset_sched_cycles_p);
 }

I've checked that it fixes the ICE on the original revision, trunk doesn't ICE
for me.

[Bug rtl-optimization/85876] ICE in move_op_ascend, at sel-sched.c:6164

[abel at gcc dot gnu.org]

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

Andrey Belevantsev  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-03-21
 CC||abel at gcc dot gnu.org,
   ||amonakov at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |abel at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug rtl-optimization/85876] ICE in move_op_ascend, at sel-sched.c:6164

[abel at gcc dot gnu.org]

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

--- Comment #1 from Andrey Belevantsev  ---
This is caused by the overeager fix of PR 48235.  We're unwinding the
first_insn variable (the border to which we step backwards in code motion) too
far so it gets beyond the original fence, which happens to be mid-block instead
of bb head.  Fixed as below.  Alexander, do you remember anything else about
that PR (e.g. I think there was a code to unwind the fence back to account for
the unscheduled instructions, but this is not it).

diff --git a/gcc/sel-sched.c b/gcc/sel-sched.c
index 315f2c0c0ab..6116e43f998 100644
--- a/gcc/sel-sched.c
+++ b/gcc/sel-sched.c
@@ -6437,7 +6437,7 @@ code_motion_path_driver (insn_t insn, av_set_t orig_ops,
ilist_t path,
 {
   expr_t expr = NULL;
   basic_block bb = BLOCK_FOR_INSN (insn);
-  insn_t first_insn, bb_tail, before_first;
+  insn_t first_insn, original_insn, bb_tail, before_first;
   bool removed_last_insn = false;

   if (sched_verbose >= 6)
@@ -6521,7 +6521,7 @@ code_motion_path_driver (insn_t insn, av_set_t orig_ops,
ilist_t path,
   /* It is enough to place only heads and tails of visited basic blocks into
  the PATH.  */
   ilist_add (&path, insn);
-  first_insn = insn;
+  first_insn = original_insn = insn;
   bb_tail = sel_bb_end (bb);

   /* Descend the basic block in search of the original expr; this part
@@ -6628,6 +6628,8 @@ code_motion_path_driver (insn_t insn, av_set_t orig_ops,
ilist_t path,
 {
   insn = sel_bb_end (bb);
   first_insn = sel_bb_head (bb);
+ if (first_insn != original_insn)
+   first_insn = original_insn;
 }

   /* Remove bb tail from path.  */

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

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
So you say that Addrlen(0) and Addrlen(2) are proper constexprs?  Of course
Addrlen(1) is not.

[Bug middle-end/89779] [9 Regression] internal compiler error: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in tree_nop_conversion_p, at tree.c:12798

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
Mine.

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

[antoshkka at gmail dot com]

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

--- Comment #2 from Antony Polukhin  ---
> So you say that Addrlen(0) and Addrlen(2) are proper constexprs?  Of course
Addrlen(1) is not.

Yes. But GCC does not even allow to define the Addrlen function:
https://godbolt.org/z/xqR2Lr

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org,
   ||redi at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
I guess that is because potential_constant_expression_1 punts on THROW_EXPR. 
There is some code to not recurse if e.g. IF_STMT or COND_EXPR condition
evaluates to constant zero or nonzero, but that is not the case here.
I actually don't know what in the standard requires something like
potential_constant_expression{,_1} rather than just punting during constexpr
evaluation if some non-constexpr construct is encountered.  For the cases
listed in dcl.constexpr which may not show up in constexpr functions I thought
that is covered in the parser already.

[Bug middle-end/89779] [9 Regression] internal compiler error: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in tree_nop_conversion_p, at tree.c:12798

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Blocks||88945

--- Comment #4 from Richard Biener  ---
So we fail to run into the defensive

static inline bool
tree_nop_conversion (const_tree exp)
{
...
  inner_type = TREE_TYPE (TREE_OPERAND (exp, 0));

  if (!inner_type)
return false;

now because the type is not NULL but error_mark_node.  Of course the real
issue is that we are operating on trees with released SSA names at all.

The above is from r158045

2010-04-07  Richard Guenther  

PR middle-end/42617
* emit-rtl.c (set_mem_attributes_minus_bitpos): Do not
discard plain indirect references.
* fold-const.c (operand_equal_p): Guard against NULL_TREE type.
* tree.c (tree_nop_conversion): Likewise.

where the tree_nop_conversion already has other defenses:

  if (TREE_OPERAND (exp, 0) == error_mark_node)
return false;

we can consolidate those checks now.

Index: gcc/tree.c
===
--- gcc/tree.c  (revision 269832)
+++ gcc/tree.c  (working copy)
@@ -12812,13 +12812,10 @@ tree_nop_conversion (const_tree exp)
   if (!CONVERT_EXPR_P (exp)
   && TREE_CODE (exp) != NON_LVALUE_EXPR)
 return false;
-  if (TREE_OPERAND (exp, 0) == error_mark_node)
-return false;

   outer_type = TREE_TYPE (exp);
   inner_type = TREE_TYPE (TREE_OPERAND (exp, 0));
-
-  if (!inner_type)
+  if (inner_type == error_mark_node)
 return false;

   return tree_nop_conversion_p (outer_type, inner_type);
Index: gcc/fold-const.c
===
--- gcc/fold-const.c(revision 269832)
+++ gcc/fold-const.c(working copy)
@@ -2973,11 +2973,6 @@ operand_equal_p (const_tree arg0, const_
   || TREE_TYPE (arg1) == error_mark_node)
 return 0;

-  /* Similar, if either does not have a type (like a released SSA name), 
- they aren't equal.  */
-  if (!TREE_TYPE (arg0) || !TREE_TYPE (arg1))
-return 0;
-
   /* We cannot consider pointers to different address space equal.  */
   if (POINTER_TYPE_P (TREE_TYPE (arg0))
   && POINTER_TYPE_P (TREE_TYPE (arg1))


The underlying issue is that IVOPTs removes unused IVs but keeps
loop->control_ivs uncleared (it clears the SCEV cache which also
resets loop->nb_iterations).  The best fix for IVOPTs is probably
to simply delay removal of those IVs and also properly free
control-iv information.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88945
[Bug 88945] ICE in fold_convert_loc in FRE when using -fdump-tree-fre-details

[Bug fortran/54262] LOC shouldn't use copy-in/copy-out

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
> The code in comment 0 compiles with 4.8.5, but gives an error
>
>p = transfer (loc(x), p)
> 1
> Error: Assumed-type argument at (1) is not permitted as actual argument
> to the intrinsic loc

LOC is a GNU extension and it is a matter of choice to accept or reject it in
gfortran.

If the choice is to reject it, then this PR should be closed as INVALID.

With the following patch

--- ../_clean/gcc/fortran/intrinsic.c   2019-03-12 16:12:35.0 +0100
+++ gcc/fortran/intrinsic.c 2019-03-20 23:03:17.0 +0100
@@ -212,7 +212,8 @@ do_ts29113_check (gfc_intrinsic_sym *spe
   && specific->id != GFC_ISYM_SIZEOF
   && specific->id != GFC_ISYM_UBOUND
   && specific->id != GFC_ISYM_IS_CONTIGUOUS
-  && specific->id != GFC_ISYM_C_LOC)
+  && specific->id != GFC_ISYM_C_LOC
+  && specific->id != GFC_ISYM_LOC)
{
  gfc_error ("Assumed-type argument at %L is not permitted as actual"
 " argument to the intrinsic %s", &a->expr->where,

the modified test with

  type(*), target, CONTIGUOUS :: x(:) ! or x(:)

is accepted, but the original test is rejected with

5 |   p = transfer (loc(x), p)
  |1
Error: Assumed-rank argument at (1) is only permitted as actual argument to
intrinsic inquiry functions

So far I did not find what to change to make specific->inquiry true for LOC. 
Again as it is an extension, it is not an "intrinsic inquiry function" 
as defined by the standard.

While looking at trans-intrinsic.c, I see in gfc_conv_intrinsic_loc

  /* Create a temporary variable for loc return value.  Without this,
 we get an error an ICE in gcc/expr.c(expand_expr_addr_expr_1).  */
  temp_var = gfc_create_var (gfc_get_int_type (gfc_index_integer_kind), NULL);
  gfc_add_modify (&se->pre, temp_var, se->expr);
  se->expr = temp_var;

and in conv_isocbinding_function

  /* TODO -- the following two lines shouldn't be necessary, but if
 they're removed, a bug is exposed later in the code path.
 This workaround was thus introduced, but will have to be
 removed; please see PR 35150 for details about the issue.  */
  se->expr = convert (pvoid_type_node, se->expr);
  se->expr = gfc_evaluate_now (se->expr, &se->pre);

These pieces of code look more as empirical hacks than as solid codes.

[Bug fortran/48419] Reduce gfortran stack usage for procedures doing IO

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #5 from Dominique d'Humieres  ---
Almost eight years later, is there any chance to fix this PR?

[Bug c++/89766] [8 Regression] ICE: canonical types differ for identical types, -std=c++17

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
(In reply to Rimvydas (RJ) from comment #10)
> Using 9.0.1 20190319 as reference several ICE cases reduce down to the same
> snippet (regression on trunk)?

None of these ICE on the trunk, there is a warning on the first one:
warning: inline function ‘constexpr a::a()’ used but never defined

What do you think the compiler does incorrectly?  E.g. for the first testcase
I guess it would be rejected if it is actually instantiated, but when not
instantiated, I'd think it falls into the invalid, no diagnostic required
category.

[Bug target/89784] Missing AVX512 intrinsics

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

[Bug debug/86549] [meta-bug] -flto -g0 vs. -g issues

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||meta-bug
   Priority|P2  |P3
 Status|ASSIGNED|NEW
 CC||rguenth at gcc dot gnu.org
   Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot 
gnu.org
   Target Milestone|8.4 |---
Summary|[8/9 Regression] -flto -g0  |[meta-bug] -flto -g0 vs. -g
   |vs. -g issues   |issues

--- Comment #4 from Richard Biener  ---
Making a meta-bug, all known issues are fixed.

[Bug c++/78645] [7/8/9 Regression] ICE on invalid code (Segmentation fault, cxx_eval_call_expression)

[paolo.carlini at oracle dot com]

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

--- Comment #6 from Paolo Carlini  ---
This is fixed in trunk. I'm adding a testcase and removing the regression
marker.

[Bug c++/78645] [7/8/9 Regression] ICE on invalid code (Segmentation fault, cxx_eval_call_expression)

[paolo at gcc dot gnu.org]

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

--- Comment #7 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Thu Mar 21 12:05:32 2019
New Revision: 269834

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

PR c++/78645
* g++.dg/cpp0x/constexpr-ice20.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-ice20.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/88066] [7 Regression] Relative includes in bits/locale_conv.h should be prefixed

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
Author: redi
Date: Thu Mar 21 12:07:10 2019
New Revision: 269835

URL: https://gcc.gnu.org/viewcvs?rev=269835&root=gcc&view=rev
Log:
PR libstdc++/88066 Use <> for includes not ""

These headers were missed in the previous commit for this bug.

There are also several "" includes in the profile mode headers, but
because they're deprecated I'm not fixing them.

* include/backward/hash_map: Use <> for includes not "".
* include/backward/hash_set: Likewise.
* include/backward/strstream: Likewise.
* include/tr1/bessel_function.tcc: Likewise.
* include/tr1/exp_integral.tcc: Likewise.
* include/tr1/legendre_function.tcc: Likewise.
* include/tr1/modified_bessel_func.tcc: Likewise.
* include/tr1/riemann_zeta.tcc: Likewise.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/backward/hash_map
trunk/libstdc++-v3/include/backward/hash_set
trunk/libstdc++-v3/include/backward/strstream
trunk/libstdc++-v3/include/tr1/bessel_function.tcc
trunk/libstdc++-v3/include/tr1/exp_integral.tcc
trunk/libstdc++-v3/include/tr1/legendre_function.tcc
trunk/libstdc++-v3/include/tr1/modified_bessel_func.tcc
trunk/libstdc++-v3/include/tr1/riemann_zeta.tcc

[Bug other/89394] libiberty :stack overflow in nm

[nickc at gcc dot gnu.org]

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

Nick Clifton  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-03-21
 CC||nickc at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #6 from Nick Clifton  ---
I have proposed a patch to fix this bug:

  https://gcc.gnu.org/ml/gcc-patches/2019-03/msg01048.html

[Bug tree-optimization/89505] [7 Regression] LibreOffice miscompilation starting with r260383

[doko at gcc dot gnu.org]

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

--- Comment #8 from Matthias Klose  ---
Author: doko
Date: Thu Mar 21 12:28:26 2019
New Revision: 269836

URL: https://gcc.gnu.org/viewcvs?rev=269836&root=gcc&view=rev
Log:
2019-03-21  Matthias Klose  

Backport from mainline
2019-02-26  Richard Biener  

PR tree-optimization/89505
* tree-ssa-structalias.c (compute_dependence_clique): Make sure
to handle restrict pointed-to vars with multiple subvars
correctly.

2019-03-21  Matthias Klose  

Backport from mainline
2019-02-26  Richard Biener  

PR tree-optimization/89505
* gcc.dg/torture/pr89505.c: New testcase.

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr89505.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/tree-ssa-structalias.c

[Bug tree-optimization/89505] [7 Regression] LibreOffice miscompilation starting with r260383

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/89509] restrict doesnt work with subfield accesses

[rguenth at gcc dot gnu.org]

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

Bug 89505 Summary: [7 Regression] LibreOffice miscompilation starting with 
r260383
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89505

   What|Removed |Added

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

[Bug rtl-optimization/85412] [8/9 Regression] ICE in put_TImodes, at sel-sched.c:7191

[asolokha at gmx dot com]

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

--- Comment #9 from Arseny Solokha  ---
(In reply to Andrey Belevantsev from comment #8)
> trunk doesn't
> ICE for me.

I don't have a good testcase at hand (it's just a matter of time, though), but
at least the following snippet makes the current trunk ICE:

  subroutine kc (IX, L4, PQ)

  integer VT, DK, L4, IX, F0
  real PQ (L4, L4)

  F0 = VT

 0010 do VT = 1, 2
  end do

  if (IX .eq. 0) go to 0020

  do VT = 1, L4
  end do

  go to 0010

 0020 do VT = 1, L4
 if (VT .ge. 0 .and. VT .le. F0) go to 0030

 do DK = VT, L4
PQ (VT, DK) = 0.0
 end do
 0030 end do

  return
  end

% powerpc-e300c3-linux-gnu-gfortran-9.0.0-alpha20190317 -m32 -mcpu=970 -O1
-fschedule-insns2 -fsel-sched-pipelining -fsel-sched-pipelining-outer-loops
-fselective-scheduling2 -ftree-parallelize-loops=2 --param
selsched-max-sched-times=3 -c eowqbvfn.f

[Bug rtl-optimization/85412] [8/9 Regression] ICE in put_TImodes, at sel-sched.c:7191

[abel at gcc dot gnu.org]

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

--- Comment #10 from Andrey Belevantsev  ---
(In reply to Arseny Solokha from comment #9)
> (In reply to Andrey Belevantsev from comment #8)
> > trunk doesn't
> > ICE for me.
> 
> I don't have a good testcase at hand (it's just a matter of time, though),
> but at least the following snippet makes the current trunk ICE:
> 
>   subroutine kc (IX, L4, PQ)
> 
>   integer VT, DK, L4, IX, F0
>   real PQ (L4, L4)
> 
>   F0 = VT
> 
>  0010 do VT = 1, 2
>   end do
> 
>   if (IX .eq. 0) go to 0020
> 
>   do VT = 1, L4
>   end do
> 
>   go to 0010
> 
>  0020 do VT = 1, L4
>  if (VT .ge. 0 .and. VT .le. F0) go to 0030
> 
>  do DK = VT, L4
> PQ (VT, DK) = 0.0
>  end do
>  0030 end do
> 
>   return
>   end
> 
> % powerpc-e300c3-linux-gnu-gfortran-9.0.0-alpha20190317 -m32 -mcpu=970 -O1
> -fschedule-insns2 -fsel-sched-pipelining -fsel-sched-pipelining-outer-loops
> -fselective-scheduling2 -ftree-parallelize-loops=2 --param
> selsched-max-sched-times=3 -c eowqbvfn.f

Is it easy for you to check that the above patch fixes also your testcase?

[Bug rtl-optimization/85412] [8/9 Regression] ICE in put_TImodes, at sel-sched.c:7191

[asolokha at gmx dot com]

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

--- Comment #11 from Arseny Solokha  ---
(In reply to Andrey Belevantsev from comment #10)
> Is it easy for you to check that the above patch fixes also your testcase?

Sure, I'll do it tomorrow.

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

[a.drobyshev at samsung dot com]

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

Andrey Drobyshev  changed:

   What|Removed |Added

  Attachment #45751|0   |1
is obsolete||
  Attachment #45851|0   |1
is obsolete||

--- Comment #27 from Andrey Drobyshev  ---
Created attachment 46001
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46001&action=edit
Updated patch candidate

I've rewritten the previous patch. Now instead of constructing a decl suitable
for one or another section, I just get the right section in assemble_variable
() and emit a dummy global into that. I like this solution better, because it
delivers us from pain of setting the right decl attributes. It seems to work
for the test cases we've introduced so far in this thread.
Please review.

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

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Also consider the equivalent(?)

constexpr foo() { throw 42; } // with or without constexpr

constexpr int Addrlen(int domain) {
switch (domain) {
  case 0:
return 0;
  case 2:
return 42;
}
foo();
}

if Addrlen is allowed to be constexpr when foo() is not called
[and is not declared constexpr].  And whether foo may be declared
constexpr or not.

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

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to Richard Biener from comment #4)
> Also consider the equivalent(?)
> 
> constexpr foo() { throw 42; } // with or without constexpr
> 
> constexpr int Addrlen(int domain) {
> switch (domain) {
>   case 0:
> return 0;
>   case 2:
> return 42;
> }
> foo();
> }
> 
> if Addrlen is allowed to be constexpr when foo() is not called
> [and is not declared constexpr].  And whether foo may be declared
> constexpr or not.

foo cannot be constexpr, but no diagnostic is required:

> For a constexpr function or constexpr constructor that is neither defaulted 
> nor a template, if no argument values exist such that an invocation of the 
> function or constructor could be an evaluated subexpression of a core 
> constant expression (7.7), or, for a constructor, a constant initializer for 
> some object (6.8.3.2), the program is ill-formed, no diagnostic required.

Addrlen *can* be constexpr, because there are argument values that allow it to
be evaluated at compile time, without ever reaching the throw (or reaching the
call to the non-constexpr foo).

[Bug fortran/54262] LOC shouldn't use copy-in/copy-out

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
> So far I did not find what to change to make specific->inquiry true for LOC. 

Fixed by the following patch

--- ../_clean/gcc/fortran/intrinsic.c   2019-03-12 16:12:35.0 +0100
+++ gcc/fortran/intrinsic.c 2019-03-21 11:24:16.0 +0100
@@ -212,7 +212,8 @@ do_ts29113_check (gfc_intrinsic_sym *spe
   && specific->id != GFC_ISYM_SIZEOF
   && specific->id != GFC_ISYM_UBOUND
   && specific->id != GFC_ISYM_IS_CONTIGUOUS
-  && specific->id != GFC_ISYM_C_LOC)
+  && specific->id != GFC_ISYM_C_LOC
+  && specific->id != GFC_ISYM_LOC)
{
  gfc_error ("Assumed-type argument at %L is not permitted as actual"
 " argument to the intrinsic %s", &a->expr->where,
@@ -3234,7 +3235,7 @@ add_functions (void)

   make_generic ("verify", GFC_ISYM_VERIFY, GFC_STD_F95);

-  add_sym_1 ("loc", GFC_ISYM_LOC, CLASS_IMPURE, ACTUAL_NO, BT_INTEGER, ii,
+  add_sym_1 ("loc", GFC_ISYM_LOC, CLASS_INQUIRY, ACTUAL_NO, BT_INTEGER, ii,
 GFC_STD_GNU, gfc_check_loc, NULL, gfc_resolve_loc,
 x, BT_UNKNOWN, 0, REQUIRED);

[Bug rtl-optimization/85528] ICE in code_motion_process_successors, at sel-sched.c:6403

[abel at gcc dot gnu.org]

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

Andrey Belevantsev  changed:

   What|Removed |Added

 CC||abel at gcc dot gnu.org

--- Comment #1 from Andrey Belevantsev  ---
Doesn't ICE for me at r259563 checkout -- anything else needed?

[Bug c++/89512] [7/8/9 Regression] ICE in get_expr_operands, at tree-ssa-operands.c:882

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #4 from Marek Polacek  ---
So fixed on trunk?

[Bug tree-optimization/88945] ICE in fold_convert_loc in FRE when using -fdump-tree-fre-details

[rguenth at gcc dot gnu.org]

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

Bug 89779 Summary: [9 Regression]  internal compiler error: tree check: 
expected class ‘type’, have ‘exceptional’ (error_mark) in 
tree_nop_conversion_p, at tree.c:12798
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89779

   What|Removed |Added

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

[Bug middle-end/89779] [9 Regression] internal compiler error: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in tree_nop_conversion_p, at tree.c:12798

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
Fixed (aka mitigated), IVOPTs issue still there, patch waiting for comments.

[Bug middle-end/89779] [9 Regression] internal compiler error: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in tree_nop_conversion_p, at tree.c:12798

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Author: rguenth
Date: Thu Mar 21 14:27:32 2019
New Revision: 269838

URL: https://gcc.gnu.org/viewcvs?rev=269838&root=gcc&view=rev
Log:
2019-03-21  Richard Biener  

PR tree-optimization/89779
* tree.c (tree_nop_conversion): Consolidate and fix defensive
checks with respect to released SSA names now having error_mark_node
type.
* fold-const.c (operand_equal_p): Likewise.

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

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

[Bug c++/81866] [7/8/9 Regression] ICE with a default template parameter which is a template class nested in a template class

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #3 from Marek Polacek  ---
Started with r149188.

[Bug rtl-optimization/88652] sel-sched.c:1545:11: runtime error: index 2 out of bounds for type 'long unsigned int [2]'

[abel at gcc dot gnu.org]

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

Andrey Belevantsev  changed:

   What|Removed |Added

 CC||abel at gcc dot gnu.org

--- Comment #2 from Andrey Belevantsev  ---
(In reply to Martin Liška from comment #1)
> Any progress on this please?

Maybe a stupid question, but how do I debug this
If I read that source line correctly, we're just assuming that for a
HARD_REG_SET set and a (regno, mode) pair we can always have enough space in
the set for regno, regno + 1, ..., regno + hard_regno_nregs (regno, mode) - 1. 
Is that not true anymore?

[Bug rtl-optimization/85528] ICE in code_motion_process_successors, at sel-sched.c:6403

[asolokha at gmx dot com]

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

--- Comment #2 from Arseny Solokha  ---
(In reply to Andrey Belevantsev from comment #1)
> Doesn't ICE for me at r259563 checkout -- anything else needed?

You may also want -m32, depending on your exact target[1]. I'll try to get
another testcase if needed.


[1] https://gcc.godbolt.org/z/SP6KQX

[Bug rtl-optimization/88652] sel-sched.c:1545:11: runtime error: index 2 out of bounds for type 'long unsigned int [2]'

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
(In reply to Andrey Belevantsev from comment #2)
> (In reply to Martin Liška from comment #1)
> > Any progress on this please?
> 
> Maybe a stupid question, but how do I debug this
> If I read that source line correctly, we're just assuming that for a
> HARD_REG_SET set and a (regno, mode) pair we can always have enough space in
> the set for regno, regno + 1, ..., regno + hard_regno_nregs (regno, mode) -
> 1.  Is that not true anymore?

I suppose place in a gcc_assert (regno + i < FIRST_PSEUDO_REGISTER) and have it
assert?

I don't see where the code checks that regno is a hard register.  With 
the following I get

during RTL pass: sched1
pr87759.c:39:1: internal compiler error: in verify_target_availability, at
sel-sched.c:1545
   39 | }
  | ^
0x110f7c3 verify_target_availability
/space/rguenther/src/svn/trunk2/gcc/sel-sched.c:1545
0x110fc31 find_best_reg_for_expr
/space/rguenther/src/svn/trunk2/gcc/sel-sched.c:1680
0x11147e9 fill_vec_av_set
/space/rguenther/src/svn/trunk2/gcc/sel-sched.c:3800
0x1114fea fill_ready_list
...

Index: gcc/sel-sched.c
===
--- gcc/sel-sched.c (revision 269832)
+++ gcc/sel-sched.c (working copy)
@@ -1542,6 +1542,7 @@ verify_target_availability (expr_t expr,
 {
   if (bitmap_bit_p (used_regs, regno + i))
 live_available = false;
+  gcc_assert (regno + i < FIRST_PSEUDO_REGISTER);
   if (TEST_HARD_REG_BIT (reg_rename_p->unavailable_hard_regs, regno + i))
 hard_available = false;
 }

(gdb) p regno
$1 = 158

[Bug c++/89214] [7/8/9 Regression] ICE in digest_init_r, at cp/typeck2.c:1211 with -std=c++17

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek  ---
Somewhat cleaned up test:

struct A
{
  A (int);
};

struct BB
{
  A v;
};

struct B : BB
{};

B
foo ()
{
  return {{B {{42;
}

[Bug rtl-optimization/88652] sel-sched.c:1545:11: runtime error: index 2 out of bounds for type 'long unsigned int [2]'

[abel at gcc dot gnu.org]

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

--- Comment #4 from Andrey Belevantsev  ---
(In reply to Richard Biener from comment #3)
> (In reply to Andrey Belevantsev from comment #2)
> > (In reply to Martin Liška from comment #1)
> > > Any progress on this please?
> > 
> > Maybe a stupid question, but how do I debug this
> > If I read that source line correctly, we're just assuming that for a
> > HARD_REG_SET set and a (regno, mode) pair we can always have enough space in
> > the set for regno, regno + 1, ..., regno + hard_regno_nregs (regno, mode) -
> > 1.  Is that not true anymore?
> 
> I suppose place in a gcc_assert (regno + i < FIRST_PSEUDO_REGISTER) and have
> it
> assert?

Looks like you're right :)  I'll fix that, then.

> 
> I don't see where the code checks that regno is a hard register.  With 
> the following I get
> 
> during RTL pass: sched1
> pr87759.c:39:1: internal compiler error: in verify_target_availability, at
> sel-sched.c:1545
>39 | }
>   | ^
> 0x110f7c3 verify_target_availability
> /space/rguenther/src/svn/trunk2/gcc/sel-sched.c:1545
> 0x110fc31 find_best_reg_for_expr
> /space/rguenther/src/svn/trunk2/gcc/sel-sched.c:1680
> 0x11147e9 fill_vec_av_set
> /space/rguenther/src/svn/trunk2/gcc/sel-sched.c:3800
> 0x1114fea fill_ready_list
> ...
> 
> Index: gcc/sel-sched.c
> ===
> --- gcc/sel-sched.c (revision 269832)
> +++ gcc/sel-sched.c (working copy)
> @@ -1542,6 +1542,7 @@ verify_target_availability (expr_t expr,
>  {
>if (bitmap_bit_p (used_regs, regno + i))
>  live_available = false;
> +  gcc_assert (regno + i < FIRST_PSEUDO_REGISTER);
>if (TEST_HARD_REG_BIT (reg_rename_p->unavailable_hard_regs, regno +
> i))
>  hard_available = false;
>  }
> 
> (gdb) p regno
> $1 = 158

[Bug c++/89214] [7/8/9 Regression] ICE in digest_init_r, at cp/typeck2.c:1211 with -std=c++17

[mpolacek at gcc dot gnu.org]

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

--- Comment #7 from Marek Polacek  ---
And an extended test:

// PR c++/89214
// { dg-do compile { target c++17 } }

struct A
{
  A (int);
};

struct BB
{
  A a;
};

struct B : BB
{
};

void
foo ()
{
  B b1 = {42};
  B b2 = {{42}};
  B b3 = {{{42}}};

  B b4 = B{42};
  B b5 = B{{42}};
  B b6 = B{{{42}}};

  B b7 = {B{42}};
  B b8 = {B{{42}}};
  B b9 = {B{{{42;

  B b10 = {{B{42}}};
  B b11 = {{B{{42;
  B b12 = {{B{{{42};

  B bb1{42};
  B bb2{{42}};
  B bb3{{{42}}};

  B bb7{B{42}};
  B bb8{B{{42}}};
  B bb9{B{{{42;

  B bb10{{B{42}}};
  B bb11{{B{{42;
  B bb12{{B{{{42};
}

[Bug rtl-optimization/85412] [8/9 Regression] ICE in put_TImodes, at sel-sched.c:7191

[asolokha at gmx dot com]

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

--- Comment #12 from Arseny Solokha  ---
Meanwhile, here's a C testcase that fails w/ the latest trunk snapshot on
x86_64:

__int128 jv;

void
zm (__int128 g9, unsigned short int sm, short int hk)
{
  while (hk < 1)
{
  if (jv == 0)
sm *= g9;

  if (sm < jv)
hk = sm;

  g9 |= sm == hk;
}
}

% x86_64-unknown-linux-gnu-gcc-9.0.0-alpha20190317 -march=bonnell -O1
-fpeephole2 -fschedule-insns2 -fsel-sched-pipelining -fselective-scheduling2
-ftree-loop-if-convert -fno-if-conversion -fno-move-loop-invariants
-fno-split-wide-types -fno-tree-dominator-opts -c erji5uml.c

[Bug fortran/87352] [7/8/9 Regression] Large stack usage with new gfortran

[jeremy at jeremysanders dot net]

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

--- Comment #6 from Jeremy Sanders  ---
I think I have worked out where the problem lies. The code contains fixed-sized
arrays of types containing allocatable arrays and other nested types with
allocatable arrays. If I switch the fixed-sized declarations to allocatable,
then the compile time and output size drastically reduce.

Changing three of the declarations in the source code to allocatable fixes the
problem (see attached test case patch).

I've also made a much smaller testcase (only 90 lines) which highlights the
problem. This source code takes 50s to compile on my system. Commenting out
line 73 and uncommenting line 74 reduces the compile time to 0.4s.

[Bug fortran/87352] [7/8/9 Regression] Large stack usage with new gfortran

[jeremy at jeremysanders dot net]

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

--- Comment #7 from Jeremy Sanders  ---
Created attachment 46002
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46002&action=edit
Tiny patch to fix testcase

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

[segher at gcc dot gnu.org]

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

--- Comment #28 from Segher Boessenkool  ---
Patches should go to gcc-patches@.  That is where reviews happen, too.

[Bug fortran/87352] [7/8/9 Regression] Large stack usage with new gfortran

[jeremy at jeremysanders dot net]

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

--- Comment #8 from Jeremy Sanders  ---
Created attachment 46003
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46003&action=edit
Much smaller testcase. Switch 73/74 to see the difference.

[Bug c++/80559] [7/8/9 Regression] Segmentation fault on invalid initializer list template arguments

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||paolo.carlini at oracle dot com

--- Comment #6 from Paolo Carlini  ---
The ICE cannot be reproduced in trunk. Apparently it got fixed for 8.1.0 and
the fix backported to 7.2.0 too. Thus I think we can close this completely or
maybe remove the regression markers and change it to a pure diagnostic
enhancement issue, because certainly the series of four identical error
messages about template argument 2 doesn't make any sense. Barring different
opinions I'm going to do the latter in a day or so.

[Bug target/89784] Missing AVX512 intrinsics

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 46004
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46004&action=edit
gcc9-pr89784.patch

Untested patch, so far without testsuite coverage.

[Bug ada/89786] New: ice in add_expr, at tree.c:7767

[dcb314 at hotmail dot com]

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

Bug ID: 89786
   Summary: ice in add_expr, at tree.c:7767
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

I just tried out some Ada testsuite code:

This works:

$ ~/gcc/results/bin/gcc -c -I./gnat.dg/   -I- ./gnat.dg/slice7.adb
slice7.adb:27:03: warning: variable "Obj" is read but never assigned
$ 

This doesn't:

$ ~/gcc/results/bin/gcc -c -I./gnat.dg/ -O2  -I- ./gnat.dg/slice7.adb
slice7.adb:27:03: warning: variable "Obj" is read but never assigned
+===GNAT BUG DETECTED==+
| 20190319 (experimental) (x86_64-pc-linux-gnu) GCC error:   |
| in add_expr, at tree.c:7767  |
| Error detected around ./gnat.dg/slice7.adb:35:3   

The problem seems to occur sometime before revision 269500.
slice7.adb is from the gcc/testsuite directory.

[Bug fortran/89787] New: Fortran OpenACC 'routine' directive: parent namespace(s)

[tschwinge at gcc dot gnu.org]

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

Bug ID: 89787
   Summary: Fortran OpenACC 'routine' directive: parent
namespace(s)
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: openacc
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: aldot at gcc dot gnu.org
  Target Milestone: ---

See the suggested 'gfc_find_symtree' changes and then 'gfc_find_sym_tree'
comment in .  We'll need
to understand how to constuct such (nested?) namespaces, need test cases.

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

[a.drobyshev at samsung dot com]

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

--- Comment #29 from Andrey Drobyshev  ---
(In reply to Segher Boessenkool from comment #28)
> Patches should go to gcc-patches@.  That is where reviews happen, too.

That's still a patch candidate. I want to hear other folks' opinion before it
goes to gcc-patches@.

[Bug other/89788] New: trunk/liboffloadmic/runtime/emulator/coi_host.cpp:175]: (error) Null pointer dereference

[dcb314 at hotmail dot com]

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

Bug ID: 89788
   Summary: trunk/liboffloadmic/runtime/emulator/coi_host.cpp:175]
: (error) Null pointer dereference
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Source code is

  DIR *dir = opendir (path);
  if (dir == NULL)
COIERROR ("Cannot open directory %s.", dir);

maybe better code:

  DIR *dir = opendir (path);
  if (dir == NULL)
COIERROR ("Cannot open directory %s.", path);

[Bug tree-optimization/89789] New: [9 Regression] Compile time hog during RPO VN

[asolokha at gmx dot com]

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

Bug ID: 89789
   Summary: [9 Regression] Compile time hog during RPO VN
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: compile-time-hog
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-9.0.0-alpha20190317 snapshot (r269746) takes indefinite time when compiling
the following testcase at -O2 (-O3, -Ofast, -Os):

int x2;

void
m2 (void)
{
  goto gg;

  int fz, vh = 0;

  for (fz = 0; fz < 1; ++fz)
{
  vh ^= x2;

  if (0)
{
 gg:
  x2 %= 1;
  x2 += vh;
}
}
}

% timeout 10 gcc-9.0.0-alpha20190317 -O2 -c nzl2rb2h.c
zsh: exit 124   timeout 10 gcc-9.0.0-alpha20190317 -O2 -c nzl2rb2h.c

[Bug middle-end/89790] New: [9 Regression] ICE segfault in operand_equal_p() at fold-const.c:3000 with -Wduplicated-cond since r269838

[belyshev at depni dot sinp.msu.ru]

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

Bug ID: 89790
   Summary: [9 Regression] ICE segfault in operand_equal_p() at
fold-const.c:3000 with -Wduplicated-cond since r269838
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: belyshev at depni dot sinp.msu.ru
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---

Fix for bug 89779 (r269838) caused ICE during gdb build.  Reduced testcase,
compile with -O -Wduplicated-cond:

template  class a {
  typedef a b;
  template  void c();
};
template  template  void a::c() {
  int f;
  b g;
  if (g == 0)
;
  else if (f)
{
}
}


Partial backtrace:

Program received signal SIGSEGV, Segmentation fault.
operand_equal_p (arg0=0x776df7e0, arg1=0x776df740, flags=16) at
../../gcc/gcc/fold-const.c:3000
3000  if (TYPE_UNSIGNED (TREE_TYPE (arg0)) != TYPE_UNSIGNED (TREE_TYPE
(arg1))
(gdb) bt
#0  operand_equal_p (arg0=0x776df7e0, arg1=0x776df740, flags=16) at
../../gcc/gcc/fold-const.c:3000
#1  0x00c9ac8b in operand_equal_p (arg0=arg0@entry=0x776df7e0,
arg1=arg1@entry=0x776df740, 
flags=flags@entry=0) at ../../gcc/gcc/fold-const.c:2950
#2  0x00b0c572 in warn_duplicated_cond_add_or_warn (loc=, cond=cond@entry=0x776df7e0, 
chain=chain@entry=0x7fffdd88) at ../../gcc/gcc/c-family/c-warn.c:2318
#3  0x009c4846 in cp_parser_selection_statement (chain=,
if_p=0x0, parser=0x77fd0ab0)
at ../../gcc/gcc/cp/parser.c:11784
#4  cp_parser_statement (parser=0x77fd0ab0, in_statement_expr=0x0,
in_compound=, if_p=0x0, 
chain=, loc_after_labels=0x7fffddec) at
../../gcc/gcc/cp/parser.c:11147
#5  0x009de4f8 in cp_parser_implicitly_scoped_statement
(parser=parser@entry=0x77fd0ab0, 
if_p=if_p@entry=0x0, guard_tinfo=..., chain=0x25323d0) at
../../gcc/gcc/cp/parser.c:13004
#6  0x009c4788 in cp_parser_selection_statement (chain=,
if_p=0x0, parser=0x77fd0ab0)
at ../../gcc/gcc/cp/parser.c:11865
...

[Bug debug/89463] debug information for iteractor of an empty loop is gone (at -O3)

[qrzhang at gatech dot edu]

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

--- Comment #4 from Qirun Zhang  ---
Bisect points to r151362.

commit ff79704e04af919c4fe501c7dceca8b21cced614
Author: aoliva 
Date:   Thu Sep 3 05:24:57 2009 +

* toplev.c (process_options): Enable var-tracking-assignments
by default if var-tracking is enabled.


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@151362
138bc75d-0d04-0410-961f-82ee72b054a4

[Bug c++/89214] [7/8/9 Regression] ICE in digest_init_r, at cp/typeck2.c:1211 with -std=c++17

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug debug/89791] New: gcc generates wrong debug information at -O3

[qrzhang at gatech dot edu]

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

Bug ID: 89791
   Summary: gcc generates wrong debug information at -O3
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: qrzhang at gatech dot edu
  Target Milestone: ---

It affects gcc-4.6 to gcc-trunk. The expected output is "i=7" or . With "-O3", it outputs "i=0".

I am using two files since "noipa" attribute directive is not supported in
early gcc versions.

Bisect points to r154402.

commit 43e54ec3e93dd2ef495375ead1f1eac467a727d1
Author: aoliva 
Date:   Sat Nov 21 05:06:24 2009 +

* tree-ssa.c (find_released_ssa_name): Handle NULL wi.
(insert_debug_temp_for_var_def): Handle degenerate PHI nodes.
(insert_debug_temps_for_defs): Handle PHI nodes.
* tree-ssa-dom.c (degenerate_phi_result): Don't crash on released
SSA names.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@154402
138bc75d-0d04-0410-961f-82ee72b054a4


$ gcc-trunk -v
gcc version 9.0.1 20190321 (experimental) [trunk revision 269832] (GCC)


$ cat abc.c
int main() {
  int i = 0;
  for (; i < 7; i++)
;
optimize_me_not();
}


$ cat outer.c
void optimize_me_not() {}

# correct output #
$ gcc-trunk -g  abc.c outer.c
$ gdb -x cmds -batch a.out
Breakpoint 1 at 0x40046d: file abc.c, line 5.

Breakpoint 1, main () at abc.c:5
5   optimize_me_not();
$1 = 7

# Wrong output #
$ gcc-trunk -g  abc.c outer.c
$ gdb -x cmds -batch a.out
Breakpoint 1 at 0x400380: file abc.c, line 5.

Breakpoint 1, main () at abc.c:5
5   optimize_me_not();
$1 = 0

[Bug c++/89214] [7/8/9 Regression] ICE in digest_init_r, at cp/typeck2.c:1211 with -std=c++17

[mpolacek at gcc dot gnu.org]

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

--- Comment #8 from Marek Polacek  ---
Another version, without a converting ctor:

struct B {
  int c;
};

struct D : B { };

void
fn ()
{
  D b{{D{42}}};
}

[Bug fortran/29383] Fortran 2003/F95[TR15580:1999]: Floating point exception (IEEE) support

[tschwinge at gcc dot gnu.org]

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

--- Comment #17 from Thomas Schwinge  ---
Author: tschwinge
Date: Thu Mar 21 18:54:50 2019
New Revision: 269845

URL: https://gcc.gnu.org/viewcvs?rev=269845&root=gcc&view=rev
Log:
[testsuite, Fortran] Consistently set 'DEFAULT_FFLAGS'

In the same 'runtest' instance, 'global' variables persist from one '*.exp'
file to another.

All other '*.exp' files are using " -pedantic-errors" instead of the empty
string as the default for 'DEFAULT_FFLAGS'.  Thus this setting of
'DEFAULT_FFLAGS' is not idempotent, depends on whether
'gfortran.dg/ieee/ieee.exp', or an other defining '*.exp' file is executed
first.

gcc/testsuite/
PR fortran/29383
* gfortran.dg/ieee/ieee.exp (DEFAULT_FFLAGS): Set the same as in
other '*.exp' files.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/ieee/ieee.exp

[Bug fortran/29383] Fortran 2003/F95[TR15580:1999]: Floating point exception (IEEE) support

[tschwinge at gcc dot gnu.org]

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

--- Comment #19 from Thomas Schwinge  ---
Author: tschwinge
Date: Thu Mar 21 18:57:56 2019
New Revision: 269847

URL: https://gcc.gnu.org/viewcvs?rev=269847&root=gcc&view=rev
Log:
[testsuite, Fortran] Consistently set 'DEFAULT_FFLAGS'

In the same 'runtest' instance, 'global' variables persist from one '*.exp'
file to another.

All other '*.exp' files are using " -pedantic-errors" instead of the empty
string as the default for 'DEFAULT_FFLAGS'.  Thus this setting of
'DEFAULT_FFLAGS' is not idempotent, depends on whether
'gfortran.dg/ieee/ieee.exp', or an other defining '*.exp' file is executed
first.

gcc/testsuite/
PR fortran/29383
* gfortran.dg/ieee/ieee.exp (DEFAULT_FFLAGS): Set the same as in
other '*.exp' files.

trunk r269845

Modified:
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/ieee/ieee.exp

[Bug fortran/29383] Fortran 2003/F95[TR15580:1999]: Floating point exception (IEEE) support

[tschwinge at gcc dot gnu.org]

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

--- Comment #18 from Thomas Schwinge  ---
Author: tschwinge
Date: Thu Mar 21 18:57:39 2019
New Revision: 269846

URL: https://gcc.gnu.org/viewcvs?rev=269846&root=gcc&view=rev
Log:
[testsuite, Fortran] Consistently set 'DEFAULT_FFLAGS'

In the same 'runtest' instance, 'global' variables persist from one '*.exp'
file to another.

All other '*.exp' files are using " -pedantic-errors" instead of the empty
string as the default for 'DEFAULT_FFLAGS'.  Thus this setting of
'DEFAULT_FFLAGS' is not idempotent, depends on whether
'gfortran.dg/ieee/ieee.exp', or an other defining '*.exp' file is executed
first.

gcc/testsuite/
PR fortran/29383
* gfortran.dg/ieee/ieee.exp (DEFAULT_FFLAGS): Set the same as in
other '*.exp' files.

trunk r269845

Modified:
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/ieee/ieee.exp

[Bug fortran/56408] Fix dependency handling of testsuite/gfortran.dg

[tschwinge at gcc dot gnu.org]

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

--- Comment #12 from Thomas Schwinge  ---
Author: tschwinge
Date: Thu Mar 21 19:16:29 2019
New Revision: 269848

URL: https://gcc.gnu.org/viewcvs?rev=269848&root=gcc&view=rev
Log:
[testsuite, Fortran] Apply DejaGnu 1.4.4 work-around also to
'gfortran.dg/coarray/caf.exp:dg-compile-aux-modules'

See trunk r215293.  This unifies all 'dg-compile-aux-modules' instances.

gcc/testsuite/
PR fortran/56408
* gfortran.dg/coarray/caf.exp (dg-compile-aux-modules): Workaround
missing nexted dg-test call support in dejaGNU 1.4.4.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/coarray/caf.exp

[Bug fortran/56408] Fix dependency handling of testsuite/gfortran.dg

[tschwinge at gcc dot gnu.org]

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

--- Comment #13 from Thomas Schwinge  ---
Author: tschwinge
Date: Thu Mar 21 19:16:54 2019
New Revision: 269849

URL: https://gcc.gnu.org/viewcvs?rev=269849&root=gcc&view=rev
Log:
[testsuite, Fortran] Apply DejaGnu 1.4.4 work-around also to
'gfortran.dg/coarray/caf.exp:dg-compile-aux-modules'

See trunk r215293.  This unifies all 'dg-compile-aux-modules' instances.

gcc/testsuite/
PR fortran/56408
* gfortran.dg/coarray/caf.exp (dg-compile-aux-modules): Workaround
missing nexted dg-test call support in dejaGNU 1.4.4.

trunk r269848

Modified:
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/coarray/caf.exp

[Bug fortran/56408] Fix dependency handling of testsuite/gfortran.dg

[tschwinge at gcc dot gnu.org]

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

--- Comment #14 from Thomas Schwinge  ---
Author: tschwinge
Date: Thu Mar 21 19:17:12 2019
New Revision: 269850

URL: https://gcc.gnu.org/viewcvs?rev=269850&root=gcc&view=rev
Log:
[testsuite, Fortran] Apply DejaGnu 1.4.4 work-around also to
'gfortran.dg/coarray/caf.exp:dg-compile-aux-modules'

See trunk r215293.  This unifies all 'dg-compile-aux-modules' instances.

gcc/testsuite/
PR fortran/56408
* gfortran.dg/coarray/caf.exp (dg-compile-aux-modules): Workaround
missing nexted dg-test call support in dejaGNU 1.4.4.

trunk r269848

Modified:
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/coarray/caf.exp

[Bug fortran/56408] Fix dependency handling of testsuite/gfortran.dg

[tschwinge at gcc dot gnu.org]

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

--- Comment #15 from Thomas Schwinge  ---
Author: tschwinge
Date: Thu Mar 21 19:29:57 2019
New Revision: 269851

URL: https://gcc.gnu.org/viewcvs?rev=269851&root=gcc&view=rev
Log:
[testsuite] Fix 'dg-compile-aux-modules' diagnostic

gcc/testsuite/
PR fortran/56408
* gcc.target/powerpc/ppc-fortran/ppc-fortran.exp
(dg-compile-aux-modules): Fix diagnostic.
* gfortran.dg/coarray/caf.exp (dg-compile-aux-modules): Likewise.
* gfortran.dg/dg.exp (dg-compile-aux-modules): Likewise.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/powerpc/ppc-fortran/ppc-fortran.exp
trunk/gcc/testsuite/gfortran.dg/coarray/caf.exp
trunk/gcc/testsuite/gfortran.dg/dg.exp

[Bug fortran/56408] Fix dependency handling of testsuite/gfortran.dg

[tschwinge at gcc dot gnu.org]

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

--- Comment #16 from Thomas Schwinge  ---
Author: tschwinge
Date: Thu Mar 21 19:31:09 2019
New Revision: 269852

URL: https://gcc.gnu.org/viewcvs?rev=269852&root=gcc&view=rev
Log:
[testsuite] Fix 'dg-compile-aux-modules' diagnostic

gcc/testsuite/
PR fortran/56408
* gcc.target/powerpc/ppc-fortran/ppc-fortran.exp
(dg-compile-aux-modules): Fix diagnostic.
* gfortran.dg/coarray/caf.exp (dg-compile-aux-modules): Likewise.
* gfortran.dg/dg.exp (dg-compile-aux-modules): Likewise.

trunk r269851

Modified:
branches/gcc-8-branch/gcc/testsuite/ChangeLog
   
branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/ppc-fortran/ppc-fortran.exp
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/coarray/caf.exp
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/dg.exp

[Bug fortran/56408] Fix dependency handling of testsuite/gfortran.dg

[tschwinge at gcc dot gnu.org]

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

--- Comment #17 from Thomas Schwinge  ---
Author: tschwinge
Date: Thu Mar 21 19:31:30 2019
New Revision: 269853

URL: https://gcc.gnu.org/viewcvs?rev=269853&root=gcc&view=rev
Log:
[testsuite] Fix 'dg-compile-aux-modules' diagnostic

gcc/testsuite/
PR fortran/56408
* gcc.target/powerpc/ppc-fortran/ppc-fortran.exp
(dg-compile-aux-modules): Fix diagnostic.
* gfortran.dg/coarray/caf.exp (dg-compile-aux-modules): Likewise.
* gfortran.dg/dg.exp (dg-compile-aux-modules): Likewise.

trunk r269851

Modified:
branches/gcc-7-branch/gcc/testsuite/ChangeLog
   
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/ppc-fortran/ppc-fortran.exp
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/coarray/caf.exp
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/dg.exp

[Bug c++/89214] [7/8/9 Regression] ICE in digest_init_r, at cp/typeck2.c:1211 with -std=c++17

[mpolacek at gcc dot gnu.org]

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

--- Comment #9 from Marek Polacek  ---
And a fix:

--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -5978,6 +5978,18 @@ reshape_init_class (tree type, reshape_iter *d, bool
first_initializer_p,
   field = next_initializable_field (DECL_CHAIN (field));
 }

+  /* "If T is a class type and the initializer list has a single
+ element of type cv U, where U is T or a class derived from T,
+ the object is initialized from that element."  */
+  if (cxx_dialect >= cxx11
+  && BRACE_ENCLOSED_INITIALIZER_P (new_init)
+  && CONSTRUCTOR_NELTS (new_init) == 1)
+{
+  tree elt = CONSTRUCTOR_ELT (new_init, 0)->value;
+  if (reference_related_p (type, TREE_TYPE (elt)))
+   return elt;
+}
+
   return new_init;
 }

[Bug fortran/72741] Fortran OpenACC routine directive doesn't properly handle clauses specifying the level of parallelism

[tschwinge at gcc dot gnu.org]

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

--- Comment #12 from Thomas Schwinge  ---
Author: tschwinge
Date: Thu Mar 21 19:44:45 2019
New Revision: 269855

URL: https://gcc.gnu.org/viewcvs?rev=269855&root=gcc&view=rev
Log:
[PR72741] Encode OpenACC 'routine' directive's level of parallelism inside
Fortran module files

If 'use'ing with an old GCC a new module file (with OpenACC 'routine'
directive's level of parallelism encoded), then that expectedly fails as
follows:

f951: Fatal Error: Reading module 'routine_module_mod_1' at line 27 column
21: find_enum(): Enum not found

If 'use'ing with a new GCC an old module file (without OpenACC 'routine'
directive's level of parallelism encoded), then that (silently) continues to
accept the module file, and will proceed with the previous, erroneous behavior.

These seem to be acceptable compromises, instead of incrementing 'MOD_VERSION'.

gcc/fortran/
PR fortran/72741
* module.c (verify_OACC_ROUTINE_LOP_NONE): New function.
(enum ab_attribute): Add AB_OACC_ROUTINE_LOP_GANG,
AB_OACC_ROUTINE_LOP_WORKER, AB_OACC_ROUTINE_LOP_VECTOR,
AB_OACC_ROUTINE_LOP_SEQ.
(attr_bits): Add these.
(mio_symbol_attribute): Handle these.
gcc/testsuite/
PR fortran/72741
* gfortran.dg/goacc/routine-module-1.f90: New file.
* gfortran.dg/goacc/routine-module-2.f90: Likewise.
* gfortran.dg/goacc/routine-module-mod-1.f90: Likewise.

Added:
trunk/gcc/testsuite/gfortran.dg/goacc/routine-module-1.f90
trunk/gcc/testsuite/gfortran.dg/goacc/routine-module-2.f90
trunk/gcc/testsuite/gfortran.dg/goacc/routine-module-mod-1.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/module.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/72741] Fortran OpenACC routine directive doesn't properly handle clauses specifying the level of parallelism

[tschwinge at gcc dot gnu.org]

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

--- Comment #13 from Thomas Schwinge  ---
Author: tschwinge
Date: Thu Mar 21 19:54:51 2019
New Revision: 269856

URL: https://gcc.gnu.org/viewcvs?rev=269856&root=gcc&view=rev
Log:
[PR72741] The name in a Fortran OpenACC 'routine' directive refers to the
containing subroutine or function

gcc/fortran/
PR fortran/72741
* openmp.c (gfc_match_oacc_routine): Clarify.
gcc/testsuite/
PR fortran/72741
* gfortran.dg/goacc/routine-module-mod-1.f90: Update.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/openmp.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/goacc/routine-module-mod-1.f90

[Bug fortran/89773] Fortran OpenACC 'routine' directive refuses procedures with implicit EXTERNAL attribute

[tschwinge at gcc dot gnu.org]

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

--- Comment #1 from Thomas Schwinge  ---
Author: tschwinge
Date: Thu Mar 21 20:02:42 2019
New Revision: 269857

URL: https://gcc.gnu.org/viewcvs?rev=269857&root=gcc&view=rev
Log:
[PR89773] Fortran OpenACC 'routine' directive refuses procedures with implicit
EXTERNAL attribute

gcc/fortran/
PR fortran/89773
* gfortran.h (gfc_oacc_routine_name): Add loc member.
(gfc_resolve_oacc_routines): Declare.
* openmp.c (gfc_match_oacc_routine): Move some error checking
into...
(gfc_resolve_oacc_routines): ... this new function.
* resolve.c (resolve_codes): Call it.
gcc/testsuite/
PR fortran/89773
* gfortran.dg/goacc/pr89773.f90: New file.
* gfortran.dg/goacc/pr77765.f90: Adjust.
* gfortran.dg/goacc/routine-6.f90: Adjust, and extend.

Added:
trunk/gcc/testsuite/gfortran.dg/goacc/pr89773.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/openmp.c
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/goacc/pr77765.f90
trunk/gcc/testsuite/gfortran.dg/goacc/routine-6.f90

[Bug fortran/89787] Fortran OpenACC 'routine' directive: parent namespace(s)

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-03-21
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=78377
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
What is this PR about?

Note that it may be related to pr78377 item 5.

[Bug fortran/78377] [cleanup] gfc_get_tbp_symtree vs. gfc_get_sym_tree

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
This kind of PRs is a nightmare when sorting the bug list.

[Bug middle-end/89790] [9 Regression] ICE segfault in operand_equal_p() at fold-const.c:3000 with -Wduplicated-cond since r269838

[dcb314 at hotmail dot com]

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

David Binderman  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #1 from David Binderman  ---
I see something similar during bootstrap with -Wduplicated-cond.

0xc91b30 warn_duplicated_cond_add_or_warn(unsigned int, tree_node*,
vec**)
../../trunk/gcc/c-family/c-warn.c:2318
0xa5dfd4 cp_parser_selection_statement
../../trunk/gcc/cp/parser.c:11784
0xa5ccc4 cp_parser_statement
../../trunk/gcc/cp/parser.c:11147
0xa6100c cp_parser_implicitly_scoped_statement
../../trunk/gcc/cp/parser.c:13004

This used to work at revision 269800 and doesn't at 269850.

[Bug fortran/72741] Fortran OpenACC routine directive doesn't properly handle clauses specifying the level of parallelism

[tschwinge at gcc dot gnu.org]

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

--- Comment #14 from Thomas Schwinge  ---
Author: tschwinge
Date: Thu Mar 21 20:13:44 2019
New Revision: 269858

URL: https://gcc.gnu.org/viewcvs?rev=269858&root=gcc&view=rev
Log:
[PR72741] Properly handle clauses specifying the level of parallelism for
'external' Fortran OpenACC routines

..., so as to also for these enable the generic middle end OMP code to verify
proper nesting of loops/routines regarding their levels of parallelism.

gcc/fortran/
PR fortran/72741
* openmp.c (gfc_match_oacc_routine): Set the level of parallelism
for all variants.
(gfc_resolve_oacc_routines): Call gfc_add_omp_declare_target.
gcc/testsuite/
PR fortran/72741
* c-c++-common/goacc/routine-3-extern.c: New file.
* c-c++-common/goacc/routine-3.c: Adjust.
* c-c++-common/goacc/routine-4-extern.c: New file.
* c-c++-common/goacc/routine-4.c: Adjust.
* gfortran.dg/goacc/routine-module-3.f90: New file.
* gfortran.dg/goacc/routine-external-level-of-parallelism-1.f: New
file.
* gfortran.dg/goacc/routine-external-level-of-parallelism-2.f:
Likewise.

Added:
trunk/gcc/testsuite/c-c++-common/goacc/routine-3-extern.c
  - copied, changed from r269857,
trunk/gcc/testsuite/c-c++-common/goacc/routine-3.c
trunk/gcc/testsuite/c-c++-common/goacc/routine-4-extern.c
  - copied, changed from r269857,
trunk/gcc/testsuite/c-c++-common/goacc/routine-4.c
   
trunk/gcc/testsuite/gfortran.dg/goacc/routine-external-level-of-parallelism-1.f
   
trunk/gcc/testsuite/gfortran.dg/goacc/routine-external-level-of-parallelism-2.f
trunk/gcc/testsuite/gfortran.dg/goacc/routine-module-3.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/openmp.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/goacc/routine-3.c
trunk/gcc/testsuite/c-c++-common/goacc/routine-4.c

[Bug debug/89454] gcc generates wrong debug information at -Og

[qrzhang at gatech dot edu]

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

--- Comment #1 from Qirun Zhang  ---
Bisect points to r151362.

commit ff79704e04af919c4fe501c7dceca8b21cced614
Author: aoliva 
Date:   Thu Sep 3 05:24:57 2009 +

* toplev.c (process_options): Enable var-tracking-assignments
by default if var-tracking is enabled.


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@151362
138bc75d-0d04-0410-961f-82ee72b054a4

[Bug debug/89454] gcc generates wrong debug information at -Og

[qrzhang at gatech dot edu]

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

--- Comment #2 from Qirun Zhang  ---
(In reply to Qirun Zhang from comment #1)
> Bisect points to r151362.
> 
> commit ff79704e04af919c4fe501c7dceca8b21cced614
> Author: aoliva 
> Date:   Thu Sep 3 05:24:57 2009 +
> 
> * toplev.c (process_options): Enable var-tracking-assignments
> by default if var-tracking is enabled.
> 
> 
> git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@151362
> 138bc75d-0d04-0410-961f-82ee72b054a4

Bisected the result with "-O3" since gcc-4.4 does not support "-Og".

[Bug c++/89214] [7/8/9 Regression] ICE in digest_init_r, at cp/typeck2.c:1211 with -std=c++17

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #10 from Marek Polacek  ---
https://gcc.gnu.org/ml/gcc-patches/2019-03/msg01075.html

[Bug fortran/54262] LOC shouldn't use copy-in/copy-out

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres  ---
Regtested cleanly with the patch in comment 4.

If I remove the lines

  se->expr = convert (pvoid_type_node, se->expr);
  se->expr = gfc_evaluate_now (se->expr, &se->pre);

in conv_isocbinding_function, on darwin I get a warning at link time with the
tests in f03gl:

ld: warning: PIE disabled. Absolute addressing (perhaps -mdynamic-no-pic) not
allowed in code signed PIE, but used in lC0 from
/var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//ccjizw7H.o. To fix this
warning, don't compile with -mdynamic-no-pic or link with -Wl,-no_pie

However all the tests I have tried succeed.

I also see

FAIL: gfortran.dg/c_loc_test_22.f90   -O   scan-tree-dump-times original
"D.[0-9]+ = parm.[0-9]+.data;[^;]+ptr[1-4] = D.[0-9]+;" 4 (found 0 times)

the

D.* = parm.*.data;
ptr* = D.*;

are replaced with

ptr* = parm.*.data;

If I remove the lines

  temp_var = gfc_create_var (gfc_get_int_type (gfc_index_integer_kind), NULL);
  gfc_add_modify (&se->pre, temp_var, se->expr);
  se->expr = temp_var;

in gfc_conv_intrinsic_loc, I see

FAIL: gfortran.dg/loc_1.f90   -O*  (test for excess errors)

due to

% gfc /opt/gcc/_clean/gcc/testsuite/gfortran.dg/loc_1.f90
Undefined symbols for architecture x86_64:
  "_targ.3866", referenced from:
  lC0 in ccakGHjX.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status

[Bug debug/89463] debug information for iteractor of an empty loop is gone (at -O3)

[qrzhang at gatech dot edu]

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

--- Comment #5 from Qirun Zhang  ---
(In reply to Qirun Zhang from comment #4)
> Bisect points to r151362.
> 
> commit ff79704e04af919c4fe501c7dceca8b21cced614
> Author: aoliva 
> Date:   Thu Sep 3 05:24:57 2009 +
> 
> * toplev.c (process_options): Enable var-tracking-assignments
> by default if var-tracking is enabled.
> 
> 
> git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@151362
> 138bc75d-0d04-0410-961f-82ee72b054a4

Sorry... Please discard this comment. This was meant for another bug. Let me
post the bisect result in the following comment..

[Bug debug/89463] debug information for iteractor of an empty loop is gone (at -O3)

[qrzhang at gatech dot edu]

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

--- Comment #6 from Qirun Zhang  ---
As mentioned in my earlier comment, the revision should be between gcc-5 and
gcc-6.

Bisect points to r239357.


commit ec969ce4161538b561592a032eca6dcfaf513596
Author: rguenth 
Date:   Thu Aug 11 09:02:04 2016 +

2016-08-11  Richard Biener  

PR tree-optimization/72772
* cfgloopmanip.c (create_preheader): Use split_edge if there
is a single loop entry, avoiding degenerate PHIs.

* gcc.dg/graphite/pr35356-1.c: Adjust.
* gcc.dg/tree-ssa/pr59597.c: Likewise.


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@239357
138bc75d-0d04-0410-961f-82ee72b054a4

[Bug c++/89767] [8/9 Regression] ICE with tuple and optimization

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Author: jakub
Date: Thu Mar 21 22:01:02 2019
New Revision: 269860

URL: https://gcc.gnu.org/viewcvs?rev=269860&root=gcc&view=rev
Log:
PR c++/89767
* parser.c (cp_parser_lambda_introducer): Add ids and first_capture_id
variables, check for duplicates in this function.
* lambda.c (add_capture): Don't check for duplicates nor use
IDENTIFIER_MARKED.
(register_capture_members): Don't clear IDENTIFIER_MARKED here.

* g++.dg/cpp1y/lambda-init18.C: New test.
* g++.dg/cpp1y/lambda-init19.C: New test.
* g++.dg/cpp1y/pr89767.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/lambda-init18.C
trunk/gcc/testsuite/g++.dg/cpp1y/lambda-init19.C
trunk/gcc/testsuite/g++.dg/cpp1y/pr89767.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/lambda.c
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/71446] Incorrect overload resolution when using designated initializers

[jakub at gcc dot gnu.org]

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

--- Comment #21 from Jakub Jelinek  ---
Author: jakub
Date: Thu Mar 21 22:03:07 2019
New Revision: 269861

URL: https://gcc.gnu.org/viewcvs?rev=269861&root=gcc&view=rev
Log:
PR c++/71446
* call.c (filed_in_pset): Change pset from hash_set * to
hash_set &, adjust uses accordingly.
(build_aggr_conv): Change pset from hash_set *
to hash_set.  Replace goto fail; with return NULL;,
adjust pset uses.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c

[Bug lto/89692] [9 Regression] ICE in streamer_write_chain, at tree-streamer-out.c:506

[jakub at gcc dot gnu.org]

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

--- Comment #16 from Jakub Jelinek  ---
Author: jakub
Date: Thu Mar 21 22:04:29 2019
New Revision: 269862

URL: https://gcc.gnu.org/viewcvs?rev=269862&root=gcc&view=rev
Log:
PR lto/89692
* tree.c (fld_type_variant, fld_incomplete_type_of,
fld_process_array_type): Call fld->pset.add and don't call
add_tree_to_fld_list if it returns true.
(free_lang_data_in_type): Similarly with self-recursive call.  Purge
non-marked types from TYPE_NEXT_VARIANT list.
(find_decls_types_r): Call fld_worklist_push for TYPE_CANONICAL (t).

* g++.dg/other/pr89692.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/other/pr89692.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree.c

[Bug lto/89692] [9 Regression] ICE in streamer_write_chain, at tree-streamer-out.c:506

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug driver/87769] GCC build from source uses headers and libraries from directories host machine.

[mte.zych at gmail dot com]

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

--- Comment #9 from Mateusz Zych  ---
Hi ;)

I've analysed this issue further and
tested all combinations of different vendors in host and target triplets.

Here are the results:
 +---+
 |   host|
 |---|
 |    |  glibc |unknown |   pc   |
++---+
|   |    |  FAIL  |  PASS  |  PASS  |  FAIL  |
| t ||||||
| a |  glibc |  PASS  |  FAIL  |  PASS  |  PASS  |
| r ||||||
| g |unknown |  PASS  |  PASS  |  FAIL  |  PASS  |
| e ||||||
| t |   pc   |  FAIL  |  PASS  |  PASS  |  FAIL  |
++---+

Looks like building isolated compiler (target == host) doesn't work at all
and for some reason cross-compiling by combining no vendor with pc vendor fails
as well.

Note that, all failing configurations are encountering the same issue
with compilation of libstdc++-v3 during first GCC build:

  checking whether the 
  /home/mzych/Downloads/build-many-glibcs/gcc-first-build/./gcc/xgcc 
  -B/home/mzych/Downloads/build-many-glibcs/gcc-first-build/./gcc/ 
  -B/home/mzych/Downloads/build-many-glibcs/gcc/x86_64-pc-linux-gnu/bin/ 
  -B/home/mzych/Downloads/build-many-glibcs/gcc/x86_64-pc-linux-gnu/lib/ 
  -isystem
/home/mzych/Downloads/build-many-glibcs/gcc/x86_64-pc-linux-gnu/include 
  -isystem
/home/mzych/Downloads/build-many-glibcs/gcc/x86_64-pc-linux-gnu/sys-include
  linker
(/home/mzych/Downloads/build-many-glibcs/gcc-first-build/./gcc/collect-ld -m
elf_x86_64) 
  supports shared libraries... yes
  checking dynamic linker characteristics... 
  configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES.
  Makefile:18985: recipe for target 'configure-stage1-target-libstdc++-v3'
failed

Initially I was thinking that there might be something wrong with the script,
which I've used to build GCC (CreateToolchain.sh),
but it seems unlikely, since other configurations work without any issues.

To me this looks very surprising that changing vendor in a triplet causes GCC
to fail to compile.
Can somebody help with figuring out what's going on here?

I think that the script CreateToolchain.sh could benefit the whole GCC
community,
because developers could use it to compile GCC by simply choosing desired
configuration.

Thank you, Mateusz

[Bug driver/87769] GCC build from source uses headers and libraries from directories host machine.

[mte.zych at gmail dot com]

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

--- Comment #10 from Mateusz Zych  ---
Created attachment 46005
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46005&action=edit
Build log of first GCC, ending on compilation failure of libstdc++-v3.

[Bug driver/87769] GCC build from source uses headers and libraries from directories host machine.

[mte.zych at gmail dot com]

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

--- Comment #11 from Mateusz Zych  ---
Oh, I forgot to mention that I've also tested this configuration:

HOST=x86_64-abc-linux-gnu
TARGET=x86_64-xyz-linux-gnu

and it worked without any issues.

I don't understand why would these configurations fail:

   HOST   = x86_64-linux-gnu
   TARGET = x86_64-pc-linux-gnu

   HOST   = x86_64-pc-linux-gnu
   TARGET = x86_64-pc-linux-gnu

yet such a fabricated configuration works.
This is really confusing. @.@

Best regards, Mateusz

[Bug target/89784] Missing AVX512 intrinsics

[crazylht at gmail dot com]

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

--- Comment #5 from Hongtao.liu  ---
(In reply to Jakub Jelinek from comment #4)
> Created attachment 46004 [details]
> gcc9-pr89784.patch
> 
> Untested patch, so far without testsuite coverage.

I'll do the test.

[Bug rtl-optimization/85412] [8/9 Regression] ICE in put_TImodes, at sel-sched.c:7191

[asolokha at gmx dot com]

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

--- Comment #13 from Arseny Solokha  ---
The patch in comment 8 fixes testcases from both comment 9 and comment 12 for
me.

[Bug debug/89792] New: gcc generates wrong debug information at -O3

[qrzhang at gatech dot edu]

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

Bug ID: 89792
   Summary: gcc generates wrong debug information at -O3
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: qrzhang at gatech dot edu
  Target Milestone: ---

It affects gcc-8 and gcc-trunk. gcc-7 works fine.

The testcase looks similar to Bug 89463. But they affect different gcc versions
and bisect points to different revisions. It would be helpful to have them
fixed.

For this bug, bisect points to r255569.



$ cat abc.c
volatile int a, b;
static int c;
int main() {
  int i;
  b = 0;
  i = 0;
  for (; i < 3; i++)
a = c;
  i = 0;
  for (; i < 5; i++)
;
  optimize_me_not();
}

$ cat outer.c
void optimize_me_not() {}

$ cat cmds
b 12
r
p i
kill
q



#Correct output#
$ gcc-trunk -g  abc.c outer.c
$ gdb -x cmds -batch a.out
Breakpoint 1 at 0x400496: file abc.c, line 12.

Breakpoint 1, main () at abc.c:12
12optimize_me_not();
$1 = 5

#Wrong output#
$ gcc-trunk -g -O3 abc.c outer.c
$ gdb -x cmds -batch a.out
Breakpoint 1 at 0x4003ae: file abc.c, line 12.

Breakpoint 1, main () at abc.c:12
12optimize_me_not();
$1 = 0

[Bug debug/89792] gcc generates wrong debug information at -O3

[qrzhang at gatech dot edu]

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

--- Comment #1 from Qirun Zhang  ---
This might be a latent issue.

Attaching my gcc version:

$ gcc-trunk -v
Thread model: posix
gcc version 9.0.1 20190321 (experimental) [trunk revision 269832] (GCC)

$ gcc-7 -v
Thread model: posix
gcc version 7.4.0 (Ubuntu 7.4.0-1ubuntu1~16.04~ppa1)

$ gcc-8 -v
gcc version 8.1.0 (Ubuntu 8.1.0-5ubuntu1~16.04)

[Bug tree-optimization/88443] [meta-bug] bogus/missing -Wstringop-overflow warnings

[msebor at gcc dot gnu.org]

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

Bug 89350 Summary: [9 Regression] Wrong -Wstringop-overflow= warning since 
r261518
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89350

   What|Removed |Added

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

[Bug tree-optimization/89350] [9 Regression] Wrong -Wstringop-overflow= warning since r261518

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #12 from Martin Sebor  ---
Patch committed in r269867.

[Bug tree-optimization/89350] [9 Regression] Wrong -Wstringop-overflow= warning since r261518

[msebor at gcc dot gnu.org]

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

--- Comment #11 from Martin Sebor  ---
Author: msebor
Date: Fri Mar 22 02:58:27 2019
New Revision: 269867

URL: https://gcc.gnu.org/viewcvs?rev=269867&root=gcc&view=rev
Log:
PR tree-optimization/89350 - Wrong -Wstringop-overflow= warning since r261518

gcc/ChangeLog:

PR tree-optimization/89350
* builtins.c (compute_objsize): Also ignore offsets whose upper
bound is negative.
* gimple-ssa-warn-restrict.c (builtin_memref): Add new member.
(builtin_memref::builtin_memref): Initialize new member.
Allow EXPR to be null.
(builtin_memref::extend_offset_range): Replace local with a member.
Avoid assuming pointer offsets are unsigned.
(builtin_memref::set_base_and_offset): Determine base object
before computing offset range.
(builtin_access::builtin_access): Handle memset.
(builtin_access::generic_overlap): Replace local with a member.
(builtin_access::strcat_overlap): Same.
(builtin_access::overlap): Same.
(maybe_diag_overlap): Same.
(maybe_diag_access_bounds): Same.
(wrestrict_dom_walker::check_call): Handle memset.
(check_bounds_or_overlap): Same.

gcc/testsuite/ChangeLog:

PR tree-optimization/89350
* gcc.dg/Wstringop-overflow.c: Xfail overly ambitious tests.
* gcc.dg/Wstringop-overflow-11.c: New test.
* gcc.dg/Wstringop-overflow-12.c: New test.
* gcc.dg/pr89350.c: New test.
* gcc.dg/pr40340-1.c: Adjust expected warning.
* gcc.dg/pr40340-2.c: Same.
* gcc.dg/pr40340-4.c: Same.
* gcc.dg/pr40340-5.c: Same.


Added:
trunk/gcc/testsuite/gcc.dg/Wstringop-overflow-11.c
trunk/gcc/testsuite/gcc.dg/Wstringop-overflow-12.c
trunk/gcc/testsuite/gcc.dg/pr89350.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/gimple-ssa-warn-restrict.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/Warray-bounds-40.c
trunk/gcc/testsuite/gcc.dg/Wstringop-overflow.c
trunk/gcc/testsuite/gcc.dg/pr40340-1.c
trunk/gcc/testsuite/gcc.dg/pr40340-2.c
trunk/gcc/testsuite/gcc.dg/pr40340-4.c
trunk/gcc/testsuite/gcc.dg/pr40340-5.c

[Bug c++/89793] New: Implicit conversion to std::string is ambiguous on GCC 8.2 but not GCC 7.3

[duyang.seu at gmail dot com]

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

Bug ID: 89793
   Summary: Implicit conversion to std::string is ambiguous on GCC
8.2 but not GCC 7.3
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: duyang.seu at gmail dot com
  Target Milestone: ---

Created attachment 46006
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46006&action=edit
the preprocessed file

GCC Version:
gcc version 8.2.1 20180905 (Red Hat 8.2.1-3) (GCC) 

System Type:
CentOS Linux release 7.5.1804 (Core) 

GCC Configured options:
COLLECT_LTO_WRAPPER=/opt/rh/devtoolset-8/root/usr/libexec/gcc/x86_64-redhat-linux/8/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,lto --prefix=/opt/rh/devtoolset-8/root/usr
--mandir=/opt/rh/devtoolset-8/root/usr/share/man
--infodir=/opt/rh/devtoolset-8/root/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --with-linker-hash-style=gnu
--with-default-libstdcxx-abi=gcc4-compatible --enable-plugin
--enable-initfini-array
--with-isl=/builddir/build/BUILD/gcc-8.2.1-20180905/obj-x86_64-redhat-linux/isl-install
--disable-libmpx --enable-gnu-indirect-function --with-tune=generic
--with-arch_32=x86-64 --build=x86_64-redhat-linux
Thread model: posix

Compilation errors:

message.cpp: In instantiation of ‘Message::Message(String&&) [with String =
StringType]’:
/opt/rh/devtoolset-8/root/usr/include/c++/8/ext/new_allocator.h:136:4:  
required from ‘void __gnu_cxx::new_allocator<_Tp>::construct(_Up*, _Args&& ...)
[with _Up = Message; _Args =
 {StringType}; _Tp = Message]’
/opt/rh/devtoolset-8/root/usr/include/c++/8/bits/alloc_traits.h:475:4:  
required from ‘static void std::allocator_traits
>::construct(std::allocator_traits >::allocator_type&, _Up*, _Args&& ...) [with _Up =
Message; _Args = {StringType}; _Tp = Message;
std::allocator_traits >::allocator_type
 = std::allocator]’
/opt/rh/devtoolset-8/root/usr/include/c++/8/bits/shared_ptr_base.h:543:39:  
required from ‘std::_Sp_counted_ptr_inplace<_Tp, _Alloc,
_Lp>::_Sp_counted_ptr_inplace(_Alloc, _Args&& .
..) [with _Args = {StringType}; _Tp = Message; _Alloc =
std::allocator; __gnu_cxx::_Lock_policy _Lp =
(__gnu_cxx::_Lock_policy)2]’
/opt/rh/devtoolset-8/root/usr/include/c++/8/bits/shared_ptr_base.h:656:4:  
required from
‘std::__shared_count<_Lp>::__shared_count(std::_Sp_make_shared_tag, _Tp*, const
_Alloc&, _A
rgs&& ...) [with _Tp = Message; _Alloc = std::allocator; _Args =
{StringType}; __gnu_cxx::_Lock_policy _Lp = (__gnu_cxx::_Lock_policy)2]’
/opt/rh/devtoolset-8/root/usr/include/c++/8/bits/shared_ptr_base.h:1322:35:  
required from ‘std::__shared_ptr<_Tp,
_Lp>::__shared_ptr(std::_Sp_make_shared_tag, const _Alloc&, _Args
&& ...) [with _Alloc = std::allocator; _Args = {StringType}; _Tp =
Message; __gnu_cxx::_Lock_policy _Lp = (__gnu_cxx::_Lock_policy)2]’
/opt/rh/devtoolset-8/root/usr/include/c++/8/bits/shared_ptr.h:360:64:  
required from ‘std::shared_ptr<_Tp>::shared_ptr(std::_Sp_make_shared_tag, const
_Alloc&, _Args&& ...) [with _
Alloc = std::allocator; _Args = {StringType}; _Tp = Message]’
/opt/rh/devtoolset-8/root/usr/include/c++/8/bits/shared_ptr.h:706:14:  
required from ‘std::shared_ptr<_Tp> std::allocate_shared(const _Alloc&, _Args&&
...) [with _Tp = Message; _Al
loc = std::allocator; _Args = {StringType}]’
/opt/rh/devtoolset-8/root/usr/include/c++/8/bits/shared_ptr.h:722:39:  
required from ‘std::shared_ptr<_Tp> std::make_shared(_Args&& ...) [with _Tp =
Message; _Args = {StringType}]’
message.cpp:77:44:   required from ‘void Queue::EnqueueImpl(T1&&, const
Queue::Type&) [with T1 = StringType; T2 = StringType; M = Message]’
message.cpp:63:5:   required from ‘void Queue::Enqueue(T&&) [with T =
StringType; M = Message]’
message.cpp:86:29:   required from here
message.cpp:47:60: error: call of overloaded ‘basic_string()’ is ambiguous
   Message(String&& data) : data_{std::forward(data)} {}
^
In file included from /opt/rh/devtoolset-8/root/usr/include/c++/8/string:52,
 from /usr/local/include/boost/utility/string_view_fwd.hpp:21,
 from /usr/local/include/boost/utility/string_view.hpp:22,
 from /usr/local/include/boost/beast/core/string.hpp:19,
 from /usr/local/include/boost/beast/core/file_base.hpp:14,
 from /usr/local/include/boost/beast/core/type_traits.hpp:14,
 from
/usr/local/include/boost/beast/http/basic_dynamic_body.hpp:14,
 from /usr/local/in

[Bug bootstrap/19852] Segmentation fault during: build/genmodes -h > tmp-modes.h

[yjf.victor at foxmail dot com]

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

yjf.victor at foxmail dot com changed:

   What|Removed |Added

 CC||yjf.victor at foxmail dot com

--- Comment #4 from yjf.victor at foxmail dot com ---
I have the same problem.

```
make[3]: Entering directory '/dev/fs/E/22/gcc/bindir/gcc'
build/genmodes -h > tmp-modes.h
Memory fault (core dumped)
make[3]: *** [Makefile:2206: s-modes-h] Error 139
make[3]: Leaving directory '/dev/fs/E/22/gcc/bindir/gcc'
make[2]: *** [Makefile:4369: all-stage1-gcc] Error 2
make[2]: Leaving directory '/dev/fs/E/22/gcc/bindir'
make[1]: *** [Makefile:19210: stage1-bubble] Error 2
make[1]: Leaving directory '/dev/fs/E/22/gcc/bindir'
make: *** [Makefile:902: all] Error 2
[ -f stage_final ] || echo stage3 > stage_final
make[1]: Entering directory '/dev/fs/E/22/gcc/bindir'
make[2]: Entering directory '/dev/fs/E/22/gcc/bindir'
make[3]: Entering directory '/dev/fs/E/22/gcc/bindir'
^Cmake[3]: *** [Makefile:19168: stage1-end] Interrupt
make[2]: *** [Makefile:19125: stage1-start] Error 130
make[1]: *** [Makefile:19210: stage1-bubble] Error 130
make: *** [Makefile:902: all] Error 130
```