[Bug fortran/78387] OpenMP segfault/stack size exceeded writing to internal file

[wilson at gcc dot gnu.org]

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

--- Comment #10 from Jim Wilson  ---
newunit_stack needs to be allocated dynamically, just like the newunits array.

I modified libgfortran to compute the highest value of newunit_tos, and print
it when the program exits.  I set NEWUNIT_STACK_SIZE to 128 so I could go up to
128 threads.

weathertop:2188$ OMP_NUM_THREADS=8 ./a.out 2> /dev/null
newunit_tos_max = 8
weathertop:2188$ OMP_NUM_THREADS=16 ./a.out 2> /dev/null
newunit_tos_max = 16
weathertop:2189$ OMP_NUM_THREADS=32 ./a.out 2> /dev/null
newunit_tos_max = 32
weathertop:2190$ OMP_NUM_THREADS=64 ./a.out 2> /dev/null
newunit_tos_max = 64
weathertop:2191$ OMP_NUM_THREADS=128 ./a.out 2> /dev/null
newunit_tos_max = 128
Segmentation fault (core dumped)
weathertop:2192$

So the size of newunit stack depends on the number of threads, and can be any
number.  If you don't want to put a hard limit of the number of threads that
gfortran can support, then you need to dynamically allocate it.

There is some variation from one run to the next, so using 16 threads doesn't
guarantee failure, and using 8 threads doesn't guarantee success.

weathertop:2192$ OMP_NUM_THREADS=8 ./a.out 2> /dev/null
newunit_tos_max = 8
weathertop:2193$ OMP_NUM_THREADS=8 ./a.out 2> /dev/null
newunit_tos_max = 8
weathertop:2193$ OMP_NUM_THREADS=8 ./a.out 2> /dev/null
newunit_tos_max = 8
weathertop:2193$ OMP_NUM_THREADS=8 ./a.out 2> /dev/null
newunit_tos_max = 8
weathertop:2193$ OMP_NUM_THREADS=8 ./a.out 2> /dev/null
newunit_tos_max = 3
weathertop:2193$ OMP_NUM_THREADS=8 ./a.out 2> /dev/null
newunit_tos_max = 8
weathertop:2193$ OMP_NUM_THREADS=8 ./a.out 2> /dev/null
newunit_tos_max = 5
weathertop:2193$ OMP_NUM_THREADS=8 ./a.out 2> /dev/null
newunit_tos_max = 8
weathertop:2193$ OMP_NUM_THREADS=8 ./a.out 2> /dev/null
newunit_tos_max = 8
weathertop:2193$

[Bug middle-end/81172] Expected new warning option -Warray-bounds-pointer-arithmetic

[ryxi at stu dot xidian.edu.cn]

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

--- Comment #5 from Xi Ruoyao  ---
(In reply to Martin Sebor from comment #4)

> Clang diagnoses the the cases where the offset or index is a constant
> expression (and under the expected option) but it doesn't diagnose others
> where the offset/index value is not a constant expression but can be
> determined to be out of bounds by VRP, for instance.  GCC can do better, but
> it may not be able to distinguish between the two kinds of warnings outside
> the front end.

I'm aware that GCC C/C++ FE convert a[x] to *(a+x) very early.  But now it's
very strange - why GCC -Warray-bounds doesn't warn for pointer arithmetics?

[Bug c++/81270] New: [concepts] ill-formed code with a constrained variable declaration with multiple declarators with different deduced types not rejected

[tom at honermann dot net]

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

Bug ID: 81270
   Summary: [concepts] ill-formed code with a constrained variable
declaration with multiple declarators with different
deduced types not rejected
   Product: gcc
   Version: c++-concepts
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org
  Target Milestone: ---

The Concepts TS (N4674) updates § 10.1.7.4 [dcl.spec.auto] paragraph 9
(paragraph 7 in the current WP) to state:

> If the init-declarator-list contains more than one init-declarator, they
> shall all form declarations of variables. The type of each declared
> variable is determined by placeholder type deduction (10.1.7.4.1), and if
> the type that replaces the declared variable type or return type is not
> the same in each deduction, the program is ill-formed.

gcc 7.1.0 fails to diagnose the following code that is ill-formed due to a
different type being deduced for each of the v1 and v2 declarators:

$ cat t.cpp 
template concept bool C = true;
C v1 = 1, v2 = nullptr;  // Ill-formed.
// Following code to demonstrate that the types of v1 and v2 are deduced
// to different types.
template struct is_same {
  static constexpr bool value = false;
};
template struct is_same {
  static constexpr bool value = true;
};
static_assert(is_same::value);
static_assert(is_same::value);

$ g++ --version
g++ (GCC) 7.1.0
...

$ g++ -c -fconcepts t.cpp


The expectation is that gcc reject the above code as it does if the declared
variable type C is replaced with auto:

$ cat t2.cpp 
auto v1 = 1, v2 = nullptr;

$ g++ -c -fconcepts t2.cpp
t2.cpp:1:1: error: inconsistent deduction for ‘auto’: ‘int’ and then
‘std::nullptr_t’
 auto v1 = 1, v2 = nullptr;
 ^~~~

[Bug fortran/78387] OpenMP segfault/stack size exceeded writing to internal file

[dominiq at lps dot ens.fr]

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

--- Comment #9 from Dominique d'Humieres  ---
Related to pr81195 and pr81241? Works on darwin with 8 threads.

[Bug fortran/78387] OpenMP segfault/stack size exceeded writing to internal file

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #8 from Jerry DeLisle  ---
(In reply to Jim Wilson from comment #7)
--- snip ---
> 
> However, for stash_internal_unit, we have as global definitions
>   #define NEWUNIT_STACK_SIZE 16
>   static gfc_saved_unit newunit_stack[NEWUNIT_STACK_SIZE];
> and inside the function we have
>   if (newunit_tos >= NEWUNIT_STACK_SIZE)

That size is fairly arbitrary. Short term we can bump this limit up to some
higher value. Longer term, I wonder if this needs to be more dynamic.  I will
get on it.

[Bug c++/45976] optional template keyword is not accepted by g++

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #3 from Jason Merrill  ---
That template keyword is not allowed in a declarator-id, but I've fixed GCC 8
to accept it with a pedwarn.

[Bug c++/54769] [Core/1111] dependent class method template not found if structure template with the same name is visible

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|8.0 |7.2

--- Comment #10 from Jason Merrill  ---
The fix for 81257 made me more comfortable with backporting this to 7.

[Bug c++/54769] [Core/1111] dependent class method template not found if structure template with the same name is visible

[jason at gcc dot gnu.org]

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

--- Comment #9 from Jason Merrill  ---
Author: jason
Date: Fri Jun 30 22:20:22 2017
New Revision: 249857

URL: https://gcc.gnu.org/viewcvs?rev=249857=gcc=rev
Log:
PR c++/54769 - wrong lookup of dependent template-name.

PR c++/81257 - ICE with invalid ::template.
* parser.c (cp_parser_template_name): Handle dependent object type.
(cp_parser_nested_name_specifier_opt): Make template_keyword_p a
parameter.
(cp_parser_id_expression): Pass it.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/parse/template-keyword1.C
branches/gcc-7-branch/gcc/testsuite/g++.dg/template/lookup11.C
Modified:
branches/gcc-7-branch/gcc/cp/ChangeLog
branches/gcc-7-branch/gcc/cp/parser.c

[Bug c++/81257] [8 Regression] ICE on invalid C++ template code: in make_typename_type, at cp/decl.c:3709

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Fri Jun 30 22:20:22 2017
New Revision: 249857

URL: https://gcc.gnu.org/viewcvs?rev=249857=gcc=rev
Log:
PR c++/54769 - wrong lookup of dependent template-name.

PR c++/81257 - ICE with invalid ::template.
* parser.c (cp_parser_template_name): Handle dependent object type.
(cp_parser_nested_name_specifier_opt): Make template_keyword_p a
parameter.
(cp_parser_id_expression): Pass it.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/parse/template-keyword1.C
branches/gcc-7-branch/gcc/testsuite/g++.dg/template/lookup11.C
Modified:
branches/gcc-7-branch/gcc/cp/ChangeLog
branches/gcc-7-branch/gcc/cp/parser.c

[Bug c++/81257] [8 Regression] ICE on invalid C++ template code: in make_typename_type, at cp/decl.c:3709

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
   Target Milestone|--- |8.0

--- Comment #3 from Jason Merrill  ---
Fixed.

[Bug ipa/81261] [8 Regression] ICE with -fno-guess-branch-probability

[hubicka at gcc dot gnu.org]

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

--- Comment #2 from Jan Hubicka  ---
Author: hubicka
Date: Fri Jun 30 21:09:13 2017
New Revision: 249856

URL: https://gcc.gnu.org/viewcvs?rev=249856=gcc=rev
Log:

PR ipa/81261
* tree-inline.c (expand_call_inline): Combine profile statuses.

Added:
trunk/gcc/testsuite/g++.dg/ipa/pr81261.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-inline.c

[Bug c++/54769] [Core/1111] dependent class method template not found if structure template with the same name is visible

[jason at gcc dot gnu.org]

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

--- Comment #8 from Jason Merrill  ---
Author: jason
Date: Fri Jun 30 21:08:53 2017
New Revision: 249855

URL: https://gcc.gnu.org/viewcvs?rev=249855=gcc=rev
Log:
PR c++/81257 - ICE with invalid ::template.

PR c++/54769 - wrong lookup of dependent template-name.
* parser.c (cp_parser_template_name): Revert part of last change.

Added:
trunk/gcc/testsuite/g++.dg/parse/template-keyword1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c

[Bug c++/81257] [8 Regression] ICE on invalid C++ template code: in make_typename_type, at cp/decl.c:3709

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Fri Jun 30 21:08:53 2017
New Revision: 249855

URL: https://gcc.gnu.org/viewcvs?rev=249855=gcc=rev
Log:
PR c++/81257 - ICE with invalid ::template.

PR c++/54769 - wrong lookup of dependent template-name.
* parser.c (cp_parser_template_name): Revert part of last change.

Added:
trunk/gcc/testsuite/g++.dg/parse/template-keyword1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c

[Bug tree-optimization/81245] [8 Regression] ICE building calculix with -Ofast

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #11 from Andrew Pinski  ---
Forgot to put the PR # in the changelog :).

Author: pinskia
Date: Fri Jun 30 20:40:38 2017
New Revision: 249854

URL: https://gcc.gnu.org/viewcvs?rev=249854=gcc=rev
Log:
2017-06-30  Andrew Pinski  

* tree-if-conv.c (predicate_scalar_phi): Update new_stmt if
fold_stmt returned true.
2017-06-30  Andrew Pinski  

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


Added:
trunk/gcc/testsuite/gcc.dg/torture/pr81245.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-if-conv.c

[Bug c/81269] wrong color highlighting in -Wrestrict warnings

[msebor at gcc dot gnu.org]

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

--- Comment #1 from Martin Sebor  ---
Created attachment 41660
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41660=edit
Even more unusual behavior seen in my enhancement.

Attached is another screenshot, this one showing even more unusual highlighting
with my (not-yet-committed) enhancement to gimple-ssa-sprintf.c.

[Bug c/81269] New: wrong color highlighting in -Wrestrict warnings

[msebor at gcc dot gnu.org]

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

Bug ID: 81269
   Summary: wrong color highlighting in -Wrestrict warnings
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Created attachment 41659
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41659=edit
Screenshot showing unexpected colors.

While testing an enhancement to -Wrestrict for sprintf (bug 35503) I noticed
some strange effects in the current implementation of the warning.

For the test case below, the first argument caret are pink, the second green,
the third blue, and the fourth green again.

I see even more unusual behavior in my enhancement.

$ cat b.c && gcc -O2 -S -Wall -Wrestrict b.c
extern int sprintf (char* restrict, const char*, ...);

void sink (void*);

void f (void)
{
  char d[5] = "1234";
  sprintf (d, "%s %s %s", d, d, d);
  sink (d);
}

b.c: In function ‘f’:
b.c:8:12: warning: passing argument 1 to restrict-qualified parameter aliases
with arguments 3, 4, 5 [-Wrestrict]
   sprintf (d, "%s %s %s", d, d, d);
^  ~  ~  ~

[Bug target/81268] [avr] Support __gcc_isr pseudo-instruction for more efficient ISR prologues

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Target||avr
   Priority|P3  |P5
 Blocks||20296
   Assignee|unassigned at gcc dot gnu.org  |gjl at gcc dot gnu.org


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20296
[Bug 20296] Speeding up small interrupts on avr

[Bug target/81268] New: [avr] Support __gcc_isr pseudo-instruction for more efficient ISR prologues

[gjl at gcc dot gnu.org]

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

Bug ID: 81268
   Summary: [avr] Support __gcc_isr pseudo-instruction for more
efficient ISR prologues
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---

GNU assembler supports the __gcc_isr pseudo-instruction, cf.

https://sourceware.org/bugzilla/show_bug.cgi?id=21683

This can be used up reduce overhead in ISR prologues and epilogues due to GCC's
modeling of TMP_REG and ZERO_REG as fixed regs und using cc0 to model SREG.

[Bug target/68467] libgcc, compilation for target m68k-linux breaks in linux_atomic.c

[csotoalonso at gmail dot com]

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

--- Comment #18 from Carlos Soto  ---
(In reply to angelo from comment #17)
> Hi Carlos,
> 
> maybe you can try one of these 2 toolchains i prepared years ago:
> 
> http://sysam.it/toolchains.html
> 
> Regads,
> Angelo
> 

Hi angelo,
thanks for pointing that. But unfortunately those toolchain lack a sysroot so
they are not suitable for Buildroot, the tool I use to create the root fs.

So, I'm stuck for the time being...

[Bug ipa/81214] GCC target_clone support does not work for global functions with no references

[meissner at gcc dot gnu.org]

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

--- Comment #5 from Michael Meissner  ---
The change commited in svn id 249840, does fix the problem on the PowerPC. 
Thanks.

[Bug libstdc++/81263] Work around CWG issue 1558 (guarantee SFINAE when using `void_t`)

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #2 from TC  ---
This is not DR1558; the issue here is declaration matching rather than SFINAE.
Just having the two func definitions is sufficient to trigger the error:

template using void_t = void;

template * = nullptr>
void func() {}
template * = nullptr>
void func() {}

This is actually CWG 1980.

[Bug tree-optimization/58012] Gcc bootstrap failed with cloog-isl: undefined reference to std::istream::ignore(long)

[mario at emmenlauer dot de]

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

Mario Emmenlauer  changed:

   What|Removed |Added

 CC||mario at emmenlauer dot de

--- Comment #2 from Mario Emmenlauer  ---
I'm still plagued by this issue with gcc 5.4.0 and gcc 6.3.0 on CentOS 6.8 and
CentOS 7.3.1611. I tried with and without my own isl 0.18.0, no difference. Was
this never really resolved? Newest isl 0.18.0 has int.h only in the
include/deprecated/ directory, is the patch still needed?

[Bug debug/81267] Missing DW_AT_type in DW_TAG_typedef of "typedef of typedef of void"

[palves at redhat dot com]

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

--- Comment #1 from Pedro Alves  ---
xref:
 https://sourceware.org/ml/gdb-patches/2017-06/msg00827.html

[Bug tree-optimization/81162] [8 Regression] UBSAN switch triggers incorrect optimization in SLSR

[wschmidt at gcc dot gnu.org]

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

--- Comment #7 from Bill Schmidt  ---
This case comes up when we're going to replace a NEGATE_EXPR with a PLUS_EXPR
or MINUS_EXPR.  This is another case of an unprofitable replacement that should
be avoided anyway.  So I think the following fix is what we need:

Index: gcc/gimple-ssa-strength-reduction.c
===
--- gcc/gimple-ssa-strength-reduction.c (revision 249846)
+++ gcc/gimple-ssa-strength-reduction.c (working copy)
@@ -2082,13 +2082,14 @@ replace_mult_candidate (slsr_cand_t c, tree basis_
  types but allows for safe negation without twisted logic.  */
   if (wi::fits_shwi_p (bump)
   && bump.to_shwi () != HOST_WIDE_INT_MIN
-  /* It is not useful to replace casts, copies, or adds of
+  /* It is not useful to replace casts, copies, negates, or adds of
 an SSA name and a constant.  */
   && cand_code != SSA_NAME
   && !CONVERT_EXPR_CODE_P (cand_code)
   && cand_code != PLUS_EXPR
   && cand_code != POINTER_PLUS_EXPR
-  && cand_code != MINUS_EXPR)
+  && cand_code != MINUS_EXPR
+  && cand_code != NEGATE_EXPR)
 {
   enum tree_code code = PLUS_EXPR;
   tree bump_tree;

This fixes the particular test.  I have to head out on vacation now, but I will
regstrap this and submit it when I get back if there are no objections.

[Bug libstdc++/81263] Work around CWG issue 1558 (guarantee SFINAE when using `void_t`)

[webrown.cpp at gmail dot com]

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

W E Brown  changed:

   What|Removed |Added

 CC||webrown.cpp at gmail dot com

--- Comment #1 from W E Brown  ---
I have not confirmed the report but, as the originator of the void_t technique,
I do have a few comments:

a)  The cited CWG issue was resolved several years ago, and is in DR status. 
That means the exhibited code is expected to work.  If it doesn't, I consider
it a compiler issue, not a library issue.

b) Therefore, once the compiler is fixed (if necessary), ISTM there should be
no reason to use the cited alternative definition of void_t, which I first
discovered and disseminated as a temporary workaround only.  See my WG21 paper
N3911 and/or part 2 of my metaprogramming talk at CppCon 2014.

c)  FWIW, while it should work as exhibited in the report, the code does not
quite conform to the design of the detection idiom.  I prefer to write such a
2nd template parameter as a type parameter of the form
   class = void_t.

[Bug tree-optimization/81192] [8 Regression] gcc ICE at -Os on x86_64-linux-gnu: Segmentation fault

[vries at gcc dot gnu.org]

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

--- Comment #12 from Tom de Vries  ---
Currently bootstrapping and reg-testing patch series on x86_64.

[Bug tree-optimization/81192] [8 Regression] gcc ICE at -Os on x86_64-linux-gnu: Segmentation fault

[vries at gcc dot gnu.org]

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

--- Comment #11 from Tom de Vries  ---
Created attachment 41658
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41658=edit
3 - Ignore EDGE_DFS_BACK in tail-merge

This is a fix for the issue noted in comment 7: EDGE_DFS_BACK is in an
undefined state during tail-merge, but taken into account when comparing edges,
which causes missed merge opportunities in tail-merge.

This patch fixes the issue by ignoring EDGE_DFS_BACK in tail-merge.

For the example in this PR, the patch allows us to merge two latch blocks in
the same loop. Previously this merge didn't happen because one bb had
EDGE_DFS_BACK set on the back-edge, while the other one did not.

A fix for trunk only, the previous two we probably want to back-port.

[Bug target/81225] [6/7 Regression] ICE with -mavx512ifma -O3 -ffloat-store

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[6/7/8 Regression] ICE with |[6/7 Regression] ICE with
   |-mavx512ifma -O3|-mavx512ifma -O3
   |-ffloat-store   |-ffloat-store

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

[Bug tree-optimization/81192] [8 Regression] gcc ICE at -Os on x86_64-linux-gnu: Segmentation fault

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

  Attachment #41650|0   |1
is obsolete||

--- Comment #10 from Tom de Vries  ---
Created attachment 41657
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41657=edit
2 - Don't tail-merge blocks from different loops

[Bug tree-optimization/81192] [8 Regression] gcc ICE at -Os on x86_64-linux-gnu: Segmentation fault

[vries at gcc dot gnu.org]

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

--- Comment #9 from Tom de Vries  ---
Created attachment 41656
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41656=edit
1 - Fix sigsegv in find_same_succ_bb

Essentially the same as the fix in comment 3.

[Bug c++/81259] New: Class template deduction cannot work on Constructor without parameters in some cases

[webrown.cpp at gmail dot com]

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

Bug ID: 81259
   Summary: Class template deduction cannot work on Constructor
without parameters in some cases
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kmp53 at sina dot com
CC: webrown.cpp at gmail dot com
  Target Milestone: ---
CC: webrown.cpp at gmail dot com

template
class C {
public:
  void fn(){}
};
int main(int argc,char*argv[]){
  C c;//OK
  C{}.fn();//OK
  C().fn();//cannot deduce template arguments for 'C' from ()
}

[Bug fortran/81265] allocatable coarrays in submodule subroutines wrongly identified as unallocated

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-30
 CC||pault at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Confirmed with 7.1.0 and trunk (8.0) and -fcoarray=single is enough to
reproduce the problem. Note that replacing 'source=0' with e.g., 'source=42'
makes the test passes, but accessing coarray gives a segfault.

[Bug target/81266] FAIL: 30_threads/thread/native_handle/typesizes.cc execution test on darwin

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
This was previously only run for GNU/Linux, Solaris and AIX, but is now enabled
for all pthreads targets. I don't think this particular test will ever pass for
targets where is_pointer is true.

[Bug c++/81260] Error "taking address of temporary" is missing

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-30
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||5.3.0, 6.3.0, 7.1.0, 8.0

--- Comment #1 from Martin Sebor  ---
Confirmed with the smaller test case below and all of 5.x, 6.x, 7.x, and 8.0. 
The expected warning is issued when the class is empty (in g()) but not
otherwise.  Interestingly, Clang only diagnoses the first call to f() in both
functions, maybe because it "forgets" about the temporary as it passes through
the implicitly generate copy assignment operator in the second call.

$ cat t.C && gcc -S -Wall -Wextra -Wpedantic t.C
void f (void*);

struct A { A (int); };

struct B
{
  B (int);
  int i;
};

void g ()
{
  f (&(A (1)));
  f (&(A (1) = 1));
}

void h ()
{
  f (&(B (1)));
  f (&(B (1) = 1));
}

t.C: In function ‘void g()’:
t.C:13:13: error: taking address of temporary [-fpermissive]
   f (&(A (1)));
 ^
t.C:14:17: error: taking address of temporary [-fpermissive]
   f (&(A (1) = 1));
 ^
t.C: In function ‘void h()’:
t.C:19:13: error: taking address of temporary [-fpermissive]
   f (&(B (1)));
 ^

[Bug c++/80014] [6/7/8 Regression] Caret missing in error message

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #7 from David Malcolm  ---
Fixed on trunk by r249845, for gcc 8 onwards.

[Bug c++/80014] [6/7/8 Regression] Caret missing in error message

[dmalcolm at gcc dot gnu.org]

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

--- Comment #6 from David Malcolm  ---
Author: dmalcolm
Date: Fri Jun 30 15:20:55 2017
New Revision: 249845

URL: https://gcc.gnu.org/viewcvs?rev=249845=gcc=rev
Log:
Fix location of typeid() (PR c++/80014)

gcc/cp/ChangeLog:
PR c++/80014
* parser.c (cp_parser_postfix_expression): Construct a location
for typeid expressions.

gcc/testsuite/ChangeLog:
PR c++/80014
* g++.dg/plugin/diagnostic-test-expressions-1.C (std::type_info):
Add declaration.
(test_typeid): New test function.


Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/plugin/diagnostic-test-expressions-1.C

[Bug debug/81267] New: Missing DW_AT_type in DW_TAG_typedef of "typedef of typedef of void"

[palves at redhat dot com]

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

Bug ID: 81267
   Summary: Missing DW_AT_type in DW_TAG_typedef of "typedef of
typedef of void"
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: palves at redhat dot com
  Target Milestone: ---

I'm writing a GDB testcase that exercises the "whatis" command.  If passed a
type name, that command strips one, and only one, level of typedef from the
type.  The test exposed missing target type info in the case of "typedef of
typedef of void".

I.e., with:

~~~
typedef void void_typedef1;
typedef void_typedef1 void_typedef2;

void_typedef1 *void_typedef1_ptr; // just to be sure the types are emitted.
void_typedef2 *void_typedef2_ptr; // ditto.
~~~

We get:

 <1><21>: Abbrev Number: 2 (DW_TAG_typedef)
<22>   DW_AT_name: (indirect string, offset: 0x1bf): void_typedef1
<26>   DW_AT_decl_file   : 1
<27>   DW_AT_decl_line   : 1
 <1><28>: Abbrev Number: 2 (DW_TAG_typedef)
<29>   DW_AT_name: (indirect string, offset: 0x1cd): void_typedef2
<2d>   DW_AT_decl_file   : 1
<2e>   DW_AT_decl_line   : 2

Notice that "void_typedef2" has no DW_AT_type pointing to "void_typedef1".
Seeing this, GDB assumes that "void_typedef2" is a direct typedef to "void":

 (gdb) whatis void_typedef1
 type = void
 (gdb) whatis void_typedef2
 type = void

The correct output in the second case above would have been:

 (gdb) whatis void_typedef2
 type = void_typedef1

... which is what I get if I compile the testcase with clang instead of gcc.  

clang (3.7) outputs:

 <1><44>: Abbrev Number: 4 (DW_TAG_typedef)
<45>   DW_AT_name: (indirect string, offset: 0x5e): void_typedef1
<49>   DW_AT_decl_file   : 1
<4a>   DW_AT_decl_line   : 1
...
 <1><65>: Abbrev Number: 5 (DW_TAG_typedef)
<66>   DW_AT_type: <0x44>
<6a>   DW_AT_name: (indirect string, offset: 0x7e): void_typedef2
<6e>   DW_AT_decl_file   : 1
<6f>   DW_AT_decl_line   : 2

I.e., it only "optimizes out" DW_AT_type when the typedef is a direct typedef
to void.

[Bug target/81266] New: FAIL: 30_threads/thread/native_handle/typesizes.cc execution test on darwin

[dominiq at lps dot ens.fr]

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

Bug ID: 81266
   Summary: FAIL: 30_threads/thread/native_handle/typesizes.cc
execution test on darwin
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
CC: iains at gcc dot gnu.org, redi at gcc dot gnu.org, ro at 
gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-apple-darwin16
Target: x86_64-apple-darwin16
 Build: x86_64-apple-darwin16

After revision r249217 the test 30_threads/thread/native_handle/typesizes.cc
fails at run time on darwin with (it was UNSUPPORTED before this revision)

terminate called after throwing an instance of 'std::runtime_error'
  what():
size of _Tp: 4
alignment of _Tp: 4
size of *(_Tp::native_handle_type): 4096
alignment of *(_Tp::native_handle_type): 4096

[Bug middle-end/81172] Expected new warning option -Warray-bounds-pointer-arithmetic

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-30
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Martin Sebor  ---
Confirmed.  There are a few bug reports for missing -Warray-bounds warning that
might be worth reviewing as well (e.g., pr67872).

I'm not sure distinguishing between forming an out-of-bounds pointer by (a + 5)
vs dereferencing a past-the-end element by a[5] is necessary or even a good
idea.  My concern with having distinct options for such closely related
problems is that it might be tricky to get their interaction right in cases
like (a + N) and [N]: should that trigger -Warray-bounds or
-Warray-bounds-pointer-arithmetic, what about when N is not a constant
expression?

Clang diagnoses the the cases where the offset or index is a constant
expression (and under the expected option) but it doesn't diagnose others where
the offset/index value is not a constant expression but can be determined to be
out of bounds by VRP, for instance.  GCC can do better, but it may not be able
to distinguish between the two kinds of warnings outside the front end.

[Bug target/81225] [6/7/8 Regression] ICE with -mavx512ifma -O3 -ffloat-store

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Fri Jun 30 14:52:24 2017
New Revision: 249844

URL: https://gcc.gnu.org/viewcvs?rev=249844=gcc=rev
Log:
PR target/81225
* config/i386/sse.md (vec_extract_lo_): For
V8FI, V16FI and VI8F_256 iterators, use  instead
of nonimmediate_operand and  instead of m for
the input operand.  For V8FI iterator, always split if input is a MEM.
For V16FI and V8SF_256 iterators, don't test if both operands are MEM
if .  For VI4F_256 iterator, use 
instead of register_operand and  instead of v
for
the input operand.  Make sure both operands aren't MEMs for if not
.

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

Added:
trunk/gcc/testsuite/gcc.target/i386/pr81225.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/sse.md
trunk/gcc/testsuite/ChangeLog

[Bug c++/55203] No unused warning for variables of non-trivial types

[msebor at gcc dot gnu.org]

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

--- Comment #20 from Martin Sebor  ---
*** Bug 81250 has been marked as a duplicate of this bug. ***

[Bug c++/81250] C++ warnings about unused stl

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #7 from Martin Sebor  ---
Resolving as a dupe of 55203 per comment #6.

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

[Bug fortran/81265] allocatable coarrays in submodule subroutines wrongly identified as unallocated

[mexas at bristol dot ac.uk]

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

--- Comment #1 from Anton Shterenlikht  ---
On Cray seems to run fine too.

Sorry for crooked rushed English.
The code itself is very simple, so
should be clear what's going on.
But I think if I put all code in a single
file, then I cannot reproduce the error anymore.

Thanks!

[Bug fortran/81265] New: allocatable coarrays in submodule subroutines wrongly identified as unallocated

[mexas at bristol dot ac.uk]

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

Bug ID: 81265
   Summary: allocatable coarrays in submodule subroutines wrongly
identified as unallocated
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mexas at bristol dot ac.uk
  Target Milestone: ---

Created attachment 41655
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41655=edit
m.f90 sm.f90 m2.f90 p.f90 - 4 Fortran 2008 files

Sorry I cannot yet reduce this further.

m.f90 - module 1
sm.f90 - submodule of module 1
m2.f90 - module 2
p.f90 - program that uses both modules: m and m2.

submodule sm has subroutine s, which is passed as
one actual argument subroutine s2 from module m2.

An allocatable coarray is allocated in the program p.
Then subroutine s is called with s2 passed in.
In s the allocatable coarray is seen as allocated,
but when it is passed further to s2 from 2, in s2
it is seen as not allocated.

To build/run:

rat> caf -c m.f90 m2.f90 sm.f90 p.f90
rat> caf p.o m.o m2.o sm.o
rat> cafrun -np 4 ./a.out
ERROR: s2: coarray is not allocated
ERROR: s2: coarray is not allocated
ERROR: s2: coarray is not allocated
ERROR: s2: coarray is not allocated
ERROR STOP 
ERROR STOP 
ERROR STOP 
rat> 


rat> caf --version

OpenCoarrays Coarray Fortran Compiler Wrapper (caf version 1.9.0)
Copyright (C) 2015-2016 Sourcery, Inc.

OpenCoarrays comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of OpenCoarrays under the terms of the
BSD 3-Clause License.  For more information about these matters, see
the file named LICENSE.

rat> caf -w
caf wraps CAFC=/usr/local/bin/mpif90
rat> mpif90 --version
GNU Fortran (FreeBSD Ports Collection) 7.0.1 20170326 (experimental)
Copyright (C) 2017 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.

Shall I send this to OpenCoarrays instead?

ifort 16 runs this program with no error.

[Bug ipa/81214] GCC target_clone support does not work for global functions with no references

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Known to work||8.0
  Known to fail||5.4.0, 6.3.0, 7.1.0

--- Comment #4 from Martin Liška  ---
Fixed on trunk so far, I'll try to do a back-port.

[Bug ipa/81214] GCC target_clone support does not work for global functions with no references

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Author: marxin
Date: Fri Jun 30 13:51:19 2017
New Revision: 249840

URL: https://gcc.gnu.org/viewcvs?rev=249840=gcc=rev
Log:
Fix removal of ifunc (PR ipa/81214).

2017-06-30  Martin Liska  

PR ipa/81214
* gcc.target/i386/pr81214.c: New test.
2017-06-30  Martin Liska  

PR ipa/81214
* multiple_target.c (create_dispatcher_calls): Make ifunc
also for function that don't have calls or are not referenced.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr81214.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/multiple_target.c
trunk/gcc/testsuite/ChangeLog

[Bug c/81264] New: fixincludes/fixincl.c fails on DEBUG build

[mario at emmenlauer dot de]

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

Bug ID: 81264
   Summary: fixincludes/fixincl.c fails on DEBUG build
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mario at emmenlauer dot de
  Target Milestone: ---

fixincludes/fixincl.c reads in line 1123:
  fprintf (stderr, z_failed, _ttyp, p_fixd->fix_name,   \
   pz_fname, p_fixd->test_ct - test_ct);

The variable z_failed is undefined.

This is not a critical issue as it only appears if DEBUG is defined.
But AFAIK its still a bug, so I wanted to report it.

[Bug target/80510] Optimize Power7/power8 Altivec load/stores

[meissner at gcc dot gnu.org]

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

--- Comment #10 from Michael Meissner  ---
Author: meissner
Date: Fri Jun 30 12:09:12 2017
New Revision: 249836

URL: https://gcc.gnu.org/viewcvs?rev=249836=gcc=rev
Log:
[gcc]
2017-06-30  Michael Meissner  

Backport from mainline
2017-06-23  Michael Meissner  

PR target/80510
* config/rs6000/rs6000.md (ALTIVEC_DFORM): Do not allow DImode in
32-bit, since indexed is not valid for DImode.
(mov_hardfloat32): Reorder ISA 2.07 load/stores before ISA
3.0 d-form load/stores to be the same as mov_hardfloat64.
(define_peephole2 for Altivec d-form load): Add 32-bit support.
(define_peephole2 for Altivec d-form store): Likewise.

[gcc/testsuite]
2017-06-30  Michael Meissner  

Backport from mainline
2017-06-23  Michael Meissner  

PR target/80510
* gcc.target/powerpc/pr80510-1.c: Allow test to run on 32-bit.
* gcc.target/powerpc/pr80510-2.c: Likewise.


Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/rs6000/rs6000.md
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/pr80510-1.c
branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/pr80510-2.c

[Bug c++/81229] [8 Regression] ICE in c_tree_chain_next on aarch64

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #7 from Nathan Sidwell  ---
Fixed r249835.

[Bug sanitizer/81262] [8 Regression] verify_flow_info failed for asmgoto test-case with -fsanitize=undefined

[jakub at gcc dot gnu.org]

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

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

Untested fix.

[Bug c++/81229] [8 Regression] ICE in c_tree_chain_next on aarch64

[nathan at gcc dot gnu.org]

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

--- Comment #6 from Nathan Sidwell  ---
Author: nathan
Date: Fri Jun 30 11:40:08 2017
New Revision: 249835

URL: https://gcc.gnu.org/viewcvs?rev=249835=gcc=rev
Log:
PR c++/81229
* name-lookup.c (do_pushdecl): Reset IDENTIFIER_TYPE when finding
a matching TYPE_DECL.

* g++.dg/lookup/pr81229.C: New.

Added:
trunk/gcc/testsuite/g++.dg/lookup/pr81229.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/name-lookup.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/55203] No unused warning for variables of non-trivial types

[redi at gcc dot gnu.org]

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

--- Comment #19 from Jonathan Wakely  ---
cppcheck isn't a compiler, it just does simple pattern matching and maybe uses
whitelists/blacklists of types. I don't think anything it does is really
relevant to GCC.

[Bug sanitizer/81262] [8 Regression] verify_flow_info failed for asmgoto test-case with -fsanitize=undefined

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-06-30
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug sanitizer/81262] [8 Regression] verify_flow_info failed for asmgoto test-case with -fsanitize=undefined

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Bet asm goto isn't handled correctly in fix_up_fall_thru_edges or in
add_labels_and_missing_jumps.
Looking at the former, I'm puzzled how it works at all, seems e.g. the
cond_jump variable can hold edge for completely unrelated bb (isn't cleared
like e.g. fall_thru is).  I believe all the function-local vars should be moved
into the FOR_EACH_BB_FN block except for cur_bb.

[Bug ipa/80597] [8 Regression] internal compiler error: in compute_inline_parameters, at ipa-inline-analysis.c:3126

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

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

[Bug c++/54769] [Core/1111] dependent class method template not found if structure template with the same name is visible

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
If it is backported, PR81257 will need to be resolved there as well.

[Bug rtl-optimization/81020] [6/7/8 Regression] wrong code with -O -fno-tree-bit-ccp -fno-tree-coalesce-vars -fno-tree-vrp

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug c++/81258] [7/8 Regression] ICE on C++1z code with invalid decomposition declaration: in cp_finish_decl, at cp/decl.c:6760

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug c++/55203] No unused warning for variables of non-trivial types

[jg at jguk dot org]

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

Jon Grant  changed:

   What|Removed |Added

 CC||jg at jguk dot org

--- Comment #18 from Jon Grant  ---
Hello
Perhaps a derived class would do some behaviour, so better not allow
inheritance. Certainly just tagging each STL class we know doesn't construct
anything would allow identification of them.

I wonder how cppcheck does it?

Happy to pay a bounty 100 USD to get in a new release.

[Bug rtl-optimization/81020] [6/7/8 Regression] wrong code with -O -fno-tree-bit-ccp -fno-tree-coalesce-vars -fno-tree-vrp

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-30
 CC||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, started with r228320. Richi, can you please take a look?

[Bug sanitizer/81262] [8 Regression] verify_flow_info failed for asmgoto test-case with -fsanitize=undefined

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Version|7.0 |8.0
   Target Milestone|--- |8.0

[Bug ipa/81261] [8 Regression] ICE with -fno-guess-branch-probability

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Version|7.0 |8.0
   Target Milestone|--- |8.0

[Bug sanitizer/81021] stack-use-after-scope false positive error with exceptions

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Known to work||8.0
  Known to fail||7.1.0

--- Comment #6 from Martin Liška  ---
Fixed on trunk so far.

[Bug sanitizer/81021] stack-use-after-scope false positive error with exceptions

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
Author: marxin
Date: Fri Jun 30 08:51:00 2017
New Revision: 249833

URL: https://gcc.gnu.org/viewcvs?rev=249833=gcc=rev
Log:
Call BUILT_IN_ASAN_HANDLE_NO_RETURN before BUILT_IN_UNWIND_RESUME (PR
sanitizer/81021).

2017-06-30  Martin Liska  

PR sanitizer/81021
* g++.dg/asan/pr81021.C: New test.
2017-06-30  Martin Liska  

PR sanitizer/81021
* tree-eh.c (lower_resx): Call BUILT_IN_ASAN_HANDLE_NO_RETURN
before BUILT_IN_UNWIND_RESUME when ASAN is used.

Added:
trunk/gcc/testsuite/g++.dg/asan/pr81021.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-eh.c

[Bug c++/81258] [7/8 Regression] ICE on C++1z code with invalid decomposition declaration: in cp_finish_decl, at cp/decl.c:6760

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-30
 CC||marxin at gcc dot gnu.org
Summary|ICE on C++1z code with  |[7/8 Regression] ICE on
   |invalid decomposition   |C++1z code with invalid
   |declaration: in |decomposition declaration:
   |cp_finish_decl, at  |in cp_finish_decl, at
   |cp/decl.c:6760  |cp/decl.c:6760
 Ever confirmed|0   |1

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

[Bug c++/81257] [8 Regression] ICE on invalid C++ template code: in make_typename_type, at cp/decl.c:3709

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-30
 CC||marxin at gcc dot gnu.org
Summary|ICE on invalid C++ template |[8 Regression] ICE on
   |code: in|invalid C++ template code:
   |make_typename_type, at  |in make_typename_type, at
   |cp/decl.c:3709  |cp/decl.c:3709
 Ever confirmed|0   |1

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

[Bug sanitizer/81262] New: [8 Regression] verify_flow_info failed for asmgoto test-case with -fsanitize=undefined

[marxin at gcc dot gnu.org]

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

Bug ID: 81262
   Summary: [8 Regression] verify_flow_info failed for asmgoto
test-case with -fsanitize=undefined
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
hubicka at ucw dot cz, jakub at gcc dot gnu.org, kcc at gcc 
dot gnu.org,
marxin at gcc dot gnu.org
  Target Milestone: ---

Starting from r249070, following test-case fails:

$ g++ /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/ext/asmgoto1.C
-fsanitize=unreachable -O2 -c
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/ext/asmgoto1.C: In function
‘int bar(int)’:
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/ext/asmgoto1.C:32:1: error:
fallthru edge crosses section boundary in bb 6
 }
 ^
during RTL pass: bbpart
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/ext/asmgoto1.C:32:1: internal
compiler error: verify_flow_info failed
0xc15932 verify_flow_info()
../../gcc/cfghooks.c:259
0x1089f20 execute_function_todo
../../gcc/passes.c:2001
0x1088e92 do_per_function
../../gcc/passes.c:1655
0x108a0a0 execute_todo
../../gcc/passes.c:2043

[Bug c++/55203] No unused warning for variables of non-trivial types

[glisse at gcc dot gnu.org]

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

--- Comment #17 from Marc Glisse  ---
I wonder if attributes unused / warn_unused should be automatically inherited
by classes when a member or base has it (with various rules, maybe unused has
priority over warn_unused). For a tuple of locks or a tuple of strings, that
seems to do the right thing. For a class that contains a private internal lock,
the user might need to specify warn_unused so the compiler does not guess
"unused" instead.
Even if that's currently useless, I still believe that decorating the relevant
classes (locks, etc) with attribute unused would be good (it could be used by
external tools as well).

[Bug ipa/81261] [8 Regression] ICE with -fno-guess-branch-probability

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-30
 CC||hubicka at ucw dot cz
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Commit r249800.

[Bug ipa/81261] New: [8 Regression] ICE with -fno-guess-branch-probability

[marxin at gcc dot gnu.org]

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

Bug ID: 81261
   Summary: [8 Regression] ICE with -fno-guess-branch-probability
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Probably staring from Honza's commit, I see:

$ ./xg++ -B. /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/ipa/pr61160-1.C
-O1 -fno-guess-branch-probability

/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/ipa/pr61160-1.C: In member
function ‘virtual void* CExample::_ZThn8_N8CExample9MixinFuncEiPv(int, void*)’:
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/ipa/pr61160-1.C:14:9:
internal compiler error: in to_reg_br_prob_base, at profile-count.h:189
   void *MixinFunc (int arg, void *arg2)
 ^
0xe1d414 profile_probability::to_reg_br_prob_base() const
../../gcc/profile-count.h:189
0xf9349d estimate_bb_frequencies(bool)
../../gcc/predict.c:3558
0xf94152 rebuild_frequencies()
../../gcc/predict.c:3854
0xf77694 execute_function_todo
../../gcc/passes.c:1970
0xf76750 do_per_function
../../gcc/passes.c:1655
0xf7795e execute_todo
../../gcc/passes.c:2043
0xf77edd execute_one_ipa_transform_pass
../../gcc/passes.c:2240
0xf78018 execute_all_ipa_transforms()
../../gcc/passes.c:2276
0xba0b1f cgraph_node::expand()
../../gcc/cgraphunit.c:2042
0xba22ca expand_all_functions
../../gcc/cgraphunit.c:2185
0xba22ca symbol_table::compile()
../../gcc/cgraphunit.c:2542
0xba4a16 symbol_table::compile()
../../gcc/cgraphunit.c:2635
0xba4a16 symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2632

[Bug tree-optimization/81249] [8 Regression] ICE: error: incompatible types in PHI argument 0

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/81249] [8 Regression] ICE: error: incompatible types in PHI argument 0

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Author: rguenth
Date: Fri Jun 30 08:08:33 2017
New Revision: 249831

URL: https://gcc.gnu.org/viewcvs?rev=249831=gcc=rev
Log:
2017-06-30  Richard Biener  

PR tree-optimization/81249
* tree-vect-loop.c (vect_create_epilog_for_reduction): Convert
condition reduction result to original scalar type.

* g++.dg/torture/pr81249.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr81249.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-loop.c

[Bug c++/55203] No unused warning for variables of non-trivial types

[redi at gcc dot gnu.org]

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

--- Comment #16 from Jonathan Wakely  ---
I missed this update, sorry.

(In reply to Martin Sebor from comment #15)
> Jonathan, what's the next step?  It sounds as though you don't think
> decorating nearly every libstdc++ class makes sense.

I'd really rather not do that, but we could start with std::basic_string.

> Should -Wunused be
> tweaked to diagnose unused variables of all types and let users deal with
> the fallout for RAII classes by decorating then with attribute unused?

I don't think that would be popular.

[Bug tree-optimization/81248] No ipa-sra optimization for small struct / class

[wilhelm.me...@hs-kl.de]

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

--- Comment #7 from wilhelm.me...@hs-kl.de ---
Looks like also no optimization is done for non-template function 
g(const uint8_t&).

[Bug bootstrap/81253] Flags -march and -mtune are ignored

[kidon at posteo dot de]

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

Philipp  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #6 from Philipp  ---
Yes, you are right. It is not a GNU Fortran bug; issue is resolved. Thank you
very much.

[Bug c++/81260] New: Error "taking address of temporary" is missing

[carljohnson95 at gmx dot com]

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

Bug ID: 81260
   Summary: Error "taking address of temporary" is missing
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: carljohnson95 at gmx dot com
  Target Milestone: ---

Command line:
>c++ main.cpp -std=c++14 -Wall -Wextra -Wpedantic -fno-strict-aliasing -fwrapv 
>-o 1.exe
Compiler output:

main.cpp: In function 'int main()':
main.cpp:10:22: error: taking address of temporary [-fpermissive]
   cout << (int)&((A)1) << endl; //  error: taking address of temporary

This is the code:

// BEGIN
#include 
using namespace std;

class A{public:
  A(int a){this->a = a;}
  int a;
};

int main(void){
  cout << (int)&((A)1) << endl; //  error: taking address of temporary
  cout << (int)&((A)1 = 1) << endl; // No error
}
// END

According to the specs, shouldn't the second throw an error too? (assuming that
sizeof(A*)==sizeof(int))

[Bug c++/81250] C++ warnings about unused stl

[glisse at gcc dot gnu.org]

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

--- Comment #6 from Marc Glisse  ---
See PR 55203.

[Bug ipa/81133] [8 Regression] PGO/LTO bootstrap: ICE: in inline_small_functions, at ipa-inline.c:1891

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #4 from Markus Trippelsdorf  ---
No, unfortunately it still happens. 
(I was testing with checking=release. Sorry.)