[Bug fortran/78033] Internal Compiler Error in enforce_single_undo_checkpoint

[kargl at gcc dot gnu.org]

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

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #1)
> Reduced testcase.
> 
> function f(n, x)
>integer, intent(in) :: n 
>complex, intent(in) :: x(1:n)
>real :: f
>f = g([real(x(1:n)), aimag(x(1:n))])
> end function f
> 
> If the array sections are removed in favor of the whole array,
> the code compiles.

Even further reduction.

subroutine f(n, x)
   integer, intent(in) :: n 
   complex, intent(in) :: x(1:n)
   real :: y(2*n)
   y = [real(x(1:n), aimag(x(1:n))]
end subroutine f

The constructor with array sections is going south.

[Bug fortran/78033] Internal Compiler Error in enforce_single_undo_checkpoint

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
Reduced testcase.

function f(n, x)
   integer, intent(in) :: n 
   complex, intent(in) :: x(1:n)
   real :: f
   f = g([real(x(1:n)), aimag(x(1:n))])
end function f

If the array sections are removed in favor of the whole array,
the code compiles.

[Bug fortran/78033] New: Internal Compiler Error in enforce_single_undo_checkpoint

[physiker at toast2 dot net]

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

Bug ID: 78033
   Summary: Internal Compiler Error in
enforce_single_undo_checkpoint
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: physiker at toast2 dot net
  Target Milestone: ---

Created attachment 39833
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39833=edit
Source code

Compiling the file bug.f90 causes an internal compiler error. This is a
regression. gcc-5 and gcc-6 compile the code without an error message.

LANG=C gfortran-7 -c bug.f90 -Wall -W -v 
Using built-in specs.
COLLECT_GCC=gfortran-7
Target: x86_64-apple-darwin13.4.0
Configured with: ../gcc/configure --enable-languages=c,c++,fortran,lto
--with-gmp=/sw --with-libiconv-prefix=/sw --with-isl=/sw --with-mpc=/sw
--with-system-zlib --program-suffix=-7
Thread model: posix
gcc version 7.0.0 20161015 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-c' '-Wall' '-Wextra' '-v' '-mmacosx-version-min=10.9.4'
'-mtune=core2'
 /usr/local/libexec/gcc/x86_64-apple-darwin13.4.0/7.0.0/f951 bug.f90 -fPIC
-quiet -dumpbase bug.f90 -mmacosx-version-min=10.9.4 -mtune=core2 -auxbase bug
-Wall -Wextra -version -fintrinsic-modules-path
/usr/local/lib/gcc/x86_64-apple-darwin13.4.0/7.0.0/finclude -o
/var/folders/97/4qnhjhtn25s86s9hkz0h37_mgn/T//ccNO9KhM.s
GNU Fortran (GCC) version 7.0.0 20161015 (experimental)
(x86_64-apple-darwin13.4.0)
compiled by GNU C version 7.0.0 20161015 (experimental), GMP version
6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version 0.15
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU Fortran2008 (GCC) version 7.0.0 20161015 (experimental)
(x86_64-apple-darwin13.4.0)
compiled by GNU C version 7.0.0 20161015 (experimental), GMP version
6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version 0.15
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
f951: internal compiler error: in enforce_single_undo_checkpoint, at
fortran/symbol.c:3514

f951: internal compiler error: Abort trap: 6
gfortran-7: internal compiler error: Abort trap: 6 (program f951)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug libgcc/78017] weak reference usage in gthr-posix.h (__gthread*) is broken

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
There are other reasons why using static libraries does not make sense for
libpthread.

[Bug libstdc++/78030] Lambda capture expression (different results than Clang & MSVC)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
The standard does not say the predicate can't be copied at all.  So this is
invalid.  There are more than one copy of the predicate floating around which
is why you get this behavior.  GCC implements it by calling find_if so it
starts maybe the slow part of going though each element slowly; because of that
call, find_if copies the lambda which means now you have two s's.

[Bug libstdc++/78030] Lambda capture expression (different results than Clang & MSVC)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c++ |libstdc++

--- Comment #1 from Andrew Pinski  ---
I don't think this is a front-end bug but possible a library bug.
Take a look at the implementation:

  template
_ForwardIterator
__remove_if(_ForwardIterator __first, _ForwardIterator __last,
  _Predicate __pred)
{
  __first = std::__find_if(__first, __last, __pred);
  if (__first == __last)
 return __first;
  _ForwardIterator __result = __first;
  ++__first;
  for (; __first != __last; ++__first)
 if (!__pred(__first))
   {
 *__result = std::move(*__first);
 ++__result;
   }
  return __result;
}


Notice how we call __find_if, it makes a copy of __pred which means we get a
new copy of s for the lambda.

This effect can be seen if we add:
print(s);

to the lambda:

1
1 2
1 2 4

1
1 4
1 4 5
1 4 5
1 4 5
1 4 5
1 4 5
1 3 4 5
- CUT -
The question now becomes is your lambda a valid Predicate function.
I think no.

[Bug sanitizer/78028] ASAN doesn't find memory leak

[kcc at gcc dot gnu.org]

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

--- Comment #1 from Kostya Serebryany  ---
interestingly, this works for me with clang

[Bug c++/78022] constexpr int template rejected unless constructor is used before hand

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-19
Summary|Strange C++ compilation |constexpr int template
   |error   |rejected unless constructor
   ||is used before hand
 Ever confirmed|0   |1
  Known to fail||5.3.0, 5.4.0, 7.0

--- Comment #2 from Andrew Pinski  ---
Confirmed.
struct X can be a function too.

[Bug libfortran/77828] [7 Regression] Linking gfortran-7 compiled program with libgfortran of 5.x allowed but crashes when containing write to string

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||damian at sourceryinstitute 
dot or
   ||g

--- Comment #5 from Jerry DeLisle  ---
Patch submitted to list for review.

[Bug other/64184] libcilkrts fails to build on darwin due to error: '_SC_NPROCESSORS_ONLN' undeclared

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||build
 Status|WAITING |NEW
Summary|error:  |libcilkrts fails to build
   |'_SC_NPROCESSORS_ONLN'  |on darwin due to error:
   |undeclared (first use in|'_SC_NPROCESSORS_ONLN'
   |this function)  |undeclared

[Bug c++/78032] [5/6/7 Regression] Incorrect code generated

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-19
   Target Milestone|--- |5.5
Summary|Incorrect code generated|[5/6/7 Regression]
   ||Incorrect code generated
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
<>>) >;

GCC 5.3 produced:
t8932.cc:11:20: error: converting to ‘foo’ from initializer list would use
explicit constructor ‘foo::foo(unsigned int)’
 void bar(foo x = 0u)
^
t8932.cc: In function ‘int main()’:
t8932.cc:18:13: error: converting to ‘foo’ from initializer list would use
explicit constructor ‘foo::foo(unsigned int)’
 bar();
 ^


Confirmed.

[Bug c++/78032] Incorrect code generated

[patrick at motec dot com.au]

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

Patrick Oppenlander  changed:

   What|Removed |Added

  Known to work||5.3.0
  Known to fail||5.4.0

--- Comment #1 from Patrick Oppenlander  ---
5.3.0 correctly diagnoses the invalid program.
5.4.0 also compiles incorrectly without error or warning.

[Bug c++/78032] New: Incorrect code generated

[patrick at motec dot com.au]

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

Bug ID: 78032
   Summary: Incorrect code generated
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick at motec dot com.au
  Target Milestone: ---

The following test case generates an invalid program using GCC 6.2.1 20160830:

The call to bar is eliminated and the resultant program does nothing.

#include 

struct foo {
foo(double);
foo(float);
explicit foo(unsigned);

unsigned v;
};

void bar(foo x = 0u)
{
printf("%d\n", x.v);
}

int main()
{
bar();
return 0;
}

[Bug other/64184] error: '_SC_NPROCESSORS_ONLN' undeclared (first use in this function)

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
It looks like it's used unconditionally even on trunk.

Libstdc++ has an autoconf check for it, see GLIBCXX_CHECK_SC_NPROCESSORS_ONLN
in libstdc++-v3/acinclude.m4

[Bug c++/77999] GCC diagnoses usage of STL literal operators as invalid.

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 CC||ville.voutilainen at gmail dot 
com

--- Comment #3 from Ville Voutilainen  ---
*** Bug 78031 has been marked as a duplicate of this bug. ***

[Bug c++/78031] Warning when a standard library UDL is brought to scope with a using-declaration

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

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

--- Comment #1 from Ville Voutilainen  ---
Dup.

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

[Bug c++/78031] New: Warning when a standard library UDL is brought to scope with a using-declaration

[ville.voutilainen at gmail dot com]

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

Bug ID: 78031
   Summary: Warning when a standard library UDL is brought to
scope with a using-declaration
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ville.voutilainen at gmail dot com
  Target Milestone: ---

#include 
#include 

int main() {
using std::literals::operator""s;
std::cout << "hello\n"s;
}

prog.cc: In function 'int main()':
prog.cc:5:34: warning: literal operator suffixes not preceded by '_' are
reserved for future standardization
 using std::literals::operator""s;
  ^~~

It's quite odd that gcc warns about code like that.

[Bug c++/32071] Partial explicit specialization template parameters not checked

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-18
 Ever confirmed|0   |1

[Bug c++/78030] New: Lambda capture expression (different results than Clang & MSVC)

[sthlm58 at gmail dot com]

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

Bug ID: 78030
   Summary: Lambda capture expression (different results than
Clang & MSVC)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sthlm58 at gmail dot com
  Target Milestone: ---

The following code is supposed to remove non-unique elements from the vector
(i.e. already existing in a set 's' (which is captured by value for the lambda
purposes))

Problem is: it produces different results than Clang and MSVC, which seem to be
correct.


#include 
#include 
#include 
#include 

template 
void print(T c) { for (auto e : c) std::cout << e << " "; std::cout <<
std::endl; }

int main()
{
std::vector elements { 1, 2, 4, 2, 1, 4, 5, 4, 4, 5, 1, 3, 0 };
elements.erase(std::remove_if(elements.begin(), elements.end(), [s =
std::set()](intc) mutable
{
return !s.insert(c).second;
}), elements.end());

print(elements);
}

OUTPUT:
1 2 4 1 4 5 3 0// GCC 4.x / 5.x / 6.x / 7.0

REQUIRED OUTPUT:
1 2 4 5 3 0// Clang 3.4 - 4.0, Lastest MSVC

Shown here:
http://melpon.org/wandbox/permlink/h68S9ZKLYZqw4kvP

[Bug rtl-optimization/78029] ICE in maybe_record_trace_start, at dwarf2cfi.c:2285

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-18
   Assignee|unassigned at gcc dot gnu.org  |segher at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Segher Boessenkool  ---
Mine.  Something with shrink-wrap-separate.

[Bug rtl-optimization/78029] New: ICE in maybe_record_trace_start, at dwarf2cfi.c:2285

[pthaugen at gcc dot gnu.org]

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

Bug ID: 78029
   Summary: ICE in maybe_record_trace_start, at dwarf2cfi.c:2285
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pthaugen at gcc dot gnu.org
CC: dje at gcc dot gnu.org, segher at gcc dot gnu.org,
wschmidt at gcc dot gnu.org
  Target Milestone: ---
  Host: powerpc64*-unknown-linux-gnu
Target: powerpc64*-unknown-linux-gnu
 Build: powerpc64*-unknown-linux-gnu

The following reduced testcase shows an ICE that occurs when building
483.xalancbmk from cpu2006.

class A {
public:
  static unsigned short fgXMLString[];
};
class B {
  bool hasFeature() const;
};
class XMLString {
public:
  static int compareIString(const unsigned short *);
  static bool equals(const unsigned short *, const unsigned short *);
};
const short chDigit_1 = 1;
const unsigned short g1_0[]{chDigit_1};
const unsigned short g2_0[]{2};
const unsigned short g3_0[]{3, 4};
const unsigned short gRange[]{};
unsigned short *hasFeature_version;
inline bool XMLString::equals(const unsigned short *p1,
  const unsigned short *p2) {
  if (p1 == 0)
return false;
  while (*p1 == *p2) {
if (!*p1)
  return true;
p1++;
p2++;
  }
  return false;
}
bool B::hasFeature() const {
  bool anyVersion = hasFeature_version == 0 || !*hasFeature_version,
   version1_0 = XMLString::equals(hasFeature_version, g1_0);
  bool version2_0 = XMLString::equals(hasFeature_version, g2_0);
  bool version3_0 = XMLString::equals(hasFeature_version, g3_0);
  if (XMLString::compareIString(A::fgXMLString) && version2_0)
return true;
  if (anyVersion || version1_0 || version2_0 || version3_0)
return true;
  XMLString::compareIString(gRange);
}


$ /home/pthaugen/install/gcc/trunk/bin/g++ -s -m64 -O2 -mcpu=power6
DOMImplementationImpl.ii
DOMImplementationImpl.ii: In member function ‘bool B::hasFeature() const’:
DOMImplementationImpl.ii:41:1: internal compiler error: in
maybe_record_trace_start, at dwarf2cfi.c:2285
 }
 ^
0x10665753 maybe_record_trace_start
/home/pthaugen/src/gcc/trunk/gcc/gcc/dwarf2cfi.c:2285
0x10665c27 create_trace_edges
/home/pthaugen/src/gcc/trunk/gcc/gcc/dwarf2cfi.c:2379
0x10665e07 scan_trace
/home/pthaugen/src/gcc/trunk/gcc/gcc/dwarf2cfi.c:2593
0x10666aa3 create_cfi_notes
/home/pthaugen/src/gcc/trunk/gcc/gcc/dwarf2cfi.c:2619
0x10666aa3 execute_dwarf2_frame
/home/pthaugen/src/gcc/trunk/gcc/gcc/dwarf2cfi.c:2977
0x10666aa3 execute
/home/pthaugen/src/gcc/trunk/gcc/gcc/dwarf2cfi.c:3457
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug tree-optimization/78024] [7 regression] test cases gfortran.dg/goacc/routine-4.f90 and also routine-5.f90 fail starting with r241296

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-18
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Confirmed.

[Bug fortran/78027] [6/7 Regression] ICE in new_oacc_loop_routine, at omp-low.c:19000

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code, openacc,
   ||openmp
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-18
 CC||marxin at gcc dot gnu.org,
   ||nathan at gcc dot gnu.org
   Target Milestone|--- |6.3
Summary|ICE in  |[6/7 Regression] ICE in
   |new_oacc_loop_routine, at   |new_oacc_loop_routine, at
   |omp-low.c:19000 |omp-low.c:19000
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
Confirmed, started with r229466.

[Bug fortran/78025] [5/6/7 Regression] ICE in simd_clone_adjust, at omp-simd-clone.c:1126

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code, openmp
 CC||marxin at gcc dot gnu.org
Summary|ICE in simd_clone_adjust,   |[5/6/7 Regression] ICE in
   |at omp-simd-clone.c:1126|simd_clone_adjust, at
   ||omp-simd-clone.c:1126

--- Comment #2 from Martin Liška  ---
Confirmed, started with GCC 4.9.1.

[Bug fortran/78026] [5/6/7 Regression] ICE in gfc_resolve_omp_declare_simd, at fortran/openmp.c:5190

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code, openmp
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-18
 CC||marxin at gcc dot gnu.org
Summary|ICE in  |[5/6/7 Regression] ICE in
   |gfc_resolve_omp_declare_sim |gfc_resolve_omp_declare_sim
   |d, at fortran/openmp.c:5190 |d, at fortran/openmp.c:5190
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, started with GCC 4.9.1.

[Bug libstdc++/78015] pthread_cancel while some exception is pending results in std::terminate ()

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-18
 Ever confirmed|0   |1

--- Comment #3 from Jason Merrill  ---
The problem is that non-C++ exceptions like forced unwind have no exception
header, so we can't chain them onto caughtExceptions.  But it seems to me that
we ought to be able to wrap such an exception in a C++ exception to make it
more palatable to the C++ runtime: in __cxa_catch, we can allocate a C++
exception using the foreign exception as the object.  Anyone see a problem with
this strategy?

[Bug fortran/78025] ICE in simd_clone_adjust, at omp-simd-clone.c:1126

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-18
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
> Affects versions 5, 6 and 7 ...

and also 4.9. The change occurred around r211768.

[Bug sanitizer/78028] New: ASAN doesn't find memory leak

[barto at cambridgesemantics dot com]

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

Bug ID: 78028
   Summary: ASAN doesn't find memory leak
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barto at cambridgesemantics 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
  Target Milestone: ---

Checking address sanitizer leaks lead me to
https://github.com/google/sanitizers/wiki/AddressSanitizerLeakSanitizer and the
sample code therein.

I copied/pasted it and ran it on my Ubuntu 14.04 box.
The leak for FooBar was detected and reported.
So I added the suppression file and got no leak reported.
I then removed the allocation code in the FooBar function and still had no
report of a memory leak.

516_ g++ -fsanitize=address lsan-suppressed.cc
517_ ./a.out

=
==4471==ERROR: LeakSanitizer: detected memory leaks

519_ ASAN_OPTIONS=detect_leaks=1
LSAN_OPTIONS=suppressions=suppressions=suppr.txt ./a.out
-
Suppressions used:
  count  bytes template
  1  7 FooBar

But no error for Baz as noted on the webpage. Removing the allocation in FooBar
will then pass without the suppression file applied.

[Bug fortran/77678] ICE in fold_read_from_constant_string, at fold-const.c:13706

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #6 from kargl at gcc dot gnu.org ---
(In reply to Richard Biener from comment #5)
> ICE fixed.

Add -fcheck=all to your command line options.

With the ICE fixed, I think that this falls squarely in the
WONTFIX or INVALID category.  It is the user's responsibility
to check if the value of i is within the bounds of the string.


% gfc7 -o z -O2 -fcheck=all -finit-integer=-123456 a.f90 && ./z
At line 5 of file a.f90
Fortran runtime error: Substring out of bounds: lower bound (-123456)
is less than one

[Bug fortran/78027] ICE in new_oacc_loop_routine, at omp-low.c:19000

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #1 from Gerhard Steinmetz  
---

No ICE with one loop only :


$ cat z3.f90
real function f()
   !$omp declare target(f)
   f = 1.
   !$acc parallel
   !$acc loop
   do i = 1, 8
   end do
   !$acc end parallel
end

[Bug fortran/78027] New: ICE in new_oacc_loop_routine, at omp-low.c:19000

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 78027
   Summary: ICE in new_oacc_loop_routine, at omp-low.c:19000
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

Affects version 6 and 7 at -Os, -O2, -O3 :


$ cat z1.f90
real function f()
   !$omp declare target(f)
   f = 1.
   !$acc parallel
   !$acc loop
   do i = 1, 8
   end do
   !$acc end parallel
   !$acc parallel
   !$acc loop
   do i = 1, 8
   end do
   !$acc end parallel
end


$ gfortran-7-20161016 -O2 -fopenmp -fopenacc -c z1.f90
z1.f90:4:0:

!$acc parallel

internal compiler error: in new_oacc_loop_routine, at omp-low.c:19000
0xb0dda8 new_oacc_loop_routine
../../gcc/omp-low.c:19000
0xb0dda8 oacc_loop_discover_walk
../../gcc/omp-low.c:19139
0xb0dc90 oacc_loop_discover_walk
../../gcc/omp-low.c:19208
0xb0f98e oacc_loop_discovery
../../gcc/omp-low.c:19242
0xb0f98e execute_oacc_device_lower
../../gcc/omp-low.c:19654
0xb0f98e execute
../../gcc/omp-low.c:19860

[Bug fortran/78026] New: ICE in gfc_resolve_omp_declare_simd, at fortran/openmp.c:5190

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 78026
   Summary: ICE in gfc_resolve_omp_declare_simd, at
fortran/openmp.c:5190
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

With invalid code, and configured with --enable-checking=yes :
(bailed out with official releases 5, 6)


$ cat z1.f90
select type (a)
end select
!$omp declare simd(b)
end


$ gfortran-7-20161016 -c z1.f90
z1.f90:1:15:

 select type (a)
   1
Error: Selector shall be polymorphic in SELECT TYPE statement at (1)


$ gfortran-7-20161016 -fopenmp -c z1.f90
z1.f90:3:21:

 !$omp declare simd(b)
 1
Error: Unexpected !$OMP DECLARE SIMD statement at (1)
f951: internal compiler error: Segmentation fault
0xc2f45f crash_signal
../../gcc/toplev.c:338
0x6d0c75 gfc_resolve_omp_declare_simd(gfc_namespace*)
../../gcc/fortran/openmp.c:5190
0x6f90f8 resolve_types
../../gcc/fortran/resolve.c:15715
0x6f486c gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:15785
0x6df39a resolve_all_program_units
../../gcc/fortran/parse.c:5879
0x6df39a gfc_parse_file()
../../gcc/fortran/parse.c:6131
0x722652 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:198

[Bug fortran/78025] New: ICE in simd_clone_adjust, at omp-simd-clone.c:1126

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 78025
   Summary: ICE in simd_clone_adjust, at omp-simd-clone.c:1126
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

Affects versions 5, 6 and 7 :


$ cat z1.f90
real function f()
!$omp declare simd(f) inbranch
   if ( .true. ) call abort
end


$ cat z2.f90
real function f()
!$omp declare simd(f) inbranch
   stop
end


$ gfortran-7-20161016 -fopenmp -c z1.f90
z1.f90:4:0:

 end

internal compiler error: Segmentation fault
0xc2f45f crash_signal
../../gcc/toplev.c:338
0x13614fb vec::operator[](unsigned int)
../../gcc/vec.h:732
0x13614fb simd_clone_adjust
../../gcc/omp-simd-clone.c:1126
0x13651d6 expand_simd_clones
../../gcc/omp-simd-clone.c:1624
0x13651d6 ipa_omp_simd_clone
../../gcc/omp-simd-clone.c:1642
0x13651d6 execute
../../gcc/omp-simd-clone.c:1670

[Bug libstdc++/41861] [DR 887][C++0x] does not use monotonic_clock

[mac at mcrowe dot com]

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

--- Comment #14 from Mike Crowe  ---
(In reply to Jonathan Wakely from comment #13)
> (In reply to Roman Fietze from comment #12)
> > Sorry if it is inappropriate to ask for any changes, but how can it be, that
> > there is no fix for this bug for years in any of the GCC releases? 
> 
> Because it's not possible to implement the C++ requirements purely in terms
> of POSIX, so it requires a new API in the C library, which is complicated.
> All the information you need to investigate that is provided in this bug
> report and the enclosed links.

I submitted an RFC glibc patch last year:
http://patchwork.ozlabs.org/project/glibc/list/?submitter=66786

There were some objections but no-one seemed to outright say no. Unfortunately
it is blocked waiting for Torvald Riegel's removal of the assembly
"optimisation" for x86 and x86_64 before it can go in. This seems to be taking
longer than I expected when I wrote the patch.

> > With this bug condition_variable::wait_until is completely unusable on many
> 
> I find that hard to believe.

Well, it does make it unsafe to use in an environment where CLOCK_REALTIME can
change arbitrarily which some may consider to equate to "unusable".

However, in the intervening time I've become aware of the std::synchronic
proposal ( http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0126r2.pdf
) and I've been wondering whether libstdc++ would be better off implementing
support for that and then using it to build its own condition_variable
implementation. I'm not sure whether I'm qualified to do that though. :)

If we wanted to do something in the short term then we could consider flipping
the default clock for std::condition_variable to be std::chrono::steady_clock
where it is available. I suspect that most code is using a relative timeout
anyway and isn't really expecting the timeout to change when the system clock
changes.

[Bug tree-optimization/77989] [7 Regression] -O3 causes verify_gimple fail

[amker at gcc dot gnu.org]

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

--- Comment #6 from amker at gcc dot gnu.org ---
Ah, I think this duplicates to PR77988 and was fixed by richi.  I will add a
test case for this though.

[Bug tree-optimization/78005] [7 Regression] 172.mgrid and 450.soplex miscompare

[amker at gcc dot gnu.org]

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

--- Comment #4 from amker at gcc dot gnu.org ---
Hmm, some code got lost during iterating of patch testing...  Will send a patch
soon.

[Bug tree-optimization/78024] [7 regression] test cases gfortran.dg/goacc/routine-4.f90 and also routine-5.f90 fail starting with r241296

[seurer at linux dot vnet.ibm.com]

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

--- Comment #1 from Bill Seurer  ---
These also fail on x86.

[Bug tree-optimization/78024] New: [7 regression] test cases gfortran.dg/goacc/routine-4.f90 and also routine-5.f90 fail starting with r241296

[seurer at linux dot vnet.ibm.com]

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

Bug ID: 78024
   Summary: [7 regression] test cases
gfortran.dg/goacc/routine-4.f90 and also routine-5.f90
fail starting with r241296
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at linux dot vnet.ibm.com
  Target Milestone: ---

> FAIL: gfortran.dg/goacc/routine-4.f90   -O   (test for errors, line 116)
> FAIL: gfortran.dg/goacc/routine-4.f90   -O   (test for errors, line 54)
> FAIL: gfortran.dg/goacc/routine-4.f90   -O   (test for errors, line 59)
> FAIL: gfortran.dg/goacc/routine-4.f90   -O   (test for errors, line 64)
> FAIL: gfortran.dg/goacc/routine-4.f90   -O   (test for errors, line 85)
> FAIL: gfortran.dg/goacc/routine-4.f90   -O   (test for errors, line 90)
> FAIL: gfortran.dg/goacc/routine-4.f90   -O   (test for warnings, line 114)
> FAIL: gfortran.dg/goacc/routine-4.f90   -O   (test for warnings, line 141)
> FAIL: gfortran.dg/goacc/routine-4.f90   -O   (test for warnings, line 47)
> FAIL: gfortran.dg/goacc/routine-4.f90   -O   (test for warnings, line 52)
> FAIL: gfortran.dg/goacc/routine-4.f90   -O   (test for warnings, line 57)
> FAIL: gfortran.dg/goacc/routine-4.f90   -O   (test for warnings, line 62)
> FAIL: gfortran.dg/goacc/routine-4.f90   -O   (test for warnings, line 83)
> FAIL: gfortran.dg/goacc/routine-4.f90   -O   (test for warnings, line 88)
> FAIL: gfortran.dg/goacc/routine-4.f90   -O  2 (test for warnings, line 131)
> FAIL: gfortran.dg/goacc/routine-4.f90   -O  3 (test for warnings, line 121)
> FAIL: gfortran.dg/goacc/routine-5.f90   -O   (test for errors, line 104)
> FAIL: gfortran.dg/goacc/routine-5.f90   -O   (test for errors, line 109)
> FAIL: gfortran.dg/goacc/routine-5.f90   -O   (test for errors, line 45)
> FAIL: gfortran.dg/goacc/routine-5.f90   -O   (test for errors, line 72)
> FAIL: gfortran.dg/goacc/routine-5.f90   -O   (test for errors, line 77)
> FAIL: gfortran.dg/goacc/routine-5.f90   -O   (test for errors, line 99)
> FAIL: gfortran.dg/goacc/routine-5.f90   -O   (test for warnings, line 94)

It appears these test cases should be generating messages like this:

seurer@genoa:~/gcc/build/gcc-test3$ svn info $GCC_SRC
Revision: 241295
seurer@genoa:~/gcc/build/gcc-test3$
/home/seurer/gcc/build/gcc-test3/gcc/testsuite/gfortran/../../gfortran
-B/home/seurer/gcc/build/gcc-test3/gcc/testsuite/gfortran/../../
-B/home/seurer/gcc/build/gcc-test3/powerpc64le-unknown-linux-gnu/./libgfortran/
/home/seurer/gcc/gcc-test3/gcc/testsuite/gfortran.dg/goacc/routine-4.f90 
-fno-diagnostics-show-caret -fdiagnostics-color=never-O  -fopenacc -S   -o
routine-4.s
/home/seurer/gcc/gcc-test3/gcc/testsuite/gfortran.dg/goacc/routine-4.f90:54:0:
Error: routine call uses same OpenACC parallelism as containing loop
/home/seurer/gcc/gcc-test3/gcc/testsuite/gfortran.dg/goacc/routine-4.f90:52:0:
note: containing loop here
/home/seurer/gcc/gcc-test3/gcc/testsuite/gfortran.dg/goacc/routine-4.f90:121:0:
note: routine 'gang' declared here
/home/seurer/gcc/gcc-test3/gcc/testsuite/gfortran.dg/goacc/routine-4.f90:59:0:
Error: routine call uses same OpenACC parallelism as containing loop
/home/seurer/gcc/gcc-test3/gcc/testsuite/gfortran.dg/goacc/routine-4.f90:57:0:
note: containing loop here
/home/seurer/gcc/gcc-test3/gcc/testsuite/gfortran.dg/goacc/routine-4.f90:121:0:
note: routine 'gang' declared here
/home/seurer/gcc/gcc-test3/gcc/testsuite/gfortran.dg/goacc/routine-4.f90:64:0:
Error: routine call uses same OpenACC parallelism as containing loop
/home/seurer/gcc/gcc-test3/gcc/testsuite/gfortran.dg/goacc/routine-4.f90:62:0:
note: containing loop here
/home/seurer/gcc/gcc-test3/gcc/testsuite/gfortran.dg/goacc/routine-4.f90:121:0:
note: routine 'gang' declared here
/home/seurer/gcc/gcc-test3/gcc/testsuite/gfortran.dg/goacc/routine-4.f90:47:0:
Warning: insufficient partitioning available to parallelize loop
/home/seurer/gcc/gcc-test3/gcc/testsuite/gfortran.dg/goacc/routine-4.f90:85:0:
Error: routine call uses same OpenACC parallelism as containing loop
/home/seurer/gcc/gcc-test3/gcc/testsuite/gfortran.dg/goacc/routine-4.f90:83:0:
note: containing loop here
/home/seurer/gcc/gcc-test3/gcc/testsuite/gfortran.dg/goacc/routine-4.f90:131:0:
note: routine 'worker' declared here
/home/seurer/gcc/gcc-test3/gcc/testsuite/gfortran.dg/goacc/routine-4.f90:90:0:
Error: routine call uses same OpenACC parallelism as containing loop
/home/seurer/gcc/gcc-test3/gcc/testsuite/gfortran.dg/goacc/routine-4.f90:88:0:
note: containing loop here
/home/seurer/gcc/gcc-test3/gcc/testsuite/gfortran.dg/goacc/routine-4.f90:131:0:
note: routine 'worker' declared here
/home/seurer/gcc/gcc-test3/gcc/testsuite/gfortran.dg/goacc/routine-4.f90:116:0:
Error: routine call uses same OpenACC parallelism as containing loop

[Bug target/78023] ice in replace_one_candidate with -O3 and -march=native

[ubizjak at gmail dot com]

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

--- Comment #3 from Uroš Bizjak  ---
(In reply to David Binderman from comment #0)
> Created attachment 39831 [details]
> C source code after creduce
> 
> The attached C code, when compiled by gcc trunk dated 20161018,
> and compiler flags -O3 -march=native, does this:

BTW: Please note that -march=native gets replaced with true -march=... and a
bunch of -mABI options by the compiler driver. 

You can see options, passed by the driver, by adding -### to the compiler
flags. Please report -march=... that is determined by the driver. Usually, this
is enough to reproduce the bug, for some unusual targets (e.g. emulators)
please also report other -m... options. 

> The processor has this in /proc/cpuinfo

This info is useless and redundant when true -march= is reported.

[Bug tree-optimization/77902] Auto-vectorizes epilogue loops of manually vectorized functions

[linux at carewolf dot com]

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

Allan Jensen  changed:

   What|Removed |Added

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

--- Comment #3 from Allan Jensen  ---
Since it appears to be optimized better in gcc 7, let's say this is resolved.

[Bug middle-end/78016] REG_NOTE order is not kept during insn copy

[jiwang at gcc dot gnu.org]

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

--- Comment #2 from Jiong Wang  ---
(In reply to Eric Botcazou from comment #1)
> > I attached a simply fix to keep REG-NOTE order during insn copy.
> > 
> > Any comments?
> 
> This seems reasonable if you need it for the DWARF CFI stuff, but note that
> emit_copy_of_insn_after is not the only place where notes are copied, e.g.
> try_split or create_copy_of_insn_rtx does that too.

Thanks for the comments Eric.

I am wondering whether it's OK to use copy_insn_1 here? that is to replace the
whole for loop into something simply as "REG_NOTES (new_insn) = copy_insn_1
(REG_NOTES (old_insn);"  as I think copy_insn_1 will do recursive copy.  This
is what's used in old reload1.c.

in emit_copy_of_insn_after, gcc is skipping REG_LABEL_OPERAND because it is
thinking the above mark_jump_label will generate that.  My understanding is
it's also OK to copy from the source as they will be identical given the
CODE_LABEL is the same.

So copy_insn_1 is safe?

For the other two places, try_split will just return if the insn is
RTX_FRAME_RELATED_P, so should be OK.

  /* We're not good at redistributing frame information.  */
  if (RTX_FRAME_RELATED_P (trial))
return trial;

While for create_copy_of_insn_rtx in sel-sched-ir.c, I find those historical
discussion at https://gcc.gnu.org/ml/gcc-patches/2011-12/msg01232.html, it was
supposed to copy REG_ARGS_SIZE only, later extended to all except
REG_LABEL_OPERAND/REG_EQUAL/REG_EQUALV.  There is actually no mark_jump_label
here, so I am thinking the skip of REG_LABEL_OPERAND is wrong, while I am not
sure if copying REG_EQUAL/REG_EQUALV is wrong.

[Bug target/78023] ice in replace_one_candidate with -O3 and -march=native

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #2 from Markus Trippelsdorf  ---
This is already fixed by r241305.

[Bug target/78023] ice in replace_one_candidate with -O3 and -march=native

[dcb314 at hotmail dot com]

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

--- Comment #1 from David Binderman  ---
Created attachment 39832
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39832=edit
gzipped C source code, before creduce

[Bug target/78023] New: ice in replace_one_candidate with -O3 and -march=native

[dcb314 at hotmail dot com]

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

Bug ID: 78023
   Summary: ice in replace_one_candidate with -O3 and
-march=native
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 39831
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39831=edit
C source code after creduce

The attached C code, when compiled by gcc trunk dated 20161018,
and compiler flags -O3 -march=native, does this:

$ ../results/bin/gcc -c -O3 -march=native bug312.c
../../src/H5Tconv.c: In function ‘H5T__conv_int_float’:
../../src/H5Tconv.c:7558:1: internal compiler error: in replace_one_candidate,
at gimple-ssa-strength-reduction.c:3375
0x139c70e replace_one_candidate
../../trunk/gcc/gimple-ssa-strength-reduction.c:3375
0x13a1359 replace_profitable_candidates
../../trunk/gcc/gimple-ssa-strength-reduction.c:3486
0x13a13a5 replace_profitable_candidates
../../trunk/gcc/gimple-ssa-strength-reduction.c:3495
0x13a504f analyze_candidates_and_replace
../../trunk/gcc/gimple-ssa-strength-reduction.c:3574

The processor has this in /proc/cpuinfo

processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 21
model   : 2
model name  : AMD FX(tm)-8350 Eight-Core Processor
stepping: 0
microcode   : 0x600084f
cpu MHz : 4000.000
cache size  : 2048 KB
physical id : 0
siblings: 8
core id : 0
cpu cores   : 4
apicid  : 16
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 13
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clf
lush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm
constant_tsc rep_good 
nopl nonstop_tsc extd_apicid aperfmperf eagerfpu pni pclmulqdq monitor ssse3
fma cx16 sse4_1 
sse4_2 popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm
sse4a misalign
sse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext
perfctr_core pe
rfctr_nb cpb hw_pstate vmmcall bmi1 arat npt lbrv svm_lock nrip_save tsc_scale
vmcb_clean flu
shbyasid decodeassists pausefilter pfthreshold
bugs: fxsave_leak sysret_ss_attrs null_seg
bogomips: 8026.96
TLB size: 1536 4K pages
clflush size: 64
cache_alignment : 64
address sizes   : 48 bits physical, 48 bits virtual
power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro

[Bug c++/67697] [concepts] ICE when using non-constexpr in requires expression

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-18
 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Started with r226713, where Concepts were introduced.

[Bug middle-end/65950] exit in main is causing the path to it to become unlikely.

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |7.0

--- Comment #13 from Andrew Pinski  ---
Fixed.

[Bug middle-end/65950] exit in main is causing the path to it to become unlikely.

[pinskia at gcc dot gnu.org]

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

--- Comment #12 from Andrew Pinski  ---
Author: pinskia
Date: Tue Oct 18 15:42:21 2016
New Revision: 241309

URL: https://gcc.gnu.org/viewcvs?rev=241309=gcc=rev
Log:
2016-10-18  Andrew Pinski  

PR tree-opt/65950
* predict.c (is_exit_with_zero_arg): New function.
(tree_bb_level_predictions): Don't consider paths leading to exit(0)
as nottaken.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/predict.c

[Bug target/78020] [AArch64] vuzp{1,2}q_f64 implementation identical to vzip{1,2}q_f64 in arm_neon.h and probably incorrect

[christophe.monat at st dot com]

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

--- Comment #6 from Christophe Monat  ---
James,

(In reply to James Greenhalgh from comment #5)
> This bug looks invalid to me. I think you're both failing to grasp the
> intuition behind these intrinsics. Ignoring the descriptions in the
> reference manual for a second, and thinking only in terms of vector
> operations. If you start with:

Thank you for your truly authoritative exposition of the working of the ASIMD
zip/unzip pair that is a much better read than the manual (this does not excuse
my error).

At least, I'll keep this post as a future reference.

Kyrill, Yvan,

Thank you both for the time that you spent with my blunder, I took my lesson
here.
--C

[Bug c++/69637] ICE on an invalid bit-field with template name for width

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed|2016-02-02 00:00:00 |2016-10-18
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
All releases that support -std=c++11 ICE (4.7.0).

[Bug libgcc/78017] weak reference usage in gthr-posix.h (__gthread*) is broken

[nsz at gcc dot gnu.org]

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

--- Comment #2 from nsz at gcc dot gnu.org ---
i see the glibc threads linked from
https://sourceware.org/bugzilla/show_bug.cgi?id=5784
but there are other libcs with static linking support, so even
if weakrefs worked on glibc (now they don't) this would be a
gcc bug on other targets..

when this came up with musl libc it required fair amount of
debugging and i see other cases where people spent time on this:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33960
so i think it is worth changing the logic.

[Bug c++/78022] Strange C++ compilation error

[fiesh at zefix dot tv]

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

--- Comment #1 from fiesh at zefix dot tv ---
The same happens with 6.2.1.

[Bug c++/70555] ICE in expand_expr_real_1 accessing a multi-dimensional VLA via lambda-capture

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-18
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Martin Liška  ---
Confirmed, ICEs on all releases I have (4.5.0+).

[Bug c++/70565] [5/6/7 Regression] ICE at gimplify.c:8832 (cilkplus array extension)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||4.9.4
   Keywords||ice-on-invalid-code
   Last reconfirmed||2016-10-18
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|ICE at gimplify.c:8832  |[5/6/7 Regression] ICE at
   |(cilkplus array extension)  |gimplify.c:8832 (cilkplus
   ||array extension)
   Target Milestone|--- |5.5
  Known to fail||5.4.0, 6.2.0, 7.0

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

[Bug target/78020] [AArch64] vuzp{1,2}q_f64 implementation identical to vzip{1,2}q_f64 in arm_neon.h and probably incorrect

[jgreenhalgh at gcc dot gnu.org]

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

James Greenhalgh  changed:

   What|Removed |Added

 CC||jgreenhalgh at gcc dot gnu.org

--- Comment #5 from James Greenhalgh  ---
This bug looks invalid to me. I think you're both failing to grasp the
intuition behind these intrinsics. Ignoring the descriptions in the reference
manual for a second, and thinking only in terms of vector operations. If you
start with:

  v1 = {a0, a1, a2, a3}
  v2 = {b0, b1, b2, b3}

Then a zipped vector would look like:

  zipped = {a0, b0, a1, b1, a2, b2, a3, b3}

zip1 takes the low elements of the vector (the first half), and zip2 takes the
high elements of the vector (the second half), i.e.

  zip1 = {a0, b0, a1, b1}
  zip1 = {a2, b2, a3, b3}

And for clarity, with two element vectors, you're looking at:

  v1 = {a0, a1}
  v2 = {b0, b2}
  zipped = {a0, b0, a1, b1}
  zip1 = {a0, b0}
  zip2 = {a1, b1}

uzp is the inverse operation, which takes a vector which has been zipped, and
unzips it in to two components. That is to say:

  v1 = {a0, b0, a1, b1}
  v2 = {a2, b2, a3, b3}
  concatenated = {a0, b0, a1, b1, a2, b2, a3, b3}
  unzipped = {a0, a1, a2, a3, b0, b1, b2, b3}
  uzp1 = {a0, a1, a2, a3}
  uzp2 = {b0, b1, b2, b3}

Running this example with two element vectors:

  v1 = {a0, b0}
  v2 = {a1, b1}
  concatenated = {a0, b0, a1, b1}
  unzipped = {a0, a1, b0, b1}
  uzp1 = {a0, a1}
  uzp2 = {b0, b1}

And finally, with the labelling of elements identical to the labelling of
elements we used for the zip example:

  v1 = {a0, a1}
  v2 = {b0, b1}
  concatenated = {a0, a1, b0, b1}
  unzipped = {a0, b0, a1, b1}
  uzp1 = {a0, b0}
  uzp2 = {a1, b1}

This should make it clear that for a two element vector uzp1 == zip1 and uzp2
== zip2. As implemented in GCC.

[Bug libgomp/67335] [6/7 Regression] ICE in compiling omp simd function with unused argument

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code, openmp
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-18
Summary|[ICE] in compiling omp simd |[6/7 Regression] ICE in
   |function with unused|compiling omp simd function
   |argument|with unused argument
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, started with 4.9.0.

[Bug c++/78022] New: Strange C++ compilation error

[fiesh at zefix dot tv]

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

Bug ID: 78022
   Summary: Strange C++ compilation error
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fiesh at zefix dot tv
  Target Milestone: ---

The following piece of code does not compile.  Since clang 3.8.1 compiles it,
and furthermore changes that would appear inconsequential make it compile, I
suspect it might be an issue of GCC:

--
#include 

template
struct A
{
template
constexpr A(Args&&... args) :
entries_{std::forward(args)...} {}
std::array entries_;
};

struct B : public A
{
using A::A;
};

// Uncommenting the following line makes this file compile.
//constexpr B p{0};
// Commenting the following line makes this file compile.
template
struct X
{
X()
{
// The following line is fine.
const B b0{0};
// The following line produces an error.
constexpr B b1{0};
}
};
--

The output is as follows:
% g++ -std=c++11 -c test.cpp
test.cpp: In constructor ‘X::X()’:
test.cpp:31:20: error: ‘constexpr B::B(Args&& ...) [with Args = {int}]’ used
before its definition
constexpr B b1{0};

[Bug target/77345] [7 Regression] Segmentation fault w/ -misel -O1 (and above)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-18
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

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

[Bug target/78020] [AArch64] vuzp{1,2}q_f64 implementation identical to vzip{1,2}q_f64 in arm_neon.h and probably incorrect

[yroux at gcc dot gnu.org]

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

--- Comment #4 from Yvan Roux  ---

> Yes, you're right Yvan.
> James just went through it with me on a board and they are indeed equivalent.
> Sorry for the confusion.

No worries, this kind of thing is tricky and deserve board drawings, It's a
really good thing these figures were added to the manual !

[Bug target/78020] [AArch64] vuzp{1,2}q_f64 implementation identical to vzip{1,2}q_f64 in arm_neon.h and probably incorrect

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from ktkachov at gcc dot gnu.org ---
(In reply to Yvan Roux from comment #2)
> Christophe, Kyrill
> 
> My understanding of the ARMv8-A Architecture Reference Manual is not the
> same.  For me when the vectors have two elements ZIP, UZIP and TRN
> instruction give the same result.
> 
> for instance if we have:
> 
>+ -+--+
> Vn |  A1  |  A0  |
>+ -+--+
> Vm |  B1  |  B0  |
>+ -+--+
> 
> UZIP1 reads the even-numbered elemenents of Vn (i.e A0), places it in the
> lower half of Vd and then do the same with Vm, thus we have:
> 
>+ -+--+
> Vd |  B0  |  A0  |
>+ -+--+
> 
> ZIP1 reads the first pair from Vn (which is only A0 is this case) and places
> it into the lowest element of Vd and then do same with Vm to get them
> interleaved, thus we also have:
> 
>+ -+--+
> Vd |  B0  |  A0  |
>+ -+--+
> 
> Maybe the confusion comes from the revision of the manual you looked at,
> which doesn't include detailled explanation of these instructions,
> DDI0487A_k includes figures.
> 
> Kyrill, in the UZP1 figures (C7.2.346) it show that the first unzipped
> vector is from Vn ... but maybe I'm the one who misundertand the description
> ! ;)

Yes, you're right Yvan.
James just went through it with me on a board and they are indeed equivalent.
Sorry for the confusion.

[Bug target/78020] [AArch64] vuzp{1,2}q_f64 implementation identical to vzip{1,2}q_f64 in arm_neon.h and probably incorrect

[yroux at gcc dot gnu.org]

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

Yvan Roux  changed:

   What|Removed |Added

 CC||yroux at gcc dot gnu.org

--- Comment #2 from Yvan Roux  ---
Christophe, Kyrill

My understanding of the ARMv8-A Architecture Reference Manual is not the same. 
For me when the vectors have two elements ZIP, UZIP and TRN instruction give
the same result.

for instance if we have:

   + -+--+
Vn |  A1  |  A0  |
   + -+--+
Vm |  B1  |  B0  |
   + -+--+

UZIP1 reads the even-numbered elemenents of Vn (i.e A0), places it in the lower
half of Vd and then do the same with Vm, thus we have:

   + -+--+
Vd |  B0  |  A0  |
   + -+--+

ZIP1 reads the first pair from Vn (which is only A0 is this case) and places it
into the lowest element of Vd and then do same with Vm to get them interleaved,
thus we also have:

   + -+--+
Vd |  B0  |  A0  |
   + -+--+

Maybe the confusion comes from the revision of the manual you looked at, which
doesn't include detailled explanation of these instructions, DDI0487A_k
includes figures.

Kyrill, in the UZP1 figures (C7.2.346) it show that the first unzipped vector
is from Vn ... but maybe I'm the one who misundertand the description ! ;)

[Bug target/77991] [5/6/7 Regression] ICE on x32 in plus_constant, at explow.c:87

[hjl.tools at gmail dot com]

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

--- Comment #5 from H.J. Lu  ---
(In reply to Uroš Bizjak from comment #3)
> HJ, can you please test the proposed patch on x32?

There is no regression on x32.  Thanks.

[Bug c++/67980] left shift count is negative [-Wshift-count-negative] generated for unreachable code

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com

--- Comment #5 from Paolo Carlini  ---
Looking into it.

[Bug tree-optimization/77989] [7 Regression] -O3 causes verify_gimple fail

[amker at gcc dot gnu.org]

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

--- Comment #5 from amker at gcc dot gnu.org ---
As suspected. VRP missed folding statement after copy propagation.  Testing
patch...

[Bug target/78020] [AArch64] vuzp{1,2}q_f64 implementation identical to vzip{1,2}q_f64 in arm_neon.h and probably incorrect

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||wrong-code
   Last reconfirmed||2016-10-18
 CC||ktkachov at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|[Aarch64, ARM64]|[AArch64] vuzp{1,2}q_f64
   |vuzp{1,2}q_f64  |implementation identical to
   |implementation identical to |vzip{1,2}q_f64 in
   |vzip{1,2}q_f64 in   |arm_neon.h and probably
   |arm_neon.h and probably |incorrect
   |incorrect   |
   Target Milestone|--- |7.0
  Known to fail||4.8.5, 4.9.4, 5.3.1, 6.0,
   ||7.0

--- Comment #1 from ktkachov at gcc dot gnu.org ---
I think you're right after reading the ARM ARM (the same version as you)
I suppose the minimal testcase is something like:

#include "arm_neon.h"

double amem[] = {1.0, 2.0};
double bmem[] = {3.0, 4.0};

int
main (void)
{
  float64x2_t a = vld1q_f64 (amem);
  float64x2_t b = vld1q_f64 (bmem);

  float64x2_t res = vuzp1q_f64 (a, b);
  if (vgetq_lane_f64 (res, 0) != 3.0
  || vgetq_lane_f64 (res, 1) != 1.0)
__builtin_abort ();

  return 0;
}


I guess it can a bit fiddly to get right because in the instruction:
UZP1 ., ., .

the 'zipped' vector that we unzip is Vm:Vn i.e. Vm goes first and so
the first element of the unzipped vector is from Vm

[Bug target/77991] [5/6/7 Regression] ICE on x32 in plus_constant, at explow.c:87

[uros at gcc dot gnu.org]

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

--- Comment #4 from uros at gcc dot gnu.org ---
Author: uros
Date: Tue Oct 18 14:39:39 2016
New Revision: 241308

URL: https://gcc.gnu.org/viewcvs?rev=241308=gcc=rev
Log:
PR target/77991
* config/i386/i386.c (legitimize_tls_address)
: For TARGET_64BIT || TARGET_ANY_GNU_TLS
convert dest to Pmode if different than Pmode.

testsuite/ChangeLog:

PR target/77991
* gcc.target/i386/pr77991.c: New test.


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

[Bug fortran/78021] Wrong result with optimization on character constant

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #2 from Dominique d'Humieres  ---
The output at run time is 5 if the code is compiled with
'-fno-frontend-optimize'.

[Bug fortran/78021] Wrong result with optimization on character constant

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-18
 CC||marxin at gcc dot gnu.org
  Known to work||4.6.4
 Ever confirmed|0   |1
  Known to fail||4.7.0

--- Comment #1 from Martin Liška  ---
Confirmed, started with GCC 4.7.0.

[Bug fortran/78021] New: Wrong result with optimization, character constant

[dcesari69 at gmail dot com]

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

Bug ID: 78021
   Summary: Wrong result with optimization, character constant
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcesari69 at gmail dot com
  Target Milestone: ---

The following simple code:

PROGRAM test_o_char
PRINT*,mylen('c')+mylen('c   ')

CONTAINS

FUNCTION mylen(c)
CHARACTER(len=*),INTENT(in) :: c
INTEGER :: mylen
mylen=LEN(c)
END FUNCTION mylen
END PROGRAM test_o_char

gives a wrong result (8 instead of 5) when compiled with -O1 or higher. It is
evident that a static optimisation does not take into account blank padding of
character constants and considers the two calls to mylen() equivalent.

GNU Fortran (GCC) 6.2.1 20160916 (Red Hat 6.2.1-2)
Copyright (C) 2016 Free Software Foundation, Inc.

[Bug middle-end/77964] [7 Regression] Linux kernel firmware loader miscompiled

[jakub at gcc dot gnu.org]

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

--- Comment #17 from Jakub Jelinek  ---
(In reply to Jiri Slaby from comment #16)
> (In reply to Jakub Jelinek from comment #15)
> > lots of them that rely on pointer arithmetics being defined only within the
> > same object.
> 
> Sure, but the two pointers (taken implicitly of the arrays) are within the
> same object. So I do not see, why it wouldn't work? I.e. where exactly this
> breaks the C specs?

No.  In C
extern struct builtin_fw __start_builtin_fw[];
extern struct builtin_fw __end_builtin_fw[];
declares two external arrays, thus they are two independent objects.  It is
like if you have:
int a[10];
int b[10];
in your program, although they might be allocated adjacent, such that
int *p = [10]; int *q = [0]; memcmp (, , sizeof (p)) == 0;
[0] - [0] is still UB.
What you do with __start_*/__end_* symbols is nothing you can define in C, you
need linker support or asm for that, and to use it without UB you also need to
use an optimization barrier that has been suggested.

[Bug libgcc/78017] weak reference usage in gthr-posix.h (__gthread*) is broken

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
IIRC this was declared a libc bug or an user error (not using the full
archive). There is another thread on the glibc side if you want to read up on
that.

[Bug libitm/63907] libitm/config/posix/rwlock.cc doesn't compile

[lts-rudolph at gmx dot de]

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

--- Comment #10 from Klaus Rudolph  ---
Created attachment 39830
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39830=edit
preprocessed file rwlock.ii

Add rwlock.ii file as requested.

[Bug middle-end/77964] [7 Regression] Linux kernel firmware loader miscompiled

[jirislaby at gmail dot com]

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

--- Comment #16 from Jiri Slaby  ---
(In reply to Jakub Jelinek from comment #15)
> lots of them that rely on pointer arithmetics being defined only within the
> same object.

Sure, but the two pointers (taken implicitly of the arrays) are within the
same object. So I do not see, why it wouldn't work? I.e. where exactly this
breaks the C specs?

[Bug middle-end/77964] [7 Regression] Linux kernel firmware loader miscompiled

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek  ---
(In reply to Jiri Slaby from comment #14)
> (In reply to Andrew Pinski from comment #10)
> > (In reply to Markus Trippelsdorf from comment #9)
> > > Is subtracting undefined, too?
> > Yes.  Comparing two unrelated arrays or subtracting them is undefined.
> 
> But they are not unrelated arrays. So what from the C standard actually
> makes (and allows) gcc think they are unrelated?

C doesn't have any notion of "related" declarations.

> And given gcc 7 is to be released yet, can we have a switch to disable this
> optimization?

This is nothing new in GCC 7, you've most likely just been extremely lucky in
the past that it happened to work as you expected.  Other projects had to
change similar UB code years ago.  It isn't just a single optimization, but
lots of them that rely on pointer arithmetics being defined only within the
same object.

[Bug middle-end/77964] [7 Regression] Linux kernel firmware loader miscompiled

[jirislaby at gmail dot com]

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

--- Comment #14 from Jiri Slaby  ---
(In reply to Andrew Pinski from comment #10)
> (In reply to Markus Trippelsdorf from comment #9)
> > Is subtracting undefined, too?
> Yes.  Comparing two unrelated arrays or subtracting them is undefined.

But they are not unrelated arrays. So what from the C standard actually makes
(and allows) gcc think they are unrelated?

And given gcc 7 is to be released yet, can we have a switch to disable this
optimization?

[Bug tree-optimization/77916] [6/7 Regression] ICE in verify_gimple_in_cfg: invalid (pointer) operands to plus/minus

[wschmidt at gcc dot gnu.org]

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

--- Comment #5 from Bill Schmidt  ---
Author: wschmidt
Date: Tue Oct 18 13:35:19 2016
New Revision: 241305

URL: https://gcc.gnu.org/viewcvs?rev=241305=gcc=rev
Log:
2016-10-18  Bill Schmidt  

PR tree-optimization/77916
* gimple-ssa-strength-reduction.c (analyze_increments): Reinstate
stopgap fix, as pointers with -1 increment are still broken.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-strength-reduction.c

[Bug libitm/63907] libitm/config/posix/rwlock.cc doesn't compile

[lts-rudolph at gmx dot de]

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

--- Comment #9 from Klaus Rudolph  ---
hi all,

> Gesendet: Freitag, 14. Oktober 2016 um 10:32 Uhr
> Von: "redi at gcc dot gnu.org" 
> An: lts-rudo...@gmx.de
> Betreff: [Bug libitm/63907] libitm/config/posix/rwlock.cc doesn't compile
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63907
> 
> --- Comment #6 from Jonathan Wakely  ---
> See https://gcc.gnu.org/bugs/
> 


How can I add "-save-temps" to the gcc build process itself. Because the bug is
compiling the libitm library from the compiler compilation itself. Anything
which can be done with "./configure" or must the Makefiles be patched? I have
no idea how to set this additional CFLAG/CXXFLAG or similar.

Regards
 Klaus

[Bug c++/78018] [C++14] "internal compiler error: Segmentation fault" with templates and lambdas

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-18
 CC||trippels at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||5.4.0, 6.2.0, 7.0

--- Comment #1 from Markus Trippelsdorf  ---
Confirmed. It is not a regression, because it never worked.

Even icc crashes:

markus@x4 tmp % icpc -c error.cpp
error.cpp(20): internal error: bad pointer
  f2([&] (auto t) { f3(t); } );
^
compilation aborted for error.cpp (code 4)

Clang accepts the code.

[Bug c++/78019] Local class with lambda in default member initializer cannot default-capture this

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-18
 Ever confirmed|0   |1

[Bug target/78020] New: [Aarch64, ARM64] vuzp{1,2}q_f64 implementation identical to vzip{1,2}q_f64 in arm_neon.h and probably incorrect

[christophe.monat at st dot com]

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

Bug ID: 78020
   Summary: [Aarch64, ARM64] vuzp{1,2}q_f64 implementation
identical to vzip{1,2}q_f64 in arm_neon.h and probably
incorrect
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: christophe.monat at st dot com
  Target Milestone: ---

Created attachment 39829
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39829=edit
Suggested patch to fix the zip vs unzp intrinsic issue

I think that vuzp{1,2}q_f64 in gcc/config/aarch64/arm_neon.h are not correctly
implemented.

For instance:
vzip1q_f64 (float64x2_t __a, float64x2_t __b)
(snippage)
  return __builtin_shuffle (__a, __b, (uint64x2_t) {0, 2});

and:
vuzp1q_f64 (float64x2_t __a, float64x2_t __b)
(snippage)
  return __builtin_shuffle (__a, __b, (uint64x2_t) {0, 2});

But then, according to the "ARM Architecture reference Manual, ARMv8 for
ARMv8-A architecture profile" (I am reading ARM DDI 0487A.i (ID 012816)), the
semantic of zip1 and uzp1 differ (C3.5.18 is a convenient starting point to
browse the architectural descriptions).

It looks to me that the correct implementation would look like:
vuzp1q_f64 (float64x2_t __a, float64x2_t __b)
(snippage)
  return __builtin_shuffle (__a, __b, (uint64x2_t) {2, 0});

that would generate
zip1v0.2d, v1.2d, v0.2d
instead of:
zip1v0.2d, v0.2d, v1.2d

and has the correct semantic, though it does not use the uzp1 mnemonic (I
expected this uzp1 to appear more or less at the beginning, and scratched a
little bit my head and draw some diagrams to convince me that I was hopefully
correct).

I have also noticed that vtrn{1,2}q_f64 are implemented in terms of zip{1,2},
but it seems ok semantically (though I had to check manually with the semantic
description and more drawings to convince myself).

I have attached a patch suggesting a change in arm_neon.h, in case this
analysis is correct.

I note that if https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70369 were
completed the occurrence of such issue would be less likely.

[Bug c++/78019] New: Local class with lambda in default member initializer cannot default-capture this

[colu...@gmx-topmail.de]

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

Bug ID: 78019
   Summary: Local class with lambda in default member initializer
cannot default-capture this
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: colu...@gmx-topmail.de
  Target Milestone: ---

int main() {
struct A {
int x, i = [&] { return x; }();
} a{0};
}

-
> error: 'this' was not captured for this lambda function 

Making the default-capture `=' doesn't help, but explicitly capturing `this'
works.

[Bug c++/78018] New: [C++14] "internal compiler error: Segmentation fault" with templates and lambdas

[andipeer at gmx dot net]

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

Bug ID: 78018
   Summary: [C++14] "internal compiler error: Segmentation fault"
with templates and lambdas
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andipeer at gmx dot net
  Target Milestone: ---

Created attachment 39828
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39828=edit
Minimal working example for triggering the crash

Trying to compile the minimal working example that is attached, the compiler
crashes with a segfault. The exact output is stated below. The code should be
correct, as other compilers like Clang have no problem in compiling it.
Note that the bug does not occur if all methods of A are declared inline. Also
note that removing one element of the template-lambda call chain, the bug does
not occur, neither.

Command line: "g++ -std=c++14 -c error.cpp"

The error that is thrown is:

error.cpp: In member function ‘void A::f2(F) [with F =
A::f1()::]’:
error.cpp:24:6: internal compiler error: Segmentation fault
 void A::f2(F f)
  ^
0xad48ef crash_signal
../../src/gcc/toplev.c:333
0xd286ba wi::extended_tree<128>::get_len() const
../../src/gcc/tree.h:5268
0xd286ba wi::int_traits >
>::decompose(long*, unsigned int, generic_wide_int >
const&)
../../src/gcc/wide-int.h:898
0xd286ba
wide_int_ref_storage::wide_int_ref_storage
> >(generic_wide_int > const&, unsigned int)
../../src/gcc/wide-int.h:945
0xd286ba generic_wide_int::generic_wide_int >
>(generic_wide_int > const&, unsigned int)
../../src/gcc/wide-int.h:722
0xd286ba wi::unary_traits >
>::result_type wi::lshift >,
int>(generic_wide_int > const&, int const&)
../../src/gcc/wide-int.h:2847
0xd286ba int_bit_position(tree_node const*)
../../src/gcc/tree.h:5377
0xd286ba classify_argument
../../src/gcc/config/i386/i386.c:8095
0xd28b89 examine_argument
../../src/gcc/config/i386/i386.c:8409
0xd28de6 function_arg_advance_64
../../src/gcc/config/i386/i386.c:8822
0xd28de6 ix86_function_arg_advance
../../src/gcc/config/i386/i386.c:8915
0x8afd94 gimplify_parameters()
../../src/gcc/function.c:3999
0x8e5ef4 gimplify_body(tree_node*, bool)
../../src/gcc/gimplify.c:11522
0x8e6097 gimplify_function_tree(tree_node*)
../../src/gcc/gimplify.c:11682
0x7c5087 cgraph_node::analyze()
../../src/gcc/cgraphunit.c:625
0x7c7a2f analyze_functions
../../src/gcc/cgraphunit.c:1086
0x7c81a8 symbol_table::finalize_compilation_unit()
../../src/gcc/cgraphunit.c:2542

[Bug target/78007] Important loop from 482.sphinx3 is not vectorized

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Probably handling should be moved after
targetm.vectorize.builtin_vectorized_function handling to allow arms
builtin-bswap vectorization via vrev to apply (not sure if its permutation
handling selects vrev for a bswap permutation).

[Bug target/78007] Important loop from 482.sphinx3 is not vectorized

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Created attachment 39827
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39827=edit
untested patch

Mostly untested prototype.  For -mavx2 we get from the testcase innermost loop

.L6:
vmovdqa (%r9,%rdx), %ymm0
addl$1, %r8d
vperm2i128  $0, %ymm0, %ymm0, %ymm0
vpshufb %ymm1, %ymm0, %ymm0
vmovdqa %ymm0, (%r9,%rdx)
addq$32, %rdx
cmpl%r11d, %r8d
jb  .L6

with -msse4:

.L6:
movdqa  (%rax,%rdx), %xmm0
addl$1, %r8d
pshufb  %xmm1, %xmm0
movaps  %xmm0, (%rax,%rdx)
addq$16, %rdx
cmpl%r10d, %r8d
jb  .L6

not sure if I got the bswap permutation vector constant correct either ;) 
(quick hack)

  vect_load_dst_8.13_63 = MEM[(u32 *)vectp_b.11_61];
  load_dst_8 = *_3;
  _64 = VIEW_CONVERT_EXPR(vect_load_dst_8.13_63);
  _65 = VEC_PERM_EXPR <_64, _64, { 3, 2, 1, 0, 3, 2, 1, 0, 3, 2, 1, 0, 3, 2, 1,
0 }>;
  _66 = VIEW_CONVERT_EXPR(_65);
  _13 = __builtin_bswap32 (load_dst_8);
  MEM[(u32 *)vectp_b.14_69] = _66;

[Bug libgcc/78017] New: weak reference usage in gthr-posix.h (__gthread*) is broken

[nsz at gcc dot gnu.org]

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

Bug ID: 78017
   Summary: weak reference usage in gthr-posix.h (__gthread*) is
broken
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nsz at gcc dot gnu.org
  Target Milestone: ---

there seem to be no open bug for the issue discussed in
https://gcc.gnu.org/ml/libstdc++/2014-11/msg00122.html

i think libstdc++, libgfortran and libgcov are affected.

libgcc/gthr-posix.h uses weak references for the pthread api to
1) detect single-threadedness
2) use pthread api without adding -lpthread dependency.

this does not work

a) with static linking:

because 1) fails on the target:

single threaded execution can be assumed if pthread_create and
thrd_create are not referenced (on targets without libpthread
dlopen support), but the gthr logic only checks pthread_create
(on bionic) or pthread_cancel (on some targets as a misguided
attempt to avoid detecting threads because of ldpreloaded pthread
wrappers which "seem unlikely" to define pthread_cancel).

symbols required by libstdc++ may be missing because of 2),
(causing hard to debug runtime crashes):

redhat puts all of libpthread into a single .o, others use
 -Wl,--whole-archive -lpthread -Wl,--no-whole-archive
linker flags as a workaround, but this should not be needed:
if libstdc++.a semantically requires strong references then
those references must be strong (the calls may be elided
using the detection above).

b) if there is dlopen support for libpthread

then single-threadedness can change at runtime, so any check
would break code like

  std::mutex m;
  m.lock();
  dlopen(.. something that starts threads and use m ..)
  m.unlock();


various targets explicitly opt out from the weak ref hacks,
(using gcc configure time hacks), i think instead the gthr
logic should be safe by default:

assume multi-threaded execution by default and only try
to optimize the single threaded case when it is guaranteed
to be safe.

[Bug fortran/78009] [OOP] polymorphic component of derived type array slice handling error

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-18
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from 4.8 up to trunk (7.0).

[Bug libfortran/66756] libgfortran: ThreadSanitizer: lock-order-inversion

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #5 from Dominique d'Humieres  ---
> I also obtain this with GCC 6.1.0.

So moved to NEW.

[Bug middle-end/78016] REG_NOTE order is not kept during insn copy

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-18
 Ever confirmed|0   |1

--- Comment #1 from Eric Botcazou  ---
> I attached a simply fix to keep REG-NOTE order during insn copy.
> 
> Any comments?

This seems reasonable if you need it for the DWARF CFI stuff, but note that
emit_copy_of_insn_after is not the only place where notes are copied, e.g.
try_split or create_copy_of_insn_rtx does that too.

[Bug libstdc++/78015] pthread_cancel while some exception is pending results in std::terminate ()

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
(In reply to Jakub Jelinek from comment #0)
> #ifdef WORKAROUND
>   try
>   {
> throw 1;
>   }
>   catch (int &)
> #endif

Oops, of course I meant #ifndef WORKAROUND.  The problem is when there is an
outstanding normal exception and then we try to rethrow forced unwind exception
that we catch in the catch handler.

[Bug libstdc++/78015] pthread_cancel while some exception is pending results in std::terminate ()

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||rth at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
CCing also Richard as the author of the PR10570 changes.

[Bug middle-end/78016] New: REG_NOTE order is not kept during insn copy

[jiwang at gcc dot gnu.org]

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

Bug ID: 78016
   Summary: REG_NOTE order is not kept during insn copy
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jiwang at gcc dot gnu.org
CC: ebotcazou at gcc dot gnu.org, jakub at redhat dot com
  Target Milestone: ---

Created attachment 39826
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39826=edit
keep REG_NOTE order during insn copy

I recently noticed when copying insn, GCC is actually not keeping the order of
REG_NOTEs.  This seems OK for some types of REG_NOTEs, for example UNUSED,
NORETURN etc.  But it seems not OK for DWARF annotation REG_NOTEs.

The reason is GCC DEARF module will do sanity check to make sure CFI rules come
from multiply paths are identical.


  AB
  \   /
   \ /
\   /
  C

For example, A and B are predecessor of C, then the following code in
"maybe_record_trace_start" in dwarf2cfi.c will do sanity check to make sure
DWARF rules come from A and B will be identical.

  /* We ought to have the same state incoming to a given trace no
 matter how we arrive at the trace.  Anything else means we've
 got some kind of optimization error.  */
  gcc_checking_assert (cfi_row_equal_p (cur_row, ti->beg_row));


As we don't keep the order of REG_NOTE, it's possible the final DWARF rules for
each register won't be identical.

It seems this issue is not exposed because:

  * normally, only prologue and epilogue basic blocks will contain DWARF
annnocation info.
  * Very few passes (bb-reorder) after pro/epi insertion pass will do insn
copy.
  * DWARF sanity check happens before CFI auto deduction, normally backends
only
generate simply DWARF info.  So normally we simply mark the insn as
RTX_FRAME_RELATED_P to let GCC auto-deduct the CFI annocation this happens
after the sanity check.

I came accorss the ICE when I was playing with some DWARF generation.

  0x98c9f4 maybe_record_trace_start
../../gcc-svn/gcc/dwarf2cfi.c:2285
  0x98cd15 create_trace_edges
../../gcc-svn/gcc/dwarf2cfi.c:2379
  0x98d59e scan_trace
../../gcc-svn/gcc/dwarf2cfi.c:2593
  0x98d686 create_cfi_notes
../../gcc-svn/gcc/dwarf2cfi.c:2619
  0x98e172 execute_dwarf2_frame
../../gcc-svn/gcc/dwarf2cfi.c:2977
  0x98ee3e execute
../../gcc-svn/gcc/dwarf2cfi.c:3457

You can reproduce this ICE by

step 1  (patch aarch64.c to generate DWARF manually)
===
Index: gcc/config/aarch64/aarch64.c
===
--- gcc/config/aarch64/aarch64.c(revision 241233)
+++ gcc/config/aarch64/aarch64.c(working copy)
@@ -2958,9 +2958,26 @@

   insn = emit_insn (aarch64_gen_storewb_pair (mode, stack_pointer_rtx, reg1,
  reg2, adjustment));
+#if 0
   RTX_FRAME_RELATED_P (XVECEXP (PATTERN (insn), 0, 2)) = 1;
   RTX_FRAME_RELATED_P (XVECEXP (PATTERN (insn), 0, 1)) = 1;
+#else
+  /* cfi_offset for reg1.  */
+  rtx mem =
+gen_rtx_MEM (Pmode, plus_constant (Pmode, stack_pointer_rtx,
-adjustment));
+  add_reg_note (insn, REG_CFA_OFFSET, gen_rtx_SET (mem, reg1));
+
+  /* cfi_offset for reg2.  */
+  mem =
+gen_rtx_MEM (Pmode,
+plus_constant (Pmode, stack_pointer_rtx, -adjustment + 8));
+  add_reg_note (insn, REG_CFA_OFFSET, gen_rtx_SET (mem, reg2));
+
+  /* .cfi_def_cfa_offset for sp adjustment.  */
+  add_reg_note (insn, REG_CFA_DEF_CFA,
+   plus_constant (Pmode, stack_pointer_rtx, -adjustment));
+  add_reg_note (insn, REG_CFA_OFFSET, gen_rtx_SET (mem, reg2));
+
+  /* .cfi_def_cfa_offset for sp adjustment.  */
+  add_reg_note (insn, REG_CFA_DEF_CFA,
+   plus_constant (Pmode, stack_pointer_rtx, -adjustment));
   RTX_FRAME_RELATED_P (insn) = 1;
+#endif
 }

 static rtx

step 2
===
./configure --target=aarch64-linux --enable-languages=c,c++
make all-gcc -j10
./gcc/cc1 ./gcc/testsuite/gcc.c-torture/execute/20031204-1.c -g -O3 
-funroll-loops -fpeel-loops -ftracer -finline-functions 20031204-1.i
(please remove the #include  in the head of 20031204-1.c)

I attached a simply fix to keep REG-NOTE order during insn copy.

Any comments?

(The only relevant discussion I can find is at
https://gcc.gnu.org/ml/gcc-patches/2012-01/msg00546.html, where and when
REG_NOTE order was thinking to be not matter)

[Bug fortran/68649] [6/7 Regression] note: code may be misoptimized unless -fno-strict-aliasing is used

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #18 from Joost VandeVondele  
---
since this PR, and the related PR77278 can presumably only be fixed by changing
libgfortran abi (at least if I understand Richard's suggestion for fixing
this). The announced major version bump of libgfortran
(https://gcc.gnu.org/ml/gcc-patches/2016-10/msg01376.html) could be a good
opportunity for this change. It is the major thing holding back the use of LTO
with Fortran projects, I think.

[Bug tree-optimization/77943] [5/6 Regression] Optimization incorrectly commons noexcept calls with non-noexcept calls

[marxin at gcc dot gnu.org]

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

--- Comment #13 from Martin Liška  ---
The replacement you described fully makes sense for me! As I mentioned earlier,
I'm not c++ expert, I can't come up with more possible counter examples that
worth for testing.

However, we'll fix further issues ;)

[Bug libstdc++/78015] New: pthread_cancel while some exception is pending results in std::terminate ()

[jakub at gcc dot gnu.org]

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

Bug ID: 78015
   Summary: pthread_cancel while some exception is pending results
in std::terminate ()
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

#include 
#include 

namespace __cxxabiv1
{  
  class __forced_unwind
  {
virtual ~__forced_unwind() throw();
virtual void __pure_dummy() = 0; 
  };
}

int a;

extern "C" void *
fun (void *)
{
#ifdef WORKAROUND
  try
  {
throw 1;
  }
  catch (int &)
#endif
  {
try
{
  char buf[10];
  for (;;)
read (4, buf, 0);
}
catch (__cxxabiv1::__forced_unwind &)
{
  a = 5;
  throw;
}
  }

  return NULL;
}

int
main ()
{
  pthread_t thread;
  pthread_create (, NULL, fun, NULL);
  pthread_cancel (thread);
  pthread_join (thread, NULL);
}

fails with std::terminate (), while works with -DWORKAROUND.
The problem is in __cxa_begin_catch:
51// Note that this use of "header" is a lie.  It's fine so long as we
only
52// examine header->unwindHeader though.
53if (!__is_gxx_exception_class(header->unwindHeader.exception_class))
54  {
55if (prev != 0)
56  std::terminate ();

With -DWORKAROUND, prev is NULL and thus we handle it fine as forced unwinding
exception.
But without that, prev is non-NULL here.  I don't know what exactly should we
do instead if prev is non-NULL,
whether to somehow destruct the previous exception, or just continue normally
and destruct it when the forced unwinding finishes,
or when.