[Bug fortran/77506] New: stamdard for f2008 does not allow CHARACTER(LEN=*) in array constructor

[urbanjost at comcast dot net]

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

Bug ID: 77506
   Summary: stamdard for f2008 does not allow CHARACTER(LEN=*) in
array constructor
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: urbanjost at comcast dot net
  Target Milestone: ---

I posted to fortran.comp.org a question on whether LEN=* was allowed in an
array
constructor. The concensus as that it is not standard, but gfortran 5.0.4
allows it without reporting it when -std=f2008 option is used. The dialog from
the newgroup (including two very short example programs) follows:


Can "CHARACTER(LEN=*)" be used in an array constructor? 

 The standard appears to state strings have to be the same length in an array
constructor 
 unless a length type parameter is specified (NOTE 4.74).  And a type-spec
cannot contain 
 a deferred type parameter LEN=:. I thought that C418 also prohibited LEN=*,
but 
 gfortran 5.4.0 appears to allow LEN=* as a length type parameter. Is this an
extension 
 or standard?  If standard, should the resulting length of the elements be
determined by 
 the longest value in the array constructor or by the length of the first
element or must 
 all values be the same length? This test program and it's output shows that in
this 
 particular programming environment (gfortran 5.4.0) that LEN=* is allowed and
that the 
 resulting array has elements trimmed to the length of the first element length 
 when the elements in the constructor are deferred length. 

 More specifically, can anyone clarify if the following is a standard program? 
> 
>   character(len=:),allocatable :: textblock(:) 
>   ! constants of same length 
>   ! does LEN=* violate C418? 
>   textblock=[ character(len=*) :: 'abc   ', '123456'] 
>   write(*,'(a)')textblock 
>   end 
> 
>   Output is: 
>   abc 
>   123456 
> 
 Or, is this standard? 
>   character(len=:),allocatable :: all1,all2 
>   ! deferred of different lengths in this case 
>   all1='ABC' 
>   all2='abcdefghij' 
>   textblock=[ character(len=*) :: all1, all2] 
>   write(*,'(a)')textblock 
>   end 
> 
Output is: 
>   abc 
>   ABC 

References: 
> 
>NOTE 4.74 
>An example of an array constructor that specifies a length type parameter: 
> 
>   [ CHARACTER(LEN=7) :: 'Takata', 'Tanaka', 'Hayashi' ] 
> 
>In this constructor, without the type specification, it would have been 
> necessary to specify all of the constants 
>with the same character length. 
> 

> C418  (R420 R421 R422) A type-param-value of * shall be used only 
> · to declare a dummy argument, 
> · to declare a named constant, 
> · in the type-spec of an ALLOCATE statement wherein each allocate-object 
> is a dummy argument of type 
>   CHARACTER with an assumed character length, 
> · in the type-spec or derived-type-spec of a type guard statement 
> (8.1.9), or 
> · in an external function, to declare the character length parameter of 
> the function result. 

!
 

Ian Harvey   

Sep 6 (34 minutes ago) 

That use of LEN=* is not standard conforming - as the constraint you 
mention and quote below indicates. 

I expect that the lack of diagnostic is just an oversight with that 
compiler, rather than a deliberate extension. 

(Another compiler I tried died with an ICE, so it is a common oversight!) 

The normative requirement for the items in an array constructor to have 
the same corresponding length parameters, in the absence of a leading 
/type-spec/, is in F2008 4.8p2, as modified by TC2. 

None of the programs are conforming, because of the above.

[Bug fortran/77505] New: Negative character length not treated as LEN=0

[urbanjost at comcast dot net]

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

Bug ID: 77505
   Summary: Negative character length not treated as LEN=0
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: urbanjost at comcast dot net
  Target Milestone: ---

From section 4.4.5.2-5 of the f2008 standard, I think negative character
lengths
should be treated as LEN=0. In the following sample, if I enter a negative
value
the code gets a segmentation fault using gfortran 5.4.0 on Cygwin, at least.

program rabbithole
! 4.4.5.2-5 If the character length parameter value evaluates to a negative
value, the length of character entities declared is zero. 
implicit none
character(len=:),allocatable:: text_block(:)
integer :: i
integer :: ii
character(len=10)   :: cten='abcdefghij'
character(len=20)   :: ctwenty='abcdefghijabcdefghij'
   write(*,*)'DOES A NEGATIVE VALUE ACT LIKE LEN=0? (4.4.5.2-5)'
   write(*,*)'ENTER NEGATIVE LENGTH '  ! enter a negative number to be mean
   read(*,*)ii
   text_block=[ character(len=ii) :: cten, ctwenty ] 
   write(*,*)'WRITE IT'
   write(*,'(a)')(trim(text_block(i)),i=1,size(text_block))
end program rabbithole

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

Backtrace for this error:
#0  0x
#1  0x
#2  0x
#3  0x
#4  0x
#5  0x
#6  0x
#7  0x
#8  0x
#9  0x
#10  0x
#11  0x
#12  0x
#13  0x
/home/urbanjs/.twm/scripts_daily/quiet: line 8: 23784 Segmentation fault 
(core dumped) $COMMAND

CYGWIN_NT-10.0 buzz 2.6.0(0.304/5/3) 2016-08-31 14:32 x86_64 Cygwin

GNU Fortran (GCC) 5.4.0
Copyright (C) 2015 Free Software Foundation, Inc.

[Bug fortran/77504] "is used uninitialized" with allocatable string and array constructors

[urbanjost at comcast dot net]

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

urbanjost at comcast dot net changed:

   What|Removed |Added

 CC||urbanjost at comcast dot net

--- Comment #5 from urbanjost at comcast dot net ---
The other duplicate candidates indicate "Maybe" uninitialized, while this case
says definitively that it is uninitialized. Perhaps this is different?

[Bug middle-end/10138] warn for uninitialized arrays passed as const* arguments

[msebor at gcc dot gnu.org]

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

--- Comment #26 from Martin Sebor  ---
It seems that it should be possible to enhance the warn_uninitialized_vars
function in tree-ssa-uninit.c to detect this case by iterating over a callee's
arguments and warn on uninitialized variables whose address is passed to it via
a const pointer parameter.

[Bug middle-end/10138] warn for uninitialized arrays passed as const* arguments

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

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

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

[msebor at gcc dot gnu.org]

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

Bug 70987 Summary: missing -Wuninitialized calling built-in string functions 
with an uninitialized argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70987

   What|Removed |Added

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

[Bug middle-end/70987] missing -Wuninitialized calling built-in string functions with an uninitialized argument

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Sebor  ---
I agree this bug can be handled as a duplicate of bug 10138.  It makes sense to
issue a "may be uninitialized" warning when passing the address of a
uninitialized local variable to a function that takes a const pointer (or const
reference in C++) since the called function is most likely going to read the
value of the variable.

It seems that it should be possible to enhance the warn_uninitialized_vars
function in tree-ssa-uninit.c to detect this case.  If I have time I'll try to
look into it.

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

[Bug libfortran/77393] [7 Regression] Revision r237735 changed the behavior of F0.0

[jvdelisle at gcc dot gnu.org]

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

--- Comment #13 from Jerry DeLisle  ---
Author: jvdelisle
Date: Tue Sep  6 23:22:26 2016
New Revision: 240018

URL: https://gcc.gnu.org/viewcvs?rev=240018=gcc=rev
Log:
2016-09-06  Jerry DeLisle  

PR libgfortran/77393
* io/write_float.def (build_float_string): Recognize when the
result will not fit in the user provided, star fill, and exit
early.

* gfortran.dg/fmt_f0_2.f90: Update test.
* gfortran.dg/fmt_f0_3.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/fmt_f0_3.f90
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/fmt_f0_2.f90
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/write_float.def

[Bug c++/33952] -Wfatal-errors truncates multi-line error messages.

[gcc-bugzilla at contacts dot eelis.net]

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

--- Comment #5 from Eelis  ---
(In reply to David Malcolm from comment #4)
> Eelis: FWIW, gcc has a -fmax-errors=n option; I wonder if setting that to 1
> might be a better fit for geordi?  (just thinking aloud here).

It also truncates the error in the testcase.

[Bug c++/33952] -Wfatal-errors truncates multi-line error messages.

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #4 from David Malcolm  ---
(In reply to Eelis from comment #2)
> Then perhaps I ought to explain what I'm using -Wfatal-errors for.
> 
> I wrote an IRC bot called geordi ( http://www.eelis.net/geordi ) that
> accepts lines of C++ code, compiles them with g++, and either reports the
> first compilation error or proceeds to run the resulting program and report
> its output. Geordi has proved to be an extremely useful demonstration tool
> that is now used in several C++ channels, including Freenode's ##c++ and
> ##iso-c++.
> 
> Since geordi only reports the first error (if any), it passes -Wfatal-errors
> to g++ to not waste time compiling further (response time is very important
> here). Unfortunately, this means that it currently reports truncated errors
> for snippets like the one I mentioned.

Eelis: FWIW, gcc has a -fmax-errors=n option; I wonder if setting that to 1
might be a better fit for geordi?  (just thinking aloud here).

[Bug target/77493] [6/7 Regression] -fcrossjumping (-O2) on ppc64le causes segfaults (jump to 0x0) (first bad r230091)

[david.abdurachmanov at gmail dot com]

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

--- Comment #10 from David Abdurachmanov  
---
We have been bitten by DSE with TBB already on GCC 6.2.0.

I decided to try -fno-lifetime-dse on the first bad commit and got some
surprising results. Now it fails with:

pure virtual method called
terminate called without an active exception

In this case we have a standard library container with 7 elements,
std::shared_ptr, where TrackingRecHit is abstract class, which
has:

  virtual int dimension() const = 0;

If I dump the actual type: typeid(*(x.get())).name() the actual object is of
MuonTransientTrackingRecHit type.

Then the code does std::stable_sort on the collection and now in some cases
MuonTransientTrackingRecHit changes to TrackingRecHit (abstract class). Thus we
are really calling pure virtual method.

This does not happen on x86_64.

I guess, this could be caused by actual MuonTransientTrackingRecHit being
destroyed if the last std::shared_ptr point to it goes away.

DUMP_BEFORE: std::shared_ptr
DUMP_BEFORE_TYPE: MuonTransientTrackingRecHit
DUMP_BEFORE: std::shared_ptr
DUMP_BEFORE_TYPE: MuonTransientTrackingRecHit
DUMP_BEFORE: std::shared_ptr
DUMP_BEFORE_TYPE: MuonTransientTrackingRecHit
DUMP_BEFORE: std::shared_ptr
DUMP_BEFORE_TYPE: MuonTransientTrackingRecHit
DUMP_BEFORE: std::shared_ptr
DUMP_BEFORE_TYPE: MuonTransientTrackingRecHit
DUMP_BEFORE: std::shared_ptr
DUMP_BEFORE_TYPE: MuonTransientTrackingRecHit
DUMP_BEFORE: std::shared_ptr
DUMP_BEFORE_TYPE: MuonTransientTrackingRecHit

// after std::stable_sort

DUMP: std::shared_ptr
DUMP_TYPE: MuonTransientTrackingRecHit
DUMP: std::shared_ptr
DUMP_TYPE: MuonTransientTrackingRecHit
DUMP: std::shared_ptr
DUMP_TYPE: TrackingRecHit
DUMP: std::shared_ptr
DUMP_TYPE: TrackingRecHit
DUMP: std::shared_ptr
DUMP_TYPE: MuonTransientTrackingRecHit
DUMP: std::shared_ptr
DUMP_TYPE: TrackingRecHit
DUMP: std::shared_ptr
DUMP_TYPE: TrackingRecHit

SIZE: 7

[Bug debug/57519] DW_TAG_imported_declaration put in wrong class (base class instead of derived class)

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #13 from Dominique d'Humieres  ---
Closing as FIXED.

[Bug debug/77389] FAIL: g++.dg/debug/dwarf2/template-params-12f.C -std=gnu++11 scan-assembler-times DIE \\\\([^\\n]*\\\\) DW_TAG_template_value_param ...

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Dominique d'Humieres  ---
Closing as FIXED.

[Bug debug/57519] DW_TAG_imported_declaration put in wrong class (base class instead of derived class)

[dominiq at gcc dot gnu.org]

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

--- Comment #12 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Tue Sep  6 22:26:11 2016
New Revision: 240017

URL: https://gcc.gnu.org/viewcvs?rev=240017=gcc=rev
Log:
2016-09-07  Dominique d'Humieres  

PR debug/57519
* g++.dg/debug/dwarf2/imported-decl-2.C: Likewise.


Modified:
branches/gcc-5-branch/gcc/testsuite/ChangeLog
branches/gcc-5-branch/gcc/testsuite/g++.dg/debug/dwarf2/imported-decl-2.C

[Bug debug/57519] DW_TAG_imported_declaration put in wrong class (base class instead of derived class)

[dominiq at gcc dot gnu.org]

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

--- Comment #11 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Tue Sep  6 22:22:58 2016
New Revision: 240016

URL: https://gcc.gnu.org/viewcvs?rev=240016=gcc=rev
Log:
2016-09-07  Dominique d'Humieres  

PR debug/57519
* g++.dg/debug/dwarf2/imported-decl-2.C: Likewise.


Modified:
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/testsuite/g++.dg/debug/dwarf2/imported-decl-2.C

[Bug debug/77389] FAIL: g++.dg/debug/dwarf2/template-params-12f.C -std=gnu++11 scan-assembler-times DIE \\\\([^\\n]*\\\\) DW_TAG_template_value_param ...

[dominiq at gcc dot gnu.org]

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

--- Comment #5 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Tue Sep  6 22:18:54 2016
New Revision: 240015

URL: https://gcc.gnu.org/viewcvs?rev=240015=gcc=rev
Log:
2016-09-07  Dominique d'Humieres  

PR debug/77389
* g++.dg/debug/dwarf2/template-params-12g.C: Pass -gno-strict-dwarf
in dg-options.

PR debug/57519
* g++.dg/debug/dwarf2/imported-decl-2.C: Likewise.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/debug/dwarf2/imported-decl-2.C
trunk/gcc/testsuite/g++.dg/debug/dwarf2/template-params-12g.C

[Bug debug/57519] DW_TAG_imported_declaration put in wrong class (base class instead of derived class)

[dominiq at gcc dot gnu.org]

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

--- Comment #10 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Tue Sep  6 22:18:54 2016
New Revision: 240015

URL: https://gcc.gnu.org/viewcvs?rev=240015=gcc=rev
Log:
2016-09-07  Dominique d'Humieres  

PR debug/77389
* g++.dg/debug/dwarf2/template-params-12g.C: Pass -gno-strict-dwarf
in dg-options.

PR debug/57519
* g++.dg/debug/dwarf2/imported-decl-2.C: Likewise.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/debug/dwarf2/imported-decl-2.C
trunk/gcc/testsuite/g++.dg/debug/dwarf2/template-params-12g.C

[Bug libfortran/77393] [7 Regression] Revision r237735 changed the behavior of F0.0

[jvdelisle at gcc dot gnu.org]

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

--- Comment #12 from Jerry DeLisle  ---
Created attachment 39577
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39577=edit
Patch for testing, fixes comment #2?

This patch for testing.  I have tested on x86_64-unknown-freebsd12.0 which also
exhibited the issue with an invalid memory reference.

[Bug target/69255] ICE on x86_64-linux-gnu in "emit_move_insn"

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Tue Sep  6 20:30:57 2016
New Revision: 240014

URL: https://gcc.gnu.org/viewcvs?rev=240014=gcc=rev
Log:
PR target/69255
* config/i386/i386.c (ix86_expand_builtin): For builtin with
unsupported or unknown ISA, use expand_call.

* gcc.target/i386/pr69255-1.c: New test.
* gcc.target/i386/pr69255-2.c: New test.
* gcc.target/i386/pr69255-3.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr69255-1.c
trunk/gcc/testsuite/gcc.target/i386/pr69255-2.c
trunk/gcc/testsuite/gcc.target/i386/pr69255-3.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/77504] "is used uninitialized" with allocatable string and array constructors

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
Also pr66459.

[Bug fortran/77504] "is used uninitialized" with allocatable string and array constructors

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
Another candidate for duplicate: pr56670.

[Bug fortran/77504] "is used uninitialized" with allocatable string and array constructors

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  ---
Similar problem in/duplicate of pr60500.

[Bug fortran/77504] "is used uninitialized" with allocatable string and array constructors

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-06
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from 4.8 up to trunk (7.0). I have the feeling that it is a
duplicate.

[Bug rtl-optimization/77499] Regression after code-hoisting, due to combine pass failing to evaluate known value range

[segher at gcc dot gnu.org]

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

--- Comment #2 from Segher Boessenkool  ---
(In reply to avieira from comment #0)
> PS: I am not sure I completely understand the way the last_set_value stuff
> works for pseudo's in combine, but it looks to me like each instruction is
> visited in a top down order per basic block again in a top-down order.

Yeah.

> And
> each pseudo will have its 'last_set_value' according to the last time that
> register was seen being set, without any regards to loop or proper dataflow
> analysis. Can anyone explain to me how this doesnt go horribly wrong?

It only allows a last set value when either:
- It is set in the same extended basic block, but before this insn;
- The register is set exactly once, and is not a function parameter.

This might also be why it optimises less well now for you?

[Bug tree-optimization/77503] [7 regression] ICE in vect_transform_stmt compiling postgresql

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||amker at gcc dot gnu.org

--- Comment #9 from Markus Trippelsdorf  ---
Started with r239416:

commit 56fb8e9de1cba491893b249e5db6bf4d206e8f31
Author: amker 
Date:   Fri Aug 12 14:58:20 2016 +

PR tree-optimization/69848
* tree-vectorizer.h (enum vect_def_type): New condition reduction
type CONST_COND_REDUCTION.
* tree-vect-loop.c (vectorizable_reduction): Support new condition
reudction type CONST_COND_REDUCTION.

gcc/testsuite
PR tree-optimization/69848
* gcc.dg/vect/vect-pr69848.c: New test.

[Bug c/77336] -Wsuggest-attribute=format warning overly simplistic

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
Author: msebor
Date: Tue Sep  6 19:23:25 2016
New Revision: 240013

URL: https://gcc.gnu.org/viewcvs?rev=240013=gcc=rev
Log:
PR c/77336 -  -Wsuggest-attribute=format warning overly simplistic

gcc/c-family/ChangeLog:

PR c/77336
* c-format.c (check_function_format): Avoid issuing warnings for
functions unless they call format functions with non-constant
format strings.

gcc/testsuite/ChangeLog:

PR c/77336
* gcc.dg/format/miss-7.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/format/miss-7.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-format.c
trunk/gcc/testsuite/ChangeLog

[Bug c/77336] -Wsuggest-attribute=format warning overly simplistic

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
Fixed by r240013.

[Bug fortran/77504] New: "is used uninitialized" with allocatable string and array constructors

[tkoenig at gcc dot gnu.org]

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

Bug ID: 77504
   Summary: "is used uninitialized" with allocatable string and
array constructors
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

Original bug report from John Urban, from

https://gcc.gnu.org/ml/fortran/2016-09/msg00015.html

program testit
implicit none
character(len=:),allocatable :: help_text(:)
integer  :: i
   help_text=[ CHARACTER(LEN=80) :: &
   'defines length and size with different length expressions. Yeah!',&
   '   a',&
   '   b',&
   '   d',&
   '']
   write(*,'(a)')repeat('=',len(help_text(1))) !assumed at least size one
   write(*,'(a)')(trim(help_text(i)),i=1,size(help_text))
   write(*,'(a)')repeat('=',len(help_text(1))) !assumed at least size one
end program testit

yields:

fortran -Wuninitialized a.f90
a.f90:3:0:

 character(len=:),allocatable :: help_text(:)

Warning: '.help_text' is used uninitialized in this function [-Wuninitialized]

with a current trunk.

Valgrind does not complain, so it might be spurious

[Bug bootstrap/70473] genautomata memory footprint for arm

[lly.dev at gmail dot com]

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

--- Comment #14 from Leonid Lisovskiy  ---
(In reply to ktkachov from comment #13)
> Marking this as fixed then. Thanks for testing.

Could you repeat the same optimizations for MIPS (`xlp_cpu', `xlp_fpu')?
Should I create the separate PR for this task?

[Bug tree-optimization/77503] [7 regression] ICE in vect_transform_stmt compiling postgresql

[tulipawn at gmail dot com]

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

--- Comment #8 from PeteVine  ---
Ditto on ARM:
$ gcc -O3 -mfpu=neon pr77503.c , and so on.

but gcc 6 seems to work fine.

[Bug tree-optimization/77503] [7 regression] ICE in vect_transform_stmt compiling postgresql

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Target|aarch64-linux-gnu   |aarch64-linux-gnu, x86_64

--- Comment #7 from Uroš Bizjak  ---
(In reply to Markus Trippelsdorf from comment #6)
> markus@x4 tmp % cat fsmpage.i
> extern void d(void);
> void a() {
>   char *b;
>   char c = 0;
>   for (; b < (char *)a; b++) {
> if (*b)
>   c = 1;
> *b = 0;
>   }
>   if (c)
> d();
> }

Also fails on x86_64 with -O3 -mavx2:

$ /ssd/uros/gcc-build/gcc/cc1 -O3 -mavx2 -quiet pr77503.c 
pr77503.c: In function ‘a’:
pr77503.c:2:6: internal compiler error: in vect_transform_stmt, at
tree-vect-stmts.c:8424
 void a() {
  ^
0xd94faa vect_transform_stmt(gimple*, gimple_stmt_iterator*, bool*, _slp_tree*,
_slp_instance*)
/home/uros/gcc-svn/trunk/gcc/tree-vect-stmts.c:8424
0xd9c229 vect_transform_loop(_loop_vec_info*)
/home/uros/gcc-svn/trunk/gcc/tree-vect-loop.c:7045
0xdb9d96 vectorize_loops()
/home/uros/gcc-svn/trunk/gcc/tree-vectorizer.c:585
Please submit a full bug report,

[Bug tree-optimization/77503] [7 regression] ICE in vect_transform_stmt compiling postgresql

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|middle-end  |tree-optimization
 Ever confirmed|0   |1

--- Comment #6 from Markus Trippelsdorf  ---
markus@x4 tmp % cat fsmpage.i
extern void d(void);
void a() {
  char *b;
  char c = 0;
  for (; b < (char *)a; b++) {
if (*b)
  c = 1;
*b = 0;
  }
  if (c)
d();
}

markus@x4 tmp % /var/tmp/gcc_build_dir_/gcc/cc1 -fpreprocessed fsmpage.i -quiet
-dumpbase fsmpage.i -O3
fsmpage.i: In function ‘a’:
fsmpage.i:2:6: internal compiler error: in vect_transform_stmt, at
tree-vect-stmts.c:8424
 void a() {
  ^
0xd570c9 vect_transform_stmt(gimple*, gimple_stmt_iterator*, bool*, _slp_tree*,
_slp_instance*)
../../gcc/gcc/tree-vect-stmts.c:8424
0xd5e7c6 vect_transform_loop(_loop_vec_info*)
../../gcc/gcc/tree-vect-loop.c:7045
0xd7c994 vectorize_loops()
../../gcc/gcc/tree-vectorizer.c:585

[Bug middle-end/77503] [7 regression] ICE in vect_transform_stmt compiling postgresql

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  ---
Reducing ...

[Bug middle-end/77503] [7 regression] ICE in vect_transform_stmt compiling postgresql

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 CC||pinskia at gcc dot gnu.org
   Target Milestone|--- |7.0

[Bug middle-end/77503] [7 regression] ICE in vect_transform_stmt compiling postgresql

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED
 Ever confirmed|1   |0

--- Comment #4 from Andrew Pinski  ---
.

[Bug middle-end/77503] [7 regression] ICE in vect_transform_stmt compiling postgresql

[tulipawn at gmail dot com]

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

--- Comment #3 from PeteVine  ---
Created attachment 39576
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39576=edit
preprocessed fsmpage source

[Bug middle-end/77503] [7 regression] ICE in vect_transform_stmt compiling postgresql

[tulipawn at gmail dot com]

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

PeteVine  changed:

   What|Removed |Added

 Target||aarch64-linux-gnu
 CC||tulipawn at gmail dot com
   Host||aarch64-linux-gnu
  Build||aarch64-linux-gnu

--- Comment #2 from PeteVine  ---
I was getting to that :)

[Bug middle-end/77503] [7 regression] ICE in vect_transform_stmt compiling postgresql

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-09-06
 CC||trippels at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
Please attach the preprocessed fsmpage.i here. See: https://gcc.gnu.org/bugs/

[Bug c++/77502] -Wzero-as-null-pointer-constant : misleading/imprecise messages

[petschy at gmail dot com]

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

--- Comment #1 from petschy at gmail dot com ---
I found another case: initializing an array of structs:

struct X
{
const char* p;
int i;
};

X x[] = {
{ "hello", 0 },
{ 0, 0 }, // !
{ 0, 0 }, // !
{ 0, 0 }  // !
}; // all 3 errors marked here

[Bug middle-end/77503] New: [7 regression] ICE in vect_transform_stmt compiling postgresql

[tulipawn at gmail dot com]

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

Bug ID: 77503
   Summary: [7 regression] ICE in vect_transform_stmt compiling
postgresql
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tulipawn at gmail dot com
  Target Milestone: ---

Trying to build postgresql with GCC7 for a phoronix benchmark, fails:

gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement
-Wendif-labels -Wmissing-format-attribute -Wformat-security -f
no-strict-aliasing -fwrapv -fexcess-precision=standard -O3 -mcpu=cortex-a53
-fomit-frame-pointer -fipa-pta -march=armv8-a+crc -I../../../..
/src/include -D_GNU_SOURCE   -c -o fsmpage.o fsmpage.c
fsmpage.c: In function 'fsm_truncate_avail':
fsmpage.c:313:1: internal compiler error: in vect_transform_stmt, at
tree-vect-stmts.c:8424
 fsm_truncate_avail(Page page, int nslots)
 ^~


Quickest reproduction probably:

$ phoronix-test-suite test pgbench-1.5.1
 LOG:
~/.phoronix-test-suite/installed-tests/pts/pgbench-1.5.1/install-failed.log

$ gcc -v 
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/gcc7/lib/gcc/aarch64-linux-gnu/7.0.0/lto-wrapper
Target: aarch64-linux-gnu
Configured with: /tmp/gcc-7-20160904/configure --enable-languages=c,c++,fortran
--prefix=/usr/gcc7 --program-suffix=-7 --enable-shared --enable-linker-build-id
--libexecdir=/usr/gcc7/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/gcc7/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-libquadmath --enable-plugin
--with-system-zlib --disable-browser-plugin --with-arch-directory=aarch64
--enable-multiarch --enable-fix-cortex-a53-843419 --disable-werror
--enable-checking=release --build=aarch64-linux-gnu --host=aarch64-linux-gnu
--target=aarch64-linux-gnu --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160904 (experimental) (GCC)

[Bug gcov-profile/58306] Broken profiling for unrar sources: error: corrupted value profile: value profile counter (X out of Y) inconsistent with basic-block count

[t.artem at mailcity dot com]

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

--- Comment #46 from Artem S. Tashkinov  ---
(In reply to PeteVine from comment #44)
> In case I was a little unclear, the board freezes, not the binary.

Looks like GCC optimizes the output so much, the board cannot cope with such a
perfect code. ;-)

Jokes aside, I tend to believe that it's either a bug in the kernel or board
components.

[Bug preprocessor/77488] Proposal for __FILENAME_ONLY__

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
> How would that help here?  You obviously pass the address of the string
> literal to the __assert_func or how is the assertion passed, thus it escapes.

With the optimization in place the assert macro could be defined similarly to
the one below.  __builtin_printf is known not to escape string arguments of its
%s directives (or form pointers prior to their beginning).

#define FILE  (__builtin_strrchr (__FILE__, '/') ? __builtin_strrchr (__FILE__,
'/') + 1 : __FILE__)

#define assert(e) ((e) ? (void)0 : (void)(__builtin_printf ("%s:%i: assertion
%s failed\n", FILE, __LINE__, #e), __builtin_abort ()))

To make the optimization more generally applicable (so that it could work with
arbitrary functions including __assert_func) a new attribute might need to be
introduced to tell GCC about the same guarantee.

[Bug preprocessor/77488] Proposal for __FILENAME_ONLY__

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
(In reply to Martin Sebor from comment #3)
> Perhaps it might be possible to generalize the enhancement request to a
> space optimization for GCC to store only the trailing part of strings that
> are ever referenced in the program.  For instance, since in the file below
> only the range [s + 5, s + 10] is ever used it should be possible to store
> just "56789" instead of all of "0123456789" (this would only be possible if
> all computations involving the literal were known and would have to be
> avoided if a pointer to the literal escaped to an external function that
> could derive from it a pointer to the initial substring).
> 
> static const char* const s = "0123456789" + 5;
> 
> void f (void)
> {
>   __builtin_printf ("%s\n", s);
> }

How would that help here?  You obviously pass the address of the string literal
to the __assert_func or how is the assertion passed, thus it escapes.

Though, especially when using autoconf/automake, it really is very easy, not
hard, to tweak the Makefiles to use short paths.  And, in many cases, the
basename of source files isn't unique and sufficient to recognize where the
problem is.  E.g. glibc ships with tons of headers like ,
, ,  etc.

[Bug preprocessor/77488] Proposal for __FILENAME_ONLY__

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #3 from Martin Sebor  ---
Perhaps it might be possible to generalize the enhancement request to a space
optimization for GCC to store only the trailing part of strings that are ever
referenced in the program.  For instance, since in the file below only the
range [s + 5, s + 10] is ever used it should be possible to store just "56789"
instead of all of "0123456789" (this would only be possible if all computations
involving the literal were known and would have to be avoided if a pointer to
the literal escaped to an external function that could derive from it a pointer
to the initial substring).

static const char* const s = "0123456789" + 5;

void f (void)
{
  __builtin_printf ("%s\n", s);
}

[Bug c++/77502] New: -Wzero-as-null-pointer-constant : misleading/imprecise messages

[petschy at gmail dot com]

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

Bug ID: 77502
   Summary: -Wzero-as-null-pointer-constant : misleading/imprecise
messages
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: petschy at gmail dot com
  Target Milestone: ---

Created attachment 39575
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39575=edit
C++ source

g++-7.0.0 -Werror -Wall -Wextra -Wzero-as-null-pointer-constant
20160906-Wzero-as-null-pointer-constant.cpp

20160906-Wzero-as-null-pointer-constant.cpp: In constructor ‘Foo::Foo()’:
20160906-Wzero-as-null-pointer-constant.cpp:10:6: error: zero as null pointer
constant [-Werror=zero-as-null-pointer-constant]
   c(0) // 1
  ^
20160906-Wzero-as-null-pointer-constant.cpp: At global scope:
20160906-Wzero-as-null-pointer-constant.cpp:17:20: error: zero as null pointer
constant [-Werror=zero-as-null-pointer-constant]
  void Fn(char* p = 0); // 2, OK
    ^
20160906-Wzero-as-null-pointer-constant.cpp: In member function ‘void
TBar::Fn(char*) [with T = int]’:
20160906-Wzero-as-null-pointer-constant.cpp:34:9: error: zero as null pointer
constant [-Werror=zero-as-null-pointer-constant]
  br->Fn(); // 3
 ^
20160906-Wzero-as-null-pointer-constant.cpp: In member function ‘void
TBaz::Fn(char*) [with T = int]’:
20160906-Wzero-as-null-pointer-constant.cpp:35:9: error: zero as null pointer
constant [-Werror=zero-as-null-pointer-constant]
  bz->Fn(); // 4
 ^

The issues:

1) 0 is used instead of nullptr when initializing Foo.a ("a(0)"), but the error
marker is at the end of the initializer list, not at the line of the actual
error.

2) The default argument of Fn() in the non-template Bar class is diagnosed OK

3,4) The default argument of Fn() in the template classes TBar and TBaz is
diagnosed, but the error marker is put at the call site, not at the
declaration. This caused me quite some pondering on the production codebase, as
for a largish templated class hierarchy it's not obvious just by looking at the
call site which fn will be actually called.

Debian Jessie, AMD64
$ g++-7.0.0 -v
Using built-in specs.
COLLECT_GCC=g++-7.0.0
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --enable-languages=c,c++ --disable-multilib
--program-suffix=-7.0.0 --disable-bootstrap CFLAGS='-O2 -march=native'
CXXFLAGS='-O2 -march=native'
Thread model: posix
gcc version 7.0.0 20160831 (experimental) (GCC)

[Bug c++/77496] ICE in instantiate_type, at cp/class.c:8270

[bernd.edlinger at hotmail dot de]

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

--- Comment #4 from Bernd Edlinger  ---
(In reply to Bernd Edlinger from comment #3)
> The "correct" test case emits two nearly identical -Wpedantic warnings:
> 

... which is probably OK, given the second one if it is emitted,
points to the instantiation?

[Bug gcov-profile/58306] Broken profiling for unrar sources: error: corrupted value profile: value profile counter (X out of Y) inconsistent with basic-block count

[marxin at gcc dot gnu.org]

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

--- Comment #45 from Martin Liška  ---
(In reply to PeteVine from comment #44)
> In case I was a little unclear, the board freezes, not the binary.

Aarg, got it. That's definitely funny behavior ;)

[Bug c++/77448] Incorrect code generation for calling stack object's method

[nfitzgerald at mozilla dot com]

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

Nick Fitzgerald [:fitzgen] [⏰PDT; UTC-7]  
changed:

   What|Removed |Added

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

--- Comment #2 from Nick Fitzgerald [:fitzgen] [⏰PDT; UTC-7]  ---
Woops! Was dealing with two compilation units that didn't agree on the size of
the struct due to messing up defines. Sorry for wasting your time, and thanks
for your patience!

[Bug gcov-profile/58306] Broken profiling for unrar sources: error: corrupted value profile: value profile counter (X out of Y) inconsistent with basic-block count

[tulipawn at gmail dot com]

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

--- Comment #44 from PeteVine  ---
In case I was a little unclear, the board freezes, not the binary.

[Bug fortran/77501] ICE in gfc_match_generic, at fortran/decl.c:9429

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #1 from Gerhard Steinmetz  
---

More variants :


$ cat z2.f90
module m
   type t
   contains
  generic :: f => g
  generic :: g => f
   end type
end


$ cat z3.f90
module m
   type t
   contains
  generic :: f => g
  generic :: g => g
   end type
end


$ cat z5.f90
module m
   type t
   contains
  generic :: operator(>) => g
  generic :: g => h
   end type
end


$ cat z6.f90
module m
   type t
   contains
  generic :: f => g
  generic :: g => h
  generic :: h => f
   end type
end


$ cat z7.f90
module m
   type t
   contains
  generic :: f => g
  generic :: h => e
  generic :: e => f
   end type
end

[Bug fortran/77501] New: ICE in gfc_match_generic, at fortran/decl.c:9429

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 77501
   Summary: ICE in gfc_match_generic, at fortran/decl.c:9429
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

With invalid code, down to at least 4.8 :
(ambiguous binding skeleton only to trigger an ICE)


$ cat z1.f90
module m
   type t
   contains
  generic :: f => g
  generic :: g => h
   end type
end


$ gfortran-7-20160904 z1.f90
f951: internal compiler error: in gfc_match_generic, at fortran/decl.c:9429
0x681861 gfc_match_generic()
../../gcc/fortran/decl.c:9429
0x6d2f39 match_word_omp_simd
../../gcc/fortran/parse.c:93
0x6d7bc5 match_word
../../gcc/fortran/parse.c:492
0x6d7bc5 decode_statement
../../gcc/fortran/parse.c:492
0x6d8444 next_free
../../gcc/fortran/parse.c:1143
0x6d8444 next_statement
../../gcc/fortran/parse.c:1376
0x6d982c parse_derived_contains
../../gcc/fortran/parse.c:2649
0x6d982c parse_derived
../../gcc/fortran/parse.c:3203
0x6d982c parse_spec
../../gcc/fortran/parse.c:3663
0x6dc998 parse_module
../../gcc/fortran/parse.c:5720
0x6dd389 gfc_parse_file()
../../gcc/fortran/parse.c:6036
0x71f602 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:198

[Bug fortran/77500] New: ICE in gfc_trans_omp_atomic, at fortran/trans-openmp.c:2822

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 77500
   Summary: ICE in gfc_trans_omp_atomic, at
fortran/trans-openmp.c:2822
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

Aborts with ICE down to at least 4.8 :


$ cat z1.f90
program p
   real :: x
!$omp atomic write
   x = f()
!$omp end atomic
end


$ gfortran-7-20160904 -fopenmp z1.f90
z1.f90:3:0:

 !$omp atomic write

internal compiler error: Segmentation fault
0xc2100f crash_signal
../../gcc/toplev.c:336
0x78df67 gfc_trans_omp_atomic
../../gcc/fortran/trans-openmp.c:2822
0x79b37f gfc_trans_omp_directive(gfc_code*)
../../gcc/fortran/trans-openmp.c:4488
0x722987 trans_code
../../gcc/fortran/trans.c:1933
0x7517a8 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6224
0x6dd050 translate_all_program_units
../../gcc/fortran/parse.c:5911
0x6dd050 gfc_parse_file()
../../gcc/fortran/parse.c:6117
0x71f602 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:198

[Bug gcov-profile/58306] Broken profiling for unrar sources: error: corrupted value profile: value profile counter (X out of Y) inconsistent with basic-block count

[marxin at gcc dot gnu.org]

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

--- Comment #43 from Martin Liška  ---
(In reply to PeteVine from comment #42)
> Funnily enough, using `-fprofile-update=atomic` and targeting Cortex-A5/NEON
> immediately leads to a hard-freeze on trying to run the instrumented binary.
> Probably a bug in the outdated kernel. (I've got a screenshot of the xterm
> session if anybody's interested)

Can you please try to attach gdb to the instrumented binary and isolate a place
where it's freezed?

[Bug target/77452] [7 Regression] ICE: in plus_constant, at explow.c:87 with -fno-split-wide-types -mavx512f --param=max-combine-insns=2

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #5 from Uroš Bizjak  ---
Fixed for gcc-6+.

[Bug gcov-profile/58306] Broken profiling for unrar sources: error: corrupted value profile: value profile counter (X out of Y) inconsistent with basic-block count

[tulipawn at gmail dot com]

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

--- Comment #42 from PeteVine  ---
Funnily enough, using `-fprofile-update=atomic` and targeting Cortex-A5/NEON
immediately leads to a hard-freeze on trying to run the instrumented binary.
Probably a bug in the outdated kernel. (I've got a screenshot of the xterm
session if anybody's interested)

[Bug c++/77496] ICE in instantiate_type, at cp/class.c:8270

[bernd.edlinger at hotmail dot de]

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

--- Comment #3 from Bernd Edlinger  ---
The "correct" test case emits two nearly identical -Wpedantic warnings:

One when the template is parsed, and one when the template is instantiated.

The second one is unnecessary, IMHO.

template 
class z : x
{
public:
  bool zz () { return false; }
  int f () { return zz () ? : 1; } // { dg-warning "omitted middle operand" }
};

class t
{
};

int
main ()
{
  z x;
  return x.f ();
}


g++ -Wpedantic  pr77496.C 
pr77496.C: In member function 'int z::f()':
pr77496.C:9:29: warning: ISO C++ does not allow ?: with omitted middle operand
[-Wpedantic]
   int f () { return zz () ? : 1; } // { dg-warning "omitted middle operand" }
 ^
pr77496.C: In instantiation of 'int z::f() [with x = t]':
pr77496.C:20:15:   required from here
pr77496.C:9:27: warning: ISO C++ forbids omitting the middle term of a ?:
expression [-Wpedantic]
   int f () { return zz () ? : 1; } // { dg-warning "omitted middle operand" }
   ^

[Bug rtl-optimization/77499] New: Regression after code-hoisting, due to combine pass failing to evaluate known value range

[avieira at gcc dot gnu.org]

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

Bug ID: 77499
   Summary: Regression after code-hoisting, due to combine pass
failing to evaluate known value range
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: avieira at gcc dot gnu.org
  Target Milestone: ---

Hello,

We are seeing a regression for arm-none-eabi on a Cortex-M7. This regression
was observed after Biener's and Bosscher's GIMPLE code-hoisting patch
(https://gcc.gnu.org/ml/gcc-patches/2016-07/msg00360.html). The example below
will illustrate the regression:

$ cat t.c
unsigned short foo (unsigned short x, int c, int d, int e)
{
  unsigned short y;

  while (c > d)
{
  if (c % 3)
{
 x = (x >> 1) ^ 0xB121U;
}
  else
 x = x >> 1;
  c-= e;
}
  return x;
}

Comparing:
$ arm-none-eabi-gcc -mcpu=cortex-m7 -mthumb -O2 -S t.c 
vs
$ arm-none-eabi-gcc -mcpu=cortex-m7 -mthumb -O2 -S t.c -fno-code-hoisting

Will illustrate that the code-hoisting version has an extra zero_extension of
HImode to SImode. After some digging I found out that during the combine phase,
the no-code-hoisting version is able to recognize that the
'last_set_nonzero_bits' are 0x7fff whereas for the code-hoisted version it
seems to have lost this knowledge.

Looking at the graph dump for the no-code-hoisting t.c.246r.ud_dce.dot I see
the following insns:
23: r125:SI=r113:SI 0>>0x1
24: r111:SI=zero_extend(r125:SI#0)
27: r128:SI=r111:SI^r131:SI
28: r113:SI=zero_extend(r128:SI#0)

These are all in the same basic block. 

For the code-hoisting version we have:

BB A:
...
12: r116:SI=r112:SI 0>>0x1
13: r112:SI=zero_extend(r116:SI#0)
...
BB B:
27: r127:SI=r112:SI^r129:SI
28: r112:SI=zero_extend(r127:SI#0)


Now from what I have observed by debugging the combine pass is that combine
will first combine instructions 23 and 24. 
Here combine is able to optimize away the zero_extend, because in
'reg_nonzero_bits_for_combine' the reg_stat[113] has its 'last_set_value' to
'r0' (the unsigned short argument) and its corresponding
'last_set_nonzero_bits' to 0x. Which means the zero_extend is
pointless. The code-hoisting version also combines 12 and 13, optimizing away
the zero_extend.

However, the next set of instructions is where things get tricky. In the
no-code-hoisting case it will end up combining all 4 instructions one by one
from the top down and it will end up figuring out that the last zero_extend is
also not required. For the code-hoisting case, when it tries to combine 28 with
27 (remember they are not in the basic block as 13 and 14, so it will never try
to combine all 4), it will eventually try to evaluate the nonzero bits based on
r112 and see that the last_set_value for r112 is:
(lshiftrt:SI (clobber:SI (const_int 0 [0]))
(const_int 1 [0x1]))

The last_set_nonzero_bits will be 0x7fff, instead of the expected
0x7fff. This looks like the result of the code in 'record_value_for_reg' in
combine.c that sits bellow the comment:

  /* The value being assigned might refer to X (like in "x++;").  In that
 case, we must replace it with (clobber (const_int 0)) to prevent
 infinite loops.  */

Given that 12 and 13 were combined into:
r112:SI=r112:SI 0>>0x1

This seems to be invalidating the last_set_value and thus leaving us with a
weaker 'last_set_nonzero_bits' which isn't enough to optimize away the
zero_extend.

Any clue on how to "fix" this?

Cheers,
Andre

PS: I am not sure I completely understand the way the last_set_value stuff
works for pseudo's in combine, but it looks to me like each instruction is
visited in a top down order per basic block again in a top-down order. And each
pseudo will have its 'last_set_value' according to the last time that register
was seen being set, without any regards to loop or proper dataflow analysis.
Can anyone explain to me how this doesnt go horribly wrong?

[Bug rtl-optimization/77499] Regression after code-hoisting, due to combine pass failing to evaluate known value range

[avieira at gcc dot gnu.org]

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

avieira at gcc dot gnu.org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org,
   ||segher at gcc dot gnu.org

--- Comment #1 from avieira at gcc dot gnu.org ---
Adding Richard, since this was exposed after Richard's code-hoisting patch and
Segher because I believe the root of the problem might be related to the way
combine works.

[Bug tree-optimization/77498] [7 regression] Performance drop after r239414 on spec2000/172mgrid

[avieira at gcc dot gnu.org]

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

avieira at gcc dot gnu.org changed:

   What|Removed |Added

 Target||arm-none-eabi
 CC||avieira at gcc dot gnu.org

--- Comment #2 from avieira at gcc dot gnu.org ---
I am observing some regressions for arm-none-eabi on a Cortex-M0+ for a popular
embedded benchmark following this patch.

I believe register pressure might also be the root cause of this given the
significant increase of loads and registers from and to the stack. Though I
need to have a better look.

Passing the option -fno-code-hoisting brings the performance numbers back up.

[Bug target/77452] [7 Regression] ICE: in plus_constant, at explow.c:87 with -fno-split-wide-types -mavx512f --param=max-combine-insns=2

[uros at gcc dot gnu.org]

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

--- Comment #4 from uros at gcc dot gnu.org ---
Author: uros
Date: Tue Sep  6 15:33:32 2016
New Revision: 240012

URL: https://gcc.gnu.org/viewcvs?rev=240012=gcc=rev
Log:
Backport from mainline
2016-09-05  Uros Bizjak  

PR rtl-optimization/77452
* explow.c (plus_constant) : Extract scalar constant from
inner-mode reference to a CONST_VECTOR constant in the constant pool.

testsuite/ChangeLog:

Backport from mainline
2016-09-05  Uros Bizjak  

PR rtl-optimization/77452
* gcc.target/i386/pr77452.c: New test.


Added:
branches/gcc-6-branch/gcc/testsuite/gcc.target/i386/pr77452.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/explow.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/77498] [7 regression] Performance drop after r239414 on spec2000/172mgrid

[ysrumyan at gmail dot com]

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

--- Comment #1 from Yuri Rumyantsev  ---
Created attachment 39574
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39574=edit
test-case to reproduce

Need to compile with -O2 -ffast-math to reproduce.

[Bug tree-optimization/77498] New: [7 regression] Performance drop after r239414 on spec2000/172mgrid

[ysrumyan at gmail dot com]

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

Bug ID: 77498
   Summary: [7 regression] Performance drop after r239414 on
spec2000/172mgrid
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ysrumyan at gmail dot com
  Target Milestone: ---

We noticed significant regression after
https://gcc.gnu.org/viewcvs/gcc?view=revision=239414
I attached simple routine to reproduce. We can see that register pressure is 2x
higher with this patch after pre. The regression is worse for 32-bit mode.

[Bug driver/77497] New: Setting DWARF level and debug level together has flag-ordering-dependent results

[torne at google dot com]

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

Bug ID: 77497
   Summary: Setting DWARF level and debug level together has
flag-ordering-dependent results
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: torne at google dot com
  Target Milestone: ---

The -gdwarf-N option appears to confuse a previously set -gN debug level, and
the intended interpretation of the options only applies if you set the DWARF
level first. I compiled the same trivial source file with all combinations of
-g[123] and -gdwarf-[34] in both parameter orders and the file sizes show the
problem pretty clearly:

-rw-r- 1 torne eng  2412 Sep  5 18:04 test-g1-gdwarf-3.o
-rw-r- 1 torne eng  2384 Sep  5 18:04 test-g1-gdwarf-4.o
-rw-r- 1 torne eng  2412 Sep  5 18:04 test-g2-gdwarf-3.o
-rw-r- 1 torne eng  2384 Sep  5 18:04 test-g2-gdwarf-4.o
-rw-r- 1 torne eng 16648 Sep  5 18:04 test-g3-gdwarf-3.o
-rw-r- 1 torne eng 16620 Sep  5 18:04 test-g3-gdwarf-4.o
-rw-r- 1 torne eng  2268 Sep  5 18:04 test-gdwarf-3-g1.o
-rw-r- 1 torne eng  2412 Sep  5 18:04 test-gdwarf-3-g2.o
-rw-r- 1 torne eng 16648 Sep  5 18:04 test-gdwarf-3-g3.o
-rw-r- 1 torne eng  2248 Sep  5 18:04 test-gdwarf-4-g1.o
-rw-r- 1 torne eng  2384 Sep  5 18:04 test-gdwarf-4-g2.o
-rw-r- 1 torne eng 16620 Sep  5 18:04 test-gdwarf-4-g3.o

In the cases where -g1 appears before the DWARF level it appears to be ignored
and the exact same output as -g2 is generated. Weirdly this *doesn't* happen
for -g3?

This appears to have been introduced in gcc 4.9 (I can't repro in 4.8) and is
still happening in 6.1.1. The docs don't appear to state that these flags are
ordering-dependent, and in any case it's somewhat weird (especially that it
doesn't affect -g3, only -g1).

[Bug sanitizer/68260] false positive with tsan

[dvyukov at google dot com]

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

--- Comment #7 from Dmitry Vyukov  ---
I looked at the patch, but I am unqualified to review it. The test looks good
to me. +Yuri

[Bug middle-end/66661] incorrect memory access in optimization with flexible array member

[fw at gcc dot gnu.org]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fw at gcc dot gnu.org

--- Comment #11 from Florian Weimer  ---
I think this is a GCC bug.

Object sizes do not have to be a multiple of the object alignment.  Consider
this example:

#include 
#include 
#include 

_Alignas (128) unsigned v0 = 128;
_Alignas (8) unsigned v1 = 8;
_Alignas (8) unsigned v2 = 8;
_Alignas (8) unsigned v3 = 8;
_Alignas (4) unsigned v4 = 4;
_Alignas (4) unsigned v5 = 4;
_Alignas (8) unsigned v6 = 8;
_Alignas (8) unsigned v7 = 8;
_Alignas (8) unsigned v8 = 8;
_Alignas (4) unsigned v9 = 4;
_Alignas (4) unsigned v10 = 4;

static int
cmp(const void *a, const void *b)
{
  unsigned *const *a1 = a;
  unsigned *const *b1 = b;
  if (*a1 < *b1)
return -1;
  if (*a1 > *b1)
return 1;
  return 0;
}

int
main()
{
  unsigned *p[] = {, , , , , , , , , };
  qsort (p, 10, sizeof (p[0]), cmp);
  for (int i = 0; i < 9; ++i) {
printf ("%d: alignment %u, size %zd\n",
i, *p[i], (p[i + 1] - p[i]) * sizeof (*p[i]));
  }
}

With gcc-5.3.1-6.fc23.x86_64, it prints this for me:

0: alignment 4, size 4
1: alignment 4, size 4
2: alignment 8, size 8
3: alignment 8, size 8
4: alignment 8, size 4
5: alignment 4, size 4
6: alignment 4, size 8
7: alignment 8, size 8
8: alignment 8, size 8

So the assumption that objects are at least as large as their alignment appears
to be refuted by code generated by GCC.

[Bug gcov-profile/77378] [7 Regression] tree-profile and libgcov assume long long atomic operations are supported

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #8 from Martin Liška  ---
Fixed.

[Bug gcov-profile/58306] Broken profiling for unrar sources: error: corrupted value profile: value profile counter (X out of Y) inconsistent with basic-block count

[marxin at gcc dot gnu.org]

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

Bug 77466 Summary: [7 regression] FAIL: g++.dg/gcov/gcov-dump-1.C  -std=gnu++11 
(test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77466

   What|Removed |Added

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

[Bug sanitizer/68260] false positive with tsan

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Created attachment 39573
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39573=edit
gcc7-pr68260.patch

Untested fix.

[Bug gcov-profile/77378] [7 Regression] tree-profile and libgcov assume long long atomic operations are supported

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
Author: marxin
Date: Tue Sep  6 14:13:21 2016
New Revision: 240008

URL: https://gcc.gnu.org/viewcvs?rev=240008=gcc=rev
Log:
Detect whether target can use -fprofile-update=atomic

PR gcov-profile/77378
PR gcov-profile/77466
* libgcov-profiler.c: Use __GCC_HAVE_SYNC_COMPARE_AND_SWAP_{4,8} to
conditionaly enable/disable *_atomic functions.
PR gcov-profile/77378
PR gcov-profile/77466
* tree-profile.c (tree_profiling): Detect whether target can use
-fprofile-update=atomic.
PR gcov-profile/77378
PR gcov-profile/77466
* gcc.dg/profile-update-warning.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/profile-update-warning.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-profile.c
trunk/libgcc/ChangeLog
trunk/libgcc/libgcov-profiler.c

[Bug gcov-profile/77466] [7 regression] FAIL: g++.dg/gcov/gcov-dump-1.C -std=gnu++11 (test for excess errors)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
Fixed.

[Bug gcov-profile/77466] [7 regression] FAIL: g++.dg/gcov/gcov-dump-1.C -std=gnu++11 (test for excess errors)

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
Author: marxin
Date: Tue Sep  6 14:13:21 2016
New Revision: 240008

URL: https://gcc.gnu.org/viewcvs?rev=240008=gcc=rev
Log:
Detect whether target can use -fprofile-update=atomic

PR gcov-profile/77378
PR gcov-profile/77466
* libgcov-profiler.c: Use __GCC_HAVE_SYNC_COMPARE_AND_SWAP_{4,8} to
conditionaly enable/disable *_atomic functions.
PR gcov-profile/77378
PR gcov-profile/77466
* tree-profile.c (tree_profiling): Detect whether target can use
-fprofile-update=atomic.
PR gcov-profile/77378
PR gcov-profile/77466
* gcc.dg/profile-update-warning.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/profile-update-warning.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-profile.c
trunk/libgcc/ChangeLog
trunk/libgcc/libgcov-profiler.c

[Bug gcov-profile/58306] Broken profiling for unrar sources: error: corrupted value profile: value profile counter (X out of Y) inconsistent with basic-block count

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #41 from Martin Liška  ---
Fixed.

[Bug gcov-profile/58306] Broken profiling for unrar sources: error: corrupted value profile: value profile counter (X out of Y) inconsistent with basic-block count

[tulipawn at gmail dot com]

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

--- Comment #40 from PeteVine  ---
Absolutely! Even at 32 threads there's no problem whatsoever.

[Bug gcov-profile/58306] Broken profiling for unrar sources: error: corrupted value profile: value profile counter (X out of Y) inconsistent with basic-block count

[marxin at gcc dot gnu.org]

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

--- Comment #39 from Martin Liška  ---
(In reply to PeteVine from comment #38)
> Aaargh, I was using a recent nightly for the first time in a month and
> completely forgot it was still necessary. Apologies!

No problem! Good that it works, may I mark the PR as resolved?

[Bug gcov-profile/58306] Broken profiling for unrar sources: error: corrupted value profile: value profile counter (X out of Y) inconsistent with basic-block count

[tulipawn at gmail dot com]

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

--- Comment #38 from PeteVine  ---
Aaargh, I was using a recent nightly for the first time in a month and
completely forgot it was still necessary. Apologies!

[Bug fortran/67564] Segfault on sourced allocattion statement with class(*) arrays

[neil.n.carlson at gmail dot com]

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

--- Comment #11 from neil.n.carlson at gmail dot com ---
Ping

[Bug gcov-profile/58306] Broken profiling for unrar sources: error: corrupted value profile: value profile counter (X out of Y) inconsistent with basic-block count

[marxin at gcc dot gnu.org]

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

--- Comment #37 from Martin Liška  ---
(In reply to PeteVine from comment #36)
> The original patch is still not enough it seems. I've just tried profiling
> the C-ray benchmark from issue #53659 (./c-ray-mt -t 32 -s 160x120 -r 8 -i
> sphfract -o output.ppm) and any -t (for threads) greater than 1 results in:
> 
> c-ray-mt.c: In function ‘ray_sphere’:
> c-ray-mt.c:671:1: error: corrupted profile info: profile data is not
> flow-consistent
>  }
>  ^
> c-ray-mt.c:671:1: error: corrupted profile info: number of executions for
> edge 12-14 thought to be -67
> c-ray-mt.c:671:1: error: corrupted profile info: number of executions for
> edge 12-13 thought to be 456322
> c-ray-mt.c: In function ‘shade’:
> c-ray-mt.c:671:1: error: corrupted profile info: profile data is not
> flow-consistent
> c-ray-mt.c:671:1: error: corrupted profile info: number of executions for
> edge 7-4 thought to be 113111929
> c-ray-mt.c:671:1: error: corrupted profile info: number of executions for
> edge 7-8 thought to be -3827604

Have you added -fprofile-update=atomic to your compiler options?
Can you please provide info about your target and the compiler options you use?

Thanks,
Martin

[Bug tree-optimization/77485] Missed dead store elimination of aggregate store followed by partial stores

[petschy at gmail dot com]

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

--- Comment #2 from petschy at gmail dot com ---
I agree that the generic case can become quite complicated: if after the
memset, the individual values are written with gaps between them, or multiple
contiguous chunks with gaps between them, it's not easy to tell whether having
a single memset + overwrites is better than having multiple memsets with
distinct regions + the individual byte writes, or anything in-between. It all
depends on the actual pattern.

However, for a simplified approach I can think of is keeping track of
contiguous regions that are written, then trimming the regions based on the
order and overlap, or merging them if they are adjacent.

In this particular case this would mean that
 [0,199] : memset 0 + [0,31] : const init
could be converted to
 [32,199] : memset 0 + [0,31] : const init
knowing that the const init comes later.

A similar adjustment can be made if a second const init region overlaps with
the end of the memset region. Adjacent or overlapping const init regions can be
merged.

But then, of course comes the devil with the details: if the trivial merging
and trimming of the intervals is done,
 - at what length is it worth having the memset merged into the const init
   regions, if a short memset is stuck between two const init regions?
 - and vica versa, at what length is it worth having a single memset with
   an overwriting const init region at the middle vs memset + const init +
   memset as disjunct regions?
 - at what point is it worth storing the whole data in .rodata and just memcpy
   it to the target?
 - how to integrate regions of runtime calculated values into the above?

For my particular case, I can work around this inefficiency by setting the
buffer to the exact size. I have no idea how a simple region based approach
like the above would perform in general and whether it would worth the
development effort.

[Bug preprocessor/77488] Proposal for __FILENAME_ONLY__

[rdiezmail-gcc at yahoo dot de]

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

--- Comment #2 from R. Diez  ---

> __FILE__ expands to whatever you pass on the command line as the base file
> (and for headers whatever the directory is where they are found + the header
> filename.  So, if you compile with gcc -c something.c -I subdir/ , then
> __FILE__ will be "something.c" or e.g. "subdir/something.h".  If you use
> absolute filenames, that is what you get.  So, if you care about the lengths
> of these, just tweak your Makefiles so that you do the right thing (compile
> in the directory with the sources, with -o to the directory of object files
> if different), rather than compiling in the object directory, with absolute
> filenames as sources.  Adding yet another __FILE__-like builtin preprocessor
> constant is IMHO undesirable,

I already wrote that I cannot easily control the path depth, because  I am
using the autotools in my project in order to generate the makefiles. Some
libraries come with their own (complex) makefiles or build systems, so your
advice is not practicable in real life. Moreover, the GCC toolchain itself
decides where some of the include files lie and how their paths look.

I also said that using absolute paths in the makefiles may be desirable for
other reasons. I am concerned that the binary easily depends on the source code
and toolchain location, which makes it hard to get a reproducible build. With
__FILE__, there is no practicable solution.


> especially in the spelling you're proposing.

I do not actually mind about the spelling. I am just looking for some workable
way (in real life) to include filename (source code position) information in
assert messages that does not depend on full paths (and enables easily
reproducible builds).


> As for strrchr folding, I see it folded properly, e.g. __builtin_strrchr
> (__FILE__, '/') is optimized into "foo/bar/baz.c" + 7.  Optimizing it into
> "baz.c" would be incorrect, you can do later on with the returned pointer
> e.g. ptr -= 4; etc., which would be undefined behavior if everything before
> the last / is removed from the string literal.

OK, now I understand the issue with strrchr(), thanks.

[Bug tree-optimization/77450] [5/6 Regression] ICE: in verify_ssa, at tree-ssa.c:1016 on very simple code with vectors

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||7.0
Summary|[5/6/7 Regression] ICE: in  |[5/6 Regression] ICE: in
   |verify_ssa, at  |verify_ssa, at
   |tree-ssa.c:1016 on very |tree-ssa.c:1016 on very
   |simple code with vectors|simple code with vectors
  Known to fail|7.0 |

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

[Bug tree-optimization/77479] [7 Regression] Compile time hog w/ -O2 (-Os)

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Tue Sep  6 12:51:01 2016
New Revision: 240007

URL: https://gcc.gnu.org/viewcvs?rev=240007=gcc=rev
Log:
2016-09-06  Richard Biener  

PR tree-optimization/77479
* tree-vrp.c (update_value_range): Extend overflow handling to
VARYING.

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

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr77479.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vrp.c

[Bug tree-optimization/77479] [7 Regression] Compile time hog w/ -O2 (-Os)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/77450] [5/6/7 Regression] ICE: in verify_ssa, at tree-ssa.c:1016 on very simple code with vectors

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Tue Sep  6 12:49:53 2016
New Revision: 240006

URL: https://gcc.gnu.org/viewcvs?rev=240006=gcc=rev
Log:
2016-09-06  Richard Biener  

PR c/77450
c-family/
* c-common.c (c_common_mark_addressable_vec): Handle
COMPOUND_LITERAL_EXPR.

* c-c++-common/vector-subscript-7.c: Adjust.
* c-c++-common/vector-subscript-8.c: New testcase.

Added:
trunk/gcc/testsuite/c-c++-common/vector-subscript-8.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/vector-subscript-7.c

[Bug fortran/72743] ICE in get_constraint_for_ssa_var, at tree-ssa-structalias.c:2958

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

   Keywords||openacc
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |cltang at gcc dot 
gnu.org

--- Comment #7 from Thomas Schwinge  ---
Patch review in .

[Bug middle-end/77484] Static branch predictor causes ~6-8% regression of SPEC2000 GAP

[hubicka at ucw dot cz]

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

--- Comment #2 from Jan Hubicka  ---
> IIRC the measurements have been run on x86 only, they are done "statically",
> that is, verify the prediction against real outcomes as computed by the edge
> profile
> which is target independent.

Yes, the measurements should be target independent modulo the differences we
already
see at early gimple level (different headers, different word sizes etc). 

I will take a look how the predictions work for gap and if they can be
improved.
Of course even improvements in profile guessing doesn't always guarantee better
final code.  It sometimes happen that codegen just got lucky with numbers it
used
to be fed with.

We do have improtant problems with jump threading and profile updating. That
needs
to be solved first IMO.  I will try to find time for that during Cauldron.

[Bug gcov-profile/58306] Broken profiling for unrar sources: error: corrupted value profile: value profile counter (X out of Y) inconsistent with basic-block count

[t.artem at mailcity dot com]

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

Artem S. Tashkinov  changed:

   What|Removed |Added

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

[Bug gcov-profile/58306] Broken profiling for unrar sources: error: corrupted value profile: value profile counter (X out of Y) inconsistent with basic-block count

[tulipawn at gmail dot com]

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

--- Comment #36 from PeteVine  ---
The original patch is still not enough it seems. I've just tried profiling the
C-ray benchmark from issue #53659 (./c-ray-mt -t 32 -s 160x120 -r 8 -i sphfract
-o output.ppm) and any -t (for threads) greater than 1 results in:

c-ray-mt.c: In function ‘ray_sphere’:
c-ray-mt.c:671:1: error: corrupted profile info: profile data is not
flow-consistent
 }
 ^
c-ray-mt.c:671:1: error: corrupted profile info: number of executions for edge
12-14 thought to be -67
c-ray-mt.c:671:1: error: corrupted profile info: number of executions for edge
12-13 thought to be 456322
c-ray-mt.c: In function ‘shade’:
c-ray-mt.c:671:1: error: corrupted profile info: profile data is not
flow-consistent
c-ray-mt.c:671:1: error: corrupted profile info: number of executions for edge
7-4 thought to be 113111929
c-ray-mt.c:671:1: error: corrupted profile info: number of executions for edge
7-8 thought to be -3827604

[Bug bootstrap/70473] genautomata memory footprint for arm

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||7.0
 Resolution|--- |FIXED

--- Comment #13 from ktkachov at gcc dot gnu.org ---
Marking this as fixed then. Thanks for testing.

[Bug c++/77496] ICE in instantiate_type, at cp/class.c:8270

[bernd.edlinger at hotmail dot de]

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

--- Comment #2 from Bernd Edlinger  ---
possible fix:

--- a/gcc-7-20160904/gcc/cp/class.c 2016-08-26 17:10:57.0 +0200
+++ b/gcc-7-20160904/gcc/cp/class.c 2016-09-06 11:55:27.252138088 +0200
@@ -8262,6 +8262,11 @@ instantiate_type (tree lhstype, tree rhs
   return error_mark_node;
 }

+  /* If we instantiate a template, and it is a A ?: C expression
+ with omitted B.  */
+  if (TREE_CODE (rhs) == SAVE_EXPR)
+rhs = TREE_OPERAND (rhs, 0);
+
   /* There only a few kinds of expressions that may have a type
  dependent on overload resolution.  */
   gcc_assert (TREE_CODE (rhs) == ADDR_EXPR

[Bug c++/77477] error recovery for explicit qualification

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords|error-recovery  |diagnostic

--- Comment #6 from Jonathan Wakely  ---
Oh actually even then it isn't valid, because you use size_t but don't include
 or anything that is guaranteed to define size_t in the global
namespace. You should #include  or use std::size_t instead.

[Bug c++/77477] error recovery for explicit qualification

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to Jim Michaels from comment #2)
> I don't believe this answer.
> to my knowledge the syntax is OK for c++11.

Please stop claiming templates don't work and learn to write C++.

> I was even told once that  is not needed, which was wrong.
> you did not state exactly what was wrong, only that "your code is wrong."
> please be explicit like you require your bug reporters to be. thank you.

Remove all occurrences of  and str:: from your example code and it will be
valid C++.

[Bug c++/77446] Suspicious "non-constant condition for static assertion" error

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-06
 Ever confirmed|0   |1

[Bug target/77494] -mcpu=cortex-a53 does not allow use of crc extensions

[rearnsha at gcc dot gnu.org]

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

--- Comment #3 from Richard Earnshaw  ---
You need to report gas bugs to the binutils maintainers.

[Bug target/77494] -mcpu=cortex-a53 does not allow use of crc extensions

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Earnshaw  ---
This is a bug in GAS, the assembler.  The compiler puts out a directive 
   .cpu cortex-a53
in the assembler output, but the assembler then fails to recognize that this
CPU has CRC instructions.

[Bug libstdc++/77356] regex error for a ECMAScript syntax string

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug libstdc++/77469] std::regex x("[b\\-a]") throws with message "Invalid range in bracket expression."

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
(In reply to Andreas Schwab from comment #4)
> \ is not special inside bracket expressions, [b\-a] means b and the range
> between \ and a.  If you want to include a - in a bracket expression, put it
> first or last.

That's true for POSIX BREs and EREs, but for ECMAScript escaping the dash
should work (and does on trunk).

[Bug sanitizer/68260] false positive with tsan

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
No, it is a tsan.c bug, which doesn't instrument __atomic_clear and
__atomic_test_and_set builtins (i.e. those that operate solely on bool). 
Trying to implement that now.

[Bug sanitizer/68260] false positive with tsan

[dvyukov at google dot com]

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

--- Comment #4 from Dmitry Vyukov  ---
Good point. I wonder if using -O2 fixes this.
We tend to always use tsan with -O2 for performance reasons. Tsan already
considerably slows down execution, and additional unnecessary memory accesses
and non-inlined trivial function calls (which there can be zillions in "modern
C++") with -O0 slow down execution even more.

[Bug c++/77496] ICE in instantiate_type, at cp/class.c:8270

[bernd.edlinger at hotmail dot de]

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

--- Comment #1 from Bernd Edlinger  ---
But it works if I write:

int f(bool z) { return zz(0) ? : 0; }

[Bug c++/77496] New: ICE in instantiate_type, at cp/class.c:8270

[bernd.edlinger at hotmail dot de]

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

Bug ID: 77496
   Summary: ICE in instantiate_type, at cp/class.c:8270
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bernd.edlinger at hotmail dot de
  Target Milestone: ---

this invalid C++ template creates an ICE:

cat test.cc
template 
class z : x
{
public:
  bool zz (int) { return false; }
  int f(bool z) { return zz ? : 0; }
};

class t
{
};

int
main()
{
  z x;
  return x.f(0);
}

g++ test.cc
test.cc: In instantiation of 'int z::f(bool) [with x = t]':
test.cc:16:15:   required from here
test.cc:6:29: internal compiler error: in instantiate_type, at cp/class.c:8270
   int f(bool z) { return zz ? : 0; }
  ~~~^
0x6f9bcf instantiate_type(tree_node*, tree_node*, int)
../../gcc-7-20160904/gcc/cp/class.c:8267
0x62eb27 perform_implicit_conversion_flags(tree_node*, tree_node*, int, int)
../../gcc-7-20160904/gcc/cp/call.c:9763
0x63d0f6 build_conditional_expr_1
../../gcc-7-20160904/gcc/cp/call.c:4811
0x63ef8c build_conditional_expr(unsigned int, tree_node*, tree_node*,
tree_node*, int)
../../gcc-7-20160904/gcc/cp/call.c:5237
0x77cecb build_x_conditional_expr(unsigned int, tree_node*, tree_node*,
tree_node*, int)
../../gcc-7-20160904/gcc/cp/typeck.c:6279
0x6a0805 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc-7-20160904/gcc/cp/pt.c:16822
0x695e54 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-7-20160904/gcc/cp/pt.c:15936
0x6948ed tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-7-20160904/gcc/cp/pt.c:15238
0x693d48 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-7-20160904/gcc/cp/pt.c:15419
0x6d64e4 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-7-20160904/gcc/cp/pt.c:15213
0x6d64e4 instantiate_decl(tree_node*, int, bool)
../../gcc-7-20160904/gcc/cp/pt.c:22159
0x6dd29b instantiate_pending_templates(int)
../../gcc-7-20160904/gcc/cp/pt.c:22276
0x71feaa c_parse_final_cleanups()
../../gcc-7-20160904/gcc/cp/decl2.c:4617
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.