[Bug other/80895] format not a string literal and no format arguments; in GCC itself

[miloradovsky at gmail dot com]

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

Andrew Miloradovsky  changed:

   What|Removed |Added

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

--- Comment #8 from Andrew Miloradovsky  ---
Well, then it seems like

- the entire patch is wrong, and all those changes shouldn't be made
- inserting the comment before every diagnostic output call is not worth it
- in future, this mechanism may be changed, to filter out the warnings
- but, ATM, format-security should always be disabled when compiling GCC
- so the "bug" may be closed now; at least I learned something new; thanks

[Bug other/80895] format not a string literal and no format arguments; in GCC itself

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #7 from Martin Sebor  ---
GCC format strings can contain directives like %< and %> that trigger special
handling (such as quoting and highlighting).  For example, in
gcc/c-family/c-common.c:

message = catenate_messages (gmsgid, " before %<#pragma%>");
...
  if (message)
{
  error (message);
  free (message);

error message ends up quoting #pragma and displaying it in the color set by
quote= in GCC_COLORS:

https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Message-Formatting-Options.html

To do what you suggest I think GCC would need to recognize and use a special
directive telling to treat its argument as a format string (i.e., implement at
least a limited form recursive format string handling).

[Bug other/80895] format not a string literal and no format arguments; in GCC itself

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Andrew Miloradovsky from comment #4)
> Hmm, man printf(3) doesn't tell anything about the formats, what are they
> for?

They are part of the gcc diagnostic format. Gcc does not use printf directly
for those functions.  See how they have the gcc_format attribute rather than
the printf_format attribute.

[Bug other/80895] format not a string literal and no format arguments; in GCC itself

[miloradovsky at gmail dot com]

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

--- Comment #5 from Andrew Miloradovsky  ---
After all I might simply insert that comment everywhere, to reduce confusion.

[Bug other/80895] format not a string literal and no format arguments; in GCC itself

[miloradovsky at gmail dot com]

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

--- Comment #4 from Andrew Miloradovsky  ---
Hmm, man printf(3) doesn't tell anything about the formats, what are they for?

[Bug other/80895] format not a string literal and no format arguments; in GCC itself

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
Still broken:
   else
-error (gmsgid);
+error ("%s", gmsgid);

And more where you have *msgid.

I bet invalid_func_diag has similar too.

[Bug other/80895] format not a string literal and no format arguments; in GCC itself

[miloradovsky at gmail dot com]

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

Andrew Miloradovsky  changed:

   What|Removed |Added

  Attachment #41428|0   |1
is obsolete||

--- Comment #2 from Andrew Miloradovsky  ---
Created attachment 41429
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41429=edit
excluding few cases

where it's said explicitly that `msgid` may be a format string

[Bug tree-optimization/80894] [8 Regression] 456.hmmer in SPEC CPU 2006 is miscompiled

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||x86_64-linux-gnu,
   ||aarch64-linux-gnu
   Target Milestone|--- |8.0
   Severity|normal  |blocker

[Bug tree-optimization/80894] [8 Regression] 456.hmmer in SPEC CPU 2006 is miscompiled

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-27
  Component|middle-end  |tree-optimization
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
On AARCH64-linux-gnu also so this is not target specific.

[Bug other/80895] format not a string literal and no format arguments; in GCC itself

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
This patch is incorrect:
   /* The gmsgid may be a format string with %< and %>. */
-  warned = pedwarn (exploc, opt, gmsgid);
+  warned = pedwarn (exploc, opt, "%s", gmsgid);

See that comment of why.

[Bug other/80895] New: format not a string literal and no format arguments; in GCC itself

[miloradovsky at gmail dot com]

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

Bug ID: 80895
   Summary: format not a string literal and no format arguments;
in GCC itself
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: miloradovsky at gmail dot com
  Target Milestone: ---

Created attachment 41428
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41428=edit
a trivial patch

GCC couldn't be compiled with `-Werror=format-security`, now it can.
The motivation is here (although that post is somewhat outdated):

-
https://unix.stackexchange.com/questions/356232/disabling-the-security-hardening-options-for-a-nix-shell-environment

[Bug middle-end/80894] New: [8 Regression] 456.hmmer in SPEC CPU 2006 is miscompiled

[hjl.tools at gmail dot com]

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

Bug ID: 80894
   Summary: [8 Regression] 456.hmmer in SPEC CPU 2006 is
miscompiled
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: glisse at gcc dot gnu.org
  Target Milestone: ---

On Linux/x86-64, r248447 miscompiled 456.hmmer in SPEC CPU 2006 with

-O2 -ffast-math   -DSPEC_CPU_LP64 -funsigned-char


456.hmmer: copy 0 non-zero return code (exit code=1, signal=0)



Contents of nph3.err


FATAL: HMM file nph3.hmm corrupt or in incorrect format? Parse failed

[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 #17 from Daniel Santos  ---
(In reply to Rainer Orth from comment #15)
> Created attachment 41404 [details]
> Switch ms-sysv to more regular dg functions

You may be surprised to learn how many faulty assumptions you may have about
how the gcc test harness works and manages parallelization.  I did try your
patch and it didn't work.  I didn't go too deeply into trying to analyze the
failures, but if you call dg-runtest, you are using gcc's hack-daptation of
parallelization.  However, your patch doesn't remove *my* hack-daptation of
parallelization, so we end up with two different parallelization schemes that
step on each other's toes.

Another problem with the already present parallelization is that it bunches
tests into groups of 10 per job which will perform very poorly for these tests.

(https://github.com/gcc-mirror/gcc/blob/master/gcc/testsuite/lib/gcc-defs.exp#L170).
 I presume this is to reduce disk I/O and it makes sense from that standpoint
(I don't want to know what it would take to get a ramdisk/tmpfs in a
platform-neutral fashion.)

However, I'm learning a little more about how the test harness works, and it
MAY be possible to call gcc_parallel_test_enable 0 at the start of ms-sysv.exp
and be able to use all of the built-in dg-runtest, et. al. functions!  If I can
get this to work (and not break something else in the process), then we may be
on to a pathway to clean up ms-sysv.exp a little bit -- that is except for a
few outstanding (possibly surmountable) issues:

1.) Can the default time-out of 5 minutes be changed?  I need 20 minutes for
the slowest processors and a whole HOUR when full tests are enabled.

2.) The test description should include the generator flags and not just the
CFLAGS.  Is that possible from dg-runtest, et. al.?  I suppose it's always
possible to add them to CFLAGS with -DGEN_FLAGS="-p0-12" as a hack.

I guess you can see why I said that I was "semi-content" to leave it like it
is. :)  But I'm also glad to better understand how the test harness
parallelization works.  Maybe it's possible to make a small modification to
dg-defs.exp to get it to divvy out a single test per job instead of 10.

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

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #3 from Jerry DeLisle  ---
 gfc::vector testing status:0 (PASSED): Performance:   
2172016.0660160840 
 gfc::tree testing status:0 (PASSED): Performance:   
773072.10385898117 
 gfc::dictionary testing status:0 (PASSED): Performance:   
323307.23290432733 

Program received signal SIGSEGV, Segmentation fault.
0x00300235c8ef in ?? ()
(gdb) bt
#0  0x00300235c8ef in ?? ()
#1  0x00405ffb in __gfc_vector_MOD_vectoriterelementvalue ()
#2  0x00414826 in __gfc_graph_MOD_graphiterappendlink ()
#3  0x00417836 in __gfc_graph_test_MOD_test_gfc_graph ()
#4  0x00401a24 in MAIN__ ()
#5  0x0040137d in main ()

With latest gfortran trunk. I get the error consistently here.

Using source pointed to at original post. 

With gdb:

Breakpoint 1, gfc_vector::vectoriterelementvalue (this=..., offset=0, ierr=0)
at gfc_vector.F90:733
733 function VectorIterElementValue(this,offset,ierr) result(val_p)
(gdb) n
743  val_p=>NULL(); cep=>this%element(offset,errc)
(gdb) n
744  if(errc.eq.GFC_SUCCESS) val_p=>cep%get_value(errc)
(gdb) n

Program received signal SIGSEGV, Segmentation fault.
0x00300235c8ef in ?? ()

Looks like you are giving an offset of zero, maybe it should be 1?

[Bug bootstrap/80887] gnat bootstrap fails at s-regpat.o: raised STORAGE_ERROR : stack overflow or erroneous memory access

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-26
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #6 from Martin Sebor  ---
I just ran into the same problem, co confirming.

[Bug bootstrap/80887] gnat bootstrap fails at s-regpat.o: raised STORAGE_ERROR : stack overflow or erroneous memory access

[glisse at gcc dot gnu.org]

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

--- Comment #5 from Marc Glisse  ---
(I am adding -gnatwA -gnatyN to the command line to let the reduced version
compile, and -m32 is fundamental)
Maybe simplifying (sizetype)_26 to _3 is fine, but it isn't fine to keep
valueizing _3 and redoing a simplification that has already been done.
Fixing FRE (assuming that is indeed the culprit) may be a bit hard for me, I'll
probably revert the patch when I get the chance (if anyone feels like doing it
earlier, be my guest, it is enough to revert the match.pd part), it needs more
work for the vector case anyway.

[Bug bootstrap/80887] gnat bootstrap fails at s-regpat.o: raised STORAGE_ERROR : stack overflow or erroneous memory access

[glisse at gcc dot gnu.org]

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

--- Comment #4 from Marc Glisse  ---
Created attachment 41427
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41427=edit
Reduced version of s-regpat.ad[bs]

[Bug bootstrap/80887] gnat bootstrap fails at s-regpat.o: raised STORAGE_ERROR : stack overflow or erroneous memory access

[glisse at gcc dot gnu.org]

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

--- Comment #3 from Marc Glisse  ---
Seems to me that it is FRE valueization doing something strange. We have (not
in a loop)

  _26 = CHAIN.23_25(D)->parse_pos;
  _28 = _26 + 1;
  CHAIN.23_25(D)->parse_pos = _28;
  _30 = CHAIN.23_25(D)->expression;
  _32 = _30->P_ARRAY;
  _33 = CHAIN.23_25(D)->parse_pos;
  parse_pos.11_2 = (sizetype) _33;
  _3 = parse_pos.11_2 + 4294967295;

and when, during the simplification of some later stmt that turns out to be
equivalent to _3, we call vn_nary_op_lookup_pieces on _26 (with a NOP to
sizetype), it returns _3, so obviously we loop.

[Bug target/80880] internal compiler error: in ix86_expand_builtin

[ienkovich at gcc dot gnu.org]

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

Ilya Enkovich  changed:

   What|Removed |Added

 CC||ienkovich at gcc dot gnu.org

--- Comment #2 from Ilya Enkovich  ---
It would be more preferable to avoid conditional replacement for bndret calls
but making such exception may require unintuitive fixes in various propagators.
We can loose returned bounds in some cases anyway, so I agree with proposed
patch.

Also it might make sense to handle NULL case because it is likely to be the
most popular propagated conditional value for pointers.

[Bug target/80848] /crtend.o(.eh_frame); no .eh_frame_hdr table will be created

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||rth at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #3 from Richard Henderson  ---
Dup.

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

[Bug libgcc/80037] Bad .eh_frame data in crtend.o

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

 CC||mitalis at iiitd dot ac.in

--- Comment #8 from Richard Henderson  ---
*** Bug 80848 has been marked as a duplicate of this bug. ***

[Bug libgcc/80037] Bad .eh_frame data in crtend.o

[stilor at att dot net]

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

--- Comment #7 from Alexey Neyman  ---
Can you close 80848 as a duplicate of this one?

[Bug libgcc/80037] Bad .eh_frame data in crtend.o

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

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

--- Comment #6 from Richard Henderson  ---
Fixed.

[Bug libgcc/80037] Bad .eh_frame data in crtend.o

[rth at gcc dot gnu.org]

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

--- Comment #5 from Richard Henderson  ---
Author: rth
Date: Fri May 26 19:33:19 2017
New Revision: 248526

URL: https://gcc.gnu.org/viewcvs?rev=248526=gcc=rev
Log:
PR libgcc/80037

 Backport from mainline
 * config/alpha/t-alpha (CRTSTUFF_T_CFLAGS): New.


Modified:
branches/gcc-6-branch/libgcc/ChangeLog
branches/gcc-6-branch/libgcc/config/alpha/t-alpha

[Bug libgcc/80037] Bad .eh_frame data in crtend.o

[rth at gcc dot gnu.org]

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

--- Comment #4 from Richard Henderson  ---
Author: rth
Date: Fri May 26 19:29:46 2017
New Revision: 248525

URL: https://gcc.gnu.org/viewcvs?rev=248525=gcc=rev
Log:
PR libgcc/80037

 Backport from mainline
 * config/alpha/t-alpha (CRTSTUFF_T_CFLAGS): New.


Modified:
branches/gcc-7-branch/libgcc/ChangeLog
branches/gcc-7-branch/libgcc/config/alpha/t-alpha

[Bug c/80892] [8 regression] -Wfloat-conversion now warns about non-floats

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-05-26
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed:

$ cat t.c && gcc -S -Wfloat-conversion t.c
void f (char);

void g (unsigned long x)
{
  f (x);
}
t.c: In function ‘g’:
t.c:5:6: warning: conversion from ‘long unsigned int’ to ‘char’ may change
value [-Wfloat-conversion]
   f (x);
  ^

The conversion changes were committed in r248431.  They weren't intended to
change how warnings are controlled so this is a bug.

[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 #2 from DIL  ---
I have fixed all issues reported by VALGRIND so the code now is valgrind-clean.
However, the problem I reported still shows up from time to time (only when the
code is compiled with -g and no optimization: BUILD_TYPE = DEV). The test which
fails depends on a number of source files, so I do not really see a clear way
to localize the problem in a small code snippet. In fact, the ALLOCATE()
statement which fails works just fine when called from other places. I thought
you might have some tools to inspect the ALLOCATE() code to see why it sees a
NULLIFIED pointer as ALLOCATED when the error message is triggered (the exact
location of the ALLOCATE statement is specified in the previous message). But I
am not sure how hard this would be. Also, I haven't had a chance to try the new
7.1 compiler.
Thanks,
Dmitry

[Bug other/80803] libgo appears to be miscompiled on powerpc64le since r247497

[pinskia at gcc dot gnu.org]

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

--- Comment #20 from Andrew Pinski  ---
(In reply to boger from comment #19)
> Is someone building and testing gccgo on x86_64 on a regular basis?  If I
> look at the gcc-testresults output for x86_64 I don't see the go or libgo
> test results like I do for ppc64le.  Maybe it does fail there too.

I am testing go on both x86_64 and aarch64:
latest results for go on x86_64 from me:
https://gcc.gnu.org/ml/gcc-testresults/2017-05/msg02832.html

latest results on aarch64 from me:
https://gcc.gnu.org/ml/gcc-testresults/2017-05/msg02770.html

[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0

[amonakov at gcc dot gnu.org]

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

--- Comment #8 from Alexander Monakov  ---
Well, at least it's not too late to update the compiler manual, so I've
submitted a patch: https://gcc.gnu.org/ml/gcc-patches/2017-05/msg02080.html

[Bug other/80803] libgo appears to be miscompiled on powerpc64le since r247497

[boger at us dot ibm.com]

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

--- Comment #19 from boger at us dot ibm.com ---
Is someone building and testing gccgo on x86_64 on a regular basis?  If I look
at the gcc-testresults output for x86_64 I don't see the go or libgo test
results like I do for ppc64le.  Maybe it does fail there too.

[Bug libgcc/80037] Bad .eh_frame data in crtend.o

[rth at gcc dot gnu.org]

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

--- Comment #3 from Richard Henderson  ---
Author: rth
Date: Fri May 26 18:45:59 2017
New Revision: 248522

URL: https://gcc.gnu.org/viewcvs?rev=248522=gcc=rev
Log:
PR libgcc/80037

 * config/alpha/t-alpha (CRTSTUFF_T_CFLAGS): New.

Modified:
trunk/libgcc/ChangeLog
trunk/libgcc/config/alpha/t-alpha

[Bug libstdc++/80893] New: std::vector creation dereferences null pointer

[terra at gnome dot org]

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

Bug ID: 80893
   Summary: std::vector creation dereferences null pointer
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: terra at gnome dot org
  Target Milestone: ---

Created attachment 41426
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41426=edit
g++ -E output, just in case it's needed

It looks like copying a pristine vector or initializing one
with an explicit length of zero involves dereferencing a null pointer
although nothing is actually done with the result.  -fsanitize is unhappy
with that.


# cat test.C
#include 

int main() {
  // OK
  std::vector a;

  // Fails.
  std::vector b(a);

  // Fails.
  std::vector c(0);

  (void)a;
  (void)b;
  (void)c;
  return 0;
}


# /usr/local/products/gcc/7.1.0/bin/g++ -v -D_GLIBCXX_DEBUG
-fsanitize=undefined -O test.C -Wl,-rpath,/usr/local/products/gcc/7.1.0/lib64
-fsanitize=undefined
Using built-in specs.
COLLECT_GCC=/usr/local/products/gcc/7.1.0/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/products/gcc/7.1.0/lib/gcc/x86_64-suse-linux/7.1.0/lto-wrapper
Target: x86_64-suse-linux
Configured with: ../../gcc-7.1.0/configure --enable-languages=c,c++,fortran
--enable-targets=x86_64-suse-linux,i686-suse-linux
--prefix=/usr/local/products/gcc/7.1.0 --with-gnu-as
--with-as=/usr/local/products/gcc/binutils-2.26/bin/as --with-gnu-ld
--with-ld=/usr/local/products/gcc/binutils-2.26/bin/ld.bfd
--with-gmp=/usr/local/products/gcc/gmp-6.1.0
--with-mpfr=/usr/local/products/gcc/mpfr-3.1.4
--with-mpc=/usr/local/products/gcc/mpc-1.0.3 --enable-threads=posix
--enable-shared --enable-__cxa_atexit --enable-libstdcxx-allocator=pool
x86_64-suse-linux
Thread model: posix
gcc version 7.1.0 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-D' '_GLIBCXX_DEBUG' '-fsanitize=undefined' '-O'
'-fsanitize=undefined' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/local/products/gcc/7.1.0/lib/gcc/x86_64-suse-linux/7.1.0/cc1plus -quiet
-v -D_GNU_SOURCE -D _GLIBCXX_DEBUG test.C -quiet -dumpbase test.C
-mtune=generic -march=x86-64 -auxbase test -O -version -fsanitize=undefined
-fsanitize=undefined -o /tmp/ccjJFQr4.s
GNU C++14 (GCC) version 7.1.0 (x86_64-suse-linux)
compiled by GNU C version 7.1.0, GMP version 6.1.0, MPFR version 3.1.4,
MPC version 1.0.3, isl version none
warning: MPFR header version 3.1.4 differs from library version 3.1.3.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
"/usr/local/products/gcc/7.1.0/lib64/gcc/x86_64-suse-linux/7.1.0/../../../../x86_64-suse-linux/include"
#include "..." search starts here:
#include <...> search starts here:

/usr/local/products/gcc/7.1.0/lib64/gcc/x86_64-suse-linux/7.1.0/../../../../include/c++/7.1.0

/usr/local/products/gcc/7.1.0/lib64/gcc/x86_64-suse-linux/7.1.0/../../../../include/c++/7.1.0/x86_64-suse-linux

/usr/local/products/gcc/7.1.0/lib64/gcc/x86_64-suse-linux/7.1.0/../../../../include/c++/7.1.0/backward
 /usr/local/products/gcc/7.1.0/lib64/gcc/x86_64-suse-linux/7.1.0/include
 /usr/local/include
 /usr/local/products/gcc/7.1.0/include
 /usr/local/products/gcc/7.1.0/lib64/gcc/x86_64-suse-linux/7.1.0/include-fixed
 /usr/include
End of search list.
GNU C++14 (GCC) version 7.1.0 (x86_64-suse-linux)
compiled by GNU C version 7.1.0, GMP version 6.1.0, MPFR version 3.1.4,
MPC version 1.0.3, isl version none
warning: MPFR header version 3.1.4 differs from library version 3.1.3.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 2b9455e910d94e4d2b3b828bd090b81a
COLLECT_GCC_OPTIONS='-v' '-D' '_GLIBCXX_DEBUG' '-fsanitize=undefined' '-O'
'-fsanitize=undefined' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/local/products/gcc/binutils-2.26/bin/as -v --64 -o /tmp/ccJ4ZfpM.o
/tmp/ccjJFQr4.s
GNU assembler version 2.26 (x86_64-suse-linux) using BFD version (GNU Binutils)
2.26.20160125
COMPILER_PATH=/usr/local/products/gcc/7.1.0/lib/gcc/x86_64-suse-linux/7.1.0/:/usr/local/products/gcc/7.1.0/lib/gcc/x86_64-suse-linux/7.1.0/:/usr/local/products/gcc/7.1.0/lib/gcc/x86_64-suse-linux/:/usr/local/products/gcc/7.1.0/lib64/gcc/x86_64-suse-linux/7.1.0/:/usr/local/products/gcc/7.1.0/lib64/gcc/x86_64-suse-linux/
LIBRARY_PATH=/usr/local/products/gcc/7.1.0/lib64/gcc/x86_64-suse-linux/7.1.0/:/usr/local/products/gcc/7.1.0/lib64/gcc/x86_64-suse-linux/7.1.0/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/local/products/gcc/7.1.0/lib64/gcc/x86_64-suse-linux/7.1.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-D' '_GLIBCXX_DEBUG' '-fsanitize=undefined' '-O'
'-fsanitize=undefined' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/local/products/gcc/7.1.0/lib/gcc/x86_64-suse-linux/7.1.0/collect2 -plugin

[Bug other/80803] libgo appears to be miscompiled on powerpc64le since r247497

[ian at airs dot com]

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

--- Comment #18 from Ian Lance Taylor  ---
Lynn, thanks for the detailed investigation.

Martin, Lynn is saying that these problems started with the SRA patch for PR
78687 committed on 2017-05-02.

It's odd that this problem only shows up on PPC64LE, not on x86_64.

In this case we have a three element struct, and we are passing the address of
the struct to a function.  Somehow the writes to two of the fields of the
struct are being dropped.  But since we are taking the address anyhow, I'm not
sure precisely where SRA is kicking in.

[Bug other/80803] libgo appears to be miscompiled on powerpc64le since r247497

[boger at us dot ibm.com]

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

--- Comment #17 from boger at us dot ibm.com ---
Here's more info on the failures and how to reproduce them.  Starting with
commit 247497 there are 7 new failures in the libgo testsuite.

There are 4 that fail with a SEGV at runtime: reflect, archive/tar,
mime/multipart, and net/mail. I looked at 2 and their stacks look similar but
not quite the same.  The SEGV happens because a 0 is passed as the address of
the src argument.

archive/tar shows a stack like this at the point of the SEGV:
Program received signal SIGSEGV, Segmentation fault.
__memcpy_power7 () at ../sysdeps/powerpc/powerpc64/power7/memcpy.S:219
219 ../sysdeps/powerpc/powerpc64/power7/memcpy.S: No such file or
directory.
(gdb) bt
#0  __memcpy_power7 () at ../sysdeps/powerpc/powerpc64/power7/memcpy.S:219
#1  0x3fffb6350918 in __GI_memmove (dest=0xc208086600, src=,
len=) at ../sysdeps/powerpc/memmove.c:54
#2  0x3fffb71567bc in runtime.memmove (p1=, p2=, len=)
at ../../../src/libgo/runtime/go-memmove.c:15
#3  0x3fffb7620fd8 in runtime.typedmemmove (typ=,
dst=, src=)
at ../../../src/libgo/go/runtime/stubs.go:298
#4  0x3fffb76215bc in reflect.typedmemmove (typ=,
dst=, src=)
at ../../../src/libgo/go/runtime/stubs.go:304
#5  0x3fffb75c8384 in reflect.packEface (v=...) at
../../../src/libgo/go/reflect/value.go:113
#6  reflect.valueInterface (param=..., safe=true) at
../../../src/libgo/go/reflect/value.go:821
#7  0x3fffb75c8760 in reflect.Interface.N13_reflect.Value
(pointer=) at ../../../src/libgo/go/reflect/value.go:781
#8  0x3fffb72e570c in fmt.printValue.pN6_fmt.pp (p=,
param=..., verb=, depth=)
at ../../../src/libgo/go/fmt/print.go:694
#9  0x3fffb72e623c in fmt.printValue.pN6_fmt.pp (p=,
param=..., verb=, depth=)

With gdb I found that when reflect.typedmemmove calls runtime.typedmemmove, it
is passing a bad argument for the src.

Something similar happens in the reflect test, although that SEGV stack looks
like this:
288 ../sysdeps/powerpc/powerpc64/power7/memcpy.S: No such file or
directory.
(gdb) bt
#0  __memcpy_power7 () at ../sysdeps/powerpc/powerpc64/power7/memcpy.S:288
#1  0x3fffb6350918 in __GI_memmove (dest=0xc20800b6d0, src=,
len=) at ../sysdeps/powerpc/memmove.c:54
#2  0x3fffb71567bc in runtime.memmove (p1=, p2=, len=)
at ../../../src/libgo/runtime/go-memmove.c:15
#3  0x3fffb762165c in runtime.typedslicecopy (typ=, dst=...,
src=...) at ../../../src/libgo/go/runtime/stubs.go:329
#4  0x3fffb76216cc in reflect.typedslicecopy (elemType=,
dst=..., src=...) at ../../../src/libgo/go/runtime/stubs.go:336
#5  0x10052c6c in reflect.Copy (param=..., param=...) at value.go:1747
#6  0x100529f4 in reflect.AppendSlice (param=..., param=...) at
value.go:1702
#7  0x10069514 in reflect_test.TestAppend (t=) at
all_test.go:534

And the bad address is passed for the src argument for the call from
reflect.typedslicecopy to runtime.typedslicecopy.

The tests for fmt, net, and debug/dwarf fail when processing code that calls
reflect.DeepEqual followed by a call to Errorf, something like this:

if out := ParseIP(tt.in); !reflect.DeepEqual(out, tt.out) {
  t.Errorf("ParseIP(%q) = %v, want %v", tt.in, out, tt.out)
}

The argument for tt.out is passed incorrectly to DeepEqual, causing it to
return false when it shouldn't, and then passes bad information to the Errorf
function.

I've tried to reproduce this in a smaller testcase but haven't been able to.  I
run these tests after a build by first editing the src/libgo/testsuite/gotest
to set keep=true and trace=true.  Then I go to my bld directory:

cd bld/powerpc64le-linux/libgo
make fmt/check

That should give you output with the full gccgo command to build the test, the
directory containing the a.out and files from the test.  The name of the
directory is gotestx.

FAIL
Keeping gotest32163
FAIL: fmt
Makefile:3331: recipe for target 'fmt/check' failed

[Bug c/80892] New: [8 regression] -Wfloat-conversion now warns about non-floats

[egall at gwmail dot gwu.edu]

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

Bug ID: 80892
   Summary: [8 regression] -Wfloat-conversion now warns about
non-floats
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: egall at gwmail dot gwu.edu
CC: msebor at gcc dot gnu.org
  Target Milestone: ---
  Host: i386-apple-darwin10.8.0
Target: i386-apple-darwin10.8.0
 Build: i386-apple-darwin10.8.0

Previously, it was possible to request warnings about just conversions
involving floating point types by specifying -Wfloat-conversion. However, with
my latest build from trunk, -Wfloat-conversion seems to have become an alias
for -Wconversion, meaning that it now warns on things like:

/usr/local/bin/gcc -c -DHAVE_CONFIG_H -g -O2 -arch i386  -I. -I./../include
-D_DARWIN_UNLIMITED_STREAMS -mmacosx-version-min=10.5 -Wall -Wextra
-Wwrite-strings -Wc++-compat -Wodr -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-parameter-type -Wmissing-declarations -Wnested-externs -Wundef
-Wshadow -Wformat=2 -Wformat-overflow=2 -Wformat-truncation=2
-Wstringop-overflow=2 -Walloc-zero -Wrestrict -Wold-style-definition
-Wold-style-declaration -Wfloat-conversion -Wabi -Wc99-c11-compat
-Wmisleading-indentation -Wnull-dereference -Wpointer-compare -Wbool-operation
-pedantic  ./cp-demangle.c -o cp-demangle.o
./cp-demangle.c: In function 'd_print_java_identifier':
./cp-demangle.c:3473:27: warning: conversion from 'long unsigned int' to 'char'
may change value [-Wfloat-conversion]
d_append_char(dpi, c);
   ^

This means I now have a bunch of new warnings in my build where I previously
didn't, because I'm only using -Wfloat-conversion and not the full
-Wconversion. cc-ing Martin Sebor since he was the last one I remember seeing
posting patches touching the -Wconversion code.

gcc version info:
$ /usr/local/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/bin/gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i386-apple-darwin10.8.0/8.0.0/lto-wrapper
Target: i386-apple-darwin10.8.0
Configured with: ../configure --disable-werror --disable-werror-always
--enable-languages=c,c++,objc,obj-c++,lto --enable-stage1-checking=release,rtl
-C --with-system-libunwind --enable-secureplt --enable-frame-pointer
--enable-debug --without-isl --disable-host-shared --enable-maintainer-mode
--disable-default-pie --with-ld64 --without-pic --enable-target-optspace
--disable-nls --with-system-zlib --with-libiconv-prefix=/opt/local
--with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local --enable-lto
--enable-libstcxx-time --with-build-config=bootstrap-debug
--with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld
--with-ar=/opt/local/bin/ar --enable-objc-gc --enable-libada --enable-libssp
CC='/usr/bin/gcc-4.2 -arch i386 -arch x86_64' CXX='/usr/bin/g++-4.2 -arch
x86_64' AR_FOR_TARGET=/opt/local/bin/ar AS_FOR_TARGET=/opt/local/bin/as
LD_FOR_TARGET=/opt/local/bin/ld NM_FOR_TARGET=/opt/local/bin/nm
RANLIB_FOR_TARGET=/opt/local/bin/ranlib STRIP_FOR_TARGET=/opt/local/bin/strip
OTOOL=/opt/local/bin/otool OTOOL64=/opt/local/bin/otool
AUTOCONF=/opt/local/bin/autoconf264 AUTOHEADER=/opt/local/bin/autoheader264
AUTOM4TE=/opt/local/bin/autom4te264 AUTORECONF=/opt/local/bin/autoreconf264
AUTOSCAN=/opt/local/bin/autoscan264 AUTOUPDATE=/opt/local/bin/autoupdate264
IFNAMES=/opt/local/bin/ifnames264 ACLOCAL=/sw/bin/aclocal-1.11
PERL=/opt/local/bin/perl CFLAGS='-pipe -g -Os' CXXFLAGS='-pipe -g -Os
-fcheck-new' CPP='/usr/bin/gcc-4.2 -E' CXXCPP='/usr/bin/g++-4.2 -E'
M4=/opt/local/bin/gm4
Thread model: posix
gcc version 8.0.0 20170525 (experimental) (GCC)

[Bug c++/80891] [8 Regression] Three new ICEs

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-26
   Assignee|unassigned at gcc dot gnu.org  |nathan at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug fortran/80889] [8 Regression] Bootstrap broken on all targets due to rev 248472

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

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

[Bug c++/80891] New: [8 Regression] Three new ICEs

[trippels at gcc dot gnu.org]

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

Bug ID: 80891
   Summary: [8 Regression] Three new ICEs
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
CC: nathan at gcc dot gnu.org
  Target Milestone: ---

1)

 % cat chi_square_std_dev_test.ii
namespace std {
struct A {
  void operator<<(A(A));
};
template  _CharT endl(_Traits);
A a;
}
using std::endl;
void chi_squared_sample_sized() {
  using namespace std;
  a << endl;
}

 % g++ -c chi_square_std_dev_test.ii
chi_square_std_dev_test.ii: In function ‘void chi_squared_sample_sized()’:
chi_square_std_dev_test.ii:11:8: internal compiler error: in get_bindings, at
cp/pt.c:21559
   a << endl;
^~~~
0x7b3a35 get_bindings
../../gcc/gcc/cp/pt.c:21559
0x7b3af5 more_specialized_inst
../../gcc/gcc/cp/pt.c:21692
0x7b3c31 most_specialized_instantiation(tree_node*)
../../gcc/gcc/cp/pt.c:21732
0x5eef43 resolve_address_of_overloaded_function
../../gcc/gcc/cp/class.c:8251
0x5ccdf6 standard_conversion
../../gcc/gcc/cp/call.c:1123
0x5daef8 implicit_conversion
../../gcc/gcc/cp/call.c:1839
0x5dc896 add_function_candidate
../../gcc/gcc/cp/call.c:2196
0x5de6b7 add_candidates
../../gcc/gcc/cp/call.c:5479
0x5e6269 add_candidates
../../gcc/gcc/cp/call.c:5379
0x5e6269 build_new_op_1
../../gcc/gcc/cp/call.c:5653
0x5e6b3e build_new_op(unsigned int, tree_code, int, tree_node*, tree_node*,
tree_node*, tree_node**, int)
../../gcc/gcc/cp/call.c:6009
0x815de2 build_x_binary_op(unsigned int, tree_code, tree_node*, tree_code,
tree_node*, tree_code, tree_node**, int)
../../gcc/gcc/cp/typeck.c:3957
0x72e894 cp_parser_binary_expression
../../gcc/gcc/cp/parser.c:9051
0x72efe4 cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:9184
0x732e28 cp_parser_expression
../../gcc/gcc/cp/parser.c:9353
0x73b698 cp_parser_expression_statement
../../gcc/gcc/cp/parser.c:10912
0x7208e6 cp_parser_statement
../../gcc/gcc/cp/parser.c:10728
0x7219ad cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:11054
0x721a7f cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:11008
0x722198 cp_parser_function_body
../../gcc/gcc/cp/parser.c:21445

2)

 % cat ptr_vector.ii
void swap();
namespace boost {   
void swap();
}   
using namespace boost;  
template  void reversible_container_test() {
  using namespace boost;
  C a;  
  swap(a);  
}   
namespace boost {   
struct A {};
template  void swap();
}   
void test_ptr_vector() { reversible_container_test; } 

 % g++ -c ptr_vector.ii
ptr_vector.ii: In instantiation of ‘void reversible_container_test() [with C =
boost::A;  = int;  = int]’: 
ptr_vector.ii:15:64:   required from here   
ptr_vector.ii:9:7: internal compiler error: in ovl_copy, at cp/tree.c:2142  
   swap(a); 
   ^~~
0x7f7812 ovl_copy   
../../gcc/gcc/cp/tree.c:2142
0x7fc4e7 lookup_maybe_add(tree_node*, tree_node*)   
../../gcc/gcc/cp/tree.c:2383
0x6f951a name_lookup::add_fns(tree_node*)   
../../gcc/gcc/cp/name-lookup.c:688  
0x6f98ff name_lookup::adl_namespace(tree_node*) 
../../gcc/gcc/cp/name-lookup.c:714  
0x6f98ff name_lookup::adl_class_only(tree_node*)
../../gcc/gcc/cp/name-lookup.c:740  
0x6f9c3e name_lookup::adl_bases(tree_node*) 
../../gcc/gcc/cp/name-lookup.c:774  
0x6fa094 name_lookup::adl_class(tree_node*) 
../../gcc/gcc/cp/name-lookup.c:817  
0x6fae3c name_lookup::search_adl(tree_node*, vec*) 
../../gcc/gcc/cp/name-lookup.c:1001 
0x6faef4 lookup_arg_dependent(tree_node*, tree_node*, vec*) 
../../gcc/gcc/cp/name-lookup.c:1026 
0x7d6786 perform_koenig_lookup(cp_expr, vec*, int) 
../../gcc/gcc/cp/semantics.c:2270   
0x7903c0 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)  
../../gcc/gcc/cp/pt.c:17253 
0x77ec33 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) 
../../gcc/gcc/cp/pt.c:16514 
0x77d3ae tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) 

[Bug fortran/80889] [8 Regression] Bootstrap broken on all targets due to rev 248472

[tkoenig at gcc dot gnu.org]

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

--- Comment #2 from Thomas Koenig  ---
Author: tkoenig
Date: Fri May 26 17:16:35 2017
New Revision: 248519

URL: https://gcc.gnu.org/viewcvs?rev=248519=gcc=rev
Log:
2017-05-26  Thomas Koenig  

PR boostrap/80889
* acinclude.m4: Also set HAVE_AVX128 on the false
branch of LIBGFOR_CHECK_AVX128.
* configure:  Regenerated.


Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/acinclude.m4
trunk/libgfortran/configure

[Bug bootstrap/80887] gnat bootstrap fails at s-regpat.o: raised STORAGE_ERROR : stack overflow or erroneous memory access

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Trying to print captures in the frame that calls gimple_simplify_135 I see it
oscillating between:
parse_pos.474_23
4294967295
4294967295

and

_78
1
4294967294

(captures[0..2]).

  _76 = CHAIN.552_67(D)->parse_pos;
  _78 = _76 + 1;
...
  _115 = CHAIN.552_67(D)->parse_pos;
  parse_pos.474_23 = (sizetype) _115;
  _24 = parse_pos.474_23 + 4294967295;

[Bug c++/80890] Qualified class member access in a member initialization

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
Dup of Bug 52595, fixed by 224152

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

[Bug c++/52595] [DR 325] commas and non-static data member initializers don't mix

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||sergi.mateo at bsc dot es

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

[Bug bootstrap/80887] gnat bootstrap fails at s-regpat.o: raised STORAGE_ERROR : stack overflow or erroneous memory access

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||glisse at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
For me r248443 works (well, I had to add 0 && in
maybe_warn_about_cast_ignoring_quals because there are two different bootstrap
failures caused by that), while r248453 fails.  As the ICE is in wide_int
handling from const_binop from match.pd, and the closest match.pd line is 1308
in gimple-match.c in the backtrace, I suspect r248448.

[Bug libgomp/80822] libgomp incorrect affinity when OMP_PLACES=threads

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
Should apply cleanly against 6.x, 7.x as well as current trunk.

[Bug libgomp/80822] libgomp incorrect affinity when OMP_PLACES=threads

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

So far untested patch that should implement what from the above dumps Intel
runtime seems to implement, i.e. always walk process all (available) OS cpus
from each socket and within each socket all (available) OS cpus for each core,
just depending on threads/cores/sockets choose what to put together into
individual places vs. when to start a new place.

[Bug c++/80859] Performance Problems with OpenMP 4.5 support

[thorstenkurth at me dot com]

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

--- Comment #26 from Thorsten Kurth  ---
Hello Jakub,

thanks for the clarification. So a team maps to a CTA which is somewhat
equivalent to a block in CUDA language, correct? And it is good to have some
categorical equivalency between GPU and CPU code (SIMD units <> WARPS) instead
of mapping SIMT threads to OpenMP threads, that makes it easier for making it
portable. 

About my mapping "problem" is there an elegant way for doing this or does only
brute force work, i.e. by writing additional member functions returning
pointers etc.?
In general, the OpenMP mapping business is very verbose (not your fault, I
know), it makes the code very annoying to read.

Best
Thorsten

[Bug fortran/35339] Improve translation of implied do loop in transfer

[jvdelisle at gcc dot gnu.org]

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

--- Comment #8 from Jerry DeLisle  ---
(In reply to Nicolas Koenig from comment #7)
> Created attachment 41420 [details]
> Early patch for simplifying impl do loops - 2
> 
> Sorry, wrong patch _and_ wrong testcase... Still fails for mysterious
> reasons, though.

I was thinking the whole change would be in trans-io.c. This was before
frontend-passes.c existed.

[Bug fortran/80889] [8 Regression] Bootstrap broken on all targets due to rev 248472

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-05-26
   Assignee|unassigned at gcc dot gnu.org  |tkoenig at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Thomas Koenig  ---
I broke it, so I'll fix it.

[Bug c++/80859] Performance Problems with OpenMP 4.5 support

[jakub at gcc dot gnu.org]

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

--- Comment #25 from Jakub Jelinek  ---
In the GCC implementation of offloading to PTX, all HW threads in a warp (i.e.
32 of them) are a single OpenMP thread, and one needs to use a simd region
(effectively SIMT) to get useful work done by all all the threads of a warp
rather than just one.
Right now GCC doesn't do auto-SIMTization (but does auto-vectorization on the
host or XeonPhi accelerator etc., but only with -O3 or -O2 -ftree-vectorize;
while with simd constructs you get it even with just -O2 -fopenmp for those
regions), so simd construct is important to get the right performance.  Threads
within a team are the warp groups of threads within a PTX CTA, and different
teams are the CTAs in a CTA grid (in PTX terms).

[Bug c++/80859] Performance Problems with OpenMP 4.5 support

[thorstenkurth at me dot com]

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

--- Comment #24 from Thorsten Kurth  ---
Hello Jakub,

I know that the section you mean is racey and gets the wrong number of threads
is not right but I put this in in order to see if I get the correct numbers on
a CPU (I am not working on a GPU yet, that will be next). Most of the defines
for setting number of teams and threads in outer loop are for playing around
with that and see what works best, in the end this will be removed. This code
is not finished by any means, it is a moving target and under active
development. Only the OpenMP3 version is considered done and works well.

You said that SIMD pragmas is missing, and this is for a reason. First of all,
the code is memory bandwidth bound, so it has a rather low AI so that
vectorization does not help a lot. Of course vectorization helps in the sense
that the loads and stores are vectorized and the prefetcher works more
efficiently. But we made sure that the (Intel) compiler vectorizes the inner
loops automatically nicely. Putting in explicit SIMD pragmas made the code
performance worse, because in that case the (Intel) compiler generates worse
code in some cases (according to some Intel compiler guys, this is because if
the compiler sees a SIMD statement it will not try to partially unroll loops
etc. and might generate more masks than necessary). So auto vectorization works
fine here so we have not revisited this issue. The GNU compiler might be
different and I did not look at what the auto-vectorizer did.

The more important questions I have are the following:
1) as you see the codes has two levels of parallelism. On the CPU, it is most
efficient to tile the boxes (this is the loop with the target distribute) and
then let one thread work on a box. I added another level of parallelism inside
that box, because on the GPU you have more thread and might want to exploit
more parallelism. Talking to folks from IBM at an OpemMP 4.5 hackathon at least
this is what they suggested. 
So my question is: when you have a target teams distribute, will be one team
equal to a CUDA WARP or will it be something bigger? In that case, I would like
to have one WARP working on a box and not letting different ptx threads working
on individual boxes. To summarize: on the CPU the OpenMP threading should be
such that one threads gets a box and the vectorization works on the inner loop
(which is fine, that works), and in the CUDA case one team/WARP should work on
a box and then SIMT parallelize the work on the box.

2) related to this: how does ptx behave when it sees a SIMD statement in a
target region? Is that ignored or somehow interpreted? In any case, how does
OpenMP do the mapping between CUDA WARP <-> OpenMP CPU thread, because this is
the closest equivalence I would say. I would guess it ignores SIMD pragmas and
just acts on thread level, where in the CUDA world one thread more or less acts
like a SIMD lane on the CPU.

3) this device mapping business is extremely verbose for C++ classes. For
example the MFIter class amfi, comfy, solnLmfi whatever are not correctly
mapped yet and would cause trouble on the GPU (the intel compiler complains
that the stuff is not bitwise copyable, GNU complies it though). These are
classes containing other class pointers. So in order to map that properly I
would technically need to map the dereferenced data member of the member class
of the first class, correct? As an example, you have a class with
std::vector * vector data member. You technically need to map the
vector.data() member to the device, right? That however tells you that you need
to be able to access that guy, i.e. it should not be a protected class member.
So what happens when you have a class which you cannot change but need to map
private/protected members of it? The example at hand is the MFIter class which
has this:

protected:

const FabArrayBase& fabArray;

IntVect tile_size;

unsigned char flags;
int   currentIndex;
int   beginIndex;
int   endIndex;
IndexType typ;

const Array* index_map;
const Array* local_index_map;
const Array* tile_array;

void Initialize ();

It has these array pointers. So technically this is (to my knowledge, I do not
know the code fully) an array of indices which determines which global indices
the iterator is in fact iterating over. This stuff can be shared among the
threads and it is only read and never written. Nevertheless, it needs to know
the indices on the device so the index_map etc. needs to be mapped. Now, Array
is just a class with a public member of std::vector. But in order to map the
index_map class member I would need to have access to it, so that I can map the
underlying std::vector data member. Do you know what I mean? How is this done
in the most elegant way in OpenMP?

[Bug other/80803] libgo appears to be miscompiled on powerpc64le since r247848

[boger at us dot ibm.com]

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

--- Comment #16 from boger at us dot ibm.com ---
After further investigation I found the original testcase failures started
happening with an earlier commit, which I have verified as 247497.  That commit
caused 7 new libgo testcase failures, but at the time, it didn't cause the
error log to grow excessively so went unnoticed.  When the large gofrontend
change went in, then the same failures occurred but it was at that point when
the information written to the error log grew to an excessive size.  Probably
due to the random nature of the original bug.

One additional note, when debugging a few other failures, I found that when
calling runtime.typedmemmove from reflect.typedmemmove, the second argument is
not being initialized, which results in a SEGV for some tests (reflect,
archive/tar, mime/multipart).  It might be easier to compile the file
containing reflect.typedmemmove and dump out the intermediate output?

[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

--- Comment #5 from amker at gcc dot gnu.org ---
Author: amker
Date: Fri May 26 14:18:26 2017
New Revision: 248512

URL: https://gcc.gnu.org/viewcvs?rev=248512=gcc=rev
Log:
PR tree-optimization/80815
* tree-data-ref.c (prune_runtime_alias_test_list): Simplify condition
for merging runtime alias checks.  Handle negative DR_STEPs.
gcc/testsuite
* gcc.dg/vect/pr80815-1.c: New test.
* gcc.dg/vect/pr80815-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/vect/pr80815-1.c
trunk/gcc/testsuite/gcc.dg/vect/pr80815-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-data-ref.c

[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
Since this makes libatomic required for DCAS on x86_64 it should probably have
been documented at https://gcc.gnu.org/gcc-7/changes.html

[Bug c++/80890] New: Qualified class member access in a member initialization

[sergi.mateo at bsc dot es]

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

Bug ID: 80890
   Summary: Qualified class member access in a member
initialization
   Product: gcc
   Version: 5.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sergi.mateo at bsc dot es
  Target Milestone: ---

The following C++11 code doesn't compile with g++ 5.4.1, although it compiles
fine with g++ 6:

template < typename _K, typename _V >
class  A
{
int x;
int *px =  // OK
int *qx = >x;   // OK
int *rx = &(*this).x; // OK
int *sx = &((*this).::A<_K, _V>::x); // OK
int *tx = &(*this).::A<_K, _V>::x;   // KO
};

The error message is the following one:

g++ -c t1.cc -std=c++11

t1.cc:9:36: error: expected ‘;’ at end of member declaration
 int *tx = &(*this).::A<_K, _V>::x;   // KO
^
t1.cc:9:36: error: declaration of ‘int A<_K, _V>::_V’
t1.cc:1:25: error:  shadows template parm ‘class _V’
 template < typename _K, typename _V >
 ^
t1.cc:9:38: error: expected unqualified-id before ‘>’ token
 int *tx = &(*this).::A<_K, _V>::x;   // KO
  ^
t1.cc:9:32: error: wrong number of template arguments (1, should be 2)
 int *tx = &(*this).::A<_K, _V>::x;   // KO
^
t1.cc:2:8: note: provided for ‘template class A’
 class  A


Best regards,
Sergi

[Bug fortran/80889] New: [8 Regression] Bootstrap broken on all targets due to rev 248472

[wilco at gcc dot gnu.org]

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

Bug ID: 80889
   Summary: [8 Regression] Bootstrap broken on all targets due to
rev 248472
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wilco at gcc dot gnu.org
  Target Milestone: ---

As reported in https://gcc.gnu.org/ml/gcc-patches/2017-05/msg01995.html all
bootstraps fail:

configure: error: conditional "HAVE_AVX128" was never defined.
Usually this means the macro was only invoked conditionally.
Makefile:19843: recipe for target 'configure-target-libgfortran' failed
make[1]: *** [configure-target-libgfortran] Error 1
make[1]: *** Waiting for unfinished jobs

Even if you disable this error, bootstrap fails due to trying to build x86
specific files:

gcc/libgfortran/generated/matmulavx128_i1.c  -fPIC -DPIC -o
.libs/matmulavx128_i1.o
xgcc: error: unrecognized command line option ‘-mprefer-avx128’
make[3]: *** [matmulavx128_i1.lo] Error 1

[Bug sanitizer/80350] UBSAN changes code semantics when -fno-sanitize-recover=undefined is used

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #8 from Martin Liška  ---
As the patch can't be easily ported to GCC 5, I'm not planning to backport to
the branch. Thus closing as resolved.

[Bug ada/80888] Wide_Text_IO defaults to bracket encoding even if -gnatW8 specified

[simon at pushface dot org]

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

--- Comment #1 from simon at pushface dot org ---
Created attachment 41424
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41424=edit
Demonstrator

[Bug ada/80888] New: Wide_Text_IO defaults to bracket encoding even if -gnatW8 specified

[simon at pushface dot org]

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

Bug ID: 80888
   Summary: Wide_Text_IO defaults to bracket encoding even if
-gnatW8 specified
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: simon at pushface dot org
  Target Milestone: ---
  Host: x86_64-apple-darwin15

The GNAT reference manual says in 11.6 Wide_Text_IO
,

   "The default encoding method for the standard files, and for opened
   files for which no WCEM parameter is given in the FORM string matches
   the wide character encoding specified for the main program (the
   default being brackets encoding if no coding method was specified with
   -gnatW)."

This is slightly wrong, in that the UTF-8 coding method is selected
even in the absence of -gnatW8 if the main program's source file has
the appropriate BOM; but the point of this PR is that it is not in
fact true, and even if -gnatW8 is given files are created/opened with
bracket encoding unless the Form parameter is given (Form => "wcem=8").

The attached demonstrator shows this. The file as uploaded begins with
EF BB BF, but compile with -gnatW8 to be sure:

$ gnatmake utf8_encoding -gnatW8
gcc -c -gnatW8 utf8_encoding.adb
gnatbind -x utf8_encoding.ali
gnatlink utf8_encoding.ali
$ ./utf8_encoding 

Two files are created, one without the Form parameter:

   $ od -tx1 -c -N32 file_without_form 
   0005b  22  30  33  43  30  22  5d  72  b2  68  0a
  [   "   0   3   C   0   "   ]   r 262   h  \n
   014

and one with:

   $ od -tx1 -c -N32 file_with_form 
   000cf  80  72  c2  b2  68  0a
  π  **   r   ²  **   h  \n
   007

[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

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

--- Comment #6 from Alexander Monakov  ---
There's a bit of a misunderstanding here, the -mcx16 option remains supported,
and the compiler remains capable of issuing lock-cmpxchg16b for __sync
builtins, in particular for __sync_val_compare_and_swap. What changed in gcc-7
is that __atomic builtins that would previously get expanded to a sequence
involving cmpxchg16b now always yield a library call on x86, but libatomic
tries to support that efficiently by using cmpxchg16b internally, on CPUs that
have it and on targets that support IFUNC.

No bug here, rather a (non-obvious imho) design change.

[Bug libgomp/80822] libgomp incorrect affinity when OMP_PLACES=threads

[weeks at iastate dot edu]

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

--- Comment #9 from Nathan Weeks  ---
Created attachment 41423
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41423=edit
Code from 80822 comment #4 run as per comment #8

[Bug bootstrap/80867] gnat bootstrap broken on powerpc64le-linux-gnu with -O3

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Target|powerpc64le-linux-gnu,  |powerpc64le-linux-gnu
   |x86_64-apple-darwin16,  |
   |sparc-sun-solaris2.12,  |
   |i386-pc-solaris2.12 |

--- Comment #7 from Jonathan Wakely  ---
I've created Bug 80887 for the trunk error affecting all targets, so this can
stay specific to the powerpc64le one on gcc-7-branch

[Bug bootstrap/80887] New: gnat bootstrap fails at s-regpat.o: raised STORAGE_ERROR : stack overflow or erroneous memory access

[redi at gcc dot gnu.org]

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

Bug ID: 80887
   Summary: gnat bootstrap fails at s-regpat.o: raised
STORAGE_ERROR : stack overflow or erroneous memory
access
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

I just got the following building trunk on x86_64-pc-linux-gnu with no special
flags, just $srcdir/configure --enable-languages=c,c++,ada --enable-werror


/home/jwakely/src/gcc/bootstrap/./gcc/xgcc
-B/home/jwakely/src/gcc/bootstrap/./gcc/ -B/usr/local/x86_64-pc-linux-gnu/bin/
-B/usr/local/x86_64-pc-linux-gnu/lib/ -isystem
/usr/local/x86_64-pc-linux-gnu/include -isystem
/usr/local/x86_64-pc-linux-gnu/sys-include-c -g -O2 -m32 -fpic  -W -Wall
-gnatpg -nostdinc -m32  s-regpat.adb -o s-regpat.o

raised STORAGE_ERROR : stack overflow or erroneous memory access
../gcc-interface/Makefile:296: recipe for target 's-regpat.o' failed


According to Bug 80867 comment 5 and Bug 80867 comment 6 this also happens on
darwin and solaris. It started between r248423 and r248462

[Bug sanitizer/80350] UBSAN changes code semantics when -fno-sanitize-recover=undefined is used

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Known to work||6.3.1
  Known to fail|6.3.1   |

--- Comment #7 from Martin Liška  ---
Fixed on GCC 6 branch.

[Bug ipa/79931] ICE in dump_possible_polymorphic_call_targets with -fdump-ipa-all -O2

[marxin at gcc dot gnu.org]

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

--- Comment #11 from Martin Liška  ---
Author: marxin
Date: Fri May 26 11:32:26 2017
New Revision: 248504

URL: https://gcc.gnu.org/viewcvs?rev=248504=gcc=rev
Log:
Backport r247097

2017-05-26  Martin Liska  

Backport from mainline
2017-04-24  Jan Hubicka  

PR middle-end/79931
* ipa-devirt.c (dump_possible_polymorphic_call_targets): Fix ICE.
2017-05-26  Martin Liska  

Backport from mainline
2017-04-24  Martin Liska  

PR middle-end/79931
* g++.dg/ipa/pr79931.C: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/ipa/pr79931.C
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/ipa-devirt.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug lto/50345] Incomplete GCC Internals sentence on LTO

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
Author: marxin
Date: Fri May 26 11:31:33 2017
New Revision: 248502

URL: https://gcc.gnu.org/viewcvs?rev=248502=gcc=rev
Log:
Backport r246995

2017-05-26  Martin Liska  

Backport from mainline
2017-04-19  Paulo J. Matos  

PR lto/50345
* doc/lto.texi: Remove an extra 'that'.

Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/doc/lto.texi

[Bug ipa/65972] ICE after applying a patch to enable verify_ssa with auto-pgo

[marxin at gcc dot gnu.org]

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

--- Comment #13 from Martin Liška  ---
Author: marxin
Date: Fri May 26 11:31:52 2017
New Revision: 248503

URL: https://gcc.gnu.org/viewcvs?rev=248503=gcc=rev
Log:
Backport r246996

2017-05-26  Martin Liska  

Backport from mainline
2017-04-19  Richard Biener  

PR ipa/65972
* auto-profile.c (afdo_vpt_for_early_inline): Update SSA
when needed by AutoPGO.

Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/auto-profile.c

[Bug gcov-profile/78783] gcov-tool fails in gcov_read_counter_mem

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
Author: marxin
Date: Fri May 26 11:31:15 2017
New Revision: 248501

URL: https://gcc.gnu.org/viewcvs?rev=248501=gcc=rev
Log:
Backport r246961

2017-05-26  Martin Liska  

Backport from mainline
2017-04-18  Martin Liska  

PR gcov-profile/78783
* gcov-tool.c (gcov_output_files): Validate that destination
file is either removed by the tool or by a user.
2017-05-26  Martin Liska  

Backport from mainline
2017-04-18  Martin Liska  

PR gcov-profile/78783
* libgcov-driver.c (gcov_get_filename): New function.

Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/gcov-tool.c
branches/gcc-6-branch/libgcc/ChangeLog
branches/gcc-6-branch/libgcc/libgcov-driver.c

[Bug gcov-profile/80413] sanitizer detects undefined behaviour in gcov-io.c using -ftest-coverage

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
Author: marxin
Date: Fri May 26 11:30:54 2017
New Revision: 248500

URL: https://gcc.gnu.org/viewcvs?rev=248500=gcc=rev
Log:
Backport r246903

2017-05-26  Martin Liska  

Backport from mainline
2017-04-13  Martin Liska  

PR gcov-profile/80413
* gcov-io.c (gcov_write_string): Copy to buffer just when
allocated size is greater than zero.

Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/gcov-io.c

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

[marxin at gcc dot gnu.org]

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

--- Comment #8 from Martin Liška  ---
Author: marxin
Date: Fri May 26 11:29:35 2017
New Revision: 248499

URL: https://gcc.gnu.org/viewcvs?rev=248499=gcc=rev
Log:
Backport r246848

2017-05-26  Martin Liska  

Backport from mainline
2017-04-11  Martin Liska  

PR ipa/80212
* cgraph.c (cgraph_node::dump): Dump calls_comdat_local.
* ipa-split.c (split_function): Create a local comdat symbol
if caller is in a comdat group.
2017-05-26  Martin Liska  

Backport from mainline
2017-04-11  Martin Liska  

PR ipa/80212
* g++.dg/ipa/pr80212.C: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/ipa/pr80212.C
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/cgraph.c
branches/gcc-6-branch/gcc/ipa-split.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

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

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
Author: marxin
Date: Fri May 26 11:28:44 2017
New Revision: 248498

URL: https://gcc.gnu.org/viewcvs?rev=248498=gcc=rev
Log:
Backport r246847

2017-05-26  Martin Liska  

Backport from mainline
2017-04-11  Martin Liska  

PR ipa/80212
* ipa-cp.c (determine_versionability): Handle calls_comdat_local
flags.

Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/ipa-cp.c

[Bug sanitizer/70878] [5/6 Regression] ICE in expand_expr_addr_expr_1, at expr.c:7680

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
Author: marxin
Date: Fri May 26 11:28:07 2017
New Revision: 248497

URL: https://gcc.gnu.org/viewcvs?rev=248497=gcc=rev
Log:
Backport r246837

2017-05-26  Martin Liska  

Backport from mainline
2017-04-11  Martin Liska  

PR sanitizer/70878
* ubsan.c (instrument_object_size): Do not instrument register
variables.
2017-05-26  Martin Liska  

Backport from mainline
2017-04-11  Martin Liska  

PR sanitizer/70878
* gcc.dg/ubsan/pr70878.c: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.dg/ubsan/pr70878.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/ubsan.c

[Bug gcov-profile/80224] gcov -i crashes with two arguments

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
Author: marxin
Date: Fri May 26 11:27:25 2017
New Revision: 248496

URL: https://gcc.gnu.org/viewcvs?rev=248496=gcc=rev
Log:
Backport r246804

2017-05-26  Martin Liska  

Backport from mainline
2017-04-10  Martin Liska  

PR gcov-profile/80224
* gcov.c (print_usage): Fix usage string.
(get_gcov_intermediate_filename): Remove.
(output_gcov_file): Use both for normal and intermediate format.
(generate_results): Do not initialize special file for
intermediate format.

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

[Bug sanitizer/80350] UBSAN changes code semantics when -fno-sanitize-recover=undefined is used

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
Author: marxin
Date: Fri May 26 11:26:45 2017
New Revision: 248495

URL: https://gcc.gnu.org/viewcvs?rev=248495=gcc=rev
Log:
Backport r246799

2017-05-26  Martin Liska  

Backport from mainline
2017-04-10  Martin Liska  

PR sanitizer/80350
* c-ubsan.c (ubsan_instrument_shift): Evaluate RHS before
doing an UBSAN check.
2017-05-26  Martin Liska  

Backport from mainline
2017-04-10  Martin Liska  

PR sanitizer/80350
* c-c++-common/ubsan/pr80350.c: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/c-c++-common/ubsan/pr80350.c
Modified:
branches/gcc-6-branch/gcc/c-family/ChangeLog
branches/gcc-6-branch/gcc/c-family/c-ubsan.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug sanitizer/80166] SANITIZER_INTERCEPT_GETGROUPS modifies list when size is 0 Out-of-bounds write

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
Author: marxin
Date: Fri May 26 11:26:04 2017
New Revision: 248494

URL: https://gcc.gnu.org/viewcvs?rev=248494=gcc=rev
Log:
Backport r246730

2017-05-26  Martin Liska  

Backport from mainline
2017-04-06  Martin Liska  

PR sanitizer/80166
* gcc.dg/asan/pr80166.c: New test.
2017-05-26  Martin Liska  

Backport from mainline
2017-04-06  Martin Liska  

PR sanitizer/80166
* sanitizer_common/sanitizer_common_interceptors.inc (INTERCEPTOR):
Cherry-pick upstream r299036.

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.dg/asan/pr80166.c
Modified:
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/libsanitizer/ChangeLog
   
branches/gcc-6-branch/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc

[Bug ipa/80205] [5/6 Regression] ICE in walk_ssa_copies at ipa-polymorphic-call.c:835

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Author: marxin
Date: Fri May 26 11:25:34 2017
New Revision: 248493

URL: https://gcc.gnu.org/viewcvs?rev=248493=gcc=rev
Log:
Backport r246530

2017-05-26  Martin Liska  

Backport from mainline
2017-03-28  Richard Biener  

PR ipa/80205
* tree-inline.c (copy_phis_for_bb): Do not create PHI node
without arguments, generate default definition of a SSA name.
2017-05-26  Martin Liska  

Backport from mainline
2017-03-28  Martin Liska  

PR ipa/80205
* g++.dg/ipa/pr80205.C: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/ipa/pr80205.C
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/tree-inline.c

[Bug ipa/80104] ICE in initialize_argument_information, at calls.c:1748

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
Author: marxin
Date: Fri May 26 11:24:49 2017
New Revision: 248492

URL: https://gcc.gnu.org/viewcvs?rev=248492=gcc=rev
Log:
Backport r246525

2017-05-26  Martin Liska  

Backport from mainline
2017-03-28  Martin Liska  

PR ipa/80104
* cgraphunit.c (cgraph_node::expand_thunk): Mark argument of a
thunk call as DECL_GIMPLE_REG_P when vector or complex type.
2017-05-26  Martin Liska  

Backport from mainline
2017-03-28  Martin Liska  

PR ipa/80104
* gcc.dg/ipa/pr80104.c: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.dg/ipa/pr80104.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/cgraphunit.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug sanitizer/80659] [7 Regression] -fsanitize=address evokes ICE in in gimplify_switch_expr

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug sanitizer/80875] [7 Regression] UBSAN: compile time crash in fold_binary_loc at fold-const.c:9817

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug libgomp/80881] [7 Regression] null pointer access in libgomp.h

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
There is always an emulated TLS support, but that is not what you ask for if
you --enable-tls.  As for mingw TLS support, you need to ask the mingw
maintainers, I don't have access to that target, nor sufficient knowledge about
it.

[Bug sanitizer/80659] [7 Regression] -fsanitize=address evokes ICE in in gimplify_switch_expr

[mpolacek at gcc dot gnu.org]

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

--- Comment #11 from Marek Polacek  ---
Author: mpolacek
Date: Fri May 26 11:17:34 2017
New Revision: 248491

URL: https://gcc.gnu.org/viewcvs?rev=248491=gcc=rev
Log:
PR sanitizer/80659
* c-decl.c (build_compound_literal): Set DECL_ARTIFICIAL and
DECL_IGNORED_P even for non-static compound literals.

* gcc.dg/asan/pr80659.c: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.dg/asan/pr80659.c
Modified:
branches/gcc-7-branch/gcc/c/ChangeLog
branches/gcc-7-branch/gcc/c/c-decl.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug sanitizer/80875] [7 Regression] UBSAN: compile time crash in fold_binary_loc at fold-const.c:9817

[mpolacek at gcc dot gnu.org]

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

--- Comment #8 from Marek Polacek  ---
Author: mpolacek
Date: Fri May 26 11:15:37 2017
New Revision: 248490

URL: https://gcc.gnu.org/viewcvs?rev=248490=gcc=rev
Log:
PR sanitizer/80875
* fold-const.c (fold_binary_loc) : Check if OP1
can be negated.

* c-c++-common/ubsan/pr80875.c: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/c-c++-common/ubsan/pr80875.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/fold-const.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug ipa/80663] signed integer overflow in ipa-split.c

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Known to work||8.0
  Known to fail||5.4.0, 6.3.0, 7.1.0

--- Comment #3 from Martin Liška  ---
Fixed on trunk so far.

[Bug ipa/80663] signed integer overflow in ipa-split.c

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Author: marxin
Date: Fri May 26 11:05:52 2017
New Revision: 248489

URL: https://gcc.gnu.org/viewcvs?rev=248489=gcc=rev
Log:
Bound partial-inlining-entry-probability param (PR ipa/80663).

2017-05-26  Martin Liska  

PR ipa/80663
* params.def: Bound partial-inlining-entry-probability param.
2017-05-26  Martin Liska  

PR ipa/80663
* g++.dg/ipa/pr80212.C: Remove the test as it does not longer
split at the problematic spot.
* gcc.dg/ipa/pr48195.c: Change 101 to 100 as 101 is no longer
a valid value of the param.

Removed:
trunk/gcc/testsuite/g++.dg/ipa/pr80212.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/params.def
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/ipa/pr48195.c

[Bug libgomp/80881] [7 Regression] null pointer access in libgomp.h

[daniel.f.starke at freenet dot de]

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

--- Comment #2 from Daniel Starke  ---
True, I have rebuild GCC without --enable-tls enabled and the null pointer
access is gone. So I guess there is still no TLS support for mingw-w64 (even
though Windows supports it as far as I know).

[Bug c++/71605] ICE on invalid C++ code (incorrect member access): in pop_binding, at cp/name-lookup.c:368

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org,
   ||paolo.carlini at oracle dot com

--- Comment #2 from Paolo Carlini  ---
Adding David in CC because, besides the main issue, apparently his Rev. 244715
(in particular the change id_expr_token->location to id_expression.get_location
() in cp_parser_primary_expression) broke the location of the error we emit for
this testcase before crashing.

[Bug tree-optimization/80884] [8 regression] test case gcc.target/powerpc/20050830-1.c fails starting with r247886

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #1 from amker at gcc dot gnu.org ---
Sorry for breaking it, I will investigate.  Thanks.

[Bug target/80862] [x86] Wrong rounding results for some test cases

[julia.koval at intel dot com]

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

--- Comment #2 from Yulia Koval  ---
Patch posted at https://gcc.gnu.org/ml/gcc-patches/2017-05/msg02013.html

[Bug c++/80886] New: __builtin_constant_p magic has broken at some point

[q....@rsn-tech.co.uk]

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

Bug ID: 80886
   Summary: __builtin_constant_p magic has broken at some point
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: q@rsn-tech.co.uk
  Target Milestone: ---

I'm using g++ for an embedded system, and as is common with such things,
hardware addresses are provided as hex constants. I want to create pointers
from them, using constexpr because they are known at compile time.

Now the C++ Standard forbids reinterpret_cast<> or the equivalent in a
constexpr so it can't be done directly, which is annoying but that's the
Standard.

However, with older versions of g++, one could solve this with the magic use of
__builtin_constant_p() in a ternary expression. Thus:

test.cpp:
#define CONST(x) (__builtin_constant_p(x) ? x : x)

constexpr void *phardware {CONST ((void *) 0x1000)};

(This is sufficient for a complete test program, BTW)

This use appears to be documented, although it's not 100% clear. It's certainly
very desirable.

My cross-development system recently upgraded from 4.9.2 to 6.2.1 and the magic
has stopped working. The loss of magic holds in other 6.x versions I've tried,
but still works in clang 3.8.1 which is the latest version in my distro (Fedora
24)

Compilation results:

$ <4.9.2>-g++  -c -std=c++14 test.cpp
$

$ <6.2.1>-g++  -c -std=c++14 test.cpp
test.cpp:4:28: error: reinterpret_cast from integer to pointer
 constexpr void *phardware {CONST ((void *) 0x1000)};
^~
test.cpp:2:45: note: in definition of macro 'CONST'
 #define CONST(x) (__builtin_constant_p(x) ? x : x)
$

Has this behaviour changed deliberately? As I say, it is contrary to the
Standard, but it would be disappointing to lose such a useful extension.

[Bug middle-end/80809] Multi-free error for variable size array used within OpenMP task

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Author: jakub
Date: Fri May 26 10:14:37 2017
New Revision: 248488

URL: https://gcc.gnu.org/viewcvs?rev=248488=gcc=rev
Log:
Backported from mainline
2017-05-22  Jakub Jelinek  

PR middle-end/80809
* omp-low.c (finish_taskreg_remap): New function.
(finish_taskreg_scan): If unit size of ctx->record_type
is non-constant, unshare the size expression and replace
decls in it with possible outer var refs.

* testsuite/libgomp.c/pr80809-2.c: New test.
* testsuite/libgomp.c/pr80809-3.c: New test.

Added:
branches/gcc-7-branch/libgomp/testsuite/libgomp.c/pr80809-2.c
branches/gcc-7-branch/libgomp/testsuite/libgomp.c/pr80809-3.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/omp-low.c
branches/gcc-7-branch/libgomp/ChangeLog

[Bug middle-end/80809] Multi-free error for variable size array used within OpenMP task

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Fri May 26 10:13:34 2017
New Revision: 248487

URL: https://gcc.gnu.org/viewcvs?rev=248487=gcc=rev
Log:
Backported from mainline
2017-05-22  Jakub Jelinek  

PR middle-end/80809
* gimplify.c (omp_add_variable): For GOVD_DEBUG_PRIVATE use
GOVD_SHARED rather than GOVD_PRIVATE with it.
(gimplify_adjust_omp_clauses_1, gimplify_adjust_omp_clauses): Expect
GOVD_SHARED rather than GOVD_PRIVATE with GOVD_DEBUG_PRIVATE.

* testsuite/libgomp.c/pr80809-1.c: New test.

Added:
branches/gcc-7-branch/libgomp/testsuite/libgomp.c/pr80809-1.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/gimplify.c
branches/gcc-7-branch/libgomp/ChangeLog

[Bug middle-end/80853] [6/7 Regression] OpenMP ICE in build_outer_var_ref with array reduction

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Fri May 26 10:05:39 2017
New Revision: 248486

URL: https://gcc.gnu.org/viewcvs?rev=248486=gcc=rev
Log:
Backported from mainline
2017-05-22  Jakub Jelinek  

PR middle-end/80853
* omp-low.c (lower_reduction_clauses): Pass OMP_CLAUSE_PRIVATE
as last argument to build_outer_var_ref for pointer bases of array
section reductions.

* testsuite/libgomp.c/pr80853.c: New test.

Added:
branches/gcc-7-branch/libgomp/testsuite/libgomp.c/pr80853.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/omp-low.c
branches/gcc-7-branch/libgomp/ChangeLog

[Bug target/80846] auto-vectorized AVX2 horizontal sum should narrow to 128b right away, to be more efficient for Ryzen and Intel

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Created attachment 41422
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41422=edit
adjusted tree-vect-loop.c hunk

[Bug target/80846] auto-vectorized AVX2 horizontal sum should narrow to 128b right away, to be more efficient for Ryzen and Intel

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Note that similar to the vec_init optab not allowing constructing larger
vectors from smaller ones vec_extract doesn't allow extracting smaller vectors
from larger ones.  So I might be forced to go V8SI -> V2TI -> TI -> V4SI to
make the RTL expander happy.

In that case for AVX512 we'll expose 256bit integers into the IL which means
VRP will barf immediately and we may so anyway as if optimization somehow
exposes
a constant that won't fit in widest_int...  Not sure if there's even V2OImode
supported.

For AVX2 we then expand

  _6 = VIEW_CONVERT_EXPR(vect_sum_11.6_14);
  _5 = BIT_FIELD_REF <_6, 128, 0>;
  _29 = VIEW_CONVERT_EXPR(_5);
  _22 = BIT_FIELD_REF <_6, 128, 128>;
  _21 = VIEW_CONVERT_EXPR(_22);
  _20 = _21 + _29;

to

;; _20 = _21 + _29;

(insn 18 17 19 (set (reg:OI 104)
(subreg:OI (reg:V2TI 89 [ _6 ]) 0)) -1
 (nil))

(insn 19 18 20 (set (reg:TI 105)
(subreg:TI (reg:OI 104) 16)) -1
 (nil))

(insn 20 19 21 (set (reg:OI 106)
(subreg:OI (reg:V2TI 89 [ _6 ]) 0)) -1
 (nil))

(insn 21 20 22 (set (reg:TI 107)
(subreg:TI (reg:OI 106) 0)) -1
 (nil))

(insn 22 21 0 (set (reg:V4SI 95 [ _20 ])
(plus:V4SI (subreg:V4SI (reg:TI 105) 0)
(subreg:V4SI (reg:TI 107) 0))) -1
 (nil))

which doesn't seem any better ... (still using subregs rather than going
through vec_extract).

(define_expand "vec_extract"
  [(match_operand: 0 "register_operand")
   (match_operand:VEC_EXTRACT_MODE 1 "register_operand")
   (match_operand 2 "const_int_operand")]
  "TARGET_SSE"
{
  ix86_expand_vector_extract (false, operands[0], operands[1],
  INTVAL (operands[2]));
  DONE;
})

ssescalarmode doesn't include TImode.

Note there's the corresponding bug that says x86 doesn't implement
{ TImode, TImode } vec_init either.

[Bug tree-optimization/80632] [8 Regression] error: invalid PHI argument with -O2

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #8 from Jakub Jelinek  ---
Fixed.

[Bug sanitizer/80875] [7 Regression] UBSAN: compile time crash in fold_binary_loc at fold-const.c:9817

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

Summary|[7/8 Regression] UBSAN: |[7 Regression] UBSAN:
   |compile time crash in   |compile time crash in
   |fold_binary_loc at  |fold_binary_loc at
   |fold-const.c:9817   |fold-const.c:9817

--- Comment #7 from Marek Polacek  ---
Fixed on trunk so far.

[Bug sanitizer/80875] [7/8 Regression] UBSAN: compile time crash in fold_binary_loc at fold-const.c:9817

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek  ---
Author: mpolacek
Date: Fri May 26 09:31:36 2017
New Revision: 248485

URL: https://gcc.gnu.org/viewcvs?rev=248485=gcc=rev
Log:
PR sanitizer/80875
* fold-const.c (fold_binary_loc) : Check if OP1
can be negated.

* c-c++-common/ubsan/pr80875.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/ubsan/pr80875.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog

[Bug testsuite/80557] rewrite absolute line numbers into relative or saved line numbers

[vries at gcc dot gnu.org]

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

--- Comment #13 from Tom de Vries  ---
Author: vries
Date: Fri May 26 09:25:00 2017
New Revision: 248484

URL: https://gcc.gnu.org/viewcvs?rev=248484=gcc=rev
Log:
Replace absolute line numbers in gcc.dg

2017-05-26  Tom de Vries  

PR testsuite/80557
* gcc.dg/20011021-1.c: Replace absolute line numbers.
* gcc.dg/Wcxx-compat-8.c: Same.
* gcc.dg/Wobjsize-1.c: Same.
* gcc.dg/Wshadow-local-2.c: Same.
* gcc.dg/Wstrict-aliasing-converted-assigned.c: Same.
* gcc.dg/anon-struct-6.c: Same.
* gcc.dg/asm-wide-1.c: Same.
* gcc.dg/builtin-inf-1.c: Same.
* gcc.dg/builtin-redefine.c: Same.
* gcc.dg/c90-array-lval-6.c: Same.
* gcc.dg/c90-array-lval-7.c: Same.
* gcc.dg/c90-fordecl-1.c: Same.
* gcc.dg/c99-fordecl-2.c: Same.
* gcc.dg/cast-lvalue-1.c: Same.
* gcc.dg/cast-lvalue-2.c: Same.
* gcc.dg/compound-lvalue-1.c: Same.
* gcc.dg/cond-lvalue-1.c: Same.
* gcc.dg/cpp/2419-1.c: Same.
* gcc.dg/cpp/backslash.c: Same.
* gcc.dg/cpp/backslash2.c: Same.
* gcc.dg/cpp/macspace1.c: Same.
* gcc.dg/cpp/macspace2.c: Same.
* gcc.dg/cpp/multiline-2.c: Same.
* gcc.dg/cpp/pr2.c: Same.
* gcc.dg/cpp/pr30786.c: Same.
* gcc.dg/cpp/pr34602.c: Same.
* gcc.dg/cpp/redef1.c: Same.
* gcc.dg/cpp/tr-warn1.c: Same.
* gcc.dg/cpp/tr-warn3.c: Same.
* gcc.dg/cpp/tr-warn6.c: Same.
* gcc.dg/cpp/trad/hash.c: Same.
* gcc.dg/cpp/trad/redef1.c: Same.
* gcc.dg/cpp/ucs.c: Same.
* gcc.dg/declspec-10.c: Same.
* gcc.dg/declspec-11.c: Same.
* gcc.dg/declspec-18.c: Same.
* gcc.dg/format/c99-strftime-1.c: Same.
* gcc.dg/format/ext-3.c: Same.
* gcc.dg/format/pr72858.c: Same.
* gcc.dg/gomp/appendix-a/a.24.1.c: Same.
* gcc.dg/init-string-1.c: Same.
* gcc.dg/label-decl-3.c: Same.
* gcc.dg/m-un-2.c: Same.
* gcc.dg/nofixed-point-2.c: Same.
* gcc.dg/noncompile/20020213-1.c: Same.
* gcc.dg/pch/counter-2.c: Same.
* gcc.dg/plugin/diagnostic-test-string-literals-2.c: Same.
* gcc.dg/pr27528.c: Same.
* gcc.dg/pr27953.c: Same.
* gcc.dg/pr35899.c: Same.
* gcc.dg/pr37561.c: Same.
* gcc.dg/pr45461.c: Same.
* gcc.dg/pr45750.c: Same.
* gcc.dg/pr53196-2.c: Same.
* gcc.dg/pr53265.c: Same.
* gcc.dg/redecl-1.c: Same.
* gcc.dg/tls/thr-init-1.c: Same.
* gcc.dg/torture/pr51106-1.c: Same.
* gcc.dg/torture/pr51106-2.c: Same.
* gcc.dg/uninit-19.c: Same.
* gcc.dg/uninit-pr20644.c: Same.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/20011021-1.c
trunk/gcc/testsuite/gcc.dg/Wcxx-compat-8.c
trunk/gcc/testsuite/gcc.dg/Wobjsize-1.c
trunk/gcc/testsuite/gcc.dg/Wshadow-local-2.c
trunk/gcc/testsuite/gcc.dg/Wstrict-aliasing-converted-assigned.c
trunk/gcc/testsuite/gcc.dg/anon-struct-6.c
trunk/gcc/testsuite/gcc.dg/asm-wide-1.c
trunk/gcc/testsuite/gcc.dg/builtin-inf-1.c
trunk/gcc/testsuite/gcc.dg/builtin-redefine.c
trunk/gcc/testsuite/gcc.dg/c90-array-lval-6.c
trunk/gcc/testsuite/gcc.dg/c90-array-lval-7.c
trunk/gcc/testsuite/gcc.dg/c90-fordecl-1.c
trunk/gcc/testsuite/gcc.dg/c99-fordecl-2.c
trunk/gcc/testsuite/gcc.dg/cast-lvalue-1.c
trunk/gcc/testsuite/gcc.dg/cast-lvalue-2.c
trunk/gcc/testsuite/gcc.dg/compound-lvalue-1.c
trunk/gcc/testsuite/gcc.dg/cond-lvalue-1.c
trunk/gcc/testsuite/gcc.dg/cpp/2419-1.c
trunk/gcc/testsuite/gcc.dg/cpp/backslash.c
trunk/gcc/testsuite/gcc.dg/cpp/backslash2.c
trunk/gcc/testsuite/gcc.dg/cpp/macspace1.c
trunk/gcc/testsuite/gcc.dg/cpp/macspace2.c
trunk/gcc/testsuite/gcc.dg/cpp/multiline-2.c
trunk/gcc/testsuite/gcc.dg/cpp/pr2.c
trunk/gcc/testsuite/gcc.dg/cpp/pr30786.c
trunk/gcc/testsuite/gcc.dg/cpp/pr34602.c
trunk/gcc/testsuite/gcc.dg/cpp/redef1.c
trunk/gcc/testsuite/gcc.dg/cpp/tr-warn1.c
trunk/gcc/testsuite/gcc.dg/cpp/tr-warn3.c
trunk/gcc/testsuite/gcc.dg/cpp/tr-warn6.c
trunk/gcc/testsuite/gcc.dg/cpp/trad/hash.c
trunk/gcc/testsuite/gcc.dg/cpp/trad/redef1.c
trunk/gcc/testsuite/gcc.dg/cpp/ucs.c
trunk/gcc/testsuite/gcc.dg/declspec-10.c
trunk/gcc/testsuite/gcc.dg/declspec-11.c
trunk/gcc/testsuite/gcc.dg/declspec-18.c
trunk/gcc/testsuite/gcc.dg/format/c99-strftime-1.c
trunk/gcc/testsuite/gcc.dg/format/ext-3.c
trunk/gcc/testsuite/gcc.dg/format/pr72858.c
trunk/gcc/testsuite/gcc.dg/gomp/appendix-a/a.24.1.c
trunk/gcc/testsuite/gcc.dg/init-string-1.c
trunk/gcc/testsuite/gcc.dg/label-decl-3.c
trunk/gcc/testsuite/gcc.dg/m-un-2.c
trunk/gcc/testsuite/gcc.dg/nofixed-point-2.c
trunk/gcc/testsuite/gcc.dg/noncompile/20020213-1.c

[Bug target/80885] Do not use the opaque _mm256_cmp_ps to produce -1

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-26
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  The macro-case looks like wrong-code.

[Bug bootstrap/80867] gnat bootstrap broken on powerpc64le-linux-gnu with -O3

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Target|powerpc64le-linux-gnu,  |powerpc64le-linux-gnu,
   |x86_64-apple-darwin16   |x86_64-apple-darwin16,
   ||sparc-sun-solaris2.12,
   ||i386-pc-solaris2.12
 CC||ro at gcc dot gnu.org

--- Comment #6 from Rainer Orth  ---
Same on mainline between r248423 and r248462 on Solaris (both sparc and x86).

[Bug target/80846] auto-vectorized AVX2 horizontal sum should narrow to 128b right away, to be more efficient for Ryzen and Intel

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Similar with AVX512F I get

.L2:
vmovdqa64   -112(%rbp), %zmm3
addq$64, %rdi
vpaddd  -64(%rdi), %zmm3, %zmm2
cmpq%rdi, %rax
vmovdqa64   %zmm2, -112(%rbp)
jne .L2
vmovdqa -80(%rbp), %ymm0
vpaddd  -112(%rbp), %ymm0, %ymm5
vmovdqa %ymm5, -112(%rbp)
vmovdqa -96(%rbp), %xmm0
vpaddd  -112(%rbp), %xmm0, %xmm0
...