[Bug testsuite/80759] gcc.target/x86_64/abi/ms-sysv FAILs

[daniel.santos at pobox dot com]

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

Daniel Santos  changed:

   What|Removed |Added

  Attachment #41543|0   |1
is obsolete||

--- Comment #38 from Daniel Santos  ---
Created attachment 41543
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41543=edit
proposed fix v5 addendum (only partially tested)

I've only run check on RUNTESTFLAGS="ms-sysv.exp" so far and I have a full
regression test running right now, but I *think* this is correct.  I'm
presuming that using .hidden is a no-no as well, at least from what I can tell
it's elf-specific, but I'm not sure what else to do with it other than #ifdef
__ELF__.  (I googled 'hidden elf' and got a lot of interesting fiction...)  So
I'm sorry to just ask you to see if it blows up on Solaris & Darwin w/o gas.

I'm also unsure about my changes to libtgcc/config.host as I just don't have a
broad understanding of all of the *nix platforms out there.

Feedback greatly appreciated!

Thanks,
Daniel

--- Comment #39 from Daniel Santos  ---
Created attachment 41544
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41544=edit
proposed fix v5 addendum (only partially tested)

remove fix stray carriage return...

[Bug testsuite/80759] gcc.target/x86_64/abi/ms-sysv FAILs

[daniel.santos at pobox dot com]

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

--- Comment #38 from Daniel Santos  ---
Created attachment 41543
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41543=edit
proposed fix v5 addendum (only partially tested)

I've only run check on RUNTESTFLAGS="ms-sysv.exp" so far and I have a full
regression test running right now, but I *think* this is correct.  I'm
presuming that using .hidden is a no-no as well, at least from what I can tell
it's elf-specific, but I'm not sure what else to do with it other than #ifdef
__ELF__.  (I googled 'hidden elf' and got a lot of interesting fiction...)  So
I'm sorry to just ask you to see if it blows up on Solaris & Darwin w/o gas.

I'm also unsure about my changes to libtgcc/config.host as I just don't have a
broad understanding of all of the *nix platforms out there.

Feedback greatly appreciated!

Thanks,
Daniel

[Bug c++/81067] [8 regression] g++.dg/template/nontype10.C FAILs

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-12
 CC||dje at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from David Edelsohn  ---
This seems to be failing on all 32 bit targets (IA-32, powerpc -m32, AIX -m32).

[Bug c++/81078] New: dynamic_cast to virtual base produces the wrong answer

[arthur.j.odwyer at gmail dot com]

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

Bug ID: 81078
   Summary: dynamic_cast to virtual base produces the wrong answer
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arthur.j.odwyer at gmail dot com
  Target Milestone: ---

(This was found by the same fuzzer as
https://bugs.llvm.org/show_bug.cgi?id=33425 --- except in this case Clang gets
the right answer and GCC gets it wrong.)

#include 

struct Class2 { virtual ~Class2() {} };
struct Class3 { virtual ~Class3() {} };
struct Class4 : protected virtual Class3, public  Class2 {};
struct Class8 : public virtual Class3, public  Class4 {};

int main() {
Class8 c8;
Class2 *c2 = static_cast();
Class3 *c3 = static_cast();
printf("cast Class3 to Class2: %p\n", dynamic_cast(c3));
printf("cast Class2 to Class3: %p\n", dynamic_cast(c2));
}


Clang and GCC disagree about this code: Clang makes both dynamic_casts succeed,
and GCC makes them both fail (that is, return nullptr). I believe that Clang is
correct and GCC is wrong, because this case is covered by N4618
[expr.dynamic.cast] 5.2.7 /(8.2):

> If C is the class type to which T points or refers, the runtime check 
> logically executes as follows:
>
> (8.1) If, in the most derived object pointed (referred) to by v, v points 
> (refers) to a public base class subobject of a C object, and if only one 
> object of type C is derived from the subobject pointed (referred) to by v the 
> result points (refers) to that C object.
>
> (8.2) Otherwise, if v points (refers) to a public base class subobject of the 
> most derived object, and the type of the most derived object has a base 
> class, of type C, that is unambiguous and public, the result points (refers) 
> to the C subobject of the most derived object.
>
> (8.3) Otherwise, the runtime check fails.


MSVC seems to agree with me and with Clang.

[Bug testsuite/80759] gcc.target/x86_64/abi/ms-sysv FAILs

[daniel.santos at pobox dot com]

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

--- Comment #37 from Daniel Santos  ---
(In reply to Daniel Santos from comment #36)
> tutor!  :)  This is assembly with cpp, so the gas .macro could be replaced
> with a cpp macro, but is that acceptable considering that it would result in
> multiple instructions on the same line delimited by semicolons instead of
> "\n\t"?  So should I just copy & paste the instructions and be done with it?

I forgot to note that even though the gas .macro takes an argument for base
offset, in all uses that offset is 0x60.

[Bug testsuite/80759] gcc.target/x86_64/abi/ms-sysv FAILs

[daniel.santos at pobox dot com]

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

--- Comment #36 from Daniel Santos  ---
Thank you for all of your work on this.  The .cfi directives shouldn't be *too*
critical -- I've barely scratched the surface of learning DWARF and, iirc, the
last time I stepped through these stubs in gdb it still wasn't always able to
determine the call frame correctly (although I could be thinking of stepping
through the assembly code in the test program).  I suppose this can be an issue
for somebody debugging Wine code at some future date, but I have no qualms with
removing it for now, and possibly redoing it later in more portable way (and
that actually provides the debugger with everything it needs).

Also, you *had* mentioned this linking problem in the past and I apologize for
loosing track of it.  I have not actually done a thorough study of ABIs used in
other *nix operating systems, but my guess would be that all 64-bit platforms
that GCC supports use the SystemV ABI except for Windows (Cygwin & MinGW)? 
This is a question outside of my expertise, so please let me know if the below
solution amenable.

I should also note that while this optimization isn't meant for Windows and
would likely almost never appear in code built for windows (unless somebody is
trying to link to objects/libs built on for *nix), support on Windows is
explicitly disabled due to the SEH unwind emit code not supporting
REG_CFA_EXPRESSION, which it requires.  So we don't need the stubs on Windows
anyway.

diff --git a/libgcc/config.host b/libgcc/config.host
index 7711abf2704..f0f0d6c0916 100644
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -1355,6 +1355,14 @@ esac
 case ${host} in
 i[34567]86-*-* | x86_64-*-*)
case ${host} in
+   *-*-cygwin* | *-*-mingw*)
+   ;;
+   *)
+   tmake_file="${tmake_file} i386/t-msabi"
+   ;;
+   esac
+
+   case ${host} in
*-musl*)
tmake_file="${tmake_file} i386/t-cpuinfo-static"
;;
@@ -1365,11 +1373,12 @@ i[34567]86-*-* | x86_64-*-*)
;;
 esac

+
 case ${host} in
 i[34567]86-*-linux* | x86_64-*-linux* | \
   i[34567]86-*-kfreebsd*-gnu | x86_64-*-kfreebsd*-gnu | \
   i[34567]86-*-gnu*)
-   tmake_file="${tmake_file} t-tls i386/t-linux i386/t-msabi
t-slibgcc-libgcc"
+   tmake_file="${tmake_file} t-tls i386/t-linux t-slibgcc-libgcc"
if test "$libgcc_cv_cfi" = "yes"; then
tmake_file="${tmake_file} t-stack i386/t-stack-i386"
fi


As for the stubs, I don't think there's a real need to stay tied to gas
extensions -- truth be told, this was my first actual non-inline, x86 assembly
code I have written (last time I did assembly prior was on a Motorola
6502/6510), so I'm sorry to have forced you to become my unwitting tutor!  :) 
This is assembly with cpp, so the gas .macro could be replaced with a cpp
macro, but is that acceptable considering that it would result in multiple
instructions on the same line delimited by semicolons instead of "\n\t"?  So
should I just copy & paste the instructions and be done with it?

Thanks,
Daniel

[Bug fortran/52473] CSHIFT slow - inline it?

[tkoenig at gcc dot gnu.org]

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

--- Comment #12 from Thomas Koenig  ---
Created attachment 41542
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41542=edit
Test case which still fails

[Bug fortran/52473] CSHIFT slow - inline it?

[tkoenig at gcc dot gnu.org]

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

--- Comment #11 from Thomas Koenig  ---
Created attachment 41541
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41541=edit
Patch for the library, not yet quite correct

This is a patch which brings a dramatic speedup for
any cshift with dim>1, but it also causes a regression for
a test case which I will attach next.

[Bug libstdc++/81076] __byte_operand is not SFINAE-friendly

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-06-12
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Target Milestone|--- |7.2
 Ever confirmed|0   |1

[Bug c++/80265] __builtin_{memcmp,memchr,strlen} are not usable in constexpr functions

[palves at gcc dot gnu.org]

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

--- Comment #19 from palves at gcc dot gnu.org ---
Author: palves
Date: Mon Jun 12 22:22:39 2017
New Revision: 249137

URL: https://gcc.gnu.org/viewcvs?rev=249137=gcc=rev
Log:
Finish implementing P0426R1 "Constexpr for std::char_traits" for C++17

As discussed in PR c++/80265 ("__builtin_{memcmp,memchr,strlen} are
not usable in constexpr functions"), use __builtin_constant_p to tell
whether we can defer to a constexpr algorithm.

I used __always_inline__ just to be thorough.  It isn't really really
necessary as far as I could determine.

Changes like these:

 if (__n == 0)
   return 0;
 -  return wmemcmp(__s1, __s2, __n);
 +  else
 +return wmemcmp(__s1, __s2, __n);

are necessary otherwise G++ complains that we're calling a
non-constexpr function, which looks like a a manifestation of PR67026
to me.

libstdc++-v3:
2017-06-12  Pedro Alves  

* doc/xml/manual/status_cxx2017.xml: Update C++17 constexpr
char_traits status.
* doc/html/*: Regenerate.

* include/bits/char_traits.h (_GLIBCXX_ALWAYS_INLINE): Define if
not already defined.
(__cpp_lib_constexpr_char_traits): Uncomment.
(__constant_string_p, __constant_char_array_p): New.
(std::char_traits, std::char_traits): Add
_GLIBCXX17_CONSTEXPR on compare, length and find and use
__constant_string_p, __constant_char_array_p and
__builtin_constant_p to defer to __gnu_cxx::char_traits at compile
time.

* testsuite/21_strings/char_traits/requirements/
constexpr_functions_c++17.cc: Uncomment
__cpp_lib_constexpr_char_traits tests.  Uncomment
test_compare, test_length, test_find,
test_compare, test_length and test_find
static_assert tests.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/doc/xml/manual/status_cxx2017.xml
trunk/libstdc++-v3/include/bits/char_traits.h
   
trunk/libstdc++-v3/testsuite/21_strings/char_traits/requirements/constexpr_functions_c++17.cc

[Bug c/81077] linker constants are randomized

[gregory.mounie at imag dot fr]

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

Grégory Mounié  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Grégory Mounié  ---
Output due to the randomization of the virtual address space

The use of -fno-pie -no-pie at compile and link time solve the "bug".

[Bug c/81077] linker constants are randomized

[gregory.mounie at imag dot fr]

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

--- Comment #2 from Grégory Mounié  ---
  Yes ! It correct my problem. I should have found it alone.

  Sorry for the inconvenience and thanks for lightning speed answer.
  Grégory

Le 12/06/2017 à 23:02, pinskia at gcc dot gnu.org a écrit :
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81077
>
> Andrew Pinski  changed:
>
>What|Removed |Added
> 
>  Status|UNCONFIRMED |WAITING
>Last reconfirmed||2017-06-12
>  Ever confirmed|0   |1
>
> --- Comment #1 from Andrew Pinski  ---
> -fPIE is default for the compiler you are using so they are definitely going 
> to
> be randomized.
>
> Use -fno-pie -no-pie when compiling if you want non-random virtual addresses.
>

[Bug c/81077] linker constants are randomized

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-06-12
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
-fPIE is default for the compiler you are using so they are definitely going to
be randomized.

Use -fno-pie -no-pie when compiling if you want non-random virtual addresses.

[Bug c/81077] New: linker constants are randomized

[gregory.mounie at imag dot fr]

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

Bug ID: 81077
   Summary: linker constants are randomized
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gregory.mounie at imag dot fr
  Target Milestone: ---

Created attachment 41540
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41540=edit
printf of two linker constants using & and [] notations

When compiling with linker constants, the constants values does not have the
given values but looks randomized. They change values at each execution.
Theses constants have really only an address but no values. The symbol table of
the executable is still correct according to objdump.

Code of my test file (testld.c (the .i file is in attachment)
#include 

extern unsigned char liloo;
extern unsigned char lilootab[];

static void * spa = & liloo;
static void * sta = lilootab;

int main() {
void * pa = & liloo;
void * ta = lilootab;
printf("%p %p %p %p\n", spa, sta, pa, ta);
return 0;
}

Command line of compilation:
gcc -v -save-temps -Wl,--defsym=liloo=0x100 -Wl,--defsym=lilootab=0x200
testld.c -o testld

Output of the compilation:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 6.3.0-18'
--with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-6 --program-prefix=x86_64-linux-gnu- --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--with-target-system-zlib --enable-objc-gc=auto --enable-multiarch
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 6.3.0 20170516 (Debian 6.3.0-18) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'testld' '-mtune=generic'
'-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/6/cc1 -E -quiet -v -imultiarch x86_64-linux-gnu
testld.c -mtune=generic -march=x86-64 -fpch-preprocess -o testld.i
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/6/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-linux-gnu/6/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/6/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'testld' '-mtune=generic'
'-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/6/cc1 -fpreprocessed testld.i -quiet -dumpbase
testld.c -mtune=generic -march=x86-64 -auxbase testld -version -o testld.s
GNU C11 (Debian 6.3.0-18) version 6.3.0 20170516 (x86_64-linux-gnu)
compiled by GNU C version 6.3.0 20170516, GMP version 6.1.2, MPFR
version 3.1.5, MPC version 1.0.3, isl version 0.15
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C11 (Debian 6.3.0-18) version 6.3.0 20170516 (x86_64-linux-gnu)
compiled by GNU C version 6.3.0 20170516, GMP version 6.1.2, MPFR
version 3.1.5, MPC version 1.0.3, isl version 0.15
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 0fe3e671dc62e01e15c40cc5df58cb5f
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'testld' '-mtune=generic'
'-march=x86-64'
 as -v --64 -o testld.o testld.s
Version de l'assembleur GNU 2.28 (x86_64-linux-gnu) utilisant la version BFD
(GNU Binutils for Debian) 2.28
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/6/:/usr/lib/gcc/x86_64-linux-gnu/6/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/6/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/6/:/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/6/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/6/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 

[Bug fortran/80983] [F03] memory leak when calling procedure-pointer component with allocatable result

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

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

[Bug libstdc++/81076] New: __byte_operand is not SFINAE-friendly

[rs2740 at gmail dot com]

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

Bug ID: 81076
   Summary: __byte_operand is not SFINAE-friendly
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

Because the primary template is left undefined, the cv specializations of
__byte_operand causes a hard error for nonintegral types:

#include 

template void to_integer(...);

using t = decltype(to_integer(std::byte{}));
using t = void;

[Bug target/81075] [avr] Move jump-tables out of .text

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Target||avr
   Priority|P3  |P4
   Assignee|unassigned at gcc dot gnu.org  |gjl at gcc dot gnu.org

[Bug target/81075] New: [avr] Move jump-tables out of .text

[gjl at gcc dot gnu.org]

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

Bug ID: 81075
   Summary: [avr] Move jump-tables out of .text
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---

Since PR71151 has been fixed (v6.2), we have JUMP_TABLES_IN_TEXT_SECTION.  This
means that branches that cross such tables have larger branch offsets than
before that fix.  Hence resurrect jump tables that are not in .text.

[Bug target/80968] stack frame reference allowed in delay slot of return instruction

[davem at gcc dot gnu.org]

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

--- Comment #10 from davem at gcc dot gnu.org ---
Author: davem
Date: Mon Jun 12 19:32:49 2017
New Revision: 249135

URL: https://gcc.gnu.org/viewcvs?rev=249135=gcc=rev
Log:
More refinements to fixing sparc's PR target/80968.

PR target/80968
* config/sparc/sparc.md (return expander): Emit frame blockage if
function uses alloca.


Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/sparc/sparc.md

[Bug target/80968] stack frame reference allowed in delay slot of return instruction

[davem at gcc dot gnu.org]

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

--- Comment #9 from davem at gcc dot gnu.org ---
Author: davem
Date: Mon Jun 12 19:30:45 2017
New Revision: 249134

URL: https://gcc.gnu.org/viewcvs?rev=249134=gcc=rev
Log:
More refinements to fixing sparc's PR target/80968.

gcc/

PR target/80968
* config/sparc/sparc.md (return expander): Emit frame blockage if
function uses alloca.




Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sparc/sparc.md

[Bug c++/81074] New: [7 regression] Nested template specialization causes segmentation fault

[jan at ypmania dot nl]

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

Bug ID: 81074
   Summary: [7 regression] Nested template specialization causes
segmentation fault
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jan at ypmania dot nl
  Target Milestone: ---

Created attachment 41539
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41539=edit
Source file causing the segfault

The attached test.cpp defines a partially specialized template inside of a
template, i.e. as

template 
struct Outer {
  template 
  struct Inner {};

  template 
  struct Inner { ... };
};

and causes a segmentation fault while trying to resolve constexpr's inside
Inner. The problem goes away if I flatten the structure, moving the inner
templates into the global namespace.

This is possibly related / duplicate of #55639; however, the code compiled fine
under GCC 6 and 5 (compiler explorer verifies this).

GCC Output: ---

$ gcc -v -save-temps test.cpp
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/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 --disable-multilib --disable-werror
--enable-checking=release
Thread model: posix
gcc version 7.1.1 20170516 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/cc1plus -E -quiet -v -D_GNU_SOURCE
test.cpp -mtune=generic -march=x86-64 -fpch-preprocess -o test.ii
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../include/c++/7.1.1

/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../include/c++/7.1.1/x86_64-pc-linux-gnu
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../include/c++/7.1.1/backward
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/include
 /usr/local/include
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/cc1plus -fpreprocessed test.ii -quiet
-dumpbase test.cpp -mtune=generic -march=x86-64 -auxbase test -version -o
test.s
GNU C++14 (GCC) version 7.1.1 20170516 (x86_64-pc-linux-gnu)
compiled by GNU C version 7.1.1 20170516, GMP version 6.1.2, MPFR
version 3.1.5-p2, MPC version 1.0.3, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++14 (GCC) version 7.1.1 20170516 (x86_64-pc-linux-gnu)
compiled by GNU C version 7.1.1 20170516, GMP version 6.1.2, MPFR
version 3.1.5-p2, MPC version 1.0.3, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 74aace2f6deb87bb86dbfd7a28ebe524
test.cpp: In substitution of ‘template struct Outer::Varint<_fieldIdx, unsigned char, field> [with
unsigned char _fieldIdx = 1; uint8_t Msg::* field = ::a]’:
test.cpp:5:30:   required from ‘constexpr const uint8_t
HighestMaxFieldIdx
>::maxFieldIdx’
test.cpp:25:95:   required from here
test.cpp:5:30: internal compiler error: Segmentation fault
 static constexpr uint8_t maxFieldIdx = T::fieldIdx;
  ^~~

[Bug other/80803] libgo appears to be miscompiled on powerpc64le since r247497

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 CC||su at cs dot ucdavis.edu

--- Comment #31 from Martin Jambor  ---
*** Bug 81063 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/81063] [8 Regression] wrong code at -O1 and above on x86_64-linux-gnu

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Jambor  ---
Hi, this is a duplicate on the issue I was working on last week (sorry
for the breakage).  I have just posted patches to address this issue
to the mailing list:

  - https://gcc.gnu.org/ml/gcc-patches/2017-06/msg00833.html
  - https://gcc.gnu.org/ml/gcc-patches/2017-06/msg00834.html

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

[Bug other/80803] libgo appears to be miscompiled on powerpc64le since r247497

[jamborm at gcc dot gnu.org]

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

--- Comment #30 from Martin Jambor  ---
I have posted the following two patches to fix this issue to the
mailing list.  The second one also includes two simple C testcases:

  - https://gcc.gnu.org/ml/gcc-patches/2017-06/msg00833.html
  - https://gcc.gnu.org/ml/gcc-patches/2017-06/msg00834.html

[Bug libstdc++/55917] Impossible to find/debug unhandled exceptions in an std::thread

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |8.0

--- Comment #17 from Jonathan Wakely  ---
Fixed for GCC 8.

[Bug libstdc++/55917] Impossible to find/debug unhandled exceptions in an std::thread

[redi at gcc dot gnu.org]

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

--- Comment #16 from Jonathan Wakely  ---
Author: redi
Date: Mon Jun 12 16:37:28 2017
New Revision: 249130

URL: https://gcc.gnu.org/viewcvs?rev=249130=gcc=rev
Log:
PR libstdc++/55917 do not handle exceptions in std::thread

PR libstdc++/55917
* src/c++11/thread.cc (execute_native_thread_routine): Remove
try-block so that exceptions propagate out of the thread and terminate
is called by the exception-handling runtime.
(execute_native_thread_routine_compat): Likewise.
* testsuite/30_threads/thread/cons/terminate.cc: New.

Added:
trunk/libstdc++-v3/testsuite/30_threads/thread/cons/terminate.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/src/c++11/thread.cc

[Bug c/81050] ICE with -fexec-charset=utf-16

[joseph at codesourcery dot com]

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

--- Comment #2 from joseph at codesourcery dot com  ---
That's not a valid execution character set (unless char is at least 16 
bits, which doesn't currently apply to any GCC target).  "The basic 
character set shall be present and each character shall be encoded as a 
single byte." and "A byte with all bits zero shall be interpreted as a 
null character independent of shift state. Such a byte shall not occur as 
part of any other multibyte character.".

It would be reasonable to reject any attempt to set the execution 
character set to UTF-16, UTF-32 or any other character sets where any 
member of the basic character set is mapped to more than one byte, or that 
use the zero byte as part of another character.

[Bug c++/81073] [5/6/7/8 Regression] link failure as C++ misses to instanciate some objects

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #2 from Jonathan Wakely  ---
r217662 is correct (i.e. defines the variable), r217663 gives an ICE, which
persists until r217748 which compiles it again but fails to define the
variable.

commit da7981e061ae97c7f83ed4ace5cf725e6fe0cffb
Author: jason 
Date:   Wed Nov 19 03:03:39 2014 +

* constexpr.c (cxx_eval_statement_list): Handle statement-expressions.
(potential_constant_expression_1): Handle STMT_EXPR.

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

[Bug testsuite/80759] gcc.target/x86_64/abi/ms-sysv FAILs

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #35 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> In all cases, I get link errors:
>
> Excess errors:
> Undefined   first referenced
>  symbol in file
> __resms64f_12   /var/tmp//ccRVJueb.o
> __resms64f_13   /var/tmp//ccRVJueb.o
> __resms64f_14   /var/tmp//ccRVJueb.o
> __resms64f_15   /var/tmp//ccRVJueb.o
> __resms64f_16   /var/tmp//ccRVJueb.o
> __resms64f_17   /var/tmp//ccRVJueb.o
> __savms64f_12   /var/tmp//ccRVJueb.o
> __savms64f_13   /var/tmp//ccRVJueb.o
> __savms64f_14   /var/tmp//ccRVJueb.o
> __savms64f_15   /var/tmp//ccRVJueb.o
> __savms64f_16   /var/tmp//ccRVJueb.o
> __savms64f_17   /var/tmp//ccRVJueb.o
> __resms64fx_12  /var/tmp//ccRVJueb.o
> __resms64fx_13  /var/tmp//ccRVJueb.o
> __resms64fx_14  /var/tmp//ccRVJueb.o
> __resms64fx_15  /var/tmp//ccRVJueb.o
> __resms64fx_16  /var/tmp//ccRVJueb.o
> __resms64fx_17  /var/tmp//ccRVJueb.o
> ld: fatal: symbol referencing errors
I've found what's going on here: those functions are from
libgcc/config/i386/{res, sav}ms64*.S.  However,
t-msabi which controls their build is only included for Linux/x86_64
targets, not for Solaris (or Darwin).

If I do this with /bin/as, I get all sorts of assembler errors:

Assembler:
"/var/tmp//ccPz3Pub.s", line 1 : Illegal mnemonic
Near line: ".macro SSE_SAVE off=0"
"/var/tmp//ccPz3Pub.s", line 1 : Syntax error
Near line: ".macro SSE_SAVE off=0"
"/var/tmp//ccPz3Pub.s", line 1 : Syntax error
Near line: ".macro SSE_SAVE off=0"
"/var/tmp//ccPz3Pub.s", line 2 : Syntax error
Near line: " movaps %xmm15,(\off - 0x90)(%rax)"
"/var/tmp//ccPz3Pub.s", line 3 : Syntax error
Near line: " movaps %xmm14,(\off - 0x80)(%rax)"
"/var/tmp//ccPz3Pub.s", line 4 : Syntax error
Near line: " movaps %xmm13,(\off - 0x70)(%rax)"
"/var/tmp//ccPz3Pub.s", line 5 : Syntax error
Near line: " movaps %xmm12,(\off - 0x60)(%rax)"
"/var/tmp//ccPz3Pub.s", line 6 : Syntax error
Near line: " movaps %xmm11,(\off - 0x50)(%rax)"
"/var/tmp//ccPz3Pub.s", line 7 : Syntax error
"/var/tmp//ccPz3Pub.s", line 8 : Syntax error
Near line: " movaps %xmm9, (\off - 0x30)(%rax)"
"/var/tmp//ccPz3Pub.s", line 9 : Syntax error
Near line: " movaps %xmm8, (\off - 0x20)(%rax)"
"/var/tmp//ccPz3Pub.s", line 10 : Syntax error
Near line: " movaps %xmm7, (\off - 0x10)(%rax)"
"/var/tmp//ccPz3Pub.s", line 11 : Syntax error
Near line: " movaps %xmm6, \off(%rax)"
"/var/tmp//ccPz3Pub.s", line 12 : Illegal mnemonic
Near line: ".endm"
"/var/tmp//ccPz3Pub.s", line 12 : Syntax error
Near line: ".endm"
"/var/tmp//ccPz3Pub.s", line 13 : Illegal mnemonic
Near line: ".macro SSE_RESTORE off=0"
"/var/tmp//ccPz3Pub.s", line 13 : Syntax error
Near line: ".macro SSE_RESTORE off=0"
"/var/tmp//ccPz3Pub.s", line 13 : Syntax error
Near line: ".macro SSE_RESTORE off=0"
"/var/tmp//ccPz3Pub.s", line 14 : Syntax error
Near line: " movaps (\off - 0x90)(%rsi), %xmm15"
"/var/tmp//ccPz3Pub.s", line 15 : Syntax error
Near line: " movaps (\off - 0x80)(%rsi), %xmm14"
"/var/tmp//ccPz3Pub.s", line 16 : Syntax error
Near line: " movaps (\off - 0x70)(%rsi), %xmm13"
"/var/tmp//ccPz3Pub.s", line 17 : Syntax error
Near line: " movaps (\off - 0x60)(%rsi), %xmm12"
"/var/tmp//ccPz3Pub.s", line 18 : Syntax error
Near line: " movaps (\off - 0x50)(%rsi), %xmm11"
"/var/tmp//ccPz3Pub.s", line 19 : Syntax error
Near line: " movaps (\off - 0x40)(%rsi), %xmm10"
"/var/tmp//ccPz3Pub.s", line 20 : Syntax error
Near line: " movaps (\off - 0x30)(%rsi), %xmm9"
"/var/tmp//ccPz3Pub.s", line 21 : Syntax error
Near line: " movaps (\off - 0x20)(%rsi), %xmm8"
"/var/tmp//ccPz3Pub.s", line 22 : Syntax error
Near line: " movaps (\off - 0x10)(%rsi), %xmm7"
"/var/tmp//ccPz3Pub.s", line 23 : Syntax error
Near line: " movaps \off(%rsi), %xmm6"
"/var/tmp//ccPz3Pub.s", line 24 : Illegal mnemonic
Near line: ".endm"
"/var/tmp//ccPz3Pub.s", line 24 : Syntax error
Near line: ".endm"
"/var/tmp//ccPz3Pub.s", line 41 : Illegal mnemonic
Near line: " SSE_SAVE off=0x60"
Too many errors - Goodbye
make[2]: *** [/vol/gcc/src/hg/trunk/local/libgcc/shared-object.mk:36:
savms64_s.o] Error 1
make[2]: Leaving directory

[Bug c++/81073] [5/6/7/8 Regression] link failure as C++ misses to instanciate some objects

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-12
  Known to work||4.9.4
Summary|link failure as C++ misses  |[5/6/7/8 Regression] link
   |to instanciate some objects |failure as C++ misses to
   ||instanciate some objects
 Ever confirmed|0   |1
  Known to fail||5.4.0, 6.3.0, 7.1.0, 8.0

--- Comment #1 from Jonathan Wakely  ---
C++98 version that compiles fine with versions before 5.1.0

struct test { const int *addr; };

const test* setup()
{
static const test atest =
{
({ static const int inner = 123;  })
};

return 
}

int main(){}

[Bug middle-end/77926] Add __builtin_iszero

[tnfchris at gcc dot gnu.org]

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

tnfchris at gcc dot gnu.org changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Last reconfirmed||2017-06-12
 Resolution|FIXED   |---
 Ever confirmed|0   |1

--- Comment #3 from tnfchris at gcc dot gnu.org ---
Patch has been reverted to due to late expansion issues and PowerPC failures.

[Bug middle-end/77925] Add __builtin_issubnormal

[tnfchris at gcc dot gnu.org]

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

tnfchris at gcc dot gnu.org changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Last reconfirmed||2017-06-12
 Resolution|FIXED   |---
 Ever confirmed|0   |1

--- Comment #3 from tnfchris at gcc dot gnu.org ---
Patch has been reverted to due to late expansion issues and PowerPC failures.

[Bug middle-end/81052] ICE in verify_dominators, at dominance.c:1184

[ryan.burn at gmail dot com]

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

--- Comment #3 from ryan.burn at gmail dot com ---
The only other gcc I have installed is

g++ (GCC) 7.0.1 20170408 (experimental)
Copyright (C) 2017 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.

I attached the preprocessed output from that compiler as well if it helps.

[Bug middle-end/81052] ICE in verify_dominators, at dominance.c:1184

[ryan.burn at gmail dot com]

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

--- Comment #2 from ryan.burn at gmail dot com ---
Created attachment 41538
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41538=edit
old compiler preprocessed

[Bug sanitizer/81021] stack-use-after-scope false positive error with exceptions

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
Created attachment 41537
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41537=edit
Untested patch

[Bug c++/81073] New: link failure as C++ misses to instanciate some objects

[gjl at gcc dot gnu.org]

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

Bug ID: 81073
   Summary: link failure as C++ misses to instanciate some objects
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---

$ g++ struct.cpp -Os -save-temps

the following C++ test case struct.cpp:


struct test { const int *addr; };

const test* setup()
{
static constexpr test atest =
{
({ static const int inner = 123;  })
};

return 
}

int main(){}


This gives a linker error:

struct.o:(.rodata+0x0): undefined reference to `setup()::inner'

"atest" is initialized as expected with a reference to _ZZ5setupvE5inner, but
that object is never instanciated, resulting in a link failure.

Seeing this with v7.1 on and for x86_64-linux-gnu, also on trunk (future v8).

[Bug sanitizer/81023] False positiv stack-use-after-scope (worked with GCC 6, fails with GCC 7)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Martin Liška  ---
Dup.

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

[Bug sanitizer/81021] stack-use-after-scope false positive error with exceptions

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||d.frey at gmx dot de

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

[Bug target/81072] [avr] Support some XMEGA devices with flash seen in RAM address space.

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug target/81072] [avr] Support some XMEGA devices with flash seen in RAM address space.

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

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

--- Comment #2 from Georg-Johann Lay  ---
Added in v8 and will need

https://sourceware.org/bugzilla/show_bug.cgi?id=21472

for configure to pass.

[Bug target/81072] [avr] Support some XMEGA devices with flash seen in RAM address space.

[gjl at gcc dot gnu.org]

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

--- Comment #1 from Georg-Johann Lay  ---
Author: gjl
Date: Mon Jun 12 12:52:30 2017
New Revision: 249124

URL: https://gcc.gnu.org/viewcvs?rev=249124=gcc=rev
Log:
gcc/
Support multilibs and devices that see flash in RAM address range.

PR target/81072
* config/avr/avr-arch.h (avr_arch_id) : New enum.
(avr_mcu_t) : New field.
(avr_device_specific_features) : New enum.
* config/avr/avr.h (AVR_SHORT_CALLS): New define.
(AVR_HAVE_JMP_CALL): Don't set if AVR_SHORT_CALLS.
(AVR_TINY_PM_OFFSET): Remove macro.
* config/avr/avr.opt (-mshort-calls): New option.
* config/avr/gen-avr-mmcu-specs.c (print_mcu)
[*self_spec]: Add / remove -mshort-calls depending on AVR_ISA_RCALL.
* config/avr/avr-c.c (avr_cpu_cpp_builtins)
<__AVR_SHORT_CALLS__>: Built-in define if AVR_SHORT_CALLS.
<__AVR_HAVE_JMP_CALL__>: Use AVR_HAVE_JMP_CALL as condition
instead of avr_arch->have_jmp_call.
<__AVR_PM_BASE_ADDRESS__>: Built-in define if
avr_arch->flash_pm_offset.
[AVR_TINY] <__AVR_TINY_PM_BASE_ADDRESS__>: Use
avr_arch->flash_pm_offset to define.
* config/avr/avr-devices.c (avr_arch_types): Add initializers for
new field flash_pm_offset.  Add entry for avrxmega3.
(avr_texinfo): Add entry for avrxmega3.
* config/avr/avr-mcus.def: Add entries for: avrxmega3,
attiny212, attiny214,
attiny412, attiny414, attiny416, attiny417,
attiny814, attiny816, attiny817,
attiny1614, attiny1616, attiny1617,
attiny3214, attiny3216, attiny3217.
* config/avr/avr.c (avr_assemble_integer)[AVR_TINY]: Use
avr_arch->flash_pm_offset instead of AVR_TINY_PM_OFFSET.
(avr_print_operand_address) [AVR_TINY]: Same.
(avr_asm_init_sections) : Only patch
callback if avr_arch->flash_pm_offset = 0.
(avr_asm_named_section) : Skip setting it
for rodata if avr_arch->flash_pm_offset != 0.
(avr_encode_section_info) [AVR_TINY]: Adjust comment.
* config/avr/genmultilib.awk (dir_rcall, opt_rcall): New vars.
(opts) [AVR_ISA_RCALL]: Append opt_rcall.
(m_options): Append opt_rcall.
(m_dirnames): Append dir_rcall.
* config/avr/t-multilib: Regenerate.
* configure.ac [target=avr]: Check whether avrxmega3 default
linker description file works as needed.
* configure: Regenerate.
* doc/avr-mmcu.texi: Regenerate.
* doc/invoke.texi (AVR Options) <-mshort-calls>: Document it.
<__AVR_ARCH__>: Document avrxmega3 and 103.
<__AVR_HAVE_JMP_CALL__>: Adjust documentation.
<__AVR_SHORT_CALLS__>: Document it.
<__AVR_PM_BASE_ADDRESS__>: Document it.
* doc/extend.texi (AVR Options) <-mshort-calls>: Document it.
(AVR Variable Attributes) : Document this is
not needed for avrxmega3.
(AVR Named Address Spaces) <__flash>: Dito.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/avr/avr-arch.h
trunk/gcc/config/avr/avr-c.c
trunk/gcc/config/avr/avr-devices.c
trunk/gcc/config/avr/avr-mcus.def
trunk/gcc/config/avr/avr.c
trunk/gcc/config/avr/avr.h
trunk/gcc/config/avr/avr.opt
trunk/gcc/config/avr/gen-avr-mmcu-specs.c
trunk/gcc/config/avr/genmultilib.awk
trunk/gcc/config/avr/t-multilib
trunk/gcc/configure
trunk/gcc/configure.ac
trunk/gcc/doc/avr-mmcu.texi
trunk/gcc/doc/extend.texi
trunk/gcc/doc/invoke.texi

[Bug target/81072] New: [avr] Support some XMEGA devices with flash seen in RAM address space.

[gjl at gcc dot gnu.org]

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

Bug ID: 81072
   Summary: [avr] Support some XMEGA devices with flash seen in
RAM address space.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---

[Bug target/81072] [avr] Support some XMEGA devices with flash seen in RAM address space.

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Target||avr
   Priority|P3  |P4
   Assignee|unassigned at gcc dot gnu.org  |gjl at gcc dot gnu.org

[Bug other/80909] auto-profile.c possible mismatching parentheses in MACRO

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Known to work||8.0

--- Comment #3 from Martin Liška  ---
Fixed on trunk.

[Bug libstdc++/81064] [8 Regression] Inline namespace regression

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Maybe we could take this opportunity to get rid of most of the __8 namespaces
and only have std::__8 and __gnu_cxx::__8, rather than std::__8 and numerous
std::xxx::__8 namespaces.

That would simplify the code, as the correct placement of
__GLIBCXX_BEGIN_NAMESPACE_VERSION and _GLIBCXX_END_NAMESPACE_VERSION is a
constant source of bugs.

[Bug libstdc++/81064] [8 Regression] Inline namespace regression

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
We have this structure in libstdc++:

namespace std
{
  inline namespace __8 { }

  inline namespace literals {
inline namespace chrono_literals { inline namespace __8 { } }
inline namespace complex_literals { inline namespace __8 { } }
inline namespace string_literals { inline namespace __8 { } }
inline namespace string_view_literals { inline namespace __8 { } }
  }
}

The innermost __8 namespaces conflict with std::__8 so we'll need to remove
them. Maybe we can change to:

namespace std
{
  inline namespace __8 {
inline namespace literals {
  inline namespace chrono_literals { }
  inline namespace complex_literals { }
  inline namespace string_literals { }
  inline namespace string_view_literals { }
}
  }
}

[Bug sanitizer/81040] asan false negative if parameter of a global function passed by reference

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #3 from Martin Liška  ---
As mentioned by Richard, currently ASAN is able to protect function variables
that live on stack. In your case the function foo is called with constant that
is then assigned a stack slot which we don't instrument with red zones.

[Bug libstdc++/81064] [8 Regression] Inline namespace regression

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

   Keywords|rejects-valid   |
 Status|ASSIGNED|NEW
  Component|c++ |libstdc++
   Assignee|nathan at gcc dot gnu.org  |unassigned at gcc dot 
gnu.org

[Bug tree-optimization/81041] [8 regression] test case gcc.dg/pr78582.c fails with ICE starting with r249058

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Liška  ---
Fixed.

[Bug tree-optimization/81041] [8 regression] test case gcc.dg/pr78582.c fails with ICE starting with r249058

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
Author: marxin
Date: Mon Jun 12 11:56:32 2017
New Revision: 249120

URL: https://gcc.gnu.org/viewcvs?rev=249120=gcc=rev
Log:
Create an extra BB in profile-generate (PR tree-optimization/81041).

2017-06-12  Martin Liska  

PR tree-optimization/81041
* tree-profile.c (gimple_gen_ic_func_profiler):
Create an extra BB in profile-generate
(gimple_gen_time_profiler): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-profile.c

[Bug tree-optimization/81003] [8 Regression] ICE: tree check: expected ssa_name, have integer_cst in optimize_range_tests_to_bit_test, at tree-ssa-reassoc.c:2782

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Fixed.

[Bug sanitizer/81066] sanitizer_stoptheworld_linux_libcdep.cc:276:22: error: aggregate ‘sigaltstack handler_stack’ has incomplete type and cannot be defined

[joseph at codesourcery dot com]

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

--- Comment #4 from joseph at codesourcery dot com  ---
Using stack_t instead of struct sigaltstack is correct.  However, the type 
declaration should be obtained from .  Nothing outside of glibc 
should ever include  headers or define glibc's __need_* macros; 
those are purely implementation details, not public interfaces, and are 
liable to change incompatibly at any time.

[Bug bootstrap/80897] [8 regression] gnat bootstrap broken on SPARC64/Linux

[ebotcazou at gcc dot gnu.org]

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

--- Comment #8 from Eric Botcazou  ---
Author: ebotcazou
Date: Mon Jun 12 11:28:33 2017
New Revision: 249119

URL: https://gcc.gnu.org/viewcvs?rev=249119=gcc=rev
Log:
PR bootstrap/80897
* exp_ch3.adb (Make_Predefined_Primitive_Specs): Use Positive index.

Modified:
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/exp_ch3.adb

[Bug c++/81060] [8 Regression] ICE with un-expanded parameter pack

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

[Bug c++/81064] [8 Regression] Inline namespace regression

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #3 from Nathan Sidwell  ---
Thanks for the reduced testcase.  This is caused by:
2017-05-26  Nathan Sidwell  

Implement DR2061
* name-lookup.c (push_inline_namespaces): New.
(push_namespace): Look inside inline namespaces.

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#2061

I think I've implemented it correctly, and that the testcase is ill-formed. 
Perhaps we could check whenever creating a new namepace that it doesn't cause
an ambiguity within the 'local' inline namespace tree.  (though, such an
ambiguity could occur on declaring any new name, not just a namespace).

2061. Inline namespace after simplifications
Section: 7.3.1  [namespace.def] Status: CD4 Submitter: Richard Smith   
 Date: 2014-12-18

[Adopted at the February, 2016 meeting.]

After the resolution of issue 1795, 7.3.1 [namespace.def] paragraph 3 now says:

In a named-namespace-definition, the identifier is the name of the
namespace. If the identifier, when looked up (3.4.1 [basic.lookup.unqual]),
refers to a namespace-name (but not a namespace-alias) introduced in the
declarative region in which the named-namespace-definition appears, the
namespace-definition extends the previously-declared namespace. Otherwise, the
identifier is introduced as a namespace-name into the declarative region in
which the named-namespace-definition appears. 

This appears to break code like the following:

  namespace A {
inline namespace b {
  namespace C {
template void f();
  }
}
  }

  namespace A {
namespace C {
  template<> void f() { }
}
  }

because (by definition of “declarative region”) C cannot be used as an
unqualified name to refer to A::b::C within A if its declarative region is
A::b.

Proposed resolution (September, 2015):

Change 7.3.1 [namespace.def] paragraph 3 as follows:

In a named-namespace-definition, the identifier is the name of the
namespace. If the identifier, when looked up (3.4.1 [basic.lookup.unqual]),
refers to a namespace-name (but not a namespace-alias) that was introduced in
the declarative region namespace in which the named-namespace-definition
appears or that was introduced in a member of the inline namespace set of that
namespace, the namespace-definition extends the previously-declared namespace.
Otherwise, the identifier is introduced as a namespace-name into the
declarative region in which the named-namespace-definition appears.

[Bug c/81071] New: __builtin_ia32_movddup has been dropped on 4.8 -> 4.9 release transition

[oder at eleks dot com]

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

Bug ID: 81071
   Summary: __builtin_ia32_movddup has been dropped on 4.8 -> 4.9
release transition
   Product: gcc
   Version: 4.9.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: oder at eleks dot com
  Target Milestone: ---

x86 SSE3 built-in function v2df __builtin_ia32_movddup(v2df) has disappeared
with 4.9 releases.

Also, as of 5.4 release (MinGW) another function - __builtin_ia32_loadss() - is
still in manuals but the compiler does not recognize it.

[Bug ada/81070] [7/8 Regression] build failure for s-intrr.adb

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #6 from Eric Botcazou  ---
.

[Bug ada/81070] [7/8 Regression] build failure for s-intrr.adb

[ebotcazou at gcc dot gnu.org]

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

--- Comment #5 from Eric Botcazou  ---
Author: ebotcazou
Date: Mon Jun 12 10:49:17 2017
New Revision: 249116

URL: https://gcc.gnu.org/viewcvs?rev=249116=gcc=rev
Log:
PR ada/81070
* s-interr-hwint.adb: Reinstate.
* gcc-interface/Makefile.in (RTEMS): Use it again.

Added:
branches/gcc-7-branch/gcc/ada/s-interr-hwint.adb   (props changed)
  - copied unchanged from r249112,
branches/gcc-6-branch/gcc/ada/s-interr-hwint.adb
Modified:
branches/gcc-7-branch/gcc/ada/ChangeLog
branches/gcc-7-branch/gcc/ada/gcc-interface/Makefile.in

Propchange: branches/gcc-7-branch/gcc/ada/s-interr-hwint.adb
('svn:mergeinfo' added)

[Bug ada/81070] [7/8 Regression] build failure for s-intrr.adb

[ebotcazou at gcc dot gnu.org]

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

--- Comment #4 from Eric Botcazou  ---
Author: ebotcazou
Date: Mon Jun 12 10:47:36 2017
New Revision: 249115

URL: https://gcc.gnu.org/viewcvs?rev=249115=gcc=rev
Log:
PR ada/81070
* s-interr-hwint.adb: Reinstate.
* gcc-interface/Makefile.in (RTEMS): Use it again.

Added:
trunk/gcc/ada/s-interr-hwint.adb   (props changed)
  - copied unchanged from r249113,
branches/gcc-6-branch/gcc/ada/s-interr-hwint.adb
Modified:
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/gcc-interface/Makefile.in

Propchange: trunk/gcc/ada/s-interr-hwint.adb
('svn:mergeinfo' added)

[Bug tree-optimization/81003] [8 Regression] ICE: tree check: expected ssa_name, have integer_cst in optimize_range_tests_to_bit_test, at tree-ssa-reassoc.c:2782

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Mon Jun 12 10:45:52 2017
New Revision: 249114

URL: https://gcc.gnu.org/viewcvs?rev=249114=gcc=rev
Log:
PR tree-optimization/81003
* tree-ssa-reassoc.c (force_into_ssa_name): New function.
(update_range_test): Use it instead of force_gimple_operand_gsi.

* gcc.c-torture/compile/pr81003.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr81003.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-reassoc.c

[Bug tree-optimization/66623] Unsafe FP math reduction used in strict math mode

[rguenth at gcc dot gnu.org]

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

Bug 81053 Summary: ICE on valid code at -O3 on x86_64-linux-gnu: in as_a, at 
is-a.h:192
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81053

   What|Removed |Added

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

[Bug tree-optimization/81053] ICE on valid code at -O3 on x86_64-linux-gnu: in as_a, at is-a.h:192

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Mon Jun 12 10:42:57 2017
New Revision: 249113

URL: https://gcc.gnu.org/viewcvs?rev=249113=gcc=rev
Log:
2017-06-12  Richard Biener  

PR tree-optimization/81053
* tree-vect-loop.c (vect_is_simple_reduction): Handle PHI
with backedge value not defined in loop.  Simplify def stmt
compute.

* gcc.dg/torture/pr81053.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr81053.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-loop.c

[Bug tree-optimization/81053] ICE on valid code at -O3 on x86_64-linux-gnu: in as_a, at is-a.h:192

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #6 from Richard Biener  ---
Fixed.

[Bug ada/81070] [7/8 Regression] build failure for s-intrr.adb

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #3 from Eric Botcazou  ---
Fixing.

[Bug ada/81070] [7/8 Regression] build failure for s-intrr.adb

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-12
 CC||ebotcazou at gcc dot gnu.org
Summary|[7/8 Regression] Cannot |[7/8 Regression] build
   |build s-intrr.adb   |failure for s-intrr.adb
 Ever confirmed|0   |1

[Bug ada/81070] [7/8 Regression] Cannot build s-intrr.adb

[ebotcazou at gcc dot gnu.org]

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

--- Comment #2 from Eric Botcazou  ---
Introduced by:

2016-10-13  Ed Falis  

* i-vxinco.adb, i-vxinco.ads: New files.
* impunit.adb: add i-vxinco.ads.
* s-interr-vxworks.adb: add hook for user interrupt connection routine.

2016-10-13  Ed Falis  

* s-interr-hwint.adb, s-interr-vxworks.adb: Rename s-interr-hwint.adb
to s-interr-vxworks.adb.

[Bug ada/81070] [7/8 Regression] Cannot build s-intrr.adb

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||build
   Priority|P3  |P4
   Target Milestone|--- |7.2
Summary|Cannot build s-intrr.adb|[7/8 Regression] Cannot
   ||build s-intrr.adb

[Bug testsuite/80759] gcc.target/x86_64/abi/ms-sysv FAILs

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #34 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
One more data point: I tried to run the ms-sysv.exp tests on
x86_64-apple-darwin and failed initially:

FAIL: gcc.target/x86_64/abi/ms-sysv/ms-sysv.c  -O2 "-DGEN_ARGS=-p0" (test for
excess errors)
Excess errors:
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/ms-sysv.c:168:Unknown
pseudo-op: .global
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/ms-sysv.c:168:Rest
of line ignored. 1st junk character valued 100 (d).
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/do-test.S:51:Unknown
pseudo-op: .global
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/do-test.S:51:Rest
of line ignored. 1st junk character valued 114 (r).
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/do-test.S:73:Unknown
pseudo-op: .global
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/do-test.S:73:Rest
of line ignored. 1st junk character valued 109 (m).
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/do-test.S:96:Unknown
pseudo-op: .global
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/do-test.S:96:Rest
of line ignored. 1st junk character valued 100 (d).
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/do-test.S:97:Unknown
pseudo-op: .cfi_startproc
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/do-test.S:107:Unknown
pseudo-op: .global
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/do-test.S:107:Rest
of line ignored. 1st junk character valued 100 (d).
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/do-test.S:116:Unknown
pseudo-op: .cfi_endproc

There are two issues here: while gas understands .global, the Darwin as
does not.  However, globl is common to both (as can e.g. be seen in
libffi/src/x86/sysv.S), so using it makes the test more portable.

The .cfi_* pseudo-ops are another matter: the same file has this comment

/* Sadly, OSX cctools-as doesn't understand .cfi directives at all.  */

so if frame info is really necessary, it would have to be hand-coded as
in those files.  It seems that it's not, though: just commenting
.cfi_startproc and .cfi_endproc still lets the tests still PASS on
x86_64-pc-linux-gnu.  Older Solaris/x86 assemblers have the same issue,
btw.

I cannot right now test the patched tests on Darwin, but will have to do
so later tonight at home.

Rainer


diff --git a/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/do-test.S
b/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/do-test.S
--- a/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/do-test.S
+++ b/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/do-test.S
@@ -34,7 +34,7 @@ see the files COPYING3 and COPYING.RUNTI
 # endif

 # define FUNC(fn)  \
-   .global fn; \
+   .globl fn;  \
ELFFN_BEGIN(fn);\
 fn:

@@ -94,7 +94,7 @@ FUNC_END(mem_to_regs)

 # NOTE: Not MT safe
 FUNC(do_test_unaligned)
-   .cfi_startproc
+   #.cfi_startproc
# The below alignment checks are to verify correctness of the test
# its self.

@@ -113,7 +113,7 @@ FUNC(do_test_aligned)
 L0:
popf
jmp do_test_body
-.cfi_endproc
+#.cfi_endproc
 FUNC_END(do_test_aligned)
 FUNC_END(do_test_unaligned)

diff --git a/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/ms-sysv.c
b/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/ms-sysv.c
--- a/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/ms-sysv.c
+++ b/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/ms-sysv.c
@@ -156,7 +156,7 @@ static const char *argv0;
 #endif

 #define FUNC_BEGIN(fn) \
-   "   .global " fn "\n"   \
+   "   .globl " fn "\n"\
ELFFN_BEGIN(fn) \
fn ":\n"
 #define FUNC_END(fn) ELFFN_END(fn)

[Bug c++/81045] [7/8 Regression] return type deduction causes dependent types?

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-12
 Ever confirmed|0   |1

[Bug c++/81064] [8 Regression] Inline namespace regression

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
EDG warns for that code:

"ns.cc", line 9: warning: a redeclaration of inline namespace "n1::in" must be
  declared inline
namespace in { }
^


But trunk still rejects it even with that change:

namespace n1 {
  inline namespace in { }
  inline namespace n2 {
inline namespace in { }
  }
}

namespace n1 {
  inline namespace in { }
}


ns.cc:9:20: error: conflicting declaration of namespace ‘n1::in’
   inline namespace in { }
^~
ns.cc:2:20: note: previous declaration of namespace ‘n1::in’ here
   inline namespace in { }
^~

[Bug c++/81064] [8 Regression] Inline namespace regression

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-12
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Confirmed:

namespace n1 {
  inline namespace in { }
  inline namespace n2 {
inline namespace in { }
  }
}

namespace n1 {
  namespace in { }
}

ns.cc:9:13: error: conflicting declaration of namespace ‘n1::in’
   namespace in { }
 ^~
ns.cc:2:20: note: previous declaration of namespace ‘n1::in’ here
   inline namespace in { }
^~


Aside: do we really want to translate "namespace" in diagnostics?

[Bug c++/81067] [8 regression] g++.dg/template/nontype10.C FAILs

[renlin at gcc dot gnu.org]

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

Renlin Li  changed:

   What|Removed |Added

 CC||renlin at gcc dot gnu.org

--- Comment #1 from Renlin Li  ---
I confirm I noticed the same regressions on arm targets.

[Bug ada/81070] Cannot build s-intrr.adb

[sebastian.hu...@embedded-brains.de]

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

--- Comment #1 from Sebastian Huber  ---
The native GNAT is:

gnat --version
GNAT 7.1.1 20170530 [gcc-7-branch revision 248621]

[Bug ada/81070] New: Cannot build s-intrr.adb

[sebastian.hu...@embedded-brains.de]

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

Bug ID: 81070
   Summary: Cannot build s-intrr.adb
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sebastian.hu...@embedded-brains.de
  Target Milestone: ---

On GCC 7.1 branch (34df49547806512c6e1549a58048f161f5fa42bc) I get the
following error while building the Ada run-time support:

make[5]: 's-inmaop.o' is up to date.
/build/git-build/b-gcc-git-arm-rtems4.12/./gcc/xgcc
-B/build/git-build/b-gcc-git-arm-rtems4.12/./gcc/ -nostdinc
-B/build/git-build/b-gcc-git-arm-rtems4.12/arm-rtems4.12/newlib/ -isystem
/build/git-build/b-gcc-git-arm-rtems4.12/arm-rtems4.12/newlib/targ-include
-isystem /home/EB/sebastian_h/archive/gcc-git/newlib/libc/include
-B/opt/rtems-4.12/arm-rtems4.12/bin/ -B/opt/rtems-4.12/arm-rtems4.12/lib/
-isystem /opt/rtems-4.12/arm-rtems4.12/include -isystem
/opt/rtems-4.12/arm-rtems4.12/sys-include-c -g -O2   -W -Wall -gnatpg
-nostdinc   s-interr.adb -o s-interr.o
s-interr.adb:206:06: subprogram "Interrupt_Connect" has wrong convention
s-interr.adb:206:06: does not match "Interrupt_Connector" declared at line 199
s-interr.adb:206:06: probable missing pragma Convention for
"Interrupt_Connector"
../gcc-interface/Makefile:296: recipe for target 's-interr.o' failed
make[5]: *** [s-interr.o] Error 1
make[5]: Leaving directory
'/build/git-build/b-gcc-git-arm-rtems4.12/gcc/ada/rts'
gcc-interface/Makefile:2791: recipe for target 'gnatlib' failed
make[4]: *** [gnatlib] Error 2

Configure command line:

configure --target=arm-rtems4.12 --with-newlib --disable-nls --disable-lto
--disable-plugin --enable-languages=c,c++,ada

[Bug libstdc++/81056] [7/8 Regression] FAIL: 17_intro/names.cc (test for excess errors)

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-12
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
(In reply to John David Anglin from comment #0)
> These errors are caused by following header issues on hpux:
> 
> /mnt/gnu/gcc/objdir/./gcc/include-fixed/sys/types.h:
>typedef struct _physadr { intptr_t r[1]; } *physadr;
> 
> /mnt/gnu/gcc/objdir/./gcc/include-fixed/stdlib.h:
> _NAMESPACE_STD_START
>  inline int abs(int d) { return (d>0)?d:-d; }
> _NAMESPACE_STD_END
> 
> Probably, the use of `r' and `d' in the above circumstances is not a
> problem.  So, I think the test should be adjusted as on AIX.  See attached
> fix.

It's a problem because it means some valid C++ programs that include 
won't compile, but only programs that use 'r' and 'd' as macros, which is
insane. So simply adjusting the test is fine.

The patch is OK for trunk - thanks.

[Bug c++/81047] thread local storage static class members of class type cannot be initialized

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b98-Thread-Local-Edits.html

> The storage for an object of thread storage duration shall be statically 
> initialized before the first statement of the thread startup function. An 
> object of thread storage duration shall not require dynamic initialization. 

So you can't use __thread for objects that require dynamic initialization.

(In reply to Jason Vas Dias from comment #0)
> Incidentally, the error is very confusing - it first claims that it
> is an error to attempt to initialize the TLS variable dynamically, and
> then issues a 'note:' that C++11 supports dynamic initialization of 
> TLS objects - but it doesn't ?

Yes it does, but __thread is not part of C++11.

thread_local is part of C++11, and supports what you're trying to do.

__thread and thread_local are not the same thing.

[Bug target/81069] New: nvptx offloading: "-O1" execution test of "libgomp.oacc-fortran/nested-function-1.f90" timeout/FAIL

[tschwinge at gcc dot gnu.org]

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

Bug ID: 81069
   Summary: nvptx offloading: "-O1" execution test of
"libgomp.oacc-fortran/nested-function-1.f90"
timeout/FAIL
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: openacc
  Severity: major
  Priority: P3
 Component: target
  Assignee: tschwinge at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
  Target Milestone: ---

Merging trunk r239357 (part of the PR72772 "Missed SCEV after pass
reordering@236440" changes) into gomp-4-branch r240825, there is a regression
with nvptx offloading, such that (only) the "-O1" execution test of
"libgomp.oacc-fortran/nested-function-1.f90" FAILs, running into a "WARNING:
program timed out".

[Bug testsuite/80759] gcc.target/x86_64/abi/ms-sysv FAILs

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #33 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #32 from Daniel Santos  ---
> Created attachment 41533
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41533=edit
> 41532: proposed fix v5

I've given this one a whirl (with Solaris/x86 /bin/as only so far), and
we're getting closer: right now, the only ms-sysv tests failing are

FAIL: gcc.target/x86_64/abi/ms-sysv/ms-sysv.c -mcall-ms2sysv-xlogues -O0 -g3
"-DGEN_ARGS=-p0\ --omit-rbp-clobbers" (test for excess errors)
FAIL: gcc.target/x86_64/abi/ms-sysv/ms-sysv.c -mcall-ms2sysv-xlogues -O0 -g3
"-DGEN_ARGS=-p1\ --omit-rbp-clobbers" (test for excess errors)
FAIL: gcc.target/x86_64/abi/ms-sysv/ms-sysv.c -mcall-ms2sysv-xlogues -O0 -g3
"-DGEN_ARGS=-p5\ --omit-rbp-clobbers" (test for excess errors)
FAIL: gcc.target/x86_64/abi/ms-sysv/ms-sysv.c -mcall-ms2sysv-xlogues -O2
"-DGEN_ARGS=-p0\ --omit-rbp-clobbers" (test for excess errors)
FAIL: gcc.target/x86_64/abi/ms-sysv/ms-sysv.c -mcall-ms2sysv-xlogues -O2
"-DGEN_ARGS=-p1\ --omit-rbp-clobbers" (test for excess errors)
FAIL: gcc.target/x86_64/abi/ms-sysv/ms-sysv.c -mcall-ms2sysv-xlogues -O2
"-DGEN_ARGS=-p5\ --omit-rbp-clobbers" (test for excess errors)

In all cases, I get link errors:

Excess errors:
Undefined   first referenced
 symbol in file
__resms64f_12   /var/tmp//ccRVJueb.o
__resms64f_13   /var/tmp//ccRVJueb.o
__resms64f_14   /var/tmp//ccRVJueb.o
__resms64f_15   /var/tmp//ccRVJueb.o
__resms64f_16   /var/tmp//ccRVJueb.o
__resms64f_17   /var/tmp//ccRVJueb.o
__savms64f_12   /var/tmp//ccRVJueb.o
__savms64f_13   /var/tmp//ccRVJueb.o
__savms64f_14   /var/tmp//ccRVJueb.o
__savms64f_15   /var/tmp//ccRVJueb.o
__savms64f_16   /var/tmp//ccRVJueb.o
__savms64f_17   /var/tmp//ccRVJueb.o
__resms64fx_12  /var/tmp//ccRVJueb.o
__resms64fx_13  /var/tmp//ccRVJueb.o
__resms64fx_14  /var/tmp//ccRVJueb.o
__resms64fx_15  /var/tmp//ccRVJueb.o
__resms64fx_16  /var/tmp//ccRVJueb.o
__resms64fx_17  /var/tmp//ccRVJueb.o
ld: fatal: symbol referencing errors

Rainer

[Bug sanitizer/81068] New: Sanitizer memory leak in codecvt_utf8

[piotr.stachura at delphi dot com]

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

Bug ID: 81068
   Summary: Sanitizer memory leak in codecvt_utf8
   Product: gcc
   Version: 5.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: piotr.stachura at delphi dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

Simple string conversion application compiled with -fsanitize=undefined results
in runtime_error and memory leak.

Code:
--
#include 
#include 
#include 

int main()
{
   const uint8_t input_data[] = { 0x22, 0x44, 0xC2, 0x80, 0xC5, 0x96, 0xCD,
0x8B };
   std::wstring_convert converter;
   std::u16string output_string = converter.from_bytes((const
char*)_data[0], (const char*)_data[7]);

   return 0;
}
--

Compilation command:
g++ -fsanitize=address -fsanitize=undefined -std=c++11 1.cpp -o 1

Run results:
/usr/include/c++/5/bits/locale_conv.h:68:48: runtime error: member call on
address 0x6030efe0 which does not point to an object of type
'__codecvt_abstract_base'
0x6030efe0: note: object is of type 'std::codecvt_utf8'
 01 00 80 21  20 3b b7 eb 54 56 00 00  00 00 00 00 be be be be  ff ff 10 00 00
00 00 00  00 00 00 00
  ^~~
  vptr for 'std::codecvt_utf8'
/usr/include/c++/5/bits/codecvt.h:220:36: runtime error: member call on address
0x6030efe0 which does not point to an object of type
'__codecvt_abstract_base'
0x6030efe0: note: object is of type 'std::codecvt_utf8'
 01 00 80 21  20 3b b7 eb 54 56 00 00  00 00 00 00 be be be be  ff ff 10 00 00
00 00 00  00 00 00 00
  ^~~
  vptr for 'std::codecvt_utf8'
/usr/include/c++/5/bits/codecvt.h:202:32: runtime error: member call on address
0x6030efe0 which does not point to an object of type
'__codecvt_abstract_base'
0x6030efe0: note: object is of type 'std::codecvt_utf8'
 01 00 80 21  20 3b b7 eb 54 56 00 00  00 00 00 00 be be be be  ff ff 10 00 00
00 00 00  00 00 00 00
  ^~~
  vptr for 'std::codecvt_utf8'

=
==7612==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 384 byte(s) in 6 object(s) allocated from:
#0 0x7fe5ef1ac911 in realloc
(/usr/lib/x86_64-linux-gnu/libasan.so.2+0x98911)
#1 0x7fe5eee1e093  (/usr/lib/x86_64-linux-gnu/libstdc++.so.6+0x92093)

SUMMARY: AddressSanitizer: 384 byte(s) leaked in 6 allocation(s).

Notes:
- issue also visible on gcc 6.2.0
- without -fsanitize=undefined, no errors and no memory leak.

[Bug sanitizer/81065] UBSAN: false positive as a result of distribution involving different types

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
Oh, and I think it's fine to always distribute

 CST * (x * CST1 + CST2)

in case x * CST1 and CST2 have the same sign.

So the previous fix was incomplete and we now hit

  /* If we were able to eliminate our operation from the first side,
 apply our operation to the second side and reform the PLUS.  */
  if (t1 != 0 && (TREE_CODE (t1) != code || code == MULT_EXPR))
return fold_build2 (tcode, ctype, fold_convert (ctype, t1), op1);

where the code immediately following it is correct:

  /* The last case is if we are a multiply.  In that case, we can
 apply the distributive law to commute the multiply and addition
 if the multiplication of the constants doesn't overflow
 and overflow is defined.  With undefined overflow
 op0 * c might overflow, while (op0 + orig_op1) * c doesn't.  */
  if (code == MULT_EXPR && TYPE_OVERFLOW_WRAPS (ctype))
return fold_build2 (tcode, ctype,
fold_build2 (code, ctype,
 fold_convert (ctype, op0),
 fold_convert (ctype, c)),
op1);


Mine.  Testing

Index: gcc/fold-const.c
===
--- gcc/fold-const.c(revision 249112)
+++ gcc/fold-const.c(working copy)
@@ -6243,7 +6243,7 @@ extract_muldiv_1 (tree t, tree c, enum t

   /* If we were able to eliminate our operation from the first side,
 apply our operation to the second side and reform the PLUS.  */
-  if (t1 != 0 && (TREE_CODE (t1) != code || code == MULT_EXPR))
+  if (t1 != 0 && TREE_CODE (t1) != code)
return fold_build2 (tcode, ctype, fold_convert (ctype, t1), op1);

   /* The last case is if we are a multiply.  In that case, we can

[Bug c++/81067] New: [8 regression] g++.dg/template/nontype10.C FAILs

[ro at gcc dot gnu.org]

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

Bug ID: 81067
   Summary: [8 regression] g++.dg/template/nontype10.C FAILs
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: jason at gcc dot gnu.org
  Target Milestone: ---

Between 20170609 (r249050) and 20170610 (r249098), the
g++.dg/template/nontype10.C 
testcase started to regress:

FAIL: g++.dg/template/nontype10.C  -std=c++11 (test for excess errors)
FAIL: g++.dg/template/nontype10.C  -std=c++14 (test for excess errors)
FAIL: g++.dg/template/nontype10.C  -std=c++98 (test for excess errors)

I'm seeing it on i386-pc-solaris2.12 and sparc-sun-solaris2.12 (32-bit only),
but according to gcc-testresults many more targets are affected.

Excess errors:
/vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/template/nontype10.C:5:28:
warning: converting to non-pointer type 'int' from NULL [-Wconversion-null]
/vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/template/nontype10.C:5:28:
warning: converting to non-pointer type 'int' from NULL [-Wconversion-null]
/vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/template/nontype10.C:5:28:
warning: converting to non-pointer type 'int' from NULL [-Wconversion-null]

The warning moved from l.8, where it's expected, to l.5.

  Rainer

[Bug c++/81067] [8 regression] g++.dg/template/nontype10.C FAILs

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug sanitizer/81065] UBSAN: false positive as a result of distribution involving different types

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-12
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Thanks for reporting these bugs, they are all latent wrong-code even w/o UBSAN.

.original w/o ubsan:

;; Function foo (null)
;; enabled by -tree-original


{
  return (int) x * 14165900 + -77663775;
}


and as usual, it's extract_muldiv ...

(gdb) p debug_generic_expr (op0)
(int) x * 1652 + -9057
$1 = void
(gdb) p debug_generic_expr (op1)
8575

turning that into

(int) x * 14165900 + -77663775


it really means that this kind of distribution is never safe unless we rewrite
the inner multiplication into unsigned arithmetic (given the cast of x we
do have an idea about the value range of the other operand so we could
handle some cases -- but I'd rather not do that in extract_muldiv but
in a match.pd pattern).

I'd love to say bye-bye to extract_muldiv in it's current state...

[Bug sanitizer/81040] asan false negative if parameter of a global function passed by reference

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-12
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
(In reply to Richard Biener from comment #1)
> Likely instrumentation simply is missing
> 
>goo((int*));
> 
> given 'a' lives on the stack.  With static foo and IPA CP applied it
> eventually
> sees a address-taken constant pool reference.

Yes, with -O2 and static function, const prop creates clone of foo, where
variable 'a' lives on stack. Write in goo is checked, but it points to a valid
shadow memory (stack). I'm investigating more.

[Bug c++/81064] [8 Regression] Inline namespace regression

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||rejects-valid
   Target Milestone|--- |8.0
Summary|Inline namespace regression |[8 Regression] Inline
   ||namespace regression

[Bug c++/81061] [7/8 Regression] ICE modifying read-only variable

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |7.2

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #42 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
Just for the record: at r249012 (i.e. before the patches causing PR
bootstrap/81033), I managed to successfully bootstrap
x86_64-apple-darwin16.6.0, x86_64-apple-darwin11.4.2, and
i386-apple-darwin11.4.2.

Thanks.
Rainer

[Bug c++/81060] [8 Regression] ICE with un-expanded parameter pack

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |8.0

[Bug c++/81057] [5/6/7/8 Regression] ICE with broken default template parameter

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||error-recovery
   Priority|P3  |P4
   Target Milestone|--- |5.5

[Bug c++/81055] [5/6/7/8 Regression] ICE with invalid initializer for array new

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |5.5

[Bug libstdc++/81056] [7/8 Regression] FAIL: 17_intro/names.cc (test for excess errors)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.2
Summary|[7,8 Regression] FAIL:  |[7/8 Regression] FAIL:
   |17_intro/names.cc (test for |17_intro/names.cc (test for
   |excess errors)  |excess errors)

[Bug c++/81054] [7/8 Regression] ICE with volatile variable in constexpr function

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |7.2

[Bug c++/81051] lambda capture of this in initialization list with virtual inheritance

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-12
 Ever confirmed|0   |1
  Known to fail||7.1.1, 8.0

--- Comment #1 from Richard Biener  ---
Confirmed.

[Bug fortran/81048] [6/7/8 Regression] incorrect derived type initialization

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.4

[Bug c++/81045] [7/8 Regression] return type deduction causes dependent types?

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||rejects-valid
   Target Milestone|--- |7.2
Summary|[7 Regression] return type  |[7/8 Regression] return
   |deduction causes dependent  |type deduction causes
   |types?  |dependent types?

[Bug middle-end/81046] [8 Regression] FAIL: gcc.dg/pr28796-2.c execution test

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug sanitizer/81040] asan false negative if parameter of a global function passed by reference

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
Likely instrumentation simply is missing

   goo((int*));

given 'a' lives on the stack.  With static foo and IPA CP applied it eventually
sees a address-taken constant pool reference.

[Bug tree-optimization/81041] [8 regression] test case gcc.dg/pr78582.c fails with ICE starting with r249058

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug tree-optimization/81038] [8 regression] test case g++.dg/vect/slp-pr56812.cc fails starting with r248678

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

--- Comment #2 from Richard Biener  ---
Eventually the loop is no longer unrolled (was it?) and is now loop vectorized?
(and that bit is "fragile" because of -fvect-cost-model=dynamic?)

Just guessing.

[Bug bootstrap/81037] Xcode 9 requires back ports on gcc-5-branch and gcc-6-branch for bootstrapping under Xcode 9

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||build
Version|unknown |6.3.1

--- Comment #4 from Richard Biener  ---
The gcc-6 backport is ok (if you want to go ahead).