[Bug tree-optimization/25290] PHI-OPT could be rewritten so that is uses fold

[rguenther at suse dot de]

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

--- Comment #13 from rguenther at suse dot de  ---
On February 21, 2018 2:13:22 PM GMT+01:00, "egallager at gcc dot gnu.org"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25290
>
>Eric Gallager  changed:
>
>   What|Removed |Added
>
>   Keywords||patch
>   CC||egallager at gcc dot gnu.org
>
>--- Comment #11 from Eric Gallager  ---
>(In reply to Andrew Pinski from comment #10)
>> Note this needs at least:
>> https://gcc.gnu.org/ml/gcc-patches/2016-11/msg02837.html
>> 
>
>This was approved; has it been committed yet?


AFAIK no

[Bug fortran/84506] [6/7/8 Regression] INQUIRE(pos=) always sets pos=0 with -fdefault-integer-8

[jvdelisle at gcc dot gnu.org]

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

--- Comment #11 from Jerry DeLisle  ---
Tentative patch. Testing now. The intent originally was to prevent unit numbers
that don't fit into kind=4.  It use to be we had no negative unit numbers. With
newunit, now we do.

I need to see if this patch allows any invalid code.


diff --git a/gcc/fortran/trans-io.c b/gcc/fortran/trans-io.c
index 021c788ba54..36adb034475 100644
--- a/gcc/fortran/trans-io.c
+++ b/gcc/fortran/trans-io.c
@@ -639,12 +639,12 @@ set_parameter_value_inquire (stmtblock_t *block, tree
var,
   /* Don't evaluate the UNIT number multiple times.  */
   se.expr = gfc_evaluate_now (se.expr, );

-  /* UNIT numbers should be greater than zero.  */
+  /* UNIT numbers should be greater than the min.  */
   i = gfc_validate_kind (BT_INTEGER, 4, false);
+  val = gfc_conv_mpz_to_tree (gfc_integer_kinds[i].pedantic_min_int, 4);
   cond1 = build2_loc (input_location, LT_EXPR, logical_type_node,
  se.expr,
- fold_convert (TREE_TYPE (se.expr),
- integer_zero_node));
+ fold_convert (TREE_TYPE (se.expr), val));
   /* UNIT numbers should be less than the max.  */
   val = gfc_conv_mpz_to_tree (gfc_integer_kinds[i].huge, 4);
   cond2 = build2_loc (input_location, GT_EXPR, logical_type_node,

[Bug fortran/84506] [6/7/8 Regression] INQUIRE(pos=) always sets pos=0 with -fdefault-integer-8

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Keywords||wrong-code
  Known to work||4.9.3
   Target Milestone|--- |6.5
Summary|INQUIRE(pos=) always sets   |[6/7/8 Regression]
   |pos=0 with  |INQUIRE(pos=) always sets
   |-fdefault-integer-8 |pos=0 with
   ||-fdefault-integer-8
  Known to fail||5.5.0

--- Comment #10 from Dominique d'Humieres  ---
Gfortran 4.9.3 gives the expected results.

[Bug fortran/84506] INQUIRE(pos=) always sets pos=0 with -fdefault-integer-8

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #9 from Steve Kargl  ---
On Thu, Feb 22, 2018 at 03:30:01AM +, jvdelisle at gcc dot gnu.org wrote:
> 
> if (D.3772 < -some-reasonable-value || D.3772 > 2147483647)
>   {
> inquire_parm.3.common.unit = -3;
>   }
> _gfortran_st_inquire (_parm.3);
> 
> It could be something like -32768 simply because the check is to make sure the
> value used fits within kind=4 common.unit number.
> 

Is the range check intended as a guard of inquiring on
stderr, stdin, and stdout?

[Bug fortran/84506] INQUIRE(pos=) always sets pos=0 with -fdefault-integer-8

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #8 from Jerry DeLisle  ---
With iUnit as kind=4, the dump ford not have the check.

  {
struct __st_parameter_inquire inquire_parm.2;

inquire_parm.2.common.filename = &"pr84506.f90"[1]{lb: 1 sz: 1};
inquire_parm.2.common.line = 7;
inquire_parm.2.strm_pos_out = 
inquire_parm.2.common.flags = 8192;
inquire_parm.2.common.unit = iunit;
_gfortran_st_inquire (_parm.2);
  }

So we need to adjust the range check to include possible negative unit numbers.
In other words, change the test to:

if (D.3772 < -some-reasonable-value || D.3772 > 2147483647)
  {
inquire_parm.3.common.unit = -3;
  }
_gfortran_st_inquire (_parm.3);

It could be something like -32768 simply because the check is to make sure the
value used fits within kind=4 common.unit number.

[Bug fortran/84506] INQUIRE(pos=) always sets pos=0 with -fdefault-integer-8

[jvdelisle at gcc dot gnu.org]

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

--- Comment #7 from Jerry DeLisle  ---
The problem is not related to the newunit functions or neunit alloc stuff.

In the call to st_inquire we are passing the correct value of -10 for the unit
number.  However, the dump-original we have:

  {
struct __st_parameter_inquire inquire_parm.3;
integer(kind=8) D.3772;

inquire_parm.3.common.filename = &"pr84506.f90"[1]{lb: 1 sz: 1};
inquire_parm.3.common.line = 7;
inquire_parm.3.strm_pos_out = 
inquire_parm.3.common.flags = 8192;
inquire_parm.3.common.unit = (integer(kind=4)) iunit;
D.3772 = iunit;
if (D.3772 < 0 || D.3772 > 2147483647)
  {
inquire_parm.3.common.unit = -3;
  }
_gfortran_st_inquire (_parm.3);
  }

The test is checking the range to be within a kind=4 integer limits and we are
passing -3 to the inquire statement.

The correct unit number is -10 as provided by newunit.

(gdb) r
Starting program: /home/jerry/dev/test/pr84506/a.out 

Breakpoint 1, testinquire () at pr84506.f90:7
7  inquire(iUnit, pos=iPos)
(gdb) p iUnit
$2 = -10
(gdb) s
_gfortran_st_inquire (iqp=0x7fffd930)
at ../../../trunk/libgfortran/io/inquire.c:775
775   library_start (>common);
(gdb) p iqp->common.unit
$3 = -3

[Bug sanitizer/84508] Load of misaligned address using _mm_load_sd

[noloader at gmail dot com]

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

--- Comment #1 from Jeffrey Walton  ---
__m128d is a tad bit cleaner. It does not require the casts.

$ cat test.c
#include 
int main(int argc, char* argv[])
{
  unsigned char t[16+1];
  __m128d x = _mm_load_sd((const double *)(t+1));
  _mm_store_pd((double*)t, x);
  return 0;
}

$ gcc -fsanitize=undefined test.c -o test.exe

$ ./test.exe
/usr/lib/gcc/x86_64-linux-gnu/6/include/emmintrin.h:140:10: runtime error: load
of misaligned address 0x7ffd1cf2dd11 for type 'const double', which requires 8
byte alignment
0x7ffd1cf2dd11: note: pointer points here
 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00
00 00  c0 c8 e0 ba c4

[Bug sanitizer/84508] New: Load of misaligned address using _mm_load_sd

[noloader at gmail dot com]

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

Bug ID: 84508
   Summary: Load of misaligned address using _mm_load_sd
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: noloader at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

According to Intel
(https://software.intel.com/sites/landingpage/IntrinsicsGuide), there are no
alignment requirements for _mm_load_sd, _mm_store_sd and _mm_loaddup_pd. For
example, from _mm_load_sd:

  Description

Load a double-precision (64-bit) floating-point element from
memory into the lower of dst, and zero the upper element.
mem_addr does not need to be aligned on any particular boundary.

$ gcc --version
gcc (Debian 6.3.0-18) 6.3.0 20170516

$ cat test.c
#include 
int main(int argc, char* argv[])
{
  unsigned char t[16+1];
  __m128i x =  _mm_castpd_si128(_mm_load_sd((const double *)(t+1)));
  _mm_store_pd((double*)t, _mm_castsi128_pd(x));
  return 0;
}

$ gcc -fsanitize=undefined test.c -o test.exe

$ ./test.exe
/usr/lib/gcc/x86_64-linux-gnu/6/include/emmintrin.h:140:10: runtime error: load
of misaligned address 0x7ffc768309b1 for type 'const double', which requires 8
byte alignment
0x7ffc768309b1: note: pointer points here
 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  b0 79 38 ee ca 7f
00 00  98 7e 38 ee ca
  ^

[Bug fortran/84506] INQUIRE(pos=) always sets pos=0 with -fdefault-integer-8

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org
  Known to fail||6.4.1, 7.3.1, 8.0

--- Comment #6 from kargl at gcc dot gnu.org ---
Add Jerry to CC list.

[Bug fortran/84506] INQUIRE(pos=) always sets pos=0 with -fdefault-integer-8

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #5 from Steve Kargl  ---
On Thu, Feb 22, 2018 at 12:08:24AM +, sgk at troutmask dot
apl.washington.edu wrote:
> program TestInquire
>implicit none
>integer(8) :: iUnit
>integer(8) :: iPos
>open(newunit=iunit, file='output.txt', access='stream', status='replace')
>write(iUnit) 'TEXT'
>inquire(iUnit, pos=iPos)
>print *, iPos
> end program TestInquire
> 

It related to the automatic allocate of UNIT numbers with NEWUNIT.

If I do 

   iunit = 10
   open(unit=iunit, file='output.txt', access='stream', status='replace')

One gets the right answer.

Looking in io/inquire.c, one has 

void
st_inquire (st_parameter_inquire *iqp)
{
  gfc_unit *u;

  library_start (>common);

  if ((iqp->common.flags & IOPARM_INQUIRE_HAS_FILE) == 0)
{
  u = find_unit (iqp->common.unit);
  inquire_via_unit (iqp, u);
}

(gdb) p iqp->common
$1 = {flags = 8192, unit = 10, filename = 0x4a6180 "d.f90", line = 9, 
  iomsg_len = 4806240, iomsg = 0x2008d0010 "", iostat = 0xc}
(gdb) p u
$2 = (gfc_unit *) 0x200ce6f00

Now with newunit.

(gdb) p  iqp->common
$1 = {flags = 8192, unit = -3, filename = 0x4a6140 "d.f90", line = 9, 
  iomsg_len = 4806192, iomsg = 0x2008d0010 "", iostat = 0xc}
(gdb) p u
$2 = (gfc_unit *) 0x0

Whoops.  u = 0x0, then runs into line 228-229.

  if ((cf & IOPARM_INQUIRE_HAS_STRM_POS_OUT) != 0)
*iqp->strm_pos_out = (u != NULL) ? u->strm_pos : 0;

and there's your 0.

[Bug fortran/84506] INQUIRE(pos=) always sets pos=0 with -fdefault-integer-8

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #4 from Steve Kargl  ---
The problem is related to UNIT.

program TestInquire
   implicit none
   integer(4) :: iUnit
   integer(8) :: iPos
   open(newunit=iunit, file='output.txt', access='stream', status='replace')
   write(iUnit) 'TEXT'
   inquire(iUnit, pos=iPos)
   print *, iPos
end program TestInquire

The above gives the expected result.

program TestInquire
   implicit none
   integer(8) :: iUnit
   integer(8) :: iPos
   open(newunit=iunit, file='output.txt', access='stream', status='replace')
   write(iUnit) 'TEXT'
   inquire(iUnit, pos=iPos)
   print *, iPos
end program TestInquire

This gives the wrong result.

[Bug c++/84507] stack corruption

[justinpopo6 at gmail dot com]

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

Justin Chen  changed:

   What|Removed |Added

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

--- Comment #1 from Justin Chen  ---
Sorry web browser bugged out and created this...

[Bug c++/84507] New: stack corruption

[justinpopo6 at gmail dot com]

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

Bug ID: 84507
   Summary: stack corruption
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: justinpopo6 at gmail dot com
  Target Milestone: ---

[Bug middle-end/61118] [6/7/8 Regression] Indirect call generated for pthread_cleanup_push with constant cleanup function

[law at redhat dot com]

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

--- Comment #23 from Jeffrey A. Law  ---
Note that if we fix the abnormal handler to target the block after the setjmp
rather than the setjmp itself all the problems magically disappear.  That's
actually a more accurate CFG and arguably the right thing to do.

The concern is whether or not there are assumptions, particularly in the
gimple->rtl phase that fixing the CFG would break.

[Bug fortran/84506] INQUIRE(pos=) always sets pos=0 with -fdefault-integer-8

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #3 from Steve Kargl  ---
Upon closer inspection, gfortran's dump is correct
for both INTEGER and INTEGER(8) for 

program TestInquire
   integer :: iUnit, iPos
!  integer(8) :: iUnit, iPos
   open(newunit=iunit, file='output.txt', access='stream', status='replace')
   write(iUnit) 'TEXT'
   inquire(iUnit, pos=iPos)
   print *, iPos
end program TestInquire

INTEGER gives 5 and INTEGER(8) gives 0.

Looks like a Jerry issue. :)

[Bug c/66222] gcc error: invalid use of '__builtin_va_arg_pack ()' at -O2 and up & pass at noopt

[justinpopo6 at gmail dot com]

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

Justin Chen  changed:

   What|Removed |Added

 CC||justinpopo6 at gmail dot com

--- Comment #4 from Justin Chen  ---
Created attachment 43486
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43486=edit
Preprocessed File

Attached preprocessed c file.
I am having a similar error with this build command. (Compiles properly without
-Ox flag)

gcc -c -o av.o -DSPEC_CPU2000_NEED_BOOL -O1 av.c
In file included from /usr/include/stdio.h:936:0,
 from perlsdio.h:5,
 from iperlsys.h:203,
 from perl.h:325,
 from av.c:16:
/usr/include/x86_64-linux-gnu/bits/stdio2.h: In function ‘sprintf’:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:33:10: error: invalid use of
‘__builtin_va_arg_pack ()’
   return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
  ^
/usr/include/x86_64-linux-gnu/bits/stdio2.h: In function ‘snprintf’:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:64:10: error: invalid use of
‘__builtin_va_arg_pack ()’
   return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1,
  ^
/usr/include/x86_64-linux-gnu/bits/stdio2.h: In function ‘fprintf’:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:97:10: error: invalid use of
‘__builtin_va_arg_pack ()’
   return __fprintf_chk (__stream, __USE_FORTIFY_LEVEL - 1, __fmt,
  ^
/usr/include/x86_64-linux-gnu/bits/stdio2.h: In function ‘printf’:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:104:10: error: invalid use of
‘__builtin_va_arg_pack ()’
   return __printf_chk (__USE_FORTIFY_LEVEL - 1, __fmt, __va_arg_pack ());
  ^
/usr/include/x86_64-linux-gnu/bits/stdio2.h: In function ‘dprintf’:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:141:10: error: invalid use of
‘__builtin_va_arg_pack ()’
   return __dprintf_chk (__fd, __USE_FORTIFY_LEVEL - 1, __fmt,

gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
5.4.0-6ubuntu1~16.04.9' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-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
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.9)

[Bug c++/14710] Warning about useless casts

[redi at gcc dot gnu.org]

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

--- Comment #14 from Jonathan Wakely  ---
I guess because nobody asked for it.

[Bug c++/84453] [8 Regression] ICE in build_type_attribute_qual_variant, at attribs.c:1166

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
So fixed?

[Bug c++/84453] [8 Regression] ICE in build_type_attribute_qual_variant, at attribs.c:1166

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Author: jason
Date: Wed Feb 21 22:12:08 2018
New Revision: 257883

URL: https://gcc.gnu.org/viewcvs?rev=257883=gcc=rev
Log:
PR c++/84314 - ICE with templates and fastcall attribute.

* attribs.c (build_type_attribute_qual_variant): Remove assert.

Added:
trunk/gcc/testsuite/g++.dg/ext/attrib56.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/attribs.c

[Bug c++/84502] [8 Regression] Argument corruption when passing empty templated struct

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug fortran/84506] INQUIRE(pos=) always sets pos=0 with -fdefault-integer-8

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|WAITING |NEW
 CC||kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #1)
> Use
> 
>   integer(4) :: iUnit, iPos
> 
> -fdefault-integer-8 converts iUnit and iPos to integer(8) while open and
> inquire expect default integer, i.e., 4.
> 
> IMO this PR should be closed as INVALID.

There isn't a problem with OPEN.  The dump 
(removing clutter) looks like

testinquire ()
{
  integer(kind=8) ipos;
  integer(kind=8) iunit;

  {
struct __st_parameter_open open_parm.0;
integer(kind=4) newunit.1;

open_parm.0.newunit = 
_gfortran_st_open (_parm.0);
iunit = (integer(kind=8)) newunit.1;
  }

Here open uses a INTEGER(4) internally and assigns
to the promoted INTEGER(8).

The INQUIRE is however broken for POS, which looks like

  {
struct __st_parameter_inquire inquire_parm.3;
integer(kind=8) D.3764;
inquire_parm.3.strm_pos_out = 
inquire_parm.3.common.unit = (integer(kind=4)) iunit;
_gfortran_st_inquire (_parm.3);
  }
 }

inquire_parm.3.strm_pos_out is likely an INTEGER(4) and 
gfortran is passing a pointer to an INTEGER(8) ipos.

At one point in time, there was a warning that
-fdefault-integer-8 changes the ABI and possibly
causes problems with libgfortran.  I cannot find
the warning now.  Documentation states

'-fdefault-integer-8'
 Set the default integer and logical types to an
 8 byte wide type.

which means gfortran should compile and execute 
this code.  In fact, gfortran appears broken.

From F03, 9.9.1, R930 has

inquire-spec is [ UNIT = ] file-unit-number
 or POS = scalar-int-variable

Note that does not state scalar-default-int-variable.

Changing the original code to use INTEGER(8) instead of
using the -fdefault-integer-8 shows the same program.

[Bug tree-optimization/84505] [8 Regression] store-merging miscompilation on i586 in xemacs package starting with r254391

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
(In reply to Jakub Jelinek from comment #1)
> Might very well be a dup of PR84503, let me finish up the patch.

I hope so. According to description it looks very similar ;)

[Bug fortran/84506] INQUIRE(pos=) always sets pos=0 with -fdefault-integer-8

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-02-21
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Use

  integer(4) :: iUnit, iPos

-fdefault-integer-8 converts iUnit and iPos to integer(8) while open and
inquire expect default integer, i.e., 4.

IMO this PR should be closed as INVALID.

[Bug testsuite/83983] FAIL: g++.dg/lto/pr83121 (test for LTO warnings, pr83121_0.C line 8)

[sje at gcc dot gnu.org]

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

Steve Ellcey  changed:

   What|Removed |Added

 CC||sje at gcc dot gnu.org

--- Comment #3 from Steve Ellcey  ---
I tried digging into this some but was not able to come up with a fix.
I compared x86, which gives the expected error messages with aarch64
which gives different errors and tried to find out where they diverged.

I tracked it down to get_odr_type in ipa-devirt.c.  Just before:

  if (val->type != type
  && (!val->types_set || !val->types_set->add (type)))

I added this print statement:

  fprintf(stderr,"%p %p %p\n", (void *) type, (void *) val->type, (void *)
val->types_set);

On x86 I see:

0x7f98aa018dc8 0x7f98aa018930 (nil)
0x7f98aa0189d8 0x7f98aa018d20 (nil)
0x7f98aa0189d8 0x7f98aa018d20 0x32c9610
0x7f0222cbfc78 0x7f0222cbf9d8 (nil)
0x7f0222cbfa80 0x7f0222cbfa80 (nil)

On Aarch64 I see:

0x4002c859aaa0 0x4002c859a758 (nil)
0x4002c859a6b0 0x4002c859a6b0 (nil)
0x4002c859a6b0 0x4002c859a6b0 (nil)
0x4001f45aa9f8 0x4001f45aa758 (nil)
0x4001f45aa800 0x4001f45aa800 (nil)

I think the second line where type and val->type are the same
for Aarch64 but not for x86 is where the problem is but I am not 
sure why we have this difference.

I think it may be a bug in the odr hash function with an accidental
hash collision but I am not sure.

[Bug tree-optimization/84503] [7/8 Regression] store-merging miscompilation on powerpc64 with -O3 since r241789

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
In 7.x this exact problem doesn't really exist, so the issue must be different
there.
I'd think it might be something fixable by PR82916 - like patch, but haven't
actually tried that yet.

[Bug c++/84314] [8 Regression] Another ICE in finish_member_declaration

[jason at gcc dot gnu.org]

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

--- Comment #8 from Jason Merrill  ---
Author: jason
Date: Wed Feb 21 22:12:08 2018
New Revision: 257883

URL: https://gcc.gnu.org/viewcvs?rev=257883=gcc=rev
Log:
PR c++/84314 - ICE with templates and fastcall attribute.

* attribs.c (build_type_attribute_qual_variant): Remove assert.

Added:
trunk/gcc/testsuite/g++.dg/ext/attrib56.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/attribs.c

[Bug fortran/84506] New: INQUIRE(pos=) always sets pos=0 with -fdefault-integer-8

[albandil at atlas dot cz]

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

Bug ID: 84506
   Summary: INQUIRE(pos=) always sets pos=0 with
-fdefault-integer-8
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: albandil at atlas dot cz
  Target Milestone: ---

INQUIRE(pos=...) seems to set 'pos' to zero when the unit number is 64bit
integer. This can be illustrated on the following example, which writes four
characters to a stream file and then INQUIRES position:

  program TestInquire

  implicit none

  integer :: iUnit, iPos

  open(newunit=iunit, file='output.txt', access='stream',
position='append', form='unformatted')
  write(iUnit) 'TEXT'
  inquire(iUnit, pos=iPos)

  print *, iPos

  end program TestInquire

The expected output is '5', which can be obtained by compilation using the
command

  gfortran -ffree-form -std=f2008 inquire.f -o inquire

However, when the following command is used to compile the program, the output
is '0':

  gfortran -ffree-form -std=f2008 inquire.f -o inquire -fdefault-integer-8

Both 4-byte and 8-byte mode produce '5' when Intel Fortran Compiler 17.0.1 is
used,

  ifort -free -stand=f08 inquire.f -o inquire
  ifort -free -stand=f08 inquire.f -o inquire -i8

[Bug c/60083] Duplicate conversion warnings from negative integer to unsigned type (gcc-4.3 emits only one warning)

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||manu at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #5 from Manuel López-Ibáñez  ---

This probably got fixed when early folding was fixed:

gcc 8.0 -Wsign-conversion -Wparentheses -Wall -Wextra -Wconversion gives:

:3:48: warning: suggest parentheses around comparison in operand of '^'
[-Wparentheses]
   unsigned short s = ~0x4578ADBCAA1DE677LL ^ a == 0;
  ~~^~~~
:3:44: warning: unsigned conversion from 'long long int' to 'short
unsigned int' changes value from '-5005942011641849463' to '6537' [-Woverflow]
   unsigned short s = ~0x4578ADBCAA1DE677LL ^ a == 0;
  ~~^~~~

The fix-it notes for -Wparentheses and having some warnings enabled by default
would be nice, but they are a different topic altogether.

[Bug fortran/84504] procedure pointer variables cannot be initialized with functions returning pointers

[sriram at pobox dot com]

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

--- Comment #4 from Sriram Swaminarayan  ---
OK, I will admit that my knowledge here is pretty limited so if someone could
point out what I'm missing, I'd appreciate it.

On reading the other thread [PR45290] it appears it deals with pointers being
initialized with other pointers, be they procedure or data.  

This compile error has to do with not being able to deal with a specific return
type for a function (i.e. those functions that return pointers).  The return
type of a function should have no bearing on whether or not the initialization
should succeed.

[Bug c++/84502] [8 Regression] Argument corruption when passing empty templated struct

[patrick.schlangen at bmw dot de]

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

--- Comment #6 from patrick.schlangen at bmw dot de ---
(In reply to Jakub Jelinek from comment #5)
> Completely untested fix:

I've applied the patch and it seems to resolve the issue.
Thanks a lot!

[Bug c/80793] three signed conversion warnings for the same expression

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-21
 CC||manu at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #5 from Manuel López-Ibáñez  ---
(In reply to Martin Sebor from comment #0)

There are several issues conflated here.

> t.c: In function ‘f’:
> t.c:3:46: warning: signed and unsigned type in conditional expression
> [-Wsign-compare]
>unsigned char c = i ? (-__SCHAR_MAX__ - 1) : 1U;

This warning should be moved to where -Wsign-conversion is handled to avoid
emitting both.

The reason we cannot simply remove -Wsign-compare is because -Wsign-conversion
is not enabled by neither -Wall nor -Wextra, while -Wsign-compare is.

The reason -Wsign-conversion is not enabled by neither -Wall nor -Wextra is
because it has annoying false positives like PR40752. Clang doesn't have those.

> t.c:3:46: warning: negative integer implicitly converted to unsigned type
> [-Wsign-conversion]

This is same warning as Clang gives, just less informative than Clang's.
Printing the types should be easy.

> t.c:3:21: warning: conversion to ‘unsigned char’ alters ‘unsigned int’
> constant value [-Wconversion]
>unsigned char c = i ? (-__SCHAR_MAX__ - 1) : 1U;

This warning is a bug in my opinion. Probably the patch in PR40752 silences it.

[Bug c++/84489] [6/7/8 Regression] Non-type template parameter dependency

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||5.4.0
   Keywords||rejects-valid
   Last reconfirmed||2018-02-21
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|Non-type template parameter |[6/7/8 Regression] Non-type
   |dependency  |template parameter
   ||dependency
  Known to fail||6.4.0, 7.3.0, 8.0

--- Comment #1 from Martin Sebor  ---
The error is present with with the top of trunk.  The first revision that fails
to compile the code is r223301 (gcc 6.0.0).  It refers to DR 1391 but I'm not
sure that the DR has a bearing on whether the test case is valid.  Other
compilers including Clang, EDG, Intel ICC, and MSVC, successfully compile the
code so I'll confirm this report as valid on that basis.

r223301 | jason | 2015-05-18 13:14:11 -0400 (Mon, 18 May 2015) | 3 lines

DR 1391
* pt.c (type_unification_real): Check convertibility here.
(unify_one_argument): Not here.

[Bug fortran/84504] procedure pointer variables cannot be initialized with functions returning pointers

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #3 from Steve Kargl  ---
On Wed, Feb 21, 2018 at 09:15:24PM +, dominiq at lps dot ens.fr wrote:
>
> > This appears to be related to PR44290.
> 
> Are you sure about the PR?
> 

Argh, fat fingers!  r169948


r169948 | janus | 2011-02-08 14:51:04 -0800 (Tue, 08 Feb 2011) | 12 lines

2011-02-08  Janus Weil  

PR fortran/45290
* expr.c (gfc_check_assign_symbol): Reject pointers as pointer
initialization target.


2011-02-08  Janus Weil  

PR fortran/45290
* gfortran.dg/pointer_init_6.f90: New.

[Bug fortran/83149] [8 Regression] ICE on SELECT CASE: crash_signal in toplev.c:325

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org,
   ||tkoenig at gcc dot gnu.org

--- Comment #9 from Thomas Koenig  ---
I've done a bisection, and r255094 is the first revision that fails.

[Bug c/60018] Bogus conversion warning with optimization flag -O1

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

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

--- Comment #5 from Manuel López-Ibáñez  ---
(In reply to Eric Gallager from comment #4)
> bug 53277 perhaps?

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

[Bug c/53277] -Wconversion cannot handle compound expressions

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||chengniansun at gmail dot com

--- Comment #16 from Manuel López-Ibáñez  ---
*** Bug 60018 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/84480] [8 Regression] bogus -Wstringop-truncation despite assignment with an inlined string literal

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #3 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2018-02/msg01247.html

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

[manu at gcc dot gnu.org]

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

Bug 80787 Summary: gcc -Wmaybe-uninitialized false negative when compiling Emacs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80787

   What|Removed |Added

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

[Bug c/80787] gcc -Wmaybe-uninitialized false negative when compiling Emacs

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||manu at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #3 from Manuel López-Ibáñez  ---
(In reply to Marc Glisse from comment #1)
> This is a DUP of many other PRs, -fno-tree-ccp -fno-tree-vrp gives you the
> warning, but otherwise gcc optimises cond?value:undef to value.

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

[Bug tree-optimization/18501] [6/7/8 Regression] Missing 'used uninitialized' warning (CCP)

[manu at gcc dot gnu.org]

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

--- Comment #83 from Manuel López-Ibáñez  ---
*** Bug 80787 has been marked as a duplicate of this bug. ***

[Bug fortran/84504] procedure pointer variables cannot be initialized with functions returning pointers

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-02-21
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
> This appears to be related to PR44290.

Are you sure about the PR?

[Bug fortran/84504] procedure pointer variables cannot be initialized with functions returning pointers

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
This appears to be related to PR44290.

There is a fairly long discussion.  The conclusion in that PR
suggests that you example is invalid.  I'm not so sure that
is correct.

The EBNF in F2018, 10.2.2 to me seems to permit what
you are trying to do, but I don't use pointers so would
need to spend too much time unraveling the subtleties.

[Bug c++/84502] [8 Regression] Argument corruption when passing empty templated struct

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
Completely untested fix:

--- gcc/stor-layout.c.jj2018-02-13 21:23:29.187981310 +0100
+++ gcc/stor-layout.c   2018-02-21 21:43:24.783522853 +0100
@@ -1883,6 +1883,9 @@ finalize_type_size (tree type)
   && TREE_CODE (TYPE_SIZE_UNIT (type)) != INTEGER_CST)
 TYPE_SIZE_UNIT (type) = variable_size (TYPE_SIZE_UNIT (type));

+  /* Handle empty records as per the x86-64 psABI.  */
+  TYPE_EMPTY_P (type) = targetm.calls.empty_record_p (type);
+
   /* Also layout any other variants of the type.  */
   if (TYPE_NEXT_VARIANT (type)
   || type != TYPE_MAIN_VARIANT (type))
@@ -1895,6 +1898,7 @@ finalize_type_size (tree type)
   unsigned int precision = TYPE_PRECISION (type);
   unsigned int user_align = TYPE_USER_ALIGN (type);
   machine_mode mode = TYPE_MODE (type);
+  bool empty_p = TYPE_EMPTY_P (type);

   /* Copy it into all variants.  */
   for (variant = TYPE_MAIN_VARIANT (type);
@@ -1911,11 +1915,9 @@ finalize_type_size (tree type)
  SET_TYPE_ALIGN (variant, valign);
  TYPE_PRECISION (variant) = precision;
  SET_TYPE_MODE (variant, mode);
+ TYPE_EMPTY_P (variant) = empty_p;
}
 }
-
-  /* Handle empty records as per the x86-64 psABI.  */
-  TYPE_EMPTY_P (type) = targetm.calls.empty_record_p (type);
 }

 /* Return a new underlying object for a bitfield started with FIELD.  */

[Bug tree-optimization/83543] strlen of a local array member not optimized on some targets

[msebor at gcc dot gnu.org]

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

--- Comment #6 from Martin Sebor  ---
(In reply to Martin Sebor from comment #5)

The cutoff between (a) and (b) also depends on whether or not a function is
being optimized for speed or for size, so at -Os, the x86_64 target also uses
(b) for all sizes.

Here's a test case and its output with an x86_64 compiler:

$ cat t.c && gcc -S -Wall -fdump-tree-optimized=/dev/stdout t.c
#pragma GCC optimize ("O2")
int f (void)
{
  struct A { char a[4]; } a = { "123" };
  return __builtin_strlen (a.a);
}

#pragma GCC optimize ("Os")
int g (void)
{
  struct B { char b[4]; } b = { "123" };
  return __builtin_strlen (b.b);
}

;; Function f (f, funcdef_no=0, decl_uid=1957, cgraph_uid=0, symbol_order=0)

__attribute__((optimize ("O2")))
f ()
{
   [local count: 1073741825]:
  return 3;

}



;; Function g (g, funcdef_no=1, decl_uid=1963, cgraph_uid=1, symbol_order=1)

__attribute__((optimize ("O2", "Os")))
g ()
{
  struct B b;
  long unsigned int _1;
  int _4;

   [local count: 1073741825]:
  b.b = "123";
  _1 = __builtin_strlen ();
  _4 = (int) _1;
  b ={v} {CLOBBER};
  return _4;

}

[Bug c++/14710] Warning about useless casts

[bje at gcc dot gnu.org]

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

Ben Elliston  changed:

   What|Removed |Added

 CC||bje at gcc dot gnu.org

--- Comment #13 from Ben Elliston  ---
Is there a reason this option doesn't extend to the C frontend?  The same
problem with useless static_casts occurs with conventional C casts, too.

[Bug c/46921] Lost side effect when struct initializer expression uses comma operator

[dave.pagan at oracle dot com]

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

Dave Pagan  changed:

   What|Removed |Added

Summary|Dropped side effect with|Lost side effect when
   |combination of statement|struct initializer
   |expression and struct   |expression uses comma
   |initializer |operator

--- Comment #3 from Dave Pagan  ---
When emitting initializer elements (output_init_element), the left hand
expression of a comma operator with result size zero is not evaluated. It
should be, however, if the expression is marked as having side effects.

[Bug c++/43064] improve location and text of diagnostics in constructor initializer lists

[lopezibanez at gmail dot com]

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

--- Comment #6 from Manuel López-Ibáñez  ---
If I remember correctly, the problem here is constants and other
non-expression nodes don't have a location, so diagnostics use
input_location, which points to the end of the initializer. Something like
X+1 should work.

If so, David started fixing this problem, but this code may need fixes
similar to these:  https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00660.html

Otherwise, the problem is more insidious, and the nodes are probably built
with the wrong location.

[Bug tree-optimization/84505] [8 Regression] store-merging miscompilation on i586 in xemacs package starting with r254391

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Liška  ---
I can confirm https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84503#c3 fixes the
issue, thus it's dup.
Great work Jakub!

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

[Bug c++/84502] [8 Regression] Argument corruption when passing empty templated struct

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Regressed with r255066

[Bug tree-optimization/84503] [7/8 Regression] store-merging miscompilation on powerpc64 with -O3 since r241789

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
*** Bug 84505 has been marked as a duplicate of this bug. ***

[Bug target/69770] [ARM] -mlong-calls does not affect calls to __gnu_mcount_nc generated by -pg

[mkuvyrkov at gcc dot gnu.org]

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

--- Comment #4 from Maxim Kuvyrkov  ---
Update from Charles:
===
When I tried to bootstrap the compiler with the patch, it failed because of
issues with -fPIC. I'm not sure it's worth pursuing the amount of work required
to resolve the -fPIC issue.
===

[Bug middle-end/65041] Improve -Wclobbered

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||law at redhat dot com
 Resolution|DUPLICATE   |---

--- Comment #6 from Jeffrey A. Law  ---
The warning on a2 is clearly bogus.  ISTM we ought to get a warning on fd, but
don't because it's associated DECL_RTL is not set.

It almost feels like instead of walking over the variables in the blocks we
ought to iterate over the pseudos and check which of them map back to user
variables via REG_EXPR.

I'm going to re-open -- this is not entirely a duplicate of 21161 as there's a
missed warning here.

[Bug tree-optimization/84503] [7/8 Regression] store-merging miscompilation on powerpc64 with -O3 since r241789

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 43485
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43485=edit
gcc8-pr84503.patch

Untested fix.

[Bug c/84229] A valid code rejected with -flto

[hubicka at gcc dot gnu.org]

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

--- Comment #5 from Jan Hubicka  ---
Author: hubicka
Date: Wed Feb 21 19:05:30 2018
New Revision: 257877

URL: https://gcc.gnu.org/viewcvs?rev=257877=gcc=rev
Log:
PR c/84229
* ipa-cp.c (determine_versionability): Do not version functions caling
va_arg_pack.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-cp.c

[Bug fortran/70913] ICE in gfc_encode_character, at fortran/target-memory.c:227

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
AFAICT the tests in comment 0 and 1 compile at revision r257865, but compiling
the test z4.f90 still gives an ICE.

[Bug c/84500] diagnostic says "array of chars" for arrays of wchar_t, char16_t and char32_t

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-21
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Sebor  ---
Confirmed.  I think the warning would be the most informative and the least
vague if it instead used the name of the array type, and also mentioned the
size of the initializer in case it's hidden behind a macro:

  warning: initializer-string for an object of 'wchar_t[3]' has 5 elements

as long as there is a way to get at the name of the typedef.  Otherwise,
printing the underlying type would be an alternative.

[Bug c++/77285] [5 Regression] extern thread_local linkage

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||zhykzhykzhyk at gmail dot com

--- Comment #15 from Jonathan Wakely  ---
*** Bug 66971 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/83543] strlen of a local array member not optimized on some targets

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
(In reply to Ramana Radhakrishnan from comment #4)

Setting -march=armv7-a doesn't make a difference.

The root cause is that initializers of locally defined aggregates such as

  struct { char a[N]; } S s = { "12345" };

are represented in one of two ways in GIMPLE:

a) as an assignment of the string to s.a, or
b) as a copy from a label (e.g., 's = *.LC0')

and the strlen pass only knows how to deal with (a) but not (b).

AFAICS, whether form (a) or form (b) is chosen depends on the size of the size
of the aggregate.  Some targets use a lower threshold for (b) than others.  As
far as I can see, x86_64 appears to cut over at 257 bytes, while arm-none-eabi
always uses (b).

[Bug fortran/83148] [8 regression] ICE: crash_signal from toplev.c:325

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #5 from Paul Thomas  ---
(In reply to Thomas Koenig from comment #4)
> Reverting the resolve.c part of r254427 makes the problem go away.

It's the second part of the patch to resolve.c that offends. Clearly, the
possession of a iso_bind_c type component is the problem.

I will investigate more on Friday, when I have some time.

Paul

[Bug middle-end/61118] [6/7/8 Regression] Indirect call generated for pthread_cleanup_push with constant cleanup function

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|DUPLICATE   |---

--- Comment #22 from Jeffrey A. Law  ---
I don't think this is a duplicate of 21161.

AFAICT the core of the problem here is the multiple static assignments to the
pseudos holding cancel_arg and cancel_routine.

They set the objects to the same value, but the multiple-assignment nature is a
key aspect of the longjmp clobbering analysis.

I think the multiple assignment largely steps from the PHIs in this block:

;;   basic block 5, loop depth 0, count 536656163 (estimated locally), maybe
hot
;;prev block 4, next block 6, flags: (NEW, REACHABLE, IRREDUCIBLE_LOOP,
VISITED)
;;pred:   4 [always (guessed)]  count:268328082 (estimated locally)
(FALLTHRU,IRREDUCIBLE_LOOP,EXECUTABLE)
;;6 [always (guessed)]  count:1716613 (estimated locally)
(ABNORMAL,DFS_BACK,IRREDUCIBLE_LOOP,EXECUTABLE)
;;3 [50.0% (guessed)]  count:268328082 (estimated locally)
(IRREDUCIBLE_LOOP,FALSE_VALUE,EXECUTABLE)
  # __cancel_routine_9(ab) = PHI 
  # __cancel_arg_12(ab) = PHI <_1(4), __cancel_arg_13(ab)(6), _1(3)>
  _24 = __sigsetjmp (&__cancel_buf.__cancel_jmp_buf, 0);
  goto ; [99.96%]


This happens in CCP1 and FRE1 for cancel_routine and cancel_arg respectively.
(replacinging a cancel_{arg,routine} with an equivalent).   Once replaced, it's
exceedingly hard to undo.  One could easily argue that we shouldn't to the
replacement in an abnormal PHI.

Regardless, this is separate from 21161.  There is a slim chance that fixing
21161 is a requirement to fix this BZ, but they are not duplicates AFAICT.

[Bug fortran/83980] Various issues with character length in array constructors

[dominiq at lps dot ens.fr]

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

--- Comment #6 from Dominique d'Humieres  ---
> The fix for pr83823 seems to have fixed the problems reported in
> comment #0 and comment #2 for 8.0 trunk.  The issues persist up to
> 7.2 (haven't checked 7.3).

Confirmed.

[Bug tree-optimization/84505] [8 Regression] store-merging miscompilation on i586 in xemacs package starting with r254391

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Might very well be a dup of PR84503, let me finish up the patch.

[Bug target/69770] [ARM] -mlong-calls does not affect calls to __gnu_mcount_nc generated by -pg

[mkuvyrkov at gcc dot gnu.org]

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

Maxim Kuvyrkov  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
 CC||mkuvyrkov at gcc dot gnu.org
   Assignee|cbaylis at gcc dot gnu.org |unassigned at gcc dot 
gnu.org

[Bug c++/66971] thread_local with external linkage and constructor cannot be compiled correctly

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
It was fixed on trunk by r242607 i.e. PR c++/77285

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

[Bug tree-optimization/84505] New: [8 Regression] store-merging miscompilation on i586 in xemacs package starting with r254391

[marxin at gcc dot gnu.org]

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

Bug ID: 84505
   Summary: [8 Regression] store-merging miscompilation on i586 in
xemacs package starting with r254391
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

I'm still reducing the test-case, but with:

$ gcc -O2 -m32 alloc.i -funroll-loops -fdump-tree-optimized=/tmp/bad.txt -c -o
/tmp/bad.s -S -fno-strict-aliasing

I see following difference in tree-optimized dump:

$ diff -u /tmp/good.txt /tmp/bad.txt -U20
--- /tmp/good.txt   2018-02-21 19:15:26.081205161 +0100
+++ /tmp/bad.txt2018-02-21 19:23:04.898349760 +0100
@@ -9831,50 +9831,49 @@

 free_marker (Lisp_Object ptr)
 {
   struct Lisp_Marker * FFT_ptr;
   struct Lisp_Free * marker_free_list.705_1;
   long int consing_since_gc.706_2;
   long unsigned int consing_since_gc.707_3;
   long unsigned int _4;
   long int _5;
   long unsigned int total_consing.708_6;
   long unsigned int _7;
   int profiling_active.709_8;
   int gc_count_num_marker_freelist.711_10;
   int _11;
   long int prephitmp_31;
   long int pretmp_40;

[local count: 1431]:
   FFT_ptr_15 = (struct Lisp_Marker *) ptr_14(D);
   unchain_marker (ptr_14(D));
-  MEM[(unsigned int *)FFT_ptr_15] = 3735928559;
-  MEM[(unsigned int *)FFT_ptr_15 + 4B] = 3735928559;
   MEM[(unsigned int *)FFT_ptr_15 + 8B] = 3735928559;
   MEM[(unsigned int *)FFT_ptr_15 + 12B] = 3735928559;
   MEM[(unsigned int *)FFT_ptr_15 + 16B] = 3735928559;
   MEM[(unsigned int *)FFT_ptr_15 + 20B] = 3735928559;
   marker_free_list.705_1 = marker_free_list;
   MEM[(struct Lisp_Free *)FFT_ptr_15].chain = marker_free_list.705_1;
   marker_free_list = FFT_ptr_15;
-  MEM[(struct lrecord_header *)FFT_ptr_15].type = 69;
+  MEM[(void *)FFT_ptr_15] = 3735928389;
+  MEM[(unsigned int *)FFT_ptr_15 + 4B] = 3735928559;
   consing_since_gc.706_2 = consing_since_gc;
   consing_since_gc.707_3 = (long unsigned int) consing_since_gc.706_2;
   _4 = consing_since_gc.707_3 + 4294967272;
   _5 = (long int) _4;
   consing_since_gc = _5;
   total_consing.708_6 = total_consing;
   _7 = total_consing.708_6 + 4294967272;
   total_consing = _7;
   profiling_active.709_8 = profiling_active;
   if (profiling_active.709_8 != 0)
 goto ; [33.00%]
   else
 goto ; [67.00%]

[local count: 472]:
   profile_record_unconsing (24);
   pretmp_40 = consing_since_gc;

[local count: 1429]:
   # prephitmp_31 = PHI 

I suspect later 2 stores:
+  MEM[(void *)FFT_ptr_15] = 3735928389;
+  MEM[(unsigned int *)FFT_ptr_15 + 4B] = 3735928559;

which overwrite:
MEM[(struct Lisp_Free *)FFT_ptr_15].chain = marker_free_list.705_1;

It's probably connected with aliasing analysis that allows store motion after
the *.chain store.

[Bug c/70186] RFE: better handling of misspelled attributes

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=82914

--- Comment #4 from Martin Sebor  ---
See also bug 82914 that points out cases where GCC silently ignores all
attributes, misspelled or otherwise.  (It's a different problem than this one
and the solutions are different as well.)

[Bug tree-optimization/84480] [8 Regression] bogus -Wstringop-truncation despite assignment with an inlined string literal

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
Summary|Unexpected  |[8 Regression] bogus
   |-Wstringop-truncation on|-Wstringop-truncation
   |strncpy with string literal |despite assignment with an
   |at -O2  |inlined string literal

[Bug tree-optimization/84480] Unexpected -Wstringop-truncation on strncpy with string literal at -O2

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-21
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Sebor  ---
Thanks for the test case.  The root cause is the same as in bug 84474.  The
warnings in both of these test cases are issued in gimple-fold.c (see
gimple_fold_builtin_strncpy), long before the code in tree-ssa-strlen.c has
run.

The difference between this case and the one in bug 84474 is that here the next
statement is already available.  With that, I think there may be a way to avoid
the subset of the warnings in this report.

[Bug tree-optimization/84503] [7/8 Regression] store-merging miscompilation on powerpc64 with -O3 since r241789

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
The bug is in the way we handle overlapping stores.  The problem is that all we
do if there is overlap is:
  if (IN_RANGE (info->bitpos, merged_store->start,
merged_store->start + merged_store->width - 1))
{
  /* Only allow overlapping stores of constants.  */
  if (info->rhs_code == INTEGER_CST
  && merged_store->stores[0]->rhs_code == INTEGER_CST)
{
  merged_store->merge_overlapping (info);
  continue;
}
}
otherwise we:
  /* |---store 1---|  |---store 2---|.
 Gap between stores or the rhs not compatible.  Start a new group.  */

  /* Try to apply all the stores recorded for the group to determine
 the bitpattern they write and discard it if that fails.
 This will also reject single-store groups.  */
  if (!merged_store->apply_stores ())
delete merged_store;
  else
m_merged_store_groups.safe_push (merged_store);

  merged_store = new merged_store_group (info);
But the statements here are sorted primarily by bitpos and we emit statements
for the group at the location of the last statement (highest order) in the
merged store group.  So I think we need to check before adding another store if
it is not rhs_code INTEGER_CST, whether there is any overlap with following
stores.  Overlap is fine if the order of all the overlapping statements is
higher than MAX (merged_store->last_order, info->order), because then we know
we'll start a new group right after info and the merged stores of the current
group will come before any overlapping stores (whether merged successfully with
something or not), but otherwise we just shouldn't add info into the current
group.

[Bug c++/84502] [8 Regression] Argument corruption when passing empty templated struct

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #3 from Marek Polacek  ---
This might be the reason why building Chromium gn fails (I hope).  Related:
PR84286

[Bug c++/45431] specify the field for initializer-string for array of chars is too long

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Because the C front end gets the location info right in recent versions of GCC
it also marks the bad initializer with carets:

bug.c:4:3: warning: initializer-string for array of chars is too long
   "Christopher",
   ^
bug.c:4:3: note: (near initialization for 'sc_me.name')
bug.c:5:3: warning: initializer-string for array of chars is too long
   "Yeleighton" };
   ^~~~
bug.c:5:3: note: (near initialization for 'sc_me.surname')

This is ideal, as it shows both the bad initializer, and the field it's trying
to initialize.

[Bug c++/43064] improve location and text of diagnostics in constructor initializer lists

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #5 from Jonathan Wakely  ---
In this similar case the C front end gets the location right, and also prints a
note with the name of the field:

#include 
struct X { int i; int j; };
struct X x = {
  NULL,
  2
};

$ gcc -Wall s.c -c
s.c:4:3: warning: initialization makes integer from pointer without a cast
[-Wint-conversion]
   NULL,
   ^~~~
s.c:4:3: note: (near initialization for ‘x.i’)

$ g++ -Wall s.c -c
s.c:6:1: warning: converting to non-pointer type ‘int’ from NULL
[-Wconversion-null]
 };
 ^

[Bug c++/84502] [8 Regression] Argument corruption when passing empty templated struct

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||ABI
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-21
  Known to work||7.3.0
Summary|Argument corruption when|[8 Regression] Argument
   |passing empty templated |corruption when passing
   |struct  |empty templated struct
 Ever confirmed|0   |1
  Known to fail||8.0.1

--- Comment #2 from Jonathan Wakely  ---
This is caused by -fabi-version=12 (which is the default for GCC 8). You can
get the old handling of empty structs with -fabi-version=11

The bug only seems to happen when the empty struct is a class template.

Reduced, this fails at -O0 but not any other optimization level, or with
-fabi-version=11:

template
struct EmptyTemplatedStruct { };

using X = EmptyTemplatedStruct;

void func(X, int a1, int a2, int a3, int a4, int a5, int a6, int a7, int a8)
{
  if (a1 != 0)
__builtin_abort();
  if (a2 != 1)
__builtin_abort();
  if (a3 != 2)
__builtin_abort();
  if (a4 != 3)
__builtin_abort();
  if (a5 != 4)
__builtin_abort();
  if (a6 != 5)
__builtin_abort();
  if (a7 != 6)
__builtin_abort();
  if (a8 != 7)
__builtin_abort();
}

int main()
{
  func(X{}, 0, 1, 2, 3, 4, 5, 6, 7);
}

[Bug c++/84502] [8 Regression] Argument corruption when passing empty templated struct

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||wrong-code
   Target Milestone|--- |8.0

[Bug tree-optimization/84503] [7/8 Regression] store-merging miscompilation on powerpc64 with -O3 since r241789

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Can be reproduced also on x86_64-linux with -O3 -fno-tree-vectorize
-fno-ivopts.

For the latter, I wonder what's the point in using TARGET_MEM_REF in:
  MEM[(long int *)p_28] = 0;
  MEM[(long int *)p_28 + 8B] = 0;
  MEM[(long int *)p_28 + 16B] = 0;
  MEM[(long int *)p_28 + 24B] = 0;
  MEM[(long int *)p_28 + 32B] = 0;
  MEM[(long int *)p_28 + 40B] = 0;
  MEM[(long int *)p_28 + 48B] = 0;
, isn't that something that MEM_REF can express too?  store-merging doesn't
handle TARGET_MEM_REFs and only handles MEM_REFs.  So, for stage1 shall it
handle also TARGET_MEM_REFs that only have base and optionally constant disp
and nothing else, or shall ivopts pass instead just generate MEM_REFs in those
cases?

[Bug c++/84491] Multiple inheritance and covariant return types causes internal compiler error

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-21
 CC||dmalcolm at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from David Malcolm  ---
Confirmed.

It's failing this assertion in method.c:

96/* Likewise, we can only be adding thunks to a function declared in
97   the class currently being laid out.  */
98gcc_assert (TYPE_SIZE (DECL_CONTEXT (function))
99&& TYPE_BEING_DEFINED (DECL_CONTEXT (function)));

[Bug c++/84492] [8 Regression] ICE with statement expression

[dmalcolm at gcc dot gnu.org]

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

--- Comment #2 from David Malcolm  ---
This assertion is failing, where rhs is a STMT_EXPR.

8000  /* There are only a few kinds of expressions that may have a type
8001 dependent on overload resolution.  */
8002  gcc_assert (TREE_CODE (rhs) == ADDR_EXPR
8003  || TREE_CODE (rhs) == COMPONENT_REF
8004  || is_overloaded_fn (rhs)
8005  || (flag_ms_extensions && TREE_CODE (rhs) ==
FUNCTION_DECL));

[Bug c++/84492] [8 Regression] ICE with statement expression

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-21
 CC||dmalcolm at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from David Malcolm  ---
Confirmed.

Started with r253599.

[Bug fortran/84495] Incorrect result for concatenation of Fortran allocatable string

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #4 from Steve Kargl  ---
On Wed, Feb 21, 2018 at 10:44:07AM +, tkoenig at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84495
> 
> Thomas Koenig  changed:
> 
>What|Removed |Added
> 
>  CC||tkoenig at gcc dot gnu.org
> 
> --- Comment #2 from Thomas Koenig  ---
> This looks like a duplicate of PR81116, fixed by r251125.
> 
> This is not a regression, and in genereal (we have played loose with
> this rule) we are not supposed to backport.
> 
> Opinions?
> 

Release Manager would probably say that it is up the Fortran
Maintainers on whether something should be backported.  If I
have a patch on trunk that applies to the branch(es) with
minimum effort, I tend to backport to keep code in sync.

[Bug fortran/84504] New: procedure pointer variables cannot be initialized with functions returning pointers

[sriram at pobox dot com]

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

Bug ID: 84504
   Summary: procedure pointer variables cannot be initialized with
functions returning pointers
   Product: gcc
   Version: 6.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sriram at pobox dot com
  Target Milestone: ---

Also occurs on gcc 7.2.0 - not tried on other version.

procedure pointer variables pointing initialized with functions returning
pointers fail to compile.  Note that the sample code below compiles if we
change the function type to not be a pointer.


Source:
module test_procedure_pointer
  implicit none
  private
  procedure(the_proc), pointer  :: ptr => the_proc
contains
  function the_proc() 
integer, pointer :: the_proc
  end function the_proc
end module test_procedure_pointer

Error:
   procedure(the_proc), pointer  :: ptr => the_proc
  1
Error: Pointer initialization target at (1) must have the TARGET attribute


save-temps:
sn-fey1[1-290] gfortran -v -save-temps ~/procpointer.f90
Driving: gfortran -v -save-temps /users/sriram/procpointer.f90 -l gfortran -l m
-shared-libgcc
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/yellow/usr/projects/hpcsoft/toss3/common/gcc/6.4.0/bin/../libexec/gcc/x86_64-pc-linux-gnu/6.4.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-6.4.0/configure
--prefix=/usr/projects/hpcsoft/toss3/common/gcc/6.4.0 --enable-threads=posix
--enable-__cxa_atexit --enable-lto --enable-checking=release --disable-multilib
--enable-languages=c,c++,fortran
Thread model: posix
gcc version 6.4.0 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'

/yellow/usr/projects/hpcsoft/toss3/common/gcc/6.4.0/bin/../libexec/gcc/x86_64-pc-linux-gnu/6.4.0/f951
/users/sriram/procpointer.f90 -quiet -dumpbase procpointer.f90 -mtune=generic
-march=x86-64 -auxbase procpointer -version -fintrinsic-modules-path
/yellow/usr/projects/hpcsoft/toss3/common/gcc/6.4.0/bin/../lib/gcc/x86_64-pc-linux-gnu/6.4.0/finclude
-o procpointer.s
GNU Fortran (GCC) version 6.4.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 6.4.0, GMP version 4.3.2, MPFR version 2.4.2,
MPC version 0.8.1, isl version 0.15
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran2008 (GCC) version 6.4.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 6.4.0, GMP version 4.3.2, MPFR version 2.4.2,
MPC version 0.8.1, isl version 0.15
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
/users/sriram/procpointer.f90:4:50:

   procedure(the_proc), pointer  :: ptr => the_proc
  1
Error: Pointer initialization target at (1) must have the TARGET attribute

[Bug go/84484] libgo configure tests fail to find -latomic

[sch...@linux-m68k.org]

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

--- Comment #16 from Andreas Schwab  ---
Created attachment 43484
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43484=edit
libgo support for riscv64

With this patch I can sucessfully build libgo for riscv64.

[Bug c++/84502] Argument corruption when passing empty templated struct

[patrick.schlangen at bmw dot de]

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

--- Comment #1 from patrick.schlangen at bmw dot de ---
Note: This problem does not happen with gcc 7.2.1.

The problem can also be reproduced with -O3 when the empty struct object passed
to the function is actually used in the function. (So it is not optimized out.)

[Bug tree-optimization/84503] [7/8 Regression] store-merging miscompilation on powerpc64 with -O3 since r241789

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-02-21
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

[Bug tree-optimization/84503] New: [7/8 Regression] store-merging miscompilation on powerpc64 with -O3 since r241789

[jakub at gcc dot gnu.org]

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

Bug ID: 84503
   Summary: [7/8 Regression] store-merging miscompilation on
powerpc64 with -O3 since r241789
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

typedef __SIZE_TYPE__ size_t;
typedef __UINTPTR_TYPE__ uintptr_t;

struct S { int a; unsigned short b; int c, d, e; long f, g, h; int i, j; };
static struct S *k;
static size_t l = 0;
int m;

static int
bar (void)
{
  unsigned i;
  int j;
  if (k[0].c == 0)
{
  ++m;
  size_t n = l * 2;
  struct S *o;
  o = (struct S *) __builtin_realloc (k, sizeof (struct S) * n);
  if (!o)
__builtin_exit (0);
  k = o;
  for (i = l; i < n; i++)
{
  void *p = (void *) [i];
  int q = 0;
  size_t r = sizeof (struct S);
  if uintptr_t) p) % __alignof__ (long)) == 0
  && r % sizeof (long) == 0)
{
  long __attribute__ ((may_alias)) *s = (long *) p;
  long *t = (long *) ((char *) s + r);
  while (s < t)
*s++ = 0;
}
  else
__builtin_memset (p, q, r);
  k[i].c = i + 1;
  k[i].a = -1;
}
  k[n - 1].c = 0;
  k[0].c = l;
  l = n;
}
  j = k[0].c;
  k[0].c = k[j].c;
  return j;
}

int
main ()
{
  k = (struct S *) __builtin_malloc (sizeof (struct S));
  if (!k)
__builtin_exit (0);
  __builtin_memset (k, '\0', sizeof (struct S));
  k->a = -1;
  l = 1;
  for (int i = 0; i < 15; ++i)
bar ();
  if (m != 4)
__builtin_abort ();
  return 0;
}

is miscompiled with -O3 starting with r241789.  The bug can be seen when
diffing store_merging dump with the previous one:
--- rh1547495.c.192t.widening_mul   2018-02-21 17:25:00.049972838 +0100
+++ rh1547495.c.193t.store-merging  2018-02-21 17:25:00.049972838 +0100
@@ -1,6 +1,10 @@

 ;; Function main (main, funcdef_no=1, decl_uid=2691, cgraph_uid=1,
symbol_order=4) (executed once)

+Coalescing successful!
+Merged into 2 stores
+New sequence of 2 stmts to replace old one of 3 stmts
+Merging successful!
 main ()
 {
   unsigned int i;
@@ -120,8 +124,6 @@ main ()
 goto ; [57.11%]

[local count: 510973054]:
-  MEM[(long int *)p_28] = 0;
-  MEM[(long int *)p_28 + 8B] = 0;
   MEM[(long int *)p_28 + 16B] = 0;
   MEM[(long int *)p_28 + 24B] = 0;
   MEM[(long int *)p_28 + 32B] = 0;
@@ -130,7 +132,8 @@ main ()
   _14 = i_31 + 1;
   _119 = (int) _14;
   MEM[(struct S *)p_28].c = _119;
-  MEM[(struct S *)p_28].a = -1;
+  MEM[(void *)p_28] = 18446744069414584320;
+  MEM[(long int *)p_28 + 8B] = 0;
   _111 = (long unsigned int) _14;
   if (n_21 > _111)
 goto ; [89.00%]

MEM[(void *)p_28] = 18446744069414584320;
is fine, that stores 0x into the first 8 bytes, but
MEM[(struct S *)p_28].c = _119;
stores 4 bytes at offset 8 and MEM[(long int *)p_28 + 8B] = 0;
overwrites it.

[Bug c++/84502] New: Argument corruption when passing empty templated struct

[patrick.schlangen at bmw dot de]

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

Bug ID: 84502
   Summary: Argument corruption when passing empty templated
struct
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick.schlangen at bmw dot de
  Target Milestone: ---

Created attachment 43483
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43483=edit
Minimal example

Hi,

we've discovered a strange problem when passing many function arguments where
one argument is an alias (using = ...) for a templated struct which has no
members (e.g. std::integer_sequence).

When building in non-optimized mode or with -O1/-O2, all arguments starting
from argument #7 seem to be corrupt. Building with -O3 seems to solve the
issue.

I've attached a small example program.

Correct output:
---

$ ~/gcc-8/bin/g++ -O3 -o repro repro.cpp && ./repro
0, 1, 2, 3, 4, 5, 6, 7


Wrong outputs:
--

$ ~/gcc-8/bin/g++ -O2 -o repro repro.cpp && ./repro
0, 1, 2, 3, 4, 5, 7, 0

$ ~/gcc-8/bin/g++ -O1 -o repro repro.cpp && ./repro
0, 1, 2, 3, 4, 5, 7, 0

$ ~/gcc-8/bin/g++ -O0 -o repro repro.cpp && ./repro
0, 1, 2, 3, 4, 5, 7, 2088590376


gcc version (freshly built):


$ ~/gcc-8/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/home/patrick/gcc-8/bin/g++
COLLECT_LTO_WRAPPER=/home/patrick/gcc-8/libexec/gcc/x86_64-pc-linux-gnu/8.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ./configure --prefix=/home/patrick/gcc-8 --disable-multilib
Thread model: posix
gcc version 8.0.1 20180218 (experimental) (GCC) 

Best Regards

Patrick

[Bug tree-optimization/83126] [8 Regression] ICE in transform_to_exit_first_loop_alt, at tree-parloops.c:1713

[vries at gcc dot gnu.org]

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

--- Comment #9 from Tom de Vries  ---
(In reply to Tom de Vries from comment #8)
> Created attachment 43476 [details]
> Tentative patch
> 
> (In reply to rguent...@suse.de from comment #3)
> 
> > This is the usual "you should not repeat analysis during transform" issue.
> > The vectorizer gets around this by caching relevant scalar evolution
> > but obviously that's difficult if using generic stuff like
> > canonicalize_loop_ivs ...
> 
> This patch caches affine_iv info before calling loop_version, and then uses
> that cached info in canonicalize_loop_ivs. This fixes the ICE.

Bootstrap and reg-test on x86_64 succeeded.

Richard, is this approach ok for stage1 and/or stage4?

[Bug c/16351] NULL dereference warnings

[msebor at gcc dot gnu.org]

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

--- Comment #56 from Martin Sebor  ---
I'd say any warning option with more than just a handful of pr's against it
would benefit from having a meta-bug.

[Bug go/84484] libgo configure tests fail to find -latomic

[ian at airs dot com]

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

--- Comment #15 from Ian Lance Taylor  ---
> The first hunk is useless since this is a compile test.

Understood, but I would prefer to test the exact options that the build is
going to use.

[Bug target/84264] [8 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:10367 starting with r256656

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|kelvin at gcc dot gnu.org  |bergner at gcc dot 
gnu.org

--- Comment #5 from Peter Bergner  ---
I'm looking into this.

[Bug go/84484] libgo configure tests fail to find -latomic

[sch...@linux-m68k.org]

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

--- Comment #14 from Andreas Schwab  ---
See gcc/config/riscv/linux.h for why it does that.

[Bug go/84484] libgo configure tests fail to find -latomic

[sch...@linux-m68k.org]

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

--- Comment #13 from Andreas Schwab  ---
The first hunk is useless since this is a compile test.

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

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #23 from Thomas Koenig  ---
Let's close it then.

Thanks for the bug report!

[Bug tree-optimization/25290] PHI-OPT could be rewritten so that is uses fold

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords|patch   |

--- Comment #12 from Andrew Pinski  ---
(In reply to Eric Gallager from comment #11)
> (In reply to Andrew Pinski from comment #10)
> > Note this needs at least:
> > https://gcc.gnu.org/ml/gcc-patches/2016-11/msg02837.html
> > 
> 
> This was approved; has it been committed yet?

Yes. That patch was applied. But that patch is only a support patch and not the
full patch to fix this.  I was actually going to working on this again but it
won't go in until gcc 9.

[Bug c++/84434] [8 Regression] internal compiler error: tree check: expected var_decl or field_decl or function_decl or type_decl or template_decl, have using_decl in build_deduction_guide, at cp/pt.c

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||jakub at gcc dot gnu.org

[Bug c++/84447] [8 Regression] ICE with inherited deleted constructor and default argument

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug go/84484] libgo configure tests fail to find -latomic

[ian at airs dot com]

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

--- Comment #12 from Ian Lance Taylor  ---
How about this patch?

diff --git a/libgo/configure b/libgo/configure
index aba4dc39..dcfc524b 100755
--- a/libgo/configure
+++ b/libgo/configure
@@ -14209,7 +14209,7 @@ if test "${libgo_cv_lib_pthread+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   CFLAGS_hold=$CFLAGS
-CFLAGS="$CFLAGS -pthread"
+CFLAGS="$CFLAGS -pthread -L../libatomic/.libs"
 cat confdefs.h - <<_ACEOF >conftest.$ac_ext
 /* end confdefs.h.  */
 int i;
@@ -14226,7 +14226,8 @@ fi
 $as_echo "$libgo_cv_lib_pthread" >&6; }
 PTHREAD_CFLAGS=
 if test "$libgo_cv_lib_pthread" = yes; then
-  PTHREAD_CFLAGS=-pthread
+  # RISC-V apparently adds -latomic when using -pthread.
+  PTHREAD_CFLAGS="-pthread -L../libatomic/.libs"
 fi


diff --git a/libgo/configure.ac b/libgo/configure.ac
index 1264a1d2..1f49aee9 100644
--- a/libgo/configure.ac
+++ b/libgo/configure.ac
@@ -493,14 +493,15 @@ dnl Test whether the compiler supports the -pthread
option.
 AC_CACHE_CHECK([whether -pthread is supported],
 [libgo_cv_lib_pthread],
 [CFLAGS_hold=$CFLAGS
-CFLAGS="$CFLAGS -pthread"
+CFLAGS="$CFLAGS -pthread -L../libatomic/.libs"
 AC_COMPILE_IFELSE([[int i;]],
 [libgo_cv_lib_pthread=yes],
 [libgo_cv_lib_pthread=no])
 CFLAGS=$CFLAGS_hold])
 PTHREAD_CFLAGS=
 if test "$libgo_cv_lib_pthread" = yes; then
-  PTHREAD_CFLAGS=-pthread
+  # RISC-V apparently adds -latomic when using -pthread.
+  PTHREAD_CFLAGS="-pthread -L../libatomic/.libs"
 fi
 AC_SUBST(PTHREAD_CFLAGS)

[Bug c/16351] NULL dereference warnings

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=71157,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=84315,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=84316

--- Comment #55 from Eric Gallager  ---
Related: bug 71157, bug 84315, and bug 84316

(should this be a meta-bug for all issues with -Wnull-dereference? In which
case I should be putting those under "Depends on" instead of "See Also"...)

[Bug target/82096] [6 Regression] ICE in int_mode_for_mode, at stor-layout.c:403 with arm-linux-gnueabi

[sudi at gcc dot gnu.org]

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

sudi at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #14 from sudi at gcc dot gnu.org ---
Backported to gcc-6

[Bug c++/84454] [8 Regression] ICE in invalid_nonstatic_memfn_p at gcc/cp/typeck.c:1882

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #1 from Jason Merrill  ---
Author: jason
Date: Wed Feb 21 14:25:54 2018
New Revision: 257875

URL: https://gcc.gnu.org/viewcvs?rev=257875=gcc=rev
Log:
PR c++/84454 - ICE with pack expansion in signature.

* error.c (find_typenames_r): Also stop on EXPR_PACK_EXPANSION.

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

--- Comment #2 from Jason Merrill  ---
Fixed.

[Bug c++/84454] [8 Regression] ICE in invalid_nonstatic_memfn_p at gcc/cp/typeck.c:1882

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #1 from Jason Merrill  ---
Author: jason
Date: Wed Feb 21 14:25:54 2018
New Revision: 257875

URL: https://gcc.gnu.org/viewcvs?rev=257875=gcc=rev
Log:
PR c++/84454 - ICE with pack expansion in signature.

* error.c (find_typenames_r): Also stop on EXPR_PACK_EXPANSION.

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

--- Comment #2 from Jason Merrill  ---
Fixed.