[Bug other/67179] New: failed to build gcc on RHEL 6.2

[zxrlha at gmail dot com]

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

Bug ID: 67179
   Summary: failed to build gcc on RHEL 6.2
   Product: gcc
   Version: 4.9.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zxrlha at gmail dot com
  Target Milestone: ---

I've tried to build GCC 4.9.3 and 5.2.0 from source on RHEL 6.2, but failed in
stage1 with following error(the following is error for GCC5.2.0, and GCC4.9.3
will result in similar error):

g++: fatal error: braced spec
'%:sanitize(address):%{!shared:libasan_preinit%O%s}
%{static-libasan:%{!shared:-Bstatic --whole-archive -lasan --no-whole-archive
-Bdynamic}}%{!static-libasan:-lasan}}
%{%:sanitize(thread):%{static-libtsan:%{!shared:-Bstatic --whole-archive -ltsan
--no-whole-archive -Bdynamic}}%{!static-libtsan:-ltsan}}
%{%:sanitize(leak):%{static-liblsan:%{!shared:-Bstatic --whole-archive -llsan
--no-whole-archive -Bdynamic}}%{!static-liblsan:-llsan}}' is invalid at '%'
compilation terminated.
make[3]: *** [cc1] Error 1
make[3]: Leaving directory `/home/hbsally/hocode/gcc520build/gcc'
make[2]: *** [all-stage1-gcc] Error 2
make[2]: Leaving directory `/home/hbsally/hocode/gcc520build'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/home/hbsally/hocode/gcc520build'
make: *** [all] Error 2

I try to build them with both system GCC(version 4.4.6), and a GCC(version
4.8.4) compiled by myself, and they will result in same error.

I run grep, and found the spec is from file ./gcc/specs. I compare it with gcc
-dumpspecs, and found that both GCC4.4.6 and GCC4.8.4 using something like
"%{fsanitize=thread:", while this file contains "%:sanitize(thread)".

I try to run following command(this time, I compile GCC4.9.3 with system
GCC4.4.6):
gcc -dumpspecs > ./gcc/specs
and then run make to continue compiling, it is OK now.

The configure options when I compile GCC 4.9.3(similar for GCC 5.2.0):
../gcc-4.9.3/configure --prefix=/home/hbsally/hocode/apps/gcc-4.9.3
--disable-multilib --with-system-zlib --enable-languages=c,c++,fortran
--disable-nls

The system GCC version(gcc -v):
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-ppl --with-cloog --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.4.6 20110731 (Red Hat 4.4.6-3) (GCC)

and the GCC 4.8.4 compiled by myself(gcc -v):
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/hbsally/hocode/apps/libexec/gcc/x86_64-unknown-linux-gnu/4.8.4/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.8.4/configure --prefix=/home/hbsally/hocode/apps
--enable-languages=c,c++,fortran --disable-multilib
Thread model: posix
gcc version 4.8.4 (GCC)

the system version(cat /etc/redhat-release):
Red Hat Enterprise Linux Server release 6.2 (Santiago)

and (uname -a):
Linux login2 2.6.32-220.el6.x86_64 #1 SMP Wed Nov 9 08:03:13 EST 2011 x86_64
x86_64 x86_64 GNU/Linux

I use GMP 5.1.3, MPFR 3.1.2, MPC 1.0.3, and no ISL. These three packages are
placed in source directory of GCC, as the INSTALL documents said to bootstrap
with GCC. I've successful build GCC4.8.4 with these three packages.

[Bug tree-optimization/61441] ARM aarch64 fails to quiet signaling NaN

[ssaraswati at gmail dot com]

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

Sujoy  changed:

   What|Removed |Added

 CC||ssaraswati at gmail dot com

--- Comment #2 from Sujoy  ---
I could reproduce this on x86_64-linux-gnu with 4.9 and trunk.

As far as the issue is concerned, the ccp propagates the sNaN value at -O1 or
higher optimization level. Should this be done only when -fsignaling-nans is
on? From the man page of gcc, -fsignaling-nans says -

"Compile code assuming that IEEE signaling NaNs may generate user-visible traps
during floating-point operations.  Setting this option disables optimizations
that may change the number of exceptions visible with signaling NaNs."

Going by this, should we stop ccp from folding sNaN values when
-fsignaling-nans is on? However, the man page also says the following for
-fsignaling-nans -

"This option is experimental and does not currently guarantee to disable all
GCC optimizations that affect signaling NaN behavior."

Given this, may be we can probably let ccp propagate the sNaN value if
-fsignaling-nans is on, and change it to qNaN otherwise. With this though, we
would still see different behavior for the test case at -O0 and -O1 when
-fsignaling-nans is used.

Is my understanding right? I would be interested in pushing a patch for this if
this issue is confirmed. What would be the process to get this confirmed?

[Bug target/54089] [SH] Refactor shift patterns

[bugdal at aerifal dot cx]

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

--- Comment #39 from Rich Felker  ---
Oleg, do you have rights under your copyright assignment agreement to
dual-license the libgcc part of the patch under GPLv2 so it could be included
in the kernel, and if so, would you be willing to do so? I agree it would be
cleaner for the kernel not to duplicate libgcc code, but getting in a simple
patch to update the code that's there would be a lot easier than the
build-architectural change of using libgcc itself in the kernel, which is an
issue I'd really rather not fight with the kernel developers on if they
disagree. :-)

[Bug target/67172] [5/6 regression] i686-w64-mingw32 dwarf2 bootstrap fails with undefined reference to __EH_FRAME_BEGIN__

[breedlove.matt at gmail dot com]

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

--- Comment #3 from Matt Breedlove  ---
In gcc/defaults.h, it gets defined via:

/* If we have a definition of INCOMING_RETURN_ADDR_RTX, assume that
   the rest of the DWARF 2 frame unwind support is also provided.  */
#if !defined (DWARF2_UNWIND_INFO) && defined (INCOMING_RETURN_ADDR_RTX)
#define DWARF2_UNWIND_INFO 1
#endif

/* If we have named sections, and we're using crtstuff to run ctors,
   use them for registering eh frame information.  */
#if defined (TARGET_ASM_NAMED_SECTION) && DWARF2_UNWIND_INFO \
&& !defined (EH_FRAME_IN_DATA_SECTION)
#ifndef EH_FRAME_SECTION_NAME
#define EH_FRAME_SECTION_NAME ".eh_frame"
#endif
#endif


This then gets pulled in to gcc/c-family/c-cppbuiltin.c at:

#ifdef EH_FRAME_SECTION_NAME
  builtin_define_with_value ("__LIBGCC_EH_FRAME_SECTION_NAME__",
 EH_FRAME_SECTION_NAME, 1);
#endif


INCOMING_RETURN_ADDR_RTX gets defined in gcc/config/i386/i386.h and
TARGET_ASM_NAMED_SECTION is defined in gcc/config/i386/cygming.h which is used
by both cygwin and mingw.  Cygwin, however, has their own EH specific blocks
and because many of the headers are shared between it and mingw, I'm unsure
where this actually belongs.  

In addition, libgcc/config/i386/cygming-crtbegin.c defines __EH_FRAME_BEGIN__
via the following:

#if DWARF2_UNWIND_INFO
static EH_FRAME_SECTION_CONST char __EH_FRAME_BEGIN__[]
  __attribute__((used, section(__LIBGCC_EH_FRAME_SECTION_NAME__), aligned(4)))
  = { };

This passes and the symbol for it can be seen within the nm output included in
the additional_notes.txt file attached to the bug.  Both of these files compile
with __LIBGCC_EH_FRAME_SECTION_NAME__ set seen below but fail the link.

crtbegin.i:

# 97 "../../../gcc/libgcc/config/i386/cygming-crtbegin.c"
static char __EH_FRAME_BEGIN__[]
  __attribute__((used, section(".eh_frame"), aligned(4)))
  = { };


__main_s.i:

#pragma GCC visibility pop
# 2216 "../../../gcc/libgcc/libgcc2.c" 2
extern unsigned char __EH_FRAME_BEGIN__[];



With all the target-specific blocks in the common cygwin/mingw headers, I
didn't want to go messing around with things without input since I was told
EH_FRAME_SECTION_NAME shouldn't be defined for mingw and having it undefined
will fail a number of blocks that are protected merely by DWARF2_UNWIND_INFO
being defined.  The patch merely restores things back to pre-5.0 but whether
the definitions were correct then or simply masked an underlying issue and
allowed linking to pass, I'm not sure.  I have the full build temps in case
anyone requires additional documentation.

[Bug target/67172] [5/6 regression] i686-w64-mingw32 dwarf2 bootstrap fails with undefined reference to __EH_FRAME_BEGIN__

[joseph at codesourcery dot com]

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

--- Comment #2 from joseph at codesourcery dot com  ---
Well, making libgcc use a host-side target macro again certainly isn't the 
right fix.  Why is EH_FRAME_SECTION_NAME differently defined when building 
c-cppbuiltin.c and when building libgcc2.c?  Whatever the cause is, you 
should fix the host-side build so that __LIBGCC_EH_FRAME_SECTION_NAME__ 
doesn't get defined inappropriately (probably meaning that 
EH_FRAME_SECTION_NAME isn't defined when building c-cppbuiltin.c).

[Bug lto/66014] 5.1 mingw64 fails to perform slim bootstrap-lto: ccEt8YNj.ltrans4.ltrans.o::(.text+0x628): undefined reference to `stpcpy'

[breedlove.matt at gmail dot com]

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

--- Comment #3 from Matt Breedlove  ---
Created attachment 36166
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36166&action=edit
Patch to bypass sys_siglist and disable stpcpy builtin during bootstrap

I'm currently using this patch which overrides sys_siglist detection in
addition to the stpcpy built-in when building libiberty which prevents lto
bootstrapping.

sys_siglist causes failures in both slim and fat lto bootstraps in the later
stages while the stpcpy issue remains present only within slim bootstrapping.

[Bug target/67172] [5/6 regression] i686-w64-mingw32 dwarf2 bootstrap fails with undefined reference to __EH_FRAME_BEGIN__

[breedlove.matt at gmail dot com]

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

--- Comment #1 from Matt Breedlove  ---
Seems to have started with r214954.  Here's the direct link to the ML post:

https://gcc.gnu.org/ml/gcc-patches/2014-09/msg00409.html

Per discussions with Kai, EH_FRAME_SECTION_NAME shouldn't be getting defined
for mingw-w64 which it isn't while compiling libgcc2.c however the change to
using _LIBGCC_EH_FRAME_SECTION_NAME__ which *is* defined while compiling this
file ends up breaking linking.  This is mingw specific as the modified code is
in a block surrounded by an #ifndef __CYGWIN__.  The complexities of gcc's
dwarf2 code especially during bootstrapping are a bit beyond me.  The patch
above merely restores GCC 4.9 behavior for mingw but whether the change should
be implemented there or in a target-specific section, I'm not sure.

[Bug fortran/63921] [F08] pointer function as lvalue doesn't work when the function is a type bound function

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Severity|critical|normal

--- Comment #3 from Dominique d'Humieres  ---
Reset the importance to normal: as for today there are 854 open PRs and several
hundreds of them are more or as 'critical' than this one.

If this PR is really critical for you, you should consider to fix it yourself
(or hire someone to do it for you).

[Bug tree-optimization/54803] Rotates are not vectorized

[miyuki at gcc dot gnu.org]

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

Mikhail Maltsev  changed:

   What|Removed |Added

 CC||miyuki at gcc dot gnu.org

--- Comment #4 from Mikhail Maltsev  ---
On x86_64 the testcase is also vectorized. For example, with -O3
-march=haswell:

.L9:
vmovdqa (%r9,%rax), %ymm0
addq$1, %r8
vpsrlq  $32, %ymm0, %ymm1
vpsllq  $32, %ymm0, %ymm0
vpor%ymm0, %ymm1, %ymm0
vmovdqa %ymm0, (%r9,%rax)
addq$32, %rax
cmpq%r8, %rcx
ja  .L9

On bdver2 vprotq insn is used:

.L14:
incq%rcx
vprotq  $32, (%rax,%r8), %xmm0
vmovaps %xmm0, (%rdx,%r8)
addq$16, %r8
cmpq%r10, %rcx
jb  .L14

[Bug libfortran/67140] undefined reference to _gfortran_mvbits_i16

[kargl at gcc dot gnu.org]

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

--- Comment #12 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Mon Aug 10 21:45:01 2015
New Revision: 226769

URL: https://gcc.gnu.org/viewcvs?rev=226769&root=gcc&view=rev
Log:
2015-08-10  Steven G. Kargl  

PR libfortran/67140
* intrinsics/mvbits.c: Fix build for paltforms without c_int128_t.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/intrinsics/mvbits.c

[Bug libfortran/67140] undefined reference to _gfortran_mvbits_i16

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #11 from kargl at gcc dot gnu.org ---
Reclose.

[Bug libfortran/67140] undefined reference to _gfortran_mvbits_i16

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #10 from Steve Kargl  ---
On Mon, Aug 10, 2015 at 09:40:51PM +, hjl.tools at gmail dot com wrote:
> > 
> > Index: intrinsics/mvbits.c
> > ===
> > --- intrinsics/mvbits.c (revision 226764)
> > +++ intrinsics/mvbits.c (working copy)
> > @@ -84,6 +84,7 @@ SUB_NAME (const TYPE *from, const int *f
> >  #  undef TYPE
> >  #  undef UTYPE
> >  
> > +#if defined (HAVE_GFC_INTEGER_16)
> >  #  define TYPE GFC_INTEGER_16
> >  #  define UTYPE GFC_UINTEGER_16
> >  #  define SUB_NAME mvbits_i16
> > @@ -92,3 +93,4 @@ SUB_NAME (const TYPE *from, const int *f
> >  #  undef TYPE
> >  #  undef UTYPE
> >  #endif
> > +#endif
> 
> It builds on x86.
> 

Thanks.  I'll commit a fix in a few moments.

[Bug libfortran/67140] undefined reference to _gfortran_mvbits_i16

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #9 from H.J. Lu  ---
(In reply to Steve Kargl from comment #8)
> Sorry about that.  Can you tst this diff?
> 
> Index: intrinsics/mvbits.c
> ===
> --- intrinsics/mvbits.c (revision 226764)
> +++ intrinsics/mvbits.c (working copy)
> @@ -84,6 +84,7 @@ SUB_NAME (const TYPE *from, const int *f
>  #  undef TYPE
>  #  undef UTYPE
>  
> +#if defined (HAVE_GFC_INTEGER_16)
>  #  define TYPE GFC_INTEGER_16
>  #  define UTYPE GFC_UINTEGER_16
>  #  define SUB_NAME mvbits_i16
> @@ -92,3 +93,4 @@ SUB_NAME (const TYPE *from, const int *f
>  #  undef TYPE
>  #  undef UTYPE
>  #endif
> +#endif

It builds on x86.

[Bug libfortran/67140] undefined reference to _gfortran_mvbits_i16

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #8 from Steve Kargl  ---
On Mon, Aug 10, 2015 at 09:24:53PM +, hjl.tools at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67140
> 
> --- Comment #7 from H.J. Lu  ---
> (In reply to kargl from comment #6)
> > Fixed on trunk.  
> > 
> > The GFORTRAN_1.6 section of the symbol map where I've inserted
> > the _gfortan_mvbits_i16 symbol does not exist in 5-branch.  If
> > the other functions in this section are backported, then this
> > function can also be backported.
> 
> On Linux/x86, I got
> 
> ../../../src-trunk/libgfortran/intrinsics/mvbits.c:87:16: error: unknown type
> name ???GFC_INTEGER_16???
>  #  define TYPE GFC_INTEGER_16
> ^
> ../../../src-trunk/libgfortran/intrinsics/mvbits.c:36:29: note: in expansion 
> of
> macro ???TYPE???
>  extern void SUB_NAME (const TYPE *, const int *, const int *, TYPE *,
> 

Sorry about that.  Can you tst this diff?

Index: intrinsics/mvbits.c
===
--- intrinsics/mvbits.c (revision 226764)
+++ intrinsics/mvbits.c (working copy)
@@ -84,6 +84,7 @@ SUB_NAME (const TYPE *from, const int *f
 #  undef TYPE
 #  undef UTYPE

+#if defined (HAVE_GFC_INTEGER_16)
 #  define TYPE GFC_INTEGER_16
 #  define UTYPE GFC_UINTEGER_16
 #  define SUB_NAME mvbits_i16
@@ -92,3 +93,4 @@ SUB_NAME (const TYPE *from, const int *f
 #  undef TYPE
 #  undef UTYPE
 #endif
+#endif

[Bug libfortran/67140] undefined reference to _gfortran_mvbits_i16

[hjl.tools at gmail dot com]

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

--- Comment #7 from H.J. Lu  ---
(In reply to kargl from comment #6)
> Fixed on trunk.  
> 
> The GFORTRAN_1.6 section of the symbol map where I've inserted
> the _gfortan_mvbits_i16 symbol does not exist in 5-branch.  If
> the other functions in this section are backported, then this
> function can also be backported.

On Linux/x86, I got

../../../src-trunk/libgfortran/intrinsics/mvbits.c:87:16: error: unknown type
name ‘GFC_INTEGER_16’
 #  define TYPE GFC_INTEGER_16
^
../../../src-trunk/libgfortran/intrinsics/mvbits.c:36:29: note: in expansion of
macro ‘TYPE’
 extern void SUB_NAME (const TYPE *, const int *, const int *, TYPE *,

[Bug fortran/63921] [F08] pointer function as lvalue doesn't work when the function is a type bound function

[mirco.valentini at polimi dot it]

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

mirco  changed:

   What|Removed |Added

   Severity|normal  |critical

[Bug pch/56549] #pragma once ineffective with BOM in include file

[tanner at gmx dot net]

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

Tom Tanner  changed:

   What|Removed |Added

 CC||tanner at gmx dot net

--- Comment #3 from Tom Tanner  ---
confirmed with g++ 4.2.1, 4.7.4, 4.8.5 and 4.9.3

[Bug c++/67178] [concepts] ICE on self-referencing concept

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-08-10
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug c++/67178] New: [concepts] ICE on self-referencing concept

[adrian.wielgosik at gmail dot com]

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

Bug ID: 67178
   Summary: [concepts] ICE on self-referencing concept
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: adrian.wielgosik at gmail dot com
  Target Milestone: ---

Created attachment 36165
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36165&action=edit
compiler output

template 
concept bool SomeConcept = requires(SomeConcept val) {
{ val };
};

void function(SomeConcept) {}

int main() {
function(1);
}


Revision 226764. Attached compiler output.

[Bug libfortran/67140] undefined reference to _gfortran_mvbits_i16

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #6 from kargl at gcc dot gnu.org ---
Fixed on trunk.  

The GFORTRAN_1.6 section of the symbol map where I've inserted
the _gfortan_mvbits_i16 symbol does not exist in 5-branch.  If
the other functions in this section are backported, then this
function can also be backported.

[Bug sanitizer/67168] Asan crashes on program startup

[kcc at gcc dot gnu.org]

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

Kostya Serebryany  changed:

   What|Removed |Added

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

--- Comment #1 from Kostya Serebryany  ---
- don't add -lsan. -fsanitize=address is all you need. 
- please provide more details.
- check if lsan works for you on a simple synthetic test case, e.g. grab some
from https://github.com/llvm-mirror/compiler-rt/tree/master/test/lsan/TestCases
- does the lsan in fresh clang work for you? 

Since the bug report is not actionable at this point I am closing it.
Please reopen when the above bullets are checked.

[Bug libfortran/67140] undefined reference to _gfortran_mvbits_i16

[kargl at gcc dot gnu.org]

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

--- Comment #5 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Mon Aug 10 17:42:00 2015
New Revision: 226764

URL: https://gcc.gnu.org/viewcvs?rev=226764&root=gcc&view=rev
Log:
2015-08-10  Steven G. Kargl  

PR libfortran/67140
* gfortran.map: Add _gfortran_mvbits_i16.
* intrinsics/mvbits.c: Generate mvbits for c_int128_t.

2015-08-10  Francois-Xavier Coudert  

PR libfortran/67140
* gfortran.dg/pr67140.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr67140.f90
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libgfortran/ChangeLog
trunk/libgfortran/gfortran.map
trunk/libgfortran/intrinsics/mvbits.c

[Bug tree-optimization/67175] gcc.dg/vect/trapv-vect-reduc-4.c FAILs

[vries at gcc dot gnu.org]

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

--- Comment #1 from vries at gcc dot gnu.org ---
Created attachment 36164
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36164&action=edit
tentative patch

Does this patch fix the fail on sparc?

[Bug middle-end/66332] goacc/acc_on_device-2.c scan-rtl-dump-times expand testsuite failure

[tschwinge at gcc dot gnu.org]

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

--- Comment #6 from Thomas Schwinge  ---
Author: tschwinge
Date: Mon Aug 10 16:48:26 2015
New Revision: 226763

URL: https://gcc.gnu.org/viewcvs?rev=226763&root=gcc&view=rev
Log:
[PR libgomp/65742, PR middle-end/66332] libgomp: Remove plugin for non-shared
memory host execution

gcc/
* builtins.c (expand_builtin_acc_on_device) [ACCEL_COMPILER]: Emit
open-coded sequence.
* omp-low.c (oacc_process_reduction_data): Remove handline of
GOMP_DEVICE_HOST_NONSHM.
gcc/testsuite/
* c-c++-common/goacc/acc_on_device-2.c: Remove XFAIL for C.
include/
* gomp-constants.c (GOMP_DEVICE_HOST_NONSHM): Remove.
libgomp/
* libgomp-plugin.h (enum offload_target_type): Remove
OFFLOAD_TARGET_TYPE_HOST_NONSHM.
* openacc.f90 (openacc_kinds): Remove acc_device_host_nonshm.
* openacc.h (enum acc_device_t): Likewise.
* openacc_lib.h: Likewise.
* oacc-init.c (name_of_acc_device_t): Don't handle it.
(acc_on_device): Just use __builtin_acc_on_device.
* testsuite/libgomp.oacc-c-c++-common/if-1.c: Don't forbid usage
of acc_on_device builtin.
* plugin/plugin-host.h: Remove file.
* plugin/plugin-host.c: Likewise, but salvage some content into...
* oacc-host.c: ... this file.
* plugin/Makefrag.am: Don't build libgomp-plugin-host_nonshm.la.
* plugin/configfrag.ac (offload_targets): Don't add host_nonshm.
* Makefile.in: Regenerate.
* configure: Likewise.
* testsuite/lib/libgomp.exp
(check_effective_target_openacc_host_nonshm_selected): Remove.
* testsuite/libgomp.oacc-c++/c++.exp: Don't handle
ACC_DEVICE_TYPE=host_nonshm.
* testsuite/libgomp.oacc-c/c.exp: Likewise.
* testsuite/libgomp.oacc-fortran/fortran.exp: Likewise.
* testsuite/libgomp.oacc-c-c++-common/acc_on_device-1.c: Likewise.
* testsuite/libgomp.oacc-fortran/acc_on_device-1-1.f90: Likewise.
* testsuite/libgomp.oacc-fortran/acc_on_device-1-2.f: Likewise.
* testsuite/libgomp.oacc-fortran/acc_on_device-1-3.f: Likewise.

Removed:
trunk/libgomp/plugin/plugin-host.c
trunk/libgomp/plugin/plugin-host.h
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/omp-low.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/goacc/acc_on_device-2.c
trunk/include/ChangeLog
trunk/include/gomp-constants.h
trunk/libgomp/ChangeLog
trunk/libgomp/Makefile.in
trunk/libgomp/configure
trunk/libgomp/libgomp-plugin.h
trunk/libgomp/oacc-host.c
trunk/libgomp/oacc-init.c
trunk/libgomp/openacc.f90
trunk/libgomp/openacc.h
trunk/libgomp/openacc_lib.h
trunk/libgomp/plugin/Makefrag.am
trunk/libgomp/plugin/configfrag.ac
trunk/libgomp/testsuite/lib/libgomp.exp
trunk/libgomp/testsuite/libgomp.oacc-c++/c++.exp
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/acc_on_device-1.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/if-1.c
trunk/libgomp/testsuite/libgomp.oacc-c/c.exp
trunk/libgomp/testsuite/libgomp.oacc-fortran/acc_on_device-1-1.f90
trunk/libgomp/testsuite/libgomp.oacc-fortran/acc_on_device-1-2.f
trunk/libgomp/testsuite/libgomp.oacc-fortran/acc_on_device-1-3.f
trunk/libgomp/testsuite/libgomp.oacc-fortran/fortran.exp

[Bug fortran/67177] New: MOVE_ALLOC not automatically allocating deferred character arrays in derived types

[templed at tcd dot ie]

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

Bug ID: 67177
   Summary: MOVE_ALLOC not automatically allocating deferred
character arrays in derived types
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: templed at tcd dot ie
  Target Milestone: ---

(First time submitting a bug, apologies if I've messed up somewhere)

When a derived type containing a deferred-length character variable is the TO=
argument of a MOVE_ALLOC() call the character length is not correctly set and
the value of the variable is not stored.

Two workarounds for this is to either not use deferred-length character
variables (use an allocatable array of single characters), or to preallocate
the length to the variable that will be the TO= argument.

The below test program has been tested with Intel 15.0.2 (20150121) and, when
the line critical line is commented out (see code) the program correctly
allocates the deferred-length string and populates it with the correct value.
In gfortran 5.2 (and 4.9.2, FWIW) it fails to allocate the length and store the
value even though a check with allocated() returns true.


$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/support/modules/gnu-5.2/libexec/gcc/x86_64-unknown-linux-gnu/5.2.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/usr/support/modules/gnu-5.2
--disable-multilib
Thread model: posix
gcc version 5.2.0 (GCC) 


Test program:

program str
implicit none

type string
  character(:), Allocatable :: text
end type string

type strings
  type(string), allocatable, dimension(:) :: strlist
end type strings

type(strings) :: teststrs
type(string) :: tmpstr
integer :: strlen = 20

allocate(teststrs%strlist(1))
allocate(character(len=strlen) :: tmpstr%text)

! This is the critical line. If this is commented then
! the move_alloc fails. Whereas what should happen is that
! this variable should be allocated automatically by move_alloc
allocate(character(len=strlen) :: teststrs%strlist(1)%text)


! Needs blanking otherwise memory is leaked
tmpstr%text(1:20) = ' '
tmpstr%text(1:3) = 'foo'
! Should return "alloc?, strlen F20" when the critical line is
commented out (shows 'T' otherwise)
write(*,*)'alloc?, strlen
',allocated(teststrs%strlist(1)%text),len(tmpstr%text)
call move_alloc(tmpstr%text,teststrs%strlist(1)%text)
! Should return "alloc?, strlen T20"
write(*,*)'alloc?, strlen
',allocated(teststrs%strlist(1)%text),len(teststrs%strlist(1)%text)
! Should return "foo "
write(*,*)'"',teststrs%strlist(1)%text,'"'

end program str

[Bug c++/66460] ICE using __func__ in constexpr function.

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||colu...@gmx-topmail.de

--- Comment #2 from Markus Trippelsdorf  ---
*** Bug 66292 has been marked as a duplicate of this bug. ***

[Bug c++/66460] ICE using __func__ in constexpr function.

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||anton.kalmykov at gmail dot com

--- Comment #3 from Markus Trippelsdorf  ---
*** Bug 67176 has been marked as a duplicate of this bug. ***

[Bug c++/67176] Segmentation fault

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #1 from Markus Trippelsdorf  ---
dup.

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

[Bug c++/66292] ICE in constexpr call evaluation

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #5 from Markus Trippelsdorf  ---
dup.

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

[Bug c++/67176] New: Segmentation fault

[anton.kalmykov at gmail dot com]

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

Bug ID: 67176
   Summary: Segmentation fault
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anton.kalmykov at gmail dot com
  Target Milestone: ---

Created attachment 36163
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36163&action=edit
source file to reproduce the issue

Compilation of the attached source produces segmentation fault.

GCC invoke command: gcc -std=c++14 ./foo.cpp

gcc -v:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/gcc-multilib/src/gcc-5.2.0/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=gcc4-compatible
Thread model: posix
gcc version 5.2.0 (GCC) 


Additionally, here is a link to ideone.com where I have reproduced this issue:
https://ideone.com/rgn4kb

[Bug c++/67151] internal compiler error: in tsubst, at cp/pt.c:12126

[nickolay.merkin at gmail dot com]

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

--- Comment #3 from Nickolay Merkin  ---
(In reply to Markus Trippelsdorf from comment #2)
> Already fixed in gcc-5 branch and trunk.

Thank you!

[Bug c/16351] NULL dereference warnings

[law at redhat dot com]

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

--- Comment #44 from Jeffrey A. Law  ---
Duh, I should have remembered that we had returns_nonnull because I wrote a
dataflow pass to find any NULLs that flow to such statements :-)

The pieces that are missing are tagging functions with that attribute when we
can prove they never return NULL.  We'll be relying a lot of IPA to present
functions in the right order, but it'd be a good improvement.

[Bug c++/67151] internal compiler error: in tsubst, at cp/pt.c:12126

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #2 from Markus Trippelsdorf  ---
Already fixed in gcc-5 branch and trunk.

[Bug c++/67151] internal compiler error: in tsubst, at cp/pt.c:12126

[nickolay.merkin at gmail dot com]

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

Nickolay Merkin  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code

--- Comment #1 from Nickolay Merkin  ---
Yet another ICE in same location

http://ideone.com/yxsgWl

unsigned constexpr foo(int (*p)[1]) { return 0ULL; }
int constexpr foo(void* p) { return 0; }

template auto const bar = foo((int(*)[N])nullptr);
template int const buz = (true ? -1 : bar) / 2;

int main() {
//  auto x = bar<1>; // uncomment to eliminate ICE
auto y = buz<1>; // ICE!!!
}

Now, we deal with valid code. The ICE appears only if the right operand,
bar<1>, has not been instantiated yet. As soon as it has been instantiated
(uncommment the x), all works well.

In this example I tried to show how the type of ignored operand may change the
result of the operation. Compare buz<1> and buz<2>. But the ICE does not let me
show that.

No recursion, no obvious error. Thus, I add the keyword 'ice-on-valid-code'.

[Bug libstdc++/67173] experimental/filesystem/operations/current_path.cc FAILs

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-08-10
  Component|c++ |libstdc++
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug lto/65995] LTO: ICE in add_symbol_to_partition_1 for debug build

[zerolo at gmail dot com]

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

Daniel Vollmer  changed:

   What|Removed |Added

 CC||zerolo at gmail dot com

--- Comment #6 from Daniel Vollmer  ---
I'm seeing the same ICE in GCC 5.2.0 for x86_64 on Darwin. Unfortunately I
cannot provide the code in question (C++11, heavy template usage, computational
simulation code) and was unable to reduce the problem. I seem to recall that
the code (or at least a slightly earlier version of it) compiled fine with LTO
with 4.9.

Disabling partitioning with "-flto-partition=none" works around the ICE.

The link invocation is
g++-5 -v -flto -g -fopenmp -dynamiclib -Wl,-compatibility_version,1
-Wl,-current_version,1 src/SpatialDiscretization/DiscretizationFactory.cpp.5.o
src/SpatialDiscretization/Instantiations.cpp.5.o
src/SpatialDiscretization/InstantiationsFV.cpp.5.o -o
/Users/maven/Development/dlr/dx/negev/build/libSpatialDiscretization.dylib -L.
-L/Users/maven/Development/dlr/flowsim/packages-gcc/fsdm/lib -L/usr/local/lib
-L/Users/maven/Development/dlr/flowsim/packages/utparmetis/lib -L/usr/local/lib
-L/usr/local/lib -lDiscreteEquation -lDistributed -lParallel -lDXCommon
-lFSMesh -lFSRelationsModel -lFSDataLog -lFSBoundaryCondition -lFSCommon -lmpi
-lxml2 -lnetcdf -lhdf5_hl -lhdf5 -lcgns -lutparmetis -lutmetis -lutgklib
-lzoltan -lmpi

The reported error is
lto1: internal compiler error: in add_symbol_to_partition_1, at
lto/lto-partition.c:211

lto1: internal compiler error: Abort trap: 6
g++-5: internal compiler error: Abort trap: 6 (program lto1)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper: fatal error: g++-5 returned 4 exit status
compilation terminated.
collect2: fatal error: lto-wrapper returned 1 exit status
compilation terminated.


The complete output of the command run with -v is
g++-5 -v -flto -g -fopenmp -dynamiclib -Wl,-compatibility_version,1
-Wl,-current_version,1 src/SpatialDiscretization/DiscretizationFactory.cpp.5.o
src/SpatialDiscretization/Instantiations.cpp.5.o
src/SpatialDiscretization/InstantiationsFV.cpp.5.o -o
/Users/maven/Development/dlr/dx/negev/build/libSpatialDiscretization.dylib -L.
-L/Users/maven/Development/dlr/flowsim/packages-gcc/fsdm/lib -L/usr/local/lib
-L/Users/maven/Development/dlr/flowsim/packages/utparmetis/lib -L/usr/local/lib
-L/usr/local/lib -lDiscreteEquation -lDistributed -lParallel -lDXCommon
-lFSMesh -lFSRelationsModel -lFSDataLog -lFSBoundaryCondition -lFSCommon -lmpi
-lxml2 -lnetcdf -lhdf5_hl -lhdf5 -lcgns -lutparmetis -lutmetis -lutgklib
-lzoltan -lmpi
Using built-in specs.
COLLECT_GCC=g++-5
COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc/5.2.0/libexec/gcc/x86_64-apple-darwin14.4.0/5.2.0/lto-wrapper
Target: x86_64-apple-darwin14.4.0
Configured with: ../configure --build=x86_64-apple-darwin14.4.0
--prefix=/usr/local/Cellar/gcc/5.2.0
--libdir=/usr/local/Cellar/gcc/5.2.0/lib/gcc/5
--enable-languages=c,c++,objc,obj-c++ --program-suffix=-5
--with-gmp=/usr/local/opt/gmp --with-mpfr=/usr/local/opt/mpfr
--with-mpc=/usr/local/opt/libmpc --with-isl=/usr/local/opt/isl
--with-system-zlib --enable-libstdcxx-time=yes --enable-stage1-checking
--enable-checking=release --enable-lto --with-build-config=bootstrap-debug
--disable-werror --with-pkgversion='Homebrew gcc 5.2.0 --without-fortran
--without-multilib' --with-bugurl=https://github.com/Homebrew/homebrew/issues
--enable-plugin --disable-nls --disable-multilib
Thread model: posix
gcc version 5.2.0 (Homebrew gcc 5.2.0 --without-fortran --without-multilib) 
COMPILER_PATH=/usr/local/Cellar/gcc/5.2.0/libexec/gcc/x86_64-apple-darwin14.4.0/5.2.0/:/usr/local/Cellar/gcc/5.2.0/libexec/gcc/x86_64-apple-darwin14.4.0/5.2.0/:/usr/local/Cellar/gcc/5.2.0/libexec/gcc/x86_64-apple-darwin14.4.0/:/usr/local/Cellar/gcc/5.2.0/lib/gcc/5/gcc/x86_64-apple-darwin14.4.0/5.2.0/:/usr/local/Cellar/gcc/5.2.0/lib/gcc/5/gcc/x86_64-apple-darwin14.4.0/
LIBRARY_PATH=/usr/local/Cellar/gcc/5.2.0/lib/gcc/5/gcc/x86_64-apple-darwin14.4.0/5.2.0/:/usr/local/Cellar/gcc/5.2.0/lib/gcc/5/gcc/x86_64-apple-darwin14.4.0/5.2.0/../../../:/usr/lib/
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.10.4' '-v' '-flto' '-g' '-fopenmp'
'-Zdynamiclib' '-o'
'/Users/maven/Development/dlr/dx/negev/build/libSpatialDiscretization.dylib'
'-L.' '-L/Users/maven/Development/dlr/flowsim/packages-gcc/fsdm/lib'
'-L/usr/local/lib'
'-L/Users/maven/Development/dlr/flowsim/packages/utparmetis/lib'
'-L/usr/local/lib' '-L/usr/local/lib' '-shared-libgcc' '-mtune=core2'

/usr/local/Cellar/gcc/5.2.0/libexec/gcc/x86_64-apple-darwin14.4.0/5.2.0/collect2
-flto -dynamic -dylib -arch x86_64 -macosx_version_min 10.10.4
-weak_reference_mismatches non-weak -o
/Users/maven/Development/dlr/dx/negev/build/libSpatialDiscretization.dylib -L.
-L/Users/maven/Development/dlr/flowsim/packages-gcc/fsdm/lib -

[Bug tree-optimization/67175] gcc.dg/vect/trapv-vect-reduc-4.c FAILs

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug tree-optimization/67175] New: gcc.dg/vect/trapv-vect-reduc-4.c FAILs

[ro at gcc dot gnu.org]

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

Bug ID: 67175
   Summary: gcc.dg/vect/trapv-vect-reduc-4.c FAILs
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: vries at gcc dot gnu.org
  Target Milestone: ---
  Host: sparc*-sun-solaris2.*
Target: sparc*-sun-solaris2.*
 Build: sparc*-sun-solaris2.*

Created attachment 36162
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36162&action=edit
trapv-vect-reduc-4.c.133t.vect

Between 20150731 and 20150807, a testsuite regression on Solaris/SPARC occured:

FAIL: gcc.dg/vect/trapv-vect-reduc-4.c scan-tree-dump-times vect "vectorized 2
loops" 1

It happens for both 32 and 64-bit and was probably introduced by this patch:

2015-08-01  Tom de Vries  
[...]
* gcc.dg/vect/trapv-vect-reduc-4.c: Update scan to match vectorized min
and max reductions.

  Rainer

[Bug fortran/67174] [6 regression] gfortran.dg/do_iterator.f90 FAILs

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug fortran/67174] New: [6 regression] gfortran.dg/do_iterator.f90 FAILs

[ro at gcc dot gnu.org]

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

Bug ID: 67174
   Summary: [6 regression] gfortran.dg/do_iterator.f90 FAILs
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
  Host: *-*-solaris2.11
Target: *-*-solaris2.11
 Build: *-*-solaris2.11

Since about 20150529 (r223861), there's a testsuite regression on Solaris 11
(both sparc and x86, both 32 and 64-bit):

FAIL: gfortran.dg/do_iterator.f90   -O  changing do-iterator 3 (test for
errors, line 10)
FAIL: gfortran.dg/do_iterator.f90   -O  changing do-iterator 3 (test for
errors, line 9)

  Rainer

[Bug fortran/67171] [6.0 regression] sourced allocation

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-08-10
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Revision r223090 is OK, r223694 is not.

[Bug c++/67173] New: experimental/filesystem/operations/current_path.cc FAILs

[ro at gcc dot gnu.org]

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

Bug ID: 67173
   Summary: experimental/filesystem/operations/current_path.cc
FAILs
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: redi at gcc dot gnu.org
  Target Milestone: ---
  Host: *-*-solaris2.10
Target: *-*-solaris2.10
 Build: *-*-solaris2.10

Sometime between 20150724 (r226149) and 20150731 (r226440),
experimental/filesystem/operations/current_path.cc started to FAIL on Solaris
10
only (Solaris 11 is still fine):

terminate called after throwing an instance of
'std::experimental::filesystem::v1::__cxx11::filesystem_error'
  what():  filesystem error: cannot canonicalize: Invalid argument [/tmp]
Abort

I suspect this is due to this change:

2015-07-30  Jonathan Wakely  

* testsuite/experimental/filesystem/operations/current_path.cc: Use
canonical paths for comparisons.

  Rainer

[Bug c++/67173] experimental/filesystem/operations/current_path.cc FAILs

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug c++/66735] [C++14] lambda init-capture fails for const references

[aaron.mcdaid at gmail dot com]

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

aaron.mcdaid at gmail dot com changed:

   What|Removed |Added

 CC||aaron.mcdaid at gmail dot com

--- Comment #1 from aaron.mcdaid at gmail dot com ---
I'm also seeing the same problem, and another very similar issue:

int main() {
const int x = 0;
auto l = [&rx = x]() {};
}

This is rejected by g++ (4.9.3 and 5.2.0) but accepted  by clang. Also
discussed on StackOverflow: http://stackoverflow.com/q/31919260/146041

[Bug target/67172] New: [5/6 regression] i686-w64-mingw32 dwarf2 bootstrap fails with undefined reference to __EH_FRAME_BEGIN__

[breedlove.matt at gmail dot com]

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

Bug ID: 67172
   Summary: [5/6 regression] i686-w64-mingw32 dwarf2 bootstrap
fails with undefined reference to __EH_FRAME_BEGIN__
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: breedlove.matt at gmail dot com
CC: alexpux at gmail dot com, ktietz70 at googlemail dot com,
mingw.android at gmail dot com
  Target Milestone: ---
  Host: i686-w64-mingw32
Target: i686-w64-mingw32
 Build: i686-w64-mingw32

Created attachment 36161
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36161&action=edit
Build notes, save-temps, object files

GCC 5/6 branches fail to bootstrap starting with the beginning of GCC 5
releases configured as:

./configure \
--prefix=/mingw32 --with-local-prefix=/mingw32/local \
--build=i686-w64-mingw32 --host=i686-w64-mingw32
--target=i686-w64-mingw32 \
--with-native-system-header-dir=/mingw32/i686-w64-mingw32/include \
--libexecdir=/mingw32/lib \
--with-gxx-include-dir=/mingw32/include/c++/6.0.0 \
--enable-bootstrap \
--with-arch=i686 --with-tune=generic \
--enable-languages=c,lto,c++ \
--enable-shared --enable-static \
--enable-threads=posix \
--enable-libatomic --enable-graphite --enable-fully-dynamic-string \
--enable-libstdcxx-time=yes \
--disable-libstdcxx-pch --disable-libstdcxx-debug \
--enable-version-specific-runtime-libs \
--disable-isl-version-check \
--enable-lto --enable-libgomp --enable-checking=release \
--disable-multilib --disable-rpath --disable-win32-registry
--disable-nls --disable-werror --disable-symvers \
--with-libiconv --with-system-zlib \
--with-gmp=/mingw32 --with-mpfr=/mingw32 --with-mpc=/mingw32
--with-isl=/mingw32 \
--with-gnu-as --with-gnu-ld \
--disable-sjlj-exceptions --with-dwarf2


Problem discussed here:

http://sourceforge.net/p/msys2/mailman/msys2-users/thread/c48f5a81-8875-4b57-8668-d1d737c8a...@gmail.com/



The following patch reverts behavior to pre-5.0 behavior and allows building
and is in active use in msys2:


diff --git a/libgcc/libgcc2.c b/libgcc/libgcc2.c
index c737620..e5ab209 100644
--- a/libgcc/libgcc2.c
+++ b/libgcc/libgcc2.c
@@ -2211,7 +2211,7 @@ TRANSFER_FROM_TRAMPOLINE
 /* Some ELF crosses use crtstuff.c to provide __CTOR_LIST__, but use this
code to run constructors.  In that case, we need to handle EH here, too. 
*/

-#ifdef __LIBGCC_EH_FRAME_SECTION_NAME__
+#ifdef EH_FRAME_SECTION_NAME
 #include "unwind-dw2-fde.h"
 extern unsigned char __EH_FRAME_BEGIN__[];
 #endif
@@ -2231,7 +2231,7 @@ __do_global_dtors (void)
   (*(p-1)) ();
 }
 #endif
-#if defined (__LIBGCC_EH_FRAME_SECTION_NAME__) && !defined (HAS_INIT_SECTION)
+#if defined (EH_FRAME_SECTION_NAME) && !defined (HAS_INIT_SECTION)
   {
 static int completed = 0;
 if (! completed)
@@ -2250,7 +2250,7 @@ __do_global_dtors (void)
 void
 __do_global_ctors (void)
 {
-#ifdef __LIBGCC_EH_FRAME_SECTION_NAME__
+#ifdef EH_FRAME_SECTION_NAME
   {
 static struct object object;
 __register_frame_info (__EH_FRAME_BEGIN__, &object);



I've attached the build logs, -save-temps=obj output, and some additional
notes.  If you can't find what you need in that file, I've put what couldn't
fit or probably isn't really wanted below:

https://drive.google.com/file/d/0B6Y2OcAf3yVKWTRaaWxtSEJjMGM/view?usp=sharing

[Bug fortran/67171] [6.0 regression] sourced allocation

[vehre at gcc dot gnu.org]

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

--- Comment #1 from vehre at gcc dot gnu.org ---
First working thesis on this:

offset of d is errorneously propagate to tmp.

A suitable workaround is to wrap the last allocate in an associate:

associate (t => tmp(1:50,:))
allocate( d( 50, 2 ), source = t , stat=errstat )
end associate

[Bug fortran/67171] New: [6.0 regression] sourced allocation

[mexas at bristol dot ac.uk]

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

Bug ID: 67171
   Summary: [6.0 regression] sourced allocation
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mexas at bristol dot ac.uk
CC: vehre at gcc dot gnu.org
  Target Milestone: ---

program z
implicit none

real, allocatable :: d(:,:), tmp(:,:)
integer :: i, errstat

allocate( d( 100, 2 ), source = 0.0, stat=errstat )

d(:,1) = (/ ( real(i), i=1,100) /)
d(:,2) = (/ ( real(2*i), i=1,100) /)

write (*,*) d( 1, :) 
call move_alloc( from=d, to=tmp )
write (*,*) tmp( 1, :) 
allocate( d( 50, 2 ), source = tmp(1:50,:) , stat=errstat )
write (*,*) d( 1, :) 
deallocate( tmp )

end program z 

Correct output in gfortran 5:

$ gfortran5 -Wl,-rpath=/usr/local/lib/gcc5 z.f90
$ ./a.out 
   1.   2.
   1.   2.
   1.   2.

Wrong output in gfortran 6:

$ gfortran6 -Wl,-rpath=/usr/local/lib/gcc6 z.f90 
$ ./a.out 
   1.   2.
   1.   2.
   4.   0.

This is on FreeBSD 10.1-RELEASE-p16 amd64

[Bug middle-end/66214] [6 Regression] ICE verify_type failed with -O0 -g via gen_type_die_with_usage's dwarf2out.c:20250

[burnus at gcc dot gnu.org]

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

--- Comment #11 from Tobias Burnus  ---
Another test case is the GIT version of LLVM, which fails when compiling 
ExecutionEngine.cpp for Debug+Asserts build.

[Bug tree-optimization/67153] [5/6 Regression] integer optimizations 53% slower than std::bitset<>

[ncm at cantrip dot org]

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

--- Comment #5 from ncm at cantrip dot org ---
My preliminary conclusion is that a hardware optimization provided in Haswell
but not in Westmere is not recognizing the opportunity in the unsigned int
test case, that it finds in the original bitset version, as compiled by gcc-5.

I have also observed that adding an assertion that the array index is not
negative, before the first array access, slows the program a further 100%, 
on Westmere.

Note that the entire data set fits in L3 cache on all tested targets, so
memory bandwidth does not figure.

To my inexperienced eye the effects look like branch mispredictions.
I do not understand why a 3.4 GHz DDR3 Haswell runs as slowly as a 
2.4 GHz DDR2 Westmere, when branch prediction (or whatever it is) 
fails.

[Bug tree-optimization/67153] [5/6 Regression] integer optimizations 53% slower than std::bitset<>

[ncm at cantrip dot org]

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

--- Comment #4 from ncm at cantrip dot org ---
Also fails 5.2.1 (Debian 5.2.1--15) 5.2.1 20150808
As noted, the third version of the program, using bitset but not using
lambdas, is as slow as the version using unsigned int -- even when built
using gcc-4.9.  (Recall the int version and the first bitset version
run fast when built with gcc-4.9.)

Confirmed that on Westmere, compiled -march=native, all versions 
run about the same speed with all versions of the compiler reported,
and this runtime is about the same as the slow Haswell speed despite
the very different clock rate.

[Bug fortran/67170] PRE can't hoist out a readonly argument

[mliska at suse dot cz]

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

--- Comment #1 from Martin Liška  ---
Created attachment 36160
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36160&action=edit
Test case

[Bug fortran/67170] New: PRE can't hoist out a readonly argument

[mliska at suse dot cz]

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

Bug ID: 67170
   Summary: PRE can't hoist out a readonly argument
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mliska at suse dot cz
  Target Milestone: ---

In attached Fortran source file, we are unable to hoist out the single function
argument. The argument is reloaded at the end of loop.

Thanks,
Martin

[Bug c/67169] New: -fstack-check=no doesn't disable stack checking

[dwmw2 at infradead dot org]

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

Bug ID: 67169
   Summary: -fstack-check=no doesn't disable stack checking
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dwmw2 at infradead dot org
  Target Milestone: ---

$ echo 'void foo(void) { char lots[8192]; }' | i686-w64-mingw32-gcc -S -o- -xc
- -fstack-check=no
.file   ""
.text
.globl  _foo
.def_foo;   .scl2;  .type   32; .endef
_foo:
pushl   %ebp
movl%esp, %ebp
movl$8192, %eax
call___chkstk_ms
subl%eax, %esp
nop
leave
ret
.ident  "GCC: (GNU) 5.1.0 20150422 (Fedora MinGW 5.1.0-2.fc22)"


This is causing me problems when building the EDK II UEFI implementation.
Building that with MinGW is useful because it reproduces a number of
LLP64-related issues which would otherwise require Windows to discover.

If I use '-fstack-check=specific' *that* does seem to do what I want. But I'm
not sure I should be suggesting that as an upstream fix for the MinGW build,
because it seems wrong.

[Bug bootstrap/57125] Build not SMP safe; fails to build bconfig.h

[vapier at gentoo dot org]

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

--- Comment #9 from Mike Frysinger  ---
after having the backport deployed in Gentoo, we found an edge case with the
fix in trunk ...

we still have this rule in gcc/Makefile.in:
# Generated source files for gengtype.  Prepend inclusion of
# bconfig.h because AIX requires _LARGE_FILES to be defined before
# any system header is included.
gengtype-lex.c : gengtype-lex.l
-$(FLEX) $(FLEXFLAGS) -o$@ $< && { \
  echo '#include "bconfig.h"' > $@.tmp; \
  cat $@ >> $@.tmp; \
  mv $@.tmp $@; \
}

so even though gengtype-lex.l was adapted to not include bconfig.h when
HOST_GENERATOR_FILE is defined, and the bconfig.h dep on that file was dropped,
the source still tries to always include it for both host & build modes.

i don't really understand the comment ... it seems to me that the lex file will
include the right config.h header files first already, so we should drop the
explicit insertion of bconfig.h here.

[Bug sanitizer/67168] New: Asan crashes on program startup

[bizyaev.game at yandex dot ru]

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

Bug ID: 67168
   Summary: Asan crashes on program startup
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bizyaev.game at yandex dot ru
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
  Target Milestone: ---

I've compiled my program with -fsanitize=address and -lasan, and it crashes
with the following console output:

==4563==Sanitizer CHECK failed:
../../../../src/libsanitizer/asan/asan_malloc_linux.cc:85 ((allocated <
kCallocPoolSize)) != (0) (0, 0)

[Bug c/67167] New: cilkplus vectorization problems

[marcin.krotkiewski at gmail dot com]

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

Bug ID: 67167
   Summary: cilkplus vectorization problems
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marcin.krotkiewski at gmail dot com
  Target Milestone: ---

I think there is a problem with vectorization of arithmetic operations in the
cilkplus implementation in gcc. I have inspected generated asm of the following
two implementations of vector addition (a = a + b). The code is compiled with
'gcc -O3 -mavx -ftree-vectorize -fopt-info-vec -fcilkplus test.c'.


// ICC compatibility - alignment hint
#ifdef __GNUC__

#define __assume_aligned(lvalueptr, align) lvalueptr = __builtin_assume_aligned
(lvalueptr, align)

#endif
#define RESTRICT __restrict__

typedef double Double;

void test(Double * RESTRICT a, Double * RESTRICT b, int size)
{
  int i;

  __assume_aligned(a, 64);
  __assume_aligned(b, 64);

  for(i=0; i

[Bug target/65952] [AArch64] Will not vectorize storing induction of pointer addresses for LP64

[vekumar at gcc dot gnu.org]

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

vekumar at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #11 from vekumar at gcc dot gnu.org ---

This is getting fixed after patch
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=226675

Vectorize mult expressions with power 2 constants via shift, for targets has no
vector multiplication support.

2015-08-06  Venkataramanan Kumar  

* tree-vect-patterns.c (vect_recog_mult_pattern): New function
for vectorizing multiplication patterns.
* tree-vectorizer.h: Adjust the number of patterns.

2015-08-06  Venkataramanan Kumar  

* gcc.dg/vect/vect-mult-pattern-1.c: New test.
* gcc.dg/vect/vect-mult-pattern-2.c: New test.

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

[vekumar at gcc dot gnu.org]

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

Bug 65952 Summary: [AArch64] Will not vectorize storing induction of pointer 
addresses for LP64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65952

   What|Removed |Added

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