[Bug fortran/78737] [OOP] linking error with deferred, undefined user-defined derived-type I/O

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #8 from Paul Thomas  ---
(In reply to janus from comment #5)
> (In reply to janus from comment #4)
> > Looking at the dump, one probably needs a polymorphic reference to
> > 'a->_vptr->write_formatted' instead of using the interface?
> 
> Btw, such wrong-code behavior is also seen in the non-abstract version:
> 
> 
> module object_interface
>   type :: object
>   contains
> procedure :: write_formatted
> generic :: write(formatted) => write_formatted
>   end type
> contains
>   subroutine write_formatted(this,unit,iotype,vlist,iostat,iomsg)
> class(object), intent(in) :: this
> integer, intent(in) :: unit
> character (len=*), intent(in) :: iotype
> integer, intent(in) :: vlist(:)
> integer, intent(out) :: iostat
> character (len=*), intent(inout) :: iomsg
>   end subroutine
> 
>   subroutine assert(a)
> class(object):: a
> write(*,*) a
>   end subroutine
> end module
> 
> end
> 
> 
> If the write procedure is overwritten in an extended type, then the write
> statement still calls the one from the base class, which is wrong.

Janus,

We interpreted the standard to imply that a SELECT TYPE is required in
write_formatted to obtain the correct dtio io procedure.

I did think about adding pointers to the procedures in the vtable but decided
that the standard did not require it.

Cheers

Paul

[Bug c++/78770] New: error: 'bar' was not declared in this scope. note: suggested alternative: 'bar'

[safinaskar at mail dot ru]

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

Bug ID: 78770
   Summary: error: 'bar' was not declared in this scope. note:
suggested alternative: 'bar'
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: safinaskar at mail dot ru
  Target Milestone: ---

Consider this code:

struct foo
{
  friend void
  bar (void);

  void baz (void)
  {
bar ();
  }
};

void
bar (void)
{
}

g++ gives very strange "suggestion":

gcrash.cpp: In member function 'void foo::baz()':
gcrash.cpp:8:5: error: 'bar' was not declared in this scope
 bar ();
 ^~~
gcrash.cpp:8:5: note: suggested alternative: 'bar'
 bar ();
 ^~~
 bar

Error seems to be legit. Problem is in suggestion. g++ suggests to replace
"bar" with "bar". (???)

Command line:
/usr/lib/gcc-snapshot/bin/g++ -std=c++1z -fdiagnostics-color=always -c -o
/dev/null gcrash.cpp

debian gnu/linux stretch amd64 (x86_64). debian package gcc-snapshot
20161124-2. gcc -v:

Using built-in specs.
COLLECT_GCC=/usr/lib/gcc-snapshot/bin/gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc-snapshot/libexec/gcc/x86_64-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 20161124-2'
--with-bugurl=file:///usr/share/doc/gcc-snapshot/README.Bugs
--enable-languages=c,ada,c++,go,fortran,objc,obj-c++
--prefix=/usr/lib/gcc-snapshot --program-prefix= --enable-shared
--enable-linker-build-id --disable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=yes --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 7.0.0 20161124 (experimental) [trunk revision 242836] (Debian
20161124-2)

[Bug fortran/78737] [OOP] linking error with deferred, undefined user-defined derived-type I/O

[pault at gcc dot gnu.org]

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

--- Comment #9 from Paul Thomas  ---
Created attachment 40302
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40302&action=edit
A workaround for the PR (even a patch?)

The attached allows this testcase to run as intended:

! { dg-do run }
!
! Test the fix for PR78737. This is a development of the testscase
! in comment #6, which runs as intended.
!
! Contributed by Damian Rouson  
!
module object_interface
  type, abstract :: object
  contains
procedure(write_formatted), deferred :: write_formatted
generic :: write(formatted) => write_formatted
  end type

! First extended type
  type, extends(object) :: non_abstract_child1
integer :: i
  contains
! Point write_formatted to a specific procedure
procedure :: write_formatted => write_formatted1
  end type

! Second extended type
  type, extends(object) :: non_abstract_child2
real :: r
  contains
! Use the instantiation of the generic name
procedure :: write_formatted
  end type

! Third extended type
  type, extends(object) :: non_abstract_child3
character(3) :: c
  contains
! Use the instantiation of the generic name
procedure :: write_formatted
  end type

contains
  subroutine write_formatted1(this,unit,iotype,vlist,iostat,iomsg)
class(non_abstract_child1), intent(in) :: this
integer, intent(in) :: unit
character (len=*), intent(in) :: iotype
integer, intent(in) :: vlist(:)
integer, intent(out) :: iostat
character (len=*), intent(inout) :: iomsg
if (this%i .ne. 99) call abort
  end subroutine

  subroutine write_formatted(this,unit,iotype,vlist,iostat,iomsg)
class(object), intent(in) :: this
integer, intent(in) :: unit
character (len=*), intent(in) :: iotype
integer, intent(in) :: vlist(:)
integer, intent(out) :: iostat
character (len=*), intent(inout) :: iomsg
select type (this)
  class is (non_abstract_child1)
if (this%i .ne. 99) call abort
  class is (non_abstract_child2)
if (abs (this%r - 3.14159274) .gt. 1.0e-6) call abort
  class is (non_abstract_child3)
if (this%c .ne. "abc") call abort
end select
  end subroutine

  subroutine assert(a)
class(object):: a
select type (a)
  class is (non_abstract_child1)
write(*,*) a
  class default
write(*,*) a
end select
  end subroutine
end module

  use object_interface
  class(object), allocatable :: z
  allocate (z, source = non_abstract_child1 (99))
  call assert (z)
  write (*,*) z
  deallocate (z)
  allocate (z, source = non_abstract_child2 (2.0*acos(0.0)))
  call assert (z)
  write (*,*) z
  deallocate (z)
  allocate (z, source = non_abstract_child3 ("abc"))
  call assert (z)
  write (*,*) z
end

Boostraps and regtests OK.

Paul

[Bug fortran/44265] Link error with reference to parameter array in specification expression

[dominiq at lps dot ens.fr]

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

--- Comment #20 from Dominique d'Humieres  ---
Created attachment 40303
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40303&action=edit
Assembly for char_result_16 with -flto on darwin

[Bug fortran/44265] Link error with reference to parameter array in specification expression

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||iains at gcc dot gnu.org

--- Comment #21 from Dominique d'Humieres  ---
Note that the test gfortran.dg/char_result_17.f90 should be run only on target
supporting LTO.

[Bug fortran/44265] Link error with reference to parameter array in specification expression

[iains at gcc dot gnu.org]

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

--- Comment #22 from Iain Sandoe  ---
(In reply to Dominique d'Humieres from comment #20)
> Created attachment 40303 [details]
> Assembly for char_result_16 with -flto on darwin

It appears that two identical entries are present:

.section __GNU_LTO,__wrapper_sects,regular,debug
L_GNU_LTO4: ;# .gnu.lto___get_PROC_names.547da9c50a5f9b09
.set L$gnu$lto$offs4,L_GNU_LTO4-L_GNU_LTO0
.set L$gnu$lto$size4,L_GNU_LTO5-L_GNU_LTO4
.ascii "x\234cc``\250\1bI\6\10\230\302\314\270\254\377\322"
.ascii
"2vE\246\371\15\34s\230\301\2G\377\177?\300\337\315<\207\231\221\221\11\310\375z\352\352D\16E.\204\374\226#\307\333"
.ascii "8 \362\214@n_\347\372\277\\\212B\10\371k-s\205-\266"
.ascii "5t,h0\230\303\314\304\300\270\233Q\221q\27\243\14\343N
\275\3HogTd`\334\303h\301\300\356\233\230\227\236\257\240\300\356_\4d\244*\260;\26\24\344\244*(\0\0g\2-\203"
.text



.section __GNU_LTO,__wrapper_sects,regular,debug
L_GNU_LTO2: ;# .gnu.lto___get_PROC_names.547da9c50a5f9b09
.set L$gnu$lto$offs2,L_GNU_LTO2-L_GNU_LTO0
.set L$gnu$lto$size2,L_GNU_LTO3-L_GNU_LTO2
.ascii "x\234cc``\250\1bI\6\10\230\302\314\270\254\377\322"
.ascii
"2vE\246\371\15\34s\230\301\2G\377\177?\300\337\315<\207\231\221\221\11\310\375z\352\352D\16E.\204\374\226#\307\333"
.ascii "8 \362\214@n_\347\372\277\\\212B\10\371k-s\205-\266"
.ascii "5t,h0\230\303\314\304\300\270\233Q\221q\27\243\14\343N
\275\3HogTd`\334\303h\301\300\356\233\230\227\236\257\240\300\356_\4d\244*\260;\26\24\344\244*(\0\0g\2-\203"
.text

I assume that's not expected - so we need to determine why (i.e. if there
really are two coming in or if we've recorded something incorrectly)

[Bug fortran/44265] Link error with reference to parameter array in specification expression

[iains at gcc dot gnu.org]

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

--- Comment #23 from Iain Sandoe  ---
(In reply to Paul Thomas from comment #19)
> Created attachment 40286 [details]
> Failing testcases with -flto under Darwin
> 
> The PR is fixed under Linux but gives a link error under Darwin with -flto.
> From Dominique's message to the list on 7th December:
> The tests gfortran.dg/char_result_16.f90 and gfortran.dg/char_result_17.f90
> fail with
> 
> lto1: error: two or more sections for
> .gnu.lto___get_PROC_names.3e3ee55b08747e7c
> lto1: internal compiler error: cannot read LTO decls from
> /var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//ccEJosbA.o
> 
> This may be darwin specific as the linker is more picky than the linux one.

It might be Darwin-specific for a number of reasons:
 (a) Darwin doesn't use the linker plugin so there's a different code-path, 
 (b) we have to wrap the LTO sections to accommodate the limitation of 255
sections on darwin 
 (c) Something to do with missing symbol aliases 
 (d) something else ;-)

However, in this case it does not appear to be a Darwin linker issue;
the ICE is in lto1 - the only external Darwin tool involved at that point is
the assembler, and AFAICT the assembler is correctly rendering that there are
two instances in the input assembly (as posted by Dominique and as per the
complaint in the ICE).  Next thing is to figure out how/why we have those two
instances.

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

[iains at gcc dot gnu.org]

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

--- Comment #56 from Iain Sandoe  ---
Author: iains
Date: Sun Dec 11 16:01:35 2016
New Revision: 243524

URL: https://gcc.gnu.org/viewcvs?rev=243524&root=gcc&view=rev
Log:
[Darwin] Back-port fix for PR71767.

gcc/

2016-12-11  Iain Sandoe  

Backport from mainline
2016-11-27  Iain Sandoe  

PR target/71767
* config/darwin-sections.def (picbase_thunk_section): New.
* config/darwin.c (darwin_init_sections): Set up picbase thunk
section. (darwin_rodata_section, darwin_objc2_section,
machopic_select_section, darwin_asm_declare_constant_name,
darwin_emit_weak_or_comdat, darwin_function_section): Don’t use
coalesced with newer linkers.
(darwin_override_options): Decide on usage of coalesed sections
on the basis of the target linker version.
* config/darwin.h (MIN_LD64_NO_COAL_SECTS): New.
* config/darwin.opt  (mtarget-linker): New.
* config/i386/i386.c (ix86_code_end): Do not force the thunks into
a coalesced section, instead use a thunks section.

Backport from mainline
2016-11-28  Iain Sandoe  

PR target/71767
* configure.ac (with_ld64): Use portable method to extract the
major part of the version number.
* configure: Regenerated.

Backport from mainline
2016-11-27  Iain Sandoe  

PR target/71767
* configure.ac (with-ld64): New var, set for Darwin, set on
detection of ld64, gcc_cv_ld64_export_dynamic: New, New test.
* config/darwin.h: Use LD64_HAS_DYNAMIC export. DEF_LD64: New,
define.
* config/darwin10.h(DEF_LD64): Update for this target version.
* config/darwin12.h(LINK_GCC_C_SEQUENCE_SPEC): Remove rdynamic
test.  (DEF_LD64): Update for this target version.
* configure: Regenerated.
* config.in: Regenerated.

Backport from mainline
2016-11-27  Iain Sandoe  

PR target/71767
* config/darwin.c (imachopic_indirection_name): Make data
section indirections linker-visible.
* config/darwin.h (ASM_GENERATE_INTERNAL_LABEL): Make local
constant labels linker-visible.

gcc/testsuite/

2016-12-11  Iain Sandoe  

Backport from mainline
2016-11-27  Dominique d'Humieres  
Iain Sandoe  

PR target/71767
* g++.dg/abi/key2.C: Adjust for changed Darwin sections and
linker-visible symbols.
* g++.dg/torture/darwin-cfstring-3.C: Likewise.
* gcc.dg/const-uniq-1.c: Likewise.
* gcc.dg/torture/darwin-cfstring-3.c: Likewise.
* gcc.target/i386/pr70799-1.c: Likewise.



Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config.in
branches/gcc-6-branch/gcc/config/darwin-sections.def
branches/gcc-6-branch/gcc/config/darwin.c
branches/gcc-6-branch/gcc/config/darwin.h
branches/gcc-6-branch/gcc/config/darwin.opt
branches/gcc-6-branch/gcc/config/darwin10.h
branches/gcc-6-branch/gcc/config/darwin12.h
branches/gcc-6-branch/gcc/config/i386/i386.c
branches/gcc-6-branch/gcc/configure
branches/gcc-6-branch/gcc/configure.ac
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/testsuite/g++.dg/abi/key2.C
branches/gcc-6-branch/gcc/testsuite/g++.dg/torture/darwin-cfstring-3.C
branches/gcc-6-branch/gcc/testsuite/gcc.dg/const-uniq-1.c
branches/gcc-6-branch/gcc/testsuite/gcc.dg/torture/darwin-cfstring-3.c

[Bug target/57438] bootstrap fails on x86_64 darwin in stage2 linking cc1

[iains at gcc dot gnu.org]

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

--- Comment #32 from Iain Sandoe  ---
Author: iains
Date: Sun Dec 11 16:10:48 2016
New Revision: 243525

URL: https://gcc.gnu.org/viewcvs?rev=243525&root=gcc&view=rev
Log:
[Darwin] Back-port fix for PR57438.

gcc/

2016-12-11  Iain Sandoe  

Backport from mainline
2016-11-27  Iain Sandoe  

PR target/57438
* config/i386/i386.c (ix86_code_end): Note that we emitted code
where the function might otherwise appear empty for picbase thunks.
(ix86_output_function_epilogue): If we find a zero-sized function
assume that reaching it is UB and trap.  If we find a trailing label
append a nop.
* config/rs6000/rs6000.c (rs6000_output_function_epilogue): If we
find a zero-sized function assume that reaching it is UB and trap.
If we find a trailing label, append a nop.

gcc/testsuite/

2016-12-11  Iain Sandoe  

Backport from mainline
2016-11-27  Iain Sandoe  

PR target/57438
* gcc.dg/pr57438-1.c: New Test.
* gcc.dg/pr57438-2.c: New Test.


Added:
branches/gcc-6-branch/gcc/testsuite/gcc.dg/pr57438-1.c
branches/gcc-6-branch/gcc/testsuite/gcc.dg/pr57438-2.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/i386/i386.c
branches/gcc-6-branch/gcc/config/rs6000/rs6000.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/78725] [7 Regression] wrong code at -O3 on x86_64-linux-gnu (in both 32-bit and 64-bit modes)

[su at cs dot ucdavis.edu]

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

--- Comment #3 from Zhendong Su  ---
Below is another test that might trigger the same miscompilation: 

$ gcc-trunk -O2 -fsplit-loops small.c; ./a.out
Aborted (core dumped)
$   
$ gcc-trunk -O3 -fno-split-loops small.c; ./a.out
$ 
$ gcc-trunk -O3 small.c; ./a.out
Aborted (core dumped)
$ 
$ cat small.c
int a, b, c;

int main ()
{
  int d; 
  for (; c < 1; c++)
for (d = 0; d < 3; d++)
  for (b = 0; b < 1; b++)
if (c >= d) 
  a = 1;

  if (a != 1) 
__builtin_abort ();

  return 0; 
}
$ 
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20161211 (experimental) [trunk revision 243523] (GCC) 
$

[Bug target/67710] FAIL: gcc.dg/darwin-*version-*.c (test for excess errors) with Xcode 7

[iains at gcc dot gnu.org]

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

--- Comment #14 from Iain Sandoe  ---
Author: iains
Date: Sun Dec 11 16:23:04 2016
New Revision: 243526

URL: https://gcc.gnu.org/viewcvs?rev=243526&root=gcc&view=rev
Log:
[Darwin] Back-port fix for PR67710.

gcc/

2016-12-11  Iain Sandoe  

Backport from mainline
2016-11-27  Iain Sandoe  
Rainer Orth  

PR target/67710
* config.in: Regenerate
* config/darwin-driver.c (darwin_driver_init): Emit a version string
for the assembler.
* config/darwin.h(ASM_MMACOSX_VERSION_MIN_SPEC): New, new tests.
* config/darwin.opt(asm_macosx_version_min): New.
* config/i386/darwin.h: Handle ASM_MMACOSX_VERSION_MIN_SPEC.
* configure: Regenerate
* configure.ac: Check for mmacosx-version-min handling.

gcc/testsuite/

2016-12-11  Iain Sandoe  

Backport from mainline
2016-11-27  Iain Sandoe  
Rainer Orth  
Dominique d'Humieres  

PR target/67710
*  gcc.dg/darwin-minversion-1.c: Update min version check.
*  gcc.dg/darwin-minversion-2.c: Likewise.
*  gcc.dg/darwin-minversion-3.c: Likewise.

libgcc/

2016-12-11  Iain Sandoe  

Backport from mainline
2016-11-27  Iain Sandoe  
Rainer Orth  

PR target/67710
*  config/t-darwin: Default builds to 10.5 codegen.


Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config.in
branches/gcc-6-branch/gcc/config/darwin-driver.c
branches/gcc-6-branch/gcc/config/darwin.h
branches/gcc-6-branch/gcc/config/darwin.opt
branches/gcc-6-branch/gcc/config/i386/darwin.h
branches/gcc-6-branch/gcc/configure
branches/gcc-6-branch/gcc/configure.ac
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/testsuite/gcc.dg/darwin-minversion-1.c
branches/gcc-6-branch/gcc/testsuite/gcc.dg/darwin-minversion-2.c
branches/gcc-6-branch/gcc/testsuite/gcc.dg/darwin-minversion-3.c
branches/gcc-6-branch/libgcc/ChangeLog
branches/gcc-6-branch/libgcc/config/t-darwin

[Bug target/70118] UBSan claims misaligned access in SSE instrinsics

[uros at gcc dot gnu.org]

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

--- Comment #6 from uros at gcc dot gnu.org ---
Author: uros
Date: Sun Dec 11 16:27:08 2016
New Revision: 243527

URL: https://gcc.gnu.org/viewcvs?rev=243527&root=gcc&view=rev
Log:
PR target/70118
* config/i386/mmintrin.h (__m64_u): New type
* config/i386/emmintrin.h (_mm_loadl_epi64, _mm_storel_epi64):
Make the allowed unaligned memory access explicit.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/emmintrin.h
trunk/gcc/config/i386/mmintrin.h

[Bug fortran/66189] Block loops for inline matmul

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #4 from Thomas Koenig  ---
Now we have a blocking version for the library, do
you think we still need blocking in the front end?

[Bug fortran/66189] Block loops for inline matmul

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres  ---
> Now we have a blocking version for the library, do
> you think we still need blocking in the front end?

See comment 1. See also pr68600.

[Bug target/78695] [7 Regression] ICE (segfault) on powerpc64le-linux-gnu

[wschmidt at gcc dot gnu.org]

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

--- Comment #11 from Bill Schmidt  ---
Patch under test:

Index: gcc/config/rs6000/rs6000.c   
===
--- gcc/config/rs6000/rs6000.c  (revision 243506)   
+++ gcc/config/rs6000/rs6000.c  (working copy)  
@@ -41433,6 +41433,12 @@ find_alignment_op (rtx_insn *insn, rtx base_reg)
   if (!base_def_link || base_def_link->next)   
break;  

+  /* With stack-protector code enabled, and possibly in other  
+circumstances, there may not be an associated insn for 
+the def.  */   
+  if (!base_def_link->ref->base.insn_info) 
+   break;  
+   
   rtx_insn *and_insn = DF_REF_INSN (base_def_link->ref);   
   and_operation = alignment_mask (and_insn);   
   if (and_operation != 0)

[Bug fortran/29651] Subroutine: Kind convertion of intent(out) value: signal

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|NEW |WAITING
 CC||tkoenig at gcc dot gnu.org

--- Comment #10 from Thomas Koenig  ---
Is there anything left to fix?

A dump with recent trunk shows

   integer(kind=4) D.3468;

D.3468 = (integer(kind=4)) status2;
_gfortran_signal_sub_int (&i1, &i2, &D.3468);

[Bug fortran/50538] formal argument cannot be same as procedure name in ENTRY

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

   Last reconfirmed|2013-06-22 00:00:00 |2016-12-11
 CC||tkoenig at gcc dot gnu.org
Summary|formal argument cannot be   |formal argument cannot be
   |same as procedure name  |same as procedure name in
   |(r178939)   |ENTRY

--- Comment #2 from Thomas Koenig  ---
Still present in current trunk, adjusting subject a bit.

[Bug fortran/50542] gfortran should detect violation of Fortran 95 R536 (r178939)

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

   Last reconfirmed|2013-06-22 00:00:00 |2016-12-11
 CC||tkoenig at gcc dot gnu.org

--- Comment #2 from Thomas Koenig  ---
Still present.

[Bug fortran/78672] Gfortran test suite failures with a sanitized compiler

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
Created attachment 40304
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40304&action=edit
Results with the new patch.

Results with patch at https://gcc.gnu.org/ml/fortran/2016-12/msg00120.html.

[Bug c++/78771] New: Internal compiler error when using inherited constructors

[richardg.work at gmail dot com]

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

Bug ID: 78771
   Summary: Internal compiler error when using inherited
constructors
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: richardg.work at gmail dot com
  Target Milestone: ---

The code below generates an internal compiler error.

Godbolt : https://godbolt.org/g/kgkbqy

: In substitution of 'template D2::D2(U) [with U = int]':
:23:12:   required by substitution of 'template D2::D2(U)
[with U = int]'
:26:28:   required from here
:23:12: internal compiler error: in instantiate_template_1, at
cp/pt.c:16113
using D1::D1;
  ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

First observed on Fedora 22 (gcc 5.4.0 built from source)


template 
struct StrictType
{
  template 
  StrictType(U) = delete;

  constexpr StrictType(T t) : m_value(t) {}

  T m_value {};
};

struct D2;

struct D1 : StrictType
{
using StrictType::StrictType;
D1(D2);
};

struct D2 : D1
{
using D1::D1;
};

D1::D1(D2 v) : D1(v.m_value) {}

[Bug fortran/53957] Polyhedron 11 benchmark: MP_PROP_DESIGN twice as long as other compiler

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

   Last reconfirmed|2012-07-18 00:00:00 |2016-12-11

--- Comment #16 from Thomas Koenig  ---
Still present on current trunk:

fortran -Ofast -funroll-loops -march=native -mtune=native -fopt-info-vec
mp_prop_design.f90 
mp_prop_design.f90:1117:0: note: loop vectorized
mp_prop_design.f90:1117:0: note: loop vectorized
mp_prop_design.f90:1087:0: note: loop vectorized
mp_prop_design.f90:1060:0: note: loop vectorized
mp_prop_design.f90:1032:0: note: loop vectorized
mp_prop_design.f90:662:0: note: loop vectorized
mp_prop_design.f90:375:0: note: loop vectorized
mp_prop_design.f90:375:0: note: loop vectorized
mp_prop_design.f90:14:0: note: basic block vectorized

[Bug c++/78637] [7 Regression] ICE on invalid C++ code on x86_64-linux-gnu (internal compiler error: in pop_namespace, at cp/name-lookup.c:3826)

[paolo at gcc dot gnu.org]

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

--- Comment #3 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Sun Dec 11 18:15:31 2016
New Revision: 243529

URL: https://gcc.gnu.org/viewcvs?rev=243529&root=gcc&view=rev
Log:
/cp
2016-12-11  Paolo Carlini  

PR c++/78637
* parser.c (cp_parser_namespace_definition): Increment
nested_definition_count only if push_namespace succeeds.

/testsuite
2016-12-11  Paolo Carlini  

PR c++/78637
* g++.dg/parse/namespace14.C: New.

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

[Bug c++/78637] [7 Regression] ICE on invalid C++ code on x86_64-linux-gnu (internal compiler error: in pop_namespace, at cp/name-lookup.c:3826)

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #4 from Paolo Carlini  ---
Fixed.

[Bug fortran/29651] Subroutine: Kind convertion of intent(out) value: signal

[anlauf at gmx dot de]

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

--- Comment #11 from Harald Anlauf  ---
(In reply to Thomas Koenig from comment #10)
> Is there anything left to fix?
> 
> A dump with recent trunk shows
> 
>integer(kind=4) D.3468;
> 
> D.3468 = (integer(kind=4)) status2;
> _gfortran_signal_sub_int (&i1, &i2, &D.3468);

If you look further down in the dump, you'll see that
the result of the optional status argument is not
transferred to status2.  Unless I am missing something...

  {
integer(kind=4) D.3387;

D.3387 = (integer(kind=4)) status2;
_gfortran_signal_sub_int (&i1, &i2, &D.3387);
  }
  {
struct __st_parameter_dt dt_parm.1;

dt_parm.1.common.filename = &"xx.f90"[1]{lb: 1 sz: 1};
dt_parm.1.common.line = 9;
dt_parm.1.common.flags = 128;
dt_parm.1.common.unit = 6;
_gfortran_st_write (&dt_parm.1);
_gfortran_transfer_integer_write (&dt_parm.1, &status2, 2);
_gfortran_st_write_done (&dt_parm.1);
  }

Just add some -finit-integer=-42 to the flags and run the code.

[Bug fortran/66189] Block loops for inline matmul

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #6 from Jerry DeLisle  ---
(In reply to Thomas Koenig from comment #4)
> Now we have a blocking version for the library, do
> you think we still need blocking in the front end?

Is there much to be gained? For example 3x3 and 4x4 problem sets may be more
common than 6x6. Can we gain much by blocking these smaller arrays?

If we know of key applications that could benefit from further optimizations on
the smaller array sizes then we could consider it further. For now, I would
consider closing this PR and 68600

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

[uros at gcc dot gnu.org]

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

--- Comment #7 from uros at gcc dot gnu.org ---
Author: uros
Date: Sun Dec 11 18:59:07 2016
New Revision: 243530

URL: https://gcc.gnu.org/viewcvs?rev=243530&root=gcc&view=rev
Log:
PR target/70799
* config/i386/i386.c (dimode_scalar_to_vector_candidate_p)
: Consider all constant shifts.
Add FIXME comment.
(dimode_scalar_chain::compute_convert_gain): Reduce gain for
constant shifts larger or equal than 32.

testsuite/ChangeLog:

PR target/70799
* gcc.target/i386/pr70799-3.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr70799-3.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug target/47754] [missed optimization] AVX allows unaligned memory operands but GCC uses unaligned load and register operand

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #12 from Uroš Bizjak  ---
(In reply to Allan Jensen from comment #11)
> I think this one could probably be closed though.

Fixed.

[Bug rtl-optimization/71496] Two picbase loads created for libjava code on powerpc-darwin after rev 228022.

[iains at gcc dot gnu.org]

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

--- Comment #4 from Iain Sandoe  ---
Author: iains
Date: Sun Dec 11 19:24:46 2016
New Revision: 243532

URL: https://gcc.gnu.org/viewcvs?rev=243532&root=gcc&view=rev
Log:
[Darwin, PPC] Fix PR71496 by marking pic base loads as non-copyable.

The Darwin pic base loads (and reloads for non-local-gotos) are not
validly copied (since the pic base label would be duplicated).  Thus, 
mark the pic base {re-}loads as non-copyable.

gcc/

2016-12-11  Iain Sandoe  

PR rtl-optimization/71496
* config/rs6000/darwin.md (load_macho_picbase_si): Mark as non-
copyable.  (load_macho_picbase_di, reload_macho_picbase_si,
reload_macho_picbase_di): Likewise.



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

[Bug other/16519] -pthread undocumented

[sandra at gcc dot gnu.org]

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #3 from sandra at gcc dot gnu.org ---
Proposed doc patch that would categorize -pthread as a generic linker option. 
I think "GNU/Linux Options" is the wrong place because it's also supported by
all the BSD variants, Darwin, AIX64, HP-UX, plus x86 MinGW and Cygwin targets. 
If you think this is wrong, speak up.

https://gcc.gnu.org/ml/gcc-patches/2016-12/msg00966.html

[Bug middle-end/68733] [6/7 Regression] FAIL: libgomp.c/target-29.c (internal compiler error)

[danglin at gcc dot gnu.org]

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

--- Comment #12 from John David Anglin  ---
Work around installed:
https://gcc.gnu.org/ml/gcc-patches/2016-12/msg00967.html

[Bug middle-end/55814] Missed optimization with short-circuit evaluation of always evaluated comparisons/loads

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

   Last reconfirmed|2012-12-26 00:00:00 |2016-12-11

--- Comment #4 from Thomas Koenig  ---
Still present on current trunk.

[Bug middle-end/78606] [7 Regression] -Wformat-length/-fprintf-return-value incorrect for %+.0i and %.0o with zero value

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |7.0
Summary|-Wformat-length/-fprintf-re |[7 Regression]
   |turn-value incorrect for|-Wformat-length/-fprintf-re
   |%+.0i and %.0o with zero|turn-value incorrect for
   |value   |%+.0i and %.0o with zero
   ||value

[Bug fortran/78239] [5/6/7 Regression] ICE in char_len_param_value, at fortran/decl.c:926, with -fimplicit-none

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #4 from Thomas Koenig  ---
The namespace of the 

Program received signal SIGSEGV, Segmentation fault.
0x0067270d in char_len_param_value (expr=0x7fffd2d8,
deferred=) at ../../trunk/gcc/fortran/decl.c:926
warning: Source file is more recent than executable.
926   || e->symtree->n.sym->ns->parent->seen_implicit_none ==
1))
(gdb) p e
$1 = (gfc_expr *) 0x23523c0
(gdb) p e->symtree
$2 = (gfc_symtree *) 0x2350660
(gdb) p e->symtree->n.sym
$3 = (gfc_symbol *) 0x2351ba0
(gdb) p e->symtree->n.sym->ns
$4 = (gfc_namespace *) 0x23d1ab0
(gdb) p e->symtree->n.sym->ns->parent
$5 = (gfc_namespace *) 0x0

n is put into a namespace without a parent:

(gdb) p e->symtree->n.sym.name
$8 = 0x77503060 "n"

[Bug fortran/78239] [5/6/7 Regression] ICE in char_len_param_value, at fortran/decl.c:926, with -fimplicit-none

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #5 from Thomas Koenig  ---
Trivial patch:

Index: decl.c
===
--- decl.c  (Revision 243516)
+++ decl.c  (Arbeitskopie)
@@ -922,7 +922,8 @@ char_len_param_value (gfc_expr **expr, bool *defer

   if (!t && e->ts.type == BT_UNKNOWN
  && e->symtree->n.sym->attr.untyped == 1
- && (e->symtree->n.sym->ns->seen_implicit_none == 1
+ && (flag_implicit_none
+ || e->symtree->n.sym->ns->seen_implicit_none == 1
  || e->symtree->n.sym->ns->parent->seen_implicit_none == 1))
{
  gfc_free_expr (e);

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

[daniel.black at au dot ibm.com]

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

Daniel Black  changed:

   What|Removed |Added

 CC||daniel.black at au dot ibm.com

--- Comment #25 from Daniel Black  ---
*** Bug 78624 has been marked as a duplicate of this bug. ***

[Bug target/78624] [7 Regression] ICE (invalid rtl sharing) while doing a build

[daniel.black at au dot ibm.com]

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

Daniel Black  changed:

   What|Removed |Added

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

--- Comment #3 from Daniel Black  ---
32bit powerpc and powerpc64 builds are fixed. BE & LE.

Sorry the libgcc2.i source has been purged.

Thanks for the fix.

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

[Bug fortran/78737] [OOP] linking error with deferred, undefined user-defined derived-type I/O

[janus at gcc dot gnu.org]

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

--- Comment #10 from janus at gcc dot gnu.org ---
(In reply to Paul Thomas from comment #9)
> Created attachment 40302 [details]
> A workaround for the PR (even a patch?)
> 
> The attached allows this testcase to run as intended:

True, your patch makes gfortran accept the test case in comment #9 (probably
correctly), but AFAICS it does not fix the link-time error on comment 0 or 6.

[Bug fortran/78737] [OOP] linking error with deferred, undefined user-defined derived-type I/O

[janus at gcc dot gnu.org]

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

--- Comment #11 from janus at gcc dot gnu.org ---
(In reply to Paul Thomas from comment #8)
> (In reply to janus from comment #5)
> > 
> > module object_interface
> >   type :: object
> >   contains
> > procedure :: write_formatted
> > generic :: write(formatted) => write_formatted
> >   end type
> 
> Janus,
> 
> We interpreted the standard to imply that a SELECT TYPE is required in
> write_formatted to obtain the correct dtio io procedure.

Huh, that sounds quite surprising to me. Could you explain how you came to that
conclusion?

In my above example, 'write_formatted' is certainly a normal type-bound
procedure that can be called in a polymorphic context. Shouldn't the DTIO
generic binding be treated like any other typebound generic binding, meaning
that it should be resolved to a polymorphic typebound call in a write
statement?


> I did think about adding pointers to the procedures in the vtable but
> decided that the standard did not require it.

I don't think that's necessary anyway. We don't need any vtab entries for other
typebound generics either, since they are resolved to a specific typebound
procedure at compile-time. Therefore only vtab entries for specific TBPs are
required (which we have already of course) and no additional hooks should be
necessary for 'polymorphic DTIO', right?

[Bug fortran/78737] [OOP] linking error with deferred, undefined user-defined derived-type I/O

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #12 from Paul Thomas  ---
Created attachment 40305
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40305&action=edit
Patch for the PR

That attachment appears to fix the testcases of comments #6 and #9. This check
of comment #6 runs OK:

module object_interface
  type, abstract :: object
  contains
procedure(write_formatted_interface), deferred :: write_formatted
generic :: write(formatted) => write_formatted
  end type
  abstract interface
subroutine write_formatted_interface(this,unit,iotype,vlist,iostat,iomsg)
  import object
  class(object), intent(in) :: this
  integer, intent(in) :: unit
  character (len=*), intent(in) :: iotype
  integer, intent(in) :: vlist(:)
  integer, intent(out) :: iostat
  character (len=*), intent(inout) :: iomsg
end subroutine
  end interface
  type, extends(object) :: non_abstract_child
integer :: i
  contains
procedure :: write_formatted
  end type
contains
  subroutine write_formatted(this,unit,iotype,vlist,iostat,iomsg)
class(non_abstract_child), intent(in) :: this
integer, intent(in) :: unit
character (len=*), intent(in) :: iotype
integer, intent(in) :: vlist(:)
integer, intent(out) :: iostat
character (len=*), intent(inout) :: iomsg
select type (this)
  class is (non_abstract_child)
print *, this%i
  class default
print *, "Error"
end select
  end subroutine
  subroutine assert(a)
class(object):: a
write(*,*) a
  end subroutine
end module

  use object_interface
  class (object), allocatable :: z
  allocate (z, source = non_abstract_child (99))
  call assert (z)
end

The patch bootstraps and regtests OK. Will submit tomorrow.

Paul

[Bug target/78660] [7 Regression] 7.0 bootstrap fail on mips64el-unknow-linux: configure-stage2-target-libgcc' failed

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||build, wrong-code
 Target||mips64el-unkown-linux
  Component|bootstrap   |target
   Target Milestone|--- |7.0
Summary|7.0 bootstrap fail on   |[7 Regression] 7.0
   |mips64el-unknow-linux:  |bootstrap fail on
   |configure-stage2-target-lib |mips64el-unknow-linux:
   |gcc' failed |configure-stage2-target-lib
   ||gcc' failed

[Bug fortran/78737] [OOP] linking error with deferred, undefined user-defined derived-type I/O

[pault at gcc dot gnu.org]

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

--- Comment #13 from Paul Thomas  ---
(In reply to Paul Thomas from comment #12)
> Created attachment 40305 [details]
> Patch for the PR
> 
> That attachment appears to fix the testcases of comments #6 and #9. This
> check of comment #6 runs OK:
> 
> module object_interface
>   type, abstract :: object
>   contains
> procedure(write_formatted_interface), deferred :: write_formatted
> generic :: write(formatted) => write_formatted
>   end type
>   abstract interface
> subroutine write_formatted_interface(this,unit,iotype,vlist,iostat,iomsg)
>   import object
>   class(object), intent(in) :: this
>   integer, intent(in) :: unit
>   character (len=*), intent(in) :: iotype
>   integer, intent(in) :: vlist(:)
>   integer, intent(out) :: iostat
>   character (len=*), intent(inout) :: iomsg
> end subroutine
>   end interface
>   type, extends(object) :: non_abstract_child
> integer :: i
>   contains
> procedure :: write_formatted
>   end type
> contains
>   subroutine write_formatted(this,unit,iotype,vlist,iostat,iomsg)
> class(non_abstract_child), intent(in) :: this
> integer, intent(in) :: unit
> character (len=*), intent(in) :: iotype
> integer, intent(in) :: vlist(:)
> integer, intent(out) :: iostat
> character (len=*), intent(inout) :: iomsg
> select type (this)
>   class is (non_abstract_child)
> print *, this%i
>   class default
> print *, "Error"
> end select
>   end subroutine
>   subroutine assert(a)
> class(object):: a
> write(*,*) a
>   end subroutine
> end module
> 
>   use object_interface
>   class (object), allocatable :: z
>   allocate (z, source = non_abstract_child (99))
>   call assert (z)
> end
> 
> The patch bootstraps and regtests OK. Will submit tomorrow.
> 
> Paul

Sorry, should have had:
...snip...
  subroutine write_formatted(this,unit,iotype,vlist,iostat,iomsg)
class(object), intent(in) :: this
...snip...

Both versions work fine.

Paul

[Bug fortran/53957] Polyhedron 11 benchmark: MP_PROP_DESIGN twice as long as other compiler

[tkoenig at gcc dot gnu.org]

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

--- Comment #18 from Thomas Koenig  ---
Under Preferences/Email Preferences, you can select "Disable All Mail",
which should work and keep you from getting unwanted mail.

[Bug middle-end/78606] [7 Regression] -Wformat-length/-fprintf-return-value incorrect for %+.0i and %.0o with zero value

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

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

[Bug target/78695] [7 Regression] ICE (segfault) on powerpc64le-linux-gnu

[wschmidt at gcc dot gnu.org]

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

--- Comment #12 from Bill Schmidt  ---
Author: wschmidt
Date: Sun Dec 11 23:37:17 2016
New Revision: 243534

URL: https://gcc.gnu.org/viewcvs?rev=243534&root=gcc&view=rev
Log:
[gcc]

2016-12-11  Bill Schmidt  

PR target/78695
* config/rs6000/rs6000.c (find_alignment_op): Discard from
consideration any artificial definition.

[gcc/testsuite]

2016-12-11  Bill Schmidt  

PR target/78695
* gcc.target/powerpc/swaps-stack-protector.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/powerpc/swaps-stack-protector.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/testsuite/ChangeLog

[Bug target/78695] [7 Regression] ICE (segfault) on powerpc64le-linux-gnu

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

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

--- Comment #13 from Bill Schmidt  ---
Fixed.

[Bug tree-optimization/78450] strlen(s) return value can be assumed to be less than the size of s

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug fortran/78737] [OOP] linking error with deferred, undefined user-defined derived-type I/O

[damian at sourceryinstitute dot org]

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

--- Comment #14 from Damian Rouson  ---
Hi Paul,

Based on comment #12, I assume you no longer believe that type guarding is
required.  If I misinterpreted comment #12, please let me know. Otherwise,
please let me know what in the standard indicates that type guarding is
required.  I too would be surprised.

[Bug target/78660] [7 Regression] 7.0 bootstrap fail on mips64el-unknow-linux: configure-stage2-target-libgcc' failed

[paul.hua.gm at gmail dot com]

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

--- Comment #1 from Paul Hua  ---
The latest version r243504 still build fail.
The version r241773 can build successfully.