[Bug fortran/78238] [7 Regression] ICE: verify_gimple failed, with -fdefault-integer-8

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC|rguenth at gcc dot gnu.org |
   Target Milestone|--- |7.0

--- Comment #4 from Richard Biener  ---
Well, the FE failed to convert the constant to integer(4) (or the other operand
to integer(8)).

[Bug c++/70909] Libiberty Demangler segfaults (4)

[rschiele at gmail dot com]

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

Robert Schiele  changed:

   What|Removed |Added

 CC||rschiele at gmail dot com

--- Comment #6 from Robert Schiele  ---
*** Bug 67738 has been marked as a duplicate of this bug. ***

[Bug other/67738] infinite recursion in libiberty/cp-demangle.c

[rschiele at gmail dot com]

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

Robert Schiele  changed:

   What|Removed |Added

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

--- Comment #3 from Robert Schiele  ---
Solved with the patch https://gcc.gnu.org/ml/gcc-patches/2016-05/msg00105.html
proposed for PR70909.

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

[Bug libstdc++/78236] regex_iterator constructor is incomplete and creates uninitialized values that may be used

[christophe.monat at st dot com]

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

--- Comment #3 from Christophe Monat  ---
(In reply to Tim Shen from comment #2)
> I proposed another way to fix this in the list:
> https://gcc.gnu.org/ml/libstdc++/2016-11/msg8.html

Looks perfect - I was somewhat annoyed by the _M_match() call anyway.

The test case is a reconstruction from a much bigger one exhibiting an issue
that we encountered at first on ARM/AArch64.

[Bug debug/78247] Unused inline function returning u32string causes u32string debuginfo to be emitted.

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
I don't think this is anything we can fix for dwarf2; maybe for dwarf4 (or 5)
with split debugging.

[Bug libstdc++/78236] regex_iterator constructor is incomplete and creates uninitialized values that may be used

[timshen at gcc dot gnu.org]

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

Tim Shen  changed:

   What|Removed |Added

 CC||timshen at gcc dot gnu.org

--- Comment #2 from Tim Shen  ---
(In reply to Christophe Monat from comment #1)
> Comment on attachment 39982 [details]
> Proposed patch to fix the regex_iterator constructor
> 
> >diff --git a/libstdc++-v3/include/bits/regex.h 
> >b/libstdc++-v3/include/bits/regex.h
> >index a7d45e6..bb0a167 100644
> >--- a/libstdc++-v3/include/bits/regex.h
> >+++ b/libstdc++-v3/include/bits/regex.h
> >@@ -2454,7 +2454,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
> >* one-past-the-end of a range.
> >*/
> >   regex_iterator()
> >-  : _M_match()
> >+  : _M_pregex(), _M_flags(regex_constants::match_default), _M_match()
> >   { }
> > 
> >   /**

I proposed another way to fix this in the list:
https://gcc.gnu.org/ml/libstdc++/2016-11/msg8.html

[Bug fortran/78059] Pointer to variable length array, debug info

[bernhard.heckel at intel dot com]

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

--- Comment #6 from Bernhard Heckel  ---
Ping

[Bug debug/78247] New: Unused inline function returning u32string causes u32string debuginfo to be emitted.

[toojays at toojays dot net]

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

Bug ID: 78247
   Summary: Unused inline function returning u32string causes
u32string debuginfo to be emitted.
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: toojays at toojays dot net
  Target Milestone: ---

Consider the following source, compiled with and without MORE_BLOAT defined:

jscott@citra:~/src/debuginfo-bloat$ cat bloat-string.cpp
#include 

#ifdef MORE_BLOAT
inline std::u32string f(const char32_t* __str, size_t __len)
{ return std::u32string{__str, __len}; }
#endif

jscott@citra:~/src/debuginfo-bloat$ g++-6 -std=c++11 -gdwarf-4 -c
bloat-string.cpp -o bloat-string.o 
jscott@citra:~/src/debuginfo-bloat$ g++-6 -DMORE_BLOAT -std=c++11 -gdwarf-4 -c
bloat-string.cpp -o bloat-string-more.o 
jscott@citra:~/src/debuginfo-bloat$ ls -l bloat-string.o bloat-string-more.o
-rw-rw-r-- 1 jscott jscott 61256 Nov  8 13:58 bloat-string-more.o
-rw-rw-r-- 1 jscott jscott 24672 Nov  8 13:58 bloat-string.o


I.e. if I have an inline function refering to u32string it bloats my output
object by 40K, even though I never used that function. The extra space seems to
go toward debug info for u32string and its associated char_traits.

In effect this occurs whenever someone switches from -std=c++11 to -std=c++14,
because of the inline string literal operators at the end of basic_string.h.

I originally noticed this because switching from -std=c++11 to -std=c++14
increased the size of generated binaries. Discussion at
.

I tried to create a smaller example (i.e. not requiring ), but couldn't
figure out how. The only types I have seen affected by this problem so far are
u16string and u32string.


My test setup:
jscott@citra:~/src/debuginfo-bloat$ gcc-6 -v
Using built-in specs.
COLLECT_GCC=gcc-6
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
6.2.0-3ubuntu11~14.04' --with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-6 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=gcc4-compatible --disable-libstdcxx-dual-abi
--enable-gnu-unique-object --disable-vtable-verify --enable-libmpx
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 6.2.0 20160901 (Ubuntu 6.2.0-3ubuntu11~14.04)

[Bug libstdc++/78231] Should std::sort use unqualifed iter_swap?

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
The correct way to implement swap for your own type is to overload it in your
type's namespace, and it will be found by ADL.
http://stackoverflow.com/questions/11562/how-to-overload-stdswap
http://stackoverflow.com/questions/6380862/how-to-provide-a-swap-function-for-my-class
http://stackoverflow.com/questions/11635172/how-to-implement-swap

That doesn't work for iter_swap, for the reasons stated above: calls to
iter_swap do not use ADL.

It is not valid to add overloads of std::iter_swap, you can't add overloads to
namespace std.

You can specialize it as long as the specialization depends on at least one
program-defined type.

Please follow up in a more appropriate forum. GCC's library is doing the right
thing, so this is not a bug. "How do I do ...?" does not belong in GCC's
bugzilla.

[Bug libstdc++/78231] Should std::sort use unqualifed iter_swap?

[correaa at llnl dot gov]

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

--- Comment #4 from Alfredo  ---
ok, thanks for the clarification. 
So algorithms on iterators that swap use `::std::iter_swap`? (I didn't know
that.) That is step forward. 

Is then one allowed to overload/specialize `std::iter_swap`? Just like one does
with `swap`?

[Bug libstdc++/78231] Should std::sort use unqualifed iter_swap?

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
See 17.6.3.2 [swappable.requirements]. ValueSwappable is defined in terms of
swappable, which is defined in terms of swappable with, which is defined in
terms of an unqualified call to swap. It has nothing to do with std::iter_swap.
This is a special rule for "swap" that doesn't apply to other functions.

17.6.1.1 [contents] says all references to iter_swap in the Standard Library
refer to ::std::iter_swap, i.e. any function specified to call iter_swap must
call ::std::iter_swap not some other function found by ADL.

[Bug libfortran/51119] MATMUL slow for large matrices

[jvdelisle at gcc dot gnu.org]

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

--- Comment #34 from Jerry DeLisle  ---
Created attachment 39987
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39987=edit
A test program

Just ran some tests comparing reference results and results using -Ofast.

-Ofast does reorder execution.. 

Using kind=8

DELTA = (reference - result) and looking at the ranges of minval and maxval
with several random matrices one sees (4 cases):

Using some smaller matrices. see attachment for test program.

 delta minval  delta maxval

-2.2204460492503131E-016   2.2204460492503131E-016

-4.4408920985006262E-016   4.4408920985006262E-016

-2.2204460492503131E-016   2.2204460492503131E-016

-4.4408920985006262E-016   2.2204460492503131E-016

So the wiggling one gets in the least significant bits may matter to some.

With larger arrays (error amplification):

1000 x 1000-1.0231815394945443E-012   8.8107299234252423E-013

2000 x 2000-2.7284841053187847E-012   2.6716406864579767E-012

Compiling the test program with -Ofast so that the reference method has the
same optimization as MATMUL, one gets.

2000 x 2000 0.0.

Opinions welcome.

[Bug c++/72803] [7 Regression] ICE on invalid code in linemap_position_for_loc_and_offset, at libcpp/line-map.c:891

[aldyh at gcc dot gnu.org]

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

--- Comment #6 from Aldy Hernandez  ---
In cp_lexer_new_main() we read all the tokens from the preprocessor:

/* Get the remaining tokens from the preprocessor.  */
  while (token.type != CPP_EOF)
{
  cp_lexer_get_preprocessor_token (lexer, );
  vec_safe_push (lexer->buffer, token);
}

The next to last token we push onto lexer->buffer is the closing brace in the
testcase:

(gdb) p token
$252 = {type = CPP_CLOSE_BRACE, keyword = RID_MAX, flags = 1 '\001', 
  implicit_extern_c = 0, error_reported = 0, purged_p = 0, location = 258432, u
= {
tree_check_value = 0x0, value = }}
(gdb) p token.location
$253 = 258432
(gdb) call expand_location($253)
$254 = {file = 0x7fffe774 "b.ii", line = 1, column = 511, data = 0x0, sysp
= false}

However, the next token is the CPP_EOF, and calling expand_location() again on
the CPP_CLOSE_BRACE token has the line and column offset completely incorrect:

// Read the next token, which is CPP_EOF

(gdb) next
(gdb) p token
$255 = {type = CPP_EOF, keyword = RID_MAX, flags = 64 '@', implicit_extern_c =
0, 
  error_reported = 0, purged_p = 0, location = 258496, u = {tree_check_value =
0x0, 
value = }}

// Look at the closing brace token again:

(gdb) call expand_location($253)
$256 = {file = 0x7fffe774 "b.ii", line = 4, column = 127, data = 0x0, sysp
= false}
(gdb) 

That should still be line 1 and column 511.  Why is it line 4 and column 127? 
Something smells fishy.

[Bug target/78246] Incorrect vector variable set but not used warning

[zoltan at hidvegi dot com]

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

--- Comment #1 from Zoltan Hidvegi  ---
Created attachment 39986
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39986=edit
gcc -O2 -S -Wall warning_test.C gives incorrect warning: variable ‘sm’ set but
not used

[Bug target/78246] New: Incorrect vector variable set but not used warning

[zoltan at hidvegi dot com]

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

Bug ID: 78246
   Summary: Incorrect vector variable set but not used warning
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zoltan at hidvegi dot com
  Target Milestone: ---

Negating a vector variable can cause incorrect unused variable warning. This
happens both on x86 and PowerPC. Compile with g++ -O2 -S -Wall warning_test.C

Interestingly, compiling this as a C program, the warning disappears. This
happens with compiles as old as gcc-4.8 or as new as gcc-6.2

[Bug libstdc++/78231] Should std::sort use unqualifed iter_swap?

[correaa at llnl dot gov]

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

--- Comment #2 from Alfredo  ---
@Jonathan, Can you link to the part of the line in the standard? I found that
standard to be very vague, for example in defining ValueSwappable. Is
ValueSwappable something that can be called with `std::iter_swap`, or just
`iter_swap` or is only defined through `(std::)swap`? (plus the semantics).

Also, When you said "customization point" I searched for it, and I found this
http://ericniebler.com/2014/10/21/customization-point-design-in-c11-and-beyond/

It seems that I am not the first to point this out, and also seems that Eric
has the same opinion "... iter_swap may also be a customization point. (I think
it is, or that it should be.) ..."

[Bug c/71924] missing -Wreturn-local-addr returning alloca result

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
On second thought, the right fix is to report the problem consistently for all
kinds of storage, including auto variables, alloca-ted storage, and compound
literals.

[Bug fortran/71723] [5/6/7 Regression] [F08] ICE on invalid pointer initialization

[w6ws at earthlink dot net]

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

--- Comment #4 from Walter Spector  ---
As you are surmising, there are actually two problems in the example.  First,
'data' needs the 'target' attribute in order to be pointed to.  Second, 'data'
must either have the 'target' or a 'pointer' attribute, but not both.

Walter

[Bug middle-end/78245] missing -Wformat-length on an overflow of a dynamically allocated buffer

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-11-07
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
This is due to a limitation of the compute_builtin_object_size function in
tree-object-size.c.  The function only computes the sizes of dynamically
allocated objects that have been explicitly passed to the __builtin_object_size
intrinsic.

Let me look into removing the limitation and having the function handle
dynamically allocated objects even if they're not passed to the built-in.

[Bug middle-end/78245] New: missing -Wformat-length on an overflow of a dynamically allocated buffer

[msebor at gcc dot gnu.org]

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

Bug ID: 78245
   Summary: missing -Wformat-length on an overflow of a
dynamically allocated buffer
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The -Wformat-length warning points out instances of buffer overflow involving
either statically or automatically allocated buffers but fails to do the same
for dynamically allocated ones, greatly diminishing the usefulness of the
checker.  The test case below demonstrates the problem.


$ cat b.c && /build/gcc-git/gcc/xgcc -B /build/gcc-git/gcc -O2 -S -Wall b.c
char a[2];
char *p;

void f_auto (void)
{
  __builtin_sprintf (a, "%i", 123);  // warning
}

void f_static (void)
{
  char b[2];
  __builtin_sprintf (b, "%i", 123);   // warning

  extern void sink (void*);
  sink (b);
}

void g (void)
{
  p = __builtin_malloc (2);
  __builtin_sprintf (p, "%i", 123);   // no warning
}

b.c: In function ‘f_auto’:
b.c:6:26: warning: ‘%i’ directive writing 3 bytes into a region of size 2
[-Wformat-length=]
   __builtin_sprintf (a, "%i", 123);  // warning
  ^~
b.c:6:3: note: format output 4 bytes into a destination of size 2
   __builtin_sprintf (a, "%i", 123);  // warning
   ^~~~
b.c: In function ‘f_static’:
b.c:12:26: warning: ‘%i’ directive writing 3 bytes into a region of size 2
[-Wformat-length=]
   __builtin_sprintf (b, "%i", 123);   // warning
  ^~
b.c:12:3: note: format output 4 bytes into a destination of size 2
   __builtin_sprintf (b, "%i", 123);   // warning
   ^~~~

[Bug c++/78244] New: Narrowing conversion is accepted in a function template, but it should be rejected

[michele.caini at gmail dot com]

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

Bug ID: 78244
   Summary: Narrowing conversion is accepted in a function
template, but it should be rejected
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: michele.caini at gmail dot com
  Target Milestone: ---

Consider the following code:

auto f() -> decltype(int{0.}, void()) { }
int main() { f(); }

It fails to compile with the following error:

> narrowing conversion of '0.0' from 'double' to 'int' inside { }

On the other side, the following function is accepted:

template 
auto f(T) -> decltype(int{0.}, void()) { }

int main(){
f(0);
}

Narrowing conversion still present.

[Bug fortran/78238] [7 Regression] ICE: verify_gimple failed, with -fdefault-integer-8

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|WAITING |NEW
 CC||rguenth at gcc dot gnu.org
Summary|ICE: verify_gimple failed,  |[7 Regression] ICE:
   |with -fdefault-integer-8|verify_gimple failed, with
   ||-fdefault-integer-8

--- Comment #3 from Dominique d'Humieres  ---
I confirm that configuring with --enable-checking=yes is needed to reproduce
the ICE and I don't see any ICE with r240271.

[Bug target/78243] New: incorrect byte offset in vextractuh with -mcpu=power9

[acsawdey at gcc dot gnu.org]

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

Bug ID: 78243
   Summary: incorrect byte offset in vextractuh with -mcpu=power9
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: meissner at gcc dot gnu.org
  Reporter: acsawdey at gcc dot gnu.org
CC: wschmidt at linux dot vnet.ibm.com
  Target Milestone: ---
Target: powerpc64*-*-*

The test case is:

gcc.c-torture/execute/pr68532.c

#define SIZE 128
unsigned short _Alignas (16) in[SIZE];

__attribute__ ((noinline)) int
test (unsigned short sum, unsigned short *in, int x)
{
  for (int j = 0; j < SIZE; j += 8)
sum += in[j] * x;
  return sum;
}

/home/sawdey/src/gcc/trunk2/build/gcc/xgcc
-B/home/sawdey/src/gcc/trunk2/build/gcc/
/home/sawdey/src/gcc/trunk2/trunk/gcc/testsuite/gcc.c-torture/execute/pr68532.c
-mcpu=power9 -Wl,-rpath=/tmp/lib64 -fno-diagnostics-show-caret
-fdiagnostics-color=never -O2 -O2 -ftree-vectorize -fno-vect-cost-model -lm -g
-S -o pr68532.s

asm output is:

vsplth 0,0,3
lxv 33,-16(4)
vperm 1,1,10,13
vperm 1,1,11,13
xxspltib 43,0
vperm 1,1,12,13
xxspltib 45,0
vmladduhm 0,0,1,13
vsum4shs 0,0,11
vsumsws 0,0,11
vextractuh 0,0,0
mfvsrd 9,32
add 3,3,9

The vsumsws produces a result in word 3 of v0, so the vextractuh 3rd argument
should be 14 to extract bytes 14,15 in order to produce the correct result.

Another question about this code would be why we produce all this complex
vector code but only use it for the first half of the computation, the latter
half uses this simple code:

.L2:
lhz 9,0(4)
addi 4,4,16
mullw 9,9,5
add 3,9,3
.LVL4:
rlwinm 3,3,0,0x
.LVL5:
.loc 1 10 0
bdnz .L2

It seems like we could just do this for 2 vector lengths and not need this
cleanup code.

[Bug target/78229] [6/7 Regression] ICE in redirect_eh_edge_1, at tree-eh.c:2305

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Author: jakub
Date: Mon Nov  7 22:35:43 2016
New Revision: 241942

URL: https://gcc.gnu.org/viewcvs?rev=241942=gcc=rev
Log:
PR target/78229
* config/i386/i386.c (ix86_gimple_fold_builtin): Do not adjust  
EH info even for bzhi and pdep/pext.

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

[Bug libfortran/51119] MATMUL slow for large matrices

[jvdelisle at gcc dot gnu.org]

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

--- Comment #33 from Jerry DeLisle  ---
With #pragma GCC optimize ( "-O3" )

$ gfc -static -O2 -finline-matmul-limit=0 compare.f90 
$ ./a.out 
 =
 MEASURED GIGAFLOPS  =
 =
 Matmul   Matmul
 fixed Matmul variable
 Size  Loops explicit   refMatmul  assumedexplicit
 =
2  2000  0.055  0.051  0.038  0.056
4  2000  0.408  0.274  0.318  0.408
8  2000  0.644  0.711  1.287  1.831
   16  2000  2.507  2.591  2.521  2.579
   32  2000  3.573  2.300  3.506  3.573
   64  2000  4.628  2.196  4.462  4.629
  128  2000  5.030  2.393  5.304  5.054
  256   477  4.802  2.367  5.573  4.854
  51259  3.907  1.856  5.234  4.035
 1024 7  3.891  1.178  5.222  4.022
 2048 1  3.901  1.500  5.238  4.033

and with no #pragma it is better than the -O3 version

$ gfc -static -O2 -finline-matmul-limit=0 compare.f90 
$ ./a.out 
 =
 MEASURED GIGAFLOPS  =
 =
 Matmul   Matmul
 fixed Matmul variable
 Size  Loops explicit   refMatmul  assumedexplicit
 =
2  2000  0.054  0.052  0.043  0.057
4  2000  0.397  0.281  0.316  0.414
8  2000  0.691  0.773  1.831  1.995
   16  2000  2.493  2.691  2.521  2.512
   32  2000  3.629  2.301  3.623  3.572
   64  2000  4.557  2.072  4.568  4.468
  128  2000  5.282  2.387  5.291  5.284
  256   477  5.629  2.369  5.620  5.605
  51259  5.215  1.874  5.240  5.216
 1024 7  5.212  1.174  5.217  5.217
 2048 1  5.230  1.499  5.234  5.229

Still a good improvement over gfortran6 on the larger matrices.

[Bug libstdc++/64735] std::future broken on armel

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
  Component|c++ |libstdc++
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org

--- Comment #8 from Jonathan Wakely  ---
The patch is a pessimization for non-armv5 targets, we don't want to change the
targets that already work correctly. I'll look at a better way to do it (maybe
encapsulating the ref-count more neatly) this week.

[Bug libstdc++/71313] [Filesystem TS] remove_all fails to remove directory contents recursively

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||david_bjornbak at keysight dot 
com

--- Comment #7 from Jonathan Wakely  ---
*** Bug 78167 has been marked as a duplicate of this bug. ***

[Bug libstdc++/78167] experimental/filesystem calls behave differently between Linux gcc 5.3.0 and Windows Visual Studio 2015

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|FIXED   |DUPLICATE

--- Comment #5 from Jonathan Wakely  ---
This was Bug 71313

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

[Bug libstdc++/78236] regex_iterator constructor is incomplete and creates uninitialized values that may be used

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-07
 Ever confirmed|0   |1

[Bug libstdc++/78231] Should std::sort use unqualifed iter_swap?

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
No, iter_swap is not a customization point. The standard seems clear to me.

[Bug libstdc++/78156] constexpr basic_string_view::basic_string_view(const charT *) calls non-constexpr char_traits::length

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
This is not a bug in GCC, and I'm not in favour of complicating things to work
around this limitation. As Daniel said, there is a proposal to make
std::char_traits do the right thing.

[Bug libstdc++/78167] experimental/filesystem calls behave differently between Linux gcc 5.3.0 and Windows Visual Studio 2015

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
I'm going to backport all the  fixes to the
gcc-5-branch soon, so this will be fixed for 5.5

[Bug libstdc++/78184] std::call_once freezes on second execution if the callable threw an exception on first execution

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
dup

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

[Bug libstdc++/66146] call_once not C++11-compliant on ppc64le

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||simon.heybrock at esss dot se

--- Comment #19 from Jonathan Wakely  ---
*** Bug 78184 has been marked as a duplicate of this bug. ***

[Bug libstdc++/77459] [6/7 Regression] undefined reference to `snprintf' when building mingw-w64 cross-compiler

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
(In reply to François Dumont from comment #6)
> Created attachment 39984 [details]
> Stop using __builtin_snprintf until __has_builtin is supported.
> 
> Could you try this patch ? Until we have __has_builtin support I propose to
> simulate __builtin_snprintf with __builtin_sprint.

This patch is wrong in several ways. GCC always supports __builtin_snprintf, so
even if we supported __has_builtin (which is "if" not "until") the test would
not be right. What happens when it's not supported by the target is a linker
error, not a missing builtin.

The patch adds complexity and pessimizes targets that do support snprintf.

[Bug c++/72822] libiberty/ demangler crash

[orion at cora dot nwra.com]

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

Orion Poplawski  changed:

   What|Removed |Added

 CC||orion at cora dot nwra.com

--- Comment #5 from Orion Poplawski  ---
I'm seeing this as well:

../../gdb/cp-support.c:1615: demangler-warning: unable to demangle
'_ZNK6clover6detail11basic_rangeINS_13adaptor_rangeIZNS_6kernel6launchERNS_13command_queueERKSt6vectorImSaImEESA_SA_EUlmE_JRS8_EEENS0_16iterator_adaptorISB_JN9__gnu_cxx17__normal_iteratorIPmS8_ESJ_EcvT_IS6_IPjSaISN_EEvEEv'
(demangler failed with signal 11)

[Bug testsuite/78242] New: Error in testsuite/gcc.dg/asan/use-after-scope-8.c since its introduction

[seurer at linux dot vnet.ibm.com]

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

Bug ID: 78242
   Summary: Error in testsuite/gcc.dg/asan/use-after-scope-8.c
since its introduction
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at linux dot vnet.ibm.com
  Target Milestone: ---

There is a problem in the new test case gcc.dg/asan/use-after-scope-8.c


/home/seurer/gcc/build/gcc-trunk/gcc/xgcc
-B/home/seurer/gcc/build/gcc-trunk/gcc/
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/asan/use-after-scope-8.c
-B/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/./libsanitizer/
-B/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/./libsanitizer/asan/
-L/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/./libsanitizer/asan/.libs
-fsanitize=address -g
-I/home/seurer/gcc/gcc-trunk/gcc/testsuite/../../libsanitizer/include
-fno-diagnostics-show-caret -fdiagnostics-color=never -O0 -fdump-tree-asan0 -S
-o use-after-scope-8.s
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/asan/use-after-scope-8.c: In
function 'fn1':
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/asan/use-after-scope-8.c:9:16:
error: invalid register name for 'a'
compiler exited with status 1
output is:
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/asan/use-after-scope-8.c: In
function 'fn1':
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/asan/use-after-scope-8.c:9:16:
error: invalid register name for 'a'

FAIL: gcc.dg/asan/use-after-scope-8.c   -O0  (test for excess errors)
Excess errors:
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/asan/use-after-scope-8.c:9:16:
error: invalid register name for 'a'

[Bug fortran/78240] ICE in match_clist_expr, at fortran/decl.c:728

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-07
 Ever confirmed|0   |1

--- Comment #3 from Dominique d'Humieres  ---
I don't see any ICE for 4.8 and 4.9 (without -fdec indeed):

pr78240.f90:2.3:

   structure /s/
   1
Error: Unclassifiable statement at (1)
pr78240.f90:4.6:

   end structure
  1
Error: Expecting END PROGRAM statement at (1)
pr78240.f90:3.16:

  integer x(n) /1/
1
Error: Variable 'n' cannot appear in the expression at (1)
pr78240.f90:3.18:

  integer x(n) /1/
  1
Error: The module or main program array 'x' at (1) must have constant shape


Error: Nonconstant array section at (1) in DATA statement

[Bug libfortran/51119] MATMUL slow for large matrices

[jvdelisle at gcc dot gnu.org]

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

--- Comment #32 from Jerry DeLisle  ---
Created attachment 39985
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39985=edit
Proposed patch to get testing going

This patch works pretty good for me. My results are as follows:

gfortran version 6:

$ gfc6 -static -O2 -finline-matmul-limit=0 compare.f90 
[jerry@quasar pr51119]$ ./a.out 
 =
 MEASURED GIGAFLOPS  =
 =
 Matmul   Matmul
 fixed Matmul variable
 Size  Loops explicit   refMatmul  assumedexplicit
 =
2  2000  0.086  0.054  0.060  0.098
4  2000  0.288  0.302  0.256  0.315
8  2000  0.799  0.830  2.094  2.246
   16  2000  4.045  2.539  4.198  4.266
   32  2000  5.358  2.301  5.340  5.335
   64  2000  5.411  2.207  5.391  5.395
  128  2000  5.918  2.416  5.919  5.915
  256   477  5.871  2.393  5.870  5.869
  51259  2.927  1.891  2.927  2.928
 1024 7  1.668  1.182  1.667  1.668
 2048 1  1.763  1.526  1.763  1.763

gfortran version 7:

$ gfc -static -O2 -finline-matmul-limit=0 compare.f90 
[jerry@quasar pr51119]$ ./a.out 
 =
 MEASURED GIGAFLOPS  =
 =
 Matmul   Matmul
 fixed Matmul variable
 Size  Loops explicit   refMatmul  assumedexplicit
 =
2  2000  0.053  0.052  0.043  0.054
4  2000  0.310  0.304  0.277  0.377
8  2000  0.704  0.858  1.711  1.758
   16  2000  2.805  2.529  2.798  2.780
   32  2000  4.693  2.210  4.700  4.821
   64  2000  6.768  2.038  6.732  6.782
  128  2000  8.550  2.419  8.647  8.595
  256   477  9.442  2.378  9.425  9.446
  51259  8.565  1.960  8.641  8.568
 1024 7  8.537  1.178  8.610  8.530
 2048 1  8.576  1.512  8.652  8.582

A portion of the speed up is from using:

#pragma GCC optimize ( "-Ofast" ) which I just discovered. I am thinking
addition and subtraction are fairly safe with this option, however I do not
know if it is acceptable for release since it may contradict somewhere on some
platform or even a gcc policy. But hey it workd for me.

Much testing needed. There is a nice sweet spot at 256. This is on a single
thread on 3.8 GHz core.

[Bug fortran/78238] ICE: verify_gimple failed, with -fdefault-integer-8

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-11-07
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
AFAICT you need a recent compiler configured with --enable-checking=yes. I am
currently investigating.

[Bug fortran/70601] [5/6/7 Regression] [OOP] ICE on procedure pointer component call

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

  Known to work||4.9.4
   Target Milestone|--- |7.0
Summary|[OOP] ICE on procedure  |[5/6/7 Regression] [OOP]
   |pointer component call  |ICE on procedure pointer
   ||component call
  Known to fail||5.4.1, 6.2.0

--- Comment #5 from janus at gcc dot gnu.org ---
I boiled the test case down a bit:


program test
  implicit none

  type :: concrete_type
procedure (run_concrete_type), pointer :: run
  end type

  type(concrete_type), allocatable :: concrete

  allocate(concrete)
  concrete % run => run_concrete_type
  call concrete % run()

contains

   subroutine run_concrete_type(this)
  class(concrete_type) :: this
   end subroutine

end


I see the ICE with trunk and 6.2 and a slightly different one with 5.4, but
none with 4.9, so this is a regression.

[Bug fortran/78239] [5/6/7 Regression] ICE in char_len_param_value, at fortran/decl.c:926, with -fimplicit-none

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
  Known to work||4.9.3
   Keywords||ice-on-invalid-code
   Last reconfirmed||2016-11-07
 CC||kargl at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|ICE in  |[5/6/7 Regression] ICE in
   |char_len_param_value, at|char_len_param_value, at
   |fortran/decl.c:926, with|fortran/decl.c:926, with
   |-fimplicit-none |-fimplicit-none
  Known to fail||5.4.0, 6.2.0, 7.0

--- Comment #2 from Dominique d'Humieres  ---
The changed occurred between revisions r229283 (2015-10-24) which gives the
error

 subroutine s(n)
  1
Error: Symbol 'n' at (1) has no IMPLICIT type

and r229293 (2015-10-25) which gives the ICE, likely r229287 or r229288 for
gcc-6 and r229553 or r229560 for gcc-5.

Note that using "implicit none" in the subroutine gives

pr78239_db.f90:3:13:

character(n) :: c
 1
Error: Scalar INTEGER expression expected at (1)
pr78239_db.f90:1:14:

 subroutine s(n)
  1
Error: Symbol 'n' at (1) has no IMPLICIT type
pr78239_db.f90:4:4:

c = 'c'
1
Error: Symbol 'c' at (1) has no IMPLICIT type

without any ICE.

[Bug libstdc++/77459] [6/7 Regression] undefined reference to `snprintf' when building mingw-w64 cross-compiler

[fdumont at gcc dot gnu.org]

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

--- Comment #6 from François Dumont  ---
Created attachment 39984
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39984=edit
Stop using __builtin_snprintf until __has_builtin is supported.

Could you try this patch ? Until we have __has_builtin support I propose to
simulate __builtin_snprintf with __builtin_sprint.

[Bug middle-end/77784] duplicate warning for snprintf when n > object size

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Sebor  ---
I'll handle this in an update on my cumulative patch for bug 53562 initially
posted for review here:
https://gcc.gnu.org/ml/gcc-patches/2016-10/msg02308.html

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

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||wrong-code
 CC||janus at gcc dot gnu.org
   Target Milestone|--- |7.0

--- Comment #2 from janus at gcc dot gnu.org ---
Slightly simpler test case:


program test
  type :: t
integer :: a
  end type
  type, extends(t) :: tt
integer :: b
  end type
  type :: group
class(t), allocatable, dimension(:) :: unit
  end type

  type(group) :: g
  allocate(tt::g%unit(10))
  g%unit(:)%a = 1

  select type (units => g%unit)
  type is (tt)
do i=1,10
  write(*,*) units(i)%a, units(i)%b
end do
  end select
end program test


Note: When removing the 'group' type and declaring 'unit' directly in the main
program, the correct output is obtained.

[Bug fortran/78122] [5/6/7 Regression] [F08] ICE in get, at cgraph.h:395

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Depends on||55207

--- Comment #5 from janus at gcc dot gnu.org ---
I think the test case is valid. A workaround for the ICE is to declare 'a' with
 the SAVE attribute.

According to the F08 standard every variable in the main program implicitly
gets the SAVE attribute, which is the subject of PR55207.

I assume the regression is caused by r208668.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55207
[Bug 55207] [F08] Variables declared in the main program should implicitly get
the SAVE attribute

[Bug fortran/78240] ICE in match_clist_expr, at fortran/decl.c:728

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to Gerhard Steinmetz from comment #1)
> For completeness, without -fdec :
> 
> 
> $ gfortran-7-20161106 z1.f90
> z1.f90:2:12:
> 
> structure /s/
> 1
> Error: STRUCTURE at (1) is a DEC extension, enable with -fdec-structure
> z1.f90:4:6:
> 
> end structure
>   1
> Error: Expecting END PROGRAM statement at (1)
> z1.f90:3:16:
> 
>integer x(n) /1/
> 1
> Error: Variable 'n' cannot appear in the expression at (1)
> z1.f90:3:18:
> 
>integer x(n) /1/
>   1
> Error: The module or main program array 'x' at (1) must have constant shape
> 
> in gfc_format_decoder, at fortran/error.c:935
> 0x68b46e gfc_format_decoder
> ../../gcc/fortran/error.c:935
> 0x13f1eef pp_format(pretty_printer*, text_info*)
> ../../gcc/pretty-print.c:660
> 0x13e5310 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
> ../../gcc/diagnostic.c:947
> 0x68b307 gfc_error
> ../../gcc/fortran/error.c:1277
> 0x68c700 gfc_error(char const*, ...)
> ../../gcc/fortran/error.c:1306
> 0x6f152a check_data_variable
> ../../gcc/fortran/resolve.c:14939
> 0x6f152a traverse_data_var
> ../../gcc/fortran/resolve.c:15130
> 0x6fbc91 resolve_data
> ../../gcc/fortran/resolve.c:15185
> 0x6fbc91 resolve_types
> ../../gcc/fortran/resolve.c:15939
> 0x6f76ac gfc_resolve(gfc_namespace*)
> ../../gcc/fortran/resolve.c:16027
> 0x6e1bba resolve_all_program_units
> ../../gcc/fortran/parse.c:5883
> 0x6e1bba gfc_parse_file()
> ../../gcc/fortran/parse.c:6130
> 0x725822 gfIndex: resolve.c

===
--- resolve.c   (revision 241667)
+++ resolve.c   (working copy)
@@ -14973,8 +14975,7 @@ check_data_variable (gfc_data_variable *

   if (!gfc_array_size (e, ))
{
- gfc_error ("Nonconstant array section at %L in DATA statement",
->where);
+ gfc_error ("Nonconstant array section at %C in DATA statement");
  mpz_clear (offset);
  return false;
}
c_be_parse_file
> ../../gcc/fortran/f95-lang.c:198

[Bug rtl-optimization/78241] [7 Regression] wrong code with -funroll-loops

[zsojka at seznam dot cz]

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

--- Comment #1 from Zdenek Sojka  ---
$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-241681-checking-yes-rtl-df-extra-nographite-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--without-cloog --without-ppl --without-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-241681-checking-yes-rtl-df-extra-nographite-amd64
Thread model: posix
gcc version 7.0.0 20161029 (experimental) (GCC)

[Bug rtl-optimization/78241] New: [7 Regression] wrong code with -funroll-loops

[zsojka at seznam dot cz]

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

Bug ID: 78241
   Summary: [7 Regression] wrong code with -funroll-loops
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu

Created attachment 39983
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39983=edit
reduced testcase

Output:
$ x86_64-pc-linux-gnu-gcc -Og -funroll-loops testcase.c
$ ./a.out
Aborted

Correct value is 0x, wrong value is 16.
Tested targets that fail in 7.0.0:
aarch64-unknown-linux-gnu
armv7a-hardfloat-linux-gnueabi
armv7a-softfp-linux-gnueabi
powerpc64le-unknown-linux-gnu
powerpc64-unknown-linux-gnu
sparc-unknown-linux-gnu
x86_64-pc-linux-gnu

[Bug testsuite/68972] g++.dg/cpp1y/vla-initlist1.C test case fails on powerpc64le

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #8 from Martin Sebor  ---
The test hasn't changed since December 2014 and it's still failing in recent
test results:

https://gcc.gnu.org/ml/gcc-testresults/2016-11/msg00722.html

Jason didn't like the change I proposed in comment #5 and I haven't come back
to it since then.  I'm busy wrapping up my stage 1 projects and don't expect to
have the time to revisit this for a while, so I'm unassigning myself from this
to give other a chance to work on it.

[Bug libgcc/78064] unwind-c.c never uses _Unwind_GetIPInfo

[fw at gcc dot gnu.org]

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

--- Comment #6 from Florian Weimer  ---
Author: fw
Date: Mon Nov  7 19:54:05 2016
New Revision: 241929

URL: https://gcc.gnu.org/viewcvs?rev=241929=gcc=rev
Log:
PR libgcc/78064: Add missing include directive to unwind-c.c

Backport from mainline
2016-10-24  Florian Weimer  


PR libgcc/78064
* unwind-c.c: Include auto-target.h.

Modified:
branches/gcc-5-branch/   (props changed)
branches/gcc-5-branch/libgcc/ChangeLog
branches/gcc-5-branch/libgcc/unwind-c.c

Propchange: branches/gcc-5-branch/
('svn:mergeinfo' modified)

[Bug fortran/78238] ICE: verify_gimple failed, with -fdefault-integer-8

[kargl at gcc dot gnu.org]

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

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 ---
Works for me on x86_64-*-freebsd.  What system are you using?
Also, what happens if you use -freal-4-real-8?

[Bug fortran/78226] Fill out location information everywhere

[tkoenig at gcc dot gnu.org]

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

--- Comment #5 from Thomas Koenig  ---
Author: tkoenig
Date: Mon Nov  7 19:33:27 2016
New Revision: 241927

URL: https://gcc.gnu.org/viewcvs?rev=241927=gcc=rev
Log:
2016-11-07  Thomas Koenig  

PR fortran/78226
* expr.c (gfc_generate_initializer):  Add where to EXPR_NULL
statement.
* iresolve.c (gfc_resolve_extends_type_of):  Add where to
both arguments of the function.
* resolve.c (resolve_select_type):  Add where to the
second argument of the new statement.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/expr.c
trunk/gcc/fortran/iresolve.c
trunk/gcc/fortran/resolve.c

[Bug driver/78206] bootstrap failure under Apple sandbox that blacklists reads in /usr/local

[mrs at gcc dot gnu.org]

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

--- Comment #6 from mrs at gcc dot gnu.org  ---
Author: mrs
Date: Mon Nov  7 19:17:04 2016
New Revision: 241926

URL: https://gcc.gnu.org/viewcvs?rev=241926=gcc=rev
Log:
2016-11-06  Jack Howarth  

PR driver/78206
* incpath.c: (remove_dup(): Also silently ignore EPERM.

Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/incpath.c

[Bug fortran/78240] ICE in match_clist_expr, at fortran/decl.c:728

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

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

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

For completeness, without -fdec :


$ gfortran-7-20161106 z1.f90
z1.f90:2:12:

structure /s/
1
Error: STRUCTURE at (1) is a DEC extension, enable with -fdec-structure
z1.f90:4:6:

end structure
  1
Error: Expecting END PROGRAM statement at (1)
z1.f90:3:16:

   integer x(n) /1/
1
Error: Variable 'n' cannot appear in the expression at (1)
z1.f90:3:18:

   integer x(n) /1/
  1
Error: The module or main program array 'x' at (1) must have constant shape

in gfc_format_decoder, at fortran/error.c:935
0x68b46e gfc_format_decoder
../../gcc/fortran/error.c:935
0x13f1eef pp_format(pretty_printer*, text_info*)
../../gcc/pretty-print.c:660
0x13e5310 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
../../gcc/diagnostic.c:947
0x68b307 gfc_error
../../gcc/fortran/error.c:1277
0x68c700 gfc_error(char const*, ...)
../../gcc/fortran/error.c:1306
0x6f152a check_data_variable
../../gcc/fortran/resolve.c:14939
0x6f152a traverse_data_var
../../gcc/fortran/resolve.c:15130
0x6fbc91 resolve_data
../../gcc/fortran/resolve.c:15185
0x6fbc91 resolve_types
../../gcc/fortran/resolve.c:15939
0x6f76ac gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:16027
0x6e1bba resolve_all_program_units
../../gcc/fortran/parse.c:5883
0x6e1bba gfc_parse_file()
../../gcc/fortran/parse.c:6130
0x725822 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:198

[Bug fortran/78240] New: ICE in match_clist_expr, at fortran/decl.c:728

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

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

Bug ID: 78240
   Summary: ICE in match_clist_expr, at fortran/decl.c:728
   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: ---

Invalid code with an uninitialized parameter n.
Affects version 6 and 7, needs option -fdec* :


$ cat z1.f90
program p
   structure /s/
  integer x(n) /1/
   end structure
end


$ gfortran-7-20161106 -fdec z1.f90
f951: internal compiler error: in match_clist_expr, at fortran/decl.c:728
0x682abe match_clist_expr
../../gcc/fortran/decl.c:728
0x682abe variable_decl
../../gcc/fortran/decl.c:2350
0x682abe gfc_match_data_decl()
../../gcc/fortran/decl.c:4891
0x6d7b89 match_word_omp_simd
../../gcc/fortran/parse.c:93
0x6daa9e match_word
../../gcc/fortran/parse.c:377
0x6daa9e decode_statement
../../gcc/fortran/parse.c:377
0x6dc8a4 next_free
../../gcc/fortran/parse.c:1149
0x6dc8a4 next_statement
../../gcc/fortran/parse.c:1382
0x6dd6ca parse_struct_map
../../gcc/fortran/parse.c:3071
0x6de3c1 parse_spec
../../gcc/fortran/parse.c:3691
0x6e05c3 parse_progunit
../../gcc/fortran/parse.c:5521
0x6e1b64 gfc_parse_file()
../../gcc/fortran/parse.c:6030
0x725822 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:198

[Bug driver/78206] bootstrap failure under Apple sandbox that blacklists reads in /usr/local

[mrs at gcc dot gnu.org]

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

--- Comment #5 from mrs at gcc dot gnu.org  ---
Author: mrs
Date: Mon Nov  7 18:35:50 2016
New Revision: 241920

URL: https://gcc.gnu.org/viewcvs?rev=241920=gcc=rev
Log:
2016-11-06  Jack Howarth  

PR driver/78206
* incpath.c: (remove_dup(): Also silently ignore EPERM.


Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/incpath.c

[Bug fortran/78239] ICE in char_len_param_value, at fortran/decl.c:926, with -fimplicit-none

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

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

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

An invalid example, with uninitialized parameter n :


$ cat z2.f90
program p
   character(*), parameter :: z(2) = [character(n) :: 'x', 'y']
end


$ gfortran-7-20161106 -fimplicit-none z2.f90
f951: internal compiler error: Segmentation fault
0xc3a64f crash_signal
../../gcc/toplev.c:338
0x6790df char_len_param_value
../../gcc/fortran/decl.c:926
0x67b1a4 gfc_match_char_spec(gfc_typespec*)
../../gcc/fortran/decl.c:2847
0x6badcd gfc_match_type_spec(gfc_typespec*)
../../gcc/fortran/match.c:2051
0x662e89 gfc_match_array_constructor(gfc_expr**)
../../gcc/fortran/array.c:1123
0x6bfc79 match_primary
../../gcc/fortran/matchexp.c:153
0x6bfc79 match_level_1
../../gcc/fortran/matchexp.c:211
0x6bfc79 match_mult_operand
../../gcc/fortran/matchexp.c:267
0x6bfed8 match_add_operand
../../gcc/fortran/matchexp.c:356
0x6c016c match_level_2
../../gcc/fortran/matchexp.c:480
0x6c02c2 match_level_3
../../gcc/fortran/matchexp.c:551
0x6c03d4 match_level_4
../../gcc/fortran/matchexp.c:599
0x6c03d4 match_and_operand
../../gcc/fortran/matchexp.c:693
0x6c0592 match_or_operand
../../gcc/fortran/matchexp.c:722
0x6c0682 match_equiv_operand
../../gcc/fortran/matchexp.c:765
0x6c0772 match_level_5
../../gcc/fortran/matchexp.c:811
0x6bfae1 gfc_match_expr(gfc_expr**)
../../gcc/fortran/matchexp.c:870
0x691292 gfc_match_init_expr(gfc_expr**)
../../gcc/fortran/expr.c:2702
0x682784 variable_decl
../../gcc/fortran/decl.c:2391
0x682784 gfc_match_data_decl()
../../gcc/fortran/decl.c:4891

[Bug driver/78206] bootstrap failure under Apple sandbox that blacklists reads in /usr/local

[mrs at gcc dot gnu.org]

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

--- Comment #4 from mrs at gcc dot gnu.org  ---
Author: mrs
Date: Mon Nov  7 18:33:49 2016
New Revision: 241919

URL: https://gcc.gnu.org/viewcvs?rev=241919=gcc=rev
Log:
2016-11-06  Jack Howarth  

PR driver/78206
* incpath.c: (remove_dup(): Also silently ignore EPERM.

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

[Bug fortran/78239] New: ICE in char_len_param_value, at fortran/decl.c:926, with -fimplicit-none

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

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

Bug ID: 78239
   Summary: ICE in char_len_param_value, at fortran/decl.c:926,
with -fimplicit-none
   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: ---

Some valid cases flag an ICE with option -fimplicit-none.
Affects version 5, 6 and 7.


$ cat z1.f90
subroutine s(n)
   character(n) :: c
   c = 'c'
end


$ gfortran-7-20161106 -fimplicit-none z1.f90
f951: internal compiler error: Segmentation fault
0xc3a64f crash_signal
../../gcc/toplev.c:338
0x6790df char_len_param_value
../../gcc/fortran/decl.c:926
0x67b1a4 gfc_match_char_spec(gfc_typespec*)
../../gcc/fortran/decl.c:2847
0x680419 gfc_match_decl_type_spec(gfc_typespec*, int)
../../gcc/fortran/decl.c:3055
0x681746 gfc_match_data_decl()
../../gcc/fortran/decl.c:4819
0x6d7b89 match_word_omp_simd
../../gcc/fortran/parse.c:93
0x6daa9e match_word
../../gcc/fortran/parse.c:377
0x6daa9e decode_statement
../../gcc/fortran/parse.c:377
0x6dc8a4 next_free
../../gcc/fortran/parse.c:1149
0x6dc8a4 next_statement
../../gcc/fortran/parse.c:1382
0x6de63c parse_spec
../../gcc/fortran/parse.c:3551
0x6e05c3 parse_progunit
../../gcc/fortran/parse.c:5521
0x6e1e74 gfc_parse_file()
../../gcc/fortran/parse.c:6037
0x725822 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:198

[Bug fortran/78238] New: ICE: verify_gimple failed, with -fdefault-integer-8

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

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

Bug ID: 78238
   Summary: ICE: verify_gimple failed, with -fdefault-integer-8
   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: ---

Valid code with explicitly no integer variable in source,
and in first test case with no 4-byte integer value.
ICE with option -fdefault-integer-8 or similar, seen with 7.


$ cat z1.f90
program p
   type t
  class(*), allocatable :: q(:)
   end type
   type(t) :: z
   real :: a(2_8) = [1.0, 2.0]
   allocate (z%q(2_8), source=a)
   call s
contains
   subroutine s
  select type (x => z%q)
  type is (real)
 if ( any(x/=a) ) call abort
  end select
   end
end


$ cat z2.f90
program p
   type t
  class(*), allocatable :: q(:)
   end type
   type(t) :: z
   real :: a(2) = [1.0, 2.0]
   allocate (z%q(2), source=a)
   call s
contains
   subroutine s
  select type (x => z%q)
  type is (real)
 if ( any(x/=a) ) call abort
  end select
   end
end


$ gfortran-7-20161106 -fdefault-integer-8 z1.f90
z1.f90:10:0:

subroutine s

Error: mismatching comparison operand types
integer(kind=4)
integer(kind=8)
if (_10 == 64409183) goto ; else goto ;
z1.f90:10:0: internal compiler error: verify_gimple failed
0xc745fd verify_gimple_in_seq(gimple*)
../../gcc/tree-cfg.c:4876
0x9dcbc2 gimplify_body(tree_node*, bool)
../../gcc/gimplify.c:12251
0x9dcf56 gimplify_function_tree(tree_node*)
../../gcc/gimplify.c:12339
0xcd1892 gimplify_all_functions
../../gcc/tree-nested.c:3280
0xcd1877 gimplify_all_functions
../../gcc/tree-nested.c:3282
0xcd9fd6 lower_nested_functions(tree_node*)
../../gcc/tree-nested.c:3299
0x84aa76 cgraph_node::analyze()
../../gcc/cgraphunit.c:632
0x84e073 analyze_functions
../../gcc/cgraphunit.c:1087
0x84ed88 symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2562

[Bug c++/72803] [7 Regression] ICE on invalid code in linemap_position_for_loc_and_offset, at libcpp/line-map.c:891

[aldyh at gcc dot gnu.org]

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

--- Comment #5 from Aldy Hernandez  ---
Confirmed with the attachment.  Thanks.

Let's leave this open for now, as the ICE occurs in a different place than
PR77949.  It could be another unrelated bug caused by the same patch.  Though
it seems like this is a better place to start, since the testcase is
considerable shorter.

[Bug sanitizer/77538] segmentation fault: thread sanitizer shadow stack overflow

[dvyukov at google dot com]

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

--- Comment #18 from Dmitry Vyukov  ---
Looks like shadow stack overflow.
Do you use fibers, ucontext, longjmp, exceptions or any other non-obvious
control flow constructs?
Fibers and exceptions are not supported. Longjmp should work.

[Bug target/77834] [7 Regression] ICE: in make_decl_rtl, at varasm.c:1311 with -O -ftree-pre -mstringop-strategy=libcall

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Author: jakub
Date: Mon Nov  7 17:35:16 2016
New Revision: 241917

URL: https://gcc.gnu.org/viewcvs?rev=241917=gcc=rev
Log:
PR target/77834
* dse.c (dse_step5): Call scan_reads even if just
insn_info->frame_read.  Improve and fix dump file messages.

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

[Bug target/78227] ICE: unrecognizable insn: in extract_insn, at recog.c:2311 with -mavx512bw and vector comare

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Mon Nov  7 17:33:27 2016
New Revision: 241916

URL: https://gcc.gnu.org/viewcvs?rev=241916=gcc=rev
Log:
PR target/78227
* config/i386/i386.c (ix86_expand_sse_cmp): Force dest into
cmp_mode argument even for -O0 if cmp_mode != mode and maskcmp.

* gcc.target/i386/pr78227-1.c: New test.
* gcc.target/i386/pr78227-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr78227-1.c
trunk/gcc/testsuite/gcc.target/i386/pr78227-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/35691] Missed (a == 0) && (b == 0) into (a|(typeof(a)(b)) == 0 when the types don't match

[prathamesh3492 at gcc dot gnu.org]

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

--- Comment #1 from prathamesh3492 at gcc dot gnu.org ---
Author: prathamesh3492
Date: Mon Nov  7 17:32:17 2016
New Revision: 241915

URL: https://gcc.gnu.org/viewcvs?rev=241915=gcc=rev
Log:
2016-11-07  Prathamesh Kulkarni  

PR middle-end/35691
* match.pd: Add following two patterns:
(x == 0 & y == 0) -> (x | typeof(x)(y)) == 0.
(x != 0 | y != 0) -> (x | typeof(x)(y)) != 0.

testsuite/
* gcc.dg/pr35691-1.c: New test-case.
* gcc.dg/pr35691-4.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/pr35691-1.c
trunk/gcc/testsuite/gcc.dg/pr35691-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/match.pd
trunk/gcc/testsuite/ChangeLog

[Bug c++/78235] [7 Regression] libstdc++ testsuite run.cc ICE in int_bit_position

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
Related to PR 66149.

[Bug c++/78235] [7 Regression] libstdc++ testsuite run.cc ICE in int_bit_position

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|middle-end  |c++
   Target Milestone|--- |7.0

--- Comment #3 from Andrew Pinski  ---
> expected field_decl, have template_decl in int_bit_position

template_decl should not have leaked to int_bit_position at all.

[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

Jiong Wang  changed:

   What|Removed |Added

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

--- Comment #5 from Jiong Wang  ---
This bug itself should have been fixed by

 https://gcc.gnu.org/viewcvs/gcc?view=revision=241913

[Bug libgcc/78064] unwind-c.c never uses _Unwind_GetIPInfo

[fw at gcc dot gnu.org]

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

--- Comment #5 from Florian Weimer  ---
Author: fw
Date: Mon Nov  7 17:08:40 2016
New Revision: 241914

URL: https://gcc.gnu.org/viewcvs?rev=241914=gcc=rev
Log:
PR libgcc/78064: Add missing include directive to unwind-c.c

Backport from mainline
2016-10-24  Florian Weimer  


PR libgcc/78064
* unwind-c.c: Include auto-target.h.


Modified:
branches/gcc-6-branch/   (props changed)
branches/gcc-6-branch/libgcc/ChangeLog
branches/gcc-6-branch/libgcc/unwind-c.c

Propchange: branches/gcc-6-branch/
('svn:mergeinfo' modified)

[Bug fortran/77596] [F03] procedure pointer with implicit interface in type pointing to a function can be 'called'

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |janus at gcc dot gnu.org
   Target Milestone|--- |7.0

--- Comment #3 from janus at gcc dot gnu.org ---
I have a patch to fix this ...

[Bug tree-optimization/77309] [5/6/7 Regression] wrong code at -Os and above on x86_64-linux-gnu (in the 64-bit mode)

[bernds at gcc dot gnu.org]

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

--- Comment #3 from Bernd Schmidt  ---
Author: bernds
Date: Mon Nov  7 16:59:11 2016
New Revision: 241912

URL: https://gcc.gnu.org/viewcvs?rev=241912=gcc=rev
Log:
PR rtl-optimization/77309
* combine.c (make_compound_operation): Allow EQ for IN_CODE, and
don't assume an equality comparison for plain COMPARE.
(simplify_comparison): Pass a more accurate code to
make_compound_operation.

testsuite/
PR rtl-optimization/77309
* gcc.dg/torture/pr77309.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr77309.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/combine.c
trunk/gcc/testsuite/ChangeLog

[Bug target/68467] libgcc, compilation for target m68k-linux breaks in linux_atomic.c

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-07
  Component|libgcc  |target
Summary|libgcc, compilation for |libgcc, compilation for
   |target m68k-linux breaks in |target m68k-linux breaks in
   |linux_atomic.c, #define |linux_atomic.c
   |COMMA , |
 Ever confirmed|0   |1

--- Comment #3 from Joseph S. Myers  ---
Confirmed.  Building libgcc for m68k-linux-gnu --with-arch=cf fails for every
GCC version from 4.7 onwards (4.6 didn't have linux-atomic.c, so I'm not sure
if this counts as a regression).

Errors with current mainline:

/scratch/jmyers/glibc/many7/src/gcc/libgcc/config/m68k/linux-atomic.c: In
function '__sync_bool_compare_and_swap_1':
/scratch/jmyers/glibc/many7/src/gcc/libgcc/config/m68k/linux-atomic.c:197:13:
internal compiler error: in emit_library_call_value_1, at calls.c:4624
 return (__sync_val_compare_and_swap_##WIDTH (ptr, oldval, newval) \
 ^
/scratch/jmyers/glibc/many7/src/gcc/libgcc/config/m68k/linux-atomic.c:202:1:
note: in expansion of macro 'SUBWORD_BOOL_CAS'
 SUBWORD_BOOL_CAS (unsigned char,  1)
 ^~~~
0x6a7dc7 emit_library_call_value_1
/scratch/jmyers/glibc/many7/src/gcc/gcc/calls.c:4623
0x6acb5f emit_library_call_value(rtx_def*, rtx_def*, libcall_type,
machine_mode, int, ...)
/scratch/jmyers/glibc/many7/src/gcc/gcc/calls.c:4817
0x9e576e expand_atomic_compare_and_swap(rtx_def**, rtx_def**, rtx_def*,
rtx_def*, rtx_def*, bool, memmodel, memmodel)
/scratch/jmyers/glibc/many7/src/gcc/gcc/optabs.c:6210
0x690b1b expand_builtin_compare_and_swap
/scratch/jmyers/glibc/many7/src/gcc/gcc/builtins.c:5059
0x69db77 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
/scratch/jmyers/glibc/many7/src/gcc/gcc/builtins.c:6606
0x7bdd4d expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/scratch/jmyers/glibc/many7/src/gcc/gcc/expr.c:10773
0x7c8e4f store_expr_with_bounds(tree_node*, rtx_def*, int, bool, bool,
tree_node*)
/scratch/jmyers/glibc/many7/src/gcc/gcc/expr.c:5548
0x7ca790 expand_assignment(tree_node*, tree_node*, bool)
/scratch/jmyers/glibc/many7/src/gcc/gcc/expr.c:5317
0x6bb4ba expand_call_stmt
/scratch/jmyers/glibc/many7/src/gcc/gcc/cfgexpand.c:2666
0x6bb4ba expand_gimple_stmt_1
/scratch/jmyers/glibc/many7/src/gcc/gcc/cfgexpand.c:3581
0x6bb4ba expand_gimple_stmt
/scratch/jmyers/glibc/many7/src/gcc/gcc/cfgexpand.c:3747
0x6bd28e expand_gimple_basic_block
/scratch/jmyers/glibc/many7/src/gcc/gcc/cfgexpand.c:5754
0x6c3176 execute
/scratch/jmyers/glibc/many7/src/gcc/gcc/cfgexpand.c:6368
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug middle-end/61118] Spurious -Wclobbered warning generated by gcc 4.9.0 for pthread_cleanup_push

[herve.codina at gmail dot com]

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

Hervé Codina  changed:

   What|Removed |Added

 CC||herve.codina at gmail dot com

--- Comment #5 from Hervé Codina  ---
Same problem using Tavian attached source file on gcc 4.9.3 and 5.2.0.

Note that the problem appears when optimization is turned on (flag -O1 or more)
Without optimization, no warning.

[Bug target/77822] [6 Regression] arm64 Error: immediate value out of range 0 to 63 at operand 3

[vogt at linux dot vnet.ibm.com]

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

--- Comment #25 from Dominik Vogt  ---
I see.

This test verifies that a negative "pos" is indeed rejected:
--
#include  
int g; 
void foo(int64_t b) 
{ 
  if (b >> 65 & 1) 
g = b; 
} 
--

[Bug libstdc++/78237] New: std::timed_mutex::try_lock_for/until affected by system realtime clock

[marejde at gmail dot com]

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

Bug ID: 78237
   Summary: std::timed_mutex::try_lock_for/until affected by
system realtime clock
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marejde at gmail dot com
  Target Milestone: ---

The following program:

#include 
#include 
#include 
#include 

int main(void)
{
std::recursive_timed_mutex mutex;

bool ret = mutex.try_lock_for(std::chrono::seconds(2));
std::cout << "ret = " << ret << "\n";

std::thread thread([]() {
std::this_thread::sleep_for(std::chrono::seconds(1));
auto now = std::chrono::steady_clock::now();
bool ret = mutex.try_lock_until(now +
std::chrono::seconds(60));
std::cout << "ret = " << ret << "\n";
});

thread.join();

return 0;
}

does not work as expected when modifying the system time. try_lock_until()
returns false immediately when time is advanced passed now + 60s.

Compiling with Clang and libc++ try_lock_until() waits for 60 seconds
regardless of what the system time is changed to.

Looking at the implementation in libstdc++ it looks like it ends up calling
pthread_mutex_timedwait() (that uses CLOCK_REALTIME) while the libc++
implementation implements the methods with a condition variable.

[Bug libstdc++/78236] regex_iterator constructor is incomplete and creates uninitialized values that may be used

[christophe.monat at st dot com]

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

--- Comment #1 from Christophe Monat  ---
Comment on attachment 39982
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39982
Proposed patch to fix the regex_iterator constructor

>diff --git a/libstdc++-v3/include/bits/regex.h 
>b/libstdc++-v3/include/bits/regex.h
>index a7d45e6..bb0a167 100644
>--- a/libstdc++-v3/include/bits/regex.h
>+++ b/libstdc++-v3/include/bits/regex.h
>@@ -2454,7 +2454,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
>* one-past-the-end of a range.
>*/
>   regex_iterator()
>-  : _M_match()
>+  : _M_pregex(), _M_flags(regex_constants::match_default), _M_match()
>   { }
> 
>   /**

[Bug libstdc++/78236] New: regex_iterator constructor is incomplete and creates uninitialized values that may be used

[christophe.monat at st dot com]

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

Bug ID: 78236
   Summary: regex_iterator constructor is incomplete and creates
uninitialized values that may be used
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: christophe.monat at st dot com
  Target Milestone: ---

Created attachment 39982
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39982=edit
Porposed patch to fix the regex_iterator constructor

The following code snippet, when compiled on X8664 with gcc-trunk, dumps core
with any optimization level (you might need to add -std=c++11 depending on your
compiler version).

#include 
#include 

int main(int argc, char *argv[])
{
  char const s[] = "afoo";
  std::basic_regex r("(f+)");
  {
std::cregex_iterator i(s, s+sizeof(s), r);
std::cregex_iterator j(s, s+sizeof(s), r);
assert(i == j);
  }
  // The iterator manipulation code must be repeated in the same scope
  // to expose the undefined read during the execution of the ==
  // operator (stack location reuse)
  {
std::cregex_iterator i(s, s+sizeof(s), r);
std::cregex_iterator j;
assert(!(i == j));
  }
  return 0;
}

This happens during the execution of the operator== that reads some of the
private implementation fields, some of which appear not to be initialized.

The issue is due to the fact that the regex_iterator
(libstdc++v3/include/bits/regex.h) has for instance a pointer member (const
regex_type* _M_pregex) and a user-defined constructor that fails to initialize
it

I have attached a trivial patch that initializes the two fields that are to be
explicitly initialized to avoid the reported issue.

[Bug target/77822] [6 Regression] arm64 Error: immediate value out of range 0 to 63 at operand 3

[ktkachov at gcc dot gnu.org]

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

--- Comment #24 from ktkachov at gcc dot gnu.org ---
(In reply to Dominik Vogt from comment #23)
> Regarding the ARM patch:
> 
> +  {
> +if (!IN_RANGE (INTVAL (operands[2]) + INTVAL (operands[3]),
> +1, GET_MODE_BITSIZE (DImode) - 1))
> + FAIL;
> +  }
> 
> Isn't this patch too simple?  On s390x we get "pos" -N (operand 3) with
> "size" M, so the correct check should be:
> 
>   if (! IN_RANGE (INTVAL (operands[3]), 0, GET_MODE_BITSIZE (DImode) - 1)
>   || IN_RANGE (INTVAL (operands[3]) + INTVAL (operands[2]),
>1, GET_MODE_BITSIZE (DImode)))
> FAIL;
> 
> It's just luck that the test program does not generate something like
> 
>   (zero_extract (...) (-1) (16))
> 
> Which can only be caught by testing "pos" individually.
> 
> --
> 
> Also, I don't understand why the valid range is "1, GET_MODE_BITSIZE
> (DImode) - 1", shouldn't it be "1, GET_MODE_BITSIZE (DImode)" without the "-
> 1"?

operands[3] also gets the aarch64_simd_shift_imm_di predicate which checks that
IN_RANGE (INTVAL (op), 0, 63), so we should be okay

[Bug target/77822] [6 Regression] arm64 Error: immediate value out of range 0 to 63 at operand 3

[vogt at linux dot vnet.ibm.com]

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

--- Comment #23 from Dominik Vogt  ---
Regarding the ARM patch:

+  {
+if (!IN_RANGE (INTVAL (operands[2]) + INTVAL (operands[3]),
+  1, GET_MODE_BITSIZE (DImode) - 1))
+ FAIL;
+  }

Isn't this patch too simple?  On s390x we get "pos" -N (operand 3) with "size"
M, so the correct check should be:

  if (! IN_RANGE (INTVAL (operands[3]), 0, GET_MODE_BITSIZE (DImode) - 1)
  || IN_RANGE (INTVAL (operands[3]) + INTVAL (operands[2]),
   1, GET_MODE_BITSIZE (DImode)))
FAIL;

It's just luck that the test program does not generate something like

  (zero_extract (...) (-1) (16))

Which can only be caught by testing "pos" individually.

--

Also, I don't understand why the valid range is "1, GET_MODE_BITSIZE (DImode) -
1", shouldn't it be "1, GET_MODE_BITSIZE (DImode)" without the "- 1"?

[Bug tree-optimization/72785] [7 Regression] kernel build error since r236831

[dhowells at redhat dot com]

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

--- Comment #17 from dhowells at redhat dot com  ---
(In reply to dhowe...@redhat.com from comment #16)
> ...
> 0027 :
>   27:   0f bd c7bsr%edi,%eax
>   2a:   83 f0 1fxor$0x1f,%eax
>   2d:   c3  retq   
> 
> though the XOR is superfluous - for any valid input to ilog2(), I think the
> output is always in the range 0-31.

Ah - it's not actually an AND, so the XOR isn't necessarily superfluous.

[Bug fortran/78226] Fill out location information everywhere

[tkoenig at gcc dot gnu.org]

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

--- Comment #4 from Thomas Koenig  ---
Here's the commit, the PR number was incorrect.

Author: tkoenig
Date: Mon Nov  7 15:25:21 2016
New Revision: 241909

URL: https://gcc.gnu.org/viewcvs?rev=241909=gcc=rev
Log:
2016-11-07  Thomas Koenig  

PR fortran/78226
* match.c (gfc_match_select_type):  Add where for expr1.
* resolve.c (resolev_select_type): Add where for expr1 of new
statement.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/match.c
trunk/gcc/fortran/resolve.c

[Bug tree-optimization/72785] [7 Regression] kernel build error since r236831

[dhowells at redhat dot com]

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

--- Comment #16 from dhowells at redhat dot com  ---
I guess the following could be used:

int clz_ilog2(unsigned long x)
{
return __builtin_clz(x);
}

which compiles to:

0027 :
  27:   0f bd c7bsr%edi,%eax
  2a:   83 f0 1fxor$0x1f,%eax
  2d:   c3  retq   

though the XOR is superfluous - for any valid input to ilog2(), I think the
output is always in the range 0-31.

[Bug sanitizer/77538] segmentation fault: thread sanitizer shadow stack overflow

[coollpe at hotmail dot com]

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

--- Comment #17 from peien luo  ---
(In reply to Dmitry Vyukov from comment #16)
> > The stack size limit in my box is 8M. I have also checked /proc/limits.
> 
> So, is increasing stack size help?
> Tsan increases stack consumption. 8MB is not that much provided that you
> have 1MB frames.
> 
> > By enabling -fstack-protector-all, in gdb it still may get segfault here 
> > (at function entry).
> 
> Stack protector will not help to detect/prevent stack overflow. It only
> prevents PC overwrite on buffer overflows.

Increased to 80MB, no help.

In a 4.9.0 tsan case, I have come across a segfault in gdb with back trace:
23  void MutexSet::Add(u64 id, bool write, u64 epoch) {
24// Look up existing mutex with the same id.
25for (uptr i = 0; i < size_; i++) {
26  if (descs_[i].id == id) {
27descs_[i].count++;
28descs_[i].epoch = epoch;
29return;
30  }

(gdb) p size_
$2 = 139907922088632

(gdb) bt
#0  0x7f3ed9c5f37c in __tsan::MutexSet::Add
(this=this@entry=0x7f3ec6f63080, id=55166398195828824, 
write=write@entry=true, epoch=1680548) at
../../../../libsanitizer/tsan/tsan_mutexset.cc:26
#1  0x7f3ed9c555e5 in __tsan::MutexLock (thr=thr@entry=0x7f3ec6e78840,
pc=pc@entry=139907918263873, 
addr=addr@entry=138040248895576) at
../../../../libsanitizer/tsan/tsan_rtl_mutex.cc:109
#2  0x7f3ed9c4f6ae in __interceptor_pthread_mutex_lock (m=0x7d8c0858)
at ../../../../libsanitizer/tsan/tsan_interceptors.cc:811
...

something overflowed?

[Bug tree-optimization/72785] [7 Regression] kernel build error since r236831

[dhowells at redhat dot com]

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

--- Comment #15 from dhowells at redhat dot com  ---
(In reply to Jakub Jelinek from comment #14)
> (In reply to dhowe...@redhat.com from comment #13)
> ...
> Ugh, no.  Why not just x && (x & -x) == x ? __builtin_ctz (x) : -1
> (or ctzl or ctzll depending on what the type is)?

Comparing the kernel's ilog2() to your suggestion:

int kernel_ilog2(unsigned long x)
{
return ilog2(x);
}

int jakub_ilog2(unsigned long x)
{
return x && (x & -x) == x ? __builtin_ctz (x) : -1;
}

compiled with -Os for x86_64 gives:

 :
   0:   83 c8 ffor $0x,%eax
   3:   48 0f bd c7 bsr%rdi,%rax
   7:   c3  retq   

0008 :
   8:   83 c8 ffor $0x,%eax
   b:   48 85 fftest   %rdi,%rdi
   e:   74 17   je 27 
  10:   48 89 famov%rdi,%rdx
  13:   0f bc c7bsf%edi,%eax
  16:   48 f7 daneg%rdx
  19:   48 21 faand%rdi,%rdx
  1c:   48 39 d7cmp%rdx,%rdi
  1f:   ba ff ff ff ff  mov$0x,%edx
  24:   0f 45 c2cmovne %edx,%eax
  27:   c3  retq   

Note that in the kernel variant, the initial OR instruction is superfluous, but
is required by fls() and fls64() which x86_64 is using behind the scenes.  Not
all arches, however, use fls() and fls64() to implement ilog2().

[Bug fortran/71860] [5/6/7 Regression] [OOP] ICE on pointing to null(mold), verify_gimple failed

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||janus at gcc dot gnu.org
Summary|[5/6/7 Regression] ICE on   |[5/6/7 Regression] [OOP]
   |pointing to null(mold), |ICE on pointing to
   |verify_gimple failed|null(mold), verify_gimple
   ||failed

--- Comment #3 from janus at gcc dot gnu.org ---
Is this example invalid? If yes, why?

[Bug libstdc++/78235] [7 Regression] libstdc++ testsuite run.cc ICE in int_bit_position

[dje at gcc dot gnu.org]

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

--- Comment #2 from David Edelsohn  ---
20_util/variant/compile.cc produces a similar error:

In file included from
/nasfarm/edelsohn/src/src/libstdc++-v3/testsuite/20_util/variant/compile.cc:21:
/tmp/GCC/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/variant: In instantiation
of 'class std::variant >':
/tmp/GCC/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/type_traits:881:  
required by substitution of 'template static std::true_type
std::__do_is_default_constructible_impl::__test(int) [with _Tp =
std::variant >;  = ]'
/tmp/GCC/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/type_traits:892:  
required from 'struct std::__is_default_constructible_impl
> >'
/tmp/GCC/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/type_traits:143:  
required from 'struct std::__and_
> > >, std::__is_default_constructible_impl
> > >'
/tmp/GCC/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/type_traits:896:  
required from 'struct std::__is_default_constructible_atom
> >'
/tmp/GCC/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/type_traits:917:  
required from 'struct std::__is_default_constructible_safe
>, false>'
/tmp/GCC/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/type_traits:923:  
required from 'struct std::is_default_constructible
> >'
/tmp/GCC/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/type_traits:2966:  
required from 'constexpr const bool
std::is_default_constructible_v
> >'
/nasfarm/edelsohn/src/src/libstdc++-v3/testsuite/20_util/variant/compile.cc:56:
required from here
/tmp/GCC/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/variant:956: internal
compiler error: tree check: expected field_decl, have template_decl in
int_bit_position, at tree.h:5396

[Bug fortran/71723] [5/6/7 Regression] [F08] ICE on invalid pointer initialization

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||accepts-invalid
 CC||janus at gcc dot gnu.org
Summary|[5/6/7 Regression] ICE with |[5/6/7 Regression] [F08]
   |attempted pointer   |ICE on invalid pointer
   |initialization  |initialization

--- Comment #3 from janus at gcc dot gnu.org ---
(In reply to Walter Spector from comment #0)
> The example is not legal.  Nonetheless, the compiler should not ICE.

Could you explain why exactly the example is illegal? I guess because 'data'
lacks the TARGET attribute?

When removing the POINTER attribute on 'data', the example is correctly
rejected. So possibly the problem is that 'data%i' is believed to have the
POINTER attribute, because 'data' itself is a pointer.

[Bug tree-optimization/46006] vectorization outside of loops

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
So currently we indeed miss the "sinks":

t.i:29:6: note: === vect_analyze_data_ref_accesses ===
t.i:29:6: note: Detected interleaving load MEM[(struct B *)] and MEM[(struct
B *) + 8B]
t.i:29:6: note: Detected interleaving load MEM[(struct B *)] and MEM[(struct
B *) + 16B]
t.i:29:6: note: Detected interleaving load MEM[(struct B *)] and MEM[(struct
B *) + 24B]
t.i:29:6: note: Detected interleaving load MEM[(struct B *)] and MEM[(struct
B *) + 32B]
t.i:29:6: note: Detected interleaving load MEM[(struct B *)] and MEM[(struct
B *) + 40B]
t.i:29:6: note: Detected interleaving load u_43(D)->c.x and u_43(D)->c.y
t.i:29:6: note: Detected interleaving load u_43(D)->c.x and u_43(D)->c.z
t.i:29:6: note: Detected interleaving load u_43(D)->c.x and u_43(D)->d
t.i:29:6: note: Detected interleaving load of size 6 starting with v$a$x_48 =
MEM[(struct B *)];
t.i:29:6: note: Detected interleaving load of size 4 starting with _5 =
u_43(D)->c.x;
t.i:29:6: note: not vectorized: no grouped stores in basic block.

two classes of sinks are currently missing: reductions and vector CONSTRUCTORs

parts of the testcase might be handled with reduction support.

[Bug libstdc++/78235] [7 Regression] libstdc++ testsuite run.cc ICE in int_bit_position

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-07
 Ever confirmed|0   |1

--- Comment #1 from David Edelsohn  ---
New.

[Bug libstdc++/78235] New: [7 Regression] libstdc++ testsuite run.cc ICE in int_bit_position

[dje at gcc dot gnu.org]

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

Bug ID: 78235
   Summary: [7 Regression] libstdc++ testsuite run.cc ICE in
int_bit_position
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc-ibm-aix*

Created attachment 39981
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39981=edit
preprocessed source from 20_util/variant/run.cc

In file included from
/nasfarm/edelsohn/src/src/libstdc++-v3/testsuite/20_util/variant/run.cc:21:
/tmp/GCC/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/variant: In instantiation
of 'class std::variant >':
/nasfarm/edelsohn/src/src/libstdc++-v3/testsuite/20_util/variant/run.cc:54:  
required from here
/tmp/GCC/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/variant:956: internal
compiler error: tree check: expected field_decl, have template_decl in
int_bit_position, at tree.h:5396

[Bug tree-optimization/72785] [7 Regression] kernel build error since r236831

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  ---
(In reply to dhowe...@redhat.com from comment #13)
> Another possibility, at least for handling ilog2(), could be to provide
> __builtin_ilog2(unsigned long x) as an alternative.
> 
> Note that the kernel ilog2() has the property that the result is undefined
> if x==0 (and will jump to ilog2_NaN() if x is constant 0).

Ugh, no.  Why not just x && (x & -x) == x ? __builtin_ctz (x) : -1
(or ctzl or ctzll depending on what the type is)?

[Bug tree-optimization/72785] [7 Regression] kernel build error since r236831

[dhowells at redhat dot com]

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

dhowells at redhat dot com  changed:

   What|Removed |Added

 CC||dhowells at redhat dot com

--- Comment #13 from dhowells at redhat dot com  ---
Another possibility, at least for handling ilog2(), could be to provide
__builtin_ilog2(unsigned long x) as an alternative.

Note that the kernel ilog2() has the property that the result is undefined if
x==0 (and will jump to ilog2_NaN() if x is constant 0).

[Bug target/77822] [6 Regression] arm64 Error: immediate value out of range 0 to 63 at operand 3

[vogt at linux dot vnet.ibm.com]

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

Dominik Vogt  changed:

   What|Removed |Added

 CC||vogt at linux dot vnet.ibm.com

--- Comment #22 from Dominik Vogt  ---
Does that mean that every pattern that uses zero_extract or sign_extract needs
to check itself that 0 <= size+pos < GET_MODE_BITS (mode)?

[Bug tree-optimization/78234] [7 Regression] LLVM reports dynamic-stack-buffer-overflow in gimple-ssa-store-merging.c

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-11-07
   Assignee|unassigned at gcc dot gnu.org  |ktkachov at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from ktkachov at gcc dot gnu.org ---
I think I saw this independently while writing some unit tests.
I'm already testing a patch.

[Bug tree-optimization/78224] [5/6/7 Regression] g++ ICE at -O2(-O1 on gcc6) and above in verify_loop_structure, at cfgloop.c:1646

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
On the branch this is call-cdce, probably on trunk as well.  It wrecks loop
info
when the call is in the loop latch and we have an EH loop exit in this case:

  /* Now find the join target bb -- split bi_call_bb if needed.  */
  if (stmt_ends_bb_p (bi_call))
{
  /* We checked that there was a fallthrough edge in
 can_guard_call_p.  */
  join_tgt_in_edge_from_call = find_fallthru_edge (bi_call_bb->succs);
  gcc_assert (join_tgt_in_edge_from_call);
  free_dominance_info (CDI_DOMINATORS);
}

if we split the edge everything is fine.  Otherwise the pass needs to handle
PHIs in join_tgt_in_edge_from_call->dest.  So we can conditionally split
only.

Index: gcc/tree-call-cdce.c
===
--- gcc/tree-call-cdce.c(revision 241902)
+++ gcc/tree-call-cdce.c(working copy)
@@ -800,15 +800,21 @@ shrink_wrap_one_built_in_call_with_conds
   join_tgt_in_edge_from_call = find_fallthru_edge (bi_call_bb->succs);
   if (join_tgt_in_edge_from_call == NULL)
 return false;
+  /* We don't want to handle PHIs.  */
+  if (EDGE_COUNT (join_tgt_in_edge_from_call->dest->preds) > 1)
+   join_tgt_bb = split_edge (join_tgt_in_edge_from_call);
+  else
+   join_tgt_bb = join_tgt_in_edge_from_call->dest;
   free_dominance_info (CDI_DOMINATORS);
 }
   else
-join_tgt_in_edge_from_call = split_block (bi_call_bb, bi_call);
+{
+  join_tgt_in_edge_from_call = split_block (bi_call_bb, bi_call);
+  join_tgt_bb = join_tgt_in_edge_from_call->dest;
+}

   bi_call_bsi = gsi_for_stmt (bi_call);

-  join_tgt_bb = join_tgt_in_edge_from_call->dest;
-
   /* Now it is time to insert the first conditional expression
  into bi_call_bb and split this bb so that bi_call is
  shrink-wrapped.  */


similar patch works on trunk.

[Bug fortran/78221] [6/7 Regression] bogus warning: Non-zero imaginary part discarded in conversion [-Wconversion]

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #11 from Thomas Koenig  ---
Fixed on all affected branches, closing.

[Bug middle-end/78233] compute_idf fails quick_push size check when compiling libgcc for Debian armel with qemu-arm-static

[suokkos at gmail dot com]

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

--- Comment #1 from Pauli  ---
Sorry. Error in original report:
gcc (Debian 6.2.0-11) 6.2.0 20161103

with command:
gcc -isystem /usr/local/armv7l-unknown-linux-gnueabi/include -isystem
/usr/local/armv7l-unknown-linux-gnueabi/sys-include-g -O2 -O2  -g -O2
-DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem
./include   -fPIC -fno-inline -g -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-protector   -fPIC -fno-inline -I. -I. -I../.././gcc
-I../../../libgcc -I../../../libgcc/. -I../../../libgcc/../gcc
-I../../../libgcc/../include-o _muldi3.o -MT _muldi3.o -MD -MP -MF
_muldi3.dep -DL_muldi3 -c ../../../libgcc/libgcc2.c -fvisibility=hidden
-DHIDE_EXPORTS

works fine. I forgot that actual compile job is separate process when testing
system gcc.

On amd64 host:
/home/coren/project/gcc/buildamd64/./gcc/xgcc
-B/home/coren/project/gcc/buildamd64/./gcc/ -isystem
/usr/local/armv7l-unknown-linux-gnueabi/include -isystem
/usr/local/armv7l-unknown-linux-gnueabi/sys-include-g -O2 -O2  -g -O2
-DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem
./include   -fPIC -fno-inline -g -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-protector   -fPIC -fno-inline -I. -I. -I../.././gcc
-I../../../libgcc -I../../../libgcc/. -I../../../libgcc/../gcc
-I../../../libgcc/../include-o _muldi3.o -MT _muldi3.o -MD -MP -MF
_muldi3.dep -DL_muldi3 -c
/home/coren/project/gcc/buildarmel/armv7l-unknown-linux-gnueabi/libgcc/libgcc2.i
-fvisibility=hidden -DHIDE_EXPORTS

works fine.


Too bad compile cycle for armel is very long (about 30 hours) making it very
annoying that cc1 doesn't have debug symbols.

[Bug tree-optimization/78234] New: [7 Regression] LLVM reports dynamic-stack-buffer-overflow in gimple-ssa-store-merging.c

[trippels at gcc dot gnu.org]

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

Bug ID: 78234
   Summary: [7 Regression] LLVM reports
dynamic-stack-buffer-overflow in
gimple-ssa-store-merging.c
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
CC: ktkachov at gcc dot gnu.org
  Target Milestone: ---

with CXX="clang++ -fsanitize=address -fsanitize-address-use-after-scope"
../gcc/configure ...

I get:

markus@x4 libgcc % LSAN_OPTIONS="detect_leaks=0"
/var/tmp/gcc_build_dir_/./gcc/xgcc -B/var/tmp/gcc_build_dir_/./gcc/
-B/usr/local/x86_64-pc-linux-gnu/bin/ -B/usr/local/x86_64-pc-linux-gnu/lib/
-isystem /usr/local/x86_64-pc-linux-gnu/include -isystem
/usr/local/x86_64-pc-linux-gnu/sys-include-g -O2 -O2  -g -O2 -DIN_GCC-W
-Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition  -isystem ./include   -fpic
-mlong-double-80 -DUSE_ELF_SYMVER -g -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-protector   -fpic -mlong-double-80 -DUSE_ELF_SYMVER -I. -I.
-I../.././gcc -I../../../gcc/libgcc -I../../../gcc/libgcc/.
-I../../../gcc/libgcc/../gcc -I../../../gcc/libgcc/../include
-I../../../gcc/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS 
-DUSE_TLS -Wno-missing-prototypes -Wno-type-limits -o trunctfxf2.o -MT
trunctfxf2.o
-MD -MP -MF trunctfxf2.dep  -c ../../../gcc/libgcc/soft-fp/trunctfxf2.c
-fvisibility=hidden -DHIDE_EXPORTS
=
==4958==ERROR: AddressSanitizer: dynamic-stack-buffer-overflow on address
0x7fff682b1f03 at pc 0x02f8cb35 bp 0x7fff682b1eb0 sp 0x7fff682b1ea8
READ of size 1 at 0x7fff682b1f03 thread T0
#0 0x2f8cb34 in (anonymous namespace)::clear_bit_region(unsigned char*,
unsigned int, unsigned int)
/var/tmp/gcc_build_dir_/gcc/../../gcc/gcc/gimple-ssa-store-merging.c:332:14
#1 0x2f8bf63 in (anonymous namespace)::encode_tree_to_bitpos(tree_node*,
unsigned char*, int, int, unsigned int)
/var/tmp/gcc_build_dir_/gcc/../../gcc/gcc/gimple-ssa-store-merging.c:449:6
#2 0x2f8b4c6 in (anonymous namespace)::merged_store_group::apply_stores()
/var/tmp/gcc_build_dir_/gcc/../../gcc/gcc/gimple-ssa-store-merging.c:657:18
#3 0x2f8787f in (anonymous
namespace)::imm_store_chain_info::coalesce_immediate_stores()
/var/tmp/gcc_build_dir_/gcc/../../gcc/gcc/gimple-ssa-store-merging.c:925:24
#4 0x2f8787f in (anonymous
namespace)::imm_store_chain_info::terminate_and_process_chain()
/var/tmp/gcc_build_dir_/gcc/../../gcc/gcc/gimple-ssa-store-merging.c:1260
#5 0x2f8787f in (anonymous
namespace)::pass_store_merging::terminate_and_release_chain((anonymous
namespace)::imm_store_chain_info*)
/var/tmp/gcc_build_dir_/gcc/../../gcc/gcc/gimple-ssa-store-merging.c:844
#6 0x2f8a72e in (anonymous
namespace)::pass_store_merging::terminate_all_aliasing_chains((anonymous
namespace)::imm_store_chain_info**, bool, gimple*)
/var/tmp/gcc_build_dir_/gcc/../../gcc/gcc/gimple-ssa-store-merging.c:829:4
#7 0x2f85e1f in (anonymous
namespace)::pass_store_merging::execute(function*)
/var/tmp/gcc_build_dir_/gcc/../../gcc/gcc/gimple-ssa-store-merging.c:1488:4
#8 0x1630b4a in execute_one_pass(opt_pass*)
/var/tmp/gcc_build_dir_/gcc/../../gcc/gcc/passes.c:2341:22
#9 0x1632baa in execute_pass_list_1(opt_pass*)
/var/tmp/gcc_build_dir_/gcc/../../gcc/gcc/passes.c:2430:11
#10 0x1632bcf in execute_pass_list_1(opt_pass*)
/var/tmp/gcc_build_dir_/gcc/../../gcc/gcc/passes.c:2431:9
#11 0x1601146 in execute_pass_list(function*, opt_pass*)
/var/tmp/gcc_build_dir_/gcc/../../gcc/gcc/passes.c:2441:3
#12 0xb7ffbb in cgraph_node::expand()
/var/tmp/gcc_build_dir_/gcc/../../gcc/gcc/cgraphunit.c:2001:3
#13 0xb8a28a in expand_all_functions()
/var/tmp/gcc_build_dir_/gcc/../../gcc/gcc/cgraphunit.c:2137:10
#14 0xb8a28a in symbol_table::compile()
/var/tmp/gcc_build_dir_/gcc/../../gcc/gcc/cgraphunit.c:2494
#15 0xb8bf50 in symbol_table::finalize_compilation_unit()
/var/tmp/gcc_build_dir_/gcc/../../gcc/gcc/cgraphunit.c:2584:3
#16 0x18bc495 in compile_file()
/var/tmp/gcc_build_dir_/gcc/../../gcc/gcc/toplev.c:493:15
#17 0x18ba33e in do_compile()
/var/tmp/gcc_build_dir_/gcc/../../gcc/gcc/toplev.c:2012:11
#18 0x18ba33e in toplev::main(int, char**)
/var/tmp/gcc_build_dir_/gcc/../../gcc/gcc/toplev.c:2146
#19 0x327a648 in main
/var/tmp/gcc_build_dir_/gcc/../../gcc/gcc/main.c:39:17
#20 0x7f4f7fb932f0 in __libc_start_main
/home/markus/glibc/csu/../csu/libc-start.c:286
#21 0x588e69 in _start /home/markus/glibc/csu/../sysdeps/x86_64/start.S:120

Address 0x7fff682b1f03 is located in stack of thread T0
SUMMARY: AddressSanitizer: dynamic-stack-buffer-overflow

[Bug fortran/78221] [6/7 Regression] bogus warning: Non-zero imaginary part discarded in conversion [-Wconversion]

[tkoenig at gcc dot gnu.org]

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

--- Comment #10 from Thomas Koenig  ---
Author: tkoenig
Date: Mon Nov  7 13:46:31 2016
New Revision: 241906

URL: https://gcc.gnu.org/viewcvs?rev=241906=gcc=rev
Log:
2016-11-07  Thomas Koenig  

Backport from trunk
PR fortran/78221
* arith.c (gfc_complex2real):  Change gfc_warning_now to
gfc_warning.

2016-11-07  Thomas Koenig  

Backport from trunk
PR fortran/78221
* gfortran.dg/warn_conversion_9.f90:  New test.


Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/warn_conversion_9.f90
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/arith.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog