[Bug c++/78488] ICE when building call to inherited default constructor.

[eric at efcs dot ca]

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

--- Comment #1 from Eric Fiselier  ---
>  GCC 6 exits with status 1 and without producing any diagnostics or an output 
> file

Disregard that I was using a broken GCC 6. IDK how GCC 6 handles this bug.

[Bug fortran/77505] Negative character length not treated as LEN=0

[elizebethp at gmail dot com]

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

--- Comment #7 from Elizebeth Punnoose  ---
I plan to send the patch to gcc-patches from my official mail id, in a couple
of days. Please do let me know if there are any suggestions/comments.

[Bug c++/78488] New: ICE when building call to inherited default constructor.

[eric at efcs dot ca]

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

Bug ID: 78488
   Summary: ICE when building call to inherited default
constructor.
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

GCC ICE's when default initializing a type T when T's default constructor is an
inherited constructor. Note that this only happens when T doesn't define its
own default ctor, either implicitly or explicitly.

The below reproducer is rejected by GCC 5.3 and earlier. GCC 6 exits with
status 1 and without producing any diagnostics or an output file, and GCC 7
segfaults.

Reproducer: 

// g++ -std=c++1z test.cpp
struct Foo { Foo() {} };

struct Bar : Foo {
  using Foo::Foo;
  Bar(void*); // Define another constructor so Foo() isn't generated.
};

int main() {
 Bar f;
}

[Bug c++/78434] Incorrect warning about missing align_val_t for placement new

[marc.mutz at kdab dot com]

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

--- Comment #3 from Marc Mutz  ---
Possibly. I couldn't check later versions because trunk failed to compile for
me in i386.c.

[Bug tree-optimization/78455] [7 Regression] ICE in operator[], at vec.h:732

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/78455] [7 Regression] ICE in operator[], at vec.h:732

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
Author: mpolacek
Date: Wed Nov 23 03:17:14 2016
New Revision: 242733

URL: https://gcc.gnu.org/viewcvs?rev=242733=gcc=rev
Log:
PR tree-optimization/78455
* tree-ssa-uninit.c (can_chain_union_be_invalidated_p): Fix typo.

* gcc.dg/uninit-23.c: New.

Added:
trunk/gcc/testsuite/gcc.dg/uninit-23.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-uninit.c

[Bug target/78458] [7 Regression] LRA ICE building libgcc for powerpc-linux-gnuspe e500v2

[joseph at codesourcery dot com]

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

--- Comment #11 from joseph at codesourcery dot com  ---
For e500v2, that patch moves things from a libgcc build failure to a glibc 
build failure having built libgcc successfully: many files in glibc fail 
to build with errors of the form:

../sysdeps/ieee754/ldbl-128ibm/s_modfl.c: In function '__modfl':
../sysdeps/ieee754/ldbl-128ibm/s_modfl.c:91:1: error: unrecognizable insn:
 }
 ^
(insn 31 30 32 2 (set (reg:DF 203)
(subreg:DF (reg:TI 202) 8)) 
"../sysdeps/ieee754/ldbl-128ibm/s_modfl.c":44 -1
 (nil))
../sysdeps/ieee754/ldbl-128ibm/s_modfl.c:91:1: internal compiler error: in 
extract_insn, at recog.c:2311

I think it would be reasonable for you to submit your patch for inclusion 
at this point, as a useful incremental improvement.  The above error is 
fixed by a patch

Index: gcc/config/rs6000/spe.md
===
--- gcc/config/rs6000/spe.md(revision 242699)
+++ gcc/config/rs6000/spe.md(working copy)
@@ -2314,6 +2314,18 @@
 }
 })

+(define_insn "*frob__ti_8"
+  [(set (match_operand:SPE64 0 "nonimmediate_operand" "=r")
+(subreg:SPE64 (match_operand:TI 1 "input_operand" "r") 8))]
+  "(TARGET_E500_DOUBLE && mode == DFmode)
+   || (TARGET_SPE && mode != DFmode)"
+{
+  if (WORDS_BIG_ENDIAN)
+return "evmergelo %0,%Y1,%Z1";
+  else
+return "evmergelo %0,%Z1,%Y1";
+})
+
 (define_insn "*frob_tf_ti"
   [(set (match_operand:TF 0 "gpc_reg_operand" "=r")
 (subreg:TF (match_operand:TI 1 "gpc_reg_operand" "r") 0))]

(I'm familiar with this part of spe.md).  That moves the error to an 
assembler error from GCC generating bad offsets building s_fmal.o

/tmp/ccLQIeP5.s: Assembler messages:
/tmp/ccLQIeP5.s:735: Error: operand out of range (256 is not between 0 and 248)

which I need to investigate further.

[Bug target/78478] Compile Error for i386-rtems

[joseph at codesourcery dot com]

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

--- Comment #5 from joseph at codesourcery dot com  ---
On Tue, 22 Nov 2016, ubizjak at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78478
> 
> --- Comment #2 from Uroš Bizjak  ---
> For 7.0, somebody changed i[34567]86-*-rtems* entry in libgcc/config.host to
> use t-softfp-sfdftf. Please test the following patch:

The change was by design meant to ensure that _Float128 was always 
available on x86, so that __float128 can always be aliased to _Float128.  
Making _Float128 always available means making libgcc support for TFmode 
always available.

I.e., the bug was enabling unintended soft-fp usage of XFmode at the same 
time as enabling usage of TFmode.  The TFmode functions should be kept in 
libgcc while disabling the conversions between XFmode and TFmode for this 
case.

[Bug inline-asm/78487] asm cpuid code and -fgcse crashes

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
Also I doubt this code is correct.

[Bug inline-asm/78487] asm cpuid code and -fgcse crashes

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
Crashes at runtime or crashes inside GCC?

[Bug inline-asm/78487] asm cpuid code and -fgcse crashes

[s-beyer at gmx dot net]

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

--- Comment #2 from Stephan Beyer  ---
The following problem is only reproducible on one machine.
I cannot reproduce it on any other machine.

When compiling the attached C++ source file with
g++ -O1 -fgcse, it crashes at the third cpuid call (ie,
there are three output lines).
When just using g++ -O1 (without -fgcse), it works well.

Changing the code in main() slightly or making cpuid() inline
makes it work well also with -fgcse.

uname -a and g++ --version of that machine says:

Linux ipc675 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt4-3 (2015-02-03) x86_64
GNU/Linux

g++ (Debian 6.2.0-13) 6.2.0 20161109

If useful, I can also attach assembly output of the crashing code (with
-fgcse),
of the code without -fgcse and of the code with "inline" (there using
-fgcse makes no difference).

The code is not written by me, so I don't know if its "correct" or if
the input/output asm constraints are just used wrong.
(It's just the minimal example I got from code where a crash occurred.)

PS: excuse the first empty bug report, it seems I am too
stupid for bugzilla.

[Bug inline-asm/78487] asm cpuid code and -fgcse crashes

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
What is the error message which you are getting?  

Here is how GCC's cpuid.h header look like for cpuid:

#define __cpuid(level, a, b, c, d)  \
  __asm__ ("cpuid\n\t"  \
   : "=a" (a), "=b" (b), "=c" (c), "=d" (d) \
   : "0" (level))

#define __cpuid_count(level, count, a, b, c, d) \
  __asm__ ("cpuid\n\t"  \
   : "=a" (a), "=b" (b), "=c" (c), "=d" (d) \
   : "0" (level), "2" (count))


It does not use r but rather b directly.

[Bug c++/78487] New: asm cpuid code and -fgcse crashes

[s-beyer at gmx dot net]

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

Bug ID: 78487
   Summary: asm cpuid code and -fgcse crashes
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: s-beyer at gmx dot net
  Target Milestone: ---

Created attachment 40123
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40123=edit
the C++ source

[Bug tree-optimization/78476] snprintf(0, 0, ...) with known arguments not optimized away

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Sebor  ---
The test in comment #0 isn't quite right.  The result of the snprintf call
isn't 7 but rather at most 7 so the call cannot be easily eliminated.  The
following is a test case where the call can be, and with the attached patch is,
eliminated.

void f (void)
{
  int n = 7;
  const char *s = "1234567";
  if (n != __builtin_snprintf (0, 0, "%.*s", n, s))
__builtin_abort ();
}

[Bug libstdc++/78486] feature request: std::iu16stringstream std::ou16stringstream, and utf8

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Do these exist in standard C++ at all?  If not then I doubt they will be added
to the GCC's library.

[Bug tree-optimization/68548] bogus "may be used uninitialized" (predicate analysis)

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #2 from Jeffrey A. Law  ---
True that tree-ssa-uninit.c is now powerful enough to grok this case.

But my first preference for any kind of Wuninitialized false positive is to
first think of it as a missed optimization.  Fix the missed optimization and
the false positive goes away for free.

In this particular case there's a couple potential approaches.

;;   basic block 2, loop depth 0, count 0, freq 1, maybe hot
;;prev block 0, next block 3, flags: (NEW, REACHABLE, VISITED)
;;pred:   ENTRY [100.0%]  (FALLTHRU,EXECUTABLE)
  _1 = writemask_5(D) & 1;
  if (_1 != 0)
goto ;
  else
goto ;
;;succ:   4 [50.0%]  (TRUE_VALUE,EXECUTABLE)
;;3 [50.0%]  (FALSE_VALUE,EXECUTABLE)

;;   basic block 3, loop depth 0, count 0, freq 5000, maybe hot
;;prev block 2, next block 4, flags: (NEW, VISITED)
;;pred:   2 [50.0%]  (FALSE_VALUE,EXECUTABLE)
;;succ:   4 [100.0%]  (FALLTHRU,EXECUTABLE)

;;   basic block 4, loop depth 0, count 0, freq 1, maybe hot
;;prev block 3, next block 5, flags: (NEW, REACHABLE, VISITED)
;;pred:   3 [100.0%]  (FALLTHRU,EXECUTABLE)
;;2 [50.0%]  (TRUE_VALUE,EXECUTABLE)
  # data0_3 = PHI 
  _2 = ~writemask_5(D);
  remaining_8 = _2 & 1;
  if (remaining_8 == 0)
goto ;
  else
goto ;

One would be to realize that remaining_8 can be expressed in terms of _1.  If
that's done we expose the redundant test and we end up with the only path to
bar() being the one where data0 is initialized.  This can be modeled in DOM and
is about ~20 lines of code.  Not sure how often it'd trigger in the real world.

Another would be to utilize bitwise inference in jump threading in conjunction
with the ASSERT_EXPRs from VRP.  That essentially allows us to construct jump
threads 2->3->4->6 and 2->4->5 which result in the only path to bar() being one
were data0 is initialized.  This is probably more effective, but requires
extending the VRP related jump threading bits whereas I'd rather be relying
upon those less.  But it might be the most tractable for gcc-7.

A third approach would be to extend the backward jump threader to walk through
some binary and unary ops.  I've got some prototype code to do that, but it's
not gcc-7 material.

A fourth approach would be to take the bitwise inference stuff and do it in the
DOM threader instead (which will likely last longer than the VRP threader).  My
worry in this case is that we won't have the ASSERT_EXPRs or range information
on the appropriate edges that would allow us to identify the jump threads.

A fifth approach would be to extend tree-ssa-uninit.c.  But I'd really prefer
to explore opportunities to remove the useless test and unexecutable paths
through the CFG first.

[Bug tree-optimization/78476] snprintf(0, 0, ...) with known arguments not optimized away

[msebor at gcc dot gnu.org]

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

--- Comment #1 from Martin Sebor  ---
Created attachment 40122
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40122=edit
Patch under test.

Patch being tested (requires a patch for bug 78461).

[Bug fortran/78479] ICE in gfc_apply_init, at fortran/expr.c:4135

[kargl at gcc dot gnu.org]

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

--- Comment #5 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Tue Nov 22 23:28:43 2016
New Revision: 242729

URL: https://gcc.gnu.org/viewcvs?rev=242729=gcc=rev
Log:
2016-11-22  Steven G. Kargl  

PR fortran/78479
* gfortran.dg/char_component_initializer_3.f90: Add PR number in a
comment.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/char_component_initializer_3.f90

[Bug go/78431] [7 regression] ICE in go_append_padding, at godump.c:636

[ian at airs dot com]

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

Bug 78432 Summary: [7 Regression] -fdump-go-spec ICEs for aligned causing x32 
libgo library to fail to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78432

   What|Removed |Added

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

[Bug go/78431] [7 regression] ICE in go_append_padding, at godump.c:636

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #3 from Ian Lance Taylor  ---
Should be fixed.

[Bug go/78432] [7 Regression] -fdump-go-spec ICEs for aligned causing x32 libgo library to fail to build

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #5 from Ian Lance Taylor  ---
Should be fixed.

[Bug go/78431] [7 regression] ICE in go_append_padding, at godump.c:636

[ian at gcc dot gnu.org]

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

--- Comment #2 from ian at gcc dot gnu.org  ---
Author: ian
Date: Tue Nov 22 23:25:07 2016
New Revision: 242728

URL: https://gcc.gnu.org/viewcvs?rev=242728=gcc=rev
Log:
PR go/78431
PR go/78432
* godump.c (go_format_type): Always pass alignment as 1 when
calling go_append_padding at end of struct/union.

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

[Bug go/78432] [7 Regression] -fdump-go-spec ICEs for aligned causing x32 libgo library to fail to build

[ian at gcc dot gnu.org]

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

--- Comment #4 from ian at gcc dot gnu.org  ---
Author: ian
Date: Tue Nov 22 23:25:07 2016
New Revision: 242728

URL: https://gcc.gnu.org/viewcvs?rev=242728=gcc=rev
Log:
PR go/78431
PR go/78432
* godump.c (go_format_type): Always pass alignment as 1 when
calling go_append_padding at end of struct/union.

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

[Bug c++/78486] New: feature request: std::iu16stringstream std::ou16stringstream, and utf8

[jmichae3 at yahoo dot com]

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

Bug ID: 78486
   Summary: feature request: std::iu16stringstream
std::ou16stringstream, and utf8
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jmichae3 at yahoo dot com
  Target Milestone: ---

std::iu32stringstream 
std::ou32stringstream, 
std::iu16stringstream 
std::ou16stringstream, 
std::iutf8stringstream
std::outf8stringstream

 have not been implemented in the string library.
most of that should be copy and paste. but they use wide characters, etc.

[Bug libstdc++/11196] _GNU_SOURCE vs. M_PI

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||krzysztof at jusiak dot net

--- Comment #14 from Andrew Pinski  ---
*** Bug 78483 has been marked as a duplicate of this bug. ***

[Bug libstdc++/78483] Error: reference to 'on_exit' is ambiguous

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Dup of bug 11196 due to _GNU_SOURCE usage.

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

[Bug libstdc++/78483] Error: reference to 'on_exit' is ambiguous

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
Also on_exit is not part of the C++ standard at all.

[Bug libstdc++/78483] Error: reference to 'on_exit' is ambiguous

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
This is most likely because _GNU_SOURCE is defined when compiling with C++ code
in GNU C++ mode.

[Bug tree-optimization/78485] Missed scalarization in undefined use after going out of scope case

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

   Keywords||missed-optimization

--- Comment #3 from Marc Glisse  ---
We could also call it a missed optimization, if you don't think the
compile-time warning is worth it.

[Bug target/78458] [7 Regression] LRA ICE building libgcc for powerpc-linux-gnuspe e500v2

[bergner at gcc dot gnu.org]

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

--- Comment #10 from Peter Bergner  ---
(In reply to Peter Bergner from comment #9)
> I'm testing the following patch (which is a little more general) on a
> powerpc64le-linux bootstrap to see if this survives.

Ok, this patch passed bootstrap and regtesting on powerpc64le-linux with no
regressions.

Joseph, can you try the patch above and see if it passes bootstrap and
regresting on a powerpc-linux-gnuspe build?

[Bug tree-optimization/78485] Missed scalarization in undefined use after going out of scope case

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
Warning is not done at compile time but is handled at runtime via the
sanitizers:
-fsanitize-address-use-after-scope
Enable sanitization of local variables to detect use-after-scope bugs. The
option sets -fstack-reuse to ‘none’.

[Bug tree-optimization/78485] Missed scalarization in undefined use after going out of scope case

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|Missed scalarization in |Missed scalarization in
   |simple read-from-clobber|undefined use after going
   |case|out of scope case

--- Comment #1 from Andrew Pinski  ---
There might be already a bug about a warning or even a runtime catch for these
kind of things.

[Bug tree-optimization/78485] New: Missed scalarization in simple read-from-clobber case

[glisse at gcc dot gnu.org]

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

Bug ID: 78485
   Summary: Missed scalarization in simple read-from-clobber case
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glisse at gcc dot gnu.org
  Target Milestone: ---

#include 
static std::initializer_list f(int i) { return { i }; }
int main() { auto c=f(-1); return 1+c.begin()[0]; }

This remains as

  D.3093 ={v} {CLOBBER};
  _1 = MEM[(const int *)];
  _3 = _1 + 1;

instead of becoming

  _3 = SR.10_5(D) + 1;

so we don't warn about it. Ideally something like PRE/DOM would handle it in
the general case, but in this specific case, SRA would be sufficient. However,
it does not seem interested in scalarizing this variable:

! Disqualifying D.3093 - No scalar replacements to be created.

I am hoping that a minor tweak to the heuristic could let it handle this case.
We still wouldn't warn (see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517#c18) but we would be
close...

[Bug testsuite/77684] many tree-prof testsuite failures in parallel make check

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Sebor  ---
The failures are due to the following error:

Running
/opt/notnfs/msebor/src/gcc/trunk/gcc/testsuite/../config/i386/gcc-auto-p
rofile -o perf.data  -o
/opt/notnfs/msebor/build/gcc-trunk/gcc/testsuite/gcc15/s
ection-attr-1.perf.data
/opt/notnfs/msebor/build/gcc-trunk/gcc/testsuite/gcc15/s
ection-attr-1.x01
spawn [open ...]
Permission error mapping pages.
Consider increasing /proc/sys/kernel/perf_event_mlock_kb,
or try again with a smaller value of -m/--mmap_pages.
(current value: 4294967295)
FAIL: gcc.dg/tree-prof/section-attr-1.c execution,-g


perf_event_mlock_kb is set to the default 516

$ cat /proc/sys/kernel/perf_event_mlock_kb
516

The file is only writeable by root so the error message claiming that the
current value is 4294967295 isn't right (i.e., it seems unlikely that the test
suite tries to temporarily raise it).

I tried bumping it up to 1k, 4k, and 64k but the failures persisted until I
finally raised to 1MB.  With that all the tests passed even with make -j128.

[Bug target/78478] Compile Error for i386-rtems

[joel at gcc dot gnu.org]

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

--- Comment #4 from Joel Sherrill  ---
FWIW I haven't been able to build this far using i386-elf. It fails in
libbacktrace doing a configure probe because there isn't a crt0.o. I can't
figure out why it isn't building libgloss. I have it and newlib symlinked into
the gcc tree and am configuring with --with-newlib. I don't see any magic
putting it into the noconfigdirs for this target.

I was hoping to reproduce on a target that wasn't rtems.

[Bug c++/78484] if-else chain is not turned into a local jump table

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup of bug 14799.

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

[Bug tree-optimization/14799] [tree-ssa] convert a sequence of "if"s to a "switch" statement

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||timshen at gcc dot gnu.org

--- Comment #4 from Andrew Pinski  ---
*** Bug 78484 has been marked as a duplicate of this bug. ***

[Bug fortran/78479] ICE in gfc_apply_init, at fortran/expr.c:4135

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||kargl at gcc dot gnu.org
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org
   Target Milestone|--- |7.0

--- Comment #4 from kargl at gcc dot gnu.org ---
Fixed on trunk.  Patch does not apply on 6-branch.

[Bug c++/78484] New: if-else chain is not turned into a local jump table

[timshen at gcc dot gnu.org]

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

Bug ID: 78484
   Summary: if-else chain is not turned into a local jump table
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: timshen at gcc dot gnu.org
  Target Milestone: ---

Convenient link: https://godbolt.org/g/AEYMwC

The following C++ code is slow, since it's not turned into a jump table:

template
void Foo();

template
struct BarImpl {
  static void Apply(int m) {
if (m == n) {
  Foo();
} else {
  BarImpl::Apply(m);
}
  }
};

template<>
struct BarImpl<0> {
  static void Apply(int m) {
Foo<0>();
  }
};

void Bar(int n) {
  BarImpl<30>::Apply(n);
}

[Bug fortran/78479] ICE in gfc_apply_init, at fortran/expr.c:4135

[kargl at gcc dot gnu.org]

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

--- Comment #3 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Tue Nov 22 21:52:15 2016
New Revision: 242725

URL: https://gcc.gnu.org/viewcvs?rev=242725=gcc=rev
Log:
2016-11-22  Steven G. Kargl  

PR fortran/78479
* expr.c (gfc_apply_init):  Allocate a charlen if needed.

2016-11-22  Steven G. Kargl  

PR fortran/78479
* gfortran.dg/char_component_initializer_3.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/char_component_initializer_3.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/expr.c
trunk/gcc/testsuite/ChangeLog

[Bug target/78478] Compile Error for i386-rtems

[joel at gcc dot gnu.org]

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

--- Comment #3 from Joel Sherrill  ---
That patch gets the build further but there is more wrong. __float128 isn't
defined.

/home/joel/test-gcc/b-i386-rtems4.12-gcc/./gcc/xgcc
-B/home/joel/test-gcc/b-i386-rtems4.12-gcc/./gcc/ -nostdinc
-B/home/joel/test-gcc/b-i386-rtems4.12-gcc/i386-rtems4.12/newlib/ -isystem
/home/joel/test-gcc/b-i386-rtems4.12-gcc/i386-rtems4.12/newlib/targ-include
-isystem /home/joel/test-gcc/gcc/newlib/libc/include
-B/home/joel/test-gcc/install-master/i386-rtems4.12/bin/
-B/home/joel/test-gcc/install-master/i386-rtems4.12/lib/ -isystem
/home/joel/test-gcc/install-master/i386-rtems4.12/include -isystem
/home/joel/test-gcc/install-master/i386-rtems4.12/sys-include -DHAVE_CONFIG_H
-I. -I../../../gcc/libgfortran -iquote../../../gcc/libgfortran/io
-I../../../gcc/libgfortran/../gcc -I../../../gcc/libgfortran/../gcc/config
-I../.././gcc -I../../../gcc/libgfortran/../libgcc -I../libgcc
-I../../../gcc/libgfortran/../libbacktrace -I../libbacktrace -I../libbacktrace
-std=gnu11 -Wall -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wextra -Wwrite-strings
-Werror=implicit-function-declaration -Werror=vla -fcx-fortran-rules
-ffunction-sections -fdata-sections -g -O2 -MT single.lo -MD -MP -MF
.deps/single.Tpo -c ../../../gcc/libgfortran/caf/single.c -o single.o
In file included from ./kinds.h:69:0,
 from ../../../gcc/libgfortran/libgfortran.h:232,
 from ../../../gcc/libgfortran/caf/libcaf.h:33,
 from ../../../gcc/libgfortran/caf/single.c:26:
../../../gcc/libgfortran/kinds-override.h:40:5: error: #error "Where has
__float128 gone?"
 #   error "Where has __float128 gone?"
 ^

[Bug middle-end/78461] [7 Regression] ICE: in operator+=, at gimple-ssa-sprintf.c:214

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
Created attachment 40121
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40121=edit
Patch under test.

Testing the attached patch.

[Bug fortran/78290] Gfortran incorrectly creates a copy of an array passed to an array pointer dummy argument

[anlauf at gmx dot de]

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

--- Comment #3 from Harald Anlauf  ---
(In reply to Harald Anlauf from comment #2)
> internal compiler error: in gfc_add_modify_loc, at fortran/trans.c:159
> 0x835756e gfc_add_modify_loc(unsigned int, stmtblock_t*, tree_node*,
> tree_node*)
> ../../trunk/gcc/fortran/trans.c:158
> 0x83575e7 gfc_add_modify(stmtblock_t*, tree_node*, tree_node*)
> ../../trunk/gcc/fortran/trans.c:170
> 0x83a90eb gfc_trans_pointer_assignment(gfc_expr*, gfc_expr*)
> ../../trunk/gcc/fortran/trans-expr.c:8267
> 0x83a9688 gfc_trans_pointer_assign(gfc_code*)
> ../../trunk/gcc/fortran/trans-expr.c:8054
> 0x8358357 trans_code
> ../../trunk/gcc/fortran/trans.c:1714
> 0x838d62c gfc_generate_function_code(gfc_namespace*)
> ../../trunk/gcc/fortran/trans-decl.c:6261
> 0x830d833 translate_all_program_units
> ../../trunk/gcc/fortran/parse.c:6038
> 0x830d833 gfc_parse_file()
> ../../trunk/gcc/fortran/parse.c:6238
> 0x8352db5 gfc_be_parse_file
> ../../trunk/gcc/fortran/f95-lang.c:202

The ICE location and traceback seem to be related to PR 69604.

[Bug target/78458] [7 Regression] LRA ICE building libgcc for powerpc-linux-gnuspe e500v2

[bergner at gcc dot gnu.org]

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

--- Comment #9 from Peter Bergner  ---
The IFmode usage is coming from HARD_REGNO_CALLER_SAVE_MODE(8, 2, TFmode)
returning IFmode, which comes from choose_hard_reg_mode (8, 2, false).  As a
quick hack, I modified HARD_REGNO_CALLER_SAVE_MODE() to instead return TFmode,
and it didn't ICE.

I'm testing the following patch (which is a little more general) on a
powerpc64le-linux bootstrap to see if this survives.

Index: gcc/config/rs6000/rs6000.h
===
--- gcc/config/rs6000/rs6000.h  (revision 241976)
+++ gcc/config/rs6000/rs6000.h  (working copy)
@@ -1279,9 +1279,11 @@ enum data_align { align_abi, align_opt,
enough space to account for vectors in FP regs.  However, TFmode/TDmode
should not use VSX instructions to do a caller save. */
 #define HARD_REGNO_CALLER_SAVE_MODE(REGNO, NREGS, MODE)   
\
-  (TARGET_VSX  \
-   && ((MODE) == VOIDmode || ALTIVEC_OR_VSX_VECTOR_MODE (MODE))   
\
-   && FP_REGNO_P (REGNO)   \
+  (NREGS <= rs6000_hard_regno_nregs[MODE][REGNO]   \
+   ? MODE  \
+   : TARGET_VSX   
\
+ && ((MODE) == VOIDmode || ALTIVEC_OR_VSX_VECTOR_MODE (MODE))  \
+ && FP_REGNO_P (REGNO) \
? V2DFmode  \
: TARGET_E500_DOUBLE && (MODE) == SImode\
? SImode\

[Bug libstdc++/78483] New: Error: reference to 'on_exit' is ambiguous

[krzysztof at jusiak dot net]

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

Bug ID: 78483
   Summary: Error: reference to 'on_exit' is ambiguous
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: krzysztof at jusiak dot net
  Target Milestone: ---

It seems that including cstdlib is not adding std namespace, at least for
on_exit function, which causes ambiguity with user defined type with the same
name.

Example.

#include 

namespace test {
struct on_exit {}; }

int main() {
  using namespace test;
  on_exit{}; // error
}

Full example here:
http://melpon.org/wandbox/permlink/3ddFqVlBGxbB64mF

[Bug fortran/78290] Gfortran incorrectly creates a copy of an array passed to an array pointer dummy argument

[anlauf at gmx dot de]

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

Harald Anlauf  changed:

   What|Removed |Added

 CC||anlauf at gmx dot de

--- Comment #2 from Harald Anlauf  ---
While trying to reduce the reproducer, I encountered a situation where adding
a VOLATILE statement triggers an ICE for the code that is miscompiled:

pr78290a.f90:18:0:

   ip=>ia

internal compiler error: in gfc_add_modify_loc, at fortran/trans.c:159
0x835756e gfc_add_modify_loc(unsigned int, stmtblock_t*, tree_node*,
tree_node*)
../../trunk/gcc/fortran/trans.c:158
0x83575e7 gfc_add_modify(stmtblock_t*, tree_node*, tree_node*)
../../trunk/gcc/fortran/trans.c:170
0x83a90eb gfc_trans_pointer_assignment(gfc_expr*, gfc_expr*)
../../trunk/gcc/fortran/trans-expr.c:8267
0x83a9688 gfc_trans_pointer_assign(gfc_code*)
../../trunk/gcc/fortran/trans-expr.c:8054
0x8358357 trans_code
../../trunk/gcc/fortran/trans.c:1714
0x838d62c gfc_generate_function_code(gfc_namespace*)
../../trunk/gcc/fortran/trans-decl.c:6261
0x830d833 translate_all_program_units
../../trunk/gcc/fortran/parse.c:6038
0x830d833 gfc_parse_file()
../../trunk/gcc/fortran/parse.c:6238
0x8352db5 gfc_be_parse_file
../../trunk/gcc/fortran/f95-lang.c:202

% cat pr78290a.f90
! Wrong code
PROGRAM main
  IMPLICIT NONE
  INTEGER,PARAMETER::KI=4

  TYPE mytype
INTEGER(KIND=KI)::i=1_KI
  END TYPE mytype

  TYPE(mytype),DIMENSION(9),TARGET, SAVE::ta
  INTEGER(KIND=KI),DIMENSION(3),TARGET, SAVE::ia= 3_KI
  INTEGER(KIND=KI),DIMENSION(:),POINTER ::ia2   =>NULL()
  INTEGER(KIND=KI),DIMENSION(:),POINTER ::ip=>NULL()
 volatile::ip
  ALLOCATE(ia2(5)); ia2=2_KI
  ip=>ia
  print*,size(ip)
  CALL sub1(ip)
  print*,size(ip)
  WRITE(*,*)'ia',ia
  WRITE(*,*)'ip',ip

  ip=>ta%i !!! Works if you comment this line out !!!

! Produces:
! ia   2   2   2
! ip   2   2   2
!
! Should produce:
! ia   3   3   3
! ip   2   2   2   2   2
!
! Seems to be creating a copy of ia and setting argument ipa as a pointer this,
and
! changes to this never get transferred back to ia
! Also does not transfer back change of target or INOUT argugment
! Works if you comment out the line "ip=>ta%i"
!
CONTAINS

  SUBROUTINE sub1(ipa)
INTEGER(KIND=KI),DIMENSION(:),POINTER::ipa
ipa => ia2
  END SUBROUTINE sub1

END PROGRAM main

[Bug go/77910] [7 Regression] go: open zversion.go: no such file or directory

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

 Resolution|WONTFIX |FIXED

--- Comment #9 from Ian Lance Taylor  ---
Fixed.

[Bug go/77910] [7 Regression] go: open zversion.go: no such file or directory

[ian at gcc dot gnu.org]

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

--- Comment #8 from ian at gcc dot gnu.org  ---
Author: ian
Date: Tue Nov 22 21:04:27 2016
New Revision: 242724

URL: https://gcc.gnu.org/viewcvs?rev=242724=gcc=rev
Log:
PR go/77910
cmd/go: don't check standard packages when using gccgo

This copies https://golang.org/cl/33295 to libgo.

This fixes GCC PR 77910.

Reviewed-on: https://go-review.googlesource.com/33471

Modified:
trunk/gcc/go/gofrontend/MERGE
trunk/libgo/go/cmd/go/pkg.go

[Bug libstdc++/71096] std::get did not work for nested derived classes from std::tuple if one element is empty

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

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

--- Comment #2 from Marc Glisse  ---
2 things that would help:
- IMO we should implement PR63579 and stop using the EBO. Such a hack (deriving
when we really want a member) is fine in user code, but more questionable in
libraries. Depending on how we implement it exactly, it might even be possible
to preserve the layout of tuples.
- access control in C++ needs to change from a trap (private things are
visible, but if you look at them you get a hard error) to some useful hiding
mechanism. A first step was done in this direction with SFINAE in C++11.

[Bug libfortran/78379] Processor-specific versions for matmul

[jvdelisle at gcc dot gnu.org]

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

--- Comment #21 from Jerry DeLisle  ---
(In reply to Thomas Koenig from comment #19)
> Created attachment 40120 [details]
> Updated patch
> 
> Well, here's an update also for AVX512F.
> 
> I can confirm the patch gives the same performance as the AVX
> version on a machine that supports AVX.  Untested on AVX512, because
> I don't have a machine for that.
> 
> Adding AVX2 would be fairly trivial.
> 
> I'm not sure that yanking out the info into the new cpuinfo.h header
> file is the way to go, but I am not sure of a better way to do it.
> 
> Other comments?

I wonder if there is one in the gcc compile farm. Is the AVX512 a Knights
Landing feature? Which machines have it. (time to google)

[Bug libfortran/78379] Processor-specific versions for matmul

[jvdelisle at gcc dot gnu.org]

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

--- Comment #20 from Jerry DeLisle  ---
(In reply to Thomas Koenig from comment #18)
> Created attachment 40119 [details]
> Version that works (AVX only)
> 
> Here is a version that should only do AVX stuff on Intel processors.
> Optimization for other processor types could come later.

This is interesting. This patch works fine on the AMD processors I tested.

Looking at the disaasembly the vanilla matmul does use the xmm registers but
does not use any vector instructions. Peak with this is about 9.3 gflops.

With -mavx and -mprefer-avx128 the peak is 10.0 gflops or about 7.5%
improvement.

I think get this patch committed and then we can work on the AMD side. I know
Steve is running an FX series AMD processor. Once this patch goes in, I will
give it a spin there. The FX are clearly better than this generation of APU
which is more focused on using the on chip GPU features (which are pretty good)

We will also want to keep an eye on the Zen based processors which I expect
will behave more like Intel regarding the vector instructions (well we will see
anyway)

[Bug libfortran/78379] Processor-specific versions for matmul

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

  Attachment #40119|0   |1
is obsolete||

--- Comment #19 from Thomas Koenig  ---
Created attachment 40120
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40120=edit
Updated patch

Well, here's an update also for AVX512F.

I can confirm the patch gives the same performance as the AVX
version on a machine that supports AVX.  Untested on AVX512, because
I don't have a machine for that.

Adding AVX2 would be fairly trivial.

I'm not sure that yanking out the info into the new cpuinfo.h header
file is the way to go, but I am not sure of a better way to do it.

Other comments?

[Bug target/78451] [7 Regression] FAIL: gcc.target/i386/sse-22a.c: error: inlining failed in call to always_inline '_mm512_setzero_ps'

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Tue Nov 22 20:36:35 2016
New Revision: 242723

URL: https://gcc.gnu.org/viewcvs?rev=242723=gcc=rev
Log:
PR target/78451
* config/i386/avx512bwintrin.h (_mm512_setzero_qi,
_mm512_setzero_hi): Removed.
(_mm512_maskz_mov_epi16, _mm512_maskz_loadu_epi16,
_mm512_maskz_mov_epi8, _mm512_maskz_loadu_epi8,
_mm512_maskz_broadcastb_epi8, _mm512_maskz_set1_epi8,
_mm512_maskz_broadcastw_epi16, _mm512_maskz_set1_epi16,
_mm512_mulhrs_epi16, _mm512_maskz_mulhrs_epi16, _mm512_mulhi_epi16,
_mm512_maskz_mulhi_epi16, _mm512_mulhi_epu16,
_mm512_maskz_mulhi_epu16, _mm512_maskz_mullo_epi16,
_mm512_cvtepi8_epi16, _mm512_maskz_cvtepi8_epi16, _mm512_cvtepu8_epi16,
_mm512_maskz_cvtepu8_epi16, _mm512_permutexvar_epi16,
_mm512_maskz_permutexvar_epi16, _mm512_avg_epu8, _mm512_maskz_avg_epu8,
_mm512_maskz_add_epi8, _mm512_maskz_sub_epi8, _mm512_avg_epu16,
_mm512_maskz_avg_epu16, _mm512_subs_epi8, _mm512_maskz_subs_epi8,
_mm512_subs_epu8, _mm512_maskz_subs_epu8, _mm512_adds_epi8,
_mm512_maskz_adds_epi8, _mm512_adds_epu8, _mm512_maskz_adds_epu8,
_mm512_maskz_sub_epi16, _mm512_subs_epi16, _mm512_maskz_subs_epi16,
_mm512_subs_epu16, _mm512_maskz_subs_epu16, _mm512_maskz_add_epi16,
_mm512_adds_epi16, _mm512_maskz_adds_epi16, _mm512_adds_epu16,
_mm512_maskz_adds_epu16, _mm512_srl_epi16, _mm512_maskz_srl_epi16,
_mm512_packs_epi16, _mm512_sll_epi16, _mm512_maskz_sll_epi16,
_mm512_maddubs_epi16, _mm512_maskz_maddubs_epi16, _mm512_unpackhi_epi8,
_mm512_maskz_unpackhi_epi8, _mm512_unpackhi_epi16,
_mm512_maskz_unpackhi_epi16, _mm512_unpacklo_epi8,
_mm512_maskz_unpacklo_epi8, _mm512_unpacklo_epi16,
_mm512_maskz_unpacklo_epi16, _mm512_shuffle_epi8,
_mm512_maskz_shuffle_epi8, _mm512_min_epu16, _mm512_maskz_min_epu16,
_mm512_min_epi16, _mm512_maskz_min_epi16, _mm512_max_epu8,
_mm512_maskz_max_epu8, _mm512_max_epi8, _mm512_maskz_max_epi8,
_mm512_min_epu8, _mm512_maskz_min_epu8, _mm512_min_epi8,
_mm512_maskz_min_epi8, _mm512_max_epi16, _mm512_maskz_max_epi16,
_mm512_max_epu16, _mm512_maskz_max_epu16, _mm512_sra_epi16,
_mm512_maskz_sra_epi16, _mm512_srav_epi16, _mm512_maskz_srav_epi16,
_mm512_srlv_epi16, _mm512_maskz_srlv_epi16, _mm512_sllv_epi16,
_mm512_maskz_sllv_epi16, _mm512_maskz_packs_epi16, _mm512_packus_epi16,
_mm512_maskz_packus_epi16, _mm512_abs_epi8, _mm512_maskz_abs_epi8,
_mm512_abs_epi16, _mm512_maskz_abs_epi16, _mm512_dbsad_epu8,
_mm512_maskz_dbsad_epu8, _mm512_srli_epi16, _mm512_maskz_srli_epi16,
_mm512_slli_epi16, _mm512_maskz_slli_epi16, _mm512_shufflehi_epi16,
_mm512_maskz_shufflehi_epi16, _mm512_shufflelo_epi16,
_mm512_maskz_shufflelo_epi16, _mm512_srai_epi16,
_mm512_maskz_srai_epi16, _mm512_packs_epi32,
_mm512_maskz_packs_epi32, _mm512_packus_epi32,
_mm512_maskz_packus_epi32): Use _mm512_setzero_si512 instead of
_mm512_setzero_qi or _mm512_setzero_hi.
(_mm512_maskz_alignr_epi8, _mm512_dbsad_epu8,
_mm512_maskz_dbsad_epu8): Formatting fixes.
(_mm512_srli_epi16, _mm512_maskz_srli_epi16, _mm512_slli_epi16,
_mm512_maskz_slli_epi16, _mm512_shufflehi_epi16,
_mm512_maskz_shufflehi_epi16, _mm512_shufflelo_epi16,
_mm512_maskz_shufflelo_epi16, _mm512_srai_epi16,
_mm512_maskz_srai_epi16): Use _mm512_setzero_si512 instead of
_mm512_setzero_qi or _mm512_setzero_hi.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/avx512bwintrin.h

[Bug bootstrap/78477] [7 Regression] bootstrap broken on s390x-linux-gnu

[glisse at gcc dot gnu.org]

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

--- Comment #3 from Marc Glisse  ---
Stage2 issue, so most likely gcc was miscompiled during stage1. If you have a
chance to run the testsuite on a non-bootstrap compiler, that often gives
testcases that are much easier to debug...

[Bug c/78482] New: wrong code at -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu

[chengniansun at gmail dot com]

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

Bug ID: 78482
   Summary: wrong code at -O3 in both 32-bit and 64-bit modes on
x86_64-linux-gnu
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chengniansun at gmail dot com
  Target Milestone: ---

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20161122 (experimental) [trunk revision 242702] (GCC)
$ gcc-trunk -O3 small.c ; ./a.out
2
$ gcc-trunk -O2 small.c ; ./a.out
$ cat small.c
int printf(const char*, ...);
short a = 65531;
int b = 3, f;
char c, d;
void fn1(int p1) {
  short e;
  b = f;
  if (f > p1 && p1)
  L:
  for (e = 0; 0;)
;
  else if (d) b = 0 >= b;
  for (; e <= 3; e++) {
if (b)
  continue;
b = 3;
goto L;
  }
}

int main() {
  for (; c >= 0; c--) {
if (!b) {
  printf("%d\n", 2);
  continue;
}
fn1(a);
  }
  return 0;
}
$
$

[Bug target/78458] [7 Regression] LRA ICE building libgcc for powerpc-linux-gnuspe e500v2

[bergner at gcc dot gnu.org]

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

--- Comment #8 from Peter Bergner  ---
Last one, I promise.  We don't need _Complex at all:

extern void bar (void);
long double
foo (long double p1)
{
  bar ();
  asm volatile ("# clobbers" :::
"r14", "r15", "r16", "r17", "r18", "r19",
"r20", "r21", "r22", "r23", "r24", "r25",
"r26", "r27", "r28", "r29", "r30", "r31");

  return p1;
}

[Bug libgcc/78481] New: libunwind.a conflicting recipes on AIX

[dje at gcc dot gnu.org]

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

Bug ID: 78481
   Summary: libunwind.a conflicting recipes on AIX
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc-ibm-aix*

libgcc/Makefile.in defines:

libgcc.a libgcov.a libunwind.a libgcc_eh.a:
-rm -f $@

objects="$(objects)";   \
if test -z "$$objects"; then\
  echo 'int __libgcc_eh_dummy;' > eh_dummy.c;   \
  $(gcc_compile_bare) $(vis_hide) -c eh_dummy.c \
 -o eh_dummy$(objext);  \
  objects=eh_dummy$(objext);\
fi; \
$(AR_CREATE_FOR_TARGET) $@ $$objects

$(RANLIB) $@

and

libunwind$(SHLIB_EXT): $(libunwind-s-objects) $(extra-parts)
# @multilib_flags@ is still needed because this may use
# $(GCC_FOR_TARGET) and $(LIBGCC2_CFLAGS) directly.
# @multilib_dir@ is not really necessary, but sometimes it has
# more uses than just a directory name.
$(mkinstalldirs) $(MULTIDIR)
$(subst @multilib_flags@,$(CFLAGS) -B./,$(subst \
@multilib_dir@,$(MULTIDIR),$(subst \
@shlib_objs@,$(objects),$(subst \
@shlib_base_name@,libunwind,$(subst \
@shlib_slibdir_qual@,$(MULTIOSSUBDIR),$(SHLIBUNWIND_LINK))

endif

SHLIB_EXT is ".a" on AIX (a shared library is an archive of shared objects), so
the two recipes define the same target. This leads to the warning:

Makefile:985: warning: overriding recipe for target `libunwind.a'
Makefile:922: warning: ignoring old recipe for target `libunwind.a'

The Makefile generates the correct result by accident.

[Bug target/78458] [7 Regression] LRA ICE building libgcc for powerpc-linux-gnuspe e500v2

[bergner at gcc dot gnu.org]

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

--- Comment #7 from Peter Bergner  ---
Here's a smaller test case that induces spilling which leads to our ICE:

extern void bar (void);
_Complex
foo (long double p1)
{
  _Complex e;
  bar ();
  asm volatile ("# clobbers" :::
"r14", "r15", "r16", "r17", "r18", "r19",
"r20", "r21", "r22", "r23", "r24", "r25",
"r26", "r27", "r28", "r29", "r30", "r31");

  __imag__ e = p1;
  return e;
}

[Bug libgcc/78481] libunwind.a conflicting recipes on AIX

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

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

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

[Bug target/78480] New: m68k-rtems compile error in libgfortran

[joel at gcc dot gnu.org]

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

Bug ID: 78480
   Summary: m68k-rtems compile error in libgfortran
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joel at gcc dot gnu.org
  Target Milestone: ---

$ ./gcc/xgcc --version
xgcc (GCC) 7.0.0 20161121 (experimental)

I think the key is -mcpu=5206 has double and long double to be the same but
_LDBL_EQ_DBL. Craig Howland suggested adding this to newlib's ieeefp.h which
detected that it wasn't defined.

#if (DBL_MANT_DIG == LDBL_MANT_DIG)  &&  (LDBL_MIN_EXP == DBL_MIN_EXP)  && \
 (LDBL_MAX_EXP == DBL_MAX_EXP)
   #define _LDBL_EQ_DBL
  #else
   #error "LDBL != DBL"
#endif
#endif


m68k-rtems4.12/sys-include -DHAVE_CONFIG_H -I. -I../../../../gcc/libgfortran
-iquote../../../../gcc/libgfortran/io -I../../../../gcc/libgfortran/../gcc
-I../../../../gcc/libgfortran/../gcc/config -I../../.././gcc
-I../../../../gcc/libgfortran/../libgcc -I../../libgcc
-I../../../../gcc/libgfortran/../libbacktrace -I../../libbacktrace
-I../libbacktrace -std=gnu11 -Wall -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wextra -Wwrite-strings
-Werror=implicit-function-declaration -Werror=vla -fcx-fortran-rules
-ffunction-sections -fdata-sections -g -O2 -mcpu=5206 -MT single.lo -MD -MP -MF
.deps/single.Tpo -c ../../../../gcc/libgfortran/caf/single.c -o single.o
In file included from ../../../../gcc/libgfortran/libgfortran.h:81:0,
 from ../../../../gcc/libgfortran/caf/libcaf.h:33,
 from ../../../../gcc/libgfortran/caf/single.c:26:
/home/joel/test-gcc/gcc/newlib/libc/include/ieeefp.h:152:2: error: #error
"double and long double are the same size but LDBL_EQ_DBL is not defined"
 #error "double and long double are the same size but LDBL_EQ_DBL is not
defined"
  ^
/home/joel/test-gcc/gcc/newlib/libc/include/ieeefp.h:195:3: error: unknown type
name '__ieee_ext_field_type'
   __ieee_ext_field_type  ext_fracl : EXT_FRACLBITS;
   ^
/home/joel/test-gcc/gcc/newlib/libc/include/ieeefp.h:195:38: error:
'EXT_FRACLBITS' undeclared here (not in a function); did you mean
'EXT_FRACBITS'?
   __ieee_ext_field_type  ext_fracl : EXT_FRACLBITS;
  ^
  EXT_FRACBITS
/home/joel/test-gcc/gcc/newlib/libc/include/ieeefp.h:195:26: error: bit-field
'ext_fracl' width not an integer constant
   __ieee_ext_field_type  ext_fracl : EXT_FRACLBITS;
  ^
/home/joel/test-gcc/gcc/newlib/libc/include/ieeefp.h:196:3: error: unknown type
name '__ieee_ext_field_type'
   __ieee_ext_field_type  ext_frach : EXT_FRACHBITS;
   ^
/home/joel/test-gcc/gcc/newlib/libc/include/ieeefp.h:196:38: error:
'EXT_FRACHBITS' undeclared here (not in a function); did you mean
'EXT_FRACLBITS'?
   __ieee_ext_field_type  ext_frach : EXT_FRACHBITS;
  ^
  EXT_FRACLBITS
/home/joel/test-gcc/gcc/newlib/libc/include/ieeefp.h:196:26: error: bit-field
'ext_frach' width not an integer constant
   __ieee_ext_field_type  ext_frach : EXT_FRACHBITS;
  ^
/home/joel/test-gcc/gcc/newlib/libc/include/ieeefp.h:197:3: error: unknown type
name '__ieee_ext_field_type'
   __ieee_ext_field_type  ext_exp   : EXT_EXPBITS;
   ^
/home/joel/test-gcc/gcc/newlib/libc/include/ieeefp.h:197:38: error:
'EXT_EXPBITS' undeclared here (not in a function); did you mean 'EXT_EXP_BIAS'?
   __ieee_ext_field_type  ext_exp   : EXT_EXPBITS;
  ^~~
  EXT_EXP_BIAS
/home/joel/test-gcc/gcc/newlib/libc/include/ieeefp.h:197:26: error: bit-field
'ext_exp' width not an integer constant
   __ieee_ext_field_type  ext_exp   : EXT_EXPBITS;
  ^~~
/home/joel/test-gcc/gcc/newlib/libc/include/ieeefp.h:198:3: error: unknown type
name '__ieee_ext_field_type'
   __ieee_ext_field_type  ext_sign  : 1;
   ^

[C++ PR 78252] illformed lamda?

[Nathan Sidwell]

Jason,
digging further into the demangler crash of 78252, I think the root 
cause is ill-formed C++.  Here's a further reduced testcase.


template
void for2 (T )
{
}

void Foo ()
{
  auto lam_1 = [](int &) { };
  auto lam_2 = [](auto &) { }; // IIUC this is implicitly templatey

  for2 (lam_1);
  for2 (lam_2);  // What is the lambda's argument type?
}

We get 2 instantiations of for2:
.type   _Z4for2IZ3FoovEUlRiE_EvRT_, @function
.type   _Z4for2IZ3FoovEUlRT_E0_EvS1_, @function

The first one has 'UlRiE_' for the lambda -- a reference to an int.  The 
second one has 'UlRT_E0_' a reference to the first template parm.  But 
it's in the template parm specification itself (I...E), so that must be 
bogus.


It looks to me that deduction of the lambda's argument type has got 
tangled up with deduction of the template function's type. (I've not 
looked at pt.c yet)


Is that second call of for2 illformed?

nathan

--
Nathan Sidwell

[Bug target/78458] [7 Regression] LRA ICE building libgcc for powerpc-linux-gnuspe e500v2

[bergner at gcc dot gnu.org]

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

--- Comment #6 from Peter Bergner  ---
This whole lra reload is due to us trying to split insns like the following:

(insn 129 281 264 9 (set (subreg:TF (reg:TI 315 [orig:262 p1 ] [262]) 0)
(reg/v:TF 173 [ p1 ])) "pr78458.i":17 1930 {*frob_ti_tf_2}
 (expr_list:REG_DEAD (reg/v:TF 173 [ p1 ])
(nil)))

Old reload just leaves the insn alone.

[Bug go/77910] [7 Regression] go: open zversion.go: no such file or directory

[ian at airs dot com]

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

--- Comment #7 from Ian Lance Taylor  ---
Coincidentally I am going to submit the patch to fix this today.  It was held
up for a while in code review on the master repository.  (The fix in the master
repository is https://golang.org/cl/33295).

[Bug target/78458] [7 Regression] LRA ICE building libgcc for powerpc-linux-gnuspe e500v2

[bergner at gcc dot gnu.org]

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

--- Comment #5 from Peter Bergner  ---
gdb show we don't like:

(gdb) frame 1
#1  0x10a7d328 in lra_set_insn_recog_data (insn=0x3fffb5584340) at
/home/bergner/gcc/gcc-fsf-mainline-reg-move_costs-base/gcc/lra.c:963
963   gcc_assert (GET_CODE (PATTERN (insn)) == USE
(gdb) pr insn
(insn 281 280 129 9 (set (subreg:SI (reg/v:TF 173 [ p1 ]) 12)
(subreg:SI (reg:IF 325) 12)) "pr78458.i":17 -1
 (nil))

Looking at the -mno-lra output, it's interesting that we don't have any use of
IFmode anywhere.

[Bug target/78458] [7 Regression] LRA ICE building libgcc for powerpc-linux-gnuspe e500v2

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-22
 CC||bergner at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Peter Bergner  ---
Confirmed with the following creduced test case:

bergner@genoa:~/gcc/BUGS/GNU_SPE$ cat pr78458.i 
long double a, f, g, h, i;
long double b, c, d, k;
_Complex
foo (long double p1)
{
  _Complex e;
  a = k * h;
  b = p1 * g;
  if (__builtin_expect(c, 0)
  && __builtin_expect(d, 0))
{
  long double j = __builtin_expect(k, 0);
  if (__builtin_expect(j, 0))
p1 = __builtin_copysignl(1, p1);
  a = b = b - i;
  if (f)
d = h + p1 * g;
}
  e = c;
  __imag__ e = d;
  return e;
}
bergner@genoa:~/gcc/BUGS/GNU_SPE$
/home/bergner/gcc/build/gcc-fsf-mainline-gnuspe/gcc/xgcc
-B/home/bergner/gcc/build/gcc-fsf-mainline-gnuspe/gcc -O2 -mcpu=8548 -S
pr78458.i 
pr78458.i: In function ‘foo’:
pr78458.i:22:1: internal compiler error: in lra_set_insn_recog_data, at
lra.c:965
 }
 ^
0x10a7d327 lra_set_insn_recog_data(rtx_insn*)
/home/bergner/gcc/gcc-fsf-mainline-reg-move_costs-base/gcc/lra.c:963
0x10a7a177 lra_get_insn_recog_data
   
/home/bergner/gcc/gcc-fsf-mainline-reg-move_costs-base/gcc/lra-int.h:487
0x10a7fc8f lra_update_insn_regno_info(rtx_insn*)
/home/bergner/gcc/gcc-fsf-mainline-reg-move_costs-base/gcc/lra.c:1585
0x10a806af lra_push_insn_1
/home/bergner/gcc/gcc-fsf-mainline-reg-move_costs-base/gcc/lra.c:1736
0x10a80713 lra_push_insn(rtx_insn*)
/home/bergner/gcc/gcc-fsf-mainline-reg-move_costs-base/gcc/lra.c:1744
0x10a80973 push_insns
/home/bergner/gcc/gcc-fsf-mainline-reg-move_costs-base/gcc/lra.c:1787
0x10a80ca7 lra_process_new_insns(rtx_insn*, rtx_insn*, rtx_insn*, char const*)
/home/bergner/gcc/gcc-fsf-mainline-reg-move_costs-base/gcc/lra.c:1835
0x10aa6f5f split_reg
   
/home/bergner/gcc/gcc-fsf-mainline-reg-move_costs-base/gcc/lra-constraints.c:5369
0x10aab417 inherit_in_ebb
   
/home/bergner/gcc/gcc-fsf-mainline-reg-move_costs-base/gcc/lra-constraints.c:6178
0x10aab8d3 lra_inheritance()
   
/home/bergner/gcc/gcc-fsf-mainline-reg-move_costs-base/gcc/lra-constraints.c:6248
0x10a82cf3 lra(_IO_FILE*)
/home/bergner/gcc/gcc-fsf-mainline-reg-move_costs-base/gcc/lra.c:2403
0x109fe61f do_reload
/home/bergner/gcc/gcc-fsf-mainline-reg-move_costs-base/gcc/ira.c:5381
0x109fee53 execute
/home/bergner/gcc/gcc-fsf-mainline-reg-move_costs-base/gcc/ira.c:5565

[Bug fortran/78479] ICE in gfc_apply_init, at fortran/expr.c:4135

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

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

[Bug target/78478] Compile Error for i386-rtems

[ubizjak at gmail dot com]

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

--- Comment #2 from Uroš Bizjak  ---
For 7.0, somebody changed i[34567]86-*-rtems* entry in libgcc/config.host to
use t-softfp-sfdftf. Please test the following patch:

Index: libgcc/config.host
===
--- libgcc/config.host  (revision 242716)
+++ libgcc/config.host  (working copy)
@@ -638,7 +638,7 @@
extra_parts=crtbegin.o
;;
 i[34567]86-*-rtems*)
-   tmake_file="$tmake_file i386/t-crtstuff t-softfp-sfdftf
i386/32/t-softfp i386/t-softfp t-softfp"
+   tmake_file="$tmake_file i386/t-crtstuff t-softfp-sfdf i386/32/t-softfp
i386/t-softfp t-softfp"
extra_parts="$extra_parts crti.o crtn.o"
;;
 i[34567]86-*-solaris2* | x86_64-*-solaris2.1[0-9]*)

Please commit the patch to SVN, if it works OK.

[Bug fortran/78479] ICE in gfc_apply_init, at fortran/expr.c:4135

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

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

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

Whereas, these variants are ok :


$ cat z3.f90
program p
   type t
  character(2) :: c(1) = 'a' // ['b']
   end type
   type(t) :: z
   print *, len(z%c), size(z%c), z
end


$ gfortran-7-20161120 z3.f90
$ a.out
   2   1 ab



$ cat z4.f90
program p
   type t
  character(3) :: c(1)
   end type
   type(t) :: z
   z%c = 'a' // ['b']
   print *, len(z%c), size(z%c), z
end


$ gfortran-7-20161120 z4.f90
$ a.out
   3   1 ab

[Bug fortran/78479] New: ICE in gfc_apply_init, at fortran/expr.c:4135

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

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

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

With valid code down to at least 4.8 :


$ cat z1.f90
program p
   type t
  character(3) :: c(1) = 'a' // ['b']
   end type
end


$ cat z2.f90
program p
   type t
  character(1) :: c(1) = 'a' // ['b']
   end type
end


$ gfortran-7-20161120 z1.f90
f951: internal compiler error: Segmentation fault
0xc4265f crash_signal
../../gcc/toplev.c:333
0x68f1b2 gfc_apply_init(gfc_typespec*, symbol_attribute*, gfc_expr*)
../../gcc/fortran/expr.c:4135
0x6828bf build_struct
../../gcc/fortran/decl.c:1943
0x6828bf variable_decl
../../gcc/fortran/decl.c:2443
0x6828bf gfc_match_data_decl()
../../gcc/fortran/decl.c:4898
0x6daa89 match_word_omp_simd
../../gcc/fortran/parse.c:93
0x6de03e match_word
../../gcc/fortran/parse.c:377
0x6de03e decode_statement
../../gcc/fortran/parse.c:377
0x6dfe44 next_free
../../gcc/fortran/parse.c:1180
0x6dfe44 next_statement
../../gcc/fortran/parse.c:1413
0x6e138a parse_derived
../../gcc/fortran/parse.c:3233
0x6e138a parse_spec
../../gcc/fortran/parse.c:3773
0x6e3bc3 parse_progunit
../../gcc/fortran/parse.c:5615
0x6e51b4 gfc_parse_file()
../../gcc/fortran/parse.c:6124
0x729052 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:202

[Bug target/78478] Compile Error for i386-rtems

[joel at gcc dot gnu.org]

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

Joel Sherrill  changed:

   What|Removed |Added

 Target||i386-rtems4.12
  Known to work||6.2.1
Version|unknown |7.0

--- Comment #1 from Joel Sherrill  ---
This error did not exist in "6.2.1 20161110"

$ ./gcc/xgcc --version
xgcc (GCC) 7.0.0 20161121 (experimental)
This patch allowed the build to continue:

diff --git a/libgcc/soft-fp/extended.h b/libgcc/soft-fp/extended.h
index 7b19e83..6c7396d 100644
--- a/libgcc/soft-fp/extended.h
+++ b/libgcc/soft-fp/extended.h
@@ -66,7 +66,11 @@
 #define _FP_HIGHBIT_DW_E   \
   ((_FP_W_TYPE) 1 << (_FP_WFRACBITS_DW_E - 1) % _FP_W_TYPE_SIZE)

+#ifdef _SOFT_FLOAT
+typedef float XFtype;
+#else
 typedef float XFtype __attribute__ ((mode (XF)));
+#endif

 #if _FP_W_TYPE_SIZE < 64

[Bug fortran/58001] Make it possible to silence "Extension: Tab character in format" warning

[kargl at gcc dot gnu.org]

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

--- Comment #16 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Tue Nov 22 18:25:55 2016
New Revision: 242717

URL: https://gcc.gnu.org/viewcvs?rev=242717=gcc=rev
Log:
2016-11-22  Steven G. Kargl  

PR fortran/58001
* io.c (next_char_not_space): Update handling of a 'tab' in a FORMAT.
(format_lex): Adjust invocations of next_char_not_space().

2016-11-22  Steven G. Kargl  

PR fortran/58001
* gfortran.dg/fmt_tab_1.f90: Adjust testcase.
* gfortran.dg/fmt_tab_2.f90: Ditto.

Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/io.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/fmt_tab_1.f90
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/fmt_tab_2.f90

[Bug target/78478] New: Compile Error for i386-rtems

[joel at gcc dot gnu.org]

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

Bug ID: 78478
   Summary: Compile Error for i386-rtems
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joel at gcc dot gnu.org
  Target Milestone: ---

This is on the git master (13d9a9837159ecd162d08fbbe2ef655aebb7a4c9) as of
yesterday.

This appears to be an issue with soft-float.

/home/joel/test-gcc/b-i386-rtems4.12-gcc/./gcc/xgcc
-B/home/joel/test-gcc/b-i386-rtems4.12-gcc/./gcc/ -nostdinc
-B/home/joel/test-gcc/b-i386-rtems4.12-gcc/i386-rtems4.12/newlib/ -isystem
/home/joel/test-gcc/b-i386-rtems4.12-gcc/i386-rtems4.12/newlib/targ-include
-isystem /home/joel/test-gcc/gcc/newlib/libc/include
-B/home/joel/test-gcc/install-master/i386-rtems4.12/bin/
-B/home/joel/test-gcc/install-master/i386-rtems4.12/lib/ -isystem
/home/joel/test-gcc/install-master/i386-rtems4.12/include -isystem
/home/joel/test-gcc/install-master/i386-rtems4.12/sys-include-g -O2
-msoft-float -O2 -I../../../../gcc/libgcc/../newlib/libc/sys/rtems/include -g
-O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition  -isystem ./include   -g -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-protector -Dinhibit_libc  -I. -I. -I../../.././gcc
-I../../../../gcc/libgcc -I../../../../gcc/libgcc/.
-I../../../../gcc/libgcc/../gcc -I../../../../gcc/libgcc/../include 
-DHAVE_CC_TLS  -Wno-missing-prototypes -Wno-type-limits -o trunctfdf2.o -MT
trunctfdf2.o -MD -MP -MF trunctfdf2.dep  -c
../../../../gcc/libgcc/soft-fp/trunctfdf2.c -fvisibility=hidden -DHIDE_EXPORTS
/home/joel/test-gcc/b-i386-rtems4.12-gcc/./gcc/xgcc
-B/home/joel/test-gcc/b-i386-rtems4.12-gcc/./gcc/ -nostdinc
-B/home/joel/test-gcc/b-i386-rtems4.12-gcc/i386-rtems4.12/newlib/ -isystem
/home/joel/test-gcc/b-i386-rtems4.12-gcc/i386-rtems4.12/newlib/targ-include
-isystem /home/joel/test-gcc/gcc/newlib/libc/include
-B/home/joel/test-gcc/install-master/i386-rtems4.12/bin/
-B/home/joel/test-gcc/install-master/i386-rtems4.12/lib/ -isystem
/home/joel/test-gcc/install-master/i386-rtems4.12/include -isystem
/home/joel/test-gcc/install-master/i386-rtems4.12/sys-include-g -O2
-msoft-float -O2 -I../../../../gcc/libgcc/../newlib/libc/sys/rtems/include -g
-O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition  -isystem ./include   -g -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-protector -Dinhibit_libc  -I. -I. -I../../.././gcc
-I../../../../gcc/libgcc -I../../../../gcc/libgcc/.
-I../../../../gcc/libgcc/../gcc -I../../../../gcc/libgcc/../include 
-DHAVE_CC_TLS  -Wno-missing-prototypes -Wno-type-limits -o trunctfxf2.o -MT
trunctfxf2.o -MD -MP -MF trunctfxf2.dep  -c
../../../../gcc/libgcc/soft-fp/trunctfxf2.c -fvisibility=hidden -DHIDE_EXPORTS
In file included from ../../../../gcc/libgcc/soft-fp/extendxftf2.c:31:0:
../../../../gcc/libgcc/soft-fp/extended.h:69:1: error: unable to emulate 'XF'
 typedef float XFtype __attribute__ ((mode (XF)));

[Bug fortran/38319] Memory leaks in allocatable component expressions

[pault at gcc dot gnu.org]

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

--- Comment #9 from Paul Thomas  ---
class_array_15.f03 leaks from line 65-66:
  allocate (indv(2), source = [individual(1, [99,999]), &
   individual(2, [999,])])


==22496== HEAP SUMMARY:
==22496== in use at exit: 32 bytes in 4 blocks
==22496==   total heap usage: 31 allocs, 27 frees, 12,096 bytes allocated
==22496== 
==22496== 8 bytes in 1 blocks are definitely lost in loss record 1 of 3
==22496==at 0x4A0645D: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==22496==by 0x403582: pr53876_ (class_array_15.f03:66)
==22496==by 0x403D83: MAIN__ (class_array_15.f03:53)
==22496==by 0x403DC4: main (class_array_15.f03:56)
==22496== 
==22496== 8 bytes in 1 blocks are definitely lost in loss record 2 of 3
==22496==at 0x4A0645D: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==22496==by 0x40375C: pr53876_ (class_array_15.f03:66)
==22496==by 0x403D83: MAIN__ (class_array_15.f03:53)
==22496==by 0x403DC4: main (class_array_15.f03:56)
==22496== 
==22496== 16 bytes in 2 blocks are definitely lost in loss record 3 of 3
==22496==at 0x4A0645D: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==22496==by 0x4039AE: pr53876_ (class_array_15.f03:66)
==22496==by 0x403D83: MAIN__ (class_array_15.f03:53)
==22496==by 0x403DC4: main (class_array_15.f03:56)
==22496== 
==22496== LEAK SUMMARY:
==22496==definitely lost: 32 bytes in 4 blocks
==22496==indirectly lost: 0 bytes in 0 blocks
==22496==  possibly lost: 0 bytes in 0 blocks
==22496==still reachable: 0 bytes in 0 blocks
==22496== suppressed: 0 bytes in 0 blocks
==22496== 
==22496== For counts of detected and suppressed errors, rerun with: -v
==22496== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 2 from 2)

The coming patch for PR78293 halves this number. The remaining leaks are
associated with the temporaries associated with individual(1, [99,999]), where
the component 'genes' does not get deallocated.

Paul

[Bug go/77910] [7 Regression] go: open zversion.go: no such file or directory

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #6 from Markus Trippelsdorf  ---
No reaction. I no longer build Go. Closing.

[Bug bootstrap/78477] [7 Regression] bootstrap broken on s390x-linux-gnu

[doko at gcc dot gnu.org]

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

--- Comment #2 from Matthias Klose  ---
sorry, no, just saw yesterday's changes to match.pd as a hint.

[Bug bootstrap/78477] [7 Regression] bootstrap broken on s390x-linux-gnu

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
Did you bisect this to a specific commit? (I assumed so from the cc:, but the
revision number does not match one of my patches)

[Bug middle-end/78409] Segfault in classify_object_over_fdes when throwing and exception

[orion at cora dot nwra.com]

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

--- Comment #2 from Orion Poplawski  ---
So, what exactly can I get you?

I'm building
https://www.cora.nwra.com/~orion/fedora/octave-4.2.0-1.fc26.src.rpm on Fedora
rawhide.  It fails during the tests:

  libinterp/dldfcn/__osmesa_print__.cc-tst panic:
Segmentation fault -- stopping myself...

You can run the test in gdb with:

cd octave-4.2.0
./run-octave -g
gdb> run
octave:1> test __osmesa_print__

[Bug bootstrap/78477] New: [7 Regression] bootstrap broken on s390x-linux-gnu

[doko at gcc dot gnu.org]

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

Bug ID: 78477
   Summary: [7 Regression] bootstrap broken on s390x-linux-gnu
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

trunk r242706 fails to bootstrap on s390x-linux-gnu:

original build log (search for "error:")
https://launchpadlibrarian.net/294554997/buildlog_ubuntu-zesty-s390x.gcc-7_7-20161123-0ubuntu1_BUILDING.txt.gz

echo timestamp > s-preds-h
/bin/bash ../../src/gcc/../move-if-change tmp-condmd.c build/gencondmd.c
echo timestamp > s-conditions
/<>/build/./prev-gcc/xg++ -B/<>/build/./prev-gcc/
-B/usr/s390x-linux-gnu/bin/ -nostdinc++
-B/<>/build/prev-s390x-linux-gnu/libstdc++-v3/src/.libs
-B/<>/build/prev-s390x-linux-gnu/libstdc++-v3/libsupc++/.libs 
-I/<>/build/prev-s390x-linux-gnu/libstdc++-v3/include/s390x-linux-gnu
 -I/<>/build/prev-s390x-linux-gnu/libstdc++-v3/include 
-I/<>/src/libstdc++-v3/libsupc++
-L/<>/build/prev-s390x-linux-gnu/libstdc++-v3/src/.libs
-L/<>/build/prev-s390x-linux-gnu/libstdc++-v3/libsupc++/.libs -c  
-g -O2 -fno-stack-protector -gtoggle -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H
-DGENERATOR_FILE -fno-PIE -I. -Ibuild -I../../src/gcc -I../../src/gcc/build
-I../../src/gcc/../include  -I../../src/gcc/../libcpp/include  \
-o build/gencondmd.o build/gencondmd.c
/<>/build/./prev-gcc/xg++ -B/<>/build/./prev-gcc/
-B/usr/s390x-linux-gnu/bin/ -nostdinc++
-B/<>/build/prev-s390x-linux-gnu/libstdc++-v3/src/.libs
-B/<>/build/prev-s390x-linux-gnu/libstdc++-v3/libsupc++/.libs 
-I/<>/build/prev-s390x-linux-gnu/libstdc++-v3/include/s390x-linux-gnu
 -I/<>/build/prev-s390x-linux-gnu/libstdc++-v3/include 
-I/<>/src/libstdc++-v3/libsupc++
-L/<>/build/prev-s390x-linux-gnu/libstdc++-v3/src/.libs
-L/<>/build/prev-s390x-linux-gnu/libstdc++-v3/libsupc++/.libs   -g
-O2 -fno-stack-protector -gtoggle -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H
-DGENERATOR_FILE -fno-PIE -static-libstdc++ -static-libgcc -Wl,-z,relro -no-pie
-o build/genmatch \
build/genmatch.o ../libcpp/libcpp.a ../libiberty/libiberty.a build/errors.o
build/vec.o build/hash-table.o .././libiberty/libiberty.a  
build/genmatch --gimple ../../src/gcc/match.pd \
> tmp-gimple-match.c
../../src/gcc/match.pd:93:3 warning: duplicate pattern
 (plus:c @0 real_zerop@1)
  ^
../../src/gcc/match.pd:82:6 warning: previous pattern defined here
(op @0 integer_zerop)
 ^
(PLUS_EXPR @0 real_zerop@1)
../../src/gcc/match.pd:99:3 warning: duplicate pattern
 (minus @0 real_zerop@1)
  ^
../../src/gcc/match.pd:82:6 warning: previous pattern defined here
(op @0 integer_zerop)
 ^
(MINUS_EXPR @0 real_zerop@1)
../../src/gcc/match.pd:122:3 warning: duplicate pattern
 (mult @0 real_zerop@1)
  ^
../../src/gcc/match.pd:114:3 warning: previous pattern defined here
 (mult @0 integer_zerop@1)
  ^
(MULT_EXPR @0 real_zerop@1)
../../src/gcc/match.pd:129:3 warning: duplicate pattern
 (mult @0 real_onep)
  ^
../../src/gcc/match.pd:114:3 warning: previous pattern defined here
 (mult @0 integer_zerop@1)
  ^
(MULT_EXPR @0 real_onep)
../../src/gcc/match.pd:129:3 warning: duplicate pattern
 (mult @0 real_onep)
  ^
../../src/gcc/match.pd:122:3 warning: previous pattern defined here
 (mult @0 real_zerop@1)
  ^
(MULT_EXPR @0 real_onep)
../../src/gcc/match.pd:137:3 warning: duplicate pattern
 (mult @0 real_minus_onep)
  ^
../../src/gcc/match.pd:114:3 warning: previous pattern defined here
 (mult @0 integer_zerop@1)
  ^
(MULT_EXPR @0 real_minus_onep)
../../src/gcc/match.pd:137:3 warning: duplicate pattern
 (mult @0 real_minus_onep)
  ^
../../src/gcc/match.pd:122:3 warning: previous pattern defined here
 (mult @0 real_zerop@1)
  ^
(MULT_EXPR @0 real_minus_onep)
../../src/gcc/match.pd:137:3 warning: duplicate pattern
 (mult @0 real_minus_onep)
  ^
../../src/gcc/match.pd:129:3 warning: previous pattern defined here
 (mult @0 real_onep)
  ^
(MULT_EXPR @0 real_minus_onep)
../../src/gcc/match.pd:146:6 warning: duplicate pattern
(op @0 integer_onep)
 ^
../../src/gcc/match.pd:114:3 warning: previous pattern defined here
 (mult @0 integer_zerop@1)
  ^
(MULT_EXPR @0 integer_onep)
../../src/gcc/match.pd:146:6 warning: duplicate pattern
(op @0 integer_onep)
 ^
../../src/gcc/match.pd:122:3 warning: previous pattern defined here
 (mult @0 real_zerop@1)
  ^
(MULT_EXPR @0 integer_onep)
../../src/gcc/match.pd:146:6 warning: duplicate 

[Bug tree-optimization/78476] New: snprintf(0, 0, ...) with known arguments not optimized away

[msebor at gcc dot gnu.org]

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

Bug ID: 78476
   Summary: snprintf(0, 0, ...) with known arguments not optimized
away
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

As a special case, a call to snprintf with a zero size is a request to compute
the size of output without actually writing anything into the provided buffer
(which may be a null pointer).  When the format string and all arguments to all
directives in it are within known ranges such that the output length can be
determined at compile time (by the -fprintf-return-value optimization) the
entire snprintf call can be eliminated and replaced with the constant return
value.  The test case below shows that while GCC folds the return value it does
not take advantage of this additional optimization opportunity.

$ cat c.c && /build/gcc-svn/gcc/xgcc -B /build/gcc-svn/gcc -O2 -c
-fdump-tree-optimized=/dev/stdout c.c
void f (const char *s)
{
  int n = 7;
  if (n != __builtin_snprintf (0, 0, "%.*s", n, s))
__builtin_abort ();
}



;; Function f (f, funcdef_no=0, decl_uid=1795, cgraph_uid=0, symbol_order=0)

f (const char * s)
{
  :
  __builtin_snprintf (0B, 0, "%.*s", 7, s_3(D)); [tail call]
  return;

}

[Bug middle-end/78461] [7 Regression] ICE: in operator+=, at gimple-ssa-sprintf.c:214

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
  Component|c   |middle-end
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org

--- Comment #3 from Martin Sebor  ---
Confirmed.  Enabling the -fprintf-return-value optimization makes the pass run
even when -Wformat-length is otherwise inactive which isn't as thoroughly
tested as when the warning is enabled.

[Bug libfortran/78379] Processor-specific versions for matmul

[tkoenig at gcc dot gnu.org]

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

--- Comment #18 from Thomas Koenig  ---
Created attachment 40119
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40119=edit
Version that works (AVX only)

Here is a version that should only do AVX stuff on Intel processors.
Optimization for other processor types could come later.

[Bug c++/77739] [5/6/7 Regression] internal compiler error: in create_tmp_var, at gimple-expr.c:524

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Or another option perhaps would be in cp_genericize_data note whether it is
cp_genericize_tree called from cp_genericize or from elsewhere, and only
replace invisiref parms if called from cp_genericize.

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

[ktkachov at gcc dot gnu.org]

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

--- Comment #30 from ktkachov at gcc dot gnu.org ---
Fixed on aarch64 for 6.3 as well. There's nothing more to do for aarch64 here.
Dominik, do you intend to do any backports of the s390 patches? Or can we close
this?

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

[ktkachov at gcc dot gnu.org]

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

--- Comment #29 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Tue Nov 22 16:55:16 2016
New Revision: 242709

URL: https://gcc.gnu.org/viewcvs?rev=242709=gcc=rev
Log:
[AArch64] Fix PR target/77822: Use tighter predicates for zero_extract patterns

Backport from mainline
2016-11-07  Kyrylo Tkachov  

PR target/77822
* config/aarch64/aarch64.md (*tb1): Use
aarch64_simd_shift_imm_ predicate for operand 1.
(, ANY_EXTRACT): Use tighter predicates on operands 2 and 3
to restrict them to an appropriate range and add FAIL check if the
region they specify is out of range.  Delete useless constraint
strings.
(*, ANY_EXTRACT): Add appropriate predicates on operands
2 and 3 to restrict their range and add pattern predicate.

* g++.dg/torture/pr77822.C: New test.


Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/torture/pr77822.C
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/aarch64/aarch64.md
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug target/78451] [7 Regression] FAIL: gcc.target/i386/sse-22a.c: error: inlining failed in call to always_inline '_mm512_setzero_ps'

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Tue Nov 22 16:54:13 2016
New Revision: 242708

URL: https://gcc.gnu.org/viewcvs?rev=242708=gcc=rev
Log:
PR target/78451
* gcc.target/i386/sse-22.c: Add avx5124fmaps,avx5124vnniw to
GCC target pragma before including immintrin.h.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/sse-22.c

[Bug target/78451] [7 Regression] FAIL: gcc.target/i386/sse-22a.c: error: inlining failed in call to always_inline '_mm512_setzero_ps'

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Tue Nov 22 16:53:35 2016
New Revision: 242707

URL: https://gcc.gnu.org/viewcvs?rev=242707=gcc=rev
Log:
PR target/78451
* config/i386/avx512vlintrin.h (_mm_setzero_di): Removed.
(_mm_maskz_mov_epi64): Use _mm_setzero_si128 instead of
_mm_setzero_di.
(_mm_maskz_load_epi64): Likewise.
(_mm_setzero_hi): Removed.
(_mm_maskz_loadu_epi64): Use _mm_setzero_si128 instead of
_mm_setzero_di.
(_mm_abs_epi64, _mm_maskz_abs_epi64, _mm_maskz_srl_epi64,
_mm_maskz_unpackhi_epi64, _mm_maskz_unpacklo_epi64,
_mm_maskz_compress_epi64, _mm_srav_epi64, _mm_maskz_srav_epi64,
_mm_maskz_sllv_epi64, _mm_maskz_srlv_epi64, _mm_rolv_epi64,
_mm_maskz_rolv_epi64, _mm_rorv_epi64, _mm_maskz_rorv_epi64,
_mm_min_epi64, _mm_max_epi64, _mm_max_epu64, _mm_min_epu64,
_mm_lzcnt_epi64, _mm_maskz_lzcnt_epi64, _mm_conflict_epi64,
_mm_maskz_conflict_epi64, _mm_sra_epi64, _mm_maskz_sra_epi64,
_mm_maskz_sll_epi64, _mm_rol_epi64, _mm_maskz_rol_epi64,
_mm_ror_epi64, _mm_maskz_ror_epi64, _mm_alignr_epi64,
_mm_maskz_alignr_epi64, _mm_srai_epi64, _mm_maskz_slli_epi64):
Likewise.
(_mm_cvtepi32_epi8, _mm256_cvtepi32_epi8, _mm_cvtsepi32_epi8,
_mm256_cvtsepi32_epi8, _mm_cvtusepi32_epi8, _mm256_cvtusepi32_epi8,
_mm_cvtepi32_epi16, _mm256_cvtepi32_epi16, _mm_cvtsepi32_epi16,
_mm256_cvtsepi32_epi16, _mm_cvtusepi32_epi16, _mm256_cvtusepi32_epi16,
_mm_cvtepi64_epi8, _mm256_cvtepi64_epi8, _mm_cvtsepi64_epi8,
_mm256_cvtsepi64_epi8, _mm_cvtusepi64_epi8, _mm256_cvtusepi64_epi8,
_mm_cvtepi64_epi16, _mm256_cvtepi64_epi16, _mm_cvtsepi64_epi16,
_mm256_cvtsepi64_epi16, _mm_cvtusepi64_epi16, _mm256_cvtusepi64_epi16,
_mm_cvtepi64_epi32, _mm256_cvtepi64_epi32, _mm_cvtsepi64_epi32,
_mm256_cvtsepi64_epi32, _mm_cvtusepi64_epi32, _mm256_cvtusepi64_epi32,
_mm_maskz_set1_epi32, _mm_maskz_set1_epi64): Formatting fixes.
(_mm_maskz_cvtps_ph, _mm256_maskz_cvtps_ph): Use _mm_setzero_si128
instead of _mm_setzero_hi.
(_mm256_permutex_pd, _mm256_maskz_permutex_epi64, _mm256_insertf32x4,
_mm256_maskz_insertf32x4, _mm256_inserti32x4, _mm256_maskz_inserti32x4,
_mm256_extractf32x4_ps, _mm256_maskz_extractf32x4_ps,
_mm256_shuffle_i32x4, _mm256_maskz_shuffle_i32x4, _mm256_shuffle_f64x2,
_mm256_maskz_shuffle_f64x2, _mm256_shuffle_f32x4,
_mm256_maskz_shuffle_f32x4, _mm256_maskz_shuffle_pd,
_mm_maskz_shuffle_pd, _mm256_maskz_shuffle_ps, _mm_maskz_shuffle_ps,
_mm256_maskz_srli_epi32, _mm_maskz_srli_epi32, _mm_maskz_srli_epi64,
_mm256_mask_slli_epi32, _mm256_maskz_slli_epi32,
_mm256_mask_slli_epi64,
_mm256_maskz_slli_epi64, _mm256_roundscale_ps,
_mm256_maskz_roundscale_ps, _mm256_roundscale_pd,
_mm256_maskz_roundscale_pd, _mm_roundscale_ps, _mm_maskz_roundscale_ps,
_mm_roundscale_pd, _mm_maskz_roundscale_pd, _mm256_getmant_ps,
_mm256_maskz_getmant_ps, _mm_getmant_ps, _mm_maskz_getmant_ps,
_mm256_getmant_pd, _mm256_maskz_getmant_pd, _mm_getmant_pd,
_mm_maskz_getmant_pd, _mm256_maskz_shuffle_epi32,
_mm_maskz_shuffle_epi32, _mm256_rol_epi32, _mm256_maskz_rol_epi32,
_mm_rol_epi32, _mm_maskz_rol_epi32, _mm256_ror_epi32,
_mm256_maskz_ror_epi32, _mm_ror_epi32, _mm_maskz_ror_epi32,
_mm_maskz_alignr_epi32, _mm_maskz_alignr_epi64,
_mm256_maskz_srai_epi32, _mm_maskz_srai_epi32, _mm_srai_epi64,
_mm_maskz_srai_epi64, _mm256_maskz_permutex_pd,
_mm256_maskz_permute_pd, _mm256_maskz_permute_ps, _mm_maskz_permute_pd,
_mm_maskz_permute_ps, _mm256_permutexvar_ps): Formatting fixes.
(_mm_maskz_slli_epi64, _mm_rol_epi64, _mm_maskz_rol_epi64,
_mm_ror_epi64, _mm_maskz_ror_epi64): Use _mm_setzero_si128 instead of
_mm_setzero_di.
(_mm_maskz_cvtps_ph, _mm256_maskz_cvtps_ph): Use _mm_setzero_si128
instead of _mm_setzero_hi.
* config/i386/avx512dqintrin.h (_mm512_broadcast_f64x2,
_mm512_broadcast_i64x2, _mm512_broadcast_f32x2, _mm512_broadcast_i32x2,
_mm512_broadcast_f32x8, _mm512_broadcast_i32x8): Formatting fixes.
(_mm512_extracti64x2_epi64, _mm512_maskz_extracti64x2_epi64): Use
_mm_setzero_si128 instead of _mm_setzero_di.
(_mm512_cvtt_roundpd_epi64, _mm512_mask_cvtt_roundpd_epi64,
_mm512_maskz_cvtt_roundpd_epi64, _mm512_cvtt_roundpd_epu64,
_mm512_mask_cvtt_roundpd_epu64, _mm512_maskz_cvtt_roundpd_epu64,
_mm512_cvtt_roundps_epi64, _mm512_mask_cvtt_roundps_epi64,
_mm512_maskz_cvtt_roundps_epi64, _mm512_cvtt_roundps_epu64,
_mm512_mask_cvtt_roundps_epu64, _mm512_maskz_cvtt_roundps_epu64,
_mm512_cvt_roundpd_epi64, 

[Bug c++/77739] [5/6/7 Regression] internal compiler error: in create_tmp_var, at gimple-expr.c:524

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
The problem is that some expressions are genericized twice.
First when genericizing the whole function, RESULT_DECL is determined to be
is_invisiref_parm and therefore references to it are turned into INDIRECT_REF
around it and the RESULT_DECL becomes REFERENCE_TYPE.
Later on gimplify_body calls unshare_body and unshares the INDIRECT_REF.
Then the INDIRECT_REF is gimplified into a MEM_REF.  And finally:
(cp_gimplify_expr)  does:
625 cp_walk_tree (expr_p, cp_fold_r, , NULL);
626 cp_genericize_tree (expr_p);
and sees the is_invisiref_parm RESULT_DECL again (inside of MEM_REF) and turns
it again into INDIRECT_REF and that is later gimplified again into MEM_REF.  So
we have 2 nested MEM_REFs, so one indirection too many.

I think one possibility would be to be careful about REFERENCE_REF_Ps and
corresponding MEM_REFs (I guess would need to double check that the offset is 0
and type is compatible with the type of the reference), if their argument is
is_invisiref_parm, ensure it isn't convert_from_reference again.  Will try to
implement that now.

[Bug target/78386] [PPC] Optimization -O2 and higher cause math inconsistency

[brenohl at br dot ibm.com]

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

Breno Leitao  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #12 from Breno Leitao  ---
Ack. Closing as 'Invalid'

[Bug target/78459] [7 Regression] [SH] ICE in maybe_record_trace_start building glibc string tests

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

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

[Bug target/78459] [7 Regression] [SH] ICE in maybe_record_trace_start building glibc string tests

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Created attachment 40118
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40118=edit
A bit reduced test-case

ICE error message is:
...

Processing trace 158 : start at note 3215
   saw edge from trace 158 to 212 (via jump_insn 4189)
Inconsistent CFI state!
SHOULD have:
.cfi_def_cfa 15, 32
.cfi_offset 8, -4
.cfi_offset 9, -8
.cfi_offset 10, -12
.cfi_offset 11, -16
.cfi_offset 12, -20
.cfi_offset 13, -24
.cfi_offset 14, -28
.cfi_offset 17, -32
DO have:
.cfi_def_cfa 15, 0

[Bug c++/78434] Incorrect warning about missing align_val_t for placement new

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Isn't this Bug 77742 which is already fixed?

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

[Bug c++/77742] Warning about placement new for over-aligned type

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||marc.mutz at kdab dot com

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

[Bug libstdc++/78465] [7 regression] 29_atomics/headers/atomic/macros.cc FAILs

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Should be fixed now.

[Bug libstdc++/78465] [7 regression] 29_atomics/headers/atomic/macros.cc FAILs

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Author: redi
Date: Tue Nov 22 16:31:19 2016
New Revision: 242704

URL: https://gcc.gnu.org/viewcvs?rev=242704=gcc=rev
Log:
PR78465 Remove runtime tests for  macros

PR libstdc++/78465
* testsuite/29_atomics/headers/atomic/macros.cc: Replace runtime tests
with preprocessor conditions.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/testsuite/29_atomics/headers/atomic/macros.cc

[Bug fortran/78443] [OOP] Incorrect behavior with non_overridable keyword

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |5.5

--- Comment #7 from janus at gcc dot gnu.org ---
The problem is fixed on trunk with r242703. Thanks for reporting!

I plan to backport the fix to the release branches (5 and 6) within a week or
so, and will keep the issue open until this is done.

[Bug fortran/78443] [OOP] Incorrect behavior with non_overridable keyword

[janus at gcc dot gnu.org]

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

--- Comment #6 from janus at gcc dot gnu.org ---
Author: janus
Date: Tue Nov 22 16:06:46 2016
New Revision: 242703

URL: https://gcc.gnu.org/viewcvs?rev=242703=gcc=rev
Log:
2016-11-22  Janus Weil  

PR fortran/78443
* class.c (add_proc_comp): Add a vtype component for non-overridable
procedures that are overriding.

2016-11-22  Janus Weil  

PR fortran/78443
* gfortran.dg/typebound_proc_35.f90: New test case.

Added:
trunk/gcc/testsuite/gfortran.dg/typebound_proc_35.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/class.c
trunk/gcc/testsuite/ChangeLog

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

[jsm28 at gcc dot gnu.org]

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

--- Comment #5 from Joseph S. Myers  ---
Created attachment 40117
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40117=edit
preprocessed source

Preprocessed source of file causing ICE attached.  Compile with: -S -g -O2
-fPIC -fbuilding-libgcc -fno-stack-protector linux-atomic.i

Compiler configured with: /scratch/jmyers/glibc/many7/src/gcc/configure
'--prefix=/scratch/jmyers/glibc/many7/install/compilers/m68k-linux-gnu-coldfire'
'--build=x86_64-pc-linux-gnu' '--host=x86_64-pc-linux-gnu'
'--target=m68k-glibc-linux-gnu'
'--with-sysroot=/scratch/jmyers/glibc/many7/install/compilers/m68k-linux-gnu-coldfire/sysroot'
'--with-arch=cf' --disable-multilib --disable-libsanitizer --disable-libssp
'--with-gmp=/scratch/jmyers/glibc/many7/install/host-libraries'
'--with-mpfr=/scratch/jmyers/glibc/many7/install/host-libraries'
'--with-mpc=/scratch/jmyers/glibc/many7/install/host-libraries'
'--enable-languages=c' --disable-shared --disable-threads --disable-libatomic
--disable-decimal-float --disable-libffi --disable-libgomp --disable-libitm
--disable-libmpx --disable-libquadmath --without-headers --with-newlib
'--with-glibc-version=2.24'

[Bug libstdc++/78465] [7 regression] 29_atomics/headers/atomic/macros.cc FAILs

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
We should have used __builtin_abort() there, rather than add an incorrect
definition. Better yet would be to use static_assert.

[Bug libstdc++/78475] Mixing objects form different g++ versions can crash a program

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Jan Engelhardt from comment #0)
> Is mixing "finalized" object files (ET_EXEC, ET_DYN) produced by different
> g++ versions a supported scenario?

Yes, but prior to GCC 5 it was only supported for C++98/C++03 code. Since
std::make_shared() is a C++11 feature, it's not supported to mix code compiled
by GCC 4.x with code compiled by later releases.

Since GCC 5.1 C++11 support is complete and non-experimental, and mixing
objects compiled by GCC 5 and GCC 6 (and future releases) is OK.

[Bug libstdc++/78475] Mixing objects form different g++ versions can crash a program

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
Ugh. Probably due to r197554 or r198367