[Bug fortran/78618] ICE in gfc_check_rank, at fortran/check.c:3670

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #10 from Steve Kargl  ---
On Sat, Dec 03, 2016 at 07:31:21AM +, janus at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78618
> 
> --- Comment #9 from janus at gcc dot gnu.org ---
> (In reply to Steve Kargl from comment #8)
> > Note, I configured gcc with 
> > 
> > ../gcc7/configure  \
> > --prefix=$HOME/work/7 --with-isl=/usr/local \
> > --enable-languages=c,fortran,c++ --enable-libsanitizer \
> > --disable-libmudflap --disable-nls
> 
> I'm configuring with
> 
> --program-suffix=-7 --build=x86_64-linux-gnu --host=x86_64-linux-gnu
> --target=x86_64-linux-gnu --with-arch=haswell --prefix=/us
> r --libdir=/usr/lib --libexecdir=/usr/lib --enable-languages=c,c++,fortran
> --disable-bootstrap --disable-multilib
> 
> I admit that's not a full bootstrap, but I see things working on two different
> machines. The testsuite is clean and compiling the test case by hand works as
> well.
> 

Others are see the failures.

https://gcc.gnu.org/ml/gcc-testresults/2016-12/msg00313.html
https://gcc.gnu.org/ml/gcc-testresults/2016-12/msg00311.html

I think your patch is correct, but uncovering a new latent bug.
Does your memory allocator fill freed memory with junk?  This
looks like a used-after-freed bug.

[Bug fortran/78618] ICE in gfc_check_rank, at fortran/check.c:3670

[janus at gcc dot gnu.org]

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

--- Comment #9 from janus at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #8)
> Note, I configured gcc with 
> 
> ../gcc7/configure  \
> --prefix=$HOME/work/7 --with-isl=/usr/local \
> --enable-languages=c,fortran,c++ --enable-libsanitizer \
> --disable-libmudflap --disable-nls

I'm configuring with

--program-suffix=-7 --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu --with-arch=haswell --prefix=/us
r --libdir=/usr/lib --libexecdir=/usr/lib --enable-languages=c,c++,fortran
--disable-bootstrap --disable-multilib

I admit that's not a full bootstrap, but I see things working on two different
machines. The testsuite is clean and compiling the test case by hand works as
well.

[Bug c++/77373] __attribute__((vector_size(N))) fails on AIX

[dje at gcc dot gnu.org]

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

--- Comment #4 from David Edelsohn  ---
 
unit size 
align 256 symtab 0 alias set -1 canonical type 700fc0c0
fields 
used nonlocal decl_3 BLK file
/gsa/yktgsa/home/e/d/edelsohn/src/src/gcc/testsuite/g++.dg/ext/vector32.C line
5 col 55 size  unit size 
align 256 offset_align 128
offset 
bit offset  context  chain > context 
full-name "struct D<8>"
X() X(constX&) this=(X&) n_parents=0 use_template=1 interface-unknown
pointer_to_this  reference_to_this
 chain >
constant static lngt 1
idx 
sizes-gimplified BLK size  unit size

align 256 symtab 0 alias set -1 canonical type 700fc180 nunits 8>
used nonlocal decl_3 BLK file
/gsa/yktgsa/home/e/d/edelsohn/src/src/gcc/testsuite/g++.dg/ext/vector32.C line
5 col 55 size  unit size 
align 256 offset_align 128 offset  bit offset
 context 
chain 
external nonlocal suppress-debug decl_4 VOID file
/gsa/yktgsa/home/e/d/edelsohn/src/src/gcc/testsuite/g++.dg/ext/vector32.C line
4 col 10
align 8 context  result 
   >>
val 
constant
elt0:  
elt1:  
elt2:  
elt3:  
elt4:  
elt5:  
elt6:  
elt7:  >>

[Bug fortran/78659] Spurious "requires DTIO" reported against namelist statement

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #2 from Jerry DeLisle  ---
Created attachment 40236
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40236=edit
Likely patch

This patch fixes without breaking any current dtio tests. The first chunk is
just a cleanup. Second chunk remove the error check.  Full regression testing
now.

[Bug libstdc++/78441] [variant] variant_alternative doesn't allow cv qualifiers

[eric at efcs dot ca]

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

Eric Fiselier  changed:

   What|Removed |Added

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

--- Comment #2 from Eric Fiselier  ---
Closing as RESOLVED FIXED based on the last comment.

[Bug c++/71537] GCC rejects consetxpr boolean conversions and comparisons on the result of pointer arithmetic.

[eric at efcs dot ca]

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

Eric Fiselier  changed:

   What|Removed |Added

 CC||jason at redhat dot com

--- Comment #3 from Eric Fiselier  ---
Ping and CC Jason the Wizard. This is needed to implement C++17 constexpr
char_traits (See wg21.link/P0426R1).

[Bug c++/78551] [5/6/7 Regression] Internal compiler error with constexpr initialization of union

[vlad at petric dot cc]

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

--- Comment #9 from Vlad Petric  ---
Created attachment 40235
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40235=edit
Compliant code that segfaults the compiler

[Bug fortran/78659] Spurious "requires DTIO" reported against namelist statement

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-12-03
 CC||jvdelisle at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jerry DeLisle  ---
Confirmed, looks like we have a check in the wrong place.

[Bug fortran/78659] New: Spurious "requires DTIO" reported against namelist statement

[ian_harvey at bigpond dot com]

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

Bug ID: 78659
   Summary: Spurious "requires DTIO" reported against namelist
statement
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ian_harvey at bigpond dot com
  Target Milestone: ---

The attached, when compiled with gfortran recent trunk (r243203): 


MODULE ma
  IMPLICIT NONE
  TYPE :: ta
INTEGER, ALLOCATABLE :: array(:)
  END TYPE ta
END MODULE ma

PROGRAM p
  USE ma
  TYPE(ta) :: x
  NAMELIST /nml/ x
END PROGRAM p


results in:


$ gfortran 2016-12-03\ dtio-namelist-1.f90
2016-12-03 dtio-namelist-1.f90:11:15:

   NAMELIST /nml/ x
   1
Error: NAMELIST object ‘x’ in namelist ‘nml’ at (1) has ALLOCATABLE or POINTER
components and thus requires a defined input/output procedure


The error is reported against the namelist statement.  The standard does not
impose such a requirement on the namelist statement itself - the requirement is
imposed on data transfer statements that reference the namelist (F2008
9.6.4.7p2).

A namelist with such an object is not useful, so a warning is perhaps warranted
specifically for the above code, but the current error message causes issues
with useful code, such as:


MODULE mb
  IMPLICIT NONE
  TYPE :: tb
INTEGER, ALLOCATABLE :: array(:)
  CONTAINS
PROCEDURE :: read_formatted
GENERIC :: READ(FORMATTED) => read_formatted
  END TYPE tb
CONTAINS
  SUBROUTINE read_formatted(dtv, unit, iotype, v_list, iostat, iomsg)
CLASS(tb), INTENT(INOUT) :: dtv
INTEGER, INTENT(IN) :: unit
CHARACTER(*), INTENT(IN) :: iotype
INTEGER, INTENT(IN) :: v_list(:)
INTEGER, INTENT(OUT) :: iostat
CHARACTER(*), INTENT(INOUT) :: iomsg

iostat = 0
  END SUBROUTINE read_formatted
END MODULE mb

PROGRAM p
  USE mb
  TYPE(tb) :: y
  NAMELIST /nml/ y
  READ (*, nml)
END PROGRAM p


$ gfortran 2016-12-03\ dtio-namelist-2.f90
2016-12-03 dtio-namelist-2.f90:25:15:

   NAMELIST /nml/ y
   1
Error: NAMELIST object ‘y’ in namelist ‘nml’ at (1) has ALLOCATABLE or POINTER
components and thus requires a defined input/output procedure


The error goes away if a defined output procedure is also provided, but the
standard does not require a defined output procedure for the last example.

[Bug middle-end/78519] missing warning for sprintf %s with null pointer

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-12-03
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Testing a trivial patch.

[Bug tree-optimization/78608] gimple-ssa-sprintf.c:570:17: runtime error: negation of -9223372036854775808 cannot be represented in type 'long int'

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords|ice-on-invalid-code |patch

--- Comment #5 from Martin Sebor  ---
A bigger patch that addresses a number of overflow-related problems has been
posted for review:
https://gcc.gnu.org/ml/gcc-patches/2016-12/msg00262.html

[Bug c++/78551] [5/6/7 Regression] Internal compiler error with constexpr initialization of union

[vlad at petric dot cc]

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

--- Comment #8 from Vlad Petric  ---
(In reply to Vlad Petric from comment #7)
> Ok, so the example that I started this bug with is not standard compliant
> because it initialized different elements in a union with the constexpr
> constructor.
> 
> The following does just one. I believe that the following is
> standard-compliant code (though obviously I could be wrong)
> 
> And it generates a segfault.
> 
> struct A {
>   union {
> long s;
> char d[4];
>   };
>   constexpr A (char x) : d("") { d[0] = x; }
> };
> 
> A a{'a'};

clang 3.8/4.0 have no problem with the above code.

Personally I think that we should change the main attachment and the tag - to
segfault on valid code (worse than ICE ...).

[Bug rtl-optimization/78638] [7 regression] test cases gcc.target/powerpc/rlwimi-0.c and rlwimi-2.c fail starting with r243000

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||krebbel at gcc dot gnu.org

--- Comment #5 from Segher Boessenkool  ---
For comment 2, r243162 is what caused it.

[Bug target/78631] [Intel MPX] libmpxwrappers shared library leads to a non-bounds-preserving memcpy()

[ienkovich at gcc dot gnu.org]

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

--- Comment #7 from Ilya Enkovich  ---
(In reply to H.J. Lu from comment #6)
> -z bndplt is needed to call external functions with bounds.  But
> it isn't needed for internal function calls.

That doesn't explain why we need a hack you propose. Code like 

void *fn1 (void *p) {
  return fn2(p);
}

should work fine for any fn1 and fn2 compiled with MPX. Both internal and
external functions should work. If call goes through PLT then BNDPLT should be
used. If it's not then it's a bug in toolchain.

[Bug rtl-optimization/78638] [7 regression] test cases gcc.target/powerpc/rlwimi-0.c and rlwimi-2.c fail starting with r243000

[segher at gcc dot gnu.org]

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

--- Comment #4 from Segher Boessenkool  ---
I have a patch for the rlwimi ones.  The new ones are an actual regression
as well.

[Bug fortran/78618] ICE in gfc_check_rank, at fortran/check.c:3670

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #8 from Steve Kargl  ---
On Fri, Dec 02, 2016 at 10:49:12PM +, janus at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78618
> 
> --- Comment #7 from janus at gcc dot gnu.org ---
> (In reply to kargl from comment #6)
> > I updated my source tree to r243203, which includes your change.
> > My source tree cuurently has no other changes.  I still see an ICE.
> 
> Sorry, I can not reproduce that with my build on x86_64-linux-gnu ...
> 

I anticipated that that would be your response. :-)

Note, I configured gcc with 

../gcc7/configure  \
--prefix=$HOME/work/7 --with-isl=/usr/local \
--enable-languages=c,fortran,c++ --enable-libsanitizer \
--disable-libmudflap --disable-nls

Perhaps, I need to re-do a full bootstrap.  In the meantime,
I poking around to see what's happening.

[Bug fortran/78618] ICE in gfc_check_rank, at fortran/check.c:3670

[janus at gcc dot gnu.org]

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

--- Comment #7 from janus at gcc dot gnu.org ---
(In reply to kargl from comment #6)
> I updated my source tree to r243203, which includes your change.
> My source tree cuurently has no other changes.  I still see an ICE.

Sorry, I can not reproduce that with my build on x86_64-linux-gnu ...

[Bug bootstrap/78616] [7 regression] bootstrap fails for x86_64-darwin at stage1 after 243030 when the bootstrap compiler doesn't have strndup

[dmalcolm at gcc dot gnu.org]

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

--- Comment #10 from David Malcolm  ---
Build breakage should have been fixed as of r243207 (sorry again).

Should we poision strndup in system.h?

[Bug bootstrap/78616] [7 regression] bootstrap fails for x86_64-darwin at stage1 after 243030 when the bootstrap compiler doesn't have strndup

[dmalcolm at gcc dot gnu.org]

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

--- Comment #9 from David Malcolm  ---
Author: dmalcolm
Date: Fri Dec  2 22:39:43 2016
New Revision: 243207

URL: https://gcc.gnu.org/viewcvs?rev=243207=gcc=rev
Log:
selftest.c: remove calls to strndup (PR bootstrap/78616)

gcc/ChangeLog:
PR bootstrap/78616
* selftest.c (selftest::assert_strndup_eq): Rename to...
(selftest::assert_xstrndup_eq): ...this, and remove call to
strndup.
(selftest::test_strndup): Rename to...
(selftest::test_xstrndup): ...this, updating for above renaming.
(selftest::test_libiberty): Update for renaming.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/selftest.c

[Bug target/77761] [7 Regression] wrong code with -fschedule-insns -mavx512f --param=max-pending-list-length=512

[vmakarov at gcc dot gnu.org]

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

--- Comment #2 from Vladimir Makarov  ---
  Thanks for reporting this, Zdenek.

  After some time staring at the generated code I believe the problem is in
hard register splitting optimization.  LRA uses wrongly smaller mode for
splitting than necessary.

  I hope the patch will be ready on Tuesday.

[Bug target/78639] [7 Regression] Power9 bad code generation for cactusADM benchmark

[meissner at gcc dot gnu.org]

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

--- Comment #3 from Michael Meissner  ---
Author: meissner
Date: Fri Dec  2 22:12:08 2016
New Revision: 243206

URL: https://gcc.gnu.org/viewcvs?rev=243206=gcc=rev
Log:
2016-12-02  Michael Meissner  

PR target/78639
* config/rs6000/rs6000.md (movdi_internal64): Fix typo in
subversion id 242679 that causes the wrong store instruction to be
generated if a DImode is in an Altivec register using REG+REG
addressing.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.md

[Bug c++/70909] Libiberty Demangler segfaults (4)

[boehme.marcel at gmail dot com]

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

--- Comment #31 from Marcel Böhme  ---
Hi Mark,

Your patch looks good to me. One more thing: It seems that our patches evaluate
these two mangled strings differently. Is it because of Nathan's patch? Can
these strings be demangled properly at all?

> 
_ZNK6Common15ConvertingRangeIN5boost12range_detail17transformed_rangeIZN1a1b1cEbEUljE_KSt6vectorIjSaIjEcvT_IS7_INS4_1dESaISF_v

Common::ConvertingRange const>
>::operator a::b::c(bool)::{lambda(unsigned int)#1} const>
>::operator > > const>
>::operator
Common::ConvertingRange const>
>::operator > > >() const

> _ZNK6clover6detail11basic_rangeINS_13adaptor_rangeINS_9addressesEINS2_IRFRNS_5eventEP9_cl_eventEINS_14iterator_rangeIPKS7_NS0_16iterator_adaptorIS3_INSG_IS9_ISC_EESI_EcvT_ISt6vectorIPS4_SaISN_EEvEEv

clover::detail::basic_range > >,
clover::detail::iterator_adaptor > > >,
clover::detail::iterator_adaptor > >::operator std::vector > >,
clover::detail::iterator_adaptor > > >,
clover::detail::iterator_adaptor > >::operator > > > >,
clover::detail::iterator_adaptor > > >,
clover::detail::iterator_adaptor > >::operator
clover::detail::basic_range > >,
clover::detail::iterator_adaptor > > >,
clover::detail::iterator_adaptor > >::operator > >, void>() const

[Bug fortran/78618] ICE in gfc_check_rank, at fortran/check.c:3670

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #6 from kargl at gcc dot gnu.org ---
Janus,

I updated my source tree to r243203, which includes your change.
My source tree cuurently has no other changes.  I still see an ICE.
However, an error message is printed.

troutmask:sgk[232] gfc7 -o z char_conversion.f90 
char_conversion.f90:8:30:

character, parameter :: c = char(256,4) ! { dg-error "cannot be converted"
}
  1
Error: Character '\u0100' in string at (1) cannot be converted into character
kind 1
f951: internal compiler error: Segmentation fault
0xbb020f crash_signal
../../gcc7/gcc/toplev.c:333
0x5f0662 gfc_is_constant_expr(gfc_expr*)
../../gcc7/gcc/fortran/expr.c:899
0x658e21 resolve_fl_procedure
../../gcc7/gcc/fortran/resolve.c:12013
0x658e21 resolve_symbol
../../gcc7/gcc/fortran/resolve.c:14721
0x67755b do_traverse_symtree
../../gcc7/gcc/fortran/symbol.c:3994
0x6523a4 resolve_types
../../gcc7/gcc/fortran/resolve.c:15948
0x656b2c gfc_resolve(gfc_namespace*)
../../gcc7/gcc/fortran/resolve.c:16061
0x645ef4 resolve_all_program_units
../../gcc7/gcc/fortran/parse.c:5977
0x645ef4 gfc_parse_file()
../../gcc7/gcc/fortran/parse.c:6224
0x68a3c2 gfc_be_parse_file
../../gcc7/gcc/fortran/f95-lang.c:202

Running f951 under gdb shows

(gdb) run char_conversion.f90 
Starting program:
/mnt/sgk/work/7/libexec/gcc/x86_64-unknown-freebsd12.0/7.0.0/f951
char_conversion.f90
char_conversion.f90:8:30:

character, parameter :: c = char(256,4) ! { dg-error "cannot be converted"
}
  1
Error: Character '\u0100' in string at (1) cannot be converted into character
kind 1

Program received signal SIGSEGV, Segmentation fault.
gfc_is_constant_expr (e=0x193e) at ../../gcc7/gcc/fortran/expr.c:899
899   switch (e->expr_type)

0x193e is certainly an invalid pointer.

(gdb) up
#1  0x00658e22 in resolve_fl_procedure (mp_flag=0, sym=0x203636180)
at ../../gcc7/gcc/fortran/resolve.c:12013
12013 if (cl && cl->length && gfc_is_constant_expr (cl->length)
(gdb) p *sym
$1 = {name = 0x20382c9d0 "__convert_s4_s1", 
(gdb) p *sym->ts.u.cl
$4 = {length = 0x193e, next = 0x0, length_from_typespec = false, 
  backend_decl = 0x2039d5020, passed_length = 0x0, resolved = 56844352}

[Bug c++/78649] [5/6 Regression] ICE on invalid C++ code on x86_64-linux-gnu (internal compiler error: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in build_value_init_noctor, at

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[5/6/7 Regression] ICE on   |[5/6 Regression] ICE on
   |invalid C++ code on |invalid C++ code on
   |x86_64-linux-gnu (internal  |x86_64-linux-gnu (internal
   |compiler error: tree check: |compiler error: tree check:
   |expected class ‘type’, have |expected class ‘type’, have
   |‘exceptional’ (error_mark)  |‘exceptional’ (error_mark)
   |in build_value_init_noctor, |in build_value_init_noctor,
   |at cp/init.c:380)   |at cp/init.c:380)

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

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

[baker at usgs dot gov]

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

--- Comment #9 from Larry Baker  ---
To answer Waldemar's question, that is exactly how I worked around the problem
for gcc 4.7 and 4.8 in 2012 (see Bug 53833).  That enabled me to have a
functioning gcc for ColdFire.  I used it to fix broken stack limit checking for
ColdFire processors.  I never tried to use it for building any system
components, such as Jeff describes.

[Bug target/70322] STV doesn't optimize andn

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c++/78649] [5/6/7 Regression] ICE on invalid C++ code on x86_64-linux-gnu (internal compiler error: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in build_value_init_noctor,

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Fri Dec  2 21:23:22 2016
New Revision: 243204

URL: https://gcc.gnu.org/viewcvs?rev=243204=gcc=rev
Log:
PR c++/78649
* pt.c (tsubst_init): Don't call build_value_init if decl's type
is error_mark_node.

* g++.dg/cpp0x/pr78649.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr78649.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog

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

[law at redhat dot com]

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

--- Comment #8 from Jeffrey A. Law  ---
Unsure.  I thought libstdc++ used some of the libatomic facilities under the
hood so we'd just replace one build failure with another.

It might also mess up the older 68k systems (assuming I'm wrong about the ABI
implications and they are in fact working properly) to just remove libatomic
from the builds.

In short, I don't have enough information to recommend a reasonable course of
action on this BZ.

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

[wbx at openadk dot org]

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

--- Comment #7 from Waldemar Brodkorb  ---
Can't we disable compilation of linux-atomic.c for gcc7 then?
So that at least it is possible to build a toolchain for coldfire?

[Bug fortran/77517] ICE in conv_intrinsic_move_alloc, at fortran/trans-intrinsic.c:9517

[anlauf at gmx dot de]

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

--- Comment #6 from Harald Anlauf  ---
Extending the check in comment #5 to

  if (from->ts.type == BT_CLASS && to->ts.type != BT_CLASS ||
  to->ts.type == BT_CLASS && from->ts.type != BT_CLASS)
{
  gfc_error ("The FROM and TO arguments at %L are incompatible",
>where);
  return false;
}

also avoids the ICE for

program p
   class(*), allocatable :: a, b
   call move_alloc (a, b)
contains
   subroutine b
   end
end

[Bug fortran/77517] ICE in conv_intrinsic_move_alloc, at fortran/trans-intrinsic.c:9517

[anlauf at gmx dot de]

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

--- Comment #5 from Harald Anlauf  ---
Besides the lack of diagnosing the conflicting definitions,
I think there is a missing check in gfc_check_move_alloc().

The test case

program p
   class(*), allocatable :: a, b
   call move_alloc (a, b)
contains
   subroutine a
   end
end

hits near the end of the function

  /* CLASS arguments: Make sure the vtab of from is present.  */
  if (to->ts.type == BT_CLASS && !UNLIMITED_POLY (from))
gfc_find_vtab (>ts);

However, for that case I get

 (gdb) print from->ts.type
$7 = BT_PROCEDURE

which should never happen, and is not expected.
To avoid an ICE, one might add a check just before this block, like:

  if (to->ts.type == BT_CLASS && from->ts.type != BT_CLASS)
{
  gfc_error ("The FROM and TO arguments at %L are incompatible",
>where);
  return false;
}

[Bug target/78658] New: powerpc64le: ICE with -mcpu=power9 -Og

[anton at samba dot org]

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

Bug ID: 78658
   Summary: powerpc64le: ICE with -mcpu=power9 -Og
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anton at samba dot org
CC: meissner at gcc dot gnu.org, segher at gcc dot gnu.org,
wschmidt at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc64le-linux

The following test case:

float a;
char b;
void c(void) { a = b = a; }

when built with:

gcc -Og -mcpu=power9 crash1.i

hits an ICE:

crash1.i: In function ‘c’:
crash1.i:3:1: error: unrecognizable insn:
 void c(void) { a = b = a; }
 ^~~~
(insn 20 10 21 2 (set (scratch:DI)
(zero_extend:DI (reg:QI 32 0 [159]))) "crash1.i":3 -1
 (nil))
crash1.i:3:1: internal compiler error: in extract_insn, at recog.c:2311
0x1086d6d3 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/gcc/rtl-error.c:108
0x1086d737 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc/gcc/rtl-error.c:116
0x108316b7 extract_insn(rtx_insn*)
../../gcc/gcc/recog.c:2311
0x1083177f extract_insn_cached(rtx_insn*)
../../gcc/gcc/recog.c:2201
0x10514737 cleanup_subreg_operands(rtx_insn*)
../../gcc/gcc/final.c:3138
0x1082e817 split_insn
../../gcc/gcc/recog.c:2925
0x108349bf split_all_insns()
../../gcc/gcc/recog.c:2978
0x10834aa7 rest_of_handle_split_before_sched2
../../gcc/gcc/recog.c:4019
0x10834aa7 execute
../../gcc/gcc/recog.c:4058

[Bug target/78642] [7 regression] ICE: invalid rtl sharing found in the insn on sparc

[ebotcazou at gcc dot gnu.org]

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

--- Comment #4 from Eric Botcazou  ---
> Is your compiler configured with --enable-checking=rtl ?

Yes, but I don't think Rainer's is.

> Perhaps it can be only reproduced natively, or relies on particular
> auto-host.h content (I don't have cross-binutils to Solaris around).

Or it was fixed by your emit-rtl.c change.

[Bug tree-optimization/78646] incorrect result type for pointer addition in slsr

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 CC||wschmidt at gcc dot gnu.org

--- Comment #6 from Bill Schmidt  ---
Stefan, I want to look at the code more carefully to consider potential
alignment issues in total.  I won't get to this until next week, though.

Thanks,
Bill

[Bug c/78657] New: Using macro with _Pragma gives error: '#pragma' is not allowed here

[jquinsey at entrenet dot com]

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

Bug ID: 78657
   Summary: Using macro with _Pragma gives error: '#pragma' is not
allowed here
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jquinsey at entrenet dot com
  Target Milestone: ---

The following two-line source file test.c:

   #define FOO _Pragma("GCC diagnostic push") 42
   int foo = FOO;

gives:

gcc test.c -E
# 1 "test.c"
# 1 ""
# 1 ""
# 1 "test.c"

int foo =
# 2 "test.c"
#pragma GCC diagnostic push
# 2 "test.c"
 42;

gcc test.c   
test.c:2:1: error: expected expression before '#pragma'
 int foo = FOO; 
 ^

g++ -x c++ test.c
test.c:2:1: error: '#pragma' is not allowed here
 int foo = FOO; 
 ^

This appears to be consistent across many versions of gcc and g++. For example,
5.4.0 from Cygwin, 5.1 from this test sample at http://ideone.com/6unk5c, and
versions 4.4 through to 6.2 and 7 at https://godbolt.org/.

The icc and clang compilers (from 3.2 upwards) seem handle this correctly.

The text within the _Pragma doesn't seem relevant. Reversing the order of the
two parts of the macro gives a slightly different error message for C:

error: expected ',' or ';' before '#pragma'

[Bug target/69311] [5 Regression] ICE (cc1 killed) on s390x-linux-gnu

[krebbel at gcc dot gnu.org]

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

Andreas Krebbel  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-12-02
 Ever confirmed|0   |1

[Bug target/69311] [5 Regression] ICE (cc1 killed) on s390x-linux-gnu

[krebbel at gcc dot gnu.org]

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

--- Comment #5 from Andreas Krebbel  ---
Created attachment 40234
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40234=edit
auto-reduced testcase

Fails with -O3 -march=z196. Endless loop in VRP with GCC 5. Works fine with GCC
6 branch.

[Bug target/70322] STV doesn't optimize andn

[uros at gcc dot gnu.org]

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

--- Comment #8 from uros at gcc dot gnu.org ---
Author: uros
Date: Fri Dec  2 18:48:35 2016
New Revision: 243202

URL: https://gcc.gnu.org/viewcvs?rev=243202=gcc=rev
Log:
PR target/70322
* config/i386/i386.md (*andndi3_doubleword): Add non-BMI alternative
and corresponding post-reload splitter.

testsuite/ChangeLog:

PR target/70322
* gcc.target/i386/pr70322-2.c (dg-final): Remove xfail.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/pr70322-2.c

[Bug fortran/78618] ICE in gfc_check_rank, at fortran/check.c:3670

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||janus at gcc dot gnu.org
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |janus at gcc dot gnu.org
   Target Milestone|--- |7.0

--- Comment #5 from janus at gcc dot gnu.org ---
Fixed with r243201. Closing.

[Bug fortran/78618] ICE in gfc_check_rank, at fortran/check.c:3670

[janus at gcc dot gnu.org]

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

--- Comment #4 from janus at gcc dot gnu.org ---
Author: janus
Date: Fri Dec  2 18:38:24 2016
New Revision: 243201

URL: https://gcc.gnu.org/viewcvs?rev=243201=gcc=rev
Log:
2016-12-02  Janus Weil  
Steven G. Kargl  

PR fortran/78618
* check.c (gfc_check_rank): Remove ATTRIBUTE_UNUSED.
* expr.c (gfc_check_assign): Fix error propagation.

2016-12-02  Steven G. Kargl  

PR fortran/78618
* gfortran.dg/char_conversion.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/char_conversion.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/check.c
trunk/gcc/fortran/expr.c
trunk/gcc/testsuite/ChangeLog

[Bug target/78631] [Intel MPX] libmpxwrappers shared library leads to a non-bounds-preserving memcpy()

[hjl.tools at gmail dot com]

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

--- Comment #6 from H.J. Lu  ---
(In reply to Ilya Enkovich from comment #5)
> (In reply to H.J. Lu from comment #3)
> > The problem is that the internal MPX wrapper calls in libmpxwrappers.so:
> Why doesn't call go through bndplt? Users might use similar code in their
> libraries and expect it to work.

-z bndplt is needed to call external functions with bounds.  But
it isn't needed for internal function calls.

[Bug target/78631] [Intel MPX] libmpxwrappers shared library leads to a non-bounds-preserving memcpy()

[ienkovich at gcc dot gnu.org]

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

--- Comment #5 from Ilya Enkovich  ---
(In reply to H.J. Lu from comment #3)
> The problem is that the internal MPX wrapper calls in libmpxwrappers.so:
Why doesn't call go through bndplt? Users might use similar code in their
libraries and expect it to work.

[Bug c++/70909] Libiberty Demangler segfaults (4)

[trippels at gcc dot gnu.org]

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

--- Comment #30 from Markus Trippelsdorf  ---
(In reply to Nathan Sidwell from comment #29)
> On 12/02/2016 12:58 PM, trippels at gcc dot gnu.org wrote:
> 
> > Please also note that Nathan's lambda demangling patch needs adjustments,
> > because with level 1 of recursion it prints everything twice.
> 
> sorry, please clarify.  With what symbol(s)?

Sorry please ignore my statement, it has nothing to do with Mark's patch.

I mean, e.g. (c++filt__ is from libcxxabi, c++filt is libiberty with Nathan's
patch)

markus@x4 libiberty % c++filt__
_ZSt7forwardIR17predicate_matcherIZ11any_matcherIiEDavEUlOT_E_13typed_matcherIiEEES3_RNSt16remove_referenceIS2_E4typeE
int&& std::forward&>(std::remove_reference::type&)
markus@x4 libiberty % c++filt
_ZSt7forwardIR17predicate_matcherIZ11any_matcherIiEDavEUlOT_E_13typed_matcherIiEEES3_RNSt16remove_referenceIS2_E4typeE
predicate_matcher()::{lambda(auto&&)#1},
typed_matcher >& std::forward&>(std::remove_reference&>::type&)
markus@x4 libiberty % c++filt__
_ZN4eggs8variants6detail7forwardIOZN5ossia15vec_merger_implILi2EEclINS0_7variantIJNS3_12strong_valueINS3_11speed_ratioISt5ratioILl1ELl1EENS8_INS9_ISA_ILl16093440ELl3600EENS8_INS9_ISA_ILl1000ELl3600EENS8_INS9_ISA_ILl1852ELl3600EENS8_INS9_ISA_ILl3048ELl1EENS8_INS9_ISA_ILl3048ELl3600EEENS7_IJNS3_5valueENS7_IJNS8_INS3_14distance_ratioISB_NS8_INSV_ISA_ILl1000ELl1EENS8_INSV_ISA_ILl1ELl10EENS8_INSV_ISA_ILl1ELl100EENS8_INSV_ISA_ILl1ELl1000EENS8_INSV_ISA_ILl1ELl100EENS8_INSV_ISA_ILl1ELl10EENS8_INSV_ISA_ILl1ELl1EENS8_INSV_ISA_ILl254ELl1EENS8_INSV_ISN_NS8_INSV_ISA_ILl16093440ELl1ENS7_IJNS8_INS3_14cartesian_3d_uEEENS8_INS3_14cartesian_2d_uEEENS8_INS3_11spherical_uEEENS8_INS3_7polar_uEEENS8_INS3_8opengl_uEEENS8_INS3_13cylindrical_uEEST_NS7_IJNS8_INS3_12quaternion_uEEENS8_INS3_7euler_uEEENS8_INS3_6axis_uEENS7_IJNS8_INS3_8degree_uEEENS8_INS3_8radian_uEENS7_IJNS8_INS3_6argb_uEEENS8_INS3_6rgba_uEEENS8_INS3_5rgb_uEEENS8_INS3_5bgr_uEEENS8_INS3_7argb8_uEEENS8_INS3_5hsv_uEEENS8_INS3_6cmy8_uEEENS8_INS3_5xyz_uEENS7_IJNS8_INS3_8linear_uEEENS8_INS3_10midigain_uEEENS8_INS3_9decibel_uEEENS8_INS3_13decibel_raw_uERKT_EUlRS38_E_EEOS38_RNSt16remove_referenceIS38_E4typeE
eggs::variants::variant > >, ossia::strong_value > >, ossia::strong_value
> >, ossia::strong_value > >,
ossia::strong_value > >,
ossia::strong_value > > >&&
eggs::variants::detail::forward > >, ossia::strong_value > >,
ossia::strong_value > >,
ossia::strong_value > >,
ossia::strong_value > >,
ossia::strong_value > >,
ossia::strong_value > >,
ossia::strong_value > >,
ossia::strong_value > >,
ossia::strong_value > >,
ossia::strong_value > > >,
eggs::variants::variant,
eggs::variants::variant > >, ossia::strong_value > >, ossia::strong_value
> >, ossia::strong_value > >,
ossia::strong_value > >,
ossia::strong_value > > >,
eggs::variants::variant,
eggs::variants::variant,
eggs::variants::variant,
eggs::variants::variant >

[Bug c++/70909] Libiberty Demangler segfaults (4)

[nathan at acm dot org]

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

--- Comment #29 from Nathan Sidwell  ---
On 12/02/2016 12:58 PM, trippels at gcc dot gnu.org wrote:

> Please also note that Nathan's lambda demangling patch needs adjustments,
> because with level 1 of recursion it prints everything twice.

sorry, please clarify.  With what symbol(s)?

nathan

[Bug c++/70909] Libiberty Demangler segfaults (4)

[trippels at gcc dot gnu.org]

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

--- Comment #28 from Markus Trippelsdorf  ---
(In reply to Mark Wielaard from comment #26)
> Created attachment 40233 [details]
> d_print_comp with 1 level of recursion protection
> 
> This is the variant that allows 1 level of recursion (with an xxx ??? to why
> 1 level). Plus various symbols added to demangle-expected from PRs that used
> to crash the demangler because of endless recursion.
> 
> The question now is whether this really is a good fix or if some of these
> symbols really should demangle to something meaningful.

It is always better not to crash. 

Please also note that Nathan's lambda demangling patch needs adjustments,
because with level 1 of recursion it prints everything twice.

[Bug target/78642] [7 regression] ICE: invalid rtl sharing found in the insn on sparc

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
(In reply to Eric Botcazou from comment #1)
> I cannot reproduce at r243172:
> 
> eric@polaris:~/build/gcc/sparc-sun-solaris2.10> gcc/xgcc -Bgcc -S
> 20030917-1.c -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer
> -finline-functions  
> 20030917-1.c:9:1: warning: return type defaults to 'int' [-Wimplicit-int]
>  blah(size,strp)
>  ^~~~
> eric@polaris:~/build/gcc/sparc-sun-solaris2.10>

Is your compiler configured with --enable-checking=rtl ?
Perhaps it can be only reproduced natively, or relies on particular auto-host.h
content (I don't have cross-binutils to Solaris around).

[Bug c++/78645] [6/7 Regression] ICE on invalid C++ code on x86_64-linux-gnu (Segmentation fault, cxx_eval_call_expression)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Well, after changing the static_assert to static_assert (check (2, check), "");
this ICEs already starting with r217663 with -std=c++1y, when C++14 constexpr
were implemented.  With -fpermissive this isn't even error-recovery bug, we
just warn.  I think cxx_eval_call_expression should recognize this and punt.

[Bug c++/70909] Libiberty Demangler segfaults (4)

[nathan at gcc dot gnu.org]

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

--- Comment #27 from Nathan Sidwell  ---
I think the symbols containing 'Ul' should demangle -- they're lambdas and I'd
expect my patch to fix those.  Some of the others certainly look suspicious. 
Did they come out of the compiler, or are they the result of fuzzing?

IMHO it'd be better to change d_print_comp to take a pointer to non-constant
demangle_component, rather than use casts in the function. (I realize current
patch may just be a proof of concept.)  It looks a good approach to me.

[Bug tree-optimization/78646] incorrect result type for pointer addition in slsr

[stefan at reservoir dot com]

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

--- Comment #5 from Stefan M Freudenberger  ---
This is the revised patch:

-  add_expr = fold_build2 (POINTER_PLUS_EXPR, TREE_TYPE (c->base_expr),
+  add_expr = fold_build2 (POINTER_PLUS_EXPR, c->cand_type,
  c->base_expr, c->stride);

[Bug c++/70909] Libiberty Demangler segfaults (4)

[mark at gcc dot gnu.org]

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

Mark Wielaard  changed:

   What|Removed |Added

  Attachment #40230|0   |1
is obsolete||
  Attachment #40231|0   |1
is obsolete||

--- Comment #26 from Mark Wielaard  ---
Created attachment 40233
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40233=edit
d_print_comp with 1 level of recursion protection

This is the variant that allows 1 level of recursion (with an xxx ??? to why 1
level). Plus various symbols added to demangle-expected from PRs that used to
crash the demangler because of endless recursion.

The question now is whether this really is a good fix or if some of these
symbols really should demangle to something meaningful.

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

[law at redhat dot com]

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

--- Comment #6 from Jeffrey A. Law  ---


This is a bad interaction between PREFERRED_STACK_BOUNDARY and PUSH_ROUNDING,
but there's a deeper code generation issue that needs to be looked at as well.

So background.  A push insn on the m68k is actually a store using a
pre-decrement addressing mode and register a7. ie -(%a7) aka -(%sp)

The original m68k family special cased byte pushes so that if you did something
like

mov.b ,-(%sp)

You would actually push 2 bytes on the stack instead of 1 to ensure the stack
was always 2 byte aligned.  This quirk was only done when using sp/a7 in
predec/postinc addressing modes as push/pop insns.

The coldfire family did away with that quirk and no longer special cases sp/a7
in those addressing modes.


GCC uses PUSH_ROUNDING to describe the behavior of the original m68k family. 
As expected it's behavior is now conditional on TARGET_COLDFIRE:

/* On the 680x0, sp@- in a byte insn really pushes a word.
   On the ColdFire, sp@- in a byte insn pushes just a byte.  */
#define PUSH_ROUNDING(BYTES) (TARGET_COLDFIRE ? BYTES : ((BYTES) + 1) & ~1)


Another quirk of the Coldfire family is that it really prefers its stack stack
32 bit aligned.  It impacts all kinds of things.  So not surprisingly m68k has
(m68k.h and linux.h respectively):

/* ColdFire and fido strongly prefer a 32-bit aligned stack.  */
#define PREFERRED_STACK_BOUNDARY \
  ((TARGET_COLDFIRE || TARGET_FIDOA) ? 32 : 16)


#undef PREFERRED_STACK_BOUNDARY
#define PREFERRED_STACK_BOUNDARY 32


So far, so good on the target bits.We define various sync builtins,
including:

DEF_SYNC_BUILTIN (BUILT_IN_SYNC_VAL_COMPARE_AND_SWAP_1,
  "__sync_val_compare_and_swap_1",
  BT_FN_I1_VPTR_I1_I1, ATTR_NOTHROWCALL_LEAF_LIST)

ie,

char __sync_val_compare_and_swap_1 (void *, char, char)

These are called as libcalls, not normal functions.  This distinction is
important.  

So when we make a call to __sync_val_compare_and_swap, on coldfire we push 6
bytes of data.  This then runs afoul of this assert in
emit_library_call_value_1:


 /* Stack must be properly aligned now.  */
  gcc_assert (!(stack_pointer_delta
& (PREFERRED_STACK_BOUNDARY / BITS_PER_UNIT - 1)));

(STACK_POINTER_DELTA will be 6).


But wait, it's actually worse.  While the caller seems to want to push bytes,
the callee seems to be using a more standard ABI where the usual promotions
occur.  ie, expects the caller to have pushed 32bit words.

So not only do we have the assertion to deal with, we really need to address
the ABI mismatch.  What a mess.  There's a reasonable chance I will not get
this addressed prior to gcc-7.  m68k just isn't that high a priority.

[Bug libstdc++/70530] [DR2468] You should probably add addressof (a) != addressof (b) check to std::swap

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
DR 2468 now says we should do something like this.

[Bug c++/70909] Libiberty Demangler segfaults (4)

[mark at gcc dot gnu.org]

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

--- Comment #25 from Mark Wielaard  ---
(In reply to Markus Trippelsdorf from comment #24)
> (In reply to Mark Wielaard from comment #22)
> > Created attachment 40230 [details]
> > d_printing mark/walk/unmark protection
> > 
> > (In reply to Nathan Sidwell from comment #21)
> > > Why doesn't a mark/walk/unmark idiom when walking a potentially circular
> > > data structure work here?  I.e. add a mutable counter to 
> > > demangle_component.
> > > Inc/dec at start/end of d_print_comp? IIUC if it gets to >1 there's a
> > > problem.
> > 
> > That is a good idea. However it seems things aren't as simple as that.
> > The attached patch implements it, but that produces various testsuite
> > failures:
> > ./test-demangle: 960 tests, 7 failures
> > 
> > It might of course be that I messed up the check or that any of these
> > failures really are bad.
> 
> You need to allow one more level of recursion. The following variant works
> fine: 

Indeed it does!
Why do we need the extra recursion level?

This prevents crashes for various issues collected in this and other PRs.
The only question is if those mangled symbols are all really bad. There are a
couple that don't demangle, but where the user seems to expect they would. Of
course they certainly don't expect to crash the demangler, so it is an
improvement, but some extra investigation seems necessary.

[Bug target/77267] MPX does not work in a presence of "-Wl,-as-needed" option (Ubuntu default)

[aivchenk at gmail dot com]

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

Alexander Ivchenko  changed:

   What|Removed |Added

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

--- Comment #11 from Alexander Ivchenko  ---
Fixed with r240057

[Bug other/65530] [meta-bug] -mmpx -fcheck-pointer-bounds failures

[aivchenk at gmail dot com]

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

Bug 77267 Summary: MPX does not work in a presence of "-Wl,-as-needed" option 
(Ubuntu default)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77267

   What|Removed |Added

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

[Bug target/78631] [Intel MPX] libmpxwrappers shared library leads to a non-bounds-preserving memcpy()

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu  ---
Created attachment 40232
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40232=edit
A patch

[Bug ipa/78644] [7 Regression] ICE: SIGSEGV in is_gimple_reg_type with -Og -fipa-cp

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Verified reverting the tree-ssa-ccp.c hunk of r242920 makes the ICE go away
(then instead of _18 = _7 + _17; there is _18 = x2_3 + _17;
(no idea why _7 hasn't actually been replaced with 0 but just with x2_3, though
there is UB involved in the loop if x4[0] isn't 0 at the beginning)).

[Bug target/78631] [Intel MPX] libmpxwrappers shared library leads to a non-bounds-preserving memcpy()

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Last reconfirmed||2016-12-02
 Resolution|INVALID |---
 Ever confirmed|0   |1

--- Comment #3 from H.J. Lu  ---
The problem is that the internal MPX wrapper calls in libmpxwrappers.so:

(gdb) disass
Dump of assembler code for function __mpx_wrapper_memcpy:
=> 0x779d1120 <+0>: sub$0x8,%rsp
   0x779d1124 <+4>: bnd callq 0x779cfb50
<__mpx_wrapper_memmove@plt>
   0x779d112a <+10>:add$0x8,%rsp
   0x779d112e <+14>:bnd retq 
End of assembler dump.

(gdb) disass
Dump of assembler code for function __mpx_wrapper_memmove@plt:
=> 0x779cfb50 <+0>: jmpq   *0x2024c2(%rip)# 0x77bd2018
   0x779cfb56 <+6>: pushq  $0x0
   0x779cfb5b <+11>:jmpq   0x779cfb40
End of assembler dump.

[Bug c++/70909] Libiberty Demangler segfaults (4)

[trippels at gcc dot gnu.org]

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

--- Comment #24 from Markus Trippelsdorf  ---
(In reply to Mark Wielaard from comment #22)
> Created attachment 40230 [details]
> d_printing mark/walk/unmark protection
> 
> (In reply to Nathan Sidwell from comment #21)
> > Why doesn't a mark/walk/unmark idiom when walking a potentially circular
> > data structure work here?  I.e. add a mutable counter to demangle_component.
> > Inc/dec at start/end of d_print_comp? IIUC if it gets to >1 there's a
> > problem.
> 
> That is a good idea. However it seems things aren't as simple as that.
> The attached patch implements it, but that produces various testsuite
> failures:
> ./test-demangle: 960 tests, 7 failures
> 
> It might of course be that I messed up the check or that any of these
> failures really are bad.

You need to allow one more level of recursion. The following variant works
fine: 

+  /* We need to cheat for the endless recursive printing protection.  */
+  struct demangle_component *dc1 = (struct demangle_component *) dc;
+  if (dc1 == NULL || dc1->d_printing > 1)
+{
+  d_print_error (dpi);
+  return;
+}
+  else
+dc1->d_printing += 1;

[Bug rtl-optimization/78652] LRA generates wrong code by inheriting changed register

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

  Known to work||6.2.1
  Known to fail||7.0

--- Comment #2 from amker at gcc dot gnu.org ---
Tested on 6.2.1, it works.

[Bug target/78255] [5/6/7 regression] Indirect sibling call causing wrong code generation for ARM

[law at redhat dot com]

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

--- Comment #11 from Jeffrey A. Law  ---
IIRC the (proprietary) linker didn't generate argument shuffling stubs for
indirect calls.  So we ran into problems if any pass changed a direct into an
indirect call.  The only pass that did this back in the early 90s was CSE :-)

If an indirect call were changed to a direct call, we could have an argument
location mis-match, but the linker would step in and generate a little stub to
shuffle them into the expected locations.  Thus we never bothered trying to fix
combine.

[Bug ipa/78644] [7 Regression] ICE: SIGSEGV in is_gimple_reg_type with -Og -fipa-cp

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
So, before ccp4 we have:
  _7 = x3_1 + x2_3;
  _8 = {_7, _7, _7, _7};
  x4.1_9 = x4;
  _15 = {_7, _7, _7, _7};
  _16 = BIT_FIELD_REF <_15, 128, 0>;
  _17 = BIT_FIELD_REF ;
  _18 = _16 + _17;
  _19 = {_7, _7, _7, _7};
  _20 = BIT_FIELD_REF <_19, 128, 128>;
  _21 = BIT_FIELD_REF ;
  _22 = _20 + _21;
  _23 = {_7, _7, _7, _7};
  _24 = BIT_FIELD_REF <_23, 128, 256>;
  _25 = BIT_FIELD_REF ;
  _26 = _24 + _25;
  _27 = {_7, _7, _7, _7};
  _28 = BIT_FIELD_REF <_27, 128, 384>;
  _29 = BIT_FIELD_REF ;
  _30 = _28 + _29;
  _10 = {_18, _22, _26, _30};
   = _10;

ccp4 sees those uses:
_7 : -->20 uses.
_27 = {_7, _7, _7, _7};
_27 = {_7, _7, _7, _7};
_27 = {_7, _7, _7, _7};
_27 = {_7, _7, _7, _7};
_23 = {_7, _7, _7, _7};
_23 = {_7, _7, _7, _7};
_23 = {_7, _7, _7, _7};
_23 = {_7, _7, _7, _7};
_19 = {_7, _7, _7, _7};
_19 = {_7, _7, _7, _7};
_19 = {_7, _7, _7, _7};
_19 = {_7, _7, _7, _7};
_15 = {_7, _7, _7, _7};
_15 = {_7, _7, _7, _7};
_15 = {_7, _7, _7, _7};
_15 = {_7, _7, _7, _7};
_8 = {_7, _7, _7, _7};
_8 = {_7, _7, _7, _7};
_8 = {_7, _7, _7, _7};
_8 = {_7, _7, _7, _7};
...
Visiting statement:
_7 = x3_1 + x2_3;
which is likely CONSTANT
Match-and-simplified x3_1 + x2_3 to 0
Lattice value changed to CONSTANT 0.  Adding SSA edges to worklist.

and replaces all those ctors with {x2_3, x2_3, x2_3, x2_3}.
But folding also happens while this is ongoing:
Folding statement: _17 = BIT_FIELD_REF ;
Not folded
Folding statement: _18 = _16 + _17;
Folded into: _18 = _7 + _17;
and thus a new _7 reference appears, and we don't fold that into _18 = x2_3 +
_17, but remove the _7 setter, because we assume all uses are replaced:

Removing dead stmt _7 = x3_1 + x2_3;

Richi, I think this is your area of expertise.

[Bug rtl-optimization/78638] [7 regression] test cases gcc.target/powerpc/rlwimi-0.c and rlwimi-2.c fail starting with r243000

[seurer at linux dot vnet.ibm.com]

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

--- Comment #3 from Bill Seurer  ---
Also on power6...

[Bug rtl-optimization/78638] [7 regression] test cases gcc.target/powerpc/rlwimi-0.c and rlwimi-2.c fail starting with r243000

[seurer at linux dot vnet.ibm.com]

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

--- Comment #2 from Bill Seurer  ---
I see it on both BE and LE, power7 and power8.

Also a whole bunch more of your new tests started complaining:

New failures:
FAIL: gcc.target/powerpc/ppc-negeq0-1.c scan-assembler-not cntlz
FAIL: gcc.target/powerpc/rldic-0.c scan-assembler-times (?n)^s+[a-z] 1799
FAIL: gcc.target/powerpc/rldic-1.c scan-assembler-times (?n)^s+[a-z] 1799
FAIL: gcc.target/powerpc/rldic-1.c scan-assembler-times (?n)^s+rldic 415
FAIL: gcc.target/powerpc/rldic-1.c scan-assembler-times (?n)^s+sldi 29
FAIL: gcc.target/powerpc/rldimi-0.c scan-assembler-times (?n)^s+[a-z] 4471
FAIL: gcc.target/powerpc/rldimi-0.c scan-assembler-times (?n)^s+mr 873
FAIL: gcc.target/powerpc/rldimi-0.c scan-assembler-times (?n)^s+rldimi 1744
FAIL: gcc.target/powerpc/rldimi-0.c scan-assembler-times (?n)^s+rotldi 54
FAIL: gcc.target/powerpc/rldimi-1.c scan-assembler-times (?n)^s+[a-z] 4045
FAIL: gcc.target/powerpc/rldimi-1.c scan-assembler-times (?n)^s+mr 447
FAIL: gcc.target/powerpc/rldimi-1.c scan-assembler-times (?n)^s+rldimi 892
FAIL: gcc.target/powerpc/rlwinm-0.c scan-assembler-times (?n)^s+[a-z] 9730
FAIL: gcc.target/powerpc/rlwinm-0.c scan-assembler-times (?n)^s+rldicl 3095
FAIL: gcc.target/powerpc/rlwinm-0.c scan-assembler-times (?n)^s+rlwinm 3094
FAIL: gcc.target/powerpc/rlwinm-0.c scan-assembler-times (?n)^s+srdi 12
FAIL: gcc.target/powerpc/rlwinm-1.c scan-assembler-times (?n)^s+[a-z] 9606
FAIL: gcc.target/powerpc/rlwinm-1.c scan-assembler-times (?n)^s+rldic 2946
FAIL: gcc.target/powerpc/rlwinm-1.c scan-assembler-times (?n)^s+rlwinm 622
FAIL: gcc.target/powerpc/rlwinm-1.c scan-assembler-times (?n)^s+slwi 1
FAIL: gcc.target/powerpc/rlwinm-2.c scan-assembler-times (?n)^s+[a-z] 9466
FAIL: gcc.target/powerpc/rlwinm-2.c scan-assembler-times (?n)^s+rldic 2840
FAIL: gcc.target/powerpc/rlwinm-2.c scan-assembler-times (?n)^s+rlwinm 721
FAIL: gcc.target/powerpc/rlwinm-2.c scan-assembler-times (?n)^s+srdi 12

[Bug ipa/78644] [7 Regression] ICE: SIGSEGV in is_gimple_reg_type with -Og -fipa-cp

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
I'm seeing it starting with r242923, but that doesn't make any sense, the ICE
is in ccp4 and the dump before ccp4 looks identical between compiler that ICEs
and doesn't ICE.  So r242920 looks much more likely culprit from a close range
to that.

[Bug tree-optimization/78646] incorrect result type for pointer addition in slsr

[stefan at reservoir dot com]

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

--- Comment #4 from Stefan M Freudenberger  ---
I guess there wouldn't be an issue if it were a reference type. However, there
is an issue with the incorrect alignment for the object type.

[Bug target/70799] STV pass does not convert DImode shifts

[ubizjak at gmail dot com]

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

--- Comment #6 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #5)
> (In reply to Uroš Bizjak from comment #0)
> > These should all be converted to DImode vector shifts for SSE2/AVX2 32bit
> > target (and similar for rotates):
> 
> There are no corresponding SSE insns for rotates.

There are only variable logical shifts missing from the set of possible STV
transformations on x86. There is slight complication present: in contrast to
integer instructions, SSE shifts don't use masked count operand, so masking of
count operand is necessary. Loading of 0x63 constant and executing AND on SSE
register can be costly, so masking should be performed with a SImode integer
instruction. After that, SImode value can be moved to SSE register and used in
a shift.

OTOH, following code for a simple DImode shift:

movl4(%esp), %ecx
movla+4, %edx
movla, %eax
shrdl   %edx, %eax
shrl%cl, %edx
testb   $32, %cl
je  .L2
movl%edx, %eax
xorl%edx, %edx
.L2:
movl%eax, c
movl%edx, c+4
ret

would be converted to:

movl4(%esp), %eax
andl$63, %eax
movd%eax, %xmm1
movqa, %xmm0
psrlq   %xmm1, %xmm0
movq%xmm0, c
ret

if we don't care about undefined values, then

movzbl  4(%esp), %eax
movd%eax, %xmm1
movqa, %xmm0
psrlq   %xmm1, %xmm0
movq%xmm0, c
ret

would do the trick, too.

[Bug target/70322] STV doesn't optimize andn

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Fri Dec  2 16:28:41 2016
New Revision: 243195

URL: https://gcc.gnu.org/viewcvs?rev=243195=gcc=rev
Log:
PR target/70322
* config/i386/i386.c (dimode_scalar_to_vector_candidate_p): Handle
NOT.
(dimode_scalar_chain::compute_convert_gain): Likewise.
(dimode_scalar_chain::convert_insn): Likewise.
* config/i386/i386.md (*one_cmpldi2_doubleword): New
define_insn_and_split.
(one_cmpl2): Use SWIM1248x iterator instead of SWIM.

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

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

[Bug tree-optimization/72785] [7 Regression] kernel build error since r236831

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #18 from Christophe Lyon  ---
*** Bug 78653 has been marked as a duplicate of this bug. ***

[Bug other/78653] badly optimized kernel code with -fsanitize=object-size -fsanitize=null

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #4 from Christophe Lyon  ---
Thanks for the pointer, Markus.

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

[Bug ipa/78599] [7 Regression] hwint.h:292:72: runtime error: shift exponent 64 is too large for 64-bit type 'long int'

[trippels at gcc dot gnu.org]

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

--- Comment #8 from Markus Trippelsdorf  ---
(In reply to Martin Jambor from comment #7)
> I cannot reproduce this using the testcase from comment #1 even whe I add
> -fsanitize=undefined to the command line.  Is this on x86_64?

You need to use an instrumented compiler, either
--with-build-config="bootstrap-ubsan" or CXX="g++ -fsanitize=undefined"
../gcc/configure.

[Bug target/78255] [5/6/7 regression] Indirect sibling call causing wrong code generation for ARM

[wilco at gcc dot gnu.org]

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

--- Comment #10 from wilco at gcc dot gnu.org ---
(In reply to Richard Earnshaw from comment #8)
> Hmm, why is this even being considered on ARM?
> 
> arm.h:#define NO_FUNCTION_CSE 1
> 
> doc/tm.texi
> @defmac NO_FUNCTION_CSE
> Define this macro to be true if it is as good or better to call a constant
> function address than to call an address kept in a register.
> @end defmac

(In reply to Jeffrey A. Law from comment #9)
> Also note that on some targets indirect calls have a different ABI than
> calls to named function.  SO changing between direct and indirect calls is
> strictly forbidden on some targets.
> 
> I suspect there's some magic we need to replicate in postreload-gcse from
> cse/gcse/combine to prevent this from occurring unnecessarily.

Well it's easy to add NO_FUCNTION_CSE to postreload. However a quick experiment
shows combine still changes indirect calls to direct calls, so if the ABI is
not identical this would be incorrect. So there are multiple places where this
would need to be fixed.

[Bug c++/78656] New: Fix-it suggestion for std::alocator doesn't include std::allocator

[redi at gcc dot gnu.org]

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

Bug ID: 78656
   Summary: Fix-it suggestion for std::alocator doesn't include
std::allocator
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
CC: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

This typo for std::allocator gets a poor suggestion:

#include 

void* allocate(std::size_t n) { return std::allocate().allocate(n); }

bad-fixit.cc: In function ‘void* allocate(std::size_t)’:
bad-fixit.cc:3:40: error: ‘allocate’ is not a member of ‘std’
 void* allocate(std::size_t n) { return std::allocate().allocate(n); }
^~~
bad-fixit.cc:3:40: note: suggested alternative:
bad-fixit.cc:3:7: note:   ‘allocate’
 void* allocate(std::size_t n) { return std::allocate().allocate(n); }
   ^~~~
bad-fixit.cc:3:54: error: expected primary-expression before ‘char’
 void* allocate(std::size_t n) { return std::allocate().allocate(n); }
  ^~~~
bad-fixit.cc:3:54: error: expected ‘;’ before ‘char’
bad-fixit.cc:3:58: error: expected unqualified-id before ‘>’ token
 void* allocate(std::size_t n) { return std::allocate().allocate(n); }
  ^

Even std::allocato or std::allocator or std::alocator doesn't get a good
suggestion, it still suggests changing "std" to "allocate" (which would give
"allocate::allocate")

It seems that qualification with namespaces isn't really supported properly.

[Bug ipa/78599] [7 Regression] hwint.h:292:72: runtime error: shift exponent 64 is too large for 64-bit type 'long int'

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu.org

--- Comment #7 from Martin Jambor  ---
I cannot reproduce this using the testcase from comment #1 even whe I add
-fsanitize=undefined to the command line.  Is this on x86_64?

[Bug c++/70909] Libiberty Demangler segfaults (4)

[mark at gcc dot gnu.org]

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

--- Comment #23 from Mark Wielaard  ---
Created attachment 40231
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40231=edit
Check output with d_printing.patch

[Bug c++/70909] Libiberty Demangler segfaults (4)

[mark at gcc dot gnu.org]

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

--- Comment #22 from Mark Wielaard  ---
Created attachment 40230
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40230=edit
d_printing mark/walk/unmark protection

(In reply to Nathan Sidwell from comment #21)
> Why doesn't a mark/walk/unmark idiom when walking a potentially circular
> data structure work here?  I.e. add a mutable counter to demangle_component.
> Inc/dec at start/end of d_print_comp? IIUC if it gets to >1 there's a
> problem.

That is a good idea. However it seems things aren't as simple as that.
The attached patch implements it, but that produces various testsuite failures:
./test-demangle: 960 tests, 7 failures

It might of course be that I messed up the check or that any of these failures
really are bad.

[Bug fortran/78505] [F08] Coarray source allocation not synchronizing on oversubscribed cores

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

--- Comment #2 from vehre at gcc dot gnu.org ---
Waiting for review. Patch available at:

https://gcc.gnu.org/ml/fortran/2016-12/msg00012.html

[Bug target/78614] [7 Regression] ICE error: invalid rtl sharing found in the insn (verify_rtx_sharing) gcc/emit-rtl.c:2743

[jakub at gcc dot gnu.org]

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

--- Comment #24 from Jakub Jelinek  ---
Author: jakub
Date: Fri Dec  2 15:42:04 2016
New Revision: 243194

URL: https://gcc.gnu.org/viewcvs?rev=243194=gcc=rev
Log:
PR target/78614
* rtl.c (copy_rtx): Don't clear used flag here.
(shallow_copy_rtx_stat): Clear used flag here unless code the rtx
is shareable.
* simplify-rtx.c (simplify_replace_fn_rtx): When copying rtx with
'E' in format, copy all vectors.
* emit-rtl.c (copy_insn_1): Don't clear used flag here.
* valtrack.c (cleanup_auto_inc_dec): Likewise.
* config/rs6000/rs6000.c (rs6000_frame_related): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/emit-rtl.c
trunk/gcc/rtl.c
trunk/gcc/valtrack.c

[Bug libstdc++/78058] Complex initialization of nested std::optional does not work

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

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

--- Comment #3 from Ville Voutilainen  ---
Fixed by r242401

[Bug libstdc++/78058] Complex initialization of nested std::optional does not work

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 CC||ville.voutilainen at gmail dot 
com

--- Comment #2 from Ville Voutilainen  ---
This is fixed by r242401

[Bug libstdc++/78595] Unnecessary copies in _Rb_tree

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
Oops, the second condition *should* fail in that last example, but here it
shouldn't:

#include 
#include 
#include 

struct Key { int key; };

struct X {
  operator std::pair() const { return { { x }, 0 }; }
  int x;
};

template
struct Alloc
{
  Alloc() = default;
  template
Alloc(const Alloc&) { }
  using value_type = T;

  T* allocate(std::size_t n) { return std::allocator().allocate(n); }
  void deallocate(T* p, std::size_t n) { std::allocator().deallocate(p, n);
}

  template
void construct(U* p, const X& x) { ::new (p) U{ { x.x+1 }, 0}; }

  template
bool operator==(const Alloc&) { return true; }
  template
bool operator!=(const Alloc&) { return false; }
};

bool operator<(const Key& l, const Key& r) { return l.key < r.key; }

int main()
{
  using namespace std;
  map, Alloc> m;
  m.insert(X{});
  m.insert(X{}); // RB tree is corrupted
  if (m.size() != 1)
puts("RB tree corrupt");

  map, Alloc> m2;
  m.insert(X{});
  m.insert(X{1});
  if (m.size() != 2)
puts("RB tree failed to insert distinct value");
}

[Bug c++/78655] New: gcc doesn't exploit the fact that the result of pointer addition can not be nullptr

[vanyacpp at gmail dot com]

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

Bug ID: 78655
   Summary: gcc doesn't exploit the fact that the result of
pointer addition can not be nullptr
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vanyacpp at gmail dot com
  Target Milestone: ---

Consider the following piece of code:

#include 

struct blob
{
void* data;
size_t size;
};

void uninitialized_copy(blob* first, blob* last, blob* current)
{
for (; first != last; ++first, (void) ++current) {
::new (static_cast(current)) blob(*first);
}
}

The nested loop generated for it by GCC 7 is the following:

.L4:
testq   %rdx, %rdx
je  .L3
movdqu  (%rdi), %xmm0
movups  %xmm0, (%rdx)
.L3:
addq$16, %rdi
addq$16, %rdx
cmpq%rdi, %rsi
jne .L4

As you can see after each iteration generated code checks if current is nullptr
and omit calling the copy constructor if it is so.

Clang 3.9 doesn't exhibit such behavior. It translates the loop into:

.LBB0_1:# =>This Inner Loop Header: Depth=1
movups  (%rdi), %xmm0
movups  %xmm0, (%rdx)
addq$16, %rdi
addq$16, %rdx
cmpq%rdi, %rsi
jne .LBB0_1

This optimization is valid, because if addition of pointer and integer results
in nullptr, the integer was clearly out of bound of allocated memory block thus
the addition causes undefined behavior.

Absence of this optimization affects std::uninitialized_copy and any functions
that use it (for example std::vector::push_back).

The issue can be reproduced with a simpler piece of code:

bool g(int* a)
{
return (a + 10) != nullptr;
}

GCC 7:
g(int*):
cmpq$-40, %rdi
setne   %al
ret

Clang 3.9:
g(int*): # @g(int*)
movb$1, %al
retq

P.S. Another issue is that GCC used mismatched instructions to read from/to
memory. movdqu -- is for integer data, movups -- is for single precision
floating point. I don't know if it causes any stalls on modern CPUs, I heard
that on older CPU writing register with an instruction of one type and reading
with an instruction of another might causes stalls. Should I report a separate
bug report issue for this?

[Bug libstdc++/78595] Unnecessary copies in _Rb_tree

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
Pure evil:


#include 
#include 

struct Key { int key; };

struct X {
  operator std::pair() const { return { { x }, 0 }; }
  int x;
};

template
struct Alloc
{
  Alloc() = default;
  template
Alloc(const Alloc&) { }
  using value_type = T;

  T* allocate(std::size_t n) { return std::allocator().allocate(n); }
  void deallocate(T* p, std::size_t n) { std::allocator().deallocate(p, n);
}

  template
void construct(U* p, const X&) { ::new (p) U{ { 99 }, 0}; }

  template
bool operator==(const Alloc&) { return true; }
  template
bool operator!=(const Alloc&) { return false; }
};

bool operator<(const Key& l, const Key& r) { return l.key < r.key; }

int main()
{
  using namespace std;
  map, Alloc> m;
  m.insert(X{});
  m.insert(X{}); // RB tree is corrupted
  if (m.size() != 1)
__builtin_puts("RB tree corrupt");

  map, Alloc> m2;
  m.insert(X{});
  m.insert(X{99});
  if (m.size() != 2)
__builtin_puts("RB tree failed to insert distinct value");
}

[Bug other/78654] ubsan can lead to excessive stack usage

[clyon at gcc dot gnu.org]

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

--- Comment #2 from Christophe Lyon  ---
Created attachment 40229
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40229=edit
preprocessed source from linux/drivers/media/dvb-frontends/mb86a16.c

[Bug other/78654] ubsan can lead to excessive stack usage

[clyon at gcc dot gnu.org]

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

--- Comment #1 from Christophe Lyon  ---
Created attachment 40228
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40228=edit
preprocessed source from linux/crypto/serpent_generic.c

[Bug other/78654] New: ubsan can lead to excessive stack usage

[clyon at gcc dot gnu.org]

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

Bug ID: 78654
   Summary: ubsan can lead to excessive stack usage
   Product: gcc
   Version: 7.0
   URL: https://bugs.linaro.org/show_bug.cgi?id=2350
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

[Forwarding Arnd's bug report from
https://bugs.linaro.org/show_bug.cgi?id=2350]

When building the kernel with all sanitizers enabled, some functions have a
much larger stack frame than expected. In some cases we just barely cross the
1024 byte stack size limit for functions that were already using a lot, but one
file sticks out from using almost twice as much as before.

Using today's trunk
$ arm-none-linux-gnueabi-gcc -O2 -Wno-pointer-sign  -Wframe-larger-than=100 -
c serpent_generic.i 
frame size 528

$ arm-none-linux-gnueabi-gcc -O2 -Wno-pointer-sign  -Wframe-larger-than=1024 -c
 serpent_generic.i -fsanitize=shift -fsanitize=integer-divide-by-zero
-fsanitize=unreachable -fsanitize=vla-bound -fsanitize=null
-fsanitize=signed-integer-overflow -fsanitize=bounds -fsanitize=object-size
-fsanitize=returns-nonnull-attribute -fsanitize=bool -fsanitize=enum
-fsanitize=alignment
frame size 1072

$ arm-none-linux-gnueabi-gcc  -Wall -Wframe-larger-than=100 -Wno-pointer-sign
-Os -c  mb86a16.i
frame size 416

$ arm-none-linux-gnueabi-gcc  -Wall -Wframe-larger-than=100 -Wno-pointer-sign
-Os -c  mb86a16.i -fsanitize=signed-integer-overflow
frame size 448

[Bug other/78653] badly optimized kernel code with -fsanitize=object-size -fsanitize=null

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org

--- Comment #3 from Markus Trippelsdorf  ---
See: PR72785

[Bug other/78653] badly optimized kernel code with -fsanitize=object-size -fsanitize=null

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-12-02
 Ever confirmed|0   |1

--- Comment #2 from Christophe Lyon  ---
To reproduce, use:
arm-linux-gnueabi-gcc -Wno-pointer-sign -O2 -fsanitize=object-size
-fsanitize=null -c -o zl10353.o zl10353.i
nm zl10353.o | grep ilog2_NaN

Compiling without -fsanitize=object-size -fsanitize=null removes the reference
to ilog2_NaN

Reproduced with today's trunk, but originally reported against 5.3.1

[Bug other/78653] badly optimized kernel code with -fsanitize=object-size -fsanitize=null

[clyon at gcc dot gnu.org]

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

--- Comment #1 from Christophe Lyon  ---
Created attachment 40227
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40227=edit
preprocessed source from linux/drivers/media/dvb-frontends/zl10353.i

[Bug other/78653] New: badly optimized kernel code with -fsanitize=object-size -fsanitize=null

[clyon at gcc dot gnu.org]

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

Bug ID: 78653
   Summary: badly optimized kernel code with
-fsanitize=object-size -fsanitize=null
   Product: gcc
   Version: 7.0
   URL: https://bugs.linaro.org/show_bug.cgi?id=2354
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---
Target: arm

As described in the original bug report
(https://bugs.linaro.org/show_bug.cgi?id=2354)
parts of the Linux kernel fail to build after enabling UBSAN.

With the sample attached testcase, a simple function gets expanded to a very
complex expression. The original source for the function is

static void zl10353_calc_nominal_rate(struct dvb_frontend *fe,
  u32 bandwidth,
  u16 *nominal_rate)
{
struct zl10353_state *state = fe->demodulator_priv;
u32 adc_clock = 450560; /* 45.056 MHz */
u64 value;
u8 bw = bandwidth / 100;

if (state->config.adc_clock)
adc_clock = state->config.adc_clock;

value = (u64)10 * (1 << 23) / 7 * 125;
value = (bw * value) + adc_clock / 2;
do_div(value, adc_clock);
*nominal_rate = value;

dprintk("%s: bw %d, adc_clock %d => 0x%x\n",
__func__, bw, adc_clock, *nominal_rate);
}

The key here appears to be the setting of adc_clock, which the compiler knows
is not zero, but it doesn't know the actual value of.

The do_div() macro in turn is a complex way of turning a constant 64-bit
division into a multiplication, for reference the non-preprocessed version is
at
http://lxr.free-electrons.com/source/include/asm-generic/div64.h?v=4.6
The __builtin_constant_p() here should guard code that only makes sense for a
constant input:

208 if (__builtin_constant_p(__base) && \
209 is_power_of_2(__base)) {\
210 __rem = (n) & (__base - 1); \
211 (n) >>= ilog2(__base);  \

however, the ilog2_NaN symbol is referenced here:

#define ilog2(n)\
(   \
__builtin_constant_p(n) ? ( \
(n) < 1 ? ilog2_NaN() : \
(n) & (1ULL << 63) ? 63 :   \
(n) & (1ULL << 62) ? 62 :   \
(n) & (1ULL << 61) ? 61 :   \
(n) & (1ULL << 60) ? 60 :   \
...
(n) & (1ULL <<  1) ?  1 :   \
(n) & (1ULL <<  0) ?  0 :   \
ilog2_NaN() \
   ) :  \
(sizeof(n) <= 4) ?  \
__ilog2_u32(n) :\
__ilog2_u64(n)  \
 )

after 'n' has been determined to be constant yet not known whether
it is less than '1', which mathematically makes no sense.

[Bug libstdc++/78595] Unnecessary copies in _Rb_tree

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #0)
> This prints "conv" twice, because we create a temporary to get the key here:
> 
>   pair<_Base_ptr, _Base_ptr> __res
>   = _M_get_insert_unique_pos(_KeyOfValue()(__v));

This is extra-broken, because the temporary that gets implicitly created could
fail for at least these reasons:

- the relevant constructor of value_type is explicit
- there is no relevant constructor, because it expects an allocator (we would
need to use the _Temporary_value helper type from  there)

Even if the implicit conversion works, the key of that temporary might not be
the same as the key that would result from constructing the value_type with an
allocator.

Here be dragons. With guns. And they're angry.

[Bug libstdc++/78595] Unnecessary copies in _Rb_tree

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

Version|7.0 |unknown

--- Comment #5 from Ville Voutilainen  ---
Jonathan and I looked at this, and a proper fix requires teaching the functions
in bits/stl_tree.h new tricks. That's not stage3 material, so let's punt this
to 8.

[Bug c++/67054] Constructor inheritance with non-default constructible members

[martin.hierholzer at desy dot de]

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

--- Comment #2 from Martin Hierholzer  ---
I stumbled across this bug, too (and asked about it on stackoverflow, since I
wasn't sure if it's valid C++11, see
http://stackoverflow.com/questions/40932844/constructor-inheritance-and-direct-member-initialisation).

This problem is still there in gcc 6.2.0.

The code compiles, if one adds a default constructor to NonDefault, despite
that default constructor never gets called in the end. (This can be used as a
work-around).

[Bug rtl-optimization/78561] Constant pool size (offset) can become stale where constant pool entires become unused

[jgreenhalgh at gcc dot gnu.org]

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

--- Comment #3 from James Greenhalgh  ---
Author: jgreenhalgh
Date: Fri Dec  2 14:31:10 2016
New Revision: 243183

URL: https://gcc.gnu.org/viewcvs?rev=243183=gcc=rev
Log:
[Patch 2/2 PR78561] Recalculate constant pool size before emitting it

gcc/

PR rtl-optimization/78561
* varasm.c (recompute_pool_offsets): New.
(output_constant_pool): Call it.

gcc/testsuite/

PR rtl-optimization/78561
* gcc.target/aarch64/pr78561.c: New.



Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/varasm.c

[Bug rtl-optimization/78561] Constant pool size (offset) can become stale where constant pool entires become unused

[jgreenhalgh at gcc dot gnu.org]

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

--- Comment #2 from James Greenhalgh  ---
Author: jgreenhalgh
Date: Fri Dec  2 14:29:35 2016
New Revision: 243182

URL: https://gcc.gnu.org/viewcvs?rev=243182=gcc=rev
Log:
[Patch 1/2 PR78561] Rename get_pool_size to get_pool_size_upper_bound

gcc/

PR rtl-optimization/78561
* config/rs6000/rs6000.c (rs6000_reg_live_or_pic_offset_p) Rename
get_pool_size to get_pool_size_upper_bound.
(rs6000_stack_info): Likewise.
(rs6000_emit_prologue): Likewise.
(rs6000_elf_declare_function_name): Likewise.
(rs6000_set_up_by_prologue): Likewise.
(rs6000_can_eliminate): Likewise, reformat spaces to tabs.
* output.h (get_pool_size): Rename to...
(get_pool_size_upper_bound): ...This.
* varasm.c (get_pool_size): Rename to...
(get_pool_size_upper_bound): ...This.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/output.h
trunk/gcc/varasm.c

[Bug tree-optimization/78646] incorrect result type for pointer addition in slsr

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
A reference type is treated as a pointer type all the way through the middle
end of gcc. Why is there an issue with that for your target?

[Bug c++/78648] [5/6/7 Regression] ICE on invalid C++ code on x86_64-linux-gnu (Segmentation fault, contains_struct_check)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug c++/78648] [5/6/7 Regression] ICE on invalid C++ code on x86_64-linux-gnu (Segmentation fault, contains_struct_check)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-12-02
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
   Target Milestone|--- |5.5
Summary|ICE on invalid C++ code on  |[5/6/7 Regression] ICE on
   |x86_64-linux-gnu|invalid C++ code on
   |(Segmentation fault,|x86_64-linux-gnu
   |contains_struct_check)  |(Segmentation fault,
   ||contains_struct_check)
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Also started to ICE with either r175765 or r175764, r175761 doesn't ICE.

[Bug c++/78635] [6/7 Regression] internal compiler error: in output_constructor_regular_field, at varasm.c:4989

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug c++/78649] [5/6/7 Regression] ICE on invalid C++ code on x86_64-linux-gnu (internal compiler error: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in build_value_init_noctor,

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.