[Bug c/53037] warn_if_not_aligned(X)

[hpa at zytor dot com]

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

--- Comment #30 from H. Peter Anvin  ---
On August 18, 2017 3:52:12 PM CDT, "hjl.tools at gmail dot com"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53037
>
>--- Comment #29 from H.J. Lu  ---
>(In reply to r...@cebitec.uni-bielefeld.de from comment #28)
>> > --- Comment #27 from H.J. Lu  ---
>> 
>> > What are error messages?
>> 
>> None, the warnings are simply missing.
>> 
>>  Rainer
>
>Sparc defines STRICT_ALIGNMENT which leads to
>
>  unsigned mode_align = GET_MODE_ALIGNMENT (TYPE_MODE (type));
>
>/* Don't override a larger alignment requirement coming from a user
> alignment of one of the fields.  */
>  if (mode_align >= TYPE_ALIGN (type))
>{
>  SET_TYPE_ALIGN (type, mode_align);
>  TYPE_USER_ALIGN (type) = 0; 
>}
>
>so __attribute__ ((packed)) is basically ignored on Sparc.  This patch
>
>diff --git a/gcc/stor-layout.c b/gcc/stor-layout.c
>index 3028d55773a..6dd605810ac 100644
>--- a/gcc/stor-layout.c
>+++ b/gcc/stor-layout.c
>@@ -1784,7 +1784,7 @@ finalize_type_size (tree type)
>
>/* Don't override a larger alignment requirement coming from a user
>alignment of one of the fields.  */
>-  if (mode_align >= TYPE_ALIGN (type))
>+  if (mode_align > TYPE_ALIGN (type))
>   {
> SET_TYPE_ALIGN (type, mode_align);
> TYPE_USER_ALIGN (type) = 0;
>
>works with cross compiler.  But I have no idea if it is correct.

Ignoring __attribute__((packed)) I would consider to be a super serious error.

[Bug target/80210] ICE in in extract_insn, at recog.c:2311 on ppc64 for with __builtin_pow

[bergner at gcc dot gnu.org]

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

--- Comment #8 from Peter Bergner  ---
Fixed on trunk.  I'm testing backports to the open release branches and will
commit them after the trunk patch has aged a bit (next week?).

[Bug middle-end/64928] [5/6/7/8 Regression] Inordinate cpu time and memory usage in "phase opt and generate" with -ftest-coverage -fprofile-arcs

[lucier at math dot purdue.edu]

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

--- Comment #23 from lucier at math dot purdue.edu ---
I tried the mainline compiler with the smaller input file on a similar machine
to the one in the original report.

I don't know whether I've configured the compiler incorrectly or something, but
the problem seems worse now than when first reported.

This is the compiler:

heine:~/programs/gcc> /pkgs/gcc-mainline/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/pkgs/gcc-mainline/bin/gcc
COLLECT_LTO_WRAPPER=/pkgs/gcc-mainline/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../../gcc-mainline/configure --prefix=/pkgs/gcc-mainline
--enable-checking=release --enable-languages=c --disable-multilib
--enable-gather-detailed-mem-stats
Thread model: posix
gcc version 8.0.0 20170818 (experimental) [trunk revision 251188] (GCC) 

and this is the result: 

/pkgs/gcc-mainline/bin/gcc -Q -save-temps -Wno-unused -Wno-write-strings -O1
-fno-math-errno -fschedule-insns2 -fno-strict-aliasing -fno-trapping-math
-fwrapv -fomit-frame-pointer -fPIC -fno-common -mieee-fp -fprofile-arcs
-ftest-coverage -I"../include" -c -o "_system.o" -I. -DHAVE_CONFIG_H 
-D___PRIMAL _system.c -D___LIBRARY
Execution times (seconds)
 phase setup :   0.05 (100%) usr   0.00 ( 0%) sys   0.05 (83%) wall
   1425 kB (99%) ggc
 TOTAL :   0.05 0.00 0.06  
1434 kB
 btowc wctob mbrlen __signbitf __signbit __signbitl ___H__20___system
___H__23__23_type ___H__23__23_type_2d_cast ___H__23__23_subtype
___H__23__23_subtype_2d_set_21_ ___H__23__23_fixnum_3f_
___H__23__23_subtyped_3f_ ___H__23__23_subtyped_2d_mutable_3f_
___H__23__23_subtyped_2e_vector_3f_ ___H__23__23_subtyped_2e_symbol_3f_
___H__23__23_subtyped_2e_flonum_3f_ ___H__23__23_subtyped_2e_bignum_3f_
___H__23__23_special_3f_ ___H__23__23_ratnum_3f_ ___H__23__23_cpxnum_3f_
___H__23__23_structure_3f_ ___H__23__23_values_3f_ ___H__23__23_meroon_3f_
___H__23__23_jazz_3f_ ___H__23__23_frame_3f_ ___H__23__23_continuation_3f_
___H__23__23_promise_3f_ ___H__23__23_return_3f_ ___H__23__23_foreign_3f_
___H__23__23_flonum_3f_ ___H__23__23_bignum_3f_ ___H__23__23_unbound_3f_
___H__23__23_quasi_2d_append ___H__23__23_quasi_2d_list
___H__23__23_quasi_2d_cons ___H__23__23_quasi_2d_list_2d__3e_vector
___H__23__23_quasi_2d_vector ___H__23__23_case_2d_memv ___H__23__23_eqv_3f_
___H_eqv_3f_ ___H__23__23_eq_3f_ ___H_eq_3f_ ___H__23__23_bvector_2d_equal_3f_
___H__23__23_equal_3f_ ___H_equal_3f_ ___H__23__23_symbol_2d_hash
___H_symbol_2d_hash ___H__23__23_keyword_2d_hash ___H_keyword_2d_hash
___H__23__23_eq_3f__2d_hash ___H_eq_3f__2d_hash ___H__23__23_eqv_3f__2d_hash
___H_eqv_3f__2d_hash ___H__23__23_equal_3f__2d_hash ___H_equal_3f__2d_hash
___H__23__23_string_3d__3f__2d_hash ___H_string_3d__3f__2d_hash
___H__23__23_string_2d_ci_3d__3f__2d_hash ___H_string_2d_ci_3d__3f__2d_hash
___H__23__23_generic_2d_hash
___H__23__23_fail_2d_check_2d_invalid_2d_hash_2d_number_2d_exception
___H_invalid_2d_hash_2d_number_2d_exception_3f_
___H_invalid_2d_hash_2d_number_2d_exception_2d_procedure
___H_invalid_2d_hash_2d_number_2d_exception_2d_arguments
___H__23__23_raise_2d_invalid_2d_hash_2d_number_2d_exception
___H__23__23_fail_2d_check_2d_unbound_2d_table_2d_key_2d_exception
___H_unbound_2d_table_2d_key_2d_exception_3f_
___H_unbound_2d_table_2d_key_2d_exception_2d_procedure
___H_unbound_2d_table_2d_key_2d_exception_2d_arguments
___H__23__23_raise_2d_unbound_2d_table_2d_key_2d_exception
___H__23__23_gc_2d_hash_2d_table_3f_ ___H__23__23_gc_2d_hash_2d_table_2d_ref
___H__23__23_gc_2d_hash_2d_table_2d_set_21_
___H__23__23_gc_2d_hash_2d_table_2d_rehash_21_
___H__23__23_smallest_2d_prime_2d_no_2d_less_2d_than
___H__23__23_gc_2d_hash_2d_table_2d_resize_21_
___H__23__23_gc_2d_hash_2d_table_2d_allocate
___H__23__23_gc_2d_hash_2d_table_2d_for_2d_each
___H__23__23_gc_2d_hash_2d_table_2d_search
___H__23__23_gc_2d_hash_2d_table_2d_foldl ___H__23__23_mem_2d_allocated_3f_
___H__23__23_fail_2d_check_2d_table ___H_table_3f_ ___H__23__23_make_2d_table
___H_make_2d_table ___H__23__23_table_2d_get_2d_eq_2d_gcht
___H__23__23_table_2d_get_2d_gcht_2d_not_2d_mem_2d_alloc
___H__23__23_table_2d_get_2d_gcht ___H__23__23_table_2d_length
___H_table_2d_length ___H__23__23_table_2d_access ___H__23__23_table_2d_ref
___H_table_2d_ref ___H__23__23_table_2d_resize_21_
___H__23__23_table_2d_set_21_ ___H_table_2d_set_21_
___H__23__23_table_2d_search ___H_table_2d_search
___H__23__23_table_2d_for_2d_each ___H_table_2d_for_2d_each
___H__23__23_table_2d_foldl ___H__23__23_table_2d__3e_list
___H_table_2d__3e_list ___H__23__23_list_2d__3e_table ___H_list_2d__3e_table
___H__23__23_table_2d_copy ___H_table_2d_copy ___H__23__23_table_2d_merge_21_
___H_table_2d_merge_21_ ___H__23__23_table_2d_merge ___H_table_2d_merge
___H__23__23_table_2d_equal_3f_ ___H__23__23_table_2d_equal_3f__2d_hash
___H__23__23_fail_2d_check_2d_unbound_2d_serial

[Bug tree-optimization/46805] ICE: SIGSEGV in optab_for_tree_code (optabs.c:407) with -O -fno-tree-scev-cprop -ftree-vectorize

[dmalcolm at gcc dot gnu.org]

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

--- Comment #5 from David Malcolm  ---
Author: dmalcolm
Date: Fri Aug 18 23:56:28 2017
New Revision: 251192

URL: https://gcc.gnu.org/viewcvs?rev=251192=gcc=rev
Log:
jit: fix segfault with autovectorization (PR tree-optimization/46805)

libgccjit ran into its own version of PR tree-optimization/46805 (seen
with the Go frontend); this patch fixes it in the same way.

gcc/jit/ChangeLog:
PR tree-optimization/46805
* dummy-frontend.c (jit_langhook_parse_file): Handle vector types.

gcc/testsuite/ChangeLog:
PR tree-optimization/46805
* jit.dg/all-non-failing-tests.h: Add test-autovectorize.c.
* jit.dg/test-autovectorize.c: New test case.


Added:
trunk/gcc/testsuite/jit.dg/test-autovectorize.c
Modified:
trunk/gcc/jit/ChangeLog
trunk/gcc/jit/dummy-frontend.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/jit.dg/all-non-failing-tests.h

[Bug target/81850] [mingw/cygwin] -mabi=sysv ignored

[daniel.santos at pobox dot com]

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

--- Comment #1 from Daniel Santos  ---
I have a patch that I've tested and will be submitting it shortly (I can't
change the assigned to field yet).

[Bug target/80210] ICE in in extract_insn, at recog.c:2311 on ppc64 for with __builtin_pow

[bergner at gcc dot gnu.org]

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

--- Comment #7 from Peter Bergner  ---
Author: bergner
Date: Fri Aug 18 23:41:41 2017
New Revision: 251190

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

gcc/
PR target/80210
* config/rs6000/rs6000.c (rs6000_activate_target_options): New
function.
(rs6000_set_current_function): Rewrite function to use it.

gcc/testsuite/
PR target/80210
* gcc.target/powerpc/pr80210.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr80210.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/70879] Missed jump threading opportunity with multiple != conditions

[amacleod at redhat dot com]

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

--- Comment #5 from Andrew Macleod  ---
On 08/18/2017 06:13 PM, law at redhat dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70879
>
> Jeffrey A. Law  changed:
>
> What|Removed |Added
> 
>   Status|NEW |RESOLVED
>   Resolution|--- |FIXED
>
> --- Comment #4 from Jeffrey A. Law  ---
> This was fixed by RIchi's change for pr71433.
>
Made a bunch of updates this week, and things are in decent shape I think.

so looking at that test case with the code base as of this afternoon, if 
we expand irange to have 3 sub-ranges (which I think long term we will 
may need)

void
foo (int a)
{
   if (a != 5 && a != 10)
 bar ();
   if (a == 10)
 baz ();
}
we get gimple

 [0.00%] [count: INV]:
   _1 = a_6(D) != 5;
   _2 = a_6(D) != 10;
   _3 = _1 & _2;
   if (_3 != 0)
 goto ; [INV] [count: INV]
   else
 goto ; [INV] [count: INV]

[0.00%] [count: INV]:
   bar ();

[0.00%] [count: INV]:
   if (a_6(D) == 10)
 goto ; [INV] [count: INV]
   else
 goto ; [INV] [count: INV]

shows

BB  2:  T: _1   [0x0001, 0x0001] precision = 1
BB  2:  T: _2   [0x0001, 0x0001] precision = 1
BB  2:  T: _3   [0x, 0x] precision = 1
BB  2:  T: a_6(D)   [0x8000, 0x4][0x6, 0x9][0xb, 
0x7fff] precision = 32
BB  2:  F: _1   [0x0, 0x0001] precision = 1
BB  2:  F: _2   [0x0, 0x0001] precision = 1
BB  2:  F: _3   [0x0, 0x0] precision = 1
BB  2:  F: a_6(D)   [0x5, 0x5][0xa, 0xa] precision = 32

BB  4:  T: a_6(D)   [0xa, 0xa] precision = 32
BB  4:  F: a_6(D)   [0x8000, 0x9][0xb, 0x7fff] 
precision = 32


so the true side of bb2 shows the range of a_6 to be everything except 5 
and 10  [0x8000, 0x4][0x6, 0x9][0xb, 0x7fff] precision = 32

and the true side of bb4, leading to the call to baz(), a_6 has to have 
a value of 10.. if you intersect those 2 ranges on that path... voila!!

its a NULL range meaning that call can't happen on that path 
2->3->4->5,  letting you do your thing..

So that is promising...

Andrew

Over the weekend im going to consider options for handling an increase 
of precision in ranges without going full on dynamic.

[Bug tree-optimization/47413] Constant Propagation and Virtual Function Tables

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #4 from Jeffrey A. Law  ---
Fixed, not really sure when though:

int main() ()
{
  struct obj * obj;
  int _1;

;;   basic block 2, loop depth 0, count 0, freq 1, maybe hot
;;prev block 0, next block 3, flags: (NEW, REACHABLE, VISITED)
;;pred:   ENTRY [100.0%]  (FALLTHRU,EXECUTABLE)
  obj_5 = malloc (8);
  if (obj_5 == 0B)
goto ; [30.86%]
  else
goto ; [69.14%]
;;succ:   4 [30.9%]  (TRUE_VALUE,EXECUTABLE)
;;3 [69.1%]  (FALSE_VALUE,EXECUTABLE)

;;   basic block 3, loop depth 0, count 0, freq 6914, maybe hot
;;prev block 2, next block 4, flags: (NEW, REACHABLE, VISITED)
;;pred:   2 [69.1%]  (FALSE_VALUE,EXECUTABLE)
  printf ("%d\n", 1337);
;;succ:   4 [100.0%]  (FALLTHRU,EXECUTABLE)

;;   basic block 4, loop depth 0, count 0, freq 1, maybe hot
;;prev block 3, next block 1, flags: (NEW, REACHABLE, VISITED)
;;pred:   2 [30.9%]  (TRUE_VALUE,EXECUTABLE)
;;3 [100.0%]  (FALLTHRU,EXECUTABLE)
  # _1 = PHI <0(2), 1(3)>
  return _1;
;;succ:   EXIT [100.0%]

}

Note passing 1337 directly into the printf call.

[Bug middle-end/70879] Missed jump threading opportunity with multiple != conditions

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #4 from Jeffrey A. Law  ---
This was fixed by RIchi's change for pr71433.

[Bug tree-optimization/19794] [meta-bug] Jump threading related bugs

[law at redhat dot com]

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

Bug 70879 Summary: Missed jump threading opportunity with multiple != conditions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70879

   What|Removed |Added

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

[Bug middle-end/81897] [5.4/6.4/7.2/8 Regression] spurious -Wmaybe-uninitialized warning

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||4.6.3, 4.8.3
   Keywords||diagnostic
   Last reconfirmed||2017-08-18
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|spurious|[5.4/6.4/7.2/8 Regression]
   |-Wmaybe-uninitialized   |spurious
   |warning |-Wmaybe-uninitialized
   ||warning
  Known to fail||4.9.3, 5.4.0, 6.4.0, 7.2.0,
   ||8.0

--- Comment #1 from Martin Sebor  ---
Confirmed.  The regression was apparently introduced in r205074 (gcc 4.9.0). 
There was no warning prior to that change going as far back as r158841.  The
next older revision I have access to, r158831, again warns.

[Bug fortran/81898] New: Issue with polymorphic container class

[jdhughes at usgs dot gov]

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

Bug ID: 81898
   Summary: Issue with polymorphic container class
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jdhughes at usgs dot gov
  Target Milestone: ---

Created attachment 42006
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42006=edit
Offending code

The attached code is a minimal example of a problem we have encountered
compiling one of our software products with version 7.1.1. The compiled code
returns the following:

Program received signal SIGSEGV: Segmentation fault - invalid memory
reference.

Backtrace for this error: 
#0  0x10b7310bc
#1  0x10b7308aa
#2  0x7fffe6ebdb39
Segmentation fault: 11

when compiled with gfortran 7.1.1 2017062 on OSX from macports using the
following fortran flags:

-g -fcheck=all -fbacktrace -fbounds-check -O0 -Wall -Wextra
-fno-strict-aliasing -fwrapv

The code also fails on linux with GNU Fortran (Ubuntu 7.1.0-5ubuntu2~14.04)
7.1.0 using the following fortran flags

-O2 -fbacktrace -ffpe-summary=overflow -ffpe-trap=overflow,zero,invalid

The code runs successfully when compiled on ubuntu linux with the following:

4.9.4
5.4.1 20160904
6.3.0 20170519

The segmentation fault occurs after the program completes allocation and
initialization of this%element(i)%obj on line 117 for each element and makes
the call to a_rd on line 121.

A segmentation fault does not occur if this%elements is defined as:

type(Btype), pointer, dimensions(:) :: elements => null()

and the code is modified to reflect the change to this%elements.

Is this a bug in 7.1.1?

[Bug fortran/80164] ICE in gfc_format_decoder at gcc/fortran/error.c:933

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #16 from Jerry DeLisle  ---
Fixed on 7.3, closing

[Bug fortran/80164] ICE in gfc_format_decoder at gcc/fortran/error.c:933

[jvdelisle at gcc dot gnu.org]

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

--- Comment #15 from Jerry DeLisle  ---
Author: jvdelisle
Date: Fri Aug 18 21:36:50 2017
New Revision: 251189

URL: https://gcc.gnu.org/viewcvs?rev=251189=gcc=rev
Log:
2017-08-18  Jerry DeLisle  

Backport from trunk
PR fortran/80164
* trans-stmt.c (gfc_trans_call): If no code expr, use code->loc
as warning/error locus.

* gfortran.dg/array_temporaries_4.f90: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/array_temporaries_4.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/trans-stmt.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug c/53037] warn_if_not_aligned(X)

[hjl.tools at gmail dot com]

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

--- Comment #29 from H.J. Lu  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #28)
> > --- Comment #27 from H.J. Lu  ---
> 
> > What are error messages?
> 
> None, the warnings are simply missing.
> 
>   Rainer

Sparc defines STRICT_ALIGNMENT which leads to

  unsigned mode_align = GET_MODE_ALIGNMENT (TYPE_MODE (type));

  /* Don't override a larger alignment requirement coming from a user
 alignment of one of the fields.  */
  if (mode_align >= TYPE_ALIGN (type))
{
  SET_TYPE_ALIGN (type, mode_align);
  TYPE_USER_ALIGN (type) = 0; 
}

so __attribute__ ((packed)) is basically ignored on Sparc.  This patch

diff --git a/gcc/stor-layout.c b/gcc/stor-layout.c
index 3028d55773a..6dd605810ac 100644
--- a/gcc/stor-layout.c
+++ b/gcc/stor-layout.c
@@ -1784,7 +1784,7 @@ finalize_type_size (tree type)

   /* Don't override a larger alignment requirement coming from a user
alignment of one of the fields.  */
-  if (mode_align >= TYPE_ALIGN (type))
+  if (mode_align > TYPE_ALIGN (type))
   {
 SET_TYPE_ALIGN (type, mode_align);
 TYPE_USER_ALIGN (type) = 0;

works with cross compiler.  But I have no idea if it is correct.

[Bug target/81572] [7/8 Regression] gcc-7 regression: unnecessary vector regmove on compare

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-18
 CC||bergner at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Peter Bergner  ---
Confirmed.

GCC 6, GCC 7 and trunk all generate the same RTL going into IRA.  This includes
a register copy of the incoming formal arg reg r79 into a pseudo reg.  IRA also
assigns the same hard registers to the same pseudos for all three gcc versions,
which also includes the destination of the above copy insn getting assigned r79
making the copy a nop.

The difference is that starting with GCC 7, LRA decides that the assigning the
destination of the copy insn to r79 is "risky":

Spill r129 after risky transformations
  Reassigning non-reload pseudos
   Assign 77 to r129 (freq=3000)

so it ends up re-assigning it to r77.  This now means the copy insn is no
longer a nop and cannot be deleted.  Looking at the debugger, I see that at
some point, r79 gets added to:

  lra_reg_info[129].conflict_hard_regs

...which forces us to reassign pseudo 129.  I'm tracking down where r79 is
added to pseudo's conflist_hard_regs.

[Bug go/81893] [8 regression] compilation error in libgo starting with r251127

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

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

[Bug go/81893] [8 regression] compilation error in libgo starting with r251127

[ian at gcc dot gnu.org]

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

--- Comment #4 from ian at gcc dot gnu.org  ---
Author: ian
Date: Fri Aug 18 20:17:26 2017
New Revision: 251188

URL: https://gcc.gnu.org/viewcvs?rev=251188=gcc=rev
Log:
PR go/81893
runtime: only use PPC GNU/Linux register code on little endian

Reportedly the current code builds on little endian but not big endian.

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

Reviewed-on: https://go-review.googlesource.com/57110

Modified:
trunk/gcc/go/gofrontend/MERGE
trunk/libgo/runtime/go-signal.c

[Bug c/53037] warn_if_not_aligned(X)

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #28 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #27 from H.J. Lu  ---

> What are error messages?

None, the warnings are simply missing.

Rainer

[Bug c/53037] warn_if_not_aligned(X)

[hjl.tools at gmail dot com]

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

--- Comment #27 from H.J. Lu  ---
(In reply to Rainer Orth from comment #26)
> Several of the new tests FAIL on Solaris/SPARC (both 32 and 64-bit):
> 
> +FAIL: g++.dg/pr53037-2.C  -std=gnu++11  (test for warnings, line 16)
> +FAIL: g++.dg/pr53037-2.C  -std=gnu++11  (test for warnings, line 29)
> +FAIL: g++.dg/pr53037-2.C  -std=gnu++11  (test for warnings, line 6)
> +FAIL: g++.dg/pr53037-2.C  -std=gnu++14  (test for warnings, line 16)
> +FAIL: g++.dg/pr53037-2.C  -std=gnu++14  (test for warnings, line 29)
> +FAIL: g++.dg/pr53037-2.C  -std=gnu++14  (test for warnings, line 6)
> +FAIL: g++.dg/pr53037-2.C  -std=gnu++98  (test for warnings, line 16)
> +FAIL: g++.dg/pr53037-2.C  -std=gnu++98  (test for warnings, line 29)
> +FAIL: g++.dg/pr53037-2.C  -std=gnu++98  (test for warnings, line 6)
> +FAIL: g++.dg/pr53037-3.C  -std=gnu++11  (test for warnings, line 16)
> +FAIL: g++.dg/pr53037-3.C  -std=gnu++11  (test for warnings, line 29)
> +FAIL: g++.dg/pr53037-3.C  -std=gnu++11  (test for warnings, line 6)
> +FAIL: g++.dg/pr53037-3.C  -std=gnu++14  (test for warnings, line 16)
> +FAIL: g++.dg/pr53037-3.C  -std=gnu++14  (test for warnings, line 29)
> +FAIL: g++.dg/pr53037-3.C  -std=gnu++14  (test for warnings, line 6)
> +FAIL: g++.dg/pr53037-3.C  -std=gnu++98  (test for warnings, line 16)
> +FAIL: g++.dg/pr53037-3.C  -std=gnu++98  (test for warnings, line 29)
> +FAIL: g++.dg/pr53037-3.C  -std=gnu++98  (test for warnings, line 6)
> 
> +FAIL: gcc.dg/pr53037-2.c  (test for warnings, line 16)
> +FAIL: gcc.dg/pr53037-2.c  (test for warnings, line 32)
> +FAIL: gcc.dg/pr53037-2.c  (test for warnings, line 8)
> +FAIL: gcc.dg/pr53037-3.c  (test for warnings, line 16)
> +FAIL: gcc.dg/pr53037-3.c  (test for warnings, line 32)
> +FAIL: gcc.dg/pr53037-3.c  (test for warnings, line 8)
> 

What are error messages?

[Bug c/53037] warn_if_not_aligned(X)

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org

--- Comment #26 from Rainer Orth  ---
Several of the new tests FAIL on Solaris/SPARC (both 32 and 64-bit):

+FAIL: g++.dg/pr53037-2.C  -std=gnu++11  (test for warnings, line 16)
+FAIL: g++.dg/pr53037-2.C  -std=gnu++11  (test for warnings, line 29)
+FAIL: g++.dg/pr53037-2.C  -std=gnu++11  (test for warnings, line 6)
+FAIL: g++.dg/pr53037-2.C  -std=gnu++14  (test for warnings, line 16)
+FAIL: g++.dg/pr53037-2.C  -std=gnu++14  (test for warnings, line 29)
+FAIL: g++.dg/pr53037-2.C  -std=gnu++14  (test for warnings, line 6)
+FAIL: g++.dg/pr53037-2.C  -std=gnu++98  (test for warnings, line 16)
+FAIL: g++.dg/pr53037-2.C  -std=gnu++98  (test for warnings, line 29)
+FAIL: g++.dg/pr53037-2.C  -std=gnu++98  (test for warnings, line 6)
+FAIL: g++.dg/pr53037-3.C  -std=gnu++11  (test for warnings, line 16)
+FAIL: g++.dg/pr53037-3.C  -std=gnu++11  (test for warnings, line 29)
+FAIL: g++.dg/pr53037-3.C  -std=gnu++11  (test for warnings, line 6)
+FAIL: g++.dg/pr53037-3.C  -std=gnu++14  (test for warnings, line 16)
+FAIL: g++.dg/pr53037-3.C  -std=gnu++14  (test for warnings, line 29)
+FAIL: g++.dg/pr53037-3.C  -std=gnu++14  (test for warnings, line 6)
+FAIL: g++.dg/pr53037-3.C  -std=gnu++98  (test for warnings, line 16)
+FAIL: g++.dg/pr53037-3.C  -std=gnu++98  (test for warnings, line 29)
+FAIL: g++.dg/pr53037-3.C  -std=gnu++98  (test for warnings, line 6)

+FAIL: gcc.dg/pr53037-2.c  (test for warnings, line 16)
+FAIL: gcc.dg/pr53037-2.c  (test for warnings, line 32)
+FAIL: gcc.dg/pr53037-2.c  (test for warnings, line 8)
+FAIL: gcc.dg/pr53037-3.c  (test for warnings, line 16)
+FAIL: gcc.dg/pr53037-3.c  (test for warnings, line 32)
+FAIL: gcc.dg/pr53037-3.c  (test for warnings, line 8)

  Rainer

[Bug fortran/69834] [OOP] Collision in derived type hashes

[pault at gcc dot gnu.org]

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

--- Comment #16 from Paul Thomas  ---
Dear Jerry,

Thanks for your confirmation of my feeling about this. I have enough on my
plate as it is!

Cheers

Paul

[Bug fortran/80657] [7/8 Regression] Loop in character function declaration

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #4 from Paul Thomas  ---
Since I caused it, I had better take the PR!

I am away for the next ten days and will work on it while my wife is working on
her film script :-)

Cheers

Paul

[Bug middle-end/81897] New: spurious -Wmaybe-uninitialized warning

[arnd at linaro dot org]

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

Bug ID: 81897
   Summary: spurious -Wmaybe-uninitialized warning
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arnd at linaro dot org
  Target Milestone: ---

I keep seeing a class of false-positive -Wmaybe-uninitialized in the linux
kernel and have done countless kernel patches to work around them. The latest
one triggered me to look a little deeper. The general pattern I see is that
when one variable is conditionally initialized and conditionally used based on
the same variable, but any form of lock (mutex, semaphore, spinlock, ...)
release happens in-between, the compiler no longer knows if the initialization
was correct, and produces a spurious warning.

This particular instance of the warning I saw today reduced to a relatively
simple function between the initialization and the use:

int f(void);
static inline void rcu_read_unlock(void)
{
        static _Bool __warned;
        if (f() && !__warned && !f()) {
                __warned = 1;
        }
}
int inet6_rtm_getroute(void)
{
        int dst;
        int fibmatch = f();

        if (!fibmatch)
                dst = f();
        rcu_read_unlock();
        if (fibmatch)
                dst = 0;

        return dst;
}

Clearly, 'dst' is initialized here when it gets returned.

I can reproduce the warning in gcc-4.7 through 7.1.1, which is the latest I
tried.

[Bug c++/81896] New: omp target enter data not recognized

[thorstenkurth at me dot com]

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

Bug ID: 81896
   Summary: omp target enter data not recognized
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thorstenkurth at me dot com
  Target Milestone: ---

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

Dear Sir/Madam,

I am not sure if my report got posted the first time because I cannot find it
any more (did not receive a notification about it and it is also not marked
invalid somewhere).
Therefore, I will post it again.

It seems that gcc has problems with the omp target enter/exit data constructs.
When I compile the appended code I get:

g++ -O2 -std=c++11 -fopenmp -foffload=nvptx-none -c aclass.cpp -o aclass.o
In file included from aclass.h:2:0,
 from aclass.cpp:1:
masterclass.h: In member function 'void master::allocate(const unsigned int&)':
masterclass.h:10:50: error: 'master::data' is not a variable in 'map' clause
 #pragma omp target enter data map(alloc: data[0:size*sizeof(double)])
  ^~~~
masterclass.h:10:9: error: '#pragma omp target enter data' must contain at
least one 'map' clause
 #pragma omp target enter data map(alloc: data[0:size*sizeof(double)])
 ^~~
masterclass.h: In member function 'void master::deallocate()':
masterclass.h:15:51: error: 'master::data' is not a variable in 'map' clause
 #pragma omp target exit data map(release: data[:0])
   ^~~~
masterclass.h:15:9: error: '#pragma omp target exit data' must contain at least
one 'map' clause
 #pragma omp target exit data map(release: data[:0])
 ^~~
make: *** [aclass.o] Error 1

The same code compiles fine when using XLC. 

Best Regards
Thorsten Kurth

[Bug target/81894] Typo in x86 built-in function list

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||documentation
 Target||i386-*-*, x86_64-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-18
  Component|web |target
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
N.B. "web" is for the web pages, not the gcc manual. Although there are copies
of the manual online, it's part of the compiler sources, not the web pages.

Use keyword "documentation" for doc bugs.

[Bug go/81893] [8 regression] compilation error in libgo starting with r251127

[ian at airs dot com]

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

--- Comment #3 from Ian Lance Taylor  ---
Thanks.  I think https://golang.org/cl/57110 should fix the problem.

[Bug tree-optimization/81488] [8 Regression] gcc goes off the limits allocating memory in gimple-ssa-strength-reduction.c

[wschmidt at gcc dot gnu.org]

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

--- Comment #6 from Bill Schmidt  ---
Patch submitted:  https://gcc.gnu.org/ml/gcc-patches/2017-08/msg01145.html

[Bug go/81893] [8 regression] compilation error in libgo starting with r251127

[seurer at gcc dot gnu.org]

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

--- Comment #2 from seurer at gcc dot gnu.org ---
Yes, it compiles OK on LE.

Note that I saw the errors on both power7 and power8 BE systems and using
different versions of gcc to build.

[Bug fortran/69834] [OOP] Collision in derived type hashes

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||jvdelisle at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #15 from Jerry DeLisle  ---
(In reply to Jakub Jelinek from comment #14)
> GCC 7.1 has been released.

This is already in 7. I see no need for 6.

[Bug fortran/79072] ICE with class(*) pointer function result and character value

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #9 from Jerry DeLisle  ---
(In reply to Eric Gallager from comment #8)
> Redoing https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01290.html which was lost:
> 
> --- Comment #8 from neil.n.carlson at gmail dot com ---
> Ping.  Is there any interest in fixing this regression?

Yes, anything that is a failure on valid code we want to fix. We are simply
very short handed. What is the pain level on this one?

[Bug c++/81514] g++.dg/lookup/missing-std-include-2.C FAILs on Solaris

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #5 from David Malcolm  ---
Should be fixed by r251186.

[Bug c++/81514] g++.dg/lookup/missing-std-include-2.C FAILs on Solaris

[dmalcolm at gcc dot gnu.org]

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

--- Comment #4 from David Malcolm  ---
Author: dmalcolm
Date: Fri Aug 18 18:12:47 2017
New Revision: 251186

URL: https://gcc.gnu.org/viewcvs?rev=251186=gcc=rev
Log:
C++: fix ordering of missing std #include suggestion (PR c++/81514)

gcc/cp/ChangeLog:
PR c++/81514
* name-lookup.c (maybe_suggest_missing_header): Convert return
type from void to bool; return true iff a suggestion was offered.
(suggest_alternative_in_explicit_scope): Move call to
maybe_suggest_missing_header to before use of best_match, and
return true if the former offers a suggestion.

gcc/testsuite/ChangeLog:
PR c++/81514
* g++.dg/lookup/empty.h: New file.
* g++.dg/lookup/missing-std-include-2.C: Replace include of
stdio.h with empty.h and a declaration of a "std::sprintf" not based
on a built-in.


Added:
trunk/gcc/testsuite/g++.dg/lookup/empty.h
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/name-lookup.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/lookup/missing-std-include-2.C

[Bug fortran/81827] Large compile time with derived-type rrays

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #8 from Paul Thomas  ---
I have taken a brief look at this but have to postpone completion of a fix for
a couple of weeks because I will be on vacation.

Index: ../trunk/gcc/fortran/trans-expr.c
===
*** ../trunk/gcc/fortran/trans-expr.c   (revision 250712)
--- ../trunk/gcc/fortran/trans-expr.c   (working copy)
*** gfc_trans_assignment_1 (gfc_expr * expr1
*** 10075,10083 
  }
else
  tmp = gfc_trans_scalar_assign (, , expr1->ts,
!  gfc_expr_is_variable (expr2)
   || scalar_to_array
!  || expr2->expr_type == EXPR_ARRAY,
   !(l_is_temp || init_flag) && dealloc,
   expr1->symtree->n.sym->attr.codimension);
/* Add the pre blocks to the body.  */
--- 10075,10086 
  }
else
  tmp = gfc_trans_scalar_assign (, , expr1->ts,
!  !(init_flag
!&& flag_coarray != GFC_FCOARRAY_LIB
!&& expr2->expr_type == EXPR_STRUCTURE)
!  && (gfc_expr_is_variable (expr2)
   || scalar_to_array
!  || expr2->expr_type == EXPR_ARRAY),
   !(l_is_temp || init_flag) && dealloc,
   expr1->symtree->n.sym->attr.codimension);
/* Add the pre blocks to the body.  */

apart from a few regressions associated with tree dump counts of malloc.

The blanket exclusion of GFC_COARRAY_LIB is clearly not right or if it is,
I have not yet understood why.

I think that the problem lies in the default initializer for these derived
types. The suppression of the deep copy that the above patch provides can only
be necessary because the field in the initializer for the allocatable
components is not a null expression, as it should be. Otherwise, the deep copy
would stop dead in its tracks at the first level.

I have taken the bug.

Paul

[Bug libstdc++/81891] [5/6/7 Regression] heap-use-after-free if inserting element in std::unordered_map(InputIt, InputIt) throws

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Known to work||8.0
   Target Milestone|--- |5.5
Summary|[5/6/7/8 Regression]|[5/6/7 Regression]
   |heap-use-after-free if  |heap-use-after-free if
   |inserting element in|inserting element in
   |std::unordered_map(InputIt, |std::unordered_map(InputIt,
   |InputIt) throws |InputIt) throws
  Known to fail|8.0 |

--- Comment #5 from Jonathan Wakely  ---
Fixed on trunk so far.

[Bug preprocessor/81794] "would be stringified in traditional C" warning should be controlled by -Wtraditional

[dmalcolm at gcc dot gnu.org]

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

--- Comment #2 from David Malcolm  ---
Please can you turn it into a patch that contains both the fix *and* the new
testcase?  (e.g. gcc.dg/pragma-diag-8.c)

[Bug libstdc++/81891] [5/6/7/8 Regression] heap-use-after-free if inserting element in std::unordered_map(InputIt, InputIt) throws

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Fri Aug 18 17:46:57 2017
New Revision: 251185

URL: https://gcc.gnu.org/viewcvs?rev=251185=gcc=rev
Log:
PR libstdc++/81891 fix double-free in hashtable constructor

PR libstdc++/81891
* include/bits/hashtable.h (_Hashtable(_InputIterator, _InputIterator,
size_type, const _H1&, const _H2&, const _Hash&, const _Equal&,
const _ExtractKey&, const allocator_type&)): Let destructor do clean
up if an exception is thrown.
* testsuite/23_containers/unordered_map/cons/81891.cc: New.

Added:
trunk/libstdc++-v3/testsuite/23_containers/unordered_map/cons/81891.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/hashtable.h

[Bug c++/50169] "new struct X {{}};" incorrectly treated as an invalid struct-definition

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-18
 CC||jason at redhat dot com
 Ever confirmed|0   |1

--- Comment #5 from Ville Voutilainen  ---
This is DR 2141:
http://open-std.org/JTC1/SC22/WG21/docs/cwg_defects.html#2141

The original code is supposed to be valid, so confirming this as an actual bug.

[Bug c++/44283] bad error recovery for explicit template instantiation in wrong namespace

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||error-recovery
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-18
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Eric Gallager  ---
(In reply to Jonathan Wakely from comment #0)
> namespace NS
> {
> typedef int X;
> 
> template void f(X f, T t) { }
> }
> 
> template void f(X, int); // (1)
> 
> template void f(int, char);  // (2)
> 
> 
> The code is invalid, the explicit instantiations should be inside NS or
> should be qualified e.g.
> template void NS::func(X, int);
> 
> But the diagnostic for instantiation (1) is unhelpful:
> 
> bug.cc:8:17: error: variable or field 'f' declared void
> bug.cc:8:16: error: expected ';' before '(' token
> 
> This is closely related to Bug 16663 but the diagnostic for (2) implies it
> might be possible to improve things without fixing bug 16663, as this is
> much better:
> 
> bug.cc:10:26: error: 'f' is not a template function
> 
> Is it possible to give the same "is not a template function" diagnostic for
> (1)?

The message is now:

$ /usr/local/bin/g++ -c -Wall -Wextra -pedantic 44283.cc
44283.cc:8:17: error: variable or field ‘f’ declared void
 template void f(X, int); // (1)
 ^
44283.cc:8:16: error: expected ‘;’ before ‘(’ token
 template void f(X, int); // (1)
^
44283.cc:10:26: error: ‘f’ is not a template function
 template void f(int, char);  // (2)
  ^
$

so it has the "is not a template function" diagnostic now, but it could still
probably be improved.

> 
> Comeau does significantly better, reporting:
>identifier "X" is undefined
> and 
>"f" is not a class or function template name in the current scope
> 
> 
> 
> If the invalid instantiation is for a class template the diagnostic is fine:
> 
> namespace NS
> {
> template struct S;
> }
> 
> template struct S;
> 
> bug2.cc:6:17: error: 'S' is not a template
> bug2.cc:6:19: error: 'X' was not declared in this scope
> bug2.cc:6:17: error: explicit instantiation of non-template type 'S'
> 
> The only improvement I would make would be to add something like "in this
> scope" to the first error.
> 

With carets, this is now:

$ /usr/local/bin/g++ -c -Wall -Wextra -pedantic 44283_2.cc
44283_2.cc:6:17: error: ‘S’ is not a class template
 template struct S;
 ^
44283_2.cc:6:19: error: ‘X’ was not declared in this scope
 template struct S;
   ^
44283_2.cc:6:17: error: explicit instantiation of non-template type ‘S’
 template struct S;
 ^
$

(note the addition of the word 'class')

> 
> Here's another bad diagnostic for instantiating a template function, which
> doesn't have any undeclared type:
> 
> namespace NS
> {
> template void g() { }
> }
> 
> template void g<0>();
> 
> bug3.cc:6:15: error: variable or field 'g' declared void
> bug3.cc:6:16: error: expected ';' before '<' token
> 
> Surely it's possible to say "g is not a template function" when the compiler
> sees "template ... g<...>" ?
> 

This is still bad even with carets:

$ /usr/local/bin/g++ -c -Wall -Wextra -pedantic 44283_3.cc
44283_3.cc:6:15: error: variable or field ‘g’ declared void
 template void g<0>();
   ^
44283_3.cc:6:16: error: expected ‘;’ before ‘<’ token
 template void g<0>();
^
$

> Comeau is much better again:
> 
> "ComeauTest.c", line 6: error: g is not a template,
>   Should it be XX::g?, where XX is some namespace?
>   Did you #include the right header?
>   template void g<0>();
> ^
> 
> "ComeauTest.c", line 6: error: invalid explicit instantiation declaration
>   template void g<0>();
>^

So, confirmed that the errors could be improved.

[Bug preprocessor/81794] "would be stringified in traditional C" warning should be controlled by -Wtraditional

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-18
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed.  Please keep pinging the patch weekly until it's reviewed.

[Bug c/80529] Split "C++ style comments are not allowed in ISO C90" pedwarn into its own warning flag

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #6 from Eric Gallager  ---
(In reply to Martin Sebor from comment #5)
> I also don't think that adding a pure style warning for // comments is in
> line with GCC philosophy.  Quoting from the GCC manual:
> 
>   Warnings are diagnostic messages that report constructions that are not
>   inherently erroneous but that are risky or suggest there may have been
>   an error. 
> 
> Unlike with the traditional C-style comments, I don't know of any problems
> due to C++-style comments, so I don't think adding a warning option for them
> would be appropriate.
> 
> Regarding the exceptions cited in comment #2, I believe those exist not so
> much to help enforce particular coding styles but rather to avoid relying on
> C++ features that, at the time they were made available in G++, either
> weren't universally supported or weren't implemented efficiently enough to
> be suitable for all projects (e.g., embedded code would avoid some of these
> C++ features to minimize code bloat).

Actually I guess a better comparison would be -Wdeclaration-after-statement,
which you can get as part of -std=c89 -pedantic, but which you can also get
separately for other standards. Remember, gcc already warns for // comments
with
-std=gnu89 -pedantic, so splitting it into a new option wouldn't be so much
adding a warning option as it would be enabling an existing warning option for
other standards.

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

[richard-gccbugzilla at metafoo dot co.uk]

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

--- Comment #3 from Richard Smith  ---
The diagnostic in #1 is not only wrong for this case, it's also a rejects-valid
in the case where the underlying types match. I've filed
https://gcc.gnu.org/PR81895 for that.

[Bug c++/81895] New: gcc rejects out-of-line definition of enum member of class template under -pedantic-errors

[richard-gccbugzilla at metafoo dot co.uk]

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

Bug ID: 81895
   Summary: gcc rejects out-of-line definition of enum member of
class template under -pedantic-errors
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: richard-gccbugzilla at metafoo dot co.uk
  Target Milestone: ---

g++ -std=c++11 -pedantic-errors has a rejects-valid on this:

template struct S { enum class E : int; };
template enum class S::E : int { e };
S::E x = S::E::e;

The bogus error is:

error: 'enum S::E' is an enumeration template [-Wpedantic]

[Bug c++/80684] poor error message and fix-it hint for a function with an argument of undeclared type

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-18
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
For me the fix-it is just:

$ /usr/local/bin/g++ -S -Wall -Wextra -pedantic 80684.cc
80684.cc:1:15: error: variable or field ‘f’ declared void
 void f (string);
   ^
80684.cc:1:9: error: ‘string’ was not declared in this scope
 void f (string);
 ^~
80684.cc:1:9: note: suggested alternative: ‘__strong’
 void f (string);
 ^~
 __strong
$

When I include the header, the message is:

$ /usr/local/bin/g++ -S -Wall -Wextra -pedantic 80684.cc
80684.cc:3:15: error: variable or field ‘f’ declared void
 void f (string);
   ^
80684.cc:3:9: error: ‘string’ was not declared in this scope
 void f (string);
 ^~
80684.cc:3:9: note: suggested alternative:
In file included from /usr/local/include/c++/8.0.0/string:39:0,
 from 80684.cc:1:
/usr/local/include/c++/8.0.0/bits/stringfwd.h:74:33: note:  
‘std::__cxx11::string’
   typedef basic_stringstring;
 ^~
$

It seems like in this second case where  is already included, the ideal
fix-it would be to suggest inserting the 'std::' prefix before 'string', or
adding a "using namespace std;" directive earlier in the file. Thus,
confirming.

[Bug c/80529] Split "C++ style comments are not allowed in ISO C90" pedwarn into its own warning flag

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #5 from Martin Sebor  ---
I also don't think that adding a pure style warning for // comments is in line
with GCC philosophy.  Quoting from the GCC manual:

  Warnings are diagnostic messages that report constructions that are not
  inherently erroneous but that are risky or suggest there may have been
  an error. 

Unlike with the traditional C-style comments, I don't know of any problems due
to C++-style comments, so I don't think adding a warning option for them would
be appropriate.

Regarding the exceptions cited in comment #2, I believe those exist not so much
to help enforce particular coding styles but rather to avoid relying on C++
features that, at the time they were made available in G++, either weren't
universally supported or weren't implemented efficiently enough to be suitable
for all projects (e.g., embedded code would avoid some of these C++ features to
minimize code bloat).

[Bug c++/80567] bogus fixit hint for undeclared memset: else

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-18
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Confirmed.

[Bug web/81894] New: Typo in x86 built-in function list

[lh_mouse at 126 dot com]

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

Bug ID: 81894
   Summary: Typo in x86 built-in function list
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: web
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lh_mouse at 126 dot com
  Target Milestone: ---

https://gcc.gnu.org/onlinedocs/gcc-7.2.0/gcc/x86-Built-in-Functions.html#x86-Built-in-Functions
  says:

```
The following built-in functions are available when -mlzcnt is used. All of
them generate the machine instruction that is part of the name.

unsigned short __builtin_ia32_lzcnt_16(unsigned short);
unsigned int __builtin_ia32_lzcnt_u32(unsigned int);
unsigned long long __builtin_ia32_lzcnt_u64 (unsigned long long);
```

The first function `__builtin_ia32_lzcnt_16()` doesn't exist. It is
`__builtin_ia32_lzcnt_u16()` that exists.

[Bug go/81893] [8 regression] compilation error in libgo starting with r251127

[ian at airs dot com]

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

--- Comment #1 from Ian Lance Taylor  ---
Did you test powerpc64 little endian?

[Bug libstdc++/81891] [5/6/7/8 Regression] heap-use-after-free if inserting element in std::unordered_map(InputIt, InputIt) throws

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
I think this might be all we need to do to fix it:

--- a/libstdc++-v3/include/bits/hashtable.h
+++ b/libstdc++-v3/include/bits/hashtable.h
@@ -973,17 +973,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
_M_bucket_count = __bkt_count;
  }

-   __try
- {
-   for (; __f != __l; ++__f)
- this->insert(*__f);
- }
-   __catch(...)
- {
-   clear();
-   _M_deallocate_buckets();
-   __throw_exception_again;
- }
+   for (; __f != __l; ++__f)
+ this->insert(*__f);
   }

   template

[Bug libstdc++/81891] [5/6/7/8 Regression] heap-use-after-free if inserting element in std::unordered_map(InputIt, InputIt) throws

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||fdumont at gcc dot gnu.org

--- Comment #2 from Jonathan Wakely  ---
The regression started with r214986 which introduced the constructor
delegation, but didn't change the logic to account for the destructor running.

[Bug libstdc++/81891] [5/6/7/8 Regression] heap-use-after-free if inserting element in std::unordered_map(InputIt, InputIt) throws

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
The problem is that the _Hashtable constructor delegates to another
constructor, so if an exception happens in the delegating constructor the
object has been constructed and its destructor will run. The delegating
constructor calls _M_deallocate_buckets() but doesn't zero the _M_buckets
pointer, so the destructor tries to deallocate them again.

[Bug preprocessor/81419] GCC wrongly suggests function-like macro as fixit hint for undefined object-like macro

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-18
 CC||msebor at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=80567,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=80684
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed.  There are few other similar bugs for these fix-it hints (e.g.,
pr80567 or pr80684).  I haven't looked at the implementation but from the
symptoms it feels like the problem is that the search doesn't fully consider
the context in which the undeclared is used.   I.e., it doesn't distinguish
between a function call, other kinds of expressions, a type, or even a keyword,
etc.

[Bug go/81893] New: [8 regression] compilation error in libgo starting with r251127

[seurer at gcc dot gnu.org]

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

Bug ID: 81893
   Summary: [8 regression] compilation error in libgo starting
with r251127
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: seurer at gcc dot gnu.org
CC: cmang at google dot com
  Target Milestone: ---

I only saw this on powerpc64 big endian.

/home/seurer/gcc/gcc-trunk/libgo/runtime/go-signal.c: In function 'dumpregs':
/home/seurer/gcc/gcc-trunk/libgo/runtime/go-signal.c:349:19: error:
initialization of 'mcontext_t * {aka struct  *}' from incompatible
pointer type 'union uc_regs_ptr *' [-Werror=incompatible-pointer-types]
   mcontext_t *m = &((ucontext_t*)(context))->uc_mcontext;
   ^
/home/seurer/gcc/gcc-trunk/libgo/runtime/go-signal.c:353:37: error: 'mcontext_t
{aka struct }' has no member named 'regs'; did you mean 'gregs'?
runtime_printf("r%d %X\n", i, m->regs->gpr[i]);
 ^~~~
 gregs
/home/seurer/gcc/gcc-trunk/libgo/runtime/go-signal.c:354:33: error: 'mcontext_t
{aka struct }' has no member named 'regs'; did you mean 'gregs'?
   runtime_printf("pc  %X\n", m->regs->nip);
 ^~~~
 gregs
/home/seurer/gcc/gcc-trunk/libgo/runtime/go-signal.c:355:33: error: 'mcontext_t
{aka struct }' has no member named 'regs'; did you mean 'gregs'?
   runtime_printf("msr %X\n", m->regs->msr);
 ^~~~
 gregs
/home/seurer/gcc/gcc-trunk/libgo/runtime/go-signal.c:356:33: error: 'mcontext_t
{aka struct }' has no member named 'regs'; did you mean 'gregs'?
   runtime_printf("cr  %X\n", m->regs->ccr);
 ^~~~
 gregs
/home/seurer/gcc/gcc-trunk/libgo/runtime/go-signal.c:357:33: error: 'mcontext_t
{aka struct }' has no member named 'regs'; did you mean 'gregs'?
   runtime_printf("lr  %X\n", m->regs->link);
 ^~~~
 gregs
/home/seurer/gcc/gcc-trunk/libgo/runtime/go-signal.c:358:33: error: 'mcontext_t
{aka struct }' has no member named 'regs'; did you mean 'gregs'?
   runtime_printf("ctr %X\n", m->regs->ctr);
 ^~~~
 gregs
/home/seurer/gcc/gcc-trunk/libgo/runtime/go-signal.c:359:33: error: 'mcontext_t
{aka struct }' has no member named 'regs'; did you mean 'gregs'?
   runtime_printf("xer %X\n", m->regs->xer);
 ^~~~
 gregs

[Bug c++/80763] [7/8 Regression] -O3 causes error: inline clone in same comdat group list

[dcb314 at hotmail dot com]

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

--- Comment #8 from David Binderman  ---
(In reply to David Binderman from comment #7)
> Still seems to be broken, over a month later.

Still broken, a couple of months even later ...

[Bug c++/52801] improve selective typedef unwrapping

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic, error-recovery
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-18
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Confirmed that the notes could ease up on the template spew; g++ output is now:

$ /usr/local/bin/g++ -fsyntax-only 52801.cc
52801.cc: In function ‘void foo()’:
52801.cc:9:8: error: no match for ‘operator=’ (operand types are
‘std::__cxx11::string {aka std::__cxx11::basic_string}’ and
‘std::vector’)
  str = vec;
^~~
In file included from /usr/local/include/c++/8.0.0/string:52:0,
 from 52801.cc:2:
/usr/local/include/c++/8.0.0/bits/basic_string.h:627:7: note: candidate:
‘std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::operator=(const
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT = char;
_Traits = std::char_traits; _Alloc = std::allocator]’
   operator=(const basic_string& __str)
   ^~~~
/usr/local/include/c++/8.0.0/bits/basic_string.h:627:7: note:   no known
conversion for argument 1 from ‘std::vector’ to ‘const
std::__cxx11::basic_string&’
/usr/local/include/c++/8.0.0/bits/basic_string.h:666:7: note: candidate:
‘std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::operator=(const _CharT*)
[with _CharT = char; _Traits = std::char_traits; _Alloc =
std::allocator]’
   operator=(const _CharT* __s)
   ^~~~
/usr/local/include/c++/8.0.0/bits/basic_string.h:666:7: note:   no known
conversion for argument 1 from ‘std::vector’ to ‘const char*’
/usr/local/include/c++/8.0.0/bits/basic_string.h:677:7: note: candidate:
‘std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::operator=(_CharT) [with
_CharT = char; _Traits = std::char_traits; _Alloc =
std::allocator]’
   operator=(_CharT __c)
   ^~~~
/usr/local/include/c++/8.0.0/bits/basic_string.h:677:7: note:   no known
conversion for argument 1 from ‘std::vector’ to ‘char’
/usr/local/include/c++/8.0.0/bits/basic_string.h:695:7: note: candidate:
‘std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&
std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::operator=(std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&&) [with
_CharT = char; _Traits = std::char_traits; _Alloc =
std::allocator]’
   operator=(basic_string&& __str)
   ^~~~
/usr/local/include/c++/8.0.0/bits/basic_string.h:695:7: note:   no known
conversion for argument 1 from ‘std::vector’ to
‘std::__cxx11::basic_string&&’
/usr/local/include/c++/8.0.0/bits/basic_string.h:749:7: note: candidate:
‘std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&
std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::operator=(std::initializer_list<_Tp>) [with _CharT = char; _Traits =
std::char_traits; _Alloc = std::allocator]’
   operator=(initializer_list<_CharT> __l)
   ^~~~
/usr/local/include/c++/8.0.0/bits/basic_string.h:749:7: note:   no known
conversion for argument 1 from ‘std::vector’ to
‘std::initializer_list’
$

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

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-18
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Eric Gallager  ---
(In reply to Daniel Krügler from comment #1)
> Confirmed for 4.7.0 20120218 (experimental).
> 

(In reply to Daniel Krügler from comment #3)
> (In reply to comment #2)
> 
> Agreed. It seems that the fix did not solve some array-related corner cases
> like this one.

Changing status to NEW then.

[Bug libstdc++/81891] [5/6/7/8 Regression] heap-use-after-free if inserting element in std::unordered_map(InputIt, InputIt) throws

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-18
 Ever confirmed|0   |1

[Bug tree-optimization/81892] suboptimal code for a if (p) free(p) else free(p)

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-18
 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=80519
 Ever confirmed|0   |1

--- Comment #2 from Eric Gallager  ---
Related to bug 80519 but I'll leave this one separate because this one mentions
the "else" case and 80519 doesn't

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

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 Status|WAITING |NEW

--- Comment #2 from Jonathan Wakely  ---
I don't know what an "enumeration template" is, but I would say no. The code
should be rejected because S::E is declared with an underlying type of int,
then redeclared with an underlying type that depends on the template parameter.

The pedwarn about enumeration types is something unrelated, and predates fixed
underlying types by more than a decade.

[Bug tree-optimization/81892] suboptimal code for a if (p) free(p) else free(p)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||missed-optimization
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=80528

--- Comment #1 from Martin Sebor  ---
See bug 80528 for a related request.

[Bug tree-optimization/81892] New: suboptimal code for a if (p) free(p) else free(p)

[msebor at gcc dot gnu.org]

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

Bug ID: 81892
   Summary: suboptimal code for a if (p) free(p) else free(p)
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

As mentioned in bug 80528, comment 2, GCC generates suboptimal code for the
following test case.  It would be more optimal to emit an unconditional jump to
free as Clang and ICC do.

Separately it might also be worth considering eliminating the 'if (p)' test
altogether, even in cases with no else clause.  I.e., using
-fdelete-null-pointer-checks to transform 'if (p) free (p)' to a call to an
unconditional free (p).  Since (in the absence of any information to the
contrary) a pointer passed to free() is far less likely to be null than not,
keeping the test only makes the code bigger and slower.

$ cat b.c && gcc -O2 -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout  b.c
void free (void*);

void g (void *p)
{
  if (p)
free (p);
  else
free (p);
}


;; Function g (g, funcdef_no=0, decl_uid=1817, cgraph_uid=0, symbol_order=0)

Removing basic block 5
g (void * p)
{
   [100.00%] [count: INV]:
  if (p_2(D) != 0B)
goto ; [53.47%] [count: INV]
  else
goto ; [46.53%] [count: INV]

   [53.47%] [count: INV]:
  free (p_2(D)); [tail call]

   [100.00%] [count: INV]:
  return;

}

[Bug tree-optimization/81673] Harmful SLP vectorization

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 Depends on||80689

--- Comment #5 from Martin Jambor  ---
Benchmarking the patch revealed that without addressing PR 80689
first, it severely harms -Ofast performance of 538.imagick_r.  With PR
80689 addressed, it helps as intended.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80689
[Bug 80689] 128 bit loads generated for structure copying with gcc 7.1.0 and
leads to STLF stalls in avx2 targets.

[Bug c++/48829] g++ no warning initializing a variable using itself

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-18
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Eric Gallager  ---
(In reply to matferib from comment #0)
> This code issues a warning:
> 
> g++ -Wall
> int i = 5 + i;
> warning: ‘i’ may be used uninitialized in this function
> 
> This code does not:
> string s = string("str") + s;
> 
> Neither this:
> string s(string("str") + s);
> 
> Shouldnt the 2 last ones issue warnings too?

(In reply to Jonathan Wakely from comment #1)
> The string case calls a function (the overloaded operator+ or std::string)
> so is actually closer to:
> 
>   int f(int);
>   int i = f(i);
> 
> which doesn't warn either (although it should do, ideally)
> 
> This is similar to PR 48483, maybe even a dup.

So, I combined all the snippets into a single testcase, and g++ doesn't even
warn on the first one anymore:

$ cat 48829.cc
#include 

using namespace std;

int i = 5 + i;

string s = string("str") + s;

string ss(string("str") + ss);

int f(int);
int ii = f(ii);
$ /usr/local/bin/g++ -c -Wall -Wextra -pedantic -Wuninitialized -Winit-self
-Weffc++ -O2 48829.cc
$ 

Same with all other optimization levels I tried. So, confirmed.

[Bug target/80689] 128 bit loads generated for structure copying with gcc 7.1.0 and leads to STLF stalls in avx2 targets.

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-08-18
   Assignee|unassigned at gcc dot gnu.org  |jamborm at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #8 from Martin Jambor  ---
I have a prototype patch and will start testing and benchmarking it soon.

[Bug c/80528] reimplement gnulib's "useless-if-before-free" script as a compiler warning

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-18
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Sebor  ---
I think a warning like this might be useful, although I probably wouldn't want
to enable under -Wall or -Wextra.   (GCC could also use branch probabilities to
decide whether or not to warn.)

That said, I would expect GCC to get rid of the tests with
-fdelete-null-pointer-checks.  As it is, it eliminates the call to free when
the pointer is known to be null but not the test itself (see below).  That
seems quite suboptimal to me since in the absence of any other information a
pointer being passed to free is far more likely to be non-null than not.  Clang
and ICC both optimize the function below into an unconditional jump to free. 
So while I think implementing the optimization is the better solution here, the
warning could also help improve the efficiency of the emitted code in its
absence.

$ cat b.c && gcc -O2 -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout  b.c
void free (void*);

void g (void *p)
{
  if (p)// test retained
free (p);
  else
free (p);   // eliminated
}


;; Function g (g, funcdef_no=0, decl_uid=1817, cgraph_uid=0, symbol_order=0)

Removing basic block 5
g (void * p)
{
   [100.00%] [count: INV]:
  if (p_2(D) != 0B)
goto ; [53.47%] [count: INV]
  else
goto ; [46.53%] [count: INV]

   [53.47%] [count: INV]:
  free (p_2(D)); [tail call]

   [100.00%] [count: INV]:
  return;

}

[Bug c++/51789] GCC does not consider SFINAE in template parameter list of template parameter pack

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 Status|WAITING |NEW

--- Comment #2 from Jonathan Wakely  ---
Yes, it is not a complete testcase. It should have #include , or
here's a complete version:

namespace std {
template struct is_same { static const bool value =
false; };
template struct is_same { static const bool value = true; };
template struct enable_if { };
template struct enable_if { using type = T; };
}

struct A {  
  template<
typename ...T, 
template::value, int
  >::type ...
> class...
  >
  A(T...); 
}; 

A a = {1, 2.0, 3};

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

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-08-18
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
You can make g++ reject it with -pedantic-errors:

$ /usr/local/bin/g++ -c -Wall -Wextra -pedantic-errors -std=c++11 52130.cc
52130.cc:2:27: error: ‘enum S::E’ is an enumeration template [-Wpedantic]
 template enum S::E : T { e };
   ^~~~
$

Is that sufficient?

[Bug c++/51789] GCC does not consider SFINAE in template parameter list of template parameter pack

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-08-18
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
g++ errors on the code for me:

$ /usr/local/bin/g++ -c -Wall -Wextra -pedantic 51789.cc
51789.cc:4:28: error: ‘enable_if’ in namespace ‘std’ does not name a template
type
 template’ before ‘<’ token
 template’ before ‘<’ token
51789.cc:7:12: error: expected identifier before ‘...’ token
 > class...
^~~
51789.cc:7:12: error: expected unqualified-id before ‘...’ token
51789.cc:12:17: error: too many initializers for ‘A’
 A a = {1, 2.0, 3};
 ^
$ 

Is it missing an include of a header or something?

[Bug c++/71003] __extension__ silences pedwarn for "\e" in C but not in C++

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-18
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed.  The manual says clearly that it should work so this is a G++ bug.

'-Wpedantic' does not cause warning messages for use of the alternate keywords
whose names begin and end with '__'.  Pedantic warnings are also disabled in
the expression that follows __extension__.

[Bug c++/81327] cast to void* does not suppress -Wclass-memaccess

[ville.voutilainen at gmail dot com]

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

--- Comment #1 from Ville Voutilainen  ---
Note that this currently blocks building Qt with gcc 8. We could work around it
by turning our void* casts to char* casts, but we have a preference for fixing
this problem in the compiler.

[Bug c++/50169] "new struct X {{}};" incorrectly treated as an invalid struct-definition

[ville.voutilainen at gmail dot com]

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

--- Comment #4 from Ville Voutilainen  ---
I have sent this to Core for consideration.

[Bug libstdc++/81891] New: heap-use-after-free if inserting element in std::unordered_map(InputIt, InputIt) throws

[pdziepak at quarnos dot org]

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

Bug ID: 81891
   Summary: heap-use-after-free if inserting element in
std::unordered_map(InputIt, InputIt) throws
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pdziepak at quarnos dot org
  Target Milestone: ---

GCC 7.1.1 from Fedora 26 (gcc version 7.1.1 20170622 (Red Hat 7.1.1-3) (GCC))

Reproducer:
--snip--
#include 
#include 

struct fails_on_copy {
fails_on_copy() = default;
fails_on_copy(const fails_on_copy&) {
throw 0;
};
};

int main()
{
std::array, 128> range;
try {
std::unordered_map umap(range.begin(),
range.end());
} catch(...) { }
}
--snip--

When built with AddressSanitizer:

g++ -fsanitize=address -g test.cc -o test

The following error is reported:

$ ./test
=
==18550==ERROR: AddressSanitizer: heap-use-after-free on address 0x61900080
at pc 0x7f3ae4dbca1a bp 0x7ffc9cfc6fc0 sp 0x7ffc9cfc6768
WRITE of size 1096 at 0x61900080 thread T0
#0 0x7f3ae4dbca19  (/lib64/libasan.so.4+0x5ea19)
#1 0x401c62 in std::_Hashtable,
std::__detail::_Select1st, std::equal_to, std::hash,
std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash,
std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits >::clear() /usr/include/c++/7/bits/hashtable.h:2039
#2 0x4019b7 in std::_Hashtable,
std::__detail::_Select1st, std::equal_to, std::hash,
std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash,
std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits >::~_Hashtable() /usr/include/c++/7/bits/hashtable.h:1364
#3 0x40205b in std::_Hashtable,
std::__detail::_Select1st, std::equal_to, std::hash,
std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash,
std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits >::_Hashtable*>(std::pair*, std::pair*, unsigned long, std::hash
const&, std::__detail::_Mod_range_hashing const&,
std::__detail::_Default_ranged_hash const&, std::equal_to const&,
std::__detail::_Select1st const&, std::allocator const&) /usr/include/c++/7/bits/hashtable.h:962
#4 0x401b27 in std::_Hashtable,
std::__detail::_Select1st, std::equal_to, std::hash,
std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash,
std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits >::_Hashtable*>(std::pair*, std::pair*, unsigned long, std::hash
const&, std::equal_to const&, std::allocator const&) /usr/include/c++/7/bits/hashtable.h:444
#5 0x401960 in std::unordered_map
>::unordered_map*>(std::pair*, std::pair*, unsigned long, std::hash
const&, std::equal_to const&, std::allocator const&) /usr/include/c++/7/bits/unordered_map.h:176
#6 0x40138b in main /home/pdziepak/gcc/test.cc:15
#7 0x7f3ae40f84d9 in __libc_start_main (/lib64/libc.so.6+0x204d9)
#8 0x401119 in _start (/home/pdziepak/gcc/test+0x401119)

0x61900080 is located 0 bytes inside of 1096-byte region
[0x61900080,0x619004c8)
freed by thread T0 here:
#0 0x7f3ae4e3efd0 in operator delete(void*) (/lib64/libasan.so.4+0xe0fd0)
#1 0x403cfb in
__gnu_cxx::new_allocator::deallocate(std::__detail::_Hash_node_base**,
unsigned long) /usr/include/c++/7/ext/new_allocator.h:125
#2 0x403145 in
std::allocator_traits
>::deallocate(std::allocator&,
std::__detail::_Hash_node_base**, unsigned long)
/usr/include/c++/7/bits/alloc_traits.h:462
#3 0x402963 in
std::__detail::_Hashtable_alloc >
>::_M_deallocate_buckets(std::__detail::_Hash_node_base**, unsigned long)
/usr/include/c++/7/bits/hashtable_policy.h:2121
#4 0x40218d in std::_Hashtable,
std::__detail::_Select1st, std::equal_to, std::hash,
std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash,
std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits >::_M_deallocate_buckets(std::__detail::_Hash_node_base**,

[Bug lto/81847] ICE with LTO enabled

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
Created attachment 42004
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42004=edit
A bit smaller test-case

Smaller test-cast which needs to add --param lto-min-partition=1.

Problem is following, we create an isra clone and we'll put it into a comdat
group:

_Z11format_packIJiiN1a1b1fIcccvDpT_.isra.37/2088
(_Z11format_packIJiiN1a1b1fIcccvDpT_.isra.37) @0x2b2b65795b80
  Type: function definition analyzed
  Visibility: prevailing_def_ironly
comdat_group:_ZN3PigC5IiJiN1a1b1fIcccET_DpT0_ artificial
  Same comdat group as: _ZN3PigC2IiJiN1a1b1fIcccET_DpT0_/371
  References: __gxx_personality_v0/1347 (addr)
  Referring: 
  Read from file: gccbug.o
  Availability: local
  First run: 0
  Function flags: local
  Called by: _ZN3PigC2IiJiN1a1b1fIcccET_DpT0_/371 (1.00 per call) 
  Calls: _ZN1a1b1fIcccE2crEl/1473 _ZN1a5tupleIJiiNS_1b1fIcccD1Ev/607
_ZN1a1b1fIcccE2crEl/1473 (0.37 per call)
_ZN1a5tupleIJiiNS_1b1fIcccD2Ev/2938 (inlined) (1.00 per call)
_Z12format_tupleIN1a5tupleIJiiNS0_1b1fIcccELi3EEvT_NS0_1lIiXT0_EEE.isra.10/1803
(inlined) (1.00 per call)
_ZN1a5tupleIJiiNS_1b1fIcccC2IJiiS3_ELj1EEEDpT_/798 (inlined) (1.00 per
call) _ZN1a1b1fIcccE2coC1EPcNS_9allocatorIcEE/1471 (1.00 per call) (can throw
external) _ZN1a1b1fIcccE2csEv/1470 (1.00 per call) (can throw external) 

Then we start partitioning and following symbols are put to a partition:

add_symbol_to_partition: __base_ctor /371
Step 1: added _Z11format_packIJiiN1a1b1fIcccvDpT_.isra.37/2088, size 931,
cost 3013/1012 best 3013/1012, step 1

the partition is finished and in a next partition:
Symbol node __base_ctor /371 now used in multiple partitions

and then we attempt to add again the isra clone and we fail. That triggers the
assert.
We have:

   113  static bool
   114  add_symbol_to_partition_1 (ltrans_partition part, symtab_node *node)
   115  {
...
   124/* non-duplicated aliases or tunks of a duplicated symbol needs to be
output
   125   just once.
   126  
   127   Be lax about comdats; they may or may not be duplicated and we may
   128   end up in need to duplicate keyed comdat because it has unkeyed
alias.  */
   129if (c == SYMBOL_PARTITION && !DECL_COMDAT (node->decl)
   130&& symbol_partitioned_p (node))
   131  return false;

Shouldn't be this place somehow adjusted in order to handle symbols in comdat
group that are actually
not DECL_COMDATs? Honza?

[Bug c++/71527] wrong type mismatch while template argument deduction/substitution

[benni.buch at gmail dot com]

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

Benjamin Buch  changed:

   What|Removed |Added

 CC||benni.buch at gmail dot com

--- Comment #2 from Benjamin Buch  ---
Bug does still exist in:

$ g++ --version
g++ (GCC) 8.0.0 20170818 (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.

[Bug inline-asm/81890] asm memory constraints are difficult and not well documented

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

   Keywords||documentation
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-18
 Ever confirmed|0   |1

[Bug inline-asm/81890] New: asm memory constraints are difficult and not well documented

[amodra at gmail dot com]

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

Bug ID: 81890
   Summary: asm memory constraints are difficult and not well
documented
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: inline-asm
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amodra at gmail dot com
  Target Milestone: ---

gcc doesn't have a simple way to say that a pointer passed to an inline asm is
used to address an array.  "m" (*p) unfortunately only makes the asm depend on
the first element of an array.

The following came about from a discussion starting at
https://gcc.gnu.org/ml/gcc/2017-08/msg00116.html

Compiling with -DTRY=4 or -DTRY=6 give good results, and I believe are
reasonable to extend to types other than char without falling foul of aliasing
rules, but these tricks are a little contrived and not documented.  

-DTRY=5 is no doubt what should be used but this does not appear to be
documented.


/* -O3 */
#include 

#if TRY == 1
int get_string_length (const char *p)
{
  int count;

  /* Unfortunately the "m" here only makes the asm depend on p[0], so
 this is not safe.  The initialization of buff in main can be
 partly moved past the get_string_length call.  */
  __asm__ ("repne scasb"
   : "=c" (count), "+D" (p)
   : "m" (*p), "0" (-1), "a" (0)
   );
  return -2 - count;
}
#elif TRY == 2
/* No better than the above.  */
int get_string_length (const char p[])
{
  int count;

  __asm__ ("repne scasb"
   : "=c" (count), "+D" (p)
   : "m" (*p), "0" (-1), "a" (0)
   );
  return -2 - count;
}
#elif TRY == 3
int get_string_length (const char *p)
{
  int count;

  /* Warns unfortunately, but works, at least on some versions of gcc.  */
  __asm__ ("repne scasb"
   : "=c" (count), "+D" (p)
   : "m" (*(const void *)p), "0" (-1), "a" (0)
   );
  return -2 - count;
}
#elif TRY == 4
int get_string_length (const char *p)
{
  int count;

  /* A way of saying that p points to an array of indeterminate
 length, near enough.  */
  __asm__ ("repne scasb"
   : "=c" (count), "+D" (p)
   : "m" (*(const struct {char a; char x[];} *) p), "0" (-1), "a" (0)
   );
  return -2 - count;
}
#elif TRY == 5
int get_string_length (const char *p)
{
  int count;

  /* The right way to say that p points to an array of char of
 indeterminate length.  */
  __asm__ ("repne scasb"
   : "=c" (count), "+D" (p)
   : "m" (*(const char (*)[]) p), "0" (-1), "a" (0)
   );
  return -2 - count;
}
#elif TRY == 6
int get_string_length (const char *p)
{
  int count;

  /* Make gcc lose detailed information regarding the memory pointed
 to by p.  This, in conjuction with "m" (*p) as an input below
 will act similarly to a "memory" clobber, but is more precise in
 that it doesn't say all memory may be written.  */
  __asm__ ("#%0" : "+X" (p));

  __asm__ ("repne scasb"
   : "=c" (count), "+D" (p)
   : "m" (*p), "0" (-1), "a" (0)
   );
  return -2 - count;
}
#elif TRY == 7
int get_string_length (const char *p)
{
  int count;

  /* As recommended by the gcc info doc.  Suffers from needing to know
 the size of the array.  */
  __asm__ ("repne scasb"
   : "=c" (count), "+D" (p)
   : "m" (*(const struct {char x[48];} *) p), "0" (-1), "a" (0)
   );
  return -2 - count;
}
#else
int get_string_length (const char *p)
{
  int count;

  /* Bog standard, but unfortunately says to gcc that memory might be
 written by the asm.  As can be seen by inspecting the code
 produced, this means "expected" below must be read before calling
 get_string_length, using an extra register.  This may result in
 less optimized code in real-world examples.  */
  __asm__ ("repne scasb"
   : "=c" (count), "+D" (p)
   : "0" (-1), "a" (0)
   : "memory"
   );
  return -2 - count;
}
#endif

int expected = 4;

int
main ()
{
  char buff[48] = "hello world";
  buff[4] = 0;
  int b = expected;
  int a = get_string_length (buff);
  printf ("%s: %d %d\n", buff, a, b);
  return 0;
}

[Bug ipa/81877] [7/8 Regression] Incorrect results with lto and -fipa-cp and -fipa-cp-clone

[amonakov at gcc dot gnu.org]

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

--- Comment #13 from Alexander Monakov  ---
> More rigorously defining the semantic of loop->safelen (the
> middle-end term) is necessary nevertheless.  I believe omp ordered
> doesn't have any middle-end representation?

Except on nvptx, 'omp ordered' in omp-simd context becomes a stmt sequence
bracketed with IFN_GOMP_SIMD_ORDERED_{START,END}, which completely disables
cross-iteration vectorization aiui. So your example doesn't get vectorized (not
even with SLP).

(on omp/ptx the approach is different)

[Bug c++/51545] missing -Wparentheses diagnostic with compound assignment used as condition

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-18
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Eric Gallager  ---
Confirmed.

[Bug c++/51234] ambiguity in mangling function attribute

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |WORKSFORME

--- Comment #1 from Eric Gallager  ---
Compiles successfully for me with no warnings or errors with gcc8.

$ /usr/local/bin/g++ -c -Wall -Wextra -pedantic 51234.cc
$

[Bug c++/49531] Doesn't resolve to conversion function template specialization in expressions

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-18
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Confirmed, clang accepts it with both standards:

$ /usr/local/bin/g++ -c -Wall -Wextra -pedantic -std=c++03 49531.cc
49531.cc: In function ‘void f()’:
49531.cc:5:12: error: statement cannot resolve address of overloaded function
 void f() { ::operator int; }
^~
$ /usr/local/bin/g++ -c -Wall -Wextra -pedantic -std=c++0x 49531.cc
49531.cc: In function ‘void f()’:
49531.cc:5:12: error: statement cannot resolve address of overloaded function
 void f() { ::operator int; }
^~
$ /sw/opt/llvm-3.1/bin/clang++ -c -Wall -Wextra -pedantic -std=c++03 49531.cc
49531.cc:5:12: warning: expression result unused [-Wunused-value]
void f() { ::operator int; }
   ^~~~
1 warning generated.
$ /sw/opt/llvm-3.1/bin/clang++ -c -Wall -Wextra -pedantic -std=c++0x 49531.cc
49531.cc:5:12: warning: expression result unused [-Wunused-value]
void f() { ::operator int; }
   ^~~~
1 warning generated.
$

(although in my opinion the code still just looks weird...)

[Bug middle-end/81889] [7 Regression] bogus warnings with -Wmaybe-uninitialized -O3

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=67679

--- Comment #1 from janus at gcc dot gnu.org ---
This may be related to other -Wmaybe-uninitialized regressions like PR 67679.

[Bug c++/47256] "--sysroot" option is not passed to COLLECT_GCC_OPTIONS

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-08-18
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Eric Gallager  ---
(In reply to Paolo Carlini from comment #3)
> Patches go to gcc-patches...

WAITING until patch is submitted

[Bug middle-end/81889] New: [7 Regression] bogus warnings with -Wmaybe-uninitialized -O3

[janus at gcc dot gnu.org]

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

Bug ID: 81889
   Summary: [7 Regression] bogus warnings with
-Wmaybe-uninitialized -O3
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: janus at gcc dot gnu.org
  Target Milestone: ---

Please consider this simple Fortran test case:


module m

   type t
  integer, dimension(:), pointer :: list
   end type

contains

   subroutine s(n, p, Y)
  integer, intent(in) :: n
  type(t) :: p
  real, dimension(:) :: Y

  real, dimension(1:16) :: xx

  if (n > 3) then
 xx(1:n) = 0.
 print *, xx(1:n)
  else
 xx(1:n) = Y(p%list(1:n))
 print *, sum(xx(1:n))
  end if

   end subroutine

end module



When compiled with "gfortran-7 -Wmaybe-uninitialized -O3 -c", it yields:

maybe_uninit.f90:21:0:

  print *, sum(xx(1:n))

Warning: ‘xx[3]’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
maybe_uninit.f90:21:0: Warning: ‘xx[4]’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
maybe_uninit.f90:21:0: Warning: ‘xx[5]’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
maybe_uninit.f90:21:0: Warning: ‘xx[6]’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
maybe_uninit.f90:21:0: Warning: ‘xx[7]’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
maybe_uninit.f90:21:0: Warning: ‘xx[8]’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
maybe_uninit.f90:21:0: Warning: ‘xx[9]’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
maybe_uninit.f90:21:0: Warning: ‘xx[10]’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
maybe_uninit.f90:21:0: Warning: ‘xx[11]’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
maybe_uninit.f90:21:0: Warning: ‘xx[12]’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
maybe_uninit.f90:21:0: Warning: ‘xx[13]’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
maybe_uninit.f90:21:0: Warning: ‘xx[14]’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
maybe_uninit.f90:21:0: Warning: ‘xx[15]’ may be used uninitialized in this
function [-Wmaybe-uninitialized]


Obviously no value that is used is actually uninitialized. gfortran 6 and
earlier does not show these warnings. Also decreasing the optimization level
makes them disappear.

[Bug c++/26748] gimplify_expr_stmt in cp-gimplifer.c does warnings

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-08-18
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Eric Gallager  ---
(In reply to Andrew Pinski from comment #0)
> I don't have a testcase but gimplify_expr_stmt produces warnings:
> warning (OPT_Wextra, "statement with no effect");
> ...
>   else if (warn_unused_value)
> warn_if_unused_value (stmt, input_location);

WAITING on a testcase

[Bug c++/49224] [C++0x] Scoped enumeration instantiated even if not required

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-18
 Ever confirmed|0   |1

--- Comment #2 from Eric Gallager  ---
Actually scratch that, my version of clang is old so it doesn't default to
c++11. When I manually force -std=c++0x, clang accepts the code, while g++
still rejects it:

$ /usr/local/bin/g++ -c -Wall -Wextra -pedantic -std=c++0x 49224.cc
49224.cc: In instantiation of ‘struct A’:
49224.cc:9:9:   required from here
49224.cc:3:13: error: ‘value’ is not a member of ‘int’
  enum class B {
 ^
49224.cc: In function ‘int main()’:
49224.cc:9:9: warning: unused variable ‘a’ [-Wunused-variable]
  A a;
 ^
$ /sw/opt/llvm-3.1/bin/clang++ -c -Wall -Wextra -pedantic -std=c++0x 49224.cc
49224.cc:9:9: warning: unused variable 'a' [-Wunused-variable]
A a;
   ^
1 warning generated.
$

So confirming then.

[Bug c++/49224] [C++0x] Scoped enumeration instantiated even if not required

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
(In reply to Johannes Schaub from comment #0)
> GCC should not instantiate the definition of the scoped enumeration:
> 
> template
> struct A {
>   enum class B {
> X = T::value
>   };
> };
> 
> int main() {
>   A a;
> }
> 
> GCC error:
> 
> main1.cpp: In instantiation of ‘A’:
> main1.cpp:9:10:   instantiated from here
> main1.cpp:3:14: error: ‘value’ is not a member of ‘int’
> 
> This code looks well-formed. Only if we look into the enumeration, as
> "A::B::X", the definition of the enumeration is required to exist and
> thus implicitly instantiated. This is specified at 14.7.1p1 and p2.

Confirmed that g++ rejects it, but clang rejects it too:

$ /usr/local/bin/g++ -c -Wall -Wextra -pedantic 49224.cc
49224.cc: In instantiation of ‘struct A’:
49224.cc:9:9:   required from here
49224.cc:3:13: error: ‘value’ is not a member of ‘int’
  enum class B {
 ^
49224.cc: In function ‘int main()’:
49224.cc:9:9: warning: unused variable ‘a’ [-Wunused-variable]
  A a;
 ^
$ /sw/opt/llvm-3.1/bin/clang++ -c -Wall -Wextra -pedantic 49224.cc
49224.cc:3:7: error: expected identifier or '{'
enum class B {
 ^
49224.cc:3:2: warning: declaration does not declare anything
[-Wmissing-declarations]
enum class B {
^~~~
49224.cc:9:9: warning: unused variable 'a' [-Wunused-variable]
A a;
   ^
2 warnings and 1 error generated.
$

Since I'm not sure if this is intentional or not, I'm leaving it UNCONFIRMED.

[Bug c++/50456] attributes ignored on member templates

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |WORKSFORME

--- Comment #1 from Eric Gallager  ---
It errors for me:

$ /usr/local/bin/g++ -c -Wall -Wextra -pedantic -O2 50456.cc
50456.cc: In function ‘int main(int, char**)’:
50456.cc:8:15: warning: unused parameter ‘argc’ [-Wunused-parameter]
 int main (int argc, char *argv[]) {
   ^~~~
50456.cc:8:32: warning: unused parameter ‘argv’ [-Wunused-parameter]
 int main (int argc, char *argv[]) {
^
50456.cc:10:28: error: call to ‘Object::should_error’ declared with
attribute error: Calling this function should trigger a compiler error
  FloatObject::should_error (7);
  ~~^~~
$

[Bug c/81887] pragma omp ordered simd ignored under -fopenmp-simd

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
See also PR81877 for some discussion and an example where SLP vectorization can
break 'ordered'.

[Bug c++/81888] [7/8 Regression] Structured bindings stopped working

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
  Known to work||7.1.0
   Keywords||rejects-valid
   Last reconfirmed||2017-08-18
 Ever confirmed|0   |1
Summary|Structured bindings stopped |[7/8 Regression] Structured
   |working |bindings stopped working
   Target Milestone|--- |7.3
  Known to fail||7.2.0

--- Comment #1 from Richard Biener  ---
Confirmed.  The feature was new in GCC 7.

[Bug ipa/81877] [7/8 Regression] Incorrect results with lto and -fipa-cp and -fipa-cp-clone

[rguenther at suse dot de]

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

--- Comment #12 from rguenther at suse dot de  ---
On Fri, 18 Aug 2017, amonakov at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81877
> 
> --- Comment #11 from Alexander Monakov  ---
> (In reply to Richard Biener from comment #10)
> > Now - for refs that have an invariant address in such loop the interleaving
> > effectively means that they are independent even in the same iteration. 
> 
> Not if there's no "other iteration", i.e. runtime iteration count is 1.

Not sure about this, I interpret 'ivdep' as there's no dependence for
any number of iterations.

> [...]
> > for example.  I suppose it's not their intent.  So maybe there's an
> > additional
> > restriction on the interleaving?  Preserve iteration order of individual
> > stmts?  That would prevent autopar in face of just ivdep for example.
> > 
> > Note that any "handle must-defs 'correctly'" writing is inherently fishy.
> 
> I think you're saying that pragma-ivdep and do-concurrent are too hand-wavy
> about how the compiler may or must privatize variables, whether it must detect
> and handle reductions/inductions etc. But note that LIM is keying on 
> 'simdlen',
> and simdlen is also set by OpenMP-SIMD which is more rigorous in that regard,
> i.e. privatization is explicit in GIMPLE. And there I believe LIM does not 
> have
> the license to disregard may-alias relations *unless* it verifies that loop
> iterates at least twice and repeated writes are UB. On this example:

Yeah, the middle-end uses safelen which is also used for simdlen.  It has
to adhere to the most conservative definition.

> void g(int p, int *out)
> {
>   int x, y = 0, *r = p ?  : 
>   unsigned n = 0;
>   asm("" : "+r" (n));
> #pragma omp simd
>   for (int i = 0; i <= n; i++)
> {
> //#pragma omp ordered simd
>   x = 42;
>   out[i] = *r;
> }
> }
> 
> I believe LSM is wrong for n=0, and for any n if the pragma-ordered is
> uncommented.

I see.  I wonder if we handle pramga-ordered correctly in vectorization
for say

#pragma omp simd
  for (int i = 0; i <= n; i++)
{
#pragma omp ordered simd
  out[i+2] = 0;
  out[i+1] = 1;
  out[i] = 2;
}

I believe we vectorize this with SLP and unrolling with VF 12 as

   out[i..i+3] = {2, 1, 0, 2};
   out[i+4..i+7] = {1, 0, 2, 1};
   out[i+8..i+11] = {0, 2, 1, 0};

I guess "at the same time" fulfils 'ordered' but does splitting
like above do?  That moves out[i+3] store before out[i+5].

The safest thing would be to remove safelen handling from invariant
motion.

More rigorously defining the semantic of loop->safelen (the
middle-end term) is necessary nevertheless.  I believe omp ordered
doesn't have any middle-end representation?

[Bug libstdc++/81885] operator-> not checked by -D_GLIBCXX_ASSERTIONS

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
In fact it's the idiomatic way to get a real pointer from any kind of smart
pointer, e.g. fancy pointers used by allocators (which don't necessarily have a
get member function).

There's even a proposal to standardize a helper utility for doing it, see
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0653r1.html

It might not be so common for unique_ptr but it's still not dangerous, or
deserving of an assertion. If the returned pointer is dereferenced you'll get a
segfault anyway, so the benefit of an assertion is minimal. It doesn't prevent
any bugs.

[Bug c++/50169] "new struct X {{}};" incorrectly treated as an invalid struct-definition

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
EDG rejects it too:

"gr.cc", line 3: error: expected a declaration
 new struct A {{ }}; 
   ^

"gr.cc", line 3: error: type definition is not allowed
 new struct A {{ }}; 
 ^

2 errors detected in the compilation of "gr.cc".


VC++ accepts it though.

I suggest taking it to WG21 as a core issue.

[Bug tree-optimization/81884] [6/7/8 Regression] Invalid code generation with zero size arrays or flexible array members

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Attachment #42000|0   |1
is obsolete||

--- Comment #4 from Richard Biener  ---
Created attachment 42003
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42003=edit
updated patch

[Bug tree-optimization/81884] [6/7/8 Regression] Invalid code generation with zero size arrays or flexible array members

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Regresses gfortran.dg/reassoc_4.f because we no longer DSE

@@ -207,6 +207,7 @@
   _28 = *weight_94(D);
   _29 = _27 * _28;
   _30 = _10 + _29;
+  *s_91(D)[_9] = _30;
   _173 = _12 + 9;
   _174 = _17 + _173;
   _175 = _19 + _174;
@@ -226,6 +227,7 @@
   _193 = _189 * _192;
   _194 = _28 * _193;
   _195 = _185 + _194;
+  *s_91(D)[_9] = _195;
...

so the restriction is too broad.  Now the question is if we want to allow

struct S { int a[0]; };
struct S (*p)[1];

and (*p)[0].a[4].  Or array of size n and (*p)[n-1].a[4]...

[Bug c++/81888] New: Structured bindings stopped working

[antoshkka at gmail dot com]

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

Bug ID: 81888
   Summary: Structured bindings stopped working
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antoshkka at gmail dot com
  Target Milestone: ---

The following code worked well on GCC-7.1, but fails on GCC-7.2 with
-std=c++17:



struct do_not_define_std_tuple_size_for_me {
  bool test1 = true;
};

template 
bool is_structured_bindings_work() noexcept {
  auto [a] = T{};
  return a;
}

const bool do_not_use =
is_structured_bindings_work();



Error message:
error: invalid initializer for structured binding declaration
   auto [a] = T{};
^~~

Fix from Bug 78939 does not resolves the issue. Clang-4.0 and GCC-7.1 compile
the code well.

[Bug libstdc++/81885] operator-> not checked by -D_GLIBCXX_ASSERTIONS

[joerg.rich...@pdv-fs.de]

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

--- Comment #2 from Jörg Richter  ---
Okay, I see your point. But I think calling operator->() to get the pointer is
not a very common use-case. Its more like get() is the right function for this
task.

[Bug c++/45033] "delete" does overload resolution for class operands, but shouldn't.

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Clang only rejects it in C++98 or C++11 mode, it accepts it for C++14.

EDG accepts it unconditionally.

[Bug libstdc++/81885] operator-> not checked by -D_GLIBCXX_ASSERTIONS

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Jonathan Wakely  ---
No, because there's nothing wrong with calling operator-> on a null unique_ptr:

std::unique_ptr p;
int* pp = p.operator->();

I'd be more inclined to remove the pedantic assertion in debug mode.

[Bug c++/50445] Rejects use of constant expression using a pointer non-type template parameter

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-08-18
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
The error message is now:

$ /usr/local/bin/g++ -c -Wall -Wextra -pedantic 50445.cc
50445.cc: In instantiation of ‘const int X<(& values)>::val0’:
50445.cc:7:22:   required from here
50445.cc:4:19: error: the value of ‘values’ is not usable in a constant
expression
  static int const val0 = values[0];
   ^~~~
50445.cc:1:18: note: ‘values’ was not declared ‘constexpr’
 extern int const values[] = { 1, 2, 3 };
  ^~
50445.cc:7:26: error: size of array ‘array’ is not an integral
constant-expression
 int array[X::val0];
  ^
$

...which I think clears things up. Although maybe the note saying 'values' was
not declared 'constexpr' could have a fix-it hint added to it showing where to
insert the 'constexpr'? Putting in WAITING to see what the reporter thinks.

[Bug c++/50169] "new struct X {{}};" incorrectly treated as an invalid struct-definition

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
(In reply to Johannes Schaub from comment #0)
> The following looks like valid code:
> 
>  struct A { int a; }; 
>  int main() { 
>new struct A {{ }}; 
>  }
> 
> The type-specifier-seq "struct A" is followed by a braced-init-list "{{}}".
> But GCC says:
> 
> main1.cpp: In function 'int main()':
> main1.cpp:3:16: error: types may not be defined in a new-type-id
> main1.cpp:3:17: error: expected unqualified-id before '{' token
> 
> As far as I can see, I would only define a new type if I would say:
> 
> new struct A { };
> 
> But the two-braces disambiguates it.

Confirmed that g++ rejects it, but clang++ rejects it too:

$ /usr/local/bin/g++ -c -Wall -Wextra -pedantic 50169.cc
50169.cc: In function ‘int main()’:
50169.cc:3:15: error: types may not be defined in a new-type-id
  new struct A {{ }};
   ^
50169.cc:3:16: error: expected unqualified-id before ‘{’ token
  new struct A {{ }};
^
$ /sw/opt/llvm-3.1/bin/clang++ -c -Wall -Wextra -pedantic 50169.cc
50169.cc:3:16: error: expected member name or ';' after declaration specifiers
new struct A {{ }}; 
  ^
50169.cc:3:13: error: 'A' can not be defined in a type specifier
new struct A {{ }}; 
   ^
2 errors generated.
$

...so I'm not sure if it's an incorrect treatment or not...

(In reply to Ville Voutilainen from comment #1)
> Trying
> 
> struct A { int a; }; 
>  int main() { 
>new (struct A) {{ }}; 
>  }
> 
> gives
> 
> internal compiler error: in cxx_eval_bare_aggregate, at cp/semantics.c:6601
> 

I can't reproduce this ICE with gcc8...

I guess I'll leave this in UNCONFIRMED for now.