[Bug rtl-optimization/78583] [7 Regression] ICE on valid C code at -O3 on x86_64-linux-gnu (internal compiler error: in simplify_truncation)

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

[Bug rtl-optimization/78588] rtlanal.c:5210:38: runtime error: shift exponent 4294967295 is too large for 64-bit type 'long unsigned int'

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #2 from Markus Trippelsdorf  ---
Fixed on trunk.

[Bug fortran/78593] [6/7 Regression] ICE in gfc_match_varspec, at fortran/primary.c:2053

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-30
 CC||janus at gcc dot gnu.org
Summary|ICE in gfc_match_varspec,   |[6/7 Regression] ICE in
   |at fortran/primary.c:2053   |gfc_match_varspec, at
   ||fortran/primary.c:2053
 Ever confirmed|0   |1

--- Comment #2 from janus at gcc dot gnu.org ---
Confirmed. Reduced test case:

type(t) function add (x, y)
  type(t), intent(in) :: x, y
  add%a = x%a + y%a
end

[Bug fortran/78592] [7 Regression] ICE in gfc_find_specific_dtio_proc, at fortran/interface.c:4939

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||6.2.0
   Keywords||ice-on-invalid-code
   Last reconfirmed||2016-11-30
 CC||janus at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|ICE in  |[7 Regression] ICE in
   |gfc_find_specific_dtio_proc |gfc_find_specific_dtio_proc
   |, at|, at
   |fortran/interface.c:4939|fortran/interface.c:4939
  Known to fail||7.0

--- Comment #1 from janus at gcc dot gnu.org ---
This is a regression. gfortran 6 does not support DTIO and shows no ICE.

[Bug rtl-optimization/78588] rtlanal.c:5210:38: runtime error: shift exponent 4294967295 is too large for 64-bit type 'long unsigned int'

[trippels at gcc dot gnu.org]

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

--- Comment #1 from Markus Trippelsdorf  ---
Author: trippels
Date: Wed Nov 30 07:30:55 2016
New Revision: 242997

URL: https://gcc.gnu.org/viewcvs?rev=242997=gcc=rev
Log:
Fix PR78588 - rtlanal.c:5210:38: runtime error: shift exponent 4294967295 is
too large for 64-bit type

Building gcc with -fsanitize=undefined shows:
 rtlanal.c:5210:38: runtime error: shift exponent 4294967295 is too large for
64-bit type 'long unsigned int'

This happens because if_then_else_cond() in combine.c calls
num_sign_bit_copies() in rtlanal.c with mode==BLKmode.

5205   bitwidth = GET_MODE_PRECISION (mode);
5206   if (bitwidth > HOST_BITS_PER_WIDE_INT)
5207 return 1;
5208
5209   nonzero = nonzero_bits (x, mode);
5210   return nonzero & (HOST_WIDE_INT_1U << (bitwidth - 1))
5211  ? 1 : bitwidth - floor_log2 (nonzero) - 1;

This causes (bitwidth - 1) to wrap around.

PR rtl-optimization/78588
* combine.c (if_then_else_cond): Also guard against BLKmode.
* rtlanal.c (num_sign_bit_copies1): Add assert.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/combine.c
trunk/gcc/rtlanal.c

[Bug fortran/78573] [7 Regression] [OOP] ICE in resolve_component, at fortran/resolve.c:13405

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from janus at gcc dot gnu.org ---
Fixed with r242996. Closing.

[Bug fortran/78573] [7 Regression] [OOP] ICE in resolve_component, at fortran/resolve.c:13405

[janus at gcc dot gnu.org]

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

--- Comment #3 from janus at gcc dot gnu.org ---
Author: janus
Date: Wed Nov 30 07:25:36 2016
New Revision: 242996

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

PR fortran/78573
* decl.c (build_struct): On error, return directly and do not build
class symbol.

2016-11-30  Janus Weil  

PR fortran/78573
* gfortran.dg/class_61.f90: New test case.

Added:
trunk/gcc/testsuite/gfortran.dg/class_61.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/78607] New: [7 Regression] ICE: verify_flow_info failed (error: missing barrier after block 2)

[asolokha at gmx dot com]

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

Bug ID: 78607
   Summary: [7 Regression] ICE: verify_flow_info failed (error:
missing barrier after block 2)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: powerpc-*-linux-gnu*

gcc-7.0.0-alpha20161127 snapshot (r242902) w/ stand-alone r242947 applied on
top of it ICEs when compiling the following snippets for 32-bit BE powerpc w/
-O2 or above:

% cat ffjloyn2.c 
void
rc (int cx)
{
  int mq;

  if (mq == 0 && (cx / 0) != 0)
for (;;)
  {
  }
}
% powerpc-e300c3-linux-gnu-gcc-7.0.0-alpha20161127 -O2 -w -c ffjloyn2.c
ffjloyn2.c: In function 'rc':
ffjloyn2.c:10:1: error: missing barrier after block 2
 }
 ^
ffjloyn2.c:10:1: internal compiler error: verify_flow_info failed
0x30be2f3d1a1 verify_flow_info()
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20161127/work/gcc-7-20161127/gcc/cfghooks.c:260
0x30be2f57c91 execute
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20161127/work/gcc-7-20161127/gcc/cfgrtl.c:3569

% cat lvh5rgvk.c
void
xt (void)
{
  int pk, op;

  for (;;)
if (pk >= op)
  op /= 0;
}
% powerpc-e300c3-linux-gnu-gcc-7.0.0-alpha20161127 -O2 -w -c lvh5rgvk.c
lvh5rgvk.c: In function 'xt':
lvh5rgvk.c:9:1: error: missing barrier after block 2
 }
 ^
lvh5rgvk.c:9:1: internal compiler error: verify_flow_info failed
0x2b5475d11a1 verify_flow_info()
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20161127/work/gcc-7-20161127/gcc/cfghooks.c:260
0x2b5475ebc91 execute
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20161127/work/gcc-7-20161127/gcc/cfgrtl.c:3569

[Bug rtl-optimization/78342] [7 Regression] ICE in rtl_verify_bb_insns, at cfgrtl.c:2657 (error: flow control insn inside a basic block)

[asolokha at gmx dot com]

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

--- Comment #6 from Arseny Solokha  ---
(In reply to Segher Boessenkool from comment #5)
> Please file a separate bug.

I've filed PR78607.

[Bug tree-optimization/78529] [7 Regression] gcc.c-torture/execute/builtins/strcat-chk.c failed with lto/O2

[pinskia at gcc dot gnu.org]

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

--- Comment #13 from Andrew Pinski  ---
https://gcc.gnu.org/ml/gcc-testresults/2016-11/msg03338.html

[Bug c/78584] Bug in GCC argument parser expandargv

[dj at redhat dot com]

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

DJ Delorie  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #6 from DJ Delorie  ---
I'm using ext4

[Bug c/78584] Bug in GCC argument parser expandargv

[fw at gcc dot gnu.org]

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

--- Comment #5 from Florian Weimer  ---
Hmm.  Maybe it is file-system-specific.  I don't see the anomalous return
values on XFS and tmpfs.

[Bug tree-optimization/78529] [7 Regression] gcc.c-torture/execute/builtins/strcat-chk.c failed with lto/O2

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Target|aarch64 |aarch64-elf
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-30
 Ever confirmed|0   |1

--- Comment #12 from Andrew Pinski  ---
Fails only on -elf targets for me. That is it passes for aarch64-linux-gnu but
not for aarch64-elf. My testsuite go to the mailing list if anyone wants to
look into them.

[Bug c/78584] Bug in GCC argument parser expandargv

[dj at redhat dot com]

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

--- Comment #4 from DJ Delorie  ---
kernel-4.8.6-201.fc24.x86_64
glibc-2.23.1-11.fc24.x86_64

but I'm also working on a libiberty patch to detect the case and avoid it.

[Bug c/78584] Bug in GCC argument parser expandargv

[fw at gcc dot gnu.org]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fw at gcc dot gnu.org

--- Comment #3 from Florian Weimer  ---
(In reply to DJ Delorie from comment #2)
> Confirmed on Fedora 24 with gcc 6.2.1, but agreed, the @file thing is for
> reading arguments from a file, not compiling a file that starts with @.  It
> shouldn't fail like that though.

This probably depends on the kernel version.  Could you provide this
information?

[Bug tree-optimization/78529] [7 Regression] gcc.c-torture/execute/builtins/strcat-chk.c failed with lto/O2

[wilson at gcc dot gnu.org]

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

--- Comment #11 from Jim Wilson  ---
FYI I'm using the gdb simulator to run the testcases.

[Bug ipa/78599] [7 Regression] hwint.h:292:72: runtime error: shift exponent 64 is too large for 64-bit type 'long int'

[prathamesh3492 at gcc dot gnu.org]

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

--- Comment #2 from prathamesh3492 at gcc dot gnu.org ---
Hi Markus,
Thanks for the report, I am able to reproduce it with ubsan-built gcc
(--with-build-config=bootstrap-ubsan) on x86_64-unknown-linux-gnu.
I am looking into it.

Thanks,
Prathamesh

[Bug tree-optimization/55177] missed optimizations with __builtin_bswap

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||TREE

--- Comment #19 from Andrew Pinski  ---
Note some of these are optimized now at the RTL level but we should be able to
catch some more at the TREE level.  I hope to do some of that over Christmas in
time for stage 1.

[Bug libobjc/23681] CLS_HAS_CXX_STRUCTORS is not supported with the GNU runtime

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
No longer working on this.

[Bug rtl-optimization/46888] missed optimization of zero_extract with constant inputs

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #9 from Andrew Pinski  ---
No longer working on this.

[Bug libobjc/24775] libobjc should not include GCC's target headers

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #9 from Andrew Pinski  ---
No longer working on this.

[Bug testsuite/36165] Foreign exceptions for Objective-C and C++ are not tested

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
No longer working on this.

[Bug libfortran/78549] Very slow formatted internal file output

[jvdelisle at gcc dot gnu.org]

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

--- Comment #8 from Jerry DeLisle  ---
(In reply to Jerry DeLisle from comment #7)
Correction:
> Regardless, I will be looking at pr78351 (which is a result of doing some
> speedups for internal units) and I will be thinking more about this PR here.

[Bug libfortran/78549] Very slow formatted internal file output

[jvdelisle at gcc dot gnu.org]

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

--- Comment #7 from Jerry DeLisle  ---
(In reply to mecej4 from comment #6)
> (In reply to Jerry DeLisle from comment #5)
> > 
> > Can you explain what "Windows Subsystem for Linux (Ubuntu 14) on Windows-10"
> > is?
> 
> Sorry if I created a bad portmanteau phrase. 
> 
> Here is a link to Microsoft's own description of WSL (Windows Subsystem for
> Linux) : https://msdn.microsoft.com/en-us/commandline/wsl/about .
> 
> This beta product for Windows 10-x64 provides a Bash shell in which
> character I/O, user-mode Linux applications can be run (only 64-bit a.out
> supported). I found it fairly simple to install, and it worked well for the
> tests that I tried. Once Bash has been installed, one can install Ubuntu-14
> packages using Apt-Get; in particular, there is a Gfortran 6.2 package that
> works.
> 
> While browsing the sources of LibGfortran, I found the file which seemed to
> be a candidate for profiling: write_float.def, which I understand you are
> currently revising.

Thanks for the explanation. I am done with planned changes to write_float.def.
It really is not fair to compare f2c/gcc because f2c does some optimizations we
can not do and we have many runtime checks that have to be done to support F95,
F2003, F2008. Regardless I am always looking for ways to improve.
Unfortunately, some of my ideas would involve significant rewrites of things.
(aka changing the entire structure of how we do things in libgfortran)

With that said, I don't think write_float is fundamentally the issue here. We
have to handle a plethora of formatting of the float strings, depending on the
the format string. decimal status, comma status, blank status, rounding modes,
etc. We call snprintf to get the basic numeric strings and build the required
output from there. After all that, we send it out.

Regardless, I will be looking at pr78531 (which is a result of doing some
speedups for internal units) and I will be thinking more about this PR here.

[Bug libfortran/78549] Very slow formatted internal file output

[mecej4 at operamail dot com]

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

--- Comment #6 from mecej4 at operamail dot com ---
(In reply to Jerry DeLisle from comment #5)
> 
> Can you explain what "Windows Subsystem for Linux (Ubuntu 14) on Windows-10"
> is?

Sorry if I created a bad portmanteau phrase. 

Here is a link to Microsoft's own description of WSL (Windows Subsystem for
Linux) : https://msdn.microsoft.com/en-us/commandline/wsl/about .

This beta product for Windows 10-x64 provides a Bash shell in which character
I/O, user-mode Linux applications can be run (only 64-bit a.out supported). I
found it fairly simple to install, and it worked well for the tests that I
tried. Once Bash has been installed, one can install Ubuntu-14 packages using
Apt-Get; in particular, there is a Gfortran 6.2 package that works.

While browsing the sources of LibGfortran, I found the file which seemed to be
a candidate for profiling: write_float.def, which I understand you are
currently revising.

[Bug middle-end/78606] New: -Wformat-length/-fprintf-return-value incorrect for %+.0i and %.0o with zero value

[msebor at gcc dot gnu.org]

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

Bug ID: 78606
   Summary: -Wformat-length/-fprintf-return-value incorrect for
%+.0i and %.0o with zero value
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

There's an obscure rule in C that says that an integer conversion specification
with a zero precision and zero value (such as a "%.0i") results in bytes. 
There's an even more obscure rule that implies that the + flag (but no other
flag) results in a sole plus sign being output when used in such a directive
(i.e., "%+.0i").  And yet another obscure rule says that when used with the o
conversion (but none other), the # flag has the effect of increasing zero
precision from zero to 1 when used with a zero argument so that "%#.0o" results
in a 0 on output (while "%#.0x" results in nothing).  The test case below shows
that the gimple-ssa-sprintf pass doesn't get these subtleties right.

$ (set -x; cat c.c && for f in '"%+.0i"' '"%#.0o"'; do /build/gcc-git/gcc/xgcc
-B /build/gcc-git/gcc -DFMT="$f" -O2 -Wextra -Wformat-length c.c && ./a.out;
done)
+ cat c.c
const char* fmt = FMT;

int main (void)
{
   int n = __builtin_snprintf (0, 0, FMT, 0);

  if (n != __builtin_snprintf (0, 0, fmt, 0))
__builtin_abort ();
}
+ for f in ''\''"%+.0i"'\''' ''\''"%#.0o"'\'''
+ /build/gcc-git/gcc/xgcc -B /build/gcc-git/gcc '-DFMT="%+.0i"' -O2 -Wextra
-Wformat-length c.c
+ ./a.out
+ for f in ''\''"%+.0i"'\''' ''\''"%#.0o"'\'''
+ /build/gcc-git/gcc/xgcc -B /build/gcc-git/gcc '-DFMT="%#.0o"' -O2 -Wextra
-Wformat-length c.c
+ ./a.out

[Bug preprocessor/78569] "internal compiler error: in get_substring_ranges_for_loc" processing sprintf buffer overflow

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #6 from David Malcolm  ---
Should be fixed by r242990; marking this as resolved.  Feel free to reopen it
if you still see the problem after r242990.

[Bug preprocessor/78569] "internal compiler error: in get_substring_ranges_for_loc" processing sprintf buffer overflow

[dmalcolm at gcc dot gnu.org]

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

--- Comment #5 from David Malcolm  ---
Author: dmalcolm
Date: Wed Nov 30 01:13:37 2016
New Revision: 242990

URL: https://gcc.gnu.org/viewcvs?rev=242990=gcc=rev
Log:
substring locations and # line directives (PR preprocessor/78569)

The ICE in PR preprocessor/78569 appears to be due to an attempt to
generate substring locations in a .i file where the underlying .c file
has changed since the .i file was generated.

This can't work, so it seems safest for the on-demand substring
locations to be unavailable for such files, falling back to
"whole string" locations for such cases.

gcc/ChangeLog:
PR preprocessor/78569
* input.c (get_substring_ranges_for_loc): Fail gracefully if
line directives were present.

gcc/testsuite/ChangeLog:
PR preprocessor/78569
* gcc.dg/format/pr78569.c: New test case.

Added:
trunk/gcc/testsuite/gcc.dg/format/pr78569.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/input.c
trunk/gcc/testsuite/ChangeLog

[Bug libgcc/78576] [PPC] wrong long double to long int conversion

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

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

--- Comment #15 from Bill Schmidt  ---
So, closing as invalid.

[Bug middle-end/78605] bogus -Wformat-length=1 with %f

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  ---
On Tue, 29 Nov 2016, msebor at gcc dot gnu.org wrote:

> As an independent issue, since the type of the arguments to the %f directive 
> is
> float (not double), the checker should use -FLT_MAX rather than -DBL_MAX to
> determine the output.

That may not be safe in general, because of excess range and precision.

In the -fexcess-precision=standard case, the front end will have dealt 
with the excess precision as needed, involving wider types explicitly and 
truncating anything wider than double to double for the variable 
arguments.  Given that these checks are done in the middle end, it will 
see IR where the excess precision is explicit and shouldn't have problems 
with it.

In the -fexcess-precision=fast (default) case, however, the fact that a 
float value might have long double range and precision is invisible to the 
middle end.  On 32-bit x86 the truncation to double will happen as a 
result of storing the argument on the stack, but the double value could 
be outside the range of float without anything in the IR indicating this.

(Remember that with -fexcess-precision=fast, even values stored in 
variables can have excess range and precision, not just direct results of 
arithmetic.  Generally, the issue is where there is implicit excess 
precision in the back end; explicit excess precision inserted in the IR by 
the front end shouldn't be an issue, except for affecting portability of 
testcases.)

[Bug target/70905] [7 regression] FAIL: gcc.c-torture/compile/20011219-2.c -Os (unrecognizable insn)

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||bernds at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #1 from Bernd Schmidt  ---
No longer seems to happen with a powerpc-linux cross and -frename-registers.

[Bug libgcc/78576] [PPC] wrong long double to long int conversion

[joseph at codesourcery dot com]

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

--- Comment #14 from joseph at codesourcery dot com  ---
On Tue, 29 Nov 2016, bergner at gcc dot gnu.org wrote:

> Using gdb, I see:
> 
> (gdb) info registers f1 f2
> f1 27   (raw 0x403b)
> f2 -3.0814879110195774e-33  (raw 0xb930)

Given this, there's no bug in libgcc (truncating to 26 is correct) and 
none in glibc either (that low part is -2^-108, which is much less than 
1ulp of 27).

[Bug target/78597] [7 regression] test case gcc.dg/torture/fp-int-convert-float128-ieee.c (and others) fail starting with r242780

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  ---
If these fail but weren't previously run then it's not a regression, but 
an indication of a wrong-code bug in the float128 support for powerpc (for 
which testing was previously very limited - even now, the _FloatN / 
_FloatNx tests are fairly basic).

[Bug sanitizer/78532] [7 Regression] libsanitizer fails to build on sparc64-linux-gnu

[joseph at codesourcery dot com]

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

--- Comment #5 from joseph at codesourcery dot com  ---
On Tue, 29 Nov 2016, m.ostapenko at samsung dot com wrote:

> /home/max/src/glibc/resolv/ns_print.c:99: undefined reference to
> `__stack_chk_guard'

You get this if glibc and GCC have mismatched stack checking 
configuration.  To avoid that, use the --with-glibc-version= 
option when configuring a bootstrap GCC to be used to build glibc.

Mainline glibc's build-many-glibcs.py knows how to configure GCC and glibc 
for building many different configurations.  It uses 
--disable-libsanitizer, but if libsanitizer is meant to work for all glibc 
configurations you could try removing it (adding it back for the initial 
bootstrap GCC only) and seeing what libsanitizer problems it shows up.

[Bug target/78594] Bug in November 11th, 2016 change to rs6000.md

[meissner at gcc dot gnu.org]

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

--- Comment #4 from Michael Meissner  ---
Fixed in subversion id 242983.

[Bug target/78594] Bug in November 11th, 2016 change to rs6000.md

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

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

--- Comment #3 from Michael Meissner  ---
Fixed in subversion id 242983.

[Bug target/78594] Bug in November 11th, 2016 change to rs6000.md

[meissner at gcc dot gnu.org]

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

--- Comment #2 from Michael Meissner  ---
Author: meissner
Date: Wed Nov 30 00:05:46 2016
New Revision: 242983

URL: https://gcc.gnu.org/viewcvs?rev=242983=gcc=rev
Log:
2016-11-29  Michael Meissner  

PR target/78594
* config/rs6000/rs6000.md (mov_internal, QHI iterator): Add
'x' to stxsix print pattern, so that QImode and HImode values
residing in traditional altivec registers can be stored
correctly.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.md

[Bug sanitizer/78532] [7 Regression] libsanitizer fails to build on sparc64-linux-gnu

[doko at gcc dot gnu.org]

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

--- Comment #4 from Matthias Klose  ---
using the glibc build from Debian unstable, build logs at
https://buildd.debian.org/status/package.php?p=glibc

see https://buildd.debian.org/status/logs.php?pkg=glibc=sparc64
for the last successful build.

[Bug tree-optimization/78586] [7 Regression] Wrong code caused by printf-return-value

[msebor at gcc dot gnu.org]

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

--- Comment #6 from Martin Sebor  ---
(In reply to Jakub Jelinek from comment #5)
> There are still various weird spots in format_integer.
> E.g.
>   else if (TREE_CODE (TREE_TYPE (arg)) == INTEGER_TYPE
>|| TREE_CODE (TREE_TYPE (arg)) == POINTER_TYPE)
> {
>   /* Determine the type of the provided non-constant argument.  */
>   if (TREE_CODE (arg) == NOP_EXPR)
> arg = TREE_OPERAND (arg, 0);
>   else if (TREE_CODE (arg) == CONVERT_EXPR)
> arg = TREE_OPERAND (arg, 0);
>   if (TREE_CODE (arg) == COMPONENT_REF)
> arg = TREE_OPERAND (arg, 1);
>   
>   argtype = TREE_TYPE (arg);
> }
> When would this actually happen?

I checked by running the builtin-sprintf*.c tests and none of the conditions is
true for any of them so it looks like it might be dead code from an earlier
versions of the pass that I never took out.

> 2) for SSA_NAMEs with VR_RANGE, you only look at the argument's ranges,
> while for something VR_VARYING and similar you consider both dirtype and
> argtype's precision.  Isn't it always UB if the precision is different? 

For %hhi and %hi the argument type can be char, short, or int, and considering
the type of the directive's "formal" argument avoids warning on cases where the
actual argument would be too big to fit if it were formatted using a directive
for its own type.  Like this:

  char d[4];
  return __builtin_sprintf (d, "%hhu", 123456);


> Corner case might be C bitfields, not sure what exact type one gets when
> passing that to varargs.  For UB wouldn't it be better to punt (return don't
> know value)?

Yes, the pass shouldn't try to make any assumptions when it detects undefined
behavior.  I didn't intentionally encode any such assumptions in it but I may
have done that inadvertently.  Those would be bugs.

> 3) "When precision is specified but unknown, use zero as the minimum since
> it results in no bytes on output (unless width is specified to be greater
> than 0)."
> When is 0 printed as nothing?  I thought it is printed as 0 (or 0x0 etc.).

I thought the same until last week.  Apparently we both thought wrong. 
printf("%.0i", 0) is required to print nothing.  The text is under the  d, i,
o, u, and x/X conversion specifiers: "The result of converting zero with an
explicit precision of zero shall be no characters."

> 4)   if (code == NOP_EXPR)
> argtype = TREE_TYPE (gimple_assign_rhs1 (def));
> Similar case to 1), except it can happen, but argtype could be anything,
> boolean type, perhaps fixed point type, enum, whatever.

I'm not quite sure I follow what you are trying to say here.  This code avoids
false positives for unknown arguments of wider types that are cast to narrower
types, as in: 'sprintf ((char[4]){ }, "%hhi", (unsigned char)i)' where i is an
int with an unknown value.  It strips the NOP_EXPR that promotes the argument
to int and lets the function use the range of the type of the argument before
the promotion.  It could be that I'm missing something so a test case would be
helpful.

[Bug target/78560] powerpc64le ICE with -mcpu=power9

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

  Attachment #40194|0   |1
is obsolete||

--- Comment #4 from Michael Meissner  ---
Created attachment 40196
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40196=edit
Fixed patch that handles the second problem found as well as the initial patch

[Bug target/78426] [7 Regression] wrong code with strncmp on SH

[kkojima at gcc dot gnu.org]

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

--- Comment #5 from Kazumoto Kojima  ---
Fixed on 5/6 branches too.

[Bug target/78426] [7 Regression] wrong code with strncmp on SH

[kkojima at gcc dot gnu.org]

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

--- Comment #4 from Kazumoto Kojima  ---
Author: kkojima
Date: Tue Nov 29 23:23:30 2016
New Revision: 242982

URL: https://gcc.gnu.org/viewcvs?rev=242982=gcc=rev
Log:
Backported from mainline
2016-11-19  Kaz Kojima  

PR target/78426
* config/sh/sh-mem.cc (sh_expand_cmpnstr): Use copy_to_mode_reg
instead of force_reg.
(sh_expand_setmem): Likewise.


Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/sh/sh-mem.cc

[Bug libfortran/78549] Very slow formatted internal file output

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|NEW |WAITING
   Assignee|unassigned at gcc dot gnu.org  |jvdelisle at gcc dot 
gnu.org

--- Comment #5 from Jerry DeLisle  ---
Assigning to myself so I do not forget to look at it in the pile.

Can you explain what "Windows Subsystem for Linux (Ubuntu 14) on Windows-10"
is?

[Bug target/78426] [7 Regression] wrong code with strncmp on SH

[kkojima at gcc dot gnu.org]

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

--- Comment #3 from Kazumoto Kojima  ---
Author: kkojima
Date: Tue Nov 29 23:20:28 2016
New Revision: 242981

URL: https://gcc.gnu.org/viewcvs?rev=242981=gcc=rev
Log:
Backported from mainline
2016-11-19  Kaz Kojima  

PR target/78426
* config/sh/sh-mem.cc (sh_expand_cmpnstr): Use copy_to_mode_reg
instead of force_reg.
(sh_expand_setmem): Likewise.


Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/sh/sh-mem.cc

[Bug libgcc/78576] [PPC] wrong long double to long int conversion

[brenohl at br dot ibm.com]

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

--- Comment #13 from Breno Leitao  ---
(In reply to Bill Schmidt from comment #11)
> Breno, what is your environment?  Which glibc is present?

We found this problem originally on Debian[1], but we tested and reproduced it
even on Big Endian distro.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=845082

[Bug rtl-optimization/78590] [7 Regression] FAIL: gcc.target/aarch64/advsimd-intrinsics/vget_lane.c in change_zero_ext in combine

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

[Bug target/78560] powerpc64le ICE with -mcpu=power9

[meissner at gcc dot gnu.org]

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

--- Comment #3 from Michael Meissner  ---
Unfortunately once you get past the problem with the element being a memory
location, the example does not compile on little endian due to an operand out
of error message from the assembler:

-> ./xgcc -B./ -O3 -mcpu=power9 -save-temps -c pr78560.c -mlittle
pr78560.s: Assembler messages:
pr78560.s:35: Error: operand out of range (56 is not between 0 and 15)

[Bug target/78602] PowerPC vec-extract-v2df.c can fail if -mcpu=power9 -O0

[meissner at gcc dot gnu.org]

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

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

[Bug target/78560] powerpc64le ICE with -mcpu=power9

[meissner at gcc dot gnu.org]

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

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

[Bug target/78560] powerpc64le ICE with -mcpu=power9

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

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

--- Comment #1 from Michael Meissner  ---
The bug is due to 'val' (the value being set into one of the vector elements)
being a memory location, and it generates code assuming it is in a register.

[Bug middle-end/78605] bogus -Wformat-length=1 with %f

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

[Bug middle-end/78605] New: bogus -Wformat-length=1 with %f

[msebor at gcc dot gnu.org]

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

Bug ID: 78605
   Summary: bogus -Wformat-length=1 with %f
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

This issue was raised on the gcc list:
  https://gcc.gnu.org/ml/gcc/2016-11/msg00102.html

In my response I didn't fully understand the problem that was being pointed
out.  Here's a smaller test case that should hopefully make it clearer.  The
issue is that while there is no warning for the sprintf call in f one is
emitted for the call in g.  In both instances the arguments of the call are
unknown and may take on values that will fit into the provided buffer as well
as values that will not.  The -Wformat-length=1 setting is supposed to be
conservative in diagnosing potential overflows by assuming unknown integers
have the value 1.  The same logic should apply to floating point arguments, so
the warning for g is a false positive.

$ cat c.c && gcc -S -O2 -Wall -Wextra c.c
char d[10];

int f (int i)
{
  return __builtin_sprintf (d, "%i %i", i, i);
}

int g (float f)
{
  return __builtin_sprintf (d, "%.2f %.2f", f, f);
}
c.c: In function ‘g’:
c.c:10:38: warning: ‘%.2f’ directive writing between 4 and 317 bytes into a
region of size 0 [-Wformat-length=]
   return __builtin_sprintf (d, "%.2f %.2f", f, f);
  ^~~~
c.c:10:10: note: format output between 10 and 636 bytes into a destination of
size 10
   return __builtin_sprintf (d, "%.2f %.2f", f, f);
  ^~~~


Compiling with -Wformat-length=2 on the other hand emits a warning for the
sprintf call in f because the unknown argument is assumed to take on the value
that results in the largest number of bytes (in  this case -DBL_MAX). 
Similarly, the sprintf call in g is diagnosed (as expected).  What is missing
is a note indicating the range of values the checker considers in the floating
case.

As an independent issue, since the type of the arguments to the %f directive is
float (not double), the checker should use -FLT_MAX rather than -DBL_MAX to
determine the output.

As another, separate, issue, the underlining seems off in the first note in the
integer case.

c.c: In function ‘f’:
c.c:5:33: warning: ‘%i’ directive writing between 1 and 11 bytes into a region
of size 10 [-Wformat-length=]
   return __builtin_sprintf (d, "%i %i", i, i);
 ^~
c.c:5:32: note: using the range [‘1’, ‘-2147483648’] for directive argument
   return __builtin_sprintf (d, "%i %i", i, i);
^~~
c.c:5:10: note: format output between 4 and 24 bytes into a destination of size
10
   return __builtin_sprintf (d, "%i %i", i, i);
  ^~~~
c.c: In function ‘g’:
c.c:10:33: warning: ‘%.2f’ directive writing between 4 and 317 bytes into a
region of size 10 [-Wformat-length=]
   return __builtin_sprintf (d, "%.2f %.2f", f, f);
 ^~~~
c.c:10:10: note: format output between 10 and 636 bytes into a destination of
size 10
   return __builtin_sprintf (d, "%.2f %.2f", f, f);
  ^~~~

[Bug fortran/77517] ICE in conv_intrinsic_move_alloc, at fortran/trans-intrinsic.c:9517

[anlauf at gmx dot de]

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

Harald Anlauf  changed:

   What|Removed |Added

 CC||anlauf at gmx dot de

--- Comment #4 from Harald Anlauf  ---
There appears to be a difference between class(*) and e.g. type(*)
in the detection of clashes.

% cat pr77517-3.f90
  class(*), allocatable :: a
  type(*),  allocatable :: c
contains
  subroutine a
  end
  subroutine c
  end
end

% gfc-trunk -c pr77517-3.f90
pr77517-3.f90:6:14:

   subroutine c
  1
Error: SUBROUTINE attribute conflicts with ALLOCATABLE attribute in 'c' at (1)
pr77517-3.f90:1:28:

   class(*), allocatable :: a
1
pr77517-3.f90:8:3:

 end
   2 
Error: Two main PROGRAMs at (1) and (2)


Also try commenting out one of the declarations.

[Bug target/78603] internal compiler error: in dwarf2out_var_location, at dwarf2out.c:21846

[jcmvbkbc at gcc dot gnu.org]

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

jcmvbkbc at gcc dot gnu.org changed:

   What|Removed |Added

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

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

[Bug c/78584] Bug in GCC argument parser expandargv

[dj at redhat dot com]

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

DJ Delorie  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-29
 CC||dj at redhat dot com
 Ever confirmed|0   |1

--- Comment #2 from DJ Delorie  ---
Confirmed on Fedora 24 with gcc 6.2.1, but agreed, the @file thing is for
reading arguments from a file, not compiling a file that starts with @.  It
shouldn't fail like that though.

gcc: out of memory allocating 9223372036854775808 bytes after a total of 0
bytes

[Bug target/78603] internal compiler error: in dwarf2out_var_location, at dwarf2out.c:21846

[jcmvbkbc at gcc dot gnu.org]

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

--- Comment #3 from jcmvbkbc at gcc dot gnu.org ---
Author: jcmvbkbc
Date: Tue Nov 29 22:22:13 2016
New Revision: 242979

URL: https://gcc.gnu.org/viewcvs?rev=242979=gcc=rev
Log:
xtensa: Fix PR target/78603

2016-11-29  Max Filippov  
gcc/
* config/xtensa/xtensa.c (hwloop_optimize): Don't emit zero
overhead loop start between a call and its CALL_ARG_LOCATION
note.


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

[Bug libgcc/78576] [PPC] wrong long double to long int conversion

[wschmidt at gcc dot gnu.org]

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

--- Comment #12 from Bill Schmidt  ---
Ah, I was incorrect about that.  If I use -O0, the test produces 26 in my
environment as well.  At higher optimization the whole computation is folded.

[Bug tree-optimization/78601] [7 regression] test case gcc.dg/uninit-pred-6_a.c and gcc.dg/uninit-pred-7_c.c fail starting with r242639

[seurer at linux dot vnet.ibm.com]

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

--- Comment #2 from Bill Seurer  ---
That patch indeed seems to fix these problems.

[Bug c/78584] Bug in GCC argument parser expandargv

[tavianator at gmail dot com]

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

Tavian Barnes  changed:

   What|Removed |Added

 CC||tavianator at gmail dot com

--- Comment #1 from Tavian Barnes  ---
Can't reproduce with GCC 6.2.1.  The `@file` syntax is used to read command
line options from `file`.  You can probably write `./@.` if you want to compile
a file with that name.

[Bug libgcc/78576] [PPC] wrong long double to long int conversion

[wschmidt at gcc dot gnu.org]

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

--- Comment #11 from Bill Schmidt  ---
Breno, what is your environment?  Which glibc is present?

[Bug libgcc/78576] [PPC] wrong long double to long int conversion

[wschmidt at gcc dot gnu.org]

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

--- Comment #10 from Bill Schmidt  ---
OK, that accounts for it.  That would be a glibc problem.

Building this code with GCC trunk on Ubuntu 14.04 with glibc 2.19, the program
produces 27 as expected.

[Bug target/78603] internal compiler error: in dwarf2out_var_location, at dwarf2out.c:21846

[jcmvbkbc at gcc dot gnu.org]

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

--- Comment #2 from jcmvbkbc at gcc dot gnu.org ---
Similar bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48214
And looks like the same problem here: first instruction of zero overhead loop
got inserted between the call and its NOTE_INSN_CALL_ARG_LOCATION:

(call_insn 145 144 574 11 (set (reg:SI 10 a10)
(call (mem:SI (reg/f:SI 8 a8 [135]) [0 pj_thread_sleep S4 A32])
(const_int 0 [0]))) ../src/pjlib-test/thread.c:221 56
{call_value_internal}
 (expr_list:REG_DEAD (reg/f:SI 8 a8 [135])
(expr_list:REG_UNUSED (reg:SI 10 a10)
(expr_list:REG_CALL_DECL (symbol_ref:SI ("pj_thread_sleep") [flags
0x41]  )
(nil
(expr_list:SI (use (reg:SI 10 a10))
(nil)))

(insn 574 145 493 11 (parallel [
(set (pc)
(if_then_else (ne (reg:SI 2 a2 [198])
(const_int 1 [0x1]))
(label_ref 175)
(pc)))
(set (reg:SI 2 a2 [198])
(plus (reg:SI 2 a2 [198])
(const_int -1 [0x])))
(unspec [
(const_int 0 [0])
] 12)
]) ../src/pjlib-test/thread.c:221 -1
 (nil))

(note 493 574 494 11 (expr_list:REG_DEP_TRUE (concat:SI (pc)
(const (unspec [
(symbol_ref:SI ("pj_thread_sleep") [flags 0x41] 
)
] 3)))
(expr_list:REG_DEP_TRUE (concat:SI (reg:SI 10 a10)
(const_int 1000 [0x3e8]))
(nil))) NOTE_INSN_CALL_ARG_LOCATION)

[Bug target/78603] internal compiler error: in dwarf2out_var_location, at dwarf2out.c:21846

[jcmvbkbc at gcc dot gnu.org]

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

--- Comment #1 from jcmvbkbc at gcc dot gnu.org ---
Created attachment 40193
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40193=edit
additional patch on top of gcc-5.4.0

[Bug tree-optimization/78604] New: [7 regression] test case gcc.target/powerpc/p8vector-vectorize-1.c fails starting with r242750

[seurer at linux dot vnet.ibm.com]

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

Bug ID: 78604
   Summary: [7 regression] test case
gcc.target/powerpc/p8vector-vectorize-1.c fails
starting with r242750
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at linux dot vnet.ibm.com
  Target Milestone: ---

spawn /home/seurer/gcc/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test/gcc/
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.target/powerpc/p8vector-vectorize-1.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -mcpu=power8 -O2
-ftree-vectorize -fvect-cost-model=dynamic -fno-unroll-loops
-fno-unroll-all-loops -ffat-lto-objects -S -o p8vector-vectorize-1.s
PASS: gcc.target/powerpc/p8vector-vectorize-1.c (test for excess errors)
PASS: gcc.target/powerpc/p8vector-vectorize-1.c scan-assembler-times [\t
]vaddudm[\t ] 2
PASS: gcc.target/powerpc/p8vector-vectorize-1.c scan-assembler-times [\t
]vsubudm[\t ] 3
PASS: gcc.target/powerpc/p8vector-vectorize-1.c scan-assembler-times [\t
]vmaxsd[\t ] 2
PASS: gcc.target/powerpc/p8vector-vectorize-1.c scan-assembler-times [\t
]vmaxud[\t ] 1
PASS: gcc.target/powerpc/p8vector-vectorize-1.c scan-assembler-times [\t
]vminsd[\t ] 1
PASS: gcc.target/powerpc/p8vector-vectorize-1.c scan-assembler-times [\t
]vminud[\t ] 1
PASS: gcc.target/powerpc/p8vector-vectorize-1.c scan-assembler-times [\t
]vsld[\t ] 2
PASS: gcc.target/powerpc/p8vector-vectorize-1.c scan-assembler-times [\t
]vsrad[\t ] 1
PASS: gcc.target/powerpc/p8vector-vectorize-1.c scan-assembler-times [\t
]vsrd[\t ] 1
FAIL: gcc.target/powerpc/p8vector-vectorize-1.c scan-assembler-times [\t
]vcmpequd[\t ] 2
PASS: gcc.target/powerpc/p8vector-vectorize-1.c scan-assembler-times [\t
]vcmpgtsd[\t ] 1
PASS: gcc.target/powerpc/p8vector-vectorize-1.c scan-assembler-times [\t
]vcmpgtud[\t ] 1


Prior to 242750:

seurer:~/gcc/build/gcc-test$ grep vcmpequd p8vector-vectorize-1.s
vcmpequd 0,0,1
vcmpequd 0,0,1

After 242750:

vcmpequd 0,0,1
vcmpequd 1,1,13
vcmpequd 0,0,1
vcmpequd 1,1,13


It may be the test case just needs to be updated.

[Bug target/78603] New: internal compiler error: in dwarf2out_var_location, at dwarf2out.c:21846

[jcmvbkbc at gcc dot gnu.org]

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

Bug ID: 78603
   Summary: internal compiler error: in dwarf2out_var_location, at
dwarf2out.c:21846
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jcmvbkbc at gcc dot gnu.org
  Target Milestone: ---

Created attachment 40192
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40192=edit
preprocessed source that triggers ICE

gcc-5.4.0 with the attached patch (backport from r226828):

xtensa-buildroot-linux-uclibc-gcc -c -Wall -DPJ_AUTOCONF=1 -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -mlongcalls -mauto-litpools -Os
-g2 -DPJ_HAS_IPV6=1 -DPJ_IS_BIG_ENDIAN=1 -DPJ_IS_LITTLE_ENDIAN=0 -fPIC
-I/home/jcmvbkbc/ws/tensilica/buildroot/build-20161129-reproduce-libpjsip/host/usr/xtensa-buildroot-linux-uclibc/sysroot/usr/include
-I../include -o output/pjlib-test-xtensa-buildroot-linux-uclibc/thread.o
../src/pjlib-test/thread.c
../src/pjlib-test/thread.c: In function 'thread_test':
../src/pjlib-test/thread.c:328:1: internal compiler error: in
dwarf2out_var_location, at dwarf2out.c:21846
 }
 ^

[Bug c/78498] [7 Regression] valgrind conditional jump or move depends on uninitialised value(s) in format_type_warning

[dmalcolm at gcc dot gnu.org]

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

--- Comment #5 from David Malcolm  ---
Candidate patch:
  https://gcc.gnu.org/ml/gcc-patches/2016-11/msg02937.html

[Bug target/78602] PowerPC vec-extract-v2df.c can fail if -mcpu=power9 -O0

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 Target||powerpc64{,le}-linux-gnu,
   ||-mcpu=power9
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-11-29
 CC||dje at gcc dot gnu.org,
   ||segher at gcc dot gnu.org,
   ||wschmidt at gcc dot gnu.org
   Host||powerpc64{,le}-linux-gnu
   Assignee|unassigned at gcc dot gnu.org  |meissner at gcc dot 
gnu.org
 Ever confirmed|0   |1
  Build||powerpc64{,le}-linux-gnu

[Bug target/78602] New: PowerPC vec-extract-v2df.c can fail if -mcpu=power9 -O0

[meissner at gcc dot gnu.org]

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

Bug ID: 78602
   Summary: PowerPC vec-extract-v2df.c can fail if -mcpu=power9
-O0
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org
  Target Milestone: ---

In doing testing of a future patch, I forgot to apply any optimization when I
was building the vec-extract-v*.c tests for -mcpu=power9, and the compiler
fails with an insn not found error:

-genoa-> ./xgcc -B./ -save-temps -c -mcpu=power9 vec-extract-v2df.c 
In file included from vec-extract-v2df.c:9:0:
vec-extract.h: In function 'get_auto_n':
vec-extract.h:36:1: error: unrecognizable insn:
 }
 ^
(insn 8 7 9 2 (parallel [
(set (reg:DF 158)
(unspec:DF [
(reg:V2DF 157)
(mem/c:DI (plus:DI (reg/f:DI 150 virtual-stack-vars)
(const_int 16 [0x10])) [4 n+0 S8 A64])
] UNSPEC_VSX_EXTRACT))
(clobber (scratch:DI))
(clobber (scratch:V2DI))
]) "vec-extract.h":35 -1
 (nil))
vec-extract.h:36:1: internal compiler error: in extract_insn, at recog.c:2311
0x10888313 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/meissner/fsf-src/trunk-242932/gcc/rtl-error.c:108
0x10888377 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/meissner/fsf-src/trunk-242932/gcc/rtl-error.c:116
0x1084bc4b extract_insn(rtx_insn*)
/home/meissner/fsf-src/trunk-242932/gcc/recog.c:2311
0x105703a7 instantiate_virtual_regs_in_insn
/home/meissner/fsf-src/trunk-242932/gcc/function.c:1589
0x105703a7 instantiate_virtual_regs
/home/meissner/fsf-src/trunk-242932/gcc/function.c:1956
0x105703a7 execute
/home/meissner/fsf-src/trunk-242932/gcc/function.c:2005
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

The cause of the error is the rs6000_expand_vector_extract function was
expecting the element number to be either a constant or a register.  Normal
optimization does a force_reg before doing the expansion in the hopes of
letting GCSE find common instructions.  However if no optimization is used,
this is not done.

[Bug fortran/58904] ICE: accessing a component field of an unavailable type results in a seg fault

[janus at gcc dot gnu.org]

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

--- Comment #4 from janus at gcc dot gnu.org ---
(In reply to janus from comment #3)
> Draft patch:

Unfortunately this causes several regressions in the testsuite:

FAIL: gfortran.dg/asynchronous_1.f90   -O   (test for errors, line 35)
FAIL: gfortran.dg/asynchronous_1.f90   -O   (test for errors, line 36)
FAIL: gfortran.dg/asynchronous_1.f90   -O   (test for errors, line 40)
FAIL: gfortran.dg/asynchronous_1.f90   -O   (test for errors, line 41)
FAIL: gfortran.dg/asynchronous_1.f90   -O  (test for excess errors)
FAIL: gfortran.dg/class_result_4.f90   -O   (test for errors, line 3)
FAIL: gfortran.dg/class_result_4.f90   -O   (test for errors, line 4)
FAIL: gfortran.dg/class_result_4.f90   -O  (test for excess errors)
FAIL: gfortran.dg/derived_external_function_1.f90   -O0  (test for excess
errors)
FAIL: gfortran.dg/derived_external_function_1.f90   -O1  (test for excess
errors)
FAIL: gfortran.dg/derived_external_function_1.f90   -O2  (test for excess
errors)
FAIL: gfortran.dg/derived_external_function_1.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (test for excess
errors)
FAIL: gfortran.dg/derived_external_function_1.f90   -O3 -g  (test for excess
errors)
FAIL: gfortran.dg/derived_external_function_1.f90   -Os  (test for excess
errors)
FAIL: gfortran.dg/derived_function_interface_1.f90   -O   (test for errors,
line 41)
FAIL: gfortran.dg/derived_function_interface_1.f90   -O   (test for errors,
line 42)
FAIL: gfortran.dg/derived_function_interface_1.f90   -O  (test for excess
errors)
FAIL: gfortran.dg/func_result_5.f90   -O  (test for excess errors)
FAIL: gfortran.dg/function_types_1.f90   -O   (test for errors, line 9)
FAIL: gfortran.dg/function_types_1.f90   -O  (test for excess errors)
FAIL: gfortran.dg/function_types_2.f90   -O  (test for excess errors)
FAIL: gfortran.dg/function_types_3.f90   -O   (test for errors, line 8)
FAIL: gfortran.dg/function_types_3.f90   -O   (test for errors, line 17)
FAIL: gfortran.dg/function_types_3.f90   -O   (test for errors, line 18)
FAIL: gfortran.dg/function_types_3.f90   -O  (test for excess errors)
FAIL: gfortran.dg/func_derived_5.f90   -O  (test for excess errors)
FAIL: gfortran.dg/function_kinds_1.f90   -O0  (test for excess errors)
FAIL: gfortran.dg/function_kinds_1.f90   -O1  (test for excess errors)
FAIL: gfortran.dg/function_kinds_1.f90   -O2  (test for excess errors)
FAIL: gfortran.dg/function_kinds_1.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (test for excess
errors)
FAIL: gfortran.dg/function_kinds_1.f90   -O3 -g  (test for excess errors)
FAIL: gfortran.dg/function_kinds_1.f90   -Os  (test for excess errors)
FAIL: gfortran.dg/function_kinds_2.f90   -O   (test for errors, line 16)
FAIL: gfortran.dg/function_kinds_2.f90   -O  (test for excess errors)

[Bug preprocessor/78569] "internal compiler error: in get_substring_ranges_for_loc" processing sprintf buffer overflow

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 CC||daniel.black at au dot ibm.com

--- Comment #4 from David Malcolm  ---
*** Bug 78169 has been marked as a duplicate of this bug. ***

[Bug preprocessor/78169] internal compiler error: in get_substring_ranges_for_loc, at input.c:1379

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #7 from David Malcolm  ---


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

[Bug preprocessor/78169] internal compiler error: in get_substring_ranges_for_loc, at input.c:1379

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #6 from David Malcolm  ---
Thanks for filing this.

The final part of the error message in comment #0 is this:

  internal compiler error: in get_substring_ranges_for_loc, at input.c:1379

I think that this is a dup of PR 78569.

Line 1379 of input.c was:

1379   gcc_assert (line_width >= (start.column - 1 + literal_length));

https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/input.c;hb=f9f267593af83bc4b4327294ae00a4b77955f295

until r242667 where it moved to line 1388 (as seen in PR 78569):

1388   gcc_assert (line_width >= (start.column - 1 + literal_length));

https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/input.c;hb=8df44fbf7f4788ef56a3b792cbb833b654392d7c

so I think both bugs are the same assertion firing.

In both cases, I think what we're seeing is an issue where the .i file is
out-of-sync with the .c file; perhaps the .c file got edited after the .i file
was written?

I'm working on a fix.

[Bug tree-optimization/78512] [7 Regression] r242674 miscompiles Linux kernel

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #7 from Martin Sebor  ---
Patch along with a rationale for it posted for review:
https://gcc.gnu.org/ml/gcc-patches/2016-11/msg02833.html

%p handling removed in r242975.

[Bug fortran/58904] ICE: accessing a component field of an unavailable type results in a seg fault

[janus at gcc dot gnu.org]

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

--- Comment #3 from janus at gcc dot gnu.org ---
Draft patch:


Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c  (revision 242960)
+++ gcc/fortran/decl.c  (working copy)
@@ -5962,6 +5962,19 @@ gfc_match_function_decl (void)
   return m;
 }

+  if (current_ts.type == BT_DERIVED || current_ts.type == BT_CLASS)
+{
+  sym = gfc_use_derived (current_ts.u.derived);
+
+  if (sym == NULL)
+   {
+ m = MATCH_ERROR;
+ goto cleanup;
+   }
+
+  current_ts.u.derived = sym;
+}
+
   if (gfc_match ("function% %n", name) != MATCH_YES)
 {
   gfc_current_locus = old_loc;


This generates the right error, thus removing the ICE, but also produces
several follow-up errors, because the function statement is rejected:


c0.f90:3:14:

   TYPE(mytype) FUNCTION create_sort_range(b) result(r)
  1
Error: Derived type ‘mytype’ at (1) is being used before it is defined
c0.f90:4:13:

 INTEGER b
 1
Error: Unexpected data declaration statement in CONTAINS section at (1)
c0.f90:5:6:

 r%b = b
  1
Error: Symbol ‘r’ at (1) has no IMPLICIT type
c0.f90:6:5:

   END FUNCTION create_sort_range
 1
Error: Expecting END MODULE statement at (1)

[Bug tree-optimization/78512] [7 Regression] r242674 miscompiles Linux kernel

[msebor at gcc dot gnu.org]

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

--- Comment #6 from Martin Sebor  ---
Author: msebor
Date: Tue Nov 29 21:08:02 2016
New Revision: 242975

URL: https://gcc.gnu.org/viewcvs?rev=242975=gcc=rev
Log:
PR tree-optimization/78512 - [7 Regression] r242674 miscompiles Linux kernel

gcc/ChangeLog:

PR tree-optimization/78512
* config/linux.h (TARGET_PRINTF_POINTER_FORMAT): Remove.
* config/rs6000/linux.h: Same.
* config/rs6000/linux64.h: Same.
* config/sol2.h: Same.
* config/sol2.c (solaris_printf_pointer_format): Remove.
* doc/tm.texi.in (TARGET_PRINTF_POINTER_FORMAT): Remove.
* doc/tm.texi: Regenerate.
* gimple-ssa-sprintf.c (format_pointer): Rempove.
(pass_sprintf_length::compute_format_length): Return bool.
(pass_sprintf_length::handle_gimple_call): Adjust.
* target.def (printf_pointer_format): Remove.
* targhooks.c (default_printf_pointer_format): Remove.
(linux_printf_pointer_format): Same.
* targhooks.h (default_printf_pointer_format): Remove.
(linux_printf_pointer_format, solaris_printf_pointer_format): Same.

gcc/testsuite/ChangeLog:

PR tree-optimization/78512
* gcc.dg/tree-ssa/builtin-sprintf-6.c: Add test cases.
* gcc.dg/tree-ssa/builtin-sprintf-warn-1.c: Remove test cases.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/linux.h
trunk/gcc/config/rs6000/linux.h
trunk/gcc/config/rs6000/linux64.h
trunk/gcc/config/sol2.c
trunk/gcc/config/sol2.h
trunk/gcc/doc/tm.texi
trunk/gcc/doc/tm.texi.in
trunk/gcc/gimple-ssa-sprintf.c
trunk/gcc/target.def
trunk/gcc/targhooks.c
trunk/gcc/targhooks.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-6.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c

[Bug tree-optimization/78601] [7 regression] test case gcc.dg/uninit-pred-6_a.c and gcc.dg/uninit-pred-7_c.c fail starting with r242639

[aldyh at gcc dot gnu.org]

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

--- Comment #1 from Aldy Hernandez  ---
Without verifying, this looks like a duplicate of pr78566.

Can you try with the latest trunk plus the patch I've posted here:

https://gcc.gnu.org/ml/gcc-patches/2016-11/msg02900.html

[Bug tree-optimization/78601] New: [7 regression] test case gcc.dg/uninit-pred-6_a.c and gcc.dg/uninit-pred-7_c.c fail starting with r242639

[seurer at linux dot vnet.ibm.com]

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

Bug ID: 78601
   Summary: [7 regression] test case gcc.dg/uninit-pred-6_a.c and
gcc.dg/uninit-pred-7_c.c fail starting with r242639
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at linux dot vnet.ibm.com
  Target Milestone: ---

Running /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/dg.exp ...
FAIL: gcc.dg/uninit-pred-6_a.c warning (test for warnings, line 36)

=== gcc Summary ===

# of expected passes2
# of unexpected failures1

It used to generate a warning but no longer does:

seurer@genoa:~/gcc/build/gcc-test2$ /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/uninit-pred-6_a.c 
-fno-diagnostics-show-caret -fdiagnostics-color=never   -Wuninitialized -O2 -S 
 -o uninit-pred-6_a.s
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/uninit-pred-6_a.c: In function
'foo_2':
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/uninit-pred-6_a.c:36:7:
warning: 'v' may be used uninitialized in this function [-Wmaybe-uninitialized]


Running /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/dg.exp ...
FAIL: gcc.dg/uninit-pred-7_c.c (internal compiler error)
FAIL: gcc.dg/uninit-pred-7_c.c warning (test for warnings, line 29)
FAIL: gcc.dg/uninit-pred-7_c.c (test for excess errors)

=== gcc Summary ===

# of unexpected failures3

seurer@genoa:~/gcc/build/gcc-test2$ /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/uninit-pred-7_c.c 
-fno-diagnostics-show-caret -fdiagnostics-color=never   -Wuninitialized -O2 -S 
 -o uninit-pred-7_c.s
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/uninit-pred-7_c.c: In function
'foo':
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/uninit-pred-7_c.c:9:5: internal
compiler error: in operator[], at vec.h:732
0x10b5afbb vec::operator[](unsigned int)
/home/seurer/gcc/gcc-test2/gcc/vec.h:732
0x10b5afbb vec::operator[](unsigned int)
/home/seurer/gcc/gcc-test2/gcc/vec.h:1216
0x10b5afbb flatten_out_predicate_chains
/home/seurer/gcc/gcc-test2/gcc/tree-ssa-uninit.c:2226
0x10b5afbb uninit_ops_invalidate_phi_use
/home/seurer/gcc/gcc-test2/gcc/tree-ssa-uninit.c:2300
0x10b5b68f is_use_properly_guarded
/home/seurer/gcc/gcc-test2/gcc/tree-ssa-uninit.c:2364
0x10b5cd8f find_uninit_use
/home/seurer/gcc/gcc-test2/gcc/tree-ssa-uninit.c:2434
0x10b5cd8f warn_uninitialized_phi
/home/seurer/gcc/gcc-test2/gcc/tree-ssa-uninit.c:2504
0x10b5cd8f execute
/home/seurer/gcc/gcc-test2/gcc/tree-ssa-uninit.c:2612

[Bug c/78600] gcc reads c++ object file during build for no apparent reason

[bezemer at cs dot queensu.ca]

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

cpbezemer at gmail dot com  changed:

   What|Removed |Added

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

--- Comment #1 from cpbezemer at gmail dot com  
---
Sorry, just found out that this is normal behaviour. gcc opens the directory
and reads files until it finds the C version

[Bug c/78600] New: gcc reads c++ object file during build for no apparent reason

[bezemer at cs dot queensu.ca]

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

Bug ID: 78600
   Summary: gcc reads c++ object file during build for no apparent
reason
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bezemer at cs dot queensu.ca
  Target Milestone: ---

I am a researcher in a team that is working on build systems and we are doing a
case study on missing dependencies in the Qt 5.3.0 build system. I found
something that we could not explain and I contacted the Qt mailing list... but
I was forwarded to the gcc mailing list because it looks like we detected a bug
in gcc.


My question:
The target for .obj/qgrayraster.o in the Makefile in qtbase/src/gui has a
dependency on .pch/Qt5Gui.gch/c, but we noticed that during the build, the
.pch/Qt5Gui.gch/c++ file is also read. Is there a reason why gcc would read the
c++ file during the build? E.g. because c and c++ code is being mixed? We do
not observe similar behaviour (i.e., the c file being read by g++) for targets
that are compiled from .cpp files.

Reply from one of the Qt maintainers:
I can confirm it with strace. Seems like a bug because there is no C++ code
mixed in for that particular compilation. You should check with GCC folks.


The target in question:
.obj/qgrayraster.o: painting/qgrayraster.c
../../include/QtGui/5.3.0/QtGui/private/qrasterdefs_p.h \
painting/qrasterdefs_p.h \
../../include/QtGui/5.3.0/QtGui/private/qgrayraster_p.h \
painting/qgrayraster_p.h \
.pch/Qt5Gui.gch/c
$(CC) -c -include .pch/Qt5Gui $(CFLAGS) $(INCPATH) -o
.obj/qgrayraster.o painting/qgrayraster.c


Sorry for not having a shorter working example.

[Bug rtl-optimization/78342] [7 Regression] ICE in rtl_verify_bb_insns, at cfgrtl.c:2657 (error: flow control insn inside a basic block)

[segher at gcc dot gnu.org]

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

--- Comment #5 from Segher Boessenkool  ---
Please file a separate bug.  PR77346 is unrelated, let's not mix matters. 
Thanks!

[Bug ipa/78599] [7 Regression] hwint.h:292:72: runtime error: shift exponent 64 is too large for 64-bit type 'long int'

[trippels at gcc dot gnu.org]

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

--- Comment #1 from Markus Trippelsdorf  ---
markus@x4 ~ % cat bench.ii
struct A {
  enum { __value };
};
template  _OI __copy_move_a2(_II, _OI);
template  void copy(_II, _II, _OI p3) {
  __copy_move_a2(0, p3);
}
struct B {
  template  using __iter = B;
  B(const __iter &);
};
struct C {
  C(int, int);
  B m_fn1();
};
void run(void(double *, double *));
void deque_test(double *p1, double *p2) {
  C a(0, 0);
  B b = a.m_fn1();
  copy(p1, p2, b);
}
int main() { run(deque_test); }

markus@x4 ~ % /var/tmp/gcc_ubsan/usr/local/bin/g++ -r -nostdlib -O2 -flto
bench.ii
../../gcc/gcc/hwint.h:292:61: runtime error: shift exponent 64 is too large for
64-bit type 'long unsigned int'
../../gcc/gcc/hwint.h:292:72: runtime error: shift exponent 64 is too large for
64-bit type 'long int'

[Bug libgcc/78576] [PPC] wrong long double to long int conversion

[bergner at gcc dot gnu.org]

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

--- Comment #9 from Peter Bergner  ---
(In reply to jos...@codesourcery.com from comment #7)
> What are the actual high and low doubles in the return from powl?  The 
> simplest reason for the reported result here would be that powl returns a 
> result very slightly less than 27 (which is fine; there is no expectation 
> of powl, or any operations for IBM long double, being correctly rounded).

Using gdb, I see:

(gdb) info registers f1 f2
f1 27   (raw 0x403b)
f2 -3.0814879110195774e-33  (raw 0xb930)

[Bug preprocessor/78569] "internal compiler error: in get_substring_ranges_for_loc" processing sprintf buffer overflow

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-11-29
 Depends on|78498   |
   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #3 from David Malcolm  ---
I'm able to reproduce this, based on the theory in comment #2.

I'm working on a fix.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78498
[Bug 78498] [7 Regression] valgrind conditional jump or move depends on
uninitialised value(s) in format_type_warning

[Bug ipa/78599] New: [7 Regression] hwint.h:292:72: runtime error: shift exponent 64 is too large for 64-bit type 'long int'

[trippels at gcc dot gnu.org]

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

Bug ID: 78599
   Summary: [7 Regression] hwint.h:292:72: runtime error: shift
exponent 64 is too large for 64-bit type 'long int'
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
CC: mjambor at suse dot cz, prathamesh3492 at gcc dot gnu.org
  Target Milestone: ---

Since r239769:

commit a54071b275d13d8516e0cb305fb5cb49da201f14
Author: prathamesh3492 
Date:   Fri Aug 26 08:05:39 2016 +

Patch for performing interprocedural bitwise constant propagation.

2016-08-26  Prathamesh Kulkarni  
Martin Jambhor  

I get:

~ % UBSAN_OPTIONS=print_stacktrace=1 /var/tmp/gcc_ubsan/usr/local/bin/g++ -O2
-flto bench.cpp
...
../../gcc/gcc/hwint.h:292:61: runtime error: shift exponent 64 is too large for
64-bit type 'long unsigned int'
#0 0x34f7541 in sext_hwi ../../gcc/gcc/hwint.h:292
#1 0x34f7541 in
wi::unary_traits > >::result_type
wi::sext >
>(generic_wide_int > const&, unsigned int)
../../gcc/gcc/wide-int.h:2063
#2 0x34f7541 in
ipcp_bits_lattice::meet_with(generic_wide_int >,
generic_wide_int >, unsigned int)
../../gcc/gcc/ipa-cp.c:1024
#3 0x34fe417 in propagate_bits_accross_jump_function(cgraph_edge*, int,
ipa_jump_func*, ipcp_bits_lattice*) ../../gcc/gcc/ipa-cp.c:1836
#4 0x350009c in propagate_constants_accross_call
../../gcc/gcc/ipa-cp.c:2261
#5 0x3510372 in propagate_constants_topo ../../gcc/gcc/ipa-cp.c:3162
#6 0x3510372 in ipcp_propagate_stage ../../gcc/gcc/ipa-cp.c:3272
#7 0x351b158 in ipcp_driver ../../gcc/gcc/ipa-cp.c:5002
#8 0x16282e8 in execute_one_pass(opt_pass*) ../../gcc/gcc/passes.c:2370
#9 0x162c0ca in execute_ipa_pass_list(opt_pass*)
../../gcc/gcc/passes.c:2805
#10 0x698e32 in do_whole_program_analysis ../../gcc/gcc/lto/lto.c:3095
#11 0x698e32 in lto_main() ../../gcc/gcc/lto/lto.c:3316
#12 0x1a05a7a in compile_file ../../gcc/gcc/toplev.c:463
#13 0x619d44 in do_compile ../../gcc/gcc/toplev.c:1983
#14 0x619d44 in toplev::main(int, char**) ../../gcc/gcc/toplev.c:2117
#15 0x61c3a6 in main ../../gcc/gcc/main.c:39
#16 0x7fc03c93b310 in __libc_start_main ../csu/libc-start.c:286
#17 0x61c7c9 in _start
(/var/tmp/gcc_ubsan/usr/local/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto1+0x61c7c9)

Happens with almost any program when using -flto.

[Bug preprocessor/78569] "internal compiler error: in get_substring_ranges_for_loc" processing sprintf buffer overflow

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #2 from David Malcolm  ---
Thanks for filing this bug report.

(In reply to Andrew Pinski from comment #1)
> I think this is also the same issue as PR 78498.

Thanks, but I think it's a separate issue.


The backtrace shows the ICE is at line 1388 of input.c, which would suggest
it's a failure of this assertion:

  gcc_assert (line_width >= (start.column - 1 + literal_length));

where it earlier called:

  const char *line = location_get_source_line (start.file, start.line,
   _width);

I *think* what's happening is that that line is reading the latest on-disk copy
of the input file, but using location information based on the state of the
input file when the .i file was created.

I'm not able to reproduce this yet, but I'll try to based on the above theory.

[Bug libstdc++/78595] Unnecessary copies in _Rb_tree

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
And for the insert-with-hint case:

@@ -848,13 +855,14 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
   { return _M_t._M_insert_unique_(__position, __x); }

 #if __cplusplus >= 201103L
-  template::value>::type>
+  iterator
+  insert(const_iterator __position, value_type&& __x)
+  { return _M_t._M_insert_unique_(__position, std::move(__x)); }
+
+  template>
 iterator
 insert(const_iterator __position, _Pair&& __x)
-{ return _M_t._M_insert_unique_(__position,
-   std::forward<_Pair>(__x)); }
+{ return _M_t._M_insert_unique_(__position, value_type(__x)); }
 #endif

   /**

We could do something similar for multimap, but it would still involve an
unnecessary move when we do the insertion. That would be an improvement on what
we have today, but the optimal case would totally refactor _M_insert_equal* to
allocate a node immediately, construct into it, get the insert position, then
hook the node in at the right position. That's complicated, and definitely not
stage 3 material.

[Bug tree-optimization/78598] New: tree-ssa-loop-prefetch.c:835:16: runtime error: signed integer overflow

[trippels at gcc dot gnu.org]

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

Bug ID: 78598
   Summary: tree-ssa-loop-prefetch.c:835:16: runtime error: signed
integer overflow
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
  Target Milestone: ---

markus@x4 mplayer % cat subassconvert.i
struct bstr {
  long len;
} fn1();
struct microdvd_tag {
  int key;
  int data1;
  struct bstr data_string;
} fn2() {
  struct microdvd_tag *a;
  int i = sizeof "cfshyYpo";
  for (;; i--)
switch (a[i].key)
case 'y':
  if (a[i].data1)
fn1();
}

markus@x4 mplayer % UBSAN_OPTIONS=print_stacktrace=1
/var/tmp/gcc_ubsan/usr/local/bin/gcc  -O3 -march=amdfam10 -c subassconvert.i
../../gcc/gcc/tree-ssa-loop-prefetch.c:835:16: runtime error: signed integer
overflow: 288230376151711743 * 64 cannot be represented in type 'long int'
#0 0x232e7bd in prune_ref_by_group_reuse
../../gcc/gcc/tree-ssa-loop-prefetch.c:835
#1 0x232e7bd in prune_ref_by_reuse
../../gcc/gcc/tree-ssa-loop-prefetch.c:923
#2 0x232e7bd in prune_group_by_reuse
../../gcc/gcc/tree-ssa-loop-prefetch.c:936
#3 0x232e7bd in prune_by_reuse ../../gcc/gcc/tree-ssa-loop-prefetch.c:975
#4 0x232e7bd in loop_prefetch_arrays
../../gcc/gcc/tree-ssa-loop-prefetch.c:1879
#5 0x232e7bd in tree_ssa_prefetch_arrays()
../../gcc/gcc/tree-ssa-loop-prefetch.c:1989
#6 0x195ad78 in execute_one_pass(opt_pass*) ../../gcc/gcc/passes.c:2370
#7 0x195cc0b in execute_pass_list_1 ../../gcc/gcc/passes.c:2459
#8 0x195cc34 in execute_pass_list_1 ../../gcc/gcc/passes.c:2460
#9 0x195cc34 in execute_pass_list_1 ../../gcc/gcc/passes.c:2460
#10 0x195ccc4 in execute_pass_list(function*, opt_pass*)
../../gcc/gcc/passes.c:2470
#11 0xc75e4b in cgraph_node::expand() ../../gcc/gcc/cgraphunit.c:2001
#12 0xc7b35a in expand_all_functions ../../gcc/gcc/cgraphunit.c:2137
#13 0xc7b35a in symbol_table::compile() ../../gcc/gcc/cgraphunit.c:2494
#14 0xc85517 in symbol_table::compile() ../../gcc/gcc/cgraphunit.c:2587
#15 0xc85517 in symbol_table::finalize_compilation_unit()
../../gcc/gcc/cgraphunit.c:2584
#16 0x1d3ead0 in compile_file ../../gcc/gcc/toplev.c:488
#17 0x629a34 in do_compile ../../gcc/gcc/toplev.c:1983
#18 0x629a34 in toplev::main(int, char**) ../../gcc/gcc/toplev.c:2117
#19 0x62c066 in main ../../gcc/gcc/main.c:39
#20 0x7f60d01cf310 in __libc_start_main ../csu/libc-start.c:286
#21 0x62c489 in _start
(/var/tmp/gcc_ubsan/usr/local/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/cc1+0x62c489)

[Bug libstdc++/78595] Unnecessary copies in _Rb_tree

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
For example:

--- a/libstdc++-v3/include/bits/stl_map.h
+++ b/libstdc++-v3/include/bits/stl_map.h
@@ -795,12 +795,19 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
   { return _M_t._M_insert_unique(__x); }

 #if __cplusplus >= 201103L
-  template::value>::type>
+  std::pair
+  insert(value_type&& __x)
+  { return _M_t._M_insert_unique(std::move(__x)); }
+
+  template
+   using _Insertable
+ = _Require<__not_>,
+is_constructible>;
+
+  template>
 std::pair
 insert(_Pair&& __x)
-{ return _M_t._M_insert_unique(std::forward<_Pair>(__x)); }
+{ return _M_t._M_insert_unique(value_type(__x)); }
 #endif

 #if __cplusplus >= 201103L


We could also add a static assertion in _Rb_tree::_M_insert_unique  to ensure
it's only called with value_type arguments, so we know the caller has done any
necessary conversions to avoid temporaries.

For multimap/multiset we probably want to do things differently, and just
change _M_insert_equal to allocate the node first and construct the element
into it, and get the key directly from the constructed element.

[Bug target/78597] New: [7 regression] test case gcc.dg/torture/fp-int-convert-float128-ieee.c (and others) fail starting with r242780

[seurer at linux dot vnet.ibm.com]

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

Bug ID: 78597
   Summary: [7 regression] test case
gcc.dg/torture/fp-int-convert-float128-ieee.c (and
others) fail starting with r242780
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at linux dot vnet.ibm.com
  Target Milestone: ---

Previously these tests were unsupported for power and are still not supported.

FAIL: gcc.dg/torture/fp-int-convert-float128-ieee.c   -O0  execution test
FAIL: gcc.dg/torture/fp-int-convert-float128-ieee.c   -O1  execution test
FAIL: gcc.dg/torture/fp-int-convert-float128-ieee.c   -O2  execution test
FAIL: gcc.dg/torture/fp-int-convert-float128-ieee.c   -O2 -flto
-fno-use-linker-plugin -flto-partition=none  execution test
FAIL: gcc.dg/torture/fp-int-convert-float128-ieee.c   -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects  execution test
FAIL: gcc.dg/torture/fp-int-convert-float128-ieee.c   -O3 -g  execution test
FAIL: gcc.dg/torture/fp-int-convert-float128-ieee.c   -Os  execution test
FAIL: gcc.dg/torture/fp-int-convert-float64x.c   -O0  execution test
FAIL: gcc.dg/torture/fp-int-convert-float64x.c   -O1  execution test
FAIL: gcc.dg/torture/fp-int-convert-float64x.c   -O2  execution test
FAIL: gcc.dg/torture/fp-int-convert-float64x.c   -O2 -flto
-fno-use-linker-plugin -flto-partition=none  execution test
FAIL: gcc.dg/torture/fp-int-convert-float64x.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
FAIL: gcc.dg/torture/fp-int-convert-float64x.c   -O3 -g  execution test
FAIL: gcc.dg/torture/fp-int-convert-float64x.c   -Os  execution test

[Bug rtl-optimization/78596] New: combine.c:12561:14: runtime error: left shift of negative value -9

[trippels at gcc dot gnu.org]

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

Bug ID: 78596
   Summary: combine.c:12561:14: runtime error: left shift of
negative value -9
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
  Target Milestone: ---

markus@x4 mplayer % cat demux_mkv.i
extern void fn2();
void fn1() {
  int a = fn1, b = 8;
  if (a > 18446744073709551615UL - b)
fn2();
}

markus@x4 mplayer % UBSAN_OPTIONS=print_stacktrace=1
/var/tmp/gcc_ubsan/usr/local/bin/gcc -w -O2 -c demux_mkv.i
../../gcc/gcc/combine.c:12561:14: runtime error: left shift of negative value
-9
#0 0x361d796 in simplify_comparison ../../gcc/gcc/combine.c:12561
#1 0x3620ed6 in simplify_set ../../gcc/gcc/combine.c:6652
#2 0x3627f5f in combine_simplify_rtx ../../gcc/gcc/combine.c:6187
#3 0x3632a35 in subst ../../gcc/gcc/combine.c:5487
#4 0x3641bd4 in try_combine ../../gcc/gcc/combine.c:3269
#5 0x36561b7 in combine_instructions ../../gcc/gcc/combine.c:1265
#6 0x36561b7 in rest_of_handle_combine ../../gcc/gcc/combine.c:14581
#7 0x36561b7 in execute ../../gcc/gcc/combine.c:14626
#8 0x195ad78 in execute_one_pass(opt_pass*) ../../gcc/gcc/passes.c:2370
#9 0x195cc0b in execute_pass_list_1 ../../gcc/gcc/passes.c:2459
#10 0x195cc34 in execute_pass_list_1 ../../gcc/gcc/passes.c:2460
#11 0x195ccc4 in execute_pass_list(function*, opt_pass*)
../../gcc/gcc/passes.c:2470
#12 0xc75e4b in cgraph_node::expand() ../../gcc/gcc/cgraphunit.c:2001
#13 0xc7b35a in expand_all_functions ../../gcc/gcc/cgraphunit.c:2137
#14 0xc7b35a in symbol_table::compile() ../../gcc/gcc/cgraphunit.c:2494
#15 0xc85517 in symbol_table::compile() ../../gcc/gcc/cgraphunit.c:2587
#16 0xc85517 in symbol_table::finalize_compilation_unit()
../../gcc/gcc/cgraphunit.c:2584
#17 0x1d3ead0 in compile_file ../../gcc/gcc/toplev.c:488
#18 0x629a34 in do_compile ../../gcc/gcc/toplev.c:1983
#19 0x629a34 in toplev::main(int, char**) ../../gcc/gcc/toplev.c:2117
#20 0x62c066 in main ../../gcc/gcc/main.c:39
#21 0x7f40bae26310 in __libc_start_main ../csu/libc-start.c:286
#22 0x62c489 in _start
(/var/tmp/gcc_ubsan/usr/local/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/cc1+0x62c489)

[Bug fortran/77532] ICE in check_dtio_interface1, at fortran/interface.c:4622

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

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

--- Comment #8 from Gerhard Steinmetz  
---

ICEs from above are fixed a while ago, not present with gfortran-7-20161127.

[Bug target/78594] Bug in November 11th, 2016 change to rs6000.md

[meissner at gcc dot gnu.org]

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

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

[Bug libstdc++/78595] Unnecessary copies in _Rb_tree

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-11-29
 CC||ville.voutilainen at gmail dot 
com
   Assignee|unassigned at gcc dot gnu.org  |ville.voutilainen at 
gmail dot com
 Ever confirmed|0   |1

--- Comment #1 from Ville Voutilainen  ---
I'll see what I can do.

[Bug libstdc++/78595] New: Unnecessary copies in _Rb_tree

[redi at gcc dot gnu.org]

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

Bug ID: 78595
   Summary: Unnecessary copies in _Rb_tree
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

#include 
#include 

struct X {
  operator std::pair() const { puts("conv"); return {}; }
};

int main()
{
  std::map m;
  m.insert(X());
}

This prints "conv" twice, because we create a temporary to get the key here:

  pair<_Base_ptr, _Base_ptr> __res
= _M_get_insert_unique_pos(_KeyOfValue()(__v));

and then again when we insert the node:

  return _Res(_M_insert_(__res.first, __res.second,
 _GLIBCXX_FORWARD(_Arg, __v), __an),
  true);

This is bad.

Either we should have separate _Rb_tree::_M_insert_unique() functions that take
value_type arguments, to avoid unnecessary temporaries, and the generic one
taking _Arg&& should create a local value_type object, get the key from that,
and then move from it if insertion happens.

Alternatively, we could constrain the map::insert(_Pair&&) function that calls
it so it's only used when !is_same, value_type> and create the
copy there, and ensure _M_insert_unique(_Arg&&) is only ever called with
value_type arguments.

There's a similar problem for multimap:

#include 
#include 

struct X {
  operator std::pair() const { puts("conv"); return {}; }
};

int main()
{
  std::multimap m;
  m.insert(X());
}

This also prints "conv" twice, and here we *definitely* don't need the
temporary in order to get the key, because we know that insertion always
succeeds. This is bad too.

[Bug libgcc/78576] [PPC] wrong long double to long int conversion

[wschmidt at gcc dot gnu.org]

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

--- Comment #8 from Bill Schmidt  ---
At the time, Breno reported 0x403b  as the high half, which is
accurate.  Looking back, I didn't get a report of the low half.  If somehow
that were produced as a negative number, that would also account for the
problem.  That would seem pretty weird, but we can't discount it.

[Bug tree-optimization/78529] [7 Regression] gcc.c-torture/execute/builtins/strcat-chk.c failed with lto/O2

[prathamesh3492 at gcc dot gnu.org]

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

--- Comment #10 from prathamesh3492 at gcc dot gnu.org ---
On a related note, Jim told me he is seeing following failures
on aarch64-none-elf before and after updating the tree.

FAIL: gcc.c-torture/execute/builtins/memset-chk.c execution,  -O2
-flto -fuse-linker-plugin -fno-fat-lto-objects
FAIL: gcc.c-torture/execute/builtins/snprintf-chk.c execution,  -O2
-flto -fuse-linker-plugin -fno-fat-lto-objects
FAIL: gcc.c-torture/execute/builtins/vsnprintf-chk.c execution,  -O2
-flto -fuse-linker-plugin -fno-fat-lto-objects

However he isn't seeing the failure for strcat-chk.c before or after.
Before he updated the tree, it was older than 23rd Nov, which didn't
contain r242745. Perhaps the issue is sth else ?
Bin, are you able to see the above test-cases FAIL too ?

Thanks,
Prathamesh

[Bug target/70718] multilib_defaults on nios2 refers to -EL

[stilor at att dot net]

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

--- Comment #1 from Alexey Neyman  ---
Ping? [trivial patch]

[Bug target/78594] Bug in November 11th, 2016 change to rs6000.md

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

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

[Bug target/78594] New: Bug in November 11th, 2016 change to rs6000.md

[meissner at gcc dot gnu.org]

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

Bug ID: 78594
   Summary: Bug in November 11th, 2016 change to rs6000.md
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org
  Target Milestone: ---

In my November 11th, 2016 change to GCC, I had a small typo in adding support
for QImode and HImode to go into vector registers.

I forgot to use the 'x' print_modifier for the STXSIBX and STXSIHX
instructions.  This meant that if you tried to store a QImode or HImode from a
traditional Altivec register, it would wind up storing a floating point
register instead.

[Bug fortran/78593] ICE in gfc_match_varspec, at fortran/primary.c:2053

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

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

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

Works with a public type declaration :


$ cat z2.f90
module m1
   public
   type t
  integer :: a
   end type
end

module m2
   use m1
   interface operator(+)
  module procedure add
   end interface
contains
   type(t) function add (x, y)
  type(t), intent(in) :: x, y
  add%a = x%a + y%a
   end
end