[Bug c++/78104] optimizer doesn't grok C++ new/delete yet

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Markus Trippelsdorf from comment #0)
> A simple example:
> 
> int main() {
>   int *ob = new int();
>   delete ob;
> }
> 
> clang optimizes it away:

Which is funny considering what Chris Lattner  wrote in PR 23383 comment #4:
This would not be legal, there is no reason operator new can't return a pointer
that already exists in the program.

[Bug c++/78104] optimizer doesn't grok C++ new/delete yet

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
PR 23383 for one.

[Bug c++/78104] optimizer doesn't grok C++ new/delete yet

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
There might be a few duplicates of this bug already.

[Bug c++/78104] New: optimizer doesn't grok C++ new/delete yet

[trippels at gcc dot gnu.org]

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

Bug ID: 78104
   Summary: optimizer doesn't grok C++ new/delete yet
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
  Target Milestone: ---

A simple example:

int main() {
  int *ob = new int();
  delete ob;
}

clang optimizes it away:

main:  # @main
xorl%eax, %eax
retq

gcc doesn't:

main:
subq$8, %rsp
movl$4, %edi
calloperator new(unsigned long)
movl$4, %esi
movl$0, (%rax)
movq%rax, %rdi
calloperator delete(void*, unsigned long)
xorl%eax, %eax
addq$8, %rsp
ret

[Bug target/78094] limit in mask targets

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Component|bootstrap   |target
 Resolution|--- |INVALID

--- Comment #1 from Andrew Pinski  ---
Why use MASK, why can't you use a variable here instead?

>i have found limitation in gcc/opth-gen.awk

It is not a limitation just in the awk script.  In fact there is a check there
because the target mask is a 32bit variable.

[Bug tree-optimization/77550] [6/7 Regression] std::deque with -O3 has infinite std::distance

[edlinger at gcc dot gnu.org]

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

Bernd Edlinger  changed:

   What|Removed |Added

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

--- Comment #19 from Bernd Edlinger  ---
fixed

[Bug target/78102] [5/6/7 regression] GCC refuses to generate PCMPEQQ instruction for SSE4.1

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-25
 Ever confirmed|0   |1

--- Comment #1 from Marc Glisse  ---
vector lowering pass... (possibly checking for vec_cmpv2div2di)

[Bug tree-optimization/78103] Failure to optimize with __builtin_clzl

[ben.maurer at gmail dot com]

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

--- Comment #1 from Ben Maurer  ---
Also along the same lines:

https://godbolt.org/g/Nzed5m

GCC figures out BSRNew, but there's a cdqe instruction that's unnecessary

[Bug tree-optimization/78103] New: Failure to optimize with __builtin_clzl

[ben.maurer at gmail dot com]

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

Bug ID: 78103
   Summary: Failure to optimize with __builtin_clzl
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ben.maurer at gmail dot com
  Target Milestone: ---

constexpr
unsigned long findLastSet(unsigned long x) {
  return x ? 8 * sizeof(unsigned long) - __builtin_clzl(x) : 0;
}
constexpr
unsigned long findLastSet2(unsigned long x) {
  return x ? ((8 * sizeof(unsigned long) - 1) ^ __builtin_clzl(x)) + 1 : 0;
}

These two functions are the same, but GCC does a better job at compiling the
second vs the more idiomatic first

https://godbolt.org/g/B2x5iG

findLastSet(unsigned long):
xor eax, eax
testrdi, rdi
je  .L1
bsr rdi, rdi
mov eax, 64
xor rdi, 63
movsx   rdi, edi
sub rax, rdi
.L1:
rep ret
findLastSet2(unsigned long):
xor eax, eax
testrdi, rdi
je  .L6
bsr rdi, rdi
movsx   rax, edi
add rax, 1

[Bug target/78095] [7 Regression] valgrind build error on ppc64le

[wschmidt at gcc dot gnu.org]

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

--- Comment #9 from Bill Schmidt  ---
Done.  https://gcc.gnu.org/ml/gcc-patches/2016-10/msg01983.html

[Bug target/78102] New: [5/6/7 regression] GCC refuses to generate PCMPEQQ instruction for SSE4.1

[vegorov13 at mail dot ru]

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

Bug ID: 78102
   Summary: [5/6/7 regression] GCC refuses to generate PCMPEQQ
instruction for SSE4.1
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vegorov13 at mail dot ru
  Target Milestone: ---

Test case: https://godbolt.org/g/kmycx1

#include 

__m128i pcmpeqq(const __m128i x, const __m128i y) {
  return _mm_cmpeq_epi64(x, y);
}

Compiled with -msse4.1. Expected result: PCMPEQQ instruction emitted. However I
get non-vectorised code:

movaps  XMMWORD PTR [rbp-32], xmm0
mov rdx, QWORD PTR [rbp-16]
mov rax, QWORD PTR [rbp-32]
cmp rdx, rax
setne   al
movzx   eax, al
sub rax, 1
mov QWORD PTR [rbp-72], rax
movqxmm0, QWORD PTR [rbp-72]
mov rdx, QWORD PTR [rbp-8]
mov rax, QWORD PTR [rbp-24]
cmp rdx, rax
setne   al
movzx   eax, al
sub rax, 1
mov QWORD PTR [rbp-72], rax
pinsrq  xmm0, QWORD PTR [rbp-72], 1

If I use -msse4.2 instead, everything works fine. PCMPEQQ is a SSE4.1
instruction though.

[Bug fortran/78092] [5/6/7 Regression] ICE when calling SIZEOF on CLASS(*) entry

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #3 from kargl at gcc dot gnu.org ---
I have a patch for this, but don't do CLASS so need someone to actually look at
it.  See gfortran mailing list.

[Bug target/78101] New: PowerPC 64-bit little endian does not build spec-2017 kit102 527.cam4_r or 627.cam4_s with -O3 -mcpu=power9

[meissner at gcc dot gnu.org]

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

Bug ID: 78101
   Summary: PowerPC 64-bit little endian does not build spec-2017
kit102 527.cam4_r or 627.cam4_s with -O3 -mcpu=power9
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org
  Target Milestone: ---

If you compile kit 102 of the Spec 2017 benchmark suite for a base run using
the options: "-O3 -mcpu=power9", it fails in both the 527.cam4_r and 627.cam4_s
benchmarks with an insn not found error.  If you use the -mno-power9-fusion
switch, it will compile fine.

cldwat2m_macro.fppized.f90:1101:0:

end subroutine mmacro_pcond

Error: insn does not satisfy its constraints:
(insn 34030 2826 2832 309 (parallel [
(set (mem:DF (plus:DI (plus:DI (reg:DI 3 3 [4385])
(const_int 65536 [0x1]))
(const_int -5632 [0xea00])) [2 qmin1 S8
A64])
(unspec:DF [
(reg:DF 5 5 [orig:1781 _4839 ] [1781])
] UNSPEC_FUSION_P9))
(clobber (reg:DI 3 3 [4387]))
]) "cldwat2m_macro.fppized.f90":608 797 {fusion_gpr_di_df_store}
 (nil))
cldwat2m_macro.fppized.f90:1101:0: internal compiler error: in
extract_constrain_insn, at recog.c:2213
0x108a0f53 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/meissner/fsf-src/trunk/gcc/rtl-error.c:108
0x108a0fb7 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/meissner/fsf-src/trunk/gcc/rtl-error.c:119
0x10867717 extract_constrain_insn(rtx_insn*)
/home/meissner/fsf-src/trunk/gcc/recog.c:2213
0x1086c96f copyprop_hardreg_forward_1
/home/meissner/fsf-src/trunk/gcc/regcprop.c:794
0x1086da97 execute
/home/meissner/fsf-src/trunk/gcc/regcprop.c:1301
Please submit a full bug report,
with preprocessed source if appropriate.

I'm not sure I can add an attachment for the bug, since spec 2017 is not
released at this point.

[Bug fortran/78021] [5/6/7 Regression] Wrong result with optimization on character constant

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #7 from Thomas Koenig  ---
Fixed on all affected branches, closing.

Thanks for the bug report!

[Bug fortran/78021] [5/6/7 Regression] Wrong result with optimization on character constant

[tkoenig at gcc dot gnu.org]

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

--- Comment #6 from Thomas Koenig  ---
Author: tkoenig
Date: Mon Oct 24 22:12:06 2016
New Revision: 241498

URL: https://gcc.gnu.org/viewcvs?rev=241498=gcc=rev
Log:
2016-10-24  Thomas Koenig  

Backport from trunk
PR fortran/78021
* gfc_compare_functions:  Strings with different lengths in
argument lists compare unequal.

2016-10-24  Thomas Koenig  

Backport from trunk
PR fortran/78021
* gfortran.dg/string_length_3.f90:  New test.


Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/string_length_3.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/dependency.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug c++/64431] "-Wignored-qualifiers" warning gives misleading position in code

[psmith at gnu dot org]

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

Paul Smith  changed:

   What|Removed |Added

 CC||psmith at gnu dot org

--- Comment #6 from Paul Smith  ---
Still see this in GCC 6.2.0.  It was even more confusing for me because in my
case the const in the return type was hidden in a typedef:

  class Foo
  {
  typedef const char* const MyType;
...

  MyType myFunction() const { ... }
  };

Shows this error:

  Foo.h:202:26: error: type qualifiers ignored on function return type
   MyType myFunction() const
   ^

I was _really_ confused :).

I'm not even sure this should trigger this error... I mean, it's inside a type.
 In my case I can take it out without a big problem but what if I wanted to
have the const in the type?  Then I can't return that type anymore without a
warning?  Maybe that's a separate bug.

[Bug fortran/71895] ICE in gfc_compare_derived_types, at fortran/interface.c:520

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from kargl at gcc dot gnu.org ---
Fixed on 5, 6, and 7.

[Bug libfortran/77828] [7 Regression] Linking gfortran-7 compiled program with libgfortran of 5.x allowed but crashes when containing write to string

[jvdelisle at gcc dot gnu.org]

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

--- Comment #6 from Jerry DeLisle  ---
Author: jvdelisle
Date: Mon Oct 24 21:42:29 2016
New Revision: 241497

URL: https://gcc.gnu.org/viewcvs?rev=241497=gcc=rev
Log:
2016-10-24  Jerry DeLisle  

PR fortran/77828
* io/io.h (st_parameter_dt): Reorder for readability and sanity.
* io/transfer.c (data_transfer_init): Remove TODO and enable the
runtime error message, rec= specifier not allowed in STREAM
access.
* libtool-version: Bump major version of libgfortran to 4.

* ioparm.def: Reorder dt parameters to match libgfortran.
* libgfortran.h: Swap definitions of GFC_INTERNAL_UNIT and
GFC_INTERNAL_UNIT4.

Added:
trunk/gcc/testsuite/gfortran.dg/streamio_17.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/ioparm.def
trunk/gcc/fortran/libgfortran.h
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/io.h
trunk/libgfortran/io/transfer.c
trunk/libgfortran/libtool-version

[Bug fortran/71895] ICE in gfc_compare_derived_types, at fortran/interface.c:520

[kargl at gcc dot gnu.org]

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

--- Comment #4 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Mon Oct 24 21:36:49 2016
New Revision: 241496

URL: https://gcc.gnu.org/viewcvs?rev=241496=gcc=rev
Log:
2016-10-24  Steven G. Kargl  

PR fortran/71895
* interface.c (gfc_compare_derived_types):  Convert gcc_assert()
to a gfc_internal_error() to prevent an ICE.

2016-10-24  Steven G. Kargl  

PR fortran/71895
* gfortran.dg/pr71895.f90: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr71895.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/interface.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug debug/78100] DWARF symbols for an array sometimes missing the array length

[gccbugs at dima dot secretsauce.net]

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

--- Comment #2 from Dima Kogan  ---
For easier reading, the test program looks like this:

 #include 

 extern int s[];
 int s[] = { 1,2,3 };

 int main(void)
 {
 printf("%zd\n", sizeof(s));
 return 0;
 }

[Bug target/71767] Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler

[howarth.at.gcc at gmail dot com]

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

--- Comment #43 from Jack Howarth  ---
(In reply to Eric Gallager from comment #33)
> I'm not sure if this is due to the patches from this bug report, or if it's
> due to some other change made to GCC recently, but my fork of Emacs now
> fails to build with LTO due to a bunch of undefined local symbols:
> 

This issue appears to be PR57438 because passing
-D__builtin_unreachable=__builtin_trap to the build on OS X 10.11 allows emac
25.1 to build against the Xcode 8.1 GM linker using stock gcc 6.2.0 compiler
with...

  $ ../configure --enable-link-time-optimization --without-ns
CC=/sw/bin/gcc-fsf-6 CXX=/sw/bin/g++-fsf-6
CPPFLAGS="-D__builtin_unreachable=__builtin_trap -I/sw/include"
LDFLAGS="-L/sw/lib"

[Bug target/78077] gcc 6.2.0 fails to link temacs from emacs-25.1 using the Xcode 8 linker

[howarth.at.gcc at gmail dot com]

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

--- Comment #6 from Jack Howarth  ---
(In reply to Iain Sandoe from comment #5)
> (In reply to Jack Howarth from comment #4)
> > The Apple developers think this is gcc bug producing malformatted input to
> > the linker. From macho_relocatable_file.cpp, we are triggering the linker
> > check...
> > 
> > #ifndef NDEBUG
> > // scan for FDEs claming the same function
> > for(uint32_t i=1; i < cfiStartsArrayCount; ++i) {
> > assert( cfiStartsArray[i] != cfiStartsArray[i-1] );
> > }
> > #endif
> 
> If it's a 0-length FDE caused by a 0-length function, then this is a repeat
> of 57438.  If so please mark it accordingly  (I expect to post a fix for
> 57438 soon, and I can send you a preview if that helps).
> 
> If this is something different, then please can we have a reduced test-case.
> Thanks

A reduced test case is unlikely but I can confirm that this appears to be due
to PR57438 since passing -D__builtin_unreachable=__builtin_trap by using...

../configure --enable-link-time-optimization --without-ns CC=/sw/bin/gcc-fsf-6
CXX=/sw/bin/g++-fsf-6 CPPFLAGS="-D__builtin_unreachable=__builtin_trap
-I/sw/include" LDFLAGS="-L/sw/lib"

produces a successful build at -O2 with LTO under stock gcc 6.2.0 and Xcode 8.1
GM's linker.

[Bug target/78095] [7 Regression] valgrind build error on ppc64le

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #8 from Markus Trippelsdorf  ---
(In reply to Bill Schmidt from comment #7)
> Anyone object if we add a note to gcc-7/change.html and close this as
> NOTABUG?

Fine with me.

[Bug target/78095] [7 Regression] valgrind build error on ppc64le

[wschmidt at gcc dot gnu.org]

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

--- Comment #7 from Bill Schmidt  ---
(In reply to Markus Trippelsdorf from comment #6)
> At least it needs a big fat explanation in
> https://gcc.gnu.org/gcc-7/changes.html

I tend to think this is the right action.  It has never been a good idea to
clobber r2 with an inline asm, but it was previously undiagnosed.  The clobbers
in valgrind are wrong (and our valgrind guy is now aware this needs to be
fixed).

We can expect a round of similar bug reports for misguided asm, but these are
all user errors that will be worth exposing.

Anyone object if we add a note to gcc-7/change.html and close this as NOTABUG?

[Bug tree-optimization/77550] [6/7 Regression] std::deque with -O3 has infinite std::distance

[edlinger at gcc dot gnu.org]

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

--- Comment #18 from Bernd Edlinger  ---
Author: edlinger
Date: Mon Oct 24 20:21:06 2016
New Revision: 241495

URL: https://gcc.gnu.org/viewcvs?rev=241495=gcc=rev
Log:
2016-10-24  Bernd Edlinger  

Backport from mainline
2016-09-21  Bernd Edlinger  

PR tree-optimization/77550
* tree-vect-stmts.c (create_array_ref): Change parameters.
(get_group_alias_ptr_type): New function.
(vectorizable_store, vectorizable_load): Use get_group_alias_ptr_type.

testsuite:
2016-09-21  Bernd Edlinger  

PR tree-optimization/77550
* g++.dg/pr77550.C: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/pr77550.C
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/tree-vect-stmts.c

[Bug target/78095] [7 Regression] valgrind build error on ppc64le

[trippels at gcc dot gnu.org]

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

--- Comment #6 from Markus Trippelsdorf  ---
At least it needs a big fat explanation in
https://gcc.gnu.org/gcc-7/changes.html

[Bug fortran/71895] ICE in gfc_compare_derived_types, at fortran/interface.c:520

[kargl at gcc dot gnu.org]

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

--- Comment #3 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Mon Oct 24 20:03:08 2016
New Revision: 241494

URL: https://gcc.gnu.org/viewcvs?rev=241494=gcc=rev
Log:
2016-10-24  Steven G. Kargl  

PR fortran/71895
* interface.c (gfc_compare_derived_types):  Convert gcc_assert()
to a gfc_internal_error() to prevent an ICE.

2016-10-24  Steven G. Kargl  

PR fortran/71895
* gfortran.dg/pr71895.f90: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/pr71895.f90
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/interface.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug fortran/69298] Array finalisers seem to be given the wrong array when the array is a member variable.

[pault at gcc dot gnu.org]

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

--- Comment #5 from Paul Thomas  ---
(In reply to Dominique d'Humieres from comment #3)
> > Created attachment 37448 [details]
> > Self-contained variant
> 
> With n=3, the output of the attached test is
> 
> Initialising stuff_type 4
> Finalising stuff_type 0
> ...
> ---
> Initialising test_type
> Initialising stuff_type 4
> Finalising stuff_type 0
> Copy initialiser 4 4
> Initialising stuff_type 1
> Finalising stuff_type 0
> Copy initialiser 1 1
> Initialising stuff_type 2
> Finalising stuff_type 0
> Copy initialiser 2 2
> Initialising stuff_type 3
> Finalising stuff_type 0
> Copy initialiser 3 3
> Finalising stuff_type 4
> Copy initialiser 4 4
> thing 10
> Finalising stuff_type 4
> 
> Program received signal SIGSEGV: Segmentation fault - invalid memory
> reference.
> 
> Changing 'n' to 2 or 4, gives respectively
> 
> ...
> ---
> Initialising test_type
> Initialising stuff_type 4
> Finalising stuff_type 1342972320
> Copy initialiser 4 4
> Initialising stuff_type 1
> Finalising stuff_type 32767
> Copy initialiser 1 1
> Initialising stuff_type 2
> Finalising stuff_type 263453344
> Copy initialiser 2 2
> Finalising stuff_type 4
> Copy initialiser 4 4
> thing 7
> Finalising stuff_type 4
> 
> Program received signal SIGSEGV: Segmentation fault - invalid memory
> reference.
> 
> and
> 
> ...
> Initialising test_type
> Initialising stuff_type 4
> Finalising stuff_type 107478528
> Copy initialiser 4 4
> Initialising stuff_type 1
> Finalising stuff_type 1
> Copy initialiser 1 1
> Initialising stuff_type 2
> Finalising stuff_type 5120
> Copy initialiser 2 2
> Initialising stuff_type 3
> Finalising stuff_type 0
> Copy initialiser 3 3
> Initialising stuff_type 4
> Finalising stuff_type 1501114256
> Copy initialiser 4 4
> Finalising stuff_type 4
> Copy initialiser 4 4
> thing 14
> Finalising stuff_type 4
> 
> where the nonzero values changed between different runs.

For the record, since I have spent an hour or two investigating this tonight:

__final_test_mod_Test_type has, towards the end


{
  struct array0_stuff_type desc.32;

  desc.32.dtype = 296;
  desc.32.data = (void * restrict) >thing;
  __final_stuff_mod_Stuff_type ();
}
{
  struct array1_stuff_type parm.33;

  parm.33.dtype = 297;
  parm.33.dim[0].lbound = 1;
  parm.33.dim[0].ubound = 3;
  parm.33.dim[0].stride = 1;
  parm.33.data = (void *) >things[0];
  parm.33.offset = -1;
  __final_stuff_mod_Stuff_type ();
}

whereas the prototype for the 'stuff' finalization is

__final_stuff_mod_Stuff_type (struct array7_stuff_type & restrict array,
integer(kind=8) byte_stride, logical(kind=1) fini_coarray)


That is to say that two actual arguments are missing.

Since this contains
  if (byte_stride == 4)
{
  {
static integer(kind=8) C.3513 = 4;

stuff_1d_finaliser ((struct array7_stuff_type *) array,
);
  }
}

It seems difficult to understand how stuff_1d_finaliser is getting called at
all!

I'll come back to this when I can.

Paul

[Bug target/78095] [7 Regression] valgrind build error on ppc64le

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|RESOLVED|NEW
 Resolution|INVALID |---

--- Comment #5 from Markus Trippelsdorf  ---
Well, other places are also affected:

coregrind/m_debuglog.c

 198 static UInt local_sys_write_stderr ( const HChar* buf, Int n ) 
 199 {  
 200volatile Long block[2]; 
 201block[0] = (Long)buf;   
 202block[1] = (Long)n; 
 203__asm__ volatile (  
 204   "addi 1,1,-256\n\t"  
 205   "mr   5,%0\n\t" /* r5 = [0] */ 
 206   "std  5,0(1)\n\t"   /* stash on stack */ 
 207   "li   0,"VG_STRINGIFY(__NR_write)"\n\t" /* %r0 = __NR_write */   
 208   "li   3,2\n\t"  /* set %r3 = stderr */   
 209   "ld   4,0(5)\n\t"   /* set %r4 = buf */  
 210   "ld   5,8(5)\n\t"   /* set %r5 = n */
 211   "sc\n\t"/* write(stderr, buf, n) */  
 212   "ld   5,0(1)\n\t"
 213   "addi 1,1,256\n\t"   
 214   "std  3,0(5)\n" /* block[0] = result */  
 215   :
 216   : "b" (block)
 217   : "cc","memory","cr0","ctr", 
 218 "r0","r2","r3","r4","r5","r6","r7","r8","r9","r10","r11","r12" 
 219);  
 220if (block[0] < 0)   
 221   block[0] = -1;   
 222return (UInt)(Int)block[0]; 
 223 }  
 224
 225 static UInt local_sys_getpid ( void )  
 226 {  
 227register ULong __res __asm__ ("r3");
 228__asm__ volatile (  
 229   "li 0, %1\n\t"   
 230   "sc" 
 231   : "=" (__res)  
 232   : "i" (__NR_getpid)  
 233   : "cc","memory","cr0","ctr", 
 234 "r0","r2","r4","r5","r6","r7","r8","r9","r10","r11","r12"  
 235);  
 236return (UInt)__res; 
 237 }

[Bug debug/78100] DWARF symbols for an array sometimes missing the array length

[gccbugs at dima dot secretsauce.net]

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

--- Comment #1 from Dima Kogan  ---
Created attachment 39876
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39876=edit
test case

[Bug debug/78100] New: DWARF symbols for an array sometimes missing the array length

[gccbugs at dima dot secretsauce.net]

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

Bug ID: 78100
   Summary: DWARF symbols for an array sometimes missing the array
length
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gccbugs at dima dot secretsauce.net
  Target Milestone: ---

Hi.

I'm using gcc 6.2 from Debian on an amd64 machine:

dima@fatty:/tmp$ gcc --version

gcc (Debian 6.2.0-9) 6.2.0 20161019
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Let's say I have the attached tiny C program: tst.c. I build and run it:

dima@fatty:/tmp$ gcc -g -o tst tst.c

dima@fatty:/tmp$ ./tst
12

This is correct output: s has 3 32-bit integers in it for a total of 12 bytes.
Let me load this program in gdb, and see what gdb thinks sizeof(s) is:

dima@fatty:/tmp$ gdb tst

...
Reading symbols from tst...done.
(gdb) p sizeof(s)
$1 = 0

This is wrong. As stated before, the correct answer is 12, not 0. The problem
is
that the DWARF data generated by gcc is incorrect:

dima@fatty:/tmp$ readelf -wi tst

Contents of the .debug_info section:

...
 <1><62>: Abbrev Number: 4 (DW_TAG_base_type)
<63>   DW_AT_byte_size   : 4
<64>   DW_AT_encoding: 5(signed)
<65>   DW_AT_name: int

 <1><303>: Abbrev Number: 12 (DW_TAG_array_type)
<304>   DW_AT_type: <0x62>
<308>   DW_AT_sibling : <0x30e>
 <2><30c>: Abbrev Number: 17 (DW_TAG_subrange_type)
 <2><30d>: Abbrev Number: 0

 <1><30e>: Abbrev Number: 18 (DW_TAG_variable)
<30f>   DW_AT_name: s
<311>   DW_AT_decl_file   : 1
<312>   DW_AT_decl_line   : 3
<313>   DW_AT_type: <0x303>
<317>   DW_AT_external: 1
<317>   DW_AT_declaration : 1

 <1><317>: Abbrev Number: 19 (DW_TAG_variable)
<318>   DW_AT_specification: <0x30e>
<31c>   DW_AT_decl_line   : 4
<31d>   DW_AT_location: 9 byte block: 3 10 10 20 0 0 0 0 0 
(DW_OP_addr: 201010)

Here the 'extern' declaration appears in DIE 0x30e with the type in DIE 0x303.
This type die is an array of an unknown number of elements, which isn't wrong.

The instantiation is in DIE 0x317. This isn't extern, so we actually have a
location for this object. But instead of declaring the full type, we simply
reference the already-seen DIE 0x30e; this DIE doesn't know how many elements
we
have, so this information doesn't appear in the DWARF data at all. Thus gdb
doesn't know we have 3 integers.

Removing the 'extern' declaration makes it work. Clang works as well.

For completeness, the code that reads this DWARF lives in array_size() in
elfutils/libdw/dwarf_aggregate_size.c. Given a DW_TAG_subrange_type it expects
either an DW_AT_count attribute or a DW_AT_upper_bound attribute, neither of
which we have here.

Thanks

[Bug middle-end/78098] error: interrupt service routine can't be called directly

[hjl.tools at gmail dot com]

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

--- Comment #5 from H.J. Lu  ---
(In reply to Martin Liška from comment #4)
> Hello H.J.
> As interrupt handler attribute is very specific and rare attribute, I'm
> suggesting to basically skip all functions in IPA ICF analysis that have
> such attribute.
> 
> Does it work for you?

I'd like to keep it as a "feature" to detect code duplication in
interrupt handler, like

[hjl@gnu-6 pr78098]$ /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -Os -m32 -mno-sse -mno-mmx
-mno-80387 -S -o foo1.s foo1.i
foo1.i: In function ‘foo1’:
foo1.i:10:33: error: interrupt service routine ‘foo2’ can't be called directly
 __attribute__((interrupt)) void foo2 (void *p)
 ^~~~
foo1.i:10:33: note: is interrupt service routine ‘foo1’ identical to ‘foo2’?
[hjl@gnu-6 pr78098]$

[Bug tree-optimization/18487] Warnings for pure and const functions that are not actually pure or const

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed|2004-11-14 21:57:50 |2016-10-24
 Ever confirmed|0   |1

--- Comment #13 from Martin Sebor  ---
Let me confirm this request.  I think diagnosing even just the simple cases
would be worthwhile.  The -Wsuggest-atribute= option isn't perfect either but
it is presumably useful nonetheless, as are many other warnings that are
similarly limited and prone to both false negatives and false positives.

[Bug target/78095] [7 Regression] valgrind build error on ppc64le

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #4 from Andrew Pinski  ---
The inline-asm already restores it:
3301  "ld 2,-16(12)\n\t" /* restore tocptr */  \

So there is no reason to mark r2 as being clobbered.

[Bug fortran/71895] ICE in gfc_compare_derived_types, at fortran/interface.c:520

[kargl at gcc dot gnu.org]

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

--- Comment #2 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Mon Oct 24 19:21:42 2016
New Revision: 241493

URL: https://gcc.gnu.org/viewcvs?rev=241493=gcc=rev
Log:
2016-10-24  Steven G. Kargl  

PR fortran/71895
* interface.c (gfc_compare_derived_types):  Convert gcc_assert()
to a gfc_internal_error() to prevent an ICE.

2016-10-24  Steven G. Kargl  

PR fortran/71895
* gfortran.dg/pr71895.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr71895.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/interface.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/69298] Array finalisers seem to be given the wrong array when the array is a member variable.

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #4 from Paul Thomas  ---
(In reply to Dominique d'Humieres from comment #3)
> > Created attachment 37448 [details]
> > Self-contained variant
> 
> With n=3, the output of the attached test is
> 
> Initialising stuff_type 4
> Finalising stuff_type 0
> ...
> ---
> Initialising test_type
> Initialising stuff_type 4
> Finalising stuff_type 0
> Copy initialiser 4 4
> Initialising stuff_type 1
> Finalising stuff_type 0
> Copy initialiser 1 1
> Initialising stuff_type 2
> Finalising stuff_type 0
> Copy initialiser 2 2
> Initialising stuff_type 3
> Finalising stuff_type 0
> Copy initialiser 3 3
> Finalising stuff_type 4
> Copy initialiser 4 4
> thing 10
> Finalising stuff_type 4
> 
> Program received signal SIGSEGV: Segmentation fault - invalid memory
> reference.
> 
> Changing 'n' to 2 or 4, gives respectively
> 
> ...
> ---
> Initialising test_type
> Initialising stuff_type 4
> Finalising stuff_type 1342972320
> Copy initialiser 4 4
> Initialising stuff_type 1
> Finalising stuff_type 32767
> Copy initialiser 1 1
> Initialising stuff_type 2
> Finalising stuff_type 263453344
> Copy initialiser 2 2
> Finalising stuff_type 4
> Copy initialiser 4 4
> thing 7
> Finalising stuff_type 4
> 
> Program received signal SIGSEGV: Segmentation fault - invalid memory
> reference.
> 
> and
> 
> ...
> Initialising test_type
> Initialising stuff_type 4
> Finalising stuff_type 107478528
> Copy initialiser 4 4
> Initialising stuff_type 1
> Finalising stuff_type 1
> Copy initialiser 1 1
> Initialising stuff_type 2
> Finalising stuff_type 5120
> Copy initialiser 2 2
> Initialising stuff_type 3
> Finalising stuff_type 0
> Copy initialiser 3 3
> Initialising stuff_type 4
> Finalising stuff_type 1501114256
> Copy initialiser 4 4
> Finalising stuff_type 4
> Copy initialiser 4 4
> thing 14
> Finalising stuff_type 4
> 
> where the nonzero values changed between different runs.

For the record, since I have spent an hour or two investigating this tonight:

__final_test_mod_Test_type has, towards the end


{
  struct array0_stuff_type desc.32;

  desc.32.dtype = 296;
  desc.32.data = (void * restrict) >thing;
  __final_stuff_mod_Stuff_type ();
}
{
  struct array1_stuff_type parm.33;

  parm.33.dtype = 297;
  parm.33.dim[0].lbound = 1;
  parm.33.dim[0].ubound = 3;
  parm.33.dim[0].stride = 1;
  parm.33.data = (void *) >things[0];
  parm.33.offset = -1;
  __final_stuff_mod_Stuff_type ();
}

whereas the prototype for the 'stuff' finalization is

__final_stuff_mod_Stuff_type (struct array7_stuff_type & restrict array,
integer(kind=8) byte_stride, logical(kind=1) fini_coarray)


That is to say that two actual arguments are missing.

Since this contains
  if (byte_stride == 4)
{
  {
static integer(kind=8) C.3513 = 4;

stuff_1d_finaliser ((struct array7_stuff_type *) array,
);
  }
}

It seems difficult to understand how stuff_1d_finaliser is getting called at
all!

I'll come back to this when I can.

Paul

[Bug middle-end/78099] New: Typo in sem_function::get_hash

[hjl.tools at gmail dot com]

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

Bug ID: 78099
   Summary: Typo in sem_function::get_hash
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

sem_function::get_hash has

  /* Add common features of declaration itself.  */
  if (DECL_FUNCTION_SPECIFIC_TARGET (decl))
hstate.add_wide_int
 (cl_target_option_hash
   (TREE_TARGET_OPTION (DECL_FUNCTION_SPECIFIC_TARGET (decl;
  if (DECL_FUNCTION_SPECIFIC_OPTIMIZATION (decl))
 (cl_optimization_hash
   (TREE_OPTIMIZATION (DECL_FUNCTION_SPECIFIC_OPTIMIZATION (decl;

Shouldn't it be

  if (DECL_FUNCTION_SPECIFIC_OPTIMIZATION (decl))
hstate.add_wide_int
 ^ This is missing.
 (cl_optimization_hash
   (TREE_OPTIMIZATION (DECL_FUNCTION_SPECIFIC_OPTIMIZATION (decl;

[Bug target/78095] [7 Regression] valgrind build error on ppc64le

[trippels at gcc dot gnu.org]

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

--- Comment #3 from Markus Trippelsdorf  ---
include/valgrind.h: 

3263 /* These regs are trashed by the hidden call. */   
3264 #define __CALLER_SAVED_REGS   \
3265"lr", "ctr", "xer",\
3266"cr0", "cr1", "cr2", "cr3", "cr4", "cr5", "cr6", "cr7",\
3267"r0", "r2", "r3", "r4", "r5", "r6", "r7", "r8", "r9", "r10",   \
3268"r11", "r12", "r13" 
3269
3270 /* Macros to save and align the stack before making a function 
3271call and restore it afterwards as gcc may not keep the stack
3272pointer aligned if it doesn't realise calls are being made  
3273to other functions. */  
3274
3275 #define VALGRIND_ALIGN_STACK   \   
3276   "mr 28,1\n\t"\   
3277   "rldicr 1,1,0,59\n\t"
3278 #define VALGRIND_RESTORE_STACK \   
3279   "mr 1,28\n\t"
3280
3281 /* These CALL_FN_ macros assume that on ppc64-linux, sizeof(unsigned   
3282long) == 8. */  
3283
3284 #define CALL_FN_W_v(lval, orig)   \
3285do {   \
3286   volatile OrigFn_orig = (orig);  \
3287   volatile unsigned long _argvec[3+0];\
3288   volatile unsigned long _res;\
3289   /* _argvec[0] holds current r2 across the call */   \
3290   _argvec[1] = (unsigned long)_orig.r2;   \
3291   _argvec[2] = (unsigned long)_orig.nraddr;   \
3292   __asm__ volatile(   \
3293  VALGRIND_ALIGN_STACK \
3294  "mr 12,%1\n\t"   \
3295  "std 2,-16(12)\n\t"  /* save tocptr */   \
3296  "ld   2,-8(12)\n\t"  /* use nraddr's tocptr */   \
3297  "ld  12, 0(12)\n\t"  /* target->r12 */   \
3298  VALGRIND_BRANCH_AND_LINK_TO_NOREDIR_R12  \
3299  "mr 12,%1\n\t"   \
3300  "mr %0,3\n\t"\
3301  "ld 2,-16(12)\n\t" /* restore tocptr */  \
3302  VALGRIND_RESTORE_STACK   \
3303  : /*out*/   "=r" (_res)  \
3304  : /*in*/"r" (&_argvec[2])\
3305  : /*trash*/ "cc", "memory", __CALLER_SAVED_REGS, "r28"   \
3306   );  \
3307   lval = (__typeof__(lval)) _res; \
3308} while (0)

[Bug fortran/71796] Link error referencing compiler generated symbol __vtab_xxx

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |dominiq at lps dot 
ens.fr

--- Comment #2 from Dominique d'Humieres  ---
The link error has been fixed by r241450. I'll commit the test to the gfortran
test suite soon.

Note that it would be nice to have a test giving a working executable with an
expected result at run time: the executable for the test segfaults at run time.

[Bug target/78095] [7 Regression] valgrind build error on ppc64le

[segher at gcc dot gnu.org]

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

--- Comment #2 from Segher Boessenkool  ---
So why does valgrind try to clobber r2?  That just isn't going to work...

[Bug target/78077] gcc 6.2.0 fails to link temacs from emacs-25.1 using the Xcode 8 linker

[iains at gcc dot gnu.org]

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

--- Comment #5 from Iain Sandoe  ---
(In reply to Jack Howarth from comment #4)
> The Apple developers think this is gcc bug producing malformatted input to
> the linker. From macho_relocatable_file.cpp, we are triggering the linker
> check...
> 
> #ifndef NDEBUG
> // scan for FDEs claming the same function
> for(uint32_t i=1; i < cfiStartsArrayCount; ++i) {
> assert( cfiStartsArray[i] != cfiStartsArray[i-1] );
> }
> #endif

If it's a 0-length FDE caused by a 0-length function, then this is a repeat of
57438.  If so please mark it accordingly  (I expect to post a fix for 57438
soon, and I can send you a preview if that helps).

If this is something different, then please can we have a reduced test-case. 
Thanks

[Bug middle-end/78098] error: interrupt service routine can't be called directly

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-24
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

--- Comment #4 from Martin Liška  ---
Hello H.J.
As interrupt handler attribute is very specific and rare attribute, I'm
suggesting to basically skip all functions in IPA ICF analysis that have such
attribute.

Does it work for you?

[Bug libgcc/78064] unwind-c.c never uses _Unwind_GetIPInfo

[fw at gcc dot gnu.org]

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

Florian Weimer  changed:

   What|Removed |Added

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

--- Comment #4 from Florian Weimer  ---
Fixed in 7.0.

[Bug libgcc/78064] unwind-c.c never uses _Unwind_GetIPInfo

[fw at gcc dot gnu.org]

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

--- Comment #3 from Florian Weimer  ---
Author: fw
Date: Mon Oct 24 18:25:09 2016
New Revision: 241491

URL: https://gcc.gnu.org/viewcvs?rev=241491=gcc=rev
Log:
PR libgcc/78064: Add missing include directive to unwind-c.c

PR libgcc/78064
* unwind-c.c: Include auto-target.h.


Modified:
trunk/libgcc/ChangeLog
trunk/libgcc/unwind-c.c

[Bug middle-end/78098] error: interrupt service routine can't be called directly

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu  ---
Another problem:

[hjl@gnu-6 pr78098]$ cat foo2.i 
void bar (int);

void foo1 (void *p)
{
  bar (0);
  *((int *)0xFEE00080) = 0;
}

__attribute__((interrupt)) void foo2 (void *p)
{
  bar (0);
  *((int *)0xFEE00080) = 0;
}
[hjl@gnu-6 pr78098]$ make foo2.s
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -Os -DQM_LAKEMONT  -m32 -miamcu
-mno-sse -mno-mmx -mno-80387 -S -o foo2.s foo2.i
foo2.i: In function ‘foo1’:
foo2.i:3:6: error: interrupt service routine can't be called directly
 void foo1 (void *p)
  ^~~~
Makefile:33: recipe for target 'foo2.s' failed
make: *** [foo2.s] Error 1
[hjl@gnu-6 pr78098]$ 

Can ICF turn foo1 into a tail call to foo2 when foo2 has an interrupt
attribute?

[Bug fortran/78053] [OOP] SELECT TYPE on CLASS(*) component for deferred length char arrays ICEs for -O > 0

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #5 from Dominique d'Humieres  ---
Duplicate of pr72770.

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

[Bug fortran/72770] [7 Regression] ICE in make_ssa_name_fn, at tree-ssanames.c:263

[dominiq at lps dot ens.fr]

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

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

[Bug target/78084] gcc miscompiles vec_vsx_ld on -O3

[wschmidt at gcc dot gnu.org]

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

--- Comment #5 from Bill Schmidt  ---
For the record, this was fixed a couple of months ago under
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72863.  I'll give Canonical a
heads-up to be sure they pick up the patch.

[Bug libstdc++/71337] temp_directory_path(error_code&) shouldn't throw from !exists(p) || !is_directory(p)

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
fixed on trunk so far.

[Bug target/78077] gcc 6.2.0 fails to link temacs from emacs-25.1 using the Xcode 8 linker

[howarth.at.gcc at gmail dot com]

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

--- Comment #4 from Jack Howarth  ---
The Apple developers think this is gcc bug producing malformatted input to the
linker. From macho_relocatable_file.cpp, we are triggering the linker check...

#ifndef NDEBUG
// scan for FDEs claming the same function
for(uint32_t i=1; i < cfiStartsArrayCount; ++i) {
assert( cfiStartsArray[i] != cfiStartsArray[i-1] );
}
#endif

[Bug fortran/72770] [7 Regression] ICE in make_ssa_name_fn, at tree-ssanames.c:263

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |WAITING
 CC||vehre at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |vehre at gcc dot gnu.org

--- Comment #6 from vehre at gcc dot gnu.org ---
Patch available at:

https://gcc.gnu.org/ml/fortran/2016-10/msg00189.html

Waiting for review.

[Bug middle-end/78098] error: interrupt service routine can't be called directly

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  ---
GCC correctly identified that foo1 == foo2 and generate a tail call.
But we don't want tail call in interrupt handler.  On the other hand,
there is no need to have 2 identical copies of an interrupt handler.
There should be only one interrupt handler or they should be different.

This patch

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index eef6d7b..be40ad9 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -28014,7 +28014,8 @@ ix86_expand_call (rtx retval, rtx fnaddr, rtx callarg1,
   if (fndecl
 && (lookup_attribute ("interrupt",
TYPE_ATTRIBUTES (TREE_TYPE (fndecl)
-  error ("interrupt service routine can't be called directly");
+  error ("interrupt service routine %q+D can't be called directly",
+ fndecl);
 }
   else
 fndecl = NULL_TREE;

changes the error message to

foo.i: In function ‘foo1’:
foo.i:9:33: error: interrupt service routine ‘foo2’ can't be called directly
 __attribute__((interrupt)) void foo2 (void *p)

to indicate that foo2 is called from foo1.

[Bug fortran/61337] Wrong indexing and runtime crash with unlimited polymorphic array.

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |WAITING
 CC||vehre at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |vehre at gcc dot gnu.org

--- Comment #6 from vehre at gcc dot gnu.org ---
Waiting one week for regression reports.

[Bug fortran/61376] Error using private statement in polymorphic derived type

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |WAITING
 CC||vehre at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |vehre at gcc dot gnu.org

--- Comment #3 from vehre at gcc dot gnu.org ---
Waiting one week for regression reports.

[Bug middle-end/77735] FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c (test for warnings, line 358)

[msebor at gcc dot gnu.org]

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

--- Comment #8 from Martin Sebor  ---
Author: msebor
Date: Mon Oct 24 16:53:20 2016
New Revision: 241489

URL: https://gcc.gnu.org/viewcvs?rev=241489=gcc=rev
Log:
PR middle-end/77735 - FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c

gcc/ChangeLog:

PR middle-end/77735
* builtins.c (string_length): New function.
(c_strlen): Use string_length.  Correctly handle wide strings.
* gimple-ssa-sprintf.c (target_max_value, target_size_max): New
functions.
(target_int_max): Call target_max_value.
(format_result::knownrange): New data member.
(fmtresult::fmtresult): Define default constructor.
(format_integer): Use it and set format_result::knownrange.
Handle global constants.
(format_floating_max): Add third argument.
(format_floating): Recompute maximum value for %a for each argument.
(get_string_length): Use fmtresult default ctor.
(format_string): Set format_result::knownrange.
(format_directive): Check format_result::knownrange.
(add_bytes): Same.  Correct caret placement in diagnostics.
(pass_sprintf_length::compute_format_length): Set
format_result::knownrange.
(pass_sprintf_length::handle_gimple_call): Use target_size_max.

gcc/testsuite/ChangeLog:

PR middle-end/77735
* gcc.dg/tree-ssa/builtin-sprintf-2.c: Add test cases.
* gcc.dg/tree-ssa/builtin-sprintf-warn-1.c: Same.
* gcc.dg/tree-ssa/builtin-sprintf-warn-2.c: Same.
* gcc.dg/tree-ssa/builtin-sprintf-warn-3.c: Adjust/relax.
* gcc.dg/tree-ssa/builtin-sprintf-warn-4.c: Add test cases.
* gcc.dg/tree-ssa/builtin-sprintf-warn-6.c: XFAIL for LP64 only.
* gcc.dg/tree-ssa/builtin-sprintf.c: Add test cases.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/gimple-ssa-sprintf.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-2.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-2.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-3.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-4.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-6.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c

[Bug fortran/57117] [OOP] ICE for sourced allocation of a polymorphic entity using TRANSPOSE

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

--- Comment #16 from vehre at gcc dot gnu.org ---
Waiting one week for regression reports.

[Bug middle-end/77735] FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c (test for warnings, line 358)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #9 from Martin Sebor  ---
r241489 should fix all the reported issues.  Besides natively on
{powerpc64,x86_64}-linux I also tested it with the hppa-unknown-linux-gnu
powerpc{,64}-linux, and sparc{,v9}-sun-solaris2.12 cross compilers with no
failures in any of the builtin-sprintf*.c tests.  If there are any lingering
failures please open a new bug.  Thanks everyone for your patience and help
with resolving these!

[Bug fortran/43366] [OOP][F08] Intrinsic assign to polymorphic variable

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING
 CC||vehre at gcc dot gnu.org
   Assignee|janus at gcc dot gnu.org   |vehre at gcc dot gnu.org

--- Comment #19 from vehre at gcc dot gnu.org ---
Waiting one week for regression reports.

[Bug fortran/51864] [OOP] ALLOCATE with polymorphic array constructor as SOURCE=

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |WAITING
   Assignee|unassigned at gcc dot gnu.org  |vehre at gcc dot gnu.org

--- Comment #4 from vehre at gcc dot gnu.org ---
Waiting one week for regression reports.

[Bug middle-end/78098] error: interrupt service routine can't be called directly

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
  Component|target  |middle-end

--- Comment #1 from H.J. Lu  ---
It is generated by IPA-ICF.

[Bug fortran/78053] [OOP] SELECT TYPE on CLASS(*) component for deferred length char arrays ICEs for -O > 0

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

--- Comment #4 from vehre at gcc dot gnu.org ---
Patch available at:

https://gcc.gnu.org/ml/fortran/2016-10/msg00189.html

Waiting for review.

[Bug libstdc++/71337] temp_directory_path(error_code&) shouldn't throw from !exists(p) || !is_directory(p)

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Mon Oct 24 16:45:51 2016
New Revision: 241487

URL: https://gcc.gnu.org/viewcvs?rev=241487=gcc=rev
Log:
PR71337 fix filesystem::temp_directory_path error handling

PR libstdc++/71337
* src/filesystem/ops.cc (temp_directory_path): Pass error_code
argument to other filesystem operations.
* testsuite/experimental/filesystem/operations/temp_directory_path.cc:
Add testcase for inaccessible directory.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/src/filesystem/ops.cc
   
trunk/libstdc++-v3/testsuite/experimental/filesystem/operations/temp_directory_path.cc

[Bug target/78095] [7 Regression] valgrind build error on ppc64le

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-24
 CC||amodra at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
Started with r235876:

commit 9213244550335bcb2b8590a0d7d58ac74c932361
Author: amodra 
Date:   Wed May 4 13:23:58 2016 +

[RS6000] Correct PIC_OFFSET_TABLE_REGNUM

Leaving this as r30 results in pic_offset_table_rtx of (reg 30)
for -m64, which is completely bogus.  Various rtl analysis predicate
functions treat pic_offset_table_rtx specially..

[Bug target/78098] New: error: interrupt service routine can't be called directly

[hjl.tools at gmail dot com]

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

Bug ID: 78098
   Summary: error: interrupt service routine can't be called
directly
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

[hjl@gnu-6 repro]$ cat foo.c
void bar (int);

__attribute__((interrupt)) void foo1 (void *p)
{
  bar (0);
  *((int *)0xFEE00080) = 0;
}

__attribute__((interrupt)) void foo2 (void *p)
{
  bar (0);
  *((int *)0xFEE00080) = 0;
}
[hjl@gnu-6 repro]$ make foo.s
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -Os -mno-sse -mno-mmx
-mno-80387 -S -o foo.s foo.c
foo.c: In function ‘foo1’:
foo.c:3:33: error: interrupt service routine can't be called directly
 __attribute__((interrupt)) void foo1 (void *p)
 ^~~~
Makefile:21: recipe for target 'foo.s' failed
make: *** [foo.s] Error 1
[hjl@gnu-6 repro]$ 

The problem is the tail call:

;; Function foo1 (foo1, funcdef_no=3, decl_uid=1466, cgraph_uid=0,
symbol_order=0)

foo1 (void * p)
{
;;   basic block 2, loop depth 0
;;pred:   ENTRY
  foo2 (p_2(D)); [tail call]
  return;
;;succ:   EXIT

}

[Bug other/78097] gcc-6.2.0 inconsistent libgcc_s.so link

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
Those libraries should not be using -R. But I doubt they are. I suspect
something else is funny here.

[Bug other/78097] gcc-6.2.0 inconsistent libgcc_s.so link

[edeveaud at pasteur dot fr]

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

--- Comment #1 from Eric  ---
oops of course 
find /exe/gcc/4.9.4 -type l -name \*.so | xargs ldd | grep libgcc_s.so

should be read

find /exe/gcc/6.0.2 -type l -name \*.so | xargs ldd | grep libgcc_s.so

[Bug other/78097] New: gcc-6.2.0 inconsistent libgcc_s.so link

[edeveaud at pasteur dot fr]

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

Bug ID: 78097
   Summary: gcc-6.2.0 inconsistent libgcc_s.so link
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: edeveaud at pasteur dot fr
  Target Milestone: ---

Hello, 

building gcc-6.2.0 on centos6 lead on inconsistent link to libgcc_s.so

some libraries are linked to the installed  libraries, while other are linked
to libgcc_s.so system libraries


here is a Dockerfile that reproduce the problem.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
FROM centos:6
MAINTAINER Eric Deveaud 

RUN yum install -y gcc gcc-c++ wget

WORKDIR /src

#  install internal gcc 
RUN mkdir -p gcc/6.2.0 && \
cd gcc/6.2.0 && \
wget -qO-  ftp://ftp.lip6.fr/pub/gcc/releases/gcc-6.2.0/gcc-6.2.0.tar.gz |
tar xz --strip-components 1 && \
sh contrib/download_prerequisites

RUN mkdir -p /tmp/build && \
cd /tmp/build && \
/src/gcc/6.2.0/configure --disable-multilib --enable-threads=posix
--enable-__cxa_atexit -enable-languages=c,c++ --prefix=/exe/gcc/6.2.0 && \
MAKEFLAGS="-j $(grep -c ^processor /proc/cpuinfo)" make  bootstrap && \
make install

# run produced docker using 
# docker run -i -t  gcc /bin/bash
# then
# find /exe/gcc/4.9.4 -type l -name \*.so | xargs ldd | grep libgcc_s.so

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

container was built using 

docker build   -f Dockerfile-gcc  -t  gcc . | tee log

(I can provide buil log)

and then container run using 

docker run -i -t  gcc /bin/bash


following command emphasis the linking problem.

[root@5ec47cdc07e6 src]# find /exe/gcc/6.2.0/ -type l -name \*.so | xargs ldd |
grep libgcc_s.so
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7ff1dde2e000)
libgcc_s.so.1 => /exe/gcc/6.2.0/lib/../lib64/libgcc_s.so.1
(0x7f1be06c7000)
libgcc_s.so.1 => /exe/gcc/6.2.0/lib/../lib64/libgcc_s.so.1
(0x7f6490629000)
libgcc_s.so.1 => /exe/gcc/6.2.0/lib/../lib64/libgcc_s.so.1
(0x7f7afcaf3000)
libgcc_s.so.1 => /exe/gcc/6.2.0/lib/../lib64/libgcc_s.so.1
(0x7febfaf18000)
libgcc_s.so.1 => /exe/gcc/6.2.0/lib/../lib64/libgcc_s.so.1
(0x7fbe2165c000)
libgcc_s.so.1 => /exe/gcc/6.2.0/lib/../lib64/libgcc_s.so.1
(0x7f18d26f8000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7f2390256000)
libgcc_s.so.1 => /exe/gcc/6.2.0/lib/../lib64/libgcc_s.so.1
(0x7f9755e8a000)



/exe/gcc/6.2.0/lib64/libstdc++.so
/exe/gcc/6.2.0/lib64/libitm.so
 links to /lib64/libgcc_s.so.1

/exe/gcc/6.2.0/lib64/libasan.so
/exe/gcc/6.2.0/lib64/liblsan.so
/exe/gcc/6.2.0/lib64/libcilkrts.so
/exe/gcc/6.2.0/lib64/libtsan.so
/exe/gcc/6.2.0/lib64/libubsan.so
/exe/gcc/6.2.0/lib64/libcc1.so
/exe/gcc/6.2.0/lib/gcc/x86_64-pc-linux-gnu/6.2.0/plugin/libcc1plugin.so
links to /exe/gcc/6.2.0/lib/../lib64/libgcc_s.so.1 

NB see also: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78096
@Markus I hope that gcc-6.0.2 is still maintained  ;-)

best regards

Eric

[Bug other/78096] gcc-4.9.4 make bootstrap libgcc_s.so link problem

[edeveaud at pasteur dot fr]

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

--- Comment #6 from Eric  ---
same problem with gcc/6.2.0 

/exe/gcc/6.2.0/lib64/libstdc++.so
/exe/gcc/6.2.0/lib64/libitm.so
 links to /lib64/libgcc_s.so.1

/exe/gcc/6.2.0/lib64/libasan.so
/exe/gcc/6.2.0/lib64/liblsan.so
/exe/gcc/6.2.0/lib64/libcilkrts.so
/exe/gcc/6.2.0/lib64/libtsan.so
/exe/gcc/6.2.0/lib64/libubsan.so
/exe/gcc/6.2.0/lib64/libcc1.so
/exe/gcc/6.2.0/lib/gcc/x86_64-pc-linux-gnu/6.2.0/plugin/libcc1plugin.so
links to /exe/gcc/6.2.0/lib/../lib64/libgcc_s.so.1 

I'll open a new bug report for gcc/6.2.0


docker run -i -t  gcc /bin/bash 
[root@5ec47cdc07e6 src]# find /exe/gcc/6.2.0/ -type l -name \*.so | xargs ldd |
grep libgcc_s.so
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7ff1dde2e000)
libgcc_s.so.1 => /exe/gcc/6.2.0/lib/../lib64/libgcc_s.so.1
(0x7f1be06c7000)
libgcc_s.so.1 => /exe/gcc/6.2.0/lib/../lib64/libgcc_s.so.1
(0x7f6490629000)
libgcc_s.so.1 => /exe/gcc/6.2.0/lib/../lib64/libgcc_s.so.1
(0x7f7afcaf3000)
libgcc_s.so.1 => /exe/gcc/6.2.0/lib/../lib64/libgcc_s.so.1
(0x7febfaf18000)
libgcc_s.so.1 => /exe/gcc/6.2.0/lib/../lib64/libgcc_s.so.1
(0x7fbe2165c000)
libgcc_s.so.1 => /exe/gcc/6.2.0/lib/../lib64/libgcc_s.so.1
(0x7f18d26f8000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7f2390256000)
libgcc_s.so.1 => /exe/gcc/6.2.0/lib/../lib64/libgcc_s.so.1
(0x7f9755e8a000)

[Bug tree-optimization/78088] [7 Regression] error: non-trivial conversion in unary operation

[matz at gcc dot gnu.org]

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

Michael Matz  changed:

   What|Removed |Added

 CC||matz at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |matz at gcc dot gnu.org

--- Comment #2 from Michael Matz  ---
Mine.

[Bug other/78096] gcc-4.9.4 make bootstrap libgcc_s.so link problem

[trippels at gcc dot gnu.org]

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

--- Comment #5 from Markus Trippelsdorf  ---
This question should be asked on the gcc-h...@gcc.gnu.org list.
Bugzilla is the wrong place for it.

[Bug tree-optimization/78060] [7 Regression] -O3 causes "error: type mismatch in binary expression"

[matz at gcc dot gnu.org]

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

Michael Matz  changed:

   What|Removed |Added

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

--- Comment #4 from Michael Matz  ---
On it.

[Bug other/78096] gcc-4.9.4 make bootstrap libgcc_s.so link problem

[edeveaud at pasteur dot fr]

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

--- Comment #4 from Eric  ---
anyway the link is not consistent 

what can I do in order to remove any system gcc + libs 
to provide ONLY the gcc we compiled to our cluster users ?

[Bug other/78096] gcc-4.9.4 make bootstrap libgcc_s.so link problem

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||trippels at gcc dot gnu.org
 Resolution|--- |WONTFIX

--- Comment #1 from Markus Trippelsdorf  ---
gcc-4.9 isn't maintained anymore. Please see gcc.gnu.org for 
a list of currently supported releases.

[Bug other/78096] gcc-4.9.4 make bootstrap libgcc_s.so link problem

[edeveaud at pasteur dot fr]

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

--- Comment #2 from Eric  ---
so I have to switch on gcc version 5 or 6 
with incompatible ABI change in the C++ library ? 

nice ;-)

[Bug other/78096] gcc-4.9.4 make bootstrap libgcc_s.so link problem

[trippels at gcc dot gnu.org]

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

--- Comment #3 from Markus Trippelsdorf  ---
(In reply to Eric from comment #2)
> so I have to switch on gcc version 5 or 6 
> with incompatible ABI change in the C++ library ? 
> 
> nice ;-)

No need to switch the ABI, you can use the old one just fine.

[Bug other/78096] New: gcc-4.9.4 make bootstrap libgcc_s.so link problem

[edeveaud at pasteur dot fr]

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

Bug ID: 78096
   Summary: gcc-4.9.4 make bootstrap libgcc_s.so link problem
   Product: gcc
   Version: 4.9.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: edeveaud at pasteur dot fr
  Target Milestone: ---

Hello, 

while building gcc-4.9.4 on centos6 I have a strange link problem
some libraries are linked to the installed libgcc_s.so libraries, while other
are linked to libgcc_s.so system libraries

eg:
link to system libgcc_s.so
libstdc++.so
libvtv.so
libitm.so

link to installed libgcc_s.so
libasan.so
liblsan.so
libcilkrts.so 
libtsan.so
libubsan.so


here is a Dockerfile that reproduce the problem.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
FROM centos:6
MAINTAINER Eric Deveaud 

RUN yum install -y gcc gcc-c++ wget

WORKDIR /src

#  install internal gcc 
RUN mkdir -p gcc/4.9.4 && \
cd gcc/4.9.4 && \
wget -qO-  ftp://ftp.lip6.fr/pub/gcc/releases/gcc-4.9.4/gcc-4.9.4.tar.gz |
tar xz --strip-components 1 && \
sh contrib/download_prerequisites 

RUN mkdir -p /tmp/build && \
cd /tmp/build && \
/src/gcc/4.9.4/configure --disable-multilib --enable-threads=posix
--enable-__cxa_atexit -enable-languages=c,c++ --prefix=/exe/gcc/4.9.4 && \
make  bootstrap && \
make install 

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

container was built using 

docker build   -f Dockerfile-gcc  -t  gcc . | tee log

(I can provide buil log

and then container run using 

docker run -i -t  gcc /bin/bash


following command emphasis the linking problem.

find /exe/gcc/4.9.4 -type l -name \*.so | xargs ldd | grep libgcc_s.so
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7f043971c000)
libgcc_s.so.1 => /exe/gcc/4.9.4/lib/../lib64/libgcc_s.so.1
(0x7f7ae4b97000)
libgcc_s.so.1 => /exe/gcc/4.9.4/lib/../lib64/libgcc_s.so.1
(0x7f4321ef7000)
libgcc_s.so.1 => /exe/gcc/4.9.4/lib/../lib64/libgcc_s.so.1
(0x7fd9918fe000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7f5ea3ba4000)
libgcc_s.so.1 => /exe/gcc/4.9.4/lib/../lib64/libgcc_s.so.1
(0x7fbaf49bc000)
libgcc_s.so.1 => /exe/gcc/4.9.4/lib/../lib64/libgcc_s.so.1
(0x7fd7f5423000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7f57bcfeb000)


did I missed something ?

best regards

Eric

[Bug libstdc++/77495] optional assignment from {} acts weirdly

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

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

--- Comment #2 from Ville Voutilainen  ---
Fixed by the fix in PR 77288.

[Bug libfortran/78055] [7 regression] Many new gfortran test failures

[dje at gcc dot gnu.org]

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

--- Comment #15 from David Edelsohn  ---
The AIX failures are fixed.

[Bug tree-optimization/78061] [7 Regression] -O3 causes "Error: definition in block 117 does not dominate use in block 164"

[matz at gcc dot gnu.org]

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

Michael Matz  changed:

   What|Removed |Added

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

--- Comment #3 from Michael Matz  ---
On it.

[Bug libfortran/78055] [7 regression] Many new gfortran test failures

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #12 from Jerry DeLisle  ---
> Rainer, please confirm the fix commited on trunk when you have time.

Sure: I had it in my tree during this weekend's bootstraps and all
failures are gone, as expected.

Thanks.
Rainer

[Bug target/78095] [7 Regression] valgrind build error on ppc64le

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug testsuite/71491] [7 Regression] gcc.dg/vect/slp-43.c FAILs

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #6 from Richard Biener  ---
Ok, fixed then.

[Bug testsuite/71491] [7 Regression] gcc.dg/vect/slp-43.c FAILs

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Author: rguenth
Date: Mon Oct 24 12:58:20 2016
New Revision: 241478

URL: https://gcc.gnu.org/viewcvs?rev=241478=gcc=rev
Log:
2016-10-24  Richard Biener  

PR testsuite/71491
* gcc.dg/vect/slp-43.c: Adjust for !vect_hw_misalign.
* gcc.dg/vect/slp-45.c: Likewise.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/vect/slp-43.c
trunk/gcc/testsuite/gcc.dg/vect/slp-45.c

[Bug target/78095] New: [7 Regression] valgrind build error on ppc64le

[trippels at gcc dot gnu.org]

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

Bug ID: 78095
   Summary: [7 Regression] valgrind build error on ppc64le
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
CC: dje at gcc dot gnu.org, segher at gcc dot gnu.org,
wschmidt at gcc dot gnu.org
  Target Milestone: ---
  Host: powerpc64le-unknown-linux-gnu
Target: powerpc64le-unknown-linux-gnu
 Build: powerpc64le-unknown-linux-gnu

I cannot build valgrind on ppc64le with trunk:

trippels@gcc2-power8 coregrind % cat vg_preloaded.i
void fn1() {
  __asm__("" : : : "r2");
}

trippels@gcc2-power8 coregrind % ~/gcc_5/usr/local/bin/gcc -c vg_preloaded.i
trippels@gcc2-power8 coregrind % ~/gcc_6/usr/local/bin/gcc -c vg_preloaded.i
trippels@gcc2-power8 coregrind % ~/gcc_7/usr/local/bin/gcc -c vg_preloaded.i
vg_preloaded.i: In function ‘fn1’:
vg_preloaded.i:2:3: error: PIC register clobbered by ‘r2’ in ‘asm’
   __asm__("" : : : "r2");
   ^~~

[Bug testsuite/71491] [7 Regression] gcc.dg/vect/slp-43.c FAILs

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #4 from Richard Biener  ---
[...]
> I suppose XFAILing / providing alternat scan-dump for [!] vect_hw_misalign
> will fix this.
>
> Can you test the attached?

Both tests now PASS in 32 and 64-bit.

Thanks.
Rainer

[Bug libstdc++/77495] optional assignment from {} acts weirdly

[ville.voutilainen at gmail dot com]

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

Bug 77288 Summary: Std::experimental::optional::operator= implementation is 
broken in gcc 6.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77288

   What|Removed |Added

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

[Bug libstdc++/77727] Unwrapping std::optional constructor is not working for non-transferable object

[ville at gcc dot gnu.org]

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

--- Comment #6 from ville at gcc dot gnu.org ---
Author: ville
Date: Mon Oct 24 12:52:31 2016
New Revision: 241477

URL: https://gcc.gnu.org/viewcvs?rev=241477=gcc=rev
Log:
Backport from mainline:

2016-10-24  Ville Voutilainen  

Cross-port the latest resolution of LWG2756 and some
bug-fixes to experimental::optional.
PR libstdc++/77288
PR libstdc++/77727
* include/experimental/optional (_Optional_base):
Remove constructors that take a _Tp.
(__is_optional_impl, __is_optional): Remove.
(__converts_from_optional): New.
(optional(_Up&&)): Fix constraints, call base with in_place.
(optional(const optional<_Up>&)): Fix constraints, use emplace.
(optional(optional<_Up>&&)): Likewise.
(operator=(_Up&&)): Fix constraints.
(operator=(const optional<_Up>&)): Likewise.
(operator=(optional<_Up>&&)): Likewise.
(emplace(_Args&&...)): Constrain.
(emplace(initializer_list<_Up>, _Args&&...)): Likewise.
* testsuite/experimental/optional/77288.cc: New.
* testsuite/experimental/optional/assignment/5.cc: Adjust.
* testsuite/experimental/optional/cons/77727.cc: New.
* testsuite/experimental/optional/cons/value.cc: Adjust.

Added:
branches/gcc-6-branch/libstdc++-v3/testsuite/experimental/optional/77288.cc
   
branches/gcc-6-branch/libstdc++-v3/testsuite/experimental/optional/cons/77727.cc
  - copied, changed from r241461,
branches/gcc-6-branch/libstdc++-v3/testsuite/experimental/optional/assignment/5.cc
Modified:
branches/gcc-6-branch/libstdc++-v3/ChangeLog
branches/gcc-6-branch/libstdc++-v3/include/experimental/optional
   
branches/gcc-6-branch/libstdc++-v3/testsuite/experimental/optional/assignment/5.cc
   
branches/gcc-6-branch/libstdc++-v3/testsuite/experimental/optional/cons/value.cc

[Bug libstdc++/77288] Std::experimental::optional::operator= implementation is broken in gcc 6.1

[ville at gcc dot gnu.org]

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

--- Comment #12 from ville at gcc dot gnu.org ---
Author: ville
Date: Mon Oct 24 12:52:31 2016
New Revision: 241477

URL: https://gcc.gnu.org/viewcvs?rev=241477=gcc=rev
Log:
Backport from mainline:

2016-10-24  Ville Voutilainen  

Cross-port the latest resolution of LWG2756 and some
bug-fixes to experimental::optional.
PR libstdc++/77288
PR libstdc++/77727
* include/experimental/optional (_Optional_base):
Remove constructors that take a _Tp.
(__is_optional_impl, __is_optional): Remove.
(__converts_from_optional): New.
(optional(_Up&&)): Fix constraints, call base with in_place.
(optional(const optional<_Up>&)): Fix constraints, use emplace.
(optional(optional<_Up>&&)): Likewise.
(operator=(_Up&&)): Fix constraints.
(operator=(const optional<_Up>&)): Likewise.
(operator=(optional<_Up>&&)): Likewise.
(emplace(_Args&&...)): Constrain.
(emplace(initializer_list<_Up>, _Args&&...)): Likewise.
* testsuite/experimental/optional/77288.cc: New.
* testsuite/experimental/optional/assignment/5.cc: Adjust.
* testsuite/experimental/optional/cons/77727.cc: New.
* testsuite/experimental/optional/cons/value.cc: Adjust.

Added:
branches/gcc-6-branch/libstdc++-v3/testsuite/experimental/optional/77288.cc
   
branches/gcc-6-branch/libstdc++-v3/testsuite/experimental/optional/cons/77727.cc
  - copied, changed from r241461,
branches/gcc-6-branch/libstdc++-v3/testsuite/experimental/optional/assignment/5.cc
Modified:
branches/gcc-6-branch/libstdc++-v3/ChangeLog
branches/gcc-6-branch/libstdc++-v3/include/experimental/optional
   
branches/gcc-6-branch/libstdc++-v3/testsuite/experimental/optional/assignment/5.cc
   
branches/gcc-6-branch/libstdc++-v3/testsuite/experimental/optional/cons/value.cc

[Bug libstdc++/77288] Std::experimental::optional::operator= implementation is broken in gcc 6.1

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

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

--- Comment #13 from Ville Voutilainen  ---
Fixed.

[Bug libstdc++/77288] Std::experimental::optional::operator= implementation is broken in gcc 6.1

[ville at gcc dot gnu.org]

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

--- Comment #11 from ville at gcc dot gnu.org ---
Author: ville
Date: Mon Oct 24 12:46:44 2016
New Revision: 241476

URL: https://gcc.gnu.org/viewcvs?rev=241476=gcc=rev
Log:
Cross-port the latest resolution of LWG2756 and some
bug-fixes to experimental::optional.
PR libstdc++/77288
PR libstdc++/77727
* include/experimental/optional (_Optional_base):
Remove constructors that take a _Tp.
(__is_optional_impl, __is_optional): Remove.
(__converts_from_optional): New.
(optional(_Up&&)): Fix constraints, call base with in_place.
(optional(const optional<_Up>&)): Fix constraints, use emplace.
(optional(optional<_Up>&&)): Likewise.
(operator=(_Up&&)): Fix constraints.
(operator=(const optional<_Up>&)): Likewise.
(operator=(optional<_Up>&&)): Likewise.
(emplace(_Args&&...)): Constrain.
(emplace(initializer_list<_Up>, _Args&&...)): Likewise.
* testsuite/experimental/optional/77288.cc: New.
* testsuite/experimental/optional/assignment/5.cc: Adjust.
* testsuite/experimental/optional/cons/77727.cc: New.
* testsuite/experimental/optional/cons/value.cc: Adjust.

Added:
trunk/libstdc++-v3/testsuite/experimental/optional/77288.cc
trunk/libstdc++-v3/testsuite/experimental/optional/cons/77727.cc
  - copied, changed from r241475,
trunk/libstdc++-v3/testsuite/experimental/optional/assignment/5.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/experimental/optional
trunk/libstdc++-v3/testsuite/experimental/optional/assignment/5.cc
trunk/libstdc++-v3/testsuite/experimental/optional/cons/value.cc

[Bug libstdc++/77727] Unwrapping std::optional constructor is not working for non-transferable object

[ville at gcc dot gnu.org]

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

--- Comment #5 from ville at gcc dot gnu.org ---
Author: ville
Date: Mon Oct 24 12:46:44 2016
New Revision: 241476

URL: https://gcc.gnu.org/viewcvs?rev=241476=gcc=rev
Log:
Cross-port the latest resolution of LWG2756 and some
bug-fixes to experimental::optional.
PR libstdc++/77288
PR libstdc++/77727
* include/experimental/optional (_Optional_base):
Remove constructors that take a _Tp.
(__is_optional_impl, __is_optional): Remove.
(__converts_from_optional): New.
(optional(_Up&&)): Fix constraints, call base with in_place.
(optional(const optional<_Up>&)): Fix constraints, use emplace.
(optional(optional<_Up>&&)): Likewise.
(operator=(_Up&&)): Fix constraints.
(operator=(const optional<_Up>&)): Likewise.
(operator=(optional<_Up>&&)): Likewise.
(emplace(_Args&&...)): Constrain.
(emplace(initializer_list<_Up>, _Args&&...)): Likewise.
* testsuite/experimental/optional/77288.cc: New.
* testsuite/experimental/optional/assignment/5.cc: Adjust.
* testsuite/experimental/optional/cons/77727.cc: New.
* testsuite/experimental/optional/cons/value.cc: Adjust.

Added:
trunk/libstdc++-v3/testsuite/experimental/optional/77288.cc
trunk/libstdc++-v3/testsuite/experimental/optional/cons/77727.cc
  - copied, changed from r241475,
trunk/libstdc++-v3/testsuite/experimental/optional/assignment/5.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/experimental/optional
trunk/libstdc++-v3/testsuite/experimental/optional/assignment/5.cc
trunk/libstdc++-v3/testsuite/experimental/optional/cons/value.cc

[Bug target/77934] pattern for mtvsrdd needs to use b constraint not r

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

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

--- Comment #2 from Bill Schmidt  ---
Fixed a couple of weeks ago.

[Bug target/78077] gcc 6.2.0 fails to link temacs from emacs-25.1 using the Xcode 8 linker

[howarth.at.gcc at gmail dot com]

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

--- Comment #3 from Jack Howarth  ---
Opened radar://28914335 'linker crash when linking temacs from emacs 25.1 when
built with FSF gcc 6.2.0 or gcc trunk' with standalone test case attached as
reproducer.

[Bug fortran/78092] [5/6/7 Regression] ICE when calling SIZEOF on CLASS(*) entry

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  ---
The change occurred between revisions r213007 (2014-07-24, compiles) and
r213805 (2014-08-11, ICE), likely r213079 (PRs 57305, 61881, and 61888).
Backtrace with r241433 is

* thread #1: tid = 0xd87554, 0x000100105200
f951`gfc_class_vptr_get(decl=0x000143ee4000) + 64 at trans-expr.c:208,
queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1,
address=0x8)
frame #0: 0x000100105200
f951`gfc_class_vptr_get(decl=0x000143ee4000) + 64 at trans-expr.c:208
   205  decl = build_fold_indirect_ref_loc (input_location, decl);
   206vptr = gfc_advance_chain (TYPE_FIELDS (TREE_TYPE (decl)),
   207  CLASS_VPTR_FIELD);
-> 208return fold_build3_loc (input_location, COMPONENT_REF,
   209TREE_TYPE (vptr), decl, vptr,
   210NULL_TREE);
   211  }
(lldb) bt
* thread #1: tid = 0xd87554, 0x000100105200
f951`gfc_class_vptr_get(decl=0x000143ee4000) + 64 at trans-expr.c:208,
queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1,
address=0x8)
  * frame #0: 0x000100105200
f951`gfc_class_vptr_get(decl=0x000143ee4000) + 64 at trans-expr.c:208
frame #1: 0x000100105809 f951`gfc_class_vtab_size_get(tree_node*) + 5
at trans-expr.c:279
frame #2: 0x000100105804 f951`gfc_class_vtab_size_get(cl=)
+ 4
frame #3: 0x000100127a48
f951`::gfc_conv_intrinsic_sizeof(se=0x7fff5fbfe5c0, expr=) +
760 at trans-intrinsic.c:6715
frame #4: 0x00010012ebda
f951`gfc_conv_intrinsic_function(se=0x7fff5fbfe5c0,
expr=0x000142308c80) + 5818 at trans-intrinsic.c:8986
frame #5: 0x000100114d35
f951`::gfc_conv_function_expr(se=0x7fff5fbfe5c0, expr=) + 117
at trans-expr.c:6714
frame #6: 0x00010010b504 f951`gfc_conv_expr_val(se=0x7fff5fbfe5c0,
expr=) + 20 at trans-expr.c:7786
frame #7: 0x00010011acbb
f951`::gfc_conv_intrinsic_function_args(se=0x7fff5fbfea50,
argarray=0x7fff5fbfe660, nargs=1, expr=, expr=) +
107 at trans-intrinsic.c:229
frame #8: 0x00010011c107
f951`::gfc_conv_intrinsic_conversion(se=0x7fff5fbfea50,
expr=0x000142308480) + 167 at trans-intrinsic.c:287
frame #9: 0x00010012f22b
f951`gfc_conv_intrinsic_function(se=0x7fff5fbfea50,
expr=0x000142308480) + 7435 at trans-intrinsic.c:8641
frame #10: 0x000100114d35
f951`::gfc_conv_function_expr(se=0x7fff5fbfea50, expr=) + 117
at trans-expr.c:6714
frame #11: 0x000100117094
f951`::gfc_trans_assignment_1(expr1=0x000142308290,
expr2=0x000142308480, init_flag=, dealloc=) + 612
at trans-expr.c:9489
frame #12: 0x0001000db876 f951`::trans_code(code=0x000142308a30,
cond=0x) + 790 at trans.c:1710
frame #13: 0x000100102a45
f951`gfc_generate_function_code(ns=) + 965 at trans-decl.c:6252
frame #14: 0x0001001027dd
f951`gfc_generate_function_code(gfc_namespace*) + 107 at trans-decl.c:5232
frame #15: 0x000100102772
f951`gfc_generate_function_code(ns=0x000146017400) + 242
frame #16: 0x000100090e35 f951`gfc_parse_file() + 1749 at parse.c:5940
frame #17: 0x0001000d7e76 f951`::gfc_be_parse_file() + 54 at
f95-lang.c:198
frame #18: 0x0001009fa07a f951`::compile_file() + 58 at toplev.c:468
frame #19: 0x000100e1a841 f951`toplev::main(int, char**) + 1216 at
toplev.c:2012
frame #20: 0x000100e1a381 f951`toplev::main(this=0x7fff5fbff2b0,
argc=, argv=) + 737
frame #21: 0x000100e1c439 f951`main(argc=2, argv=0x7fff5fbff2f8) +
41 at main.c:39

[Bug fortran/61420] [5/6/7 Regression] [OOP] type-bound procedure returning a procedure pointer fails to compile

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #14 from Paul Thomas  ---
Fixed on 5-, 6- and 7-branches.

Thanks for the report.

Paul

[Bug fortran/61420] [5/6/7 Regression] [OOP] type-bound procedure returning a procedure pointer fails to compile

[pault at gcc dot gnu.org]

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

--- Comment #13 from Paul Thomas  ---
Author: pault
Date: Mon Oct 24 12:14:52 2016
New Revision: 241474

URL: https://gcc.gnu.org/viewcvs?rev=241474=gcc=rev
Log:
2016-10-24  Paul Thomas  

PR fortran/61420
PR fortran/78013
* resolve.c (resolve_variable): Obtain the typespec for a
variable expression, when the variable is a function result
that is a procedure pointer.

2016-10-24  Paul Thomas  

PR fortran/61420
PR fortran/78013
* gfortran.dg/proc_ptr_49.f90: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/proc_ptr_49.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/resolve.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug fortran/78013] unexpected 'has no IMPLICIT type' error for a type-bound function returning a procedure pointer

[pault at gcc dot gnu.org]

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

--- Comment #4 from Paul Thomas  ---
Author: pault
Date: Mon Oct 24 12:14:52 2016
New Revision: 241474

URL: https://gcc.gnu.org/viewcvs?rev=241474=gcc=rev
Log:
2016-10-24  Paul Thomas  

PR fortran/61420
PR fortran/78013
* resolve.c (resolve_variable): Obtain the typespec for a
variable expression, when the variable is a function result
that is a procedure pointer.

2016-10-24  Paul Thomas  

PR fortran/61420
PR fortran/78013
* gfortran.dg/proc_ptr_49.f90: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/proc_ptr_49.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/resolve.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug debug/77985] DW_AT_comp_dir is omitted when filename is absolute and the file does not contain a specific typedef

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|6.3 |7.0

--- Comment #12 from Richard Biener  ---
Fixed for GCC 7.

[Bug debug/77985] DW_AT_comp_dir is omitted when filename is absolute and the file does not contain a specific typedef

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener  ---
Author: rguenth
Date: Mon Oct 24 11:57:27 2016
New Revision: 241473

URL: https://gcc.gnu.org/viewcvs?rev=241473=gcc=rev
Log:
2016-10-24  Ximin Luo  

PR debug/77985
* dwarf2out.c (file_table_relative_p): Remove.
(gen_compile_unit_die, dwarf2out_early_finish): Emit DW_AT_comp_dir
also for absolute paths.
* doc/tm.texi: Update.
* doc/tm.texi.in (SDB and DWARF) : Remove.
* target.def (force_at_comp_dir): Remove hook.
* config/darwin.h (TARGET_FORCE_AT_COMP_DIR): Remove define.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/darwin.h
trunk/gcc/doc/tm.texi
trunk/gcc/doc/tm.texi.in
trunk/gcc/dwarf2out.c
trunk/gcc/target.def

[Bug target/78077] gcc 6.2.0 fails to link temacs from emacs-25.1 using the Xcode 8 linker

[howarth.at.gcc at gmail dot com]

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

--- Comment #2 from Jack Howarth  ---
This issue is also observed on x86_64-apple-darwin14 using gcc 6.2.0 and the
linker from Xcode 7.2.1.