[Bug target/81753] Building of cross-compiler for powerpc-darwin7 is broken

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-08-08
 Ever confirmed|0   |1

--- Comment #4 from Martin Liška  ---
(In reply to Segher Boessenkool from comment #3)
> rs6000-p8swap.o as well :-)

I can confirm it works ;) Should I send the patch and install it?

[Bug target/81753] Building of cross-compiler for powerpc-darwin7 is broken

[segher at gcc dot gnu.org]

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

--- Comment #3 from Segher Boessenkool  ---
rs6000-p8swap.o as well :-)

[Bug tree-optimization/81723] [7/8 Regression] fortran build doesn't terminate on 64bit targets

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

   Target Milestone|--- |7.2

[Bug target/81753] Building of cross-compiler for powerpc-darwin7 is broken

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Apparently it's not enough:

g++ -no-pie   -O0 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE   -fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common 
-DHAVE_CONFIG_H -static-libstdc++ -static-libgcc  -o cc1 c/c-lang.o
c-family/stub-objc.o attribs.o c/c-errors.o c/c-decl.o c/c-typeck.o
c/c-convert.o c/c-aux-info.o c/c-objc-common.o c/c-parser.o
c/c-array-notation.o c/c-fold.o c/gimple-parser.o c-family/c-common.o
c-family/c-cppbuiltin.o c-family/c-dump.o c-family/c-format.o
c-family/c-gimplify.o c-family/c-indentation.o c-family/c-lex.o
c-family/c-omp.o c-family/c-opts.o c-family/c-pch.o c-family/c-ppoutput.o
c-family/c-pragma.o c-family/c-pretty-print.o c-family/c-semantics.o
c-family/c-ada-spec.o c-family/c-cilkplus.o c-family/array-notation-common.o
c-family/cilk.o c-family/c-ubsan.o c-family/c-attribs.o c-family/c-warn.o
darwin-c.o rs6000-c.o \
  cc1-checksum.o libbackend.a main.o libcommon-target.a libcommon.a
../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a
../libcpp/libcpp.a   ../libbacktrace/.libs/libbacktrace.a
../libiberty/libiberty.a ../libdecnumber/libdecnumber.a  -lisl -lmpc -lmpfr
-lgmp -rdynamic -ldl  -L./../zlib -lz
g++ -no-pie   -O0 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE   -fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common 
-DHAVE_CONFIG_H -static-libstdc++ -static-libgcc  -o cc1plus \
  cp/cp-lang.o c-family/stub-objc.o cp/call.o cp/class.o cp/constexpr.o
cp/constraint.o cp/cp-array-notation.o cp/cp-cilkplus.o cp/cp-gimplify.o
cp/cp-objcp-common.o cp/cp-ubsan.o cp/cvt.o cp/cxx-pretty-print.o cp/decl.o
cp/decl2.o cp/dump.o cp/error.o cp/except.o cp/expr.o cp/friend.o cp/init.o
cp/lambda.o cp/lex.o cp/logic.o cp/mangle.o cp/method.o cp/name-lookup.o
cp/optimize.o cp/parser.o cp/pt.o cp/ptree.o cp/repo.o cp/rtti.o cp/search.o
cp/semantics.o cp/tree.o cp/typeck.o cp/typeck2.o cp/vtable-class-hierarchy.o
attribs.o incpath.o c-family/c-common.o c-family/c-cppbuiltin.o
c-family/c-dump.o c-family/c-format.o c-family/c-gimplify.o
c-family/c-indentation.o c-family/c-lex.o c-family/c-omp.o c-family/c-opts.o
c-family/c-pch.o c-family/c-ppoutput.o c-family/c-pragma.o
c-family/c-pretty-print.o c-family/c-semantics.o c-family/c-ada-spec.o
c-family/c-cilkplus.o c-family/array-notation-common.o c-family/cilk.o
c-family/c-ubsan.o c-family/c-attribs.o c-family/c-warn.o darwin-c.o rs6000-c.o
cc1plus-checksum.o libbackend.a main.o libcommon-target.a libcommon.a
../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a
../libcpp/libcpp.a   ../libbacktrace/.libs/libbacktrace.a
../libiberty/libiberty.a ../libdecnumber/libdecnumber.a  -lisl -lmpc -lmpfr
-lgmp -rdynamic -ldl  -L./../zlib -lz
passes.o: In function `gcc::pass_manager::pass_manager(gcc::context*)':
passes.c:(.text+0xd709): undefined reference to
`make_pass_analyze_swaps(gcc::context*)'
collect2: error: ld returned 1 exit status
make[1]: *** [../../gcc/c/Make-lang.in:85: cc1] Error 1
passes.o: In function `gcc::pass_manager::pass_manager(gcc::context*)':
passes.c:(.text+0xd709): undefined reference to
`make_pass_analyze_swaps(gcc::context*)'
collect2: error: ld returned 1 exit status

[Bug c++/81764] New: Visibility for explicitly instantiated template class get warned if it was implicitly instantiated

[lanxingcan at gmail dot com]

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

Bug ID: 81764
   Summary: Visibility for explicitly instantiated template class
get warned if it was implicitly instantiated
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lanxingcan at gmail dot com
  Target Milestone: ---

```cpp

template class g;

template
class __attribute((visibility("default"))) g
{
g() = default;

static int f(int x)
{
return g<>::yyy::u(x); // g<> instantiated here
}


struct yyy
{
static int u(int x){
return x+ sizeof...(T);
}
};
};

extern template class __attribute((visibility("default"))) g<>; 
template class  g<>;
```

g++ says: extern-template.cc:23:60: warning: type attributes ignored after type
is already defined [-Wattributes]
 extern template class __attribute((visibility("default"))) g<>;

Is this behaviour intended?

[Bug target/81763] Issues with 32bit x86 apps on GCC 7.1+

[mike at fireburn dot co.uk]

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

--- Comment #2 from Mike Lothian  ---
Sorry I should have been more clear, this is LLVM trunk

I'm using these flags: 

CFLAGS="-O2 -march=native -pipe"
CXXFLAGS="-O2 -march=native -pipe"
LDFLAGS="-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed"

gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/7.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-7.1.0-r1/work/gcc-7.1.0/configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/7.1.0
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.0/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/7.1.0
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/7.1.0/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/7.1.0/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.0/include/g++-v7
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/7.1.0/python
--enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--enable-checking=release --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion='Gentoo 7.1.0-r1 p1.1' --disable-esp --enable-libstdcxx-time
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64
--disable-altivec --disable-fixed-point --enable-targets=all --disable-libgcj
--enable-libgomp --disable-libmudflap --disable-libssp --disable-libcilkrts
--enable-libmpx --enable-vtable-verify --enable-libvtv --enable-lto --with-isl
--disable-isl-version-check --enable-libsanitizer --disable-default-pie
--disable-default-ssp
Thread model: posix
gcc version 7.1.0 (Gentoo 7.1.0-r1 p1.1)

[Bug target/81763] Issues with 32bit x86 apps on GCC 7.1+

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
There are some known issues with older versions of LLVM, maybe you are using
too older version of LLVM.  That is some versions of LLVM have undefined C++
code in them.  GCC 7.1 is more aggressive of optimizing things.

[Bug c/81763] New: Issues with 32bit x86 apps on GCC 7.1+

[mike at fireburn dot co.uk]

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

Bug ID: 81763
   Summary: Issues with 32bit x86 apps on GCC 7.1+
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mike at fireburn dot co.uk
  Target Milestone: ---

I've been seeing issues with 32bit x86 llvm & mesa when using GCC 7.1.0 and
I've just tested GCC 7.2 RC

When llvm & mesa are compiled with GCC 7.1.0+ and I run a 32bit glxgears it
segfaults, the 64bit version work fine and if I recompile with GCC 6.3.0
everything works fine too (games also segfault but glxgears is a nice cut down
example)

This is only with the radeonsi driver, i965 works fine

https://bugs.freedesktop.org/show_bug.cgi?id=101881

It would be nice to rule out a GCC issue before 7.2.0 is released, the last
time I tried turning on debugging the issue no longer manifested.

Is there anything you can think of that might help pinpoint the bug?

[Bug target/81593] Optimize PowerPC vector set from vector extract

[meissner at gcc dot gnu.org]

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

--- Comment #2 from Michael Meissner  ---
Author: meissner
Date: Mon Aug  7 23:51:27 2017
New Revision: 250936

URL: https://gcc.gnu.org/viewcvs?rev=250936=gcc=rev
Log:
[gcc]
2017-08-07  Michael Meissner  

PR target/81593
* config/rs6000/vsx.md (vsx_concat_, VSX_D): Cleanup
constraints since the -mupper-regs-* switches have been
eliminated.
(vsx_concat__1): New combiner insns to recognize inserting
into a vector from a double word element that was extracted from
another vector, and eliminate extra XXPERMDI instructions.
(vsx_concat__2): Likewise.
(vsx_concat__3): Likewise.
(vsx_set_, VSX_D): Rewrite vector set in terms of vector
concat to allow optimizing inserts from previous extracts.

[gcc/testsuite]
2017-08-07  Michael Meissner  

PR target/81593
* gcc.target/powerpc/vec-setup.h: New tests to test various
combinations of setting up vectors of 2 double word elements.
* gcc.target/powerpc/vec-setup-long.c: Likewise.
* gcc.target/powerpc/vec-setup-double.c: Likewise.
* gcc.target/powerpc/vec-setup-be-long.c: Likewise.
* gcc.target/powerpc/vec-setup-be-double.c: Likewise.
* gcc.target/powerpc/vsx-extract-6.c: New tests for optimzing
vector inserts from vector extracts.
* gcc.target/powerpc/vsx-extract-7.c: Likewise.


Added:
trunk/gcc/testsuite/gcc.target/powerpc/vec-setup-be-double.c
trunk/gcc/testsuite/gcc.target/powerpc/vec-setup-be-long.c
trunk/gcc/testsuite/gcc.target/powerpc/vec-setup-double.c
trunk/gcc/testsuite/gcc.target/powerpc/vec-setup-long.c
trunk/gcc/testsuite/gcc.target/powerpc/vec-setup.h
trunk/gcc/testsuite/gcc.target/powerpc/vsx-extract-6.c
trunk/gcc/testsuite/gcc.target/powerpc/vsx-extract-7.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/vsx.md
trunk/gcc/testsuite/ChangeLog

[Bug c++/81668] LTO ODR warnings are not helpful

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #6 from Manuel López-Ibáñez  ---
> fts0pars.y:62:0: note: a field with different name is defined in another
> translation unit

Did you cut the above? It looks like a note without a previous warning. Also,
GCC will have trouble to point out the correct location when compiling a
generated file that contains linemarkers, unless the linemarkers exactly point
out to the original file AND the original file is available to read.

> ../include/violite.h:288:8: warning: type ‘struct st_vio’ violates the C++
> One Definition Rule [-Wodr]
>  struct st_vio
> ^
> ../include/violite.h:288:0: note: a different type is defined in another
> translation unit
>  struct st_vio
> 

This seems a problem with location info that fails to point to the .c file
affected. One should never get column 0.

[Bug fortran/52387] I/O output of write after nonadvancing read

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|REOPENED|ASSIGNED

--- Comment #14 from Eric Gallager  ---
(In reply to Jerry DeLisle from comment #13)
> (In reply to Eric Gallager from comment #12)
> > (In reply to Dominique d'Humieres from comment #11)
> > > > Tobias, any further information on this one?
> > > 
> > > Any news after more than one year?
> > 
> > Guess not, closing for being stuck in WAITING for so long
> 
> Although we have had no feedback from Standards people, I was actually
> starting to look at this a few days ago.  The issue is one of squeezing my
> personal time to work on these things. I do think we should unless I
> discover a major pain to do it.

OK, changing to ASSIGNED then since you're already the assignee for it.

[Bug lto/41565] -m32 causes an ICE when the object files were compiled with 64bit

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Last reconfirmed|2009-10-04 09:54:07 |2017-8-7

--- Comment #13 from Eric Gallager  ---
(In reply to Eric Gallager from comment #12)
> (In reply to Andrew Pinski from comment #11)
> > Simple testcase for powerpc64.
> > int main(void){ return 0; }
> > --- CUT --
> > gcc  t.c -flto -c -m64 
> > /home/apinski/gcc-mainline/libexec/gcc/powerpc64-unknown-linux-gnu/4.5.0/
> > lto1 t.o  -m32
> > 
> > --- CUT ---
> > I have not tried after the patch though.
> 
> Confirmed, happens on i386-apple-darwin9.8.0 too.

Oops, meant to switch back to ASSIGNED since it already has an assignee.

[Bug fortran/81758] [OOP] Broken vtab

[liakhdi at ornl dot gov]

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

--- Comment #2 from DIL  ---
No, at this point I do not, unfortunately. These OOP bugs tend to show up at
higher levels, so it is not always clear how to reduce it to something small. I
will try to reduce it to something smaller, but not sure how far. For example,
the current problem shows up in the implementation of a vector container
(gfc_vector.F90), but only when it is used to implement something more complex,
specifically the graph container in this case (gfc_graph.F90). The latter uses
three containers in its implementation: vector, list, and dictionary, so it
depends on all of those.

[Bug c++/81762] New: errors defining attribute target overloads of the same function template

[msebor at gcc dot gnu.org]

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

Bug ID: 81762
   Summary: errors defining attribute target overloads of the same
function template
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

G++ accepts definitions of distinct overloads of the same function that differ
only in their target attribute specifier but rejects definitions of equivalent
"overloads" of function templates, or "overloads" of the same explicit
specializations of a function template.

In the test case below, I expect all the definitions to be accepted as distinct
but the template ones are rejected with errors that suggest an incomplete
integration of the attribute target feature into the C++ front end.


$ cat a.c && gcc -Wall -Wextra -xc++ a.c && ./a.out 
#define A "arch=corei7"

void __attribute__ ((target ("default")))
foo (int) { }

void __attribute__ ((target (A)))
foo (int) { /* okay, different foo */ }


template 
void bar (T);

template <>
void __attribute__ ((target ("default")))
bar(int) { }

template <>
void __attribute__ ((target (A)))
bar(int) { /* rejected (bug?) */ }


template 
void __attribute__ ((target ("default")))
baz (T) { }

template 
void __attribute__ ((target (A)))
baz (T) { /* rejected (bug?) */ }
a.c:19:1: error: redefinition of ‘void bar(T) [with T = int]’
 bar(int) { /* rejected (bug?) */ }
 ^~~~
a.c:15:1: note: ‘void bar(T) [with T = int]’ previously declared here
 bar(int) { }
 ^~~~
a.c:28:1: error: ambiguating new declaration ‘template void baz(T)’
 baz (T) { /* rejected (bug?) */ }
 ^~~
a.c:24:1: note: old declaration ‘template void baz(T)’
 baz (T) { }
 ^~~

[Bug c++/81721] precompiled header : internal compiler error: Segmentation fault

[juro.bystricky at intel dot com]

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

Juro Bystricky  changed:

   What|Removed |Added

 CC||juro.bystricky at intel dot com

--- Comment #2 from Juro Bystricky  ---
This patch fixes the issue:
http://lists.openembedded.org/pipermail/openembedded-core/2017-August/140486.html

[Bug c++/81721] precompiled header : internal compiler error: Segmentation fault

[juro.bystricky at intel dot com]

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

--- Comment #1 from Juro Bystricky  ---
This patch fixes the issue:
http://lists.openembedded.org/pipermail/openembedded-core/2017-August/140486.html

[Bug c++/81761] New: assembler error on __func__ et al. on attribute target overloads

[msebor at gcc dot gnu.org]

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

Bug ID: 81761
   Summary: assembler error on __func__ et al. on attribute target
overloads
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Using the assert() macro or the __func__ special identifier in two or more
overloads of a function that differ only in their attribute target
specification leads to assembler errors caused by the identifiers not being
sufficiently differentiated from one another.  The test case below shows the
problem on x86_64 but the same issue is likely to affect the powerpc64 back
end.

$ cat a.c && gcc -Wall -Wextra -xc++ a.c && ./a.out 
#include 

#define A "arch=silvermont"

void __attribute__ ((target ("default")))
foo ()
{
  assert (!__builtin_cpu_is ("silvermont"));
}

void __attribute__ ((target (A)))
foo ()
{
  assert (__builtin_cpu_is ("silvermont"));
}

/tmp/ccX8mC6W.s: Assembler messages:
/tmp/ccX8mC6W.s:82: Error: symbol `_ZZ3foovE19__PRETTY_FUNCTION__' is already
defined

[Bug target/81759] Improve data tracking for _pext_u64 and __builtin_ffsll

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Target||x86_64-pc-linux-gnu
   Severity|normal  |enhancement

[Bug c++/81760] New: attribute target uses the wrong default function argument

[msebor at gcc dot gnu.org]

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

Bug ID: 81760
   Summary: attribute target uses the wrong default function
argument
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

GCC allows multiple functions with attribute target to be declared with
conflicting default arguments.  The function that ends up invoked may or may
not be passed the default argument values corresponding to its declaration.

The test case below should print one of two lines.  Either

  foo ("arch=silvermont") [arch=silvermont]

on a Silvermont CPU, or

  foo ("default") [default]

on a lesser processor, but it instead prints:

  foo ("arch=silvermont") [default]

indicating that the default function is invoked with the default argument value
corresponding to the one Silvermont overload.

Since C++ normally prohibits declaring the same function with two different
default argument values it seems that rejecting it on distinct overloads that
differ only in the target attribute would make the most sense.


$ cat a.c && gcc -Wall -Wextra -fdump-tree-optimized=/dev/stdout -xc++ a.c &&
./a.out
$ cat a.c && /ssd/build/gcc-git/gcc/xgcc -B /ssd/build/gcc-git/gcc -Wall
-Wextra -fdump-tree-optimized=/dev/stdout -xc++ a.c && ./a.out 
#define A "arch=silvermont"

void __attribute__ ((target ("default")))
foo (const char* = "default");

void __attribute__ ((target (A)))
foo (const char * = A);   // accepted (bug)

int main ()
{
  foo ();
}

int __attribute__ ((target ("default")))
foo (const char *a)
{
  __builtin_printf ("foo (\"%s\") [default]\n", a);
  return 0;
}

int __attribute__ ((target (A)))
foo (const char *a)
{
  __builtin_printf ("foo (\"%s\") [%s]\n", a, A);
  return 0;
}


;; Function int main() (main, funcdef_no=0, decl_uid=2445, cgraph_uid=3,
symbol_order=3)

int main() ()
{
  int D.2460;
  int _3;

   [0.00%] [count: INV]:
  _Z3fooPKc ("arch=silvermont");
  _3 = 0;

   [0.00%] [count: INV]:
:
  return _3;

}



;; Function int foo(const char*) (_Z3fooPKc, funcdef_no=1, decl_uid=2455,
cgraph_uid=4, symbol_order=4)

__attribute__((target ("default")))
int foo(const char*) (const char * a)
{
  int D.2467;
  int _4;

   [0.00%] [count: INV]:
  __builtin_printf ("foo (\"%s\") [default]\n", a_2(D));
  _4 = 0;

   [0.00%] [count: INV]:
:
  return _4;

}



;; Function int foo(const char*) (_Z3fooPKc.arch_silvermont, funcdef_no=2,
decl_uid=2458, cgraph_uid=5, symbol_order=5)

__attribute__((target ("arch=silvermont")))
int foo(const char*) (const char * a)
{
  int D.2469;
  int _4;

   [0.00%] [count: INV]:
  __builtin_printf ("foo (\"%s\") [%s]\n", a_2(D), "arch=silvermont");
  _4 = 0;

   [0.00%] [count: INV]:
:
  return _4;

}



;; Function _Z3fooPKc.resolver (_Z3fooPKc.resolver, funcdef_no=4,
decl_uid=2462, cgraph_uid=6, symbol_order=6)

_Z3fooPKc.resolver ()
{
  void * D.2466;
  int D.2465;
  void * D.2464;
  int _3;
  void * _4;
  void * _5;

   [100.00%] [count: INV]:
  __builtin_cpu_init ();
  _3 = __builtin_cpu_is (&"silvermont"[0]);
  if (_3 > 0)
goto ; [100.00%] [count: INV]
  else
goto ; [INV] [count: INV]

   [100.00%] [count: INV]:
  _5 = (void *) foo;
  return _5;

   [100.00%] [count: INV]:
  _4 = (void *) foo;
  return _4;

}


foo ("arch=silvermont") [default]

[Bug c/81759] New: Improve data tracking for _pext_u64 and __builtin_ffsll

[bugzi...@poradnik-webmastera.com]

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

Bug ID: 81759
   Summary: Improve data tracking for _pext_u64 and
__builtin_ffsll
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bugzi...@poradnik-webmastera.com
  Target Milestone: ---

This simple function gets index of least significant byte with its MSB cleared:

#include 
#include "immintrin.h"

uint64_t get_first_msb_cleared(uint64_t val)
{
  uint64_t msbs = _pext_u64(val, 0x8080808080808080);
  uint64_t msb_index = __builtin_ffsll(~msbs) - 1;
  return msb_index;
}

Here is assembly generated by gcc 7.1 (according to https://godbolt.org/):
get_first_msb_cleared(unsigned long):
  movabs rax, -9187201950435737472
  pext rdi, rdi, rax
  mov rax, -1
  not rdi
  bsf rdi, rdi
  cmove rdi, rax
  movsx rax, edi
  ret

gcc could do better job here. In this case value returned by _pext_u64 has bits
9-64 set to zero, so after negation they will be set to 1. Because of this gcc
could skip "mov rax, -1" and "cmove rdi, rax", this code path is dead.

[Bug fortran/81758] [OOP] Broken vtab

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #1 from Thomas Koenig  ---
Do you have a reduced test case that does not require understanding
your whole package?

[Bug libfortran/80850] Sourced allocate() fails to allocate a pointer

[liakhdi at ornl dot gov]

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

--- Comment #11 from DIL  ---
The additional problem you observe with gfortran/7.1 described in the comment
"2017-05-26 22:43:21 UTC" seems to be another gfortran compiler bug introduced
in GCC/7.0. I have just filed a bug report for it (#81758). To my current
understanding, it is not related to this (potential) bug report which is
observed with GCC/5.x and GCC/6.x. Also, in the context of the current bug
report, for more convenience I have isolated the problematic section of my code
in a separate few-line procedure that can be found in stsubs.F90 line 275
(function clone_object). I still observe the same wrong behavior: Sourced
allocate() returns "Attempt to allocated and allocated object" on an explicitly
dissociated pointer (meaning allocation status is Unallocated). Additionally, I
ran more tests on different platforms and here is the statistics:
a) The sourced allocation crash I observe is non-deterministic;
b) It is more likely to appear in the "-O0 -g" build than in "-O3";
c) It disappears in GDB;
d) It always crashes on Mac;
e) It crashes ~ 50% of times on Ubuntu Linux;
f) It does not crash on some platforms with RedHat Linux.

The code repo is the same:
https://github.com/DmitryLyakh/GFC.git
or
https://gitlab.com/DmitryLyakh/GFC.git

Any response or comment would be highly appreciated! Thanks.

[Bug libstdc++/81751] __basic_file::sync() may flush _all_ files

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-07
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
That seems like a sensible change.

[Bug c++/81757] function reference on nonnull and noexcept

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-07
 Ever confirmed|0   |1

[Bug target/72804] Poor code gen with -mvsx-timode

[bergner at gcc dot gnu.org]

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

--- Comment #5 from Peter Bergner  ---
I'm testing a patch.  The root cause is that the vsx_le_permute_*,
vsx_le_perm_load_* and vsx_le_perm_store_* patterns do not support the TImode
values in integer registers and it is these patterns that LRA is using to try
and reload the TImode values into/out of integer registers, which causes us to
loop until some magic happens and we break out.

Adding support for integer registers to the above patterns improves the code to
what we would expect to see.

[Bug fortran/81758] New: [OOP] Broken vtab

[liakhdi at ornl dot gov]

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

Bug ID: 81758
   Summary: [OOP] Broken vtab
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: liakhdi at ornl dot gov
  Target Milestone: ---

It seems like something is seriously wrong with GFORTRAN 7.x virtual table
constructor. I observe an incorrect association of type-bound procedures to
their calling names. For example, in
procedure, public:: method_name=>ProcedureName
I observe method_name to be associated with another (unrelated) type-bound
procedure from a completely different type (pretty much all of them are
associated with wrong procedures). If you clone my GFC (Generic Fortran
Containers) code from
https://github.com/DmitryLyakh/GFC.git
or
https://gitlab.com/DmitryLyakh/GFC.git
then in file gfc_vector.F90 lines 740-742 you will see that a pointer "cep" is
associated and is trying to invoke one of its type-bound procedures
"get_value()". However the debugger shows that get_value() in _vptr is
currently associated with another type-bound procedure from a completely
different type vector_t, specifically its type-bound procedure
VectorLowerBound(), which does not make any sense. Other type-bound procedures
in "cep" also associated with wrong procedures. As a consequence, the call
crashes with invalid memory reference. This is only observed with GCC 7.

To build my code, just type make and run the binary.

[Bug rtl-optimization/81625] GCC v4.7 ... v8 is bloating code by > 25% compared to v3.4

[fredrik.hederstie...@securitas-direct.com]

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

--- Comment #5 from Fredrik Hederstierna 
 ---
I tried build several AVR toolchains from 3.4.6 to 7.1.0 and I can confirm that
code size increases as described. I suspect for AVR this might start already
from 3.x -> 4.x

Checked Bug 17549 - [4.0 Regression] 10% increase in codesize with C code
compared to GCC 3.3: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17549

If TER pass is disabled adding "-fno-tree-ter", then results get more than -10%
smaller. Though results still gets +10% worse than 3.4.6 even with 7.1.0,
though adding -mstrict-X also makes its slightly better too..

[Bug target/81755] Building of cross compiler for powerpc-wrs-vxworksmils is broken

[hainque at gcc dot gnu.org]

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

Olivier Hainque  changed:

   What|Removed |Added

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

--- Comment #3 from Olivier Hainque  ---
fixed on mainline

[Bug target/81755] Building of cross compiler for powerpc-wrs-vxworksmils is broken

[hainque at gcc dot gnu.org]

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

--- Comment #2 from Olivier Hainque  ---
Author: hainque
Date: Mon Aug  7 20:13:53 2017
New Revision: 250931

URL: https://gcc.gnu.org/viewcvs?rev=250931=gcc=rev
Log:
Olivier Hainque  

PR target/81755
* config/vxworksae.h (VXWORKS_HAVE_TLS): Define.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/vxworksae.h

[Bug tree-optimization/81741] Misoptimisation : replacing a constant field read access by a function call

[patrick.pelissier at gmail dot com]

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

--- Comment #2 from Patrick Pelissier  ---
I can reproduce the behavior without __builtin_constant_p by removing it from
the M_ASSUME macro :

# define M_ASSUME(x)\
  (  (x) ?  \
   (void) 0 : __builtin_unreachable())

It still generates the same instructions.

[Bug target/81755] Building of cross compiler for powerpc-wrs-vxworksmils is broken

[hainque at gcc dot gnu.org]

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

Olivier Hainque  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-08-07
 Ever confirmed|0   |1

--- Comment #1 from Olivier Hainque  ---
mine

[Bug fortran/81116] Last character of allocatable-length string reset to blank in an assigment

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #2 from Thomas Koenig  ---
Mine.

[Bug c++/81359] [7/8 Regression] bogus error: constructor required before non-static data member for ‘Foo::Bar::test’ has been parsed

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #2 from Jason Merrill  ---
Reduced:

template
static int test(int);

template
static void test(...);

template (0))>
struct A { };

struct B
{
  struct C {
int i = 0;
  };
  A a;
};

[Bug c++/81525] [7/8 Regression] Invalid codegen with constexpr variable template

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
The bug is that GCC is replacing the auto with the implicit template argument
of the generic lambda.

[Bug c++/81525] [7/8 Regression] Invalid codegen with constexpr variable template

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/81757] New: function reference on nonnull and noexcept

[patrick.a.moran at gmail dot com]

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

Bug ID: 81757
   Summary: function reference on nonnull and noexcept
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick.a.moran at gmail dot com
  Target Milestone: ---

Created attachment 41948
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41948=edit
a minimal reproduction

We have noticed a behavior that we believe to be a bug.  It appears in the
recent 7.2 release candidate, and we know for sure that the behavior was not
present in 6.3.  It manifests in --std=c++17 or --std=c++1z.

I have attached a minimal reproduction.

g++ --std=c++17 -c repro.cpp

We get a failure to compile with the following message

--
error: invalid initialization of reference of type ‘void (&)(void*) noexcept’
from expression of type ‘void(void*) noexcept’
 void do_stuff() { test(foo); }
   ^
note: in passing argument 1 of ‘void test(TFunction&&) [with TFunction = void
(&)(void*) noexcept]’
 void test(TFunction&& function);
--

We encounter the error only if _all_ the following conditions are met:

1. The function passed as an argument takes a pointer-typed argument is forward
declared with __attribute__((nonnull(n)))  (With "n" replaced with the 1-based
index of the pointer-typed argument).

2. The function is declared noexcept

3. That function is passed as an argument to another function via forwarding
reference

[Bug c/69389] bit field incompatible with OpenMP atomic update

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Mon Aug  7 18:34:29 2017
New Revision: 250929

URL: https://gcc.gnu.org/viewcvs?rev=250929=gcc=rev
Log:
PR c/69389
* gimplify.c (goa_stabilize_expr): Handle BIT_INSERT_EXPR and
BIT_FIELD_REF.

* c-omp.c (c_finish_omp_atomic): Handle atomics on bitfields.

* testsuite/libgomp.c/pr69389.c: New test.
* testsuite/libgomp.c++/pr69389.C: New test.

Added:
trunk/libgomp/testsuite/libgomp.c++/pr69389.C
trunk/libgomp/testsuite/libgomp.c/pr69389.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-omp.c
trunk/gcc/gimplify.c
trunk/libgomp/ChangeLog

[Bug fortran/67493] -fcheck=recursive not thread aware

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||tkoenig at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #2 from Thomas Koenig  ---
In this particular case, all variables are on the stack, so this
is not a problem.

However, even a PURE function could put an array into static storage,
such as this example:

$ gfortran -S -fdump-tree-original worker.f90
$ cat worker.f90.003t.original 
worker (integer(kind=4) & restrict n, integer(kind=4) & restrict sumn)
{
  integer(kind=4) k;
  static integer(kind=4) x[1];

  *sumn = 0;

[...]

So, for thread-safety, better specify RECURSIVE.

[Bug middle-end/78266] broken openacc loop partitioning on nvptx offloading targets

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

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

--- Comment #10 from Tom de Vries  ---
patch with test-case committed.

marking resolved-fixed.

[Bug middle-end/78266] broken openacc loop partitioning on nvptx offloading targets

[vries at gcc dot gnu.org]

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

--- Comment #9 from Tom de Vries  ---
patch with test-suite (In reply to cesar from comment #8)
> Because num_gangs exceeds largest unsigned value that can be represented by
> the induction variable.

I think what you're trying to say here is that the program is not correct. I
haven't found anything in the standard to suggest that this is incorrect.

[Bug middle-end/78266] broken openacc loop partitioning on nvptx offloading targets

[cesar at gcc dot gnu.org]

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

--- Comment #8 from cesar at gcc dot gnu.org ---
Because num_gangs exceeds largest unsigned value that can be represented by the
induction variable.

[Bug middle-end/78266] broken openacc loop partitioning on nvptx offloading targets

[vries at gcc dot gnu.org]

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

--- Comment #7 from Tom de Vries  ---
(In reply to cesar from comment #6)
> I'm not sure that solution is correct.

Why ?

[Bug middle-end/78266] broken openacc loop partitioning on nvptx offloading targets

[cesar at gcc dot gnu.org]

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

--- Comment #6 from cesar at gcc dot gnu.org ---
I'm not sure that solution is correct.  A better solution would be to report an
error/warning stating that num_workers exceeds the size of the induction
variable. Also, in the case that user doesn't specify num_gangs and the type of
the induction variable is less than integer_node_type, then hard-code num_gangs
to 255 or something small so that the runtime doesn't assign num_gangs that
generate bogus results.

[Bug target/81753] Building of cross-compiler for powerpc-darwin7 is broken

[acsawdey at gcc dot gnu.org]

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

acsawdey at gcc dot gnu.org changed:

   What|Removed |Added

 CC||acsawdey at gcc dot gnu.org

--- Comment #1 from acsawdey at gcc dot gnu.org ---
Looks to me like this configuration is not including rs6000-string.o. 

Can you see if this is fixed by adding rs6000-string.o to extra_objs in the
*-*-darwin section of gcc/config.gcc?

[Bug middle-end/78266] broken openacc loop partitioning on nvptx offloading targets

[vries at gcc dot gnu.org]

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

--- Comment #5 from Tom de Vries  ---
Author: vries
Date: Mon Aug  7 17:06:11 2017
New Revision: 250925

URL: https://gcc.gnu.org/viewcvs?rev=250925=gcc=rev
Log:
Fix diff_type in expand_oacc_for char iter_type

2017-08-07  Tom de Vries  

PR middle-end/78266
* omp-expand.c (expand_oacc_for): Ensure diff_type is large enough.

* testsuite/libgomp.oacc-c-c++-common/vprop-2.c: New test.
* testsuite/libgomp.oacc-c-c++-common/vprop.c: Remove xfail.

Added:
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/vprop-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/omp-expand.c
trunk/libgomp/ChangeLog
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/vprop.c

[Bug c/81756] New: type attributes silently ignored on type declarations

[msebor at gcc dot gnu.org]

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

Bug ID: 81756
   Summary: type attributes silently ignored on type declarations
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

When the C11 _Alignas specifier is used on a struct declaration GCC issues a
helpful warning pointing out that the attribute is meaningless.  The warning is
issued unconditionally with no option to control it.  This should be corrected
and the warning should be enabled under a designated option (e.g., -Wattributes
or -Wignored-attributes).

However, when the equivalent attribute aligned is used the same way GCC
silently ignores it.  It would help prevent subtle bugs to have GCC issue a
warning in this case to let the user know that the attribute has no effect.

The test case below illustrates the problem.

$ cat b.c && gcc -O2 -S -Wall -Wextra b.c
#define A(e) _Static_assert ((e), #e)

_Alignas (32) struct NotAligned;   // ignored with warning  (good)

struct NotAligned { long i; };

A (_Alignof (struct NotAligned) == _Alignof (long));   // passes


struct __attribute__ ((aligned (32)))   // silently ignored
Aligned32;

struct Aligned32 { long i; };

A (_Alignof (struct Aligned32) == 32);   // FAILS
b.c:3:22: warning: useless ‘_Alignas’ in empty declaration
 _Alignas (32) struct NotAligned;   // ignored with warning  (good)
  ^~
b.c:1:14: error: static assertion failed: "_Alignof (struct Aligned32) == 32"
 #define A(e) _Static_assert ((e), #e)
  ^~
b.c:15:1: note: in expansion of macro ‘A’
 A (_Alignof (struct Aligned32) == 32);   // FAILS
 ^

[Bug target/81755] New: Building of cross compiler for powerpc-wrs-vxworksmils is broken

[marxin at gcc dot gnu.org]

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

Bug ID: 81755
   Summary: Building of cross compiler for powerpc-wrs-vxworksmils
is broken
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: powerpc-wrs-vxworksmils

g++ -fno-PIE -c   -O0 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE   -fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common 
-DHAVE_CONFIG_H -I. -I. -I/home/marxin/Programming/gcc2/gcc
-I/home/marxin/Programming/gcc2/gcc/.
-I/home/marxin/Programming/gcc2/gcc/../include
-I/home/marxin/Programming/gcc2/gcc/../libcpp/include 
-I/home/marxin/Programming/gcc2/gcc/../libdecnumber
-I/home/marxin/Programming/gcc2/gcc/../libdecnumber/dpd -I../libdecnumber
-I/home/marxin/Programming/gcc2/gcc/../libbacktrace   -I. -I.
-I/home/marxin/Programming/gcc2/gcc -I/home/marxin/Programming/gcc2/gcc/.
-I/home/marxin/Programming/gcc2/gcc/../include
-I/home/marxin/Programming/gcc2/gcc/../libcpp/include 
-I/home/marxin/Programming/gcc2/gcc/../libdecnumber
-I/home/marxin/Programming/gcc2/gcc/../libdecnumber/dpd -I../libdecnumber
-I/home/marxin/Programming/gcc2/gcc/../libbacktrace 
/home/marxin/Programming/gcc2/gcc/config/vxworks.c
/home/marxin/Programming/gcc2/gcc/config/vxworks.c: In function ‘void
vxworks_override_options()’:
/home/marxin/Programming/gcc2/gcc/config/vxworks.c:130:22: error:
‘VXWORKS_HAVE_TLS’ was not declared in this scope
   targetm.have_tls = VXWORKS_HAVE_TLS;
  ^~~~
/home/marxin/Programming/gcc2/gcc/config/vxworks.c:130:22: note: suggested
alternative: ‘VXWORKS_KIND_AE’
   targetm.have_tls = VXWORKS_HAVE_TLS;
  ^~~~
  VXWORKS_KIND_AE

[Bug fortran/68829] [5/6/7/8 Regression] Segfaults with -Ofast due to large array on stack

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #9 from Thomas Koenig  ---
Actually closing.

[Bug fortran/68829] [5/6/7/8 Regression] Segfaults with -Ofast due to large array on stack

[tkoenig at gcc dot gnu.org]

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

--- Comment #8 from Thomas Koenig  ---
It is now possible to use -fmax-stack-var-size with -Ofast.

Closing.

[Bug fortran/68829] [5/6/7/8 Regression] Segfaults with -Ofast due to large array on stack

[tkoenig at gcc dot gnu.org]

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

Bug 81701 Summary: -fstack-arrays hehavior does not match documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81701

   What|Removed |Added

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

[Bug fortran/81701] -fstack-arrays hehavior does not match documentation

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #3 from Thomas Koenig  ---
Fixed the docs, closing.

[Bug fortran/68829] [5/6/7/8 Regression] Segfaults with -Ofast due to large array on stack

[tkoenig at gcc dot gnu.org]

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

--- Comment #7 from Thomas Koenig  ---
Author: tkoenig
Date: Mon Aug  7 16:43:05 2017
New Revision: 250923

URL: https://gcc.gnu.org/viewcvs?rev=250923=gcc=rev
Log:
2017-08-07  Thomas Koenig  

PR fortran/68829
* doc/invoke.texi: Document change in behvaior for -Ofast for
Fortran.

2017-08-07  Thomas Koenig  

PR fortran/68829
PR fortran/81701
* options.c: Make -Ofast honor -fmax-stack-var-size.
* invoke.texi: Document change.

2017-08-07  Thomas Koenig  

PR fortran/68829
PR fortran/81701
* gfortran.dg/o_fast_stacksize.90:  New test.


Added:
trunk/gcc/testsuite/gfortran.dg/o_fast_stacksize.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/invoke.texi
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/options.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/81701] -fstack-arrays hehavior does not match documentation

[tkoenig at gcc dot gnu.org]

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

--- Comment #2 from Thomas Koenig  ---
Author: tkoenig
Date: Mon Aug  7 16:43:05 2017
New Revision: 250923

URL: https://gcc.gnu.org/viewcvs?rev=250923=gcc=rev
Log:
2017-08-07  Thomas Koenig  

PR fortran/68829
* doc/invoke.texi: Document change in behvaior for -Ofast for
Fortran.

2017-08-07  Thomas Koenig  

PR fortran/68829
PR fortran/81701
* options.c: Make -Ofast honor -fmax-stack-var-size.
* invoke.texi: Document change.

2017-08-07  Thomas Koenig  

PR fortran/68829
PR fortran/81701
* gfortran.dg/o_fast_stacksize.90:  New test.


Added:
trunk/gcc/testsuite/gfortran.dg/o_fast_stacksize.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/invoke.texi
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/options.c
trunk/gcc/testsuite/ChangeLog

[Bug target/81754] New: Building of cross compiler avr-elf is broken

[marxin at gcc dot gnu.org]

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

Bug ID: 81754
   Summary: Building of cross compiler avr-elf is broken
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: avr-elf

Hello.

After this revision I see:

$ ../configure --target=avr-elf --enable-languages=c,c++ --disable-bootstrap

$ make

../../gcc/config/avr/avr.c: In function ‘void avr_option_override()’:
../../gcc/config/avr/avr.c:778:29: error: lvalue required as left operand of
assignment
   TARGET_GASISR_PROLOGUES = 0;
 ^

[Bug target/81753] New: Building of cross-compiler for powerpc-darwin7 is broken

[marxin at gcc dot gnu.org]

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

Bug ID: 81753
   Summary: Building of cross-compiler for powerpc-darwin7 is
broken
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: powerpc-darwin7

make[2]: Entering directory
'/dev/shm/gcc-batch-builds/objs/powerpc-darwin7/gcc'
g++ -no-pie   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE   -fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common 
-DHAVE_CONFIG_H -static-libstdc++ -static-libgcc  -o cc1 c/c-lang.o
c-family/stub-objc.o attribs.o c/c-errors.o c/c-decl.o c/c-typeck.o
c/c-convert.o c/c-aux-info.o c/c-objc-common.o c/c-parser.o
c/c-array-notation.o c/c-fold.o c/gimple-parser.o c-family/c-common.o
c-family/c-cppbuiltin.o c-family/c-dump.o c-family/c-format.o
c-family/c-gimplify.o c-family/c-indentation.o c-family/c-lex.o
c-family/c-omp.o c-family/c-opts.o c-family/c-pch.o c-family/c-ppoutput.o
c-family/c-pragma.o c-family/c-pretty-print.o c-family/c-semantics.o
c-family/c-ada-spec.o c-family/c-cilkplus.o c-family/array-notation-common.o
c-family/cilk.o c-family/c-ubsan.o c-family/c-attribs.o c-family/c-warn.o
darwin-c.o rs6000-c.o \
  cc1-checksum.o libbackend.a main.o libcommon-target.a libcommon.a
../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a
../libcpp/libcpp.a   ../libbacktrace/.libs/libbacktrace.a
../libiberty/libiberty.a ../libdecnumber/libdecnumber.a  -lisl -lmpc -lmpfr
-lgmp -rdynamic -ldl  -L./../zlib -lz
passes.o: In function `gcc::pass_manager::pass_manager(gcc::context*)':
passes.c:(.text+0xd709): undefined reference to
`make_pass_analyze_swaps(gcc::context*)'
insn-emit.o: In function `gen_setmemsi(rtx_def*, rtx_def*, rtx_def*,
rtx_def*)':
insn-emit.c:(.text+0x2df83): undefined reference to
`expand_block_clear(rtx_def**)'
insn-emit.o: In function `gen_movmemsi(rtx_def*, rtx_def*, rtx_def*,
rtx_def*)':
insn-emit.c:(.text+0x2dffc): undefined reference to
`expand_block_move(rtx_def**)'
insn-output.o: In function `output_456(rtx_def**, rtx_insn*)':
insn-output.c:(.text+0x27d9): undefined reference to
`rs6000_output_load_multiple(rtx_def**)'
insn-output.o: In function `output_457(rtx_def**, rtx_insn*)':
insn-output.c:(.text+0x27f7): undefined reference to
`rs6000_output_load_multiple(rtx_def**)'
insn-output.o: In function `output_458(rtx_def**, rtx_insn*)':
insn-output.c:(.text+0x2815): undefined reference to
`rs6000_output_load_multiple(rtx_def**)'
insn-output.o: In function `output_459(rtx_def**, rtx_insn*)':
insn-output.c:(.text+0x2833): undefined reference to
`rs6000_output_load_multiple(rtx_def**)'
insn-output.o: In function `output_460(rtx_def**, rtx_insn*)':
insn-output.c:(.text+0x2851): undefined reference to
`rs6000_output_load_multiple(rtx_def**)'
insn-output.o:insn-output.c:(.text+0x286f): more undefined references to
`rs6000_output_load_multiple(rtx_def**)' follow
collect2: error: ld returned 1 exit status

[Bug libstdc++/81749] std::align: runtime error: negation of 8 cannot be represented in type 'size_t'

[max at maxbruckner dot de]

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

--- Comment #10 from Max Bruckner  ---
(In reply to Jakub Jelinek from comment #9)
> (In reply to Max Bruckner from comment #8)
> > Nevertheless I disagree that there is no "overflow" or "underflow". It's a
> > question of how you define the two words, in a way, but being defined
> > doesn't make less of an underflow/overflow.
> > 
> > This is no bug, since std::align exhibits totally defined behavior, but I
> > still think that having a runtime check for unsigned overflow is quite
> > useful, because although it might not be undefined, it might still be
> > unintended behavior in many cases.
> 
> I don't see how something like that can be ever useful.  unsigned integral
> types don't have negative values, so if you want to sometimes subtract and
> sometimes add some value, but the condition when that happens is done e.g.
> in another function, you just use one of the operations and use negated
> numbers.  That triggers this misdesigned sanitizer though of course.

First let me define unsigned integer overflow:
In my definition, overflow occurs when either an addition or multiplication
(maybe left shift as well?) of/with a positive number yields a result that is
smaller than the result would be with non-modular math. For example
((size_t)SIZE_MAX) + ((size_t)1U) which is 0, not SIZE_MAX + 1.

Simple example: Something like calloc.

If you calculate the size of a buffer with a multiplication, you might overflow
it (or almost overflow it and later add something that overflows it). When you
then go ahead and allocate some space for that buffer without checking, your
caller might think that enough space was allocated and start using it, not
knowing that it will go out of the bounds of the allocated memory region.

This discussion is kind of off-topic, but I just couldn't let the following
stand, because I find unsigned overflow detection very useful.

> Yeah, it is IMHO a very big mistake clang added that, we have conciously 
> added only signed-integer-overflow sanitizer, but not unsigned.

[Bug libstdc++/81749] std::align: runtime error: negation of 8 cannot be represented in type 'size_t'

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
(In reply to Max Bruckner from comment #8)
> Nevertheless I disagree that there is no "overflow" or "underflow". It's a
> question of how you define the two words, in a way, but being defined
> doesn't make less of an underflow/overflow.
> 
> This is no bug, since std::align exhibits totally defined behavior, but I
> still think that having a runtime check for unsigned overflow is quite
> useful, because although it might not be undefined, it might still be
> unintended behavior in many cases.

I don't see how something like that can be ever useful.  unsigned integral
types don't have negative values, so if you want to sometimes subtract and
sometimes add some value, but the condition when that happens is done e.g. in
another function, you just use one of the operations and use negated numbers. 
That triggers this misdesigned sanitizer though of course.

[Bug libgomp/81752] New: num_gangs(65536) converted to 0

[vries at gcc dot gnu.org]

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

Bug ID: 81752
   Summary: num_gangs(65536) converted to 0
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

num_gangs hits a limit at 65536 for nvptx. For this example:
...
int
main ()
{
#pragma acc parallel num_gangs(65536)
  ;
  return 0;
}
...

we get this warning:
...
/tmp/ccjtQtKi.c:47:21: warning: unsigned conversion from 'int' to 'short
unsigned int' changes value from '65536' to '0' [-Woverflow]
  {"main$_omp_fn$0", 0x1, 0x1, 0x20}
...

The code triggering the warning in more detail:
...
static const struct nvptx_fn {
  const char *name;
  unsigned short dim[3];
} func_mappings[] = {

{"main$_omp_fn$0", 0x1, 0x1, 0x20}
};
...

[Bug c/69389] bit field incompatible with OpenMP atomic update

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 41947
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41947=edit
gcc8-pr69389.patch

Untested fix.

[Bug libstdc++/81749] std::align: runtime error: negation of 8 cannot be represented in type 'size_t'

[max at maxbruckner dot de]

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

--- Comment #8 from Max Bruckner  ---
I understand how unsigned integers work and that they are defined by the
standard to have modular arithmetic. In this case I just didn't add 1 and 1
together I guess.

Nevertheless I disagree that there is no "overflow" or "underflow". It's a
question of how you define the two words, in a way, but being defined doesn't
make less of an underflow/overflow.

This is no bug, since std::align exhibits totally defined behavior, but I still
think that having a runtime check for unsigned overflow is quite useful,
because although it might not be undefined, it might still be unintended
behavior in many cases.

[Bug target/81709] __attribute__((interrupt)) should handle SSE registers

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #1 from H.J. Lu  ---
If you want to use SSE registers, you can write the interrupt handler
with the new naked attribute in GCC 8.

[Bug middle-end/46932] Inefficient code sequence to access local variable

[wilco at gcc dot gnu.org]

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

--- Comment #8 from Wilco  ---
Author: wilco
Date: Mon Aug  7 13:56:02 2017
New Revision: 250918

URL: https://gcc.gnu.org/viewcvs?rev=250918=gcc=rev
Log:
Fix unresolved in gcc.dg/pr46932.c

Build only if pre-increment is supported.  Given there is no config test,
add a list of targets which have HAVE_PRE_INCREMENT set.

testsuite/
PR middle-end/46932
* gcc.dg/pr46932.c: Compile on targets with pre-increment.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/pr46932.c

[Bug libstdc++/81751] New: __basic_file::sync() may flush _all_ files

[bugzilla.volker at kabelmail dot de]

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

Bug ID: 81751
   Summary: __basic_file::sync() may flush _all_ files
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bugzilla.volker at kabelmail dot de
  Target Milestone: ---

When creating a stdio_filebuf from a FILE* the constructor calls
__basic_file::sys_open() which in turn calls __basic_file::sync(). Sync()
unconditionally makes a call to fflush() even if the _M_cfile member is NULL
which then causes _all_ open streams to be sync'd.

This behaviour makes it impossible to use stdio_filebuf in a multithreaded
environment as there may be a buffer that is flushed multiple times.

My proposed solution to file libstdc++-v3/config/io/basic_file_stdio.cc is to
call fflush() in sync() only if _M_cfile is not NULL:

int 
__basic_file::sync() 
{ return _M_cfile ? fflush(_M_cfile) : 0; }

This change makes sure only the controlled sequence is synchronized.

Alternatively the call to sync in function sys_open (in the same file) may be
made conditional on _M_cfile.

This issue is present in versions back to at least 4.7.2.

[Bug tree-optimization/81627] [8 Regression] ICE on valid code at -O3: in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:707

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from amker at gcc dot gnu.org ---
Fixed.

[Bug tree-optimization/81620] [8 Regression] ICE in is_inv_store_elimination_chain, at tree-predcom.c:1651 with -O3

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from amker at gcc dot gnu.org ---
Fixed.

[Bug middle-end/81408] Lots of new -Wunsafe-loop-optimizations warnings with 7 compared to 6

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #11 from amker at gcc dot gnu.org ---
Fixed.

[Bug target/81414] [6/7 Regression] ICE in fma steering on AArch64/cortex-a57

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #7 from amker at gcc dot gnu.org ---
Fixed.

[Bug middle-end/80815] wrong code because of broken runtime alias check in vectorizer

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #9 from amker at gcc dot gnu.org ---
Fixed.

[Bug preprocessor/81745] missing warning with -pedantic when a C file does not end with a newline character

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  ---
(In reply to Vincent Lefèvre from comment #9)
> Changed back to INVALID (there's a bug in bugzilla, which changes INVALID to
> FIXED after a reload + a new comment).

Sounds like something your browser did, bugzilla doesn't do that.

[Bug target/81736] Unnecessary save and restore frame pointer with -fno-omit-frame-pointer

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #2 from H.J. Lu  ---
Fixed.

[Bug target/81743] int __attribute__ ((target("arch=westmere"))) is compiled incorrectly

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #3 from H.J. Lu  ---
Fixed.

[Bug target/81743] int __attribute__ ((target("arch=westmere"))) is compiled incorrectly

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug c++/81668] LTO ODR warnings are not helpful

[sgunderson at bigfoot dot com]

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

--- Comment #5 from sgunderson at bigfoot dot com ---
(In reply to Markus Trippelsdorf from comment #3)
> I don't see any bug, all relevant information is in the warnings.

My point is that all relevant information _isn't_ in the warnings.

In particular: The context of the .h file (which .o/.cc file it was compiled as
part of in the two cases) is nowhere to be found. If I had that, it would be a
lot easier to preprocess the two files and try to find what the difference is.

Seemingly at least one of these was a GCC bug (#81716); with some luck, the
others I cannot figure out are, too.

[Bug tree-optimization/78972] [5/6/7/8 Regression] poor x86 simd instruction scheduling

[bernds at gcc dot gnu.org]

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

--- Comment #11 from Bernd Schmidt  ---
For reference: patch and discussion here.
https://gcc.gnu.org/ml/gcc-patches/2017-05/msg01058.html

[Bug middle-end/80283] [5/6/7/8 Regression] bad SIMD register allocation

[bernds at gcc dot gnu.org]

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

--- Comment #15 from Bernd Schmidt  ---
For reference: patch and discussion here.
https://gcc.gnu.org/ml/gcc-patches/2017-05/msg01058.html

[Bug target/81736] Unnecessary save and restore frame pointer with -fno-omit-frame-pointer

[hjl at gcc dot gnu.org]

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

--- Comment #1 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Mon Aug  7 11:49:10 2017
New Revision: 250916

URL: https://gcc.gnu.org/viewcvs?rev=250916=gcc=rev
Log:
i386: Don't use frame pointer without stack access

When there is no stack access, there is no need to use frame pointer
even if -fno-omit-frame-pointer is used.

gcc/

PR target/81736
* config/i386/i386.c (ix86_finalize_stack_realign_flags): Renamed
to ...
(ix86_finalize_stack_frame_flags): This.  Also clear
frame_pointer_needed if -fno-omit-frame-pointer is used without
stack access.
(ix86_expand_prologue): Replace ix86_finalize_stack_realign_flags
with ix86_finalize_stack_frame_flags.
(ix86_expand_epilogue): Likewise.
(ix86_expand_split_stack_prologue): Likewise.

gcc/testsuite/

PR target/81736
* gcc.target/i386/pr81736-1.c: New test.
* gcc.target/i386/pr81736-2.c: Likewise.
* gcc.target/i386/pr81736-3.c: Likewise.
* gcc.target/i386/pr81736-4.c: Likewise.

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

[Bug target/81743] int __attribute__ ((target("arch=westmere"))) is compiled incorrectly

[hjl at gcc dot gnu.org]

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

--- Comment #2 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Mon Aug  7 11:47:22 2017
New Revision: 250915

URL: https://gcc.gnu.org/viewcvs?rev=250915=gcc=rev
Log:
i386: Set priority to P_AES for Westmere

The difference between Nehalem and Westmere is AES.  We should set
priority to P_AES for Westmere, not P_PROC_SSE4_2 which is for Nehalem.
Otherwise, we will pick Nehalem implementation on Westmere.  Tested on
Westmere.

PR target/81743
* config/i386/i386.c (get_builtin_code_for_version): Set priority
to P_AES for Westmere.

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

[Bug libstdc++/81749] std::align: runtime error: negation of 8 cannot be represented in type 'size_t'

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
Strictly speaking, unsigned overflow doesn't even exist. "Integer overflow" is
only something that happens for signed integers. Operations on unsigned
integers have defined behaviour, they can't "overflow".

The C++ standard is clear what happens here: "The negative of an unsigned
quantity is computed by subtracting its value from 2^n , where n is the number
of bits in the promoted operand. The type of the result is the type of the
promoted operand."

[Bug hsa/81713] BIT_FIELD_REF produced by Brig FE do not pass new verification

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Jambor  ---
Thank you, this is now fixed.

[Bug libstdc++/81749] std::align: runtime error: negation of 8 cannot be represented in type 'size_t'

[max at maxbruckner dot de]

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

--- Comment #6 from Max Bruckner  ---
Oh, you're right, unsigned overflow is defined of course. I guess I should
report a bug with UBSan then to get a suppression included for libstdc++.

[Bug tree-optimization/81744] [8 Regression] ICE: verify_ssa failed, at tree-ssa.c:1186

[amker at gcc dot gnu.org]

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

--- Comment #6 from amker at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #5)
> (In reply to amker from comment #4)
> > So with below code in prepare_finalizers_chain:
> >   tree fini, niters = number_of_latch_executions (loop);
> >   //...
> >   niters = copy_node (niters);
> >   niters = force_gimple_operand (niters, , true, NULL);
> > 
> > Even with copy_node, the old niters (which is loop->nb_iterations is changed
> > by the call to force_gimple_operand.  The code expects every time function
> > prepare_finalizers_chain is callsed, the niters/loop->nb_iterations stays in
> > the same.  What should I do that?  Thanks.
> 
> copy_node copies only one level.  force_gimple_operand, like other
> entrypoints to the gimplifier, are destructive on the tree you pass in, so
> if you want to reuse niters after it, you should use niters = unshare_expr
> (niters).

Yes, I will send a patch.  Thanks.

[Bug tree-optimization/81744] [8 Regression] ICE: verify_ssa failed, at tree-ssa.c:1186

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
(In reply to amker from comment #4)
> So with below code in prepare_finalizers_chain:
>   tree fini, niters = number_of_latch_executions (loop);
>   //...
>   niters = copy_node (niters);
>   niters = force_gimple_operand (niters, , true, NULL);
> 
> Even with copy_node, the old niters (which is loop->nb_iterations is changed
> by the call to force_gimple_operand.  The code expects every time function
> prepare_finalizers_chain is callsed, the niters/loop->nb_iterations stays in
> the same.  What should I do that?  Thanks.

copy_node copies only one level.  force_gimple_operand, like other entrypoints
to the gimplifier, are destructive on the tree you pass in, so if you want to
reuse niters after it, you should use niters = unshare_expr (niters).

[Bug tree-optimization/81744] [8 Regression] ICE: verify_ssa failed, at tree-ssa.c:1186

[amker at gcc dot gnu.org]

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

--- Comment #4 from amker at gcc dot gnu.org ---
So with below code in prepare_finalizers_chain:
  tree fini, niters = number_of_latch_executions (loop);
  //...
  niters = copy_node (niters);
  niters = force_gimple_operand (niters, , true, NULL);

Even with copy_node, the old niters (which is loop->nb_iterations is changed by
the call to force_gimple_operand.  The code expects every time function
prepare_finalizers_chain is callsed, the niters/loop->nb_iterations stays in
the same.  What should I do that?  Thanks.

[Bug middle-end/78266] broken openacc loop partitioning on nvptx offloading targets

[vries at gcc dot gnu.org]

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

--- Comment #4 from Tom de Vries  ---
F.i., we generate:
...
  _41 = GOACC_DIM_SIZE (0);
  _29 = (signed char) _41;
...
where _41 is 256.

When folding in forwprop2, we fold _29 to '0':
...
gimple_simplified to _29 = 0;
...

[Bug libstdc++/81749] std::align: runtime error: negation of 8 cannot be represented in type 'size_t'

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #5 from Jakub Jelinek  ---
Yeah, it is IMHO a very big mistake clang added that, we have conciously added
only signed-integer-overflow sanitizer, but not unsigned.

[Bug middle-end/78266] broken openacc loop partitioning on nvptx offloading targets

[vries at gcc dot gnu.org]

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

--- Comment #3 from Tom de Vries  ---
Minimal example:
...
int
main ()
{

  #pragma acc parallel num_gangs(256)
  {
#pragma acc loop gang
for (unsigned char j = 0; j < 5; j++)
  ;
  }

  return 0;
}
...

We generate an unconditional trap, thanks to pass_isolate_erroneous_paths:
...
.entry main$_omp_fn$0 (.param .u64 %in_ar0)
{
  .reg .u64 %ar0;
  ld.param.u64 %ar0,[%in_ar0];
  .reg .pred %r23;
  {
.reg .u32 %x;
mov.u32 %x,%tid.x;
setp.ne.u32 %r23,%x,0;
  }
  @ %r23 bra $L2;
  trap;
  $L2:
}
...

AFAICT, the problem is that the logic that distributes the iterations over the
gangs uses signed char, while the number of gangs can be larger than what is
representable.

[Bug libstdc++/81749] std::align: runtime error: negation of 8 cannot be represented in type 'size_t'

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org

--- Comment #4 from Markus Trippelsdorf  ---
Unsigned integer overflow isn't undefined behavior.

[Bug libstdc++/81749] std::align: runtime error: negation of 8 cannot be represented in type 'size_t'

[max at maxbruckner dot de]

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

--- Comment #3 from Max Bruckner  ---
Created attachment 41946
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41946=edit
Suppression file as a workaround. Add to UBSAN_OPTIONS=supressions=...

[Bug libstdc++/81749] std::align: runtime error: negation of 8 cannot be represented in type 'size_t'

[max at maxbruckner dot de]

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

--- Comment #2 from Max Bruckner  ---
This is on x86_64

[Bug libstdc++/81749] std::align: runtime error: negation of 8 cannot be represented in type 'size_t'

[max at maxbruckner dot de]

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

--- Comment #1 from Max Bruckner  ---
Created attachment 41945
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41945=edit
Makefile to reproduce the error

[Bug libstdc++/81749] New: std::align: runtime error: negation of 8 cannot be represented in type 'size_t'

[max at maxbruckner dot de]

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

Bug ID: 81749
   Summary: std::align: runtime error: negation of 8 cannot be
represented in type 'size_t'
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: max at maxbruckner dot de
  Target Milestone: ---

Created attachment 41944
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41944=edit
C++ file to reproduce the error

When compiling code with clangs undefined behavior sanitizer (clang++ 4.0.1
-fsanitize=unsigned-integer-overflow) that uses std::align, a runtime error
occurs:

/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../include/c++/7.1.1/memory:117:54:
runtime error: negation of 8 cannot be represented in type 'size_t' (aka
'unsigned long')

The issue can be reproduced with the C++ and Makefile from the attachments.

The full output of my test:

alignof(intmax_t) = 8  
alloced = 0x5606f17e7c21   
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../include/c++/7.1.1/memory:117:54:
runtime error: negation of 8 cannot be represented in type 'size_t' (aka
'unsigned long')
address = 0x5606f17e7c28   
space = 92

[Bug middle-end/78266] broken openacc loop partitioning on nvptx offloading targets

[vries at gcc dot gnu.org]

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

--- Comment #2 from Tom de Vries  ---
Reproduced it by mapping the outer loop to gang, and setting num_gangs to 640.

[Bug middle-end/81737] [8 Regression] 164.gzip in SPEC CPU 2000 failed to build

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug middle-end/81737] [8 Regression] 164.gzip in SPEC CPU 2000 failed to build

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Fixed.

[Bug middle-end/81737] [8 Regression] 164.gzip in SPEC CPU 2000 failed to build

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Author: mpolacek
Date: Mon Aug  7 09:13:02 2017
New Revision: 250912

URL: https://gcc.gnu.org/viewcvs?rev=250912=gcc=rev
Log:
PR middle-end/81737
* fold-const.c (fold_indirect_ref_1): Check type_domain.

* gcc.dg/pr81737.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr81737.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/81748] New: extensible types non-conforming behaviour

[mexas at bristol dot ac.uk]

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

Bug ID: 81748
   Summary: extensible types non-conforming behaviour
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mexas at bristol dot ac.uk
  Target Milestone: ---

module m
implicit none
  type t1
integer :: age
  end type t1
  type, extends( t1 ) :: t2
real :: height_cm
  end type t2
  type, extends( t2 ) :: t3
real :: mass_kg
  end type t3
contains
  subroutine s( man )
class( t1 ) :: man(:)
integer :: i
do i = 1, size( man )
  if ( man(i) % age .gt. 3 ) write (*,*) man(i) % age
end do
  end subroutine s
end module m
program z
use m
implicit none
  type( t3 ) :: person3( 5 )
  integer:: i
person3 % t2 % age = (/ (i, i=1, size(person3)) /)
write (*,*) person3 % age
write (*,*) person3 % t1 % age
write (*,*) person3 % t2 % age
call s( person3 % t1 )
call s( person3 % t2 )
call s( person3 )
end program z

The correct output is (e.g. ifort 16 gives it):

   1   2   3   4   5
   1   2   3   4   5
   1   2   3   4   5
   4
   5
   4
   5
   4
   5

However, with gfortran8 the output is missing from lines:
   call s( person3 % t1 )
   call s( person3 % t2 )

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

[daniel.santos at pobox dot com]

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

--- Comment #63 from Daniel Santos  ---
Created attachment 41943
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41943=edit
test patch for uncaught exception in generator

(In reply to Dominique d'Humieres from comment #62)
> Created attachment 41937 [details]
> Log file for ms-sysv.exp
> 
> Log file generated with
> 
> make -k check-gcc RUNTESTFLAGS="ms-sysv.exp"

Thanks Dominique.  I'm still not seeing all of what I want to see because when
you ran this test run the code generator gcc/testsuite/gcc/ms-sysv-generate.exe
already existed and so was not rebuilt.  I'm curious to know the full command
line when it was built.  Could you apply this patch and run it again?  I should
probably make sure that we rebuild the generator on each new run anyway.

As far as the generator, it's not catching an exception that it should.  I had
been catching it by value because I always knew the type that was being thrown,
but maybe there is some type of weirdness in your particular stdlibc++
implementation, so this patch also changes the catch to by-reference.

Thanks,
Daniel

[Bug middle-end/81698] expand_case uses wrong edge as default edge

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Mon Aug  7 08:29:21 2017
New Revision: 250909

URL: https://gcc.gnu.org/viewcvs?rev=250909=gcc=rev
Log:
PR middle-end/81698
* stmt.c (emit_case_dispatch_table): Add DEFAULT_EDGE argument,
instead of computing it in the function.  Formatting fix.
(expand_case): Don't rely on default_edge being the first edge,
clear it if removing it, pass default_edge to
emit_case_dispatch_table.
(expand_sjlj_dispatch_table): Pass NULL as DEFAULT_EDGE, formatting
fix.

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

[Bug c++/81722] [7/8 Regression] memory hog building c++ on i686-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
It compiles just fine for me with 32-bit i686-linux-gnu cc1plus -g -O{0,1,2}
-std=c++11 -fpie.
top maxed around
virtual resident
3674.1m 3.455g
or so.  Of course it is close to the limitations of 32-bit address space,
assuming you can compile all template heavy code out there in 32-bit address
space is just wrong.

[Bug tree-optimization/81744] [8 Regression] ICE: verify_ssa failed, at tree-ssa.c:1186

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |amker at gcc dot gnu.org

--- Comment #3 from amker at gcc dot gnu.org ---
Thanks for reporting, I will investigate the issue.