[Bug tree-optimization/66272] [4.9/5/6 Regression] wrong code at -O3 on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |4.9.3
Summary|[4.9.2/5/6 Regression]  |[4.9/5/6 Regression] wrong
   |wrong code at -O3 on|code at -O3 on
   |x86_64-linux-gnu|x86_64-linux-gnu

[Bug middle-end/66148] [6 regression] build/genpreds: Internal error: abort in choose_enum_order, at genpreds.c:1006

[thopre01 at gcc dot gnu.org]

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

Thomas Preud'homme  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-05-25
   Assignee|unassigned at gcc dot gnu.org  |thopre01 at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Thomas Preud'homme  ---
The patch set out to use information from REG_EQUAL notes to get more accurate
nonzero_bits value. When compiling the testcase with commit r223033 (the one
just before the bug is seen) and options -O2 -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables I can see:

(insn 360 358 361 27 (set (reg:DI 549)
(const_int -822083584 [0xcf00]))
../../gcc/gcc/genpreds.c:983 123 {*pa.md:4196}
 (expr_list:REG_EQUAL (const_int 3472883712 [0xcf00])
(nil)))

Here the REG_EQUAL does not match the value that is set: the 32 most
significant bits are zero. Which is why combine decide that the set of
zero_extract can be removed. Looking at the dumps of the various pass,
everything looks fine until cse1 where instruction 360 is replaced from:

(insn 360 359 361 32 (set (reg:DI 549)
(lo_sum:DI (reg:DI 550)
(const_int -822083584 [0xcf00])))
../../gcc/gcc/genpreds.c:983 93 {*pa.md:2773}
 (expr_list:REG_EQUAL (const_int 3472883712 [0xcf00])
(nil)))

to:

(insn 360 359 361 32 (set (reg:DI 549)
(const_int -822083584 [0xcf00]))
../../gcc/gcc/genpreds.c:983 123 {*pa.md:4196}
 (expr_list:REG_DEAD (reg:DI 550)
(expr_list:REG_EQUAL (const_int 3472883712 [0xcf00])
(nil

without the REG_EQUAL note being updated. The replacement is made by the else
if in cse.c with the following comment:

/* Look for a substitution that makes a valid insn.  */

I'm not sure what component is at fault here (my guess is that cse is not
expected to update the note directly but probably some other function) and I am
thus not very sure who to reassign this bug to.

[Bug tree-optimization/66272] [4.9/5/6 Regression] wrong code at -O3 on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Started with r214006.

[Bug middle-end/66276] [5/6 Regression] internal compiler error: in get_loop_body, at cfgloop.c:856

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |5.2
Summary|[5 regression] internal |[5/6 Regression] internal
   |compiler error: in  |compiler error: in
   |get_loop_body, at   |get_loop_body, at
   |cfgloop.c:856   |cfgloop.c:856

--- Comment #2 from Jakub Jelinek  ---
Started with r211625.

[Bug inline-asm/66274] gcc6: x86 -m32 emits 64bit register in inline asm

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-05-25
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

--- Comment #1 from Uroš Bizjak  ---
Oops.

--cut here--
Index: config/i386/i386.c
===
--- config/i386/i386.c  (revision 223641)
+++ config/i386/i386.c  (working copy)
@@ -15229,7 +15229,7 @@ print_reg (rtx x, int code, FILE *file)
 case 8:
 case 4:
   if (LEGACY_INT_REGNO_P (regno))
-   putc (msize == 8 ? 'r' : 'e', file);
+   putc (msize == 8 && TARGET_64BIT ? 'r' : 'e', file);
 case 16:
 case 12:
 case 2:
--cut here--

[Bug c/66277] New: [regression] cpp-5: fatal error: too many input files

[paulepanter at users dot sourceforge.net]

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

Bug ID: 66277
   Summary: [regression] cpp-5: fatal error: too many input files
   Product: gcc
   Version: 5.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: paulepanter at users dot sourceforge.net
  Target Milestone: ---

With Debian Sid/unstable, trying to build GRUB master with GCC 5.1.1 fails with
the error `cpp-5: fatal error: too many input files`.

$ cpp-5 --version
cpp-5 (Debian 5.1.1-7) 5.1.1 20150522
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.

$ git clone git://git.savannah.gnu.org/grub.git
$ cd grub
$ git describe
grub-2.02-beta2-420-g5e74a3e
$ ./autogen.sh
$ CC=gcc-5 CPP=cpp-5 ./configure --with-platform=coreboot
$ make
cpp-5 -DHAVE_CONFIG_H -I.  -Wall -W -DGRUB_UTIL=1
-D_FILE_OFFSET_BITS=64 -I./include -DGRUB_FILE=\"grub_script.tab.h\" -I. -I.
-I. -I. -I./include -I./include -I./grub-core/lib/libgcrypt-grub/src/ 
-I./grub-core/lib/minilzo -I./grub-core/lib/xzembed -DMINILZO_HAVE_CONFIG_H
-Wall -W -DGRUB_UTIL=1 -D_FILE_OFFSET_BITS=64 -I./include
-DGRUB_FILE=\"grub_script.tab.h\" -I. -I. -I. -I. -I./include -I./include
-I./grub-core/lib/libgcrypt-grub/src/  -I./grub-core/gnulib
-I./grub-core/gnulib -D_FILE_OFFSET_BITS=64 \
  -D'GRUB_MOD_INIT(x)=@MARKER@x@' grub_script.tab.h grub_script.yy.h
grub-core/commands/blocklist.c grub-core/commands/macbless.c
grub-core/commands/xnu_uuid.c grub-core/commands/testload.c
grub-core/commands/ls.c grub-core/disk/dmraid_nvidia.c
grub-core/disk/loopback.c grub-core/disk/lvm.c grub-core/disk/mdraid_linux.c
grub-core/disk/mdraid_linux_be.c grub-core/disk/mdraid1x_linux.c
grub-core/disk/raid5_recover.c grub-core/disk/raid6_recover.c
grub-core/font/font.c grub-core/gfxmenu/font.c grub-core/normal/charset.c
grub-core/video/fb/fbblit.c grub-core/video/fb/fbutil.c
grub-core/video/fb/fbfill.c grub-core/video/fb/video_fb.c
grub-core/video/video.c grub-core/video/capture.c grub-core/video/colors.c
grub-core/unidata.c grub-core/io/bufio.c grub-core/fs/affs.c grub-core/fs/afs.c
grub-core/fs/bfs.c grub-core/fs/btrfs.c grub-core/fs/cbfs.c
grub-core/fs/archelp.c grub-core/fs/cpio.c grub-core/fs/cpio_be.c
grub-core/fs/odc.c grub-core/fs/newc.c grub-core/fs/ext2.c grub-core/fs/fat.c
grub-core/fs/exfat.c grub-core/fs/fshelp.c grub-core/fs/hfs.c
grub-core/fs/hfsplus.c grub-core/fs/hfspluscomp.c grub-core/fs/iso9660.c
grub-core/fs/jfs.c grub-core/fs/minix.c grub-core/fs/minix2.c
grub-core/fs/minix3.c grub-core/fs/minix_be.c grub-core/fs/minix2_be.c
grub-core/fs/minix3_be.c grub-core/fs/nilfs2.c grub-core/fs/ntfs.c
grub-core/fs/ntfscomp.c grub-core/fs/reiserfs.c grub-core/fs/romfs.c
grub-core/fs/sfs.c grub-core/fs/squash4.c grub-core/fs/tar.c grub-core/fs/udf.c
grub-core/fs/ufs2.c grub-core/fs/ufs.c grub-core/fs/ufs_be.c grub-core/fs/xfs.c
grub-core/fs/zfs/zfscrypt.c grub-core/fs/zfs/zfs.c grub-core/fs/zfs/zfsinfo.c
grub-core/fs/zfs/zfs_lzjb.c grub-core/fs/zfs/zfs_lz4.c
grub-core/fs/zfs/zfs_sha256.c grub-core/fs/zfs/zfs_fletcher.c
grub-core/lib/envblk.c grub-core/lib/hexdump.c grub-core/lib/LzFind.c
grub-core/lib/LzmaEnc.c grub-core/lib/crc.c grub-core/lib/adler32.c
grub-core/lib/crc64.c grub-core/normal/datetime.c grub-core/normal/misc.c
grub-core/partmap/acorn.c grub-core/partmap/amiga.c grub-core/partmap/apple.c
grub-core/partmap/sun.c grub-core/partmap/plan.c grub-core/partmap/dvh.c
grub-core/partmap/sunpc.c grub-core/partmap/bsdlabel.c grub-core/partmap/dfly.c
grub-core/script/function.c grub-core/script/lexer.c grub-core/script/main.c
grub-core/script/script.c grub-core/script/argv.c grub-core/io/gzio.c
grub-core/io/xzio.c grub-core/io/lzopio.c grub-core/kern/ia64/dl_helper.c
grub-core/kern/arm/dl_helper.c grub-core/kern/arm64/dl_helper.c
grub-core/lib/minilzo/minilzo.c grub-core/lib/xzembed/xz_dec_bcj.c
grub-core/lib/xzembed/xz_dec_lzma2.c grub-core/lib/xzembed/xz_dec_stream.c
util/misc.c grub-core/kern/command.c grub-core/kern/device.c
grub-core/kern/disk.c grub-core/lib/disk.c util/getroot.c
grub-core/osdep/unix/getroot.c grub-core/osdep/getroot.c
grub-core/osdep/devmapper/getroot.c grub-core/osdep/relpath.c
grub-core/kern/emu/hostdisk.c grub-core/osdep/devmapper/hostdisk.c
grub-core/osdep/hostdisk.c grub-core/osdep/unix/hostdisk.c
grub-core/osdep/exec.c grub-core/osdep/sleep.c grub-core/osdep/password.c
grub-core/kern/emu/misc.c grub-core/kern/emu/mm.c grub-core/kern/env.c
grub-core/kern/err.c grub-core/kern/file.c grub-core/kern/fs.c
grub-core/kern/list.c grub-core/kern/misc.c grub-core/kern/partition.c
grub-core/lib/crypto.c grub-core/disk/luks.c grub-core/disk/geli.c
grub-core/disk/cryptodi

[Bug c/66265] strict aliasing with O2 fails to generate correct code and gives no warnings

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #1 from Jakub Jelinek  ---
There is a warning with -Wstrict-aliasing=1 , if you read the documentation,
you'd find there are various levels that differ in the amount of false
positives.  The code is obviously invalid.

[Bug preprocessor/66277] [regression] cpp-5: fatal error: too many input files

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #1 from Jakub Jelinek  ---
Seems to be a user error.  Just read man page of cpp and gcc, the former
accepts (besides options) just two arguments, infile and outfile, while grub
clearly relies on $(CPP) being able to preprocess many source files at the same
time.
That is gcc -E, not cpp (and if you don't override it from the command line,
that is indeed what the configure will do correctly automatically).

[Bug preprocessor/66277] [regression] cpp-5: fatal error: too many input files

[paulepanter at users dot sourceforge.net]

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

--- Comment #2 from Paul Menzel  ---
(In reply to Jakub Jelinek from comment #1)
> Seems to be a user error.  Just read man page of cpp and gcc, the former
> accepts (besides options) just two arguments, infile and outfile, while grub
> clearly relies on $(CPP) being able to preprocess many source files at the
> same time.
> That is gcc -E, not cpp (and if you don't override it from the command line,
> that is indeed what the configure will do correctly automatically).

Indeed! Thank you very much. `CC=gcc-5 ./configure` does not use `cpp-4.9` for
`CPP` but `gcc-5 -E`. Quite confusing.

So it’s indeed not a bug and not a regression. I’ll remember to not set `CPP`
manually in the future. Sorry for the noise.

[Bug c++/55095] Wshift-overflow

[mpolacek at gcc dot gnu.org]

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

--- Comment #10 from Marek Polacek  ---
I've started looking into this.  Unfortunately, int_const_binop_1 doesn't say
whether an overflow occurred for e.g. 10 << 30.  So what we need to do is
something akin to what I did in cxx_eval_check_shift_p (I should have done that
using wide_int...).  It's also what our ubsan does when checking for overflows,
only at runtime.

build_binary_op then should be able to use that trick in case it's dealing with
INTEGER_CSTs, and warn appropriately.

It also seems we need yet another shift warning, -Wshift-overflow.

[Bug tree-optimization/66142] Loop is not vectorized because not sufficient support for GOMP_SIMD_LANE

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Slightly improved variant of #c6 testcase:
struct A { float x, y; };
struct B { struct A u; };
void bar (struct A *);

float
f1 (struct B *x, int y)
{
  struct A p;
  p.x = 1.0f;
  p.y = 2.0f;
  struct A *q = &x[y].u;
  *q = p;
  float f = x[y].u.x + x[y].u.y;
  bar (&p);
  return f;
}

float
f2 (struct B *x, int y)
{
  struct A p;
  p.x = 1.0f;
  p.y = 2.0f;
  x[y].u = p;
  float f = x[y].u.x + x[y].u.y;
  bar (&p);
  return f;
}

float
f3 (struct B *x, int y)
{
  struct A p;
  p.x = 1.0f;
  p.y = 2.0f;
  struct A *q = &x[y].u;
  __builtin_memcpy (&q->x, &p.x, sizeof (float));
  __builtin_memcpy (&q->y, &p.y, sizeof (float));
  *q = p;
  float f = x[y].u.x + x[y].u.y;
  bar (&p);
  return f;
}

float
f4 (struct B *x, int y)
{
  struct A p;
  p.x = 1.0f;
  p.y = 2.0f;
  __builtin_memcpy (&x[y].u.x, &p.x, sizeof (float));
  __builtin_memcpy (&x[y].u.y, &p.y, sizeof (float));
  float f = x[y].u.x + x[y].u.y;
  bar (&p);
  return f;
}

[Bug rtl-optimization/66275] __attribute__((sysv_abi)) with x86_64-w64-mingw32-gcc generates incorrect code

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-05-25
  Component|c   |rtl-optimization
   Target Milestone|--- |4.9.3
 Ever confirmed|0   |1

--- Comment #1 from Uroš Bizjak  ---
This problem can also be seen on x86_64-linux with gcc-6.0 and

gcc -O3 -funroll-loops -mabi=ms

In _.ce3 dump, we have following sequence:

  ...
   73: L73:
   72: NOTE_INSN_BASIC_BLOCK 5
   44: dx:DI=[si:DI+ax:DI]
  REG_EQUIV [si:DI+ax:DI]
   45: r9:DI=zero_extend(dx:QI)
   46: NOTE_INSN_DELETED
   47: xmm0:V4SI=vec_merge(vec_duplicate([r9:DI*0x4+cx:DI]),const_vector,0x1)
  REG_DEAD r9:DI
   50: NOTE_INSN_DELETED
   51: NOTE_INSN_DELETED
   52: dx:DI=zero_extract(dx:DI,0x8,0x8)
   53: NOTE_INSN_DELETED
   54: NOTE_INSN_DELETED
   55:
xmm1:V4SI=vec_merge(vec_duplicate([dx:DI*0x4+cx:DI+0x400]),const_vector,0x1)
  REG_DEAD dx:DI
   56: xmm0:V2DI=xmm0:V2DI^xmm1:V2DI
  REG_DEAD xmm1:V2DI
   57: xmm0:V2DI=xmm0:V2DI^[di:DI+ax:DI]
  REG_EQUIV [di:DI+ax:DI]
   58: [di:DI+ax:DI]=xmm0:V2DI
  REG_DEAD xmm0:V2DI
  183: dx:DI=[si:DI+ax:DI+0x10]
  REG_EQUIV [si:DI+ax:DI+0x10]
  ...

Please note (insn 183), a consumer of SI register.

In _.rnreg dump, the above sequence is transformed to:

  ...
   73: L73:
   72: NOTE_INSN_BASIC_BLOCK 5
   44: dx:DI=[si:DI+r10:DI]
  REG_EQUIV [si:DI+ax:DI]
   45: si:DI=zero_extend(dx:QI)
   46: NOTE_INSN_DELETED
   47: xmm8:V4SI=vec_merge(vec_duplicate([si:DI*0x4+cx:DI]),const_vector,0x1)
  REG_DEAD r9:DI
   50: NOTE_INSN_DELETED
   51: NOTE_INSN_DELETED
   52: ax:DI=zero_extract(dx:DI,0x8,0x8)
   53: NOTE_INSN_DELETED
   54: NOTE_INSN_DELETED
   55:
xmm9:V4SI=vec_merge(vec_duplicate([ax:DI*0x4+cx:DI+0x400]),const_vector,0x1)
  REG_DEAD dx:DI
   56: xmm8:V2DI=xmm8:V2DI^xmm9:V2DI
  REG_DEAD xmm1:V2DI
   57: xmm8:V2DI=xmm8:V2DI^[di:DI+r10:DI]
  REG_EQUIV [di:DI+ax:DI]
   58: [di:DI+r10:DI]=xmm8:V2DI
  REG_DEAD xmm0:V2DI
  183: dx:DI=[si:DI+r10:DI+0x10]
  REG_EQUIV [si:DI+ax:DI+0x10]
  ...

So, (insn 45) now indeed clobbers SI register that is needed by (insn 183).

Confirmed as RTL optimization problem, specifically, a rnreg pass problem.

[Bug target/65979] [4.9/5/6 Regression] [SH] Wrong code is generated with stage1 compiler

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #27 from John Paul Adrian Glaubitz  ---
(In reply to Oleg Endo from comment #25)
> So, if I understand correctly ...
> - 4.9.something doesn't bootstrap because of something unknown

It doesn't bootstrap because the D compiler fails the compare test. This
happens both on gcc-4.8 and gcc-4.9, here's the excerpt from 4.8 [1]:

Comparing stages 2 and 3
warning: gcc/cc1objplus-checksum.o differs
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1obj-checksum.o differs
Bootstrap comparison failure!
gcc/d/ctfeexpr.dmd.o differs

> - 5.something doesn't bootstrap because of c#19
> 
> ... right?

Yeah, that seems to be unrelated. Sorry for the confusion. I assumed those were
the same.

> Adrian, which compiler do you use to build the SH native compiler(s)?
> Last time I've tried to do a native GCC 5 build on the SH4 debian box,
> vanilla GCC would not build and I gave up.  Sorry for my impatience.

gcc-4.9.2_10 which is SVN_r218987 (20141220).

> > But in any case, I am super happy you guys are fixing this. I will be back
> > in Japan in October, so if I have a chance to meet either of you, I owe you
> > some beer/sake/wine etc :).
> 
> Will trade beer for Mohnkuchen.
> Will trade many other things for an SH4A-X4 8-core board with 2+ GB RAM.

Heh. I could try to talk to Nobuhiro again. Maybe he has some ideas where to
get hold of faster SH4 hardware.

Adrian

> [1] 
> http://buildd.debian-ports.org/status/fetch.php?pkg=gcc-4.8&arch=sh4&ver=4.8.4-2&stamp=1432515052

[Bug target/65979] [4.9/5/6 Regression] [SH] Wrong code is generated with stage1 compiler

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #28 from John Paul Adrian Glaubitz  ---
> It doesn't bootstrap because the D compiler fails the compare test. This
> happens both on gcc-4.8 and gcc-4.9, here's the excerpt from 4.8 [1]:
> 
> Comparing stages 2 and 3
> warning: gcc/cc1objplus-checksum.o differs
> warning: gcc/cc1-checksum.o differs
> warning: gcc/cc1plus-checksum.o differs
> warning: gcc/cc1obj-checksum.o differs
> Bootstrap comparison failure!
> gcc/d/ctfeexpr.dmd.o differs

Hmm, now I'm confused. The comparision actually also failed before but the
build was still successful [1] for gcc_4.8.4-1:

Comparing stages 2 and 3
warning: gcc/cc1objplus-checksum.o differs
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1obj-checksum.o differs
Comparison successful.

For gcc_4.8.4-2, the problem is not ignored [2] and the build therefore fails:

Comparing stages 2 and 3
warning: gcc/cc1objplus-checksum.o differs
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1obj-checksum.o differs
Bootstrap comparison failure!

Interesting. So apparently this is _not_ a regression. Maybe we should split
the comparison failure of stage 2 and stage 3 into a different bug report.

Adrian

> [1] 
> http://buildd.debian-ports.org/status/fetch.php?pkg=gcc-4.8&arch=sh4&ver=4.8.4-1&stamp=1422178262
> [2] 
> http://buildd.debian-ports.org/status/fetch.php?pkg=gcc-4.8&arch=sh4&ver=4.8.4-2&stamp=1432515052

[Bug middle-end/66148] [6 regression] build/genpreds: Internal error: abort in choose_enum_order, at genpreds.c:1006

[dave.anglin at bell dot net]

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

--- Comment #5 from dave.anglin at bell dot net ---
On 2015-05-25, at 3:21 AM, thopre01 at gcc dot gnu.org wrote:

> Here the REG_EQUAL does not match the value that is set: the 32 most
> significant bits are zero. Which is why combine decide that the set of
> zero_extract can be removed. Looking at the dumps of the various pass,
> everything looks fine until cse1 where instruction 360 is replaced from:
> 
> (insn 360 359 361 32 (set (reg:DI 549)
>(lo_sum:DI (reg:DI 550)
>(const_int -822083584 [0xcf00])))
> ../../gcc/gcc/genpreds.c:983 93 {*pa.md:2773}
> (expr_list:REG_EQUAL (const_int 3472883712 [0xcf00])
>(nil)))

The note appears wrong before cse1.

Dave
--
John David Anglin   dave.ang...@bell.net

[Bug tree-optimization/66142] Loop is not vectorized because not sufficient support for GOMP_SIMD_LANE

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #8 from Jakub Jelinek  ---
I guess it depends on what exactly SCCVN uses the operand vectors
created/optimized by copy_reference_ops_from_ref/valueize_refs_1 for.
If it is used only for tracking what is the value of the reference (the value
stored into that piece of memory), or also for canonicalization of references
to certain more canonical form, or both.  If only the value of the reference,
then
supposedly it would be nice to get far more canonicalization in the references
(e.g. turn (perhaps multiple nested) COMPONENT_REFs into MEM_REFs with offset
(except perhaps for bitfields, perhaps even do something about ARRAY_REFs, so
that say even:
struct A { float x, y; };
struct B { struct A u; };
void bar (struct A *);

float
f2 (struct B *x, int y)
{
  struct A p;
  p.x = 1.0f;
  p.y = 2.0f;
  char *z = (char *) x;
  z += y * sizeof (struct B);
  z += __builtin_offsetof (struct B, u.y);
  x[y].u = p;
  float f = *(float *) z;
  bar (&p);
  return f;
}
is handled).  But, supposedly it would be undesirable to canonicalize all the
COMPONENT_REFs to the MEM_REFs (at least early on, e.g. for
__builtin_object_size (, 1) purposes, or aliasing etc.).
Richi, any thoughts on this?

[Bug target/66215] [4.8/4.9/5/6 Regression] Wrong after label NOP emission for -mhotpatch

[mbenes at suse dot cz]

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

--- Comment #18 from Miroslav Benes  ---
I confirm that v4 of the proposed patch works for me. Tested on simple
userspace program similar to the one in the bug description and on the kernel
module where I stumbled upon the bug originally.

Thanks a lot for the fix,
Miroslav

[Bug target/66215] [4.8/4.9/5/6 Regression] Wrong after label NOP emission for -mhotpatch

[jakub at gcc dot gnu.org]

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

--- Comment #19 from Jakub Jelinek  ---
I'm still missing (untested):
-dg-runtest [lsort [glob -nocomplain $srcdir/$subdir/*.\[cS\]]] \
+dg-runtest [lsort [prune [glob -nocomplain $srcdir/$subdir/*.\[cS\]] \
+ $srcdir/$subdir/hotpatch-\[0-9\]*.c]] \
 "" $DEFAULT_CFLAGS
or similar change in the s390.exp, otherwise you run all the hotpatch-[0-9]*.c
tests once outside of the torture (with the implicit -O0) and many times in the
torture mode (where it includes -O0 too).

[Bug c++/65945] C++ alignment of nullptr_t is 1 and might cause unaligned stores to the frame

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #10 from Eric Botcazou  ---
> This also happens on Sparc.

Right, it was also reported under PR C++/65090.

[Bug tree-optimization/66278] New: Missed auto-vectorization of an array subtraction

[marxin at gcc dot gnu.org]

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

Bug ID: 66278
   Summary: Missed auto-vectorization of an array subtraction
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---
Target: x86_64-linux-gnu

Hello.

In the following test case, we do not optimize assembly to utilize a vector
instruction.

$ cat vector.c

#include 

#define N 101

int main(int argc, char **argv)
{
  uint32_t array[N][N][N];

  const unsigned int next = argc == 3 ? 0 : 1;

  for (unsigned i = next; i < N;  i++)
array[3][3][i] = array[3][3][i] - 10;

  return array[3][3][argc];
}

gcc 5.1.0 (same for GCC 4.8) with -O3 (http://goo.gl/zA7LMy):
main:
xorl%eax, %eax
subq$4121104, %rsp
cmpl$3, %edi
setne   %al
.L2:
movl%eax, %edx
addl$1, %eax
subl$10, 123504(%rsp,%rdx,4)
cmpl$101, %eax
jne .L2
movslq  %edi, %rdi
movl123504(%rsp,%rdi,4), %eax
addq$4121104, %rsp
ret

icc 13.0.1 with -O3 (http://goo.gl/xzlz2C):
L__routine_start_main_0:
main:
pushq %rbp  #6.1
movq  %rsp, %rbp#6.1
andq  $-128, %rsp   #6.1
pushq %r12  #6.1
subq  $4121208, %rsp#6.1
movl  %edi, %r12d   #6.1
movl  $3, %edi  #6.1
call  __intel_new_proc_init #6.1
stmxcsr   (%rsp)#6.1
movslq%r12d, %r12   #6.1
xorl  %edi, %edi#9.37
movl  $1, %esi  #9.37
cmpq  $3, %r12  #9.37
cmove %edi, %esi#9.37
orl   $32832, (%rsp)#6.1
ldmxcsr   (%rsp)#6.1
movl  %esi, %ecx#11.3
negl  %ecx  #11.3
addl  $101, %ecx#11.3
lea   123624(%rsp,%rsi,4), %rax #11.3
andq  $15, %rax #11.3
movl  %eax, %edx#11.3
negl  %edx  #11.3
addl  $16, %edx #11.3
shrl  $2, %edx  #11.3
testl %eax, %eax#11.3
cmovne%edx, %eax#11.3
lea   4(%rax), %r8d #11.3
cmpl  %r8d, %ecx#11.3
jl..B1.16   # Prob 10%  #11.3
movl  %ecx, %edx#11.3
subl  %eax, %edx#11.3
andl  $3, %edx  #11.3
negl  %edx  #11.3
addl  %ecx, %edx#11.3
testl %eax, %eax#11.3
jbe   ..B1.8# Prob 10%  #11.3
..B1.6: # Preds ..B1.4 ..B1.6
lea   (%rsi,%rdi), %r8d #12.22
incl  %edi  #11.3
addl  $-10, 123624(%rsp,%r8,4)  #12.39
cmpl  %eax, %edi#11.3
jb..B1.6# Prob 99%  #11.3
..B1.8: # Preds ..B1.6 ..B1.4
movdqa.L_2il0floatpacket.2(%rip), %xmm0 #12.39
..B1.9: # Preds ..B1.9 ..B1.8
lea   (%rsi,%rax), %edi #12.22
addl  $4, %eax  #11.3
cmpl  %edx, %eax#11.3
movdqa123624(%rsp,%rdi,4), %xmm1#12.39
paddd %xmm0, %xmm1  #12.39
movdqa%xmm1, 123624(%rsp,%rdi,4)#12.5
jb..B1.9# Prob 99%  #11.3

[Bug c++/55095] Wshift-overflow

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
   Target Milestone|--- |6.0

--- Comment #11 from Marek Polacek  ---
I have a patch (I made use of widest_int instead).

[Bug c/66265] strict aliasing with O2 fails to generate correct code and gives no warnings

[gougolith at gmail dot com]

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

--- Comment #2 from Mark  ---
Yes thank you, it all makes sense unfortunately...it is all buried in -O2...

On Mon, May 25, 2015 at 12:50 AM, jakub at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66265
>
> Jakub Jelinek  changed:
>
>What|Removed |Added
>
> 
>  Status|UNCONFIRMED |RESOLVED
>  CC||jakub at gcc dot gnu.org
>  Resolution|--- |INVALID
>
> --- Comment #1 from Jakub Jelinek  ---
> There is a warning with -Wstrict-aliasing=1 , if you read the
> documentation,
> you'd find there are various levels that differ in the amount of false
> positives.  The code is obviously invalid.
>
> --
> You are receiving this mail because:
> You reported the bug.
>

[Bug inline-asm/66279] New: Input/output asm operand is not loaded inside a constructor with a virtual base class

[andrey.vihrov at gmail dot com]

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

Bug ID: 66279
   Summary: Input/output asm operand is not loaded inside a
constructor with a virtual base class
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: inline-asm
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrey.vihrov at gmail dot com
  Target Milestone: ---

Created attachment 35620
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35620&action=edit
Testcase

When inline assembly is used inside a constructor of a class with a virtual
base class, and the inline assembly block has an input/output operand, GCC
fails to load the value of the operand into a corresponding register.

The attached code, compiled with GCC 5.1, produces

a.out: test.cpp:16: B::B(): Assertion `x == 42' failed.

This happens with both -O2 and -O0. Remove 'virtual' or place the code in a
regular function, and the assertion will succeed. Marking the ctor as inline
also makes the assertion succeed.

gcc -v:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/gcc-multilib/src/gcc-5-20150519/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --enable-multilib --disable-werror
--enable-checking=release --with-default-libstdcxx-abi=c++98
Thread model: posix
gcc version 5.1.0 (GCC)

[Bug inline-asm/66279] Input/output asm operand is not loaded inside a constructor with a virtual base class

[andrey.vihrov at gmail dot com]

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

Andrey Vihrov  changed:

   What|Removed |Added

  Attachment #35620|0   |1
is obsolete||

--- Comment #1 from Andrey Vihrov  ---
Created attachment 35621
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35621&action=edit
Testcase

[Bug tree-optimization/66278] Missed auto-vectorization of an array subtraction

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Seems to be overly conservative tree-chrec.c code.
chrec_fold_plus is called on
(sizetype) {i_5, +, 1}_1 and 30906
where loop->nb_iterations_upper_bound is 100 and
loop->nb_iterations is (unsigned int) _4 + 1 <= 101 ? 100 - (unsigned int) _4 :
0
It is a pitty we don't use range info on _4 when simplifying
loop->nb_iterations, here it is [0, 1], so we could at least easily find out
that (unsigned int) _4 + 1 <= 101 is always true.
Anyway, chrec_fold_plus just gives up on:
CASE_CONVERT:
  if (tree_contains_chrecs (op0, NULL))
return chrec_dont_know;
eventhough from the loop bounds in this case it could prove that for all loop
iterations the chrec always fits into the narrower type, including the addition
and thus it can safely move the addition into the chrec's op0.
If I change [3][3] to [0][0], then the problem is in chrec_fold_multiply
instead (again, we have (sizetype) i_16 * 4 and give up because of the cast).

If the testcase is modified, so that it uses unsigned long as i and next type,
then it is vectorized fine.

[Bug inline-asm/66274] gcc6: x86 -m32 emits 64bit register in inline asm

[uros at gcc dot gnu.org]

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

--- Comment #2 from uros at gcc dot gnu.org ---
Author: uros
Date: Mon May 25 17:49:28 2015
New Revision: 223649

URL: https://gcc.gnu.org/viewcvs?rev=223649&root=gcc&view=rev
Log:
PR target/66274
* config/i386/i386.c (print_reg): Only print "r" for TARGET_64BIT
when LEGACY_INT_REGNO_P is processed.

testsuite/ChangeLog:

PR target/66274
* gcc.target/i386/pr66274.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr66274.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug target/66274] gcc6: x86 -m32 emits 64bit register in inline asm

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Target||x86
 Status|ASSIGNED|RESOLVED
  Component|inline-asm  |target
 Resolution|--- |FIXED

--- Comment #3 from Uroš Bizjak  ---
Fixed.

[Bug tree-optimization/66280] New: internal compiler error: in vect_get_vec_def_for_operand, at tree-vect-stmts.c:1322

[ketan.surender at gmail dot com]

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

Bug ID: 66280
   Summary: internal compiler error: in
vect_get_vec_def_for_operand, at
tree-vect-stmts.c:1322
   Product: gcc
   Version: 4.7.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ketan.surender at gmail dot com
  Target Milestone: ---

Created attachment 35622
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35622&action=edit
preprocessed reproduction file

Hitting an internal compilation error for the attached repro.i file.

g++ -c -std=c++98 -pedantic -Wno-long-long -fwrapv -fPIC -O3 -fno-loop-optimize
repro.i

dtodoublessingleststscript4.cpp: In function ‘void
dtodoublessingleststscript4(short int, const cint16_T*, short int*, cint16_T*,
int*, cint32_T*, cint32_T*, int*, cint32_T*, cint16_T*, cint32_T*, int*, int*,
cint32_T*, cint32_T*, int*, cint32_T*, int*, int*, cint32_T*, cint32_T*,
cint16_T*, short int*, short int*, short int*, short int*)’:
dtodoublessingleststscript4.cpp:102:6: internal compiler error: in
vect_get_vec_def_for_operand, at tree-vect-stmts.c:1322
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

I am seeing this on a Debian 7 machine.

g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/SNIP/glnxa64/gcc-4.7.2/libexec/gcc/x86_64-unknown-linux-gnu/4.7.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /SNIP/gcc-4.7/configure --prefix=/SNIP/glnxa64/gcc-4.7.2
--with-gmp=/SNIP/glnxa64/gcc-4.7/gmp --with-mpfr=/SNIP/glnxa64/gcc-4.7/mpfr
--with-mpc=/SNIP/glnxa64/gcc-4.7/mpc --enable-languages=c,c++,fortran
--with-as=/SNIP/glnxa64/gcc-4.7.2/bin/as
--with-ld=/SNIP/glnxa64/gcc-4.7.2/bin/ld
Thread model: posix
gcc version 4.7.2 (GCC)

[Bug tree-optimization/66280] [4.8/4.9/5/6 Regression] ICE: in vect_get_vec_def_for_operand, at tree-vect-stmts.c:1472

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-05-25
 CC||trippels at gcc dot gnu.org
Summary|internal compiler error: in |[4.8/4.9/5/6 Regression]
   |vect_get_vec_def_for_operan |ICE: in
   |d, at   |vect_get_vec_def_for_operan
   |tree-vect-stmts.c:1322  |d, at
   ||tree-vect-stmts.c:1472
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
markus@x4 tmp % cat repro.ii
typedef struct
{
  short re;
  short im;
} cint16_T;
typedef struct
{
  int re;
  int im;
} cint32_T;
int a;
short b;
cint16_T *c;
cint32_T *d, *e;
void
fn1 ()
{
  for (; a; a++)
{
  d[a].re = d[a].im = e[a].re = c[a].re * b;
  e[a].im = c[a].im * b;
}
}

markus@x4 tmp % g++ -c -O3 repro.ii
repro.ii: In function ‘void fn1()’:
repro.ii:16:1: internal compiler error: in vect_get_vec_def_for_operand, at
tree-vect-stmts.c:1472
 fn1 ()
  ^
0xe98c19 vect_get_vec_def_for_operand(tree_node*, gimple_statement_base*,
tree_node**)
../../gcc/gcc/tree-vect-stmts.c:1472
0xea1273 vectorizable_store
../../gcc/gcc/tree-vect-stmts.c:5330
0xeab8f0 vect_transform_stmt(gimple_statement_base*, gimple_stmt_iterator*,
bool*, _slp_tree*, _slp_instance*)
../../gcc/gcc/tree-vect-stmts.c:7345
0xeb0d84 vect_transform_loop(_loop_vec_info*)
../../gcc/gcc/tree-vect-loop.c:6185
0xecbe82 vectorize_loops()
../../gcc/gcc/tree-vectorizer.c:502
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/66280] [4.8/4.9/5/6 Regression] ICE: in vect_get_vec_def_for_operand, at tree-vect-stmts.c:1472

[trippels at gcc dot gnu.org]

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

--- Comment #2 from Markus Trippelsdorf  ---
repro.ii: In function ‘void fn1()’:
repro.ii:16:1: error: definition in block 7 follows the use
 fn1 ()
 ^
for SSA_NAME: vect_patt_56.19_117 in statement:
vect_inter_high_132 = VEC_PERM_EXPR ;
repro.ii:16:1: internal compiler error: verify_ssa failed
0xe77f79 verify_ssa(bool, bool)
../../gcc/gcc/tree-ssa.c:1068
0xbcfee5 execute_function_todo
../../gcc/gcc/passes.c:1953
0xbd06d3 execute_todo
../../gcc/gcc/passes.c:2003
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug tree-optimization/66280] [4.8/4.9/5/6 Regression] ICE: in vect_get_vec_def_for_operand, at tree-vect-stmts.c:1472

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |4.8.5

--- Comment #3 from Jakub Jelinek  ---
Started with r172817.

[Bug c++/66281] New: [C++14][Variable templates] internal compiler error: in tsubst, at cp/pt.c:12022

[ldionne.2 at gmail dot com]

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

Bug ID: 66281
   Summary: [C++14][Variable templates] internal compiler error:
in tsubst, at cp/pt.c:12022
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ldionne.2 at gmail dot com
  Target Milestone: ---

Hi,

The following code causes an ICE on GCC trunk (couple of weeks old):


template  auto f() { return 1; }

template 
auto variable_template2 = f();

template 
auto variable_template1 = variable_template2;

template int variable_template1<'c'>;



Sample command line (lines trimmed):

› ~/code/gcc5/bin/g++ --version
g++ (GCC) 6.0.0 20150423 (experimental)
Copyright (C) 2015 Free Software Foundation, Inc.


› ~/code/gcc5/bin/g++ -std=c++1y ~/Desktop/bug.cpp
~/Desktop/bug.cpp: In instantiation of ‘auto variable_template1<'c'>’:
~/Desktop/bug.cpp:9:14:   required from here
~/Desktop/bug.cpp:4:6: internal compiler error: in tsubst, at cp/pt.c:11973
 auto variable_template2 = f();
  ^

~/Desktop/bug.cpp:4:6: internal compiler error: Abort trap: 6
g++: internal compiler error: Abort trap: 6 (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


Regards,
Louis Dionne

[Bug bootstrap/66252] [6 regression] bootstrap comparison failures on sparc-linux

[mikpelinux at gmail dot com]

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

--- Comment #1 from Mikael Pettersson  ---
Started with r67:

fc6cc27b3f46a6f70f610ec93a1c5e68d83c933b is the first bad commit
commit fc6cc27b3f46a6f70f610ec93a1c5e68d83c933b
Author: rguenth 
Date:   Tue Apr 21 12:52:43 2015 +

2015-04-21  Richard Biener  

PR tree-optimization/65650
* tree-ssa-ccp.c (valid_lattice_transition): Allow lattice
transitions involving copies.
(set_lattice_value): Adjust for copy lattice state.
(ccp_lattice_meet): Do not merge UNDEFINED and a copy to the copy
if that doesn't dominate the merge point.
(bit_value_unop): Adjust what we treat as varying mask.
(bit_value_binop): Likewise.
(bit_value_assume_aligned): Likewise.
(evaluate_stmt): When we simplified to a SSA name record a copy
instead of dropping to varying.
(visit_assignment): Simplify.

* gimple-match.h (gimple_simplify): Add another callback.
* gimple-fold.c (fold_stmt_1): Adjust caller.
(gimple_fold_stmt_to_constant_1): Likewise - pass valueize
for the 2nd callback.
* gimple-match-head.c (gimple_simplify): Add a callback that is
used to valueize the stmt operands and use it that way.

* gcc.dg/tree-ssa/ssa-ccp-37.c: New testcase.
* gcc.dg/tree-ssa/forwprop-11.c: Adjust.
* gcc.dg/tree-ssa/ssa-fre-3.c: Likewise.
* gcc.dg/tree-ssa/ssa-fre-4.c: Likewise.
* gcc.dg/tree-ssa/ssa-fre-5.c: Likewise.
* gcc.dg/tree-ssa/ssa-fre-32.c: Likewise.


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@67
138bc75d-0d04-0410-961f-82ee72b054a4

[Bug c++/66270] [6 Regression] ICE: canonical types differ for identical types

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

[Bug bootstrap/66252] [6 regression] bootstrap comparison failures on sparc-linux

[andreast at gcc dot gnu.org]

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

--- Comment #2 from Andreas Tobler  ---
I see the same failures on sparc-solaris 10

[Bug ipa/66181] [6 Regression]: /usr/include/bits/types.h:134:16: ICE: verify_type failed

[andreast at gcc dot gnu.org]

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

--- Comment #11 from Andreas Tobler  ---
For the record from my side:

sparc-solaris and arm*-*-freebsd* are also affected. Applying the line from #6
cures the bootstrap on arm. But sparc-solaris is still broken, 66252 is the
pointer there.

[Bug c/66282] New: Missing x86 floating point conversion on explicit casts violates C standard

[timo.kreuzer at reactos dot org]

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

Bug ID: 66282
   Summary: Missing x86 floating point conversion on explicit
casts violates C standard
   Product: gcc
   Version: 4.7.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: timo.kreuzer at reactos dot org
  Target Milestone: ---

When compiling floating point code, the compiler omits to convert an
intermediate computation result, which is cast to double, to 64 bit precision
and instead keeps the internal 80 bit precision.

Example code:

void bugbug()
{
double x = 4.4;
double y;

y = (1 / x);
if ( y != ((double)(1 / x)) )
{
printf("Standard violation!\n");
}
}

compiled with "gcc.exe -Wall -g -c fpu.c -o fpu.o"

The expression on the right side inside the if() is not converted to double
precision, which is in violation of the C standard.

Quote:
"Implementations employing wide registers have to take care to honor
appropriate
semantics. Values are independent of whether they are represented in a register
or in memory. For example, an implicit spilling of a register is not permitted
to alter the value. Also, an explicit store and load is required to round to
the precision of the storage type. In particular, casts and assignments are
required to perform their specified conversion."

Emphasis is on the last sentence.

This was tested on a mingw version of the compiler, but I do not think this is
mingw specific.

[Bug c/66282] Missing x86 floating point conversion on explicit casts violates C standard

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
I think 4.9 and above implement this semantics.

[Bug c/66283] New: [ICE] [IA64] verify type mis-diagnosis: type variant differs by TYPE_NO_FORCE_BLK

[gary at intrepid dot com]

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

Bug ID: 66283
   Summary: [ICE] [IA64] verify type mis-diagnosis: type variant
differs by TYPE_NO_FORCE_BLK
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gary at intrepid dot com
  Target Milestone: ---

This recent commit implemented additional type verification checks:

r223252 | hubicka | 2015-05-16 13:51:50 -0700 (Sat, 16 May 2015) | 3 lines

* tree.c (verify_type_variant): Verify tree_base and type_common flags.
(verify_type): Verify STRING_FLAG.

This triggers an ICE on IA64 when configured with --enable-checking and when
the test program below is compiled with "-g".  It may be possible to change
the test so that the declaration of "struct S" to asserts TYPE_NO_FORCE_BLK()
for a more common target like the x86_64, but I didn't try that.

typedef volatile struct S opaque_qualified_t;

struct S
{
   unsigned long _s1;
   int _s2;
};

void
proc (opaque_qualified_t *p __attribute__((unused)))
{
}

ice-no-force-blk.i: In function ‘proc’:
ice-no-force-blk.i:12:1: error: type variant differs by TYPE_NO_FORCE_BLK.
 }
  ^
  
constant 128>
unit size  
constant 16>
align 64 symtab 12587232 alias set -1 canonical type 0x20b6eee0
fields 
unit size 
align 64 symtab 12587632 alias set -1 canonical type
0x20ab0888 precision 64 min 
 max 

pointer_to_this >
unsigned DI file ice-no-force-blk.i line 5 col 18 size  
unit size 
align 64 offset_align 128
offset 
bit offset  context

chain 

SI file ice-no-force-blk.i line 6 col 8
size 
unit size 
align 32 offset_align 128 offset 
bit offset  context >> context

chain >
  
constant 128>
unit size  
constant 16>
align 64 symtab 12587152 alias set -1 canonical type 0x20b6ef88
fields 
unit size 
align 64 symtab 12587632 alias set -1 canonical type
0x20ab0888 precision 64 min 
 max 

pointer_to_this >
unsigned DI file ice-no-force-blk.i line 5 col 18 size  
unit size 
align 64 offset_align 128
offset 
bit offset  context

chain 

SI file ice-no-force-blk.i line 6 col 8
size 
unit size 
align 32 offset_align 128 offset 
bit offset  context >> context

pointer_to_this >
ice-no-force-blk.i:12:1: internal compiler error: verify_type failed
0x425159ff verify_type(tree_node const*)
/eng/upc/dev/gary/gupc-dev/src/gupc/gcc/tree.c:13209
0x40ad3d4f gen_type_die_with_usage
/eng/upc/dev/gary/gupc-dev/src/gupc/gcc/dwarf2out.c:20304
0x40ad4b0f gen_type_die_with_usage
/eng/upc/dev/gary/gupc-dev/src/gupc/gcc/dwarf2out.c:20391
0x40ad572f gen_type_die
/eng/upc/dev/gary/gupc-dev/src/gupc/gcc/dwarf2out.c:20488
0x40adbfdf gen_decl_die
/eng/upc/dev/gary/gupc-dev/src/gupc/gcc/dwarf2out.c:21104
0x40ac4d9f gen_subprogram_die
/eng/upc/dev/gary/gupc-dev/src/gupc/gcc/dwarf2out.c:18859
0x40adb0af gen_decl_die
/eng/upc/dev/gary/gupc-dev/src/gupc/gcc/dwarf2out.c:21018
0x40adee0f dwarf2out_decl
/eng/upc/dev/gary/gupc-dev/src/gupc/gcc/dwarf2out.c:21451
0x40adee7f dwarf2out_function_decl
/eng/upc/dev/gary/gupc-dev/src/gupc/gcc/dwarf2out.c:21459
0x40c9fc0f rest_of_handle_final
/eng/upc/dev/gary/gupc-dev/src/gupc/gcc/final.c:4525
0x40ca037f execute
/eng/upc/dev/gary/gupc-dev/src/gupc/gcc/final.c:4567

[Bug libstdc++/66284] New: std::reference_wrapper is transparent to std::function::target_type

[potswa at mac dot com]

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

Bug ID: 66284
   Summary: std::reference_wrapper is transparent to
std::function::target_type
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: potswa at mac dot com
  Target Milestone: ---

std::function elides reference_wrappers from the target. This is not
conforming.


#include 
#include 

struct s { void operator () () {} } g;
std::function< void() > f = std::ref( g );

int main() {
assert ( f.target< std::reference_wrapper< s > >() );
assert ( ! f.target< s >() );
}

[Bug target/66215] [4.8/4.9/5/6 Regression] Wrong after label NOP emission for -mhotpatch

[vogt at linux dot vnet.ibm.com]

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

--- Comment #20 from Dominik Vogt  ---
I'll remove "-O0" from the list of torture test options so that the list of
hotpatch torture tests is only defined in one place.

[Bug bootstrap/66252] [6 regression] bootstrap comparison failures on sparc-linux

[mikpelinux at gmail dot com]

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

--- Comment #3 from Mikael Pettersson  ---
Still occurs with trunk @ r223652.