[Bug c++/80356] [7 Regression] ICE in convert_nontype_argument, at cp/pt.c:6827

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #6 from Markus Trippelsdorf  ---
Fixed. Only three P1 bugs left.

[Bug c++/80267] [7 Regression] Compiling aborts when template/auto/lambda occur in some way

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #6 from Markus Trippelsdorf  ---
Fixed. Thanks.

[Bug c++/80356] [7 Regression] ICE in convert_nontype_argument, at cp/pt.c:6827

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Sun Apr  9 05:38:40 2017
New Revision: 246794

URL: https://gcc.gnu.org/viewcvs?rev=246794=gcc=rev
Log:
PR c++/80356 - ICE with reference to function template argument.

PR c++/79294
* pt.c (convert_nontype_argument_function): Adjust type even with a
value-dependent argument.

Added:
trunk/gcc/testsuite/g++.dg/template/fn-ref1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug c++/79294] [7 Regression] ICE in convert_nontype_argument, at cp/pt.c:6812

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Sun Apr  9 05:38:40 2017
New Revision: 246794

URL: https://gcc.gnu.org/viewcvs?rev=246794=gcc=rev
Log:
PR c++/80356 - ICE with reference to function template argument.

PR c++/79294
* pt.c (convert_nontype_argument_function): Adjust type even with a
value-dependent argument.

Added:
trunk/gcc/testsuite/g++.dg/template/fn-ref1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug c++/80373] non-optimal handling of copying a std::complex

[trippels at gcc dot gnu.org]

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

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 80372 ***

[Bug c++/80372] non-optimal handling of copying a std::complex

[trippels at gcc dot gnu.org]

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

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

[Bug c++/80373] New: non-optimal handling of copying a std::complex

[no...@turm-lahnstein.de]

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

Bug ID: 80373
   Summary: non-optimal handling of copying a std::complex
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: no...@turm-lahnstein.de
  Target Milestone: ---

While copying a std::complex from a memory location to another, four
movsd operations are used. However it is possible to use two movups, which are
faster (at least on some hardware) and need less memory (36 bytes for
movsd-version, but only 16 the the movups-version).

Consider the following example:

#include   
void get(std::complex *res){
   res[1]=res[0];
}

is compiled to:

movsd   (%rdi), %xmm0
movsd   %xmm0, 16(%rdi)
movsd   8(%rdi), %xmm0
movsd   %xmm0, 24(%rdi)
ret

but could be:

movups  (%rdi), %xmm0
movups  %xmm0, 16(%rdi)
ret

That is in fact, what clang and icc17 do.

[Bug c++/80372] New: non-optimal handling of copying a std::complex

[no...@turm-lahnstein.de]

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

Bug ID: 80372
   Summary: non-optimal handling of copying a std::complex
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: no...@turm-lahnstein.de
  Target Milestone: ---

While copying a std::complex from a memory location to another, four
movsd operations are used. However it is possible to use two movups, which are
faster (at least on some hardware) and need less memory (36 bytes for
movsd-version, but only 16 the the movups-version).

Consider the following example:

#include   
void get(std::complex *res){
   res[1]=res[0];
}

is compiled to:

movsd   (%rdi), %xmm0
movsd   %xmm0, 16(%rdi)
movsd   8(%rdi), %xmm0
movsd   %xmm0, 24(%rdi)
ret

but could be:

movups  (%rdi), %xmm0
movups  %xmm0, 16(%rdi)
ret

That is in fact, what clang and icc17 do.

[Bug c++/80267] [7 Regression] Compiling aborts when template/auto/lambda occur in some way

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Sun Apr  9 05:06:08 2017
New Revision: 246793

URL: https://gcc.gnu.org/viewcvs?rev=246793=gcc=rev
Log:
PR c++/80267 - ICE with nested capture of reference

PR c++/60992
* pt.c (tsubst_copy): Handle lookup finding a capture proxy.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-nested6.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug c++/60992] [4.9/4.10 Regression] ICE in tsubst_copy, at cp/pt.c:12637

[jason at gcc dot gnu.org]

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

--- Comment #7 from Jason Merrill  ---
Author: jason
Date: Sun Apr  9 05:06:08 2017
New Revision: 246793

URL: https://gcc.gnu.org/viewcvs?rev=246793=gcc=rev
Log:
PR c++/80267 - ICE with nested capture of reference

PR c++/60992
* pt.c (tsubst_copy): Handle lookup finding a capture proxy.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-nested6.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug fortran/80361] [5/6/7 Regression] bogus recursive call to nonrecursive procedure with -fcheck=recursion

[juergen.reuter at desy dot de]

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

--- Comment #11 from Jürgen Reuter  ---
(In reply to Dominique d'Humieres from comment #10)
> If I remove the final stuff in unit_tests.f90, 
> 
> --- unit_tests_orig.f90   2017-04-08 16:16:57.0 +0200
> +++ unit_tests.f902017-04-08 16:17:20.0 +0200
> @@ -72,7 +72,6 @@ module unit_tests
>   procedure, private :: add => test_results_add
>   procedure, private :: write => test_results_write
>   procedure, private :: report => test_results_report
> - procedure, private :: final => test_results_final
>   procedure :: wrapup => test_results_wrapup
>end type test_results_t
>  
> @@ -144,26 +143,12 @@ contains
>  success = list%n_failure == 0
>end subroutine test_results_report
>  
> -  subroutine test_results_final (list)
> -class(test_results_t), intent(inout) :: list
> -type(test_result_t), pointer :: result
> -do while (associated (list%first))
> -   result => list%first
> -   list%first => result%next
> -   deallocate (result)
> -end do
> -list%last => null ()
> -list%n_success = 0
> -list%n_failure = 0
> -  end subroutine test_results_final
> -
>subroutine test_results_wrapup (list, u, success)
>  class(test_results_t), intent(inout) :: list
>  integer, intent(in) :: u
>  logical, intent(out), optional :: success
>  call list%write (u)
>  if (present (success))  call list%report (success)
> -call list%final ()
>end subroutine test_results_wrapup
>  
>subroutine test (test_proc, name, description, u_log, results)
> 
> I still get with a clean make
> 
> Fortran runtime error: Recursive call to nonrecursive procedure
> '__final_particle_specifiers_Prt_spec_list_t'
> 
> This seems buggy unless I am missing something(?).

I believe that the __final_particle_specifiers_Prt_spec_list_t is none of our
finalisers, but probably one automatic finaliser from the compiler.

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

[palves at redhat dot com]

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

--- Comment #7 from Pedro Alves  ---
TBH, though I do think being able to use different algorithms for
compile/runtime is useful and a good idea, making the __builtin_strlen etc.
builtins works OOTB would of course be great.  I'm merely suggesting the
__builtin_constant_p idea here, in case it has a better chance of having
P0426R1 addressed in GCC7.

Also, AFAICS, GCC doesn't have __builtin_wcslen (and equivalents for 
char16_t/char32_t), etc. yet.  The separate compile/runtime paths approach
allows calling into the C runtime's optimized wcslen (etc.) when not in a
compile-time context without having to depend on adding the built-ins.

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

[palves at redhat dot com]

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

--- Comment #6 from Pedro Alves  ---
Hmm.  I'd argue that __builtin_constant_p should return true in that case,
since we're in a constexpr?

In any case, changing the test like this:

-   if (__builtin_constant_p (s))
+   if (__builtin_constant_p (s[0]))

makes that work.  I.e, this compiles:


#include 

constexpr size_t constexpr_strlen(const char* s)
{
  size_t count = 0;

  while (*s++)
count++;

  return count;
}

template 
struct ce_char_traits : std::char_traits
{
  using char_type = typename std::char_traits::char_type;

  static constexpr std::size_t length(const char_type* s) noexcept
  {
if (__builtin_constant_p (s[0]))
  return constexpr_strlen (s);

return __builtin_strlen (s);
  }
};

static_assert (ce_char_traits::length ("") == 0);
static_assert (ce_char_traits::length ("hello") == 5);
static_assert (ce_char_traits::length ("he\0llo") == 2);

static const char array[] = "foo";
static_assert (ce_char_traits::length (array) == 3);

constexpr bool str()
{
  char s[] = "str";
  return ce_char_traits::length(s) == 3;
}

constexpr bool str1()
{
  char s[] = "str";
  s[0] = 'l';
  s[1] = '\0';
  return ce_char_traits::length(s) == 1;
}

constexpr bool str2()
{
  char s[3] {};
  s[0] = 'l';
  s[1] = '\0';
  return ce_char_traits::length(s) == 1;
}

constexpr bool str3()
{
  char s = {};
  return ce_char_traits::length() == 0;
}

static_assert( str() );
static_assert( str1() );
static_assert( str2() );
static_assert( str3() );

[Bug rtl-optimization/70478] [LRA] S/390: Performance regression - superfluous stack frame

[vmakarov at gcc dot gnu.org]

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

--- Comment #9 from Vladimir Makarov  ---
Author: vmakarov
Date: Sat Apr  8 19:18:42 2017
New Revision: 246789

URL: https://gcc.gnu.org/viewcvs?rev=246789=gcc=rev
Log:
2017-04-08  Vladimir Makarov  

PR rtl-optimization/70478
* lra-constraints.c: Reverse the last patch.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-constraints.c

[Bug c++/80371] New: std::is_integral and std::is_floating_point fail with vector types

[jwjagersma at gmail dot com]

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

Bug ID: 80371
   Summary: std::is_integral and std::is_floating_point fail with
vector types
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jwjagersma at gmail dot com
  Target Milestone: ---

Testing with std::is_integral or std::is_floating_point fails for vector
types. I don't think that's supposed to happen.

$ cat vectest.cpp
#include 

using Vi [[gnu::vector_size(4 * sizeof(int))]] = int;
using Vf [[gnu::vector_size(4 * sizeof(float))]] = float;

static_assert(std::is_integral::value, "");
static_assert(std::is_floating_point::value, "");

$ g++ vectest.cpp
vectest.cpp:6:1: error: static assertion failed
 static_assert(std::is_integral::value, "");
 ^
vectest.cpp:7:1: error: static assertion failed
 static_assert(std::is_floating_point::value, "");
 ^

$ g++ -v
Using built-in specs.
COLLECT_GCC=D:\msys64\mingw64\bin\g++.exe
COLLECT_LTO_WRAPPER=D:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-6.3.0/configure --prefix=/mingw64
--with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32
--host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32
--with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include
--libexecdir=/mingw64/lib --enable-bootstrap --with-arch=x86-64
--with-tune=generic --enable-languages=c,lto,c++,objc,obj-c++,fortran,ada
--enable-shared --enable-static --enable-libatomic --enable-threads=posix
--enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-time=yes
--disable-libstdcxx-pch --disable-libstdcxx-debug --disable-isl-version-check
--enable-lto --enable-libgomp --disable-multilib --enable-checking=release
--disable-rpath --disable-win32-registry --disable-nls --disable-werror
--disable-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw64
--with-mpfr=/mingw64 --with-mpc=/mingw64 --with-isl=/mingw64
--with-pkgversion='Rev2, Built by MSYS2 project'
--with-bugurl=https://sourceforge.net/projects/msys2 --with-gnu-as
--with-gnu-ld
Thread model: posix
gcc version 6.3.0 (Rev2, Built by MSYS2 project)

[Bug fortran/79553] [F03] Infinite gfortran loop on invalid code with dummy procedure

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Liška  ---
Yes, marking as fixed.

[Bug ipa/80212] [5/6 Regression] ICE: error: comdat-local function called by virtual

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Known to work|7.0 |
  Known to fail||7.0

--- Comment #3 from Martin Liška  ---
Patch has been reverted and need to be reworked.

[Bug ipa/80366] [7 Regression] r246759 causes LLVM build failure: error: comdat-local function called by outside its comdat

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
As it broke a lot of stuff, I decided to revert the original patch (r246785).

[Bug c/80369] Warnings from preprocessor generated code not shown

[adam.trhon at gmail dot com]

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

--- Comment #2 from Adam Trhoň  ---
Could you please provide a further explanation? Why the warning in my example
should not be shown?

My background: We are setting up icecream (but it could be any other tool as
ccache or distcc) with OpenEmbedded. The build fails on ltrace, but only when
icecream is active (as it splits preprocessing and compilation). The ltrace
project has -Wall -Werror in the command and 

assert(val != val);

in the code to abort in some case. Of course this should be fixed in the code,
but the gcc behavior seems confusing here.

I will also submit this to icecream (as, without further investigaion, it looks
like a problem on their side), but first I would like a comment from comunity
around gcc.

[Bug c/80369] Warnings from preprocessor generated code not shown

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
I think this is expected behavior ...

[Bug target/80367] internal compiler error: in print_reg, at config/i386/i386.c:16549

[jwjagersma at gmail dot com]

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

--- Comment #4 from jwjagersma at gmail dot com ---
I fixed my code by changing the first two asm inputs to memory operands
(should've done that anyway since I'm potentially modifying ds, so that could
have caused issues at runtime). No longer triggers an ICE now, but still I
don't think that should've happened in the first place with "rm" constraints.
I'm guessing it ran out of registers maybe? But then that should've caused an
"impossible constraints" error instead.

[Bug rtl-optimization/80358] [7 Regression] ICE (cc1 killed) building glib with -O3 on powerpc64le-linux-gnu

[acsawdey at gcc dot gnu.org]

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

acsawdey at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from acsawdey at gcc dot gnu.org ---
Fixed in 246784.

[Bug rtl-optimization/80358] [7 Regression] ICE (cc1 killed) building glib with -O3 on powerpc64le-linux-gnu

[acsawdey at gcc dot gnu.org]

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

--- Comment #2 from acsawdey at gcc dot gnu.org ---
Author: acsawdey
Date: Sat Apr  8 16:10:26 2017
New Revision: 246784

URL: https://gcc.gnu.org/viewcvs?rev=246784=gcc=rev
Log:
2017-04-08  Aaron Sawdey  

PR target/80358
* config/rs6000/rs6000.c (expand_block_compare): Fix boundary check.



Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c

[Bug ipa/80366] [7 Regression] r246759 causes LLVM build failure: error: comdat-local function called by outside its comdat

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Mine.

[Bug c/80369] New: Warnings from preprocessor generated code not shown

[adam.trhon at gmail dot com]

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

Bug ID: 80369
   Summary: Warnings from preprocessor generated code not shown
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: adam.trhon at gmail dot com
  Target Milestone: ---

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

The example in main.c (attached) contains a preprocessor macro that should
generate tautological-compare warning (with -Wall). But the warning is not
generated unless preprocessing and compilation are done in separate steps.

When compiled as:

gcc -Wall main.c

the warning about tautological compare is *not shown*. But when compiled as:

gcc -Wall -no-integrated-cpp main.c

or as:

gcc -Wall -E main.c -o main.i
gcc -Wall --preprocessed main.i

then this warning is printed:

main.c: In function ‘main’:
main.c:31:11: warning: self-comparison always evaluates to false
[-Wtautological-compare]
  FOO
   ^ 

The issue was observed with:
gcc 6.2 for ARM built by OpenEmbedded
gcc 6.3 for x86_64 from Arch Linux
gcc 7.0 for x86_64 built from upstram git (commit ae4f1e0ee12)

[Bug fortran/80361] [5/6/7 Regression] bogus recursive call to nonrecursive procedure with -fcheck=recursion

[dominiq at lps dot ens.fr]

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

--- Comment #10 from Dominique d'Humieres  ---
If I remove the final stuff in unit_tests.f90, 

--- unit_tests_orig.f90 2017-04-08 16:16:57.0 +0200
+++ unit_tests.f90  2017-04-08 16:17:20.0 +0200
@@ -72,7 +72,6 @@ module unit_tests
  procedure, private :: add => test_results_add
  procedure, private :: write => test_results_write
  procedure, private :: report => test_results_report
- procedure, private :: final => test_results_final
  procedure :: wrapup => test_results_wrapup
   end type test_results_t

@@ -144,26 +143,12 @@ contains
 success = list%n_failure == 0
   end subroutine test_results_report

-  subroutine test_results_final (list)
-class(test_results_t), intent(inout) :: list
-type(test_result_t), pointer :: result
-do while (associated (list%first))
-   result => list%first
-   list%first => result%next
-   deallocate (result)
-end do
-list%last => null ()
-list%n_success = 0
-list%n_failure = 0
-  end subroutine test_results_final
-
   subroutine test_results_wrapup (list, u, success)
 class(test_results_t), intent(inout) :: list
 integer, intent(in) :: u
 logical, intent(out), optional :: success
 call list%write (u)
 if (present (success))  call list%report (success)
-call list%final ()
   end subroutine test_results_wrapup

   subroutine test (test_proc, name, description, u_log, results)

I still get with a clean make

Fortran runtime error: Recursive call to nonrecursive procedure
'__final_particle_specifiers_Prt_spec_list_t'

This seems buggy unless I am missing something(?).

[Bug c++/70435] section attribute of a function template is not honored.

[armin at otheruse dot nl]

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

--- Comment #2 from Armin van der Togt  ---
Problem is still present in version 6.3.1

[Bug target/80367] internal compiler error: in print_reg, at config/i386/i386.c:16549

[jwjagersma at gmail dot com]

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

--- Comment #3 from jwjagersma at gmail dot com ---
Here's an interesting observation: The ICE doesn't occur when I remove the
"esp" clobber from inline asm in vbe2::set_palette() (vbe.cpp:621,
vbe.ii:66207). But that's obviously not a solution since it produces wrong
code.

[Bug c++/80368] New: g++ thinks sizeof a non-type template parameter is dependent

[aschepler at gmail dot com]

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

Bug ID: 80368
   Summary: g++ thinks sizeof a non-type template parameter is
dependent
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aschepler at gmail dot com
  Target Milestone: ---

g++ rejects the following valid code:

template 
struct A {
static constexpr unsigned int value = N;
};

template 
struct B : public A {
static constexpr unsigned int member = value;
};

claiming "value" was not declared in the scope of B.

Standard section 14.6.2 is clear: sizeof unary-expression is never
type-dependent, and is only value-dependent if the unary-expression is
type-dependent.  But (N) is only value-dependent, so sizeof(N) is not dependent
at all.  Name lookup should include members of all non-dependent base classes.

[Bug target/80367] internal compiler error: in print_reg, at config/i386/i386.c:16549

[jwjagersma at gmail dot com]

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

--- Comment #2 from jwjagersma at gmail dot com ---
Created attachment 41161
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41161=edit
vbe.ii gzipped

[Bug target/80367] internal compiler error: in print_reg, at config/i386/i386.c:16549

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-04-08
 CC||trippels at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
Please attach vbe.ii.

[Bug target/80367] New: internal compiler error: in print_reg, at config/i386/i386.c:16549

[jwjagersma at gmail dot com]

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

Bug ID: 80367
   Summary: internal compiler error: in print_reg, at
config/i386/i386.c:16549
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jwjagersma at gmail dot com
  Target Milestone: ---

I got this ICE yesterday and I haven't been able to figure out what caused it,
or how to reduce the code to a small test case.
The only information I can provide right now is the full program:

https://github.com/jwt27/jwdpmi_test.git
checkout commit 88431be254cb414fb6499cefe0caf584a6c316f4 (should be the last
one, as of now)

I believe this error occured after I changed function pixel::max()
(include/jw/video/pixel.h:202) to return std::int32_t (previously
std::int16_t). This would make the vector functions in the pixel class use a
vector type of 4*int. But I don't see how that is directly related, since it
looks like the ICE originates from the inline asm in src/vbe.cpp. I also tried
changing the return type back to std::int16_t but the error is still there.
Also it only happens with some -march= options. pentium2 and earlier compiles
fine, core2 and later work too, anything inbetween (pentium3 to prescott)
fails.

$ make
make -C lib/libjwdpmi/
make[1]: Entering directory '/home/JW/projects/jwdpmi_test/lib/libjwdpmi'
g++  -pipe -masm=intel -MD -MP -O3 -flto=24 -flto-odr-type-merging -mmmx -msse
-march=pentium3 -ffast-math -mfpmath=both -std=gnu++17 -Wall -Wextra
-Wno-attributes -Wsuggest-override -Wattributes -ggdb -fnon-call-exceptions
-fasynchronous-unwind-tables -mcld -mpreferred-stack-boundary=4 -mstackrealign
-DNDEBUG -save-temps -masm=intel -std=gnu++17 -Wall -Wextra
-fasynchronous-unwind-tables -fnon-call-exceptions -mcld
-mpreferred-stack-boundary=4 -MD -MP -MF obj/vbe.d -o obj/vbe.o -Iinclude -c
src/vbe.cpp
g++.exe: warning: -pipe ignored because -save-temps specified
src/vbe.cpp: In member function
'jw::video::vbe2::set_palette(jw::video::pixel const*,
jw::video::pixel const*, unsigned long, bool)':
src/vbe.cpp:647:9: internal compiler error: in print_reg, at
config/i386/i386.c:16549
 }
 ^
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[1]: *** [makefile:39: obj/vbe.o] Error 1
make[1]: Leaving directory '/home/JW/projects/jwdpmi_test/lib/libjwdpmi'
make: *** [makefile:65: libjwdpmi] Error 2

$ g++ -v
Using built-in specs.
COLLECT_GCC=D:\msys64\usr\local\djgpp\i586-pc-msdosdjgpp\bin\g++.exe
COLLECT_LTO_WRAPPER=D:/msys64/usr/local/djgpp/lib/gcc/../../libexec/gcc/i586-pc-msdosdjgpp/6.1.0/lto-wrapper.exe
Target: i586-pc-msdosdjgpp
Configured with: ../gnu/gcc-6.10/configure --build=x86_64-w64-mingw32
--target=i586-pc-msdosdjgpp --program-prefix=i586-pc-msdosdjgpp-
--prefix=/usr/local/djgpp --disable-nls --disable-plugin --enable-lto
--enable-libquadmath-support
--with-gmp=/home/JW/build-djgpp/build/djcross-gcc-6.1.0/tmpinst
--with-mpfr=/home/JW/build-djgpp/build/djcross-gcc-6.1.0/tmpinst
--with-mpc=/home/JW/build-djgpp/build/djcross-gcc-6.1.0/tmpinst
--enable-version-specific-runtime-libs --enable-languages=c,c++
Thread model: single
gcc version 6.1.0 (GCC)

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

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
That doesn't work in this case:

constexpr bool str()
{
  char s[] = "str";
  return ce_char_traits::length(s) == 3;
}

static_assert( str() );

i.e. it works OK for C++11-style constant expressions, but not C++14 ones.

[Bug fortran/80361] [5/6/7 Regression] bogus recursive call to nonrecursive procedure with -fcheck=recursion

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

Summary|[7.0.1. regression] severe  |[5/6/7 Regression] bogus
   |regression  recursive call  |recursive call to
   |to nonrecursive procedure   |nonrecursive procedure with
   ||-fcheck=recursion

--- Comment #9 from Dominique d'Humieres  ---
The change occurred between revisions r200946 (2013-07-14, no runtime error)
and r201266 (2013-07-26, runtime error), may be r200954(?).

Note that the range is different from the one in pr67505.

[Bug fortran/67505] [F03] bogus runtime error with final subroutine and -fcheck=recursion

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
The change occurred between revisions r200320 (2013-06-21, no runtime error)
and r200350 (2013-06-23, runtime error), likely r200321 (pr37336).

[Bug sanitizer/80348] [6/7 Regression] UBSAN: compile time crash in ubsan_instrument_division

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

Summary|[6 Regression] UBSAN:   |[6/7 Regression] UBSAN:
   |compile time crash in   |compile time crash in
   |ubsan_instrument_division   |ubsan_instrument_division

--- Comment #8 from Marek Polacek  ---
Ouch.  I'll have a look.

[Bug fortran/80361] [7.0.1. regression] severe regression recursive call to nonrecursive procedure

[dominiq at lps dot ens.fr]

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

--- Comment #8 from Dominique d'Humieres  ---
Duplicate of/related to pr67505?

The flag -fcheck=recursion is enough to trigger the runtime error and I see it
with 4.9.3, but not with 4.8.5.

[Bug c++/80363] #'vec_cond_expr' not supported by dump_expr#

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-04-08
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Created attachment 41160
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41160=edit
gcc7-pr80363.patch

Untested fix.  As for std::{min,max} handling vector types, it would need to be
some extension.  I think it would need to return the vector directly rather
than reference to it, because minimum or maximum vector might not be one of the
operands, there is a precedent for it with min/max with
std::initializer_list
argument though.  Plus we'd need some trait to recognize vector types, then
just
return a < b ? a : b; or similar.

[Bug ipa/80366] [7 Regression] r246759 causes LLVM build failure: error: comdat-local function called by outside its comdat

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |7.0

[Bug ipa/80366] New: [7 Regression] r246759 causes LLVM build failure: error: comdat-local function called by outside its comdat

[trippels at gcc dot gnu.org]

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

Bug ID: 80366
   Summary: [7 Regression] r246759 causes LLVM build failure:
error: comdat-local function called by outside its
comdat
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
CC: hubicka at ucw dot cz, marxin at gcc dot gnu.org
  Target Milestone: ---

Since r246759 LLVM doesn't build anymore:

trippels@gcc2-power8 llvm_build % cat DAGISelMatcherEmitter.ii
struct B {
  int *Ptr;
  B(int, int p2) {
if (!p2)
  if (Ptr || *Ptr)
++Ptr;
  }
};
template  struct StringMapIterator : B {
  using base = B;
  StringMapIterator() : base(0, 0) {}
};
template  struct A {
  void operator[](int) { StringMapIterator(); }
};
struct C {
  A PatternPredicateMap;
  unsigned m_fn1();
};
unsigned C::m_fn1() { PatternPredicateMap[0]; }

trippels@gcc2-power8 llvm_build % g++ -c -O3 DAGISelMatcherEmitter.ii
DAGISelMatcherEmitter.ii:20:47: error: comdat-local function called by
B::B(int, int) outside its comdat
 unsigned C::m_fn1() { PatternPredicateMap[0]; }
   ^
_ZN1BC2Eii.part.0/8 (B::B(int, int)) @0x3fff7bf7
  Type: function definition analyzed
  Visibility: prevailing_def_ironly comdat_group:_ZN1BC5Eii artificial
  Same comdat group as: _ZN1BC2Eii/1
  References: 
  Referring: 
  Availability: local
  First run: 1
  Function flags: body local split_part
  Called by: _ZN1BC2Eii.constprop.2/10 (0.54 per call) _ZN1BC2Eii/1 (0.54 per
call) 
  Calls: 
DAGISelMatcherEmitter.ii:20:47: internal compiler error: verify_cgraph_node
failed
0x10610e0b cgraph_node::verify_node()
../../gcc/gcc/cgraph.c:3505
0x10600ec3 symtab_node::verify()
../../gcc/gcc/symtab.c:1183
0x106013c7 symtab_node::verify_symtab_nodes()
../../gcc/gcc/symtab.c:1203
0x10904b43 symtab_node::checking_verify_symtab_nodes()
../../gcc/gcc/cgraph.h:616
0x10904b43 symbol_table::remove_unreachable_nodes(_IO_FILE*)
../../gcc/gcc/ipa.c:698
0x10a3c62f execute_todo
../../gcc/gcc/passes.c:2030

[Bug fortran/80361] [7.0.1. regression] severe regression recursive call to nonrecursive procedure

[juergen.reuter at desy dot de]

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

--- Comment #7 from Jürgen Reuter  ---
Created attachment 41159
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41159=edit
Correct reproducer

[Bug fortran/80361] [7.0.1. regression] severe regression recursive call to nonrecursive procedure

[juergen.reuter at desy dot de]

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

--- Comment #6 from Jürgen Reuter  ---
Ah sorry, here is the tarball with the missing file and also the correct flags. 
And please remove the 'severe' from regression, I first thought this was with
default flags.

[Bug middle-end/80364] [7 Regression]sanitizer detects signed integer overflow in gimple-ssa-sprintf.c

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-04-08
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
get_int_range looks weird. First of all, it assumes tree_to_uhwi/tree_to_shwi
will always succeed, without testing, not sure if the callers guarantee you
don't get there wider types like int128_t.
Another one is that the values are stored as HOST_WIDE_INT (signed) regardless
whether the type is signed or unsigned, and then arithmetics or comparisons are
performed on it always as signed.
It seems except for recursion the type is always integer_type_node, so then the
signed vs. unsigned would be fine, but when it recurses, it uses whatever type
the arg has, and that doesn't even have to be an integral type, can be
floating, structure or whatever.  So perhaps it would be enough to just check
if TREE_TYPE (arg) is integral type with precision smaller than integer (then
look at that type), but if it is precision equal or greater than type, starting
from unsigned int and onwards, or non-integral type, just use a range of type
(== integer_type_node)?

Another thing is that ubsan should not present array types, the negation
certainly has long int type rather than long int [3].

[Bug libfortran/80365] New: undefined memcpy while writing zero length array on unformatted stream in unix.c

[zeccav at gmail dot com]

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

Bug ID: 80365
   Summary: undefined memcpy while writing zero length array on
unformatted stream in unix.c
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

! undefined memcpy writing zero length array on unformatted stream
! must be compiled and run
! ../../../gcc-trunk-246751/libgfortran/io/unix.c:596:7: runtime error: null
pointer passed as argument 2, which is declared to never be null
! unix.c:596 is "memcpy (s->buffer + (s->logical_offset - s->buffer_offset),
buf, nbyte);"
! buf is zero but luckily nbyte is zero as well
! just in case I suggest putting "assert(buf || !nbyte);" before memcpy
  real v(1:0)
  open(1,form='unformatted',access='stream')
  write(unit=1,pos=1) v
  end

This is related to bug 67536

[Bug target/79733] ICE in int_mode_for_mode, at stor-layout.c:406

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||schnetter at gmail dot com

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

[Bug target/80360] internal compiler error: in int_mode_for_mode, at stor-layout.c:405

[trippels at gcc dot gnu.org]

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

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 79733 ***

[Bug middle-end/80362] gcc miscompiles arithmetic with signed char

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-04-08
 CC||trippels at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
Even 4.4 calls abort with -O2:

int main() {
  signed char var_0, var_1 = -128;
  var_0 = (signed char)(-var_1) / 3;
  if (var_0 > 0)
__builtin_abort();
}