[Bug go/81449] runtime.inc:782:28: error: field ‘__sem_lock’ has incomplete type

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #2 from Ian Lance Taylor  ---
Should be fixed on mainline now by revision 250217
(https://golang.org/cl/48593).

[Bug go/81449] runtime.inc:782:28: error: field ‘__sem_lock’ has incomplete type

[ian at airs dot com]

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

--- Comment #3 from Ian Lance Taylor  ---
Thanks for reporting it.

[Bug target/70589] PowerPC target attribute/pragma cannot set/disable -mfloat128

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 CC||meissner at gcc dot gnu.org

--- Comment #1 from Michael Meissner  ---
Created attachment 41763
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41763=edit
Proposed patch to fix the problem

[Bug ipa/81450] New: Typedef with assume aligned builtin yields segmentation fault in nested loop

[philipp.kopp at tum dot de]

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

Bug ID: 81450
   Summary: Typedef with assume aligned builtin yields
segmentation fault in nested loop
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: philipp.kopp at tum dot de
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 41762
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41762=edit
Small example with the working and the failing version

Hi,

I found that the assume aligned built-in gives a segmentation fault in nested
loops when using it with a typedef (or the C++ 11 using keyword). I attached a
small example code. I am using Ubuntu 17.04 with the standard gcc 6.3.0 from
the Ubuntu archives. I am compiling with gcc -O3 -g. So SSE vectorization is
enabled, without that the code runs fine.

The core part where execution fails is the following:

>  typedef double __attribute__((aligned (32))) AlignedDouble;

>  const size_t size = 17;
>  double alpha = 1.0 / 3.0;

>  // uses posix_memalign (see full testcase)
>  AlignedDouble* A = aligned_doubles( size * size );

>  for( size_t i = 0; i < size; ++i )
>  {
>printf( "i = %lu\n", i );
>for( size_t j = 0; j < size; ++j )
>{
>  A[j + i * size] += alpha;
>}
>  }

I checked the disassembly and found that the loop over j runs once cpompletely
and fails the second time, as a temporary pointer to A is incremented by i *
size, which will yield an unaligned pointer if size % 2 != 0 (or 4 with avx2).
However, if the alignment is directly used in the definition of A, without
using a typedef, the result is different. Looking at the output of
-fopt-info-loop the loop is peeled for alignment in this case.

With typedef:
>  gcc -O3 -g main.cpp -o main -fopt-info-loop
>  main.cpp:40:26: note: loop vectorized
>  main.cpp:40:26: note: loop turned into non-loop; it never loops
>  main.cpp:15:5: note: loop turned into non-loop; it never loops.
>  main.cpp:15:5: note: loop with 8 iterations completely unrolled

Without typedef:
>  gcc -O3 -g main.cpp -o main -fopt-info-loop
>  main.cpp:30:26: note: loop vectorized
>  main.cpp:30:26: note: loop peeled for vectorization to enhance alignment
>  main.cpp:30:26: note: loop turned into non-loop; it never loops
>  main.cpp:15:5: note: loop turned into non-loop; it never loops.
>  main.cpp:15:5: note: loop with 9 iterations completely unrolled
>  main.cpp:15:5: note: loop turned into non-loop; it never loops

In the attached test case you find for both scenarios the code, the binary, an
objdump, as well as outputs from -fopt-info-loop and -fopt-info-all. In the
objdum I marked the increment of A as well as the instruction where the
segmentation fault happens.

Please let me know if more info is needed. Thanks a lot for your time!

Best wishes,
Philipp Kopp

[Bug libstdc++/45896] [C++0x] Facet time_get not reading dates according to the IEEE 1003 standard.

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
(In reply to xyzdragon from comment #7)
> Had this bug when trying "%m" formatter on input "7" input. Saw the comment
> from 7 years ago "Can fix pretty quickly." and let out a desperate laugh. Is
> C++11 dead?

The next comment, just half an hour later, pointed out it wasn't as simple as
initially thought.

[Bug middle-end/81445] Dynamic stack allocation not optimized into static allocation

[glisse at gcc dot gnu.org]

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

--- Comment #6 from Marc Glisse  ---
(In reply to Wilco from comment #5)
> Also it doesn't support these simple cases:
> 
> void vla2(int x)
> {
>   if (x == 10)
>   {
> int arr[x];
> t (arr);
>   }
> }

Again, try something smaller. When the allocation is not always executed, the
threshold is even lower.

[Bug go/81449] runtime.inc:782:28: error: field ‘__sem_lock’ has incomplete type

[mfe at live dot de]

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

--- Comment #1 from martin  ---
Created attachment 41761
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41761=edit
runtime.inc

[Bug rtl-optimization/79856] rtl_verify_edges: use internal_error instead of error

[roland.illig at gmx dot de]

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

Roland Illig  changed:

   What|Removed |Added

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

--- Comment #10 from Roland Illig  ---
Fine.

Just FYI, the German translation already has all internal errors copied
verbatimly so they are not translated.

[Bug middle-end/81445] Dynamic stack allocation not optimized into static allocation

[wilco at gcc dot gnu.org]

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

--- Comment #5 from Wilco  ---
(In reply to Marc Glisse from comment #4)
> (In reply to Wilco from comment #2)
> > I don't see it happen for the simplest case in current trunk:
> 
> 400 bytes is too large, try again with something smaller. (I'm with you if
> you want to increase the threshold)

I see, it appears 256 bytes is the maximum, that's a bit low indeed. Note it
will statically allocate 100 arrays of 256 bytes but not 1 array of 25600
bytes...

Also it doesn't support these simple cases:

void vla2(int x)
{
  if (x == 10)
  {
int arr[x];
t (arr);
  }
}

void vla3(int x)
{
  if (x >= 0 && x <= 10)
  {
int arr[x];
t (arr);
  }
}

[Bug tree-optimization/81162] [8 Regression] UBSAN switch triggers incorrect optimization in SLSR

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

  Known to work||8.0

--- Comment #9 from Bill Schmidt  ---
Fixed in trunk so far.  Need to verify that backports are needed, but I suspect
they are.

[Bug tree-optimization/81162] [8 Regression] UBSAN switch triggers incorrect optimization in SLSR

[wschmidt at gcc dot gnu.org]

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

--- Comment #8 from Bill Schmidt  ---
Author: wschmidt
Date: Fri Jul 14 18:06:45 2017
New Revision: 250212

URL: https://gcc.gnu.org/viewcvs?rev=250212=gcc=rev
Log:
[gcc]

2016-07-14  Bill Schmidt  

PR tree-optimization/81162
* gimple-ssa-strength-reduction.c (replace_mult_candidate): Don't
replace a negate with an add.

[gcc/testsuite]

2016-07-14  Bill Schmidt  

PR tree-optimization/81162
* gcc.dg/pr81162.c: New file.


Added:
trunk/gcc/testsuite/gcc.dg/pr81162.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-strength-reduction.c
trunk/gcc/testsuite/ChangeLog

[Bug go/81449] New: runtime.inc:782:28: error: field ‘__sem_lock’ has incomplete type

[mfe at live dot de]

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

Bug ID: 81449
   Summary: runtime.inc:782:28: error: field ‘__sem_lock’ has
incomplete type
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: mfe at live dot de
CC: cmang at google dot com
  Target Milestone: ---

the exact version of GCC:
gcc-7.1.0

the system type:
NetgearReadyNAS Duo (http://netgear.nas-central.org/wiki/Category:ReadyNasDUO)

the options given when GCC was configured/built:
configure CC=/opt/gcc-4.6/bin/gcc CXX=/opt/gcc-4.6/bin/g++
--enable-languages=c,c++,go --prefix=/opt/gcc-7.1  --with-cpu=v7
--with-mpc=/usr/local  --with-mpfr=/usr/local --with-gmp=/usr/local
--with-isl=/usr/local/ --disable-libstdcxx-pch 

the complete command line that triggers the bug;
/usr/local/bin/make

the compiler output (error messages, warnings, etc.);
[...]
/media/gcc-7.1-compiled/./gcc/xgcc -B/media/gcc-7.1-compiled/./gcc/
-B/opt/gcc-7.1/sparc-unknown-linux-gnu/bin/
-B/opt/gcc-7.1/sparc-unknown-linux-gnu/lib/ -isystem
/opt/gcc-7.1/sparc-unknown-linux-gnu/include -isystem
/opt/gcc-7.1/sparc-unknown-linux-gnu/sys-include-DHAVE_CONFIG_H -I.
-I../../../gcc-7.1.0/libgo  -I ../../../gcc-7.1.0/libgo/runtime
-I../../../gcc-7.1.0/libgo/../libffi/include -I../libffi/include -pthread 
-fexceptions -fnon-call-exceptions -fplan9-extensions  -Wall -Wextra
-Wwrite-strings -Wcast-qual -Werror   -D_GNU_SOURCE -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -I ../../../gcc-7.1.0/libgo/../libgcc -I
../../../gcc-7.1.0/libgo/../libbacktrace -I ../../gcc/include -fPIC -g -O2 -MT
libgobegin_a-go-main.o -MD -MP -MF .deps/libgobegin_a-go-main.Tpo -c -o
libgobegin_a-go-main.o `test -f 'runtime/go-main.c' || echo
'../../../gcc-7.1.0/libgo/'`runtime/go-main.c
In file included from ../../../gcc-7.1.0/libgo/runtime/runtime.h:113:0,
 from ../../../gcc-7.1.0/libgo/runtime/go-main.c:17:
./runtime.inc:782:28: error: field ‘__sem_lock’ has incomplete type
  struct __pthread_fastlock __sem_lock;
^~
make[4]: *** [Makefile:1580: libgobegin_a-go-main.o] Error 1
make[4]: Leaving directory
'/c/media/gcc-7.1-compiled/sparc-unknown-linux-gnu/libgo'
make[3]: *** [Makefile:2746: all-recursive] Error 1
make[3]: Leaving directory
'/c/media/gcc-7.1-compiled/sparc-unknown-linux-gnu/libgo'
make[2]: *** [Makefile:1344: all] Error 2
make[2]: Leaving directory
'/c/media/gcc-7.1-compiled/sparc-unknown-linux-gnu/libgo'
make[1]: *** [Makefile:20030: all-target-libgo] Error 2
make[1]: Leaving directory '/c/media/gcc-7.1-compiled'
make: *** [Makefile:934: all] Error 2

If this bug is related to #81421, I apologize for the inconvenience and I will
set the bug status to invalid.

[Bug go/81421] Circular runtime.s-gox -> runtime.lo dependency dropped -> objcopy: 'runtime.s-gox.tmp': No such file

[mfe at live dot de]

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

martin  changed:

   What|Removed |Added

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

--- Comment #18 from martin  ---
Thanks for your hint. I reinstalled grep which fixed the issue.
grep/egrep/fgrep is now on version 2.15 and the symlinks disappeared.

[Bug c++/71504] bogus error: accessing value through a glvalue in a constant expression

[kot.tom97 at gmail dot com]

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

Tom Westerhout  changed:

   What|Removed |Added

 CC||kot.tom97 at gmail dot com

--- Comment #2 from Tom Westerhout  ---
Hi!


I'm working on a library that does a lot of work inside constexpr
functions. In simple cases like the example above it's relatively easy
to avoid this bug. In real life, however, it's almost impossible.

Although this bug is not considered important, it it important for
me. Currently, it is the only reason my library doesn't work with GCC.
I'd really appreciate it if this bug was assigned to someone. If there
are no volunteers, I'd be happy to help myself. Unfortunately, I'm not
familiar with GCC's code base at all. So some pointers to where I can
get started would be very helpful.


Tom

[Bug target/81300] -fpeephole2 breaks __builtin_ia32_sbb_u64, _subborrow_u64 on AMD64

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Target|x86-*-* |x86
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |5.5

--- Comment #6 from Uroš Bizjak  ---
Fixed.

[Bug target/81375] [6/7/8 Regression] unrecognizable insn

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|6.5 |5.5

--- Comment #6 from Uroš Bizjak  ---
Fixed.

[Bug c/81448] False positive -Werror=multistatement-macros in openssl

[bernd.edlinger at hotmail dot de]

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

--- Comment #4 from Bernd Edlinger  ---
(In reply to Marek Polacek from comment #3)
> Guess we'll need the PR81364 fix for that.

Yes, although it would be good to require
a "{" only if cprefix##_ecb_encrypt(...) actually expands
to multiple stmts, if it expands to single stmt as here
BLOCK_CIPHER_ecb_loop() would be usable like for(;;)

[Bug target/81375] [6/7/8 Regression] unrecognizable insn

[uros at gcc dot gnu.org]

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

--- Comment #5 from uros at gcc dot gnu.org ---
Author: uros
Date: Fri Jul 14 17:19:30 2017
New Revision: 250211

URL: https://gcc.gnu.org/viewcvs?rev=250211=gcc=rev
Log:
Backport from mainline
2017-07-10  Uros Bizjak  

PR target/81375
* config/i386/i386.md (divsf3): Add TARGET_SSE to TARGET_SSE_MATH.
(rcpps): Ditto.
(*rsqrtsf2_sse): Ditto.
(rsqrtsf2): Ditto.
(div3): Macroize insn from divdf3 and divsf3
using MODEF mode iterator.

Backport from mainline
2017-07-04  Uros Bizjak  

PR target/81300
* config/i386/i386.md (setcc + movzbl/and to xor + setcc peepholes):
Require dead FLAGS_REG at the beginning of a peephole.

testsuite/ChangeLog:

Backport from mainline
2017-07-10  Uros Bizjak  

PR target/81375
* gcc.target/i386/pr81375.c: New test.

Backport from mainline
2017-07-04  Uros Bizjak  

PR target/81300
* gcc.target/i386/pr81300.c: New test.


Added:
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/pr81300.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/pr81375.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/i386/i386.md
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug target/81300] -fpeephole2 breaks __builtin_ia32_sbb_u64, _subborrow_u64 on AMD64

[uros at gcc dot gnu.org]

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

--- Comment #5 from uros at gcc dot gnu.org ---
Author: uros
Date: Fri Jul 14 17:19:30 2017
New Revision: 250211

URL: https://gcc.gnu.org/viewcvs?rev=250211=gcc=rev
Log:
Backport from mainline
2017-07-10  Uros Bizjak  

PR target/81375
* config/i386/i386.md (divsf3): Add TARGET_SSE to TARGET_SSE_MATH.
(rcpps): Ditto.
(*rsqrtsf2_sse): Ditto.
(rsqrtsf2): Ditto.
(div3): Macroize insn from divdf3 and divsf3
using MODEF mode iterator.

Backport from mainline
2017-07-04  Uros Bizjak  

PR target/81300
* config/i386/i386.md (setcc + movzbl/and to xor + setcc peepholes):
Require dead FLAGS_REG at the beginning of a peephole.

testsuite/ChangeLog:

Backport from mainline
2017-07-10  Uros Bizjak  

PR target/81375
* gcc.target/i386/pr81375.c: New test.

Backport from mainline
2017-07-04  Uros Bizjak  

PR target/81300
* gcc.target/i386/pr81300.c: New test.


Added:
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/pr81300.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/pr81375.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/i386/i386.md
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/81346] Missed constant propagation into comparison

[glisse at gcc dot gnu.org]

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

--- Comment #10 from Marc Glisse  ---
(In reply to Jakub Jelinek from comment #9)
> (In reply to Marc Glisse from comment #8)
> > I think always using an unsigned type for the range check would be simpler.
> > If we try to check that x>=INT_MIN+2 && x<=INT_MAX-2 with -fwrapv, int is
> > still not a suitable type in which to do
> > x-(INT_MIN+2)<=INT_MAX-2-(INT_MIN+2), while the issue doesn't exist with an
> > unsigned type.
> 
> I'm trying to preserve what we did before, it can be tweaked incrementally
> if needed.

Then you may need to check for overflow in "hi = const_binop (MINUS_EXPR,
etype, hi, lo);", current build_range_check has "if (value != 0 &&
!TREE_OVERFLOW (value))" for the result of that operation. That should matter
for instance when simplifying X/INT_MAX==0.

[Bug c/81448] False positive -Werror=multistatement-macros in openssl

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Guess we'll need the PR81364 fix for that.

[Bug middle-end/81445] Dynamic stack allocation not optimized into static allocation

[glisse at gcc dot gnu.org]

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

--- Comment #4 from Marc Glisse  ---
(In reply to Wilco from comment #2)
> I don't see it happen for the simplest case in current trunk:

400 bytes is too large, try again with something smaller. (I'm with you if you
want to increase the threshold)

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

[kelvin at gcc dot gnu.org]

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

--- Comment #13 from kelvin at gcc dot gnu.org ---
Author: kelvin
Date: Fri Jul 14 16:58:00 2017
New Revision: 250210

URL: https://gcc.gnu.org/viewcvs?rev=250210=gcc=rev
Log:
gcc/ChangeLog:

2017-07-14  Kelvin Nilsen  

Backports from trunk

2017-03-23  Kelvin Nilsen  
* config/rs6000/rs6000.c (rs6000_option_override_internal): Change
handling of certain combinations of target options, including the
combinations -mpower8-vector vs. -mno-vsx, -mpower8-vector vs.
-mno-power8-vector, and -mpower9_dform vs. -mno-power9-vector.

2017-03-27  Kelvin Nilsen  
PR target/80103
* config/rs6000/rs6000.c (rs6000_option_override_internal): Add
special handling for target option conflicts between dform options
(-mpower9-dform, -mpower9-dform-vector, -mpower9-dform-scalar) and
-mno-direct-move.

2017-05-08  Kelvin Nilsen  
PR target/80101
* config/rs6000/power6.md: Replace store_data_bypass_p calls with
rs6000_store_data_bypass_p in seven define_bypass directives and
in several comments.
* config/rs6000/rs6000-protos.h: Add prototype for
rs6000_store_data_bypass_p function.
* config/rs6000/rs6000.c (rs6000_store_data_bypass_p): New
function implements slightly different (rs6000-specific) semantics
than store_data_bypass_p, returning false rather than aborting
with assertion error when arguments do not satisfy the
requirements of store data bypass.
(rs6000_adjust_cost): Replace six calls of store_data_bypass_p with
rs6000_store_data_bypass_p.

gcc/testsuite/ChangeLog:

2017-07-14  Kelvin Nilsen  

Backports from trunk:

2017-01-23  Kelvin Nilsen  
PR target/9
* gcc.dg/loop-8.c: Modify dg-skip-if directive to exclude this
test on powerpc targets.

2017-02-08  Kelvin Nilsen  
PR target/68972
* g++.dg/cpp1y/vla-initlist1.C: Add dg-skip-if directive to
disable this test on power architecture.

2017-03-23  Kelvin Nilsen  
* gcc.target/powerpc/p9-options-1.c: New test.

2017-03-27  Kelvin Nilsen  
PR target/80103
* gcc.target/powerpc/pr80103-1.c: New test.

2017-05-08  Kelvin Nilsen  
PR target/80101
* gcc.target/powerpc/pr80101-1.c: New test.

2017-07-05  Kelvin Nilsen  
PR target/80103
* gcc.target/powerpc/pr80103-1.c (b): Correct spelling of
__attribute__.


Added:
branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/p9-options-1.c
branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/pr80101-1.c
branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/pr80103-1.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/rs6000/power6.md
branches/gcc-6-branch/gcc/config/rs6000/rs6000-protos.h
branches/gcc-6-branch/gcc/config/rs6000/rs6000.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/testsuite/g++.dg/cpp1y/vla-initlist1.C
branches/gcc-6-branch/gcc/testsuite/gcc.dg/loop-8.c

[Bug rtl-optimization/66669] FAIL: gcc.dg/loop-8.c

[kelvin at gcc dot gnu.org]

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

--- Comment #6 from kelvin at gcc dot gnu.org ---
Author: kelvin
Date: Fri Jul 14 16:58:00 2017
New Revision: 250210

URL: https://gcc.gnu.org/viewcvs?rev=250210=gcc=rev
Log:
gcc/ChangeLog:

2017-07-14  Kelvin Nilsen  

Backports from trunk

2017-03-23  Kelvin Nilsen  
* config/rs6000/rs6000.c (rs6000_option_override_internal): Change
handling of certain combinations of target options, including the
combinations -mpower8-vector vs. -mno-vsx, -mpower8-vector vs.
-mno-power8-vector, and -mpower9_dform vs. -mno-power9-vector.

2017-03-27  Kelvin Nilsen  
PR target/80103
* config/rs6000/rs6000.c (rs6000_option_override_internal): Add
special handling for target option conflicts between dform options
(-mpower9-dform, -mpower9-dform-vector, -mpower9-dform-scalar) and
-mno-direct-move.

2017-05-08  Kelvin Nilsen  
PR target/80101
* config/rs6000/power6.md: Replace store_data_bypass_p calls with
rs6000_store_data_bypass_p in seven define_bypass directives and
in several comments.
* config/rs6000/rs6000-protos.h: Add prototype for
rs6000_store_data_bypass_p function.
* config/rs6000/rs6000.c (rs6000_store_data_bypass_p): New
function implements slightly different (rs6000-specific) semantics
than store_data_bypass_p, returning false rather than aborting
with assertion error when arguments do not satisfy the
requirements of store data bypass.
(rs6000_adjust_cost): Replace six calls of store_data_bypass_p with
rs6000_store_data_bypass_p.

gcc/testsuite/ChangeLog:

2017-07-14  Kelvin Nilsen  

Backports from trunk:

2017-01-23  Kelvin Nilsen  
PR target/9
* gcc.dg/loop-8.c: Modify dg-skip-if directive to exclude this
test on powerpc targets.

2017-02-08  Kelvin Nilsen  
PR target/68972
* g++.dg/cpp1y/vla-initlist1.C: Add dg-skip-if directive to
disable this test on power architecture.

2017-03-23  Kelvin Nilsen  
* gcc.target/powerpc/p9-options-1.c: New test.

2017-03-27  Kelvin Nilsen  
PR target/80103
* gcc.target/powerpc/pr80103-1.c: New test.

2017-05-08  Kelvin Nilsen  
PR target/80101
* gcc.target/powerpc/pr80101-1.c: New test.

2017-07-05  Kelvin Nilsen  
PR target/80103
* gcc.target/powerpc/pr80103-1.c (b): Correct spelling of
__attribute__.


Added:
branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/p9-options-1.c
branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/pr80101-1.c
branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/pr80103-1.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/rs6000/power6.md
branches/gcc-6-branch/gcc/config/rs6000/rs6000-protos.h
branches/gcc-6-branch/gcc/config/rs6000/rs6000.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/testsuite/g++.dg/cpp1y/vla-initlist1.C
branches/gcc-6-branch/gcc/testsuite/gcc.dg/loop-8.c

[Bug target/80101] ICE in store_data_bypass_p, at recog.c:3737

[kelvin at gcc dot gnu.org]

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

--- Comment #3 from kelvin at gcc dot gnu.org ---
Author: kelvin
Date: Fri Jul 14 16:58:00 2017
New Revision: 250210

URL: https://gcc.gnu.org/viewcvs?rev=250210=gcc=rev
Log:
gcc/ChangeLog:

2017-07-14  Kelvin Nilsen  

Backports from trunk

2017-03-23  Kelvin Nilsen  
* config/rs6000/rs6000.c (rs6000_option_override_internal): Change
handling of certain combinations of target options, including the
combinations -mpower8-vector vs. -mno-vsx, -mpower8-vector vs.
-mno-power8-vector, and -mpower9_dform vs. -mno-power9-vector.

2017-03-27  Kelvin Nilsen  
PR target/80103
* config/rs6000/rs6000.c (rs6000_option_override_internal): Add
special handling for target option conflicts between dform options
(-mpower9-dform, -mpower9-dform-vector, -mpower9-dform-scalar) and
-mno-direct-move.

2017-05-08  Kelvin Nilsen  
PR target/80101
* config/rs6000/power6.md: Replace store_data_bypass_p calls with
rs6000_store_data_bypass_p in seven define_bypass directives and
in several comments.
* config/rs6000/rs6000-protos.h: Add prototype for
rs6000_store_data_bypass_p function.
* config/rs6000/rs6000.c (rs6000_store_data_bypass_p): New
function implements slightly different (rs6000-specific) semantics
than store_data_bypass_p, returning false rather than aborting
with assertion error when arguments do not satisfy the
requirements of store data bypass.
(rs6000_adjust_cost): Replace six calls of store_data_bypass_p with
rs6000_store_data_bypass_p.

gcc/testsuite/ChangeLog:

2017-07-14  Kelvin Nilsen  

Backports from trunk:

2017-01-23  Kelvin Nilsen  
PR target/9
* gcc.dg/loop-8.c: Modify dg-skip-if directive to exclude this
test on powerpc targets.

2017-02-08  Kelvin Nilsen  
PR target/68972
* g++.dg/cpp1y/vla-initlist1.C: Add dg-skip-if directive to
disable this test on power architecture.

2017-03-23  Kelvin Nilsen  
* gcc.target/powerpc/p9-options-1.c: New test.

2017-03-27  Kelvin Nilsen  
PR target/80103
* gcc.target/powerpc/pr80103-1.c: New test.

2017-05-08  Kelvin Nilsen  
PR target/80101
* gcc.target/powerpc/pr80101-1.c: New test.

2017-07-05  Kelvin Nilsen  
PR target/80103
* gcc.target/powerpc/pr80103-1.c (b): Correct spelling of
__attribute__.


Added:
branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/p9-options-1.c
branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/pr80101-1.c
branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/pr80103-1.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/rs6000/power6.md
branches/gcc-6-branch/gcc/config/rs6000/rs6000-protos.h
branches/gcc-6-branch/gcc/config/rs6000/rs6000.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/testsuite/g++.dg/cpp1y/vla-initlist1.C
branches/gcc-6-branch/gcc/testsuite/gcc.dg/loop-8.c

[Bug target/80103] ICE in output_1144, at config/rs6000/vsx.md:2298

[kelvin at gcc dot gnu.org]

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

--- Comment #5 from kelvin at gcc dot gnu.org ---
Author: kelvin
Date: Fri Jul 14 16:58:00 2017
New Revision: 250210

URL: https://gcc.gnu.org/viewcvs?rev=250210=gcc=rev
Log:
gcc/ChangeLog:

2017-07-14  Kelvin Nilsen  

Backports from trunk

2017-03-23  Kelvin Nilsen  
* config/rs6000/rs6000.c (rs6000_option_override_internal): Change
handling of certain combinations of target options, including the
combinations -mpower8-vector vs. -mno-vsx, -mpower8-vector vs.
-mno-power8-vector, and -mpower9_dform vs. -mno-power9-vector.

2017-03-27  Kelvin Nilsen  
PR target/80103
* config/rs6000/rs6000.c (rs6000_option_override_internal): Add
special handling for target option conflicts between dform options
(-mpower9-dform, -mpower9-dform-vector, -mpower9-dform-scalar) and
-mno-direct-move.

2017-05-08  Kelvin Nilsen  
PR target/80101
* config/rs6000/power6.md: Replace store_data_bypass_p calls with
rs6000_store_data_bypass_p in seven define_bypass directives and
in several comments.
* config/rs6000/rs6000-protos.h: Add prototype for
rs6000_store_data_bypass_p function.
* config/rs6000/rs6000.c (rs6000_store_data_bypass_p): New
function implements slightly different (rs6000-specific) semantics
than store_data_bypass_p, returning false rather than aborting
with assertion error when arguments do not satisfy the
requirements of store data bypass.
(rs6000_adjust_cost): Replace six calls of store_data_bypass_p with
rs6000_store_data_bypass_p.

gcc/testsuite/ChangeLog:

2017-07-14  Kelvin Nilsen  

Backports from trunk:

2017-01-23  Kelvin Nilsen  
PR target/9
* gcc.dg/loop-8.c: Modify dg-skip-if directive to exclude this
test on powerpc targets.

2017-02-08  Kelvin Nilsen  
PR target/68972
* g++.dg/cpp1y/vla-initlist1.C: Add dg-skip-if directive to
disable this test on power architecture.

2017-03-23  Kelvin Nilsen  
* gcc.target/powerpc/p9-options-1.c: New test.

2017-03-27  Kelvin Nilsen  
PR target/80103
* gcc.target/powerpc/pr80103-1.c: New test.

2017-05-08  Kelvin Nilsen  
PR target/80101
* gcc.target/powerpc/pr80101-1.c: New test.

2017-07-05  Kelvin Nilsen  
PR target/80103
* gcc.target/powerpc/pr80103-1.c (b): Correct spelling of
__attribute__.


Added:
branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/p9-options-1.c
branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/pr80101-1.c
branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/pr80103-1.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/rs6000/power6.md
branches/gcc-6-branch/gcc/config/rs6000/rs6000-protos.h
branches/gcc-6-branch/gcc/config/rs6000/rs6000.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/testsuite/g++.dg/cpp1y/vla-initlist1.C
branches/gcc-6-branch/gcc/testsuite/gcc.dg/loop-8.c

[Bug tree-optimization/81346] Missed constant propagation into comparison

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
(In reply to Marc Glisse from comment #8)
> I think always using an unsigned type for the range check would be simpler.
> If we try to check that x>=INT_MIN+2 && x<=INT_MAX-2 with -fwrapv, int is
> still not a suitable type in which to do
> x-(INT_MIN+2)<=INT_MAX-2-(INT_MIN+2), while the issue doesn't exist with an
> unsigned type.

I'm trying to preserve what we did before, it can be tweaked incrementally if
needed.

> I notice you call build_range_check in GENERIC (and new code for GIMPLE). Is
> that temporary until match.pd can optimize range checks?

As long as we keep build_range_check, which is used in multiple other places in
fold-const.c as well as the reassoc pass, using that for GENERIC looks
faster/simpler than emitting the comparison and then optimizing it.

> Do we want :s on trunc_div?

Yes, will do that.

[Bug c/81448] False positive -Werror=multistatement-macros in openssl

[bernd.edlinger at hotmail dot de]

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

--- Comment #2 from Bernd Edlinger  ---
Not really:

diff --git a/crypto/evp/evp_locl.h b/crypto/evp/evp_locl.h
index 2bb709a..cb44ed8 100644
--- a/crypto/evp/evp_locl.h
+++ b/crypto/evp/evp_locl.h
@@ -71,8 +71,9 @@
 #define BLOCK_CIPHER_func_ecb(cname, cprefix, kstruct, ksched) \
 static int cname##_ecb_cipher(EVP_CIPHER_CTX *ctx, unsigned char *out, const
unsigned char *in, size_t inl) \
 {\
-BLOCK_CIPHER_ecb_loop() \
+BLOCK_CIPHER_ecb_loop() { \
 cprefix##_ecb_encrypt(in + i, out + i, &((kstruct
*)ctx->cipher_data)->ksched, ctx->encrypt);\
+} \
 return 1;\
 }

In file included from e_bf.c:63:0:
e_bf.c: In function 'bf_ecb_cipher':
evp_locl.h:74:33: error: macro expands to multiple statements
[-Werror=multistatement-macros]
 BLOCK_CIPHER_ecb_loop() { \
 ^
evp_locl.h:132:9: note: in expansion of macro 'BLOCK_CIPHER_func_ecb'
 BLOCK_CIPHER_func_ecb(cname, cprefix, kstruct, ksched) \
 ^
evp_locl.h:251:9: note: in expansion of macro 'BLOCK_CIPHER_all_funcs'
 BLOCK_CIPHER_all_funcs(cname, cprefix, cbits, kstruct, ksched) \
 ^~
e_bf.c:76:1: note: in expansion of macro 'IMPLEMENT_BLOCK_CIPHER'
 IMPLEMENT_BLOCK_CIPHER(bf, ks, BF, EVP_BF_KEY, NID_bf, 8, 16, 8, 64,
 ^~
evp_locl.h:69:9: note: some parts of macro expansion are not guarded by this
'for' clause
 for(i=0; i <= inl; i+=bl)
 ^~~
evp_locl.h:74:9: note: in expansion of macro 'BLOCK_CIPHER_ecb_loop'
 BLOCK_CIPHER_ecb_loop() { \
 ^
evp_locl.h:132:9: note: in expansion of macro 'BLOCK_CIPHER_func_ecb'
 BLOCK_CIPHER_func_ecb(cname, cprefix, kstruct, ksched) \
 ^
evp_locl.h:251:9: note: in expansion of macro 'BLOCK_CIPHER_all_funcs'
 BLOCK_CIPHER_all_funcs(cname, cprefix, cbits, kstruct, ksched) \
 ^~
e_bf.c:76:1: note: in expansion of macro 'IMPLEMENT_BLOCK_CIPHER'
 IMPLEMENT_BLOCK_CIPHER(bf, ks, BF, EVP_BF_KEY, NID_bf, 8, 16, 8, 64,
 ^~

[Bug c++/80935] [C++1z] incorrect error 'uninitialized variable in constexpr function' when conditionally declaring variable inside lambda inside template class

[andrew.kw.w at gmail dot com]

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

Andrew Wong  changed:

   What|Removed |Added

 CC||andrew.kw.w at gmail dot com

--- Comment #1 from Andrew Wong  ---
I am also running into this issue on g++ 7.1.0, and I can reproduce the error
using the attached code.

[Bug tree-optimization/81346] Missed constant propagation into comparison

[glisse at gcc dot gnu.org]

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

--- Comment #8 from Marc Glisse  ---
I think always using an unsigned type for the range check would be simpler. If
we try to check that x>=INT_MIN+2 && x<=INT_MAX-2 with -fwrapv, int is still
not a suitable type in which to do x-(INT_MIN+2)<=INT_MAX-2-(INT_MIN+2), while
the issue doesn't exist with an unsigned type.
I notice you call build_range_check in GENERIC (and new code for GIMPLE). Is
that temporary until match.pd can optimize range checks?
Do we want :s on trunc_div?

[Bug go/81421] Circular runtime.s-gox -> runtime.lo dependency dropped -> objcopy: 'runtime.s-gox.tmp': No such file

[ian at airs dot com]

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

--- Comment #17 from Ian Lance Taylor  ---
Thanks.  I have no recommendation.  I can not explain why your version of grep
behaves differently than mine, and, since nobody else has reported this bug,
apparently differently than everyone else's.

I do notice one interesting thing, which is that earlier you said

> grep --version
> egrep (GNU grep) 2.4.2

On my system running `grep --version` prints

grep (GNU grep) 2.16

(plus a copyright notice) and running `egrep --version` prints

egrep (GNU grep) 2.16

It's interesting that on your system `grep --version` prints "egrep" rather
than "grep".  If your "grep" program is somehow really "egrep", that would
explain the problem you are seeing.  But I don't know how that could happen.

[Bug go/81421] Circular runtime.s-gox -> runtime.lo dependency dropped -> objcopy: 'runtime.s-gox.tmp': No such file

[mfe at live dot de]

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

--- Comment #16 from martin  ---
For clarification the duplicate of "/go/runtime/mksizeclasses.go > FILE" was a
copy paste mistake.

[Bug middle-end/81445] Dynamic stack allocation not optimized into static allocation

[wilco at gcc dot gnu.org]

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

--- Comment #3 from Wilco  ---
There is also something buggy with the way alloca aligns, it always allocates
16 bytes too much...

[Bug go/81421] Circular runtime.s-gox -> runtime.lo dependency dropped -> objcopy: 'runtime.s-gox.tmp': No such file

[mfe at live dot de]

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

--- Comment #15 from martin  ---
You are right!
I did:

sed '/^package /q' < /media/gcc-7.1.0/libgo/go/runtime/mksizeclasses.go > FILE 
   
   /go/runtime/mksizeclasses.go > FILE

The grep command "grep '^// +build ' FILE"  printed nothing.

Also egrep and fgrep are symlinks to 
grep: /bin/grep
whereis egrep
egrep: /bin/egrep
ls /bin/egrep -lah
lrwxrwxrwx1 root root Jun 29 11:42 /bin/egrep -> grep
ls /bin/fgrep -lah
lrwxrwxrwx1 root root Jun 29 11:42 /bin/fgrep -> grep

The command env doesn't list GREP_OPTIONS.

[Bug middle-end/81445] Dynamic stack allocation not optimized into static allocation

[wilco at gcc dot gnu.org]

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

--- Comment #2 from Wilco  ---
(In reply to Marc Glisse from comment #1)
> Note that we already do it for VLA (aka BUILT_IN_ALLOCA_WITH_ALIGN) in CCP.

I don't see it happen for the simplest case in current trunk:

void t(int *);
void vla(void)
{
  int x = 100;
  int arr[x];
  t (arr);
}

void no_vla(void)
{
  int arr[100];
  t (arr);
}

vla:
stp x29, x30, [sp, -16]!
add x29, sp, 0
sub sp, sp, #416   // alloca
mov x0, sp
bl  t
add sp, x29, 0
ldp x29, x30, [sp], 16
ret

no_vla:
stp x29, x30, [sp, -416]!
add x29, sp, 0
add x0, sp, 16
bl  t
ldp x29, x30, [sp], 416
ret

[Bug c/81448] False positive -Werror=multistatement-macros in openssl

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
To me it seems the warning is doing what it should here, simply wrapping the
body of the for loop into {} should fix it.

[Bug c/81448] New: False positive -Werror=multistatement-macros in openssl

[bernd.edlinger at hotmail dot de]

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

Bug ID: 81448
   Summary: False positive -Werror=multistatement-macros in
openssl
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bernd.edlinger at hotmail dot de
  Target Milestone: ---

building openssl with ./config --strict-warnings
fails due to -Werror=multistatement-macros
I see no obvious way how to work around that:

gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include 
-DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -Wa,--noexecstack
-m64 -DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT
-DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DRC4_ASM -DSHA1_ASM -DSHA256_ASM
-DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM
-DGHASH_ASM -DECP_NISTZ256_ASM -pedantic -DPEDANTIC -Wno-long-long
-Wsign-compare -Wmissing-prototypes -Wshadow -Wformat -Wundef -Werror
-DCRYPTO_MDEBUG_ALL -DCRYPTO_MDEBUG_ABORT -DREF_CHECK -DOPENSSL_NO_DEPRECATED  
-c -o e_bf.o e_bf.c
In file included from e_bf.c:63:0:
e_bf.c: In function 'bf_ecb_cipher':
e_bf.c:76:32: error: macro expands to multiple statements
[-Werror=multistatement-macros]
 IMPLEMENT_BLOCK_CIPHER(bf, ks, BF, EVP_BF_KEY, NID_bf, 8, 16, 8, 64,
^~
evp_locl.h:75:17: note: in definition of macro 'BLOCK_CIPHER_func_ecb'
 cprefix##_ecb_encrypt(in + i, out + i, &((kstruct
*)ctx->cipher_data)->ksched, ctx->encrypt);\
 ^~~
evp_locl.h:250:9: note: in expansion of macro 'BLOCK_CIPHER_all_funcs'
 BLOCK_CIPHER_all_funcs(cname, cprefix, cbits, kstruct, ksched) \
 ^~
e_bf.c:76:1: note: in expansion of macro 'IMPLEMENT_BLOCK_CIPHER'
 IMPLEMENT_BLOCK_CIPHER(bf, ks, BF, EVP_BF_KEY, NID_bf, 8, 16, 8, 64,
 ^~
evp_locl.h:69:9: note: some parts of macro expansion are not guarded by this
'for' clause
 for(i=0; i <= inl; i+=bl)
 ^~~
evp_locl.h:74:9: note: in expansion of macro 'BLOCK_CIPHER_ecb_loop'
 BLOCK_CIPHER_ecb_loop() \
 ^
evp_locl.h:131:9: note: in expansion of macro 'BLOCK_CIPHER_func_ecb'
 BLOCK_CIPHER_func_ecb(cname, cprefix, kstruct, ksched) \
 ^
evp_locl.h:250:9: note: in expansion of macro 'BLOCK_CIPHER_all_funcs'
 BLOCK_CIPHER_all_funcs(cname, cprefix, cbits, kstruct, ksched) \
 ^~
e_bf.c:76:1: note: in expansion of macro 'IMPLEMENT_BLOCK_CIPHER'
 IMPLEMENT_BLOCK_CIPHER(bf, ks, BF, EVP_BF_KEY, NID_bf, 8, 16, 8, 64,
 ^~
cc1: all warnings being treated as errors
make[2]: *** [e_bf.o] Error 1
make[2]: Leaving directory `/home/ed/OPC/openssl/crypto/evp'
make[1]: *** [subdirs] Error 1
make[1]: Leaving directory `/home/ed/OPC/openssl/crypto'
make: *** [build_crypto] Error 1

this is in evp_locl.h (as of openssl 1.0.2):

#define BLOCK_CIPHER_ecb_loop() \
size_t i, bl; \
bl = ctx->cipher->block_size;\
if(inl < bl) return 1;\
inl -= bl; \
for(i=0; i <= inl; i+=bl)

#define BLOCK_CIPHER_func_ecb(cname, cprefix, kstruct, ksched) \
static int cname##_ecb_cipher(EVP_CIPHER_CTX *ctx, unsigned char *out, const
unsigned char *in, size_t inl) \
{\
BLOCK_CIPHER_ecb_loop() \
cprefix##_ecb_encrypt(in + i, out + i, &((kstruct
*)ctx->cipher_data)->ksched, ctx->encrypt);\
return 1;\
}


and cprefix##_ecb_encrypt expands to BF_ecb_encrypt which
is a single function call.

[Bug go/81421] Circular runtime.s-gox -> runtime.lo dependency dropped -> objcopy: 'runtime.s-gox.tmp': No such file

[ian at airs dot com]

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

--- Comment #14 from Ian Lance Taylor  ---
OK, so the sed command works.  Run the sed command redirecting standard output
to a file, then see what this prints:

grep '^// +build ' FILE

It sounds like that will print nothing.  The only way I could explain that
would be if your grep command acts like either fgrep or egrep rather than
normal grep.

Do you have GREP_OPTIONS set in your environment?  Do you have any symlink from
grep to egrep or fgrep?

[Bug ada/81446] Building Ada on Linux m68k fails due to missing No_Elaboration_Code_All

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #1 from John Paul Adrian Glaubitz  ---
I can confirm that the previously suggested patch fixes the issue.

[Bug middle-end/81445] Dynamic stack allocation not optimized into static allocation

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
Note that we already do it for VLA (aka BUILT_IN_ALLOCA_WITH_ALIGN) in CCP.

[Bug fortran/81447] New: gfortran fails to recognize the exact dynamic type of a polymorphic entity that was allocated in a external procedure

[mathewc at nag dot co.uk]

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

Bug ID: 81447
   Summary: gfortran fails to recognize the exact dynamic type of
a polymorphic entity that was allocated in a external
procedure
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mathewc at nag dot co.uk
  Target Milestone: ---

> uname -a && gfortran --version && cat foo.f90 && gfortran foo.f90 && ./a.out
Linux cuivienen.nag.co.uk 4.11.9-300.fc26.x86_64 #1 SMP Wed Jul 5 16:21:56 UTC
2017 x86_64 x86_64 x86_64 GNU/Linux
GNU Fortran (GCC) 7.1.1 20170622 (Red Hat 7.1.1-3)
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Module m
  Type :: t
  End Type
End Module
Program p
  Use m
  Class (t), Allocatable :: x
  Interface
Subroutine s(x)
  Use m
  Class (t), Allocatable :: x
End Subroutine
  End Interface
  Call s(x)
  Select Type (x)
  Type Is (t)
Continue
  Class Is (t)
Stop 'Inconceivable t'
  Class Default
Stop 'Inconceivable *'
  End Select
  Print *, 'ok'
End Program
Subroutine s(x)
  Use m, Only: t
  Implicit None
  Class (t), Allocatable :: x
  Allocate (t :: x)
End Subroutine
STOP Inconceivable t

Note that the version with s internal to p is OK:

Module m
  Type :: t
  End Type
End Module
Program p
  Use m
  Class (t), Allocatable :: x
  Call s(x)
  Select Type (x)
  Type Is (t)
Continue
  Class Is (t)
Stop 'Inconceivable t'
  Class Default
Stop 'Inconceivable *'
  End Select
  Print *, 'ok'
Contains
  Subroutine s(x)
Use m, Only: t
Implicit None
Class (t), Allocatable :: x
Allocate (t :: x)
  End Subroutine
End Program
 ok

[Bug go/81421] Circular runtime.s-gox -> runtime.lo dependency dropped -> objcopy: 'runtime.s-gox.tmp': No such file

[mfe at live dot de]

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

--- Comment #13 from martin  ---
Thanks for the fast reply.
It prints:

nas-02-90-38:/media/gcc-7.1.0/libgo# sed '/^package /q' <
/media/gcc-7.1.0/libgo/go/runtime/mksizeclasses.go
// Copyright 2016 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.

// +build ignore

// Generate tables for small malloc size classes.
//
// See malloc.go for overview.
//
// The size classes are chosen so that rounding an allocation
// request up to the next size class wastes at most 12.5% (1.125x).
//
// Each size class has its own page count that gets allocated
// and chopped up when new objects of the size class are needed.
// That page count is chosen so that chopping up the run of
// pages into objects of the given size wastes at most 12.5% (1.125x)
// of the memory. It is not necessary that the cutoff here be
// the same as above.
//
// The two sources of waste multiply, so the worst possible case
// for the above constraints would be that allocations of some
// size might have a 26.6% (1.266x) overhead.
// In practice, only one of the wastes comes into play for a
// given size (sizes < 512 waste mainly on the round-up,
// sizes > 512 waste mainly on the page chopping).
//
// TODO(rsc): Compute max waste for any given size.

package main
nas-02-90-38:/media/gcc-7.1.0/libgo#

[Bug go/81421] Circular runtime.s-gox -> runtime.lo dependency dropped -> objcopy: 'runtime.s-gox.tmp': No such file

[ian at airs dot com]

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

--- Comment #12 from Ian Lance Taylor  ---
Sorry, I meant: what does this print?

sed '/^package /q' < SRCDIR/libgo/go/runtime/mksizeclasses.go

[Bug middle-end/70140] Inefficient expansion of __builtin_mempcpy

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||missed-optimization
 CC||msebor at gcc dot gnu.org

--- Comment #5 from Martin Sebor  ---
In r249278 GCC was changed to transform early on calls to bcmp, bcopy and bzero
to memcmp, memcpy, and memset.  The main motivation was to simplify their
handling and ensure they are optimized equivalently by the rest of the
compiler.  (This was suggested here:
https://gcc.gnu.org/ml/gcc-patches/2017-06/msg00114.html).  It might make sense
to take the same approach with mempcpy.

(The second part of r249278, i.e., the removal of the bcmp, bcopy and bzero
handling, is yet to be done.)

[Bug go/81421] Circular runtime.s-gox -> runtime.lo dependency dropped -> objcopy: 'runtime.s-gox.tmp': No such file

[mfe at live dot de]

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

--- Comment #11 from martin  ---
nas-02-90-38:/media/gcc-7.1.0/libgo# sed
Usage: sed [OPTION]... {script-only-if-no-other-script} [input-file]...

  -n, --quiet, --silent
 suppress automatic printing of pattern space
  -e script, --expression=script
 add the script to the commands to be executed
  -f script-file, --file=script-file
 add the contents of script-file to the commands to be executed
  -i[SUFFIX], --in-place[=SUFFIX]
 edit files in place (makes backup if extension supplied)
  -l N, --line-length=N
 specify the desired line-wrap length for the `l' command
  --posix
 disable all GNU extensions.
  -r, --regexp-extended
 use extended regular expressions in the script.
  -s, --separate
 consider files as separate rather than as a single continuous
 long stream.
  -u, --unbuffered
 load minimal amounts of data from the input files and flush
 the output buffers more often
  --help display this help and exit
  --version  output version information and exit

If no -e, --expression, -f, or --file option is given, then the first
non-option argument is taken as the sed script to interpret.  All
remaining arguments are names of input files; if no input files are
specified, then the standard input is read.

E-mail bug reports to: bonz...@gnu.org .
Be sure to include the word ``sed'' somewhere in the ``Subject:'' field.

[Bug go/81421] Circular runtime.s-gox -> runtime.lo dependency dropped -> objcopy: 'runtime.s-gox.tmp': No such file

[ian at airs dot com]

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

--- Comment #10 from Ian Lance Taylor  ---
As far as I know your sed and grep are sufficiently up to date.  What does the
sed command by itself print on your system?

[Bug c++/81147] [avr] C++ for -mmcu=atmega2560 doesn't do NRVO or RVO when class inherits from empty base

[gjl at gcc dot gnu.org]

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

--- Comment #5 from Georg-Johann Lay  ---
What you mean by "NRVO" and "RVO" ?

[Bug ada/81446] New: Building Ada on Linux m68k fails due to missing No_Elaboration_Code_All

[glaubitz at physik dot fu-berlin.de]

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

Bug ID: 81446
   Summary: Building Ada on Linux m68k fails due to missing
No_Elaboration_Code_All
   Product: gcc
   Version: 7.1.0
   URL: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=8629
27
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glaubitz at physik dot fu-berlin.de
CC: jrtc27 at jrtc27 dot com, schwab at gcc dot gnu.org
  Target Milestone: ---
Target: m68k-*-*

Trying to cross-build gnat for Linux m68k fails with:

/<>/gcc/build/./gcc/xgcc -B/<>/gcc/build/./gcc/
-B/usr/m68k-linux-gnu/bin/ -B/usr/m68k-linux-gnu/lib/ -isystem
/usr/m68k-linux-gnu/include -isystem /usr/m68k-linux-gnu/sys-include -isystem
/<>/gcc/build/sys-include-c -g -O2   -W -Wall -gnatpg
-nostdinc  -gnatn  s-maccod.ads -o s-maccod.o
/<>/gcc/build/./gcc/xgcc -B/<>/gcc/build/./gcc/
-B/usr/m68k-linux-gnu/bin/ -B/usr/m68k-linux-gnu/lib/ -isystem
/usr/m68k-linux-gnu/include -isystem /usr/m68k-linux-gnu/sys-include -isystem
/<>/gcc/build/sys-include-c -g -O2   -W -Wall -gnatpg
-nostdinc  -gnatn  s-mantis.adb -o s-mantis.o
/<>/gcc/build/./gcc/xgcc -B/<>/gcc/build/./gcc/
-B/usr/m68k-linux-gnu/bin/ -B/usr/m68k-linux-gnu/lib/ -isystem
/usr/m68k-linux-gnu/include -isystem /usr/m68k-linux-gnu/sys-include -isystem
/<>/gcc/build/sys-include-c -g -O2   -W -Wall -gnatpg
-nostdinc  -gnatn  s-mastop.adb -o s-mastop.o
/<>/gcc/build/./gcc/xgcc -B/<>/gcc/build/./gcc/
-B/usr/m68k-linux-gnu/bin/ -B/usr/m68k-linux-gnu/lib/ -isystem
/usr/m68k-linux-gnu/include -isystem /usr/m68k-linux-gnu/sys-include -isystem
/<>/gcc/build/sys-include-c -g -O2   -W -Wall -gnatpg
-nostdinc  -gnatn  s-memcop.ads -o s-memcop.o
/<>/gcc/build/./gcc/xgcc -B/<>/gcc/build/./gcc/
-B/usr/m68k-linux-gnu/bin/ -B/usr/m68k-linux-gnu/lib/ -isystem
/usr/m68k-linux-gnu/include -isystem /usr/m68k-linux-gnu/sys-include -isystem
/<>/gcc/build/sys-include-c -g -O2   -W -Wall -gnatpg
-nostdinc  -gnatn -fno-optimize-sibling-calls  \
  s-memory.adb -o s-memory.o
/<>/gcc/build/./gcc/xgcc -B/<>/gcc/build/./gcc/
-B/usr/m68k-linux-gnu/bin/ -B/usr/m68k-linux-gnu/lib/ -isystem
/usr/m68k-linux-gnu/include -isystem /usr/m68k-linux-gnu/sys-include -isystem
/<>/gcc/build/sys-include-c -g -O2   -W -Wall -gnatpg
-nostdinc  -gnatn  s-multip.adb -o s-multip.o
yes
s-maccod.ads:36:15: violation of No_Elaboration_Code_All at line 37
s-maccod.ads:36:15: unit "System" does not have No_Elaboration_Code_All
../gcc-interface/Makefile:299: recipe for target 's-maccod.o' failed
make[9]: *** [s-maccod.o] Error 1
make[9]: *** Waiting for unfinished jobs

Comparing system-linux-m68k.ads with the equivalent code for other
architectures on Linux, it seems the following changes is necessary:

diff --git a/gcc/ada/system-linux-m68k.ads b/gcc/ada/system-linux-m68k.ads
index 9aa6143f262..2de957cfd9f 100644
--- a/gcc/ada/system-linux-m68k.ads 
+++ b/gcc/ada/system-linux-m68k.ads 
@@ -40,6 +40,9 @@ package System is 
--  this unit Pure instead of Preelaborable; see RM 13.7.1(15). In Ada
--  2005, this is Pure in any case (AI-362).

+   pragma No_Elaboration_Code_All;
+   --  Allow the use of that restriction in units that WITH this unit
+
type Name is (SYSTEM_NAME_GNAT);
System_Name : constant Name := SYSTEM_NAME_GNAT;

@@ -126,7 +129,7 @@ private
--  of the individual switch values.

Backend_Divide_Checks : constant Boolean := False;
-   Backend_Overflow_Checks   : constant Boolean := False;
+   Backend_Overflow_Checks   : constant Boolean := True;
Command_Line_Args : constant Boolean := True;
Configurable_Run_Time : constant Boolean := False;
Denorm: constant Boolean := True;

I'm currently testing this patch and will report back once I have a result.

[Bug target/81312] Enable X86_TUNE_ACCUMULATE_OUTGOING_ARGS

[hjl.tools at gmail dot com]

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

--- Comment #6 from H.J. Lu  ---
(In reply to Jan Hubicka from comment #5)
> What are the code size/performance tradeoffs in 32bit/64bit mode with Intel
> machines?

Pavel, should we investigate it?

[Bug libstdc++/45896] [C++0x] Facet time_get not reading dates according to the IEEE 1003 standard.

[xyzdragon at fastmail dot fm]

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

xyzdragon at fastmail dot fm changed:

   What|Removed |Added

 CC||xyzdragon at fastmail dot fm

--- Comment #7 from xyzdragon at fastmail dot fm ---
Had this bug when trying "%m" formatter on input "7" input. Saw the comment
from 7 years ago "Can fix pretty quickly." and let out a desperate laugh. Is
C++11 dead?

[Bug go/81421] Circular runtime.s-gox -> runtime.lo dependency dropped -> objcopy: 'runtime.s-gox.tmp': No such file

[mfe at live dot de]

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

--- Comment #9 from martin  ---
The OS is based on debian with some custom modification from Netgear.

I thought I "upgraded" all neccessary libraries for gcc 7.1.0.

ldconfig -V
ldconfig (GNU libc) 2.3.2

sed --version
GNU sed version 4.1.5

grep --version
egrep (GNU grep) 2.4.2

If upgrading sed and grep helps to solve the issue, I can do so. Would I then
have to reconfigure and recompile the whole gcc-7.1.0 or could I try to
continue the process with make? Thanks.

[Bug target/81312] Enable X86_TUNE_ACCUMULATE_OUTGOING_ARGS

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #5 from Jan Hubicka  ---
What are the code size/performance tradeoffs in 32bit/64bit mode with Intel
machines?

[Bug middle-end/59521] __builtin_expect not effective in switch

[drepper.fsp at gmail dot com]

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

--- Comment #12 from Ulrich Drepper  ---
On Fri, Jul 14, 2017 at 2:17 PM, marxin at gcc dot gnu.org
 wrote:
> Maybe I miss something, but I would expect to sort all branches in
> emit_case_decision_tree as either predictors can sort branches, or one have a
> profile feedback. Having a chain of equal comparisons, that should be always
> beneficial, or?

I agree.  There seems to be no negative effect.  If you use a stable
sort algorithm the programmer can have influence when needed since the
program's order is preserved.  If the compiler has probability
information it should use it.  Note, I just mean the order of the
tests.  Deciding about placing code in cold sections is a different
story but this isn't what we're talking about here, right?

[Bug middle-end/81445] New: Dynamic stack allocation not optimized into static allocation

[wilco at gcc dot gnu.org]

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

Bug ID: 81445
   Summary: Dynamic stack allocation not optimized into static
allocation
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wilco at gcc dot gnu.org
  Target Milestone: ---

Many compilers optimize small dynamic allocations into static allocation. This
is more efficient as it allows multiple small dynamic allocations to be merged
into a single static allocation. In some cases it may remove all dynamic
allocations, avoiding the need for a frame pointer (which frees up an extra
register on various targets in addition to reducing prolog/epilog overheads).

Obviously allocations cannot be in a loop (including tail-recursion), and the
total size should be limited to avoid increasing stack size by too much.

void f(void*);
void alloca (int x)
{
  if (x < 100)
f (__builtin_alloca (x));
  f (__builtin_alloca (16));
}

[Bug go/81421] Circular runtime.s-gox -> runtime.lo dependency dropped -> objcopy: 'runtime.s-gox.tmp': No such file

[ian at airs dot com]

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

--- Comment #8 from Ian Lance Taylor  ---
On my system I see this:

> sed '/^package /q' < ~/gcc/gcc-7-branch/libgo/go/runtime/mksizeclasses.go | 
> grep '^// +build ' | cat
// +build ignore

That is, the command displays `// +build ignore`.  The fact that it displays
nothing on your system is the root of the problem here.

You seem to be running GNU/Linux.  What versions of sed and grep are on your
PATH?  The sed and grep commands look simple enough to me.  I can't think of
any reason why they would fail.  What does the sed command print if you run it
alone?

[Bug middle-end/70140] Inefficient expansion of __builtin_mempcpy

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu  ---
(In reply to Wilco from comment #3)
> Yes. Ignoring GLIBC internals, mempcpy is used quite infrequently. As a
> result not many targets have added highly optimized implementations. The
> targets that do have the issue that mempcpy is typically not in the cache
> when called, while memcpy is more likely already cached.
> 

FWIW, in x86-64 glibc, memcpy and mempcpy share the same function
body:

0010 <__mempcpy>:
  10:   48 89 f8mov%rdi,%rax
  13:   48 01 d0add%rdx,%rax
  16:   eb 1b   jmp33 <__memcpy+0x3>

[Bug middle-end/70140] Inefficient expansion of __builtin_mempcpy

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

 CC||wilco at gcc dot gnu.org

--- Comment #3 from Wilco  ---
(In reply to Martin Liška from comment #2)
> I've just taken look at that and please confirm that I understand that
> correctly:
> 
> 1) we want to ideally a same function for expansion of memcpy and mempcpy,
> where for later one we'll append calculation of return value (dest + n)?

Yes, I think the current movmem expander does not deal with the return value so
could be reused for mempcpy expansion.

> 2) I'm bit confused with 'GLIBC currently inlines mempcpy into memcpy'. Do
> is mean that you basically do not want to emit any call to mempcpy and
> prefer rather:

Yes. Ignoring GLIBC internals, mempcpy is used quite infrequently. As a result
not many targets have added highly optimized implementations. The targets that
do have the issue that mempcpy is typically not in the cache when called, while
memcpy is more likely already cached.

If there are targets that do not want this, we could add a target define.

Note that I'm not concerned about the corner case of a mempcpy being tailcalled
which isn't possible anymore after we optimize mempcpy into memcpy. In almost
all targets mempcpy is a C function that calls memcpy, ie. you already have
extra overhead on every mempcpy call. See glibc/string/mempcpy.c:

void *
MEMPCPY (void *dest, const void *src, size_t len)
{
  return memcpy (dest, src, len) + len;
}

[Bug tree-optimization/81346] Missed constant propagation into comparison

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #41707|0   |1
is obsolete||

--- Comment #7 from Jakub Jelinek  ---
Created attachment 41760
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41760=edit
gcc8-pr81346-wip.patch

Updated patch that does this, by moving the code from build_range_check into a
helper function that can be used in two spots it is actually small.

The remaining tasks are testsuite coverage and then match.pd optimizations for
the build_range_check stuff where needed.

[Bug middle-end/81444] expmed.c:init_expmed_one_mode uses wrong mode for widening cost computations

[gjl at gcc dot gnu.org]

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

--- Comment #1 from Georg-Johann Lay  ---
Created attachment 41759
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41759=edit
Proposed patch.

PR middle-end/81444
* expmed.c (init_expmed_one_conv): Don't clobber all->reg's mode.
(init_expmed_one_mode): For widening mult and mult_highpart,
use wider_mode 2x wider than the input mode.

[Bug target/71112] [6 Regression] ICE with -fpie on aarch64 ILP32 big-endian

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||ramana at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #12 from Ramana Radhakrishnan  ---
Fixed then.

[Bug middle-end/81444] New: expmed.c:init_expmed_one_mode uses wrong mode for widening cost computations

[gjl at gcc dot gnu.org]

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

Bug ID: 81444
   Summary: expmed.c:init_expmed_one_mode uses wrong mode for
widening cost computations
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---

expmed.c:init_expmed_one_mode uses a wrong mode for widening cost computations.
 For example, on avr this function will compute the costs for
set_mul_highpart_cost as follows:

Almost correct (TImode is strange, this is due to init_expmed_one_conv
clobbering modes):

init_expmed_one_mode[:pass=?]: 0, (truncate:QI (lshiftrt:HI (mult:HI
(zero_extend:HI (reg:TI 42))
(zero_extend:HI (reg:TI 42)))
(const_int 8 [0x8]))) = 20

Wrong: mult_highpart will use SImode (2*HImode).  This target is special as it
provides a 24-bit mode (PSI) between HI and SI.  The cost of "-88" will be used
in the remainder where (truncate:HI (lshiftrt:SI (mult:SI... is the actual RTX.

init_expmed_one_mode[:pass=?]: 0, (truncate:HI (lshiftrt:PSI (mult:PSI
(zero_extend:PSI (reg:TI 42))
(zero_extend:PSI (reg:TI 42)))
(const_int 16 [0x10]))) = -88

Following is not used.  It would be unusable for sensible widening operation
because SI <  2 * PSI.

init_expmed_one_mode[:pass=?]: 0, (truncate:PSI (lshiftrt:SI (mult:SI
(zero_extend:SI (reg:TI 42))
(zero_extend:SI (reg:TI 42)))
(const_int 24 [0x18]))) = 32

Correct again but still strange TImode:

init_expmed_one_mode[:pass=?]: 0, (truncate:SI (lshiftrt:DI (mult:DI
(zero_extend:DI (reg:TI 42))
(zero_extend:DI (reg:TI 42)))
(const_int 32 [0x20]))) = 64

...

Instead, what expmed computes costs for should read:

init_expmed_one_mode[:pass=?]: 0, (truncate:QI (lshiftrt:HI (mult:HI
(zero_extend:HI (reg:QI 42))
(zero_extend:HI (reg:QI 42)))
(const_int 8 [0x8]))) = 20

init_expmed_one_mode[:pass=?]: 0, (truncate:HI (lshiftrt:SI (mult:SI
(zero_extend:SI (reg:HI 42))
(zero_extend:SI (reg:HI 42)))
(const_int 16 [0x10]))) = 32

init_expmed_one_mode[:pass=?]: 0, (truncate:SI (lshiftrt:DI (mult:DI
(zero_extend:DI (reg:SI 42))
(zero_extend:DI (reg:SI 42)))
(const_int 32 [0x20]))) = 64

etc.

[Bug middle-end/59521] __builtin_expect not effective in switch

[marxin at gcc dot gnu.org]

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

--- Comment #11 from Martin Liška  ---
(In reply to Yuri Gribov from comment #10)
> (In reply to Martin Liška from comment #9)
> > The patch works for me for the described case, but does not for PGO, which
> > should do the same based on real numbers:
> 
> Problem here is that we optimize only very_likely edges.  They requires
> 99.95% probability whereas in your testcase we only get 90%.  Changing mods
> to "% 1" and "% 100" results in desired asm:
> 
> cmpl$1, %eax
> je  .L3
> cmpl$10, %eax
> je  .L4
> cmpl$100, %eax
> je  .L5

Maybe I miss something, but I would expect to sort all branches in
emit_case_decision_tree as either predictors can sort branches, or one have a
profile feedback. Having a chain of equal comparisons, that should be always
beneficial, or?

> 
> > Just a small note, Honza's planning to rewrite switch expansion to happen on
> > tree level. Maybe (hopefully) such transformations
> > will be easier on tree level?
> 
> Thanks, that's important to consider.  I'll send patch for review and Cc him
> to maybe comment.  Probly I'll just rebase when his work is in.

Actually he was convincing me to rewrite it, but I still have more unfinished
tasks from history which I should start with ;)

[Bug middle-end/59521] __builtin_expect not effective in switch

[tetra2005 at gmail dot com]

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

--- Comment #10 from Yuri Gribov  ---
(In reply to Martin Liška from comment #9)
> The patch works for me for the described case, but does not for PGO, which
> should do the same based on real numbers:

Problem here is that we optimize only very_likely edges.  They requires 99.95%
probability whereas in your testcase we only get 90%.  Changing mods to "%
1" and "% 100" results in desired asm:

cmpl$1, %eax
je  .L3
cmpl$10, %eax
je  .L4
cmpl$100, %eax
je  .L5

> Just a small note, Honza's planning to rewrite switch expansion to happen on
> tree level. Maybe (hopefully) such transformations
> will be easier on tree level?

Thanks, that's important to consider.  I'll send patch for review and Cc him to
maybe comment.  Probly I'll just rebase when his work is in.

[Bug other/80573] ICE: internal compiler error: in assign_temp, at function.c:961

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-14
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Martin Liška  ---
Confirmed, all releases I have do ICE.

[Bug middle-end/81030] [8 Regression] ICE on valid code at -O1 (only) on x86_64-linux-gnu: verify_flow_info failed

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

 CC||vries at gcc dot gnu.org

--- Comment #5 from Tom de Vries  ---
When we expand this jump:
...
  _23 = _21 | _22;
  if (_23 != 0)
goto ; [73.27%] [count: INV]
  else
goto ; [26.73%] [count: INV]
;;succ:   7 [73.3% (guessed)]  (TRUE_VALUE,EXECUTABLE)
;;6 [26.7% (guessed)]  (FALSE_VALUE,EXECUTABLE)
...


we hit the TRUTH_ORIF_EXPR handling in do_jump_1:
...
case TRUTH_ANDIF_EXPR:
  {
/* Spread the probability that the expression is false evenly between
   the two conditions. So the first condition is false half the total
   probability of being false. The second condition is false the other
   half of the total probability of being false, so its jump has a
false
   probability of half the total, relative to the probability we
   reached it (i.e. the first condition was true).  */
profile_probability op0_prob = profile_probability::uninitialized ();
profile_probability op1_prob = profile_probability::uninitialized ();
if (prob.initialized_p ())
  {
profile_probability false_prob = prob.invert ();
profile_probability op0_false_prob = false_prob.apply_scale (1, 2);
profile_probability op1_false_prob = false_prob.apply_scale (1, 2)
/ op0_false_prob.invert ();
/* Get the probability that each jump below is true.  */
op0_prob = op0_false_prob.invert ();
op1_prob = op1_false_prob.invert ();
  }
if (if_false_label == NULL)
  {
drop_through_label = gen_label_rtx ();
do_jump (op0, drop_through_label, NULL, op0_prob);
do_jump (op1, NULL, if_true_label, op1_prob);
  }
else
  {
do_jump (op0, if_false_label, NULL, op0_prob);
do_jump (op1, if_false_label, if_true_label, op1_prob);
  }
break;
  }
...

The true edge to bb7 with probability 7327 is split into two probabilities, as
the comment explains:
...
(gdb) p op0_prob
$5 = {static n_bits = 30, static max_probability = 1, 
  static uninitialized_probability = 1073741823, m_val = 3664, m_quality =
profile_guessed}
(gdb) p op1_prob
$6 = {static n_bits = 30, static max_probability = 1, 
  static uninitialized_probability = 1073741823, m_val = 5783, m_quality =
profile_guessed}
...


The assert we run into is:

test2.c:26:1: error: verify_flow_info: REG_BR_PROB does not match cfg 3664 7327
...
The assert complains that the first do_jump generates a branch with REG_BR_PROB
3664, while the corresponding edge remains at 7327.

In other words:
...
(jump_insn 15 14 18 5 (set (pc)
(if_then_else (ne (reg:CCZ 17 flags)
(const_int 0 [0]))
(label_ref:DI 32)
(pc))) "test2.c":20 617 {*jcc_1}
 (int_list:REG_BR_PROB 3664 (nil))
 -> 32)
;;succ:   10 [73.3% (guessed)]
;;6 [26.7% (guessed)]  (FALLTHRU)
...

[Bug middle-end/70140] Inefficient expansion of __builtin_mempcpy

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
I've just taken look at that and please confirm that I understand that
correctly:

1) we want to ideally a same function for expansion of memcpy and mempcpy,
where for later one we'll append calculation of return value (dest + n)?

2) I'm bit confused with 'GLIBC currently inlines mempcpy into memcpy'. Do is
mean that you basically do not want to emit any call to mempcpy and prefer
rather:

int my_mempcpy(void)
{
  return __builtin_mempcpy (a, b, SIZE);
}

$ ./xgcc -B. /tmp/mem.c -O2 -S  -DSIZE=10 -o /dev/stdout

my_mempcpy:
.LFB1:
.cfi_startproc
subq$8, %rsp
.cfi_def_cfa_offset 16
movqb(%rip), %rsi
movqa(%rip), %rdi
movl$10, %edx
callmemcpy
addq$8, %rsp
.cfi_def_cfa_offset 8
addq$10, %rax
ret
.cfi_endproc

?
Thanks

[Bug middle-end/81443] New: gcc-7.1.0/MIPS N32: build/genrecog.o: virtual memory exhausted: Cannot allocate memory

[kumba at gentoo dot org]

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

Bug ID: 81443
   Summary: gcc-7.1.0/MIPS N32: build/genrecog.o: virtual memory
exhausted: Cannot allocate memory
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kumba at gentoo dot org
  Target Milestone: ---

I am attempting to compile gcc-7.1.0 on a 64-bit MIPS platform, targeting the
MIPS-III ISA, glibc-userland, N32 ABI, big-endian architecture, and an unable
to complete the compile due to exhausting all available virtual memory.  The
machine in question has 2GB of physical RAM installed and ~7GB of swap space
(3GB in partitions, 4GB as a temp swap file).  I at first thought it was the
parallelization (-j3 to make), since the machine is dual CPU, but it also fails
as -j2 and -j1.  I watched the swap usage with 'watch -n2 swapon --show', and
when the compile terminates, swap is barely at 50%, so I don't think it's
related to lack of available swap space.

I was able to successfully compile gcc-7.1 on the same machine, different
chroot, under the O32 ABI for glibc-2.24, and O32 ABI for uclibc-ng-1.0.25 in
another chroot.  So I suspect this is a regression for the N32 ABI case.

I am not sure what files or data will of use to run this one down.  I am
preserving the last builddir for now, so if specific files are needed for
analysis, let me know.

# /var/tmp/portage/sys-devel/gcc-7.1.0-r1/work/build/./prev-gcc/xg++ -v
Using built-in specs.
COLLECT_GCC=/var/tmp/portage/sys-devel/gcc-7.1.0-r1/work/build/./prev-gcc/xg++
Target: mips64-unknown-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-7.1.0-r1/work/gcc-7.1.0/configure
--host=mips64-unknown-linux-gnu --build=mips64-unknown-linux-gnu --prefix=/usr
--bindir=/usr/mips64-unknown-linux-gnu/gcc-bin/7.1.0
--includedir=/usr/lib/gcc/mips64-unknown-linux-gnu/7.1.0/include
--datadir=/usr/share/gcc-data/mips64-unknown-linux-gnu/7.1.0
--mandir=/usr/share/gcc-data/mips64-unknown-linux-gnu/7.1.0/man
--infodir=/usr/share/gcc-data/mips64-unknown-linux-gnu/7.1.0/info
--with-gxx-include-dir=/usr/lib/gcc/mips64-unknown-linux-gnu/7.1.0/include/g++-v7
--with-python-dir=/share/gcc-data/mips64-unknown-linux-gnu/7.1.0/python
--enable-languages=c,c++ --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 --disable-multilib --disable-altivec --disable-fixed-point
--with-abi=n32 --disable-libgcj --disable-libgomp --disable-libmudflap
--disable-libssp --disable-libcilkrts --disable-libmpx --disable-vtable-verify
--disable-libvtv --disable-libquadmath --enable-lto --without-isl
--disable-libsanitizer --disable-default-pie --enable-default-ssp
Thread model: posix
gcc version 7.1.0 (Gentoo 7.1.0-r1 p1.1)

[Bug gcov-profile/81442] error: verify_flow_info: REG_BR_PROB is set but cfg probability is not during RTL pass: outof_cfglayout

[vries at gcc dot gnu.org]

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

--- Comment #2 from Tom de Vries  ---
(In reply to Tom de Vries from comment #1)
> I'm currently testing if that also makes the test-case pass.

It does.

[Bug gcov-profile/81442] error: verify_flow_info: REG_BR_PROB is set but cfg probability is not during RTL pass: outof_cfglayout

[vries at gcc dot gnu.org]

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

--- Comment #1 from Tom de Vries  ---
Created attachment 41758
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41758=edit
Tentative patch

I'm not sure how this is supposed to be fixed.

But this is a point fix that at least allows lto1 to finish. I'm currently
testing if that also makes the test-case pass.

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

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  ---
Author: jakub
Date: Fri Jul 14 09:10:45 2017
New Revision: 250200

URL: https://gcc.gnu.org/viewcvs?rev=250200=gcc=rev
Log:
PR sanitizer/81066
* sanitizer_common/sanitizer_linux.h: Cherry-pick upstream r307969.
* sanitizer_common/sanitizer_linux.cc: Likewise.
* sanitizer_common/sanitizer_stoptheworld_linux_libcdep.cc: Likewise.
* tsan/tsan_platform_linux.cc: Likewise.

Modified:
trunk/libsanitizer/ChangeLog
trunk/libsanitizer/sanitizer_common/sanitizer_linux.cc
trunk/libsanitizer/sanitizer_common/sanitizer_linux.h
trunk/libsanitizer/sanitizer_common/sanitizer_stoptheworld_linux_libcdep.cc
trunk/libsanitizer/tsan/tsan_platform_linux.cc

[Bug gcov-profile/81442] New: error: verify_flow_info: REG_BR_PROB is set but cfg probability is not during RTL pass: outof_cfglayout

[vries at gcc dot gnu.org]

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

Bug ID: 81442
   Summary: error: verify_flow_info: REG_BR_PROB is set but cfg
probability is not during RTL pass: outof_cfglayout
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

I.

At r250114, I run into the following ICE in
libgomp.oacc-c-c++-common/reduction-5.c:
...
libgomp/testsuite/libgomp.oacc-c/../libgomp.oacc-c-c++-common/reduction-5.c: In
function 'main._omp_fn.2':
libgomp/testsuite/libgomp.oacc-c/../libgomp.oacc-c-c++-common/reduction-5.c:52:9:
error: verify_flow_info: REG_BR_PROB is set but cfg probability is not
during RTL pass: outof_cfglayout
libgomp/testsuite/libgomp.oacc-c/../libgomp.oacc-c-c++-common/reduction-5.c:52:9:
internal compiler error: verify_flow_info failed
0x6511e9 verify_flow_info()
gcc/cfghooks.c:259
0x66b0c5 execute
gcc/cfgrtl.c:3581
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
...

This is with an x86_64 compiler with nvptx accelerator, in lto1 when compiling
for the nvptx target.

The error occurs during the call to checking_verify_flow_info at the end of
cfg_layout_finalize.

The jump_insn that is complained about is the last insn of bb2:
...
(jump_insn 18 17 32 2 (set (pc)
(if_then_else (eq (reg:BI 83)
(const_int 0 [0]))
(label_ref:DI 33)
(pc))) "reduction-5.c":52 105 {br_false}
 (expr_list:REG_DEAD (reg:BI 83)
(int_list:REG_BR_PROB 0 (nil)))
 -> 33)
...

The two edges are to bbs 3 and 4:
...
(gdb) p
cfun->cfg->x_basic_block_info.m_vecdata[2].succs.m_vecdata[0].dest.index
$31 = 3
(gdb) p
cfun->cfg->x_basic_block_info.m_vecdata[2].succs.m_vecdata[1].dest.index
$32 = 4
...

With these probabilities:
...
(gdb) p
cfun->cfg->x_basic_block_info.m_vecdata[2].succs.m_vecdata[0].probability
$28 = {static n_bits = 30, static max_probability = 1, static
uninitialized_probability = 1073741823, 
  m_val = 1, m_quality = profile_precise}
(gdb) p
cfun->cfg->x_basic_block_info.m_vecdata[2].succs.m_vecdata[1].probability
$29 = {static n_bits = 30, static max_probability = 1, static
uninitialized_probability = 1073741823, 
  m_val = 1073741823, m_quality = profile_guessed}
...

The branch edge is to bb4, because bb4 is the one starting with:
...
(gdb) call debug_bb_n (4)
(code_label 33 5 34 4 25 (nil) [1 uses])
(note 34 33 35 4 [bb 4] NOTE_INSN_BASIC_BLOCK)
...


So:
- the fallthru edge to bb3 has probability 1.
- the branch edge to bb 4 has uninitialized probability
- the REG_BR_PROB 0 claims the branch edge has probability 0.
The assert happens because of the difference between the last two.


II.

Before fixup_reorder_chain in cfg_layout_finalize, we have:
...
(jump_insn 18 17 31 2 (set (pc)
(if_then_else (ne (reg:BI 83)
(const_int 0 [0]))
(label_ref 31)
(pc))) "reduction-5.c":52 104 {br_true}
 (expr_list:REG_DEAD (reg:BI 83)
(int_list:REG_BR_PROB 1 (nil)))
 -> 31)
...
So, the jump condition is the inverse, as is the REG_BR_PROB.

The branch edge is to bb3, is the one starting with:
...
(gdb) call debug_bb_n(3)
(code_label 31 18 32 3 24 (nil) [1 uses])
(note 32 31 4 3 [bb 3] NOTE_INSN_BASIC_BLOCK)
...
So that is also inverted

The edge destinations are the same:
...
$39 = (basic_block_def *) 0x7749b068
(gdb) p
cfun->cfg->x_basic_block_info.m_vecdata[2].succs.m_vecdata[0].dest.index
$40 = 3
(gdb) p
cfun->cfg->x_basic_block_info.m_vecdata[2].succs.m_vecdata[1].dest.index
$41 = 4
...

As are the edge probabilities:
...
(gdb) p
cfun->cfg->x_basic_block_info.m_vecdata[2].succs.m_vecdata[0].probability
$42 = {static n_bits = 30, static max_probability = 1, static
uninitialized_probability = 1073741823, 
  m_val = 1, m_quality = profile_precise}
(gdb) p
cfun->cfg->x_basic_block_info.m_vecdata[2].succs.m_vecdata[1].probability
$43 = {static n_bits = 30, static max_probability = 1, static
uninitialized_probability = 1073741823, 
  m_val = 1073741823, m_quality = profile_guessed}
...

So here we have:
- the fallthru edge is to bb4, which has uninitialized probability.
- the branch edge to bb 3, which has probability 1 
- the REG_BR_PROB 1 claims the branch edge has probability 1.
In this case, the last two are in agreement.


III.

This bit in fixup_reorder_chain does the jump inversion:
...
  /* Otherwise we can try to invert the jump.  This will
 basically never fail, however, keep up the pretense.  */
  else if (invert_jump (bb_end_jump,
(e_fall->dest
 

[Bug target/56564] movdqa on possibly-8-byte-aligned struct with -O3

[jakub at gcc dot gnu.org]

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

--- Comment #23 from Jakub Jelinek  ---
The bug is fixed, you must be running into a different issue, either in the
source you're compiling, or in the compiler.  So, please open a new bugreport
instead of commenting on a different one, and supply all the needed information
(see http://gcc.gnu.org/bugs/ for details on what we need).

[Bug fortran/81416] OpenMP craches if large arrays passed

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
Note the array is never allocated on the heap, it is either on the stack, or
(e.g. without -frecursive/-fopenmp) it can be in allocated .bss or if
initialized in .data section.  For heap allocations you need to use dynamic
allocation (allocatable array or pointer and use ALLOCATE on that).

[Bug ipa/79765] [CHKP] ICE in create_target_clone in multiple_target.c:211

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Liška  ---
I was unable to fix that, thus leaving as unassigned.

[Bug fortran/81416] OpenMP craches if large arrays passed

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Pinski  ---
If b is not used, then it is removed and not put on either the stack or the
heap.  That is what your second test case is showing.

[Bug ipa/79902] ICE in rebuild_frequencies, at predict.c:3689

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Liška  ---
Can't reproduce, thus marking as invalid.

[Bug fortran/81416] OpenMP craches if large arrays passed

[bz0815 at tirol dot com]

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

--- Comment #4 from bz0815 at tirol dot com ---
(In reply to Andrew Pinski from comment #3)
> >  DOUBLE PRECISION,DIMENSION(n) :: b
> 
> This array is on the stack.

So

  DOUBLE PRECISION,DIMENSION(n) :: b

is put on the stack if it is passed as an argument but put on heap if it isn't?

If it is passed as argument even small dimensions cause a segmentation fault:

PROGRAM Prog
  USE Mod
  USE OMP_LIB
  IMPLICIT NONE

  INTEGER :: nthreads
  INTEGER,PARAMETER :: n = 262144
  DOUBLE PRECISION,DIMENSION(n) :: b

  nthreads = 4

  CALL OMP_SET_NUM_THREADS(nthreads)

  PRINT *,omp_get_num_procs()
  PRINT *,omp_get_max_threads()
  PRINT *,omp_get_num_threads()

  CALL Print_Info(b)

END PROGRAM Prog

$ make
$ gfortran -Wl,--stack,2097152 -fopenmp -c mod.f08 -o mod.o
$ gfortran -Wl,--stack,2097152 -fopenmp  -o prog mod.o prog.f08

$ ./prog
Segmentation fault (core dumped)

However, if array b is not passed as an argument even dimensions greater than
stack limit work fine: 

PROGRAM Prog
  USE Mod
  USE OMP_LIB
  IMPLICIT NONE

  INTEGER :: nthreads
  INTEGER,PARAMETER :: n = 134217728
  DOUBLE PRECISION,DIMENSION(n) :: b

  nthreads = 4

  CALL OMP_SET_NUM_THREADS(nthreads)

  PRINT *,omp_get_num_procs()
  PRINT *,omp_get_max_threads()
  PRINT *,omp_get_num_threads()

!  CALL Print_Info(b)

END PROGRAM Prog

$ gfortran -Wl,--stack,2097152 -fopenmp -c mod.f08 -o mod.o
$ gfortran -Wl,--stack,2097152 -fopenmp  -o prog mod.o prog.f08

$ ./prog
   8
   4
   1

Anyway, many thanks for the hint. My program is now up and running.

[Bug go/81421] Circular runtime.s-gox -> runtime.lo dependency dropped -> objcopy: 'runtime.s-gox.tmp': No such file

[mfe at live dot de]

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

--- Comment #7 from martin  ---
/media/gcc-7.1.0 is my source dir

nas-02-90-38:/media/gcc-7.1.0# libgo/match.sh --goarch=sparc --goos=linux
--srcdir=/media/gcc-7.1.0/libgo/go/runtime --extrafiles="runtime_sysinfo.go
sigtab.go" --tag=libffi
/media/gcc-7.1.0/libgo/go/runtime/alg.go
/media/gcc-7.1.0/libgo/go/runtime/cgo_gccgo.go
/media/gcc-7.1.0/libgo/go/runtime/cgocheck.go
/media/gcc-7.1.0/libgo/go/runtime/chan.go
/media/gcc-7.1.0/libgo/go/runtime/compiler.go
/media/gcc-7.1.0/libgo/go/runtime/cpuprof.go
/media/gcc-7.1.0/libgo/go/runtime/cputicks.go
/media/gcc-7.1.0/libgo/go/runtime/debug.go
/media/gcc-7.1.0/libgo/go/runtime/env_posix.go
/media/gcc-7.1.0/libgo/go/runtime/error.go
/media/gcc-7.1.0/libgo/go/runtime/extern.go
/media/gcc-7.1.0/libgo/go/runtime/fastlog2.go
/media/gcc-7.1.0/libgo/go/runtime/fastlog2table.go
/media/gcc-7.1.0/libgo/go/runtime/ffi.go
/media/gcc-7.1.0/libgo/go/runtime/hash32.go
/media/gcc-7.1.0/libgo/go/runtime/hash64.go
/media/gcc-7.1.0/libgo/go/runtime/hashmap.go
/media/gcc-7.1.0/libgo/go/runtime/hashmap_fast.go
/media/gcc-7.1.0/libgo/go/runtime/iface.go
/media/gcc-7.1.0/libgo/go/runtime/lfstack.go
/media/gcc-7.1.0/libgo/go/runtime/lfstack_32bit.go
/media/gcc-7.1.0/libgo/go/runtime/lfstack_64bit.go
/media/gcc-7.1.0/libgo/go/runtime/lock_futex.go
/media/gcc-7.1.0/libgo/go/runtime/lock_sema.go
/media/gcc-7.1.0/libgo/go/runtime/mcache.go
/media/gcc-7.1.0/libgo/go/runtime/mkfastlog2table.go
/media/gcc-7.1.0/libgo/go/runtime/mksizeclasses.go
/media/gcc-7.1.0/libgo/go/runtime/mprof.go
/media/gcc-7.1.0/libgo/go/runtime/msan0.go
/media/gcc-7.1.0/libgo/go/runtime/mstats.go
/media/gcc-7.1.0/libgo/go/runtime/mstkbar.go
/media/gcc-7.1.0/libgo/go/runtime/netpoll.go
/media/gcc-7.1.0/libgo/go/runtime/netpoll_epoll.go
/media/gcc-7.1.0/libgo/go/runtime/netpoll_kqueue.go
/media/gcc-7.1.0/libgo/go/runtime/netpoll_stub.go
/media/gcc-7.1.0/libgo/go/runtime/os_gccgo.go
/media/gcc-7.1.0/libgo/go/runtime/os_linux.go
/media/gcc-7.1.0/libgo/go/runtime/os_linux_ppc64x.go
/media/gcc-7.1.0/libgo/go/runtime/panic.go
/media/gcc-7.1.0/libgo/go/runtime/print.go
/media/gcc-7.1.0/libgo/go/runtime/proc.go
/media/gcc-7.1.0/libgo/go/runtime/race0.go
/media/gcc-7.1.0/libgo/go/runtime/rdebug.go
/media/gcc-7.1.0/libgo/go/runtime/runtime.go
/media/gcc-7.1.0/libgo/go/runtime/runtime1.go
/media/gcc-7.1.0/libgo/go/runtime/runtime2.go
/media/gcc-7.1.0/libgo/go/runtime/select.go
/media/gcc-7.1.0/libgo/go/runtime/sema.go
/media/gcc-7.1.0/libgo/go/runtime/signal_gccgo.go
/media/gcc-7.1.0/libgo/go/runtime/signal_sighandler.go
/media/gcc-7.1.0/libgo/go/runtime/signal_unix.go
/media/gcc-7.1.0/libgo/go/runtime/sigqueue.go
/media/gcc-7.1.0/libgo/go/runtime/sizeclasses.go
/media/gcc-7.1.0/libgo/go/runtime/slice.go
/media/gcc-7.1.0/libgo/go/runtime/stack.go
/media/gcc-7.1.0/libgo/go/runtime/string.go
/media/gcc-7.1.0/libgo/go/runtime/stubs.go
/media/gcc-7.1.0/libgo/go/runtime/stubs2.go
/media/gcc-7.1.0/libgo/go/runtime/symtab.go
/media/gcc-7.1.0/libgo/go/runtime/time.go
/media/gcc-7.1.0/libgo/go/runtime/trace.go
/media/gcc-7.1.0/libgo/go/runtime/traceback_gccgo.go
/media/gcc-7.1.0/libgo/go/runtime/type.go
/media/gcc-7.1.0/libgo/go/runtime/typekind.go
/media/gcc-7.1.0/libgo/go/runtime/unaligned1.go
/media/gcc-7.1.0/libgo/go/runtime/unaligned2.go
/media/gcc-7.1.0/libgo/go/runtime/utf8.go
/media/gcc-7.1.0/libgo/go/runtime/vdso_none.go
/media/gcc-7.1.0/libgo/go/runtime/write_err.go runtime_sysinfo.go sigtab.go
nas-02-90-38:/media/gcc-7.1.0# sed '/^package /q' <
/media/gcc-7.1.0/libgo/go/runtime/mksizeclasses.go | grep '^// +build ' | cat

The last command didn't produce any output.

[Bug driver/79659] Provide valid values for integer options (e.g. -Wformat) with --help= option

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

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

[Bug rtl-optimization/79856] rtl_verify_edges: use internal_error instead of error

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #9 from Martin Liška  ---
As discussion shows, there's not so big interest to migrate internal_error
messages to be excluded from translation. Thus, I'm leaving the PR unassigned.

[Bug middle-end/81441] New: slowdown due to -fpeel-loops and -ftracer added by -fprofile-use

[Joost.VandeVondele at mat dot ethz.ch]

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

Bug ID: 81441
   Summary: slowdown due to -fpeel-loops and -ftracer added by
-fprofile-use
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Joost.VandeVondele at mat dot ethz.ch
  Target Milestone: ---

For our code, we see a slowdown (3%-7% depending on the user reporting) due to
the options -fpeel-loops and -ftracer added by default when using
-fprofile-use.

The code is stockfish, which is presumably the strongest open source chess
engine, and part of benchmark suites such as
https://openbenchmarking.org/test/pts/stockfish 

The same behaviour has been observed for gcc versions from 4.X to 7.1 so it is
not some recent regression and quite persistent. (Discussions in
https://groups.google.com/forum/?fromgroups=#!topic/fishcooking/YzV_fG7ejR4 and
https://github.com/official-stockfish/Stockfish/pull/1165 )

It is not easy for me to pinpoint the location in the code that is affected
most (despite the code being only ~5000 lines of C++). I tried differential
profiling with perf, but didn't get profiles that made sense to me. 

It is easy to reproduce, by testing two successive git commits where the change
of options in the Makefile is the only difference:

git clone https://github.com/official-stockfish/Stockfish.git
cd Stockfish/src/

# version with -fprofile-use -fno-peel-loops -fno-tracer
# ==
git checkout c8e5384c3a4a5d9ac709c9b50954907a7f07109c
make clean && make -j ARCH=x86-64-modern profile-build
./stockfish bench 128 1 16 default depth 2>&1 | grep 'Total time (ms)'
# (locally reports Total time (ms) : 9947)

#version with just -fprofile-use
#===
git checkout 0371a8f8c4a043cb3e7d08b5b8e7d08d49f28324
make clean && make -j ARCH=x86-64-modern profile-build
./stockfish bench 128 1 16 default depth 2>&1 | grep 'Total time (ms)'
# (locally reports Total time (ms) : 10456)

So '-fprofile-use -fno-peel-loops -fno-tracer' is 5% faster than
'-fprofile-use' in my case.

Let me know if I can provide more info. The length of the benchmarks can be
adjusted easily by changing the '16' in the bench command to smaller (shorter)
or larger (longer) numbers (time increases/decreases exponentially, change in
steps of 1 to have ~2x change).

[Bug tree-optimization/81396] [7/8 Regression] Optimization of reading Little-Endian 64-bit number with portable code has a regression

[glisse at gcc dot gnu.org]

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

--- Comment #6 from Marc Glisse  ---
(In reply to Jakub Jelinek from comment #5)
> Or both this bswap change and the match.pd addition.

Doing both sounds good to me :-)